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

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

▶ ヴィチェーン ファウンデーション リミテッドの特許一覧

<>
  • 特許-ブロックチェーン取引処理 図1
  • 特許-ブロックチェーン取引処理 図2
  • 特許-ブロックチェーン取引処理 図3
  • 特許-ブロックチェーン取引処理 図4
  • 特許-ブロックチェーン取引処理 図5
  • 特許-ブロックチェーン取引処理 図6
  • 特許-ブロックチェーン取引処理 図7
  • 特許-ブロックチェーン取引処理 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-14
(45)【発行日】2023-12-22
(54)【発明の名称】ブロックチェーン取引処理
(51)【国際特許分類】
   G06Q 20/36 20120101AFI20231215BHJP
【FI】
G06Q20/36
【請求項の数】 26
(21)【出願番号】P 2020558447
(86)(22)【出願日】2019-04-18
(65)【公表番号】
(43)【公表日】2021-08-26
(86)【国際出願番号】 SG2019050223
(87)【国際公開番号】W WO2019203736
(87)【国際公開日】2019-10-24
【審査請求日】2022-04-15
(31)【優先権主張番号】62/659,917
(32)【優先日】2018-04-19
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/664,981
(32)【優先日】2018-05-01
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520401701
【氏名又は名称】ヴィチェーン ファウンデーション リミテッド
(74)【代理人】
【識別番号】100136319
【弁理士】
【氏名又は名称】北原 宏修
(74)【代理人】
【識別番号】100148275
【弁理士】
【氏名又は名称】山内 聡
(74)【代理人】
【識別番号】100142745
【弁理士】
【氏名又は名称】伊藤 世子
(74)【代理人】
【識別番号】100143498
【弁理士】
【氏名又は名称】中西 健
(72)【発明者】
【氏名】ジャンリャン グ
(72)【発明者】
【氏名】ビン キアン
(72)【発明者】
【氏名】ジヘン ジョウ
【審査官】星野 裕
(56)【参考文献】
【文献】特開2018-045540(JP,A)
【文献】特開2017-054339(JP,A)
【文献】特開2006-099644(JP,A)
【文献】特開2001-350915(JP,A)
【文献】特開2002-245256(JP,A)
【文献】特開2003-132289(JP,A)
【文献】特開2004-102787(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
ブロックチェーンノードを含むブロックチェーン取引処理システムにおいてブロックチェーン取引をコンピュータ処理する方法であって、
前記ブロックチェーンノードに対して、
前記ブロックチェーン取引の取引提案者と取引内容と取引受領者とを少なくとも示す取引要求を受信させることと、
前記取引内容に基づいて、前記ブロックチェーン取引をコンピュータ処理するための取引手数料を計算させることと、
前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることと、
前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引手数料が差し引かれる支払口座を決定させることと
を実行させる方法。
【請求項2】
前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることは、前記取引要求が前記取引受領者の署名情報をさらに示すという判定に応じて、前記取引提案者が前記取引受領者の保証付き利用者であることを判定させることを含む
請求項1に記載の方法。
【請求項3】
前記取引提案者と前記取引受領者との保証人関係に基づいて前記取引提案者が前記取引受領者の保証付き利用者であることを判定することに応じて、前記取引受領者の署名情報は、前記取引受領者の管理装置が前記取引受領者の秘密鍵を用いて前記取引内容に署名することによって生成されて前記取引要求に追加され、
前記保証人関係は、前記管理装置に格納される
請求項2に記載の方法。
【請求項4】
前記取引提案者のクレジット残高が前記取引手数料以上であると判定することにさらに応じて、前記取引受領者の署名情報は、前記取引受領者の管理装置が前記取引受領者の秘密鍵を用いて前記取引内容に署名することによって生成されて前記取引要求に追加される
請求項3に記載の方法。
【請求項5】
前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることとは、前記ブロックチェーンに記録された前記取引提案者と前記取引受領者との保証人関係に基づいて前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることを含む
請求項1に記載の方法。
【請求項6】
前記ブロックチェーンノードに対して、
前記取引提案者が前記取引受領者の保証付き利用者ではないという判定に応じて、前記取引提案者の第1口座の残高が前記取引手数料以上であるかどうかを判定させることと、
前記取引提案者の前記第1口座の残高が前記取引手数料以上であるという判定に応じて、前記取引提案者の前記第1口座を支払口座として決定させることと
をさらに実行させる
請求項5に記載の方法。
【請求項7】
前記取引手数料が差し引かれる支払口座を決定させることは、
前記取引受領者に関連付けられた保証人口座があるかどうかを判定させることと、
前記取引受領者に関連付けられた保証人口座があるという判定に応じて、前記保証人口座の残高が前記取引手数料以上であるかどうかを判定させることと、
前記保証人口座の残高が前記取引手数料以上であるという判定に応じて、前記保証人口座を前記支払口座として決定させることとを含む
請求項1に記載の方法。
【請求項8】
前記取引手数料が差し引かれる支払口座を決定させることは、
前記取引受領者に関連付けられた保証人口座がないという判定に応じて、または、前記保証人口座の残高が前記取引手数料未満であるという判定に応じて、前記取引受領者の第2口座の残高が前記取引手数料以上であるかどうかを決定させることと、
前記取引受領者の前記第2口座の残高が前記取引手数料以上であるという判定に応じて、前記取引受領者の前記第2口座を前記支払口座として決定させることとをさらに含む
請求項7に記載の方法。
【請求項9】
前記取引手数料が差し引かれる支払口座を決定させることは、
前記取引受領者の前記第2口座の残高が前記取引手数料未満であるという判定に応じて、前記取引提案者の第1口座の残高が前記取引手数料以上であるかどうかを判定させることと、
前記取引提案者の前記第1口座の残高が前記取引手数料以上であるという判定に応じて、前記取引提案者の前記第1口座を前記支払口座として決定させることとを含む
請求項8に記載の方法。
【請求項10】
前記ブロックチェーンノードに対して、
前記取引内容が送金取引を示して前記取引提案者から前記取引受領者に暗号通貨の送金額が送金されるという判定に応じて、前記取引提案者の第3口座の残高が前記送金額以上であるかどうかを判定させることと、
前記取引提案者の前記第3口座の残高が前記送金額以上であるという判定に応じて、前記取引提案者の前記第3口座から前記取引受領者の第4口座に暗号通貨の前記送金額を送金させることと
をさらに実行させる
請求項9に記載の方法。
【請求項11】
前記第1口座および前記第2口座は第1種類の暗号通貨に対応し、
前記第3口座および前記第4口座は第2種類の暗号通貨に対応し、
前記第1種類は、前記第2種類と異なる
請求項10に記載の方法。
【請求項12】
前記ブロックチェーンノードに対して、
前記取引内容が送金取引を示して前記取引提案者から前記取引受領者に暗号通貨の送金額が送金されるという判定に応じて、前記取引提案者の前記第1口座の残高が前記送金額以上であるかどうかを判定させることと、
前記取引提案者の前記第1口座の残高が前記送金額以上であるという判定に応じて、前記取引提案者の前記第1口座から前記取引受領者の前記第2口座に前記暗号通貨の送金額を送金させることと
をさらに実行させ、
前記第1口座、前記第2口座および前記暗号通貨の送金額は、第1種類の暗号通貨に対応する
請求項9記載の方法。
【請求項13】
前記取引手数料が差し引かれる支払口座を決定させることは、
前記ブロックチェーンに記録された前記取引提案者のクレジット情報に基づいて、前記取引提案者のクレジット残高が前記取引手数料以上であるかどうかを判定させることと、
前記取引提案者のクレジット残高が前記取引手数料以上であるという判定に応じて、前記取引手数料が差し引かれる前記支払口座を決定させることとをさらに含む
請求項1に記載の方法。
【請求項14】
前記クレジット情報は、クレジット限度および利用済みクレジットを少なくとも示し、
前記クレジット残高は、「クレジット残高=クレジット限度-利用済みクレジット」によって決定される
請求項13に記載の方法。
【請求項15】
前記クレジット情報は、クレジット復元率およびブロック高をさらに含み、
前記クレジット復元率は、通過する各ブロックによって復元されるクレジット額を示し、
前記ブロック高は、前記取引受領者が前記取引提案者の前記取引手数料を支払った前回から通過したブロック数を示し、
前記クレジット残高は、「クレジット残高=クレジット限度-利用済みクレジット+ブロック高×クレジット復元率」によって決定される
請求項14に記載の方法。
【請求項16】
前記クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し、
前記クレジット残高は、「クレジット残高=クレジット支払回数限度-利用済みクレジット支払回数」によって決定される
請求項13に記載の方法。
【請求項17】
管理装置を含むブロックチェーン取引処理システムにおいてブロックチェーン取引をコンピュータ管理する方法であって、
前記管理装置に対して、
前記ブロックチェーン取引の取引提案者から、前記ブロックチェーン取引の前記取引提案者、取引内容および取引受領者を少なくとも示す要求を受信することと、
前記取引提案者が前記取引受領者の保証付き供利用者であるかどうかを判定させることと、
前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引受領者の署名情報を生成すると共に受信した前記要求に前記取引受領者の署名情報を追加することによって、取引要求を形成させることと
を実行させ、
前記署名情報は、前記ブロックチェーン取引を処理するブロックチェーンのブロックチェーンノードに対する取引手数料を前記取引受領者に関連付けられた支払口座から差し引くことができることを示す
方法。
【請求項18】
前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることは、前記取引提案者と前記取引受領者との保証人関係に基づいて、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定させることを含み、
前記保証人関係は、前記管理装置に格納される
請求項17に記載の方法。
【請求項19】
前記署名情報を生成すると共に受信した前記要求に前記署名情報を追加することによって、取引要求を形成させることは、
前記管理装置に格納された前記取引提案者のクレジット情報に基づいて、前記取引提案者のクレジット残高が前記取引手数料以上であるかどうかを判定させることと、
前記取引提案者のクレジット残高が前記取引手数料以上であるという判定に応じて、前記取引受領者の秘密鍵で前記取引内容に署名させることによって、前記署名情報を生成させると共に受信した前記要求に前記署名情報を追加させることとを含む
請求項17に記載の方法。
【請求項20】
前記クレジット情報は、クレジット限度および利用済みクレジットを少なくとも示し、
前記クレジット残高は、「クレジット残高=クレジット限度-利用済みクレジット」によって決定される
請求項19に記載の方法。
【請求項21】
前記クレジット情報は、クレジット復元率およびブロック高をさらに含み、
前記クレジット復元率は、通過する各ブロックによって復元されるクレジット額を示し、
前記ブロック高は、前記取引受領者が前記取引提案者の前記取引手数料を支払った前回から通過したブロック数を示し、
前記クレジット残高は、「クレジット残高=クレジット限度-利用済みクレジット+ブロックの高さ×クレジット復元率」によって決定される
請求項20に記載の方法。
【請求項22】
前記クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し、
前記クレジット残高は、「クレジット残高=クレジット支払回数限度-利用済みクレジット支払回数」によって決定される
請求項19に記載の方法。
【請求項23】
ブロックチェーン取引をコンピュータ処理する装置であって、
1以上のプログラムを格納するように構成されるメモリと、
前記メモリに結合され、前記1以上のプログラムを実行して請求項1から16のいずれか1項に記載の方法を前記装置に実行させるように構成される処理部と
を備える装置。
【請求項24】
ブロックチェーン取引をコンピュータ管理する装置であって、
1以上のプログラムを格納するように構成されるメモリと、
前記メモリに結合され、前記1以上のプログラムを実行して請求項17から22のいずれか1項に記載の方法を前記装置に実行させるように構成される処理部と
を備える装置。
【請求項25】
機械実行可能命令が格納される非一時的コンピュータ可読記憶媒体であって、
前記機械実行可能命令は、実行されると、請求項1から22のいずれか1項に記載の方法を機械に実行させる
非一時的コンピュータ可読記憶媒体。
【請求項26】
非一時的コンピュータ可読媒体に有形に格納され、機械実行可能命令を備え、
前記機械実行可能命令は、実行されると、請求項1から22のいずれか1項に記載の方法の過程を機械に実行させる
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施形態は一般に、ブロックチェーン上の取引処理の分野に関し、より詳細には、ブロックチェーン取引処理またはブロックチェーン取引管理に関する。
【背景技術】
【0002】
従来のブロックチェーン取引処理体系では、個人または企業は、ブロックチェーンサービスを使用し、暗号通貨を送金したい場合またはスマートコントラクトを呼び出して実行したい場合には必ず、ネットワークに取引を送信し、自分自身の口座残高を用いることでブロックチェーン取引を処理するために必要な取引手数料を支払わなければならない。
【0003】
いくつかのブロックチェーンアプリケーションでは、取引提案者は通常の利用者であり得る。利用者は、暗号通貨を市場から入手するとき、高い価格変動率に直面することになる。したがって、従来の取引管理体系は、通常の利用者がブロックチェーン取引を処理するための取引手数料を支払うのに便利ではない。さらに、送金取引の場合、暗号通貨額を取引提案者から取引受領者に送金する必要がある。ブロックチェーン取引手数料および送金額は、異なる種類の暗号通貨であり得る。このことは、「利用者が、少なくとも2種類の暗号通貨を有すると共に様々な種類のツールに精通して利用者の暗号通貨を管理し、取引手数料および送金額に対して口座残高が十分であることを保証しなければならない。」ことを必要とする。したがって、従来の取引処理体系では、通常の利用者がブロックチェーンアプリケーションを使用するのに多くの負担がかかる。
【発明の概要】
【発明が解決しようとする課題】
【0004】
一般に、本開示の例示的な実施形態は、ブロックチェーン取引を処理または管理するための解決策を提供する。これにより、通常の利用者はブロックチェーンサービスを便利に利用し得る。
【課題を解決するための手段】
【0005】
本開示の第1局面によれば、ブロックチェーン取引を処理するための方法が提供される。前記方法は、前記ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードにおいて、取引要求を受信することを含む。前記取引要求は、前記取引の取引提案者と取引内容と取引受領者とを少なくとも示す。前記方法は、前記取引内容に基づいて、前記取引を処理するための取引手数料を計算することと、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することと、前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引手数料が差し引かれる支払口座を決定することとをさらに含む。
【0006】
本開示の第2局面によれば、ブロックチェーン取引を管理するための方法が提供される。前記方法は、前記ブロックチェーン取引を管理するための管理装置において、前記取引の取引提案者から要求を受信することを含む。前記要求は、前記取引の前記取引提案者と取引内容と取引受領者とを少なくとも示す。前記方法は、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することと、前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引受領者の署名情報を生成すると共に受信した前記要求に前記取引受領者の署名情報を追加することによって、取引要求を形成することとをさらに含む。前記署名情報は、前記ブロックチェーン取引を処理するブロックチェーンのブロックチェーンノードに対する取引手数料を前記取引受領者に関連付けられた支払口座から差し引くことができることを示す。
【0007】
本開示の第3局面によれば、ブロックチェーン取引を処理するための装置が提供される。前記装置は、メモリと処理部とを含む。前記メモリは、1以上のプログラムを格納するように構成される。前記処理部は、前記メモリに結合され、前記1以上のプログラムを実行して本開示の第1の局面に係る方法の過程を前記装置に実行させるように構成される。
【0008】
本開示の第4局面によれば、ブロックチェーン取引を管理するための装置が提供される。前記装置は、メモリと処理部とを含む。前記メモリは、1以上のプログラムを格納するように構成される。前記処理部は、前記メモリに結合され、前記1以上のプログラムを実行して本開示の第2の局面に係る方法の過程を前記装置に実行させるように構成される。
【0009】
本開示の第5局面によれば、機械実行可能命令が格納される非一時的コンピュータ可読記憶媒体が提供される。前記機械実行可能命令は、実行されると、本開示の第1局面および第2局面のいずれか1局面に係る方法の過程を機械に実行させる。
【0010】
本開示の第6局面によれば、コンピュータプログラム製品が提供される。前記コンピュータプログラム製品は、非一時的コンピュータ可読媒体に有形に格納され、機械実行可能命令を備える。前記機械実行可能命令は、実行されると、本開示の第1局面および第2局面のいずれか1局面に係る方法の過程を機械に実行させる。
【0011】
本概要は本開示の実施形態の要所または本質的な特徴を識別することを意図するものではなく、また、本概要は本開示の範囲を限定するように利用されることを意図するものでもないことを理解されたい。本開示の他の特徴は、以下の説明を通して容易に理解されるであろう。
【図面の簡単な説明】
【0012】
上記記載、および、本開示の他の目的、特徴および利点は、図面を参照して本開示の例示的な実施形態をより詳細に説明することで、より明らかにされるであろう。なお、同一の参照符号は、本開示の例示的な実施形態における同一の部分を表す。
図1】従来技術における取引処理方法のフローチャートを示す。
図2】本開示の実施形態による取引処理システムの体系図を示す。
図3】本開示の実施形態によるブロックチェーン取引を処理するための方法のフローチャートを示す。
図4】本開示の実施形態によるブロックチェーン取引を管理するための方法のフローチャートを示す。
図5】本開示の一実施形態による管理装置によって受信される要求を示す。
図6】本開示の一実施形態による取引受領者の署名情報を伴う取引要求を示す。
図7】本開示の実施形態によるブロックチェーン取引を処理するための方法のフローチャートを示す。
図8】本開示の実施形態を実施するのに適した例示的な装置のブロック図を概略的に示す。
【0013】
なお、各図において、同一の符号または対応する符号は、同一の構成要素または対応する構成要素を示す。
【発明を実施するための形態】
【0014】
いくつかの例示的な実施形態を参照して本開示の原理を説明する。これらの実施形態は、開示の範囲に関していかなる限定を示唆するものではなく、説明目的のためにのみ記載されており、当業者が本開示を理解して実施するための助けになることが、理解されるであろう。本明細書で説明される開示は、下記方法以外の様々な方法で実施され得る。
【0015】
以下の説明および特許請求の範囲では、別段の定義がない限り、本明細書で使用されるすべての技術用語および専門用語は、当業者によって一般に理解される意味と同意である。
【0016】
本開示における「一実施形態」、「実施形態」、「例示的な実施形態」などへの言及は、記載された実施形態が特定の特徴、構造または性質を含み得ることを示す。しかし、すべての実施形態が特定の特徴、構造または性質を含む必要はない。さらに、そのような文言は、必ずしも同じ実施形態を参照しているわけではない。さらに、特定の特徴、構造または性質が実施形態に関連して記載されている場合、明示的に記載されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造または性質に影響を及ぼすことは当業者の知識の範囲内であることが提示される。
【0017】
「第1」、「第2」、「第3」および「第4」などの用語が本明細書で使用されて様々な要素が説明され得るが、これらの要素はこれらの用語によって限定されるべきではないことを理解されたい。これらの用語は、1つの要素を他の要素から区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱しなければ、第1要素を第2要素と呼ぶことができ、同様に、第2要素を第1要素と呼ぶことができる。例えば、以下の説明では、第1、第2、第3および第4口座は、口座の数または順序を限定する意味ではなく、異なる主体の異なる口座を区別することのみを意味する。本明細書で使用されるように、「および/または」という用語は、列挙される1以上の用語の任意の組合せおよびすべての組合せを含む。
【0018】
本明細書で使用される用語は、特定の実施形態を説明するためだけのものであり、例示的な実施形態を限定することを意味するものではない。本明細書で使用されるように、単数形「a」、「an」および「the」は、文脈に別段の明示がない限り、複数形も含むことを意味するものである。「comprises」、「comprising」、「has」、「having」、「includes」および/または「including」という用語は、本明細書で使用される場合、述べられた特徴、要素および/または構成要素などの存在を明示するが、1以上の他の特徴、要素、構成要素および/またはそれらの組合せの存在または追加を排除するものではないことがさらに理解されるであろう。
【0019】
図1は、従来技術における取引管理方法100のフローチャートを示す。図1に示されるように、ブロック102において、ブロックチェーンの取引処理ノードは取引要求を受信する。例えば、取引要求は、取引提案者から取引受領者に暗号通貨額を送金するための送金取引を示す。ブロック104において、取引処理ノードは、取引提案者の識別性を認証する。ブロック106において、取引処理ノードは、取引を処理するための取引手数料を計算する。ブロック108において、取引処理ノードは、取引提案者の口座残高が、計算された取引手数料以上であるかどうかを判定する。ブロック108における判定結果がNoである場合、方法100はブロック116に進み、取引処理が失敗したと判定される。ブロック108における判定結果がYesである場合、すなわち、取引提案者の口座残高が、計算された取引手数料以上である場合、ブロック110において、取引処理ノードは、取引提案者の口座から取引手数料を差し引く。次に、取引提案者から取引受領者に暗号通貨額を送金するための送金取引を取引要求が示す場合、ブロック112において、取引処理ノードは、取引提案者の更新後口座残高が送金予定額以上であるかどうかを判定する。ブロック112における判定結果がYesである場合、ブロック114において、取引処理ノードは、取引提案者の口座から取引受領者の口座に暗号通貨額を送金する。ブロック112における判定結果がNoである場合、すなわち、取引提案者の更新後口座残高が送金予定額未満である場合、方法100はブロック116に進み、取引処理が失敗したと判定される。
【0020】
上述のように、従来の取引処理体系では、取引を処理するための取引手数料を取引提案者だけが支払うことができる。提案者の口座残高が必要取引手数料未満であるか送金予定額未満である場合、取引処理は失敗する。さらに、多くのブロックチェーンシステムでは、ブロックチェーン取引手数料および送金予定額が、異なる種類の暗号通貨であり得る。この場合、取引提案者は、少なくとも2種類の暗号通貨を有すると共にそれらの暗号通貨を管理するための少なくとも2種類のツールに精通し、それらの口座残高が取引手数料および送金予定額に対して十分であることを保証することを必要とする。したがって、従来の取引処理体系では、通常の利用者に多くの負担がかかる。
【0021】
上記の問題および他の潜在的問題の1つ以上を少なくとも部分的に対処するために、本開示の例示的な実施形態は、取引処理解決策を提案する。本解決策では、ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードが取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示す。ブロックチェーンノードは、取引を処理するための取引手数料を取引内容に基づいて計算し、取引提案者が取引受領者の保証付き利用者であるかどうかを判定する。取引提案者が取引受領者の保証付き利用者であるという判定に応じて、ブロックチェーンノードは、取引手数料が差し引かれる支払口座を決定する。本開示で提供される取引処理解決策により、通常の利用者はブロックチェーンサービスを便利に使用することができる。
【0022】
取引提案者だけがブロックチェーン取引手数料を支払うことができる従来の取引処理体系とは異なり、上記の解決策では、取引提案者が取引受領者の保証付き利用者であるということを判定することによって、取引処理ノードは、取引手数料が差し引かれる支払口座を決定し得る。ブロックチェーン取引手数料は、決定された支払口座(例えば、保証人口座、取引受領者口座または取引提案者口座のいずれか1つ)から支払われ得る。このようにして、通常の利用者は、特別な注意を払うことなく自分の暗号通貨を使用/管理して取引手数料を支払い、現在の通常アプリのようにブロックチェーンサービスを利用し得る。したがって、本開示が提供されることにより、通常の利用者がブロックチェーンサービスをより便利に使用し、複数の異なるブロックチェーンサービスを有する企業がこれらのサービスをより便利に管理することができる。本開示は、より多くの利用者がブロックチェーンサービスを使用することを促進する。
【0023】
図2は、本開示の実施形態による取引処理システム200の体系図を示す。図2に示されるように、システム200は、管理装置214と、ブロックチェーン取引を処理するための複数のノード212-1,212-2~212-N(すなわち、取引処理ノード212)と、複数の端末装置(例えば、携帯電話242、コンピュータ240および244)とを備える。管理装置214および取引処理ノード212はすべて、ブロックチェーンプラットフォーム210のブロックチェーンノードとなり得る。管理装置214、取引処理ノード212および端末装置は、ネットワーク230を介してデータの相互作用を実行し得る。
【0024】
ブロックチェーンノードの数および端末装置の数はいかなる限定を示唆するものではなくて例示目的のためだけのものであることを理解されたい。システム200は、本開示の実施形態を実施するのに適した任意の適切な数のブロックチェーンノードおよび端末装置を含み得る。
【0025】
端末装置は任意の終端装置を含み得る。終端装置は、携帯電話(a mobile phone)、携帯電話(a cellular phone)、スマートフォン、ボイスオーバーIP(VoIP)電話、無線ローカルループ電話、タブレット、携帯情報端末(PDA)、携帯型コンピュータ、デスクトップコンピュータなどを含み得るが、これらに限定されるものではない。利用者250または252は、対応する端末装置240または242を介して取引を開始し得て、端末装置は、管理装置214の受領者アドレスに関連するサービス用に、対応する取引要求を管理装置214に送信し得る。いくつかの実施形態では、財布アプリケーションを端末装置上で実行することができる。利用者250または252は、財布アプリケーションを介して管理装置214に登録し、関連アカウントIDを取得し得る。関連アカウントIDは、管理装置214において利用者を一意に識別する。関連アカウントIDは、例えば、利用者の識別子(メールボックスまたは携帯電話番号など)と、管理装置214または管理装置214の管理者の識別子との組み合わせであり得るが、これに限定されない。さらに、利用者250または252は、財布アプリケーションを介して自身のアドレスを生成し、自身のブロックチェーン取引の提案者アドレスまたは受領者アドレスとして作用し得る。いくつかの実施形態において、端末装置は、利用者の秘密鍵で取引要求に署名することによって、取引要求についての署名情報を生成し得る。利用者は、取引手数料の支払いを保証する専用の取引受領者のスマートコントラクトに登録することによって、取引受領者の保証付き利用者になり得る。
【0026】
管理装置214は、ブロックチェーンプラットフォーム210のノードとして作用するためのネットワーク装置であり得る。管理装置214は、1以上のコンピュータまたはサーバを含み得るが、これらに限定されない。管理装置214は、各端末装置を介して利用者250および252から取引要求を受信し得る。管理装置214は、利用者250および252のアドレスを介して利用者250および252にブロックチェーンサービスを提供し得る。例えば、利用者252は、取引受領者の保証付き利用者であると想定される。ここで、取引受領者の保証付き利用者は、取引受領者の受領者アドレスに登録され、取引受領者による保証人支払いのスマートコントラクトに署名している。言い換えれば、取引受領者の保証付き利用者は、取引受領者の登録済み利用者として取引受領者(例えば、管理装置214)に登録されるだけでなく、取引受領者に対して利用者が開始した取引についての取引手数料の支払いを保証する専用の取引受領者のスマートコントラクトにも明確に登録される。また、利用者250は取引受領者の単なる通常の登録済み利用者であるが受領者の保証付き利用者ではないと想定される。管理装置214は、管理装置214の初期化工程中に、保証人口座と取引受領者とを関連付け得る。さらに、いくつかの実施形態では、管理装置214はまた、保証付き利用者ごとにクレジット情報を決定し得る。いくつかの実施形態では、管理装置214は、受信した要求の取引提案者が取引受領者の保証付き利用者であることを判定し得て、その後、取引受領者の秘密鍵で取引要求に署名することによって署名情報を生成して受信した要求に追加し、取引要求を形成し得る。管理装置214はさらに、ブロックチェーンプラットフォーム210上に署名情報付き取引要求を送信し得るか、取引処理ノード212のいずれかまたはすべてに署名情報付き取引要求を送信し得る。この場合、管理装置214は、取引受領者の署名情報を用いて、この取引に対する取引手数料が取引受領者によって支払われ得ることを、取引を処理するための取引処理ノード212に対して示し得る。
【0027】
ここで、管理装置214、取引受領者、受領者アドレス、および、取引受領者の口座は、いくつかの実施形態では交換可能に使用され、現在の取引が向けられるブロックチェーン主体を示し得る。
【0028】
ブロックチェーンプラットフォーム210に関しては、ブロックチェーン取引を処理すると共に取引結果データを蓄積するために使用される。ブロックチェーンプラットフォーム210は、構造的には、例えば、基本サービス層、スマートコントラクト層およびブロックチェーン最下層を上から下に備える(図示せず)。ブロックチェーンプラットフォーム210は、管理装置214および取引処理ノード212を備え得る。さらに、ブロックチェーンプラットフォーム210は、端末装置240,242および244のいずれかまたはすべてがブロックチェーンノードとして作用し得る場合、それらをさらに含み得る。いくつかの実施形態では、ブロックチェーンプラットフォーム210は、プライベート型ブロックチェーン、パブリック型ブロックチェーンまたはフェデレーテッド型ブロックチェーンを基にすることができる。
【0029】
取引処理ノード212は、ブロックチェーンプラットフォーム210のノードとして作用するためのネットワーク装置であり得る。取引処理のための取引処理ノード212(すなわち、取引処理ノード212)は、1以上のコンピュータまたはサーバを含み得るが、これらに限定されない。取引処理ノード212は、管理装置214から取引要求を受信し、受信した取引要求に基づいて、取引を処理するための取引手数料を計算することが可能であり得る。取引処理ノード212は、取引提案者が取引受領者の保証付き利用者であると判定すると、支払口座を決定し、計算された取引手数料を支払口座から差し引き得る。いくつかの実施形態では、取引処理ノード212は、受信した取引要求に示される取引受領者の署名情報に基づいて、または、取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。後者の場合、保証人関係は、ブロックチェーンプラットフォーム210または取引処理ノード212に格納され得る。前者の場合、同様の保証人関係が管理装置214の管理装置214に格納され、取引提案者が取引受領者の保証付き利用者であるかどうかが判定され得る。
【0030】
いくつかの実施形態では、取引提案者が取引受領者の保証付き利用者であると取引処理ノード212が判定した場合、本開示の3層支払モデルは、取引手数料が差し引かれる支払口座を決定するために使用される。以下、図3図7を参照して、3層支払モデルについて詳述する。
【0031】
一方、取引提案者が取引受領者の保証付き利用者ではないと取引処理ノード212が判定した場合、取引提案者の第1口座残高が取引手数料以上であるかどうかが判定され得る。提案者の第1口座残高が取引手数料以上である場合、取引処理ノード212は、取引提案者の第1口座を支払口座として決定し、取引提案者の第1口座から取引手数料を差し引き得る。
【0032】
図3は、本開示の実施形態によるブロックチェーン取引を処理するための方法300のフローチャートを示す。図3では、例えば、図2に示されるような取引処理ノード212のプロセッサによって、様々な処理が実行される。方法300はまた、図示されていない追加の処理を含み得て、および/または、図示された処理を省略し得て、本開示の範囲はこの点で限定されない。
【0033】
ブロック302において、取引処理ノード212は取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示す。取引処理ノード212は、図2に示されるように管理装置214から取引要求を受信し得る。いくつかの実施形態では、取引要求は、取引提案者の署名情報および/または取引受領者の署名情報をさらに示す。いくつかの実施形態では、取引受領者は、業務運営システムであって、業務運営システムは、特定のスマートコントラクトに基づいて、受領者の保証付き利用者または受領者の通常の登録済み利用者に1以上のサービスを提供する。
【0034】
ブロック304において、取引処理ノード212は、取引内容に基づいて、取引を処理するための取引手数料を計算する。例えば、取引が、ブロックチェーンプラットフォーム上に新しいスマートコントラクトを展開すること、展開されたスマートコントラクトを呼び出すこと、または、取引提案者から取引受領者に暗号通貨送金額を送金することであることを、取引内容は示し得る。いくつかの実施形態では、取引手数料および送金額は、異なる種類の暗号通貨であり得る。いくつかの他の実施形態では、取引手数料および送金額は共に同じ種類の暗号通貨である。
【0035】
ブロック306において、取引処理ノード212は、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。
【0036】
いくつかの実施形態では、取引処理ノード212は、受信した取引要求によって示される取引受領者の署名情報に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。この場合、取引要求を取引処理ノード212に送信する前に、管理装置214は、例えば、管理装置214に格納された取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者(すなわち、管理装置214)の保証付き利用者であるかどうかを判定し得る。取引提案者が取引受領者の保証付き利用者であるという判定に応じて、管理装置214は、取引提案者の対応する端末装置から受信した要求に署名をさらに加え得る。署名は、管理装置214が管理装置214の秘密鍵を用いて取引内容に署名することによって生成され得る。このようにして、取引処理ノード212は単に、受信した取引要求が、管理装置214の署名を含むかどうかを調べ、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。
【0037】
代替的に又は追加的に、取引処理ノード212は、取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。保証人関係は、ブロックチェーンプラットフォーム210のノードの一部または全てに記録される。この場合、保証人関係は、あらかじめブロックチェーンプラットフォーム210上でブロックとして公開されている。また、取引処理ノード212は、ブロックチェーンプラットフォーム210上に記録された保証人関係(以下の表1に示されるように)に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。
【0038】
いくつかのさらなる実施形態では、取引提案者が取引受領者の保証付き提供利用者であると管理装置214が判定した後、管理装置214は、取引提案者のクレジット残高が取引手数料以上であるかどうかをさらに判定し得る。この判定は、管理装置214に格納される保証付き利用者専用のクレジット情報(以下の表3にクレジット案として示されるように)を参照して行われ得る。保証付き利用者のクレジット情報は、管理装置214の管理人又は管理装置214の他の監督人によって、あらかじめ設定され得る。取引提案者のクレジット残高が取引手数料以上である場合にのみ、取引受領者の署名情報が生成されて取引要求に加えられる。このようにして、取引処理ノード212は、取引要求内に管理装置214の署名情報が存在していることを単に確認することによって、取引提案者が取引受領者の保証付き利用者であると共に取引提案者のクレジット残高が十分であると判定し得る。
【0039】
図3に戻ると、ブロックチェーンプラットフォーム210に記録される保証人関係に基づいて取引提案者が取引受領者の保証付き利用者であるかどうかを取引処理ノード212が判定する実施形態では、取引提案者が取引受領者の保証付き利用者であるという判定に応じて、方法300は、取引提案者のクレジット残高が取引手数料(図示せず)以上であるかどうかを取引処理ノード212が判定することをさらに含み得る。判定は、ブロックチェーンプラットフォーム210のノードの一部またはすべてに格納される保証付き利用者専用のクレジット情報(以下の表3にクレジット案として示されるように)を参照して行われ得る。保証付き利用者のクレジット情報は、管理装置214の管理人または管理装置214の他の監督人によってあらかじめ設定され得て、ブロックチェーンプラットフォーム210上でブロックとして公開され得る。
【0040】
上述したクレジット情報は、取引受領者が保証付き利用者の取引手数料を支払う金額の上限であるクレジット限度を少なくとも示す。いくつかの実施形態では、管理装置214またはブロックチェーンプラットフォーム210に格納されるクレジット情報は利用済みクレジットをさらに含み得る。利用済みクレジットは、取引受領者が保証付き利用者の取引手数料に対して支払った金額を示す。この場合、クレジット残高は、クレジット限度および利用済みクレジットに基づいて決定され得る。例えば、クレジット残高は、以下の式(1)によって決定され得る。
クレジット残高=クレジット限度-利用済みクレジット ・・・(1)
【0041】
いくつかの実施形態ではクレジット限度および利用済みクレジットに加えて、クレジット情報は、クレジット復元率およびブロック高をさらに含み得る。クレジット復元率は、通過する各ブロックによって保証付き利用者が復元するクレジット額を示し、ブロック高は、取引受領者が取引提案者(保証付き利用者)の取引手数料を支払った前回から通過したブロック数を示す。各ブロックによって復元されるクレジット額はクレジット限度を超えることはできないことは明らかである。この場合、クレジット残高は、以下の式(2)で決定され得る。
クレジット残高=クレジット限度-利用済みクレジット+ブロック高×クレジット復元率 ・・・(2)
【0042】
あるいは、クレジット案は、保証付き利用者に対する取引受領者による保証人支払いの回数形式であり得る。この場合、クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し得る。クレジット支払回数限度は、取引受領者が保証付き利用者の取引手数料を支払う回数の上限であり得て、利用済みクレジット支払回数は、取引受領者が保証付き利用者の取引手数料を支払った回数を示し得る。この場合、クレジット残高は、以下の(3)式によって決定され得る。
クレジット残高=クレジット支払回数限度-利用済みクレジット支払回数 ・・・(3)
【0043】
ブロック308において、取引処理ノード212は、取引提案者が取引受領者の保証付き利用者である(および、いくつかのさらなる実施形態では、クレジット残高が取引手数料に対して十分である)と判定すると、取引手数料が差し引かれる支払口座をさらに決定する。
【0044】
いくつかの実施形態では、支払口座は3層モデルによって決定され得る。これを用いると、取引手数料が、保証人口座、取引受領者、取引提案者の順に従って差し引かれ得る。
【0045】
いくつかの実施形態では、取引処理ノード212は、取引受領者に関連付けられた保証人口座があるかどうかを判定し得る。取引処理ノード212が取引受領者に関連付けられた保証人口座があると判定した場合、取引処理ノード212は、保証人口座残高が取引手数料以上であるかどうかをさらに判定し得る。保証人口座残高が取引手数料以上であると判定された場合、取引処理ノード212は、保証人口座を支払口座として決定し、保証人口座から取引手数料を差し引き得る。一方、取引処理ノード212が、取引受領者に関連付けられた保証人口座がないと判定した場合、または、保証人口座残高が取引手数料未満であると判定した場合、取引処理ノード212は、取引受領者の第2口座残高が取引手数料以上であるかどうかを判定し得る。
【0046】
取引処理ノード212が、取引受領者の第2口座残高が取引手数料以上であると判定した場合、取引処理ノード212は、取引受領者の第2口座を支払口座として決定し、取引受領者の第2口座から取引手数料を差し引き得る。一方、取引処理ノード212が、取引受領者の第2口座残高が取引手数料未満であると判定した場合、取引処理ノード212は、取引提案者の第1口座残高が取引手数料以上であるかどうかを判定し得る。取引処理ノード212が、取引提案者の第1口座残高が取引手数料以上であると判定した場合、取引処理ノード212は、取引提案者の第1口座を支払口座として決定し、取引提案者の第1口座から取引手数料を差し引き得る。
【0047】
前述の解決策では、取引提案者が取引受領者の保証付き利用者であるという判定に基づいて、取引手数料が差し引かれる支払口座を取引処理ノード212が決定することによって、ブロックチェーン取引手数料が、優先順に従って支払口座から支払われ得る(例えば、支払口座は、保証人口座、取引受領者の第2口座および取引提案者の第1口座のいずれか1つであり得る。)。このようにして、通常の利用者は、自分の暗号通貨を使用/管理して取引手数料を支払うことに特別な注意を払わずに、ブロックチェーンサービスを便利に使用することができる。
【0048】
いくつかの実施形態では、方法300は、取引手数料を差し引いた後、取引提案者から取引受領者に暗号通貨の送金額を送金するための送金取引を取引内容が示すということを取引処理ノード212が判定した場合に、取引提案者の第3口座残高が送金額以上であるかどうかを取引処理ノード212がさらに判定し得ることをさらに含み得る。取引処理ノード212は、取引提案者の第3口座残高が送金額以上であると判定した場合、取引提案者の第3口座から取引受領者の第4口座に暗号通貨の送金額を送金する。
【0049】
いくつかの実施形態では、取引手数料および送金額は、異なる種類の暗号通貨に対応し得る。例えば、取引提案者の第1口座および取引受領者の第2口座は、取引手数料用の第1種暗号通貨に対応し得て、取引提案者の第3口座および取引受領者の第4口座は送金額用の第2種暗号通貨に対応し得て、第1種は第2種とは異なる。この場合、取引処理ノード212は、取引提案者の第3口座から取引受領者の第4口座に、暗号通貨の送金額を送金し得る。言い換えれば、取引手数料は第1種暗号通貨で支払われると共に受け取られ、そのうえ、送金予定暗号通貨は、第1種とは異なる第2種である。
【0050】
いくつかの他の実施形態では、取引手数料および送金額は、同じ種類の暗号通貨に対応し得る。この場合、取引提案者の第1口座および第3口座は同一であり得て、取引受領者の第2口座および第4口座は同一であり得る。取引処理ノード212は、取引提案者の第1口座(すなわち、第3口座)から取引受領者の第2口座(すなわち、第4口座)に暗号通貨の送金額を送金し得る。
【0051】
上述のように、取引手数料を支払うための多層支払モデルを説明する。例えば、3層支払モデルでは、保証人口座、取引受領者の口座または取引提案者の口座のいずれか1つによって、取引手数料を支払うことができる。このようにして、通常の利用者は、ブロックチェーン取引の取引手数料の支払いについて特別な注意を払うことなく、現在の通常アプリケーションのようにブロックチェーンサービスを利用することができる。
【0052】
図4は、本開示の実施形態によるブロックチェーン取引を管理するための方法400のフローチャートを示す。図4において、種々の処理は、例えば、図2に示される管理装置214のプロセッサによって実行される。方法400はまた、図示されていない追加の処理を含み得て、および/または、図示される処理を省略し得て、本開示の範囲はこの点で限定されない。
【0053】
ブロック402において、管理装置214は、取引提案者から要求を受信し得る。要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示し得る。いくつかの実施形態では、要求は、端末装置(例えば、携帯電話)242を介して、取引提案者から管理装置214(すなわち、取引受領者)に送信される。
【0054】
図5は、本開示の一実施形態による管理装置214によって受信される要求500を示す。図5では、要求500は、とりわけ取引内容を少なくとも含む。通常、要求500は、図5に示されるように、取引提案者の署名情報をさらに含む。取引提案者の署名情報は、取引提案者の端末装置が取引提案者の秘密鍵で取引内容に署名することによって生成される。要求500内における取引提案者の署名情報は管理装置214または取引処理ノード212によって使用され、取引提案者の識別性が認証され得る。特に図示されていないが、要求500は取引提案者および取引受領者をさらに示し得る。
【0055】
ブロック404において、管理装置214は、管理装置214に格納される取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。いくつかの実施形態では、管理装置214および/または利用者の端末装置の初期化工程中に、管理装置214は、保証付き利用者と取引受領者(すなわち、管理装置214)との保証人関係を、生成し得るかそうでなければ取得し得る。さらに、管理装置214は、保証付き利用者毎にクレジット案を設定し得る。
【0056】
いくつかの実施形態では、取引提案者と取引受領者との保証人関係は、保証付き利用者と取引受領者との対応関係を示す。いくつかの実施形態では、保証人関係は、各保証付き利用者のクレジット情報をさらに示す。例えば、クレジット情報は、各保証付き利用者のクレジット案を含み得る。
【0057】
下記の表1~3は、本開示の実施形態による保証人関係を示す。以下の表1は、受領者と保証付き利用者との対応関係を示す。例えば、利用者1は受領者1の保証付き利用者であり、利用者2は受領者2の保証付き利用者であり、利用者3は受領者3の保証付き利用者である。いくつかの実施形態では、表1における受領者および保証人利用者は、それらのアドレスによって示される。それらのアドレスは、ブロックチェーンアドレス、財布アドレスと呼ばれ得るか、アカウントまたはスマートコントラクトアカウントと呼ばれることもあり得る。例えば、管理装置214(例えば、企業のサーバ)が複数のブロックチェーンアプリケーションの複数のスマートコントラクトを提供する場合、各スマートコントラクトアドレスは、対応するスマートコントラクトに向けられる取引要求の取引受領者として作用し得る。この場合、管理装置214は、表1に示されるように対応関係を含む保証人関係を維持し得る。表1では、1の受領者が1の保証付き利用者に対応することが示されている。しかし、ほとんどの実際の実施形態では、1の受領者が複数の保証付き利用者に対応し得る。
【表1】
【0058】
下記の表2は、受領者と保証人口座との対応関係を示す。対応関係は、受領者が、対応する保証人口座に関連付けられて受領者の取引手数料が支払われることを示す。例えば、保証人口座1は受領者1に対する取引手数料の保証人支払いを支持し得て、保証人口座2は受領者2に対する取引手数料の保証人支払いを支持し得て、保証人口座3は、受領者3に対する取引手数料の保証人支払いを支持し得る。これは、企業が複数の分散型アプリケーション(DApps)を開発して支援する状況において特に適用可能である。この場合、企業の管理装置214は、DAppsに対する複数のスマートコントラクトそれぞれを提供して管理すべきであり、各スマートコントラクトは、ブロックチェーン取引の受領者として作用し得る。同様に、実際の実施形態では、表2における受領者および保証人口座はそれらのアドレスによって示される。表2では、1の受領者が1の保証人口座に対応することが示されている。しかし、本開示はこれに限定されず、1の保証人口座は複数の受領者に対応し得る。例えば、管理装置214(例えば、企業のサーバ)は、複数のブロックチェーンアプリケーションに対する複数のスマートコントラクトを提供する場合、スマートコントラクトの全てまたは一部に対する1の保証人口座のみを設定し得る。
【表2】
【0059】
下記の表3は、保証付き利用者と保証付き利用者のクレジット情報との対応関係を示す。例えば、表3に示されるように、利用者1はクレジット情報1を有し、利用者2はクレジット情報2を有し、利用者3はクレジット情報3を有する。クレジット情報はクレジット案を含み得て、クレジット案は全ての保証付き利用者について同一にまたは別々に構成され得る。クレジット情報は、例えば、上記式(1)に従って取引提案者のクレジット残高を判定するためのクレジット限度および利用済みクレジットを少なくとも含み得る。この場合、表3はブロックごとに動的に更新され得る。いくつかのさらなる実施形態では、クレジット情報は、例えば、上記式(2)に従って取引提案者のクレジット残高を決定するためのクレジット復元率およびブロック高をさらに含み得る。
【表3】
【0060】
保証人関係は、ブロックチェーンプラットフォーム210上で管理装置214によってブロックとして公開され得る。このため、保証人関係により、取引処理ノード212は、アクセスして取引を処理することが可能になる。管理装置214はまた、保証人関係をローカルに記憶し得る。
【0061】
再び上記の表2を参照すると、表2は、複数の受領者と複数の保証人口座との関係を示している。表内の各受領者は、実質的に受領者のアドレスによって示される。受領者のアドレスは、受領者の性質に応じて、スマートコントラクトアドレスまたは通常のブロックチェーンアドレス(非スマートコントラクトアドレス)であり得る。企業が、異なる機能の複数のDAppsを支援し、企業の管理装置214がDAppsの複数のスマートコントラクトを提供する場合、企業がスマートコントラクトアドレスまたは非スマートコントラクトアドレスそれぞれの保証人口座を構成するように、親口座が構成され得る。例えば、管理装置またはスマートコントラクトの初期化工程中に、親口座は、管理装置214によって使用され、各受領者の保証人口座を決定するか、管理装置214において提供される全部または一部の受領者の保証人口座を決定し得る。このようにして、スマート口座を使用することによって、企業は、単一の親口座でさえ使用し、それにより支援されるすべてのスマートコントラクトを管理し得る。
【0062】
いくつかの実施形態では、受領者が通常のブロックチェーンアドレス(すなわち、非スマートコントラクトアドレス)である場合、受領者の親口座は、受領者自体の口座、または、企業によって指定された別の口座であり得る。
【0063】
いくつかの他の実施形態では、受領者がスマートコントラクトアドレスである場合、受領者の親口座は、初期設定ではスマートコントラクトのデプロイヤの口座であり得る。さらに、デプロイヤは、この権利を別の口座に移転し得る。
【0064】
ブロック406において、提案者が取引受領者の保証付き利用者であると管理装置214が判定した場合、管理装置214は、受信した要求に取引受領者の署名情報を生成して追加することによって、取引要求を形成する。署名情報は、ブロックチェーン取引を処理するブロックチェーンノードに対する取引手数料が受領者によって支払われることが許可されることを示す。いくつかの実施形態では、署名情報は、取引受領者の秘密鍵で取引内容に署名する管理装置214によって生成される。この場合、取引処理ノード212は、受信した取引要求が取引受領者の署名を含むかどうかを判定し、ブロックチェーンプラットフォーム210から保証人関係を引き出す代わりに取引提案者が取引受領者の保証付き利用者であるかどうかを判定するだけである。
【0065】
図6は、本開示の一実施形態による、取引受領者の署名情報を伴う取引要求600を示す。図6において、取引要求600は、要求500に含まれるものに加えて、取引受領者の署名情報をさらに含む。
【0066】
いくつかの実施形態では、管理装置214は、取引提案者が取引受領者の保証付き利用者であると判定した後、管理装置214で記録された取引提案者のクレジット情報に基づいて、取引提案者のクレジット残高が取引手数料以上であるかどうかをさらに判定し得る。この場合、取引提案者のクレジット残高が取引手数料以上であると管理装置214が判定した場合にのみ、管理装置214は、署名情報を生成して、受信した要求に署名情報を追加し、取引要求を形成する。
【0067】
上述のように、管理装置214が保証人関係をローカルに記憶する実施形態では、管理装置214は、取引提案者の取引手数料を支払うべきかどうかを決定し、取引手数料を支払うと決定した場合に署名を追加し得る。図6に示されるような取引要求を受信した後、取引処理ノード212は、取引受領者の公開鍵を用いて、受信した取引要求を復号すると共に、受領者の署名情報を取得し得る。取引受領者の署名情報に基づいて、取引処理ノード212は、受信した取引が受領者によって支払われることが取引受領者によって確認されたことをさらに判定し得る。この場合、取引受領者の署名情報に基づいて、取引処理ノード212は、受信した取引が保証人支払いを伴う取引であることを直接判定し、取引提案者が取引受領者の保証付き利用者であるかどうかについてさらなる判定を行う必要がなくなり得る。
【0068】
図7は、本開示の実施形態によるブロックチェーン取引を処理するための方法700のフローチャートを示す。図7では、処理が、取引処理ノード212-1、212-2~212-Nのいずれかによって実施され得る。方法700は、図示されていない追加の処理をさらに含み、および/または、図示される処理を省略し得て、本開示の範囲はこの点で限定されないことを理解されたい。
【0069】
ブロック702において、取引処理ノード212は取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示し得る。ブロック704において、取引処理ノード212は、取引提案者の識別性を認証し得る。ブロック704における取引提案者の識別性の認証が成功している場合、ブロック706において、取引処理ノード212は、取引要求に示される取引内容に基づいて、取引を処理するための取引手数料を計算し得る。
【0070】
ブロック708において、取引処理ノード212は、取引要求が取引受領者の署名情報を示すかどうかを判定し得る。ブロック708において、取引提案者が取引受領者の保証付き利用者であることを意味する取引受領者の署名情報を取引要求が示すと判定される場合(Yes)、方法700はブロック712に進む。一方、ブロック708において、取引要求が取引受領者の署名情報を示さないと判定される場合(No)、ブロック710において、取引処理ノード212は、取引処理ノード212に記憶された、または、ブロックチェーンプラットフォーム210に記録された保証付き利用者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかをさらに判定し得る。
【0071】
ブロック710において、取引提案者が取引受領者の保証付き利用者でないと判定される場合(No)、取引が本発明の保証人支払モデルに適用可能でないことが意味され、方法700は、ブロック722に進み、従来の方法、すなわち取引提案者が取引手数料の支払いを試みる方法で取引の処理を継続する。一方、ブロック708またはブロック710において、取引提案者が取引受領者の保証付き利用者であると判定される場合(Yes)、方法700は、本開示の保証人支払モデルの適用に進む。この場合、ブロック712において、取引処理ノード212は、取引受領者に関連付けられた保証人口座があるかどうかを判定し得る。
【0072】
ブロック712において、取引受領者に関連付けられた保証人口座があると判定される場合(Yes)、方法700はブロック714に進み、取引処理ノード212は、保証人口座残高が取引手数料以上であるかどうかを判定し得る。ブロック714において、保証人口座残高が取引手数料以上であると判定される場合(Yes)、ブロック716において、取引処理ノード212は、保証人口座から取引手数料を差し引き得る。
【0073】
一方、ブロック712において、取引受領者に関連付けられた保証人口座がないと判定される場合(No)、または、ブロック714において、保証人口座残高が取引手数料よりも少ないと判定される場合、受領者自身の口座から取引手数料を支払うことを試みる方法が進行され得る。この場合、ブロック718において、取引処理ノード212は、取引受領者の第2口座残高が取引手数料以上であるかどうかを判定し得る。ブロック718において、取引受領者の第2口座残高が取引手数料以上であると判定される場合(Yes)、ブロック720において、取引処理ノード212は、取引受領者の第2口座から取引手数料を差し引き得る。
【0074】
一方、ブロック718において、取引受領者の第2口座残高が取引手数料よりも少ないと判定される場合(No)、方法700は、従来の方法、すなわち取引提案者が取引手数料の支払いを試みる方法に進み得る。この場合、ブロック722において、取引処理ノード212は、取引提案者の第1口座残高が取引手数料以上であるかどうかを判定し得る。ブロック722において、取引提案者の第1口座残高が取引手数料以上であると判定される場合(Yes)、ブロック724において、取引処理ノード212は、取引提案者の第1口座から取引手数料を差し引き得る。
【0075】
ここまで、取引手数料の支払いについて説明した。以下では、取引処理ノード212は、従来の方法で取引内容に従って取引を処理し得る。取引がブロックチェーン上で新しいスマートコントラクトを展開すること、暗号通貨の額を受領者に送金すること、ブロックチェーン上で展開されたスマートコントラクトを呼び出すこと、または、それらの任意の組合せであることを取引内容は示し得る。しかしながら、本開示はそれに限定されず、取引内容は、開発済みまたは将来開発予定の任意の他の種類のブロックチェーン取引を示し得る。以下では、送金取引を例として、方法700の追加の処理を説明する。
【0076】
ブロック716、720または724における取引手数料の支払い後、取引内容が送金取引を示して取引提案者から取引受領者に暗号通貨の送金額が送金されると取引処理ノード212が判定する場合、ブロック728において、取引処理ノード212は、取引提案者の第3口座残高が送金額以上であるかどうかを判定し得る。ブロック728において、取引提案者の第3口座残高が送金額以上であると判定される場合(Yes)、ブロック730において、取引処理ノード212は、取引提案者の第3口座から取引受領者の第4口座に暗号通貨の送金額を送金し得る。
【0077】
一方、ブロック722において、取引提案者の第1口座残高が取引手数料より少ないと判定された場合(No)、または、ブロック728において、取引提案者の第3口座残高が送金額より少ないと判定される場合(NO)、ブロック726において、取引処理が失敗したと判定される。すなわち、いずれも口座残高が取引手数料または送金額に対して不足していると、取引全体が失敗することになる。さらに、図7は、取引が失敗したことを示す単一のブロックを示すが、取引失敗の様々な原因を示す追加のブロックを含み得る。
【0078】
なお、上述の説明では、取引手数料および送金額が、異なる種類の暗号通貨であると仮定される。この場合、取引提案者は、取引手数料および送金口座それぞれのために、2つの異なる種類の暗号通貨を有する2つの口座(すなわち、第1口座および第3口座)を有する。同様に、取引受領者もまた、取引手数料および送金口座それぞれのために、2つの異なる種類の暗号通貨を有する2つの口座(すなわち、第2口座および第4口座)を有する。
【0079】
上記から、取引提案者が取引手数料および送金額の両方に対して十分な暗号通貨額を有する必要がある従来の取引管理体系とは異なり、本明細書で説明される実施形態では、取引受領者に関連付けられた保証人口座、または、取引受領者の第2口座などの受領者によって取引手数料が支払われ得ることが分かる。このようにして、通常の利用者は、特別な注意を払って異なる暗号通貨を管理して取引手数料や送金額を支払うことなく、ブロックチェーンサービスを便利に使用することができる。
【0080】
しかし、本開示はそれに限定されない。システムおよび方法は、1つの種類の暗号通貨のみが含まれる概要に適用され得る。したがって、取引手数料および送金額の両方が同じ種類の暗号通貨になる。この場合、取引提案者および取引受領者はそれぞれ、同じ種類の暗号通貨を有する1つの口座のみを有し得る。したがって、ブロック728において、取引提案者の第3口座残高が送金額以上であるかどうかを判定する代わりに、取引提案者の第1口座残高(取引手数料が、ブロック716において保証人口座によって、または、ブロック720において受領者の口座によって支払われる場合)、または、取引提案者の更新後第1口座残高(取引手数料が、提案者の口座によって支払われる場合)が送金額以上であると判定される。したがって、ブロック730において、送金額は、取引提案者の第1口座から取引受領者の第2口座に送金される。
【0081】
提案者が受領者の保証付き利用者であるかどうかの判定に関して、方法700では、2つの工程による判定、すなわちブロック708および710が説明される。しかし、当業者は、ブロック708またはブロック710のみによって判定が行われ得ることを理解すべきである。すなわち、受領者の署名を確認するだけか、保証人関係に基づいて独立した判定を行うか、その両方であるかは、ブロックチェーン構成全体の高度な戦略であり得る。
【0082】
いくつかの実施形態では、支払モデルは、上述の第3層モデル(例えば、ブロック716、ブロック720およびブロック724)に限定されず、2層モデルであってもよい。例えば、取引処理ノード212は、支払口座を決定して以下の順序の1つに従って取引手数料を差し引き得る。その順序は、取引受領者に関連付けられた保証人口座および取引受領者の第2口座(ブロック716およびブロック720)、取引受領者の第2口座および取引提案者の第1口座(ブロック720およびブロック724)、または、保証人口座および取引提案者の第1口座(ブロック716およびブロック724)である。図7の流れを適宜修正することは可能である。
【0083】
図8は、本明細書で説明される主題の実施形態を実施するように適合された電子装置800のブロック図を示す。装置800が使用され、図2に示されるシステム200の1つ以上のホスト(例えば、図2に示される取引処理のための管理装置214、ノード212-1、212-2~212-N)が実装され得る。図8に示されるように、装置800は中央処理装置(CPU)801を備える。CPU801は、読出し専用メモリ(ROM)802に記憶されたコンピュータプログラム命令、または、記憶装置808からランダムアクセスメモリ(RAM)803にロードされたコンピュータプログラム命令に従って、様々な動作および工程を実行することができる。RAM 803には、装置800の動作に必要な各種プログラムやデータが記憶される。CPU 801、ROM 802およびRAM 803は、バス804を介して互いに接続される。入出力(I/O) インターフェース805もまた、バス804に接続される。
【0084】
装置800の以下の構成要素はI/Oインターフェース805に接続される。構成要素は、キーボード、マウス等を含む入力装置806、各種ディスプレイ、スピーカー等を含む出力装置807、ディスク、光ディスク等の記憶装置808、ネットワークカード、モデム、無線通信送受信機等の通信装置809である。通信装置809により、インターネットおよび/または様々な電気通信ネットワークのようなコンピュータネットワークを介して、装置800は、他の装置と情報/データを交換することができる。
【0085】
処理装置801は、上述した様々な方法及び処理、例えば、方法300、400および700を実行する。例えば、いくつかの実施形態では、方法300、400および700は、コンピュータソフトウェアプログラムとして実施され得る。コンピュータソフトウェアプログラムは、機械可読媒体、例えば、記憶装置808に記憶される。いくつかの実施形態では、一部または全体のコンピュータプログラムは、ROM 802および/または通信装置809を介して、装置800にロードおよび/またはインストールされ得る。コンピュータプログラムがRAM 803にロードされてCPU 801によって実行されると、上述した方法300、400および700の1つ以上の動作が実行され得る。あるいは、他の実施形態では、CPU 801は、任意の他の適切な方法(例えば、ファームウェアの利点によって)で構成され、方法300、400および700の1つ以上の動作を実行し得る。
【0086】
本開示は方法、装置、システムおよび/またはコンピュータプログラム製品であり得ることをさらに理解されたい。コンピュータプログラム製品はコンピュータ可読記憶媒体を含み得る。コンピュータ可読記憶媒体は、プロセッサに本開示の局面を実行させるためのコンピュータ可読プログラム命令を有する。
【0087】
コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持して記憶することができる有形装置であってもよい。コンピュータ可読記憶媒体は、例えば、電子記憶装置、磁気記憶装置、光記憶装置、電磁記憶装置、半導体記憶装置またはこれらの任意の適切な組合せであり得るが、これらに限定されない。完全に網羅されているわけではないが、コンピュータ可読記憶媒体のより具体的な例からなる一覧には、携帯用コンピュータディスケット、ハードディスク、ランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)、消去可能プログラマブル読出し専用メモリ(EPROMまたはフラッシュメモリ)、静的ランダムアクセスメモリ(SRAM)、携帯用コンパクトディスク読出し専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)、メモリスティック、フロッピーディスク、パンチカードまたは記録された命令を有する溝内の隆起構造等の機械的に符号化された装置、および、これらの任意の適切な組み合わせが含まれる。本明細書で使用されるコンピュータ可読記憶媒体は、電波または他の自由に伝播する電磁波、導波管または他の伝送媒体(例えば、光ファイバケーブルを通過する光パルス)を通って伝播する電磁波、または、ワイヤを通って伝送される電気信号などの一時的な信号自体であると解釈されるべきではない。
【0088】
コンピュータ可読記憶媒体からそれぞれの演算/処理装置に、または、ネットワーク、例えばインターネット、ローカルエリアネットワーク、ワイドエリアネットワークおよび/または無線ネットワークを介して外部コンピュータまたは外部記憶装置に、本明細書で説明されるコンピュータ可読プログラム命令をダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータおよび/またはエッジサーバを備え得る。各演算/処理装置におけるネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を転送して演算/処理装置それぞれのコンピュータ可読記憶媒体に記憶する。
【0089】
本開示の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ(ISA)命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、1つ以上のプログラミング言語の任意の組み合わせで書かれたソースコードまたはオブジェクトコードのいずれかであり得る。プログラミング言語は、Java、Smalltalk、C++などのオブジェクト指向プログラミング言語、および、「C」プログラミング言語または類似のプログラミング言語などの従来の手続き型プログラミング言語を含む。コンピュータ可読プログラム命令は、利用者のコンピュータ上で全体的に、スタンドアロンのソフトウェアパッケージとして利用者のコンピュータ上で部分的に、利用者のコンピュータ上で部分的に、および、リモートのコンピュータ上で部分的にまたはリモートのコンピュータまたはサーバ上で全体的に実行し得る。後者の概要では、リモートコンピュータは、ローカルエリアネットワーク(LAN)またはワイドエリアネットワーク(WAN)を含む任意の種類のネットワークを介して、利用者のコンピュータに接続されるか、外部コンピュータ(例えば、インターネットサービスプロバイダを使用してインターネットを介して)に接続され得る。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールドプログラマブルゲートアレイ(FPGA)またはプログラマブル論理アレイ(PLA)を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行して電子回路を個人化し、本開示の局面を実行し得る。
【0090】
本開示の局面は、本開示の実施形態による方法、装置(システム)およびコンピュータプログラム製品のフローチャート図および/またはブロック図を参照して本明細書で説明される。フローチャート図および/またはブロック図の各ブロック、および、フローチャート図および/またはブロック図のブロックの組合せをコンピュータ可読プログラム命令が実施できることを理解されたい。
【0091】
これらのコンピュータ可読プログラム命令は、汎用コンピュータ、専用コンピュータ、または、他のプログラマブルデータ処理装置のプロセッサに提供され得る。プロセッサは、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行する命令がフローチャート図および/またはブロック図の1つ以上のブロックで指定された機能/動作を実施するための手段を作成するように、機械を生成する。これらのコンピュータ可読プログラム命令はまた、コンピュータ、プログラマブルデータ処理装置および/または他の装置に命令をして特定の方法で機能させるコンピュータ可読記憶媒体に記憶され得る。その結果、その中に記憶された命令を有するコンピュータ可読記憶媒体は、フローチャートおよび/またはブロック図の1つ以上のブロックで指定された機能/動作の局面を実施する命令を含む製造品を備える。
【0092】
コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブルデータ処理装置または他の装置上にロードされ、コンピュータ、他のプログラマブル装置または他の装置上で実行される一連の動作ステップを引き起こしてコンピュータ実施工程を生成し得る。その結果、コンピュータ、他のプログラマブル装置または他の装置上で実行される命令は、フローチャートおよび/またはブロック図の1つ以上のブロックで指定された機能/動作を実施する。
【0093】
図中のフローチャートおよびブロック図は、本開示の様々な実施形態による、システム、方法およびコンピュータプログラム製品の可能な実施形態である体系、機能および動作を示す。この点に関して、フローチャートまたはブロック図の各ブロックは、指定された論理機能を実施するための1つ以上の実行可能命令を備えるモジュール、セグメント、または、コードの一部を表し得る。また、いくつかの代替的な実施形態では、ブロックに示される機能が図に記載されている順序の乱れが起き得ることを留意されたい。例えば、連続して示される2つのブロックは、実際には実質的に同時に実行され得る。または、それらのブロックは、含まれる機能次第で逆順序で時々実行され得る。ブロック図および/またはフローチャート図の各ブロック、および、ブロック図および/またはフローチャート図におけるブロックの組み合わせは、指定された機能または動作を実行する専用ハードウェアベースのシステム、または、専用ハードウェアおよびコンピュータ命令の組み合わせによって実施され得ることにも留意されたい。
【0094】
本開示の様々な実施形態の記述は、例示の目的で提示されてきたが、網羅的であること、または、開示された実施形態に限定されることを意図していない。記載された実施形態の範囲および精神から逸脱しなければ、多くの修正および変形は当業者にとって明らかであろう。本明細書で使用される用語が選択されたことで、実施形態の原理、実際の運用、または、市場で見出される技術に対する技術的改善が最もよく説明されるか、当業者が本明細書で開示される実施形態を理解することができる。
【0095】
記載されているものは、本開示の好ましい実施形態にすぎず、本開示を限定することを意図していない。当業者は、本開示に対して様々な修正および変形が適用され得ることを理解する。本開示の精神および原理内における任意の修正、均等物の置換および改善は、すべて本開示の保護範囲内にある。
図1
図2
図3
図4
図5
図6
図7
図8