▶ エリス デジタル ホールディングス、エルエルシーの特許一覧
特表2022-548429ブロックチェーンによって統合された暗号難易度を基にした金融商品の電子取引及び決済システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-11-18
(54)【発明の名称】ブロックチェーンによって統合された暗号難易度を基にした金融商品の電子取引及び決済システム
(51)【国際特許分類】
G06Q 20/38 20120101AFI20221111BHJP
【ＦＩ】
G06Q20/38 310
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022534630
(86)(22)【出願日】2020-12-09
(85)【翻訳文提出日】2022-08-02
(86)【国際出願番号】 US2020064130
(87)【国際公開番号】W WO2021119210
(87)【国際公開日】2021-06-17
(31)【優先権主張番号】62/945,505
(32)【優先日】2019-12-09
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】522226269
【氏名又は名称】エリス デジタル ホールディングス、エルエルシー
(74)【代理人】
【識別番号】100103137
【弁理士】
【氏名又は名称】稲葉 滋
(74)【代理人】
【識別番号】100145838
【弁理士】
【氏名又は名称】畑添 隆人
(74)【代理人】
【識別番号】100216367
【弁理士】
【氏名又は名称】水谷 梨絵
(72)【発明者】
【氏名】トルドー、マシュー
(72)【発明者】
【氏名】マクグロン、ジョゼフ
(72)【発明者】
【氏名】チッパス、トーマス
【テーマコード（参考）】
5L055
【Ｆターム（参考）】
5L055AA21
(57)【要約】
原資産である暗号通貨の現物受渡を用いて、暗号難易度を基にした金融商品の確立と取引を可能にする金融商品取引システムが提供される。暗号難易度を基にした金融商品は、暗号通貨のブロック当たりの所定の報酬と、所定のハッシュレートと、所定の金融商品の長さと、原資産である暗号通貨の所定のナンス値と、原資産である暗号通貨によって採用されている現在の難易度とを含む期待価値に基づいており、難易度が変わるにつれて変わり得る。清算機関決済システムは、金融商品の評価における日々の変動証拠金を計算し、変動証拠金を満たすように、原資産である暗号通貨の現物受渡を提供する。
【特許請求の範囲】
【請求項1】
原資産である暗号通貨に基づく、暗号難易度を基にした金融商品であり、Rは現在の期待価値であり、
Bは暗号通貨のブロック当たりの所定の報酬であり、前記原資産である暗号通貨のブロックインターバルに対してブロックチェーンプロトコルにより定義され、
Hは所与のハッシュレートであり、
Sは所定の計算期間の秒単位の長さであり、
Ｄは前記原資産である暗号通貨のブロックチェーンプロトコルによって定義された現在の難易度であり、
Nは前記原資産である暗号通貨のブロックチェーンプロトコルによって定義されたナンス値の範囲である、暗号難易度を基にした金融商品と、
上記で決定された前記暗号難易度を基にした金融商品の期待価値を格納する決済データベースを備えるコンピュータ決済システムであって、前記暗号難易度を基にした金融商品の現在の期待価値を決定するために前記暗号難易度を基にした金融商品の前記期待価値を再計算するコンピュータ決済システムを備える電子清算機関であって、前回の期待価値と前記現在の期待価値との差が変動証拠金を構成する電子清算機関と、
前記暗号難易度を基にした金融商品に関する顧客取引データを含む顧客口座を含むポジションデータベースを備える電子清算機関と、を備え、
前記顧客取引データが、前記顧客口座が前記暗号難易度を基にした金融商品にショートであることを示し、且つ、前記変動証拠金がポジティブである場合、前記電子清算機関は、前記変動証拠金に等しい量の前記原資産である暗号通貨の現物受渡を、前記顧客口座に要求する、
金融商品取引システム。
【請求項2】
前記原資産である暗号通貨は、ビットコインである、請求項１に記載のシステム。
【請求項3】
Hの値は、100TH/sである、請求項１に記載のシステム。
【請求項4】
Sの値は、1,209,600である、請求項１に記載のシステム。
【請求項5】
Nの値は、4,294,967,296である、請求項１に記載のシステム。
【請求項6】
前記前回の期待価値は、前記現在の難易度とは異なる前回の難易度を使用して決定される、請求項１に記載のシステム。
【請求項7】
前記コンピュータ決済システムは、前記暗号難易度を基にした金融商品の前記期待価値を所定の頻度で再計算する、請求項１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、2019年12月9日に出願された「ブロックチェーンによって統合された暗号難易度を基にした金融商品の電子取引決済システム」と題する米国仮特許出願第62/945,505号の利益を主張するものであり、その全体を参照により本明細書に援用する。
【背景技術】
【0002】
本発明は、一般に、暗号通貨取引システムに関する。より詳細には、本発明は、暗号通貨の現物受渡を含む暗号通貨取引システムに関する。
【0003】
暗号通貨は、価値の保存又は交換媒体として使用され得るデジタル資産であり、通常、分散型ネットワークを使用してトランザクションを記録する。暗号通貨が動作する分散型ネットワークは、一般的にブロックチェーンベースの技術である。ブロックチェーンは、一連の不変なトランザクションで、ブロックのチェーンであり、ユーザのネットワーク間で共有され、分散台帳と呼ばれることもある。分散台帳は、パブリックまたはプライベートのいずれかである。プライベート分散台帳では、通常お互いを知っていて信頼している指定されたネットワーク参加者によって全てのトランザクションが検証され、ネットワークへのアクセスは、中央の信頼できる１又は複数の機関によって制御され得る。パブリック分散台帳は、誰がネットワークに参加してトランザクションを検証できるかに制約がなく、一般に、担当する人や団体がいない台帳である。パブリック台帳のトランザクション検証者は、しばしばマイナーと呼ばれ、何らかの形の報酬と引き換えにトランザクションを検証するために互いに競い合う。
【0004】
ネットワーク参加者の間でトランザクションが検証および確認されるためには、トランザクションのグループ即ち「ブロック」がチェーンに追加される前に、ネットワークはコンセンサスに達しなければならない。参加者がコンセンサスに達するメカニズムの目標は、台帳の状態及びどのトランザクションが正当であるかについて全員が合意できる明確なルールセットを持つことである。今日、いくつかのコンセンサスメカニズムが存在するが、一般的なコンセンサスメカニズムの1つは、プルーフ・オブ・ワーク(PoW)である。
【0005】
所与のブロックチェーンソフトウェアを実行するネットワーク上のコンピュータは、ノードとも呼ばれる。PoWモデルでは、これらのノードは、数学的問題の解を見つけることでトランザクションのブロックをブロックチェーンに追加することを競い合い、解を見つけたときに仕事の見返りに報酬を得ている。報酬は、新たに生成される暗号通貨であり、このプロセスはマイニングとも呼ばれる。これらの努力により、ブロックチェーンが安全でかつすべてのネットワーク参加者間で同期されることが保証される。
【0006】
マイニングのプロセスは、かなりの量の問題の解を高速で推測することができる特殊なコンピューティングハードウェアを必要とするように進化してきた。これらのマシンが解決しようとしている数学的問題は、トランザクションのブロックに暗号化ハッシュアルゴリズムを適用することを必要とする。ビットコインのSHA-256、ライトコインのscrypt、イーサリアムのEquihashなど、今日ブロックチェーン全体で使用されている様々なハッシュアルゴリズムがある。ブロックがブロックチェーンソフトウェアに埋め込まれていることを確認するのに平均してかかる時間は、ネットワークのスピードと安定性を維持するように設計されている。
【0007】
マイニングノードは、マイナーとも呼ばれ、独自にトランザクションを選択してグループ化し、ブロックを形成する。ブロックの内容を要約するブロックヘッダが追加され、これには、通常、次のようなデータ構成要素を含む。
【0008】
バージョン：ソフトウェア/プロトコルのバージョン番号
【0009】
１つ前のブロックのハッシュ：チェーンにおける１つ前のブロックへの参照
【0010】
マークルルート：候補ブロック内の全てのトランザクションのハッシュ値
【0011】
タイムスタンプ：ブロック作成時刻
【0012】
難易度ターゲット(difficulty target)：ブロックのハッシュが下回らなければならない可変閾値
【0013】
ナンス：許容可能なハッシュ値を達成するために変更される変数
【0014】
これらのブロックの1つをブロックチェーンに追加する際の課題は、難易度ターゲットのレベルよりも低い数値であるブロックヘッダデータのハッシュ値を見つけることを必要とするプルーフ・オブ・ワークアルゴリズムを解くことである。全てのヘッダデータ構成要素は、ナンスを除いて定数である。マイナーは、ナンス値を段階的に変更し、難易度ターゲットを下回るハッシュ値を達成するまでブロックヘッダデータをハッシュ関数に通し、その時点で、マイナーは「作業」を実証することができる。他のノードは、その作業の証明に基づいて、ブロックを受け入れ、チェーンに追加することができる。ビットコインのナンスは、例えば、32ビットのフィールドであるため、0～4,294,967,295の間の任意の整数を含むことができる。
【0015】
マイナーは、自身のノードを有益に運営するために、複数の不確実性に直面する。第一に、マイニングの成功は確率的であり、決定論的ではなく、即ち、実際のマイニング報酬は期待される報酬を上回ることも又は下回ることもあり得る。報酬自体は決定論的であるが、報酬の獲得は宝くじのようなもので、オッズ によって決まるー時間の経過につれて、これらは標準分布の周りに収束するはずである。第二に、暗号通貨の報酬が評価されたフィアット通貨換算額は、価格が変動するにつれて、現在の価値又は期待値を上回ることも又は下回ることもあり得る。第三に、ネットワークのハッシュレート、即ちオンラインの処理能力の尺度は、ネットワークに出入りするノードの数によって大きく変動する可能性がある。
【0016】
上記の全ての変数は、相互に関連しており、ブロックをマイニングするオッズ、報酬の価値、及びブロック確認時間、ひいては将来の難易度ターゲットに影響を与えるフィードバックメカニズムを作成する。
【0017】
マイナーが収益性を判断する際に考慮する様々な要因がある。彼らのコストは、フィアット通貨で支払わなければならない、マイニングハードウェアやそれらを収容するスペースなどの資本的支出と、人員配置、電気などの運営支出とを含むものとしてかなりよく理解されているかもしれない。前述のように、マイナーは、期待される将来のフィアット収入に対して様々な不確実性に直面する。しかし、2つの重要な不確実性には、1)最終的に生産する暗号通貨の量と、2)その生産物を取得した時に直ぐに売り得る価格が含まれる。
【発明の概要】
【0018】
本発明の1つ以上の実施形態は、原資産である暗号通貨の現物受渡を用いて、暗号難易度を基にした金融商品の確立と取引を可能にする金融商品取引システムを提供する。暗号難易度を基にした金融商品は、暗号通貨のブロック当たりの所定の報酬と、所定のハッシュレートの量と、所定の金融商品の長さと、所定のナンス値の範囲と、原資産である暗号通貨によって採用されている現在の難易度(difficulty level)とを含む期待価値に基づいており、難易度(difficulty level)が変わるにつれて変わり得る。取引システムは、金融商品の評価における日々の変動証拠金を計算し、変動証拠金を満たすように、原資産である暗号通貨の現物受渡を提供する。
【図面の簡単な説明】
【0019】
【図1】本発明の一実施形態に係る契約リスティングシステム100を示す。
【図2】例示的な契約データを含むリスティングを構成する個々の契約リスティングデータ構造の例を示す。
【図3】本取引システムの口座資金調達処理を示す。
【図4】本取引システムの暗号通貨預金処理を示す。
【図5】本発明の一実施形態に係る取引及び清算システムを示す。
【図6】本発明の一実施形態に係るマーク・トゥ・マーケット・システムを示す。
【図7】本発明の一実施形態に係る最終決済システムを示す。
【発明を実施するための形態】
【0020】
上述のように、マイナーは、彼らの期待される将来のフィアット収入に対して、1)彼らが最終的に生産する暗号通貨の量、及び2)その生産物を取得して直ぐに売り得る価格を含む、様々な不確実性に直面する。一方で、マイニングは、商品としての暗号通貨の生産と見なすことができる。従って、今日の伝統的な商品生産者と同様に、マイナーは、リスク管理システムを高く評価し、彼らの業務に組み込み、これらのリスクに対処することができる。
【0021】
本発明の一実施形態は、所与のPoWブロックチェーンについて公開された、推定対実観測難易度に基づいて、暗号通貨の交換及び受渡を容易にする、コンピュータで実行する方法を提供する。
【0022】
本発明の実施形態は、取引所取引型中央清算システムにおいて説明されるが、取引所及び取引プラットフォーム等の用語は、商品、デリバティブ、有価証券及びその他の金融商品が取引される市場を広く指し、適用免除取引所、指定契約市場、指定清算機関、証券取引所、スワップ執行ファシリティ、電子通信ネットワーク等を含むが、必ずしもこれらに限定されない。
【0023】
本発明は、ビットコイン、イーサリアム、ビットコインキャッシュ及びライトコインを含むがこれらに限定されない全てのPoW暗号通貨に用いられ得る。また、マイニングまたはコンセンサスに達する同様のプロセスを通じて追加の暗号通貨を生成するという概念を持つ、あらゆる全ての暗号通貨にも適用できる。
【0024】
難易度(difficulty level)は、指定されたブロック数の後に決定論的にリセットされる。例えば、ビットコインの難易度リセットは、2,016ブロックごとである。難易度ターゲット(difficulty target)が変化し、ゆえに、対応する、ハッシュパワーの単位当たりのブロック報酬を獲得する期待オッズが減少すると、本発明は、買い手と売り手が、最初の推定報酬と更新されたオッズに基づく予想報酬とに基づいて、原資産である報酬資産の差を交換することを可能にする。他の全てが等しい場合、難易度(difficulty)が上がるにつれ、ハッシュパワーの所与の単位のブロック報酬を獲得する期待オッズは減少し、ゆえに買い手は売り手から報酬値の差をコインで受け取り、難易度(difficulty)が減少した場合はその逆である。
【0025】
図1は、本発明の一実施形態に係る契約リスティングシステム100を示す。一般に、契約リスティングシステム100では、契約リスティングを構成する個々の契約リスティングデータ構造が、仕様に従って作成され、契約データが入力され、後述するように後の取引のためにリファレンスデータベースに追加される。さらに、以下の図2は、例示的な契約データを含むリスティングを構成する個々の契約リスティングデータ構造の例を示す。
【0026】
一実施形態では、各契約リスティングのデータは、その作成時に契約リスティングデータ構造に定義され、固定される。さらに、リファレンスデータベースは、契約仕様に対応するフィールドのセットを含むように設計されている。以下でさらに説明するように、第1の実施形態では、契約リスティングを構成するデータ構造が作成され、取引所リファレンスデータシステム127のリファレンスデータベースに追加されてもよく、一方、第2実施形態では、契約リスティングを含むデータ構造が作成され、清算機関リファレンスデータシステム150のリファレンスデータベースに追加されてもよい。
【0027】
より具体的には、1人以上の管理者105は、ユーザインタフェースを介して契約データを入力し得る。ユーザインタフェースは、モバイルアプリケーション111、ウェブブラウザ112、または管理アプリケーション113のいずれかによって提供されてもよく、これらの各々は、サポートされ得るが、それら独自のアプリケーションプログラミングインタフェース(API)115－117である。個々のAPIを図1に示すが、各APIは1つ以上のAPIであってよい。その後、契約データ110は、インターネットまたはプライベートネットワーク120を通過し、取引所リファレンスシステム127及び清算機関リファレンスシステム150にインターフェースすることができるAPI122を通過することができる。
【0028】
一実施形態では、契約データ125は、取引所リファレンスシステム127のリファレンスデータシステム130に渡される。リファレンスデータシステム130において、管理者105は、リファレンスデータシステム130に契約リスティングデータ構造を作成するよう指示し、次に、例えばリファレンスデータシステム130に送信されたデータをユーザインタフェースを介して入力することによって、以下の図2の例に示すように、契約リスティングデータ構造の各データフィールドに手動で入力する。契約リスティングデータ構造に契約データが入力されると、契約リスティングデータ構造は、契約データ134としてリファレンスデータデータベース136に送信され、格納される。
【0029】
取引所リファレンスシステム127はまた、契約自動生成システム132を含む。契約自動生成システム132において、契約リスティングデータ構造は、契約自動生成システム132にプログラムされた所定の仕様および/またはスケジューリングに従って自動的に作成されてもよい。例えば、以下の図2に示す契約リスティングデータ構造のデータフィールドについて、契約自動生成システム132は、以下の図２に示すように、暗号通貨データフィールド210に対してビットコイン(BTC)等、契約サイズデータフィールド220に対して100(TH/s)等、価格提示形式データフィールド230に対してGH等、最低価格増分データフィールド240に対して10GH等、満期日フィールド260に対して12リセット等、決済方法データフィールド260に対して現物決済等、及び決済手順データフィールド270に対して日変動証拠金の交換や難易度に応じた最終決済等の、固定された所定値を用いて契約リスティングデータ構造を自動的に生成してもよい。スケジューリングの面に関しては、一例では、契約自動生成システム132は、12回のリセット毎、即ちBTCブロックチェーンの24,192ブロック毎に、契約リスティングデータ構造を作成し、入力してよい。さらに、契約自動生成システム132は、特定の暗号通貨に対して異なるサイズおよび頻度の契約リスティングデータ構造を作成し、入力するようにしてもよい。また、契約自動生成システム132は、個々の暗号通貨ごとに異なる契約データを有する異なる契約リスティングデータ構造を生成してもよい。契約自動生成システムにより契約リスティングデータ構造が生成されると、契約リスティングデータ構造は、契約データ134としてリファレンスデータデータベース136に送信され、格納される。
【0030】
追加の実施形態では、契約自動生成システム132は、契約リスティングデータ構造を自動的に生成し、それに契約データを取り込むことができる。その後、契約リスティングデータ構造は、リファレンスデータシステム130に渡されることができる。リファレンスデータシステム130において、契約リスティングデータ構造および/または契約データは、レビュー、修正、および/または承認のために管理者105に送信されてもよい。契約リスティングデータ構造が管理者によって承認されると、契約リスティングデータ構造は、契約データ134としてリファレンスデータデータベース136に送信され、格納される。
【0031】
次に、取引所契約リスティングスケジューラシステム138において、リファレンスデータデータベース136に格納された契約データ構造は、取引に利用可能となるように、取引システム142にリスティングするようスケジュールされる。取引所契約リスティングスケジューラシステム138において、ソフトウェアは、契約状態に基づいて、契約情報140をネットワークを介して取引システム142に公開するようリファレンスデータシステムに指示する。契約リスティングスケジューラシステム138は、契約ライフサイクルを通じて契約状態が変化するイベントを定義するデータを含むスケジュールデータベースを含む。一実施形態では、契約ライフサイクルは、以下のように進行する：リスティング、最初の取引、最後の取引、満期、およびデリスティング。一実施形態では、各状態またはイベントは、指定された日時、例えば2019年11月11日午後4時中部標準時(CT)であってもよい。別の実施形態では、各状態またはイベントは、指定されたブロックチェーンブロック高、例えばブロック600,768であってもよい。
【0032】
取引所契約リスティングスケジューラシステム138の一実施形態では、管理者105は、管理者ユーザインタフェース(UI)を使用して、スケジュールプロファイルデータを作成し、スケジュールデータベースに追加し得る。別の実施形態では、取引所契約リスティングスケジューラシステム138は、事前に定義された仕様のセットに基づいて、スケジュールプロファイルデータを自動的に作成しスケジュールデータベースに追加し得る。例えば、取引所契約リスティングスケジューラシステム138は、リファレンスデータデータベースから契約リスティング仕様を取得し、契約リスティング仕様に基づいてイベントをスケジュールすることができる。例えば、取引契約リスティングスケジューラシステム138は、契約データ構造から満期日データフィールド260を取得し、満期データを使用して、リスティング、最初の取引、最後の取引、およびデリスティングの日付をスケジュールすることができる。
【0033】
一実施形態では、契約リスティングデータ構造は、それらが取引のために上場されている規定期間及び満期についてのデータを有し、それらは作成時にリファレンスデータデータベースに記録される。一実施形態では、これらのデータは、例えば毎週、毎月、四半期ごと等の時間周期に基づいて指定される間隔を含む。別の実施形態では、これらのデータは、ブロックチェーンブロック高によって決定される難易度リセット期間、例えば第1リセット、第2リセット、第3リセット等に基づいて指定される間隔を含む。さらに、リセット周期と間隔は、ブロックチェーンによって異なる場合がある。
【0034】
別の実施形態では、契約データ125が取引所リファレンスシステム127のリファレンスデータシステム130に渡される代わりに、契約データ125が、代わりに、清算機関150の清算機関リファレンスデータシステム152に渡される。動作面においては、清算機関リファレンスデータシステム152は、取引所リファレンスデータシステム132と同様に動作する。さらに、清算機関契約自動生成システム154は、取引所契約自動生成システム132と同様に作用する。最後に、清算機関リファレンスデータベース158は、リファレンスデータシステム152から受信した契約データ156を格納する際に、取引所リファレンスデータデータベース136と同様に動作する。
【0035】
動作面では、清算機関リファレンスデータデータベース158に格納された契約リスティングデータ構造は、取引所127における契約リスティングスケジューラ138によって、清算機関150から取得され得る。取引所127の契約リスティングスケジューラ138に移動する、清算機関リファレンスデータデータベース158から渡される契約リスティングデータ構造は、清算機関のAPI160を通過し、契約データ162として取引所のAPI164に送信される。契約リスティングスケジューラ138は、次に、取引所リファレンスデータデータベース136から受信した契約リスティングデータ構造に関して上述したように、清算機関リファレンスデータデータベース158から受信した契約リスティングデータ構造に対して動作することができる。
【0036】
取引所取引システム142では、契約リスティングスケジューラ138により決定された予定タイミングに従って、取引所リファレンスデータデータベース136及び清算機関リファレンスデータデータベース158のいずれか又は両方から契約リスティングデータ構造を受信する。取引所取引システム142は、更新された契約状態の契約データ144をネットワークを介してマッチングエンジン146に公開する。例えば、更新された契約状態は、リスティングデータ及び決済日等のリスティングデータ構造要素を含み得る。上述したように、一実施形態では、各契約状態またはイベントは、指定された日時、例えば、2019年11月11日午後4時中部標準時(CT)であってよい。別の実施形態では、各状態またはイベントは、指定されたブロックチェーンブロック高、例えばブロック600,768であってもよい。
【0037】
マッチングエンジン146では、マッチングエンジン146は、マッチングエンジンがその内部メモリデータベースを更新し、契約リスティングデータ構造によって表される契約（複数可）に対するマッチング、注文送信、注文変更、及び注文キャンセルを可能にする。
【0038】
契約リスティングスケジューラシステム138は、取引システム142で公開されている契約リスティングデータ構造の状態及びタイミングのあらゆる更新を継続的に監視する。例えば、契約が満了して取引を停止するように設定されている場合、最後の取引イベントが発生した時点で、契約リスティングスケジューラシステム138は、更新された契約状態をネットワークを介して取引システム142に公開して取引を無効にする。その後、取引システム142は、更新された契約状態を取引データベースに記録する。前述のように、最後の取引イベントは、指定された日時またはブロックチェーンブロックの高さであってよい。
【0039】
取引所取引システム142は、更新された契約状態をネットワークを介してマッチングエンジン146に公開する。マッチングエンジン146は、その内部メモリを更新し、契約リスティングデータ構造によって表される満了する契約（複数可）に対するマッチング、注文送信、注文変更、および注文キャンセルを無効にする。さらに、マッチングエンジンは、契約リスティングデータ構造によって表される満了する契約（複数可）について、取引システム内のすべてのオープンオーダーをキャンセルする。例えば、上述したように、マッチングエンジン146は、その内部メモリデータベースを更新して、そのデータベースにまだ残っているあらゆるオープンオーダーを削除することによって、オープンオーダーをキャンセルすることができる。
【0040】
図2は、例示的な契約データを含むリスティングを構成する個々の契約リスティングデータ構造200の例を示す。ここで契約リスティングデータ構造内のデータフィールドに目を向けると、暗号通貨データフィールド210は、契約リスティングデータ構造200の原資産である特定の暗号通貨の識別情報を含む。図2に示すように、暗号通貨はビットコイン(BTC)であり、イーサリアムやライトコインなどの他のすべての暗号通貨が採用されてもよい。次に、契約サイズデータフィールド220では、契約のサイズは、標準的なハッシュレート及び時間、例えば毎秒100テラハッシュ(TH/s)で指定される。
【0041】
次に、価格提示形式データフィールド230では、契約リスティングデータ構造200に対する価格提示形式が指定される。例えば、価格提示形式は、難易度(difficulty)のギガハッシュ(GH)またはテラハッシュ(TH)であり得る。
【0042】
次に、最低価格増分データフィールド240では、契約リスティングデータ構造220の値が取引中に増分又は減分され得る最低価格が示される。最小価格増分は、10GHなどの難易度(difficulty)の単位で表される。
【0043】
次に、契約市場価値データフィールド250では、下記式に従って契約市場価値が計算及び格納され、これは期待されるマイニング報酬を決定する定式的な方法を示す。ビットコイン(BTC)の場合、所与の期間とハッシュレートに対して、所与の難易度(difficulty level)から、コインの量で測られる期待マイニング報酬を計算できる。
【0044】
ここで、Rは計算される期待報酬であり、これは契約市場価値への入力として使用され得る。
【0045】
Bはブロック当たりの報酬であり、これは、ブロックチェーンプロトコルにより、契約が上場されているブロックインターバルに対して定義される。
【0046】
Hは、指定されたハッシュレートまたは1秒あたりのハッシュ数である。図2の例では、Hは、契約サイズデータフィールド220で指定されるように、100TH/sに固定され得る。
【0047】
Sは、計算期間の秒数である。一実施形態では、計算期間の秒数は、1,209,600秒又は14日に固定されてもよい。
【0048】
Dは、ブロックチェーンによって定義される難易度(difficulty level)である。この値は、暗号通貨が動作している特定のブロックチェーンによって設定される。
【0049】
Nは、所与のブロックチェーンに対するナンス値の範囲である。この値もまた、暗号通貨が動作している特定のブロックチェーンによって設定される。一例では、ナンス値の範囲は、N=4,294,967,296であり得る。
【0050】
従って、式に示すように、採用されるB、H、S、およびNの値は、特定の契約に対して固定されてもよいが、難易度Dは変化し得、Rの現在の値は、暗号通貨がマイニングされているブロックチェーンによって義務付けられている現在の難易度によって変化する。上記の式に示すように、難易度が高くなるにつれて、Rの値は減少する。これは、難易度が上がるにつれて、暗号通貨を獲得するために実行する必要がある計算の数が全体的に多くなるため、契約市場価値で指定された固定量のTH/sでは、マイナーが暗号通貨を獲得する結果となる可能性が低いことを反映している。逆に、難易度が下がると、Rの値は大きくなる。繰り返すが、これは、難易度が下がるにつれて、暗号通貨を獲得するために実行する必要がある計算の数が全体的に少なくなるため、契約市場価値で指定された固定量のTH/sでは、マイナーが暗号通貨を獲得する結果となる可能性が高いことを反映している。難易度Dは、契約の存続期間中に増減する可能性がある。
【0051】
次に、満期日フィールド260において、契約リスティングデータ構造200の満期データが設定されてもよい。本明細書に記載されるように、満期日は、ビットコインブロック高によって決定され得る。例えば、ビットコインの難易度ターゲットは、2,016ブロックごとにリセットされる。一実施形態では、満期データは、契約リスティングデータ構造200が、連続する12回のリセット、すなわちブロックチェーンに追加された合計24,192ブロックの間上場されることを可能にし得る。
【0052】
次に、決済方法データフィールド270において、契約リスティングデータ構造200の決済方法が設定され得る。一実施形態では、決済は、それぞれのブロックチェーン上の暗号通貨を、顧客によって管理される口座に現物決済することによって行われてもよい。別の実施形態では、決済は、清算機関の帳簿および記録内で暗号通貨を現物決済することによって行われてもよい。別の実施形態では、決済は、清算機関の帳簿および記録内で暗号通貨の価値をフィアット通貨で現金決済することによって行われてもよい。
【0053】
最後に、決済手順データフィールド270において、契約リスティングデータ構造200の決済手順が指定され得る。一実施形態では、取引システムは、日々の契約決済価格によって決定される通り、変動証拠金が原資産である暗号通貨(例えばBTC)で毎日交換されることを要求することができる。さらに、指定されたブロック高で難易度がリセットされた後、最終決済は、ビットコインブロックチェーンによって公開された難易度ターゲットレベルに基づいてもよい。本実施形態では、決済は、決済時に新たに設定された難易度ターゲットに基づき、その新たなターゲットは、契約データ構造の作成時に決定されて以前設定された難易度ターゲットよりも低い、等しい、または高いのいずれかであってよい。また、買い手又は売り手の負担額、即ち決済時の負担額を決定する契約の結果は、契約データ構造仕様で指定されているように、決済時に更新された難易度に基づいてもよい。
【0054】
図3は、本取引システムの口座資金調達処理300を示す。口座資金調達処理は、顧客コンピュータシステム310、顧客の銀行312、カストディアン銀行314、および清算機関316を含む。口座資金調達処理に目を向けると、まず、ステップ320において、顧客310は、顧客の銀行312からカストディアン銀行314にフィアット通貨を送金するように顧客の銀行312に指示を送る。ステップ325において、顧客の銀行312は、顧客310から要求を受信した。ステップ330において、顧客の銀行312は、依頼された額を顧客の口座から引き落とし、引き落とされた金額をフィアット通貨でカストディアン銀行314に送金する。
【0055】
次に、ステップ335において、カストディアン銀行314は、フィアット通貨を受け取り、清算機関316に通知する。ステップ340において、清算機関316が所有するカストディアン銀行314の口座に、顧客のフィアット預金が入金される。
【0056】
次いで、ステップ345において、清算機関は、例えば、清算機関システムがネットワークを介してカストディアン銀行のシステムに残高クエリを送信することによって、カストディアン銀行における清算機関の銀行口座における対応する残高増加を確認することにより、顧客の預金を検証する。カストディアン銀行のシステムは、口座データベースから残高を取得し、ネットワーク経由でクエリに応答する。応答を受信すると、清算機関システムは、自身の内部口座データベースを新しい顧客口座残高で更新する。ステップ350において、清算機関316は、カストディアン銀行314における自身の口座の残高を検証し、新しい内部台帳残高を反映するように内部台帳データベースを更新する。ステップ355において、清算機関316は、顧客の預金を反映するために、清算機関316の顧客口座に入金する。最後に、ステップ360において、顧客310は、例えば、清算機関316から顧客の更新された口座データを取得し、それが顧客の顧客銀行312に対する指示を反映していることを確認することによって、顧客の口座の更新された残高を確認する。
【0057】
したがって、一実施形態では、取引システムを使用して取引を行うために、顧客は、取引所及び清算機関で口座を作成し、資金を提供する。たとえば、顧客は、システムエンドポイントから口座を開設する要求を送信できる。例えば、顧客は、モバイルアプリケーション、PC、サーバなどのシステムエンドポイントを使用して要求を提出することができる。システムエンドポイントは、ネットワークを介して取引所および清算機関のシステムに要求情報を送信する。さらに、顧客要求メッセージは、名前、個人識別番号、住所、電話番号、銀行情報、暗号通貨ウォレットアドレスなどのデータを含むことができる。
【0058】
取引所および/または清算機関の口座システムにおいて、これらのシステムは、顧客の新しい口座要求を受信し、顧客の識別情報を検証し、口座データベースにユーザ口座を作成し、識別データを口座データベースに記録する。次に、顧客は、システムエンドポイントを使用して、取引所および/または清算機関での口座開設を確認することができる。例えば、取引所および/または清算機関の口座システムは、ネットワークを介して完了メッセージをエンドポイントシステムに送信することができ、システムエンドポイントは完了メッセージを表示することができる。
【0059】
別の実施形態では、顧客は、自分の銀行口座から清算機関銀行口座にフィアット通貨を送金する要求をシステムエンドポイントから提出する。例えば、ユーザは、モバイルアプリケーション、PC、サーバなどのシステムエンドポイントを用いて要求を送信してもよい。次に、システムエンドポイントは、ネットワーク経由でユーザの銀行に送金要求を送信する。要求メッセージには、銀行口座番号、金額、通貨、受取銀行口座番号などのデータが含まれていてもよい。
【0060】
顧客銀行システムは、次に、要求を受信し、それを検証し、送金指示を処理する。例えば、顧客銀行システムは、口座データベースに格納されている顧客の口座残高を問い合わせることによって、顧客が送金をするのに十分な資金を有することを検証してもよい。顧客が送金を実行するのに十分な資金を持っていない場合、顧客銀行システムは、顧客にエラーメッセージを送信することができる。
【0061】
次に、顧客銀行システムは、送金記録を反映するために内部トランザクションデータベースを更新する。顧客銀行システムはまた、口座残高の更新を反映するために、顧客口座残高口座データベース・レコードを送金金額だけ減らすことによって、口座データベースに格納されている顧客口座レコードを更新する。その後、顧客銀行システムは、送金要求を発行することができる。この送金要求は、ネットワークを介して清算機関銀行システムに送信され得る。
【0062】
清算機関銀行システムにおいて、要求が受信され、検証され、清算機関銀行システムは、トランザクションの指示及びデータ要素を処理する。一実施形態では、清算機関銀行システムは、口座残高の更新を反映するために、口座データベースに格納されている顧客口座残高を更新する。例えば、清算機関銀行システムは、インバウンド送金をトランザクションデータベースに記録し、残高データベースレコード内の清算機関口座残高を送金金額だけ増加させてもよい。その後、清算機関銀行システムは、ネットワークを介して清算機関決済システムにトランザクションレコードを送信する。トランザクションレコード/メッセージには、銀行口座番号、金額、通貨、受取人口座番号などのデータが含まれてよい。
【0063】
その後、清算機関決済システムは、銀行システムからトランザクションレコードを受信する。清算機関決済システムは、顧客/受取人口座番号を顧客の清算機関の口座番号と照合し、口座残高の更新を反映するために、残高データベースに格納されている顧客口座残高を更新する。例えば、清算機関決済システムは、残高データベースレコード内の顧客口座残高を送金金額だけ増加させてもよい。
【0064】
最後に、顧客は、エンドポイントシステムを用いて、顧客の銀行口座から送金されたフィアット通貨の更新された残高を検証する。一実施形態では、エンドポイントシステムは、ネットワークを介して口座残高クエリを顧客銀行システムに送信し、顧客銀行システムは、次に、口座データベースから顧客の口座残高を引き出し、クエリに応答する。次に、顧客エンドポイントシステムは、口座残高クエリ応答を受信し、残高データを顧客に提示する。
【0065】
図4は、本取引システムの暗号通貨預金処理400を示す。暗号通貨預金処理400は、顧客コンピュータシステム410、暗号通貨ウォレットプロバイダ412、暗号通貨カストディアン414、清算機関416、ブロックチェーンネットワーク418、およびブロックチェーンネットワーク418上のパブリックアドレス420を含む。ここで暗号通貨預金処理400に目を向けると、まず、ステップ425で、顧客410は、ウォレットプロバイダ412が顧客のウォレットのパブリックアドレスから暗号通貨カストディアン414のパブリックアドレスに暗号通貨の金額を送金するように要求する。次に、ステップ430で、ウォレットプロバイダ412における顧客の暗号通貨ウォレットは、顧客の要求を処理する。
【0066】
次に、ステップ432では、ブロックチェーンネットワーク418において、顧客のパブリックアドレスから暗号通貨カストディアンのパブリックアドレスへの暗号通貨の送金が処理される。ステップ434では、ブロックチェーンノードシステム及びコンセンサスメカニズムが送金を確認する。ステップ436では、顧客のパブリックアドレス残高が減少し、ステップ438では、暗号通貨カストディアンのパブリックアドレス残高が増加する。次に、ステップ440では、清算機関416において、ブロックチェーンノードシステムは、送金を確認する。一実施形態では、ブロックチェーンノードシステムは、残高更新を示すメッセージを暗号通貨カストディアンに自動的に送信し得る。別の実施形態では、暗号通貨カストディアン414は、残高要求をブロックチェーンノードシステムに送信し、ブロックチェーンノードシステムは、更新された残高で応答する。
【0067】
ステップ442において、暗号通貨カストディアン414は、暗号通貨カストディアン414のパブリックアドレスにおいて顧客からの暗号通貨の受取を検証し、清算機関414 に通知する。ステップ444で、暗号通貨カストディアン414は、顧客の口座に入金するように清算機関416に指示を送る。
【0068】
ステップ446において、例えば、清算機関システムがネットワークを介して暗号通貨カストディアンのシステムに残高クエリを送信することにより、暗号通貨カストディアンにおける清算機関の暗号通貨カストディ口座における対応する残高増加を確認することによって、清算機関は顧客の預金を検証する。暗号通貨カストディアンのシステムは、口座データベースから残高を取得し、ネットワーク経由でクエリに応答する。応答を受信すると、清算機関システムは、自身の内部口座データベースを新しい顧客口座残高で更新する。その後、ステップ448において、清算機関416は、暗号通貨の預金を反映するために、顧客の暗号通貨口座残高に入金する。最後に、ステップ450で、顧客は、期待される更新された残高が清算機関416の顧客口座に現れることを確認する。
【0069】
一実施形態では、顧客は、自分のウォレットから清算機関のウォレットに暗号通貨を転送する要求をシステムエンドポイントから提出する。ユーザは、モバイルアプリケーション、PC、サーバなどのシステムエンドポイントを使用して要求を送信できる。システムエンドポイントは、ネットワーク経由でユーザのウォレットプロバイダに送金要求を送信する。要求メッセージには、ウォレットアドレス、金額、暗号通貨、受信ウォレットアドレスなどのデータが含まれている。ブロックチェーンノードシステムでは、送金指示メッセージが受信され、ウォレットはネットワークを介してブロックチェーンノードシステムに暗号通貨送金指示を送信する。
【0070】
ブロックチェーンノードシステムは、暗号通貨送金メッセージを受信し、ブロックチェーンの計算方法に従って処理する。暗号通貨送金メッセージには、送金する暗号通貨の量、送金元のパブリックアドレス、および暗号通貨の送金先のパブリックアドレスが含まれる。さらに、ブロックチェーンノードシステムは、送信側のアドレスが、要求された送金および関連する手数料をカバーするのに十分な暗号通貨を有することを確認することができる。送信側のアドレスが十分な暗号通貨を有していない場合、ブロックチェーンのコンセンサスメカニズムはトランザクションを確認しない。その結果、ブロックチェーンノードシステムは、清算機関のブロックチェーンノードシステムに残高更新メッセージを送信せず、顧客のウォレットにエラーメッセージを送信してもよい。さらに、ブロックチェーンノードシステムは、マイニング/コンセンサスの方法に従って、暗号通貨送金トランザクション（複数可）をブロックチェーンデータベースに記録する。
【0071】
清算機関のデジタルカストディアンは、トランザクションアクティビティのためにネットワークを介してブロックチェーンノードシステムに問い合わせる。次に、ブロックチェーンノードは、ブロックチェーンデータベース内のブロックチェーン上のパブリックアドレストランザクションアクティビティを検査する。ブロックチェーンノードは、ネットワーク経由でトランザクションレコードを送信する。トランザクションレコード/メッセージには、金額、暗号通貨、発信元のパブリックアドレスなどを含むトランザクションの詳細が含まれ得る。清算機関のデジタルカストディアンは、トランザクションレコードを受信し、ネットワーク経由で清算機関決済システムに引き渡す。その後、清算機関決済システムは、口座残高の更新を反映するために、口座データベースに格納されている口座残高を更新する。例えば、清算機関決済システムは、口座データベースレコード内の清算機関口座残高を送金金額だけ増加させてもよい。
【0072】
清算機関決済システムは、デジタルカストディアンからトランザクションレコードを受け取り、発信元のパブリックアドレスを顧客の清算機関口座と照合する。例えば、顧客の非清算機関ウォレットアドレスは、口座開設時に顧客から取得され、口座データベースに格納され得る。次に、清算機関決済システムは、送金金額などの口座残高の更新を反映するため、残高データベースに格納されている顧客口座残高を更新する。
【0073】
顧客は、顧客のコンピュータシステムエンドポイントシステムを用いて、ブロックチェーン上で送金された暗号通貨の更新された残高を検証する。一実施形態では、エンドポイントシステムは、ネットワークを介して口座残高クエリをブロックチェーンノードに送信する。次に、ブロックチェーンノードは、ブロックチェーンデータベース内のブロックチェーン上の顧客のパブリックアドレス口座残高を検査する。そして、ブロックチェーンノードは、ネットワーク経由で顧客のエンドポイントシステムに口座残高クエリ応答を送信する。最後に、顧客エンドポイントシステムは、口座残高クエリ応答を受信し、残高データを顧客に提示する。
【0074】
図5は、本発明の一実施形態に係る取引及び清算システム500を示す。取引及び清算システム500は、顧客505、モバイルアプリケーション511、ウェブブラウザ512、および取引アプリケーション513並びにそれらのそれぞれのAPI515～517、インターネットまたはプライベートネットワーク520、電子取引取引所530、電子清算機関550、銀行カストディアンシステム566、デジタルカストディアンシステム570、ブロックチェーンノードシステム580及びブロックチェーン590を含む。個々のAPIを図5に示すが、各APIは1つ以上のAPIであってよい。図5に示すように、電子取引取引所530は、取引所口座システム532および付随する取引所口座データベース534と、リファレンスデータシステム536および付随するリファレンスデータデータベース538と、スケジューラシステム540および付随するスケジューリングデータベース542と、取引システム544および付随する取引データベースと、マッチングエンジンとを含む。
【0075】
電子清算機関550は、清算機関口座システム552及び付随する清算機関口座データベース554、並びに決済データベース558、ポジションデータベース560、及び残高データベース562を含む決済システム556を含む。電子清算機関550は、1つ以上のAPI564を介して銀行カストディアンシステム556 に接続される。電子清算機関550は、1つ以上のAPI568を介してデジタルカストディアンシステム570に接続される。また、デジタルカストディアンシステム570は、API572を介してブロックチェーンノードシステム580と通信している。また、取引所システム530は、1つ以上のAPI574を介してブロックチェーン590と通信している。
【0076】
ブロックチェーン590は、分散台帳データベース592及びコンセンサスメカニズム594を含む。現在の難易度の値は、API574を介して取引所530のブロックチェーンノードシステム580によって、分散台帳データベース592から取得され得る。
【0077】
動作面では、顧客505は、モバイルアプリケーション511、ウェブブラウザ512、取引アプリケーション513、PC、サーバなどのシステムエンドポイントから、契約（複数可）を売買する注文を取引所システム530に提出する。次に、システムエンドポイントは、注文メッセージをネットワーク520を介して取引所取引システム530に送信する。取引メッセージには、ユーザアカウント、契約識別子、注文タイプ、数量、価格などのデータを含めることができる。
【0078】
取引所取引システム530は、メッセージを受信し、それを検証して、注文をマッチングエンジンに公開する。例えば、取引システムは、ユーザアカウント、契約、注文タイプなどを確認するメッセージの内容を検証してもよい。取引システム544は、注文を取引データベース546に格納してもよい。
【0079】
マッチングエンジン548は、システム定義マッチングロジックに基づいて、取引データベース546に格納された売買する1つ以上の注文をマッチングすることを試みる。マッチングエンジン548が2つの注文をマッチングさせると、取引所取引システム530は、決済のために、マッチングされた注文の詳細をネットワークを介して清算機関システム550に引き渡す。マッチングされた注文のメッセージに含まれる詳細には、買い手/売り手口座、価格、数量、取引時間などの情報が含まれる。
【0080】
前述のように、リファレンスデータシステムは、リスティング契約データ構造の設定に使用され、リスティング契約データ構造はリファレンスデータデータベースに格納される。さらに、上述したように、スケジューラシステムは、リスティング、最初の取引、最後の取引、満期及びデリスティングを含む、リスティング契約データ構造の状態をスケジュールする。最後に、口座システムは、例えば顧客の取引、与信限度額およびリスク限度額、口座名及び/又はID番号、ならびに、口座が取引可能とされる商品等の口座のシステム構成、口座パスワード等のAPI構成、及び通信セッションの切断時に未処理の注文をキャンセルする設定等のリスク制御設定に関連する他の口座データを記録することによって、取引所システム530において顧客の口座を管理するために使用される。
【0081】
次に、清算機関システム550において、清算機関システム550は、取引所システム530におけるマッチングエンジン548から情報を受信する。次に、清算機関システム550は、以下のように、それぞれの買い手及び売り手の口座において決済処理を実行する。清算機関システム550は、マッチングエンジン548からの情報を検証し、ポジションデータベース560に記録する。次に、清算機関システム550は、買い手口座または売り手口座のいずれかが、契約リスティングデータ構造によって表される契約において既存のポジションを有するかどうかをチェックする。ポジションが見つからない場合、決済システム556は、ポジションデータベース560内に顧客のポジションを有する契約リスティングデータ構造の新しいレコードを作成する。逆に、既存のポジションが見つかると、決済システム556は、ポジションデータベース560内のポジションのポジション量および価格を更新する。次に、清算機関システム550は、買い手及び売り手についての決済債務を計算し、残高データベース562内の買い手及び売り手の口座残高を更新する。次に、清算機関システム550は、決済データベース558にトランザクションを記録する。
【0082】
決済の詳細はまた、清算機関システム550の口座システム552に送信され、そこで、顧客505のために検索され表示されてもよい。
【0083】
図6は、本発明の一実施形態によるマーク・トゥ・マーケット・システム600を示す。マーク・トゥ・マーケット・システム600は、図5の電子取引所システム530および電子清算機関550を含む。取引所システム530は、取引所スケジューラシステム540、スケジューラデータデータベース542、電子取引システム544、取引データベース546、およびマッチングエンジン548を含む。電子清算機関550は、決済システム556、決済データベース558、ポジションデータベース560、および残高データベース562を含む。個々のAPIを図6に示すが、各APIは1つ以上のAPIであってもよい。
【0084】
マーク・トゥ・マーケット・システム600において、オープンポジションは、定期的に、最も一般的には毎日、マーク・トゥ・マーケットされてもよく、変動証拠金は、例えば、1つ以上の口座の借方に記入し1つ以上の口座の貸方に記入するようにその内部帳簿及び記録を更新するなど、清算機関によって口座間で移動され得る。ここで取引所取引システム530に目を向けると、取引所取引システムは、以下に説明するような計算方法に基づいて、ある時点での毎日の決済価格を計算する。計算される時点を定義するデータは、スケジューラシステムのスケジューリングデータデータベース542に格納される。一例では、計算は、取引システムソフトウェアに格納されたプログラムによって実装される方法であってもよい。例えば、その方法は、過去24時間の間に特定の契約リスティングデータ構造によって表される契約において行われたすべての取引の売買高加重平均価格を決定することであってもよい。
【0085】
取引所スケジューラシステム540では、決済価格計算スケジュールがスケジューリングデータベース542から取得される。次に、取引所スケジューラシステム540は、計算手順に従い取引システムを用いて決済価格の計算を開始してもよい。一実施形態の一例は、満期日が2019年10月11日金曜日であり、その後のリスティングが2019年10月23日金曜日等である隔週で上場される契約についてマーク・トゥ・マーケット価格が計算されることを示すスケジュールデータデータベース542内の契約データである。代替の実施形態では、スケジュールデータデータベース542内の契約データは、満期がブロック高598,752、ブロック高600,768等で発生するビットコインベースの契約について、マーク・トゥ・マーケット価格が計算されることを示してもよい。
【0086】
一実施形態では、取引所取引システム530は、アクティブな契約リスティングごとに、毎日のマーク・トゥ・マーケット価格を計算する。この計算は、取引システム530内のソフトウェアによって実行されてもよい。上述したように、マーク・トゥ・マーケット価格の計算手順は、定義された期間の間の取引から計算された売買高加重平均価格(VWAP)などのアルゴリズムを含み得る。この計算を完了するために必要なデータ入力は格納され、及び／又は、例えばスケジュールデータデータベース542、トランザクションレベルの取引履歴を含む取引データベース546、または他のシステムデータベースを含む取引所システム530内の1つ以上のデータベースから取得され得る。以下でさらに説明するように、図2に挙げた契約についてのこの計算から生成される決済価格の値の一例は、13,000ギガハッシュである。この値は、図2の契約式において、値Dとして使用される。
【0087】
また、取引所取引システム530は、日々の決済価格データを取引データベース546に記録し、決済価格データをマッチングエンジンシステム548に公開し、ネットワークを介して日々の決済価格データを清算機関システム550に公開する。
【0088】
清算機関システム550において、決済システム556は、日々の決済価格データを受信し、それを決済データベース558に格納する。決済システム556はまた、各顧客口座についての変動証拠金要求額の計算を開始する。一実施形態では、決済システム556は、取引システム530から決済価格を受け取った時点で変動証拠金の計算を開始する。別の実施形態では、決済システム550は、変動証拠金を決定するために事前定義された予定時点を有し、ここで、所定の時間が決済データベース558に格納されてもよい。
【0089】
決済システム556は、日々の決済価格データを用いて契約式に基づき、新たな契約市場価値を計算する。基準となる市場価値の計算式の例を図2に示す。市場価値の計算式の値(B,H,S,及びN)が生成され、上述のように、契約作成時にリファレンスデータデータベース538に格納される。価格決定式における唯一の変数として、決済時のデータ要素Dの値は、上述したように、取引システムから取得される、計算に用いられる変動決済価格を制御する。
【0090】
１契約あたりの市場価値の計算出力の簡略化された例は、以下の通りである。
【0091】
ここで、所与の価格、例えば、難易度(D)13,000に対する１契約あたりの市場価値、例えば、報酬(R)は、0.02707999BTCである。
【0092】
12.5はBTCブロック報酬(B)である。
【0093】
毎秒100テラハッシュ(TH/s)は契約サイズ(H)であり、1012は1テラハッシュ(TH)に等しい。
【0094】
Sは、1,209,600秒、すなわち14日間の契約期間の長さである。
【0095】
契約価格は難易度（D）のギガハッシュで表され、109は1ギガハッシュ(GH)に等しい。
【0096】
ブロックチェーンのナンス値の範囲は4,294,967,296である。
【0097】
上述のように、期待報酬Dの値は、変化する唯一のものである。その結果、難易度の不利な/増加する変化のリスクをヘッジすることができる。ブロック報酬Bはいずれ変化する可能性があるが、ブロック報酬の変更は、指定されたブロック高で発生する事前定義されたスケジュールされたイベントである。したがって、Bが一定のときのみ行われるように契約を構成することで、Bの変化をリスクとして回避することができる。
【0098】
逆に、Dは、間隔をおいてブロックチェーンによって決定される。したがって、Dが更新されたときに何が起こるかによって、期待報酬の値が変化する：Dは上昇することもあれば、下降することもあるし、または同じままのこともある。契約が複数のDのリセットにまたがり、Dの値がリセット時に変化すると、契約の値もシフトし、本システムは、最新の間隔の難易度の変化に基づいて変動証拠金をシフトする。最後に、決済時に、決済前の最後の間隔での難易度に基づいて、契約が決済のために評価される。Dはブロックチェーンから直接取得できる。
【0099】
決済システム556は、口座のポジション、すなわちロング又はショートに基づいて、各顧客口座の変動証拠金を計算することを進める。一実施形態では、決済システム556は、ポジションデータベース560から口座ポジションデータを取得する。次に、決済システム556は、ポジションデータベース560に格納された市場価格と新たに計算された市場価格との間のポジション市場価格の変化として、変動証拠金要求額を計算する。
【0100】
一実施形態において、変動証拠金の決済は、契約の原資産である暗号通貨の形態で行われる。例えば、後述するように、格納されている市場価値と新たに決定された市場価値との計算された差額は、決済される必要がある変動証拠金を表す。以下の表は、図2で参照される契約の各口座の変動証拠金が0.10029628BTCであると決定された例を示す。上述したように、難易度Dは、ブロックチェーンによってリセットされた場合に変化し得る。この例では、難易度が、前回の決済値13,000から現在の決済値13,500に変化している。難易度が上がったため、契約の期待報酬、ひいては市場価値が下がる。
【0101】
この例では、顧客口座#1はロング100契約であり、顧客口座#2はショート100契約である。前日の決済価格は難易度13,000GH(図2に示された計算を使用して2.70799949BTCの値が得られる)であり、当日の決済価格は難易度13,500GH(図2に示された計算を使用して2.60770321BTCの値が得られる)である。したがって、両口座のポジション値の変化は0.10029628BTCである。顧客口座#1はロングであるため、顧客口座#1は価格の上昇即ち難易度の上昇による変動証拠金を受け取り、顧客口座#2はショートであるため、顧客口座#2は変動証拠金を支払う必要がある。したがって、顧客口座#2からは0.10029628BTCが引き落とされ、顧客口座#1には0.10029628BTCが入金される。そして、これらの入金および引落は、買い手および売り手の口座残高を格納する残高データベース562に記録される。顧客口座が変動証拠金を満たすのに十分なBTCを有していない場合、本システムは、顧客へのマージンコールを生成し得る。さらに、特定の契約について、システムは、原資産である暗号通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはフィアット通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはマージンコールを支払う顧客がそれを原資産である暗号通貨またはフィアット通貨で支払うかどうかを選択できるようにしてもよい。
【0102】
別の実施形態では、変動証拠金決済は、契約のフィアットデノミネーションのフィアット通貨、例えば米ドル等の形態で行われる。上記の例と同様に、下表でも、難易度が前回の決済値13,000から現在の決済値13,500に変更されている。難易度が上がったため、契約の期待報酬、ひいては市場価値が下がる。したがって、ディレクション、量、前回の決済、現在の決済、前回の価値、現在の価値、および変動証拠金のエントリは、上記の表と同じである。ただし、前回のフィアット、現在のフィアット、前回の価値フィアット、現在の価値フィアット、変動証拠金フィアットが追加されました。前回のフィアットは、最後のマーク・トゥ・マーケットにおける暗号通貨1単位のフィアット建てのマーク・トゥ・マーケット値であり、現在のフィアットは、現在のマーク・トゥ・マーケットにおける暗号通貨1単位のフィアット建てのマーク・トゥ・マーケット値である。前回の価値フィアットは、前回の価値に前回のフィアットを掛けた値として計算される、ポジションのフィアット建ての値である。現在の価値フィアットは、現在の価値に現在のフィアットを掛けた値として計算される、ポジションのフィアット建ての値である。変動証拠金フィアットは、前回の価値フィアットと現在の価値フィアットの差額で、ドルなどのフィアット通貨で表される。
【0103】
【0104】
変動証拠金決済のフィアット通貨換算値を決定するために、決済システムは、その決済計算の一部として、フィアット通貨への変換を実行する。決済システムは、更に、決済価格公開処理の一部として、暗号通貨からフィアット通貨への価格を、取引システムから受信して、リファレンスデータデータベースに格納する。そして、これらの入金および引落は、買い手および売り手の口座残高を格納する残高データベース562に記録される。一実施形態では、暗号通貨からフィアット通貨への価格は、例えば、1つ以上の参照市場におけるフィアット通貨に対する暗号通貨、例えばBTC対USDの最近の取引（複数可）に基づいて、取引システムによってリファレンスデータデータベースに追加される。一実施形態では、参照市場は、ErisXのスポット市場などの単一市場であってもよい。別の実施形態では、リファレンスはスポット市場のインデックスであってもよい。取引システムは、ネットワークを介してソース、市場またはインデックスプロバイダから、暗号通貨からフィアット通貨への価格を受け取り、暗号通貨からフィアット通貨への価格をリファレンスデータデータベースに追加することができる。
【0105】
上述のように、変動証拠金決済が行われ、決済データベース558に設定された事前定義されたスケジュールで顧客口座に記録される。一実施形態では、顧客口座間の移動は、決済システムが変動証拠金計算を完了した時点で開始される。別の実施形態では、顧客口座間の移動は、例えば真夜中などの定義された時点で行われる。
【0106】
上述したように、次に、顧客口座残高に対する更新は、変動証拠金決済を反映するために残高データベース563 に格納される。したがって、顧客口座を、契約の変動証拠金決済に基づいて、顧客が所有する資産または契約ごとに増減させることができる。さらに、顧客口座が変動証拠金を満たすのに十分なフィアット通貨を有していない場合、本システムは、顧客へのマージンコールを生成し得る。さらに、特定の契約について、システムは、原資産である暗号通貨でのマージンコールの支払いを要求するよう構成されてもよいし、またはフィアット通貨でのマージンコールの支払いを要求するよう構成されてもよいし、またはマージンコールを支払う顧客がそれを原資産である暗号通貨またはフィアット通貨で支払うかどうかを選択できるようにしてもよい。
【0107】
図7は、本発明の一実施形態による最終決済システム700を示す。最終決済システム700は、図5の電子取引所システム530および電子清算機関550を含む。取引所システム530は、取引所スケジューラシステム540、スケジューラデータデータベース542、電子取引システム544、取引データベース546、マッチングエンジン548、リファレンスデータデータベース538、リファレンスデータシステム536、およびブロックチェーンノードシステム580を含む。電子取引所550は、決済システム556、決済データベース558、ポジションデータベース560、および残高データベース562を含む。また、図7には、分散台帳データベース592およびコンセンサスメカニズム594を含むブロックチェーン590、ならびにブロックチェーンデータシステム720およびブロックチェーンデータデータベース730を含む第三者ブロックチェーンデータプロバイダ710も示されている。個々のAPIを図7に示すが、各APIは1つ以上のAPIであってもよい。
【0108】
動作面では、契約の最終決済時に、その価格が、所与の契約の原資産である暗号通貨のブロックチェーンによって公開された難易度ターゲットレベルから決定される。最終決済処理は、特定の契約リスティングデータ構造について、現在時刻が契約リスティングデータ構造に関連付けられた所定の満期日と一致すると判定されたときに、取引所スケジューラシステム540において開始される。その際、取引所スケジューラシステム540は、契約状態データの変化を取引システム544に送信する。別の言い方をすれば、取引所スケジューラシステム540は、最終決済を処理するために契約を設定し、取引データベース546内の契約状態を更新し最終決済のために取引データベース546内のデータを取得するよう取引システムを開始する。上述したように、データ抽出が行われる時点は、スケジューラシステム540のスケジューリングデータベース542に定義される。前述のように、満期および/または最後の取引イベントは、指定された日時またはブロックチェーンブロック高であってもよい。
【0109】
次に、取引所取引システム544は、契約期間における難易度を取得する。一実施形態では、難易度は、ブロックチェーンから直接取得される。例えば、リファレンスデータシステム536は、難易度についての要求をブロックチェーンノードシステム580に送信してもよい。ブロックチェーンノードシステムは、要求を受信し、ブロックチェーンソフトウェアから難易度を取得し、難易度を返すことができる。前述のように、契約が1回の難易度のリセットのみにまたがる場合、難易度は変化しない。ただし、契約が2回以上のリセットにまたがり、難易度がリセットされた場合は、契約の価値が調整される。
【0110】
別の実施形態では、難易度は、ブロックチェーンデータを専門とする第三者のブロックチェーンデータプロバイダ710から取得される。この実施形態では、リファレンスデータシステム536は、1つ以上のAPIを介して要求を第三者のブロックチェーンデータプロバイダ710に送信してもよい。第三者のブロックチェーンデータプロバイダ710は、そのブロックチェーンデータシステム720に関連付けられたブロックチェーンデータデータベース730から難易度データを取得し、そして、その難易度データをブロックチェーンノードシステム580に返し、その後、難易度情報をリファレンスデータシステム536に送信してよい。ブロックチェーンデータシステム720は、分散台帳データベースから難易度データを前もって取得し、それをブロックチェーンデータデータベースに格納していてもよい。前述のように、本システムでは、契約の評価を決定するために、最新の難易度の値を使用する。
【0111】
次に、取引所取引システム544は、難易度を契約価格の形式に変換する。例えば図2で参照した契約では、最終決済時の難易度が13,750,000,000,000である場合、取引システムは最終決済価格を13,750(GH)として変換して格納する。取引所取引システム544は、最終決済価格を取引データベース546に記録し、最終決済価格をネットワークを介して清算機関システム550に公開する。
【0112】
清算機関システム550は、最終決済価格を受け取り、それを決済データベース558に格納する。次に、清算機関システム550は、各口座の最終決済債務要求額の計算を開始する。一実施形態では、決済システム556は、取引システム530から決済価格を受け取った時点で最終決済計算を開始する。別の実施形態では、決済システム556は、例えば真夜中などの所定の時点で最終決済計算を開始する。
【0113】
次に、決済システム556は、最終決済価格を用いて、図2の契約式に基づき、最終契約市場価値、すなわち報酬を計算する。前回の決済価格13,000が現在の決済価格13,500まで上昇した例に引き続き、最終決済価格が13,750と判定された例を考えてみる。この最終決済価格については、図2に示す式を使用し、さらに以下に説明するように、最終契約市場価値は0.02560290BTCである。
【0114】
決済システム556は、口座のポジション、すなわちロング又はショートに基づいて、各口座の最終決済債務を計算する。決済システム556は、口座ごとに、ポジションデータベース560から口座ポジションデータを取得する。変動証拠金決済が現物の暗号通貨で行われる一実施形態では、最終決済債務は、ポジションの市場価値の変化に基づく最終変動証拠金決済として計算される。
【0115】
上記のマーク・トゥ・マーケットの例と同様に、図2で参照されている契約の最終決済の簡略化された計算例は、以下の通りである。
この例では、顧客口座#1はロング100契約で、顧客口座#2はショート100契約である。前日の決済価格は難易度13,500GH(図2に示された計算を使用して2.60770321BTCの値が得られる)であり、当日の決済価格は難易度13,750GH(図2に示された計算を使用して2.56029042BTCの値が得られる)である。したがって、両口座のポジション値の変化は0.04741279BTCである。顧客口座#1はロングであるため、顧客口座#1は価格の上昇即ち難易度の上昇による変動証拠金を受け取り、顧客口座#2はショートであるため、顧客口座#2は変動証拠金を支払う必要がある。したがって、顧客口座#2からは0.04741279BTCが引き落とされ、顧客口座#1には0.04741279BTCが入金される。そして、これらの入金および引落は、買い手および売り手の口座残高を格納する残高データベース562に記録される。上述のように、顧客口座が変動証拠金を満たすのに十分なBTCを有していない場合、本システムは、顧客へのマージンコールを生成し得る。さらに、特定の契約について、システムは、原資産である暗号通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはフィアット通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはマージンコールを支払う顧客がそれを原資産である暗号通貨またはフィアット通貨で支払うかどうかを選択できるようにしてもよい。
【0116】
マーク・トゥ・マーケット計算について上述したものと同様に、変動証拠金決済が契約のフィアットデノミネーションのフィアット通貨の形態で行われる別の実施形態では、最終決済債務は、暗号通貨の現物受渡及びフィアット通貨決済として計算される。例えば、上記した例を基に、以下の表において、取引価格、取引フィアット、取引価値、および取引価値フィアットが追加されている。取引価格は、両当事者間で契約が最初に取引された価格(この場合は13,000)である。取引フィアットは、最初に取引された日の暗号通貨1単位のフィアット通貨建てのマーク・トゥ・マーケット値である。取引価値は、図2に示す計算を使用して提供される値である。取引価値フィアットは、取引価値に取引フィアットを掛けた値として計算される、ポジションのフィアット建ての値である。
【0117】
この例では、顧客口座#1と顧客口座#2の最初の取引価格は13,000である。最終決済価格が13,750であるため、各口座のポジションの報酬の差は0.14770906BTCとなる。顧客口座#2はショートであり、価格の上昇、すなわち難易度の増加に伴い、顧客口座#2は報酬の差額を現物のBTCで受け渡す義務がある。
【0118】
以前の変動証拠金決済は、フィアット通貨、例えば米ドルで担保されていたため、以前の変動証拠金は、この際、清算機関に返済される。例えば、以前の累積変動証拠金の決済は、各口座で合計616.82ドルであり、顧客口座#1はフィアット通貨の利益を受け取っていた。その結果、顧客口座#1は清算機関に616.82ドルを返還する義務がある。
【0119】
上述のように、決済システム556は、各顧客口座及び各契約について、決済データベース558に最終決済計算の出力を格納する。上述のように、顧客口座の最終決済の調整は、決済データベース558に格納された事前定義されたスケジュール上で行われ得る。例えば、顧客口座の最終決済の調整は、決済システムが最終決済債務の計算を完了した時点で開始してよい。あるいは、顧客口座の最終決済の調整は、例えば深夜0時など、決済システムに格納された所定の時間に行われてもよい。決済システムは、顧客口座の最終決済債務に基づいて各資産の顧客口座残高を増減させることにより、残高データベースに格納されている顧客口座残高を更新して最終決済を反映させる。さらに、顧客口座が変動証拠金を満たすのに十分なフィアット通貨を有していない場合、本システムは、顧客へのマージンコールを生成し得る。さらに、特定の契約について、システムは、原資産である暗号通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはフィアット通貨でのマージンコールの支払いを要求するように構成されてもよいし、またはマージンコールを支払う顧客がそれを原資産である暗号通貨またはフィアット通貨で支払うかどうかを選択できるようにしてもよい。
【0120】
したがって、本システムを使用して、暗号通貨マイナーは、マイニングハードウェアによって実行されるTH/sの実際の数の全部または一部を表す1つ以上の契約を、固定価格で売る機会を有する。上記のように、暗号通貨マイニングの決定論的ではなく確率的な性質のために、マイナーは、マイニング作業により実際にどれだけの暗号通貨が彼らに付与されるかについて事前に確信が持てず、本システムの下では暗号通貨の量は契約の販売価格よりも大きい可能性も少ない可能性もある。さらに、暗号通貨の市場価格は変動する可能性があるため、マイナーは、マイニング作業により実際に彼らに付与される暗号通貨のドル価値について事前に確信が持てない。しかし、暗号通貨マイナーが1つ以上の契約を売却すれば、その1つ以上の契約 で表される彼らのマイニングハードウェアによって提供されるTH/sの部分についての、マイナーがその1つ以上の契約について受け取る価格としてのマイナーのドル価値が明らかになり、固定される。本システムを使用して契約を売却することにより収益の安定性を達成する暗号通貨マイナーの能力は、暗号通貨マイナーにとって非常に望ましいものである。なぜなら、マイナーは通常、給与、電気代、およびその他の運用上のオーバーヘッドの形で、フィアット通貨建ての負債を抱えているためである。マイナーが、価格/市場/難易度リスクを管理する能力がなく、彼らの生産物の価値の変動リスクに完全にさらされる場合、彼らの生産物の収益が運営経費を賄うのに十分でなくなる、および/または財務予測と計画がより危険で困難になるというリスクを冒す。これらは、農家、貴金属および卑金属鉱山業者、石油生産業者、および生産量の市場価格が変動する他の企業など、より伝統的な商品生産者が直面するリスクに似ている。
【0121】
本発明の特定の要素、実施形態、及び用途を示し説明したが、特に上記教示に照らして、当業者によって変更を加えることが可能であるため、本発明はこれに限定されるものではないことがわかる。従って、添付の特許請求の範囲によって、そのような変更を網羅し、本発明の精神と範囲内に入るそれらの特徴を組み込むことが意図されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【手続補正書】
【提出日】2022-08-09
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
金融商品取引システムは、電子取引所と、電子清算機関と、を備え、
前記電子取引所は、ブロックチェーン対応暗号通貨の電子システムで機能する原資産である暗号通貨に基づいた暗号学的ディフィカルティを基にした金融商品の第１の市場価値を決定し、前記暗号通貨の電子システムは、Ｂ～Ｎの特性を有し、
Ｂは暗号通貨のブロック当たりの所定の報酬であり、前記原資産である暗号通貨のブロックインターバルに対してブロックチェーンプロトコルにより定義され、
Ｓは、前記原資産である暗号通貨のブロックチェーンプロトコルにより定義される所定の計算期間の秒単位の長さ、
Ｄは、前記第１の市場価値が決定された時に、前記原資産である暗号通貨のブロックチェーンプロトコルによって設定され、前記電子取引所によって電子的に受け取られる現在の難易度であり、
前記難易度は、前記ブロックチェーンプロトコルにより定期的に自動的に更新され、
前記難易度は、前記暗号通貨の前記ブロックの成功した暗号学的ハッシュを決定する最大ハッシュ値を表し、
Ｎは前記原資産である暗号通貨のブロックチェーンプロトコルによって定義されたナンス値の範囲であり、
Ｈは、前記電子取引所に電子的に格納された所与のハッシュレートであり、
前記電子取引所は、前記第１の市場価値を、
Ｒは前記第１の市場価値であり、
前記電子清算機関は、電子顧客口座を含むポジションデータベースを含み、前記電子顧客口座は、前記第１の市場価値と電子的に関連した前記暗号学的ディフィカルティを基にした金融商品における取引ポジションに電子的に関連しており、
前記電子清算機関は、前記暗号通貨のブロックチェーンプロトコルのＤの現在の値が、前記暗号学的ディフィカルティを基にした金融商品の前記第１の市場価値の決定に用いられたＤの値と異なることを電子的に決定し、
前記電子清算機関は、Ｄの現在の値を用いて前記暗号学的ディフィカルティを基にした金融商品の新しい市場価値を自動的に決定してＲを決定し、
前記電子清算機関は、前記取引ポジションと前記第１の市場価値を含む前記電子顧客口座を自動的に取得し、
前記電子顧客口座が前記暗号学的ディフィカルティを基にした金融商品におけるショートポジションを示し、前記新しい市場価値が前記第１の市場価値よりも大きい時には、
前記電子清算機関は、前記電子顧客口座と電子的に関連する暗号通貨ウォレットから前記電子清算機関と電子的に関連する暗号通貨ウォレットへの前記原資産である暗号通貨の電子的な移動を受け取り、前記移動された原資産としての暗号通貨の価値は、前記第１の市場価値と前記新しい市場価値の差に等しく、
前記電子顧客口座が前記暗号学的ディフィカルティを基にした金融商品におけるショートポジションを示し、前記新しい市場価値が前記第１の市場価値よりも小さい時には、
前記電子清算機関は、前記電子清算機関に電子的に関連した前記暗号通貨ウォレットから前記電子顧客口座に電子的に関連した前記暗号通貨ウォレットへの前記原資産である暗号通貨の電子的な移動を自動的に開始し、前記移動された原資産としての暗号通貨の価値は、前記第１の市場価値と前記新しい市場価値の差に等しい、
金融商品取引システム。
【請求項2】
前記原資産である暗号通貨は、ビットコインである、請求項１に記載のシステム。
【請求項3】
Ｈの値は、100TH/sである、請求項１に記載のシステム。
【請求項4】
Ｓの値は、1,209,600である、請求項１に記載のシステム。
【請求項5】
Ｎの値は、4,294,967,296である、請求項１に記載のシステム。
【請求項6】
前記難易度は、前記暗号通貨の2016ブロック後に更新される、
請求項１に記載のシステム。
【国際調査報告】