JP2020064460A - クラウドデザイン管理方法、クラウドデザインデータベース及びクラウドデザイン管理プログラム - Google Patents

Abstract

【課題】エコノミーモデルを有する分散型クラウドデザインデータベースを実現し、クラウドデザイン管理に係る正当性及び透明性の担保を解決すべき課題とする。【解決手段】分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行手段と、前記設計情報に係る類似度及び評価値を決定する鑑定手段と、前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量と、前記分散ネットワークへの参加者に対する前記トークンの配布量と、を決定する融通手段と、を有することを特徴とするクラウドデザインデータベースを実現する。【選択図】図１

Description

本発明は、クラウドデザイン管理方法、クラウドデザインデータベースおよびクラウドデザイン管理プログラムに関する。

生産手法の共有による限界費用ゼロ社会の実現は、情報化社会における潮流の１つと認識されている。クラウドサービスの構築（生産）を例に挙げるならば、サービスを構築するためのシステム情報の決定は、当該生産における参入障壁の構成因子であり、クラウドデザインの導入による当該参入障壁の低下が、既に試みられている。

クラウドデザインとは、クラウドコンピューティングを利用するシステムアーキテクチャにおける設計方法や問題解決策が、Ｋｎｏｗ―Ｈｏｗとして、暗黙知から形式知へと、変換／整理されたテンプレート情報を指し、クラウドデザインパターンとも称される。

クラウドコンピューティングとは、共用の構成可能なコンピューティングリソース（ネットワーク、サーバ、ストレージ、アプリケーション、サービス）の集積に、どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデルであり、最小限の利用手続きまたはサービスプロバイダとのやりとりで速やかに割当てられ提供されるものである（非特許文献１）。

クラウドデザインを用いたシステムアーキテクティングは、クラウドコンピューティングにおける長所の１つである、迅速な実証実験を促進する。ただし、多様な要求仕様、又は、デプロイ先に応じて、最適なクラウドデザインを選択できなければ、クラウドコンピューティングの調達ミスとなり、システムアーキテクティングにおける効率性が損なわれ、システムダウン等が生ずる恐れがある。

特許文献１によれば、異なるクラウドコンピューティングプラットフォームに対するアプリケーションのデプロイが、ＸＭＬフォーマットを用いた当該アプリケーションに係るクラウドデザインの翻訳を経て行われる技術が報告されている（特許文献１）。

特許文献２によれば、複数データセンタにまたがる情報システムにおいて、要件を満たした最適なシステム構成案を生成するためのシステム構成案生成方法および設計支援装置に関する技術が報告されている（特許文献２）。

特許文献２によれば、複数データセンタに跨ったシステム設計のベストプラクティスを、予めクラウドデザインパターン集として登録しておく技術が報告されている。利用者が入力したシステム構成情報に対し妥当性の評価を行う。妥当性評価において問題が判明した場合には、デザインパターンを検索し、問題解決が可能かどうかを判定する。問題解決できるデザインパターンが見つかった場合には、デザインパターンを適用することでシステム構成の最適化を行い、その結果を利用者に提示する（特許文献２）。

Ｐｅｔｅｒ Ｍｅｌｌ ａｎｄ Ｔｉｍｏｔｈｙ Ｇｒａｎｃｅ，"Ｔｈｅ ＮＩＳＴ Ｄｅｆｉｎｉｔｉｏｎ ｏｆ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ"，ＮＩＳＴ Ｓｐｅｃｉａｌ Ｐｕｂｌｉｃａｔｉｏｎ ８００−１４５（２０１１）

米国特許第８４３４０８０Ｂ２号明細書 特許第６１７３９０９号公報

クラウドデザインデータベースは、形式知の共有と、形式知の継承及び改善と、を目的とする観点から、オープンデータネイティブな情報リポジトリの態様をとることが望ましい。すなわち、不特定多数のユーザから提供されたクラウドデザインを改竄なく公開する、例えば、分散ネットワーク等に基づく、中立性が担保された監査の導入が求められる。

クラウドデザインの誘致を好適に行うためには、クラウドデザインの提供者に対し報酬を付与するエコノミーモデルを構築する必要がある。このとき、提供されたクラウドデザインに係る報酬／インセンティブ設計に対して正当性と透明性とを担保する観点からも、データベースに対し、中立性が担保された監査を導入することが求められる。

無数のクラウドデザインの中から有用なクラウドデザインをユーザに選択させるためには、クラウドデザインに対する評価基準を設けることが好ましい。ベストプラクティス等の編集された情報の場合、重要な情報の要約や、広告意図による内容の改竄が発生する恐れがあるため、例えば、実際のオンラインサービスに採用された実績があるか否か等の評価基準に基づいた評価を、クラウドデザインに付すことが好ましい。

本発明は、エコノミーモデルを有する分散型クラウドデザインデータベースを実現し、クラウドデザイン管理に係る正当性及び透明性の担保を、解決すべき課題とする。

上記課題を解決するために、本発明は、クラウドデザイン管理方法であって、分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行ステップと、前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量と、前記分散ネットワークへの参加者に対する前記トークンの配布量と、を決定する融通ステップと、をコンピュータのプロセッサに実行させること、を特徴とする。

このような構成とすることで、不特定多数のユーザから提供されたクラウドデザインを改竄なく公開し、提供されたクラウドデザインに対応付けられた報酬／インセンティブ設計に対して正当性と透明性とを担保することができる。

本発明の好ましい形態では、前記分散ネットワークは、１以上のパブリックノードからなり、プルーフ・オブ・ワーク方式及び／又はプルーフ・オブ・ステーク方式の合意形成アルゴリズムに基づくブロックチェーンネットワークであり、前記スマートコントラクトの執行又は前記設計情報の共有のための記憶領域を保持する仮想マシンを有すること、を特徴とする。

このような構成とすることで、オープンデータネイティブかつブロックチェーンネイティブなクラウドデザインデータベースを実現でき、スマートコントラクトによるクラウドデザイン及び報酬／インセンティブに係る管理を、分散コンピューティングに基づく仮想マシンにより実現できる。

本発明の好ましい形態では、前記設計情報は、前記クラウドデザインに係るサービス利用者を示す情報を含むアクターオブジェクトと、前記クラウドデザインに係るシステム要件を示す情報を含むリソースオブジェクトと、前記アクターオブジェクトと前記リソースオブジェクトの相関に係る情報を示すコンテキストオブジェクトとを含み、マークアップ言語に基づき記述されること、を特徴とする。

このような構成とすることで、マークアップ言語に基づき、システム要件と、サービス目的／用途と、を分散ネットワーク上に保存することができ、共通化されたワークフローを用いてクラウドデザインの共有と、クラウドデザイン作成／監査を含むクラウドアーキテクティングに係るタレントシェアリングの実現と、が容易となる。

本発明の好ましい形態では、クラウドデザイン管理方法であって、前記設計情報に係る類似度及び評価値を決定する鑑定ステップを、コンピュータのプロセッサに実行させ、前記鑑定ステップは、形態素解析により前記分散ネットワークにおける前記設計情報に係る特徴量を抽出し、当該設計情報に係る中心性尺度の決定と、前記類似度の決定と、を行うこと、を特徴とする。

このような構成とすることで、クラウドデザインを構成する単位情報を特徴量として抽出でき、分散ネットワークへの参加者による、所望のクラウドデザインの索出と、クラウドデザインに係る評価と、が容易となる。

本発明の好ましい形態では、前記鑑定ステップは、前記設計情報の変更を転機とした前記評価値に係る変動が生じた場合、変動した前記評価値と当該設計情報に係る前記評価値の最高値との差分に基づき、前記評価値を更新すること、を特徴とする。

このような構成とすることで、既存のクラウドデザインに対する評価結果に対応した報酬の分配ではなく、既存のクラウドデザインからの改良に対する評価結果に連動した報酬の分配を実現でき、クラウドデザインデータベースを構成する種々のクラウドデザインの改良を促すことができる。

本発明の好ましい形態では、前記鑑定ステップは、前記設計情報に係るシステム要件を示す要件情報、前記設計情報に係るシステム稼働実績を示す実績情報、前記設計情報に係る参照元としての前記クラウドデザインの数量を示す参照情報、及び、前記設計情報に係るクラウドデザイン作成者を示す設計者情報の少なくとも１つに基づき、前記評価値を決定すること、を特徴とする。

このような構成とすることで、多様なデプロイ先において実用に耐えるクラウドデザインか否かを示す生デザイン指標と、分散ネットワーク参加者による探索が容易であるか否かを示す探索可能性指標と、に基づき、クラウドデザインに係る評価を決定できる。

本発明の好ましい形態では、 前記鑑定ステップは、前記設計情報において、前記要件情報、実績情報、参照情報及び設計者情報が入力されている場合、当該設計情報に係る前記評価値を加算すること、を特徴とする。

このような構成とすることで、クラウドデザインがマークアップ言語により記述された設計情報に含まれる情報の網羅性に基づき、当該クラウドデザインに係る評価を決定することができ、クラウドデザインデータベースを構成する設計情報における情報の欠如を、未然に防ぐことができる。

本発明の好ましい形態では、前記融通ステップは、前記トークンに係る前記参加者間の送受を行うための前記トランザクション処理を受け付けること、を特徴とする。

このような構成とすることで、クラウドデザイン管理のための分散ネットワーク上で生成／発行されるトークンを用いた取引が可能となる。

本発明の好ましい形態では、前記融通ステップは、前記実行ステップにより、前記設計情報の入力を含む前記トランザクション処理を実行した前記参加者に対して、前記トークンに係る前記配布量を決定し、前記実行ステップは、当該決定に基づく前記トークンの配布を含むスマートコントラクトの執行と、当該執行に係るトランザクション処理の実行と、を行うこと、を特徴とする。

このような構成とすることで、クラウドデザインを提供した分散ネットワーク参加者に対して、報酬としてトークンを配布することができる。これにより、デザイン提供者とデザイン享受者とのフラットな関係性を実現し、データベースとデータベース利用者が共に成長可能な共創関係が構築され、クラウドデザインの好適な共有が可能となる。

本発明の好ましい形態では、前記実行ステップは、前記参加者に対する前記トークンの配布を含むスマートコントラクトの執行、及び、当該執行に係るトランザクション処理の実行を、所定期間毎に、前記参加者に対応付けられた前記設計情報の変更が行われている場合に行うこと、を特徴とする。

このような構成とすることで、提供されたクラウドデザインの変更／更新に応じて、当該変更／更新に連動した追加報酬を、分散ネットワーク参加者に対して分配することができ、クラウドデザインデータベースの発展に寄与できる。

本発明の好ましい形態では、前記融通ステップは、前記トークンに係る前記発行量と、前記参加者により前記分散ネットワーク上に入力された前記設計情報に係る前記評価値、前記参加者に係る前記トークンの保有量、及び、前記参加者に係る前記トークンの保有期間の少なくとも１つと、に基づき、前記参加者に対する前記配布量を決定すること、を特徴とする。

このような構成とすることで、クラウドデザインを好適に管理するための分散ネットワークにおけるトークンエコノミーモデルについて、トークン流通量を好適に制御し、トークン価値の好適な管理を実現できる。

本発明の好ましい形態では、前記実行ステップは、前記参加者が、前記配布量以上の前記トークンを、所定期間以上、保有していない場合、当該参加者に対する前記トークンの配布を含むスマートコントラクトの執行と、当該執行に係るトランザクション処理の実行と、を行わないこと、を特徴とする。

このような構成とすることで、クラウドデザインを好適に管理するための分散ネットワークにおいて、クラウドデザインの提供／作成／監査に係る意思を持たない好適でないユーザに対する、トークン分配を抑制し、好適なトークンエコノミーモデルに基づく分散型クラウドデザインデータベースを実現できる。

本発明の好ましい形態では、前記融通ステップは、前記トークンに係る前記発行量及び前記参加者に係る前記トークンの保有量に基づく前記トークンの保有比率と、前記参加者により前記分散ネットワークに入力された１以上の前記設計情報に係る前記評価値の総和と、に基づき決定されるデータベース貢献度を決定し、前記トークンに係る追加発行量及び前記データベース貢献度に基づき前記トークンに係る前記配布量を決定すること、を特徴とする。

このような構成とすることで、クラウドデザインデータベースに対する貢献度を少なくとも提供したクラウドデザインに基づき決定し、当該貢献度とトークン保有量／保有期間とを併せることで、クラウドデザインデータベースにとって好適な分散ネットワーク参加者か否かを判断し、報酬を分配することができる。

本発明の好ましい形態では、前記融通ステップは、前記データベース貢献度と所定の配布レートとの積を、前記トークンに係る前記配布量の上限とすること、を特徴とする。

このような構成とすることで、分散ネットワークにおいて、クラウドデザインデータベースの充実に寄与しない分散ネットワーク参加者による、追加発行されたトークンの寡占を抑制することができ、好適なトークンエコノミーモデルを実現できる。

本発明の好ましい形態では、前記融通ステップは、追加発行された前記トークンに係る実効性付与の比率を、当該追加発行からの経過時間を変数とするシグモイド関数に基づき決定すること、を特徴とする。

このような構成とすることで、実効性を付与するトークンの比率を指数関数的に増大させ、分散ネットワークにおけるトークン価値の急激な変動を抑制する。これにより、好適なトークンエコノミーモデルを実現できる。

本発明の好ましい形態では、前記実行ステップは、前記参加者による前記クラウドデザインに係る作成又は監査に係る依頼と、当該依頼に対応付けられる前記トークンの報酬量に係る設定と、を行うためのトランザクション処理を実行すること、を特徴とする。

このような構成とすることで、クラウドデザインの提供のみならず、クラウドデザインに係る作成及び監査を、分散ネットワーク上のトークン取引により、実現できる。

本発明の好ましい形態では、前記実行ステップは、前記依頼に基づく前記設計情報を含む前記トランザクション処理が、前記参加者により実行されることを転機として、前記報酬量の前記トークンを当該参加者に対する配布を行うためのスマートコントラクトの執行と、当該執行に対応付けられたトランザクション処理を実行すること、を特徴とする。

このような構成とすることで、クラウドデザインに係る作成／監査の依頼達成を分散ネットワーク上のトランザクションに基づき証明でき、透明性の高いタレントシェアリングを実現できる。

本発明の好ましい形態では、前記実行ステップは、前記依頼に基づく前記設計情報を含む前記トランザクション処理を行われた場合、少なくとも前記参加者に係る情報を前記設計情報に追加し更新すること、を特徴とする。

このような構成とすることで、クラウドデザインに係る作成依頼を達成した作成者／設計者に係る情報をアクターオブジェクトに追加し、適切な報酬分配を実現できる。

本発明では、クラウドデザインデータベースであって、分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行手段と、前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量の決定と、前記分散ネットワークへの参加者に対する前記トークンの配布量の決定と、を行う融通手段と、有すること、を特徴とする。

本発明では、クラウドデザイン管理プログラムであって、コンピュータを、分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行手段と、前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量の決定と、前記分散ネットワークへの参加者に対する前記トークンの配布量の決定と、を行う融通手段と、として機能させること、を特徴とする。

本発明によれば、オープンデータネイティブかつブロックチェーンネイティブなクラウドデザイン管理が実現できる。

本発明の実施形態におけるクラウドデザインデータベースの概要図である。 本発明の実施形態におけるクラウドデザインデータベースのハードウェア構成図及び機能ブロック図である。 本発明の実施形態におけるクラウドデザインデータベース上に保存される設計情報が有するオブジェクトについて図示している。 本発明の実施形態におけるクラウドデザインを示す設計情報に係る処理を図示している。 本発明の実施形態における分散ネットワークの概要図である。 本発明の実施形態における分散ネットワークに係るトランザクション及びアカウント状態を図示している。 本発明の実施形態における分散ネットワーク上のスマートコントラクトの実行手順を図示している。 本発明の実施形態におけるクラウドデザインに係る依頼の概要を図示している。

以下、図面を用いて、本発明に係るクラウドデザインデータベースについて説明する。なお、以下に示す実施形態は本発明の一例であり、本発明を以下の実施形態に限定するものではなく、様々な構成を採用することもできる。

図１は、本発明の実施形態に係るクラウドデザインデータベース１の概要を図示している。クラウドデザインデータベース１における、クラウドデザインの保存、並びに、参照は、１以上のノード２において行われ、サーバ装置を別途設ける必要はない。

本実施形態におけるクラウドデザインとは、クラウドコンピューティングのためのシステム構成情報を指し、インスタンスを含むコンポーネントとしてのコンピューティングリソースの数量及び組み合わせを示す情報からなる。また、当該クラウドデザインは、１のユーザにより作成されるものではなく、複数のユーザにより作成されてもよい。

本発明におけるクラウドデザインデータベース１は、以下の目的に基づき実現される。
（１）分散ストレージを用いた、言語化されたクラウドデザインの保存。
（２）分散ネットワーク上でのクラウドデザインの評価／参照性担保。
（３）クラウドデザインの共有を好適に実現するエコノミーモデルの構築。
当該目的を実現するために、本発明における実施形態では、ブロックチェーンを含む分散型台帳技術に基づく分散ネットワークが用いられる。

例えば、本実施形態では、クラウドデザインデータベース１の構成、動作などについて説明するが、同様の構成の方法、コンピュータ装置、コンピュータプログラム、記録媒体なども、同様の作用効果を奏することができる。

本実施形態におけるクラウドデザインデータベース１の構成は、いかなる当業者も本発明を作成または使用することができるように与えられるものである。これらの構成に対する様々な修正は当業者には容易に明らかとなり、本実施形態で定義されるクラウドデザインデータベース１に係る一般原理は、本発明の趣旨または範囲から逸脱することなく、他の態様に適用され得る。

本実施形態におけるプログラムは、記録媒体に記憶させてもよい。この記録媒体を用いれば、コンピュータ装置にプログラムをインストールできる。ここで、プログラムを記憶した記録媒体は、非一過性の記録媒体であっても良い。

本実施形態における非一過性の記録媒体には、例として、フラッシュメモリ等の不揮発性メモリや、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）等の光ディスクストレージや、フロッピー（登録商標）等の磁気ストレージデバイス等が採用されてよい。

図２は、本実施形態に係るクラウドデザインデータベース１の機能ブロック図及びハードウェア構成図を示している。

図２（ａ）に示すとおり、クラウドデザインデータベース１は、１以上のノード２からなり、ブロックチェーンに基づく分散ネットワークＤＮＷを有する。

本実施形態における分散ネットワークＤＮＷでは、チューリング完全なクリプトネットワークであり、所定の合意形成アルゴリズムに基づきネットワークの維持／アップデートが行われ、ビザンチン・フォールトトレラント性としての改竄耐性が実現される構成が好ましい。

本実施形態では、イーサリアム（Ｅｔｈｅｒｅｕｍ）、ＥＶＭ（Ｅｔｈｅｒｅｕｍ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）及びＥＲＣ−２０（Ｅｔｈｅｒｅｕｍ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ−２０）トークンに基づくクラウドデザインデータベースを構築し、クラウドデザイン管理を行う場合について例示する。なお、データストレージ機能及びトークン生成機能を有するスマートコントラクトを含む分散型アプリケーション（ＤＡｐｐｓ：Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ａｐｐｌｉｃａｔｉｏｎｓ）プラットフォームであれば、ブロックチェーン、仮想マシン及びトークンの種別に、特に制限はない。

本実施形態におけるスマートコントラクトは、コントラクト（契約）に係る自己執行権を有するコンピュータプロトコルを指す。スマートコントラクトでは、コントラクトに係る条件確認及び履行が、自動的に執行される。本実施形態における分散ネットワークＤＮＷでは、スマートコントラクトに係る１以上のトランザクション処理が含まれるブロックが、第三者により承認され、さらに、当該トランザクション処理が公開されるため、中立性／透明性が担保されたスマートコントラクトが実現される。

本実施形態におけるノード２は、クラウドデザインの保存及び参照に係る処理と、報酬の受渡に係る処理とに限らず、分散ネットワークＤＮＷを形成するための、合意形成アルゴリズムに基づく処理も併せて実行可能である構成が好ましい。

本実施形態において用いられる分散ネットワークに係る合意形成アルゴリズムに、特に制限はない。例えば、ＰｏＷ（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ：プルーフ・オブ・ワーク）方式や、ＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ：プルーフ・オブ・ステーク）方式に限らず、ＰｏＷとＰｏＳのハイブリッドであってもよい。また、特定のＶａｌｉｄａｔｏｒが、トランザクションを承認する構成としてもよい。

本実施形態においてノード２により構成される分散ネットワークＤＮＷは、不特定多数のノード２が参加し、参加制限が課されていない、パブリックネットワークである構成が好ましい。なお、あらかじめ参加を許可されたノード２のみにより構成されるコンソーシアムネットワークである構成としてもよい。このとき、参加が許可されるノード２は、例として、個人若しくは営利団体により管理される電子計算機である。

図２（ｂ）に示すとおり、ノード２は、演算装置２０１と、主記憶装置２０２と、補助記憶装置２０３と、入力装置２０４と、出力装置２０５と、分散ネットワークＤＮＷ上の処理を実行するための通信を行う通信装置２０６と、当該装置に係る相互接続のためのバスインタフェースと、を備える。

演算装置２０１は、命令セットを実行可能なプロセッサからなる。主記憶装置２０２は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性メモリを含む。補助記憶装置２０３は、不揮発性メモリ等の記録媒体を含み、その記録方式に、特に制限はない。入力装置２０４は、ポインティングデバイス若しくはタッチパネル等で構成される。

出力装置２０５は、描画情報を保持するためのフレームバッファとしてのビデオメモリ（ＶＲＡＭ）と、リアルタイム画像処理に特化したプロセッサとを混載するビデオカード又はオンボードグラフィックス機能を備え、また、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）や有機ＥＬ（Ｅｌｅｃｔｒｏ―Ｌｕｍｉｎｅｓｃｅｎｃｅ）や電気泳動方式の電子ペーパー等で構成されるディスプレイ装置を備える。

本実施形態では、演算装置２０１及び主記憶装置２０２を少なくとも含む、ＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）が、ノード２に備えられている構成としてもよい。このとき、当該ＳｏＣには、例として、エンコード／デコード等のためのＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）コア、機械学習／深層学習／強化学習等の特定用途に最適化された集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のプログラマブル論理デバイスを含むコプロセッサーが含まれる構成としてもよい。

本実施形態における演算装置２０１としての汎用プロセッサは、マルチプロセッサであり得るが、代替的に、プロセッサはいかなる従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサは、コンピューティングデバイスの組合せ、たとえば、ＤＳＰコアとマルチプロセッサとの組合せ、複数のマルチプロセッサ、ＤＳＰコアと連携する1つもしくは複数のマルチプロセッサ、または任意の他のそのような構成としても実装され得る。

なお、本実施形態におけるノード２は、デスクトップＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）や、ワークステーション等の態様をとる他、スマートフォン、タブレット等の携帯機器の態様としてもよい。また、Ｒａｓｂｅｒｒｙ Ｐｉ（登録商標）等の、入力装置２０４及び出力装置２０５を備えないコンピュータ装置を、ノード２としてもよい。

通信装置２０６は、無線ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）／ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）／ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介した通信を行うために用いられる。当該通信は、Ｗｉ−Ｆｉ（登録商標）等の無線通信規格に基づく。通信媒体は、電波、音波及び光波等が利用でき、その種別に特に制限はない。なお、本実施形態における通信装置２０６は、Ｅｔｈｅｒｎｅｔ（登録商標）等の有線通信規格を用いる構成としてもよい。

クラウドデザインデータベース１は、例えば、通信プロトコルにＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等を用いてデータ通信ができる。なお、分散ネットワークＤＮＷは、ＣＡＴＶ（Ｃｏｍｍｕｎｉｔｙ Ａｎｔｅｎｎａ Ｔｅｌｅｖｉｓｉｏｎ）回線や、移動体通信網、航空通信網、衛星通信網等、種々の回線を利用することができ、特に制限はない。

補助記憶装置２０３は、オペレーティングシステム（ＯＳ）２００１と、ＯＳ２００１と協調してその機能を発揮するクラウドデザイン管理プログラム２００２と、入力処理を種々の経路から行うためのアプリケーションプログラミングインタフェース（ＡＰＩ）２００３と、が記録されている。ＯＳ２００１には、Ｕｎｉｘ系ＯＳを一例とする種々のＯＳを採用してよい。また、ＡＰＩ２００３には、ＪａｖａＳｃｒｉｐｔ（登録商標）ＡＰＩをはじめとする種々のＡＰＩを採用してよい。

また、クラウドデザインデータベース１は、アプリケーションに代え、又は加えて、クラウドデザイン管理用のウェブページを利用する為の、ブラウザアプリケーションや、通知を確認する為のメーラーアプリケーションを記憶する、という構成にしてもよい。

本実施形態における、ノード２は、補助記憶装置２０３とは別に、各種データのバックアップ先として、バックアップ装置ＢＵに対応付けられる構成としてもよい。このとき、当該バックアップ装置ＢＵは、通信装置２０６を介してアクセス可能であり、不揮発性メモリを含む情報記憶装置からなる構成が好ましい。

また、本実施形態では、クラウドデザイン管理に係る通知処理は、ノード２に記憶したアプリケーションを用いて行う。当該通知処理はこれに限らず、例えば、ユーザのメールアドレスに対して電子メールを送信する方法や、その他、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）サービス上での通知等、種々の方法を利用することができる。

本実施形態におけるノード２におけるＯＳ２００１のカーネルは、非特権コードが実行される場合はユーザ空間内に編成され、特権コードが実行される場合はカーネル空間内に編成される。この分離は、カーネル空間の一部であるコードが一般公的使用許諾(ＧＰＬ：Ｇｅｎｅｒａｌ Ｐｕｂｌｉｃ Ｌｉｃｅｎｓｅ)で許諾される必要がある一方で、ユーザ空間において実行するコードがＧＰＬ許諾されなくてもよい。本実施形態における様々なソフトウェア構成要素/モジュールは、明示的に別段の記述がない場合、カーネル空間またはユーザ空間の何れかにに実装される構成としてもよい。

図２（ｂ）に示すとおり、ノード２は、入力手段２１、表示手段２２、鑑定手段２３、実行手段２４、融通手段２５及び承認手段２６を備える。これらの手段は、ノード２に記憶されている、ＯＳ２００１、クラウドデザイン管理プログラム２００２及びＡＰＩ２００３の少なくとも１つに対応付けられている。

入力手段２１は、クラウドデザインに係る保存及び参照に係る入力処理のために用いられる。また、トランザクション実行を含むブロックチェーン上の処理に係る意思入力や、生成されたトークンの取引に係る意思入力を行うために用いられる。

本実施形態において、入力手段２１は、所定のマークアップ言語に基づき記述されたクラウドデザインを、設計情報Ｄ０として、分散ネットワークＤＮＷに保存する。このとき、入力手段２１は、後述する実行手段２４と協調して、設計情報Ｄ０を分散ネットワークＤＮＷが利用するブロックチェーン上の仮想ストレージに保存する構成が好ましい。

本実施形態におけるクラウドデザイン管理に係るマークアップ言語を、以降、ＣＤＭＬ（Ｃｌｏｕｄ Ｄｅｓｉｇｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）言語と称す。ＣＤＭＬ言語は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＹＡＭＬ等の汎用フォーマットと、ＣｌｏｕｄＦｏｒｍａｔｉｏｎやＴｅｒｒａｆｏｒｍ等のクラウドオートメーション言語と、に基づく。

図３に示すとおり、本実施形態における設計情報Ｄ０に係るオブジェクトは、アクターオブジェクトＯＢＪ１、リソースオブジェクトＯＢＪ２及びコンテキストオブジェクトＯＢＪ３が含まれる。なお、本実施形態における設計情報Ｄ０には、メタデータを有するメタデータオブジェクトが含まれる構成としてもよい。

アクターオブジェクトＯＢＪ１には、サービス利用者や連携先となる外部システムに係る情報が含まれる。リソースオブジェクトＯＢＪ２には、用いられるコンピューティングリソースに係る情報と、コンピューティングリソース同士の組み合わせを示す情報と、が含まれる。コンテキストオブジェクトＯＢＪ３には、アクターオブジェクトとリソースオブジェクトとの相関を示す情報が含まれる。

アクターオブジェクトＯＢＪ１に記述されるクラウドデザイン作成者に係る情報は、当該クラウドデザイン作成者に対応付けられた電子署名である構成としてもよい。このとき、当該電子署名は、分散ネットワークＤＮＷに参加するクラウドデザイン作成者に固有の秘密鍵（プライベートキー）に基づく構成としてもよいし、クラウドデザイン作成者に係る生体鍵に基づく構成としてもよい。

リソースオブジェクトＯＢＪ２は、既存のクラウドオートメーション言語による記述の流用が可能である構成が好ましい。一例として、Ａｐａｃｈｅ（登録商標）上でＷｏｒｄＰｒｅｓｓ（登録商標）が動作する環境構築を行う場合、インスタンス、サブネット、ルートテーブル、インターネットゲートウェイ、Ｅｌａｓｔｉｃ ＩＰ、ＮＡＴゲートウェイが少なくとも必要となる。このとき、インスタンスの数量や各クラウドコンポーネントとの相関等を含むコンピューティングリソースに係る情報が、リソースオブジェクトおＢＪ２に含まれる。

コンテキストオブジェクトＯＢＪ３では、特定のユーザに係る用いるコンピューティングリソースの種別と期間や、後述する参照化担保のためにベクトル化された単位情報としてのクラウドデザインに係る情報や、アクターとリソースとの相関が記述される。

表示手段２２は、クラウドデザイン管理に係る表示処理を行う。当該表示処理は、ノード２上のアプリケーション、若しくは、ブラウザ上のページの態様で行われる構成が好ましい。このとき、分散ネットワークＤＮＷを介して、複数のノード２間で協調して、当該表示処理が行われる構成としてもよい。

鑑定手段２３は、分散ネットワークＤＮＷに保存された設計情報Ｄ０に基づき、クラウドデザインに係る類似度と可用性を示す評価値とを決定する。本実施形態における可用性とは、当該クラウドデザインに基づき構築されたソフトウェア／アプリケーションに係る、継続して稼働できる能力、当該信頼性、保守性、保全性及び安全性の少なくとも１つが含まれる。

鑑定手段２３は、ＣＤＭＬ言語に基づき記述されたクラウドデザインに係る情報を含む設計情報Ｄ０について、形態素解析と特徴抽出とを行う。

図４は、クラウドデザインを示すクラウドオートメーション言語に係る共起ネットワークを、媒介中心性に係る濃淡とともに例示している。鑑定手段２３は、クラウドデザインを示す設計情報Ｄ０における中心性尺度の決定を、形態素解析を経て行う。当該形態素解析は、クラウドデザインに係る類似度の決定を含む参照性担保、及び／又は、評価のために行われる構成が好ましい。

本実施形態におけるクラウドデザインに係る特徴量は、クラウドコンポーネント及びアドレスを含む単語に係る情報、又は、ストレージサイズ及びトラフィック量を含む数値情報を指す。鑑定手段２３は、当該クラウドデザインの形態素解析を行い、当該単語の正規化を経て、特徴量のベクトル化を行う。

クラウドデザインに係るベクトル値は、クラウドデザインデータベース１におけるクラウドデザインの参照性担保のために用いられる。具体的には、式（１）に示すようなコサイン類似度に基づく類似性の定量化と、式（２）に示すような、媒介中心性ノードとしての単位デザインの検出／定量化と、が参照性担保のために行われる。

本実施形態におけるクラウドデザインに係る参照性担保のための中心性尺度の決定は、媒介中心性に限定されず、次数中心性及び固有ベクトル中心性の何れかに基づく構成としてもよい。本実施形態では、設計情報Ｄ０に係る特徴量解析は、共起ネットワーク生成、クラスター分析、対応分析等の態様で、結果の出力が行われる構成としてもよい。

本実施形態におけるクラウドデザインに係る評価を定量化した評価値は、所定の評価指標毎に算出された評価値の総和に基づき、式（３）のように決定される。

本実施形態における評価値（Ｅｉｅ）は、評価基準毎の評価値（Ｃ）と、評価基準毎の重み付け（Ｒ）との積の総和に基づき、決定される。先ずは、保存されたクラウドデザインに係る設計情報Ｄ０に係る評価値を決定し、以降、設計情報Ｄ０が更新される都度、当該評価値は最高値（ｍａｘ（Ｅｉ））からの上昇分のみが、評価値として更新される。当該更新は、後述する報酬／インセンティブの付与を管理するために、所定期間毎に行われる構成が好ましい。本実施形態における評価値の更新は、最高値を含む、当該設計情報Ｄ０の履歴に基づいて行われる。例えば、最低値を基準とした更新としてもよい。このとき、当該履歴は、分散ネットワークＤＮＷ上の仮想ストレージに保存される。

本実施形態における評価値は、鑑定手段２３によって、要件情報、実績情報、参照情報及び設計者情報の少なくとも１つに基づき、決定される。

本実施形態における要件情報は、実在性又は妥当性を示す生デザイン指標として、クラウドデザインに係る評価に用いられる。生デザイン指標は、クラウドコンピューティングの正しい利用実態、調達条件を示し、実用に耐えないクラウドデザインか否かを判定するために用いられる。

評価値の決定因子の１つである、実在性に係る情報は、クラウドデザインに基づくソフトウェアが実際に構築され稼働した実績に基づいて決定される。具体的には、当該クラウドデザインを示す設計情報Ｄ０に当該ソフトウェアが稼働するサービスに係る情報が記述され、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）認証やＡＰＩ連動等により、当該ソフトウェアの実在が証明された場合、実在性を示す評価基準に対応付けられた評価値が上方修正される。

評価値の決定因子の１つである、妥当性に係る情報は、クラウドコンピューティングの調達条件に基づき、決定される。具体的には、ＡＷＳ ＣｌｏｕｄＦｏｒｍａｔｉｏｎ（登録商標）等のクラウドコンピューティングの発注に利用できるインフラストラクチャーオートメーションツール用発注コードがリソースオブジェクトＯＢＪ２に記述されている場合、妥当性を示す評価値が上方修正される。

本実施形態における参照情報及び設計者情報は、探索可能性指標として、ユーザが有する目的に合致したクラウドデザインの発見を促すために用いられる。これは、クラウドアーキテクティングにおける調達ミスを回避するためであり、探索／参照のし易さを、クラウドデザインデータベース１における評価指標の１つとしている。

本実施形態における参照情報はクラウドデザインに係る他デザインとの類似を示す関連性を指し、設計者情報はクラウドデザインの１以上の作成者を示す関連性を示す。また、本実施形態における評価値は、設計情報Ｄ０に係る網羅性にも基づく。

本実施形態における網羅性に係る情報は、設計情報Ｄ０に含まれる情報範囲を示す。具体的には、アクターオブジェクトＯＢＪ１、リソースオブジェクトＯＢＪ２、コンテキストオブジェクトＯＢＪ３の内、記述が行われている項目数に係る情報に基づき、網羅性を示す評価値が決定される。

評価値に係る決定因子の１つである、関連性に係る情報は、クラウドデザインの作成において、参考とした他のクラウドデザインに係る情報提供を示す。当該情報提供により、可用性が認められないクラウドデザインが、設計情報Ｄ０にリファレンスとして記述されていたとしても、下記の式（４）に基づき、評価値が決定される。なお、当該数式におけるリファレンス数に係るカットオフ値（ｎ）に、特に制限はない。

本実施形態における関連性に係る情報に基づく評価値の更新は、リファレンスとして用いられたクラウドデザインの可用性に基づく構成としてもよい。これは、例えば、既に可用性が担保されているクラウドデザインに基づき、改善されたものであるか否か、の判定に用いられる。また、参照元であるクラウドデザインに係る設計情報Ｄ０の評価値に基づき、評価を受ける設計情報Ｄ０の評価値が決定される構成としてもよい。

本実施形態に係る関連性に係る情報は、クラウドデザインに係る作成者に係る情報を指す。デザイン作成に関与したプランナーやエンジニアが、設計情報Ｄ０において記述されることで、評価値は関連性の観点により、下記の数式５に基づき、評価値が更新される。なお、当該数式における作成者数に係るカットオフ値（ｎ）に、特に制限はない。

本実施形態における評価値は、前述の類似度ならびに媒介中心性ノードに基づき、決定される構成としてもよい。具体的には、クラウドデザインの参照を行うユーザにより入力処理された、所望のソフトウェアアーキテクチャと合致するクラウドデザインを索出するために、当該ソフトウェアアーキテクチャを示すベクトルとの類似度が高いクラウドデザインに対し、評価値を加算する構成としてもよい。また、当該ソフトウェアアーキテクチャのメインフィーチャーを示す単位デザインが、媒介中心性上位ノードとして検出されるクラウドデザインについて、評価値を加算する構成としてもよい。

実行手段２４は、分散ネットワークＤＮＷを構成するブロックチェーンにおけるトランザクションの実行と、スマートコントラクトの執行と、コントラクトアカウント作成を含む当該スマートコントラクトに係るトランザクションの実行と、を行うために用いられる。当該トランザクションは、後述する当該スマートコントラクトに対応付けられたトークンの取引を含む、アカウントステートの更新のために実行される。なお、トランザクションの実行に係るネットワーク手数料については、適宜、好適に決定される。

次に、本実施形態における分散ネットワークＤＮＷを構成するブロックチェーンＢＣ及び分散ネットワークＤＮＷ上の仮想マシンＥＶＭについて、図５を交えて、説明する。

図５（ａ）に示すとおり、本実施形態における分散ネットワークＤＮＷは、改竄耐性を有する状態遷移マシン（ステートマシン）として、振る舞う。分散ネットワークＤＮＷにおける状態（ｗｏｒｌｄ ｓｔａｔｅ）は、ブロックチェーンＢＣの態様で保存／公開され、その遷移はノード２を介したトランザクション実行により行われる。仮想マシンＥＶＭは、チューリング完全なスクリプト言語に基づき、スマートコントラクトを執行する。

図５（ｂ）に示すとおり、ブロックチェーンＢＣでは、ブロックヘッダー（ｈｅａｄｅｒ）及び１以上のトランザクション（ｔｒａｎｓａｃｔｉｏｎ）を含むブロック（ｂｌｏｃｋ）が、ハッシュチェーンの態様で相関を持つ。分散ネットワークＤＮＷにおける状態は、ブロックヘッダーに保存される。

ブロックチェーンＢＣにおける任意のブロックが有するブロックヘッダーは、直前ブロック（親ブロック）に係るハッシュ値と、当該ブロックにおける全トランザクションが実行された状態に係る状態木（ｓｔａｔｅ ｒｏｏｔ）を示すルートノードのハッシュ値と、当該プロックにおけるトランザクションに係るトランザクション木（ｔｒａｎｓａｃｔｉｏｎ ｒｏｏｔ）を示すルートノードのハッシュ値と、当該ブロックに含まれるトランザクションの実行結果に係るデータ構造を示すルートノードのハッシュ値と、を含む。このとき、ブロックヘッダーが有するルートノードは、中間ノードと、末端のリーフノードとに対応付けられ、マークルパトリシアツリーの態様のデータ構造として振る舞う。

ブロックヘッダーは、ブロック生成難易度、当該ブロックで用いられたブロックチェーンＢＣ上での手数料、同一の鍵情報により暗号処理を繰り返すためのランダムデータであるノンス（ｎｏｎｃｅ）、タイムスタンプ及びブロックサイズを、少なくとも含む。

図５（ｃ）に示すとおり、仮想マシンＥＶＭは、分散ネットワークＤＮＷ上の状態を管理するために用いられる。状態（ｗｏｒｌｄ ｓｔａｔｅ）は、オブジェクトとしてのアカウントに係る状態（ａｃｃｏｕｎｔ ｓｔａｔｅ）及び仮想マシンＥＶＭに係る状態（ｍａｃｈｉｎｅ ｓｔａｔｅ）を含む。状態遷移を行うためのトランザクションは、アドレス（ａｄｄｒｅｓｓ）、値（ｖａｌｕｅ）及び入力データ（ｉｎｐｕｔ ｄａｔａ）を少なくとも含む。仮想マシンＥＶＭは、アカウント状態に対応付けられるコントラクトコード及び仮想ストレージと、当該入力データと、に係る情報を有する。

仮想マシンＥＶＭは、仮想演算装置ＥＶＭ１０１、仮想主記憶装置ＥＶＭ１０２、仮想補助記憶装置ＥＶＭ１０３、及び、コントラクトコードとしてのクラウドデザイン管理プログラムＥＶＭ１００１を、有する。なお、クラウドデザイン管理プログラムＥＶＭ１００１は、クラウドデザイン管理プログラム２００２に含まれる。

仮想演算装置ＥＶＭ１０１は、分散ネットワークＤＮＷにおける少なくとも１つのノード２が備える演算装置２０１からなる。

仮想主記憶装置ＥＶＭ１０２は、揮発性を有するデータ領域として、ｓｔａｃｋ及びｍｅｍｏｒｙを有し、ｍａｃｈｉｎｅ ｓｔａｔｅに対応付けられる。

仮想補助記憶装置ＥＶＭ１０３は、不揮発性を有するデータ領域として、コントラクトコードの保存領域及び仮想ストレージとして用いられる。当該ｓｔａｃｋは、コントラクトコードによる処理の実行に際し、先ず更新され、その後、当該ｍｅｍｏｒｙ及び当該仮想ストレージに対するランダムアクセスが行われる

仮想マシンＥＶＭにおけるコントラクトコードは、クラウドデザイン管理に係るスマートコントラクトの執行のために用いられる。当該スマートコントラクトは、後述する報酬／インセンティブ付与のためのトークン管理の他に、クラウドデザインに係る保存／参照に対応付けられた処理に係る執行内容が記述される。

仮想マシンＥＶＭにおける仮想ストレージは、クラウドデザイン保存のために用いられる。当該仮想ストレージは、Ｋｅｙ―Ｖａｌｕｅ−Ｓｔｏｒｅ（ＫＶＳ）の態様で保存される構成としてもよい。

本実施形態におけるブロックチェーンＢＣ上の、トランザクション実行、及び、アカウント状態（ａｃｃｏｕｎｔ ｓｔａｔｅ）に係る処理を、図６を交えて、説明する。

図６（ａ）に示すとおり、コントラクトコードを有するコントラクトアカウント（ＣＡ：ｃｏｎｔｒａｃｔ ａｃｃｏｕｎｔ）生成、若しくは、アカウントに対する処理（ｍｅｓｓａｇｅ ｃａｌｌ）を指定するトランザクションは、ＡＰＩ（Ｗｅｂ３ＡＰＩ）を介して入力処理／実行される。さらに、分散ネットワークＤＮＷにおける状態確認（ｉｎｓｐｅｃｔｉｏｎ）も同様に行われる。

ノード２は当該ＡＰＩを介して、ノード２に対応付けられたプライベートキー（秘密鍵）に基づきトランザクションを実行する。本実施形態では、ウェブウォレットを介して当該トランザクションを実行する構成としてもよいし、Ｊａｖａ Ｓｃｒｉｐｔ（登録商標）言語に基づいた仮想マシンとＡＰＩとを介して当該トランザクションを実行する構成としてもよい。このとき、後述するトークンに係る表示処理は、当該ウェブウォレット又はクライアント型ウォレット上で行われる構成としてもよい。

トランザクションに含まれるｍｅｓｓａｇｅ ｃａｌｌでは、送信者の設定により、ｉｎｐｕｔ ｄａｔａが付与される。また、当該トランザクションが実行された場合、ｏｕｔｐｕｔ ｄａｔａが付与される。当該ｏｕｔｐｕｔ ｄａｔａは、コントラクトアカウントによる参照対象となる。

図６（ｂ）に示すとおり、分散ネットワークＤＮＷにおけるアカウント状態は、コントラクトアカウント（ＣＡ）と外部アカウント（ＥＯＡ：ｅｘｔｅｒｎａｌｌｙ ｏｗｎｅｄ ａｃｃｏｕｎｔ）と、に大別される。分散ネットワークＤＮＷ上で実行されるトランザクションは、ＥＯＡ／ＣＡ間で処理を行う。

なお、本実施形態におけるトランザクション処理には、ＥＯＡによるトランザクションと、ＣＡ間の内部トランザクションと、が含まれる。

ＥＯＡ／ＣＡは固有のアドレスに対応付けられたノンス及び通貨保有量（ｂａｌａｎｃｅ）に係る情報を含む。ＣＡは、前述の仮想マシンＥＶＭの記載にもある通り、コントラクトコード及びストレージに係る情報が対応付けられている。

本実施形態におけるＥＯＡアドレスは、プライベートキーを元に暗号化生成されたパブリックキー（公開鍵）に基づいたハッシュ値である構成が好ましい。このとき、ＣＡアドレスは、ＥＯＡアドレス及びノンスに基づき、生成される。本実施形態におけるハッシュ値生成のためのハッシュ関数は、ＲＳＡ方式やＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）方式を例とする、離散対数問題の困難性を利用した暗号方式であれば、特に制限はない。

図６（ｃ）に示すとおり、本実施形態におけるクラウドデザイン管理に係るスマートコントラクトの執行は、ＥＯＡを送信者とするトランザクションの実行を転機として行われる。当該トランザクションによりＣＡは、対応付けられたコントラクトコードに基づき、スマートコントラクトを執行する。このとき、その他のＣＡに処理を指定する内部トランザクションを実行する。つまり、本実施形態におけるクラウドデザイン管理プログラムは、複数のＣＡに横断し、トークン管理を含む種々の処理を行う構成としてもよい。

本実施形態における分散ネットワークＤＮＷは、採用されるブロックチェーンＢＣに応じて、ブロック及び仮想マシンが有する情報も適宜、変更される。

融通手段２５は、分散ネットワークＤＮＷを構成するブロックチェーン上での、トークンインフレーションにより、クラウドデザインの提供を含む共有行為に係る報酬／インセンティブを生成する。当該報酬は、所定期間毎に設計情報Ｄ０の提供者に付与される。

図７（ａ）に示すとおり、本実施形態における融通手段２５による報酬／インセンティブの付与は、異なる処理内容に対応付けられた複数のコントラクトアカウントからなるスマートコントラクトに基づき行われる構成が好ましい。

本実施形態における分散ネットワークＤＮＷ上の仮想マシンＥＶＭに格納されるクラウドデザイン管理プログラムＥＶＭ１００１は、更新機能が付加される構成としてもよい。当該更新機能は、評価値の不当な獲得を目的とした悪意あるクラウドデザイン保存に対応するため付与される。本発明は、ブロックチェーン及び合意形成アルゴリズムの種別に制限がないことを含め、半中央集権性を示す構成としてもよい。

ユーザによるトランザクション実行を転機として、設計情報Ｄ０の保存が行われる他、トークンに係る取引が行われる（ステップＳ１１）。このときスマートコントラクトにおいては、クラウドデザインに係る処理を行うサービスコントラクト（ｓｅｒｖｉｃｅ ｃｏｎｔｒａｃｔ）と、トークン生成とその収支バランスを管理するトークンコントラクト（ｔｏｋｅｎ ｃｏｎｔｒａｃｔ）とが協調し、設計情報Ｄ０に基づいた報酬／インセンティブの付与が行われる（ステップＳ１２）。

ステップＳ１２におけるサービスコントラクト及びトークンコントラクトの協調は、ユーザによるトランザクション実行を交えて、図７（ｂ）のように図示される。

ユーザによるトランザクション実行は、トークンコントラクトに対し送信者（ユーザ）のトークン残高に基づくトークン転送の許可申請を行う（ステップＳ１０１）。当該トランザクションに係る関数には、アドレス並びに値に係る情報が少なくとも含まれる。

ユーザによるトランザクション実行は、サービスコントラクトに対するデータ入力を含むサービス利用に係る申請を行う（ステップＳ１０２）。当該トランザクションは、トークン転送に係るトランザクションと併せて行われる構成としてもよいし、個別に、何れかのトランザクションのみが実行される構成としてもよい。

サービスコントラクトは、送信者のトークンがサービスコントラクトに転送されたように振る舞う。具体的には、トークンコントラクトに対しトークン状態に係る状態遷移を指示する内部トランザクションを実行する（ステップＳ１０３）。本実施形態におけるトークンは、ＫＶＳの態様で仮想マシンＥＶＭにその資産情報が記憶される。

最後に、トークン転送等を条件とするコントラクト執行が、サービスコントラクトにより行われる（ステップＳ１０４）。本実施形態において執行されるコントラクトに係る内容は、分散ネットワークＤＮＷ上に保存された設計情報Ｄ０に基づく報酬／インセンティブの付与の他に、設計情報Ｄ０に係る評価値の通知等を含む。

融通手段２５は、提供された設計情報Ｄ０に係るクラウドデザインの評価値と、スマートコントラクトに対応付けられたトークンに係る発行量、保有量及び保有期間の少なくとも１つに基づき、提供者であるユーザへの当該トークンの配布量が決定される。

本実施形態の一例では、トークン保有者全員のトークン保有量の総和としての発行量（Ｈ）及び当該クラウドデザインの作成者のトークン保有量（Ｈ’）に基づき、配布量が決定される。

なお、本実施形態における報酬としてのトークン配布は、設計情報Ｄ０を分散ネットワークＤＮＷに入力したＥＯＡに対応付けられるネットワーク参加者のみならず、設計情報Ｄ０上のアクターオブジェクトＯＢＪ１に記載された１以上の作成者／設計者に対して、行われる構成としてもよい。

融通手段２５は、評価値と、式（６）で表されるクラウドデザイン作成者のトークン保有比率（Ｏ）とに基づきデータベース貢献度（Ｐ）を決定し、当該データベース貢献度及び生成された追加発行量のトークン（ｒ）とに基づき、式（７）のように、配布量（Ｒ）を決定する。このとき、標準レート（Ｂ．Ｒ．）と、データベース貢献度との積が配布量の上限となる。

本実施形態における標準レートの値は、一例として、３×１０^−５となる。当該標準レートは、悪意あるユーザによる膨大な量の設計情報Ｄ０の保存を転機とする追加発行トークンの寡占を防ぐために、設定される。

報酬の残量が当該追加発行量を下回る場合、当該残量の一部は、トークン価値への還元を目的として無効化される。当該無効化は、ブロックチェーン上の所定のアドレスを指定したトランザクションの実行により、行われる構成が好ましい。

本実施形態において、追加発行されたトークンの一部は、ボラティリティー抑制のために実効性を付与されない構成が好ましい。当該トークンの中で実効性が付与されるトークン量は、配布日からの経過日数を変数とするシグモイド関数に基づき、式（８）および式（９）のように決定される。

数式８では、時間（ｔ）と初回交換レート（Ｆ．Ｅ．Ｒ：Ｆｉｒｓｔ Ｅｘｃｈａｎｇｅａｂｌｅ Ｒａｔｉｏ）と最大交換レート（Ｍ．Ｅ．Ｒ：Ｍａｘ Ｅｘｃｈａｎｇｅａｂｌｅ Ｒａｔｉｏ）とに基づき、実効レートが決定される。このとき、一例として、Ｆ．Ｅ．Ｒ及びＭ．Ｅ．Ｒは、１％及び１００％となり、定数（ｒ）は０．１となる。この場合、約１４５日経過することで、実効レートは１００％となる。

本実施形態では、任意のＥＯＡが、配布量以上のトークンを所定期間以上、保有していない場合、当該ＥＯＡに対するトークン送付を指定するスマートコントラクトの執行と、トランザクション処理と、が実行されない構成が好ましい。

本実施形態における、クラウドデザインを示す設計情報Ｄ０は、分散ネットワークＤＮＷへの参加者に対して無償で提供される構成が好ましい。融通手段２５によるトークン流通は、分散ネットワークＤＮＷへのクラウドデザイン提供者に対する報酬／インセンティブの付与を目的としている。

図８に示すとおり、本実施形態に係るクラウドデザインに関する依頼は、分散ネットワークＤＮＷ上の設計情報Ｄ０に基づき、スマートコントラクトを介して行われる。

クラウドデザインに係る設計情報Ｄ０におけるアクターオブジェクトＯＢＪ１、リソースオブジェクトＯＢＪ２及びコンテキストオブジェクトＯＢＪ３を含むオブジェクトにおいてデータが入力されている場合、当該クラウドデザインに係るカスタマイズ／監査を依頼することができる（依頼スキームＲ１）。

クラウドデザインに係る設計情報Ｄ０においてアクターオブジェクトＯＢＪ１に係るデータ入力のみが行われている場合、分散ネットワークＤＮＷの参加者に対して当該クラウドデザインに係る発注を依頼できる（依頼スキームＲ２）。

クラウドデザインに係る設計情報Ｄ０においてリソースオブジェクトＯＢＪ２のみがデータ入力されている場合は、当該クラウドデザインにとって好適なサービス内容の作成を依頼することとなる（依頼スキームＲ３）。なお、本実施形態における依頼は、設計情報Ｄ０に含まれるメタデータを用いて行われてもよいし、ブラウザ等を用いて依頼内容を表示処理する構成でもよい。

本実施形態におけるクラウドデザインに係る依頼は、設計情報Ｄ０上のオブジェクトに対するデータ入力が行われることで完遂される。なお、当該依頼を完遂したユーザに対してはトークンが付与される構成が好ましい。

本実施形態における分散ネットワークＤＮＷ上のトークン流通は、クラウドデザインのカスタマイズ／サービス構築／監査に係る依頼を含む、ＩＴインフラストラクチャーのアウトソーシング手段として、その利用用途を拡充する。

クラウドデザインに係るカスタマイズ／サービス構築／監査の場合、依頼者は、分散ネットワークＤＮＷ上で、所定量のトークンを発注先に送信する。当該カスタマイズ／サービス構築／監査には、特定機能に係るデプロイ先の変更、対応可能なアクセス数の向上や、クラウドデザインに基づくクラウドアーキテクチャに係る品質チェック等が含まれる。これにより、分散ネットワークＤＮＷは、エンジニア、プランナーを含むクリエイターの能力交換を実現するタレントシェアリングエコノミーとして、機能する。

分散ネットワークＤＮＷ上でのカスタマイズ／サービス構築／監査に係る依頼は、依頼内容に対応付けられた設計情報Ｄ０に係る納期が設定される構成としてもよい。当該納期を超過した上で当該設計情報を含むトランザクションが実行される場合や、依頼内容に沿わない要件を違反する設計情報を含むトランザクションが実行された場合は、依頼に先立って発注先へ送信された報酬（トークン）が没収される構成としてもよい。このとき、当該トークンは、依頼者側へ還元される。当該違反に係る判定は、鑑定手段２３による評価値の決定に基づき行われる構成が好ましい。なお、当該納期は、設計情報Ｄ０においてメタデータとして記述される構成としてもよい。

分散ネットワークＤＮＷ上でのカスタマイズ／サービス構築／監査に係る依頼は、コンペティション等を想定した、発注先を限定しない態様で関連するトランザクションが実行される構成としてもよい。

本実施形態では、依頼者が希望する要件等を含む依頼内容に係る情報と当該依頼に対応付けられた報酬設定に係る情報とが含まれるトランザクションが実行され、第三者により当該依頼内容を満たすクラウドデザインに係る設計情報を含むトランザクションが実行された場合、当該第三者に対して、設定された報酬が付与される。なお、依頼達成を転機として、当該第三者に係る情報が、依頼に対応付けられる設計情報Ｄ０上のアクターオブジェクトＯＢＪ１に追加される。

また、本実施形態における分散ネットワークＤＮＷは、クラウドデザイン作成に係るワークフロー管理のためにも用いられる。ＣＤＭＬ言語で記述された設計情報に基づく共通のインターフェースにより、要求仕様（要件）、設計、監査を統合的に実施可能となる。

分散ネットワークＤＮＷを用いたワークフロー管理の過程で編集が行われた設計情報は、ＣＤＭＬ言語の形式で、クラウドベンダーへの発注データを含めるため、クラウドデザイン作成／クラウドコンピューティング調達の効率化を実現できる。

本実施形態におけるクラウドデザインは、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ：モノのインターネット）基盤、基幹業務システム、制御系システム等が対象であり、その種別に、特に制限はない。

承認手段２６は、分散ネットワークＤＮＷ上のブロック承認を行うために用いられる。当該承認は、ノード２が有するハッシュレート、及び／又は、ステーク量に基づいて行われる構成が好ましい。

本実施形態におけるブロック承認は、ブロックに対応付けられたブロックヘッダーが有するハッシュ値（ｍｉｘＨａｓｈ）及びノンスと当該ブロックにおけるシードとに基づき生成された有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）から、当該ノンスと整合性をもつハッシュ値を生成することで、行われる。ハッシュレートとは、当該生成を行うためのコンピューティング能力の多寡を指す。

本実施形態におけるブロック承認は、コンピューティング能力に依存せず、ノード２が有する分散ネットワークＤＮＷ上の資産量に応じて、ブロック生成者を決定してもよい。このとき、資産の保有数及び保有期間に基づく資産年齢に基づき、当該決定が行われる。

本実施形態におけるクラウドデザインデータベース１は、その用途を、クラウドデザイン管理に限定しない。一例として、オブジェクト指向ソフトウェア開発におけるデザインパターンの好適な管理のために用いられる構成としてもよい。

クラウドデザインデータベース１は、所定のマークアップ言語により記述可能な意匠に係る情報であれば、その機能を最大限に発揮できる。例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のウェブページに係るデザイン情報や、ＴｅＸ等のマークアップ言語で記述された文書情報や、ＳＢＭＬ（Ｓｙｓｔｅｍｓ Ｂｉｏｌｏｇｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の生命に係る構成要素を電子回路上のコンポーネントと見立てる生物モデルに対しても、有効である。

本発明によれば、オープンデータネイティブかつブロックチェーンネイティブなクラウドデザインデータベースに基づき、不特定多数のユーザから提供されたクラウドデザインに改竄耐性を付与し、報酬の供与を含むエコノミーモデルを構築することができる。

本発明によれば、オープンデータの二次利用を基盤とした、エンジニアやデザイナー等のクラウドデザイン提供者によるデザインの売買のみに依らないタレントシェアリングマーケットを、実現できる。

１ クラウドデザインデータベース
２ ノード
２１ 入力手段
２２ 表示手段
２３ 鑑定手段
２４ 実行手段
２５ 融通手段
２６ 承認手段
２０１ 演算装置
２０２ 主記憶装置
２０３ 補助記憶装置
２０４ 入力装置
２０５ 出力装置
２０６ 通信装置
２００１ ＯＳ
２００２ クラウドデザイン管理プログラム
２００３ ＡＰＩ
ＢＣ ブロックチェーン
ＢＵ バックアップ装置
ＣＡ コントラクトアカウント
Ｄ０ 設計情報
ＤＮＷ 分散ネットワーク
ＥＯＡ 外部アカウント
ＥＶＭ 仮想マシン
ＥＶＭ１０１ 仮想演算装置
ＥＶＭ１０２ 仮想主記憶装置
ＥＶＭ１０３ 仮想補助記憶装置
ＥＶＭ１００１ クラウドデザイン管理プログラム
ＯＢＪ１ アクターオブジェクト
ＯＢＪ２ リソースオブジェクト
ＯＢＪ３ コンテキストオブジェクト
Ｒ１、Ｒ２、Ｒ３ 依頼スキーム
Ｓ１１、Ｓ１２、Ｓ１０１、Ｓ１０２、Ｓ１０３、Ｓ１０４ ステップ

Claims (20)

1. クラウドデザイン管理方法であって、
   分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行ステップと、
   前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量と、前記分散ネットワークへの参加者に対する前記トークンの配布量と、を決定する融通ステップと、をコンピュータのプロセッサに実行させること、
   を特徴とするクラウドデザイン管理方法。
2. 前記分散ネットワークは、１以上のパブリックノードからなり、プルーフ・オブ・ワーク方式及び／又はプルーフ・オブ・ステーク方式の合意形成アルゴリズムに基づくブロックチェーンネットワークであり、前記スマートコントラクトの執行又は前記設計情報の共有のための記憶領域を保持する仮想マシンを有すること、
   を特徴とする請求項１に記載のクラウドデザイン管理方法。
3. 前記設計情報は、前記クラウドデザインに係るサービス利用者を示す情報を含むアクターオブジェクトと、前記クラウドデザインに係るシステム要件を示す情報を含むリソースオブジェクトと、前記アクターオブジェクトと前記リソースオブジェクトの相関に係る情報を示すコンテキストオブジェクトとを含み、マークアップ言語に基づき記述されること、
   を特徴とする請求項１又は２に記載のクラウドデザイン管理方法。
4. クラウドデザイン管理方法であって、
   前記設計情報に係る類似度及び評価値を決定する鑑定ステップを、有し、
   前記鑑定ステップは、形態素解析により前記分散ネットワークにおける前記設計情報に係る特徴量を抽出し、当該設計情報に係る中心性尺度の決定と、前記類似度の決定と、を行うこと、を特徴とする請求項１〜３の何れかに記載のクラウドデザイン管理方法。
5. 前記鑑定ステップは、前記設計情報の変更を転機とした前記評価値に係る変動が生じた場合、変動した前記評価値と当該設計情報に係る前記評価値の最高値との差分に基づき、前記評価値を更新すること、
   を特徴とする請求項４に記載のクラウドデザイン管理方法。
6. 前記鑑定ステップは、前記設計情報に係るシステム要件を示す要件情報、前記設計情報に係るシステム稼働実績を示す実績情報、前記設計情報に係る参照元としての前記クラウドデザインの数量を示す参照情報、及び、前記設計情報に係るクラウドデザイン作成者を示す設計者情報の少なくとも１つに基づき、前記評価値を決定すること、
   を特徴とする請求項４又は５に記載のクラウドデザイン管理方法。
7. 前記鑑定ステップは、前記設計情報において、前記要件情報、実績情報、参照情報及び設計者情報が入力されている場合、当該設計情報に係る前記評価値を加算すること、
   を特徴とする請求項６に記載のクラウドデザイン管理方法。
8. 前記融通ステップは、前記トークンに係る前記参加者間の送受を行うための前記トランザクション処理を受け付けること、
   を特徴とする請求項４〜７の何れかに記載のクラウドデザイン管理方法。
9. 前記融通ステップは、前記実行ステップにより、前記設計情報の入力を含む前記トランザクション処理を実行した前記参加者に対して、前記トークンに係る前記配布量を決定し、
   前記実行ステップは、当該決定に基づく前記トークンの配布を含むスマートコントラクトの執行と、当該執行に係るトランザクション処理の実行と、を行うこと、
   を特徴とする請求項４〜８の何れかに記載のクラウドデザイン管理方法。
10. 前記実行ステップは、前記参加者に対する前記トークンの配布を含むスマートコントラクトの執行、及び、当該執行に係るトランザクション処理の実行を、所定期間毎に、前記参加者に対応付けられた前記設計情報の変更が行われている場合に行うこと、
    を特徴とする請求項９に記載のクラウドデザイン管理方法。
11. 前記融通ステップは、前記トークンに係る前記発行量と、前記参加者により前記分散ネットワーク上に入力された前記設計情報に係る前記評価値、前記参加者に係る前記トークンの保有量、及び、前記参加者に係る前記トークンの保有期間の少なくとも１つと、に基づき、前記参加者に対する前記配布量を決定すること、
    を特徴とする請求項９に記載のクラウドデザイン管理方法。
12. 前記実行ステップは、前記参加者が、前記配布量以上の前記トークンを、所定期間以上、保有していない場合、当該参加者に対する前記トークンの配布を含むスマートコントラクトの執行と、当該執行に係るトランザクション処理の実行と、を行わないこと、
    を特徴とする請求項９に記載のクラウドデザイン管理方法。
13. 前記融通ステップは、前記トークンに係る前記発行量及び前記参加者に係る前記トークンの保有量に基づく前記トークンの保有比率と、前記参加者により前記分散ネットワークに入力された１以上の前記設計情報に係る前記評価値の総和と、に基づき決定されるデータベース貢献度を決定し、前記トークンに係る追加発行量及び前記データベース貢献度に基づき前記トークンに係る前記配布量を決定すること、
    を特徴とする請求項９に記載のクラウドデザイン管理方法。
14. 前記融通ステップは、前記データベース貢献度と所定の配布レートとの積を、前記トークンに係る前記配布量の上限とすること、
    を特徴とする請求項１３に記載のクラウドデザイン管理方法。
15. 前記融通ステップは、追加発行された前記トークンに係る実効性付与の比率を、当該追加発行からの経過時間を変数とするシグモイド関数に基づき決定すること、
    を特徴とする請求項１３に記載のクラウドデザイン管理方法。
16. 前記実行ステップは、前記参加者による前記クラウドデザインに係る作成又は監査に係る依頼と、当該依頼に対応付けられる前記トークンの報酬量に係る設定と、を行うためのトランザクション処理を実行すること、
    を特徴とする請求項１〜１５の何れかに記載のクラウドデザイン管理方法。
17. 前記実行ステップは、前記依頼に基づく前記設計情報を含む前記トランザクション処理が、前記参加者により実行されることを転機として、前記報酬量の前記トークンを当該参加者に対する配布を行うためのスマートコントラクトの執行と、当該執行に対応付けられたトランザクション処理を実行すること、
    を特徴とする請求項１６に記載のクラウドデザイン管理方法。
18. 前記実行ステップは、前記依頼に基づく前記設計情報を含む前記トランザクション処理を行われた場合、少なくとも前記参加者に係る情報を前記設計情報に追加し更新すること、
    を特徴とする請求項１６に記載のクラウドデザイン管理方法。
19. クラウドデザインデータベースであって、
    分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行手段と、
    前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量の決定と、前記分散ネットワークへの参加者に対する前記トークンの配布量の決定と、を行う融通手段と、を有すること、
    を特徴とするクラウドデザインデータベース。
20. クラウドデザイン管理プログラムであって、
    コンピュータを、分散型台帳技術に基づく分散ネットワークにおいて、クラウドデザインを含む設計情報に基づくスマートコントラクトに係る執行と、前記設計情報の共有及び／又は前記執行に係るトランザクション処理の実行と、を行う実行手段と、
    前記設計情報に基づき、前記スマートコントラクトに対応付けられたトークンに係る発行量の決定と、前記分散ネットワークへの参加者に対する前記トークンの配布量の決定と、を行う融通手段と、として機能させること、
    を特徴とするクラウドデザイン管理プログラム。