JP7761146B2 - システム及び方法 - Google Patents

Description

本発明は、システム及び方法に関する。

病院などに保有されている個人情報を、個人の同意に基づき事業者などの情報提供先の装置に提供する情報流通システムが存在する。

例えば、特許文献１には、個人の希望に応じたプライバシー保護を実現するパーソナルデータ提供システム、提供方法及び情報処理装置を提供する、と記載されている。特許文献１のパーソナルデータ提供システムは、複数の情報処理装置を有する。複数の情報処理装置の各々は、第１送信部と、符号化部と、を備える。第１送信部は、個人の識別子の符号化方式についての問い合わせを、各個人の端末に送信する。符号化部は、各個人の端末から受信した、問い合わせに対する応答に基づき、各個人の識別子を符号化して各個人の符号を生成し、各個人のパーソナルデータに当該個人の符号を対応付ける。

特開２０１８－１２８８８４号公報

特許文献１に開示された情報流通システム（データ流通システム）においてユーザデータを第三者に提供可能とするためには、ユーザデータの発生に寄与した利用者の同意が必要となる。ここで、パーソナルデータ取引市場において、提供対象のパーソナルデータは複数のデータ提供元に跨って蓄積されていることがある。

この場合、データ提供先に提供されるデータに同一人物のデータであることを示すＩＤを付与する必要がある。このようなＩＤが存在しなければ、データ提供先は、取得したデータの利活用が行えない。

データに付与するＩＤとして、個人が知っている識別子（情報流通システムから払い出されたユーザＩＤ）の使用が考えられる。このような識別子を使用すると、データ利活用事業者は、複数のデータ提供申込で得られたユーザデータを対応付けることが可能になる。その結果、利用者のプライバシーが漏洩する可能性がある。

また、個人が知っている識別子が使用されると、当該個人によるＩＤの管理が不十分な場合、プライバシー漏洩のリスクが高まる。即ち、データ提供元とデータ提供先のＩＤ管理が十分なものであっても、個人によるＩＤ管理が不十分な場合、プライバシー漏洩のリスクが高まる。

本発明は、情報流通システムに参加する利用者のプライバシーを保護することに寄与する、システム及び方法を提供することを主たる目的とする。

本発明の第１の視点によれば、取引サーバと、サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、前記データ提供を制御する、流通制御サーバと、を含み、前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信する、システムが提供される。

本発明の第２の視点によれば、取引サーバと、サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、前記データ提供を制御する、流通制御サーバと、を含むシステムにおいて、前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信する、方法が提供される。

本発明の各視点によれば、情報流通システムに参加する利用者のプライバシーを保護することに寄与する、システム及び方法が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

図１は、一実施形態の概要を説明するための図である。 図２は、一実施形態の動作の一例を示すフローチャートである。 図３は、第１の実施形態に係る情報流通システムの概略構成の一例を示す図である。 図４は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図５は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図６は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図７は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図８は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図９は、第１の実施形態に係るカタログ情報の一例を示す図である。 図１０は、第１の実施形態に係るデータ提供申込の一例を示す図である。 図１１は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図１２Ａ、図１２Ｂ及び図１２Ｃは、第１の実施形態に係るデータ提供契約の一例を示す図である。 図１３は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図１４は、第１の実施形態に係るデータ提供状況情報の一例を示す図である。 図１５は、第１の実施形態に係る情報流通システムの動作を説明するための図である。 図１６は、第１の実施形態に係る流通制御サーバの処理構成の一例を示す図である。 図１７は、第１の実施形態に係る利用者情報データベースの一部の一例を示す図である。 図１８は、第１の実施形態に係る所在情報データベースの一例を示す図である。 図１９は、第１の実施形態に係る同意管理データベースの一例を示す図である。 図２０は、第１の実施形態に係るサービスサーバの処理構成の一例を示す図である。 図２１は、第１の実施形態に係る顧客情報データベースの一例を示す図である。 図２２は、第１の実施形態に係る取引サーバの処理構成の一例を示す図である。 図２３は、第１の実施形態に係る口座開設者リストの一例を示す図である。 図２４は、第１の実施形態に係る端末の処理構成の一例を示す図である。 図２５は、第１の実施形態に係る情報流通システムの動作の一例を示すシーケンス図である。 図２６は、本願開示に係る取引サーバのハードウェア構成の一例を示す図である。

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

一実施形態に係るシステムは、取引サーバ１０１と、サービスサーバ１０２と、データ利活用サーバ１０３と、流通制御サーバ１０４と、を含む（図１参照）。サービスサーバ１０２は、サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する。データ利活用サーバ１０３は、データ利活用事業者により運営され、少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、所定の要件を含むデータ提供申込を取引サーバに送信する。流通制御サーバ１０４は、データ提供を制御する。取引サーバ１０１は、データ提供申込を流通制御サーバ１０４に送信する（図２のステップＳ１）。流通制御サーバ１０４は、所定の要件を満たすデータを指定する情報と、利用者のＩＤであってデータ提供申込に対応して生成された対象者ＩＤと、を含む提供指示をサービスサーバ１０２に送信する（ステップＳ２）。サービスサーバ１０２は、指定されたデータと対象者ＩＤをデータ利活用サーバ１０３に送信する（ステップＳ３）。

上記システムにおいて、流通制御サーバ１０４は、データ提供元であるサービスサーバ１０２に対し、データ提供の対象データ（データ提供先が求める所定の要件を満たすデータ）と共にデータ提供申込に対応する対象者ＩＤを送信するように指示する。即ち、流通制御サーバ１０４は、データ提供申込ごとに異なる対象者ＩＤを生成し、当該対象者ＩＤを利用者のＩＤとして送信するようにサービスサーバ１０２に指示する。このような構成により、データ利活用事業者が、複数のデータ提供申込で得られたユーザデータを不当に対応付けることが防止される。また、提供されたユーザデータは、個人が把握することができない対象者ＩＤによって管理される。利用者自身から対象者ＩＤが漏洩することはないため、当該利用者のプライバシーは保護される。

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

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

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

情報流通事業者は、サービス事業者に蓄積されたパーソナルデータのデータ流通サービス（情報流通サービス）のプラットフォームを提供する事業者である。情報流通事業者は、事業者（サービス事業者、データ利活用事業者）間のデータ流通を制御する。情報流通事業者は、流通制御サーバ１０を備える。

流通制御サーバ１０は、情報流通事業者により運営される。流通制御サーバ１０は、サービス事業者間のデータ流通を制御（実現）したり、サービス事業者とデータ利活用事業者の間のデータ流通を制御したりするサーバ装置である。流通制御サーバ１０は、サービス事業者が保持するデータの情報流通サービスを実現する。

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

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

データ利活用事業者は、個人に直接サービスを提供しない主体である。データ利活用事業者には、製薬会社のような事業者が例示される。例えば、製薬会社は、サービス事業者から取得したデータを用いて新薬を開発する。

なお、本願開示では、個人にサービスを提供しない主体を「データ利活用事業者」と扱い説明を行うが、データ利活用事業者が利用者にサービスを提供する際には「サービス事業者」として振る舞うのは当然である。即ち、データ利活用事業者の業務形態によっては、当データ利活用事業者がサービス事業者にもなり得る。

データ利活用事業者は、サービス事業者からデータを取得し利活用するためのデータ利活用サーバ３０を備える。データ利活用サーバ３０は、データ利活用事業者により運営される。データ利活用サーバ３０は、少なくとも１以上のユーザデータをサービスサーバ２０からデータ提供により取得する。

取引事業者は、サービス事業者とデータ利活用事業者の間の取引を実現する主体である。取引事業者は、データ生成者（サービス事業者）とデータ消費者（データ利活用事業者）の間のデータ流通を実現する。取引事業者は、サービス事業者とデータ利活用事業者の間のデータ流通取引の仲介を行う事業者である。

取引事業者は、当該データ流通の実現のための取引サーバ４０を備える。取引サーバ４０は、取引事業者により運営される。取引サーバ４０は、サービス事業者とデータ利活用事業者の間のデータ提供契約に関する制御を行う。

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

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

図３に示す構成は例示であって、本願開示の情報流通システムの構成等を限定する趣旨ではない。例えば、情報流通事業者には２台以上の流通制御サーバ１０が含まれていてもよい。また、取引事業者やデータ利活用事業者に関し、システムに参加している事業者の数に応じたデータ利活用サーバ３０や取引サーバ４０が情報流通システムに含まれる。

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

利用者は、サービスの提供を受けたいサービス事業者と個別に契約を締結する。例えば、利用者は、氏名等をサービス事業者に提供しつつ当該サービス事業者と新たな契約（サービスを享受するための契約）をしたい旨を申し出る。

例えば、病院を受診したい利用者は、氏名等が記載された健康保険証等を当該病院に提出する。あるいは、オンラインショッピングに係るサービスを提供するＥＣ（Electronic Commerce）事業者については、利用者は、当該ＥＣ事業者が運営するサービスサーバ２０にアクセスしアカウントを生成する。

サービス事業者は、新規な顧客（利用者）を識別するための「個人識別ＩＤ」を生成する。例えば、病院は、利用者（患者）を管理するための診察券番号を採番し、当該診察券番号を個人識別ＩＤとして生成する。ＥＣ事業者は、顧客を管理するための会員番号等を個人識別ＩＤとして生成する。サービスサーバ２０は、生成した個人識別ＩＤ（例えば、診察券番号や会員番号等）をデータベース等に記憶する。

個人識別ＩＤが生成されると、利用者は、サービス事業者からサービスの提供を受けることができる。例えば、利用者は病院から医療サービス（健康診断や診察等）を受ける。あるいは、利用者は、ＥＣ事業者を利用してオンラインショッピングを行う。

サービス事業者が利用者にサービスを提供したこと等で生じたユーザデータを、データ流通の対象とするためには、データの「蓄積」が必要になる。データ蓄積は、サービス事業者（ユーザデータの提供元）が、ユーザデータを第三者に提供可能なデータとして情報流通システムに登録することである。

流通制御サーバ１０は、データ蓄積者（サービス事業者）から利用者に提供されるサービスに関するデータをデータ流通の対象とするためのデータ蓄積を制御する。即ち、流通制御サーバ１０は、ユーザデータを第三者に提供可能なデータとして情報流通システムに登録するためのデータ蓄積を制御する。蓄積されたデータがデータ流通の対象となる。

情報流通システムにおけるデータ流通の手段として「共有」と「提供」が存在する。流通制御サーバ１０は、データ蓄積により登録されたユーザデータを一のサービスサーバ２０から他のサービスサーバ２０に共有するためのデータ共有を制御する。流通制御サーバ１０は、データ蓄積により登録されたユーザデータをサービスサーバ２０からデータ利活用サーバ３０に提供するためのデータ提供を制御する。

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

「共有」は、サービス利用者自身の利便性の向上に用いられるため、利用者にデータ流通に対する対価（利用者に対する対価）は支払われない。「共有」は、利用者がサービス事業者からより良いサービスの提供を受けるため他のサービス事業者が蓄積したデータを活用するために使用されるためである。

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

「提供」は、利用者に直接サービスを提供しないデータ利活用事業者が用いる手段のため、データ流通に対する対価（利用者に対する対価）が発生する。即ち、「提供」が行われると、利用者に対して対価が支払われる。また、「提供」が行われると、データ取得者（データ提供先）からデータ提供元（データ蓄積者）及び情報流通システム（情報流通事業者）に対して対価が支払われる。

なお、本願開示では、便宜上、取引事業者には対価（手数料）が発生しないものとして説明する。実際には、データ提供先からデータ提供元等に支払われる対価の一部が取引事業者に「手数料」として支払われてもよい。

流通制御サーバ１０は、データ共有先（データの供給を受けるサービス事業者）が蓄積されたデータを取得するためのデータ共有を制御する。流通制御サーバ１０は、データ提供先（データの供給を受けるデータ利活用事業者）が蓄積されたデータを取得するためのデータ提供を制御する。

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

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

利用者は、システムアカウント生成のための操作（例えば、所定ボタンの押下）を行い、システムアカウントを生成する。その際、流通制御サーバ１０は、利用者のシステムアカウント生成に必要な情報を取得する。具体的には、流通制御サーバ１０は、利用者のログイン情報（ログインＩＤ、パスワード）や個人情報（氏名、生年月日、連絡先、口座情報等）を取得する。

ログイン情報、個人情報等を取得すると、流通制御サーバ１０は、当該利用者を情報流通システムにおいて一意に識別するためのユーザＩＤ（Identifier）を生成する。

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

流通制御サーバ１０は、生成したユーザＩＤを利用者（端末５０）に払い出す。端末５０は、払い出されたユーザＩＤを記憶する。

＜ＩＤの連携＞
上述のように、サービス事業者が保持するユーザデータをデータ流通の対象とするためには、「データ蓄積」が必要となる。データ蓄積を実現するためには、システムアカウントのＩＤ（ユーザＩＤ）とサービス事業者が生成したＩＤ（個人識別ＩＤ）を連携する必要がある。

例えば、図４に示すように、利用者は病院の窓口において、当該病院が保持するユーザデータの活用を希望している旨を病院職員に伝える（データ活用の申し込みを行う）。病院職員は、利用者の個人特定情報、利用者の個人識別ＩＤ（例えば、診察券番号）及び事業者コードを病院端末６０に入力する。

なお、個人特定情報は、利用者を特定するための情報である。個人特定情報には、利用者の氏名、又は、氏名と生年月日の組み合わせ等が例示される。

また、事業者コードは、情報流通システムに参加するサービス事業者を識別するための識別情報（ＩＤ）である。例えば、病院とＥＣ事業者には異なるコードが割り当てられる。事業者コードは、任意の手段によりシステム参加者（情報流通事業者、サービス事業者、データ利活用事業者）の間で共有される。例えば、サービス事業者が情報流通システムに参加する際、情報流通事業者が当該サービス事業者に割り当てる事業者コードを生成する。情報流通事業者は、当該生成した事業者コードをサービス事業者等に通知する。

病院端末６０は、取得した個人特定情報、個人識別ＩＤ及び事業者コードを含む「ＩＤ連携要求」を流通制御サーバ１０に送信する。

あるいは、ＥＣ事業者のユーザデータの活用を希望する利用者は、端末５０を操作して、当該ＥＣ事業者のサービスサーバ２０にアクセスする（図５参照）。利用者は、ＥＣ事業者のアカウントにログインし、当該アカウント上でデータ活用のための申請を行う。当該申請に応じて、サービスサーバ２０は、利用者の個人特定情報、個人識別ＩＤ及び事業者コードを含む「ＩＤ連携要求」を流通制御サーバ１０に送信する。

流通制御サーバ１０は、病院端末６０やサービスサーバ２０からＩＤ連携希望者の個人特定情報、個人識別ＩＤ及びＩＤ連携の対象となるサービス事業者（例えば、病院、ＥＣ事業者）の事業者コードを取得する。

流通制御サーバ１０は、事業者コードからＩＤ連携の対象となっているサービス事業者を特定する。また、流通制御サーバ１０は、個人特定情報からシステムアカウントに登録された利用者を特定する。流通制御サーバ１０は、当該特定した利用者のアカウントにおいてサービス事業者と個人識別ＩＤを対応付ける。

個人識別ＩＤがシステムアカウントに登録されると（ＩＤ連携が完了すると）、ＩＤ連携の対象となったサービス事業者は、データ活用を希望する利用者のユーザデータを「蓄積」可能となる。

＜データ蓄積＞

サービス事業者は、利用者にサービスを提供すると、当該利用者の個人識別ＩＤとユーザデータ（パーソナルデータ）を対応付けて記憶する。例えば、病院は、利用者の診察を行い病名が得られると、当該利用者の個人識別ＩＤ（診察券番号等）と病名（例えば、胃がん等の具体的な病名）を対応付けて記憶する。例えば、サービスサーバ２０は、「顧客情報データベース」を用いて利用者の個人識別ＩＤとユーザデータを対応付けて記憶する。なお、顧客情報データベースの詳細は後述する。

サービス事業者のサービスサーバ２０は、ＩＤ連携の完了した利用者（データ活用の申し込みをした利用者）に関し、ユーザデータ（サービス提供の結果生じるデータ、サービスの提供に必要なデータ）を記憶するたびにデータ蓄積に関する制御を行う。

具体的には、サービスサーバ２０は、利用者のユーザデータを蓄積データ（データ流通対象のユーザデータ）として情報流通システムに登録する。具体的には、サービスサーバ２０は、ＩＤ連携の完了した利用者に関する「所在情報」を流通制御サーバ１０に送信する（図６参照）。

所在情報は、ユーザデータの保管場所（データの蓄積主体；サービス事業者）等に関する情報である。所在情報には、ユーザデータ（蓄積データ）を識別するためのデータＩＤ、個人識別ＩＤ、事業者コード、保持するデータの種類等が含まれる。

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

＜データ共有＞
他のサービス事業者が蓄積したデータ（他のサービス事業者が利用者にサービスを提供した結果生じたユーザデータ）の取得を希望するサービス事業者は、「共有」によって当該データを取得する。

ここでは、図７を参照しつつ、ＥＣ事業者Ｂが、病院Ａに蓄積された利用者のデータ（診察結果；病名）を「共有」により取得する場合について説明する。なお、病院はサービスサーバ２０－１を備え、ＥＣ事業者はサービスサーバ２０－２を備える。

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

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

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

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

利用者の同意が得られれば、流通制御サーバ１０は、データ共有元（病院Ａ）に対して共有指示を送信する（ステップＳ１４）。

共有指示を受信した病院Ａ（サービスサーバ２０－１）は、顧客情報データベースを参照し、対象となる利用者の診察結果（病名）等を指定されたデータ共有先であるサービスサーバ２０－２に送信する（ステップＳ１５）。

続いて、「提供」によるデータ流通について説明する。

＜口座開設＞
データ提供により対価を取得しようとする利用者は、取引事業者に口座を開設する必要がある。図８を参照しつつ、提供のための口座開設について説明する。

取引事業者は、情報流通システムに参加する複数のサービス事業者のうち少なくとも１以上のサービス事業者と提携を行う。例えば、医療に関するデータを取り扱う取引事業者は、医療機関（病院、薬局等）と提携する。あるいは、教育に関するデータを取り扱う取引事業者は、教育事業者と提携する。取引事業者は、提携先のサービス事業者に関する事業者コードを記憶する。

また、取引事業者は、データ利活用事業者の事業者コードを記憶する。例えば、取引事業者は、データ利活用事業者と取引を開始する際に当該データ利活用事業者の事業者コードを生成する。データ利活用事業者の事業者コードは、任意の方法によって、情報流通事業者、取引事業者及びデータ利活用事業者の間で共有される。

取引事業者は、提携先のサービス事業者が保持するデータ（蓄積されたデータ）をデータ利活用事業者に販売する（販売の仲介をする）。例えば、図８に示す提携サービス事業者が医療機関であれば、取引事業者は、提携先の医療機関が保持するデータを製薬会社等に販売する。

上述のように、取引事業者を介したデータ提供により対価を取得したい利用者は、取引事業者（取引サーバ４０）に口座を開設する必要がある。情報流通システムに参加する利用者のうちデータ提供により収益を得たい利用者は、取引サーバ４０に「情報口座」を開設する。

利用者は、流通制御サーバ１０から払い出されたユーザＩＤを取引サーバ４０に提示し、情報口座を開設する。取引サーバ４０は、取得したユーザＩＤを記憶する。取引サーバ４０は、口座開設した利用者のユーザＩＤを口座開設者リストにより管理する。

＜カタログ情報＞
「提供」によるデータ流通を実現するため、情報流通事業者はカタログ情報を用意する。情報流通事業者の担当者（システム管理者）は、販売可能なデータを記載したカタログ情報を定義する（図９参照）。カタログ情報は、情報流通システムがデータ利活用事業者に販売可能なデータの詳細を示す情報である。

図９に示すカタログ情報に含まれるデータセット名は、カタログ情報を識別するための情報である。例えば、健康診断に関するデータセットには「検診結果１」、診察結果に関するデータセットには「診察結果１」といったデータセット名が付与される。

カタログ情報に含まれるデータ種類は、サービス事業者が保持しているデータ（第三者に提供可能な蓄積データ）の種類を示す。例えば、検診結果における「身長」、「体重」、「血圧」や診察結果における「病名」、「服薬」、「検査結果」等の情報がデータ種類に相当する。データフォーマットは、どのような形式でデータが提供されるのかを規定する。

データ利活用事業者は、取引事業者を介してカタログ情報を取得する。より具体的には、データ利活用サーバ３０は、取引サーバ４０に対して「カタログ情報提示要求」を送信する。

カタログ情報提示要求を受信すると、取引サーバ４０は、流通制御サーバ１０に対して「カタログ情報送信要求」を送信する。

カタログ情報送信要求の受信に応じて、流通制御サーバ１０は、情報流通事業者により定義されたカタログ情報を取引サーバ４０に送信する。

取引サーバ４０は、提携先のサービス事業者に関するカタログ情報を選択し、データ利活用サーバ３０に送信する。例えば、上記の例では、取引サーバ４０は、製薬会社の業務に関するカタログ情報を選択してデータ利活用事業者に送信する。データ利活用事業者は、受信したカタログ情報を閲覧し、自身の事業に必要なカタログ情報を特定する。

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

ここでは、製薬会社Ｄが、利用者の病名、検査結果、活動量を「提供」により取得する場合について説明する。病院Ａ、病院Ｂが利用者の病名、検査結果に関するユーザデータを保持し、フィットネスクラブＣが活動量に関するユーザデータを保持する。

データ提供先（製薬会社Ｄ）の職員等は、公開されているカタログ情報を参照しデータ提供申込を作成する。データ提供申込は、少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込である。

例えば、職員等は、データ利活用サーバ３０に図１０に示すようなデータ提供申込を入力する。データ提供申込の入力日は２０２１年１月１日とする。

データ提供申込には、データ提供概略情報と、提供データの要件と、提供対価提示と、が含まれる。

データ提供概略情報は、データ提供先（製薬会社Ｄ）が申し込むデータ提供の概略に関する情報である。データ提供概略情報には、データ提供を要請する事業者の情報、データ提供申込の目的、対象期間（データが蓄積された期間）、予算、締め切り日等が含まれる。

データ提供を要請する事業者（データ利活用事業者、例えば、製薬会社Ｄ）に関する情報は、当該事業者の名称、事業者コード、データの提供先（データの送信先アドレス）等を含む。

提供データの要件は、データ提供によりデータ利活用事業者に提供されるデータに関する要件である。提供データの要件には、対象者の情報、必要な対象者の人数、必要なデータの情報（データの種類、必要データ量を示す下限値と上限値）等が含まれる。

提供対価提示は、データ提供によりデータ利活用事業者が支払う提供対価の提示に関する詳細な情報である。提供対価提示には、データ提供先から支払われる、データ種類ごとの対価が含まれる。

図１１等を参照して、データ提供時の情報流通システムの動作を説明する。

はじめに、データ利活用サーバ３０は、データ提供申込を取引サーバ４０に送信する（ステップＳ２１）。

データ提供申込を受信した取引サーバ４０は、データ提供申込に提供申込ＩＤを付与し、当該受信したデータ提供申込を記憶する。その後、取引サーバ４０は、提供申込ＩＤ、データ提供申込と口座開設者リストを含む「提供要請」を流通制御サーバ１０に送信する（ステップＳ２２）。

取引サーバ４０は、データ提供申込に付与した提供申込ＩＤをデータ利活用サーバ３０に通知する。データ利活用サーバ３０は、通知された提供申込ＩＤと取引サーバ４０に送信したデータ提供申込を対応付けて記憶する。

流通制御サーバ１０は、提供要請の受信に応じて、データ提供元（データ蓄積者）の候補に関する通知とデータ提供に関する利用者の同意取得を行う。

＜データ提供元及び対象者の特定＞
流通制御サーバ１０は、データ提供申込に記載された提供データの要件に合致するユーザデータを保持するデータ提供元（サービス事業者）を特定する。具体的には、流通制御サーバ１０は、利用者情報データベース及び所在情報データベースを参照し、データ提供申込に記載された要件に合致する利用者（対象者）のデータを保持するデータ提供元を特定する。

図１０の例では、流通制御サーバ１０は、利用者情報データベースを参照し、２０歳から６５歳までの利用者であって口座開設者リストに記載された利用者を特定する。

流通制御サーバ１０は、所在情報データベースを参照し、特定された利用者のうちさらに提供データの要件に適合する対象者を特定する。図１０の例では、流通制御サーバ１０は、対象期間（２０１９年１月１日～２０２０年１２月３１日）に病名、１年に１回以上の検査による検査結果、１ヶ月に３回以上の活動量が登録されている利用者が特定される。

流通制御サーバ１０は、所在情報データベースを参照し、特定された利用者について、対象データ（提供データ）を保持するサービス事業者を特定する。上記の例では、病名及び検査結果を保持する病院Ａ、病院Ｂ、活動量を保持するフィットネスクラブＣが特定される。

流通制御サーバ１０は、特定された利用者、データ提供の対象となるデータのデータＩＤ、特定されたサービス事業者及び提供申込ＩＤを対応付けて記憶する。

流通制御サーバ１０は、特定したデータ提供元に関する情報を取引サーバ４０に通知する。具体的には、流通制御サーバ１０は、提供申込ＩＤ、特定したデータ提供元の名称、連絡先（サービスサーバ２０のアドレス）、データ提供元が蓄積するデータ種類等を含む「提供元通知」を取引サーバ４０に送信する（ステップＳ２３）。上記の例では、病院Ａ、病院Ｂが病名及び検査結果を蓄積し、フィットネスクラブＣが活動量を蓄積していることが取引サーバ４０に通知される。

＜データ提供契約に関する交渉＞
取引サーバ４０は、提供元通知を受信すると、流通制御サーバ１０により特定されたサービス事業者に対してデータ利活用事業者との間でデータ提供申込の契約締結を依頼する。

はじめに、取引サーバ４０は、データ提供申込を、提供元通知により通知されたデータ提供元ごとに分離する。具体的には、取引サーバ４０は、データ提供先と各データ提供元の間の個別のデータ提供契約（データ提供契約のドラフト）を生成する。

上記の例では、取引サーバ４０は、病名、検査結果に関するユーザデータを蓄積する病院Ａ向けのデータ提供契約として、図１２Ａに示すデータ提供契約を生成する。同様に、取引サーバ４０は、病名、検査結果に関するユーザデータを蓄積する病院Ｂ向けのデータ提供契約として、図１２Ｂに示すデータ提供契約を生成する。取引サーバ４０は、活動量に関するユーザデータを蓄積するフィットネスクラブＣ向けのデータ提供契約として、図１２Ｃに示すデータ提供契約を生成する。

図１２Ａ乃至図１２Ｃに示すように、データ提供契約には、データ提供先の情報、データ提供元の情報、提供データの種類及びその対価が含まれる。なお、図１２Ａ乃至図１２Ｃに示すデータ提供契約は、取引サーバ４０により作成されてもよいし、取引事業者の職員等により作成されてもよい。

取引サーバ４０は、各データ提供契約に提供契約ＩＤを付与する。取引サーバ４０は、データ提供契約と提供契約ＩＤを対応付けて記憶する。取引サーバ４０は、データ提供申込の提供申込ＩＤとデータ提供契約の提供契約ＩＤを対応付けて記憶する。

取引サーバ４０は、提供申込ＩＤ、個別の提供契約ＩＤ及びデータ提供契約を含む「提供契約締結依頼」を流通制御サーバ１０から通知された各連絡先（例えば、病院Ａ、病院Ｂ、フィットネスクラブＣのサービスサーバ２０）に送信する（ステップＳ２４）。

提供契約締結依頼を受信したことに応じて、データ提供元は、データ提供先（データ利活用事業者）とデータ提供に関する交渉を行う。データ提供元の職員等は、データ提供契約を検討した結果をサービスサーバ２０に入力する。サービスサーバ２０は、取得した検討結果に応じて提供契約締結依頼に対する応答を取引サーバ４０に送信する（ステップＳ２５）。

具体的には、データ提供契約に記載された条件（主に、データ提供に対する対価の提案）に同意すれば、データ提供元の職員は、その旨をサービスサーバ２０に入力する。サービスサーバ２０は、データ提供契約に応じる旨（データ提供契約を締結する旨）を示す肯定応答を取引サーバ４０に送信する。

データ提供契約に記載された条件に同意できなければ、データ提供元の職員は、その旨をサービスサーバ２０に入力する。サービスサーバ２０は、データ提供申込に応じない旨（データ提供契約を締結しない旨）を示す否定応答を取引サーバ４０に送信する。

肯定応答を受信した場合（データ提供契約が成立の場合）、取引サーバ４０は、データ提供契約が成立したことを記憶する。取引サーバ４０は、データ提供契約が成立したことを流通制御サーバ１０及びデータ利活用サーバ３０に通知する。具体的には、取引サーバ４０は、提供申込ＩＤ、個別の提供契約ＩＤ及びデータ提供契約を含む「個別契約成立通知」を流通制御サーバ１０及びデータ利活用サーバ３０に送信する（ステップＳ２６）。

否定応答を受信した場合（データ提供契約が不成立の場合）、取引サーバ４０は、データ提供契約が不成立であることをデータ利活用サーバ３０に通知する。取引サーバ４０は、提供申込ＩＤ、個別の提供契約ＩＤ及びデータ提供契約を含む「個別契約不成立通知」をデータ利活用サーバ３０に送信する（図１１に図示せず）。

データ提供契約が不成立の場合、データ利活用事業者の職員等は、データ提供契約を取り下げるか、条件を引き上げて再びデータ提供契約を申し込むか検討する。

データ提供契約を取り下げる場合には、データ利活用事業者の職員等は、その旨をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、提供申込ＩＤ及び個別の提供契約ＩＤを含む「個別契約取下通知」を取引サーバ４０に送信する（図１１に図示せず）。取引サーバ４０は、受信した個別契約取下通知を流通制御サーバ１０に転送する。

再びデータ提供契約に関する交渉を行う場合には、データ利活用事業者の職員等は、新たな条件を設定したデータ提供契約をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、新たなデータ提供契約を取引サーバ４０に送信する。

取引サーバ４０は、新たなデータ提供契約を含む提供契約締結依頼をサービスサーバ２０に送信する。データ提供元は、提示された新たな条件を検討し、検討結果を、取引サーバ４０を介してデータ提供先に通知する。データ提供元とデータ提供先は、上記のような価格交渉を繰り返す。

以降の説明では、病院Ａとデータ提供先（製薬会社Ｄ）の間でデータ提供契約が成立し、病院Ｂとデータ提供先との間では契約は成立せず、フィットネスクラブＣとデータ提供先との間で契約が成立した場合について説明する。

流通制御サーバ１０、データ利活用サーバ３０及び取引サーバ４０は、契約が成立したデータ提供契約と成立しないデータ提供契約を提供契約ＩＤ、提供申込ＩＤを用いて管理する。

＜利用者の同意取得＞
流通制御サーバ１０は、データ流通対象者を特定すると、当該対象者のデータ流通に対する同意を取得する。

流通制御サーバ１０は、利用者情報データベース、所在情報データベース等を用いて特定された利用者の連絡先（端末５０が受信可能なメールアドレス）にデータ提供に関する問合せを送信する（図１１のステップＳ２７）。

流通制御サーバ１０は、ユーザデータを保持するデータ提供元であって、データ提供先とのデータ提供契約が成立したデータ提供元に関し、データ提供に関する問合せを上記特定された利用者に対して行う。上記の例では、病院Ａ、フィットネスクラブＣのそれぞれが蓄積するユーザデータに関する、データ提供の問合せが送信される。

データ提供の問合せには、データ提供の要請元（上記の例では製薬会社Ｄ）の情報、データ提供元（病院Ａ、フィットネスクラブＣ）の情報、提供が要望されたデータ種類（例えば、病名、検査結果、活動量）が含まれる。

データ提供の問合せを受信した端末５０は、データ提供に関する利用者の意思を取得するためのＧＵＩを表示する。端末５０は、ＧＵＩを用いて、利用者の意思（データ提供に同意、不同意）を取得する。

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

流通制御サーバ１０は、利用者がデータ提供に同意すると、その旨を記憶する。その際、流通制御サーバ１０は、データ提供に同意した利用者を識別するための識別情報を生成する。より具体的には、流通制御サーバ１０は、データ提供申込ごとに異なる対象者ＩＤ（データ提供に同意した個人を識別するＩＤ）を生成する。流通制御サーバ１０は、提供申込ＩＤ、対象者ＩＤ及びユーザＩＤを対応付けて同意管理データベースに記憶する。同意管理データベースの詳細は後述する。

流通制御サーバ１０は、データ提供申込に記載された必要人数以上の同意が得られるまで、定期的又は所定のタイミングで上記データ提供の問合せを対象者の端末５０に送信する。例えば、流通制御サーバ１０は、データ提供を拒否した利用者に対しては、所定の日数が経過後、データ提供の問合せを行う。

このように、取引サーバ４０は、データ提供申込を含む提供要請を流通制御サーバ１０に送信する。流通制御サーバ１０は、所定の要件を満たすデータに対応する利用者が所持する端末５０に対し、データ提供の問合せを送信する。流通制御サーバ１０は、データ提供の問合せを端末５０に送信することで、データ利活用事業者が提供を望むユーザデータの発生に寄与した利用者の同意（データ提供に対する同意）を取得する。

利用者がデータ提供に同意すると、流通制御サーバ１０は、当該利用者の同意により提供されるデータ量を計算する。流通制御サーバ１０は、所在情報データベースを参照し、利用者が同意することで提供されるデータ量を把握する。

例えば、１人の利用者がデータ提供に同意することで、１件の病名、１０件の検査結果、１００件の活動量のようなデータ種類ごとの提供データが発生する。

利用者の同意が得られるたびに、流通制御サーバ１０は、計算したデータ量を取引サーバ４０に通知する。流通制御サーバ１０は、提供申込ＩＤ及び計算したデータ量を含む「提供データ量通知」を取引サーバ４０に送信する（図１３のステップＳ３１）。

取引サーバ４０は、データ提供の状況を示す「データ提供状況情報」を生成する。取引サーバ４０は、データ提供申込ごとにデータ提供状況情報を生成する。取引サーバ４０は、データ提供状況情報により、データ提供先に提供されるデータ種類ごとのデータ量、及び、データ提供が成立した場合にデータ提供先が支払う対価（対価の総額）を管理する。

例えば、取引サーバ４０は、提供データ量通知を受信したことに応じて、データ種類ごとのデータ量（蓄積量）を計算し、グラフ化する。同様に、取引サーバ４０は、データ提供先が支払う対価をグラフ化する。例えば、取引サーバ４０は、図１４に示すような時系列グラフをデータ提供状況情報として作成する。

取引サーバ４０は、生成したデータ提供状況情報（例えば、図１４に示すようなグラフ）を定期的又は所定のタイミングでデータ利活用サーバ３０に送信する（図１３に図示せず）。

このように、流通制御サーバ１０は、利用者がデータ提供に同意すると、利用者の同意により生じる、サービスサーバ２０からデータ利活用サーバ３０へ提供可能なデータのデータ量を取引サーバ４０に通知する。取引サーバ４０は、流通制御サーバ１０から受信した、サービスサーバ２０からデータ利活用サーバ３０へ提供可能なデータのデータ量に基づいて、データ提供申込の状況を示すデータ提供状況情報を生成する。取引サーバ４０は、生成されたデータ提供状況情報をデータ利活用サーバ３０に送信する。

＜データ提供申込のキャンセル＞
データ利活用事業者は、データ提供申込（データ提供申込から派生した全てのデータ提供契約）をキャンセルできる。データ利活用事業者の職員は、取引サーバ４０から取得したデータ提供状況情報を確認しつつ、データ提供申込を取り消すか継続するか決定する。即ち、データ利活用事業者は、図１４に示すような時系列グラフ（データ提供状況情報）を参照し、データ提供契約を継続するかキャンセルするか決定できる。

ただし、データ利活用事業者は、データ提供申込のキャンセルは無条件で行えない。データ利活用事業者は、キャンセル対象のデータ提供申込の提供データの要件が満たされているとデータ提供申込をキャンセルできない。

具体的には、データ提供先は、対象データの一部が必要データ量の下限を満たしていない時は、データ提供契約の締め切り日によらずデータ提供申込をキャンセルできる。即ち、データ利活用事業者（データ提供先）は、データ提供の締め切りに関わらず提供データの要件に規定されたデータの少なくとも１つが揃っていなければ、データ提供申込を任意のタイミングでキャンセルできる。

対して、データ提供先は、対象データの全てが必要データ量の下限を満たしている時は、データ提供申込の締め切り日によらずデータ提供申込をキャンセルできない。即ち、データ利活用事業者は、自ら申し込んだ提供データの要件が満たされている場合には、データ提供申込の締め切りに関わらずデータ提供申込をキャンセルできない。

このような対応により、データ提供先は、必要なデータが揃わないにも関わらず、対価を支払う必要がなくなる。その結果、データ提供先が保護される。また、データ提供先は、必要なデータを確保できた時点でデータ提供契約をキャンセルされることはない。その結果、データ提供先が保護される。

データ提供申込のキャンセルを希望するデータ利活用事業者の事業者は、その旨をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、データ提供申込のキャンセル希望を取得すると、その旨を取引サーバ４０に通知する。データ利活用サーバ３０は、提供申込ＩＤを含む「提供申込取消要求」を取引サーバ４０に送信する（図１３のステップＳ３２）。

提供申込取消要求を受信すると、取引サーバ４０は、データ提供申込の状況を確認し、データ提供申込のキャンセルが可能か否か判定する。取引サーバ４０は、判定結果に応じた応答をデータ利活用サーバ３０に送信する（ステップＳ３３）。

取引サーバ４０は、データ提供申込の状況がキャンセル可な状態であれば、データ提供申込のキャンセルを受け付ける旨の肯定応答をデータ利活用サーバ３０に送信する。取引サーバ４０は、データ提供申込の状況がキャンセル不可な状態であれば、データ提供申込のキャンセルを受け付けられない旨の否定応答をデータ利活用サーバ３０に送信する。

データ提供申込のキャンセルを受け付けた場合には、取引サーバ４０は、その旨を流通制御サーバ１０に通知する（図１３に図示せず）。流通制御サーバ１０は、キャンセルが通知されたデータ提供申込に関する情報等を破棄する。

このように、取引サーバ４０は、所定の要件（提供データの要件）を満たすデータが、サービスサーバ２０からデータ利活用サーバ３０へ提供可能になると、データ提供申込のキャンセルの要求を拒否する。当該所定の要件は、サービスサーバ２０からデータ利活用サーバ３０に提供される提供データごとのデータ種類と必要データ量の下限値を含む。取引サーバ４０は、提供データの各データ種類について、サービスサーバ２０からデータ利活用サーバ３０へ提供可能なデータのデータ量が必要データ量の下限値を超えた場合、データ提供申込のキャンセルの要求を拒否する。

＜データ提供の実行＞
取引サーバ４０は、所定の条件が満たされるとデータ提供を実行する。取引サーバ４０は、所定の条件が満たされると、流通制御サーバ１０に対し、データ提供の実行を指示する。取引サーバ４０は、所定の条件が満たされていない場合、データ提供申込を破棄してもよい。

例えば、取引サーバ４０は、データ提供申込に記載された締め切り日が到来し、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供を実行する。

取引サーバ４０は、データ提供申込の締め切り日が到来し、且つ、提供データの各データ種類について、サービスサーバ２０からデータ利活用サーバ３０へ提供可能なデータのデータ量が必要データ量の下限値を超えた場合、データ提供の実行を指示する。

即ち、データ提供申込に記載された各対象データの全てにおいて必要データ量の下限値以上のデータが提供可能な場合に、提供データ要件が満たされていると判定される。図１０の例では、５件以上の病名、２０件以上の検査結果、１０００件以上の活動量のデータが提供可能となった場合に、提供データの要件が満たされたと判定される。

この場合、取引サーバ４０は、提供申込ＩＤを含む「データ提供実行指示」を流通制御サーバ１０に送信する（図１５参照）。

データ提供実行指示を受信すると、流通制御サーバ１０は、データ提供に対する同意が得られている利用者に関し、データ提供元に提供指示を送信する（図１１のステップＳ２９）。

その際、流通制御サーバ１０は、同意管理データベースに記憶された対象者ＩＤを含む提供指示をデータ提供元に送信する。流通制御サーバ１０は、各データ提供元が独自に管理している個人識別ＩＤを対象者ＩＤに置き換えてデータ提供するようにサービスサーバ２０に指示する。

例えば、１０人の利用者の同意が得られていれば、流通制御サーバ１０は、当該１０人分のデータに関し、サービスサーバ２０に提供指示を送信する。例えば、流通制御サーバ１０は、病院Ａのサービスサーバ２０に対し、１０人分の病名、検査結果の提供指示を送信する。同様に、流通制御サーバ１０は、フィットネスクラブＣのサービスサーバ２０に対し、１０人分の活動量の提供指示を送信する。

このように、流通制御サーバ１０は、所定の要件を満たすデータ（提供対象のデータ）が複数のサービスサーバ２０に記憶されている場合、複数のサービスサーバ２０それぞれに、同一の対象者ＩＤを含む提供指示を送信する。

提供指示を受信したサービスサーバ２０は、顧客情報データベースを参照し、同意した利用者のユーザデータを指定されたデータ提供先に送信する（ステップＳ３０）。

その際、データ提供元のサービスサーバ２０は、ユーザデータと共に流通制御サーバ１０から通知された対象者ＩＤをデータ提供先に送信する。サービスサーバ２０は、データ流通対象者の個人識別ＩＤを流通制御サーバ１０により指定された対象者ＩＤに置き換えて、データ提供を行う。

データ提供先（データ利活用事業者）のデータ利活用サーバ３０は、各サービスサーバ２０から受信した対象者ＩＤに基づいて、当該各サービスサーバ２０から受信したユーザデータの対応付けを行う。データ利活用サーバ３０は、対象者ＩＤを用いてユーザデータの名寄せを行う。

このように、取引サーバ４０は、データ提供申込を流通制御サーバ１０に送信する。流通制御サーバ１０は、所定の要件を満たすデータを指定する情報（例えば、データＩＤ）と、利用者のＩＤであってデータ提供申込に対応して生成された対象者ＩＤと、を含む提供指示をサービスサーバ２０に送信する。サービスサーバ２０は、指定されたデータと対象者ＩＤをデータ利活用サーバ３０に送信する。

取引サーバ４０は、データ提供申込に記載された締め切り日が到来したが、データ提供申込に記載された提供データの要件が満たされていなければ、データ提供契約を破棄する。この場合、取引サーバ４０は、その旨を流通制御サーバ１０及びデータ利活用サーバ３０に通知する。

あるいは、取引サーバ４０は、データ提供申込の予算に基づいて、データ提供を実行してもよい。

取引サーバ４０は、データ利活用事業者がサービス事業者に支払う対価の総額が予算を超え、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供を実行する。

具体的には、取引サーバ４０は、利用者がデータ提供に同意することでデータ提供先が支払う対価がデータ提供申込に記載された予算を上回り、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供の実行を指示する。

対して、取引サーバ４０は、データ提供先が支払う対価がデータ提供申込に記載された予算を上回ったが、データ提供申込に記載された提供データの要件が満たされていなければ、データ提供申込を破棄する。

あるいは、取引サーバ４０は、対象データの少なくとも１つが必要データ量の上限を超え、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供を実行してもよい。即ち、取引サーバ４０は、提供データの少なくとも１つのデータ種類について、サービスサーバ２０からデータ利活用サーバ３０へ提供可能なデータのデータ量が必要データ量の上限値を超え、且つ、提供データの要件が満たされていれば、データ提供を実行する。

対して、取引サーバ４０は、対象データの少なくとも１つが必要データ量の上限を超えたが、データ提供申込に記載された提供データの要件が満たされていなければ、データ提供申込を破棄してもよい。

このように、取引サーバ４０は、締め切り日が到来した場合、データ提供先が支払う対価が予算を超過した場合、対象データの少なくとも１つが必要データ件数の上限を超えた場合等においてデータ提供を実行するか破棄するか決定する。

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

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

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

利用者登録部２０２は、上述の利用者登録（利用者のシステム登録）を実現する手段である。利用者登録部２０２は、利用者の端末５０から個人情報（氏名、生年月日、連絡先、口座情報等）を取得する。

利用者登録部２０２は、当該個人情報を取得すると、利用者を識別するためのユーザＩＤを生成する。例えば、利用者登録部２０２は、利用者のシステム登録のたびに一意な値を採番し、当該採番された値をユーザＩＤとして用いる。

利用者登録部２０２は、ユーザＩＤと個人情報を利用者情報データベースに記憶する（図１７参照）。なお、図１７に示すように、利用者情報データベースは、ユーザＩＤ、個人情報及びサービス事業者ごとの個人識別ＩＤを対応付けて記憶する。また、図１７に示す利用者情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、利用者登録された日時等が利用者情報データベースに登録されていてもよい。

利用者登録部２０２は、生成したユーザＩＤを端末５０に送信する。

ＩＤ連携部２０３は、上述のＩＤ連携を実現する手段である。ＩＤ連携部２０３は、サービス事業者の端末（例えば、病院端末６０）やサービスサーバ２０から「ＩＤ連携要求」を受信する。ＩＤ連携要求には、ＩＤ連携（サービス事業者の登録）を希望する利用者の個人特定情報、個人識別ＩＤ及び事業者コードが含まれる。

ＩＤ連携部２０３は、個人特定情報（利用者の氏名、氏名と生年月日の組み合わせ等）をキーとして利用者情報データベースを検索し、対応する利用者を特定する。ＩＤ連携部２０３は、当該特定された利用者の個人識別ＩＤフィールドのうち事業者コードに対応するフィールドにＩＤ連携要求に含まれる個人識別ＩＤを設定する。即ち、ＩＤ連携部２０３は、個人特定情報からシステムアカウントに登録された利用者を特定し、当該特定した利用者のアカウントにおいてサービス事業者と個人識別ＩＤを対応付ける。

所在情報管理部２０４は、サービス事業者から取得する所在情報を管理する手段である。所在情報管理部２０４は、サービス事業者が利用者にサービスを提供することで発生したユーザデータを第三者に提供可能なデータとして情報流通システムに登録するためのデータ蓄積を制御する。

所在情報管理部２０４は、各サービスサーバ２０から取得した所在情報を所在情報データベースに記憶する（図１８参照）。図１８に示すように、所在情報データベースは、個人識別ＩＤ、事業者コード、データＩＤ、データ種類、データ蓄積日等を対応付けて記憶する。

なお、図１８に示す所在情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。また、図１８を含む図面において、理解の容易のため、事業者コードをサービス事業者の名称を用いて表記している。

データ流通制御部２０５は、「共有」又は「提供」によるデータ流通を制御する手段である。

はじめに、「共有」に関するデータ流通について説明する。

データ流通制御部２０５は、サービスサーバ２０から共有要請を受信する。共有要請には、データ取得の対象となる利用者の個人識別ＩＤ、共有要請の送信元の事業者コード、取得を希望するデータ種類が含まれる。図７の例では、ＥＣ事業者Ｂ（サービスサーバ２０－２）が利用者に対して生成した個人識別ＩＤ、ＥＣ事業者Ｂの事業者コード、データ種類として「病名」が共有要請に含まれる。

データ流通制御部２０５は、共有要請に含まれる個人識別ＩＤ、事業者コードに基づいてデータ流通の対象者を特定する。具体的には、データ流通制御部２０５は、図１７に示す利用者情報データベースを参照し、当該対象者を特定する。上記の例では、ＥＣ事業者Ｂから「ＥＣ０１」の個人識別ＩＤを含む共有要請を受信すると、データ流通制御部２０５は、図１７に示す１行目のエントリから利用者Ｕ１がデータ流通の対象者であることを把握する。

その後、データ流通制御部２０５は、特定された利用者の個人識別ＩＤと共有要請に含まれるデータ種類を用いて必要なデータを蓄積しているサービス事業者を特定する。具体的には、データ流通制御部２０５は、図１８に示す所在情報データベースを参照し、共有要請に含まれるデータ種類に対応するデータを蓄積するサービス事業者を特定する。上記の例では、利用者Ｕ１の個人識別ＩＤ「ＨＬ０１」と共有要請に含まれるデータ種類「病名」に基づき、病院Ａが特定される。

利用者の個人識別ＩＤと共有要請に含まれるデータ種類の組み合わせが所在情報データベースに記憶されていない場合には、データ流通制御部２０５は、共有要請の送信元に対してデータ共有不可を示す否定応答を送信する。上記の例では、利用者Ｕ１の個人識別ＩＤ「ＨＬ０１」とデータ種類「病名」の組み合わせが所在情報データベースに登録されていなければ、否定応答がＥＣ事業者Ｂ（サービスサーバ２０－２）に送信される。

データ流通の対象者と流通させるデータの蓄積者が特定されると、データ流通制御部２０５は、データ流通対象者に対してデータ共有の問い合わせを行う。具体的には、データ流通制御部２０５は、データ流通対象者の連絡先に、データ共有に関する問合せを送信する。上記の例では、利用者Ｕ１が所持する端末５０に上記問合せが送信される。

なお、データ共有の問合せには、データ共有の要請元、データ蓄積者、データ共有されるデータ種類等の情報が含まれる。上記の例では、データ共有の要請元としてＥＣ事業者Ｂ、データ蓄積者として病院Ａ、データ共有されるデータ種類として「病名」がそれぞれ設定される。

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

利用者がデータ共有を拒否している場合には、データ流通制御部２０５は、データ共有不可をデータ共有要請元に通知する。上記の例では、データ流通制御部２０５は、ＥＣ事業者Ｂのサービスサーバ２０－２に対して共有要請に対する否定応答を送信する。

利用者がデータ共有に同意した場合には、データ流通制御部２０５は、データ蓄積者に対して共有指示を送信する。上記の例では、データ蓄積者である病院Ａのサービスサーバ２０－１に共有指示が送信される。

共有指示には、データ蓄積者が生成した個人識別ＩＤと、データ共有先に関する情報と、データ共有する対象のデータ種類と、が含まれる。上記の例では、利用者Ｕ１の個人識別ＩＤ「ＨＬ０１」と、ＥＣ事業者Ｂのサービスサーバ２０－２のアドレスと、データ種類「病名」を含む共有指示が病院Ａのサービスサーバ２０－１に送信される。

このように、データ流通制御部２０５は、データ共有に同意した利用者（対象者）の個人識別ＩＤであってデータ蓄積者が生成した個人識別ＩＤを含む共有指示を送信する。

続いて、「提供」に関するデータ流通について説明する。

データ流通制御部２０５は、取引サーバ４０から「提供要請」を受信する。提供要請には、提供申込ＩＤ、データ提供申込及び口座開設者リストが含まれる。

データ流通制御部２０５は、データ提供申込に記載された提供データの要件に合致するユーザデータを保持するデータ提供元（サービス事業者）を特定する。データ流通制御部２０５は、利用者情報データベース及び所在情報データベースを参照し、データ提供申込に記載された要件に合致する利用者（対象者）のデータを保持するデータ提供元を特定する。

図１０の例では、データ流通制御部２０５は、利用者情報データベースを参照し、２０歳から６５歳までの利用者であって口座開設者リストに記載された利用者を特定する。

その後、データ流通制御部２０５は、所在情報データベースを参照し、特定された利用者のうちさらに提供データの要件に適合する対象者を特定する。図１０の例では、データ流通制御部２０５は、対象期間（２０１９年１月１日～２０２０年１２月３１日）に病名、１年に１回以上の検査による検査結果、１ヶ月に３回以上の活動量が登録されている利用者を特定する。

データ流通制御部２０５は、所在情報データベースを参照し、特定された利用者について、対象データ（提供データ）を保持するサービス事業者を特定する。

図１８の例では、個人識別ＩＤ「ＨＬ０１」の利用者Ｕ１が上記特定された利用者に該当する場合には、データ流通制御部２０５は、病名、検査結果を保持する病院Ａを特定する。

また、利用者Ｕ１が病院Ｂを受診し、病名、検査結果がデータ提供の対象データとして所在情報データベースに登録されていれば、データ流通制御部２０５は、病名、検査結果を保持する病院Ｂを特定する。

同様に、個人識別ＩＤ「ＦＣ０１」の利用者が利用者Ｕ１であって上記特定された利用者に該当する場合には、データ流通制御部２０５は、活動量を保持するフィットネスクラブＣを特定する。

データ流通制御部２０５は、特定された利用者のユーザＩＤ、特定された利用者ごとの対象データのデータＩＤ、特定されたサービス事業者の事業者コード及び提供申込ＩＤを対応付けて記憶する。

データ流通制御部２０５は、特定したデータ提供元に関する情報を取引サーバ４０に通知する。具体的には、流通制御サーバ１０は、提供申込ＩＤ、特定したデータ提供元の名称、連絡先（サービスサーバ２０のアドレス）、データ提供元が蓄積するデータ種類等を含む「提供元通知」を取引サーバ４０に送信する。

データ流通制御部２０５は、情報流通事業者の職員等が流通制御サーバ１０に予め入力したデータ提供元の事業者コード、データ提供元の名称、連絡先等を対応付けて記憶するテーブル情報を参照し、上記データ提供元に関する情報を取得する。

データ流通制御部２０５は、取引サーバ４０から「個別契約成立通知」又は「個別契約取下通知」を受信する。データ流通制御部２０５は、これらの通知に含まれる提供契約ＩＤに基づいて、個別のデータ提供契約（データ提供先ごとの契約）の成立、不成立を管理する。

データ提供契約が成立すると、データ流通制御部２０５は、データ提供に対する対象者の同意を取得するための制御を行う。データ流通制御部２０５は、利用者情報データベース、所在情報データベース等を用いて特定された利用者の連絡先（端末５０が受信可能なメールアドレス）にデータ提供に関する問合せを送信する。

具体的には、データ流通制御部２０５は、データ提供契約が成立したデータ提供元に関し、データ提供の問合せを上記特定された利用者に対して行う。上述の例では、病院Ａと製薬会社Ｄの間でデータ提供契約が成立し、フィットネスクラブＣと製薬会社Ｄの間でデータ提供契約が成立している。従って、データ流通制御部２０５は、病院Ａ及びフィットネスクラブＣが保持するユーザデータに関するデータ提供の問合せをデータ流通対象者の端末５０に送信する。

データ提供の問合せには、データ提供の要請元（上記の例では製薬会社Ｄ）の情報、データ提供元（病院Ａ、フィットネスクラブＣ）の情報、提供が要望されたデータ種類（例えば、病名、検査結果、）が含まれる。

データ流通制御部２０５は、データ提供の問合せに対する応答を端末５０から受信する。利用者がデータ提供に同意しなければ、データ流通制御部２０５は、特段の対応をしない。

利用者がデータ提供に同意すると、データ流通制御部２０５は、データ提供申込ごとに、データ提供に同意した利用者を識別するための対象者ＩＤを生成する。例えば、データ流通制御部２０５は、データ提供申込の提供申込ＩＤとデータ提供に同意した利用者のユーザＩＤの連結値を計算する。データ流通制御部２０５は、計算した連結値のハッシュ値を対象者ＩＤとして生成する。

データ流通制御部２０５は、提供申込ＩＤ、データ提供に同意した利用者の対象者ＩＤ及びユーザＩＤを対応付けて同意管理データベースに記憶する（図１９参照）。なお、図１９に示す同意管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。

図１９を参照すると、「ＰＩＤ０１」のデータ提供申込には、２人の利用者が同意している。また、ユーザＩＤが「ＩＤ１１」の利用者は、「ＰＩＤ０１」と「ＰＩＤ０２」の２つのデータ提供申込に同意している。当該利用者には、異なる対象者ＩＤが付与されている。

また、利用者がデータ提供に同意すると、データ流通制御部２０５は、当該利用者の同意により提供される提供データのデータ量を計算する。

利用者が病院Ａに保持されたユーザデータの提供に同意した場合、データ提供申込の対象期間に蓄積された病名が１件、検査結果が３件といったデータ量が計算される。具体的には、データ流通制御部２０５は、所在情報データベースを参照し、対象期間にデータ提供元が上記利用者のユーザデータ（病名、検査結果）を蓄積した数をカウントする。

利用者の同意が得られるたびに、データ流通制御部２０５は、計算したデータ量を取引サーバ４０に通知する。流通制御サーバ１０は、提供申込ＩＤ及び計算したデータ量（データ種類ごとのデータ量）を含む「提供データ量通知」を取引サーバ４０に送信する。

なお、データ流通制御部２０５は、データ提供申込に記載された必要人数の同意が得られるまで、定期的又は所定のタイミングで上記データ提供の問合せを対象者の端末５０に送信する。

データ流通制御部２０５は、取引サーバ４０から「データ提供実行指示」を受信する。

データ提供実行指示を受信すると、データ流通制御部２０５は、データ提供に対する同意が得られている利用者に関し、各データ提供元に提供指示を送信する。例えば、１０人の利用者からデータ提供に対する同意が得られていれば、データ流通制御部２０５は、当該１０人の利用者に関し、各サービスサーバ２０に提供指示を送信する。

提供指示には、データ提供に同意した利用者の個人識別ＩＤと、対象者ＩＤと、データ提供先に関する情報（例えば、事業者名、事業者コード、データ利活用サーバ３０のアドレス）と、提供データを特定（指定）するための情報と、が含まれる。提供データを特定するための情報は、データＩＤであってもよいし、提供データの蓄積された期間及びデータ種類の組み合わせであってもよい。

なお、対象者ＩＤはデータ提供申込ごとに生成される。従って、異なるサービスサーバ２０に送信される提供指示であっても、同じデータ提供申込に起因する提供指示には同一の対象者ＩＤが含まれる。上記の例では、病院ＡとフィットネスクラブＣに送信される提供指示（同一の利用者に関する提供指示）には同じ対象者ＩＤが含まれる。

データ流通制御部２０５は、データ利活用事業者との間でデータ提供契約が締結されたサービス事業者からのデータ提供の同意を利用者から取得する。データ流通制御部２０５は、データ利活用事業者との間でデータ提供契約が締結され、且つ、利用者がデータ提供に同意しているサービス事業者のサービスサーバ２０に提供指示を送信する。

カタログ情報管理部２０６は、カタログ情報を管理する手段である。カタログ情報管理部２０６は、システム管理者が作成したカタログ情報を記憶部２０７に記憶する。

カタログ情報管理部２０６は、取引サーバ４０から「カタログ情報送信要求」を受信する。当該要求の受信に応じて、カタログ情報管理部２０６は、記憶部２０７に記憶されたカタログ情報を取引サーバ４０に送信する。

記憶部２０７は、流通制御サーバ１０の動作に必要な情報を記憶する。記憶部２０７には、利用者情報データベース等が構築される。

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

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

ＩＤ連携制御部３０２は、利用者のＩＤ連携に関する制御を行う手段である。ＩＤ連携制御部３０２は、ＧＵＩ（Graphical User Interface）等を用いてアカウントにログインしている利用者からＩＤ連携の要望を取得する。ＩＤ連携制御部３０２は、利用者からの要望に応じて、個人特定情報（ログインしている利用者の氏名等）、個人識別ＩＤ（当該利用者の会員番号等）及び事業者コードを含む「ＩＤ連携要求」を流通制御サーバ１０に送信する。

なお、利用者の個人識別ＩＤ、個人特定情報及びユーザデータ等は、顧客情報データベースを用いて管理される（図２１参照）。図２１に示すように、顧客情報データベースは、利用者のＩＤ連携が完了しているか否かの情報（フラグ）を保持する。ＩＤ連携制御部３０２は、ＩＤ連携を完了すると、対応する利用者のＩＤ連携状態フィールドにフラグをセットする（図２１では、丸印が設定されている）。

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

データ蓄積制御部３０４は、利用者に対してサービスを提供した結果生じるユーザデータの蓄積に関する制御を行う手段である。データ蓄積制御部３０４は、利用者の個人識別ＩＤと、当該利用者のユーザデータ（利用者にサービスを提供した結果生じたデータ、又は、利用者に提供するサービスに必要なデータ）を対応付けて顧客情報データベースに記憶する。

図２１に示すように、データ蓄積制御部３０４は、発生したデータの種類に応じたフィールドにユーザデータを記憶する（具体的なデータの内容を記憶する）。その際、データ蓄積制御部３０４は、ユーザデータを識別するためのデータＩＤを生成し、ユーザデータ及びデータ蓄積日と対応付けて記憶する。なお、図２１は、病院Ａのサービスサーバ２０に構築された顧客情報データベースの一例を示す。

ここで、ＩＤ連携が完了している利用者に関し、データ蓄積制御部３０４は、ユーザデータを顧客情報データベースに記憶するたびに、所在情報を流通制御サーバ１０に送信する。例えば、個人識別ＩＤ「ＨＬ０１」の利用者にサービスが提供され、診察結果として病名のデータが発生した場合を考える。この場合、個人識別ＩＤ「ＨＬ０１」、事業者コード「病院Ａ」、データＩＤ「ＨＬＤ０１」、データ種類「病名」を含む所在情報が流通制御サーバ１０に送信される。

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

共有指示を受信した場合には、データ流通部３０５は、顧客情報データベースを参照し、共有指示に含まれる個人識別ＩＤ、データ種類に対応するエントリを特定する。例えば、個人識別ＩＤ「ＨＬ０１」、データ種類「病名」を含む共有指示を受信した場合には、データ流通部３０５は、図２１の最上段に示されるエントリを特定する。

データ流通部３０５は、特定されたエントリの対応するデータ種類フィールドに記載されたユーザデータを共有指示で指定されたデータ共有先に送信する。図７及び図２１の例では、「胃がん」がＥＣ事業者Ｂのサービスサーバ２０－２に送信される。

提供指示を受信した場合、データ流通部３０５は、当該提供指示に含まれるデータＩＤに基づいてデータ提供の対象データを特定する。データ流通部３０５は、特定されたエントリの対応するデータ種類フィールドに記載されたユーザデータを提供指示で指定されたデータ提供先に送信する。

その際、データ流通部３０５は、ユーザデータと共に、提供指示に含まれる対象者ＩＤを提供指示に指定されたデータ提供先に送信する。

あるいは、データ流通部３０５は、提供指示に含まれる個人識別ＩＤ、データ蓄積期間、データ種類により定まるユーザデータを、提供指示により指定されたデータ提供先に送信してもよい。

なお、データ流通部３０５は、共有指示に基づいて共有データを送信する際、利用者の個人特定情報（氏名等）を相手先のサービスサーバ２０に送信してもよい。また、データ流通部３０５は、提供データを受信した事業者が、取得データの対応付けを可能とするように提供データにＩＤを付与してもよい。例えば、データ流通部３０５は、利用者の個人特定情報のハッシュ値を計算し、当該ハッシュ値を利用者のＩＤとしてデータ流通先に送信してもよい。

契約締結制御部３０６は、データ提供の契約に関する制御を行う手段である。契約締結制御部３０６は、取引サーバ４０から受信した提供契約締結依頼を処理する。契約締結制御部３０６は、当該依頼を受信すると、サービス事業者の職員等に当該依頼の内容を提示する。

職員等は、図１２Ａ乃至図１２Ｃに示されるようなデータ提供契約を検討し、データ提供契約を締結するか否か決定する。契約締結制御部３０６は、ＧＵＩ等を用いて職員が決定した内容（データ提供契約を締結する、又は、拒否する）を取得する。

データ提供契約が締結される場合、契約締結制御部３０６は、データ提供契約を締結する旨を示す肯定応答を取引サーバ４０に送信する。

データ提供契約が拒否された場合、契約締結制御部３０６は、データ提供契約を締結しない旨を示す否定応答を取引サーバ４０に送信する。

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

［データ利活用サーバ］
データ利活用サーバ３０は、利用者（データ利活用事業者の職員等）に情報を提示し、利用者からの操作を受け付ければよい。具体的には、データ流通要請部３０３は、取引サーバ４０から取得したカタログ情報の一覧等を表示し、利用者が入力したデータ提供申込を取引サーバ４０に送信すればよい。

データ利活用サーバ３０は、取引サーバ４０から取得する各種の通知を処理する。具体的には、データ利活用サーバ３０は、データ提供契約が不成立であることを通知されると、その旨をデータ利活用事業者の職員等に通知する。この場合、データ利活用サーバ３０は、職員等から新たなデータ提供契約やデータ提供申込のキャンセルの指示を取得する。データ利活用サーバ３０は、新たなデータ提供契約や個別契約取下通知を取引サーバ４０に送信する。

また、データ利活用事業者がデータ提供申込をキャンセルする意思を示した場合、データ利活用サーバ３０は、提供申込取消要求を取引サーバ４０に送信する。

データ提供により取得したユーザデータを活用する際、データ利活用サーバ３０は、各サービスサーバ２０から受信した対象者ＩＤに基づいて、各サービスサーバ２０から受信したユーザデータの対応付けを行う。データ利活用サーバ３０は、対象者ＩＤを用いてユーザデータの名寄せを行う。

［取引サーバ］
図２２は、第１の実施形態に係る取引サーバ４０の処理構成（処理モジュール）の一例を示す図である。図２２を参照すると、取引サーバ４０は、通信制御部４０１と、口座開設部４０２と、カタログ情報要求部４０３と、提供契約制御部４０４と、記憶部４０５と、を備える。

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

口座開設部４０２は、提供によるデータ流通を希望する利用者の口座を開設する手段である。口座開設部４０２は、利用者の端末５０からユーザＩＤを取得する。口座開設部４０２は、取得したユーザＩＤを口座開設者リストに追加する（図２３参照）。

カタログ情報要求部４０３は、流通制御サーバ１０に対して「カタログ情報送信要求」を送信する手段である。

カタログ情報要求部４０３は、データ利活用サーバ３０から「カタログ情報提示要求」を受信すると、流通制御サーバ１０に対して「カタログ情報送信要求」を送信する。

当該要求を送信することに応じて、カタログ情報要求部４０３は、流通制御サーバ１０が記憶しているカタログ情報を取得する。カタログ情報要求部４０３は、自装置が提携しているサービス事業者が関係するカタログ情報を選択して、データ利活用事業者（データ利活用サーバ３０）に送信する。なお、カタログ情報要求部４０３は、提携先のサービス事業者の事業者コードとカタログ情報に含まれる事業者コードに基づいて提携先のサービス事業者に関するカタログ情報を選択する。

提供契約制御部４０４は、データ提供契約に関する制御を行う手段である。提供契約制御部４０４は、データ利活用サーバ３０から受信するデータ提供申込を処理する。

データ提供申込を受信すると、提供契約制御部４０４は、当該受信したデータ提供申込に提供申込ＩＤを付与する。提供契約制御部４０４は、提供申込ＩＤを用いてデータ提供申込を管理する。

提供契約制御部４０４は、提供申込ＩＤ、データ提供申込と口座開設者リストを含む「提供要請」を流通制御サーバ１０に送信する。

提供契約制御部４０４は、流通制御サーバ１０から提供元通知を受信する。当該提供元通知には、提供申込ＩＤ、データ提供の対象となるデータを蓄積するデータ提供元の名称、連絡先（サービスサーバ２０のアドレス）、データ種類等が含まれる。

提供元通知を受信すると、提供契約制御部４０４は、データ提供申込をデータ提供元ごとの個別契約（個別契約案）に分離する。具体的には、提供契約制御部４０４は、通知されたデータ種類が共通するデータ提供元について１つのデータ提供契約を生成する。

上記の例では、病名、検査結果はそれぞれ病院Ａ、病院Ｂに保持されているので、提供契約制御部４０４は、病院Ａ向けのデータ提供契約、病院Ｂ向けのデータ提供契約を生成する。また、活動量はフィットネスクラブＣに保持されているので、提供契約制御部４０４は、フィットネスクラブＣ向けのデータ提供契約を生成する。

あるいは、個別のデータ提供契約は取引事業者の職員等により生成されてもよい。提供契約制御部４０４は、提供元通知の内容を上記職員に提示する。提供契約制御部４０４は、職員が生成したデータ提供契約を、ＧＵＩ等を用いて取得する。

提供契約制御部４０４は、生成したデータ提供契約に提供契約ＩＤを付与する。取引サーバ４０は、提供申込ＩＤ、提供契約ＩＤ及びデータ提供契約を対応付けて記憶する。

各データ提供元（データ蓄積者）向けの個別契約を生成すると、提供契約制御部４０４は、各データ提供元にデータ提供契約の締結依頼を行う。具体的には、提供契約制御部４０４は、提供申込ＩＤ、個別の提供契約ＩＤ及びデータ提供契約を含む「提供契約締結依頼」を流通制御サーバ１０から通知された各連絡先（サービスサーバ２０）に送信する。

提供契約制御部４０４は、サービスサーバ２０から提供契約締結依頼に対する応答を受信する。

肯定応答（データ提供元はデータ提供契約に応じる旨の応答）を受信した場合、提供契約制御部４０４は、契約が成立したデータ提供契約の提供契約ＩＤを記憶する。さらに、提供契約制御部４０４は、データ提供契約が成立したことを流通制御サーバ１０及びデータ利活用サーバ３０に通知する。提供契約制御部４０４は、提供申込ＩＤ、提供契約ＩＤ及びデータ提供契約を含む「個別契約成立通知」を流通制御サーバ１０及びデータ利活用サーバ３０に送信する。

否定応答（データ提供元はデータ提供契約に応じない旨の応答）を受信した場合、提供契約制御部４０４は、データ提供契約が不成立であることをデータ利活用サーバ３０に通知する。具体的には、提供契約制御部４０４は、提供申込ＩＤ、提供契約ＩＤ及びデータ提供契約を含む個別契約不成立通知をデータ利活用サーバ３０に送信する。

この場合、提供契約制御部４０４は、データ利活用サーバ３０から、新たなデータ提供契約（条件が見直されたデータ提供契約）又は個別契約取下通知を受信する。

新たなデータ提供契約を受信した場合、提供契約制御部４０４は、当該新たなデータ提供契約を含む提供契約締結依頼をデータ提供元のサービスサーバ２０に送信する。

個別契約取下通知を受信した場合、提供契約制御部４０４は、受信した個別契約取下通知を流通制御サーバ１０に転送する。

提供契約制御部４０４は、データ利活用事業者からのデータ提供申込の取消に関する制御を行う。

提供契約制御部４０４は、データ利活用サーバ３０から提供申込ＩＤを含む「提供申込取消要求」を受信する。

提供申込取消要求を受信すると、提供契約制御部４０４は、データ提供契約の状況を確認し、データ提供申込のキャンセルが可能か否か判定する。

提供契約制御部４０４は、データ提供申込の提供データの要件が満たされていれば、データ提供申込はキャンセル不可と判定する。提供契約制御部４０４は、データ提供申込の提供データの要件が満たされていなければ、データ提供申込はキャンセル可と判定する。

具体的には、対象データの一部のデータ量が必要データ量の下限を超えていない場合には、データ提供申込の締め切り日によらずデータ提供申込はキャンセル可と判定される。対して、対象データの全てのデータ量が必要データ量の下限を超えている場合には、データ提供契約の締め切り日によらずデータ提供申込はキャンセル不可と判定される。

提供契約制御部４０４は、データ提供の状況がキャンセル可な状態であれば、データ提供申込のキャンセルを受け付ける旨の肯定応答をデータ利活用サーバ３０に送信する。提供契約制御部４０４は、データ提供の状況がキャンセル不可な状態であれば、データ提供申込のキャンセルを受け付けられない旨の否定応答をデータ利活用サーバ３０に送信する。

また、データ提供申込のキャンセルを受け付けた場合には、提供契約制御部４０４は、その旨を流通制御サーバ１０に通知する。

提供契約制御部４０４は、データ提供の実行に関する制御を行う。提供契約制御部４０４は、所定の条件が満たされるとデータ提供を実行する。提供契約制御部４０４は、所定の条件が満たされるとデータ提供契約を自動的に締め切る自動締切機能を備える。

具体的には、提供契約制御部４０４は、データ提供申込に記載された締め切り日が到来し、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供の実行を流通制御サーバ１０に指示する。

あるいは、提供契約制御部４０４は、データ提供申込の予算に基づいて、データ提供を実行してもよい。具体的には、提供契約制御部４０４は、利用者がデータ提供に同意することでデータ提供先が支払う対価がデータ提供申込に記載された予算を上回り、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供申込を実行する。

あるいは、提供契約制御部４０４は、対象データの少なくとも１つが必要データ量の上限を超え、且つ、データ提供申込に記載された提供データの要件が満たされていれば、データ提供を実行してもよい。

データ提供を実行する場合、提供契約制御部４０４は、提供申込ＩＤを含む「データ提供実行指示」を流通制御サーバ１０に送信する。

提供契約制御部４０４は、データ提供申込の状況を管理する。提供契約制御部４０４は、流通制御サーバ１０から受信する「提供データ量通知」を処理する。

提供契約制御部４０４は、提供データ量通知に含まれる提供申込ＩＤに基づき、流通制御サーバ１０が利用者の同意を取得したデータ提供申込を特定する。提供契約制御部４０４は、管理されている提供データのデータ量に、提供データ量通知で通知されたデータ量を反映する。提供契約制御部４０４は、提供データの種類ごとに、提供可能なデータ量を管理するパラメータに上記提供データ量通知で通知されたデータ量を加算する。

提供契約制御部４０４は、データ提供契約に記載された対価（当事者が合意した対価）と利用者が同意したデータ種類及び提供されるデータ量に基づき、データ提供先が支払う対価を算出する。

例えば、図１２Ａの例において、利用者が１件の病名と３件の検査結果の提供に同意すると、当該同意によりデータ提供先が支払う対価は、１０円＋６（２×３）円＝１６円と算出される。提供契約制御部４０４は、利用者の同意により生じる対価を既に計算済の対価に加算することで、データ提供先が支払う対価の総額を計算する。

提供契約制御部４０４は、提供データ量通知を受信したことに応じて、データ種類ごとの提供データのデータ量（蓄積量）とデータ提供先が支払う対価の総額とを含む「データ提供状況情報」を生成する。あるいは、データ提供状況情報は、上記データ量や支払総額が可視化されたグラフであってもよい。

提供契約制御部４０４は、生成したデータ提供状況情報（例えば、図１４に示すようなグラフ）を定期的又は所定のタイミングでデータ利活用サーバ３０に送信する。

記憶部４０５は、取引サーバ４０の動作に必要な情報を記憶する。記憶部４０５は、提携先のサービス事業者の事業者コードを記憶する。

［端末］
図２４は、第１の実施形態に係る端末５０の処理構成（処理モジュール）の一例を示す図である。図２４を参照すると、端末５０は、通信制御部５０１と、個人情報入力部５０２と、問合せ処理部５０３と、記憶部５０４と、を備える。

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

個人情報入力部５０２は、利用者登録の際に個人情報を流通制御サーバ１０に入力する手段である。個人情報入力部５０２は、任意の手段を用いて個人情報（氏名、生年月日、連絡先、口座情報等）を流通制御サーバ１０に入力する。例えば、個人情報入力部５０２は、ＧＵＩを用いて上記個人情報を利用者から取得し、当該取得した個人情報を流通制御サーバ１０に送信する。

個人情報入力部５０２は、流通制御サーバ１０から払い出されたユーザＩＤを記憶部５０４に記憶する。

問合せ処理部５０３は、データ共有の問合せ又はデータ提供の問合せを処理する手段である。問合せ処理部５０３は、問い合わせの内容（データ共有、データ提供）に合わせたＧＵＩを用いて利用者の意思（同意、不同意）を取得する。問合せ処理部５０３は、利用者の意思を含む応答を流通制御サーバ１０に送信する。

記憶部５０４は、端末５０の動作に必要な情報を記憶する。

［病院端末］
病院端末６０には、スマートフォン、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。病院端末６０は、病院職員の操作を受け付け、流通制御サーバ１０等と通信可能であれば任意の機器、デバイスとすることができる。また、病院端末６０の構成等は当業者にとって明らかであるので、詳細な説明を省略する。

病院端末６０は、病院職員の操作に応じて、ＩＤ連携要求を流通制御サーバ１０に送信すればよい。また、病院端末６０は、ＩＤ連携要求を自社のサービスサーバ２０にも送信する。サービスサーバ２０（ＩＤ連携制御部３０２）は、ＩＤ連携要求に含まれる個人識別ＩＤに対応する利用者のエントリ（顧客情報データベースのエントリ）のＩＤ連携状態フィールドにフラグをセットする。

［システムの動作］
続いて、第１の実施形態に係る情報流通システムの動作について説明する。図２５は、第１の実施形態に係る情報流通システムの動作の一例を示すシーケンス図である。図２５を参照し、データ提供時のシステムの動作を説明する。流通制御サーバ１０は、データ提供の対象者からデータ提供に対する同意を取得する（ステップＳ４１）。

利用者の同意を取得すると、流通制御サーバ１０は、当該利用者を識別するＩＤであって、データ提供申込ごとに異なる対象者ＩＤを生成する（ステップＳ４２）。

取引サーバ４０からデータ提供の実行を指示されると、流通制御サーバ１０は、提供対象のデータを指定するデータＩＤと、対象データの生成に寄与した利用者の対象者ＩＤと、を含む提供指示を各サービスサーバ２０に送信する（ステップＳ４３）。

各サービスサーバ２０は、提供指示により指定されたユーザデータ（蓄積データ）と対象者ＩＤをデータ利活用サーバ３０に送信する（ステップＳ４４）。

データ利活用サーバ３０は、各サービスサーバ２０から取得した対象者ＩＤに基づいてユーザデータを対応付ける（ステップＳ４５）。

以上のように、第１の実施形態に係る情報流通システムにおいて、流通制御サーバ１０は、データ提供に対する利用者の同意が得られると、対象データの発生に関与した利用者を識別するための対象者ＩＤを生成する。流通制御サーバ１０は、データ提供申込ごとに異なる対象者ＩＤを生成する。データ提供の実行時には、流通制御サーバ１０は、対象者ＩＤを含む提供指示をサービスサーバ２０に送信する。提供指示の受信に応じて、サービスサーバ２０は、ユーザデータと対象者ＩＤをデータ利活用サーバ３０に送信する。データ利活用サーバ３０は、各サービスサーバ２０から受信した対象者ＩＤに基づいて受信したユーザデータの対応付けを行う。このような構成により、データ利活用事業者が、複数のデータ提供申込で得られたユーザデータを不当に対応付けることが防止される。即ち、データ提供申込ごとに対象者ＩＤが異なるので、データ利活用事業者は、異なるデータ提供申込から得られたデータを対応付けることができない。また、サービスサーバ２０とデータ利活用サーバ３０の間で送受信される対象者ＩＤは利用者に通知されることはない。そのため、利用者自身から対象者ＩＤが漏洩することはない。当該観点からも、データ利活用事業者は、ユーザデータの対応付けを行うことができない。その結果、個人のプライバシーは保護される。

データ提供元が利用者を管理する個人識別ＩＤはデータ提供元ごとに異なる。各データ提供元が、当該個人識別ＩＤの相違を考慮せず、ユーザデータをデータ提供先に送信すると、データ提供先はデータの整合性を図ることができない。その結果、データ提供先は、取得したデータを有効に活用できない。そこで、本願開示の情報流通システムは、流通制御サーバ１０は、各データ提供元に対象者ＩＤを送信し、当該対象者ＩＤに個人識別ＩＤを書き換えて（置き換えて）ユーザデータをデータ提供先に送信するように指示する。

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

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

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

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

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

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

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

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

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

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

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

上記実施形態では、情報流通事業者と取引事業者は異なる事業者であることを前提として説明を行った。しかし、１つの事業者が情報流通事業と取引事業を行ってもよい。この場合、１つのサーバ装置が、流通制御サーバ１０と取引サーバ４０の機能を備えていてもよい。

上記実施形態で説明したデータ提供状況情報（例えば、図１４に示すような時系列グラフ）は例示であって、取引サーバ４０は様々な内容のデータ提供状況情報を生成できる。例えば、取引サーバ４０は、各データに関する必要データ量の下限値を含む時系列グラフを生成してもよい。その際、取引サーバ４０は、キャンセルに関する最新の状況（現時点でのキャンセル可否）やキャセン不可となる状況が記載された時系列グラフを生成してもよい。あるいは、取引サーバ４０は、自動的にデータ提供が行われるタイミング（目安）が記載された時系列グラフを生成してもよい。

データ提供の対象となるデータ（原本データ）にデジタル署名が付与されている場合には、所謂、墨塗署名技術が適用されてもよい。当該墨塗署名技術を使用することで、個人識別ＩＤから対象者ＩＤにＩＤの付け替えが行われても署名検証が可能となる。

上記実施形態では、データ提供契約の締結後に利用者の同意を取得する場合について説明した。しかし、利用者の同意取得後にデータ提供契約の締結が行われてもよい。あるいは、利用者の同意取得とデータ提供契約の締結が並列に実行されてもよい。

上記実施形態に係るデータ流通システムは、データ提供申込の締め切り延長の仕組みを備えていてもよい。具体的には、データ利活用事業者は、データ提供の状況を確認し、締め切り日の延長が必要と判断した場合には、その旨をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、締め切り日の延長申請を取引サーバ４０に行う。取引サーバ４０は、対応するデータ提供申込の締め切り日を通知された締め切り日に更新する。

上記実施形態に係るデータ流通システムは、データ提供先による予算の追加設定に関する仕組みを備えていてもよい。具体的には、データ利活用事業者は、データ提供の状況を確認し、予算の追加が必要と判断した場合には、その旨をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、予算の追加を取引サーバ４０に通知する。取引サーバ４０は、対応するデータ提供申込の予算を通知された予算に更新する。

上記実施形態に係るデータ流通システムは、手動で締め切り日を設定可能な構成であってもよい。具体的には、データ利活用事業者は、データ提供の状況を確認し、必要なデータが集まったと判断した場合には、データ提供申込を完了する旨をデータ利活用サーバ３０に入力する。データ利活用サーバ３０は、データ提供申込の終了要請を取引サーバ４０に行う。取引サーバ４０は、対応するデータ提供申込を終了し、データ提供の実施を流通制御サーバ１０に指示する。

上記実施形態では、データ提供の締め切りとデータ提供の実行が実質的に同じタイミングである場合について説明した。しかし、データ提供の締め切りとデータ提供は異なるタイミングで実行されてもよい。例えば、データ提供先は、データ提供申込に「履行予定日」を入力する。取引サーバ４０は、当該履行予定日が到来するとデータ提供を実行（履行）してもよい。

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

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

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

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

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

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
取引サーバと、
サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、
データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、
前記データ提供を制御する、流通制御サーバと、
を含み、
前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、
前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、
前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信する、システム。
［付記２］
前記流通制御サーバは、前記所定の要件を満たすデータが複数の前記サービスサーバに記憶されている場合、前記複数のサービスサーバそれぞれに、同一の前記対象者ＩＤを含む前記提供指示を送信する、付記１に記載のシステム。
［付記３］
前記データ利活用サーバは、前記対象者ＩＤに基づいて、前記複数のサービスサーバから受信したデータを対応付ける、付記２に記載のシステム。
［付記４］
前記流通制御サーバは、前記データ提供申込ごとに異なるように前記対象者ＩＤを生成する、付記３に記載のシステム。
［付記５］
前記流通制御サーバは、前記所定の要件を満たすデータに対応する利用者が所持する端末に、データ提供の問合せを送信する、付記４に記載のシステム。
［付記６］
前記流通制御サーバは、前記データ提供の申込対する応答を受信し、
前記利用者が前記データ提供に同意すると、前記データ提供に同意した利用者のユーザＩＤ、前記対象者ＩＤ及び前記データ提供申込の提供申込ＩＤを対応付けて同意管理データベースに記憶する、付記５に記載のシステム。
［付記７］
前記取引サーバは、前記サービス事業者と前記データ利活用事業者の間のデータ流通取引の仲介を行う取引事業者により運営される、付記１乃至６のいずれか一項に記載のシステム。
［付記８］
前記取引サーバは、前記サービス事業者と前記データ利活用事業者の間のデータ提供契約に関する制御を行う、付記７に記載のシステム。
［付記９］
前記流通制御サーバは、前記データ利活用事業者との間で前記データ提供契約が締結された前記サービス事業者の前記サービスサーバに前記提供指示を送信する、付記８に記載のシステム。
［付記１０］
取引サーバと、
サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、
データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、
前記データ提供を制御する、流通制御サーバと、
を含むシステムにおいて、
前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、
前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、
前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信する、方法。

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

１０ 流通制御サーバ
２０ サービスサーバ
２０－１ サービスサーバ
２０－２ サービスサーバ
３０ データ利活用サーバ
４０ 取引サーバ
５０ 端末
６０ 病院端末
１０１ 取引サーバ
１０２ サービスサーバ
１０３ データ利活用サーバ
１０４ 流通制御サーバ
２０１ 通信制御部
２０２ 利用者登録部
２０３ ＩＤ連携部
２０４ 所在情報管理部
２０５ データ流通制御部
２０６ カタログ情報管理部
２０７ 記憶部
３０１ 通信制御部
３０２ ＩＤ連携制御部
３０３ データ流通要請部
３０４ データ蓄積制御部
３０５ データ流通部
３０６ 契約締結制御部
３０７ 記憶部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 口座開設部
４０３ カタログ情報要求部
４０４ 提供契約制御部
４０５ 記憶部
５０１ 通信制御部
５０２ 個人情報入力部
５０３ 問合せ処理部
５０４ 記憶部

Claims (9)

1. 取引サーバと、
   サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、
   データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、
   前記データ提供を制御する、流通制御サーバと、
   を含み、
   前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、
   前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、
   前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信し、
   前記流通制御サーバは、前記データ提供申込ごとに異なるように前記対象者ＩＤを生成する、システム。
2. 前記流通制御サーバは、前記所定の要件を満たすデータが複数の前記サービスサーバに記憶されている場合、前記複数のサービスサーバそれぞれに、同一の前記対象者ＩＤを含む前記提供指示を送信する、請求項１に記載のシステム。
3. 前記データ利活用サーバは、前記対象者ＩＤに基づいて、前記複数のサービスサーバから受信したデータを対応付ける、請求項２に記載のシステム。
4. 前記流通制御サーバは、前記所定の要件を満たすデータに対応する利用者が所持する端末に、データ提供の問合せを送信する、請求項３に記載のシステム。
5. 前記流通制御サーバは、前記データ提供の申込対する応答を受信し、
   前記利用者が前記データ提供に同意すると、前記データ提供に同意した利用者のユーザＩＤ、前記対象者ＩＤ及び前記データ提供申込の提供申込ＩＤを対応付けて同意管理データベースに記憶する、請求項４に記載のシステム。
6. 前記取引サーバは、前記サービス事業者と前記データ利活用事業者の間のデータ流通取引の仲介を行う取引事業者により運営される、請求項１乃至５のいずれか一項に記載のシステム。
7. 前記取引サーバは、前記サービス事業者と前記データ利活用事業者の間のデータ提供契約に関する制御を行う、請求項６に記載のシステム。
8. 前記流通制御サーバは、前記データ利活用事業者との間で前記データ提供契約が締結された前記サービス事業者の前記サービスサーバに前記提供指示を送信する、請求項７に記載のシステム。
9. 取引サーバと、
   サービス事業者により運営され、利用者にサービスを提供することで発生した少なくとも１以上のユーザデータを記憶する、サービスサーバと、
   データ利活用事業者により運営され、前記少なくとも１以上のユーザデータのうち所定の要件を満たすデータをデータ提供により取得するための申込であって、前記所定の要件を含むデータ提供申込を前記取引サーバに送信する、データ利活用サーバと、
   前記データ提供を制御する、流通制御サーバと、
   を含むシステムにおいて、
   前記取引サーバは、前記データ提供申込を前記流通制御サーバに送信し、
   前記流通制御サーバは、前記所定の要件を満たすデータを指定する情報と、前記利用者のＩＤであって前記データ提供申込に対応して生成された対象者ＩＤと、を含む提供指示を前記サービスサーバに送信し、
   前記サービスサーバは、前記指定されたデータと前記対象者ＩＤを前記データ利活用サーバに送信する、方法であって、
   前記流通制御サーバは、前記データ提供申込ごとに異なるように前記対象者ＩＤを生成する、方法。