JP2021513179A - ブロックチェーンを基にした同意管理システムおよび方法 - Google Patents

Abstract

ブロックチェーンを基にした同意管理システムが、ブロックチェーンについての同意データへのアクセスおよび／または同意データに対応するトランザクションを求める、許可されたウェブユーザ要求を受信および処理するように構成されたウェブサーバサブシステムであって、ブロックチェーン・サブシステム・インターフェースを備えるウェブサーバサブシステムと、少なくとも2つの組織を有するチャネル、対応するチェーンコード、および承認ポリシーを定義するブロックチェーンサブシステムであって、少なくとも2つの組織のそれぞれが少なくとも1つのピアを有し、少なくとも1つのピアのそれぞれがブロックチェーンコピーを維持し、ブロックチェーンサブシステムがブロックチェーン・サブシステム・インターフェースと通信するオーダラーを備えるブロックチェーンサブシステムとを含む。

Description

関連出願の相互参照
本願は、参照によりその内容全体が本明細書に組み込まれる、2018年2月12日に出願された米国仮特許出願第62/629,412号の優先権を主張する。

以下は、概して、コンピュータが実行する医療および他の患者およびステークホルダ同意管理システムに関し、より詳細にはブロックチェーンを基にした同意管理システムおよび方法に関する。

医療提供システムのための、適切で効率的な同意の取得、管理、維持、および共有は困難である。これは特に、同意を含む患者の個人情報または医療関連情報が、注意深く安全な扱いを必要とするような、非常に注意を要するものと考えられるからである。さらに、同意を収集および管理するそれぞれの方法を有する患者、規制者、医師、病院、診療所、救急隊員、臨床試験を実施する製薬会社、規制者などの、医療システム内のステークホルダの数が多く、変動する。さらに、様々なタイプの同意があり、それぞれ考慮すべき点を有する。たとえば、同意には、患者を治療するための同意、患者についての情報を保護するための同意、患者の権利、マーケティング同意、自動ダイヤル同意、カスタマイズ可能な同意、インフォームドコンセント、および情報を共有するための同意が含まれ得る。他の形態の同意があり得、医療規制、治療、およびシステムが進化につれて必要となり得る。同意は、各管轄区域にわたって異なり得、患者の性質または年齢、および同意を与える患者の能力に応じて異なり得る。

患者および他の医療システムステークホルダについての同意の管理を集中化するための様々なシステムが提案されている。より最近では、同意に関するデータの不変かつ長期の記憶のため、および患者についての不変の同意記録へのアクセスを制御するためにブロックチェーンを活用するシステムが提案されている。たとえば、Curbera他の米国特許出願公開第2018/0082023号は、マスタ患者記録インデックスによって提供される患者記録ロケータを使用して、ある医療提供者が別の医療提供者に患者情報を直接的に要求することを可能にする、安全な分散型患者同意および情報管理システムおよび方法を開示している。

システムおよび方法が提案されているが、改良が望ましい。

一態様によれば、ブロックチェーンについての同意データへのアクセスおよび／または同意データに対応するトランザクションを求める、許可されたウェブユーザ要求を受信および処理するように構成されたウェブサーバサブシステムであって、ブロックチェーン・サブシステム・インターフェースを備える、ウェブサーバサブシステムと、少なくとも2つの組織を有するチャネル、対応するチェーンコード、および承認ポリシーを定義するブロックチェーンサブシステムであって、少なくとも2つの組織のそれぞれが少なくとも1つのピアを有し、少なくとも1つのピアのそれぞれがブロックチェーンコピーを維持し、ブロックチェーンサブシステムがブロックチェーン・サブシステム・インターフェースと通信しているオーダラーを備える、ブロックチェーンサブシステムとを備える、ブロックチェーンを基にした同意管理システムが提供される。

一実施形態では、ブロックチェーンサブシステムとウェブサーバサブシステムが通信し、それによって、ブロックチェーンについてのトランザクションを求める許可された要求が、ウェブサーバサブシステムに、個々の承認のためにブロックチェーン・サブシステム・インターフェースを介してブロックチェーンサブシステムのチャネルピアにルーティングされるべきトランザクション提案を生成させ、ピアからの承認応答を受信させ、承認応答が集合的に承認ポリシーを満たす場合、ブロックチェーンの追加のブロック内に含めるために、承認されたトランザクションをオーダラーに送信させ、オーダラーが、ピアのブロックチェーンコピーのそれぞれの中に追加のブロックを記憶させるように構成される。

一実施形態では、ウェブサーバサブシステムは、システムのための認証局と通信している。

一実施形態では、ウェブサーバサブシステムは、要求キューを介して第2の自動スケーリンググループと通信している第1の自動スケーリンググループを備え、第1の自動スケーリンググループは、第2の自動スケーリンググループによる消費のために、ユーザ要求に対応する要求を要求キュー内に保管する。

一実施形態では、第1の自動スケーリンググループは、ユーザインターフェースおよびアプリケーションミドルウェア構成要素を有する1つまたは複数のNode JSウェブサーバを備える。

一実施形態では、第2の自動スケーリンググループは、ハイパーレッジャー・ファブリック・インターフェースのインスタンスを有する1つまたは複数のNode JSウェブサーバを備える。

一実施形態では、ウェブサーバサブシステムは、第1の自動スケーリンググループ内のウェブサーバインスタンスにユーザ要求をルーティングする負荷平衡構成要素をさらに備える。

本明細書において開示される実施形態は様々な利点をもたらす。たとえば、ブロックチェーンを基にしたシステムは、同意情報を保護するためのセキュリティー、機密性、および監査可能性の恩恵をもたらす。本明細書において開示されるようにブロックチェーン内に記憶された同意情報は、不変であり、適切な権限なしに進入する、すなわちハッキングすることが極めて困難である。

ウェブを基にしたアプリケーションを利用する実施形態は、許可されたユーザがシステムおよびそのデータとどのように対話することができるかに関して著しい制限を課すことなく、ブロックチェーンデータへのアクセスおよび追加にわたる強力な制御を実現し、ブロックチェーンデータに直接的に関係しないことがある他のアプリケーション特徴の配置を可能にするのに適している。本明細書において開示されるシステムの実施形態はまた、組織やピアなどの追加のエンティティを組み込み、新しい、または修正されたチェーンコードを介して、新しい、またはより洗練されたビジネスロジックを配置し、アクセス制御リストを調節および配置するように容易にスケーリングされる。システムの柔軟性により、ネットワークが成長し、より洗練され、規制および他の変更に適応し、一般には、実際にそうであるように過度の混乱なしにユーザにとってより有益なものとなることが可能となる。

本明細書において開示される実施形態は、組織に対して行われた変更、組織、ピアの追加または除去、およびネットワークに対する他の修正の後に続くユーザを基にした増加および減少に応答して、システムを自動的に拡張および収縮させ、またはより良好な地理的可用性を提供するために、自動スケーリンググループおよび／もしくは負荷平衡を提供することによって、ならびに／またはクラウドサービスの使用によって潜在的ネットワーク・トラフィック・ボトルネックに対処する。

以下の説明および図面から様々な他の実施形態および利点が明らかとなるであろう。

次に、添付の図面を参照しながら、本発明の実施形態が説明される。

一実施形態による、ブロックチェーンを基にした同意管理システムを示す概略図である。 図1のブロックチェーンを基にした同意管理システムのウェブサーバサブシステムの構成要素を示す拡大概略図である。 図1のブロックチェーンを基にした同意管理システムのブロックチェーンサブシステムの構成要素を示す拡大概略図である。 一実施形態による、図1のブロックチェーンを基にした同意管理システムの1つまたは複数の構成要素についてのハードウェアプラットフォームとして適しているコンピューティングシステムのハードウェアアーキテクチャを示す概略図である。

図1は、一実施形態による、コンピュータを基にしたブロックチェーンを基にした同意管理システム10を示す概略図である。この実施形態によるブロックチェーンを基にした同意管理システム10は、ハイパーレッジャー・ファブリック・フレームワーク(hyperledger fabric framework)(たとえば、https://www.hyperledger.org/projects/fabricを参照)の特徴を使用して実装される。この実施形態では、ウェブサーバサブシステム20は、ブロックチェーンについての同意データへのアクセスおよび／または同意データに対応するトランザクション、ならびにブロックチェーンに直接的に関係しない他の機能へのアクセスを求める、許可されたウェブユーザ要求をユーザ5A、5B、5C、5D、および任意の他のネットワーク参加者から受信および処理するように構成される。ウェブサーバサブシステム20はブロックチェーン・サブシステム・インターフェース40を含む。ブロックチェーンを基にした同意管理システム10はまた、ウェブサーバサブシステム20のブロックチェーン・サブシステム・インターフェース40と通信しているブロックチェーンサブシステム60を含む。この実施形態では、ブロックチェーンサブシステム60は、複数の組織64A、64B、64Cなどを有するチャネル62、対応するチェーンコード、および承認ポリシー(図示せず)を定義し、少なくとも2つの組織64A、64Bなどのそれぞれは、この実施形態では複数のピアPを有する。チャネル62の組織64A、64Bなどの複数のピアPのそれぞれは、ブロックチェーンコピー(図示せず)を維持する。この実施形態では、各組織64A、64Bなどについての少なくとも1つのピアPが、アンカーピアとして指定され、アンカーピアは、チャネル62内の別の組織のアンカーピアと通信することが可能となる。この実施形態では、組織64Aの右下のピアPがアンカーピアであり、組織64Bの右上のピアPがアンカーピアである。ブロックチェーンサブシステム60のオーダラー(orderer)80が、ブロックチェーン・サブシステム・インターフェース40と通信している。

動作の際に、ブロックチェーンサブシステム60とウェブサーバサブシステム20が通信し、それによって、ウェブアプリケーション22を介するブロックチェーンについてのトランザクションを求める許可された要求が、ウェブサーバサブシステム20に、個々の承認のためにブロックチェーン・サブシステム・インターフェース40を介してブロックチェーンサブシステム60のチャネルピアPにルーティングされるべきトランザクション提案を生成させ、ピアPからの承認応答を受信させる。承認応答が集合的に承認ポリシーを満たす場合、ブロックチェーンの追加のブロック内に含めるために、承認されたトランザクションをオーダラー80に送信する。さらに、オーダラー80は、ピアPによって維持されるブロックチェーンコピーのそれぞれの中に追加のブロックを記憶させるように構成される。

図2は、この実施形態による、ブロックチェーンを基にした同意管理システム10のウェブサーバサブシステム20の構成要素を示す拡大概略図である。ネットワーク参加者によって使用中のデバイス上で動作する個々のウェブブラウザを通じてアクセス可能なウェブアプリケーション22が、ウェブサーバサブシステム20への許可されたアクセスを実現し、ウェブサーバサブシステム20は、ブロックチェーンへのアクセスを実現し、またはブロックチェーンに直接的に関係しない他の機能を提供する。

この実施形態では、アプリケーション22は、HTTP REST API(Hypertext Transfer Protocol, Representational State Transfer, Application Programming Interfaces)を使用してウェブサーバサブシステム20の要求を行うウェブブラウザに配置され、ウェブサーバサブシステム20の自動スケーリンググループ内のNode JSウェブサーバ30の潜在的にいくつかのインスタンスのうちの1つからサービスされる。自動スケーリンググループは、入って来るトラフィック負荷の上昇および下落を効率的に処理するために、必要に応じてNode JSウェブサーバ30の複数のインスタンスをインスタンス化し、または漸減することを可能にするための機構である。この実施形態での、トラフィックを処理および配布するための負荷平衡サブシステム24は、ELB(Elastic Load Balancer)28と組み合わせたAmazon Route 53 DNSサービス26を含む。

アプリケーション22がサービスされるNode JSウェブサーバ30のインスタンスは、APIインターフェース32、Authミドルウェア34、データベースインターフェース38、および要求パブリッシャ36を提供するという点で、その自動スケーリンググループのすべてのメンバを代表する。APIインターフェース32は、アプリケーション22と対話するために、ならびに読み取り要求を生成し、トランザクションおよび他の操作を開始するためにユーザと対話するために、ユーザのウェブブラウザにユーザインターフェースを配置するために実行可能なユーザインターフェースコードを提供する。Authミドルウェア34は認証局(CA)サービスへのインターフェースを提供する。理解するであろうが、CAサービスは、特にX.509規格に準拠する暗号的に検証されたデジタル証明書を発行および維持することによって、ネットワーク内の各エンティティおよび参加者についての識別子を生成し、それによって、ピアP、組織64A、64B、64Cなど、オーダラー80などの識別を認証およびリンクする。MSP(メンバーシップ・サービスプロバイダ)構成は、各ピアPおよびオーダラー80にローカルに記憶される。データベースインターフェース38は、この実施形態ではキャッシングサポート52を備えるNoSQL DB50内の、セキュリティーグループによって維持される非ブロックチェーンのセキュリティー関連データへの制御されたアクセスを実現する。セキュリティーグループという用語は、たとえばhttps://blog.learningtree.com/understanding-amazon-ec2-security-groups-and-firewallsにおいて説明されているような、Amazonのネットワーク・セキュリティー・ポリシーのセットを指すために使用される。

データベースインターフェース38はまた、支援文書およびブロックチェーン上に記憶されている同意に関する他のデータを記憶するためのクラウドストレージサービス54、この実施形態ではAmazon Simple Storage Service(Amazon S3)への制御されたアクセスをも実現する。たとえば、Amazon S3 54は、それ自体の自動スケーリングプロセスにおいてその新しいインスタンスを作成するために使用される、Node JSウェブサーバ40のDockerイメージのような、配置および構成関連のアセットを記憶する。

要求パブリッシャ36は、アプリケーション22を介して提供されるユーザ要求に応答して行われる要求を保管するために、セキュリティーグループによって維持される要求キューRQとインターフェースする。

Node JSウェブサーバ40の第2の自動スケーリンググループが、主にブロックチェーン・サブシステム・インターフェースとして働くために提供される。この第2の自動スケーリンググループ内のNode JSウェブサーバ40のそれぞれは、ブロックチェーンに関するさらなる処理を求める要求を抽出するために、要求キューRQとインターフェースする要求コンシューマー42を含む。Node JSウェブサーバ40のそれぞれはまた、キャッシング52を備えるNoSQL DB 50内のセキュリティーグループによって維持される非ブロックチェーンのセキュリティー関連データへの制御されたアクセスのためのそれぞれのデータベースインターフェース46を含む。データベースインターフェース46はまた、Amazon S3クラウドストレージサービス54への制御されたアクセスを実現する。Node JSウェブサーバ40はまた、キー管理システム、この実施形態ではAmazon KMSとインターフェースする。

ファブリックインターフェース44は、Node JSウェブサーバ40がブロックチェーンサブシステム60とインターフェースすることを可能にする。図3は、ブロックチェーンサブシステム60の構成要素を示す拡大概略図である。この実施形態では、ブロックチェーンサブシステム60は、特にネットワーク内の参加者についての同意データの記憶、保守、およびアクセスを処理するためのチャネル62を維持するハイパーレッジャー・ファブリック・インスタンスである。

チャネル62は、それぞれのブロックチェーンを管理するための論理構造であり、クライアントについての、およびクライアントにわたる同意の管理を促進するために設立された健康情報検証組織の特定のクライアントなどの、プライベートデータの周りのコンソーシアムの形成を可能にする。この実施形態では、コンソーシアムが2つの組織64Aおよび64Bを含むように示されている。この実施形態では、オーダラー80は分散型KafkaおよびZookeeper ordererサービスである。

ハイパーレッジャー・ファブリック・フレームワークによれば、チャネル62は、1つまたは複数のチェーンコード(ビジネスロジックを確立するスマートコントラクト)、対応する承認ポリシー、およびアクセス制御リスト(ACL)に関連付けられる。この実施形態では、ACLは、それぞれの有効期限後に同意へのアクセスをブロックするために同意満了チェックを実施する。これらのチャネル属性は、その組織64A、64Bなどが包含についてピアPを許可している各ピアP上にそれぞれ記憶される。チャネル62内の各組織はまた、異なるブロックチェーンを維持し、チャネル62によって影響を受けず、またはチャネル62を通じてアクセス可能ではない別の異なるチャネルの一部であり得る。たとえば、この例では、組織64Aは、別々のチャネルについてのそれ自体のチェーンコードおよび承認ポリシーを有し、組織64Bは、別の別々のチャネルについてのそれ自体のチェーンコードおよび承認ポリシーを有する。組織64Aおよび64Bは、互いの、およびチャネルに追加され得る任意の他の組織との間の同意管理に対応するビジネスロジックを処理するために、他の組織(たとえば64C)と共に、チャネル62の部分でもある。

この実施形態では、特定の患者記録は、チャネル62のブロックチェーン内のアセットであり、以下の表1に示されるデータの少なくとも一部を含む。

この実施形態では、特定の同意記録は、チャネル62のブロックチェーン内のアセットであり、以下の表2に示されるデータの少なくとも一部を含む。

この実施形態では、特定の患者同意は、チャネル62のブロックチェーン内のアセットであり、以下の表3の内容を含む。

この実施形態では、同意被授与者は、以下の表4に従って識別されるチャネル62のネットワーク参加者である。

特定の同意確認またはブロックチェーンに対する他の変更を書き込むために、ユーザがアプリケーション22を介して行われる要求を行う場合、チャネル62についてのチェーンコードがチャネル62内の各ピアP上に呼び出され、それぞれのブロックチェーンコピーを通じてトランザクションが試行され、トランザクションがピアPにとって許容される場合、承認が与えられる。ピアPによってNode JSウェブサーバ40のファブリックインターフェース44に戻される、必要とされる承認が、そのチェーンコードについての承認ポリシーが満たされていることを検証する場合、ファブリックインターフェース44は、オーダラー80とインターフェースして、次のブロックチェーンブロックにトランザクションを追加するための命令を与える。命令に従って、オーダラー80は、トランザクションを新しいブロック内に配列し、新しいブロックを、ピアPによって維持されるブロックチェーンのそれぞれのコピーに追加されるようにチャネル内のすべての組織64A、64Bなどに送る。したがって、異なる組織64A、64Bなどであっても、チャネル62内のすべてのピアPが、ブロックチェーンの正確で最新のコピーを含むように意図される。チャネル62内のピアPを有する任意の他の組織が同様に処理され、チャネル62内にない他のピアPまたは組織は、チャネル62のブロックチェーンにアクセスして、それから読み取り、またはそれに書き込むことができない。

システム10を使用して同意タイプ、受信日付、先に与えられた同意が満了する日付を指す有効期限、個人の名前、誕生日、ZIPコードもしくは郵便番号、ユーザまたは特定の同意に固有の識別子、同意ステータスなどの様々なパラメータによって同意を検索および閲覧する能力を、許可されたユーザに与えることなどの様々な特徴が実装される。さらに、システム10は、許可されたユーザが同意のステータスを、オープンから、承認の保留、承認、満了などまで、そのライフサイクルを通じて更新することを可能にする。システム10はまた、チェーンコードおよびそれぞれの同意の適切で安全な規制に対応する承認ポリシーに従って企業間および企業内で同意を共有することを可能にする。

一実施形態では、ウェブサーバサブシステム20は、同意トランザクションを手動でロードし、バッチロードし、またはスケジューラに基づいて別のシステムから自動機構を使用してロードすることを可能にする。同意データがブロックチェーン内に記憶され、そのコピーが、ブロックチェーンが関係する所与のチャネル内のピアのそれぞれによって維持される。

一実施形態では、同意に対応するメタデータがブロックチェーン内に記憶され、あるいは安全に記憶され得、その結果、患者が関連する同意を与えることを示す内容を含むオーディオ、ビデオ、イメージファイルなどの同意を支援するデータ、または同意を与えるデータが、監査または他の規制目的で参照され得る。スケーラビリティのために、そのような支援文書が、ブロックチェーンの外部に、ブロックチェーン内に記憶されている同意データとは別々に記憶されることが好ましいことがある。

一実施形態では、同意は、適切な許可を通じて、医師から、その医師の許可の下で研究を行う下請研究会社になど、システム内のエンティティ間で伝達され得る。

一実施形態では、ウェブアプリケーション22を介してアクセスするユーザについて、様々な役割が確立され得る。たとえば、管理者ユーザ、読み取り専用アクセスなどである。さらに、実施形態では、ウェブアプリケーション22は、許可されたユーザがネットワークにエンティティを追加すること、異なる種類の同意および対応するチェーンコードおよび承認ポリシーをシステムに追加すること、ならびにシステム内からの警報の種類(SMS、プッシュ通知、eメール)を管理することを可能にする機能を配置する。

一実施形態では、システム10の内部ユーザと外部ユーザの両方が、特定の同意の存在についての情報の提供を受け、かつ／または同意がシステム10によって取り込まれていることを確認する能力を備え得る。実施形態は、同意が取り込まれたとき、承認されたとき、もしくは満了したとき、または別の方法で変更されたときなどに、同意がステータスを変更すると、指定されたユーザに警報を与え得る。

実施形態は、同意のライフサイクル全体にわたって同意に対する変更をログ記録し、同意ライフサイクルが監査され、あるいは別の方法で調査され得るように、そのようなログおよびレポーティングツールへのユーザインターフェースアクセスを提供する。

図4は、一実施形態による、図1のブロックチェーンを基にした同意管理システム10の1つまたは複数の構成要素についてのハードウェアアーキテクチャを示す概略図である。理解されるであろうが、ブロックチェーンを基にした同意管理システム10の構成要素は、オンデマンドでスループットを処理するように仮想サーバをそれ自体で配置し得るAmazon Web Service(AWS)などのクラウドサービスを使用して、様々な負荷平衡スキーマを使用して配置され得る。負荷平衡、拡張、地理的局所性などのために様々な技法を使用するアーキテクチャの様々な実装が利用され得る。

一実施形態では、コンピューティングシステム1000は、情報を伝達するためのバス1010または他の通信機構と、情報を処理するためのバス1010と結合されたプロセッサ1018とを含む。コンピューティングシステム1000はまた、情報およびプロセッサ1018によって実行されるべき命令を記憶するための、バス1010に結合された、ランダムアクセスメモリ(RAM)や他の動的記憶デバイス(たとえば、ダイナミックRAM(DRAM)、スタティックRAM(SRAM)、および同期型DRAM(SDRAM))などのメインメモリ1004をも含む。さらに、メインメモリ1004は、プロセッサ1018による命令の実行中に変数または他の中間情報を一時的に記憶するために使用され得る。プロセッサ1018は、命令の実行中にそのような一時変数または他の中間情報を記憶するためのレジスタなどのメモリ構造を含み得る。コンピューティングシステム1000は、プロセッサ1018についての静的情報および命令を記憶するための、バス1010に結合された読み取り専用メモリ(ROM)1006または他の静的記憶デバイス(たとえば、プログラマブルROM(PROM)、消去可能PROM(EPROM)、および電気消去可能PROM(EEPROM))をさらに含む。

コンピューティングシステム1000はまた、磁気ハードディスク1022および／またはソリッド・ステート・ドライブ(SSD)および／またはフラッシュドライブ、および取り外し可能メディアドライブ1024(たとえば、USBキーなどのソリッド・ステート・ドライブまたは外部ハードドライブ、フロッピーディスクドライブ、読み取り専用コンパクトディスクドライブ、読み取り／書き込みコンパクトディスクドライブ、コンパクトディスクジュークボックス、テープドライブ、および取り外し可能光磁気ドライブ)などの、情報および命令を記憶するための1つまたは複数の記憶デバイスを制御するために、バス1010に結合されたディスクコントローラ1008をも含む。記憶デバイスは、適切なデバイスインターフェース(たとえば、シリアルATA(SATA)、peripheral component interconnect(PCI)、small computing system interface(SCSI)、integrated device electronics(IDE)、エンハンストIDE(E-IDE)、direct memory access(DMA)、ウルトラDMA、ならびにクラウドを基にしたデバイスインターフェース)を使用してコンピューティングシステム1000に追加され得る。

コンピューティングシステム1000はまた、専用論理デバイス(たとえば、特定用途向け集積回路(ASIC))または構成可能論理デバイス(たとえば、シンプルプログラマブル論理デバイス(SPLD)、複合プログラマブル論理デバイス(CPLD)、およびフィールドプログラマブルゲートアレイ(FPGA))をも含み得る。

ユーザと直接的に対話しないハードウェアについて厳密には必要とされないが、コンピューティングシステム1000はまた、LED(発光ダイオード)ディスプレイ、有機LED(OLED)ディスプレイ、液晶ディスプレイ(LCD)ディスプレイ、またはコンピュータユーザに情報を表示するのに適した何らかの他のデバイスなどのディスプレイ1012を制御するためにバス1010に結合されたディスプレイコントローラ1002をも含み得る。実施形態では、ディスプレイコントローラ1002は、主にグラフィックス集約的な演算または他の高度に並列の演算を処理するための専用グラフィックス処理装置(GPU)を組み込む。そのような演算には、球体や立方体などの多角形を含むワイヤフレームオブジェクトにテクスチャリング、シェーディングなどを適用することによるレンダリングが含まれ得、それによって、コンピューティングシステム1000の全性能を犠牲にしてプロセッサ1018がそのような集約的演算を引き受けなければならないことが軽減される。GPUは、その動作中に生成されたデータを記憶するための専用グラフィックスメモリを組み込み得、ディスプレイ1012のピクセルを作動させるために使用されるビットマップとして処理結果を記憶するためのフレームバッファRAMメモリを含む。GPUは、OpenGL、Direct3Dなどのグラフィックス指向のアプリケーション・プログラミング・インターフェース(API)を使用して、コンピューティングシステム1000上で実行中のアプリケーションによる様々な動作を引き受けるように命令され得る。

ユーザと直接的に対話しないハードウェアについて厳密には必要とされないが、コンピューティングシステム1000は、コンピュータユーザと対話し、プロセッサ1018に情報を提供するための、キーボード1014やポインティングデバイス1016などの入力デバイスを含み得る。ポインティングデバイス1016は、たとえば、プロセッサ1018に方向情報およびコマンド選択を伝達し、ディスプレイ1012上のカーソル移動を制御するためのマウス、トラックボール、またはポインティングスティックであり得る。コンピューティングシステム1000は、タッチスクリーンなどの入力デバイスと結合されるディスプレイデバイスを利用し得る。赤外線検出器、ジャイロスコープ、加速度計、レーダー／ソナーなどを含むジェスチャ検出器などの、有線を介して、または無線でコンピューティングシステムにデータを提供するような他の入力デバイスが利用され得る。プリンタが、コンピューティングシステム1000によって記憶および／または生成されたデータの印刷されたリスティングを提供し得る。

コンピューティングシステム1000は、プロセッサ1018および／またはディスプレイコントローラ1002のGPUがメインメモリ1004などのメモリ内に含まれる1つまたは複数の命令の1つまたは複数のシーケンスを実行することに応答して、本明細書において論じた処理ステップの一部またはすべてを実行する。そのような命令は、ハードディスク1022や取り外し可能メディアドライブ1024などの別のプロセッサ可読媒体からメインメモリ1004内に読み取られ得る。中央演算処理装置と1つまたは複数のグラフィックス処理装置の両方を有するコンピューティングシステム1000などの複数処理構成内の1つまたは複数のプロセッサも、メインメモリ1004またはGPUの専用グラフィックスメモリ内に含まれる命令のシーケンスを実行するために利用され得る。代替実施形態では、ハード結線回路が、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用され得る。

前述のように、コンピューティングシステム1000は、本発明の教示に従ってプログラムされた命令を保持し、データ構造、テーブル、レコード、または本明細書において説明された他のデータを収容するための少なくとも1つのプロセッサ可読媒体またはメモリを含む。プロセッサ可読媒体の例は、ソリッド・ステート・デバイス(SSD)、フラッシュを基にしたドライブ、コンパクトディスク、ハードディスク、フロッピーディスク、テープ、光磁気ディスク、PROM(EPROM、EEPROM、フラッシュEPROM)、DRAM、SRAM、SDRAM、または任意の他の磁気媒体、コンパクトディスク(たとえば、CD-ROM)、任意の他の光媒体、パンチカード、紙テープ、または穴のパターンを有する他の物理媒体、搬送波(以下で説明する)、あるいはコンピュータがそれから読み取ることのできる任意の他の媒体である。

コンピューティングシステム1000を制御し、本明細書において論じられた機能を実行するようにデバイスを駆動し、コンピューティングシステム1000が人間のユーザと対話することを可能にするためのソフトウェアが、プロセッサ可読媒体のうちの1つまたはそれらの組合せの上に記憶される。そのようなソフトウェアは、限定はしないが、デバイスドライバ、オペレーティングシステム、開発ツール、およびアプリケーションソフトウェアを含み得る。そのようなプロセッサ可読媒体は、本明細書において説明された、実行される処理のすべてまたは一部(処理が分散される場合)を実行するためのコンピュータプログラム製品をさらに含む。

本明細書において論じられたコンピュータコードデバイスは、限定はしないが、スクリプト、インタプリタ型プログラム、ダイナミックリンクライブラリ(DLL)、Javaクラス、および完全な実行可能プログラムを含む、任意の解釈可能または実行可能なコード機構であり得る。さらに、本発明の処理の各部分は、より良好な性能、信頼性、および／またはコストのために分散され得る。

プロセッサ1018に命令を提供するプロセッサ可読媒体は、限定はしないが、不揮発性媒体、揮発性媒体、および伝送媒体を含む多くの形態を取り得る。不揮発性媒体には、たとえば、ハードディスク1022や取り外し可能メディアドライブ1024などの、光ディスク、磁気ディスク、および光磁気ディスクが含まれる。揮発性媒体には、メインメモリ1004などのダイナミックメモリが含まれる。伝送媒体には、バス1010を構成する配線を含む、同軸ケーブル、銅線、および光ファイバが含まれる。伝送媒体はまた、様々な通信プロトコルを使用する電波および赤外線データ通信中に生成されるような音響波または光波の形態も取り得る。

様々な形態のプロセッサ可読媒体が、実行のためのプロセッサ1018に対する1つまたは複数の命令の1つまたは複数のシーケンスを実行することに関係し得る。たとえば、命令は当初、リモートコンピュータの磁気ディスク上に担持され得る。リモートコンピュータは、本発明のすべてまたは一部を実現するための命令をリモートにダイナミックメモリ内にロードし、モデムを使用して有線または無線接続を介して命令を送り得る。コンピューティングシステム1000のローカルのモデムは、有線イーサネットを介して、またはWi-Fiを介して無線でデータを受信し、バス1010上にデータを配置し得る。バス1010は、メインメモリ1004にデータを搬送し、プロセッサ1018は、メインメモリ1004から命令を取り出し、実行する。任意選択で、メインメモリ1004によって受け取られた命令は、プロセッサ1018の実行前または実行後に記憶デバイス1022または1024上に記憶され得る。

コンピューティングシステム1000はまた、バス1010に結合された通信インターフェース1020をも含む。通信インターフェース1020は、たとえばローカルエリアネットワーク(LAN)1500、またはインターネットなどの別の通信ネットワーク2000に接続されるネットワークリンクへの2方向データ通信結合を実現する。たとえば、通信インターフェース1020は、任意のパケット交換LANに接続するためのネットワーク・インターフェース・カードであり得る。別の例として、通信インターフェース1020は、対応するタイプの通信回線へのデータ通信接続を実現するための非対称デジタル加入者線(ADSL)カード、統合サービス・デジタル・ネットワーク(ISDN)カード、またはモデムであり得る。無線リンクも実装され得る。任意のそのような実装では、通信インターフェース1020は、様々なタイプの情報を表すデジタルデータストリームを搬送し得る電気信号、電磁信号、光信号を送り、受信する。

ネットワークリンクは通常、限定はしないが、電子的情報の流れを可能にすることを含めて、他のデータデバイスに1つまたは複数のネットワークを通じてデータ通信を提供する。たとえば、ネットワークリンクは、ローカルネットワーク1500(たとえば、LAN)、または通信ネットワーク2000を通じて通信サービスを提供するサービスプロバイダによって運営される機器を通じて、別のコンピュータに接続を提供し得る。ローカルネットワーク1500および通信ネットワーク2000は、たとえば、デジタルデータストリームを搬送する電気信号、電磁信号、または光信号、および関連する物理層(たとえば、CAT5ケーブル、同軸ケーブル、光ファイバなど)を使用する。コンピューティングシステム1000との間でデジタルデータを搬送する、様々なネットワークを介する信号、およびネットワークリンク上の、通信インターフェース1020を介する信号は、ベースバンド信号、または搬送波を基にした信号として実現され得る。ベースバンド信号は、デジタルデータビットのストリームを記述する非変調電気パルスとしてデジタルデータを搬送し、「ビット」はシンボルを意味するように広く解釈されるべきであり、各シンボルは少なくとも1つまたは複数の情報ビットを搬送する。デジタルデータはまた、伝導媒体を介して伝播され、伝播媒体を通じて電磁波として送信される振幅、位相、および／または周波数偏移変調信号などで搬送波を変調するために使用され得る。したがって、デジタルデータは、「有線」通信チャネルを通じて非変調ベースバンドデータとして送られ、かつ／または搬送波を変調することによって、ベースバンドとは異なる所定の周波数帯内で送られ得る。コンピューティングシステム1000は、ネットワーク1500および2000、ネットワークリンク、ならびに通信インターフェース1020を通じて、プログラムコードを含むデータを送信および受信し得る。さらに、ネットワークリンクは、LAN1500を通じて、携帯情報端末(PDA)ラップトップコンピュータ、セルラー電話などのモバイルデバイス1300に接続を提供し得る。

コンピューティングシステムの代替構成は、本明細書において説明されたシステムおよびプロセスを実装するために使用され得る。

本明細書において説明されたデータベース内に実装される電子データストアは、テーブル、アレイ、データベース、構造化データファイル、XMLファイル、またはハードディスク1022や取り外し可能媒体1024などの何らかの他の機能データストアのうちの1つまたは複数であり得る。

図面を参照しながら実施形態が説明されたが、添付の特許請求の範囲によって定義される本発明の思想、範囲、および目的から逸脱することなく変形および修正が行われる得ることを当業者は理解されよう。

たとえば、一実施形態では、単一のエンティティがすべてのピアインスタンスを記憶し得、それによってブロックチェーンのすべてのコピーを集中して記憶する。ピアインスタンスは、それぞれのブロックチェーンへのアクセスを制御し得るが、相異なるマシンとして物理的に分散されるのではなく、物理的または論理的に集中して記憶され得る。

別の実施形態では、ピアのうちのいくつかは集中して記憶され、いくつかは物理的に異なるマシンである。

別の実施形態では、すべてのピアは物理的に異なるマシンである。一実施形態では、トランザクションが、アクセス制御に基づいて、アプリケーション以外のインターフェースを使用してピアにルーティングされ得る。

一実施形態では、組織は、それ自体の暗号ブロックチェーン識別を管理し、それらを使用して、同意を作成または更新することなどのトランザクションをウェブアプリケーションに送る前に、トランザクションに署名する。このアーキテクチャは、データが許可されたパーティによってシステムに提供される確実性を向上させ得る。

一実施形態では、組織内のあるユーザが、組織内の役割および責任に従ってブロックチェーン上に記憶されたデータに対する修正または制限されたアクセスを有することができるように、ウェブアプリケーションは様々なレベルのアクセス制御を提供する。

5A、5B、5C、5D ユーザ
10 ブロックチェーンを基にした同意管理システム
20 ウェブサーバサブシステム
22 ウェブアプリケーション
24 負荷平衡サブシステム
26 Amazon Route 53 DNSサービス
28 ELB(Elastic Load Balancer)
30 Node JSウェブサーバ
32 APIインターフェース
34 Authミドルウェア
36 要求パブリッシャ
38 データベースインターフェース
40 ブロックチェーン・サブシステム・インターフェース、Node JSウェブサーバ、
42 要求コンシューマー
44 ファブリックインターフェース
46 データベースインターフェース
50 NoSQL DB
52 キャッシングサポート
54 サポートクラウドストレージサービス
60 ブロックチェーンサブシステム
62 チャネル
64A、64B、64C 組織
80 オーダラー
1000 コンピューティングシステム
1002 ディスプレイコントローラ
1004 メインメモリ
1006 読み取り専用メモリ(ROM)
1008 ディスクコントローラ
1010 バス
1012 ディスプレイ
1014 キーボード
1016 ポインティングデバイス
1018 プロセッサ
1020 通信インターフェース
1022 磁気ハードディスク
1024 取り外し可能メディアドライブ
1300 モバイルデバイス
1500 ローカルエリアネットワーク(LAN)
2000 通信ネットワーク

Claims (7)

1. ブロックチェーンについての同意データへのアクセスおよび／または前記同意データに対応するトランザクションを求める、許可されたウェブユーザ要求を受信および処理するように構成されたウェブサーバサブシステムであって、ブロックチェーン・サブシステム・インターフェースを備える、ウェブサーバサブシステムと、
   少なくとも2つの組織を有するチャネル、対応するチェーンコード、および承認ポリシーを定義するブロックチェーンサブシステムであって、前記少なくとも2つの組織のそれぞれが少なくとも1つのピアを有し、前記少なくとも1つのピアのそれぞれがブロックチェーンコピーを維持し、前記ブロックチェーンサブシステムが前記ブロックチェーン・サブシステム・インターフェースと通信するオーダラーを備える、ブロックチェーンサブシステムと、
   を備える、ブロックチェーンを基にした同意管理システム。
2. 前記ブロックチェーンサブシステムと前記ウェブサーバサブシステムが通信し、それによって、前記ブロックチェーンについてのトランザクションを求める許可された要求が、前記ウェブサーバサブシステムに、個々の承認のために前記ブロックチェーン・サブシステム・インターフェースを介して前記ブロックチェーンサブシステムのチャネルピアにルーティングされるべきトランザクション提案を生成させ、前記ピアからの承認応答を受信させ、前記承認応答が集合的に前記承認ポリシーを満たす場合、前記ブロックチェーンの追加のブロック内に含めるために、承認されたトランザクションを前記オーダラーに送信させ、
   前記オーダラーが、前記ピアのブロックチェーンコピーのそれぞれの中に前記追加のブロックを記憶させるように構成される、請求項1に記載のブロックチェーンを基にした同意管理システム。
3. 前記ウェブサーバサブシステムが認証局と通信している、請求項1に記載のブロックチェーンを基にした同意管理システム。
4. 前記ウェブサーバサブシステムが、要求キューを介して第2の自動スケーリンググループと通信する第1の自動スケーリンググループを備え、前記第1の自動スケーリンググループが、前記第2の自動スケーリンググループによる消費のために、ユーザ要求に対応する要求を前記要求キュー内に保管する、請求項1に記載のブロックチェーンを基にした同意管理システム。
5. 前記第1の自動スケーリンググループが、ユーザインターフェースおよびアプリケーションミドルウェア構成要素を有する1つまたは複数のNode JSウェブサーバを備える、請求項3に記載のブロックチェーンを基にした同意管理システム。
6. 前記第2の自動スケーリンググループが、ハイパーレッジャー・ファブリック・インターフェースのインスタンスを有する1つまたは複数のNode JSウェブサーバを備える、請求項3に記載のブロックチェーンを基にした同意管理システム。
7. 前記ウェブサーバサブシステムが、前記第1の自動スケーリンググループ内のウェブサーバインスタンスに前記ユーザ要求をルーティングする負荷平衡構成要素をさらに備える、請求項3に記載のブロックチェーンを基にした同意管理システム。

Images