JP2021521545A - ブロックチェーン取引処理 - Google Patents

Abstract

【課題】本開示の実施形態は、ブロックチェーン取引を処理または管理するための方法、装置、コンピュータ可読記憶媒体およびコンピュータプログラム製品に関する。【解決手段】ブロックチェーン取引を処理するための方法において、ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードは取引要求を受信する。取引要求は、取引提案者、取引内容および取引受領者を少なくとも示す。ブロックチェーンノードは、取引内容に基づいて、取引を処理するための取引手数料を計算する。ブロックチェーンノードは、取引提案者が取引受領者の保証付き利用者であるかどうかを判定すると共に、取引提案者が取引受領者の保証付き利用者であるという判定に応じて、取引手数料が差し引かれる支払口座を決定する。本開示で提供される取引処理および管理体系により、通常の利用者はブロックチェーンサービスを便利に使用することができる。【選択図】図３

Description

本開示の実施形態は一般に、ブロックチェーン上の取引処理の分野に関し、より詳細には、ブロックチェーン取引処理またはブロックチェーン取引管理に関する。

従来のブロックチェーン取引処理体系では、個人または企業は、ブロックチェーンサービスを使用し、暗号通貨を送金したい場合またはスマートコントラクトを呼び出して実行したい場合には必ず、ネットワークに取引を送信し、自分自身の口座残高を用いることでブロックチェーン取引を処理するために必要な取引手数料を支払わなければならない。

いくつかのブロックチェーンアプリケーションでは、取引提案者は通常の利用者であり得る。利用者は、暗号通貨を市場から入手するとき、高い価格変動率に直面することになる。したがって、従来の取引管理体系は、通常の利用者がブロックチェーン取引を処理するための取引手数料を支払うのに便利ではない。さらに、送金取引の場合、暗号通貨額を取引提案者から取引受領者に送金する必要がある。ブロックチェーン取引手数料および送金額は、異なる種類の暗号通貨であり得る。このことは、「利用者が、少なくとも２種類の暗号通貨を有すると共に様々な種類のツールに精通して利用者の暗号通貨を管理し、取引手数料および送金額に対して口座残高が十分であることを保証しなければならない。」ことを必要とする。したがって、従来の取引処理体系では、通常の利用者がブロックチェーンアプリケーションを使用するのに多くの負担がかかる。

一般に、本開示の例示的な実施形態は、ブロックチェーン取引を処理または管理するための解決策を提供する。これにより、通常の利用者はブロックチェーンサービスを便利に利用し得る。

本開示の第１局面によれば、ブロックチェーン取引を処理するための方法が提供される。前記方法は、前記ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードにおいて、取引要求を受信することを含む。前記取引要求は、前記取引の取引提案者と取引内容と取引受領者とを少なくとも示す。前記方法は、前記取引内容に基づいて、前記取引を処理するための取引手数料を計算することと、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することと、前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引手数料が差し引かれる支払口座を決定することとをさらに含む。

本開示の第２局面によれば、ブロックチェーン取引を管理するための方法が提供される。前記方法は、前記ブロックチェーン取引を管理するための管理装置において、前記取引の取引提案者から要求を受信することを含む。前記要求は、前記取引の前記取引提案者と取引内容と取引受領者とを少なくとも示す。前記方法は、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することと、前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引受領者の署名情報を生成すると共に受信した前記要求に前記取引受領者の署名情報を追加することによって、取引要求を形成することとをさらに含む。前記署名情報は、前記ブロックチェーン取引を処理するブロックチェーンのブロックチェーンノードに対する取引手数料を前記取引受領者に関連付けられた支払口座から差し引くことができることを示す。

本開示の第３局面によれば、ブロックチェーン取引を処理するための装置が提供される。前記装置は、メモリと処理部とを含む。前記メモリは、１以上のプログラムを格納するように構成される。前記処理部は、前記メモリに結合され、前記１以上のプログラムを実行して本開示の第１の局面に係る方法の過程を前記装置に実行させるように構成される。

本開示の第４局面によれば、ブロックチェーン取引を管理するための装置が提供される。前記装置は、メモリと処理部とを含む。前記メモリは、１以上のプログラムを格納するように構成される。前記処理部は、前記メモリに結合され、前記１以上のプログラムを実行して本開示の第２の局面に係る方法の過程を前記装置に実行させるように構成される。

本開示の第５局面によれば、機械実行可能命令が格納される非一時的コンピュータ可読記憶媒体が提供される。前記機械実行可能命令は、実行されると、本開示の第１局面および第２局面のいずれか１局面に係る方法の過程を機械に実行させる。

本開示の第６局面によれば、コンピュータプログラム製品が提供される。前記コンピュータプログラム製品は、非一時的コンピュータ可読媒体に有形に格納され、機械実行可能命令を備える。前記機械実行可能命令は、実行されると、本開示の第１局面および第２局面のいずれか１局面に係る方法の過程を機械に実行させる。

本概要は本開示の実施形態の要所または本質的な特徴を識別することを意図するものではなく、また、本概要は本開示の範囲を限定するように利用されることを意図するものでもないことを理解されたい。本開示の他の特徴は、以下の説明を通して容易に理解されるであろう。

上記記載、および、本開示の他の目的、特徴および利点は、図面を参照して本開示の例示的な実施形態をより詳細に説明することで、より明らかにされるであろう。なお、同一の参照符号は、本開示の例示的な実施形態における同一の部分を表す。
従来技術における取引処理方法のフローチャートを示す。 本開示の実施形態による取引処理システムの体系図を示す。 本開示の実施形態によるブロックチェーン取引を処理するための方法のフローチャートを示す。 本開示の実施形態によるブロックチェーン取引を管理するための方法のフローチャートを示す。 本開示の一実施形態による管理装置によって受信される要求を示す。 本開示の一実施形態による取引受領者の署名情報を伴う取引要求を示す。 本開示の実施形態によるブロックチェーン取引を処理するための方法のフローチャートを示す。 本開示の実施形態を実施するのに適した例示的な装置のブロック図を概略的に示す。

なお、各図において、同一の符号または対応する符号は、同一の構成要素または対応する構成要素を示す。

いくつかの例示的な実施形態を参照して本開示の原理を説明する。これらの実施形態は、開示の範囲に関していかなる限定を示唆するものではなく、説明目的のためにのみ記載されており、当業者が本開示を理解して実施するための助けになることが、理解されるであろう。本明細書で説明される開示は、下記方法以外の様々な方法で実施され得る。

以下の説明および特許請求の範囲では、別段の定義がない限り、本明細書で使用されるすべての技術用語および専門用語は、当業者によって一般に理解される意味と同意である。

本開示における「一実施形態」、「実施形態」、「例示的な実施形態」などへの言及は、記載された実施形態が特定の特徴、構造または性質を含み得ることを示す。しかし、すべての実施形態が特定の特徴、構造または性質を含む必要はない。さらに、そのような文言は、必ずしも同じ実施形態を参照しているわけではない。さらに、特定の特徴、構造または性質が実施形態に関連して記載されている場合、明示的に記載されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造または性質に影響を及ぼすことは当業者の知識の範囲内であることが提示される。

「第１」、「第２」、「第３」および「第４」などの用語が本明細書で使用されて様々な要素が説明され得るが、これらの要素はこれらの用語によって限定されるべきではないことを理解されたい。これらの用語は、１つの要素を他の要素から区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱しなければ、第１要素を第２要素と呼ぶことができ、同様に、第２要素を第１要素と呼ぶことができる。例えば、以下の説明では、第１、第２、第３および第４口座は、口座の数または順序を限定する意味ではなく、異なる主体の異なる口座を区別することのみを意味する。本明細書で使用されるように、「および／または」という用語は、列挙される１以上の用語の任意の組合せおよびすべての組合せを含む。

本明細書で使用される用語は、特定の実施形態を説明するためだけのものであり、例示的な実施形態を限定することを意味するものではない。本明細書で使用されるように、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈に別段の明示がない限り、複数形も含むことを意味するものである。「ｃｏｍｐｒｉｓｅｓ」、「ｃｏｍｐｒｉｓｉｎｇ」、「ｈａｓ」、「ｈａｖｉｎｇ」、「ｉｎｃｌｕｄｅｓ」および／または「ｉｎｃｌｕｄｉｎｇ」という用語は、本明細書で使用される場合、述べられた特徴、要素および／または構成要素などの存在を明示するが、１以上の他の特徴、要素、構成要素および／またはそれらの組合せの存在または追加を排除するものではないことがさらに理解されるであろう。

図１は、従来技術における取引管理方法１００のフローチャートを示す。図１に示されるように、ブロック１０２において、ブロックチェーンの取引処理ノードは取引要求を受信する。例えば、取引要求は、取引提案者から取引受領者に暗号通貨額を送金するための送金取引を示す。ブロック１０４において、取引処理ノードは、取引提案者の識別性を認証する。ブロック１０６において、取引処理ノードは、取引を処理するための取引手数料を計算する。ブロック１０８において、取引処理ノードは、取引提案者の口座残高が、計算された取引手数料以上であるかどうかを判定する。ブロック１０８における判定結果がＮｏである場合、方法１００はブロック１１６に進み、取引処理が失敗したと判定される。ブロック１０８における判定結果がＹｅｓである場合、すなわち、取引提案者の口座残高が、計算された取引手数料以上である場合、ブロック１１０において、取引処理ノードは、取引提案者の口座から取引手数料を差し引く。次に、取引提案者から取引受領者に暗号通貨額を送金するための送金取引を取引要求が示す場合、ブロック１１２において、取引処理ノードは、取引提案者の更新後口座残高が送金予定額以上であるかどうかを判定する。ブロック１１２における判定結果がＹｅｓである場合、ブロック１１４において、取引処理ノードは、取引提案者の口座から取引受領者の口座に暗号通貨額を送金する。ブロック１１２における判定結果がＮｏである場合、すなわち、取引提案者の更新後口座残高が送金予定額未満である場合、方法１００はブロック１１６に進み、取引処理が失敗したと判定される。

上述のように、従来の取引処理体系では、取引を処理するための取引手数料を取引提案者だけが支払うことができる。提案者の口座残高が必要取引手数料未満であるか送金予定額未満である場合、取引処理は失敗する。さらに、多くのブロックチェーンシステムでは、ブロックチェーン取引手数料および送金予定額が、異なる種類の暗号通貨であり得る。この場合、取引提案者は、少なくとも２種類の暗号通貨を有すると共にそれらの暗号通貨を管理するための少なくとも２種類のツールに精通し、それらの口座残高が取引手数料および送金予定額に対して十分であることを保証することを必要とする。したがって、従来の取引処理体系では、通常の利用者に多くの負担がかかる。

上記の問題および他の潜在的問題の１つ以上を少なくとも部分的に対処するために、本開示の例示的な実施形態は、取引処理解決策を提案する。本解決策では、ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードが取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示す。ブロックチェーンノードは、取引を処理するための取引手数料を取引内容に基づいて計算し、取引提案者が取引受領者の保証付き利用者であるかどうかを判定する。取引提案者が取引受領者の保証付き利用者であるという判定に応じて、ブロックチェーンノードは、取引手数料が差し引かれる支払口座を決定する。本開示で提供される取引処理解決策により、通常の利用者はブロックチェーンサービスを便利に使用することができる。

取引提案者だけがブロックチェーン取引手数料を支払うことができる従来の取引処理体系とは異なり、上記の解決策では、取引提案者が取引受領者の保証付き利用者であるということを判定することによって、取引処理ノードは、取引手数料が差し引かれる支払口座を決定し得る。ブロックチェーン取引手数料は、決定された支払口座（例えば、保証人口座、取引受領者口座または取引提案者口座のいずれか１つ）から支払われ得る。このようにして、通常の利用者は、特別な注意を払うことなく自分の暗号通貨を使用／管理して取引手数料を支払い、現在の通常アプリのようにブロックチェーンサービスを利用し得る。したがって、本開示が提供されることにより、通常の利用者がブロックチェーンサービスをより便利に使用し、複数の異なるブロックチェーンサービスを有する企業がこれらのサービスをより便利に管理することができる。本開示は、より多くの利用者がブロックチェーンサービスを使用することを促進する。

図２は、本開示の実施形態による取引処理システム２００の体系図を示す。図２に示されるように、システム２００は、管理装置２１４と、ブロックチェーン取引を処理するための複数のノード２１２−１，２１２−２〜２１２−Ｎ（すなわち、取引処理ノード２１２）と、複数の端末装置（例えば、携帯電話２４２、コンピュータ２４０および２４４）とを備える。管理装置２１４および取引処理ノード２１２はすべて、ブロックチェーンプラットフォーム２１０のブロックチェーンノードとなり得る。管理装置２１４、取引処理ノード２１２および端末装置は、ネットワーク２３０を介してデータの相互作用を実行し得る。

ブロックチェーンノードの数および端末装置の数はいかなる限定を示唆するものではなくて例示目的のためだけのものであることを理解されたい。システム２００は、本開示の実施形態を実施するのに適した任意の適切な数のブロックチェーンノードおよび端末装置を含み得る。

端末装置は任意の終端装置を含み得る。終端装置は、携帯電話（a mobile phone）、携帯電話(a cellular phone)、スマートフォン、ボイスオーバーＩＰ(VoIP)電話、無線ローカルループ電話、タブレット、携帯情報端末(PDA)、携帯型コンピュータ、デスクトップコンピュータなどを含み得るが、これらに限定されるものではない。利用者２５０または２５２は、対応する端末装置２４０または２４２を介して取引を開始し得て、端末装置は、管理装置２１４の受領者アドレスに関連するサービス用に、対応する取引要求を管理装置２１４に送信し得る。いくつかの実施形態では、財布アプリケーションを端末装置上で実行することができる。利用者２５０または２５２は、財布アプリケーションを介して管理装置２１４に登録し、関連アカウントＩＤを取得し得る。関連アカウントＩＤは、管理装置２１４において利用者を一意に識別する。関連アカウントＩＤは、例えば、利用者の識別子（メールボックスまたは携帯電話番号など）と、管理装置２１４または管理装置２１４の管理者の識別子との組み合わせであり得るが、これに限定されない。さらに、利用者２５０または２５２は、財布アプリケーションを介して自身のアドレスを生成し、自身のブロックチェーン取引の提案者アドレスまたは受領者アドレスとして作用し得る。いくつかの実施形態において、端末装置は、利用者の秘密鍵で取引要求に署名することによって、取引要求についての署名情報を生成し得る。利用者は、取引手数料の支払いを保証する専用の取引受領者のスマートコントラクトに登録することによって、取引受領者の保証付き利用者になり得る。

管理装置２１４は、ブロックチェーンプラットフォーム２１０のノードとして作用するためのネットワーク装置であり得る。管理装置２１４は、１以上のコンピュータまたはサーバを含み得るが、これらに限定されない。管理装置２１４は、各端末装置を介して利用者２５０および２５２から取引要求を受信し得る。管理装置２１４は、利用者２５０および２５２のアドレスを介して利用者２５０および２５２にブロックチェーンサービスを提供し得る。例えば、利用者２５２は、取引受領者の保証付き利用者であると想定される。ここで、取引受領者の保証付き利用者は、取引受領者の受領者アドレスに登録され、取引受領者による保証人支払いのスマートコントラクトに署名している。言い換えれば、取引受領者の保証付き利用者は、取引受領者の登録済み利用者として取引受領者（例えば、管理装置２１４）に登録されるだけでなく、取引受領者に対して利用者が開始した取引についての取引手数料の支払いを保証する専用の取引受領者のスマートコントラクトにも明確に登録される。また、利用者２５０は取引受領者の単なる通常の登録済み利用者であるが受領者の保証付き利用者ではないと想定される。管理装置２１４は、管理装置２１４の初期化工程中に、保証人口座と取引受領者とを関連付け得る。さらに、いくつかの実施形態では、管理装置２１４はまた、保証付き利用者ごとにクレジット情報を決定し得る。いくつかの実施形態では、管理装置２１４は、受信した要求の取引提案者が取引受領者の保証付き利用者であることを判定し得て、その後、取引受領者の秘密鍵で取引要求に署名することによって署名情報を生成して受信した要求に追加し、取引要求を形成し得る。管理装置２１４はさらに、ブロックチェーンプラットフォーム２１０上に署名情報付き取引要求を送信し得るか、取引処理ノード２１２のいずれかまたはすべてに署名情報付き取引要求を送信し得る。この場合、管理装置２１４は、取引受領者の署名情報を用いて、この取引に対する取引手数料が取引受領者によって支払われ得ることを、取引を処理するための取引処理ノード２１２に対して示し得る。

ここで、管理装置２１４、取引受領者、受領者アドレス、および、取引受領者の口座は、いくつかの実施形態では交換可能に使用され、現在の取引が向けられるブロックチェーン主体を示し得る。

ブロックチェーンプラットフォーム２１０に関しては、ブロックチェーン取引を処理すると共に取引結果データを蓄積するために使用される。ブロックチェーンプラットフォーム２１０は、構造的には、例えば、基本サービス層、スマートコントラクト層およびブロックチェーン最下層を上から下に備える（図示せず）。ブロックチェーンプラットフォーム２１０は、管理装置２１４および取引処理ノード２１２を備え得る。さらに、ブロックチェーンプラットフォーム２１０は、端末装置２４０，２４２および２４４のいずれかまたはすべてがブロックチェーンノードとして作用し得る場合、それらをさらに含み得る。いくつかの実施形態では、ブロックチェーンプラットフォーム２１０は、プライベート型ブロックチェーン、パブリック型ブロックチェーンまたはフェデレーテッド型ブロックチェーンを基にすることができる。

取引処理ノード２１２は、ブロックチェーンプラットフォーム２１０のノードとして作用するためのネットワーク装置であり得る。取引処理のための取引処理ノード２１２（すなわち、取引処理ノード２１２）は、１以上のコンピュータまたはサーバを含み得るが、これらに限定されない。取引処理ノード２１２は、管理装置２１４から取引要求を受信し、受信した取引要求に基づいて、取引を処理するための取引手数料を計算することが可能であり得る。取引処理ノード２１２は、取引提案者が取引受領者の保証付き利用者であると判定すると、支払口座を決定し、計算された取引手数料を支払口座から差し引き得る。いくつかの実施形態では、取引処理ノード２１２は、受信した取引要求に示される取引受領者の署名情報に基づいて、または、取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。後者の場合、保証人関係は、ブロックチェーンプラットフォーム２１０または取引処理ノード２１２に格納され得る。前者の場合、同様の保証人関係が管理装置２１４の管理装置２１４に格納され、取引提案者が取引受領者の保証付き利用者であるかどうかが判定され得る。

いくつかの実施形態では、取引提案者が取引受領者の保証付き利用者であると取引処理ノード２１２が判定した場合、本開示の３層支払モデルは、取引手数料が差し引かれる支払口座を決定するために使用される。以下、図３〜図７を参照して、３層支払モデルについて詳述する。

一方、取引提案者が取引受領者の保証付き利用者ではないと取引処理ノード２１２が判定した場合、取引提案者の第１口座残高が取引手数料以上であるかどうかが判定され得る。提案者の第１口座残高が取引手数料以上である場合、取引処理ノード２１２は、取引提案者の第１口座を支払口座として決定し、取引提案者の第１口座から取引手数料を差し引き得る。

図３は、本開示の実施形態によるブロックチェーン取引を処理するための方法３００のフローチャートを示す。図３では、例えば、図２に示されるような取引処理ノード２１２のプロセッサによって、様々な処理が実行される。方法３００はまた、図示されていない追加の処理を含み得て、および／または、図示された処理を省略し得て、本開示の範囲はこの点で限定されない。

ブロック３０２において、取引処理ノード２１２は取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示す。取引処理ノード２１２は、図２に示されるように管理装置２１４から取引要求を受信し得る。いくつかの実施形態では、取引要求は、取引提案者の署名情報および／または取引受領者の署名情報をさらに示す。いくつかの実施形態では、取引受領者は、業務運営システムであって、業務運営システムは、特定のスマートコントラクトに基づいて、受領者の保証付き利用者または受領者の通常の登録済み利用者に１以上のサービスを提供する。

ブロック３０４において、取引処理ノード２１２は、取引内容に基づいて、取引を処理するための取引手数料を計算する。例えば、取引が、ブロックチェーンプラットフォーム上に新しいスマートコントラクトを展開すること、展開されたスマートコントラクトを呼び出すこと、または、取引提案者から取引受領者に暗号通貨送金額を送金することであることを、取引内容は示し得る。いくつかの実施形態では、取引手数料および送金額は、異なる種類の暗号通貨であり得る。いくつかの他の実施形態では、取引手数料および送金額は共に同じ種類の暗号通貨である。

ブロック３０６において、取引処理ノード２１２は、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。

いくつかの実施形態では、取引処理ノード２１２は、受信した取引要求によって示される取引受領者の署名情報に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。この場合、取引要求を取引処理ノード２１２に送信する前に、管理装置２１４は、例えば、管理装置２１４に格納された取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者（すなわち、管理装置２１４）の保証付き利用者であるかどうかを判定し得る。取引提案者が取引受領者の保証付き利用者であるという判定に応じて、管理装置２１４は、取引提案者の対応する端末装置から受信した要求に署名をさらに加え得る。署名は、管理装置２１４が管理装置２１４の秘密鍵を用いて取引内容に署名することによって生成され得る。このようにして、取引処理ノード２１２は単に、受信した取引要求が、管理装置２１４の署名を含むかどうかを調べ、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。

代替的に又は追加的に、取引処理ノード２１２は、取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。保証人関係は、ブロックチェーンプラットフォーム２１０のノードの一部または全てに記録される。この場合、保証人関係は、あらかじめブロックチェーンプラットフォーム２１０上でブロックとして公開されている。また、取引処理ノード２１２は、ブロックチェーンプラットフォーム２１０上に記録された保証人関係（以下の表１に示されるように）に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。

いくつかのさらなる実施形態では、取引提案者が取引受領者の保証付き提供利用者であると管理装置２１４が判定した後、管理装置２１４は、取引提案者のクレジット残高が取引手数料以上であるかどうかをさらに判定し得る。この判定は、管理装置２１４に格納される保証付き利用者専用のクレジット情報（以下の表３にクレジット案として示されるように）を参照して行われ得る。保証付き利用者のクレジット情報は、管理装置２１４の管理人又は管理装置２１４の他の監督人によって、あらかじめ設定され得る。取引提案者のクレジット残高が取引手数料以上である場合にのみ、取引受領者の署名情報が生成されて取引要求に加えられる。このようにして、取引処理ノード２１２は、取引要求内に管理装置２１４の署名情報が存在していることを単に確認することによって、取引提案者が取引受領者の保証付き利用者であると共に取引提案者のクレジット残高が十分であると判定し得る。

図３に戻ると、ブロックチェーンプラットフォーム２１０に記録される保証人関係に基づいて取引提案者が取引受領者の保証付き利用者であるかどうかを取引処理ノード２１２が判定する実施形態では、取引提案者が取引受領者の保証付き利用者であるという判定に応じて、方法３００は、取引提案者のクレジット残高が取引手数料（図示せず）以上であるかどうかを取引処理ノード２１２が判定することをさらに含み得る。判定は、ブロックチェーンプラットフォーム２１０のノードの一部またはすべてに格納される保証付き利用者専用のクレジット情報（以下の表３にクレジット案として示されるように）を参照して行われ得る。保証付き利用者のクレジット情報は、管理装置２１４の管理人または管理装置２１４の他の監督人によってあらかじめ設定され得て、ブロックチェーンプラットフォーム２１０上でブロックとして公開され得る。

上述したクレジット情報は、取引受領者が保証付き利用者の取引手数料を支払う金額の上限であるクレジット限度を少なくとも示す。いくつかの実施形態では、管理装置２１４またはブロックチェーンプラットフォーム２１０に格納されるクレジット情報は利用済みクレジットをさらに含み得る。利用済みクレジットは、取引受領者が保証付き利用者の取引手数料に対して支払った金額を示す。この場合、クレジット残高は、クレジット限度および利用済みクレジットに基づいて決定され得る。例えば、クレジット残高は、以下の式（１）によって決定され得る。
クレジット残高＝クレジット限度−利用済みクレジット ・・・（１）

いくつかの実施形態ではクレジット限度および利用済みクレジットに加えて、クレジット情報は、クレジット復元率およびブロック高をさらに含み得る。クレジット復元率は、通過する各ブロックによって保証付き利用者が復元するクレジット額を示し、ブロック高は、取引受領者が取引提案者（保証付き利用者）の取引手数料を支払った前回から通過したブロック数を示す。各ブロックによって復元されるクレジット額はクレジット限度を超えることはできないことは明らかである。この場合、クレジット残高は、以下の式（２）で決定され得る。
クレジット残高＝クレジット限度−利用済みクレジット＋ブロック高×クレジット復元率 ・・・（２）

あるいは、クレジット案は、保証付き利用者に対する取引受領者による保証人支払いの回数形式であり得る。この場合、クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し得る。クレジット支払回数限度は、取引受領者が保証付き利用者の取引手数料を支払う回数の上限であり得て、利用済みクレジット支払回数は、取引受領者が保証付き利用者の取引手数料を支払った回数を示し得る。この場合、クレジット残高は、以下の（３）式によって決定され得る。
クレジット残高＝クレジット支払回数限度−利用済みクレジット支払回数 ・・・（３）

ブロック３０８において、取引処理ノード２１２は、取引提案者が取引受領者の保証付き利用者である（および、いくつかのさらなる実施形態では、クレジット残高が取引手数料に対して十分である）と判定すると、取引手数料が差し引かれる支払口座をさらに決定する。

いくつかの実施形態では、支払口座は３層モデルによって決定され得る。これを用いると、取引手数料が、保証人口座、取引受領者、取引提案者の順に従って差し引かれ得る。

いくつかの実施形態では、取引処理ノード２１２は、取引受領者に関連付けられた保証人口座があるかどうかを判定し得る。取引処理ノード２１２が取引受領者に関連付けられた保証人口座があると判定した場合、取引処理ノード２１２は、保証人口座残高が取引手数料以上であるかどうかをさらに判定し得る。保証人口座残高が取引手数料以上であると判定された場合、取引処理ノード２１２は、保証人口座を支払口座として決定し、保証人口座から取引手数料を差し引き得る。一方、取引処理ノード２１２が、取引受領者に関連付けられた保証人口座がないと判定した場合、または、保証人口座残高が取引手数料未満であると判定した場合、取引処理ノード２１２は、取引受領者の第２口座残高が取引手数料以上であるかどうかを判定し得る。

取引処理ノード２１２が、取引受領者の第２口座残高が取引手数料以上であると判定した場合、取引処理ノード２１２は、取引受領者の第２口座を支払口座として決定し、取引受領者の第２口座から取引手数料を差し引き得る。一方、取引処理ノード２１２が、取引受領者の第２口座残高が取引手数料未満であると判定した場合、取引処理ノード２１２は、取引提案者の第１口座残高が取引手数料以上であるかどうかを判定し得る。取引処理ノード２１２が、取引提案者の第１口座残高が取引手数料以上であると判定した場合、取引処理ノード２１２は、取引提案者の第１口座を支払口座として決定し、取引提案者の第１口座から取引手数料を差し引き得る。

前述の解決策では、取引提案者が取引受領者の保証付き利用者であるという判定に基づいて、取引手数料が差し引かれる支払口座を取引処理ノード２１２が決定することによって、ブロックチェーン取引手数料が、優先順に従って支払口座から支払われ得る（例えば、支払口座は、保証人口座、取引受領者の第２口座および取引提案者の第１口座のいずれか１つであり得る。）。このようにして、通常の利用者は、自分の暗号通貨を使用／管理して取引手数料を支払うことに特別な注意を払わずに、ブロックチェーンサービスを便利に使用することができる。

いくつかの実施形態では、方法３００は、取引手数料を差し引いた後、取引提案者から取引受領者に暗号通貨の送金額を送金するための送金取引を取引内容が示すということを取引処理ノード２１２が判定した場合に、取引提案者の第３口座残高が送金額以上であるかどうかを取引処理ノード２１２がさらに判定し得ることをさらに含み得る。取引処理ノード２１２は、取引提案者の第３口座残高が送金額以上であると判定した場合、取引提案者の第３口座から取引受領者の第４口座に暗号通貨の送金額を送金する。

いくつかの実施形態では、取引手数料および送金額は、異なる種類の暗号通貨に対応し得る。例えば、取引提案者の第１口座および取引受領者の第２口座は、取引手数料用の第１種暗号通貨に対応し得て、取引提案者の第３口座および取引受領者の第４口座は送金額用の第２種暗号通貨に対応し得て、第１種は第２種とは異なる。この場合、取引処理ノード２１２は、取引提案者の第３口座から取引受領者の第４口座に、暗号通貨の送金額を送金し得る。言い換えれば、取引手数料は第１種暗号通貨で支払われると共に受け取られ、そのうえ、送金予定暗号通貨は、第１種とは異なる第２種である。

いくつかの他の実施形態では、取引手数料および送金額は、同じ種類の暗号通貨に対応し得る。この場合、取引提案者の第１口座および第３口座は同一であり得て、取引受領者の第２口座および第４口座は同一であり得る。取引処理ノード２１２は、取引提案者の第１口座（すなわち、第３口座）から取引受領者の第２口座（すなわち、第４口座）に暗号通貨の送金額を送金し得る。

上述のように、取引手数料を支払うための多層支払モデルを説明する。例えば、３層支払モデルでは、保証人口座、取引受領者の口座または取引提案者の口座のいずれか１つによって、取引手数料を支払うことができる。このようにして、通常の利用者は、ブロックチェーン取引の取引手数料の支払いについて特別な注意を払うことなく、現在の通常アプリケーションのようにブロックチェーンサービスを利用することができる。

図４は、本開示の実施形態によるブロックチェーン取引を管理するための方法４００のフローチャートを示す。図４において、種々の処理は、例えば、図２に示される管理装置２１４のプロセッサによって実行される。方法４００はまた、図示されていない追加の処理を含み得て、および／または、図示される処理を省略し得て、本開示の範囲はこの点で限定されない。

ブロック４０２において、管理装置２１４は、取引提案者から要求を受信し得る。要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示し得る。いくつかの実施形態では、要求は、端末装置（例えば、携帯電話）２４２を介して、取引提案者から管理装置２１４（すなわち、取引受領者）に送信される。

図５は、本開示の一実施形態による管理装置２１４によって受信される要求５００を示す。図５では、要求５００は、とりわけ取引内容を少なくとも含む。通常、要求５００は、図５に示されるように、取引提案者の署名情報をさらに含む。取引提案者の署名情報は、取引提案者の端末装置が取引提案者の秘密鍵で取引内容に署名することによって生成される。要求５００内における取引提案者の署名情報は管理装置２１４または取引処理ノード２１２によって使用され、取引提案者の識別性が認証され得る。特に図示されていないが、要求５００は取引提案者および取引受領者をさらに示し得る。

ブロック４０４において、管理装置２１４は、管理装置２１４に格納される取引提案者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかを判定し得る。いくつかの実施形態では、管理装置２１４および／または利用者の端末装置の初期化工程中に、管理装置２１４は、保証付き利用者と取引受領者（すなわち、管理装置２１４）との保証人関係を、生成し得るかそうでなければ取得し得る。さらに、管理装置２１４は、保証付き利用者毎にクレジット案を設定し得る。

いくつかの実施形態では、取引提案者と取引受領者との保証人関係は、保証付き利用者と取引受領者との対応関係を示す。いくつかの実施形態では、保証人関係は、各保証付き利用者のクレジット情報をさらに示す。例えば、クレジット情報は、各保証付き利用者のクレジット案を含み得る。

下記の表１〜３は、本開示の実施形態による保証人関係を示す。以下の表１は、受領者と保証付き利用者との対応関係を示す。例えば、利用者１は受領者１の保証付き利用者であり、利用者２は受領者２の保証付き利用者であり、利用者３は受領者３の保証付き利用者である。いくつかの実施形態では、表１における受領者および保証人利用者は、それらのアドレスによって示される。それらのアドレスは、ブロックチェーンアドレス、財布アドレスと呼ばれ得るか、アカウントまたはスマートコントラクトアカウントと呼ばれることもあり得る。例えば、管理装置２１４（例えば、企業のサーバ）が複数のブロックチェーンアプリケーションの複数のスマートコントラクトを提供する場合、各スマートコントラクトアドレスは、対応するスマートコントラクトに向けられる取引要求の取引受領者として作用し得る。この場合、管理装置２１４は、表１に示されるように対応関係を含む保証人関係を維持し得る。表１では、１の受領者が１の保証付き利用者に対応することが示されている。しかし、ほとんどの実際の実施形態では、１の受領者が複数の保証付き利用者に対応し得る。

下記の表２は、受領者と保証人口座との対応関係を示す。対応関係は、受領者が、対応する保証人口座に関連付けられて受領者の取引手数料が支払われることを示す。例えば、保証人口座１は受領者１に対する取引手数料の保証人支払いを支持し得て、保証人口座２は受領者２に対する取引手数料の保証人支払いを支持し得て、保証人口座３は、受領者３に対する取引手数料の保証人支払いを支持し得る。これは、企業が複数の分散型アプリケーション(DApps)を開発して支援する状況において特に適用可能である。この場合、企業の管理装置２１４は、DAppsに対する複数のスマートコントラクトそれぞれを提供して管理すべきであり、各スマートコントラクトは、ブロックチェーン取引の受領者として作用し得る。同様に、実際の実施形態では、表２における受領者および保証人口座はそれらのアドレスによって示される。表２では、１の受領者が１の保証人口座に対応することが示されている。しかし、本開示はこれに限定されず、１の保証人口座は複数の受領者に対応し得る。例えば、管理装置２１４（例えば、企業のサーバ）は、複数のブロックチェーンアプリケーションに対する複数のスマートコントラクトを提供する場合、スマートコントラクトの全てまたは一部に対する１の保証人口座のみを設定し得る。

下記の表３は、保証付き利用者と保証付き利用者のクレジット情報との対応関係を示す。例えば、表３に示されるように、利用者１はクレジット情報１を有し、利用者２はクレジット情報２を有し、利用者３はクレジット情報３を有する。クレジット情報はクレジット案を含み得て、クレジット案は全ての保証付き利用者について同一にまたは別々に構成され得る。クレジット情報は、例えば、上記式（１）に従って取引提案者のクレジット残高を判定するためのクレジット限度および利用済みクレジットを少なくとも含み得る。この場合、表３はブロックごとに動的に更新され得る。いくつかのさらなる実施形態では、クレジット情報は、例えば、上記式（２）に従って取引提案者のクレジット残高を決定するためのクレジット復元率およびブロック高をさらに含み得る。

保証人関係は、ブロックチェーンプラットフォーム２１０上で管理装置２１４によってブロックとして公開され得る。このため、保証人関係により、取引処理ノード２１２は、アクセスして取引を処理することが可能になる。管理装置２１４はまた、保証人関係をローカルに記憶し得る。

再び上記の表２を参照すると、表２は、複数の受領者と複数の保証人口座との関係を示している。表内の各受領者は、実質的に受領者のアドレスによって示される。受領者のアドレスは、受領者の性質に応じて、スマートコントラクトアドレスまたは通常のブロックチェーンアドレス（非スマートコントラクトアドレス）であり得る。企業が、異なる機能の複数のDAppsを支援し、企業の管理装置２１４がDAppsの複数のスマートコントラクトを提供する場合、企業がスマートコントラクトアドレスまたは非スマートコントラクトアドレスそれぞれの保証人口座を構成するように、親口座が構成され得る。例えば、管理装置またはスマートコントラクトの初期化工程中に、親口座は、管理装置２１４によって使用され、各受領者の保証人口座を決定するか、管理装置２１４において提供される全部または一部の受領者の保証人口座を決定し得る。このようにして、スマート口座を使用することによって、企業は、単一の親口座でさえ使用し、それにより支援されるすべてのスマートコントラクトを管理し得る。

いくつかの実施形態では、受領者が通常のブロックチェーンアドレス（すなわち、非スマートコントラクトアドレス）である場合、受領者の親口座は、受領者自体の口座、または、企業によって指定された別の口座であり得る。

いくつかの他の実施形態では、受領者がスマートコントラクトアドレスである場合、受領者の親口座は、初期設定ではスマートコントラクトのデプロイヤの口座であり得る。さらに、デプロイヤは、この権利を別の口座に移転し得る。

ブロック４０６において、提案者が取引受領者の保証付き利用者であると管理装置２１４が判定した場合、管理装置２１４は、受信した要求に取引受領者の署名情報を生成して追加することによって、取引要求を形成する。署名情報は、ブロックチェーン取引を処理するブロックチェーンノードに対する取引手数料が受領者によって支払われることが許可されることを示す。いくつかの実施形態では、署名情報は、取引受領者の秘密鍵で取引内容に署名する管理装置２１４によって生成される。この場合、取引処理ノード２１２は、受信した取引要求が取引受領者の署名を含むかどうかを判定し、ブロックチェーンプラットフォーム２１０から保証人関係を引き出す代わりに取引提案者が取引受領者の保証付き利用者であるかどうかを判定するだけである。

図６は、本開示の一実施形態による、取引受領者の署名情報を伴う取引要求６００を示す。図６において、取引要求６００は、要求５００に含まれるものに加えて、取引受領者の署名情報をさらに含む。

いくつかの実施形態では、管理装置２１４は、取引提案者が取引受領者の保証付き利用者であると判定した後、管理装置２１４で記録された取引提案者のクレジット情報に基づいて、取引提案者のクレジット残高が取引手数料以上であるかどうかをさらに判定し得る。この場合、取引提案者のクレジット残高が取引手数料以上であると管理装置２１４が判定した場合にのみ、管理装置２１４は、署名情報を生成して、受信した要求に署名情報を追加し、取引要求を形成する。

上述のように、管理装置２１４が保証人関係をローカルに記憶する実施形態では、管理装置２１４は、取引提案者の取引手数料を支払うべきかどうかを決定し、取引手数料を支払うと決定した場合に署名を追加し得る。図６に示されるような取引要求を受信した後、取引処理ノード２１２は、取引受領者の公開鍵を用いて、受信した取引要求を復号すると共に、受領者の署名情報を取得し得る。取引受領者の署名情報に基づいて、取引処理ノード２１２は、受信した取引が受領者によって支払われることが取引受領者によって確認されたことをさらに判定し得る。この場合、取引受領者の署名情報に基づいて、取引処理ノード２１２は、受信した取引が保証人支払いを伴う取引であることを直接判定し、取引提案者が取引受領者の保証付き利用者であるかどうかについてさらなる判定を行う必要がなくなり得る。

図７は、本開示の実施形態によるブロックチェーン取引を処理するための方法７００のフローチャートを示す。図７では、処理が、取引処理ノード２１２−１、２１２−２〜２１２−Ｎのいずれかによって実施され得る。方法７００は、図示されていない追加の処理をさらに含み、および／または、図示される処理を省略し得て、本開示の範囲はこの点で限定されないことを理解されたい。

ブロック７０２において、取引処理ノード２１２は取引要求を受信する。取引要求は、取引の取引提案者、取引内容および取引受領者を少なくとも示し得る。ブロック７０４において、取引処理ノード２１２は、取引提案者の識別性を認証し得る。ブロック７０４における取引提案者の識別性の認証が成功している場合、ブロック７０６において、取引処理ノード２１２は、取引要求に示される取引内容に基づいて、取引を処理するための取引手数料を計算し得る。

ブロック７０８において、取引処理ノード２１２は、取引要求が取引受領者の署名情報を示すかどうかを判定し得る。ブロック７０８において、取引提案者が取引受領者の保証付き利用者であることを意味する取引受領者の署名情報を取引要求が示すと判定される場合（Ｙｅｓ）、方法７００はブロック７１２に進む。一方、ブロック７０８において、取引要求が取引受領者の署名情報を示さないと判定される場合（Ｎｏ）、ブロック７１０において、取引処理ノード２１２は、取引処理ノード２１２に記憶された、または、ブロックチェーンプラットフォーム２１０に記録された保証付き利用者と取引受領者との保証人関係に基づいて、取引提案者が取引受領者の保証付き利用者であるかどうかをさらに判定し得る。

ブロック７１０において、取引提案者が取引受領者の保証付き利用者でないと判定される場合（Ｎｏ）、取引が本発明の保証人支払モデルに適用可能でないことが意味され、方法７００は、ブロック７２２に進み、従来の方法、すなわち取引提案者が取引手数料の支払いを試みる方法で取引の処理を継続する。一方、ブロック７０８またはブロック７１０において、取引提案者が取引受領者の保証付き利用者であると判定される場合（Ｙｅｓ）、方法７００は、本開示の保証人支払モデルの適用に進む。この場合、ブロック７１２において、取引処理ノード２１２は、取引受領者に関連付けられた保証人口座があるかどうかを判定し得る。

ブロック７１２において、取引受領者に関連付けられた保証人口座があると判定される場合（Ｙｅｓ）、方法７００はブロック７１４に進み、取引処理ノード２１２は、保証人口座残高が取引手数料以上であるかどうかを判定し得る。ブロック７１４において、保証人口座残高が取引手数料以上であると判定される場合（Ｙｅｓ）、ブロック７１６において、取引処理ノード２１２は、保証人口座から取引手数料を差し引き得る。

一方、ブロック７１２において、取引受領者に関連付けられた保証人口座がないと判定される場合（Ｎｏ）、または、ブロック７１４において、保証人口座残高が取引手数料よりも少ないと判定される場合、受領者自身の口座から取引手数料を支払うことを試みる方法が進行され得る。この場合、ブロック７１８において、取引処理ノード２１２は、取引受領者の第２口座残高が取引手数料以上であるかどうかを判定し得る。ブロック７１８において、取引受領者の第２口座残高が取引手数料以上であると判定される場合（Ｙｅｓ）、ブロック７２０において、取引処理ノード２１２は、取引受領者の第２口座から取引手数料を差し引き得る。

一方、ブロック７１８において、取引受領者の第２口座残高が取引手数料よりも少ないと判定される場合（Ｎｏ）、方法７００は、従来の方法、すなわち取引提案者が取引手数料の支払いを試みる方法に進み得る。この場合、ブロック７２２において、取引処理ノード２１２は、取引提案者の第１口座残高が取引手数料以上であるかどうかを判定し得る。ブロック７２２において、取引提案者の第１口座残高が取引手数料以上であると判定される場合（Ｙｅｓ）、ブロック７２４において、取引処理ノード２１２は、取引提案者の第１口座から取引手数料を差し引き得る。

ここまで、取引手数料の支払いについて説明した。以下では、取引処理ノード２１２は、従来の方法で取引内容に従って取引を処理し得る。取引がブロックチェーン上で新しいスマートコントラクトを展開すること、暗号通貨の額を受領者に送金すること、ブロックチェーン上で展開されたスマートコントラクトを呼び出すこと、または、それらの任意の組合せであることを取引内容は示し得る。しかしながら、本開示はそれに限定されず、取引内容は、開発済みまたは将来開発予定の任意の他の種類のブロックチェーン取引を示し得る。以下では、送金取引を例として、方法７００の追加の処理を説明する。

ブロック７１６、７２０または７２４における取引手数料の支払い後、取引内容が送金取引を示して取引提案者から取引受領者に暗号通貨の送金額が送金されると取引処理ノード２１２が判定する場合、ブロック７２８において、取引処理ノード２１２は、取引提案者の第３口座残高が送金額以上であるかどうかを判定し得る。ブロック７２８において、取引提案者の第３口座残高が送金額以上であると判定される場合（Ｙｅｓ）、ブロック７３０において、取引処理ノード２１２は、取引提案者の第３口座から取引受領者の第４口座に暗号通貨の送金額を送金し得る。

一方、ブロック７２２において、取引提案者の第１口座残高が取引手数料より少ないと判定された場合（Ｎｏ）、または、ブロック７２８において、取引提案者の第３口座残高が送金額より少ないと判定される場合（ＮＯ）、ブロック７２６において、取引処理が失敗したと判定される。すなわち、いずれも口座残高が取引手数料または送金額に対して不足していると、取引全体が失敗することになる。さらに、図７は、取引が失敗したことを示す単一のブロックを示すが、取引失敗の様々な原因を示す追加のブロックを含み得る。

なお、上述の説明では、取引手数料および送金額が、異なる種類の暗号通貨であると仮定される。この場合、取引提案者は、取引手数料および送金口座それぞれのために、２つの異なる種類の暗号通貨を有する２つの口座（すなわち、第１口座および第３口座）を有する。同様に、取引受領者もまた、取引手数料および送金口座それぞれのために、２つの異なる種類の暗号通貨を有する２つの口座（すなわち、第２口座および第４口座）を有する。

上記から、取引提案者が取引手数料および送金額の両方に対して十分な暗号通貨額を有する必要がある従来の取引管理体系とは異なり、本明細書で説明される実施形態では、取引受領者に関連付けられた保証人口座、または、取引受領者の第２口座などの受領者によって取引手数料が支払われ得ることが分かる。このようにして、通常の利用者は、特別な注意を払って異なる暗号通貨を管理して取引手数料や送金額を支払うことなく、ブロックチェーンサービスを便利に使用することができる。

しかし、本開示はそれに限定されない。システムおよび方法は、１つの種類の暗号通貨のみが含まれる概要に適用され得る。したがって、取引手数料および送金額の両方が同じ種類の暗号通貨になる。この場合、取引提案者および取引受領者はそれぞれ、同じ種類の暗号通貨を有する１つの口座のみを有し得る。したがって、ブロック７２８において、取引提案者の第３口座残高が送金額以上であるかどうかを判定する代わりに、取引提案者の第１口座残高（取引手数料が、ブロック７１６において保証人口座によって、または、ブロック７２０において受領者の口座によって支払われる場合）、または、取引提案者の更新後第１口座残高（取引手数料が、提案者の口座によって支払われる場合）が送金額以上であると判定される。したがって、ブロック７３０において、送金額は、取引提案者の第１口座から取引受領者の第２口座に送金される。

提案者が受領者の保証付き利用者であるかどうかの判定に関して、方法７００では、２つの工程による判定、すなわちブロック７０８および７１０が説明される。しかし、当業者は、ブロック７０８またはブロック７１０のみによって判定が行われ得ることを理解すべきである。すなわち、受領者の署名を確認するだけか、保証人関係に基づいて独立した判定を行うか、その両方であるかは、ブロックチェーン構成全体の高度な戦略であり得る。

いくつかの実施形態では、支払モデルは、上述の第３層モデル（例えば、ブロック７１６、ブロック７２０およびブロック７２４）に限定されず、２層モデルであってもよい。例えば、取引処理ノード２１２は、支払口座を決定して以下の順序の１つに従って取引手数料を差し引き得る。その順序は、取引受領者に関連付けられた保証人口座および取引受領者の第２口座（ブロック７１６およびブロック７２０）、取引受領者の第２口座および取引提案者の第１口座（ブロック７２０およびブロック７２４）、または、保証人口座および取引提案者の第１口座（ブロック７１６およびブロック７２４）である。図７の流れを適宜修正することは可能である。

図８は、本明細書で説明される主題の実施形態を実施するように適合された電子装置８００のブロック図を示す。装置８００が使用され、図２に示されるシステム２００の１つ以上のホスト（例えば、図２に示される取引処理のための管理装置２１４、ノード２１２−１、２１２−２〜２１２−Ｎ）が実装され得る。図８に示されるように、装置８００は中央処理装置（ＣＰＵ）８０１を備える。ＣＰＵ８０１は、読出し専用メモリ（ＲＯＭ）８０２に記憶されたコンピュータプログラム命令、または、記憶装置８０８からランダムアクセスメモリ（ＲＡＭ）８０３にロードされたコンピュータプログラム命令に従って、様々な動作および工程を実行することができる。ＲＡＭ ８０３には、装置８００の動作に必要な各種プログラムやデータが記憶される。ＣＰＵ ８０１、ＲＯＭ ８０２およびＲＡＭ ８０３は、バス８０４を介して互いに接続される。入出力（Ｉ／Ｏ） インターフェース８０５もまた、バス８０４に接続される。

装置８００の以下の構成要素はＩ／Ｏインターフェース８０５に接続される。構成要素は、キーボード、マウス等を含む入力装置８０６、各種ディスプレイ、スピーカー等を含む出力装置８０７、ディスク、光ディスク等の記憶装置８０８、ネットワークカード、モデム、無線通信送受信機等の通信装置８０９である。通信装置８０９により、インターネットおよび／または様々な電気通信ネットワークのようなコンピュータネットワークを介して、装置８００は、他の装置と情報／データを交換することができる。

処理装置８０１は、上述した様々な方法及び処理、例えば、方法３００、４００および７００を実行する。例えば、いくつかの実施形態では、方法３００、４００および７００は、コンピュータソフトウェアプログラムとして実施され得る。コンピュータソフトウェアプログラムは、機械可読媒体、例えば、記憶装置８０８に記憶される。いくつかの実施形態では、一部または全体のコンピュータプログラムは、ＲＯＭ ８０２および／または通信装置８０９を介して、装置８００にロードおよび／またはインストールされ得る。コンピュータプログラムがＲＡＭ ８０３にロードされてＣＰＵ ８０１によって実行されると、上述した方法３００、４００および７００の１つ以上の動作が実行され得る。あるいは、他の実施形態では、ＣＰＵ ８０１は、任意の他の適切な方法（例えば、ファームウェアの利点によって）で構成され、方法３００、４００および７００の１つ以上の動作を実行し得る。

本開示は方法、装置、システムおよび／またはコンピュータプログラム製品であり得ることをさらに理解されたい。コンピュータプログラム製品はコンピュータ可読記憶媒体を含み得る。コンピュータ可読記憶媒体は、プロセッサに本開示の局面を実行させるためのコンピュータ可読プログラム命令を有する。

コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持して記憶することができる有形装置であってもよい。コンピュータ可読記憶媒体は、例えば、電子記憶装置、磁気記憶装置、光記憶装置、電磁記憶装置、半導体記憶装置またはこれらの任意の適切な組合せであり得るが、これらに限定されない。完全に網羅されているわけではないが、コンピュータ可読記憶媒体のより具体的な例からなる一覧には、携帯用コンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、携帯用コンパクトディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリスティック、フロッピーディスク、パンチカードまたは記録された命令を有する溝内の隆起構造等の機械的に符号化された装置、および、これらの任意の適切な組み合わせが含まれる。本明細書で使用されるコンピュータ可読記憶媒体は、電波または他の自由に伝播する電磁波、導波管または他の伝送媒体（例えば、光ファイバケーブルを通過する光パルス）を通って伝播する電磁波、または、ワイヤを通って伝送される電気信号などの一時的な信号自体であると解釈されるべきではない。

コンピュータ可読記憶媒体からそれぞれの演算／処理装置に、または、ネットワーク、例えばインターネット、ローカルエリアネットワーク、ワイドエリアネットワークおよび／または無線ネットワークを介して外部コンピュータまたは外部記憶装置に、本明細書で説明されるコンピュータ可読プログラム命令をダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータおよび／またはエッジサーバを備え得る。各演算／処理装置におけるネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を転送して演算／処理装置それぞれのコンピュータ可読記憶媒体に記憶する。

本開示の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、１つ以上のプログラミング言語の任意の組み合わせで書かれたソースコードまたはオブジェクトコードのいずれかであり得る。プログラミング言語は、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語または類似のプログラミング言語などの従来の手続き型プログラミング言語を含む。コンピュータ可読プログラム命令は、利用者のコンピュータ上で全体的に、スタンドアロンのソフトウェアパッケージとして利用者のコンピュータ上で部分的に、利用者のコンピュータ上で部分的に、および、リモートのコンピュータ上で部分的にまたはリモートのコンピュータまたはサーバ上で全体的に実行し得る。後者の概要では、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介して、利用者のコンピュータに接続されるか、外部コンピュータ（例えば、インターネットサービスプロバイダを使用してインターネットを介して）に接続され得る。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）またはプログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行して電子回路を個人化し、本開示の局面を実行し得る。

本開示の局面は、本開示の実施形態による方法、装置（システム）およびコンピュータプログラム製品のフローチャート図および／またはブロック図を参照して本明細書で説明される。フローチャート図および／またはブロック図の各ブロック、および、フローチャート図および／またはブロック図のブロックの組合せをコンピュータ可読プログラム命令が実施できることを理解されたい。

これらのコンピュータ可読プログラム命令は、汎用コンピュータ、専用コンピュータ、または、他のプログラマブルデータ処理装置のプロセッサに提供され得る。プロセッサは、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行する命令がフローチャート図および／またはブロック図の１つ以上のブロックで指定された機能／動作を実施するための手段を作成するように、機械を生成する。これらのコンピュータ可読プログラム命令はまた、コンピュータ、プログラマブルデータ処理装置および／または他の装置に命令をして特定の方法で機能させるコンピュータ可読記憶媒体に記憶され得る。その結果、その中に記憶された命令を有するコンピュータ可読記憶媒体は、フローチャートおよび／またはブロック図の１つ以上のブロックで指定された機能／動作の局面を実施する命令を含む製造品を備える。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブルデータ処理装置または他の装置上にロードされ、コンピュータ、他のプログラマブル装置または他の装置上で実行される一連の動作ステップを引き起こしてコンピュータ実施工程を生成し得る。その結果、コンピュータ、他のプログラマブル装置または他の装置上で実行される命令は、フローチャートおよび／またはブロック図の１つ以上のブロックで指定された機能／動作を実施する。

図中のフローチャートおよびブロック図は、本開示の様々な実施形態による、システム、方法およびコンピュータプログラム製品の可能な実施形態である体系、機能および動作を示す。この点に関して、フローチャートまたはブロック図の各ブロックは、指定された論理機能を実施するための１つ以上の実行可能命令を備えるモジュール、セグメント、または、コードの一部を表し得る。また、いくつかの代替的な実施形態では、ブロックに示される機能が図に記載されている順序の乱れが起き得ることを留意されたい。例えば、連続して示される２つのブロックは、実際には実質的に同時に実行され得る。または、それらのブロックは、含まれる機能次第で逆順序で時々実行され得る。ブロック図および／またはフローチャート図の各ブロック、および、ブロック図および／またはフローチャート図におけるブロックの組み合わせは、指定された機能または動作を実行する専用ハードウェアベースのシステム、または、専用ハードウェアおよびコンピュータ命令の組み合わせによって実施され得ることにも留意されたい。

本開示の様々な実施形態の記述は、例示の目的で提示されてきたが、網羅的であること、または、開示された実施形態に限定されることを意図していない。記載された実施形態の範囲および精神から逸脱しなければ、多くの修正および変形は当業者にとって明らかであろう。本明細書で使用される用語が選択されたことで、実施形態の原理、実際の運用、または、市場で見出される技術に対する技術的改善が最もよく説明されるか、当業者が本明細書で開示される実施形態を理解することができる。

記載されているものは、本開示の好ましい実施形態にすぎず、本開示を限定することを意図していない。当業者は、本開示に対して様々な修正および変形が適用され得ることを理解する。本開示の精神および原理内における任意の修正、均等物の置換および改善は、すべて本開示の保護範囲内にある。

Claims (26)

1. ブロックチェーン取引を処理するための方法であって、
   前記ブロックチェーン取引を処理するためのブロックチェーンのブロックチェーンノードにおいて、取引要求を受信すること
   を備え、
   前記取引要求は、前記取引の取引提案者と取引内容と取引受領者とを少なくとも示し、
   前記取引内容に基づいて、前記取引を処理するための取引手数料を計算することと、
   前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することと、
   前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引手数料が差し引かれる支払口座を決定することと
   をさらに備える方法。
2. 前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することは、
   前記取引要求が前記取引受領者の署名情報をさらに示すという判定に応じて、前記取引提案者が前記取引受領者の保証付き利用者であることを判定することを備える
   請求項１に記載の方法。
3. 前記取引提案者と前記取引受領者との保証人関係に基づいて前記取引提案者が前記取引受領者の保証付き利用者であることを判定することに応じて、前記取引受領者の署名情報は、前記取引受領者の管理装置が前記取引受領者の秘密鍵を用いて前記取引内容に署名することによって生成されて前記取引要求に追加され、
   前記保証人関係は、前記管理装置に格納される
   請求項２に記載の方法。
4. 前記取引提案者のクレジット残高が前記取引手数料以上であると判定することにさらに応じて、前記取引受領者の署名情報は、前記取引受領者の管理装置が前記取引受領者の秘密鍵を用いて前記取引内容に署名することによって生成されて前記取引要求に追加される
   請求項３に記載の方法。
5. 前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することとは、
   前記ブロックチェーンに記録された前記取引提案者と前記取引受領者との保証人関係に基づいて前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することを備える
   請求項１に記載の方法。
6. 前記取引提案者が前記取引受領者の保証付き利用者ではないという判定に応じて、前記取引提案者の第１口座の残高が前記取引手数料以上であるかどうかを判定することとと、
   前記取引提案者の前記第１口座の残高が前記取引手数料以上であるという判定に応じて、前記取引提案者の前記第１口座を支払口座として決定することと
   をさらに備える
   請求項５に記載の方法。
7. 前記取引手数料が差し引かれる支払口座を決定することは、
   前記取引受領者に関連付けられた保証人口座があるかどうかを判定することと、
   前記取引受領者に関連付けられた保証人口座があるという判定に応じて、前記保証人口座の残高が前記取引手数料以上であるかどうかを判定することと、
   前記保証人口座の残高が前記取引手数料以上であるという判定に応じて、前記保証人口座を前記支払口座として決定することとを備える
   請求項１に記載の方法。
8. 前記取引手数料が差し引かれる支払口座を決定することは、
   前記取引受領者に関連付けられた保証人口座がないという判定に応じて、または、前記保証人口座の残高が前記取引手数料未満であるという判定に応じて、前記取引受領者の第２口座の残高が前記取引手数料以上であるかどうかを決定することと、
   前記取引受領者の前記第２口座の残高が前記取引手数料以上であるという判定に応じて、前記取引受領者の前記第２口座を前記支払口座として決定することとをさらに備える
   請求項７に記載の方法。
9. 前記取引手数料が差し引かれる支払口座を決定することは、
   前記取引受領者の前記第２口座の残高が前記取引手数料未満であるという判定に応じて、前記取引提案者の第１口座の残高が前記取引手数料以上であるかどうかを判定することと、
   前記取引提案者の前記第１口座の残高が前記取引手数料以上であるという判定に応じて、前記取引提案者の前記第１口座を前記支払口座として決定することとを備える
   請求項８に記載の方法。
10. 前記取引内容が送金取引を示して前記取引提案者から前記取引受領者に暗号通貨の送金額が送金されるという判定に応じて、前記取引提案者の第３口座の残高が前記送金額以上であるかどうかを判定することと、
    前記取引提案者の前記第３口座の残高が前記送金額以上であるという判定に応じて、前記取引提案者の前記第３口座から前記取引受領者の第４口座に暗号通貨の前記送金額を送金することと
    をさらに備える
    請求項９に記載の方法。
11. 前記第１口座および前記第２口座は第１種類の暗号通貨に対応し、
    前記第３口座および前記第４口座は第２種類の暗号通貨に対応し、
    前記第１種類は、前記第２種類と異なる
    請求項１０に記載の方法。
12. 前記取引内容が送金取引を示して前記取引提案者から前記取引受領者に暗号通貨の送金額が送金されるという判定に応じて、前記取引提案者の前記第１口座の残高が前記送金額以上であるかどうかを判定することと、
    前記取引提案者の前記第１口座の残高が前記送金額以上であるという判定に応じて、前記取引提案者の前記第１口座から前記取引受領者の前記第２口座に前記暗号通貨の送金額を送金することと
    をさらに備え、
    前記第１口座、前記第２口座および前記暗号通貨の送金額は、第１種類の暗号通貨に対応する
    請求項９記載の方法。
13. 前記取引手数料が差し引かれる支払口座を決定することは、
    前記ブロックチェーンに記録された前記取引提案者のクレジット情報に基づいて、前記取引提案者のクレジット残高が前記取引手数料以上であるかどうかを判定することと、
    前記取引提案者のクレジット残高が前記取引手数料以上であるという判定に応じて、前記取引手数料が差し引かれる前記支払口座を決定することとをさらに備える
    請求項１に記載の方法。
14. 前記クレジット情報は、クレジット限度および利用済みクレジットを少なくとも示し、
    前記クレジット残高は、「クレジット残高＝クレジット限度−利用済みクレジット」によって決定される
    請求項４または１３に記載の方法。
15. 前記クレジット情報は、クレジット復元率およびブロック高をさらに含み、
    前記クレジット復元率は、通過する各ブロックによって復元されるクレジット額を示し、
    前記ブロック高は、前記取引受領者が前記取引提案者の前記取引手数料を支払った前回から通過したブロック数を示し、
    前記クレジット残高は、「クレジット残高＝クレジット限度−利用済みクレジット＋ブロック高×クレジット復元率」によって決定される
    請求項１４に記載の方法。
16. 前記クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し、
    前記クレジット残高は、「クレジット残高＝クレジット支払回数限度−利用済みクレジット支払回数」によって決定される
    請求項４または１３に記載の方法。
17. ブロックチェーン取引を管理するための方法であって、
    前記ブロックチェーン取引を管理するための管理装置において、前記取引の取引提案者から要求を受信すること
    を備え、
    前記要求は、前記取引の前記取引提案者、取引内容および取引受領者を少なくとも示し、
    前記取引提案者が前記取引受領者の保証付き供利用者であるかどうかを判定することと、
    前記取引提案者が前記取引受領者の保証付き利用者であるという判定に応じて、前記取引受領者の署名情報を生成すると共に受信した前記要求に前記取引受領者の署名情報を追加することによって、取引要求を形成することと
    をさらに備え、
    前記署名情報は、前記ブロックチェーン取引を処理するブロックチェーンのブロックチェーンノードに対する取引手数料を前記取引受領者に関連付けられた支払口座から差し引くことができることを示す
    方法。
18. 前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することは、
    前記取引提案者と前記取引受領者との保証人関係に基づいて、前記取引提案者が前記取引受領者の保証付き利用者であるかどうかを判定することを備え、
    前記保証人関係は、前記管理装置に格納される
    請求項１７に記載の方法。
19. 前記署名情報を生成すると共に受信した前記要求に前記署名情報を追加することによって、取引要求を形成することは、
    前記管理装置に格納された前記取引提案者のクレジット情報に基づいて、前記取引提案者のクレジット残高が前記取引手数料以上であるかどうかを判定することと、
    前記取引提案者のクレジット残高が前記取引手数料以上であるという判定に応じて、前記取引受領者の秘密鍵で前記取引内容に署名することによって、前記署名情報を生成すると共に受信した前記要求に前記署名情報を追加することとを備える
    請求項１７に記載の方法。
20. 前記クレジット情報は、クレジット限度および利用済みクレジットを少なくとも示し、
    前記クレジット残高は、「クレジット残高＝クレジット限度−利用済みクレジット」によって決定される
    請求項１９に記載の方法。
21. 前記クレジット情報は、クレジット復元率およびブロック高をさらに含み、
    前記クレジット復元率は、通過する各ブロックによって復元されるクレジット額を示し、
    前記ブロック高は、前記取引受領者が前記取引提案者の前記取引手数料を支払った前回から通過したブロック数を示し、
    前記クレジット残高は、「クレジット残高＝クレジット限度−利用済みクレジット＋ブロックの高さ×クレジット復元率」によって決定される
    請求項２０に記載の方法。
22. 前記クレジット情報は、クレジット支払回数限度および利用済みクレジット支払回数を少なくとも示し、
    前記クレジット残高は、「クレジット残高＝クレジット支払回数限度−利用済みクレジット支払回数」によって決定される
    請求項１９に記載の方法。
23. ブロックチェーン取引を処理するための装置であって、
    １以上のプログラムを格納するように構成されるメモリと、
    前記メモリに結合され、前記１以上のプログラムを実行して請求項１から１６のいずれか１項に記載の方法を前記装置に実行させるように構成される処理部と
    を備える装置。
24. ブロックチェーン取引を管理するための装置であって、
    １以上のプログラムを格納するように構成されるメモリと、
    前記メモリに結合され、前記１以上のプログラムを実行して請求項１７から２２のいずれか１項に記載の方法を前記装置に実行させるように構成される処理部と
    を備える装置。
25. 機械実行可能命令が格納される非一時的コンピュータ可読記憶媒体であって、
    前記機械実行可能命令は、実行されると、請求項１から２２のいずれか１項に記載の方法を機械に実行させる
    非一時的コンピュータ可読記憶媒体。
26. 非一時的コンピュータ可読媒体に有形に格納され、機械実行可能命令を備え、
    前記機械実行可能命令は、実行されると、請求項１から２２のいずれか１項に記載の方法の過程を機械に実行させる
    コンピュータプログラム製品。

Images