(57)【要約】【課題】保険者側にとっては、個別具体的に保険料の算定を行うための被保険者の信憑性のある健康情報を取得でき、組織側にとっては、健康経営の指標ともなり得る情報を取得でき、被保険者側にとっては、保険者側からの利益を取得でき、さらに、組織側の機器と保険者側の機器との間で個別に通信を行うことを不要とした情報処理装置を提供する。【解決手段】情報処理装置の第１の受信手段は、組織側の機器から送信されてきた該組織に属する被保険者の健康に関する第１の情報を受信し、第１の送信手段は、前記第１の情報を、前記被保険者に対応する保険者側の機器に送信し、第２の受信手段は、前記保険者側の機器から送信されてきた前記被保険者への利益を含む第２の情報を受信し、第２の送信手段は、前記第２の情報を前記組織側の機器に送信する。【選択図】図１
2019091328.tif 000002
【特許請求の範囲】
【請求項１】
組織側の機器から送信されてきた該組織に属する被保険者の健康に関する第１の情報を受信する第１の受信手段と、
前記第１の情報を、前記被保険者に対応する保険者側の機器に送信する第１の送信手段と、
前記保険者側の機器から送信されてきた前記被保険者への利益を含む第２の情報を受信する第２の受信手段と、
前記第２の情報を前記組織側の機器に送信する第２の送信手段
を有する情報処理装置。
【請求項２】
前記第１の受信手段は、前記組織側の機器から能動的に送信されてきた前記第１の情報を受信し、
前記第１の送信手段は、前記保険者側の機器からの要求にしたがって、前記第１の情報を送信し、
前記第２の受信手段は、前記保険者側の機器から能動的に送信されてきた前記第２の情報を受信し、
前記第２の送信手段は、本情報処理装置が能動的に送信する
請求項１に記載の情報処理装置。
【請求項３】
前記第１の情報と前記第２の情報は、前記組織の識別情報と前記保険者の識別情報を含み、該組織の識別情報と該保険者の識別情報以外の情報は、暗号化されている
請求項１に記載の情報処理装置。
【請求項４】
前記第１の情報は、前記保険者の公開鍵で暗号化されており、
前記第２の情報は、前記組織の公開鍵で暗号化されている
請求項３に記載の情報処理装置。
【請求項５】
前記組織の識別情報と前記保険者の識別情報は、本情報処理装置の公開鍵で暗号化されており、
受信した情報を本情報処理装置の秘密鍵で復号する復号手段と、
前記復号手段によって、復号した情報を用いて、前記第１の情報又は前記第２の情報を管理する管理手段
をさらに有する請求項４に記載の情報処理装置。
【請求項６】
請求項１に記載の情報処理装置と、
前記組織側の機器と、
前記保険者側の機器
を有しており、
前記組織側の機器は、
前記第１の情報を前記被保険者から収集する収集手段と、
前記収集手段によって収集された第１の情報を前記情報処理装置に送信する第３の送信手段と、
前記情報処理装置から送信されてきた前記第２の情報を受信する第３の受信手段と、
前記第２の情報内の前記被保険者への利益にしたがって、該被保険者に割り当てられる利益を提示する提示手段
を有しており、
前記保険者側の機器は、
前記情報処理装置から送信されてきた前記第１の情報を受信する第４の受信手段と、
前記第１の情報にしたがって、前記被保険者への利益を算出する算出手段と、
前記第２の情報を前記情報処理装置に送信する第４の送信手段
を有する情報処理システム。
【請求項７】
コンピュータを、
組織側の機器から送信されてきた該組織に属する被保険者の健康に関する第１の情報を受信する第１の受信手段と、
前記第１の情報を、前記被保険者に対応する保険者側の機器に送信する第１の送信手段と、
前記保険者側の機器から送信されてきた前記被保険者への利益を含む第２の情報を受信する第２の受信手段と、
前記第２の情報を前記組織側の機器に送信する第２の送信手段
として機能させるための情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム及び情報処理プログラムに関する。
【背景技術】
【０００２】
例えば、特許文献１には、保険契約をペーパレスで、且つ、そのほとんどをモバイル端末により、保険契約申込者と取扱者との間で成立させることができる保険契約システムを提供することを課題とし、モバイル端末で、利用規約等の確認・同意、申込内容の確認、重要事項兼受領確認，意向確認、申込内容確認・自署を行い、ペーパレス処理の場合は、告知手続前の注意確認、告知事項の回答、告知内容の確認・自署、収納手続、お客様控印刷・交付、取扱者報告、内部管理責任者の承認を行い、保険契約管理サーバーで、データ受信、引受査定、成立・証券発送を行うことが開示されている。
【０００３】
また、例えば、特許文献２には、所定のライフイベントが発生した場合に、必要な手続を漏れなく行う支援をすることを課題とし、保険の契約者を識別する情報と、契約者が契約した保険の契約番号と、保険の契約に関する複数の契約項目にそれぞれ登録された複数の登録内容と、を対応付けて保存する保険契約情報ＤＢと、ライフイベントの種別と、ライフイベントが発生した場合に保全が必要な契約項目に対する変更手続きとを対応付けて保存するライフイベント情報ＤＢと、ユーザーが選択したライフイベントに基づいて、選択されたライフイベントに対応する変更手続きを行うための第１手続画面を表示させる表示制御部と、第１手続画面に表示された変更手続きによって行われた契約項目に対する、ユーザーからの登録内容の変更を受け付け、保険契約情報ＤＢに登録された登録内容の変更処理を行う変更処理部と、を備えることが開示されている。
【０００４】
また、例えば、特許文献３には、電子商取引により保険商品を取り扱う場合において、電子商取引による販売から、対面販売への引き継ぎを容易にすることを課題とし、団体保険の加入を受け付ける団体保険加入方法であって、加入者に配布された団体保険の募集資料に記載された二次元コードを読み取った携帯情報端末からのアクセスに基づいて、団体保険の加入申込用のＷｅｂページを携帯情報端末へ提供するＷｅｂページ提供段階と、提供段階で提供されたＷｅｂページへの、携帯情報端末からの情報の入力を受け付ける入力受付段階と、入力受付段階で受け付けられた情報が予め定められた条件を満たすと判断した場合に加入を受け付けた旨と共に情報を情報格納部に格納するとともに、条件を満たさないと判断した場合に、それまでに入力された情報の少なくとも一部を、予め登録された代理店端末に通知する判断段階とを備えることが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１７−１７４０２０号公報
【特許文献２】特開２０１７−１６２０８２号公報
【特許文献３】特開２０１６−１９２１４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
保険において、保険料の算定が行われている。例えば、生命保険の場合は、性別と年齢で定まっている生保標準生命表等が用いられている。
しかし、保険料の算定は、被保険者の健康に応じて、個別具体的にされるべきものであって、性別と年齢だけで算定されてしまうと、本来保険料が少なくても済む被保険者の負担が大きくなることがある。一方、個人の被保険者から信憑性のある健康情報を取得することは困難である。ただし、被保険者が属している会社等の組織では、信憑性のある健康情報を収集しており、さらに、残業時間等の組織だけが有している健康情報もある。そして、経営的視点から健康経営の指標も重視されてきている。また、被保険者は自由に保険者を選択して保険契約を行っているので、各保険者に健康情報を送信すること、逆に各組織から健康情報を収集することは煩雑である。
そこで、本発明は、以下に示すような情報処理装置、情報処理システム及び情報処理プログラムを提供することを目的としている。保険者側にとっては、個別具体的に保険料の算定を行うための被保険者の信憑性のある健康情報を取得できる。組織側にとっては、健康経営の指標ともなり得る情報を取得できる。被保険者側にとっては、保険者側からの利益を取得できる。さらに、組織側の機器と保険者側の機器との間で個別に通信を行うことを不要としている。
【課題を解決するための手段】
【０００７】
かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、組織側の機器から送信されてきた該組織に属する被保険者の健康に関する第１の情報を受信する第１の受信手段と、前記第１の情報を、前記被保険者に対応する保険者側の機器に送信する第１の送信手段と、前記保険者側の機器から送信されてきた前記被保険者への利益を含む第２の情報を受信する第２の受信手段と、前記第２の情報を前記組織側の機器に送信する第２の送信手段を有する情報処理装置である。
【０００８】
請求項２の発明は、前記第１の受信手段は、前記組織側の機器から能動的に送信されてきた前記第１の情報を受信し、前記第１の送信手段は、前記保険者側の機器からの要求にしたがって、前記第１の情報を送信し、前記第２の受信手段は、前記保険者側の機器から能動的に送信されてきた前記第２の情報を受信し、前記第２の送信手段は、本情報処理装置が能動的に送信する請求項１に記載の情報処理装置である。
【０００９】
請求項３の発明は、前記第１の情報と前記第２の情報は、前記組織の識別情報と前記保険者の識別情報を含み、該組織の識別情報と該保険者の識別情報以外の情報は、暗号化されている請求項１に記載の情報処理装置である。
【００１０】
請求項４の発明は、前記第１の情報は、前記保険者の公開鍵で暗号化されており、前記第２の情報は、前記組織の公開鍵で暗号化されている請求項３に記載の情報処理装置である。
【００１１】
請求項５の発明は、前記組織の識別情報と前記保険者の識別情報は、本情報処理装置の公開鍵で暗号化されており、受信した情報を本情報処理装置の秘密鍵で復号する復号手段と、前記復号手段によって、復号した情報を用いて、前記第１の情報又は前記第２の情報を管理する管理手段をさらに有する請求項４に記載の情報処理装置である。
【００１２】
請求項６の発明は、請求項１に記載の情報処理装置と、前記組織側の機器と、前記保険者側の機器を有しており、前記組織側の機器は、前記第１の情報を前記被保険者から収集する収集手段と、前記収集手段によって収集された第１の情報を前記情報処理装置に送信する第３の送信手段と、前記情報処理装置から送信されてきた前記第２の情報を受信する第３の受信手段と、前記第２の情報内の前記被保険者への利益にしたがって、該被保険者に割り当てられる利益を提示する提示手段を有しており、前記保険者側の機器は、前記情報処理装置から送信されてきた前記第１の情報を受信する第４の受信手段と、前記第１の情報にしたがって、前記被保険者への利益を算出する算出手段と、前記第２の情報を前記情報処理装置に送信する第４の送信手段を有する情報処理システムである。
【００１３】
請求項７の発明は、コンピュータを、組織側の機器から送信されてきた該組織に属する被保険者の健康に関する第１の情報を受信する第１の受信手段と、前記第１の情報を、前記被保険者に対応する保険者側の機器に送信する第１の送信手段と、前記保険者側の機器から送信されてきた前記被保険者への利益を含む第２の情報を受信する第２の受信手段と、前記第２の情報を前記組織側の機器に送信する第２の送信手段として機能させるための情報処理プログラムである。
【発明の効果】
【００１４】
請求項１の情報処理装置によれば、保険者側にとっては、個別具体的に保険料の算定を行うための被保険者の信憑性のある健康情報を取得でき、組織側にとっては、健康経営の指標ともなり得る情報を取得でき、被保険者側にとっては、保険者側からの利益を取得でき、さらに、組織側の機器と保険者側の機器との間で個別に通信を行うことを不要とすることができる。
【００１５】
請求項２の情報処理装置によれば、保険者側の機器からの要求があった後に第１の情報を送信し、他の通信は、送信側が能動的に送信することができる。
【００１６】
請求項３の情報処理装置によれば、組織の識別情報と保険者の識別情報以外の情報を暗号化によって保護することができる。
【００１７】
請求項４の情報処理装置によれば、第１の情報と第２の情報を、公開鍵暗号を用いて保護することができる。
【００１８】
請求項５の情報処理装置によれば、組織の識別情報と保険者の識別情報も、公開鍵暗号を用いて保護することができる。
【００１９】
請求項６の情報処理装置によれば、保険者側にとっては、個別具体的に保険料の算定を行うための被保険者の信憑性のある健康情報を取得でき、組織側にとっては、健康経営の指標ともなり得る情報を取得でき、被保険者側にとっては、保険者側からの利益を取得でき、さらに、組織側の機器と保険者側の機器との間で個別に通信を行うことを不要とすることができる。
【００２０】
請求項７の情報処理プログラムによれば、保険者側にとっては、個別具体的に保険料の算定を行うための被保険者の信憑性のある健康情報を取得でき、組織側にとっては、健康経営の指標ともなり得る情報を取得でき、被保険者側にとっては、保険者側からの利益を取得でき、さらに、組織側の機器と保険者側の機器との間で個別に通信を行うことを不要とすることができる。
【図面の簡単な説明】
【００２１】
【図１】本実施の形態（情報処理装置）の構成例についての概念的なモジュール構成図である。
【図２】本実施の形態（企業側サーバー）の構成例についての概念的なモジュール構成図である。
【図３】本実施の形態（生保側サーバー）の構成例についての概念的なモジュール構成図である。
【図４】本実施の形態を利用したシステム構成例を示す説明図である。
【図５】健康パケットのデータ構造例を示す説明図である。
【図６】健康データのデータ構造例を示す説明図である。
【図７】生保リターンデータのデータ構造例を示す説明図である。
【図８】本実施の形態による処理例を示すフローチャートである。
【図９】本実施の形態による処理例を示すフローチャートである。
【図１０】本実施の形態による処理例を示すフローチャートである。
【図１１】本実施の形態による処理例を示すフローチャートである。
【図１２】本実施の形態による処理例を示すフローチャートである。
【図１３】健康パケット管理テーブルのデータ構造例を示す説明図である。
【図１４】本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。
【発明を実施するための形態】
【００２２】
以下、図面に基づき本発明を実現するにあたっての好適な一実施の形態の例を説明する。
図１、図２、図３は、本実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係、ログイン等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態にしたがって、又はそれまでの状況・状態にしたがって定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、全ての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。また、「Ａ、Ｂ、Ｃ」等のように事物を列挙した場合は、断りがない限り例示列挙であり、その１つのみを選んでいる場合（例えば、Ａのみ）を含む。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。
【００２３】
本実施の形態である情報処理装置１００は、組織側の機器と保険者側の機器との間で通信を行い、被保険者の健康に関する情報等のやり取りを行うものであって、図１の例に示すように、通信（Ａ）モジュール１０５、暗号処理モジュール１２０、管理モジュール１３５、パケットＤＢ１４０、通信（Ｂ）モジュール１４５を有している。
ここで組織とは、組織形態を有しており、１人以上の被保険者が属しているものである。例えば、企業等がある。企業には、私企業と公企業が含まれており、私企業には個人企業、組合企業のほか、合名会社、合資会社、合同会社、株式会社等の会社企業がある。以下、主に企業を例示して説明する。なお、被保険者が組織から離脱（退職等）して個人になった場合も、保障の継続（本システムを用いたサービス）を受けられるようにしてもよい。その場合、図５の例を用いて後述する健康パケット５００の署名５１８を用いて、その個人がかつて組織に属していたことを証明する情報を記載させるようにしてもよい。
また、保険者とは、保険契約に基づいて、保険料を徴収し、保険事故の発生の際に保険金を支払う義務を負う者である。例えば、保険会社等がある。保険会社には、保険株式会社と保険相互会社が含まれている。保険には、国や地方自治体などの政府が運営する公営保険と民間会社が運営する私営保険（民営保険）が含まれており、生命保険事業と損害保険事業を含めてもよい。具体的には、（１）生命保険、（２）損害保険、（３）傷害保険・疾病保険・介護保険（第三分野の保険）の引き受けを行う事業を含めてもよい。なお、社会保険（健康保険、介護保険、厚生年金保険、厚生年金基金等）、労働保険（労災保険、雇用保険）等を含めてもよい。以下、主に生命保険を例示して説明する。
本実施の形態では、生命保険会社は、健康経営を推進している企業から、社員である被保険者（保険の契約者）の正確な健康情報（データ）を入手し、被保険者は、保険料の割引等の利益を得て、企業は、健康経営の指標ともなり得る情報を取得できるようにするものである。また、生命保険会社と企業とのデータのやり取りを安全に行うものである。
【００２４】
通信（Ａ）モジュール１０５は、受信（Ａ）モジュール１１０、送信（Ａ）モジュール１１５を有しており、暗号処理モジュール１２０と接続されている。通信（Ａ）モジュール１０５は、組織側の機器である企業側サーバー２００との通信を行う。
受信（Ａ）モジュール１１０は、企業側サーバー２００から送信されてきた組織に属する被保険者の健康に関する第１の情報を受信する。
また、受信（Ａ）モジュール１１０は、企業側サーバー２００から能動的に送信されてきた第１の情報を受信するようにしてもよい。第１の情報として、図５の例に示す健康パケット５００を用いて後述する。ここで能動的とは、情報処理装置１００からの要求（要請）がなくても、企業側サーバー２００が自発的に送信することをいう。ただし、情報処理装置１００は、管理モジュール１３５によるスケジュール管理にしたがって、締め切り日になったら（締め切り日に近くなったら）、企業側サーバー２００に対して催促するようにしてもよい。この場合も能動的に送信することに該当する。つまり、能動的とは、要求がなくても送信可能であることをいう。
【００２５】
なお、第１の情報は、組織の識別情報と保険者の識別情報を含み、その組織の識別情報とその保険者の識別情報以外の情報は、暗号化されていてもよい。この第１の情報は、保険者の公開鍵で暗号化されていてもよい。
さらに、第１の情報内の組織の識別情報と保険者の識別情報は、情報処理装置１００の公開鍵で暗号化されていてもよい。なお、第１の情報内の組織の識別情報と保険者の識別情報だけを対象として暗号化してもよいし、第１の情報全体（もちろんのことながら、組織の識別情報と保険者の識別情報が含まれている）を対象として暗号化してもよい。
送信（Ａ）モジュール１１５は、第２の情報を企業側サーバー２００に送信する。第２の情報として、図５の例に示す健康パケット５００を用いて後述する。
また、送信（Ａ）モジュール１１５は、情報処理装置１００が能動的に第２の情報を企業側サーバー２００に送信するようにしてもよい。
【００２６】
暗号処理モジュール１２０は、暗号化モジュール１２５、復号モジュール１３０を有しており、通信（Ａ）モジュール１０５、管理モジュール１３５、通信（Ｂ）モジュール１４５と接続されている。暗号処理モジュール１２０は、企業側サーバー２００、生保側サーバー３００との通信におけるデータの安全性を確保するために、通信対象である第１の情報、第２の情報の暗号処理を行う。
暗号化モジュール１２５は、送信（Ａ）モジュール１１５又は送信（Ｂ）モジュール１５０によって送信する情報に対して暗号化処理を行う。例えば、情報処理装置１００の秘密鍵を用いて暗号化するようにしてもよい。
復号モジュール１３０は、受信（Ａ）モジュール１１０又は受信（Ｂ）モジュール１５５によって受信した暗号化されている情報を復号する。例えば、情報処理装置１００の秘密鍵で復号するようにしてもよい。
なお、後述するように、健康パケット５００内の暗号化対象データ群５１０に対しては、情報処理装置１００で復号することはできず、情報処理装置１００においても、その内容を解読しない（解読することはできない）。暗号処理モジュール１２０による暗号化対象（復号対象）のデータは、健康パケット５００全体又は健康パケット５００内の暗号化対象データ群５１０以外のデータである。もちろんのことながら、健康パケット５００全体を復号したとしても、暗号化対象データ群５１０の部分は他の装置（企業側サーバー２００又は生保側サーバー３００）によって暗号化処理が施されているので、暗号化対象データ群５１０の部分は情報処理装置１００で復号しない（復号することはできない）。
【００２７】
管理モジュール１３５は、暗号処理モジュール１２０、パケットＤＢ１４０と接続されている。管理モジュール１３５は、企業側サーバー２００又は生保側サーバー３００から受信したデータをパケットＤＢ１４０に蓄積する。具体的には、復号モジュール１３０によって、復号した情報を用いて、第１の情報又は第２の情報を管理する。なお、企業側サーバー２００、生保側サーバー３００との通信をパケットとして管理しており、企業側サーバー２００から受け付けた第１の情報に対して、生保側サーバー３００にその第１の情報を送信し、生保側サーバー３００から第２の情報を受け付け、企業側サーバー２００にその第２の情報を送信することを管理する。
また、管理モジュール１３５は、企業側サーバー２００、生保側サーバー３００の通信におけるスケジュール管理をしてもよい。例えば、企業と生命保険会社との契約により、毎月１０日までに前月の第１の情報を企業側サーバー２００から生保側サーバー３００に送信し、毎月２０日までに前月の第２の情報を生保側サーバー３００から企業側サーバー２００に送信するようなスケジュールになっている場合に、そのスケジュールに合わせて、毎月１０日前に企業側サーバー２００から第１の情報が送信されていない場合は、その企業側サーバー２００に「送信期限が近い」旨を送信し、毎月２０日前に生保側サーバー３００から第２の情報が送信されていない場合は、生保側サーバー３００に「送信期限が近い」旨を送信するようにしてもよい。
【００２８】
パケットＤＢ１４０は、管理モジュール１３５と接続されている。パケットＤＢ１４０は、健康データである第１の情報又は第２の情報を蓄積する。例えば、健康パケット管理テーブル１３００を記憶している。図１３は、健康パケット管理テーブル１３００のデータ構造例を示す説明図である。健康パケット管理テーブル１３００は、健康パケットＩＤ欄１３０２、企業ＩＤ欄１３０４、生保ＩＤ欄１３０６、受信（Ａ）日時欄１３０８、送信（Ａ）日時欄１３１０、生データ（Ａ）欄１３１２、受信（Ｂ）日時欄１３１４、送信（Ｂ）日時欄１３１６、生データ（Ｂ）欄１３１８を有している。健康パケットＩＤ欄１３０２は、本実施の形態において、健康パケット（第１の情報又は第２の情報）を一意に識別するための情報（健康パケットＩＤ：ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）を記憶している。企業ＩＤ欄１３０４は、企業を一意に識別するための情報である企業ＩＤを記憶している。生保ＩＤ欄１３０６は、生命保険会社を一意に識別するための情報である生保ＩＤを記憶している。受信（Ａ）日時欄１３０８は、受信（Ａ）日時を記憶している。送信（Ａ）日時欄１３１０は、送信（Ａ）日時を記憶している。生データ（Ａ）欄１３１２は、第１の情報を記憶している。受信（Ｂ）日時欄１３１４は、受信（Ｂ）日時を記憶している。送信（Ｂ）日時欄１３１６は、送信（Ｂ）日時を記憶している。生データ（Ｂ）欄１３１８は、第２の情報を記憶している。具体的には、図８の例に示すＳｔｅｐ８０２の日時（年、月、日、時、分、秒、秒以下、又はこれらの組み合わせであってもよい）を受信（Ａ）日時欄１３０８に記憶させ、Ｓｔｅｐ８０６の日時を送信（Ａ）日時欄１３１０に記憶させ、Ｓｔｅｐ８０２又はＳｔｅｐ８０６で対象となったデータを生データ（Ａ）欄１３１２に記憶させ、Ｓｔｅｐ８０８の日時を受信（Ｂ）日時欄１３１４に記憶させ、Ｓｔｅｐ８１０の日時を送信（Ｂ）日時欄１３１６に記憶させ、Ｓｔｅｐ８０８又はＳｔｅｐ８１０で対象となったデータを生データ（Ｂ）欄１３１８に記憶させる。
【００２９】
通信（Ｂ）モジュール１４５は、送信（Ｂ）モジュール１５０、受信（Ｂ）モジュール１５５を有しており、暗号処理モジュール１２０と接続されている。通信（Ｂ）モジュール１４５は、保険者側の機器である生保側サーバー３００との通信を行う。
送信（Ｂ）モジュール１５０は、第１の情報を、被保険者に対応する生保側サーバー３００に送信する。
また、送信（Ｂ）モジュール１５０は、生保側サーバー３００からの要求にしたがって、第１の情報を生保側サーバー３００に送信するようにしてもよい。前述した能動的な送信とは異なり、生保側サーバー３００からの要求がない限り、生保側サーバー３００には送信しない。
受信（Ｂ）モジュール１５５は、生保側サーバー３００から送信されてきた被保険者への利益を含む第２の情報を受信する。この被保険者への利益として、少なくともその被保険者の保険料の割引率又は割引額に関する情報を含むようにしてもよい。
また、受信（Ｂ）モジュール１５５は、生保側サーバー３００から能動的に送信されてきた第２の情報を受信するようにしてもよい。
なお、第２の情報は、組織の識別情報と保険者の識別情報を含み、その組織の識別情報とその保険者の識別情報以外の情報は、暗号化されていてもよい。この第２の情報は、組織の公開鍵で暗号化されていてもよい。
さらに、第２の情報内の組織の識別情報と保険者の識別情報は、情報処理装置１００の公開鍵で暗号化されていてもよい。なお、第２の情報内の組織の識別情報と保険者の識別情報だけを対象として暗号化してもよいし、第２の情報全体（もちろんのことながら、組織の識別情報と保険者の識別情報が含まれている）を対象として暗号化してもよい。
送信（Ａ）モジュール１１５は、第２の情報を企業側サーバー２００に送信する。第２の情報として、図５の例に示す健康パケット５００を用いて後述する。
【００３０】
図２は、本実施の形態（組織側の機器の一例である企業側サーバー２００）の構成例についての概念的なモジュール構成図である。企業側サーバー２００は、組織側の意思によって用いられるものであればよく、組織によって所有されている必要もなく、組織側の敷地内に設置されている必要もない。
企業側サーバー２００は、通信モジュール２０５、従業員健康情報ＤＢ２２０、暗号処理モジュール２２５、健康処理モジュール２４０を有している。
【００３１】
通信モジュール２０５は、送信モジュール２１０、受信モジュール２１５を有しており、暗号処理モジュール２２５と接続されている。通信モジュール２０５は、情報処理装置１００との通信を行う。
送信モジュール２１０は、健康処理モジュール２４０によって収集された第１の情報を情報処理装置１００に送信する。
受信モジュール２１５は、情報処理装置１００から送信されてきた第２の情報を受信する。
【００３２】
従業員健康情報ＤＢ２２０は、暗号処理モジュール２２５、健康処理モジュール２４０と接続されている。従業員健康情報ＤＢ２２０は、組織に属している者の健康に関する情報を記憶している。例えば、第１の情報の一部である後述する図６の例に示した健康データ５１２等を記憶している。そして、従業員健康情報ＤＢ２２０は、組織に属している者に対する「被保険者への利益」を記憶している。例えば、第２の情報から抽出した後述する図７の例に示した生保リターンデータ５１４等を記憶していてもよい。
【００３３】
暗号処理モジュール２２５は、暗号化モジュール２３０、復号モジュール２３５を有しており、通信モジュール２０５、従業員健康情報ＤＢ２２０、健康処理モジュール２４０と接続されている。暗号処理モジュール２２５は、情報処理装置１００との通信におけるデータの安全性を確保するために、通信対象である第１の情報、第２の情報の暗号処理を行う。
暗号化モジュール２３０は、送信モジュール２１０によって送信する情報に対して暗号化処理を行う。例えば、保険者側の公開鍵を用いて暗号化処理を行う。さらに、情報処理装置１００の公開鍵を用いて暗号化するようにしてもよい。
復号モジュール２３５は、受信モジュール２１５によって受信した暗号化されている情報を復号する。例えば、組織側の秘密鍵で復号するようにしてもよい。
【００３４】
健康処理モジュール２４０は、従業員健康情報ＤＢ２２０、暗号処理モジュール２２５と接続されている。健康処理モジュール２４０は、第１の情報を被保険者から収集する。ここでの被保険者とは、この組織に属している者であって、保険者との契約を行っている者である。例えば、従業員（社員）、組合員等が該当する。
そして、健康処理モジュール２４０は、第２の情報内の被保険者への利益にしたがって、その被保険者に割り当てられる利益を提示する。また、第２の情報内に含まれている保険料の割引率又は割引額を用いて、健康経営の指標を算出してもよい。健康経営の指標として、例えば、保険料の割引率の統計的値（平均値、中央値、最頻値、最大値、最小値等）であってもよいし、保険料の割引額の統計的値（合計値、平均値、中央値、最頻値、最大値、最小値等）であってもよい。
【００３５】
また、健康処理モジュール２４０は、保険料の割引率又は割引額から、被保険者への給与支払額を増減（一般的には増額）してもよい。例えば、従業員である被保険者が健康であるため、保険料の割引が行われ、その分の金額が給与に加算されて支払いが行われるようにしてもよい。そのために、保険者から組織側に、保険料の割引率又は割引額に応じた金額が支払われる。さらに、組織側が信頼性のある健康データ（第１の情報）を提供していることから、その提供料が、保険者から組織側に支払われてもよい。さらに、組織側が従業員の健康を増進する活動を支援している場合は、その支援金等が、保険者から組織側に支払われてもよい。例えば、活動量計を従業員に支給し、その計測データを健康データ（第１の情報）に含めるようにしている場合等が該当する。
【００３６】
図３は、本実施の形態（保険者側の機器の一例である生保側サーバー３００）の構成例についての概念的なモジュール構成図である。
生保側サーバー３００は、通信モジュール３０５、保険者健康情報ＤＢ３２０、暗号処理モジュール３２５、リターン処理モジュール３４０を有している。
【００３７】
通信モジュール３０５は、送信モジュール３１０、受信モジュール３１５を有しており、暗号処理モジュール３２５と接続されている。通信モジュール３０５は、情報処理装置１００との通信を行う。
送信モジュール３１０は、リターン処理モジュール３４０によって生成された第２の情報を情報処理装置１００に送信する。
受信モジュール３１５は、情報処理装置１００から送信されてきた第１の情報を受信する。なお、受信モジュール３１５が第１の情報を受信するに際して、送信モジュール３１０は、情報処理装置１００に対して要求（第１の情報を送信する旨の要求）を送信してもよい。
【００３８】
保険者健康情報ＤＢ３２０は、暗号処理モジュール３２５、リターン処理モジュール３４０と接続されている。保険者健康情報ＤＢ３２０は、被保険者の健康に関する情報を記憶している。例えば、第１の情報から抽出した後述する図６の例に示した健康データ５１２等を記憶している。そして、保険者健康情報ＤＢ３２０は、被保険者に対する「被保険者への利益」を記憶している。例えば、第２の情報の一部である後述する図７の例に示した生保リターンデータ５１４等を記憶していてもよい。
【００３９】
暗号処理モジュール３２５は、暗号化モジュール３３０、復号モジュール３３５を有しており、通信モジュール３０５、保険者健康情報ＤＢ３２０、リターン処理モジュール３４０と接続されている。暗号処理モジュール３２５は、情報処理装置１００との通信におけるデータの安全性を確保するために、通信対象である第１の情報、第２の情報の暗号処理を行う。
暗号化モジュール３３０は、送信モジュール３１０によって送信する情報に対して暗号化処理を行う。例えば、組織側の公開鍵を用いて暗号化処理を行う。さらに、情報処理装置１００の公開鍵を用いて暗号化するようにしてもよい。
復号モジュール３３５は、受信モジュール３１５によって受信した暗号化されている情報を復号する。例えば、保険者側の秘密鍵で復号するようにしてもよい。
【００４０】
リターン処理モジュール３４０は、保険者健康情報ＤＢ３２０、暗号処理モジュール３２５と接続されている。リターン処理モジュール３４０は、受信モジュール３１５が受信した第１の情報にしたがって、被保険者への利益を算出する。そして、その被保険者についての第２の情報を生成する。例えば、「被保険者への利益」として、保険料の割引率又は割引額がある。性別、年齢から算出されている保険料から、健康診断データ、残業時間等を加味して保険料の割引率又は割引額を算出すればよい。例えば、過去の統計データ（残業時間と平均余命との関係等）から算出してもよいし、過去の統計データを教師データとして機械学習を行い、生成したモデルを用いて算出してもよい。
【００４１】
図４は、本実施の形態を利用したシステム構成例を示す説明図である。
企業側サーバー２００Ａ、ユーザー端末２５０Ａ、ユーザー端末２５０Ｂ、ユーザー端末２５０Ｃは、通信回線４９２Ａを介してそれぞれ接続されている。
企業側サーバー２００Ｂ、ユーザー端末２５０Ｄ、ユーザー端末２５０Ｅ、ユーザー端末２５０Ｆ、ユーザー端末２５０Ｇは、通信回線４９２Ｂを介してそれぞれ接続されている。
企業側サーバー２００Ｃ、ユーザー端末２５０Ｈ、ユーザー端末２５０Ｉは、通信回線４９２Ｃを介してそれぞれ接続されている。
生保側サーバー３００Ａ、ユーザー端末３５０Ａ、ユーザー端末３５０Ｂは、通信回線４９４Ａを介してそれぞれ接続されている。
生保側サーバー３００Ｂ、ユーザー端末３５０Ｃ、ユーザー端末３５０Ｄは、通信回線４９４Ｂを介してそれぞれ接続されている。
情報処理装置１００、企業側サーバー２００Ａ、企業側サーバー２００Ｂ、企業側サーバー２００Ｃ、生保側サーバー３００Ａ、生保側サーバー３００Ｂ、ユーザー端末４００Ａ、ユーザー端末４００Ｂは、通信回線４９０を介してそれぞれ接続されている。
通信回線４９２、通信回線４９４は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのイントラネット等であってもよい。
通信回線４９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット等であってもよい。
また、情報処理装置１００による機能は、クラウドサービスとして実現してもよい。
【００４２】
企業側サーバー２００は、人事部等で管理されており、残業情報、健康診断情報等を管理しており、また、従業員が用いているユーザー端末２５０から各人の健康情報を収集する。
生保側サーバー３００は、被保険者の健康情報を用いて、保険料の割引率又は割引額を算出する。
そして、企業側サーバー２００は、保険料の割引率又は割引額を用いて、各従業員の給与支払額等を算出する。
企業と生命保険会社の数は、Ｎ対Ｍ（Ｎ、Ｍは１以上の整数、ＮとＭは一般的には異なる数であるが、同じ数であってもよい。図４の例では、３対２）の関係となる。ただし、企業側サーバー２００Ａの従業員が生保側サーバー３００Ａと生保側サーバー３００Ｂの両方の生命保険会社と契約しているとは限らないので、各企業にとってはＭ以下の生命保険会社、又は、各生命保険会社にとってはＮ以下の企業との通信が情報処理装置１００を介して行われることになる。
もしも情報処理装置１００を介さずに通信を行う場合、つまり、企業側サーバー２００と生保側サーバー３００が直接通信を行う場合は、企業側サーバー２００は、従業員が契約している各生命保険会社の生保側サーバー３００の全てと通信を行い、逆に、生保側サーバー３００は、被保険者が所属している各企業の企業側サーバー２００の全てと通信を行う必要がある。また、保険契約の変更等も起こり得るので、通信する毎にそれらを調査し、通信先を決定することは煩雑である。
本実施の形態では、情報処理装置１００を介しているので、企業側サーバー２００、生保側サーバー３００は、情報処理装置１００との通信を行うだけで、各企業と各生命保険会社との間のやり取りができるようになる。
【００４３】
図５は、健康パケット５００のデータ構造例を示す説明図である。健康パケット５００は、第１の情報、第２の情報の具体的な例である。もちろんのことながら、第１の情報として、生保リターンデータ５１４、オプションデータ５１６、署名５１８を除外した健康パケット５００を用いてもよいし、第２の情報として、健康データ５１２、オプションデータ５１６、署名５１８を除外した健康パケット５００を用いてもよい。
健康パケット５００は、企業ＩＤ５０２、生保ＩＤ５０４、Ｔｏ日時５０６、Ｆｒｏｍ日時５０８、健康データ５１２、生保リターンデータ５１４、オプションデータ５１６、署名５１８で構成されている。
【００４４】
企業ＩＤ５０２は、企業ＩＤを記憶している。
生保ＩＤ５０４は、生保ＩＤを記憶している。
Ｔｏ日時５０６は、第１の情報の場合は、生保側サーバー３００に送信した日時を記憶している。第２の情報の場合は、企業側サーバー２００に送信した日時を記憶している。
Ｆｒｏｍ日時５０８は、第１の情報の場合は、企業側サーバー２００から受信した日時を記憶している。第２の情報の場合は、生保側サーバー３００から受信した日時を記憶している。なお、Ｔｏ日時５０６、Ｆｒｏｍ日時５０８は、情報処理装置１００によって生成される。
【００４５】
健康データ５１２は、被保険者の健康データを記憶している。具体的には、図６の例に示す健康データ５１２によって構成されている。
生保リターンデータ５１４は、生命保険会社が算出した保険料の割引率又は割引額等を記憶している。具体的には、図７の例に示す生保リターンデータ５１４によって構成されている。
オプションデータ５１６は、企業から生命保険会社への伝言、又は、生命保険会社から企業への伝言を記憶している。
署名５１８は、第１の情報の場合は、企業側を示すデータ（例えば、生命保険会社と取り決めた情報、具体的には、企業名、住所等）を企業側の秘密鍵で暗号されたデータを記憶している。受け取った情報処理装置１００、生保側サーバー３００は、企業側の公開鍵で復号して確認すればよい。第２の情報の場合は、生命保険会社側を示すデータ（例えば、企業側と取り決めた情報、具体的には、生命保険会社名、住所等）を生命保険会社側の秘密鍵で暗号されたデータを記憶している。受け取った情報処理装置１００、企業側サーバー２００は、生命保険会社側の公開鍵で復号して確認すればよい。
なお、前述したように、被保険者が組織から離脱して個人になった場合であっても、本システムを用いたサービスを受けられるようにしてもよい。具体的には、その個人のユーザー端末４００において、健康パケット５００を生成する際に、署名５１８内に、かつて組織に属していたことを証明する情報を記載しておき、情報処理装置１００又は生保側サーバー３００は、その署名５１８内の情報を確認し、企業側サーバー２００から送られてきたデータを同等に扱うようにしてもよい。
【００４６】
暗号化対象データ群５１０として、健康データ５１２、生保リターンデータ５１４、オプションデータ５１６を有している。暗号化対象データ群５１０は、企業側サーバー２００によって生命保険会社の公開鍵を用いて暗号化され、又は、生保側サーバー３００によって企業側の公開鍵を用いて暗号化される。
前述したように、企業側サーバー２００又は生保側サーバー３００は送信する際に、健康パケット５００全体を情報処理装置１００の公開鍵で暗号化してもよいし、健康パケット５００の暗号化対象データ群５１０以外の企業ＩＤ５０２、生保ＩＤ５０４、署名５１８（さらに、Ｔｏ日時５０６、Ｆｒｏｍ日時５０８を含めてもよい。以下、同様）を暗号化してもよい。受け取った情報処理装置１００は、情報処理装置１００の秘密鍵を用いて、健康パケット５００全体を復号してもよいし、健康パケット５００の暗号化対象データ群５１０以外の企業ＩＤ５０２、生保ＩＤ５０４、署名５１８を復号してもよい。そして、復号した企業ＩＤ５０２、生保ＩＤ５０４を用いて、送信先を決定する。また、情報処理装置１００は送信する際に、健康パケット５００全体を企業側サーバー２００又は生保側サーバー３００の公開鍵で暗号化してもよいし、健康パケット５００の暗号化対象データ群５１０以外の企業ＩＤ５０２、生保ＩＤ５０４、署名５１８を暗号化してもよい。受け取った企業側サーバー２００又は生保側サーバー３００は、企業側サーバー２００又は生保側サーバー３００の秘密鍵を用いて、健康パケット５００全体を復号してもよいし、健康パケット５００の暗号化対象データ群５１０以外の企業ＩＤ５０２、生保ＩＤ５０４、署名５１８を復号してもよい。
なお、企業側サーバー２００によって生成される第１の情報（又は生保側サーバー３００によって生成される第２の情報）の数は、保険契約数の数となる。したがって、月１回の処理が行われる場合は、毎月、各企業に属している従業員の保険契約数の第１の情報が発生することになる。
【００４７】
図６は、健康データ５１２のデータ構造例を示す説明図である。
健康データ５１２は、保険ＩＤ６０２、社員ＩＤ６０４、氏名６０６、生年月日６０８、性別６１０、住所６１２、健康診断日６１４、健康診断データ６１６、病歴６１８、診断データ６２０、残業データ６２２、有休取得データ６２４等で構成されている。
保険ＩＤ６０２は、生命保険会社にとって保険契約を一意に識別するための情報である。例えば、保険契約書番号等であってもよい。
社員ＩＤ６０４は、企業にとって従業員を一意に識別するための情報である。例えば、社員番号等であってもよい。
氏名６０６は、その保険契約者（従業員）の名前を記憶している。
生年月日６０８は、その保険契約者の生年月日を記憶している。
性別６１０は、その保険契約者の性別を記憶している。
住所６１２は、その保険契約者の住所を記憶している。
健康診断日６１４は、その保険契約者が健康診断（人間ドックを含む）を受けた日を記憶している。
健康診断データ６１６は、その健康診断の結果データを記憶している。
病歴６１８は、その保険契約者の病歴を記憶している。
診断データ６２０は、その病歴における診断データを記憶している。
残業データ６２２は、その保険契約者の残業時間を記憶している。
有休取得データ６２４は、その保険契約者の有給休暇の取得状況を記憶している。
この他に、健康データ５１２に、疾病休暇日数、在宅勤務日数、勤務状況、ストレステスト結果、産業医問診結果、レセプトデータ、歩数、カロリー摂取量、体重、体脂肪率、血圧、脈拍、睡眠時間、食事内容等の情報を含めてもよい。
【００４８】
生保側サーバー３００は、被保険者への利益を算出する以外に、以下の処理を行うようにしてもよい。
入院歴があった場合は、保険請求を促す旨のデータを生保リターンデータに含めて返信するようにしてもよい。
住所が契約書と異なっている場合は、住所変更を促す旨のデータを生保リターンデータに含めて返信するようにしてもよい。
さらに、保険請求の書類、住所変更の書類を被保険者に郵送するようにしてもよい。
【００４９】
図７は、生保リターンデータ５１４のデータ構造例を示す説明図である。
生保リターンデータ５１４は、生保割引率７０２、メッセージ７０４等で構成されている。
生保割引率７０２は、生保側サーバー３００が算出した被保険者への利益を記憶している。
メッセージ７０４は、生命保険会社から被保険者へのメッセージを記憶している。例えば、保険請求を促す旨、住所変更を促す旨等のメッセージである。
【００５０】
図８は、本実施の形態による処理例を示すフローチャートである。情報処理装置１００、企業側サーバー２００Ａ、生保側サーバー３００Ａによる通信処理例を示したものである。なお、前述したように、企業側サーバー２００と生保側サーバー３００はＮ対Ｍの関係にあるので、それぞれ複数あってもよい。
なお、本処理を行う前に、情報処理装置１００に参加する企業（企業側サーバー２００）、生命保険会社（生保側サーバー３００）が登録されている。また、「従業員の健康情報が、その従業員が契約している生命保険会社に開示されること」が、その従業員によって承認されている。
【００５１】
ステップＳ８０２では、企業側サーバー２００Ａは、情報処理装置１００に対して、健康パケット５００を能動的に送信（Ｐｕｓｈ）する。
ステップＳ８０４では、生保側サーバー３００Ａは、情報処理装置１００に対して、健康パケット５００を要請（Ｒｅｑｕｅｓｔ）する。
ステップＳ８０６では、情報処理装置１００は、ステップＳ８０４でのＲｅｑｕｅｓｔに応じて、生保側サーバー３００Ａに対して、ステップＳ８０２で受信した健康パケット５００を送信する。
ステップＳ８０８では、生保側サーバー３００Ａは、情報処理装置１００に対して、健康パケット５００を能動的に送信（Ｐｕｓｈ）する。
ステップＳ８１０では、情報処理装置１００は、企業側サーバー２００Ａに対して、ステップＳ８０８で受信した健康パケット５００を能動的に送信（Ｐｕｓｈ）する。
【００５２】
図９は、本実施の形態による処理例を示すフローチャートである。具体的には、図８の例に示したステップＳ８０２に対応する処理例を示すものである。
ステップＳ９０２では、企業側サーバー２００Ａの健康処理モジュール２４０は、従業員の健康データを収集し、従業員・生命保険会社の組み合わせ毎の健康パケット５００を生成する。なお、１人の従業員が１つの生命保険会社に複数の契約を行っている場合もあるので、その場合は、保険契約毎に健康パケット５００を生成してもよい。
ステップＳ９０４では、企業側サーバー２００Ａの暗号化モジュール２３０は、生保側サーバー３００Ａの公開鍵で健康パケット５００の暗号化対象データ群５１０を暗号化する。
ステップＳ９０６では、企業側サーバー２００Ａの暗号化モジュール２３０は、さらに、情報処理装置１００の公開鍵で健康パケット５００全体を暗号化する。
ステップＳ９０８では、企業側サーバー２００Ａの送信モジュール２１０は、暗号化した健康パケット５００を情報処理装置１００に送信する。
【００５３】
ステップＳ９１０では、情報処理装置１００の受信（Ａ）モジュール１１０は、企業側サーバー２００Ａから健康パケット５００を受信する。
ステップＳ９１２では、情報処理装置１００の復号モジュール１３０は、情報処理装置１００の秘密鍵で復号する。
ステップＳ９１４では、情報処理装置１００の管理モジュール１３５は、健康パケット５００の署名５１８をチェックする。
ステップＳ９１６では、情報処理装置１００の管理モジュール１３５は、健康パケット５００を、パケットＤＢ１４０内に生命保険会社別に蓄積する。この際に、健康パケット５００を受信した日時をＦｒｏｍ日時５０８に記入して蓄積する。
【００５４】
図１０は、本実施の形態による処理例を示すフローチャートである。具体的には、図８の例に示したステップＳ８０４、Ｓ８０６に対応する処理例を示すものである。
ステップＳ１００２では、生保側サーバー３００Ａの送信モジュール３１０は、情報処理装置１００に健康パケット５００の開示請求を送信する。
ステップＳ１００４では、情報処理装置１００の受信（Ｂ）モジュール１５５は、生保側サーバー３００Ａからの開示請求を受信する。
ステップＳ１００６では、情報処理装置１００の管理モジュール１３５は、生保側サーバー３００Ａ宛の健康パケット５００があるかをチェックする。
ステップＳ１００８では、情報処理装置１００の暗号化モジュール１２５は、生保側サーバー３００Ａの公開鍵で健康パケット５００全体を暗号化する。
【００５５】
ステップＳ１０１０では、情報処理装置１００の送信（Ｂ）モジュール１５０は、生保側サーバー３００Ａ宛の健康パケット５００を送信する。
ステップＳ１０１２では、生保側サーバー３００Ａの受信モジュール３１５は、情報処理装置１００からの健康パケット５００を受信する。
ステップＳ１０１４では、生保側サーバー３００Ａの復号モジュール３３５は、生保側サーバー３００Ａの秘密鍵で健康パケット５００を復号する。
ステップＳ１０１６では、生保側サーバー３００Ａの復号モジュール３３５は、生保側サーバー３００Ａの秘密鍵で暗号化対象データ群５１０を復号する。
ステップＳ１０１８では、生保側サーバー３００Ａのリターン処理モジュール３４０は、保険者健康情報ＤＢ３２０内に企業別に蓄積する。
【００５６】
図１１は、本実施の形態による処理例を示すフローチャートである。具体的には、図８の例に示したステップＳ８０８に対応する処理例を示すものである。
ステップＳ１１０２では、生保側サーバー３００Ａのリターン処理モジュール３４０は、保険者健康情報ＤＢ３２０内のデータを用いて、被保険者に対するリターンを算出する。
ステップＳ１１０４では、生保側サーバー３００Ａのリターン処理モジュール３４０は、被保険者毎の健康パケット５００を生成する。
ステップＳ１１０６では、生保側サーバー３００Ａの暗号化モジュール３３０は、企業側サーバー２００Ａの公開鍵で暗号化対象データ群５１０を暗号化する。
ステップＳ１１０８では、生保側サーバー３００Ａの暗号化モジュール３３０は、情報処理装置１００の公開鍵で健康パケット５００全体を暗号化する。
【００５７】
ステップＳ１１１０では、生保側サーバー３００Ａの送信モジュール３１０は、健康パケット５００を情報処理装置１００に送信する。
ステップＳ１１１２では、情報処理装置１００の受信（Ｂ）モジュール１５５は、生保側サーバー３００Ａからの健康パケット５００を受信する。
ステップＳ１１１４では、情報処理装置１００の復号モジュール１３０は、情報処理装置１００の秘密鍵で復号する。
ステップＳ１１１６では、情報処理装置１００の管理モジュール１３５は、健康パケット５００の署名５１８をチェックする。
ステップＳ１１１８では、情報処理装置１００の管理モジュール１３５は、パケットＤＢ１４０内に企業別に蓄積する。
【００５８】
図１２は、本実施の形態による処理例を示すフローチャートである。具体的には、図８の例に示したステップＳ８１０に対応する処理例を示すものである。
ステップＳ１２０２では、情報処理装置１００の管理モジュール１３５は、企業側サーバー２００Ａに送信すべき健康パケット５００はあるかをチェックする。
ステップＳ１２０４では、情報処理装置１００の暗号化モジュール１２５は、企業側サーバー２００Ａの公開鍵で健康パケット５００全体を暗号化する。
ステップＳ１２０６では、情報処理装置１００の送信（Ａ）モジュール１１５は、企業側サーバー２００Ａ宛の健康パケット５００を送信する。
ステップＳ１２０８では、企業側サーバー２００Ａの受信モジュール２１５は、情報処理装置１００からの健康パケット５００を受信する。
【００５９】
ステップＳ１２１０では、企業側サーバー２００Ａの復号モジュール２３５は、企業側サーバー２００Ａの秘密鍵で健康パケット５００を復号する。
ステップＳ１２１２では、企業側サーバー２００Ａの復号モジュール２３５は、企業側サーバー２００Ａの秘密鍵で暗号化対象データ群５１０を復号する。
ステップＳ１２１４では、企業側サーバー２００Ａの健康処理モジュール２４０は、各従業員にリターンに応じた処理を行う。
ステップＳ１２１６では、企業側サーバー２００Ａの健康処理モジュール２４０は、健康経営指標を算出する。
【００６０】
なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図１４に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ１４０１を用い、記憶装置としてＲＡＭ１４０２、ＲＯＭ１４０３、ＨＤ１４０４を用いている。ＨＤ１４０４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）を用いてもよい。通信（Ａ）モジュール１０５、受信（Ａ）モジュール１１０、送信（Ａ）モジュール１１５、暗号処理モジュール１２０、暗号化モジュール１２５、復号モジュール１３０、管理モジュール１３５、通信（Ｂ）モジュール１４５、送信（Ｂ）モジュール１５０、受信（Ｂ）モジュール１５５、通信モジュール２０５、送信モジュール２１０、受信モジュール２１５、暗号処理モジュール２２５、暗号化モジュール２３０、復号モジュール２３５、健康処理モジュール２４０、通信モジュール３０５、送信モジュール３１０、受信モジュール３１５、暗号処理モジュール３２５、暗号化モジュール３３０、復号モジュール３３５、リターン処理モジュール３４０等のプログラムを実行するＣＰＵ１４０１と、そのプログラムやデータを記憶するＲＡＭ１４０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ１４０３と、パケットＤＢ１４０、従業員健康情報ＤＢ２２０、保険者健康情報ＤＢ３２０としての機能を有する補助記憶装置（フラッシュ・メモリ等であってもよい）であるＨＤ１４０４と、キーボード、マウス、タッチスクリーン、マイク、カメラ（視線検知カメラ等を含む）等に対する利用者の操作（動作、音声、視線等を含む）に基づいてデータを受け付ける受付装置１４０６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置１４０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース１４０７、そして、それらをつないでデータのやり取りをするためのバス１４０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。
【００６１】
前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図１４に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１４に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続している形態でもよく、さらに図１４に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。
【００６２】
なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラムの全体又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分若しくは全部であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。
【符号の説明】
【００６３】
１００…情報処理装置
１０５…通信（Ａ）モジュール
１１０…受信（Ａ）モジュール
１１５…送信（Ａ）モジュール
１２０…暗号処理モジュール
１２５…暗号化モジュール
１３０…復号モジュール
１３５…管理モジュール
１４０…パケットＤＢ
１４５…通信（Ｂ）モジュール
１５０…送信（Ｂ）モジュール
１５５…受信（Ｂ）モジュール
２００…企業側サーバー
２０５…通信モジュール
２１０…送信モジュール
２１５…受信モジュール
２２０…従業員健康情報ＤＢ
２２５…暗号処理モジュール
２３０…暗号化モジュール
２３５…復号モジュール
２４０…健康処理モジュール
２５０…ユーザー端末
３００…生保側サーバー
３０５…通信モジュール
３１０…送信モジュール
３１５…受信モジュール
３２０…保険者健康情報ＤＢ
３２５…暗号処理モジュール
３３０…暗号化モジュール
３３５…復号モジュール
３４０…リターン処理モジュール
３５０、４００…ユーザー端末
４９０、４９２、４９４…通信回線
【図１】
2019091328.tif 000003
【図２】
2019091328.tif 000004
【図３】
2019091328.tif 000005
【図４】
2019091328.tif 000006
【図５】
2019091328.tif 000007
【図６】
2019091328.tif 000008
【図７】
2019091328.tif 000009
【図８】
2019091328.tif 000010
【図９】
2019091328.tif 000011
【図１０】
2019091328.tif 000012
【図１１】
2019091328.tif 000013
【図１２】
2019091328.tif 000014
【図１３】
2019091328.tif 000015
【図１４】
2019091328.tif 000016