IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

特表2024-537593ブロックチェーンベースのトランザクションプロトコル
<>
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図1
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図2
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図3A
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図3B
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図3C
  • 特表-ブロックチェーンベースのトランザクションプロトコル 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-16
(54)【発明の名称】ブロックチェーンベースのトランザクションプロトコル
(51)【国際特許分類】
   H04L 9/32 20060101AFI20241008BHJP
   H04L 67/141 20220101ALI20241008BHJP
   H04L 67/00 20220101ALI20241008BHJP
【FI】
H04L9/32 200B
H04L9/32 200E
H04L67/141
H04L67/00
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024505579
(86)(22)【出願日】2022-09-21
(85)【翻訳文提出日】2024-03-27
(86)【国際出願番号】 EP2022076270
(87)【国際公開番号】W WO2023046779
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】2113527.2
(32)【優先日】2021-09-22
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】アンドリュー・ジェームズ・ミー
(57)【要約】
本開示は、顧客(100)とマーチャント(130)との間のトランザクションを処理するための方法、デバイスおよびシステムを提案する。方法は、マーチャントデバイスにおいて実施され得る。方法は、顧客に関連付けられた顧客デバイスから顧客情報を受信するステップと、顧客情報に基づいて、顧客とマーチャントとの間のセキュアな通信チャネル(125)を確立するステップと、顧客情報に基づいて、部分的インボイストランザクションを生成するステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションを顧客デバイスへ送るステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションの完了バージョンであるとともに顧客デバイスにおいて認可されたトランザクションを受信するステップと、トランザクションを認証するステップと、認証されたトランザクションを、ブロックチェーン(155)に提出されるようにブロックチェーンノード(150)にブロードキャストするステップと、トランザクションがブロックチェーンノードによって認証され、ブロックチェーン上に含まれるという少なくとも1つの通知を受信するステップとを含み得る。
【特許請求の範囲】
【請求項1】
顧客とマーチャントとの間のトランザクションを処理するための、マーチャントデバイスにおいて実施される、コンピュータにより実施される方法であって、
前記顧客に関連付けられた顧客デバイスから顧客情報を受信するステップと、
前記顧客情報に基づいて、前記顧客と前記マーチャントとの間のセキュアな通信チャネルを確立するステップと、
前記顧客情報に基づいて、部分的インボイストランザクションを生成するステップと、
前記セキュアな通信チャネルを介して、前記部分的インボイストランザクションを前記顧客デバイスへ送るステップと、
前記セキュアな通信チャネルを介して、前記部分的インボイストランザクションの完了バージョンであるとともに前記顧客デバイスにおいて認可されたトランザクションを受信するステップと、
前記トランザクションを認証するステップと、
前記認証されたトランザクションを、ブロックチェーンに提出されるようにブロックチェーンノードにブロードキャストするステップと、
前記トランザクションが前記ブロックチェーンノードによって認証され、前記ブロックチェーン上に含まれるという少なくとも1つの通知を受信するステップと
を含む、コンピュータにより実施される方法。
【請求項2】
前記顧客情報は、購入注文および前記顧客の別名を含む、請求項1に記載の方法。
【請求項3】
前記顧客の前記別名は、前記マーチャントデバイスの外部のサーバに関連して検証される、請求項2に記載の方法。
【請求項4】
前記顧客情報を受信するステップは、前記クライアントと前記マーチャントとの間のハンドシェイク手順を確立する、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記セキュアな通信チャネルは、前記マーチャントデバイスの外部のチャネルサーバに関連して確立される、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記セキュアな通信チャネルは、通信が、前記マーチャントから前記顧客へと、前記顧客から前記マーチャントへの両方で送られることを許可する、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記セキュアな通信チャネルはエンドツーエンド暗号化される、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記部分的インボイストランザクションを生成するステップは、マーチャントウォレットに関連して、トランザクションテンプレートに1つまたは複数のトランザクション出力を投入するステップを含む、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記トランザクションは、顧客ウォレットに関連付けられた1つまたは複数のトランザクション入力を含み、
前記1つまたは複数のトランザクション入力は、少なくとも、前のトランザクションのマークルルートを含む、請求項1から8のいずれか一項に記載の方法。
【請求項10】
前記トランザクションは、確認された祖先の、マークルプルーフと、完全なトランザクションとをさらに含むデータ構造にカプセル化される、請求項9に記載の方法。
【請求項11】
前記トランザクションを認証するステップは、
前記前のトランザクションのマークルルートを個別に構築するステップと、
前記構築されたマークルルートを、前記1つまたは複数のトランザクション入力の前記マークルルートでクロスチェックするステップと
を含む、請求項9または請求項10に記載の方法。
【請求項12】
前記マークルルートは、ブロックヘッダの最良チェーンを提供するヘッダクライアントと通信する前記マーチャントデバイスによって個別に構築される、請求項11に記載の方法。
【請求項13】
前記トランザクションにおいて提供される前記マークルルートが前記個別に構築されたマークルルートと一致する場合、前記トランザクションは認証される、請求項11または12に記載の方法。
【請求項14】
前記トランザクションはビットコイントランザクションである、請求項1から13のいずれか一項に記載の方法。
【請求項15】
前記少なくとも1つの通知はコールバック通知である、請求項1から14のいずれか一項に記載の方法。
【請求項16】
前記コールバック通知は、前記トランザクションが前記ブロックチェーンに成功裡に提出されたことを示す戻りマークルプルーフを提供する、請求項15に記載の方法。
【請求項17】
前記戻りマークルプルーフは、
前記マークルプルーフが関連する前記ブロックチェーントランザクションのトランザクション識別子と、
前記ブロックチェーンが含まれる前記ブロックのブロックヘッダと、
前記トランザクション識別子用の兄弟ハッシュのアレイと
を含む、請求項16に記載の方法。
【請求項18】
前記少なくとも1つの通知を前記顧客デバイスへ送るステップをさらに含む、請求項1から17のいずれか一項に記載の方法。
【請求項19】
前記少なくとも1つの通知が受信されると、前記セキュアな通信チャネルを閉じるステップをさらに含む、請求項1から18のいずれか一項に記載の方法。
【請求項20】
前記顧客の公開アドレスおよび前記マーチャントの公開アドレスは各々、前記顧客および前記マーチャントに関連付けられたそれぞれのデジタルウォレットの公開鍵を含む、請求項1から19のいずれか一項に記載の方法。
【請求項21】
デジタル署名は、前記マーチャントおよび/または前記顧客のアイデンティティを検証するために使われ、
前記マーチャントと前記顧客の両方に関連付けられた前記デジタル署名は、前記トランザクションがブロックチェーン台帳上で作成され、記憶され、またはポスティングされる前に、各それぞれのエンティティの検証のために要求される、請求項20に記載の方法。
【請求項22】
顧客とマーチャントとの間のトランザクションを処理するためのコンピュータシステムであって、
請求項1から21のいずれか一項に記載の方法を実施するように構成されたマーチャントデバイスと、
顧客デバイスと、
ブロックチェーンネットワークを作り上げる複数のブロックチェーンノードのうちの1つであるブロックチェーンノードと
を備える、コンピュータシステム。
【請求項23】
プロセッサおよびメモリを備えるコンピューティングデバイスであって、前記メモリは実行可能命令を含み、前記命令は、前記プロセッサによる実行の結果として、前記デバイスに、請求項1から21のいずれか一項に記載のコンピュータにより実施される方法を実施させる、コンピューティングデバイス。
【請求項24】
実行可能命令を記憶したコンピュータ可読記憶媒体であって、コンピュータのプロセッサによって実行された結果として、前記コンピュータに、請求項1から21のいずれか一項に記載の方法を実施させる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は概して、1つまたは複数のクライアント向けの決済サービスを実装するための方法およびシステムに関する。詳細には、ただし限定ではなく、本開示は、1つまたは複数のクライアント向けの、またはその代わりに、ブロックチェーンまたは分散型台帳に関連付けられた、セキュアな信頼できる決済トランザクションを可能にすることに関し、トランザクションは、顧客に関連付けられたデジタル資産決済に関係する。本開示は詳細には、顧客からマーチャントへの暗号通貨決済を容易にするための方法の提供に適しているが、それに限定されない。
【背景技術】
【0002】
本文書では、「ブロックチェーン」という用語を、あらゆる形の電子的な、コンピュータベースの分散型台帳を含むように使う。これらは、合意ベースのブロックチェーンおよびトランザクションチェーン技術、許可型および非許可型台帳、共有台帳、公開および秘密ブロックチェーン、ならびにそれらの変形を含む。ブロックチェーン技術の最も広く知られているアプリケーションはビットコイン台帳であるが、他のブロックチェーン実装形態も提案され、開発されている。ビットコインは、便宜および例示の目的のために本明細書において言及される場合があるが、本開示は、ビットコインブロックチェーンとの使用に限定されず、任意の種類のデジタル資産またはデジタル資産の表現に関連付けられた代替ブロックチェーン実装およびプロトコルが、本開示の範囲内であることに留意されたい。「クライアント」、「エンティティ」、「ノード」、「ユーザ」、「送信者」、「受信者」、「支払元」、「支払先」という用語は本明細書では、計算またはプロセッサベースのリソースを指し得る。「ビットコイン」という用語は本明細書では、ビットコインプロトコルから派生するか、またはそれに基づく任意のバージョンまたは変形を含むように使われる。「デジタル資産」という用語は、暗号通貨、プロパティの少なくとも一部を表すトークン、スマートコントラクト、ライセンス、すなわち、ソフトウェアライセンス、またはメディアコンテンツのためのDRM契約などのような、任意の移転可能資産を指し得る。デジタル資産という用語は、本文書を通して、あるエンティティから別のエンティティへのトランザクションにおいて移転されるか、または決済として提供され得る価値に関連付けられ得る商品を表すのに使われることが理解されよう。
【0003】
ブロックチェーンとは、ブロックでできている、コンピュータベースの非集中型、分散型システムとして実装されるピアツーピアの電子台帳であり、ブロックは、トランザクションでできている。各トランザクションは、ブロックチェーンシステムへの参加者の間でのデジタル資産の制御の移転を符号化するとともに、少なくとも1つの入力および少なくとも1つの出力を含むデータ構造である。各ブロックは前のブロックのハッシュを含み、そうすることによって、ブロックは互いとチェーン結合されて、ブロックチェーンにその初めから書き込まれているすべてのトランザクションの恒久的な、改変不可能な記録を作成する。トランザクションは、その入力および出力に埋め込まれたスクリプトとして知られる小型プログラムを含み、これらは、トランザクションの出力がどのように、および誰によってアクセスされ得るかを指定する。ビットコインプラットフォームでは、これらのスクリプトは、スタックベースのスクリプト言語を使って書かれる。
【0004】
トランザクションがブロックチェーンに書き込まれるためには、「認証され」なければならない。ネットワークノード(マイナー(miner))が、各トランザクションが有効であることを保証するための作業を実施し、無効トランザクションはネットワークから拒絶される。ノードにインストールされたソフトウェアクライアントが、この認証作業を、そのロックおよびロック解除スクリプトを実行することによって、未使用トランザクション(UTXO)に対して実施する。ロックおよびロック解除スクリプトの実行がTRUEとして評価される場合、トランザクションは有効であり、トランザクションは次いで、ブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、i)トランザクションを受信した第1のノードによって認証されることであって、すなわち、トランザクションが認証された場合、ノードはそれを、ネットワークの中の他のノードに中継する、ことと、ii)マイナーによって組み立てられた新規ブロックに追加されることと、iii)マイニングされる、すなわち、過去のトランザクションの公開台帳に追加されることとが行われなければならない。
【0005】
ブロックチェーンにUTXOとして記憶されると、ユーザは、関連付けられたリソースの制御を、別のトランザクションにおける入力に関連付けられた別のアドレスへ移転することができる。この移転は一般に、ただし本質的にではなく、デジタルウォレットを使って行われる。このデジタルウォレットは、デバイス、物理媒体、プログラム、デスクトップ、ラップトップもしくはモバイル端末などのコンピューティングデバイス上のアプリケーション(アプリ)、またはインターネットなどのネットワーク上のドメインに関連付けられたリモートホストサービスであってよい。デジタルウォレットは、公開および秘密鍵を記憶し、ユーザに関連付けられたリソース、トークン、および資産などの所有権を追跡し、デジタル資産を受信もしくは消費し、暗号通貨、もしくはライセンス、もしくはプロパティなどのデジタル資産、または他のタイプのリソースに関し得るトークンを移転するのに使うことができる。暗号通貨自体は、デジタルウォレットに記憶されず、そこから導出されたビットコインおよび暗号通貨の場合、暗号通貨は、パブリックに利用可能な台帳、すなわち、ブロックチェーンに非集中的に記憶され、維持される。様々な形の知られている暗号通貨ウォレットが存在し、そのようなウォレットのネットワークは、ビットコインSV(BSV)ウォレットのエコシステムなどのエコシステムと呼ばれる。デジタルウォレットは、簡易決済検証(SPV)ウォレットであってもよい。
【0006】
ブロックチェーン技術は、暗号通貨実装の使用が最も広く知られているが、デジタル企業は、ビットコインが基づく暗号化によるセキュリティシステムと、ブロックチェーンに記憶することができるデータの両方の使用を、新規システムを実装するために探っている。暗号通貨の領域に限定されない自動化タスクおよびプロセスにブロックチェーンを使うことができれば、大いに有利であろう。そのようなソリューションは、それらの適用においてより汎用性がありながら、ブロックチェーンの利益(たとえば、イベントの恒久的な改竄防止記録、分散処理など)を利用することができよう。
【0007】
上述の例またはシナリオは、ユーザ間もしくはエンティティ間での、何らかの資産、すなわち、デジタル資産、またはデジタル資産の制御の移転に関する。したがって、より良好なユーザエクスペリエンス、より安いマーチャントまたは支払先コスト、およびより安全なレベルのセキュリティで、現実世界での資産を尊重し得る、2つのエンティティ間での資金の交換のための、特に、マーチャントと顧客との間でのデジタル資産決済のための、既存の決済またはeコマースシステムに似ている、セキュアで堅牢なシステムを実装することが要望されている。より詳細には、分散型台帳(ブロックチェーン)技術と、記録のセキュリティ強化、透明度、および信頼性という利点とを利用して、任意のマーチャント、または複数のマーチャントが、それぞれの顧客とのデジタル資産決済が即座に、およびセキュアにブロックチェーンにマイニングされるか、または書き込まれることを保証するのを可能にする共通プラットフォームまたはインターフェースを提供し、そうすることによって、そのような決済の長期的な改竄防止および監査可能な記録を提供することが要望されている。
【0008】
簡易決済検証(SPV)機構が存在し、ここで、アプリケーションは、ブロックチェーンからの情報を要するが、フルマイナーノードを稼働させるわけではないので、ブロックチェーンへの直接リンクは有していない。そのようなSPVアプリケーションにより、軽量クライアントは、ブロックチェーン全体をダウンロードすることなく、トランザクションが本当にブロックチェーンに含まれることを検証することが可能になる。これは有利であるが、クライアントに関するトランザクションに関連付けられるブロックチェーンのいくつかの部分をクライアントが稼働するという要件を依然として提示し、というのは、ピアのうちの送信者または受信者のいずれかが、トランザクションをブロックチェーンに最終的に提出し、前記トランザクションがマイニングされたかどうかを識別することを求められるからである。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】GB2106950.5
【特許文献2】米国特許出願第16/384696号
【特許文献3】英国特許出願第2007597.4号
【特許文献4】英国特許出願第GB1914043.3号
【特許文献5】英国特許出願第GB2015358.1号
【特許文献6】英国出願第GB2102217.3号
【発明の概要】
【課題を解決するための手段】
【0010】
方法の態様が、独立請求項において述べられ、好ましい特徴が従属請求項において述べられる。
【0011】
第1の態様では、本開示は、顧客とマーチャントとの間のトランザクションを処理するための方法を提案する。方法は、マーチャントデバイスにおいて実施され得る。方法は、顧客に関連付けられた顧客デバイスから顧客情報を受信するステップと、顧客情報に基づいて、顧客とマーチャントとの間のセキュアな通信チャネルを確立するステップと、顧客情報に基づいて、部分的インボイストランザクションを生成するステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションを顧客デバイスへ送るステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションの完了バージョンであるとともに顧客デバイスにおいて認可されたトランザクションを受信するステップと、トランザクションを認証するステップと、認証されたトランザクションを、ブロックチェーンに提出されるようにブロックチェーンノードにブロードキャストするステップと、トランザクションがブロックチェーンノードによって認証され、ブロックチェーン上に含まれるという少なくとも1つの通知を受信するステップとを含み得る。
【0012】
第2の態様によると、顧客とマーチャントとの間のトランザクションを処理するためのコンピュータシステムが提供される。システムは、第1の態様の方法を実施するように構成されたマーチャントデバイスと、顧客デバイスと、ブロックチェーンネットワークを作り上げる複数のブロックチェーンノードのうちの1つであるブロックチェーンノードとを備え得る。
【0013】
第3の態様によると、プロセッサおよびメモリを備えるコンピューティングデバイスが提供され、メモリは実行可能命令を含み、命令は、プロセッサによる実行の結果として、デバイスに、第1の態様に述べられる、コンピュータにより実施される方法を実施させる。
【0014】
第4の態様によると、実行可能命令を記憶したコンピュータ可読記憶媒体が提供され、命令は、コンピュータのプロセッサによって実行された結果として、コンピュータに、第1の態様の方法を実施させる。
【0015】
本明細書を通して、「備える(comprise)」という単語、または「含む(includes)」、「備える(comprises)」もしくは「備える(comprising)」などの変形は、明言した要素、整数もしくはステップ、または要素、整数もしくはステップのグループを含むことを含意するが、どの他の要素、整数もしくはステップ、または要素、整数もしくはステップのグループも除外するわけではないと理解されたい。
【0016】
次に、本開示の態様および実施形態が、例示の目的でのみ、および添付の図面を参照して記載される。
【図面の簡単な説明】
【0017】
図1】顧客とマーチャントとの間のトランザクションを実装するための例示的システムを示す図である。
図2】マーチャントと顧客との間のトランザクションを処理するための方法のブロック図である。
図3A】顧客とマーチャントとの間のトランザクションを処理するためのピアツーピア転送プロトコルフローを示す図である。
図3B】顧客とマーチャントとの間のトランザクションを処理するためのピアツーピア転送プロトコルフローを示す図である。
図3C】SPVエンベロープデータ構造の概略を示す図である。
図4】本開示の少なくとも1つの実施形態を実践するのに使われ得るコンピューティングデバイスの例示的な簡略ブロック図である。
【発明を実施するための形態】
【0018】
分散型台帳に関連付けられたトランザクション用の、1つまたは複数のクライアントに資産移転サービスを実装する、コンピュータにより実施される方法が提供される。一例では、資産移転サービスは決済サービスであってよい。この方法は、顧客およびマーチャントに関連付けられたトランザクションが分散型台帳、すなわちブロックチェーンに書き込まれ、または記憶されることを可能にするための決済サービスを実装する。決済サービスは、マーチャントがアクセスを有するAPIであって、マーチャントに関するデジタル資産決済を処理するAPIとして実装することができる。
【0019】
本明細書に記載する方法は、トランザクション自体と、関与する当事者の両方のセキュリティを維持しながら、トランザクションが効率的に完了されることを保証するために、オフチェーンとオンチェーンの両方のいくつかの有利なプロセスを組み合わせる決済サービスを提供する。トランザクションを下支えするアーキテクチャは、従来のブロックチェーンシステムで見られるいくつかの制限を克服するように規模を拡大することができる。本明細書では、いかなるクライアントも、計算能力が高い(computationally sophisticated)かどうかにかかわらず、クライアントにとって計算的および機能的に比較的煩わしくない、シンプルな、秩序通りの、迅速な、正確な、信頼できる、およびセキュアなやり方で直接(ピアツーピア方式で)、別の当事者、すなわち前記クライアントに関連付けられたトランザクションの相手方または送信者/受信者に即座にアクセスし、対話することができるようにする、セキュアな、低複雑度の、ユーザフレンドリーな、効率的、および堅牢なプロセスが実装される。ブロックチェーン技術、ならびに記録のセキュリティ強化、透明度、および信頼性という利点は、どのクライアントコンピューティングデバイスも、クライアントに関連付けられたあらゆるデータ、イベント、またはデジタル資産を保証することを可能にするように提供され、即座に、およびセキュアにブロックチェーンにマイニングし、またはブロックチェーンに容易に書き込むことができ、そうすることによって、長期的な、改竄防止のための、および監査可能な記録を提供し、これは、求めに応じて作成し、書き込み、更新し、読み出し、または閲覧することができる。好ましくは、これは、ライトクライアントである、マーチャントおよび顧客などのクライアントによって実施することができ、したがって、ブロックチェーン自体のどの一部をダウンロードすることも稼働することも要しない。ブロックチェーンの一部または全部を実際にダウンロードし、稼働するノードとの簡易なアクセス可能対話も、本明細書に記載する方法によって提供され、これは、トランザクションがブロックチェーンに書き込まれ得ることを保証する。
【0020】
本開示は、顧客とマーチャントとの間のトランザクションを処理するための方法、デバイスおよびシステムを提案する。この方法は、マーチャントデバイスにおいて実施されてよい。方法は、顧客に関連付けられた顧客デバイスから顧客情報を受信するステップと、顧客情報に基づいて、顧客とマーチャントとの間のセキュアな通信チャネルを確立するステップと、顧客情報に基づいて、部分的インボイストランザクションを生成するステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションを顧客デバイスへ送るステップと、セキュアな通信チャネルを介して、部分的インボイストランザクションの完了バージョンであるとともに顧客デバイスにおいて認可されたトランザクションを受信するステップと、トランザクションを認証するステップと、認証されたトランザクションを、ブロックチェーンに提出されるようにブロックチェーンノードにブロードキャストするステップと、トランザクションがブロックチェーンノードによって認証され、ブロックチェーン上に含まれるという少なくとも1つの通知を受信するステップとを含み得る。いくつかの実施形態では、マーチャントおよび顧客デバイスは、軽量クライアント(ライトクライアント)であってよい。
【0021】
上記方法は、マーチャントと、顧客と、ブロックチェーンとの間の安全な即時トランザクションを提供し、このトランザクションは、スケーラブルであり、安定し、セキュアである。有利には、方法は、ブロックチェーンネットワークの軽量クライアントにおいて実質的に達成することができる、顧客とマーチャントとの間のトランザクションの、セキュアで効率的な実施法を提供する。軽量またはライトクライアントは、ブロックチェーンのフルノードとして稼働する必要がなく、すなわち、ブロックチェーンのフルレプリカを所有していない。そのようなクライアントは、エネルギー消費および記憶要件がはるかに軽いので、「フル」または「マイナー」ノードと比較して、稼働するのによりコストがかからず、要する帯域幅がはるかに低い。フルノードでないマーチャントデバイスおよび顧客デバイスにおいてトランザクションを生成し、認証することの利益は、かかる時間と、求められる処理能力が大幅に削減されることである。特に、顧客デバイスおよびマーチャントデバイスの計算要件は、ブロックチェーンノードのものよりもはるかに少なくなり得る。最終的に、スケーラブルな方法がもたらされるが、これが、現在のインフラストラクチャの限界である。
【0022】
方法は、セキュアな通信チャネルを介して、2つのエンティティの間のセキュアな通信を提供する。これらの通信は、公開台帳であり得るブロックチェーンにポスティングされず(すなわち、「オフチェーン」)、したがって有益には秘密のままである。セキュアな通信チャネルはしたがって、強化されたセキュリティおよび機密性での、リソースの交換を可能にする。
【0023】
さらに、部分的インボイストランザクション(やはり「オフチェーン」で実施される)を顧客に提供することで、顧客は、トランザクションを自分で書き入れ、完了することができる。こうすることにより、今度は直ちに調和がとられる。ブロックチェーンにアップロードされるのに先立ってトランザクションを認証することにより、トランザクションの迅速な処理が可能になり、マーチャントは、たとえばマイナーノードであってよいブロックチェーンノードと直接対話することができ、トランザクションがブロックチェーンに書き込まれたという即時通知を受信し得る。
【0024】
いくつかの実施形態では、部分的インボイストランザクションはトランザクションテンプレートであってよい。
【0025】
いくつかの実施形態では、顧客情報は任意選択で、購入注文および顧客の別名を含む。この情報は、部分的インボイストランザクションを生成するのに使うことができる。顧客の別名により、マーチャントデバイスは、たとえばインターネットを介して、またはセキュアな方法により、顧客を見つけ、かつ/または検証することができるようになり得る。
【0026】
いくつかの実施形態では、顧客の別名は、マーチャントデバイスの外部のサーバに関連して検証され得る。サーバは、1人または複数の顧客またはマーチャントに関する複数の別名を記憶してよく、2つのエンティティ間の通信を容易にし得る。
【0027】
いくつかの実施形態では、顧客情報を受信することで、クライアントとマーチャントとの間のハンドシェイク手順を確立することができる。ハンドシェイク手順は、どのデータが共有される前であっても、セキュアな通信プロセスが確立されることを保証し得る。この手順はさらに、マーチャントおよび顧客が各々、他方のデバイスを検証することを可能にし得る。
【0028】
いくつかの実施形態では、セキュアな通信チャネルは、マーチャントデバイスの外部のチャネルサーバに関連して確立され得る。有利には、これは、両方の当事者にとって、セキュリティを維持するのを助け得る。マーチャントデバイスにおいて実施されるプロセスを削減するのも助けることができ、そうすることによって、マーチャントデバイスにおいて求められるエネルギー消費および/または記憶空間を抑え、このことが、方法の効率を向上することと、マーチャントデバイスにおける性能向上とを助ける。
【0029】
いくつかの実施形態では、セキュアな通信チャネルは、マーチャントから顧客へ、および顧客からマーチャントへの両方で通信が送られることを許可し得る。このようにして、ただ1つのチャネルが、クライアントデバイス間で可能にされ得る。これにより有利には、トランザクション履歴を維持することができる。さらに、双方向通信チャネルが、たとえば2つの単方向通信チャネルと比較して、故障またはセキュリティ違反の機会を削減し得る。
【0030】
いくつかの実施形態では、セキュアな通信チャネルはエンドツーエンド暗号化されてよい。これは有利には、ハッキングまたは攻撃に対するさらなるセキュリティおよび保護を提供する。
【0031】
いくつかの実施形態では、部分的インボイストランザクションを生成することは、マーチャントウォレットに関連して、トランザクションテンプレートに1つまたは複数のトランザクション出力を投入することを含み得る。トランザクションテンプレートはトランザクション出力を含んでよく、この出力は、マーチャントに支払われるべき暗号通貨の一定の値を指定し得る。トランザクション出力は、トランザクション認証において求められる、マーチャントのデジタル署名をさらに含み得る。いくつかの実施形態では、トランザクション出力は、ロッキングスクリプトをさらに含む。有利には、マーチャントウォレットに関連してトランザクション出力を投入されたトランザクションテンプレートを提供することは、マーチャントと顧客との間の信頼性を向上するのを助け得る。
【0032】
いくつかの実施形態では、トランザクションは、顧客ウォレットに関連付けられた1つまたは複数のトランザクション入力を含んでよく、1つまたは複数のトランザクション入力は、少なくとも、前のトランザクションのマークルルートを含む。トランザクション入力は、顧客のデジタル署名を含み得る。トランザクション入力は、ロック解除スクリプトをさらに含み得る。有利には、部分的インボイストランザクションは、顧客デバイスにおいて顧客によって完了されてよく、顧客は、顧客ウォレットに関連して入力を挿入する。前のトランザクションのマークルルートは、顧客デバイスにおいて顧客にとって容易に利用可能であってよく、そうすることによって、トランザクションプロセスの効率を向上する。
【0033】
任意選択で、トランザクションは、確認された祖先(ancestor)のマークルプルーフおよび完全なトランザクションをさらに含むデータ構造の中にカプセル化される。たとえば、トランザクションは、SPVエンベロープをさらに含み得る。SPVエンベロープは、確認された祖先のマークルプルーフおよび完全なトランザクションとともに、トランザクションをカプセル化するデータ構造である。SPVエンベロープは、カプセル化されたマークルプルーフとともに、トランザクションが、トランザクションを認証するのに求められる情報を提供することによって、二重支出リスクの削減など、未確認祖先とのトランザクション、および状態チャネルなどの暫定状態をもつトランザクションにおいてより高いレベルの信頼性を可能にするので、有効であることを証明するのを助ける情報を提供する。
【0034】
いくつかの実施形態では、トランザクションを認証することは、前のトランザクションのマークルルートを個別に構築することと、構築されたマークルルートを、1つまたは複数のトランザクション入力のマークルルートでクロスチェックすることとを含み得る。マークルルートを個別に構築することは、任意選択で、マーチャントデバイスにおいて実施される。マークルプルーフの組合せの包含は、トランザクションが確認される見込みを評価するのに求められる情報を提供する。そのような情報を提供することで、トランザクションが確認され、認証される速度を向上することもできる。
【0035】
いくつかの実施形態では、マークルルートは、ブロックヘッダの最良チェーンを提供するヘッダクライアントと通信するマーチャントデバイスによって個別に構築され得る。ヘッダクライアントは、ライトクライアントとして稼働し、マーチャントデバイスに、ブロックヘッダの最良チェーンを提供し得る。ブロックチェーンのライトクライアントとして動作するヘッダクライアントは、ブロックチェーンのフルレプリカも所有せず、フルノードとしても稼働しない。ブロックハッシュが、ヘッダクライアントによってマーチャントに提供される最良チェーン中にあることが確認された場合、トランザクションは、有効なトランザクションとして確認され得る。
【0036】
いくつかの実施形態では、トランザクションは、トランザクションにおいて提供されるマークルルートが、個別に構築されたマークルルートと一致する場合に認証され得る。このチェックに通った場合、トランザクションは、ブロックチェーンに含められる準備ができていると判断されてよく、マーチャントは、トランザクションが検証されたと判断する。
【0037】
いくつかの実施形態では、トランザクションはビットコイントランザクションであってよい。
【0038】
いくつかの実施形態では、少なくとも1つの通知はコールバック通知であってよい。任意選択で、コールバック通知は、トランザクションが成功裡にブロックチェーンに提出されたことを示す戻りマークルプルーフを提供する。コールバック通知は、ブロックチェーン中の所与のクライアントによって提出されたトランザクションの包含の証明、すなわちマークルプルーフに関し得る。
【0039】
任意選択で、戻りマークルプルーフは、マークルプルーフに関連するブロックチェーントランザクションのトランザクション識別子と、ブロックチェーンが含まれるブロックのブロックヘッダと、トランザクション識別子用の兄弟ハッシュ(sibling hash)のアレイとを含み得る。
【0040】
いくつかの実施形態では、方法は、少なくとも1つの通知を顧客デバイスへ送るステップをさらに含み得る。これは、マークルプルーフを含み得る。有利には、この情報を提供することは、トランザクションがブロックチェーンに正当に追加されたことをクライアントに対して示すことができ、トランザクションが完成され、完了されたことを意味する。
【0041】
いくつかの実施形態では、方法は、少なくとも1つの通知が受信されると、セキュアな通信チャネルを閉じるステップをさらに含み得る。これは、セキュリティを向上し、マーチャントデバイスおよび/または顧客デバイスの総記憶要件を削減するのを助け得る。
【0042】
いくつかの実施形態では、顧客の公開アドレスおよびマーチャントの公開アドレスは各々、顧客およびマーチャントに関連付けられたそれぞれのデジタルウォレットの公開鍵を含み得る。
【0043】
いくつかの実施形態では、デジタル署名は、マーチャントおよび/または顧客のアイデンティティを検証するために使うことができ、マーチャントと顧客の両方に関連付けられたデジタル署名は、トランザクションがブロックチェーン台帳上で作成され、記憶され、またはポスティングされる前に、各それぞれのエンティティの検証のために求められる。
【0044】
本明細書では、顧客とマーチャントとの間のトランザクションを処理するためのコンピュータシステムが提供される。システムは、第1の態様の方法を実施するように構成されたマーチャントデバイスと、顧客デバイスと、ブロックチェーンネットワークを作り上げる複数のブロックチェーンノードのうちの1つであるブロックチェーンノードとを備え得る。
【0045】
本明細書では、プロセッサおよびメモリを備えるコンピューティングデバイスが提供され、メモリは実行可能命令を含み、命令は、プロセッサによる実行の結果として、デバイスに、上述した、コンピュータにより実施される方法を実施させる。
【0046】
本明細書では、実行可能命令を記憶したコンピュータ可読記憶媒体が提供され、命令は、コンピュータのプロセッサによって実行された結果として、コンピュータに、上述した方法を実施させる。
【0047】
上述したように、本明細書で開示される方法、デバイスおよびシステムは、顧客デバイスと、マーチャントデバイスと、ブロックチェーンノードとの間の、オフチェーンとオンチェーンの両方での、セキュアなプロセスのシームレスな蓄積を提供して、ブロックチェーン上での、トランザクションの申し出から完了までの、トランザクションの円滑な稼働を保証する。いくつかの有利なプロセスは、関与する当事者のセキュリティを保証し、ブロックチェーン上でトランザクションが提出され、受諾されるのにかかる時間の効率を向上するように組み合わされる。
【0048】
図1は、顧客100とマーチャント130との間の決済トランザクションを実装するための例示的システム10を示す。
【0049】
システム10は、顧客デバイス100に関連付けられた顧客100-1と、アドレス指定サーバ110と、チャネルサーバ120と、マーチャントデバイス130に関連付けられたマーチャント130-1と、マーチャントAPI(mAPI)140と、ピアツーピア(P2P)ネットワーク155中のノード、たとえばマイナーノードであるブロックチェーンノード150とを備える。アドレス指定サーバ110は好ましくは、別名ベースのアドレス指定を実装する。このサーバはこれ以降、決済サービス110または決済サーバ110またはPayMailサーバ110と呼ばれる。システム10の要素の各々は、インターネット105などの通信ネットワークに接続可能である。サイドチャネル(セキュアなチャネル)125が、顧客100とマーチャント130との間で可能にされ得る。
【0050】
システムは、顧客100およびマーチャント130を含むユーザのコンピュータ機器を備える。これらのユーザは、ブロックチェーンネットワークと対話する場合があるが、トランザクションおよびネットワーク155中のブロックを認証し、構築し、または伝搬するのには参加しない。顧客100およびマーチャント130は、トランザクションにおける送信者および受信者として作用してよく、必ずしも送信者または受信者として作用せずに、ブロックチェーン150と対話してよい。さらに、一方または両方の当事者が、ブロックチェーンのコピーを記憶する記憶エンティティとして作用し、それらを提供され、またはそれらとのセキュアな通信をしてよい(たとえば、ブロックチェーンノード150から、ブロックチェーンのコピーを取得してある)。いくつかの実施形態では、この記憶エンティティはヘッダクライアントであってよい。
【0051】
顧客100およびマーチャント130の一方または両方が、ライトクライアントとして動作してよい。したがって、当事者100-1、130-1の一方または両方が、異なるネットワーク、たとえば、ブロックチェーンネットワーク155の上に重ねられたネットワークの一部として接続されてよい。ブロックチェーンネットワークのユーザ(しばしば、「クライアント」と呼ばれる)は、ブロックチェーンネットワークを含むシステムの一部であると言われ得るが、これらのユーザは、ブロックチェーンノードに求められる役割を実施しないので、ブロックチェーンノード150ではない。そうではなく、各当事者100-1、130-1は、ブロックチェーンネットワークと対話し、そうすることによって、ブロックチェーンノード150に接続する(すなわち、それと通信する)ことによって、ブロックチェーンを使用し得る。より多くのそのような顧客100-1および顧客のそれぞれのコンピュータ機器100がシステム10の中に存在し、参加していてよいが、便宜上、それらは図示されないことが理解されよう。各当事者100、130は、個人または組織であってよい。
【0052】
ライトクライアントは概して、ブロックチェーンのフルレプリカを所有せず、したがって、「フル」または「マイナー」ノードと比較して、稼働するのにはるかにコストがかからず、はるかに低い帯域幅を要する。ライトクライアントは、たとえば、ブロックヘッダの最良チェーンおよび/またはトランザクションのマークルルート値に関する、ヘッダクライアントによって提供されるデータに依拠することができる。最良チェーンは、ブロックチェーン中の最初のブロックである起源から、ブロックチェーン中の最新ブロックである現在の最良ブロックまでのブロックのチェーンとして記述することができる。最良ブロックは、最も高い蓄積プルーフオブワークを有してよく、これは、ブロックチェーンのその特定のブランチを維持する際にネットワークによって消費される大部分のエネルギーとして記述することができる。ヘッダクライアントがブロックヘッダの最良チェーンを判断するためにブロックヘッダをソーシングすることは、上で言及したマーチャントAPI140を通して実施されてよい。ライトクライアントはしたがって、それらの独自のデータ/トランザクションボリュームに合わせて、データのボリュームおよび各ブロックの中に入るトランザクションにまったく影響されずにスケーリングすることができる。
【0053】
本明細書で開示され、たとえば、nChain Holdings Limitedの名義で2021年5月14日に出願されたGB2106950.5により詳しく記載される実施形態によると、ヘッダクライアントは、顧客100およびマーチャント130などのライトクライアントにとって容易にアクセス可能であり得るとともに、ブロックチェーンとしても更新することができるブロックヘッダの最良チェーンが拡張されると判断することができる。ブロックヘッダの最良チェーンは、ブロックチェーン上の各ブロックについての完全なトランザクション情報を提供することなく、ブロックチェーンの状態のビューを提供するので、トランザクション検証のためにライトクライアントアプリケーションにとって有用である。ヘッダクライアントの記憶モジュールの記憶空間は、ブロックチェーンの「フル」ノードと比較して削減され得るが、それは、ブロックヘッダは、特にブロックチェーン自体の上のブロックと比較して、データで重いわけではないからである。したがって、ヘッダクライアントにおいて実施される処理は、フルノードと比較して迅速であり得る。より低い記憶空間要件に加え、ヘッダクライアントを操作するのに求められる計算パワーも、フルノードと比較して小さくなる場合があり、ヘッダクライアントは、フルノードよりも、稼働し、維持するのにコストがかからない場合がある。たとえば、ヘッダクライアントは、Raspberry Piなどのシングルボードコンピューティングデバイス上で稼働されてよい。
【0054】
ライトクライアントは、ヘッダクライアントによって提供される情報を、未使用トランザクション出力、すなわちUTxOを作成する、前のトランザクションのマークルルートを個別に構築するのに使うことができる。
【0055】
コンピュータ機器100、130は、1つまたは複数のプロセッサ、たとえば1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途プロセッサ、および/またはFPGAを備えるそれぞれの処理装置を備える。各当事者のコンピュータ機器は、メモリ、すなわちコンピュータ可読ストレージを、1つまたは複数の非一時的コンピュータ可読媒体の形でさらに備える。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリもしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光学媒体を利用する1つまたは複数のメモリユニットを備え得る。各当事者100-1、130-1のコンピュータ機器100、130上のメモリは、処理装置上で稼働するように用意された少なくとも1つのクライアントアプリケーションのそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において、所与の当事者100-1、130-1に起因したどのアクションも、それぞれのコンピュータ機器100、130の処理装置上で稼働するソフトウェアを使って実施されてよいことが理解されよう。各当事者100-1、130-1のコンピュータ機器100、130は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどの装着可能デバイスを備える。所与の当事者100-1、130-1のコンピュータ機器100、130は、ユーザ端末を介してアクセスされるクラウド計算リソースなど、1つまたは複数の他のネットワーク接続リソースも備え得る。
【0056】
クライアントまたは顧客のアプリケーションは最初に、任意の所与の当事者100-1、130-1のコンピュータ機器100、130に、1つもしくは複数の適切なコンピュータ可読記憶媒体上で提供され、たとえばサーバからダウンロードされ、あるいは取り外し可能SSDなどの取り外し可能記憶デバイス、フラッシュメモリキー、取り外し可能EEPROM、取り外し可能磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROM、または取り外し可能光ドライブなどの光ディスクなどの上で提供され得る。
【0057】
クライアントアプリケーションは、「ウォレット」機能を含み得る。これは、2つの主な機能性を有する。これらのうちの1つは、それぞれの当事者100が、トランザクションおよび/もしくは部分的トランザクションまたはトランザクションテンプレートを作成し、認可し(たとえば署名し)、別のクライアントまたは1つもしくは複数のブロックチェーンノード150など、システム中の他のエンティティへ送って、次いで、ブロックチェーンノード150のネットワーク中に伝搬され、そうすることによってブロックチェーンに含められることを可能にすることである。通常、ブロックチェーンノード150へは、ブロックチェーンに提出されるために、完了されたトランザクションのみが送られる(したがって、部分的トランザクションもトランザクションテンプレートも送られない)。ウォレットの他の機能は、当事者が現在所有するデジタル資産の額についてそれぞれの当事者に報告を返すことである。出力ベースのシステムでは、この第2の機能性は、問題の当事者に属す、ブロックチェーン中に散乱した様々なトランザクションの出力において定義される額を照合することを含む。
【0058】
いくつかの実施形態では、顧客ライトクライアント100は、決済プロトコルクライアント、決済プロトコルサーバ、SPVチャネルクライアント、トランザクションビルダ、ヘッダクライアント、SPV認証元および決済認証元というユニットのうちの1つまたは複数を備え得る。顧客ライトクライアントは、顧客ウォレットおよび顧客PayMailサーバ、たとえばPayMailサーバ110と対話し得る。nChain Holdings Limitedの名義で2019年4月15日に出願された米国特許出願第16/384696号においてより詳しく記載されるように、所与のクライアント向けの別名を提供することを含む、別名ベースの決済サービスを実装することができ、別名は、所与のクライアントに固有であり、別名は、ネットワーク識別子を含むか、またはそれに関連する。方法は次いで、別名を、ディレクトリの中のネットワーク識別子に関連付けるステップを含む。この関連付けは、ディレクトリの中のネットワーク識別子に基づいて、サービス記録を作成するステップによって達成される。サービス記録は次いで、決済サービスが、ネットワークまたはネットワーク識別子に関連付けられたドメインと、決済サービスを担当する、ホスト計算リソースについてのロケーションによって提供されることを示すように更新され、ホスト計算リソースは、別名に関連したトランザクションに関する要求の受信に応答して、別名に関連付けられたクライアントの識別を容易にするように構成される。本明細書において言及するPayMailサーバは、別名ベースの決済サービスを実装するサーバであると、たとえばディレクトリと見なすことができる。PayMailサーバ110は、たとえば、顧客100についての情報を記憶し得る。サーバ110は、顧客デバイス100またはマーチャントデバイス130など、1つまたは複数のクライアントによって、ワイヤードまたはワイヤレス通信ネットワークを介してアクセスすることができる単一、リモートまたは分散コンピューティングノードまたはエンティティ上で稼働している場合がある。
【0059】
いくつかの実施形態では、マーチャントライトクライアントは、決済プロトコルクライアント、決済プロトコルサーバ、SPVチャネルクライアント、トランザクションビルダ、トランザクションブロードキャスター、ヘッダクライアント、SPV認証元、PayMailクライアント、および決済認証元というユニットのうちの1つまたは複数を備え得る。マーチャントAPI、すなわちmAPI140も、マーチャントライトクライアント上で稼働され得る。マーチャントライトクライアントは、マーチャントウォレット、SPVチャネルサーバ120、およびPayMailサーバ110と対話し得る。mAPI140を通して、マーチャント130は、ブロックチェーン台帳にトランザクションを提出することが可能なブロックチェーンノード150であるマイナーノードと対話することもできる。
【0060】
マーチャントデバイス130および顧客デバイス100における決済プロトコルクライアントは、それぞれの決済プロトコルサーバとともに作動し、たとえば、クライアントがサーバとの通信をトリガした場合、2つのエンティティ間の通信を容易にする。同様に、顧客デバイス100およびマーチャントデバイス130におけるSPVクライアントは、それぞれのデバイスがSPVチャネルサーバ120と通信することができるような機能性を提供する。PayMailクライアントは、顧客デバイス100と、マーチャントデバイス130と、PayMailサーバ110との間の通信を提供する。
【0061】
トランザクションビルダは、たとえば、顧客100またはマーチャント130に関連付けられたウォレットとともに、トランザクションを組み立てることができる。いくつかの例では、トランザクションビルダは、マーチャントデバイスおよび/または顧客デバイスにおけるトランザクションテンプレートに、トランザクション入力および/または出力を挿入する。いくつかの実施形態における入力および出力は、トランザクションがそこから支出される/そこへ支払われるウォレットの公開鍵(すなわち、マーチャントまたは顧客の公開鍵)を含むことができる。いくつかの実施形態では、トランザクションテンプレートには、トランザクション入力および出力が別々に投入されてよい。一例では、マーチャントデバイス130は、トランザクションテンプレートに、顧客デバイス100へのトランザクション出力を提供し、顧客デバイス100は、トランザクション入力を提供することによって、テンプレートトランザクションを完了する。
【0062】
トランザクションブロードキャスターは、mAPI140によって実装される決済プロトコルと通信して、1つまたは複数のトランザクションを、ブロックチェーン台帳への提出のためにブロックチェーンノード150にブロードキャストする。
【0063】
決済認証元、SPV認証元、およびヘッダクライアントは、以下でより詳しく説明するように、組み合わせて作動して、トランザクションを検証または認証し得る。
【0064】
注:様々なクライアント機能性が、必ずしも限定的ではない所与のクライアントアプリケーションに統合されるものとして記述される場合があるが、そうではなく、本明細書に記載されるいかなるクライアント機能性も、たとえばAPIによりインターフェースをとるか、または一方が他方へのプラグインである、一連の2つ以上の別個のアプリケーションにおいて代わりに実装されてよい。より一般的には、クライアント機能性は、アプリケーションレイヤもしくはオペレーティングシステムなどの下位レイヤ、またはこれらの任意の組合せにおいて実装されてもよい。
【0065】
チャネルサーバ120は、ワイヤードまたはワイヤレス通信ネットワークを介して、顧客デバイス100またはマーチャントデバイス130など、1つまたは複数のクライアントによってアクセスすることができる単一、リモートまたは分散コンピューティングノードまたはエンティティ上で稼働している場合がある。いくつかの実施形態では、クライアントは、1つまたは複数のプロセッサを有する、エンティティ、ユーザ端末/デバイスまたはコンピューティングデバイスもしくはシステムであってよい。いくつかの実施形態では、クライアントは、暗号通貨およびトークンなどのような1つまたは複数のデジタル資産をクライアントが管理できるようにする、顧客100および/またはマーチャント130のデジタルウォレットに関連付けられてよい。いくつかの実施形態では、チャネルサービスは、1つまたは複数のクライアントの中の所与のクライアントに、デジタルウォレットにより提供されてよい。ただし、デジタルウォレットも、デジタル資産のための別途のアプリケーションも有しないクライアントエンティティも、本開示の範囲内であることを理解されたい。いくつかの実施形態では、特に、計算能力が高いクライアント向けに、チャネルサービスを実装するチャネルプロセッサは、クライアントエンティティと統合されるか、またはその一部であってよく、たとえば、マーチャント130はクライアントエンティティである。この場合、チャネルプロセッサは、前記クライアント向けのチャネルサービス機能性を可能にする、クライアント端末内のモジュールとして実装されてよい。いくつかの実施形態では、他のクライアントまたはエンティティも、前記チャネルプロセッサによってサービスされ得る。
【0066】
本明細書ではチャネルおよび/またはセキュアなチャネルとも呼ばれるサイドチャネル125は、ブロックチェーンネットワークとは別に、データの交換を可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、トランザクションが(まだ)ブロックチェーンネットワーク155に登録されることも、ブロックチェーンに達することもなく、顧客100とマーチャント130との間でトランザクションインボイスを交換するのに使われてよい。トランザクション、またはインボイストランザクションをこのように共有することは、「トランザクションテンプレート」を共有する、と呼ばれることがある。トランザクションテンプレートは、完全トランザクションを形成するために求められる1つまたは複数の入力および/または出力を欠いている場合がある。代替または追加として、サイドチャネル125は、鍵、交渉される額または条項、データ内容などのような、任意の他のトランザクション関連データを交換するのにも使われてよい。いくつかの実施形態では、チャネル125は、データの送信に関するチャネル機能もしくは手順、および/またはチャネルを使って送信されるデータに関するメッセージ機能もしくは手順を含む1つまたは複数の機能に関連付けられる。したがって、チャネル125は、セキュアな環境におけるメッセージまたはデータの転送のための、エンティティ間の直接またはピアツーピア通信経路またはセッションを可能にする。大部分の実施形態では、各チャネル125に対してただ2つのエンティティ、すなわち顧客100およびマーチャント130が存在する。大部分の実施形態では、チャネルは、クライアントと他方のエンティティとの間の全二重、すなわち二方向通信を可能にする。いくつかの実施形態では、通信は一方向においてのみ認められる場合があり、すなわち、クライアントは、他方のエンティティへメッセージを送るか、またはそこからメッセージを受信したいだけである場合がある。
【0067】
チャネルサービスおよび/またはチャネルプロセッサの一例が、nChain Holdings Limitedの名義で2020年5月21日に出願された英国特許出願第2007597.4号に詳しく記載されており、その主題は、参照によって本明細書に組み込まれている。
【0068】
いくつかの実施形態では、チャネル125はチャネル識別子に関連付けられてよく、チャネル識別子は、チャネル125についてのロケーションまたはアクセスポイントに関連付けられる。いくつかの実施形態では、各チャネル125は、特定のチャネル識別子に関連付けられる。同じ所与のクライアントが、いくつかの別々のチャネルを有することができ、各々が、それ自体の一意の識別子をもち、これは、チャネル125にそれを介してアクセスすることができるロケーションまたはエンドポイントに対応し得る。いくつかの実施形態では、所与のチャネル125は、特定のタイプまたはトピックに関連付けられるデータに関連した、任意の他のエンティティとの通信用であり、チャネル125における各トピックに関連付けられたデータは、1つまたは複数のメッセージまたはトランザクションであるか、またはその中に含まれる。有利には、特定のトピックまたはトランザクション用に特定のチャネル125を有すると、クライアント向けに、特に、追跡されるか、または同じクライアントに関連付けられたすべての他のトピックまたは他のトランザクションとは別々に扱われる必要があるトピックの番号(トランザクション番号もしくはIDまたはインボイス番号など)を有する場合がある、マーチャントエンティティのようなクライアントの場合、より優れた明瞭さ、信頼性、および柔軟性が保証される。
【0069】
マーチャントなど、事業に関連付けられるか、または組織を表し得るクライアントエンティティの場合、そのようなクライアントは、いくつかの商品に関してトランザクションを一緒に執り行う多数の他のエンティティ(顧客)を有し得る。したがって、そのようなシナリオのために、1人もしくは複数の顧客または1つもしくは複数のトランザクションとの通信用のチャネルを使いながら、すべてのそのようなトランザクションの記録を維持するブロックチェーンに関連した、どの機能性の実装からも断絶または結合解除されることは、かなり有益であろう。チャネル機能ならびにメッセージ機能がチャネルサービスにより提供されるので、そのようなクライアントは、いくつかの実施形態では、特定のトランザクション(いくつかの商品についての特定のインボイスまたは問合せなど)に関連する特定の顧客向けに特定のチャネル125を使用する能力を有し、そのようなトランザクションに固有の、どのさらなる情報も、いつでも前記チャネル125を介して取得することが可能である。
【0070】
いくつかの実施形態では、複数のチャネルが存在してよく、上述のチャネル125は、これらの複数のうちの1つであり、これらは、チャネルサービスによって提供される1つまたは複数の機能に基づくチャネルである。いくつかの実施形態では、1つまたは複数の機能は、所与のクライアント向けに発行されるか、またはそこに提供されるアプリケーションプログラミングインターフェース(API)であり、前記APIは、1つまたは複数のチャネル用のチャネルAPIと、データ、すなわち各々の、または所与のチャネル125に関連付けられたトピックに関するメッセージ用のメッセージAPIとを含む。APIは、エンドポイント、インターフェース、またはこの場合は、アプリケーション、もしくは他のサービスの特徴もしくはデータにアクセスするクライアントなどのエンティティ用のアプリケーションの作成もしくは管理を可能にする機能および手順のセットとして理解されてよい。この場合、それは、チャネル機能ならびにメッセージ機能を実装するためである。
【0071】
マーチャントAPIまたはmAPIともいう決済プロセッサ140は、nChain Holdings Limitedの名義で2019年9月30日に出願された英国特許出願第GB1914043.3号および2020年9月29日に出願された英国特許出願第GB2015358.1号に詳しく記載されるように、決済を処理するための機能性を提供する。決済プロセッサは、マーチャント130および/または顧客100に通信可能に結合され、マイナーの複数のネットワークまたは複数のマイニングプールを含み得る複数のマイナーノード150にも結合される。いくつかの実施形態では、決済プロセッサ140は、マーチャント130の一部であるか、またはそれと関連付けて実装されてよく、マーチャント130は、計算能力が高いマーチャント販売時点管理(POS)端末であり得る。
【0072】
いくつかの実施形態では、決済プロセッサ/mAPI140は、関連付けられたまたはサードパーティサービスとして、1つまたは複数のクライアント(すなわち、顧客100およびマーチャント130)向けの決済インターフェースを提供するように構成される。いくつかの実施形態では、決済プロセッサは、ウェブベースの対話を提供するためのアプリケーションプログラミングインターフェース(API)として実装され、すなわち、HTTPS、TCP/IPなどのような、ウェブベースのサービスのための標準インターネット通信プロトコルを使うインターネットを介して通信が起こり得るような1つまたは複数のクライアント向けのウェブサービスとして実装される。
【0073】
このAPIは、決済プロセッサに関連付けられたマーチャント130または顧客100に知られているか、または利用可能にされるか、または送られる/提供される。いくつかの実施形態では、このAPIは、決済プロセッサによって提供されるサービスまたは機能にアクセスするための登録またはサインアッププロセスが行われると提供され得る。いくつかの例では、APIは、ウェブベースのサービスにアクセスすることを望むクライアントもしくは他のエンティティのための、よく知られているAPI設計および開発ツールまたはインターフェースであるSwaggerなどのAPIユーザインターフェースを介した使用のために提供または公開され得る。有利には、本開示のAPIは、表現可能状態転送(REST)エンドポイントとして実装されてよく、そうすることによって、HTTPSなどの、標準インターネットまたはウェブベースのプロトコルを使う通信を可能にする。RESTとは、ウェブサービスおよびウェブベースの対話を開発するためのアーキテクチャスタイルである。REST API設計規格は、以下のコマンドを使って、HTTPS要求および通信を処理することができる。
【0074】
【表1】
【0075】
REST APIのコンテキストにおけるリソースは、タイプ、関連付けられたデータ、他のリソースとの関係、およびその上で動作する方法のセットをもつオブジェクトである。いくつかの実施形態では、決済サービスは、ビットコインSV(BSV)ブロックチェーンなどのブロックチェーンまたは分散型台帳の状態にアクセスするための、およびその状態を、アプリケーションインターフェースにより改変し、REST APIとして公表することができる動作をトリガするためのAPI実装形態として、決済プロセッサによって提供される。したがって、決済プロセッサは、1つまたは複数のクライアント用のRESTエンドポイントと見なされ得る。マーチャント130はこのように、HTTPSにより決済サービスと通信し、決済プロセッサ、または決済プロセッサによって実装される決済サービスへの匿名アクセスをさらに有することができる。
【0076】
トランザクション認証および公開に関与するリソースにより、通常は少なくともブロックチェーンノード150の各々が、1つまたは複数の物理的サーバユニット、またはデータセンター全体さえも備えるサーバの形をとる。ただし、原則として、どの所与のブロックチェーンノード150が、ユーザ端末または互いとネットワーク接続されたユーザ端末のグループの形をとってもよい。
【0077】
各ブロックチェーンノード150のメモリは、それぞれの1つまたは複数の役割を実施し、ブロックチェーンノードプロトコルに従ってトランザクションを扱うために、ブロックチェーンノード150の処理装置上で稼働するように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード150に起因するどのアクションも、それぞれのコンピュータ機器の処理装置上で稼働されるソフトウェアによって実施されてよいことが理解されよう。ノードソフトウェアは、アプリケーションレイヤ、もしくはオペレーティングシステムレイヤやプロトコルレイヤなどの下位レイヤ、またはこれらの任意の組合せにおける1つもしくは複数のアプリケーションの中で実装され得る。
【0078】
図2は、マーチャント130と顧客100との間のトランザクションを処理するための方法のブロック図を示す。
【0079】
第1のステップ200によると、方法は、マーチャントデバイスにおいて、顧客情報を受信するステップと、マーチャントと顧客との間のセキュアな通信チャネルを確立するステップとを含む。好ましくは、顧客デバイスおよびマーチャントデバイスは、フルブロックチェーンノードを稼働しないライトクライアントデバイスであり、すなわち、これらは、ブロックチェーンのフルレプリカを所有しない。顧客情報は、たとえば、マーチャントから商品またはサービスを購入するための要求および/または顧客別名などの顧客識別を含み得る。トランザクション情報などの情報をセキュアなやり方で交換するためのセキュアな通信チャネルを、2人の当事者間でセットアップすることができる。トランザクションが提出されるのに先立ってセキュアに交換される情報は、公開台帳であってよいブロックチェーンに、一定の情報が書き込まれるのを防止することができる。
【0080】
第2のステップ220によると、方法は、マーチャントデバイスにおいて、インボイストランザクションを生成するステップを含む。いくつかの実施形態では、これは、顧客によって完了されるべき決済要求またはテンプレートトランザクションであってよい。インボイストランザクションは、受信された顧客情報に基づいて、たとえば、顧客によって要求された商品および/またはサービスに対してマーチャントに支払われるべき額を指定するように構築することができ、マーチャントによって提供されるトランザクション出力をさらに含み得る。いくつかの実施形態では、マーチャントは、顧客によって提供される顧客識別が有効であることを保証するためのチェックを実施してよい。トランザクション出力は、マーチャントのデジタル署名および/または顧客によってマーチャントに支払われるべき暗号通貨の額を含み得る。
【0081】
第3のステップ240によると、方法は、顧客デバイスにおいてトランザクションを認可し、認証するステップを含む。これは、セキュアな通信チャネルを介して、マーチャントと顧客との間で情報を交換することによって達成することができる。たとえば、顧客は、ブロックチェーンへ送信される準備ができている決済トランザクションを完了するためのトランザクション入力を提供し得る。
【0082】
第4のステップ260によると、方法は、有効なトランザクションをブロックチェーンに提出するステップと、トランザクションがブロックチェーン台帳の上に含まれていることを検証するステップとを含む。マーチャントは、トランザクションを、ブロックチェーン台帳に提出するのに先立って個別に認証すればよい。トランザクションは、ブロックチェーンネットワークのフルノードであるノードへ最初に送信されてから、ブロックチェーンへ送信されてよい。
【0083】
上記方法のステップについて、図3Aおよび図3Bに関連して、以下でより詳しく説明する。図3Aおよび図3Bは、顧客100とマーチャント130との間のトランザクションを処理するためのピアツーピア(P2P)決済プロトコルフローを示す。決済サービスは、1つまたは複数のクライアントがアクセスを有するゲートウェイまたはAPIエンドポイントとして実装される。1つまたは複数のクライアントは、顧客100、PayMailサーバ110、SPVチャネルサーバ120、マーチャント130、マーチャントAPI(mAPI)140、およびブロックチェーンノード150を含む。エンティティ間の通信が矢印で示され、矢印は、エンティティのうちの1つから、エンティティのうちの別のものへ、矢印の方向で通信が行われていることを示す。
【0084】
方法は、顧客100がマーチャント130から何かを買いたいときに起こり得る。第1のプロセス200は、顧客100とマーチャント130との間の通信チャネルを確立する。第1のプロセス200は、以下のステップ202~ステップ214を含み得る。
【0085】
ステップ202において、たとえばマーチャント130によって提供される商品またはサービスに対して、購入注文が顧客100によって作成される。購入注文は、オンラインカゴなど、商品のカゴを作成することを含んでよく、顧客識別などの顧客100についての情報をさらに含み得る。いくつかの実施形態では、顧客識別は顧客の別名によって提供される。いくつかの例では、顧客別名はPayMail情報を含んでよく、PayMail情報は顧客100の別名(たとえば、PayMail ID)を含み得る。前記情報を含む、メッセージなどの通信が、顧客100からマーチャント130へ送られる。この通信は、インターネット105などの通信ネットワークを介して送られてよい。
【0086】
ステップ204において、顧客情報は、マーチャント130において受信され、マーチャントは顧客100を識別する。いくつかの実施形態では、顧客PayMailのためのホスト発見は、マーチャント130において実施され、これにより、提供された別名(PayMail ID)に基づいて顧客を見つける。顧客100のPayMail IDなどの顧客アイデンティティが、マーチャント130において、たとえば、マーチャントデバイス130に関連付けられる決済プロトコルサーバにおいて記録されてよい。
【0087】
ステップ206において、顧客IDの検証がデジタル署名に基づく場合、標準公開鍵インフラストラクチャ(PKI)技法が、使われ、実装されてよい。いくつかの実施形態では、PKI認証実施および顧客アイデンティティ入手メッセージが、マーチャント130からPayMailサーバ110へ送られ得る。いくつかの実施形態では、マーチャント130は、PayMailサーバ110から将来、送信者認証および送信者公開鍵入手(MVP)を始動するためのメッセージと、トラベルルールなどのアイデンティティ情報とをさらに要求するか、または送ってよい。情報は、PayMailサーバ110に対して行われた要求に応答してマーチャント130において受信することができ、将来の使用のために記憶されてよい。
【0088】
第2のプロセス207が、第1のプロセス200内で起こり得る。第2のプロセス207は、マーチャント130が、新規チャネル、たとえば、図1との関連で図示され、論じられたように、サイドチャネル125を作成することを含む。いくつかの実施形態では、新規チャネル125は、チャネルサーバ120との既存のマーチャントアカウント用に作成されてよい。チャネル125は好ましくは、SPVチャネルなどのセキュアなチャネルである。SPVチャネルは、nChain Holdings Limitedの名義で2020年5月21日に出願された英国特許出願第2007597.4号においてより詳しく記載されている。
【0089】
第2のプロセス207の一部であるステップ208において、マーチャント130は、新規チャネルがSPVチャネルサーバ120によって作成されるための要求を、SPVチャネルサーバ120へ送る。このメッセージは、マーチャント130の決済プロトコルサーバに関連付けられたSPVチャネルクライアントから送られてよい。
【0090】
やはり第2のプロセスの一部であるステップ210において、SPVチャネルサーバ120は、マーチャント130によってSPVチャネルサーバ120へ送られたチャネル作成要求に応答して、新規チャネルを作成し、マーチャント130にチャネルIDを提供する。いくつかの実施形態では、チャネルIDは、PayMailサーバ110を介して顧客100に提供することができ、そうすることによってマーチャント130は、チャネルIDをPayMailサーバ110に提供する。こうすることにより、顧客100は、提供されたチャネルIDを受信すると、チャネルにログインすることが可能になる。マーチャント130と顧客100との間のいかなる将来の通信も、一意のチャネルIDを有する、このセキュアなチャネル125を介して起こり得る。いくつかの実施形態では、新規メッセージがチャネルに提供されると、顧客100および/またはマーチャント130に通知される。任意選択で、顧客100およびマーチャント130は、チャネルが顧客100とマーチャント130との間で多方向であるように、チャネルを通してメッセージおよび/または情報を互いにポスティングすることができる。
【0091】
第1のプロセス200の一部であるステップ212において、チャネルおよびマーチャント詳細が、マーチャント130からPayMailサーバ110へ送信される。いくつかの実施形態では、方法は、要求の中に含まれるタイムスタンプおよびデジタル署名に基づいてマーチャント130を認証するステップを含む。
【0092】
いくつかの実施形態では、顧客100およびマーチャント130の公開アドレスは各々、顧客100およびマーチャント130に関連付けられたそれぞれのデジタルウォレットの公開鍵を含み、トランザクションを要求するマーチャント130のアイデンティティを検証するために、デジタル署名が使われる。いくつかの関連実施形態では、マーチャント130と顧客100の両方に関連付けられたデジタル署名が、各それぞれのエンティティの検証のために、たとえば、トランザクションが分散型台帳上で作成され、記憶され、またはポスティングされる前に求められる。
【0093】
ステップ214において、認証の成功に応答して、顧客100に関連付けられた出力スクリプトがマーチャント130に提供される。この出力スクリプトは、トランザクションを作成するために使われてよく、トランザクションは、分散型台帳(ブロックチェーン台帳)上で記憶されるか、またはポスティングされることになる。PayMailサーバ110は、チャネルおよびマーチャント詳細が受諾されたことを確認するために、メッセージ、たとえば「応答OK」メッセージを、マーチャント130へ送ればよい。
【0094】
第1のプロセス200において通信が確立されると、第3のプロセス220が起こり得る。第3のプロセス220において、マーチャント130は、インボイスおよび決済要求を作成する。マーチャント130は、顧客が購入することを望む商品またはサービスに対する、顧客100の購入注文に基づいてインボイスを作成する。顧客100によって提供される顧客情報も、インボイスを作成するのに使われる。
【0095】
ステップ222において、マーチャント130は、インボイス(たとえば、決済要求)を作成する。項目または顧客の商品カゴの中にあるようなものに対して、インボイスは、顧客100からマーチャント130に支払われるべき額を指定し得る。いくつかの実施形態では、これは、テンプレートトランザクションまたは部分的トランザクションであってよい。
【0096】
任意選択で、ステップ224およびステップ230において、マーチャント130は、決済プロセッサマーチャントAPI(mAPI)140と通信し、mAPI140は、ステップ226およびステップ228においてブロックチェーンノード150と通信する。マーチャント130は、(失効していない見積が入手可能でない場合)GET policyQuote()メッセージをmAPI140へ送る。決済プロセッサmAPI140は、マーチャント130からメッセージを受信したことに応答して、ブロックチェーンノード150と通信する。決済プロセッサによって実装される決済サービスがAPIであるので、いくつかの実施形態では、マーチャント130からの第1の要求および/または状況問合せはHTTPS GET要求である。したがって、有利には、トランザクションがブロックチェーンにマイニングされることを要求するのに、標準インターネットおよびウェブベースの通信プロトコルを、クライアントによって使うことができる。いくつかの実施形態では、第1および/もしくは第2の要求、ならびに/またはクライアントからの状況問合せに関連付けられたデータは、Javaスクリプトオブジェクト表記(JSON)オブジェクトフォーマットで提供される。
【0097】
ステップ226において、mAPI140とブロックチェーンノード150との間の対話の結果としてmAPI140によって送られたpolicyQuote応答が、マーチャント130において受信される。
【0098】
ステップ232において、マーチャント130は、顧客100に配達されるべき決済要求を構築する。決済要求は、部分的インボイストランザクションまたはトランザクションテンプレートであってよい。マーチャント130によって構築された決済要求は、出力、決済手数料などを含み得る。決済プロトコルサーバは、マーチャントデバイス130に関連付けられたウォレットと対話し得る。たとえば、決済プロトコルサーバは、マーチャントウォレットからトランザクション出力(TxO)を受信し得る。いくつかの実施形態では、マーチャント130によって構築された決済要求は、トランザクション入力を含まない。トランザクション入力は、たとえば顧客100の顧客ウォレットによって、トランザクションに後で挿入されてよい。
【0099】
インボイスが顧客へ送られ、ブロックチェーンに提出されることによって支払いが行われるように、第4のプロセス240がP2P決済プロトコルステップを実行する。
【0100】
ステップ242において、マーチャント130は、第1のプロセス200において確立されたセキュアなチャネルを介して、インボイス(第3のプロセス220において準備された)をSPVチャネルサーバ120にポスティングする。インボイスは、たとえば、マーチャント130によって判断されたトランザクション出力を含む決済要求を含み得る。セキュアなチャネル125における決済要求の到着は、たとえばセキュアなチャネルの中に、見られるべき新規メッセージがあることを顧客に通知する通知を受信することを、顧客100に促す。
【0101】
ステップ244において、顧客100は、SPVチャネルサーバ120によって確立されたセキュアなチャネル125を介してマーチャント130から受信された決済インボイスを受信または閲覧する。顧客100は任意選択で、マーチャント130に関連付けられた決済サービスなどのアドレス指定プロセス/プロトコルまたは機構を実装することによって、要求がマーチャント130から発したというチェックを確かなものにする。いくつかの実施形態では、これは、マーチャント130からの要求を送ることを含み、要求は、顧客100用の別名に基づく。
【0102】
ステップ246において、顧客100は決済要求を読む。顧客100は次いで、決済要求の認可に進む。
【0103】
ステップ248において、顧客100は、決済のための入力およびマークルプルーフを顧客ウォレットからフェッチする。これらは、トランザクションを完了するために、マーチャント130によって顧客100へ送られる部分的トランザクション(トランザクションテンプレート)に追加されてよい。
【0104】
ステップ250において、顧客100は、決済トランザクションを構築し、トランザクション情報も構築し、この情報は、いくつかの実施形態では、マークルプルーフと、SPVエンベロープ300など、確認された祖先の完全なトランザクションとをさらに含むデータ構造を含み得る。
【0105】
図3Cは、SPVエンベロープ300ともいう、トランザクションをカプセル化するデータ構造の例示的概略を示す。SPVエンベロープ300の中に含まれ得るデータは、以下のうちの1つまたは複数を含む。
A)ブロードキャストされるべきトランザクション(Tx)310、
B)Aにおけるトランザクションの確認された入力の完全なトランザクション320、
C)Aにおけるトランザクションの未確認入力の完全なトランザクション330。これは、第1の確認されたトランザクション祖先までさかのぼることができ、それを含み得る、
D)Bおよび/もしくはCにおける各確認されたトランザクションのマークルプルーフ340、ならびに/または
E)Bおよび/もしくはCにおける各未確認トランザクションのためのmAPI応答(任意選択)350。
【0106】
SPVエンベロープ300は、確認された祖先のマークルプルーフ340および完全なトランザクション320とともに、トランザクションをカプセル化するデータ構造である。この構造は、確認されたトランザクション330に切れ目のないチェーンを返すための中間未確認祖先をさらに含んでもよい。任意選択で、未確認トランザクションには、ブロック包含のためにトランザクションがブロードキャストされ、受諾されたことを論証するために、マイナーによって署名されたmAPI応答350が伴ってよい。
【0107】
いくつかの実施形態では、これは、顧客ウォレットAPIを介して入力をフェッチすることによって実施されてよい。SPVエンベロープ300は、カプセル化されたマークルプルーフ340とともに、トランザクションが有効であることを証明するのを助ける情報を提供する。SPVエンベロープ300は、独立トランザクションチェックが実施されるために求められる補足情報を通信する標準化方法を確立する。様々な理由でSPV情報を送信および受信する非常に様々なウォレット実装形態が存在する見込みがあるので、標準フォーマットが採用された場合、実装が簡素化される。
【0108】
多くの場合、マイナーへのトランザクションのブロードキャスターは、トランザクション有効性、すなわち、合格/失格評価、正しいマイナー料金および署名完全性の独自チェックを実施するために求められる情報をもたない。さらに、SPVエンベロープ300は、トランザクションを認証するのに求められる情報を提供することによって、二重支出リスクの削減など、未確認祖先とのトランザクションにおけるより高いレベルの信頼性、および状態チャネルなど、暫定状態とのトランザクションを可能にする。
【0109】
マークルプルーフ340と署名付きmAPI応答350との組合せを含むことで、トランザクションが確認される見込みを評価するのに求められる情報がすべて提供される。受信者は任意選択で、mAPI応答が不適当と思われる場合、mAPI140により、すべての未確認祖先に二重支出通知を登録することができる。未加工トランザクションバイトは、証明プロセスの一部として算出される必要があるトランザクションIDとして使うことができる。
【0110】
料金を算出するための入力参照ならびに出力値を判断するために、トランザクションが解析され得る。SPVエンベロープ300はただ1つのトランザクションのための証明を含むことが、概して想定される。ただし、データ構造は、複数のトランザクションが含まれる場合に対応する。
【0111】
ステップ252において、顧客100は、インボイス(決済要求)を認可し、承認し、たとえば顧客の署名でインボイスに署名する。一実施形態では、顧客100は、ボタン、たとえば「OK」ボタンをクリックして、入力に署名し、インボイスを認証することができる。他の実施形態では、顧客は、署名として作用するパスワードまたはパスコードを尋ねられる場合がある。
【0112】
ステップ254において、顧客100からSPVチャネルサーバ120へ決済が(SPVエンベロープ300と一緒に)ポスティングされる。
【0113】
ステップ256において、SPVチャネルサーバ120とマーチャント130が通信して、SPVエンベロープと一緒に、完了された決済を取り出す。いくつかの実施形態では、決済およびSPVエンベロープは、マーチャント130の決済プロトコルサーバにおいて受信され得る。
【0114】
ステップ258において、マーチャント130は、決済トランザクション(Tx)を個別に認証する。いくつかの実施形態では、これは、マーチャントデバイスの決済プロトコルサーバが、マーチャントデバイスの決済認証元と通信することを含み得る。決済認証元は、ヘッダクライアントと対話して、たとえばSPV認証元とのSPVチェックを実施することによって、たとえば、決済トランザクションを認証し得る。SPV認証元は、ヘッダクライアントと通信して、決済トランザクションのブロックハッシュがブロックヘッダの最良チェーンの中にあることを認証する。ブロックハッシュが最良チェーンの中にあることが確認された場合、トランザクションは、有効なトランザクションとして確認され得る。
【0115】
本明細書で開示される実施形態によると、および、たとえばnChain Holdings Limitedの名義で2021年2月17日に出願された英国出願第GB2102217.3号においてより詳しく記載されるように、マーチャント130は、ブロックヘッダの最良チェーンに関連してヘッダクライアントに問い合わせるための機能を含む。トランザクションを構築したマーチャント130は、ブロックヘッダを、ブロックチェーンに含めるために提出する前に認証することができる。ブロックヘッダは、それらのトランザクション(または他のクライアントからのトランザクション)の状態について、外部ソースから学習することもできる。マーチャント130は、以下のデータを所有している場合、トランザクションが有効であると確信し得る。
・その包含が証明されるべきであるトランザクション。
・トランザクションがマークルルート値に寄与したことを示す、そのトランザクションのマークル包含証明。
・マークルルートを含むビットコインSVブロックヘッダ。
・プルーフオブワークによって測定されるブロックヘッダの最良チェーン。
【0116】
トランザクション包含の検証は、以下のように実施することができる。第1に、マーチャント130が、特定のトランザクションに関するヘッダクライアントに記憶されたブロックヘッダを要求または閲覧し、たとえば、ライトクライアントが最良チェーンを閲覧し得る。ライトクライアントは、ソーストランザクションおよび包含証明から、マークルツリーのルートを算出する。証明を捏造するのは、暗号的に強力なハッシュ関数を反転するのと同程度に困難であり、つまり、事実上不可能と見なされる。ライトクライアントは、前のステップにおいて算出されたマークルルートが、指定されたブロックヘッダの中で宣言されたマークルルートと一致することを検証する。ライトクライアントはまた、ブロックヘッダの最良チェーンを、指定されたブロックヘッダが最良チェーンの中に存在することを検証するのに使う。これらのチェックにすべて合格した場合、トランザクションは、ブロックチェーンに含まれる準備ができており、ライトクライアントは、トランザクションが検証されると判断する。
【0117】
マークルプルーフは、以下のデータを含み得る。
・マークルプルーフと関連するブロックチェーントランザクションのトランザクション識別子(TxID)、
・ブロックチェーントランザクションが含まれるブロックのブロックヘッダ、
・トランザクション識別子(TxID)用の兄弟ハッシュのアレイ。
【0118】
マーチャント130が決済トランザクションを認証すると、2つの代替プロセスが起こり得る。トランザクションが無効トランザクション(無効Tx)である第1のもの、またはトランザクションが有効トランザクション(有効Tx)である第2のものである。
【0119】
トランザクションが無効Txである場合、ステップ262において、マーチャント130は決済を拒絶する。マーチャント130は、この拒絶(エラー)に関して、SPVチャネルサーバ120へメッセージを送る。
【0120】
ステップ264において、SPVチャネルサーバ120は、決済拒絶(エラー)メッセージを、セキュアなチャネル125を通して顧客100へ送る。
【0121】
ただし、トランザクションが有効Txである場合、ステップ266において、マーチャント130は、ブロックチェーンにポスティングするためのトランザクションを提出する。決済認証元は、マーチャントデバイス130に関連付けられたトランザクションブロードキャスターと通信してよく、デバイス130はmAPI140と通信する。マーチャントデバイス130のトランザクションブロードキャスターは、mAPI140へPOST submitTransaction(Tx)を送る。mAPI140は、ステップ268においてマイナーノードであるブロックチェーンノード150にトランザクションをポスティングし、ステップ270において、マイナーノードから応答が受信される。決済プロセッサによって実装される決済サービスはAPIであるので、いくつかの実施形態では、第2の要求はHTTPS POST要求である。
【0122】
ステップ272において、mAPI140は、トランザクションがブロックチェーンに書き込まれたことを示すコールバック通知を、マーチャント130に戻す。いくつかの実施形態では、これは、mAPI140から、マーチャントデバイス130の決済プロトコルサーバへ送られるトランザクションポスティング応答であり得る。
【0123】
一実施形態では、コールバック通知は、ブロックチェーン中の所与のクライアントによって提出されたトランザクションの包含の証明、すなわちマークルプルーフに関する。この場合、マイナーによってチャネル125の中で提供されるデータは戻りマークルプルーフであり、前記戻りマークルプルーフはマイナーによって提供される。
【0124】
いくつかの実施形態では、mAPI140によって生成されたコールバック通知は、mAPI140とブロックチェーンネットワーク155のマイナーノード150との間でデータが交換されるとすぐに取得される警告またはメッセージであってよい。それは、特定のTxIDまたは決済プロセッサによってすでに処理されている、すなわち、決済プロセッサによってマイナーへすでに送られているブロックチェーントランザクションに関するので、コールバック通知と呼ばれ得る。
【0125】
他の実施形態では、コールバック通知は、顧客100によってすでに提出され、ブロックチェーンに記録されているトランザクションの二重支出の通知に関する。この場合、マイナーによって提供されるデータは、以下のデータを含む戻りペイロードである。
・二重支出であるブロックチェーントランザクションのトランザクション識別子(TxID)、およびいくつかの場合は任意選択で、
・ブロックチェーントランザクションを提出した決済プロセッサのためのサービスエンドポイント。これは、クライアントが複数の決済サービスに関連付けられる場合に有用であり、したがって識別子は、最初にマイナーに要求を提出した決済プロセッサを明白に示す。
【0126】
ステップ274において、確認応答、または「決済ACK」メッセージが、マーチャント130から、SPVチャネルサーバ120におけるセキュアなチャネル125へ送られる。
【0127】
ステップ276において、「決済ACK」メッセージが、SPVチャネルサーバ120におけるセキュアなチャネル125から顧客100へ送られる。他の実施形態では、顧客100は、セキュアなチャネル125の中のメッセージを閲覧し得る。
【0128】
いくつかの実施形態では、マーチャントデバイス130の決済プロトコルサーバは、トランザクションの現在の状況に関する問合せをmAPI140へ送り得る。返答として、mAPI140は、問合せに応答して更新されたトランザクション状況を、マーチャントデバイス130の決済プロトコルサーバへ送る。
【0129】
ステップ278において、マークルプルーフは、mAPI140から、SPVチャネルサーバ120におけるセキュアなチャネルへ送られる。セキュアなチャネル125を介して、マークルプルーフは、顧客100およびマーチャント130に配布され得る。
【0130】
ステップ280において、SPVチャネルサーバ120におけるセキュアなチャネル125において受信されたマークルプルーフが、SPVチャネルサーバ120から顧客100へ送られる。マークルプルーフは、顧客ウォレットに記憶することができる。
【0131】
ステップ282において、SPVチャネルサーバ120におけるセキュアなチャネル125において受信されたマークルプルーフが、SPVチャネルサーバ120からマーチャント130へ送られる。いくつかの実施形態では、マークルプルーフは、マーチャントデバイス130におけるSPVチャネルクライアントにおいて受信される。マーチャントデバイス130におけるSPVチャネルクライアントは次いで、マークルプルーフを、マーチャントデバイス130における決済プロトコルサーバにフォワードしてよい。マークルプルーフは、マーチャントウォレットに記憶することができる。
【0132】
任意選択で、トランザクションが完了され、マークルプルーフが提供され、そうすることによってトランザクションを認証すると、セキュアなチャネルは閉じられてよい。
【0133】
図4は、本開示の少なくとも一実施形態を実践するのに使われ得るコンピューティングデバイス400の例示的な簡略ブロック図を提供する。様々な実施形態において、コンピューティングデバイス400は、図示され、上述したシステムのいずれをも実装するのに使われ得る。たとえば、コンピューティングデバイス400は、マーチャントデバイス130として使われるように構成されてよい。したがって、コンピューティングデバイス400は、ポータブルコンピューティングデバイス、パーソナルコンピュータ、または任意の電子コンピューティングデバイスであってもよい。図4に示すように、コンピューティングデバイス400は、メインメモリ408および永続ストレージ410を含む記憶サブシステム406と通信するように構成することができる1つまたは複数のレベルのキャッシュメモリおよびメモリコントローラをもつ1つまたは複数のプロセッサ(まとめて402と標示される)を含み得る。メインメモリ408は、図示されるように、動的ランダムアクセスメモリ(DRAM)418および読取り専用メモリ(ROM)420を含み得る。記憶サブシステム406およびキャッシュメモリ402は、本開示に記載するトランザクションおよびブロックに関連付けられた詳細などの情報の記憶のために使われ得る。プロセッサ402は、本開示に記載する任意の実施形態のステップまたは機能性を提供するのに使用されてもよい。
【0134】
プロセッサ402は、1つまたは複数のユーザインターフェース入力デバイス412、1つまたは複数のユーザインターフェース出力デバイス414、およびネットワークインターフェースサブシステム416と通信することもできる。
【0135】
バスサブシステム404は、意図通りに互いと通信するための、コンピューティングデバイス400の様々な構成要素およびサブシステムを可能にするための機構を提供し得る。バスサブシステム404は、単一バスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを使用してよい。
【0136】
ネットワークインターフェースサブシステム416は、他のコンピューティングデバイスおよびネットワークへのインターフェースを提供し得る。ネットワークインターフェースサブシステム416は、コンピューティングデバイス400とは別のシステムからデータを受信し、そこへデータを送信するためのインターフェースとして働き得る。たとえば、ネットワークインターフェースサブシステム416は、データ技師が、データセンターなどの遠隔ロケーションにいる間にデバイスへデータを送信し、デバイスからデータを受信することが可能になり得るように、データ技師がデバイスをネットワークに接続することを可能にし得る。
【0137】
ユーザインターフェース入力デバイス412は、キーボードなど、1つまたは複数のユーザ入力デバイス、一体型マウス、トラックボール、タッチパッド、またはグラフィックスタブレットなどのポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、ボイス認識システム、マイクロフォンなどのオーディオ入力デバイス、および他のタイプの入力デバイスを含み得る。概して、「入力デバイス」という用語の使用は、コンピューティングデバイス400に情報を入力するための、すべての可能なタイプのデバイスおよび機構を含むことを意図している。
【0138】
1つまたは複数のユーザインターフェース出力デバイス414は、ディスプレイサブシステム、プリンタ、またはオーディオ出力デバイスなどの非視覚ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)などのフラットパネルデバイス、発光ダイオード(LED)ディスプレイ、または投影型もしくは他のディスプレイデバイスであってよい。概して、「出力デバイス」という用語の使用は、コンピューティングデバイス400から情報を出力するための、すべての可能なタイプのデバイスおよび機構を含むことを意図している。1つまたは複数のユーザインターフェース出力デバイス414は、たとえば、記載するプロセスおよびその変形を実施するアプリケーションとのユーザ対話を、そのような対話が適切であり得るとき、容易にするためのユーザインターフェースを提示するのに使われ得る。
【0139】
記憶サブシステム406は、本開示の少なくとも1つの実施形態の機能性を提供し得る基本的プログラミングおよびデータ構造を記憶するためのコンピュータ可読記憶媒体を提供し得る。アプリケーション(プログラム、コードモジュール、命令)は、1つまたは複数のプロセッサによって実行されると、本開示の1つまたは複数の実施形態の機能性を提供することができ、記憶サブシステム406に記憶されてよい。これらのアプリケーションモジュールまたは命令は、1つまたは複数のプロセッサ402によって実行され得る。記憶サブシステム406は、本開示に従って使われるデータを記憶するためのリポジトリをさらに提供し得る。たとえば、メインメモリ408およびキャッシュメモリ402は、プログラムおよびデータのための揮発性記憶を提供することができる。永続ストレージ410は、プログラムおよびデータのための永続(不揮発性)記憶を提供することができ、フラッシュメモリ、1つまたは複数の固体状態ドライブ、1つまたは複数の磁気ハードディスクドライブ、関連付けられた取り外し可能媒体をもつ1つまたは複数のフロッピーディスクドライブ、関連付けられた取り外し可能媒体をもつ1つまたは複数の光ドライブ(たとえば、CD-ROMまたはDVDまたはBlue-Ray)ドライブ、および他の同様の記憶媒体を含み得る。そのようなプログラムおよびデータは、本開示に記載される1つまたは複数の実施形態のステップを実践するためのプログラムならびに本開示に記載されるトランザクションおよびブロックに関連付けられたデータを含み得る。
【0140】
コンピューティングデバイス400は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション、または以下で説明する任意の他のデバイスも含む様々なタイプであってよい。さらに、コンピューティングデバイス400は、1つまたは複数のポート(たとえば、USB、ヘッドフォンジャック、ライトニングコネクタなど)を通してコンピューティングデバイス400に接続され得る別のデバイスを含み得る。コンピューティングデバイス400に接続され得るデバイスは、光ファイバコネクタを受け入れるように構成された複数のポートを含み得る。したがって、このデバイスは、光信号を電気信号にコンバートするように構成されてよく、電気信号は、デバイスをコンピューティングデバイス400に接続するポートを通して、処理のために送信され得る。コンピュータおよびネットワークの変化し続ける性質により、図4に示すコンピューティングデバイス400の記述は、デバイスの好ましい実施形態を例示する目的のための具体例としてのみ意図されている。図4に示すシステムよりも多いか、または少ない構成要素を有する多くの他の構成が可能である。
【符号の説明】
【0141】
10 システム
100 顧客、顧客デバイス、コンピュータ機器
105 インターネット
110 アドレス指定サーバ、決済サービス、決済サーバ、PayMailサーバ
120 チャネルサーバ、SPVチャネルサーバ
125 サイドチャネル、チャネル
130 マーチャント、マーチャントデバイス
140 マーチャントAPI(mAPI)、決済プロセッサ、決済プロセッサmAPI
150 ブロックチェーンノード、ブロックチェーン、マイナーノード
155 ピアツーピア(P2P)ネットワーク、ネットワーク
400 コンピューティングデバイス
402 プロセッサ、キャッシュメモリ
404 バスサブシステム
406 記憶サブシステム
408 メインメモリ
410 永続ストレージ
412 ユーザインターフェース入力デバイス
414 ユーザインターフェース出力デバイス
416 ネットワークインターフェースサブシステム
418 動的ランダムアクセスメモリ(DRAM)
420 読取り専用メモリ(ROM)
図1
図2
図3A
図3B
図3C
図4
【手続補正書】
【提出日】2024-04-02
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
顧客とマーチャントとの間のトランザクションを処理するための、マーチャントデバイスにおいて実施される、コンピュータにより実施される方法であって、
前記顧客に関連付けられた顧客デバイスから顧客情報を受信するステップと、
前記顧客情報に基づいて、前記顧客と前記マーチャントとの間のセキュアな通信チャネルを確立するステップと、
前記顧客情報に基づいて、部分的インボイストランザクションを生成するステップと、
前記セキュアな通信チャネルを介して、前記部分的インボイストランザクションを前記顧客デバイスへ送るステップと、
前記セキュアな通信チャネルを介して、前記部分的インボイストランザクションの完了バージョンであるとともに前記顧客デバイスにおいて認可されたトランザクションを受信するステップと、
前記トランザクションを認証するステップと、
前記認証されたトランザクションを、ブロックチェーンに提出されるようにブロックチェーンノードにブロードキャストするステップと、
前記トランザクションが前記ブロックチェーンノードによって認証され、前記ブロックチェーン上に含まれるという少なくとも1つの通知を受信するステップと
を含む、コンピュータにより実施される方法。
【請求項2】
前記顧客情報は、購入注文および前記顧客の別名を含む、請求項1に記載の方法。
【請求項3】
前記顧客の前記別名は、前記マーチャントデバイスの外部のサーバに関連して検証される、請求項2に記載の方法。
【請求項4】
前記顧客情報を受信するステップは、前記顧客と前記マーチャントとの間のハンドシェイク手順を確立する、請求項1に記載の方法。
【請求項5】
前記セキュアな通信チャネルは、前記マーチャントデバイスの外部のチャネルサーバに関連して確立される、請求項1に記載の方法。
【請求項6】
前記セキュアな通信チャネルは、通信が、前記マーチャントから前記顧客へと、前記顧客から前記マーチャントへの両方で送られることを許可する、請求項1に記載の方法。
【請求項7】
前記セキュアな通信チャネルはエンドツーエンド暗号化される、請求項1に記載の方法。
【請求項8】
前記部分的インボイストランザクションを生成するステップは、マーチャントウォレットに関連して、トランザクションテンプレートに1つまたは複数のトランザクション出力を投入するステップを含む、請求項1に記載の方法。
【請求項9】
前記トランザクションは、顧客ウォレットに関連付けられた1つまたは複数のトランザクション入力を含み、
前記1つまたは複数のトランザクション入力は、少なくとも、前のトランザクションのマークルルートを含む、請求項1に記載の方法。
【請求項10】
前記トランザクションは、確認された祖先の、マークルプルーフと、完全なトランザクションとをさらに含むデータ構造にカプセル化される、請求項9に記載の方法。
【請求項11】
前記トランザクションを認証するステップは、
前記前のトランザクションのマークルルートを個別に構築するステップと、
前記構築されたマークルルートを、前記1つまたは複数のトランザクション入力の前記マークルルートでクロスチェックするステップと
を含む、請求項9に記載の方法。
【請求項12】
前記マークルルートは、ブロックヘッダの最良チェーンを提供するヘッダクライアントと通信する前記マーチャントデバイスによって個別に構築される、請求項11に記載の方法。
【請求項13】
前記トランザクションにおいて提供される前記マークルルートが前記個別に構築されたマークルルートと一致する場合、前記トランザクションは認証される、請求項11に記載の方法。
【請求項14】
前記トランザクションはビットコイントランザクションである、請求項1に記載の方法。
【請求項15】
前記少なくとも1つの通知はコールバック通知である、請求項1に記載の方法。
【請求項16】
前記コールバック通知は、前記トランザクションが前記ブロックチェーンに成功裡に提出されたことを示す戻りマークルプルーフを提供する、請求項15に記載の方法。
【請求項17】
前記戻りマークルプルーフは、
前記マークルプルーフが関連するブロックチェーントランザクションのトランザクション識別子と、
前記ブロックチェーンが含まれるブロックのブロックヘッダと、
前記トランザクション識別子用の兄弟ハッシュのアレイと
を含む、請求項16に記載の方法。
【請求項18】
前記少なくとも1つの通知を前記顧客デバイスへ送るステップをさらに含む、請求項1に記載の方法。
【請求項19】
前記少なくとも1つの通知が受信されると、前記セキュアな通信チャネルを閉じるステップをさらに含む、請求項1に記載の方法。
【請求項20】
前記顧客の公開アドレスおよび前記マーチャントの公開アドレスは各々、前記顧客および前記マーチャントに関連付けられたそれぞれのデジタルウォレットの公開鍵を含む、請求項1に記載の方法。
【請求項21】
デジタル署名は、前記マーチャントおよび/または前記顧客のアイデンティティを検証するために使われ、
前記マーチャントと前記顧客の両方に関連付けられた前記デジタル署名は、前記トランザクションがブロックチェーン台帳上で作成され、記憶され、またはポスティングされる前に、各それぞれのエンティティの検証のために要求される、請求項20に記載の方法。
【請求項22】
顧客とマーチャントとの間のトランザクションを処理するためのコンピュータシステムであって、
請求項1から21のいずれか一項に記載の方法を実施するように構成されたマーチャントデバイスと、
顧客デバイスと、
ブロックチェーンネットワークを作り上げる複数のブロックチェーンノードのうちの1つであるブロックチェーンノードと
を備える、コンピュータシステム。
【請求項23】
プロセッサおよびメモリを備えるコンピューティングデバイスであって、前記メモリは実行可能命令を含み、前記実行可能命令は、前記プロセッサによる実行の結果として、前記コンピューティングデバイスに、請求項1から21のいずれか一項に記載のコンピュータにより実施される方法を実施させる、コンピューティングデバイス。
【請求項24】
実行可能命令を記憶したコンピュータ可読記憶媒体であって、コンピュータのプロセッサによって実行された結果として、前記コンピュータに、請求項1から21のいずれか一項に記載の方法を実施させる、コンピュータ可読記憶媒体。
【国際調査報告】