JP6730369B2 - 利用管理方法、利用管理システム、および、ノード - Google Patents

Description

本発明は、分散台帳システムに関する利用管理方法、利用管理システム、および、ノード、に関するものであり、具体的には、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況を的確に把握し、活用可能とする技術に関する。

従来行われてきた中央集権機関（例：金融機関や政府など）を経由した取引に代わる、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）による直接的な取引として、分散台帳技術が登場している。

そうした技術としては、例えば、仮想通貨を用いることで、銀行などの中央集権機関を必要とせずに決済取引を行う技術（非特許文献１参照）が提案されている。この技術では、Ｐ２Ｐネットワーク上における取引データ（以下、トランザクションとも称する）に対し、マイナーと呼ばれるノードによる正当性判定を行った後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行っている。ここで確定されたトランザクションは１つのブロックにまとめられ、ブロックチェーン（以下、ＢＣとも称する）と呼ばれる分散台帳に記載される。なお、分散台帳における参加者のノードによって構成されるシステムを分散台帳システムと称する。
一方、近年では、上述の技術に基づいて実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術が提案され、進化を続けている。

現状のＢＣの主な特徴としては、（１）分散台帳システム上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、が挙げられる。

このようなＢＣをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。

例えば、分散台帳は、従来の単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくロジックも管理可能となってきている。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。

そこで、上述のＳＣの実行機能を有する分散台帳システム（非特許文献２および非特許文献３）も存在する。こうした分散台帳システムでは、ノード間において所定の合意水準で合意形成しながら、トランザクション（以下、ＴＸとも称する）を受け入れて、各ノードでＴＸを実行することにより、複数ノード上で情報（台帳）を共有する。また、ＴＸに対して予め決めたロジックを実行するスマートコントラクト（ＳＣ）実行機能を備える。

特に、従来のいわゆるパブリック型と異なり、特定企業／組織間のノードで構成した、コンソーシアム型の分散台帳システムにおいては、当該コンソーシアムに参加する複数の
組織間で各ノードが分散合意プロトコルに基づき同期／連動しながら、事前に取り決められ、かつ、コード化された契約内容（上述のＳＣ）に従って取引を自動実行することができる。

この場合、管理ドメインの異なる複数組織にまたがり、組織各々が互いのリソースを持ち寄ることで、分散台帳システムが実現される。従って、組織各間でリソースやそのデータを利用し合いながら取引を成立させ、組織横断での価値や情報を共有することとなる。

一方、そうしたコンソーシアム型の分散台帳システムを健全に維持／運営するためには、各組織がノードなどリソースやそのデータを提供する必要がある。また、その提供費用を管理するための課金管理技術も必要となる。

課金管理に関する従来技術としては、例えば、複数の利用者の端末と、リソースプロバイダと、複数のパブリッククラウドとがネットワークで通信接続され、前記複数のパブリッククラウドは、各々に、前記リソースプロバイダが管理する共同利用型サーバが設置され、前記リソースプロバイダは、制御部と、記憶部と、を有し、前記制御部は、登録部と、実行制御部とを有し、前記記憶部は、前記利用者のプログラムのデータを管理情報と共に格納し、前記登録部は、前記利用者からの指示に基づき、前記利用者のプログラムのデータを管理情報と共に前記記憶部に格納する処理を行い、前記実行制御部は、前記利用者からの指示に基づき、前記記憶部の前記利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させるように制御する処理を行い、前記実行制御部からの制御に基づき、前記対象のパブリッククラウドの対象の共同利用型サーバは、前記利用者のプログラムの処理を稼働させること、を特徴とするクラウド共用型リソース提供システム（特許文献１参照）などが提案されている。

特開２０１３−６９２３７号公報

"Ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆ＞ "Ｅｔｈｅｒｅｕｍ Ｗｈｉｔｅ Ｐａｐｅｒ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｔｈｅｒｅｕｍ／ｗｉｋｉ／ｗｉｋｉ／［Ｅｎｇｌｉｓｈ］−Ｗｈｉｔｅ−Ｐａｐｅｒ＞ "Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ"， ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ−ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞

コンソーシアム全体で課金管理を行う手段としては、例えば、分散台帳システムの維持運営費（の課金）として、各組織のリソースやデータの提供（例：ノードやそのデータの提供）を求めることに加え、各組織からの一律料金徴収（例：参加費）を行う方法が挙げられる。

しかしながら、コンソーシアムにおける組織ごとに、それぞれの維持運営負担（リソースやデータの提供や一律料金の支払等）と、システム消費（例：自身が要求するトランザ
クションの処理やデータの参照や蓄積）とのバランスは異なっている。そのため上述の方法を適用すると、負担に関して組織間での不公平が生じやすい。

上述のバランスが維持運営負担側に偏っている組織であれば、その不公平感は強まり、リソース等の提供の動機が乏しくなる。すると、分散台帳システムにおけるリソース等の質や量が低下し、最終的にはシステム破綻につながりかねない。

一方、上述の従来技術では、リソースプロバイダ（中央機関）がすべての組織におけるリソースの利用状況と各クラウドリソースの稼働状況を把握できることを前提としており、リソースプロバイダが複数存在するコンソーシアム型の分散台帳システムに適用することはできない。

つまり、従来技術においては、各組織によるリソース等の利用状況やリソース等の提供によるコンソーシアムへの貢献状況を、組織を跨いで的確に把握する手段がなく、また、そうした状況把握を各組織からの自己申告により行っても信ぴょう性が不確かである、といった問題が存在している。

そこで本発明の目的は、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況を的確に把握し、活用可能とする技術を提供することにある。

上記課題を解決する本発明の利用管理方法は、複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定の複数ノードそれぞれが、前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置を備え、前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する、ことを特徴とする。

また、本発明の利用管理システムは、複数の組織それぞれのノードで構成された分散台帳システムにおける、前記ノードのうち少なくとも所定の複数ノードを含むシステムであり、前記複数ノードが、前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置と、前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する演算装置と、を有するものであることを特徴とする。

また、本発明のノードは、複数の組織それぞれのノードで構成された分散台帳システムにおける、前記ノードのうちの所定ノードであって、前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置と、前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する演算装置と、を有することを特徴とする。

本発明によれば、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況を的確に把握し、活用可能とできる。

実施例１におけるコンソーシアム型分散台帳システムの概念例を示す図である。 実施例１のコンソーシアム型分散台帳ネットワークにおけるコンピュータシステムを模式的に示す図である。 実施例１における分散台帳ノードの物理的な構成例を示す図である。 実施例１における分散台帳上のブロックチェーンのデータ構造例を示す図である。 実施例１における分散台帳上のブロックチェーンのデータ構造例を示す図である。 実施例１における分散台帳上のステート情報のデータ構造例を示す図である。 実施例１における構成情報のデータ構造例を示す図である。 実施例１におけるシステム消費／貢献度計算ＳＣのデータ構造および処理内容を示す図である。 実施例１におけるシステム消費／貢献度計算ＳＣのステート情報として管理されるシステム消費／貢献度計算ロジックを示す図である。 実施例１におけるシステム消費／貢献度計算ＳＣのステート情報として管理されるシステム消費／貢献度計算ロジックを示す図である。 実施例１におけるシステム消費／貢献度計算ＳＣのステート情報として管理されるシステム消費／貢献度計算結果を示す図である。 実施例１におけるシステム消費／貢献度計算ＳＣのステート情報として管理されるポイント集計結果を示す図である。 実施例１における分散台帳システムの利用管理方法のフロー例１を示す図である。 実施例１における分散台帳システムの利用管理方法のフロー例２を示す図である。 実施例１における分散台帳システムの利用管理方法のフロー例３を示す図である。 実施例１における分散台帳システムの利用管理方法のフロー例４を示す図である。 実施例３のコンソーシアム型分散台帳システムにおけるコンピュータシステムを模式的に示す図である。 実施例３における分散台帳システムの利用管理方法のフロー例を示す図である。

−−−実施例１−−−
＜コンソーシアム型分散台帳システムの概念＞

まず、コンソーシアム型分散台帳システムの基本概念について説明する。図１に実施例１におけるコンソーシアム型分散台帳システム５の概念例を示す。また図２に、コンソーシアム型分散台帳システム５のコンピュータシステムの構成例を示す。

本実施例におけるコンソーシアム型分散台帳システム５（以下、分散台帳システム５と称する）は、当該コンソーシアムの構成組織における共同利用対象となるシステム（分散
台帳システム５自体か、或いは他の管理対象システムの少なくともいずれか）の利用状況ならびに貢献状況を的確に把握し、活用可能とする利用管理システム１０を含んで構成される。
この利用管理システム１０は、分散台帳システム５における分散台帳ノード３（図２）から構成されるシステムである。

また、この利用管理システム１０が管理対象とするシステム、すなわち管理対象システムは、ここでは分散台帳システム５それ自体であるとするが、後述するように、これに限定するものではない。

こうした利用管理システム１０を構成する各分散台帳ノード３は、所属組織で行う業務処理に応じたトランザクションを処理し、その実行履歴を分散台帳Ｄ１に格納する業務スマートコントラクトＤ１１（下記のシステム運用履歴共有スマートコントラクトＤ１３と同様、第１のスマートコントラクトに相当）と、そうして処理されるトランザクションの情報を合意形成を経た上で運用履歴として分散台帳Ｄ１に格納するシステム運用履歴共有スマートコントラクトＤ１３（以下、システム運用履歴共有ＳＣ。第１のスマートコントラクト）と、分散台帳Ｄ１における上述の実行履歴や運用履歴（これらは本発明における「処理履歴」に相当）に基づいて分散台帳システム５における消費度や当該システムへの貢献度を計算するシステム消費／貢献度計算スマートコントラクト（以下、システム消費／貢献度計算ＳＣ。第２のスマートコントラクト）とを少なくとも管理する。

なお、上述のシステム消費／貢献度計算ＳＣは、管理対象システムたる分散台帳システム５の各参加組織における、システムの消費度（当該システムの利用状況を定量化した値）および当該分散台帳システム５への貢献度（当該システムに対するリソースやデータ、サービスの提供状況を定量化した値）、に関する計算方法（計算ポリシー）を定めたスマートコントラクトである。

図１で示す構成において、上述の分散台帳システム５を構成するノード（以下、分散台帳ノード３）に対して、計算処理実行要求としてシステム消費／貢献度ＳＣの実行ＴＸが発行されると、分散台帳ノード３の間で、この実行ＴＸに対する合意形成処理がなされる。また、この合意形成がなされた後で、各分散台帳ノード３上で、システム消費／貢献度計算ＳＣにて定義された計算ポリシーに従い、各参加組織の消費度や貢献度が計算される。 システム消費／貢献度計算ＳＣ中には、ポリシーや計算方法として、上述の消費度や貢献度に対する対価／報酬の計算ロジックおよびその集計／分配のための計算方法が記載される。分散台帳ノード３は、こうしたＳＣ機能を用いており、各分散台帳ノード３上で同一の計算処理が実施されるため、実質的に計算結果を相互確認しながら実施することができる。

こうした背景の下、本実施例における分散台帳システム５の参加組織は、組織横断でのシステム消費／貢献度ＳＣを（業務ごとに）定義し、分散台帳ノード３の分散台帳上に配置しておくものとする。このシステム消費／貢献度ＳＣ中の計算ポリシーは、計算ロジック、その計算の入力となる上述の実行履歴や運用履歴の属性等を含む。
なお、上述の計算ロジックは、分散台帳システム５における消費度や貢献度に対する、対価／報酬の計算式（およびその集計／組織間分配）が規定されている。

また、この計算ロジックの入力としては、複数組織で相互管理している実績情報（具体的には分散台帳に蓄積された上述の実行履歴や運用履歴であり、処理履歴に相当）や、分散台帳システム５への参加組織の情報が用いられる。

分散台帳ノード３が、このようなシステム消費／貢献度ＳＣを実行し、他の分散台帳ノ
ード３との間で、当該ＳＣに基づき相互に合意形成／検証をしながら、各組織の消費度や貢献度を計算し、その結果を自身の分散台帳に格納することとなる。

また、分散台帳ノード３は、上述のシステム消費／貢献度ＳＣに基づき、他の分散台帳ノード３との間で相互に合意形成／検証をしながら、消費度や貢献度の計算結果を組織ごとに集計／分配した結果を分散台帳に格納する。なお、詳細については後述するが、利用組織の違う複数業務が存在する場合、業務横断の全体の消費度や貢献度の計算を行うものとする（同様にスマートコントラクトに従う）。
図１においては、業務Ａと業務Ｂという２つの業務が存在し、それぞれ利用グループが異なっている（図中では異なる業務グループをチャネルと呼んでいる）。

例えば業務Ａチャネルは、少なくとも組織１（Ｏｒｇ１）、組織２（Ｏｒｇ２）、組織３（Ｏｒｇ３）が参加し、それぞれの間で互いにノードが所有／相互利用される。例えば、図中の例では、Ｏｒｇ１がトランザクション（以下、ＴＸとも称する）を発行した場合に、自組織のノードだけでなく他組織（Ｏｒｇ２）によって当該ＴＸの実行／承認が行われている。また、そのＴＸ実行結果は各組織の分散台帳上に複製コピーして共有される。

例えば、業務ＡのＴＸ実行結果や実行履歴は、Ｏｒｇ１，Ｏｒｇ２，Ｏｒｇ３の分散台帳の間で同期した複製が保持される。こうした分散台帳には参加組織が取り決めた水準に従って合意／承認された取引情報が、相互に保持されることになる。これにより、分散台帳で保持されたデータは、耐改ざん性や客観性が高いデータとなっている。

一方、分散台帳上に保持されるデータは、組織のＴＸ発行量などに応じて偏りが出る。例えば、この図ではＯｒｇ１のデータ量がＯｒｇ２や３に比べて多いことを表現している。

このようにＴＸ発行量などによって組織ごとにノード処理量や分散台帳内に蓄積されるデータ量が偏る中で、分散台帳に蓄積された運用履歴や実行履歴を実績情報として利用し、組織横断での消費度や貢献度（以下、システム消費／貢献度）の計算ポリシーをＳＣ化しておき、複数組織で相互計算することで、コンソーシアムを構成する複数組織の間での公正／公平なシステム消費状況ならびにシステム貢献状況の把握・計算を実現する。

ここで、分散台帳に蓄積された履歴としては、この業務に関するＴＸの実行履歴だけでなく、この業務に関連した分散台帳システム５の運用作業履歴なども共有しておけば、業務そのものだけでなくシステム運用作業に関する各組織のシステム消費／貢献度も計算することができる。その計算結果は、ＳＣを介して分散台帳上に登録しておき、図の下部に示す通り、参加組織の異なる業務チャネルを横断したシステム消費／貢献度計算ＳＣを実行することで、業務跨ぎでのシステム消費／貢献度の計算も公正／公平に実施することができる。

なお、上述の分散台帳システム５を構成するコンピュータシステムは、図２で例示するように、１台以上の分散台帳ノード３、および、１台以上のクライアントノード４によって構成される。これらの機器は、物理的な通信回線２を通してネットワーク１に接続される。

このうち分散台帳ノード３は、コンセンサス管理部３１、スマートコントラクト実行／管理部３２（以下、ＳＣ実行／管理部３２とも称する）、メンバー管理部３３、トランザクション管理部３４、トランザクション発行部３５、承認済トランザクション配信部３６、ネットワークプロトコル部３７、分散台帳Ｄ１、構成情報Ｄ２、および、参加メンバー管理情報Ｄ３によって構成される。

こうした分散台帳ノード３は、トランザクション管理部３４の機能によりＴＸを受け付けて、コンセンサス管理部３１の機能によって、他の分散台帳ノード３との間で当該ＴＸを受け入れてよいかの合意形成を行い、合意形成がなされたらＳＣ実行／管理部３２の機能を介して、ＳＣのデプロイ、デプロイ済みのＳＣに対する実行を行う。

また分散台帳ノード３は、上述のＳＣに対する実行を経て、上述のＴＸの実行履歴とその実行結果を分散台帳Ｄ１に記録する。ここで、上述の合意形成やＳＣ実行は必ずしもすべてのノードが行う必要はなく、一部のノード間で行ってその結果を他ノードに配信してもよい（その取り決めは合意形成アルゴリズムにも依存する）。

また、分散台帳ノード３は、承認済トランザクション配信部３６の機能により、上述の合意形成やＳＣ実行に参加しなかったノードに対して、その結果（具体的には、ＴＸの実行履歴と実行結果）を配信する。
ここで、ノード間での合意形成や承認済ＴＸの配信といった分散台帳ノード３間の通信は、ネットワークプロトコル部３７の機能によって行う。

また、分散台帳ノード３は、トランザクション管理部３４の機能により、クライアントノード４等の各ノードからの要求に対して、ＴＸを受け付けたり、当該ＴＸの実行履歴等の情報を取得し、これを所定のインタフェースを介しクライアントノード４にて閲覧させる。本実施例では、分散台帳ノード３がＴＸ発行可能であることとし、トランザクション発行部３５を介して各種ＴＸを発行する。

また、分散台帳ノード３のメンバー管理部３３は、分散台帳システム５に参加するメンバーの新規発行や認証機能を提供する。メンバー管理部３３では、秘密鍵と公開鍵のペアを用いて、参加組織ならびにその組織に所属するメンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。こうしたメンバー管理部３３にて取り扱う鍵情報は、参加メンバー管理情報Ｄ３上に格納・管理される。

また、トランザクション管理部３４は、ＴＸを受け付けた際に、適宜、メンバー管理部３３の機能を介して、当該ＴＸの発行者が権限を持った正しい参加者かどうかを確認する。ただし、こうした機能は公知技術であり説明は省略する。

なお、構成情報Ｄ２では、分散台帳システム５を構成する組織やその組織に属するメンバー（ノード、管理者、ユーザなどを含む）の情報を格納・管理する。本実施例では本情報が分散台帳ノード３の機能の中で（例えば、メンバー管理部３３やネットワークプロトコル部３７）管理され、各ノードが互いに保持していることを想定する。

また、分散台帳上Ｄ１では、既に述べたように、業務に関するＳＣ（以下、業務ＳＣ＿Ｄ１１）、システム消費／貢献度計算に関するＳＣ（以下、システム消費／貢献度計算ＳＣ＿Ｄ１２）、システム運用履歴を共有するためのＳＣ（以下、システム運用履歴共有ＳＣ＿Ｄ１３）に関わる台帳情報を格納・管理する。

そのデータ構造としては、本実施例では、ＴＸの履歴をＢＣとして、ＴＸの実行結果に基づくステート情報をテーブル上で保持することを想定する。その内部テーブルではＫｅｙ−Ｖａｌｕｅの組として値を保持する想定である。
一方、クライアントノード４は、少なくとも、トランザクション発行部３５、業務アプリ４１、および、管理アプリ４２を含んで構成される。

ＳＣの利用者もしくは提供者は、こうしたクライアントノード４のトランザクション発
行部３５を介して、各種ＴＸを発行して分散台帳ノード３に対して送信する。なお、こうしたＴＸには発行者情報が付与されるが、この発行者情報としては、参加メンバー管理情報Ｄ３に基づき所定のアルゴリズムで発行された認証情報（秘密鍵）を利用する。

また業務アプリ４１は、上述のトランザクション発行部３５を介して、業務ＳＣ＿Ｄ１１に関するＴＸを発行することで、業務処理を実行／管理するアプリである。

また管理アプリ４２は、トランザクション発行部３５を介して、システム運用履歴共有ＳＣ＿Ｄ１３に関するＴＸを発行することで、システム運用作業履歴を登録／管理したり、システム消費／貢献度計算ＳＣ＿Ｄ１２に関するＴＸを発行することで、各組織のシステム消費／貢献度を計算し、さらにはその結果に基づいて課金管理を行うためのアプリである。

本実施例では、分散台帳ノード３が複数存在し、それらが複数の主体（例えば、複数の事業者／複数の組織／複数のベンダ）によってそれぞれ管理されることを想定する。
同様にクライアントノード４も複数台存在し、複数のＳＣ利用者がそれぞれ別のクライアントノード４を利用することを想定する。
なお、クライアントノード４に関しては、ＴＸに付与する認証情報をユーザ毎に切り替えることにより、複数のＳＣ利用者が共用することも可能である。
＜分散台帳ノードのハードウェア構成＞

図３は、実施例１における分散台帳ノード３の物理的な構成例を示すブロック図である。本実施例における分散台帳ノード３は、インタフェース（Ｉ／Ｆ）１００、プロセッサ１０１、メモリ１０２、および、補助記憶装置１０４を備える計算機である。
また、こうしたＩ／Ｆ１００、プロセッサ１０１、メモリ１０２、および、補助記憶装置１０４は、データバス１０３によって互いに接続されている。

このうちＩ／Ｆ１００は、ネットワーク１を介して他の分散台帳ノード３やクライアントノード４と通信するネットワークインタフェースカード等を想定できる。
またプロセッサ１０１は、ＣＰＵ等の演算装置である。

また、メモリ１０２は、プログラム１０２１およびデータ１０２２を一時的に保持するための記憶装置であり、具体的にはＲＡＭなどの揮発性記憶手段で構成される。

また、補助記憶装置１０４は、プログラム１０２１やデータ１０２２を格納している記憶装置であり、具体的にはＳＳＤやＨＤＤなど不揮発性記憶手段で構成される。

上述のプロセッサ１０１は、補助記憶装置１０４からデータバス１０３を介してプログラム１０２１やデータ１０２２をメモリ１０２に読み出し、実行することで、分散台帳ノード３として必要な機能を実装する。
＜分散台帳について＞

図４および図５は、分散台帳Ｄ１におけるデータ構造の一例を示す図である。このうち図４では、分散台帳Ｄ１上で管理するデータ構造の一つである、ＢＣ１１の例を示している。ＢＣ１１を用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。
前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変わるため、改ざんを困難にすることができる。

なお、本実施例では説明をシンプルにするために、１つのＴＸにつき、１ブロックとす
るが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。また本実施例では、各ＳＣ（Ｄ１１〜Ｄ１３）が単一のＢＣとして連なっているが、参加組織がそれぞれ管理／参照可能であればＢＣ自体は別々であっても構わない。

図４、図５におけるブロックＤ１０００〜Ｄ１００８は、ＢＣ１１を構成する一連のブロックの連なりである。各ブロックは、それぞれ業務ＳＣのデプロイおよび実行、システム運用履歴共有ＳＣのデプロイおよび実行、システム消費／貢献度計算ＳＣのデプロイおよび実行、のいずれかのＴＸ情報を含む。
また各ブロックは、前ブロックのハッシュ値を含み、後述のステート情報から生成したハッシュ値を含んでいる。

上記のようなデータ構造により、業務ＳＣのデプロイおよび実行、システム運用履歴共有ＳＣのデプロイおよび実行、システム消費／貢献度計算ＳＣのデプロイおよび実行、のＴＸ履歴がＢＣ１１中でデータの連鎖として管理される。

なお、ブロックＤ１０００は、業務ＳＣのデプロイＴＸを格納したブロックの一例である。この例では、複数組織間での顧客確認（Ｋｎｏｗ Ｙｏｕｒ Ｃｕｓｔｏｍｅｒ業務）に関するビジネスコントラクトの例を示している。顧客が信用できる優良顧客か否かの顧客信用情報を複数組織で台帳上において共有することで、顧客本人の身分確認や判断を効率化することができるようになる。

本実施例のデプロイＴＸは、ＴＸが発行されたタイムスタンプ、適用するＳＣが業務かシステム運用かシステム消費／貢献度計算かを特定するＳＣ種別、ＳＣを一意に識別するＳＣ＿ＩＤ、ＴＸがデプロイか実行か参照かを特定するＴＸ種別、ＳＣの実態（例えば実行可能なバイナリ）を含む。

また、デプロイＴＸは、ＳＣが持つ関数名やその引数を利用者が把握するためのＳＣ入力仕様を含んでいる。さらに、デプロイ時に指定した入力引数にしたがって決めたパラメータであるＳＣメタ定義を含む。このＳＣメタ定義としては、例えばこのＳＣの実行時における合意形成条件（例：２組織以上の承認を持ってＴＸを受け入れる）や、各種定義情報等を想定する。

また、デプロイＴＸは、当該ＴＸの発行者の情報を含む。ＴＸ発行者の情報は、発行者のメンバーＩＤと、発行元と、データに改ざんが無いことを検証するために用いる電子署名情報とを含む。なお、この電子署名は、メンバー管理部３３が発行した各参加メンバー（すなわちＳＣ提供者や利用者）の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。

また、デプロイＴＸは、ＴＸ発行者の情報と同様にＴＸ実行／承認者（言い換えると、コンセンサス管理部３１、ＳＣ管理／実行部３２を用いた合意形成ならびにＳＣ実行処理に関わった参加者の情報）の情報や、承認済ＴＸ配信者（言い換えると、承認済ＴＸ配信部３６による配信処理に関わった参加者の情報）の情報も含む。

さらにデプロイＴＸは、当該ＴＸで参照／更新を行ったステート情報であるＲｅａｄ−Ｗｒｉｔｅ（ＲＷ）セットの情報も含む。ＲＷセットについては後述の実行ＴＸの説明にて詳細に述べる。

なお、以降ではＳＣが持つ関数のことをＳＣ関数とも称する。例えば、ブロックＤ１０００でデプロイされているＳＣは、ＳＣ＿ＩＤ「業務Ａ」として組織「Ｏｒｇ１」の「管理者」によって提供され、以下のＳＣ関数が定義されている。
・関数名：登録（）、入力引数：顧客ＩＤ、顧客信用ステータス、戻り値：なし
・関数名：参照（）、入力引数：顧客ＩＤ、戻り値：顧客信用ステータス

また、ブロックＤ１００５は、業務ＳＣの実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸは、基本的にデプロイＴＸと同様の構成であるが、ＳＣの実態やＳＣ入力仕様はない。その代わりに、呼び出すＳＣ関数名と入力する引数の情報とを含む。

なお、本実施例では、ＴＸ種別については、台帳の更新を含むＴＸ実行の場合には「実行」、台帳の更新を行わない参照処理の場合には「参照」を指定することとする。

また、ブロックＤ１００５のＴＸでは、ＳＣ＿ＩＤに「業務Ａ」を指定し、ＳＣ関数「登録（）」に入力引数「ＣｕｓｔｏｍｅｒＢ，Ｎｏｔ Ｇｏｏｄ」を指定した実行要求を行う例を示す。すなわち、ブロックＤ１０００に示したＳＣを呼び出している例である。

また、ＲＷセットでは、ＳＣ（の関数）のデプロイや実行にて、参照／更新されたステート情報を示し、ＳＣ＿ＩＤ、参照（Ｒｅａｄ）か更新（Ｗｒｉｔｅ）かを識別する「ＲＷ区分」、対象となるステート情報のＫｅｙ、Ｖａｌｕｅの情報を含む。

さらにこのＶａｌｕｅの更新バージョン番号の情報を示す。このバージョン番号は、ＳＣ＿ＩＤのＫｅｙ毎に管理されて、更新のたびに１ずつインクリメントされることとする。 ブロックＤ１００５の例では、関数呼び出し「登録（ＣｕｓｔｏｍｅｒＢ，Ｎｏｔ Ｇｏｏｄ）」の実行処理の中で、Ｋｅｙ「ＣｕｓｔｏｍｅｒＢ」を参照し、バージョン番号「４」のＶａｌｕｅ「Ｇｏｏｄ」を取得し（１行目）、Ｖａｌｕｅ「Ｎｏｔ Ｇｏｏｄ」で更新して、その結果、バージョン番号が「５」に更新されたことを示す。

このようにＴＸの実行結果をＲＷセットとして管理／保持することで、ＳＣを実行せずともその実行結果を把握することができ、これによりＳＣを実行しなかったノードに対してもＳＣ実行結果を共有できるため、処理が効率的である。

上述のブロックのうち、ブロックＤ１００１およびブロックＤ１００６は、システム運用履歴共有ＳＣのデプロイＴＸおよび実行ＴＸを格納したブロックの一例である。本実施例のシステム運用履歴共有ＳＣのデプロイＴＸおよび実行ＴＸは、大枠のデータ構造としては、業務ＳＣの同ＴＸと同様の情報を含む。単純に、業務に関わるＳＣが記述されているか、分散台帳システム５に対するシステム運用作業の実行履歴共有に関するＳＣが記述されているかの違いしかない想定である。

ここで分散台帳システム５の運用作業とは、具体的には、例えば、ノードに蓄積された分散台帳のバックアップ作業やノードに対するパッチあて作業などがあげられる。

ブロックＤ１００１およびブロックＤ１００６の例は、上述の業務ＳＣ（ＳＣ＿ＩＤ：業務Ａ）に対する運用作業の履歴を登録するためのＳＣであることを示す。各組織の管理者が組織全体で共有するべき運用作業を実行した際に、運用実行履歴登録として、運用作業ＩＤ、実行完了時刻、実行者、運用実行結果詳細などの情報を、本ＳＣの実行ＴＸにより登録することとする。

一方、ブロックＤ１００２およびブロックＤ１００７は、システム消費／貢献度計算ＳＣのデプロイＴＸおよび実行ＴＸを格納したブロックの一例である。本実施例のシステム消費／貢献度計算ＳＣのデプロイＴＸおよび実行ＴＸは、大枠のデータ構造としては、業務ＳＣの同ＴＸと同様の情報を含む。単純に、業務に関わるＳＣが記述されているか、分散台帳システム５のシステム消費／貢献度計算に関するＳＣが記述されているかの違いし
かない想定である。

これにより分散台帳システム５の内部（具体的には分散台帳ノード３の３１〜３７の各機能）に手を加えなくとも、外側の機能として本発明を実装することが可能である。システム消費／貢献度計算ＳＣの詳細は後述するため、ここでは省略する。
＜ステート情報について＞

図６は、分散台帳Ｄ１上で管理するステート情報１２である。上述のＢＣ１１を用いた分散台帳管理では、通常、（最新の）ステート（例えば、仮想通貨の場合にはアカウントの残高）を取得するためには、ＢＣ１１を辿らなければならない。これでは処理効率が悪いため、ＢＣ１１とは別に、最新のステート情報をキャッシュしておく方法が存在する（非特許文献３等）。

本実施例の分散台帳ノード３でも、最新のステート情報１２を保持することを想定する。本実施例では、ＳＣ毎にステートのデータ領域が用意されることとする。

ステート情報１２は、ＳＣ＿ＩＤとそのＳＣの実態を保持する。これにより、ＳＣ実行／管理部３２は、ＳＣ＿ＩＤをキーにして、ＳＣの実態を取得して実行することができる。 また、ステート情報１２は、ＳＣの実行結果を保持するための内部テーブルを備える。分散台帳ノード３は、ＴＸの実行ごとにこの内部テーブルの内容を更新する。なお、本ステート情報１２に関しても、業務ＳＣ、システム運用履歴共有ＳＣ、システム消費／貢献度計算ＳＣなどの各ＳＣの情報が格納される。

ここで、ステート情報１２における業務ＳＣに関する情報Ｄ１１１０の内部テーブルに着目すると、図４での説明で述べたＲＷセットと対応づいており、ＲＷセットをすべて反映した最新の状態が保持されている。なお、典型的な実装例では、このようにＫｅｙ−ｖａｌｕｅ形式でデータを保持するが、ＶａｌｕｅにＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）形式などの構造化されたデータも格納できる。そうすれば、任意のデータスキーマのテーブルを保持できることになる。またＫｅｙの設計を工夫すれば、内部テーブル内で複数のテーブル（スキーマの異なる情報）を仮想的に管理することができる。システム運用履歴共有ＳＣに関する情報Ｄ１１１１や、システム消費／貢献度計算ＳＣに関する情報Ｄ１１１２における内部テーブルは、説明をシンプルにするために、Ｖａｌｕｅに構造化されたデータを格納するケースで、Ｋｅｙ−Ｖａｌｕｅ−バージョンの記載などを省略した表現をしている。例えば、情報Ｄ１１１１では、実際には、Ｖａｌｕｅに運用作業ＩＤ、実行完了時刻、実行者、運用実行結果詳細の情報がＪＳＯＮ形式などで格納されているイメージである。

また、分散台帳システム５では、分散台帳にＴＸが追加されたことを契機にしてイベントを発行して、各参加組織のノードに通知する機能も提供可能である。各参加組織のノードはこのようなイベントに従った振る舞いを行うことも可能である。図５のＴＸ情報に含まれるＴＸイベントは、そのような分散台帳のイベント管理機能を用いた場合に発行されるイベント情報である。
＜構成情報＞

図７は、構成情報Ｄ２のデータ構造の例を示す図である。本実施例における構成情報Ｄ２は、分散台帳システム５を構成する組織やその組織に属するメンバー（ノード、管理者、ユーザなどを含む）の情報を格納したものである。

このうちチャネルＤ２０００は、分散台帳システム５にて行われる業務を示す。また、組織ＩＤ＿Ｄ２００１は、分散台帳システム５（ならびにチャネル）に参加する組織を示
す。また、メンバーＩＤ＿Ｄ２００２は参加組織中のメンバーを識別する情報である。具体的には、管理者、ノード、ユーザを識別する情報である。

こうした構成情報の例では、チャネルとして、業務Ａと業務Ｂが存在し、業務Ａには組織「Ｏｒｇ１」、「Ｏｒｇ２」、「Ｏｒｇ３」が、業務Ｂには組織「Ｏｒｇ３」、「Ｏｒｇ４」が少なくとも参加しているネットワークの状態を示している。
なお、組織は必ずしも分散台帳ノード３を持つ必要はなく、クライアントノード４を介してシステムを利用するだけの場合もある。
＜システム消費／貢献度計算ＳＣ＞

図８は、本実施例におけるシステム消費／貢献度計算ＳＣのデータ構造およびＳＣ関数の例を示す図である。なお、システム消費／貢献度計算ＳＣのデータ構造は、ステート情報１２として管理・保持される。

システム消費／貢献度計算ＳＣ内のデータ構造では、システム消費／貢献度計算に関するポリシーとして「システム消費／貢献度計算ポリシーＤ１２０」が記述されている。

また、その計算結果として「システム消費／貢献度計算結果Ｄ１２１」とさらにその結果に基づいた集計結果として「ポイント集計結果Ｄ１２２」が管理される。それぞれのデータ構造の詳細については後述する。

ここで、ＳＣ関数としては、指定した期間におけるシステム消費／貢献度を計算するための「計算処理実行」が少なくとも定義されることとする。その他、システム消費／貢献度計算ポリシーの定義変更を行うＳＣ関数や、定義あるいは各種計算結果を取得／参照するためのＳＣ関数であってもよいが、図の中では省略する。また、上述のＳＣ関数「計算処理実行」の具体的な流れについてはフローチャートを用いて後述する。
続いて図９、図１０に、上述のシステム消費／貢献度計算ＳＣ内で管理されるシステム消費／貢献度ポリシーＤ１２０のデータ構造の例を示す。

ここで示す例では、システム消費度および貢献度は、それぞれポイント（ｐｔ）という単位で定量化することとする。システム消費度および貢献度はそれぞれ別々に算出した上で、貢献度は加算ポイント、消費度は減算ポイントとして取り扱い、ポイントを合算し、各組織のポイントウォレット（仮想通貨におけるウォレットと同概念）から差し引きを行う。

これらの「ポイント」は、言い換えると本ＳＣ内における独自のトークン（仮想通貨）と捉えることもできる。参加組織間で合意を取ることができ、かつ、定量化可能であれば、この単位に限定されずどのような単位を用いてもよく、例えば、円、ドル、仮想通貨などの実在する通貨単位を用いても構わない。

図中に示すデータ構造は、ステート情報１２における情報Ｄ１１１２の内部テーブルＤ１１０４内で管理された状態を想定したものである。本実施例ではシステム消費／貢献度計算ポリシーが、計算対象となる業務チャネルやＳＣ、そのシステム消費／貢献内容に応じて複数定義されることとする。
このうちポリシーＩＤ＿Ｄ１２０−１列は、定義されたシステム消費／貢献度計算ルールを識別する情報である。
また、ＳＣ＿ＩＤ＿Ｄ１２０−２列は、対象となるＳＣを識別する情報である。本実施例ではこの指定が業務チャネルの指定も兼ねている。
また、大区分Ｄ１２０−３と小区分Ｄ１２０−４列は、計算対象となるシステム消費／貢献内容を表す分類ラベル情報である。

また、入力となる実績情報Ｄ１２０−５列は、本ポリシーのシステム消費／貢献度計算の入力として用いる実績情報であり、少なくとも計算処理（ＳＣ実行）に参加する２組織以上によって参照可能であることを想定する。

また、計算ロジックＤ１２０−６列は、本ポリシーにおけるシステム消費／貢献の具体的な計算ロジックを表す。本実施例の計算ロジックは、ＳＣの記述に用いるプログラミング言語もしくはＤｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ （ＤＳＬ）に従ったプログラムコードによって記述されることを想定する。

図中の例においては、Ｊａｖａ（登録商標）などのような一般的なオブジェクト指向言語を模擬した擬似コードを用いている。通常のプログラミング言語と同様なｆｏｒｅａｃｈやｉｆといった制御構文を利用している他、「！＝」や「＝＝」のような等価／非等価／比較演算子、「＋＝」のようなインクリメント演算子を含む四則演算表記、オブジェクト指向におけるクラス／インスタンスの表現、具体的にはオブジェクト．メンバー変数表記によるメンバー変数の参照／代入やオブジェクト．メンバー変数（引数）によるメンバー関数呼び出しなどの記法を用いている。

なお、ＳＣ内部で利用される関数は各クラスのメンバー関数として別途定義されていても良いし、計算ロジック内に記述されていてもよい（本実施例では説明が冗長になることを防ぐため、前者を想定して記載する）。

また、本実施例の計算ロジック中では、各ＳＣや区分に関するシステム貢献度と消費度の計算をひとつのポリシーの中で規定している。しかし、それぞれ別々に定義しても構わない。別々に定義したほうが管理は複雑になる反面、より細かい計算処理がしやすくなるというメリットがある。

これらの計算ポリシー（図中のＤ１２０−１１〜Ｄ１２０−１９）は、分散台帳システム５の参加者によって予め合議され、定義（デプロイ）されていることを想定する。なお、計算ポリシーは、参加者による合議の上で随時更新されても構わない。
これらの計算ポリシーを用いた具体的な計算処理については後述のフローチャートの説明にて詳細に述べる。
図１１は、上述のシステム消費／貢献度計算ＳＣ内で管理されるシステム消費／貢献度計算結果Ｄ１２２のデータ構造の例を示す図である。
図中に示すデータ構造は、ステート情報１２における情報Ｄ１１１２の内部テーブルＤ１１０４内で管理された状態を想定したものである。

このうち列Ｄ１２１−１〜Ｄ１２１−５は計算結果を識別するための情報である。計算期間Ｄ１２２−１列は、システム消費／貢献度計算ＳＣのＳＣ関数「計算処理」実行時の引数に指定した計算期間である。ポリシーＩＤ＿Ｄ１２１−２、ＳＣ＿ＩＤ＿Ｄ１２１−３列は、それぞれシステム消費／貢献度ポリシーＤ１２０のＤ１２０−１、Ｄ１２０−２列に対応する情報である。また、組織ＩＤ＿Ｄ１２１−４列は、本計算結果に対応する組織を識別する情報である。また、結果区分Ｄ１２１−５は計算結果が「貢献度」か「消費度」かを識別する情報である。

また、ポイントＤ１２１−６列は、上述のＤ１２１−１〜Ｄ１２１−５列に対応する計算結果（ポイント）を格納する。なお、ポリシーＩＤ＿Ｄ１２１−２列の特別な場合としてポリシーＩＤ以外に「合計」が登録されることし、その場合には、当該ＳＣ名、計算期間、組織、計算区分に関して、すべてのポリシーのポイント計算結果を合算した結果を示す。

続いて図１２に、システム消費／貢献度計算ＳＣ内で管理されるポイント集計結果Ｄ１２３のデータ構造の例を示す。図中に示すデータ構造は、ステート情報１２における情報Ｄ１１１２の内部テーブルＤ１１０４内で管理された状態を想定したものである。

計算期間Ｄ１２２−１列は、システム消費／貢献度計算ＳＣのＳＣ関数「計算処理」実行時の引数に指定した計算期間である。また、組織ＩＤ＿Ｄ１２２−２列は、本集計結果に対応する組織を識別する情報である。また、ポイント集計結果Ｄ１２２−３列は、計算した貢献度を加算ポイント、消費度は減算ポイントとして、ポイントを合算した集計結果である。また、Ｄ１２２−４列は、各組織のポイントを保持／管理するウォレットにおける精算前ポイント残高、また、Ｄ１２２−５列は、Ｄ１２２−４列からＤ１２２−３列の差し引きを行った後、すなわち精算後のポイント残高である。
＜処理フロー：メンバー登録＞

以降では、実施例１における利用管理方法のフロー例について説明する。実施例１では基本形として、業務取引履歴を実績情報として用いてシステム消費／貢献度計算を行う例を示す。
図１３は、分散台帳システム５に参加するメンバーの新規登録処理の例を示すフローチャートである。

この場合、分散台帳ノード３のメンバー管理部３３は、クライアントノード４等の他ノードからメンバー登録要求を受け付ける（Ｓ１０１）。ここで、メンバー登録要求には、要求メンバーを一意に識別するメンバーＩＤが含まれることとする。
上述のメンバー管理部は、秘密鍵Ｄ３１と公開鍵Ｄ３２の組を生成して、受け取ったメンバーＩＤと紐付ける（Ｓ１０２）。

次に、メンバー管理部３３は、新規登録対象となるメンバーＩＤと生成した公開鍵Ｄ３２とを他のノードにブロードキャストする（Ｓ１０３）。ブロードキャストされたメンバーＩＤと生成した公開鍵Ｄ３２の情報は、各ノード上で参加メンバー管理情報Ｄ３として保管する。

さらに、メンバー管理部３３は、メンバー登録要求を行ったノードに、生成した秘密鍵Ｄ３１を返す（Ｓ１０４）。秘密鍵Ｄ３１を受け取ったノードは、参加メンバー管理情報Ｄ３に自身の秘密鍵Ｄ３１として保管する。

本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、分散台帳システム５への参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。

具体的には、例えば、クライアントノード４の側は、発行された秘密鍵で電子署名したＴＸを発行し、検証ノード側（予め定めたいずれかのノードである）が公開鍵を用いて電子署名を検証することで、本人確認を実現できる。

なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法、鍵とＩＤを紐付ける手法については、公知または周知の技術を適用すれば良いので、本実施例１では詳述しない。

また、本実施例ではメンバー管理部３３の機能を分散台帳ノード３中に機能として示したが、外部にメンバー管理専用のノードを立ててそのノードがメンバー管理部３３と同等の機能を提供してもよい。
＜処理フロー：ＴＸ実行処理＞

続いて図１４に、ＴＸ実行処理、すなわち、ＳＣのデプロイ、実行処理のフロー例を示す。ＳＣの種別としては、業務、システム運用履歴共有、システム消費／貢献度計算等があるが、本実施例では、これらのＳＣ種別による処理の違いは、ＳＣ内部処理の違いとして表現可能であり、ＳＣにおけるＴＸ実行処理の流れ自体は共通であることとする。

この場合、分散台帳ノード３のトランザクション管理部３４が、クライアントノード４等のＴＸ発行元からＴＸを受け取り（Ｓ２０１）、これをコンセンサス管理部３１に渡して、ＴＸの種別に応じたＳＣのデプロイ、実行処理を行う。

Ｓ２０１で受け取ったＴＸがＳＣのデプロイＴＸの場合（Ｓ２０２：ＹＥＳ）、まずコンセンサス管理部３１は、他の分散台帳ノード３との間で、受け取ったＴＸを実行してよいか、ブロックとしてＢＣ１１の末尾に追加してよいかの合意形成処理を行う（Ｓ２０３）。 具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。例えば、Ｐｌａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｒｅｒａｎｃｅ（ＰＢＦＴ）と呼ばれるアルゴリズム等を採用することが考えられる。ＰＢＦＴは合意形成に参加するすべてのノード（すなわち検証ノード）の間で一定（３分の２）以上のノードによる合意を条件とするアルゴリズムである。

また別の例として、非特許文献３に開示される技術では、Ｅｎｄｏｒｓｅｒ−Ｏｒｄｅｒｅｒモデルと呼ばれる合意形成アルゴリズムが用いられる。Ｅｎｄｏｒｓｅｒ−Ｏｒｄｅｒｅｒモデルでは、分散台帳ノード３の中から、承認権限のある一部の分散台帳ノード３を選定／ＴＸを送信し、それらの選択された分散台帳ノードのみが問題がないかの検証を行い、問題がなければ承認を返す。予め決めた合意形成条件（例えば、２組織以上の承認）を満たした場合にそのＴＸを受け入れる。さらに、その承認済ＴＸを全分散台帳ノード３に配信する。Ｅｎｄｏｒｓｅｒ−Ｏｒｄｅｒｅｒモデルでは、全分散台帳ノード３がＴＸ検証を行う必要が無いため、ＰＢＦＴに比べて効率的である。

ここではＥｎｄｏｒｓｅｒ−Ｏｒｄｅｒｅｒモデルをベースとした合意形成以降の流れを簡単に説明する。分散台帳ノード３はまず受け取ったＴＸを分散台帳システム５に参加しており、ＴＸの承認権限のある分散台帳ノード３に対して送信し、ＴＸを受け取った各分散台帳ノード３でＴＸに対する署名検証を行って改ざんがされていないことやＴＸの内容の正当性を確認し、ＴＸを送信した分散台帳ノード３に対して確認結果を返却する。予め決めた合意形成条件が満たされた場合にＴＸの承認完了したこととし、確認できたことをもって合意形成が完了する。

上述の合意形成を経て、コンセンサス管理部３１は、承認済ＴＸ配信部３６の機能を用いて、全ての分散台帳ノード３に、承認済ＴＸをブロードキャストすることとなる。

承認済ＴＸを受け取ったら、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、当該ＴＸに含まれるＳＣを分散台帳Ｄ１に登録する（Ｓ２０４）。具体的には、ＴＸの内容に基づき、ＳＣ＿ＩＤやＳＣ実体を分散台帳Ｄ１上のステート情報１２として登録し、ＢＣ１１の末尾にこのデプロイＴＸを含むブロックを追加する。
最後に、コンセンサス管理部３１は、デプロイＴＸの実行結果をＴＸ発行元に返し（Ｓ２０５）、処理を終了する。

一方、Ｓ２０１で受け取ったＴＸがＳＣの実行ＴＸの場合（Ｓ２０２：ＮＯ）、分散台帳ノード３は、デプロイＴＸと同様に合意形成処理を行う（Ｓ２０６）。この合意形成処理はＳ２０３と同様である。

合意形成が完了したら、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、ＳＣを実行して分散台帳Ｄ１の内容を更新する（Ｓ２０７）。具体的には、実行ＴＸ内で指定されたＳＣ＿ＩＤを持つＳＣ（登録済みであることを前提とする）に対して、実行ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳Ｄ１の内容を更新する。実行結果に基づいて、本ＳＣに関するステート情報Ｄ１２を更新し、ＢＣの末尾のブロックとして実行ＴＸを追加する。
最後に、コンセンサス管理部３１は、この実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返し（Ｓ２０９）、処理を終了する。
＜処理フロー：システム消費／貢献度計算＞

続いて図１５に、実施例１におけるシステム全体としてのシステム消費／貢献度計算ＳＣに従った計算処理の流れを示す。なお、以降の説明では、実行／参照される各種ＳＣは既に分散台帳上にデプロイ済みであることとする。

この場合、あるノードからシステム消費／貢献度計算ＳＣのＳＣ関数「計算処理」の実行ＴＸが発行されたとする（Ｓ３０１）。そこで、各分散台帳ノード３はそのＴＸを受け取り、他ノード間で合意形成をしながら受け取った実行ＴＸに従ってシステム消費／貢献度計算ＳＣのＳＣ関数「計算処理」実行する（Ｓ３０２）。ここで、実行ＴＸのタイミングは、ＳＣの実行権限のあるいずれかの参加メンバーによって運用アプリ４２の表示画面上の操作をもって発行されてもよいし、各ノードの直接操作によってＴＸが発行されてもよい。

次に、上述の「計算処理」の具体的な内容について説明する。図１６は、システム消費／貢献度計算ＳＣのＳＣ関数「計算処理」呼び出し時の内部処理の例を示すフローチャートである。

この場合、各分散台帳ノード３は、合意形成済みの運用実行ＴＸとして、システム消費／貢献度計算ＳＣのＳＣ関数「計算処理」呼び出しを受け取る（Ｓ４０１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従ったシステム消費／貢献度計算処理を実行する。 なお、本実施例ではＳＣ関数の引数として「計算対象期間」も入力されている。具体的な内部処理を以下に示す。消費／貢献度計算の説明では、これまでに述べた「業務Ａ」を対象に具体的に説明している。

まず、分散台帳ノード３は、システム消費／貢献度計算ＳＣのステート情報「システム消費／貢献度計算ポリシー」を参照し、その中に定義された「入力となる実績情報」に基づいて、各ルールで必要となる実績情報を分散台帳から取得する（Ｓ４０２）。

図９、図１０に示したシステム消費／貢献度計算ポリシーを具体例に説明すると、ポリシーＩＤ「Ｐｏｌｉｃｙ０１」〜「Ｐｏｌｉｃｙ０７」が「業務Ａ」の実行履歴に基づくシステム消費／貢献度計算ポリシーである。また「Ｐｏｌｉｃｙ０８」「Ｐｏｌｉｃｙ０９」は「業務Ａ」のシステム運用履歴に基づく計算ポリシーなので、本実施例では利用せず実施例２にて利用する。

ここで分散台帳ノード３は、利用する「Ｐｏｌｉｃｙ０１」〜「Ｐｏｌｉｃｙ０７」の「入力となる実績情報」列を参照して、まず、「Ｐｏｌｉｃｙ０１」〜「Ｐｏｌｉｃｙ０７」共通で利用する「業務Ａ」の履歴情報一覧を取得する。以降の説明では、この一覧を「ＢｉｚＬｏｇＬｉｓｔ」とも称する。これは具体的には、分散台帳Ｄ１の業務ＳＣ＿Ｄ１１のＢＣ１１に蓄積された一連の履歴情報である（図４ではブロックＤ１００１やブロックＤ１００５など）。

さらに分散台帳ノード３は、「Ｐｏｌｉｃｙ０４」〜「Ｐｏｌｉｃｙ０６」で利用する分散台帳システム５の構成情報を取得する。以降の説明では、取得した構成情報を「Ｃｏｎｆｉｇｓ」とも称する。これは具体的には、図７の構成情報Ｄ１のうち、チャネルが「業務Ａ」であるものの集合である。なお、これらのＢｉｚＬｏｇＬｉｓｔやＣｏｎｆｉｇｓのような取得した実績情報は、ＳＣ内で操作（参照など）がしやすいように図４や図７に示すデータ構造からＳＣのプログラミング言語上のオブジェクトにマッピングされていることとする。

次に、分散台帳ノード３は、システム消費／貢献度計算ＳＣのステート情報「システム消費／貢献度計算ポリシー」に定義された「計算ロジック」とＳ４０２で取得した実績情報に基づいて、各ポリシーに従い、組織ごとのシステム消費度と貢献度を計算する（Ｓ４０３）。以下では、各ポリシーについてそれぞれ説明する。
＜Ｐｏｌｉｃｙ０１：ＴＸ実行処理量＞

本計算ポリシーは、「業務Ａ」のＴＸ量に関するシステム消費／貢献度計算ポリシーの一例である。この例では、「業務Ａ」のＴＸを発行した組織が分散台帳システム５のリソースやデータ（以下、システム）を消費し、一方そのＴＸ実行処理のためにノードやデータを提供した組織がシステムに貢献したというポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である業務Ａの履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。

次に分散台帳ノード３は、ＢｉｚＬｏｇのタイムスタンプ（例：図４におけるブロックＤ１００５のＴＸ情報中のタイムスタンプに対応）を参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、もし含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、もし含まれる場合、分散台帳ノード３は、このＢｉｚＬｏｇのＴＸ種別（例：図４におけるブロックＤ１００５のＴＸ情報中のＴＸ種別に対応）が実行あるいはデプロイであるかを確認する。

もし実行あるいはデプロイでなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、実行あるいはデプロイの場合には、分散台帳ノード３は、ＢｉｚＬｏｇ中のＴＸ発行者とＴＸ実行／承認者を参照する（例：それぞれ図４のブロックＤ１００５のＴＸ情報中のＴＸ発行者（電子署名情報を含む）とＴＸ実行／承認者（電子署名情報を含む）に対応）。

そして分散台帳ノード３は、取得した各ＴＸ実行／承認者がＴＸ発行者と一致しない場合に、ＴＸ実行／承認者の所属する組織の貢献度の１０ｐｔ加算、ＴＸ発行者の所属する組織の消費度の１０ｐｔ加算を繰り返す。例えば、あるＢｉｚＬｏｇでＴＸ発行者が「組織Ａ」ユーザで、ＴＸ実行／承認者が「組織Ａ」「組織Ｂ」「組織Ｃ」の各ユーザだった場合には、「組織Ａ」の消費度が２０ｐｔ、「組織Ｂ」と「組織Ｃ」の貢献度がそれぞれ１０ｐｔとなる。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０２：ＴＸ参照処理量＞

本計算ポリシーは、上述の「業務Ａ」のＴＸ量に関するシステム消費／貢献度計算ポリ
シーの一例である。この例では、「業務Ａ」のＴＸを発行した組織がシステムを消費し、一方そのＴＸ参照処理のためにノードを提供した組織がシステムに貢献したというポリシーが規定されている。

通常、ＴＸ実行に比べて処理コスト少ないため、付与されるポイント量は、上述のＰｏｌｉｃｙ０１に比べて少ない。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。
次に分散台帳ノード３は、ＢｉｚＬｏｇのタイムスタンプを参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、もし含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する処理をスキップする。他方、もし含まれる場合、分散台帳ノード３は、このＢｉｚＬｏｇのＴＸ種別が参照であるかを確認する。

もし参照でなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、参照の場合、分散台帳ノード３は、ＢｉｚＬｏｇ中のＴＸ発行者とＴＸ実行／承認者を参照する。

そして、取得した各ＴＸ実行／承認者がＴＸ発行者と一致しない場合、分散台帳ノード３は、ＴＸ実行／承認者の所属する組織の貢献度の２ｐｔ加算、ＴＸ発行者の所属する組織の消費度の２ｐｔ加算を繰り返す。例えば、あるＢｉｚＬｏｇでＴＸ発行者が「組織Ａ」ユーザで、ＴＸ実行／承認者が「組織Ｂ」のユーザだった場合には、「組織Ａ」の消費度が２ｐｔ、「組織Ｂ」の貢献度がそれぞれ２ｐｔとなる。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０３：承認済ＴＸ配信処理量＞

本計算ポリシーは、上述の「業務Ａ」のＴＸ量に関するシステム消費／貢献度計算ポリシーの一例である。この例では「業務Ａ」のＴＸを発行した組織がシステムを消費し、一方そのＴＸ承認後に各組織にそのＴＸを各ノードに配信するためにノードを提供した組織がシステムに貢献したというポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。
次に分散台帳ノード３は、ＢｉｚＬｏｇのタイムスタンプを参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、もし含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、含まれる場合、分散台帳ノード３は、このＢｉｚＬｏｇのＴＸ種別が実行あるいはデプロイであるかを確認する。

もし実行あるいはデプロイでなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、実行あるいはデプロイの場合、分散台帳ノード３は、ＢｉｚＬｏｇ中のＴＸ発行者と承認済ＴＸ配信者（例：図４におけるブロックＤ１００５のＴＸ情報中の承認済ＴＸ配信者（電子署名情報含む））を参照する。

そして分散台帳ノード３は、取得した承認済ＴＸ配信者がＴＸ発行者と一致しない場合に、承認済ＴＸ配信者の所属する組織の貢献度を２ｐｔ加算、ＴＸ発行者の所属する組織消費度を２ｐｔ加算する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０４：ＴＸイベント通知処理量＞

本計算ポリシーは、上述の「業務Ａ」のＴＸ量に関するシステム消費／貢献度計算ポリシーの一例である。この例ではＴＸイベント発行時に、各組織にそのＴＸイベントを各ノードに配信するためにノードを提供した組織がシステムに貢献、イベントを受け取った組織がシステムを消費したこととするポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。
次に分散台帳ノード３は、ＢｉｚＬｏｇのタイムスタンプを参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、もし含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、判定の結果、含まれる場合、分散台帳ノード３は、このＢｉｚＬｏｇのＴＸ種別が実行で、かつＢｉｚＬｏｇがＴＸイベント（例： 図４ Ｄ１００５のＴＸ情報中のＴＸイベント）を含むかを確認する。

上述の確認の結果、もし上記がみたされなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、みたされる場合、分散台帳ノード３は、Ｃｏｎｆｉｇｓの中から業務Ａに関するノード所有者を取得する。
この情報は図７のチャネルが「業務Ａ」かつ「メンバーＩＤ」が「ノード」を含む「組織」を抽出することで取得できる。

さらに分散台帳ノード３は、ＢｉｚＬｏｇ中の承認済ＴＸ配信者を参照する。そして、各ノード所有者の組織の消費度を０．１ｐｔ加算し、さらにノード所有者の数だけ、承認済ＴＸ配信者の所属する組織の貢献度を０．１ｐｔ加算する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０５：ＳＣ登録業務運用＞

本計算ポリシーは、業務運用に関するシステム消費／貢献度計算ポリシーの一例である。この例ではＳＣ登録／更新時に、対象となるＳＣを開発／業務運用したと考えられるＴＸ発行者が所属した組織がシステムに貢献、一方、そのＳＣを受け取ってノードを所有する組織がシステムを消費したこととするポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。

次に分散台帳ノード３は、ＢｉｚＬｏｇのＴＸ種別がデプロイかどうかを確認する。この確認の結果、デプロイでなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続
の処理をスキップする。他方、デプロイの場合、分散台帳ノード３は、Ｃｏｎｆｉｇｓの中から業務Ａに関するノード所有者をＰｏｌｉｃｙ０４と同様に取得する。

さらに分散台帳ノード３は、ＢｉｚＬｏｇ中のＴＸ発行者を参照する。そして、各ノード所有者の組織の消費度を１０ｐｔ加算し、さらにノード所有者の数だけ、ＴＸ発行者の所属する組織の貢献度を１０ｐｔ加算する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０６：台帳データ保存量＞

本計算ポリシーは、データ保存量に関するシステム消費／貢献度計算ポリシーの一例である。この例では実行ＴＸを発行して分散台帳の履歴（ＢＣ）より多くのデータを蓄積した組織が、システムの運用に貢献したこととするポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。

次に分散台帳ノード３は、ＢｉｚＬｏｇのＴＸ種別が実行かどうかを確認する。もし実行でなければ、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。 他方、もし実行の場合、分散台帳ノード３は、Ｃｏｎｆｉｇｓの中から「業務Ａ」に関するノード所有者をＰｏｌｉｃｙ０４と同様に取得する。

さらに分散台帳ノード３は、ＢｉｚＬｏｇ中のＴＸ発行者を参照する。そして、各ノード所有者の組織の貢献度を１ｐｔ加算し、さらにノード所有者の数（つまり、複製の数）だけ、ＴＸ発行者の所属する組織の消費度を１ｐｔ加算する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０７：登録情報の利活用＞

本計算ポリシーは、上述の「業務Ａ」に関する情報利活用に関するシステム消費／貢献度計算ポリシーの一例である。ＳＣによって分散台帳に登録された情報は、誰かに参照された場合に、他者にとって情報共有した価値があるとみなすことができる。

そこでこの例では、各ＴＸのＲＷセットを確認して、参照された場合にはそのＴＸ発行者は情報利用、すなわちシステムを消費、その情報提供者、すなわち、参照された情報に対する更新を行ったＴＸ発行者がシステムに貢献したというポリシーを規定している。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

まず分散台帳ノード３は、ＢｉｚＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の履歴情報を１件取得する。以下、取得した履歴情報をＢｉｚＬｏｇと呼ぶ。
次に分散台帳ノード３は、ＢｉｚＬｏｇのタイムスタンプを参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、含まれる場合、分散台帳ノード３は、このＢｉｚＬｏｇのＲＷセット（例：図４におけるブロックＤ１００５のＴＸ情報中のＲＷセットに対応）を取得する。

分散台帳ノード３は、ここで取得した各ＲＷ行に対して、ＲＷ区分が「Ｒ」かどうかを判定する。この判定の結果、「Ｒ」だった場合、分散台帳ノード３は、その行に記載された情報を過去に更新したことがある各ＴＸ発行者に貢献度を付与する。

具体的には当該ＲＷ行のＫｅｙ情報を元に、ＢｉｚＬｏｇＬｉｓｔの中から、Ｋｅｙの更新すなわちＲＷ区分が「Ｗ」の履歴（更新履歴）をすべて抽出する。そして、その更新履歴のＴＸのＴＸ発行者の所属する組織の貢献度を加算する。なおそのポイント数値は１０ｐｔをベースに、更新した世代が古くなるにつれて半減することとしている。この貢献度と同一のポイント分だけ、ＢｉｚＬｏｇの（すなわち情報を参照した）ＴＸ発行者の所属する組織の消費度を加算する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。

上記のとおり、図１６のフローにおけるＳ４０３による各ポリシーのシステム消費／貢献度計算を実施した後で、分散台帳ノード３は、この計算結果を用いて、システム消費／貢献度計算ＳＣのステート情報「システム消費／貢献度計算結果」を追記／更新する（Ｓ４０４）。その際には各ポリシーのシステム消費／貢献度計算結果だけでなく、業務ごとの各組織のシステム消費／貢献度の合算結果もあわせて登録する。

さらに分散台帳ノード３は、上述のＳ４０４の結果を用いて各組織の最終的なポイント集計処理を行い、その結果に基づいて、システム消費／貢献度計算ＳＣのステート情報「ポイント集計結果」を追記／更新する（Ｓ４０５）。

本実施例では、ポイント集計処理として、例えば、計算対象期間における各組織のすべてのシステム貢献度と消費度をそれぞれ合計し、それぞれ加算ポイント、減算ポイントとして、ポイントを集計する。この集計結果を出力して、各組織に対する課金請求／報酬額として提示してもよい。あるいは組織ごとにポイント用のウォレットを用意しておき、ポイント集計結果に基づいて、ウォレットからポイントを加減算して精算まで行ってもよい。
最後に分散台帳ノード３は、本ＳＣの実行結果を返し（Ｓ４０６）、処理を終了する。

以上で示したとおり、本実施例によれば、複数の組織が合意／同期しながら、共通のロジックを実行可能な分散台帳上のＳＣとして、システム消費／貢献度の計算ロジックを実行し、さらに信ぴょう性の不明な自己申告情報ではなく、客観性を持つ情報として、分散台帳に格納された履歴情報を活用することで、複数の組織による相互計算／検証を実現する。複数のノードが同じコピー（分散台帳）を持っていることを逆手に取ることで、クロスチェックで信ぴょう性を担保することができる。このような特徴を持つ本実施例の構成を用いれば、複数組織／管理ドメインにまたがったリソース等を持ち寄って構成される分散台帳システムにおいて、各組織のシステム消費／貢献度を公平／公正に計算でき、この計算結果を活用することでシステム課金や報酬分配を組織横断で公平に実現できる効果がある。

なお、本実施例では、簡単のために１ブロックあたり１トランザクションを格納する例を示しているが、複数トランザクションを格納しても構わない。本発明はその場合にも適用可能である。

また本実施例では、計算時に加減算するポイント数値として固定値を利用しているが、予め決めたポリシーに基づいて変動させてもよい。例えば、実際のリソースやデータの利用量やサービス利用料金に基づいて決めても良い。そのような場合には、例えば、監視ツ
ールや監視エージェントなどで計測した結果も併せて分散台帳に記録すれば実現可能である。

また構成情報Ｄ２は、分散台帳ノード３の機能の中で管理するデータとして記載しているが、ＳＣ上で管理してもよい。複数の組織で構成情報が確認できればそのような方法でも構わない。

また、システム貢献度／計算ポリシーＤ１２０における計算ロジックは、メタ言語やＤｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ（ＤＳＬ）として、引数の中で定義しても良いし、予め、ＳＣ関数の中に埋め込んでもよい。メタ言語化することで外部定義が可能となり、柔軟性が高まるメリットがある。一方、ＳＣ関数の中で埋め込むと管理が容易になるというメリットがある。
−−−実施例２−−−
以降では、他の実施例として実施例２について説明する。ただし実施例１をベースとするため、共通部分の説明は省略する。

実施例２は、実施例１と同様の業務取引履歴（実行履歴）に加えて、システム運用履歴も実績情報として用いてシステム消費／貢献度計算を行う例を示す。実施例１とは、システム運用履歴共有ＳＣ＿Ｄ１２を用い、さらに図９中のポリシー「Ｐｏｌｉｃｙ０８」「Ｐｏｌｉｃｙ０９」を用いる点が異なる。それ以外の処理は基本的に共通である。
ここでは、図１６で示したシステム消費／貢献度計算ＳＣのＳＣ関数「計算処理」呼び出し時の内部処理における実施例１との差分について述べる。

まず、分散台帳ノード３は、Ｓ４０２における各ルールで必要となる実績情報を分散台帳から取得として、ＢｉｚＬｏｇＬｉｓｔとＣｏｎｆｉｇｓに加えて、ポリシーＩＤ「Ｐｏｌｉｃｙ０８」「Ｐｏｌｉｃｙ０９」で必要となる「業務Ａ」のシステム運用履歴一覧を取得する。以降の説明では、この一覧を「ＯｐｓＬｏｇＬｉｓｔ」とも称する。これは具体的には、分散台帳Ｄ１のシステム運用履歴共通ＳＣ＿Ｄ１３のＢＣ１１に蓄積された一連の履歴情報である（図４ではブロックＤ１００２やブロックＤ１００６など）。

次に、分散台帳ノード３は、Ｓ４０３における組織ごとのシステム消費度と貢献度を計算する処理において、以下のシステム運用履歴に関する各ポリシーも追加実行する。
＜Ｐｏｌｉｃｙ０８：システム運用実行＞

本計算ポリシーは、システム運用に関するシステム消費／貢献度計算ポリシーの一例である。この例では、「業務Ａ」に関するシステム運用作業（例えば、「業務Ａ」用に管理するノードや分散台帳に関する組織間で共有するべき運用作業）に関して、システム運用履歴共有ＳＣに関して実行ＴＸを発行した組織、すなわち運用作業を実行した組織がシステムに貢献し、一方それに対して、その他の参加組織が対価を払う（言い換えるとシステムを消費した）というポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＯｐｓＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の運用に関する履歴情報を１件取得する。以下、取得した履歴情報をＯｐｓＬｏｇと呼ぶ。

次に分散台帳ノード３は、ＯｐｓＬｏｇのタイムスタンプ（例：図４におけるブロックＤ１００６のＴＸ情報中のタイムスタンプに対応）を参照し、ＳＣ関数の引数に指定した「計算対象期間」に含まれているかを判定する。

上述の判定の結果、含まれない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。他方、含まれる場合、分散台帳ノード３は、このＯｐｓＬｏｇのＴＸ発行者を取得する（例：図４におけるブロックＤ１００６のＴＸ情報中のＴＸ発行者（電子署名情報を含む）に対応）。
そして分散台帳ノード３は、取得したＴＸ発行者の所属する組織の貢献度に１０ｐｔ加算する。

続いて分散台帳ノード３は、Ｃｏｎｆｉｇｓの中から「業務Ａ」に関するノード所有者をＰｏｌｉｃｙ０４と同様に取得して、その組織の間で１０ｐｔを均等負担、言い換えると消費度の加算を行う。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
＜Ｐｏｌｉｃｙ０８：台帳バックアップデータ保存量＞

本計算ポリシーは、バックアップデータ保存量に関するシステム消費／貢献度計算ポリシーの一例である。この例では、「業務Ａ」に関する台帳のバックアップデータ保存量に関して、システム運用履歴共有ＳＣに関して実行ＴＸを発行した組織、すなわちバックアップ作業を実行してバックアップデータを保持している組織がシステムに貢献し、一方それに対して、その他の参加組織が対価を払う（言い換えるとシステムを消費した）というポリシーが規定されている。本ポリシー中の「計算ロジック」列に記載されたロジックに従った具体的な計算処理を説明する。

この場合、分散台帳ノード３は、まずＯｐｓＬｏｇＬｉｓｔの中から計算に未使用である「業務Ａ」の運用に関する履歴情報を１件取得する。以下、取得した履歴情報をＯｐｓＬｏｇと呼ぶ。

次にＯｐｓＬｏｇのＳＣ引数に含まれる運用作業ＩＤ（例：図４におけるブロックＤ１００６のＴＸ情報中の「呼び出し関数＋入力引数）の第一引数に対応）を参照し、運用作業が「台帳データバックアップ」であるかを判定する。
上述の判定の結果、「台帳データバックアップ」でない場合、分散台帳ノード３は、本ＢｉｚＬｏｇに関する後続の処理をスキップする。
他方、「台帳データバックアップ」である場合、分散台帳ノード３は、このＯｐｓＬｏｇのＴＸ発行者を取得する。
そして分散台帳ノード３は、取得したＴＸ発行者の所属する組織の貢献度に１００ｐｔ加算する。

続いて分散台帳ノード３は、Ｃｏｎｆｉｇｓの中から「業務Ａ」に関するノード所有者をＰｏｌｉｃｙ０４と同様に取得して、その組織の間で１００ｐｔを台帳データ消費量のうちその組織が占める割合で負担、言い換えると消費度の加算を行う。なお、データ消費量の計算は、Ｐｏｌｉｃｙ０６と同様の方法で行えば良いので詳細は割愛する。
分散台帳ノード３は、これらの処理を、取得した履歴情報分繰り返すことで本ポリシーにおける各組織のシステム消費度と貢献度を計算する。
−−−実施例３−−−
実施例３は、分散台帳システム５で複数の業務を管理する場合に、業務横断でのシステム消費／貢献度計算も行う例を示す。

図１７に、実施例３で想定する分散台帳システム５を模式的に示す。本分散台帳システム５は、基本的に実施例１、実施例２と同じであるが、分散台帳Ｄ１において業務ごとにサブ台帳５０を管理している点が異なる。

なお、「業務Ａ」に関するサブ台帳５０＿１においては、ＳＣとして業務ＳＣ＿Ｄ１１、システム消費／貢献度計算ＳＣ＿Ｄ１２、システム運用履歴共有ＳＣ＿Ｄ１３を、実施例１と同様に備えている。一方、「業務Ｂ」に関するサブ台帳５０＿２においては、ＳＣとしてＤ４１〜Ｄ４３が備わっている。

さらに本実施例の分散台帳ノード３は、業務横断のサブ台帳５５を備え、そこでは、上述の「業務Ａ」と「業務Ｂ」の業務横断システム消費／貢献度計算ＳＣ＿Ｄ５が管理される。なお「業務Ａ」、「業務Ｂ」のサブ台帳５０＿１、５０＿２は、それぞれの業務に参加する組織のみにアクセス権が付与され、分散台帳上で共有／参照／実行可能とする。そのため業務チャネルに参加していない組織は参照不可である。

一方、本実施例の業務横断システム消費／貢献度計算ＳＣ＿Ｄ５は、全組織がアクセス可能とする。上述の「業務Ａ」、「業務Ｂ」の両業務に参加している組織が、本ＳＣによる計算処理を実行することで、組織跨ぎであっても相互計算による信ぴょう性や公平性の確保が可能である。

図１８に、本実施例における業務横断システム消費／貢献度計算ＳＣの内部処理のフロー例を示す。ここで示すフローは、「業務Ａ」のシステム消費／貢献度計算ＳＣ＿Ｄ１２の代わりに、業務横断システム消費／貢献度計算ＳＣ＿Ｄ４を用いる以外は、基本的な処理の流れは実施例１や実施例２と同様である（Ｓ４０１〜Ｓ４０６がＳ５０１〜Ｓ５０６に対応）。

なお、計算実行前の前提条件として、「業務Ａ」と「業務Ｂ」のシステム消費／貢献度計算が完了していることとする（あるいは業務横断システム消費／貢献度計算ＳＣ＿Ｄ４実行を契機に各業務のシステム消費／貢献度計算ＳＣが起動されて計算されてもよい）。
この場合、分散台帳ノード３は、Ｓ５０２の実績情報の取得において、例えば、各業務のシステム消費／貢献度計算結果やポイント集計結果を用いる。

さらに分散台帳ノード３は、Ｓ５０３において、例えば、各組織のシステム消費／貢献度あるいはポイント集計結果を業務間で相殺することで、業種横断でのシステム消費／貢献度計算結果やポイント集計結果を計算する。具体的には、例えば、「業務Ａ」と「業務Ｂ」のいずれも行っている或る組織が分散台帳で保持するデータ量に関し、ポイントを計算する場合、「業務Ａ」と「業務Ｂ」のいずれに関して計算しても、基本的に同じ対象に基づき計算することになる。そこで、この組織の分散台帳のデータ量に関するポイントとしては、「業務Ａ」と「業務Ｂ」のそれぞれについて計算した値の集計値から、一方の計算値を差し引きする、といった処理を想定できる。これは、「業務Ａ」と「業務Ｂ」で共通するトランザクションが発生しているケースでも同様に想定できる。
このように実施例３を用いれば、組織跨ぎであっても相互計算による信ぴょう性や公平性の確保できるという効果がある。

以上で示したとおり、本発明を用いることで、各種計算ポリシーの説明にて示した通り、ＴＸ量、業務運用、データ保存量、情報利活用、システム運用、バックアップデータ量などの様々な観点でのシステム消費／貢献度を計算することができるという効果がある。これにより、システム消費／貢献度状況をより詳細かつ厳密に反映して管理可能となる。

なお、本発明は貢献／消費の両方の行う参加者に限定されない。すなわち、リソースやデータの提供やシステム運用だけを行う組織があってもよいし、利用／消費だけを行う組織があっても良い。

記載した本発明の実施例では、ＳＣ ＩＤごとにシステム貢献度／消費度計算ポリシー
を規定しているが、この形態に限定されない。計算ポリシーは対象ＳＣおよびその関数ごとに規定してもよいし、逆に複数のＳＣで共通の計算ポリシーがあってもよいし、それらを組み合わせても構わない。

記載した本発明の実施例では、ＴＸ発行のたびに、参照トランザクションもＢＣ上に登録することを想定しているが、参加者が客観的に実績を確認できるのであれば、別な手段を用いても良い。例えば、各組織のローカルに保持する実行ログをまとめて別の履歴情報としてＢＣに登録しても構わない。

記載した本発明の実施例では、組織ごとのシステム消費／貢献度を計算しているが、これは組織ごとではなく参加メンバーごとに算出してもよい。参加メンバーごとにシステム消費／貢献度を計算すれば、より詳細なシステム消費／貢献内訳を管理でき、さらに参加メンバー同士（すなわち個と個）でのシステム消費／貢献度に関するポイント交換（言い換えるなら仮想通貨のＰ２Ｐ取引）を行うことができる。

記載した本発明の実施例では、貢献度と消費度は同等の価値（同一レート）としている。また、実施例３において、サブ台帳間でのポイントも同等の価値としているが、これはポイント間に変換レートを設定してもよい。変換レートも予め、システム消費／貢献度計算ＳＣの中で定義しておくとよい。

本発明は、コンソーシアム型で運営する分散台帳システムに対するシステム消費／貢献度管理に最も有効ではあるが、複数組織でまたがってリソースやデータを持ち寄りながら運営するようなシステム全般に適用可能（例：グリッドコンピューティング）である。ただし、管理対象システムの利用／貢献に関わる実績情報（例えば、稼働ログ）が分散台帳上に共有／蓄積されることを想定する。その場合には、管理対象となる分散処理（業務）を実行するノードと分散台帳ノードが分離していてもよい。例えば管理対象となるシステムに関するＴＸ発行のたびにクライアント側とサーバ側でそれぞれ同一の稼働ログを出力し、そのログに基づいた実績情報を分散台帳上に蓄積するようにすれば、実績情報の客観性も分散台帳システムの場合並に高めることができる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、分散台帳システムにおいてコンソーシアムを形成する各組織に関して、互いに合意／同期することで信憑性が担保されるＳＣとして、分散台帳システムを含みうる所定の管理対象システムの消費と貢献のそれぞれについて的確に捕捉し、その情報を用いた公平、公正な課金管理が実現されることとなる。

すなわち、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況を的確に把握し、活用可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記第１のスマートコントラクトを実行することで、前記複数の組織のノード間で合意形成して受け入れたトランザクションの情報を処理履歴として分散台帳に格納し、前記第２のスマートコントラクトの実行に際し、前記計算に関して、前記分散台帳における前記処理履歴にアクセス可能な他組織のノードとの間で合意形成して、前記計算結果を前記分散台帳に格納する、としてもよい。

これによれば、トランザクションの処理、格納、および、これを用いた計算、のいずれについても、所定のノード間での合意形成を経て適宜な真正性が担保された状況で実行で
きることとなる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記第２のスマートコントラクトの実行に際し、所定の記憶装置で保持する、前記複数の組織それぞれの属性を示す構成情報と、前記処理履歴が示す、当該トランザクションの発行者、承認者、実行者、当該トランザクションの参照対象ないし更新対象、当該トランザクションの発行イベントの受信者、の少なくともいずれかの情報とに基づき、前記消費度および前記貢献度の少なくともいずれかに関わる組織の処理履歴を特定し、当該特定した処理履歴が示す情報により、当該組織に関して前記消費度および前記貢献度の少なくともいずれかを計算する、としてもよい。

これによれば、トランザクションの処理履歴のうち消費度や貢献度の計算に用いるべきものの特定・抽出を、より効率的で確かなものとできる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記第２のスマートコントラクトの実行に際し、前記処理履歴から、トランザクション量および当該トランザクションの実行に要したリソース消費量、データ保存量、業務ないしシステムの運用の負荷、バックアップデータの保持量、および、データ利活用実績、の少なくともいずれかの項目について集計し、この結果に基づいて前記消費度および貢献度の少なくともいずれかを計算する、としてもよい。

これによれば、消費度や貢献度の計算に必要となる情報を効率的に用意し計算に利用することができる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記処理履歴を特定するに際し、前記処理履歴に記録された組織の署名情報を用いて、前記複数の組織それぞれに関して処理履歴を特定する、としてもよい。

これによれば、分散台帳において格納されているトランザクションの処理履歴のうち、計算に用いるべきものを署名をキーに簡便に特定・抽出できることとなる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記計算した消費度および貢献度の少なくともいずれかを、組織間で交換可能な所定のトークンに変換し、当該トークンを介して当該組織における貢献度または消費度の大きさに応じた所定の精算処理を更に実行する、としてもよい。

これによれば、分散台帳システムとの親和性が高い仮想通貨等をトークンとして用いることで、コンソーシアム型分散台帳システムの構成員である各組織のシステム利用料の徴収を効率的に行うことができる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況を的確に把握し、より活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記管理対象システムで実行される業務ごとに前記分散台帳を管理しており、前記複数の組織それぞれに関する、前記消費度および前記貢献度の少なくともいずれかの計算を前記業務ごとに実行し、前記計算した、前記複数の組織それぞれの前記業務ごとの、前記消費度および前記貢献度の少なくともいずれかを、前記管理対象システムにおける全業務に関して、業務間での重複を相殺しつつ集計し、業務横断での消費度および貢献度の少なくともいずれかを計算する、としてもよい。

これによれば、或る組織が複数の業務を前記管理対象システムにて行っている状況に対応して、精度良く消費度や貢献度の計算を行うことができる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

また、本実施形態の利用管理方法において、前記複数ノードそれぞれが、前記消費度および前記貢献度の少なくともいずれかの計算ルールを、前記第２のスマートコントラクトおよび当該スマートコントラクトの持つ関数ごとに保持し、当該計算ルールに従って、前記消費度および前記貢献度の少なくともいずれかを計算する、としてもよい。

これによれば、例えば、業務や組織ごとに上述の計算ルールを規定し、第２のスマートコントラクトの実行に適用することが可能となる。ひいては、コンソーシアム型分散台帳システムの構成組織における共同利用対象となるシステムに関して、その利用状況ならびに貢献状況をより的確に把握し、活用可能となる。

１ ネットワーク
２ 物理的な通信回線
３ 分散台帳ノード
５ コンソーシアム型分散台帳システム
１０ 利用管理システム
１００ Ｉ／Ｆ
１０１ プロセッサ
１０２ メモリ
１０２１ プログラム
１０２２ データ
１０３ データバス
１０４ 補助記憶装置
３１ コンセンサス管理部
３２ スマートコントラクト実行／管理部（ＳＣ実行／管理部）
３３ メンバー管理部
３４ トランザクション管理部
３５ トランザクション発行部
３６ 承認済トランザクション配信部
３７ ネットワークプロトコル部
４ クライアントノード
４１ 業務アプリ
４２ 管理アプリ
５０ サブ台帳
５５ 業務横断のサブ台帳
Ｄ１ 分散台帳
Ｄ１１，Ｄ４１ 業務スマートコントラクト（業務ＳＣ）
Ｄ１２，Ｄ４２ システム消費／貢献度計算スマートコントラクト（システム消費／貢献度計算ＳＣ）
Ｄ１３，Ｄ４３ システム運用履歴共有スマートコントラクト（システム運用履歴共有ＳＣ）
Ｄ２ 構成情報
Ｄ３ 参加メンバー管理情報
Ｄ５ 業務横断システム消費／貢献度計算スマートコントラクト（業務横断システム消費／貢献度計算ＳＣ）

Claims (10)

1. 複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定の複数ノードそれぞれが、
   前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置を備え、
   前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、
   前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する、
   ことを特徴とする利用管理方法。
2. 前記複数ノードそれぞれが、
   前記第１のスマートコントラクトを実行することで、前記複数の組織のノード間で合意形成して受け入れたトランザクションの情報を処理履歴として分散台帳に格納し、
   前記第２のスマートコントラクトの実行に際し、前記計算に関して、前記分散台帳における前記処理履歴にアクセス可能な他組織のノードとの間で合意形成して、前記計算結果を前記分散台帳に格納する、
   ことを特徴とする請求項１に記載の利用管理方法。
3. 前記複数ノードそれぞれが、
   前記第２のスマートコントラクトの実行に際し、所定の記憶装置で保持する、前記複数の組織それぞれの属性を示す構成情報と、前記処理履歴が示す、当該トランザクションの発行者、承認者、実行者、当該トランザクションの参照対象ないし更新対象、当該トランザクションの発行イベントの受信者、の少なくともいずれかの情報とに基づき、前記消費度および前記貢献度の少なくともいずれかに関わる組織の処理履歴を特定し、当該特定した処理履歴が示す情報により、当該組織に関して前記消費度および前記貢献度の少なくともいずれかを計算する、
   ことを特徴とする請求項２に記載の利用管理方法。
4. 前記複数ノードそれぞれが、
   前記第２のスマートコントラクトの実行に際し、前記処理履歴から、トランザクション量および当該トランザクションの実行に要したリソース消費量、データ保存量、業務ないしシステムの運用の負荷、バックアップデータの保持量、および、データ利活用実績、の少なくともいずれかの項目について集計し、この結果に基づいて前記消費度および貢献度の少なくともいずれかを計算する、
   ことを特徴とする請求項３に記載の利用管理方法。
5. 前記複数ノードそれぞれが、
   前記処理履歴を特定するに際し、前記処理履歴に記録された組織の署名情報を用いて、前記複数の組織それぞれに関して処理履歴を特定する、
   ことを特徴とする請求項３に記載の利用管理方法。
6. 前記複数ノードそれぞれが、
   前記計算した消費度および貢献度の少なくともいずれかを、組織間で交換可能な所定のトークンに変換し、当該トークンを介して当該組織における貢献度または消費度の大きさに応じた所定の精算処理を更に実行する、
   ことを特徴とする請求項１に記載の利用管理方法。
7. 前記複数ノードそれぞれが、
   前記管理対象システムで実行される業務ごとに前記分散台帳を管理しており、
   前記複数の組織それぞれに関する、前記消費度および前記貢献度の少なくともいずれかの計算を前記業務ごとに実行し、
   前記計算した、前記複数の組織それぞれの前記業務ごとの、前記消費度および前記貢献度の少なくともいずれかを、前記管理対象システムにおける全業務に関して、業務間での重複を相殺しつつ集計し、業務横断での消費度および貢献度の少なくともいずれかを計算する、
   ことを特徴とする請求項１に記載の利用管理法。
8. 前記複数ノードそれぞれが、
   前記消費度および前記貢献度の少なくともいずれかの計算ルールを、前記第２のスマートコントラクトおよび当該スマートコントラクトの持つ関数ごとに保持し、当該計算ルールに従って、前記消費度および前記貢献度の少なくともいずれかを計算する、
   ことを特徴とする請求項１に記載の利用管理方法。
9. 複数の組織それぞれのノードで構成された分散台帳システムにおける、前記ノードのうち少なくとも所定の複数ノードを含むシステムであり、
   前記複数ノードが、
   前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置と、
   前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する演算装置と、
   を有するものである、
   ことを特徴とする利用管理システム。
10. 複数の組織それぞれのノードで構成された分散台帳システムにおける、前記ノードのうちの所定ノードであって、
    前記ノードの間での合意形成を経てスマートコントラクトがデプロイされた分散台帳、を保持する記憶装置と、
    前記スマートコントラクトのうち、前記分散台帳システムにおける前記組織のいずれかによる所定業務の業務処理または当該業務処理に伴うシステム運用処理に関する各トランザクションの処理履歴を、当該組織の識別情報と紐付けて前記分散台帳に格納する第１のスマートコントラクトを実行し、前記スマートコントラクトのうち、前記複数の組織によって共同利用される管理対象システムに関して、前記分散台帳に格納されている前記処理履歴のうち、所定業務に関するものが示す、前記業務処理及び前記システム運用処理の各トランザクションの発行者、承認者、及び実行者のそれぞれに関する、前記管理対象システムの運用への貢献度と当該管理対象システムのリソースの消費度の各値を規定する計算ロジックを規定した、第２のスマートコントラクトを実行し、前記組織それぞれに関して、前記貢献度の値から前記消費度の値を差引する処理を前記処理履歴ごとに繰り返し、組織それぞれの貢献状況である計算結果を得て前記分散台帳に格納する演算装置と、
    を有することを特徴とするノード。

Images