(57)【要約】【課題】提案の根拠となる評価情報を含むサービスの提案情報を出力する提案出力装置等の提供【解決手段】提案出力装置は、ユーザ情報、ユーザが利用するサービス、サービスを利用したサービス履歴を記憶する記憶部と、対象ユーザの特徴を参照し、該対象ユーザに類似する類似ユーザを特定する特定部と、類似ユーザのサービス履歴を記憶部から抽出する抽出部と、ユーザ毎に利用されたサービスの評価を行い、評価情報を生成する評価部と、対象ユーザ宛に抽出したサービス及びサービスの対象ユーザに対応する評価情報を含む提案情報を出力する出力部とを備える。【選択図】図２
2020197925.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ情報、ユーザが利用するサービス、該サービスを利用したサービス履歴を記憶する記憶部と、
対象ユーザの特徴を参照し、該対象ユーザに類似する類似ユーザを特定する特定部と、
前記類似ユーザのサービス履歴を前記記憶部から抽出する抽出部と、
ユーザ毎に利用された前記サービスの評価を行い、評価情報を生成する評価部と、
前記対象ユーザ宛に抽出した前記サービス及び前記サービスの対象ユーザに対応する評価情報を含む提案情報を出力する出力部と
を備えることを特徴とする提案出力装置。
【請求項２】
前記評価情報は、ユーザが受ける損益情報が含まれ、
前記損益情報に基づき、利益が損失を上回るサービスを選択する選択部
を備えることを特徴とする請求項１に記載の提案出力装置。
【請求項３】
前記出力部は、複数の提案情報を該提案情報に係るサービスについてのメリットと共に出力する
ことを特徴とする請求項１又は請求項２に記載の提案出力装置。
【請求項４】
前記評価部は、前記サービス利用開始前後の前記類似ユーザについての時間利用パターン、購買パターン若しくは生体データパターン、又は前記サービスに対する評価、前記サービスに対する苦情件数若しくは前記サービスの継続利用年数に基づき、前記サービスの評価を行う
ことを特徴とする請求項１から請求項３の何れか１項に記載の提案出力装置。
【請求項５】
前記対象ユーザから要求を受け付ける受付部を備え、
前記特定部、前記抽出部、前記評価部及び前記出力部は、前記受付部が前記要求を受付後に処理を行う
ことを特徴とする請求項１から請求項４の何れか１項に記載の提案出力装置。
【請求項６】
ユーザ情報、ユーザが利用するサービス、該サービスを利用したサービス履歴を記憶する記憶部にアクセス可能なコンピュータが、
対象ユーザの特徴を参照し、該対象ユーザに類似する類似ユーザを特定し、
前記類似ユーザのサービス履歴を前記記憶部から抽出し、
ユーザ毎に利用された前記サービスの評価を行い、評価情報を生成し、
前記対象ユーザ宛に抽出した前記サービス及び前記サービスの対象ユーザに対応する評価情報を含む提案情報を出力する
ことを特徴とする提案出力方法。
【請求項７】
ユーザ情報、ユーザが利用するサービス、該サービスを利用したサービス履歴を記憶する記憶部にアクセス可能なコンピュータに、
対象ユーザの特徴を参照し、該対象ユーザに類似する類似ユーザを特定し、
前記類似ユーザのサービス履歴を前記記憶部から抽出し、
ユーザ毎に利用された前記サービスの評価を行い、評価情報を生成し、
前記対象ユーザ宛に抽出した前記サービス及び前記サービスの対象ユーザに対応する評価情報を含む提案情報を出力する
処理を行わせることを特徴とする提案出力プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス等の提案を出力する提案出力装置等に関する。
【背景技術】
【０００２】
生活者がパーソナルデータを予め登録することで、第三者が提供するサービスを生活者が利用する際に、登録したパーソナルデータを第三者に渡すことにより、利用申込みの手続を簡便化するシステムが提案されている。しかし、生活者が利用可能なサービスの選択肢が多くなると、生活者はどのサービスを選択すれば、生活の質の向上に効果的なのか判断が困難である。
【０００３】
また、生活者に対してサービスを提案するシステムも提案されている。例えば、特許文献１には、特定の生活者のエージェントが製品やサービスのカタログ情報を収集するエージェントシステムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２０１７／０７２９０６号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、従来技術による提案では、サービスを提案する根拠が提示されないため、生活者がその提案を信頼できない。本発明はこのような状況に鑑みてなされたものである。その目的は、提案の根拠となる評価情報を含むサービスの提案情報を出力する提案出力装置等の提供である。
【課題を解決するための手段】
【０００６】
本発明に係る提案出力装置は、ユーザ情報、ユーザが利用するサービス、サービスを利用したサービス履歴を記憶する記憶部と、対象ユーザの特徴を参照し、該対象ユーザに類似する類似ユーザを特定する特定部と、類似ユーザのサービス履歴を記憶部から抽出する抽出部と、ユーザ毎に利用されたサービスの評価を行い、評価情報を生成する評価部と、対象ユーザ宛に抽出したサービス及びサービスの対象ユーザに対応する評価情報を含む提案情報を出力する出力部とを備えることを特徴とする。
【発明の効果】
【０００７】
本発明にあっては、サービス及び当該サービスの評価情報を含む提案情報を出力するので、生活者（対象ユーザ）は提案の根拠を参照し、自分に適切なサービスが提案されているか否かを判断可能となる。
【図面の簡単な説明】
【０００８】
【図１】提案システムの構成例を示す説明図である。
【図２】提案出力サーバのハードウェア構成例を示すブロック図である。
【図３】ユーザ端末のハードウェア構成例を示すブロック図である。
【図４】ユーザＤＢの例を示す説明図である。
【図５】サービスＤＢの例を示す説明図である。
【図６】履歴ＤＢの例を示す説明図である。
【図７】条件ＤＢの例を示す説明図である。
【図８】アクセス権ＤＢの例を示す説明図である。
【図９】サービス登録処理の手順例を示すフローチャートである。
【図１０】ユーザ登録処理の手順例を示すフローチャートである。
【図１１】提案情報出力処理の手順例を示すフローチャートである。
【図１２】提案情報出力処理の手順例を示すフローチャートである。
【図１３】サービス申し込み処理の手順例を示すフローチャートである。
【図１４】提案情報表示画面の例を示す説明図である。
【発明を実施するための形態】
【０００９】
以下実施の形態を、図面を参照して説明する。図１は提案システムの構成例を示す説明図である。提案システムは、提案出力サーバ１（提案出力装置）、ユーザ端末２、事業者サーバ３を含む。ユーザ端末２は１台でも複数台でも良い。事業者サーバ３は１台でも複数台でも良い。
【００１０】
提案出力サーバ１はユーザに対して利用開始を推奨するサービスの情報を提供する。提案出力サーバ１はユーザからサービス開始のリクエストを受け付けた場合、事業者サーバ３へ当該ユーザのパーソナルデータを送信し、ユーザによるサービス申し込みを支援する。ユーザ端末２はユーザが使用する端末である。提案出力サーバ１からユーザに提案するサービスの情報を受信し、表示する。事業者サーバ３はユーザにサービスを提供する事業者のサーバである。提案出力サーバ１、ユーザ端末２、事業者サーバ３はネットワークＮにより、通信可能に接続されている。なお、提案出力サーバ１や事業者サーバ３が提供する機能をクラウドサービスで実現してもよい。
【００１１】
図２は提案出力サーバのハードウェア構成例を示すブロック図である。提案出力サーバ１はサーバコンピュータ、ブレードサーバ、ワークステーション等で構成する。提案出力サーバ１は制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５を含む。制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５はバスＢにより接続されている。提案出力サーバ１はパネルコンピュータやタブレットコンピュータ等で構築しても良い。また、提案出力サーバ１を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン又は量子コンピュータで構成しても良い。
【００１２】
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（提案出力プログラム）を読み出して実行することにより、提案出力サーバ１に係る種々の情報処理、制御処理等を行う機能部（特定部、抽出部、評価部、出力部、選択部、受付部等）として機能する。
【００１３】
主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。
【００１４】
補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、ユーザＤＢ１３１、サービスＤＢ１３２、履歴ＤＢ１３３、条件ＤＢ１３４及びアクセス権ＤＢ１３５を記憶する。補助記憶部１３は提案出力サーバ１に接続された外部記憶装置であってもよい。例えば、補助記憶部１３に記憶する各種ＤＢ等を、データベースサーバやクラウドストレージに記憶しても良い。
【００１５】
通信部１４はネットワークＮを介して、ユーザ端末２や事業者サーバ３と通信を行う。また、制御部１１が通信部１４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。読み取り部１５はＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）−ＲＯＭ及びＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１５を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。
【００１６】
図３はユーザ端末のハードウェア構成例を示すブロック図である。ユーザ端末２はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。ユーザ端末２は制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５、及び表示部２６を含む。各構成はバスＢで接続されている。
【００１７】
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ、ＧＰＵ等の演算処理装置を有する。制御部２１は補助記憶部２３に記憶された制御プログラム２Ｐにしたがい、ハードウェア各部を制御する。主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等である。主記憶部２２は主として制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。
【００１８】
補助記憶部２３はハードディスク又はＳＳＤ等であり、制御部２１が処理を実行するために必要な制御プログラム２Ｐや各種データを記憶する。通信部２４はネットワークＮを介して、提案出力サーバ１や事業者サーバ３と通信を行う。また、制御部２１が通信部２４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、補助記憶部２３に記憶してもよい。
【００１９】
入力部２５はキーボードやマウスである。表示部２６は液晶表示パネル等を含む。表示部２６は提案出力サーバ１が出力したサービス情報などを表示する。また、表示部２６は入力部２５と一体化したタッチパネルディスプレイでもよい。なお、ユーザ端末２は外部の表示装置に表示を行ってもよい。
【００２０】
次に、提案出力サーバ１の補助記憶部１３に記憶するデータベース（DB：Database）について説明する。図４はユーザＤＢの例を示す説明図である。ユーザＤＢ１３１はユーザに関する情報を記憶する。ユーザＤＢ１３１は、ユーザＩＤ列、氏名列、生年月日列、住所列、身長列、体重列、クレジットカード列、アレルギー列、食材の好み列、年収列、家族構成列、保険情報列、及び在宅情報列を含む。ユーザＩＤ列はユーザを一意に特定可能なユーザＩＤを記憶する。ユーザＩＤは、提案システムのユーザ登録時に提案出力サーバ１が発行する。ユーザＩＤはユーザを一意に特定可能なものであれば、提案出力サーバ１が発行するものではなくてもよい。例えば、ユーザＩＤを電子メールアドレスとしても良い。氏名列はユーザの氏名を記憶する。生年月日列ユーザの生年月日を記憶する。住所列はユーザの現住所を記憶する。身長列はユーザの身長を記憶する。体重列はユーザの体重を記憶する。クレジットカード列はユーザ名義のクレジットカードの番号を記憶する。アレルギー列はユーザが持つアレルギーを記憶する。ユーザが食物アレルギーを持つ場合、アレルギー症状を引き起こす食物の名称等を記憶する。食材の好み列はユーザが好む食材を記憶する。年収列はユーザの年収金額を記憶する。家族構成列はユーザの家族構成を記憶する。保険情報列はユーザが加入している生命保険、傷害保険等の情報を記憶する。在宅情報列はユーザが在宅している時間帯の情報を記憶する。ユーザ情報はパーソナルデータの一例である。
【００２１】
図５はサービスＤＢの例を示す説明図である。サービスＤＢ１３２は事業者が提供するサービスに関する情報を記憶する。サービスＤＢ１３２はサービスＩＤ列、事業者列、サービス名列、サービスジャンル列、必須項目列、及び追加項目列を含む。サービスＩＤ列はサービスを一意に特定可能なサービスＩＤを記憶する。サービスＩＤは例えば、サービスがサービスＤＢ１３２に登録される際に発行される。事業者列はサービスを提供する事業者の識別情報、例えば事業者の名称を記憶する。サービス名列はサービスの名称を記憶する。サービスジャンル列はサービスの業種、種別、提供形態等を記憶する。ジャンルは例えば、定期購入、保険、健康等である。必須項目列はユーザがサービスの提供を受けるに当たり、事業者への提供が必須なパーソナルデータの項目を記憶する。追加項目列はユーザがサービスの提供を受けるに当たり、事業者への提供が望ましいパーソナルデータの項目を記憶する。
【００２２】
図６は履歴ＤＢの例を示す説明図である。履歴ＤＢ１３３はユーザの行動履歴を記憶する。履歴ＤＢ１３３はユーザＩＤ列、種別列、時刻列、及び詳細列を含む。ユーザＩＤ列は行動したユーザのユーザＩＤを記憶する。種別列は行動の種別を記憶する。種別は例えば、サービス利用、サービス評価、サービス苦情、移動履歴、行動履歴、購買履歴、運転履歴、食事履歴、睡眠履歴、治療履歴、財務履歴、運動履歴等である。時刻列は行動が行われた日時を記憶する。日時は行動を開始した日時又は行動を終了した日時等である。詳細列は行動の詳細を記憶する。
【００２３】
図７は条件ＤＢの例を示す説明図である。条件ＤＢ１３４はパーソナルデータの利用条件を記憶する。条件ＤＢ１３４はユーザＩＤ列、業種列、許可列、及び目的列を含む。ユーザＩＤ列はユーザＩＤを記憶する。業種列はパーソナルデータの利用を許可する事業者の業種を記憶する。業種でなくサービスのジャンルを記憶しても良い。また、「除外：保険」のように、許可しない業種を、業種列に記憶しても良い。許可列は利用を許可するパーソナルデータの項目を記憶する。目的列はパーソナルデータの利用目的の制限を記憶する。例えば、サービス向上であれば、ユーザに提供するサービスの向上を目的とするのであれば、利用を許可する。この場合の例としては、食材配達サービスにおいて、ユーザの食材の好みとパーソナルデータは、ユーザが好む食材の選択に役立ち、サービスが向上するので、利用が許可される。
【００２４】
図８はアクセス権ＤＢの例を示す説明図である。アクセス権ＤＢ１３５はパーソナルデータに含まれる追加項目について、サービス事業者に付与されたアクセス権を記憶する。アクセス権ＤＢ１３５はユーザＩＤ列、サービスＩＤ列、事業者列、及び追加項目列を含む。ユーザＩＤ列はアクセス権を付与したユーザのユーザＩＤを記憶する。サービスＩＤ列はアクセス権を付与する際に、ユーザが申し込みをしたサービスのサービスＩＤを記憶する。事業者列はサービスを提供する事業者の識別情報を記憶する。追加項目列はアクセス権を付与した追加項目の識別情報、例えば項目名を記憶する。
【００２５】
続いて、提案システムが行う処理について、説明する。図９はサービス登録処理の手順例を示すフローチャートである。サービス登録処理は事業者が提供するサービスを登録する際の処理である。サービス事業者は提案出力サーバ１にアクセスし、サービスの登録画面を開く。事業者は登録画面にサービスの情報を入力し、提案出力サーバ１に送信する。提案出力サーバ１の制御部１１は、サービス情報を取得する（ステップＳ１）。制御部１１はサービスＩＤを発行する（ステップＳ２）。制御部１１はサービス情報をサービスＩＤと対応づけて、サービスＤＢ１３２に記憶し（ステップＳ３）、処理を終了する。
【００２６】
図１０はユーザ登録処理の手順例を示すフローチャートである。ユーザ登録処理は提案システムを利用したい生活者が利用登録する際の処理である。生活者はユーザ端末２より提案出力サーバ１にアクセスし、ユーザ登録を要求する。提案出力サーバ１はユーザ登録画面をユーザ端末２に送信する。生活者はユーザ端末２に表示されたユーザ登録画面にユーザ情報を入力し、提案出力サーバ１へ送信する。提案出力サーバ１の制御部１１はユーザ情報を取得する（ステップＳ１１）。制御部１１はユーザ情報をユーザＤＢ１３１に記憶する（ステップＳ１２）。制御部１１はユーザ情報を含むパーソナルデータの利用条件設定画面をユーザ端末２へ送信する。制御部１１は利用条件を取得する（ステップＳ１３）。制御部１１は利用条件を条件ＤＢ１３４に記憶し（ステップＳ１４）、処理を終了する。
【００２７】
図１１及び図１２は、提案情報出力処理の手順例を示すフローチャートである。提案情報出力処理はユーザにサービスの申し込みを促す提案情報を出力する処理である。提案情報出力処理はユーザからの要求により開始しても良いし、バッチ処理により開始しても良い。制御部１１はサービスＤＢ１３２からサービスの一覧を取得する（ステップＳ２１）。制御部１１は処理対象とするサービスを選択する（ステップＳ２２）。制御部１１は選択したサービスを既に利用しているユーザ（既存ユーザ）を取得する（ステップＳ２３）。既存ユーザは、履歴ＤＢ１３３、又は事業者サーバ３から取得する。制御部１１は取得した既存ユーザから処理対象とする一の既存ユーザを選択する（ステップＳ２４）。
【００２８】
制御部１１は選択した既存ユーザと処理対象としているユーザの類似度を算出する（ステップＳ２５）。類似度は、ユーザの属性（居住地、年収額）、利用中のサービス、行動履歴等、ユーザの特徴を示す項目に基づき算出する。例えば、関東地方居住、東京都居住、年収５００万以上、フィットネスアドバイスサービスを利用しているなどの各比較項目について、両者が一致すれば１、一致しなければ０とするベクトルを作成する。作成したベクトルの重み付きの内積を算出し、類似度とする。重みはサービスのジャンル毎に決定しておく。制御部１１は未処理の既存ユーザがあるか否かを判定する（ステップＳ２６）。制御部１１は未処理の既存ユーザがあると判定した場合（ステップＳ２６でＹＥＳ）、処理をステップＳ２４に戻し、未処理の既存ユーザについての処理を行う。
【００２９】
制御部１１は未処理の既存ユーザがないと判定した場合（ステップＳ２６でＮＯ）、既存ユーザの中から、類似度が高い上位ユーザ、例えば、上位５ユーザを選択する（ステップＳ２７）。制御部１１は、選択した上位ユーザ（類似ユーザ）について、サービスを利用した後に得た損益を計算する（ステップＳ２８）。損益は所定の項目毎に履歴ＤＢ１３３から得られる行動履歴に基づき、計算する。損益項目は次のようなものが考えられる。サービス利用開始前後での時間の利用パターン（時間利用パターン）の変化、例えば、時間の短縮や延長である。家事時間が短縮すれば、余暇時間が増えたことによる有益な価値として利益（メリット）とみなす。また、サービス申し込み前後での購買パターンが変化した場合、例えば、食料品の購買回数が減少すれば、食料品の購入のための時間や手間が減り、自由時間の増加、家事負担の軽減という有益な価値として利益とする。さらに、サービス申し込み前後での血圧パターンの変化した場合、例えば、高血圧の人の血圧が下がれば、健康増進という有益な価値として利益とする。同様に、低血圧の人の血圧が上がれば、利益とする。ユーザのサービスの継続利用年数は利益とする。サービスの利用年数が長いほど、利益を示す点数の値が大きくなるように設定する。なお、血圧パターンは生体データパターンの一例である。血圧以外の生体データとしては、体温、心拍数、脈拍数、呼吸数、血糖値、発汗量、体重等がある。これらの生体データのパターンに基づき、サービスを利用したことによる損益を計算してもよい。加えて、ユーザのサービスへの評価により損益を計算する。例えば、５点満点中何点と評価したなどである。評価の点数そのままを利益値してもよい。また、５点は＋２点、４点は＋１点、３点は０点、２点は−１点、１点は−２点など、損益に振り分けるように変換してもよい。一方、ユーザがサービスへの苦情を出した件数（苦情件数）は、損失とする。苦情件数が多いほど損失が大きくなる（負の値で、絶対値が大きくなる）ようにする。
【００３０】
具体的な例として、食材購入サービスに関する損益の計算例を示す。食材購入サービスでは以下のような項目について損益計算する。申し込み後に１ヶ月あたりのスーパーへの移動に利用した時間が平均５時間減少した：−５×ｗ１。申し込み後に１か月あたりの食材に対する支払い金額が３，０００円増加した：３０００×ｗ２。申し込み後にサービスへ星５の評価を付けた：＋２×ｗ３。申し込み後サービスを継続している：ｗ４。ここで、ｗ１からｗ４は重みであり、予めサービスジャンルごとにシステムが決めた値でもよいし、ユーザが設定できるようにしてもよい。正の値のもの（利益）と負の値のもの（損害）をそれぞれ独立して合計する。合計の際、対象ユーザと既存ユーザとの類似度を重みとして算出しても良い。利益の合計値及び損害の合計値は損益情報の一例である。
【００３１】
制御部１１は未処理のサービスがあるか否かを判定する（ステップＳ２９）。制御部１１は未処理のサービスがあると判定した場合（ステップＳ２９でＹＥＳ）、処理をステップＳ２２に戻し、未処理のサービスについての処理を行う。制御部１１は未処理のサービスがないと判定した場合（ステップＳ２９でＮＯ）、各サービスの損害を参照し、損害が一定以上のもの、すなわち、損害を示す負の値が予め定めた閾値より小さいものを除外する（ステップＳ３０）。例えば「定期購入サービスＢ」は苦情を入れている人が多く、評価も低いとすると損害が大きくなり、除外される。制御部１１は対象ユーザが既に申し込み済みのものは除外する（ステップＳ３１）。なお、ステップＳ３１はステップＳ２１とステップＳ２２との間に実行しても良い。制御部１１は利益が大きいものを選択する（ステップＳ３２）。例えば「食材購入サービスＡ」は、スーパーへの移動に使っている時間を減っているユーザが多く、評価も高いとすると利益が大きくなり、選択される。
【００３２】
図１２に移り、制御部１１は、残っているサービスについて、利用ユーザを取得する（ステップＳ３３）。制御部１１は取得した利用ユーザから、対象ユーザと類似度の高いユーザを選択する（ステップＳ３４）。例えば、対象ユーザと住所が近いという点において、類似しているとする。制御部１１は、類似度の高いユーザがサービス利用により、特に得ている利益を選択する（ステップＳ３５）。例えば、制御部１１は「申し込み後に１か月あたりのスーパーへの移動に利用した時間が平均５時間減少した」という利益を選択する。制御部１１は、対象ユーザと類似度が高く、選択した利益を得ているという条件に該当するユーザの数を取得する（ステップＳ３６）。例えば、該当サービスに申し込んでいるユーザの中で、「東京都に住んでいて、申し込み後に１か月あたりのスーパーへの移動に利用した時間が平均５時間以上減少した」というユーザの数を取得する。制御部１１は該当ユーザ数が予め定めた閾値以上であるか否かを判定する（ステップＳ３７）。制御部１１は該当ユーザ数が予め定めた閾値以上でないと判定した場合（ステップＳ３７でＮＯ）、該当ユーザとする条件を変更し（ステップＳ３８）、処理をステップＳ３６に戻す。例えば、「東京都在住」という条件を「関東在住」という条件に変更する。又は、スーパーへの移動に利用した時間の減少が「平均５時間以上」という条件を「平均４時間以上」に変更する。制御部１１は該当ユーザ数が予め定めた閾値以上であると判定した場合（ステップＳ３７でＹＥＳ）、該当ユーザ数とする条件に基づき、推薦理由を生成する（ステップＳ３９）。例えば、「東京都に住んでいるあるユーザは、サービス申し込み後に１か月あたりのスーパーへの移動に利用した時間が平均５時間以上減少しました」という推薦理由を生成する。制御部１１は、提案するサービス及び推薦理由を含む提案情報を出力し（ステップＳ４０）、処理を終了する。提案情報には、サービスを申し込みにあたり、事業者に提供する必要がある追加項目を含めても良い。追加項目はサービスＤＢ１３２から取得する。
【００３３】
図１３はサービス申し込み処理の手順例を示すフローチャートである。サービス申し込み処理は、提案情報に基づき、ユーザが新たなサービスを申し込み際の処理である。サービス申し込み処理に先立ち、提案情報出力処理の結果として、提案情報が作成されている。ユーザ端末２の制御部２１は、提案情報を表示部２６に表示する（ステップＳ５１）。ユーザは入力部２５により申し込むサービスと追加項目を選択する。制御部２１は選択を受け付ける（ステップＳ５２）。制御部２１は通信部２４を介して、選択情報を提案出力サーバ１へ送信する（ステップＳ５３）。提案出力サーバ１の制御部１１は通信部１４を介して選択情報を受信する（ステップＳ５４）。制御部１１は選択情報に基づき、ユーザが申し込むサービスを利用するために必要な追加項目のうち、ユーザが選択した項目についてのアクセス権を、当該サービス提供する事業者に対して付与する（ステップＳ５６）。すなわち、制御部１１は新たなレコードをアクセス権ＤＢ１３５に記憶する。制御部１１はユーザがサービスを申し込む意向を示す申し込み情報を事業者サーバ３に送信し（ステップＳ５７）、処理を終了する。なお、制御部１１はステップＳ５７の後に、ユーザ端末２との処理を事業者サーバ３へ転送し、ユーザ端末２と事業者サーバ３との間で、サービス申し込みのために必要な事業者での処理を行えるようにしても良い。
【００３４】
図１４は提案情報表示画面の例を示す説明図である。提案情報表示画面は２つの画面から構成されている。図１４Ａは提案サービス一覧画面である。提案サービス一覧画面２６１はジャンル選択メニュー２６１１及び提案一覧２６１２を含む。ジャンル選択メニュー２６１１はプルダウンメニューである。ジャンル選択メニュー２６１１によりサービスのジャンルを指定することより、提案一覧２６１２に表示するサービスを絞り込むことが可能である。提案一覧２６１２はユーザに申し込みを提案するサービスを一覧表示する。
【００３５】
図１４Ｂは提案理由表示画面である。提案理由表示画面２６２は、提案サービス一覧画面２６１でサービスを選択した場合に表示される。提案理由表示画面２６２は内容表示２６２１、理由表示２６２２、追加項目表示２６２３、申込ボタン２６２４を含む。内容表示２６２１はサービス内容の説明を表示する。理由表示２６２２は提案理由を表示する。追加項目表示２６２３はサービスを利用するあたり、サービス事業者に対して開示する必要がある追加項目を表示する。申込ボタン２６２４をサービスの申し込みを行うためのボタンである。
【００３６】
本実施の形態においては、サービスを提案する理由を表示するので、ユーザは自分に適切なサービスが提案されているか否かを判断することが可能となる。また、提案理由を生成する際、参考にするユーザの該当数が少ない場合は、該当とする条件を緩め、該当とするユーザ数が増加するようにする。提案理由には、該当する条件を含める。そのため、該当ユーザが少ない条件は該当ユーザが誰であるのか特定されやすい。そのような条件を対象ユーザに提示することは、プライバシー保護上、好ましくないからである。本実施の形態においては、該当ユーザ数がある程度以上の数となる条件から提案理由を生成するので、対象ユーザが提案理由を目にしたとしても、該当ユーザは特定されず、プライバシーの漏洩を防ぐことが可能となる。
【００３７】
各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【００３８】
１      提案出力サーバ
１１    制御部
１２    主記憶部
１３    補助記憶部
１３１  ユーザＤＢ
１３２  サービスＤＢ
１３３  履歴ＤＢ
１３４  条件ＤＢ
１３５  アクセスＤＢ権
１４    通信部
１Ｐ    制御プログラム
２      ユーザ端末
２１    制御部
２２    主記憶部
２３    補助記憶部
２４    通信部
２５    入力部
２６    表示部
２６１  提案サービス一覧画面
２６２  提案理由表示画面
２Ｐ    制御プログラム
３      事業者サーバ
【図１】
2020197925.tif 000003
【図２】
2020197925.tif 000004
【図３】
2020197925.tif 000005
【図４】
2020197925.tif 000006
【図５】
2020197925.tif 000007
【図６】
2020197925.tif 000008
【図７】
2020197925.tif 000009
【図８】
2020197925.tif 000010
【図９】
2020197925.tif 000011
【図１０】
2020197925.tif 000012
【図１１】
2020197925.tif 000013
【図１２】
2020197925.tif 000014
【図１３】
2020197925.tif 000015
【図１４】
2020197925.tif 000016