(57)【要約】【課題】利用者側の利便性および個人情報の保護を向上させ、ベンダ側の情報漏洩のリスクを低減する。【解決手段】個人情報管理システムは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノード６１と、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部６２と、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う対象確認部６３と、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する記録登録部６４とを備える。【選択図】図２１
2019219780.tif 000002
【特許請求の範囲】
【請求項１】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、
前記ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、
前記利用者から開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う対象確認部と、
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する記録登録部とを備える
ことを特徴とする個人情報管理システム。
【請求項２】
前記登録部は、前記第１ブロックに含まれる情報の作成者または前記利用者本人もしくは前記対象確認情報の正当性を確認した機関の少なくともいずれかの署名が付された第１ブロックを登録する
請求項１に記載の個人情報管理システム。
【請求項３】
前記対象確認部は、
開示された前記対象確認情報の正当性を、前記ブロックチェーン内にある前記利用者の第１ブロックに付された署名に基づく前記第１ブロック内の前記対象確認情報のハッシュ値の信頼性の確認結果と、前記第１ブロック内の前記対象確認情報のハッシュ値と開示された前記対象確認情報から算出されたハッシュ値との一致性の確認結果とに基づいて検証する正当性検証部を含む
請求項２に記載の個人情報管理システム。
【請求項４】
前記対象確認部は、前記利用者に前記対象確認情報の開示を要求した結果、前記対象確認情報に代えて前記利用者から前記第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される前記第２ブロック内の前記対象確認の記録を参照して前記対象確認を行う
請求項１から請求項３のうちのいずれかに記載の個人情報管理システム。
【請求項５】
前記記録登録部は、前記第２ブロックに含まれる情報の作成者または前記対象確認を行った機関の署名が付された第２ブロックを登録し、
前記対象確認部は、開示された情報から特定される前記第２ブロックに付された署名に基づく前記第２ブロック内の前記対象確認の記録の信頼性を少なくとも確認した上で、前記対象確認の記録を参照して前記対象確認を行う
請求項１から請求項４のうちのいずれかに記載の個人情報管理システム。
【請求項６】
前記登録部によって前記第１ブロックにそのハッシュ値が登録された前記対象確認情報を少なくとも保持する利用者側データ保持部と、
前記対象確認部から前記対象確認情報の開示要求を受け付けると、前記利用者に許可を得た上で、前記利用者側データ保持部に保持されている前記対象確認情報を開示する開示部とを備え、
前記登録部は、前記ブロックチェーンに、前記利用者に割り当てられた識別子またはそのハッシュ値と、前記利用者から開示された個人情報であって前記対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックを登録し、
前記第１ブロックが２以上の対象確認情報のハッシュ値を含むか、前記ブロックチェーンに、前記利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されており、
前記開示部は、前記利用者に許可を得た上で、前記対象確認部から指定された前記対象確認情報のみを開示する
請求項１から請求項５のいずれかに記載の個人情報管理システム。
【請求項７】
利用者が使用する個人用端末と、利用者に所定のサービスを提供するサービス提供装置と、前記サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置と、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードとを備え、
前記個人用端末は、
前記ブロックチェーンに、前記利用者の識別子と、前記利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、前記利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録する登録部を含み、
前記サービス提供装置は、
要求元の利用者に対して本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認を行った上で前記利用者に前記所定のサービスを提供するサービス提供部と、
前記利用者に第２の対象確認情報の開示を要求して、得られた情報を基に前記対象確認を行う第１の対象確認部と、
前記ブロックチェーンに、前記利用者の識別子と、前記対象確認の記録もしくは前記所定のサービスの提供の記録とを含む第２ブロックを登録する記録登録部とを含み、
前記許可証判定装置は、
前記利用者から入場または前記許可証により得られる利益の受領の申請を受け付けると、前記利用者に、前記第２ブロックを特定可能な情報と、前記第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行う第２の対象確認部と、
前記第２の対象確認部による前記対象確認の結果に基づいて、前記利用者の申請の可否を判定する判定部とを含む
ことを特徴とするサービス提供システム。
【請求項８】
前記サービスが、チケットサービス、施設管理サービス、投票サービスまたは定期券運賃管理サービスのいずれかである
請求項７のいずれかに記載のサービス提供システム。
【請求項９】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを少なくとも登録しておき、
前記利用者からサービスを要求されると、前記利用者に前記対象確認情報の開示を要求し、開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行い、
前記対象確認の結果に基づいて、前記利用者にサービスを提供するとともに、前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する
ことを特徴とするサービス提供方法。
【請求項１０】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンであって、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックが少なくとも登録されたブロックチェーンから少なくとも前記第１ブロックの情報を取得可能なコンピュータに、
前記利用者からサービスを要求されると、前記利用者に前記対象確認情報の開示を要求し、開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う処理、
前記対象確認の結果に基づいて、前記利用者にサービスを提供する処理、および
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する処理
を実行させるためのサービス提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、個人情報を管理する個人情報管理システム、それを利用してサービスを提供するサービス提供システム、サービス提供方法およびサービス提供プログラムに関する。
【背景技術】
【０００２】
サービス提供の場において、サービスの提供を行う側（以下、ベンダという）が、要求元ユーザがユーザ本人かどうかを確認した上で、サービスの提供を行うことがある。例えば、ベンダは、要求元ユーザに個人情報の開示を要求し、開示された個人情報を基にそのユーザがユーザ本人であるか否かを確認する。一般に、ある人物がその人物本人であることを確認することを、「本人確認（personal identification）」や「身元確認（identity verification）と呼ぶ。本人確認に用いられる個人情報としては、例えば、免許証（より具体的には、それに含まれる情報集合。以下同様）、保険証（より具体的には、それに含まれる情報集合。以下同様）、パスポート（より具体的にはそれに含まれる情報集合。以下同様）、クレジットカード（より具体的にはそれに含まれる情報集合。以下同様）、生体情報、マイナンバーなどが挙げられる。なお、場合によっては、ＩＤとパスワードの組といった所定の２以上の情報の組み合わせも、そのような個人情報に含まれる。
【０００３】
また、例えば、ベンダは、要求元ユーザが当該ベンダにおける正規のユーザであることを確認するために、要求元ユーザにユーザ識別情報と認証情報とを要求し、得られた情報と予め登録されている情報とを照合することにより、そのユーザが当該ベンダにおける正規のユーザであるか否かを確認する。あるシステムに対して特定のユーザであると申告した者がその特定のユーザすなわち正規の一ユーザであることを確認することを、「ユーザ認証（User authentication）」と呼ぶ。ここで、正規のユーザであることを確認するとは、より具体的には、あるシステムに対して特定のユーザであると申告した申告者がそのシステムにおいてその特定のユーザと同一人物またはそれと同等とみなせる資格を有することを確認することである。本人確認は、申告者が申告者本人であることまで確認するのに対して、ユーザ認証は、申告者が予め登録されているユーザと同一とみなせることを確認するのに留まる点で、確認結果に対して要求されるレベルが異なるが、ユーザ認証は個々のシステム内における本人確認の一種とみなすこともできる。
【０００４】
また、個人情報を利用する他のケースとしては、あるサービスの提供を要求した要求者がそのサービスの受給資格を有していることを確認する「適格性確認（eligibility verification）」などが挙げられる。ここで、サービスには、有料／無料を問わない物品や役務の提供など、あらゆるサービスが含まれる。
【０００５】
以下では、個人情報を利用してサービスの要求者に対して、本人確認、ユーザ認証および適格性確認の少なくともいずれかを行うことを、対象確認（target verification）と呼ぶ。換言すると、対象確認を、本人確認、ユーザ認証および適格性確認を含む概念として定義する。
【０００６】
このような個人情報を利用した対象確認技術に関し、例えば、特許文献１には、自販機等の商品提供装置で撮影された顔画像を用いて管理装置がユーザ認証を行うことで、ユーザの手間をかけずに商品を提供できる商品提供システムが記載されている。
【０００７】
また、特許文献２には、ＩＣカードとそのリーダといった専用カードおよび専用装置を使用することなく、また個人が設定する任意のＩＤを使用せずに、個人を特定できる本人認証システムが記載されている。特許文献２に記載の本人認証システムは、予め認証サーバにおいてユーザを識別する情報としての端末ＩＤと、認証用の情報（生体情報と位置情報の組など）とを対応づけて保持しておくとともに、情報サーバにおいて端末ＩＤとユーザの個人情報とを対応づけて保持しておく。その上で、端末ＩＤを保持している端末装置が、自身が取得した照合用の情報（生体情報と位置情報）とともにユーザの個人情報を要求するコマンドをリーダー・ライタを介して情報サーバに送信する。情報サーバは、受信したコマンドを解析し、端末装置から受信した照合用の情報と認証サーバに記憶されている認証用の情報とを比較してユーザ認証を行った上で、受信したユーザの個人情報を端末装置に送信する。
【０００８】
また、非特許文献１には、ブロックチェーンを利用して本人確認を行うシステムの１つとして、ShoCard社によって提供されている個人情報管理システム（Identity Management Sysmtem：IMS）による個人認証サービスである“ShoBadge”が紹介されている。また、ShoCard社は、個人認証サービス用アプリケーションである“ShoCard”も個人端末向けに提供している。以下では、実際のサービス名やアプリケーション名を問わず、ShoCard社によるＩＭＳを“ShoCard”と呼び、そのＩＭＳで用いられるプラットフォームおよび個人端末向けアプリケーションを“ShoCardプラットフォーム”および“ShoCard APP”と呼ぶ場合がある。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１７−１６２１９１号公報
【特許文献２】特開２０１７−１０２８４２号公報
【００１０】
【非特許文献１】"SHOBADGE Secure Enterprise Identity Authentication Built Using the Blockchain (White paper)", [online], 2017, ShoCard Inc., [平成30年4月6日検索], インターネット＜URL:https://shocard.com/shobadge/＞
【発明の概要】
【発明が解決しようとする課題】
【００１１】
課題は、個人情報を利用して対象確認を行う場合に、利用者側の利便性および個人情報の保護並びにベンダ側の情報漏洩のリスク回避が十分でないという点にある。
【００１２】
例えば、特許文献１や特許文献２に記載の方法は、サービスごとに、ＩＤと認証情報の組を管理したり、対象確認のための手続きを行う必要がある。そのため、利用者は、種々のサービスの提供を受けようとすると、サービスやベンダごとに異なるＩＤや認証情報や対象確認のための手続きに用いる情報を管理する必要があり、煩雑である。
【００１３】
また、各ベンダにとっても、利用者の個人情報を自身で保持、管理しなければならず、漏洩リスクを負うだけでなく攻撃に対する防御を含む情報管理のためのコストが増加する問題がある。
【００１４】
なお、利用者の個人情報をベンダ側で管理せず、サービスを要求された際にその都度利用者に提示させることも考えられる。しかし、この方法は、対象確認においてその都度対象確認に必要な情報を提示しなければならず、利用者にとって煩雑である。加えて、この方法は、例えば、対象確認では免許証などの利用者本人を証明する証明書の一部の情報のみを提示すれば足りる場合であっても、証明書全体を提示せざるを得ない場合など、目的や用途ごとに必要最小限の情報のみを開示するといった制御ができず、個人情報の保護という点でも十分でない。
【００１５】
なお、上述の“ShoCard”では、端末アプリ利用時にユーザごとに割り当てられるShoCardIDを利用して、ユーザの個人情報の開示要求をしたり、開示された情報の真正性を検証して本人確認を行うための個人用アプリケーションを提供している。このような個人用アプリケーションを利用すれば、サービス提供側の提携先システムとの間で仕様を決めて協同することで対象確認を含むサービスを提供できるかもしれないが、２回目以降の同様の承認を、ユーザが再度の個人情報の開示する等の手間をかけずに、またどのベンダにおいても利用者の個人情報の漏洩リスクを負わずに、かつ継続して利用可能な環境下で実現しようといったことは何ら考慮されいてない。
【００１６】
本発明は、上記のような課題を解決するために、利用者における手続きや手続きのための情報の管理が煩雑でなく、またベンダが利用者の個人情報の漏洩リスクを負うことなく、個人情報を利用した対象確認を行うことが可能な個人情報管理システム、それを利用してサービスを提供するサービス提供システム、サービス提供方法およびサービス提供プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明による個人情報管理システムは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う対象確認部と、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する記録登録部とを備えることを特徴とする。
【００１８】
本発明によるサービス提供システムは、利用者が使用する個人用端末と、利用者に所定のサービスを提供するサービス提供装置と、サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置と、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードとを備え、個人用端末は、ブロックチェーンに、利用者の識別子と、利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録する登録部を含み、サービス提供装置は、要求元の利用者に対して本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認を行った上で利用者に所定のサービスを提供するサービス提供部と、利用者に第２の対象確認情報の開示を要求して、得られた情報を基に対象確認を行う第１の対象確認部と、ブロックチェーンに、利用者の識別子と、対象確認の記録もしくは所定のサービスの提供の記録とを含む第２ブロックを登録する記録登録部とを含み、許可証判定装置は、利用者から入場または許可証により得られる利益の受領の申請を受け付けると、利用者に、第２ブロックを特定可能な情報と、第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行う第２の対象確認部と、第２の対象確認部による対象確認の結果に基づいて、利用者の申請の可否を判定する判定部とを含むことを特徴とする。
【００１９】
本発明によるサービス提供方法は、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを少なくとも登録しておき、利用者からサービスを要求されると、利用者に対象確認情報の開示を要求し、開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行い、対象確認の結果に基づいて、利用者にサービスを提供するとともに、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録することを特徴とする。
【００２０】
本発明によるサービス提供プログラムは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンであって、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックが少なくとも登録されたブロックチェーンから少なくとも第１ブロックの情報を取得可能なコンピュータに、利用者からサービスを要求されると、利用者に対象確認情報の開示を要求し、開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う処理、対象確認の結果に基づいて、利用者にサービスを提供する処理、およびブロックチェーンに、対象確認の記録を含む第２ブロックを登録する処理を実行させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、利用者において手続きおよび手続きのための情報の管理が煩雑でなく、またベンダが利用者の個人情報の漏洩リスクを負うことなく、個人情報を利用した対象確認を行うことができる。
【図面の簡単な説明】
【００２２】
【図１】第１の実施形態の個人情報管理システムにおける各種情報の保持例を示す説明図である。
【図２】登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。
【図３】登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。
【図４】確認記録ブロックの例を示す説明図である。
【図５】第１の実施形態の個人情報管理システムの主要な構成を示す構成図である。
【図６】確認部２０２の構成例を示すブロック図である。
【図７】台帳管理ノード３０１の構成例を示すブロック図である。
【図８】第１実施形態の個人情報管理システムの登録フェーズにおける動作の一例を示すフローチャートである。
【図９】第１実施形態の個人情報管理システムの登録フェーズにおける動作の他の例を示すフローチャートである。
【図１０】第１の実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。
【図１１】第１の実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。
【図１２】確認フェーズにおける確認機関側システムの動作例を示すフローチャートである。
【図１３】第２の実施形態のチケットサービスシステムの概略構成図である。
【図１４】第２の実施形態のチケットサービスシステムの動作の概略を示すフローチャートである。
【図１５】第２の実施形態の本人登録時の処理の流れの一例を示すシーケンス図である。
【図１６】第２の実施形態の購入申請時の処理の流れの一例を示すシーケンス図（１）である。
【図１７】第２の実施形態の購入申請時の処理の流れの一例を示すシーケンス図（２）である。
【図１８】第２の実施形態の入場申請時の処理の流れの一例を示すシーケンス図である。
【図１９】第２の実施形態のチケットサービスシステムの他の例を示すブロック図である。
【図２０】本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。
【図２１】本発明の個人情報管理システムの概要を示すブロック図である。
【発明を実施するための形態】
【００２３】
以下、図面を参照して本発明の実施形態について説明する。まず、本発明における個人情報管理システム（Identity Management Sysmtem：IMS）の技術コンセプトを簡単に説明する。
【００２４】
本発明における個人情報管理システムでは、種々の個人情報と利用者とを対応づける識別情報として１つの個人ＩＤを割り当てる。より具体的には、対象確認に利用される種々の個人情報を、利用者ごとに割り当てられた１つの個人ＩＤに対応づけてセキュアに管理する。なお、個人ＩＤは、その利用者が所有する全ての個人情報に対応づけられることが好ましいが、少なくとも本発明が提供する個人情報管理システムが管理する個人情報と対応づけられていればよい。その場合も、個人ＩＤは、個人情報管理システム内において、対象確認に利用される種々の個人情報に対応づけられる１つの識別情報、すなわち集約された識別番号であるといえる。
【００２５】
また、本発明における個人情報管理システムでは、利用者の個人情報を管理するための機構として、ブロックチェーンを利用する。ここで、ブロックチェーンは、ブロックとよばれる所定のデータ構造を有するデータ群を時系列に並べたものであり、取引内容を記した台帳としての役割を有する。各ブロックは、取引内容等の当該ブロックに記録したいデータの他に、一つ以上前のブロック（以下、前ブロックという）の情報と、改ざんの有無を検知するための情報（ノンスや署名など）とを含む。ノンスは、あるデータ領域に対して、その領域内のデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように設定される、当該データ領域内の値である。ブロックチェーンには、２台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される。例えば、コンセンサスアルゴリズムの一つであるＰｏＷ（Proof of Work）では、前ブロックの情報とノンスとを含む各ブロック（データ群）に対して、「ブロックのＨａｓｈ値が閾値（ターゲット値）以下であること」といった規則が予め決められており、ブロックを追加する際に、そのような規則を満たすようなノンスを複数のノードが同時並列的に探索する処理が行われる。なお、ＰｏＷ以外にもＢＦＴ（Byzantine fault tolerance）等のコンセンサスアルゴリズムがある。
【００２６】
ただし、ブロックチェーンには個人情報をそのまま記録せずに、個人ＩＤのハッシュ値と対応づけて個人情報のハッシュ値を記録する。その際、ハッシュ値に対して該ハッシュ値を作成した者（作成元）の署名を付す。署名は、例えば、個人情報の所有者である本人の署名や、個人情報が正しいこと（Correctness）を確認した第三者機関（以下、確認機関という）の署名などである。署名として、署名者の秘密鍵で、署名対象の情報（この場合、ハッシュ値）を暗号化して得られたデジタル署名を利用できる。ハッシュ値に作成元の署名を付すことで、該ハッシュ値の信頼性（reliability）、より具体的には、該ハッシュ値が署名者本人によって作成されたもの（作成元証明）であり、かつ署名時点から改ざんされていないこと（非改ざん証明）を、該ハッシュ値を参照する側が確認できるようにする。このようなハッシュ値の作成者証明と非改ざん証明とを行うことより、登録情報であるハッシュ値が信頼できる情報、すなわち正規の所有者が所持している情報または確認機関がその正当性を確認した情報から作成された情報であることが、署名から確認できるようにする。なお、署名を付す処理に代えて暗号化を行うことも可能である。
【００２７】
なお、ブロックチェーンに登録された情報（ハッシュ値やそれに付される署名）自体の信頼性は、ブロックチェーンの改ざん困難性によって担保する。
【００２８】
一方で、ハッシュ値の元データである個人情報は、本人以外の者に隠ぺいされるようセキュアな環境に保持される。例えば、個人情報は、本人が所持するデバイス（以下、クライアントデバイスという）内のセキュア領域に記憶されたり、分散ファイルサーバに暗号化して記憶されてもよい。利用者は、このようなセキュアな環境に置かれた個人情報について、自由に開示するか否か、開示する場合にはどの個人情報を開示するかをコントロールできる。
【００２９】
本発明における個人情報管理システムでは、第三者が参照可能なブロックチェーンには、その個人ＩＤ（ブロック内の個人ＩＤのハッシュ値の元データである個人ＩＤ）と対応づけられる利用者の個人情報としての正しさを示す情報のみを記憶することで、個人情報の秘匿性を担保する。また、その際、個人情報の所有者を識別するための識別情報を１つにまとめることで、これまで用途ごとに異なっていた対象確認の手続きを、１つの識別情報（個人ＩＤ）で指定される統一的な処理により行えるようにする。
【００３０】
さらに、本発明における個人情報管理システムでは、ブロックチェーンに記憶されている該利用者の個人情報のハッシュ値を利用して対象確認を行った場合に、その確認の記録を示すブロックを該ブロックチェーンに追加していく。このように、ブロックチェーンに確認の記録の履歴を残すことで、具体的な個人情報の開示を伴わずに同様の目的の対象確認に、過去の対象確認の結果を利用できるようにする。例えば、過去に同様の目的で対象確認が行われた利用者に対しては、個人情報の開示を要求しなくても、個人情報のハッシュ値を利用してブロックチェーン内の情報と照合を行うだけで、過去の対象確認の結果と同様の結果を与えることができるようにする。これにより、個人情報の開示を最小限に抑える。
【００３１】
なお、本発明における個人情報管理システムでは、利用者と個人情報とを結びつけるための情報として個人ＩＤを利用しているが、個人ＩＤは携帯電話機やＩＣカードや認証デバイスのような唯一のデバイスと対応づけて管理されるものではないため、仮にデバイス等が紛失したとしても登録済みの情報の書き換え等を行うことなくリカバリが可能となる。
【００３２】
実施形態１．
次に、具体的なシステム構成を提示しつつ、本発明における個人情報管理システムの実施形態を説明する。図１は、第１の実施形態の個人情報管理システムにおける各種情報の保持例を示す説明図である。図１には、利用者が所持するクライアントデバイス１と、確認機関が所持する確認機関デバイス２と、ブロックチェーン３とが示されている。
【００３３】
図１において、クライアントデバイス１には、その利用者本人の署名用の鍵ペア（秘密鍵１１Ｄと公開鍵１２Ｄ）と、個人情報管理システムから利用者に割り当てられた個人ＩＤ１３Ｄとが保持される。なおクライアントデバイス１において、個人ＩＤ１３Ｄは、１つ以上の個人情報１４Ｄと対応づけられている。
【００３４】
また、確認機関デバイス２には、その確認機関の署名用の鍵ペア（秘密鍵２１Ｄと公開鍵２２Ｄ）が保持される。
【００３５】
また、ブロックチェーン３には、以下に示すような登録ブロックや確認記録ブロックが保持される。
【００３６】
例えば、ある個人が個人情報管理システムの利用を開始すると、利用者となるその個人に個人ＩＤ１３Ｄが割り当てられるとともに、署名用の鍵ペア（秘密鍵１１Ｄと公開鍵１２Ｄ）が生成される。個人ＩＤ１３Ｄが割り当てられ、鍵ペアが生成されると、利用者は、クライアントデバイス１を操作して、個人ＩＤ１３Ｄのハッシュ値と、登録したい個人情報１４Ｄ（特に、対象確認に用いられる個人情報）のハッシュ値とを算出し、それらを含む個人情報管理ブロックを作成してブロックチェーンに追加する。
【００３７】
図１には、ブロックチェーン３に追加された登録ブロックの例として、ブロックｎ−１が示されている。登録ブロックには、個人ＩＤ＿Ｈａｓｈ３１Ｄ（上記の個人ＩＤ１３Ｄのハッシュ値に対応）と、個人情報Ｈａｓｈ３２Ｄ（上記の個人情報１４Ｄのハッシュ値に対応）と、それらの作成元である本人の署名３３Ｄとが含まれる。ここで、本人の署名３３Ｄは、当該ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄが、元データの正規の所有者である利用者本人によって作成されたものであることを示すための署名である。
【００３８】
個人情報Ｈａｓｈ３２Ｄは、該個人情報の所有者である利用者が個人情報を開示する単位ごとに算出されるのが好ましい（図２（ａ）参照）。その際、各々の個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄを付すことも可能である（図２（ｂ）参照）。図２は、登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。なお、図２において、点線は本人の署名３３Ｄの署名対象データを表している。
【００３９】
なお、利用者は、登録したい個人情報が複数ある場合、それらのハッシュ値を別々の登録ブロックにしてブロックチェーン３に追加することも可能である。いずれの場合においても、登録ブロックにおいて、作成元の署名とともに、利用者の個人ＩＤ＿Ｈａｓｈ３１Ｄと個人情報Ｈａｓｈ３２Ｄとが対応づけられていればよい。なお、個人ＩＤも個人情報の一つとみなすこともでき、その場合、登録ブロックは、個人ＩＤとそれ以外の個人情報の２以上の個人情報について、それらのハッシュ値が作成元の署名とともに含まれていればよい。
【００４０】
なお、図示省略しているが、各ブロックには、上記の他、署名の作成元の公開鍵や、ブロックの種別や、各登録情報の種別等を示す情報が含まれていてもよい。
【００４１】
また、ブロックチェーン３を構成する各ブロックには、当該ブロックがブロックチェーンの一部を構成するために必要とされる制御情報、例えば、前ブロックのハッシュ値や、当該ブロックを追加した者の署名等が含まれる。これら制御情報は、用いるブロックチェーンの仕様により定められる。
【００４２】
以下、個人情報として免許証を登録する場合を例に用いて説明する。免許証には、名前、住所、顔写真、生年月日、免許証番号、有効期限など複数の個人情報が含まれるが、利用者は、対象確認に用いる個人情報として、免許証全体を撮影した免許証画像を用いてもよい。その場合、免許証画像のハッシュ値を個人情報Ｈａｓｈ３２Ｄとして含む登録ブロックがブロックチェーン３に登録される。なお、個人情報である免許証画像自体は、クライアントデバイス１のセキュア領域に保持されたり、分割・暗号化されて分散ファイルシステムに保持されればよい。
【００４３】
免許証を個人情報として登録する場合において、免許証全体を１つの画像にする以外にも、開示をコントロールしたい単位に分割して複数の部分画像にしたり、開示をコントロールしたい単位を設定した上で単位ごとにその部分のみを識別可能に加工して複数の加工画像にしたり、テキスト入力可能な情報（住所や生年月日や氏名等）であればテキスト入力等によりデータ化したり、それらを適宜組み合わせたものを、個人情報として登録してもよい。その場合において、免許証画像（全体）、部分画像、加工画像およびテキストデータをそれぞれ異なる種類の個人情報として保持することも可能である。
【００４４】
例えば、利用者は、免許証の生年月日が記載された領域のみが識別できる画像（上記のい部分画像や加工画像）を、個人情報の１つである生年月日データとして登録したい場合には、該利用者の個人ＩＤのハッシュ値と、該生年月日データのハッシュ値とを算出し、それらの各々またはそれらを１つにまとめて本人の署名を付し、それら本人の署名が付されたハッシュ値を登録した登録ブロックを、ブロックチェーン３に追加してもよい。
【００４５】
次に、ブロックチェーン３に登録されている情報を利用して、利用者の対象確認を行う場合を説明する。対象確認を行いたい確認機関の確認機関デバイス２は、確認対象の利用者のクライアントデバイス１から、個人ＩＤ１３Ｄと、対象確認に用いる個人情報１４Ｄ（以下、第１の個人情報という）とを取得する。そして、確認機関デバイス２は、個人ＩＤ１３Ｄのハッシュ値と対応づけて第１の個人情報のハッシュ値が登録された登録ブロックを取得する。登録ブロックの取得は、個人ＩＤ１３Ｄから算出されるハッシュ値と第１の個人情報から算出されるハッシュ値とをキーにしてブロックチェーン３を検索して得てもよいし、後述するような利用者が保持しているブロック登録履歴等から得られる登録ブロックのハッシュ値等を得て、それをキーにブロックチェーン３を検索して得てもよい。少なくともブロックチェーン３において公開されている情報を基に検索できればよい。該当する登録ブロックが検索されると、確認機関デバイス２は、該登録ブロックに登録されている情報（個人ＩＤ＿Ｈａｓｈ３１Ｄや個人情報Ｈａｓｈ３２Ｄ）がその利用者本人（この場合、個人情報を開示した開示者本人）によって作成され（作成元証明）、かつ署名時点から改ざんされていないこと（非改ざん証明）を、該情報に付された本人の署名３３Ｄと、署名者とされた利用者の公開鍵１２Ｄとを用いて確認する（登録情報の信頼性確認）。また、確認機関デバイス２は、検索された登録ブロック内の個人情報Ｈａｓｈ３２Ｄと、利用者から取得した第１の個人情報から算出したハッシュ値とを照合する（元データの一致性確認）。なお、元データの一致性確認は、第１の個人情報から算出されるハッシュ値をキーにして登録ブロックを検索した場合は省略される。
【００４６】
確認機関デバイス２は、これら２つの確認結果がともにＯＫであった場合に、開示者から得られた第１の個人情報が、開示者から得られた個人ＩＤ１３Ｄが示す利用者本人の個人情報１４Ｄであると判定し、開示された第１の個人情報に基づいて、当該確認機関において必要な対象確認（本人確認やユーザ認証や適格性確認）を行う。
【００４７】
一例として、確認機関デバイス２が、サービスの受給資格の条件として、サービス要求元の利用者の年齢確認を行うことを考える。この場合、確認機関デバイス２は、該利用者のクライアントデバイス１に対して、個人ＩＤ１３Ｄと、第１の個人情報として生年月日データ（例えば、免許証画像の部分画像や加工画像やテキストデータ）の開示を要求してもよい。なお、第１の個人情報とされる生年月日データは、少なくともそのハッシュ値がその利用者の個人ＩＤ１３Ｄから算出されたハッシュ値とともに登録ブロックに登録されているもの、すなわち登録ブロック内の個人情報Ｈａｓｈ３２Ｄの元データであるとする。
【００４８】
これらの情報を得ると、確認機関デバイス２は、開示された個人ＩＤ１３Ｄが示す利用者の、開示された生年月日データのハッシュ値を登録した登録ブロックを取得する。該登録ブロックを取得すると、確認機関デバイス２は、該登録ブロックに含まれる生年月日データのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）および個人ＩＤ＿Ｈａｓｈ３１Ｄに付された本人の署名３３Ｄを作成元（利用者本人）の公開鍵１２Ｄを用いて復号し、得られた復号データ（署名対象とされたハッシュ値）の信頼性を確認する（登録情報の信頼性確認）。ここで、作成元の公開鍵として、ブロック内のものを用いてもよいし、利用者本人として第１の個人情報を開示した開示者の公開鍵を用いることもできる。
【００４９】
また、確認機関デバイス２は、必要に応じて該登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄと、利用者から開示された生年月日データから作成したハッシュ値とを照合して、両者が一致するかを確認する（元データの一致性確認）。なお、既に説明したように、元データの一致性確認は、開示された個人情報から算出されたハッシュ値をキーに用いて登録ブロックを検索した場合は、該検索処理に代替される（検索されたブロックは元データと一致している）。
【００５０】
登録情報の信頼性確認および元データの一致性確認がいずれもＯＫであった場合に、確認機関デバイス２は、開示された生年月日データは、開示された個人ＩＤが示す利用者本人である開示者の正しい個人情報であるとして、該生年月日データに基づいて年齢確認を行う。その結果、確認機関デバイス２は、例えば、年齢制限のあるサービス等を提供してもよい。このようにして、確認機関デバイス２は、サービスの要求元から個人ＩＤ１３Ｄと生年月日データとを取得するだけで、その生年月日データがその開示者の生年月日データであるか否かといった本人確認を自身で行わなくても、開示された生年月日データを基に対象確認（年齢確認）を行うことができる。
【００５１】
また、確認機関デバイス２は、ブロックチェーン３内の情報を利用して対象確認を行った場合、該確認の記録を示す確認記録ブロックをブロックチェーン３に登録する。
【００５２】
図１には、ブロックチェーン３に追加された確認記録ブロックの例として、ブロックｎやブロックｎ＋１が示されている。確認記録ブロックには、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄ（利用者から開示された個人ＩＤ１３Ｄから算出されるハッシュ値に対応）とその作成元である確認機関の署名３５Ｄとが含まれる。なお、ブロックｎとして示すように、確認記録ブロックは、さらに、確認情報３４Ｄを含んでいてもよい。
【００５３】
ここで、確認情報３４Ｄは、例えば、確認機関の情報（確認機関ＩＤ等）や、確認事項を示す情報を含んでいてもよい。このような確認情報３４Ｄを登録することで、以降、同じ目的の対象確認を行う場合に重複した処理を行わなくて済むようにできる。例えば、確認機関の情報は、例えば、確認機関を識別する確認機関ＩＤであってもよい。また、確認事項は、例えば、対象確認に利用したブロックの情報（これにより対象確認に利用した個人情報のハッシュ値や種別等がわかる）や、対象確認の結果（対象確認中に行われた種々の確認の結果を含む）や、対象確認の結果提供したサービスの種別や、そのサービスが必要とする適格性の種別等であってもよい。
【００５４】
このような確認記録ブロックがブロックチェーン３に含まれていれば、以降、確認機関は、具体的な個人情報（例えば、生年月日データ）の開示なしに、利用者から開示される個人ＩＤと個人情報のハッシュ値とに基づいて、それらハッシュ値から特定される過去の確認記録ブロックの確認情報３４Ｄで示される確認結果と同等の確認結果を利用者に与えることができる。また、利用者は、個人情報の不要な開示を防ぐことができる。
【００５５】
上記の例であれば、生年月日データの開示を受けずに、利用者の個人ＩＤと生年月日データのハッシュ値とから、過去にその利用者に与えられたサービスの種別やそれが必要とする適格性の種別と同等のサービスや適格性を、その利用者に与えることができる。なお、例えば、使用目的および使用機関が限定されている場合など、確認機関の署名３５Ｄからその利用者に対してどのような個人情報を用いてどのような対象確認が行われたかが特定可能な場合は、確認情報３４Ｄがなくても、同様の対象確認の結果をその利用者に与えることも可能である。なお、その場合においても、その利用者の確認記録とされる確認記録ブロックの登録情報について、署名に基づく信頼性確認を行うことを前提とする。
【００５６】
なお、利用者のクライアントデバイス１が、自身の情報（少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄ）を記録したブロックのブロックチェーン３におけるキー情報（ブロックのハッシュ値等）を登録履歴として保持しておき、対象確認時に援用したいブロックのキー情報を指定することも可能である。
【００５７】
ところで、上記の登録情報の信頼性判定は、利用者の個人ＩＤ、個人情報および秘密鍵が第三者に秘匿状態にあり、署名者（それらのハッシュ値を作成した者）が正しい個人ＩＤおよび個人情報からハッシュ値を作成していることを前提としている。しかし、仮に正規の利用者が故意に不正（個人情報の改ざん等）をした場合には、登録情報（この場合、個人ＩＤのハッシュ値および個人情報のハッシュ値）に付された本人の署名だけでは、元データ（個人ＩＤそのものや個人情報そのもの）の正当性までは保証されない。
【００５８】
例えば、対象確認に用いる第１の個人情報が顔写真や生体情報など利用者の生体由来の情報の場合、開示された第１の個人情報から作成したハッシュ値と開示された個人ＩＤ１３Ｄから作成したハッシュ値との対応関係、および開示された第１の個人情報と開示者本人から得られる同等の情報（現在の生体情報等）との類否関係から、開示された第１の個人情報または開示された第１の個人情報のハッシュ値の元データの正当性、すなわち個人ＩＤ１３Ｄを開示した開示者でありその個人ＩＤ１３Ｄが示す利用者本人の個人情報としての正当性が確認できる。
【００５９】
しかし、開示された第１の個人情報が利用者の生体由来の情報以外の情報（例えば、氏名や住所や生年月日などの属性情報）の場合、登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄの信頼性確認だけでは、元データである第１の個人情報の正当性までは確認できない。
【００６０】
そこで、利用者の故意の不正までを考慮して、所定の確認機関に該個人情報の正当性を確認させた上で、登録ブロックを追加するようにしてもよい。このとき、個人情報Ｈａｓｈ３２Ｄに、本人の署名３３Ｄに代えてもしくは本人の署名３３Ｄと合わせてその確認機関の署名３５Ｄを付してもよい。本人の署名３３Ｄに代えて確認機関の署名３５Ｄを付す場合でも、本人の署名３３Ｄが個人ＩＤ＿Ｈａｓｈ３１Ｄに付されるため、特に問題ない。また、本人の署名３３Ｄと確認機関の署名３５Ｄを合わせて付す場合、一方の署名が付された署名対象データを１つのデータとみなして他方の署名を付すなど入れ子構造にしてもよいし、１つの署名対象データにそれぞれが署名を付してもよい。
【００６１】
図３は、登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。なお、図３において、点線は本人の署名３３Ｄの署名対象データを表し、破線は確認機関の署名３５Ｄの署名対象データを表している。図３（ａ）は、個人情報Ｈａｓｈ３２Ｄに本人の署名３３Ｄに代えて確認機関の署名３５Ｄを付した場合の例である。また、図３（ｂ）〜（ｆ）は、個人情報Ｈａｓｈ３２Ｄに本人の署名３３Ｄと確認機関の署名３５Ｄとを合わせて付した場合の例である。なお、図３（ｂ）に示す例では、署名対象データである個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄと確認機関の署名３５Ｄをそれぞれ付し、図３（ｃ）〜（ｆ）に示す例では、入れ子構造で本人の署名３３Ｄと確認機関の署名３５Ｄを付している。なお、ここで「入れ子構造」は、署名対象データに対して先に一方の署名を付し、その署名を含むデータを新たな署名対象データにして他方の署名を付すことをいう。なお、後に署名を行う署名者は、先に付された署名と合わせて先の署名対象データやそれ以外のデータを含むことも可能である。なお、いずれの場合においても、対象確認において登録情報の信頼性を確認する際に、どのような構造でかつどのデータを対象に誰の署名が付されているかが予めもしくは該ブロック内の情報等からわかっているものとする。これにより、他の確認機関が個人ＩＤのハッシュ値と個人情報のハッシュ値と本人の公開鍵と確認機関の公開鍵とを入手可能であれば、登録情報の信頼性（これには個人情報の正当性を確認した確認機関の署名３５Ｄの信頼性を含む）を確認できるようにする。
【００６２】
例えば、図３（ｃ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に本人の署名３３Ｄを付し、その本人の署名３３Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして確認機関の署名３５Ｄを付している。また、例えば、図３（ｄ）に示す例は、２つの登録情報である個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄに先に本人の署名３３Ｄを付し、その本人の署名３３Ｄと先の署名対象データ（個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして確認機関の署名３５Ｄを付している。なお、図３（ｃ）〜（ｄ）において、確認機関は、先の署名である本人の署名３３Ｄのみを新たな署名対象データにして確認機関の署名３５Ｄを付すことも可能である。また、例えば、図３（ｅ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に確認機関の署名３５Ｄを付し、その確認機関の署名３５Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして本人の署名３３Ｄを付している。なお、本人は、確認機関の署名３５Ｄのみを新たな署名対象データにして本人の署名３３Ｄを付すことも可能である。また、例えば、図３（ｆ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に確認機関の署名３５Ｄを付し、その確認機関の署名３５Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）と他の登録情報（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を新たな署名対象データにして本人の署名３３Ｄを付している。
【００６３】
なお、個人情報管理システムでは、図２や図３に示すように、登録情報（例えば、個人ＩＤ＿Ｈａｓｈ３１Ｄや個人情報Ｈａｓｈ３２Ｄ）と１対１で本人または確認機関の署名が付されていなくても、ある署名の署名対象データに、その署名の目的とされる登録情報もしくはその登録情報を署名対象データとした他の署名が含まれている場合（入れ子構造により含まれている場合も含む）は、実質的にその登録情報にはそのある署名が付されているものとみなす。
【００６４】
したがって、ある登録情報について本人の署名を付して登録するといった場合には、他の登録情報と一体になって本人の署名が付されたもの、他の署名の署名対象データとされた登録情報にさらに本人の署名が付されたもの、他の署名が先に付されている登録情報に付された当該他の署名を含む署名対象データに本人の署名が付されたもの、本人の署名が先に付されている登録情報に付された当該本人の署名を署名対象データとしてさらに他の署名が付されたものなども含まれる。
【００６５】
例えば、第１の個人情報の正当性確認を依頼された確認機関の確認機関デバイス２は、クライアントデバイス１から、第１の個人情報と、該第１の個人情報が正しいことを当該確認機関において確認できる第２の個人情報とを取得してもよい。そして、確認機関デバイス２は、第２の個人情報を基に第１の個人情報が正しいことを確認した上で、第１の個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）を算出し、得られたハッシュ値に自身の署名（確認機関の署名３５Ｄ）を付してクライアントデバイス１に返信する。クライアントデバイス１は、確認機関の署名が付された個人情報のハッシュ値を受け取ると、本人の署名３３Ｄを付した個人ＩＤのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と合わせて登録ブロックを作成し、ブロックチェーン３に追加してもよい。
【００６６】
個人情報の正当性確認を行う確認機関は、例えば、その個人情報の発行元の機関（例えば、免許証情報であれば警察機関など）であってもよい。その場合、発行元としての確認機関の確認機関デバイス２は、例えば、当該確認機関において本人確認もしくはユーザ認証可能な情報（免許証番号や、顔写真や、クレジットカード番号や、パスワード等）を、第２の個人情報として取得し、それらが自身が保持している認証情報と一致するか否かを確認した上で、自身が発行した第１の個人情報と確認依頼された第１の個人情報とが一致するか否かを確認することでその正当性を判定してもよい。そして、正当性が確認できた場合には、利用者から取得した第１の個人情報のハッシュ値を算出し、そのハッシュ値に自身の署名を付してクライアントデバイス１に返信してもよい。以下、個人情報の正当性確認を行う確認機関が取得する第２の個人情報を、正当性確認情報という場合がある。
【００６７】
なお、クライアントデバイス１に返信せず、確認機関側で、登録ブロックを作成してブロックチェーン３に追加することも可能である。その場合、確認機関デバイス２は、クライアントデバイス１から、利用者本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄをさらに取得すればよい。なお、必要に応じて本人の署名３３Ｄが付された個人情報Ｈａｓｈ３２Ｄや、本人の署名３３Ｄが付された登録情報としての個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄを取得してもよい。
【００６８】
このような登録ブロックがブロックチェーン３に含まれていれば、以降、確認機関は、利用者から開示された第１の個人情報の正当性を自身で確認する必要なしに、ブロック内の登録情報（個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ）の信頼性確認および元データの一致性確認を行うだけで、該個人情報を対象確認に用いることができる。ただし、確認機関は、登録情報の信頼性確認で、本人の署名３３Ｄによるその署名が付された署名対象データの作成元証明（この場合、登録元証明）および非改ざん証明に加えて、確認機関の署名３５Ｄによるその署名が付された署名対象データの作成元証明（この場合、登録元証明）およびを非改ざん証明を行う。
【００６９】
なお、登録ブロックの個人情報Ｈａｓｈ３２Ｄの元データである個人情報の正当性を確認するタイミングは、登録ブロックの登録時に限定されない。例えば、登録ブロックの登録後に所定の確認機関に該個人情報の正当性を確認させることも可能である。その場合、確認機関は、登録情報の元データ（より具体的には登録情報の元データとの一致性が確認された第１の個人情報）の正当性確認を含む対象確認（本人確認やユーザ認証）を行ったとして、例えば、図４に示すような確認記録ブロックをブロックチェーン３に登録すればよい。図４に示す確認記録ブロックは、確認情報３４Ｄに、登録情報の元データの正当性確認を行った登録情報に含まれる個人情報Ｈａｓｈ３２Ｄや、本人確認の結果（ＯＫ）や、元データの正当性確認の結果（ＯＫ）の情報を含んでいる。
【００７０】
登録情報の元データである個人情報の正当性確認を含む対象確認は、例えば、上記の対象確認の処理において、確認機関デバイス２がさらにクライアントデバイス１から、開示された個人情報（第１の個人情報）が正しいことを当該確認機関において確認できる第２の個人情報を取得することにより実現できる。なお、第２の個人情報から第１の個人情報の正当性を確認する方法は上述したとおりである。なお、その確認機関において第１の個人情報から、目視等により第１の個人情報の正当性が確認できる場合は、第２の個人情報の取得は省略される。
【００７１】
なお、個人情報の発行元以外の確認機関が個人情報の正当性確認を行うことも可能である。その場合、該確認機関の確認機関デバイス２は、上記の対象確認の処理において、第１の個人情報またはそれと同等の内容を示す情報をその一部に含む第２の個人情報であって、さらにその個人情報（第２の個人情報）が正しいことをその確認機関または本システムにおいて確認できるものを取得してもよい。なお、いずれの機関が正当性を確認する場合も、その機関において第１の個人情報から、目視等により第１の個人情報の正当性が確認できる場合は、第２の個人情報の取得は省略される。
【００７２】
発行元以外の確認機関が個人情報の正当性確認を行う場合、第２の個人情報（正当性確認情報）として、例えば、次の条件（１）〜（３）のいずれかを満たす個人情報を用いてもよい。
・（１）（ａ）「（ａ１）『第１の個人情報またはそれと同じの内容を示す情報』と（ａ２）『本人確認が可能な情報』とを少なくとも一体化して含む情報の原本」または該原本の複写画像であること。
・（２）（ｂ１）「少なくとも（ａ１）『第１の個人情報またはそれと同じの内容を示す情報』を含む情報」であって、かつ（ｂ２）「そのハッシュ値の元データに対して発行元の確認機関の署名が付されたブロックがブロックチェーンに登録されている情報」であること。
・（３）（ｃ）「正規の第１の個人情報を保持する機関（正規情報保持機関）において利用者を識別可能な情報とユーザ認証が可能な認証情報の組」であること。
【００７３】
なお、条件（１）について、例えば、（ａ）＝（ａ１）生年月日データと（ａ２）顔画像とを一体化して含む免許証の原本またはその複写画像である場合を考える。そのような場合、開示された（ａ）内の（ａ２）について目視や現在の利用者から取得した（ａ２）と同等の情報との照合により開示者が本人であることが確認されれば、（ａ１）も本人の情報であるとみなすことができる。あとは、開示された（ａ）内の（ａ１）と、開示された第１の個人情報とを照合すればよい。このとき、複写画像を、対象確認時に原本から得るようにしてもよい。なお、開示された（ａ）内の（ａ１）と、開示された第１の個人情報との照合には、画像データとテキストデータの照合等も含まれる。また、第２の個人情報の正当性を確認するために、現在の利用者からさらに（ａ２）と同等の情報を取得する場合、その情報を第３の個人情報と呼ぶ場合がある。この場合、第３の個人情報を含めて本人確認情報と呼ぶ場合がある。
【００７４】
また、条件（２）について、例えば、（ｂ１）＝（ａ１）生年月日データを含む保険証画像（全体）である場合を考える。そのような場合、開示された（ｂ１）のハッシュ値の元データに対して発行元の確認機関の署名が付されたブロックがブロックチェーン３に登録されていれば、そのブロック内の登録情報の信頼性と、開示された（ｂ１）とブロック内のハッシュ値の元データとの一致性とが確認されれば、開示された（ｂ１）について正当性が確認される。あとは、開示された（ｂ１）内の（ａ１）と、開示された第１の個人情報とを照合すればよい。
【００７５】
また、条件（３）について、（ｃ）＝そのようなユーザ識別情報と認証情報の組であれば、第１の個人情報とともに（ｃ）を正規情報保持機関に送信して、（ｃ）を基にユーザ認証を行った上で、送信した第１の個人情報と正規情報保持機関が保持しているそのユーザの正規の第１の個人情報とを照合した結果を返信してもらうことで、開示された第１の個人情報の正当性を確認できる。
【００７６】
例えば、その利用者の登録ブロックや確認記録ブロックに含まれる個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）に、元データの正当性を確認した確認機関の署名３５Ｄが付されていない場合、確認機関の確認機関デバイス２は、対象確認に用いる第１の個人情報の正当性確認を含む対象確認を行ってもよい。具体的には、確認機関デバイス２は、対象確認時に上記のような第２の個人情報の開示をさらに要求してもよい。
【００７７】
また、個人情報管理システムは、必要に応じて、利用者が個人ＩＤを開示する際に、該個人ＩＤに対してユーザ認証を行った上で、上記の処理を行うようにしてもよい。ユーザ認証は、既存の認証技術を利用できる。
【００７８】
なお、上述した登録ブロックの追加、確認記録ブロックの追加、ブロック内の登録情報の信頼性確認、元データの一致性確認、元データの正当性確認等における具体的処理（個人情報や秘密鍵へのアクセスを除く）は、個人情報管理システムが提供するＵＩ（User Interface）やＡＰＩ（Application Program Interface）等を利用して個人情報管理システムが行う。
【００７９】
次に、図５を参照して、個人情報管理システムの主要な構成について説明する。図５に示す個人情報管理システム１００は、データ記憶部１０１、登録部１０２、開示部１０３、認証部１０４、データ記憶部２０１、確認部２０２、台帳管理ノード３０１、データ記憶部５０１および個人ＩＤ割当部５０２を備える。図５に示すように、個人情報管理システム１００は、大きく、利用者側システム１０と、確認機関側システム２０と、台帳管理システム３０と、管理側システム５０とに大別されている。
【００８０】
図５において、データ記憶部１０１、登録部１０２、開示部１０３および認証部１０４は利用者側システム１０に属する。また、データ記憶部２０１および確認部２０２は確認機関側システム２０に属する。また、台帳管理ノード３０１は台帳管理システム３０に属する。また、データ記憶部５０１および個人ＩＤ割当部５０２は管理側システム５０に属する。なお、認証部１０４は、管理側システムで保持している認証情報を用いてユーザ認証を行う場合は管理側システムに属することも可能である。
【００８１】
ただし、この分類は情報のアクセス権限に基づくものであり、実際のプログラムの動作環境を限定するものではない。例えば、登録部１０２の一部（データ記憶部１０１へのアクセスを除く）や確認部２０２の一部（データ記憶部２０１へのアクセスを除く）の機能が、管理側システム５０が備える装置に実装されてもよい。
【００８２】
図示省略しているが、利用者側システム１０は少なくともクライアントデバイス１を含む。また、確認機関側システム２０は少なくとも確認機関デバイス２を含む。
【００８３】
データ記憶部１０１、データ記憶部２０１およびデータ記憶部５０１を除いた各処理部は、それぞれネットワーク４０を介して接続されている。なお、ネットワーク４０は、インターネットとＥｔｈｅｒｅｕｍネットワークなどの複数の異なるネットワークを含んでいてもよい。データ記憶部１０１は、登録部１０２、開示部１０３および認証部１０４と接続されていればよい。また、データ記憶部２０１は確認部２０２と接続されていればよい。また、データ記憶部５０１は、個人ＩＤ割当部５０２と接続されていればよい。
【００８４】
データ記憶部１０１は、利用者側システム１０に属する各処理部が必要な情報や、利用者の情報として他のシステムに開示される情報を保持する。データ記憶部１０１は、例えば、利用者の個人情報１４Ｄや、個人情報管理システム１００が割り当てる個人ＩＤ１３Ｄや、署名用のペア鍵（秘密鍵１１Ｄおよび公開鍵１２Ｄ）を記憶する。本実施形態において、データ記憶部１０１の少なくとも一部は、利用者側システム１０が備える装置（例えば、クライアントデバイス１）が備えるセキュア領域を有する記憶装置や、利用者側システム１０が備える装置からアクセス可能な分割ファイルシステムにより実現される。
【００８５】
登録部１０２は、利用者からの指示に応じて、利用者の個人ＩＤ１３Ｄのハッシュ値と、登録したい個人情報１４Ｄのハッシュ値と、必要な署名（少なくとも本人の署名を含む）とを有する登録ブロックをブロックチェーン３に登録する。なお、実際の登録は後述する台帳管理ノード３０１が所定の手続きを経て行うため、登録部１０２は、台帳管理ノード３０１を介して登録ブロックをブロックチェーン３に追加するための処理を行う。なお、登録部１０２は、そのような登録ブロックをブロックチェーン３に登録するための手続きを利用者に提供できればよい。
【００８６】
登録部１０２は、例えば、利用者から登録したい個人情報１４Ｄが指定されると、データ記憶部１０１から指定された個人情報１４Ｄを読み出し、そのハッシュ値を算出する。そして、得られた個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）と個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）とに対して少なくとも１つの本人の署名３３Ｄを付した上で、それらが登録された登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信する。
【００８７】
なお、登録部１０２は、必要に応じて所定の確認機関の確認部２０２に、元データとされる個人情報１４Ｄの正当性確認の依頼を該個人情報１４Ｄとともに送信してもよい。それにより、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄを得てもよい。その上で、登録部１０２は、個人情報Ｈａｓｈ３２Ｄと、個人ＩＤ＿Ｈａｓｈ３１Ｄと、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄと、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄに対する本人の署名３３Ｄとを登録情報として含む登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信してもよい。
【００８８】
また、登録部１０２は、所定の確認機関の確認部２０２に、個人情報１４Ｄの正当性確認および登録ブロックの登録依頼を、少なくとも本人の署名３３Ｄを付した個人ＩＤ＿Ｈａｓｈ３１Ｄとともに送信してもよい。その場合、確認部２０２によって、個人情報Ｈａｓｈ３２Ｄと、個人ＩＤ＿Ｈａｓｈ３１Ｄと、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄと、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄに対する本人の署名３３Ｄとを登録情報として含む登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信してもよい。
【００８９】
開示部１０３は、利用者からの指示に応じて、指定された個人情報１４Ｄまたはそのハッシュ値を外部に出力する。ここで、外部への出力には、表示（表示装置への出力）や、送信（指定された宛て先への出力）が含まれうる。開示部１０３は、例えば、確認部２０２から個人情報１４Ｄが指定された開示要求を受け付けると、利用者にその開示有無を問い合わせた上で、指定された個人情報１４Ｄまたはそのハッシュ値を、指定された出力先（要求元の確認部２０２や表示部等）に出力する。なお、開示部１０３は、その個人情報１４Ｄのハッシュ値が同じ目的の対象確認の結果や確認機関の署名とともに確認記録ブロックや登録ブロックとしてブロックチェーン３に登録されている場合、指定された個人情報１４Ｄに代えて、指定された個人情報１４Ｄのハッシュ値を出力することも可能である。その際、開示部１０３は、いずれの情報を開示するかを利用者に問い合わせした後、指定された情報を出力してもよいし、問い合わせをせずに優先してハッシュ値を出力してもよい。また、個人情報に代えて個人情報のハッシュ値を出力する場合、開示部１０３は、そのときの確認記録ブロックの情報を合わせて出力してもよい。
【００９０】
認証部１０４は、他の処理部が個人ＩＤ１３Ｄにアクセスする際に、現在の利用者に対してユーザ認証を行う。認証部１０４は、例えば、個人ＩＤ１３Ｄへのアクセスを検知すると、現在の利用者に認証情報の入力を要求し、入力された認証情報と予め保持している認証情報とを照合して、現在の利用者のユーザ認証を行う。なお、利用者側システム１０において個人ＩＤ１３Ｄに対するユーザ認証が不要な場合は、認証部１０４は省略されてもよい。
【００９１】
本実施形態において、登録部１０２、開示部１０３および認証部１０４は、例えば、利用者側システム１０が備える装置にインストールされるなど、データ記憶部１０１にアクセス可能なＣＰＵ等により実現される。
【００９２】
なお、認証部１０４は、管理側システム５０において、開示部１０３から開示された個人ＩＤ１３Ｄに対するユーザ認証を行う処理部として動作することも可能である。その場合、認証部１０４は、後述する確認部２０２からの要求に応じて、個人ＩＤ１３Ｄを開示した開示部１０３の現在の利用者（開示者）に認証情報の入力を要求し、入力された認証情報とデータ記憶部５０１等に予め保持している認証情報とを照合して、開示者のユーザ認証を行う。その場合、認証部１０４は、データ記憶部５０１にアクセス可能に実装されているＣＰＵ等により実現される。
【００９３】
データ記憶部２０１は、確認機関側システム２０に属する各処理部が必要な情報や、確認機関の情報として当該個人情報管理システム１００が備える他のシステムに開示される情報を保持する。データ記憶部２０１は、例えば、確認機関ＩＤや、署名用のペア鍵（秘密鍵２１Ｄおよび公開鍵２２Ｄ）を記憶する。本実施形態において、データ記憶部２０１の少なくとも一部は、確認機関側システム２０が備える装置（例えば、確認機関デバイス２）が備えるセキュア領域を有する記憶装置や、確認機関側システム２０が備える装置からアクセス可能な分割ファイルシステムにより実現される。
【００９４】
確認部２０２は、利用者からサービスを要求された確認機関からの指示に応じて、利用者の対象確認を行う。確認部２０２は、例えば、指定された利用者の開示部１０３から取得される情報と、ブロックチェーン３に登録されている情報（登録ブロックおよび確認記録ブロック内の情報）とに基づいて、利用者の対象確認を行う。
【００９５】
確認部２０２は、例えば、指定された利用者の開示部１０３に対して、個人ＩＤ１３Ｄと対象確認に用いられる個人情報１４Ｄまたはそのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）の開示を要求する。また、確認部２０２は、得られた情報や利用者側システム１０が保持するブロックの登録履歴を基に、該利用者の登録ブロックまたは確認記録ブロックを検索する。そして、得られた該利用者の登録ブロックまたは確認記録ブロックを利用して、上述したような登録情報の信頼性確認や元データの一致性確認や個人情報の正当性確認を行い、それらの確認結果を出力したり、それらの確認結果に基づき対象確認を行う。なお、対象確認自体は、登録情報の信頼性確認、元データの一致性確認または個人情報の正当性確認もしくはそれらの組み合わせを基に判定される開示された情報の正当性の判定結果の出力を基に、確認機関側のユーザが行ってもよい。その場合、確認部２０２は、該ユーザが行った対象確認結果を受け付ける。
【００９６】
また、確認部２０２は、必要に応じて対象確認の記録を示す確認記録ブロックを作成し、ブロックチェーン３に追加するための処理を行う。確認記録ブロックは、対象確認を行った利用者の個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と、それに対する確認機関の署名３５Ｄとを少なくとも含む。
【００９７】
なお、確認部２０２は、そのような対象確認およびそのような確認記録ブロックのブロックチェーン３への登録手続きを確認機関に提供できればよい。本実施形態において、確認部２０２は、例えば、確認機関側システム２０が備える装置にインストールされるなど、データ記憶部２０１にアクセス可能なＣＰＵ等により実現される。
【００９８】
なお、図５では、利用者側システム１０および確認機関側システム２０がそれぞれ１つしか示されていないが、利用者側システム１０は利用者ごとに設けられ、また確認機関側システム２０も確認機関ごとに設けられる。
【００９９】
台帳管理システム３０は、ブロックチェーンを台帳とし、該台帳を複数のノードが共有して管理するシステムである。なお、ブロックチェーンを管理するシステムとして、台帳管理システムを例示するが、所定のコンセンサスアルゴリズムに従う処理（以下、コンセンサス処理という）を実行可能で、かつ改ざんが困難な台帳をシステム内の端末で共有するシステムであれば、台帳管理システムに限定されない。
【０１００】
台帳管理ノード３０１は、台帳管理システム３０において、コンセンサス処理を実行するノードである。台帳管理ノード３０１の各々は、当該コンセンサス処理の実行を通して、ブロックチェーン３のコピーを保持する。
【０１０１】
なお、図５では、利用者側システム１０と台帳管理システム３０、確認機関側システム２０と台帳管理システム３０とを分けて記載しているが、例えば、利用者側システム１０や確認機関側システム２０が台帳管理ノード３０１の機能を有していてもよい。
【０１０２】
データ記憶部５０１は、管理側システム５０に属する各処理部が必要な情報や、管理側システム５０の情報として当該個人情報管理システム１００が備える他のシステムに開示される情報があればそれを保持する。データ記憶部５０１は、例えば、利用者に割り当てた個人ＩＤの情報や、当該個人情報管理システム１００が備える他のシステムの処理部が行う手続きを実装したプログラム（実行コードなど）を記憶してもよい。本実施形態において、データ記憶部５０１の少なくとも一部は、管理側システム５０が備えるセキュア領域を有する記憶装置や、管理側システム５０が備える装置からアクセス可能な分割ファイルシステムにより実現される。
【０１０３】
個人ＩＤ割当部５０２は、利用者に個人ＩＤ１３Ｄを割り当てる。本実施形態において、個人ＩＤ割当部５０２は、例えば、管理側システム５０が備える装置にインストールされるなど、データ記憶部５０１にアクセス可能なＣＰＵ等により実現される。
【０１０４】
また、図６は、確認部２０２の構成例を示すブロック図である。図６に示すように、確認部２０２は、データ取得部２２１と、登録情報信頼性確認部２２２と、元データ一致性確認部２２３と、個人情報正当性確認部２２４と、結果出力部２２５と、確認記録登録部２２６とを含んでいてもよい。
【０１０５】
データ取得部２２１は、利用者側システム１０（特に、開示部１０３）から個人ＩＤ１３Ｄとともに対象確認に必要な情報（例えば、個人情報１４Ｄまたはそのハッシュ値や、その利用者の過去の確認記録ブロックの情報等）を取得する。また、データ取得部２２１は、利用者側システム１０から取得した情報を基にブロックチェーン３を検索して、その利用者の情報（特に、対象確認に必要な個人情報１４Ｄまたはそのハッシュ値や、それを用いて対象確認を行った旨の記録（確認情報３４Ｄ等））を含むブロックを取得する。
【０１０６】
例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄと個人情報１４Ｄとを取得した場合には、その個人ＩＤ１３Ｄのハッシュ値とその個人情報１４Ｄのハッシュ値とを含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄと個人情報１４Ｄのハッシュ値とを取得した場合には、その個人ＩＤ１３Ｄから算出されるハッシュ値とその個人情報１４Ｄのハッシュ値とを含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄを取得した場合には、その個人ＩＤ１３Ｄから算出されるハッシュ値を含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄのハッシュ値と過去の確認記録ブロックの情報とを取得した場合には、最新の確認記録ブロックをブロックチェーン３から取得してもよい。
【０１０７】
データ取得部２２１は、利用者側システム１０からどのような情報を取得するかを、その利用者の確認記録から決定してもよい。
【０１０８】
登録情報信頼性確認部２２２は、データ取得部２２１が取得したブロック内の情報（登録情報）の信頼性を、該登録情報に付されている署名を基に確認する。なお、登録情報信頼性確認部２２２は、ブロック内に複数の署名が含まれている場合には、指定された署名の署名対象データについてそれぞれ当該署名の復号結果との照合により信頼性を確認する。このとき、入れ子構造で指定された署名が入れ子構造で付されている場合には、署名を付した際の暗号化処理の順番とは逆向きに復号処理を行って、各署名の署名対象データと当該署名の復号結果とを照合して最終的な信頼性を確認すればよい。
【０１０９】
元データ一致性確認部２２３は、データ取得部２２１が利用者の個人情報１４Ｄを得て、その個人情報１４Ｄのハッシュ値とされる個人情報Ｈａｓｈ３２Ｄを含むブロックを取得した場合に、該ブロック内の個人情報Ｈａｓｈ３２Ｄの元データとされる個人情報と、取得した個人情報１４Ｄとの一致性を確認する。元データ一致性確認部２２３は、例えば、データ取得部２２１が得た個人情報１４Ｄから算出されるハッシュ値と、ブロック内の個人情報Ｈａｓｈ３２Ｄとを照合することにより、ブロック内の個人情報Ｈａｓｈ３２Ｄの元データとされる個人情報と、取得した個人情報１４Ｄとの一致性を確認すればよい。
【０１１０】
個人情報正当性確認部２２４は、データ取得部２２１が対象確認に用いる個人情報（第１の個人情報）を得た場合に、その第１の個人情報の正当性を確認する。個人情報正当性確認部２２４は、現在の利用者（開示者）の生体情報・「本人確認が可能な情報」・「本システムにおいてユーザ認証が可能な情報」など第１の個人情報が正しいことを当該確認機関において確認できる第２の個人情報をデータ取得部２２１にさらに取得させ、それらを基に、第１の個人情報の正当性を確認する。
【０１１１】
結果出力部２２５は、登録情報信頼性確認部２２２、元データ一致性確認部２２３、個人情報正当性確認部２２４による確認結果や、それらを基に判定される、開示された情報の正当性の判定結果や、最終的な対象確認の結果を出力する。なお、最終的な対象確認は、登録情報信頼性確認部２２２、元データ一致性確認部２２３、個人情報正当性確認部２２４による確認結果や、それらを基に判定される開示された情報の正当性の判定結果の出力を基に、確認機関側のユーザが行ってもよい。その場合、確認部２０２は、該ユーザが行った対象確認結果を受け付ける。
【０１１２】
確認記録登録部２２６は、結果出力部２２５が得た結果を基に、確認記録ブロックをブロックチェーン３に登録する。また、確認記録登録部２２６は、必要に応じて、利用者側システム１０に該確認記録ブロックの情報を出力する。
【０１１３】
また、図７は、台帳管理ノード３０１の構成例を示すブロック図である。図７に示す台帳管理ノード３０１は、登録情報受付部３１１と、ブロック生成部３１２と、ブロック共有部３１３と、情報記憶部３１４と、ブロック検証部３１５とを含む。
【０１１４】
登録情報受付部３１１は、外部ノードから、台帳管理システム３０が管理するブロックチェーンである台帳に記録する情報を受け付ける。本実施形態では、登録情報受付部３１１は、例えば、台帳に記録する情報として、登録ブロックの内容（ブロックデータ）や、確認記録ブロックの内容（ブロックデータ）を受け付ける。
【０１１５】
ブロック生成部３１２は、登録情報受付部３１１が受け付けた情報（ブロックデータ）を基に、ブロックチェーンに追加するブロックを生成する。ブロック生成部３１２は、前ブロックに基づく情報と登録情報受付部３１１が受け付けた情報とを含むブロックを生成する。また、ブロック生成部３１２は、自身が生成したブロックまたは後述するブロック共有部３１３を介して他の台帳管理ノード３０１が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン（ブロックチェーン３のコピーに相当）にブロックを追加する。なお、ブロック生成部３１２が生成したブロックに対して、複数の台帳管理ノード３０１が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン３に追加されるブロックとなる。
【０１１６】
ブロック共有部３１３は、台帳管理システム３０に属する台帳管理ノード３０１間で情報交換を行う。ブロック共有部３１３は、より具体的には、登録情報受付部３１１が受け付けた情報や、ブロック生成部３１２が生成したブロックや、他の台帳管理ノード３０１から受け付けたブロック等を、適宜他の台帳管理ノード３０１に送信する。これにより、可能な限り全ての台帳管理ノード３０１でこれらの情報および最新のブロックチェーン３を共有する。
【０１１７】
情報記憶部３１４は、ブロックチェーン３のコピーを記憶する。なお、情報記憶部３１４は、ブロックチェーン３のコピー以外にも、例えば、後述するブロック検証部３１５での検証処理に必要となる情報などを記憶してもよい。
【０１１８】
ブロック検証部３１５は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の情報の検証を行う。通常、追加対象とされるブロックは、自ノードを含む台帳管理ノード３０１群において最も早く規則が満たされたブロックであるが、悪意のある台帳管理ノード３０１が含まれていた場合等を考慮して、実際に規則が満たされているか等を検証してもよい。
【０１１９】
なお、図７の構成はあくまで一例であって、台帳管理ノード３０１は、改ざんが困難なブロックチェーン３を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。
【０１２０】
次に、本実施形態の動作を説明する。本実施形態の動作は、登録ブロックをブロックチェーンに登録する登録フェーズと、ブロックチェーンに登録された登録ブロックや過去の確認記録ブロックを基に対象確認を行う確認フェーズの２つに大別される。さらに、確認フェーズは、利用者に個人情報を開示させて、ブロックチェーン３内の登録ブロックを基に対象確認を行う第１の確認フェーズと、利用者に個人情報を開示させずに、ブロックチェーンに３内の確認記録ブロックを基に対象確認を行う第２の確認フェーズの２つに大別される。
【０１２１】
まず、図８を参照して、登録フェーズにおける個人情報管理システムの動作を説明する。図８は、本実施形態の個人情報管理システムの登録フェーズにおける動作の一例を示すフローチャートである。なお、図８に示す登録フェーズは、確認機関によって元データとされる個人情報の正当性確認を行わずに登録ブロックを登録する場合の例である。
【０１２２】
図８に示す例では、まず、利用者側システム１０の登録部１０２が、データ記憶部１０１から個人ＩＤ１３Ｄおよび登録したい個人情報１４Ｄを読み出し、それぞれについてハッシュ値を算出して、個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄを得る（ステップＳ１０１）。登録部１０２は、ユーザ認証を行った上で、個人ＩＤ１３Ｄや個人情報１４Ｄへのアクセスを行ってもよい。
【０１２３】
次いで、登録部１０２は、そのようにして得た個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄを付し、該本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄが登録された登録ブロックを作成する（ステップＳ１０２）。
【０１２４】
次いで、登録部１０２は、作成した登録ブロックの追加要求を台帳管理ノード３０１に行って、該登録ブロックをブロックチェーン３に登録する（ステップＳ１０３）。このとき、登録部１０２は、登録された登録ブロックのキー情報を台帳管理ノード３０１から取得して、データ記憶部１０１に登録履歴として保持してもよい。
【０１２５】
このようにして、ブロックチェーン３に、利用者本人の署名３３Ｄが付された、利用者の個人ＩＤ１３Ｄのハッシュ値である個人ＩＤ＿Ｈａｓｈ３１Ｄおよび利用者の個人情報１４Ｄのハッシュ値である個人情報Ｈａｓｈ３２Ｄを登録情報として含む登録ブロックが追加される。
【０１２６】
また、図９は、本実施形態の個人情報管理システムの登録フェーズにおける動作の他の例を示すフローチャートである。なお、図９に示す登録フェーズは、確認機関によって元データとされる個人情報の正当性確認を行った上で登録ブロックを登録する場合の例である。
【０１２７】
図９に示す例では、まず、利用者側システム１０の登録部１０２が、データ記憶部１０１から登録したい個人情報１４Ｄ（第１の個人情報）を読み出す（ステップＳ１１１）。
【０１２８】
次いで、登録部１０２は、発行元の確認機関側システム２０の確認部２０２に、第１の個人情報と、必要であれば第２の個人情報とを含む、個人情報の正当性確認要求を送信する（ステップＳ１１２）。
【０１２９】
確認部２０２（例えば、個人情報正当性確認部２２４）は、個人情報の正当性確認要求を受信すると、それに含まれる第１の個人情報の正当性を、第２の個人情報を基に確認する（ステップＳ１１３）。また、確認部２０２は、第１の個人情報の正当性が確認できた場合に、そのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）を算出し、得られたハッシュ値に確認機関の署名３５Ｄを付して、要求元に確認結果とともに送信する（ステップＳ１１４〜ステップＳ１１６）。
【０１３０】
登録部１０２は、個人情報の正当性の確認が得られた場合、個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を算出し（ステップＳ１１７）、得られたハッシュ値に本人の署名３３Ｄを付す。そして、本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄと確認機関の署名３５Ｄが付された個人情報Ｈａｓｈ３２Ｄとが登録された登録ブロックを作成する（ステップＳ１１８）。なお、作成した登録ブロックのブロックチェーン３への登録処理は、ステップＳ１０３と同様でよい。
【０１３１】
次に、図１０を参照して、確認フェーズにおける個人情報管理システムの動作を説明する。図１０は、本実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。なお、図１０に示す確認フェーズは、利用者に個人情報を開示させて、ブロックチェーン３内の登録ブロックを基に対象確認を行う第１の確認フェーズの例である。
【０１３２】
図１０に示す例では、まず確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、利用者側システム１０に個人ＩＤの開示要求を送信する（ステップＳ２０１）。
【０１３３】
個人ＩＤの開示要求を受けた利用者側システム１０の開示部１０３は、データ記憶部１０１から個人ＩＤ１３Ｄを読み出し、要求元に送信する（ステップＳ２０２、ステップＳ２０３）。
【０１３４】
個人ＩＤ１３Ｄを受信した確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、得られた個人ＩＤ１３Ｄのハッシュ値を含む確認記録ブロックをブロックチェーン３から検索する（ステップＳ２０４）。データ取得部２２１は、ステップＳ２０３で開示部１０３から、個人ＩＤ１３Ｄとともに同様の目的の対象確認の記録を示す確認記録ブロックの情報を取得し、それらを基に確認記録ブロックを検索してもよい。なお、開示部１０３は、例えば、そのようなブロックの情報を利用者側システム１０が保持している登録履歴より得てもよい。
【０１３５】
検索の結果、所望の確認記録ブロック（例えば、同一の目的での確認結果を示す確認情報３４Ｄを含む確認記録ブロック）が見つからなかった場合、データ取得部２２１は、さらに、対象確認に必要な個人情報の開示要求を開示部１０３に送信する（ステップＳ２０５）。該開示要求には要求する個人情報の種別が含まれていてもよい。
【０１３６】
開示部１０３は、個人情報の開示要求を受信すると、要求された種別の個人情報（ここでは、第１の個人情報）を読み出し、要求元に送信する（ステップＳ２０６、ステップＳ２０７）。このとき、開示部１０３は、利用者に該個人情報の開示の許可を取った上で、要求元に送信してもよい。
【０１３７】
データ取得部２２１は、第１の個人情報を取得すると、そのハッシュ値である個人情報Ｈａｓｈ３２Ｄ（以下、個人情報Ｈａｓｈ３２Ｄ−１と記す）が登録された登録ブロックをブロックチェーン３から検索する（ステップＳ２０８）。データ取得部２２１は、ステップＳ２０７で開示部１０３から、個人情報とともにそのハッシュ値が登録された登録ブロックの情報を取得し、それらを基に登録ブロックを検索してもよい。
【０１３８】
検索の結果、所望の登録ブロックを得ると、確認部２０２の登録情報信頼性確認部２２２は、登録ブロックに含まれる、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ−１について、それらに付された署名を基に、その信頼性を確認する（ステップＳ２０９：登録情報の信頼性確認）。なお、登録情報の信頼性の確認方法は上述した通りである。
【０１３９】
また、確認部２０２の元データ一致性確認部２２３は、登録ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ−１について、それらの元データが、取得された個人ＩＤ１３Ｄおよび第１の個人情報と一致するかを、ハッシュ値同士の照合により確認する（ステップＳ２１０：元データの一致性確認）。なお、元データの一致性確認の方法は上述した通りである。
【０１４０】
なお、ステップＳ２０８で、データ取得部２２１は、第１の個人情報の正当性の確認記録を示す確認記録ブロックを検索してもよい。
【０１４１】
その場合、ステップＳ２０９の登録情報の信頼性確認処理では、確認記録ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄについて、それらに付された署名を基に、その信頼性を確認すればよい。また、ステップＳ２１０の元データの一致性確認処理では、開示された第１の個人情報との比較対象とする個人情報Ｈａｓｈ３２Ｄ−１を、確認記録ブロックの確認情報３４Ｄを基に取得すればよい。例えば、データ取得部２２１は、確認情報３４Ｄにおいて示される正当性の確認対象とされたハッシュ値（個人情報Ｈａｓｈ３２Ｄ−１）を取得してもよい。また、例えば、データ取得部２２１は、確認情報３４Ｄに、正当性の確認対象とされたハッシュ値（個人情報Ｈａｓｈ３２Ｄ−１）が登録されている登録ブロックの情報（後述するＴｘＩＤ等）が含まれている場合は、該情報から該登録ブロックを検索し、検索された登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄ−１を取得してもよい。
【０１４２】
なお、検索の結果、所望の登録ブロックや確認記録ブロックが発見されなかった場合は、対象確認に用いる個人情報が未登録である旨を、利用者側システム１０に送信して、処理を終了してもよい。
【０１４３】
また、確認部２０２（例えば、個人情報正当性確認部２２４）は、登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄ−１に、例えば発行元や正規情報保持機関などの所定の条件を満たす確認機関の署名３５Ｄが付されていない場合、第１の個人情報について正当性確認を行ってもよい。
【０１４４】
例えば、個人情報正当性確認部２２４は、正当性確認に必要な情報（正当性確認情報）の開示要求を開示部１０３に送信する（ステップＳ２１１）。該開示要求には要求する個人情報の種別が含まれていてもよい。
【０１４５】
開示部１０３は、正当性確認情報の開示要求を受信すると、要求された種別の個人情報（ここでは、正当性確認情報とされる第２の個人情報）を読み出し、要求元に送信する（ステップＳ２１２、ステップＳ２１３）。ステップＳ２０６と同様、開示部１０３は、利用者に該個人情報の開示の許可を取った上で、要求元に送信してもよい。
【０１４６】
個人情報正当性確認部２２４は、正当性確認情報とされる第２の個人情報を取得すると、第２の個人情報に基づいて第１の個人情報の正当性を確認する（ステップＳ２１４：個人情報の正当性確認）。なお、個人情報の信頼性確認の方法は上述した通りである。ここで、データ取得部２２１が、さらに第２の個人情報のハッシュ値が登録された登録ブロックや、現在の利用者の生体情報などを取得してもよい。
【０１４７】
なお、ステップＳ２１１〜ステップＳ２１４の処理は、個人情報Ｈａｓｈ３２Ｄ−１が登録されている登録ブロックにおいて、該個人情報Ｈａｓｈ３２Ｄ−１に、所定の条件を満たす確認機関の署名３５Ｄが付されている場合は省略される。その場合、確認部２０２は、そのままステップＳ２１４の個人情報の正当性の確認結果を、確認ＯＫとすればよい。
【０１４８】
次いで、確認部２０２の結果出力部２２５は、これまでの処理結果から、開示された第１の個人情報の正当性の判定結果や、最終的な対象確認の結果を出力する（ステップＳ２１５）。
【０１４９】
結果出力部２２５は、例えば、ステップＳ２０９の登録情報の信頼性確認、ステップＳ２１０の元データの一致性確認およびステップＳ２１４の個人情報の正当性確認の結果がいずれもＯＫであった場合、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報であると判定してもよい。なお、いずれかの確認結果がＮＧであった場合、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報でないと判定してもよい。また、例えば、結果出力部２２５は、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報であると判定された場合において、その第１の個人情報に基づいて、当該確認機関が目的とする対象確認を行い、その確認結果を出力してもよい。対象確認の例として、年齢確認や、サービスの受給資格確認などが挙げられる。ここで、サービスの受給資格確認の一例として、開示された第１の個人情報で特定される、確認機関側システム内のユーザ情報（決済情報等）との照合が挙げられる。
【０１５０】
次いで、確認機関側システム２０（例えば、図示しないサービス提供部）は、結果出力部２２５から出力される、開示された第１の個人情報の正当性（本人確認を含む）の判定結果や、対象確認結果を基に、利用者にサービスを提供してもよい（ステップＳ２１６）。
【０１５１】
次いで、確認記録登録部２２６が、今回の確認の記録を示す確認記録ブロックを作成し、該ブロックをブロックチェーン３に登録する（ステップＳ２１７、ステップＳ２１８）。確認記録登録部２２６は、例えば、上記の登録ブロック内の個人情報Ｈａｓｈ３２Ｄ−１について所定の対象確認ＯＫの旨や、本人確認ＯＫの旨を示す確認情報３４Ｄを生成する。また、確認記録登録部２２６は、例えば、ステップＳ２０３で取得した個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を算出する。そして、そのようにして得た個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄに対して当該確認機関の署名３５Ｄを生成し、該確認機関の署名３５Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄを含む確認記録ブロックを作成してもよい。なお、ブロックの登録処理は、ステップＳ１０３と同様でよい。
【０１５２】
このようにして、例えば１回目の対象確認が行われると、ブロックチェーン３に、その対象確認を行った確認機関の署名３５Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄと個人情報Ｈａｓｈ３２Ｄ−１に対する確認結果を示す確認情報３４Ｄとを含む確認記録ブロックが追加される。
【０１５３】
次に、図１１を参照して、確認フェーズにおける個人情報管理システムの動作を説明する。図１１は、本実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。なお、図１１に示す確認フェーズは、利用者に個人情報を開示させずに、ブロックチェーンに３内の確認記録ブロックを基に対象確認を行う第２の確認フェーズの例である。
【０１５４】
図１１に示す例でも、まず確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、利用者側システム１０に個人ＩＤの開示要求を送信する（ステップＳ２０１）。なお、ステップＳ２０１〜ステップＳ２０４までの処理は、第１の確認フェーズと同様でよい。
【０１５５】
本例では、検索の結果、所望の確認記録ブロック（例えば、同一の目的での確認結果を示す確認情報３４Ｄを含む確認記録ブロック）を得る。
【０１５６】
次いで、確認部２０２の登録情報信頼性確認部２２２は、確認記録ブロックに含まれる、個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄについて、それらに付された確認機関の署名３５Ｄを基に、その信頼性を確認する（ステップＳ２０９：登録情報の信頼性確認）。
【０１５７】
次いで、確認部２０２の結果出力部２２５は、これまでの処理結果から、最終的な対象確認の結果を出力する（ステップＳ２１５）。本例では、結果出力部２２５は、ステップＳ２０９の登録情報の信頼性確認の結果がＯＫであれば、確認記録ブロックの確認情報３４Ｄに含まれる確認結果が過去に得られていることを出力したり、過去の対象確認結果をそのまま援用してもよい。このとき、結果出力部２２５は、自身以外の確認機関による確認記録であった場合、そのまま援用せずに、対象確認を行った確認機関やその確認内容を出力した上で、確認機関側ユーザに対象確認結果の援用可否を問い合わせてもよい。
【０１５８】
援用可であった場合、確認機関側システム２０（例えば、図示しないサービス提供部）は、その対象確認結果を基に、利用者にサービスを提供してもよい（ステップＳ２１６）。なお、援用不可であった場合は、図１０に示すステップＳ２０５以降の処理を行えばよい。
【０１５９】
本例でも、確認記録登録部２２６が、今回の確認の記録を示す確認記録ブロックを作成し、該ブロックをブロックチェーン３に登録してもよい（ステップＳ２１７、ステップＳ２１８）。確認記録登録部２２６は、例えば、取得した個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と、援用した確認記録ブロックの情報や対象確認結果を示す確認情報３４Ｄとに対して当該確認機関の署名３５Ｄを付し、確認記録ブロックを生成してもよい。
【０１６０】
このようにして、例えば２回目の対象確認が行われると、ブロックチェーン３に、その対象確認を行った確認機関の署名３５Ｄが付された、利用者の個人ＩＤ１３Ｄのハッシュ値である個人ＩＤ＿Ｈａｓｈ３１Ｄ、および援用した確認記録ブロックの情報や対象確認結果を示す確認情報３４Ｄとに対して当該確認機関の署名３５Ｄを含む確認記録ブロックが追加される。
【０１６１】
なお、３回目以降は、例えば、２回目の対象確認の記録を示す確認記録ブロックの登録情報の信頼性を確認した上で、その確認情報３４Ｄに示される情報から得られる対象確認結果等を利用することができる。例えば、援用した確認記録ブロック（３回目であれば、１回目の対象確認の記録を示す確認記録ブロック）の情報が取得された場合には、さらに、その援用した確認記録ブロックを取得し、その登録情報の信頼性確認や確認情報の検証を行い、援用の可否を問い合わせてもよい。
【０１６２】
また、図１２は、確認フェーズにおける確認機関側システム２０の動作をまとめたフローチャートである。図１２に示すように、確認部２０２のデータ取得部２２１は、まず利用者（より具体的には利用者側システム１０）から個人ＩＤ１３Ｄを取得する（ステップＳ３０１）。
【０１６３】
次いで、データ取得部２２１は、ブロックチェーン３から、その利用者の過去の確認記録ブロックを検索する（ステップＳ３０２）。
【０１６４】
同様の目的での確認記録を示す確認記録ブロックが存在した場合（ステップＳ３０３のＹｅｓ）、その確認記録ブロックの登録情報を取得した上で、ステップＳ３１０に進む。
【０１６５】
そのような確認記録ブロックが存在しなかった場合（ステップＳ３０３のＮｏ）、データ取得部２２１は、対象確認に用いる個人情報（第１の個人情報）の開示を利用者に要求する（ステップＳ３０３）。
【０１６６】
第１の個人情報を取得すると、ブロックチェーン３から、個人情報Ｈａｓｈ３２Ｄ−１が登録された登録ブロックまたは登録済みの個人情報Ｈａｓｈ３２Ｄ−１の元データに対して本人確認を行った記録を示す確認記録ブロックを検索する（ステップＳ３０４）。
【０１６７】
そのような登録ブロックや確認記録ブロックが確認されると、そのブロックの登録情報を取得した上で、ステップＳ３０５に進む。
【０１６８】
ステップＳ３０５では、取得された登録情報における、個人情報Ｈａｓｈ３２Ｄ−１に付されている確認機関の署名３５Ｄの有無や、取得された登録情報に含まれる確認情報３４Ｄの確認結果などから、ブロックチェーン３に登録されている個人情報Ｈａｓｈ３２Ｄ−１に関し、過去にその元データ（第１の個人情報）の正当性が確認されているか否かを確認する。
【０１６９】
元データ（第１の個人情報）の正当性が確認済みでなければ（ステップＳ３０５のＮｏ）、データ取得部２２１は、第１の個人情報の正当性を確認できる第２の個人情報（正当性確認情報）の開示をさらに利用者に要求する（ステップＳ３０６）。
【０１７０】
そして、個人情報正当性確認部２２４が、取得された第２の個人情報を基に、利用者から取得した第１の個人情報の正当性を確認する（ステップＳ３０７）。第１の個人情報の正当性の確認が終わると、ステップＳ３１１に進む。
【０１７１】
一方、元データ（第１の個人情報）の正当性が確認済みであれば（ステップＳ３０５のＹｅｓ）、データ取得部２２１は、ブロックチェーン３に登録されている、元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１を取得した上で、ステップＳ３０８に進む。
【０１７２】
ステップＳ３０８では、元データ一致性確認部２２３が、ブロックチェーン３内の元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとされる第１の個人情報（登録時の個人情報）と、利用者から取得した第１の個人情報との一致性を確認する。元データ一致性確認部２２３は、利用者から取得した第１の個人情報からハッシュ値を算出し、それとブロックチェーン３内の元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１とが一致するかを確認すればよい。
【０１７３】
正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとの一致性が確認されなかった場合（ステップＳ３０９のＮｏ）、そのままステップＳ３１１に進む。
【０１７４】
一方、正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとの一致性が確認された場合（ステップＳ３０９のＹｅｓ）、ステップＳ３１０に進む。
【０１７５】
ステップＳ３１０では、登録情報信頼性確認部２２２が、これまでの判定に用いた情報の取得先である登録情報（ステップＳ３０３の確認記録ブロックやステップＳ３０４の登録ブロックまたは確認記録ブロックの登録情報等）について、それに付された署名を用いた信頼性確認を行う。なお、登録情報信頼性確認部２２２は、登録情報の一部の情報を取得した場合、少なくとも該情報と、該情報と対応づけられている個人ＩＤ＿Ｈａｓｈ３１Ｄについて、信頼性確認を行う。
【０１７６】
また、本例では、先に個人情報の正当性確認の有無を判定した上で、個人情報の正当性確認、または元データとの一致性確認および登録情報の信頼性確認を行う例を示したが、これら確認の順番は特に問わない。例えば、ブロックの登録情報から情報（確認情報３４Ｄや個人情報Ｈａｓｈ３２Ｄ−１等）を取得する度に、該情報と、それと対応づけられた個人ＩＤ＿Ｈａｓｈ３１Ｄとについて同ブロック内においてそれらに付された署名を用いて信頼性を確認してもよい。
【０１７７】
また、ステップＳ３１１では、これまでの確認結果や、それに基づく開示された情報の正当性の判定結果や、最終的な対象確認の結果を出力する。なお、同様の目的での確認記録ブロックが発見された場合には、その確認結果の援用有無を問い合わせてもよい。また、これまでの確認結果や、開示された情報の正当性の判定結果を出力した上で、確認機関側ユーザから、対象確認結果を受け付けてもよい。
【０１７８】
また、確認部２０２は、対象確認に複数の個人情報が必要な場合にそれらについて未取得な情報または正当性が未確認な情報があるなど、対象確認が完了していない場合（ステップＳ３１２のＮｏ）は、ステップＳ３０３に戻る。そして、必要な個人情報の要求を利用者に行ってもよい。なお、確認部２０２は、対象確認が完了したか否かを、確認機関側ユーザから受け付けることで判定してもよい。
【０１７９】
一方、確認部２０２は、対象確認が完了した場合には（ステップＳ３１２のＹｅｓ）、今回の確認の記録を示す確認記録ブロックを作成し、ブロックチェーン３に登録して処理を終了する（ステップＳ３１４）。
【０１８０】
以上のように、本実施形態によれば、元データの正当性の確認記録や様々な目的での確認記録がブロックチェーン３内に登録されていくことで、一つの個人ＩＤを開示するだけで、免許証やパスポートに代わる本人確認を行うことができるようになる。このため、利用者は目的や用途ごとに本人確認の手続きをする必要がなくなる。
【０１８１】
例えば、単に個人ＩＤを開示するだけではその個人ＩＤの所有者の身元や要求されたサービスを享受できる権限（受給資格）の有無は確認できない。しかし、本実施形態によれば、例えば一度目の個人ＩＤの開示において、サービスの受給資格があるか、また必要であればその個人ＩＤの所有者が誰であるかの確認（本人確認）を、その個人ＩＤに対応づけられている個人情報を基に確認し、当該確認に用いた情報の正しさを示すハッシュ値やその結果を確認者の署名とともに、ブロックチェーン３に記録をする。そして、二度目以降の同様のサービスを利用するシーンにおいて、サービス提供側で過去の確認結果を確認、その内容を検証することで、同様の確認結果を与えられるようにしている。
【０１８２】
例えば、ある利用者が、年齢情報である生年月日や成人か否かの情報について、所定の確認機関に正当性（その個人ＩＤが示す利用者本人の正しい情報であること）を確認させた上で、そのハッシュ値を個人ＩＤのハッシュ値と対応づけてブロックチェーンに登録していた場合を想定する。
【０１８３】
そのような場合に、ある店舗Ａでお酒を購入するシーンにおいて、一度目は、個人ＩＤ開示後に年齢情報の開示要求がなされ、利用者の許可の下、その年齢情報である生年月日や成人か否かの情報が店舗側に開示される。
【０１８４】
店舗Ａでは、開示された情報の正当性を、ブロックチェーンの記録を基に確認できる。このため、店舗Ａでは、開示された情報（生年月日や成人か否かの情報）だけで、年齢確認を行ってお酒を提供できる。このとき、店舗Ａは、年齢確認の結果（成人である旨の確認結果）を、開示された個人ＩＤのハッシュ値とともに自身の署名を付してブロックチェーンに記録する。
【０１８５】
次に、別の店舗Ｂでお酒を購入するシーンにおいて、同種の年齢確認について二度目となるケースでは、個人ＩＤを開示後、店舗Ｂにより年齢情報の開示要求がなされた場合に、利用者は、年齢情報の開示に代えて１回目の年齢確認の結果が記録された確認記録ブロックの情報を開示できる。店舗Ｂでは、開示された情報を基に、１回目の年齢確認の結果をブロックチェーンから取得することで、この個人ＩＤが店舗Ａで既に同種の年齢確認がされ、サービス提供を受けていることを確認できる。なお、店舗Ｂは、確認の記録の開示ではなく、二度目の確認においても、本人確認の情報開示を要求することもできる。これらはサービス提供側のポリシーによって定められるが、同様のサービス提供であれば、二度目の開示が確認記録の開示で済む場合も多く考えられる。
【０１８６】
このようにして、利用者は、サービス利用にあたって、本人確認のために免許証などの複数の個人情報を含む情報を開示する代わりに、種々の個人情報と互いのハッシュ値を経由して対応づけられている１つの個人ＩＤを開示するだけで、当該個人ＩＤと対応づけられている個人情報またはそれを用いた確認記録を開示したと同等の利益を享受できるようになる。したがって、本システムのサービスを複数のベンダやサービスで共有すれば、サービスごとやベンダごとに個人を識別する情報が増えるのを防止できる。
【０１８７】
また、本実施形態によれば、一度、元の個人情報の正当性が確認され、その記録がブロックチェーンに登録されていれば、１回目においても、年齢確認のために必要な情報（生年月日等）の正当性を確認するために年齢確認とは関係ない不必要な個人情報（免許証番号や名前、住所など）を開示することを防止できる。このように、本実施形態によれば、個人ＩＤに対応づけられた個人情報を選択的に開示することができるので、確認に必要最小限な情報のみを開示するといったコントロールが可能となる。
【０１８８】
なお、本実施形態では、各ブロックに個人ＩＤのハッシュ値を登録するようにしているため、サーバダウンなどによるサービスの停止が想定されないブロックチェーンの特性上、利用開始時に発行された個人ＩＤは、利用者や管理者の意志によって無効としない限り、永続的に使用できる。
【０１８９】
なお、これは、クライアントデバイスにおいて個人ＩＤが認証情報とともに対応づけられていた場合、クライアントデバイスの紛失によって登録された記録は書き換えられないことを意味する。このため、仮にクライアントデバイスが紛失した場合には、次のような方法によって個人ＩＤをリカバリできるようにしてもよい。
【０１９０】
第１の方法としては、本システム利用開始時に個人ＩＤを割り当てる際、当該個人ＩＤとその認証情報としてのデバイスＩＤとの組に対して複数の認証メンバを登録しておく方法が挙げられる。利用者は、デバイス紛失した場合、認証メンバに新たなデバイスＩＤを通知する。このとき、一定数の認証メンバの承認により新たなデバイスＩＤで当該個人ＩＤを再利用可能としてもよい。当該方法は、ｕＰｏｒｔと呼ばれるブロックチェーンのＩＤ管理プラットフォームを利用して実現してもよい。
【０１９１】
より具体的には、利用者に対してブロックチェーンネットワークにおけるユーザキーとして、ｕＰｏｒｔＩＤと呼ばれる、Ｐｒｏｘｙコントラクトのアドレスとなる永続的なＩＤを用意する。なお、ｕＰｏｒｔＩＤは、ＵｓｅｒＡｄｄｒｅｓｓからＰｒｉｖａｔｅＫｅｙを用いて作成される。ここで、ＵｓｅｒＡｄｄｒｅｓｓは、ユーザデバイスキーと対応するＥＯＡ（Ｅｔｈｅｒｅｕｍアカウント）のアドレスに相当する。また、本例においてクライアントデバイスに相当するｕＰｏｒｔデバイスは、デバイスＩＤとペアとなるＵｓｅｒＡｄｄｒｅｓｓ（ＥＯＡ）と、秘密鍵とをもつ。
【０１９２】
このようなＥｈｔｅｒｅｕｍブロックチェーンネットワークを利用して、例えば、ユーザは、ｕＰｏｒｔデバイスを紛失した場合、まず新しいデバイスでＥｔｈｅｒｅｕｍに接続し、新しいＵｓｅｒＡｄｒｅｓｓを取得する。そして、新しいＵｓｅｒＡｄｒｅｓｓを、事前に登録された認証メンバ（リアルなｄｅｌｅｇａｔｅメンバ等）に通知する。
【０１９３】
認証メンバは、Ｒｅｃｏｖｅｒｙコントラクトを呼び出し、ユーザ確認を行うなどして、新しいＵｓｅｒＡｄｒｅｓｓを認証する。認証の結果、一定数以上の承認が得られた場合、新しいＵｓｅｒＡｄｒｅｓｓは、Ｃｏｎｔｒｏｌｌｅｒコントラクトに通知されて、古いＵｓｅｒＡｄｒｅｓｓと書き換えられる。
【０１９４】
これにより、Ｐｒｏｘｙコントラクトにおいてクライアントデバイスの識別情報として機能するＵＰｏｒｔＩＤは変わらずに、実際のデバイスＩＤと対応するＥＯＡのみを変更できる。このように、デイバスＩＤと対応するＥＯＡと、ブロックチェーン上のデータと対応するＰｒｏｘｙアドレスとを分断することで、デバイス紛失などによるクライアントデバイスの交換時にも既存のデータとの接続性を維持できる。ここで、ｕＰｏｒｔＩＤが上記の個人ＩＤに相当する。
【０１９５】
また、別の方法としては、本システム利用開始時に個人ＩＤを割り当てた際、その個人ＩＤのハッシュ値と対応づけて本人確認やユーザ認証が可能な個人情報のハッシュ値が登録された登録ブロックをブロックチェーンに追加させておく方法が挙げられる。当該方法では、新たなデバイスにそのような個人情報とそれが登録されたときの個人ＩＤとが登録された場合に、新たなデバイスに対して該個人情報と同等の登録情報を用いたユーザ認証を行うことで、新たなデバイスでの当該個人ＩＤを再利用可能としてもよい。
【０１９６】
例えば、電話番号であればＳＭＳ認証、メールアドレスであればそのメールアドレス宛てのメール送信、生体情報であれば現在の利用者の生体情報との比較などにより、新たなデバイスでのユーザ認証が通れば、新たなデバイスでその個人ＩＤを再利用可能としてもよい。
【０１９７】
実施形態２．
次に、第１の個人情報管理システムの具体的な利活用例をいくつか説明する。本実施形態では、チケットの転売防止に本実施形態の個人情報管理システムを利用した例としてチケットサービスシステムについて説明する。図１３は、第２の実施形態のチケットサービスシステムの概略構成図である。図１３に示すチケットサービスシステムは、個人用端末１０Ａと、サービス提供装置２１Ａと、入場装置２２Ａと、ブロックチェーンネットワーク（以下、ブロックチェーンＮＷという）３０Ａとを備える。
【０１９８】
ここで、個人用端末１０Ａは、上記の利用者側システム１０に相当する。また、サービス提供装置２１Ａは、上記の確認機関側システム２０であって、チケット情報の発行元の機関（チケットの販売会社等）の確認機関側システム２０に相当する。入場装置２２Ａは、チケット情報を基にチケット購入者の該場所（イベント会場等）への入退場をチェックする機関（コンサートの運営会社等）の確認機関側システム２０に相当する。入場装置２２Ａは、例えば、サービス提供装置２１Ａが発行したチケットが使用される場所に設置される。なお、サービス提供装置２１Ａと入場装置２２Ａとが、同じ機関の確認機関側システム２０に属していてもかまわない。また、ブロックチェーンＮＷ３０Ａは、上記の台帳管理システム３０に相当する。なお、図示省略しているが、ブロックチェーンＮＷ３０Ａは、本システムで使用可能なブロックチェーン３を実装する他、上記の管理側システム５０の機能（個人ＩＤの割当やペア鍵の生成等）を行う。なお、本例では、ブロックチェーン３においてブロックの作成者を識別する識別子（上記のｕＰｏｒｔＩＤ等）が個人ＩＤ１３Ｄを兼ねている。この場合、管理側システム５０の機能を個人用端末１０Ａが有していてもよい。
【０１９９】
本例において、個人用端末１０Ａには、本例における利用者側アプリケーションとして、利用者が本システムを利用してチケット購入サービスを受けるための手続きを行うチケット購入アプリケーションがダウンロードされている。チケット購入アプリケーションは、当該個人用端末１０ＡのＣＰＵ上で動作して、本システムにおける利用者側システム１０の所定の処理を当該個人用端末１０Ａに実行させる。なお、本例では、チケット購入アプリケーションのダウンロード時に、個人ＩＤの割当および鍵ペアの生成が行われるものとする。
【０２００】
また、サービス提供装置２１Ａには、本例における第１のサービス提供側アプリケーションとして、チケット情報管理アプリケーションが予め実装されているものとする。ここで、チケット情報管理アプリケーションは、利用者からの購入申請に応じて、ブロックチェーン３内の情報を利用した本人確認を含むチケットの購入資格の審査および入金確認を行いつつ、利用者に販売するための手続きを行うアプリケーションである。当該アプリケーションは、例えば、サービス提供装置２１ＡのＣＰＵ上で動作して、本システムにおける確認機関側システム２０の所定の処理を当該サービス提供装置２１Ａに実行させる。
【０２０１】
また、入場装置２２Ａには、本例における第２のサービス提供側アプリケーションとして、チケット情報確認アプリケーションが予め実装されているものとする。ここで、チケット情報確認アプリケーションは、利用者からの入退場申請に応じて、ブロックチェーン３内の情報を利用した本人確認を含む入退場資格の審査を行いつつ、利用者の入退場を管理するための手続きを行うアプリケーションである。当該アプリケーションは、例えば、入場装置２２ＡのＣＰＵ上で動作して、本システムにおける確認機関側システム２０の所定の処理を当該入場装置２２Ａに実行させる。
【０２０２】
次に、本例のチケットサービスシステムの動作を説明する。図１４は、本実施形態のチケットサービスシステムの動作の概略を示すフローチャートである。図１４に示すように、本例のチケットサービスシステムでは、まず、利用者が、本システムに対して本人登録を行う（ステップＳ４０１Ａ）。
【０２０３】
ステップＳ４０１Ａでは、利用者からの指示に応じて、個人用端末１０Ａが、チケット購入時および会場への少なくとも入場時に行われる本人確認のための生体情報（例えば、顔写真等）を取得するとともに、チケット購入時に必要とされる個人情報（例えば、住所、氏名、クレジットカード番号等）を読み出す。そして、個人用端末１０Ａは、それらの各々またはそれらの組み合わせである所定の開示単位についてハッシュ値を算出するとともに、当該利用者に割り当てられた個人ＩＤ１３Ｄについてハッシュ値を算出する。なお、各ブロック内において個人を特定するための情報として、個人ＩＤ＿Ｈａｓｈ３１Ｄではなく個人ＩＤ１３Ｄをそのまま用いることも可能である。その場合には、以降の処理において個人ＩＤ＿ｈａｓｈ３１Ｄを個人ＩＤと読み替えるとともに、個人ＩＤ＿ｈａｓｈ３１Ｄに対する信頼性確認処理を省略すればよい。なお、上記の実施形態においても同様とする。
【０２０４】
本例では、住所と氏名の組が、サービス提供装置２１Ａが提供するチケット購入サービスにおいてチケット購入時のユーザ情報として用いられ、クレジットカード番号が、同サービスにおいて決済情報として用いられることを想定している。なお、生体情報は、既に説明したように、チケット購入時および会場への少なくとも入場時に行われる本人確認情報として用いられることを想定している。
【０２０５】
以下、説明を簡単にするために、住所と氏名の組を個人情報１４Ｄ（１）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（１）と記す場合がある。また、決済情報としてのクレジットカード番号を個人情報１４Ｄ（２）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（２）と記す場合がある。また、生体情報を個人情報１４Ｄ（３）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（３）と記す場合がある。
【０２０６】
個人用端末１０Ａは、個人情報１４Ｄ（１），（２），（３）および個人ＩＤ１３Ｄについてそれぞれハッシュ値（個人情報Ｈａｓｈ３２Ｄ（１），（２），（３））を算出すると、それらとそれに付された本人の署名３３Ｄとを登録情報とする登録ブロックの追加要求をブロックチェーンＮＷ３０Ａに要求して、ブロックチェーン３に登録させる。
【０２０７】
ブロックチェーン３にブロックが登録されると、個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａから、ブロックチェーン３内においてその個人ＩＤ１３Ｄに関する情報のブロックを識別するトランザクションＩＤ（ＴｘＩＤ）を受信する。ステップＳ４０１Ａでは、当該個人ＩＤ１３Ｄにおける始めての登録ブロックであることを示す、ＴｘＩＤ＝１を受信する。
【０２０８】
本例のチケットサービスシステムでは、ブロックチェーン３内のブロックの指定を、このＴｘＩＤを用いて行う。したがって、個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａから得られる自身の個人ＩＤ１３ＤにおけるＴｘＩＤを登録履歴として保持しておく。個人用端末１０Ａは、登録履歴として、例えば、登録ブロックのＴｘＩＤと、少なくとも最新の確認記録ブロックのＴｘＩＤとを保持しておいてもよい。
【０２０９】
このようにして、生体情報を含む個人情報のハッシュ値が本人の署名３３Ｄとともに個人ＩＤ１３Ｄのハッシュ値と対応づけられた登録ブロックがブロックチェーン３に登録されると、本人登録が完了する。
【０２１０】
本人登録が完了すると、次いで、利用者は、サービス提供装置２１Ａに対してチケットの購入申請を行う（ステップＳ４０２Ａ）。ステップＳ４０２Ａでは、個人用端末１０Ａは、例えば、個人ＩＤ１３Ｄと購入したいチケットの情報とを含むチケット購入申請を、サービス提供装置２１Ａに送信する。
【０２１１】
チケット購入申請を受け付けたサービス提供装置２１Ａは、それに含まれる個人ＩＤ１３Ｄと、さらに申請者から直接開示される個人情報とを基に、利用者のブロックチェーン３内の登録情報を利用して、購入資格を確認する（ステップＳ４０３Ａ）。本例の個人情報管理システムレベルでの購入資格としては、チケット購入に必要な個人情報であって本人確認に用いられる生体情報と一緒にそれらのハッシュ値がブロックチェーン３内に登録されている個人情報（上記の個人情報１４Ｄ（１）（２））が開示されること、としている。ただし、一部の個人情報（本例では、個人情報１４Ｄ（１））については、ブロックチェーン３内に登録している過去の購入記録の開示で代替可能としている。なお、チケットサービスシステムレベルでの購入資格には、さらに開示された情報により決済が正常に行われることなどが追加される。
【０２１２】
また、例えば、入場時だけでなく、購入時にも本人確認を行いたい場合には、上記の購入資格に、さらに、申請者に対して開示された個人情報または過去の購入の際に開示した個人情報の所有者としての本人確認がとれること、を追加することも可能である。なお、これらはあくまで一例であり、サービス提供元で自由に定めればよい。
【０２１３】
本例のサービス提供装置２１Ａは、本例の購入資格の確認処理として、要求元の利用者（申請者）に対して、過去の購入記録を含めて少なくとも１度の個人情報１４Ｄ（１）の開示と、購入の度の個人情報１４Ｄ（２）の開示とを少なくとも要求し、開示された情報の正当性を確認する（ステップＳ４０３Ａ）。サービス提供装置２１Ａは、開示された情報について、ブロックチェーン３内の登録情報（確認記録を含む）との照合を行って、該情報の正当性を確認すればよい。なお、登録情報との照合には、上述したような元データの一致性確認や登録情報自体の信頼性確認も含まれる。
【０２１４】
なお、サービス提供装置２１Ａは、購入資格の確認処理において、申請者（より具体的には上記２つの個人情報を開示した開示者）に対して本人確認を行うこともできる。その場合、サービス提供装置２１Ａは、個人用端末１０Ａに、申請者の現在の生体情報をさらに開示させ、そのハッシュ値と、登録ブロックに登録されている個人情報Ｈａｓｈ３２Ｄ（３）とを比較して本人確認を行ってもよい。なお、生体情報によっては登録時と現在の情報が完全には一致しない場合があり、ハッシュ値での比較、照合が難しいことも考えられる。そのような場合には、登録された生体情報のハッシュ値である個人情報Ｈａｓｈ３２Ｄ（３）の元データ（登録時の生体情報）を開示させて、申請者の現在の生体情報との照合を行えばよい。なお、上記の本人確認を、個人用端末１０Ａ（より具体的には、確認機関側システムの確認部２０２の一部の機能を含むチケット購入アプリケーション）側で行うことも可能である。
【０２１５】
サービス提供装置２１Ａは、このようにして申請者の購入資格が確認されると、申請者にチケットを発行する。サービス提供装置２１Ａは、購入資格が確認されチケットを発行すると、確認情報３４Ｄとして、チケット発行情報（例えば、チケットが発行されたことや発行されたチケット情報やチケット発行時における購入資格の確認記録を示す情報）を含む確認記録ブロックをブロックチェーン３に登録する（ステップＳ４０４Ａ）。確認記録ブロックには、開示された個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）が含まれるとともに、該個人ＩＤ＿Ｈａｓｈ３１Ｄと該確認情報３４Ｄとに対してチケット情報の発行元である確認機関の署名３５Ｄが付される。なお、発行されたチケット情報自体はサービス提供装置２１Ａ側で保持しておき、確認記録ブロックには、そのチケット情報を識別する識別子（サービスＩＤ）を登録してもよい。
【０２１６】
確認記録ブロックの登録が完了すると、サービス提供装置２１Ａは、要求元の個人用端末１０Ａに、発行されたチケット情報として、サービスＩＤやそれが記録された確認記録ブロックのＴｘＩＤを返信する。
【０２１７】
次に、このようにして発行されたチケットを利用して、利用者が会場へ入場する場面を考える。本例では、利用者は、入場装置２２Ａに対して入場申請を行えばよい（ステップＳ４０５Ａ）。ステップＳ４０５Ａでは、個人用端末１０Ａは、例えば、個人ＩＤ１３Ｄと、サービス提供装置２１Ａから受信したチケット情報（サービスＩＤやそれが記録された確認記録ブロックのＴｘＩＤ等）とを含む入場申請を、入場装置２２Ａに送信する。
【０２１８】
入場申請を受け付けた入場装置２２Ａは、それに含まれる情報を基に、利用者のブロックチェーン３内の登録情報を利用して、入場資格を確認する（ステップＳ４０６Ａ）。本例の個人情報管理システムレベルでの入場資格としては、利用者に対してチケット発行情報を含む確認記録ブロックがブロックチェーン３に登録されており、かつ申請者に対して購入時に開示もしくは参照した個人情報の所有者としての本人確認がとれること、としている。なお、これらはあくまで一例であり、サービス提供元で自由に定めればよい。
【０２１９】
入場装置２２Ａは、本例の入場資格の確認処理として、開示されたチケット情報からチケット発行情報を含む確認記録ブロックの有無およびその登録情報の正当性を確認するとともに、申請者に対して本人確認を行う。確認記録ブロックの登録情報の正当性は、チケット情報の発行元とされる確認機関の公開鍵を利用して確認すればよい。なお、本人確認の方法は上述した方法と同様でよい。
【０２２０】
入場装置２２Ａは、このようにして申請者の入場資格が確認されると、ゲート（不図示）を開けたり、入場許可を示す情報を出力するなどの入場処理を行う。また、入場装置２２Ａは、入場資格が確認され入場処理を実施すると、確認情報３４Ｄとして、入場処理をした旨を示す入場情報を含む確認記録ブロックをブロックチェーン３に登録してもよい（ステップＳ４０７Ａ）。確認記録ブロックには、開示された個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）が含まれるとともに、該個人ＩＤ＿Ｈａｓｈ３１Ｄと該確認情報３４Ｄとに対してチケット情報の発行元である確認機関の署名３５Ｄが付される。
【０２２１】
なお、再入場の際も、入場申請と同様の方法で本人確認の上で入場処理を行ってもよい。なお、途中退場する際に退場記録をブロックチェーン３に登録しておき、さらにその情報との照合処理を行うことも可能である。
【０２２２】
なお、図１５〜図１８は、上記の本人登録時、購入申請時および入場申請時の処理の流れの一例を示すシーケンス図である。
【０２２３】
図１５は、本人登録時の処理の流れの一例を示すシーケンス図である。なお、本人登録の前に、個人ＩＤ１３Ｄの割り当てや、ペア鍵の発行は行われているものとする。
【０２２４】
図１５に示す例では、まず利用者が個人用端末１０Ａに対して個人情報の登録指示を行う（ステップＳ５０１）。個人情報の登録指示を受け付けると、個人用端末１０Ａは、個人情報１４Ｄ（１）（２）（３）を取得し、それらについて各々ハッシュ値を算出し、個人情報Ｈａｓｈ３２Ｄ（１）（２）（３）を得る（ステップＳ５０２）。
【０２２５】
次いで、個人用端末１０Ａは、個人ＩＤ１３Ｄと、個人情報Ｈａｓｈ３２Ｄ（１）（２）（３）と、それらに付す本人の署名３３Ｄとを含むブロック追加要求をブロックチェーンＮＷ３０Ａに送信する（ステップＳ５０３）。
【０２２６】
ブロックチェーンＮＷ３０Ａでは、ブロック追加要求に含まれる情報を登録情報として含むブロック（登録ブロック）をブロックチェーン３に追加する（ステップＳ５０４）。
【０２２７】
個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａからブロック追加応答を受信すると（ステップＳ５０５）、追加したブロックのＴｘＩＤ（本例では、ＴｘＩＤ＝１）を登録履歴に保持するとともに、以降の開示要求に備えて、登録時の個人情報すなわち登録ブロックの登録時の元データである個人情報１４Ｄ（１）（２）（３）を保存する（ステップＳ５０６）。その後、利用者に完了通知を行う（ステップＳ５０７）。
【０２２８】
また、図１６〜図１７は、購入申請時の処理の流れの一例を示すシーケンス図である。なお、図１７は、図１６のつづきである。図１６〜図１７に示す例では、まず利用者が、個人用端末１０Ａに対して購入申請の指示を行う（ステップＳ５１１）。このとき、購入したいチケットの情報が指定されてもよい。
【０２２９】
購入申請の指示を受け付けると、個人用端末１０Ａは、サービス提供装置２１Ａに、個人ＩＤ１３Ｄを含む購入申請を送信する（ステップＳ５１２）。
【０２３０】
個人用端末１０Ａからの購入申請を受けたサービス提供装置２１Ａは、まず要求元の個人用端末１０Ａに、個人情報１４Ｄ（１）を指定した個人情報の開示要求Ａを送信する（ステップＳ５１３）。
【０２３１】
個人情報の開示要求Ａを受信した個人用端末１０Ａは、例えば、登録履歴を検索して過去に当該チケットサービスシステム内において個人情報１４Ｄ（１）の開示や、それを伴う同等の対象確認（本例では購入資格確認）があったか否かを確認してもよい。
【０２３２】
過去に個人情報１４Ｄ（１）の開示も同等の対象確認もなければ、個人用端末１０Ａは、利用者の許可を得て、個人情報１４Ｄ（１）を開示する。本例では、個人用端末１０Ａは、個人情報１４Ｄ（１）と、その正当性を示す情報（個人情報Ｈａｓｈ３２Ｄ（１）と本人の署名３３Ｄ等）を含む登録ブロックのＴｘＩＤとを含む個人情報開示応答Ａを、サービス提供装置２１Ａに送信する（ステップＳ５１４）。
【０２３３】
個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報開示応答Ａに含まれるＴｘＩＤを基に、個人情報１４Ｄ（１）の登録ブロックを取得する（ステップＳ５１５）。そして、サービス提供装置２１Ａは、登録ブロックの登録情報の信頼性確認および元データの一致性確認（開示された個人情報１４Ｄ（１）と登録ブロック内の個人情報Ｈａｓｈ３２Ｄ（１）の元データ間の一致性確認）を行って、開示された個人情報１４Ｄ（１）の正当性を確認する（ステップＳ５１６）。このとき、サービス提供装置２１Ａは、個人情報１４Ｄ（１）の開示がされ、かつその正当性が確認されたことを示す購入資格確認Ａの記録を、確認記録ブロックにしてブロックチェーン３に登録してもよい。その結果として、該確認記録ブロックのＴｘＩＤ（本例では、ＴｘＩＤ＝２）を受信する（ステップＳ５１７、ステップＳ５１８）。
【０２３４】
一方、個人用端末１０Ａは、過去に個人情報１４Ｄ（１）の開示や同等の対象確認（本例では購入資格確認）があった場合、個人情報１４Ｄ（１）に代えて、そのときの確認記録ブロックのＴｘＩＤ（例えば、上記のＴｘＩＤ＝２や後述するＴｘＩＤ＝４等）を含む個人情報開示応答Ａを、サービス提供装置２１Ａに送信する（ステップＳ５１９）。
【０２３５】
個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報開示応答Ａに含まれるＴｘＩＤを基に、個人情報１４Ｄ（１）についての正当性確認結果や同等のサービス受給資格（チケット購入資格）を示す確認記録ブロックを取得する（ステップＳ５２０）。そして、サービス提供装置２１Ａは、確認記録ブロックの登録情報の信頼性確認を行って、その登録情報が示す確認結果を検証（援用判定）する（ステップＳ５２１）。
【０２３６】
本例では、自身の機関が登録した確認記録ブロックであれば、その登録情報の信頼性確認（作成者証明および非改ざん証明）がされれば、個人情報１４Ｄ（１）の開示は省略可能とする。ステップＳ５２１の確認についても、サービス提供装置２１Ａは、指定された確認記録ブロックの確認結果により個人情報１４Ｄ（１）の正当性が確認されたことを示す購入資格確認Ａの記録を、確認記録ブロックにしてブロックチェーン３に登録してもよい。その結果として、該確認記録ブロックのＴｘＩＤを受信する（ステップＳ５２２、ステップＳ５２３）。
【０２３７】
個人情報１４Ｄ（１）の開示および／または正当性確認が完了すると、サービス提供装置２１Ａは、要求元の個人用端末１０Ａに、決済情報としての個人情報１４Ｄ（２）を指定した個人情報の開示要求Ｂを送信する（ステップＳ５２４）。なお、本例では、決済情報としての個人情報１４Ｄ（２）は確認記録での開示は認められない。
【０２３８】
個人情報の開示要求Ｂを受信した個人用端末１０Ａは、利用者の許可を得て、個人情報１４Ｄ（２）を開示する。本例でも、個人用端末１０Ａは、個人情報１４Ｄ（２）と、その正当性を示す情報（個人情報Ｈａｓｈ３２Ｄ（２）と本人の署名３３Ｄ等）を含む登録ブロックのＴｘＩＤとを含む個人情報開示応答Ｂを、サービス提供装置２１Ａに送信する（ステップＳ５２５）。
【０２３９】
個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報１４Ｄ（１）を受信した場合と同様の正当性確認の行い、その記録をブロックチェーン３に追加する（ステップＳ５２６〜ステップＳ５２９）。
【０２４０】
サービス提供装置２１Ａは、このようにして個人情報１４Ｄ（１）の正当性が少なくとも確認され、かつ正当な個人情報１４Ｄ（２）が取得されたことを受けて、購入資格の確認を完了する。そして、サービス提供装置２１Ａは、指定されたチケットをその利用者に発行する（ステップＳ５３０）。このとき、サービス提供装置２１Ａは、チケットが発行されたことを示すチケット発行情報を含む確認記録ブロックをブロックチェーン３に登録する（ステップＳ５３１）。その結果として、該確認記録ブロックのＴｘＩＤ（例えば、ＴｘＩＤ＝３）を受信する（ステップＳ５３２）。
【０２４１】
チケット発行情報には、当該サービス提供装置２１Ａにおいて今回のチケットの発行にかかる情報（発行先の利用者の情報や入場時等に必要なブロックのＴｘＩＤ（発行記録ＴｘＩＤや発行処理において登録したブロックや参照したブロックのＴｘＩＤ）や個人情報等）と対応づけられたサービスＩＤが含まれているものとする。また、サービス提供装置２１Ａは、そのようなサービスＩＤと対応づけて、今回のチケットの発行にかかる情報を保持する（ステップＳ５３３）。
【０２４２】
以上の処理を終えると、サービス提供装置２１Ａは、購入申請に対して購入許可を、今回のチケットの発行にかかる情報を識別するためのサービスＩＤや、今回のチケットの発行記録が登録されたＴｘＩＤ（図中の発行記録ＴｘＩＤ）とともに、要求元の個人用端末１０Ａに返信する（ステップＳ５３４）。
【０２４３】
購入許可を受信した個人用端末１０Ａは、購入許可とともに受信したサービスＩＤや発行記録ＴｘＩＤを、発券チケット情報として保存する（ステップＳ５３５）。その後、利用者に完了通知を行う（ステップＳ５３６）。
【０２４４】
また、図１８は、入場申請時の処理の流れの一例を示すシーケンス図である。図１８に示す例では、まず利用者が、個人用端末１０Ａに対して入場申請の指示を行う（ステップＳ５４１）。このとき、入場申請を行う発券チケット情報としてのサービスＩＤが指定されてもよい。
【０２４５】
入場申請の指示を受け付けると、個人用端末１０Ａは、入場装置２２Ａに、個人ＩＤ１３ＤとサービスＩＤとを含む入場申請を送信する（ステップＳ５４２）。これは、実際に会場に設置された入場装置２２Ａが備えるリーダー装置へのタッチによる情報通信により行われてもよい。
【０２４６】
個人用端末１０Ａからの購入申請を受けた入場装置２２Ａは、サービス提供装置２１Ａに個人ＩＤ１３ＤとサービスＩＤとを含むサービスＩＤ妥当性確認を送信する（ステップＳ５４３）。なお、サービスＩＤ妥当性確認にはさらに開催されているイベントや会場に関する情報が含まれていてもよい。
【０２４７】
入場装置２２ＡからのサービスＩＤ妥当性確認を受けたサービス提供装置２１Ａは、そのサービスＩＤの妥当性を確認する（ステップＳ５４４）。サービス提供装置２１Ａは、受信したサービスＩＤに対して、その入場装置２２Ａが設置されたイベントに対するチケットの発行にかかる情報が登録されているかを確認すればよい。
【０２４８】
そして、サービス提供装置２１Ａは、自身が保持している該サービスＩＤに対応づけられている発行記録ＴｘＩＤを基に、発行記録を登録した確認記録ブロックを取得し、その登録情報の信頼性を確認した上で、発行記録の正当性を確認する（ステップＳ５４５〜ステップＳ５４６）。サービス提供装置２１Ａは、確認記録ブロック内の発行記録の正当性まで確認されると、サービスＩＤ妥当性結果（ＯＫ）を入場装置２２Ａに返信する（ステップＳ５４７）。サービス提供装置２１Ａは、発行記録の正当性を確認できなければ、サービスＩＤ妥当性結果（ＮＧ）を入場装置２２Ａに返信する。
【０２４９】
サービスＩＤ妥当性結果を受信した入場装置２２Ａは、サービスＩＤ妥当性結果がＮＧであれば、個人用端末１０Ａに入場不可を返信する（ステップＳ５４８）。このとき、入場装置２２Ａは、サービスＩＤが不正である旨を併せて送信してもよい。入場不可を受信した個人用端末１０Ａは利用者に不可通知をして処理を終了する（ステップＳ５４９）。
【０２５０】
一方、入場装置２２Ａは、サービスＩＤ妥当性結果がＯＫであれば、生体認証要求Ｄを個人用端末１０Ａに送信する（ステップＳ５５０）。なお、以下に示す例は、個人用端末１０Ａ側でブロックチェーン３内の生体認証を利用して本人確認を行う例であるが、同様の処理を入場装置２２Ａ等で行ってもよい。
【０２５１】
生体認証要求Ｄを受信した個人用端末１０Ａは、自身が保持している登録履歴を検索して本人登録の際に登録した登録ブロックのＴｘＩＤを取得し（ステップＳ５５１）、その登録情報（特に、生体情報のハッシュ値である個人情報Ｈａｓｈ３２Ｄ（３））を取得する。
【０２５２】
そして、個人用端末１０Ａは、取得した登録情報の信頼性確認（ステップＳ５５２）、および自身で保持している登録時の個人情報と登録情報の元データとの一致性確認により（ステップＳ５５３）、自身が保持している個人情報１４Ｄ（３）がブロックチェーン３に登録した時の生体情報であることを確認する。なお、この確認は、ブロックチェーンＮＷ３０Ａに、登録ブロックのＴｘＩＤを参照ＴｘＩＤとして指定し、確認対象とする登録した時の生体情報から算出したハッシュ値を比較元として指定した登録情報参照要求を送信することで行うことも可能である。
【０２５３】
このようにして自身が保持している個人情報１４Ｄ（３）の正当性（本人登録認証）が確認されると、個人用端末１０Ａは、さらに現在（入場申請時）の利用者の生体情報を取得し、両者の同一性を確認する（ステップＳ５５４）。なお、個人用端末１０Ａは、両者をハッシュ値の形式で照合してもよい。そして、個人用端末１０Ａは、ステップＳ５５４の結果を生体認証結果として入場装置２２Ａに返信する（ステップＳ５５５）。
【０２５４】
生体認証結果を受信した入場装置２２Ａは、生体認証結果ＮＧであれば、個人用端末１０Ａに入場不可を返信する（ステップＳ５５６）。このとき、入場装置２２Ａは、生体認証エラーである旨を併せて送信してもよい。入場不可を受信した個人用端末１０Ａは利用者に不可通知をして処理を終了する（ステップＳ５５７）。
【０２５５】
一方、入場装置２２Ａは、生体認証結果ＯＫであれば、今回の認証記録を確認記録ブロックにしてブロックチェーン３に追加した後（ステップＳ５５８、ステップＳ５５９）、個人用端末１０Ａに入場許可を返信する（ステップＳ５６０）。入場許可を受信した個人用端末１０Ａは利用者に許可通知をして処理を終了する（ステップＳ５６１）。
【０２５６】
以上のように、本実施形態によれば、漏れなく、確実かつ素早く、本人確認を含むチケットサービスを実現できる。また、本人確認のために人員の現場におかなくてもよいため、コスト削減にもつながる。
【０２５７】
また、図１９は、本実施形態のチケットサービスシステムの他の構成例を示すブロック図である。図１９に示すチケットサービスシステムは、個人用端末１０Ｂと、サービス提供装置２１Ｂと、入場装置２２Ｂと、ブロックチェーンＮＷ３０Ｂとを備える。
【０２５８】
個人用端末１０Ｂは、サービス要求部７１１Ｂと、ＩＭＳアプリケーション部７１２Ｂとを含む。
【０２５９】
サービス提供装置２１Ｂは、サービス提供部７２１Ｂと、第１の対象確認サービス部７２２Ｂとを含む。
【０２６０】
入場装置２２Ｂは、第２の対象確認サービス部７３１Ｂと、判定部７３２Ｂとを含む。
【０２６１】
サービス要求部７１１Ｂは、第２の実施形態の個人用端末１０Ａで行っていたサービス提供にかかる処理（確認部２０２が行う処理に相当する対象確認および記録登録にかかる処理以外の処理）を行う。サービス要求部７１１Ｂは、例えば、個人用端末１０Ｂのユーザからの操作に応じて、サービス提供部７２１Ｂにサービスを要求するメッセージを送信する。
【０２６２】
ＩＭＳアプリケーション部７１２Ｂは、第２の実施形態の個人用端末１０Ａで行っていた対象確認および記録登録にかかる処理を行う。ＩＭＳアプリケーション部７１２Ｂは、具体的には、個人用端末１０Ｂのユーザであって本システムの利用者が上記の個人情報管理システムを利用するための各種処理およびインタフェースを提供する。
【０２６３】
サービス提供部７２１Ｂは、第２の実施形態のサービス提供装置２１Ａで行っていたサービス提供にかかる処理のうち、対象確認以外の処理を行う。なお、本例のサービス提供部７２１Ｂは、チケットサービスを提供する。サービス提供部７２１Ｂは、例えば、サービス要求部７１１Ｂとの情報のやりとりにより、利用者に、サービスを提供する。
【０２６４】
第１の対象確認サービス部７２２Ｂは、第２の実施形態のサービス提供装置２１Ａで行っていたサービス提供にかかる処理のうち、対象確認にかかる処理を行う。第１の対象確認サービス部７２２Ｂは、具体的には、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部７１２Ｂとの情報のやりとりにより、利用者の対象確認を行う。
【０２６５】
第２の対象確認サービス部７３１Ｂは、第２の実施形態の入場装置２２Ａで行っていたサービス提供にかかる処理のうち、対象確認にかかる処理を行う。第２の対象確認サービス部７３１Ｂは、具体的には、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部７１２Ｂとの情報のやりとりにより、利用者の対象確認を行う。
【０２６６】
判定部７３２Ｂは、第２の実施形態の入場装置２２Ａで行っていたサービス提供にかかる処理のうち、対象確認以外の処理を行う。判定部７３２Ｂは、例えば、第２の対象確認サービス部７３１Ｂによる対象確認の結果に基づいて、利用者の入場の可否を判定する。
【０２６７】
このような構成において、サービス提供部７２１Ｂは、第１の対象確認サービス部７２２Ｂから通知された利用者の対象確認の結果を基に利用者にチケット購入サービスを提供してもよい。
【０２６８】
なお、本例においてＩＭＳは、２以上のノード３０１Ｂと、登録部１０２Ｂと、開示部１０３Ｂと、対象確認部２０２１Ｂと、記録登録部２０２２Ｂとを備えている。
【０２６９】
ノード３０１Ｂは、台帳管理ノード３０１に相当し、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーン（より具体的には、ブロックチェーンＮＷ３０Ｂ）を構成する。
【０２７０】
登録部１０２Ｂは、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する。
【０２７１】
開示部１０３Ｂは、個人情報の開示要求を受信すると、要求された種別の個人情報を所定の記憶部（図示省略）から読み出し、要求元に送信する。または、要求された種別の個人情報に代えて、該個人情報を用いて行われた過去の対象確認の記録を含む第２ブロックを特定可能な情報を送信してもよい。
【０２７２】
対象確認部２０２１Ｂは、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う。
【０２７３】
記録登録部２０２２Ｂは、ブロックチェーンに、対象確認もしくはサービスの提供の記録を含む第２ブロックを登録する。
【０２７４】
なお、本例では、ＩＭＳアプリケーション部７１２Ｂが、ＩＭＳの一部として登録部１０２Ｂを有し、第１の対象確認サービス部７２２Ｂおよび第２の対象確認サービス部７３１Ｂがそれぞれ、ＩＭＳの一部として対象確認部２０２１Ｂおよび記録登録部２０２２Ｂを有しているものとする。
【０２７５】
そのような構成において、ＩＭＳアプリケーション部７１２Ｂは、登録部１０２Ｂを介して、ブロックチェーンに、利用者の識別子と、利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録してもよい。
【０２７６】
また、第１の対象確認サービス部７２２Ｂは、対象確認部２０２１Ｂを介して、利用者に第２の対象確認情報の開示を要求して、得られた情報を基に対象確認を行ってもよい。
【０２７７】
また、第２の対象確認サービス部７３１Ｂは、利用者から入場申請を受け付けると、対象確認部２０２１Ｂを介して、利用者に、第２ブロックを特定可能な情報と、第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行ってもよい。
【０２７８】
また、第１の対象確認サービス部７２２Ｂおよび第２の対象確認サービス部７３１Ｂは、対象確認や何らかのサービスを提供した場合、記録登録部２０２２Ｂを介して、ブロックチェーンに、対象確認もしくはサービスの提供の記録を含む第２ブロックを登録してもよい。
【０２７９】
このような構成によれば、利用者は必要最小限の個人情報を開示するだけで、対象確認を伴うチケットサービスの提供を受けることができる。なお、他の点に関しては、第１の実施形態の個人情報管理システムおよび第２の実施形態のチケットサービスシステムと同様である。
【０２８０】
なお、本実施形態では、チケットの販売から入場判定までの一連のチケットサービスに、１つの個人ＩＤに対応づけられたブロックチェーン３内の情報を利用して本人確認を含む対象確認を行う個人情報管理システムを適用した例を示したが、適用先のサービスはチケットサービスに限定されない。
【０２８１】
例えば、スマートキーを利用して施錠／開錠を行う施設や部屋の予約、スマートキーの発行および入出場管理を行う施設管理サービスや、生体情報が登録されたウェアラブルデバイスや携帯端末などを用いた投票サービスや、生体情報が登録されたウェアラブルデバイスや携帯端末などを用いた改札での定期券運賃管理サービスなども考えられる。
【０２８２】
上記の施設管理サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、本サービスにおいて必要とされる個人情報と併せて本人確認用の生体情報のハッシュ値を、個人ＩＤとともにブロックチェーンに登録（本人登録）する。
・予約時、本人確認の上で電子鍵を発行して、その記録をブロックチェーンに登録する。
・チェックイン時、本人確認の上で発行した電子鍵を有効にし、その記録をブロックチェーンに登録する。
・電子による開錠／施錠時、施錠装置等を介してその記録をブロックチェーンに登録する。
・チェックアウト時、発行した電子鍵を無効にし、ブロックチェーン上の記録を基に清算を行う。
【０２８３】
上記の投票サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、本サービスにおいて必要とされる個人情報と併せて本人確認用の生体情報のハッシュ値を、個人ＩＤとともにブロックチェーンに登録（本人登録）する。
・電子投票権申請時、本人確認と電子投票権発行に必要な情報の確認の上、電子投票権を発行して、発行記録をブロックチェーンに登録する。
・投票時、投票を受け付けた投票装置が、本人確認と発行記録を確認した上で、投票を受け付ける。また、投票内容（暗号化）を含む投票記録をブロックチェーンに登録する。
・開票時、開票装置が、ブロックチェーン上の投票記録を基に開票を行う。
【０２８４】
上記の定期券運賃管理サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、利用者が所持しているウェアラブルデバイスや携帯端末に、生体情報を登録する。
・定期券申請時、生体情報を登録したデバイスＩＤと定期券発行情報とを含む発行記録をブロックチェーンに登録する。このとき、デバイスＩＤを個人ＩＤとみなしてもよいし、別に割り当ててもよい。
・改札通過（乗車）時、生体認証済みのウェアラブルデバイスや携帯端末から取得されるデバイスＩＤや定期券発行時に通知した個人ＩＤを基に、ブロックチェーン上の発行記録や直前の記録を確認して、入場可否を判定する。また、入場記録をブロックチェーンに登録する。
・改札通過（下車）時、生体認証済みのウェアラブルデバイスや携帯端末から取得されるデバイスＩＤや定期券発行時に通知した個人ＩＤを基に、ブロックチェーン上の発行記録や直前の記録を確認して、出場可否を判定する。また、出場記録をブロックチェーンに登録する。
【０２８５】
なお、上記に示す例では、入場装置が、利用者から入場の申請を受け付けて、対象確認の結果に基づいて、利用者の申請の可否を判定する例を示したが、該入場装置を、サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置に置き換えることも可能である。そのような場合、図１９に示すように、許可証判定装置において、第２の対象確認サービス部が、利用者から入場の申請または許可証により得られる利益の受領の申請を受け付け、判定部が、第２の対象確認部による対象確認の結果に基づいて、利用者の申請の可否を判定してもよい。ここで、許可証は、電子チケット、電子キー、電子投票券、定期券であってもよい。
【０２８６】
また、図２０は、本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５と、入力デバイス１００６とを備える。
【０２８７】
上述の各実施形態のシステムが備えるサーバその他の装置等は、コンピュータ１０００に実装されてもよい。その場合、各装置の動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って各実施形態における所定の処理を実施する。なお、ＣＰＵ１００１は、プログラムに従って動作する情報処理装置の一例であり、ＣＰＵ（Central Processing Unit）以外にも、例えば、ＭＰＵ（Micro Processing Unit）やＭＣＵ（Memory Control Unit）やＧＰＵ（Graphics Processing Unit）などを備えていてもよい。
【０２８８】
補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、各実施形態における所定の処理を実行してもよい。
【０２８９】
また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで各実施形態における所定の処理を実現する差分プログラムであってもよい。
【０２９０】
インタフェース１００４は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置１００５は、ユーザに情報を提示する。また、入力デバイス１００６は、ユーザからの情報の入力を受け付ける。
【０２９１】
また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、コンピュータ１０００がユーザに情報を提示しないのであれば、ディスプレイ装置１００５は省略可能である。例えば、コンピュータ１０００がユーザから情報入力を受け付けないのであれば、入力デバイス１００６は省略可能である。
【０２９２】
また、上記の各実施形態の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、上記の各実施形態各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【０２９３】
上記の各実施形態の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【０２９４】
次に、本発明の概要を説明する。図２１は、本発明の個人情報管理システムの概要を示すブロック図である。図２１に示すように、本発明の個人情報管理システムは、２以上のノード６１と、登録部６２と、対象確認部６３と、記録登録部６４とを備えていてもよい。
【０２９５】
ノード６１は、２以上のノード６１が参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する。
【０２９６】
登録部６２は、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する。
【０２９７】
対象確認部６３は、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う。
【０２９８】
記録登録部６４は、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する。
【０２９９】
以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【産業上の利用可能性】
【０３００】
本発明によれば、本人確認、ユーザ認証または適格性確認のいずれかを行った上で利用者にサービスを提供するものであれば、好適に適用できる。
【符号の説明】
【０３０１】
１  クライアントデバイス
２  確認機関デバイス
３  ブロックチェーン
４  ネットワーク
１１Ｄ、２１Ｄ  秘密鍵
１２Ｄ、２２Ｄ  公開鍵
１３Ｄ  個人ＩＤ
１４Ｄ  個人情報
３１Ｄ  個人ＩＤ＿Ｈａｓｈ
３２Ｄ  個人情報Ｈａｓｈ
３３Ｄ  本人の署名
３４Ｄ  確認情報
３５Ｄ  確認機関の署名
１００  個人情報管理システム
１０  利用者側システム
１０１  データ記憶部
１０２  登録部
１０３  開示部
１０４  認証部
２０  確認機関側システム
２０１  データ記憶部
２０２  確認部
２２１  データ取得部
２２２  登録情報信頼性確認部
２２３  元データ一致性確認部
２２４  個人情報正当性確認部
２２５  結果出力部
２２６  確認記録登録部
３０  台帳管理システム
３０１  台帳管理ノード
３１１  登録情報受付部
３１２  ブロック生成部
３１３  ブロック共有部
３１４  情報記憶部
３１５  ブロック検証部
４０  ネットワーク
５０  管理側システム
５０１  データ記憶部
５０２  個人ＩＤ割当部
１０Ａ、１０Ｂ  個人用端末
２１Ａ、２１Ｂ  サービス提供装置
２２Ａ、２２Ｂ  入場装置
３０Ａ、３０Ｂ  ブロックチェーンＮＷ
７１１Ｂ  サービス要求部
７１２Ｂ  ＩＭＳアプリケーション部
７２１Ｂ  サービス提供部
７２２Ｂ  第１の対象確認サービス部
７３１Ｂ  第２の対象確認サービス部
７３２Ｂ  判定部
１０２Ｂ  登録部
１０３Ｂ  開示部
２０２１Ｂ  対象確認部
２０２２Ｂ  記録登録部
３０１Ｂ  ノード
１０００  コンピュータ
１００１  ＣＰＵ
１００２  主記憶装置
１００３  補助記憶装置
１００４  インタフェース
１００５  ディスプレイ装置
１００６  入力デバイス
６１  ノード
６２  登録部
６３  対象確認部
６４  記録登録部
【図１】
2019219780.tif 000003
【図２】
2019219780.tif 000004
【図３】
2019219780.tif 000005
【図４】
2019219780.tif 000006
【図５】
2019219780.tif 000007
【図６】
2019219780.tif 000008
【図７】
2019219780.tif 000009
【図８】
2019219780.tif 000010
【図９】
2019219780.tif 000011
【図１０】
2019219780.tif 000012
【図１１】
2019219780.tif 000013
【図１２】
2019219780.tif 000014
【図１３】
2019219780.tif 000015
【図１４】
2019219780.tif 000016
【図１５】
2019219780.tif 000017
【図１６】
2019219780.tif 000018
【図１７】
2019219780.tif 000019
【図１８】
2019219780.tif 000020
【図１９】
2019219780.tif 000021
【図２０】
2019219780.tif 000022
【図２１】
2019219780.tif 000023
【手続補正書】
【提出日】平成30年12月21日(2018.12.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、
前記ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、
前記利用者から開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う対象確認部と、
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する記録登録部と、
前記登録部によって前記第１ブロックにそのハッシュ値が登録された前記対象確認情報を少なくとも保持する利用者側データ保持部と、
前記対象確認部から前記対象確認情報の開示要求を受け付けると、前記利用者に許可を得た上で、前記利用者側データ保持部に保持されている前記対象確認情報を開示する開示部とを備え、
前記登録部は、前記ブロックチェーンに、前記利用者に割り当てられた識別子またはそのハッシュ値と、前記利用者から開示された個人情報であって前記対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックを登録し、
前記第１ブロックが２以上の対象確認情報のハッシュ値を含むか、前記ブロックチェーンに、前記利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されており、
前記開示部は、前記利用者に許可を得た上で、前記対象確認部から指定された前記対象確認情報のみを開示する
ことを特徴とする個人情報管理システム。
【請求項２】
前記登録部は、前記第１ブロックに含まれる情報の作成者または前記利用者本人もしくは前記対象確認情報の正当性を確認した機関の少なくともいずれかの署名が付された第１ブロックを登録する
請求項１に記載の個人情報管理システム。
【請求項３】
前記対象確認部は、
開示された前記対象確認情報の正当性を、前記ブロックチェーン内にある前記利用者の第１ブロックに付された署名に基づく前記第１ブロック内の前記対象確認情報のハッシュ値の信頼性の確認結果と、前記第１ブロック内の前記対象確認情報のハッシュ値と開示された前記対象確認情報から算出されたハッシュ値との一致性の確認結果とに基づいて検証する正当性検証部を含む
請求項２に記載の個人情報管理システム。
【請求項４】
前記対象確認部は、前記利用者に前記対象確認情報の開示を要求した結果、前記対象確認情報に代えて前記利用者から前記第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される前記第２ブロック内の前記対象確認の記録を参照して前記対象確認を行う
請求項１から請求項３のうちのいずれかに記載の個人情報管理システム。
【請求項５】
前記記録登録部は、前記第２ブロックに含まれる情報の作成者または前記対象確認を行った機関の署名が付された第２ブロックを登録し、
前記対象確認部は、開示された情報から特定される前記第２ブロックに付された署名に基づく前記第２ブロック内の前記対象確認の記録の信頼性を少なくとも確認した上で、前記対象確認の記録を参照して前記対象確認を行う
請求項１から請求項４のうちのいずれかに記載の個人情報管理システム。
【請求項６】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックであって、前記利用者に割り当てられた識別子またはそのハッシュ値と、前記利用者から開示された個人情報であって前記対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックを少なくとも登録しておき、
前記利用者からサービスを要求されると、前記利用者に前記対象確認情報の開示を要求し、開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行い、
前記対象確認の結果に基づいて、前記利用者にサービスを提供するとともに、前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録し、
前記対象確認情報の開示要求を受け付けると、前記利用者に許可を得た上で、前記第１ブロックにそのハッシュ値が登録された前記対象確認情報を少なくとも保持する利用者側データ保持部に保持されている前記対象確認情報を開示し、
前記第１ブロックが２以上の対象確認情報のハッシュ値を含むか、前記ブロックチェーンに、前記利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されている状態で、前記対象確認情報を開示するときに、前記利用者に許可を得た上で、指定された前記対象確認情報のみを開示する
ことを特徴とするサービス提供方法。
【請求項７】
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンであって、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックであって、前記利用者に割り当てられた識別子またはそのハッシュ値と、前記利用者から開示された個人情報であって前記対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックが少なくとも登録されたブロックチェーンから少なくとも前記第１ブロックの情報を取得可能なコンピュータに、
前記利用者からサービスを要求されると、前記利用者に前記対象確認情報の開示を要求し、開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う処理、
前記対象確認の結果に基づいて、前記利用者にサービスを提供する処理、
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する処理、および、
前記対象確認情報の開示要求を受け付けると、前記利用者に許可を得た上で、前記第１ブロックにそのハッシュ値が登録された前記対象確認情報を少なくとも保持する利用者側データ保持部に保持されている前記対象確認情報を開示する処理を実行させ、
前記第１ブロックが２以上の対象確認情報のハッシュ値を含むか、前記ブロックチェーンに、前記利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されている状態で、前記対象確認情報を開示させるときに、前記利用者に許可を得た上で、指定された前記対象確認情報のみを開示させる
ためのサービス提供プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
本発明による個人情報管理システムは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う対象確認部と、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する記録登録部と、登録部によって第１ブロックにそのハッシュ値が登録された対象確認情報を少なくとも保持する利用者側データ保持部と、対象確認部から対象確認情報の開示要求を受け付けると、利用者に許可を得た上で、利用者側データ保持部に保持されている対象確認情報を開示する開示部とを備え、登録部が、ブロックチェーンに、利用者に割り当てられた識別子またはそのハッシュ値と、利用者から開示された個人情報であって対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックを登録し、第１ブロックが２以上の対象確認情報のハッシュ値を含むか、ブロックチェーンに、利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されており、開示部が、利用者に許可を得た上で、対象確認部から指定された対象確認情報のみを開示することを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】削除
【補正の内容】
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】変更
【補正の内容】
【００１９】
本発明によるサービス提供方法は、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックであって、利用者に割り当てられた識別子またはそのハッシュ値と、利用者から開示された個人情報であって対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックを少なくとも登録しておき、利用者からサービスを要求されると、利用者に対象確認情報の開示を要求し、開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行い、対象確認の結果に基づいて、利用者にサービスを提供するとともに、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録し、対象確認情報の開示要求を受け付けると、利用者に許可を得た上で、第１ブロックにそのハッシュ値が登録された対象確認情報を少なくとも保持する利用者側データ保持部に保持されている対象確認情報を開示し、第１ブロックが２以上の対象確認情報のハッシュ値を含むか、ブロックチェーンに、利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されている状態で、対象確認情報を開示するときに、利用者に許可を得た上で、指定された対象確認情報のみを開示することを特徴とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】変更
【補正の内容】
【００２０】
本発明によるサービス提供プログラムは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンであって、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックであって、利用者に割り当てられた識別子またはそのハッシュ値と、利用者から開示された個人情報であって対象確認に必要な個人情報である対象確認情報のハッシュ値とを含む第１ブロックが少なくとも登録されたブロックチェーンから少なくとも第１ブロックの情報を取得可能なコンピュータに、利用者からサービスを要求されると、利用者に対象確認情報の開示を要求し、開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う処理、対象確認の結果に基づいて、利用者にサービスを提供する処理、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する処理、および、対象確認情報の開示要求を受け付けると、利用者に許可を得た上で、第１ブロックにそのハッシュ値が登録された対象確認情報を少なくとも保持する利用者側データ保持部に保持されている対象確認情報を開示する処理を実行させ、第１ブロックが２以上の対象確認情報のハッシュ値を含むか、ブロックチェーンに、利用者の２以上の対象確認情報の少なくともいずれかのハッシュ値を含む第１ブロックが２以上登録されている状態で、対象確認情報を開示させるときに、利用者に許可を得た上で、指定された対象確認情報のみを開示させることを特徴とする。