知財求人 - 知財ポータルサイト「IP Force」
▶ レミュー，ビクトリアの特許一覧 ▶ ボスコボイニコフ，アルテミージの特許一覧 ▶ カウル，ラヴニートの特許一覧 ▶ フレイザー，ロバートの特許一覧 ▶ コスタンゾ，イアンの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-08-22
(54)【発明の名称】デジタル台帳ベースのヘルスデータ共有および管理
(51)【国際特許分類】
H04L 9/32 20060101AFI20230815BHJP
G06F 21/62 20130101ALI20230815BHJP
【ＦＩ】
H04L9/32 200Z
G06F21/62 345
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023504488
(86)(22)【出願日】2021-07-20
(85)【翻訳文提出日】2023-03-15
(86)【国際出願番号】 CA2021051017
(87)【国際公開番号】W WO2022016280
(87)【国際公開日】2022-01-27
(31)【優先権主張番号】63/053,880
(32)【優先日】2020-07-20
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/162,719
(32)【優先日】2021-03-18
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
２．アンドロイド
３．Ｌｉｎｕｘ
４．ＱＲコード
５．ＪＡＶＡ ＳＣＲＩＰＴ
(71)【出願人】
【識別番号】523023292
【氏名又は名称】レミュー，ビクトリア
【氏名又は名称原語表記】ＬＥＭＩＥＵＸ， Ｖｉｃｔｏｒｉａ
【住所又は居所原語表記】ｃ／ｏ Ｍｏｌｅｃｕｌａｒ Ｃｏｒｐｏｒａｔｉｏｎ ３０７ － ７８８ Ｂｅａｔｔｙ Ｓｔｒｅｅｔ Ｖａｎｃｏｕｖｅｒ， Ｂｒｉｔｉｓｈ Ｃｏｌｕｍｂｉａ Ｖ６Ｂ ２Ｍ１ （ＣＡ）
(71)【出願人】
【識別番号】523023306
【氏名又は名称】ボスコボイニコフ，アルテミージ
【氏名又は名称原語表記】ＶＯＳＫＯＢＯＪＮＩＫＯＶ， Ａｒｔｅｍｉｊ
【住所又は居所原語表記】ｃ／ｏ Ｍｏｌｅｃｕｌａｒ Ｃｏｒｐｏｒａｔｉｏｎ ３０７ － ７８８ Ｂｅａｔｔｙ Ｓｔｒｅｅｔ Ｖａｎｃｏｕｖｅｒ， Ｂｒｉｔｉｓｈ Ｃｏｌｕｍｂｉａ Ｖ６Ｂ ２Ｍ１ （ＣＡ）
(71)【出願人】
【識別番号】523023317
【氏名又は名称】カウル，ラヴニート
【氏名又は名称原語表記】ＫＡＵＲ， Ｒａｖｎｅｅｔ
【住所又は居所原語表記】ｃ／ｏ Ｍｏｌｅｃｕｌａｒ Ｃｏｒｐｏｒａｔｉｏｎ ３０７ － ７８８ Ｂｅａｔｔｙ Ｓｔｒｅｅｔ Ｖａｎｃｏｕｖｅｒ， Ｂｒｉｔｉｓｈ Ｃｏｌｕｍｂｉａ Ｖ６Ｂ ２Ｍ１ （ＣＡ）
(71)【出願人】
【識別番号】523023328
【氏名又は名称】フレイザー，ロバート
【氏名又は名称原語表記】ＦＲＡＳＥＲ， Ｒｏｂｅｒｔ
【住所又は居所原語表記】ｃ／ｏ Ｍｏｌｅｃｕｌａｒ Ｃｏｒｐｏｒａｔｉｏｎ ３０７ － ７８８ Ｂｅａｔｔｙ Ｓｔｒｅｅｔ Ｖａｎｃｏｕｖｅｒ， Ｂｒｉｔｉｓｈ Ｃｏｌｕｍｂｉａ Ｖ６Ｂ ２Ｍ１ （ＣＡ）
(71)【出願人】
【識別番号】523023339
【氏名又は名称】コスタンゾ，イアン
【氏名又は名称原語表記】ＣＯＳＴＡＮＺＯ， Ｉａｎ
【住所又は居所原語表記】ｃ／ｏ Ｍｏｌｅｃｕｌａｒ Ｃｏｒｐｏｒａｔｉｏｎ ３０７ － ７８８ Ｂｅａｔｔｙ Ｓｔｒｅｅｔ Ｖａｎｃｏｕｖｅｒ， Ｂｒｉｔｉｓｈ Ｃｏｌｕｍｂｉａ Ｖ６Ｂ ２Ｍ１ （ＣＡ）
(74)【代理人】
【識別番号】110003487
【氏名又は名称】弁理士法人東海特許事務所
(72)【発明者】
【氏名】レミュー，ビクトリア
(72)【発明者】
【氏名】ボスコボイニコフ，アルテミージ
(72)【発明者】
【氏名】カウル，ラヴニート
(72)【発明者】
【氏名】フレイザー，ロバート
(72)【発明者】
【氏名】コスタンゾ，イアン
(57)【要約】
規制の強化は、ヘルスデータの共有に関する個人の懸念の高まりを反映している。しかし、対処されないままにしておくと、これらの規制は、ヘルスケア研究者およびヘルスケアプロバイダが、ＡＩを活用したヘルスの向上に必要な現実世界のヘルスデータにアクセスする際の障壁として作用する。したがって、本発明者らは、個人向け分散型台帳ベースの自己主権型データ管理プラットフォームを確立した。プラットフォームを介して、自分自身のヘルスデータの制御および管理を与える自己主権型データ管理をサポートするための個人向けヘルスウォレットが個人に提供される。プラットフォームは以下を提供する。
・例えば、共有する個人の同意および／または倫理的承認を有する第三者研究プロジェクトに関する、検証可能な請求の品質およびサポートを保証するためのデータクレデンシャル
・個人のプライバシーを保護し、安全なデータ共有を促進するゼロ知識証明
・個人の同意およびデータ共有に関するプライバシー保護監査、説明責任およびコンプライアンスの支援
・例えば、共有する個人の同意および／または倫理的承認を有する第三者研究プロジェクトに関する、検証可能な請求の品質およびサポートを保証するためのデータクレデンシャル
・個人のプライバシーを保護し、安全なデータ共有を促進するゼロ知識証明
・個人の同意およびデータ共有に関するプライバシー保護監査、説明責任およびコンプライアンスの支援
【特許請求の範囲】
【請求項1】
個人データの項目を転送する方法であって、１つまたは複数のブロックチェーン内に記憶された発行者およびシーカの公開分散型識別子に応じて、前記個人データの項目のプロバイダおよび前記個人データの項目の前記シーカのアイデンティティを確立および検証することと、
前記１つまたは複数のブロックチェーンから独立して前記プロバイダから前記シーカへ前記個人データの項目を転送することとを含む、方法。
【請求項2】
個人データの項目を転送する方法であって、１つまたは複数のブロックチェーン内に記憶された発行者およびシーカの公開分散型識別子に応じて、前記個人データの項目のプロバイダおよび前記個人データの項目の前記シーカのアイデンティティを確立および検証することと、
前記１つまたは複数のブロックチェーンから独立して前記プロバイダから前記シーカへ前記個人データの項目を転送することとを含み、
前記個人データの項目の転送が、前記プロバイダのアイデンティティが前記シーカまたは第三者のいずれにも明らかにされることなく実行される、方法。
【請求項3】
個人データの項目を転送する方法であって、前記個人データの項目の所有者の第１の分散型識別子（ＤＩＤ）を確立することと、
前記個人データの項目を取得しようとしている当事者の第２のＤＩＤを確立することと、
前記第１のＤＩＤおよび前記第２のＤＩＤを検証することに応じて安全な接続を確立することと、
前記個人データの前記所有者に関連付けられた第１のウォレットから、前記個人データの項目を前記当事者に関連付けられた第２のウォレットへ転送することとを含む、方法。
【請求項4】
前記第１のＤＩＤがブロックチェーン内に記憶されず、前記第２のＤＩＤが前記ブロックチェーン内に記憶される、
前記第１のウォレットから前記第２のウォレットへの転送が、前記個人データの項目が前記ブロックチェーン内に記憶されることなく実行される、請求項３に記載の方法。
【請求項5】
前記第１のＤＩＤおよび前記第２のＤＩＤが一意である、請求項３に記載の方法。
【請求項6】
前記第１のＤＩＤおよび前記第２のＤＩＤが、前記個人データの各転送について一意に確立される、請求項３に記載の方法。
【請求項7】
前記個人データの項目が、プロバイダに関する前記個人データの所定の部分であり、前記個人データの項目が関連する前記個人データの前記所定の部分が、前記プロバイダによって確立される、請求項３に記載の方法。
【請求項8】
前記個人データの項目の粒度が、前記プロバイダによって確立される、請求項３に記載の方法。
【請求項9】
前記個人データの項目の前記転送が、前記プロバイダのアイデンティティが前記シーカまたは第三者のいずれにも明らかにされることなく実行され、前記第１のＤＩＤが、前記プロバイダを識別するデータを含まない、請求項３に記載の方法。
【請求項10】
個人データを転送する方法であって、前記個人データの所有者と前記個人データの取得者との間の個人データの転送をすることを含み、
前記転送が、ブロックチェーン上に記憶された非個人データを記憶および処理することによって確立され、
前記個人データの実際の転送が、前記ブロックチェーンから独立して実行される、方法。
【請求項11】
発行者が同意受信アイデンティティを生成し、所有者に同意有効化クレデンシャルを発行することと、前記所有者が前記同意有効化クレデンシャルを受け入れるか否かを確立することと、
前記所有者が前記同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、前記所有者から前記発行者へ最初の承認を送信することと、
前記最初の承認の受信に応じて前記発行者から前記所有者へ同意証明要求を送信することと、
前記所有者が前記同意証明要求を受け入れるか否かを確立することと、
前記所有者が前記同意証明要求を受け入れると肯定的な判定をした場合、前記所有者から前記発行者へ同意証明提示を送信することと、
前記発行者が前記所有者から受け取った同意証明提示を受け入れるか否かを確立することと、
前記発行者が前記同意証明提示を受け入れると肯定的な判定をした場合、証明データを前記発行者から証明レジストリへ送信することとを含む、方法。
【請求項12】
前記証明レジストリへ送信される前記データが、前記同意証明要求と、前記同意証明検証と、前記同意受信アイデンティティとを含む、請求項１１に記載の方法。
【請求項13】
前記所有者が前記同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、前記同意有効化クレデンシャルを前記証明レジストリへ送信することと、前記所有者が前記同意有効化クレデンシャルを受け入れると否定的な判定をした場合、前記否定的な判定を前記証明レジストリへ送信することと、
前記同意有効化クレデンシャルまたは前記否定的な判定のいずれかを前記証明レジストリ内に記憶することとをさらに含む、請求項１１に記載の方法。
【請求項14】
前記所有者が前記同意証明要求を受け入れると肯定的な判定をした場合、前記同意証明提示クレデンシャルを前記証明レジストリへ送信することと、前記所有者が前記同意証明要求を受け入れると否定的な判定をした場合、前記否定的な判定を前記証明レジストリへ送信することと、
前記同意証明要求または前記否定的な判定のいずれかを前記証明レジストリ内に記憶することとをさらに含む、請求項１１に記載の方法。
【請求項15】
バイオマーカーの所有者から分散型台帳ソフトウェアアプリケーションへ前記バイオマーカーの要求を確立することと、前記バイオマーカーの要求の受信に応じて、前記分散型台帳ソフトウェアアプリケーションを用いて、共有ＳＩ、共有ＳＲ、および共有ＳＨを生成することと、
前記分散型台帳ソフトウェアアプリケーションを用いて、要求された前記バイオマーカーに関するクレデンシャルを生成することと、
前記所有者へバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを送信することと、
前記所有者が前記バイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れるか否かを判定すること、
前記所有者が前記バイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れると肯定的な判定をした場合、前記所有者の前記バイオマーカーへのアクセスを求める研究者へ前記バイオマーカーアイデンティティおよび共有ＳＲを送信することと、
前記バイオマーカーアイデンティティおよび共有ＳＲの受信を受けて、同意受信アイデンティティを生成することと、
前記研究者から前記所有者へ同意有効化クレデンシャルの発行および送信をすることと、
前記所有者が前記同意有効化クレデンシャルを受け入れるか否か判定することと、
前記所有者が前記同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、前記研究者へ最初の承認を送信することと、
前記研究者が最初の承認を受信したことを受けて、共有ＳＲを含む同意証明要求を生成し、証明レジストリおよび前記所有者へ前記同意証明要求を送信することと、
前記同意証明要求を前記証明レジストリ内に記憶することと、
前記所有者が前記同意証明要求を受け入れるか否かを判定することと、
前記所有者が前記同意証明要求を受け入れると肯定的な判定をした場合、同意証明提示を生成し、前記研究者へ前記同意証明提示を送信することとを含む、方法。
【請求項16】
研究による前記同意証明提示を検証することと、前記研究者が肯定的な検証をした場合、証明データを前記証明レジストリへ送信することと、
前記証明データを前記証明レジストリ内に記憶することとをさらに含む、請求項１５に記載の方法。
【請求項17】
前記証明データが、前記同意証明提示と、前記研究者による前記同意証明レジストリの検証に関する検証データとを含み、前記同意証明提示が、前記所有者の明らかにされた属性が存在しない、請求項１６に記載の方法。
【請求項18】
監査者からの同意データの要求を証明レジストリによって受信すること、前記証明レジストリ上で、要求を受け入れるか否かを判定することと、
肯定的な判定をした場合、前記証明レジストリと関連付けられたデータベースから前記同意データを取得することと、
前記証明レジストリから前記監査者へバイオマーカーアイデンティティおよび共有ＳＲを送信することと、
秘密を前記監査者によって再生することと、
分散型台帳ソフトウェアアプリケーションへ、前記秘密である、バイオマーカーアイデンティティおよび共有を送信することと、
前記バイオマーカーアイデンティティに応じて前記分散型台帳ソフトウェアアプリケーションを用いて共有をマッピングし、前記分散型台帳ソフトウェアアプリケーションに関連付けられた別のデータベースから別の共有ＳＩを取得することと、
前記共有ＳＲおよび別の共有ＳＩに応じて前記分散型台帳ソフトウェアアプリケーションを用いてハッシュを再構築することと、
前記分散型台帳ソフトウェアアプリケーションに関連付けられたさらに別のデータベースから前記ハッシュに応じたルックアップを介してアイデンティティを取得することと、
取得された前記アイデンティティを前記監査者へ送信することとを含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本出願は、２０２０年７月２０日に出願された米国仮特許出願第６３／０５３，８８０号の優先権の利益を主張し、２０２１年３月１８日に出願された米国仮特許出願第６３／１６２，７１９号の優先権の利益を主張する。
本出願は、２０２０年７月２０日に出願された米国仮特許出願第６３／０５３，８８０号の優先権の利益を主張し、２０２１年３月１８日に出願された米国仮特許出願第６３／１６２，７１９号の優先権の利益を主張する。
【0002】
本特許出願は、個人データに関し、より詳細には、個人データの所有者によって確立された粒度で個人データを転送し、個人データの自己主権型アイデンティティを確立し、個人データの所有者のアイデンティティを公開せずに個人データを転送し、分散型台帳を利用して、転送が分散型台帳から独立して実行される個人データの転送を確立するための方法およびシステムに関する。
【背景技術】
【0003】
過去数十年にわたって、インターネット、低コスト高性能ポータブル電子デバイス、および高速電気通信の進化は、例えば、我々の個人データの記憶および使用が急速に進化し、ＩＤ盗難、個人データの盗難、および個人データの販売などの新たな問題をもたらしていることを意味している。したがって、個人データのセキュリティおよび管理を向上させる必要がある。
【0004】
例えば、個人向け人工知能（ＡＩ）主導のヘルスは、個人が自分のヘルスを制御することを可能にし、ポジティブヘルスおよび社会的利益を推進する可能性を有する。しかしながら、クライアントデータのプライバシーおよびセキュリティが大きな懸念事項であるため、多くの課題に直面しており、データ侵害に関するほぼ毎日のニュースと、データを集約し、個人の知識または同意なしに二次的な目的で使用する大規模な集中型プラットフォームに対する消費者の疑念の高まりがある。その結果、一般データ保護規則（ＧＤＰＲ）などの規制が登場しつつある。規制の強化は、自分のヘルスデータを共有することに対する個人の懸念の高まりを反映しており、この規制は、対処されないままにしておくと、ヘルスケア研究者およびヘルスケアプロバイダが、ＡＩを活用したヘルスの向上に必要な現実世界のヘルスデータにアクセスする際の障壁として作用し得る。
【0005】
したがって、以下を可能にする分散型台帳ベースの自己主権型データ管理プラットフォームを個人に提供することが有益であろう。
・顧客に自身のヘルスデータの制御および管理を与える自己主権型をサポートする個人向けヘルスウォレット
・検証可能な請求、例えば共有する個人の同意および第三者の倫理的承認に関する請求の質およびサポートを保証するためのデータクレデンシャル
・個人のプライバシーを保護し、安全なデータ共有を促進するためのゼロ知識証明
・個人の同意および個人データ共有に関するプライバシー保護監査、説明責任およびコンプライアンスのサポート
・顧客に自身のヘルスデータの制御および管理を与える自己主権型をサポートする個人向けヘルスウォレット
・検証可能な請求、例えば共有する個人の同意および第三者の倫理的承認に関する請求の質およびサポートを保証するためのデータクレデンシャル
・個人のプライバシーを保護し、安全なデータ共有を促進するためのゼロ知識証明
・個人の同意および個人データ共有に関するプライバシー保護監査、説明責任およびコンプライアンスのサポート
【0006】
分散型台帳ベースの自己主権型データ管理プラットフォームが、報酬システムをサポートして個人データ共有および行動変化にインセンティブを与えウェルネスを促進し、相互に有益なビジネスパートナーシップのためのビジネスエコシステムをサポートすることはさらに有益であろう。
【0007】
本発明の他の態様および特徴は、本発明の特定の実施形態の以下の説明を添付の図面と併せて検討することによって当業者には明らかになるであろう。
【発明の概要】
【0008】
本発明の目的は、個人データに関する従来技術内の制限を緩和することであり、より詳細には、個人データの所有者によって確立された粒度で個人データを転送し、個人データの自己主権型アイデンティティを確立し、個人データの所有者のアイデンティティを公開せずに個人データを転送し、分散型台帳を利用して、転送が分散型台帳から独立して実行される個人データの転送を確立するための方法およびシステムである。
【0009】
本発明の一実施形態によれば、個人データの項目を転送する方法であって、
１つまたは複数のブロックチェーン内に記憶されたプロバイダおよびシーカ(seeker)の分散型識別子に応じて、個人データの項目のプロバイダおよび個人データの項目のシーカのアイデンティティを確立および検証することと、
１つまたは複数のブロックチェーンから独立してプロバイダからシーカへ個人データの項目を転送することとを含む、方法が提供される。
１つまたは複数のブロックチェーン内に記憶されたプロバイダおよびシーカ(seeker)の分散型識別子に応じて、個人データの項目のプロバイダおよび個人データの項目のシーカのアイデンティティを確立および検証することと、
１つまたは複数のブロックチェーンから独立してプロバイダからシーカへ個人データの項目を転送することとを含む、方法が提供される。
【0010】
本発明の一実施形態によれば、個人データの項目を転送する方法であって、
１つまたは複数のブロックチェーン内に記憶された発行者およびシーカの公開分散型識別子に応じて、個人データの項目のプロバイダおよび個人データの項目のシーカのプライバシー保護分散型アイデンティティを確立および検証することと、
１つまたは複数のブロックチェーンから独立してプロバイダからシーカへ個人データの項目を転送することとを含み、
個人データの項目の転送が、プロバイダのアイデンティティがシーカまたは第三者のいずれにも明らかにされることなく実行される、方法が提供される。
１つまたは複数のブロックチェーン内に記憶された発行者およびシーカの公開分散型識別子に応じて、個人データの項目のプロバイダおよび個人データの項目のシーカのプライバシー保護分散型アイデンティティを確立および検証することと、
１つまたは複数のブロックチェーンから独立してプロバイダからシーカへ個人データの項目を転送することとを含み、
個人データの項目の転送が、プロバイダのアイデンティティがシーカまたは第三者のいずれにも明らかにされることなく実行される、方法が提供される。
【0011】
本発明の一実施形態によれば、個人データの項目を転送する方法であって、
個人データのその実施形態の所有者になる当事者にクレデンシャルを発行することと、
個人データの項目の所有者の第１の分散型識別子（ＤＩＤ）を確立することと、
個人データの項目を取得しようとしている当事者の第２のＤＩＤを確立することと、
第２のＤＩＤによって第１のＤＩＤによって保有されているクレデンシャルを検証することに応じて、真偽主張の証明を確立することと、
個人データの所有者に関連付けられた第１のウォレットから、個人データの項目を別の当事者に関連付けられた第２のウォレットへ転送することとを含む、方法が提供される。
個人データのその実施形態の所有者になる当事者にクレデンシャルを発行することと、
個人データの項目の所有者の第１の分散型識別子（ＤＩＤ）を確立することと、
個人データの項目を取得しようとしている当事者の第２のＤＩＤを確立することと、
第２のＤＩＤによって第１のＤＩＤによって保有されているクレデンシャルを検証することに応じて、真偽主張の証明を確立することと、
個人データの所有者に関連付けられた第１のウォレットから、個人データの項目を別の当事者に関連付けられた第２のウォレットへ転送することとを含む、方法が提供される。
【0012】
本発明の一実施形態によれば、
個人データの所有者と個人データの取得者との間の個人データの転送することを含み、
転送が、ブロックチェーン上に記憶された非個人データを記憶および処理することによって確立され、
個人データの実際の転送が、ブロックチェーンから独立して実行される、方法が提供される。
個人データの所有者と個人データの取得者との間の個人データの転送することを含み、
転送が、ブロックチェーン上に記憶された非個人データを記憶および処理することによって確立され、
個人データの実際の転送が、ブロックチェーンから独立して実行される、方法が提供される。
【0013】
本発明の一実施形態によれば、
発行者が同意受信アイデンティティを生成し、所有者に同意有効化クレデンシャルを発行することと、
所有者が同意有効化クレデンシャルを受け入れるか否かを確立することと、
所有者が同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、所有者から発行者へ最初の承認を送信することと、
最初の承認の受信に応じて発行者から所有者へ同意証明要求を送信することと、
所有者が同意証明要求を受け入れるか否かを確立することと、
所有者が同意証明要求を受け入れると肯定的な判定をした場合、所有者から発行者へ同意証明提示を送信することと、
発行者が所有者から受信した同意証明提示を受け入れるか否かを確立することと、
発行者が同意証明提示を受け入れると肯定的な判定をした場合、証明データを発行者から証明レジストリへ送信することとを含む、方法が提供される。
発行者が同意受信アイデンティティを生成し、所有者に同意有効化クレデンシャルを発行することと、
所有者が同意有効化クレデンシャルを受け入れるか否かを確立することと、
所有者が同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、所有者から発行者へ最初の承認を送信することと、
最初の承認の受信に応じて発行者から所有者へ同意証明要求を送信することと、
所有者が同意証明要求を受け入れるか否かを確立することと、
所有者が同意証明要求を受け入れると肯定的な判定をした場合、所有者から発行者へ同意証明提示を送信することと、
発行者が所有者から受信した同意証明提示を受け入れるか否かを確立することと、
発行者が同意証明提示を受け入れると肯定的な判定をした場合、証明データを発行者から証明レジストリへ送信することとを含む、方法が提供される。
【0014】
本発明の一実施形態によれば、
バイオマーカーの所有者から分散型台帳ソフトウェアアプリケーションへバイオマーカーの要求を確立することと、
バイオマーカーの要求の受信に応じて、分散型台帳ソフトウェアアプリケーションを用いて、共有ＳＩ、共有ＳＲ、および共有ＳＨを生成することと、
分散型台帳ソフトウェアアプリケーションを用いて、要求されたバイオマーカーに関するクレデンシャルを生成することと、
所有者へバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを送信することと、
所有者がバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れるか否かを判定することと、
所有者がバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れると肯定的な判定をした場合、所有者のバイオマーカーへのアクセスを求める研究者へバイオマーカーアイデンティティおよび共有ＳＲを送信することと、
バイオマーカーアイデンティティおよび共有ＳＲの受信を受けて、同意受信アイデンティティを生成することと、
研究者から所有者へ同意有効化クレデンシャルの発行および送信をすることと、
所有者が同意有効化クレデンシャルを受け入れるか否かを判定することと、
所有者が同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、研究者へ最初の承認を送信することと、
研究者が最初の承認を受信したことを受けて、共有ＳＲを含む同意証明要求を生成し、証明レジストリおよび所有者へ同意証明要求を送信することと、
同意証明要求を証明レジストリ内に記憶することと、
所有者が同意証明要求を受け入れるか否かを判定することと、
所有者が同意証明要求を受け入れると肯定的な判定をした場合、同意証明提示を生成し、研究者へ同意証明提示を送信することとを含む、方法が提供される。
バイオマーカーの所有者から分散型台帳ソフトウェアアプリケーションへバイオマーカーの要求を確立することと、
バイオマーカーの要求の受信に応じて、分散型台帳ソフトウェアアプリケーションを用いて、共有ＳＩ、共有ＳＲ、および共有ＳＨを生成することと、
分散型台帳ソフトウェアアプリケーションを用いて、要求されたバイオマーカーに関するクレデンシャルを生成することと、
所有者へバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを送信することと、
所有者がバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れるか否かを判定することと、
所有者がバイオマーカーアイデンティティならびに共有ＳＲおよび共有ＳＨを受け入れると肯定的な判定をした場合、所有者のバイオマーカーへのアクセスを求める研究者へバイオマーカーアイデンティティおよび共有ＳＲを送信することと、
バイオマーカーアイデンティティおよび共有ＳＲの受信を受けて、同意受信アイデンティティを生成することと、
研究者から所有者へ同意有効化クレデンシャルの発行および送信をすることと、
所有者が同意有効化クレデンシャルを受け入れるか否かを判定することと、
所有者が同意有効化クレデンシャルを受け入れると肯定的な判定をした場合、研究者へ最初の承認を送信することと、
研究者が最初の承認を受信したことを受けて、共有ＳＲを含む同意証明要求を生成し、証明レジストリおよび所有者へ同意証明要求を送信することと、
同意証明要求を証明レジストリ内に記憶することと、
所有者が同意証明要求を受け入れるか否かを判定することと、
所有者が同意証明要求を受け入れると肯定的な判定をした場合、同意証明提示を生成し、研究者へ同意証明提示を送信することとを含む、方法が提供される。
【0015】
本発明の一実施形態によれば、
監査者からの同意データの要求を証明レジストリによって受信することと、
証明レジストリ上で、要求を受け入れるか否かを判定することと、
肯定的な判定をした場合、証明レジストリと関連付けられたデータベースから同意データを取得することと、
証明レジストリから監査者へバイオマーカーアイデンティティおよび共有ＳＲを送信することと、
秘密を監査者によって再生することと、
分散型台帳ソフトウェアアプリケーションへ、秘密である、バイオマーカーアイデンティティおよび共有を送信することと、
バイオマーカーアイデンティティに応じて分散型台帳ソフトウェアアプリケーションを用いて共有をマッピングし、分散型台帳ソフトウェアアプリケーションに関連付けられた別のデータベースから別の共有ＳＩを取得することと、
共有ＳＲおよび別の共有ＳＩに応じて分散型台帳ソフトウェアアプリケーションを用いてハッシュを再構築することと、
分散型台帳ソフトウェアアプリケーションに関連付けられたさらに別のデータベースからハッシュに応じたルックアップを介してアイデンティティを取得することと、
取得されたアイデンティティを監査者へ送信することとを含む、方法が提供される。
監査者からの同意データの要求を証明レジストリによって受信することと、
証明レジストリ上で、要求を受け入れるか否かを判定することと、
肯定的な判定をした場合、証明レジストリと関連付けられたデータベースから同意データを取得することと、
証明レジストリから監査者へバイオマーカーアイデンティティおよび共有ＳＲを送信することと、
秘密を監査者によって再生することと、
分散型台帳ソフトウェアアプリケーションへ、秘密である、バイオマーカーアイデンティティおよび共有を送信することと、
バイオマーカーアイデンティティに応じて分散型台帳ソフトウェアアプリケーションを用いて共有をマッピングし、分散型台帳ソフトウェアアプリケーションに関連付けられた別のデータベースから別の共有ＳＩを取得することと、
共有ＳＲおよび別の共有ＳＩに応じて分散型台帳ソフトウェアアプリケーションを用いてハッシュを再構築することと、
分散型台帳ソフトウェアアプリケーションに関連付けられたさらに別のデータベースからハッシュに応じたルックアップを介してアイデンティティを取得することと、
取得されたアイデンティティを監査者へ送信することとを含む、方法が提供される。
【0016】
本発明の他の態様および特徴は、本発明の特定の実施形態の以下の説明を添付の図面と併せて検討することによって当業者には明らかになるであろう。
【図面の簡単な説明】
【0017】
ここでは本発明の実施形態について、添付の図面を参照して、単なる例として説明する。
【0018】
【図1】本発明の実施形態による、および本発明の実施形態をサポートする、構成可能な電気デバイスを展開され、動作されてもよい例示的なネットワーク環境を示す。
【0019】
【0020】
【図3】プライベートで安全なヘルスデータ管理および共有のための本発明の一実施形態による、ブロックチェーンネットワーク上の取引を利用するアーキテクチャの大まかなアーキテクチャの例示的な概略図を示す。
【0021】
【図4】本発明の実施形態による、分散型台帳個人データ（ＤｅＬｅＰｅＤａ）システム、アプリケーション、およびプラットフォーム（ＤｅＬｅＰｅＤａ－ＳＡＰ）をサポートするブロックチェーンフレームワークのフロントエンドサービスおよびバックエンドサービスの例示的なアーキテクチャを示す。
【0022】
【図5】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰをサポートするブロックチェーンフレームワークの大まかなアーキテクチャを示す。
【0023】
【図6】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰの第１のユースケースの論理プロセスフローおよびアーキテクチャを示す。
【0024】
【図7】本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰの第２のユースケースの論理プロセスフローおよびアーキテクチャを示す。
【0025】
【図8】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰの第２のユースケースの要求およびデータフローの例示的なスキーマを示す。
【0026】
【図9】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰによって使用される例示的なデータアーキテクチャを示す。
【0027】
【図10】本発明の実施形態による、自己主権型の制御の軌跡がＤｅＬｅＰｅＤａ－ＳＡＰによってサポートされる、履歴アイデンティティおよび自己主権型アイデンティティの制御の軌跡を示す。
【0028】
【図11】本発明の実施形態による、当事者およびＤｅＬｅＰｅＤａ－ＳＡＰ内のブロックチェーン間の例示的なプロセスフローを示す。
【0029】
【図12】別の当事者のウォレット内に記憶されている個人データを取得するための最初のユーザ要求の当事者およびブロックチェーン間の例示的なプロセスフローを示す。
【0030】
【図13】本発明の一実施形態による、（監査データリポジトリとしても知られる）監査データレジストリの例示的なビジネスプロセスモデリング表記法（ＢＰＭＮ）図を示す。
【0031】
【図14】本発明の一実施形態による、監査データレジストリの例示的なＢＰＭＮ図を示す。
【0032】
【図15】本発明の一実施形態による、監査データレジストリの証明の再検証を示す。
【0033】
【図16】本発明の一実施形態による監査データレジストリ内に記憶されたクレデンシャルを示す。
【0034】
【図17】本発明の一実施形態による、監査データレジストリ内に記憶された証明を示す。
【0035】
【図18】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰの論理プロセスフローおよびアーキテクチャを示す。
【0036】
【図19】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰの例示的なアーキテクチャを示す。
【0037】
【図20】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰを利用する研究者プロジェクトセットアップおよび研究倫理委員会承認の例示的なプロセスフローを示す。
【0038】
【図21】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のユーザ接続およびクレデンシャル受信の例示的なプロセスフローを示す。
【0039】
【図22】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のプロジェクト適格性証明の例示的なプロセスフローを示す。
【0040】
【図23】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内の研究から同意クレデンシャルを受信するクライアントの例示的なプロセスフローを示す。
【0041】
【図24】本発明の実施形態による、クライアントが証明有りで同意し、ＤｅＬｅＰｅＤａ－ＳＡＰ内で証明有りヘルスデータを共有する、例示的なプロセスフローを示す。
【0042】
【図25】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内での同意受信の例示的なプロセスフローを示す。
【0043】
【0044】
【図27】本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の例示的な対話を示す。
【0045】
【図28】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内でヘルスクレデンシャルを発行する例示的なプロセスフローを示す。
【0046】
【図29】本発明の実施形態による、クライアントがプロジェクトを閲覧し、ＤｅＬｅＰｅＤａ－ＳＡＰ内に登録することを選択する、例示的なプロセスフローを示す。
【0047】
【図30】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内で同意を得てデータを共有するためのクライアントと研究者との対話の例示的なプロセスフローを示す。
【0048】
【図31】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内の例示的なＳＳＩアーキテクチャを示す。
【0049】
【図32】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のプロジェクトセットアップおよび研究倫理委員会承認のメッセージングフローを有する例示的なアーキテクチャを示す。
【0050】
【図33】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のクライアント接続およびクレデンシャル受信のメッセージングフローを有する例示的なアーキテクチャを示す。
【0051】
【図34】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のプロジェクト適格性証明のメッセージングフローを有する例示的なアーキテクチャを示す。
【0052】
【図35】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内の研究者からの同意クレデンシャル受信のメッセージングフローを有する例示的なアーキテクチャを示す。
【0053】
【図36】本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内で同意を提供し、ヘルスデータを共有する（両方とも証明有り）メッセージングフローを有する例示的なアーキテクチャを示す。
【0054】
【図37】本発明の一実施形態による、所有者に関するデータを研究者に提供することに関する、所有者および研究者（要求者）に関するハンドシェイクの例示的なＢＰＭＮ図を示す。
【0055】
【図38】本発明の一実施形態による、監査データレジストリから監査者による同意に関するアイデンティティ情報を取得する例示的なＢＰＭＮ図を示す。
【発明を実施するための形態】
【0056】
本発明は、個人データに関し、より詳細には、個人データの所有者によって確立された粒度で個人データを転送し、個人データの自己主権型アイデンティティを確立し、個人データの所有者のアイデンティティを公開せずに個人データを転送し、分散型台帳を利用して、転送が分散型台帳から独立して実行される個人データの転送を確立するための方法およびシステムに関する。
【0057】
以下の説明は、代表的な１つまたは複数の実施形態のみを提供し、本開示の範囲、適用性、または構成を限定することを意図するものではない。むしろ、以下の実施形態の説明は、当業者に、本発明の１つまたは複数の実施形態を実装するための有効な説明を提供する。添付の特許請求の範囲に記載の精神および範囲から逸脱することなく、要素の機能および配置に様々な変更を加えることができることが理解される。したがって、一実施形態は、本発明の例または実装であり、唯一の実装ではない。「１つの実施形態」、「一実施形態」、または「いくつかの実施形態」の様々な出現は、必ずしもすべてが同じ実施形態を指すわけではない。本発明の様々な特徴を単一の実施形態の文脈で説明してもよいが、特徴は別個にまたは任意の適切な組み合わせで提供してもよい。逆に、本発明は、明確にするために別個の実施形態の文脈で本明細書で説明してもよいが、本発明は、単一の実施形態または実施形態の任意の組み合わせで実装することもできる。
【0058】
本明細書における「１つの実施形態」、「一実施形態」、「いくつかの実施形態」または「他の実施形態」への言及は、実施形態に関連して説明される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれるが、必ずしもすべての実施形態に含まれるわけではないことを意味する。本明細書で使用される表現および用語は、限定として解釈されるべきではなく、説明目的のためのものにすぎない。特許請求の範囲または本明細書が「１つの」要素に言及する場合、そのような言及は、その要素の１つのみが存在すると解釈されるべきではないことを理解されたい。本明細書が、構成要素の特徴、構造、または特性を「含んでもよい」、または「含むことができる」と述べている場合、その特定の構成要素、特徴、構造、または特性を含める必要はないことを理解されたい。
【0059】
「左」、「右」、「上」、「下」、「前」、および「後」などの用語への言及は、本発明の実施形態を示す図内の特定の特徴、構造、または要素の向きに関して使用することを意図している。デバイスの実際の使用に関するそのような方向の用語は、デバイスが１人または複数のユーザによって複数の向きで使用され得るので、特定の意味を有さないことは明らかであろう。
【0060】
「含む」、「備える」、「からなる」という用語およびその文法上の変形は、１つまたは複数の構成要素、特徴、ステップ、整数、またはそれらのグループの追加を除外するものではなく、これらの用語は、構成要素、特徴、ステップ、または整数を特定するものとして解釈されるべきではない。同様に、「から本質的になる」という語句およびその文法上の変形は、本明細書で使用される場合、追加の構成要素、ステップ、特徴、整数またはそのグループを除外するものと解釈されるべきではなく、むしろ追加の特徴、整数、ステップ、構成要素またはそのグループは、特許請求される構成要素、デバイスまたは方法の基本的かつ新規の特性を実質的に変更しない。本明細書または特許請求の範囲が「追加の」要素に言及する場合、それは追加の要素が２つ以上存在することを除外しない。
【0061】
本明細書および本開示全体を通して使用される「記録（またはレコード）」は、法的義務の遂行または企業の取引において、組織または個人によって証拠として、および資産として作成、受け取り、および維持される情報を指すが、これらに限定されない。
【0062】
本明細書および本開示を通して使用される「取引レコード」は、取引を文書化した記録を指すが、これに限定されない。
【0063】
本明細書および本開示全体で使用される「台帳記録（またはレコード）」は、分散型台帳技術（ＤＬＴ）を使用して、１つまたは複数の分散型台帳（例えば、ブロックチェーン）上に記録された、１つまたは複数の取引レコード、１つまたは複数の取引レコードのハッシュ値、および１つまたは複数の取引レコードの１つまたは参照のうちの１つまたは複数を含む、１つまたは複数のレコードを指すが、これらに限定されない。
【0064】
本明細書および本開示を通して使用される「レコードシステム」は、経時的にレコードを捕捉し、管理し、およびアクセスを提供する情報システムを指すが、これに限定されない。
【0065】
本明細書および本開示を通して使用される「クレデンシャル」は、発行者によって作成された請求のセットを指すが、これに限定されない。
【0066】
本明細書および本開示を通して使用される「検証可能なクレデンシャル」は、暗号的に検証することができる権限を有する不正開封防止クレデンシャルを指すが、これに限定されない。
【0067】
本明細書および本開示を通して使用される「発行者」は、１つまたは複数のサブジェクトに関する請求を主張し、これらの請求から検証可能なクレデンシャルを作成し、検証可能なクレデンシャルを所有者へ送信することによってエンティティが実行することができる役割を指すが、これに限定されない。
【0068】
本明細書および本開示を通して使用される「所有者」は、１つまたは複数の検証可能なクレデンシャルを所有し、それらから提示を生成することによってエンティティが実行することができる役割を指すが、これに限定されない。
【0069】
本明細書および本開示を通して使用される「検証者」は、所与のサブジェクトに関する請求を検証するエンティティを指すが、これに限定されない。
【0070】
本明細書および本開示を通して使用される「証明要求」は、１人または複数の発行者によって発行され、１人または複数の所有者によって保有される、１つまたは複数の検証可能なクレデンシャルの要求を指すが、これに限定されない。
【0071】
本明細書および本開示を通して使用される「証明提示」は、１人または複数の発行者によって発行され、特定の１人または複数の検証者と共有される、１つまたは複数の検証可能なクレデンシャルから導出されたデータを指すが、これに限定されない。
【0072】
本明細書および本開示を通して使用される「証明検証」は、検証可能なクレデンシャルまたは検証可能な提示が、それぞれ発行者または提示者の真正で適時のステートメントであるか否かに関する評価を指すが、これに限定されない。
【0073】
本明細書および本開示を通して使用される「無線規格」は、典型的にはＲＦ無線システムおよび技術が主流であるが、光、無線周波数（ＲＦ）、またはマイクロ波であってもよい電磁放射線を介して信号および／またはデータを送信するための規格を指すが、これに限定されない。無線規格は、全世界的に、国内的に、または機器製造業者もしくは機器製造業者のセットに固有に定義してもよい。現在の主流の無線規格には、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、ＵＭＴＳ、ＧＳＭ８５０、ＧＳＭ９００、ＧＳＭ１８００、ＧＳＭ１９００、ＧＰＲＳ、ＩＴＵ－Ｒ５．１３８、ＩＴＵ－Ｒ５．１５０、ＩＴＵ－Ｒ５．２８０、ＩＭＴ－１０００、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、Ｕｌｔｒａ－ＷｉｄｅｂａｎｄおよびＷｉＭＡＸが含まれるが、これらに限定されない。いくつかの規格は、ＩＥＥＥ８０２．１ａ、ＩＥＥＥ８０２．１１ｂ、ＩＥＥＥ８０２．１１ｇ、またはＩＥＥＥ８０２．１１ｎを指す場合があるＩＥＥＥ８０２．１１などのサブ規格、ならびにＩＥＥＥ８０２．１１の傘下にある他のサブ規格の集合であってもよいが、これらに限定されない。
【0074】
本明細書および本開示を通して使用される「有線規格」は、一般に、電気ケーブルを介して信号および／またはデータを離散的にまたは別の信号と組み合わせて送信するための規格を指すが、これに限定されない。そのような有線規格は、デジタル加入者ループ（ＤＳＬ）と、（インターネットサービスプロバイダ（ＩＳＰ）への接続を確立するために公衆交換電話網（ＰＳＴＮ）を利用する）ダイヤルアップと、データオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）と、イーサネットと、ギガビットホームネットワーキング（Ｇ．ｈｎ）と、サービス総合デジタル網（ＩＳＤＮ）と、マルチメディア・オーバー・コウクス・アライアンス（ＭｏＣＡ）と、（ＡＣ／ＤＣ電源にデータが重畳された）電力線通信（ＰＬＣ）とを含んでもよいが、これらに限定されない。いくつかの実施形態では、「有線規格」は、光ケーブル、および、例えば受動光ネットワーク（ＰＯＮ）内などの光インターフェースを利用することを指す場合があるが、これらに限定されない。
【0075】
本明細書で使用される「センサ」は、測定値の大きさに応じて生成され、環境センサと、医学的センサと、生体センサと、化学的センサと、周囲環境センサと、位置センサと、運動センサと、熱センサと、赤外線センサと、可視センサと、ＲＦＩＤセンサと、医療検査と、診断デバイスとを含むがこれらに限定されないグループから選択される電気出力を提供するトランスデューサを指す場合があるが、これらに限定されない。
【0076】
本明細書および本開示を通して使用される「ポータブル電子デバイス」（ＰＥＤ）は、電力のためにバッテリまたは他の独立した形態のエネルギーを必要とする通信および他の用途に使用される無線デバイスを指す。これには、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、携帯型コンピュータ、ポケットベル、携帯型マルチメディアプレーヤー、携帯型ゲームコンソール、ラップトップコンピュータ、タブレットコンピュータ、ウェアラブルデバイス、および電子リーダなどのデバイスが含まれるが、これらに限定されない。
【0077】
本明細書および本開示を通して使用される「固定電子デバイス」（ＦＥＤ）は、電力を得るために固定インターフェースへ接続を必要とする通信および他の用途に使用される無線デバイスおよび／または有線デバイスを指す。これには、ラップトップコンピュータ、パーソナルコンピュータ、コンピュータサーバ、キオスク、ゲームコンソール、デジタルセットトップボックス、アナログセットトップボックス、インターネット対応機器、インターネット対応テレビ、およびマルチメディアプレーヤーが含まれるが、これらに限定されない。
【0078】
本明細書および本開示全体を通して使用される「サーバ」は、他のコンピュータ、ＰＥＤ、ＦＥＤなどのユーザのホストとして１つまたは複数のサービスを実行して、これらの他のユーザのクライアントニーズにサービスを提供する、同じ場所に配置された、および／または地理的に分散された１つまたは複数の物理コンピュータを指す。これには、データベースサーバ、ファイルサーバ、メールサーバ、プリントサーバ、ウェブサーバ、ゲームサーバ、または仮想環境サーバが含まれるが、これらに限定されない。
【0079】
本明細書で使用される（一般に「アプリ」と呼ばれる）「アプリケーション」は、「ソフトウェアアプリケーション」、「ソフトウェアスイート」の要素、個人が活動を実行することを可能にするように設計されたコンピュータプログラム、電子デバイスがアクティビティを実行することを可能にするように設計されたコンピュータプログラム、およびローカル電子デバイスおよび／またはリモート電子デバイスと通信するように設計されたコンピュータプログラムを指す場合があるが、これらに限定されない。したがって、アプリケーションは、（コンピュータを実行する）オペレーティングシステム、（保守または汎用の作業を実行する）ユーティリティ、および（コンピュータプログラムが作成される）プログラミングツールとは異なる。一般に、本発明の実施形態に関する以下の説明では、アプリケーションは、一般に、ＰＥＤおよび／またはＦＥＤに永続的および／または一時的にインストールされるソフトウェアに関して提示される。
【0080】
本明細書で使用される「企業」は、ユーザ、顧客、または消費者に対するサービスおよび／または製品のプロバイダを指す場合があるが、これらに限定されない。これには、小売店、店舗、市場、オンライン市場、製造業者、オンライン小売業者、チャリティ、ユーティリティ、およびサービスプロバイダが含まれるが、これらに限定されない。そのような企業は、会社によって直接所有および制御されてもよく、または、フランチャイザーの指示および管理の下でフランチャイジーによって所有および運営されてもよい。
【0081】
本明細書で使用される「サービスプロバイダ」は、企業および／または個人および／または個人のグループおよび／またはマイクロプロセッサを備えるデバイスに対する、サービスおよび／または製品の第三者プロバイダを指す場合があるが、これらに限定されない。これには、小売店、店舗、市場、オンライン市場、製造業者、オンライン小売業者、ユーティリティ、独自のブランドプロバイダ、およびサービスプロバイダが含まれるが、これらに限定されず、サービスおよび／または製品は、サービスプロバイダのみまたはサービスプロバイダに加えて企業によって市場に出され、販売され、提供され、および流通されるうちの少なくとも１つである。
【0082】
本明細書で使用される「第三者」または「第三者プロバイダ」は、企業および／または個人および／または個人のグループおよび／またはマイクロプロセッサを備えるデバイスへサービスおよび／または製品のいわゆる「アームズ・レングス」プロバイダを指す場合があるが、これらに限定されず、消費者および／または顧客は第三者に関与するが、関心があり、および／または購入し、および／または受け取る実際のサービスおよび／または製品は、企業および／またはサービスプロバイダを介して提供される。
【0083】
本明細書で使用される「ユーザ」は、個人または個人のグループを指す場合があるが、これらに限定されない。これには、個人、組織および／または企業の従業員、コミュニティ組織のメンバー、チャリティ組織のメンバー、男性および女性が含まれるが、これらに限定されない。その最も広い意味で、ユーザは、本発明の１つまたは複数の実施形態を利用する能力によって特徴付けられてもよいソフトウェアシステム、機械システム、ロボットシステム、アンドロイドシステムなどをさらに含んでもよいが、これらに限定されない。ユーザはまた、ダッシュボード、ウェブサービス、ウェブサイト、ソフトウェアプラグイン、ソフトウェアアプリケーション、およびグラフィカルユーザインターフェースを介して、サービスプロバイダ、第三者プロバイダ、企業、ソーシャルネットワーク、ソーシャルメディアなどのうちの１つまたは複数に、１つまたは複数のアカウントおよび／またはプロファイルを介して関連付けられてもよい。
【0084】
本明細書で使用される「バイオメトリック」情報は、限定はしないが、それらの環境、医学的状態、生物学的状態、生理学的状態、化学的状態、周囲環境状態、位置状態、神経学的状態、薬物状態、およびこれらの状態の１つまたは複数の１つまたは複数の特定の態様を含むがこれらに限定されない状態のサブセットに関するデータによって特徴付けられるユーザに関するデータを指す場合がある。したがって、そのようなバイオメトリック情報は、血液酸素化、血圧、血流量、心拍数、テンパレート、流体ｐＨ、粘度、粒子含有量、固形分、高度、振動、運動、発汗、ＥＥＧ、ＥＣＧ、エネルギーレベルなどを含んでもよいが、これらに限定されない。さらに、バイオメトリック情報は、身体の形状および／または身体の状態に関連する生理学的特性に関するデータを含んでもよく、例としては、指紋、顔の形状、禿頭、ＤＮＡ、手の形状、匂い、および香りを含んでもよいが、これらに限定されない。バイオメトリック情報はまた、タイピングリズム、歩行、および音声を含むがこれらに限定されない挙動特性に関するデータを含んでもよい。
【0085】
本明細書で使用される「ユーザ情報」は、ユーザ挙動情報および／またはユーザプロファイル情報を指す場合があるが、これらに限定されない。「ユーザ情報」はまた、ユーザのバイオメトリック情報、ユーザのバイオメトリック情報の推定、または現在および／または履歴の生体情報から導出されたユーザの生体情報の投影／予測を含んでもよい。
【0086】
「ウェアラブルデバイス」または「ウェアラブルセンサ」は、衣類の下、衣類内、衣類と共に、または衣類の上にあるものを含む、およびこれとは対照的に汎用または専用の情報技術およびメディア開発を対象とする「ウェアラブルコンピュータ」を含むより広い一般的なクラスのウェアラブル技術の一部である、ユーザによって着用される小型電子デバイスに関する。そのようなウェアラブルデバイスおよび／またはウェアラブルセンサは、スマートフォンと、スマートウォッチと、ｅテキスタイルと、スマートシャツと、アクティビティ追跡デバイスと、スマートグラスと、環境センサと、医学的センサと、生体センサと、生理学的センサと、化学的センサと、周囲環境センサと、位置センサと、神経学的センサと、薬物送達システムと、医療検査と、診断デバイスと、運動センサとを含んでもよいが、これらに限定されない。
【0087】
本明細書で使用される「衣料品」は、典型的には１つまたは複数の生地、または１つまたは複数の繊維で作られた、ユーザによって着用される衣類を指す。ウェアラブルデバイスまたはウェアラブルセンサは、衣料品の一体部分を形成してもよく、または衣料品に取り外し可能に取り付けられるものであってもよい。
【0088】
本明細書で使用される（「コンテンツ」または「デジタルコンテンツ」とも呼ばれる）「電子コンテンツ」は、記憶、送信、受信、および／または変換されたデジタルデータの形態で存在する任意のタイプのコンテンツを指す場合があるが、これらに限定されず、これらのステップの１つまたは複数はアナログであってもよいが、一般にこれらのステップはデジタルである。デジタルコンテンツの形態には、デジタル放送、ストリーミング、または個別のファイルに含まれる情報が含まれるが、これらに限定されない。狭義に見ると、デジタルコンテンツのタイプには、例えば、ＭＰ３、ＪＰＧ、ＡＶＩ、ＴＩＦＦ、ＡＡＣ、ＴＸＴ、ＲＴＦ、ＨＴＭＬ、ＸＨＴＭＬ、ＰＤＦ、ＸＬＳ、ＳＶＧ、ＷＭＡ、ＭＰ４、ＦＬＶ、およびＰＰＴなどの一般的なメディアタイプ、ならびに他のものが含まれ、例えば、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｌｉｓｔ＿ｏｆ＿ｆｉｌｅ＿ｆｏｒｍａｔｓを参照されたい。より広範なアプローチの中で、デジタルコンテンツマットは、任意のタイプのデジタル情報、例えば、デジタル更新された天気予報、ＧＰＳマップ、電子書籍、写真、ビデオ、Ｖｉｎｅ（商標）、ブログ投稿、Ｆａｃｅｂｏｏｋ（商標）投稿、Ｔｗｉｔｔｅｒ（商標）ツイート、オンラインＴＶなどを含んでもよい。デジタルコンテンツは、ユーザ要求に応じて、生成、選択、作成、変更、および送信されるうちの少なくとも１つである任意のデジタルデータであってもよく、要求は、例えば、クエリ、検索、トリガ、アラーム、およびメッセージであってもよい。
【0089】
本明細書および本開示を通して使用される「プロファイル」は、成人用デバイスの設定および／または制限に関するデータを含むコンピュータおよび／またはマイクロプロセッサ可読データファイルを指す。そのようなプロファイルは、デバイス、サービスなどの製造業者／サプライヤ／プロバイダによって確立されてもよく、そのようなプロファイルは、デバイス、別のデバイス、サーバ、またはサービスプロバイダなどと通信するデバイス、サービス、またはＰＥＤ／ＦＥＤのユーザインターフェースを介してユーザによって確立されてもよい。
【0090】
本明細書で使用される（一般にファイルとして知られている）「コンピュータファイル」は、本開示を通して、コンピュータストレージデバイスに離散的にデータを記録するためのコンピュータリソースを指し、このデータは電子コンテンツである。ファイルは、異なる目的のために設計された異なるタイプのコンピュータファイルのうちの１つによって定義されてもよい。ファイルは、書き込まれたメッセージ、ビデオ、コンピュータプログラム、または多種多様な他のタイプのデータなどの電子コンテンツを記憶するように設計されてもよい。いくつかのタイプのファイルは、一度にいくつかのタイプの情報を記憶することができる。ファイルは、１つまたは複数のソフトウェアアプリケーションを用いて任意の回数、オープン、読み取り、変更、コピー、およびクローズすることができる。典型的には、ファイルは、ファイルが１つまたは複数のストレージデバイス上のどこに位置するかを追跡し、ユーザアクセスを可能にする異なるタイプのメディアを利用して多数の異なるタイプのストレージデバイス上で使用することができるファイルシステムに編成される。ファイルは単にデータ用のコンテナであるため、ファイルのフォーマットはそのコンテンツによって定義されるが、いくつかのプラットフォーム上では、フォーマットは通常そのファイル名拡張子によって示され、バイトをどのように編成して意味のあるものとして解釈しなければならないかについての規則を指定する。例えば、プレーンテキストファイルのバイトは、ＡＳＣＩＩ文字またはＵＴＦ－８文字のいずれかに関連付けられ、画像、ビデオ、およびオーディオファイルのバイトは、他の形で解釈される。いくつかのファイルタイプはまた、メタデータに数バイトを割り当て、ファイルがそれ自体に関するいくつかの基本情報を搬送することを可能にする。
【0091】
本明細書で使用される「暗号化」は、許可された当事者のみがそれを読み取ることができるようにメッセージまたは情報を符号化するプロセスを指す場合があるが、これに限定されない。これには、例えば、Ｔｗｏｆｉｓｈ、Ｓｅｒｐｅｎｔ、ＡＥＳ（Ｒｉｊｎｄａｅｌ）、Ｂｌｏｗｆｉｓｈ、ＣＡＳＴ５、ＲＣ４、３ＤＥＳ、およびＩＤＥＡなどのアルゴリズムを介した対称鍵暗号化、ならびにＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ、Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ｓｔａｎｄａｒｄ、Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ、ＥｌＧａｍａｌ、楕円曲線技術、パスワード認証鍵合意技術、Ｐａｉｌｌｉｅｒ暗号システム、ＲＳＡ暗号アルゴリズム、Ｃｒａｍｅｒ－Ｓｈｏｕｐ暗号システム、およびＹＡＫ認証鍵合意プロトコルなどのアルゴリズムを介した公開鍵暗号化が含まれるが、これらに限定されない。
【0092】
「ブロックチェーン（ｂｌｏｃｋｃｈａｉｎ）」（元々はブロックチェーン（ｂｌｏｃｋ ｃｈａｉｎ））は、暗号化分散型台帳の一実施形態またはＤＬＴの一実施形態を表す。本明細書で使用されるブロックチェーンは、暗号を使用してリンクされ、保護される、ブロックと呼ばれる、レコードの連続的に増加するリストを指す場合があるが、これに限定されない。各ブロックは、典型的には、チェーン内の１つまたは複数の他のブロックの暗号化ハッシュ、タイムスタンプ、および取引データを含む。設計により、ブロックチェーンは本質的にデータの変更に耐性があり、２者間の取引を効率的かつ検証可能かつ永続的に記録できるオープン分散型台帳を提供する。分散型台帳として使用するために、ブロックチェーンは、典型的には、ノード間通信および新しいブロックの検証のためのプロトコルに集合的に従うピアツーピアネットワークによって管理される。記録されると、任意の所与のブロック内のデータは、チェーン内のすべての後続のブロックの変更なしに遡及的に変更することはできず、ネットワークの大部分の結託を必要とする。したがって、ブロックチェーンは設計によって安全であり、高いビザンチン障害耐性を有する分散コンピューティングシステムの一例である。したがって、イベント、医療記録、およびアイデンティティ管理、金融取引処理、出所証明、食品トレーサビリティ、投票などの他の記録管理アクティビティの記録に適したものにするブロックチェーンを用いて、分散型コンセンサスが達成されている。本発明の実施形態では、暗号化ハッシュはまた、チェーン内の次のブロックのアドレスのポインタ（および場合によってはハッシュ）を含んでもよい。
【0093】
本明細書で使用される「分散型台帳」は、複数のサイト、機関、および／または地理にわたって広がる１つまたは複数のネットワークにわたって合意により共有および同期されるデータベースを指す場合があるが、これに限定されない。それは、取引が公開「証人」を有することを可能にし、それによってサイバー攻撃をより困難にする。ネットワークの各ノードの参加者は、そのネットワークで共有される記録にアクセスすることができ、その同一のコピーを所有することができる。さらに、台帳に行われたいかなる変更または追加は、通常は数秒または数分以内に、迅速にすべての参加者に反映およびコピーされる。分散型台帳技術の基礎はブロックチェーンである。
【0094】
本明細書で使用される「暗号通貨」は、暗号を使用してその取引を保護し、追加のユニットの作成を制御し、資産の転送を検証する交換メディアとして機能するように設計されたデジタル資産を指す場合があるが、これに限定されない。暗号通貨は、デジタル通貨、代替通貨、および仮想通貨の一種である。暗号通貨は、集中型電子マネーおよび中央銀行システムとは対照的に、分散型制御を使用する。各暗号通貨の分散型制御は、分散型台帳として機能する公開取引データベースであるブロックチェーンを介して行われる。
【0095】
本明細書で使用される「自己主権型アイデンティティ」（ＳＳＩ）は、仲介機関または集中型機関の許可を要求することを強いられることなく、ユーザが１つまたは複数のクレデンシャルを完全に作成および制御することを可能にし、ユーザの個人データがどのように共有および使用されるかについての制御をユーザに与える、ユーザのデジタルアイデンティティを指す場合があるが、これに限定されない。ＳＳＩを用いて、ユーザは、一意の識別子を生成および制御する手段、ならびにアイデンティティデータを記憶するための何らかの機能を有する。ＳＳＩは、分散型の方法で記憶された個別のアイデンティティまたは分散型のアイデンティティであってもよいが、その最も広い範囲では、例えば、ユーザのソーシャルメディアアカウントデータ、ユーザによる電子商取引（ｅコマース）サイト上の取引の履歴、または他の個人および／または企業（例えば、友人または同僚）からの証明のセットなど、ユーザに関連付けられたデータのセットであってもよい。したがって、ＳＳＩがその一部を形成する分散型のアイデンティティのパラダイムでは、ユーザはフレームワークの中心にあり、第三者がアイデンティティを発行および管理する必要はない。しかしながら、ユーザは、そのＳＳＩを第三者プロバイダまたはサービスプロバイダによって記憶させることを選択してもよい。
【0096】
分散型台帳個人データシステムおよびプラットフォーム
【0097】
図１を参照すると、本発明の実施形態による、分散型台帳個人データ（ＤｅＬｅＰｅＤａ）システム、アプリケーション、およびプラットフォーム（ＤｅＬｅＰｅＤａ－ＳＡＰ）を介して本発明の実施形態をサポートするネットワーク１００が示されている。図示されるように、第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂは、電気通信ネットワーク１００にそれぞれインターフェースする。代表的な電気通信アーキテクチャにおいて、リモート中央交換機１８０は、例えば長距離ＯＣ－４８／ＯＣ－１９２バックボーン要素、ＯＣ－４８広域ネットワーク（ＷＡＮ）、受動光ネットワーク、および無線リンクを含んでもよいネットワーク１００を介して残りの電気通信サービスプロバイダネットワークと通信する。中央交換機１８０は、ネットワーク１００を介してローカル、地域、および国際交換機（明確にするために図示せず）に接続され、その中でネットワーク１００を介して第１のユーザグループ１００Ａおよび第２のユーザグループ１００ＢにそれぞれＷｉ－Ｆｉセルを提供する第１のセルラＡＰ１９５Ａおよび第２のセルラＡＰ１９５Ｂにそれぞれ接続される。ネットワーク１００には、第１のＷｉ－Ｆｉノード１１０Ａおよび第２のＷｉ－Ｆｉノード１１０Ｂも接続されており、後者はルータ１０５を介してネットワーク１００に結合されている。第２のＷｉ－Ｆｉノード１１０Ｂは、他の第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂを含む商用サービスプロバイダ１６０と関連付けられる。第２のユーザグループ１００Ｂはまた、ＤＳＬと、ダイヤルアップと、ＤＯＣＳＩＳと、イーサネットと、Ｇ．ｈｎと、ＩＳＤＮと、ＭｏＣＡと、ＰＯＮと、電力線通信（ＰＬＣ）とを含むがこれらに限定されない有線インターフェースを介してネットワーク１００に接続されてもよく、これらはルータ１０５などのルータを介してルーティングされてもされなくてもよい。
【0098】
第１のＡＰ １１０Ａに関連付けられるセル内で、第１のユーザグループ１００Ａは、例えば、ラップトップコンピュータ１５５、携帯型ゲームコンソール１３５、タブレットコンピュータ１４０、スマートフォン１５０、携帯電話１４５、および携帯型マルチメディアプレーヤー１３０を含む様々なＰＥＤを使用してもよい。第２のＡＰ１１０Ｂに関連付けられるセル内で、例えばゲームコンソール１２５、パーソナルコンピュータ１１５、および無線／インターネット対応テレビ１２０、ならびにケーブルモデム１０５を含む様々なＦＥＤを使用してもよい第２のユーザグループ１００Ｂがある。第１のセルラＡＰ １９５Ａおよび第２のセルラＡＰ １９５Ｂは、例えば、セルラＧＳＭ（グローバル・システム・フォー・モバイル・コミュニケーションズ）電話サービス、ならびに強化されたデータトランスポートサポートを有する３Ｇおよび４Ｇ発展型サービスをそれぞれ提供する。第２のセルラＡＰ １９５Ｂは、例示的な実施形態におけるカバレッジを第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂに提供する。あるいは、第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂは、地理的に異なっていてもよく、明確にするために示されていないが、１人または複数のネットワークオペレータによって地理的に分散された複数のＡＰを介してネットワーク１００にアクセスしてもよい。図示のような第１のセルラＡＰ １９５Ａは、第１のユーザグループ１００Ａに、および第１のユーザグループ１００Ａと同様に第２のユーザグループ１００Ｂを含む環境１７０にカバレッジを提供する。したがって、第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂは、それらの特定の通信インターフェースに従って、例えばＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、ＵＭＴＳ、ＧＳＭ８５０、ＧＳＭ９００、ＧＳＭ１８００、ＧＳＭ１９００、ＧＰＲＳ、ＩＴＵ－Ｒ５．１３８、ＩＴＵ－Ｒ５．１５０、ＩＴＵ－Ｒ５．２８０、およびＩＭＴ－１０００などの１つまたは複数の無線通信規格を介してネットワーク１００と通信してもよい。多くのポータブル電子デバイスおよび固定電子デバイスが複数の無線プロトコルを同時にサポートしてもよく、例えば、ユーザが電話、ＳＭＳ、Ｗｉ－Ｆｉ／ＷｉＭＡＸデータ伝送、ならびにＶＯＩＰおよびインターネットアクセスなどのＧＳＭサービスを使用してもよいことは、当業者には明らかであろう。したがって、第１のユーザグループ１００Ａ内のポータブル電子デバイスは、ＩＥＥＥ８０２．１５およびＢｌｕｅｔｏｏｔｈなどの規格を介して、アドホックな方法で関連付けを形成してもよい。
【0099】
ネットワーク１００にはまた、ソーシャルネットワーク（ＳＯＣＮＥＴＳ）１６５、第１のサービスプロバイダ１７０Ａおよび第２のサービスプロバイダ１７０Ｂのそれぞれ、第１の第三者サービスプロバイダ１７０Ｃおよび第２の第三者サービスプロバイダ１７０Ｄのそれぞれ、ならびにユーザ１７０Ｅが接続されている。また、ネットワーク１００には、第１の企業１７５Ａおよび第２の企業１７５Ｂのそれぞれ、第１の組織１７５Ｃおよび第２の組織１７５Ｄのそれぞれ、ならびに政府エンティティ１７５Ｅも接続されている。これらの各々は、本発明の実施形態であるかまたは本発明の実施形態をサポートするＤｅＬｅＰａＤａ－ＳＡＰを利用および／またはサポートしてもよい。また、分散型台帳個人データ（ＤｅＬｅＰｅＤａ）システム、アプリケーション、プラットフォーム（ＤｅＬｅＰｅＤａ－ＳＡＰ）、ならびに、連絡先管理システムおよび連絡先管理アプリケーション／プラットフォームのプロバイダ、ＤｅＬｅＰｅＤａ－ＳＡＰ機能を利用するＳＯＮＥＴまたはソーシャルメディア（ＳＯＭＥ）のプロバイダ、ＤｅＬｅＰｅＤａ－ＳＡＰ機能を利用していないＳＯＮＥＴおよび／またはＳＯＭＥのプロバイダ、ＰＥＤＳおよび／またはＦＥＤＳに対するサービスのプロバイダ、有線通信および／または無線通信の１つまたは複数の態様のプロバイダ、ＤｅＬｅＰｅＤａ－ＳＡＰ機能を利用する企業１６０、ライセンスデータベース、コンテンツデータベース、画像データベース、コンテンツライブラリ、顧客データベース、ウェブサイト、ならびにＤｅＬｅＰｅＤａ－ＳＡＰ機能を利用および／またはホストするＦＥＤおよび／またはＰＥＤならびにＤｅＬｅＰｅＤａ－ＳＡＰを利用するユーザへのダウンロードまたはそれらによるアクセスのためのソフトウェアアプリケーションに関連付けられた、本発明の実施形態による複数のサービスをホストしてもよい第１のサーバ１９０Ａおよび第２のサーバ１９０Ｂが示されている。第１の一次コンテンツサーバ１９０Ａおよび第２の一次コンテンツサーバ１９０Ｂはまた、例えば、検索エンジン、金融サービス、第三者アプリケーションおよび他のインターネットベースのサービスなどの他のインターネットサービスをホストしてもよい。
【0100】
また、図１には、ユーザ、組織などがＤｅＬｅＰｅＤａ－ＳＡＰにアクセスして利用することを可能にする、本発明の実施形態によるＤｅＬｅＰｅＤａ電子デバイス（ＤｅＬｅＰｅＤａ－ＥＤ）１０００が示されている。図１に示されるように、ＤｅＬｅＰｅＤａ－ＥＤ１０００はネットワーク１００に直接通信することができる。ＤｅＬｅＰｅＤａ－ＥＤ１０００は、例えば、ＩＥＥＥ８０２．１１と、ＩＥＥＥ８０２．１５と、ＩＥＥＥ８０２．１６と、ＩＥＥＥ８０２．２０と、ＵＭＴＳと、ＧＳＭ８５０と、ＧＳＭ９００と、ＧＳＭ１８００と、ＧＳＭ１９００と、ＧＰＲＳと、ＩＴＵ－Ｒ５．１３８と、ＩＴＵ－Ｒ５．１５０と、ＩＴＵ－Ｒ５．２８０と、ＩＭＴ－１０００と、ＤＳＬと、ダイヤルアップと、ＤＯＣＳＩＳと、イーサネットと、Ｇ．ｈｎと、ＩＳＤＮと、ＭｏＣＡと、ＰＯＮと、電力線通信（ＰＬＣ）とを含むグループから選択されたものを含む１つまたは複数の無線インターフェースまたは有線インターフェースを介してネットワーク１００と通信してもよい。
【0101】
したがって、ユーザは、ＤｅＬｅＰｅＤａ－ＥＤ１０００を利用して、ＰＥＤ、ＦＥＤ、企業１６０、ＳＯＣＮＥＴＳ１６５、第１のサービスプロバイダ１７０Ａ、第２のサービスプロバイダ１７０Ｂ、第１の第三者サービスプロバイダ１７０Ｃ、第２の第三者サービスプロバイダ１７０Ｄ、および別のユーザ１７０Ｅのうちの１つまたは複数と直接対話してもよい。あるいは、ユーザは、ＤｅＬｅＰｅＤａ－ＥＤ１０００を利用して、第１の企業１７５Ａ、第２の企業１７５Ｂ、第１の組織１７５Ｃ、第２の組織１７５Ｄ、政府エンティティ１７５Ｅ、第１のサーバ１９０Ａ、および第２のサーバ１９０Ｂのうちの１つまたは複数と対話してもよい。ユーザは、ＤｅＬｅＰｅＤａ－ＥＤ１０００を利用して、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ機能を提供するアプリケーションへのアクセス／ダウンロード、ＤｅＬｅＰｅＤａ－ＳＡＰ機能を提供する既にインストールされたアプリケーションの実行、ＤｅＬｅＰｅＤａ－ＳＡＰ機能を提供するウェブベースのアプリケーションの実行、コンテンツへのアクセス、コンテンツ生成、データ取得、およびデータ提供などの１つまたは複数の動作を実行してもよい。同様に、iユーザは、第１のセルラＡＰ１９５Ａおよび第２のセルラＡＰ１９５Ｂのそれぞれのうちの１つと第１のＷｉ－Ｆｉノード１１０Ａとを介して、第１のユーザグループ１００Ａおよび第２のユーザグループ１００Ｂのそれぞれの内のＰＥＤまたはＦＥＤと併せてＤｅＬｅＰｅＤａ－ＥＤ１０００を使用することによって、本発明の実施形態を利用するそのような動作または他の動作を行ってもよい。また、ユーザは、ネットワーク１００を利用して、電話、ファックス、電子メール、ＳＭＳ、ソーシャルメディアなどを介して通信してもよく、またはＤｅＬｅＰｅＤａ－ＥＤ １０００を使用してローカルＰＥＤもしくはＦＥＤおよび／またはリモートＰＥＤもしくはＦＥＤに関して１つまたは複数の動作をトリガしてもよいことは明らかであろう。さらに、図２に関して明らか、かつ後述されるように、ユーザは、直接または間接的に、別のＤｅＬｅＰｅＤａ－ＥＤ１０００に関する１つまたは複数の動作をそれらのＤｅＬｅＰｅＤａ－ＥＤ１０００からトリガしてもよい。
【0102】
ここで図２を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ機能をサポートする電子デバイス２０４およびネットワークアクセスポイント２０７が示されている。電子デバイス２０４は、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＥＤ１０００であってもよく、または本発明の実施形態によるＤｅＬｅＰｅＤａ－ＥＤ１０００とインターフェースしてもよい。電子デバイス２０４は、上述および図示されたものを超える追加の要素を含んでもよく、または、説明および図示されたいくつかの要素を省略してもよい。また、電子デバイス２０４内には、電子デバイス２０４と、第１のＡＰ１１０などのアクセスポイント（ＡＰ）２０６と、通信サーバ、ストリーミングメディアサーバなどの１つまたは複数のネットワークデバイス２０７と、例えばそれぞれ第１のサーバ１９０Ａおよび第２のサーバ１９０Ｂなどのルータとを含むシステム２００の簡略化された機能図の一部としてのプロトコルアーキテクチャも示されている。ネットワークデバイス２０７は、図１に関して上述したようなネットワーク、有線通信リンク、無線通信リンク、および／または光通信リンクの任意の組み合わせを介して、ならびに示されるように直接ＡＰ２０６に結合してもよい。ネットワークデバイス２０７は、ネットワーク１００およびその中のソーシャルネットワーク（ＳＯＣＮＥＴＳ）１６５、第１のサービスプロバイダ１７０Ａおよび第２のサービスプロバイダ１７０Ｂのそれぞれ、第１の第三者サービスプロバイダ１７０Ｃおよび第２の第三者サービスプロバイダ１７０Ｄのそれぞれ、ユーザ１７０Ｅ、第１の企業１７５Ａおよび第２の企業１７５Ｂのそれぞれ、第１の組織１７５Ｃおよび第２の組織１７５Ｄのそれぞれ、ならびに政府エンティティ１７５Ｅに結合される。
【0103】
電子デバイス２０４は、１つまたは複数のプロセッサ２１０と、１つまたは複数のプロセッサ２１０に結合されたメモリ２１２とを含む。ＡＰ２０６はまた、１つまたは複数のプロセッサ２１１と、１つまたは複数のプロセッサ２１０に結合されたメモリ２１３とを含む。プロセッサ２１０および２１１のいずれかの例の非網羅的なリストは、中央処理装置（ＣＰＵ）と、デジタル信号プロセッサ（ＤＳＰ）と、縮小命令セットコンピュータ（ＲＩＳＣ）と、複合命令セットコンピュータ（ＣＩＳＣ）などとを含む。さらに、プロセッサ２１０および２１１のいずれかは、特定用途向け集積回路（ＡＳＩＣ）の一部であってもよいし、特定用途向け標準製品（ＡＳＳＰ）の一部であってもよい。メモリ２１２および２１３の例の非網羅的なリストは、レジスタ、ラッチ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリデバイス、不揮発性ランダムアクセスメモリデバイス（ＮＶＲＡＭ）、ＳＤＲＡＭ、ＤＲＡＭ、ダブルデータレート（ＤＤＲ）メモリデバイス、ＳＲＡＭ、ユニバーサルシリアルバス（ＵＳＢ）リムーバブルメモリなどの半導体デバイスの任意の組み合わせを含む。
【0104】
電子デバイス２０４は、プロセッサ２１０のいずれかに結合された、例えばマイクロフォンなどのオーディオ入力要素２１４と、例えばスピーカなどのオーディオ出力要素２１６とを含んでもよい。電子デバイス２０４は、プロセッサ２１０のいずれかに結合された、例えばビデオカメラまたはカメラなどのビデオ入力要素２１８と、例えばＬＣＤディスプレイなどのビデオ出力要素２２０とを含んでもよい。電子デバイス２０４はまた、キーボード２１５およびタッチパッド２１７を含み、これらは例えば、ユーザが複数のアプリケーション２２２のうちの１つの内でコンテンツを入力または機能を選択することを可能にする物理キーボードおよびタッチパッドであってもよい。あるいは、キーボード２１５およびタッチパッド２１７は、電子デバイス２０４内のディスプレイの一部を形成するタッチ感受性要素の所定の領域であってもよい。典型的にはメモリ２１２に記憶され、プロセッサ２１０の任意の組み合わせによって実行可能な１つまたは複数のアプリケーション２２２。電子デバイス２０４はまた、プロセス２１０に三次元運動入力を提供する加速度計２６０と、地理的位置情報をプロセッサ２１０に提供するＧＰＳ ２６２とを含む。
【0105】
電子デバイス２０４はプロトコルスタック２２４を含み、ＡＰ２０６はＡＰスタック２２５を含む。システム２００内のプロトコルスタック２２４は、例えばＩＥＥＥ８０２．１１プロトコルスタックが存在してもよいが、代わりに、電子デバイス２０４は、例えばインターネット技術特別調査委員会（ＩＥＴＦ）マルチメディアプロトコルスタックなどの他のプロトコルスタックを利用してもよい。プロトコルスタック２２４およびＡＰスタック２２５の要素は、ソフトウェア、ファームウェア、および／またはハードウェアの任意の組み合わせで実装されてもよい。例えば、プロトコルスタック２２４は、１つまたは複数のフロントエンドＴｘ／Ｒｘ＆アンテナ２２８に結合されたＩＥＥＥ８０２．１１互換ＰＨＹモジュールと、ＩＥＥＥ８０２．２互換ＬＬＣモジュールに結合されたＩＥＥＥ８０２．１１互換ＭＡＣモジュールとを含んでもよい。プロトコルスタック２２４はまた、ネットワーク層ＩＰモジュールと、トランスポート層ユーザデータグラムプロトコル（ＵＤＰ）モジュールと、トランスポート層伝送制御プロトコル（ＴＣＰ）モジュールとを含んでもよい。
【0106】
プロトコルスタック２２４はまた、セッション層リアルタイムトランスポートプロトコル（ＲＴＰ）モジュールと、セッション通知プロトコル（ＳＡＰ）モジュールと、セッション開始プロトコル（ＳＩＰ）モジュールと、およびリアルタイムストリーミングプロトコル（ＲＴＳＰ）モジュールとを含んでもよい。プロトコルスタック２２４はまた、提示層メディアネゴシエーションモジュールおよび呼制御モジュールと、この例では別個に示されている１つまたは複数のオーディオコーデック２５２と１つまたは複数のビデオコーデック２５４とを含んでもよい。アプリケーション２２２は、ＡＰ２０６によってデバイス２０７のいずれかとの通信セッションを維持および／または終了してもよい。典型的には、アプリケーション２２２は、その目的のために、ＳＡＰ、ＳＩＰ、ＲＴＳＰ、メディアネゴシエーション、および呼制御モジュールのうちのいずれかを起動してもよい。典型的には、情報は、ＴＣＰモジュール、ＩＰモジュール、ＬＬＣモジュール、およびＭＡＣモジュールを介して、ＳＡＰ、ＳＩＰ、ＲＴＳＰ、メディアネゴシエーション、および呼制御モジュールからＰＨＹモジュールへ伝播してもよい。
【0107】
例えばＩＥＥＥ８０２．１１互換ＰＨＹモジュールと、ＩＥＥＥ８０２．１１互換ＭＡＣモジュールと、ＩＥＥＥ８０２．２互換ＬＬＣモジュールとを含むプロトコルスタック２２４の１つまたは複数の要素を含むがこれらに限定されない、電子デバイス２０４の要素もＡＰ ２０６内に実装してもよいことは当業者には明らかであろう。ＡＰ２０６は、ネットワーク層ＩＰモジュールと、トランスポート層ユーザデータグラムプロトコル（ＵＤＰ）モジュールおよびトランスポート層伝送制御プロトコル（ＴＣＰ）モジュールと、セッション層リアルタイムトランスポートプロトコル（ＲＴＰ）モジュールと、セッション通知プロトコル（ＳＡＰ）モジュールと、セッション開始プロトコル（ＳＩＰ）モジュールおよびリアルタイムストリーミングプロトコル（ＲＴＳＰ）モジュールと、メディアネゴシエーションモジュールと、呼制御モジュールとをさらに含んでもよい。電子デバイス２０４によって表されるポータブル電子デバイスおよび固定電子デバイスは、ＩＥＥＥ８０２．１５と、ＩＥＥＥ８０２．１６と、ＩＥＥＥ８０２．２０と、ＵＭＴＳと、ＧＳＭ８５０と、ＧＳＭ９００と、ＧＳＭ１８００と、ＧＳＭ１９００と、ＧＰＲＳと、ＩＴＵ－Ｒ５．１３８と、ＩＴＵ－Ｒ５．１５０と、ＩＴＵ－Ｒ５．２８０と、ＩＭＴ－１０００と、ＤＳＬと、ダイヤルアップと、ＤＯＣＳＩＳと、イーサネットと、Ｇ．ｈｎと、ＩＳＤＮと、ＭｏＣＡと、ＰＯＮと、電力線通信（ＰＬＣ）とを含むグループから選択されてもよい図示のＩＥＥＥ８０２．１１インターフェースに加えて、１つまたは複数の追加の無線インターフェースまたは有線インターフェースを含んでもよい。
【0108】
また、図２には、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＥＤ１０００が示されており、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、電子デバイス２０４は、ＤｅＬｅＰｅＤａ－ＥＤ１０００を表してもよい。図２に示されるように、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＥＤ１０００は、ネットワーク１００に直接通信してもよく、一方、他のＤｅＬｅＰｅＤａ－ＥＤ１０００は、ネットワークデバイス２０７、アクセスポイント２０６、および電子デバイス２０４と通信してもよい。いくつかのＤｅＬｅＰｅＤａ－ＥＤ１０００は、他のＤｅＬｅＰｅＤａ－ＥＤ１０００と直接通信してもよい。図２において、ネットワーク１００、ネットワークデバイス２０７、ＡＰ２０６、および電子デバイス２０４に結合されたＨＰＤ－ＥＤ１０００は、無線インターフェースを介して通信する。しかしながら、本発明の他の実施形態では、ＤｅＬｅＰｅＤａ－ＥＤ１０００は、連続的ではなく定期的にまたは無線で有線インターフェースを介して結合されてもよい。各ＤｅＬｅＰｅＤａ－ＥＤ１０００は、別の電子デバイス、例えばアクセスポイント２０６、電子デバイス２０４およびネットワークデバイス２０７、またはネットワーク、例えばネットワーク１００と通信してもよい。各ＤｅＬｅＰｅＤａ－ＥＰ１０００は、例えば、ＩＥＥＥ８０２．１１と、ＩＥＥＥ８０２．１５と、ＩＥＥＥ８０２．１６と、ＩＥＥＥ８０２．２０と、ＵＭＴＳと、ＧＳＭ８５０と、ＧＳＭ９００と、ＧＳＭ１８００と、ＧＳＭ１９００と、ＧＰＲＳと、ＩＴＵ－Ｒ５．１３８と、ＩＴＵ－Ｒ５．１５０と、ＩＴＵ－Ｒ５．２８０と、ＩＭＴ－１０００と、ＤＳＬと、ダイヤルアップと、ＤＯＣＳＩＳと、イーサネットと、Ｇ．ｈｎと、ＩＳＤＮと、ＭｏＣＡと、ＰＯＮと、電力線通信（ＰＬＣ）とを含むグループから選択されたものを含む、１つまたは複数の無線インターフェースまたは有線インターフェースをサポートしてもよい。
【0109】
任意選択で、有線通信インターフェースデバイスおよび／または無線通信インターフェースではなく、デバイスは、光通信インターフェースおよび／または衛星通信インターフェースなどの他の通信インターフェースを利用してもよい。光通信インターフェースは、イーサネット、ギガビットイーサネット、ＳＯＮＥＴ、同期デジタルハイアラーキー（ＳＤＨ）などをサポートしてもよい。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＥＤは、別のＤｅＬｅＰｅＤａ－ＥＤ、ＰＥＤ、またはＦＥＤに情報を提供するウェアラブルデバイスを表してもよい。
【0110】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、ＤｅＬｅＰｅＤａ－ＥＤは、例えば、ユーザプロファイルと、ユーザ情報と、コンピュータファイルと、電子コンテンツとを含む、ユーザに関する追加情報を記憶してもよい。したがって、ＤｅＬｅＰｅＤａ－ＥＤは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内でＤｅＬｅＰｅＤａ－ＳＡＰが追加情報の一部またはすべてをブロックチェーンまたは分散型台帳に暗号化してもよいように追加情報を使用してもよい。
【0111】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、ＤｅＬｅＰｅＤａ－ＥＤは１つまたは複数のセンサを含んでもよい。例えば、センサは、バイオメトリックセンサと、環境センサと、医学的センサと、生体センサと、化学的センサと、周囲環境センサと、位置センサと、運動センサと、熱センサと、赤外線センサと、可視センサと、ＲＦＩＤセンサと、医療検査と、診断デバイスとを含んでもよいが、これらに限定されない。したがって、ＤｅＬｅＰｅＤａ－ＥＤは、１つまたは複数のセンサからのデータを使用し、追加情報の一部またはすべてをブロックチェーンまたは分散型台帳に暗号化してもよい。本発明の一実施形態によるＤｅＬｅＰｅＤａ－ＥＤは、離散的、定期的、または連続的にユーザの特性を確立するために、医師または他の医療従事者にデータを提供するために使用されてもよい。したがって、ＤｅＬｅＰｅＤａ－ＨＤまたはＤｅＬｅＰａＤａ－ＳＡＰは、ユーザの生理学的状態に関するデータを追跡および転送してもよい。
【0112】
分散型台帳個人データ概念
【0113】
個人向け人工知能（ＡＩ）主導ヘルスケアシステムの開発を妨げる多数の課題がある。その中には以下がある。
・クライアントデータのプライバシーおよびセキュリティ
・第三者使用に対する文書化された同意の要件
・クライアントが自身のデータの主権を得ることを支援する方法がないこと
・クライアントにデータ共有を促進するための要件
・データ共有のユースケース
・データ品質およびデータソースの均一なセマンティクスおよび保証の制御のための要件
・実世界のデータにアクセスするための要件
・クライアントデータのプライバシーおよびセキュリティ
・第三者使用に対する文書化された同意の要件
・クライアントが自身のデータの主権を得ることを支援する方法がないこと
・クライアントにデータ共有を促進するための要件
・データ共有のユースケース
・データ品質およびデータソースの均一なセマンティクスおよび保証の制御のための要件
・実世界のデータにアクセスするための要件
【0114】
したがって、本発明者らは、個人向けのプロアクティブなヘルスを促進し、ヘルスを制御するのを促進するために立ちはだかる障壁を除去するエコシステムを作成する、本明細書内で「ＭｙＰＤｘ」と呼ばれるプラットフォームを確立することに焦点を合わせた。それにより、ＭｙＰＤｘは、本発明の実施形態によればＤｅＬｅＰａＤａ－ＳＡＰを表す。
【0115】
以下の明細書において、本発明者らは、２つの特定のユーザケースを説明および図示するが、これらが複数のユースケースのうちの２つのみを表すことは明らかであろう。第１の例示的なユーザケース、ケース１は、ＡＩ主導の個人ヘルス研究を促進するために、個人のヘルスデータを共有する確信をユーザに与えるという問題に対処する。第２のユーザケース、ケース２は、ユーザが顧客とみなされ、保険事業者が支払者とみなされてもよい従業員給付プログラムを介して、雇用者および保険事業者と個人のヘルスデータを共有する確信をユーザに与えるという問題に対処する。両方のユースケースとも、ヘルスケア従事者が、病気へ焦点を置くことからウェルネスへ１つの焦点を置くことへの継続的な重点移行をサポートするＡＩ主導の個人向けヘルスケアの促進という共通の目的に対処する。
【0116】
したがって、これらのユースケースを考慮して、各ユースケースに関与する主要当事者の「作業者」の概要、および本発明の実施形態を利用するヘルスケアエコシステムに参加することによって各当事者がどのように利益を得るかを以下に概説する。以下の説明では、カナダのＭｏｌｅｃｕｌａｒ Ｙｏｕ社を指すために略語「ＭＹ」が使用される。
【0117】
ケース１－個人向けヘルス研究
・クライアントの制御下でプライバシー保護および安全な個人のヘルスデータ共有を可能にする「ＭＹクライアント」（例えば、ユーザ）
・個人向けのヘルス研究アプリケーションなどのためにデータを共有することをＭＹクライアントにインセンティブを与える「ＭＹ研究パートナー」
・高度なプライバシー保護およびセキュリティを提供することによって個人のヘルスデータ共有をサポートするプラットフォームを提供する「ＭＹ」
・倫理審査委員会は、研究者に倫理クレデンシャルを発行し、個人が共有時にデータが適切に取り扱われることを検証できるようにする
・クライアントの制御下でプライバシー保護および安全な個人のヘルスデータ共有を可能にする「ＭＹクライアント」（例えば、ユーザ）
・個人向けのヘルス研究アプリケーションなどのためにデータを共有することをＭＹクライアントにインセンティブを与える「ＭＹ研究パートナー」
・高度なプライバシー保護およびセキュリティを提供することによって個人のヘルスデータ共有をサポートするプラットフォームを提供する「ＭＹ」
・倫理審査委員会は、研究者に倫理クレデンシャルを発行し、個人が共有時にデータが適切に取り扱われることを検証できるようにする
【0118】
ケース２－支払者／保険事業者
・クライアントの制御下でプライバシー保護および安全な個人のヘルスデータ共有を可能にする「ＭＹクライアント」（例えば、ユーザ）
・ＭＹクライアントからのデータへアクセスすることによって、より正確な保険コスト、リスク、モデリング、およびウェルネス促進を可能にすることができる支払者／保険事業者
・データへのアクセスを得ることによって、ヘルスケアレビュー、リスク評価を実行し、規制要件などを満たすだけでなく、１つまたは複数の給付パッケージを評価し、潜在的に保険コストを削減することができる雇用者
・高度なプライバシー保護およびセキュリティを提供することによって個人のヘルスデータ共有をサポートするプラットフォームを提供し、個人のヘルスデータを多数の多様な垂直市場にわたって使用を可能にする「ＭＹ」
・クライアントの制御下でプライバシー保護および安全な個人のヘルスデータ共有を可能にする「ＭＹクライアント」（例えば、ユーザ）
・ＭＹクライアントからのデータへアクセスすることによって、より正確な保険コスト、リスク、モデリング、およびウェルネス促進を可能にすることができる支払者／保険事業者
・データへのアクセスを得ることによって、ヘルスケアレビュー、リスク評価を実行し、規制要件などを満たすだけでなく、１つまたは複数の給付パッケージを評価し、潜在的に保険コストを削減することができる雇用者
・高度なプライバシー保護およびセキュリティを提供することによって個人のヘルスデータ共有をサポートするプラットフォームを提供し、個人のヘルスデータを多数の多様な垂直市場にわたって使用を可能にする「ＭＹ」
【0119】
したがって、ＭＹは、ＭＹクライアント、ＭＹ研究パートナー、支払者、保険事業者、雇用者、および様々な第三者プロバイダ、サービスプロバイダ、企業などに提供するのに必要なエコシステムを構築するプラットフォームを確立する個人向けデータ交換（ＭｙＰＤｘ）を提供する。ケース１およびケース２では、ＭＹ研究パートナーおよび雇用者はデータシーカに一般化してもよいが、ＭＹクライアントはデータ所有者に一般化してもよく、データシーカがデータ所有者の個人データ、例えばヘルスデータまたはバイオマーカーの１つまたは複数の項目にアクセスすることを望む他のユースケースが明確にサポートされることが明らかであろう。これは、例えば研究者、雇用者などのプロアクティブなアクセス希望であってもよく、または、例えば医師、歯科医、栄養士、眼科医などに行うことができるようなデータ所有者からの要求に応じた応答性のアクセス希望であってもよい。
【0120】
したがって、ＭｙＰＤｘは、１つまたは複数の第三者ではなくユーザに自身のヘルスデータの所有権を提供し、ユーザが誰とデータを共有するか、どのデータを共有するかを選択し、最終的にそれがどの目的または複数の目的に使用されるかを決定することを可能にする。ＭｙＰＤｘは、インフォームドコンセントなしに、および害を引き起こす大きな可能性を有する方法で、個人の個人データが収集され、第三者と共有され、第三者によって使用される複数の例に経時的に対処し、防止することを求める。経時的に、これらの事象は、ユーザの信頼を低下させ、機密性の高いヘルス情報を収集するサービスを使用することに不本意にさせる。これは、個人が自分のヘルスリスクを理解するために使用することができ、自分の全体的なヘルスを維持または改善することを可能にする個人向けヘルスレビューを受け取ることから大きな利益を得ることができる場合であっても当てはまる。この不本意は、データ侵害、データの盗難などを考慮しなくても、データを提供するヘルスデータサービスがデータをどのようにして経時的に記憶および使用するかについての不確実性から生じる。
【0121】
したがって、欧州では、規制当局が、個人に個人データの制御を与えることを目的とした（一般にＧＤＰＲと呼ばれる）一般データ保護規則２０１６／６７９を制定した。ビジネスプロセスは、データを保護し、デフォルトで可能な限り最高のプライバシー設定を使用するための保護手段を提供しなければならず、その結果、データは明示的なインフォームドコンセントなしでは公開して利用できず、対象を識別するために使用できない。いかなる個人データも、この同意をいつでも取り消す権利を有するデータサブジェクト（ユーザ）からの同意の明示的な明確な肯定を伴わずに処理されてはならない。
【0122】
しかしながら、ユーザはどのようにして自分の情報を共有し、その後販売されたり、不正使用されたり、盗まれるなどをしないことを企業に同意したことを確信するか。したがって、本発明の実施形態、例えばＭｙＰＤｘは、ユーザに確信および信頼を与えることによって、これらのより厳しい規制に準拠することを意図している。これは、個人にそのデータの直接的な特定の所有権を与え、個人がそのデータのデータ共有に対する詳細な同意を確立できるようにすることによって達成される。さらに、本発明の実施形態は、データの直接的な詳細なユーザレベル制御を提供することによって、ユーザが自分のデータを共有することを促進し、それによってユーザが自分のヘルス、ヘルスケアにおいてプロアクティブになり、病気の治療の１つからユーザに焦点を当ててウェルネスを治療する１つへヘルスケアの焦点の移行をサポートし、可能にするプロアクティブな個人向けヘルスエコシステムの一部を形成することを促進する。
【0123】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、本発明者らは、プライベートで安全なデータ共有を提供するためのソリューションとしてブロックチェーン技術を利用する。しかしながら、本発明の他の実施形態では、本発明の範囲から逸脱することなく、他の分散型台帳技術を使用してもよいことは明らかであろう。ブロックチェーンは、不正開封を困難にするために一緒に連鎖されたブロックに保有される確認および検証された取引のセットを使用する。ブロックチェーンの設計は、プライバシーの分散型管理を様々な特徴の中でサポートするネットワーク化された分散された自律的なグローバル動作を利用する。様々なブロックチェーンプラットフォームが存在し、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で使用されてもよい。本発明の実施形態の発明者らによる例示的な実装形態は、ＭｙＰＤｘのためのブロックチェーンプラットフォームとして「Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙ」を利用する。しかしながら、分散型プライバシー管理を達成するためにそれらのデータに対するユーザ制御を提供するように特別に設計または変更されている他のブロックチェーンプラットフォームが使用されてもよいことは明らかであろう。
【0124】
従来技術では、ブロックチェーン技術をヘルスケア記録に使用するいくつかの例があったが、これらは主に組み合わせて、いわゆる「クラウド」コンピューティングまたはクラウド技術をブロックチェーンと組み合わせてセキュリティ層を提供することを試みてきた。医療デバイス間の安全な通信または医療保険の安全な保管のためのブロックチェーン技術の使用を検討してきた人もいる。
【0125】
しかしながら、本発明の実施形態は、例えば、ある医師から別の医師に今日移動することを望む患者は、他の医師に記録を転送するように医師に依頼しなければならないなど、従来の集中型医療記録管理から全体的な焦点を移行する。むしろ、本発明の実施形態は、患者が現在の医師へのアクセスを取り消し、新しい医師へのアクセスを許可することができる患者（ユーザ）中心のモデルを確立する。従来の集中型医療記録管理からより患者中心のモデルへの移行はまた、埋め込まれたまたは埋め込まれていない経済層を追加して、データの貢献およびデータ使用を患者に補償することを可能にする。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、ユーザは、自分のヘルスデータを研究に利用可能にすることに対する同意の提供に応じて、例えば暗号通貨を介して金銭的報酬を提供してもよく、報酬は、共有されるデータおよび共有される正確なデータの程度に応じて決定してもよい。
【0126】
したがって、ＭｙＰＤｘなどの本発明の実施形態は、オープンソースのブロックチェーンフレームワーク（例えば、Ｈｙｐｅｒｌｅｄｇｅｒ Ａｒｉｅｓ／Ｉｎｄｙ）を活用して、プライバシーを保護し、ユーザが確立した粒度で個人のヘルスデータを安全に共有することを可能にする新規のブロックチェーンソリューションを提供する。本発明者らは、最初に、上述の２つのユースケースのためのＭｙＰＤｘプラットフォームを確立した。しかしながら、本発明の実施形態は、ヘルスケアセクタ内の様々な他のユースケースをサポートしてもよい。本発明の実施形態は、他の商業、産業、学術、個人セクタなどにおける様々なユースケースをサポートしてもよいことも明らかであろう。ケース１は、例えば研究プロジェクトに参加する資格があるとして研究者が個人を検証することを可能にし、データを共有することに同意するなど、個人、例えばユーザにクレデンシャルを発行しなければならないという点でケース２とは異なることも明らかである。これにより、クレデンシャルを失効させると、その個人による記録へのアクセスが阻止される。別のユースケースでは、クレデンシャルは、例えば、患者が、アクセスを許可したい医師がライセンスを与えられているか検証できるように、医師にライセンスを与える一般医療顧問によって発行されてもよい。ここでも、医師のライセンス、したがってクレデンシャルの失効は、記録へのアクセスを阻止する。
【0127】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で使用される信頼スタックの例示的な概略図を図３に説明および図示する。したがって、第１のＰＥＤ３１０からから第３の３３０、またはＦＥＤ３４０を介したユーザは、クラウドエージェント／クラウドウォレット３５０へアクセスしてもよい。複数のクラウドエージェント／クラウドウォレット３５０は、任意のペアのクラウドエージェント／クラウドウォレット３５０間の検証可能な請求の安全な交換を提供する。概念的には、クラウドエージェント／クラウドウォレット３５０のこの第１の層内では、オブザーバ３６０のオブザーバプールを備える第２の層であり、オブザーバ３６０はＡＩ対応デバイス、アプリケーション、またはシステムであってもよい、クラウドエージェント／クラウドウォレット３５０のための／クラウドエージェント／クラウドウォレットによるブロックチェーンブロックおよび／または自己主権型アイデンティティ（ＳＳＩ）の検証／認証の態様を監視および管理する。オブザーバ３６０のこの第２の層は、オブザーバ３６０のための／オブザーバによるブロックチェーンブロックおよび／またはＳＳＩの検証／認証の態様を監視および管理するバリデータ３７０のバリデータプールの周りに概念的に配置される。したがって、図３に示されるように、オブザーバプールおよびバリデータプールは、例えばプライベートセクタの国際非営利組織であるＳｏｖｒｉｎ Ｆｏｕｎｄａｔｉｏｎによって提供されるものなどのＳＳＩネットワークによって提供されてもよい。
【0128】
したがって、ＭｙＰＤｘは、ユーザが研究、個人および／またはビジネス目的のためのデータ共有を可能にしながら、ヘルス情報のプライバシーおよびセキュリティを保護するという課題に対処するための新規のアプローチをユーザに提供する。ソリューションの設計は、データの共有を可能にし、インセンティブを与えながらも、基本的にユーザのプライバシーを尊重する方法で、ユーザに個人のヘルスデータへのアクセスの所有権および制御を与える。
【0129】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、ユーザのヘルスデータのアプリケーションに関連付けられた複数の当事者の各当事者は、例えば、あるアプリケーションはケース１であってもよく、別のアプリケーションはケース２であってもよく、ブロックチェーンウォレットと対話して互いに取引を実行する。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、ブロックチェーンウォレット（ウォレット）は、暗号鍵（例えば、秘密鍵）、秘密（例えば、リンク秘密、パスワードなど）、他の機密暗号鍵素材、およびエンティティ（例えば、ウォレットにアクセスする許可を有する当事者）によって使用される他のデータ（例えば、ユーザプライベートデータ）を安全に記憶およびアクセスするためのソフトウェアモジュール、および任意選択的に関連付けられたハードウェアモジュールであってもよい。したがって、ユースケース１では、複数の当事者がＭｙクライアントおよびＭｙ研究パートナーであり、ケース２では、複数の当事者が支払者／保険事業者および／または雇用者のＭｙクライアントである。
【0130】
上述したように、本発明の実施形態をサポートするＤｅＬｅＰａＤａ－ＳＡＰの一実施形態を表すＭｙＰＤｘは、ブロックチェーンフレームワークを利用する。ＭｙＰＤｘの開発は、上述したように、Ｈｙｐｅｒｌｅｄｇｅｒ Ａｒｉｅｓ／Ｉｎｄｙブロックチェーンフレームワークを利用するが、他のブロックチェーンおよび／または分散型台帳フレームワークは、本発明の実施形態をサポートするか、または本発明の実施形態をサポートするように修正される限り、本発明の範囲から逸脱することなく使用してもよい。
【0131】
Ｈｙｐｅｒｌｅｄｇｅｒ Ａｒｉｅｓ／Ｉｎｄｙ（ＨＬ Ａｒｉｅｓ／Ｉｎｄｙ）は、Ｌｉｎｕｘ Ｆｏｕｎｄａｔｉｏｎによって維持されているオープンソースのブロックチェーンフレームワークであり、パブリックドメインネットワーク、例えばインターネットにわたってユーザに分散型台帳ベースの信頼層を提供する。したがって、本発明の実施形態による分散型アイデンティティ管理ユースケースを可能にする。ＨＬは、以下の４つのコアの構成要素を備える。
・検証可能な請求
・ピアツーピアエージェント
・分散型識別子
・分散型台帳
・検証可能な請求
・ピアツーピアエージェント
・分散型識別子
・分散型台帳
【0132】
本明細書の範囲内の検証可能な請求は、暗号学的に真正であり、否認不可能であるエンティティによって作成された機械可読ステートメントである（すなわち、ステートメントの作成者は、その作成者または関連付けられた契約の有効性に異議を申し立てることができない）。したがって、「所有者」エージェントが、「発行者」エージェントから別の「検証者」エージェントに、受信側検証者エージェントが暗号的に真正であることを証明することができるピアツーピア接続を介して受信した暗号化クレデンシャル、すなわち証明可能なデジタル署名されたデータを送信すると、検証可能な請求が作成される。各対話型エージェントは、分散型識別子、任意の集中型レジストリ、アイデンティティプロバイダ、または認証局から独立したＳＳＩなどの検証可能な識別子を有し、分散型識別子は、各ペアワイズ接続における通信を容易にするために使用される。ＨＬ Ｉｎｄｙは、選択的開示およびゼロ知識証明（エージェントが何を知っているかを明らかにすることなく、エージェントがパスワードなどの何かを知っていることを証明することを可能にする暗号技術）などのプライバシー強化技術をサポートする。分散型台帳、すなわち、ノードのセットにわたって共有され、コンセンサスメカニズム（例えば、実用的なビザンチン障害耐性）を使用してノード間で同期される台帳は、発行者エージェント、クレデンシャルのデータスキーマ、クレデンシャル定義、および失効レジストリなどの（請求の暗号検証を可能にする）公開分散型識別子（ＤＩＤ）を記憶するために使用される。
【0133】
本発明の一実施形態による例示的なアーキテクチャを表す図４および図５の大まかなアーキテクチャ。図４に示されるように、大まかなアーキテクチャは、フロントエンド４１０およびバックエンド４２０からなり、これらは各々、パブリックネットワーク、例えばインターネット４００に接続される。フロントエンド４１０は、Ｍｏｌｅｃｕｌａｒ Ｙｏｕ社（ＭＹ）のクライアントであるシステムのユーザに対するバリデータ／トラストアンカーおよびクレデンシャル発行者として機能するＭＹと、ユースケースの１人または複数のパートナー（例えば、研究のための研究プロジェクトを宣伝する研究パートナー）とを含む。フロントエンドユーザは、ＲＥＳＴ ＡＰＩ呼び出しを使用してバックエンド４２０と通信する。バックエンド４２０は、ＬＩＢＶＣＸおよびＬＩＢＩＮＤＹに基づいて構築されたＩｎｄｙ－Ｄｊａｎｇｏコミュニティを使用して設計されている。バックエンド４１０の第２の構成要素は、特定用途向けデータを有し、かつＳＱＬｉｔｅデータベースに記憶されるＭｙＡＰＩである。Ｉｎｄｙ Ｄｊａｎｇｏコミュニティは、クライアントによって受信されたクレデンシャルを記憶する役割を担うＰｏｓｔｇｒｅＳＱＬデータベースに作成および記憶されるウォレットのサポートを提供する。また、Ｉｎｄｙ Ｄｊａｎｇｏコミュニティは、分散型台帳、すなわち分散型アイデンティティを提供するためのブロックチェーンのサポートを提供する。公開ＤＩＤ（分散型識別子）、スキーマ定義およびクレデンシャル定義は、分散型台帳／ブロックチェーン内に記憶される。
【0134】
このプロセスは、図１１に概略的に示されており、ユーザ１１００Ａは、最初にＭｙＰＤｘサービスにレジストリし、ＭＹＣＯ１１００Ｂによって保有されている記憶された個人データからウォレット内にデータを確立している。したがって、クライアント１１００Ａは、ＭＹ Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙ（ＭＹＨＩ）と呼ばれるＭｙＰＤｘサービスのダッシュボードにログインし、「ヘルスウォレット」サービスを要求する。ＭＹＨＩログインプロセスは、クライアントアイデンティティを識別し、クライアント１１００ＡのためのセッションをＭＹＣＯ１１００Ｂと確立する。クライアント１１００Ａが初めてヘルスウォレット（ウォレット１１１０）を確立している場合、ＭＹＣＯエージェント１１４０は、コード１１５０を含むクライアント１１００Ａに対する招待を発行する。これは、例えば、ユーザ１１００Ａが現在ログインしているダッシュボード内のユーザにレンダリングされるＱＲコードの形態であってもよく、または登録プロセス中に（例えば、その場合にＱＲコードがそのスマートフォンへ送信されるその電話番号、その場合にＱＲコードがその電子メールアドレスへ送信される電子メールアドレスなど）クライアント１１００Ａによって入力されたアイデンティティに基づいてユーザのＰＥＤなどの別の通信チャネルを介してもよい。クライアントエージェント１１２０を確立するためのＭＹＣＯエージェント１１４０からの招待を確立するために、ＱＲコード以外の初期データ通信の他のフォーマットが使用されてもよいことは明らかであろう。ＱＲコードが例えばダッシュボード内でレンダリングされた場合、クライアント１１００Ａは、クライアントエージェント１１２０が確立されているＱＲコードの画像を捕捉してもよい。その後、クライアント１１００Ａは、招待を受け入れる。これにより、ブロックチェーン１１９０上の定義済みクレデンシャル１１０４０を指す、ＭＹＣＯウォレット１１８０内のクレデンシャル１１７０が作成される。したがって、ＭＹＣＯエージェント１１４０を介してクライアントエージェント１１２０とＭＹＣＯウォレット１１８０との間に既に作成されている接続を使用して、クライアント１１２０は、そのウォレット１１１０へ転送されるレポート（すなわち、ＭＹＣＯが保有する記録）から個人データを要求することができる。
【0135】
ＭＹＣＯ１１００Ｂのアイデンティティの証明としてクライアント１１１０Ａに提示されたコード１１５０は、ブロックチェーン１１９０上のＭＹＣＯ ＤＩＤ １１０１０を指す。同様に、クライアント１１００Ａのアイデンティティの証明としてクライアント１１１０ＡによってＭＹＣＯ１１００Ｂに提示された証明１１３０は、ブロックチェーン１１９０上のクライアントＤＩＤ１１０３０を指す。ＭＹＣＯウォレット１１８０内のクレデンシャル１１７０によって指し示される定義済みクレデンシャル１１０４０は、ＭＹＣＯ ＤＩＤ １１０１０およびクライアントＤＩＤ１１０３０にスキーマ１１０２０を適用することによって確立された一意のクレデンシャルである。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰに関して明らかになるように、クライアントＤＩＤ１１０３０および／またはＭＹＣＯ ＤＩＤ１１０１０は、クライアント１１００ＡからＭＹＣＯ１１００Ｂへ各要求に対して一意に確立されてもよく、個人データの各要求は一意の定義済みクレデンシャル１１０４０に関連付けられる。さらに、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰに関して明らかになるように、この定義済みクレデンシャル１１０４０は、クライアント１１００Ａが実際にＭＹＣＯ１１００Ｂからの個人データを要求した監査証跡の一部を提供してもよい。個人データはブロックチェーン１１９０に記憶されることなくＭＹＣＯウォレット１１８０からウォレット１１１０へ転送されるため、結果として得られる監査証跡はクライアント１１００Ａの個人データを一切含まない。ＭＹＣＯ１１００Ｂがクライアント１１００Ａから個人データを取得することを望む場合、図１１に示す例示的なプロセスを逆に見ることができる。
【0136】
この例示的なプロセスはまた、図１２に示されており、それぞれステップＡ～Ｅを示す、以下の通りである。
・ステップＡ：クライアントがＭＹＨＩダッシュボードにログインし、「ヘルスウォレット」サービスを介してヘルスウォレット１２２０を要求し、ＭＹＨＩログインがクライアントのアイデンティティを識別する
・ステップＢ：ヘルスウォレットを初めて取得するクライアントに対して、ＭｙＣＯエージェント１２３０は、ＱＲコード（例えば）の形式でクライアント１２１０に対する招待を発行する
・ステップＣ：クライアント１２１０は、クライアントモバイルエージェント１２４０内の招待をスキャンし、招待を受け入れる
・ステップＤ：クライアントモバイルエージェント１２４０とヘルスウォレット１２２０との間に既に作成されている接続を使用して、クライアント１２１０はそれらのレポートからクレデンシャルを要求することができる
・ステップＥ：ＭｙＣＯは、クライアントモバイルエージェント１２４０にヘルスクレデンシャルを発行し、その中の個人のウォレットに格納する
・ステップＡ：クライアントがＭＹＨＩダッシュボードにログインし、「ヘルスウォレット」サービスを介してヘルスウォレット１２２０を要求し、ＭＹＨＩログインがクライアントのアイデンティティを識別する
・ステップＢ：ヘルスウォレットを初めて取得するクライアントに対して、ＭｙＣＯエージェント１２３０は、ＱＲコード（例えば）の形式でクライアント１２１０に対する招待を発行する
・ステップＣ：クライアント１２１０は、クライアントモバイルエージェント１２４０内の招待をスキャンし、招待を受け入れる
・ステップＤ：クライアントモバイルエージェント１２４０とヘルスウォレット１２２０との間に既に作成されている接続を使用して、クライアント１２１０はそれらのレポートからクレデンシャルを要求することができる
・ステップＥ：ＭｙＣＯは、クライアントモバイルエージェント１２４０にヘルスクレデンシャルを発行し、その中の個人のウォレットに格納する
【0137】
本発明の他の実施形態では、クライアント１２１０は、「ヘルスウォレット」を要求するのではなく、本発明の範囲から逸脱することなく、財務データに関連する「金融ウォレット」、個人データに関連する「個人のウォレット」、学術データに関連する「学術ウォレット」などを要求してもよいことは明らかであろう。
【0138】
図５に示されるように、フロントエンド５１０は、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、例えばｖｕｅ．ｊｓの上部に構築されたＮｕｘｔ．ｊｓを利用してもよい１つまたは複数のウェブページとしてグラフィカルユーザインターフェース（ＧＵＩ）をユーザに提供する。本発明者らは、ウェブページの開発のためにＶｕｅフレームワークを採用したが、これは、漸進的に適応可能なアーキテクチャをサポートすることに加えて、開発のための様々な任意選択のツールを提供し、既存のアプリケーションとの統合を容易にする。初期開発実装用のＧＵＩウェブページは、そのフロントエンドＣＳＳライブラリ用のＢｏｏｔｓｔｒａｐを使用して設計されており、本発明者らが応答性モバイルおよびウェブアプリケーションを迅速にプロトタイプ化することを可能にする。
【0139】
ウェブベースのアプリケーションのフロントエンド５１０は、インターネットを介してバックエンドウェブサービス５２９と通信し、これは、発明者らによって開発されたプロトタイプ内で、Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙ Ａｇｅｎｔアプリケーションを開発するためのクラウドベースのフレームワークを提供するパイソンライブラリであるＩｎｄｙ－Ｄｊａｎｇｏコミュニティライブラリを利用した。Ｉｎｄｙ Ｄｊａｎｇｏは、ＬＩＢＶＣＸおよびＬＩＢＩＮＤＹ、すなわちＨｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙライブラリのサポートを提供する。ＬＩＢＩＮＤＹは、Ｒｕｓｔで記述されたネイティブライブラリへ外部関数インターフェース（ＦＦＩ）を使用して実装される。ＬＩＢＶＣＸは、高度なクレデンシャル交換プロトコルを提供するＬＩＢＩＮＤＹ上に構築されたｃ呼び出し可能ライブラリである。ＬＩＢＶＣＸは、エージェントアプリケーションの作成を支援し、Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙインフラストラクチャのためのより良いエージェント間の相互運用性を提供する。
【0140】
アプリケーション関連ＡＰＩは、その中にプロジェクトデータを包含するＭｙＡＰＩに含まれる。バリデータ／トラストアンカー、クレデンシャル発行者、研究パートナーまたはクライアントなどのシステムに入るユーザは、ＭｙＡＰＩの一部として定義および作成される。Ｉｎｄｙ Ｄｊａｎｇｏコミュニティはウォレットサービスのサポートも提供し、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、ウォレットは、暗号化形式でトラストアンカーから受信したクライアントのクレデンシャルを保有する。ＭｙＰＤｘのプロトタイプ用のウォレットは、ＰｏｓｔｇｒｅＳＱＬで実装されている。
【0141】
２つの代表的なユーザケース、ケース１およびケース２に関して上述したように、ＭｙＰＤｘ初期プロトタイプ実装形態は４つの主要な対話当事者を有するが、本発明の実施形態のアプリケーション内の当事者の数は２つから上方に変化してもよいことは当業者には明らかであろう。したがって、アプリケーションフローの最初のステップは、ＭＹクライアントがそれらのバイオマーカーの各々について暗号化クレデンシャルを要求するときに行われる。その後、ＭＹは、これらのクレデンシャルを各々のデータ所有者（ＭＹクライアント）の個人ヘルスウォレットに発行する。代表的なユーザケースであるケース１およびケース２は、ヘルスベースのアプリケーションに関するものであるため、クライアントからの要求は、ユーザのヘルス情報、すなわちバイオマーカーに関するものである。しかしながら、他のユースケースでは、ユーザが共有を希望し、したがって暗号化クレデンシャルを要求するデータは、個人データを含むがこれに限定されない他のデータであってもよい。
【0142】
ケース１を考慮すると、本発明の一実施形態によれば、研究は、彼らの研究を行うために倫理証明書を倫理審査委員会（ＥＲＢ）に申請し、承認されると、倫理証明書が暗号化クレデンシャルの形態で申請者／研究者のウォレットへ送信される。研究者が倫理的承認を得ると、研究者はＭｙＰＤｘプラットフォームを使用して、研究プロジェクトをデータ所有者（すなわち、ユーザ／患者）に宣伝することができる。
【0143】
データ所有者が参加したい研究プロジェクトに気付いたとき、これは、Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙベースのブロックチェーンネットワークを使用して「ハンドシェイク」プロセスを開始し、ここで、データ所有者は、研究プロジェクトが必要な倫理的承認を有することを検証し、研究者は、データ所有者が研究基準を満たしていることを検証し、データ共有に対する同意を得る。データ所有者が研究に必要な特定のヘルスデータ（例えば、バイオマーカー）を共有すると、プロセスは完了する。任意選択で、研究者または研究のスポンサーは、暗号化クレデンシャル（例えば、暗号通貨報酬）にあってよい、研究へ参加に対する報酬をデータ所有者へ送信してもよい。典型的には、報酬は、研究者が有意義かつ適切な方法でデータを共有するためのデータ所有者を認識することを可能にするゲノミクスと健康のための世界連合（ＧＡ４ＧＨ）の原理に従う。
【0144】
図６は、データ所有者（すなわち、ＭＹクライアント）とＭｙＰＤｘの研究者との間で行われるこのケース１（研究ユースケース）アプリケーションフローの視覚的概要を提供する。プロセス全体の重要な特徴は、データ所有者のアイデンティティが研究者に明らかにされることはなく、個人のヘルス情報がブロックチェーンに記録または記憶されることはなく、データ所有者は常に自分の個人のヘルス情報を制御したままであり、取引のリスク利益の評価を考慮すると、自分が快適と感じる情報のみを明らかにすることである。取引全体は、データ所有者と研究者との間の特定の関係に対してのみ存在するウォレットを介して行われ、それらの当事者のみが、それぞれウォレットにデータを入れ、そこからデータを取得するための暗号化クレデンシャルを有する。
【0145】
ここで第２の例示的なユーザケース、ケース２を考慮すると、例示的なアプリケーションフローが図７に示されている。
したがって、ＭｙＰＤｘにおける本発明の一実施形態のこのユースケースは、やはり４つの主要当事者を有する。しかしながら、このアプリケーションフローは、以下を可能にする。
・従業員の現在のウェルネスレベルを証明するヘルスクレデンシャルを従業員に発行するＭＹ
・従業員は、自らのヘルスクレデンシャルを安全かつプライバシー保護のために使用者／保険事業者との間で、知識証明の検証可能な請求を共有する
・保険事業者は、雇用者または保険事業者が個々の従業員に関する個人のヘルス情報を知る、または追跡する必要なく、雇用者の従業員集団のウェルネス軌跡を即座に確認し、それに応じて保険料を調整する
したがって、ＭｙＰＤｘにおける本発明の一実施形態のこのユースケースは、やはり４つの主要当事者を有する。しかしながら、このアプリケーションフローは、以下を可能にする。
・従業員の現在のウェルネスレベルを証明するヘルスクレデンシャルを従業員に発行するＭＹ
・従業員は、自らのヘルスクレデンシャルを安全かつプライバシー保護のために使用者／保険事業者との間で、知識証明の検証可能な請求を共有する
・保険事業者は、雇用者または保険事業者が個々の従業員に関する個人のヘルス情報を知る、または追跡する必要なく、雇用者の従業員集団のウェルネス軌跡を即座に確認し、それに応じて保険料を調整する
【0146】
したがって、雇用者および／または保険事業者は、離散的に、またはフォローアップ動作に基づく継続的なインセンティブ、データ共有などと組み合わせて、情報を共有することに対する報酬を従業員に提供することができ、従業員は、ユーザ固有のヘルスケア計画に従い、よりヘルス的な行動をとるようにインセンティブを与えられる。ＭＹがヘルスクレデンシャルを発行する最初のステップは、共有された１つまたは複数のバイオマーカーが処理されて、従業員の現在のウェルネスレベルを判定するために使用される結果を判定する、図８およびケース１に関して説明および図示されたようなプロセスフローを使用して実行され得ることは明らかであろう。
【0147】
したがって、このようなユースケースは、安全なエコシステムに参加する者に、各当事者の利益を提供する。従業員の場合、従業員は、個人のヘルス情報が明らかにされることを恐れずに、従業員がヘルスな状態を保つのに役立つ定期的な情報と、そのための報酬を受け取ることができる。雇用者にとって、雇用者は、ウェルネス指向の職場文化を促進し、保険料の削減を受けることができる。保険事業者にとって、全体的なウェルネスが向上し、リスクモデルの正確な調整に使用するための安全でプライバシーを保護するデータソースを有するので、病気に対する保険のコストは下がる。
【0148】
ユーザによって確立されたプロトタイプＭｙＰＤｘなどの本発明の実施形態では、個人のヘルスデータがブロックチェーンに記録されないことに留意することが重要である。代わりに、ＭｙＰＤｘなどの本発明の一実施形態は、ブロックチェーン上に公開分散型識別子（公開ＤＩＤ）、クレデンシャルスキーマ、およびクレデンシャル定義のみを記憶する。したがって、図９を参照すると、ケース１、研究ユースケースのクレデンシャルスキーマおよびクレデンシャル定義の概要が示されている。この例では、ユーザは「Ａｌｉｃｅ」という名前である。図示のように、フローには、ウォレットを確立するためのＡｌｉｃｅからの最初の要求に関連するもの、研究者のクレデンシャルの生成に関連するものなどは含まれていない。
【0149】
本発明の一実施形態は、独立して制御される連合エンティティ（バリデータノード）によって動作する構成要素を有する分散型システムとして動作することは明らかであろう。構成要素は、オンプレミスまたはクラウド（例えば、サービスとしてのインフラストラクチャ（ＩａａＳ）モデル）内で維持されてもよい。フロントエンドおよびバックエンド構成要素は、クライアント－サーバ展開モデルを使用し、フロントエンド（例えば、デバイス、ウェブアプリケーション）はバックエンドサーバを呼び出し、バックエンドサーバはその後ブロックチェーンと通信する。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の構成要素の動作の責任および場所は、以下の通りであり得る。
・ソリューションのフロントエンド－ＭＹによって提供されるが、クライアントのエンドポイントデバイスまたはパートナーのエンドポイントデバイス（例えば、直接またはウェブブラウザを介したウェブベースのアプリケーションを介してＰＥＤまたはＦＥＤ）で動作するアプリケーション。ＭＹはまた、各クライアントのＤＩＤペアおよびクレデンシャルの記憶に使用されるデータベース、およびクライアントのクレデンシャルとともにアプリケーション固有データの記憶に使用されるデータベースのサポートも提供する。これらのデータベースの各々は、クラウド内に維持されてもよい。
・ソリューションバックエンド－バリデータプール内のノード、例えば、トラストアンカーおよび／またはクレデンシャル発行者は、独立したエコシステムパートナーによって制御および運用され、その各々は、例えば、別個の法的エンティティであってもよい。これらのノードを維持および運用することは、個々のパートナーの責任である。それらは、オンプレミスまたはクラウド内のノードを動作させてもよい。
・ソリューションのフロントエンド－ＭＹによって提供されるが、クライアントのエンドポイントデバイスまたはパートナーのエンドポイントデバイス（例えば、直接またはウェブブラウザを介したウェブベースのアプリケーションを介してＰＥＤまたはＦＥＤ）で動作するアプリケーション。ＭＹはまた、各クライアントのＤＩＤペアおよびクレデンシャルの記憶に使用されるデータベース、およびクライアントのクレデンシャルとともにアプリケーション固有データの記憶に使用されるデータベースのサポートも提供する。これらのデータベースの各々は、クラウド内に維持されてもよい。
・ソリューションバックエンド－バリデータプール内のノード、例えば、トラストアンカーおよび／またはクレデンシャル発行者は、独立したエコシステムパートナーによって制御および運用され、その各々は、例えば、別個の法的エンティティであってもよい。これらのノードを維持および運用することは、個々のパートナーの責任である。それらは、オンプレミスまたはクラウド内のノードを動作させてもよい。
【0150】
したがって、本発明者らの発明概念は、個人が自分自身のデータの管理および制御を行い、誰が自分のデータにアクセスでき、どのような目的でアクセスできるかを管理することができるように、自己主権型アイデンティティ（ＳＳＩ）を活用する。ブロックチェーンは、台帳外取引を容易にするために使用されるパブリックアイデンティティおよびドキュメント定義を管理および配布するためのプラットフォームを提供するために使用される。したがって、個人の個人データはブロックチェーンに書き込まれず、それにより、ユーザに個人データの管理におけるセキュリティおよび信頼性が向上する。さらに、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、発行および検証などの当事者間の実際の取引はブロックチェーン台帳に書き込まれない。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のエージェントは、アプリケーションが安全かつプライバシーを保護する方法でデータを接続および交換するための設備を提供する。したがって、本発明者の方法は、固有の「設計によるプライバシー」をユーザに提供するアプリケーションにおいてＳＳＩを活用し実装する。したがって、本発明の実施形態は、分散型台帳内に個人データを記憶しない分散型台帳を介して分散型のアイデンティティおよび検証可能なクレデンシャルを活用するフレームワークを提供する。
【0151】
本発明の実施形態は、ヘルスケアデータの管理および共有を変えるための新しい形態の人間の関与および調整を可能にする技術開発を利用する。したがって、本発明の実施形態は、ブロックチェーンを活用して、中央調整、監視、または支配機関のない分散型協調を確立するための新しい技術インフラストラクチャを作成する。したがって、本発明者らの発明概念は、ユーザの手元で個人データ管理を提供し、公開されてアクセス可能な分散型台帳に個人データを記憶することなく（暗号化されていても）安全な方法でその共有を提供することによって、報酬の発行および転送の有無にかかわらず、新しい形態の価値の創出および配布を可能にする。ＭｙＰＤｘソリューションは、エコシステム内、およびエコシステムと第三者との間の外部の両方で、価値の創出および配布の新しい方法を予測する。これらは、ＭｙＰＤｘソリューションが提供するサービスに結合されたデジタル報酬の形成に依存する新しい経済モデルを伴う。
【0152】
上述したように、本発明の実施形態は、各顧客が自己主権型アイデンティティ（ＳＳＩ）を有するという基礎の上に構築されている。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、このＳＳＩは、ユーザのバイオマーカーに基づく不可分なデジタルヘルスアイデンティティであり得る。本発明の実施形態によるＭｙＰＤｘプラットフォームおよびＤｅＬａＰｅＤａ－ＳＡＰの早期採用者は、雇用者、保険事業者、規制者などの企業が特定の目的のために個人データ共有を必要とする前に、ヘルスを意識した個人であると予想される。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、プライバシーを保護する方法で、例えば研究者、雇用者、および支払者とデータを安全に交換する。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰの採用を推進する様々な要因が予想される。これらの要因は、現在のヘルスケア提供モデルが企業対消費者（Ｂ２Ｃ）の１つから消費者対企業（Ｃ２Ｂ）に反転されるヘルスの状況に対して設定される。これは、消費者はサービスを押し付けられるのではなく、引き出していることを意味する。ヘルスケア提供の将来は、データの相互運用性、プライバシー、セキュリティ、および所有権に焦点を当てた革新的な技術および個人向けのプログラムを活用し、採用することが期待されている。使用新しい状況は、可処分所得、モバイルおよびオンラインのヘルスケアツールの使用、疲弊したヘルスケアシステム、プライバシーの中核を有するより技術に精通したエンドユーザ、および増加するデータセキュリティリスクを有する高齢化人口から浮上している。
【0153】
ＭｙＰＤｘなどの本発明の実施形態の顧客／エンドユーザの採用に影響を与える要因には、以下を含んでもよいが、これらに限定されない。
・データのプライバシーおよびセキュリティに関する懸念
・制御および同意に関する懸念
・エンドユーザが付着していると感じる原因および研究、ならびにそれらのデータが価値、すなわち癌研究を提供することができる市場に参加するための経路
・エンドユーザは、データ共有を承諾した対価として報酬を受け取る
・合意されたメトリックに基づく価格の引き下げとデータの共有を通じた柔軟な保険契約の可能性
・個人向け保険契約
・情報、動機、およびサポートのためのソーシャルヘルスネットワーク
・自己指向型／自己診断型ヘルスケア
・医師およびヘルス指導者との個人データ交換
・個人向けのヘルス改善計画
・データのプライバシーおよびセキュリティに関する懸念
・制御および同意に関する懸念
・エンドユーザが付着していると感じる原因および研究、ならびにそれらのデータが価値、すなわち癌研究を提供することができる市場に参加するための経路
・エンドユーザは、データ共有を承諾した対価として報酬を受け取る
・合意されたメトリックに基づく価格の引き下げとデータの共有を通じた柔軟な保険契約の可能性
・個人向け保険契約
・情報、動機、およびサポートのためのソーシャルヘルスネットワーク
・自己指向型／自己診断型ヘルスケア
・医師およびヘルス指導者との個人データ交換
・個人向けのヘルス改善計画
【0154】
ＭｙＰＤｘなどの本発明の実施形態の支払者／研究者／雇用者の採用に影響を与える要因には、以下が含まれ得るが、これらに限定されない。
・データへ同意されたアクセス
・新たなプライバシー規制への準拠およびデータ制御に対する消費者の期待
・消費されたデータに対してのみ支払う
・安全な方法で当事者間でデータを共有するための改良された使いやすいプラットフォーム
・市場は、データの購入者と販売者との間の摩擦を低減し、データの取得コストを低減する
・高品質な認証、検証可能データの提供
・保険契約および従業員給付プラットフォームのより良いレートおよびより良いリスク管理モデルを提供する
・承諾されたデータを有する参加ベースのプログラム
・リアルタイムのヘルスデータに基づく成果ベースのプログラム
・ビッグデータおよびスマートダッシュボードへのアクセスおよびより良い活用
・モバイルヘルス技術、ウェアラブル、および他のデジタルプログラム
・ヘルス、コンテンツ、およびカスタマイズ／チャネル最適化の良好なデータ分析
・保険および従業員給付プログラムのための給付および処方管理
・データへ同意されたアクセス
・新たなプライバシー規制への準拠およびデータ制御に対する消費者の期待
・消費されたデータに対してのみ支払う
・安全な方法で当事者間でデータを共有するための改良された使いやすいプラットフォーム
・市場は、データの購入者と販売者との間の摩擦を低減し、データの取得コストを低減する
・高品質な認証、検証可能データの提供
・保険契約および従業員給付プラットフォームのより良いレートおよびより良いリスク管理モデルを提供する
・承諾されたデータを有する参加ベースのプログラム
・リアルタイムのヘルスデータに基づく成果ベースのプログラム
・ビッグデータおよびスマートダッシュボードへのアクセスおよびより良い活用
・モバイルヘルス技術、ウェアラブル、および他のデジタルプログラム
・ヘルス、コンテンツ、およびカスタマイズ／チャネル最適化の良好なデータ分析
・保険および従業員給付プログラムのための給付および処方管理
【0155】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、コンソーシアムパートナーは、単一の検証ノードを動作させて、これを許可されているが真に分散型のプラットフォームにすることができ、これは同時に、より大きなパブリックネットワーク（例えば、ＳＳＩネットワーク）と対話することができる。コンソーシアムのパートナーおよびそれらの動作するバリデータノードまたはトラストアンカーは、例えば、民間の営利エンティティ、民間の非営利エンティティ、または公的機関であってもよい。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内には、データ購入者のサブスクリプション料金およびデータ購入者からエンドユーザへ支払われる取引手数料が存在してもよい。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、ＭＹクライアントとしてオンボードされると、エンドユーザはＭｙＰＤｘウォレットにアクセスしてヘルスケアクレデンシャルを記憶する。これは無料であってもよく、または本発明の実施形態が他の方法に対して提供するセキュリティ上の利点のためにコストが請求されてもよい。
【0156】
この料金は、例えば、ヘルスデータを販売および記憶するための毎月のサブスクリプションであってもよい。この取引手数料は、トークンにリンクされるのではなく、市場ベースであってもよいし、トークンにリンクされてもよい。例えば、医療記録ごとの料金は、記録の完全性に従って、低い数字、例えば０．１０ドルから高い値、例えば１，０００ドルまで変化し得る。
【0157】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、支払いの明細がプラットフォームを介して（例えば、スマートコントラクトを介して）配信される。一部は、データ所有者（すなわち、エンドユーザ－総支払いの％）、クレデンシャル証明者（証明可能なクレームを証明するためにクレデンシャルが使用されるたびに発行者に支払われる％）、ネットワーク保守（ネットワーク保守に使用されるネットワークにおける継続的な価値貢献または株式を表す％）、およびコンソーシアムのパートナー（すなわち、バリデータノード－ネットワークにおける初期の所有権および継続的な利害関係に従ってすべてのパートナー間で分割されている％）へ送られてもよい。
【0158】
ヘルスケアデータのための同意ベースのデータ市場が、すべての市場に影響を及ぼす可能性があることは明らかであろう。データは、産業の成長にとって最も重要なツールになりつつある。消費者データ、家族データ、ヘルスデータ、および地理空間データはすべて、任意の企業が決定および変換を行うのを助けることができる個人データの例である。データのプライバシー期待値は、クロスカットであり、収益化することができるすべてのデータに適用されるが、これは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰを利用することによって制御されている消費者によって行われなければならない。
【0159】
有益なことに、ＭｙＰＤｘなどの本発明の実施形態は、パブリックネットワークおよび他の特定の組織ネットワークと協働する許可ネットワークを提供する。本発明の実施形態は投機的トークンを利用してもよく、例えば、ビットコインなど、これは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰの動作の中心ではなく、したがって、これらは、コストの削減および速度の向上において平坦通貨のトークン化の摩擦のない利点を活用することができる。ヘルスデータのための市場を発展させ、その後機微なヘルスケアデータのセキュリティを実装するために改善することに反対して、ＭｙＰＤｘなどのＤｅＬｅＰｅＤａ－ＳＡＰは、カナダの個人情報保護および電子文書法（ＰＩＰＥＤＡ）、米国の医療保険の相互運用性および説明責任法（ＨＩＰＡＡ）、欧州の一般データ保護規則（ＧＤＰＲ）、および米国食品医薬品局規則２１条第１１章（電子記録・電子署名）などの要件に準拠している。
【0160】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、生態系内、および生態系と第三者との間の外部の両方で、価値の創出および配布の新しい方法を開き、促進することが期待される。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰを実装するソフトウェアにオープンソースモデルを利用することによって、本発明者らは、新しい革新者および研究者が容易にアクセス可能であり、より広い国内および国際ネットワークと相互運用可能なエコシステムを確立している。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰが新しい共有資産を構築するために活用されることを可能にするデータ共有の信頼に基づいて非商業モデルおよび商業モデルを確立することができる。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、これまで不可能であった方法で、研究者、臨床医、および患者が革新者と直接対話するのを促進することが予想される。ビジネスの機会および共同作業は、信頼があらゆる取引の基礎となる新しいレベルに進む。
【0161】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、４つの基礎となる概念およびそれらの関連付けられた基礎に基づいて本発明者らによって確立されており、それによってソリューション設計に影響を与え、このソリューションを従来技術のブロックチェーンソリューションから区別する。これらの概念は、以下の通りである。
・設計によるプライバシー
・ゲノミクスと健康のための世界連合（ＧＡ４ＧＨ）
・自己主権型アイデンティティ
・尊重
・設計によるプライバシー
・ゲノミクスと健康のための世界連合（ＧＡ４ＧＨ）
・自己主権型アイデンティティ
・尊重
【0162】
設計によるプライバシー（ＰｂＤ）は、規制フレームワークへの準拠によってではなく、むしろ組織のデフォルトの動作モードによって推進され、そのＩＴシステム、説明責任のあるビジネス慣行、ネットワークインフラストラクチャを視野に入れている。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、以下の７つの基本原理からなるＰｂＤフレームワークに基づいている。
・反応的ではなくプロアクティブ：予防的で改善的ではなく、後に追加するのではなく、設計時点でシステムにプライバシーを組み込むという基本的な考え方に言及する
・ＩＴシステムにおけるデフォルト設定としてのプライバシー
・プライバシーは設計に組み込まれており、プライバシーは決して既存のソリューションに後付けされるべきではないという考えを包含する
・全機能：ゼロサムではなくポジティブサム
・エンドツーエンドのセキュリティ：完全なライフサイクル保護
・可視性および透明性：オープンに保ち、データ主体に、自分の個人データがどのように収集および使用されているか、およびどのような１つまたは複数の目的のために収集および使用されているかを十分に認識させるための要件を示す
・ユーザプライバシーへの尊重
・反応的ではなくプロアクティブ：予防的で改善的ではなく、後に追加するのではなく、設計時点でシステムにプライバシーを組み込むという基本的な考え方に言及する
・ＩＴシステムにおけるデフォルト設定としてのプライバシー
・プライバシーは設計に組み込まれており、プライバシーは決して既存のソリューションに後付けされるべきではないという考えを包含する
・全機能：ゼロサムではなくポジティブサム
・エンドツーエンドのセキュリティ：完全なライフサイクル保護
・可視性および透明性：オープンに保ち、データ主体に、自分の個人データがどのように収集および使用されているか、およびどのような１つまたは複数の目的のために収集および使用されているかを十分に認識させるための要件を示す
・ユーザプライバシーへの尊重
【0163】
ゲノミクスと健康のための世界連合（ＧＡ４ＧＨ）のゲノム・ヘルス関連データの責任のある共有のためのフレームワークは、一般にオミクス研究と呼ばれるもの、すなわち、その名称が接尾辞－ｏｍｉｃｓで終わる生物学の科学および／または分野内の参加に対処している。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰをＧＡ４ＧＨフレームワークに準拠するように設計することは、以下を強調する。
・データ共有のための目的、プロセス、手順、およびガバナンスフレームワークに関する明確に定義され、アクセス可能な情報を開発することと、ゲノムおよびヘルス関連データの目的、収集、使用および交換に関する明確な情報を提供することと、データアクセスおよび／またはデータ交換の要求を公平に決定するための手順を実施することとを伴う透明性
・ソースへデータアクセスおよび／または交換のチェーンを追跡することを含む説明責任
・相互運用性および複製可能性を向上させ、長期的な検索性および完全性を維持するために、収集、使用、および転送されたデータを正確、検証可能、不偏、比例、および最新の方法で記憶および処理することを含むデータ品質およびセキュリティ
・データの収集、記憶、処理、および交換の際に機密性およびプライバシーが適切に保護されることをユーザに保証しながら、データ共有のあらゆる段階で適用されるプライバシーおよびデータ保護規制の準拠
・個人、家族、およびコミュニティとのデータ共有の害および利益のリスク利益分析
・関連するメディアまたは分野にとって有意かつ適切であり、結果に貢献したすべての者の正当なクレジットおよび承認を提供するデータ共有のための認識および帰属
・アーカイブおよび適切な識別および検索システムの使用の両方を通じて、ならびにゲノムおよびヘルス関連データを共有するために使用される機構およびシステムの重要な評価を通じて、将来の使用のために生成されるデータの持続可能性
・データ共有およびデータ管理を進め、データの品質および完全性を常に向上させるための教育訓練
・最大の利益を生み出すことができる協調的なパートナーシップおよびデータ共有を含む、アクセス可能性および普及、ならびに寄託、管理およびアクセス手順の調和、ならびにアクセス可能性を促進する手段としての使用
・データ共有のための目的、プロセス、手順、およびガバナンスフレームワークに関する明確に定義され、アクセス可能な情報を開発することと、ゲノムおよびヘルス関連データの目的、収集、使用および交換に関する明確な情報を提供することと、データアクセスおよび／またはデータ交換の要求を公平に決定するための手順を実施することとを伴う透明性
・ソースへデータアクセスおよび／または交換のチェーンを追跡することを含む説明責任
・相互運用性および複製可能性を向上させ、長期的な検索性および完全性を維持するために、収集、使用、および転送されたデータを正確、検証可能、不偏、比例、および最新の方法で記憶および処理することを含むデータ品質およびセキュリティ
・データの収集、記憶、処理、および交換の際に機密性およびプライバシーが適切に保護されることをユーザに保証しながら、データ共有のあらゆる段階で適用されるプライバシーおよびデータ保護規制の準拠
・個人、家族、およびコミュニティとのデータ共有の害および利益のリスク利益分析
・関連するメディアまたは分野にとって有意かつ適切であり、結果に貢献したすべての者の正当なクレジットおよび承認を提供するデータ共有のための認識および帰属
・アーカイブおよび適切な識別および検索システムの使用の両方を通じて、ならびにゲノムおよびヘルス関連データを共有するために使用される機構およびシステムの重要な評価を通じて、将来の使用のために生成されるデータの持続可能性
・データ共有およびデータ管理を進め、データの品質および完全性を常に向上させるための教育訓練
・最大の利益を生み出すことができる協調的なパートナーシップおよびデータ共有を含む、アクセス可能性および普及、ならびに寄託、管理およびアクセス手順の調和、ならびにアクセス可能性を促進する手段としての使用
【0164】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の分散型デジタルアイデンティティの変形である自己主権型アイデンティティ（ＳＳＩ）は、ブロックチェーン技術のアフォーダンスを活用して、デジタル世界におけるアイデンティティに対するユーザ制御を向上させる。ＳＳＩは、個人のアイデンティティおよびそれらに関連付けられたデータが、個人自身を除いていかなる権限によっても与えられず、取り消し可能でもなく、所有されていないことを意味する。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰが以下の３つの基本的な要件を満たすことを可能にする開放型システム間相互接続（ＯＳＩ）モデルスタック内の層としてＳＳＩを確立する。
・セキュリティ－アイデンティティ情報は、意図しない開示から保護されなければならない
・制御－アイデンティティ所有者は、誰が自分のデータを見てアクセスできるか、およびどのような目的のためにアクセスできるかを制御しなければならない
・可搬性－ユーザは、単一のプロバイダに結び付けられずに、自分のアイデンティティデータをいつでも使用できる必要がある
・セキュリティ－アイデンティティ情報は、意図しない開示から保護されなければならない
・制御－アイデンティティ所有者は、誰が自分のデータを見てアクセスできるか、およびどのような目的のためにアクセスできるかを制御しなければならない
・可搬性－ユーザは、単一のプロバイダに結び付けられずに、自分のアイデンティティデータをいつでも使用できる必要がある
【0165】
したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、例えば、この制御がデータ管理者、研究倫理委員会、および研究者によって保持されるのではなく、ユーザが例えばヘルス関連データのコントローラになるように、ＰｂＤおよびＧＡ４ＧＨモデルに基づいて構築するためにＳＳＩを使用する。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内に埋め込まれたＳＳＩの核は以下の通りである。
【0166】
すべての個々の人間は、自分自身のアイデンティティの元のソースである
【0167】
アイデンティティは、他者が制御するための管理メカニズムではない。
【0168】
各個人は、自身のアイデンティティの根本であり、その管理の中心である。
【0169】
図１０を参照すると、本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内のＳＳＩによって提供されるデータの制御の従来技術の軌跡および制御の軌跡が示されている。
【0170】
尊重とは、何をすべきか（例えば、個人のヘルスデータの二次的な研究使用を許可するか否か）から、何を尊重すべきか（例えば、データ、例えば医療データが関連するユーザ）または改善すべきか（例えば、すべてのエージェントを含む情報エンティティ全体によって構成される環境であるインフォスフィア、プロセス、それらの特性、および相互関係）に問題が変わるにつれて、他の生物中心の倫理的フレームとは全く異なるプライバシー問題に対処する。
【0171】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ネットワーク化されたエンドポイントデバイス、ＡＰＩ、データベースサーバ、コードライブラリなどからなる分散型システムとして動作する。このソリューションのプライバシー保護および安全なデータ交換機能が依存するコアオープンソースＨＬ Ａｒｉｅｓ／ＩｎｄｙコードおよびＨＬ Ｕｒｓａ暗号に関して、ＨＬ Ａｒｉｅｓ／Ｉｎｄｙコードベースを維持するＬｉｎｕｘ Ｆｏｕｎｄａｔｉｏｎは、定期的なセキュリティ監査を行う。しかしながら、ＭｙＰＤｘソリューションの全体的なセキュリティは、対話するすべての構成要素のセキュリティを評価および保証することに依存し、最も弱いリンクと同程度に良好であるにすぎない。しかしながら、基本的に、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ブロックチェーン内に個人データを記憶しない。ブロックチェーンのセキュリティに関するほとんどの議論は、ブロックチェーン内の取引を変更することの困難さ（例えば、初期取引ブロックチェーンブロックだけでなく、すべての後続のブロックチェーンブロックが操作を必要とする）に焦点を当てているが、データプライバシーの問題は、個人データを含む単一のブロックチェーンブロックのコンテンツさえも無許可で復号することが違反であるという点で異なる。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ブロックチェーンのみを使用してデータの転送をネゴシエート／許可することによってこの問題を回避し、一方で実際のデータ転送は、それ自体公開されていない暗号的に暗号化されたウォレットを介して実行される。
【0172】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、２４／７接続性、応答時間、最小ダウンタイムなどの問題の許容可能なサービスレベルに従って動作する検証ノードを利用する。
【0173】
ＭｙＰＤｘなどの本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、許可されたブロックチェーンとして動作する。すなわち、ソリューションを使用して活動を行うために許可が必要とされる。これは、関与するエンティティのアイデンティティの必要性を意味し、それに対して認可が付与される。組織アイデンティティと個人のアイデンティティ（例えば、ＭＹクライアント）の両方が存在する。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、組織がＭＹパートナーとしてレジストリすることを要求される場合があり、それによって、プライバシーおよびセキュリティの保守に関連するものを含む、エコシステムに参加する条項および条件に同意する。レジストリされると、パートナー組織は独自の１つまたは複数のＭｙＰＤｘウォレットを作成し、それはパートナーがクレデンシャルを発行するために使用する固定公開ＤＩＤを生成する。すべてのクレデンシャル発行者（すなわち、パートナー組織）の公開ＤＩＤは、ブロックチェーンに記憶される。
【0174】
ネットワークに参加するすべての個人は、ＭＹクライアントとしてレジストリする必要があり得る。レジストリされたＭＹクライアントは、ＭｙＰＤｘネットワークに参加することができ、参加しないこともでき、これは完全にそれらの選択である。参加することを選択した場合、ＭＹクライアントは、エコシステムに参加する条項および条件に同意した後、ＭｙＰＤｘウォレットを作成する。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰの一部として、クライアントウォレットとＭＹの運用システムとのプライバシー保護および安全な統合が行われる。
【0175】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、以下の３つの主要な構成要素を有する。
・ブロックチェーン上のデータストレージ
・クライアントウォレットに関連付けられたデータ
・アプリケーション固有データ
・ブロックチェーン上のデータストレージ
・クライアントウォレットに関連付けられたデータ
・アプリケーション固有データ
【0176】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰおよびブロックチェーン上に記憶されたデータ（例えば、発行者の公開ＤＩＤ、クレデンシャルスキーマ、クレデンシャル定義、およびクレデンシャル失効レジストリ）に関して、これらは、ブロックチェーンソリューションを動作させるノードの各々に記憶されてもよい。したがって、ここではＩｎｄｙノード上のデータストレージの詳細について説明するが、本発明の範囲から逸脱することなく、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で他の実装形態を使用してもよい。ブロックチェーンノードは、「トラストアンカー」（すなわち、ネットワークを維持するために信頼できるパートナー）として指定された参加パートナーによって運用される。参加するパートナーは、自社のノードを社内またはクラウド内に維持することを（サービスがエコシステムの条項および条件を満たす場合には、自らが選択したプロバイダによって）選択してもよい。
【0177】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のクライアントウォレット（すなわち、ペアワイズＤＩＤ、クレデンシャル）に関連するデータは、ブロックチェーン外、例えばクラウド内のＰｏｓｔｇｒｅＳＱＬデータベース内に記憶される。各クライアントは、他のすべてのクライアントのデータベースから論理的に分離された独自のデータベースを有する。任意選択的に、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のクライアントは、例えばＤｅＬｅＰｅＤａ－ＳＡＰによって定義されたものではなく、自己主権の原理に従って、それらのウォレットアプリケーションをそれらの選択したバックエンドストレージリポジトリに接続することができる。
【0178】
アプリケーション固有データ（例えば、研究投稿）は、クラウドで動作するネットワークアクセス可能データベース、例えば、ＳＱＬｉｔｅデータベース内に記憶されてもよい。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、例えばＰＩＰＥＤＡ／ＨＩＰＡＡ準拠サービスなどの準拠サービスを提供するという条件で、クラウドサービスプロバイダに依存しなくてもよい。
【0179】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、例えば、ユーザがパスワード復元／バックアップメカニズムにアクセスすることを可能にする分散型鍵管理システム（ＤＫＭＳ）とすることができる鍵およびデータバックアップ戦略を実装してもよい。
【0180】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、例えばＩＳＯ ２７０００などの１つまたは複数の業界規格に従って確立され得るクラウドベースのデータベースをバックアップするなど、クレデンシャル記憶をバックアップすることができる。
【0181】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰによってブロックチェーン上に記録されたデータは、ネットワークノード（例えば、クレデンシャルスキーマ、定義、公開ＤＩＤ）に分散されてもよく、各ノードは他のノードに対するバックアップコピーとして機能する。
【0182】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、データ受託責任の所有権および制御、すなわちデータの所有権を個々のクライアントごとに根本的に移行させる。したがって、クライアントは、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰおよび他のクレデンシャル発行者によって発行されたクレデンシャルを所有および制御する。各クレデンシャル発行者は、クレデンシャルスキーマが複数の発行者、例えば同意クレデンシャルによって使用されない限り、発行するスキーマおよびクレデンシャル定義を定義し、制御し、維持する。その場合、スキーマおよび関連するクレデンシャル定義は、エコシステムのパートナーおよび参照関連規格と協議して定義することができ、エコシステムに代わってエンティティ、例えばＭＹによって制御および維持される。
【0183】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰはまた、ブロックチェーンフレームワークの機能によって定義されるデータソース追跡を提供してもよい。例えば、ブロックチェーンファブリックは、すべてのデータのソースを暗号的に認証することができる。したがって、ユーザは、自分が保持するクレデンシャルに基づいて事実上の主張を行うことができ、これは暗号学的に真正であると証明することができる（すなわち、信頼できるソースによって発行され、完全性を有する）。暗号証明は、例えば、いくつかの明らかにされたまたはゼロ知識証明属性と、属性がクレデンシャルの発行者によってアテステーションされたことを証明する署名とを含むＪａｖａ Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔｉｆｉｃａｔｉｏｎ（ＪＳＯＮ）文書であってもよい。場合によっては、属性は証明（例えば、バイオマーカー名）から直接得られる。時として、それは断定（バイオマーカーが特定の値を有するという事実）の数学的実証として伝達される。検証は、プロバイダによって使用された計算を確認することと、適切なキーによって作成されたことを確認するために署名を確認することとからなる。
【0184】
場合によっては、本発明の一実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ヘルスデータも提供する企業に関連付けられてもよい。例えば、ＭＹは、ＭｙＰＤｘアプリケーション（本発明の一実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ）を提供するだけでなく、クライアントにデータを提供することもでき、クライアントはその後、上述および図示の例示的なプロセスを使用して転送される。そのような場合、ＭＹからクライアントへ個人データの転送は、ＭｙＰＤｘに関して説明および図示されたプロセスおよびフローを利用することができる。
【0185】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内では、ピアツーピアデータ交換を使用してデータを交換することができる。デジタル検証可能なクレデンシャルは、暗号的に信頼できる情報の一部である。送信されるデータのプライバシーおよびセキュリティを強化するために、使用されるブロックチェーンフレームワーク、例えばＨＬ Ｉｎｄｙは、ゼロ知識証明および選択的開示を使用してプライバシーを提供する機能を有することができる。このようなブロックチェーンフレームワークと、ゼロ知識証明を内蔵することで、個人情報（ＰＩＩ）を漏らすことなく、クレームの検証が可能となる。一般に、公開検証はすべてのＰＩＩデータを含み、アイデンティティを常に脆弱にする。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、データの最小化、すなわち、特定の目的を達成するために直接関連し、必要な個人情報の収集を利用する。
【0186】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰはまた、それらの個人データに関する別のクライアントの問題、すなわち、何が起こったかをどのように証明するかに対処することができる。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ＤｅＬｅＰｅＤａ－ＳＡＰ設計および実装の他の基本的な核に加えて、個人が個人のヘルスデータまたは任意の他の個人データを共有することをしばしば妨げる信頼に対するいくつかの障壁を解決するように設計された監査証跡の実装を可能にする。
【0187】
共有に対する共通の第１の障壁は、個人が、ヘルス上のリスクを理解するために使用することができる個人向けヘルスレビューを受信することから利益を得る場合であっても、個人に関する機密のヘルス情報を収集するサービスを使用することに不本意であり、個人向け行動計画を配信することによって、個人の全体的なウェルネスを改善することを可能にするために生じる。個人の不本意は、サービスが将来どのようにヘルスデータを記憶し、場合によっては使用するかについての不確実性から生じる。最近、主要なソーシャルネットワークおよび他のプラットフォームが個人の機密性の高い個人データをどのように使用するかに関して明らかになったことを考慮すると、サービスプロバイダのプライバシーポリシーが会社がこれを行わないことを明確に述べている場合であっても、ユーザは自らのデータが同意なしに第三者と共有されることを正当に恐れている。個人の信頼は損なわれており、その結果、倫理的に証明されたヘルス研究などの合法的かつ個人的または社会的に有益な目的であっても、データを共有することをますます望んでいない。個々のユーザを自分のヘルスデータの所有者にし、ユーザがデータ共有に対するきめ細かいレベルの同意を定義できるようにすることによって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、プラットフォームおよびデータ共有プロセスに対するユーザの信頼を高め、より大きな信頼をユーザに与える。ＳＳＩは、ユーザが制御しており、ユーザが制御していることを知っていることを意味する。
【0188】
ユーザはまた、通常、既に説明したように、自分のアイデンティティが自分のヘルスに関する情報にリンクされることを非常に懸念する。特に、バイオマーカーが特定のタイプの疾患を有するか、またはそのリスクがあることを示す個人は、保険事業者または雇用者によって差別されること、または社会的に孤立することを恐れ得る。これらのリスクは、ユーザの個人のヘルスデータを現実世界のアイデンティティと接続することが不可能であることを保証することを極めて重要にする。このソリューションは、分散型識別子（ＤＩＤ）の使用を通じて特定のバイオマーカーに関連付けられた現実世界のアイデンティティを保護する。すべてについて１つのアイデンティティでは、個人をそのヘルスデータと相関させることは容易である。対照的に、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、すべての関係および取引に対して異なるアイデンティティを使用する、すなわち、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ペアワイズ対話ごとに別々のＤＩＤを使用する。さらに、これらのＤＩＤは個人によって制御され、ブロックチェーンではなくウォレットに記憶される。
【0189】
信頼に対する別の障壁は、情報へのアクセスの要求がユーザから必要以上に多くの情報を要求することが多いことである。例えば、研究は、わずかなゲノムまたはバイオマーカーに関する情報しか必要としない場合であっても、個体の遺伝子配列全体または広範囲のバイオマーカーへのアクセスを要求し得る。したがって、倫理委員会の承認などを含む本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、データ共有の要求が研究プロジェクトの目的によって正当化され、特定のバイオマーカーに限定されるという観点から設計される。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、リクエスタのクレデンシャルと関連付けられたデータと一致するように、ユーザによって許可された個人データをフィルタリングしてもよい。例えば、特定の研究プロジェクトのための研究者のクレデンシャルは、彼らがどのデータを取得することを許可されているかを定義してもよく、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰはこれをウォレット内で使用してもよい。
【0190】
さらに、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、バイオマーカーの暗号化ヘルスクレデンシャルへ１対１のマッピングを提供し、それにより、研究プロジェクトが研究に必要なバイオマーカーを指定することを確実にする。この粒度レベルのヘルスデータ管理およびクレデンシャルは、ユーザが特定の研究が必要とする特定のバイオマーカーのヘルス情報を共有するだけでよいことを意味する（例えば、図８を参照）。これは、ユーザの医療記録へのアクセスがすべて包括的である従来技術とは根本的に異なる。対照的に、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、例えば、ユーザがバイオマーカーデータ、ヘルスデータまたは他の個人データの単一の項目を共有することを可能にする。
【0191】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内で、ユーザは、例えば、バイオマーカーの範囲が研究の要件に適合するか否かを判定することができる。このソリューションは、ユーザが所与の研究に必要な特定のバイオマーカー情報のみを共有するように設計されており、アイデンティティを解放することなく安全な方法で共有されたときのユーザの個人データの収益化が利用可能であるが、ユーザは、ユーザが自分の個人データの有効性を拡大および／または維持するように促進されるように、利用可能な個人データの範囲を広げるように促進されてもよい。例えば、研究は、所与の時間枠内の最後の日付を有する所定の期間にわたる個人データを必要としてもよい。このようにして、例えば、組織は、インセンティブがユーザに提供されるにつれて、特定の１つまたは複数の個人データを提供するユーザの数を増加させることができる。例えば、過去２年間に前立腺検査を検証した５０歳を超えるすべての男性は、政府に統計の増加を提供してもよい報酬を受け取る。あるいは、パンデミック中に、自分が試験されたことを検証するすべてのユーザが報酬を受け取るか、またはヘルスケア施設が、個人データの項目を提供しない個人へアクセスを制限する可能性がある（例えば、伝染性感染症の陰性検査結果）。
【0192】
従来技術の記録内には、取引が行われた、要件が満たされた、または権利もしくは請求が存在するという証拠を提供する監査証跡が提供される。監査証跡の利用可能性は、システムの動作における全体的な信頼を高め、すべての当事者が動作規則に準拠し、誠実に行動するという保証を提供する。同時に、監査証跡は、発明者が「デジタル排気」と呼ぶもの、すなわち個人に関する個人を特定可能な情報を不注意に明らかにするデータを生成してもよい。ヘルス研究の文脈では、重要な監査証跡は、ヘルスデータの共有に対するユーザの同意を取り巻く。しかしながら、同意をブロックチェーン上に記録することによって同意の監査記録を保持することは、個人が参加している研究を第三者が観察することを可能にするので、信頼に対する潜在的な障壁を導入する。個人の現実世界のアイデンティティがＤＩＤの使用によってマスクされ、データが暗号化され得るとしても、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰの設計方法は、相関、復号（例えば、量子暗号解析を介して）、または機密性の高い個人のヘルス情報を不注意に明らかにし得る他の技術のリスクを予測する。
【0193】
したがって、このリスクを回避し、ユーザに研究者との対話（およびヘルス状態）が明らかにならないというより大きな信頼を提供する一方で、同意の監査証跡がもたらす信頼を依然として支援する。したがって、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ブロックチェーン上に情報を記録する必要なしに、暗号化によって同意および関連する監査証跡の証拠を提供することができる。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰは、ブロックチェーン上の公開ＤＩＤ、データスキーマ、クレデンシャル定義、および失効レジストリのみを記録および保持することができる。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のこの設計機能は、個々のデータ所有者に、例えば、ケース１を例として考えたときの研究者に、「同意有効化」クレデンシャルを求めるクレデンシャル要求を行わせることによって達成される。したがって、ケース１を考慮すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰによって使用されるブロックチェーンフレームワークでは、個人はクレデンシャルを発行することができないため、個人ではなく研究者が同意有効化クレデンシャルを送信しなければならない。これは、クレデンシャルの発行者が、発行されたクレデンシャルに基づいて行われる検証可能なクレームの暗号証明で使用できるように、公開ＤＩＤを台帳に記憶しなければならないためである。個人のＤＩＤが、その同意に関連する請求の検証に使用するために台帳に公開して記憶された場合、これは識別の潜在的なリスクを引き起こし、プライバシー法（例えば、ＧＤＰＲ）を準拠していない可能性がある。したがって、ケース１を考慮すると、研究者は次に、ヒト可読形態であり得るＳＳＩフレームワークを用いた暗号化「同意有効化」クレデンシャルとして、研究に対する同意の条項および条件を含む同意有効化クレデンシャルを発行する。暗号化同意有効化クレデンシャルは、後で参照するために個人のウォレットに記憶される。
【0194】
本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の個人には、研究者（ケース１）が個人の同意を示す手段として証明要求を発行する前に、提供またはフロントエンドＧＵＩによって提示されるように、人間が読み取り可能な形式で条項および条件を検討する時間を与えることができる。それらが条項および条件に同意した場合、個々のデータ所有者は、研究者の証明要求に応答して、条項および条件のデジタル署名付きハッシュを含む同意の証明を返送する。本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の個人データは、同意の証拠として監査データレジストリに保持されるので、同意の証明と共に返送されないことに留意することが重要である。データが同意証明と一緒にバンドルされた場合、これは個人のヘルス情報の蓄積をもたらし、潜在的に平文になり、それによってセキュリティの脆弱性および潜在的なプライバシー法違反を引き起こす。
【0195】
同意の証明に続いて、研究者は、個々のデータ所有者から返送された情報を検証し、証明を検証する。本発明者らは、同意証明が研究者によって「監査データレジストリ」に記憶されることを予想している。その後、研究者がユーザから適切な同意を得たことを検証するために第三者が同意の証明を必要とする場合、研究者は、その真正性を証明するために常に暗号的に（再）検証することができる同意証明を提示することができる。研究者が同意証明を受信すると、個々のデータ所有者に「データ共有」クレデンシャルが提示される。個人は、オファーを受け入れ、同意証明のデジタル署名付きコピーも含むクレデンシャルを送信する。したがって、個人は、検証された証明の独自のコピーを有する。この時点で、研究者は、データ共有をトリガするために個人から証明を要求する。その後、個人は、証明における明らかな属性として、合意されたバイオマーカーデータを送信する。研究者は、証明を検証し、データを受け入れる。これにより、研究者からの「報酬」クレデンシャルの最終的なクレデンシャル提供がトリガされ、個々のクレデンシャルが要求され、研究目的でデータを共有する報酬として送信される。このようにして、個人と研究者との対話を台帳に記録することに頼らずに、暗号学的に証明可能な監査証跡が作成される。ケース１に関して上記の説明が提供されているが、そのようなプロセスフローはケース２および他のビジネスケースで採用され得ることは明らかであろう。
【0196】
監査データレジストリ
【0197】
上記のように、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内でサポートし、説明責任、監査、法的およびコンプライアンス目的のための証拠を保持する必要性をサポートしながら、証明書ベースのトークン化システムの有利なプライバシー保護および自己主権型機能を保持するために、ＳＳＩ証明書ベースのトークン化システムに新しいケイパビリティを追加する必要がある。この新しい機能は、発明者らによって「監査データレジストリ」と呼ばれている。
【0198】
本発明の実施形態による監査データレジストリは、技術的構成要素、データ構造、およびプロセスフローを含む。以下の説明の理解を容易にするために、本発明者らによって使用される用語は、ワールド・ワイド・ウェブコンソーシアム（Ｗ３Ｃ）の検証可能なクレデンシャルワーキンググループの定義に基づいている。したがって、以下の通りである。
・クレデンシャル：クレデンシャルは、発行者によって作成された請求のセットである。検証可能なクレデンシャルは、暗号的に検証することができる著作権を有する不正開封防止クレデンシャルである。
・発行者：エンティティが、１つまたは複数のサブジェクトに関するクレームを主張し、これらのクレームから検証可能なクレデンシャルを作成し、検証可能なクレデンシャルを所有者へ送信することによって実行することができる役割。
・保有者：１つまたは複数の検証可能なクレデンシャルを保有し、それらから提示を生成することによってエンティティが実行することができる役割。
・検証者：所与の主題に関する請求を検証するエンティティ。
・証明要求：１つまたは複数の発行者によって発行され、１つの所有者が保有する１つまたは複数の検証可能なクレデンシャルの要求。
・証明提示：特定の検証者と共有される、１つまたは複数の発行者によって発行された１つまたは複数の検証可能なクレデンシャルから導出されたデータ。
・証明検証：検証可能なクレデンシャルまたは検証可能な提示が、それぞれ発行者または提示者の真正かつ適時のステートメントであるか否かの評価。
・クレデンシャル：クレデンシャルは、発行者によって作成された請求のセットである。検証可能なクレデンシャルは、暗号的に検証することができる著作権を有する不正開封防止クレデンシャルである。
・発行者：エンティティが、１つまたは複数のサブジェクトに関するクレームを主張し、これらのクレームから検証可能なクレデンシャルを作成し、検証可能なクレデンシャルを所有者へ送信することによって実行することができる役割。
・保有者：１つまたは複数の検証可能なクレデンシャルを保有し、それらから提示を生成することによってエンティティが実行することができる役割。
・検証者：所与の主題に関する請求を検証するエンティティ。
・証明要求：１つまたは複数の発行者によって発行され、１つの所有者が保有する１つまたは複数の検証可能なクレデンシャルの要求。
・証明提示：特定の検証者と共有される、１つまたは複数の発行者によって発行された１つまたは複数の検証可能なクレデンシャルから導出されたデータ。
・証明検証：検証可能なクレデンシャルまたは検証可能な提示が、それぞれ発行者または提示者の真正かつ適時のステートメントであるか否かの評価。
【0199】
監査データレジストリの技術的構成要素：監査データレジストリの技術的構成要素の１つは、不正開封防止で不変の証明データのストアである。クレデンシャルが交換されるときはいつでも、対応する証明要求、証明提示、および証明検証が監査データレジストリストアへ送信される。
【0200】
監査データレジストリのデータ構造：証明要求、証明提示、および特定の検証可能なクレデンシャルに基づく証明検証の各シーケンスは、証明データのストア内の単一のレコードとして取り込まれるべきであり、そのような証明の各シーケンスのデータ構造は、証明をその基礎となるクレデンシャルにリンクバックし、証明を互いに関連付けるための特定の属性（例えば、クレデンシャル識別子および証明識別子）を含むべきである。これは、そうでなければ通信するピア間で接続されていないメッセージとして渡されることになるこれらのデータ構造間の「アーカイブ結合」と呼ばれるものを確立し、それらの真正性および完全性の記憶を可能にし、それらがアテステーションする事実の信頼できる証拠として機能することを可能にする方法で、それらをデータストア内に取り込み、必要な期間（例えば、法律、規制、または監査目的によって証拠が要求され得る期間）データストア内に記憶する。
【0201】
監査データレジストリのプロセスフロー：プロトコルに関して、本明細書で説明および提示される本発明の実施形態によれば、検証者のみが監査データレジストリと直接通信する。クレデンシャル所有者は、検証者との接続を確立し、ハンドシェイクを完了し、その後、検証者は、すべての対応する証明データを監査データレジストリへ送信する。検証者は、証明データが永続的に記憶される前に、証明データが完全かつ一貫していることを保証し、さらに、コンプライアンスを実証し、監査に応答するなどの立場になるために、そうするようにインセンティブを与えられる。
【0202】
監査データレジストリのプロトタイプ実装：本発明者らは、検証可能なヘルスクレデンシャルのコンテキストで監査データレジストリのプロトタイプを実装し、図１３の本発明の一実施形態による以下のビジネスプロセス方法表記法（ＢＰＭＮ）図にプロセスフローを提示した。
【0203】
Ａｌｉｃｅ（発行者／検証者）およびＢｏｂ（保有者）の２つのエンティティを有するシナリオを考える。例えば、Ａｌｉｃｅは、治験を行っている企業であってもよく、Ｂｏｂは、彼の検証可能なヘルスデータを共有することによって試験に参加することに関心がある個人であってもよい。しかしながら、検証可能なヘルスデータが共有される前に、治験に参加する同意が確立されなければならない。そのために、Ａｌｉｃｅは、特定のヘルスデータを共有するためのその同意が与えられたことを記録できるようにするために、その属性の１つとして特定の同意受信ＩＤを有する同意有効化クレデンシャルを生成する。同意がその特定のケースにのみ適用されることを保証するために、同意の条項および条件へハッシュリンクも含まれる。このクレデンシャルが生成されると、Ａｌｉｃｅは同意有効化クレデンシャルをＢｏｂへ送信する。その後、Ｂｏｂはクレデンシャルを受け入れる、または拒否することができる。Ｂｏｂによって受け入れられた場合、ＡｌｉｃｅはＢｏｂに同意証明要求を送信することができ、Ｂｏｂは、要求の受け入れおよび証明の提示を受けて、治験に参加するためのＢｏｂの同意をシグナリングする。
【0204】
証明要求の記録を取得するために、Ａｌｉｃｅのクライアントは要求のコピーを保持し、後で他の証明データと共に監査データレジストリの証明データストアへ送信する。
【0205】
続いて、ＡｌｉｃｅはＢｏｂに、彼の承諾された個人のヘルス情報を共有するよう求める証明要求を送信する。ボブはこれを証明でアリスに送る。証明は、クレデンシャルの発行者によるヘルスデータクレデンシャルの発行時に暗号技術を用いて生成された秘密鍵の１／３を含む。鍵の１／３は発行者によって保持され、鍵の１／３はそのウォレット内のクレデンシャルの所有者によって保持される。ＡｌｉｃｅがＢｏｂのヘルスデータを受信した時点で、Ａｌｉｃｅのクライアントはデータを受信し、暗号技術を使用して２／３の秘密鍵を照合することによって、コンプライアンス要件または緊急事態の場合に必要であれば、Ｂｏｂのアイデンティティをロック解除できるようにするために、Ｂｏｂからの証明のコピー（ＰＩＩなし）を１／３の秘密鍵と共に監査データレジストリへ送信する。このようにして、データ所有者のプライバシーを含むことなく、監査、説明責任およびコンプライアンス要件を満たすことができる。
【0206】
このようなデータは全て、同意受信ＩＤが発見可能なレコードに記憶される。プロセスフローにおける以下のステップは、証明提示および証明検証を含み、その各々はまた、それらの属性の１つとして同意受信ＩＤを含み、監査データレジストデータストアに記憶される。
【0207】
このようにして、発行された証明の履歴は、確実に、永続的に、必要な限り（例えば、法律または規制により）、不正開封防止方式で記憶される。これらの基準を満たすことは、特に、電子記録が信頼でき、法的証拠として認められることを保証するために満たす必要がある要件を規定する電子文書および署名に関する米国の規制（例えば、２１ ＣＦＲ Ｐａｒｔ １１を参照）などの規制準拠を考慮すると重要であり得る。
【0208】
図１３に示す例示的な実施形態では、捕捉され記憶された一連の証明は、所有者が元のピアツーピア接続を維持しているか否かにかかわらず、治験に参加し、ヘルス情報を交換することに同意が与えられたという信頼性のある真正な証拠を提供する。これにより、法律、監査、または説明責任の機能を有する可能性のある第三者が、監査データレジストリのデータストア（例えば、同意受信ＩＤによって）から証明データを取得することが可能になる。
・検証可能なデータ共有が要求されたインスタンスごとに、データ共有が承諾されることを確立する。
・特定のデータ共有について、使用が承認されることを確立する。
・合意された同意の条項および条件を検証する。
・当初の時刻ｔ１における同意条件がその後の時刻ｔ２において変更されていないことを確立する。
・データ所有者（データの共有者）の実際のアイデンティティが法的もしくは規制上の目的で必要である場合、またはデータ所有者（共有者）のプライバシーを含まずに緊急事態には、データ所有者（データの共有者）の実際のアイデンティティをロック解除する。
・検証可能なデータ共有が要求されたインスタンスごとに、データ共有が承諾されることを確立する。
・特定のデータ共有について、使用が承認されることを確立する。
・合意された同意の条項および条件を検証する。
・当初の時刻ｔ１における同意条件がその後の時刻ｔ２において変更されていないことを確立する。
・データ所有者（データの共有者）の実際のアイデンティティが法的もしくは規制上の目的で必要である場合、またはデータ所有者（共有者）のプライバシーを含まずに緊急事態には、データ所有者（データの共有者）の実際のアイデンティティをロック解除する。
【0209】
証明データをレジストリに記憶することにより、監査者は、不完全なデータの場合、例えば所有者によってクレデンシャルが削除された場合であっても、その有効性を検証することができる。例示的なＨｙｐｅｒｌｅｄｇｅｒ実装の場合、証明提示は、監査データレジストリなしではアクセスできない可能性がある証明要求および証明を単に取り出して再検証することによって監査者（検証者）によって検証することができる。
【0210】
図１３において、監査データレジストリは、検証者／発行者からの最終承認のみを記憶する。しかしながら、図１４を参照すると、介在する決定も監査データレジストリ内に記憶される、本発明の一実施形態による監査データレジストリのＢＰＭＮ図が示されている。したがって、所有者による発行された同意有効化クレデンシャルに関する評価されたオファーの承諾／拒否、および送信された同意証明要求の所有者による評価されたオファーのその後の承諾／拒否も、監査データレジストリ内に記憶される。図１３および図１４にそれぞれ示される例示的なプロセスの他のステップもまた、検証された提示の受け入れ／拒否などの監査データレジストリ内に記憶され得ることは明らかであろう。
【0211】
監査データレジストリの例示的な実施の有効性を評価するために、本発明者らは、同意を得てヘルスデータ共有のシミュレートされたプロセスを通して行われた実験を行った。具体的には、このプロセスの間、適格性を有し、医学的試験に参加することに同意した個人は、医学的試験のためのデータを要求している研究者から同意有効化クレデンシャルを受け取る。
【0212】
個人は、同意有効化クレデンシャルに基づいて同意証明を提示することによって同意を提供する。本発明の一実施形態による記憶されたクレデンシャルの例を図１６に示す。「ｊｔｉ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ」が特定の同意受信ＩＤを表すことは注目に値する。監査者が同意証明を監査する必要がある場合、監査者は、監査データレジストリデータベースから証明を見つけることができる。本発明の一実施形態による監査データレジストリ内に記憶されるような証明の一例であり、これはアイデンティティを介して図１７に示されており、その提示および提示要求属性を使用して証明を再検証する。再検証は、アウトラインの元のペイロードでのみ成功し、そうでない場合、署名は異なり、検証は失敗する。図１５は、この証明が再検証されたときの応答を示す。
【0213】
本発明者らによって実施される本発明の実施形態による例示的な証明レジストリはまた、特定のデータ共有について、データの特定の所有者（すなわち、法的に識別可能なクレデンシャル所有者）が、共有データの発行者、データ所有者、および受信者の間で配布される秘密鍵の分割および共有のための暗号技術の適用を通じて、プライバシー保護のＳＳＩプロトコルの動作原理に違反することなく、その使用に同意したことを証明するために必要な証拠を提供する。そのような連携は、説明責任を確立し、法的な理由で否認防止を防止するために必要であり、したがって、本発明の他の例示的な実施形態内で実施することができる。
【0214】
場合によっては、個人の特定のアイデンティティに関するデータが公開されることの明示的な許可が必要とされ得る。そのようなケースは、本発明の一実施形態による、所有者および研究者（要求者）に関するハンドシェイクのための例示的なＢＰＭＮ図を示す図３７に示されている。したがって、図３７に示す例示的なプロセスフローは、所有者によるＭＹ Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙ（ＭＹＨＩ）へ初期要求およびＭＹ Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙからの応答を組み込んだフローと、それに続く所有者と研究者（保有者のデータ、例えばバイオマーカーへのアクセスを求める）および監査データレジストリ（証明レジストリ）の両方との間の交換とを含む。
【0215】
さらに、図３８を参照すると、本発明の一実施形態による、同意に関連する監査者によるアイデンティティの取得のための例示的なＢＰＭＮ図が示されている。したがって、図３８に示す例示的なプロセスフローは、監査データレジストリ（証明レジストリ）へ監査者による初期要求およびそこからの応答、それに続くＭＹ Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙ（ＭＹＨＩ）へ監査者による通信およびそこからのアイデンティティのプロビジョニングをもたらす通信を組み込んだフローを含む。
【0216】
例示的な分散型台帳個人データプロセスフロー
【0217】
前のセクションでは、方法、概念、および関連するインフラストラクチャ、分散型台帳個人データ（ＤｅＬｅＰｅＤａ）システム、アプリケーション、およびプラットフォーム（ＤｅＬｅＰｅＤａ－ＳＡＰ）のためのレジストリについて説明し、提示した。このセクションでは、本発明の実施形態によるこれらのＤｅＬｅＰｅＤａ－ＳＡＰに関連する例示的なプロセスフローが説明および提示される。以下の説明では、「ＭｙＣＯ」、例えばＭｏｌｅｃｕｌａｒ Ｙｏｕと呼ばれる企業は、検証可能なクレデンシャルとしてヘルスデータを発行することによってデータの「ソース」として機能する。私のＣＯクライアントであるＭｙＣＯクライアントは、ヘルスクレデンシャルをモバイルウォレットに記憶している。１つの使用シナリオ内で、研究者は、「ジョブボード」を通じて参加者を募集したい研究に関する情報を公開する。研究は、研究倫理委員会（ＲＥＢ）によって「承認」される。クライアントが関心を持ち、適格性を実証することができる場合、彼らは、同意およびヘルスデータの安全な交換のために研究者と接続される。研究者らは、収集されたすべてのデータについて同意の証明を実証することができる。本発明の実施形態では、ＭｙＣＯ、ＲＥＢ、研究者、およびジョブボードは、Ｈｙｐｅｒｌｅｄｇｅｒクラウドエージェントのインスタンスを実行する。
【0218】
【0219】
ここで図２０を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰを利用する研究者プロジェクトセットアップおよび研究倫理委員会承認のための例示的なプロセスフローが示されている。したがって、以下の通りである。
・研究者は、以下を含むプロジェクト情報を投稿する。
－データ要件（バイオマーカー）
－データの使用、位置など
・承認要求がＲＥＢへ送信される。
－プロジェクト情報へのハッシュリンクを含むクレデンシャル提案
－ＲＥＢがクレデンシャルを発行する
・ジョブボードは、本プロジェクトの掲載前に「準拠証明」を要求している。
・研究者は、以下を含むプロジェクト情報を投稿する。
－データ要件（バイオマーカー）
－データの使用、位置など
・承認要求がＲＥＢへ送信される。
－プロジェクト情報へのハッシュリンクを含むクレデンシャル提案
－ＲＥＢがクレデンシャルを発行する
・ジョブボードは、本プロジェクトの掲載前に「準拠証明」を要求している。
【0220】
図２１を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のユーザ接続およびクレデンシャル受信のための例示的なプロセスフローが示されている。したがって、以下の通りである。
・クライアントは既存のウェブポータルを介してＭｙＨＩと接続する。
－ＭｙＰＤｘへ「オプトイン」を選択できる
・ＭｙＣＯがクライアントのモバイルウォレットへ接続を発行する。
－ＭｙＨＩは、接続がハイジャックされないことを保証するためにクライアントに２要素コードを送信する
・接続が確立されると、ＭｙＨＩはクライアントのウォレットにヘルスクレデンシャルを発行する。
－任意選択で、ＭｙＣＯ「アイデンティティ」クレデンシャルも発行する
・クライアントは既存のウェブポータルを介してＭｙＨＩと接続する。
－ＭｙＰＤｘへ「オプトイン」を選択できる
・ＭｙＣＯがクライアントのモバイルウォレットへ接続を発行する。
－ＭｙＨＩは、接続がハイジャックされないことを保証するためにクライアントに２要素コードを送信する
・接続が確立されると、ＭｙＨＩはクライアントのウォレットにヘルスクレデンシャルを発行する。
－任意選択で、ＭｙＣＯ「アイデンティティ」クレデンシャルも発行する
【0221】
図２２を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内のプロジェクト適格性証明のための例示的なプロセスフローが示されている。したがって、以下の通りである。
・プロジェクトの適格性は、本研究プロジェクトのデータ要件に基づく。
－バイオマーカーのタイプおよびレベル
・クライアントが０知識証明（ＺＫＰ）で応答する。
－これは、Ｈｙｐｅｒｌｅｄｇｅｒソフトウェア開発キット（ＳＤＫ）の機能に依存し得る
・ジョブボードはいかなるユーザ情報／活動も追跡しない。
－ＭｙＣＯアイデンティティ別クレデンシャルを使用してジョブボードに「ログイン」する可能性
・プロジェクトの適格性は、本研究プロジェクトのデータ要件に基づく。
－バイオマーカーのタイプおよびレベル
・クライアントが０知識証明（ＺＫＰ）で応答する。
－これは、Ｈｙｐｅｒｌｅｄｇｅｒソフトウェア開発キット（ＳＤＫ）の機能に依存し得る
・ジョブボードはいかなるユーザ情報／活動も追跡しない。
－ＭｙＣＯアイデンティティ別クレデンシャルを使用してジョブボードに「ログイン」する可能性
【0222】
図２３を参照すると、本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内の研究から同意クレデンシャルを受信するクライアントのための例示的なプロセスフローが示されている。したがって、以下の通りである。
・クライアントエージェントと研究者エージェントとの間で安全な接続が確立される。
・同意情報は、検証可能なクレデンシャルとして発行される。
－当社はこれを「同意有効化クレデンシャル」と呼ぶ
－カンタラの同意受信基準に従う
－プロジェクト情報および同意条件を調査するためのハッシュリンクを含む
・同意クレデンシャルのクライアントの受諾は、データ共有の同意を（まだ）示さない。
・クレデンシャルは、一意の識別子を含む。
・クライアントエージェントと研究者エージェントとの間で安全な接続が確立される。
・同意情報は、検証可能なクレデンシャルとして発行される。
－当社はこれを「同意有効化クレデンシャル」と呼ぶ
－カンタラの同意受信基準に従う
－プロジェクト情報および同意条件を調査するためのハッシュリンクを含む
・同意クレデンシャルのクライアントの受諾は、データ共有の同意を（まだ）示さない。
・クレデンシャルは、一意の識別子を含む。
【0223】
図２４を参照すると、本発明の実施形態による、証明有りで同意し、ＤｅＬｅＰｅＤａ－ＳＡＰ内で証明有りヘルスデータを共有するクライアントの例示的なプロセスフローが示されている。したがって、以下の通りである。
・研究者は、クライアントへ２つの証明を提供するよう依頼する。
－同意の証明
・同意有効化クレデンシャルからの属性を含む。
－ヘルスデータの証明
・同意クレデンシャルおよび要求されたヘルスデータからの「ｉｄ」を含む。
・２つの証明は、同意ＩＤによってリンクされている。
・同意条件は、ハッシュリンクされた文書に含まれる。
－この同じハッシュリンクは、このプロジェクトのために研究者に発行されたＲＥＢクレデンシャルにある。
・研究者は、クライアントへ２つの証明を提供するよう依頼する。
－同意の証明
・同意有効化クレデンシャルからの属性を含む。
－ヘルスデータの証明
・同意クレデンシャルおよび要求されたヘルスデータからの「ｉｄ」を含む。
・２つの証明は、同意ＩＤによってリンクされている。
・同意条件は、ハッシュリンクされた文書に含まれる。
－この同じハッシュリンクは、このプロジェクトのために研究者に発行されたＲＥＢクレデンシャルにある。
【0224】
図２５を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内での同意受信のための例示的なプロセスフローが示されている。したがって、以下のとおりである。
・研究者は、受信した証明書のライブラリを「監査データ台帳」に保存する。
・監査者への準拠を実証するための使用
・２つの証明が受信される（同意クレデンシャルＩＤによってリンクされる）。
－同意の証明
－共有データの証明
・監査者は、ヘルスデータへアクセスすることなく同意を検証することができる
・「証拠のチェーン」は、以下を検証することができる。
－ヘルスデータは、既知の発行者によって発行された
－同じ「所有者」からの同意およびデータの提供
－すべてのデータが同意と共有される。
－同意語は変更されていない（ハッシュリンク）
－証明は、固有の同意ＩＤによってリンクされる
・研究者は、受信した証明書のライブラリを「監査データ台帳」に保存する。
・監査者への準拠を実証するための使用
・２つの証明が受信される（同意クレデンシャルＩＤによってリンクされる）。
－同意の証明
－共有データの証明
・監査者は、ヘルスデータへアクセスすることなく同意を検証することができる
・「証拠のチェーン」は、以下を検証することができる。
－ヘルスデータは、既知の発行者によって発行された
－同じ「所有者」からの同意およびデータの提供
－すべてのデータが同意と共有される。
－同意語は変更されていない（ハッシュリンク）
－証明は、固有の同意ＩＤによってリンクされる
【0225】
図２６を参照すると、本発明の実施形態に関して説明したように、同意の受信および証明を示すソフトウェアアプリケーションの第１～第４のスクリーンショット２６００Ａ～２６００Ｄが示されている。
【0226】
本発明の実施形態では、同意を記述する情報は、研究者からクライアント（研究対象）へ検証可能なクレデンシャル（ＶＣ）として発行される。これは、例えば、固有の識別子（例えば、「ｊｔｉ＿ｕｎｉｑｕｅ＿ｉｄｅｎｔｉｆｉｅｒ」）および詳細をプロジェクト／同意するためのハッシュリンク（現在はｐｄｆ）を含むことができ、Ｋａｎｔａｒａ仕様に従うことができる。同意は、「証明」として提供される。同意および共有のヘルスデータは、同意識別子、固有の識別子（例えば、「ｊｔｉ＿ｕｎｉｑｕｅ＿ｉｄｅｎｔｉｆｉｅｒ」）によってリンクされた２つの別々の証明で提供される。重要なことに、本発明の実施形態は、個人データを明らかにすることなく、同意が監査されることを規定する。さらに、同意の失効は、クライアントによって確立され得る。
【0227】
図２７を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の例示的な対話が示されている。本明細書に記載の本発明の実施形態では、ＳＳＩ用途が使用される。したがって、クライアントは、以下と対話する。
・ＭｙＣＯヘルスクレデンシャルを発行するための既存の関係およびアイデンティティ、既存のアプリケーション（例えば、ＭｙＨＩ）
・ジョブボード－「匿名」関係、クライアントはアイデンティティ情報を明らかにすることなく研究を精査し、適格性を確認することができる
・研究者－同意を得てヘルスデータを共有する匿名の匿名データ
・ＭｙＣＯヘルスクレデンシャルを発行するための既存の関係およびアイデンティティ、既存のアプリケーション（例えば、ＭｙＨＩ）
・ジョブボード－「匿名」関係、クライアントはアイデンティティ情報を明らかにすることなく研究を精査し、適格性を確認することができる
・研究者－同意を得てヘルスデータを共有する匿名の匿名データ
【0228】
本発明の実施形態によって対処される課題の中には以下のものがある。
・モバイルおよびウェブアプリケーションを利用するソリューションを提供する有用性
・情報の「漏洩」を回避するためのセキュリティおよびプライバシー
・一般的に利用可能な技術／機能の活用
・モバイルおよびウェブアプリケーションを利用するソリューションを提供する有用性
・情報の「漏洩」を回避するためのセキュリティおよびプライバシー
・一般的に利用可能な技術／機能の活用
【0229】
本発明の実施形態のための他の考慮事項には、それだけに限らないが、以下が含まれる。
・ガバナンスフレームワーク
・ＶＣベースのワークフロー
・発明者らは、ウェブアプリケーションと組み合わされた個人向けのハイブリッドモバイルウォレット／クラウドウォレットを用いて「トリブリッド」アーキテクチャを参照している。
・ガバナンスフレームワーク
・ＶＣベースのワークフロー
・発明者らは、ウェブアプリケーションと組み合わされた個人向けのハイブリッドモバイルウォレット／クラウドウォレットを用いて「トリブリッド」アーキテクチャを参照している。
【0230】
図２８を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内でヘルスクレデンシャルを発行するための例示的なプロセスフローが示されている。したがって、ヘルスクレデンシャルを発行するためのクライアントとＭｙＣＯとの対話は、以下を利用する。
・既存のＭｙＣＯクライアントである参加者
－クライアントが実験室サンプルを提供する
－ＭｙＣＯが個人向けヘルスレポートを作成
－ＭｙＨＩは、ＭｙＣＯと対話するためのウェブベースのポータルをクライアントに提供する。
・ＭｙＣＯクライアントは、以下によってＭｙＰＤｘサービスに登録することができる。
－ＭｙＣＯとクライアントエージェントとの間の接続の確立
－２要素認証（２ＦＡ）コードを使用して、接続ＵＲＬが「ハイジャック」されないことを保証する
－「自己証明された証明」を使用して２ＦＡコードを提供するクライアント
・ＭｙＣＯは、実験室サンプルの処理に基づいて、例えばクライアントに対して約３００のヘルスクレデンシャルを発行し、以下を含む。
－バイオメトリクス
－遺伝情報
・既存のＭｙＣＯクライアントである参加者
－クライアントが実験室サンプルを提供する
－ＭｙＣＯが個人向けヘルスレポートを作成
－ＭｙＨＩは、ＭｙＣＯと対話するためのウェブベースのポータルをクライアントに提供する。
・ＭｙＣＯクライアントは、以下によってＭｙＰＤｘサービスに登録することができる。
－ＭｙＣＯとクライアントエージェントとの間の接続の確立
－２要素認証（２ＦＡ）コードを使用して、接続ＵＲＬが「ハイジャック」されないことを保証する
－「自己証明された証明」を使用して２ＦＡコードを提供するクライアント
・ＭｙＣＯは、実験室サンプルの処理に基づいて、例えばクライアントに対して約３００のヘルスクレデンシャルを発行し、以下を含む。
－バイオメトリクス
－遺伝情報
【0231】
図２９を参照すると、本発明の実施形態による、クライアントがプロジェクトを閲覧し、ＤｅＬｅＰｅＤａ－ＳＡＰ内に登録することを選択するための例示的なプロセスフローが示されている。したがって、以下の通りである。
・クライアントは、プロジェクトを閲覧し、適格性をチェックすることができる。
－０知識証明（ＺＫＰ）を介して実行される適格性チェック
－ジョブボードが適格性チェックを追跡／記録していない
－ローカルのブラウザストレージを使用して状態を記録する
・ユーザが「レジストリする」ことを決定し、研究者とデータを共有する場合：
－ジョブボードがトークンを生成し、これが研究者アプリケーションに（ウェブサービスコールを介して）送信され、クライアントにも送信される
－研究者ウェブＵＩのレジストリページにリダイレクトする
－クライアントは、レジストリページにアクセスするためにトークンを提供する
・接続およびトークンはプロジェクトごとにある。
・クライアントは、プロジェクトを閲覧し、適格性をチェックすることができる。
－０知識証明（ＺＫＰ）を介して実行される適格性チェック
－ジョブボードが適格性チェックを追跡／記録していない
－ローカルのブラウザストレージを使用して状態を記録する
・ユーザが「レジストリする」ことを決定し、研究者とデータを共有する場合：
－ジョブボードがトークンを生成し、これが研究者アプリケーションに（ウェブサービスコールを介して）送信され、クライアントにも送信される
－研究者ウェブＵＩのレジストリページにリダイレクトする
－クライアントは、レジストリページにアクセスするためにトークンを提供する
・接続およびトークンはプロジェクトごとにある。
【0232】
図３０を参照すると、本発明の実施形態による、ＤｅＬｅＰｅＤａ－ＳＡＰ内で同意を得てデータを共有するためのクライアントと研究者との対話の例示的なプロセスフローが示されている。したがって、以下の通りである。
・クライアントは、以下のいくつかのステップでワークフローと対話する。
－エージェント接続を確立する
－適格性を実証する
－同意を与える（記載された本発明の実施形態内の２つのステップであるが、単一のステップまたはＮ＞２のステップであってもよく、ここでＮは正の整数である）
－ヘルスデータを共有する
・ブラウザＵＩは、以下を提供する。
－ワークフロー状態を表示し、ユーザに「次への（ｎｅｘｔ（））」ステップを許可する
－「プロジェクトごとの」トークンを使用して、ワークフローインスタンスを識別する
・クライアントエージェントＵＩは、以下を提供する。
－クレデンシャルの受信
－１つまたは複数の証明
－ユーザの情報のセキュリティを保護しながら使用可能な体験
・クライアントは、以下のいくつかのステップでワークフローと対話する。
－エージェント接続を確立する
－適格性を実証する
－同意を与える（記載された本発明の実施形態内の２つのステップであるが、単一のステップまたはＮ＞２のステップであってもよく、ここでＮは正の整数である）
－ヘルスデータを共有する
・ブラウザＵＩは、以下を提供する。
－ワークフロー状態を表示し、ユーザに「次への（ｎｅｘｔ（））」ステップを許可する
－「プロジェクトごとの」トークンを使用して、ワークフローインスタンスを識別する
・クライアントエージェントＵＩは、以下を提供する。
－クレデンシャルの受信
－１つまたは複数の証明
－ユーザの情報のセキュリティを保護しながら使用可能な体験
【0233】
上述したように、本発明の最初のプロトタイプの実施形態は、５つのステップを含む同意／データ共有ワークフローを用いてモバイルアプリケーションとウェブアプリケーションとを切り替えることをユーザに要求するソリューションをユーザに提供する。したがって、情報の漏洩をどのように回避するかのために、ソリューションがセキュリティおよびプライバシーを提供することが重要である。これを最小限に抑えるために、エージェントはウェブＵＩにステータスを送信してユーザにステータスを表示し、ユーザがそれと対話することを可能にする。
【0234】
本発明の実施形態はまた、異なるユースケース内のデータ発行者（ＭｙＣＯ）、消費者（例えば、研究者）、およびコンプライアンス検証者（例えば、ＲＥＢ）のネットワークのための適切なガバナンスフレームワークを提供することも重要である。したがって、ガバナンスフレームワークは、ネットワークに誰が参加できるか、およびどの役割で参加できるかを定義し、ネットワーク内の信頼を定義するものを決定することが重要である。ＶＣベースのワークフローの使用は、ウェブアプリケーションおよび／またはモバイルアプリケーションを利用するワークフローの構成を可能にし、一方、トリブリッドアーキテクチャは、ウェブアプリケーションと組み合わされた個人向けのハイブリッドモバイル／クラウドウォレットを利用する。
【0235】
図３１を参照すると、本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の例示的なＳＳＩアーキテクチャが示されている。したがって、ユーザは、クラウドエージェントの使用を介して認証するモバイルエージェントと直接対話し、バルクデータをクラウドエージェントに発行することを可能にし、例えば、Ｍｏｌｅｃｕｌａｒ Ｙｏｕは約３００のクレデンシャル（各クレデンシャルはヘルスデータの項目である）を公開する。多数のクレデンシャルを発行することによって、本発明の実施形態が、個人のすべてのヘルス情報にアクセスするために単一のデータベースをハッキングすることを防止することは明らかであろう。
【0236】
図３２～図３６を参照すると、以下のための本発明の実施形態によるＤｅＬｅＰｅＤａ－ＳＡＰ内の１つまたは複数のメッセージングフローを有する例示的なアーキテクチャが示されている。
・プロジェクトセットアップおよび研究倫理委員会認定
・クライアント接続およびクレデンシャル受信
・プロジェクト適格性証明
・同意クレデンシャル受信
・同意し、ヘルスデータを共有すること（両方とも証明有り）
・プロジェクトセットアップおよび研究倫理委員会認定
・クライアント接続およびクレデンシャル受信
・プロジェクト適格性証明
・同意クレデンシャル受信
・同意し、ヘルスデータを共有すること（両方とも証明有り）
【0237】
上記の説明では、実施形態の完全な理解を提供するために具体的な詳細が示されている。しかしながら、実施形態は、これらの具体的な詳細なしで実施され得ることが理解される。例えば、実施形態を不必要に詳細に不明瞭にしないために、回路をブロック図に示すことができる。他の例では、実施形態を不明瞭にすることを避けるために、周知の回路、プロセス、アルゴリズム、構造、および技術を不必要な詳細なしに示すことができる。
【0238】
上述した技術、ブロック、ステップ、および手段の実装は、様々な方法で行うことができる。例えば、これらの技法、ブロック、ステップ、および手段は、ハードウェア、ソフトウェア、またはそれらの組み合わせで実施することができる。ハードウェア実装の場合、処理ユニットは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブルロジックデバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、上述の機能を実行するように設計された他の電子ユニット、および／またはそれらの組み合わせ内に実装されてもよい。
【0239】
また、実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートはシーケンシャルプロセスとして動作を説明することができるが、動作の多くは並行してまたは同時に実行することができる。さらに、動作の順序を入れ替えてもよい。プロセスは、その動作が完了したときに終了するが、図に含まれていない追加のステップを有することができる。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応することができる。プロセスが関数に対応する場合、その終了は、呼び出し関数またはメイン関数へ関数の戻りに対応する。
【0240】
さらに、実施形態は、ハードウェア、ソフトウェア、スクリプト言語、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、および／またはそれらの任意の組み合わせによって実装されてもよい。ソフトウェア、ファームウェア、ミドルウェア、スクリプト言語および／またはマイクロコードで実装される場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、ストレージメディアなどの機械可読メディアに記憶されてもよい。コードセグメントまたは機械実行可能命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、スクリプト、クラス、または命令、データ構造および／またはプログラムステートメントの任意の組み合わせを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、および／またはメモリコンテンツを渡すおよび／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合することができる。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の適切な手段を介して渡され、転送され、または送信され得る。
【0241】
ファームウェアおよび／またはソフトウェア実装の場合、方法は、本明細書に記載された機能を実行するモジュール（例えば、手順、機能など）で実装され得る。本明細書に記載の方法を実装する際に、命令を実体的に具現化する任意の機械可読メディアを使用することができる。例えば、ソフトウェアコードは、メモリに記憶されてもよい。メモリは、プロセッサ内またはプロセッサの外部に実装されてもよく、メモリがソフトウェアコードの実行に使用される場合と比較して、後続の実行のためにソフトウェアコードを記憶する際にメモリが使用される実装において異なってもよい。本明細書で使用される場合、「メモリ」という用語は、任意のタイプの長期、短期、揮発性、不揮発性、または他のストレージメディアを指し、任意の特定のタイプのメモリまたはメモリの数、またはメモリが記憶されるメディアのタイプに限定されるものではない。
【0242】
さらに、本明細書で開示されるように、「ストレージメディア」という用語は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ＲＡＭ、コアメモリ、磁気ディスクストレージメディア、光ストレージメディア、フラッシュメモリデバイス、および／または情報を記憶するための他の機械可読メディアを含む、データを記憶するための１つまたは複数のデバイスを表すことができる。「機械可読メディア」という用語は、ポータブルまたは固定ストレージデバイス、光ストレージデバイス、無線チャネル、および／または１つまたは複数の命令および／またはデータを記憶、記憶、または搬送することができる様々な他のメディアを含むが、これらに限定されない。
【0243】
本明細書に記載の方法は、１つまたは複数の実施形態において、命令を含むコードセグメントを受け入れる１つまたは複数のプロセッサを含む機械によって実行可能である。本明細書に記載の方法のいずれかでは、命令が機械によって実行されると、機械が方法を実行する。その機械によって行われるべき動作を指定する（シーケンシャルな、またはその他の）命令セットを実行することができる任意の機械が含まれる。したがって、典型的な機械は、１つまたは複数のプロセッサを含む典型的な処理システムによって例示してもよい。各プロセッサは、ＣＰＵ、グラフィック処理ユニット、およびプログラマブルＤＳＰユニットのうちの１つまたは複数を含むことができる。処理システムは、メインＲＡＭおよび／またはスタティックＲＡＭを含むメモリサブシステム、および／またはＲＯＭをさらに含むことができる。構成要素間で通信するためにバスサブシステムが含まれてもよい。処理システムがディスプレイを必要とする場合、そのようなディスプレイは、例えば、液晶ディスプレイ（ＬＣＤ）を含むことができる。手動データ入力が必要な場合、処理システムはまた、キーボードなどの英数字入力ユニット、マウスなどのポインティング制御デバイスなどのうちの１つまたは複数などの入力装置を含む。
【0244】
メモリは、処理システムによって実行されると、本明細書に記載の方法のうちの１つまたは複数を実行するための命令を含む機械可読コードセグメント（例えば、ソフトウェアまたはソフトウェアコード）を含む。ソフトウェアは、メモリ内に完全に存在してもよく、またはコンピュータシステムによる実行中に、ＲＡＭ内および／またはプロセッサ内に完全にまたは少なくとも部分的に存在してもよい。したがって、メモリおよびプロセッサはまた、機械可読コードを備えるシステムを構成する。
【0245】
代替の実施形態では、機械は、スタンドアロンデバイスとして動作するか、または、例えば、他の機械にネットワーク接続されてもよく、ネットワーク化された配置では、機械は、サーバ－クライアントネットワーク環境におけるサーバまたはクライアント機械の容量で、またはピアツーピアもしくは分散型ネットワーク環境におけるピア機械として動作してもよい。機械は、例えば、コンピュータ、サーバ、サーバのクラスタ、コンピュータのクラスタ、ウェブアプライアンス、分散型コンピューティング環境、クラウドコンピューティング環境、またはその機械によって取られるべき動作を指定する（シーケンシャルな、またはその他の）命令セットを実行することができる任意の機械であってもよい。「機械」という用語はまた、本明細書で説明される方法のうちの任意の１つまたは複数を実行するために命令のセット（または複数のセット）を個別にまたは共同で実行する機械の任意の集合を含むと解釈され得る。
【0246】
本発明の例示的な実施形態の上記の開示は、例示および説明の目的で提示されている。網羅的であること、または本発明を開示された正確な形態に限定することは意図されていない。本明細書に記載された実施形態の多くの変形形態および修正形態は、上記の開示に照らして当業者には明らかであろう。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によってのみ定義されるべきである。
【0247】
さらに、本発明の代表的な実施形態を説明する際に、本明細書は、本発明の方法および／またはプロセスを特定の一連のステップとして提示している場合がある。しかしながら、方法またはプロセスが本明細書に記載の特定の順序のステップに依存しない限り、方法またはプロセスは記載の特定の順序のステップに限定されるべきではない。当業者が理解するように、他の一連のステップが可能であってもよい。したがって、本明細書に記載されたステップの特定の順序は、特許請求の範囲に対する限定として解釈されるべきではない。さらに、本発明の方法および／またはプロセスに関する特許請求の範囲は、記載された順序でそれらのステップを実行することに限定されるべきではなく、当業者は、シーケンスが変更されてもよく、依然として本発明の精神および範囲内にあることを容易に理解することができる。
【図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】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【国際調査報告】