JP5951300B2 - サービス制御装置、サービス制御方法およびサービス制御プログラム - Google Patents

Description

本発明の実施形態は、サービス制御装置、サービス制御方法およびサービス制御プログラムに関する。

ユーザからの入力に基づいて、機器やウェブサービスなどの各種サービスを操作するサービス制御装置では、入力された情報を解析し、ユーザの意図した通りのサービスを提供することが要求される。

入力された情報からユーザの意図を解析し、各種サービスを操作するための条件を自動的に追加する技術がある。また、検索装置において、ユーザからの初期入力に基づいて検索式を生成し、検索結果に対するユーザからのフィードバックに基づいて検索式を再構築する技術がある。

しかしながら、これらの技術は、条件の追加やユーザからのフィードバック等の限られた知識に基づいてサービスを操作しており、ユーザの本来の目的に対して最適な結果が得られないという課題があった。

特開２００２−１０８６１４号公報 特開平６−２７４５３８号公報

発明が解決しようとする課題は、ユーザの本来の目的を考慮してサービスを操作するサービス制御装置を開発することである。

実施形態のサービス制御装置は、ユーザの要求に応じてサービスを操作するサービス制御装置であって、要求取得手段と、目的知識記憶手段と、目的推定手段と、サービス制御知識記憶手段と、サービス制御条件生成手段とを備える。要求取得手段は、ユーザの要求を取得する。目的知識記憶手段は、要求と要求の背景にある目的とを関連付けた目的知識を複数記憶する。目的推定手段は、目的知識を参照して、ユーザの要求に対応するユーザの目的を推定する。サービス制御知識記憶手段は、サービスを操作するための条件であるサービス制御条件の生成方法を、目的毎に記述したサービス制御知識を記憶する。サービス制御条件生成手段は、サービス制御知識を参照して、ユーザの要求とユーザの目的とに対応したサービス制御条件を生成する。

第１の実施形態のサービス制御装置を示すブロック図。 実施形態のサービス制御装置のハードウェア構成を示す図。 実施形態のサービス制御装置のフローチャート。 実施形態の目的知識の一例を示す図。 実施形態の選好知識の一例を示す図。 実施形態の目的をランキングする際のフローチャート。 実施形態の目的知識の表示形態の一例を示す図。 実施形態のサービス制御知識の一例を示す図。 実施形態の検索サービスからの出力の一例を示す図。 変形例の目的知識の表示形態の一例を示す図。

以下、本発明の実施形態について図面を参照しながら説明する。

（第１の実施形態）
第１の実施形態では、ユーザからの自然言語による入力を用いて旅行商品に関する検索を行い、その結果をユーザに提示するサービス制御装置について説明する。ここで、本実施形態のサービス制御装置は、外部の検索サービスを利用してユーザの本来の目的に適った旅行商品を検索し、ユーザに提示する。

本実施形態では、宿泊施設、ツアー情報、観光情報などの旅行商品を検索対象として説明するが、検索対象は旅行商品に限定されるものではない。また、本実施形態のサービス制御装置は、外部の検索サービスを操作するが、操作対象となるサービスは任意のアプリケーションであってもよい。

図１は、第１の実施形態にかかるサービス制御装置１００を示すブロック図である。本実施形態のサービス制御装置は、サービス要求取得部１０１と、サービス要求解析部１０２と、プロファイル取得部１０３と、状況情報取得部１０４と、目的知識記憶部１０５と、選好知識記憶部１０６と、目的推定部１０７と、サービス制御知識記憶部１０８と、サービス制御条件生成部１０９と、サービス制御部１１０と、サービス出力部１１１と、結果選択部１１２とを備える。

ここで、サービス制御部１１０およびサービス出力部１１１は、ネットワークを介して検索用の検索サービス１１３と接続している。

（ハードウェア構成）
本実施形態のサービス制御装置は、図２に示すような通常のコンピュータ端末を利用したハードウェアで構成されており、装置全体を制御するＣＰＵ（Central Processing Unit）等の制御部２０１と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の記憶部２０２と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の外部記憶部２０３と、キーボード、マウス、タッチパネル等の操作部２０４と、外部装置との通信を制御する通信部２０５と、音声を取得するマイク２０６と、合成音声を再生するスピーカ２０７と、映像を表示するディスプレイ２０８と、これらを接続するバス２０９とを備えている。本実施形態のサービス制御装置は、携帯型あるいは据え置き型のコンピュータ端末のどちらであってもよい。

このようなハードウェア構成において、制御部２０１がＲＯＭ等の記憶部２０２や外部記憶部２０３に記憶された各種プログラムを実行することにより以下の機能が実現される。

（各ブロックの機能）
サービス要求取得部１０１は、ユーザからの自然言語による要求をテキストデータとして取得し、サービス要求解析部１０２に送る。ユーザは、操作部２０４のキーボードを介して検索サービス１１３への要求（サービス要求）を入力することができる。サービス要求は、例えば「きれいな海に行きたい」などである。

この他にも、ユーザがサービス要求を音声で入力するようにしてもよい。この場合、マイク２０６で取得した音声を公知の音声認識技術によりテキストデータに変換する。

サービス要求解析部１０２は、サービス要求取得部１０１受け取ったサービス要求を解析し、機械可読なデータに変換して目的推定部１０７に送る。サービス要求解析部１０２の詳細は後述する。

プロファイル取得部１０３は、年齢、職業、性別、家族構成などのユーザのプロファイルを取得し、目的推定部１０７に送る。プロファイル取得部１０３は、操作部２０４のキーボードを介して、ユーザから直接プロファイルを取得してもよいし、公知のデータベースやファイルシステムによって実現されるプロファイル記憶部（図示なし）に予め記憶されたプロファイルを読み出すようにしてもよい。

状況情報取得部１０４は、日付、時刻、ユーザの位置、ユーザの行動といったユーザの状況に関する情報（状況情報）を取得し、目的推定部１０７に送る。状況情報取得部１０４は、ユーザの位置や行動に関する選択肢をユーザに提示し、操作部２０４を介してユーザに選択させるようにしてもよい。また、状況情報取得部１０４は、ＧＰＳや加速度センサ（図示なし）などの公知の状況センシング技術を用いて、ユーザの状況情報を読み出してもよい。例えば、ユーザが自宅の位置情報を予め登録しておくことで、ＧＰＳの示す位置情報からユーザが自宅にいるか否かを判別したり、加速度センサの示す加速度変化の波形からユーザが停止／歩行／乗車しているかを判別したりすることができる。

目的知識記憶部１０５は、サービス要求とそのサービス要求の背景にある目的とを関連付けた目的知識を複数記憶する。例えば、「きれいな海に行きたい」というサービス要求の背景には「海に行きたい」という目的がある、などを目的知識として記憶している。また、目的知識記憶部１０５は、目的知識同士の関連性も記憶する。これにより、「海に行きたい」という目的は「リゾートでのんびりしたい」という目的に関連することを判別でき、後述する目的推定部１０７において、サービス要求の表層だけでは分からないユーザの本来の目的を推定することができる。

目的知識記憶部１０５は、記憶部２０２や外部記憶部２０３で実現できる。目的知識記憶部１０５の詳細は後述する。

選好知識記憶部１０６は、プロファイルと目的知識および状況情報と目的知識を関連付けた選好知識を記憶する。選好知識は、例えば「子の有無＝有」というプロファイルをもつユーザは、「子供と遊びたい」という目的を強く持つ、などの情報を有している。これにより、後述する目的推定部１０７において、ユーザのプロファイルや状況情報を考慮してユーザの目的を推定することができる。

選好知識記憶部１０６は、記憶部２０２や外部記憶部２０３で実現できる。選好知識記憶部１０６の詳細は後述する。

目的推定部１０７は、サービス要求解析部１０２で変換されたサービス要求を用いて目的知識記憶部１０５に記憶された目的知識を検索し、得られた目的知識に従ってユーザ要求に対応するユーザの目的を推定する。

ここで、複数の目的が推定された場合、目的推定部１０７は、推定された目的に対応する選好知識を選好知識記憶部１０６から検索し、得られた選好知識と、プロファイル取得部１０３から受け取ったユーザのプロファイルと、状況情報取得部１０４から受け取った状況情報とに基づいて、各目的で検索サービス１１３が利用される度合いを表す選好度スコアを計算する。そして、この選好度スコアに従って、推定された複数の目的をランキングする。

目的推定部１０７は、推定された目的を後述するサービス制御条件生成部１０９に送る。推定された目的が複数ある場合は、ランキングの最上位の目的をサービス制御条件生成部１０９に送ってもよい。また、ランキングに含まれる全て、あるいは上位から一定数に含まれる複数の目的をユーザに提示し、ユーザが選択した目的をサービス制御条件生成部１０９に送るようにしてもよい。

サービス制御知識記憶部１０８は、検索サービス１１３を操作する際の条件であるサービス制御条件の生成方法をユーザの目的毎に記述したサービス制御知識を記憶している。例えば、旅行商品検索の場合、サービス制御知識とは、ユーザの旅行の目的と、客室のタイプ・付帯設備の有無・紹介文に含まれるキーワードなどからなる検索条件とを関係付けたものである。サービス制御知識記憶部１０８は、記憶部２０２や外部記憶部２０３で実現できる。サービス制御知識記憶部１０８の詳細は後述する。

サービス制御条件生成部１０９は、目的推定部１０７から受け取った目的を利用して、サービス制御知識記憶部１０８からサービス制御知識を検索し、得られたサービス制御知識とユーザ要求を用いてサービス制御条件を生成する。生成したサービス制御条件はサービス制御部１１０に送る。サービス制御条件生成部１０９の詳細は後述する。

サービス制御部１１０は、サービス制御条件生成部１０９から受け取ったサービス制御条件用いて、検索サービス１１３を操作する。

サービス出力部１１１は、検索サービス１１３の出力を受け取り、ディスプレイ２０８を介してユーザに提示する。

結果選択部１１２は、サービス出力部１１１の出力に対するユーザの操作を取得し、複数の出力が提示された場合にユーザがどの出力を好適として選択したかを検知する。

（フローチャート）
図３のフローチャートを利用して、本実施形態にかかるサービス制御装置の処理を説明する。

まず、ステップＳ１では、サービス要求取得部１０１は、ユーザのサービス要求を取得する。本実施形態では、「きれいな海に行きたい」というテキストデータを取得した場合を考える。

また、プロファイル取得部１０３は、ユーザのプロファイルを取得する。ユーザのプロファイルは、年齢、職業、性別、パートナーの有無、子の有無と年齢などである。本実施形態では、「年齢＝２５歳、職業＝会社員、性別＝男、パートナーの有無＝有、子の有無＝無、子の年齢＝ＮＡ」を取得したとする。ここで、「ＮＡ」は値を取得できなかったことを表す。

プロファイル取得部１０３は、一度取得したプロファイルを記憶部２０２あるいは外部記憶部２０３に記憶しておき、２回目以降は記憶したプロファイルに変更がないことをユーザに確認するようにしてもよい。

また、状況情報取得部１０４は、ユーザの状況情報を取得する。ユーザの状況情報は、日付、時刻、ユーザの位置、ユーザの行動などである。ユーザの位置は、サービス制御装置１００に搭載されたＧＰＳ（図示なし）により取得できる。本実施形態では、予め登録してある川崎市の自宅にユーザがいることが検知され、「位置＝自宅（川崎市）」がユーザの状況情報として取得されたものとする。

ステップＳ２では、サービス要求解析部１０２は、ユーザのサービス要求を解析し、機械可読な形式に変換する。

具体的には、サービス要求解析部１０２は、「きれいな海に行きたい」というテキストデータを公知の形態素解析技術により形態素列に変換する。その結果、「きれい＜形容動詞語幹＞＋な＜形容動詞活用語尾＞＋海＜名詞＞＋に＜助詞＞＋行き＜動詞（行く）＞＋たい＜助動詞＞」を得る。ここで、「＜名詞＞」など「＜＞」で囲まれた文字列は品詞を表し、「（行く）」など「（）」で囲まれた文字列は単語の基本形を表す。

サービス要求解析部１０２は、公知の固有表現抽出技術により、形態素解析で得られた名詞、固有名詞、未知語に対し意味のクラスを割り当てる。本実施形態では、固有表現抽出の結果として、「きれい＜形容動詞語幹＞＋な＜形容動詞活用語尾＞＋海＜名詞：地名クラス＞＋に＜助詞＞＋行き＜動詞（行く）＞＋たい＜助動詞＞」を得る。ここで、品詞にコロンで続く「地名クラス」が固有表現のクラスを表す。固有表現のクラスとしては「地名クラス」の他、「地名」「商品クラス」「商品名」「料理クラス」「料理名」などがある。なお、「地名」は「川崎市」などの具体的な地名を表すクラスであり、「地名クラス」は「海」「山」など一般的な地名を表すクラスである。「商品クラス」と「商品名」、「料理クラス」と「料理名」も同様の関係を表している。

サービス要求解析部１０２は、固有表現抽出結果に基づいてサービス要求を機械可読な形式に変換する。サービス要求の機械可読な形式のひな形として、ここでは「対象＝“名詞”、対象クラス＝“固有表現クラス”、アクション＝“動詞：基本形”、その他＝“自立語：基本形・語幹”」という形式を考える。ここで「＝」の左辺は属性名を示し、右辺の「“”」で囲まれた部分は属性値で、固有表現抽出結果から対応する文字列を抽出することを示す。このひな形により、本実施形態ではユーザのサービス要求が「対象＝海、対象クラス＝地名クラス、アクション＝行く、その他＝きれい」に変換される。なお、単文以外の複雑なサービス要求が入力された場合は、係り受け解析や照応解析などで対応できる。

ステップＳ３では、目的推定部１０７は、ユーザの要求に対応するユーザの目的を推定する。ここで、目的推定部１０７は、サービス要求解析部１０２で変換されたサービス要求を用いて、目的知識記憶部１０５から目的知識を検索し、サービス要求に対応するユーザの目的を推定する。

図４に、目的知識記憶部１０５に記憶された目的知識の例を示す。図中の「目的知識ＩＤ」は各目的知識を識別するためのユニークなＩＤ、「関連」は関連する他の目的知識の目的知識ＩＤ、「対象」は目的知識の対象を示す具体的な事物、「対象クラス」は目的知識の対象を示す一般的なクラス、「アクション」は目的知識が対応するアクション、「その他」は前述の属性以外の属性値、「ラベル」は目的知識をユーザに提示する際に用いるラベルを表している。「ラベル」属性において、その属性値が「＄地名＄」のように「＄＄」で囲まれた文字列は、ユーザに提示される際、サービス要求に含まれるクラスの具体的な文字列に変換される。本実施形態では、「ラベル」属性の属性値が、目的推定部１０７で推定されたユーザの目的を表している。

例えば、目的知識ＩＤが「００１」である目的知識は、任意の具体的な「地名」を対象として「行く」ことを示しており、具体的には「京都に行きたい」などのユーザの目的を表している。

また、目的知識ＩＤが「００３」である目的知識は、「イタリア料理」「蕎麦」などの「料理クラス」を対象として「食べる」ことを示している。目的知識ＩＤが「００１」である目的知識の「関連」が「００３」であることは、例えば、「京都に行きたい」というユーザ要求の本来の目的が「おいしいものを食べたい」である可能性があることを表している。

なお、本実施形態では、図４に示したもの以外にも目的知識が記憶されているものとする。

目的知識は、サービスの要件分析に基づいてシステム設計・開発者が開発してもよいが、インターネット上の大量のテキストを分析することで自動的・半自動的に生成するのでもよい。例えば、本実施形態では、インターネット上のブログにある日記や旅行記などから収集できる「花火を見に海に行ってきました」「子供を思いっきり遊ばせたくて海水浴にでかけました」などの記述を構文解析することで、「海に行きたい（ＩＤ００４）」という行為について「花火を見たい（ＩＤ００５）」「子供と遊びたい（ＩＤ００６）」などの目的があることを抽出し、さらにそれらの目的を関連づけることができる。

目的知識記憶部１０５は、公知のリレーショナルデータベース技術などで実現される。

目的知識の検索では、サービス要求解析部１０２によって変換されたサービス要求の属性名と属性値の組を検索条件とする。目的推定部１０７は、「対象」または「対象クラス」の属性値が一致し、かつ、「アクション」の属性値が一致する目的知識を検索する。本実施形態では、属性名「対象」の属性値が「海」、属性名「対象クラス」の属性値「地名クラス」、属性名「アクション」の属性値が「行く」であることから、図４の４０１と４０２の目的知識が抽出される。

さらに、目的推定部１０７は関連する目的知識も抽出する。本実施形態では、４０１および４０２の「関連」を参照し、目的知識４０３〜４０７も抽出する。

以上の処理により、目的推定部１０７は、目的知識４０１〜４０７の「ラベル」属性の属性値をユーザの目的として推定する。

ステップＳ４では、目的推定部１０７は、ステップＳ３で推定されたユーザの目的をランキングする。具体的には、ステップＳ１で取得したユーザのプロファイルおよび状況情報に適合する目的が上位にくるように目的知識をランキングする。このとき、目的推定部１０７は、選好知識記憶部１０６に記憶された選好知識を利用する。なお、ステップＳ３で推定されたユーザの目的が１つである場合は、本ステップの処理は省略できる。

図５に、選好知識記憶部１０６に記憶された選好知識の例を示す。「選好知識ＩＤ」は選好知識記憶部１０６が選好知識を識別するためのユニークなＩＤ、「目的知識ＩＤ」は選好知識に対応する目的知識のＩＤ、「選好条件」は選好知識を適用するか否かを判定する際に利用するユーザのプロファイルや状況情報に対する条件、「選好係数」は目的知識が選考条件に適合するユーザからどれだけ選ばれやすいかを表す指標である。

例えば、選好知識ＩＤが「００１」である場合、対応する目的知識ＩＤが「００２」である。この目的知識ＩＤ「００２」は、ユーザのプロファイルに「子の有無＝有」を含む場合、含まない場合と比べて１．６倍ユーザから選ばれやすいことを表している。

選好知識は、初期にはサービスの要件から設計・開発者が作成することができる。例えば旅行商品の場合、商品毎の想定ターゲット顧客を踏まえ、子供連れ向けの客室があるホテルであれば「子の有無＝有」の選好条件に対して大きな選好係数を与え、シニア向けのツアーであれば「年齢＞５０」の選好条件に対して大きな選好係数を与えるなどが考えられる。後述のように、選好知識はユーザの実際の利用に基づいて更新される。

選好知識記憶部１０６は、公知のリレーショナルデータベース技術などで実現される。

目的推定部１０７は、ステップＳ３で推定された複数の目的の目的知識ＩＤを手がかりとして、目的選考知識を検索する。本実施形態では、図５の５０１〜５０８が抽出される。

図６のフローチャートを利用して、ユーザの目的をランキングする処理の詳細を説明する。

ステップＳ６０１では、目的知識記憶部１０５から抽出した目的知識の目的知識ＩＤをｉｄ＿ａとして、各目的知識の選好度スコアを表す変数Ｓ［ｉｄ＿ａ］を定義し値を１．０に初期化する。

ステップＳ６０２では、選好知識記憶部１０６から抽出した選好知識をひとつ取り出す。取り出した選好知識の選好知識ＩＤの値を変数ｉｄ＿ｂに代入する。

ステップＳ６０３では、選好知識ＩＤ＝ｉｄ＿ｂである選好知識の目的知識ＩＤの値をｉｄ＿ｃに代入する。

ステップＳ６０４では、選好知識ＩＤ＝ｉｄ＿ｂである選好知識の選好条件の値を変数ｃｏｎｄに代入する。

ステップＳ６０５では、ユーザのプロファイルおよび状況情報を参照し、選好条件が真であるかを判定する。

ステップＳ６０５が真の場合は、選好知識ＩＤ＝ｉｄ＿ｂである選好知識の選好係数の値を変数ｆに代入し（ステップＳ６０６）、選好度スコアをＳ［ｉｄ＿ｃ］＝Ｓ［ｉｄ＿ｃ］×ｆとして更新する（ステップＳ６０７）。

ステップＳ６０８では、上記の処理を選好知識記憶部１０６から抽出した全ての選好知識に対して繰り返す。

ステップＳ６０９では、全ての選好知識を処理し終わったら変数Ｓ［ｉｄ＿ａ］を降順にソートする。

最後にステップＳ６１０では、変数Ｓ［ｉｄ＿ａ］の値と対応する目的知識ＩＤをソートした選好知識に対応する順に出力する。

例えば、目的知識４０１は選好知識５０１により選好度スコア＝１．４（１．０×１．４）となる。目的知識４０４は、選好知識５０２および５０４の選好条件とは合致しないが、選好知識５０３と合致するため選好度スコア＝０．１（１．０×０．１）となる。目的知識４０５は、選好知識５０５と合致するため選好度スコア＝１．２（１．０×１．２）となる。目的知識４０６は、選好知識５０７とは合致しないが、選好知識５０６と合致するため選好度スコア＝１．６（１．０×１．６）となる。目的知識４０７は、選好知識５０８とは合致せず選好度スコア＝１．０（初期値）となる。目的知識４０２および４０３は、図５には対応する選好知識がないため選好度スコア＝１．０（初期値）となる。

以上より、目的知識をランキングした結果としては、同スコアの場合を特に考慮しなければ、４０６、４０１、４０５、４０２、４０３、４０７、４０４の順となる。この結果を利用して、目的推定部１０７は、推定したユーザの目的をランキングすることができる。

図３のフローチャートに戻って説明を続ける。ステップＳ５では、目的推定部１０７は、ステップＳ４でランキングされた複数の目的をユーザに提示し、ユーザによる最適な目的の選択結果を取得する。図７は、ディスプレイ２０８に表示された目的の一例を示す図である。ここで、各目的の表示には、図４の「ラベル」属性を用いる。

本実施形態では、目的知識記憶部１０５から抽出された７個の目的知識に対応する目的全てを表示しているが、ランキングの上位の目的知識のみ、あるいは選好度スコアが１以上の目的知識のみをユーザに提示するようにしてもよい。

図７の例では、ユーザが操作部２０４を介して７０１を最適な目的として選択したものとする。目的推定部１０７は、選択された７０１に対応する目的知識４０６と、ステップＳ１で取得したプロファイルおよび状況情報を、サービス制御条件生成部１０９および選好知識記憶部１０６に送る。

ステップＳ６では、サービス制御条件生成部１０９は、ステップＳ２で変換されたサービス要求およびステップＳ５でユーザが選択した目的に基づいて、検索サービス１１３を操作するための条件であるサービス制御条件を生成する。

図８に、サービス制御知識記憶部１０８に記憶されたサービス制御知識の例を示す。サービス制御知識記憶部１０８は、公知のリレーショナルデータベース技術などによって実現できる。なお、目的知識記憶部１０５、選好知識記憶部１０６、サービス制御知識記憶部１０８は、同じリレーショナルデータベース管理システム上で動作していてもよい。

サービス制御知識は、操作対象となるサービス毎に予め作成しておく。例えば、図８のサービス制御条件８０１であれば、目的知識ＩＤ＝００９（「リゾートでのんびりしたい」）に対応する旅行商品検索を検索するのに適していて、かつ、旅行商品検索サービスが受理可能な検索条件（属性の条件やキーワードの条件など）を想定し、設計・開発者、または、旅行商品検索サービスのサービス事業者が作成することができる。

この例では、ステップＳ５でユーザが選択した目的の目的知識ＩＤ「００９」を手がかりとして、図８のサービス制御知識８０１が抽出されたものとする。

サービス制御条件生成部１０９は、抽出されたサービス制御知識８０１の「制御条件」属性の属性値に基づき、機械可読な形式に変換されたサービス要求「対象＝海、対象クラス＝地名クラス、アクション＝行く、その他＝きれい」と、プロファイル「年齢＝２５歳、職業＝会社員、性別＝男、パートナーの有無＝有、子の有無＝無、子の年齢＝ＮＡ」と、状況情報「位置＝自宅」に従って、サービス制御条件を生成する。

「制御条件」属性のうち、「＜ｉｆ Ｘ＝ａ ｔｈｅｎ ｂ＞」という表現は、サービス要求、プロフィル情報、状況情報のうち何れかの属性「Ｘ」の値が「ａ」であれば制御条件に「ｂ」を加える、という意味である。「ＯＲ」は併記された複数の属性への条件のうち何れかが成立すれば真であることを示す。また、「＄その他＄」という表現は、サービス要求、プロファイル、状況情報において該当する属性（ここでは「その他」）の値をサービス制御条件に加えるという意味である。

本実施形態では、サービス制御条件生成部１０９は、「施設＝リゾートホテル、タイプ＝カップル向け、設備＝プール＋プライベートビーチ＋スパ＋マッサージ、キーワード＝きれい＋のんびり」というサービス制御条件を生成する。

なお、本実施形態では、ユーザのプロファイルおよび状況情報も用いてサービス制御条件を生成したが、これらが取得できなかった場合は、サービス要求のみを用いてサービス制御条件を生成する。

サービス制御部１１０は、生成されたサービス制御条件を検索サービス１１３に送る。これにより、検索サービス１１３がこのサービス制御条件に従って操作される。本実施形態における検索サービス１１３は、例えばインターネット上で利用されている公知のサービスである。なお、サービス制御部１１０は、サービス制御条件をサービス出力部１１１にも送る。

ステップＳ７では、サービス出力部１１１は、サービス制御条件に従って操作された検索サービス１１３から出力を受け取り、図９のようにユーザに提示する。

本実施形態では、操作対象のサービスとして旅行商品の検索サービス１１３を想定している。そのため、検索サービス１１３からの出力は、サービス制御条件に合致する旅行商品のリストになる。なお、図９には検索結果の見出しがリストアップされているが、サービス制御条件は必ずしも見出し部分と照合されるとは限らない。

ステップＳ８では、結果選択部１１２は、サービス出力部１１１が提示した検索サービス１１３の出力からユーザが選択した結果を取得する。ユーザが適切な結果がないと指示した場合、結果選択部１１２は、サービス制御条件生成部１０９に対しサービス制御条件の修正を指示する。サービス制御条件の修正は、生成済みのサービス制御条件をユーザに提示して修正させてもよいし、予め定められた基準でサービス制御条件を緩和してもよい。サービス制御条件を緩和する基準としては、例えば、ユーザ指定でないキーワード（例えばサービス制御条件８０１であれば「のんびり」）を削除することなどが考えられる。

ここでは、図９の９０１が選択されたものとする。選択結果を受け取ったサービス制御部１１０は、検索サービス１１３に選択結果を送ってユーザを検索サービス１１３に誘導し、以降はユーザが検索サービス１１３を直接利用できるようにする。

また、選択結果を受け取った選好知識記憶部１０６は、目的推定部１０７から受け取った目的知識が、ステップＳ１で取得したユーザのプロファイルおよび状況情報のもとでユーザに適切なサービスを提供できたものとして、この目的知識の選好係数を修正する。本実施形態の場合、目的知識４０６に対応する選好知識５０６および５０７のうち、選好条件がユーザのプロファイルおよび状況情報に合致する選好知識５０６の選好係数が、１より大きい定数を乗じるなどして増大するよう修正される。

（効果）
本実施形態のサービス制御装置は、要求とこの要求の背景にある目的とを関連付けた目的知識を利用して、ユーザの要求に対応するユーザの目的を推定する。これにより、ユーザの本来の目的を考慮してサービスを操作することができる。

先ほどの例では、初期のユーザのサービス要求は「きれいな海に行きたい」であったが、本実施形態のサービス制御装置は、ユーザの本来の目的が「パートナーとのんびりしたい」であることを推定し、推定された目的に基づいてサービス制御条件を生成した。このため、最終的にユーザは「きれいな海」よりも「ゴージャスなプールのあるリゾートホテル」が自身の目的に適うと気づき、従来、初期の要求だけからは得ることのできなかった結果にたどり着くことができた。

また、本実施形態のサービス制御装置は、プロファイルと目的知識および状況情報と目的知識を関連付けた選好知識を利用して、ユーザの要求に対応するユーザの目的を推定する。このように、サービス要求だけでなく、ユーザのプロファイルおよび状況情報を考慮してユーザの目的を推定することにより、ユーザの本来の目的に近い目的を推定することができる。

さらに、本実施形態のサービス制御装置は、検索サービス１１３からの出力に対するユーザの選択結果に応じて、選好知識記憶部１０６に記憶された選好知識を更新する。これにより、ユーザが検索サービス１１３を再度利用する場合において、目的推定部１０７がユーザの本来の目的に近い目的を推定することができる。

（変形例１）
目的推定部１０７は、図１０に示すように、目的知識間の関係をユーザに提示してもよい。この図では、ユーザによって入力されたサービス要求から直接抽出できる目的に「☆」マークを付与し、選好度スコアの高い目的は枠線を太く表示している。また、図７とは異なり、目的知識の「関連」属性を複数段階辿って抽出された目的知識が示す目的も枠線を点線にして表示している。多くの目的知識が目的知識記憶部１０５に記憶されている場合は、ユーザは画面を上下左右に移動させながら関連する目的知識をさらに辿ってもよい。

（変形例２）
上述の実施形態では、検索サービス１１３が外部の端末に搭載されているが、これに限定されるものではない。例えば、検索サービス１１３が、サービス制御装置１００に搭載されてもよい。

また、上述の実施形態では、サービス制御装置１００が１台の端末で実現されているが、これに限定されるものではない。サービス制御装置１００を複数台の端末で構成し、上述した各部（サービス要求取得部１０１、サービス要求解析部１０２、プロファイル取得部１０３、状況情報取得部１０４、目的知識記憶部１０５、選好知識記憶部１０６、目的推定部１０７、サービス制御知識記憶部１０８、サービス制御条件生成部１０９、サービス制御部１１０、サービス出力部１１１、結果選択部１１２）が何れかの端末に含まれるようにしてもよい。この場合、端末間の情報伝達は、有線あるいは無線による通信で行うことができる。

（変形例３）
上述の実施形態では、目的推定部１０７で推定された複数の目的をランキングする際にユーザのプロファイルおよび状況情報を利用したが、推定結果をランキングせずにユーザに提示する場合は、目的推定部１０７は、ユーザのプロファイルおよび状況情報を用いずに動作できる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

以上説明した本実施形態における一部機能もしくは全ての機能は、ソフトウェア処理により実現可能である。

１００ サービス制御装置
１０１ サービス要求取得部
１０２ サービス要求解析部
１０３ プロファイル取得部
１０４ 状況情報取得部
１０５ 目的知識記憶部
１０６ 選好知識記憶部
１０７ 目的推定部
１０８ サービス制御知識記憶部
１０９ サービス制御条件生成部
１１０ サービス制御部
１１１ サービス出力部
１１２ 結果選択部
１１３ 検索サービス
２０１ 制御部
２０２ 記憶部
２０３ 外部記憶部
２０４ 操作部
２０５ 通信部
２０６ マイク
２０７ スピーカ
２０８ ディスプレイ
２０９ バス
４０１〜４０７ 目的知識
５０１〜５０８ 選好知識
７０１ ユーザの目的
８０１ サービス制御知識
９０１ ユーザが選択した検索サービスの出力

Claims (10)

1. ユーザの要求を取得する要求取得手段と、
   要求と前記要求の背景にある目的とを含む目的知識を他の目的知識と関連付けて記憶する目的知識記憶手段と、
   前記目的知識及び前記他の目的知識を用いて、前記ユーザの要求に対応するユーザの目的を検索する検索手段と、
   を備える検索装置。
2. 前記ユーザの目的を複数提示する提示手段と、
   を更に備える請求項１記載の検索装置。
3. 前記ユーザの要求に応じたサービスを操作するための条件であるサービス制御条件の生成方法を、前記目的毎に記述したサービス制御知識を記憶する制御知識記憶手段と、
   前記サービス制御知識を用いて、前記ユーザの要求と前記ユーザの目的とに対応したサービス制御条件を生成する制御条件生成手段と、
   を備える請求項１記載の検索装置。
4. 前記制御条件生成手段で生成されたサービス制御条件を用いて、前記サービスを操作するサービス制御手段と、
   を更に備える請求項３記載の検索装置。
5. 前記ユーザのプロファイルを取得するプロファイル取得手段と、
   前記ユーザの状況情報を取得する状況情報取得手段と、
   プロファイルと前記目的知識、および状況情報と前記目的知識を関連付けた選好知識を記憶する選好知識記憶手段とを更に備え、
   前記検索手段が、前記ユーザのプロファイルと、前記ユーザの状況情報と、前記選好知識とを更に用いて、前記ユーザの目的を検索する請求項１記載の検索装置。
6. 前記プロファイルが、ユーザの年齢、職業、性別、家族構成の何れかである請求項５記載の検索装置。
7. 前記状況情報が、日付、時刻、ユーザの位置、ユーザの行動の何れかである請求項５記載の検索装置。
8. 前記サービス制御手段によって操作された前記サービスからの出力を前記ユーザに提示するサービス提示手段と、
   前記サービスからの出力に対する前記ユーザの選択結果を取得する結果選択手段と、
   前記ユーザのプロファイルを取得するプロファイル取得手段と、
   前記ユーザの状況情報を取得する状況情報取得手段と、
   プロファイルと前記目的知識、および状況情報と前記目的知識を関連付けた選好知識を記憶する選好知識記憶手段と、
   を更に備え、
   前記選好知識記憶手段に記憶された前記選好知識が、前記ユーザの選択結果に応じて更新される請求項４記載の検索装置。
9. ユーザの要求を取得するステップと、
   要求と前記要求の背景にある目的とを含む目的知識及び前記目的知識と関連付けられた他の目的知識を用いて、前記ユーザの要求に対応するユーザの目的を検索するステップと、
   を備える、コンピュータが実行する検索方法。
10. 検索装置に、
    ユーザの要求を取得する機能と、
    要求と前記要求の背景にある目的とを含む目的知識及び前記目的知識と関連付けられた他の目的知識を用いて、前記ユーザの要求に対応するユーザの目的を検索する機能と、
    を実現させるための検索プログラム。

Images