(57)【要約】【課題】複数の組織間あるいはサービス間で、ユーザの特性情報の一貫した収集あるいは共通した活用を可能とする利便性を確保しながら、ユーザがサービスを受けるためにサービス提供元に開示する情報を把握し、その情報に基づいて行動を決定すること可能とするシステムを提供する。【解決手段】顧客の特性情報を一元管理し、サービス毎にサービス提供事業者がサービスに用いる特性情報の項目を提示し、それを顧客が許可ことにより、情報システムが特性項目の情報アクセスの権限管理を行う。【選択図】図１６
2015176263.tif 000002
【特許請求の範囲】
【請求項１】
顧客の状態又は行動又は前記顧客が受けるサービスの、何れか１つ又は複数の項目を含む情報である、特性情報を格納するデータベースにアクセス可能な情報システムであって、
前記特性情報を用いて前記顧客にサービスを提供する組織であるサービス提供組織の入力に基づいて、前記顧客に前記サービスで用いる特性情報の項目を提示する特性情報提示部と、
前記サービスで用いる前記特性情報の項目の利用許諾についての管理操作を受け付け、前記サービスを提供する組織に対し、前記許諾管理部によって許諾された前記項目のみの利用を許諾する許諾管理部と、
を有することを特徴とする情報システム。
【請求項２】
請求項１に記載の情報システムであって、
前記サービスを提供する組織に対し前記許諾された前記項目の特性情報に対し、現在及び過去に利用させた特性情報と前記特性情報を利用させた組織を表示する表示部を、
さらに有することを特徴とする情報システム。
【請求項３】
請求項１に記載の情報システムであって、
前記特性情報は口コミ情報をさらに含み、
前記顧客の許諾された特性情報を用いて前記顧客のクラスタリングを行うクラスタリング部と、
前記クラスタリングの結果、同じクラスターに分けられた前記顧客の口コミ情報を優先的に表示する表示部と、
をさらに有することを特徴とする情報システム。
【請求項４】
請求項１に記載の情報システムであって、
前記許諾された特性情報の時間に対する変化が予め定めた条件に合致した際に
前記条件に該当するサービスの推薦情報を表示する表示部を、
さらに有することを特徴とする情報システム
【請求項５】
請求項１に記載の情報システムであって、
前記特性情報は、第一の顧客にサービスを提供している第一の組織に関する情報を含み、
前記データベースは、前記組織と前記組織に課金する課金情報とを含む情報をさらに格納し、
前記第一の顧客により、前記第一の組織とは異なる第二の組織が提供するサービスを受ける入力を受け付けるサービス申込部と、
前記サービス申込部が前記入力を受け付けた場合、前記第一の組織への課金情報を更新する課金更新部と、
をさらに有することを特徴とする情報システム。
【請求項６】
請求項１に記載の情報システムであって、
前記特性情報は、前記顧客にサービスを提供している複数の前記組織に関する情報を含み、
前記データベースは、前記顧客に付与されるインセンティブに関するインセンティブ情報を含み、
前記複数の組織の提供するサービス間の前記顧客の流出入の度合いを示す流出入度を算出する流出入算出部と、
上記算出された前記流出入度に基づいて前記インセンティブ情報を前記顧客に付与するインセンティブ管理部と、
さらに有することを特徴とする情報システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は顧客の特性情報を管理し活用する情報システムに関するものである。
【背景技術】
【０００２】
性別、年齢、居住地域、購買履歴、Ｗｅｂページの閲覧履歴などのユーザのデモグラフィックデータや行動、受けているサービスとその結果などの顧客の特性を示す情報である特性情報は、傾向分析による新商品開発、ユーザへのお勧め提示など多様な応用が可能な情報であり、様々な手段で情報収集が行われている。一方、近年、日本をはじめ多くの国で人口構造が高齢化にシフトして行く中、医療費、介護費用などの社会的な負担増の抑制のために、予防や見守りサービスの重要性が増している。予防や見守りサービスを科学的、効率的に行うためには運動や食事などの行動や健康状態の特性情報を長期にわたり継続的に取得、蓄積する必要がある。つまり、性別、年齢、居住地域、購買履歴、Ｗｅｂページの閲覧履歴などのユーザの特性情報に加え、運動や食事などの行動や健康状態の特性情報を収集する新たな需要が生まれている。実際、通信機能付きの健康機器などが発売されており、機器で取得したデータと連携するサービスが現れている。
【０００３】
特許文献１には、予めサービス事業者がユーザの合意を取った情報を共通情報として複数のサービス事業者間で共有して利用する技術が開示されている。また、特許文献２には、携帯カードに記録された個人情報に複数の情報開示レベルを設定し、読み出し時に確認する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−３４４４０６公報
【特許文献２】特許第４４１４７４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Ｗｅｂサイトのアクセス履歴、ネット通販の利用履歴などユーザが意識することなくユーザ特性を収集する技術が高度化してきた。これらはユーザの好みを推定してお勧めを行うなど便利な機能を提供することを可能にする反面、ユーザ本人が予想していないほど詳細な特性情報が集められる場合が生じており、またこの実態をユーザ自身が把握しにくい。このように、自分の特性情報を自分がコントロールできないところで収集、蓄積、加工、提供されている状況に不満を持つユーザも少なくない。特に、行動や健康状態の特性情報については、情報を有効に用いれば社会コスト低減などの社会的意義が大きい成果に結びつつ可能性があるものの、情報の扱いは重要な課題である。
【０００６】
このような、ユーザ本人が把握しない形で特性情報を利用されることを避けるためには、サービスを受ける際、そのサービスに限って特性情報を利用させることが基本である。しかしながら、この場合、サービスを受けている期間にサービスの記録を取っても、サービスを止めるとそのデータが失われてしまう。
例えば、健康増進サービスにおいては、検査結果等の異常が見出されるまでは、個人の健康維持のための努力に対する動機は必ずしも強くないため、様々な要因により、あるサービス事業者の健康サービスから他のサービス事業者の健康サービスに乗り換えるという行動が見られる。このためデータに継続性がなかったり、散在してしまったりして、上述の一貫した予防の取り組みやその効果の検証ができないという課題が生じる。課題解決のためには、複数のサービス事業者間でデータを継続して記録、保管するサービスシステムが求められる。また、サービス事業者の立場からは、このようなサービスシステムを利用するインセンティブが存在する必要がある。つまり、複数の事業者間やサービス間でユーザの特性情報を集めたり、活用したりする利便性とユーザ本人が把握しない形で特性情報が利用されることの両立を図ることが課題である。
【０００７】
特許文献１の従来技術では、予め共通利用情報を定義するため、サービス内容に依存して用いる情報を決めることができない。このため、ある企業がサービスを提供する上で必要でない情報までその企業に開示することになる。また、このようなことを避けようとすると共通利用情報を非常に絞ることになり、情報を使ったサービスの種類や質に大きな制約を受けることになる。さらに、開示先企業をユーザが選択することができないという課題がある。また、特許文献２の従来技術は、開示データの種類を視認する手段と予め設定した情報開示のパターンを切り替える手段を具備するが、開示を受けるサービスや企業側で必要な情報を伝達する手段を持たない。また、携帯カードに予め記録された個人情報が対象であり、蓄積データ種、量に大きな制限がある。また、サービスを受けるのに必要な情報を開示する意思決定を行う機会や、新たに情報蓄積を行うという行動選択を行う機会が存在しない。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。その一例を挙げるならば、顧客の状態又は行動又は前記顧客が受けるサービスの、何れか１つ又は複数の項目を含む情報である、特性情報を格納するデータベースにアクセス可能な情報システムであって、特性情報を用いて顧客にサービスを提供する組織であるサービス提供組織の入力に基づいて、顧客にサービスで用いる特性情報の項目を提示する特性情報提示部と、サービスで用いる特性情報の項目の利用許諾についての管理操作を受け付け、サービスを提供する組織に対し、許諾管理部によって許諾された項目のみの利用を許諾する許諾管理部と、を有することを特徴とする情報システムである。
【発明の効果】
【０００９】
本発明によれば、複数の組織間あるいはサービス間で、ユーザの特性情報の一貫した収集あるいは共通した活用を可能とする利便性を確保しながら、ユーザがサービスを受けるためにサービス提供元に開示する情報を把握し、その情報に基づいて行動を決定することを可能とするシステムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】システムの全体構成を示す概要図である。
【図２】共通サービスシステムの構成を示す概要図である。
【図３】サービス管理ＤＢに格納される情報の例を説明する図である。
【図４】顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図５】顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図６】顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図７】サービス管理ＤＢに格納される情報の例を説明する図である。
【図８】サービス管理ＤＢに格納される情報の例を説明する図である。
【図９】顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図１０】共通サービスの申し込みフローを説明する図である。
【図１１】共通サービスのトップ画面を説明する図である。
【図１２】サービス内容を説明する画面を説明する図である。
【図１３】サービス内容を説明する画面を説明する図である。
【図１４】共通サービスの利用者が個別サービスに申し込み、個別サービスを停止するまでの流れを説明する図である。
【図１５】サービス履歴画面を説明する図である。
【図１６】情報提供依頼画面を説明する図である。
【図１７】情報提供依頼内容を説明する画面を説明する図である。
【図１８】企業等の顧客が共通サービスに申し込むフローを説明する図である。
【図１９】企業等の顧客が共通サービスを利用する際に顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図２０】ある企業等の顧客が共通サービスシステムを介して異なる企業等の顧客になるフローを説明する図である。
【図２１】共通サービス利用料を企業等に課金する際の課金例を説明する図である。
【図２２】顧客特性情報ＤＢに格納される情報の例を説明する図である。
【図２３】企業間の顧客流入に対する非一様なインセンティブの付与の例を説明する図である。
【発明を実施するための形態】
【００１１】
以下、添付図面を参照して本発明の実施例について説明する。なお、添付図面は本発明の原理に則った具体的な実施例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【実施例１】
【００１２】
＜システムの構成＞
図１は、本発明の第１実施例に係る情報システムの全体構成の例を簡略化して示した図である。顧客の特性情報を管理する共通サービスシステム１はその内部に顧客特性データを格納する顧客特性ＤＢ２及びサービスや調査の情報を管理するサービス管理ＤＢ３を有し、ネットワーク４に繋がっている。ＰＣ、携帯電話、スマートフォン、タブレット端末などの顧客端末５，６もネットワーク４に繋がっており、また、共通サービスシステム１にて収集された顧客特性を用いて顧客にサービスを提供する企業ＢＢ社とＣＣ社のサービスシステム７、８もネットワーク４に繋がっている。
【００１３】
図２に共通サービスシステムの内部構成を機能とその接続関係から、より詳細に示す。図１に示した顧客特性ＤＢ２及びサービス管理ＤＢ３に加え、顧客が操作する画面を提供するサービスアプリケーション、顧客特性ＤＢ２へのアクセス権を管理するアクセス管理部９、顧客ＤＢ２に格納されているデータを基に統計処理を行う統計処理部１０、ＷＥＢサービス機能を有するＷＥＢサービス部１１、ポイント管理情報を格納するポイント管理ＤＢ１２、掲載する記事のコンテンツ管理を行う記事ＤＢ１３、顧客端末に表示する広告データの管理を行う広告ＤＢ１４よりなる。各機能は独立なサーバーで実現しても良いし、複数機能を一つのサーバーで実現したり、一つの機能を複数のサーバーで実現したりしても構わない。また、顧客端末に表示する画面はＷＥＢ画面であるとしたが、顧客端末のアプリケーションが共通サービスシステムとデータのやり取りを行いながら表示機能やデータ収集機能を実現するのでも構わない。
【００１４】
図３、図７、図８にてサービス管理ＤＢ３に格納されているデータを説明する。説明の都合上図７、図８については後述し、まず図３の説明を行う。
【００１５】
サービスＩＤ１５が付与されている各サービスに対し、サービスの提供企業ＩＤ１６、サービスの種別を表すサービスカテゴリ１７、サービスの現在の状態を示すサービス状態１８、サービスの詳細内容情報の格納先１９、サービスを提供するために顧客に開示を求める特性情報の項目の情報２０が関連付けられている。サービスカテゴリ１７では基本となるサービスとこれに加えて個別に申し込んで実施するサービスの区別や、サービスを提供する企業に共通サービスが課金するかしないかによってカテゴリを分けている。また、サービス状態１８ではサービスが提供中なのか、提供が終了しているのか、あるいはサービスが終了予定の状態なのかの情報を提供している。
【００１６】
次に図４にて顧客特性情報ＤＢ２に格納されているデータを説明する。個人ＩＤ２１に対し、顧客が用いるＩＤであるユーザＩＤ３０、パスワード３１、後述するクラスタリングの結果２２、現在保有しているポイント数２３、基本プロファイル２４、記録しているデータ項目２５、受けているサービスのＩＤ２６が関連付けられている。基本プロファイル２４の例として、生年月日、性別、居住地域、メールアドレス、血液型、身長などを挙げる。また、それ以外の特性データとして、購買記録、ＷＥＢページのアクセス動向、日々のイベント入力、活動量、肌傾向、体温、食事記録などを挙げる。基本プロファイルは変更頻度が低いため値を格納し、活動量、体重などは時系列で変化するデータであるため、記録を実施しているデータ項目のみ格納している。ここで、顧客特性データは顧客等が手入力するものと、通信機能付の機器を介して収集するもの両方を含む。例えばＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）によるデータ出力機能を有する活動量計、ＮＦＣによるデータ読込み機能付のスマートフォンも販売されおり、これらを連携させて顧客特性を収集する。受けているサービスＩＤ２６はその顧客が受けているサービス群のサービスＩＤ１５であり、各サービスＩＤは図３のサービス管理ＤＢで定義されている。
【００１７】
図５も顧客特性情報ＤＢ２に格納されているデータであり、図４にて現れたデータ項目の内容を個人ＩＤ２１、データ種２７、データ計測日２８に関連付けられたデータ２９となっている。日々のイベント入力はその日行ったことをユーザが手入力したデータであり、例えば食べ放題に行った、長距離サイクリングを行ったなどである。あるいは、結婚、子供の誕生、親戚の不幸など生活スタイル変化に結びつくことや心の健康に関連することを記述してもよい。入力は予め決められたメニューから選択した結果を格納しても良いし、自由記述で入力してもよい。また簡易な入力と自由度を両立させるため、その組み合わせで入力としてもよい。また、顧客が自由記述で書き込んだ文字列から、キーワードに該当するものを抽出して特性情報を生成してもよい。
【００１８】
図６も顧客特性情報ＤＢ２に格納されているデータであり、顧客が書き込んだ口コミ情報や、サービスを受けた際にサービス側から受け取ったアドバイス等のメッセージや、逆に顧客がサービス事業社に送った質問、感想などのメッセージの履歴情報である。データ種の列に、データが口コミなのか、受け取ったメッセージなのか、自分が発したメッセージなのかの識別情報を持つ。また、これらがどのサービスに関するものかの情報をサービスＩＤによって保持している。
【００１９】
ここで図７、図８の説明を行う。図７は、サービス管理ＤＢ３に格納される、口コミ情報データである。サービスＩＤ、口コミＩＤ、後述するクラスター分けに基づくクラスター情報、書込み者のＩＤに併せて口コミ内容が蓄積される。
【００２０】
図８は、サービス管理ＤＢ３に格納される、コンタクト情報データである。受けるサービスにより、サービス事業者と顧客の間のメッセージ交換が発生する。例えば、顧客情報に基づいてサービス事業者がアドバイスを行ったり、顧客が疑問点をサービス事業者に投げかけ、サービス事業者がこれに回答したりする場合などである。このような場合のメッセージのやり取りを記録している。データ種別はサービス事業者が送ったアドバイスやメッセージなのか、顧客から受け取ったメッセージなのか、あるいはサービス事業者が覚書として記入するメモなのかの識別情報である。この情報はサービス事業者独自のノウハウが含まれる場合があり、他のサービス事業者には顧客特性情報として開示しない。
【００２１】
図７、図８の口コミ情報及びコンタクト情報は、同内容を図６の顧客特性情報ＤＢ２に各顧客に割り振る形で格納する。データ内容が重複するが、いずれか一方のみに持った場合に比べ、サービス毎の口コミ情報と個人の履歴のいずれにおいても表示に多くの演算を要しないため、利用者の使い勝手がよいという特徴がある。また、サービス事業者は複数の顧客と接する際にサービスＩＤ毎に顧客横断でコンタクト履歴が表示されることが望ましく、そのような場合の使い勝手もよい。
【００２２】
図９も顧客特性情報ＤＢ２に格納されているデータであり、顧客が受けたサービスの履歴情報である。個人ＩＤ２１、履歴ＩＤ４２に関連付けられて、サービスＩＤ１５、獲得ポイント４３、その顧客がサービスを受け始めた日４４、サービスを受けるのを止めた日４５の情報がある。ここでサービスＩＤ１５の内容は前述のサービス管理ＤＢ３に格納されており、参照することで使用する特性情報の項目などの詳細情報が得られる。サービス管理ＤＢ３で保持する過去のサービスデータ量を削減し、システムのレスポンスを早める観点から、これらサービスの詳細情報も含めてサービス履歴データとして保持してもよい。尚、基本プロファイル２４、記録しているデータ項目２５及びその内容であるデータ種２７、データ計測日２８、データ２９は併せて顧客が入力した顧客特性の情報であるが、現在保有しているポイント数２３、受けているサービスなども顧客を特徴付ける情報であり、広くこれらも含めて顧客特性情報と呼ぶ。
＜クラスタリング＞
ここでクラスタリングについて説明する。上述の顧客特性情報を基に、顧客を類似の特性を有する複数の集団に分ける。クラスター分けした情報の活用として、まず顧客特性に基づく記事内容、アドバイス内容やお勧めサービス、商品の選択が挙げられる。ここで記事内容は記事ＤＢ管理１３で管理される。例えば食事履歴から抽出した摂取カロリー、運動の消費カロリー、体重と身長から計算するＢＭＩ（Ｂｏｄｙ  Ｍａｓｓ  Ｉｎｄｅｘ）を用いてクラスタリングを行うとする。摂取カロリーが多くＢＭＩの大きい集団には、低カロリー食を用いたダイエットプログラムが有効であり、摂取カロリーがあまり多くなく、運動での消費カロリーが小さく、ＢＭＩの大きい集団には運動を中心としたダイエットプログラムが有効であると推測できる。また、摂取カロリーが多かったり運動が少なかったりしてもＢＭＩが小さい集団にはダイエットプログラムを勧めるべきではない。
【００２３】
クラスター分けした情報の他の活用として、お勧めやサービスの有効度が類似したクラスター分けのリコメンドや調査への利用が挙げられる。本システムは顧客特性を継続的に収集、蓄積する機能を有するため、サービスを受けることによって、特性情報が時系列で変化する様子を記録することができる。例えばダイエットサービスによって体重が変化していく様子の記録などである。従ってサービスの効果の度合いによって顧客をクラスタリングすることが可能である。ある顧客にサービスを提供して効果が大きかった場合、同じクラスターに属する他の顧客にも効果が大きいことが期待されるため、同じクラスターに属するがこのサービスを未だ受けていない顧客にこのサービスを勧めることが有効である。さらに、アドバイスやお勧めサービス、商品などの情報を提供した後の購買履歴をクラスタリングに用いることで、アドバイスやお勧めサービス、商品などの情報をどのくらい評価するかで分けた集団に分けることができる。
【００２４】
このクラスタリングで、サービス、商品等を高く評価した顧客に対し類似の商品、サービスのお勧めを行うことができる。また、サービス、商品等を低く評価した顧客に対しアンケート等を行うことで、購買に結びつく要因の検討を行うこともできる。このように、クラスタリングは使用の仕方によって顧客特性情報の多様な組み合わせによって行うものであり、結果も当然複数存在する。つまり、一人の顧客が複数のカテゴリのクラスターに属することになる。図４の顧客特性情報ＤＢ２にクラスタリング結果２２を格納する。複数のクラスタリング結果を格納するため、組み合わせをコード化して格納しても良いし、顧客特性情報の列を増やしてクラスタリング結果を格納しても構わない。
【００２５】
さらに、本システムでは生活習慣パターンなど詳細な行動、状態情報を用いてクラスタリングを行うことができるため、顧客間の生活スタイルが類似であるようなクラスター分けが可能である。クラスター内で購買履歴の商品間の相関を分析し、結果を用いてお勧め商品の表示を行うことで、クラスター分けをせずに行った相関分析の結果を用いた場合よりも、より個々の顧客に合う商品リコメンドを行うことが出来、購買に結びつき安いのと同時にサービスシステムへの顧客の信頼度向上にも寄与する。同様に、サービスや商品に対する口コミにおいても、生活スタイルが類似であるようなクラスター分けに基づき、口コミ表示の優先順位をつけることで、より顧客の満足の行く情報を提供できる。例えば、口コミ情報データにおいて、図７に示すように口コミを記入した顧客のクラスター分け情報を格納しておく。口コミ表示を行う顧客と同じクラスターあるいはクラスター間の距離の近い顧客の書き込んだ口コミ情報を優先的に表示する。
【００２６】
従来の口コミサイトなどでは、生活スタイルが近いのか異なるのか不明なまま情報に接していたため、口コミでは高評価である商品を購入しても満足できない要因となっていた。また、ＳＮＳ機能を提供し、同様の生活スタイルのクラスターに属する顧客間で交流を促してもよいし、この単位でイベントを開催することで顧客のほとんどが満足できるイベント内容の設計が可能になる。さらに、このようなクラスターの集団としての特性情報をサービス提供企業に提示することで、個人情報を保護しながらサービス設計の基本情報として用いることができ、サービスの効果のシミュレーションを行うことが可能である。加えて、本システムでは生活習慣パターンなど詳細な行動、状態情報を記録することから、顧客の特性データの変化を捉えることができる。例えば、ここ一ヶ月で体重が一定量以上増えた、肌の水分状態が一定以上悪化したなどである。
【００２７】
このような変化をクラスタリングの項目として採用することで、静的な条件だけでなく、時間に対して変化するような条件についても考慮したダイナミックなクラスター分けが可能となる。このようなクラスター分けに基づいてアドバイスやお勧めを行うことで、タイムリーで付加価値の高いサービスを提供することが可能となる。尚、クラスターに関する特性情報を外部企業などに提供する際には、条件とする顧客特性情報を詳細にしすぎると対象顧客が具体的に絞れてしまうことから、必ず対象となる顧客数が一定以下にはならないように条件を定める、所謂ｋ−匿名化などの手法を採ることとする。ｋの値は用いる条件の内容によって変えるべきであるが、例えば１０とする。
＜サービスの流れ＞
次にサービスの流れを説明する。図１０は基本となる共通サービスシステムに対し、顧客が申し込み手続きを行うフローである。基本サービスは、顧客特性の収集、蓄積、管理機能やニュースなどの情報提供、アドバイス提供、様々な企業が提供する個別サービスの紹介、整理、申し込みや、必要に応じて個別サービスへの顧客特性の開示管理機能を提供する。顧客端末に表示されたＷＥＢ画面からサービス申し込みの操作を行うと、課金条件、個人情報保護の方針を含む利用規約が表示され、これに同意すると申し込み受付となり、ユーザＩＤ３０、仮パスワードが発行される。この後顧客はログイン画面より、ユーザＩＤと仮パスワードを使ってログインを行い、仮パスワードから自分で決めるパスワード３１への変更、生年月日、性別、居住地域、血液型などの基本プロファイル情報の入力を行うと基本サービスがスタートする。入力された基本プロファイル情報を基にどのクラスターに属するかをシステムが判断し、表示内容を決め、リコメンドなどの表示内容を選択、表示する。その後本人の入力やサービスを通じて特性情報が更新されると、その情報を使ってアドバイスやリコメンドなどの表示内容を更新することを繰り返して基本サービスが提供される。尚アドバイスやリコメンドなどの生成当っては、顧客特性のみを参照して行う必要はなく、居住地域情報や端末のセンサから得られた気温、湿度、天気などの環境情報や日付などを含めて生成してもよく、多様な情報を用いることでよりその場、その時に即したアドバイスやリコメンドを生成することが可能となる。
【００２８】
ログイン後最初に表示される基本サービスのトップ画面の例を図１１に示す。ポイント３２が表示されており、選択することでアドバイス、ニュースに遷移するアイコン３３、３４が表示されている。また、クラスタリング結果に応じて選択されたお勧めのサービスのアイコン３５が表示されており、アイコンを選択することでサービスに関する情報提供を行う画面を表示する。また、既に申し込みを行い実行中のサービスのアイコン３６が表示されている。図１２９はサービスに関する情報提供を行う画面の例である。各サービスの概要を示しており、サービス名、サービスに対応するアイコン、提供企業、サービス内容の簡易な説明、料金、付与ポイント、使用する特性情報などの他、より詳細な内容を説明する表示に接続するボタン４７や、サービスを申し込む手続きに接続するボタン４８が表示されている。現在サービスを受けている場合には図１３に示すような画面となる。現在サービスを受けている旨表示され、サービス停止の申し込み手続きに接続するボタン４９が表示されている。
【００２９】
さらに、基本サービスのトップ画面の例（図１１）では、データ閲覧のアイコン３７が表示されており、アイコンを選択することで、体重、活動量など各々のデータ項目のデータをグラフ表示するなどしてわかりやすい形で可視化する画面が表示される。画面下部のサービス選択アイコン３８を選択すると、サービス提供企業が提供する多様なサービスを選択する画面を表示する。また、情報提供アイコン３９を選択すると後述する情報提供依頼画面（図１６）を表示する。さらに、サービス履歴アイコン４０を選択すると後述するサービス履歴画面（図１５）を表示する。基本サービスを受けている顧客は、この例ではメールマガジンによる通知を受け取ることとする。メールには獲得ポイント、アドバイス、お勧めサービスなどの情報や、キャンペーン情報を掲載する他広告を載せるものとする。広告は広告管理ＤＢ１４で管理されている。尚、広告はメールマガジンに掲載するのみでなく、サービス画面の一部に表示させることでも構わない。
【００３０】
図１４は、基本サービスを受けている顧客が、個別サービスを受け、止めるまでの流れを説明している。基本サービスがサービス全体を管理する機能を担うのに対し、個別サービスは例えば特定のダイエットプログラムなど、個人の好みに応じて申し込むサービスである。個別サービスの提供の仕方は様々な形態が考えられるが、ここでは例として、ＣＣ社が自社のサービスシステムでサービスを行うとし、顧客への課金はＣＣ社が独自で行うものとして説明する。
【００３１】
ログイン後図１１のようなメニューを介して図１２のような個別サービスの詳細を確認し、申し込み手続きを行う。この際図１２にあるように、サービスを受けるにあたりＣＣ社にどんな特性情報を開示するかを確認し、同意できる場合のみ操作を行い申し込みを行うことになる。申し込み後基本サービスシステムの設定変更を行い、ＣＣ社のサービスシステムが顧客が許諾した特性情報に対しアクセス可能にし、ＣＣ社に通知を行う。また、基本サービス提供事業者は、システム利用料としてＣＣ社に対し課金を行う。ＣＣ社は基本サービスシステムが収集した顧客特性情報を用いてサービスのカスタマイズを行い、またサービスとして提供した内容の情報を共通サービスシステムに送る。共通サービスステムはサービス履歴として記録を行う。この履歴情報において、サービスを受けたこと自体は、顧客が承認すれば他社が特性情報として得ることができるが、サービス内で行ったアドバイスやメッセージに関しては、ＣＣ社のノウハウに属することであり、他社が得ることができない制御を行う。顧客がサービス停止を希望した場合、ＣＣ社に通知し、支払い等の条件確認を行った後、問題が無ければ顧客のサービス履歴を更新し、さらにＣＣ社のサービスシステムが顧客の特性情報にアクセス不可能となるよう更新を行う。
【００３２】
尚、このサービスを通じてＣＣ社が入手した顧客の特性情報を他の目的で利用したり、他社に開示したりすることは禁止することとする。禁止は契約によって行うが、技術的な対策を講じても良い。例えば、肌画像など、画像や音声に関しては電子透かしを用いる。また、活動量計データに関しては、各時間間隔のデータを数カウント変更しても実用上問題がないことから、開示するサービス、あるいは事業者毎に異なるカウント変更パターンを加えたデータを開示する。例えば事業者毎に異なる時刻のデータに数カウントの変更を行う。同時にこの変更パターンを記録しておく。後でデータの不正な転用が疑われる場合には、このデータと記録しておいた変更パターンをつき合わせることでどのようなルートで流出したかが判定できる。実用上の影響をより少なくするためには、一日の生活の中でカウント数が多い昼間のデータに対してカウント変更を行うことが望ましい。
【００３３】
図１５は、サービス履歴画面の例である。図９のサービス履歴情報に基づき、必要に応じ図３のサービス管理データも参照して表示を行う。サービス名４１に対し、提供企業、サービス期間、現在サービスを受けているのかの状態、そのサービスでこれまでに獲得したポイント、サービスを受けるのに開示した、あるいは開示中のデータ項目４６が示されている。サービス名４１のどれかを選択した場合にサービス内容の説明画面（図１２または図１３）を表示する。
【００３４】
図１６は、情報提供依頼画面の例である。企業などが基本サービスを通じて既に蓄積されている顧客特性や今後蓄積される顧客特性の提供を本人に求めることを目的とした画面である。あなたの記録４９として表示されているのは、顧客特性情報ＤＢ２に格納されているデータを元に作成する、今記録を行っている、あるいは過去に記録を行っていた顧客特性の項目である。調査やサービス開発などを目的に情報提供を希望する企業等は、顧客特性のどの項目に基づいた情報提供を希望するかを明らかにし、基本サービスの提供事業者に申し込みを行う。基本サービス提供事業者は調査の妥当性などの審査を行った後、あなたの記録４９項目と情報提供を希望する企業等が求める顧客特性の項目を勘案し、どのような組織がどのような情報提供を求めているのかを情報提供依頼画面（図１６）にて各顧客に対し表示する。ここで、顧客が記録を行っている特性情報の項目が情報提供を希望する企業等が求める顧客特性の項目を全て含んでいない場合でも、今後記録を行うことで情報提供に応えられる場合にはその旨を表して募集情報を表示する。ここでは、情報提供依頼画面において、記録を行っている項目と異なる記号で表示５０としている。これにより、顧客は新たに特性記録を始めて応募することで対価を得ることが出来、また情報提供を希望する企業等はより多くの顧客の特性情報を得ることができる。また、情報提供依頼を前述のクラスタリングの結果を利用して行ってもよい。クラスター毎の特性を把握することが可能である。顧客は募集名５１を選択して表示される募集の詳細情報（図１７）を閲覧し、目的や対価として与えられるポイントや求められている特性情報などを勘案し、募集に応募するのかを判断する。
【００３５】
応募しない判断をした場合、選択ボタン５２を選択すると情報提供依頼画面（図１６）に戻る。応募する判断をした場合、選択ボタン５３を選択すると応募画面を表示する。応募画面にて応募申し込みを行うと、システムは応募登録情報を顧客特性情報ＤＢ２内のこの顧客データに登録する。統計処理部１０にて、応募登録のある顧客のみの特性情報を集計して情報提供を希望する企業等提供する情報を作成する。基本サービスの提供事業者はこの情報を情報提供を希望する企業等に渡し、情報提供を希望する企業等は予め取り決めた条件に従って対価を支払う。基本サービスの提供事業者はこの対価を原資に応募した顧客にポイントを基本サービスシステムを通じて付与する。従来のアンケート等は、同意を得てから情報を収集し始めていたのに対し、本システムでは、本人が確認、同意した後、過去に蓄積した情報も含め情報提供に用いることができる。これは、生活習慣の記録と健康状態の相関など、長期に渡る情報収集が必要な場合、情報を集める労力、コストが膨大であることから非常に重要である。尚、情報提供の同意のみでなく、後日のサービス、商品等のお勧めを目的としたアクセスの同意を取ってもよい。提供された顧客特性に基づいてサービスや商品を開発する場合には、どのような特性を持った顧客がサービスや商品を高く評価するかを把握できるため、後日のお勧めが購買に結びつく可能性が高いからである。
【００３６】
次に前述のメールマガジンに掲載する広告についてさらに説明する。掲載する広告の内容は、前述のクラスタリングに基づき、顧客が興味を持つ可能性を勘案して決定する。また、広告の掲載依頼者が顧客特性情報を指定し、これに合致する顧客に該当する広告を掲載してもよい。この際、共通サービス提供事業者から掲載依頼者には、掲載数に加えて掲載した顧客の統計情報を提供することとする。掲載依頼者には個々の顧客の特性情報、個人情報などは渡らないため、個人情報を保護しながら掲載依頼者の求める特性にターゲットを絞った広告提示が可能である。例えば、活動量計データや睡眠計のデータなどで睡眠時間が一定時間以下の顧客に対して、快眠商品の広告掲載を依頼することなどが考えられる。また、掲載依頼者は、顧客の特性データの変化を掲載条件とすることもできる。例えば、ここ一ヶ月で体重が一定量以上増えた人や肌の水分状態が一定以上悪化した顧客に対し、次のメールマガジン発行のタイミングで各々ダイエットプログラムや保湿力の高い化粧品の広告掲載を依頼することなどが考えられる。
【００３７】
ここまで述べてきたように、サービスを受ける場合や情報提供に応じる場合に顧客は誰に対してどのような特性情報の開示が求められるかを確認し、同意を行って申し込みを行う。よって、同じ顧客の同じ項目の特性情報であってもその使い方や開示対象によって、顧客は別個の判断を行い、それに応じてサービス提供企業がアクセス可能な特性項目をシステムにより管理することが可能である。また、顧客は現在や過去の自分の特性情報の開示状況をサービス履歴画面（図１５）を通じて容易に確認することが可能である。
【００３８】
ポイントについて説明する。顧客は基本サービス、個別サービス、情報提供などで共通のサービスで共通のポイントを獲得できる。獲得したポイントは、個別サービスの支払いに充てたり、プレゼント交換したりできる。従来はアンケート等で、応じることに同意した後にアンケートに答える形で新たな情報を渡し、対価を得ることはしばしば行われてきた。本システムにおいては、これに加え、過去に貯めたデータを開示することで対価を得ることができるという特徴がある。
【実施例２】
【００３９】
本実施例では、顧客が特定の企業等の顧客であった場合、あるいは特定の企業等の顧客になる場合について説明する。
図１８にはＡＡ社の顧客が、共通サービスで提供するサービスに興味を持ち、サービス申し込みを行うフローを示す。共通サービス及び共通サービスが管理する個別サービスと、ここで述べる特定の企業等が異業種であっても構わない。ＡＡ社の顧客にとって共通サービスは、ＡＡ社のサービスの付帯サービスや特典サービスとして位置づけられる。まず、ＡＡ社固有のサービスシステムにて告知を行い、顧客が興味を持った場合受付画面を表示する。ここで、顧客の受付申し込み操作後にＡＡ社のシステムでログインを求めてもよいし、ログインした顧客のみに共通サービスシステムの紹介を行うのでも構わない。いずれにせよ、ログインを通じＡＡ社の顧客であることの確認がなされる。この後、異なるサービスシステムに遷移する旨同意を得た後、共通サービスシステムがＡＡ社顧客向けに提供する画面が表示される。まず既に共通サービスシステムのアカウントが存在するかを確認し、ない場合には利用規約を表示、同意できる場合に顧客が申し込み操作を行うと、ユーザＩＤ、仮パスワードが発行される。
【００４０】
改めてログイン画面でユーザＩＤ、仮パスワードを入力し、初期登録を行い、仮パスワードを顧客が決めるパスワードに変更するとサービスが利用可能になる。共通サービス提供事業者は顧客が申し込んだことをＡＡ社に通知し、ＡＡ社に対して顧客の共通サービス利用料の課金を開始する。また、この顧客に共通サービス提供事業者がポイントを付与する。ＡＡ社をこの顧客のオーナー企業と呼ぶことにする。この場合、第１実施例の図４で示した顧客特性データは、図１９のように、オーナー企業の列５４を追加すればよい。ＡＡ社はこの顧客が確かに自社の顧客であることを確認する。共通サービスシステムは顧客が入力した特性情報に基づき、クラスタリングを行ってサービスをカスタマイズする。ここで、顧客が許可した範囲において、ＡＡ社の保有する顧客特性情報をＡＡ社から受け取り、クラスタリング情報に活用しても構わない。ＡＡ社は自社の顧客のために共通サービス利用料を負担するが、ＡＡ社が顧客に課金するかはＡＡ社が判断するものとする。例えば、一定以上のサービス利用がある顧客の場合には全額を負担し、そうでない顧客に対しては課金を行う。また、ＡＡ社が固有のポイントサービスなどを行っている場合、ポイント消化という形を採ってもよい。
【００４１】
ここでオーナー企業が入手する顧客の特性情報について説明する。オーナー企業は自社顧客の特性情報全てにアクセスできるわけではない。顧客が共通サービスを申し込んだ際に顧客許諾の下、閲覧できるのは特性情報の一部項目、例えば顧客が受けたサービス種の履歴、メールアドレスである。この閲覧できる項目については、オーナー企業ごとに異なってもよい。その他の項目については、オーナー企業が個別サービスを提供する際に用いる必要があるなどの条件も下、顧客が許諾して始めて情報入手が可能である。例えばオーナー企業が保険会社である場合、刻々と変わる顧客の健康状態を把握できることは顧客の不利益に結びつく可能性が否定できないが、上記情報開示方針に従えば、保険会社の顧客も共通サービスを安心して利用することができる。
【００４２】
次に図２０を用い、上記ＡＡ社顧客がＢＢ社の固有サービスに申し込む場合を説明する。ＡＡ社と同様、自社の顧客のために共通利用サービスの利用料を負担する企業ＢＢ社があるとする。また、ＢＢ社は共通サービスを使っている顧客向けの個別サービスも提供しているとする。ＡＡ社の顧客は共通利用サービスの中から、ＢＢ社の個別サービスに興味を持ち、ＢＢ社のサービスシステムで提供される個別サービスを受けているとする。ＢＢ社のサービスにはＢＢ社固有のサービスの魅力の紹介や、ＢＢ社固有のサービスの会員はこの個別サービスを受ける際の特典が大きいなどの情報があり、このＡＡ社の顧客はＢＢ社固有のサービスにも申し込む。ＢＢ社は共通サービスに由来して自社の固有サービスに申し込まれたことを共通サービス提供事業者に通知する。共通サービス提供事業者は、ＢＢ社にこの顧客の共通サービスシステム利用料の課金を開始する。
【００４３】
図２１に課金条件の例を示す。自社の顧客に対してオーナー企業は共通サービス利用料を支払うが、顧客の人数により傾斜がかけられている。ここでは顧客数が一万人未満であるとして説明する。例えばＡＡ社について、自社のみが顧客のオーナー企業の場合（５５）、月の利用料は１５０円である。これに対し、上記のように新にＢＢ社もオーナー企業になった場合（５６）、ＡＡ社が払う月の利用料も、ＢＢ社の払う月の利用料も１００円となる。これに基づき、図２０においても、ＢＢ社に課金が開始されるのみで無く、ＡＡ社の課金条件も更新（５８）される。さらに一社オーナー企業が増えた場合（５７）、一社あたりの負担額は８０円となる。このように、オーナー企業が増えると個々のオーナー企業の負担が減るため、他社の固有サービスに顧客を誘導するインセンティブになる。
【００４４】
また、共通サービス提供企業においても、図２１のような設定であればオーナー企業の料金負担を足し合わせた料金は、それよりもオーナー企業数が少ない場合よりも上がっているため、オーナー企業を増やすためのキャンペーン等を行うインセンティブになる。複数社がオーナー企業の場合、図１９の例５９のように、オーナー企業ＩＤを複数記録すればよい。また、新たにＢＢ社の顧客であるという特性情報が加わったことにより、クラスタリングを更新する。図２２は図２０同様ＡＡ社顧客がＢＢ社の固有サービスに申し込む場合であるが、ＢＢ社の固有サービスに申し込んだことを共通サービス提供事業者に通知するのが顧客本人であるという点が異なる。この場合、顧客の登録申請６０に対し、ＢＢ社が確かにＢＢ社の固有サービスに加入したことを確認し、共通サービスシステムに通知する６１プロセスが追加される。顧客は新にＢＢ社をオーナー企業に加えたことにより、ポイントを得ることができる。また、ＢＢ社が自社の顧客に対して特典などを用意している場合、これも受けることが可能となる。図１７のフローでは顧客の手間が少ないという特長がある。一方、図１９のフローでは、ＢＢ社が共通サービスシステムからの流入を把握するシステム上の機能を用意せずともよいという特徴がある。
【００４５】
ここまで述べたように、ＡＡ社顧客のＢＢ社固有サービスへの顧客流入もあれば、その逆にＢＢ社顧客のＡＡ社固有サービスへの顧客流入もある。他社がオーナー企業となっている顧客も含め多くの顧客について顧客流入を分析すると流入しやすさの傾向がわかる。一般に、固有サービスを行っている事業者にとって、通常自社に顧客が流入することが望ましい。従って、顧客の流入におけるインセンティブ付与を非一様にすることで、流入動向の非対称性を緩和する施策が考えられる。図２３には、顧客の流入時の非一様なインセンティブ賦与の例を示す。図２３では、ＡＡ社からＢＢ社への流入は多いが、ＢＢ社からＡＡ社への流入は少ない。この場合、ＢＢ社からＡＡ社への顧客流入において付与するポイントをボーナスポイントを介して逆の場合よりも大きくし、ＢＢ社からＡＡ社への顧客流入を促す。このＢＢ社からＡＡ社への顧客流入の際のポイントを大きくするためのポイント原資の少なくとも一部をＢＢ社が負担する。これを多数の企業間で行うことで顧客流入が到るところで起きるようなインセンティブを与える。尚、ここでは流入割合で比較したが、流入数を勘案して行っても構わない。顧客流入動向は共通サービスのシステムの蓄積する記録が元になっており、インセンティブ調整機能も共通サービスステムが提供するものとする。また、上記非一様なインセンティブを共通サービスステムが与えるインセンティブにより実施してもよい。
【符号の説明】
【００４６】
１  共通サービスシステム、２  顧客特性情報ＤＢ、３  サービス管理ＤＢ、４ネットワーク、５  顧客端末，６  顧客端末、７  サービス提供事業者のサービスシステム、８サービスアプリケーション部、９アクセス管理部、１０  統計処理部、１１  ＷＥＢサービス部、１２  ポイント管理ＤＢ、１３  記事管理ＤＢ、１４  広告管理ＤＢ、４９  顧客が記録しているデータ項目、５０  今後記録を行うことで調査に応募できるデータ項目、５１  募集名、６２  サービス提供事業者のサービスシステム
【図１】
2015176263.tif 000003
【図２】
2015176263.tif 000004
【図３】
2015176263.tif 000005
【図４】
2015176263.tif 000006
【図５】
2015176263.tif 000007
【図６】
2015176263.tif 000008
【図７】
2015176263.tif 000009
【図８】
2015176263.tif 000010
【図９】
2015176263.tif 000011
【図１０】
2015176263.tif 000012
【図１１】
2015176263.tif 000013
【図１２】
2015176263.tif 000014
【図１３】
2015176263.tif 000015
【図１４】
2015176263.tif 000016
【図１５】
2015176263.tif 000017
【図１６】
2015176263.tif 000018
【図１７】
2015176263.tif 000019
【図１８】
2015176263.tif 000020
【図１９】
2015176263.tif 000021
【図２０】
2015176263.tif 000022
【図２１】
2015176263.tif 000023
【図２２】
2015176263.tif 000024
【図２３】
2015176263.tif 000025