特開 2022-191846 情報処理装置、情報処理プログラム及び情報処理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022191846

(43)【公開日】2022-12-28

(54)【発明の名称】情報処理装置、情報処理プログラム及び情報処理方法

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20221221BHJP

   G06Q 30/02 20120101ALI20221221BHJP

【ＦＩ】

G06Q50/10

G06Q30/02 470

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2021100309

(22)【出願日】2021-06-16

(71)【出願人】

【識別番号】000002897

【氏名又は名称】大日本印刷株式会社

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】米澤 拓央

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049BB08

5L049CC11

(57)【要約】

【課題】サービスの利用申込み毎に、個人情報の開示についての同意手続を省けるように、個人情報の包括的な開示を提案する情報処理装置等を提供すること。
【解決手段】情報処理装置は、生活者の利用状況に応じたサービスを選択する選択部と、サービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部から、選択したサービスに対応する個人情報項目を取得する第１取得部と、生活者ＩＤと、サービス提供者に開示同意済みの個人情報項目と、を生活者毎に対応付けて記憶する包括項目記憶部から、生活者の同意済みの個人情報項目を取得する第２取得部と、第１取得部が取得した個人情報項目と、第２取得部が取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定する特定部と、不足項目を、生活者へ通知する送信部とを備え、生活者の許諾に応じて不足項目を記憶する。
【選択図】図１７

【特許請求の範囲】

【請求項1】

生活者の利用状況に応じたサービスを選択する選択部と、
サービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部から、選択したサービスに対応する個人情報項目を取得する第１取得部と、
生活者ＩＤと、サービス提供者に開示同意済みの個人情報項目と、を生活者毎に対応付けて記憶する包括項目記憶部から、前記生活者の同意済みの個人情報項目を取得する第２取得部と、
前記第１取得部が取得した個人情報項目と、前記第２取得部が取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定する特定部と、
前記不足項目を前記生活者へ通知する送信部と
を備え、
前記生活者からの許諾に応じて前記不足項目を前記包括項目記憶部に記憶する
ことを特徴とする情報処理装置。

【請求項2】

前記項目記憶部は、サービスの分類毎に前記個人情報項目を対応付けて記憶し、
前記特定部は、選択されたサービスの分類を特定し、
前記送信部は、前記不足項目と特定した分類とを通知する
ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記通知は、前記不足項目を前記サービス提供者への開示を同意することにより受けられるサービスから得られる損益情報を含む
ことを特徴とする請求項１又は請求項２に記載の情報処理装置。

【請求項4】

前記生活者に類似し、前記各サービスに申し込んだ既存生活者を取得する生活者取得部と、
取得した既存生活者が前記各サービスに申し込んだ後に受けた損害及び利益を取得する損益取得部と、
前記各サービスを利用する際に前記既存生活者が提供した追加項目を取得する項目取得部と、
前記損害及び利益から、損益の履歴を作成する履歴作成部と、
前記各サービス及び追加項目の組み合わせ毎に、前記既存生活者の前記生活者に対する類似度を重みとして、前記損害及び利益から、予想損益を算出する損益算出部と、
を備え、
前記送信部は、前記損益の履歴及び前記予想損益を含む前記通知を、前記生活者へ送信する
ことを特徴とする請求項３に記載の情報処理装置。

【請求項5】

サービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部、並びに、生活者ＩＤと、サービス提供者に開示同意済みの個人情報項目と、を前記生活者毎に対応付けて記憶する包括項目記憶部を参照可能なコンピュータが、
生活者の利用状況に応じたサービスを選択し、
前記項目記憶部より、選択したサービスに対応する個人情報項目を取得し、
前記包括項目記憶部より、前記生活者の同意済みの個人情報項目を取得し、
前記項目記憶部より取得した個人情報項目と、前記包括項目記憶部より取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定し、
前記不足項目を前記生活者へ送信し、
前記生活者からの許諾に応じて前記不足項目を前記包括項目記憶部に記憶する
処理を前記コンピュータに実行させることを特徴とする情報処理プログラム。

【請求項6】

サービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部、並びに、生活者ＩＤと、サービス提供者に開示同意済みの個人情報項目と、を前記生活者毎に対応付けて記憶する包括項目記憶部を参照可能なコンピュータが、
生活者の利用状況に応じたサービスを選択し、
前記項目記憶部より、選択したサービスに対応する個人情報項目を取得し、
前記包括項目記憶部より、前記生活者の同意済みの個人情報項目を取得し、
前記項目記憶部より取得した個人情報項目と、前記包括項目記憶部より取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定し、
前記不足項目を前記生活者へ送信し、
前記生活者からの許諾に応じて前記不足項目を前記包括項目記憶部に記憶する
処理を実行することを特徴とする情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、個人情報の包括的な開示を提案する情報処理装置等に関する。

【背景技術】

【0002】

生活者がパーソナルデータ（個人情報）を情報銀行に予め登録することで、第三者が提供するサービスを生活者が利用する際に、情報銀行に登録しているパーソナルデータを第三者に渡すことにより、利用申込みの手続を簡便化するシステムが提案されている。当該システムは、生活者に利用申込み手続きが簡便となる利益を与えられるものの、第三者が自らのパーソナルデータを、適切に使用するかの不安を生活者に抱かせる可能性がある。このような状況に対して、特許文献１には、利活用するパーソナルデータの粒度に応じた利潤・リスクを生活者が把握した上で、利活用に同意する情報の粒度を選択できる利用同意管理装置が提案されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１５－１４１６４２号公報

【発明の概要】

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

【0004】

特許文献１に開示されているような従来技術においては、サービスの利用申込み毎に同意が必要であり、煩雑である。本発明はこのような状況に鑑みてなされたものである。その目的は、サービスの利用申込み毎に、個人情報の開示についての同意手続を省けるように、個人情報の包括的な開示を提案する情報処理装置等の提供である。

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

【0005】

本発明に係る情報処理装置は、生活者の利用状況に応じたサービスを選択する選択部と、サービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部から、選択したサービスに対応する個人情報項目を取得する第１取得部と、生活者ＩＤと、サービス提供者に開示同意済みの個人情報項目と、を生活者毎に対応付けて記憶する包括項目記憶部から、生活者の同意済みの個人情報項目を取得する第２取得部と、第１取得部が取得した個人情報項目と、第２取得部が取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定する特定部と、不足項目を生活者へ通知する送信部とを備え、生活者からの許諾に応じて不足項目を包括項目記憶部に記憶することを特徴とする。

【発明の効果】

【0006】

本発明によれば、個人情報の包括的な開示を提案することが可能となる。

【図面の簡単な説明】

【0007】

【図1】提案システムの構成例を示す説明図である。

【図2】提案サーバのハードウェア構成例を示すブロック図である。

【図3】ユーザ端末のハードウェア構成例を示すブロック図である。

【図4】ユーザＤＢの例を示す説明図である。

【図5】サービスＤＢの例を示す説明図である。

【図6】事業者ＤＢの例を示す説明図である。

【図7】履歴ＤＢの例を示す説明図である。

【図8】条件ＤＢの例を示す説明図である。

【図9】同意提案処理の手順例を示すフローチャートである。

【図10】予想損益算定処理の手順例を示すフローチャートである。

【図11】推薦理由生成処理の手順例を示すフローチャートである。

【図12】サービス提案処理の手順例を示すフローチャートである。

【図13】サービス情報登録画面の例を示す説明図である。

【図14】提案画面の例を示す説明図である。

【図15】提案設定画面の例を示す説明図である。

【図16】サービス提案画面の例を示す説明図である。

【図17】提案サーバの機能構成例を示すブロック図である。

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

【0008】

以下実施の形態を、図面を参照して説明する。図１は提案システムの構成例を示す説明図である。提案システムは、提案サーバ１（情報処理装置）、ユーザ端末２、事業者サーバ３及び事業者端末４を含む。提案サーバ１、ユーザ端末２、事業者サーバ３及び事業者端末４はネットワークＮにより、互いに通信可能に接続されている。図１においてユーザ端末２、事業者サーバ３及び事業者端末４は各１台を記載しているが、共に複数台を想定している。ユーザ端末２は生活者（以下、「ユーザ」ともいう。）が使用する端末である。事業者サーバ３は生活者にサービスを提供するサービス提供事業者が使用するコンピュータである。事業者端末４はサービス提供事業者が使用する端末である。

【0009】

提案サーバ１及び事業者サーバ３はサーバコンピュータ、ワークステーション、ＰＣ（Personal Computer）等で構成する。また、提案サーバ１又は事業者サーバ３を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン、又は量子コンピュータで構成してもよい。さらに、提案サーバ１又は事業者サーバ３の機能をクラウドサービスで実現してもよい。ユーザ端末２及び事業者端末４はスマートフォン、タブレットコンピュータ、ノートＰＣ等で構成する。

【0010】

図２は提案サーバのハードウェア構成例を示すブロック図である。提案サーバ１は制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５を含む。制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５はバスＢにより接続されている。

【0011】

制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（情報処理プログラム）を読み出して実行することにより、提案サーバ１に係る種々の情報処理、制御処理等を行う。

【0012】

主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。

【0013】

補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、ユーザＤＢ１３１、サービスＤＢ１３２、事業者ＤＢ１３３、履歴ＤＢ１３４及び条件ＤＢ１３５を記憶する。補助記憶部１３を提案サーバ１と別体で外部接続された外部記憶装置で構成してもよい。また、補助記憶部１３に記憶する各種ＤＢ等を、提案サーバ１と異なるデータベースサーバや、クラウドストレージに記憶してもよい。

【0014】

通信部１４はネットワークＮを介して、ユーザ端末２や事業者サーバ３と通信を行う。また、制御部１１が通信部１４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。読み取り部１５はＣＤ（Compact Disc）－ＲＯＭ及びＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１５を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。

【0015】

図３はユーザ端末のハードウェア構成例を示すブロック図である。ユーザ端末２は制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５、及び表示部２６を含む。各構成はバスＢで接続されている。

【0016】

制御部２１は、一又は複数のＣＰＵ、ＭＰＵ、ＧＰＵ等の演算処理装置を有する。制御部２１は補助記憶部２３に記憶された制御プログラム２Ｐにしたがい、ハードウェア各部を制御する。主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等である。主記憶部２２は主として制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。

【0017】

補助記憶部２３はハードディスク又はＳＳＤ等であり、制御部２１が処理を実行するために必要な制御プログラム２Ｐや各種データを記憶する。通信部２４はネットワークＮを介して、提案サーバ１や事業者サーバ３と通信を行う。また、制御部２１が通信部２４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、補助記憶部２３に記憶してもよい。

【0018】

入力部２５はキーボードやマウスである。表示部２６は液晶表示パネル等を含む。表示部２６は提案サーバ１が出力した包括同意条件に基づくパーソナルデータ提供の許諾提案等を表示する。また、入力部２５と表示部２６とを一体化し、タッチパネルディスプレイを構成してもよい。なお、ユーザ端末２は別体で外部接続した表示装置に表示を行ってもよい。

【0019】

事業者端末４は制御部４１、主記憶部４２、補助記憶部４３、通信部４４、入力部４５、及び表示部４６を含む。制御部４１、主記憶部４２、補助記憶部４３、通信部４４、入力部４５、及び表示部４６は、ユーザ端末２の制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５、及び表示部２６とそれぞれ同様な構成であるから、図示及び説明を省略する。

【0020】

次に、提案システム１００が使用するデータベースについて説明する。図４はユーザＤＢの例を示す説明図である。ユーザＤＢ１３１はユーザに関する情報を記憶する。ユーザＤＢ１３１は、ユーザＩＤ列、氏名列、生年月日列、住所列、身長列、体重列、クレジットカード列、アレルギー列、食材の好み列、年収列、家族構成列、保険情報列及び在宅情報列を含む。ユーザＩＤ列はユーザを一意に特定可能なユーザＩＤを記憶する。ユーザＩＤは、提案システムのユーザ登録時に提案サーバ１が発行する。ユーザＩＤはユーザを一意に特定可能なものであれば、提案サーバ１が発行するものではなくてもよい。例えば、ユーザＩＤを電子メールアドレスとしても良い。氏名列はユーザの氏名を記憶する。生年月日列はユーザの生年月日を記憶する。住所列はユーザの現住所を記憶する。身長列はユーザの身長を記憶する。体重列はユーザの体重を記憶する。クレジットカード列はユーザ名義のクレジットカードの番号を記憶する。アレルギー列はユーザが持つアレルギーを記憶する。ユーザが食物アレルギーを持つ場合、アレルギー症状を引き起こす食物の名称等を記憶する。食材の好み列はユーザが好む食材を記憶する。年収列はユーザの年収金額を記憶する。家族構成列はユーザの家族構成を記憶する。保険情報列はユーザが加入している生命保険、傷害保険等の情報を記憶する。在宅情報列はユーザが在宅している時間帯の情報を記憶する。ユーザ情報はパーソナルデータの一例である。

【0021】

図５はサービスＤＢの例を示す説明図である。サービスＤＢ１３２は事業者が提供するサービスに関する情報を記憶する。サービスＤＢ１３２はサービスＩＤ列、事業者列、サービス名列、サービスジャンル列、必須項目列、追加項目列、説明列及び目的列を含む。サービスＩＤ列はサービスを一意に特定可能なサービスＩＤを記憶する。サービスＩＤは例えば、サービスがサービスＤＢ１３２に登録される際に発行される。事業者列はサービスを提供する事業者の識別情報、例えば事業者の名称を記憶する。サービス名列はサービスの名称を記憶する。サービスジャンル列はサービスの業種、種別、提供形態等を記憶する。ジャンルは例えば、定期購入、保険、小売、健康等である。必須項目列はユーザがサービスの提供を受けるに当たり、事業者への提供が必須なパーソナルデータの項目を記憶する。追加項目列はユーザがサービスの提供を受けるに当たり、事業者への提供が望まれているパーソナルデータの項目を記憶する。説明列はサービス内容の説明を記憶する。目的列はパーソナルデータの項目を利用する目的を記憶する。必須項目列及び追加項目列に記憶されているパーソナルデータの項目は、サービスの利用に必要な個人情報項目の一例である。また、サービスＤＢは項目記憶部の一例である。サービスジャンル列に記憶するサービスの業種、種別、提供形態等は分類の一例である。分類の他例として、サービスを受けるための条件、例えばユーザの年齢、性別、居住地等をサービスＤＢ１３２に記憶してもよい。

【0022】

図６は事業者ＤＢの例を示す説明図である。事業者ＤＢ１３３は事業者に関する情報を記憶する。事業者ＤＢ１３３は事業者ＩＤ列、名称列、地域列、サービスＩＤ列、業種列及びプライバシーマーク列を含む。事業者ＩＤ列は事業者を一意に特定可能な事業者ＩＤを記憶する。事業者ＩＤは提案サーバ１が発行してもよいが、国税庁が付与する法人番号（「行政手続における特定の個人を識別するための番号の利用等に関する法律」により付与された番号）や信用調査会社が付与した企業コード等を使用してもよい。名称列は事業者の名称を記憶する。地域列は事業者が事業（サービス提供）を行なっている地域を記憶する。サービスＩＤ列は事業者が行なっている各事業を特定するサービスＩＤを記憶する。サービスＩＤは全事業者をとおして一意な値とする。事業者ＩＤと組み合わせることで、サービスＩＤが一意な値となるようにしてもよい。業種列は事業者の業種を記憶する。事業者が複数の事業を行なっており、事業毎に異なる業種であると判断される場合、サービスＩＤ毎に異なる業種を記憶してもよい。プライバシーマーク（登録商標）列は事業者がプライバシーマークの付与を受けているか否かを記憶する。例えば、プライバシーマークの付与を受けている場合は「済」を、プライバシーマークの付与を受けていない場合は「未」を、プライバシーマーク列は記憶する。プライバシーマーク以外に、事業者がＩＳＭＳ（Information Security Management System、情報セキュリティマネジメントシステム）認証をうけているか否かを、事業者ＤＢ１３３に記憶させてもよい。

【0023】

図７は履歴ＤＢの例を示す説明図である。履歴ＤＢ１３４はユーザのサービス利用履歴等の行動履歴を記憶する。履歴ＤＢ１３４はユーザＩＤ列、種別列、時刻列及び詳細列を含む。ユーザＩＤ列は行動したユーザのユーザＩＤを記憶する。種別列は行動の種別を記憶する。種別は例えば、サービス利用、サービス評価、サービス苦情、移動履歴、行動履歴、購買履歴、運転履歴、食事履歴、睡眠履歴、治療履歴、財務履歴、運動履歴等である。時刻列は行動が行われた日時を記憶する。日時は行動を開始した日時又は行動を終了した日時等である。詳細列は行動の詳細を記憶する。

【0024】

図８は条件ＤＢの例を示す説明図である。条件ＤＢ１３５はパーソナルデータの利用条件（包括同意条件）を記憶する。ユーザはユーザ登録時に利用条件を設定する。ユーザは必要に応じて、いつでも利用条件の設定を変更可能である。条件ＤＢ１３５はユーザＩＤ列、許可列、業種列、目的列、プライバシーマーク列及び地域列を含む。ユーザＩＤ列はユーザＩＤを記憶する。許可列は利用を許可するパーソナルデータの項目を記憶する。業種列はパーソナルデータの利用を許可する事業者の業種を記憶する。目的列は、どのような目的であれば、パーソナルデータの利用を許可するかを記憶する。例えば、目的列の値が「サービス向上」である場合、ユーザへ提供するサービスの向上を目的に、事業者が利用するのであれば、許可列に記憶している項目のパーソナルデータの利用を、ユーザは許可することを意味する。プライバシーマーク列は、パーソナルデータの利用を許可する事業者の条件として、プライバシーマークの付与を受けている必要があるか否かを記憶する。プライバシーマーク列の値が「要」である場合、パーソナルデータの利用は、プライバシーマークの付与を受けている事業者でなければ許可されない。プライバシーマーク列の値が「不要」である場合、事業者がプライバシーマークの付与を受けているか否かに関わらず、他の条件を満たせば、パーソナルデータの利用は許可される。地域列は、サービスの提供地域の条件を記憶する。例えば、地域列の値が「関東」である場合、サービス提供地域が関東地方であるサービスのためにパーソナルデータを利用する場合であって、他の条件を満たせば、パーソナルデータの利用は許可される。条件ＤＢ１３５は包括項目記憶部の一例である。許可列が記憶するパーソナルデータの項目は、サービス提供者に開示同意済みの個人情報項目の一例である。

【0025】

次に、提案システム１００が行う情報処理について説明する。図９は同意提案処理の手順例を示すフローチャートである。同意提案処理は所定のタイミングで、提案対象となるユーザを特定して実行する。提案サーバ１の制御部１１はサービスＤＢ１３２からサービスの一覧を取得する（ステップＳ１）。制御部１１は処理対象とするサービスを選択する（ステップＳ２）。制御部１１は選択したサービスについて、予想損益を算定する（ステップＳ３）。予想損益の算定については後述する。制御部１１はすべてのサービスについて予想損益の算定が完了したか否かを判定する（ステップＳ４）。制御部１１は算定が完了していないと判定した場合（ステップＳ４でＮＯ）、処理をステップＳ２に戻し、未完了のサービスについての処理を行う。制御部１１は算定が完了したと判定した場合（ステップＳ４でＹＥＳ）、提案の候補となるサービスとサービスを利用する際に提供を求めるパーソナルデータ項目（追加項目）とを選択する（ステップＳ５）。例えば制御部１１は、損害が一定以下であり利益が大きいサービスと、そのときの追加項目の組み合わせとを、上位からいくつか選択する。制御部１１はサービスＤＢ１３２、事業者ＤＢ１３３を参照し、選択したサービスに共通する包括同意条件を抽出する（ステップＳ６）。包括同意条件は業種、利用目的、事業者の地域、追加項目等である。制御部１１は条件ＤＢ１３５を参照し、包括同意条件の中で、ユーザが既に同意している条件（同意済条件）を削除する（ステップＳ７）。ユーザが既に同意している条件に含まれるパーソナルデータ項目は、同意済みの個人情報項目の一例である。ステップＳ７後に残ったパーソナルデータ項目は、同意済みの個人情報項目に不足している不足項目の一例である。制御部１１は包括同意条件に従ったパーソナルデータの提供許諾を薦める理由（推薦理由）を生成する（ステップＳ８）。推薦理由の生成については後述する。制御部１１は包括同意条件と推薦理由とを含む提案をユーザ端末２へ送信する（ステップＳ９）。送信方法はプッシュ通知、電子メール、ＳＭＳ（Short Message Service）等である。制御部１１はユーザ端末２から回答を受信する（ステップＳ１０）。制御部１１は回答が「許諾」であるか否かを判定する（ステップＳ１１）。制御部１１は回答が「許諾」であると判定した場合（ステップＳ１１でＹＥＳ）、包括同意条件を条件ＤＢ１３５に記憶し（ステップＳ１２）、処理を終了する。制御部１１は回答が「許諾」でないと判定した場合（ステップＳ１１でＮＯ）、処理を終了する。回答が「許諾」でなかった場合、その履歴（提案内容と提案日時）を補助記憶部１３に記憶しておいてもよい。期間を空けずに再度、同じ提案がユーザに送信されないようにするためである。

【0026】

図１０は予想損益算定処理の手順例を示すフローチャートである。予想損益算定処理は図９のステップＳ３に対応する処理である。制御部１１は履歴ＤＢ１３４を参照して、対象のサービスを利用しているユーザの一覧を取得する（ステップＳ２１）。制御部１１は一覧に含まれるユーザから、提案対象となっているユーザと類似するユーザを抽出する（ステップＳ２２）。制御部１１は、パーソナルデータが似ている、利用中のサービスが似ている、行動履歴が似ているユーザ（類似ユーザ）を抽出する。例えば、パーソナルデータ、利用中のサービス、行動履歴をベクトルで表現し、コサイン類似度を用いて、二人のユーザが似ているか否かを判定する。制御部１１は類似ユーザの中から処理するユーザを選択する（ステップＳ２３）。制御部１１は選択したユーザ（既存生活者）がサービスに申し込んだ後に受けた損害と得た利益とに関する履歴を履歴ＤＢ１３４から取得する（ステップＳ２４）。制御部１１はサービスを申し込んだ際に、ユーザが提供した追加項目を取得する（ステップＳ２５）。制御部１１は、サービス及び追加項目、損害及び利益、並びに、類似するユーザ及び類似度を対応付けて一時記憶領域に記憶する（ステップＳ２６）。一時記憶領域は主記憶部１２、補助記憶部１３等に設ける。制御部１１は類似するユーザ全てについて処理を完了したか否かを判定する（ステップＳ２７）。制御部１１は完了してないと判定した場合（ステップＳ２７でＮＯ）、処理をステップＳ２３に戻し、未処理の類似ユーザに対しての処理を行う。制御部１１は完了したと判定した場合（ステップＳ２７でＹＥＳ）、一時記憶領域に記憶したデータを基に、サービスと追加項目の組み合わせ毎に、ユーザの類似度を重みとして、損害と利益との重み付き平均を算出する（ステップＳ２８）。算出した重み平均値を予想損益とする。制御部１１は処理を呼び出し元に戻す。制御部１１は図９のステップＳ４以降を実行する。

【0027】

図１１は推薦理由生成処理の手順例を示すフローチャートである。推薦理由生成処理は図９のステップＳ８に対応する処理である。制御部１１は類似ユーザの中から、類似度の特に高いユーザ（高類似度ユーザ）を選択する（ステップＳ４１）。制御部１１は高類似度ユーザと、包括同意条件の元になったサービスに関する損益の詳細記録を履歴ＤＢ１３４から取得する（ステップＳ４２）。制御部１１は詳細記録から個人を特定するデータを削除する（ステップＳ４３）。制御部１１は履歴ＤＢ１３４を参照し、類似する記録を持つユーザ（記録類似ユーザ）の数を算出する（ステップＳ４４）。制御部１１は記録類似ユーザの数が所定の閾値以上であるか否かを判定する（ステップＳ４５）。制御部１１は記録類似ユーザの数が閾値未満であると判定した場合（ステップＳ４５でＮＯ）、データ粒度が荒くなるように詳細記録を変更する（ステップＳ４６）。例えば、「家事時間が１時間短縮」という利益を「家事時間が短縮」に変更する。制御部１１は処理をステップＳ４４へ戻し、データ粒度を変更した後の記録を用いて、再度、記録類似ユーザの数を算出する（ステップＳ４４）。制御部１１は記録類似ユーザの数が閾値以上であると判定した場合（ステップＳ４５でＹＥＳ）、推薦理由を生成する（ステップＳ４７）。推薦理由は、損益の詳細記録と、記録類似ユーザの平均損益とを引用する。損益の詳細記録と記録類似ユーザの平均損益とは損益情報の一例である。例えば、「この包括同意条件を設定すると、○○サービスが使えるようになります。あなたに類似するユーザは、このサービスに登録した後に、買い物時間が短縮する利益や月の支出が平均で５００円増加する損害の事例がありました。類似するユーザの平均損益は…でした。」が生成される推薦理由である。制御部１１は処理を呼び出し元へ戻す。制御部１１は図９のステップＳ９以降を実行する。

【0028】

図１２はサービス提案処理の手順例を示すフローチャートである。サービス提供事業者（以下、単に「事業者」とも記す。）は事業者端末４に表示されたメニュー一覧から、サービス提案を選択する。事業者端末４の制御部４１はサービス提案の実行要求を提案サーバ１へ送信する（ステップＳ６１）。提案サーバ１の制御部１１はサービス提案の実行要求を受信する（ステップＳ６２）。制御部１１は設定画面を生成し、事業者端末４へ送信する（ステップＳ６３）。事業者端末４の制御部４１は設定画面を受信し、表示部４６に表示する（ステップＳ６４）。事業者は入力部４５を用いて提案したいサービス（提案サービス）や提案対象とするユーザの条件を設定する。制御部４１は設定を受け付ける（ステップＳ６５）。制御部４１は設定を提案サーバ１へ送信する（ステップＳ６６）。提案サーバ１の制御部１１は受信した設定に基づき、対象ユーザを抽出する（ステップＳ６７）。対象となるユーザは次の条件を満たしているユーザである。設定で指定した項目の提供を対象となっている事業者や提案サービスに対して同意しているユーザである。同意は包括同意でもよいし、個別同意でもよい。提案サービスを受けるのに必要なパーソナルデータ項目（必須項目）の提供に同意しているユーザである。当該同意についても包括同意でもよいし、個別同意でもよい。すなわち、対象ユーザは、設定条件に適合しているユーザであり、提案サービスをまだ利用していないユーザである。制御部１１はメッセージ入力画面を生成し、事業者端末４へ送信する（ステップＳ６８）。事業者端末４の制御部４１はメッセージ入力画面を受信し、表示部４６に表示する（ステップＳ６９）。事業者は入力部４５を用いてユーザ向けのメッセージを入力する。制御部４１はメッセージを受ける（ステップＳ７０）。制御部４１はメッセージを提案サーバ１へ送信する（ステップＳ７１）。提案サーバ１の制御部１１はメッセージを受信する（ステップＳ７２）。制御部１１はメッセージを含むユーザへの提案を作成する（ステップＳ７３）。制御部１１は提案をステップＳ６７で抽出した対象ユーザのユーザ端末２へ送信する（ステップＳ７４）。送信方法はプッシュ通知、電子メール、ＳＭＳ等である。ユーザ端末２の制御部２１は提案を受信し、表示部２６に表示する（ステップＳ７５）。提案を参照したユーザは入力部２５を用いて回答を入力する。制御部２１は回答を受け付け、提案サーバ１へ送信する（ステップＳ７６）。提案サーバ１の制御部１１は回答を受信する（ステップＳ７７）。制御部１１は回答がサービス申込みか否かを判定する（ステップＳ７８）。制御部１１は回答がサービス申込みでないと判定した場合（ステップＳ７８でＮＯ）、処理を終了する。制御部１１は回答がサービス申込みであると判定した場合（ステップＳ７８でＹＥＳ）、申込みがあった旨の情報と共に提案サービスに必要なパーソナルデータを事業者端末４へ送信する（ステップＳ７９）。事業者端末４の制御部４１は申込みがあった旨の情報とパーソナルデータとを受信する（ステップＳ８０）。制御部４１は申込み手続きを行い（ステップＳ８１）、処理を終了する。申込み手続きでは、例えば制御部４１は受信したパーソナルデータを事業者サーバ３へ送信し、事業者の使用するデータベースに記憶する。

【0029】

続いて、提案システム１００で利用する画面の例を示す。図１３はサービス情報登録画面の例を示す説明図である。サービス情報登録画面ｄ０１は、事業者が提供しているサービスを新たに提案システム１００へ登録する際に用いる画面である。サービス情報登録画面ｄ０１は名称欄ｄ０１１、編集ボタンｄ０１２、必須ボックスｄ０１３、説明欄ｄ０１４、目的欄ｄ０１５、追加ボタンｄ０１６及びキャンセルボタンｄ０１７を含む。名称欄ｄ０１１はサービス名称を入力する。編集ボタンｄ０１２はサービス利用者へ提供を求めるパーソナルデータ項目の追加又は削除を行う。項目が設定されていない場合、編集ボタンｄ０１２は「追加」を表示する。項目が設定されている場合、編集ボタンｄ０１２は「削除」を表示する。編集ボタンｄ０１２が「追加」を表示している場合、編集ボタンｄ０１２を選択すると、未だ選択されていないパーソナルデータの項目一覧が表示され、事業者は追加する項目を選択できる。編集ボタンｄ０１２は「削除」を表示している場合、編集ボタンｄ０１２を選択すると、対応するパーソナルデータ項目が削除される。パーソナルデータ項目の中で提供が必須の項目については、必須ボックスｄ０１３にチェックを入れる。説明欄ｄ０１４にはサービスについての説明を入力する。目的欄ｄ０１５は提供受けるパーソナルデータの利用目的を記入する。追加ボタンｄ０１６を選択すると、入力内容が提案サーバ１へ送信される。提案サーバ１は受信した内容をサービスＤＢ１３２に記憶する。キャンセルボタンｄ０１７を選択すると、サービス登録を中止し、前画面に戻る。

【0030】

図１４は提案画面の例を示す説明図である。提案画面ｄ０２は、ユーザに包括同意条件を示し、当該条件を満たす場合には、ユーザに確認不要でパーソナルデータを事業者に提供することへの許諾を提案する画面である。提案画面ｄ０２は、ジャンル欄ｄ０２１、目的欄ｄ０２２、項目欄ｄ０２３、理由欄ｄ０２４、許諾ボタンｄ０２５及び拒否ボタンｄ０２６を含む。ジャンル欄ｄ０２１はデータ提供の対象となる事業者の業種等を表示する。目的欄ｄ０２２はパーソナルデータを利用する目的を表示する。項目欄ｄ０２３は提供を求めているパーソナルデータの項目を表示する。理由欄ｄ０２４は包括同意を推薦する理由を表示する。許諾ボタンｄ０２５を選択すると、包括同意条件に従ったパーソナルデータの提供を許諾する旨が、提案サーバ１へ送信される。拒否ボタンｄ０２６を選択すると、包括同意条件に従ったパーソナルデータの提供を許諾しない旨が、提案サーバ１へ送信される。

【0031】

図１５は提案設定画面の例を示す説明図である。提案設定画面ｄ０３は、事業者がユーザに自社サービスの利用を提案する際に、対象ユーザ、提案内容等の設定を行う画面である。提案設定画面ｄ０３はサービスメニューｄ０３１、項目メニューｄ０３２、条件値メニューｄ０３３、関係メニューｄ０３４、提案文欄ｄ０３５、送信ボタンｄ０３６及びキャンセルボタンｄ０３７を含む。サービスメニューｄ０３１は提案するサービスを選択するプルダウンメニューである。事業者が提案システム１００に登録しているサービスがサービスメニューｄ０３１に表示される。項目メニューｄ０３２、条件値メニューｄ０３３、関係メニューｄ０３４は提案対象とするユーザの条件を設定するメニューである。項目メニューｄ０３２は参照するパーソナルデータの項目（参照項目）を設定するメニューである。図１５では「アクティビティ」が選択されている。条件値メニューｄ０３３は、参照項目に基づいて各ユーザが提案対象であるか否かを判定する際に条件となる値（条件値）を設定するメニューである。図１５では「フィットネス」が選択されている。条件値メニューｄ０３３の内容は、項目メニューｄ０３２で選択された項目により動的に変化する。関係メニューｄ０３４は、関係演算子等を設定するためのメニューである。参照項目と条件値とが指定された関係演算子で示す関係を満たす場合、ユーザを提案対象と判断する。図１５では「含む」が選択されている。関係メニューｄ０３４の内容は、項目メニューｄ０３２で選択された項目、条件値メニューｄ０３３で選択された値により動的に変化する。図１５では、項目メニューｄ０３２、条件値メニューｄ０３３、関係メニューｄ０３４の設定により、履歴ＤＢ１３４に「アクティビティ」として、「フィットネス」が含まれているユーザが、今回の提案対象のユーザとなる。提案文欄ｄ０３５には、ユーザへの提案文を入力する。送信ボタンｄ０３６を選択すると、項目メニューｄ０３２、条件値メニューｄ０３３及び関係メニューｄ０３４の設定、並びに、提案文欄ｄ０３５に入力された提案文が、提案サーバ１へ送信される。

【0032】

提案設定画面ｄ０３において、対象ユーザの人数等が確認できる確認ボタンを設けてもよい。当該確認ボタンを選択すると、項目メニューｄ０３２、条件値メニューｄ０３３及び関係メニューｄ０３４の設定が、提案サーバ１へ送信される。提案サーバ１は当該設定による条件に合致するユーザの人数を算出し、提案設定画面ｄ０３に表示する。人数のみでなく、男女比、年代別人数等を表示してもよい。事業者は表示された結果を見て、必要に応じて、項目メニューｄ０３２、条件値メニューｄ０３３及び関係メニューｄ０３４の設定変更や、提案文欄ｄ０３５に入力する内容の検討を行う。

【0033】

図１６はサービス提案画面の例を示す説明図である。サービス提案画面ｄ０４は、事業者からユーザへのサービス利用提案を行う画面である。当該画面は提案サーバ１からユーザ端末２へ送信され、表示部２６に表示される。サービス提案画面ｄ０４は、提案メッセージ領域ｄ０４１、申込みボタンｄ０４２及びキャンセルボタンｄ０４３を含む。提案メッセージ領域ｄ０４１は、ユーザへサービス利用を促す提案メッセージを表示する。提案メッセージには、提案設定画面ｄ０３にて事業者が入力した提案文が含まれている。申込みボタンｄ０４２を選択すると、利用申込みする旨が提案サーバ１へ送信される。キャンセルボタンｄ０４３を選択すると、サービス提案画面ｄ０４は閉じられる。なお、サービス提案画面ｄ０４において、事業者がサービスを提供するにあたり、必要とするパーソナルデータ項目について、利用許諾を求めるメッセージが表示されていないのは、当該ユーザが包括同意条件による許諾を行なっているからである。なお、サービス提案画面ｄ０４に事業者の業種、提供地域等のサービスの分類を表示してもよい。

【0034】

以上のように、本実施の形態においては、包括同意条件に基づくパーソナルデータ提供の許諾提案をユーザへ行う。当該提案に従い、ユーザがパーソナルデータの提供を許諾しておけば、ユーザが新たなサービスを利用する際に、パーソナルデータ提供の許諾を改めて求められることはないので、ユーザの利便性が向上する。また、包括同意条件に基づくパーソナルデータ提供の許諾提案を行う際には、ユーザが許諾した場合に得られる損益の情報を含めるので、ユーザは許諾するか拒否するかを的確に判断することが可能となる。以上の結果、事業者は、サービス提供に当たり必要なパーソナルデータが確実に得られるので、ユーザに則した質の高いサービスが提供可能となる。

【0035】

図１７は提案サーバの機能構成例を示すブロック図である。提案サーバ１は機能部として、選択部１１ａ、第１取得部１１ｂ、第２取得部１１ｃ、特定部１１ｄ、及び、送信部１１ｅを備える。これらの各機能部は、制御部１１が制御プログラム１Ｐに基づいて動作することにより、実現される。

【0036】

選択部１１ａは生活者の利用状況に応じたサービスを選択する。第１取得部１１ｂはサービスＩＤと、サービスの利用に必要な個人情報項目と、をサービス毎に対応付けて記憶する項目記憶部から、選択したサービスに対応する個人情報項目を取得する。第２取得部１１ｃは生活者ＩＤと、がサービス提供者に開示同意済みの個人情報項目と、を生活者毎に対応付けて記憶する包括項目記憶部から、生活者の同意済みの個人情報項目を取得する。特定部１１ｄは第１取得部が取得した個人情報項目と、第２取得部が取得した個人情報項目と、を比較し、同意済みの個人情報項目に不足している不足項目を特定する。送信部１１ｅは不足項目を生活者へ通知する。

【0037】

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

【符号の説明】

【0038】

１００ 提案システム
１ 提案サーバ
１１ 制御部
１１ａ 選択部
１１ｂ 第１取得部
１１ｃ 第２取得部
１１ｄ 特定部
１１ｅ 送信部
１２ 主記憶部
１３ 補助記憶部
１３１ ユーザＤＢ
１３２ サービスＤＢ
１３３ 事業者ＤＢ
１３４ 履歴ＤＢ
１３５ 条件ＤＢ
１４ 通信部
１５ 読み取り部
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ ユーザ端末
２１ 制御部
２２ 主記憶部
２３ 補助記憶部
２４ 通信部
２５ 入力部
２６ 表示部
２Ｐ 制御プログラム
３ 事業者サーバ
４ 事業者端末
４１ 制御部
４２ 主記憶部
４３ 補助記憶部
４４ 通信部
４５ 入力部
４６ 表示部
Ｂ バス
Ｎ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】