(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0012】
以下、本発明の実施形態を図面を参照して説明する。
図1は、第1の実施形態の入力支援システムの構成例を示すブロック図である。
図1に示す入力支援システムは、入力ログ記憶手段101と、種類別正解入力記憶手段102と、種類推定手段103とを備えている。
【0013】
入力ログ記憶手段101は、対応づけられている入力欄に過去に入力された情報を入力ログとして記憶する。なお、入力ログ記憶手段101には、対応づけられている入力欄において、入力支援が行われた結果、正しい情報に変換された後の情報が入力ログとして記憶されていてもよい。
【0014】
種類別正解入力記憶手段102(以下、種類別正解入力DB102という。)には、情報の種類別に、その正しい入力を示す情報が記憶されている。種類別の正しい入力を示す情報とは、例えば、当該種類に該当する入力情報の例や候補一覧、正しい表現形式を示した入力フォーマット等である。種類別の正しい入力を示す情報として、入力情報の例や候補一覧などデータ集合が用いられる場合、当該データ集合内の各データは、種類の表現方法において均質なデータであることが好ましい。すなわち、当該データ集合内の各データは、該当する種類について同じ表現方法がとられたデータであることが好ましい。
【0015】
種類別正解入力DB102に保持させる種類の内容や数は任意であるが、本システムが対象とする入力欄に入力させたい情報の種類が含まれていることが好ましい。例えば、種類別正解入力DB102には、予め入力欄に入力されやすい種類について、その正しい入力を示す情報を登録しておいてもよいし、対応づけられている入力欄に試験等で入力した情報を、一例として登録することも可能である。また、組織に所属する人物情報のデータベースや会社の製品情報のデータベースといった他のシステムでも利用されているデータベース等を種類別正解入力DB102として利用することも可能である。また、他のシステムにおいて取得された入力ログを、ある1つの種類の正しい入力を示す情報として利用することも可能である。
【0016】
種類推定手段103は、入力ログ記憶手段101に記憶されている入力ログと、種類別正解入力DB102に記憶されている種類別の正しい入力を示す情報とに基づいて、対象とされた入力欄に入力されるべき情報の種類を推定する。種類推定手段103は、より具体的には、入力欄に入力されるべき情報の種類が、種類別正解入力DB102に記憶されている種類別のフィールド(以下、種類別フィールドという。)のいずれに該当するかを推定する。ここで、フィールドとは、記憶手段に特定のラベルが付されて記憶されている情報の集合体またはそれを記憶している記憶領域をいう。従って、種類推定手段103は、対象の入力欄に入力されるべき情報の種類の推定結果として、その種類が具体的にどのような内容であるかということまで特定しなくてもよい。また、種類推定手段103は、推定の結果、種類別正解入力DB102に記憶されている種類別フィールドのいずれにも該当しないと判定した場合には、推定結果を種類不明としてもよい。
【0017】
種類推定手段103は、例えば、種類別正解入力DB102に記憶されている各種類別フィールドに対して、入力ログ記憶手段101に記憶されている入力ログすなわち過去の入力情報との合致度を算出し、合致度が所定の閾値以上または最大値をとった種類別フィールドを、当該入力欄に入力すべき情報の種類と推定してもよい。合致度は、例えば、種類別正解入力DB102に記憶されている種類別フィールドごとに、入力ログとして記憶されている過去の各入力情報が、当該種類別フィールドに登録されている入力フォーマットに合致するか否かや、入力情報の例または候補一覧に含まれる各情報のいずれかに合致するかを判定して、その結果を基に数値化したものであってもよい。種類推定手段103は、例えば、種類別フィールドごとに合致した入力ログ件数を求め、当該件数(以下、合致ログ件数という。)を合致度としてもよい。また、種類推定手段103は、例えば、入力ログの全件数における合致ログ件数の割合を合致度としてもよい。
【0018】
なお、本実施形態において、入力ログ記憶手段101および種類別正解入力DB102は、例えばデータベース等の記憶装置によって実現される。また、種類推定手段103は、例えば、CPU等のプログラムに従って動作する情報処理装置によって実現される。なお、入力ログ記憶手段101および種類別正解入力DB102は、種類推定手段103がアクセス可能であれば、必ずしも当該入力支援システム自身が備えていなくてもよい。
【0019】
図2は、本実施形態の動作の一例を示すフローチャートである。なお、
図2は、本実施形態の動作のうち、種類推定手段103による入力情報の種類の推定処理の処理フローの一例を示すフローチャートである。
図2に示すように、種類推定手段103は、例えば、入力情報の種類の推定を要求された場合に、入力ログ記憶手段101に記憶されている、推定対象とされた入力欄の入力ログと、種類別正解入力DB102に記憶されている種類別の正しい入力を示す情報とに基づいて、種類別正解入力DB102の種類別フィールドごとに入力ログとの合致度を算出する(ステップS101)。次いで、種類推定手段103は、算出された各種類別フィールドの合致度をもとに、推定結果とする種類別フィールドを特定する(ステップS102)。なお、入力情報の種類の推定処理は、例えば、システム導入時における初期化処理で行われてもよいし、システム稼働中に周期的に行われるようにしてもよい。
【0020】
図3は、種類別正解入力DB102に記憶される情報の一例を示す説明図である。
図3に示すように、種類別正解入力DB102には、1つの種類についてのみ、その正しい入力を示す情報が登録されていてもよい。なお、
図3には、「フィールドA」というフィールド名(識別子)が与えられた種類別フィールドを1つ有する種類別正解入力DB102の例が示されている。また、
図3には、正しい入力を示す情報として、その種別に該当する入力情報の候補一覧が登録されている例が示されている。なお、本例の「フィールドA」は、入力情報の種類が「住所」である種類別フィールドの例である。
【0021】
図4は、入力ログ記憶手段101に記憶される入力ログの一例を示す説明図である。また、
図5は、入力情報の種類の推定結果の一例を示す説明図である。なお、
図5に示す例は、
図3に示す種類別正解入力DB102の例と、
図4に示す入力ログの例とを基に入力情報の種類の推定処理を行った場合の例である。種類推定手段103は、例えば、種類別正解入力DB102に正しい入力情報を示す情報として、候補一覧が登録されている場合には、入力ログの各レコードの内容(過去の入力情報)と、種類別フィールドに含まれる各候補の内容とを比較して、種類別フィールドごとに合致ログ件数を求め、それをもとに合致度を算出してもよい。
【0022】
具体的には、種類推定手段103は、入力ログの各レコードの内容が種類別フィールドに含まれる各候補のどれに該当するかを特定する。種類推定手段103は、種類別フィールドごとに合致した入力ログの件数をカウントし、その結果を基に合致度を算出してもよい。種類推定手段103は、以下の方法を用いて、入力ログの各レコードの内容が種類別フィールドに含まれる各候補に該当するか否かを判定してもよい。種類推定手段103は、例えば、両者のフォーマットが一致しているか否かを判定してもよい。また、種類推定手段103は、各々の情報を文字列情報として扱い、両者が完全一致するか否かを判定してもよい。また、種類推定手段103は、ログの内容である過去の入力文字列に対して候補の内容である候補文字列が前方一致するか否かを判定してもよい。また前方一致した場合、種類推定手段103は、候補文字列の文字数に対して過去の入力文字列が一致した文字数の割合が所定値以上であるか否か等によって判定してもよい。
【0023】
また、例えば、種類別正解入力DB102に正しい入力情報を示す情報として、入力情報の例が登録されている場合、種類推定手段103は、入力ログの各レコードの内容(過去の入力情報)と、種類別フィールドに含まれる各例の内容とを比較してもよい。そして、種類推定手段103は、両文字列の類似性が所定値以上であれば、両者は合致するとして合致ログ件数に含めてもよい。なお、文字列の類似性は、編集距離やn−gramでベクトル化した情報の距離などを利用して算出されてもよい。また、種類推定手段103は、先頭文字列が一致することを重視するなど、文字位置により、重要度を変える重み付きの距離を用いてもよい。
【0024】
なお、複数の種類別フィールドで合致すると判定された場合、種類推定手段103は、各々のフィールドの合致件数にカウントしてもよい。また、種類推定手段103は、前方一致方式を用いる場合などには、一致した文字数の割合がより大きい方や文字列の類似性を示す距離がより近かった方のフィールドに対してのみ合致ログ件数としてカウントしてもよい。
【0025】
図5(a)には、
図3に示す種類別正解入力DB102の例と、
図4に示す入力ログの例とを比較した結果、「フィールドA」内の候補と合致した入力ログのレコードが700件、「その他」すなわちいずれの種類別フィールドの候補とも合致しなかった入力ログのレコードが300件あったことが示されている。種類推定手段103は、このような種類別フィールドごとの合致ログ件数を、その種類別フィールドの合致度として用いてもよい。ここで、いずれの種類別フィールドの候補とも合致しなかったログ件数について、種類推定手段103は、種類不明とするか否かの判定に利用してもよい。
【0026】
また、例えば、種類推定手段103は、合致ログ件数を基に、入力ログ件数(1000件)全体における合致割合を算出し、それを合致度としてもよい。すなわち、種類推定手段103は、合致した入力ログ件数を判定に用いた入力ログ件数の総数で除算した値を合致度としてもよい。
図5(b)には、合致割合を合致度とした場合の合致度の算出結果の例が示されている。
【0027】
種類推定手段103は、このようにして求めた各種類別フィールドの合致度を基に、その入力ログが収集された入力欄に入力されるべき情報の種類を推定する。なお、
図5(b)に示すように、本例では「フィールドA」に対する合致度が0.7、「その他」に対する合致度が0.3である。そこで、種類推定手段103は、推定結果として「フィールドA」を、当該入力欄に入力されるべき情報の種類に該当する種類別フィールドに特定してもよい(
図5(c)参照。)。ここで、仮に「その他」の合致割合が最大値をとった場合、種類推定手段103は、推定結果を該当フィールドなし、すなわち種類不明としてもよい。
【0028】
また、
図6は、種類別正解入力DB102に記憶される情報の他の例を示す説明図である。
図6に示すように、種類別正解入力DB102は、同一の記入項目に対して複数の記載形式をとるものを異なる種類別フィールドとして記憶してもよい。なお、
図6には、「フィールドA」というフィールド名が与えられた種別フィールドと、「フィールドB」というフィールド名が与えられた種類別フィールドとを有する種類別正解入力DB102の例が示されている。なお、本例では、「フィールドA」と「フィールドB」のどちらにも「住所」を表す情報群(候補一覧)が登録されている。より具体的には、「フィールドA」には「都道府県名から始まる住所」である情報の候補一覧が登録されており、「フィールドB」には「都道府県名を除いた住所」である情報の候補一覧が登録されている。また、
図6に示す例では、「フィールドA」と「フィールドB」とで同一レコードに登録されている情報は互いに同じ住所を示している。すなわち、種類別フィールド内の各レコードは互いに対応づけられている。なお、種類別フィールド内の各レコードは必ずしも対応づけられていなくてもよい。
【0029】
また、
図7は、入力情報の種類の推定処理の他の例を示す説明図である。なお、
図7に示す例は、
図6に示す種類別正解入力DB102の例と、
図4に示す入力ログの例とを基に種類の推定処理を行った場合の例である。
図7(a)に示すように、種類別フィールド内の情報と入力ログとを比較した結果、「フィールドA」では合致ログ件数が700件、「フィールドB」では合致ログ件数が200件、「その他」すなわちいずれの種類別フィールドの候補とも合致しなかったログ件数が100件であったとする。そのような場合には、種類推定手段103は、
図7(b)に示すように、合致ログ件数をもとに、入力ログ件数(1000件)全体における合致割合を算出し、「フィールドA」の合致度を0.7、「フィールドB」の合致度を0.2、「その他」の合致度を0.1としてもよい。なお、
図7(c)には、以上の結果から「フィールドA」が、推定対象の入力欄の種類に該当する種類別フィールドとして特定されたことが示されている。
【0030】
また、種類推定手段103は、
図8に示すように、入力欄の種類の推定処理の結果、推定対象の入力欄の種類に該当するとして特定された種類別フィールドの各レコードに対して、入力ログと合致した件数に基づくスコアを算出してもよい。そして、種類推定手段103は、算出したスコアを、種類別正解入力DB102に保持させてもよく、または、推定結果とともに出力してもよい。ここで、各レコードのスコアは、入力ログとの合致度に基づく値であれば、特に限定されない。各レコードのスコアは、例えば、合致ログ件数そのままであってもよいし、それをもとに算出された合致割合であってもよい。なお、各レコードのスコアは、推定処理ごとに新たに算出されてもよいし、過去に算出されたスコアからの累計値であってもよい。
【0031】
このようなレコード別のスコアを推定結果と一緒に提供すれば、後段の処理手段が入力候補の推薦をする際の指標とできるなど、より細やかな入力支援が可能になる。
【0032】
また、
図9は、種類別正解入力DB102に記憶される情報の他の例を示す説明図である。
図9に示すように、種類別正解入力DB102には、それぞれが異なる記入項目に対応づけられている複数の種類別フィールドが登録されていてもよい。
図9には、「フィールドA」、「フィールドB」、「フィールドC」という3つの種類別フィールドを有する種類別正解入力DB102の例が示されている。本例では、「フィールドA」には「所属」を表す情報群(本例では、候補一覧)が登録されている。また、「フィールドB」には「名字」を表す情報群(本例では、候補一覧)が登録されている。また、「フィールドC」には「メールアドレス」を表す情報群(本例では、候補一覧)が登録されている。このように、種類別正解入力DB102は、それぞれが異なる記入項目(「所属」、「名字」、「メールアドレス」等)に対応づけられている複数の種類別フィールドを保持していてもよい。また、
図9に示す例では、各種類別フィールドの各要素が各レコード間で互いに対応づけられている。すなわち、同じ列に位置するレコードには同じ対象に関する情報が登録されている。なお、このようなレコード間の対応づけはなくてもよい。
【0033】
また、
図10は、
図9に示す種類別正解入力DB102の情報を利用して、入力情報の種類の推定処理を行った場合の例を示す説明図である。例えば、入力ログとして、
図10(a)に示す入力情報(例えば、1000件)が記憶されていたとする。
図10(b)には、そのような入力ログの各レコードの内容(過去の入力情報)と、
図9に示した種類別正解入力DB102内の各種類別フィールドに含まれる各レコードの内容(入力情報の候補一覧)とを比較した結果得られた各種類別フィールドの合致ログ件数、合致割合および推定結果が示されている。具体的には、
図10(b)には、「フィールドA」の合致ログ件数が50件、「フィールドB」の合致ログ件数が150件、「フィールドC」の合致ログ件数が700件、「その他」の合致ログ件数が100件であることが示されている。また、
図10(b)には、そのような合致ログ件数をもとに算出した合致度は「フィールドA」が0.05、「フィールドB」が0.15、「フィールドC」が0.7、「その他」が0.1であること、および、その条件のもと、最も合致度の高い「フィールドC」が推定結果とされたことが示されている。
【0034】
また、
図11は、種類別正解入力DB102に記憶される情報の例および入力情報の種類の推定処理の例を示す説明図であり、
図11(a)は、種類別正解入力DB102に記憶される情報の他の例を示す説明図である。
図11(a)に示すように、種類別正解入力DB102は、粒度の異なる情報群が登録された種類別フィールドを連結させて1つの種類別フィールドとして登録するなど、複数の種類別フィールドを1つの連結された種類別フィールドを登録するものであってもよい。
図11(a)に示す例において、「フィールドA」と「フィールドB」には所定の情報(本例では、住所を示す情報)を分割したものが登録されている。なお、本例では「フィールドA」の方が情報の粒度が大きいものとする。
【0035】
種類推定手段103は、そのような場合に、連結フィールドを1つの種類別フィールドとして扱って入力ログとの合致判定を行ってもよい。
図11(a)に示す例であれば、種類推定手段103は、「ID2」による種類別フィールドの区分でなく、「ID1」による種類別フィールドの区分を用いればよい。具体的には、種類推定手段103は、フィールドA,Bの各レコードの情報を連結した情報を、当該連結フィールドの各レコードの情報として扱えばよい。本例であれば、フィールドAの1レコード目に登録されている候補である「大阪市」とフィールドBの1レコード目に登録されている候補である「北区」とを連結させる。種類推定手段103は、連結された「大阪市北区」が当該連結フィールドの1レコード目に登録されている候補であるとして、入力ログの各レコードと比較すればよい。
【0036】
例えば、入力ログとして、
図11(b)に示す入力情報(例えば、6件)が記憶されていたとする。
図11(c)には、そのような入力ログの各レコードの内容と、
図11(a)に示す種類別正解入力DB102の「ID1」の区分による種類別フィールドの各レコードの内容とを比較した結果得られた各種類別フィールドの合致ログ件数、合致割合と、推定結果とが示されている。具体的には、
図11(b)および
図11(c)には、「連結フィールドAB」の合致ログ件数が6件、「その他」の合致ログ件数が0件であることや、そのような合致ログ件数をもとに算出した合致度は、「連結フィールドAB」が1.0、「その他」が0であること、および、その条件のもと、最も合致度の高い「連結フィールドAB」が推定結果とされたことが示されている。
【0037】
なお、
図11(a)では、「ID1」の区分による種類別フィールドとして、「連結フィールドAB」のみを有する例を示したが、他の種類別フィールド(連結フィールドを含む)を有していてもよい。そのような場合には、種類推定手段103は、他の種類別フィールドについても合致度を算出し、最も合致度の高い種類別フィールドを推定結果とすればよい。
【0038】
また、種類推定手段103は、本例のような情報の粒度の大小関係にある種類別フィールドを連結させた連結フィールドを推定結果とする場合、さらに当該連結フィールドを構成している種類別フィールドに含まれる各レコードの中から特に定めた一部の候補(要素)を優先要素として出力してもよい。優先要素とする候補は、入力ログの傾向から当該種類別フィールド内において過去に有効に用いられた候補や、特に入力情報に用いられやすい候補であってもよい。
【0039】
種類推定手段103は、例えば、種類の推定結果とした種類別フィールドが連結フィールドであった場合、その連結フィールドをなす種類別フィールドのうち粒度の大きい方の種類別フィールドにおいて入力ログと合致したレコードの内容を取得し、その和集合を優先要素として出力してもよい。
図11(d)は、優先要素の取得例を示す説明図である。
図11(d)に示す例では、連結フィールドABで連結された種類別フィールドのうち粒度の大きい情報を扱っている種類別フィールドである「フィールドA」から、入力ログと合致したレコードの内容である「堺市」を取得して優先要素としている。
【0040】
また、
図12に示すように、種類推定手段103は、推定結果とした種類別フィールドが連結フィールドでない場合であっても、当該種類別フィールド内の各レコードに対して実施したクラスタリングの結果を利用して優先要素を取得してもよい。
図12は、レコード内容の類似度に基づくクラスタリングを利用した優先要素の取得例を示す説明図である。例えば、
図12(a)に示すように、事前処理として、各種類別フィールドにおいて、レコード内容の類似性に基づくクラスタリングを実施しておく。クラスタリングは、例えば、レコード内容が文字列であれば文字列間の距離に基づいて行われてもよい。具体的には、編集距離やn−gramでベクトル化した情報の距離などが利用される。なお、先頭文字列が一致することを重視するなど、文字位置により、重要度を変える重み付きの距離がクラスタリングに用いられてもよい。
【0041】
例えば、入力ログとして、
図12(b)に示す入力情報(例えば、6件)が記憶されていたとする。
図12(c)には、そのような入力ログの各レコードの内容と、
図12(a)に示す種類別正解入力DB102の各種類別フィールドに含まれる各レコードの内容とを比較した結果得られた各種類別フィールドの合致ログ件数、合致割合および推定結果が示されている。具体的には、
図12(b)および
図12(c)には、「フィールドA」の合致ログ件数が6件、「その他」の合致ログ件数が0件であることや、そのような合致ログ件数をもとに算出した合致度は「フィールドA」が1.0、「その他」が0であること、および、その条件のもと、最も合致度の高い「フィールドA」が推定結果とされたことが示されている。
【0042】
種類推定手段103は、このような推定処理において、入力ログが種類別フィールドのいずれのレコードに該当するかを特定した結果を保持しておく。そして、種類推定手段103は、推定結果とする種類別フィールドが決定した際に、その種類別フィールドにおいて入力ログと合致したレコードを含むクラスタを取得して、その和集合の要素を優先要素としてもよい。なお、
図12(a)において、網掛けの四角の目印はクラスタの和集合とされる位置を示している。また、範囲αは優先要素として取得されるレコード範囲を示している。また、
図12(d)は、本例において取得される優先要素の例を示している。
【0043】
また、種類推定手段103は、
図13に示すように、有効度付きの入力ログを利用して推定処理を行ってもよい。
図13(a)は、有効度付きの入力ログの例を示す説明図である。また、
図13(b)は、有効度付きの入力ログを利用した推定処理の結果例を示す説明図である。なお、
図13(a)には、有効度を、対応するレコードの入力内容で承認された場合を1、承認されなかった場合を0とした入力ログの例が示されている。このような有効度付きのログは、例えば、ログを登録する際に当該入力に対するエラー判定の結果を待って、その結果と一緒に登録することによって得られる。種類推定手段103は、例えば、入力ログの各レコードに付されている有効度を重みとして扱うことで合致度を数値化してもよい。種類推定手段103は、例えば、この有効度を重みとして扱い、合致ログ件数を算出する際に、ログ1件につき1を加算するのではなく、その重みを加算した結果を重み付き合致ログ件数としてもよい。なお、合致度として合致割合を用いる場合、種類推定手段103は、そのようにして得た値(重み付き合致ログ件数、すなわち有効度の合計値)を入力ログに含まれる各レコードの有効度の総和で除算すればよい。
【0044】
なお、
図13(b)には、
図13(a)に示した入力ログの各レコードの内容と、
図9に示した種類別正解入力DB102の各レコードの内容とを比較した結果得られた各種類別フィールドの合致ログ件数、重み付き合致ログ件数、合致割合および推定結果が示されている。なお、
図13(b)には、「フィールドA」と「フィールドB」の合致ログ件数がともに50件であったが、該当ログレコードに付されている有効度がいずれも0であったため、重み付き合致ログ件数がともに0件となっている例が示されている。
【0045】
また、種類推定手段103は、
図14に示すように、入力情報の種類の推定処理の結果、推定対象の入力欄の種類に該当するとして特定された種類別フィールドの各レコードに対して、入力者を示す情報付きのログを利用したスコアを算出してもよい。そして、種類推定手段103は、算出したスコアを、種類別正解入力DB102に保持させてもよく、または、推定結果とともに出力してもよい。ここで、各レコードのスコアは、指定されたユーザの入力ログとの合致度に基づく値であれば、特に限定されない。
【0046】
図14(a)は、種類別正解入力DB102内の各レコードのスコア付きの推定処理においてスコアの算出を行った例を示す説明図である。また、
図14(b)は、入力者情報付きの入力ログと、その入力ログに対応づけられている有効度の例を示す説明図である。なお、このような入力者を示す情報付きの入力ログは、例えば、システムログイン時に入力欄への入力者となるユーザを識別するID等を入力するなどの認証システムを利用し、ログを登録する際にログイン時に入力されたIDを該ログと一緒に登録することによって得られる。種類推定手段103は、例えば、推定処理において、入力ログが種類別フィールドのいずれのレコードに該当するかを特定した結果を保持しておく。種類推定手段103は、推定結果とする種類別フィールドが決定した際に、その種類別フィールドにおいて、指定されたユーザ(例えば、現在ログイン中のユーザ)ごとにスコアを算出してもよい。種類推定手段103は、例えば、指定されたユーザのIDが付された入力ログと合致したレコードに対して1を加算してスコアを算出してもよく、またはログに有効度が付されている場合はその有効度を加算してスコアを算出してもよい。その際、種類推定手段103は、指定されたユーザが正しい内容で過去に多く入力したレコードがあれば、算出したスコアがより大きくなるようにスコアを調整してもよい。
【0047】
このような個々のユーザに対応した各レコードのスコアを推定結果と一緒に提供すれば、後段の処理手段が入力候補の推薦をする際にそのユーザに適した候補を推薦できるなど、より細やかな入力支援が可能になる。
【0048】
以上のように、本実施形態によれば、入力欄に対して予め情報の粒度も含めそこに何が入力されるのかといった入力されうるデータの種類を細かく指定しておかなくてもよい。本実施形態の入力支援システムは、対象とする入力欄に過去に入力された情報のログと、種類別正解入力DB102内の情報とに基づいて、その入力欄に入力されるべき情報の種類に合致した情報群や入力フォーマットなど、正しい入力を示す情報を特定し、推定結果として提供することができる。そして、この推定結果を利用して、エラー判定を行ったり、予測変換を行ったりする等の入力支援を、様々な入力欄に対して実施できる。また、本実施形態によれば、入力欄に対して予め細かな指定をしなくても、種類別正解入力DB102と、正しい入力がされたときのログとを組み合わせることによって、任意の情報の種類を推定結果として動的に導き出すことができる。そのため、きめ細やかな入力支援システムを簡単に導入できる。
【0049】
例えば、本実施形態によれば、種類別正解入力DB102に登録する種類の区分けの制御によって、同じ住所でも都内の住所が入りやすいのか、一般的な住所が入りやすいかといった細かい粒度の判定もできる。よって、この判定により予測変換やエラー判定の精度を上げることができる。また、本実施形態によれば、システム稼働中であっても、入力ログの設定次第で入力欄に入力させる情報の種類や粒度を変えることが可能である。
【0050】
実施形態2.
次に、本発明の第2の実施形態を説明する。
図15は、第2の実施形態の入力支援システムの構成例を示すブロック図である。
図15に示す入力支援システムは、
図1に示す第1の実施形態と比べて、新たにエラー検出手段104を備えている点が異なる。
【0051】
エラー検出手段104は、種類推定手段103から出力される推定結果およびその他の情報(例えば、優先要素の情報や、レコード別のスコア等)に基づいて、対象とする入力欄に新たに入力された情報に対してエラー判定を行い、エラーを検出する。また、エラー検出手段104は、エラー判定の結果、エラーが検出された場合にはその旨を示すメッセージを出力する。
【0052】
エラー検出手段104は、例えば、対象とする入力欄に新たに入力された情報と推定結果として得られた種類別フィールド内に含まれる正しい入力を示す情報とが合致するか否かを判定し、合致しなければエラーと判定してもよい。ここでの合致判定は、基本的には、種類推定手段103において合致ログ件数を算出する際に行う合致判定と同様でよい。すなわち、種類別正解入力DB102に正しい入力を示す情報として入力フォーマットが登録されている場合、エラー検出手段104は、対象とする入力欄に新たに入力された情報が入力フォーマットと一致するか否かによってエラーを判定してもよい。また、例えば、正しい入力を示す情報として入力情報の候補の一覧が登録されている場合、エラー検出手段104は、推定結果として得られた種別フィールドを検索フィールドとして、その中から対象とする入力欄に新たに入力された情報と合致する候補を検索する。そして、エラー検出手段104は、合致する候補がなければエラーと判定してもよい。また、例えば、正しい入力を示す情報として入力情報の例が登録されているとする。この場合、エラー検出手段104は、両者のフォーマットが一致しているか否かによってエラーを判定してもよいし、各々の情報を文字列情報として扱い、両文字列の類似性が所定値以上であるか否かによってエラーを判定してもよい。
【0053】
なお、本実施形態において、エラー検出手段104は、例えば、CPU等のプログラムに従って動作する情報処理装置によって実現される。
【0054】
図16は、本実施形態の入力支援システムの動作の一例を示すフローチャートである。まず、入力ログ記憶手段101には、対象とする入力欄に過去に入力された情報が入力ログとして記憶されているとする(ステップS201)。次いで、種類推定手段103は、入力ログ記憶手段101に記憶されている当該入力欄の入力ログと、種類別正解入力DB102に記憶されている情報、より具体的には種類別の正しい入力を示す情報とに基づいて、当該入力欄の入力情報の種類を推定する(ステップS202)。ここでは、種類推定手段103は、推定結果として、当該入力欄の入力情報の種類に該当する種類別フィールドを示す情報を少なくとも得る。
【0055】
ここで、対象とする入力欄に新たな情報の入力がなされると(ステップS203のYes)、エラー検出手段104は、その入力情報に対してエラー判定を行う(ステップS204)。エラーが検出された場合(ステップS205のYes)、エラーメッセージを表示する(ステップS206)。
【0056】
図17は、エラーメッセージの表示例を示す説明図である。エラー検出手段104は、例えば、対象の入力欄への新たな入力情報として「yamamoto@sl.aaa.com」という入力を受け付けたとする。なお、本例では、当該入力欄に入力すべき情報の種類の推定結果として、
図3に示す種類別正解入力DB102の「フィールドA」を示す情報を得ていたとする。なお、
図3に示す種類別正解入力DB102は、「フィールドA」という1つの種類別フィールドを有しており、「フィールドA」には「住所」を表す情報群(候補一覧)が登録されている。
【0057】
このような場合、エラー検出手段104は、推定結果とされた種類別フィールドを検索フィールドに設定し、入力情報と合致するものがその検索フィールドの候補一覧から見つかればエラーなしとしてもよい。一方、入力情報と合致するものが見つからなければ、入力ミスである可能性があるとして、その旨を通知してもよい。エラー検出手段104は、例えば、
図17(a)に示すように、「書くべき内容を間違えていませんか」といったメッセージ(OUT1−1)を出力してもよい。また、エラー検出手段104は、推定結果とされた種類別フィールドに名称(例えば、「住所」など)がついている場合には、
図17(b)に示すように、その名称を利用して「ここには『住所』を書いてください」といったメッセージ(OUT1−2)を出力してもよい。この他にも、例えば、種類別正解入力DB102に情報の種類の説明が登録されている場合などには、エラー検出手段104は、その説明を利用して「ここには、『(例えば、都道府県名から始まる住所)』を書いてください。」といったメッセージを出力してもよい。
【0058】
また、エラー検出手段104は、種類別正解入力DB102が複数の記載形式に対応した種類別フィールドを有している場合、推定結果とされた種類別フィールドのみを検索フィールドに設定するのではなく、他の種類別フィールドも検索フィールドに加えてもよい。なお、一度推定結果とされた種類別フィールドを検索した結果、合致するものが見つからなければ、他の種類別フィールドを検索フィールドに加えて検索しなおすといったやり方も可能である。
図18〜
図21は、種類別正解入力DB102が複数の記載形式に対応した種類別フィールドを有する場合のエラー判定の例およびエラーメッセージの例を示す説明図である。
【0059】
本例において、エラー検出手段104は、対象の入力欄に入力すべき情報の種類の推定結果として、
図6に示す種類別正解入力DB102の「フィールドA」を示す情報を得ていたとする。なお、
図6に示す種類別正解入力DB102は、「フィールドA」と「フィールドB」の2つの種類別フィールドを有しており、「フィールドA」と「フィールドB」にはいずれにも「住所」を表す情報群(候補一覧)が登録されているものとする。また、種類別正解入力DB102には、「フィールドA」の方がより詳細な記載形式をとっているといった種類別フィールド間の関係を示す情報が予め保持されているものとする。
【0060】
ここで、対象の入力欄への新たな入力情報として「大阪市堺市」という入力を受け付けたとする。
図18にCASE1として示す例は、まず推定結果とされた種類別フィールドである「フィールドA」を検索フィールドとした上で、検索フィールド内の各候補の中から入力情報と合致(例えば、前方一致)するものを探した結果、2つの候補が見つかったときのエラー判定結果の例である。この場合のエラー判定結果は「エラーなし」となる。
【0061】
他方、別のタイミングで、対象の入力欄への新たな入力情報として「堺市」という入力を受け付けたとする。
図19にCASE2として示す例は、推定結果とされた種類別フィールドである「フィールドA」を検索フィールドとしただけでは入力情報と合致するものが見つからなかったことを前提とする。これに加え、さらに、
図19にCASE2として示す例では、記入項目が同一の種類別フィールドである「フィールドB」を検索フィールドに加えて検索した結果、推定結果とされた種類別フィールドとは異なる種類別フィールドに合致するデータが見つかったときのエラー判定結果の例である。この場合のエラー判定結果は「エラーあり」となる。
【0062】
エラー検出手段104は、このような場合には、
図17に示すようなエラーメッセージ以外にも、次のようなエラーメッセージを表示してもよい。すなわち、エラー検出手段104は、推定結果とされた種類別フィールドと、入力情報が合致した種類別フィールドとの関係(例えば、どちらが詳細であるか)がわかれば、そのような関係に基づいてエラーメッセージを作成してもよい。例えば、
図20(a)に示すように、入力情報が推定結果とされた種類別フィールドとは異なる種類別フィールドであって詳細でない方の種類別フィールドに合致したとする。この場合、エラー検出手段104は、「詳細な情報を書いてください」といったメッセージ(OUT2−1)を出力してもよい。また、エラー検出手段104は、種類別フィールドにフィールド名が与えられている場合には、さらにそれを利用して「詳細な住所を書いてください」といったメッセージ(OUT2−2)を出力してもよい。
【0063】
また、入力情報が推定結果とされた種類別フィールドとは異なる種類別フィールドであって詳細な方の種類別フィールドと合致したとする。この場合、エラー検出手段104は、両者のレコード内容を比較して、差分を検出し、検出された差分を利用して「ここでは『○○』(本例であれば、大阪府)は不要です」といったメッセージを出力してもよい。
【0064】
また、
図21にCASE3として示す例は、検索フィールドに記入項目が同一の種類別フィールドである「フィールドB」を加えても合致するものが見つからなかったときのエラー判定結果の例である。この場合のエラー判定は「エラーあり」となる。このような場合、エラー検出手段104は、
図17に示したようなエラーメッセージを出力してもよい。
【0065】
また、エラー検出手段104は、種類別正解入力DB102が複数の種類別フィールドを有している場合に、それらの間の記入項目の同一性の有無に関わらず、全ての種類別フィールドを検索フィールドに設定してもよい。なお、この場合も、一度推定結果とされた種類別フィールドを検索した結果合致するものがなければ、他の種類別フィールドを検索フィールドに加えて検索しなおすといったやり方も可能である。
図22〜
図25は、種類別正解入力DB102が記入項目の同一性を有さないものを含む複数の種類別フィールドを有する場合のエラー判定の例およびエラーメッセージの例を示す説明図である。
【0066】
本例において、エラー検出手段104は、対象の入力欄に入力すべき情報の種類の推定結果として、
図9に示す種類別正解入力DB102の「フィールドC」を示す情報を得ていたとする。なお、
図9に示す種類別正解入力DB102は、「フィールドC」の他に、「フィールドA」と「フィールドB」を有しており、これらの種類別フィールドは、記入項目は異なるが、各レコードがお互いに対応づけられている。
【0067】
ここで、対象の入力欄への新たな入力情報として「yamamoto@sl.aaa.com」という入力を受け付けたとする。
図22にCASE1として示す例は、まず推定結果とされた種類別フィールドである「フィールドC」を検索フィールドとした上で、検索フィールド内の各候補の中から入力情報と合致(例えば、前方一致)するものを探した結果、1つの候補が見つかったときのエラー判定結果の例である。この場合のエラー判定結果は「エラーなし」となる。
【0068】
他方、別のタイミングで、対象の入力欄への新たな入力情報として「山本」という入力を受け付けたとする。
図23にCASE2として示す例は、推定結果とされた種類別フィールドである「フィールドC」を検索フィールドとしただけでは入力情報と合致するものが見つからなかったことを前提とする。これに加え、さらに、
図23にCASE2として示す例では、残りの種類別フィールド「フィールドB」,「フィールドC」を加えて検索した結果、推定結果とされた種類別フィールドとは異なる種類別フィールドである「フィールドB」に合致するデータが見つかったときのエラー判定結果の例である。この場合のエラー判定結果は「エラーあり」となる。
【0069】
エラー検出手段104は、このような場合には、
図17に示すようなエラーメッセージ以外にも、次のようなエラーメッセージを表示してもよい。すなわち、エラー検出手段104は、例えば、
図24(a)に示すように、入力情報の種類が異なっていることを暗に示せるような「入力情報を確認してください。」といったメッセージ(OUT3−1)を出力してもよい。また、エラー検出手段104は、例えば、種類別フィールドにフィールド名が与えられている場合には、さらにそれを利用して「『名前』ではなく『メールアドレス』を書いてください」といったメッセージ(OUT3−2)を出力してもよい。なお、メッセージ(OUT3−2)で示す例は、合致したものが見つかった種類別フィールドである「フィールドB」の名称が「名前」であり、推定結果とされた種類別フィールドである「フィールドC」の名称が「メールアドレス」である場合の例である。
【0070】
また、
図25にCASE3として示す例は、検索フィールドに残りの種類別フィールドを加えても合致するものが見つからなかったときのエラー判定結果の例である。この場合のエラー判定は「エラーあり」となる。このような場合、エラー検出手段104は、
図17に示したようなエラーメッセージを出力してもよい。
【0071】
また、エラー検出手段104は、推定結果の他に優先要素が与えられる場合には、それらを利用してエラー判定を行ってもよい。
図26〜
図27は、推定結果の他に優先要素が与えられる場合のエラー判定の例を示す説明図である。エラー検出手段104は、例えば、対象の入力欄に入力すべき情報の種類の推定結果として、
図11(a)に示す種類別正解入力DB102の「連結フィールドAB」を示す情報を得ていたとする。また、エラー検出手段104は、合わせて
図11(d)に示す優先要素の情報も得ていたとする。なお、
図11(a)に示す種類別正解入力DB102の「連結フィールドAB」は、「フィールドA」と「フィールドB」とが連結されたものであって、この2つのフィールドにはいずれにも「住所」を表す情報群が登録されている。また、種類別正解入力DB102には、「フィールドA」の方が情報の粒度が大きいといった種類別フィールド間の関係を示す情報が予め保持されているものとする。また、
図11(d)に示す優先要素の情報とは、優先要素フィールドを「フィールドA」とし、該優先要素フィールドにおいて「堺市」を優先要素とする旨の情報である。
【0072】
ここで、対象の入力欄への新たな入力情報として「浪速区」という入力を受け付けたとする。
図26に示す例では、まず推定結果とされた種類別フィールドである「連結フィールドAB」内の各候補に今回の入力情報を含むか否かが判断される。また、
図26に示す例では、この判断に加え、「連結フィールドAB」として連結された「フィールドA」および「フィールドB」の各候補から今回の入力情報と合致(例えば、前方一致)するものがあるか否かが判断される。この結果、
図26では、「フィールドB」に合致するものが検索されたことが示されている。なお、本例の場合、合致したレコードに含まれる優先要素フィールドの内容が「大阪市」であって優先要素ではない。そこで、
図26に示す例では、エラー検出手段104は、入力ミスの可能性があるとして注意喚起をする旨の判定結果を表示している。
【0073】
このように、推定対象とされた種類別フィールドに合致する入力情報であってもその内容が優先要素でない、または優先要素を含まないことがある、この場合、エラー検出手段104は、
図27に示すような、その内容が始めて入力されるものである旨を確認させるメッセージを出力してもよい。なお、
図27には、『「大阪市」に関するデータが入力されたのはこれが始めてです。念のため間違ってないかご確認ください』というエラーメッセージ(OUT4)を出力する例が示されている。
【0074】
このように、優先要素を利用すれば、過去の入力傾向に基づいてエラー判定を行うことも可能である。
【0075】
また、エラー検出手段104は、推定結果とともに推定結果とされた種類別フィールドの各レコードに対するスコアが与えられる場合には、それを利用してエラー判定を行ってもよい。例えば、エラー検出手段104は、入力情報が、スコアが所定の値よりも小さい候補と合致した場合に、過去にあまり入力されていないメッセージである旨を通知するなど、同様の確認メッセージを出力してもよい。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合であっても、エラー検出手段104は、取得されたレコードの内容に合致する入力ログが何件含まれているかをカウントするなどしてスコアを算出してもよい。そして、エラー検出手段104は、算出したスコアを利用してエラー判定を行ってもよい。
【0076】
以上のように、本実施形態によれば、予め入力されうるデータの種類を指定しておかなくても、種類推定手段103による推定結果を利用して、エラー検出手段104がエラー判定を行うことできるので、精度のよい入力情報を得られる。
【0077】
実施形態3.
次に、本発明の第3の実施形態を説明する。
図28は、第3の実施形態の入力支援システムの構成例を示すブロック図である。
図28に示す入力支援システムは、
図1に示す第1の実施形態と比べて、新たに入力情報予測手段105を備えている点が異なる。
【0078】
入力情報予測手段105は、種類推定手段103から出力される推定結果、および、その他の情報(例えば、優先要素の情報や、レコード別のスコア等)に基づいて、対象とする入力欄に新たに入力された情報から該入力欄に入力されるべき情報を予測して、ユーザに提示する。
【0079】
なお、本実施形態において、入力情報予測手段105は、例えば、CPU等のプログラムに従って動作する情報処理装置によって実現される。
【0080】
図29は、本実施形態の入力支援システムの動作の一例を示すフローチャートである。なお、以下では、
図29におけるステップS201〜S203は
図16に示した第2の実施形態と同様であるため、説明を省略している。
【0081】
本実施形態では、対象とする入力欄に新たな入力がなされると(ステップS203のYes)、入力情報予測手段105は、その入力情報と、少なくとも推定結果とされた種類別フィールドを示す情報とに基づいて、当該入力欄に入力されるべき、正しい入力情報を予測する(ステップS301)。そして、入力情報予測手段105は、その結果を予測変換候補として出力する(ステップS302)。
【0082】
図30は、入力情報予測手段105による予測処理の例を示す説明図である。本例において、入力情報予測手段105は、対象の入力欄に入力すべき情報の種類の推定結果として、
図3に示す種類別正解入力DB102の「フィールドA」を示す情報を得ていたとする。なお、
図3に示す種類別正解入力DB102は、「フィールドA」という1つの種類別フィールドを有しており、「フィールドA」には「住所」を表す情報群(候補一覧)が登録されている。
【0083】
ここで、対象の入力欄への新たな入力情報として「堺市」という入力を受け付けたとする。このような場合、入力情報予測手段105は、推定結果とされた種類別フィールドである「フィールドA」を検索フィールドに設定し、その検索フィールドの候補一覧から、入力情報を含むものを取得して、それを予測変換候補としてもよい。
図30に示す例では、「大阪府堺市北区」と「大阪府堺市中区」の2つのレコードが取得されている。また、入力情報予測手段105は、取得された各レコードについて入力ログに基づくスコアを取得し、取得されたスコアに基づいて予測変換候補を順位付けした上で、取得された各レコードを提示してもよい。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105は、取得されたレコードの内容に合致する入力ログが何件含まれているかをカウントしてそれをスコアとしてもよい。なお、
図30に示す例では、1番目の予測変換候補としてスコアの最も高かった「大阪市堺市中区」と、2番目の予測変換候補として次にスコアの高かった「大阪市堺市北区」が提示される。
【0084】
このように、「堺市」と入力しただけで、それを含みかつ当該入力欄に入力されるべき情報として記載形式のあった情報が予測変換候補として提示される。よって、ユーザに正しい記載形式の情報を入力させることができるだけでなく、ユーザの入力の手間を省くこともできる。また、本例では、入力ログから予測変換候補を生成するのではなく、入力ログはあくまで入力情報の種類を推定するためおよび候補のランク付けに用いられる。内容の候補は、種類別正解入力DB102内の情報を利用して取得されるため、過去に「堺市」という入力がない場合にも正しい入力情報を予測して変換候補を提示できる。
【0085】
また、
図31は、入力情報予測手段105による予測処理の他の例を示す説明図である。本例において、入力情報予測手段105は、対象の入力欄に入力すべき情報の種類の推定結果として、
図6に示す種類別正解入力DB102の「フィールドA」を示す情報を得ていたとする。なお、
図6に示す種類別正解入力DB102は、「フィールドA」と「フィールドB」の2つの種類別フィールドを有しており、「フィールドA」と「フィールドB」にはいずれにも「住所」を表す情報群が登録されている。また、種類別正解入力DB102には、「フィールドA」の方がより詳細な記載形式をとっているといった種類別フィールド間の関係を示す情報が予め保持されているものとする。また、本例では、少なくともこれら種類別フィールド内の各レコードはお互いに対応づけられているものとする。
【0086】
ここで、対象の入力欄への新たな入力情報として「堺市」という入力を受け付けたとする。このような場合、入力情報予測手段105は、まず推定結果とされた種類別フィールドである「フィールドA」と、それと記入項目を同じくする「フィールドB」とを検索フィールドとした上で、検索フィールド内の各候補から入力情報に合致(前方一致)するものを検索してもよい。そして、該当するものがあれば、入力情報予測手段105は、推定結果とされた種類別フィールドの当該レコード位置でのレコード内容を、予測変換候補として取得してもよい。
【0087】
図31に示す例では、「フィールドB」において「堺市北区」と「堺市中区」の2つのレコードが該当したため、「フィールドA」においてそれら2つのレコードに対応するレコードの内容である「大阪府堺市北区」と「大阪府堺市中区」とが予測変換候補として取得されている。
【0088】
そして、入力情報予測手段105は、取得されたレコードについて入力ログに基づくスコアを取得し、得られたスコアに基づいて予測変換候補を順位付けして提示する。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105がスコアを算出してもよい。
図31に示す例では、1番目の予測変換候補としてスコアの最も高かった「大阪市堺市中区」と、2番目の予測変換候補として次にスコアの高かった「大阪市堺市北区」が提示される。
【0089】
このように、対象とする入力欄に入力されるべき情報の種類が特定されれば、あとは入力情報をそのような種類の情報に変換できる。本例の場合、「堺市」と入力しただけで、入力文字を含みかつ入力欄の記載形式のあった候補が提示されるので、ユーザに正しい記載形式の情報を入力させることができるだけでなく、ユーザの入力の手間を省くこともできる。また、本実施形態では、このような予測変換機能を、「堺市」という入力ログがない状態であっても行うことができる。また、本例のように、種類別正解入力DB102に記憶された情報を変換知識として利用すれば、ユーザは種類がどのようなものであるかを意識せずに予測変換候補を得ることもできる。なお、種類別正解入力DB102に記憶された情報を変換知識として利用せずに、種類別正解入力DB102に登録されている入力フォーマットや種類の説明等を利用してもよい。このとき、入力情報予測手段105は、この入力フォーマットや種類の説明等に基づき、他のシステムの変換処理等を利用して、入力情報を記載形式のあった情報に変換し、それを予測変換候補として提示してもよい。
【0090】
また、
図32は、入力情報予測手段105による予測処理の他の例を示す説明図である。本例において、入力情報予測手段105は、対象の入力欄に入力すべき情報の種類の推定結果として、
図9に示す種類別正解入力DB102の「フィールドC」を示す情報を得ていたとする。なお、
図9に示す種類別正解入力DB102は、「フィールドC」の他に、「フィールドA」と「フィールドB」を有しており、これら種類別フィールドは、記入項目は異なるが、各レコードがお互いに対応づけられている。
【0091】
ここで、対象の入力欄への新たな入力情報として「山本」という入力を受け付けたとする。このような場合、入力情報予測手段105は、全て種類別フィールドを検索フィールドとした上で、これら検索フィールド内の各候補から入力情報を含むものを検索してもよい。そして、入力情報予測手段105は、該当するものがあれば、推定結果とされた種類別フィールドの当該レコード位置でのレコード内容を、予測変換候補として取得してもよい。
【0092】
図32に示す例では、「フィールドB」において2つのレコードが該当したため、「フィールドC」でそれら2つのレコードに対応するレコードの内容である「yamamoto@sl.aaa.com」と「yamamoto@dev.aaa.com」とが予測変換候補として取得されている。
【0093】
そして、入力情報予測手段105は、取得されたレコードについて入力ログに基づくスコアを取得し、得られたスコアに基づいて予測変換候補を順位付けして提示する。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105がスコアを算出してもよい。
図32に示す例では、1番目の予測変換候補としてスコアの最も高かった「yamamoto@sl.aaa.com」と、2番目の予測変換候補として次にスコアの高かった「yamamoto@dev.aaa.com」が提示される。
【0094】
このように、本例でも「山本」と入力しただけで、それに関連する情報であってかつ当該入力欄に入力されるべき情報の種類に合致する形式の情報が変換候補として提示される。よって、ユーザが誤った種類の情報を入力したときであってもそれを正すことができ、また、入力を正すためのユーザの入力の手間を省くことができる。また、ユーザが正しい記載形式での内容を知らなくても、正しい情報を入力させることができる。例えば、ある入力欄が住所を入力すべき欄である等の指定を行わなくても、郵便番号から住所に変換することが可能になる。
【0095】
また、
図33は、入力情報予測手段105による予測処理の他の例を示す説明図である。なお、本例では、対象の入力欄に入力すべき情報の種類の推定結果として、
図11(a)に示す種類別正解入力DB102の「連結フィールドAB」を示す情報を得ていたとする。また、合わせて
図11(d)に示す優先要素の情報も得ていたとする。なお、
図11(a)に示す種類別正解入力DB102の「連結フィールドAB」は、「フィールドA」と「フィールドB」とが連結されたものであって、この2つのフィールドにはいずれにも「住所」を表す情報群が登録されている。また、種類別正解入力DB102には、「フィールドA」の方が情報の粒度が大きいといった種類別フィールド間の関係を示す情報が予め保持されているものとする。また、
図11(d)に示す優先要素の情報とは、優先要素フィールドを「フィールドA」とし、該優先要素フィールドにおいて「堺市」を優先要素とする旨の情報である。
【0096】
ここで、対象の入力欄への新たな入力情報として「北区」という入力を受け付けたとする。このような場合、入力情報予測手段105は、推定結果とされた種類別フィールドである「連結フィールドAB」または連結された「フィールドA]と「フィールドB」とを検索フィールドとした上で、これら検索フィールド内の各候補から入力情報を含むものを検索してもよい。そして、入力情報予測手段105は、該当するものがあれば、推定結果とされた種類別フィールドの当該レコード位置でのレコード内容を予測変換候補として取得してもよい。
【0097】
図33に示す例では、「フィールドB」において2つのレコードが該当したため、「連結フィールドAB」においてそれら2つのレコードに対応するレコードの内容である「大阪市北区」と「堺市北区」とが予測変換候補として取得されている。
【0098】
そして、入力情報予測手段105は、取得されたレコードについて入力ログに基づくスコアを取得し、得られたスコアに基づいて予測変換候補を順位付けして提示する。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105がスコアを算出してもよい。そのような場合には、検索されたレコードの中で入力ログに含まれる回数が多く、かつ優先要素フィールドの内容が優先要素であるものを優先するようなスコアが付与される。入力情報予測手段105は、そのようにして得られたスコアに基づいて、予測変換候補を順位付けして出力してもよい。
図33に示す例では、1番目の予測変換候補としてスコアの最も高かった「堺市北区」と、2番目の予測変換候補として次にスコアの高かった「大阪市北区」が提示される。
【0099】
このように、本例でも「北区」と入力しただけで、それを含む情報であってかつ当該入力欄に入力されるべき情報の種類に合致する形式の情報が変換候補として提示されるので、ユーザに正しい情報を簡単に入力させることができる。また、本例では、優先要素を考慮したスコアに基づいて候補を順位付けて提示する。そのため、例えば、
図11(b)に示す入力ログでは「北区」に関する入力ログはないが、他のログ内容から「堺市」を含む情報の方が可能性が高いと判断できるため、そのような順位付けがされた候補を提示できる。
【0100】
また、
図34は、入力情報予測手段105による予測処理の他の例を示す説明図である。入力情報予測手段105は、例えば
図34に示すように、推定結果とされた種類別フィールドが連結フィールドでない場合でも、クラスタリング等により優先要素が取得されている場合には、同様に優先要素を利用して予測変換候補の順位付けを行ってもよい。なお、
図34には、対象の入力欄に入力すべき情報の種類の推定結果として、
図12(a)に示す種類別正解入力DB102の「フィールドA」を示す情報を得るとともに、合わせて
図12(d)に示す優先要素の情報を得たときの予測処理の例が示されている。
【0101】
また、
図35は、入力情報予測手段105による予測処理の他の例を示す説明図である。入力情報予測手段105は、例えば、対象の入力欄に入力すべき情報の種類の推定結果として、
図9に示す種類別正解入力DB102の「フィールドC」を得ていたとする。なお、
図9に示す種類別正解入力DB102は、「フィールドC」の他に、「フィールドA」と「フィールドB」を有しており、これら種類別フィールドは、記入項目は異なるが、各レコードがお互いに対応づけられている。また、本例では、入力ログとして
図13(a)に示す情報が登録されているとする。すなわち、有効度付きの入力ログが登録されているものとする。
【0102】
ここで、対象の入力欄への新たな入力情報として「山本」という入力を受け付けたとする。このような場合、入力情報予測手段105は、全て種類別フィールドを検索フィールドとした上で、これら検索フィールド内の各候補から入力情報を含むものを検索してもよい。そして、入力情報予測手段105は、該当するものがあれば、推定結果とされた種類別フィールドの当該レコード位置でのレコード内容を予測変換候補として取得してもよい。
【0103】
図35に示す例では、「フィールドB」において2つのレコードが該当したため、「フィールドC」でそれら2つのレコードに対応するレコードの内容である「yamamoto@sl.aaa.com」と「yamamoto@dev.aaa.com」とが予測変換候補として取得されている。
【0104】
そして、入力情報予測手段105は、取得されたレコードについて入力ログに基づくスコアを取得し、得られたスコアに基づいて予測変換候補を順位付けして提示する。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105がスコアを算出してもよい。本例の場合、入力情報予測手段105は、取得されたレコードにつき、当該レコードの内容に合致する入力ログであって有効なログが何件含まれているかをカウントしてそれをスコアとしてもよい。または、入力情報予測手段105は、取得されたレコードにつき、当該レコードの内容に合致する入力ログの有効度を加算したものをスコアとしてもよい。そして、入力情報予測手段105は、そのように有効度を加味した入力ログとの合致度に基づくスコアに基づいて、予測変換候補を順位付けてもよい。なお、
図35に示す例では、1番目の予測変換候補としてスコアの最も高かった「yamamoto@sl.aaa.com」と、2番目の予測変換候補として次にスコアの高かった「yamamoto@dev.aaa.com」が提示される。
【0105】
このように、本例でも「山本」と入力しただけで、それに関連する情報であってかつ当該入力欄に入力されるべき情報の種類に合致する形式の情報が候補として提示される。よって、ユーザに正しい情報を入力させることができるだけでなく、ユーザの入力の手間を省くこともできるため、ユーザに正しい情報を簡単に入力させることができる。また、本例では、当該ログの有効度を考慮した入力ログとの合致度スコアに基づいて候補を順位付けて提示するため、過去に間違って入力された情報が高い順位で提示されることを防ぐことができるなど、より最適化された順位で変換候補を提示できる。
【0106】
また、
図36は、入力情報予測手段105による予測処理の他の例を示す説明図である。入力情報予測手段105は、例えば、対象の入力欄に入力すべき情報の種類の推定結果として、
図9に示す種類別正解入力DB102の「フィールドC」を得ていたとする。なお、
図9に示す種類別正解入力DB102は、「フィールドC」の他に、「フィールドA」と「フィールドB」を有しており、これら種類別フィールドは、記入項目は異なるが、各レコードがお互いに対応づけられている。また、本例では、入力ログとして
図14(b)に示す情報が登録されているとする。すなわち、入力者情報付きの入力ログが登録されているものとする。
【0107】
ここで、対象の入力欄への新たな入力情報として「山本」という入力を受け付けたとする。このような場合、入力情報予測手段105は、全て種類別フィールドを検索フィールドとした上で、これら検索フィールド内の各候補から入力情報を含むものを検索してもよい。そして、入力情報予測手段105は、該当するものがあれば、推定結果とされた種類別フィールドの当該レコード位置でのレコード内容を予測変換候補として取得してもよい。
【0108】
図35に示す例では、「フィールドB」において2つのレコードが該当したため、「フィールドC」でそれら2つのレコードに対応するレコードの内容である「yamamoto@sl.aaa.com」と「yamamoto@dev.aaa.com」とが予測変換候補として取得されている。
【0109】
そして、入力情報予測手段105は、取得されたレコードについて入力ログに基づくスコアを取得し、得られたスコアに基づいて予測変換候補を順位付けして提示する。なお、入力情報の種類の推定処理においてレコード別のスコアの算出が行われていない場合には、入力情報予測手段105がスコアを算出してもよい。本例の場合、入力情報予測手段105は、取得されたレコードにつき、当該レコードの内容に合致する入力ログであって、今回の入力情報の入力者と同一のユーザのログが何件含まれているかをカウントしてそれをスコアとしてもよい。入力情報予測手段105は、そのように同一ユーザの入力ログとの合致度に基づくスコアに基づいて、予測変換候補を順位付けてもよい。なお、
図36に示す例では、1番目の予測変換候補としてスコアの最も高かった「yamamoto@sl.aaa.com」と、2番目の予測変換候補として次にスコアの高かった「yamamoto@dev.aaa.com」が提示される。
【0110】
このように、本例でも「山本」と入力しただけで、それに関連する情報であってかつ当該入力欄に入力されるべき情報の種類に合致する形式の情報が変換候補として提示される。よって、ユーザに正しい情報を入力させることができるだけでなく、ユーザの入力の手間を省くこともできる。また、本例では、今回情報入力を行ったユーザの過去の入力ログとの合致度に相当するスコアに基づいて候補を順位付けて提示する。よって、そのユーザが入力する可能性が高い候補を高い順位で提示できるなど、より最適化された順位で変換候補を提示できる。
【0111】
なお、入力情報予測手段105は、予測変換候補の一覧表示をする以外にも、IME(Input Method Editor)のように、ユーザが記載途中に、その入力内容を最も順位の高い予測変換候補に書き換え、それを決定待ちの変換候補として処理させてもよい。また、入力情報予測手段105は、ユーザの入力後に、スコアの高い変換候補を用いて「入力したかったのは○○ではありませんか?」といったアラートメッセージを生成して出力してもよい。
【0112】
また、入力情報予測手段105をIMEとして動作させる場合に、入力情報予測手段105は、入力欄内で反応するWebIMEであってもよいし、クライアント端末にインストールされて動作するIMEであってもよい。また、そのような場合において、入力情報予測手段105は、ユーザ固有のIMEの履歴と、入力欄の履歴の両方を考慮した上で、予測変換候補の推薦をしてもよい。推薦の仕方としては、両方のANDをとってもORをとってもよい。また、例えば、ユーザ固有のIMEの履歴を優先してもよいし、入力欄の履歴を優先してもよいし、どちらか一方の優先順位を高くしてもよい。また、入力ログは、システム側(サーバサイド)で記憶されていてもよいし、ユーザ側(クライアントサイド)で記憶されていてもよい。
【0113】
以上のように、本実施形態によれば、予め入力されうるデータの種類を指定しておかなくても、種類推定手段103による推定結果を利用して、入力情報予測手段105が正しい入力を予測する。よって、推定結果を候補として提示したり、自動的に書き換えたり、アラートメッセージを出力したりできるので、精度のよい入力情報を得られる。
【0114】
また、
図28に示す例では、第1の実施形態の構成に入力情報予測手段105が追加された構成を示したが、例えば、第2の実施形態の構成に入力情報予測手段105を追加してもよい。そのような場合、入力支援システムは、エラー検出と予測変換候補の提示とを同時に行ってもよいし、選択的にどちらか一方の機能のみを行うようにしてもよい。
【0115】
以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【0116】
この出願は、2013年1月22日に出願された日本特許出願2013−009571を基礎とする優先権を主張し、その開示の全てをここに取り込む。