機能提示システム、端末装置、サーバ装置、プログラム及び機能提示方法
【課題】入力文字列を基に複数機能を提示して、ユーザによる機能選択を支援する。
【解決手段】サーバ装置１０は、端末装置２０の入力情報を取得し（ＳＡ１〜ＳＡ３）、登録文字列の意味に基づく分類を示す識別子が記述された音声認識辞書として機能する辞書ファイルを参照して、入力情報を認識し、入力文字列と、入力文字列に含まれる登録文字列の分類を示す第１識別子を特定する（ＳＡ５）。サーバ装置１０は、特定した入力文字列と第１識別子とを端末装置２０に送信する（ＳＡ６）。端末装置２０は、第１識別子と、提示対象となる機能が属するカテゴリとの関係を記述した機能選択ファイルを参照して、第１識別子に応じた機能が属するカテゴリを選択する（ＳＡ７〜ＳＡ９）、端末装置２０は、選択したカテゴリに属する機能を所定の提示方法で（例えば、他の機能よりも優先して）複数提示する（ＳＡ１０）。
【解決手段】サーバ装置１０は、端末装置２０の入力情報を取得し（ＳＡ１〜ＳＡ３）、登録文字列の意味に基づく分類を示す識別子が記述された音声認識辞書として機能する辞書ファイルを参照して、入力情報を認識し、入力文字列と、入力文字列に含まれる登録文字列の分類を示す第１識別子を特定する（ＳＡ５）。サーバ装置１０は、特定した入力文字列と第１識別子とを端末装置２０に送信する（ＳＡ６）。端末装置２０は、第１識別子と、提示対象となる機能が属するカテゴリとの関係を記述した機能選択ファイルを参照して、第１識別子に応じた機能が属するカテゴリを選択する（ＳＡ７〜ＳＡ９）、端末装置２０は、選択したカテゴリに属する機能を所定の提示方法で（例えば、他の機能よりも優先して）複数提示する（ＳＡ１０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザによる機能選択を支援する技術に関する。
【背景技術】
【０００２】
ユーザから受け付けた入力文字列を基に、ユーザが利用を希望する機能を推定する技術がある。特許文献１は、入力文字列を解析して金額や電話番号等の文字列の種別を判断し、判断した種別に応じたアプリケーションプログラムを自動で起動することを開示している。特許文献２は、検索入力文を構文解析して、複数の検索エンジンの中から、特定の分野に特化した望ましい検索エンジンを選択し、選択した検索エンジンを用いて情報検索を行うことを開示している。
【０００３】
特許文献３は、文字列とその文字列の属性との対応関係を記述した複数のデータテーブルを参照して、入力文字列の属性を決定し、決定した文字列の属性と検索方法との対応関係を記述したデータテーブルを参照して、入力文字列の属性に対応した最適な検索方法を決定することを開示している。特許文献３に記載された発明は、入力文字列に含まれる各文字列の属性を決定する際、文字列属性確定順位に従って一の文字列に一の属性を順次決定し、確定済みの文字列の属性とは重複しないように各文字列の属性を決定するものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−１５４０６９号公報
【特許文献２】特開２００３−１３２０６０号公報
【特許文献３】特開２００９−２６６２０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、特許文献１から特許文献３に記載された発明は、いずれも、ユーザにとって最適な機能を択一的に推定することにより、ユーザに強いられる機能選択に関する負担を減らすことができるものである。しかしながら、スマートフォンや携帯電話端末等の、多くの機能を実現可能な端末装置では、ユーザの希望する機能を１つに絞り込んで推定することが難しい場合があると考えられる。例えば、地名である「横浜」という文字列が入力文字列に含まれる場合、ユーザが現在位置から横浜までの電車での行き方を知りたいときには、電車の乗換案内を提供する機能がユーザにとって最適な機能であるし、ユーザが横浜にある飲食店に関する情報を知りたいときには、グルメ情報を提供するＷｅｂサイトを表示するためのブラウザ機能がユーザにとって最適な機能であるし、ユーザが横浜周辺の地理を知りたいときには、地図機能がユーザにとって最適な機能であると考えられる。また、グルメ情報を提供するＷｅｂサイトに様々なものがあるように、ユーザの利用目的を達成することができる機能が複数存在する場合がある。この場合、ユーザが利用したい機能はその時時で異なることも考えられる。特許文献１から特許文献３に記載された発明は、ユーザによる利用の可能性を考慮して積極的に複数の機能を提示する、という技術思想の下でなされたものでない。
そこで、本発明は、入力文字列を基に複数機能を提示して、ユーザによる機能選択を支援することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決するため、本発明の機能提示システムは、入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する第１記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを備えることを特徴とする。
【０００７】
本発明において、前記第１記憶部は、前記入力情報の認識に用いられ、登録文字列に前記識別子を割り当てた辞書ファイルを記憶し、前記特定部は、前記辞書ファイルを参照して、前記入力情報を認識し、認識した入力文字列と、当該入力文字列に対応する登録文字列の前記識別子とを特定するようにしてもよい。
本発明において、前記第１記憶部は、少なくとも一部の登録文字列について複数の前記識別子を記憶し、前記特定部は、前記入力文字列に含まれる一の登録文字列の前記識別子が前記第１記憶部に複数記憶されている場合、当該複数の前記識別子を特定するようにしてもよい。
【０００８】
本発明において、前記識別子は、前記登録文字列の意味に基づく分類を示し、前記第２記憶部は、前記識別子と、提示対象となる前記機能の種類とを対応付けて記憶し、前記提示部は、前記特定部が特定した識別子に対応付けて前記第２記憶部に記憶された種類の機能を、前記提示方法で複数提示するようにしてもよい。
また、本発明において、前記識別子は、前記登録文字列に対して定められた前記機能の種類を前記分類として示し、前記第１記憶部は、前記機能の種類に対して与えられた重み付けを前記識別子に対応付けて記憶し、前記特定部は、前記第１記憶部を参照して、前記識別子と、当該識別子が示す前記機能の種類に対する重み付けとを特定し、前記提示部は、前記特定部が特定した識別子と重み付けとに応じて、前記提示方法で複数機能を提示するようにしてもよい。
また、本発明において、前記識別子として、前記登録文字列の意味に基づく分類を示す第１識別子と、前記登録文字列の分類として前記登録文字列に対して定められた前記機能の種類を示す第２識別子とがあり、前記第１記憶部は、前記登録文字列毎に、前記第１識別子、前記第２識別子、及び当該第２識別子が示す前記機能の種類に対して与えられた重み付けを記憶し、前記提示部は、前記第２記憶部を参照して、前記特定部が特定した前記第１識別子、又は前記特定部が特定した第２識別子と重み付けとに応じて、前記提示方法で複数機能を提示するようにしてもよい。
【０００９】
本発明において、前記提示部は、前記入力文字列に対応する登録文字列の表記方法に応じて、前記提示方法を異ならせるようにしてもよい。
【００１０】
本発明において、前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第１記憶部の記憶内容を更新する第１更新部を備えるようにしてもよい。
また、本発明において、前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第２記憶部の記憶内容を更新する第２更新部を備えるようにしてもよい。
【００１１】
本発明において、前記提示部が提示した前記機能のうち決められた条件を満たす機能を実現する機能実現部を備え、前記提示部は、前記特定部が特定した識別子に応じて提示対象となる複数機能と、前記機能実現部が機能を実現した結果とを提示するようにしてもよい。
【００１２】
また、本発明の機能提示システムは、サーバ装置と端末装置とを備える機能提示システムであって、前記サーバ装置は、前記端末装置と通信する第１通信部と、前記端末装置の入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する第１記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、前記特定部が特定した識別子を前記端末装置に送信するよう、前記第１通信部を制御する送信制御部と、を有し、前記端末装置は、前記サーバ装置と通信する第２通信部と、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、前記第２通信部により前記サーバ装置から受信した前記識別子を取得する識別子取得部と、前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを有することを特徴とする。
【００１３】
本発明の端末装置は、サーバ装置と通信する通信部と、自端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子が前記サーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得部と、前記識別子と、提示対象となる機能との関係を記憶する記憶部と、前記記憶部を参照して、前記識別子取得部が取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを備えることを特徴とする。
【００１４】
本発明のサーバ装置は、自サーバ装置から受信した識別子に応じた機能を複数提示する端末装置と通信する通信部と、前記端末装置の入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記記憶部を参照して特定する特定部と、前記特定部が特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御部とを備えることを特徴とする。
【００１５】
本発明のプログラムは、通信部を有する端末装置のコンピュータに、前記端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子がサーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得ステップと、前記識別子と、提示対象となる機能との関係を記憶する記憶部を参照して、前記識別子取得ステップで取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップとを実行させるためのものである。
【００１６】
本発明のプログラムは、通信部を有するサーバ装置のコンピュータに、当該サーバ装置から受信した識別子に応じた機能を複数提示する端末装置の入力情報を取得する情報取得ステップと、登録文字列の分類を示す識別子を記憶する記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、前記特定ステップで特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御ステップとを実行させるためのものである。
【００１７】
本発明の機能提示方法は、入力情報を取得する情報取得ステップと、登録文字列の分類を示す識別子を記憶する第１記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部を参照して、前記特定ステップで特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップとを有することを特徴とする。
【発明の効果】
【００１８】
本発明によれば、入力文字列を基に複数機能を提示して、ユーザによる機能選択を支援することができる。
【図面の簡単な説明】
【００１９】
【図１】機能提示システムの全体構成を示す図。
【図２】サーバ装置の構成を示すブロック図。
【図３】第１実施形態に係る辞書ファイルの構成を示す図。
【図４】端末装置の構成を示すブロック図。
【図５】同実施形態に係る機能選択ファイルの構成を示す図。
【図６】機能管理テーブルの構成を示す図。
【図７】同実施形態に係るサーバ装置の制御部の機能的構成を示すブロック図。
【図８】同実施形態に係る端末装置の制御部の機能的構成を示すブロック図。
【図９】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図１０】機能提示画面を示す図。
【図１１】機能提示画面を示す図。
【図１２】第２実施形態に係る辞書ファイルの構成を示す図。
【図１３】同実施形態に係る機能選択ファイルの構成を示す図。
【図１４】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図１５】第３実施形態に係る辞書ファイルの構成を示す図。
【図１６】同実施形態に係る機能選択ファイルの構成を示す図。
【図１７】重み付け更新テーブルの構成を示す図。
【図１８】第４実施形態に係るサーバ装置の制御部の機能的構成を示す機能ブロック図。
【図１９】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２０】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２１】第５実施形態に係る端末装置の制御部の機能的構成を示す機能ブロック図。
【図２２】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２３】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２４】変形例１に係る端末装置の動作を示すフローチャート。
【図２５】機能提示システムの機能的構成を示すブロック図。
【発明を実施するための形態】
【００２０】
以下、図面を参照しつつ本発明の実施形態を説明する。
［第１実施形態］
図１は、機能提示システム１の全体構成を示す図である。
機能提示システム１は、端末装置２０で実現可能な機能の中から、端末装置２０のユーザが利用を希望する機能を推定して提示するサービス（以下、「機能提示サービス」という。）を提供するためのシステムである。図１に示すように、機能提示システム１は、サーバ装置１０と、端末装置２０とを備えている。サーバ装置１０と端末装置２０とは、ネットワークＮＷ経由で互いに通信可能に接続されている。ネットワークＮＷは、ここでは、移動体通信網、ゲートウェイ及びインターネットを含む通信網である。
【００２１】
端末装置２０は、ここではスマートフォンであり、音声（端末装置２０のユーザが発する声を想定する。）を検出し、検出した音声を基に機能提示サービスで推定された機能を提示する。サーバ装置１０は、端末装置２０で検出された音声を認識する音声認識サーバとして機能する一方で、音声認識の結果に基づいて機能提示サービスの提供を支援する。
なお、端末装置２０は、スマートフォンに限らず、例えば携帯電話端末やパーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）等の通信機能を有する端末装置であってもよい。また、図１には、端末装置２０を１つだけ図示しているが、実際にはより多数の端末装置２０が機能提示システム１に含まれる。
【００２２】
図２は、サーバ装置１０の構成を示すブロック図である。図２に示すように、サーバ装置１０は、制御部１１と、通信部１２と、記憶部１３とを備える。
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）を備えるマイクロコンピュータである。ＣＰＵは、ＲＯＭや記憶部１３に記憶されたプログラムをＲＡＭに読み出して実行することにより、サーバ装置１０の各部を制御する。通信部１２は、ネットワークＮＷに接続するためのインタフェースである（第１通信部）。記憶部１３は、例えばハードディスク装置を備える、辞書ファイル１３１及び制御部１１により実行される各種プログラムを含むデータを記憶する（第１記憶部）。辞書ファイル１３１は、音声認識に用いられる音声認識辞書であるとともに、以下に説明する構成を有する辞書ファイルである。
【００２３】
図３は、辞書ファイル１３１の構成を示す図である。辞書ファイル１３１では、辞書登録された登録文字列に、その登録文字列の意味に基づく分類を示す識別子が対応付けてられている。
図３に示すように、辞書ファイル１３１は、「登録文字列」と「第１識別子」との各フィールドに記述された情報を対応付けたデータテーブルを含む。「登録文字列」のフィールドには、辞書ファイル１３１に登録された文字列が記述されている。登録文字列は、典型的には単語であるが、複合語等の任意の文字列（例えば、情報検索に用いられる検索語）を含みうる。また、登録文字列は、漢字、平仮名、片仮名、アルファベット等の、どのような文字で構成されてもよい。「第１識別子」のフィールドには、登録文字列の意味に基づく分類を示す識別子が記述される。第１識別子は、登録文字列の意味（又は概念）に応じて予め決められた分類に従って、各登録文字列に割り当てられている。例えば、登録文字列「表参道」の第１識別子は「地名」であり、登録文字列「会議」の第１識別子は「行事」である。
また、辞書ファイル１３１では、一の登録文字列に複数の第１識別子が割り当てられることもある。登録文字列「品川」の第１識別子は、「地名，人名」（地名及び人名）である。これは「品川」という文字列が、地名としても解釈しうるし、人名（詳しくは、人の姓）しても解釈しうることによるものである。辞書ファイル１３１には、少なくとも一部の登録文字列について、複数の第１識別子が記述されている。
なお、図３に示す登録文字列及び第１識別子は一例であり、実際には、より多数の組み合わせが辞書ファイル１３１に記述されている。例えば、「人名」を更に細分化して、「芸能人名」や「作家名」、「スポーツ選手名」等の第１識別子が用いられてもよい。また、辞書ファイル１３１に辞書登録されたすべての登録文字列に、第１識別子が割り当てられているとは限らない。
【００２４】
図４は、端末装置２０の構成を示すブロック図である。図４に示すように、端末装置２０は、制御部２１と、音声入出力部２２と、無線通信部２３と、ＵＩ（User Interface）部２４と、記憶部２５とを備える。
制御部２１は、ＣＰＵ、ＲＯＭ、及びＲＡＭを備えるマイクロコンピュータである。ＣＰＵは、ＲＯＭや記憶部２５に記憶されたプログラムをＲＡＭに読み出して実行することにより、端末装置２０の各部を制御する。音声入出力部２２は、受話音声等を収音するマイクロホンと送話音声を放音するスピーカとを備え、音声の入出力に関する機能を実現する。音声入出力部２２は、マイクロホンによって端末装置２０のユーザが発した音声を検出し、音声の検出結果を制御部２１に出力する。無線通信部２３は、無線通信回路やアンテナを備え、ネットワークＮＷに無線通信により接続するためのインタフェースである（第２通信部）。ＵＩ部２４は、画像を表示する表示面と、表示面に重ねられたタッチパネルとを備え、ＧＵＩ（Graphical User Interface）を提供するものである。すなわち、ＵＩ部２４は、タッチパネルによりユーザからの操作を受け付ける操作部と、表示面に表示する画像により情報を報知する表示部としての双方の機能を実現する。
なお、端末装置２０において、操作部と表示部とがそれぞれ独立したハードウェアで実現されてもよい。
【００２５】
記憶部２５は、例えばＥＥＰＲＯＭ（Electronically Erasable and Programmable ROM）を備え、機能選択ファイル２５１、機能管理テーブル２５２及び各種のアプリケーションソフトウェアを含むデータを記憶する（第２記憶部）。制御部２１は、例えば、記憶部２５が記憶するアプリケーションソフトウェアを実行することにより、端末装置２０における機能を実現する。記憶部２５が記憶するアプリケーションソフトウェアは、例えば、メーラやＷｅｂブラウザ、地図を表示するための地図アプリ、動画ファイルを再生するための動画アプリ等を含むが、どのようなアプリケーションソフトウェアを含んでいてもよい。また、これらのアプリケーションソフトウェアは、端末装置２０にプリインストールされたものや、ユーザによって端末装置２０にインストールされたものを含む。
なお、アプリケーションソフトウェアには、そのアプリケーションソフトウェアの実行をユーザが端末装置２０に指示する際に、ユーザが指定するアイコン画像を表示するためのアルゴリズムが記述されている。
【００２６】
端末装置２０で実現可能な機能は、端末装置２０が必要な情報処理を実行することにより実現され、機能毎に少なくとも情報処理の内容の一部が異なる。例えば、Ｗｅｂブラウザの実行により実現される機能であっても、アクセス先のＵＲＬ（Uniform Resource Locator）が異なれば、それぞれ異なる機能として区別される。
なお、端末装置２０で各機能の実現に必要な情報（アクセス先のＵＲＬ等）は、記憶部２５に記憶されている。制御部２１はその情報を用いた情報処理を実行して、各機能を実現する。
【００２７】
図５は、機能選択ファイル２５１の構成を示す図である。機能選択ファイル２５１は、第１識別子と、提示対象となる機能との関係を記憶するデータである。
図５に示すように、機能選択ファイル２５１は、「第１識別子」と、「カテゴリ」と、「カテゴリ優先度」との各フィールドに記述された情報を対応付けたデータテーブルである。「第１識別子」のフィールドには、辞書ファイル１３１に記述されたものと共通する第１識別子が、１又は複数の組み合わせで記述されている。「カテゴリ」のフィールドには、端末装置２０で実現可能な機能の種類として、機能が属するカテゴリが記述されている。「カテゴリ優先度」のフィールドには、カテゴリに対する優先度が記述されている。カテゴリ優先度は、詳しくは後述するが、機能提示サービスの提供において参照される優先度である。カテゴリ優先度は、ここでは「０．０」以上「１．０」以下の値であり、その値が大きいほど優先度が高いことを示す。
【００２８】
機能選択ファイル２５１には、例えば、第１識別子「地名＋食品」（地名及び食品）に対応付けて、カテゴリ「グルメ」及びカテゴリ優先度「０．６」と、カテゴリ「買い物」及びカテゴリ優先度「０．４」とが記述されている。このように、機能選択ファイル２５１では、複数の第１識別子の組み合わせに対応してカテゴリ及びカテゴリ優先度が記述されていることがある。また、機能選択ファイル２５１には、第１識別子「地名」に対応付けて、カテゴリ「地図」及びカテゴリ優先度「０．８」と、カテゴリ「グルメ」及びカテゴリ優先度「０．２」とが記述されている。機能選択ファイル２５１では、第１識別子が示す登録文字列の意味と関連が深いカテゴリが当該弟１識別子に対応付けられ、例えば、その関連が深いほどカテゴリ優先度が高い。
また、複数の第１識別子の組み合わせは、「地名＋地名」のように、同一の第１識別子を複数含んでいてもよい。第１識別子「地名＋地名」には、カテゴリ「乗換案内」が対応付けられている。これは入力文字列に地名を意味する登録文字列が２つ含まれているということは、例えば、ユーザが電車での乗換を調べるために、出発地点と到着地点とを指定した可能性が考えられることによるものである。
なお、図５に示す第１識別子、カテゴリ及びカテゴリ優先度は一例であり、実際には、より多数の組み合わせが機能選択ファイル２５１に記述されている。ただし、機能選択ファイル２５１は、一の第１識別子の組み合わせについて、カテゴリ優先度の総和が「１．０」となるように構成されている。また、どのカテゴリにどの機能が属するかについては、機能提示システム１の設計段階等で決められる。
以上の構成を有する機能選択ファイル２５１は、詳しくは後述するが、所定の提示方法で提示する機能を選択する際に、端末装置２０により参照されるデータである。
【００２９】
図６は、機能管理テーブル２５２の構成を示す図である。機能管理テーブル２５２は、端末装置２０が実現可能な機能と、当該機能が属するカテゴリとの対応関係が記述されたデータテーブルである。
図６に示すように、機能管理テーブル２５２では、「カテゴリ」と、「機能」と、「機能優先度」との各フィールドに記述された情報が対応付けられている。「カテゴリ」のフィールドには、機能選択ファイル２５１に記述されたものと共通する情報が記述されている。「機能」のフィールドには、端末装置２０で実現可能な機能を識別する情報が記述されている。例えば、「機能」のフィールドに「サイト」と記述された機能は、Ｗｅｂブラウザの実行により実現される。「機能優先度」のフィールドには、機能に対する優先度が記述されている。機能優先度は、詳しくは後述するが、機能提示サービスにおける機能の提示の際に参照される優先度である。機能優先度は、ここではカテゴリ毎に独立して各機能に割り当てられた優先順位であり、その値が小さいほど優先度が高いことを意味する。機能優先度が設定されていない機能（図６で「−」（ハイフン）で示した機能）は、端末装置２０で実現可能であるものの、機能提示サービスでは提示の対象とならないものとする。
以上の機能管理テーブル２５２の機能優先度は、ユーザ設定等に応じて端末装置２０により更新されてもよい。また、機能管理テーブル２５２において全ての機能に機能優先度が設定されていてもよい。
続いて、機能提示システム１の機能的構成を説明する。
【００３０】
図７は、サーバ装置１０の制御部１１の機能的構成を示す機能ブロック図である。図７に示すように、制御部１１は、プログラムを実行することにより、情報取得部１１１と、特定部１１２と、送信制御部１１３とに相当する機能を実現する。
情報取得部１１１は、通信部１２の通信により、端末装置２０の入力情報を取得する。入力情報は、例えば端末装置２０で検出された音声（例えば、音声波形）を示す音声情報である。
特定部１１２は、辞書ファイル１３１を参照して、情報取得部１１１が取得した入力情報が示す入力文字列と、当該入力文字列に対応する登録文字列の第１識別子とを特定する。入力情報が音声情報である場合、特定部１１２は、辞書ファイル１３１を参照して、音声情報を認識し、認識した入力文字列とこの入力文字列に対応する登録文字列の第１識別子とを特定する。特定部１１２は、入力文字列に含まれる登録文字列に対応付けられた１又は複数の第１識別子を、登録文字列毎に辞書ファイル１３１からすべて特定する。入力文字列は、ここではテキストコードで表される。
送信制御部１１３は、入力文字列と、入力文字列に対応する登録文字列について特定部１１２が特定した第１識別子との組を端末装置２０に送信するよう、通信部１２を制御する。
【００３１】
図８は、端末装置２０の制御部２１の機能的構成を示す機能ブロック図である。図８に示すように、制御部２１は、プログラムを実行することにより、識別子取得部２１１と、提示部２１２と、機能実現部２１３とに相当する機能を実現する。
識別子取得部２１１は、送信制御部１１３の制御によりサーバ装置１０から送信され無線通信部２３により受信された入力文字列と、入力文字列に対応する登録文字列の第１識別子との組を取得して、ここから第１識別子を取得する。
提示部２１２は、機能選択ファイル２５１及び機能管理テーブル２５２を参照して、識別子取得部２１１が取得した第１識別子に応じて提示対象となる機能を、所定の提示方法で複数提示する。例えば、提示部２１２は、識別子取得部２１１が取得した第１識別子に応じて提示対象となる機能を、他の機能よりも優先させてＵＩ部２４への表示により提示する。
なお、識別子取得部２１１が取得した第１識別子は、特定部１１２が特定した第１識別子と同一である。
【００３２】
機能実現部２１３は、提示部２１２が提示する機能のうち決められた条件を満たす機能を実現する。例えば、機能実現部２１３は、提示部２１２が提示する機能のうちのいずれか１つの機能を、ユーザからの当該機能の実現指示を受け付けることなく実現する。提示部２１２は、提示対象となる複数機能と、機能実現部２１３が機能を実現した結果とを提示する。
機能実現部２１３は、端末装置２０における機能の実現に関する制御を司るものであり、例えば、ＵＩ部２４の操作や音声入力によって機能の実現がユーザに指示された場合に、当該機能を実現する。また、例えばユーザによっては自動で機能の実現が開始することを希望しない場合もあると考えられるため、機能実現部２１３は、提示部２１２により提示された機能を用いてユーザからの実現指示を受け付けた場合に、その指示に応じて機能を実現するものであってもよい。また、機能実現部２１３は、入力文字列の全部又は一部を利用して機能を実現する場合もあれば、入力文字列を用いないで機能を実現する場合もある。
次に、機能提示システム１の動作を説明する。
【００３３】
図９は、機能提示システム１の動作を示すシーケンスチャートである。
端末装置２０の制御部２１は、ユーザによりＵＩ部２４が操作されて機能提示サービスの利用が指示されると、音声入力の受付を開始する。端末装置２０のユーザは自身が利用したい機能に関する言葉を発する。ここで、ユーザは、品川区にあるラーメン店に関する情報を調べたいと考え、「品川」という言葉と、「ラーメン」という言葉とを発したとする。制御部２１は、音声入出力部２２により「品川」、「ラーメン」というユーザの発声に応じて音声入力を受け付けて、この音声を示す音声情報を入力情報として受け付ける（ステップＳＡ１）。
【００３４】
端末装置２０の制御部２１は、音声情報である入力情報をサーバ装置１０に送信するよう、無線通信部２３を制御する（ステップＳＡ２）。
【００３５】
サーバ装置１０の制御部１１は、通信部１２によるサーバ装置１０との通信により音声情報である入力情報を取得する（ステップＳＡ３）。次に、制御部１１は、辞書ファイル１３１を参照して、音声情報を認識し（ステップＳＡ４）、認識した入力文字列と当該入力文字列に対応する登録文字列の第１識別子とを特定する（ステップＳＡ５）。図３に示すように、辞書ファイル１３１において、登録文字列「品川」に第１識別子「地名，人名」が割り当てられ、登録文字列「ラーメン」に第１識別子「食品」が割り当てられている。よって、制御部１１は、「品川＜地名，人名＞」及び「ラーメン＜食品＞」というデータを得る。
なお、「ＡＡ＜ＢＢ＞」という形式のデータは、入力文字列に含まれる登録文字列「ＡＡ」の第１識別子が「ＢＢ」であることを意味する。このデータ形式は一例であり、登録文字列と第１識別子との関係が明らかであれば、これ以外のデータ形式が採用されてもよい。
【００３６】
次に、制御部１１は、入力文字列と、入力文字列に含まれる登録文字列について特定した第１識別子との組を端末装置２０に送信するよう、通信部１２を制御する（ステップＳＡ６）。
【００３７】
端末装置２０の制御部２１は、入力文字列と、入力文字列に含まれる登録文字列の第１識別子との組を無線通信部２３によって受信すると、ここから第１識別子を取得する（ステップＳＡ７）。制御部１１は、「品川＜地名，人名＞」及び「ラーメン＜食品＞」というデータをサーバ装置１０から取得したから、ここでは、第１識別子として「地名，人名＋食品」を取得する。
なお、ここでは、各登録文字列から特定された第１識別子が「＋」を用いて区別される。
【００３８】
次に、制御部２１は、機能選択ファイル２５１を参照して、ステップＳＡ７の処理で取得した第１識別子に応じて提示対象となる機能が属するカテゴリを選択する（ステップＳＡ８）。
ここで、制御部２１は、機能選択ファイル２５１において、第１識別子「地名，人名＋食品」と一致する第１識別子に対応付けられたカテゴリを選択する。この選択の際、制御部２１は、第１識別子が部分一致したテゴリよりも、完全一致したカテゴリを優先させる。ここでの完全一致は、サーバ装置１０で特定された第１識別子の組み合わせが、機能選択ファイル２５１に記述されていることを意味する。また、部分一致は、サーバ装置１０で特定された第１識別子の組み合わせの一部を構成する第１識別子が、機能選択ファイル２５１に記述されていることを意味する。ここでは、図５に示すように、サーバ装置１０で特定された第１識別子「地名，人名＋食品」に完全一致する第１識別子として、「地名＋食品」が機能選択ファイル２５１に記述されている。また、サーバ装置１０で特定された第１識別子「地名，人名＋食品」に部分一致する第１識別子として、「地名」が機能選択ファイル２５１に記述されている。
よって、制御部２１はカテゴリ「グルメ」、「買い物」及び「地図」を選択し、各カテゴリ優先度をそれぞれ「０．６」、「０．４」、「０．８」と特定する。
なお、カテゴリ「グルメ」は、第１識別子「地名＋食品」と、第１識別子「地名」とで選択されるが、この場合、制御部２１はカテゴリ優先度が高い方を採用するとよい。
【００３９】
次に、制御部２１は、ステップＳＡ８の処理で選択したカテゴリに属する、決められた条件を満たす機能を実現する（ステップＳＡ９）。ここでは、制御部２１は、サーバ装置１０で特定された第１識別子と機能選択ファイル２５１に記述された第１識別子との一致数、カテゴリ優先度、及び機能優先度に応じて定まる１つの機能を、ユーザからの機能の実現指示を受け付けることなく実現する。制御部２１は、第１識別子の一致数が最も多く、且つ、カテゴリ優先度及び機能優先度がそれぞれ最も高い機能を実現する。既に説明したとおり、ここでは、第１識別子の一致数が最も多いカテゴリは「グルメ」及び「買い物」であるが、カテゴリ優先度が最も高いカテゴリは「グルメ」である。そして、カテゴリ「グルメ」に属する機能のうち、機能優先度が最も高い機能は、「グルメサイトＡ」である。よって、制御部２１は、「グルメサイトＡ」について、「品川」及び「ラーメン」を検索語として用いて情報検索を行う。
なお、この場合において、制御部２１は入力文字列に対応する登録文字列のすべてを用いてもよいし、一部の登録文字列を用いてもよい。また、制御部２１は、入力文字列の全体を用いて機能を実現してもよいし、入力文字列を用いないで機能を実現してもよい。
【００４０】
次に、制御部２１は、ステップＳＡ８の処理で選択したカテゴリに属する複数機能を所定の提示方法で提示するとともに、ステップＳＡ９の処理に応じた機能の実現結果を提示する（ステップＳＡ１０）。ここでは、制御部２１は、図６に示す機能管理テーブル２５２で機能優先度が設定されたすべての機能を提示対象とし、更に、ステップＳＡ８の処理で選択したカテゴリに属する機能であって、第１識別子に応じて提示対象となった機能を、他の機能よりも優先させて提示する。ステップＳＡ８の処理で、制御部２１は、「グルメ」、「買い物」及び「地図」という３つのカテゴリを選択したので、「グルメサイトＡ」〜「グルメサイトＣ」→「買い物サイトＡ」→「買い物サイトＣ」→「地図アプリ」という順で、これら７つの機能を他の機能よりも優先させて提示する。具体的には、制御部２１は、第１識別子に応じて提示対象となった機能に対応するアイコン画像を、サーバ装置１０で特定された第１識別子と機能選択ファイル２５１に記述された第１識別子との一致数、カテゴリ優先度、及び機能優先度に応じた態様で配置するとともに、ステップＳＡ９の処理で機能を実現した結果を配置した機能提示画面を、ＵＩ部２４に表示させる。制御部２１は、アイコン画像がＵＩ部２４の操作によりユーザに指定されたことを契機に、そのアイコン画像に対応する機能を実現する。
【００４１】
図１０は、機能提示画面を示す図である。
図１０において、アイコン画像Ｉ１〜Ｉ７は、それぞれ、他の機能よりも優先させて提示される機能に対応するアイコン画像である。機能提示画面が表示されたとき、アイコン画像Ｉ１〜Ｉ４は表示面に表示されているので、ユーザは画面を遷移させるための操作をＵＩ部２４に行うことなく、これらのアイコン画像を視認し、指定することが可能である。一方で、破線で示したアイコン画像Ｉ５〜Ｉ７は、機能提示画面が表示されたときには表示面に表示されず、ユーザが画面を遷移させるための操作（例えば、フリック操作）をＵＩ部２４に行うことで表示面に表示される。これらのアイコン画像Ｉ１〜Ｉ７は、第１識別子の一致数が多い順→カテゴリ優先度が高い順→機能優先度が高い順となるように配置される。すなわち、アイコン画像Ｉ１〜Ｉ７は、順に、「グルメサイトＡ」〜「グルメサイトＣ」→「買い物サイトＡ」〜「買い物サイトＣ」→「地図アプリ」という配置となる。よって、ユーザにしてみれば、第１識別子の一致数が多い機能、カテゴリ優先度が高い機能、又は機能優先度が高い機能のアイコン画像ほど、より少ない操作量の操作で指定することが可能である。
【００４２】
また、制御部２１は、アイコン画像Ｉ７よりも更に図中右側に、すなわち、アイコン画像Ｉ１〜Ｉ７よりもアイコン画像を表示させるための操作量が多くなる位置に、機能管理テーブル２５２で機能優先度が設定された、残りのすべての機能のアイコン画像を表示させる。このようにして制御部２１は、第１識別子に応じて提示対象となる機能以外の機能については、カテゴリ優先度及び機能優先度とは無関係にアイコン画像を配置する。例えば、制御部２１は、機能管理テーブル２５２における機能の記述順と同じになるようなアイコン画像の配置としてもよいし、設計段階等で予め決められた配置としてもよいし、ユーザによる過去の利用履歴を反映させた配置（例えば、利用回数や利用頻度が高い機能ほど、アイコン画像を図中左側に表示させる）としてもよい。ここでは、制御部２１は、第１識別子に応じて提示対象となった機能のみについて、第１識別子の一致数、カテゴリ優先度及び機能優先度に従って提示する。
なお、制御部２１は、第１識別子に応じて提示対象となった機能のみを提示し、それ以外の機能を提示しない、という提示方法を採用してもよい。この場合、アイコン画像Ｉ１〜Ｉ７のみが機能提示画面で表示される。要するに、制御部２１は、予め決められた提示方法に従って、第１識別子に応じて提示対象となった機能を少なくとも提示すればよい。
また、機能提示画面のアイコン画像と同時に、アイコン画像の下側の領域に、制御部２１がステップＳＡ９の処理で実現した機能の実現結果が表示される。この機能の実現結果は、アイコン画像Ｉ１に対応する機能の実現結果となるはずであり、ここでは「グルメサイトＡ」である。これにより、ユーザは、機能提示システム１でユーザが最も強く利用を希望すると推定された機能の実現結果を、速やかに確認することができる。
【００４３】
以上説明した第１実施形態では、サーバ装置１０は、辞書ファイル１３１を参照して、端末装置２０の入力情報を認識し、入力文字列とこの入力文字列に対応する登録文字列の第１識別子とを特定する。そして、端末装置２０は、サーバ装置１０から提供された第１識別子と、機能選択ファイル２５１及び機能管理テーブル２５２とに応じて複数機能を提示する。このような機能提示システム１では、単にユーザにとって好ましいと思われる機能を択一的に推定し提示するのではなく、ユーザの端末装置２０の様々な利用目的の可能性に鑑みて、ユーザにとって有用と推定される機能の候補を複数提示する。また、端末装置２０は、第１識別子の一致数、カテゴリ優先度及び機能優先度に応じた態様で、機能提示画面を表示する。これにより、端末装置２０は、ユーザが利用を強く希望すると推定される機能ほど、ユーザに強いる操作負担を少なくして、選択した複数機能や機能の実現結果を提示することが可能である。
【００４４】
また、機能提示システム１では、構文解析等の複雑な解析処理を入力文字列に対して行わないで、音声認識に用いられる辞書ファイル１３１を参照して第１識別子を特定する。このように、機能提示システム１では、構文解析や、入力文字列を得た後に第１識別子を特定するためのデータベース参照に係る処理を必要としないので、入力情報が端末装置２０に入力されてから機能提示までに要する時間の増大が抑えられる。また、機能提示システム１では、この第１識別子の特定に多数のデータテーブルを参照することはなく、また、入力文字列に含まれる登録文字列の第１識別子はそれぞれ独立して特定されるので、他の登録文字列の第１識別子の確定状況の影響を受けない。よって、機能提示システム１では、入力文字列の各登録文字列の本来の意味を正確に反映させて、機能提示サービスを提供することができる。
【００４５】
＜第１実施形態の変形例＞
上述した第１実施形態の構成を、以下の（１−１）〜（１−６）で説明する構成に変形してもよい。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（１−１）機能提示システム１において、機能選択ファイル２５１に記述された第１識別子の組み合わせ（例えば、「地名＋食品」）の一部を構成する第１識別子が、サーバ装置１０で特定された場合（例えば、「地名」のみが特定された場合）に、これらが部分一致すると扱われてもよい。この場合、制御部２１は、部分一致した第１識別子に機能選択ファイル２５１で対応付けられたカテゴリについては、カテゴリ優先度を小さくするよう補正する。例えば、制御部２１は、部分一致したカテゴリについては、カテゴリ優先度を１／２にする。よって、入力文字列が「品川 ラーメン」のときには、制御部２１は、カテゴリ「グルメ」、「買い物」、及び「地図」について、カテゴリ優先度を「０．６」、「０．４」、「０．４」とする。
なお、制御部２１は、部分一致の程度に応じてカテゴリ優先度の補正の内容を異ならせてもよい。例えば、制御部２１は、一致度が低いほどカテゴリ優先度を大きく減じるように補正する。
【００４６】
（１−２）機能提示システム１が表示する機能提示画面を以下のように変形してもよい。
図１１は、機能提示画面の別の態様を示す図である。
提示対象のアイコン画像の数が多くなった場合、図１０に示す機能提示画面では、第１識別氏の一致数やカテゴリ優先度、機能優先度が相対的に低い機能のアイコン画像が表示されるまでに、ユーザに強いられる操作の量が多くなる。そこで、制御部２１は、図１１（ａ）に示す機能提示画面をまずＵＩ部２４に表示させる。ここで、アイコン画像Ｉ１〜Ｉ３は、図１０に示したアイコン画像と同じものである。制御部２１は、アイコン画像Ｉ１〜Ｉ３の右側に配置したアイコン画像Ｉｅｔｃがユーザにより指定されると、図１１（ｂ）に示す機能提示画面に遷移させる。ここでは、制御部２１は、機能の実現結果を表示させないで、ＵＩ部２４の表示面のほぼ全体を使ってアイコン画像を表示させる。これにより、図１０の機能提示画面よりも表示面に配置可能なアイコン画像が増えるので、カテゴリ優先度が低いカテゴリに属する機能のアイコン画像も、ユーザは指定しやすくなる。制御部２１は、図１１（ｂ）に示す機能提示画面では、図１０に示す機能提示画面の場合と同じ規則に従ってアイコン画像を配置してもよいし、この規則とは無関係にアイコン画像を配置してもよい。制御部２１は、図１１（ｂ）に示す機能提示画面でのアイコン画像の配置を任意のものとすることが可能である。
なお、制御部２１は、図１１（ａ）に示す機能提示画面において機能に対応するアイコン画像を表示させていたが、提示対象の機能が属するカテゴリに対応するアイコン画像を表示させてもよい。この場合、アイコン画像の配置は、第１識別子の一致数が多い→カテゴリ優先度が高い、という順にすればよい。制御部２１は、いずれかのカテゴリに対応するアイコン画像がユーザに指定されると、図１１（ｂ）示す機能提示画面において、指定されたカテゴリに属する各機能のアイコン画像を表示させるとよい。
なお、制御部２１は、提示対象の機能の数が閾値未満であれば、図１０に示すような機能提示画面を表示させ、提示対象の機能の数が閾値以上であれば、図１１に示すような機能提示画面を表示させてもよい。
なお、以上説明した機能提示画面におけるアイコン画像の配置の態様は一例であり、表示面で一度に表示されるアイコン数やそれらの配置位置などは、前掲の態様に限定されない。
【００４７】
（１−３）上述した第１実施形態の機能提示システム１において、端末装置２０の制御部２１は、アイコン画像Ｉ１に対応する機能をユーザの指示なしに実現し、それ以外の機能についてはユーザによりアイコン画像が指定されたことを契機に実現していた。これに代えて、制御部２１は、アイコン画像Ｉ２〜Ｉ７に対応する機能で、第１識別子に応じて提示対象となった機能のうち、ステップＳＡ９の処理で実現しなかった機能を、予めバックグラウンドで実現してもよい。この構成によれば、制御部２１は、アイコン画像がユーザに指定されたことを契機に、迅速にその実現結果を提示することができる。この場合において、制御部２１は、カテゴリ優先度や機能優先度が一定レベル以上高い（例えば、上位の３つ）機能など、アイコン画像を提示する機能のうちの一部の機能について、予めバックグラウンドで実現してもよい。
なお、バックグラウンドでの機能の実現の際、制御部２１は、Ｗｅｂブラウザの実行によるｗｅｂサイトの表示のように、通信を伴う機能については、アプリケーションソフトウェアを実行し、更に、その機能の実現に必要なデータをダウンロードしてキャッシュしておく。一方、制御部２１（機能実現部２１３）は、通信を伴う機能以外の機能については、アプリケーションソフトウェアをＲＡＭに読み出しておく。このバックグラウンドでの機能の実現については、制御部２１がアイコン画像が指定されてから対応する機能の実現を開始するよりも、機能の実現できるまでに要する時間を短くできればよいので、処理の内容は前掲のものに限定されない。制御部２１は、機能の実現に必要な情報処理の一部を予め実行しておけばよい。
【００４８】
（１−４）機能提示システム１において、辞書ファイル１３１に記述された第１識別子に、当該第１識別子が示す分類に対する重み係数が対応付けられていてもよい。この場合、機能提示システム１では、重み係数が大きい第１識別子をより重視する。例えば、登録文字列「品川」について、仮に、地名としての認知度が低く、人名として認知度が高いとした場合に、地名の重み係数を「０．３」とし、人名の重み係数を「１．０」とする。端末装置２０に第１識別子を送信する際、サーバ装置１０の制御部１１は、この第１識別子に重み係数を対応付けておく。端末装置２０は、第１識別子とともに重み係数を取得し、この第１識別子から特定したカテゴリのカテゴリ優先度に重み係数を作用させて（ここでは、乗算する）、最終的なカテゴリ優先度を算出する。
サーバ装置１０が第１識別子「地名」を特定した場合、以下のように端末装置２０は動作する。
【００４９】
端末装置２０の制御部２１は、地図のカテゴリ優先度「０．８」に、地名の重み係数「０．３」を乗算して、カテゴリ優先度「０．２４」を算出する。また、制御部２１は、グルメのカテゴリ優先度「０．２」に、地名の重み係数「０．３」を乗算して、カテゴリ優先度「０．０６」を算出する。また、制御部２１は、Ｗｅｂ検索のカテゴリ優先度「０．５」に、人名の重み係数「１．０」を乗算して、カテゴリ優先度「０．５」を算出する。このようにすれば、カテゴリ優先度は、「Ｗｅｂ検索」＞「地図」＞「グルメ」となる。一方、上述したような重み係数を用いない構成では、「Ｗｅｂ検索」のカテゴリ優先度が「０．５」となり、「地図」のカテゴリ優先度が「０．８」となり、「グルメ」のカテゴリ優先度が「０．２」となるので、カテゴリ優先度は「地図」＞「Ｗｅｂ検索」＞「グルメ」となり、端末装置２０で第１識別子に対する重み付けを用いた場合と異なる結果になる。
以上のように、機能提示システム１では、第１識別子に対応する重み付けの有無やその重み付けの程度によって、カテゴリの提示の態様を異ならせることも可能である。ここでは、登録文字列の意味としての認知度が高いほど、重み付けが大きくなるようにしていたが、これ以外の指標で重み付けが決められていてもよい。
【００５０】
（１−５）機能提示システム１において、機能の種類として、機能が属するカテゴリを用いていたが、機能そのものを用いてもよい。また、この場合において、端末装置２０では、機能選択ファイル２５１の内容と機能管理テーブル２５２の内容を一体化したデータを参照して、入力文字列から特定した第１識別子に応じて提示対象となる機能を特定することも可能である。
【００５１】
（１−６）機能提示システム１において、機能優先度をカテゴリ優先度のように数値化し、この値が大きくなるほど優先度を高くするようにしてもよい。その際、端末装置２０は、図５に示す機能選択ファイル２５１で特定したカテゴリ優先度に機能優先度を作用させて（例えば、乗じて）機能毎の優先度を算出し、この優先度を上述の機能優先度に代えて用いてもよい。
【００５２】
［第２実施形態］
次に、本発明の第２実施形態について説明する。
この第２実施形態の機能提示システム１では、辞書ファイル及び機能選択ファイルの構成が上述した第１実施形態と相違する。これに伴い、サーバ装置１０及び端末装置２０の構成及び動作も上述の第１実施形態とは相違する。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。また、第１実施形態と対応する構成について符号の末尾に「ａ」を付して表し、適宜その説明を省略する。
サーバ装置１０は、音声認識辞書として用いられる辞書ファイル１３１ａを記憶部１３に記憶している。
【００５３】
図１２は、辞書ファイル１３１ａの構成を示す図である。
図１２に示すように、辞書ファイル１３１ａは、「登録文字列」と「機能情報」との各フィールドに記述された情報を対応付けたデータテーブルである。「登録文字列」のフィールドには、辞書ファイル１３１と同様、辞書ファイル１３１ａに登録された文字列が記述される。「機能情報」のフィールドには、第２識別子と重み係数との組が記述される。第２識別子は、登録文字列に対して定められた機能の種類を当該登録文字列の分類として示すものである。機能の種類は、上述した第１実施形態のように機能が属するカテゴリを指す場合もあれば、機能そのものを指す場合もある。図１２に示す例では、「地図」や「グルメ」はカテゴリに相当し、「スケジューラ」や「メモ帳」は機能そのものに相当する。
【００５４】
図１２では、ＡＡ「ＢＢ」というデータ形式で記述されているが、これは第２識別子「ＡＡ」という機能の種類に対して、重み係数「ＢＢ」が与えられていることを意味する。図１２の第４行には、“http://www.〜.com”と記述されているが、これは、登録文字列に関連する情報を提供するＷｅｂサイトのＵＲＬを意味する。これは、Ｗｅｂ閲覧において参照されるアドレス情報であり、機能そのものを示す情報に相当する。重み係数は、ここでは「０．０」以上「１．０」以下の値であり、その値が大きいほど機能の種類に対する重み付けが大きいことを示す。また、辞書ファイル１３１ａは、一の登録文字列について、重み係数の総和が「１．０」となるように構成されている。
辞書ファイル１３１ａでは、登録文字列の意味と関連が深い機能の種類を示す第２識別子が当該登録文字列に対応付けられ、例えば、その関連が深いほど重み係数が大きい。なお、辞書ファイル１３１ａに辞書登録されたすべての登録文字列に、機能情報が割り当てられているとは限らない。
【００５５】
図１３は、機能選択ファイル２５１ａの構成を示す図である。
端末装置２０は、入力文字列から特定される第２識別子と、提示対象となる機能との関係を記述した機能選択ファイル２５１ａを、記憶部２５に記憶している。図１３に示すように、機能選択ファイル２５１ａには、“重み係数の総和が上位３位の種類の機能を、重み付け順の配置とする”という内容が記述されている。ただし、機能選択ファイル２５１ａのこの内容は一例であり、重み係数の総和が上位５位等とされてもよいし、ユーザにより設定された内容であってもよい。このように機能選択ファイル２５１ａは、入力文字列に対応する登録文字列の機能情報に応じて提示対象となる機能の規則を記述したデータである。
以上の構成を有する機能選択ファイル２５１ａは、詳しくは後述するが、所定の提示方法で提示する機能を選択する際に、端末装置２０により参照されるデータである。
次に、制御部１１の機能的構成について説明する。ここでは、上述した第１実施形態における機能的構成との相違点を主に説明する。
【００５６】
情報取得部１１１は、通信部１２の通信により端末装置２０の入力情報を取得する。特定部１１２は、辞書ファイル１３１ａを参照して、情報取得部１１１が取得した入力情報が示す入力文字列と、当該入力文字列に対応する登録文字列の機能情報（つまり、第２識別子及び重み係数）とを特定する。入力情報が音声情報である場合、特定部１１２は、辞書ファイル１３１ａを参照して、音声情報を認識し、認識した入力文字列と入力文字列に対応する登録文字列の機能情報とを特定する。送信制御部１１３は、入力文字列と、入力文字列に対応する登録文字列について特定部１１２が特定した機能情報との組を端末装置２０に送信するよう、通信部１２を制御する。
制御部１１のこれ以外の機能は、上述した第１実施形態と同じである。
次に、制御部２１の機能的構成について説明する。ここでは、上述した第１実施形態における機能的構成との相違点を主に説明する。
【００５７】
識別子取得部２１１は、無線通信部２３により受信された入力文字列と、入力文字列に対応する登録文字列の機能情報との組を取得し、ここから機能情報を取得する。
提示部２１２は、機能選択ファイル２５１ａ及び機能管理テーブル２５２を参照して、識別子取得部２１１が取得した機能情報に応じて提示対象となる機能を所定の提示方法で複数提示する。例えば、提示部２１２は、識別子取得部２１１が取得した機能情報と、機能選択ファイル２５１ａに記述された内容とに応じて定まる機能を、他の機能よりも優先させて提示する。
制御部２１のこれ以外の機能は、上述した第１実施形態と同様である。
次に、機能提示システム１の動作を説明する。
【００５８】
図１４は、機能提示システム１の動作を示すシーケンスチャートである。図１４に示すステップＳＢ１〜ＳＢ３の処理ステップは、上述した第１実施形態のＳＡ１〜ＳＡ３と同じであるから、ここではその説明を省略する。以下の説明において、ユーザは「品川」及び「ラーメン」を音声入力したものとする。
サーバ装置１０の制御部１１は、辞書ファイル１３１ａを参照して、音声情報を認識し（ステップＳＢ４）、認識した入力文字列とこの入力文字列に対応する登録文字列の機能情報とを特定する（ステップＳＢ５）。図１２に示すように、辞書ファイル１３１ａにおいて、登録文字列「品川」には、機能情報“地図「０．７」、グルメ「０．２」、電話「０．１」”が対応付けられ、登録文字列「ラーメン」には、機能情報“グルメ「０．４」、レシピ「０．３」、買い物「０．３」”が対応付けられている。
次に、制御部１１は、入力文字列と、入力文字列に含まれる登録文字列について特定した機能情報との組を端末装置２０に送信するよう、通信部１２を制御する（ステップＳＢ６）。
【００５９】
端末装置２０の制御部２１は、入力文字列と、入力文字列に含まれる登録文字列について特定した機能情報との組を無線通信部２３によって受信すると、ここから機能情報を取得する（ステップＳＢ７）。ここで、制御部２１は、機能情報＜地図「０．７」、グルメ「０．２」、電話「０．１」＞及び＜グルメ「０．４」、レシピ「０．３」、買い物「０．３」＞をそれぞれ取得する。
次に、制御部２１は、機能選択ファイル２５１ａを参照して、機能の種類毎に重み係数の総和を算出する（ステップＳＢ８）。ここでは、制御部２１は、＜地図「０．７」、グルメ「０．６」、レシピ「０．３」、買い物「０．３」、電話「０．１」＞を算出する。
【００６０】
次に、制御部２１は、ステップＳＢ８の処理で重み係数を算出した種類の機能から、決められた条件を満たす機能を実現する（ステップＳＢ９）。ここでは、制御部２１は、重み係数が最大であった種類の機能を実現する。重み係数が最大であった機能の種類がカテゴリであった場合、制御部２１は、そのカテゴリに属する機能優先度が最も高い機能を実現する。それ以外は、制御部２１は、第１実施形態のステップＳＡ９の処理と同様にすればよい。
【００６１】
次に、制御部２１は、機能選択ファイル２５１ａ及び機能管理テーブル２５２を参照して、ステップＳＢ７で取得した機能情報に応じて提示対象となる機能を所定の提示方法で提示させるとともに、ステップＳＢ９の処理に応じた機能の実現結果を提示する（ステップＳＢ１０）。ここでは、制御部２１は、図６に示す機能管理テーブル２５２で機能優先度が設定されたすべての機能を提示対象とし、かつ、機能情報に応じて提示対象となる機能を、他の機能よりも優先させて提示する。ここでは、制御部２１は、機能選択ファイル２５１ａに記述された“重み係数の総和が上位３位の種類の機能を、重み付け順の配置とする”という内容に従って、重み係数の総和が上位３位の種類の機能（ここでは、カテゴリ「グルメ」、「買い物」及び「地図」に属する機能）について、重み係数の総和が高い順→機能優先度が高い順となるようにアイコン画像を配置して、機能提示画面をＵＩ部２４に表示させる。制御部２１は、機能管理テーブル２５２で機能優先度が設定されたそれ以外の機能については、機能優先度や重み係数の総和とは無関係にアイコン画像を配置して、機能提示画面を表示させる。
なお、本実施形態においても、制御部２１は、機能選択ファイル２５１ａで規定される条件を満たす機能のアイコン画像のみを提示し、機能管理テーブル２５２で機能優先度が設定された他の機能については提示しない、という提示方法を採用してもよい。要するに、制御部２１は、予め決められた提示方法に従って、機能情報に応じて提示対象となった機能を少なくとも提示すればよい。
【００６２】
以上説明した第２実施形態の機能提示システム１では、登録文字列の分類として登録文字列に定められた機能の種類を用いる点で、上述の第１実施形態と相違する。これにより、例えば、登録文字列と機能の種類との関係が多数のユーザによって利用される組み合わせであるほど、重み係数が大きくなるように設定されていれば、機能提示システム１では、多数のユーザの実際の利用状況の統計に応じた機能提示サービスを提供することが可能となる。また、サーバ装置１０で辞書ファイル１３１ａが管理されるので、入力文字列に応じて好ましい機能が時々刻々と変化することがあっても、サーバ装置１０側での調整により、機能提示システム１において現在の状況に応じた機能の提示が可能となる。
これ以外にも、本実施形態の機能提示システム１によれば、上述した第１実施形態と同等の作用効果を奏する。
【００６３】
＜第２実施形態の変形例＞
上述した第２実施形態の構成を、以下の（２−１）〜（２−３）で説明する構成に変形してもよい。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（２−１）機能提示システム１において、辞書ファイル１３１ａに記述された重み係数をそのまま用いるのではなく、登録文字列毎の重要度に応じて重み係数を変化させてから、制御部２１が重み係数の総和を算出するようにしてもよい。例えば、登録文字列「品川」に対して登録文字列「ラーメン」が２倍重要であったとすると、制御部２１は、登録文字列「ラーメン」の重み係数を２倍にしてから、重み係数の総和を算出する。この場合、制御部２１は、＜地図「０．７」、グルメ「０．２」、電話帳「０．１」＞、及び＜グルメ「０．８」、レシピ「０．６」、買い物「０．６」＞で加算するので、ステップＳＢ１０の処理では、カテゴリ「グルメ」、「地図」、「レシピ」の順で機能を優先させて提示する。
登録文字列毎の重要度は、サーバ装置１０の管理者や端末装置２０のユーザにより設定されてもよいし、サーバ装置１０や端末装置２０により、入力文字列における登録文字列の入力頻度の希少度（例えば、入力文字列としての利用が少ない登録文字列）や、ｔｆ−ｉｄｆ（Term Freaquency-Inverse Document Frequency）等の指標を用いて算出されてもよい。ｔｆ−ｉｄｆは、文書中の単語に関する重みの一種であり、主に情報検索や文章要約等の分野で利用されるものであるが、例えば、これまで利用された入力文字列を用いて算出されればよい。これにより、例えば、「表参道」等のような利用頻度が高い登録文字列については、重要度が低く設定され、店舗名等のように、利用頻度が低い登録文字列については、重要度が高く設定される。
【００６４】
（２−２）機能提示システム１では、機能の種類毎に重み係数を合算しているが、例えばカテゴリ「グルメ」と、機能「グルメサイトＡ」との重み係数を合算するなど、機能と、その機能が属するカテゴリとの重み係数を合算してもよい。また、本実施形態の機能提示システム１では、重み係数の総和に応じて機能を提示しているが、これ以外にも、重み付けを反映させるための周知の方法を用いて機能を提示してもよい。
（２−３）機能提示システム１で、機能の種類として、機能が属するカテゴリ又は機能そのもののどちらか一方が採用されてもよい。
【００６５】
［第３実施形態］
次に、本発明の第３実施形態について説明する。
この第３実施形態の機能提示システム１では、上述した第１実施形態のように第１識別子に応じて機能を提示する「第１の提示方法」と、上述した第２実施形態のように機能情報（第２識別子）に応じて機能を提示する「第２の提示方法」とを択一的に採用して、機能を提示する。第１及び第２の提示方法のアルゴリズムは、上述した第１、第２実施形態と同じである。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。また、第１実施形態と対応する構成について符号の末尾に「ｂ」を付して表し、適宜その説明を省略する。
【００６６】
ところで、ある入力文字列に対して第１及び第２の提示方法のいずれかを採用しようとした場合、以下のような事情が存在すると発明者は考えた。
例えば有名人の名前が入力文字列に含まれている場合、第１の提示方法のように登録文字列の意味的な分類に基づいて機能を提示する構成では、どの有名人でも結果が同じになることがある。一方で、有名人の名前であっても、その名前によって、ユーザにとって好ましい機能は異なると考えられる。例えば、ユーザにしてみれば、ウェブログを開設している有名人であればそのウェブログを閲覧したいと考えることがあるし、有名人が歌手であればその有名人の音楽を聴きたいと考える場合があるし、有名人によってはその有名人の画像を閲覧したいと考える場合もある、という具合である。このような事情を考慮すると、第２の提示方法を採用するのが好ましいと考えられる。しかしながら、第２の提示方法で好ましい機能の提示結果をユーザが得るには、辞書ファイル１３１ａにおいてユーザの利用状況に関して十分な統計結果が反映されていなければならず、統計量が不足していると、好ましい提示結果をユーザが得られない場合がある。また、入力文字列に複数の登録文字列が含まれている場合には、その組み合わせ次第で重み係数が様々に変化しうるので、必ずしもユーザにとって好ましい機能が提示されるとは限らない。このような事情に照らして、本実施形態の機能提示システム１では、上記第１又は第２の提示方法の一方を択一的に採用する。
【００６７】
図１５は、辞書ファイル１３１ｂの構成を示す図である。サーバ装置１０は、音声認識辞書として用いられる辞書ファイル１３１ｂを記憶部１３に記憶している。
図１５に示すように、辞書ファイル１３１ｂは、「登録文字列」と、「第１識別子」と、「機能情報」との各フィールドに記述された情報を対応付けたデータテーブルである。「登録文字列」のフィールドには、辞書ファイル１３１と同様、辞書ファイル１３１ｂに登録された文字列が記述される。「第１識別子」のフィールドには、辞書ファイル１３１と同様の第１識別子が記述される。「機能情報」のフィールドには、辞書ファイル１３１ａと同様の情報が記述される。
【００６８】
図１６は、機能選択ファイル２５１ｂにあっては、上述した機能選択ファイル２５１，２５１ａの双方の内容が記述されている。端末装置２０は、機能選択ファイル２５１ｂを、記憶部２５に記憶している。
この実施形態の機能提示システム１において、第１又第２の提示方法のどちらを採用するかを決定するための仕組みとして、以下のようなものがある。
【００６９】
例えば、特定部１１２は、入力文字列に対応する登録文字列が１つだけである場合、第２の提示方法を採用するように機能情報を特定し、登録文字列が２つ以上である場合には、第１の提示方法を採用するように第１識別子を特定する。以降、サーバ装置１０及び端末装置２０は、特定部１１２が特定した識別子に応じて、上述した第１、２実施形態のいずれかと同様にして機能する。例えば、入力文字列に「品川」又は「ラーメン」の一方のみが含まれていれば、機能提示システム１では、第２の提示方法が採用される。また、入力文字列に「品川」及び「ラーメン」の２つが含まれていれば、機能提示システム１では、第１の提示方法が採用される。このようにすれば、第１又は第２の提示方法のそれぞれの長所を活かすことができると考えられる。
【００７０】
制御部２１が第２の提示方法を採用する場合、図１７に示す重み付け更新テーブル１３２を参照して、第１識別子が示すカテゴリに応じた更新係数を重み係数に作用させて（ここでは、乗じて）から、重み係数の総和を算出するようにしてもよい。重み付け更新テーブル１３２は、例えばサーバ装置１０で管理され記憶部１３に記憶されている。制御部２１は、重み付け更新テーブル１３２の内容を基に、例えば第１識別子「地名＋食品」に対応付けられたカテゴリ「グルメ」に属する機能について、重み係数に更新係数を乗じて２倍にしてから、重み係数の総和を算出する。このようにすれば、第２の提示方法の採用時においても、第１の提示方法で用いた意味的な分類による作用を反映させることができる。
【００７１】
また、特定部１１２は、入力文字列に対応する登録文字列に、第１識別子又は第２識別子の一方しか対応付けられていない場合、識別子が記述されている方の提示方法を採用してもよい。これにより、機能提示システム１では、辞書ファイル１３１ｂにおける識別子の有無に応じて、適切な提示方法を選択し、より適切な機能を提示できることができる。
これら以外にも、機能提示システム１において、辞書ファイル１３１ｂにおいてユーザの利用状況の統計が十分に反映されている登録文字列が入力文字列に含まれる場合には、第２の提示方法が採用されるようにし、それ以外の場合は、第１の提示方法が採用されてもよい。例えば、サーバ装置１０が辞書ファイル１３１ｂに記述された登録文字列が入力文字列に含まれていた回数を数えておき、この回数が閾値以上になれば、統計量が十分と判断して第２の提示方法を優先して採用し、それ以外の場合は、第１の提示方法を採用する。
機能提示システム１において第１又は第２の提示方法のどちらを採用するかの判定条件は、前掲以外のものであってもよい。また、以上の第３実施形態の機能提示システム１によれば、上述した第１、第２実施形態と同等の効果も奏する。
【００７２】
［第４実施形態］
次に、本発明の第４実施形態について説明する。
この第４実施形態の機能提示システム１は、上述した第１〜３実施形態で説明した辞書ファイルを更新する機能を有している。本実施形態の機能提示システム１の構成のうち、第１，２実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。
【００７３】
図１８は、サーバ装置１０の制御部１１の機能的構成を示す機能ブロック図である。
図１８に示すように、制御部１１は、プログラムを実行することにより、情報取得部１１１と、特定部１１２と、送信制御部１１３と、更新データ取得部１１４と、第１更新部１１５とに相当する機能を実現する。情報取得部１１１、特定部１１２及び送信制御部１１３は、上述した第１又は第２実施形態と同等に機能する。更新データ取得部１１４は、提示部２１２により複数機能が提示された後にユーザにより実現が指示された機能を特定するための更新データを取得する。更新データ取得部１１４は、ＵＩ部２４が操作されていずれかの機能の実現が指示されると、その指示がなされた機能の通知を更新データとして、通信部１２の通信により取得する。ユーザにより実現が指示される機能は、機能提示画面において提示された機能もあれば、機能提示画面において提示されなかった機能もある。
【００７４】
第１更新部１１５は、更新データ取得部１１４が取得した更新データに基づいて、辞書ファイル１３１，１３１ａを更新する。第１更新部１１５は、更新データ取得部１１４が取得した更新データで特定される機能が提示部２１２により提示されやすくなるように、辞書ファイル１３１，１３１ａを更新する。
次に、機能提示システム１の動作を説明する。以下、第１識別子に基づいて機能を提示する第１の提示方法の場合と、第２実施形態のように機能情報に基づいて機能を提示する第２の提示方法の場合とに分けて動作を説明する。
【００７５】
図１９は、第１の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＡ１〜ＳＡ１０までの処理ステップは、上述した第１実施形態と同じであるから、ここではその説明を省略する。
端末装置２０の制御部２１は、ステップＳＡ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等によって、機能の実現の指示を受け付ける（ステップＳＡ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリの実行により実現される機能が指示されたものとする。この「動作アプリ」は、機能提示画面において提示されていない機能に該当するものである。
制御部２１は、登録文字列「品川」及び「ラーメン」である場合の提示結果に対し、動画アプリに関する機能の実現指示があった旨を、無線通信部２３によりサーバ装置１０に通知する（ステップＳＡ１２）。
【００７６】
サーバ装置１０の制御部１１は、通信部１２より実現指示があった旨の通知を受信すると、この通知を更新データとして取得する（ステップＳＡ１３）。次に、制御部１１は、取得した更新データに基づいて、辞書ファイル１３１を更新する（ステップＳＡ１４）。辞書ファイル１３１の更新方法として、以下のようなものがある。
例えば、制御部１１は、登録文字列「品川」及び「ラーメン」を組み合わせて一の登録文字列として、「品川ラーメン」という登録文字列を辞書ファイル１３１に新たに記述する。そして、制御部１１は、登録文字列「品川ラーメン」が入力文字列に含まれる場合に、機能「動作アプリ」が提示されるように、第１識別子を決定する。この場合の第１識別子には、図５に示す機能選択ファイル２５１で、動作アプリが属するカテゴリ「動画再生」と対応付けられた「映画名」がある。
このように制御部１１は、入力文字列に含まれる登録文字列を複数組み合わせて一の登録文字列とする。そして、制御部１１は、ステップＳＡ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部１１は、特定したカテゴリに機能選択ファイル２５１において対応付けられた第１識別子を、組み合わせた登録文字列に対応付けるよう、辞書ファイル１３１を更新する。
【００７７】
また、制御部１１は、既登録の登録文字列「品川」及び「ラーメン」のそれぞれの第１識別子を書き換えるように、辞書ファイル１３１を更新してもよい。この場合、制御部１１は、辞書ファイル１３１において、登録文字列「品川」及び「ラーメン」の双方又は一方に第１識別子「映画名」を追加するように更新する。
このように制御部１１は、ステップＳＡ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部１１は、特定したカテゴリに機能選択ファイル２５１において対応付けられた第１識別子を登録文字列に対応付けるように、辞書ファイル１３１を更新する。
【００７８】
図２０は、第２の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＢ１〜ＳＢ１０までの処理ステップは、上述した第２実施形態と同じであるから、ここではその説明を省略する。端末装置２０の制御部２１は、ステップＳＢ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等によって、機能の実現の指示を受け付ける（ステップＳＢ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリの実行により実現される機能の実現が指示されるものとする。制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリに関する機能の実現指示があった旨を、無線通信部２３によりサーバ装置１０に通知する（ステップＳＢ１２）。
【００７９】
サーバ装置１０の制御部１１は、通信部１２より実現指示があった旨の通知を受信すると、この通知を更新データとして取得する（ステップＳＢ１３）。次に、端末装置２０の制御部２１は、取得した更新データに基づいて、辞書ファイル１３１ａを更新する（ステップＳＢ１４）。辞書ファイル１３１ａの更新方法として、以下のようなものがある。
例えば、制御部１１は、登録文字列「品川」及び「ラーメン」を一の登録文字列「品川ラーメン」として辞書ファイル１３１ａに記述する。そして、制御部１１は、この登録文字列「品川ラーメン」が入力文字列に含まれる場合に、機能選択サービスにおいて機能「動画アプリ」が提示されやすくなるように、機能情報を設定する。例えば、制御部１１は、カテゴリ「動作再生」の重み係数を「１．０」としたり、機能「動画アプリ」の重み係数を「１．０」にしたりする。
このように制御部１１は、入力文字列に含まれる登録文字列を複数組み合わせて一の登録文字列とするとともに、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類（機能そのものと、機能が属するカテゴリのどちらでもよい。）を、当該一の登録文字列に対応付けるよう、辞書ファイル１３１ａを更新する。
【００８０】
また、制御部１１は、既登録の登録文字列「品川」及び「ラーメン」のそれぞれの機能情報を書き換えるように、辞書ファイル１３１ａを更新してもよい。この場合、制御部１１は、辞書ファイル１３１ａにおいて、登録文字列「品川」及び「ラーメン」の双方に、第２識別子「映画名」と重み係数とが対応付けられるように更新する。ここでは、制御部１１は、登録文字列「品川」及び「ラーメン」の第２識別子「動画再生」について、重み係数を「０．１」だけ加算するという具合に、決められた値を加算して新たな重み係数とするとよい。また、制御部１１は、上述した稀少性やｔｆ−ｉｄｆの指標を用いて、稀少性の高いものやｔｆ−ｉｄｆが大きいほど、重み係数の増加量を大きくするようにしてもよい。また、制御部１１は、登録文字列「品川」及び「ラーメン」の第２識別子として、機能「動画アプリ」を追加してもよい。
このように制御部１１が、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類を、入力文字列に含まれる一の登録文字列に新たに対応付けたり、当該登録文字列が既登録であれば当該機能の種類の重み係数を大きくしたりして、辞書ファイル１３１ａを更新する。
【００８１】
なお、機能提示システム１における辞書ファイルの更新は、ユーザにより機能提示サービスが利用されるたびに行われてもよいし、サーバ装置１０で機能提示サービスの利用履歴が管理され、同じ利用が閾値以上の回数又は頻度行われたことを契機に更新されてもよい。また、機能提示システム１において、機能提示サービスの利用履歴に基づいて、同じ利用をした端末装置２０の数又は割合が閾値以上となったことを契機に辞書ファイルが更新されてもよい。機能提示サービスの利用履歴を管理するために、例えば、更新データ取得部１１４は、取得した更新データで特定される機能の実現履歴（例えば、機能の種類や機能の実現日時、機能を実現した端末装置を識別する情報を含む。）を記憶部１３に記憶（蓄積）させる。そして、第１更新部１１５は、記憶部１３に蓄積された機能の実現履歴に基づいて、辞書ファイルを更新する。
【００８２】
以上説明した第４実施形態の機能提示システム１では、実際のユーザの機能の利用状況を学習して、辞書ファイルを更新することができる。また、この機能提示システム１によれば、機能提示サービスの利用回数が増えるほど、より好ましい機能提示サービスを提供することができるし、登録文字列が自動で辞書ファイルに蓄積されるという効果も奏する。このようにして、本実施形態の機能提示システム１によれば、多数のユーザの利用状況に応じて、世間の動向や流行等を反映したサービスの提供が可能となる。
なお、本実施形態の辞書ファイルの更新に係る構成は、上述した第３実施形態の機能提示システム１における辞書ファイル１３１ｂの更新にも適用可能である。
【００８３】
［第５実施形態］
次に、本発明の第５実施形態について説明する。
この第５実施形態の機能提示システム１は、機能選択ファイル２５１，２５１ａを更新する機能を有している。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１，２実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。
【００８４】
図２１は、端末装置２０の制御部２１の機能的構成を示す機能ブロック図である。
図２１に示すように、制御部２１は、プログラムを実行することにより、識別子取得部２１１と、提示部２１２と、機能実現部２１３と、更新データ取得部２１４と、第２更新部２１５とに相当する機能を実現する。識別子取得部２１１、提示部２１２、及び機能実現部２１３は、上述した第１又は第２実施形態と同等に機能する。更新データ取得部２１４は、提示部２１２により複数機能が提示された後にユーザにより実現が指示された機能を特定するための更新データを取得する。更新データ取得部２１４は、ＵＩ部２４が操作されていずれかの機能の実現が指示されると、その指示がなされた機能の更新データを取得する。
【００８５】
第２更新部２１５は、更新データ取得部２１４が取得した更新データで特定される機能に基づいて機能選択ファイル２５１，２５１ａを更新する。第２更新部２１５は更新データ取得部２１４が取得した更新データで特定される機能が提示部２１２で提示されやすくなるように、機能選択ファイル２５１，２５１ａを更新する。
次に、機能提示システム１の動作を説明する。以下、第１実施形態の提示方法の場合と第２実施形態の提示方法の場合とに分けて動作を説明する。
【００８６】
図２２は、第１の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＡ１〜ＳＡ１０までの処理ステップは、上述した第１実施形態と同じであるから、ここではその説明を省略する。
端末装置２０の制御部２１は、ステップＳＡ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等により、機能の実現の指示を受け付ける（ステップＳＡ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリ実行が指示されるものとする。
【００８７】
制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリにより実現される機能を特定するための更新データを取得する（ステップＳＡ１５）。次に、制御部２１は、取得した更新データに基づいて、機能選択ファイル２５１を更新する（ステップＳＡ１６）。機能選択ファイル２５１の更新方法として、以下のようなものがある。
例えば、制御部２１は、登録文字列「品川」＋「ラーメン」に対応して、第１識別子「地名＋食品」に対応するカテゴリを書き換えるように、機能選択ファイル２５１を更新する。この場合、制御部２１は、機能選択ファイル２５１において、第１識別子「地名＋食品」又は「人名＋食品」に、カテゴリ「動画再生」を対応付けるように更新する。
これにより、入力文字列に「品川」及び「ラーメン」が含まれる場合に、カテゴリ「動画再生」に属する機能が提示されることになる。この場合、登録文字列「大阪」＋「ハンバーグ」の場合も、第１識別子「地名＋食品」又は「人名＋食品」となるので、カテゴリ「動画再生」に属する機能が提示されやすくなる。
このように制御部２１は、ステップＳＡ１５の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部２１は、特定したカテゴリにステップＳＡ７の処理で取得した第１識別子を新たに対応付けたり、この第１識別子に対応付けられたカテゴリ優先度を高くしたりして、機能選択ファイル２５１を更新する。
【００８８】
図２３は、第２の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＢ１〜ＳＢ１０までの処理ステップは、上述した第２実施形態と同じであるから、ここではその説明を省略する。端末装置２０の制御部２１は、ステップＳＢ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等により、機能の実現の指示を受け付ける（ステップＳＢ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリ実行が指示されるものとする。制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリにより実現される機能を特定するための更新データを取得する（ステップＳＢ１５）。次に、制御部２１は、取得した更新データに基づいて、機能選択ファイル２５１ａを更新する（ステップＳＢ１６）。機能選択ファイル２５１ａの更新方法として、以下のようなものがある。
【００８９】
例えば、制御部２１は、登録文字列「品川」＋「ラーメン」に対応して、カテゴリ「グルメ」、「地図」および「レシピ」を選択するが、ここに強制的に、カテゴリ「動画再生」を含めるように、機能選択ファイル２５１ａ更新する。これにより、以降、入力文字列に「品川」及び「ラーメン」が含まれる場合に、機能提示システム１では、カテゴリ「動画再生」に属する機能「動画アプリ」が提示される。また、機能提示システム１において、重み係数に関わらず、カテゴリ「動画再生」や機能「動画アプリ」の機能優先度を最も高い優先度として扱う内容が機能選択ファイル２５１ａに記述されていてもよい。
このように制御部１１は、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類を特定し、特定した機能の種類がステップＳＢ７の処理で取得した機能情報と同じものが取得されたときにこの種類が提示されやすくなるよう、機能選択ファイル２５１ａを更新する。
【００９０】
なお、機能提示システム１における機能選択ファイルの更新は、ユーザにより機能提示サービスが利用されるたびに行われてもよいし、サーバ装置１０で機能提示サービスの利用履歴が管理され、同じ利用が閾値以上の回数又は頻度行われたことを契機に更新されてもよい。また、機能提示システム１において、機能提示サービスの利用履歴に基づいて、同じ利用をした端末装置２０の数又は割合が閾値以上となったことを契機に更新されてもよい。機能提示サービスの利用履歴を管理するために、例えば、更新データ取得部２１４は、取得した更新データで特定される機能の実現履歴（上述した第４実施形態と同じデータでよい。）を記憶部２５に蓄積させる。そして、第２更新部２１５は、記憶部２５に蓄積された機能の実現履歴に基づいて、機能選択ファイルを更新する。
【００９１】
以上説明した第５実施形態の機能提示システム１では、実際のユーザの機能の利用状況を学習して、機能選択ファイルを更新することができる。また、この機能提示システム１によれば、機能提示サービスの利用回数が増えるほど、より好ましい機能提示サービスを提供することができる。このようにして、本実施形態の機能提示システム１によれば、多数のユーザの利用状況に応じて、世間の動向や流行等を反映したサービスの提供が可能となる。
なお、本実施形態の機能選択ファイルの更新に係る構成は、上述した第３実施形態の機能提示システム１の機能選択ファイル２５１ｂの更新にも適用可能である。また、第４，第５実施形態の更新の機能を両方備えた機能提示システム１としてもよい。
【００９２】
［変形例］
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
［変形例１］
上述した各実施形態では、端末装置２０は辞書ファイル及び機能選択ファイルに基づいて提示する機能を特定していたが、端末装置２０が以下のように動作するようにしてもよい。なお、本変形例では、端末装置２０は、サーバ装置１０により識別子が特定される前に入力文字列を取得する。端末装置２０は、例えば、自装置の音声認識機能で入力文字列を取得する。
なお、以下では、制御部１１がサーバ装置１０から取得する入力文字列を用いて行う制御の説明を省略する。
【００９３】
図２４は、端末装置２０の動作を示すフローチャートである。
制御部２１は、入力文字列を取得する（ステップＳＣ１）。次に、制御部２１は、入力文字列に特定の登録文字列が含まれるか否かを判断する（ステップＳＣ２）。特定の登録文字列は、ここでは、「（検索サイトＡの名称） ○○」や「地図 △△」のように、ユーザが利用を希望する機能を特定可能な予め決められた文字列である。このような文字列が入力文字列に含まれていれば、実質的に、利用したい機能をユーザが指定したことに近いといえる。
制御部２１は、特定の登録文字列が含まれると判断した場合（ステップＳＣ２；ＹＥＳ）、この登録文字列に対応して定められた機能を実現する。入力文字列が「（検索サイトＡ） ○○」であれば、制御部２１は、検索サイトＡで検索語を「○○」として情報検索を行い、入力文字列が「地図 品川」であれば、制御部２１は、地図アプリを実行して品川区付近の地図を表示する、という具合である。
このような特定の登録文字列と、実現対象となる機能との対応関係は記憶部２５等に記憶され、制御部２１はこの対応関係を参照するとよい。
【００９４】
制御部２１は、ステップＳＣ３の処理を実行した後、又はステップＳＣ２で特定の登録文字列が含まれないと判断した場合（ステップＳＣ２；ＮＯ）、無線通信部２３により入力文字列をサーバ装置１０に送信する（ステップＳＣ４）。そして、上述した各実施形態の手順で、サーバ装置１０によりこの入力文字列を入力情報として第１識別子又は機能情報が特定されると、制御部２１は無線通信部２３により第１識別子又は機能情報を受信する（ステップＳＣ５）。そして、制御部２１は、受信した第１識別子又は機能情報と、機能選択ファイル及び機能管理テーブル２５２とに基づいて機能の種類を特定し（ステップＳＣ６）、提示対象の機能があるか否かを判断する（ステップＳＣ７）。
【００９５】
ここで、制御部２１は、提示対象の機能がある場合には（ステップＳＣ７；ＹＥＳ）、上述した各実施形態と同様にして、機能管理テーブル２５２に従って機能を提示する（ステップＳＣ８）。一方、制御部２１は、提示対象の機能がない場合には（ステップＳＣ７；ＮＯ）、標準設定の機能を提示する（ステップＳＣ９）。ここでは、制御部２１は、所定の情報検索サイトやメモ帳等、適切な機能が提示できなかった場合においてユーザが希望する可能性の高いと推定される所定の機能を提示する。この機能は、ユーザ設定や設計段階等で決められてもよいし、制御部２１が、ユーザの過去の利用履歴に基づいて、利用回数や頻度が閾値以上となった機能を提示してもよい。
本変形例の構成によれば、端末装置２０は、入力文字列に含まれる文字列そのものから、ユーザの希望する機能を推定して提示することが可能である。また、提示対象の機能がない場合であっても、何の機能も提示されないで、ユーザが不便に感じてしまうことを抑えることができる。
【００９６】
［変形例２］
上述した各実施形態では、入力文字列に対して辞書ファイル及び機能選択ファイルを参照して機能提示していたので、登録文字列の表記方法がいかようであっても、登録文字列が同一であれば提示結果が同一になることがある。例えば、入力文字列に「ラーメン」という１つの登録文字列が含まれる場合、「ラーメンが食べたい」、「ラーメンの作り方」のどちらであっても、提示結果が同じになるということである。しかしながら、前者の入力文字列であれば、カテゴリ「グルメ」の機能がユーザにとって好適であるといえるし、後者の入力文字列であれば、カテゴリ「レシピ」の機能がユーザにとって好適であるといえる。このように、入力文字列における登録文字列の表記方法は、入力文字列における当該登録文字列以外の文字列（又は文字）によって変化しうるものである。
そこで、本変形例では、提示部２１２は、識別子取得部２１１から識別子とともに入力文字列を取得し、入力文字列における登録文字列の表記方法に従って、機能の提示方法を異ならせる。例えば、「食べたい」や「作り方」のような文字列に対応するカテゴリ又は機能を示す情報が記憶部２５に記憶されていて、提示部２１２はこの情報に従って、他の機能よりも優先させて提示する機能を特定する。提示部２１２は、アイコン画像の配置順を変更するようにして機能の提示方法を異ならせてもよいし、優先させて提示する機能のみを提示してもよい。
【００９７】
また、提示部２１２は、入力文字列を解析して、入力文字列において文字数、登録文字列数又は形態素数が閾値以上である場合には、機能選択ファイルを参照しないで機能を提示するようにしてもよい。例えば、入力文字列が「ラーメンを最初に発明したのは誰か」の場合、提示部２１２は、予め決められた機能として、カテゴリ「Ｗｅｂ検索」に属する機能や「メモ帳」を選択する、という具合である。
【００９８】
［変形例３］
上述した各実施形態では、情報取得部１１１、特定部１１２及び送信制御部１１３に相当する機能がサーバ装置１０で実現され、識別子取得部２１１、提示部２１２及び機能実現部２１３に相当する機能が端末装置２０で実現されていたが、前掲した各機能を実現する装置は、この態様に限定されるものではない。要するに、機能提示システム１により実現される機能的構成が、例えば図２５に示す構成になればよい。
例えば、サーバ装置１０が、情報取得部１１１、特定部１１２及び識別子取得部２１１に相当する機能を実現してもよい。この場合、サーバ装置１０は、辞書ファイル及び機能選択ファイルの双方を記憶する。サーバ装置１０は、機能選択ファイルを参照して提示対象となる機能の種類を選択すると、その内容を端末装置２０に通知する。そして、端末装置２０において、提示部２１２は、通知された種類の機能を、機能管理テーブルを参照して提示する。
【００９９】
また、上述したすべての機能が端末装置２０で実現されてもよい。この場合、端末装置２０は、入力情報を取得すると、辞書ファイルを参照して、入力情報が示す入力文字列と識別子（つまり、第１又は第２識別子）とを特定する。そして、端末装置２０は、特定した識別子と、機能選択ファイル及び機能管理テーブルとに応じて、機能を提示する。この場合、端末装置２０が辞書ファイル及び機能選択ファイルの双方を記憶する。この構成であっても、サーバ装置１０が端末装置２０に更新データを送信する等して、上述した第４，５実施形態と同様にして、端末装置２０が辞書ファイル及び機能選択ファイルを更新することも可能である。また、この場合において、辞書ファイル及び機能選択ファイルをサーバ装置１０が記憶し、端末装置２０がサーバ装置１０に問い合わせて、機能選択ファイルを参照した処理を行うようにしてもよい。
【０１００】
［変形例４］
上述した各実施形態の機能提示システム１において、参照される辞書ファイルや機能選択ファイルが状況に応じて異なるようにしてもよい。
例えば、機能提示システム１において、端末装置２０のユーザのユーザ属性に応じて、参照される辞書ファイルや機能選択ファイルを異ならせてもよい。この場合、端末装置２０は、ユーザの性別や年齢、出身地、趣味等のユーザ属性を示す属性情報を、入力情報の送信時等にサーバ装置１０に送信する。サーバ装置１０の制御部１１（情報取得部１１１）は、ユーザ属性を示す属性情報を取得する。そして、制御部１１（特定部１１２）は、取得した属性情報が示すユーザ属性に対応した辞書ファイルを参照して、識別子を特定する。一方、端末装置２０の制御部１１（提示部２１２）は、ユーザ属性に対応した機能選択ファイルを参照して機能を提示する。このようにすれば、ユーザ属性に応じて利用機能の傾向が異なる場合であっても、この傾向を機能提示サービスへ反映させることが可能となる。
また、機能提示システム１において、辞書ファイルや機能選択ファイルをユーザ毎に異ならせるようにしてもよい。
【０１０１】
また、端末装置２０の位置に応じて、機能提示システム１で参照される辞書ファイルや機能選択ファイルを異ならせてもよい。例えば、端末装置２０のユーザが東京に居て大阪の情報を調べるときは、定番の観光地を調べることを希望する場合が多いと推定される。一方、端末装置２０のユーザが大阪に居て大阪の情報を調べるときは、電車の乗換案内を調べることを希望する場合が多いと推定される。このように、ある入力文字列に対する利用機能の傾向は、ユーザの居る場所に応じて異なることが考えられる。そこで、端末装置２０はＧＰＳ（Global Positioning System）測位や基地局測位等を行って自装置の位置を特定してサーバ装置１０に通知する。そして、サーバ装置１０及び端末装置２０は、この位置に応じた辞書ファイルや機能選択ファイルを選択して機能を提示するようにしてもよい。
【０１０２】
また、時刻に応じて、機能提示システム１で参照される辞書ファイルや機能選択ファイルを異ならせてもよい。例えば、昼間や夜間に「ハンバーグ」という登録文字列が含まれる入力文字列が使用された場合、ハンバーグを食べたいとユーザが考えていると推定されるので、カテゴリ「グルメ」の機能が好適であると推定される。一方、夕方に「ハンバーグ」という登録文字列が含まれる入力文字列が使用された場合、ハンバーグのレシピをユーザが調べたいと考えていて、カテゴリ「レシピ」の機能が好適であると推定される。そこで、サーバ装置１０はタイマの計時時刻から現在時刻を特定して、特定した現在時刻に応じた辞書ファイルを選択して参照する。端末装置２０においても、タイマの計時時刻から現在時刻を特定して、特定した時刻に応じた機能選択ファイルを選択して機能を提示するとよい。
また、端末装置２０の位置や時刻に応じて参照される辞書ファイルや機能選択ファイルを異ならせる構成は、カテゴリ優先度や重み係数を端末装置２０の位置や時刻に応じて変化させることでも実現可能である。
【０１０３】
［変形例５］
上述した各実施形態の機能提示システム１では、「カテゴリ優先度」や「機能優先度」という情報が存在していたが、本発明は、これらを扱うことを必須とするものではない。この場合であっても、端末装置２０では機能の提示を行うことは可能である。「カテゴリ優先度」がない構成であれば、端末装置２０は、第１識別子に基づいて特定した複数のカテゴリを平等に扱うが、例えば、機能選択ファイル２５１における記述順が先のカテゴリを、カテゴリ優先度が高いカテゴリと同じようにして扱ってもよい。また、「機能優先度」がない構成であれば、端末装置２０は、各カテゴリ内に属する複数機能を平等に扱うが、例えば、機能管理テーブル２５２における記述順が先の機能ほど、機能優先度が高い機能と同じようにして扱ってもよい。
【０１０４】
［変形例６］
また、端末装置２０は、ステップＳＡ９又はステップＳＢ９の処理で、ユーザからの指示なしに機能を実現していたが、これを実現しない構成であってもよい。この場合、制御部２１は機能実現部２１３に相当する機能を実現しなくてよい。このような場合、サーバ装置１０が、入力文字列に対して特定した識別子を端末装置２０に提供するものの、入力文字列については提供しない構成とすることも可能である。もちろん、機能実現部２１３が、ユーザからの指示なしに機能を実現する場合に入力文字列を用いないのであれば、サーバ装置１０が入力文字列を端末装置２０に提供しなくてもよい。
また、端末装置２０は、複数の機能の実現結果を機能提示画面において並べて提示できる場合、ユーザによる機能の実現指示を受け付けることなく、決められた条件を満たす複数機能を実現し、その結果を提示してもよい。この場合、例えば、端末装置２０は、カテゴリ優先度が閾値以上であるカテゴリに属する機能をすべて実現する。
【０１０５】
［変形例７］
上述した各実施形態では、サーバ装置１０が、入力文字列に含まれる登録文字列と、辞書ファイルに記述された登録文字列とが一致した場合に識別子を特定していたが、例えばいわゆる表記ゆれを考慮して、入力文字列に含まれる登録文字列「コンピュータ」に対し、辞書ファイルに辞書登録された登録文字列「コンピューター」の識別子を特定してもよい。また、サーバ装置１０は、略語の利用を考慮して、入力文字列に含まれる登録文字列「パソコン」に対し、辞書ファイルに辞書登録された登録文字列「パーソナルコンピュータ」の識別子を特定してもよい。このように、サーバ装置１０では、取得した入力文字列に対応する登録文字列の識別子を、辞書ファイルを参照して特定すればよい。
【０１０６】
［変形例８］
上述した各実施形態において、端末装置２０の入力情報は音声情報に限らない。入力情報は、端末装置２０の撮影装置で撮影された内容を示す画像情報であってもよい。この場合、例えば、文字列（例えば、手書き文字）が含まれる原稿が撮影装置で撮影される。サーバ装置１０の制御部１１は、文字認識辞書として用いられ、登録文字列に識別子を割り当てた辞書ファイルを参照して、画像情報である入力情報を認識し、認識した入力文字列とこの入力文字列に対応する登録文字列の識別子とを特定する。
このように、入力情報が辞書ファイルを参照して入力文字列を認識できる情報であり、かつ、この辞書ファイルにおいて登録文字列に識別子が割り当てられていれば、サーバ装置１０は、入力文字列を得た後に識別子を特定するためのデータベース参照に係る処理を必要としない。よって、上述した各実施形態と同様、入力情報が端末装置２０に入力されてから機能提示までに要する時間の増大が抑えられる。
【０１０７】
また、ユーザによりＵＩ部２４が操作されて、文字情報が入力情報として端末装置２０に入力されてもよい。この場合、端末装置２０は、入力情報として入力文字列を受け付けて、この入力文字列をサーバ装置１０に提供することとなる。このような場合、識別子の特定に用いられる辞書ファイルは、入力情報の認識に用いられる辞書でなくてよい。このように、サーバ装置１０が、入力情報を認識して入力文字列を特定する機能を有していなくてよい。
また、入力情報が音声情報である場合であっても、端末装置２０に実装された音声認識機能を用いて端末装置２０が音声認識を行って入力文字列を特定し、これをサーバ装置１０に提供してもよい。また、端末装置２０及びサーバ装置１０以外の装置（例えば、汎用の音声認識サーバ）によって音声認識が行われてもよい。
【０１０８】
［変形例９］
また、第１識別子及び第２識別子は、それぞれ登録文字列の分類を識別するものであればよいから、通し番号や無意味文字によって表されてもよい。
また、上述した各実施形態の機能提示システム１では、１つのカテゴリに複数の機能が属していたが、１つのカテゴリに１つの機能が属していてもよい。この場合、本発明の機能の種類は、必然的に機能そのものに対応することとなる。
また、端末装置２０における機能の提示の態様は、アイコン画像の表示に限らず、「検索サイトＡ」という文字列を表示する等、別の態様であってもよい。また、端末装置２０は、提示結果から機能の実現を指示できる態様で表示するのではなく、機能の通知のみを目的とした提示を行ってもよい。
また、サーバ装置１０の制御部１１や端末装置２０の制御部２１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の協働によって実現されうる。
【符号の説明】
【０１０９】
１…機能提示システム、１０…サーバ装置、１１…制御部、１１１…情報取得部、１１２…特定部、１１３…送信制御部、１１４…更新データ取得部、１１５…第１更新部、１２…通信部、１３…記憶部、１３１，１３１ａ，１３１ｂ…辞書ファイル、１３２…重み付け更新テーブル、２０…端末装置、２１…制御部、２１１…識別子取得部、２１２…提示部、２１３…機能実現部、２１４…更新データ取得部、２１５…第２更新部、２２…音声入出力部、２３…無線通信部、２４…ＵＩ部、２５…記憶部、２５１，２５１ａ，２５１ｂ…機能選択ファイル、２５２…機能管理テーブル
【技術分野】
【０００１】
本発明は、ユーザによる機能選択を支援する技術に関する。
【背景技術】
【０００２】
ユーザから受け付けた入力文字列を基に、ユーザが利用を希望する機能を推定する技術がある。特許文献１は、入力文字列を解析して金額や電話番号等の文字列の種別を判断し、判断した種別に応じたアプリケーションプログラムを自動で起動することを開示している。特許文献２は、検索入力文を構文解析して、複数の検索エンジンの中から、特定の分野に特化した望ましい検索エンジンを選択し、選択した検索エンジンを用いて情報検索を行うことを開示している。
【０００３】
特許文献３は、文字列とその文字列の属性との対応関係を記述した複数のデータテーブルを参照して、入力文字列の属性を決定し、決定した文字列の属性と検索方法との対応関係を記述したデータテーブルを参照して、入力文字列の属性に対応した最適な検索方法を決定することを開示している。特許文献３に記載された発明は、入力文字列に含まれる各文字列の属性を決定する際、文字列属性確定順位に従って一の文字列に一の属性を順次決定し、確定済みの文字列の属性とは重複しないように各文字列の属性を決定するものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−１５４０６９号公報
【特許文献２】特開２００３−１３２０６０号公報
【特許文献３】特開２００９−２６６２０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、特許文献１から特許文献３に記載された発明は、いずれも、ユーザにとって最適な機能を択一的に推定することにより、ユーザに強いられる機能選択に関する負担を減らすことができるものである。しかしながら、スマートフォンや携帯電話端末等の、多くの機能を実現可能な端末装置では、ユーザの希望する機能を１つに絞り込んで推定することが難しい場合があると考えられる。例えば、地名である「横浜」という文字列が入力文字列に含まれる場合、ユーザが現在位置から横浜までの電車での行き方を知りたいときには、電車の乗換案内を提供する機能がユーザにとって最適な機能であるし、ユーザが横浜にある飲食店に関する情報を知りたいときには、グルメ情報を提供するＷｅｂサイトを表示するためのブラウザ機能がユーザにとって最適な機能であるし、ユーザが横浜周辺の地理を知りたいときには、地図機能がユーザにとって最適な機能であると考えられる。また、グルメ情報を提供するＷｅｂサイトに様々なものがあるように、ユーザの利用目的を達成することができる機能が複数存在する場合がある。この場合、ユーザが利用したい機能はその時時で異なることも考えられる。特許文献１から特許文献３に記載された発明は、ユーザによる利用の可能性を考慮して積極的に複数の機能を提示する、という技術思想の下でなされたものでない。
そこで、本発明は、入力文字列を基に複数機能を提示して、ユーザによる機能選択を支援することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決するため、本発明の機能提示システムは、入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する第１記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを備えることを特徴とする。
【０００７】
本発明において、前記第１記憶部は、前記入力情報の認識に用いられ、登録文字列に前記識別子を割り当てた辞書ファイルを記憶し、前記特定部は、前記辞書ファイルを参照して、前記入力情報を認識し、認識した入力文字列と、当該入力文字列に対応する登録文字列の前記識別子とを特定するようにしてもよい。
本発明において、前記第１記憶部は、少なくとも一部の登録文字列について複数の前記識別子を記憶し、前記特定部は、前記入力文字列に含まれる一の登録文字列の前記識別子が前記第１記憶部に複数記憶されている場合、当該複数の前記識別子を特定するようにしてもよい。
【０００８】
本発明において、前記識別子は、前記登録文字列の意味に基づく分類を示し、前記第２記憶部は、前記識別子と、提示対象となる前記機能の種類とを対応付けて記憶し、前記提示部は、前記特定部が特定した識別子に対応付けて前記第２記憶部に記憶された種類の機能を、前記提示方法で複数提示するようにしてもよい。
また、本発明において、前記識別子は、前記登録文字列に対して定められた前記機能の種類を前記分類として示し、前記第１記憶部は、前記機能の種類に対して与えられた重み付けを前記識別子に対応付けて記憶し、前記特定部は、前記第１記憶部を参照して、前記識別子と、当該識別子が示す前記機能の種類に対する重み付けとを特定し、前記提示部は、前記特定部が特定した識別子と重み付けとに応じて、前記提示方法で複数機能を提示するようにしてもよい。
また、本発明において、前記識別子として、前記登録文字列の意味に基づく分類を示す第１識別子と、前記登録文字列の分類として前記登録文字列に対して定められた前記機能の種類を示す第２識別子とがあり、前記第１記憶部は、前記登録文字列毎に、前記第１識別子、前記第２識別子、及び当該第２識別子が示す前記機能の種類に対して与えられた重み付けを記憶し、前記提示部は、前記第２記憶部を参照して、前記特定部が特定した前記第１識別子、又は前記特定部が特定した第２識別子と重み付けとに応じて、前記提示方法で複数機能を提示するようにしてもよい。
【０００９】
本発明において、前記提示部は、前記入力文字列に対応する登録文字列の表記方法に応じて、前記提示方法を異ならせるようにしてもよい。
【００１０】
本発明において、前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第１記憶部の記憶内容を更新する第１更新部を備えるようにしてもよい。
また、本発明において、前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第２記憶部の記憶内容を更新する第２更新部を備えるようにしてもよい。
【００１１】
本発明において、前記提示部が提示した前記機能のうち決められた条件を満たす機能を実現する機能実現部を備え、前記提示部は、前記特定部が特定した識別子に応じて提示対象となる複数機能と、前記機能実現部が機能を実現した結果とを提示するようにしてもよい。
【００１２】
また、本発明の機能提示システムは、サーバ装置と端末装置とを備える機能提示システムであって、前記サーバ装置は、前記端末装置と通信する第１通信部と、前記端末装置の入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する第１記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、前記特定部が特定した識別子を前記端末装置に送信するよう、前記第１通信部を制御する送信制御部と、を有し、前記端末装置は、前記サーバ装置と通信する第２通信部と、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、前記第２通信部により前記サーバ装置から受信した前記識別子を取得する識別子取得部と、前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを有することを特徴とする。
【００１３】
本発明の端末装置は、サーバ装置と通信する通信部と、自端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子が前記サーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得部と、前記識別子と、提示対象となる機能との関係を記憶する記憶部と、前記記憶部を参照して、前記識別子取得部が取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部とを備えることを特徴とする。
【００１４】
本発明のサーバ装置は、自サーバ装置から受信した識別子に応じた機能を複数提示する端末装置と通信する通信部と、前記端末装置の入力情報を取得する情報取得部と、登録文字列の分類を示す識別子を記憶する記憶部と、前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記記憶部を参照して特定する特定部と、前記特定部が特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御部とを備えることを特徴とする。
【００１５】
本発明のプログラムは、通信部を有する端末装置のコンピュータに、前記端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子がサーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得ステップと、前記識別子と、提示対象となる機能との関係を記憶する記憶部を参照して、前記識別子取得ステップで取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップとを実行させるためのものである。
【００１６】
本発明のプログラムは、通信部を有するサーバ装置のコンピュータに、当該サーバ装置から受信した識別子に応じた機能を複数提示する端末装置の入力情報を取得する情報取得ステップと、登録文字列の分類を示す識別子を記憶する記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、前記特定ステップで特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御ステップとを実行させるためのものである。
【００１７】
本発明の機能提示方法は、入力情報を取得する情報取得ステップと、登録文字列の分類を示す識別子を記憶する第１記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、前記識別子と、提示対象となる機能との関係を記憶する第２記憶部を参照して、前記特定ステップで特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップとを有することを特徴とする。
【発明の効果】
【００１８】
本発明によれば、入力文字列を基に複数機能を提示して、ユーザによる機能選択を支援することができる。
【図面の簡単な説明】
【００１９】
【図１】機能提示システムの全体構成を示す図。
【図２】サーバ装置の構成を示すブロック図。
【図３】第１実施形態に係る辞書ファイルの構成を示す図。
【図４】端末装置の構成を示すブロック図。
【図５】同実施形態に係る機能選択ファイルの構成を示す図。
【図６】機能管理テーブルの構成を示す図。
【図７】同実施形態に係るサーバ装置の制御部の機能的構成を示すブロック図。
【図８】同実施形態に係る端末装置の制御部の機能的構成を示すブロック図。
【図９】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図１０】機能提示画面を示す図。
【図１１】機能提示画面を示す図。
【図１２】第２実施形態に係る辞書ファイルの構成を示す図。
【図１３】同実施形態に係る機能選択ファイルの構成を示す図。
【図１４】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図１５】第３実施形態に係る辞書ファイルの構成を示す図。
【図１６】同実施形態に係る機能選択ファイルの構成を示す図。
【図１７】重み付け更新テーブルの構成を示す図。
【図１８】第４実施形態に係るサーバ装置の制御部の機能的構成を示す機能ブロック図。
【図１９】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２０】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２１】第５実施形態に係る端末装置の制御部の機能的構成を示す機能ブロック図。
【図２２】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２３】同実施形態に係る機能提示システムの動作を示すシーケンスチャート。
【図２４】変形例１に係る端末装置の動作を示すフローチャート。
【図２５】機能提示システムの機能的構成を示すブロック図。
【発明を実施するための形態】
【００２０】
以下、図面を参照しつつ本発明の実施形態を説明する。
［第１実施形態］
図１は、機能提示システム１の全体構成を示す図である。
機能提示システム１は、端末装置２０で実現可能な機能の中から、端末装置２０のユーザが利用を希望する機能を推定して提示するサービス（以下、「機能提示サービス」という。）を提供するためのシステムである。図１に示すように、機能提示システム１は、サーバ装置１０と、端末装置２０とを備えている。サーバ装置１０と端末装置２０とは、ネットワークＮＷ経由で互いに通信可能に接続されている。ネットワークＮＷは、ここでは、移動体通信網、ゲートウェイ及びインターネットを含む通信網である。
【００２１】
端末装置２０は、ここではスマートフォンであり、音声（端末装置２０のユーザが発する声を想定する。）を検出し、検出した音声を基に機能提示サービスで推定された機能を提示する。サーバ装置１０は、端末装置２０で検出された音声を認識する音声認識サーバとして機能する一方で、音声認識の結果に基づいて機能提示サービスの提供を支援する。
なお、端末装置２０は、スマートフォンに限らず、例えば携帯電話端末やパーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）等の通信機能を有する端末装置であってもよい。また、図１には、端末装置２０を１つだけ図示しているが、実際にはより多数の端末装置２０が機能提示システム１に含まれる。
【００２２】
図２は、サーバ装置１０の構成を示すブロック図である。図２に示すように、サーバ装置１０は、制御部１１と、通信部１２と、記憶部１３とを備える。
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）を備えるマイクロコンピュータである。ＣＰＵは、ＲＯＭや記憶部１３に記憶されたプログラムをＲＡＭに読み出して実行することにより、サーバ装置１０の各部を制御する。通信部１２は、ネットワークＮＷに接続するためのインタフェースである（第１通信部）。記憶部１３は、例えばハードディスク装置を備える、辞書ファイル１３１及び制御部１１により実行される各種プログラムを含むデータを記憶する（第１記憶部）。辞書ファイル１３１は、音声認識に用いられる音声認識辞書であるとともに、以下に説明する構成を有する辞書ファイルである。
【００２３】
図３は、辞書ファイル１３１の構成を示す図である。辞書ファイル１３１では、辞書登録された登録文字列に、その登録文字列の意味に基づく分類を示す識別子が対応付けてられている。
図３に示すように、辞書ファイル１３１は、「登録文字列」と「第１識別子」との各フィールドに記述された情報を対応付けたデータテーブルを含む。「登録文字列」のフィールドには、辞書ファイル１３１に登録された文字列が記述されている。登録文字列は、典型的には単語であるが、複合語等の任意の文字列（例えば、情報検索に用いられる検索語）を含みうる。また、登録文字列は、漢字、平仮名、片仮名、アルファベット等の、どのような文字で構成されてもよい。「第１識別子」のフィールドには、登録文字列の意味に基づく分類を示す識別子が記述される。第１識別子は、登録文字列の意味（又は概念）に応じて予め決められた分類に従って、各登録文字列に割り当てられている。例えば、登録文字列「表参道」の第１識別子は「地名」であり、登録文字列「会議」の第１識別子は「行事」である。
また、辞書ファイル１３１では、一の登録文字列に複数の第１識別子が割り当てられることもある。登録文字列「品川」の第１識別子は、「地名，人名」（地名及び人名）である。これは「品川」という文字列が、地名としても解釈しうるし、人名（詳しくは、人の姓）しても解釈しうることによるものである。辞書ファイル１３１には、少なくとも一部の登録文字列について、複数の第１識別子が記述されている。
なお、図３に示す登録文字列及び第１識別子は一例であり、実際には、より多数の組み合わせが辞書ファイル１３１に記述されている。例えば、「人名」を更に細分化して、「芸能人名」や「作家名」、「スポーツ選手名」等の第１識別子が用いられてもよい。また、辞書ファイル１３１に辞書登録されたすべての登録文字列に、第１識別子が割り当てられているとは限らない。
【００２４】
図４は、端末装置２０の構成を示すブロック図である。図４に示すように、端末装置２０は、制御部２１と、音声入出力部２２と、無線通信部２３と、ＵＩ（User Interface）部２４と、記憶部２５とを備える。
制御部２１は、ＣＰＵ、ＲＯＭ、及びＲＡＭを備えるマイクロコンピュータである。ＣＰＵは、ＲＯＭや記憶部２５に記憶されたプログラムをＲＡＭに読み出して実行することにより、端末装置２０の各部を制御する。音声入出力部２２は、受話音声等を収音するマイクロホンと送話音声を放音するスピーカとを備え、音声の入出力に関する機能を実現する。音声入出力部２２は、マイクロホンによって端末装置２０のユーザが発した音声を検出し、音声の検出結果を制御部２１に出力する。無線通信部２３は、無線通信回路やアンテナを備え、ネットワークＮＷに無線通信により接続するためのインタフェースである（第２通信部）。ＵＩ部２４は、画像を表示する表示面と、表示面に重ねられたタッチパネルとを備え、ＧＵＩ（Graphical User Interface）を提供するものである。すなわち、ＵＩ部２４は、タッチパネルによりユーザからの操作を受け付ける操作部と、表示面に表示する画像により情報を報知する表示部としての双方の機能を実現する。
なお、端末装置２０において、操作部と表示部とがそれぞれ独立したハードウェアで実現されてもよい。
【００２５】
記憶部２５は、例えばＥＥＰＲＯＭ（Electronically Erasable and Programmable ROM）を備え、機能選択ファイル２５１、機能管理テーブル２５２及び各種のアプリケーションソフトウェアを含むデータを記憶する（第２記憶部）。制御部２１は、例えば、記憶部２５が記憶するアプリケーションソフトウェアを実行することにより、端末装置２０における機能を実現する。記憶部２５が記憶するアプリケーションソフトウェアは、例えば、メーラやＷｅｂブラウザ、地図を表示するための地図アプリ、動画ファイルを再生するための動画アプリ等を含むが、どのようなアプリケーションソフトウェアを含んでいてもよい。また、これらのアプリケーションソフトウェアは、端末装置２０にプリインストールされたものや、ユーザによって端末装置２０にインストールされたものを含む。
なお、アプリケーションソフトウェアには、そのアプリケーションソフトウェアの実行をユーザが端末装置２０に指示する際に、ユーザが指定するアイコン画像を表示するためのアルゴリズムが記述されている。
【００２６】
端末装置２０で実現可能な機能は、端末装置２０が必要な情報処理を実行することにより実現され、機能毎に少なくとも情報処理の内容の一部が異なる。例えば、Ｗｅｂブラウザの実行により実現される機能であっても、アクセス先のＵＲＬ（Uniform Resource Locator）が異なれば、それぞれ異なる機能として区別される。
なお、端末装置２０で各機能の実現に必要な情報（アクセス先のＵＲＬ等）は、記憶部２５に記憶されている。制御部２１はその情報を用いた情報処理を実行して、各機能を実現する。
【００２７】
図５は、機能選択ファイル２５１の構成を示す図である。機能選択ファイル２５１は、第１識別子と、提示対象となる機能との関係を記憶するデータである。
図５に示すように、機能選択ファイル２５１は、「第１識別子」と、「カテゴリ」と、「カテゴリ優先度」との各フィールドに記述された情報を対応付けたデータテーブルである。「第１識別子」のフィールドには、辞書ファイル１３１に記述されたものと共通する第１識別子が、１又は複数の組み合わせで記述されている。「カテゴリ」のフィールドには、端末装置２０で実現可能な機能の種類として、機能が属するカテゴリが記述されている。「カテゴリ優先度」のフィールドには、カテゴリに対する優先度が記述されている。カテゴリ優先度は、詳しくは後述するが、機能提示サービスの提供において参照される優先度である。カテゴリ優先度は、ここでは「０．０」以上「１．０」以下の値であり、その値が大きいほど優先度が高いことを示す。
【００２８】
機能選択ファイル２５１には、例えば、第１識別子「地名＋食品」（地名及び食品）に対応付けて、カテゴリ「グルメ」及びカテゴリ優先度「０．６」と、カテゴリ「買い物」及びカテゴリ優先度「０．４」とが記述されている。このように、機能選択ファイル２５１では、複数の第１識別子の組み合わせに対応してカテゴリ及びカテゴリ優先度が記述されていることがある。また、機能選択ファイル２５１には、第１識別子「地名」に対応付けて、カテゴリ「地図」及びカテゴリ優先度「０．８」と、カテゴリ「グルメ」及びカテゴリ優先度「０．２」とが記述されている。機能選択ファイル２５１では、第１識別子が示す登録文字列の意味と関連が深いカテゴリが当該弟１識別子に対応付けられ、例えば、その関連が深いほどカテゴリ優先度が高い。
また、複数の第１識別子の組み合わせは、「地名＋地名」のように、同一の第１識別子を複数含んでいてもよい。第１識別子「地名＋地名」には、カテゴリ「乗換案内」が対応付けられている。これは入力文字列に地名を意味する登録文字列が２つ含まれているということは、例えば、ユーザが電車での乗換を調べるために、出発地点と到着地点とを指定した可能性が考えられることによるものである。
なお、図５に示す第１識別子、カテゴリ及びカテゴリ優先度は一例であり、実際には、より多数の組み合わせが機能選択ファイル２５１に記述されている。ただし、機能選択ファイル２５１は、一の第１識別子の組み合わせについて、カテゴリ優先度の総和が「１．０」となるように構成されている。また、どのカテゴリにどの機能が属するかについては、機能提示システム１の設計段階等で決められる。
以上の構成を有する機能選択ファイル２５１は、詳しくは後述するが、所定の提示方法で提示する機能を選択する際に、端末装置２０により参照されるデータである。
【００２９】
図６は、機能管理テーブル２５２の構成を示す図である。機能管理テーブル２５２は、端末装置２０が実現可能な機能と、当該機能が属するカテゴリとの対応関係が記述されたデータテーブルである。
図６に示すように、機能管理テーブル２５２では、「カテゴリ」と、「機能」と、「機能優先度」との各フィールドに記述された情報が対応付けられている。「カテゴリ」のフィールドには、機能選択ファイル２５１に記述されたものと共通する情報が記述されている。「機能」のフィールドには、端末装置２０で実現可能な機能を識別する情報が記述されている。例えば、「機能」のフィールドに「サイト」と記述された機能は、Ｗｅｂブラウザの実行により実現される。「機能優先度」のフィールドには、機能に対する優先度が記述されている。機能優先度は、詳しくは後述するが、機能提示サービスにおける機能の提示の際に参照される優先度である。機能優先度は、ここではカテゴリ毎に独立して各機能に割り当てられた優先順位であり、その値が小さいほど優先度が高いことを意味する。機能優先度が設定されていない機能（図６で「−」（ハイフン）で示した機能）は、端末装置２０で実現可能であるものの、機能提示サービスでは提示の対象とならないものとする。
以上の機能管理テーブル２５２の機能優先度は、ユーザ設定等に応じて端末装置２０により更新されてもよい。また、機能管理テーブル２５２において全ての機能に機能優先度が設定されていてもよい。
続いて、機能提示システム１の機能的構成を説明する。
【００３０】
図７は、サーバ装置１０の制御部１１の機能的構成を示す機能ブロック図である。図７に示すように、制御部１１は、プログラムを実行することにより、情報取得部１１１と、特定部１１２と、送信制御部１１３とに相当する機能を実現する。
情報取得部１１１は、通信部１２の通信により、端末装置２０の入力情報を取得する。入力情報は、例えば端末装置２０で検出された音声（例えば、音声波形）を示す音声情報である。
特定部１１２は、辞書ファイル１３１を参照して、情報取得部１１１が取得した入力情報が示す入力文字列と、当該入力文字列に対応する登録文字列の第１識別子とを特定する。入力情報が音声情報である場合、特定部１１２は、辞書ファイル１３１を参照して、音声情報を認識し、認識した入力文字列とこの入力文字列に対応する登録文字列の第１識別子とを特定する。特定部１１２は、入力文字列に含まれる登録文字列に対応付けられた１又は複数の第１識別子を、登録文字列毎に辞書ファイル１３１からすべて特定する。入力文字列は、ここではテキストコードで表される。
送信制御部１１３は、入力文字列と、入力文字列に対応する登録文字列について特定部１１２が特定した第１識別子との組を端末装置２０に送信するよう、通信部１２を制御する。
【００３１】
図８は、端末装置２０の制御部２１の機能的構成を示す機能ブロック図である。図８に示すように、制御部２１は、プログラムを実行することにより、識別子取得部２１１と、提示部２１２と、機能実現部２１３とに相当する機能を実現する。
識別子取得部２１１は、送信制御部１１３の制御によりサーバ装置１０から送信され無線通信部２３により受信された入力文字列と、入力文字列に対応する登録文字列の第１識別子との組を取得して、ここから第１識別子を取得する。
提示部２１２は、機能選択ファイル２５１及び機能管理テーブル２５２を参照して、識別子取得部２１１が取得した第１識別子に応じて提示対象となる機能を、所定の提示方法で複数提示する。例えば、提示部２１２は、識別子取得部２１１が取得した第１識別子に応じて提示対象となる機能を、他の機能よりも優先させてＵＩ部２４への表示により提示する。
なお、識別子取得部２１１が取得した第１識別子は、特定部１１２が特定した第１識別子と同一である。
【００３２】
機能実現部２１３は、提示部２１２が提示する機能のうち決められた条件を満たす機能を実現する。例えば、機能実現部２１３は、提示部２１２が提示する機能のうちのいずれか１つの機能を、ユーザからの当該機能の実現指示を受け付けることなく実現する。提示部２１２は、提示対象となる複数機能と、機能実現部２１３が機能を実現した結果とを提示する。
機能実現部２１３は、端末装置２０における機能の実現に関する制御を司るものであり、例えば、ＵＩ部２４の操作や音声入力によって機能の実現がユーザに指示された場合に、当該機能を実現する。また、例えばユーザによっては自動で機能の実現が開始することを希望しない場合もあると考えられるため、機能実現部２１３は、提示部２１２により提示された機能を用いてユーザからの実現指示を受け付けた場合に、その指示に応じて機能を実現するものであってもよい。また、機能実現部２１３は、入力文字列の全部又は一部を利用して機能を実現する場合もあれば、入力文字列を用いないで機能を実現する場合もある。
次に、機能提示システム１の動作を説明する。
【００３３】
図９は、機能提示システム１の動作を示すシーケンスチャートである。
端末装置２０の制御部２１は、ユーザによりＵＩ部２４が操作されて機能提示サービスの利用が指示されると、音声入力の受付を開始する。端末装置２０のユーザは自身が利用したい機能に関する言葉を発する。ここで、ユーザは、品川区にあるラーメン店に関する情報を調べたいと考え、「品川」という言葉と、「ラーメン」という言葉とを発したとする。制御部２１は、音声入出力部２２により「品川」、「ラーメン」というユーザの発声に応じて音声入力を受け付けて、この音声を示す音声情報を入力情報として受け付ける（ステップＳＡ１）。
【００３４】
端末装置２０の制御部２１は、音声情報である入力情報をサーバ装置１０に送信するよう、無線通信部２３を制御する（ステップＳＡ２）。
【００３５】
サーバ装置１０の制御部１１は、通信部１２によるサーバ装置１０との通信により音声情報である入力情報を取得する（ステップＳＡ３）。次に、制御部１１は、辞書ファイル１３１を参照して、音声情報を認識し（ステップＳＡ４）、認識した入力文字列と当該入力文字列に対応する登録文字列の第１識別子とを特定する（ステップＳＡ５）。図３に示すように、辞書ファイル１３１において、登録文字列「品川」に第１識別子「地名，人名」が割り当てられ、登録文字列「ラーメン」に第１識別子「食品」が割り当てられている。よって、制御部１１は、「品川＜地名，人名＞」及び「ラーメン＜食品＞」というデータを得る。
なお、「ＡＡ＜ＢＢ＞」という形式のデータは、入力文字列に含まれる登録文字列「ＡＡ」の第１識別子が「ＢＢ」であることを意味する。このデータ形式は一例であり、登録文字列と第１識別子との関係が明らかであれば、これ以外のデータ形式が採用されてもよい。
【００３６】
次に、制御部１１は、入力文字列と、入力文字列に含まれる登録文字列について特定した第１識別子との組を端末装置２０に送信するよう、通信部１２を制御する（ステップＳＡ６）。
【００３７】
端末装置２０の制御部２１は、入力文字列と、入力文字列に含まれる登録文字列の第１識別子との組を無線通信部２３によって受信すると、ここから第１識別子を取得する（ステップＳＡ７）。制御部１１は、「品川＜地名，人名＞」及び「ラーメン＜食品＞」というデータをサーバ装置１０から取得したから、ここでは、第１識別子として「地名，人名＋食品」を取得する。
なお、ここでは、各登録文字列から特定された第１識別子が「＋」を用いて区別される。
【００３８】
次に、制御部２１は、機能選択ファイル２５１を参照して、ステップＳＡ７の処理で取得した第１識別子に応じて提示対象となる機能が属するカテゴリを選択する（ステップＳＡ８）。
ここで、制御部２１は、機能選択ファイル２５１において、第１識別子「地名，人名＋食品」と一致する第１識別子に対応付けられたカテゴリを選択する。この選択の際、制御部２１は、第１識別子が部分一致したテゴリよりも、完全一致したカテゴリを優先させる。ここでの完全一致は、サーバ装置１０で特定された第１識別子の組み合わせが、機能選択ファイル２５１に記述されていることを意味する。また、部分一致は、サーバ装置１０で特定された第１識別子の組み合わせの一部を構成する第１識別子が、機能選択ファイル２５１に記述されていることを意味する。ここでは、図５に示すように、サーバ装置１０で特定された第１識別子「地名，人名＋食品」に完全一致する第１識別子として、「地名＋食品」が機能選択ファイル２５１に記述されている。また、サーバ装置１０で特定された第１識別子「地名，人名＋食品」に部分一致する第１識別子として、「地名」が機能選択ファイル２５１に記述されている。
よって、制御部２１はカテゴリ「グルメ」、「買い物」及び「地図」を選択し、各カテゴリ優先度をそれぞれ「０．６」、「０．４」、「０．８」と特定する。
なお、カテゴリ「グルメ」は、第１識別子「地名＋食品」と、第１識別子「地名」とで選択されるが、この場合、制御部２１はカテゴリ優先度が高い方を採用するとよい。
【００３９】
次に、制御部２１は、ステップＳＡ８の処理で選択したカテゴリに属する、決められた条件を満たす機能を実現する（ステップＳＡ９）。ここでは、制御部２１は、サーバ装置１０で特定された第１識別子と機能選択ファイル２５１に記述された第１識別子との一致数、カテゴリ優先度、及び機能優先度に応じて定まる１つの機能を、ユーザからの機能の実現指示を受け付けることなく実現する。制御部２１は、第１識別子の一致数が最も多く、且つ、カテゴリ優先度及び機能優先度がそれぞれ最も高い機能を実現する。既に説明したとおり、ここでは、第１識別子の一致数が最も多いカテゴリは「グルメ」及び「買い物」であるが、カテゴリ優先度が最も高いカテゴリは「グルメ」である。そして、カテゴリ「グルメ」に属する機能のうち、機能優先度が最も高い機能は、「グルメサイトＡ」である。よって、制御部２１は、「グルメサイトＡ」について、「品川」及び「ラーメン」を検索語として用いて情報検索を行う。
なお、この場合において、制御部２１は入力文字列に対応する登録文字列のすべてを用いてもよいし、一部の登録文字列を用いてもよい。また、制御部２１は、入力文字列の全体を用いて機能を実現してもよいし、入力文字列を用いないで機能を実現してもよい。
【００４０】
次に、制御部２１は、ステップＳＡ８の処理で選択したカテゴリに属する複数機能を所定の提示方法で提示するとともに、ステップＳＡ９の処理に応じた機能の実現結果を提示する（ステップＳＡ１０）。ここでは、制御部２１は、図６に示す機能管理テーブル２５２で機能優先度が設定されたすべての機能を提示対象とし、更に、ステップＳＡ８の処理で選択したカテゴリに属する機能であって、第１識別子に応じて提示対象となった機能を、他の機能よりも優先させて提示する。ステップＳＡ８の処理で、制御部２１は、「グルメ」、「買い物」及び「地図」という３つのカテゴリを選択したので、「グルメサイトＡ」〜「グルメサイトＣ」→「買い物サイトＡ」→「買い物サイトＣ」→「地図アプリ」という順で、これら７つの機能を他の機能よりも優先させて提示する。具体的には、制御部２１は、第１識別子に応じて提示対象となった機能に対応するアイコン画像を、サーバ装置１０で特定された第１識別子と機能選択ファイル２５１に記述された第１識別子との一致数、カテゴリ優先度、及び機能優先度に応じた態様で配置するとともに、ステップＳＡ９の処理で機能を実現した結果を配置した機能提示画面を、ＵＩ部２４に表示させる。制御部２１は、アイコン画像がＵＩ部２４の操作によりユーザに指定されたことを契機に、そのアイコン画像に対応する機能を実現する。
【００４１】
図１０は、機能提示画面を示す図である。
図１０において、アイコン画像Ｉ１〜Ｉ７は、それぞれ、他の機能よりも優先させて提示される機能に対応するアイコン画像である。機能提示画面が表示されたとき、アイコン画像Ｉ１〜Ｉ４は表示面に表示されているので、ユーザは画面を遷移させるための操作をＵＩ部２４に行うことなく、これらのアイコン画像を視認し、指定することが可能である。一方で、破線で示したアイコン画像Ｉ５〜Ｉ７は、機能提示画面が表示されたときには表示面に表示されず、ユーザが画面を遷移させるための操作（例えば、フリック操作）をＵＩ部２４に行うことで表示面に表示される。これらのアイコン画像Ｉ１〜Ｉ７は、第１識別子の一致数が多い順→カテゴリ優先度が高い順→機能優先度が高い順となるように配置される。すなわち、アイコン画像Ｉ１〜Ｉ７は、順に、「グルメサイトＡ」〜「グルメサイトＣ」→「買い物サイトＡ」〜「買い物サイトＣ」→「地図アプリ」という配置となる。よって、ユーザにしてみれば、第１識別子の一致数が多い機能、カテゴリ優先度が高い機能、又は機能優先度が高い機能のアイコン画像ほど、より少ない操作量の操作で指定することが可能である。
【００４２】
また、制御部２１は、アイコン画像Ｉ７よりも更に図中右側に、すなわち、アイコン画像Ｉ１〜Ｉ７よりもアイコン画像を表示させるための操作量が多くなる位置に、機能管理テーブル２５２で機能優先度が設定された、残りのすべての機能のアイコン画像を表示させる。このようにして制御部２１は、第１識別子に応じて提示対象となる機能以外の機能については、カテゴリ優先度及び機能優先度とは無関係にアイコン画像を配置する。例えば、制御部２１は、機能管理テーブル２５２における機能の記述順と同じになるようなアイコン画像の配置としてもよいし、設計段階等で予め決められた配置としてもよいし、ユーザによる過去の利用履歴を反映させた配置（例えば、利用回数や利用頻度が高い機能ほど、アイコン画像を図中左側に表示させる）としてもよい。ここでは、制御部２１は、第１識別子に応じて提示対象となった機能のみについて、第１識別子の一致数、カテゴリ優先度及び機能優先度に従って提示する。
なお、制御部２１は、第１識別子に応じて提示対象となった機能のみを提示し、それ以外の機能を提示しない、という提示方法を採用してもよい。この場合、アイコン画像Ｉ１〜Ｉ７のみが機能提示画面で表示される。要するに、制御部２１は、予め決められた提示方法に従って、第１識別子に応じて提示対象となった機能を少なくとも提示すればよい。
また、機能提示画面のアイコン画像と同時に、アイコン画像の下側の領域に、制御部２１がステップＳＡ９の処理で実現した機能の実現結果が表示される。この機能の実現結果は、アイコン画像Ｉ１に対応する機能の実現結果となるはずであり、ここでは「グルメサイトＡ」である。これにより、ユーザは、機能提示システム１でユーザが最も強く利用を希望すると推定された機能の実現結果を、速やかに確認することができる。
【００４３】
以上説明した第１実施形態では、サーバ装置１０は、辞書ファイル１３１を参照して、端末装置２０の入力情報を認識し、入力文字列とこの入力文字列に対応する登録文字列の第１識別子とを特定する。そして、端末装置２０は、サーバ装置１０から提供された第１識別子と、機能選択ファイル２５１及び機能管理テーブル２５２とに応じて複数機能を提示する。このような機能提示システム１では、単にユーザにとって好ましいと思われる機能を択一的に推定し提示するのではなく、ユーザの端末装置２０の様々な利用目的の可能性に鑑みて、ユーザにとって有用と推定される機能の候補を複数提示する。また、端末装置２０は、第１識別子の一致数、カテゴリ優先度及び機能優先度に応じた態様で、機能提示画面を表示する。これにより、端末装置２０は、ユーザが利用を強く希望すると推定される機能ほど、ユーザに強いる操作負担を少なくして、選択した複数機能や機能の実現結果を提示することが可能である。
【００４４】
また、機能提示システム１では、構文解析等の複雑な解析処理を入力文字列に対して行わないで、音声認識に用いられる辞書ファイル１３１を参照して第１識別子を特定する。このように、機能提示システム１では、構文解析や、入力文字列を得た後に第１識別子を特定するためのデータベース参照に係る処理を必要としないので、入力情報が端末装置２０に入力されてから機能提示までに要する時間の増大が抑えられる。また、機能提示システム１では、この第１識別子の特定に多数のデータテーブルを参照することはなく、また、入力文字列に含まれる登録文字列の第１識別子はそれぞれ独立して特定されるので、他の登録文字列の第１識別子の確定状況の影響を受けない。よって、機能提示システム１では、入力文字列の各登録文字列の本来の意味を正確に反映させて、機能提示サービスを提供することができる。
【００４５】
＜第１実施形態の変形例＞
上述した第１実施形態の構成を、以下の（１−１）〜（１−６）で説明する構成に変形してもよい。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（１−１）機能提示システム１において、機能選択ファイル２５１に記述された第１識別子の組み合わせ（例えば、「地名＋食品」）の一部を構成する第１識別子が、サーバ装置１０で特定された場合（例えば、「地名」のみが特定された場合）に、これらが部分一致すると扱われてもよい。この場合、制御部２１は、部分一致した第１識別子に機能選択ファイル２５１で対応付けられたカテゴリについては、カテゴリ優先度を小さくするよう補正する。例えば、制御部２１は、部分一致したカテゴリについては、カテゴリ優先度を１／２にする。よって、入力文字列が「品川 ラーメン」のときには、制御部２１は、カテゴリ「グルメ」、「買い物」、及び「地図」について、カテゴリ優先度を「０．６」、「０．４」、「０．４」とする。
なお、制御部２１は、部分一致の程度に応じてカテゴリ優先度の補正の内容を異ならせてもよい。例えば、制御部２１は、一致度が低いほどカテゴリ優先度を大きく減じるように補正する。
【００４６】
（１−２）機能提示システム１が表示する機能提示画面を以下のように変形してもよい。
図１１は、機能提示画面の別の態様を示す図である。
提示対象のアイコン画像の数が多くなった場合、図１０に示す機能提示画面では、第１識別氏の一致数やカテゴリ優先度、機能優先度が相対的に低い機能のアイコン画像が表示されるまでに、ユーザに強いられる操作の量が多くなる。そこで、制御部２１は、図１１（ａ）に示す機能提示画面をまずＵＩ部２４に表示させる。ここで、アイコン画像Ｉ１〜Ｉ３は、図１０に示したアイコン画像と同じものである。制御部２１は、アイコン画像Ｉ１〜Ｉ３の右側に配置したアイコン画像Ｉｅｔｃがユーザにより指定されると、図１１（ｂ）に示す機能提示画面に遷移させる。ここでは、制御部２１は、機能の実現結果を表示させないで、ＵＩ部２４の表示面のほぼ全体を使ってアイコン画像を表示させる。これにより、図１０の機能提示画面よりも表示面に配置可能なアイコン画像が増えるので、カテゴリ優先度が低いカテゴリに属する機能のアイコン画像も、ユーザは指定しやすくなる。制御部２１は、図１１（ｂ）に示す機能提示画面では、図１０に示す機能提示画面の場合と同じ規則に従ってアイコン画像を配置してもよいし、この規則とは無関係にアイコン画像を配置してもよい。制御部２１は、図１１（ｂ）に示す機能提示画面でのアイコン画像の配置を任意のものとすることが可能である。
なお、制御部２１は、図１１（ａ）に示す機能提示画面において機能に対応するアイコン画像を表示させていたが、提示対象の機能が属するカテゴリに対応するアイコン画像を表示させてもよい。この場合、アイコン画像の配置は、第１識別子の一致数が多い→カテゴリ優先度が高い、という順にすればよい。制御部２１は、いずれかのカテゴリに対応するアイコン画像がユーザに指定されると、図１１（ｂ）示す機能提示画面において、指定されたカテゴリに属する各機能のアイコン画像を表示させるとよい。
なお、制御部２１は、提示対象の機能の数が閾値未満であれば、図１０に示すような機能提示画面を表示させ、提示対象の機能の数が閾値以上であれば、図１１に示すような機能提示画面を表示させてもよい。
なお、以上説明した機能提示画面におけるアイコン画像の配置の態様は一例であり、表示面で一度に表示されるアイコン数やそれらの配置位置などは、前掲の態様に限定されない。
【００４７】
（１−３）上述した第１実施形態の機能提示システム１において、端末装置２０の制御部２１は、アイコン画像Ｉ１に対応する機能をユーザの指示なしに実現し、それ以外の機能についてはユーザによりアイコン画像が指定されたことを契機に実現していた。これに代えて、制御部２１は、アイコン画像Ｉ２〜Ｉ７に対応する機能で、第１識別子に応じて提示対象となった機能のうち、ステップＳＡ９の処理で実現しなかった機能を、予めバックグラウンドで実現してもよい。この構成によれば、制御部２１は、アイコン画像がユーザに指定されたことを契機に、迅速にその実現結果を提示することができる。この場合において、制御部２１は、カテゴリ優先度や機能優先度が一定レベル以上高い（例えば、上位の３つ）機能など、アイコン画像を提示する機能のうちの一部の機能について、予めバックグラウンドで実現してもよい。
なお、バックグラウンドでの機能の実現の際、制御部２１は、Ｗｅｂブラウザの実行によるｗｅｂサイトの表示のように、通信を伴う機能については、アプリケーションソフトウェアを実行し、更に、その機能の実現に必要なデータをダウンロードしてキャッシュしておく。一方、制御部２１（機能実現部２１３）は、通信を伴う機能以外の機能については、アプリケーションソフトウェアをＲＡＭに読み出しておく。このバックグラウンドでの機能の実現については、制御部２１がアイコン画像が指定されてから対応する機能の実現を開始するよりも、機能の実現できるまでに要する時間を短くできればよいので、処理の内容は前掲のものに限定されない。制御部２１は、機能の実現に必要な情報処理の一部を予め実行しておけばよい。
【００４８】
（１−４）機能提示システム１において、辞書ファイル１３１に記述された第１識別子に、当該第１識別子が示す分類に対する重み係数が対応付けられていてもよい。この場合、機能提示システム１では、重み係数が大きい第１識別子をより重視する。例えば、登録文字列「品川」について、仮に、地名としての認知度が低く、人名として認知度が高いとした場合に、地名の重み係数を「０．３」とし、人名の重み係数を「１．０」とする。端末装置２０に第１識別子を送信する際、サーバ装置１０の制御部１１は、この第１識別子に重み係数を対応付けておく。端末装置２０は、第１識別子とともに重み係数を取得し、この第１識別子から特定したカテゴリのカテゴリ優先度に重み係数を作用させて（ここでは、乗算する）、最終的なカテゴリ優先度を算出する。
サーバ装置１０が第１識別子「地名」を特定した場合、以下のように端末装置２０は動作する。
【００４９】
端末装置２０の制御部２１は、地図のカテゴリ優先度「０．８」に、地名の重み係数「０．３」を乗算して、カテゴリ優先度「０．２４」を算出する。また、制御部２１は、グルメのカテゴリ優先度「０．２」に、地名の重み係数「０．３」を乗算して、カテゴリ優先度「０．０６」を算出する。また、制御部２１は、Ｗｅｂ検索のカテゴリ優先度「０．５」に、人名の重み係数「１．０」を乗算して、カテゴリ優先度「０．５」を算出する。このようにすれば、カテゴリ優先度は、「Ｗｅｂ検索」＞「地図」＞「グルメ」となる。一方、上述したような重み係数を用いない構成では、「Ｗｅｂ検索」のカテゴリ優先度が「０．５」となり、「地図」のカテゴリ優先度が「０．８」となり、「グルメ」のカテゴリ優先度が「０．２」となるので、カテゴリ優先度は「地図」＞「Ｗｅｂ検索」＞「グルメ」となり、端末装置２０で第１識別子に対する重み付けを用いた場合と異なる結果になる。
以上のように、機能提示システム１では、第１識別子に対応する重み付けの有無やその重み付けの程度によって、カテゴリの提示の態様を異ならせることも可能である。ここでは、登録文字列の意味としての認知度が高いほど、重み付けが大きくなるようにしていたが、これ以外の指標で重み付けが決められていてもよい。
【００５０】
（１−５）機能提示システム１において、機能の種類として、機能が属するカテゴリを用いていたが、機能そのものを用いてもよい。また、この場合において、端末装置２０では、機能選択ファイル２５１の内容と機能管理テーブル２５２の内容を一体化したデータを参照して、入力文字列から特定した第１識別子に応じて提示対象となる機能を特定することも可能である。
【００５１】
（１−６）機能提示システム１において、機能優先度をカテゴリ優先度のように数値化し、この値が大きくなるほど優先度を高くするようにしてもよい。その際、端末装置２０は、図５に示す機能選択ファイル２５１で特定したカテゴリ優先度に機能優先度を作用させて（例えば、乗じて）機能毎の優先度を算出し、この優先度を上述の機能優先度に代えて用いてもよい。
【００５２】
［第２実施形態］
次に、本発明の第２実施形態について説明する。
この第２実施形態の機能提示システム１では、辞書ファイル及び機能選択ファイルの構成が上述した第１実施形態と相違する。これに伴い、サーバ装置１０及び端末装置２０の構成及び動作も上述の第１実施形態とは相違する。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。また、第１実施形態と対応する構成について符号の末尾に「ａ」を付して表し、適宜その説明を省略する。
サーバ装置１０は、音声認識辞書として用いられる辞書ファイル１３１ａを記憶部１３に記憶している。
【００５３】
図１２は、辞書ファイル１３１ａの構成を示す図である。
図１２に示すように、辞書ファイル１３１ａは、「登録文字列」と「機能情報」との各フィールドに記述された情報を対応付けたデータテーブルである。「登録文字列」のフィールドには、辞書ファイル１３１と同様、辞書ファイル１３１ａに登録された文字列が記述される。「機能情報」のフィールドには、第２識別子と重み係数との組が記述される。第２識別子は、登録文字列に対して定められた機能の種類を当該登録文字列の分類として示すものである。機能の種類は、上述した第１実施形態のように機能が属するカテゴリを指す場合もあれば、機能そのものを指す場合もある。図１２に示す例では、「地図」や「グルメ」はカテゴリに相当し、「スケジューラ」や「メモ帳」は機能そのものに相当する。
【００５４】
図１２では、ＡＡ「ＢＢ」というデータ形式で記述されているが、これは第２識別子「ＡＡ」という機能の種類に対して、重み係数「ＢＢ」が与えられていることを意味する。図１２の第４行には、“http://www.〜.com”と記述されているが、これは、登録文字列に関連する情報を提供するＷｅｂサイトのＵＲＬを意味する。これは、Ｗｅｂ閲覧において参照されるアドレス情報であり、機能そのものを示す情報に相当する。重み係数は、ここでは「０．０」以上「１．０」以下の値であり、その値が大きいほど機能の種類に対する重み付けが大きいことを示す。また、辞書ファイル１３１ａは、一の登録文字列について、重み係数の総和が「１．０」となるように構成されている。
辞書ファイル１３１ａでは、登録文字列の意味と関連が深い機能の種類を示す第２識別子が当該登録文字列に対応付けられ、例えば、その関連が深いほど重み係数が大きい。なお、辞書ファイル１３１ａに辞書登録されたすべての登録文字列に、機能情報が割り当てられているとは限らない。
【００５５】
図１３は、機能選択ファイル２５１ａの構成を示す図である。
端末装置２０は、入力文字列から特定される第２識別子と、提示対象となる機能との関係を記述した機能選択ファイル２５１ａを、記憶部２５に記憶している。図１３に示すように、機能選択ファイル２５１ａには、“重み係数の総和が上位３位の種類の機能を、重み付け順の配置とする”という内容が記述されている。ただし、機能選択ファイル２５１ａのこの内容は一例であり、重み係数の総和が上位５位等とされてもよいし、ユーザにより設定された内容であってもよい。このように機能選択ファイル２５１ａは、入力文字列に対応する登録文字列の機能情報に応じて提示対象となる機能の規則を記述したデータである。
以上の構成を有する機能選択ファイル２５１ａは、詳しくは後述するが、所定の提示方法で提示する機能を選択する際に、端末装置２０により参照されるデータである。
次に、制御部１１の機能的構成について説明する。ここでは、上述した第１実施形態における機能的構成との相違点を主に説明する。
【００５６】
情報取得部１１１は、通信部１２の通信により端末装置２０の入力情報を取得する。特定部１１２は、辞書ファイル１３１ａを参照して、情報取得部１１１が取得した入力情報が示す入力文字列と、当該入力文字列に対応する登録文字列の機能情報（つまり、第２識別子及び重み係数）とを特定する。入力情報が音声情報である場合、特定部１１２は、辞書ファイル１３１ａを参照して、音声情報を認識し、認識した入力文字列と入力文字列に対応する登録文字列の機能情報とを特定する。送信制御部１１３は、入力文字列と、入力文字列に対応する登録文字列について特定部１１２が特定した機能情報との組を端末装置２０に送信するよう、通信部１２を制御する。
制御部１１のこれ以外の機能は、上述した第１実施形態と同じである。
次に、制御部２１の機能的構成について説明する。ここでは、上述した第１実施形態における機能的構成との相違点を主に説明する。
【００５７】
識別子取得部２１１は、無線通信部２３により受信された入力文字列と、入力文字列に対応する登録文字列の機能情報との組を取得し、ここから機能情報を取得する。
提示部２１２は、機能選択ファイル２５１ａ及び機能管理テーブル２５２を参照して、識別子取得部２１１が取得した機能情報に応じて提示対象となる機能を所定の提示方法で複数提示する。例えば、提示部２１２は、識別子取得部２１１が取得した機能情報と、機能選択ファイル２５１ａに記述された内容とに応じて定まる機能を、他の機能よりも優先させて提示する。
制御部２１のこれ以外の機能は、上述した第１実施形態と同様である。
次に、機能提示システム１の動作を説明する。
【００５８】
図１４は、機能提示システム１の動作を示すシーケンスチャートである。図１４に示すステップＳＢ１〜ＳＢ３の処理ステップは、上述した第１実施形態のＳＡ１〜ＳＡ３と同じであるから、ここではその説明を省略する。以下の説明において、ユーザは「品川」及び「ラーメン」を音声入力したものとする。
サーバ装置１０の制御部１１は、辞書ファイル１３１ａを参照して、音声情報を認識し（ステップＳＢ４）、認識した入力文字列とこの入力文字列に対応する登録文字列の機能情報とを特定する（ステップＳＢ５）。図１２に示すように、辞書ファイル１３１ａにおいて、登録文字列「品川」には、機能情報“地図「０．７」、グルメ「０．２」、電話「０．１」”が対応付けられ、登録文字列「ラーメン」には、機能情報“グルメ「０．４」、レシピ「０．３」、買い物「０．３」”が対応付けられている。
次に、制御部１１は、入力文字列と、入力文字列に含まれる登録文字列について特定した機能情報との組を端末装置２０に送信するよう、通信部１２を制御する（ステップＳＢ６）。
【００５９】
端末装置２０の制御部２１は、入力文字列と、入力文字列に含まれる登録文字列について特定した機能情報との組を無線通信部２３によって受信すると、ここから機能情報を取得する（ステップＳＢ７）。ここで、制御部２１は、機能情報＜地図「０．７」、グルメ「０．２」、電話「０．１」＞及び＜グルメ「０．４」、レシピ「０．３」、買い物「０．３」＞をそれぞれ取得する。
次に、制御部２１は、機能選択ファイル２５１ａを参照して、機能の種類毎に重み係数の総和を算出する（ステップＳＢ８）。ここでは、制御部２１は、＜地図「０．７」、グルメ「０．６」、レシピ「０．３」、買い物「０．３」、電話「０．１」＞を算出する。
【００６０】
次に、制御部２１は、ステップＳＢ８の処理で重み係数を算出した種類の機能から、決められた条件を満たす機能を実現する（ステップＳＢ９）。ここでは、制御部２１は、重み係数が最大であった種類の機能を実現する。重み係数が最大であった機能の種類がカテゴリであった場合、制御部２１は、そのカテゴリに属する機能優先度が最も高い機能を実現する。それ以外は、制御部２１は、第１実施形態のステップＳＡ９の処理と同様にすればよい。
【００６１】
次に、制御部２１は、機能選択ファイル２５１ａ及び機能管理テーブル２５２を参照して、ステップＳＢ７で取得した機能情報に応じて提示対象となる機能を所定の提示方法で提示させるとともに、ステップＳＢ９の処理に応じた機能の実現結果を提示する（ステップＳＢ１０）。ここでは、制御部２１は、図６に示す機能管理テーブル２５２で機能優先度が設定されたすべての機能を提示対象とし、かつ、機能情報に応じて提示対象となる機能を、他の機能よりも優先させて提示する。ここでは、制御部２１は、機能選択ファイル２５１ａに記述された“重み係数の総和が上位３位の種類の機能を、重み付け順の配置とする”という内容に従って、重み係数の総和が上位３位の種類の機能（ここでは、カテゴリ「グルメ」、「買い物」及び「地図」に属する機能）について、重み係数の総和が高い順→機能優先度が高い順となるようにアイコン画像を配置して、機能提示画面をＵＩ部２４に表示させる。制御部２１は、機能管理テーブル２５２で機能優先度が設定されたそれ以外の機能については、機能優先度や重み係数の総和とは無関係にアイコン画像を配置して、機能提示画面を表示させる。
なお、本実施形態においても、制御部２１は、機能選択ファイル２５１ａで規定される条件を満たす機能のアイコン画像のみを提示し、機能管理テーブル２５２で機能優先度が設定された他の機能については提示しない、という提示方法を採用してもよい。要するに、制御部２１は、予め決められた提示方法に従って、機能情報に応じて提示対象となった機能を少なくとも提示すればよい。
【００６２】
以上説明した第２実施形態の機能提示システム１では、登録文字列の分類として登録文字列に定められた機能の種類を用いる点で、上述の第１実施形態と相違する。これにより、例えば、登録文字列と機能の種類との関係が多数のユーザによって利用される組み合わせであるほど、重み係数が大きくなるように設定されていれば、機能提示システム１では、多数のユーザの実際の利用状況の統計に応じた機能提示サービスを提供することが可能となる。また、サーバ装置１０で辞書ファイル１３１ａが管理されるので、入力文字列に応じて好ましい機能が時々刻々と変化することがあっても、サーバ装置１０側での調整により、機能提示システム１において現在の状況に応じた機能の提示が可能となる。
これ以外にも、本実施形態の機能提示システム１によれば、上述した第１実施形態と同等の作用効果を奏する。
【００６３】
＜第２実施形態の変形例＞
上述した第２実施形態の構成を、以下の（２−１）〜（２−３）で説明する構成に変形してもよい。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（２−１）機能提示システム１において、辞書ファイル１３１ａに記述された重み係数をそのまま用いるのではなく、登録文字列毎の重要度に応じて重み係数を変化させてから、制御部２１が重み係数の総和を算出するようにしてもよい。例えば、登録文字列「品川」に対して登録文字列「ラーメン」が２倍重要であったとすると、制御部２１は、登録文字列「ラーメン」の重み係数を２倍にしてから、重み係数の総和を算出する。この場合、制御部２１は、＜地図「０．７」、グルメ「０．２」、電話帳「０．１」＞、及び＜グルメ「０．８」、レシピ「０．６」、買い物「０．６」＞で加算するので、ステップＳＢ１０の処理では、カテゴリ「グルメ」、「地図」、「レシピ」の順で機能を優先させて提示する。
登録文字列毎の重要度は、サーバ装置１０の管理者や端末装置２０のユーザにより設定されてもよいし、サーバ装置１０や端末装置２０により、入力文字列における登録文字列の入力頻度の希少度（例えば、入力文字列としての利用が少ない登録文字列）や、ｔｆ−ｉｄｆ（Term Freaquency-Inverse Document Frequency）等の指標を用いて算出されてもよい。ｔｆ−ｉｄｆは、文書中の単語に関する重みの一種であり、主に情報検索や文章要約等の分野で利用されるものであるが、例えば、これまで利用された入力文字列を用いて算出されればよい。これにより、例えば、「表参道」等のような利用頻度が高い登録文字列については、重要度が低く設定され、店舗名等のように、利用頻度が低い登録文字列については、重要度が高く設定される。
【００６４】
（２−２）機能提示システム１では、機能の種類毎に重み係数を合算しているが、例えばカテゴリ「グルメ」と、機能「グルメサイトＡ」との重み係数を合算するなど、機能と、その機能が属するカテゴリとの重み係数を合算してもよい。また、本実施形態の機能提示システム１では、重み係数の総和に応じて機能を提示しているが、これ以外にも、重み付けを反映させるための周知の方法を用いて機能を提示してもよい。
（２−３）機能提示システム１で、機能の種類として、機能が属するカテゴリ又は機能そのもののどちらか一方が採用されてもよい。
【００６５】
［第３実施形態］
次に、本発明の第３実施形態について説明する。
この第３実施形態の機能提示システム１では、上述した第１実施形態のように第１識別子に応じて機能を提示する「第１の提示方法」と、上述した第２実施形態のように機能情報（第２識別子）に応じて機能を提示する「第２の提示方法」とを択一的に採用して、機能を提示する。第１及び第２の提示方法のアルゴリズムは、上述した第１、第２実施形態と同じである。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。また、第１実施形態と対応する構成について符号の末尾に「ｂ」を付して表し、適宜その説明を省略する。
【００６６】
ところで、ある入力文字列に対して第１及び第２の提示方法のいずれかを採用しようとした場合、以下のような事情が存在すると発明者は考えた。
例えば有名人の名前が入力文字列に含まれている場合、第１の提示方法のように登録文字列の意味的な分類に基づいて機能を提示する構成では、どの有名人でも結果が同じになることがある。一方で、有名人の名前であっても、その名前によって、ユーザにとって好ましい機能は異なると考えられる。例えば、ユーザにしてみれば、ウェブログを開設している有名人であればそのウェブログを閲覧したいと考えることがあるし、有名人が歌手であればその有名人の音楽を聴きたいと考える場合があるし、有名人によってはその有名人の画像を閲覧したいと考える場合もある、という具合である。このような事情を考慮すると、第２の提示方法を採用するのが好ましいと考えられる。しかしながら、第２の提示方法で好ましい機能の提示結果をユーザが得るには、辞書ファイル１３１ａにおいてユーザの利用状況に関して十分な統計結果が反映されていなければならず、統計量が不足していると、好ましい提示結果をユーザが得られない場合がある。また、入力文字列に複数の登録文字列が含まれている場合には、その組み合わせ次第で重み係数が様々に変化しうるので、必ずしもユーザにとって好ましい機能が提示されるとは限らない。このような事情に照らして、本実施形態の機能提示システム１では、上記第１又は第２の提示方法の一方を択一的に採用する。
【００６７】
図１５は、辞書ファイル１３１ｂの構成を示す図である。サーバ装置１０は、音声認識辞書として用いられる辞書ファイル１３１ｂを記憶部１３に記憶している。
図１５に示すように、辞書ファイル１３１ｂは、「登録文字列」と、「第１識別子」と、「機能情報」との各フィールドに記述された情報を対応付けたデータテーブルである。「登録文字列」のフィールドには、辞書ファイル１３１と同様、辞書ファイル１３１ｂに登録された文字列が記述される。「第１識別子」のフィールドには、辞書ファイル１３１と同様の第１識別子が記述される。「機能情報」のフィールドには、辞書ファイル１３１ａと同様の情報が記述される。
【００６８】
図１６は、機能選択ファイル２５１ｂにあっては、上述した機能選択ファイル２５１，２５１ａの双方の内容が記述されている。端末装置２０は、機能選択ファイル２５１ｂを、記憶部２５に記憶している。
この実施形態の機能提示システム１において、第１又第２の提示方法のどちらを採用するかを決定するための仕組みとして、以下のようなものがある。
【００６９】
例えば、特定部１１２は、入力文字列に対応する登録文字列が１つだけである場合、第２の提示方法を採用するように機能情報を特定し、登録文字列が２つ以上である場合には、第１の提示方法を採用するように第１識別子を特定する。以降、サーバ装置１０及び端末装置２０は、特定部１１２が特定した識別子に応じて、上述した第１、２実施形態のいずれかと同様にして機能する。例えば、入力文字列に「品川」又は「ラーメン」の一方のみが含まれていれば、機能提示システム１では、第２の提示方法が採用される。また、入力文字列に「品川」及び「ラーメン」の２つが含まれていれば、機能提示システム１では、第１の提示方法が採用される。このようにすれば、第１又は第２の提示方法のそれぞれの長所を活かすことができると考えられる。
【００７０】
制御部２１が第２の提示方法を採用する場合、図１７に示す重み付け更新テーブル１３２を参照して、第１識別子が示すカテゴリに応じた更新係数を重み係数に作用させて（ここでは、乗じて）から、重み係数の総和を算出するようにしてもよい。重み付け更新テーブル１３２は、例えばサーバ装置１０で管理され記憶部１３に記憶されている。制御部２１は、重み付け更新テーブル１３２の内容を基に、例えば第１識別子「地名＋食品」に対応付けられたカテゴリ「グルメ」に属する機能について、重み係数に更新係数を乗じて２倍にしてから、重み係数の総和を算出する。このようにすれば、第２の提示方法の採用時においても、第１の提示方法で用いた意味的な分類による作用を反映させることができる。
【００７１】
また、特定部１１２は、入力文字列に対応する登録文字列に、第１識別子又は第２識別子の一方しか対応付けられていない場合、識別子が記述されている方の提示方法を採用してもよい。これにより、機能提示システム１では、辞書ファイル１３１ｂにおける識別子の有無に応じて、適切な提示方法を選択し、より適切な機能を提示できることができる。
これら以外にも、機能提示システム１において、辞書ファイル１３１ｂにおいてユーザの利用状況の統計が十分に反映されている登録文字列が入力文字列に含まれる場合には、第２の提示方法が採用されるようにし、それ以外の場合は、第１の提示方法が採用されてもよい。例えば、サーバ装置１０が辞書ファイル１３１ｂに記述された登録文字列が入力文字列に含まれていた回数を数えておき、この回数が閾値以上になれば、統計量が十分と判断して第２の提示方法を優先して採用し、それ以外の場合は、第１の提示方法を採用する。
機能提示システム１において第１又は第２の提示方法のどちらを採用するかの判定条件は、前掲以外のものであってもよい。また、以上の第３実施形態の機能提示システム１によれば、上述した第１、第２実施形態と同等の効果も奏する。
【００７２】
［第４実施形態］
次に、本発明の第４実施形態について説明する。
この第４実施形態の機能提示システム１は、上述した第１〜３実施形態で説明した辞書ファイルを更新する機能を有している。本実施形態の機能提示システム１の構成のうち、第１，２実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。
【００７３】
図１８は、サーバ装置１０の制御部１１の機能的構成を示す機能ブロック図である。
図１８に示すように、制御部１１は、プログラムを実行することにより、情報取得部１１１と、特定部１１２と、送信制御部１１３と、更新データ取得部１１４と、第１更新部１１５とに相当する機能を実現する。情報取得部１１１、特定部１１２及び送信制御部１１３は、上述した第１又は第２実施形態と同等に機能する。更新データ取得部１１４は、提示部２１２により複数機能が提示された後にユーザにより実現が指示された機能を特定するための更新データを取得する。更新データ取得部１１４は、ＵＩ部２４が操作されていずれかの機能の実現が指示されると、その指示がなされた機能の通知を更新データとして、通信部１２の通信により取得する。ユーザにより実現が指示される機能は、機能提示画面において提示された機能もあれば、機能提示画面において提示されなかった機能もある。
【００７４】
第１更新部１１５は、更新データ取得部１１４が取得した更新データに基づいて、辞書ファイル１３１，１３１ａを更新する。第１更新部１１５は、更新データ取得部１１４が取得した更新データで特定される機能が提示部２１２により提示されやすくなるように、辞書ファイル１３１，１３１ａを更新する。
次に、機能提示システム１の動作を説明する。以下、第１識別子に基づいて機能を提示する第１の提示方法の場合と、第２実施形態のように機能情報に基づいて機能を提示する第２の提示方法の場合とに分けて動作を説明する。
【００７５】
図１９は、第１の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＡ１〜ＳＡ１０までの処理ステップは、上述した第１実施形態と同じであるから、ここではその説明を省略する。
端末装置２０の制御部２１は、ステップＳＡ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等によって、機能の実現の指示を受け付ける（ステップＳＡ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリの実行により実現される機能が指示されたものとする。この「動作アプリ」は、機能提示画面において提示されていない機能に該当するものである。
制御部２１は、登録文字列「品川」及び「ラーメン」である場合の提示結果に対し、動画アプリに関する機能の実現指示があった旨を、無線通信部２３によりサーバ装置１０に通知する（ステップＳＡ１２）。
【００７６】
サーバ装置１０の制御部１１は、通信部１２より実現指示があった旨の通知を受信すると、この通知を更新データとして取得する（ステップＳＡ１３）。次に、制御部１１は、取得した更新データに基づいて、辞書ファイル１３１を更新する（ステップＳＡ１４）。辞書ファイル１３１の更新方法として、以下のようなものがある。
例えば、制御部１１は、登録文字列「品川」及び「ラーメン」を組み合わせて一の登録文字列として、「品川ラーメン」という登録文字列を辞書ファイル１３１に新たに記述する。そして、制御部１１は、登録文字列「品川ラーメン」が入力文字列に含まれる場合に、機能「動作アプリ」が提示されるように、第１識別子を決定する。この場合の第１識別子には、図５に示す機能選択ファイル２５１で、動作アプリが属するカテゴリ「動画再生」と対応付けられた「映画名」がある。
このように制御部１１は、入力文字列に含まれる登録文字列を複数組み合わせて一の登録文字列とする。そして、制御部１１は、ステップＳＡ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部１１は、特定したカテゴリに機能選択ファイル２５１において対応付けられた第１識別子を、組み合わせた登録文字列に対応付けるよう、辞書ファイル１３１を更新する。
【００７７】
また、制御部１１は、既登録の登録文字列「品川」及び「ラーメン」のそれぞれの第１識別子を書き換えるように、辞書ファイル１３１を更新してもよい。この場合、制御部１１は、辞書ファイル１３１において、登録文字列「品川」及び「ラーメン」の双方又は一方に第１識別子「映画名」を追加するように更新する。
このように制御部１１は、ステップＳＡ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部１１は、特定したカテゴリに機能選択ファイル２５１において対応付けられた第１識別子を登録文字列に対応付けるように、辞書ファイル１３１を更新する。
【００７８】
図２０は、第２の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＢ１〜ＳＢ１０までの処理ステップは、上述した第２実施形態と同じであるから、ここではその説明を省略する。端末装置２０の制御部２１は、ステップＳＢ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等によって、機能の実現の指示を受け付ける（ステップＳＢ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリの実行により実現される機能の実現が指示されるものとする。制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリに関する機能の実現指示があった旨を、無線通信部２３によりサーバ装置１０に通知する（ステップＳＢ１２）。
【００７９】
サーバ装置１０の制御部１１は、通信部１２より実現指示があった旨の通知を受信すると、この通知を更新データとして取得する（ステップＳＢ１３）。次に、端末装置２０の制御部２１は、取得した更新データに基づいて、辞書ファイル１３１ａを更新する（ステップＳＢ１４）。辞書ファイル１３１ａの更新方法として、以下のようなものがある。
例えば、制御部１１は、登録文字列「品川」及び「ラーメン」を一の登録文字列「品川ラーメン」として辞書ファイル１３１ａに記述する。そして、制御部１１は、この登録文字列「品川ラーメン」が入力文字列に含まれる場合に、機能選択サービスにおいて機能「動画アプリ」が提示されやすくなるように、機能情報を設定する。例えば、制御部１１は、カテゴリ「動作再生」の重み係数を「１．０」としたり、機能「動画アプリ」の重み係数を「１．０」にしたりする。
このように制御部１１は、入力文字列に含まれる登録文字列を複数組み合わせて一の登録文字列とするとともに、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類（機能そのものと、機能が属するカテゴリのどちらでもよい。）を、当該一の登録文字列に対応付けるよう、辞書ファイル１３１ａを更新する。
【００８０】
また、制御部１１は、既登録の登録文字列「品川」及び「ラーメン」のそれぞれの機能情報を書き換えるように、辞書ファイル１３１ａを更新してもよい。この場合、制御部１１は、辞書ファイル１３１ａにおいて、登録文字列「品川」及び「ラーメン」の双方に、第２識別子「映画名」と重み係数とが対応付けられるように更新する。ここでは、制御部１１は、登録文字列「品川」及び「ラーメン」の第２識別子「動画再生」について、重み係数を「０．１」だけ加算するという具合に、決められた値を加算して新たな重み係数とするとよい。また、制御部１１は、上述した稀少性やｔｆ−ｉｄｆの指標を用いて、稀少性の高いものやｔｆ−ｉｄｆが大きいほど、重み係数の増加量を大きくするようにしてもよい。また、制御部１１は、登録文字列「品川」及び「ラーメン」の第２識別子として、機能「動画アプリ」を追加してもよい。
このように制御部１１が、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類を、入力文字列に含まれる一の登録文字列に新たに対応付けたり、当該登録文字列が既登録であれば当該機能の種類の重み係数を大きくしたりして、辞書ファイル１３１ａを更新する。
【００８１】
なお、機能提示システム１における辞書ファイルの更新は、ユーザにより機能提示サービスが利用されるたびに行われてもよいし、サーバ装置１０で機能提示サービスの利用履歴が管理され、同じ利用が閾値以上の回数又は頻度行われたことを契機に更新されてもよい。また、機能提示システム１において、機能提示サービスの利用履歴に基づいて、同じ利用をした端末装置２０の数又は割合が閾値以上となったことを契機に辞書ファイルが更新されてもよい。機能提示サービスの利用履歴を管理するために、例えば、更新データ取得部１１４は、取得した更新データで特定される機能の実現履歴（例えば、機能の種類や機能の実現日時、機能を実現した端末装置を識別する情報を含む。）を記憶部１３に記憶（蓄積）させる。そして、第１更新部１１５は、記憶部１３に蓄積された機能の実現履歴に基づいて、辞書ファイルを更新する。
【００８２】
以上説明した第４実施形態の機能提示システム１では、実際のユーザの機能の利用状況を学習して、辞書ファイルを更新することができる。また、この機能提示システム１によれば、機能提示サービスの利用回数が増えるほど、より好ましい機能提示サービスを提供することができるし、登録文字列が自動で辞書ファイルに蓄積されるという効果も奏する。このようにして、本実施形態の機能提示システム１によれば、多数のユーザの利用状況に応じて、世間の動向や流行等を反映したサービスの提供が可能となる。
なお、本実施形態の辞書ファイルの更新に係る構成は、上述した第３実施形態の機能提示システム１における辞書ファイル１３１ｂの更新にも適用可能である。
【００８３】
［第５実施形態］
次に、本発明の第５実施形態について説明する。
この第５実施形態の機能提示システム１は、機能選択ファイル２５１，２５１ａを更新する機能を有している。以下の説明において、本実施形態の機能提示システム１の構成のうち、第１，２実施形態と共通するものは同一の符号を付して表し、その各構成の説明及び図示を適宜省略する。
【００８４】
図２１は、端末装置２０の制御部２１の機能的構成を示す機能ブロック図である。
図２１に示すように、制御部２１は、プログラムを実行することにより、識別子取得部２１１と、提示部２１２と、機能実現部２１３と、更新データ取得部２１４と、第２更新部２１５とに相当する機能を実現する。識別子取得部２１１、提示部２１２、及び機能実現部２１３は、上述した第１又は第２実施形態と同等に機能する。更新データ取得部２１４は、提示部２１２により複数機能が提示された後にユーザにより実現が指示された機能を特定するための更新データを取得する。更新データ取得部２１４は、ＵＩ部２４が操作されていずれかの機能の実現が指示されると、その指示がなされた機能の更新データを取得する。
【００８５】
第２更新部２１５は、更新データ取得部２１４が取得した更新データで特定される機能に基づいて機能選択ファイル２５１，２５１ａを更新する。第２更新部２１５は更新データ取得部２１４が取得した更新データで特定される機能が提示部２１２で提示されやすくなるように、機能選択ファイル２５１，２５１ａを更新する。
次に、機能提示システム１の動作を説明する。以下、第１実施形態の提示方法の場合と第２実施形態の提示方法の場合とに分けて動作を説明する。
【００８６】
図２２は、第１の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＡ１〜ＳＡ１０までの処理ステップは、上述した第１実施形態と同じであるから、ここではその説明を省略する。
端末装置２０の制御部２１は、ステップＳＡ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等により、機能の実現の指示を受け付ける（ステップＳＡ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリ実行が指示されるものとする。
【００８７】
制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリにより実現される機能を特定するための更新データを取得する（ステップＳＡ１５）。次に、制御部２１は、取得した更新データに基づいて、機能選択ファイル２５１を更新する（ステップＳＡ１６）。機能選択ファイル２５１の更新方法として、以下のようなものがある。
例えば、制御部２１は、登録文字列「品川」＋「ラーメン」に対応して、第１識別子「地名＋食品」に対応するカテゴリを書き換えるように、機能選択ファイル２５１を更新する。この場合、制御部２１は、機能選択ファイル２５１において、第１識別子「地名＋食品」又は「人名＋食品」に、カテゴリ「動画再生」を対応付けるように更新する。
これにより、入力文字列に「品川」及び「ラーメン」が含まれる場合に、カテゴリ「動画再生」に属する機能が提示されることになる。この場合、登録文字列「大阪」＋「ハンバーグ」の場合も、第１識別子「地名＋食品」又は「人名＋食品」となるので、カテゴリ「動画再生」に属する機能が提示されやすくなる。
このように制御部２１は、ステップＳＡ１５の処理で取得した更新データに基づいて、端末装置２０で実現された機能が属するカテゴリを特定する。そして、制御部２１は、特定したカテゴリにステップＳＡ７の処理で取得した第１識別子を新たに対応付けたり、この第１識別子に対応付けられたカテゴリ優先度を高くしたりして、機能選択ファイル２５１を更新する。
【００８８】
図２３は、第２の提示方法を採用した機能提示システム１の動作を示すシーケンスチャートである。
ステップＳＢ１〜ＳＢ１０までの処理ステップは、上述した第２実施形態と同じであるから、ここではその説明を省略する。端末装置２０の制御部２１は、ステップＳＢ１０の処理で機能提示画面をＵＩ部２４に表示させた後、アイコン画像のユーザの指定等により、機能の実現の指示を受け付ける（ステップＳＢ１１）。ここでは、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリ実行が指示されるものとする。制御部２１は、登録文字列「品川」、「ラーメン」である場合の提示結果に対し、動画アプリにより実現される機能を特定するための更新データを取得する（ステップＳＢ１５）。次に、制御部２１は、取得した更新データに基づいて、機能選択ファイル２５１ａを更新する（ステップＳＢ１６）。機能選択ファイル２５１ａの更新方法として、以下のようなものがある。
【００８９】
例えば、制御部２１は、登録文字列「品川」＋「ラーメン」に対応して、カテゴリ「グルメ」、「地図」および「レシピ」を選択するが、ここに強制的に、カテゴリ「動画再生」を含めるように、機能選択ファイル２５１ａ更新する。これにより、以降、入力文字列に「品川」及び「ラーメン」が含まれる場合に、機能提示システム１では、カテゴリ「動画再生」に属する機能「動画アプリ」が提示される。また、機能提示システム１において、重み係数に関わらず、カテゴリ「動画再生」や機能「動画アプリ」の機能優先度を最も高い優先度として扱う内容が機能選択ファイル２５１ａに記述されていてもよい。
このように制御部１１は、ステップＳＢ１３の処理で取得した更新データに基づいて、端末装置２０で実現された機能の種類を特定し、特定した機能の種類がステップＳＢ７の処理で取得した機能情報と同じものが取得されたときにこの種類が提示されやすくなるよう、機能選択ファイル２５１ａを更新する。
【００９０】
なお、機能提示システム１における機能選択ファイルの更新は、ユーザにより機能提示サービスが利用されるたびに行われてもよいし、サーバ装置１０で機能提示サービスの利用履歴が管理され、同じ利用が閾値以上の回数又は頻度行われたことを契機に更新されてもよい。また、機能提示システム１において、機能提示サービスの利用履歴に基づいて、同じ利用をした端末装置２０の数又は割合が閾値以上となったことを契機に更新されてもよい。機能提示サービスの利用履歴を管理するために、例えば、更新データ取得部２１４は、取得した更新データで特定される機能の実現履歴（上述した第４実施形態と同じデータでよい。）を記憶部２５に蓄積させる。そして、第２更新部２１５は、記憶部２５に蓄積された機能の実現履歴に基づいて、機能選択ファイルを更新する。
【００９１】
以上説明した第５実施形態の機能提示システム１では、実際のユーザの機能の利用状況を学習して、機能選択ファイルを更新することができる。また、この機能提示システム１によれば、機能提示サービスの利用回数が増えるほど、より好ましい機能提示サービスを提供することができる。このようにして、本実施形態の機能提示システム１によれば、多数のユーザの利用状況に応じて、世間の動向や流行等を反映したサービスの提供が可能となる。
なお、本実施形態の機能選択ファイルの更新に係る構成は、上述した第３実施形態の機能提示システム１の機能選択ファイル２５１ｂの更新にも適用可能である。また、第４，第５実施形態の更新の機能を両方備えた機能提示システム１としてもよい。
【００９２】
［変形例］
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
［変形例１］
上述した各実施形態では、端末装置２０は辞書ファイル及び機能選択ファイルに基づいて提示する機能を特定していたが、端末装置２０が以下のように動作するようにしてもよい。なお、本変形例では、端末装置２０は、サーバ装置１０により識別子が特定される前に入力文字列を取得する。端末装置２０は、例えば、自装置の音声認識機能で入力文字列を取得する。
なお、以下では、制御部１１がサーバ装置１０から取得する入力文字列を用いて行う制御の説明を省略する。
【００９３】
図２４は、端末装置２０の動作を示すフローチャートである。
制御部２１は、入力文字列を取得する（ステップＳＣ１）。次に、制御部２１は、入力文字列に特定の登録文字列が含まれるか否かを判断する（ステップＳＣ２）。特定の登録文字列は、ここでは、「（検索サイトＡの名称） ○○」や「地図 △△」のように、ユーザが利用を希望する機能を特定可能な予め決められた文字列である。このような文字列が入力文字列に含まれていれば、実質的に、利用したい機能をユーザが指定したことに近いといえる。
制御部２１は、特定の登録文字列が含まれると判断した場合（ステップＳＣ２；ＹＥＳ）、この登録文字列に対応して定められた機能を実現する。入力文字列が「（検索サイトＡ） ○○」であれば、制御部２１は、検索サイトＡで検索語を「○○」として情報検索を行い、入力文字列が「地図 品川」であれば、制御部２１は、地図アプリを実行して品川区付近の地図を表示する、という具合である。
このような特定の登録文字列と、実現対象となる機能との対応関係は記憶部２５等に記憶され、制御部２１はこの対応関係を参照するとよい。
【００９４】
制御部２１は、ステップＳＣ３の処理を実行した後、又はステップＳＣ２で特定の登録文字列が含まれないと判断した場合（ステップＳＣ２；ＮＯ）、無線通信部２３により入力文字列をサーバ装置１０に送信する（ステップＳＣ４）。そして、上述した各実施形態の手順で、サーバ装置１０によりこの入力文字列を入力情報として第１識別子又は機能情報が特定されると、制御部２１は無線通信部２３により第１識別子又は機能情報を受信する（ステップＳＣ５）。そして、制御部２１は、受信した第１識別子又は機能情報と、機能選択ファイル及び機能管理テーブル２５２とに基づいて機能の種類を特定し（ステップＳＣ６）、提示対象の機能があるか否かを判断する（ステップＳＣ７）。
【００９５】
ここで、制御部２１は、提示対象の機能がある場合には（ステップＳＣ７；ＹＥＳ）、上述した各実施形態と同様にして、機能管理テーブル２５２に従って機能を提示する（ステップＳＣ８）。一方、制御部２１は、提示対象の機能がない場合には（ステップＳＣ７；ＮＯ）、標準設定の機能を提示する（ステップＳＣ９）。ここでは、制御部２１は、所定の情報検索サイトやメモ帳等、適切な機能が提示できなかった場合においてユーザが希望する可能性の高いと推定される所定の機能を提示する。この機能は、ユーザ設定や設計段階等で決められてもよいし、制御部２１が、ユーザの過去の利用履歴に基づいて、利用回数や頻度が閾値以上となった機能を提示してもよい。
本変形例の構成によれば、端末装置２０は、入力文字列に含まれる文字列そのものから、ユーザの希望する機能を推定して提示することが可能である。また、提示対象の機能がない場合であっても、何の機能も提示されないで、ユーザが不便に感じてしまうことを抑えることができる。
【００９６】
［変形例２］
上述した各実施形態では、入力文字列に対して辞書ファイル及び機能選択ファイルを参照して機能提示していたので、登録文字列の表記方法がいかようであっても、登録文字列が同一であれば提示結果が同一になることがある。例えば、入力文字列に「ラーメン」という１つの登録文字列が含まれる場合、「ラーメンが食べたい」、「ラーメンの作り方」のどちらであっても、提示結果が同じになるということである。しかしながら、前者の入力文字列であれば、カテゴリ「グルメ」の機能がユーザにとって好適であるといえるし、後者の入力文字列であれば、カテゴリ「レシピ」の機能がユーザにとって好適であるといえる。このように、入力文字列における登録文字列の表記方法は、入力文字列における当該登録文字列以外の文字列（又は文字）によって変化しうるものである。
そこで、本変形例では、提示部２１２は、識別子取得部２１１から識別子とともに入力文字列を取得し、入力文字列における登録文字列の表記方法に従って、機能の提示方法を異ならせる。例えば、「食べたい」や「作り方」のような文字列に対応するカテゴリ又は機能を示す情報が記憶部２５に記憶されていて、提示部２１２はこの情報に従って、他の機能よりも優先させて提示する機能を特定する。提示部２１２は、アイコン画像の配置順を変更するようにして機能の提示方法を異ならせてもよいし、優先させて提示する機能のみを提示してもよい。
【００９７】
また、提示部２１２は、入力文字列を解析して、入力文字列において文字数、登録文字列数又は形態素数が閾値以上である場合には、機能選択ファイルを参照しないで機能を提示するようにしてもよい。例えば、入力文字列が「ラーメンを最初に発明したのは誰か」の場合、提示部２１２は、予め決められた機能として、カテゴリ「Ｗｅｂ検索」に属する機能や「メモ帳」を選択する、という具合である。
【００９８】
［変形例３］
上述した各実施形態では、情報取得部１１１、特定部１１２及び送信制御部１１３に相当する機能がサーバ装置１０で実現され、識別子取得部２１１、提示部２１２及び機能実現部２１３に相当する機能が端末装置２０で実現されていたが、前掲した各機能を実現する装置は、この態様に限定されるものではない。要するに、機能提示システム１により実現される機能的構成が、例えば図２５に示す構成になればよい。
例えば、サーバ装置１０が、情報取得部１１１、特定部１１２及び識別子取得部２１１に相当する機能を実現してもよい。この場合、サーバ装置１０は、辞書ファイル及び機能選択ファイルの双方を記憶する。サーバ装置１０は、機能選択ファイルを参照して提示対象となる機能の種類を選択すると、その内容を端末装置２０に通知する。そして、端末装置２０において、提示部２１２は、通知された種類の機能を、機能管理テーブルを参照して提示する。
【００９９】
また、上述したすべての機能が端末装置２０で実現されてもよい。この場合、端末装置２０は、入力情報を取得すると、辞書ファイルを参照して、入力情報が示す入力文字列と識別子（つまり、第１又は第２識別子）とを特定する。そして、端末装置２０は、特定した識別子と、機能選択ファイル及び機能管理テーブルとに応じて、機能を提示する。この場合、端末装置２０が辞書ファイル及び機能選択ファイルの双方を記憶する。この構成であっても、サーバ装置１０が端末装置２０に更新データを送信する等して、上述した第４，５実施形態と同様にして、端末装置２０が辞書ファイル及び機能選択ファイルを更新することも可能である。また、この場合において、辞書ファイル及び機能選択ファイルをサーバ装置１０が記憶し、端末装置２０がサーバ装置１０に問い合わせて、機能選択ファイルを参照した処理を行うようにしてもよい。
【０１００】
［変形例４］
上述した各実施形態の機能提示システム１において、参照される辞書ファイルや機能選択ファイルが状況に応じて異なるようにしてもよい。
例えば、機能提示システム１において、端末装置２０のユーザのユーザ属性に応じて、参照される辞書ファイルや機能選択ファイルを異ならせてもよい。この場合、端末装置２０は、ユーザの性別や年齢、出身地、趣味等のユーザ属性を示す属性情報を、入力情報の送信時等にサーバ装置１０に送信する。サーバ装置１０の制御部１１（情報取得部１１１）は、ユーザ属性を示す属性情報を取得する。そして、制御部１１（特定部１１２）は、取得した属性情報が示すユーザ属性に対応した辞書ファイルを参照して、識別子を特定する。一方、端末装置２０の制御部１１（提示部２１２）は、ユーザ属性に対応した機能選択ファイルを参照して機能を提示する。このようにすれば、ユーザ属性に応じて利用機能の傾向が異なる場合であっても、この傾向を機能提示サービスへ反映させることが可能となる。
また、機能提示システム１において、辞書ファイルや機能選択ファイルをユーザ毎に異ならせるようにしてもよい。
【０１０１】
また、端末装置２０の位置に応じて、機能提示システム１で参照される辞書ファイルや機能選択ファイルを異ならせてもよい。例えば、端末装置２０のユーザが東京に居て大阪の情報を調べるときは、定番の観光地を調べることを希望する場合が多いと推定される。一方、端末装置２０のユーザが大阪に居て大阪の情報を調べるときは、電車の乗換案内を調べることを希望する場合が多いと推定される。このように、ある入力文字列に対する利用機能の傾向は、ユーザの居る場所に応じて異なることが考えられる。そこで、端末装置２０はＧＰＳ（Global Positioning System）測位や基地局測位等を行って自装置の位置を特定してサーバ装置１０に通知する。そして、サーバ装置１０及び端末装置２０は、この位置に応じた辞書ファイルや機能選択ファイルを選択して機能を提示するようにしてもよい。
【０１０２】
また、時刻に応じて、機能提示システム１で参照される辞書ファイルや機能選択ファイルを異ならせてもよい。例えば、昼間や夜間に「ハンバーグ」という登録文字列が含まれる入力文字列が使用された場合、ハンバーグを食べたいとユーザが考えていると推定されるので、カテゴリ「グルメ」の機能が好適であると推定される。一方、夕方に「ハンバーグ」という登録文字列が含まれる入力文字列が使用された場合、ハンバーグのレシピをユーザが調べたいと考えていて、カテゴリ「レシピ」の機能が好適であると推定される。そこで、サーバ装置１０はタイマの計時時刻から現在時刻を特定して、特定した現在時刻に応じた辞書ファイルを選択して参照する。端末装置２０においても、タイマの計時時刻から現在時刻を特定して、特定した時刻に応じた機能選択ファイルを選択して機能を提示するとよい。
また、端末装置２０の位置や時刻に応じて参照される辞書ファイルや機能選択ファイルを異ならせる構成は、カテゴリ優先度や重み係数を端末装置２０の位置や時刻に応じて変化させることでも実現可能である。
【０１０３】
［変形例５］
上述した各実施形態の機能提示システム１では、「カテゴリ優先度」や「機能優先度」という情報が存在していたが、本発明は、これらを扱うことを必須とするものではない。この場合であっても、端末装置２０では機能の提示を行うことは可能である。「カテゴリ優先度」がない構成であれば、端末装置２０は、第１識別子に基づいて特定した複数のカテゴリを平等に扱うが、例えば、機能選択ファイル２５１における記述順が先のカテゴリを、カテゴリ優先度が高いカテゴリと同じようにして扱ってもよい。また、「機能優先度」がない構成であれば、端末装置２０は、各カテゴリ内に属する複数機能を平等に扱うが、例えば、機能管理テーブル２５２における記述順が先の機能ほど、機能優先度が高い機能と同じようにして扱ってもよい。
【０１０４】
［変形例６］
また、端末装置２０は、ステップＳＡ９又はステップＳＢ９の処理で、ユーザからの指示なしに機能を実現していたが、これを実現しない構成であってもよい。この場合、制御部２１は機能実現部２１３に相当する機能を実現しなくてよい。このような場合、サーバ装置１０が、入力文字列に対して特定した識別子を端末装置２０に提供するものの、入力文字列については提供しない構成とすることも可能である。もちろん、機能実現部２１３が、ユーザからの指示なしに機能を実現する場合に入力文字列を用いないのであれば、サーバ装置１０が入力文字列を端末装置２０に提供しなくてもよい。
また、端末装置２０は、複数の機能の実現結果を機能提示画面において並べて提示できる場合、ユーザによる機能の実現指示を受け付けることなく、決められた条件を満たす複数機能を実現し、その結果を提示してもよい。この場合、例えば、端末装置２０は、カテゴリ優先度が閾値以上であるカテゴリに属する機能をすべて実現する。
【０１０５】
［変形例７］
上述した各実施形態では、サーバ装置１０が、入力文字列に含まれる登録文字列と、辞書ファイルに記述された登録文字列とが一致した場合に識別子を特定していたが、例えばいわゆる表記ゆれを考慮して、入力文字列に含まれる登録文字列「コンピュータ」に対し、辞書ファイルに辞書登録された登録文字列「コンピューター」の識別子を特定してもよい。また、サーバ装置１０は、略語の利用を考慮して、入力文字列に含まれる登録文字列「パソコン」に対し、辞書ファイルに辞書登録された登録文字列「パーソナルコンピュータ」の識別子を特定してもよい。このように、サーバ装置１０では、取得した入力文字列に対応する登録文字列の識別子を、辞書ファイルを参照して特定すればよい。
【０１０６】
［変形例８］
上述した各実施形態において、端末装置２０の入力情報は音声情報に限らない。入力情報は、端末装置２０の撮影装置で撮影された内容を示す画像情報であってもよい。この場合、例えば、文字列（例えば、手書き文字）が含まれる原稿が撮影装置で撮影される。サーバ装置１０の制御部１１は、文字認識辞書として用いられ、登録文字列に識別子を割り当てた辞書ファイルを参照して、画像情報である入力情報を認識し、認識した入力文字列とこの入力文字列に対応する登録文字列の識別子とを特定する。
このように、入力情報が辞書ファイルを参照して入力文字列を認識できる情報であり、かつ、この辞書ファイルにおいて登録文字列に識別子が割り当てられていれば、サーバ装置１０は、入力文字列を得た後に識別子を特定するためのデータベース参照に係る処理を必要としない。よって、上述した各実施形態と同様、入力情報が端末装置２０に入力されてから機能提示までに要する時間の増大が抑えられる。
【０１０７】
また、ユーザによりＵＩ部２４が操作されて、文字情報が入力情報として端末装置２０に入力されてもよい。この場合、端末装置２０は、入力情報として入力文字列を受け付けて、この入力文字列をサーバ装置１０に提供することとなる。このような場合、識別子の特定に用いられる辞書ファイルは、入力情報の認識に用いられる辞書でなくてよい。このように、サーバ装置１０が、入力情報を認識して入力文字列を特定する機能を有していなくてよい。
また、入力情報が音声情報である場合であっても、端末装置２０に実装された音声認識機能を用いて端末装置２０が音声認識を行って入力文字列を特定し、これをサーバ装置１０に提供してもよい。また、端末装置２０及びサーバ装置１０以外の装置（例えば、汎用の音声認識サーバ）によって音声認識が行われてもよい。
【０１０８】
［変形例９］
また、第１識別子及び第２識別子は、それぞれ登録文字列の分類を識別するものであればよいから、通し番号や無意味文字によって表されてもよい。
また、上述した各実施形態の機能提示システム１では、１つのカテゴリに複数の機能が属していたが、１つのカテゴリに１つの機能が属していてもよい。この場合、本発明の機能の種類は、必然的に機能そのものに対応することとなる。
また、端末装置２０における機能の提示の態様は、アイコン画像の表示に限らず、「検索サイトＡ」という文字列を表示する等、別の態様であってもよい。また、端末装置２０は、提示結果から機能の実現を指示できる態様で表示するのではなく、機能の通知のみを目的とした提示を行ってもよい。
また、サーバ装置１０の制御部１１や端末装置２０の制御部２１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の協働によって実現されうる。
【符号の説明】
【０１０９】
１…機能提示システム、１０…サーバ装置、１１…制御部、１１１…情報取得部、１１２…特定部、１１３…送信制御部、１１４…更新データ取得部、１１５…第１更新部、１２…通信部、１３…記憶部、１３１，１３１ａ，１３１ｂ…辞書ファイル、１３２…重み付け更新テーブル、２０…端末装置、２１…制御部、２１１…識別子取得部、２１２…提示部、２１３…機能実現部、２１４…更新データ取得部、２１５…第２更新部、２２…音声入出力部、２３…無線通信部、２４…ＵＩ部、２５…記憶部、２５１，２５１ａ，２５１ｂ…機能選択ファイル、２５２…機能管理テーブル
【特許請求の範囲】
【請求項１】
入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する第１記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、
前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を備えることを特徴とする機能提示システム。
【請求項２】
前記第１記憶部は、前記入力情報の認識に用いられ、登録文字列に前記識別子を割り当てた辞書ファイルを記憶し、
前記特定部は、前記辞書ファイルを参照して、前記入力情報を認識し、認識した入力文字列と当該入力文字列に対応する登録文字列の前記識別子とを特定する
ことを特徴とする請求項１に記載の機能提示システム。
【請求項３】
前記第１記憶部は、少なくとも一部の登録文字列について複数の前記識別子を記憶し、
前記特定部は、前記入力文字列に含まれる一の登録文字列の前記識別子が前記第１記憶部に複数記憶されている場合、当該複数の前記識別子を特定する
ことを特徴とする請求項１又は２に記載の機能提示システム。
【請求項４】
前記識別子は、前記登録文字列の意味に基づく分類を示し、
前記第２記憶部は、前記識別子と、提示対象となる前記機能の種類とを対応付けて記憶し、
前記提示部は、前記特定部が特定した識別子に対応付けて前記第２記憶部に記憶された種類の機能を、前記提示方法で複数提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項５】
前記識別子は、前記登録文字列に対して定められた前記機能の種類を前記分類として示し、
前記第１記憶部は、前記機能の種類に対して与えられた重み付けを前記識別子に対応付けて記憶し、
前記特定部は、前記第１記憶部を参照して、前記識別子と、当該識別子が示す前記機能の種類に対する重み付けとを特定し、
前記提示部は、前記特定部が特定した識別子と重み付けとに応じて、前記提示方法で複数機能を提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項６】
前記識別子として、前記登録文字列の意味に基づく分類を示す第１識別子と、前記登録文字列の分類として前記登録文字列に対して定められた前記機能の種類を示す第２識別子とがあり、
前記第１記憶部は、前記登録文字列毎に、前記第１識別子、前記第２識別子、及び当該第２識別子が示す前記機能の種類に対して与えられた重み付けを記憶し、
前記提示部は、前記第２記憶部を参照して、前記特定部が特定した前記第１識別子、又は前記特定部が特定した第２識別子と重み付けとに応じて、前記提示方法で複数機能を提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項７】
前記提示部は、前記入力文字列に対応する登録文字列の表記方法に応じて、前記提示方法を異ならせる
ことを特徴とする請求項１から６のいずれか１項に記載の機能提示システム。
【請求項８】
前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第１記憶部の記憶内容を更新する第１更新部
を備えることを特徴とする請求項１から７のいずれか１項に記載の機能提示システム。
【請求項９】
前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第２記憶部の記憶内容を更新する第２更新部
を備えることを特徴とする請求項１から８のいずれか１項に記載の機能提示システム。
【請求項１０】
前記提示部が提示した前記機能のうち決められた条件を満たす機能を実現する機能実現部を備え、
前記提示部は、前記特定部が特定した識別子に応じて提示対象となる複数機能と、前記機能実現部が機能を実現した結果とを提示する
ことを特徴とする請求項１から９のいずれか１項に記載の機能提示システム。
【請求項１１】
サーバ装置と端末装置とを備える機能提示システムであって、
前記サーバ装置は、
前記端末装置と通信する第１通信部と、
前記端末装置の入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する第１記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、
前記特定部が特定した識別子を前記端末装置に送信するよう、前記第１通信部を制御する送信制御部と、
を有し、
前記端末装置は、
前記サーバ装置と通信する第２通信部と、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、
前記第２通信部により前記サーバ装置から受信した前記識別子を取得する識別子取得部と、
前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を有することを特徴とする機能提示システム。
【請求項１２】
サーバ装置と通信する通信部と、
自端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子が前記サーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得部と、
前記識別子と、提示対象となる機能との関係を記憶する記憶部と、
前記記憶部を参照して、前記識別子取得部が取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を備えることを特徴とする端末装置。
【請求項１３】
自サーバ装置から受信した識別子に応じた機能を複数提示する端末装置と通信する通信部と、
前記端末装置の入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記記憶部を参照して特定する特定部と、
前記特定部が特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御部と
を備えることを特徴とするサーバ装置。
【請求項１４】
通信部を有する端末装置のコンピュータに、
前記端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子がサーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得ステップと、
前記識別子と、提示対象となる機能との関係を記憶する記憶部を参照して、前記識別子取得ステップで取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップと
を実行させるためのプログラム。
【請求項１５】
通信部を有するサーバ装置のコンピュータに、
当該サーバ装置から受信した識別子に応じた機能を複数提示する端末装置の入力情報を取得する情報取得ステップと、
登録文字列の分類を示す識別子を記憶する記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、
前記特定ステップで特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御ステップと
を実行させるためのプログラム。
【請求項１６】
入力情報を取得する情報取得ステップと、
登録文字列の分類を示す識別子を記憶する第１記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部を参照して、前記特定ステップで特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップと
を有することを特徴とする機能提示方法。
【請求項１】
入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する第１記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、
前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を備えることを特徴とする機能提示システム。
【請求項２】
前記第１記憶部は、前記入力情報の認識に用いられ、登録文字列に前記識別子を割り当てた辞書ファイルを記憶し、
前記特定部は、前記辞書ファイルを参照して、前記入力情報を認識し、認識した入力文字列と当該入力文字列に対応する登録文字列の前記識別子とを特定する
ことを特徴とする請求項１に記載の機能提示システム。
【請求項３】
前記第１記憶部は、少なくとも一部の登録文字列について複数の前記識別子を記憶し、
前記特定部は、前記入力文字列に含まれる一の登録文字列の前記識別子が前記第１記憶部に複数記憶されている場合、当該複数の前記識別子を特定する
ことを特徴とする請求項１又は２に記載の機能提示システム。
【請求項４】
前記識別子は、前記登録文字列の意味に基づく分類を示し、
前記第２記憶部は、前記識別子と、提示対象となる前記機能の種類とを対応付けて記憶し、
前記提示部は、前記特定部が特定した識別子に対応付けて前記第２記憶部に記憶された種類の機能を、前記提示方法で複数提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項５】
前記識別子は、前記登録文字列に対して定められた前記機能の種類を前記分類として示し、
前記第１記憶部は、前記機能の種類に対して与えられた重み付けを前記識別子に対応付けて記憶し、
前記特定部は、前記第１記憶部を参照して、前記識別子と、当該識別子が示す前記機能の種類に対する重み付けとを特定し、
前記提示部は、前記特定部が特定した識別子と重み付けとに応じて、前記提示方法で複数機能を提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項６】
前記識別子として、前記登録文字列の意味に基づく分類を示す第１識別子と、前記登録文字列の分類として前記登録文字列に対して定められた前記機能の種類を示す第２識別子とがあり、
前記第１記憶部は、前記登録文字列毎に、前記第１識別子、前記第２識別子、及び当該第２識別子が示す前記機能の種類に対して与えられた重み付けを記憶し、
前記提示部は、前記第２記憶部を参照して、前記特定部が特定した前記第１識別子、又は前記特定部が特定した第２識別子と重み付けとに応じて、前記提示方法で複数機能を提示する
ことを特徴とする請求項１から３のいずれか１項に記載の機能提示システム。
【請求項７】
前記提示部は、前記入力文字列に対応する登録文字列の表記方法に応じて、前記提示方法を異ならせる
ことを特徴とする請求項１から６のいずれか１項に記載の機能提示システム。
【請求項８】
前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第１記憶部の記憶内容を更新する第１更新部
を備えることを特徴とする請求項１から７のいずれか１項に記載の機能提示システム。
【請求項９】
前記提示部により前記機能が提示された後にユーザにより実現が指示された前記機能に基づいて、前記第２記憶部の記憶内容を更新する第２更新部
を備えることを特徴とする請求項１から８のいずれか１項に記載の機能提示システム。
【請求項１０】
前記提示部が提示した前記機能のうち決められた条件を満たす機能を実現する機能実現部を備え、
前記提示部は、前記特定部が特定した識別子に応じて提示対象となる複数機能と、前記機能実現部が機能を実現した結果とを提示する
ことを特徴とする請求項１から９のいずれか１項に記載の機能提示システム。
【請求項１１】
サーバ装置と端末装置とを備える機能提示システムであって、
前記サーバ装置は、
前記端末装置と通信する第１通信部と、
前記端末装置の入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する第１記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記第１記憶部を参照して特定する特定部と、
前記特定部が特定した識別子を前記端末装置に送信するよう、前記第１通信部を制御する送信制御部と、
を有し、
前記端末装置は、
前記サーバ装置と通信する第２通信部と、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部と、
前記第２通信部により前記サーバ装置から受信した前記識別子を取得する識別子取得部と、
前記第２記憶部を参照して、前記特定部が特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を有することを特徴とする機能提示システム。
【請求項１２】
サーバ装置と通信する通信部と、
自端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子が前記サーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得部と、
前記識別子と、提示対象となる機能との関係を記憶する記憶部と、
前記記憶部を参照して、前記識別子取得部が取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示部と
を備えることを特徴とする端末装置。
【請求項１３】
自サーバ装置から受信した識別子に応じた機能を複数提示する端末装置と通信する通信部と、
前記端末装置の入力情報を取得する情報取得部と、
登録文字列の分類を示す識別子を記憶する記憶部と、
前記情報取得部が取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を、前記記憶部を参照して特定する特定部と、
前記特定部が特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御部と
を備えることを特徴とするサーバ装置。
【請求項１４】
通信部を有する端末装置のコンピュータに、
前記端末装置の入力情報が示す入力文字列に対応する登録文字列に対し、当該登録文字列の分類を示す識別子がサーバ装置により特定されると、前記通信部の通信により当該識別子を取得する識別子取得ステップと、
前記識別子と、提示対象となる機能との関係を記憶する記憶部を参照して、前記識別子取得ステップで取得した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップと
を実行させるためのプログラム。
【請求項１５】
通信部を有するサーバ装置のコンピュータに、
当該サーバ装置から受信した識別子に応じた機能を複数提示する端末装置の入力情報を取得する情報取得ステップと、
登録文字列の分類を示す識別子を記憶する記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、
前記特定ステップで特定した識別子を前記端末装置に送信するよう、前記通信部を制御する送信制御ステップと
を実行させるためのプログラム。
【請求項１６】
入力情報を取得する情報取得ステップと、
登録文字列の分類を示す識別子を記憶する第１記憶部を参照して、前記情報取得ステップで取得した入力情報に応じて、当該入力情報が示す入力文字列に対応する登録文字列の前記識別子を特定する特定ステップと、
前記識別子と、提示対象となる機能との関係を記憶する第２記憶部を参照して、前記特定ステップで特定した識別子に応じて提示対象となる機能を所定の提示方法で複数提示する提示ステップと
を有することを特徴とする機能提示方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２０１２−２４８０１６（Ｐ２０１２−２４８０１６Ａ）
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願番号】特願２０１１−１１９５２７（Ｐ２０１１−１１９５２７）
【出願日】平成２３年５月２７日（２０１１．５．２７）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願日】平成２３年５月２７日（２０１１．５．２７）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]