JP7247246B2 - ブロックチェーンにおけるエンティティの効率的な移転のための方法およびシステム - Google Patents

Description

本発明は、分散型、ピアツーピア台帳（peer-to-peer ledgers）に関し、特には、ブロックチェーン技術に関する。本発明は、また、部分的にトークナイゼーション（tokenisation）とセキュリティ技術、および、ブロックチェーンを介してエンティティ及び／又はエンティティの所有権を移転するためのセキュア（secure）なメカニズム、に関する。本発明は、ブロックチェーンにわたり異なる当事者間でセキュアなトランザクションを実行する方法を含み得る。

ブロックチェーンは、ブロック、次にトランザクションを構成するもの、で構成されたコンピュータベースの分権的な、分散システムとして実装されるピアツーピアの電子台帳である。各トランザクションは、ブロックチェーンシステムにおける参加者間のデジタルアセットの制御の移転（transfer）を符号化（encode）するデータ構造であり、そして、少なくとも１つの入力と少なくとも１つの出力を含んでいる。各ブロックは、前のブロックのハッシュを含んでおり、ブロックは一緒に連鎖されて（chained）、その最初からブロックチェーンに対して書き込まれてきた全てのトランザクションに係る永続的で、変更不可能なレコードを作成する。トランザクションは、入力と出力の中に埋め込まれた（embedded）スクリプト（scripts）として知られている小さいプログラムを含んでおり、トランザクションの出力が、どのように又は誰によってアクセスされ得るかを特定している。ビットコイン（Bitcoin）プラットフォームにおいて、これらのスクリプトはスタックベース（stack-based）のスクリプト言語を使用して記述されている。

トランザクションがブロックチェーンに対して書き込まれるためには、トランザクションが「検証される（”validated”）」必要がある。ネットワークノード（マイナ（miner））は、各トランザクションが有効であることを保証するための作業を実行し、無効なトランザクションはネットワークから拒否されている。ノード上にインストールされたソフトウェアクライアントは、ロックおよびロック解除スクリプト（locking and unlocking scripts）を実行することによって、未使用トランザクション（unspent transaction、UTXO）においてこの検証作業を実施する。ロックおよびロック解除スクリプトの実行が真（TRUE）であると評価された場合に、トランザクションは有効（valid）であり、そして、トランザクションがブロックチェーンに対して書き込まれる。従って、トランザクションがブロックチェーンに対して書き込まれるためには、ｉ）トランザクションを受け取る最初のノードによって検証される必要があり、－トランザクションが検証された場合に、ノードはネットワークにおける他のノードに対してトランザクションをリレーし（relay）、そして、ｉｉ）マイナによって構築された新しいブロックに対して追加され、かつ、ｉｉｉ）採掘（mined）、すなわち過去のトランザクションの公開台帳に対して追加されることを要する。

ブロックチェーン技術は、仮想通貨（cryptocurrency）実装の使用について最も広く知られているが、デジタル起業家（entrepreneur）は、新しいシステムを実施するために、ビットコインが基づいている暗号化セキュリティシステムとブロックチェーンに保管できるデータと両方の使用について探求を始めている。ブロックチェーンが、仮想通貨の領域に限定されない自動化されたタスクおよびプロセスについて使用され得るとすれば、非常に有利であろう。そうしたソリューションは、ブロックチェーンの利点（例えば、イベントの永続的で、改ざん防止（tamper proof）な記録、分散化処理、等）を利用することができるだろうし、一方で、それらのアプリケーションにおいてはより汎用性（versatile）がある。

現在の研究の１つの領域は、「スマートコントラクト（”smart contracts”）」の実装のためにブロックチェーンを使用することである。これらは、マシンで読取り可能な契約または同意の条件（condition）の実行を自動化するようにデザインされたコンピュータプログラムである。自然言語で書かれるであろう従来の契約とは異なり、スマートコントラクトは、結果を生成するために入力を処理することができるルールを含むマシンで実行可能なプログラムであり、次いで、その結果に応じて実行されるべきアクションを生じさせることができる。

ブロックチェーン関連の別の関心領域は、ブロックチェーンを介して現実世界のエンティティ（real-world entities）を表現し、かつ、移転するための「トークン（”tokens”）」（または「カラードコイン（”coloured coin”）」）の使用である。潜在的に機密扱い又は秘密のアイテムは、識別可能（discernable）な意味または価値を持たないトークンによって表すことができる。トークンは、従って、識別子（identifier）として機能し、現実世界のアイテムをブロックチェーンから参照できるようにする。トークナイゼーション（tokenisation）技術は、セキュリティ、匿名性、およびクロスプラットフォームのコンプライアンスが重要である多くの異なるタイプのコンテキスト（contexts）に関して使用され得る。そうしたアプリケーションの領域の１つは金融用途（financial applications）であるが、本発明は金融取引に関する使用について限定されるものではない。

この文書においては、我々は、電子、コンピュータベース、分散型台帳に係る全ての形態を含むように、用語「ブロックチェーン（”blockchain”）」を使用している。これらは、コンセンサスベースのブロックチェーンおよびトランザクションチェーン技術に限定されるわけではないが、パーミッションと非パーミッション台帳（permissioned and un-permissioned ledgers）、共有台帳、および、その変形を含んでいる。ビットコイン技術の最も広く知られているアプリケーションは、ビットコイン台帳（Bitcoin ledger）であるが、他のブロックチェーン実装がオファーされ、かつ、開発されてきている。ここにおいては、便宜および説明目的のためにビットコインが参照され得るが、本発明は、ビットコインのブロックチェーンを伴う使用に限定されるものではなく、かつ、代替的なブロックチェーン実装およびプロトコルも本発明の範囲内に在ることに留意すべきである。

本発明は、添付の請求項において定義されるものである。

本発明は、ブロックチェーンを介したアセットのセキュアな制御（control）、及び／又は、移転（transfer）、もしくは交換（exchange）のためのソリューションを提供することができる。ここにおいて、用語「エンティティ（”entity”）」は、「アセット（”asset”）」と互換的に使用されてよい。追加的または代替的に、本発明は、アセットの所有権（ownership）の制御及び／又は移転を可能にし得る。これは、スマートコントラクトといった、デジタルまたは仮想アセット、もしくは、現実世界／物理的なアセットであってよい。アセットは、ライセンスといった権利または使用権、もしくは、あるタイプのプロパティに関するある種の権利であってよい。本発明は、この制御または移転を促進するために、トークナイゼーション技術を使用することができる。本発明は、暗号鍵（cryptographic keys）の使用を組み込んで、移転／交換がセキュアな方法で実行されることを可能にし得る。一方で、根底にあるブロックチェーンプロトコルのあらゆる変更も必要としていない。本発明は、ブロックチェーントランザクション（Tx）に関連するスクリプトの中にメタデータを埋め込むための技術を使用することができる。

本発明は、特に、電子的移転のためのメモリ使用の強化された最適化、ハッシュ技術の使用を通じて改善されたセキュリティおよびデータ完全性、信頼できる第三者の必要性を排除することを通じて改善されたセキュリティ、および、強化されたデータの匿名性、を提供する。本発明は、また、異種または別個の当事者が、本発明によって提供される新規な方法及び／又はアーキテクチャを介して、互いを識別し、かつ／あるいは、データ交換することを可能にする改善された通信メカニズムも提供することができる。この利点のリストは、限定的または網羅的ではない。
本発明は、種々の別個で、かつ、分離したコンピュータベースのリソースに係る相互作用（interaction）および相互通信（inter-communication）を必要とし得る。１つまたはそれ以上のユーザデバイス、および、ブロックチェーン関連のソフトウェアおよびプロトコルを実行するように構成されたコンピューティングノードを含む、分散コンピュータシステム（ブロックチェーン）、といったものである。

本発明は、エンティティの交換を実行するコンピュータ実装方法を提供することができる。交換は、第１ユーザと第２ユーザとの間で行われてよく、コンピュータネットワークを介して行われる交換であってよい。ネットワークは、ブロックチェーン実装のネットワークであってよい。用語「ユーザ（”user”）」は、人間のユーザまたはコンピュータベースのリソースを参照し得る。本発明は、２つまたはそれ以上のエンティティの交換を制御するための交換制御方法を提供することができる。それは、デジタルエンティティの交換のためのトークナイゼーション方法を提供することができる。本発明は、ブロックチェーン実装方法として説明することができる。

本発明は、移転または交換を実行するためのコンピュータで実施される方法を提供することができる。本方法は、以下のステップを含んでよい。第１ネットワークにわたり分散された分散ハッシュテーブル（ＤＨＴ）におけるエントリーをスキャンするステップであり、ＤＨＴは複数のエントリーを含み、各エントリーは交換を実行するためのインビテーションと第２ネットワークにわたり分散されたピアツーピア（Ｐ２Ｐ）分散型台帳におけるトランザクションに対するリンクとを含み、各インビテーションは交換されるエンティティの指示と、交換のための１つまたはそれ以上の条件とを含む、ステップ。第１ユーザからの第１エントリーに係る第１インビテーションにおけるメタデータの第１セットと、第２ユーザからの第２エントリーに係る第２インビテーションにおけるメタデータの第２セットとの間の一致を判断するステップであり、判断は、第１インビテーションおよび第２インビテーションにおいて交換されるエンティティ間の一致を識別すること、および第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別することを含む、ステップ。第１交換トランザクションを生成するステップ。および、Ｐ２Ｐ分散型台帳に包含するために、第１交換トランザクションを第２ネットワークにわたりブロードキャストするステップ、である。ここで、第１交換トランザクションは、移転される仮想通貨の第１量の指示、第１エントリーに対してリンクされたＰ２Ｐ分散型台帳におけるトランザクションの出力から提供される第１入力、第１スクリプト、第１ユーザと関連付けられた第１ユーザの秘密鍵、および第１の第三者と関連付けられた第１の第三者秘密鍵を含む。ここで、第１スクリプトは、メタデータの第１セット、第１ユーザと関連付けられた、第１ユーザの秘密鍵との暗号ペアである第１ユーザの公開鍵、第１の第三者と関連付けられた、第１の第三者秘密鍵との暗号ペアである第１の第三者公開鍵、および、第１ユーザから第２ユーザへの第１エンティティの第１量の移転を指示する第１出力を含む。

追加的または代替的に、本発明は、移転または交換を実行するための方法を含んでよく、ここで、スクリプトのハッシュは、ブロックチェーントランザクション（Ｔｘ）の中で提供されてよく、または、ブロックチェーントランザクションに関連付けられてよい。スクリプトは、引き換えスクリプトであってよい。トランザクション（Ｔｘ）は、ビットコインプロトコルに従ったP2SHトランザクション、または、別のブロックチェーンプロトコルにおける別の機能的に同等なトランザクションタイプであってよい。スクリプトのハッシュは、ハッシュテーブルまたは他のストレージリソースに対するルックアップキーとして機能し得る。このストレージリソースは、インビテーションのパブリックドメインリポジトリであってよい。ストレージリソースは、ルックアップキー（すなわち、ハッシュ）、および、組み合わせて、インビテーションを定義するメタデータからの全てのフィールドを含むことができる。ルックアップキーは、レコードの残りのハッシュ、すなわち連結されたメタデータ値のハッシュであってよい。好ましい実施形態において、メタデータは、トークンと関連付けられたコントラクトのロケーションに対するポインタまたは他の参照を含んでよい。コントラクトは、別個のストレージリソースの中に格納されてよい。インビテーション（ストレージリソースにおけるメタデータによって定義される）は、ハッシュを介してブロックチェーントランザクションに対してリンクされてよい。

好ましくは、本方法は、さらに、第２交換トランザクションを生成するステップと、記Ｐ２Ｐ分散型台帳に包含するために、第２交換トランザクションを第２ネットワークにわたりブロードキャストするステップと、を含む。ここで、第２交換トランザクションは、移転される仮想通貨の第２量の指示、第２エントリーに対してリンクされたＰ２Ｐ分散型台帳におけるトランザクションの出力から提供される第２入力、第２スクリプト、第２ユーザと関連付けられた第２ユーザの秘密鍵、第２の第三者と関連付けられた第２の第三者秘密鍵、および第２ユーザから第１ユーザへの第２エンティティの第２量の移転を指示する第２出力を含む。ここで、第２スクリプトは、メタデータの第２セット、記第２ユーザと関連付けられた、第２ユーザの秘密鍵との暗号ペアである第２ユーザの公開鍵、第２の第三者と関連付けられた、第２の第三者秘密鍵との暗号ペアである第２の第三者公開鍵、および第２ユーザから第１ユーザへの第２エンティティの移転を指示する第２出力を含む。

本発明は、移転を実行するためのコンピュータで実施される方法を提供することができる。本方法は、以下のステップを含んでよい。第１ネットワークにわたり分散された分散ハッシュテーブル（ＤＨＴ）におけるエントリーをスキャンするステップであり、ＤＨＴは複数のエントリーを含み、各エントリーは交換を実行するためのインビテーションと第２ネットワークにわたり分散されたピアツーピア（Ｐ２Ｐ）分散型台帳におけるトランザクションに対するリンクとを含み、各インビテーションは交換されるエンティティの指示と交換のための１つまたはそれ以上の条件とを含む、ステップ。第１ユーザからの第１エントリーに係る第１インビテーションにおけるメタデータの第１セットと第２ユーザからの第２エントリーに係る第２インビテーションにおけるメタデータの第２セットとの間の一致を判断するステップであり、判断は、第１インビテーションおよび第２インビテーションにおいて交換されるエンティティ間の一致を識別すること、および第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別することを含む、ステップ。第１交換トランザクションを生成するステップ。および、Ｐ２Ｐ分散型台帳に包含するために、第１交換トランザクションを第２ネットワークにわたりブロードキャストするステップ、である。ここで、第１交換トランザクションは、移転される仮想通貨の第１量の指示、第１エントリーに対してリンクされたＰ２Ｐ分散型台帳におけるトランザクションの出力から提供される第１入力、第１スクリプト、第１ユーザと関連付けられた第１ユーザの秘密鍵、第１の第三者と関連付けられた第１の第三者秘密鍵、移転される仮想通貨の第２量の指示、第２エントリーに対してリンクされたＰ２Ｐ分散型台帳におけるトランザクションの出力から提供される第２入力、第２スクリプト、第２ユーザと関連付けられた第２ユーザの秘密鍵、および第２の第三者と関連付けられた第２の第三者秘密鍵を含む。ここで、第１スクリプトは、メタデータの第１セットと、第１ユーザと関連付けられた、第１ユーザの秘密鍵との暗号ペアである第１ユーザの公開鍵、第１の第三者と関連付けられた、第１の第三者秘密鍵との暗号ペアである第１の第三者公開鍵、および、第１ユーザから第２ユーザへの第１エンティティの第１量の移転を指示する第１出力、を含む。ここで、第２スクリプトは、メタデータの第２セット、第２ユーザと関連付けられた、第２ユーザの秘密鍵との暗号ペアである第２ユーザの公開鍵、第２の第三者と関連付けられた、第２の第三者秘密鍵との暗号ペアである第２の第三者公開鍵、および第２ユーザから第１ユーザへの第２エンティティの移転を指示する第２出力、を含む。

第１態様および第２態様のいずれにおいても、第１インビテーションおよび第２インビテーションにおいて交換されるエンティティ間の一致を識別するステップは、第１インビテーションにおいて要求されるエンティティと第２インビテーションにおいて提供されるエンティティとの間の一致を識別するステップと、第１インビテーションにおいて提供されるエンティティと第２インビテーションにおいて要求されるエンティティとの間の一致を識別するステップとを含む。

有利なことに、第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別するステップは、第１インビテーションにおいて要求されるエンティティの最大値を指定している第１条件を識別するステップと、第２インビテーションにおいて提供されるエンティティの最小値を指定している第２条件を識別するステップとを含む。

好ましくは、第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別するステップは、さらに、最大値が前記最小値より大きいと判断するステップを含む。

有利なことに、第１エンティティの第１量は、最大値と最小値のうち１つまたは両方に基づいて判断され得る。同様に、第２エンティティの第２量は、最大値と最小値のうち１つまたは両方に基づいて判断され得る。判断は、最大値と最小値の平均に基づくものであってよい。

第１量は、最小値ではなく最大値に基づいて判断され、かつ、第２量は、最大値ではなく最小値に基づいて判断され得る。

いくつかの実施形態において、第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別するステップは、さらに、最大値が最小値より小さいが第１閾値内にあると判断するステップ、第２ユーザに第１インビテーションを通知するステップ、第２ユーザから第１条件の受諾に係る確証を受け取るステップ、および一致を識別するステップ、を含む。

好ましくは、第１インビテーションの１つまたはそれ以上の条件と第２インビテーションの１つまたはそれ以上の条件との間の一致を識別するステップは、さらに、最小値が最大値より小さいが第２閾値内にあると判断するステップ、第１ユーザに前記第２インビテーションを通知するステップ、第１ユーザから第２条件の受諾に係る確証を受け取るステップ、および一致を識別するステップ、を含む。

第１の第三者は、エスクローサービスプロバイダであり、かつ／あるいは、第２の第三者は、エスクローサービスプロバイダである。

いくつかの実施形態において、第１交換トランザクション、第２交換トランザクション、第１インビテーショントランザクション、および第２インビテーショントランザクションのうち１つまたはそれ以上は、ペイツースクリプトハッシュ（Ｐ２ＳＨ）トランザクションである。

いくつかの実施形態において、エンティティのうち１つまたはそれ以上は、ａ）ビットコイン、ｂ）コントラクト、ｃ）商品、ｄ）サービス、のうちの１つである。コントラクトは、ａ）不換通貨、ｂ）不動産権利書、ｃ）チケット、ｄ）商品、ｅ）サービス、のうちの１つまたはそれ以上に対するものである。

条件の第１セット及び／又は条件の第２セットは、ａ）交換に関する１つまたはそれ以上の価格における１つまたはそれ以上の限度範囲、ｂ）交換レート、ｃ）第１インビテーションの遂行に対する締め切り、ｄ）交換を行うための地理的領域における制限、のうち１つまたはそれ以上を含む。

本発明は、上記に従って方法を実行するように動作可能なプロセッサまたはプロセッサのグループを提供し得る。

本発明の実施形態は、（ブロックチェーン）トランザクションの中にメタデータを埋め込むための技術を含むことができ、
アセット（Ｂ１）に関する出力（ＴｘＯ）および引き換えスクリプトのハッシュを有するブロックチェーントランザクション（Ｔｘ）を生成するステップ、を含み、
トークン化されたエンティティの表現、または参照であるトークンを含むメタデータと、
少なくとも１つの（好ましくは２つまたはそれ以上の）公開暗号鍵、を含む。

デジタルアセット（Ｂ１）は、仮想通貨、例えばビットコインの量であってよい。引き換えスクリプトは、トランザクション出力ＴｘＯのロックスクリプトにおいて提供されてよい。メタデータは、暗号鍵のロケーションとしてブロックチェーンプロトコルにおいて指定されたロケーションにおける引き換えスクリプトの中で提供されてよい。このことは、根底にあるブロックチェーンプロトコルに対するあらゆる変更を必要とすることなくメタデータを移転できるという利点を提供する。プロトコルを操作するノードは、暗号鍵の代わりにメタデータの使用について依存しない（agnostic）だろう。

本方法は、さらに、トランザクションＴｘをブロックチェーンに提出するステップを含んでよい。実際には、仮想通貨（Ｂ１）は、従って、トークンに関連してブロックチェーンにおいてロックされてよい。仮想通貨（Ｂ１）の量は、出力ＴｘＯのためのロックスクリプトの要求を満たすロック解除スクリプトの提供の際だけに費やす（引き換える）ことができる。
特には、ハッシュされた場合に、ＴｘＯのロックスクリプトにおいて提供されるハッシュと一致する引き換えスクリプトが提示される必要がある。出力ＴｘＯに対するロックスクリプトは、（メタデータにおいて）トークンを次いで有する引き換えスクリプトのハッシュを含むので、仮想通貨（Ｂ１）はトークンと関連付けされる。正しいロック解除（引き換え）スクリプトが一旦提示されると、仮想通貨（Ｂ１）の所有権は、引き換え当事者またはユーザに対して移転、すなわち、費やされる。

本発明は、上述の任意の方法を実施するように配置され、かつ、構成されたコンピュータ実装システムを提供することができる。１つの態様または実施形態に関連して上述された任意の特徴は、あらゆる他の実施形態または態様に関して使用することができる。本発明の方法に関連して言及されたあらゆる特徴は、対応するインプラント（implanting）システムについて同様に適用することができ、その逆も同様である。

この明細書を通じて、単語「含む（”comprise”）」、もしくは「含む（”comprises”または”comprising”）」といった変形は、記載されたエレメント（element）、インテジャ（integer）、またはステップ、もしくは、エレメント、インテジャ、またはステップのグループを含むことを意味すると理解される。しかし、あらゆる他のエレメント、インテジャ、またはステップ、もしくは、エレメント、インテジャ、またはステップのグループを排除するものはない。

本発明の実施形態が、添付の図面を参照して、非限定的な実施例だけによって、これから説明される
図１は、本発明の一つの実施形態に従った、システムの模式図である。 図２は、図１に係るシステムのユーザによって実行されるプロセスのフローチャートである。 図３は、交換サービスプロバイダによって実行されるプロセスを説明するフローチャートである。 図４は、交換サービスプロバイダによって生成されるインビテーション（invitation）のためのメタデータフォーマットを説明する表である。 図５は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。 図６は、図１に係るシステムの２人またはそれ以上のユーザからのインビテーションを一致させる（matching）プロセスを説明するフローチャートである。 図７は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。 図８は、図１に係るシステムに対する当事者間におけるトランザクションを説明する取引図である。 図９は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。 図１０は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。 図１１Ａは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。 図１１Ｂは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。 図１１Ｃは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。

金融上および非金融上の両方において、日常の取引（day-to-day transactions）に係る恒久的な記録を実行して、保持する、より迅速かつ安価な方法に対する必要性が存在している。本発明は、金融アプリケーションとの使用または利点に限定されなるものではないことに留意することが重要である。代わりに、本発明は、一般的に、ビットコインブロックチェーンといった、P2P分散型台帳を利用するための方法および装置に関し、当事者があらゆるタイプの価値エンティティ（entity of value）を提供し、要求し、そして、交換することを可能にする。ここにおいて説明される方法は、エンティティの交換を実行するためのインビテーション（invitation）（または、オーダー（order））エントリー（entry）を可能にする。インビテーションの受諾（acceptance）について実際の交換に係るエンアクトメント（enactment）も同様である。実施形態は、従って、保持されるべき交換プロセスに係る全てのステップの恒久的な記録を提供する。さらに、プロセスにおける各段階（オファー、受諾、および交換）は、仮想通貨のトランザクションにおいて使用されるものと同様な暗号化ロック技術（locking techniques）を使用してセキュアにすることができる。ここにおいて説明される方法は、また、あらゆるタイプのエンティティを交換するために使用することもできる。そうしたエンティティの実施例は、これらに限定されるわけではないが、ビットコイン、不換通貨（fiat currencies）、コントラクト、商品（goods）、およびサービスを含んでいる。「仮想通貨（”cryptocurrency”）」により、これに限定されるわけではないが、ビットコインといった、暗号化された電子的に移転可能なデジタルアセットを意味している。
ブロックチェーン技術の使用を取り込んでいるCoinffeine（http://www.coinffeine.com/）といった交換が、当技術分野で知られている。しかしながら、そうした従来技術の構成（arrangement）は、未だに従来のモデルに依拠しており、そして、また、動作するために、第三者ソース、エスクロー（escrows）、および、他のマルチ通貨非銀行口座／プロセッサにも依拠している。これらの既知の構成は、（本発明による）技術革新および暗号技術を通じてではなく、むしろ、ビジネスモデルを通じて分散化（decentalisation）を達成している。

本発明は、トークナイゼーション技術（tokenisation techniques）の使用を組み込んでいる。コントラクトは、トークン（tokens）によるシステムを使用して交換することができる。まとめると、トークンは、契約を表す交換可能なエンティティである。コントラクトは、いくつかの形式のうち１つをとることができる。例えば、コントラクトは、保有者に権利を授与し、または、財産の所有権を示すことができる。トークンの値は、契約上で特定されてよく、そして、「ペッグ率（”pegging rate”）」を介して根底にあるBTC量に対してリンクされる。トークンは、ビットコインプロトコルといった仮想通貨プロトコルを使用する新規なタイプのトランザクションを介して交換可能である。トランザクションにおけるビットコイン値は、デジタル形式において権利契約（a rights contract）を表しているトークンとして動作する。契約自体は、ブロックチェーン上に保管されてよく、または、公にアクセス可能なオフブロックのロケーションに保存されてよく、もしくは、特定の実施形態に応じて、契約に対する当事者によって個人的に保持されてよい。契約がブロックチェーン上に保管されていない場合に、ブロックチェーントランザクション（Tx）は、一意の（unique）ポインタ、識別子、または契約に対する他の参照を保管することができる。

トークンは、分割可能（divisible）であり得る。分割可能なトークンとは、トランザクション出力における値をより小さい量へと細分化することができるものであり、値は複数の新たなトークンにわたり割り当てることができる。分割可能なトークンの実施例は、不換通貨のためのトークン、または、競走馬におけるシェア（shares）のためのトークンを含んでいる。分割可能なコントラクトは、非ゼロ（non-zero）ペッグ率を特定するものとして定義され得る。別の言葉で言えば、トークン値は、根底にあるビットコイン値に対して結び付けられている。代替的に、トークンは、分割不可能（non- divisible）であってよい。分割不可能なトークンは、保有者の権利を固定値において特定するコントラクトであり、例えば、家または豪州ドル＄１０００を引き換えるためのコントラクトである。分割不可能なトークンは、従って、根底にあるビットコインの値に対してリンクされていない。分割不可能であるため、それらは全体としてだけ移転することができる。

トークンは、有効であるようにトークン発行者によってデジタル署名（digitally signed）され得る。発行者は、例えば、不動産権利の登記局（Registrar of Title deeds）といった機関であってよい。発行者は、支払いの見返りにトークンをユーザに対して発行することができる。そのトークンは、次いで、コントラクトが、不換通貨を引き換える権利であるか、またはサービスを実行させる権利であるか、もしくは財産（つまり、権利証書）の移転であるかにかかわらず、トークンに対してリンクされたコントラクトを行使する権利をユーザに与えることができる。

上記に従ったトークンの実施は、以下のものを含んでいる。
・コントラクトの発行者によるトランザクション出力のBTC値に対してペッグされた（pegged）不換通貨トークン（fiat currency token）。例えば、「このトークン（ビットコイントランザクション）の支払人（spender）は、１０００サトシ（satoshis）毎に１シェア（１０セント）のレートでカナダドル（CAD）のこのトークンの任意の一部を引き換える（redeem）権利がある」。
・シンジケートの複数のメンバーによって所有されている競走馬。
・所有権が権利証書（a title deed）によるものである任意のアイテム。例えば、家または他の財産がこのようにして取り扱うことができるだろう。
・コンサートチケットを表す電子契約。これは本質的に分割不可能である。
・無記名債券（bearer bond）（分割不可能）
・商品／サービスに添付されている一意の識別子（バーコードまたはRFIDといったもの）。使用される場合に、この識別子は未だに好ましくは承認されたエンティティの署名によって有効にされる。署名がないと、より安全性が低い「商品／サービス（”goods/service”）」カテゴリへと分類される（以降に説明される）。
・実行されるべきサービスに対する権利についての契約。これは、実際のサービス自体と同じものではなく、自分のために実行されるサービスを受ける権利だけであることに留意する。この権利は取引することができる。たとえば、シドニーの首都圏内で３時間までの芝生刈りについてマイケルマウイング（Michael's Mowing）からのクーポン券（voucher）。このクーポン券（契約書）の保有者は、クーポン券を実際のサービスについて引き換えることができる。

トークンは、シェア（share）の価値を指定する必要がある。例えば、１シェア＝１０セントCAD、１シェア＝１ルピア（rupia）、または、１シェア＝アイテムまたはプロパティ（競走馬、家、等）である。

以下に説明される実施形態は、ビットコインブロックチェーン（または、単純にブロックチェーン）におけるトランザクションを記録することについて特定的に参照することができるが、本発明は、任意のP2P分散台帳を使用して実装され得ることが正しく理解されよう。以下で、ブロックチェーンは、標準化のレベルが高いこと、および、関連する公的な文書化が大量であることだけによる簡潔性（simplicity）について本発明の態様を説明するために使用される。

当技術分野においてよく知られているように、ブロックチェーンは、ビットコインプロトコルに基づくシステムに参加しているネットワーク化されたノードにわたり分散されたトランザクション台帳またはデータベースである。通貨のブロックチェーンの完全コピーは、これまで通貨において実行された全てのトランザクションを含んでいる。従って、トランザクションのデータレコードに係る継続的に増加するリストが提供される。ブロックチェーン上に入力された各トランザクションは暗号化されて実施されるので、データストアノードのオペレータによってさえも、改ざん（tampering）および改訂（revision）に対してブロックチェーンが強化されている。

一方の当事者（one party）から別の当事者へビットコイン（または、他の仮想通貨）の支払いを表すトランザクションのレコードを保管することに係るデザインされた機能において使用されることの代わりに、または、加えて、ブロックチェーンは、当事者間におけるエンティティまたはアセットの移転を可能にする新規な方法で使用されている。交換（exchange）は、一方の当事者から別の当事者へデジタルエンティティの制御及び／又は所有権を移転する。これを達成するために、本発明は、１つまたはそれ以上のエンティティに係る交換を実行するためのインビテーション（または、オーダー）を保持および記録するためのメカニズムを提供する。本発明は、従って、ブロックチェーンを介して導かれる新規で有利な通信ソリューションを提供する。

上述のように、任意のタイプのエンティティまたはアセットが交換可能である。これらは、物理的な、「現実世界（”real world”）」エンティティ、または、仮想的な、デジタルエンティティであってよい。交換することができるエンティティの実施例は、ビットコイン、トークン（任意のタイプの移転可能なコントラクトを表している）、および、任意のタイプの商品とサービスを含んでいる。トークンは、特定の権利を保有者に授与する契約を表すことができる。多くの例のうちのいくつかを挙げると、不換通貨（仮想銀行紙幣）について引き換えられるため、プロパティの所有権（例えば、権利証書）を示し、または、イベントに対するアクセスを認めるための権利である。商品とサービスは、多くの例のうちのいくつかを挙げると、新品または中古の製品、労働（例えば、時間によって請求されるもの）、完全な仕事（例えば、芝生の芝刈り）を含んでよい。

図１は、一つの実施形態に従った、P2P交換システム100のネットワーク図である。システム100は、ネットワーク102およびネットワークに対する複数の当事者を含んでいる。当事者は、交換サービスプロバイダ104、第１ユーザ106、第２ユーザ108、エスクローサービスプロバイダ（an escrow service provider）110、および、発行者112を含んでいる。より詳細に以下に説明するように、交換サービスプロバイダ104、エスクローサービスプロバイダ110、および発行者112の機能の組み合わせは、単一の当事者によって引き受けることができる。別の言葉で言えば、単一の当事者がそれぞれの機能を同時に実行することができる。加えて、そして、より詳細に以下に説明するように、交換サービスプロバイダ104およびエスクローサービスプロバイダ110は、これらのサービスプロバイダ104、110を使用することなくP2P交換システム上で完全に実行できるので、任意的である。

交換サービスプロバイダ104は、第１ユーザ106および第２ユーザ108を含む、複数のユーザに交換サービスを提供する。発行者112は、破線によって示されるように、ネットワーク102に対して任意的である。より詳細に以下に説明するように、発行者112は、トークンの交換が関与する場合にだけ必要とされるものである。

いくつかの実施形態において、ネットワーク102はインターネットである。従って、他の当事者（図示なし）がネットワーク102に対する当事者であってよい。ネットワーク102に対する全ての当事者は、ネットワーク102に対する他の全ての当事者と通信することができる。ネットワーク102上でホストされているのは、ピアツーピア分散ハッシュテーブル（P2P DHT）とピアツーピア分散型台帳（P2P DL）である。システム100において示されている当事者のいくつか又は全ては、図示されていないものと一緒に、P2P DHTおよびP2P DLの両方またはいずれかに対するホストノードとして動作し得ることが正しく理解されよう。

インビテーションの構造
インビテーションは、様々なパラメータまたはコードを含むように構成されてよい。これらは、様々な目的のために使用することができる。例えば、より詳細に以下に説明されるような、インビテーションのマッチング（matching）である。１つまたはそれ以上の実施形態においては、以下の構造を使用することができる。

交換サービスプロバイダ104の１つの目的は、P2P DHTとP2P DLの両方においてインビテーション（またはオーダー）を置く（place）ためにユーザ106、108のためのゲートウェイを提供することである。ネットワーク102のユーザ106、108は、それ自体、P2P DHTとP2P DLの両方にインビテーションを置くことができるが、交換サービスプロバイダ104は、簡素化されたインターフェイスを提供し、インビテーションが生成される効率を改善し、かつ、当業者であれば理解するように、ビットコイン台帳といった、分散型台帳におけるトランザクションの直接的な取り扱いに関連する危険を低減する（例えば、トランザクションの喪失、等）。P2P DHTとP2P DLにおけるユーザインビテーションの発行を可能にすることに加えて、交換サービスプロバイダは、以下の追加サービスのうち１つまたはそれ以上を実行することができる。
・インビテーションのマッチング（Matching invitations）－ 上述のように、インビテーションは、ａ）ユーザが交換することを望むエンティティの詳細、ｂ）交換に添付された１つまたはそれ以上のユーザ適用オプション／条件、を含んでよい。２つのインビテーションは、それぞれのエンティティの詳細がミラーリングされており（mirrored）、かつ、２つのインビテーションの条件のうち１つまたはそれ以上が適合する場合に、一致し得る。別の言葉で言えば、第１インビテーションの中に含まれる一つまたはそれ以上のパラメータまたは特徴が、また、第２インビテーションの中にも含まれている場合に、一致が生じ得るし、その逆もまた同様である。インビテーションの所定の態様間においてはペアリング（pairing）または共通性が存在している。これらのパラメータは、交換が実行されるために一致について不可欠なものとして事前に指定されている。
ミラーリングされたエンティティの詳細の例は、第１ユーザ（アリス（Alice））がリンゴのためにビットコインを提供し、かつ、第２ユーザ（ボブ（Bob））がビットコインのためにリンゴを提供する場合である。サービスプロバイダは、従って、交換に適応する（accommodate）ために、コンパチブルなインビテーションを合致するマッチングサービスを提供することができる。マッチングは、一致するエンティティ及び／又は条件を有する１つまたはそれ以上のインビテーションについてP2P DHTをスキャンすることを含んでよい。いくつかの実施形態において、サービスプロバイダ104は、ユーザからの要求に応じてP2P DHTをスキャンすることができる。例えば、ユーザは、サービスプロバイダ104に対して所望のインビテーションのための１つまたはそれ以上のクライテリア（criteria）を提供することができる。提供されたクライテリアに基づいて、サービスプロバイダ104は、次いで、それらのクライテリアに一致する、既にP2P DHT上に置かれているインビテーションを検索することができる。他の実施形態において、サービスプロバイダ104は、特定のユーザ要求に関係しない、一致またはほぼ一致するインビテーションについてP2P DHTを検索する、非特定的なペアリングアルゴリズム（non-specific pairing algorithm）を実装することができる。マッチングサービスは、他の第三者プロバイダによって提供されてよいことが正しく理解されよう。１つまたはそれ以上の第三者プロバイダが存在してよく、その主な目的は、上記に従ってマッチングサービスを提供し、以下に説明されるように、同様にマッチングアラートを提供することである。いくつかの実施形態において、マッチングはマッチングサービスプロバイダ（MSP）によって提供される。
１つまたはそれ以上の実施形態に従って、かつ、また上記の「インビテーションの構造」セクションに示されるテーブルを参照して、以下のようなＡとＢとの間でインビテーションのマッチングからマッチングアルゴリズムを採用することができる。

ＡのOffer-type-codeは、ＢのRequest-type-codeと一致することを要する
ＡのRequest-type-codeは、ＢのOffer-type-codeと一致することを要する
ＡのRate-min ≦ ＢのRate-max（同等の単位で表される場合）
ＡのRate-max ≧ＢのRate-min（同等の単位で表される場合）
Request-item-IDは、Offer-Item-IDと一致することを要する
ＡのRequest-QTY-min ≦ ＢのOffer-QTY-max
ＡのRequest-QTY-max ≧ ＢのOffer-QTY-min
Ａの条件は（もしあれば）、Ｂのインビテーションと適合することを要する
Ｂの条件は（もしあれば）、Ａのインビテーションと適合することを要する

本発明は、このアルゴリズムまたはその変形を実施するマシンで実行可能なルールを組み込むように構成することができる。

・アラートの一致（Match alerts）－ 一致またはほぼ一致が検出された場合に、交換サービスプロバイダ104は、電子メールによる、もしくは、電話またはタブレットアプリケーションを介するといった、既知の方法でユーザにアラートする（alert）ことができる。従って、本発明は、新規な通信またはアラートメカニズムを提供することができる。
・一致に基づく新たなインビテーション生成（Generating new invitation based on matches）－ ユーザが、置きたいと望むインビテーションまたはオーダーの詳細を提供する場合に、サービスプロバイダ104は、ユーザのオーダーの条件を満足する１つまたはそれ以上のインビテーションについてP2P DHTをスキャンすることができる。次いで、P2P DHTにおいてインビテーションのマッチングが見つかった場合に、サービスプロバイダ104は、成功した一致を促進するために、既にP2P DHT上にある識別されたインビテーションをミラーリングするインビテーションを生成することができる。P2P DL上で最終トランザクションを完了するためには、トランザクションに対する全ての当事者は、P2P DLで既に公開されているインビテーションを有する必要があることに留意する。しかしながら、全てのインビテーションがP2P DHTにおいて公開されることを要するとは限らない。この実施例において、例えば、サービスプロバイダは、インビテーションが広告される（advertised）必要が存在しないので（所望の一致が既に見つかっている）、P2P DHT上でオファーを公開する必要はない。しかしながら、例えば、最初のマッチングが失敗に終わる場合に、生成されたインビテーションは、未だにP2P DHT上に置かれてよいことが正しく理解されよう。

・トランザクションの実行（Executing transactions）－ インビテーションのペアが成功裡に一致した後で、サービスプロバイダ104は、最終トランザクションを実施するためのプロキシとして動作することができる。例えば、２つのインビテーションが一致するという判断において、サービスプロバイダ104は、実際のトランザクション、すなわち、エンティティの交換を含むトランザクションを、P2P分散型台帳に記録することができる。このプロセスは、当事者が承認を表すことなく、または、トランザクションを承認するために一人またはそれ以上の当事者を促した後で、自動的に行われてよい。
いくつかの実施形態では、インビテーションの中のメタデータは、交換が確定される前に当事者が通知されることを要するか否かを示すことができる。

・ｅウォレットサービス（eWallet services）－ 上記に加えて、サービスプロバイダ104は、また、仮想通貨の鍵、等の保持といった、従来のｅウォレットサービスを提供することもできる。

図１のシステム１００においては、単一のサービスプロバイダ104が示されている。しかしながら、１つまたはそれ以上の追加の交換サービスプロバイダがネットワーク102に対する当事者であってよいことが正しく理解されよう。１つ以上の交換サービスプロバイダが存在する場合に、ユーザは、例えば、サービスプロバイダの料金体系、ロケーション、互換性、等を含み得る、それらの要求に応じて交換サービスプロバイダを選択することができる。従って、所定の状況においては、一致するインビテーションを持つ２人のユーザが、異なる交換サービスプロバイダを使用してよいことが正しく理解されよう。そうした状況において、ユーザのそれぞれの交換サービスプロバイダは、交換を促進するために相互間で通信することができる。

交換サービスプロバイダ104に加えて、エスクローサービスプロバイダ110（または、略してエスクロー）が、ネットワーク102における当事者であってよい。エスクローサービスプロバイダ110は、取引が決済されるまでユーザのオファーを保持すること（すなわち、提供された金額が留保されている）、または、所定の条件下において、オーダーをキャンセルし、かつ、インビテーションにおいて提供されたものを何でも返却すること、を可能にする。エスクローサービスプロバイダ110は、トランザクションについてエスクローサービスを提供するために、トランザクションの２人の当事者によって信頼される、中立的な第三者として機能する。従って、システムにより、ユーザは、最終トランザクションに参加することができ、オファーを行うユーザが、提供された金額を（ビットコインまたはトークンで）を満足できるという保証を有することができる。

交換サービスプロバイダと同様に、１つ以上のエスクローがネットワーク104に対する当事者であってよい。P2P交換システム100のユーザは、また、１つのエスクロープロバイダを使用する場合に、どのエスクロープロバイダを使用するか選択することもできる。いくつかの実施形態において、エスクロー110のサービスは、交換サービスプロバイダ104のサービスの中に組み込まれてよく、または、その逆も同様である。そうした場合には、別個のエスクローが必要とされないことがある。

上記に加えて、システム100は、また、発行者112も含んでよい。発行者112は、トランザクションがトークンの交換を含む場合に、関与することができる。そうした状況において、プロセスは、トークンに署名する発行者を取り込んでいる。トークンの移転を取り込んでいるそれぞれのトランザクションは、好ましくは、発行者112を含んでいる。ここにおいて説明される実施形態において、発行者の署名は、インビテーショントランザクションにおいて要求され、そこではトークンが提供されて、エスクローにおいて保持される。発行者の署名は、また、交換トランザクションにおいても要求され、そこでは相手方（counterparty）に対してトークンの支払いが行われる。

本開示の実施形態の重要な態様は、ビットコイン交換トランザクション（または、仮想通貨トランザクション）において交換を実行するためのインビテーションに関するメタデータを埋め込むための能力（ability）であり、同様に、ビットコインまたは他の仮想通貨トランザクションにおいて、実際の交換に関するメタデータを埋め込むための能力である。ここにおいて説明される実施形態は、以下に説明するように、そうしたメタデータの埋め込みを可能にするために、マルチシグネチャ（multi-signature）ペイツースクリプトハッシュ（pay to script hash、P2SH）タイプのトランザクションを使用する。

（ｉ）一般的なP2SHにおける引き換えスクリプト（Redeem script in P2SH in general）
背景として、ビットコインプロトコルの標準的なペイツースクリプトハッシュ方法において、引き換えスクリプトは以下の形式をとる：
<NumSigs PubK1 PubK2 ... PubK15 NumKeys OP_CHECKMULTISIG>
ここで、
NumSigsは、トランザクションをロック解除するための引き換えスクリプトを満足するために要求される有効な署名の数「m」である。
PubK1、PubK2、・・・、PubK15は、トランザクションをロック解除する署名に対応する公開鍵（public keys）である（最大１５個までの公開鍵）。
NumKeysは、公開鍵の数「n」である"（１５個以下でなければならない）。

上記の引き換えスクリプトを償還するためには、公開鍵に対応する少なくとも「m」個の署名が必要とされる。いくつかの実施においては、公開鍵の順序が重要であり、そして、署名（signing）のための「n」個の署名のうち「m」個の署名が、順番に行われなければならない。例えば、「m」が２であり、公開鍵の数「n」が１５であるとする。２個の署名が使用のために利用可能であるとすると、例えばSig1（PubK1に対応しているもの）とSig15（PubK15に対応しているもの）、引き換えスクリプトは、最初にSig1によって署名され、その後でSig15によって署名されなければならない。

（ｉｉ）P2SHにおけるメタデータの埋め込み（Embedding metadata in P2SHl）
本発明者は、引き換えスクリプトにおいて公開鍵のために利用可能な１５か所のうち１つまたはそれ以上において、メタデータがP2SHの中に埋め込まれ得ることを認識した。

例えば、P2SHは以下の形式をとる：
<NumSigs Metadata1 Metadata2 ... PubK1 PubK2 ... NumKeys OP_CHECKMULTISIG>
ここで、
NumSigsは、トランザクションをロック解除するための引き換えスクリプトを満足するために要求される有効な署名の数「m」である。
Metadata1とMetadata2は、それぞれ、公開鍵に代わるメタデータを含んでいる。
PubK1とPubK2は、実際の公開鍵である。そして、
NumKeysは、メタデータと公開鍵（１５個以下でなければならない）によって取られる位置の総数である。

引き換えスクリプトの中に、インビテーションの条件、トークンに関連するコントラクトの詳細、及び／又は、交換に関連する他の情報に対応するメタデータを置くことによって、そうした情報のハッシュは、P2P分散型台帳の中に含まれる。この埋め込み方法は、次のように要約できる。
仮想通貨の一部に関する出力（TxO）および引き換えスクリプトのハッシュを有するブロックチェーントランザクション（Tx）を生成することであり、Txは、
トークン化されたエンティティの表現、または参照である、トークンを含むメタデータ、および、
少なくとも１つ（好ましくは２つまたはそれ以上の）公開暗号鍵、を含む。

トークン化されたエンティティは、交換に関するコントラクト及び／又は他のエンティティとすることができる。メタデータは、暗号鍵のためのプロトコルによって指定されたロケーションにおいて提供される。

このように、本発明の実施形態におけるマルチシグネチャP2SHビットコイントランザクションの使用は、いくつかの利点を提供する。第１に、それは、インビテーショントランザクションがメタデータペイロードを運ぶ（carry）ことを可能にする。第２に、それは、交換トランザクションにおけるエスクローサービスの利用を促進する。第３に、交換においてトークンが移転されるロケーションで、それにより、交換トランザクションは、交換される１つまたはそれ以上のトークンに関するメタデータを運ぶことができる。また、根底にあるブロックチェーンプロトコルは、メタデータがトランザクションを介して送付されているという事実には関わらない（agnostic）。従って、この情報を伝達するためにブロックチェーンプロトコルに対する変更は必要とされない。

メタデータは、インビテーショントランザクションにおいてオファー（offer）またはリクエスト（request）を記述している記載またはキーワードを含んでよい。メタデータは、また、インビテーションに関する条件も含んでよい。例えば、インビテーションに締め切り日付を添付することができる。締め切りは、それまでにオーダーが遂行されねばならない時間及び／又は日付を指定することができる。インビテーショントランザクションを用いて締め切り条件が提供される場合には、同じBTC量を費やし、かつ、交換が行われる締め切りを表すロック時間（locktime）を含んでいる、取り消し（cancellation）トランザクションが生成されてよい。取り消しトランザクションは、ロックタイムまでP2P DL上に配信されることを防ぐことができる。締め切りまでに交換が行われない場合には、取り消しトランザクションがP2P DLに対して追加され、そして、支払人（payer）及び／又はサービスプロバイダに効果的に払い戻される。締め切りが終了する以前に交換が行われた場合に、交換トランザクションはその量（amount）を費やし、時間ロックされた取り消しトランザクションに先立ってP2P DLにヒットする二重支払い（double-spend）を創出し、それにより、取り消しトランザクションをブロックしている。いくつかの実施形態においては、メタデータは、締め切りを含まなくてよいが、その代わりに、取り消しトランザクションは、元のインビテーショントランザクションを取り消すことについて単に責任を負うことができる。代替的に、締め切りメタデータ条件は、取り消しトランザクションの支払い（spending）を自動的に引き起こさなくてよい。別の言葉で言えば、締め切りは支払人の管理下に残る柔軟な締め切りであってよい。この締め切りは、従って、単にそれが失効することを許可し、かつ、遅れて一致するインビテーションを依然として受け入れる当事者によって拡張されてよい。同様に、サービスプロバイダは、未使用のままである場合に、期限切れのオーダーとの照合を依然として試みてよい。

インビテーショントランザクションを置く（placing）のと同時に取り消しトランザクションをロックする代わりに、ユーザは、締め切りの後まで待つことができ、そして、そう望む場合には、取り消しトランザクションを手動で入力することができる。

条件は、また、例えば、トランザクションブロードキャストのロケーションが指定された座標のＸメートル以内にある場合には、トランザクションがP2P DL上にだけブロードキャストされること、を指定することができる１つまたはそれ以上のロケーション条件（location conditions）を含むこともできる。このことは、トランザクションが指定されたロケーション、例えば、ボブのコーヒーショップ、でだけ行われることを保証する。

ユーザが自分の新しい条件を作成し、そして、以前に使用されていない条件コードにそれらに割り当てることによって、条件のリストにそれらを追加することを可能にするファシリティ（facility）が存在し得る。このファシリティは、乱用に抵抗することができる。例えば、各サービスプロバイダは、単に関連する条件コードと一緒に条件の独自のテーブルを公開することができ、そして、システム100の他の当事者は、同じコーディングを採用することを選択することができ、かつ、また、それ自身の新しいコーディングを追加することもできる。次いで、例えば、条件コードの再使用のせいで紛争が発生した場合に、紛争は、サービスプロバイダまたはシステム100の他のユーザによって解決され得るものである。

本発明の実施に係るいくつかの例が、第１ユーザ106（ここにおいてはアリス（Allice）と呼ばれる）と第２ユーザ（ここにおいてはボブ（Bob）と呼ばれる）との間のトランザクションの例としてこれから説明される。この例において、トランザクションは、ビットコインについてトークン化されたカナダドルの交換である。

インビテーションを知らせること（Posting an invitation）

第１実施例において、アリスは、ビットコインについてトークン化されたカナダドル（CAD）をいくらか購入したい。彼女の関心を広告するために、アリスは、例えば、ウェブインターフェイス、もしくは、タブレットまたは携帯電話上で動作するアップ（app）を介して、交換サービスプロバイダ104にコンタクトする。図２に示されるように、ステップ２０２において、アリスは、サービスプロバイダ104のウェブインターフェイスへとログインする。ステップ２０４と２０６において、アリスは、次いで、彼女のインビテーションの詳細をサービスプロバイダに対して送付する。交換されるエンティティ（ビットコインについてトークン化されたCAD）と交換の条件、およびサービスプロバイダによって提供される任意の選択されたオプションを含むものである。アリスは、例えば、有効なインビテーションへとサービスプロバイダ104によって次いで翻訳され得る通常の言語を使用して、サービスプロバイダ104によってホストされているインターフェイスの中へこの情報を入力することができ、または、代替的に、アリスは、事前選択オプション（pre-selecting options）例えば、ドロップダウン選択メニューを介して、簡単に情報を入力することができる。

ステップ２０８において、アリスは、彼女の選択に基づいてサービスプロバイダ104によって生成され、かつ、アリスが交換したいと望むエンティティに関する情報およびインビテーションに関する任意の条件を含む、引き換えスクリプト（redeem script）をサービスプロバイダ104から受け取る。アリスは特定のサービスプロバイダ104を使用するように契約（signed up）しているので、サービスプロバイダ104は、既にアリスの公開鍵（public key）を持ち得る。代替的に、アリスは、最初の選択の最中か、または、サービスプロバイダ104からの要求に応じてかのいずれかで、サービスプロバイダ104に対して彼女の公開鍵を提供することができる。

アリスは、ステップ２１０において、彼女の公開鍵に対する暗号ペア（cryptographic pair）である、彼女の秘密鍵を使用して引き換えスクリプトに署名し、そして、ステップ２１２において、配布されるように、署名された引き換えスクリプトをサービスプロバイダ104へ送り返す。このプロセスは、それ自体がサービスプロバイダ104によって提供され得る、アップの使用によってサポートされてよい。

図３に示されるフローチャート300は、サービスプロバイダ104によって実行される対応するプロセスを説明している。ステップ３０２において、サービスプロバイダ104は、アリスからのインビテーションの詳細を受け取り、そして、ステップ３０４において、アリスの公開鍵、エンティティの詳細、およびインビテーションの条件を使用して、引き換えスクリプトを生成する。引き換えスクリプトは、P2SHビットコイントランザクションについて適したフォーマットであってよい。インビテーションの詳細は、マルチシグロック解除スクリプト（multisig unlocking script）において通常使用されている３２バイトの公開鍵の代わりに（in place of）、メタデータフィールドにおいて保管されてよい。図４は、一つの実施形態に従って、アリスのインビテーションについてメタデータのフォーマットを示している。インビテーションにおいて、アリスは、トークン化されたCADを要求し、そして、見返りに、４００CAD／ビットコイン以上のレートでビットコインを提供する。より詳細に以下に説明するように、図４は、また、インビテーションに対して追加することができる締め切り条件（deadline condition）も示している。締め切り条件は、インビテーションに基づいて、交換が確定されていない場合に締め切りにおいてインビテーションが取り消されるようにすることができる。

引き換えスクリプトは、次いで、署名のためにアリスへ送付される。アリスから署名された引き換えスクリプトを受け取ると、ステップ３０８において、サービスプロバイダ104は、署名された引き換えスクリプトのハッシュを生成する。いくつかの実施形態において、サービスプロバイダは、アリスの秘密鍵のコピーを保持することができる（そうすることが許可されている場合）。この場合に、引き換えスクリプトは物理的にアリスに対して送付されなくてよい。代わりに、アリスは、進行することを彼女が望むかどうか確認するように訊かれてよく、そして、アリスからの承認を受け取ると、サービスプロバイダ104は、次いで、アリスに代わって引き換えスクリプトに署名することができる。追加的または代替的に、アリスの秘密鍵は、サービスプロバイダ104によって保管されなくてよいが、必要とされる場合、かつ、アリスにより承認された場合には、再作成されてよい。

サービスプロバイダ104は、２つの方法でハッシュを使用する。第１に、ステップ３１０において、サービスプロバイダ104は、公に利用可能なP2P DHTにおけるハッシュと共にインビテーションの詳細をリストする。上述のように、この表はトレント技術（torrent technique）を採用しているので、集中化されるのではなく、むしろ分散されており、そして、従って、公にアクセス可能なままであり、かつ、偽和（adulteration）から安全である。他のサービスプロバイダ104は、次いで、インビテーションにアクセスし、そして、彼ら自身のサイトにおいてリストすることができる（実際には、サービスプロバイダ104は、単にハッシュテーブルを唯一のリポジトリとして使用し、そして、インビテーションに係る自身のローカルデータベースを維持する必要さえない。）

ハッシュが使用される第２の方法は、ステップ３１２において、ビットコイントランザクションのロッキングスクリプト（locking script）を作成することである。このトランザクションは、ロック解除するために２つの署名を必要とするP2SHスクリプトに対してアリスのビットコインのある量を費やす。アリスの署名、および、指定されたエスクローサービスプロバイダ110（上述のように、サービスプロバイダ104と同じエンティティであっても、なくてもよい）の署名である。このトランザクションの目的は、二重（twofold）である。第１に、インビテーションがP2P DL上に記録される（logged）。任意のユーザまたはそのサービスプロバイダは、（一致するハッシュ値を介して）P2P DL上に一致するトランザクションが存在することを保証することによって、P2P DHT上のインビテーションが正当（legitimate）であることを確認することができる。第２に、トランザクションは、アリスがインビテーションにおいて成したコミットメントを「ロック（”lock”）」する。トークン化されたCADの交換においてアリスが提供するビットコインの量は、オーダートランザクションによって費やされる量である。従って、オーダーは十分な資金（funds）によって裏付けされていることを確認することができる。

一致するインビテーションのペアリング（Pairing matching invitations）

第２の実施例において、ボブは、彼のBTCについてトークン化されたCADのいくらかを売りたい、そして、アリスによって使用されておりサービスプロバイダ104と同じか又は異なるサービスプロバイダのいずれかを使用して、彼自身のインビテーションを独立的にリストしている。ボブのオーダーも、図２および図３を参照して説明したように、ハッシュテーブルにおいてリストされ、そして、P2P DLトランザクションの中に埋め込まれている。ボブのインビテーションのメタデータが、図５において示されている。

図６を参照すると、アリスとボブのオーダーをマッチングするプロセス400が説明されている。この例において、サービスプロバイダ104が、そのプロセスを実行するものとして説明されている。しかしながら、任意の交換サービスプロバイダ、または、実際には、他の任意の適切な第三者が、プロセス400を実行し得ることが正しく理解されよう。

交換サービスプロバイダ104は、アリスとボブのインビテーション間における完全な一致または部分的な一致を識別するように動作可能なマッチングアルゴリズムを実行することができる。ステップ４０２において、交換サービスプロバイダ104は、エンティティの詳細をマッチングするために、P2P DHTをスキャンする。スキャンの最中に、サービスプロバイダ104は、アリスとボブのインビテーションに係るエンティティの詳細の間における一致をチェックする。ステップ４０４において一致が見つからない場合に、次いで、プロセスは、ステップ４０２まで戻り、そして、交換サービスプロバイダ104は、エンティティの詳細のマッチングのためにP2P DHTをスキャンし続ける。ステップ４０４において一致が見つかった場合、プロセス400は、ステップ４０６を続けて、アリスとボブのインビテーションそれぞれの１つまたはそれ以上の条件の間における一致についてチェックが行われる。ステップ４０６で一致が見つからない場合に、プロセスはステップ４０２へ戻る。１つまたはそれ以上の条件の間における一致が見つかった場合に、次いで、プロセスはステップ４０８へ移動し、そこで、交換サービスプロバイダ104は、アリスとボブとの間のトランザクションを作成し、そして、確定するように試みる。

ポジティブな一致（positive matching）が確認されるためには、ステップ４０６において、２つのインビテーションにおける全ての条件の直接的な一致が要求されなくてよい。実際に、プロセス400は、条件のいくつかが一致することを要求するだけであってよい。追加的または代替的に、１つまたはそれ以上の条件が完全に一致する必要はない。例えば、比較されている条件が各条件においてオファーされる交換レートである場合に、プロセス400は、レートが互いに既定の閾値範囲内にあれば、ポジティブな一致を確認することができる。例えば、アリスが４×１０^－５トークン化CAD／サトシ（tokenised CAD/satoshi）の最小レート条件をオファーしており、かつ、ボブの同等な最大オファーレートが３．９×１０^－５トークン化CAD／サトシである場合には、ボブの提示レートがアリスのオリジナルの要件を十分に満たすものではないとしても、プロセスは、それでも条件の一致を確認し、または提示し得る。そうした状況においては、一致に際して、アリスには受け入れるためのオプションが与えられてよい。ボブの同等な最大オファーレートが４．１×１０^－５トークン化CAD／サトシである場合には、条件が満足されることが正しく理解されよう。別の例において、条件は、オファーおよび要求においてオファーされる商品およびサービスに対するそれぞれの値であってよい。プロセス400は、２つの値が互いに既定の閾値範囲内にあれば、ポジティブな一致を再び確認することができる。いずれの場合にも、既定の閾値範囲は、例えば、オファー値または要求値に係る計数値（discrete value）またはパーセンテージであってよい。いくつかの実施形態においては、近い一致（close match）を許可するか又は許可しなかいずれかに設定され得る条件が存在してよい。すなわち、アリスとボブのそれぞれのオファーの間で直接的な一致が存在しない場合である。同様に、厳密にはオファーされた範囲内に存在しないカウンターオファーを許可するか又は許可しなかいずれかに設定され得る条件が存在してよい。

前述のように、ボブとアリスのインビテーションそれぞれ又は両方のトランザクションメタデータは、さらに、１つまたはそれ以上のロケーション条件を含んでよく、例えば、トランザクションブロードキャスト（transactional broadcast）のロケーションが指定された座標のＸメートル以内である場合にトランザクションがP2P DL上にのみブロードキャストされることを指定することができる。このことは、トランザクションが指定されたロケーション、例えばボブのコーヒーショップ、おいてのみ行われることを保証する。

一旦、一致が見い出され、かつ、トランザクションを完了する以前に、１つまたはそれ以上の介在するステップ（intervening steps）が実行されてよい。これらは、一致が見い出されたことの当事者に対するアラートを含んでよく、進行することを彼らが望んでいるということを確認するためのリクエスト、等が後に続く。例えば、上述のように、条件が１人またはそれ以上のユーザによって完全ではないがほぼ満足される場合には、それでも一致は記録されるが、全ての当事者がインビテーションの条件に満足するまで確定されなくてよい。このプロセスは、条件について最終合意を交渉するためのカウンターオファー（counter offers）をもたらし得るものであり、次いで、上述のプロセスに従ってさらなるインビテーションの生成をもたらし得る。

最終的な交換は、各インビテーショントランザクションの出力を費やす１つまたはそれ以上のビットコイントランザクションを作成することによって実行することができる。本発明者は、トランザクションを完了するいくつかの新規な方法を見い出した。これらに限定されるわけではないが、トランザクションに関与するユーザ、交換されるエンティティ、およびトランザクションに関与するサービスプロバイダと発行者、を含む状況に依存し得るものである。これらの方法のうちいくつかの実施例が以下に説明される。

図２から図６までを参照して上述された実施例から続いて、アリス－ボブおよびボブ－アリスについて別々のトランザクションのためのトランザクションテーブル500が図７に示されており、そして、トランザクションフローの概略図600が図８に示されている。図４と図５に示されるメタデータ値と同様に、トランザクションテーブル500において提供される値は、例としてだけ示されるものである。この例においては、アリスのインビテーショントランザクションにおける彼女のビットコインはボブに対して費やされ、そして、ボブのインビテーショントランザクションにおける彼のCADトークン化ビットコインはアリスに対して費やされる。

最初にアリス－ボブのトランザクションを参照すると、このトランザクションの入力602は、アリスのインビテーションと共にP2P DL上に置かれたインビテーショントランザクションの出力から提供されている。第１トランザクションと同様に、アリスとエスクローサービスプロバイダ110の両方によって入力スクリプトが署名される（アリスはトランザクションが進行することを喜ぶと仮定している）。スクリプトは、費やされたビットコイン（spent bitcoins）をロック解除し、ａ）トークン化CADに対する見返りの彼の支払いとしてボブに対して（604）、ｂ）交換に対する支払いとして交換サービスプロバイダ104に対して（606）、およびｃ）もしあれば、お釣り（change）としてアリスに対して（608）、出力することができる。

これからボブ－アリスのトランザクションを参照すると、このトランザクションは２つの入力を有している。トランザクションの第１入力610は、ボブのインビテーションと共にP2P DL上に置かれたインビテーショントランザクションの出力から提供されている。このトランザクションに対する入力はトークン化されているため、入力スクリプトはボブとトークン発行者の両方によって署名される必要がある。この状況において、トークン発行者は、また、エスクローとしても動作し、それにより、ボブ（および、任的にアリス）がトランザクションに満足するまで資金を保留している。署名されたスクリプトは費やされたトークンをロック解除し、次いで、ａ）BTCに対する見返りの支払いとしてアリスに対して（612）、およびｂ）アリスに対して送付された値より少ないオリジナルのトークン値に対するお釣りトークン（change token）としてボブに戻って（614）、出力することができる。第２入力616は、ボブの以前のビットコイントランザクションからのものである。この入力は、ロック解除され、そして、ａ）交換に対する支払いとしてサービスプロバイダ104に対して、ｂ）交換トランザクションに対する料金（fee）としてビットコインマイナに対して、およびｃ）サービスプロバイダ104の料金とマイナの料金より少ないオリジナルのビットコイン入力値の値に対するビットコインでのお釣り（change）としてボブに対して、出力される。

各トランザクションに対するサービスプロバイダ104の料金は、トランザクションの値のスライス（slice）であってよい。代替的または追加的に、料金は、２つのインビテーションにおいて示された対応するレート条件間に広がる交換レートのスライスであってよい。例えば、オファーされたレートがオーバーラップする場合に、サービスプロバイダ104は、交換に係る両面をそれぞれの提示レート（asking rate）で遂行し、そして、差を料金として保持することができる。代替的または追加的に、サービスプロバイダ104によって、フラットな料金（サトシ、トークン化された通貨、またはその他におけるもの）が取られてよい。いくつかの実施形態において、サービスプロバイダは、実際のトランザクションを介して料金を引き出すことができない。代わりに、ユーザは、トランザクションの外で料金が課されることがある。例えば、ユーザは、会費、もしくは、１つまたはそれ以上のトランザクションに対するトランザクション毎の請求書が課されることがある（トランザクション毎または掛売り（on account）で、等）。

一旦トランザクションが完了すると、ボブとアリスのそれぞれのサービスプロバイダは、P2P DHTから彼らのインビテーションのエントリーを削除し、または、オリジナルのエントリーを無効にするさらなるエントリーを入力することができる。例えば、サービスプロバイダは、エントリーが支払トランザクション（spend transaction）に対応するので、P2P DHT上にそのエントリーを単に残すことができる。これは、インビテーションが、もはや有効でないことを意味する。代替的に、サービスプロバイダは、費やされたことを示すフィールドを用いてトランザクションをマークすることができる。これは、特定のエントリーに対応するDHTにおける個別のフィールドであってよいが、インビテーションと関連付けられた実際のメタデータは変更しない（このことは、スクリプトハッシュ（script hash）が未だにトランザクションにおけるハッシュと一致することを保証し得る）。代替的に、サービスプロバイダは、P2P DHTからエントリーを削除することができる。しかしながら、P2P DHTの利点は、システム100を使用するトランザクションの永続的な監査制御（audit control）である。望ましくは、従って、P2P DHTからのエントリーの削除が防止され、もしくは、エントリーのレコードを維持するために削除されたエントリーがアーカイブされる。一つの例においては、削除されたエントリーがアーカイブされる。

上記の例のトランザクションにおいて、パズル（puzzle）は交換されない。別の言葉で言えば、２つのトランザクション（アリス－ボブとボブーアリス）は完全に分離された、別々のものである。しかしながら、ある場合には、２つのトランザクションについて有効または無効のいずれかであることが望ましい。図９は、アリスのトランザクション（アリス－
ボブ）においてパズルが交換される代替的なトランザクションの例を示している。そうすることによって、２つのトランザクションは一緒にロックされ、他方を費やすことなく、一方を費やすことはできない。このことは、相手方のトランザクションも通過することなく、一方の当事者から別の当事者へのトランザクションが通過することを防止する。この意味での「パズル（”puzzle”）」は、一方の当事者によってだけ知られている秘密に係るハッシュを含んでよい。例えば、「秘密（”secret”）」は、パズルに対する「ソリューション（”solution”）」である数字であってよい。ハッシュは、ロック解除するためには、署名並びにパズルソリューションの両方が提示される必要があるような方法で、引き換えスクリプトの一部として統合されている。

上記の２つの例においては、交換を完了するために２つのビットコイントランザクションが実行されている。可能であれば、しかしながら、上記の２つのトランザクションを単一のビットコイントランザクションへと統合することが望ましい。そうすることは、交換の２つの部分を一緒に自動的にロックし、かつ、トランザクションのためにアリスとボブによって支払われる全体の手数料の削減につながる。

図１０は、アリスとボブとの間の単一のトランザクションに対するトランザクションテーブル700を示している。交換のためのトランザクションフローは、以前の２つの実施例と同じである、つまり図６に示されているものである。しかしながら、交換は、単一のマルチ入力－マルチ出力（multi-input-multi-output、MIMO）トランザクションへと統合されている。そうであるから、パズルは、２つの別個のトランザクションが行われる場合のように、共依存（co-dependence）を確実にするために交換される必要がない。図８においては、２つの別個の料金が交換サービスプロバイダ104に対して支払われることに留意する。しかしながら、ボブとアリスの両方について交換サービスプロバイダ104が同じである場合に、これら２つの料金は、ボブ、アリス、またはボブとアリスの両方によって支払われる、単一のトランザクションへと統合され得る。

２つ以上の当事者を含むトランザクション

上記のトランザクションは、２つのエンティティ間における交換に関するものである。しかしながら、いくつかの例においては、２つより多いエンティティが交換に関与し得ることが正しく理解されよう。例えば、以下のシナリオを考えてみる。アリスはビットコインをリンゴと交換したいが、最低でも１０００個のリンゴしか受け入れない。ボブは、リンゴをビットコインと交換したいが、５００個のリンゴしか供給できない。キャロルは、リンゴをビットコインと交換したいが、６００個のリンゴしか供給できない。こうした状況において、アリスのインビテーションの条件は、ボブまたはキャロルによって個別には満足することができない。しかしながら、一緒に、ボブとキャロルは１１００個のリンゴを持っており、そして、アリスのインビテーションを満足することができる。

別の実施例において、アリスはトークン化CADをトークン化GBPと交換したいし、ボブはトークン化GBPをトークン化AUDと交換したいし、そして、キャロルはトークン化CADをトークン化AUDと交換したい。３人の当事者のあらゆる２人の間に直接的な一致は存在しないが、組み合わされて、インビテーションのそれぞれを満足することができる。－アリスのトークン化CADがキャロルのところへ行き、ボブのトークン化GBPがアリスのところへ行き、そして、キャロルのトークン化AUDがボブのところへ行くことができる。図１１Ａから図１１Ｃは、アリス、ボブ、およびキャロルの間におけるトランザクションのための例示的なトランザクションテーブルを示している。

図１１Ａを最初に参照すると、アリスからキャロルへの支払いについてトランザクションテーブルが示されている。アリスは１５００ドルのトークン化CADを有しており、そして、ボブからのトークン化GBP５００を必要としている。トランザクションは、トークン化CAD１０００をアリスからキャロルに対して支払い、そして、アリスは彼女自身に残りのトークン化CAD５００（１５００－１０００）を支払う。標準BTC（regular BTC）を使用して、アリスは、サービスプロバイダの料金（図１１Ａに示すような定額料金であってよく、または、移転の価値に応じた料金であってよい）を支払うことができ、そして、お釣りからマイナ（miner）のための１０００サトシを差し引いたものを彼女自身に支払う。

図１１Ｂをこれから参照すると、ボブからアリスへのトークン化GBPの支払いについてトランザクションテーブルが示されている。ボブはトークン化GBP７５０を有しており、そして、キャロルからのトークン化AUDを必要としている。トランザクションは、トークン化GBP５００をボブからアリスに対して支払い、そして、ボブは彼自身に残りのトークン化GBP２５０（７５０－５００）を支払う。標準BTCを使用して、ボブは、サービスプロバイダの料金（図１１Ｂに示すような定額料金であってよく、または、移転の価値に応じた料金であってよい）を支払うことができ、そして、お釣りからマイナのための１０００サトシを差し引いたものを彼自身に支払う。

図１１Ｃをこれから参照すると、キャロルからボブへのトークン化AUDの支払いについてトランザクションテーブルが示されている。キャロルはトークン化AUD１５００を有しており、そして、アリスからのトークン化CADを必要としている。トランザクションは、トークン化AUD１０００をキャロルからボブに対して支払い、そして、キャロルは彼女自身に残りのトークン化AUD５００（１５００－１０００）を支払う。標準BTCを使用して、キャロルは、サービスプロバイダの料金（図１１Ｃに示すような定額料金であってよく、または、移転の価値に応じた料金であってよい）を支払うことができ、そして、お釣りからマイナのための１０００サトシを差し引いたものを彼自身に支払う。交換が２つまたはそれ以上の別個のトランザクション（例えば、１：アリスがボブに対して移転し、そして、２：ボブがアリスに対して移転する）から成る場合には、全ての当事者が自身の資格（entitlement）を受け取るか又は誰も受け取らないかのいずれかであることを保証するように、トランザクションがリンクされてよいことが正しく理解されよう。これは、以下の条件を満足することによって達成することができる（２人の当事者、ＡとＢ、の例を使用するが、３人またはそれ以上の当事者まで容易に拡張可能である）：ＡからＢへ移転するトランザクション出力が存在し、かつ、Ｂによって費やすことができるのは、同時に、ＢからＡへ移転するトランザクション出力も存在し、かつ、Ａによって費やすことができる場合だけであり、逆もまた同様である。当事者ＡとＢは、アリスとボブだけでなく、各トランザクションのために必要とされる一式の署名者を参照する（例えば、トークン発行者、エスクロー、等を含む）ことに留意する。

ユーザからの選択の受け取り

図６を参照して上述した例示的な交換の変形においては、オーダーのマッチングのためにP2P DHTを解析する（parsing）サービスプロバイダの代わりに、現在のユーザ自身が現在のインビテーションを見るためにP2P DHTをスキャンまたはブラウズ（browse）することができる。ブラウジングは、交換サービスプロバイダ104といった、第三者によって促進されてよい。第三者は、インターフェイスを提供することができ、ユーザは、興味を持ち得るインビテーションについて、その中で閲覧、スキャン、および検索することができる。

ユーザは、次いで、P2P DHT上で彼ら自身の将来のインビテーション（prospective invitation）を入力するプロセスをスキップすることができるが、代わりに、彼らが関心を持つオーダーと一致又はほぼ一致するインビテーションを作成することを選択することができる。

例えば、先の実施例に続いて、しかし、対照的に、ボブは、ブラウジングまたは検索インターフェイスを介してP2P DHT上でアリスのインビテーションを見つけることができる。その場合に、ボブは、アリスのものと一致するように自分のインビテーションを入力することができる。ボブは、これをいくつかの方法のうちの１つで行うことができる。一つの実施例においては、オーダーを「受諾（”Accept”）」するためのアリスのオーダーを表示する機能がインターフェイス上に存在してよい。ボブが、アリスがインビテーションのために使用したのと同じ交換サービスプロバイダ104のクライアントである場合には、彼らがボブのｅウォレット（eWallet）（公開鍵、等）に既にアクセスしていることがあり、そして、従って、そうした情報に基づいて一致するオーダー（matching order）を作成することができる。それに応じて、交換サービスプロバイダ110は、インビテーションのマッチングのための引き換えスクリプトを生成し、これを署名のためにボブに対して送付し、署名された引き換えスクリプトを受け取り、そして、トランザクションのために備えてP2P DL上にオーダーを入力することができる。ボブがアリスの交換サービスプロバイダ104のクライアントでない場合には、ボブが必要とされる情報および承認（authorisation）を入力できるようにする機能が提供されてよく、次いで、サービスプロバイダがボブの一致するオーダーを作成できるようにする。図７と図８を参照して上述したのと同じプロセスが、次いで、後に続く。

上記の例は、BTCをトークン化CADと交換することを説明している。しかしながら、システム100は、あらゆるタイプのトークンについて働くことが正しく理解されよう。例えば、あらゆるタイプの（すなわち、通貨契約だけでなく、任意の契約を表わしている）トークンのためのBTC、あらゆる他のタイプのトークンのための任意のタイプのトークン、商品／サービスのためのBTC、商品／サービスのためのトークン、または、商品／サービスのための商品／サービス、を含んでいる。追加的および理論的に、上記のプロセスは、BTCに対するBTCの交換へ変更することができるが、そうした交換は現実の意味（real meaning）を有さない。

商品／サービスの交換

商品／サービスが交換に関与する場合には、上述のトランザクションプロセスに係るわずかな変更が必要とされる。

そうした場合に、（商品及び／又はサービスの）トランザクションは、交換に関わる商品またはサービスの記述（description）を含んでいる。契約書または権利証書によって表される、トークンとは異なり、記述は、契約を構成するものではない。

記述は、アイテムを一意的に識別しても、しなくてもよい。例えば、物理的アイテムがトランザクションに関与する場合、その記述は、その物理的アイテムに関連付けられた一意の識別子を明示的に参照することができる。追加的または代替的に、記述メタデータ（description metadata）は、以下のうち１つまたはそれ以上を含んでよい。ａ）提供されるか、または、要求される所望のアイテムの一般的な記述、例えば、「食器洗い機、＜ ３ ｙｏ（”dishwasher,<3 yo”）」、ｂ）オークションウェブサイトにおける販売について特定のアイテムに対する参照、例えば、「オークションサイト上で売りに出された中古品」、ｃ）アイテムタイプの任意の数、例えば、販売のための１５枚のＴシャツを、単品として又は１５枚までの任意の数量として購買することができると広告すること、ｄ）現金（cash）への参照、任意の特定の通貨におけるもの、ｅ）労働および支払いに係る記述であり、１回の作業完了のたび、もしくは、繰返し又は時間毎の支払いを伴う通常の芝刈り（繰返し作業）のためのもの、または、ｆ）１つまたはそれ以上のキーワード、例えば「食器洗い機」。

サービスに関して、サービスはトークンと同様にコントラクトによって裏付けられる。それとして、サービスはシェア（shares）へと分割可能であり、そして、分割不可能なサービスは１回限りの仕事（one-time job）、すなわち、分割可能であるが単一シェア（１シェア）を有するもの、であるとみなすことができる。サービスが分割不可能である場合に、サービスはインビテーションおよび交換の目的のトークンとして取り扱われてよい。アイテムがトークンによって裏付けされている場合に、アイテムは、インビテーションおよび交換の両方の目的のトークンとして取り扱われ、そして、不換通貨（fiat currency）のためのトークンといった、他のトークンと同じ方法で交換される。

一意の識別子と関連付けられた物理的アイテムを含むトランザクションの一つの実施が、これから説明される。先の実施例と同様に、この例において、アリスは、P2P DLおよびP2P DHT上にインビテーションを置くために彼女の交換プロバイダを使用する。このインビテーションは、彼女が一意の識別子ＸＹＺ１２３を有する物理的アイテム、ラファエルの傑作「十字架降架（”Deposition of Christ”）」に関連し得るもの、を２５００ＢＴＣ未満（no more than 2500BTC）で購入するという記述を含んでいる。同様に、ボブは、彼が２４００ＢＴＣ以上（no less than 2400BTC）でアイテムＸＹＺ１２３を販売するというインビテーションのマッチング（matching invitation）を置くことができる。アリスは、P2P DLを閲覧して、アイテム番号ＸＹＺ１２３を持つアイテムを見つけ、そして、この情報に基づいて一致するオーダー（matching order）を置くことができる。もしくは、代替的に、アリスは、その後に第三者、例えば交換サービスプロバイダ、によってマッチングされる一般的なインビテーションを置くことができ、そして、続いて、カタログアイテム番号と記述を含む新たなインビテーションがボブのオーダーと一致するように作成される。

一意のＩＤを含むトランザクションについて、そうしたIDは、特定の交換サービスプロバイダに対してだけでなく、P2P DL全体にわたっても、永久に一意でなければならないことが正しく理解されよう。従って、一意の識別子がデバイスに対して全くの一意ではない場合（例えば、デバイスのシリアル番号）には、交換サービスプロバイダは、そのデバイスについての一意の識別子を生成することができる。各識別子がP2P DL全体に対して一意であることを保証するために、各交換サービスプロバイダは、例えば、彼らが使用する番号の前につける彼ら独自の一意のコードを有することができ、P2P DL上で広告されている製品を一意的に識別する。

アリスとボブとの間で一旦合意に至ると、図７から図１０を参照して上述した例示的なトランザクションプロセスに従ってトランザクションが行われる。

物理的アイテムを含むトランザクションのさらなる実施例が、これから説明される。しかしながら、この例において、アイテムは、それに関連する一意の識別子を有していない。

インビテーションが複数の類似アイテムを販売するためのオファーを含む場合には、メタデータは、任意の１つのトランザクションを用いて購入することができるアイテムの最大および最小の量を記述するように要求され得る。例えば、アリスは、彼女が、トランザクション毎に少なくとも５枚、Dead Lizard 2015コンサートツアーＴシャツを、それぞれ０．０２５ＢＴＣで１５枚まで売るということを暗示する（inferring）インビテーションを置くことができる。この場合に、メタデータ値は、最小レート（０．０２５ＢＴＣ／アイテム）、最大量（Offer-QTY-max（15））、および最小量（Offer-QTY-min（5））を含んでよい。以下の表は、インビテーションに関連付けられたメタデータをまとめている。

支払トランザクションにおける実際のBTC値が、次いで、交換サービスプロバイダによって計算される。このトランザクションは、実行して交換するためのインビテーションを単に表しているだけなので、トランザクションの実際の値は、例えば、ダスト（dust）ほどに小さくてよい（５４６サトシ）。代替的に、以下で説明するように、値は、インビテーションを保証するためにサービスプロバイダによって必要とされる名目額（nominal amount）であってよい（例えば、そのためアリスは引出しをしないように動機付けられる）。

さらなる実施例においては、硬貨（現金）の形態における商品を交換することができる。例えば、アリスは、１５０ＢＴＣの最大購入で、カナダドル（トークンではなく硬貨（hard currency））についてビットコインを販売するインビテーションを置くことができる。インビテーションは、追加的に、彼女の店舗の住所（371 Whimsy Avenue、Brentford）だけで交換が行われなければならないというロケーション条件を含んでよい。インビテーションのマッチングを置いた後で、トランザクションを確定するために、ボブは、次いで、ビットコイントランザクションにおける支払いの代わりに、現金を引き渡すためにアリスの店に持ってきてよい。物理的な移転のためにボブとアリスがひとたび彼女の店で会うと、次いで、ボブに対するビットコインの実際のデジタルトランザクションおよびアリスに対する硬貨の移転のデジタル記録が行われてよい。

他の商品／サービスと交換される商品／サービスを含むトランザクションの場合には、P2P DL上のトランザクションは、記録としてのみ存在し、当事者間のいかなる価値も交換するものではないことが正しく理解されよう（サービスプロバイダ等に対するあらゆる料金とは別に）。ユーザは、システムを使用し、そして、交換が永久に記録されるように、P2P DL上にトランザクションを入力するための名目上のサービス料（nominal service fee）を支払うように選択することができる。

オリジナルのインビテーショントランザクションは、価値の移転またはイベントの記録としてではなく、インビテーションとしてのみ動作すること、に留意する。交換が物理的アイテムだけを含むように、商品間の交換（goods-for-goods exchange）が行われる場合には、最終的な交換がP2P DL上に記録される必要はない。P2P DLは、最終的な交換においていかなるトランザクションも完了することを要求されないからである。それにもかかわらず、物理的アイテムの交換に対する当事者がP2P DL上に交換を記録することを望む場合には、そうするためのマイナに対する料金を条件として、彼らは、インビテーショントランザクションを互いにそれぞれを費やすことができる。当事者がP2P DL上に最終的な交換を記録することを望まない場合には、インビテーショントランザクションを彼ら自身に戻すように費やすか、または、P2P DL上に未使用のまま残しておくことができる。

商品に対するBTC、または商品に対するトークンを含む交換の場合には、BTCまたはトークンの値を移転するために、少なくとも１つのトランザクションがP2P DL上で費やされる。この場合に、商品を上乗せする（offering up）インビテーショントランザクションが、費やされてもされなくてもよい。そのインビテーショントランザクションを費やすことによって交換（商品）の価値は移転されないからである。しかしながら、再度、当事者は、移転の恒久的な記録（例えば、販売の領収書）を提供するために、それにもかかわらずトランザクションを費やすように決定することができる。

上記のトランザクションにおいて費やされた金額は、特にアリスのオファーがビットコインまたはトークンではなく商品／サービスである場合に、いくつかの事例においては提供される金額を表わさないことがある。代わりに、サービスプロバイダは、商品の価値を表す金額のアリスによる「デポジット（”deposit”）」を要求するか、または、別の方法でアリスがオファーを「保証する（”guarantee”）」ことができる場合に名目上の金額だけを必要求するか、もしくは、サービスプロバイダ自身がアリスのためにビットコインを提供し（彼女はいくらも持っていないかもしれない）、そして、クライアントに対して料金を請求するあらゆる手段によってこの調達コスト（funding cost）をカバーすることができるだろう。

上述の実施形態においては、ユーザのインビテーションがP2P DHTにおいて公開される。いくつかの実施形態においては、しかしながら、ユーザのインビテーション（例えば、スクリプトおよびスクリプトハッシュ）がウェブサイトにおいて公開され、別のユーザに対して直接的に送付されてよい。

いくつかの実施形態において、ユーザのインビテーションは、サービスプロバイダによってローカルに保管されてよい。例えば、サービスプロバイダは、特定のユーザだけがユーザのインビテーションの詳細にアクセスすることができるプライベートオークションをホストすることができる。

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

ステップ、特徴、インテジャ、混合物及び／又は化合物は、個別に又は集合的に、ここにおいて開示され、または、本出願の明細書において示されており、そして、上記のステップまたは特徴の２つまたはそれ以上のうち任意および全ての組み合わせもそうである。

Claims (15)

1. 移転を開始するためのコンピュータで実施される方法であって、
   交換されるエンティティの指示および前記交換のための条件のセットを含むメタデータを含むインビテーションを、クライアントから受け取るステップと、
   前記クライアントの公開鍵を獲得するステップと、
   前記公開鍵を使用して引き換えスクリプトを生成するステップと、
   署名された引き換えスクリプトを獲得するステップであり、前記署名された引き換えスクリプは、前記クライアントの秘密鍵を使用して署名されている、ステップと、
   前記署名された引き換えスクリプトのハッシュを生成するステップと、
   前記インビテーションのメタデータおよび前記署名された引き換えスクリプトの前記ハッシュを、分散ハッシュテーブル（ＤＨＴ）において発行するステップと、
   前記署名された引き換えスクリプトの前記ハッシュに基づいて、ロッキングスクリプトを生成するステップと、
   を含む、方法。
2. 前記署名された引き換えスクリプトを獲得するステップは、
   前記引き換えスクリプトを、署名のために前記クライアントへ送付するステップと、
   署名された引き換えスクリプトを受け取るステップであり、前記署名された引き換えスクリプトは、前記クライアントの秘密鍵を使用して署名されている、ステップと、
   を含む、請求項１に記載の方法。
3. 前記署名された引き換えスクリプトを獲得するステップは、
   前記クライアントから承認のレシートを獲得するステップと、
   前記クライアントに変わって、前記クライアントの秘密鍵を使用して前記引き換えスクリプトに署名するステップと、
   を含む、請求項１に記載の方法。
4. 前記引き換えスクリプトは、Ｐ２ＳＨビットコイントランザクションについて適したフォーマットである、
   請求項１乃至３いずれか一項に記載の方法。
5. 前記メタデータは、前記引き換えスクリプトにおいて提供される、
   請求項１乃至４いずれか一項に記載の方法。
6. 前記メタデータは、暗号鍵のためのロケーションとしてブロックチェーンプロトコルにおいて指定されたロケーションにおいてスクリプトの中で提供される、
   請求項１乃至５いずれか一項に記載の方法。
7. 前記メタデータは、マルチシグロック解除スクリプトにおいて保管されている３２バイトの公開鍵で提供される、
   請求項６に記載の方法。
8. 前記方法は、さらに、
   前記ロッキングスクリプトを含むブロックチェーントランザクションを生成するステップであり、前記ブロックチェーントランザクションは、仮想通貨のある量をＰ２ＳＨスクリプトに支払うものである、ステップ、
   を含む、
   請求項４に記載の方法。
9. 前記方法は、さらに、
   Ｐ２Ｐ分散型台帳に包含するために、前記ブロックチェーントランザクションを、ネットワークにわたり、ブロードキャストするステップ、
   を含む、請求項８に記載の方法。
10. 前記Ｐ２ＳＨスクリプトは、ロック解除するために２つの署名を必要とする、
    請求項８または９に記載の方法。
11. 前記エンティティのうち１つ以上は、
    ａ）ビットコイン、
    ｂ）コントラクト、
    ｃ）商品、
    ｄ）サービス、
    のうちの１つである、
    請求項１乃至１０いずれか一項に記載の方法。
12. 前記コントラクトは、
    ａ）不換通貨、
    ｂ）不動産権利書、
    ｃ）チケット、
    ｄ）商品、
    ｅ）サービス、
    のうちの１つまたはそれ以上に対するものである、
    請求項１１に記載の方法。
13. 前記条件のセットは、
    ａ）前記交換に関する１つまたはそれ以上の価格における１つまたはそれ以上の限度範囲、
    ｂ）交換レート、
    ｃ）前記インビテーションの遂行に対する締め切り、
    ｄ）前記交換を行うための地理的領域における制限、
    のうち１つまたはそれ以上を含む、
    請求項１乃至１２いずれか一項に記載の方法。
14. 請求項１乃至１３いずれか一項に記載の方法を実行するように構成されている、電子デバイス。
15. 移転を実行するためにシステムであって、
    請求項１４に記載の電子デバイスと、
    クライアント装置であり、
    引き換えスクリプトに署名し、かつ／あるいは、
    前記引き換えスクリプトに署名するために、マッチングサービスプロバイダについて承認のレシートを提供する、
    ように構成されている、クライアント装置と、
    を含む、システム。

Images