特許 6504639 サービス提供システムおよびサービス提供方法

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

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

(11)【特許番号】6504639

(24)【登録日】2019年4月5日

(45)【発行日】2019年4月24日

(54)【発明の名称】サービス提供システムおよびサービス提供方法

(51)【国際特許分類】

   G06Q 50/00 20120101AFI20190415BHJP

【ＦＩ】

   G06Q50/00 300

【請求項の数】8

【全頁数】65

(21)【出願番号】特願2018-115125(P2018-115125)

(22)【出願日】2018年6月18日

【審査請求日】2018年6月18日

【早期審査対象出願】

(73)【特許権者】

【識別番号】000232092

【氏名又は名称】ＮＥＣソリューションイノベータ株式会社

(73)【特許権者】

【識別番号】593022629

【氏名又は名称】株式会社ジェーシービー

(74)【代理人】

【識別番号】100103090

【弁理士】

【氏名又は名称】岩壁 冬樹

(74)【代理人】

【識別番号】100124501

【弁理士】

【氏名又は名称】塩川 誠人

(72)【発明者】

【氏名】深田 彰

(72)【発明者】

【氏名】牛嶋 康貴

(72)【発明者】

【氏名】田中 清春

(72)【発明者】

【氏名】嶋中 修成

(72)【発明者】

【氏名】江口 祥生

(72)【発明者】

【氏名】中西 雅彦

【審査官】 原 忠

(56)【参考文献】

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

【文献】 特開２０１３−０６５２３６（ＪＰ，Ａ）

【文献】 国際公開第２０１８／０４３５９９（ＷＯ，Ａ１）

【文献】 特開２０１２−１６８６５５（ＪＰ，Ａ）

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

Ｇ０６Ｑ １０／００ − ９９／００

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

【請求項1】

所定のサービスを提供するサービスサーバと、前記サービスの提供先とされる利用者が使用する個人用端末とを備え、
前記個人用端末は、
前記利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、
前記利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを含み、
前記サービスサーバは、
前記ＳＮＳのプラットフォームを利用した前記ＳＮＳアプリケーション部との情報のやりとりにより、前記利用者に、前記サービスを提供するＳＮＳ側サービス提供部と、
前記ＩＭＳのプラットフォームを利用した前記ＩＭＳアプリケーション部との情報のやりとりにより、前記利用者の対象確認を行う対象確認サービス部とを含み、
前記ＩＭＳアプリケーション部は、前記対象確認サービス部に、所定の方法で、前記ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、前記ＳＮＳ側サービス提供部が前記ＳＮＳのプラットフォーム上で前記利用者を特定可能な情報であるＳＮＳ＿ＩＤを、前記利用者の対象確認の結果を特定可能な情報とともに送信し、
前記対象確認サービス部は、前記ＩＭＳアプリケーション部から受信した前記ＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された前記利用者の対象確認の結果とを対応づけて前記ＳＮＳ側サービス提供部に通知し、
前記ＩＭＳは、
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、
前記ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、
前記利用者から開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う対象確認部とを備えており、
前記ＩＭＳアプリケーション部は、前記ＩＭＳの一部として前記登録部を有し、
前記対象確認サービス部は、前記ＩＭＳの一部として前記対象確認部を有し、
前記ＩＭＳは、
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録する記録登録部をさらに備えており、
前記対象確認部は、前記利用者に前記対象確認情報の開示を要求した結果、前記対象確認情報に代えて前記利用者から前記第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される前記第２ブロック内の前記対象確認の記録を参照して前記対象確認を行い、
前記対象確認サービス部は、前記ＩＭＳの一部として前記記録登録部をさらに有する
ことを特徴とするサービス提供システム。

【請求項2】

前記ＩＭＳアプリケーション部は、前記ＳＮＳのプラットフォームより提供されるメッセージの送受信機能を利用して前記ＳＮＳ側サービス提供部より受信したＷｅｂページのリンクから自身が起動される際に受け渡される起動パラメータから前記利用者の前記ＳＮＳ_ＩＤを取得する、または、前記ＳＮＳのプラットフォームより提供される他のアプリケーションから前記ＳＮＳへのログインサービスを利用して前記利用者の前記ＳＮＳ_ＩＤを取得する
請求項１に記載のサービス提供システム。

【請求項3】

前記ＩＭＳアプリケーション部は、前記ＳＮＳのプラットフォームより提供されるメッセージの送受信機能を利用して前記ＳＮＳ側サービス提供部より受信したＷｅｂページのリンクから自身が起動される際に受け渡される起動パラメータから、前記ＳＮＳ＿ＩＤとして前記利用者を特定可能なセッションＩＤと、前記ＩＭＳのプラットフォーム上で前記対象確認サービス部を特定可能な情報である送信先ＩＭＳ＿ＩＤとを含む情報を取得する
請求項２に記載のサービス提供システム。

【請求項4】

前記ＩＭＳアプリケーション部は、前記利用者の前記ＳＮＳ_ＩＤと、自身が保持している前記ＩＭＳのプラットフォーム上で前記利用者を特定可能な情報であるＩＭＳ＿ＩＤとを対応づけて前記対象確認サービス部に送信する
請求項１から請求項３のうちのいずれかに記載のサービス提供システム。

【請求項5】

前記ＩＭＳアプリケーション部は、前記利用者の前記ＳＮＳ_ＩＤと、前記ＩＭＳのプラットフォームを利用して行った前記利用者の前記対象確認の結果とを対応づけて前記対象確認サービス部に送信する
請求項１から請求項３のうちのいずれかに記載のサービス提供システム。

【請求項6】

利用者が使用する個人用端末と、利用者に所定のサービスを提供するサービス提供装置と、サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置とを備え、
前記個人用端末は、
前記利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、
前記利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを含み、
前記サービス提供装置は、
前記ＳＮＳのプラットフォームを利用した前記ＳＮＳアプリケーション部との情報のやりとりにより、前記利用者に、前記サービスを提供するＳＮＳ側サービス提供部と、
前記ＩＭＳのプラットフォームを利用した前記ＩＭＳアプリケーション部との情報のやりとりにより、前記利用者の対象確認を行う第１の対象確認サービス部とを含み、
前記許可証判定装置は、
前記利用者から入場の申請または前記許可証により得られる利益の受領の申請を受け付けると、前記ＩＭＳのプラットフォームを利用した前記ＩＭＳアプリケーション部との情報のやりとりにより、前記利用者の対象確認を行う第２の対象確認サービス部と、
前記第２の対象確認サービス部による前記対象確認の結果に基づいて、前記利用者の申請の可否を判定する判定部とを含み、
前記ＩＭＳアプリケーション部は、少なくとも前記第１の対象確認サービス部に、所定の方法で、前記ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、前記ＳＮＳ側サービス提供部が前記ＳＮＳのプラットフォーム上で前記利用者を特定可能な情報であるＳＮＳ＿ＩＤを、前記利用者の対象確認の結果を特定可能な情報とともに送信し、
前記第１の対象確認サービス部は、前記ＩＭＳアプリケーション部から受信した前記ＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された前記利用者の対象確認の結果とを対応づけて前記ＳＮＳ側サービス提供部に通知し、
前記ＳＮＳ側サービス提供部は、前記第１の対象確認サービス部から通知された前記利用者の対象確認の結果を基に前記利用者に前記サービスを提供し、
前記ＩＭＳは、
２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、
前記ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、
前記利用者から開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行う対象確認部と、
前記ブロックチェーンに、前記対象確認もしくはサービスの提供の記録を含む第２ブロックを登録する記録登録部とを備えており、
前記ＩＭＳアプリケーション部は、前記ＩＭＳの一部として前記登録部を有し、
前記第１の対象確認サービス部および前記第２の対象確認サービス部はそれぞれ、前記ＩＭＳの一部として前記対象確認部および前記記録登録部を有し、
前記ＩＭＳアプリケーション部は、前記登録部を介して、前記ブロックチェーンに、前記利用者の識別子と、前記利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、前記利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録し、
前記第１の対象確認サービス部は、前記対象確認部を介して、前記利用者に、前記第２の対象確認情報の開示を要求して、得られた情報を基に前記対象確認を行い、
前記第２の対象確認サービス部は、前記対象確認部を介して、前記利用者に、前記第２ブロックを特定可能な情報と、前記第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行い、
前記対象確認部は、前記利用者に前記対象確認情報の開示を要求した結果、前記対象確認情報に代えて前記利用者から前記第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される前記第２ブロック内の前記対象確認の記録を参照して前記対象確認を行う
ことを特徴とするサービス提供システム。

【請求項7】

前記サービスが、チケットサービス、施設管理サービス、投票サービスまたは定期券運賃管理サービスのいずれかである
請求項１から請求項６のうちのいずれかに記載のサービス提供システム。

【請求項8】

サービスの提供先とされる利用者が使用する個人用端末であって前記利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、前記利用者が、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードを備える所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを備える個人用端末が備える前記ＩＭＳアプリケーション部が、前記サービスを提供するサービスサーバであって前記ＳＮＳのプラットフォームを利用した前記ＳＮＳアプリケーション部との情報のやりとりにより、前記利用者に、前記サービスを提供するＳＮＳ側サービス提供部と、前記ＩＭＳのプラットフォームを利用した前記ＩＭＳアプリケーション部との情報のやりとりにより、前記利用者の対象確認を行う対象確認サービス部とを備えたサービスサーバの前記対象確認サービス部に、所定の方法で、前記ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、前記ＳＮＳ側サービス提供部が前記ＳＮＳのプラットフォーム上で前記利用者を特定可能な情報であるＳＮＳ＿ＩＤを、前記利用者の対象確認の結果を特定可能な情報とともに送信し、
前記対象確認サービス部が、前記ＩＭＳアプリケーション部から受信した前記ＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された前記利用者の対象確認の結果とを対応づけて前記ＳＮＳ側サービス提供部に通知し、
前記ＳＮＳ側サービス提供部が、前記対象確認サービス部から通知された前記利用者の対象確認の結果を基に前記サービスを提供し、
前記ＩＭＳが、
前記ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録し、
前記利用者から開示された前記対象確認情報の正当性を前記ブロックチェーン内のブロックを用いて検証した上で、開示された前記対象確認情報に基づいて前記対象確認を行い、
前記ＩＭＳが、
前記ブロックチェーンに、前記対象確認の記録を含む第２ブロックを登録し、
前記利用者に前記対象確認情報の開示を要求した結果、前記対象確認情報に代えて前記利用者から前記第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される前記第２ブロック内の前記対象確認の記録を参照して前記対象確認を行う
ことを特徴とするサービス提供方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、個人情報を使用して利用者へサービスの提供を行うサービス提供システムおよびサービス提供方法に関する。

【背景技術】

【0002】

サービス提供の場において、サービスの提供を行う側（以下、ベンダという）が、要求元ユーザがユーザ本人かどうかを確認した上で、サービスの提供を行うことがある。例えば、ベンダは、要求元ユーザに個人情報の開示を要求し、開示された個人情報を基にそのユーザがユーザ本人であるか否かを確認する。一般に、ある人物がその人物本人であることを確認することを、「本人確認（personal identification）」や「身元確認（identity verification）と呼ぶ。本人確認に用いられる個人情報としては、例えば、免許証（より具体的には、それに含まれる情報集合。以下同様）、保険証（より具体的には、それに含まれる情報集合。以下同様）、パスポート（より具体的にはそれに含まれる情報集合。以下同様）、クレジットカード（より具体的にはそれに含まれる情報集合。以下同様）、生体情報、マイナンバーなどが挙げられる。なお、場合によっては、ＩＤとパスワードの組といった所定の２以上の情報の組み合わせも、そのような個人情報に含まれる。

【0003】

また、例えば、ベンダは、要求元ユーザが当該ベンダにおける正規のユーザであることを確認するために、要求元ユーザにユーザ識別情報と認証情報とを要求し、得られた情報と予め登録されている情報とを照合することにより、そのユーザが当該ベンダにおける正規のユーザであるか否かを確認する。あるシステムに対して特定のユーザであると申告した者がその特定のユーザすなわち正規の一ユーザであることを確認することを、「ユーザ認証（User authentication）」と呼ぶ。ここで、正規のユーザであることを確認するとは、より具体的には、あるシステムに対して特定のユーザであると申告した申告者がそのシステムにおいてその特定のユーザと同一人物またはそれと同等とみなせる資格を有することを確認することである。本人確認は、申告者が申告者本人であることまで確認するのに対して、ユーザ認証は、申告者が予め登録されているユーザと同一とみなせることを確認するのに留まる点で、確認結果に対して要求されるレベルが異なるが、ユーザ認証は個々のシステム内における本人確認の一種とみなすこともできる。

【0004】

また、個人情報を利用する他のケースとしては、あるサービスの提供を要求した要求者がそのサービスの受給資格を有していることを確認する「適格性確認（eligibility verification）」などが挙げられる。ここで、サービスには、有料／無料を問わない物品や役務の提供など、あらゆるサービスが含まれる。

【0005】

以下では、個人情報を利用してサービスの要求者に対して、本人確認、ユーザ認証および適格性確認の少なくともいずれかを行うことを、対象確認（target verification）と呼ぶ。換言すると、対象確認を、本人確認、ユーザ認証および適格性確認を含む概念として定義する。

【0006】

このような、個人情報を基に対象確認を行った上でサービスを提供する技術に関し、例えば、特許文献１には、自販機等の商品提供装置で撮影された顔画像を用いて管理装置がユーザ認証を行うことで、ユーザの手間をかけずに商品を提供できる商品提供システムが記載されている。

【0007】

また、特許文献２には、ＩＣカードとそのリーダといった専用カードおよび専用装置を使用することなく、また個人が設定する任意のＩＤを使用せずに、個人を特定できる本人認証システムが記載されている。特許文献２に記載の本人認証システムは、予め認証サーバにおいてユーザを識別する情報としての端末ＩＤと、認証用の情報（生体情報と位置情報の組など）とを対応づけて保持しておくとともに、情報サーバにおいて端末ＩＤとユーザの個人情報とを対応づけて保持しておく。その上で、端末ＩＤを保持している端末装置が、自身が取得した照合用の情報（生体情報と位置情報）とともにユーザの個人情報を要求するコマンドをリーダー・ライタを介して情報サーバに送信する。情報サーバは、受信したコマンドを解析し、端末装置から受信した照合用の情報と認証サーバに記憶されている認証用の情報とを比較してユーザ認証を行った上で、受信したユーザの個人情報を端末装置に送信する。

【0008】

また、非特許文献１には、ブロックチェーンを利用して本人確認を行うシステムの１つとして、ShoCard社によって提供されている個人情報管理システム（Identity Management Sysmtem：IMS）による個人認証サービスである“ShoBadge”が紹介されている。また、ShoCard社は、個人認証サービス用アプリケーションである“ShoCard”も個人端末向けに提供している。以下では、実際のサービス名やアプリケーション名を問わず、ShoCard社によるＩＭＳを“ShoCard”と呼び、そのＩＭＳで用いられるプラットフォームおよび個人端末向けアプリケーションを“ShoCardプラットフォーム”および“ShoCard APP”と呼ぶ。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０１７−１６２１９１号公報

【特許文献2】特開２０１７−１０２８４２号公報

【非特許文献】

【0010】

【非特許文献1】"SHOBADGE Secure Enterprise Identity Authentication Built Using the Blockchain (White paper)", [online], 2017, ShoCard Inc., [平成30年4月6日検索], インターネット＜URL:https://shocard.com/shobadge/＞

【発明の概要】

【発明が解決しようとする課題】

【0011】

課題は、対象確認を含むサービスを、個人情報の秘匿性を担保しつつ、ＳＮＳ（Social Networking Service）から行いたい点にある。

【0012】

一般に、ＩＭＳでは、各ユーザに対して独自に割り当てられるＩＤを利用してユーザごとの個人情報を管理している。例えば、上述の“ShoCard”では、端末アプリ利用時にユーザごとに割り当てられるShoCardIDを利用して、ユーザの個人情報の開示要求をしたり、開示された情報の真正性を検証して本人確認を行う。

【0013】

一方のＳＮＳでは、個人の匿名性を高めるため、当該ＳＮＳで利用するＩＤ以外の情報を基本的に必要としない代わりに、当該ＳＮＳの外では当該サービスを利用しているユーザ端末を特定できない仕組みになっていることが多い。

【0014】

このため、ＳＮＳ上で本人確認などの対象確認を含むサービスを提供しようとすると、ＳＮＳとＩＭＳとを連携させる必要がある。ＳＮＳとＩＭＳを連携させる場合、ＳＮＳのユーザＩＤとＩＭＳ上のユーザＩＤの両方を対応づける必要があるが、これまでＳＮＳとＩＭＳとを連携させる具体的な方法はなく、サービス提供元の各システムが独自に、サービス提供に必要となる本人確認のための情報を保持して利用するだけであった。

【0015】

例えば、特許文献１や特許文献２に記載の方法は、サービスごとに、ＩＤと認証情報の組を管理したり、対象確認のための手続きを行う必要がある。そのため、利用者は、種々のサービスの提供を受けようとすると、サービスやベンダごとに異なるＩＤや認証情報や対象確認のための手続きに用いる情報を管理する必要があり、煩雑である。

【0016】

また、各ベンダにとっても、利用者の個人情報を自身で保持、管理しなければならず、漏洩リスクを負うだけでなく攻撃に対する防御を含む情報管理のためのコストが増加する問題がある。

【0017】

なお、利用者の個人情報をベンダ側で管理せず、サービスを要求された際にその都度利用者に提示させることも考えられる。しかし、この方法は、対象確認においてその都度対象確認に必要な情報を提示しなければならず、利用者にとって煩雑である。加えて、この方法は、例えば、対象確認では免許証などの利用者本人を証明する証明書の一部の情報のみを提示すれば足りる場合であっても、証明書全体を提示せざるを得ない場合など、目的や用途ごとに必要最小限の情報のみを開示するといった制御ができず、個人情報の保護という点でも十分でない。

【0018】

本発明は、上述した課題に鑑みて、必要最小限の個人情報の開示だけで、ＳＮＳ上で、対象確認を伴うサービスの提供を行うことができるサービス提供システムおよびサービス提供方法を提供することを目的とする。

【課題を解決するための手段】

【0019】

本発明によるサービス提供システムは、所定のサービスを提供するサービスサーバと、サービスの提供先とされる利用者が使用する個人用端末とを備え、個人用端末は、利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを含み、サービスサーバは、ＳＮＳのプラットフォームを利用したＳＮＳアプリケーション部との情報のやりとりにより、利用者に、サービスを提供するＳＮＳ側サービス提供部と、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部との情報のやりとりにより、利用者の対象確認を行う対象確認サービス部とを含み、ＩＭＳアプリケーション部は、対象確認サービス部に、所定の方法で、ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、ＳＮＳ側サービス提供部がＳＮＳのプラットフォーム上で利用者を特定可能な情報であるＳＮＳ＿ＩＤを、利用者の対象確認の結果を特定可能な情報とともに送信し、対象確認サービス部は、ＩＭＳアプリケーション部から受信したＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部に通知し、ＩＭＳが、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う対象確認部とを備えており、ＩＭＳアプリケーション部が、ＩＭＳの一部として登録部を有し、対象確認サービス部が、ＩＭＳの一部として対象確認部を有し、ＩＭＳが、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録する記録登録部をさらに備えており、対象確認部が、利用者に対象確認情報の開示を要求した結果、対象確認情報に代えて利用者から第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される第２ブロック内の対象確認の記録を参照して対象確認を行い、対象確認サービス部は、ＩＭＳの一部として記録登録部をさらに有することを特徴とする。

【0020】

また、本発明によるサービス提供システムは、利用者が使用する個人用端末と、利用者に所定のサービスを提供するサービス提供装置と、サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置とを備え、個人用端末は、利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを含み、サービス提供装置は、ＳＮＳのプラットフォームを利用したＳＮＳアプリケーション部との情報のやりとりにより、利用者に、サービスを提供するＳＮＳ側サービス提供部と、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部との情報のやりとりにより、利用者の対象確認を行う第１の対象確認サービス部とを含み、許可証判定装置は、利用者から入場の申請または許可証により得られる利益の受領の申請を受け付けると、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部との情報のやりとりにより、利用者の対象確認を行う第２の対象確認サービス部と、第２の対象確認部による対象確認の結果に基づいて、利用者の申請の可否を判定する判定部とを含み、ＩＭＳアプリケーション部は、少なくとも第１の対象確認サービス部に、所定の方法で、ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、ＳＮＳ側サービス提供部がＳＮＳのプラットフォーム上で利用者を特定可能な情報であるＳＮＳ＿ＩＤを、利用者の対象確認の結果を特定可能な情報とともに送信し、第１の対象確認サービス部は、ＩＭＳアプリケーション部から受信したＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部に通知し、ＳＮＳ側サービス提供部は、第１の対象確認サービス部から通知された利用者の対象確認の結果を基に利用者にサービスを提供し、ＩＭＳは、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードと、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する登録部と、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う対象確認部と、ブロックチェーンに、対象確認もしくはサービスの提供の記録を含む第２ブロックを登録する記録登録部とを備えており、ＩＭＳアプリケーション部は、ＩＭＳの一部として登録部を有し、第１の対象確認サービス部および第２の対象確認サービス部はそれぞれ、ＩＭＳの一部として対象確認部および記録登録部を有し、ＩＭＳアプリケーション部は、登録部を介して、ブロックチェーンに、利用者の識別子と、利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録し、第１の対象確認サービス部は、対象確認部を介して、利用者に、第２の対象確認情報の開示を要求して、得られた情報を基に対象確認を行い、第２の対象確認サービス部は、対象確認部を介して、利用者に、第２ブロックを特定可能な情報と、第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行い、対象確認部が、利用者に対象確認情報の開示を要求した結果、対象確認情報に代えて利用者から第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される第２ブロック内の対象確認の記録を参照して対象確認を行ってもよい。

【0021】

本発明によるサービス提供方法は、サービスの提供先とされる利用者が使用する個人用端末であって利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供するＳＮＳアプリケーション部と、利用者が、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーンを構成する２以上のノードを備える所定のＩＭＳを利用するための各種処理およびインタフェースを提供するＩＭＳアプリケーション部とを備える個人用端末が備えるＩＭＳアプリケーション部が、サービスを提供するサービスサーバであってＳＮＳのプラットフォームを利用したＳＮＳアプリケーション部との情報のやりとりにより、利用者に、サービスを提供するＳＮＳ側サービス提供部と、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部との情報のやりとりにより、利用者の対象確認を行う対象確認サービス部とを備えたサービスサーバの対象確認サービス部に、所定の方法で、ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、ＳＮＳ側サービス提供部がＳＮＳのプラットフォーム上で利用者を特定可能な情報であるＳＮＳ＿ＩＤを、利用者の対象確認の結果を特定可能な情報とともに送信し、対象確認サービス部が、ＩＭＳアプリケーション部から受信したＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部に通知し、ＳＮＳ側サービス提供部が、対象確認サービス部から通知された利用者の対象確認の結果を基にサービスを提供し、ＩＭＳが、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録し、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行い、ＩＭＳが、ブロックチェーンに、対象確認の記録を含む第２ブロックを登録し、利用者に対象確認情報の開示を要求した結果、対象確認情報に代えて利用者から第２ブロックを特定可能な情報が開示された場合に、開示された情報から特定される第２ブロック内の対象確認の記録を参照して対象確認を行うことを特徴とする。

【発明の効果】

【0022】

本発明によれば、必要最小限の個人情報の開示だけで、ＳＮＳ上で、対象確認を伴うサービスの提供を行うことができる。

【図面の簡単な説明】

【0023】

【図1】第１の実施形態のサービス提供システムの例を示すブロック図である。

【図2】ＬＩＮＥとＳｈｏＣａｒｄを利用した第１のＩＤ受け渡し方法の具体例の概要を示す説明図である。

【図3】ＬＩＮＥとＳｈｏＣａｒｄを利用した第１のＩＤ受け渡し方法の具体例のシーケンス図である。

【図4】ＬＩＮＥとＳｈｏＣａｒｄを利用した第２のＩＤ受け渡し方法の具体例の概要を示す説明図である。

【図5】ＬＩＮＥとＳｈｏＣａｒｄを利用した第２のＩＤ受け渡し方法の具体例のシーケンス図である。

【図6】ＬＩＮＥとＳｈｏＣａｒｄを利用した第３のＩＤ受け渡し方法の具体例の概要を示す説明図である。

【図7】ＬＩＮＥとＳｈｏＣａｒｄを利用した第３のＩＤ受け渡し方法の具体例のシーケンス図である。

【図8】第２の実施形態の個人情報管理システムにおける各種情報の保持例を示す説明図である。

【図9】登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。

【図10】登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。

【図11】確認記録ブロックの例を示す説明図である。

【図12】第２の実施形態の個人情報管理システムの主要な構成を示す構成図である。

【図13】確認部２０２の構成例を示すブロック図である。

【図14】台帳管理ノード３０１の構成例を示すブロック図である。

【図15】第２の実施形態の個人情報管理システムの登録フェーズにおける動作の一例を示すフローチャートである。

【図16】第２の実施形態の個人情報管理システムの登録フェーズにおける動作の他の例を示すフローチャートである。

【図17】第２の実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。

【図18】第２の実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。

【図19】確認フェーズにおける確認機関側システムの動作例を示すフローチャートである。

【図20】第３の実施形態のチケットサービスシステムの概略構成図である。

【図21】第３の実施形態のチケットサービスシステムの動作の概略を示すフローチャートである。

【図22】第３の実施形態の本人登録時の処理の流れの一例を示すシーケンス図である。

【図23】第３の実施形態の購入申請時の処理の流れの一例を示すシーケンス図（１）である。

【図24】第３の実施形態の購入申請時の処理の流れの一例を示すシーケンス図（２）である。

【図25】第３の実施形態の入場申請時の処理の流れの一例を示すシーケンス図である。

【図26】第３の実施形態のチケットサービスシステムの他の例を示すブロック図である。

【図27】本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。

【図28】本発明のサービス提供システムの概要を示すブロック図である。

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

【0024】

実施形態１．
以下、図面を参照して本発明の実施形態について説明する。図１は、第１の実施形態のサービス提供システムの例を示すブロック図である。図１に示すサービス提供システム６００は、個人用端末６１と、ＳＮＳプラットフォーム６２と、ＩＭＳプラットフォーム６３と、サービスサーバ６４とを備える。

【0025】

個人用端末６１は、個人が利用する端末であって、ＳＮＳアプリケーション部（以下、ＳＮＳＡＰＰ部という）６１１と、ＩＭＳアプリケーション部（以下、ＩＭＳＡＰＰ部という）６１２とを含む。

【0026】

ＳＮＳＡＰＰ部６１１は、個人用端末６１のユーザに、所定のＳＮＳを利用するための各種処理およびインタフェースを提供する。なお、ＳＮＳＡＰＰ部６１１は、具体的には、所定のＳＮＳの個人ユーザ向けアプリケーション（ＳＮＳＡＰＰ）の動作主体とされる処理部である。ＳＮＳＡＰＰ部６１１は、個人用端末６１上で該ＳＮＳＡＰＰを動作させることにより、個人用端末６１のユーザに所定のＳＮＳを利用するためのインタフェースの提供および各種処理を行う。

【0027】

ここで、所定のＳＮＳは特に限定されないが、例えば、“LINE”（登録商標）、“Ameba”（登録商標）、“Facebook”（登録商標）、“Google+”（登録商標）、“GREE”（登録商標）、“Instagram”（登録商標）、“LinkedIn”（登録商標）、“mixi”（登録商標）、“skype”（登録商標）、“Twitter”（登録商標）などであってもよい。

【0028】

ＩＭＳＡＰＰ部６１２は、個人用端末６１のユーザに、所定のＩＭＳで提供される対象確認サービスを利用するための各種処理およびインタフェースを提供する。なお、ＩＭＳＡＰＰ部６１２は、具体的には、所定のＩＭＳの個人ユーザ向けアプリケーション（ＩＭＳＡＰＰ）の動作主体とされる処理部である。ＩＭＳＡＰＰ部６１２は、個人用端末６１上で該ＩＭＳＡＰＰを動作させることにより、個人用端末６１のユーザに所定のＩＭＳで提供される対象確認サービスを利用するためのインタフェースの提供および各種処理を行う。

【0029】

ここで、所定のＩＭＳは特に限定されないが、例えば、上述した“ShoCard”や後述する個人情報管理システムであってもよい。なお、対象確認サービスは、これらＩＭＳが提供するような、ブロックチェーンを利用した対象確認サービスに限定されない。

【0030】

ＳＮＳＡＰＰおよびＩＭＳＡＰＰは、例えば、予め個人用端末６１に記憶される。

【0031】

ＳＮＳプラットフォーム６２は、所定のＳＮＳを提供するプラットフォームである。ＳＮＳプラットフォーム６２は、ＳＮＳを提供するシステムの一部であり、例えば、ＳＮＳユーザ向けの機能（例えば、ユーザＩＤを使ったメッセージの送受信、タイムライン機能、ユーザ相互リンク機能、アンケート機能、ユーザ検索機能、コミュニティ機能等）を提供する。ＳＮＳプラットフォーム６２は、具体的には、それらＳＮＳにおける各種機能を実現するためのハードウェアおよびソフトウェアにより実現される。

【0032】

ＩＭＳプラットフォーム６３は、所定のＩＭＳを提供するプラットフォームである。ＩＭＳプラットフォーム６３は、個人情報の管理および照合といった対象確認サービスを提供するシステムの一部であり、例えば、対象確認サービスのユーザ向けの機能（例えば、ユーザＩＤを使った対象確認、そのための個人情報の登録・照合機能等）を提供する。ＩＭＳプラットフォーム６３は、例えば、具体的には、それら対象確認サービスにおける各種機能を実現するためのハードウェアおよびソフトウェアにより実現される。

【0033】

サービスサーバ６４は、ＳＮＳ上で対象確認を含む所定のサービスを提供するための処理を行うサーバであり、ＳＮＳ側サービス提供部６４１と、対象確認サービス部６４２と、ＩＤ連携情報記憶部６４３とを含む。

【0034】

ＳＮＳ側サービス提供部６４１は、ＳＮＳプラットフォーム６２を利用してＳＮＳＡＰＰ部６１１と情報のやりとりを行って、ＳＮＳ上（より具体的には、ＳＮＳプラットフォーム６２上）で対象確認を伴う所定のサービスを提供する処理部である。なお、対象確認については後述する対象確認サービス部６４２を介して行われる。

【0035】

対象確認サービス部６４２は、ＩＭＳプラットフォーム６３を利用してＩＭＳＡＰＰ部６１２と情報のやりとりを行って、ＩＭＳ上（より具体的には、ＩＭＳプラットフォーム６３上）で、ＳＮＳ側サービス提供部６４１が提供するサービスの利用者に対して、該サービスの提供に必要な対象確認を行う。

【0036】

また、対象確認サービス部６４２は、ＳＮＳ側サービス提供部６４１に対象確認の結果を通知する機能を有する。このとき、本実施形態の対象確認サービス部６４２は、ＳＮＳ側サービス提供部６４１がＳＮＳプラットフォーム６２上で本システムのサービス提供先の利用者を特定可能な識別子（以下、ＳＮＳ＿ＩＤという）を用いて、対象確認の結果を通知する。

【0037】

本実施形態の対象確認サービス部６４２は、自身がＩＭＳプラットフォーム６３上で本システムのサービス提供先の利用者を特定可能な識別子であるＩＭＳ＿ＩＤと、該ＩＭＳ＿ＩＤと対応するＳＮＳ＿ＩＤ（少なくともＳＮＳ側サービス提供部６４１がＳＮＳプラットフォーム６２上で該利用者を特定可能な識別子）を取得した上で、該ＩＭＳ＿ＩＤで特定される利用者に対して所定の対象確認を行う。

【0038】

なお、対象確認サービス部６４２は、ＩＭＳプラットフォーム６３を利用して指定のユーザに対して対象確認を要求する機能を含む本システム用の確認側ユーザアプリケーション（確認側ＩＭＳＡＰＰ）の動作主体とされる処理部に相当する。すなわち、対象確認サービス部６４２は、サービスサーバ６４上で該確認側ＩＭＳＡＰＰを動作させることにより、ＩＭＳ上でＳＮＳ側サービス提供部６４１が提供するサービスの利用者に対して、ＩＭＳ＿ＩＤおよびＳＮＳ＿ＩＤの取得および対象確認を行う。

【0039】

ＳＮＳ＿ＩＤおよびＩＭＳ＿ＩＤは、そのＩＤを使用する処理部において、対象プラットフォーム上で該当する利用者を特定可能な情報であればよい。すなわち、ＳＮＳ＿ＩＤは、ＳＮＳ側サービス提供部６４１がＳＮＳプラットフォーム６２上で該当する利用者を特定可能な情報であればよく、ＩＭＳ＿ＩＤは、ＳＮＳ側サービス提供部６４１がＩＭＳプラットフォーム６３上で該当する利用者を特定可能な情報であればよい。一例として、ＳＮＳ＿ＩＤは、対象プラットフォーム上で常に該当する利用者を識別可能な情報（対象プラットフォーム上で常にオープンな利用者ＩＤ等）以外にも、セッションＩＤのような、対象プラットフォーム上で該当する利用者とセッション中のサーバ等が自身で一時的に保持している情報と照合すること等により該当する利用者を特定可能な情報であってもよい。

【0040】

ＩＤ連携情報記憶部６４３は、必要に応じて、サービス提供先の利用者のＳＮＳ_ＩＤとＩＭＳ＿ＩＤとを対応づけた情報であるＩＤ連携情報を記憶する。

【0041】

本実施形態では、サービスサーバ６４においてＩＭＳ＿ＩＤとＳＮＳ＿ＩＤのＩＤ連携を可能にするために、ＳＮＳＡＰＰからＩＭＳＡＰＰへおよびＩＭＳＡＰＰから対象確認サービス部６４２へ該当する利用者のＳＮＳ＿ＩＤの受け渡しを行う。このようなＩＤの受け渡しの具体的な方法としては、例えば、次の３つの方法が挙げられる。

【0042】

（第１のＩＤ受け渡し方法）
第１のＩＤ受け渡し方法は、本サービスを利用したい個人ユーザからＳＮＳＡＰＰを利用してＳＮＳ側サービス提供部６４１宛てに送信されるメッセージに対する個人用端末６１への応答メッセージを利用して、個人用端末６１上でＩＭＳＡＰＰを起動させることにより行う。具体的には、起動の際、ＩＭＳＡＰＰに、ＳＮＳ＿ＩＤとして、ＳＮＳプラットフォーム上でサービス提供先利用者を特定可能なＩＤを通知し、該ＩＭＳＡＰＰから、自身に割り当てられたＩＭＳ_ＩＤとともに起動時に通知されたＳＮＳ＿ＩＤを、サービスサーバ６４上の確認側ＩＭＳＡＰＰの動作主体に相当する対象確認サービス部６４２に通知する。

【0043】

ＳＮＳプラットフォームの多くは、個人ユーザと任意のサーバ（いわゆるチャットボット等）との間でメッセージを交換（送受信）するためのＡＰＩ（Application Programming Interface）（以下、メッセージ用ＡＰＩという）を提供している。このようなＡＰＩを利用すれば、送信元ユーザに、任意のメッセージを自動で送信することができる。

【0044】

また、ＳＮＳ側からのＩＭＳＡＰＰの自動起動は、例えば、次のようにして実現できる。まず、webhookのような、所定のイベント発生時に指定したＵＲＬ（Uniform Resource Locator）にＰＯＳＴリクエストを送信する仕組みを利用して、サービスサーバ６４のＳＮＳ側サービス提供部６４１が個人ユーザのＳＮＳ＿ＩＤを含むメッセージを受信できるようにする。その上で、該メッセージ受信に対する応答シーケンスの中で送信されるＷｅｂページのリンクにカスタムＵＲＬスキーム（ディープリンクとも呼ばれる）を埋め込む。

【0045】

ディープリンクを使用すると、アプリケーションの特定の画面に遷移させることができるだけでなく、スキームを独自に定義すれば、他のアプリケーションの起動や該アプリケーションに対して情報を受け渡すなど、アプリケーション間の遷移を行うことができる。

【0046】

第１のＩＤ受け渡し方法では、サービスサーバ６４のＳＮＳ側サービス提供部６４１が、ＳＮＳ上のメッセージ用ＡＰＩを利用して本サービスの提供を要求するメッセージを送信してきた個人ユーザの端末（個人用端末６１）に、本サービス用の応答メッセージを送信する。その際、応答メッセージ中に、所定のアプリケーション間連携機能を実行するためのコードを埋め込む。これにより、ユーザがその機能の実行を選択した際に、個人用端末６１上に本サービス用のＩＭＳＡＰＰを自動起動させることができる。さらにこのとき、ＩＭＳＡＰＰの起動パラメータに該個人ユーザのＳＮＳ＿ＩＤを含ませる。これにより、ＩＭＳＡＰＰ部６１２が、該個人ユーザのＩＭＳ＿ＩＤだけでなく、ＳＮＳ＿ＩＤを取得できるようにする。

【0047】

ＩＭＳＡＰＰ部６１２は、例えば、ユーザの許可の下、本システムにおける確認側ＩＭＳＡＰＰの動作主体に相当するサービスサーバ６４の対象確認サービス部６４２に、自身に割り当てられたＩＭＳ_ＩＤとアプリ起動時に取得したＳＮＳ＿ＩＤとを通知する。起動されるＩＭＳＡＰＰは、予め本サービス用にそのような通知機能が実装されたアプリケーションであって、通知先の宛先情報を知っているものとする。なお、ＩＭＳＡＰＰ起動時に、ＳＮＳ＿ＩＤと併せて通知先の宛先情報としてサービスサーバ６４の情報（ＵＲＬ等）を受け渡すことも可能である。ＩＭＳＡＰＰ部６１２から対象確認サービス部６４２へのＩＭＳ＿ＩＤおよびＳＮＳ＿ＩＤの通知は、ＩＭＳプラットフォーム６３を利用して行うことも可能である。

【0048】

対象確認サービス部６４２は、ＩＭＳＡＰＰからサービス要求元の利用者のＩＭＳ＿ＩＤとＳＮＳ＿ＩＤとが通知されると、これらを対応づけてＩＤ連携情報記憶部６４３に記憶した上で、ＩＭＳプラットフォーム６３を利用して通知元の個人用端末６１上のＩＭＳＡＰＰとの間で対象確認シーケンスを開始し、対象確認の結果を受け取る。

【0049】

対象確認シーケンス自体は、ＩＭＳプラットフォーム６３から提供されるＡＰＩ等を利用して行えばよい。例えば、ＩＭＳプラットフォーム６３は、予め契約等により対象確認を依頼する権限を持つユーザ側アプリケーション（本例では、サービスサーバ６４の対象確認サービス部６４２が対応）に対して、ＩＭＳ＿ＩＤを指定した対象確認要求を受け付けるＡＰＩを提供する。

【0050】

ＩＭＳプラットフォーム６３は、そのようなＡＰＩを通じて、対象確認の相手先とされるＩＭＳ＿ＩＤが指定された対象確認要求を受け付ける。対象確認要求を受け付けると、ＩＭＳプラットフォーム６３は、指定されたＩＭＳ＿ＩＤで特定される個人ユーザの個人用端末６１上のＩＭＳＡＰＰに向けて、対象確認に必要な個人情報の開示を要求するメッセージを送信する。個人用端末６１上のＩＭＳＡＰＰ（本例では、ＩＭＳＡＰＰ部６１２が対応）は、個人情報の開示を要求するメッセージを受信するとその旨をユーザに通知する。その後、ＩＭＳＡＰＰは、ユーザ操作に応じて、要求された個人情報をＩＭＳプラットフォーム６３に送信する。

【0051】

ＩＭＳプラットフォーム６３は、ＩＭＳＡＰＰから受信した個人情報と自身で保有している該ユーザの個人情報とを照合等して、現在ＩＭＳＡＰＰを操作しているユーザに対して、ＡＰＩで要求された対象確認を行う。ＩＭＳプラットフォーム６３は、例えば、照合の結果、現在ＩＭＳＡＰＰを操作しているユーザが、指定のＩＭＳ＿ＩＤで特定されているユーザ本人であるか否か、また必要に応じて所定の条件を満たしているか否か等を判定し、その結果を要求元の確認側ＩＭＳＡＰＰ（サービスサーバ６４の対象確認サービス部６４２）に送信する。

【0052】

対象確認サービス部６４２は、ＩＭＳプラットフォーム６３からＩＭＳ＿ＩＤで特定される個人ユーザに対する対象確認の結果を受信すると、その結果を、ＳＮＳ側サービス提供部６４１に、ＩＤ連携情報記憶部６４３において該ＩＭＳ＿ＩＤと対応づけられているＳＮＳ＿ＩＤとともに通知する。

【0053】

なお、対象確認サービス部６４２は、対象確認が成功した場合、その応答メッセージとしてＩＭＳＡＰＰに送信するＷｅｂページのリンクにカスタムＵＲＬスキームを埋め込むことで、ユーザ操作に応じて、ＳＮＳＡＰＰの元のサービス画面に戻れるようにしてもよい。

【0054】

図２および図３に、第１のＩＤ受け渡し方法の具体例を示す。図２は第１のＩＤ受け渡し方法の具体例の概要を示す説明図であり、図３は本具体例のシーケンス図である。図２および図３はいずれもＳＮＳとして“LINE”を利用し、ＩＭＳとして“ShoCard”を利用した場合の具体例である。

【0055】

本例では、次のようにしてＩＤの受け渡しおよびサービス提供先の利用者に対する本人確認を行っている。本例では、LINE BotがＳＮＳ側サービス提供部６４１に相当し、LINE APPがＳＮＳＡＰＰ部６１１に相当する。また、ShoCard APPがＩＭＳＡＰＰ部６１２に相当し、ShoCardサービスが対象確認サービス部６４２に相当する。本例において、LINE Botは、例えば、LINEプラットフォームが提供するMessaging APIやその他のSDKを用いて本作成用に作成されたアプリケーションである。また、ShoCard APPおよびShoCardサービスは、例えば、ShoCard社が提供するShoCardSDKを用いて本システム用に作成されたアプリケーションである。なお、LINE APPは、一般的な個人向けLINEアプリケーションでよい。なお、他の例も同様である。

【0056】

・LINE Botは、自身にメッセージを送信してきた利用者のLINE APPに本システム用のリッチメニューを追加する（図中の１〜４）。なお、該リッチメニューは、選択されると、個人用端末上の本人確認用アプリケーションであるShoCard APPを、自身（この場合、端末側のLINE APP）のＳＮＳ＿ＩＤに相当するuserId（LINEプラットフォームで使用される内部識別ＩＤ）を引き渡して自動起動させるよう構成されたメニューである。
・LINE APPは、該リッチメニューが選択されると、メニューに従い、個人用端末上でShoCard APPを自動起動させる（図中の５）。
・起動されたShoCard APPは、起動パラメータとして、userIdを取得する（図中の６）。
・userIdを取得したShoCard APPは、自身のShoCardID（ＩＭＳ＿ＩＤ相当）と併せてuserIdをサーバ側のShoCardサービスに通知する（図中の７）。
・ShoCardIDとuserIdとが通知されたShoCardサービスは、これらを対応づけて所定の記憶部に記憶した上で（図中の８）、サーバ側から本人確認シーケンスを開始する（図中の９〜１２）。
・ShoCardサービスは、本人確認シーケンスが完了すると、LINE Botに確認結果を通知する（図中の１４）、または所定の記憶部に確認結果を記憶しておき、LINE Botからの問合せを待つ（図中の１３、１４）。

【0057】

個人用端末上で指定したアプリケーションを自動起動する方法として、例えば、リッチメニューから遷移するWebサービス画面にカスタムURLスキームを埋め込む方法が挙げられる。

【0058】

次に、図３を参照して、本方法におけるデータのやりとりをより詳細に説明する。図３に示す例では、まず、利用者が自身の端末上のLINE APPを操作して、LINEプラットフォームを介してLINE Bot宛てに利用開始メッセージを送信する（ステップＳ６０１〜ステップＳ６０３）。

【0059】

このとき、利用者のLINEメッセージは、MessagingAPIによりwebhookが取得され、LINEプラットフォームから宛先により特定される本システムのLINE Botのwebhook URL宛にリクエストが送信される。このとき、LINE Botには、送信元ユーザを特定する情報として、LINEプラットフォーム上でユニークな内部識別ＩＤ（userId）を含むJSONデータが渡される。

【0060】

LINE Botは、利用開始メッセージにかかるリクエストを受け取ると、LINE APPに所定のHTTP応答メッセージを送信し、本システム用のメニューをリッチメニューに追加して表示させる（ステップＳ６０４，ステップＳ６０５）。

【0061】

利用者がそのメニューを選択すると、サービスサーバの特定のURL宛にWebページのリクエストが送信される（ステップＳ６０６、ステップＳ６０７）。なお、本例では、LINE Botがリクエストを受け付ける例を示しているが、当該リクエストに対する処理の実装方法は特に限定されない。例えば、ShoCardサービスが受け付けてもよいし、他のサービス（サービスサーバ上の共通のWebサーバサービス等）が受け付けてもよい。

【0062】

リクエストを受け付けたサービスサーバは、リンクにカスタムURLスキームが埋め込まれたWebページを応答メッセージとして返信する（ステップＳ６０８、ステップＳ６０９）。該カスタムURLスキームは、リンクをタップすると、個人用端末６１上でShoCard APPが起動されるとともに、起動パラメータとしてuserIdが引き渡されるように構成されている。

【0063】

サービスサーバからWebページを受信した個人用端末６１のLINE APPは、受信したWebページを表示する（ステップＳ６１０）。

【0064】

利用者がそのWebページに表示されたリンクをタップすると、該リンクに埋め込まれたカスタムURLスキームに従って、個人用端末６１上でShoCard APPが起動されるとともに、起動パラメータとしてuserIdが引き渡される（ステップＳ６１１）。

【0065】

ShoCard APPは、起動パラメータとして受け取ったuserIdと自身のShoCardIDのペアを、サービスサーバのShoCardサービスに通知する（ステップＳ６１２）。

【0066】

サービスサーバのShoCardサービスは、ShoCard APPからuserIdとShoCardIDのペアが通知されると、これらを対応づけて所定の記憶部に記憶した上で（ステップＳ６１３）、本人確認シーケンスを開始する（ステップＳ６１４〜ステップＳ６２９）。

【0067】

図中の本人確認シーケンスは、サービスサーバ側から本人確認シーケンスを開始する場合の例である。

【0068】

まず、サービスサーバのShoCardサービスが、ShoCardプラットフォームを介して、ShoCard APPに本人確認のための情報開示を要求する（ステップＳ６１４、ステップＳ６１５）。このとき、ShoCardサービスからShoCardプラットフォームへのメッセージには、ShoCardプラットフォーム上で確認先の利用者を特定する識別子である“toShoCardID”が含まれる。一方、ShoCardプラットフォームからShoCard APPへのメッセージには、ShoCardプラットフォーム上で確認依頼元の利用者を特定するためのShoCardIDであるsenderShoCardIDが含まれる。

【0069】

本人確認のための情報開示の要求を受け取ると、ShoCard APPは、顔認証による本人確認を行う（ステップＳ６１６〜ステップＳ６２２）。なお、過去にそのサーバからの要求に対し本人確認が完了していれば、当該処理を省略して、ShoCardプラットフォーム上にあるその記録の情報とともに自身が保持している本人確認に必要な情報を返してもよい（ステップＳ６２３〜ステップＳ６２４）。

【0070】

ステップＳ６１６では、例えば、個人用端末６１が備えるカメラ装置を利用して利用者の顔を撮影し、本人確認用の個人情報として現在の利用者の顔写真を取得する。

【0071】

ステップＳ６１７〜ステップＳ６１９では、取得した顔写真（またはそれに基づく情報）を使って、ShoCardプラットフォーム上の情報と照合を行い、該情報（顔写真）の保有者が、指定されたShoCardIDで特定される利用者本人であるか否かを検証し、その結果を取得する。

【0072】

ステップＳ６２０〜ステップＳ６２２は、自己の本人確認の結果をShoCardプラットフォームに記録する処理である。

【0073】

このようにして自己の本人確認が完了すると、ShoCard APPは、必要に応じて、本システムのサービス提供において本人確認（または対象確認）のために必要な情報を、ShoCardサービスに送信する（ステップＳ６２３、ステップＳ６２４）。該情報は、提供された側でその情報を参照することにより所望の対象確認が行えるものであれば特に限定されない。例えば、顔写真等の生体情報でもよいし、免許証画像など所定の認証機関が発行した個人情報でもよいし、事前にShoCardプラットフォーム内に記憶されている、本システムのサービス加入者であることを示す情報（契約者識別ＩＤ等）等でもよい。また、ShoCardプラットフォームに保持されている自己の本人確認の結果の記録の識別子等でもよい。

【0074】

ShoCardサービスは、受信した情報を使って、ShoCardプラットフォーム上の情報と照合を行い、該情報の保有者である送信元の利用者が、指定されたShoCardIDで特定される利用者本人であるか否かを検証し、その結果を取得する（ステップＳ６２５〜ステップＳ６２７）。なお、ステップＳ６２５〜ステップＳ６２７の処理は、ステップＳ６１７〜ステップＳ６１９と同様である。

【0075】

また、ShoCardサービスは、開示された情報の確認結果を該情報の送信元のShoCard APPに送信する（ステップＳ６２８、ステップＳ６２９）。なお、図示省略しているが、ShoCardサービスは、例えば、本人確認の結果を所定の記憶部にShoCardIDとともに記憶しておき、LINE Botからの問合せの際に参照できるようにしておく。

【0076】

ShoCard APPは、自己およびサーバ側での本人確認の結果を受けて、起動元のLINE APPに処理を戻してもよい。

【0077】

（第２のＩＤ受け渡し方法）
第２のＩＤ受け渡し方法は、ＳＮＳＡＰＰを利用してＳＮＳ側サービス提供部６４１宛てに送信されるメッセージに対する個人用端末６１への応答メッセージを利用して、個人用端末６１上でＩＭＳＡＰＰを起動させるまでは第１のＩＤ受け渡し方法と同様である。第２のＩＤ受け渡し方法では、起動の際、ＩＭＳＡＰＰには、本人確認の結果の通知先とするサーバ側のＩＭＳ＿ＩＤと、サービス提供先の利用者のＳＮＳ＿ＩＤとして、ＳＮＳ側サービス提供部６４１がＳＮＳプラットフォーム上における該利用者を特定可能なセッションＩＤとを通知する。そして、端末側のアプリケーションであるＩＭＳＡＰＰから本人確認シーケンスを開始して、その結果を、起動時に通知されたＩＭＳ＿ＩＤを使ってサーバ側（サービスサーバ６４の対象確認サービス部６４２）にセッションＩＤとともに通知する。対象確認サービス部６４２は、ＩＭＳＡＰＰから本人確認の結果を受け取ると、セッションＩＤとともにＳＮＳ側サービス提供部６４１に通知する。

【0078】

なお、第２の受け渡し方法では、サービスサーバ６４は、サービス提供先の利用者のＩＭＳ_ＩＤとＳＮＳ＿ＩＤとの対応づけを行わず、ＩＤ連携情報も保持しない。

【0079】

図４および図５に、第１のＩＤ受け渡し方法の具体例を示す。図４は第１のＩＤ受け渡し方法の具体例の概要を示す説明図であり、図５は本具体例のシーケンス図である。本例でもＳＮＳとして“LINE”を利用し、ＩＭＳとして“ShoCard”を利用している。

【0080】

本例では、次のようにしてＩＤの受け渡しおよびサービス提供先の利用者に対する本人確認を行っている。
・カスタムURLスキームによるShoCard APP起動までは第１のＩＤ受け渡し方法と同様である（図中の１〜４）。
・ただし、リッチメニューは、ShoCard APP起動時に、サーバ側のShoCardID（senderShoCardID）と、ＳＮＳプラットフォームでサービス提供先の利用者とのメッセージのやりとりに対して割り当てたsessionIdとを引き渡すように構成される（図中の３：カスタムURLスキーム内）。
・LINE APPは、該リッチメニューが選択されると、メニューに従い、個人用端末６１上でShoCard APPを自動起動させる（図中の５）。
・起動されたShoCard APPは、起動パラメータとして、サーバ側のShoCardIDとsessionIdとを取得する（図中の６）。
・ShoCard APPは、本人確認シーケンスを開始する（図中の７）。このとき、ShoCard APPは、必要に応じて、サーバ側のShoCardサービスに本人確認のための情報開示を行ってもよい（図中の８）。
・ShoCard APPは、本人確認シーケンスが完了すると、起動時に取得したsenderShoCardID宛に確認結果を通知する（図中の９）。このとき、起動時に取得したsessionIdも併せて通知する。
・ShoCardサービスは、ShoCard APPからsessionIdを含む本人確認結果を受信すると、本人確認結果をLINE Botに通知する（図中の１１）。このとき、ShoCardサービスは、通知された確認結果にかかる確認の記録がShoCardプラットフォーム上に記録されているかを確認した上で、LINE Botに通知してもよい。

【0081】

次に、図５を参照して、本方法におけるデータのやりとりをより詳細に説明する。図５に示す例において、ステップＳ６０１〜ステップＳ６１１は、基本的に、第１のＩＤ受け渡し方法と同様のため説明を省略する。

【0082】

なお、本例では、LINE Botは、送信元ユーザを特定する情報として、userIdだけでなく、JSONデータに含まれるsessionIdを管理しているものとする。

【0083】

また、本例では、ステップＳ６０８およびステップＳ６０９で、リンクをタップすると、個人用端末６１上でShoCard APPが起動されるとともに、起動パラメータとしてsenderShoCardIDおよびsessionIdが引き渡されるように構成されたカスタムURLスキームが埋め込まれたWebページを応答メッセージとして返信する。

【0084】

ステップＳ６１１で、個人用端末６１上でShoCard APPが起動されると、ShoCard APPは、本人確認シーケンスを開始する（ステップＳ６１４〜ステップＳ６２９）。

【0085】

図中の本人確認シーケンスは、端末側から本人確認シーケンスを開始する場合の例である。なお、ステップＳ６１４およびステップＳ６１５が省略される点が異なるが、基本的には、第１のＩＤ受け渡し方法における本人確認シーケンスと同様である。

【0086】

本方法でも、自己の本人確認が完了すると、ShoCard APPは、必要に応じて、本システムのサービス提供において本人確認のために必要な情報を、ShoCardサービスに送信する（ステップＳ６２３、ステップＳ６２４）。

【0087】

ShoCardサービスは、受信した情報を使って、ShoCardプラットフォーム上の情報と照合を行い、該情報の保有者である送信元の利用者が、指定されたShoCardIDで特定される利用者本人であるか否かを検証し、その結果を取得する（ステップＳ６２５〜ステップＳ６２７）。また、ShoCardサービスは、開示された情報の確認結果を該情報の送信元のShoCard APPに送信する（ステップＳ６２８、ステップＳ６２９）。

【0088】

このようにして、ShoCard APPは、自己およびサーバ側での本人確認の結果を受けると、その結果を、起動パラメータとして受け取ったsenderShoCardID宛に、sessionIdとともに通知する（ステップＳ６３０）。

【0089】

その後、ShoCard APPは、起動元のLINE APPに処理を戻してもよい。

【0090】

（第３のＩＤ受け渡し方法）
第３のＩＤ受け渡し方法は、ＳＮＳプラットフォームが他のアプリケーション向けに提供しているＳＮＳログインサービスを利用して、ＩＭＳＡＰＰが、利用者のＳＮＳ＿ＩＤを取得して、自身のＩＭＳ＿ＩＤとともに対象確認サービス部６４２に通知する。

【0091】

本方法では、利用者に、ＩＭＳＡＰＰから本システムでのサービス提供の場である所定のＳＮＳにログインさせる。ＳＮＳログインサービスを利用してＳＮＳにログインすることにより、その利用者がＳＮＳプラットフォーム上で使用しているＳＮＳ＿ＩＤ（例えば、上記のuserId等）を知ることができる。ＩＭＳＡＰＰは、例えば、利用者にＳＮＳへのログインを促すメッセージ等を出力するなどして、利用者に所定のＳＮＳにログインさせてもよい。なお、ＩＭＳＡＰＰからＳＮＳへのログインのタイミングは特に限定されない。本システム用のＩＭＳＡＰＰの利用開始時でもよいし、利用者がＳＮＳ側サービス提供部６４１にサービスを要求するごとに、その旨のメッセージを送信するなどして利用者にログインを促すことも可能である。

【0092】

ＩＭＳＡＰＰは、ＳＮＳログインサービスを利用して利用者のＳＮＳ_ＩＤを取得すると、自身のＩＭＳ_ＩＤと併せてサービスサーバ６４の対象確認サービス部６４２に通知する。通知方法は、第１のＩＤ受け渡し方法のように取得後すぐに通知してもよいし、第２のＩＤ受け渡し方法のように、本人確認完了後に通知することも可能である。なお、通知の方法は特に問わない。

【0093】

また、通知を受け取った対象確認サービス部６４２では、受け取ったＩＭＳ_ＩＤとＳＮＳ＿ＩＤとを対応づけてＩＤ連携情報記憶部６４３に記憶する。これにより、ＳＮＳ＿ＩＤで指定されるＳＮＳ側サービス提供部６４１からの本人確認の問合せ等に対して、対応する利用者の本人確認結果を返信できる。

【0094】

図６および図７に、第３のＩＤ受け渡し方法の具体例を示す。図６は第３のＩＤ受け渡し方法の具体例の概要を示す説明図であり、図７は本具体例のシーケンス図である。本例でもＳＮＳとして“LINE”を利用し、ＩＭＳとして“ShoCard”を利用している。なお、図６（ａ）はＩＤ連携をするまでの処理の概要を示し、図６（ｂ）はＩＤ連携後の処理の概要を示している。

【0095】

本例では、次のようにしてＩＤの受け渡しおよびサービス提供先の利用者に対する本人確認を行っている。
・ShoCard APPが利用者より起動されると、利用者にLINEログインを要求する。ShoCard APPは、ユーザ操作に応じて、LINEログインサービスを利用してLINEログインを行い、その結果として利用者のuserIdを取得する（図中の１〜３）。
・userIdを取得したShoCard APPは、ユーザ操作に応じて本システムのサービスで必要な個人情報等の登録を行った上で（図中の４）、ShoCardサービスに自身のShoCardIDと取得したuserIdのペアを通知する（図中の５）。
・ShoCardサービスは、ShoCardIDとuserIdのペアが通知されると、それらを対応付けて所定の記憶部に記憶する（図中の６）。

【0096】

・LINE APPは、ユーザ操作に応じて、本システムのLINE Botにメッセージを送信する（図中の７）。
・LINE Botは、自身宛てのメッセージを受信すると（図中の８）、または受信後、送信元の利用者のLINE APPとメッセージのやりとりをする中で、ShoCardサービスに該利用者のuserIdを指定した本人確認の問合せを行う（図中の９）。
・ShoCardサービスは、LINE Botからの問合せに応じて、所定の記憶部に記憶されているＩＤ連携情報を基に、その利用者の本人確認状況を取得する（図中の１０）。このとき、本人確認が完了していればその旨を通知し、完了していない場合には、サーバ側から本人確認シーケンスを開始する（図中の１１〜１４）。
・ShoCardサービスは、本人確認シーケンスが完了すると、LINE Botに確認結果を通知する（図中の１５）。

【0097】

次に、図７を参照して、本方法におけるデータのやりとりをより詳細に説明する。図７に示す例では、まず、利用者が自身の端末上のShoCard APPを起動し、LINEログインを行う（ステップＳ６４１）。ShoCard APPは、ログイン結果として、userIdを取得する（ステップＳ６４２）。

【0098】

userIdを取得したShoCard APPは、ShoCardサービスに自身のShoCardIDと取得したuserIdのペアを通知する（ステップＳ６４３）。

【0099】

ShoCardサービスは、ShoCard APPからuserIdとShoCardIDのペアが通知されると、これらを対応づけて所定の記憶部に記憶した上で（ステップＳ６４４）、通知されたShoCardIDを指定した本人確認シーケンスを開始する（ステップＳ６４５）。なお、本人確認シーケンスは、図３に示す本人確認シーケンスと同様でよい。このときの本人確認の結果を、所定の記憶部に少なくともShoCardIDと対応づけて記憶してもよい。

【0100】

次いで、利用者が自身の端末上のLINE APPを操作して、LINEプラットフォームを介してLINE Bot宛てに利用開始メッセージを送信する（ステップＳ６５１〜ステップＳ６５３）。

【0101】

LINE Botは、利用開始メッセージにかかるリクエストを受け取ると、LINE APPにＯＫを返信するとともに（ステップＳ６５４）、ShoCardサービスにuserIdを指定した本人確認の問合せを行う（ステップＳ６５５）。

【0102】

本人確認の問合せを受け付けたShoCardサービスは、所定の記憶部を参照して本人確認の結果が登録されているか否かを確認し（ステップＳ６５６）、登録されていなければ、対応するShoCardIDを用いて本人確認シーケンスを開始する（ステップＳ６５７）。なお、本人確認シーケンスは、図３に示す本人確認シーケンスと同様でよい。

【0103】

ShoCardサービスは、本人確認が完了すると、その結果を、対応するuserIdを用いてLINE Botに通知する（ステップＳ６５８）。

【0104】

LINE Botは、ShoCardサービスから本人確認結果が通知されると、userIdで特定されるLINE APPに、応答メッセージを送信する（ステップＳ６５９〜ステップＳ６６１）。応答メッセージは、本システムのサービスの提供にかかるメッセージであってもよい。応答メッセージは、例えば、ステップＳ６５１やその後のやりとりでチケットの予約を要求された場合においてチケットの予約結果を示すメッセージ等であってもよい。

【0105】

なお、上記の例では、サービス提供先とされる任意のＳＮＳ上の利用者に対して本人確認を含むサービスを提供する際のＩＤの受け渡し方法について説明したが、ＩＭＳ上で行うサービス提供にかかる前処理は、本人確認以外にも、例えば、ユーザ認証や適格性確認であってもよく、また、それらの組み合わせであってもよい。

【0106】

また、上記のＩＤの受け渡し方法の具体例では、“LINE”と“ShoCard”を利用する例を示したが、利用するＳＮＳおよびＩＭＳはこれらに限定されない。

【0107】

以上のように、本実施形態によれば、サービスサーバ６４の対象確認サービス部６４２が、サービス提供先の利用者のＩＭＳ_ＩＤと併せてＳＮＳ_ＩＤを取得することができるので、サービスサーバ６４上でこれらＩＤを連携させることができる。ＳＮＳ上でサービスを提供するサーバ上で利用者のＩＭＳ＿ＩＤとＳＮＳ＿ＩＤの連携がとれるので、該サーバでサービス提供に必要な最小限の個人情報の開示を要求するだけで、対象確認を含むサービスを提供することができる。

【0108】

実施形態２．
以下の実施形態では、上記のＳＮＳクライアント連携を含むサービス提供システムにおいてＩＭＳとして利用可能な個人情報管理システムについて説明する。

【0109】

まず、本発明における個人情報管理システムの技術コンセプトを簡単に説明する。

【0110】

本発明における個人情報管理システムでは、種々の個人情報と利用者とを対応づける識別情報として１つの個人ＩＤを割り当てる。より具体的には、対象確認に利用される種々の個人情報を、利用者ごとに割り当てられた１つの個人ＩＤに対応づけてセキュアに管理する。なお、個人ＩＤは、その利用者が所有する全ての個人情報に対応づけられることが好ましいが、少なくとも本発明が提供する個人情報管理システムが管理する個人情報と対応づけられていればよい。その場合も、個人ＩＤは、個人情報管理システム内において、対象確認に利用される種々の個人情報に対応づけられる１つの識別情報、すなわち集約された識別番号であるといえる。

【0111】

また、本発明における個人情報管理システムでは、利用者の個人情報を管理するための機構として、ブロックチェーンを利用する。ここで、ブロックチェーンは、ブロックとよばれる所定のデータ構造を有するデータ群を時系列に並べたものであり、取引内容を記した台帳としての役割を有する。各ブロックは、取引内容等の当該ブロックに記録したいデータの他に、一つ以上前のブロック（以下、前ブロックという）の情報と、改ざんの有無を検知するための情報（ノンスや署名など）とを含む。ノンスは、あるデータ領域に対して、その領域内のデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように設定される、当該データ領域内の値である。ブロックチェーンには、２台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される。例えば、コンセンサスアルゴリズムの一つであるＰｏＷ（Proof of Work）では、前ブロックの情報とノンスとを含む各ブロック（データ群）に対して、「ブロックのＨａｓｈ値が閾値（ターゲット値）以下であること」といった規則が予め決められており、ブロックを追加する際に、そのような規則を満たすようなノンスを複数のノードが同時並列的に探索する処理が行われる。なお、ＰｏＷ以外にもＢＦＴ（Byzantine fault tolerance）等のコンセンサスアルゴリズムがある。

【0112】

ただし、ブロックチェーンには個人情報をそのまま記録せずに、個人ＩＤのハッシュ値と対応づけて個人情報のハッシュ値を記録する。その際、ハッシュ値に対して該ハッシュ値を作成した者（作成元）の署名を付す。署名は、例えば、個人情報の所有者である本人の署名や、個人情報が正しいこと（Correctness）を確認した第三者機関（以下、確認機関という）の署名などである。署名として、署名者の秘密鍵で、署名対象の情報（この場合、ハッシュ値）を暗号化して得られたデジタル署名を利用できる。ハッシュ値に作成元の署名を付すことで、該ハッシュ値の信頼性（reliability）、より具体的には、該ハッシュ値が署名者本人によって作成されたもの（作成元証明）であり、かつ署名時点から改ざんされていないこと（非改ざん証明）を、該ハッシュ値を参照する側が確認できるようにする。このようなハッシュ値の作成者証明と非改ざん証明とを行うことより、登録情報であるハッシュ値が信頼できる情報、すなわち正規の所有者が所持している情報または確認機関がその正当性を確認した情報から作成された情報であることが、署名から確認できるようにする。なお、署名を付す処理に代えて暗号化を行うことも可能である。

【0113】

なお、ブロックチェーンに登録された情報（ハッシュ値やそれに付される署名）自体の信頼性は、ブロックチェーンの改ざん困難性によって担保する。

【0114】

一方で、ハッシュ値の元データである個人情報は、本人以外の者に隠ぺいされるようセキュアな環境に保持される。例えば、個人情報は、本人が所持するデバイス（以下、クライアントデバイスという）内のセキュア領域に記憶されたり、分散ファイルサーバに暗号化して記憶されてもよい。利用者は、このようなセキュアな環境に置かれた個人情報について、自由に開示するか否か、開示する場合にはどの個人情報を開示するかをコントロールできる。

【0115】

本発明における個人情報管理システムでは、第三者が参照可能なブロックチェーンには、その個人ＩＤ（ブロック内の個人ＩＤのハッシュ値の元データである個人ＩＤ）と対応づけられる利用者の個人情報としての正しさを示す情報のみを記憶することで、個人情報の秘匿性を担保する。また、その際、個人情報の所有者を識別するための識別情報を１つにまとめることで、これまで用途ごとに異なっていた対象確認の手続きを、１つの識別情報（個人ＩＤ）で指定される統一的な処理により行えるようにする。

【0116】

さらに、本発明における個人情報管理システムでは、ブロックチェーンに記憶されている該利用者の個人情報のハッシュ値を利用して対象確認を行った場合に、その確認の記録を示すブロックを該ブロックチェーンに追加していく。このように、ブロックチェーンに確認の記録の履歴を残すことで、具体的な個人情報の開示を伴わずに同様の目的の対象確認に、過去の対象確認の結果を利用できるようにする。例えば、過去に同様の目的で対象確認が行われた利用者に対しては、個人情報の開示を要求しなくても、個人情報のハッシュ値を利用してブロックチェーン内の情報と照合を行うだけで、過去の対象確認の結果と同様の結果を与えることができるようにする。これにより、個人情報の開示を最小限に抑える。

【0117】

なお、本発明における個人情報管理システムでは、利用者と個人情報とを結びつけるための情報として個人ＩＤを利用しているが、個人ＩＤは携帯電話機やＩＣカードや認証デバイスのような唯一のデバイスと対応づけて管理されるものではないため、仮にデバイス等が紛失したとしても登録済みの情報の書き換え等を行うことなくリカバリが可能となる。

【0118】

次に、具体的なシステム構成を提示しつつ、本発明における個人情報管理システムの実施形態を説明する。

【0119】

図８は、第２の実施形態の個人情報管理システムにおける各種情報の保持例を示す説明図である。図８には、利用者が所持するクライアントデバイス１と、確認機関が所持する確認機関デバイス２と、ブロックチェーン３とが示されている。

【0120】

図８において、クライアントデバイス１には、その利用者本人の署名用の鍵ペア（秘密鍵１１Ｄと公開鍵１２Ｄ）と、個人情報管理システムから利用者に割り当てられた個人ＩＤ１３Ｄとが保持される。なおクライアントデバイス１において、個人ＩＤ１３Ｄは、１つ以上の個人情報１４Ｄと対応づけられている。

【0121】

また、確認機関デバイス２には、その確認機関の署名用の鍵ペア（秘密鍵２１Ｄと公開鍵２２Ｄ）が保持される。

【0122】

また、ブロックチェーン３には、以下に示すような登録ブロックや確認記録ブロックが保持される。

【0123】

例えば、ある個人が個人情報管理システムの利用を開始すると、利用者となるその個人に個人ＩＤ１３Ｄが割り当てられるとともに、署名用の鍵ペア（秘密鍵１１Ｄと公開鍵１２Ｄ）が生成される。個人ＩＤ１３Ｄが割り当てられ、鍵ペアが生成されると、利用者は、クライアントデバイス１を操作して、個人ＩＤ１３Ｄのハッシュ値と、登録したい個人情報１４Ｄ（特に、対象確認に用いられる個人情報）のハッシュ値とを算出し、それらを含む個人情報管理ブロックを作成してブロックチェーンに追加する。

【0124】

図８には、ブロックチェーン３に追加された登録ブロックの例として、ブロックｎ−１が示されている。登録ブロックには、個人ＩＤ＿Ｈａｓｈ３１Ｄ（上記の個人ＩＤ１３Ｄのハッシュ値に対応）と、個人情報Ｈａｓｈ３２Ｄ（上記の個人情報１４Ｄのハッシュ値に対応）と、それらの作成元である本人の署名３３Ｄとが含まれる。ここで、本人の署名３３Ｄは、当該ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄが、元データの正規の所有者である利用者本人によって作成されたものであることを示すための署名である。

【0125】

個人情報Ｈａｓｈ３２Ｄは、該個人情報の所有者である利用者が個人情報を開示する単位ごとに算出されるのが好ましい（図９（ａ）参照）。その際、各々の個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄを付すことも可能である（図９（ｂ）参照）。図９は、登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。なお、図９において、点線は本人の署名３３Ｄの署名対象データを表している。

【0126】

なお、利用者は、登録したい個人情報が複数ある場合、それらのハッシュ値を別々の登録ブロックにしてブロックチェーン３に追加することも可能である。いずれの場合においても、登録ブロックにおいて、作成元の署名とともに、利用者の個人ＩＤ＿Ｈａｓｈ３１Ｄと個人情報Ｈａｓｈ３２Ｄとが対応づけられていればよい。なお、個人ＩＤも個人情報の一つとみなすこともでき、その場合、登録ブロックは、個人ＩＤとそれ以外の個人情報の２以上の個人情報について、それらのハッシュ値が作成元の署名とともに含まれていればよい。

【0127】

なお、図示省略しているが、各ブロックには、上記の他、署名の作成元の公開鍵や、ブロックの種別や、各登録情報の種別等を示す情報が含まれていてもよい。

【0128】

また、ブロックチェーン３を構成する各ブロックには、当該ブロックがブロックチェーンの一部を構成するために必要とされる制御情報、例えば、前ブロックのハッシュ値や、当該ブロックを追加した者の署名等が含まれる。これら制御情報は、用いるブロックチェーンの仕様により定められる。

【0129】

以下、個人情報として免許証を登録する場合を例に用いて説明する。免許証には、名前、住所、顔写真、生年月日、免許証番号、有効期限など複数の個人情報が含まれるが、利用者は、対象確認に用いる個人情報として、免許証全体を撮影した免許証画像を用いてもよい。その場合、免許証画像のハッシュ値を個人情報Ｈａｓｈ３２Ｄとして含む登録ブロックがブロックチェーン３に登録される。なお、個人情報である免許証画像自体は、クライアントデバイス１のセキュア領域に保持されたり、分割・暗号化されて分散ファイルシステムに保持されればよい。

【0130】

免許証を個人情報として登録する場合において、免許証全体を１つの画像にする以外にも、開示をコントロールしたい単位に分割して複数の部分画像にしたり、開示をコントロールしたい単位を設定した上で単位ごとにその部分のみを識別可能に加工して複数の加工画像にしたり、テキスト入力可能な情報（住所や生年月日や氏名等）であればテキスト入力等によりデータ化したり、それらを適宜組み合わせたものを、個人情報として登録してもよい。その場合において、免許証画像（全体）、部分画像、加工画像およびテキストデータをそれぞれ異なる種類の個人情報として保持することも可能である。

【0131】

例えば、利用者は、免許証の生年月日が記載された領域のみが識別できる画像（上記のい部分画像や加工画像）を、個人情報の１つである生年月日データとして登録したい場合には、該利用者の個人ＩＤのハッシュ値と、該生年月日データのハッシュ値とを算出し、それらの各々またはそれらを１つにまとめて本人の署名を付し、それら本人の署名が付されたハッシュ値を登録した登録ブロックを、ブロックチェーン３に追加してもよい。

【0132】

次に、ブロックチェーン３に登録されている情報を利用して、利用者の対象確認を行う場合を説明する。対象確認を行いたい確認機関の確認機関デバイス２は、確認対象の利用者のクライアントデバイス１から、個人ＩＤ１３Ｄと、対象確認に用いる個人情報１４Ｄ（以下、第１の個人情報という）とを取得する。そして、確認機関デバイス２は、個人ＩＤ１３Ｄのハッシュ値と対応づけて第１の個人情報のハッシュ値が登録された登録ブロックを取得する。登録ブロックの取得は、個人ＩＤ１３Ｄから算出されるハッシュ値と第１の個人情報から算出されるハッシュ値とをキーにしてブロックチェーン３を検索して得てもよいし、後述するような利用者が保持しているブロック登録履歴等から得られる登録ブロックのハッシュ値等を得て、それをキーにブロックチェーン３を検索して得てもよい。少なくともブロックチェーン３において公開されている情報を基に検索できればよい。該当する登録ブロックが検索されると、確認機関デバイス２は、該登録ブロックに登録されている情報（個人ＩＤ＿Ｈａｓｈ３１Ｄや個人情報Ｈａｓｈ３２Ｄ）がその利用者本人（この場合、個人情報を開示した開示者本人）によって作成され（作成元証明）、かつ署名時点から改ざんされていないこと（非改ざん証明）を、該情報に付された本人の署名３３Ｄと、署名者とされた利用者の公開鍵１２Ｄとを用いて確認する（登録情報の信頼性確認）。また、確認機関デバイス２は、検索された登録ブロック内の個人情報Ｈａｓｈ３２Ｄと、利用者から取得した第１の個人情報から算出したハッシュ値とを照合する（元データの一致性確認）。なお、元データの一致性確認は、第１の個人情報から算出されるハッシュ値をキーにして登録ブロックを検索した場合は省略される。

【0133】

確認機関デバイス２は、これら２つの確認結果がともにＯＫであった場合に、開示者から得られた第１の個人情報が、開示者から得られた個人ＩＤ１３Ｄが示す利用者本人の個人情報１４Ｄであると判定し、開示された第１の個人情報に基づいて、当該確認機関において必要な対象確認（本人確認やユーザ認証や適格性確認）を行う。

【0134】

一例として、確認機関デバイス２が、サービスの受給資格の条件として、サービス要求元の利用者の年齢確認を行うことを考える。この場合、確認機関デバイス２は、該利用者のクライアントデバイス１に対して、個人ＩＤ１３Ｄと、第１の個人情報として生年月日データ（例えば、免許証画像の部分画像や加工画像やテキストデータ）の開示を要求してもよい。なお、第１の個人情報とされる生年月日データは、少なくともそのハッシュ値がその利用者の個人ＩＤ１３Ｄから算出されたハッシュ値とともに登録ブロックに登録されているもの、すなわち登録ブロック内の個人情報Ｈａｓｈ３２Ｄの元データであるとする。

【0135】

これらの情報を得ると、確認機関デバイス２は、開示された個人ＩＤ１３Ｄが示す利用者の、開示された生年月日データのハッシュ値を登録した登録ブロックを取得する。該登録ブロックを取得すると、確認機関デバイス２は、該登録ブロックに含まれる生年月日データのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）および個人ＩＤ＿Ｈａｓｈ３１Ｄに付された本人の署名３３Ｄを作成元（利用者本人）の公開鍵１２Ｄを用いて復号し、得られた復号データ（署名対象とされたハッシュ値）の信頼性を確認する（登録情報の信頼性確認）。ここで、作成元の公開鍵として、ブロック内のものを用いてもよいし、利用者本人として第１の個人情報を開示した開示者の公開鍵を用いることもできる。

【0136】

また、確認機関デバイス２は、必要に応じて該登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄと、利用者から開示された生年月日データから作成したハッシュ値とを照合して、両者が一致するかを確認する（元データの一致性確認）。なお、既に説明したように、元データの一致性確認は、開示された個人情報から算出されたハッシュ値をキーに用いて登録ブロックを検索した場合は、該検索処理に代替される（検索されたブロックは元データと一致している）。

【0137】

登録情報の信頼性確認および元データの一致性確認がいずれもＯＫであった場合に、確認機関デバイス２は、開示された生年月日データは、開示された個人ＩＤが示す利用者本人である開示者の正しい個人情報であるとして、該生年月日データに基づいて年齢確認を行う。その結果、確認機関デバイス２は、例えば、年齢制限のあるサービス等を提供してもよい。このようにして、確認機関デバイス２は、サービスの要求元から個人ＩＤ１３Ｄと生年月日データとを取得するだけで、その生年月日データがその開示者の生年月日データであるか否かといった本人確認を自身で行わなくても、開示された生年月日データを基に対象確認（年齢確認）を行うことができる。

【0138】

また、確認機関デバイス２は、ブロックチェーン３内の情報を利用して対象確認を行った場合、該確認の記録を示す確認記録ブロックをブロックチェーン３に登録する。

【0139】

図８には、ブロックチェーン３に追加された確認記録ブロックの例として、ブロックｎやブロックｎ＋１が示されている。確認記録ブロックには、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄ（利用者から開示された個人ＩＤ１３Ｄから算出されるハッシュ値に対応）とその作成元である確認機関の署名３５Ｄとが含まれる。なお、ブロックｎとして示すように、確認記録ブロックは、さらに、確認情報３４Ｄを含んでいてもよい。

【0140】

ここで、確認情報３４Ｄは、例えば、確認機関の情報（確認機関ＩＤ等）や、確認事項を示す情報を含んでいてもよい。このような確認情報３４Ｄを登録することで、以降、同じ目的の対象確認を行う場合に重複した処理を行わなくて済むようにできる。例えば、確認機関の情報は、例えば、確認機関を識別する確認機関ＩＤであってもよい。また、確認事項は、例えば、対象確認に利用したブロックの情報（これにより対象確認に利用した個人情報のハッシュ値や種別等がわかる）や、対象確認の結果（対象確認中に行われた種々の確認の結果を含む）や、対象確認の結果提供したサービスの種別や、そのサービスが必要とする適格性の種別等であってもよい。

【0141】

このような確認記録ブロックがブロックチェーン３に含まれていれば、以降、確認機関は、具体的な個人情報（例えば、生年月日データ）の開示なしに、利用者から開示される個人ＩＤと個人情報のハッシュ値とに基づいて、それらハッシュ値から特定される過去の確認記録ブロックの確認情報３４Ｄで示される確認結果と同等の確認結果を利用者に与えることができる。また、利用者は、個人情報の不要な開示を防ぐことができる。

【0142】

上記の例であれば、生年月日データの開示を受けずに、利用者の個人ＩＤと生年月日データのハッシュ値とから、過去にその利用者に与えられたサービスの種別やそれが必要とする適格性の種別と同等のサービスや適格性を、その利用者に与えることができる。なお、例えば、使用目的および使用機関が限定されている場合など、確認機関の署名３５Ｄからその利用者に対してどのような個人情報を用いてどのような対象確認が行われたかが特定可能な場合は、確認情報３４Ｄがなくても、同様の対象確認の結果をその利用者に与えることも可能である。なお、その場合においても、その利用者の確認記録とされる確認記録ブロックの登録情報について、署名に基づく信頼性確認を行うことを前提とする。

【0143】

なお、利用者のクライアントデバイス１が、自身の情報（少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄ）を記録したブロックのブロックチェーン３におけるキー情報（ブロックのハッシュ値等）を登録履歴として保持しておき、対象確認時に援用したいブロックのキー情報を指定することも可能である。

【0144】

ところで、上記の登録情報の信頼性判定は、利用者の個人ＩＤ、個人情報および秘密鍵が第三者に秘匿状態にあり、署名者（それらのハッシュ値を作成した者）が正しい個人ＩＤおよび個人情報からハッシュ値を作成していることを前提としている。しかし、仮に正規の利用者が故意に不正（個人情報の改ざん等）をした場合には、登録情報（この場合、個人ＩＤのハッシュ値および個人情報のハッシュ値）に付された本人の署名だけでは、元データ（個人ＩＤそのものや個人情報そのもの）の正当性までは保証されない。

【0145】

例えば、対象確認に用いる第１の個人情報が顔写真や生体情報など利用者の生体由来の情報の場合、開示された第１の個人情報から作成したハッシュ値と開示された個人ＩＤ１３Ｄから作成したハッシュ値との対応関係、および開示された第１の個人情報と開示者本人から得られる同等の情報（現在の生体情報等）との類否関係から、開示された第１の個人情報または開示された第１の個人情報のハッシュ値の元データの正当性、すなわち個人ＩＤ１３Ｄを開示した開示者でありその個人ＩＤ１３Ｄが示す利用者本人の個人情報としての正当性が確認できる。

【0146】

しかし、開示された第１の個人情報が利用者の生体由来の情報以外の情報（例えば、氏名や住所や生年月日などの属性情報）の場合、登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄの信頼性確認だけでは、元データである第１の個人情報の正当性までは確認できない。

【0147】

そこで、利用者の故意の不正までを考慮して、所定の確認機関に該個人情報の正当性を確認させた上で、登録ブロックを追加するようにしてもよい。このとき、個人情報Ｈａｓｈ３２Ｄに、本人の署名３３Ｄに代えてもしくは本人の署名３３Ｄと合わせてその確認機関の署名３５Ｄを付してもよい。本人の署名３３Ｄに代えて確認機関の署名３５Ｄを付す場合でも、本人の署名３３Ｄが個人ＩＤ＿Ｈａｓｈ３１Ｄに付されるため、特に問題ない。また、本人の署名３３Ｄと確認機関の署名３５Ｄを合わせて付す場合、一方の署名が付された署名対象データを１つのデータとみなして他方の署名を付すなど入れ子構造にしてもよいし、１つの署名対象データにそれぞれが署名を付してもよい。

【0148】

図１０は、登録ブロックにおける登録情報の署名方法の他の例を示す説明図である。なお、図１０において、点線は本人の署名３３Ｄの署名対象データを表し、破線は確認機関の署名３５Ｄの署名対象データを表している。図１０（ａ）は、個人情報Ｈａｓｈ３２Ｄに本人の署名３３Ｄに代えて確認機関の署名３５Ｄを付した場合の例である。また、図１０（ｂ）〜（ｆ）は、個人情報Ｈａｓｈ３２Ｄに本人の署名３３Ｄと確認機関の署名３５Ｄとを合わせて付した場合の例である。なお、図１０（ｂ）に示す例では、署名対象データである個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄと確認機関の署名３５Ｄをそれぞれ付し、図１０（ｃ）〜（ｆ）に示す例では、入れ子構造で本人の署名３３Ｄと確認機関の署名３５Ｄを付している。なお、ここで「入れ子構造」は、署名対象データに対して先に一方の署名を付し、その署名を含むデータを新たな署名対象データにして他方の署名を付すことをいう。なお、後に署名を行う署名者は、先に付された署名と合わせて先の署名対象データやそれ以外のデータを含むことも可能である。なお、いずれの場合においても、対象確認において登録情報の信頼性を確認する際に、どのような構造でかつどのデータを対象に誰の署名が付されているかが予めもしくは該ブロック内の情報等からわかっているものとする。これにより、他の確認機関が個人ＩＤのハッシュ値と個人情報のハッシュ値と本人の公開鍵と確認機関の公開鍵とを入手可能であれば、登録情報の信頼性（これには個人情報の正当性を確認した確認機関の署名３５Ｄの信頼性を含む）を確認できるようにする。

【0149】

例えば、図１０（ｃ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に本人の署名３３Ｄを付し、その本人の署名３３Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして確認機関の署名３５Ｄを付している。また、例えば、図１０（ｄ）に示す例は、２つの登録情報である個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄに先に本人の署名３３Ｄを付し、その本人の署名３３Ｄと先の署名対象データ（個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして確認機関の署名３５Ｄを付している。なお、図１０（ｃ）〜（ｄ）において、確認機関は、先の署名である本人の署名３３Ｄのみを新たな署名対象データにして確認機関の署名３５Ｄを付すことも可能である。また、例えば、図１０（ｅ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に確認機関の署名３５Ｄを付し、その確認機関の署名３５Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）とを新たな署名対象データにして本人の署名３３Ｄを付している。なお、本人は、確認機関の署名３５Ｄのみを新たな署名対象データにして本人の署名３３Ｄを付すことも可能である。また、例えば、図１０（ｆ）に示す例では、登録情報の１つである個人情報Ｈａｓｈ３２Ｄに先に確認機関の署名３５Ｄを付し、その確認機関の署名３５Ｄと先の署名対象データ（個人情報Ｈａｓｈ３２Ｄ）と他の登録情報（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を新たな署名対象データにして本人の署名３３Ｄを付している。

【0150】

なお、個人情報管理システムでは、図９や図１０に示すように、登録情報（例えば、個人ＩＤ＿Ｈａｓｈ３１Ｄや個人情報Ｈａｓｈ３２Ｄ）と１対１で本人または確認機関の署名が付されていなくても、ある署名の署名対象データに、その署名の目的とされる登録情報もしくはその登録情報を署名対象データとした他の署名が含まれている場合（入れ子構造により含まれている場合も含む）は、実質的にその登録情報にはそのある署名が付されているものとみなす。

【0151】

したがって、ある登録情報について本人の署名を付して登録するといった場合には、他の登録情報と一体になって本人の署名が付されたもの、他の署名の署名対象データとされた登録情報にさらに本人の署名が付されたもの、他の署名が先に付されている登録情報に付された当該他の署名を含む署名対象データに本人の署名が付されたもの、本人の署名が先に付されている登録情報に付された当該本人の署名を署名対象データとしてさらに他の署名が付されたものなども含まれる。

【0152】

例えば、第１の個人情報の正当性確認を依頼された確認機関の確認機関デバイス２は、クライアントデバイス１から、第１の個人情報と、該第１の個人情報が正しいことを当該確認機関において確認できる第２の個人情報とを取得してもよい。そして、確認機関デバイス２は、第２の個人情報を基に第１の個人情報が正しいことを確認した上で、第１の個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）を算出し、得られたハッシュ値に自身の署名（確認機関の署名３５Ｄ）を付してクライアントデバイス１に返信する。クライアントデバイス１は、確認機関の署名が付された個人情報のハッシュ値を受け取ると、本人の署名３３Ｄを付した個人ＩＤのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と合わせて登録ブロックを作成し、ブロックチェーン３に追加してもよい。

【0153】

個人情報の正当性確認を行う確認機関は、例えば、その個人情報の発行元の機関（例えば、免許証情報であれば警察機関など）であってもよい。その場合、発行元としての確認機関の確認機関デバイス２は、例えば、当該確認機関において本人確認もしくはユーザ認証可能な情報（免許証番号や、顔写真や、クレジットカード番号や、パスワード等）を、第２の個人情報として取得し、それらが自身が保持している認証情報と一致するか否かを確認した上で、自身が発行した第１の個人情報と確認依頼された第１の個人情報とが一致するか否かを確認することでその正当性を判定してもよい。そして、正当性が確認できた場合には、利用者から取得した第１の個人情報のハッシュ値を算出し、そのハッシュ値に自身の署名を付してクライアントデバイス１に返信してもよい。以下、個人情報の正当性確認を行う確認機関が取得する第２の個人情報を、正当性確認情報という場合がある。

【0154】

なお、クライアントデバイス１に返信せず、確認機関側で、登録ブロックを作成してブロックチェーン３に追加することも可能である。その場合、確認機関デバイス２は、クライアントデバイス１から、利用者本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄをさらに取得すればよい。なお、必要に応じて本人の署名３３Ｄが付された個人情報Ｈａｓｈ３２Ｄや、本人の署名３３Ｄが付された登録情報としての個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄを取得してもよい。

【0155】

このような登録ブロックがブロックチェーン３に含まれていれば、以降、確認機関は、利用者から開示された第１の個人情報の正当性を自身で確認する必要なしに、ブロック内の登録情報（個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ）の信頼性確認および元データの一致性確認を行うだけで、該個人情報を対象確認に用いることができる。ただし、確認機関は、登録情報の信頼性確認で、本人の署名３３Ｄによるその署名が付された署名対象データの作成元証明（この場合、登録元証明）および非改ざん証明に加えて、確認機関の署名３５Ｄによるその署名が付された署名対象データの作成元証明（この場合、登録元証明）およびを非改ざん証明を行う。

【0156】

なお、登録ブロックの個人情報Ｈａｓｈ３２Ｄの元データである個人情報の正当性を確認するタイミングは、登録ブロックの登録時に限定されない。例えば、登録ブロックの登録後に所定の確認機関に該個人情報の正当性を確認させることも可能である。その場合、確認機関は、登録情報の元データ（より具体的には登録情報の元データとの一致性が確認された第１の個人情報）の正当性確認を含む対象確認（本人確認やユーザ認証）を行ったとして、例えば、図１１に示すような確認記録ブロックをブロックチェーン３に登録すればよい。図１１に示す確認記録ブロックは、確認情報３４Ｄに、登録情報の元データの正当性確認を行った登録情報に含まれる個人情報Ｈａｓｈ３２Ｄや、本人確認の結果（ＯＫ）や、元データの正当性確認の結果（ＯＫ）の情報を含んでいる。

【0157】

登録情報の元データである個人情報の正当性確認を含む対象確認は、例えば、上記の対象確認の処理において、確認機関デバイス２がさらにクライアントデバイス１から、開示された個人情報（第１の個人情報）が正しいことを当該確認機関において確認できる第２の個人情報を取得することにより実現できる。なお、第２の個人情報から第１の個人情報の正当性を確認する方法は上述したとおりである。なお、その確認機関において第１の個人情報から、目視等により第１の個人情報の正当性が確認できる場合は、第２の個人情報の取得は省略される。

【0158】

なお、個人情報の発行元以外の確認機関が個人情報の正当性確認を行うことも可能である。その場合、該確認機関の確認機関デバイス２は、上記の対象確認の処理において、第１の個人情報またはそれと同等の内容を示す情報をその一部に含む第２の個人情報であって、さらにその個人情報（第２の個人情報）が正しいことをその確認機関または本システムにおいて確認できるものを取得してもよい。なお、いずれの機関が正当性を確認する場合も、その機関において第１の個人情報から、目視等により第１の個人情報の正当性が確認できる場合は、第２の個人情報の取得は省略される。

【0159】

発行元以外の確認機関が個人情報の正当性確認を行う場合、第２の個人情報（正当性確認情報）として、例えば、次の条件（１）〜（３）のいずれかを満たす個人情報を用いてもよい。
・（１）（ａ）「（ａ１）『第１の個人情報またはそれと同じの内容を示す情報』と（ａ２）『本人確認が可能な情報』とを少なくとも一体化して含む情報の原本」または該原本の複写画像であること。
・（２）（ｂ１）「少なくとも（ａ１）『第１の個人情報またはそれと同じの内容を示す情報』を含む情報」であって、かつ（ｂ２）「そのハッシュ値の元データに対して発行元の確認機関の署名が付されたブロックがブロックチェーンに登録されている情報」であること。
・（３）（ｃ）「正規の第１の個人情報を保持する機関（正規情報保持機関）において利用者を識別可能な情報とユーザ認証が可能な認証情報の組」であること。

【0160】

なお、条件（１）について、例えば、（ａ）＝（ａ１）生年月日データと（ａ２）顔画像とを一体化して含む免許証の原本またはその複写画像である場合を考える。そのような場合、開示された（ａ）内の（ａ２）について目視や現在の利用者から取得した（ａ２）と同等の情報との照合により開示者が本人であることが確認されれば、（ａ１）も本人の情報であるとみなすことができる。あとは、開示された（ａ）内の（ａ１）と、開示された第１の個人情報とを照合すればよい。このとき、複写画像を、対象確認時に原本から得るようにしてもよい。なお、開示された（ａ）内の（ａ１）と、開示された第１の個人情報との照合には、画像データとテキストデータの照合等も含まれる。また、第２の個人情報の正当性を確認するために、現在の利用者からさらに（ａ２）と同等の情報を取得する場合、その情報を第３の個人情報と呼ぶ場合がある。この場合、第３の個人情報を含めて本人確認情報と呼ぶ場合がある。

【0161】

また、条件（２）について、例えば、（ｂ１）＝（ａ１）生年月日データを含む保険証画像（全体）である場合を考える。そのような場合、開示された（ｂ１）のハッシュ値の元データに対して発行元の確認機関の署名が付されたブロックがブロックチェーン３に登録されていれば、そのブロック内の登録情報の信頼性と、開示された（ｂ１）とブロック内のハッシュ値の元データとの一致性とが確認されれば、開示された（ｂ１）について正当性が確認される。あとは、開示された（ｂ１）内の（ａ１）と、開示された第１の個人情報とを照合すればよい。

【0162】

また、条件（３）について、（ｃ）＝そのようなユーザ識別情報と認証情報の組であれば、第１の個人情報とともに（ｃ）を正規情報保持機関に送信して、（ｃ）を基にユーザ認証を行った上で、送信した第１の個人情報と正規情報保持機関が保持しているそのユーザの正規の第１の個人情報とを照合した結果を返信してもらうことで、開示された第１の個人情報の正当性を確認できる。

【0163】

例えば、その利用者の登録ブロックや確認記録ブロックに含まれる個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）に、元データの正当性を確認した確認機関の署名３５Ｄが付されていない場合、確認機関の確認機関デバイス２は、対象確認に用いる第１の個人情報の正当性確認を含む対象確認を行ってもよい。具体的には、確認機関デバイス２は、対象確認時に上記のような第２の個人情報の開示をさらに要求してもよい。

【0164】

また、個人情報管理システムは、必要に応じて、利用者が個人ＩＤを開示する際に、該個人ＩＤに対してユーザ認証を行った上で、上記の処理を行うようにしてもよい。ユーザ認証は、既存の認証技術を利用できる。

【0165】

なお、上述した登録ブロックの追加、確認記録ブロックの追加、ブロック内の登録情報の信頼性確認、元データの一致性確認、元データの正当性確認等における具体的処理（個人情報や秘密鍵へのアクセスを除く）は、個人情報管理システムが提供するＵＩ（User Interface）やＡＰＩ（Application Program Interface）等を利用して個人情報管理システムが行う。

【0166】

次に、図１２を参照して、個人情報管理システムの主要な構成について説明する。図１２に示す個人情報管理システム１００は、データ記憶部１０１、登録部１０２、開示部１０３、認証部１０４、データ記憶部２０１、確認部２０２、台帳管理ノード３０１、データ記憶部５０１および個人ＩＤ割当部５０２を備える。図１２に示すように、個人情報管理システム１００は、大きく、利用者側システム１０と、確認機関側システム２０と、台帳管理システム３０と、管理側システム５０とに大別されている。

【0167】

図１２において、データ記憶部１０１、登録部１０２、開示部１０３および認証部１０４は利用者側システム１０に属する。また、データ記憶部２０１および確認部２０２は確認機関側システム２０に属する。また、台帳管理ノード３０１は台帳管理システム３０に属する。また、データ記憶部５０１および個人ＩＤ割当部５０２は管理側システム５０に属する。なお、認証部１０４は、管理側システムで保持している認証情報を用いてユーザ認証を行う場合は管理側システムに属することも可能である。

【0168】

ただし、この分類は情報のアクセス権限に基づくものであり、実際のプログラムの動作環境を限定するものではない。例えば、登録部１０２の一部（データ記憶部１０１へのアクセスを除く）や確認部２０２の一部（データ記憶部２０１へのアクセスを除く）の機能が、管理側システム５０が備える装置に実装されてもよい。

【0169】

図示省略しているが、利用者側システム１０は少なくともクライアントデバイス１を含む。また、確認機関側システム２０は少なくとも確認機関デバイス２を含む。

【0170】

データ記憶部１０１、データ記憶部２０１およびデータ記憶部５０１を除いた各処理部は、それぞれネットワーク４０を介して接続されている。なお、ネットワーク４０は、インターネットとＥｔｈｅｒｅｕｍネットワークなどの複数の異なるネットワークを含んでいてもよい。データ記憶部１０１は、登録部１０２、開示部１０３および認証部１０４と接続されていればよい。また、データ記憶部２０１は確認部２０２と接続されていればよい。また、データ記憶部５０１は、個人ＩＤ割当部５０２と接続されていればよい。

【0171】

データ記憶部１０１は、利用者側システム１０に属する各処理部が必要な情報や、利用者の情報として他のシステムに開示される情報を保持する。データ記憶部１０１は、例えば、利用者の個人情報１４Ｄや、個人情報管理システム１００が割り当てる個人ＩＤ１３Ｄや、署名用のペア鍵（秘密鍵１１Ｄおよび公開鍵１２Ｄ）を記憶する。本実施形態において、データ記憶部１０１の少なくとも一部は、利用者側システム１０が備える装置（例えば、クライアントデバイス１）が備えるセキュア領域を有する記憶装置や、利用者側システム１０が備える装置からアクセス可能な分割ファイルシステムにより実現される。

【0172】

登録部１０２は、利用者からの指示に応じて、利用者の個人ＩＤ１３Ｄのハッシュ値と、登録したい個人情報１４Ｄのハッシュ値と、必要な署名（少なくとも本人の署名を含む）とを有する登録ブロックをブロックチェーン３に登録する。なお、実際の登録は後述する台帳管理ノード３０１が所定の手続きを経て行うため、登録部１０２は、台帳管理ノード３０１を介して登録ブロックをブロックチェーン３に追加するための処理を行う。なお、登録部１０２は、そのような登録ブロックをブロックチェーン３に登録するための手続きを利用者に提供できればよい。

【0173】

登録部１０２は、例えば、利用者から登録したい個人情報１４Ｄが指定されると、データ記憶部１０１から指定された個人情報１４Ｄを読み出し、そのハッシュ値を算出する。そして、得られた個人情報のハッシュ値（個人情報Ｈａｓｈ３２Ｄ）と個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）とに対して少なくとも１つの本人の署名３３Ｄを付した上で、それらが登録された登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信する。

【0174】

なお、登録部１０２は、必要に応じて所定の確認機関の確認部２０２に、元データとされる個人情報１４Ｄの正当性確認の依頼を該個人情報１４Ｄとともに送信してもよい。それにより、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄを得てもよい。その上で、登録部１０２は、個人情報Ｈａｓｈ３２Ｄと、個人ＩＤ＿Ｈａｓｈ３１Ｄと、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄと、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄに対する本人の署名３３Ｄとを登録情報として含む登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信してもよい。

【0175】

また、登録部１０２は、所定の確認機関の確認部２０２に、個人情報１４Ｄの正当性確認および登録ブロックの登録依頼を、少なくとも本人の署名３３Ｄを付した個人ＩＤ＿Ｈａｓｈ３１Ｄとともに送信してもよい。その場合、確認部２０２によって、個人情報Ｈａｓｈ３２Ｄと、個人ＩＤ＿Ｈａｓｈ３１Ｄと、少なくとも個人情報Ｈａｓｈ３２Ｄに対するその確認機関の署名３５Ｄと、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄに対する本人の署名３３Ｄとを登録情報として含む登録ブロックの追加要求（ブロック追加要求）を、後述する台帳管理ノード３０１に送信してもよい。

【0176】

開示部１０３は、利用者からの指示に応じて、指定された個人情報１４Ｄまたはそのハッシュ値を外部に出力する。ここで、外部への出力には、表示（表示装置への出力）や、送信（指定された宛て先への出力）が含まれうる。開示部１０３は、例えば、確認部２０２から個人情報１４Ｄが指定された開示要求を受け付けると、利用者にその開示有無を問い合わせた上で、指定された個人情報１４Ｄまたはそのハッシュ値を、指定された出力先（要求元の確認部２０２や表示部等）に出力する。なお、開示部１０３は、その個人情報１４Ｄのハッシュ値が同じ目的の対象確認の結果や確認機関の署名とともに確認記録ブロックや登録ブロックとしてブロックチェーン３に登録されている場合、指定された個人情報１４Ｄに代えて、指定された個人情報１４Ｄのハッシュ値を出力することも可能である。その際、開示部１０３は、いずれの情報を開示するかを利用者に問い合わせした後、指定された情報を出力してもよいし、問い合わせをせずに優先してハッシュ値を出力してもよい。また、個人情報に代えて個人情報のハッシュ値を出力する場合、開示部１０３は、そのときの確認記録ブロックの情報を合わせて出力してもよい。

【0177】

認証部１０４は、他の処理部が個人ＩＤ１３Ｄにアクセスする際に、現在の利用者に対してユーザ認証を行う。認証部１０４は、例えば、個人ＩＤ１３Ｄへのアクセスを検知すると、現在の利用者に認証情報の入力を要求し、入力された認証情報と予め保持している認証情報とを照合して、現在の利用者のユーザ認証を行う。なお、利用者側システム１０において個人ＩＤ１３Ｄに対するユーザ認証が不要な場合は、認証部１０４は省略されてもよい。

【0178】

本実施形態において、登録部１０２、開示部１０３および認証部１０４は、例えば、利用者側システム１０が備える装置にインストールされるなど、データ記憶部１０１にアクセス可能なＣＰＵ等により実現される。

【0179】

なお、認証部１０４は、管理側システム５０において、開示部１０３から開示された個人ＩＤ１３Ｄに対するユーザ認証を行う処理部として動作することも可能である。その場合、認証部１０４は、後述する確認部２０２からの要求に応じて、個人ＩＤ１３Ｄを開示した開示部１０３の現在の利用者（開示者）に認証情報の入力を要求し、入力された認証情報とデータ記憶部５０１等に予め保持している認証情報とを照合して、開示者のユーザ認証を行う。その場合、認証部１０４は、データ記憶部５０１にアクセス可能に実装されているＣＰＵ等により実現される。

【0180】

データ記憶部２０１は、確認機関側システム２０に属する各処理部が必要な情報や、確認機関の情報として当該個人情報管理システム１００が備える他のシステムに開示される情報を保持する。データ記憶部２０１は、例えば、確認機関ＩＤや、署名用のペア鍵（秘密鍵２１Ｄおよび公開鍵２２Ｄ）を記憶する。本実施形態において、データ記憶部２０１の少なくとも一部は、確認機関側システム２０が備える装置（例えば、確認機関デバイス２）が備えるセキュア領域を有する記憶装置や、確認機関側システム２０が備える装置からアクセス可能な分割ファイルシステムにより実現される。

【0181】

確認部２０２は、利用者からサービスを要求された確認機関からの指示に応じて、利用者の対象確認を行う。確認部２０２は、例えば、指定された利用者の開示部１０３から取得される情報と、ブロックチェーン３に登録されている情報（登録ブロックおよび確認記録ブロック内の情報）とに基づいて、利用者の対象確認を行う。

【0182】

確認部２０２は、例えば、指定された利用者の開示部１０３に対して、個人ＩＤ１３Ｄと対象確認に用いられる個人情報１４Ｄまたはそのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）の開示を要求する。また、確認部２０２は、得られた情報や利用者側システム１０が保持するブロックの登録履歴を基に、該利用者の登録ブロックまたは確認記録ブロックを検索する。そして、得られた該利用者の登録ブロックまたは確認記録ブロックを利用して、上述したような登録情報の信頼性確認や元データの一致性確認や個人情報の正当性確認を行い、それらの確認結果を出力したり、それらの確認結果に基づき対象確認を行う。なお、対象確認自体は、登録情報の信頼性確認、元データの一致性確認または個人情報の正当性確認もしくはそれらの組み合わせを基に判定される開示された情報の正当性の判定結果の出力を基に、確認機関側のユーザが行ってもよい。その場合、確認部２０２は、該ユーザが行った対象確認結果を受け付ける。

【0183】

また、確認部２０２は、必要に応じて対象確認の記録を示す確認記録ブロックを作成し、ブロックチェーン３に追加するための処理を行う。確認記録ブロックは、対象確認を行った利用者の個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と、それに対する確認機関の署名３５Ｄとを少なくとも含む。

【0184】

なお、確認部２０２は、そのような対象確認およびそのような確認記録ブロックのブロックチェーン３への登録手続きを確認機関に提供できればよい。本実施形態において、確認部２０２は、例えば、確認機関側システム２０が備える装置にインストールされるなど、データ記憶部２０１にアクセス可能なＣＰＵ等により実現される。

【0185】

なお、図１２では、利用者側システム１０および確認機関側システム２０がそれぞれ１つしか示されていないが、利用者側システム１０は利用者ごとに設けられ、また確認機関側システム２０も確認機関ごとに設けられる。

【0186】

台帳管理システム３０は、ブロックチェーンを台帳とし、該台帳を複数のノードが共有して管理するシステムである。なお、ブロックチェーンを管理するシステムとして、台帳管理システムを例示するが、所定のコンセンサスアルゴリズムに従う処理（以下、コンセンサス処理という）を実行可能で、かつ改ざんが困難な台帳をシステム内の端末で共有するシステムであれば、台帳管理システムに限定されない。

【0187】

台帳管理ノード３０１は、台帳管理システム３０において、コンセンサス処理を実行するノードである。台帳管理ノード３０１の各々は、当該コンセンサス処理の実行を通して、ブロックチェーン３のコピーを保持する。

【0188】

なお、図１２では、利用者側システム１０と台帳管理システム３０、確認機関側システム２０と台帳管理システム３０とを分けて記載しているが、例えば、利用者側システム１０や確認機関側システム２０が台帳管理ノード３０１の機能を有していてもよい。

【0189】

データ記憶部５０１は、管理側システム５０に属する各処理部が必要な情報や、管理側システム５０の情報として当該個人情報管理システム１００が備える他のシステムに開示される情報があればそれを保持する。データ記憶部５０１は、例えば、利用者に割り当てた個人ＩＤの情報や、当該個人情報管理システム１００が備える他のシステムの処理部が行う手続きを実装したプログラム（実行コードなど）を記憶してもよい。本実施形態において、データ記憶部５０１の少なくとも一部は、管理側システム５０が備えるセキュア領域を有する記憶装置や、管理側システム５０が備える装置からアクセス可能な分割ファイルシステムにより実現される。

【0190】

個人ＩＤ割当部５０２は、利用者に個人ＩＤ１３Ｄを割り当てる。本実施形態において、個人ＩＤ割当部５０２は、例えば、管理側システム５０が備える装置にインストールされるなど、データ記憶部５０１にアクセス可能なＣＰＵ等により実現される。

【0191】

また、図１３は、確認部２０２の構成例を示すブロック図である。図１３に示すように、確認部２０２は、データ取得部２２１と、登録情報信頼性確認部２２２と、元データ一致性確認部２２３と、個人情報正当性確認部２２４と、結果出力部２２５と、確認記録登録部２２６とを含んでいてもよい。

【0192】

データ取得部２２１は、利用者側システム１０（特に、開示部１０３）から個人ＩＤ１３Ｄとともに対象確認に必要な情報（例えば、個人情報１４Ｄまたはそのハッシュ値や、その利用者の過去の確認記録ブロックの情報等）を取得する。また、データ取得部２２１は、利用者側システム１０から取得した情報を基にブロックチェーン３を検索して、その利用者の情報（特に、対象確認に必要な個人情報１４Ｄまたはそのハッシュ値や、それを用いて対象確認を行った旨の記録（確認情報３４Ｄ等））を含むブロックを取得する。

【0193】

例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄと個人情報１４Ｄとを取得した場合には、その個人ＩＤ１３Ｄのハッシュ値とその個人情報１４Ｄのハッシュ値とを含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄと個人情報１４Ｄのハッシュ値とを取得した場合には、その個人ＩＤ１３Ｄから算出されるハッシュ値とその個人情報１４Ｄのハッシュ値とを含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄを取得した場合には、その個人ＩＤ１３Ｄから算出されるハッシュ値を含む最新のブロックをブロックチェーン３から取得してもよい。また、例えば、データ取得部２２１は、利用者側システム１０から個人ＩＤ１３Ｄのハッシュ値と過去の確認記録ブロックの情報とを取得した場合には、最新の確認記録ブロックをブロックチェーン３から取得してもよい。

【0194】

データ取得部２２１は、利用者側システム１０からどのような情報を取得するかを、その利用者の確認記録から決定してもよい。

【0195】

登録情報信頼性確認部２２２は、データ取得部２２１が取得したブロック内の情報（登録情報）の信頼性を、該登録情報に付されている署名を基に確認する。なお、登録情報信頼性確認部２２２は、ブロック内に複数の署名が含まれている場合には、指定された署名の署名対象データについてそれぞれ当該署名の復号結果との照合により信頼性を確認する。このとき、入れ子構造で指定された署名が入れ子構造で付されている場合には、署名を付した際の暗号化処理の順番とは逆向きに復号処理を行って、各署名の署名対象データと当該署名の復号結果とを照合して最終的な信頼性を確認すればよい。

【0196】

元データ一致性確認部２２３は、データ取得部２２１が利用者の個人情報１４Ｄを得て、その個人情報１４Ｄのハッシュ値とされる個人情報Ｈａｓｈ３２Ｄを含むブロックを取得した場合に、該ブロック内の個人情報Ｈａｓｈ３２Ｄの元データとされる個人情報と、取得した個人情報１４Ｄとの一致性を確認する。元データ一致性確認部２２３は、例えば、データ取得部２２１が得た個人情報１４Ｄから算出されるハッシュ値と、ブロック内の個人情報Ｈａｓｈ３２Ｄとを照合することにより、ブロック内の個人情報Ｈａｓｈ３２Ｄの元データとされる個人情報と、取得した個人情報１４Ｄとの一致性を確認すればよい。

【0197】

個人情報正当性確認部２２４は、データ取得部２２１が対象確認に用いる個人情報（第１の個人情報）を得た場合に、その第１の個人情報の正当性を確認する。個人情報正当性確認部２２４は、現在の利用者（開示者）の生体情報・「本人確認が可能な情報」・「本システムにおいてユーザ認証が可能な情報」など第１の個人情報が正しいことを当該確認機関において確認できる第２の個人情報をデータ取得部２２１にさらに取得させ、それらを基に、第１の個人情報の正当性を確認する。

【0198】

結果出力部２２５は、登録情報信頼性確認部２２２、元データ一致性確認部２２３、個人情報正当性確認部２２４による確認結果や、それらを基に判定される、開示された情報の正当性の判定結果や、最終的な対象確認の結果を出力する。なお、最終的な対象確認は、登録情報信頼性確認部２２２、元データ一致性確認部２２３、個人情報正当性確認部２２４による確認結果や、それらを基に判定される開示された情報の正当性の判定結果の出力を基に、確認機関側のユーザが行ってもよい。その場合、確認部２０２は、該ユーザが行った対象確認結果を受け付ける。

【0199】

確認記録登録部２２６は、結果出力部２２５が得た結果を基に、確認記録ブロックをブロックチェーン３に登録する。また、確認記録登録部２２６は、必要に応じて、利用者側システム１０に該確認記録ブロックの情報を出力する。

【0200】

また、図１４は、台帳管理ノード３０１の構成例を示すブロック図である。図１４に示す台帳管理ノード３０１は、登録情報受付部３１１と、ブロック生成部３１２と、ブロック共有部３１３と、情報記憶部３１４と、ブロック検証部３１５とを含む。

【0201】

登録情報受付部３１１は、外部ノードから、台帳管理システム３０が管理するブロックチェーンである台帳に記録する情報を受け付ける。本実施形態では、登録情報受付部３１１は、例えば、台帳に記録する情報として、登録ブロックの内容（ブロックデータ）や、確認記録ブロックの内容（ブロックデータ）を受け付ける。

【0202】

ブロック生成部３１２は、登録情報受付部３１１が受け付けた情報（ブロックデータ）を基に、ブロックチェーンに追加するブロックを生成する。ブロック生成部３１２は、前ブロックに基づく情報と登録情報受付部３１１が受け付けた情報とを含むブロックを生成する。また、ブロック生成部３１２は、自身が生成したブロックまたは後述するブロック共有部３１３を介して他の台帳管理ノード３０１が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン（ブロックチェーン３のコピーに相当）にブロックを追加する。なお、ブロック生成部３１２が生成したブロックに対して、複数の台帳管理ノード３０１が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン３に追加されるブロックとなる。

【0203】

ブロック共有部３１３は、台帳管理システム３０に属する台帳管理ノード３０１間で情報交換を行う。ブロック共有部３１３は、より具体的には、登録情報受付部３１１が受け付けた情報や、ブロック生成部３１２が生成したブロックや、他の台帳管理ノード３０１から受け付けたブロック等を、適宜他の台帳管理ノード３０１に送信する。これにより、可能な限り全ての台帳管理ノード３０１でこれらの情報および最新のブロックチェーン３を共有する。

【0204】

情報記憶部３１４は、ブロックチェーン３のコピーを記憶する。なお、情報記憶部３１４は、ブロックチェーン３のコピー以外にも、例えば、後述するブロック検証部３１５での検証処理に必要となる情報などを記憶してもよい。

【0205】

ブロック検証部３１５は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の情報の検証を行う。通常、追加対象とされるブロックは、自ノードを含む台帳管理ノード３０１群において最も早く規則が満たされたブロックであるが、悪意のある台帳管理ノード３０１が含まれていた場合等を考慮して、実際に規則が満たされているか等を検証してもよい。

【0206】

なお、図１４の構成はあくまで一例であって、台帳管理ノード３０１は、改ざんが困難なブロックチェーン３を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。

【0207】

次に、本実施形態の動作を説明する。本実施形態の動作は、登録ブロックをブロックチェーンに登録する登録フェーズと、ブロックチェーンに登録された登録ブロックや過去の確認記録ブロックを基に対象確認を行う確認フェーズの２つに大別される。さらに、確認フェーズは、利用者に個人情報を開示させて、ブロックチェーン３内の登録ブロックを基に対象確認を行う第１の確認フェーズと、利用者に個人情報を開示させずに、ブロックチェーンに３内の確認記録ブロックを基に対象確認を行う第２の確認フェーズの２つに大別される。

【0208】

まず、図１５を参照して、登録フェーズにおける個人情報管理システムの動作を説明する。図１５は、本実施形態の個人情報管理システムの登録フェーズにおける動作の一例を示すフローチャートである。なお、図１５に示す登録フェーズは、確認機関によって元データとされる個人情報の正当性確認を行わずに登録ブロックを登録する場合の例である。

【0209】

図１５に示す例では、まず、利用者側システム１０の登録部１０２が、データ記憶部１０１から個人ＩＤ１３Ｄおよび登録したい個人情報１４Ｄを読み出し、それぞれについてハッシュ値を算出して、個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄを得る（ステップＳ１０１）。登録部１０２は、ユーザ認証を行った上で、個人ＩＤ１３Ｄや個人情報１４Ｄへのアクセスを行ってもよい。

【0210】

次いで、登録部１０２は、そのようにして得た個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄに対して本人の署名３３Ｄを付し、該本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄが登録された登録ブロックを作成する（ステップＳ１０２）。

【0211】

次いで、登録部１０２は、作成した登録ブロックの追加要求を台帳管理ノード３０１に行って、該登録ブロックをブロックチェーン３に登録する（ステップＳ１０３）。このとき、登録部１０２は、登録された登録ブロックのキー情報を台帳管理ノード３０１から取得して、データ記憶部１０１に登録履歴として保持してもよい。

【0212】

このようにして、ブロックチェーン３に、利用者本人の署名３３Ｄが付された、利用者の個人ＩＤ１３Ｄのハッシュ値である個人ＩＤ＿Ｈａｓｈ３１Ｄおよび利用者の個人情報１４Ｄのハッシュ値である個人情報Ｈａｓｈ３２Ｄを登録情報として含む登録ブロックが追加される。

【0213】

また、図１６は、本実施形態の個人情報管理システムの登録フェーズにおける動作の他の例を示すフローチャートである。なお、図１６に示す登録フェーズは、確認機関によって元データとされる個人情報の正当性確認を行った上で登録ブロックを登録する場合の例である。

【0214】

図１６に示す例では、まず、利用者側システム１０の登録部１０２が、データ記憶部１０１から登録したい個人情報１４Ｄ（第１の個人情報）を読み出す（ステップＳ１１１）。

【0215】

次いで、登録部１０２は、発行元の確認機関側システム２０の確認部２０２に、第１の個人情報と、必要であれば第２の個人情報とを含む、個人情報の正当性確認要求を送信する（ステップＳ１１２）。

【0216】

確認部２０２（例えば、個人情報正当性確認部２２４）は、個人情報の正当性確認要求を受信すると、それに含まれる第１の個人情報の正当性を、第２の個人情報を基に確認する（ステップＳ１１３）。また、確認部２０２は、第１の個人情報の正当性が確認できた場合に、そのハッシュ値（個人情報Ｈａｓｈ３２Ｄ）を算出し、得られたハッシュ値に確認機関の署名３５Ｄを付して、要求元に確認結果とともに送信する（ステップＳ１１４〜ステップＳ１１６）。

【0217】

登録部１０２は、個人情報の正当性の確認が得られた場合、個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を算出し（ステップＳ１１７）、得られたハッシュ値に本人の署名３３Ｄを付す。そして、本人の署名３３Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄと確認機関の署名３５Ｄが付された個人情報Ｈａｓｈ３２Ｄとが登録された登録ブロックを作成する（ステップＳ１１８）。なお、作成した登録ブロックのブロックチェーン３への登録処理は、ステップＳ１０３と同様でよい。

【0218】

次に、図１７を参照して、確認フェーズにおける個人情報管理システムの動作を説明する。図１７は、本実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。なお、図１７に示す確認フェーズは、利用者に個人情報を開示させて、ブロックチェーン３内の登録ブロックを基に対象確認を行う第１の確認フェーズの例である。

【0219】

図１７に示す例では、まず確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、利用者側システム１０に個人ＩＤの開示要求を送信する（ステップＳ２０１）。

【0220】

個人ＩＤの開示要求を受けた利用者側システム１０の開示部１０３は、データ記憶部１０１から個人ＩＤ１３Ｄを読み出し、要求元に送信する（ステップＳ２０２、ステップＳ２０３）。

【0221】

個人ＩＤ１３Ｄを受信した確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、得られた個人ＩＤ１３Ｄのハッシュ値を含む確認記録ブロックをブロックチェーン３から検索する（ステップＳ２０４）。データ取得部２２１は、ステップＳ２０３で開示部１０３から、個人ＩＤ１３Ｄとともに同様の目的の対象確認の記録を示す確認記録ブロックの情報を取得し、それらを基に確認記録ブロックを検索してもよい。なお、開示部１０３は、例えば、そのようなブロックの情報を利用者側システム１０が保持している登録履歴より得てもよい。

【0222】

検索の結果、所望の確認記録ブロック（例えば、同一の目的での確認結果を示す確認情報３４Ｄを含む確認記録ブロック）が見つからなかった場合、データ取得部２２１は、さらに、対象確認に必要な個人情報の開示要求を開示部１０３に送信する（ステップＳ２０５）。該開示要求には要求する個人情報の種別が含まれていてもよい。

【0223】

開示部１０３は、個人情報の開示要求を受信すると、要求された種別の個人情報（ここでは、第１の個人情報）を読み出し、要求元に送信する（ステップＳ２０６、ステップＳ２０７）。このとき、開示部１０３は、利用者に該個人情報の開示の許可を取った上で、要求元に送信してもよい。

【0224】

データ取得部２２１は、第１の個人情報を取得すると、そのハッシュ値である個人情報Ｈａｓｈ３２Ｄ（以下、個人情報Ｈａｓｈ３２Ｄ−１と記す）が登録された登録ブロックをブロックチェーン３から検索する（ステップＳ２０８）。データ取得部２２１は、ステップＳ２０７で開示部１０３から、個人情報とともにそのハッシュ値が登録された登録ブロックの情報を取得し、それらを基に登録ブロックを検索してもよい。

【0225】

検索の結果、所望の登録ブロックを得ると、確認部２０２の登録情報信頼性確認部２２２は、登録ブロックに含まれる、少なくとも個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ−１について、それらに付された署名を基に、その信頼性を確認する（ステップＳ２０９：登録情報の信頼性確認）。なお、登録情報の信頼性の確認方法は上述した通りである。

【0226】

また、確認部２０２の元データ一致性確認部２２３は、登録ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび個人情報Ｈａｓｈ３２Ｄ−１について、それらの元データが、取得された個人ＩＤ１３Ｄおよび第１の個人情報と一致するかを、ハッシュ値同士の照合により確認する（ステップＳ２１０：元データの一致性確認）。なお、元データの一致性確認の方法は上述した通りである。

【0227】

なお、ステップＳ２０８で、データ取得部２２１は、第１の個人情報の正当性の確認記録を示す確認記録ブロックを検索してもよい。

【0228】

その場合、ステップＳ２０９の登録情報の信頼性確認処理では、確認記録ブロックに含まれる個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄについて、それらに付された署名を基に、その信頼性を確認すればよい。また、ステップＳ２１０の元データの一致性確認処理では、開示された第１の個人情報との比較対象とする個人情報Ｈａｓｈ３２Ｄ−１を、確認記録ブロックの確認情報３４Ｄを基に取得すればよい。例えば、データ取得部２２１は、確認情報３４Ｄにおいて示される正当性の確認対象とされたハッシュ値（個人情報Ｈａｓｈ３２Ｄ−１）を取得してもよい。また、例えば、データ取得部２２１は、確認情報３４Ｄに、正当性の確認対象とされたハッシュ値（個人情報Ｈａｓｈ３２Ｄ−１）が登録されている登録ブロックの情報（後述するＴｘＩＤ等）が含まれている場合は、該情報から該登録ブロックを検索し、検索された登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄ−１を取得してもよい。

【0229】

なお、検索の結果、所望の登録ブロックや確認記録ブロックが発見されなかった場合は、対象確認に用いる個人情報が未登録である旨を、利用者側システム１０に送信して、処理を終了してもよい。

【0230】

また、確認部２０２（例えば、個人情報正当性確認部２２４）は、登録ブロックに含まれる個人情報Ｈａｓｈ３２Ｄ−１に、例えば発行元や正規情報保持機関などの所定の条件を満たす確認機関の署名３５Ｄが付されていない場合、第１の個人情報について正当性確認を行ってもよい。

【0231】

例えば、個人情報正当性確認部２２４は、正当性確認に必要な情報（正当性確認情報）の開示要求を開示部１０３に送信する（ステップＳ２１１）。該開示要求には要求する個人情報の種別が含まれていてもよい。

【0232】

開示部１０３は、正当性確認情報の開示要求を受信すると、要求された種別の個人情報（ここでは、正当性確認情報とされる第２の個人情報）を読み出し、要求元に送信する（ステップＳ２１２、ステップＳ２１３）。ステップＳ２０６と同様、開示部１０３は、利用者に該個人情報の開示の許可を取った上で、要求元に送信してもよい。

【0233】

個人情報正当性確認部２２４は、正当性確認情報とされる第２の個人情報を取得すると、第２の個人情報に基づいて第１の個人情報の正当性を確認する（ステップＳ２１４：個人情報の正当性確認）。なお、個人情報の信頼性確認の方法は上述した通りである。ここで、データ取得部２２１が、さらに第２の個人情報のハッシュ値が登録された登録ブロックや、現在の利用者の生体情報などを取得してもよい。

【0234】

なお、ステップＳ２１１〜ステップＳ２１４の処理は、個人情報Ｈａｓｈ３２Ｄ−１が登録されている登録ブロックにおいて、該個人情報Ｈａｓｈ３２Ｄ−１に、所定の条件を満たす確認機関の署名３５Ｄが付されている場合は省略される。その場合、確認部２０２は、そのままステップＳ２１４の個人情報の正当性の確認結果を、確認ＯＫとすればよい。

【0235】

次いで、確認部２０２の結果出力部２２５は、これまでの処理結果から、開示された第１の個人情報の正当性の判定結果や、最終的な対象確認の結果を出力する（ステップＳ２１５）。

【0236】

結果出力部２２５は、例えば、ステップＳ２０９の登録情報の信頼性確認、ステップＳ２１０の元データの一致性確認およびステップＳ２１４の個人情報の正当性確認の結果がいずれもＯＫであった場合、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報であると判定してもよい。なお、いずれかの確認結果がＮＧであった場合、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報でないと判定してもよい。また、例えば、結果出力部２２５は、開示された第１の個人情報は、開示者であって開示された個人ＩＤが対応する利用者本人の正しい情報であると判定された場合において、その第１の個人情報に基づいて、当該確認機関が目的とする対象確認を行い、その確認結果を出力してもよい。対象確認の例として、年齢確認や、サービスの受給資格確認などが挙げられる。ここで、サービスの受給資格確認の一例として、開示された第１の個人情報で特定される、確認機関側システム内のユーザ情報（決済情報等）との照合が挙げられる。

【0237】

次いで、確認機関側システム２０（例えば、図示しないサービス提供部）は、結果出力部２２５から出力される、開示された第１の個人情報の正当性（本人確認を含む）の判定結果や、対象確認結果を基に、利用者にサービスを提供してもよい（ステップＳ２１６）。

【0238】

次いで、確認記録登録部２２６が、今回の確認の記録を示す確認記録ブロックを作成し、該ブロックをブロックチェーン３に登録する（ステップＳ２１７、ステップＳ２１８）。確認記録登録部２２６は、例えば、上記の登録ブロック内の個人情報Ｈａｓｈ３２Ｄ−１について所定の対象確認ＯＫの旨や、本人確認ＯＫの旨を示す確認情報３４Ｄを生成する。また、確認記録登録部２２６は、例えば、ステップＳ２０３で取得した個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）を算出する。そして、そのようにして得た個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄに対して当該確認機関の署名３５Ｄを生成し、該確認機関の署名３５Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄを含む確認記録ブロックを作成してもよい。なお、ブロックの登録処理は、ステップＳ１０３と同様でよい。

【0239】

このようにして、例えば１回目の対象確認が行われると、ブロックチェーン３に、その対象確認を行った確認機関の署名３５Ｄが付された個人ＩＤ＿Ｈａｓｈ３１Ｄと個人情報Ｈａｓｈ３２Ｄ−１に対する確認結果を示す確認情報３４Ｄとを含む確認記録ブロックが追加される。

【0240】

次に、図１８を参照して、確認フェーズにおける個人情報管理システムの動作を説明する。図１８は、本実施形態の個人情報管理システムの確認フェーズにおける動作の一例を示すフローチャートである。なお、図１８に示す確認フェーズは、利用者に個人情報を開示させずに、ブロックチェーンに３内の確認記録ブロックを基に対象確認を行う第２の確認フェーズの例である。

【0241】

図１８に示す例でも、まず確認機関側システム２０の確認部２０２（例えば、データ取得部２２１）は、利用者側システム１０に個人ＩＤの開示要求を送信する（ステップＳ２０１）。なお、ステップＳ２０１〜ステップＳ２０４までの処理は、第１の確認フェーズと同様でよい。

【0242】

本例では、検索の結果、所望の確認記録ブロック（例えば、同一の目的での確認結果を示す確認情報３４Ｄを含む確認記録ブロック）を得る。

【0243】

次いで、確認部２０２の登録情報信頼性確認部２２２は、確認記録ブロックに含まれる、個人ＩＤ＿Ｈａｓｈ３１Ｄおよび確認情報３４Ｄについて、それらに付された確認機関の署名３５Ｄを基に、その信頼性を確認する（ステップＳ２０９：登録情報の信頼性確認）。

【0244】

次いで、確認部２０２の結果出力部２２５は、これまでの処理結果から、最終的な対象確認の結果を出力する（ステップＳ２１５）。本例では、結果出力部２２５は、ステップＳ２０９の登録情報の信頼性確認の結果がＯＫであれば、確認記録ブロックの確認情報３４Ｄに含まれる確認結果が過去に得られていることを出力したり、過去の対象確認結果をそのまま援用してもよい。このとき、結果出力部２２５は、自身以外の確認機関による確認記録であった場合、そのまま援用せずに、対象確認を行った確認機関やその確認内容を出力した上で、確認機関側ユーザに対象確認結果の援用可否を問い合わせてもよい。

【0245】

援用可であった場合、確認機関側システム２０（例えば、図示しないサービス提供部）は、その対象確認結果を基に、利用者にサービスを提供してもよい（ステップＳ２１６）。なお、援用不可であった場合は、図１７に示すステップＳ２０５以降の処理を行えばよい。

【0246】

本例でも、確認記録登録部２２６が、今回の確認の記録を示す確認記録ブロックを作成し、該ブロックをブロックチェーン３に登録してもよい（ステップＳ２１７、ステップＳ２１８）。確認記録登録部２２６は、例えば、取得した個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）と、援用した確認記録ブロックの情報や対象確認結果を示す確認情報３４Ｄとに対して当該確認機関の署名３５Ｄを付し、確認記録ブロックを生成してもよい。

【0247】

このようにして、例えば２回目の対象確認が行われると、ブロックチェーン３に、その対象確認を行った確認機関の署名３５Ｄが付された、利用者の個人ＩＤ１３Ｄのハッシュ値である個人ＩＤ＿Ｈａｓｈ３１Ｄ、および援用した確認記録ブロックの情報や対象確認結果を示す確認情報３４Ｄとに対して当該確認機関の署名３５Ｄを含む確認記録ブロックが追加される。

【0248】

なお、３回目以降は、例えば、２回目の対象確認の記録を示す確認記録ブロックの登録情報の信頼性を確認した上で、その確認情報３４Ｄに示される情報から得られる対象確認結果等を利用することができる。例えば、援用した確認記録ブロック（３回目であれば、１回目の対象確認の記録を示す確認記録ブロック）の情報が取得された場合には、さらに、その援用した確認記録ブロックを取得し、その登録情報の信頼性確認や確認情報の検証を行い、援用の可否を問い合わせてもよい。

【0249】

また、図１９は、確認フェーズにおける確認機関側システム２０の動作をまとめたフローチャートである。図１９に示すように、確認部２０２のデータ取得部２２１は、まず利用者（より具体的には利用者側システム１０）から個人ＩＤ１３Ｄを取得する（ステップＳ３０１）。

【0250】

次いで、データ取得部２２１は、ブロックチェーン３から、その利用者の過去の確認記録ブロックを検索する（ステップＳ３０２）。

【0251】

同様の目的での確認記録を示す確認記録ブロックが存在した場合（ステップＳ３０３のＹｅｓ）、その確認記録ブロックの登録情報を取得した上で、ステップＳ３１０に進む。

【0252】

そのような確認記録ブロックが存在しなかった場合（ステップＳ３０３のＮｏ）、データ取得部２２１は、対象確認に用いる個人情報（第１の個人情報）の開示を利用者に要求する（ステップＳ３０３）。

【0253】

第１の個人情報を取得すると、ブロックチェーン３から、個人情報Ｈａｓｈ３２Ｄ−１が登録された登録ブロックまたは登録済みの個人情報Ｈａｓｈ３２Ｄ−１の元データに対して本人確認を行った記録を示す確認記録ブロックを検索する（ステップＳ３０４）。

【0254】

そのような登録ブロックや確認記録ブロックが確認されると、そのブロックの登録情報を取得した上で、ステップＳ３０５に進む。

【0255】

ステップＳ３０５では、取得された登録情報における、個人情報Ｈａｓｈ３２Ｄ−１に付されている確認機関の署名３５Ｄの有無や、取得された登録情報に含まれる確認情報３４Ｄの確認結果などから、ブロックチェーン３に登録されている個人情報Ｈａｓｈ３２Ｄ−１に関し、過去にその元データ（第１の個人情報）の正当性が確認されているか否かを確認する。

【0256】

元データ（第１の個人情報）の正当性が確認済みでなければ（ステップＳ３０５のＮｏ）、データ取得部２２１は、第１の個人情報の正当性を確認できる第２の個人情報（正当性確認情報）の開示をさらに利用者に要求する（ステップＳ３０６）。

【0257】

そして、個人情報正当性確認部２２４が、取得された第２の個人情報を基に、利用者から取得した第１の個人情報の正当性を確認する（ステップＳ３０７）。第１の個人情報の正当性の確認が終わると、ステップＳ３１１に進む。

【0258】

一方、元データ（第１の個人情報）の正当性が確認済みであれば（ステップＳ３０５のＹｅｓ）、データ取得部２２１は、ブロックチェーン３に登録されている、元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１を取得した上で、ステップＳ３０８に進む。

【0259】

ステップＳ３０８では、元データ一致性確認部２２３が、ブロックチェーン３内の元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとされる第１の個人情報（登録時の個人情報）と、利用者から取得した第１の個人情報との一致性を確認する。元データ一致性確認部２２３は、利用者から取得した第１の個人情報からハッシュ値を算出し、それとブロックチェーン３内の元データの正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１とが一致するかを確認すればよい。

【0260】

正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとの一致性が確認されなかった場合（ステップＳ３０９のＮｏ）、そのままステップＳ３１１に進む。

【0261】

一方、正当性が確認済みである個人情報Ｈａｓｈ３２Ｄ−１の元データとの一致性が確認された場合（ステップＳ３０９のＹｅｓ）、ステップＳ３１０に進む。

【0262】

ステップＳ３１０では、登録情報信頼性確認部２２２が、これまでの判定に用いた情報の取得先である登録情報（ステップＳ３０３の確認記録ブロックやステップＳ３０４の登録ブロックまたは確認記録ブロックの登録情報等）について、それに付された署名を用いた信頼性確認を行う。なお、登録情報信頼性確認部２２２は、登録情報の一部の情報を取得した場合、少なくとも該情報と、該情報と対応づけられている個人ＩＤ＿Ｈａｓｈ３１Ｄについて、信頼性確認を行う。

【0263】

また、本例では、先に個人情報の正当性確認の有無を判定した上で、個人情報の正当性確認、または元データとの一致性確認および登録情報の信頼性確認を行う例を示したが、これら確認の順番は特に問わない。例えば、ブロックの登録情報から情報（確認情報３４Ｄや個人情報Ｈａｓｈ３２Ｄ−１等）を取得する度に、該情報と、それと対応づけられた個人ＩＤ＿Ｈａｓｈ３１Ｄとについて同ブロック内においてそれらに付された署名を用いて信頼性を確認してもよい。

【0264】

また、ステップＳ３１１では、これまでの確認結果や、それに基づく開示された情報の正当性の判定結果や、最終的な対象確認の結果を出力する。なお、同様の目的での確認記録ブロックが発見された場合には、その確認結果の援用有無を問い合わせてもよい。また、これまでの確認結果や、開示された情報の正当性の判定結果を出力した上で、確認機関側ユーザから、対象確認結果を受け付けてもよい。

【0265】

また、確認部２０２は、対象確認に複数の個人情報が必要な場合にそれらについて未取得な情報または正当性が未確認な情報があるなど、対象確認が完了していない場合（ステップＳ３１２のＮｏ）は、ステップＳ３０３に戻る。そして、必要な個人情報の要求を利用者に行ってもよい。なお、確認部２０２は、対象確認が完了したか否かを、確認機関側ユーザから受け付けることで判定してもよい。

【0266】

一方、確認部２０２は、対象確認が完了した場合には（ステップＳ３１２のＹｅｓ）、今回の確認の記録を示す確認記録ブロックを作成し、ブロックチェーン３に登録して処理を終了する（ステップＳ３１４）。

【0267】

以上のように、本実施形態によれば、元データの正当性の確認記録や様々な目的での確認記録がブロックチェーン３内に登録されていくことで、一つの個人ＩＤを開示するだけで、免許証やパスポートに代わる本人確認を行うことができるようになる。このため、利用者は目的や用途ごとに本人確認の手続きをする必要がなくなる。

【0268】

例えば、単に個人ＩＤを開示するだけではその個人ＩＤの所有者の身元や要求されたサービスを享受できる権限（受給資格）の有無は確認できない。しかし、本実施形態によれば、例えば一度目の個人ＩＤの開示において、サービスの受給資格があるか、また必要であればその個人ＩＤの所有者が誰であるかの確認（本人確認）を、その個人ＩＤに対応づけられている個人情報を基に確認し、当該確認に用いた情報の正しさを示すハッシュ値やその結果を確認者の署名とともに、ブロックチェーン３に記録をする。そして、二度目以降の同様のサービスを利用するシーンにおいて、サービス提供側で過去の確認結果を確認、その内容を検証することで、同様の確認結果を与えられるようにしている。

【0269】

例えば、ある利用者が、年齢情報である生年月日や成人か否かの情報について、所定の確認機関に正当性（その個人ＩＤが示す利用者本人の正しい情報であること）を確認させた上で、そのハッシュ値を個人ＩＤのハッシュ値と対応づけてブロックチェーンに登録していた場合を想定する。

【0270】

そのような場合に、ある店舗Ａでお酒を購入するシーンにおいて、一度目は、個人ＩＤ開示後に年齢情報の開示要求がなされ、利用者の許可の下、その年齢情報である生年月日や成人か否かの情報が店舗側に開示される。

【0271】

店舗Ａでは、開示された情報の正当性を、ブロックチェーンの記録を基に確認できる。このため、店舗Ａでは、開示された情報（生年月日や成人か否かの情報）だけで、年齢確認を行ってお酒を提供できる。このとき、店舗Ａは、年齢確認の結果（成人である旨の確認結果）を、開示された個人ＩＤのハッシュ値とともに自身の署名を付してブロックチェーンに記録する。

【0272】

次に、別の店舗Ｂでお酒を購入するシーンにおいて、同種の年齢確認について二度目となるケースでは、個人ＩＤを開示後、店舗Ｂにより年齢情報の開示要求がなされた場合に、利用者は、年齢情報の開示に代えて１回目の年齢確認の結果が記録された確認記録ブロックの情報を開示できる。店舗Ｂでは、開示された情報を基に、１回目の年齢確認の結果をブロックチェーンから取得することで、この個人ＩＤが店舗Ａで既に同種の年齢確認がされ、サービス提供を受けていることを確認できる。なお、店舗Ｂは、確認の記録の開示ではなく、二度目の確認においても、本人確認の情報開示を要求することもできる。これらはサービス提供側のポリシーによって定められるが、同様のサービス提供であれば、二度目の開示が確認記録の開示で済む場合も多く考えられる。

【0273】

このようにして、利用者は、サービス利用にあたって、本人確認のために免許証などの複数の個人情報を含む情報を開示する代わりに、種々の個人情報と互いのハッシュ値を経由して対応づけられている１つの個人ＩＤを開示するだけで、当該個人ＩＤと対応づけられている個人情報またはそれを用いた確認記録を開示したと同等の利益を享受できるようになる。したがって、本システムのサービスを複数のベンダやサービスで共有すれば、サービスごとやベンダごとに個人を識別する情報が増えるのを防止できる。

【0274】

また、本実施形態によれば、一度、元の個人情報の正当性が確認され、その記録がブロックチェーンに登録されていれば、１回目においても、年齢確認のために必要な情報（生年月日等）の正当性を確認するために年齢確認とは関係ない不必要な個人情報（免許証番号や名前、住所など）を開示することを防止できる。このように、本実施形態によれば、個人ＩＤに対応づけられた個人情報を選択的に開示することができるので、確認に必要最小限な情報のみを開示するといったコントロールが可能となる。

【0275】

なお、本実施形態では、各ブロックに個人ＩＤのハッシュ値を登録するようにしているため、サーバダウンなどによるサービスの停止が想定されないブロックチェーンの特性上、利用開始時に発行された個人ＩＤは、利用者や管理者の意志によって無効としない限り、永続的に使用できる。

【0276】

なお、これは、クライアントデバイスにおいて個人ＩＤが認証情報とともに対応づけられていた場合、クライアントデバイスの紛失によって登録された記録は書き換えられないことを意味する。このため、仮にクライアントデバイスが紛失した場合には、次のような方法によって個人ＩＤをリカバリできるようにしてもよい。

【0277】

第１の方法としては、本システム利用開始時に個人ＩＤを割り当てる際、当該個人ＩＤとその認証情報としてのデバイスＩＤとの組に対して複数の認証メンバを登録しておく方法が挙げられる。利用者は、デバイス紛失した場合、認証メンバに新たなデバイスＩＤを通知する。このとき、一定数の認証メンバの承認により新たなデバイスＩＤで当該個人ＩＤを再利用可能としてもよい。当該方法は、ｕＰｏｒｔと呼ばれるブロックチェーンのＩＤ管理プラットフォームを利用して実現してもよい。

【0278】

より具体的には、利用者に対してブロックチェーンネットワークにおけるユーザキーとして、ｕＰｏｒｔＩＤと呼ばれる、Ｐｒｏｘｙコントラクトのアドレスとなる永続的なＩＤを用意する。なお、ｕＰｏｒｔＩＤは、ＵｓｅｒＡｄｄｒｅｓｓからＰｒｉｖａｔｅＫｅｙを用いて作成される。ここで、ＵｓｅｒＡｄｄｒｅｓｓは、ユーザデバイスキーと対応するＥＯＡ（Ｅｔｈｅｒｅｕｍアカウント）のアドレスに相当する。また、本例においてクライアントデバイスに相当するｕＰｏｒｔデバイスは、デバイスＩＤとペアとなるＵｓｅｒＡｄｄｒｅｓｓ（ＥＯＡ）と、秘密鍵とをもつ。

【0279】

このようなＥｈｔｅｒｅｕｍブロックチェーンネットワークを利用して、例えば、ユーザは、ｕＰｏｒｔデバイスを紛失した場合、まず新しいデバイスでＥｔｈｅｒｅｕｍに接続し、新しいＵｓｅｒＡｄｒｅｓｓを取得する。そして、新しいＵｓｅｒＡｄｒｅｓｓを、事前に登録された認証メンバ（リアルなｄｅｌｅｇａｔｅメンバ等）に通知する。

【0280】

認証メンバは、Ｒｅｃｏｖｅｒｙコントラクトを呼び出し、ユーザ確認を行うなどして、新しいＵｓｅｒＡｄｒｅｓｓを認証する。認証の結果、一定数以上の承認が得られた場合、新しいＵｓｅｒＡｄｒｅｓｓは、Ｃｏｎｔｒｏｌｌｅｒコントラクトに通知されて、古いＵｓｅｒＡｄｒｅｓｓと書き換えられる。

【0281】

これにより、Ｐｒｏｘｙコントラクトにおいてクライアントデバイスの識別情報として機能するＵＰｏｒｔＩＤは変わらずに、実際のデバイスＩＤと対応するＥＯＡのみを変更できる。このように、デイバスＩＤと対応するＥＯＡと、ブロックチェーン上のデータと対応するＰｒｏｘｙアドレスとを分断することで、デバイス紛失などによるクライアントデバイスの交換時にも既存のデータとの接続性を維持できる。ここで、ｕＰｏｒｔＩＤが上記の個人ＩＤに相当する。

【0282】

また、別の方法としては、本システム利用開始時に個人ＩＤを割り当てた際、その個人ＩＤのハッシュ値と対応づけて本人確認やユーザ認証が可能な個人情報のハッシュ値が登録された登録ブロックをブロックチェーンに追加させておく方法が挙げられる。当該方法では、新たなデバイスにそのような個人情報とそれが登録されたときの個人ＩＤとが登録された場合に、新たなデバイスに対して該個人情報と同等の登録情報を用いたユーザ認証を行うことで、新たなデバイスでの当該個人ＩＤを再利用可能としてもよい。

【0283】

例えば、電話番号であればＳＭＳ認証、メールアドレスであればそのメールアドレス宛てのメール送信、生体情報であれば現在の利用者の生体情報との比較などにより、新たなデバイスでのユーザ認証が通れば、新たなデバイスでその個人ＩＤを再利用可能としてもよい。

【0284】

実施形態３．
次に、上述した第２の個人情報管理システムの具体的な利活用例をいくつか説明する。本実施形態では、チケットの転売防止に上記のサービス提供システムや個人情報管理システムを利用した例としてチケットサービスシステムについて説明する。図２０は、第３の実施形態のチケットサービスシステムの概略構成図である。図２０に示すチケットサービスシステムは、個人用端末１０Ａと、サービス提供装置２１Ａと、入場装置２２Ａと、ブロックチェーンネットワーク（以下、ブロックチェーンＮＷという）３０Ａとを備える。

【0285】

ここで、個人用端末１０Ａは、上記の利用者側システム１０に相当する。なお、本例の利用者側システム１０としての個人用端末１０Ａは、上記の個人用端末６１の機能（ＳＮＮＡＰＰ部６１１やＩＭＳＡＰＰ部６１２等）をさらに含んでいてもよい。また、サービス提供装置２１Ａおよび入場装置２２Ａは、上記の確認機関側システム２０に相当する。なお、本例の確認機関側システム２０としてのサービス提供装置２１Ａおよび入場装置２２Ａは、上記のサービスサーバ６４の機能（例えば、ＳＮＳ側サービス提供部６４１や対象確認サービス部６４２）をさらに含んでいてもよい。サービス提供装置２１Ａは、より具体的には、チケット情報の発行元の機関（チケットの販売会社等）の確認機関側システム２０に相当する。入場装置２２Ａは、チケット情報を基にチケット購入者の該場所（イベント会場等）への入退場をチェックする機関（コンサートの運営会社等）の確認機関側システム２０に相当する。入場装置２２Ａは、例えば、サービス提供装置２１Ａが発行したチケットが使用される場所に設置される。なお、サービス提供装置２１Ａと入場装置２２Ａとが、同じ機関の確認機関側システム２０に属していてもかまわない。

【0286】

また、ブロックチェーンＮＷ３０Ａは、上記のＩＭＳプラットフォーム６３の一部や上記の台帳管理システム３０に相当する。なお、図示省略しているが、ブロックチェーンＮＷ３０Ａは、本システムで使用可能なブロックチェーン３を実装する他、上記の管理側システム５０の機能（個人ＩＤの割当やペア鍵の生成等）を行う。なお、本例では、ブロックチェーン３においてブロックの作成者を識別する識別子（上記のｕＰｏｒｔＩＤ等）が個人ＩＤ１３Ｄを兼ねている。この場合、管理側システム５０の機能を個人用端末１０Ａが有していてもよい。

【0287】

本例において、個人用端末１０Ａには、本例における利用者側アプリケーションとして、利用者が本システムを利用してチケット購入サービスを受けるための手続きを行うチケット購入アプリケーションがダウンロードされている。チケット購入アプリケーションは、当該個人用端末１０ＡのＣＰＵ上で動作して、本システムにおける利用者側システム１０の所定の処理を当該個人用端末１０Ａに実行させる。なお、本例では、チケット購入アプリケーションのダウンロード時に、個人ＩＤの割当および鍵ペアの生成が行われるものとする。

【0288】

また、サービス提供装置２１Ａには、本例における第１のサービス提供側アプリケーションとして、チケット情報管理アプリケーションが予め実装されているものとする。ここで、チケット情報管理アプリケーションは、利用者からの購入申請に応じて、ブロックチェーン３内の情報を利用した本人確認を含むチケットの購入資格の審査および入金確認を行いつつ、利用者に販売するための手続きを行うアプリケーションである。当該アプリケーションは、例えば、サービス提供装置２１ＡのＣＰＵ上で動作して、本システムにおける確認機関側システム２０の所定の処理を当該サービス提供装置２１Ａに実行させる。

【0289】

また、入場装置２２Ａには、本例における第２のサービス提供側アプリケーションとして、チケット情報確認アプリケーションが予め実装されているものとする。ここで、チケット情報確認アプリケーションは、利用者からの入退場申請に応じて、ブロックチェーン３内の情報を利用した本人確認を含む入退場資格の審査を行いつつ、利用者の入退場を管理するための手続きを行うアプリケーションである。当該アプリケーションは、例えば、入場装置２２ＡのＣＰＵ上で動作して、本システムにおける確認機関側システム２０の所定の処理を当該入場装置２２Ａに実行させる。

【0290】

次に、本例のチケットサービスシステムの動作を説明する。図２１は、本実施形態のチケットサービスシステムの動作の概略を示すフローチャートである。図２１に示すように、本例のチケットサービスシステムでは、まず、利用者が、本システムに対して本人登録を行う（ステップＳ４０１Ａ）。

【0291】

ステップＳ４０１Ａでは、利用者からの指示に応じて、個人用端末１０Ａが、チケット購入時および会場への少なくとも入場時に行われる本人確認のための生体情報（例えば、顔写真等）を取得するとともに、チケット購入時に必要とされる個人情報（例えば、住所、氏名、クレジットカード番号等）を読み出す。そして、個人用端末１０Ａは、それらの各々またはそれらの組み合わせである所定の開示単位についてハッシュ値を算出するとともに、当該利用者に割り当てられた個人ＩＤ１３Ｄについてハッシュ値を算出する。なお、各ブロック内において個人を特定するための情報として、個人ＩＤ＿Ｈａｓｈ３１Ｄではなく個人ＩＤ１３Ｄをそのまま用いることも可能である。その場合には、以降の処理において個人ＩＤ＿ｈａｓｈ３１Ｄを個人ＩＤと読み替えるとともに、個人ＩＤ＿ｈａｓｈ３１Ｄに対する信頼性確認処理を省略すればよい。なお、上記の実施形態においても同様とする。

【0292】

本例では、住所と氏名の組が、サービス提供装置２１Ａが提供するチケット購入サービスにおいてチケット購入時のユーザ情報として用いられ、クレジットカード番号が、同サービスにおいて決済情報として用いられることを想定している。なお、生体情報は、既に説明したように、チケット購入時および会場への少なくとも入場時に行われる本人確認情報として用いられることを想定している。

【0293】

以下、説明を簡単にするために、住所と氏名の組を個人情報１４Ｄ（１）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（１）と記す場合がある。また、決済情報としてのクレジットカード番号を個人情報１４Ｄ（２）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（２）と記す場合がある。また、生体情報を個人情報１４Ｄ（３）と記し、そのハッシュ値を個人情報Ｈａｓｈ３２Ｄ（３）と記す場合がある。

【0294】

個人用端末１０Ａは、個人情報１４Ｄ（１），（２），（３）および個人ＩＤ１３Ｄについてそれぞれハッシュ値（個人情報Ｈａｓｈ３２Ｄ（１），（２），（３））を算出すると、それらとそれに付された本人の署名３３Ｄとを登録情報とする登録ブロックの追加要求をブロックチェーンＮＷ３０Ａに要求して、ブロックチェーン３に登録させる。

【0295】

ブロックチェーン３にブロックが登録されると、個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａから、ブロックチェーン３内においてその個人ＩＤ１３Ｄに関する情報のブロックを識別するトランザクションＩＤ（ＴｘＩＤ）を受信する。ステップＳ４０１Ａでは、当該個人ＩＤ１３Ｄにおける始めての登録ブロックであることを示す、ＴｘＩＤ＝１を受信する。

【0296】

本例のチケットサービスシステムでは、ブロックチェーン３内のブロックの指定を、このＴｘＩＤを用いて行う。したがって、個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａから得られる自身の個人ＩＤ１３ＤにおけるＴｘＩＤを登録履歴として保持しておく。個人用端末１０Ａは、登録履歴として、例えば、登録ブロックのＴｘＩＤと、少なくとも最新の確認記録ブロックのＴｘＩＤとを保持しておいてもよい。

【0297】

このようにして、生体情報を含む個人情報のハッシュ値が本人の署名３３Ｄとともに個人ＩＤ１３Ｄのハッシュ値と対応づけられた登録ブロックがブロックチェーン３に登録されると、本人登録が完了する。

【0298】

本人登録が完了すると、次いで、利用者は、サービス提供装置２１Ａに対してチケットの購入申請を行う（ステップＳ４０２Ａ）。ステップＳ４０２Ａでは、個人用端末１０Ａは、例えば、個人ＩＤ１３Ｄと購入したいチケットの情報とを含むチケット購入申請を、サービス提供装置２１Ａに送信する。

【0299】

チケット購入申請を受け付けたサービス提供装置２１Ａは、それに含まれる個人ＩＤ１３Ｄと、さらに申請者から直接開示される個人情報とを基に、利用者のブロックチェーン３内の登録情報を利用して、購入資格を確認する（ステップＳ４０３Ａ）。本例の個人情報管理システムレベルでの購入資格としては、チケット購入に必要な個人情報であって本人確認に用いられる生体情報と一緒にそれらのハッシュ値がブロックチェーン３内に登録されている個人情報（上記の個人情報１４Ｄ（１）（２））が開示されること、としている。ただし、一部の個人情報（本例では、個人情報１４Ｄ（１））については、ブロックチェーン３内に登録している過去の購入記録の開示で代替可能としている。なお、チケットサービスシステムレベルでの購入資格には、さらに開示された情報により決済が正常に行われることなどが追加される。

【0300】

また、例えば、入場時だけでなく、購入時にも本人確認を行いたい場合には、上記の購入資格に、さらに、申請者に対して開示された個人情報または過去の購入の際に開示した個人情報の所有者としての本人確認がとれること、を追加することも可能である。なお、これらはあくまで一例であり、サービス提供元で自由に定めればよい。

【0301】

本例のサービス提供装置２１Ａは、本例の購入資格の確認処理として、要求元の利用者（申請者）に対して、過去の購入記録を含めて少なくとも１度の個人情報１４Ｄ（１）の開示と、購入の度の個人情報１４Ｄ（２）の開示とを少なくとも要求し、開示された情報の正当性を確認する（ステップＳ４０３Ａ）。サービス提供装置２１Ａは、開示された情報について、ブロックチェーン３内の登録情報（確認記録を含む）との照合を行って、該情報の正当性を確認すればよい。なお、登録情報との照合には、上述したような元データの一致性確認や登録情報自体の信頼性確認も含まれる。

【0302】

なお、サービス提供装置２１Ａは、購入資格の確認処理において、申請者（より具体的には上記２つの個人情報を開示した開示者）に対して本人確認を行うこともできる。その場合、サービス提供装置２１Ａは、個人用端末１０Ａに、申請者の現在の生体情報をさらに開示させ、そのハッシュ値と、登録ブロックに登録されている個人情報Ｈａｓｈ３２Ｄ（３）とを比較して本人確認を行ってもよい。なお、生体情報によっては登録時と現在の情報が完全には一致しない場合があり、ハッシュ値での比較、照合が難しいことも考えられる。そのような場合には、登録された生体情報のハッシュ値である個人情報Ｈａｓｈ３２Ｄ（３）の元データ（登録時の生体情報）を開示させて、申請者の現在の生体情報との照合を行えばよい。なお、上記の本人確認を、個人用端末１０Ａ（より具体的には、確認機関側システムの確認部２０２の一部の機能を含むチケット購入アプリケーション）側で行うことも可能である。

【0303】

サービス提供装置２１Ａは、このようにして申請者の購入資格が確認されると、申請者にチケットを発行する。サービス提供装置２１Ａは、購入資格が確認されチケットを発行すると、確認情報３４Ｄとして、チケット発行情報（例えば、チケットが発行されたことや発行されたチケット情報やチケット発行時における購入資格の確認記録を示す情報）を含む確認記録ブロックをブロックチェーン３に登録する（ステップＳ４０４Ａ）。確認記録ブロックには、開示された個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）が含まれるとともに、該個人ＩＤ＿Ｈａｓｈ３１Ｄと該確認情報３４Ｄとに対してチケット情報の発行元である確認機関の署名３５Ｄが付される。なお、発行されたチケット情報自体はサービス提供装置２１Ａ側で保持しておき、確認記録ブロックには、そのチケット情報を識別する識別子（サービスＩＤ）を登録してもよい。

【0304】

確認記録ブロックの登録が完了すると、サービス提供装置２１Ａは、要求元の個人用端末１０Ａに、発行されたチケット情報として、サービスＩＤやそれが記録された確認記録ブロックのＴｘＩＤを返信する。

【0305】

次に、このようにして発行されたチケットを利用して、利用者が会場へ入場する場面を考える。本例では、利用者は、入場装置２２Ａに対して入場申請を行えばよい（ステップＳ４０５Ａ）。ステップＳ４０５Ａでは、個人用端末１０Ａは、例えば、個人ＩＤ１３Ｄと、サービス提供装置２１Ａから受信したチケット情報（サービスＩＤやそれが記録された確認記録ブロックのＴｘＩＤ等）とを含む入場申請を、入場装置２２Ａに送信する。

【0306】

入場申請を受け付けた入場装置２２Ａは、それに含まれる情報を基に、利用者のブロックチェーン３内の登録情報を利用して、入場資格を確認する（ステップＳ４０６Ａ）。本例の個人情報管理システムレベルでの入場資格としては、利用者に対してチケット発行情報を含む確認記録ブロックがブロックチェーン３に登録されており、かつ申請者に対して購入時に開示もしくは参照した個人情報の所有者としての本人確認がとれること、としている。なお、これらはあくまで一例であり、サービス提供元で自由に定めればよい。

【0307】

入場装置２２Ａは、本例の入場資格の確認処理として、開示されたチケット情報からチケット発行情報を含む確認記録ブロックの有無およびその登録情報の正当性を確認するとともに、申請者に対して本人確認を行う。確認記録ブロックの登録情報の正当性は、チケット情報の発行元とされる確認機関の公開鍵を利用して確認すればよい。なお、本人確認の方法は上述した方法と同様でよい。

【0308】

入場装置２２Ａは、このようにして申請者の入場資格が確認されると、ゲート（不図示）を開けたり、入場許可を示す情報を出力するなどの入場処理を行う。また、入場装置２２Ａは、入場資格が確認され入場処理を実施すると、確認情報３４Ｄとして、入場処理をした旨を示す入場情報を含む確認記録ブロックをブロックチェーン３に登録してもよい（ステップＳ４０７Ａ）。確認記録ブロックには、開示された個人ＩＤ１３Ｄのハッシュ値（個人ＩＤ＿Ｈａｓｈ３１Ｄ）が含まれるとともに、該個人ＩＤ＿Ｈａｓｈ３１Ｄと該確認情報３４Ｄとに対してチケット情報の発行元である確認機関の署名３５Ｄが付される。

【0309】

なお、再入場の際も、入場申請と同様の方法で本人確認の上で入場処理を行ってもよい。なお、途中退場する際に退場記録をブロックチェーン３に登録しておき、さらにその情報との照合処理を行うことも可能である。

【0310】

なお、図２２〜図２５は、上記の本人登録時、購入申請時および入場申請時の処理の流れの一例を示すシーケンス図である。

【0311】

図２２は、本人登録時の処理の流れの一例を示すシーケンス図である。なお、本人登録の前に、個人ＩＤ１３Ｄの割り当てや、ペア鍵の発行は行われているものとする。

【0312】

図２２に示す例では、まず利用者が個人用端末１０Ａに対して個人情報の登録指示を行う（ステップＳ５０１）。個人情報の登録指示を受け付けると、個人用端末１０Ａは、個人情報１４Ｄ（１）（２）（３）を取得し、それらについて各々ハッシュ値を算出し、個人情報Ｈａｓｈ３２Ｄ（１）（２）（３）を得る（ステップＳ５０２）。

【0313】

次いで、個人用端末１０Ａは、個人ＩＤ１３Ｄと、個人情報Ｈａｓｈ３２Ｄ（１）（２）（３）と、それらに付す本人の署名３３Ｄとを含むブロック追加要求をブロックチェーンＮＷ３０Ａに送信する（ステップＳ５０３）。

【0314】

ブロックチェーンＮＷ３０Ａでは、ブロック追加要求に含まれる情報を登録情報として含むブロック（登録ブロック）をブロックチェーン３に追加する（ステップＳ５０４）。

【0315】

個人用端末１０Ａは、ブロックチェーンＮＷ３０Ａからブロック追加応答を受信すると（ステップＳ５０５）、追加したブロックのＴｘＩＤ（本例では、ＴｘＩＤ＝１）を登録履歴に保持するとともに、以降の開示要求に備えて、登録時の個人情報すなわち登録ブロックの登録時の元データである個人情報１４Ｄ（１）（２）（３）を保存する（ステップＳ５０６）。その後、利用者に完了通知を行う（ステップＳ５０７）。

【0316】

また、図２３〜図２４は、購入申請時の処理の流れの一例を示すシーケンス図である。なお、図２４は、図２３のつづきである。図２３〜図２４に示す例では、まず利用者が、個人用端末１０Ａに対して購入申請の指示を行う（ステップＳ５１１）。このとき、購入したいチケットの情報が指定されてもよい。

【0317】

購入申請の指示を受け付けると、個人用端末１０Ａは、サービス提供装置２１Ａに、個人ＩＤ１３Ｄを含む購入申請を送信する（ステップＳ５１２）。

【0318】

個人用端末１０Ａからの購入申請を受けたサービス提供装置２１Ａは、まず要求元の個人用端末１０Ａに、個人情報１４Ｄ（１）を指定した個人情報の開示要求Ａを送信する（ステップＳ５１３）。

【0319】

個人情報の開示要求Ａを受信した個人用端末１０Ａは、例えば、登録履歴を検索して過去に当該チケットサービスシステム内において個人情報１４Ｄ（１）の開示や、それを伴う同等の対象確認（本例では購入資格確認）があったか否かを確認してもよい。

【0320】

過去に個人情報１４Ｄ（１）の開示も同等の対象確認もなければ、個人用端末１０Ａは、利用者の許可を得て、個人情報１４Ｄ（１）を開示する。本例では、個人用端末１０Ａは、個人情報１４Ｄ（１）と、その正当性を示す情報（個人情報Ｈａｓｈ３２Ｄ（１）と本人の署名３３Ｄ等）を含む登録ブロックのＴｘＩＤとを含む個人情報開示応答Ａを、サービス提供装置２１Ａに送信する（ステップＳ５１４）。

【0321】

個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報開示応答Ａに含まれるＴｘＩＤを基に、個人情報１４Ｄ（１）の登録ブロックを取得する（ステップＳ５１５）。そして、サービス提供装置２１Ａは、登録ブロックの登録情報の信頼性確認および元データの一致性確認（開示された個人情報１４Ｄ（１）と登録ブロック内の個人情報Ｈａｓｈ３２Ｄ（１）の元データ間の一致性確認）を行って、開示された個人情報１４Ｄ（１）の正当性を確認する（ステップＳ５１６）。このとき、サービス提供装置２１Ａは、個人情報１４Ｄ（１）の開示がされ、かつその正当性が確認されたことを示す購入資格確認Ａの記録を、確認記録ブロックにしてブロックチェーン３に登録してもよい。その結果として、該確認記録ブロックのＴｘＩＤ（本例では、ＴｘＩＤ＝２）を受信する（ステップＳ５１７、ステップＳ５１８）。

【0322】

一方、個人用端末１０Ａは、過去に個人情報１４Ｄ（１）の開示や同等の対象確認（本例では購入資格確認）があった場合、個人情報１４Ｄ（１）に代えて、そのときの確認記録ブロックのＴｘＩＤ（例えば、上記のＴｘＩＤ＝２や後述するＴｘＩＤ＝４等）を含む個人情報開示応答Ａを、サービス提供装置２１Ａに送信する（ステップＳ５１９）。

【0323】

個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報開示応答Ａに含まれるＴｘＩＤを基に、個人情報１４Ｄ（１）についての正当性確認結果や同等のサービス受給資格（チケット購入資格）を示す確認記録ブロックを取得する（ステップＳ５２０）。そして、サービス提供装置２１Ａは、確認記録ブロックの登録情報の信頼性確認を行って、その登録情報が示す確認結果を検証（援用判定）する（ステップＳ５２１）。

【0324】

本例では、自身の機関が登録した確認記録ブロックであれば、その登録情報の信頼性確認（作成者証明および非改ざん証明）がされれば、個人情報１４Ｄ（１）の開示は省略可能とする。ステップＳ５２１の確認についても、サービス提供装置２１Ａは、指定された確認記録ブロックの確認結果により個人情報１４Ｄ（１）の正当性が確認されたことを示す購入資格確認Ａの記録を、確認記録ブロックにしてブロックチェーン３に登録してもよい。その結果として、該確認記録ブロックのＴｘＩＤを受信する（ステップＳ５２２、ステップＳ５２３）。

【0325】

個人情報１４Ｄ（１）の開示および／または正当性確認が完了すると、サービス提供装置２１Ａは、要求元の個人用端末１０Ａに、決済情報としての個人情報１４Ｄ（２）を指定した個人情報の開示要求Ｂを送信する（ステップＳ５２４）。なお、本例では、決済情報としての個人情報１４Ｄ（２）は確認記録での開示は認められない。

【0326】

個人情報の開示要求Ｂを受信した個人用端末１０Ａは、利用者の許可を得て、個人情報１４Ｄ（２）を開示する。本例でも、個人用端末１０Ａは、個人情報１４Ｄ（２）と、その正当性を示す情報（個人情報Ｈａｓｈ３２Ｄ（２）と本人の署名３３Ｄ等）を含む登録ブロックのＴｘＩＤとを含む個人情報開示応答Ｂを、サービス提供装置２１Ａに送信する（ステップＳ５２５）。

【0327】

個人情報開示応答Ａを受信したサービス提供装置２１Ａは、個人情報１４Ｄ（１）を受信した場合と同様の正当性確認の行い、その記録をブロックチェーン３に追加する（ステップＳ５２６〜ステップＳ５２９）。

【0328】

サービス提供装置２１Ａは、このようにして個人情報１４Ｄ（１）の正当性が少なくとも確認され、かつ正当な個人情報１４Ｄ（２）が取得されたことを受けて、購入資格の確認を完了する。そして、サービス提供装置２１Ａは、指定されたチケットをその利用者に発行する（ステップＳ５３０）。このとき、サービス提供装置２１Ａは、チケットが発行されたことを示すチケット発行情報を含む確認記録ブロックをブロックチェーン３に登録する（ステップＳ５３１）。その結果として、該確認記録ブロックのＴｘＩＤ（例えば、ＴｘＩＤ＝３）を受信する（ステップＳ５３２）。

【0329】

チケット発行情報には、当該サービス提供装置２１Ａにおいて今回のチケットの発行にかかる情報（発行先の利用者の情報や入場時等に必要なブロックのＴｘＩＤ（発行記録ＴｘＩＤや発行処理において登録したブロックや参照したブロックのＴｘＩＤ）や個人情報等）と対応づけられたサービスＩＤが含まれているものとする。また、サービス提供装置２１Ａは、そのようなサービスＩＤと対応づけて、今回のチケットの発行にかかる情報を保持する（ステップＳ５３３）。

【0330】

以上の処理を終えると、サービス提供装置２１Ａは、購入申請に対して購入許可を、今回のチケットの発行にかかる情報を識別するためのサービスＩＤや、今回のチケットの発行記録が登録されたＴｘＩＤ（図中の発行記録ＴｘＩＤ）とともに、要求元の個人用端末１０Ａに返信する（ステップＳ５３４）。

【0331】

購入許可を受信した個人用端末１０Ａは、購入許可とともに受信したサービスＩＤや発行記録ＴｘＩＤを、発券チケット情報として保存する（ステップＳ５３５）。その後、利用者に完了通知を行う（ステップＳ５３６）。

【0332】

また、図２５は、入場申請時の処理の流れの一例を示すシーケンス図である。図２５に示す例では、まず利用者が、個人用端末１０Ａに対して入場申請の指示を行う（ステップＳ５４１）。このとき、入場申請を行う発券チケット情報としてのサービスＩＤが指定されてもよい。

【0333】

入場申請の指示を受け付けると、個人用端末１０Ａは、入場装置２２Ａに、個人ＩＤ１３ＤとサービスＩＤとを含む入場申請を送信する（ステップＳ５４２）。これは、実際に会場に設置された入場装置２２Ａが備えるリーダー装置へのタッチによる情報通信により行われてもよい。

【0334】

個人用端末１０Ａからの購入申請を受けた入場装置２２Ａは、サービス提供装置２１Ａに個人ＩＤ１３ＤとサービスＩＤとを含むサービスＩＤ妥当性確認を送信する（ステップＳ５４３）。なお、サービスＩＤ妥当性確認にはさらに開催されているイベントや会場に関する情報が含まれていてもよい。

【0335】

入場装置２２ＡからのサービスＩＤ妥当性確認を受けたサービス提供装置２１Ａは、そのサービスＩＤの妥当性を確認する（ステップＳ５４４）。サービス提供装置２１Ａは、受信したサービスＩＤに対して、その入場装置２２Ａが設置されたイベントに対するチケットの発行にかかる情報が登録されているかを確認すればよい。

【0336】

そして、サービス提供装置２１Ａは、自身が保持している該サービスＩＤに対応づけられている発行記録ＴｘＩＤを基に、発行記録を登録した確認記録ブロックを取得し、その登録情報の信頼性を確認した上で、発行記録の正当性を確認する（ステップＳ５４５〜ステップＳ５４６）。サービス提供装置２１Ａは、確認記録ブロック内の発行記録の正当性まで確認されると、サービスＩＤ妥当性結果（ＯＫ）を入場装置２２Ａに返信する（ステップＳ５４７）。サービス提供装置２１Ａは、発行記録の正当性を確認できなければ、サービスＩＤ妥当性結果（ＮＧ）を入場装置２２Ａに返信する。

【0337】

サービスＩＤ妥当性結果を受信した入場装置２２Ａは、サービスＩＤ妥当性結果がＮＧであれば、個人用端末１０Ａに入場不可を返信する（ステップＳ５４８）。このとき、入場装置２２Ａは、サービスＩＤが不正である旨を併せて送信してもよい。入場不可を受信した個人用端末１０Ａは利用者に不可通知をして処理を終了する（ステップＳ５４９）。

【0338】

一方、入場装置２２Ａは、サービスＩＤ妥当性結果がＯＫであれば、生体認証要求Ｄを個人用端末１０Ａに送信する（ステップＳ５５０）。なお、以下に示す例は、個人用端末１０Ａ側でブロックチェーン３内の生体認証を利用して本人確認を行う例であるが、同様の処理を入場装置２２Ａ等で行ってもよい。

【0339】

生体認証要求Ｄを受信した個人用端末１０Ａは、自身が保持している登録履歴を検索して本人登録の際に登録した登録ブロックのＴｘＩＤを取得し（ステップＳ５５１）、その登録情報（特に、生体情報のハッシュ値である個人情報Ｈａｓｈ３２Ｄ（３））を取得する。

【0340】

そして、個人用端末１０Ａは、取得した登録情報の信頼性確認（ステップＳ５５２）、および自身で保持している登録時の個人情報と登録情報の元データとの一致性確認により（ステップＳ５５３）、自身が保持している個人情報１４Ｄ（３）がブロックチェーン３に登録した時の生体情報であることを確認する。なお、この確認は、ブロックチェーンＮＷ３０Ａに、登録ブロックのＴｘＩＤを参照ＴｘＩＤとして指定し、確認対象とする登録した時の生体情報から算出したハッシュ値を比較元として指定した登録情報参照要求を送信することで行うことも可能である。

【0341】

このようにして自身が保持している個人情報１４Ｄ（３）の正当性（本人登録認証）が確認されると、個人用端末１０Ａは、さらに現在（入場申請時）の利用者の生体情報を取得し、両者の同一性を確認する（ステップＳ５５４）。なお、個人用端末１０Ａは、両者をハッシュ値の形式で照合してもよい。そして、個人用端末１０Ａは、ステップＳ５５４の結果を生体認証結果として入場装置２２Ａに返信する（ステップＳ５５５）。

【0342】

生体認証結果を受信した入場装置２２Ａは、生体認証結果ＮＧであれば、個人用端末１０Ａに入場不可を返信する（ステップＳ５５６）。このとき、入場装置２２Ａは、生体認証エラーである旨を併せて送信してもよい。入場不可を受信した個人用端末１０Ａは利用者に不可通知をして処理を終了する（ステップＳ５５７）。

【0343】

一方、入場装置２２Ａは、生体認証結果ＯＫであれば、今回の認証記録を確認記録ブロックにしてブロックチェーン３に追加した後（ステップＳ５５８、ステップＳ５５９）、個人用端末１０Ａに入場許可を返信する（ステップＳ５６０）。入場許可を受信した個人用端末１０Ａは利用者に許可通知をして処理を終了する（ステップＳ５６１）。

【0344】

以上のように、本実施形態によれば、漏れなく、確実かつ素早く、本人確認を含むチケットサービスを実現できる。また、本人確認のために人員の現場におかなくてもよいため、コスト削減にもつながる。

【0345】

なお、本実施形態では、チケットの販売から入場判定までの一連のチケットサービスに、１つの個人ＩＤに対応づけられたブロックチェーン３内の情報を利用して本人確認を含む対象確認を行う個人情報管理システムを適用した例を示したが、ＳＮＳプラットフォームを利用してサービスを提供したい場合は、サービス提供時に第１の実施形態のサービス提供システムにおいて説明したようなＩＤの受け渡し方法を利用することにより、ＳＮＳとＩＭＳとの間でＩＤを連携させることができる。

【0346】

図２６は、本実施形態のチケットサービスシステムの他の構成例を示すブロック図である。図２６に示すチケットサービスシステムは、個人用端末１０Ｂと、サービス提供装置２１Ｂと、入場装置２２Ｂと、ブロックチェーンＮＷ３０Ｂとを備える。

【0347】

個人用端末１０Ｂは、ＳＮＳアプリケーション部７１１Ｂと、ＩＭＳアプリケーション部７１２Ｂとを含む。

【0348】

サービス提供装置２１Ｂは、ＳＮＳ側サービス提供部７２１Ｂと、第１の対象確認サービス部７２２Ｂとを含む。

【0349】

入場装置２２Ｂは、第２の対象確認サービス部７３１Ｂと、判定部７３２Ｂとを含む。

【0350】

ＳＮＳアプリケーション部７１１Ｂは、第１の実施形態のＳＮＳＡＰＰ部６１１が行う処理、および第３の実施形態の個人用端末１０Ａで行っていたサービス提供にかかる処理（確認部２０２が行う処理に相当する対象確認および記録登録にかかる処理以外の処理）を行う。ＳＮＳアプリケーション部７１１Ｂは、具体的には、個人用端末１０Ｂのユーザであって本システムの利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供する。

【0351】

ＩＭＳアプリケーション部７１２Ｂは、第１の実施形態のＩＭＳＡＰＰ部６１２が行う相当する処理、および第３の実施形態の個人用端末１０Ａで行っていた対象確認および記録登録にかかる処理を行う。ＩＭＳアプリケーション部７１２Ｂは、具体的には、個人用端末１０Ｂのユーザであって本システムの利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供する。

【0352】

ＳＮＳ側サービス提供部７２１Ｂは、第３の実施形態のサービス提供装置２１Ａで行っていたサービス提供にかかる処理のうち、対象確認以外の処理を行う。なお、本例のＳＮＳ側サービス提供部７２１Ｂは、ＳＮＳ上でチケットサービスを提供する。ＳＮＳ側サービス提供部７２１Ｂは、具体的には、ＳＮＳのプラットフォームを利用したＳＮＳアプリケーション部７１１Ｂとの情報のやりとりにより、利用者に、サービスを提供する。

【0353】

第１の対象確認サービス部７２２Ｂは、第３の実施形態のサービス提供装置２１Ａで行っていたサービス提供にかかる処理のうち、対象確認にかかる処理を行う。第１の対象確認サービス部７２２Ｂは、具体的には、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部７１２Ｂとの情報のやりとりにより、利用者の対象確認を行う。

【0354】

第２の対象確認サービス部７３１Ｂは、第３の実施形態の入場装置２２Ａで行っていたサービス提供にかかる処理のうち、対象確認にかかる処理を行う。第２の対象確認サービス部７３１Ｂは、具体的には、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部７１２Ｂとの情報のやりとりにより、利用者の対象確認を行う。

【0355】

判定部７３２Ｂは、第３の実施形態の入場装置２２Ａで行っていたサービス提供にかかる処理のうち、対象確認以外の処理を行う。判定部７３２Ｂは、例えば、第２の対象確認サービス部７３１Ｂによる対象確認の結果に基づいて、利用者の入場の可否を判定する。

【0356】

このような構成において、ＩＭＳアプリケーション部７１２Ｂは、少なくとも第１の対象確認サービス部７２２Ｂに、所定の方法で、ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、ＳＮＳ側サービス提供部７２１ＢがＳＮＳのプラットフォーム上で利用者を特定可能な情報であるＳＮＳ＿ＩＤを、利用者の対象確認の結果を特定可能な情報とともに送信してもよい。

【0357】

また、第１の対象確認サービス部７２２Ｂは、ＩＭＳアプリケーション部７１２Ｂから受信したＳＮＳ_ＩＤＢと、該ＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部７２１Ｂに通知してもよい。

【0358】

また、ＳＮＳ側サービス提供部７２１Ｂは、第１の対象確認サービス部７２２Ｂから通知された利用者の対象確認の結果を基に利用者にチケット購入サービスを提供してもよい。

【0359】

なお、本例においてＩＭＳは、２以上のノード３０１Ｂと、登録部１０２Ｂと、開示部１０３Ｂと、対象確認部２０２１Ｂと、記録登録部２０２２Ｂとを備えている。

【0360】

ノード３０１Ｂは、台帳管理ノード３０１に相当し、２以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加されるブロックチェーン（より具体的には、ブロックチェーンＮＷ３０Ｂ）を構成する。

【0361】

登録部１０２Ｂは、ブロックチェーンに、利用者から開示された個人情報であって、本人確認、ユーザ認証または適格性確認のいずれかである所定の対象確認に必要な個人情報である対象確認情報のハッシュ値を含む第１ブロックを登録する。

【0362】

開示部１０３Ｂは、個人情報の開示要求を受信すると、要求された種別の個人情報を所定の記憶部（図示省略）から読み出し、要求元に送信する。または、要求された種別の個人情報に代えて、該個人情報を用いて行われた過去の対象確認の記録を含む第２ブロックを特定可能な情報を送信してもよい。

【0363】

対象確認部２０２１Ｂは、利用者から開示された対象確認情報の正当性をブロックチェーン内のブロックを用いて検証した上で、開示された対象確認情報に基づいて対象確認を行う。

【0364】

記録登録部２０２２Ｂは、ブロックチェーンに、対象確認もしくはサービスの提供の記録を含む第２ブロックを登録する。

【0365】

なお、本例では、ＩＭＳアプリケーション部７１２Ｂが、ＩＭＳの一部として登録部１０２Ｂを有し、第１の対象確認サービス部７２２Ｂおよび第２の対象確認サービス部７３１Ｂがそれぞれ、ＩＭＳの一部として対象確認部２０２１Ｂおよび記録登録部２０２２Ｂを有しているものとする。

【0366】

そのような構成において、ＩＭＳアプリケーション部７１２Ｂは、登録部１０２Ｂを介して、ブロックチェーンに、利用者の識別子と、利用者から開示された生体情報である第１の対象確認情報のハッシュ値と、利用者から開示された所定の個人情報である第２の対象確認情報のハッシュ値とを含む第１ブロックを登録してもよい。

【0367】

また、第１の対象確認サービス部７２２Ｂは、対象確認部２０２１Ｂを介して、利用者に第２の対象確認情報の開示を要求して、得られた情報を基に対象確認を行ってもよい。

【0368】

また、第２の対象確認サービス部７３１Ｂは、利用者から入場申請を受け付けると、対象確認部２０２１Ｂを介して、利用者に、第２ブロックを特定可能な情報と、第１ブロック登録時の第１の対象確認情報と、現在の第１の対象確認情報の開示を要求し、開示された情報に基づいて、本人確認を含む所定の適格性確認を行ってもよい。

【0369】

また、第１の対象確認サービス部７２２Ｂおよび第２の対象確認サービス部７３１Ｂは、対象確認や何らかのサービスを提供した場合、記録登録部２０２２Ｂを介して、ブロックチェーンに、対象確認もしくはサービスの提供の記録を含む第２ブロックを登録してもよい。

【0370】

このような構成によれば、必要最小限の個人情報の開示だけで、ＳＮＳ上で、対象確認を伴うチケットサービスの提供を行うことができる。なお、他の点に関しては、第１の実施形態のサービス提供システムおよび第３の実施形態のチケットサービスシステムと同様である。

【0371】

また、適用先のサービスはチケットサービスに限定されない。

【0372】

例えば、スマートキーを利用して施錠／開錠を行う施設や部屋の予約、スマートキーの発行および入出場管理を行う施設管理サービスや、生体情報が登録されたウェアラブルデバイスや携帯端末などを用いた投票サービスや、生体情報が登録されたウェアラブルデバイスや携帯端末などを用いた改札での定期券運賃管理サービスなども考えられる。

【0373】

上記の施設管理サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、本サービスにおいて必要とされる個人情報と併せて本人確認用の生体情報のハッシュ値を、個人ＩＤとともにブロックチェーンに登録（本人登録）する。
・予約時、本人確認の上で電子鍵を発行して、その記録をブロックチェーンに登録する。
・チェックイン時、本人確認の上で発行した電子鍵を有効にし、その記録をブロックチェーンに登録する。
・電子による開錠／施錠時、施錠装置等を介してその記録をブロックチェーンに登録する。
・チェックアウト時、発行した電子鍵を無効にし、ブロックチェーン上の記録を基に清算を行う。

【0374】

上記の投票サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、本サービスにおいて必要とされる個人情報と併せて本人確認用の生体情報のハッシュ値を、個人ＩＤとともにブロックチェーンに登録（本人登録）する。
・電子投票権申請時、本人確認と電子投票権発行に必要な情報の確認の上、電子投票権を発行して、発行記録をブロックチェーンに登録する。
・投票時、投票を受け付けた投票装置が、本人確認と発行記録を確認した上で、投票を受け付ける。また、投票内容（暗号化）を含む投票記録をブロックチェーンに登録する。
・開票時、開票装置が、ブロックチェーン上の投票記録を基に開票を行う。

【0375】

上記の定期券運賃管理サービスへの個人情報管理システムの適用方法としては、例えば次のようなものが挙げられる。
・利用開始時、利用者が所持しているウェアラブルデバイスや携帯端末に、生体情報を登録する。
・定期券申請時、生体情報を登録したデバイスＩＤと定期券発行情報とを含む発行記録をブロックチェーンに登録する。このとき、デバイスＩＤを個人ＩＤとみなしてもよいし、別に割り当ててもよい。
・改札通過（乗車）時、生体認証済みのウェアラブルデバイスや携帯端末から取得されるデバイスＩＤや定期券発行時に通知した個人ＩＤを基に、ブロックチェーン上の発行記録や直前の記録を確認して、入場可否を判定する。また、入場記録をブロックチェーンに登録する。
・改札通過（下車）時、生体認証済みのウェアラブルデバイスや携帯端末から取得されるデバイスＩＤや定期券発行時に通知した個人ＩＤを基に、ブロックチェーン上の発行記録や直前の記録を確認して、出場可否を判定する。また、出場記録をブロックチェーンに登録する。

【0376】

なお、上記に示す例では、入場装置が、利用者から入場の申請を受け付けて、対象確認の結果に基づいて、利用者の申請の可否を判定する例を示したが、該入場装置を、サービス提供装置で発行された当該サービスの受給資格を示す許可証が使用される場所に設置される許可証判定装置に置き換えることも可能である。そのような場合、図２６に示すように、許可証判定装置において、第２の対象確認サービス部が、利用者から入場の申請または許可証により得られる利益の受領の申請を受け付け、判定部が、第２の対象確認部による対象確認の結果に基づいて、利用者の申請の可否を判定してもよい。ここで、許可証は、電子チケット、電子キー、電子投票券、定期券であってもよい。

【0377】

また、図２７は、本発明の各実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５と、入力デバイス１００６とを備える。

【0378】

上述の各実施形態のシステムが備えるサーバその他の装置等は、コンピュータ１０００に実装されてもよい。その場合、各装置の動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って各実施形態における所定の処理を実施する。なお、ＣＰＵ１００１は、プログラムに従って動作する情報処理装置の一例であり、ＣＰＵ（Central Processing Unit）以外にも、例えば、ＭＰＵ（Micro Processing Unit）やＭＣＵ（Memory Control Unit）やＧＰＵ（Graphics Processing Unit）などを備えていてもよい。

【0379】

補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、各実施形態における所定の処理を実行してもよい。

【0380】

また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで各実施形態における所定の処理を実現する差分プログラムであってもよい。

【0381】

インタフェース１００４は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置１００５は、ユーザに情報を提示する。また、入力デバイス１００６は、ユーザからの情報の入力を受け付ける。

【0382】

また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、コンピュータ１０００がユーザに情報を提示しないのであれば、ディスプレイ装置１００５は省略可能である。例えば、コンピュータ１０００がユーザから情報入力を受け付けないのであれば、入力デバイス１００６は省略可能である。

【0383】

また、上記の各実施形態の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、上記の各実施形態各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

【0384】

上記の各実施形態の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

【0385】

次に、本発明の概要を説明する。図２８は、本発明のサービス提供システムの概要を示すブロック図である。図２８に示すように、本発明のサービス提供システムは、個人用端末７１と、サービスサーバ７２とを備える。

【0386】

個人用端末７１は、ＳＮＳアプリケーション部７１１と、ＩＭＳアプリケーション部７１２とを含む。また、サービスサーバ７２は、ＳＮＳ側サービス提供部７２１と、対象確認サービス部７２２とを含む。

【0387】

ＳＮＳアプリケーション部７１１（例えば、ＳＮＳＡＰＰ部６１１）は、利用者が所定のＳＮＳを利用するための各種処理およびインタフェースを提供する。

【0388】

ＩＭＳアプリケーション部７１２（例えば、ＩＭＳＡＰＰ部６１２）は、利用者が所定のＩＭＳを利用するための各種処理およびインタフェースを提供する。

【0389】

ＳＮＳ側サービス提供部７２１（例えば、ＳＮＳ側サービス提供部６４１）は、ＳＮＳのプラットフォームを利用したＳＮＳアプリケーション部７１１との情報のやりとりにより、利用者に、サービスを提供する。

【0390】

対象確認サービス部７２２（例えば、対象確認サービス部６４２）は、ＩＭＳのプラットフォームを利用したＩＭＳアプリケーション部７１２との情報のやりとりにより、利用者の対象確認を行う。

【0391】

このような構成において、ＩＭＳアプリケーション部７１２は、対象確認サービス部７２２に、所定の方法で、ＳＮＳのプラットフォームより提供される機能を少なくとも利用して取得した、ＳＮＳ側サービス提供部７２１がＳＮＳのプラットフォーム上で利用者を特定可能な情報であるＳＮＳ＿ＩＤを、利用者の対象確認の結果を特定可能な情報とともに送信する。そして、対象確認サービス部７２２は、ＩＭＳアプリケーション部７１２から受信したＳＮＳ_ＩＤと、該ＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部７２１に通知する。

【0392】

これにより、必要最小限の個人情報の開示だけで、ＳＮＳ上で、対象確認を伴うサービスの提供を行うことができる。

【0393】

以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

【産業上の利用可能性】

【0394】

本発明によれば、本人確認、ユーザ認証または適格性確認のいずれかを行った上で利用者にサービスを提供するものであれば、好適に適用できる。

【符号の説明】

【0395】

６００ サービス提供システム
６１ 個人用端末
６１１ ＳＮＳＡＰＰ部
６１２ ＩＭＳＡＰＰ部
６２ ＳＮＳプラットフォーム
６３ ＩＭＳプラットフォーム
６４ サービスサーバ
６４１ ＳＮＳ側サービス提供部
６４２ 対象確認サービス部
６４３ ＩＤ連携情報記憶部
１ クライアントデバイス
２ 確認機関デバイス
３ ブロックチェーン
４ ネットワーク
１１Ｄ、２１Ｄ 秘密鍵
１２Ｄ、２２Ｄ 公開鍵
１３Ｄ 個人ＩＤ
１４Ｄ 個人情報
３１Ｄ 個人ＩＤ＿Ｈａｓｈ
３２Ｄ 個人情報Ｈａｓｈ
３３Ｄ 本人の署名
３４Ｄ 確認情報
３５Ｄ 確認機関の署名
１００ 個人情報管理システム
１０ 利用者側システム
１０１ データ記憶部
１０２ 登録部
１０３ 開示部
１０４ 認証部
２０ 確認機関側システム
２０１ データ記憶部
２０２ 確認部
２２１ データ取得部
２２２ 登録情報信頼性確認部
２２３ 元データ一致性確認部
２２４ 個人情報正当性確認部
２２５ 結果出力部
２２６ 確認記録登録部
３０ 台帳管理システム
３０１ 台帳管理ノード
３１１ 登録情報受付部
３１２ ブロック生成部
３１３ ブロック共有部
３１４ 情報記憶部
３１５ ブロック検証部
４０ ネットワーク
５０ 管理側システム
５０１ データ記憶部
５０２ 個人ＩＤ割当部
１０Ａ、１０Ｂ 個人用端末
２１Ａ、２１Ｂ サービス提供装置
２２Ａ、２２Ｂ 入場装置
３０Ａ、３０Ｂ ブロックチェーンＮＷ
７１１Ｂ ＳＮＳアプリケーション部
７１２Ｂ ＩＭＳアプリケーション部
７２１Ｂ ＳＮＳ側サービス提供部
７２２Ｂ 第１の対象確認サービス部
７３１Ｂ 第２の対象確認サービス部
７３２Ｂ 判定部
１０２Ｂ 登録部
１０３Ｂ 開示部
２０２１Ｂ 対象確認部
２０２２Ｂ 記録登録部
３０１Ｂ ノード
１０００ コンピュータ
１００１ ＣＰＵ
１００２ 主記憶装置
１００３ 補助記憶装置
１００４ インタフェース
１００５ ディスプレイ装置
１００６ 入力デバイス
７１ 個人用端末
７１１ ＳＮＳアプリケーション部
７１２ ＩＭＳアプリケーション部
７２ サービスサーバ
７２１ ＳＮＳ側サービス提供部
７２２ 対象確認サービス部

【要約】

【課題】 必要最小限の個人情報の開示だけで、ＳＮＳ上で対象確認を伴うサービスの提供を可能にする。
【解決手段】 サービス提供システムは、ＳＮＳアプリケーション部７１１とＩＭＳアプリケーション部７１２とを含む個人用端末７１と、ＳＮＳのプラットフォームを利用して利用者にサービスを提供するＳＮＳ側サービス提供部７２１と、ＩＭＳのプラットフォームを利用して利用者の対象確認を行う対象確認サービス部７２２とを含むサービスサーバ７２とを備え、ＩＭＳアプリケーション部７１２は、対象確認サービス部７２２にＳＮＳのプラットフォームより提供される機能を利用して取得したＳＮＳ＿ＩＤとその利用者の対象確認の結果を特定可能な情報とを送信し、対象確認サービス部７２２は、受信したＳＮＳ_ＩＤとＳＮＳ_ＩＤにより特定された利用者の対象確認の結果とを対応づけてＳＮＳ側サービス提供部７２１に通知する。
【選択図】図２８

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】