(57)【要約】【課題】  利用者の潜在的なニーズを示すシナリオ候補を導出する情報処理装置、情報処理方法、及び情報処理プログラムを提供することにある。【解決手段】  利用者の行動プロセスをシナリオ構成定義情報、シナリオ順序定義情報、シナリオ条件定義情報を用いてモデル化し、利用者の利用者シナリオ履歴情報、前記利用者が属するモデルのシナリオ情報、および質問定義情報を参照して前記利用者への質問の集合を計算し（ステップ１３２２）、前記質問の集合から質問を一つ抽出して質問を実施し（ステップ１３２４）、前記利用者による前記質問の回答から新たに導出可能なシナリオの構成要素を計算し（ステップ１３２５）、前記利用者シナリオ履歴情報および前記計算されたシナリオ要素に対して、前記シナリオ条件定義情報の条件・推論ロジック適用することにより前記利用者の潜在的なニーズを示すシナリオ候補を計算する（ステップ１３２６）。【選択図】  図１４
2010186283.tif 000002
【特許請求の範囲】
【請求項１】
利用者の行動タイプや行動プロセスに対応する利用者の潜在ニーズに応じた情報を提供可能な情報処理装置において、
前記利用者の行動タイプおよび行動プロセスを示す情報であるペルソナ、前記利用者のある局面での利用シーンを示すシナリオの構成要素を定義するシナリオ構成定義情報および前記シナリオの構成要素の発生順序を含む関連性を定義するシナリオ順序定義情報を記憶する手段と、
前記利用者に対する質問への応答を入力する手段と、
入力された応答および前記記憶する手段への記憶内容を用いて、前記利用者に対するシナリオを生成する手段とを有し、
前記生成する手段は、前記入力する手段で更に入力される応答に基づいて、生成された前記シナリオを変更して、新たなシナリオを更に作成することを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記生成する手段にて、前記新たなシナリオを生成した場合、さらに前記利用者に対して質問を実行する手段を更に有することを特徴とする情報処理装置。
【請求項３】
請求項１または２のいずれかに記載の情報処理装置において、
前記生成する手段にて、前記新たなシナリオを生成できなかった場合、生成された前記シナリオを前記利用者に提示する手段と、
提示された前記シナリオに対する前記利用者からの指示により、当該シナリオを最終的なシナリオとして特定する手段とを更に有することを特徴とする情報処理装置。
【請求項４】
請求項１乃至３のいずれかに記載の情報処理装置において、
前記生成する手段は、
前記記憶する手段に応じて、複数のシナリオ候補を算出可能か判断し、
前記シナリオ候補が算出可能な場合、各シナリオ候補を算出して、算出されたシナリオ候補それぞれについての前記利用者への質問を特定し、
特定された質問に対する応答に対応するシナリオの構成要素を特定し、
特定された前記シナリオの構成要素を用いて、前記新たなシナリオを生成することを特徴とする情報処理装置。
【請求項５】
請求項１乃至４のいずれかに記載の情報処理装置において、
前記生成する手段は、前記ペルソナが記憶されていない場合には、前記利用者が特定できない匿名情報を利用して前記シナリオを生成することを特徴とする情報処理装置。
【請求項６】
請求項１乃至５のいずれかに記載の情報処理装置において、
前記記憶する手段は、前記ペルソナに対して満たすべき条件あるいは推論により得られる結果を記述した推論条件と前記シナリオに関する制約条件を形式論理として定義するシナリオ条件定義情報をさらに記憶し、
前記生成する手段は、前記シナリオ条件定義情報を用いて、前記利用者のニーズもしくは行動を予測することで、前記シナリオを生成することを特徴とする情報処理装置。
【請求項７】
利用者の行動タイプや行動プロセスに対応する利用者の潜在ニーズに応じた情報を提供可能な情報処理装置を、
前記利用者の行動タイプおよび行動プロセスを示す情報であるペルソナ、前記利用者のある局面での利用シーンを示すシナリオの構成要素を定義するシナリオ構成定義情報および前記シナリオの構成要素の発生順序を含む関連性を定義するシナリオ順序定義情報を記憶する手段と、
前記利用者に対する質問への応答を入力する手段と、
入力された応答および前記記憶する手段への記憶内容を用いて、前記利用者に対するシナリオを生成する手段として機能させ、
前記生成する手段を、前記入力する手段で更に入力される応答に基づいて、生成された前記シナリオを変更して、新たなシナリオを更に作成する機能を実現させるプログラム。
【請求項８】
請求項７に記載のプログラムにおいて、
前記生成する手段にて、前記新たなシナリオを生成した場合、さらに前記利用者に対して質問を実行する手段を更に機能させることを特徴とするプログラム。
【請求項９】
請求項７または８のいずれかに記載のプログラムにおいて、
前記生成する手段にて、前記新たなシナリオを生成できなかった場合、生成された前記シナリオを前記利用者に提示する手段と、
提示された前記シナリオに対する前記利用者からの指示により、当該シナリオを最終的なシナリオとして特定する手段とを更に機能させることを特徴とするプログラム。
【請求項１０】
請求項７乃至９のいずれかに記載のプログラムにおいて、
前記生成する手段に、
前記記憶する手段に応じて、複数のシナリオ候補を算出可能か判断し、
前記シナリオ候補が算出可能な場合、各シナリオ候補を算出して、算出されたシナリオ候補それぞれについての前記利用者への質問を特定し、
特定された質問に対する応答に対応するシナリオの構成要素を特定し、
特定された前記シナリオの構成要素を用いて、前記新たなシナリオを生成する機能を実行させることを特徴とするプログラム。
【請求項１１】
請求項７乃至１０のいずれかに記載のプログラムにおいて、
前記生成する手段に、前記ペルソナが記憶されていない場合には、前記利用者が特定できない匿名情報を利用して前記シナリオを生成する機能を実行させることを特徴とするプログラム。
【請求項１２】
請求項７乃至１１のいずれかに記載のプログラムにおいて、
前記記憶する手段に、前記ペルソナに対して満たすべき条件あるいは推論により得られる結果を記述した推論条件と前記シナリオに関する制約条件を形式論理として定義するシナリオ条件定義情報をさらに記憶させ、
前記生成する手段に、前記シナリオ条件定義情報を用いて、前記利用者のニーズもしくは行動を予測することで、前記シナリオを生成させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者の行動タイプや行動プロセスに応じて利用者の潜在ニーズを予測する情報処理装置、情報処理方法、及び情報処理プログラムに関し、特に営業店窓口での相談業務において担当者が利用者との相談の中で利用者の潜在ニーズを予測して解決手段を提案することができる窓口端末に用いて好適な情報処理装置、情報処理方法、及び情報処理プログラムに関する。
【背景技術】
【０００２】
利用者の過去の購買履歴を基にして利用者の購買希望商品を予測し、利用者に提示する「レコメンデーション」という技術が存在する。例えば、インターネット上でのある電子ショッピングサイトでは、利用者が閲覧した商品ページに応じて、「この商品を買った人はこんな商品も買っています」という形式で複数の商品情報を提示したり、「この商品を見た後に買っているのは？」という形式でどの程度の割合の人が他にどのような商品を購入しているかという情報を提示する。さらに、利用者が電子ショッピングサイトにログインし、利用者の過去の購買履歴が分かっている場合は、「おすすめ商品」という形式で利用者の過去の購買商品と関連性の高い商品を提示する。このようなレコメンデーション機能により、利用者の商品購買を支援するとともに、利用者の購買ニーズの予測によって商品販売の拡大につなげることが可能である。
【０００３】
特にこのレコメンデーション機能に関する従来技術として、特許文献１がある。特許文献１では、ユーザの負担を減らしつつユーザに適合したレコメンデーションを実現することを目的としている。このために、特許文献１では、コンピュータにより、ユーザに適した情報の選択に利用される嗜好情報をレコメンデーション手段に提供する方法に関するものである。この特許文献１では、ユーザに対して、嗜好情報の設定を促すとともに、ユーザの活動履歴情報に基づく分析によって嗜好分析情報が生成された場合にこの嗜好分析情報を提示し、嗜好情報の設定を促されたユーザによって設定された嗜好情報をレコメンデーション手段に提供する。
【０００４】
言い換えると、特許文献１では、ユーザは、自己の活動履歴情報を分析して嗜好分析情報が得られた場合に、この嗜好分析情報を参考にして自己の嗜好情報を設定するものである。このため、特許文献１では、ユーザによる嗜好情報の設定作業の負担を軽減できる。また、ユーザは、現在の嗜好を反映した嗜好情報を設定できる。そして、レコメンデーションの精度を向上させることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００３−２７１８５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
かかる従来の方法においては、利用者の過去の購買履歴と類似する他の利用者の購買履歴を参照して、利用者が求めている商品を予測しているが、具体的に表面化した利用者の商品閲覧や商品購買などの行動および類似する他の利用者の行動を分析するだけでは、利用者がそのような行動を起こそうとしている本質的な背景を突き止め、潜在的なニーズを捉えることは困難である。特に、特許文献１では、「過去に多くのユーザがＷｅｂサイト（ＥＣサイト）で購入したアイテムや、過去に多くのユーザがアクセスしたアイテムのパターンを統計的に分析」しており、やはり本質的な背景を突き止めることはできない。その上、ユーザ（利用者）の能動的な動作が必要になってくる。
【０００７】
本発明の目的は、利用者の行動プロセスの活用に加えて、利用者の行動タイプをモデル化し、利用者の行動シナリオを明確化することにより、利用者の表面的な行動から導出される利用ニーズではなく、利用者の行動の本質的な背景を考慮した潜在的な利用ニーズを捉えることが可能な情報処理装置、情報処理方法、及び情報処理プログラムを提供することである。
【課題を解決するための手段】
【０００８】
この目的を達成するために、本発明では、利用者の行動タイプおよび行動プロセスを「ペルソナ」として、利用者のある局面での利用シーンを示す「シナリオ」の構成要素を定義するシナリオ構成定義情報、シナリオの構成要素の発生順序などの関連性を定義するシナリオ順序定義情報、およびシナリオに関する制約条件や推論条件を形式論理（ロジック）として定義するシナリオ条件定義情報を用いて、新たなお勧め商品の提示を含む処理を実行する。本発明では、利用者の行動プロセスをシナリオ構成定義情報、シナリオ順序定義情報、シナリオ条件定義情報を用いてモデル化してシナリオを生成し、本シナリオから利用者の行為（質問への回答を含む）に基づいた新たなシナリオを生成するものとも表現することが可能である。より詳細には、このシナリオに基づく質問に対する利用者の回答と上述した各情報に基づいて、本シナリオに基づく新たなシナリオを動的に生成するものである。本発明には、この新たなシナリオの生成を、質問に対するシナリオの変更、例えば、そのシナリオの構成要素の変更により実現することや既に存在する（生成した）他のシナリオを抽出することも含む。なお、新たなシナリオ以前のシナリオの生成についても、予め生成（定義）したシナリオ（候補）に対する変更、既に存在する（生成した）シナリオ（候補）からの抽出が含まれる。また、シナリオ構成要素の変更には、置換、追加それらの組み合わせが含まれる。
【０００９】
上記の処理については、以下のようにも表現可能である。利用者の行動タイプに応じて複数のペルソナを事前に定義し、各ペルソナの行動プロセスを定義し、
利用者に対して事前に該当するペルソナを割り当てておく。そして、利用者がこれまでに行動したシナリオの履歴を記録した利用者シナリオ履歴情報、利用者が属するペルソナに関する前記三つの定義情報、およびペルソナやシナリオに応じて質問内容や質問に関する条件を定義した質問定義情報を用いて、利用者に対して実施可能な質問の集合を計算する。前記質問の集合から、次に実施する最適な質問を一つ計算して当該利用者に質問を実施する。利用者による前記質問の回答により、シナリオの構成要素を定義したシナリオ要素定義情報を参照して、利用者の行動タイプや行動プロセスに対して利用者のニーズを示すようなシナリオの構成要素を新たに計算することが可能である場合は、前記計算により導出されたシナリオの構成要素を保持しておく。前記利用者シナリオ履歴情報および前記保持したシナリオの構成要素に対して、前記のシナリオ条件定義情報に定義している条件・推論ロジックを適用することにより、新しく別のシナリオを計算できるか否かを計算する。新しく別のシナリオを計算できる場合は、利用者の潜在的なニーズを示すシナリオの可能性があると判断し、シナリオ候補として追加する。
【００１０】
なお、利用者にペルソナが紐付けられていない場合、任意のペルソナのシナリオに関する情報、他の利用者のシナリオに関する情報、または利用者を識別できない匿名のシナリオに関する情報を代替情報として活用し、当該利用者のシナリオ候補を計算する。
【００１１】
なお、本発明では、いわゆるサーバで上述の処理を実現する態様、端末で実現する態様のいずれもが含まれる。また、これら情報処理装置で処理を実行させるためのプログラムも含まれる。
【発明の効果】
【００１２】
本発明によれば、より潜在的なニーズを捉えることを可能になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態における情報処理システムの機能構成例を示す図である。
【図２】実施形態の利用履歴情報の一例を示す図である。
【図３】実施形態のシナリオ要素定義情報の一例を示す図である。
【図４】実施形態のシナリオ構成定義情報の一例を示す図である。
【図５】実施形態のシナリオ順序定義情報の一例を示す図である。
【図６】実施形態のシナリオ条件定義情報の一例を示す図である。
【図７】実施形態のペルソナ別利用者対応情報の一例を示す図である。
【図８】実施形態の利用者シナリオ履歴情報の一例を示す図である。
【図９】実施形態の質問定義情報報の一例を示す図である。
【図１０】実施形態のサーバにおいて利用者のシナリオ候補を計算する全体処理フローを示す図である。
【図１１】実施形態の窓口端末における利用者情報画面の一例を示す図である。
【図１２】実施形態のペルソナのシナリオ情報の概略イメージの一例を示す図である。
【図１３】実施形態の利用者のシナリオ情報の概略イメージの一例を示す図である。
【図１４】実施形態のサーバにおいて利用者のシナリオ候補を計算するサブ処理フローを示す図である。
【図１５】実施形態の窓口端末における利用者へのヒアリング支援画面の一例を示す図である。
【図１６】実施形態の利用者のシナリオ候補の概略イメージの一例を示す図である。
【図１７】実施形態の窓口端末における利用者への提案支援画面の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を用いて本発明の一実施形態について説明する。
本実施形態では、銀行営業店の相談窓口において、行員（相談窓口担当者）が利用者視点に立って、利用者とのコミュニケーションの中で利用者のニーズの本質的な背景を突き止め、利用者の潜在的なニーズを捉えた提案を行うための情報処理装置、情報処理方法、及び情報処理プログラムの例を用いる。ただし、本発明の技術的思想は、この例に限定されるものではない。なお、潜在的なニーズとは、利用者自身が意識しているものでも、無意識のものでも構わない。
【００１５】
図１は、本実施形態における情報処理システムの機能構成例を示す図である。複数の利用者端末２、複数の窓口端末３、およびサーバ１は通信網４を介して接続している。
【００１６】
図１に示すように、利用者端末２は４個の機能、窓口端末３は４個の機能、サーバ１は４個の機能を備えており、各機器のハードウェア及びハードウェアを制御するプログラムによってこれらの機能が動作する。
【００１７】
利用者端末２の第一の機能は、マウス、キーボード、タッチパネルなどの入力機器を利用して、利用者端末２で動作しているアプリケーション、例えば、インターネット上のＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）ページを参照したりするＷＷＷブラウザに対して、入力、選択などの操作を行うための入力機能２１である。
【００１８】
利用者端末２の第二の機能は、利用者が入力機能２１を用いて行ったマウス操作、キーボード操作、タッチパネル操作などの操作情報、ＷＷＷブラウザなどのアプリケーションにおける参照、入力、選択などの操作情報を利用履歴として取得する利用履歴取得機能２２である。
【００１９】
なお、アプリケーションにおける一部の操作情報、例えば、ＷＷＷブラウザが参照したページ情報やＷＷＷブラウザ上で実行した取引情報などは、サーバ１の利用履歴管理機能１２において利用履歴として取得することも可能である。
【００２０】
利用者端末２の第三の機能は、利用履歴取得機能２２において取得した利用履歴をサーバ１に送信し、かつサーバ１からＷＷＷページのようなアプリケーション画面などの画面表示に関する情報を受信する送受信機能２３である。
【００２１】
利用者端末２の第四の機能は、ＷＷＷブラウザのようなアプリケーションによる画面情報に基づいて画面表示を行うための画面表示機能２４である。
【００２２】
窓口端末３の第一の機能は、マウス、キーボード、タッチパネルなどの入力機器を利用して、窓口端末３で動作しているアプリケーションに対して、入力、選択などの操作を行うための入力機能３１である。
【００２３】
窓口端末３の第二の機能は、利用者と相談窓口担当者とのコミュニケーションにおいて、相談窓口担当者の相談業務を支援するためのナビゲーション機能３２である。例えば、相談窓口担当者が利用者に対して実施する質問を担当者に提示し、利用者の回答に応じてその回答に適した次の質問を担当者に提示し、いくつかの質問の実施後に利用者の潜在的なニーズを予測して担当者に提示する。
【００２４】
なお、利用者の回答に応じて提示する質問を計算する処理、および利用者の潜在的なニーズを予測して提示する処理は、サーバ１のシナリオ計算機能１３において行い、窓口端末３のナビゲーション機能３２は、クライアント側プログラムとして動作するものである。ただし、サーバ側プログラムとして動作するシナリオ計算機能１３の全部または一部をクライアント側プログラムとして分散処理してもよい。
【００２５】
窓口端末３の第三の機能は、ナビゲーション機能３２として動作しているクライアント側プログラムにおいて発生した操作情報をサーバ１に送信し、かつサーバ１からナビゲーション機能３２として動作しているクライアント側プログラムへの命令情報や画面情報などを受信する送受信機能３３である。
【００２６】
窓口端末３の第四の機能は、ナビゲーション機能３２として動作しているクライアント側プログラムによる画面情報に基づいて画面表示を行うための画面表示機能３４である。
【００２７】
サーバ１の第一の機能は、利用者端末２から利用履歴取得機能２２において取得した利用履歴を受信し、利用者端末２にＷＷＷページまたはアプリケーション画面などの画面表示に関する情報を送信し、窓口端末３からナビゲーション機能３２として動作しているクライアント側プログラムにおいて発生した操作情報を受信し、窓口端末３のナビゲーション機能３２として動作しているクライアント側プログラムに命令情報や画面情報などを送信するための送受信機能１１である。
【００２８】
サーバ１の第二の機能は、利用端末２の利用履歴取得機能２２により取得された利用履歴、サーバ１において取得された利用履歴（取引内容、取引結果など）を収集、管理する利用履歴管理機能１２である。
サーバ１の第三の機能は、窓口端末３のナビゲーション機能３２を利用した担当者と利用者とのコミュニケーションの中で、利用者の潜在的なニーズをシナリオ候補として計算するためのシナリオ計算機能１３である。なお、シナリオ計算機能１３の詳細については、以降で別途説明する。
【００２９】
サーバ１の第四の機能は、サーバ１において取扱う情報を管理する記憶機能１４である。記憶機能１４は、利用履歴情報１４１、シナリオ要素定義情報１４２、シナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５、ペルソナ別利用者対応情報１４６、利用者シナリオ履歴情報１４７、質問定義情報１４８を格納している。
【００３０】
なお、サーバ１、利用者端末２、開発者端末３のいずれか二つまたはすべてが、通信網３を介さず物理的に１台の装置であって、上記で説明した機能を１台の装置の中に有するものであってもよい。
【００３１】
以下では、サーバ１の記憶機能１４において管理される利用履歴情報１４１、シナリオ要素定義情報１４２、シナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５、ペルソナ別利用者対応情報１４６、利用者シナリオ履歴情報１４７、質問定義情報１４８について説明する。
【００３２】
図２は、実施形態の利用履歴情報１４１の一例を示す図である。
図２において、操作時刻１４１１は利用者端末２の利用履歴取得機能２２またはサーバ１の利用履歴管理機能１２において利用履歴を取得した時刻、利用者ＩＤ１４１２は操作を行った利用者を識別するＩＤ、操作種類１４１３は利用者による操作の種類、操作内容１４１４は利用者による操作の内容である。
【００３３】
操作種類１４１３は、利用者がＷＷＷページを参照した場合は「参照」、アプリケーションの取引画面や検索画面などにおいて契約や検索などの実行操作を行った場合は「操作」として区別する。「参照」、「操作」以外の操作種類があってもよい。
【００３４】
操作内容１４１４は、操作種類１４１３が「参照」である場合は参照したＷＷＷページのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）、「操作」である場合はアプリケーションにおいて実行した操作をサーバ側で特定できる識別子、または実行したプログラム名称などである。
【００３５】
操作種類１４１３および操作内容１４１４は、ＷＷＷサーバのログ作成機能、サーバ側プログラムのログ作成機能により取得することが可能である。また、既存のＡｊａｘ（Ａｓｙｎｃｈｒｏｎｏｕｓ  ＪａｖａＳｃｒｉｐｔ＋ＸＭＬ）技術やＡｄｏｂｅ社のＦｌａｓｈ（Ｒ）技術などを利用することにより、利用者のマウス操作やキーボード操作の詳細な操作情報を取得することが可能である（これらの各名称は商標である）。
【００３６】
例えば、レコード１４１５は、「２００８年１２月１日１５時５分１０秒に、利用者ＩＤが１００１である利用者が投信売却ページ（ｆｕｎｄ−ｓｅｌｌ．ｈｔｍｌ）を参照した」ことを示す。また、レコード１４１６は「２００８年１２月１日１５時８分１５秒に、利用者ＩＤが１００１である利用者が投信売却のシミュレーション（ｓｅｌｌ−ｓｉｍｕｌａｔｉｏｎ）を実行した」ことを示す。
【００３７】
なお、利用履歴情報１４１は、ＷＷＷサーバで取得した利用履歴、複数の各アプリケーションで取得した利用履歴を一つの情報としてまとめて示したが、複数の情報として別々に管理（格納）してもよい。
【００３８】
また、利用者端末２やサーバ１において取得可能な利用履歴以外にも、提携する外部システムや外部端末、例えば、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）サイトやコミュニティサイトなどから利用履歴を取得してもよい。
【００３９】
以下では、「シナリオ要素」を、利用者の個々の最小の行動単位と定義する。例えば、利用者の「投信売却のチェック」、「投信価額のチェック」、「投信解約シミュレーションの実施」、「住宅ローンの契約」などである。シナリオ要素の定義の詳細については、以降の図３において説明する。
【００４０】
以下では、「シナリオ」を、複数のシナリオ要素から構成される意味のある一かたまりの行動と定義する。例えば、利用者の「投信売却による住宅ローン契約」、「債券担保ローン利用による資産運用」などである。
【００４１】
以下では、利用者の行動タイプを分類する手法としてペルソナ手法を活用する。
ペルソナ手法とは、利用者のプロファイルを詳細に設定して架空の利用者モデル（人格をもった仮想の人物像）を作り上げ、その「人（ペルソナ）」に向けて商品開発、宣伝・販促、ニーズ追求を行う手法である。なお、「ペルソナ」とは、「人格を持った仮想の人物像」を示す情報である。なお、仮想とはいえ、現実の利用者の人物像を示す情報であっても構わない。
【００４２】
本実施形態では、前記で定義したシナリオを活用して、複数のペルソナの行動プロセスを事前に定義する。シナリオ、およびペルソナ手法を活用した利用者のモデル化の詳細については、以降の図４〜図６で説明する。
【００４３】
以下では、各利用者に対して事前にペルソナを割り当てておく。ただし、利用者に関する情報（行動プロセス情報、つまりシナリオ情報）が不十分で、ペルソナに割り当てることができない利用者が存在してもよい。ペルソナに属する利用者の管理の詳細については、以降の図７において説明する。
【００４４】
以下では、利用者の「シナリオ情報」を、利用者の実際の行動プロセスに従ってシナリオ要素を時系列に並べたものと定義する。ペルソナのシナリオ情報についても利用者の場合と同様に定義する。各利用者のシナリオ情報はサーバ１の記憶機能１４において管理する。各利用者のシナリオ情報の詳細については、以降の図８において説明する。
【００４５】
図３は、シナリオ要素定義情報１４２の一例を示す図である。
図３において、シナリオ要素ＩＤ１４２１は各シナリオ要素を一意に識別するＩＤ、シナリオ要素名１４２２はシナリオ要素の名称、操作種類１４２３は利用者による操作の種類、操作内容１４２４は利用者による操作の内容、成立条件１４２５はシナリオ要素として成立するための当該操作内容に対する条件である。
一つのシナリオ要素は複数の（操作種類、操作内容、成立条件）の組から構成される。
【００４６】
成立条件１４２５は、シナリオ要素が成立するために、該当する操作内容の発生順序、発生回数、発生期間などの満たすべき条件を示す。なお、この条件は、複数の操作内容にまたがって成立条件を記述してもよい。ただし、必ずしも発生順序、発生回数、発生期間などのすべての制約を記述する必要はない（少なくとも１つを含むようにすればよい）。また、シナリオ要素定義情報１４２は事前に定義しておき、記憶装置に格納しておく。例えば、レコード１４２６は、「ある利用者の利用履歴において、１番目に口座残高ページ（ａｃｃｏｕｎｔ．ｈｔｍｌ）を参照し、２番目に投信価額ページ（ｆｕｎｄ−ｐｒｉｃｅ．ｈｔｍｌ）を参照し、３番目に投信売却のシミュレーション（ｓｅｌｌ−ｓｉｍｕｌａｔｉｏｎ）を実行したなどの履歴が存在する場合、投信売却チェックというシナリオ要素が成立する」ことを示す。なお、前記の図３のシナリオ要素定義情報１４２はペルソナ別に定義してもよい。
【００４７】
次に、ペルソナを活用して行動プロセスをモデル化するために、シナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５を定義し、これらの定義情報を組み合わせて利用する。
【００４８】
図４は、シナリオ構成定義情報１４３の一例を示す図である。
図４において、ペルソナＩＤ１４３１は各ペルソナを一意に識別するＩＤ、シナリオＩＤ１４３２はペルソナの行動プロセスとして定義するシナリオを一意に識別するＩＤ、シナリオ名１４３３は当該シナリオの名称、シナリオ要素ＩＤ１４３４は当該シナリオを構成する個々のシナリオ要素のＩＤ、重み１４３５は当該シナリオにおける当該シナリオ要素の重要度を示す値である。シナリオ構成定義情報１４３の欄には、前記以外の属性を追加して用いてもよい。シナリオ構成定義情報１４３は、事前に定義しておき、記憶装置に格納しておく。
【００４９】
例えば、図４では、あるペルソナのペルソナＩＤがＰ１であり、このペルソナは複数のシナリオ（Ｓ０、Ｓ１、Ｓ２、・・・）から構成されている。さらに、前記シナリオＳ１は複数のシナリオ要素（ａ１、ａ２、ａ３、ａ６、・・・）から構成されている。
【００５０】
この場合、シナリオＳ１においてシナリオ要素ａ１の重みは２０、シナリオ要素ａ２とａ３の重みは１０、シナリオ要素ａ６の重みは３０であり、シナリオＳ１の中ではシナリオ要素ａ６の重みが一番大きいので、シナリオＳ１の中でキーとなるシナリオ（重要な行動）であることを示す。シナリオ構成定義情報１４３は、ペルソナを構成するシナリオ、シナリオを構成するシナリオ要素、およびシナリオ要素の重みなどを定義したものである。シナリオ内におけるシナリオ要素の順序関係などの関連性、シナリオ間やシナリオ要素間の制約条件や成立条件などの行動プロセスを特徴付けるためのロジック（プログラム）は、それぞれシナリオ順序定義情報１４４およびシナリオ条件定義情報１４５を用いて定義する。
【００５１】
図５は、シナリオ順序定義情報１４４の一例を示す図である。
図５において、ペルソナＩＤ１４４１は各ペルソナを一意に識別するＩＤ、シナリオＩＤ１４４２はペルソナの行動プロセスとして定義するシナリオを一意に識別するＩＤ、順序１４４３はシナリオ間の順序関係またはシナリオ要素間の順序関係を複数定義したものである。シナリオ順序定義情報１４４の欄には、前記以外の属性を追加して用いてもよい。なお、シナリオ順序定義情報１４４は事前に定義しておき、記憶装置に格納しておく。
【００５２】
ペルソナ内のシナリオ間の順序関係を定義する場合は、当該ペルソナのシナリオＩＤ１４４２の欄に「―」と記述し、順序１４４３の欄にシナリオ間の順序関係を指定する。ここで、「−」とは、シナリオ同士の順序を示す情報であることを示しており、他の形態で定義してもよい。図５の例で説明すれば、図５における三つ目のレコードは、ペルソナＰ１の中で定義されているシナリオに対して「シナリオＳ０の次にシナリオＳ１が発生し（Ｓ０→Ｓ１）、シナリオＳ０の次にシナリオＳ２が発生する（Ｓ０→Ｓ２）」ことを示す。この例は、シナリオＳ０からシナリオＳ１またはＳ２に分岐する可能性があることの事例（を示す情報）である。
【００５３】
シナリオ内のシナリオ要素間の順序関係を定義する場合は、当該ペルソナのシナリオＩＤ１４４２の欄に当該シナリオＩＤを指定し、順序１４４３の欄にシナリオ要素間の順序関係を指定する。
【００５４】
例えば、図５における一つ目のレコードは、シナリオＳ１の中で定義されているシナリオ要素に対して「シナリオ要素ａ１の次にシナリオ要素ａ２が発生し（ａ１→ａ２）、シナリオ要素ａ２の次にシナリオ要素ａ３が発生する（ａ２→ａ３）」ことを示す。なお、シナリオ構成定義情報１４３で定義したシナリオまたはシナリオ要素がすべて順序関係として定義される必要はない。少なくとも、シナリオ要素を１以上含むシナリオを定義できればよい。
【００５５】
図６は、シナリオ条件定義情報１４５の一例を示す図である。
図６において、ペルソナＩＤ１４５１は各ペルソナを一意に識別するＩＤ、条件ＩＤ１４５２は当該ペルソナに対して後述の条件・推論１４５３を一意に識別するＩＤ、条件・推論１４５３は当該ペルソナに対して満たすべき条件あるいは推論により得られる結果を記述したものである。
【００５６】
シナリオ条件定義情報１４５の欄には、前記以外の属性を追加して用いてもよい。なお、シナリオ条件定義情報１４５は事前に定義しておき、記憶装置に格納しておく。
【００５７】
例えば、図６における一つ目のレコード（条件ＩＤがＣ１であるレコード）は「シナリオがS1であることを満たすためには、S1におけるシナリオ要素のカバー率が６０％以上必要である」という制約条件を示す。また、図６における二つ目のレコード（条件ＩＤがＣ２であるレコード）は「シナリオS1においてシナリオ要素a６が存在する場合は、シナリオS2においてシナリオ要素b2も存在する（と推測する）」という推論結果を示す。
【００５８】
図６の例では、前記の条件１４５３の記述は自然言語を用いているが、実装上ではプログラミング言語を用いて形式的に条件文、繰り返し文、比較、代入などの論理式を記述する。シナリオ条件定義情報１４５に記述する条件・推論１４５３は、利用者のこれまでの利用履歴や現在の行動プロセスからボトムアップ的にペルソナに反映可能なシナリオに加えて、定量調査や定性調査によりトップダウン的にペルソナとして描きたいシナリオ、さらに相談窓口担当者や銀行企画部門のノウハウをロジックとして記述する。
【００５９】
従って、シナリオ構成定義情報１４３とシナリオ順序定義情報１４４に加えて、シナリオ条件定義情報１４５を用いて行動プロセスをロジックとして記述することにより、利用者の潜在ニーズを導出することが可能である。
【００６０】
図７は、ペルソナ別利用者対応情報１４６の一例を示す図である。
図７において、ペルソナＩＤ１４６１は各ペルソナを一意に識別するＩＤ、利用者ＩＤ１４６２は当該ペルソナに属する複数の利用者ＩＤを記述したものである。例えば、図７における一つ目のレコード（ペルソナＩＤがＰ１であるレコード）は「ペルソナＰ１に属する利用者ＩＤは１００１、１００２、・・・である」ことを示す。なお、利用者がどのペルソナに属するかを事前に決定しておき、登録しておくこの決定は、人間（システム運用者等）が行ってもよいし、システム的に自動で決定してもよい。ただし、利用者に紐付け可能なペルソナが存在しない、または利用者に関する情報が不十分でペルソナを決定できないなどの理由により、どのペルソナに属するかが決定できない利用者が存在してもよい。この場合、対応付けるペルソナを登録しなくともよいし（空白）、標準ペルソナと呼ばれる標準的なデータを登録しておいてもよい。
【００６１】
図８は、利用者シナリオ履歴情報１４７の一例を示す図である。
図８において、利用者ＩＤ１４７１は利用者を識別するＩＤ、時刻１４７２は当該利用者のシナリオ要素が発生した時刻、シナリオ要素ＩＤ１４７３は当該利用者の発生したシナリオ要素のＩＤである。利用者シナリオ履歴情報１４７の欄には、前記以外の属性を追加して用いてもよい。時刻１４７２は、例えば、当該シナリオ要素が最初に発生した時刻である。図２の利用履歴情報１４１と図３のシナリオ要素定義情報を参照すると、シナリオ要素ａ１の発生時刻は１番目の操作内容（ａｃｃｏｕｎｔ．ｈｔｍｌの参照）が最初に記録された時刻「２００８／１２／０１  １５：００：００：０１」である。
【００６２】
利用者シナリオ履歴情報１４７は、利用者者端末２の利用履歴取得機能２２などにより得られた利用履歴情報１４１を基にして、図３のシナリオ要素定義情報１４２を参照して、随時、シナリオ要素を抽出して利用者シナリオ履歴情報１４７に追加していく。
【００６３】
なお、シナリオ要素定情報１４２を参照して、利用者の利用履歴情報１４１からシナリオ要素を抽出する際、必ずしも操作内容１４２４が利用履歴情報１４１において上下隣り合った連続したレコードの系列となって出現する必要はない。つまり、利用履歴情報１４１において他の操作内容が入り込んでいてもよい。
【００６４】
図９は、質問定義情報１４８の一例を示す図である。
図９において、ペルソナＩＤ１４８１は各ペルソナを一意に識別するＩＤ、シナリオＩＤ１４８２は当該ペルソナにおけるシナリオを一意に識別するＩＤ、質問ＩＤ１４８３は当該シナリオにおける質問を一意に識別するＩＤ、質問１４８４は当該シナリオにおける質問内容と回答の選択肢、条件１４８５は当該質問を行うための制約条件である。なお、質問定義情報１４８は事前に定義しておき、登録しておく。なお、この情報を含め「事前に定義しておく」ものは、管理者など人手で入力されたものを格納すればよい。条件１４８５は、質問を行う順序に関する条件や、ある条件を満たしたときに有効となるような条件が記述される。
【００６５】
質問定義情報１４８は、サーバ１のシナリオ計算機能１３において利用者のシナリオ候補を計算するために、窓口端末３のナビゲーション機能３２において、相談窓口担当者が利用者に質問を行う際に活用するものである。質問は利用者が属するペルソナや利用者の推定されるシナリオ候補、また利用者の回答の内容や質問に関する条件１４８５に応じて、次に行う質問（または質問の集合）が動的に計算される。
【００６６】
ある場面で同様の（特に同じ）シナリオである異なる二人の人が存在しても、二人の属するペルソナが異なれば、各ペルソナのその場面のシナリオに適した異なる質問を行うように定義することができる。
【００６７】
このような質問をいくつか繰返すことにより、シナリオ要素を新たに獲得することができ、その結果、シナリオ候補の計算に役立てることができる。
【００６８】
以下では、サーバ１のシナリオ計算機能１３の処理フローについて説明する。
相談窓口担当者が利用者との相談業務の中で、窓口端末３のナビゲーション機能３２により、利用者に質問を行いながら、利用者のシナリオを明らかにしていくことにより、利用者の潜在的なニーズを掘り起こす。
【００６９】
シナリオ計算機能１３は、そのシナリオを明らかにしていく過程においてサーバ１で利用される。
【００７０】
図１０は、実施形態のサーバ１において利用者のシナリオ候補を計算する全体処理フローを示す図である。
ステップ１３１では、ペルソナ別利用者対応情報１４６を参照して当該利用者にペルソナが紐付けられているか否かを調べ、ペルソナに紐付けられている場合はステップ１３２に遷移し、ペルソナに紐付けられていない場合はステップ１３６に遷移する。
【００７１】
ペルソナ別利用者対応情報１４６から当該利用者を識別する利用者ＩＤを検索し、該当するペルソナＩＤが存在すればペルソナに紐付けられているとし、以降の処理フローではこのペルソナＩＤに対応する情報を参照する。
【００７２】
ステップ１３２では、当該利用者に質問を実施しながら、当該利用者に該当するシナリオ候補を計算する。
本ステップの詳細については、以降で説明する。
【００７３】
図１１は、実施形態の窓口端末３における利用者情報画面の一例を示す図である。当該利用者にペルソナが紐付けられている場合、窓口端末３に図１１のような当該利用者に関する情報を相談窓口担当者に表示する。
【００７４】
画面領域６０１は、当該利用者に紐付けられているペルソナに関する情報（例えば、ペルソナの概要）を表示する。例えば、図１１のように、ペルソナのタイプが「積極運用派」であり、このタイプに属する人は「ＩＴを使いこなしている」、「資産運用へは積極的である」という特徴を持つことを表示する。また、このタイプの人物像を想像させるような写真を掲載する。
【００７５】
画面領域６０２は、当該利用者に関する顧客基本情報を表示する。例えば、図１１のように、利用者名、年収、取引情報（口座開設状況、取引資産残高など）を表示する。画面領域６０３は、図１１のように、相談窓口への来店予約など、利用者の現在の状態に関する情報を表示する。
【００７６】
画面領域６０４は、図１１のように、利用者のこれまでの取引や詳細操作（例えば、インターネットバンキングで投信解約シミュレーションを実施など）に関する履歴情報を表示する。画面領域６０５は、相談窓口担当者向けにお客様への接客を支援するガイダンス（アドバイス）を表示する。
【００７７】
図１２は、実施形態のペルソナのシナリオ情報の概略イメージの一例を示す図である。
シナリオ構成定義情報１４３とシナリオ順序定義情報１４４より、ペルソナＩＤがＰ１であるペルソナには、シナリオＳ０、Ｓ１、Ｓ２などが存在し、Ｓ０→Ｓ１、Ｓ０→Ｓ２などの順序関係が存在する。
【００７８】
また、シナリオ構成定義情報１４３とシナリオ順序定義情報１４４より、ペルソナＰ１のシナリオＳ１内にはシナリオ要素ａ１、ａ２、ａ３、ａ６などが存在し、ａ１→ａ２、ａ２→ａ３、ａ３→ａ６などの順序関係が存在する。
【００７９】
図１２は、ペルソナＩＤがＰ１であるペルソナのシナリオ間の順序関係と、シナリオ内のシナリオ要素間の順序関係を示したものであり、領域５０１はシナリオＳ０内のシナリオ要素間の順序関係、領域５０２はシナリオＳ１内のシナリオ要素間の順序関係、領域５０３はシナリオＳ２内のシナリオ要素間の順序関係を概略イメージとして示したものである。
【００８０】
ただし、図１２では、シナリオ条件定義情報１４５に定義されたシナリオまたはシナリオ要素に関する条件・推論のロジックの記述は省略している。なお、シナリオ間でシナリオ要素が重複したり、シナリオ間で包含関係があったり、シナリオ条件定義情報１４５で定義されたロジックや利用者のシナリオまたはシナリオ要素に応じて動的にシナリオを変化させてもよい。
【００８１】
図１３は、実施形態の利用者のシナリオ情報の概略イメージの一例を示す図である。利用者シナリオ履歴情報１４７より、利用者ＩＤが１００１である当該利用者のこれまでの行動プロセスとして、ａ１→ａ２→・・・のように時系列で並んだシナリオ要素が存在する。
【００８２】
図１３は、利用者ＩＤが１００１である当該利用者のシナリオ情報、つまりシナリオ要素の順序関係を示したものであり、領域５１１は当該利用者の全体の利用者シナリオ情報、領域５１２はこれまでの利用履歴（行動プロセス）の中でシナリオ候補として計算可能な部分を概略イメージとして示したものである。
【００８３】
ただし、図１３では、利用者シナリオ履歴情報１４７に記録された時刻１４７２に関する情報の記述は省略している。なお、領域５１２に示したシナリオ候補の計算に関しては、以降の図１４の処理フローで説明するが、利用者が相談窓口を利用するたびに、つまり図１０のステップ１３２を行うたびにシナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５を利用して動的に計算する。
【００８４】
利用者は相談窓口で担当者に相談を行う段階で、利用者のこれまでの行動履歴（図１３のような利用者のシナリオ情報）、および利用者にペルソナが紐付けられている場合は当該ペルソナに関するシナリオ情報（図１２のようなペルソナのシナリオ情報）を持ち、サーバ１の記憶機能１４において管理されている。
【００８５】
図１４は、実施形態のサーバ１において利用者のシナリオ候補を計算するサブ処理フローを示す図である。
図１４は、図１３のステップ１３２において、当該利用者に質問を実施しながら、当該利用者に該当するシナリオ候補を計算するための処理フローである。
【００８６】
ステップ１３２１では、当該利用者の利用者シナリオ履歴情報１４７に対して、シナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５を参照して、当該利用者のシナリオ情報の中からシナリオ候補を抽出できるか否かを計算する。
【００８７】
本ステップにおいて、シナリオ候補を抽出できた場合は、以降の処理においてもシナリオ候補の情報を保持しておく。なお、シナリオ候補は複数存在し、これらを保持してもよいし、候補のうち一部を選択的に保持するようにしてもよい。この場合、上記の計算で計算値を算出する場合に、その値の大きさ（例えば、予め定めた閾値以上、一定数以上の数分）で選択するようにしてもよい。なお、図１３の領域５１２は、当該利用者のシナリオ情報の中からシナリオ候補としてシナリオＳ０を抽出できることを示す一例である。
【００８８】
ステップ１３２２では、上記ステプ１３２１で抽出したシナリオ候補の中からシナリオを一つ選択し、当該利用者の利用者シナリオ履歴情報１４７、質問定義情報１４８を参照して、当該利用者に対して実施可能な質問の集合を抽出する。シナリオ候補の中からシナリオを一つ選択する方法としては、例えば、シナリオ構成定義情報１４３の重み１４３５を参考にして、当該利用者のシナリオ情報の中に存在するシナリオ要素の重みの総和が最大であるようなシナリオを選択する方法が考えられる。
【００８９】
選択されたシナリオに対して、質問定義情報１４８を参照して、まだ利用者に行っていない質問の集合を抽出する。すでに利用者のシナリオ情報から質問を実施しなくても回答が分かっている場合は、このような質問を質問の集合から除外する。例えば、当該利用者のシナリオ情報の中にすでに「投信売却チェック」というシナリオ要素が存在する場合は、質問定義情報１４８に「投信の売却を検討していますか？」という質問があっても質問の集合から除外する。
【００９０】
一方、前記ステップ１３２１においてシナリオ候補が存在しない場合は、質問定義情報１４８を参照して、当該ペルソナに関係するすべての質問の集合から、まだ利用者に行っていない質問、およびすでに利用者のシナリオ情報から質問を実施しなくても回答が分かっている質問を除外して、質問の集合とする。ただし、質問定義情報１４８の条件１４８５に指定されている質問条件を満たす必要があるので、前記条件を満たさない質問は質問の集合から除外する。例えば、すでに「投信売却による住宅ローン契約」というシナリオにいる利用者に対して質問を進めている場合、別のシナリオに関係する質問や、同じシナリオでも初期段階（質問の順序関係の中で早い段階）にさかのぼった質問などは除外の対象となる。
【００９１】
ステップ１３２３では、前記ステップ１３２２において抽出した質問の集合が存在する場合はステップ１３２４に遷移し、質問の集合が存在しない場合（空の場合）は利用者に実施可能なすべての質問を終了したと判断して図１４における処理を終了して、図１０のステップ１３３に遷移する。
【００９２】
ステップ１３２４では、前記ステップ１３２２において抽出した質問の集合の中から、次に実施する最適な質問を一つ抽出して当該利用者に質問を実施する。
質問を一つ抽出する方法としては、例えば、質問定義情報１４８の条件１４８５を参照して、質問の順序関係として現在の質問の集合の中で一番最初に行うべき質問を抽出する方法が考えられる。これは、質問定義情報１４８の条件１４８５に含まれる優先度合いを示す情報に従って定めるようにする。
【００９３】
前記ステップ１３２１においてシナリオ候補が存在しない場合は、質問定義情報１４８を参照して、各シナリオに共通する質問が存在すれば、その質問を優先的に抽出する方法も考えられる。
【００９４】
図１５は、実施形態の窓口端末３における利用者へのヒアリング支援画面の一例を示す図である。
図１５は、前記ステップ１３２において抽出された質問情報を相談窓口担当者に表示し、利用者へのヒアリングを支援するための画面である。
画面領域６１１は、当該利用者にペルソナが紐付けられている場合、当該利用者に紐付けられているペルソナに関する情報（例えば、ペルソナの概要）を表示する。
【００９５】
画面領域６１２は、利用者に実施する質問に関する情報として、質問ＩＤ、質問内容、回答の選択肢などを表示する。利用者の回答内容に応じて、相談窓口担当者が窓口端末３の入力機能３１を利用して回答を入力する。あるいは、利用者自身が入力可能な端末が別に設置されており、その端末への入力（質問への回答の選択）に連動して、図１５の回答欄が入力されるような方式であってもよい。
画面領域６１３は、相談窓口担当者向けにお客様への接客を支援するガイダンス（アドバイス）を表示する。
【００９６】
利用者と相談窓口担当者との質問のやりとりの中で、利用者の回答に応じて次の質問が抽出されるたびに図１５のような画面を相談窓口担当者に表示する。
【００９７】
ステップ１３２５では、前記ステップ１３２４における質問の回答により、シナリオ要素定義情報１４２に記載されたシナリオ要素の意味的な内容を参照して、利用者の行動やニーズを示すシナリオ要素を新たに追加することが可能である場合は、当該シナリオ要素を利用者のシナリオ候補の計算に活用可能なシナリオ要素として保持しておく。
【００９８】
ステップ１３２６では、前記ステップ１３２１と同様に、当該利用者の利用者シナリオ履歴情報１４７に対して、シナリオ構成定義情報１４３、シナリオ順序定義情報１４４、シナリオ条件定義情報１４５を参照して、当該利用者のシナリオ情報の中からシナリオ候補を抽出できるか否かを計算する（計算結果が所定の範囲内など所定条件にマッチすれば抽出できると判断する）。この計算において、前記ステップ１３２５において新たに活用可能なシナリオ要素が存在する場合、当該利用者の利用者シナリオ履歴情報１４７に加えてこのシナリオ要素を合わせて、シナリオ候補を抽出できるか否かを計算する。
【００９９】
図１６は、実施形態の利用者のシナリオ候補の概略イメージの一例を示す図である。
前記ステップ１３２５において利用者のシナリオ情報に対して新たにシナリオ要素ａ６（図１６の５２２）が追加可能である場合、利用者のシナリオ候補であるシナリオＳ１は図１６の５２１のようになる。あるいは、別のケースとして、シナリオ要素ａ６を追加することにより、シナリオ条件定義情報１４５の条件・推論１４５３によってシナリオＳ１が新たにシナリオ候補として抽出できる場合も考えられる。
【０１００】
図１６のようにシナリオ要素ａ６を追加することにより、シナリオ条件定義情報１４５の条件・推論１４５３を参照すると新たなシナリオ要素ｂ２（図１６の５２４）も追加可能であるとする。さらに、このシナリオ要素ｂ２を追加することにより、シナリオ条件定義情報１４５の条件・推論１４５３を参照するとシナリオＳ２（図１６の５２３）がシナリオ候補として抽出可能であるとする。この推論ロジックにおいて、シナリオ構成定義情報１４３の重み１４３５を参照して、各シナリオの中に存在するシナリオ要素の重みの総和を計算することにより、どのシナリオが優先されるかを計算することができる。例えば、シナリオＳ１のみがシナリオ候補として抽出されていたが、前記の例により新たにシナリオＳ２もシナリオ候補として抽出され、シナリオＳ１の重みの総和が７０であり、シナリオＳ２の重みの総和が１１０である場合、新たに抽出されたシナリオＳ２の方が優先度が高い、つまり、利用者の潜在的なニーズにより近いシナリオであると予測することができる。
【０１０１】
以上のような推論ロジックにより、当該利用者のシナリオとしてＳ１だけではなく新たにＳ２もシナリオ候補として抽出することが可能であり、利用者の潜在的なニーズの掘り起こしにつなげることが可能になる。
【０１０２】
本ステップにおける処理が終わると、ステップ１３２２に戻り、処理を繰返す。なお、本ステップにおける処理により利用者のシナリオ候補が一つに絞れる場合は、図１４における処理フローを中断して、図１０のステップ１３３に遷移してもよい。図１４における利用者のシナリオ候補を計算するサブ処理フローが終わると、図１０におけるステップ１３３に遷移する。
【０１０３】
ステップ１３３では、図１４で抽出したシナリオ候補の計算結果を参照して、当該利用者のシナリオ候補が一つ以上存在するか否かを調べ、シナリオ候補が一つ以上存在する場合はステップ１３４に遷移し、シナリオ候補が存在しない場合はステップ１３５に遷移する。
【０１０４】
ステップ１３４では、複数存在するシナリオ候補を当該利用者に示し、シナリオの選択を要求し、シナリオを一つに決定する。あるいは、図１４のステップ１３２６において説明したように、各シナリオ候補の重みの総和を計算して、当該利用者の潜在的なニーズにより近いと予測されるシナリオを当該利用者に提示し、予測したシナリオが正しいか否かを確認してもらう方法でもよい。つまり、利用者の入力機器を介した入力に応じた選択を行う。
【０１０５】
図１７は、実施形態の窓口端末３における利用者への提案支援画面の一例を示す図である。図１７は、本ステップにおいて決定されたシナリオに基づいて、利用者に対する具体的な提案を相談窓口担当者に表示するための画面である。
画面領域６２１は、当該利用者にペルソナが紐付けられている場合、当該利用者に紐付けられているペルソナに関する情報（例えば、ペルソナの概要）を表示する。
【０１０６】
画面領域６２２は、利用者に対する提案に関する情報を表示する。具体的な提案内容は、各ペルソナの各シナリオごとに事前に作成しておくものとする。画面領域６２３は、相談窓口担当者向けにお客様への接客を支援するガイダンス（アドバイス）を表示する。
【０１０７】
ステップ１３５では、シナリオ候補が存在しない場合は、シナリオ候補を計算するために、当該利用者に個別にヒアリングを実施し、シナリオ情報を充実させる必要がある。
【０１０８】
ステップ１３６では、当該利用者にペルソナが紐付けられていない場合、任意のペルソナのシナリオ情報、他の利用者に関するシナリオ情報、利用者を識別できない匿名のシナリオ情報を代替シナリオ情報として活用し、当該利用者のシナリオ候補を計算する。
【０１０９】
次に、利用者を識別できない匿名のシナリオ情報について説明する。利用者ＩＤにより具体的な利用者を特定できる場合は、利用履歴情報１４１のように利用履歴を取得することが可能である。一方、利用者が本人認証を通さずにＷＷＷページを参照する場合は、利用履歴情報１４１の利用者ＩＤ１４１２の代わりに、利用者が利用している利用者端末２のＩＰアドレスなどの情報を取得することができる。このようなＩＰアドレスなどの情報は一般的なＷＷＷサーバの機能により取得可能である。同じＩＰアドレスによるアクセスがある場合は、具体的な利用者を特定することはできないが、同じ利用者がアクセスしている可能性が高いと判断し、このような利用者から得られるシナリオ情報を匿名のシナリオ情報と呼ぶ（このような匿名のシナリオ情報については、それを示す情報（フラグ等）を関連付けておく）。
【０１１０】
本ステップでは、ステップ１３２の処理（図１４の処理）と同様に考え、任意のペルソナのシナリオ情報、他の利用者に関するシナリオ情報、匿名のシナリオ情報を活用して、当該利用者により近い行動プロセスをもつ人のシナリオ情報を参考にしてシナリオ候補を計算することができる。
【０１１１】
以上のとおり、本実施形態では、利用者の行動タイプを複数のシナリオを用いてモデル化し、具体的には、シナリオ間の関連性およびシナリオ内部の個々の具体的な行動の関連性をロジック（プログラム）として定義し、モデル化された利用者が属する行動タイプ、利用者のこれまでの行動履歴（行動プロセス）、さらに利用者への質問によって、利用者の具体的なシナリオ候補を計算するので、利用者の表面的な行動から導出される利用ニーズではなく、利用者の行動の本質的な背景を考慮した潜在的な利用ニーズを捉えることが可能である。
【産業上の利用可能性】
【０１１２】
金融、公共、流通などの分野において、利用者と店員や担当者との間でコミュニケーションが発生する場、例えば、銀行営業店の相談窓口における相談業務を支援する装置、方法、及びプログラムとして利用可能である。
【符号の説明】
【０１１３】
１  サーバ
２  利用者端末
３  窓口端末
４  通信網
【図１】
2010186283.tif 000003
【図２】
2010186283.tif 000004
【図３】
2010186283.tif 000005
【図４】
2010186283.tif 000006
【図５】
2010186283.tif 000007
【図６】
2010186283.tif 000008
【図７】
2010186283.tif 000009
【図８】
2010186283.tif 000010
【図９】
2010186283.tif 000011
【図１０】
2010186283.tif 000012
【図１１】
2010186283.tif 000013
【図１２】
2010186283.tif 000014
【図１３】
2010186283.tif 000015
【図１４】
2010186283.tif 000016
【図１５】
2010186283.tif 000017
【図１６】
2010186283.tif 000018
【図１７】
2010186283.tif 000019