特許 6957482 ブロックチェーンベースにおけるエンティティのセキュアな移転のための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6957482

(24)【登録日】2021年10月8日

(45)【発行日】2021年11月2日

(54)【発明の名称】ブロックチェーンベースにおけるエンティティのセキュアな移転のための方法およびシステム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20211021BHJP

   G06Q 20/38 20120101ALI20211021BHJP

   G09C 1/00 20060101ALI20211021BHJP

【ＦＩ】

   H04L9/00 675Z

   G06Q20/38

   H04L9/00 675B

   G09C1/00 640D

【請求項の数】23

【全頁数】47

(21)【出願番号】特願2018-539302(P2018-539302)

(86)(22)【出願日】2017年2月16日

(65)【公表番号】特表2019-508948(P2019-508948A)

(43)【公表日】2019年3月28日

(86)【国際出願番号】IB2017050861

(87)【国際公開番号】WO2017145018

(87)【国際公開日】20170831

【審査請求日】2020年1月17日

(31)【優先権主張番号】1603123.9

(32)【優先日】2016年2月23日

(33)【優先権主張国】GB

(31)【優先権主張番号】1603125.4

(32)【優先日】2016年2月23日

(33)【優先権主張国】GB

(31)【優先権主張番号】1607063.3

(32)【優先日】2016年4月22日

(33)【優先権主張国】GB

(73)【特許権者】

【識別番号】318001991

【氏名又は名称】エヌチェーン ホールディングス リミテッド

【氏名又は名称原語表記】ＮＣＨＡＩＮ ＨＯＬＤＩＮＧＳ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ライト，クレイグ スティーヴン

(72)【発明者】

【氏名】サヴァナ，ステファヌ

【審査官】 中里 裕正

(56)【参考文献】

【文献】 国際公開第２０１５／１７１５８０（ＷＯ，Ａ３）

【文献】 特表２０１０−５１７１１８（ＪＰ，Ａ）

【文献】 特表２０１２−５１０６５４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００２／０１５６７２６（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００９／０１８２６７２（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１３／００３０９４１（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１４／０３３０７２１（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１５／００２６０７２（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１５／０２２０９２８（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１５／０２６９５３９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１５／０２６２１７３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０６Ｑ ２０／３８

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項1】

エンティティの交換をオファーするためのコンピュータで実施される方法であって、
第１スクリプトを生成するステップであり、該第１スクリプトは、
第１ユーザによる第１エンティティの交換のための第１インビテーションと関連付けられたメタデータの第１セットであり、該メタデータの第１セットは、交換のために提供される前記第１エンティティの指示および交換のための第１ロケーション条件を含む、メタデータの第１セットと、
前記第１ユーザと関連付けられた第１ユーザの公開鍵（Ｐ１Ａ）であり、該第１ユーザの公開鍵（Ｐ１Ａ）は、前記第１ユーザの公開鍵（Ｐ１Ａ）および第１ユーザの秘密鍵（Ｖ１Ａ）を含む非対称暗号ペアの一部である、第１ユーザの公開鍵と、
を含む、ステップと、
第１スクリプトハッシュを生成するために前記第１スクリプトをハッシュ化するステップと、
分散ハッシュテーブル（ＤＨＴ）において前記第１スクリプトおよび前記第１スクリプトハッシュを発行するステップと、
を含む、方法。

【請求項2】

前記第１スクリプトは、さらに、
第１の第三者と関連付けられた第１の第三者公開鍵（Ｐ１Ｔ）であり、該第１の第三者公開鍵（Ｐ１Ｔ）は、前記第１の第三者公開鍵（Ｐ１Ｔ）および第１の第三者秘密鍵（Ｖ１Ｔ）を含む非対称暗号ペアの一部である、第１の第三者公開鍵、
を含む、請求項１に記載の方法。

【請求項3】

前記方法は、
ピアツーピア（Ｐ２Ｐ）分散型台帳に包含するために、第１インビテーショントランザクションを生成するステップであり、該第１インビテーショントランザクションは、前記第１エンティティの交換において移転される第２エンティティの指示および前記第１スクリプトハッシュを含む、
請求項１または２に記載の方法。

【請求項4】

前記Ｐ２Ｐ分散型台帳は、ビットコインブロックチェーンである、
請求項１乃至３いずれか一項に記載の方法。

【請求項5】

交換のために提供される前記第１エンティティ、及び／又は、前記第１エンティティのための交換において移転される前記第２エンティティは、
ａ）仮想通貨、
ｂ）コントラクト、
ｃ）商品、
ｄ）サービス、
のうちの１つである、
請求項１乃至４いずれか一項に記載の方法。

【請求項6】

前記コントラクトは、
ａ）不換通貨、
ｂ）不動産権利書、
ｃ）チケット、
ｄ）商品、
ｅ）サービス、
のうちの１つまたはそれ以上に対するものである、
請求項４に記載の方法。

【請求項7】

前記第１ロケーション条件は、
ａ）前記第１エンティティの交換のための地理的ロケーションまたはエリアを示すロケーション情報、
ｂ）前記ロケーション情報のフォーマットを示すロケーションフォーマット情報、
ｃ）前記交換に関連する前記地理的ロケーションまたはエリアにおける範囲制限を示す範囲情報、および
ｄ）前記範囲情報のフォーマットを示す範囲フォーマット情報、
のうちの１つまたはそれ以上を含む、
請求項１乃至６いずれか一項に記載の方法。

【請求項8】

前記方法は、
第２スクリプトに対して前記第１スクリプトの前記第１インビテーションをマッチングするステップであり、該第２スクリプトは、少なくとも前記第１スクリプトにおいて指定された前記第１エンティティを前記第２スクリプトにおいて指定された第２エンティティと比較することによって前記ＤＨＴにおいて発行される、ステップ、
を含み、
前記第２スクリプトは、
第２ユーザによる第２エンティティの交換のための第２インビテーションと関連付けられたメタデータの第２セットであり、該メタデータの第２セットは、前記第１エンティティの交換において提供される前記第２エンティティの指示を含む、メタデータの第２セットと、
前記第２ユーザと関連付けられた第２ユーザの公開鍵（Ｐ２Ａ）であり、該第２ユーザの公開鍵（Ｐ２Ａ）は、前記第２ユーザの公開鍵（Ｐ２Ａ）および第２ユーザの秘密鍵（Ｖ２Ａ）を含む非対称暗号ペアの一部である、第２ユーザの公開鍵と、
第２の第三者と関連付けられた第２の第三者公開鍵（Ｐ２Ｔ）であり、該第２の第三者公開鍵（Ｐ２Ｔ）は、前記第２の第三者公開鍵（Ｐ２Ｔ）および第２の第三者秘密鍵（Ｖ２Ｔ）を含む非対称暗号ペアの一部である、第２の第三者公開鍵と、
を含む、請求項１または２に記載の方法。

【請求項9】

前記方法は、
前記第１ユーザ及び／又は前記第２ユーザのロケーションを特定することによって、前記ロケーション条件が満足されているか否かを判断するステップ、
を含む、請求項８に記載の方法。

【請求項10】

前記第２の第三者は、前記第１の第三者と同一である、
請求項８または９に記載の方法。

【請求項11】

前記方法は、さらに、
前記ＤＨＴにおいて前記第２スクリプトを発行するステップを含み、該発行するステップは、
前記第２スクリプトを生成するステップ、
前記第２スクリプトをハッシュ化して、第２スクリプトハッシュを生成するステップ、および、
前記ＤＨＴにおいて前記第２スクリプトおよび第２スクリプトハッシュを発行するステップ、
を含む、請求項８乃至１０いずれか一項に記載の方法。

【請求項12】

前記方法は、さらに、
前記ピアツーピア分散型台帳に包含するために、第２インビテーショントランザクションを生成するステップであり、該第２インビテーショントランザクションは、前記第２エンティティの交換において移転される第１エンティティの指示、および前記第２スクリプトハッシュを含む、
請求項１１に記載の方法。

【請求項13】

前記方法は、さらに、
前記ピアツーピア分散型台帳に包含するために、第１交換トランザクションを生成するステップであり、該第１交換トランザクションは、
前記第１スクリプト、
前記第１ユーザの公開鍵（Ｐ１Ａ）、
前記第１の第三者公開鍵（Ｐ１Ｔ）、
前記第１インビテーショントランザクションの出力から提供される第１入力、および、
前記第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
を含む、ステップと、
前記ピアツーピア分散型台帳上に前記第１交換トランザクションを記録するステップと、
を含む、請求項１乃至１２いずれか一項に記載の方法。

【請求項14】

前記方法は、さらに、
前記ピアツーピア分散型台帳に包含するために、第２交換トランザクションを生成するステップであり、該第２交換トランザクションは、
前記第２スクリプト、
前記第２ユーザの公開鍵（Ｐ２Ａ）、
前記第２の第三者公開鍵（Ｐ２Ｔ）、
前記第２インビテーショントランザクションの出力から提供される第２入力、および、
前記第１ユーザに対して移転されることになる第２エンティティの第２量を指示する第２出力、
を含む、ステップと、
前記ピアツーピア分散型台帳上に前記第２交換トランザクションを記録するステップと、
を含む、請求項１２または１３に記載の方法。

【請求項15】

前記方法は、さらに、
前記ピアツーピア分散型台帳に包含するために、第１交換トランザクションを生成するステップであり、該第１交換トランザクションは、
前記第１スクリプト、
前記第１ユーザの公開鍵（Ｐ１Ａ）、
前記第１の第三者公開鍵（Ｐ１Ｔ）、
前記第２スクリプト、
前記第２ユーザの公開鍵（Ｐ２Ａ）、
前記第２の第三者公開鍵（Ｐ２Ｔ）、
前記第１インビテーショントランザクションの出力から提供される第１入力、
前記第２インビテーショントランザクションの出力から提供される第２入力、
前記第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
前記第１ユーザに対して移転されることになる第２エンティティの第２量を指示する第２出力、および、
前記第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
を含む、ステップと、
前記ピアツーピア分散型台帳上に前記第１交換トランザクションを記録するステップと、
を含む、請求項１２に記載の方法。

【請求項16】

前記第１交換トランザクションを生成するステップは、
前記第１スクリプトを前記第１ユーザの秘密鍵（Ｖ１Ａ）を用いて署名することを促進するステップと、
前記第１スクリプトを前記第１の第三者秘密鍵（Ｖ１Ｔ）を用いて署名することを促進するステップと、
を含む、請求項１３または１５に記載の方法。

【請求項17】

前記第２交換トランザクションを生成するステップは、
前記第２スクリプトを前記第２ユーザの秘密鍵（Ｖ２Ａ）を用いて署名することを促進するステップと、
前記第２スクリプトを前記第２の第三者秘密鍵（Ｖ２Ｔ）を用いて署名することを促進するステップと、
を含む、請求項１４または１５に記載の方法。

【請求項18】

前記方法は、さらに、
前記第１交換トランザクション及び／又は前記第２交換トランザクションを生成するステップまたは記録するステップの以前に、前記第１ユーザまたは前記第２ユーザのうち１人またはそれ以上が前記交換を受諾するように促進するステップ、
を含む、請求項１３乃至１５いずれか一項に記載の方法。

【請求項19】

前記第１交換トランザクション、および前記第２交換トランザクションのうち１つまたはそれ以上は、ペイツースクリプトハッシュ（Ｐ２ＳＨ）トランザクションである、
請求項１乃至１８いずれか一項に記載の方法。

【請求項20】

エンティティの交換をオファーするためのコンピュータシステムであって、
前記コンピュータシステムは、第１処理デバイスを含み、
前記第１処理デバイスは、
第１スクリプトを生成し、該第１スクリプトは、
第１ユーザによる第１エンティティの交換のための第１インビテーションと関連付けられたメタデータの第１セットであり、該メタデータの第１セットは、交換のために提供される前記第１エンティティの指示および交換のための第１ロケーション条件を含む、メタデータの第１セットと、
前記第１ユーザと関連付けられた第１ユーザの公開鍵（Ｐ１Ａ）であり、該第１ユーザの公開鍵（Ｐ１Ａ）は、前記第１ユーザの公開鍵（Ｐ１Ａ）および第１ユーザの秘密鍵（Ｖ１Ａ）を含む非対称暗号ペアの一部である、第１ユーザの公開鍵と、
を含み、
第１スクリプトハッシュを生成するために前記第１スクリプトをハッシュ化し、かつ、
分散ハッシュテーブル（ＤＨＴ）において前記第１スクリプトおよび前記第１スクリプトハッシュを発行する、
ように構成されている、システム。

【請求項21】

前記メタデータの第１セット及び／又は前記メタデータの第２セットは、引き換えスクリプトにおいて提供される、
請求項１乃至１９いずれか一項に記載の方法、もしくは、請求項２０に記載のシステム。

【請求項22】

前記メタデータの第１セット及び／又は前記メタデータの第２セットは、暗号鍵のためのロケーションとしてブロックチェーンプロトコルにおいて指示されたロケーションで前記スクリプトにおいて提供される、
請求項１乃至１９いずれか一項に記載の方法、もしくは、請求項２０に記載のシステム。

【請求項23】

請求項１乃至１９いずれか一項に記載の方法を実行するように動作可能である、プロセッサまたはプロセッサのグループ。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【0005】

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

【0006】

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

【0007】

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

【発明の概要】

【0008】

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

【0009】

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

【0010】

本発明は、特に、電子的移転のためのメモリ使用の強化された最適化、ハッシュ技術の使用を通じて改善されたセキュリティおよびデータ完全性、信頼できる第三者の必要性を排除することを通じて改善されたセキュリティ、および、強化されたデータの匿名性、を提供する。本発明は、また、異種または別個の当事者が、本発明によって提供される新規な方法及び／又はアーキテクチャを介して、互いを識別し、かつ／あるいは、データ交換することを可能にする改善された通信メカニズムも提供することができる。この利点のリストは、限定的または網羅的ではない。

【0011】

本発明は、種々の別個で、かつ、分離したコンピュータベースのリソースに係る相互作用（interaction）および相互通信（inter-communication）を必要とし得る。１つまたはそれ以上のユーザデバイス、および、ブロックチェーン関連のソフトウェアおよびプロトコルを実行するように構成されたコンピューティングノードを含む、分散コンピュータシステム（ブロックチェーン）、といったものである。

【0012】

本発明は、エンティティの交換をオファーするためのコンピュータで実施される方法を提供することができる。本方法は、
第１スクリプトを生成するステップであり、第１スクリプトは、
第１ユーザによる第１エンティティの交換のための第１インビテーションと関連付けられたメタデータの第１セットであり、交換のために提供される前記第１エンティティの指示および交換のための第１ロケーション条件を含む、メタデータの第１セットと、
第１ユーザと関連付けられた第１ユーザの公開鍵（Ｐ１Ａ）であり、第１ユーザの公開鍵（Ｐ１Ａ）および第１ユーザの秘密鍵（Ｖ１Ａ）を含む非対称暗号ペアの一部である、第１ユーザの公開鍵と、を含むステップと、
第１スクリプトハッシュを生成するために第１スクリプトをハッシュ化するステップと、
分散ハッシュテーブル（ＤＨＴ）において第１スクリプトおよび第１スクリプトハッシュを発行するステップと、を含んでよい。

第１スクリプトは、第１の第三者と関連付けられた第１の第三者公開鍵（Ｐ１Ｔ）を含んでよく、ここで、第１の第三者公開鍵（Ｐ１Ｔ）は、第１の第三者公開鍵（Ｐ１Ｔ）および第１の第三者秘密鍵（Ｖ１Ｔ）を含む非対称暗号ペアの一部である。

【0013】

第１スクリプトは、ブロックチェーントランザクション（Ｔｘ）と関連付けられたスクリプトであってよい。

【0014】

本方法は、さらに、ピアツーピア（Ｐ２Ｐ）分散型台帳（すなわち、ブロックチェーン）に包含するために、第１インビテーショントランザクション（Ｔｘ）を生成するステップを含み、第１インビテーショントランザクションは、第１エンティティの交換において移転される第２エンティティの指示および第１スクリプトハッシュを含んでいる。

【0015】

Ｐ２Ｐ分散型台帳は、ビットコインブロックチェーンであってよい。しかしながら、あらゆる他の好適なＰ２Ｐ分散型台帳が想定されることが正しく理解されよう。

【0016】

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

【0017】

本発明によって多くの利点が提供され、そのうちのいくつかがここで説明される。最初に、交換に関する情報は分散型台帳においてセキュアに埋め込まれたメタデータの中に含まれるため、交換は、ピアツーピアベースでセキュアに実行され、それによって信頼できる第三者を不要としている。このことは、次に、サービスプロバイダといった任意の第三者によって保持される交換に対する両当事者に関して大量の機密情報が必要となることを回避し、次に、危険にさらされている第三者のセキュリティに関するリスクを回避する。この利点は、トランザクションの匿名性を維持しながらも、また提供されている。第１スクリプトはハッシュされているので、スクリプトの対応するハッシュ値における変化を伴うことなく、メタデータの値を変更することは実行不可能な程度に難しいだろう。このことは、また、トランザクションの条件が当事者によって検証できるようにする。それらは公に利用可能な分散型台帳においてロックされているからであり、それはトランザクションの整合性を信頼できるものにしている。利点は、また、第１メタデータを第１スクリプトにおいて公開鍵のために利用可能な１つまたはそれ以上の場所に埋め込むことができることも提供し、進行をブロックするのとは対照的に、それによって、メタデータを処理するのに適していないノードが別のノードに対してスクリプトを単に送付することを可能している。このことは、次に、関連するトランザクションの計算効率を改善する。さらなる利点が提供され、制御データをメタデータの中に組み込むことができる。例えば、会合場所に対するチケット、もしくは、旅行チケットまたバウチャーを表すトークンの場合の、バリアに対するアクセスコードである。メタデータは、また、ポインタが示す交換の詳細のオフブロックリポジトリ（off-block repository）を含むこともでき、それによって、関連トランザクションの処理に使用されるメモリ及び／又は処理リソースを少なくすることができる。なおもさらなる、トークンを分割することができるという別の利点が提供され、２つまたはそれ以上のトランザクション出力を可能にしている。その各々は、トークン化、または、非トークン化された電子的に移転可能なデジタルアセットに関連し得る。

【0018】

交換のために提供される第１エンティティ、及び／又は、第１エンティティのための交換において移転される第２エンティティは、
ａ）仮想通貨、
ｂ）コントラクト、
ｃ）商品、
ｄ）サービス、のうちの１つまたはそれ以上のを含んでよい。

【0019】

コントラクトは、少なくとも部分的に、」
ａ）不換通貨、
ｂ）不動産権利書、
ｃ）チケット、
ｄ）商品、
ｅ）サービス、のうちの１つまたはそれ以上に関するものであり得る。

【0020】

第１ロケーション条件は、
ａ）第１エンティティの交換のための地理的ロケーションまたはエリアを示すロケーション情報、
ｂ）ロケーション情報のフォーマットを示すロケーションフォーマット情報、
ｃ）交換に関連する地理的ロケーションまたはエリアにおける範囲制限を示す範囲情報、および
ｄ）範囲情報のフォーマットを示す範囲フォーマット情報、のうちの１つまたはそれ以上を含み得る。

【0021】

本方法は、
第２スクリプトに対して第１スクリプトの第１インビテーションをマッチングするステップであり、第２スクリプトは、少なくとも第１スクリプトにおいて指定された第１エンティティを第２スクリプトにおいて指定された第２エンティティと比較することによってＤＨＴにおいて発行される、ステップを含み、
ここで、第２スクリプトは、
第２ユーザによる第２エンティティの交換のための第２インビテーションと関連付けられたメタデータの第２セットであり、第１エンティティの交換において提供される第２エンティティの指示を含む、メタデータの第２セットと、
前記第２ユーザと関連付けられた第２ユーザの公開鍵（Ｐ２Ａ）であり、第２ユーザの公開鍵（Ｐ２Ａ）は、第２ユーザの公開鍵（Ｐ２Ａ）および第２ユーザの秘密鍵（Ｖ２Ａ）を含む非対称暗号ペアの一部である、第２ユーザの公開鍵と、
第２の第三者と関連付けられた第２の第三者公開鍵（Ｐ２Ｔ）であり、第２の第三者公開鍵（Ｐ２Ｔ）は、第２の第三者公開鍵（Ｐ２Ｔ）および第２の第三者秘密鍵（Ｖ２Ｔ）を含む非対称暗号ペアの一部である、第２の第三者公開鍵と、を含む。

【0022】

本方法は、第１ユーザ及び／又は第２ユーザのロケーションを特定することによって、ロケーション条件が満足されているか否かを判断するステップ、を含み得る。

【0023】

第２の第三者は、第１の第三者と同一であってよい。

【0024】

本方法は、さらに、ＤＨＴにおいて第２スクリプトを発行するステップを含み、発行するステップは、
第２スクリプトを生成するステップ、
第２スクリプトをハッシュ化して、第２スクリプトハッシュを生成するステップ、および、
ＤＨＴにおいて第２スクリプトおよび第２スクリプトハッシュを発行するステップ、を含んでいる。

【0025】

本方法は、Ｐ２Ｐ分散型台帳に包含するために、第２インビテーショントランザクションを生成するステップを含んでよく、第２インビテーショントランザクションは、第２エンティティの交換において移転される第１エンティティの指示、および第２スクリプトハッシュを含んでいる。

【0026】

１つの実施例において、本方法は、さらに、
Ｐ２Ｐ分散型台帳に包含するために第１交換トランザクションを生成するステップであり、第１交換トランザクションは、
第１スクリプト、
第１ユーザの公開鍵（Ｐ１Ａ）、
第１の第三者公開鍵（Ｐ１Ｔ）、
第１インビテーショントランザクションの出力から提供される第１入力、および、
第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
を含む、ステップと、
Ｐ２Ｐ分散型台帳上に第１交換トランザクションを記録するステップと、を含み得る。

【0027】

さらに、本方法は、
Ｐ２Ｐ分散型台帳に包含するために第２交換トランザクションを生成するステップであり、第２交換トランザクションは、
第２スクリプト、
第２ユーザの公開鍵（Ｐ２Ａ）、
第２の第三者公開鍵（Ｐ２Ｔ）、
第２インビテーショントランザクションの出力から提供される第２入力、および、
第１ユーザに対して移転されることになる第２エンティティの第２量を指示する第２出力、
を含む、ステップと、
Ｐ２Ｐ分散型台帳上に第２交換トランザクションを記録するステップと、を含み得る。

【0028】

代替的に、本方法は、
Ｐ２Ｐ分散型台帳に包含するために第１交換トランザクションを生成するステップであり、第１交換トランザクションは、
第１スクリプト、
第１ユーザの公開鍵（Ｐ１Ａ）、
第１の第三者公開鍵（Ｐ１Ｔ）、
第２スクリプト、
第２ユーザの公開鍵（Ｐ２Ａ）、
第２の第三者公開鍵（Ｐ２Ｔ）、
第１インビテーショントランザクションの出力から提供される第１入力、
第２インビテーショントランザクションの出力から提供される第２入力、
第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
第１ユーザに対して移転されることになる第２エンティティの第２量を指示する第２出力、および、
第２ユーザに対して移転されることになる第１エンティティの第１量を指示する第１出力、
を含む、ステップと、
ピアツーピア分散型台帳上に第１交換トランザクションを記録するステップと、を含み得る。

【0029】

第１交換トランザクションを生成するステップは、第１スクリプトを第１ユーザの秘密鍵（Ｖ１Ａ）を用いて署名することを促進するステップ、および、第１スクリプトを第１の第三者秘密鍵（Ｖ１Ｔ）を用いて署名することを促進するステップ、を含み得る。

【0030】

同様に、第２交換トランザクションを生成するステップは、第２スクリプトを第２ユーザの秘密鍵（Ｖ２Ａ）を用いて署名することを促進するステップ、および、第２スクリプトを第２の第三者秘密鍵（Ｖ２Ｔ）を用いて署名することを促進するステップ、を含み得る。

【0031】

本方法は、さらに、第１交換トランザクション及び／又は第２交換トランザクションを生成するステップまたは記録するステップの以前に、第１ユーザまたは第２ユーザのうち１人またはそれ以上が交換を受諾するように促進するステップ、を含み得る。

【0032】

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

【0033】

本開示の実施形態に従って、エンティティの交換をオファーするためのコンピュータシステムが提供される。本コンピュータシステムは、第１処理デバイスを含み、
第１処理デバイスは、
第１スクリプトを生成し、第１スクリプトは、
第１ユーザによる第１エンティティの交換のための第１インビテーションと関連付けられたメタデータの第１セットであり、メタデータの第１セットは、交換のために提供される第１エンティティの指示および交換のための第１ロケーション条件を含む、メタデータの第１セットと、
第１ユーザと関連付けられた第１ユーザの公開鍵（Ｐ１Ａ）であり、第１ユーザの公開鍵（Ｐ１Ａ）は、第１ユーザの公開鍵（Ｐ１Ａ）および第１ユーザの秘密鍵（Ｖ１Ａ）を含む非対称暗号ペアの一部である、第１ユーザの公開鍵と、を含み、
第１スクリプトハッシュを生成するために第１スクリプトをハッシュ化し、かつ、
分散ハッシュテーブル（ＤＨＴ）において第１スクリプトおよび第１スクリプトハッシュを発行する、
ように構成されている。

本スクリプトは、さらに、第１の第三者と関連付けられた第１の第三者公開鍵（Ｐ１Ｔ）を含み、ここで、第１の第三者公開鍵（Ｐ１Ｔ）は、第１の第三者公開鍵（Ｐ１Ｔ）および第１の第三者秘密鍵（Ｖ１Ｔ）を含む非対称暗号ペアの一部である。

【0034】

本開示の実施形態は、さらに、上述の方法を実行するように動作可能である、プロセッサまたはプロセッサのグループに関する。

【0035】

本開示の実施形態は、また、実行されると、上述の方法を実行するように動作可能なインストラクションを保管したコンピュータ可読媒体に関する。

【0036】

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

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

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

【0037】

１つの態様または実施形態に関連して上述された任意の特徴は、あらゆる他の実施形態または態様に関して使用することができる。本発明の方法に関連して言及されたあらゆる特徴は、対応する実施システムについて同様に適用することができ、その逆も同様である。

【図面の簡単な説明】

【0038】

本開示に係る実施形態が、添付の図面を参照して、非限定的な実施例だけによって、これから説明される

【図1】図１は、本開示に係る一つの実施形態に従った、システムの模式図である。

【図2】図２は、図１に係るシステムのユーザによって実行されるプロセスのフローチャートである。

【図3】図３は、交換サービスプロバイダによって実行されるプロセスを説明するフローチャートである。

【図4】図４は、交換サービスプロバイダによって生成されるインビテーション（invitation）のためのメタデータフォーマットを説明する表である。

【図5】図５は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。

【図6】図６は、図１に係るシステムの２人またはそれ以上のユーザからのインビテーションを一致させる（matching）プロセスを説明するフローチャートである。

【図7】図７は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。

【図8】図８は、図１に係るシステムに対する当事者間におけるトランザクションを説明する取引図である。

【図9】図９は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。

【図10】図１０は、図１に係るシステムに対する複数の当事者間における複数のトランザクションのためのトランザクションテーブルである。

【図11】図１１は、交換サービスプロバイダによって実行されるプロセスを説明するフローチャートである。

【図12】図１２は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。

【図13】図１３は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。

【図14】図１４は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。

【図15】図１５は、交換サービスプロバイダによって生成されるインビテーションのためのメタデータフォーマットを説明する表である。

【図16A】図１６Ａは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。

【図16B】図１６Ｂは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。

【図16C】図１６Ｃは、図１に係るシステムに対する２人の当事者間におけるトランザクションのためのトランザクションテーブルである。

【発明を実施するための形態】

【0039】

別の人の銀行口座への支払い又は外貨両替といった、一般的な金融取引（financial transaction）を実行する最先端の方法は、取引手数料および時間遅延の両方においてコストを招く。対照的に、ビットコインといった電子通貨における取引は、はるかに速いレート（rate）で（すなわち、数日ではなく数分）、そして、非常に低いコスト（取引き毎に数十ドルではなく数セントのオーダー）で処理することができる。

【0040】

金融上および非金融上の両方において、日常の取引（day-to-day transactions）に係る恒久的な記録を実行して、保持する、より迅速かつ安価な方法に対する必要性が存在している。本発明は、金融アプリケーションとの使用または利点に限定されなるものではないことに留意することが重要である。代わりに、本開示は、ビットコインブロックチェーンといった、P2P分散型台帳を利用するためのコンピュータで実施される方法およびコンピュータシステムに関し、当事者が、エンティティの交換を提供し、そして、あらゆるタイプの価値エンティティ（entity of value）であり得るエンティティの交換を記録することを可能にする。ここにおいて説明される典型的な方法は、エンティティの交換を実行するためのインビテーション（invitation）またはオファー（offer）を指示するスクリプトの生成に関する。さらに、ここにおいて説明される方法は、別のスクリプトに対するスクリプトのマッチングの際、エンティティの実際の交換に係るエンアクトメント（enactment）に関する。

【0041】

ビットコインブロックチェーンといった、P2P分散型台帳を利用することによって、本開示に係る実施形態は、保持されるべき交換プロセスに係る全てのステップの恒久的な記録を提供する。さらに、プロセスにおける各段階（オファーおよび交換）は、仮想通貨のトランザクションにおいて使用されるものと同様な暗号化ロック技術（locking techniques）を使用してセキュアにすることができる。「仮想通貨（”cryptocurrency”）」により、これに限定されるわけではないが、ビットコインといった、暗号化された電子的に移転可能なデジタルアセットを意味している。

【0042】

ここにおいて説明される例示的な方法は、あらゆるタイプのエンティティを提供し、かつ、交換するために使用することができる。そうしたエンティティの例は、これらに限定されるわけではないが、ビットコインといった、仮想通貨、不換通貨（fiat currencies）、コントラクト、商品（goods）、およびサービスを含んでいる。

ブロックチェーン技術の使用を取り込んでいるCoinffeine（http://www.coinffeine.com/）といった交換が、当技術分野で知られている。しかしながら、そうした従来技術の構成（arrangement）は、未だに従来のモデルに依拠しており、そして、また、動作するために、第三者ソース、エスクロー（escrows）、および、他のマルチ通貨非銀行口座／プロセッサにも依拠している。これらの既知の構成は、（本発明による）技術革新および暗号技術を通じてではなく、むしろ、ビジネスモデルを通じて分散化（decentalisation）を達成している。
本発明は、トークナイゼーション技術（tokenisation techniques）の使用を組み込んでいる。コントラクトは、交換のためにオファーされるか、または、トークンのおかげで交換され得る。

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

交換サービスプロバイダ104の１つの目的は、P2P DHT及び／又はP2P DLにおいてインビテーションまたはエンティティの交換にためのオファーを置く（place）ためにユーザ106、108のためのゲートウェイを提供することである。ネットワーク102のユーザ106、108は、それ自体、P2P DHT及び／又はP2P DLにインビテーションを置くことができるが、交換サービスプロバイダ104は、インターフェイスを提供し、それを用いてインビテーションが生成される。さらに、交換サービスプロバイダ104は、当業者であれば理解するように、ビットコインブロックチェーンといった、分散型台帳におけるトランザクションの直接的な取り扱いに関連する危険（例えば、トランザクションの喪失、等）を低減することができる。P2P DHT及び／又はP2P DLにおけるユーザインビテーションの発行を可能にすることに加えて、交換サービスプロバイダは、以下の追加サービスのうち１つまたはそれ以上を実行することができる。
・インビテーションのマッチング（Matching invitations）− 上述のように、インビテーションは、ａ）ユーザが交換することを望むエンティティの詳細、ｂ）交換に添付された、ロケーション条件といった、１つまたはそれ以上のユーザ適用オプション／条件、を含んでよい。２つのインビテーションは、それぞれのエンティティの詳細がミラーリングされており（mirrored）、かつ、２つのインビテーションの条件のうち１つまたはそれ以上が適合する場合に、一致し得る。別の言葉で言えば、第１インビテーションの中に含まれる一つまたはそれ以上のパラメータまたは特徴が、また、第２インビテーションの中にも含まれている場合に、一致が生じ得る。一つまたはそれ以上のインビテーションの特徴の間にはいくつかの共通性が存在している。ミラーリングされたエンティティの詳細の例は、第１ユーザ（アリス（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 DHTで既に公開されているインビテーションを有する必要があることに留意する。しかしながら、全てのインビテーションがP2P DHTにおいて公開されることを要するとは限らない。この実施例において、例えば、サービスプロバイダは、所望の一致が既に見つかっているときにインビテーションが広告される（advertised）必要が存在しないので、P2P DHT上でオファーを公開する必要はない。しかしながら、例えば、最初のマッチングが失敗に終わる場合に、生成されたインビテーションは、未だにP2P DHT上に置かれてよいことが正しく理解されよう。

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

・条件成就の確認（Verifying fulfilment of conditions）− インビテーションが、ロケーション条件といった、条件を含む場合に、交換サービスプロバイダ104は、交換を確定する以前に、条件が満足されているか否かを判断することができる。ロケーション条件に関して、交換サービスプロバイダ104は、例えば、２つのインビテーションが一致したときにユーザの現在の位置を決定することができる。
・ｅウォレットサービス（eWallet services）− 上記に加えて、サービスプロバイダ104は、また、仮想通貨の鍵、等の保持といった、従来のｅウォレットサービスを提供することもできる。

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

引き換えスクリプトの中に、インビテーションの条件、トークンに関連するコントラクトの詳細、及び／又は、交換に関連する他の情報に対応するメタデータを置くことによって、そうした情報のハッシュは、P2P分散型台帳の中に含まれる。

【0067】

この埋め込み方法は、次のように要約できる。
仮想通貨の一部に関する出力（TxO）および引き換えスクリプトのハッシュを有するブロックチェーントランザクション（Tx）を生成することであり、Txは、
トークン化されたエンティティの表現、または参照である、トークンを含むメタデータ、および、
少なくとも１つ（好ましくは２つまたはそれ以上の）公開暗号鍵、を含む。
トークン化されたエンティティは、交換に関するコントラクト及び／又は他のエンティティとすることができる。メタデータは、暗号鍵のためのプロトコルによって指定されたロケーションにおいて提供される。

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

本開示の実施に係るいくつかの例が、第１ユーザ106（ここにおいてはアリス（Allice）と呼ばれる）と第２ユーザ（ここにおいてはボブ（Bob）と呼ばれる）との間のオファーおよびトランザクションの例としてこれから説明される。

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

引き換えスクリプトは、次いで、署名のためにアリスへ送付される。アリスから署名された引き換えスクリプトを受け取ると、ステップ３０８において、サービスプロバイダ104は、署名された引き換えスクリプトのハッシュを生成する。

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

各トランザクションに対するサービスプロバイダ104の料金は、トランザクションの値のスライス（slice）であってよい。代替的または追加的に、料金は、２つのインビテーションにおいて示された対応するレート条件間に広がる交換レートのスライスであってよい。例えば、オファーされたレートがオーバーラップする場合に、サービスプロバイダ104は、交換に係る両面をそれぞれの提示レート（asking rate）で遂行し、そして、差を料金として保持することができる。代替的または追加的に、サービスプロバイダ104によって、フラットな料金（サトシ、トークン化された通貨、またはその他におけるもの）が取られてよい。

【0094】

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

【0095】

上記の例のトランザクションにおいて、パズル（puzzle）は交換されない。別の言葉で言えば、２つのトランザクション（アリス−ボブとボブーアリス）は完全に分離された、別々のものである。しかしながら、ある場合には、２つのトランザクションについて有効または無効のいずれかであることが望ましい。図９は、アリスのトランザクション（アリス− ボブ）においてパズルが交換される代替的なトランザクションの例を示している。そうすることによって、２つのトランザクションは一緒にロックされ、他方を費やすことなく、一方を費やすことはできない。このことは、相手方のトランザクションも通過することなく、一方の当事者から別の当事者へのトランザクションが通過することを防止する。

【0096】

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

【0097】

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

【0098】

インビテーションを置くこと（Posting an invitation）

【0099】

第３実施例においては、ボブが、特定の量のビットコインについて金塊（gold nugget）の交換をオファーする。彼のオファーを発行するために、ボブは第１の第三者（a first third party）、この事例においては彼の交換サービスプロバイダ104、とコンタクトをとる。この特定の例において、交換サービスプロバイダ104は、ボブの携帯電話において動作するソフトウェアアプリケーションによって実装される通信インターフェイスを提供する。従って、ボブは、図１１に示されるプロセス700を参照してより詳細に以下に説明されるように、彼の携帯電話におけるソフトウェアアプリケーションを使用して金塊の交換について彼のオファーを入力することができる。

【0100】

図１１に示すように、ステップ７０２において、ボブは、彼の携帯電話上で交換サービスプロバイダ104のソフトウェアアプリケーションにログオンし、そして、ステップ７０４および７０６において、アプリケーションの中へ彼のオファーの詳細を入力する。この特定の例におけるオファーの詳細は、交換のために提供されるエンティティを含んでいる。すなわち、金塊、金塊と引き換えに期待されるビットコイン量、およびロケーション条件、である。

【0101】

ロケーション条件は、以下の情報のうち１つまたはそれ以上を含んでよい。
ａ）金塊の交換のための地理的ロケーションまたはエリアを示すロケーション情報、
ｂ）ロケーション情報のフォーマットを示すロケーションフォーマット情報、
ｃ）交換に関連する地理的ロケーションまたはエリアにおける範囲制限を示す範囲情報、および、
ｄ）範囲情報のフォーマットを示す範囲フォーマット情報、である。

【0102】

この特定の例において、ボブのオファーのロケーションは、ボブの店「ゴールドエンポリアム（”the Gold Emporium”）」から２０メートルの範囲として定義されるエリアを指定している。２０メートルの範囲は、指定されたエリアにおけるボブの携帯電話によるGPS読み取りの正確さに対する既知の限界を許容するように指定することができる。しかしながら、範囲は、様々な理由で特定され得ることが正しく理解されよう。例えば、ロケーション条件は、交換が行われる必要がある国または都市を指定することができる。

【0103】

ボブは、彼のサービスプロバイダ104のソフトウェアアプリケーションによってホストされているインターフェイスの中へ上記の情報を入力することができる。例えば、サービスプロバイダ104によって、次いで、有効なオファーへと翻訳され得る通常の言語を使用するものである。または、代替的に、ボブは、例えば、ドロップダウン選択メニューを介して、事前選択のオプション（pre-selecting options）によって情報を簡単に入力することができる。

【0104】

ステップ７０８においては、ボブの公開鍵、および、交換のためにボブがオファーしているエンティティに関する情報とオファーに関連付けられた上記のロケーション条件を含むあらゆる条件とを含むボブの選択、を使用して、引き換えスクリプトが生成される。ボブの公開鍵は、秘密鍵と公開鍵とを含む非対称暗号ペア（asymmetric cryptographic pair）の一部である。加えて、生成された引き換えスクリプトは、サービスプロバイダ104の公開鍵である、さらなる公開鍵を含んでいる。

【0105】

ステップ７１０において、ソフトウェアアプリケーションは、ボブが、上記の公開鍵に対応する彼の秘密鍵を用いて、生成された引き換えスクリプトに署名することを促進する。生成された引き換えスクリプトは、P2SHビットコイントランザクションについて適したフォーマットであってよい。インビテーションの詳細は、上述のように、マルチシグロック解除スクリプト（multisig unlocking scripts）において通常使用される３２バイトの公開鍵の代わりに、メタデータフィールドに保管されてよい。

【0106】

ステップ７１２においては、署名された引き換えスクリプトのハッシュが生成される。ステップ７１２において、ハッシュと一緒にスクリプトが公に利用可能なP2P DHT上で発行される。上述のように、この表はトレント技術を採用しているので、集中化されるのではなく、むしろ分散されており、そして、従って、公にアクセス可能なままであり、かつ、変更から安全である。インビテーションは、他のユーザや交換サービスプロバイダによってアクセスされ得る。

【0107】

図１２は、一つの実施形態に従って、ボブのスクリプトのメタデータのフォーマットを示している。スクリプトのインビテーションにおいて、ボブは、金塊と交換にビットコインを要求している。より詳細に以下で説明するように、図１２は、また、インビテーションに対して追加される上述のロケーション条件も示している。

【0108】

P2P交換モデル（P2P Exchange model）における条件メタデータブロック（condition metadata blocks）の一般的なフォーマットが、図１３に示されている。メタデータブロックは、３２バイト長である。条件メタデータブロックの最初の２バイトは、分散ハッシュテーブルといった別個のルックアップテーブルを介して指定されるように、条件を定義する数値コードである。条件メタデータブロックの残りの３０バイトのためのフォーマットは、条件に依存するものである。

【0109】

図１２におけるボブのスクリプトに対する例に示されるように、この特定のシナリオにおけるロケーション条件には、値０００４が割り当てられている。

【0110】

ロケーション条件コードの一般的なフォーマットが図１４に示されている。フィールドについての説明は、以下のとおりである。

【0111】

認識されるように、ロケーション条件は異なるフォーマットにおいて指定することができる。特定の、非限定的ないくつかの例が以下に示されている。

【0112】

上述のように、ロケーション条件は、さらに、指定されたロケーションからの範囲を指定することができる。この範囲は、GPS読み取りの正確さに対する既知の限界を許容することができ、または、交換が確定されるためにエンティティの交換が行われることを要するエリアを定義することができる。範囲コードのフォーマットについて、いくつかの例が以下に示されている。

【0113】

オファーのマッチング（Matching an Offer）

【0114】

上記の第３実施例を参照する第４実施において、アリスは、P2P DHTにおいてボブのオファーを見て、金塊を検査するためにボブのスクリプトのロケーション条件において指定されているようにボブのゴールドエンポリアムへ行く。

【0115】

金塊を検査し、そして、金塊と交換するビットコインの量を交渉して、アリスは、彼女の携帯電話で動作するソフトウェアアプリケーションを使用してマッチングオファーを作成する。特に、ソフトウェアアプリケーションは、交換されるエンティティの詳細、すなわち、交渉されるビットコイン量と交換される１つの金塊、をアリスが入力することを促進する。入力された詳細を使用して、アリスのための引き換えスクリプトが生成され、それは、次いで、ハッシュ化され、そして、P2P DHTにおいて引き換えスクリプトのハッシュと共に発行される。アリスのオファーのメタデータが、図１５に示されている。

【0116】

この特定の実施例において、図１２に示されるボブのスクリプトは、交換を確定させるためのビットコインの最小レートまたは最高レートを指定していない。従って、ボブのオファーとアリスのオファーとの間の一致を特定するために、交換サービスプロバイダ104が、上述のようにマッチングアルゴリズムを実行する場合に、ボブは、アリスのオファーを受諾するオプションが与えられる。

【0117】

この特定の実施例において、アリスのスクリプトとボブのスクリプトのマッチングのプロセスは、さらに、図１２に示されるようなボブのスクリプトにおいて指定されたロケーション条件が満足されることを検証するステップを含む。この検証ステップは、様々な方法で実行されてよい。

【0118】

例えば、交換サービスプロバイダ104は、ボブの携帯電話及び／又はアリスの携帯電話と通信して、携帯電話の位置を決定することができる。このロケーションは、次いで、ボブのスクリプトのロケーション条件において指定されるロケーションおよび範囲と比較され得る。

【0119】

ロケーションが、ボブのゴールドエンポリアムといった、建物名として指定されている場合に、交換サービスプロバイダ104は、専有の（proprietary）データベース、または、Googleマップといった、さらなるソフトウェアアプリケーションと通信することによって、このロケーションに関するGPS座標を判断することができる。判断されたGPS座標は、ボブの携帯電話またはアリスの携帯電話のGPS座標と比較され得る。

【0120】

さらなる実施例において、交換サービスプロバイダ104は、ロケーション条件が満足されることを確認するために、ボブ及び／又はアリスによる手動の入力を促進することができる。このステップは、例えば、アリスのオファーを受諾するステップと一緒に行われてよい。

【0121】

ロケーション条件が満足されていると分かった場合に、交換サービスプロバイダ104は、アリスとボブとの間でトランザクションを作成し、かつ、確定しようと試みる。一つの例においては、トランザクションブロードキャスト（transactional broadcast）の位置が指定された座標のＸメートル以内である場合に、トランザクションは、P2P DL上にだけブロードキャストされる。このことは、トランザクションが指定された場所、例えば、ボブのゴールドエンポリアム、でだけ行われる得ることを保証する。

【0122】

最終的な交換は、図２から図１０に示される第１および第２の実施例を参照して説明したように、各インビテーショントランザクションの出力を費やす１つまたはそれ以上のビットコイントランザクションを作成することによって実行することができる。

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

商品／サービスの交換

【0135】

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

【0136】

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

【0137】

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

【0138】

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

【0139】

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

【0140】

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

【0141】

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

【0142】

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

【0143】

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

【0144】

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

【0145】

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

【0146】

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

【0147】

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

【0148】

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

【0149】

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

【0150】

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

【0151】

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

【0152】

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

【0153】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図16C】