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

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

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

(11)【特許番号】

(24)【登録日】2025-02-25

(45)【発行日】2025-03-05

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

(51)【国際特許分類】

   G06Q 10/00 20230101AFI20250226BHJP

   G16H 40/20 20180101ALI20250226BHJP

【ＦＩ】

G06Q10/00

G16H40/20

【請求項の数】 10

(21)【出願番号】P 2023572315

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

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

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

(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】

【図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】図３１は、第２の実施形態に係る流通制御サーバの処理構成の一例を示す図である。

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

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

【0016】

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

【0017】

一実施形態に係るシステムは、第１のサーバ１０１と、第２のサーバ１０２と、流通制御サーバ１０３と、を含む（図１参照）。第１のサーバ１０１は、利用者にサービスを提供することで生成されたデータを蓄積する。流通制御サーバ１０３は、蓄積されたデータが第１のサーバから第２のサーバに送信されるデータ共有を制御する。図２は、一実施形態に係るシステムの動作の一例を示すフローチャートである。流通制御サーバ１０３は、利用者が設定した条件であって、自らの同意無くデータ共有を実現するための有効化条件を記憶する（ステップＳ１）。流通制御サーバ１０３は、有効化条件が成立すると、利用者の同意無く第１のサーバに蓄積されたデータを第２のサーバと共有可能にする無同意共有期間を設定する（ステップＳ２）。

【0018】

利用者は、自身の同意がなくてもデータ共有を可能とするための有効化条件をシステムに登録する。流通制御サーバ１０３は、例えば、利用者の体調急変などによって上記利用者が事前に設定した有効化条件が成立した場合には、当該利用者（体調急変者）に関し、当該利用者の同意無くデータ共有が可能な無同意共有期間を設定する。流通制御サーバ１０は、利用者の体調が急変したことに応じて、当該無同意共有期間中に第２のサーバ１０２からデータ共有の要請を受けると、第２のサーバ１０２から要請されたデータのデータ共有を実現する。このように、利用者は、事前に有効化条件をシステムに登録し、体調急変時に対する事前同意を行う。流通制御サーバ１０３は、利用者のバイタルデータ等に基づき有効化条件が満たされているか否か判定し、満たされていれば、共有指示をデータ蓄積者である第１のサーバ１０１に行う。その結果、利用者が自らの意思で同意をできない期間における機微なパーソナルデータである「病名」等のデータの共有期間が必要最小限となり、情報流通システムを利用する利用者のプライバシーは適切に保護される。

【0019】

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

【0020】

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

【0021】

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

【0022】

情報流通事業者は、サービス事業者間のデータ流通を制御する主体である。情報流通事業者は、少なくとも１以上の流通制御サーバ１０を含む。

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

［システムの動作概略］
続いて、第１の実施形態に係る情報流通システムの動作概略について説明する。初めに、第１の実施形態に係る情報流通システムの基本的な動作を説明する。その後、利用者が自らの意思でデータ流通に対する同意が行えない場合について説明する。

【0030】

第１の実施形態では、４つのサービス事業者を例にとり説明を行う。具体的には、病院Ａ、病院Ｂ、救急医療を担当する救急病院、旅行代理店の４つのサービス事業者を使って説明を行う。

【0031】

なお、図３に示すように、病院Ａはサービスサーバ２０－１を備え、病院Ｂはサービスサーバ２０－２を備え、救急病院はサービスサーバ２０－３を備え、旅行代理店はサービスサーバ２０－４を備える。また、以降の説明において、サービスサーバ２０－１～２０－４を区別する特段の事情がない場合には単に「サービスサーバ２０」と表記する。

【0032】

情報流通システムにおけるデータ流通の手段として「共有」が存在する。

【0033】

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

【0034】

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

【0035】

＜利用者登録＞
図４に示すように、情報流通システムの利用者は事前に登録（利用者登録、システム登録）を行う必要がある。より具体的には、利用者は、システム参加時に利用者登録を行う。利用者は、所持する端末３０を操作して、自身の個人情報（氏名、生年月日、連絡先等）を流通制御サーバ１０に入力する。

【0036】

流通制御サーバ１０は、当該利用者を識別するためのユーザＩＤ（Identifier）を生成し、当該生成されたユーザＩＤを利用者に払い出す。流通制御サーバ１０は、生成したユーザＩＤと取得した個人情報（氏名等）を対応付けて記憶する。より具体的には、流通制御サーバ１０は、「利用者情報データベース」を用いてユーザＩＤと個人情報を対応付けて記憶する。利用者情報データベースの詳細は後述する。

【0037】

流通制御サーバ１０は、利用者登録が完了した利用者のための個人ポータルを開設する。利用者は、個人ポータルにログインし、当該個人ポータルを介して、情報流通システムに設定した各種の情報を管理、変更できる。

【0038】

＜個人識別コードの生成＞
利用者登録が完了すると、利用者は、サービスの提供を受けたいサービス事業者と個別に契約を締結する。具体的には、利用者は、氏名等をサービス事業者に提供しつつ当該サービス事業者と新たな契約（サービスを享受するための契約）をしたい旨を申し出る。例えば、医療機関を受診したい利用者は、氏名等が記載された健康保険証等を当該医療機関に提出する。

【0039】

サービス事業者は、新規な顧客（利用者）を識別するための「個人識別コード」を生成する。例えば、医療機関は、利用者（患者）を管理するための診察券番号を採番し、当該診察券番号を個人識別コードとして生成する。サービスサーバ２０は、生成した個人識別コード（例えば、診察券番号）を独自のデータベース等に記憶する。

【0040】

個人識別コードが生成されると、利用者は、サービス事業者からサービスの提供を受けることができる。例えば、利用者は医療機関から医療サービス（健康診断や診察等）を受ける。利用者にサービスが提供されることで生成されるデータ（検診結果や病名）は、サービス事業者に蓄積され、データ流通の対象となる。

【0041】

＜個人識別コードの通知＞
生成された個人識別コードは情報流通事業者に通知される。流通制御サーバ１０は、各サービス事業者により生成された個人識別コードを取得する。

【0042】

具体的には、流通制御サーバ１０は、定期的又は所定のタイミングで、利用者登録が完了した利用者の個人特定情報を含む「利用者情報提供要求」を各サービスサーバ２０に送信する（図５参照）。個人特定情報は、利用者を特定するための情報であって、氏名や氏名と生年月日の組み合わせ等が例示される。

【0043】

サービスサーバ２０は、個人特定情報に対応する個人識別コードが存在すると、対応する利用者（顧客）に関する情報（以下、利用者情報と表記する）を流通制御サーバ１０に送信する。

【0044】

利用者情報には、上記生成された利用者の個人識別コードと、サービス事業者の事業者コードが含まれる。事業者コードは、情報流通システムに参加するサービス事業者を識別するための識別情報（ＩＤ）である。

【0045】

例えば、病院Ａと病院Ｂには異なるコードが割り当てられる。なお、事業者コードは、任意の手段によりシステム参加者（情報流通事業者、サービス事業者）の間で共有される。例えば、サービス事業者が情報流通システムに参加する際、情報流通事業者（流通制御サーバ１０）が当該サービス事業者に割り当てる事業者コードを生成する。情報流通事業者は、当該生成した事業者コードをサービス事業者に通知する。また、情報流通事業者は、生成した事業者コードをシステムに参加する他のサービス事業者にも通知する。

【0046】

流通制御サーバ１０は、取得した個人識別コードを利用者情報データベースに記憶する。

【0047】

＜データの蓄積及び所在情報の送信＞
サービス事業者は、利用者にサービスを提供することに伴い生じるデータを蓄積する。例えば、図６に示すように、病院Ａが、利用者Ｕ１～Ｕ３のそれぞれに医療サービスを提供すると、病院Ａはその結果を利用者ごとに蓄積する。例えば、病院Ａは、利用者Ｕ１～Ｕ３それぞれの診察結果（例えば、病名や検査結果）を利用者ごとに蓄積する。

【0048】

サービス事業者（サービスサーバ２０）は、各利用者の個人識別コードとサービス提供の結果得られたデータを対応付けて記憶する。例えば、図６の例では、病院Ａのサービスサーバ２０－１は、「蓄積データベース」を用いて利用者Ｕ１～Ｕ３それぞれの個人識別コードと診察結果（例えば、胃がん、肺がん等の具体的な病名）を対応付けて記憶する。なお、蓄積データベースの詳細は後述する。

【0049】

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

【0050】

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

【0051】

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

【0052】

ここでは、図７を参照しつつ、病院Ｂが、病院Ａに蓄積された利用者Ｕ１のデータを「共有」により取得する場合について説明する。

【0053】

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

【0054】

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

【0055】

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

【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】

例えば、上記の例では、利用者が対象データの種類に「病名」を設定し、救急病院のサービスサーバ２０－４も「病名」のデータ共有を要請しているので、利用者は救急病院からの共有要請に同意したと扱われる。

【0085】

利用者が共有要請に同意したと扱われた場合には、流通制御サーバ１０は、利用者の「病名」を蓄積する病院Ａのサービスサーバ２０－１に共有指示を送信する（ステップＳ２５）。

【0086】

病院Ａのサービスサーバ２０－１は、指定されたデータ種類に対応する具体的な病名を救急病院のサービスサーバ２０－３に送信する（ステップＳ２６）。サービスサーバ２０－３は、病院Ａから取得したデータ（病名；既往症、現症）と旅行代理店から取得したバイタルデータを医師等に提示する。

【0087】

医師は、これらのデータに基づいて利用者の救護を開始する。医師による救護活動は３つのフェーズ（応急処置フェーズ、搬送フェーズ、医療提供フェーズ）からなる。

【0088】

応急処置フェーズでは、現場（観光地）に救急車が到着するまでの間、救急病院からの指示を受けた観光地職員と病名等を取得した救急病院の医師の連携により要救護者の救護が行われる（図１３参照）。救急病院の医師は、バイタルデータと病名（既往症、現症）に基づき、観光地職員に対して必要な処置を指示する。指示は携帯電話等を用いて行われる。

【0089】

また、救急病院は、現場に救急車を派遣する。救急車が現場に到着すると搬送フェーズが開始する（図１４参照）。搬送フェーズは、救急隊員と救急病院の医師の連携により実施される。緊急病院の医師は、救急隊員に必要な指示を行う。

【0090】

要救護者は、救急病院に運び込まれる。救急病院に要救護者が運び込まれると、医療提供フェーズが開始する。救急病院の医師は、搬送された利用者（患者）に対して救命医療を提供する（図１５参照）。

【0091】

このように、流通制御サーバ１０は、第１のサーバ（サービスサーバ２０－１）に蓄積されたデータが第１のサーバから第２のサーバ（サービスサーバ２０－３）に送信されるデータ共有に関する制御を行う。その際、利用者が事前に設定した有効化条件が成立すると、流通制御サーバ１０は、利用者の同意無くサービスサーバ２０－１に蓄積されたデータをサービスサーバ２０－３と共有可能にする無同意共有期間を設定する。流通制御サーバ１０は、無同意設定期間に、サービスサーバ２０－３からサービスサーバ２０－１に蓄積されたデータのデータ共有を要請された場合に、当該蓄積されたデータをサービスサーバ２０－３に送信するようにサービスサーバ２０－１に指示する。

【0092】

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

【0093】

［流通制御サーバ］
図１６は、第１の実施形態に係る流通制御サーバ１０の処理構成（処理モジュール）の一例を示す図である。図１６を参照すると、流通制御サーバ１０は、通信制御部２０１と、利用者登録部２０２と、設定管理部２０３と、個人識別コード制御部２０４と、所在情報管理部２０５と、無同意共有設定制御部２０６と、データ流通制御部２０７と、記憶部２０８と、を備える。

【0094】

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

【0095】

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

【0096】

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

【0097】

利用者登録部２０２は、ユーザＩＤと個人情報を利用者情報データベースに記憶する（図１７参照）。例えば、利用者Ｕ４について利用者登録がなされると、図１７の最下段に示されるエントリが追加される。なお、利用者登録の段階では、無同意データ共有に関する情報や個人識別コードは設定されない。また、図１７に示す終了日時フィールドには、無同意共有期間が終了する日時が設定されるが、図１７では日付の図示を省略している。

【0098】

図１７に示す利用者情報データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、利用者登録された日時等が利用者情報データベースに登録されていてもよい。

【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】

具体的には、データ流通制御部２０７は、データ流通対象者に無同意共有期間が設定されているか否か確認する（ステップＳ２０３）。具体的には、データ流通制御部２０７は、データ流通対象者の無同意共有フィールドを参照し、当該フィールドにフラグがセットされているか否かに応じて無同意共有期間か否か取得する。

【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】

体調情報制御部５０２は、定期的又は所定のタイミングで現在位置を計測する。体調情報制御部５０２は、ＧＰＳ（Global Positioning System）衛星からのＧＰＳ信号を受信して測位を実行し、自装置の緯度、経度及び高度を含む位置情報を生成する。あるいは、体調情報制御部５０２は、無線アクセスポイントと通信し、当該無線アクセスポイントの位置を自装置の位置として扱っても良い。あるいは、体調情報制御部５０２は、無線アクセスポイントから受信する電波の強度に基づき位置情報を生成してもよい。

【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】

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

【0220】

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

【0221】

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

【0222】

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

【0223】

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

【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】

１０ 流通制御サーバ
２０ サービスサーバ
２０－１ サービスサーバ
２０－２ サービスサーバ
２０－３ サービスサーバ
２０－４ サービスサーバ
３０ 端末
４０ ウェアラブル端末
１０１ 第１のサーバ
１０２ 第２のサーバ
１０３ 流通制御サーバ
２０１ 通信制御部
２０２ 利用者登録部
２０３ 設定管理部
２０４ 個人識別コード制御部
２０５ 所在情報管理部
２０６ 無同意共有設定制御部
２０７ データ流通制御部
２０８ 記憶部
２０９ 体調情報処理部
３０１ 通信制御部
３０２ 個人識別コード管理部
３０３ 共有要請部
３０４ データ蓄積部
３０５ データ流通部
３０６ 記憶部
３０７ 救護要請処理部
３０８ 共有設定管理部
３０９ 体調情報処理部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 個人情報入力部
４０３ 設定制御部
４０４ 問合せ処理部
４０５ 記憶部
５０１ 通信制御部
５０２ 体調情報制御部
５０３ 記憶部

【図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】

【図32】