(57)【要約】  本明細書に記載の実施形態は、ブロックチェーン資産取引技術におけるハードウェア及びソフトウェアの改良を含む。１以上のサーバーが、１組の所定のルールに基づいて、あるメカニズムを自動的に実行する。該メカニズムは、ブロックチェーン資産取引の顧客が、取引相手を伴う（しかし取引相手のリスクを伴うことなく）ブロックチェーンを基礎としたデジタル資産（例えば、暗号通貨）に関するｓｔａｎｄｉｎｇ−ｌｉｍｉｔ又はマーケット注文を行うことを可能にする。取引相手は、顧客の取引注文が実行され、且つ顧客が所望の資産の所持（ｐｏｓｓｅｓｓｉｏｎ及びｏｗｎｅｒｓｈｉｐ）を得るまでは、支払いを受け取らない。一旦顧客が所望の資産を受け取ると、顧客は、取引相手からの支払いを戻したり、又は当該支払いを無効化することができない。システム及び方法は、ブロックチェーンデータベース、マルチ署名キー署名手順、及び、透明な、オブジェクト指向の、自動化された、ルールベースのソフトウェアエージェント管理を使用し、並びに、自動的に、複数団体の取引シナリオにおけるデジタルブロックチェーンを基礎とする資産の移動を支配し、ここで、資産損失のリスクを伴わず、そして、如何なる人間である行動者による裁量も伴わない。
2018536957.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータで実装される方法であって、以下を含む方法：
デジタル資産取引サービスを管理する取引サーバーによって、暗号化されたマルチ署名支払アカウントを生成すること、
ここで、前記支払アカウントは、クライアントコンピュータが生成する第１キー、前記取引サーバーが生成する第２キー、及びｏｒａｃｌｅサーバーが生成する第３キーによって暗号化され、そして、
前記支払アカウントは、前記第１キー、前記第２キー、及び前記第３キーのうち少なくとも２つのキーによって復号化されたときに、アクセス可能となる；
前記取引サーバーによって、第１パブリックブロックチェーン資産レコード、前記クライアントコンピュータから前記暗号化されたマルチ署名支払アカウントへの第１デジタル資産の移動を監視すること；
前記取引サーバーによって、第２パブリックブロックチェーン資産レコード、第２クライアントコンピュータから前記クライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を監視すること；並びに
前記取引サーバーによって、前記第２パブリックブロックチェーン資産レコードを通して、前記クライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を確認すること：
前記取引サーバーによって、前記第１デジタル資産の前記第１ブロックチェーンへ署名を行うこと、
ここで、前記ｏｒａｃｌｅサーバーは、前記第１ブロックチェーンに対して、前記第３キーを用いて署名を行う。
【請求項２】
請求項１の方法であって、更に以下を含む方法：前記取引サーバーにより、前記第２クライアントコンピュータに関連する支払アドレスへ、前記第２クライアントコンピュータに関連する第２クライアントへの前記第１デジタル資産のカストディを示すアップデートを送信すること。
【請求項３】
請求項１の方法であって、前記支払アカウントを生成することは、更に以下を含む、該方法：前記取引サーバーにより、前記クライアントコンピュータから、第１シード値を受け取ること。
【請求項４】
請求項３の方法であって、更に以下を含む方法：前記取引サーバーによって、前記第２キーを、前記クライアントコンピュータから受け取る前記第１シード値に基づいて、生成すること。
【請求項５】
請求項４の方法であって、更に以下を含む方法：前記取引サーバーによって、第２シードを、前記取引サーバーが生成する第２キーの一部に基づいて、生成すること。
【請求項６】
請求項５の方法であって、更に以下を含む方法：前記取引サーバーによって、前記第２シード及び前記第１シードを前記ｏｒａｃｌｅサーバーへ送信すること。
【請求項７】
請求項６の方法であって、前記ｏｒａｃｌｅサーバーが、前記第３キーを、前記第１シード及び前記第２シードに基づいて、生成する、該方法。
【請求項８】
請求項１の方法であって、前記取引サーバーが前記第１ブロックチェーンに署名をしたときに、更に以下を含む、該方法：
前記取引サーバーにより、アップデートを、前記第１ブロックチェーンを管理する複数の装置に送信すること、ここで、前記アップデートは、第１クライアントから第２クライアントへの前記第１デジタル資産のカストディを示す。
【請求項９】
請求項１の方法であって、前記第２デジタル資産の移動を確認することは、更に以下を含む、該方法：
前記取引サーバーによって、前記第２ブロックチェーンに対するアップデートを受け取り、該アップデートは、第２クライアントから第１クライアントへの前記第２デジタル資産のカストディを示す。
【請求項１０】
請求項１の方法であって、期限時間の閾値を超えたと判断したときに、更に以下を含む方法：
前記取引サーバーによって、前記第２ブロックチェーンを通して、前記第２デジタル資産の移動が発生しなかったことを確認すること：
前記取引サーバーによって、前記第１デジタル資産の前記第１ブロックチェーンへ署名を行うこと、ここで、前記ｏｒａｃｌｅサーバーは、前記第１ブロックチェーンに対して、前記第３キーを用いて署名を行う；並びに
前記取引サーバーによって、前記クライアントコンピュータに関連する返還アドレスへ、アップデートを送信し、前記アップデートは、前記第１クライアントコンピュータに関連する第１クライアントに対する前記第１デジタル資産のカストディを示す。
【請求項１１】
ブロックチェーンを基礎としたデジタル資産を取引するためのコンピューティング・システムであって、以下を含む、該システム：
プロセッサを備える１以上のサーバーコンピュータによって管理される取引サーバーであって、前記取引サーバーは、以下の動作を行うように構成される：
暗号化されたマルチ署名支払アカウントを生成すること、
ここで、前記支払アカウントは、クライアントコンピュータが生成する第１キー、前記取引サーバーが生成する第２キー、及びｏｒａｃｌｅサーバーが生成する第３キーに従って暗号化され、そして、
前記支払アカウントは、前記第１キー、前記第２キー、及び前記第３キーのうち少なくとも２つのキーによって復号化されたときにアクセス可能となる；
第１パブリックブロックチェーン資産レコード、前記クライアントコンピュータから前記暗号化されたマルチ署名支払アカウントへの第１デジタル資産の移動を監視すること；
第２パブリックブロックチェーン資産レコード、第２クライアントコンピュータから、前記クライアントコンピュータに関連する支払アドレスを有するアカウントへの第２デジタル資産の移動を監視すること；並びに
前記第２パブリックブロックチェーン資産レコードを通して、前記クライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を確認すること：
前記第１デジタル資産の前記第１ブロックチェーンに署名を行う、ここで、前記ｏｒａｃｌｅサーバーは、前記第１ブロックチェーンに対して、前記第３キーを用いて署名を行う。
【請求項１２】
前記取引サーバーは、以下の動作を行うよう更に構成される：前記第２クライアントコンピュータに関連する支払アドレスに、前記第２クライアントコンピュータに関連する第２クライアントへの前記第１デジタル資産のカストディを示すアップデートを送信すること。
【請求項１３】
前記取引サーバーは、以下の動作を行うよう更に構成される：
前記クライアントコンピュータから第１シード値を受け取ること；及び
前記第２キーを、前記クライアントコンピュータから受け取る前記第１シード値に基づいて、生成すること。
【請求項１４】
前記取引サーバーは、以下の動作を行うよう更に構成される：第２シードを、前記取引サーバーが生成する第２キーの一部に基づいて生成する。
【請求項１５】
前記取引サーバーは、以下の動作を行うよう更に構成される：前記第２シード及び前記第１シードを前記ｏｒａｃｌｅサーバーに送信すること。
【請求項１６】
前記取引サーバーが前記第１ブロックチェーンに署名したときに、前記取引サーバーは、以下の動作を行うよう更に構成される：
アップデートを、前記第１ブロックチェーンを管理する複数の装置に送信すること、ここで、前記アップデートは、前記第１デジタル資産のカストディが第１クライアントから第２クライアントへ変更されたことを示す。
【請求項１７】
前記取引サーバーは、以下の動作を行うよう更に構成される：前記第２ブロックチェーンに対するアップデートを受け取り、前記アップデートは、第２クライアントから第１クライアントへの前記第２デジタル資産のカストディを示し、これにより、前記第２デジタル資産の移動を確認すること。
【請求項１８】
前記取引サーバーが、期限時間の閾値を超えたと決定したときに、及び、
前記取引サーバーが、前記第２ブロックチェーンを通して、前記第２デジタル資産の移動が発生しなかったことを確認したときに、
前記取引サーバーは、前記第１デジタル資産の前記第１ブロックチェーンに署名するように更に構成され、及び、
ｏｒａｃｌｅサーバーは、前記第１ブロックチェーンに、前記第３キーを用いて署名するように更に構成される。
【請求項１９】
前記取引サーバーは、以下の動作を行うよう更に構成される：前記クライアントコンピュータに関連する返還アドレスへ、アップデートを送信し、前記アップデートは、前記第１クライアントコンピュータに関連する第１クライアントに対する前記第１デジタル資産のカストディを示す。
【請求項２０】
前記システムは、プロセッサを備える１以上のサーバーコンピュータによって管理される前記ｏｒａｃｌｅサーバー更に備え、前記ｏｒａｃｌｅサーバーは以下の動作を行うように構成される：
前記第３キーを、前記取引サーバーから受け取った前記第１シード及び前記第２シードに基づいて、生成すること；及び
前記第１デジタルブロックチェーンに、前記第３キーを用いて、前記第１デジタル資産のカストディに対するアップデート及び前記第２デジタル資産のカストディに対する対応するアップデートに従って、署名すること。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、自動的なルール及び自動的なマルチパーティコンファメーションを採用することによって、ブロックチェーン資産取引セキュリティを向上させること及び強化することに関する
【背景技術】
【０００２】
ブロックチェーン資産は、デジタルトークンであり（例えば、Ｂｉｔｃｏｉｎ）、これは、コンピュータによる暗号技術を利用して、取引を安全にし、及び新たな単位の生成をコントロールする。暗号通貨は、ブロックチェーン資産のサブセットである（「アルトコイン」、「デジタル通貨」、及び「仮想通貨」としても知られている）。Ｂｉｔｃｏｉｎは、ブロックチェーン資産の第１のポピュラーな例であり、そして、２００９年に最初の脱集中管理化の暗号通貨となった。現在、数多くのブロックチェーン資産が存在しており、以下のものが含まれる：暗号通貨、デジタルオーナーシップ、又は資産トークン、トークン化されたシェア及びセキュリティ等。決定的な特徴は、分散台帳システムであり、ブロックチェーンとして知られている。
【０００３】
ブロックチェーン資産は、世界中で取引が行われている。従来の非ブロックチェーン資産取引は、効率的な注文マッチングの自動化をもたらすが、管理（ｃｕｓｔｏｄｉａｎｓｈｉｐ）リスクに悩まされている。従来の取引では、顧客の資金をアカウントに保持し、取引を促進する。現代における全ての取引（ＮＡＳＤＡＱからＦＯＲＥＸのマーケット、従来のＢｉｔｃｏｉｎ取引）は、顧客の資金を保持し、その目的は、交換取引の注文記録を確立することにある。従って、顧客は、取引所が彼らのお金を保護するであろうという信頼をおかなくてはいけない。
【０００４】
非ブロックチェーン資産取引（従来のＮＡＳＤＡＱ又はＮＹＳＥのように）に関して、全ての資産は、契約ベースであり、又は紙ベースあり、中央データベースにて保存される。これらは、ブロックチェーン（脱集中化データベースに保存、又は、ローカルに保存される台帳）を基礎としたものではない。こうした理由から、これらの移動及び交換は、ほとんど、常に覆すことができてしまう。従って、ＮＡＳＤＡＱシステムがハッキングされ又は攻撃されると、結果として、顧客の収支変化が起こり、又は、悪意ある行為者が資金とともに逃亡することとなるが、ＮＡＳＤＡＱ（銀行とともに）は、最後の指示をロールバックでき、及び、顧客は彼らのお金を維持できる。その結果、従来の非ブロックチェーン取引は、顧客の信頼を獲得し、そして、維持してきており、並びに、リスクは管理可能である。
【０００５】
ブロックチェーンを基礎としたデジタル資産（例えばＢｉｔｃｏｉｎ）は、ピアツーピアネットワークの分散型データベースに依拠しており、データ記録の連続的に増大するリストを管理し、該記録は、改ざん及び変更に対して強化されている。こうした記録は、しばしば、暗号化技術的に強化され、そして、データストレージノードとして作用するマシン上で管理される。ブロックチェーン資産取引は、脱集中化コントロールを利用しており、これは、集中管理化された電子マネー／集中管理化されたバンキングシステムとは対極的である。
【０００６】
暗号通貨又はブロックチェーンを基礎とした資産に関して、しばしば、指示に関して、差し戻し不可能なものがある。もしも、悪意ある行為者が取引に割り込み、そして、顧客の収支を変更したり、又は資金を盗んだりしたら、これらの指示は差し戻しできない。資金は、何にも頼ることなく、アウトサイダー（又はインサイダー）によって盗まれる可能性がある。Ｂｉｔｃｏｉｎが創造されて以来、こうした問題は、数多く見られてきた。日本を拠点としたＭｔ．Ｇｏｘ  Ｂｉｔｃｏｉｎ取引の破たんは最も悪名高い。２０１４年、Ｍｔ．Ｇｏｘが破たんしたとき、４００万ドルを超える顧客のお金が消失した。お金が「消失」した理由は、Ｍｔ．Ｇｏｘが顧客のお金のカストディを持っていたためであった。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、取引所自体による資金のカストディがゼロであるブロックチェーン資産取引に関するニーズが存在する。必要とされるシステム及びのための方法は、ブロックチェーン資産取引を提供し、あるパーティと、取引相手となるパーティとに、彼らのブロックチェーン資産の所有物の交換に際してセキュリティを、取引相手リスクを伴うことなく提供することである。顧客は以下のような保障を必要としている。
【０００８】
所望の資産を（取引相手から）顧客が受け取るまでは、取引相手は顧客の支払いを受け取らない；逆に、取引相手は以下のような保障を必要としている：一旦注文が完結したら、顧客による支払った資金の差し戻しはできない。従って、必要とされるのは、以下を確認することができるメカニズムである：交換又は取引に対するパーティ（例えば、顧客、取引相手）は、彼らの予定の支払い又は資産を受け取り、その後で、システムが、対応する支払又は対応する資産をリリースすること。かくして、ルールベースの、コンピュータで実装される「ゼロカストディスイッチ」について説明する。これは、資金が適所にあることを確かなものとすることでコンピュータセキュリティを向上させ、そして、アクションを起こす前に、自動化されたマルチ署名認証を必要とする。その結果、如何なるパーティも他を信頼する必要がない。
【課題を解決するための手段】
【０００９】
本明細書に記載のシステム及び方法は、当分野での上述の欠点に取り組むことができ、及び、任意の数の追加の又は別の長所及び利点ももたらすことができる。本明細書に記載の実施形態は、以下を含むことができる：ブロックチェーン資産取引を管理することができるハードウェア及びソフトウェア構成要素。これにより、１以上のサーバーは、ソフトウェアを基礎とするメカニズムを実行して、取引顧客に対して以下のことを可能にする：取引相手に対して、ブロックチェーンを基礎としたデジタル資産（例えば、暗号通貨、Ｂｉｔｃｏｉｎ等）に関するｓｔａｎｄｉｎｇ−ｌｉｍｉｔ注文を行うこと。本システムは、あるメカニズム（「ゼロカストディスイッチ」）を説明するが、該メカニズムにより、暗号通貨及びブロックチェーンを基礎とした資産を、「ｂｉｄ」及び「ａｓｋ」注文において配置し、そして、管理（ｃｕｓｔｏｄｉａｎｓｈｉｐ）することなく交換できる。顧客は、当該交換において、市場注文又は制限（ｌｉｍｉｔ）注文を行うことができ、そして、これらを実行することができる。または、顧客の要求に応じて完全に返還できる。これらは、顧客又は交換に対してゼロリスクである。
【００１０】
一実施形態において、トランザクションは、両方のパーティにとって非カストディアルである；ブロックチェーン上、暗号技術的に安全となっており、その結果、如何なるパーティも単独では支払いを移動できず、そして、ユーザー定義した期間の後は、注文は期限切れとなるように構成される。顧客は以下の点が保証される：顧客が所望の資産を受け取るまで取引相手は支払いを受け取らない。こうした保証は、サードパーティルールを基礎とした「ｏｒａｃｌｅ」に部分的に基づき、これは、パブリックブロックチェーンデータベースに対するアップデートに基づいて、独立してトランザクションを確認することができる。同様に取引相手は以下の点が保証される：いったん、注文が完結し、そして、顧客が所望の資産を受け取ると、顧客は、支払いを差し戻したり、又は、取引相手から支払いを無効化することができない。
【００１１】
一実施形態において、コンピュータで実装される方法は以下のステップを含む：デジタル資産取引サービスを管理する取引サーバーによって、暗号化されたマルチ署名支払アカウントを生成すること、ここで、支払アカウントは、クライアントコンピュータが生成する第１キー、取引サーバーが生成する第２キー、及びｏｒａｃｌｅサーバーが生成する第３キーによって暗号化され、支払アカウントは、第１キー、第２キー、及び第３キーのうち少なくとも２つのキーによって復号化されたときに、アクセス可能となる；取引サーバーによって、第１パブリックブロックチェーン資産レコード、クライアントコンピュータから暗号化されたマルチ署名支払アカウントへの第１デジタル資産の移動を監視すること；取引サーバーによって、第２パブリックブロックチェーン資産レコード、第２クライアントコンピュータからクライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を監視すること；並びに取引サーバーによって、第２パブリックブロックチェーン資産レコードを通して、クライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を確認すること：取引サーバーによって、第１デジタル資産の第１ブロックチェーンへ署名を行うこと、ここで、ｏｒａｃｌｅサーバーは、第１ブロックチェーンに対して、第３キーを用いて署名を行う。
【００１２】
別の実施形態では、ブロックチェーンを基礎としたデジタル資産を取引するためのコンピューティング・システムであり、前記システムは、以下を含む：プロセッサを備える１以上のサーバーコンピュータによって管理される取引サーバー。取引サーバーは以下の動作を行うように構成される：暗号化されたマルチ署名支払アカウントを生成すること、ここで、支払アカウントは、クライアントコンピュータが生成する第１キー、取引サーバーが生成する第２キー、及びｏｒａｃｌｅサーバーが生成する第３キーに従って暗号化され、そして、支払アカウントは、第１キー、第２キー、及び第３キーのうち少なくとも２つのキーによって復号化されたときにアクセス可能となる；第１パブリックブロックチェーン資産レコード、クライアントコンピュータから暗号化されたマルチ署名支払アカウントへの第１デジタル資産の移動を監視すること；第２パブリックブロックチェーン資産レコード、第２クライアントコンピュータから、前記クライアントコンピュータに関連する支払アドレスを有するアカウントへの第２デジタル資産の移動を監視すること；並びに第２パブリックブロックチェーン資産レコードを通して、クライアントコンピュータに関連するアカウントへの第２デジタル資産の移動を確認すること：第１デジタル資産の第１ブロックチェーンに署名を行う、ここで、ｏｒａｃｌｅサーバーは、第１ブロックチェーンに対して、第３キーを用いて署名を行う。
【００１３】
理解されたい点として、上述した包括的な説明と以下の詳細な説明は、両方とも、例示的且つ説明目的にすぎず、特許請求の範囲に記載した本発明を更に説明することを意図している。
【図面の簡単な説明】
【００１４】
添付図は本明細書の一部を構成し、及び、本発明の実施形態を図示し、及び本明細書とともに、本発明を説明するためのものである。
【００１５】
【図１】本発明の実施形態の構成要素を示す。
【００１６】
【図２】本開示に従ったネットワーク実施形態の構成要素を描写する。
【００１７】
【図３】本開示の一実施形態におけるステップを描いたフローチャートを描写する。
【００１８】
【図４】本開示の一実施形態におけるステップを描いたフローチャートを描写する。
【００１９】
【図５】本開示の一実施形態におけるステップを描いたフローチャートを描写する。
【００２０】
【図６】本開示の一実施形態におけるステップを描いたフローチャートを描写する。
【００２１】
【図７】本開示の一実施形態において、資産を返却する際に使用するステップを示すフローチャートを描写する。
【発明を実施するための形態】
【００２２】
ここでは、本開示について、実施形態の一部を形成する図面に示した実施形態を参照しながら、詳細な説明を行う。本開示の思想又は範囲を逸脱することなく、他の実施形態を使用することができ、及び／又は、他の変更を行うことができる。詳細な説明に記載の例示的な実施形態は、ここで提示した主題を限定することを意味するわけではない。
【００２３】
一実施形態において、用語「ゼロカストディスイッチ」は、システム又は機構（メカニズム）を指し、これらは、ブロックチェーンを基礎とする資産に関する非カストディアルなｌｉｍｉｔ注文又はマーケットの注文の実施（及び従って機能的な金融取引注文記録）を完全に又は部分的に可能にする。非カストディアルな注文では、どのパーティも他のパーティ資産に関する所有権を有さない（その代わりに、これらは分散型のブロックチェーンを基礎とする、脱集中化マルチ署名アカウントにおいて保持される）。これにより、トランザクションが確認され且つ完了されるまで、内在する資産を潜在的な取引相手に晒すことが排除される。
【００２４】
典型的にはユーザーは、他人の１つのブロックチェーンを基礎とした資産を購入又は交換を望む。例えば、ＵｓｅｒＡはＣｏｉｎＡ（即ち、Ｂｉｔｃｏｉｎ）を所有し、当該ＣｏｉｎＡ売ることを、彼／彼女は望んでおり、そして、ＣｏｉｎＢ（即ち、Ｅｔｈｅｒｅｕｍ）を、１：１０の価格で購入することを望んでいるとする。取引所（Ｅｘｃｈａｎｇｅ）の企業は、売りたがっているＣｏｉｎＢを所有している可能性がある。ここで使用される用語「取引所」は、ブロックチェーン資産の売買元、又はブロックチェーン資産取引を指す。従って、ＵｓｅｒＡは、ＣｏｉｎＢの価格がＣｏｉｎＡの０．１倍に下落した時に実行する旨の注文を行うことを望む。ＵｓｅｒＡは常に以下の保証を望む：もしも価格目標が達成されない場合、注文は実行されず、そして、注文は取り消し可能又はキャンセル可能であること。また、ＵｓｅｒＡはまた、注文に対して、期間又は期限を設定することができ、これらは、所与のポイントで期限切れとなり、及びＵｓｅｒＡへの返還へのトリガーとなる。
【００２５】
一実施形態において、ＵｓｅｒＡは、取引所とともに、非カストディアルな注文を生成し、及び、資金を、取引所によって特定されるｍ／ｎのマルチ署名アドレスへ送る。一実施形態において、２／３のマルチ署名アドレスを使用するが、しかし、任意の他のレベルのマルチ署名アドレスを使用することができる。運用上、自動化された、ポリシーベースの、サードパーティであるｏｒａｃｌｅは、マルチ署名の連署者であってもよく、ある特定のルール及び状況に応じて、ＵｓｅｒＡ又は取引所のいずれかとともに取引所によるサインから独立して、又はこれによって運用されてもよい。一実施形態において、サードパーティであるｏｒａｃｌｅは、別会社であってもよいし、又は、あるサーバー上に存在するソフトウェア・アプリケーションであってもよい（脱集中化サーバーを含み、又は「デジタル自律性コーポレーション（ＤＡＯ）」として）。ｏｒａｃｌｅは、一旦確立されると、所有又は管理される必要がない。１組の所定のルールに基づいて、資金が取引所に行くのかユーザーに行くのかを決定するのは、本質的にはスイッチである。このスイッチの基本ルールは下記の通りである：もしも、所望の資金がユーザーに送られた場合（パブリックブロックチェーンによって規定される）、取引所とともにサインを行い、トランザクションを完了させる。２／３マルチシグアカウントを使用することで、如何なるパーティも任意のトランザクションにおいて一方的に作用することができないことを保証する。任意のトランザクションを完了させるために、３つのうち２つのパーティが同意してサインしなくてはならない。所望の資産が送信されたことが証明されるまで、取引所は、ユーザーの資金を受け取ることができない。そして、取引所が既に所望の資産の移動を証明してしまった場合には、ユーザーは資金を取り戻すことができない。ｏｒａｃｌｅは、反論不可のブロックチェーンデータに基づいて、１つのパーティ又はその他とともにサインをする。
【００２６】
いったん、ユーザーが注文を特定すると、取引所は、彼らにマルチ署名のブロックチェーン資産アドレスを付与する。当分野で理解されているが、マルチ署名アドレスは、複数の秘密鍵を必要とし、該鍵は、アカウントにアクセスしたり、及び資産を移動させるために使用される。これは、単に１つの署名しか必要としない通常のブロックチェーン資産トランザクションとは異なっている。通常のブロックチェーン資産トランザクションにおいて、ユーザーが、秘密鍵を持っている場合、お金を使用することができる。従来のブロックチェーン資産取引は、ユーザーのアカウントに関する秘密鍵を保持しており、及びこれが理由となって、管理（ｃｕｓｔｏｄｉａｎｓｈｉｐ）を有し、従って、取引相手のリスクがある。
【００２７】
いったん２つの署名を受け取ると（２／３マルチシグシナリオにおいて）、資産を移動させることができる。一実施形態において、もしも、ｏｒａｃｌｅ及び販売者（取引所）がサインした場合、資産は取引所へ移動する。もしも、ｏｒａｃｌｅ及びユーザーがサインした場合、ユーザーの資金はユーザーに戻る。部分的に注文が完了した場合、ｏｒａｃｌｅは、取引所に移動すべき資産の内、相当分に関してだけサインすることができ、そして、要求により、ユーザーに対して逆相当分だけサインする。いったん、所望のブロックチェーンを基礎としたデジタル資産の移動が発生すると、取引所又はｏｒａｃｌｅのいずれかが、当該トランザクションを、ブロックチェーンネットワーク上の全てのノードに広め、世界中でこれと同じトランザクションを記録する。この方法では、全てのブロックチェーン資産トランザクションと同様、中央サーバーが存在しない。パブリックなピアツーピアネットワーク上で、全てのブロックを基礎としたレポートが行われる。
【００２８】
一実施形態において、必要な署名を決定するために以下のルールを使用することができる。もしも、ＵｓｅｒＡが、ＣｏｉｎＢを、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓにて受け取った場合（完全に又は部分的に）、ｏｒａｃｌｅは取引所とともにサインをし、当該取引所はＣｏｉｎＡ受け取る（完全に又は部分的に）；もしも、ＵｓｅｒＡが、ＣｏｉｎＢを、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓにて受け取っていない場合、該ユーザーは、注文をキャンセルすることができ、又は期限切れになってもよい。いずれかの場合において、マルチ署名の連署者であるｏｒａｃｌｅは、ＵｓｅｒＡとともにサインし、その結果、ユーザーに、ユーザーのＣｏｉｎＡが戻され、ユーザーが指定したＲｅｆｕｎｄ＿Ａｄｄｒｅｓｓに戻される（注文が全く完遂しない場合には全部、及び注文の一部が完遂した場合には一部）。
【００２９】
ここで使用されるものとして、システムの実施形態の運用時に、４つのノートアドレスがある：Ｐａｙｍｅｎｔ＿Ａｄｄｒｅｓｓ、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓ、Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓ、及びＲｅｆｕｎｄ＿Ａｄｄｒｅｓｓ。しかし、当業者であれば以下の点を理解するであろう：様々な実施形態において、支払者、受取人、及び暗号通貨取引の責任を持つパーティを特定する目的で、任意の数のアドレスを含むことができ、又は、使用することができる。
【００３０】
Ｆｕｎｄｅｄ  Ｏｒｄｅｒは、非カストディアルな注文であり、ＣｏｉｎＡをＵｓｅｒＡから受け取る。Ｕｎｆｕｎｄｅｄ  Ｏｒｄｅｒは、非カストディアルな注文であり、ＣｏｉｎＡをＵｓｅｒＡからまだ受け取っていない。そして、Ｃｏｍｐｌｅｔｅｄ  Ｏｒｄｅｒは、非カストディアルな注文であり、ＣｏｉｎＢが、ＵｓｅｒＡに、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓへと送信され、取引を完結する。
【００３１】
Ｐａｙｍｅｎｔ＿Ａｄｄｒｅｓｓは、Ｆｕｎｄｅｄ  Ｏｒｄｅｒを生成するために、ＵｓｅｒＡがＣｏｉｎＡを送信しなければならないアドレスである。Ｆｉｎａｌ＿Ａｄｄｒｅｓｓは、注文が完了する場合又はその時に、ＣｏｉｎＢを送信してもらいたいとＵｓｅｒＡが望むアドレスである。Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓは、注文が完了しない場合、即ち、注文が期限切れとなる場合、ＣｏｉｎＡの返還送信してもらいたいとＵｓｅｒＡが望むアドレスである。更に言えば、Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓが存在し、該アドレスは、注文が完了したときに、取引所がＣｏｉｎＡを送信することを望むアドレスである。
【００３２】
一実施形態において、あるパーティにとって、別のパーティの資金を搾取したり、持っていくことができない。マルチシグアカウントから、資金を送信又は移動させるには、少なくとも２つの署名が必要である（２つのパーティから１つずつ）。もしも、２つの署名が無い場合には、資金は移動させることができない。従って、この均衡状態において、他者の承認なしでアクセスできるパーティは存在しない。もしも、取引所が、承認なく、ユーザーのお金を持っていこうと望む場合、ルールベースのｏｒａｃｌｅ又はユーザーに、彼らの署名を提供してもらうよう説得しなくてはならず、取引所は完結させることができない。
【００３３】
一実施形態において、以下の内容を、注文生成の際にｏｒａｃｌｅに送信する：Ｆｉｎａｌ＿Ａｄｄｒｅｓｓ（注文を完結させる際にＣｏｉｎＢを送信すべきユーザーのアドレス）；Ｅｘｐｅｃｔｅｄ  Ａｍｏｕｎｔ（注文を完結させる際に、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓに送信すべき量）；Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓ（Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓ又はＥｘｃｈａｎｇｅ＿Ａｄｄｒｅｓｓ、注文を完結させる際にＣｏｉｎＡの受け取り先となる）；Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓ（注文が完結しない場合にＣｏｉｎＡの受取先となるユーザーのアドレス）；及びＥｘｐｉｒａｔｉｏｎ＿Ｔｉｍｅ（注文を終了し、及びＣｏｉｎＡがＲｅｆａｎｄ＿Ａｄｄｒｅｓｓに返還された後のＵＴＣ日時）。一実施形態において、リターンデルタ（即ち、ユーザーが返還を要求した後、注文が完結しなかったことを確認するために、ｏｒａｃｌｅが待機する時間量）についても、変数として送信してもよく、又は、ｏｒａｃｌｅ内で特定の期間を設定してもよい。
【００３４】
一実施形態において、ＣｏｉｎＢに関して申し出価格が、ユーザーが望む価格とマッチする。この場合、取引所は、ＣｏｉｎＢの資金を、ユーザーのＦｉｎａｌ＿Ａｄｄｒｅｓｓに送信するであろう。取引所は、その後、ｏｒａｃｌｅに、ＣｏｉｎＡ資金をＭｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓへ移動させるための連署を要求する。ｏｒａｃｌｅは、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓをチェックし、そして、もしも、資金が、Ｅｘｐｅｃｔｅｄ  Ａｍｏｕｎｔ内に存在している場合には、ｏｒａｃｌｅは、取引所とともに、ＣｏｉｎＡ資金をＭｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓへ移動させる旨のサインを行う（完全に又は部分的に、これは、注文がどの程度完了したかに基づく）。
【００３５】
一実施形態において、もしも、ユーザーが注文をキャンセルしたい場合、ユーザーは、ｏｒａｃｌｅに、注文キャンセルの要求を送信することができる。ｏｒａｃｌｅは、所定の時間（リターンデルタ）待機し、そして、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓがいかなる預入資金も、Ｅｘｐｅｃｔｅｄ＿Ａｍｏｕｎｔにおいて受け取っていないことを確認するためのチェックを行う。その後、生成時に指定したＲｅｔｕｒｎ＿ＡｄｄｒｅｓｓへＣｏｉｎＡを移動させる旨のサインをユーザーとともに行う。
【００３６】
一実施形態において、ユーザーが注文をキャンセルしたい場合、ユーザーは、取引所に連絡して、注文をキャンセルすることができる。該実施形態において、ユーザーは、取引所と共に、ｏｒａｃｌｅの代わりに、キャンセルの確認を行い、及び取引所は、返還に関して連署する（最も可能性が高いのは手動で）。こうしたことは、例えば、ｏｒａｃｌｅがオフラインであったり、消失している場合に行われる。この方法で、注文が完結しない場合、又は、ｏｒａｃｌｅが消失した場合、ユーザーは、常に、ユーザーの資産を取り戻すことができる。
【００３７】
一実施形態において、注文が期限切れとなった場合、原因として、注文が完結することなく期限に達した場合、取引所又はユーザーが要求しなくても、全額返還が自動的に行われるであろう。期間経過すると、トランザクションは、ｏｒａｃｌｅによってサインされ、ＣｏｉｎＡがＲｅｔｕｒｎ＿Ａｄｄｒｅｓｓへ返還される。こうしたことを発生させるために、生成時に、Ｒｅｔｕｒｎトランザクションが、ｏｒａｃｌｅに付与され、そして、ユーザー鍵によるサインが行われる。こうしたことは、ｏｒａｃｌｅによって自動的に行われてもよく、又は、ｏｒａｃｌｅ無しでも、プロトコルを用いて行うことができる（例えば「ｃｈｅｃｋｌｏｃｋｔｉｍｅｖｅｒｉｆｙ」をブロックチェーン内に構築）（図７参照）。
【００３８】
一実施形態において、注文が完結する前に取引所が存在しなくなった場合、ｏｒａｃｌｅは、経過時間まで待って、通常通りのことを発生させる、又は、Ｒｅｔｕｒｎトランザクションに自動的にサインするのいずれかであってもよい（なぜならば、Ｏｒａｃｌｅは、既に、ＵｓｅｒＡによってＲｅｔｕｒｎトランザクションの連署がなされている）。該実施形態において、ＣｏｉｎＡは、Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓに送信される
【００３９】
一実施形態において、ｏｒａｃｌｅが存在しなくなったとしても、ユーザーに返還される。ｏｒａｃｌｅ以外に取引所と連署するものがいないという理由から、Ｌｉｍｉｔ注文を完結した場合、いったんｏｒａｃｌｅがもはや有効ではないと判断されると、取引所は、全てのＬｉｍｉｔ注文をキャンセルして、及びＣｏｉｎＡのユーザーへの返還のサインをそれぞれ行うことができる。
【００４０】
一実施形態において、ユーザーの鍵が盗まれたとしても、ユーザーは資金を失うことは無い。盗まれた鍵は、ＣｏｉｎＡをＲｅｆｕｎｄ＿Ａｄｄｒｅｓｓへ返還することを要求するためだけにしか使えない（なぜならば、ｏｒａｃｌｅはそのアドレスに連署するだけだからである）。このことは、ユーザーの鍵が盗まれたとしてもユーザーからリスクを除外し、そして、取引所及びｏｒａｃｌｅの責任を制限する。
【００４１】
一実施形態において、もしも、取引所の鍵が盗まれたとしても、取引所は資金を失うことは無い。なぜならば、Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓが生成時に設定され、このケースは、ユーザー鍵が盗まれた場合と同じだからである。鍵を盗んだパーティは、ＣｏｉｎＡを取引所に送ることができるに過ぎない。なぜならば、ｏｒａｃｌｅが連署するであろう唯一のアドレスだからである。従って、取引所の鍵が盗まれたとしても、取引所にとってリスクはない。
【００４２】
一実施形態において、取引所のシステムが悪化した場合、システム内の、顧客装置、ｏｒａｃｌｅ又は他のコンピュータは、全てのユーザー注文について、Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓへ返還するよう要求することができる。従来の取引とは違って、例示的なシステムにおいてこうしたことが起こった場合、ユーザーの資産は危険な状態にはなく、なぜならば、ｏｒａｃｌｅは悪化しておらず、ユーザーのＲｅｆｕｎｄ＿Ａｄｄｒｅｓｓへ資金を送信するだけだからである。
【００４３】
一実施形態において、ｏｒａｃｌｅが悪化したとしても、資金は安全である。もしもｏｒａｃｌｅが悪化した場合、悪意あるアドレスへのトランザクションにサインできるかもしれない。しかしこれは不可能である。なぜならば、ｏｒａｃｌｅは、暗号通貨の所有権を移動させるために、ユーザー又は取引所のいずれかとの連署が必要だからである。これにより、資金の損失が発生する前に、３つのエンティティのうち２つについて悪化させる必要がある。一実施形態において、もしも、ユーザー又は取引所が、ｏｒａｃｌｅが悪化していると確信した場合、どちらかが、一方的に、ユーザーの資金をＲｅｆｕｎｄ＿Ａｄｄｒｅｓｓへ返還するよう制定できる（なぜならば、各々は、既に、部分的にサインされた返還トランザクションを有しているからである）。
【００４４】
一実施形態において、生成時に、以下の情報がｏｒａｃｌｅからリターンされる：ｄｅｐｏｓｉｔ  ａｄｄｒｅｓｓ（即ち、注文をアクティベートするためにユーザーがＣｏｉｎＡを送信する先となるマルチシグアドレス）；ＴＸ  ｃｏｍｐｌｅｔｅ（Ｍｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓに対してまだサインされていないトランザクションであって、トランザクションを完了させるためにｏｒａｃｌｅがサインするべきもの）；及びＴＸ  ｒｅｔｕｒｎ＿ａ（Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓに対するトランザクションであって、ユーザー鍵及びｏｒａｃｌｅ鍵によってあらかじめサインがなされており、取引所へ与えられるもの）。一実施形態において、ＴＸ  ｒｅｔｕｒｎ＿ｂ（Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓに対するトランザクションであり、ユーザー鍵及び取引所の鍵によってサインされる）も、アカウント生成時にｏｒａｃｌｅへ送信することができる。
【００４５】
一実施形態において、新たな所有者への資金を移動すべきかどうかの唯一の決定が、ｏｒａｃｌｅと共にある（予め記載したルールに従う）。この理由として、取引所は、常にユーザーのお金を欲しがっていることから、自分自身に対する取引には常にサインしてしまう。そして、ユーザーは、新しい資産を欲しているため、自分自身への取引には常にサインしてしまう。従って資産スイッチを発生させるための権限を、ｏｒａｃｌｅに存在させ、ｏｒａｃｌｅは、コード内に、特定のルールだけを構築することができる。Ｏｒａｃｌｅは、公に利用可能なブロックチェーンを監視し、及びユーザーアカウントがその通貨を受け取ったかどうか、及びいつ受け取ったかを検出する。もし、移動を確認できる場合、第１のアクションをとる。もしも、取引を確認できない場合、第２のアクションをとることができる。資金が預けられた旨のパブリックなブロックチェーンに対するアップデートからの確認が行われるまで動作しない。ｏｒａｃｌｅは、パブリック情報に基づいて、ユーザー又は取引所の入力なしで、自動的に動作し、２つのパーティ間だけの利己的なトランザクションを、プログラム的に、公平で、安全で、誠実なものとする。もしも、充分で、客観的で、公に確認可能な条件を満たした場合、満たされた度合に比例して、ＣｏｉｎＡが取引所に移動する。もしも、条件を満たさない場合、満たさない度合に比例して、ＣｏｉｎＡは常にユーザーのもとへ戻される。
【００４６】
以下では、図面に示した例示的な実施形態について参照する。そして、具体的な言語を用いてこれらを説明する。しかし、以下の点を理解されたい：これにより、本発明の範囲を制限することを意図しているわけではない。ここで説明した発明に関する特徴の置換及び更なる変更、並びに、ここで説明した本発明の原理の更なる応用は、関連分野の当業者にとってなし得るものであり、そして、本開示に含まれるものであり、本発明の範囲内であると考える。
【００４７】
以下、例示的な本開示の実施形態が示される添付図を参照しながら、本開示について更に完全な形で説明する。しかし、本開示は、数多くの異なる形態で実施することができ、そして、必ずしも、例示的な本明細書に記載の実施形態に限定されるものとして解釈すべきではない。むしろ、こうした例示的実施形態を提供することで、当業者にとって、本開示が、本開示の概念に綿密に、そして、完全に、そして、充分に従うこととなる。更には、ある特定の例示的実施形態に関して説明した特徴は、様々な他の例示的実施形態中に、及び／又はこれとともに組み合わせることができる。本明細書に記載の例示的実施形態の異なる態様及び／又は要素は、同様の態様で組み合わせることができる。更に幾つかの例示的実施形態では、個別的及び／又は集合的にかかわらず、より大きなシステムの構成要素であってもよく、ここで、他の手順が、この応用において先立ってもよく、及び／又は、当該応用を変更してもよい。更に言えば、本明細書に記載の例示的実施形態の前、後、及び／又は同時に、複数のステップを必要としてもよい。以下の点を留意されたい：即ち、少なくとも本明細書に記載の任意の及び／又は全ての方法及び／又はプロセスは、任意の態様で、少なくとも１つのエンティティによって、少なくとも部分的に実行されてもよい。
【００４８】
ここで使用される用語は、直接的な又は間接的な、完全な又は部分的な、一時的な又は永遠の活動又は無活動を示唆することができる。例えばある要素が、他の要素に対して、「〜の上（ｏｎ）」、「接続され（ｃｏｎｎｅｃｔｅｄ）」又は「結合され（ｃｏｕｐｌｅｄ）」るものとして言及した場合、当該要素は、他の要素上に直接存在してもよく、接合されてもよく、又は結合されてもよく、及び／又は介在要素が存在してよく、直接的及び／又は間接的な変形を含む。一方で、ある要素が、他の要素に「直接接続」又は「直接結合」されるものとして言及した場合には、介在要素は存在しない。
【００４９】
本明細書では、用語として、第１、第２等を用いて、様々な要素、構成要素、領域、層及び／又はセクションを記載することができるが、これらの要素、構成要素、領域、層及び／又はセクションは、必ずしもこうした用語によって限定されるべきものではない。これらの用語は、一方の要素、構成要素、領域、層又はセクションを、別の要素、構成要素、領域、層又はセクションと区別するためだけに用いるにすぎない。従って、以下で議論する第１の要素、構成要素、領域、層又はセクションは、本開示の教示内容から逸脱することなく、第２の要素、構成要素、領域、層又はセクションと称してもよい。
【００５０】
ここで使用される用語は、特定の実施形態を説明することだけを目的としており、そして、本開示を限定することを必ずしも意図するものではない。本明細書で使用されるが、単数形「ａ」「ａｎ」及び「ｔｈｅ」は、文脈上明示しない限り、複数形も含むことを意図している。明細書で用いる際の用語「含む」（「ｃｏｍｐｒｉｓｅｓ」、「ｉｎｃｌｕｄｅｓ」及び／又は「ｃｏｍｐｒｉｓｉｎｇ」、「ｉｎｃｌｕｄｉｎｇ」）は、記述した特徴、整数、ステップ、操作、要素、及び／又は構成要素の存在を特定する、しかし、１以上の他の特徴、整数、ステップ、操作、要素、構成要素及び／又はこれらのグループの存在又は追加を排除するものではない。更に、選択的用語は、必ずしも排他的なものとして限定するべきではなく、包含的なものとしてもよい。
【００５１】
規定しない限り、ここで使用される全ての用語は、科学技術用語も含めて、本開示内容が属する分野の当業者が通常理解するのと同じ意味を有する。用語（例えば、通常使用する辞書で規定されるもの）は、関連分野の文脈での当該用語の意味と合致する意味を有するものとして解釈すべきであり、及び本明細書にてそのように明示的に規定しない限り、理想化されて、及び／又は過度にフォーマルな意味で解釈されるべきものではない。
【００５２】
本明細書で使用される用語「約」及び／又は「実質的に」は、記載した値／期間から最大で±１０％の変化及びこれを含むものを意味する。こうした変化は、こうした変化が具体的に特定されているかいないかにかかわらず、本明細書で記載された任意の所与の値／期間において常に含まれる。
【００５３】
任意の開示が参照により本明細書に組み込まれ、且つこうした開示が、部分的に及び／又は全体として、本開示と齟齬が生じている場合、齟齬の程度において、及び／又は、より広義な開示において、及び／又は、より広義な用語の意味において、本開示を優先する。こうした開示内容が互いに部分的に及び／又は全体として齟齬が生じている場合、齟齬の度合において、後日の開示内容を優先する。
【００５４】
図１は、例示的な実施形態に従った例示的なシステム（１００）の構成要素を示す。取引サービス（１０１）は、１以上の取引サーバー（１０３）及び１以上のトランザクションデータベース（１０５）を含む。取引サーバー（１０３）は、任意の汎用目的又は特定目的のコンピュータであってもよい。これは、単独のコンピュータであってもよく、これは、ハードウェア及び／又はソフトウェアサーバー、ワークステーション、デスクトップ、ラップトップ、タブレット、携帯電話、メインフレーム、スーパーコンピューター、サーバーファーム等々であってもよい。コンピュータは、直接的に及び／又は間接的に、以下によって動作し、及び／又は以下を代表して動作してもよい：取引所。コンピュータは、タッチスクリーン及び／又は非タッチスクリーンであってもよい。コンピュータは、別のコンピュータシステム及び／又はクラウドネットワークを含んでもよく、及び／又は、これらの一部であってもよい。コンピュータは任意のタイプのＯＳを実行することができる（例えばｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）及び／又は他のＯＳ）。コンピュータは、以下を含んでもよく、及び／又は以下と結合してもよい：入力装置（例えばマウス、キーボード、カメラ（前向き及び／又は後ろ向きに関係なく）、アクセラメーター、タッチスクリーン及び／又はマイクロフォン）及び／又は出力装置（例えば表示装置、スピーカー、及び／又は印刷装置）。コンピュータは、ネットワーク（１０２）と通信している（例えば直接的に及び／又は間接的に）。こうした通信は、ソフトウェア・アプリケーション、モバイルアプリ、ブラウザ、ＯＳ及び／又は任意のこれらの組合せを介したものであってもよい。コンピュータは、全地球測位のための回路を含むことができる（例えばＧＰＳ、信号の三角測量システム等々を介して）。コンピュータは、ＮＦＣ回路を備えてもよい。コンピュータはデータベースを実行してもよく（例えばリレーショナルデータベース）、これらはユーザー情報及びアカウント情報を含む。
【００５５】
トランザクションデータベース（１０５）は、別個のデータベースであってもよく、又はコンピュータ若しくは取引サーバー（１０３）を管理するコンピュータに組み込まれてもよい。これらは、リレーショナルデータベース、フラットファイル、セグメント化データベース、又は任意の他の形態若しくは構造であってもよい。データベース（１０５）は、取引サービス（１０１）によって管理されてもよく、又は、サードパーティによって管理されてもよい。顧客装置（１０７）は、モバイル装置、タブレット、コンピュータ、ラップトップ、ポータブル・コンピューティング・デバイス、静止したコンピューティング・デバイス、データ入力端末又はダム端末であってもよい。これらは、有線の若しくは無線の装置であってもよく、そして、スタンドアロン型の装置であってもよく、又はネットワークと結合した物であってもよい。
【００５６】
サードパーティコンピュータ（１０９）は、コンピュータ又はサーバーであってもよく、これは、ハードウェア及び／又はソフトウェアサーバー、ワークステーション、デスクトップ、ラップトップ、タブレット、携帯電話、メインフレーム、スーパーコンピューター、サーバーファーム等々であってもよい。コンピュータは、直接的に及び／又は間接的に、以下によって動作し、及び／又は以下を代表して動作してもよい：ｏｒａｃｌｅ。コンピュータは、タッチスクリーン及び／又は非タッチスクリーンであってもよい。コンピュータは、別のコンピュータシステム及び／又はクラウドネットワークを含んでもよく、及び／又は、これらの一部であってもよい。コンピュータは任意のタイプのＯＳを実行することができる（例えばｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）及び／又は他のＯＳ）。コンピュータは、以下を含んでもよく、及び／又は以下と結合してもよい：入力装置（例えばマウス、キーボード、カメラ（前向き及び／又は後ろ向きに関係なく）、アクセラメーター、タッチスクリーン及び／又はマイクロフォン）及び／又は出力装置（例えば表示装置、スピーカー、及び／又は印刷装置）。コンピュータは、ネットワーク（１０２）と通信している（例えば直接的に及び／又は間接的に）。こうした通信は、ソフトウェア・アプリケーション、モバイルアプリ、ブラウザ、ＯＳ及び／又は任意のこれらの組合せを介したものであってもよい。コンピュータは、全地球測位のための回路を含むことができる（例えばＧＰＳ、信号の三角測量システム等々を介して）。コンピュータは、ｏｒａｃｌｅアプリケーションを実行してもよい。
【００５７】
１以上のネットワーク（１０２）は、複数のノードを含むことができ（例えば通信チャンネルによって相互接続されるコンピュータ及び／又は他のハードウェアの集合）、これにより、リソース及び／又は情報の共有を可能にすることができる。こうした相互接続は直接的及び／又は間接的であってもよい。ネットワーク（１０２）は、有線であってもよく、及び／又は無線であってもよい。ネットワーク（１０２）は、近距離及び／又は長距離にわたる通信を可能にすることができる。ネットワーク（１０２）は、少なくとも１つのネットワークプロトコルを介して動作することができる（例えばイーサネット（登録商標）、伝送コントロールプロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）等々）。ネットワーク（１０２）は、任意のスケールであってもよい（例えばパーソナル・エリア・ネットワーク、ローカル・エリア・ネットワーク、ホーム・エリア・ネットワーク、ストレージ・エリア・ネットワーク、キャンパス・エリア・ネットワーク、バックボーン・ネットワーク、メトロポリタン・エリア・ネットワーク、ワイド・エリア・ネットワーク、エンタープライズ・プライベート・ネットワーク、バーチャル・プライベート・ネットワーク、バーチャル・ネットワーク、衛星ネットワーク、コンピュータ・クラウド・ネットワーク、インターネットワーク、セルラー・ネットワーク、等々）。ネットワーク（１０２）は、イントラネット及び／若しくはエキストラネットであってもよく、並びに／又は、イントラネット及び／若しくはエキストラネットを含んでもよい。ネットワーク（１０２）は、インターネットであってもよく、及び／又はインターネットを含んでもよい。ネットワーク（１０２）は、他のネットワークを含んでもよく、及び／又は、他のネットワークとの通信を可能にするものであってもよい（サブネットワークであるか及び／又は固有のネットワークであるかを問わず、ネットワーク（１０２）との同一及び／又は相違を問わず）。ネットワーク（１０２）は、ハードウェアを含むことができる（例えばネットワーク・インターフェース・カード、リピータ、ハブ、ブリッジ、スイッチ及び／又はファイアウォール）。ネットワーク（１０２）は、１以上のエンティティによって、及び／又はこれを代表して、直接的に及び／又は間接的に動作してもよい。
【００５８】
図２は、本開示のネットワーク環境の例示的実施形態を示す。例示的なシステム（２０）の環境は、ネットワーク（２０４）、ＵｓｅｒＡ（２００）、ｏｒａｃｌｅ（２０１）及び取引所（２０２）を含む。
【００５９】
ネットワーク（２０４）は、複数のノードを含むことができ（例えば通信チャンネルによって相互接続されるコンピュータ及び／又は他のハードウェアの集合）、これにより、リソース及び／又は情報の共有を可能にすることができる。こうした相互接続は直接的及び／又は間接的であってもよい。ネットワーク（２０４）は、有線であってもよく、及び／又は無線であってもよい。ネットワーク（２０４）は、近距離及び／又は長距離にわたる通信を可能にすることができる。ネットワーク（２０４）は、少なくとも１つのネットワークプロトコルを介して動作することができる（例えばイーサネット（登録商標）、伝送コントロールプロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）及び等々）。ネットワーク（２０４）は、任意のスケールであってもよい（例えばパーソナル・エリア・ネットワーク、ローカル・エリア・ネットワーク、ホーム・エリア・ネットワーク、ストレージ・エリア・ネットワーク、キャンパス・エリア・ネットワーク、バックボーン・ネットワーク、メトロポリタン・エリア・ネットワーク、ワイド・エリア・ネットワーク、エンタープライズ・プライベート・ネットワーク、バーチャル・プライベート・ネットワーク、バーチャル・ネットワーク、衛星ネットワーク、コンピュータ・クラウド・ネットワーク、インターネットワーク、セルラー・ネットワーク、等々）。ネットワーク（２０４）は、イントラネット及び／若しくはエキストラネットであってもよく、並びに／又は、イントラネット及び／若しくはエキストラネットを含んでもよい。ネットワーク（２０４）は、インターネットであってもよく、及び／又はインターネットを含んでもよい。ネットワーク（２０４）は、他のネットワークを含んでもよく、及び／又は、他のネットワークとの通信を可能にするものであってもよい（サブネットワークであるか及び／又は固有のネットワークであるかを問わず、ネットワーク（２０４）との同一及び／又は相違を問わず）。ネットワーク（２０４）は、ハードウェアを含むことができる（例えばネットワーク・インターフェース・カード、リピータ、ハブ、ブリッジ、スイッチ及び／又はファイアウォール）。ネットワーク（２０４）は、１以上のエンティティによって、及び／又はこれを代表して、直接的に及び／又は間接的に動作してもよい（ＵｓｅｒＡ（２００）、ｏｒａｃｌｅ（２０１）及び／又は取引所（２０２）との関係性に関連なく）。
【００６０】
ＵｓｅｒＡ（２００）はコンピュータを操作し、これは、ハードウェア及び／又はソフトウェアサーバー、ワークステーション、デスクトップ、ラップトップ、タブレット、携帯電話、メインフレーム、スーパーコンピューター、サーバーファーム等々であってもよい。コンピュータは、直接的に及び／又は間接的に、以下によって動作し、及び／又は以下を代表して動作してもよい：ＵｓｅｒＡ（２００）。コンピュータは、タッチスクリーン及び／又は非タッチスクリーンであってもよい。コンピュータは、別のコンピュータシステム及び／又はクラウドネットワークを含んでもよく、及び／又は、これらの一部であってもよい。コンピュータは、任意のタイプのオペレーティングシステム（ＯＳ）を実行することができる（例えばｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）及び／又は他のＯＳ）。コンピュータは、以下を含んでもよく、及び／又は以下と結合してもよい：入力装置（例えばマウス、キーボード、カメラ（前向き及び／又は後ろ向きに関係なく）、アクセラメーター、タッチスクリーン及び／又はマイクロフォン）及び／又は出力装置（例えば表示装置、スピーカー、及び／又は印刷装置）。コンピュータは、ネットワーク（２０４）と通信している（例えば直接的に及び／又は間接的に）。こうした通信は、ソフトウェア・アプリケーション、モバイルアプリ、ブラウザ、ＯＳ及び／又は任意のこれらの組合せを介したものであってもよい。コンピュータは、全地球測位のための回路を含むことができる（例えばＧＰＳ、信号の三角測量システム等々を介して）。コンピュータは、近距離無線通信（ＮＦＣ）回路を備えてもよい。
【００６１】
ｏｒａｃｌｅ（２０１）は、コンピュータを操作し、これは、ハードウェア及び／又はソフトウェアサーバー、ワークステーション、デスクトップ、ラップトップ、タブレット、携帯電話、メインフレーム、スーパーコンピューター、サーバーファーム等々であってもよい。コンピュータは、直接的に及び／又は間接的に、以下によって動作し、及び／又は以下を代表して動作してもよい：ｏｒａｃｌｅ（２０１）。コンピュータは、タッチスクリーン及び／又は非タッチスクリーンであってもよい。コンピュータは、別のコンピュータシステム及び／又はクラウドネットワークを含んでもよく、及び／又は、これらの一部であってもよい。コンピュータは任意のタイプのＯＳを実行することができる（例えばｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）及び／又は他のＯＳ）。コンピュータは、以下を含んでもよく、及び／又は以下と結合してもよい：入力装置（例えばマウス、キーボード、カメラ（前向き及び／又は後ろ向きに関係なく）、アクセラメーター、タッチスクリーン及び／又はマイクロフォン）及び／又は出力装置（例えば表示装置、スピーカー、及び／又は印刷装置）。コンピュータは、ネットワーク（２０４）と通信している（例えば直接的に及び／又は間接的に）。こうした通信は、ソフトウェア・アプリケーション、モバイルアプリ、ブラウザ、ＯＳ及び／又は任意のこれらの組合せを介したものであってもよい。コンピュータは、全地球測位のための回路を含むことができる（例えばＧＰＳ、信号の三角測量システム等々を介して）。コンピュータは、ＮＦＣ回路を備えてもよい。コンピュータはデータベースを実行してもよく（例えばリレーショナルデータベース）、これらはユーザー情報及び／又はアカウント情報を含む。取引所（２０２）は、コンピュータを操作し、これは、ハードウェア及び／又はソフトウェアサーバー、ワークステーション、デスクトップ、ラップトップ、タブレット、携帯電話、メインフレーム、スーパーコンピューター、サーバーファーム等々であってもよい。コンピュータは、直接的に及び／又は間接的に、以下によって動作し、及び／又は以下を代表して動作してもよい：ｏｒａｃｌｅ（２０１）。コンピュータは、タッチスクリーン及び／又は非タッチスクリーンであってもよい。コンピュータは、別のコンピュータシステム及び／又はクラウドネットワークを含んでもよく、及び／又はこれらの一部であってもよい。コンピュータは任意のタイプのＯＳを実行することができる（例えばｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）及び／又は他のＯＳ）。コンピュータは、以下を含んでもよく、及び／又は以下と結合してもよい：入力装置（例えばマウス、キーボード、カメラ（前向き及び／又は後ろ向きに関係なく）、アクセラメーター、タッチスクリーン及び／又はマイクロフォン）及び／又は出力装置（例えば表示装置、スピーカー、及び／又は印刷装置）。コンピュータは、ネットワーク（２０４）と通信している（例えば直接的に及び／又は間接的に）。こうした通信は、ソフトウェア・アプリケーション、モバイルアプリ、ブラウザ、ＯＳ及び／又は任意のこれらの組合せを介したものであってもよい。コンピュータは、全地球測位のための回路を含むことができる（例えばＧＰＳ、信号の三角測量システム等々を介して）。コンピュータは、ＮＦＣ回路を備えてもよい。コンピュータはデータベースを実行してもよく（例えばリレーショナルデータベース）、これらは支払情報を含む。
【００６２】
ＵｓｅｒＡ（２００）は、ネットワーク（２０４）と通信している（例えば直接的、間接的、暗号化、非暗号化、及びその他）。ＵｓｅｒＡ（２００）は、ネットワーク（２０４）を介して、ｏｒａｃｌｅ（２０１）及び／又は取引所（２０２）のうち少なくとも１つと選択的に通信してもよい（例えば直接的、間接的、暗号化、非暗号化、及びその他）。
【００６３】
ＵｓｅｒＡ（２００）は、消費者及び／又は法人（例えば組織、会社、パートナーシップ、及び／又はその他）であってもよい。ｏｒａｃｌｅ（２０１）は、ネットワーク（２０４）と通信している（例えば直接的、間接的、暗号化、非暗号化、及びその他）。ｏｒａｃｌｅ（２０１）は、ネットワーク（２０４）を介して、ＵｓｅｒＡ（２００）及び取引所（２０２）のうち少なくとも１つと、選択的に通信している（例えば直接的、間接的、暗号化、非暗号化、及びその他）。例えば、ｏｒａｃｌｅ（２０１）は、取引所（２０２）に関する取引所（２０２）のアクアイアラと通信してもよい。例えば、ｏｒａｃｌｅ（２０１）は、Ｅメール又は任意の他の通信手段を介して、ＵｓｅｒＡ（２００）と通信してもよい。
【００６４】
ｏｒａｃｌｅ（２０１）は、金融機関（例えば銀行）、取引所、セキュアサーバー、及び／又は、その他、及び／又は任意の他の組織を含むことができ、これらは、ブロックチェーン資産の取引及び管理に従事している。
【００６５】
ｏｒａｃｌｅは、金融機関であってもよく、これは、取引所（２０２）に関するブロックチェーン資産トランザクションの受領及び／又は処理を行う（取引所（２０２）のアカウントの借方又は貸方を含む）。こうした受領及び／又は処理は、取引所（２０２）を介してＵｓｅｒＡ（２００）に提供される商品及び／又はサービスのためである。ｏｒａｃｌｅは、また、サーバー若しくは一連のサーバーであってもよく、又は、コンピュータ若しくはサーバー上で自動的に実行されるアプリケーション若しくは一連のアプリケーションであってもよい。取引所（２０２）は、ネットワーク（２０４）と通信している（例えば直接的、間接的、暗号化、非暗号化、及びその他）。取引所（２０２）は、ネットワーク（２０４）を介して、ＵｓｅｒＡ（２００）及びｏｒａｃｌｅ（２０１）のうち少なくとも１つと選択的に通信している（例えば直接的、間接的、暗号化、非暗号化、及びその他）。取引所（２０２）は、個人の、組織の、及び／又はビジネスの受領ブロックチェーン資産トランザクションを含む（直接的及び／又は間接的にかかわらず）。取引所（２０２）は、営利法人、非営利法人、政府機関、及び／又はその他を含む。取引所（２０２）は、オンライン取引所、実店舗の取引所、及び／又は任意のこれらの組合せを含む。以下の点を留意されたい：即ち、本明細書において、任意の量の売買元又は取引所（２０２）を使用することができる。ＵｓｅｒＡ（２００）は取引所（２０２）であってもよく、及び／又は取引所（２０２）はＵｓｅｒＡ（２００）であってもよい。
【００６６】
図３は、本開示に従った実施形態を示す。ＵｓｅｒＡ（２００）は、非カストディアルな注文（ＮＣＯ）トランザクション要求（３０４）を、取引所（２０２）と共に生成し、その際に、ＵｓｅｒＡが所持し且つ交換を望むＣｏｉｎＡの種類、及び任意でその量を指定する。ＵｓｅｒＡは、以下を指定する：コインの種類、ＵｓｅｒＡが獲得を望むＣｏｉｎＢ、ＣｏｉｎＢの所望の価格、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓ、Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓ、及び注文をどれくらいの長さで行うべきか、即ち、期間（時間又は日）。一実施形態において、ＣｏｉｎＢのＥｘｐｅｃｔｅｄ  Ａｍｏｕｎｔは価格から自動的に確立される。
【００６７】
これに応じて、ｏｒａｃｌｅ（２０１）は、これらの指定された基準を用いて、Ｕｎｆｕｎｄｅｄ  Ｏｒｄｅｒ（３０５）を生成し、そして、ＵｓｅｒＡに対して、ＣｏｉｎＡを、２／３マルチシグのＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに送信するよう要求する。ＵｓｅｒＡ、ｏｒａｃｌｅ及び取引所は、みな、公開鍵機能に基づいて、鍵を生成し、そして、どのパーティも他のパーティの鍵を見ることができない。ユーザーの鍵については、明示的にユーザーに提示されるか、又は、ユーザーのブラウザウィンドウ内（クライアントサイド）に安全に保持されるかのいずれかが行われてもよい。
【００６８】
いったん、Ｕｎｆｕｎｄｅｄ  Ｏｒｄｅｒが確立されると、ＵｓｅｒＡは、ＣｏｉｎＡを、指定されたＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに送信する。ステップ（３０６）にて、ＵｓｅｒＡがＣｏｉｎＡを指定のＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに送信した旨のコンファメーションをシステムは待つ。コンファメーションについては、ブロックチェーン情報を監視し、資金がいつ移動したのかを決定することによって得られる。いったん支払いのコンファメーションが行われると、注文は、Ｕｎｆｕｎｄｅｄ  Ｏｒｄｅｒから、Ｆｕｎｄｅｄ  Ｏｒｄｅｒへと移行する（３０７）。もしも、ＵｓｅｒＡ（２００）が特定の期間内に支払を送信しない場合、Ｕｎｆｕｎｄｅｄ  Ｏｒｄｅｒは、ｏｒａｃｌｅ（２０１）によってクローズされる。この時点で、ＣｏｉｎＡは、２／３マルチ署名アカウント内に保持され、３つの鍵については、ＵｓｅｒＡ、ｏｒａｃｌｅ及び取引所それぞれによって保持される。
【００６９】
ステップ（３０８）にて、システムは、ＵｓｅｒＡが注文をキャンセルしたかどうかを決定する。もしも注文がＵｓｅｒＡ（２００）によってキャンセルされた場合、キャンセルの時点でＣｏｉｎＢのＥｘｐｅｃｔｅｄ  ＡｍｏｕｎｔがＦｉｎａｌ＿Ａｄｄｒｅｓｓにないのであれば、ｏｒａｃｌｅ（２０１）はＵｓｅｒＡへの返還にサインを行う。もしも注文がキャンセルされていない場合、システムはステップ（３０９）へと進む。ステップ（３０９）にて、システムは、注文期間が過ぎていないかどうかを見るためのチェックを行う。もしも、ステップ（３０９）において、期限経過が原因となって注文が期限切れとなった場合、ｏｒａｃｌｅ（２０１）は、ステップ（３１０）にて、ＵｓｅｒＡのＣｏｉｎＡを、Ｒｅｆｕｎｄ＿Ａｄｄｒｅｓｓに返送する。この方法では、全ての注文は、完了するか、キャンセルされるか、又は期限切れとなるかのいずれかであり、そして、ｏｒａｃｌｅはＵｓｅｒＡのコイン、又は取引所のｃｏｉｎＢを保持することは無い。当該システムはＵｓｅｒＡ（２００）にとって安全であり、なぜならば、取引所（２０２）は、ＣｏｉｎＢをＵｓｅｒＡに送信した後でなければ、ＵｓｅｒＡのＣｏｉｎＡを取ることができないからである。本開示において、当該システムは、いったんｃｏｉｎＢが送信された後の取引所にとっての安全性をもたらし、なぜならば、ＵｓｅｒＡは、いったんＣｏｉｎＢが送信されると注文をキャンセルできないからである。そして、ＵｓｅｒＡにとってもリスクが無く、なぜならば、ＵｓｅｒＡのＣｏｉｎＡは、トランザクションがキャンセルされたり、又は期限切れになると、返還されるからである。
【００７０】
一実施形態において、ステップ（３１２）でのｏｒａｃｌｅ（２０１）によるＥｘｐｅｃｔｅｄ  Ａｍｏｕｎｔのチェックは、「競合」条件を防止するためにＵｓｅｒＡのサインを受け取ったいくばくかの時間後に行われる。一実施形態において、こうしたことは、ＵｓｅｒＡのサインを関連するクライアントコンピュータから受け取った後のおおよその時間（任意の時間を用いても良いが）で行ったが、しかし、期間は、任意の短い期限であってもよい。もしも、ステップ（３１２）において、ＣｏｉｎＢのＥｘｐｅｃｔｅｄ  ＡｍｏｕｎｔがＦｉｎａｌ＿Ａｄｄｒｅｓｓにない場合、ｏｒａｃｌｅ（２０１）は、ステップ（３０８）で注文がキャンセルされるか、又はステップ（３０９）で期限切れになっているのであれば、ＣｏｉｎＡをＵｓｅｒＡに送信する移動動作にサインをし、そうでない場合には、ステップ（３１１）にて、取引所（２０２）がｃｏｉｎＢをＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに送信するのを待つ。
【００７１】
もしも、取引所（２０２）が、ステップ（３１３）にて、ＣｏｉｎＢのＥｘｐｅｃｔｅｄ  Ａｍｏｕｎｔを、Ｆｉｎａｌ＿Ａｄｄｒｅｓｓに送信している場合、ｏｒａｃｌｅは、取引所への支払いにサインをし、そして、ｏｒａｃｌｅは、ＣｏｉｎＡをＭｅｒｃｈａｎｔ＿Ａｄｄｒｅｓｓに送信し、及び、ｃｏｉｎＢを、ＵｓｅｒＡへ、指定のＦｉｎａｌ＿Ａｄｄｒｅｓｓに送信し、注文を完結させる。
【００７２】
図４は、公開鍵の生成及び注文完了に用いられるシステム及び方法及びステップの別の実施形態を説明する。ステップ（４０１）にて、データをＵｓｅｒＡによって、ブロックチェーン資産取引に従事する要求を示すブラウザ又は他の入力ポータルから入力する。一実施形態において、ユーザーアカウントを生成してデータ入力を促進する。別の実施形態では、アカウントは必要ではなく、及び注文データが、単純に、ユーザー、取引所及びｏｒａｃｌｅの間に送信される。
【００７３】
ＵｓｅｒＡは、注文量、交換通貨、及び注文を適所で維持すべき期間を入力することができる。また、ＵｓｅｒＡは、情報を入力して、公開鍵Ｋｅｙ１を生成する。他のユーザーがアクセスできないクライアントサイドのコードを用いるＵｓｅｒＡのブラウザは、公開鍵Ｋｅｙ１を生成する。このことにより、公開鍵がＵｓｅｒＡ以外誰にもアクセスできないことを保証する。いったんＫｅｙ１が生成されると、当該鍵は保存される。トランザクションにおいて重要となるデータ及びＫｅｙ１は、ステップ（４０２）にて取引所に渡される。ステップ（４０３）にて、取引所は、ＵｓｅｒＡが生成したＫｅｙ１を用いて、公開鍵Ｋｅｙ２を生成し、及びトランザクションに必要な任意の他のデータを生成する。これらの鍵は、マルチシグアカウント上でのサインとして作用する。
【００７４】
いったん、Ｋｅｙ２が生成されると、ステップ（４０４）にて、ユーザーの公開鍵Ｋｅｙ１及び取引所の公開鍵Ｋｅｙ２が両方ともｏｒａｃｌｅへ送信される。ステップ（４０５）にて、ｏｒａｃｌｅは、受け取った情報をすべて用いて、公開鍵Ｋｅｙ３を生成し、そして、これを、Ｋｅｙ１及びＫｅｙ２を組み合わせて、マルチシグアカウントに関するＤｅｐｏｓｉｔ＿Ａｄｄｒｅｓｓを生成する。ステップ（４０６）にて、ｏｒａｃｌｅは、このアドレスを、取引所へ戻す。取引所は、ステップ（４０７）にて、データを用いて、ｕｎｆｕｎｄｅｄ  Ｌｉｍｉｔ注文を生成する。ステップ（４０８）にて、Ｄｅｐｏｓｉｔ＿ＡｄｄｒｅｓｓがＵｓｅｒＡに送信される。ステップ（４０９）にて、ＵｓｅｒＡは、Ｄｅｐｏｓｉｔ＿Ａｄｄｒｅｓｓへ資金を移動させる。
【００７５】
図５は、本開示のシステム及び方法における第２ステップを描写する。ステップ（５０１）にて、取引所は、ネットワーク上のブロックチェーンデータをチェックし、ステップ（４０５）にて生成されたＤｅｐｏｓｉｔ＿Ａｄｄｒｅｓｓに資金が送信されたかどうかを確認する。いったん、ＵｓｅｒＡが当該アドレスに資金を送信したことのコンファメーションがなされると、ステップ（５０２）にて、取引所は、ユーザートランザクションへのリターンを生成し、サインする。ステップ（５０３）にて、ユーザートランザクションへのリターン及びｒｅｔｕｒｎ＿ａドキュメントが、保存のためにｏｒａｃｌｅへ送信される。これは、実質的には、ユーザーからのリターンアドレスである。リターンアドレスは、資金をユーザーに返還することができる唯一のアドレスである。これはセキュリティ目的で行われ、この結果、誰かがユーザーの鍵に後でアクセスしたり、アドレスを変更したり、異なるアドレスへ通貨を送信させたりすることができない。実質的には、取引所がこのリターンのトランザクションにサインをし、そして、これを、保存のためにｏｒａｃｌｅに付与する。かくして、もしも、ｏｒａｃｌｅがユーザーに返還を行う必要がある場合、既に取引所からはＯＫのサインをもらっている。また、ステップ（５０４）にて、ｏｒａｃｌｅは、このリターンに対するトランザクションへサインをし、そして、ステップ（５０５）にて、保存のために、これを、取引所に送信する。ステップ（５０６）にて、取引所は、リターンアドレスを保存し、そして、注文をアクティベートする。このことにより、もしもｏｒａｃｌｅが消失したとしても、取引所がユーザーに返還できることを保証する。この時点では、取引所は見かけ上注文を遂行しようとする。図５に示すように、ユーザーの資金をユーザーに返還できるのは、ｏｒａｃｌｅ又は取引所が消失し、そして、マルチシグアカウントにサインするのに必要なときに利用できない場合である。
【００７６】
図６は、本開示のシステム及び方法の一実施形態において、第３ステップを描写する。図６のステップ（６００）にて、Ｌｉｍｉｔ注文はアクティブである。ステップ（６００）から、可能性として、３つのシナリオがある。注文が完了する場合、注文が期限切れとなる場合、又は注文がキャンセルされる場合である。もしも注文が完了する予定の場合、取引所システムは、以下の点を検索し及び決定する：その注文が実際に完了できるかどうか、そして、いつ完了できるか、即ち、あるアカウントがあって、取引所自体又は他のユーザーがＵｓｅｒＡと取引を行いたいかどうか。
【００７７】
ステップ（６０１）にて、取引所は、取引所で、ＵｓｅｒＡの注文を（完全に又は部分的に）満たすレートを見つける。ステップ（６０２）にて、取引所は、トランザクションを生成し、そして、資金の取引を行う。その後、ステップ（６０３）にて、取引所は、要求された量を（完全に又は部分的に）、ＵｓｅｒＡのアカウントであるＦｉｎａｌ＿Ａｄｄｒｅｓｓに送信する。いったんこれが完了すると、ステップ（６０４）にて、取引所は、預けた資金をそのアカウントへ移動させるトランザクションを要求し、そして、連署のためにその情報をｏｒａｃｌｅに送信する。ステップ（６０５）にて、ｏｒａｃｌｅは、ブロックチェーン上のＦｉｎａｌ＿Ａｄｄｒｅｓｓを確認することにより、資金が（完全に又は部分的に）ＵｓｅｒＡに送信されたことを、自動的にコンファームする。取引の成功を確認したら、ｏｒａｃｌｅは、そのトランザクションにサインをし（全量又は各々一部）、そして、そのトランザクションを広め、そして、その情報を、取引所に戻す。この時点で、取引所は、自身に対するトランザクションを広め、そして、トランザクションを完了させるために必要な２つのサインを有する。ステップ（６０６）にて、いったん２つのサインを受け取ると、ユーザーの資金は、取引所に預けられる。
【００７８】
別のシナリオにおいて、注文は完了する前に期限切れとなる。もしも、Ｌｉｍｉｔ注文がステップ（６０１）にて満たされる前に、ステップ（６１０）にて注文が期限切れとなれば、こうしたことは、起こる可能性がある。一実施形態において、ユーザーが、もともと、ステップ（４０１）にて、ユーザーの注文及びアカウントを設定するときに、ユーザーが入力したデータの一部分は、期限時間であり、この時点で、注文が満たされないと、自動的にユーザー返還される（もしも注文が部分的に満たされている場合には部分的に返還される）。
【００７９】
ステップ（６１０）にて期限時間に到達すると、ｏｒａｃｌｅは時間切れを認知し、そして、ステップ（６１１）にて、取引所がステップ（６０４）において既にサインした返還にサインをする。その結果、ステップ（６１２）にて、資金を、ユーザーのアドレスに返還することができる。一実施形態において、期限に到達するまで、又は注文が満たされるまで、ユーザーは、ステップ（６２０）にて、任意の時間で、注文をキャンセルする旨の決定を行うことができる。
【００８０】
通常は、ｏｒａｃｌｅに連絡するが、ステップ（６２１）において、一実施形態において、取引所も資金を返還することができる。ステップ（６２２）にて、取引所又はｏｒａｃｌｅは、待機して、その後、取り消し用のアドレスに資金が供給されていないことを確認するためのチェックを行う。基本的には、ユーザーが取引所をだまし取ろうとしているわけではないことを確認する。いったん情報がコンファームされると、ｏｒａｃｌｅは、ｒｅｔｕｒｎ＿ａにサインを行い、その結果、ステップ（６２３）にて、資金はユーザーのもとへ返還することができる。何かしらの理由で、ｏｒａｃｌｅが消失した場合、ステップ（６２４）にて、ユーザーは、返還を求めて取引所に連絡する。ステップ（６２５）にて、取引所は、取り消し用のアドレスを確認することで、注文が満たされていないことをコンファームする。このことがコンファームされると、その後、取引所は、ｒｅｔｕｒｎ＿ｂにサインを行い、そして、ステップ（６２６）にて、資金が、ユーザーに返還される。こうしたことが可能となる理由は、ｏｒａｃｌｅが返還に関して予めサインを行っていたからである。一実施形態において、最初に任意のキャンセルが起こった場合、まずは、ｏｒａｃｌｅを通すことを試みる。なぜならば、自動的に処理されるからである。何かしらの理由でｏｒａｃｌｅが応答しない場合、取引所も通貨を返還することができ、その結果、資金は、誰もアクセスできないところへ失われることもない。
【００８１】
図７は、ｏｒａｃｌｅ及び取引所の両方が消失した場合にユーザーに返還するための実施形態を示す。ステップ（７０１）にて、取引所は、ブロックチェーンを監視することにより、ユーザーがＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに資金を提供したことを検出する。いったん資金が検出されると、ステップ（７０２）にて、取引所は、ＲｅｔｕｒｎトランザクションをユーザーのＲｅｔｕｒｎ＿Ａｄｄｒｅｓｓに対して生成し、これは、注文期限日及びバッファ時間（例えば、７日間）に関するｏｐ＿ｃｈｅｃｋｌｏｃｋｔｉｍｅｖｅｒｉｆｙを指定する。ｏｒａｃｌｅは、ステップ（７０３）にて、このトランザクションに連署し、そして、ステップ（７０４）にてこれを広める。ユーザーはＲｅｔｕｒｎトランザクションがブロックチェーン上で適所にあることを理解できる。しかし、所定の時間が経過するまで、且つ注文が完結せず、又はしばらくしてキャンセルされた場合、ブロックチェーンにおいてコンファームは行われない。
【００８２】
これは、Ｂｉｔｃｏｉｎの特徴である「ＣｈｅｃｋＬｏｃｋＴｉｍｅ」と類似しており、ユーザーにとって、トランザクションを完結し、及びこれらを広めることを可能にするが、しかし、トランザクションは、特定の時間までは、「有効」にならず、又は「コンファーム」されない。本開示において、取引所は、Ｒｅｔｕｒｎトランザクションを広め、その後、ｏｒａｃｌｅ及び取引所がオフラインになろうとも、又は消失しようとも、所定の時間までに完了しなければ、ユーザーは資産を取り戻すことができる。もしも、注文がユーザーのもとへ戻った場合、又は、成功して完了した場合、ｏｐ＿ｃｈｅｃｋｌｏｃｋｔｉｍｅｖｅｒｉｆｙトランザクションは無効になり、なぜならば、資金はすでに送信されているからである。本明細書に記載の実施形態に関連して記載した様々な例示的論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子的ハードウェア、コンピュータソフトウェア又は両者の組合せとして実装できる。ハードウェア及びソフトウェアのこうした相互置換性を明示するべく、様々な例示的な構成要素、ブロック、モジュール、回路、及びステップを、これらの機能の観点から包括的に上述してきた。こうした機能性をハードウェアとして実装するか、又はソフトウェアとして実装するかについては、システム全体に課せられる特定の応用及び設計の制約に依存する。当業者は、各々特定の応用のために様々な方法で、記載の機能を実装することができる。しかし、こうした実装に関する決定は、本発明の範囲から逸脱することをもたらすものと解釈すべきではない。
【００８３】
コンピュータソフトウェアにおいて実装される実施形態は、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、又は任意のこれらの組合せにて実装することができる。コードセグメント又は機械が実行可能な指示は以下を表すことができる：プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、又は指示の組合せ、データ構造又はプログラムステートメント。コードセグメントは、情報、データ、引数、パラメーター又はメモリコンテンツを渡したり及び／又は受け取ったりすることによって、別のコードセグメント又はハードウェア回路と結合してもよい。情報、引数、パラメーター、データ等は、任意の適切な手段（メモリ共有、メッセージ渡し、トークン渡し、ネットワーク伝送等を含む）によって、渡されたり、送られたり、又は送信されたりしてもよい。
【００８４】
これらのシステム及び方法を実装するために使用される実際のソフトウェアコード又は特化したコントロールハードウェアは、本発明を限定するものではない。従って、システム及び方法の動作及び振る舞いは、特定のソフトウェアコードに言及することなく説明してきたが、本明細書の記載に基づいてシステム及び方法を実装するために、ソフトウェア及びコントロールハードウェアを設計することができることを理解されたい。
【００８５】
ソフトウェア内で実装するときには、関数を、１以上の指示又はコードとして、非一時的なコンピュータ可読記憶媒体又はプロセッサ可読記憶媒体上に記憶することができる。本明細書に記載の方法又はアルゴリズムのステップは、プロセッサ実行可能ソフトウェアモジュール内で実施することができ、これらは、コンピュータ可読記憶媒体又はプロセッサ可読記憶媒体上に存在してもよい。非一時的なコンピュータ可読媒体又はプロセッサ可読媒体は、コンピュータストレージ媒体及び有形のストレージ媒体の両方を含み、これらは、コンピュータ・プログラムを１つの場所から別の場所へ移動させることを促進する。非一時的なプロセッサ可読ストレージ媒体は、コンピュータがアクセスできる任意の利用可能な媒体であってもよい。例示的な意味で、及び非限定的な意味で、こうした非一時的なプロセッサ可読媒体は、以下を含むことができる：ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光学ディスクストレージ、磁気ディスクストレージ、又は他の磁気ストレージ・デバイス又は任意の他の有形のストレージ媒体。これらは、所望のプログラムコードを、指示又はデータ構造の形式で記憶するのに用いることができ、そして、コンピュータ又はプロセッサによってアクセス可能である。ここで使用されるディスク及びディスクは、以下を含む：コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光学的ディスク、デジタルヴァーサタイルディスク（ＤＶＤ）、フロッピーディスク（登録商標）、及びブルーレイ（登録商標）ディスク、ここで、ディスクは通常データを磁気的に再現するが、一方で、ディスクは、レーザーにより、データを光学的に再現する。上述の組合せはまた、コンピュータ可読媒体の範囲内に含まれるべきものである。更に言えば方法又はアルゴリズムの操作は、非一時的なプロセッサ可読媒体及び／又はコンピュータ読取可能媒体上で、１つの又は任意の組合せ又はセットのコード及び／又は指示として存在してもよく、コンピュータ・プログラム製品に組み込まれてもよい。
【００８６】
当業者が本発明を製造又は使用できるように、本開示の実施形態を上述した。これらの実施形態に対する様々な変更が、当業者にとって容易に明らかとなるであろう。そして、本発明の思想又は範囲から逸脱することなく、本明細書に記載した包括的な原理を、他の実施形態に適用することができる。従って、本発明は、ここに示した実施形態に限定されることを意図するものではなく、以下の特許請求の範囲及び本明細書に記載の原理及び新規な特徴に合致する最も広い範囲に従ったものとすべきである。
【００８７】
様々な態様及び実施形態を開示してきたが、他の態様及び実施形態も企図している。開示した様々な態様及び実施形態は例示目的であり、そして、限定することを意図してない。ここで、真の範囲及び思想は、以下の特許請求の範囲に示される。
【図１】
2018536957.tif 000003
【図２】
2018536957.tif 000004
【図３】
2018536957.tif 000005
【図４】
2018536957.tif 000006
【図５】
2018536957.tif 000007
【図６】
2018536957.tif 000008
【図７】
2018536957.tif 000009
【手続補正書】
【提出日】平成30年8月9日(2018.8.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ゼロカストディスイッチを介してデジタル資産の交換を注文する方法であって、以下のステップを含む、該方法：
第１デジタル資産と第２デジタル資産との非カストディアルな交換のための制限注文要求を生成するステップ、ここで、前記第１デジタル資産は顧客によって保持され、前記第２デジタル資産は取引相手によって保持される；
顧客の秘密鍵及び顧客の公開鍵を含む暗号技術的な鍵のペアを生成するステップ；
Ｏｒａｃｌｅに、返還アドレス、最終支払アドレス、及び前記顧客の公開鍵を送信するステップ；
負債を有する支払アドレスを受け取るステップ；並びに
前記第１デジタル資産のネットワークに、預入トランザクションを広めるステップ、ここで、前記預入トランザクションは、前記第１デジタル資産の購入量を前記支払アドレスに移動させる。
【請求項２】
請求項１の方法であって、更に以下のステップを含む、該方法：
前記顧客の秘密鍵を用いて返還トランザクションに予めサインをするステップ；及び
前記返還トランザクションを前記Ｏｒａｃｌｅに送信するステップ。
【請求項３】
請求項１の方法であって、前記負債は、前記顧客の秘密鍵、取引相手の秘密鍵、及びＯｒａｃｌｅの秘密鍵のうち少なくとも２つのデジタル署名によって充足される、該方法。
【請求項４】
請求項１の方法であって、前記制限注文要求は期限時間を含み、そして、前記負債を充足する少なくとも１つのロック解除スクリプトは、前記期限時間に少なくとも部分的に依存する、該方法。
【請求項５】
請求項１の方法であって、前記第１デジタル資産は、第１共有台帳上で追跡され、前記第２デジタル資産は第２共有台帳上で追跡される、該方法。
【請求項６】
請求項１の方法であって、更に以下のステップを含む、該方法：
前記顧客の秘密鍵を用いて返還トランザクションにサインをするステップ；及び
前記第１デジタル資産の購入量を返還する要求とともに、返還トランザクションを前記取引相手に送信するステップ。
【請求項７】
ゼロカストディスイッチを介してデジタル資産の交換を安全にする方法であって、以下のステップを含む、該方法：
第１デジタル資産と第２デジタル資産との非カストディアルな交換のための注文要求を受け取るステップ、ここで、前記第１デジタル資産は顧客によって保持され、前記第２デジタル資産は取引相手によって保持され、前記要求は前記顧客の最終支払アドレスを含む；
取引相手の公開鍵及び取引相手の秘密鍵を含む暗号技術的な鍵のペアを生成するステップ；
支払アドレスを受け取るステップ、ここで、前記支払アドレスは負債を有し、前記取引相手の秘密鍵、顧客の秘密鍵、及びＯｒａｃｌｅの秘密鍵のうち少なくとも２つのデジタル署名に少なくとも依存する；
前記支払アドレスが資金条件を充足するかどうかを決定するステップ；及び
前記支払アドレスが前記資金条件を充足するかどうかに少なくとも部分的に基づいて、１以上の完了トランザクションを広めるステップ。
【請求項８】
請求項７の方法であって、前記１以上の完了トランザクションを広めるステップは以下を含む、該方法：
もしも前記支払アドレスが前記資金条件を充足する場合、前記第２デジタル資産のネットワーク上に交換トランザクションを広めること、ここで、前記交換トランザクションは、アウトプットとして、前記顧客の最終支払アドレスを有する；
リリーストランザクションを出力すること、ここで、前記リリーストランザクションは、取引相手アドレスへの前記支払アドレスにおいて資金を消費する；
前記取引相手の秘密鍵を利用して前記リリーストランザクションにサインすること；
前記リリーストランザクションをＯｒａｃｌｅに伝送すること、ここで、前記リリーストランザクションは、前記Ｏｒａｃｌｅの秘密鍵を用いて前記リリーストランザクションにサインを行う旨の要求を含む。
【請求項９】
請求項７の方法であって、更に以下のステップを含む、該方法：
前記Ｏｒａｃｌｅが動作不能であることを決定すること、ここで、前記１以上の完了トランザクションは、前記顧客の秘密鍵及び前記取引相手の秘密鍵によってサインされる返還トランザクションを含む。
【請求項１０】
請求項７の方法であって、前記非カストディアルな交換のための注文要求は、所望量の前記第１デジタル資産及び所望量の前記第２デジタル資産を含む、該方法。
【請求項１１】
請求項７の方法であって、前記支払アドレスを受け取る動作は、更に以下を含む、該方法：
顧客の公開鍵及びＯｒａｃｌｅの公開鍵を受け取ること；並びに
前記取引相手の公開鍵、前記顧客の公開鍵、及び前記Ｏｒａｃｌｅの公開鍵に少なくとも部分的に基づいて前記支払アドレス上に前記負債を生成すること。
【請求項１２】
請求項７の方法であって、前記交換トランザクションが前記注文要求を部分的に満たし、前記方法は更に以下のステップを含む、該方法：
部分的な返還トランザクションを出力するステップ、ここで前記部分的な返還トランザクションは、前記交換トランザクションの値と前記注文要求に含まれる要求交換量との差を規定する；
前記取引相手の秘密鍵を用いて前記部分的な返還トランザクションにサインをするステップ；並びに
前記Ｏｒａｃｌｅの秘密鍵を用いて前記部分的な返還トランザクションにサインをする旨の要求とともに、前記部分的な返還トランザクションを前記Ｏｒａｃｌｅに送信するステップ。
【請求項１３】
請求項７の方法であって、更に以下のステップを含む、該方法：
前記Ｏｒａｃｌｅの秘密鍵を用いて予めサインされた返還トランザクションを前記Ｏｒａｃｌｅから受け取るステップ、ここで、前記返還トランザクションは、前記顧客の返還アドレスへ前記支払アドレスを消費し、前記１以上の完了トランザクションは前記返還トランザクションを含む。
【請求項１４】
ゼロカストディスイッチを動作させるための指示がエンコードされた非一時的なコンピュータ可読媒体であって、前記指示は以下を含む、該媒体：
第１デジタル資産と第２デジタル資産との交換のための注文要求を受け取ること、ここで、前記注文要求は顧客の最終支払アドレスと前記顧客の返還アドレスとを含む；
顧客の公開鍵と取引相手の公開鍵とを受け取ること；
Ｏｒａｃｌｅの秘密鍵とＯｒａｃｌｅの公開鍵とを含む鍵のペアを生成すること；
前記注文要求に資金移動するための支払アドレスを受け取ること、ここで、前記支払アドレスは負債を有する；
前記支払アドレスが資金条件を充足するかどうかを決定すること；
前記顧客の最終支払アドレスが最終支払条件を充足するかどうかを決定すること；並びに、
前記Ｏｒａｃｌｅの秘密鍵を用いて完了トランザクションにサインをすること、ここで、前記完了トランザクションは、前記資金条件及び前記最終支払条件が充足される場合、取引相手アドレスへの前記支払アドレスにおいて資金を消費するリリーストランザクションであり、前記完了トランザクションは、前記最終支払条件が充足されない場合、前記顧客の返還アドレスへの前記支払アドレスにおいて資金を消費する返還トランザクションである。
【請求項１５】
請求項１４の非一時的コンピュータ可読媒体であって、前記第１デジタル資産は、第１共有台帳上で追跡され、前記第２デジタル資産は第２共有台帳上で追跡される、該媒体。
【請求項１６】
請求項１５の非一時的コンピュータ可読媒体であって、前記指示は更に以下を含む、該媒体：
前記Ｏｒａｃｌｅの秘密鍵を用いて前記完了トランザクションにサインをする動作の前に競合条件期間が経過するまで待機すること。
【請求項１７】
請求項１４の非一時的コンピュータ可読媒体であって、前記非一時的なコンピュータ可読媒体は、コンセンサスルールに従って脱集中化ネットワーク上で実行され、前記第１デジタル資産及び第２デジタル資産は前記脱集中化ネットワーク上で追跡される、該媒体。
【請求項１８】
請求項１４の非一時的コンピュータ可読媒体であって、前記指示は更に以下を含む、該媒体：
前記顧客から前記注文要求をキャンセルするための返還要求を受け取ること、ここで、前記返還要求は前記完了トランザクションを含み、前記完了トランザクションは、顧客の返還アドレスへの前記支払アドレスにおいて資金を消費する返還トランザクションであり、前記完了トランザクションは更に前記顧客の秘密鍵によって署名される；並びに
前記最終アドレスが前記受領要求を充足しない場合に、前記返還トランザクションにサインすること。
【請求項１９】
請求項１４の非一時的コンピュータ可読媒体であって、更に以下を含む、該媒体：
前記注文要求の期限を経過したことを決定すること；
前記顧客の最終支払アドレスが前記最終支払条件を充足しないことを決定すること；並びに
前記顧客返還アドレスへの前記支払アカウントにおいて資金を消費する返還トランザクションにサインすること、ここで、前記負債は前記期間経過によって充足され、署名は前記Ｏｒａｃｌｅの秘密鍵によってなされる。
【請求項２０】
請求項１４の非一時的コンピュータ可読媒体であって、前記支払アドレスを受け取る動作は、前記支払アドレス上に前記負債を生成することを含み、ここで、前記負債は、取引相手の秘密鍵、顧客の秘密鍵、及び前記Ｏｒａｃｌｅの秘密鍵のうち少なくとも２つのデジタル署名に少なくとも部分的に基づく、該媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２７
【補正方法】変更
【補正の内容】
【００２７】
いったん２つの署名を受け取ると（２／３マルチシグシナリオにおいて）、資産を移動させることができる。一実施形態において、もしも、ｏｒａｃｌｅ及び販売者（取引所）がサインした場合、資産は取引所へ移動する。もしも、ｏｒａｃｌｅ及びユーザーがサインした場合、ユーザーの資金はユーザーに戻る。部分的に注文が完了した場合、ｏｒａｃｌｅは、取引所に移動すべき資産の内、相当分に関してだけサインすることができ、そして、要求により、ユーザーに対して残り分だけサインする。いったん、所望のブロックチェーンを基礎としたデジタル資産の移動が発生すると、取引所又はｏｒａｃｌｅのいずれかが、当該トランザクションを、ブロックチェーンネットワーク上の全てのノードに広め、世界中でこれと同じトランザクションを記録する。この方法では、全てのブロックチェーン資産トランザクションと同様、中央サーバーが存在しない。パブリックなピアツーピアネットワーク上で、全てのブロックを基礎としたレポートが行われる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００７０
【補正方法】変更
【補正の内容】
【００７０】
一実施形態において、ステップ（３１２）でのｏｒａｃｌｅ（２０１）によるＥｘｐｅｃｔｅｄ  Ａｍｏｕｎｔのチェックは、「競合」条件を防止するためにＵｓｅｒＡのサインを受け取ったいくばくかの時間後に行われる。一実施形態において、こうしたことは、ＵｓｅｒＡのサインを関連するクライアントコンピュータから受け取った後のおおよその時間（任意の時間を用いても良いが）で行ったが、しかし、期間は、任意の短い期限であってもよい。もしも、ステップ（３１２）において、ＣｏｉｎＢのＥｘｐｅｃｔｅｄ  ＡｍｏｕｎｔがＦｉｎａｌ＿Ａｄｄｒｅｓｓにない場合、ｏｒａｃｌｅ（２０１）は、ステップ（３０８）で注文がキャンセルされるか、又はステップ（３０９）で期限切れになっているのであれば、ＣｏｉｎＡをＵｓｅｒＡに送信するトランザクションにサインをし、そうでない場合には、ステップ（３１１）にて、取引所（２０２）がｃｏｉｎＢをＰａｙｍｅｎｔ＿Ａｄｄｒｅｓｓに送信するのを待つ。
【国際調査報告】
2018536957.tif 000010