特許 7601264 システム、サーバ装置、サーバ装置の制御方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-12-09

(45)【発行日】2024-12-17

(54)【発明の名称】システム、サーバ装置、サーバ装置の制御方法及びプログラム

(51)【国際特許分類】

   G06F 21/45 20130101AFI20241210BHJP

   G06F 21/32 20130101ALI20241210BHJP

   G06F 21/31 20130101ALI20241210BHJP

   G06F 21/62 20130101ALI20241210BHJP

   G06Q 50/10 20120101ALI20241210BHJP

【ＦＩ】

G06F21/45

G06F21/32

G06F21/31

G06F21/62 345

G06Q50/10

【請求項の数】 10

(21)【出願番号】P 2023572316

(86)(22)【出願日】2022-01-07

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

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

(87)【国際公開日】2023-07-13

【審査請求日】2024-05-24

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100168310

【弁理士】

【氏名又は名称】▲高▼橋 幹夫

(72)【発明者】

【氏名】佐藤 雄亮

【審査官】宮司 卓佳

(56)【参考文献】

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

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

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

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

Ｇ０６Ｆ ２１／３１－２１／４６

Ｇ０６Ｆ ２１／６０－２１／６２

Ｇ０６Ｑ ５０／１０

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

【請求項1】

第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、第１のサーバ装置と、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、第２のサーバ装置と、
を含み、
前記第２のサーバ装置は、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、システム。

【請求項2】

前記利用者による前記第２のアカウントへのログイン要求を受け付け、前記利用者の認証を前記第２のサーバ装置に要求する、第３のサーバ装置をさらに含み、
前記第２のサーバ装置は、前記利用者について多要素認証を実行し、前記多要素認証の結果を前記第３のサーバ装置に通知する、請求項１に記載のシステム。

【請求項3】

前記第２のサーバ装置は、前記第２のアカウントにログインする前記利用者を認証するための生体情報を少なくとも記憶する、請求項２に記載のシステム。

【請求項4】

前記第３のサーバ装置は、前記利用者から前記第１のＩＤに関するＩＤ連携の手続きを受け付けると、前記第２のサーバ装置に連携コードの発行を要求し、
前記第２のサーバ装置は、前記利用者の前記第２のアカウントと紐付いた前記連携コードを生成し、前記生成された連携コードを前記第３のサーバ装置に送信し、
前記第３のサーバ装置は、前記送信された連携コードを前記利用者に通知する、請求項３に記載のシステム。

【請求項5】

前記第１のサーバ装置は、前記ＩＤ連携を希望する利用者から前記連携コードを取得し、前記第１のＩＤと前記取得した連携コードを含むＩＤ連携要求を前記第２のサーバ装置に送信し、
前記第２のサーバ装置は、
前記ＩＤ連携要求に含まれる連携コードから前記ＩＤ連携を希望する利用者を特定すると共に、前記特定された利用者に対して生体情報の提供を要求し、
前記要求に応じて取得した生体情報と前記第２のアカウントに記憶された生体情報を用いた生体認証を行い、前記生体認証に成功した場合に、前記第１のＩＤと前記第２のＩＤを対応付ける、請求項４に記載のシステム。

【請求項6】

前記利用者に第２のサービスを提供するために必要な第３のＩＤと前記利用者に提供される前記第２のサービスに関するデータを蓄積する、第４のサーバ装置と、
前記第２のサービスを提供するサービス事業者の職員が使用し、前記第３のＩＤと前記利用者の本人確認情報を対応付けて記憶する、端末と、
をさらに含み、
前記端末は、前記職員の操作に応じて、前記第２のＩＤと前記第３のＩＤの連携に関する処理を実行する、請求項２に記載のシステム。

【請求項7】

前記第３のサーバ装置は、前記利用者から前記第３のＩＤに関するＩＤ連携の手続きを受け付けると、前記第２のサーバ装置に対して前記ＩＤ連携を希望する利用者の本人確認情報の送信を依頼し、
前記第２のサーバ装置は、前記依頼に応じて、前記ＩＤ連携を希望する利用者の本人確認情報と生体情報を前記第４のサーバ装置に送信し、
前記端末は、前記ＩＤ連携を希望する利用者の生体情報を含む照合要求を前記第４のサーバ装置に送信し、
前記第４のサーバ装置は、前記端末から取得した生体情報と前記第２のサーバ装置から取得した生体情報を用いて前記ＩＤ連携を希望する利用者を特定し、前記特定された利用者の本人確認情報を前記端末に送信し、
前記端末は、前記第４のサーバ装置から取得した本人確認情報に対応する前記第３のＩＤを含むＩＤ連携要求を前記第２のサーバ装置に送信する、請求項６に記載のシステム。

【請求項8】

第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、通信制御部と、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、データ流通制御部と、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける、ＩＤ連携管理部と、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、ログイン管理部と、
を備える、サーバ装置。

【請求項9】

第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置において、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御し、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付け、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、サーバ装置の制御方法。

【請求項10】

第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置に搭載されたコンピュータに、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する処理と、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける処理と、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する処理と、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、システム、サーバ装置、サーバ装置の制御方法及び記憶媒体に関する。

【背景技術】

【0002】

病院などに保有されている個人情報を、個人の同意に基づき事業者などの情報提供先の装置に提供する情報流通システムが存在する。このようなシステムには、例えば、情報銀行などが管理する情報取引装置、情報提供元の企業が管理する情報提供元装置、情報提供先が管理する情報提供先装置等が含まれる。情報取引装置は、情報提供元装置から取得した個人情報を記憶する。情報取引装置は、記憶した個人情報のなかから活用事業者等が希望する個人情報を情報提供先装置へ送信する。

【0003】

例えば、特許文献１には、ユーザの個人情報を用いて取引を行なうための情報管理システム、情報管理方法及び情報管理プログラムを提供する、と記載されている。特許文献１の情報管理サーバは、登録者の個人情報を記憶する登録者情報記憶部と、個人情報の提供履歴を記憶する提供履歴記憶部と、購入者端末に接続される制御部と、を備える。制御部は、購入者端末から、情報取得条件を取得し、情報取得条件に基づいて、登録者情報記憶部から個人情報を抽出する。制御部は、購入者端末に対して、抽出した個人情報を提供し、個人情報の提供履歴を提供履歴記憶部に記録する。制御部は、提供履歴記憶部に記録された提供履歴に基づいて、提供代金を回収するとともに、提供代金に基づいて、個人情報を提供した登録者に対して対価を還元する。

【0004】

また、利用者の認証に関する種々の技術開発が進められている。

【0005】

例えば、特許文献２には、よりセキュリティ性の高いＩＣタグを用いた認証技術を提供する、と記載されている。特許文献２の認証システムは、少なくとも１つの情報端末と、少なくとも１つのサーバとを備える。認証システムは、読取部と、取得部と、復号部と、検証部と、第１認証部と、確認部と、を備える。読取部は、１以上のＰＩＮを用いて、ＩＣカードの正当な所有者の顔画像を含む個人情報と、個人情報と秘密鍵とを基に生成された電子署名とを含むＩＣカードから、個人情報および電子署名を読み取る。取得部は、対象者の顔が写る撮像データを取得する。復号部は、秘密鍵に対応する公開鍵を用いて電子署名を復号する。検証部は、復号された電子署名と個人情報とを基に、個人情報の正当性を検証する。第１認証部は、撮像データと、個人情報に含まれる顔画像とを用いた顔認証を行う。確認部は、個人情報の正当性の検証結果と顔認証の結果とに基づいて、対象者の本人確認を行う。

【0006】

特許文献３には、サービスに応じた認証方式の組み合わせを適切に決定できる認証システム、認証サーバ、事業者サーバ及び利用者端末を提供する、と記載されている。特許文献３の利用者端末は、サービスの要求を行う認証要求部と、認証方式それぞれに対する認証情報を送信する認証情報送信部と、を備える。事業者サーバは、サービスが必要とする認証の安全性を示すサービスポイントを管理するサービスポイント管理部を備える。認証サーバは、認証ポイント管理部と、認証方式決定部と、認証処理部と、を備える。認証ポイント管理部は、認証方式の組み合わせにより得られる安全性を示す認証ポイントを管理する。認証方式決定部は、認証ポイントがサービスポイント以上である認証方式の組み合わせのうち、認証ポイント及びサービスポイントの差分が小さい組み合わせを優先して決定する。認証処理部は、決定された認証方式の組み合わせそれぞれに対して、認証情報を受信し、認証処理を行う。

【0007】

特許文献４には、方式の異なるユーザ管理システム間で同一の利用者を特定可能なネットワークシステムを提供する、と記載されている。特許文献４のネットワークシステムは、第１及び第２のユーザ管理システムと、ゲートウェイサーバと、を備える。第１のユーザ管理システムは、ＩＤ情報を第１のＩＤ連携情報テーブルで管理する。第２のユーザ管理システムは、第１及び第２の仲介用ＩＤ情報を第２のＩＤ連携情報テーブルで管理する。ゲートウェイサーバは、ＩＤ情報と、第２の仲介用ＩＤ情報とを対応付けて第３のＩＤ連携情報テーブルで管理する。ゲートウェイサーバは、一方のユーザ管理システムを介して他方のユーザ管理システムにログイン要求がある場合、第３のＩＤ連携情報テーブルから、通知されたＩＤ情報又は第２の仲介用ＩＤ情報と対応する第２の仲介用ＩＤ情報又はＩＤ情報を検出する。ゲートウェイサーバは、検出した情報を他方のユーザ管理システムへ出力する。

【先行技術文献】

【特許文献】

【0008】

【文献】特開２０１９－１２８６４８号公報

【文献】特開２０１９－０５００１４号公報

【文献】特開２０１７－０７２９７９号公報

【文献】特開２０１３－１１４６２２号公報

【発明の概要】

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

【0009】

情報流通システムでは、各サービス提供組織（サービス事業者、データホルダー）が保持する個人のデータを集めて高度なサービスを提供できる。その際、サービス提供組織から提供されるデータは、ある一定以上の信頼性を備えていることが必要である。信頼性の低いデータ（セキュリティレベル、本人確認性が低いサービス提供組織から提供されるデータ）を使用すると、情報流通システムから提供されるサービス全体の品質が低下するためである。

【0010】

なお、当該問題は、上記特許文献１乃至特許文献４に開示された技術を適用しても解決できない。とりわけ、特許文献３乃至特許文献４には、利用者の認証や特定に関する技術が開示されているに過ぎないためである。

【0011】

本発明は、情報流通システムから提供されるサービスの品質を維持、向上することに寄与する、システム、サーバ装置、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。

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

【0012】

本発明の第１の視点によれば、第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、第１のサーバ装置と、第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、第２のサーバ装置と、を含み、前記第２のサーバ装置は、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、システムが提供される。

【0013】

本発明の第２の視点によれば、第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、通信制御部と、第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、データ流通制御部と、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける、ＩＤ連携管理部と、前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、ログイン管理部と、を備える、サーバ装置が提供される。

【0014】

本発明の第３の視点によれば、第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置において、第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御し、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付け、前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、サーバ装置の制御方法が提供される。

【0015】

本発明の第４の視点によれば、第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置に搭載されたコンピュータに、第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する処理と、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける処理と、前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

【発明の効果】

【0016】

本発明の各視点によれば、情報流通システムから提供されるサービスの品質を維持、向上することに寄与する、システム、サーバ装置、サーバ装置の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

【図面の簡単な説明】

【0017】

【図1】図１は、一実施形態の概要を説明するための図である。

【図2】図２は、一実施形態の動作の一例を示すフローチャートである。

【図3】図３は、第１の実施形態に係る情報流通システムの概略構成の一例を示す図である。

【図4】図４は、第１の実施形態に係る情報流通システムの動作を説明するための図である。

【図5】図５は、第１の実施形態に係る情報流通システムの動作を説明するための図である。

【図6】図６は、第１の実施形態に係る情報流通システムの動作を説明するための図である。

【図7】図７は、第１の実施形態に係る情報流通システムの動作を説明するための図である。

【図8】図８は、第１の実施形態に係る情報流通システムの動作を説明するための図である。

【図9】図９は、第１の実施形態に係るポータルサーバの処理構成の一例を示す図である。

【図10】図１０は、第１の実施形態に係る端末の表示の一例を示す図である。

【図11】図１１は、第１の実施形態に係る端末の表示の一例を示す図である。

【図12】図１２は、第１の実施形態に係る端末の表示の一例を示す図である。

【図13】図１３は、第１の実施形態に係る流通制御サーバの処理構成の一例を示す図である。

【図14】図１４は、第１の実施形態に係る利用者情報データベースの一例を示す図である。

【図15】図１５は、第１の実施形態に係る利用者情報データベースの一部の一例を示す図である。

【図16】図１６は、第１の実施形態に係るＩＤ連携管理部の動作の一例を示すフローチャートである。

【図17】図１７は、第１の実施形態に係るＩＤ連携管理部の動作の一例を示すフローチャートである。

【図18】図１８は、第１の実施形態に係る所在情報データベースの一例を示す図である。

【図19】図１９は、第１の実施形態に係るサービスサーバの処理構成の一例を示す図である。

【図20】図２０は、第１の実施形態に係る端末の表示の一例を示す図である。

【図21】図２１は、第１の実施形態に係る顧客情報データベースの一例を示す図である。

【図22】図２２は、第１の実施形態に係る情報流通システムの動作の一例を示すシーケンス図である。

【図23】図２３は、第１の実施形態に係るＩＤ連携を説明するための図である。

【図24】図２４は、第２の実施形態に係る情報流通システムの概略構成の一例を示す図である。

【図25】図２５は、第２の実施形態に係る病院端末の処理構成の一例を示す図である。

【図26】図２６は、第２の実施形態に係るサービスサーバの処理構成の一例を示す図である。

【図27】図２７は、第２の実施形態に係る情報流通システムの動作を説明するための図である。

【図28】図２８は、第２の実施形態に係る情報流通システムの動作を説明するための図である。

【図29】図２９Ａ及び図２９Ｂは、第２の実施形態に係る病院端末の表示の一例を示す図である。

【図30】図３０は、本願開示に係る流通制御サーバのハードウェア構成の一例を示す図である。

【図31】図３１は、本願開示の変形例に係る情報流通システムの概略構成の一例を示す図である。

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

【0018】

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

【0019】

一実施形態に係るシステムは、第１のサーバ装置１０１と、第２のサーバ装置１０２と、を含む（図１参照）。第１のサーバ装置１０１は、第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、利用者に提供される第１のサービスに関するデータを蓄積する。第２のサーバ装置１０２は、第２のアカウントにログインした利用者について、蓄積されたデータのデータ流通を制御する。第２のサーバ装置１０２は、第１のアカウントで管理される第１のＩＤと第２のアカウントで管理される第２のＩＤを対応付ける（ＩＤを対応付ける；図２のステップＳ１）。その後、第２のサーバ装置１０２は、利用者が第１のアカウントにログインする際、第２のアカウントにログインする手続きと同じ手続きを利用者に要求する（ログイン手続きの要求；ステップＳ２）。

【0020】

第１のサーバ装置１０１の第１のアカウントにログインする際の手続きや方式が、セキュリティレベル（認証強度）や本人確認性レベルの低い可能性がある。そのような場合であっても、第２のサーバ装置１０２は、当該第１のアカウントの第１のＩＤがシステムに登録（第２のＩＤと対応付け）された後は、第２のアカウントにログインする際の手続きと同じ手続きを利用者に要求する。即ち、第２のアカウントにログインする際に、ＩＤ認証、生体認証等を組み合わせた多要素認証が必要であれば、第２のサーバ装置１０２は、第１のアカウントへログインする際にも多要素認証を実行する。即ち、利用者を認証する際のセキュリティレベル等が低い方式を採用するサービス事業者がシステムに含まれていても、当該サービス事業者に代わり、システム（第２のサーバ装置１０２）が、セキュリティレベル等が高い方式によって利用者を認証する。その結果、上記セキュリティレベル等の低いサービス事業者がサービスを提供する利用者の身元等はより確実に保証され、当該サービス事業者が蓄積したデータの信頼性も向上する。情報流通システムは、信頼性の担保されたデータを使用するため、提供サービスの向上又は維持が図れる。

【0021】

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

【0022】

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

【0023】

［システム構成］
図３は、第１の実施形態に係る情報流通システムの概略構成の一例を示す図である。図３に示すように、情報流通システムの参加メンバー（アクター）には、情報流通事業者と、サービス事業者と、が含まれる。

【0024】

情報流通事業者は、データ流通に関するサービス（情報流通サービス）を提供する主体である。情報流通事業者は、ポータルサーバ１０と流通制御サーバ２０を含む。

【0025】

ポータルサーバ１０は、情報流通サービスを利用する利用者のインターフェイスとなるポータルサイトを提供するサーバ装置である。利用者は、情報流通サービスを利用する際、ポータルサーバ１０にアクセスする。

【0026】

流通制御サーバ２０は、サービス事業者間のデータ流通を制御（実現）するサーバ装置である。流通制御サーバ２０は、サービス事業者に蓄積されたデータのデータ流通を実現する装置である。

【0027】

サービス事業者は、個人にサービスを提供する主体である。サービス事業者は、民間の事業者であってもよいし公的機関であってもよい。サービス事業者には、例えば、利用者に医療サービスを提供する医療機関（病院、薬局等）、小売業者、顧客に健康サービスを提供するヘルスケア事業者等が例示される。

【0028】

各サービス事業者は、顧客にサービスを提供するためのサービスサーバ３０を備える。サービスサーバ３０は、サービス事業者により管理、運営される。サービスサーバ３０は、サービス事業者が利用者にサービスを提供することで生じたデータや利用者にサービスを提供するために必要なデータを蓄積する（ユーザデータを蓄積する）。即ち、サービスサーバ３０は、利用者に提供されるサービスに関するデータを蓄積する。

【0029】

情報流通システムを利用する利用者は、端末４０を使用する。

【0030】

図３に示す各装置はネットワークを介して相互に接続されている。例えば、流通制御サーバ２０とサービスサーバ３０は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。

【0031】

図３に示す構成は例示であって、本願開示の情報流通システムの構成等を限定する趣旨ではない。例えば、情報流通事業者には２台以上の流通制御サーバ２０が含まれていてもよい。

【0032】

［システムの動作概略］
続いて、第１の実施形態に係る情報流通システムの動作概略について説明する。

【0033】

第１の実施形態では、サービス事業者の一例として、利用者に健康に関するアドバイスを提供するヘルスケア事業者と、インターネット上で商品等を販売するＥＣ（Electronic Commerce）事業者と、を例にとり説明を行う。

【0034】

図３に示すように、ヘルスケア事業者はサービスサーバ３０－１を備え、ＥＣ事業者はサービスサーバ３０－２を備える。また、以降の説明において、サービスサーバ３０－１及び３０－２を区別する特段の事情がない場合には単に「サービスサーバ３０」と表記する。

【0035】

ヘルスケア事業者からサービスの提供を受けるためには、利用者は、サービスサーバ３０－１が管理するアカウント（第１のアカウント）にログインする必要がある。具体的には、利用者は、ＩＤとパスワードをサービスサーバ３０－１に提供することでアカウントにログインする。また、ヘルスケア事業者がアカウントを生成する際に、本人確認等は行われない。

【0036】

サービスサーバ３０－１（第１のサーバ装置）は、当該アカウントにログインした利用者に第１のサービス（健康に関するアドバイス）を提供するために必要なＩＤ（第１のＩＤ；会員番号等）を記憶する。また、サービスサーバ３０－１は、利用者に提供されるサービスに関するデータ（例えば、運動時間等）を蓄積する。

【0037】

なお、ヘルスケア事業者やＥＣ事業者が提供する具体的なサービスに関する説明は省略する。ヘルスケア事業者は、利用者の食事に関する情報や運動に関するデータを収集（蓄積）し、当該蓄積されたデータに基づいたアドバイス等を行う。ＥＣ事業者は、ネットワーク上での商取引サービス（オンラインショッピング）を提供する。

【0038】

情報流通システムにおけるデータ流通の手段として「共有」と「提供」が存在する。流通制御サーバ２０（第２のサーバ装置）は、アカウント（第２のアカウント）にログインした利用者について、当該利用者の蓄積されたデータのデータ流通を制御する。

【0039】

「共有」は、サービス事業者が、他のサービス事業者により蓄積されたデータを取得するための手段である。例えば、ヘルスケア事業者が利用者にサービス提供することで生成されたデータをＥＣ事業者が取得する際に「共有」によるデータ流通が用いられる。

【0040】

「共有」は、サービス利用者自身の利便性の向上に用いられるため、原則としてデータ流通に対する対価は発生しない。即ち、「共有」は、利用者がサービス事業者からより良いサービスの提供を受けるため他のサービス事業者が蓄積したデータを活用するために使用される。

【0041】

「提供」は、データ利活用事業者が、他のサービス事業者により蓄積されたデータを取得するための手段である。例えば、製薬会社が医療機関から健康診断の結果や診察の結果を取得する際に「提供」によるデータ流通が用いられる。

【0042】

「提供」は、利用者に直接サービスを提供しないデータ利活用事業者が用いる手段のため、原則としてデータ流通に対する対価が発生する。即ち、「提供」は、利用者がデータ利活用事業者から対価を受けるために使用される。

【0043】

蓄積データのデータ流通手段に関し、第１の実施形態では、「共有」を例にとり説明を行う。しかし、蓄積データは「提供」によるデータ流通の対象となり得るのは当然である。

【0044】

＜システムアカウントの生成＞
情報流通システムの利用者は事前に登録（利用者登録、システム登録）を行う必要がある。より具体的には、利用者は、ポータルサーバ１０にアクセスし、アカウント生成のための手続きを行う。以降の説明において、情報流通システムに生成されたアカウントを「システムアカウント」と表記する。

【0045】

システムアカウントを生成するため、利用者は、所持する端末４０を操作して、ポータルサーバ１０にアクセスする。端末４０のアクセスに応じて、ポータルサーバ１０は、システムアカウントを生成するためのＷＥＢ（ウェブ）ページを表示する。

【0046】

利用者は、システムアカウント生成のための操作（例えば、所定ボタンの押下）を行い、システムアカウントの生成をポータルサーバ１０に要求する（図４参照）。ポータルサーバ１０は、利用者のシステムアカウント生成に必要な情報を取得する。具体的には、ポータルサーバ１０は、利用者のログイン情報（ログインＩＤ、パスワード）、個人情報（氏名、生年月日等）、生体情報（例えば、顔画像）及び身元確認書類等（運転免許証等）を取得する。

【0047】

ポータルサーバ１０は、取得したログイン情報、個人情報、生体情報、身元確認書類等を含む「アカウント生成要求」を流通制御サーバ２０に送信する（ステップＳ０１）。

【0048】

流通制御サーバ２０は、当該アカウント生成要求に含まれる生体情報と身元確認書類に記載された生体情報を用いて本人確認を行う。流通制御サーバ２０は、本人確認に成功すると、当該利用者のシステムアカウントを生成する。その際、流通制御サーバ２０は、当該利用者を情報流通システムにおいて一意に識別するためのユーザＩＤ（Identifier）を生成する。

【0049】

流通制御サーバ２０は、当該生成された利用者のユーザＩＤ、ログイン情報、個人情報（氏名、生年月日、連絡先等）及び生体情報等を対応付けて記憶する。流通制御サーバ２０は、これらの情報を「利用者情報データベース」に記憶する。利用者情報データベースの詳細は後述する。

【0050】

流通制御サーバ２０は、上記生成したユーザＩＤをポータルサーバ１０に送信する（ステップＳ０２）。ポータルサーバ１０は、流通制御サーバ２０から取得したユーザＩＤを利用者（端末４０）に払い出す（ステップＳ０３）。端末４０は、払い出されたユーザＩＤを記憶する。

【0051】

＜サービスアカウントの生成＞
サービス事業者からサービスの提供を受けるためには、利用者は、当該サービス事業者にアカウントを生成する必要がある。より具体的には、利用者は、サービス事業者が管理するサービスサーバ３０にアクセスし、アカウント生成のための利用者登録を行う。以降の説明において、サービス事業者に生成されたアカウントを「サービスアカウント」と表記する。

【0052】

サービスアカウントを生成するため、利用者は、所持する端末４０を操作して、目的のサービスサーバ３０にアクセスする。例えば、ヘルスケア事業者からサービスの提供を受けたい利用者は、サービスサーバ３０－１にアクセスする。端末４０のアクセスに応じて、サービスサーバ３０は、サービスアカウントを生成するためのＷＥＢ（ウェブ）ページを表示する。

【0053】

利用者が、サービスアカウント生成のための操作（例えば、所定ボタンの押下）を行うと、サービスサーバ３０は、利用者のサービスアカウント生成に必要な情報を取得する。具体的には、サービスサーバ３０は、利用者のログイン情報（ログインＩＤ、パスワード）及び個人情報（氏名、生年月日等）等を取得する。

【0054】

サービスサーバ３０は、当該利用者のサービスアカウントを生成する。サービスサーバ３０は、自社（サービス事業者）において当該利用者を識別するための識別情報（ＩＤ、コード）を生成する。以降の説明において、サービス事業者が生成する識別情報を「個人識別ＩＤ」と表記する。例えば、会員番号、診察券番号等が当該個人識別ＩＤ（個人識別コード）に相当する。

【0055】

サービスサーバ３０は、利用者のログイン情報、個人情報及び個人識別ＩＤを対応付けて記憶する。サービスサーバ３０は、これらの情報を「顧客情報データベース」に記憶する。顧客情報データベースの詳細は後述する。

【0056】

サービスサーバ３０は、上記生成した個人識別ＩＤを利用者（端末４０）に払い出す。端末４０は、払い出された個人識別ＩＤを記憶する。

【0057】

＜システムアカウントにログイン＞
情報流通サービスを利用するためには、利用者は、システムアカウントにログインする必要がある。例えば、利用者は、ポータルサイトに表示される「ログイン」ボタンを押下することで、システムアカウントへのログインをポータルサーバ１０に要求する（図５参照）。

【0058】

利用者からログインを要求されると、ポータルサーバ１０は、利用者のログイン要求を流通制御サーバ２０にリダイレクトする（認証リダイレクト）。具体的には、ポータルサーバ１０は、「認証要求」を流通制御サーバ２０に送信する（ステップＳ１１）。

【0059】

ここで、情報流通システムは、利用者の認証に多要素認証を採用する。具体的には、流通制御サーバ２０と端末４０は、異なる種類の認証情報を送受信することで、多要素認証を実行する（ステップＳ１２）。

【0060】

例えば、端末４０は、ログイン情報（ＩＤ、パスワード）を認証情報として流通制御サーバ２０に送信する。流通制御サーバ２０は、ＩＤ認証（パスワード認証）に成功すると、生体情報に関する認証情報の提供を端末４０に要求する。端末４０は、利用者の生体情報を取得し、２段階目の認証情報として当該生体情報を流通制御サーバ２０に送信する。流通制御サーバ２０は、生体情報を用いた生体認証を実行する。

【0061】

流通制御サーバ２０は、認証結果（多要素認証による認証結果）をポータルサーバ１０に送信する（ステップＳ１３）。その際、流通制御サーバ２０は、認証成功の場合には、当該利用者のユーザＩＤをポータルサーバ１０に通知する。

【0062】

ポータルサーバ１０は、通知されたユーザＩＤに対応する利用者をサービス提供の対象者と判断する。システムアカウントにログインが成功すると、利用者は、ポータルサイト上で情報流通システムを利用する際の設定変更等を行える。

【0063】

＜サービスアカウントにログイン＞
サービスアカウントへのログインについては詳細な説明を省略する。利用者の端末４０及びサービスサーバ３０は、事前に定められたＩＤ及びパスワードを用いて利用者を認証すればよい。

【0064】

＜ＩＤの連携＞
サービスサーバ３０に蓄積されたデータ（ユーザデータ）をデータ流通の対象とするためには、利用者は、システムアカウントのＩＤ（ユーザＩＤ）とサービスアカウントのＩＤ（個人識別ＩＤ）を連携する必要がある。例えば、ヘルスケア事業者に蓄積されたデータをデータ流通の対象とするためには、利用者は、情報流通システムのユーザＩＤと当該ヘルスケア事業者から発行された個人識別ＩＤを連携（紐付け）する必要がある。

【0065】

なお、以降の説明において、システムアカウントのユーザＩＤとサービスアカウントの個人識別ＩＤを連携すること（対応付けること）を「ＩＤ連携」と表記する。

【0066】

ＩＤ連携を実現するため、利用者は、システムアカウントにログインする。ログインに成功すると、利用者は、ポータルサイト上でＩＤ連携のための手続きを行う（図６参照）。具体的には、利用者は、端末４０を操作して、所定のボタンを押下することで「連携コード」の発行をポータルサーバ１０に要求する。

【0067】

なお、連携コードは、ＩＤ連携を実現するための情報（データ）である。より具体的には、連携コードは、ＩＤ連携を希望する利用者のシステムアカウント（氏名等の個人情報や生体情報等の本人確認情報）と紐付く有効期限付きのトークンである。

【0068】

連携コードの発行に関する操作を受けると、ポータルサーバ１０は、流通制御サーバ２０に「連携コード発行要求」を送信する（ステップＳ２１）。

【0069】

当該連携コード発行要求の受信に応じて、流通制御サーバ２０は、連携コードを生成する。流通制御サーバ２０は、生成した連携コードを利用者情報データベースに記憶する。

【0070】

流通制御サーバ２０は、生成した連携コードをポータルサーバ１０に送信する（ステップＳ２２）。ポータルサーバ１０は、受信した連携コードを端末４０に送信する（ステップＳ２３）。端末４０は、受信した連携コードを記憶し、利用者が当該連携コードを閲覧可能な状態に管理する。

【0071】

連携コードを取得すると、利用者は、ＩＤ連携を希望するサービス事業者のサービスアカウントにログインする。利用者は、サービス事業者が提供するＷＥＢサイト上でＩＤ連携のための手続きを行う。例えば、利用者は、端末４０を操作して、所定のボタンを押下することで、ＩＤ連携をサービスサーバ３０に要求する（図７参照）。

【0072】

利用者が所定のボタンを押下すると、サービスサーバ３０は、利用者から連携コードを取得する（ステップＳ３１）。

【0073】

連携コードを取得すると、サービスサーバ３０は、ＩＤ連携の実行を流通制御サーバ２０に要求する。具体的には、サービスサーバ３０は、上記取得した連携コード、サービスアカウントにログイン中の利用者の個人識別ＩＤ及び事業者コードを含む「ＩＤ連携要求」を流通制御サーバ２０に送信する（ステップＳ３２）。

【0074】

なお、事業者コードは、情報流通システムに参加するサービス事業者を識別するための識別情報（ＩＤ）である。例えば、ヘルスケア事業者（サービスサーバ３０－１）とＥＣ事業者（サービスサーバ３０－２）には異なるコードが割り当てられる。

【0075】

事業者コードは、任意の手段によりシステム参加者（情報流通事業者、サービス事業者）の間で共有される。例えば、サービス事業者が情報流通システムに参加する際、情報流通事業者が当該サービス事業者に割り当てる事業者コードを生成する。情報流通事業者は、当該生成した事業者コードをサービス事業者に通知する。

【0076】

ＩＤ連携要求を受信すると、流通制御サーバ２０は、当該ＩＤ連携要求に含まれる連携コードをキーとして利用者情報データベースを検索し、対応する利用者を特定する。

【0077】

その後、流通制御サーバ２０は、特定した利用者が所持する端末４０に対して生体情報の提供を要求する。具体的には、流通制御サーバ２０は、「生体情報提供要求」を端末４０に送信する（ステップＳ３３）。

【0078】

生体情報提供要求の受信に応じて、端末４０は、利用者の生体情報（例えば、顔画像）を取得するためのＧＵＩ等を表示する。端末４０は、取得した生体情報（顔画像）を流通制御サーバ２０に送信する（ステップＳ３４）。

【0079】

流通制御サーバ２０は、連携コードを用いて特定した利用者の生体情報（顔画像）と端末４０から提供された生体情報を用いた生体認証（１対１認証）を実行する。即ち、流通制御サーバ２０は、ＩＤ連携を要求する利用者の身元を生体認証によって確認する。

【0080】

生体認証に成功すると、流通制御サーバ２０は、ＩＤ連携を実行する。具体的には、流通制御サーバ２０は、ＩＤ連携要求に含まれる事業者コードからサービス事業者を特定し、当該特定したサービス事業者の個人識別ＩＤを利用者情報データベースに記憶する。即ち、流通制御サーバ２０は、システムアカウントのユーザＩＤと個人識別ＩＤを対応付けて利用者情報データベースに登録する。

【0081】

例えば、システムアカウントでは「＃１０」のユーザＩＤが割り当てられ、サービスアカウントでは「＃１００」の個人識別ＩＤが割り当てられた利用者について考える。当該利用者が、ＩＤ連携を行うことで、２つのＩＤ（＃１０、＃１００）が同一人物のＩＤとしてシステム登録される。

【0082】

流通制御サーバ２０は、ＩＤ連携処理の結果をサービスサーバ３０に通知する。流通制御サーバ２０は、ＩＤ連携要求に対する応答（肯定応答、否定応答）をサービスサーバ３０に送信する（ステップＳ３５）。

【0083】

サービスサーバ３０は、ＩＤ連携処理の結果を利用者に通知する。

【0084】

＜ＩＤ連携後のサービスアカウントにログイン＞
ＩＤ連携が完了したサービス事業者からサービスの提供を受ける際には、利用者は、流通制御サーバ２０を介してサービスサーバ３０にログインする。即ち、利用者は、所謂、ＳＳＯ（Single Sign On）によりサービスサーバ３０にログインする。

【0085】

具体的には、利用者は、端末４０を操作してサービスサーバ３０にアクセスする。利用者が、サービスサーバ３０が提供するＷＥＢページ上でログイン手続きを行うと、サービスサーバ３０は、認証リダイレクトを流通制御サーバ２０に送信する。具体的には、サービスサーバ３０は、認証要求を流通制御サーバ２０に送信する。その際、サービスサーバ３０は、当該サービスサーバ３０を運営するサービス事業者の事業者コードと端末４０のアドレスを流通制御サーバ２０に送信する。

【0086】

流通制御サーバ２０は、認証要求（認証リダイレクト）を受信すると、利用者がシステムアカウントにログインする際の手続きと同様の手続きを当該利用者に要求する。具体的には、流通制御サーバ２０は、異なる種類の認証情報を用いた多要素認証を実行する。

【0087】

多要素認証に成功すると、流通制御サーバ２０は、認証処理により特定された利用者の個人識別ＩＤのうち認証要求に含まれる事業者コードに対応する個人識別ＩＤを利用者情報データベースから読み出す。

【0088】

流通制御サーバ２０は、当該読み出した個人識別ＩＤを認証要求の送信元であるサービスサーバ３０に通知する。サービスサーバ３０は、個人識別ＩＤを取得したことで、当該個人識別ＩＤの利用者がログインしたと判断する。

【0089】

このように、流通制御サーバ２０は、サービスアカウントで管理される個人識別ＩＤとシステムアカウントで管理されるユーザＩＤを対応付ける（ＩＤ連携を行う）。流通制御サーバ２０は、ＩＤが連携された後は、利用者がサービスアカウントにログインする際、システムアカウントにログインする手続きと同じ手続きを利用者に要求する。

【0090】

また、ポータルサーバ１０（第３のサーバ装置）は、利用者によるシステムアカウントへのログイン要求を受け付け、当該利用者の認証を流通制御サーバ２０に要求する。流通制御サーバ２０は、利用者について多要素認証を実行し、多要素認証の結果をポータルサーバ１０に通知する。

【0091】

＜データの蓄積及び所在情報の送信＞
サービス事業者は、利用者のユーザデータを蓄積する。サービス事業者（サービスサーバ３０）は、各利用者の個人識別コードとサービス提供の結果として得られたデータを対応付けて記憶する。

【0092】

サービス事業者は、ユーザデータ（サービス提供の結果生じるデータ、サービスの提供に必要なデータ）を蓄積するたびに、「所在情報」を流通制御サーバ２０に送信する。所在情報は、サービス事業者に蓄積されたデータの保管場所（データの蓄積主体；サービス事業者）等に関する情報である。所在情報には、個人識別コード、事業者コード、蓄積したデータの種類等が含まれる。

【0093】

流通制御サーバ２０は、取得した所在情報を「所在情報データベース」に記憶する。所在情報データベースの詳細は後述する。当該所在情報データベースは、個人識別コード、事業者コード及びデータ種類を対応付けて記憶する。

【0094】

＜共有によるデータ流通＞
他のサービス事業者が蓄積したデータの取得を希望するサービス事業者は、「共有」によって当該データを取得する。

【0095】

ここでは、図８を参照しつつ、ＥＣ事業者が、ヘルスケア事業者に蓄積された利用者Ｕ１のデータを「共有」により取得する場合について説明する。

【0096】

データ共有要請者であるＥＣ事業者のサービスサーバ３０－２は、「共有要請」を流通制御サーバ２０に送信する（ステップＳ４１）。

【0097】

流通制御サーバ２０は、共有要請に基づいて、データ流通の対象者（利用者Ｕ１）と流通させるデータのデータ蓄積者（ヘルスケア事業者）を特定する。流通制御サーバ２０は、特定された対象者（利用者Ｕ１）が所持する端末４０に対して、データ共有に関する問合せを送信する（ステップＳ４２）。

【0098】

データ共有の問合せを受信した端末４０は、データ共有に関する利用者の意思を取得する。例えば、端末４０は、ＧＵＩ（Graphical User Interface）を用いて利用者Ｕ１の意思を取得する。上記の例では、端末４０は、「ヘルスケア事業者のデータをＥＣ事業者へ共有することで、より良いサービスが受けられます。共有しますか？」といった内容のＧＵＩを表示し、利用者の意思（データ共有に同意、不同意）を取得する。

【0099】

端末４０は、データ共有の問合せに対する応答（データ共有に同意、又は、データ共有を拒否）を流通制御サーバ２０に送信する（ステップＳ４３）。

【0100】

利用者の同意が得られれば、流通制御サーバ２０は、データ蓄積者（ヘルスケア事業者のサービスサーバ３０－１）に対して共有指示を送信する（ステップＳ４４）。

【0101】

共有指示を受信したヘルスケア事業者のサービスサーバ３０－１は、顧客情報データベースを参照し、利用者Ｕ１のデータ（例えば、運動時間等）を指定されたデータ共有先のサービスサーバ３０－２に送信する（ステップＳ４５）。

【0102】

続いて、第１の実施形態に係る情報流通システムに含まれる各装置の詳細について説明する。

【0103】

［ポータルサーバ］
図９は、第１の実施形態に係るポータルサーバ１０の処理構成（処理モジュール）の一例を示す図である。図９を参照すると、ポータルサーバ１０は、通信制御部２０１と、アカウント生成制御部２０２と、ログイン制御部２０３と、ＩＤ連携制御部２０４と、記憶部２０５と、を備える。

【0104】

通信制御部２０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部２０１は、流通制御サーバ２０からデータ（パケット）を受信する。また、通信制御部２０１は、流通制御サーバ２０に向けてデータを送信する。通信制御部２０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部２０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部２０１を介して他の装置とデータの送受信を行う。通信制御部２０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0105】

アカウント生成制御部２０２は、システムアカウント生成に関する制御を行う手段である。アカウント生成制御部２０２は、ポータルサイト上で利用者が所定の操作を行うと、当該利用者用のシステムアカウント生成に関する処理を行う。例えば、アカウント生成制御部２０２は、図１０に示すポータルサイトにおいて、「アカウント生成」ボタンが押下されると、利用者のログイン情報等を取得するためのＧＵＩを表示する。

【0106】

例えば、アカウント生成制御部２０２は、図１１に示すようなＧＵＩを端末４０に表示する。アカウント生成制御部２０２は、図１１に示すようなＧＵＩによりログイン情報、個人情報、生体情報、身元確認書類の写し等を取得する。あるいは、アカウント生成制御部２０２は、生体情報や身元確認書類に関し、顔や身元確認書類の撮影を利用者に指示してもよい。

【0107】

アカウント生成制御部２０２は、端末４０から利用者のログイン情報等を取得すると、当該取得した情報（ログイン情報、個人情報、生体情報、身元確認書類）を流通制御サーバ２０に送信する。アカウント生成制御部２０２は、ログイン情報等を含む「アカウント生成要求」を流通制御サーバ２０に送信する。

【0108】

アカウント生成制御部２０２は、アカウント生成要求に対する応答（肯定応答、否定応答）を流通制御サーバ２０から受信する。

【0109】

流通制御サーバ２０がシステムアカウントの生成に成功すると（肯定応答を受信すると）、アカウント生成制御部２０２は、当該肯定応答に含まれるユーザＩＤを端末４０に送信する。

【0110】

流通制御サーバ２０がシステムアカウントの生成に失敗すると（否定応答を受信すると）、アカウント生成制御部２０２は、その旨を利用者に通知する。

【0111】

ログイン制御部２０３は、システムアカウントへのログインに関する制御を行う手段である。例えば、ログイン制御部２０３は、図１０において「ログイン」ボタンが押下されると、流通制御サーバ２０に対して認証リダイレクトを行う。

【0112】

具体的には、ログイン制御部２０３は、端末４０のアドレスを含む「認証要求」を流通制御サーバ２０に送信する。ログイン制御部２０３は、流通制御サーバ２０から認証要求に対する応答（肯定応答、否定応答）を受信する。

【0113】

ログインに失敗した場合（否定応答を受信した場合）、ログイン制御部２０３は、その旨を利用者に通知する。ログインに成功した場合（肯定応答を受信した場合）、ログイン制御部２０３は、その旨を利用者に通知すると共に、当該肯定応答に含まれるユーザＩＤをシステム利用者のＩＤとして記憶する（ログイン中の利用者として記憶する）。

【0114】

ＩＤ連携制御部２０４は、システムアカウントのＩＤとサービスアカウントのＩＤの連携に関する制御を行う手段である。

【0115】

システムアカウントにログイン中の利用者が所定の操作（例えば、ＩＤ連携ボタンの押下）を行うと、ＩＤ連携制御部２０４は、図１２に示すようなＧＵＩを端末４０に表示する。ＩＤ連携制御部２０４は、図１２に示すようなＧＵＩを用いてＩＤ連携の対象となるサービス事業者の情報を取得する。

【0116】

サービス事業者の情報（例えば、ＩＤ連携の対象となるサービス事業者の事業者コード）を取得すると、ＩＤ連携制御部２０４は、ログイン中の利用者のユーザＩＤ及び事業者コードを含む連携コード発行要求を流通制御サーバ２０に送信する。

【0117】

ＩＤ連携制御部２０４は、連携コード発行要求に対する応答（肯定応答、否定応答）を受信する。

【0118】

連携コードが発行されない場合（否定応答を受信した場合）、ＩＤ連携制御部２０４は、ＩＤ連携不可を利用者に通知する。

【0119】

連携コードが発行された場合（肯定応答を受信した場合）、ＩＤ連携制御部２０４は、ＩＤ連携先の事業者コードと共に連携コードを端末４０に送信する。

【0120】

記憶部２０５は、ポータルサーバ１０の動作に必要な情報を記憶する。例えば、記憶部２０５は、サービス事業者の名称と事業者コードを対応付けたテーブル情報等を記憶する。

【0121】

［流通制御サーバ］
図１３は、第１の実施形態に係る流通制御サーバ２０の処理構成（処理モジュール）の一例を示す図である。図１３を参照すると、流通制御サーバ２０は、通信制御部３０１とアカウント管理部３０２と、ログイン管理部３０３と、ＩＤ連携管理部３０４と、所在情報管理部３０５と、データ流通制御部３０６と、記憶部３０７と、を備える。

【0122】

通信制御部３０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部３０１は、サービスサーバ３０からデータ（パケット）を受信する。また、通信制御部３０１は、サービスサーバ３０に向けてデータを送信する。通信制御部３０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部３０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部３０１を介して他の装置とデータの送受信を行う。通信制御部３０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0123】

アカウント管理部３０２は、利用者のシステムアカウントに関する制御、管理を行う手段である。

【0124】

アカウント管理部３０２は、ポータルサーバ１０からアカウント生成要求を受信する。アカウント管理部３０２は、ポータルサーバ１０から取得した生体情報（顔画像）及び身元確認書類に記載された生体情報を使って本人確認を行う。

【0125】

具体的には、アカウント管理部３０２は、上記２つの生体情報（顔画像）それぞれから特徴量を生成する。特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、アカウント管理部３０２は、顔画像から目、鼻、口等を特徴点として抽出する。その後、アカウント管理部３０２は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトル（顔画像を特徴づけるベクトル情報）を生成する。

【0126】

アカウント管理部３０２は、上記生成された２つの特徴量を用いた認証処理（１対１認証）を行う。具体的には、アカウント管理部３０２は、２つの特徴量の間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。

【0127】

類似度が所定の値以上であれば、アカウント管理部３０２は、本人確認に成功したと判定する。類似度が所定の値より小さければ、アカウント管理部３０２は、本人確認に失敗したと判定する。

【0128】

本人確認に失敗すると、アカウント管理部３０２は、アカウントの生成に失敗した旨をポータルサーバ１０に通知する。具体的には、アカウント管理部３０２は、アカウント生成要求に対する否定応答をポータルサーバ１０に送信する。

【0129】

本人確認に成功すると、アカウント管理部３０２は、利用者のシステムアカウントを生成する。具体的には、アカウント管理部３０２は、当該利用者を情報流通システムにおいて一意に識別するためのユーザＩＤを生成する。なお、ユーザＩＤは、利用者を一意に識別できる情報であればどのような情報であってもよい。例えば、アカウント管理部３０２は、アカウント生成要求を処理するたびに一意な値を採番しユーザＩＤとしてもよい。

【0130】

アカウント管理部３０２は、当該生成された利用者のユーザＩＤ、ログイン情報、個人情報（氏名、生年月日、連絡先等）及び生体情報等を対応付けて記憶する。流通制御サーバ２０は、これらの情報を「利用者情報データベース」に記憶する（図１４参照）。

【0131】

図１４に示すように、利用者情報データベース（ＤＢ；Data Base）は、ログイン情報等を記憶するフィールドに加え、ＩＤ連携に関する情報（ＩＤ連携情報）を記憶するフィールド、サービス事業者ごとに個人識別ＩＤを記憶するフィールド等を備える。なお、個人識別ＩＤフィールドに記載された「ＨＬ」はヘルスケア事業者の事業者コードを示し、「ＥＣ」はＥＣ事業者の事業者コードを示す。

【0132】

また、図１４ではＩＤ連携情報をまとめて表記しているが、実際のＩＤ連携情報は、図１５に示すように、連携コード、事業者コード及び有効期間を１組としてユーザＩＤと対応付けられている。

【0133】

なお、図１４、図１５に示す利用者情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、ポータルサーバ１０から取得した身元確認書類が利用者情報データベースに登録されていてもよい。

【0134】

利用者のシステムアカウントを生成すると、アカウント管理部３０２は、アカウントの生成に成功した旨をポータルサーバ１０に通知する。具体的には、アカウント管理部３０２は、アカウント生成要求に対する肯定応答をポータルサーバ１０に送信する。その際、アカウント管理部３０２は、上記生成した利用者のユーザＩＤを含む肯定応答をポータルサーバ１０に送信する。

【0135】

ログイン管理部３０３は、利用者によるシステムアカウントへのログインを制御、管理する手段である。ログイン管理部３０３は、ポータルサーバ１０から認証要求（認証リダイレクト）を受信すると、当該認証要求に含まれるアドレスの端末４０を対象とし、多要素認証に関する制御を行う。

【0136】

はじめに、ログイン管理部３０３は、端末４０に対してログイン情報（ＩＤ、パスワードの組み合わせ）の提供を要求する。ログイン管理部３０３は、端末４０から取得したログイン情報をキーとして利用者情報データベースを検索し、対応する利用者の特定を試みる。

【0137】

対応する利用者が特定されれば、ログイン管理部３０３は、最初の認証情報（ログイン情報）を使った１回目の認証に成功したと判定する。対応する利用者が特定されなければ、ログイン管理部３０３は、最初の認証情報を使った１回目の認証に失敗したと判定する。

【0138】

１回目の認証に成功すると、ログイン管理部３０３は、端末４０に対して生体情報（顔画像）の提供を要求する。ログイン管理部３０３は、端末４０から取得した生体情報と上記１回目の認証で特定された利用者の生体情報を使った認証を試みる。即ち、ログイン管理部３０３は、２つ目の認証情報（生体情報）を使った２回目の認証を行う。

【0139】

ログイン管理部３０３は、２回目の認証（生体認証）にも成功すると、端末４０を所持する利用者に関する多要素認証に成功したと判定する。ログイン管理部３０３は、１回目又は２回目の認証（生体認証）に失敗すると、端末４０を所持する利用者に関する多要素認証に失敗したと判定する。

【0140】

ログイン管理部３０３は、認証結果（多要素認証の結果）をポータルサーバ１０に通知する。多要素認証に失敗していれば、ログイン管理部３０３は、否定応答をポータルサーバ１０に送信する。多要素認証に成功していれば、ログイン管理部３０３は、肯定応答をポータルサーバ１０に送信する。認証成功を通知する際には、ログイン管理部３０３は、利用者（ログイン成功者）のユーザＩＤを含む肯定応答を送信する。

【0141】

ログイン管理部３０３は、サービスサーバ３０から受信する認証要求をポータルサーバ１０から受信する認証要求と同様に処理する。多要素認証成功時に、ログイン管理部３０３は、サービスサーバ３０から取得した認証要求に含まれる事業者コードに対応する個人識別ＩＤをサービスサーバ３０に通知すればよい。

【0142】

ＩＤ連携管理部３０４は、ＩＤ連携に関する制御、管理を行う手段である。図１６及び図１７を用いてＩＤ連携管理部３０４の動作を説明する。

【0143】

ＩＤ連携管理部３０４は、ポータルサーバ１０から受信する「連携コード発行要求」を処理する。図１６は、連携コード発行要求を処理する際のＩＤ連携管理部３０４の動作の一例を示すフローチャートである。

【0144】

ＩＤ連携管理部３０４は、連携コード発行要求に含まれるユーザＩＤをキーとして利用者情報データベースを検索し、対応する利用者の特定を試みる（ステップＳ１０１）。

【0145】

利用者の特定に失敗すれば（ステップＳ１０２、Ｎｏ分岐）、ＩＤ連携管理部３０４は、連携コードを発行できない旨をポータルサーバ１０に通知する。具体的には、ＩＤ連携管理部３０４は、連携コード発行要求に対する否定応答をポータルサーバ１０に送信する（ステップＳ１０３）。

【0146】

利用者の特定に成功すれば（ステップＳ１０２、Ｙｅｓ分岐）、ＩＤ連携管理部３０４は、連携コードを生成する（ステップＳ１０４）。上述のように、連携コードは、ＩＤ連携を希望する利用者のシステムアカウントと紐付く有効期限付きのトークンである。例えば、ＩＤ連携管理部３０４は、利用者のユーザＩＤ、現在時刻、ＩＤ連携対象のサービス事業者の事業者コード等の連結値を計算し、当該計算された連結値のハッシュ値を計算することで連携コードを生成する。

【0147】

ＩＤ連携管理部３０４は、生成した連携コードを利用者情報データベースに登録する（ステップＳ１０５）。ＩＤ連携管理部３０４は、連携コード発行要求に含まれる事業者コードと上記生成した連携コードを対応付けて利用者情報データベースに記憶する。その際、ＩＤ連携管理部３０４は、連携コードの有効期間も併せて利用者情報データベースに登録する。図１５の例では、連携コードの有効期間が終了する日時が利用者情報データベースに登録されている。

【0148】

なお、ＩＤ連携管理部３０４は、予め定められた期間を有効期間に設定してもよいし、所定の規則等に基づいて有効期間を決定してもよい。例えば、ＩＤ連携管理部３０４は、サービス事業者ごとに異なる有効期間を設定してもよい。

【0149】

連携コードの生成及び登録が終了すると、ＩＤ連携管理部３０４は、生成した連携コードをポータルサーバ１０に通知する。具体的には、ＩＤ連携管理部３０４は、生成した連携コードを含む肯定応答（連携コード発行要求に対する応答）をポータルサーバ１０に送信する（ステップＳ１０６）。

【0150】

ＩＤ連携管理部３０４は、サービスサーバ３０から受信する「ＩＤ連携要求」も処理する。図１７は、ＩＤ連携要求を処理する際のＩＤ連携管理部３０４の動作の一例を示すフローチャートである。

【0151】

ＩＤ連携要求を受信すると、ＩＤ連携管理部３０４は、当該ＩＤ連携要求に含まれる連携コードをキーとして利用者情報データベースを検索する。検索に成功すると、ＩＤ連携管理部３０４は、特定された連携コードの有効期間を検証する（ステップＳ２０１）。

【0152】

連携コードの有効期間が経過していれば（ステップＳ２０２、Ｎｏ分岐）、ＩＤ連携管理部３０４は、ＩＤ連携処理の結果を「ＩＤ連携失敗」に設定する（ステップＳ２０３）。

【0153】

連携コードの有効期間が経過していなければ（ステップＳ２０２、Ｙｅｓ分岐）、ＩＤ連携管理部３０４は、連携コードに基づき特定された利用者の連絡先（端末４０のアドレス）に対して、「生体情報提供要求」を送信する（ステップＳ２０４）。

【0154】

生体情報が提供されないと（生体情報提供要求に対する否定応答を受信すると；ステップＳ２０５、Ｎｏ分岐）、ＩＤ連携管理部３０４は、ＩＤ連携処理の結果を「ＩＤ連携失敗」に設定する（ステップＳ２０３）。

【0155】

生体情報が提供されると（生体情報提供要求に対する肯定応答を受信すると；ステップＳ２０５、Ｙｅｓ分岐）、ＩＤ連携管理部３０４は、生体認証を実行する（ステップＳ２０６）。具体的には、ＩＤ連携管理部３０４は、連携コードを用いて特定した利用者の生体情報（顔画像）と端末４０から提供された生体情報を用いた生体認証（１対１認証）を実行する。

【0156】

生体認証に失敗すると（ステップＳ２０７、Ｎｏ分岐）、ＩＤ連携管理部３０４は、ＩＤ連携処理の結果を「ＩＤ連携失敗」に設定する（ステップＳ２０３）。

【0157】

生体認証に成功すると（ステップＳ２０７、Ｙｅｓ分岐）、ＩＤ連携管理部３０４は、ＩＤ連携を実行する（ステップＳ２０８）。具体的には、ＩＤ連携管理部３０４は、ＩＤ連携要求に含まれる事業者コードからＩＤ連携の対象となるサービス事業者を特定し、当該特定したサービス事業者が生成した個人識別ＩＤ（ＩＤ連携要求に含まれる個人識別ＩＤ）を利用者情報データベースに記憶する。

【0158】

例えば、図１５の例では、ユーザＩＤ「ｕＩＤ０１」の利用者は、ヘルスケア事業者にＩＤ連携を要求している（１行目参照）。当該利用者についてＩＤ連携が実行されると、図１４の１行目に示される個人識別ＩＤフィールドのヘルスケア事業者に、当該利用者の個人識別ＩＤ（ヘルスケア事業者が生成した個人識別ＩＤ）が設定される。その結果、氏名Ｕ１の利用者のユーザＩＤ「ｕＩＤ０１」とヘルスケア事業者の個人識別ＩＤが同一人物のＩＤとしてシステム登録される。

【0159】

ＩＤ連携を完了すると、ＩＤ連携管理部３０４は、ＩＤ連携処理の結果を「ＩＤ連携成功」に設定する（ステップＳ２０９）。

【0160】

ＩＤ連携管理部３０４は、ＩＤ連携処理の結果をサービスサーバ３０に通知する（ステップＳ２１０）。ＩＤ連携に成功した場合には、ＩＤ連携管理部３０４は、肯定応答をサービスサーバ３０に送信する。ＩＤ連携に失敗した場合には、ＩＤ連携管理部３０４は、否定応答をサービスサーバ３０に送信する。

【0161】

所在情報管理部３０５は、サービス事業者から取得する所在情報を管理する手段である。所在情報管理部３０５は、各サービスサーバ３０から取得した所在情報を所在情報データベースに記憶する（図１８参照）。図１８に示すように、所在情報データベースは、個人識別コード、事業者コード、データ種類を対応付けて記憶する。なお、図１８に示す所在情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、所在情報が登録された日時等が所在情報データベースに登録されていてもよい。

【0162】

データ流通制御部３０６は、利用者の蓄積データ（サービス事業者が保持するユーザデータ）のデータ流通を制御する手段である。例えば、データ流通制御部３０６は、「共有」に関するデータ流通を制御する。

【0163】

データ流通制御部３０６は、サービスサーバ３０から共有要請を受信する。共有要請には、データ取得の対象となる利用者の個人識別コード、事業者コード、データ共有先が取得を希望するデータ種類、データ共有先（データ送信先）の情報等が含まれる。

【0164】

データ流通制御部３０６は、共有要請に含まれる個人識別コード、事業者コードに基づいてデータ流通の対象者を特定する。具体的には、データ流通制御部３０６は、図１４に示す利用者情報データベースを参照し、当該対象者を特定する。

【0165】

データ流通制御部３０６は、特定された利用者の個人識別コードと共有要請に含まれるデータ種類を用いて必要なデータを蓄積しているサービス事業者を特定する。具体的には、データ流通制御部３０６は、図１８に示す所在情報データベースを参照し、共有要請に含まれるデータ種類に対応するデータを蓄積するサービス事業者を特定する。

【0166】

データ流通の対象者と流通させるデータの蓄積者が特定されると、データ流通制御部３０６は、データ流通対象者に対してデータ共有の問い合わせを行う。なお、データ共有の問合せには、データ共有の要請元、データ蓄積者、データ共有されるデータ種類等の情報が含まれる。

【0167】

データ流通制御部３０６は、データ共有の問合せに対する応答を端末４０から受信する。

【0168】

利用者がデータ共有を拒否している場合には、データ流通制御部３０６は、データ共有不可をデータ共有要請元に通知する。利用者がデータ共有に同意した場合には、データ流通制御部３０６は、データ蓄積者に対して共有指示を送信する。

【0169】

共有指示には、データ蓄積者が生成した個人識別コードと、データ共有先に関する情報と、データ共有する対象のデータ種類と、が含まれる。

【0170】

記憶部３０７は、流通制御サーバ２０の動作に必要な情報を記憶する。記憶部３０７は、システムアカウントにログインする利用者を認証するための生体情報を少なくとも記憶する。記憶部３０７には、利用者情報データベースが構築される。さらに、記憶部３０７は、サービス事業者の名称と事業者コードを対応付けて記憶するデータベース等が構築される。

【0171】

［サービスサーバ］
図１９は、第１の実施形態に係るサービスサーバ３０の処理構成（処理モジュール）の一例を示す図である。図１９を参照すると、サービスサーバ３０は、通信制御部４０１と、顧客管理部４０２と、共有要請部４０３と、データ蓄積部４０４と、データ流通部４０５と、記憶部４０６と、を備える。

【0172】

通信制御部４０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部４０１は、流通制御サーバ２０からデータ（パケット）を受信する。また、通信制御部４０１は、流通制御サーバ２０に向けてデータを送信する。通信制御部４０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部４０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部４０１を介して他の装置とデータの送受信を行う。通信制御部４０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0173】

顧客管理部４０２は、サービス事業者の顧客に関する制御、管理を行う手段である。具体的には、顧客管理部４０２は、利用者のサービスアカウントを生成したり、利用者のログインに関する制御を行ったりする。さらに、顧客管理部４０２は、ＩＤ連携に関する制御、管理を行う。

【0174】

顧客管理部４０２は、利用者がＷＥＢページ上で所定の動作を行うと、連携コードを取得するためのＧＵＩ等を端末４０に表示する。例えば、顧客管理部４０２は、図２０に示すような表示を行う。

【0175】

連携コードを取得すると、顧客管理部４０２は、当該取得した連携コード、利用者の個人識別ＩＤ及び事業者コードを含む「ＩＤ連携要求」を流通制御サーバ２０に送信する。

【0176】

顧客管理部４０２は、ＩＤ連携要求に対する応答（肯定応答、否定応答）を流通制御サーバ２０から受信する。顧客管理部４０２は、ＩＤ連携の結果（ＩＤ連携成功、ＩＤ連携失敗）を利用者に通知する。

【0177】

また、顧客管理部４０２は、ＩＤ連携に成功した利用者が利用する端末４０のアドレスをＩＤ連携済のアドレスとして記憶する。具体的には、顧客管理部４０２は、ＩＤ連携完了済リストに端末４０のアドレスを追加する。

【0178】

顧客管理部４０２は、利用者のサービスアカウントへのログインを処理する。顧客管理部４０２は、利用者のログインに関する操作を処理する際、ＩＤ連携完了済リストを参照し、ＩＤ連携済の端末４０からのログイン要求か否か判定する。

【0179】

ＩＤ連携未完了の端末４０からのログイン要求であれば、顧客管理部４０２は、利用者の端末４０にログイン情報の提供を求める。即ち、顧客管理部４０２は、サービス事業者独自の方法により利用者の認証を行う。

【0180】

ＩＤ連携完了済の端末４０からのログイン要求であれば、顧客管理部４０２は、認証要求を流通制御サーバ２０に送信する。顧客管理部４０２は、流通制御サーバ２０からの応答（肯定応答、否定応答）を受信する。顧客管理部４０２は、流通制御サーバ２０からの応答に応じた動作を行う。このように、顧客管理部４０２は、ＩＤ連携済の利用者に関するログイン処理については、情報流通システムに認証リダイレクトを行うことで、利用者にシステムアカウントへのログインと同等の手順の実施を求める。

【0181】

なお、顧客管理部４０２によるサービスアカウント生成に関する動作の詳細は説明を省略する。当該動作は当業者にとって明らかなためである。

【0182】

顧客管理部４０２は、新規な顧客にサービスを提供する際には、当該顧客の個人識別ＩＤを生成してもよい。あるいは、顧客管理部４０２は、サービス事業者の職員等が生成した個人識別ＩＤを取得してもよい。

【0183】

共有要請部４０３は、利用者のデータに関する「共有」を情報流通事業者に要請する手段である。共有要請部４０３は、サービス事業者の職員等の操作に応じて、共有要請を流通制御サーバ２０に送信する。具体的には、共有要請部４０３は、データ取得の対象となる利用者の個人識別コード、自装置の事業者コード、取得を希望するデータ種類、データ共有先の情報等を含む共有要請を流通制御サーバ２０に送信する。

【0184】

データ蓄積部４０４は、利用者のユーザデータ（利用者にサービスを提供した結果生じるデータ又は利用者にサービスを提供するために必要なデータ）を蓄積する手段である。データ蓄積部４０４は、利用者の個人識別コードとユーザデータを対応付けて蓄積データベースに記憶する（図２１参照）。

【0185】

図２１に示すように、データ蓄積部４０４は、発生したデータの種類に応じたフィールドに発生データの情報を記憶する。なお、図２１は、ヘルスケア事業者のサービスサーバ３０－１に構築された蓄積データベースの一例を示す。

【0186】

データ蓄積部４０４は、データを蓄積データベースに記憶するたびに所在情報を流通制御サーバ２０に送信する。例えば、個人識別コード「ＨＬ２１」の利用者のユーザデータを取得すると、個人識別コード「ＨＬ２１」、事業者コード「ヘルスケア事業者」、データ種類「運動時間」を含む所在情報が流通制御サーバ２０に送信される。

【0187】

データ流通部４０５は、「共有」によるデータ流通を実現する手段である。データ流通部４０５は、流通制御サーバ２０から受信した「共有指示」を処理する。

【0188】

共有指示を受信すると、データ流通部４０５は、蓄積データベースを参照し、共有指示に含まれる個人識別コード、データ種類に対応するエントリを特定する。例えば、個人識別コード「ＨＬ２１」、データ種類「睡眠時間」を含む共有指示を受信した場合には、データ流通部４０５は、図２１の最上段に示されるエントリを特定する。

【0189】

データ流通部４０５は、特定されたエントリの対応するデータ種類フィールドに記載された蓄積データを共有指示で指定されたデータ共有先に送信する。

【0190】

記憶部４０６は、サービスサーバ３０の動作に必要な情報を記憶する。

【0191】

［端末］
端末４０には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。端末４０は、利用者の操作を受け付け、ポータルサーバ１０等と通信可能であれば任意の機器、デバイスとすることができる。

【0192】

例えば、端末４０は、流通制御サーバ２０から生体情報提供要求を受信すると、顔画像を促すようなＧＵＩ（所謂、自撮りを促すＧＵＩ）を表示し、利用者の生体情報を取得する。端末４０は、取得した生体情報を生体情報提供要求に対する応答として流通制御サーバ２０に送信する。

【0193】

また、端末４０の構成等は当業者にとって明らかであるので、詳細な説明を省略する。

【0194】

［システムの動作］
続いて、第１の実施形態に係る情報流通システムの動作について説明する。

【0195】

図２２は、第１の実施形態に係る情報流通システムの動作の一例を示すシーケンス図である。図２２を参照し、ＩＤ連携を実現する際のシステム動作を説明する。

【0196】

サービスサーバ３０は、ＩＤ連携の希望者から連携コードを取得する（ステップＳ３０１）。

【0197】

連携コードを取得すると、サービスサーバ３０は、ＩＤ連携要求を流通制御サーバ２０に送信する（ステップＳ３０２）。

【0198】

ＩＤ連携要求を受信すると、流通制御サーバ２０は、ＩＤ連携希望者の端末４０に生体情報提供要求を送信する（ステップＳ３０３）。

【0199】

生体情報提供要求の受信に応じて、端末４０は、利用者の生体情報を取得し、当該取得した生体情報（顔画像）を流通制御サーバ２０に送信する（ステップＳ３０４）。

【0200】

流通制御サーバ２０は、連携コードを用いて特定した利用者の生体情報と端末４０から提供された生体情報を用いた生体認証を実行する（ステップＳ３０５）。

【0201】

生体認証に成功すると、流通制御サーバ２０は、ＩＤ連携を実行する（ステップＳ３０６）。

【0202】

流通制御サーバ２０は、ＩＤ連携の結果をサービスサーバ３０に通知する（ステップＳ３０７）。

【0203】

サービスサーバ３０は、ＩＤ連携の結果を利用者に通知する（ステップＳ３０８）。

【0204】

このように、ポータルサーバ１０は、利用者から個人識別ＩＤに関するＩＤ連携の手続きを受け付けると、流通制御サーバ２０に連携コードの発行を要求する。流通制御サーバ２０は、利用者のシステムアカウントと紐付いた連携コードを生成し、生成された連携コードをポータルサーバ１０に送信する。ポータルサーバ１０は、送信された連携コードを利用者に通知する。

【0205】

サービスサーバ３０は、ＩＤ連携を希望する利用者から連携コードを取得し、個人識別ＩＤと当該取得した連携コードを含むＩＤ連携要求を流通制御サーバ２０に送信する。流通制御サーバ２０は、ＩＤ連携要求に含まれる連携コードからＩＤ連携を希望する利用者を特定すると共に、当該特定された利用者に対して生体情報の提供を要求する。流通制御サーバ２０は、当該要求に応じて取得した生体情報とシステムアカウントに記憶された生体情報を用いた生体認証を行い、前記生体認証に成功した場合に、個人識別ＩＤとユーザＩＤを対応付ける。

【0206】

以上のように、第１の実施形態に係る情報流通システムでは、連携コードを用いてサービスアカウントの個人識別ＩＤとシステムアカウントのユーザＩＤの連携を実現する。このようなＩＤ連携によって、サービス事業者が蓄積したデータをデータ流通の対象とすることができる。また、第１の実施形態では、ＩＤ連携の完了したサービス事業者からサービスの提供を受ける際、利用者にはシステムアカウントにログインする際の手続きと同様の手続きを要求する。その結果、認証強度や本人確認強度が低いサービス事業者が蓄積したデータに対して高い信頼性を与えることができる。

【0207】

具体的には、図２３に示すように、情報流通システムのシステムアカウントを生成する際には、身元確認書類による本人確認が行われており、当該アカウントの利用者に対する本人確認強度は高い。また、利用者がシステムアカウントにログインする際には、ＩＤ認証及び生体認証の組み合わせといった多要素認証が用いられるため、被認証者を認証する際の認証強度も高い。例えば、１次照合としてＩＤとパスワードを用いた照合が行われ、２次照合として生体情報を用いた照合（認証）が行われるため、高い強度の認証が行われる。対して、サービス事業者（例えば、ヘルスケア事業者）のアカウント生成時には本人確認が行われず本人確認強度は低い。また、サービス事業者のサービスアカウントにログインする際には、ＩＤとパスワードを用いたＩＤ認証が実施されるだけであり被認証者に対する認証強度も低い。第１の実施形態では、ＩＤ連携の完了したサービス事業者からサービスの提供を受ける際には（サービスアカウントにログインする際には）、シングルサインオンを用いて流通制御サーバ２０が被認証者を認証する。その結果、サービス事業者を利用する利用者の認証強度及び本人確認強度を確保し、当該サービス事業者が蓄積したデータの信頼性を高める。

【0208】

上記説明したように、サービスの提供にあたり、高い本人確認性や認証強度を求めないサービス事業者が蓄積したユーザデータを活用するためには、当該データを蓄積するサービス事業者（サービス提供組織）による認証の信頼性を高める必要がある。具体的には、当該サービス事業者の提供するサービスサーバ３０にアクセスする際の認証セキュリティレベルと本人確認性レベルをシステムアカウントと同等に引き上げる必要がある。当該引き上げのため、第１の実施形態では、サービス事業者からサービスの提供を受ける際（例えば、ヘルスケア事業者が提供する健康アプリを使用する際には）、当該健康アプリの認証要求は情報流通システムにリダイレクトされる。情報流通システムが、健康アプリの認証要求を処理する（多要素認証を実行する）。その結果、健康アプリを利用する際の認証セキュリティレベルは、個人ポータルを利用する際のレベルにまで引き上げられる。また、連携コードを使ったＩＤ連携の際に生体認証が実行されることで、健康アプリを利用する人物と個人ポータルを利用する人物の本人確認が行われる。その結果、健康アプリを利用する際の本人確認性レベルは、個人ポータルを利用する際のレベルまで引き上げられる。

【0209】

このように、例えば、ヘルスケア事業者が提供するようなアプリケーション（健康アプリケーション）は、ＩＤとパスワードを用いた認証を行うことがあっても、生体認証を行うことはないので認証強度が低い。対して、第１の実施形態に係る情報流通システムでは、利用者が健康アプリケーションを使用する際、サービスアカウントとシステムアカウントが連携し、利用者には生体認証が要求される。そのため、健康アプリケーションのようなアプリケーションを使用する際の認証強度を高くすることが可能となり、ヘルスケア事業者などのサービス事業者が蓄積したユーザデータを活用できる。

【0210】

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

【0211】

第１の実施形態では、利用者がサービスの提供を受ける際、サービス事業者が管理するサービスアカウントにログインが必要な場合のＩＤ連携について説明した。第２の実施形態では、病院のようなサービスを受ける際に、ログイン等が不要なサービス事業者の個人識別ＩＤを連携する場合について説明する。

【0212】

以下、第１の実施形態と第２の実施形態の相違点を中心に説明する。

【0213】

図２４は、第２の実施形態に係る情報流通システムの概略構成の一例を示す図である。図２４に示すように、第２の実施形態に係る情報流通システムは、病院の内部に設置された病院端末５０と、病院の外部に設置されたサービスサーバ３０－３と、を含む。

【0214】

病院端末５０は、第２のサービスを提供するサービス事業者（病院）の職員が使用し、第３のＩＤと利用者の本人確認情報を対応付けて記憶する端末である。具体的には、病院端末５０は、患者の個人情報（氏名、生年月日等）、個人識別ＩＤ（例えば、診察券番号や健康保険証番号）等を記憶する。病院端末５０は受付窓口等に設置される。病院職員（医療課等の病院スタッフ）は、病院端末５０を使用して業務を行う。病院端末５０は、カメラ装置を備え、ネットワークに接続可能に構成されている。

【0215】

図２５は、第２の実施形態に係る病院端末５０の処理構成（処理モジュール）の一例を示す図である。図２５を参照すると、病院端末５０は、通信制御部５０１と、ＩＤ連携指示処理部５０２と、記憶部５０３と、を備える。

【0216】

病院端末５０は、病院職員の操作に応じて、システムアカウントのユーザＩＤと病院の個人識別ＩＤに関する処理を実行する。

【0217】

通信制御部５０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部５０１は、サービスサーバ３０－３からデータ（パケット）を受信する。また、通信制御部５０１は、サービスサーバ３０－３に向けてデータを送信する。通信制御部５０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部５０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部５０１を介して他の装置とデータの送受信を行う。通信制御部５０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0218】

ＩＤ連携指示処理部５０２は、病院職員からのＩＤ連携に関する指示を処理する手段である。ＩＤ連携指示処理部５０２の詳細は後述する。

【0219】

記憶部５０３は、病院端末５０の動作に必要な情報を記憶する。記憶部５０３には、患者の情報を記憶する患者情報データベースが構築されている。患者情報データベースは、患者の本人確認情報（個人情報；氏名、生年月日等）、個人識別ＩＤ（診察券番号等）を記憶する。

【0220】

サービスサーバ３０－３（第４のサーバ装置）は、利用者に第２のサービス（医療サービス）を提供するために必要な個人識別ＩＤ（診察券番号等）と利用者に提供される第２のサービスに関するデータを蓄積する。サービスサーバ３０－３は、患者のユーザデータ（例えば、病名等の診察結果）のデータ流通サービスの運営に必要なデータを記憶するサーバ装置（運営サーバ）である。

【0221】

サービスサーバ３０－３は、病院の運営に必要な運営ポータルを提供する。サービスサーバ３０－３は、患者（利用者）の個人識別ＩＤ及びデータ流通の対象となるユーザデータ（病名等）を対応付けて記憶する。

【0222】

また、サービスサーバ３０－３は、ＩＤ連携に関する機能を備える。即ち、サービスサーバ３０－３は、患者の蓄積データをデータ流通の対象とするため、当該患者の個人識別ＩＤ（例えば、診察券番号）をシステムに登録する機能を備える。なお、第１の実施形態とは異なり、利用者は、直接、サービスサーバ３０－３にアクセスすることはできない。

【0223】

図２６は、第２の実施形態に係るサービスサーバ３０－３の処理構成（処理モジュール）の一例を示す図である。図２６を参照すると、第１の実施形態に係るサービスサーバ３０の構成に照合部４０７が追加されている。

【0224】

また、サービスサーバ３０－３は、ＩＤ連携機能（顧客管理部４０２）の動作が第１の実施形態のサービスサーバ３０と異なる。また、サービスサーバ３０－３は、ＩＤ連携希望者の情報を記憶するＩＤ連携対象者データベースを備える。

【0225】

病院が発行した個人識別ＩＤをＩＤ連携の対象とする場合、利用者は、端末４０を操作してシステムアカウントにログインする。利用者は、ＩＤ連携の手続きをする際、ＩＤ連携を希望する病院を選択する。

【0226】

ポータルサーバ１０のＩＤ連携制御部２０４は、利用者が入力したサービス事業者の情報に応じて、流通制御サーバ２０に対する要求を変更する。具体的には、第１の実施形態で説明したように、利用者がサービスの提供を受ける際、サービスアカウントへのログインが必要なサービス事業者については、ＩＤ連携制御部２０４は、連携コードの発行を流通制御サーバ２０に要求する。

【0227】

対して、第２の実施形態のように、利用者がサービスの提供を受ける際、サービスアカウントへのログインが不要なサービス事業者（病院など）については、ＩＤ連携制御部２０４は、利用者の本人確認情報の送信を流通制御サーバ２０に要求（依頼）する。具体的には、ＩＤ連携制御部２０４は、利用者のユーザＩＤ及びサービス事業者（病院）の事業者コードを含む「本人確認情報送信依頼」を流通制御サーバ２０に送信する（図２７のステップＳ５１）。

【0228】

なお、ＩＤ連携制御部２０４は、事業者コードと、サービス事業者のサービス提供形態（サービスアカウントへのログイン要否）と、を対応付けたテーブル情報等を参照することで、上記流通制御サーバ２０に対する要求の切り替えを行う。

【0229】

本人確認情報送信依頼を受信すると、流通制御サーバ２０のＩＤ連携管理部３０４は、ユーザＩＤに基づいて利用者情報データベースを検索し、対応する利用者を特定する。ＩＤ連携管理部３０４は、特定した利用者のユーザＩＤ、本人確認情報（例えば、氏名又は氏名と生年月日の組み合わせ）及び生体情報（例えば、顔画像）を病院のサービスサーバ３０－３に送信する（ステップＳ５２）。

【0230】

サービスサーバ３０－３は、受信したユーザＩＤ、本人確認情報及び生体情報をＩＤ連携対象者データベースに記憶する。

【0231】

システムアカウント（ポータルサーバ１０）上でＩＤ連携のための手続きを終えた利用者は、病院を訪れる。利用者は、病院の受付窓口や会計窓口において、ＩＤ連携の希望を病院職員に伝える（図２８参照）。

【0232】

病院職員は、病院端末５０に対し、ＩＤ連携のための処理を指示する。当該指示に応じて、ＩＤ連携指示処理部５０２は、面前の利用者（ＩＤ連携を希望する利用者）の生体情報を取得する。ＩＤ連携指示処理部５０２は、取得した生体情報（顔画像）を含む「照合要求」を病院のサービスサーバ３０－３に送信する（ステップＳ６１）。

【0233】

サービスサーバ３０－３の照合部４０７は、照合要求に含まれる生体情報とＩＤ連携対象者データベースに記憶された生体情報を用いた照合処理（１対Ｎ照合；Ｎは正の整数、以下同じ）を実行し、病院を訪れたＩＤ連携希望者を特定する。照合部４０７は、特定した利用者の本人確認情報（例えば、氏名又は氏名と生年月日の組み合わせ）及びユーザＩＤを病院端末５０に送信する（ステップＳ６２）。

【0234】

病院端末５０のＩＤ連携指示処理部５０２は、サービスサーバ３０－３から取得した本人確認情報をキーとして患者情報データベースを検索することで、ＩＤ連携希望者の候補（候補者）を抽出する。ＩＤ連携指示処理部５０２は、抽出したＩＤ連携希望の候補者に関する情報を病院職員に提示する。

【0235】

例えば、ＩＤ連携指示処理部５０２は、候補者が１人の場合、図２９Ａに示すようなＧＵＩを表示する。候補者が複数の場合、ＩＤ連携指示処理部５０２は、図２９Ｂに示すようなＧＵＩを表示する。

【0236】

図２９Ａ及び図２９Ｂに示すように、ＩＤ連携指示処理部５０２は、面前の利用者を撮影することで得られる顔画像と、本人確認情報を用いて抽出された候補者の個人識別ＩＤと、を表示する。その際、同姓同名の患者が登録されていることなどが原因で複数の候補者が特定された場合には、ＩＤ連携指示処理部５０２は、当該複数の候補者の個人識別ＩＤを表示すると共に、病院職員が複数の候補なかからＩＤ連携希望者を選択可能なＧＵＩを表示する。

【0237】

ＩＤ連携指示処理部５０２は、ＩＤ連携希望候補者が１人の場合には、患者情報データベースを検索して得られた個人識別ＩＤ、ユーザＩＤ及び事業者コードを含むＩＤ連携要求を流通制御サーバ２０に送信する（図２８のステップＳ６３）。

【0238】

ＩＤ連携希望者が複数の場合には、病院職員は、ＩＤ連携希望者が受付や会計時に提出した診察券等を確認し、図２９Ｂに示すＧＵＩ上で当該診察券等に記載された診察券番号（個人識別ＩＤ）を選択する。

【0239】

ＩＤ連携指示処理部５０２は、病院職員が選択した個人識別ＩＤ等を含むＩＤ連携要求を流通制御サーバ２０に送信する（図２８のステップＳ６３）。

【0240】

流通制御サーバ２０のＩＤ連携管理部３０４は、ＩＤ連携要求に含まれるユーザＩＤに基づいてＩＤ連携希望者を特定する。ＩＤ連携管理部３０４は、特定した利用者について、取得した事業者コードの個人識別ＩＤを設定する。

【0241】

ＩＤ連携の処理を終了すると、流通制御サーバ２０は、処理結果をポータルサーバ１０に通知する（図２７のステップＳ５３）。ポータルサーバ１０は、ＩＤ連携の結果（ＩＤ連携成功、ＩＤ連携失敗）を利用者に通知する。その際、ポータルサーバ１０は、ＩＤ連携が完了した個人識別ＩＤを利用者に通知してもよい。

【0242】

利用者は、ポータルサーバ１０から通知された結果を確認する。その際、利用者は、ＩＤ連携が完了した個人識別ＩＤ（診察券番号等）を確認し、自らの個人識別ＩＤと異なっていれば、個人識別ＩＤの訂正をポータルサーバ１０に要求してもよい。例えば、利用者は、正しい個人識別ＩＤをポータルサーバ１０に入力してもよい。この場合、ポータルサーバ１０が、個人識別ＩＤを含むＩＤ連携要求を流通制御サーバ２０に送信してもよい。

【0243】

このように、ポータルサーバ１０は、利用者から病院等の個人識別ＩＤ（第３のＩＤ）に関するＩＤ連携の手続きを受け付けると、流通制御サーバ２０に対してＩＤ連携を希望する利用者の本人確認情報の送信を依頼する。流通制御サーバ２０は、当該依頼に応じて、ＩＤ連携を希望する利用者の本人確認情報と生体情報をサービスサーバ３０－３（第４のサーバ装置）に送信する。病院端末５０は、ＩＤ連携を希望する利用者の生体情報を含む照合要求をサービスサーバ３０－３に送信する。サービスサーバ３０－３は、病院端末５０から取得した生体情報と流通制御サーバ２０から取得した生体情報を用いてＩＤ連携を希望する利用者を特定し、特定された利用者の本人確認情報を病院端末５０に送信する。病院端末５０は、サービスサーバ３０－３から取得した本人確認情報に対応する個人識別ＩＤを含むＩＤ連携要求を流通制御サーバ２０に送信する。

【0244】

病院端末５０は、サービスサーバ３０－３から取得した本人確認情報に対応する個人識別ＩＤとＩＤ連携を希望する利用者の生体情報（顔画像）を病院職員に提示する。その際、病院端末５０は、サービスサーバ３０－３から取得した本人確認情報に対応する候補者が複数の場合、当該複数の候補者に関する個人識別ＩＤを病院職員に提示する。病院端末５０は、複数の個人識別ＩＤのなかから病院職員が選択した個別識別ＩＤを含むＩＤ連携要求を流通制御サーバ２０に送信する。

【0245】

以上のように、第２の実施形態では、病院等が蓄積したデータ（医療データ）を活用するため、病院が管理する個人識別ＩＤ（診察券番号等）をシステムに登録する。利用者がＩＤ連携を希望すると、ポータルサーバ１０は、流通制御サーバ２０に対し、当該ＩＤ連携希望者の本人確認情報を病院のサービスサーバ３０－３に送信するように依頼する。ＩＤ連携希望者の生体情報が病院端末５０で取得され、病院端末５０は、当該生体情報を用いた照合をサービスサーバ３０－３に要求する。サービスサーバ３０－３は、生体情報を用いた照合処理によりＩＤ連携希望者を特定し、その本人確認情報を病院端末５０に送信する。病院端末５０は、サービスサーバ３０－３から通知された本人確認情報と、患者情報データベースの本人確認情報（病院が保管する保険証の券面事項）と、を用いてＩＤ連携希望者を特定する。即ち、病院端末５０は、本人確認情報を用いた１次照合を行う。氏名等の重複により複数のＩＤ連携希望者が抽出された場合には、病院端末５０は、複数のＩＤ希望連携者からなる候補リストを病院職員に提示する。病院職員は、提示された候補リストとＩＤ連携希望者が提示する診察券等を用いて、２次照合を行い、最終的なＩＤ連携対象患者を特定する。このように、第２の実施形態では、１次照合として生体情報を用いた照合（認証）が行われ、２次照合として病院職員の目視による照合が行われる。また、候補リストには、個人識別ＩＤ（診察券番号等）が含まれるため、病院職員は当該番号を入力することなく、ＩＤ連携希望者を特定できる。そのため、病院職員にはほとんど負荷がかからない。病院端末５０は、ＩＤ連携希望者の個人識別ＩＤを含むＩＤ連携要求を流通制御サーバ２０に通知する。流通制御サーバ２０は、通知された個人識別ＩＤに関するＩＤ連携を行う。

【0246】

上記説明したように、サービスアカウントへのログインが不要な病院等が管理するデータを利用する場合、システムアカウントへのログインが必要となる（多要素認証が実行される）。そのため、病院の蓄積データ（医療データ）を利用する際の認証セキュリティレベルは、情報流通システムを利用する際のレベルにまで引き上げられる。なお、病院では、診察券を作成する際に対面で本人確認（患者の顔の確認）が行われており、本人確認性レベルは本来的に高い。この点では、問題がない。しかし、システムのユーザＩＤと個人識別ＩＤを連携する際、診察券番号をシステムに入力することを病院職員に求めると、当該職員の負荷が増加する。当該問題点に関し、第２の実施形態では、病院端末５０が、自動的に診察券番号を特定するので、ＩＤを突き合わせる必要がなくなり病院職員の負荷が低減する。

【0247】

続いて、情報流通システムを構成する各装置のハードウェアについて説明する。図３０は、流通制御サーバ２０のハードウェア構成の一例を示す図である。

【0248】

流通制御サーバ２０は、情報処理装置（所謂、コンピュータ）により構成可能であり、図３０に例示する構成を備える。例えば、流通制御サーバ２０は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

【0249】

但し、図３０に示す構成は、流通制御サーバ２０のハードウェア構成を限定する趣旨ではない。流通制御サーバ２０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、流通制御サーバ２０に含まれるプロセッサ３１１等の数も図３０の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１が流通制御サーバ２０に含まれていてもよい。

【0250】

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

【0251】

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

【0252】

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

【0253】

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

【0254】

流通制御サーバ２０の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

【0255】

なお、ポータルサーバ１０、サービスサーバ３０等も流通制御サーバ２０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は流通制御サーバ２０と相違する点はないので説明を省略する。

【0256】

情報処理装置である流通制御サーバ２０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで流通制御サーバ２０の機能が実現できる。また、流通制御サーバ２０は、当該プログラムにより流通制御サーバ２０の制御方法を実行する。

【0257】

［変形例］
なお、上記実施形態にて説明した情報流通システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。

【0258】

上記実施形態では、ポータルサーバ１０がシステムアカウントに関するインターフェイスとなる場合について説明した。しかし、ポータルサーバ１０の全部又は一部の機能は流通制御サーバ２０が担ってもよい。情報流通システムは、ポータルサーバ１０を含まなくともよい。即ち、端末４０と流通制御サーバ２０が、「連携コード発行要求」や「ＩＤ連携要求」を直接、送受信してもよい。

【0259】

上記実施形態では、流通制御サーバ２０が、利用者を管理する機能（アカウント生成、ログイン管理）とデータ流通を制御する機能を備える場合について説明した。しかし、これらの機能は異なるサーバ装置で実現されていてもよい。具体的には、利用者を管理する管理サーバ２１と、データ流通を制御する制御サーバ２２と、がシステムに含まれていてもよい（図３１参照）。この場合、管理サーバ２１は、所謂、ｅＫＹＣ（electronic Know Your Customer）サーバとして動作する。管理サーバ２１と制御サーバ２２の構成、動作等は、上記第１及び第２の実施形態に係る動作から明らかなため説明を省略する。

【0260】

上記実施形態では、情報流通システムが採用する多要素認証として、ＩＤとパスワードを用いた認証と生体情報を用いた認証を例にとり説明を行った。しかし、多要素認証は、ＩＤ認証と生体認証に限定されないことは当然である。例えば、情報処理システムは、メールアドレスに検証用のＵＲＬ（Uniform Resource Locator）を含むメールを送信するメールアドレス認証（端末認証）を採用してもよい。

【0261】

上記実施形態では、生体情報として顔画像を用いる場合について説明した。しかし、生体情報は、顔画像から生成された特徴量であってもよい。例えば、システムアカウント生成時に顔画像の代わりに特徴量が登録さてもよい。

【0262】

さらに、情報流通システムは、顔画像や特徴量以外の生体情報を活用してもよい。即ち、生体情報には、例えば、顔、指紋、声紋、静脈、網膜、瞳の虹彩の模様（パターン）といった個人に固有の身体的特徴から計算されるデータ（特徴量）が例示される。あるいは、生体情報は、顔画像、指紋画像等の画像データであってもよい。生体情報は、利用者の身体的特徴を情報として含むものであればよい。

【0263】

上記実施形態では、流通制御サーバ２０は、数字や文字の組み合わせからなる文字列を連携コードして生成し、利用者に発行することを説明した。その際、流通制御サーバ２０は、上記文字列が変換された２次元コードを連携コードとして利用者に発行してもよい。即ち、利用者に発行される連携コードは、図２０に示すような文字列に限定されない。

【0264】

上記実施形態では、流通制御サーバ２０の内部に利用者情報データベースが構成される場合について説明したが、当該データベースは外部のデータベースサーバ等に構築されてもよい。即ち、流通制御サーバ２０の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「ＩＤ連携管理部（ＩＤ連携管理手段）」、「データ流通制御部（データ流通制御手段）」等がシステムに含まれるいずれかの装置に実装されていればよい。

【0265】

各装置（ポータルサーバ１０、流通制御サーバ２０等）間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、利用者の個人情報等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。

【0266】

上記説明で用いた流れ図（フローチャート、シーケンス図）では、複数の工程（処理）が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

【0267】

上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。

【0268】

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、利用者に提供されるサービスに関する蓄積データを流通する情報流通システムなどに好適に適用可能である。

【0269】

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、第１のサーバ装置と、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、第２のサーバ装置と、
を含み、
前記第２のサーバ装置は、前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、システム。
［付記２］
前記利用者による前記第２のアカウントへのログイン要求を受け付け、前記利用者の認証を前記第２のサーバ装置に要求する、第３のサーバ装置をさらに含み、
前記第２のサーバ装置は、前記利用者について多要素認証を実行し、前記多要素認証の結果を前記第３のサーバ装置に通知する、付記１に記載のシステム。
［付記３］
前記第２のサーバ装置は、前記第２のアカウントにログインする前記利用者を認証するための生体情報を少なくとも記憶する、付記２に記載のシステム。
［付記４］
前記第３のサーバ装置は、前記利用者から前記第１のＩＤに関するＩＤ連携の手続きを受け付けると、前記第２のサーバ装置に連携コードの発行を要求し、
前記第２のサーバ装置は、前記利用者の前記第２のアカウントと紐付いた前記連携コードを生成し、前記生成された連携コードを前記第３のサーバ装置に送信し、
前記第３のサーバ装置は、前記送信された連携コードを前記利用者に通知する、付記３に記載のシステム。
［付記５］
前記第１のサーバ装置は、前記ＩＤ連携を希望する利用者から前記連携コードを取得し、前記第１のＩＤと前記取得した連携コードを含むＩＤ連携要求を前記第２のサーバ装置に送信し、
前記第２のサーバ装置は、
前記ＩＤ連携要求に含まれる連携コードから前記ＩＤ連携を希望する利用者を特定すると共に、前記特定された利用者に対して生体情報の提供を要求し、
前記要求に応じて取得した生体情報と前記第２のアカウントに記憶された生体情報を用いた生体認証を行い、前記生体認証に成功した場合に、前記第１のＩＤと前記第２のＩＤを対応付ける、付記４に記載のシステム。
［付記６］
前記利用者に第２のサービスを提供するために必要な第３のＩＤと前記利用者に提供される前記第２のサービスに関するデータを蓄積する、第４のサーバ装置と、
前記第２のサービスを提供するサービス事業者の職員が使用し、前記第３のＩＤと前記利用者の本人確認情報を対応付けて記憶する、端末と、
をさらに含み、
前記端末は、前記職員の操作に応じて、前記第２のＩＤと前記第３のＩＤの連携に関する処理を実行する、付記２に記載のシステム。
［付記７］
前記第３のサーバ装置は、前記利用者から前記第３のＩＤに関するＩＤ連携の手続きを受け付けると、前記第２のサーバ装置に対して前記ＩＤ連携を希望する利用者の本人確認情報の送信を依頼し、
前記第２のサーバ装置は、前記依頼に応じて、前記ＩＤ連携を希望する利用者の本人確認情報と生体情報を前記第４のサーバ装置に送信し、
前記端末は、前記ＩＤ連携を希望する利用者の生体情報を含む照合要求を前記第４のサーバ装置に送信し、
前記第４のサーバ装置は、前記端末から取得した生体情報と前記第２のサーバ装置から取得した生体情報を用いて前記ＩＤ連携を希望する利用者を特定し、前記特定された利用者の本人確認情報を前記端末に送信し、
前記端末は、前記第４のサーバ装置から取得した本人確認情報に対応する前記第３のＩＤを含むＩＤ連携要求を前記第２のサーバ装置に送信する、付記６に記載のシステム。
［付記８］
前記端末は、
前記第４のサーバ装置から取得した本人確認情報に対応する前記第３のＩＤと前記ＩＤ連携を希望する利用者の生体情報を前記職員に提示する、付記７に記載のシステム。
［付記９］
前記端末は、前記第４のサーバ装置から取得した本人確認情報に対応する複数の前記第３のＩＤを前記職員に提示し、
前記複数の第３のＩＤのなかから前記職員が選択した第３のＩＤを含む前記ＩＤ連携要求を前記第２のサーバ装置に送信する、付記７又は８に記載のシステム。
［付記１０］
前記多要素認証は、ＩＤとパスワードを用いた認証と、生体情報を用いた認証と、を含む、付記１乃至９のいずれか一項に記載のシステム。
［付記１１］
前記生体情報は、顔画像又は前記顔画像から生成された特徴量である、付記１０に記載のシステム。
［付記１２］
第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、通信制御部と、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する、データ流通制御部と、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける、ＩＤ連携管理部と、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、ログイン管理部と、
を備える、サーバ装置。
［付記１３］
第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置において、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御し、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付け、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する、サーバ装置の制御方法。
［付記１４］
第１のアカウントにログインした利用者に第１のサービスを提供するために必要な第１のＩＤを記憶し、前記利用者に提供される第１のサービスに関するデータを蓄積する、サーバと通信する、サーバ装置に搭載されたコンピュータに、
第２のアカウントにログインした前記利用者について、前記蓄積されたデータのデータ流通を制御する処理と、
前記第１のアカウントで管理される第１のＩＤと前記第２のアカウントで管理される第２のＩＤを対応付ける処理と、
前記第１のＩＤと前記第２のＩＤが対応付けられた後は、前記利用者が前記第１のアカウントにログインする際、前記第２のアカウントにログインする手続きと同じ手続きを前記利用者に要求する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

【0270】

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。

【符号の説明】

【0271】

１０ ポータルサーバ
２０ 流通制御サーバ
２１ 管理サーバ
２２ 制御サーバ
３０ サービスサーバ
３０－１ サービスサーバ
３０－２ サービスサーバ
３０－３ サービスサーバ
４０ 端末
５０ 病院端末
１０１ 第１のサーバ装置
１０２ 第２のサーバ装置
２０１ 通信制御部
２０２ アカウント生成制御部
２０３ ログイン制御部
２０４ ＩＤ連携制御部
２０５ 記憶部
３０１ 通信制御部
３０２ アカウント管理部
３０３ ログイン管理部
３０４ ＩＤ連携管理部
３０５ 所在情報管理部
３０６ データ流通制御部
３０７ 記憶部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 顧客管理部
４０３ 共有要請部
４０４ データ蓄積部
４０５ データ流通部
４０６ 記憶部
４０７ 照合部
５０１ 通信制御部
５０２ ＩＤ連携指示処理部
５０３ 記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】