特許 7367692 装置、リクエスト装置、方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-16

(45)【発行日】2023-10-24

(54)【発明の名称】装置、リクエスト装置、方法、およびプログラム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20231017BHJP

   G06F 21/30 20130101ALI20231017BHJP

   G06F 21/64 20130101ALI20231017BHJP

   G09C 1/00 20060101ALI20231017BHJP

【ＦＩ】

H04L9/32 200B

G06F21/30

G06F21/64

G09C1/00 640E

【請求項の数】 24

(21)【出願番号】P 2020552223

(86)(22)【出願日】2019-03-21

(65)【公表番号】

(43)【公表日】2021-08-12

(86)【国際出願番号】 GB2019050799

(87)【国際公開番号】W WO2019186119

(87)【国際公開日】2019-10-03

【審査請求日】2022-01-19

(31)【優先権主張番号】1805047.6

(32)【優先日】2018-03-28

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】110003339

【氏名又は名称】弁理士法人南青山国際特許事務所

(74)【代理人】

【識別番号】100104215

【弁理士】

【氏名又は名称】大森 純一

(74)【代理人】

【識別番号】100168181

【弁理士】

【氏名又は名称】中村 哲平

(74)【代理人】

【識別番号】100117330

【弁理士】

【氏名又は名称】折居 章

(74)【代理人】

【識別番号】100168745

【弁理士】

【氏名又は名称】金子 彩子

(72)【発明者】

【氏名】ホプキンス フー

(72)【発明者】

【氏名】モーア 二ジェル スチュアート

【審査官】青木 重徳

(56)【参考文献】

【文献】特開２０１７－２０７９７９（ＪＰ，Ａ）

【文献】特開２０１３－２０７５９０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１１／０１２６０１２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０３３２２８３（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０６９９１３３４（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／６４

Ｇ０６Ｆ ２１／３０

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項1】

ユーザデータへのアクセスをリクエストする組織を認証するための装置であって、
ネットワークを介して通信するように構成されたネットワークインターフェース回路と、
処理回路と、
サーバストレージと
を具備し、
前記処理回路は、
前記ネットワークインターフェース回路を介して、情報処理装置から暗号化されたユーザデータを受信し、
前記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成し、
前記暗号化されたユーザデータおよび前記固有の識別子を、公的に利用可能なデータベースのデータ構造にデータが変更不可能な方法で配置されるまたは取り込まれるように、前記公的に利用可能なデータベースに提供し、
前記復号化キーおよび前記固有の識別子を相互に関連付けて前記サーバストレージに保存し、
前記ネットワークインターフェース回路を介して、一組織から前記ユーザデータにアクセスするリクエストを受信し、
リクエスト側の組織が承認された組織であることを確証し、リクエスト側の組織が承認された組織である場合、
前記ネットワークインターフェース回路を介して、前記復号化キーをリクエスト側の組織に送信するように構成されている
装置。

【請求項2】

請求項１に記載の装置であって、
前記公的に利用可能なデータベースは、ブロックチェーンである
装置。

【請求項3】

請求項１または２に記載の装置であって、
前記ユーザデータにアクセスするためのリクエストは、公的に利用可能なデータベース内に保存された前記固有の識別子を含む
装置。

【請求項4】

請求項１～３のいずれか１項に記載の装置であって、
前記処理回路は、前記リクエスト側の組織が、組織のリストにあることを確認することによって承認された組織であることを確証するように構成されている
装置。

【請求項5】

請求項４に記載の装置であって、
ユーザデータへのアクセスは、公的に利用可能なデータベースに不変に保存される、他の組織から前記一組織への認証を用いて提供され、
前記処理回路はさらに、前記認証のインテグリティを確認するように構成される
装置。

【請求項6】

請求項５に記載の装置であって、
前記認証は、
前記他の組織を識別する、アクセス権限が付与された組織の識別子と、
アクセスをリクエストしている前記一組織、および、前記暗号化されたユーザデータを識別する前記固有の識別子を識別する、ユーザデータにアクセスする権限を受け取る組織の識別子と、
を含む
装置。

【請求項7】

請求項１～６のいずれか１項に記載の装置であって、
前記処理回路はさらに、前記ネットワークインターフェース回路を介して、前記ユーザデータに関連した使用規則を受け取るように構成されており、
前記使用規則は、前記ユーザデータの、使用基準の限度の１つ以上を定義する
装置。

【請求項8】

ユーザデータへのアクセスをリクエストするリクエスト装置であって、
ネットワークを介して請求項１～７のいずれか１項に記載の装置と通信するように構成されたネットワークインターフェース回路と、
処理回路と
を具備し、
前記処理回路は、
前記ネットワークインターフェース回路を介して、前記ユーザデータにアクセスするように、前記装置にリクエストを提供し、
前記リクエストの提供に応じて、暗号化されたユーザデータ用の復号化キーを、前記装置から受信するように構成されており、
前記リクエストは、前記復号化キーに関連付けられた固有の識別子、および、前記ユーザデータへのアクセスをリクエストしている組織の識別子を含む
リクエスト装置。

【請求項9】

請求項８に記載のリクエスト装置であって、
前記リクエストのプロビジョニングに応じて、前記処理回路は、前記装置から前記暗号化されたユーザデータを受け取るように構成されている
リクエスト装置。

【請求項10】

請求項８または９に記載のリクエスト装置であって、
前記処理回路は、前記復号化キーを用いて、前記暗号化されたユーザデータを復号するように構成されている
リクエスト装置。

【請求項11】

請求項１０に記載のリクエスト装置であって、
前記処理回路は、復号化されたユーザデータを削除するように構成されている
リクエスト装置。

【請求項12】

ネットワークを介してユーザデータへのアクセスをリクエストする組織を、サーバ装置が認証するための、前記サーバ装置が実行する方法であって、
前記ネットワークを介して、情報処理装置から暗号化されたユーザデータを受信することと、
前記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成することと、
前記暗号化されたユーザデータおよび前記固有の識別子を、公的に利用可能なデータベースのデータ構造にデータが変更不可能な方法で配置されるまたは取り込まれるように、前記公的に利用可能なデータベースに提供することと、
前記復号化キーおよび前記固有の識別子を相互に関連付けてサーバストレージに保存することと、
前記ネットワークを介して、一組織から前記ユーザデータにアクセスするリクエストを受信することと、
リクエスト側の組織が承認された組織であることを確証することと、リクエスト側の組織が承認された組織である場合、
前記ネットワークを介して、前記復号化キーをリクエスト側の組織に送信することと
を含む
方法。

【請求項13】

請求項１２に記載の方法であって、
前記公的に利用可能なデータベースは、ブロックチェーンである
方法。

【請求項14】

請求項１２または１３に記載の方法であって、
前記ユーザデータにアクセスするためのリクエストは、公的に利用可能なデータベース内に保存された前記固有の識別子を含む
方法。

【請求項15】

請求項１１～１４のいずれか１項に記載の方法であって、
前記リクエスト側の組織が、組織のリストにあることを確認することによって承認された組織であることを確証することを含む
方法。

【請求項16】

請求項１５に記載の方法であって、
ユーザデータへのアクセスは、公的に利用可能なデータベースに不変に保存される、他の組織から前記一組織への認証を用いて提供され、
前記方法は、前記認証のインテグリティを確認することを含む
方法。

【請求項17】

請求項１６に記載の方法であって、
前記認証は、
前記他の組織を識別する、アクセス権限が付与された組織の識別子と、
アクセスをリクエストしている前記一組織、および、前記暗号化されたユーザデータを識別する前記固有の識別子を識別する、ユーザデータにアクセスする権限を受け取る組織の識別子と、
を含む
方法。

【請求項18】

請求項１２～１７のいずれか１項に記載の方法であって、
前記方法は、前記ネットワークを介して、前記ユーザデータに関連した使用規則を受け取ることを含み、
前記使用規則は、前記ユーザデータの、使用基準の限度の１つ以上を定義する
方法。

【請求項19】

ネットワークを介して請求項１～７のいずれか１項に記載の装置にユーザデータへのアクセスをリクエストするリクエスト方法であって、
前記ネットワークインターフェース回路を介して、前記ユーザデータにアクセスするように、前記装置にリクエストを提供することと、
前記リクエストの提供に応じて、暗号化されたユーザデータ用の復号化キーを、前記装置から受信することと
を含み、
前記リクエストは、前記復号化キーに関連付けられた固有の識別子、および、前記ユーザデータへのアクセスをリクエストしている組織の識別子を含む
リクエスト方法。

【請求項20】

請求項１９に記載のリクエスト方法であって、
前記リクエストのプロビジョニングに応じて、前記装置から前記暗号化されたユーザデータを受け取ることを含む
リクエスト方法。

【請求項21】

請求項１９または２０に記載のリクエスト方法であって、
前記復号化キーを用いて、前記暗号化されたユーザデータを復号することを含む
リクエスト方法。

【請求項22】

請求項２１に記載のリクエスト方法であって、
復号化されたユーザデータを削除することを含む
リクエスト方法。

【請求項23】

ユーザデータへのアクセスをリクエストする組織を認証するためのプログラムであって、
ネットワークを介して通信するように構成されたサーバ装置に、
前記ネットワークを介して、情報処理装置から暗号化されたユーザデータを受信するステップと、
前記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成するステップと、
前記暗号化されたユーザデータおよび前記固有の識別子を、公的に利用可能なデータベースのデータ構造にデータが変更不可能な方法で配置されるまたは取り込まれるように、前記公的に利用可能なデータベースに提供するステップと、
前記復号化キーおよび前記固有の識別子を相互に関連付けて前記サーバ装置のサーバストレージに保存するステップと、
前記ネットワークを介して、一組織から前記ユーザデータにアクセスするリクエストを受信するステップと、
リクエスト側の組織が承認された組織であることを確証するステップと、
リクエスト側の組織が承認された組織である場合、前記ネットワークを介して、前記復号化キーをリクエスト側の組織に送信するステップ
を実行させるための
プログラム。

【請求項24】

請求項２３に記載のサーバ装置に、コンピュータからネットワークを介して、ユーザデータへのアクセスをリクエストするためのプログラムであって、
前記コンピュータに、
前記ユーザデータにアクセスするように、前記サーバ装置に、前記復号化キーに関連付けられた固有の識別子、および、前記ユーザデータへのアクセスをリクエストしている組織の識別子を含むリクエストを提供するステップと、
前記リクエストの提供に応じて、暗号化されたユーザデータ用の復号化キーを、前記サーバ装置から受信するステップ
を実行させるための
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は概して、装置、リクエスト装置、方法、およびプログラムに関する。

【背景技術】

【0002】

本明細書で提供される「背景技術」の説明は、本開示の背景を大まかに提示するためのものである。ここで指名されている発明者の研究開発は、出願時に従来技術とみなされない本開示における態様の説明と同様に、この背景セクションで説明される範囲で、本開示に対する従来技術として明示的にも黙示的にも認められない。

【0003】

顧客の個人データは慎重に扱うべきである。しかしながら、多くの場合、顧客に関連するサービスを提供するために、個人データを共有する必要がある。例えば、顧客は、テレビ番組の提案がビデオコンテンツの供給者によって提供されることを望む場合がある。しかしながら、ユーザが自分の個人データを様々なウェブサイトやサプライヤに繰り返し提供することは不便である。
従って、顧客はある組織に個人データを提供し、その組織が他の関連する組織と個人データを共有することが望ましい。個人データを共有する組織は、第3の組織と個人データを共有することがあり、第3の組織は、この場合も先と同様に個人データなどを共有することがある。

【0004】

このように多くの組織に個人データが提供されると、個人情報のセキュリティが損なわれる可能性がある。例えば、個人データは最終的に、セキュリティ手続きが顧客にとって満足のいくものではない組織と共有してしまう可能性がある。

【0005】

さらに、顧客の個人データの漏洩があった場合、または、個人データを保持する組織がハッキングされた場合、再び漏洩が起こる可能性を軽減するか、または漏洩の犯人を捕らえるための、個人データが移動した経路のトレーサビリティはほとんどない。

【0006】

本開示の目的は、これらの問題のうちの少なくとも1つに対処することである。

【発明の概要】

【0007】

本開示の実施形態によれば、ユーザデータへのアクセスをリクエストする組織を認証するための装置が提供される。この装置は、ネットワークを介して通信するように構成されたネットワークインターフェース回路と、処理回路とを具備し、上記処理回路は、上記ネットワークインターフェース回路を介して、情報処理装置から暗号化されたユーザデータを受信し、上記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成し、上記暗号化されたユーザデータおよび上記固有の識別子を、その中またはその上に不変に保存するように公的に利用可能なデータベースに提供し、上記固有の識別子に関連して上記復号化キーを保存し、上記ネットワークインターフェース回路を介して、一組織から上記ユーザデータにアクセスするリクエストを受信し、リクエスト側の組織が承認された組織であることを確証し、リクエスト側の組織が承認された組織である場合、上記ネットワークインターフェース回路を介して、上記復号化キーをリクエスト側の組織に送信するように構成されている。

【0008】

前述の段落は一般的な導入により提供されており、以下の特許請求の範囲を限定することを意図するものではない。説明される本実施形態は、さらなる利点とともに、添付の図面と併せて以下の詳細な説明を参照することによって最もよく理解されるであろう。

【図面の簡単な説明】

【0009】

本開示が、以下の添付図面に関連して考慮される場合、以下の詳細な説明を参照することによってよりよく理解されるように、本開示のより完全な理解とそれに付随する多くの利点とが、容易に得られるであろう。

【0010】

【図1】本開示の実施形態に係る情報処理装置を示す図である。

【図2】本開示の実施形態に係るサーバを示す図である。

【図3】本開示の実施形態に係る取り込み処理を説明する概略図である。

【図4】公的に利用可能なデータベース上へのデータ構造としての、ユーザデータの取り込み処理を説明する処理を示す図である。

【図5】公的に利用可能なデータベースに配置される本実施形態に係るデータ構造を示す図である。

【図6】ユーザデータにアクセスするためのメカニズムを説明する模式図である。

【図7】ユーザデータへのアクセスを説明するフローチャートである。

【図8】ユーザデータにアクセスするために他の組織から一組織に許可を与えるデータ構造を示す図である。

【図9】ユーザデータの検査を可能にする、サーバで実行される処理を説明するフローチャートである。

【図10】公開されているデータベースに存在するアクセス権限の妥当性検査を説明するプロセスを示す図である。

【図11】サーバストレージ内に保存されている2つのデータベースを示す図である。

【発明を実施するための形態】

【0011】

ここで図面を参照すると、いくつかの図を通して、同様の参照番号は、同一または対応する部分を示す。

【0012】

図1は、本開示の実施形態に係る情報処理装置を示す。なお、情報処理装置100は、ユーザがユーザに関する情報 (いわゆる「ユーザデータ」) を入力することが可能なものであれば、どのようなものであってもよい。例えば、情報処理装置100は、テレビ、ケーブルまたは衛星セットトップボックス、携帯電話、ゲーム機、タブレットコンピュータ等である。
ユーザデータは、番組選好(ユーザが視聴したい番組の種類)、テレビ上のオーディオおよび/またはビデオ設定、健康または金融情報、クレジットカード情報のような決済選好、情報処理装置100またはテレビの放送対象地域などのGPS位置のような位置情報を含むことができるが、これらに限定されない。
いくつかの実施形態では、(例えば、キーボードをタイプすることによって、グラフィカルユーザインターフェースとやりとりすることによって、または音声認識によって) ユーザデータがユーザによって明示的に入力されてもよい。または、他のアクションまたはシステムからユーザデータが暗示すなわち導出されてもよい (例えば、ユーザが、アクションフィルムを楽しむか、または特定のフットボールチームをフォローするか、または特定のインターネットサービスもしくはサービスレベルに加入するか、または広告によって積極的に影響されるか、もしくは、Wi-Fi（登録商標）または放送信号などの特定の信号のアクセシビリティ（アクセスのしやすさ）によって特定の場所に定住しているといった、視聴または選択されたコンテンツから暗示される)。

【0013】

いくつかの実施形態では、ユーザデータは、データにおいて1つ以上のカテゴリを含むことができる。例えば、データの1つのカテゴリはユーザ設定であり、他の一連のデータはバンク情報である。このカテゴリは、データに関連するセキュリティに従って定義されてもよい。例えば、高いセキュリティレベルを有する任意のデータは第1のカテゴリであり、低いセキュリティレベルを有する任意のデータは第2のカテゴリである。

【0014】

データに2つ以上のカテゴリが存在する場合、1つの組織が別のノードではなく1つのノードへのアクセスを提供されることが可能であるため、各カテゴリが異なるノードに分割されることが想定される。これにより、要求側組織は、そのセキュリティレベルに応じて、単一のノードへのアクセスを提供されることが可能になる。例えば、一組織が銀行情報ではなくユーザ設定にアクセスすることを許可される場合、その組織は、適切なノードにアクセスすることを許可される。
当然ながら、本開示はそれに限定されない。ユーザデータへのアクセスが、ユーザデータのカテゴリに関連するセキュリティレベルに基づいて決定されてもよい。例えば、ユーザデータは、ユーザデータのカテゴリおよび組織に関連するセキュリティレベルに応じて、異なるブロック・チェーン・ブランチに分割されてもよい。この分割は、組織に関連するセキュリティ承認のレベルに応じた要求に応じて実行されてもよい。

【0015】

他の実施形態では、ユーザデータに対して適切なセキュリティレベルを有するユーザデータにアクセスするように組織に指示するために、使用規則が使用される。例えば、この規則は、組織が銀行情報などにアクセスできるかどうかを定義する。

【0016】

ユーザは、ユーザインタフェース140とやりとりすることによって、ユーザデータを入力する。ユーザインタフェース140は、タッチスクリーン、マウス、キーボード、音声認識システム等である。ユーザインタフェース140は、プロセッサ110に接続されている。プロセッサ110は、情報処理装置100を制御するように構成された回路である。プロセッサ110は、プロセッサ110に各種機能を実行するように命令するコンピュータ可読コードに従って動作する。
コンピュータ可読コードはソフトウェアであってもよい。ソフトウェアは、ソリッドステートまたは磁気的または光学的に読み取り可能なデータ記憶装置である情報処理装置のストレージ120に保存される。また、情報処理装置ストレージ120は、特定のユーザに関連するユーザ名およびパスワードを定義するプロファイル情報のような他のユーザ固有情報を含んでもよい。

【0017】

さらに、プロセッサ110には、オーディオ/ビデオ(A/V)インターフェース150が接続されている。このA/Vインターフェース150により、情報処理装置100は、外部装置との間で音声および/または映像データを提供または受信したり、ディスプレイまたは他の装置に音声および/または映像データを提供したりすることができる。

【0018】

さらに、プロセッサ110には、ネットワークインターフェース130が接続されている。ネットワークインターフェース130はネットワークに接続し、ネットワークを介してデータを提供することを可能にする。ネットワークインターフェース130は、任意の適切なメカニズムを使用して、ネットワークを介して1つ以上の装置と通信することができる。例えば、ネットワークインターフェース130は、セルラネットワークまたは有線ネットワークを介して通信することができる。
ネットワークインターフェース130は、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、インターネット、または3G、4G、LTEなどのセルラ接続を介して通信することができる。実際、ネットワークインターフェース130は、機密データのための安全な（セキュアな）接続、または、データのプライバシーが重要でない安全でない接続など、ネットワークとの適切なタイプの接続を選択してもよい。

【0019】

最後に、暗号化回路160が、プロセッサ110に接続されている。暗号化回路160の目的は、ユーザデータを暗号化することであり、ユーザデータはその後ネットワークを介して送信される。データが暗号化キーを使用して暗号化される既知の暗号化技術を使用してデータが暗号化されることが想定される。後述するように、データキー(以下、data_keyとする)は、暗号化されたユーザデータを復号するキーである。
暗号化回路160は情報処理装置100に含まれるように示されているが、本開示はこれに限定されない。実際、暗号化回路160は、ユーザデータが送信される別の装置に配置されてもよい。この例では、暗号化回路160は、data_keyを使用してユーザデータを暗号化するのと同じ機能を実行することができる。

【0020】

図2は、本開示の実施形態によるサーバ200を示す。サーバ200は、サーバネットワークインターフェース230を用いて、ネットワークを介して情報処理装置100と通信することが想定される。サーバ200は、コンピュータまたはコンピュータデバイスのような任意の種類の装置とすることに留意されたい。

【0021】

サーバ200は、サーバプロセッサ210によって制御される。サーバプロセッサ210は、サーバ200を制御するように構成された回路である。サーバプロセッサ210は、各種機能を実行するようにサーバプロセッサ210に指示するコンピュータ可読コードに従って動作する。このコンピュータ可読コードはソフトウェアである。
ソフトウェアは、ソリッドステートまたは磁気的または光学的に読み取り可能なデータ記憶装置であるサーバストレージ220に保存される。サーバストレージ220は図11を参照して説明されるように、1つ以上のデータベース(すなわち異なるデータ構造または配置)を含む。

【0022】

さらに、サーバプロセッサ210には、サーバネットワークインターフェース230が接続されている。サーバネットワークインターフェース230はネットワークに接続し、ネットワークを介してデータを提供することを可能にする。サーバネットワークインターフェース230は、任意の適切なメカニズムを使用して、ネットワークを介して1つ以上の装置と通信することができる。例えば、サーバネットワークインターフェース230は、セルラネットワークまたは他の無線ネットワーク、あるいは有線ネットワークを介して通信することができる。
サーバネットワークインターフェース230は、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、インターネット、または3G、4G、LTEなどのセルラ接続を介して通信することができる。実際、サーバネットワークインターフェース230は、機密データのための安全な（セキュアな）接続、またはデータのプライバシーが重要でない安全でない接続など、ネットワークとの適切なタイプの接続を選択してもよい。

【0023】

サーバ200は、ブロックチェーンと通信してもよい。ブロックチェーンは、データが変更不可能な方法で保存される公的に利用可能なデータベースの一例である。言い換えれば、本開示の実施形態では、サーバ200は、公的に利用可能なデータベースに不変の方法でデータを提供する。この公的に利用可能なデータベースは、例えばクラウド内、エッジサーバ上、インターネット上、サーバストレージ220内、またはブロックチェーン上のどこにでも提供される。

【0024】

図3を参照すると、本開示の実施形態による取り込み処理を示す概略図が示されている。ユーザ305は、実施形態に係る情報処理装置100にユーザデータを提供する。特定の例では、ユーザは、ユーザデータをユーザインタフェース140に提供する。

【0025】

ユーザデータは情報処理装置100と直接やりとりするユーザによって提供されてもよいし、情報処理装置100が通信する他のデバイスによって提供されてもよい。これは、ネットワーク上に配置されたデバイスを含むことができ、もしくは、ユーザに関するバイオメトリック（生体認証）情報、またはGPS情報などのセンサからの他の情報を提供するウェアラブルデバイスを含むことができる。

【0026】

情報処理装置100へのユーザデータの提供は、図3において点線で示されている。

【0027】

また、ユーザデータに加えて、ユーザ305は、遵守すべき使用規則を提供してもよい。この使用規則はオプションである。例えば、使用規則は、どの組織がデータにアクセスできるか、ユーザデータにアクセスできる制限時間、もしくは、ユーザデータの一部またはすべてがどの組織に渡されるかを定義することができる。
例えば、使用規則は、2035年1月1日以降にデータへのアクセスを決して提供しない、またはISO27001に準拠する企業にのみユーザデータを提供する、または「企業C」などと決して共有しないなどの規則を含むことができる。また、これらの使用規則は、公的に利用可能なデータベースに保存されてもよい。これらの使用規則は、暗号化キー(data_key)を使用してセキュリティ保護することも、暗号化されていない形式で保存することもできる。

【0028】

情報処理装置100は、図2のサーバ200と通信する。具体的には、情報処理装置100のネットワークインターフェース130が、サーバ200のサーバネットワークインターフェース230と通信する。この通信は、任意の種類のネットワークまたはデータリンクを介して行われ、インターネット、セルラネットワーク、ポイントツーポイントまたはピアツーピアリンクなどを介した接続である。

【0029】

本実施形態では、サーバ200は、デジタル著作権管理(DRM)プロバイダによって操作される。当然ながら、サーバ200を操作するエンティティは任意である。

【0030】

後述するように、サーバ200の目的は、ユーザデータのセキュリティを維持しつつ、第三者がユーザデータにアクセスできるようにする情報のリポジトリであることである。具体的には、情報のリポジトリがサーバストレージ220に保存される。これについては後述する。

【0031】

サーバ200が情報処理装置100から関連情報を受信した後、情報処理装置100は、ブロックチェーン310のノードに配置される本実施形態によるデータ構造を作成する。図3では、データ構造が、ブロックチェーン310内のノード310A上に新しい項目として追加される。

【0032】

当然ながら、以下ではデータ構造をブロックチェーン上に配置することについて説明するが、本開示はこれに限定されるものではない。これに関しては上述した。実際、データ構造は、限定のない方法で誰もが確認できる任意のデータベース上に配置される。例えば、フィールドを定義する構造タグを有することによって、または、特定のフィールドが特定の位置または順序にあるように常に配列することによって、データ構造は、オプションの区切り文字に対してデータベースを形成するために操作可能なものとなる。
ただし、本実施形態によれば、データベース内のデータ構造は不変でなければならないことに留意されたい。つまり、ブロックチェーン(または他のデータベース)に一度書き込まれたデータ構造は、変更できない。

【0033】

図4を参照して、ブロックチェーン上のデータ構造としての、ユーザデータの取り込み処理を説明する処理400を説明する。

【0034】

処理400は、ステップ402で開始する。この場合、ユーザは、ユーザデータを情報処理装置100に入力する。

【0035】

処理400はステップ404に移行し、そこでユーザとプロセッサ110との間にセキュアなチャネルが設定される。本実施形態では、このセキュアチャネルは、ユーザインタフェース140とプロセッサ110との間で確立される。これは、Transport Layer Security(TLS)チャンネルまたは同様のものである。

【0036】

図4の説明では、情報処理装置100を発信元組織と呼ぶ。これは、情報処理装置100がサーバ200にコンタクトをとるためのID（識別）および接続パラメータを確証するアプリケーションのようなソフトウェアコードを実行してもよいことが想定されているためである。もちろん、本開示はそのように限定されない。
他の例では、発信元組織は、情報処理装置100が通信する異なる組織であってもよい。この場合、情報処理装置100は、外部の発信元組織とセキュアな接続を確証することになる。

【0037】

セキュアなチャネルが確証された後、ユーザデータは暗号化回路160を使用して暗号化される。具体的には、ユーザデータが、暗号化回路160によってデータキー(data_key)で暗号化される。これはステップ406である。

【0038】

その後、処理400は、情報処理装置100によってユーザデータが削除されるステップ408に移行する。この場合、限定するものではないが、情報処理装置100が装置100にアクセスする悪意のあるハッカーによって侵害された場合や、装置100が紛失または盗難された場合に、ユーザデータを検索できないように、ユーザデータが安全に削除されることが想定されている。

【0039】

次に、プロセスは、暗号化されたユーザデータ用のデータアイデンティティ(Data-ID)が情報処理装置100(または発信元組織)によって作成されるステップ410に移行する。このData-IDは、暗号化されたユーザデータに固有であり、例えば128ビット長である。このData-IDは、普遍的に固有(すなわち、世界中で固有)であってもよく、もしくは国または大陸などの特定の地域に対して固有であってもよい。
情報処理装置100は、任意のメカニズム(例えばhttps://www.uuidgenerator.netにおける4-UUID)を使用して固有のData-IDを生成することができるが、1つの考えられる他のメカニズムは、ユーザデータが情報処理装置100のメディアアクセス制御アドレス(MACアドレス)と共に生成される固有の時刻基準(UTR)を使用することを含む。MACアドレスは固有であり、ユーザデータが生成された時刻は情報処理装置100に対して固有であるため、このメカニズムは固有のData-IDを生成することになる。

【0040】

次いで、処理400はステップ412に移行し、そこで、ユーザデータの暗号化に使用されるデータキー、固有のData-ID、および任意の使用規則が、サーバストレージ220内に保存するためにサーバ200に送られる。データキーおよび固有のData-IDは、相互に関連付けて保存される。つまり、固有のData-IDを識別することで、データキーが確証される。また、使用規則はData-IDと関連付けて保存される。

【0041】

情報処理装置100は、サーバ200から、データキーおよび固有のData-IDが正常に保存されたことの確認を受けると、ブロックチェーン上に配置されるデータ構造を作成する。図5を参照してこれを説明する。

【0042】

その後、情報処理装置100は、情報処理装置100が紛失または盗難される場合に備えて、データキーを安全に削除するので、データキーを検索することができない。これはステップ416である。

【0043】

その後、処理400はステップ418で終了する。

【0044】

図5を参照すると、ブロックチェーン上に配置される本実施形態による例示的なデータ構造が示されている。

【0045】

本実施形態に係るデータ構造は、4つのフィールドを有する。

【0046】

Data_ID - これは、暗号化されたユーザデータに付与される固有のData-IDである。図5の実施例では、Data_IDは、4-UUID固有識別子fac0d6fb-8aec-42a8-b43d-ccf588121969である。
Org_ID - 発信元組織に関連する固有の識別子である。なお、発信元組織が情報処理装置100である場合には、Org_IDは、装置100のMACアドレスであってもよい。同図の場合、Org_IDはcom.organisation_Org-Oである。
DRM_data - DRM_dataは、暗号化されたユーザデータである(データキーを使用して暗号化される)。
Signature - これは、Data_ID、Org_ID、およびDRM_Dataフィールドに符号する発信元組織の署名である。

【0047】

情報処理装置100は、ネットワークインターフェース130を用いて、ブロックチェーン上にデータ構造を配置する。

【0048】

図6を参照すると、ユーザデータを検査(またはアクセス)するためのメカニズムを示す模式図600が示されている。説明を容易にするために、ここではユーザによって特定の使用規則が提供されていない。

【0049】

上で説明したように、多くの場合、情報にアクセスする必要がある第2の会社は、第1の会社にユーザデータにアクセスすることを許可するように求めることができる。これは、第2の会社が(アウトソースプロバイダのような)第1の会社にサービスを提供することができるからであり、したがって、ユーザデータへのアクセスを必要とする。

【0050】

図6の実施例では、ブロックチェーン310が図4に示す処理400を使用してブロックチェーン上にアップロードされた元のデータ構造310Aを示す。さらに、ブロックチェーンの各連続ノードは、ユーザデータへのアクセスを要求した各組織の詳細で更新される。また、ブロックチェーンのノードは、どの組織がデータにアクセスする許可を与えたかを識別する。
これは図6に示されており、(データ構造ノード310Aの後に続く)ノード615Aは、発信元組織が組織Aにユーザデータにアクセスする許可を与えたことを示している。次のノード615Bは、組織Aが組織Bにユーザデータにアクセスする許可を与えたことを示している。

【0051】

このノード構造は、組織Jが組織K 605にユーザデータにアクセスする許可を与えたことを最終ノード610が示すまで続く。

【0052】

図6には、大まかに言って、5つのステップがある。これらのステップについては、後の図7を参照して詳細に説明する。

【0053】

図6の最初のステップでは、組織K (Organisation_K)605が、Data_IDに関連付けられたユーザデータにアクセスするためのライセンスを要求する。このライセンスを取得するために、組織Kは、サーバ200にリクエストを送信する。このリクエストには、Data_IDおよび組織KのOrg_IDが含まれる。Data_IDは、どのユーザデータがリクエストされたかを確証するために必要であり、Org_IDは、組織Kがユーザデータにアクセスすることを認証されていることを確認するために必要である。
例えば、組織Kは、アクセスされるすべてのユーザデータが安全に削除され、そのネットワークがハッキングなどを回避するために十分に堅牢になるように、特定のデータセキュリティ要件に準拠する必要がある。

【0054】

図6の第2のステップでは、サーバ200が、組織Kから開始して発信元組織に戻るブロックチェーンを検証する。言い換えれば、他の組織へのアクセスを可能にする許可共有のブロックチェーンのインテグリティ（整合性）がチェックされる。これは図7を参照して説明する。

【0055】

ブロックチェーンが検証された後、第3のステップでは、サーバ200が、組織Kにデータキーおよび任意の使用規則を提供する。

【0056】

その後、組織KはブロックチェーンからDRM_dataを取得し、サーバ200によって提供されたデータキーを使用してDRM_dataを復号する。これは第4のステップである。最後に、第5のステップでは、DRM_Dataを正常に復号化してユーザデータを明らかにした後に、ユーザデータにアクセスした後、任意の使用規則に従って、組織Kは、ユーザデータを安全に削除する。

【0057】

図7を参照すると、プライベートデータ処理700の検査を示すフローチャートが示されている。処理700はステップ705で開始する。処理700はステップ710に移動し、ここで組織Kは、ユーザデータにアクセスするリクエストをサーバ200に送る。図6で前述したように、組織Kがユーザデータにアクセスするためのリクエストを送信すると、このリクエストには組織KのData_IDおよびOrg_IDが含まれる。Org_IDは組織KのIDを認証するためのものであるため、Org_IDのプロビジョニングはオプションである。

【0058】

処理700はステップ715に移行し、サーバ200は組織KのIDを検証する。これは、組織KのOrg_IDと組織Kの既知の認証済みIDとを比較することで実現できる。実際的な比較の場合に組織KのIDが検証される。もちろん、組織KのIDを検証するための他のメカニズムも想定される。

【0059】

さらに、ステップ715において、ブロックチェーン、具体的にはアクセスライセンスのチェーンが、サーバ200によって検証される。これは、図9及び図10を参照して説明される。

【0060】

その後、処理700はステップ720に進む。ステップ720では、組織Kの信頼性とアクセスライセンスのチェーンとが検証されると、サーバ装置200は、リクエストされたData_IDに関連付けられたデータキーを組織Kに送信する。さらに、Data_IDに関連付けられている任意の使用規則も組織Kに送信される。

【0061】

その後、処理700はステップ725に進む。ステップ725において、使用規則が組織Kを許可すると、組織Kは、サーバ装置200によって提供されるデータキーを使用して、ブロックチェーンから読み出されたDRM_dataを復号する。これにより、ユーザデータが組織Kに表示される。

【0062】

その後、処理700はステップ730に移行し、ここでサーバ200は、ブロックチェーンを更新して、組織Jが組織Kとアクセスを共有したことを示す。この更新については、図8を用いて説明する。

【0063】

その後、処理700はステップ735に移行し、ここで組織Kは、ユーザデータおよびデータキーを削除する。処理700はステップ740で終了する。

【0064】

図8を参照すると、組織Kにユーザデータへのアクセス権限を付与するデータ構造が示されている。図8のデータ構造は、ブロックチェーン内のノード610に保存されている。いくつかの実施形態では、組織Jがデータ構造を調整し、アセンブルすることができる。その後、組織Jは、ブロックチェーン上にデータ構造を配置する。
もちろん、本開示はそのように限定されるものではなく、どの組織もデータ構造をブロックチェーン上に配置することができる。非限定的な実施形態では、同じ組織がデータ構造をアセンブルし、これをブロックチェーンにアップロードすることが想定される。

【0065】

図8のデータ構造は以下を含む。
Data_ID: これは、暗号化されたユーザデータに付与される固有のData-IDである。図8の実施例では、Data_IDは4-UUID固有識別子fac0d6fb-8aec-42a8-b43d-ccf588121969である。
Transaction_ID: これはトランザクションを一意に識別する識別子である。つまり、Transaction_IDは、組織Jから組織Kに与えられた権限を一意に識別する識別子である。これは、4-UUID固有識別子であってもよい。Transaction_IDは、組織Jまたは組織Kのいずれかによって生成され、他の組織と共有されてもよい。そして、Transaction_IDは、保存用にサーバ200と共有される。もちろん、Transaction_IDは任意の適切な方法で生成されてよい。

【0066】

Granting_Ord_ID: これは、ユーザデータにアクセスする権限を付与する組織に関連付けられた固有の識別子である。図8の場合、Granting_Org_IDはcom.organisation_Org-Jである。
Receiving_Org_ID: これは、ユーザデータにアクセスする権限を受け取る組織に関連付けられた固有の識別子である。図8の場合、Receiving_Org_IDはcom.organisation_Org-Kである。
Statement: これは、指定されている権限と、その権限に起因する制限とを定義するステートメントである。組織Jと組織Kとはともに、ステートメントに示されたテキストに同意する。図8 の場合、ステートメントは「組織Jは、Data_IDで識別されるデータにアクセスする権限を組織Kに付与しており、かつ、組織Kは組織Jからの権限を受け入れている。」である。

【0067】

Signature_1: これは組織Jに一意に関連付けられた電子署名であり、データ構造の他の部分が署名された後に改ざんされたかどうかを識別できる必要がある。したがって、Signature_1 は、組織Jによって署名された{Data_ID, Transaction_ID, Granting_Org_ID, Receiving_Org_ID, Statement}の署名である。
Signature_2: これは組織Kに一意に関連付けられた電子署名であり、データ構造の他の部分が署名された後に改ざんされたかどうかを識別できる必要がある。したがって、Signature_2 は、組織Kによって署名された{Data_ID, Transaction_ID, Granting_Org_ID, Receiving_Org_ID, Statement}の署名である。

【0068】

図9は、ユーザデータの検査を可能にするサーバ200で実行される処理715を記述するフローチャートを示す。処理715は、ステップ905で開始する。処理715はステップ910に移行し、ここで、サーバ200でユーザデータへのアクセスリクエストが受信される。特に、サーバ200は、組織Kから受信したリクエストが正当であることを確認する。
言い換えると、サーバ200は、メッセージが不正な組織体ではなく、本当に組織Kからのものであることを確認する。これは、送信元メッセージのIPアドレスまたは固有のクライアント証明書などを確認するなどの公知の技術を使用して実現される。

【0069】

リクエストが組織Kによって行われたことが確証されると、サーバ200は、ストレージ220内に保存された、リアルタイムで承認された組織データベースを確認する。上述したように、ストレージ220は、非一時的な記憶媒体として具現化される。これはステップ915で実行される。
承認された組織データベースは、ユーザデータに関する適切なセキュリティプロビジョニングを満たした組織のIDを保存する。例えば、承認された組織データベースに保存された組織は、ユーザデータを処理するための適所に、承認されたプロセスを有することができ、ISO27001等のような特定のセキュリティ認定を示すことができる。

【0070】

何らかの理由で、組織が、ISO27001の認定を失うことなどによって、承認されていない組織になった場合、組織は、承認された組織データベースから削除されるか、または、組織が現在承認されていないことを示す、承認された組織データベースへの登録に関連して保存されるフラグを有する。
実際、いくつかの例では例えば、メッセージの確認が固有のクライアント証明書を使用する場合、クライアント証明書は、組織が承認されていない組織になったときに取り消されたものとして識別されてもよい。

【0071】

リアルタイムで承認される組織データベースを提供することによって、セキュリティ要件に準拠しない組織は、もはやユーザデータにアクセスすることができなくなる。

【0072】

組織Kが承認された組織リストにある場合、処理715はステップ920に移行する。ステップ920において、ブロックチェーン内のアクセス権限が検証される。このプロセスは図10で説明される。アクセス権限が検証されると、プロセスはステップ925で終了し、そこで、リクエストされたData_IDに関連付けられたデータキーと、Data_IDに関連付けられた任意の使用規則が、組織Kに送信される。

【0073】

図10を参照すると、ブロックチェーン上に位置するアクセス権限の検証を記述する処理1000が示されている。プロセス1000は、ステップ1002で開始する。プロセスはステップ1005に移行し、そこでブロックチェーンが問い合わせられ、フィールドReceiving_Org_IDが組織Jの固有識別子を有するすべてのノードを識別する。言い換えると、サーバ200は、ブロックチェーン内のノードに問い合わせて、フィールドReceiving_Org_IDがcom.organisation_Org-Jであるノードを識別する。

【0074】

処理1000はステップ1010に移動し、そこでこれらの識別された各ノードのData_IDが、レビューされる。具体的には、組織KによってリクエストされたData_IDフィールドに一致するノードが識別される。

【0075】

次に、プロセスはステップ1015に進む。ステップ1015において、Granting_Org_IDフィールド内の組織のIDが確証される。この場合、ブロックチェーンが有効であるためには、Granting_Org_IDフィールドの組織のIDは組織Iでなければならない。言い換えれば、Granting_Org_IDは、com.organisation_Org-Iであるべきである。

【0076】

次に、処理1000はステップ1020に移行し、そこで、ノードに保存されている署名(Signature 1およびSignature 2)が、Receiving_Org_IDおよびGranting_Org_IDフィールドで言及されているそれぞれの組織に対応する検証済み署名と比較される。言い換えれば、ノードに保存された各組織の署名は、各組織の真正の署名と比較される。これにより、ノードに保存されている2つの組織間の合意が検証される。

【0077】

組織Iと組織Jとの間のアクセス権限が検証されたので、組織Hと組織Iとの間のアクセス権限を検証する必要がある。

【0078】

これを行うために、プロセスはステップ1025に移動し、そこでブロックチェーンが問い合わせられ、フィールドReceiving_Org_IDが組織Iの固有識別子を有するすべてのノードを識別する。言い換えると、サーバ200は、ブロックチェーン内のノードに問い合わせて、フィールドReceiving_Org_IDがcom.organisation_Org-Iであるノードを識別する。

【0079】

処理1000はステップ1030に移動し、そこでこれらの識別された各ノードのData_IDが、レビューされる。具体的には、組織HによってリクエストされたData_IDフィールドに一致するノードが識別される。

【0080】

次に、プロセスはステップ1035に進む。ステップ1035において、Granting_Org_IDフィールド内の組織のIDが確証される。この場合、ブロックチェーンが有効であるためには、Granting_Org_IDフィールドの組織のIDは組織Hでなければならない。言い換えれば、Granting_Org_IDはcom.organisation_Org-Hであるべきである。

【0081】

その後、処理1000は上記のように続行され、ノードに保存されている署名(Signature 1およびSignature 2)が、Receiving_Org_IDおよびGranting_Org_IDフィールドで記載されているそれぞれの組織に対応する検証済み署名と比較される。言い換えれば、ノードに保存された各組織の署名は、各組織の真正の署名と比較される。これにより、ノードに保存されている2つの組織間の合意が検証される。

【0082】

処理1000は、アクセス権限のブロックチェーンの有効性を保証するために、各アクセス権限の検証を継続する。

【0083】

アクセス権限のブロックチェーンが引き続き有効であると仮定すると、処理1000はステップ1040に到達する。ステップ1040において、ブロックチェーンは、フィールドReceiving_Org_IDが組織Aの固有識別子を有するすべてのノードを識別するために問い合わせられる。言い換えると、サーバ200は、ブロックチェーン内のノードに問い合わせて、フィールドReceiving_Org_IDがcom.organisation_Org-Aであるノードを識別する。

【0084】

プロセスはステップ1045に移動し、そこでこれらの識別された各ノードのData_IDが、レビューされる。具体的には、組織KによってリクエストされたData_IDフィールドに一致するノードが識別される。

【0085】

次に、プロセスはステップ1050に進む。ステップ1050において、Granting_Org_IDフィールド内の組織のIDが確証される。この場合、ブロックチェーンが有効であるためには、Granting_Org_IDフィールド内の組織のIDは発信元組織でなければならない。言い換えれば、Granting_Org_IDはcom.organisation_Org-Originであるべきである。

【0086】

図示されていないが、ノードに保存されている署名(Signature 1およびSignature 2)が、Receiving_Org_IDおよびGranting_Org_IDフィールドで言及されているそれぞれの組織に対応する検証済み署名と比較される。言い換えれば、ノードに保存された各組織の署名は、各組織の真正の署名と比較される。これにより、ノードに保存されている2つの組織間の合意が検証される。

【0087】

処理1000が発信元組織と組織Aとの間の合意を検証した後に、ブロックチェーンのアクセス権限が検証され、組織Kに、Data_IDと関連付けて保存されたdata_keyが提供される。

【0088】

図11は、サーバストレージ220内に保存された2つのデータベースを示す。第１のデータベース1100Aでは、Data_ID 1110Aは、対応するdata_key 1120Aと関連付けて保存される。言い換えれば、データベース1100Aは、各Data_IDに対して保存された復号化キーを有する。
したがって、一組織が特定のData_ID項目の復号化キーをリクエストすると、サーバ200はこれを提供することができる。本実施形態におけるデータベース1100Aは、第三者がデータベース1100Aにアクセスするおそれを低減するために暗号化される。

【0089】

第2のデータベース1100Bでは、組織1110Bが、その組織がdata_keyを受信することを認証されているかどうかを示すフラグ1120Bに関連して保存される。上述のように、ISO27001の認証を維持するような継続的なデータセキュリティ要件を満たさない場合、その組織は、権限が削除される。

【0090】

さらに、組織に関連して保存されているのは、組織に関連する真の署名であることが検証された署名である。これにより、アクセス権限の署名を検証することができる。

【0091】

上記では受信したユーザデータを暗号化するために使用されるデータキーに関連付けられている固有の識別子について説明したが、本開示はこれに限定されない。例えば、データキーは、その後ユーザデータを再暗号化するデバイスによって生成されてもよい。
したがって、必要なのは、ユーザデータが暗号化され、その暗号化されたユーザデータ用の復号化キーに関連付けられた固有の識別子があることのみである。

【0092】

当然ながら、上記の教示に照らして、本開示の多数の修正および変形が可能である。したがって、添付の特許請求の範囲内で、本開示は、本明細書で具体的に説明される以外の方法で実施されてもよいことが理解される。
本開示の実施形態が少なくとも部分的に、ソフトウェア制御されたデータ処理装置によって実装されるものとして説明されている限り、光ディスク、磁気ディスク、半導体メモリなど、そのようなソフトウェアを搬送する非一時的な機械可読媒体も、本開示の実施形態を表すと考えられることが理解される。

【0093】

本発明を明確にするための上記の説明は、異なる機能ユニット、回路、および/またはプロセッサを参照して実施形態を説明したことが理解される。しかしながら、本発明の実施形態から逸脱することなく、異なる機能ユニット、回路、および/またはプロセッサ間の機能における任意の適切な分散が使用されることは明らかである。

【0094】

本明細書で説明された実施形態は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の適切な形態で実装される。本明細書で説明された実施形態は、任意選択で、1つ以上のデータプロセッサおよび/またはデジタル信号プロセッサ上で実行されるコンピュータソフトウェアとして、少なくとも部分的に実装される。任意の実施形態における部品および構成要件が、任意の適切な方法で物理的に、機能的に、および論理的に実装される。
実際、この機能は、単一のユニットで、複数のユニットで、または他の機能ユニットの一部として実装されてもよい。したがって、本開示の実施形態は、単一のユニットで実装されてもよく、または、異なるユニット、回路、および/またはプロセッサの間で物理的および機能的に分散されてもよい。

【0095】

本開示は、いくつかの実施形態に関連して説明されたが、本明細書に記載された特定の形態に限定されることは意図されていない。さらに、特徴は特定の実施形態に関連して説明されているように見えるが、当業者は、説明された実施形態の種々の特徴が本技法を実施するのに適した任意の方法で組み合わされ得ることを認識するであろう。

【0096】

本開示の種々の実施形態は、以下の番号付けされた節によって定義される。

（１）ユーザデータへのアクセスをリクエストする組織を認証するための装置であって、
ネットワークを介して通信するように構成されたネットワークインターフェース回路と、
処理回路と
を具備し、
前記処理回路は、
前記ネットワークインターフェース回路を介して、情報処理装置から暗号化されたユーザデータを受信し、
前記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成し、
前記暗号化されたユーザデータおよび前記固有の識別子を、その中またはその上に不変に保存するように公的に利用可能なデータベースに提供し、
前記固有の識別子に関連して前記復号化キーを保存し、
前記ネットワークインターフェース回路を介して、一組織から前記ユーザデータにアクセスするリクエストを受信し、
リクエスト側の組織が承認された組織であることを確証し、リクエスト側の組織が承認された組織である場合、
前記ネットワークインターフェース回路を介して、前記復号化キーをリクエスト側の組織に送信するように構成されている
装置。
（２）（１）に記載の装置であって、
前記公的に利用可能なデータベースは、ブロックチェーンである
装置。
（３）（１）または（２）に記載の装置であって、
前記ユーザデータにアクセスするためのリクエストは、公的に利用可能なデータベース内に保存された前記固有の識別子を含む
装置。
（４）（１）～（３）のいずれか１つに記載の装置であって、
前記処理回路は、前記リクエスト側の組織が、組織のリストにあることを確認することによって承認された組織であることを確証するように構成されている
装置。
（５）（４）に記載の装置であって、
ユーザデータへのアクセスは、公的に利用可能なデータベースに不変に保存される、他の組織から前記一組織への認証を用いて提供され、
前記処理回路はさらに、前記認証のインテグリティを確認するように構成される
装置。
（６）（５）に記載の装置であって、
前記認証は、
前記他の組織を識別する、アクセス権限が付与された組織の識別子と、
アクセスをリクエストしている前記一組織、および、前記暗号化されたユーザデータを識別する前記固有の識別子を識別する、ユーザデータにアクセスする権限を受け取る組織の識別子と、
を含む
装置。
（７）（１）～（６）のいずれか１つに記載の装置であって、
前記処理回路はさらに、前記ネットワークインターフェース回路を介して、前記ユーザデータに関連した使用規則を受け取るように構成されており、
前記使用規則は、前記ユーザデータの、使用基準の限度の１つ以上を定義する
装置。
（８）
ユーザデータへのアクセスをリクエストするリクエスト装置であって、
ネットワークを介して（１）～（７）のいずれか１つに記載の装置と通信するように構成されたネットワークインターフェース回路と、
処理回路と
を具備し、
前記処理回路は、
前記ネットワークインターフェース回路を介して、前記ユーザデータにアクセスするように、前記装置にリクエストを提供し、
前記リクエストの提供に応じて、暗号化されたユーザデータ用の復号化キーを、前記装置から受信するように構成されており、
前記リクエストは、前記ユーザデータへのアクセスをリクエストしている組織に関連した前記ユーザデータおよびIDに関連した固有の識別子を含む
リクエスト装置。
（９）（８）に記載のリクエスト装置であって、
前記リクエストのプロビジョニングに応じて、前記処理回路は、前記装置から前記暗号化されたユーザデータを受け取るように構成されている
リクエスト装置。
（１０）（８）または（９）に記載のリクエスト装置であって、
前記処理回路は、前記復号化キーを用いて、前記暗号化されたユーザデータを復号するように構成されている
リクエスト装置。
（１１）（１０）に記載のリクエスト装置であって、
前記処理回路は、復号化されたユーザデータを削除するように構成されている
リクエスト装置。
（１２）
ネットワークを介してユーザデータへのアクセスをリクエストする組織を認証するための方法であって、
前記ネットワークを介して、情報処理装置から暗号化されたユーザデータを受信することと、
前記暗号化されたユーザデータを復号するために使用される復号化キーに関連する固有の識別子を生成することと、
前記暗号化されたユーザデータおよび前記固有の識別子を、その中またはその上に不変に保存するように公的に利用可能なデータベースに提供することと、
前記固有の識別子に関連して前記復号化キーを保存することと、
前記ネットワークを介して、一組織から前記ユーザデータにアクセスするリクエストを受信することと、
リクエスト側の組織が承認された組織であることを確証することと、リクエスト側の組織が承認された組織である場合、
前記ネットワークを介して、前記復号化キーをリクエスト側の組織に送信することと
を含む
方法。
（１３）（１２）に記載の方法であって、
前記公的に利用可能なデータベースは、ブロックチェーンである
方法。
（１４）（１２）または（１３）に記載の方法であって、
前記ユーザデータにアクセスするためのリクエストは、公的に利用可能なデータベース内に保存された前記固有の識別子を含む
方法。
（１５）（１１）～（１４）のいずれか１つに記載の方法であって、
前記リクエスト側の組織が、組織のリストにあることを確認することによって承認された組織であることを確証することを含む
方法。
（１６）（１５）に記載の方法であって、
ユーザデータへのアクセスは、公的に利用可能なデータベースに不変に保存される、他の組織から前記一組織への認証を用いて提供され、
前記方法は、前記認証のインテグリティを確認することを含む
方法。
（１７）（１６）に記載の方法であって、
前記認証は、
前記他の組織を識別する、アクセス権限が付与された組織の識別子と、
アクセスをリクエストしている前記一組織、および、前記暗号化されたユーザデータを識別する前記固有の識別子を識別する、ユーザデータにアクセスする権限を受け取る組織の識別子と、
を含む
方法。
（１８）（１１）～（１７）のいずれか１つに記載の方法であって、
前記方法は、前記ネットワークを介して、前記ユーザデータに関連した使用規則を受け取ることを含み、
前記使用規則は、前記ユーザデータの、使用基準の限度の１つ以上を定義する
方法。
（１９）
ネットワークを介して（１）～（７）のいずれか１つに記載の装置にユーザデータへのアクセスをリクエストするリクエスト方法であって、
前記ネットワークインターフェース回路を介して、前記ユーザデータにアクセスするように、前記装置にリクエストを提供することと、
前記リクエストの提供に応じて、暗号化されたユーザデータ用の復号化キーを、前記装置から受信することと
を含み、
前記リクエストは、前記ユーザデータへのアクセスをリクエストしている組織に関連した前記ユーザデータおよびIDに関連した固有の識別子を含む
リクエスト方法。
（２０）（１９）に記載のリクエスト方法であって、
前記リクエストのプロビジョニングに応じて、前記方法は、前記装置から前記暗号化されたユーザデータを受け取ることを含む
リクエスト方法。
（２１）（１９）または（２０）に記載のリクエスト方法であって、
前記復号化キーを用いて、前記暗号化されたユーザデータを復号することを含む
リクエスト方法。
（２２）（２１）に記載のリクエスト方法であって、
復号化されたユーザデータを削除することを含む
リクエスト方法。
（２３）
コンピュータに読み込まれると、（１２）～（２２）のいずれか１つに記載の方法を実行するように前記コンピュータを構成する、コンピュータ読み取り可能な指示を含む
コンピュータプログラム製品。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】