JP3975914B2 - 言語入力システム - Google Patents
言語入力システム Download PDFInfo
- Publication number
- JP3975914B2 JP3975914B2 JP2002378899A JP2002378899A JP3975914B2 JP 3975914 B2 JP3975914 B2 JP 3975914B2 JP 2002378899 A JP2002378899 A JP 2002378899A JP 2002378899 A JP2002378899 A JP 2002378899A JP 3975914 B2 JP3975914 B2 JP 3975914B2
- Authority
- JP
- Japan
- Prior art keywords
- candidates
- candidate
- kana
- input
- kanji conversion
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Document Processing Apparatus (AREA)
- Machine Translation (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、言語入力、特に前方一致検索処理手段とかな漢字変換処理手段をともに有する言語入力方法及びシステムに関する。
【０００２】
【従来の技術】
日本語入力を効率よく入力する先行技術として、特開２００１−３２５２５２号公報が挙げられる。この先行技術では、入力されたかな文字列に対して前方一致検索候補（予測候補検索変換）を出力し、追加のかな文字列を入力することによって前方一致検索候補に加えてかな漢字変換候補を混在して出力している。ただし、これは出力すべき前方一致検索候補が減少したために、またはかな漢字変換候補と一致したために前方一致検索処理をかな漢字変換処理に切り替えているに過ぎない。つまり、入力されたかな文字列に対して前方一致検索処理とかな漢字変換処理を実行しているとは言えない。
【０００３】
【特許文献１】
特開２００１―３２５２５２号公報（第１５頁、第図２０）
【０００４】
【発明が解決しようとする課題】
ハードウェアと通信インフラの目覚ましい進歩によって、携帯電話などの携帯端末によって場所を選ばずとも情報の送受信が出来るようになってきた。ところが、小型、軽量を重要な要素とする携帯端末は、複雑な文字入力のためであっても必要最小限の操作スイッチしか用意できない。例えば「０」キーから「９」キーまでの１０キーとその他少数キーに複数の機能を割り当てて、それらを使い分けている。図１〜図６を用いて必要最小限の操作スイッチによる文字入力技術について説明する。
【０００５】
図１は、携帯電話に代表される、いわゆる１０キーデバイスでの日本語入力システムにおける入力方法を説明する図である。
【０００６】
同図において、情報入力部１から利用者２の操作によって「２」「ＡＢＣ」「か」が割り当てられた入力キーが２回操作されると、かな文字列の入力を受け付ける機能によって対応する入力信号が出力され、入力されたかな文字列を取得する機能によって、言語入力システムはかな文字「き」を取得する。同様に「８」「ＴＵＶ」「や」が割り当てられた入力キーが６回操作されると、かな文字「ょ（小文字のよ）」を取得し、「１」「．＠／」「あ」が割り当てられた入力キーが３回操作されるとかな文字「う」を取得し、「４」「ＧＨＩ」「た」が割り当てられた入力キーが５回操作されると、かな文字「と」を取得する。よって、これら一連の処理によってかな文字列「きょうと」を取得することが出来る。このかな文字列「きょうと」をかな漢字変換処理することによって、「きょうと」が「京都」になる。
【０００７】
入力されたかな文字列を漢字混じりの文章に変換する処理がかな漢字変換処理であるが、変換対象となるかな文字列「きょうと」を確定させるまでに操作を繰り返す必要があり、さらにかな漢字変換処理実行を指示する操作も必要である。携帯端末として必須な携帯性を維持するために、このように煩雑な操作が必要では利便性が悪くて仕方がないので、考え出された処理が入力予測検索処理とも呼ばれる前方一致検索処理である。
【０００８】
図２は、前方一致検索処理について説明する図である。
【０００９】
同図において、前方一致検索用辞書ＤＢ３とは、前方一致検索処理部４が用いる単語が記憶された辞書データベースのことであり大量の文書から言語入力システムが扱う言語（図例では日本語）の文章として使用頻度の高い単語をあらかじめ記憶されている。なお、言語入力システムで確定した単語を記憶容量の範囲で追加的に記憶することもある。また、前方一致検索処理部４とは、情報入力部１から入力された「かな文字列」で始まる単語を前方一致検索候補として前方一致検索用辞書ＤＢ３から検索することによって抽出し、抽出した候補を出力する処理のことである。なお、前方一致検索処理部４が抽出する前方一致検索候補は、使用頻度の高さを評価値とする順番で並べられている。
【００１０】
図例では、かな文字「き」を入力しただけで、かな文字「き」から始まる「今日、機能、昨日、規則、帰宅、気持ち、期待、キャッチフレーズ、ギブアンドテーク、・・・」などの日本語としてよく使われる単語が前方一致検索候補として出力されている。
【００１１】
図３は、かな文字が追加入力された場合の前方一致検索処理について説明する図である。
【００１２】
同図において、前方一致検索処理部４では、かな文字「き」に続いてかな文字「ょ」が入力されると、かな文字列「きょ」から始まる「今日、教室、曲、教育、・・・」などの単語が前方一致検索候補として出力される。かな文字を追加入力することで前方一致検索候補は自動的に絞り込まれることになる。つまり、かな文字「き」につづいてかな文字「ょ」が前方一致検索処理部４に入力されると、かな文字「き」から始まる前方一致検索候補の中からかな文字列「きょ」以外で始まる前方一致検索候補は出力されなくなるので、出力される候補数が自動的に減少する。
【００１３】
ところが、前方一致検索処理には、少ない入力かな文字で所望の単語が得られるという利点がある反面、前方一致検索用辞書ＤＢ３に記憶する前方一致検索候補としての融通が利かないこともその特徴であり、例えば「キャッシュ」「キャッシュカード」「キャッシュフロー」「キャッシュディスペンサー（現金自動支払機）」はすべて違う単語として記憶している。もちろん、前方一致検索処理において「現金自動支払機」と「現金自動支払い機」、さらに「現金自動支払装置」は全く別の単語として認識されている。よって、登録単語数を増やせば増やすほどのデータベースの容量が必要となるのが最大の欠点であり、痒いところに手が届くような語彙数とするために単語を片っ端から登録すると膨大な数の記憶容量が必要となってしまう。
【００１４】
また、我々が日常使っている言葉は生き物であり、時とともに変化し続けている。つまり、言葉の組み合わせや言い回しおよび表現は多様化の方向に変化し、個々の利用者２によって使い慣れた言葉が異なっているので、利用者２にとって「これくらいはあるだろう」と思っても「実際にはなかった」という前方一致検索用辞書ＤＢ３に記憶されていない「ありそうでない単語」が増える一方であるとも言える。図例では、かな文字数４文字の「きょうと」について前方一致検索辞書ＤＢ３に候補がなかったので、前方一致検索処理部４は入力されたかな文字列「きょうと」をそのまま出力している。候補がなかった場合には「きょうと」「キョウト」のようにカタカナ表記も出力することもある。
【００１５】
図４は、かな漢字変換処理に用いるかな漢字変換辞書について説明する図である。
【００１６】
ここで、かな漢字変換処理についても説明しておく。同図では、まずかな漢字変換処理に用いるかな漢字変換用辞書を記憶するかな漢字変換辞書ＤＢ５について説明する。同図において、かな漢字変換用辞書ＤＢ５は、日本語として構成可能な自立語と付属語をその品詞とともに記憶している辞書データベースのことである。日本語は単文節または連文節（多文節）で構成されており、単文節はひとつの自立語またはひとつの自立語と付属語の組み合わせで構成されている。ここで言うところの自立語とは、名詞や動詞などの単語のことであり、動詞には活用によって語尾が変化する。また、付属語とは自立語に付属して文節を構成する助詞や助動詞の類のことである。「私は医者に行く」という文章において、先頭文節は「私は」であり、自立語「私」と付属語「は」で構成され、第２文節は「医者に」であり、自立語「医者」と付属語「に」で構成され、第３文節は「行く」であり、自立語「行」と付属語「く」で構成されている。
【００１７】
図５は、かな漢字変換処理における連文節変換候補取得処理について説明する図である。
【００１８】
かな漢字変換処理は連文節変換候補取得処理と全候補取得処理から構成されており、ここでは連文節変換候補取得処理について説明する。同図において、利用者２の変換ボタンの操作によってかな漢字変換の指示を受け付けると、受け付けた変換指示に基づいてかな漢字変換処理に切り替えることによって連文節変換候補取得処理が実行される。連文節変換候補取得処理部６とは、情報入力部１から入力されたかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出し、自立語および付属語に付与された品詞に基づいて接続可能な組み合わせを多文節（または全文節）で多文節解析し、多文節解析した候補の中から最も評価値の高い候補を出力する処理のことである。
【００１９】
「きょうとにいく」という入力かな文字列を例に説明すると、連文節変換候補取得部６は、入力されたかな文字列を取得すると、取得したかな文字列で構成できる自立語と付属語を抽出し、抽出した自立語と付属語を組み合わせてみると例えば「今日―と−に−行−く」や「京都−に−行−く」など様々な組み合わせの候補が出来る。その組み合わせをそれぞれ構成可能な品詞の接続について多文節（または全文節）で解析して、最も評価値の高い組み合わせである「京都−に−行−く」を候補として選択することを多文節解析と言い、多分析解析した解析結果として「京都に行く」という候補を出力する。
【００２０】
図例では「きょうと」という入力かな文字が入力された場合を示す。まず前方一致検索処理部４による処理が実行されたが、かな文字列「きょうと」に対応する前方一致候補がなかったために、そのまま「きょうと」と情報出力部７に表示されている。仕方がないので利用者２は、かな漢字変換処理を指示するために情報入力部１にある変換ボタンを操作すると、入力かな文字列に対する処理が前方一致検索処理から連文節変換候補取得処理に切り替えられ、そのとき評価値が最も高い候補であった「京都」が出力される。
【００２１】
図６は、かな漢字変換処理における全候補取得処理について説明する図である。
【００２２】
同図において、連文節変換候補取得処理部６によって、「京都」ではなく「今日と」が出力された場合には、利用者２は自らが所望する「京都」を得るために切替ボタンを操作する。情報入力部１にある切替ボタンが操作されると、受け付けた切替指示に基づいて全候補取得処理が実行される。全候補取得処理部８とは、連文節変換候補取得処理部６で解析した結果（多文節解析結果）を取得して、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力する処理のことである。
【００２３】
「今日と」と「京都」は連文節変換候補取得処理部６によって多文節解析をしても評価値に差がほとんどないことが多く、この場合にはどちらが頻繁に使用されているかという利用頻度によって評価値が決定されるので、「今日と」など所望しない候補が出力されてしまうこともよくある。そこで、全候補取得処理を実行すると、多文節解析結果から各文節の全候補が取得されるので「今日と、京と、京都・・・」が出力されることになる。利用者２はこの出力の中から自らが所望する「京都」を選択することが出来る。
【００２４】
前方一致検索処理にもかな漢字変換処理にも長所と短所があり、どちらかが優れているというわけではない。それぞれの良いところをうまく使い分ける仕組みが大切である。特開２００１―３２５２５２号公報のようにかな漢字変換処理の前に前方一致検索処理を実行するというのは理にかなっている。
【００２５】
ただし、入力かな文字または入力かな文字列に対して前方一致検索候補のみを出力して、表示領域に表示することは様々な問題がある。まず始めに挙げられるのは、少ない文字数で利用者が望む単語を当てることが現実的に非常に困難であることである。例えば「あ」と入力されたかな文字でどんな言葉を利用者が入力しようとしているかズバリ当てられるだろうか。文章の流れで予測する技術も数多く考案されてはいるものの膨大な処理の割には得られる効果、つまり利用者が納得できる候補を出力できることが稀である。的外れな結果を出力し続けていると、使い物にならないシステムとして利用者からソッポを向かれ、結局は利用されない不要な機能になってしまうという問題点があった。
【００２６】
さらに限られた表示領域に表示できる候補数で利用者が望む単語を当てることも困難であることである。色々な言葉を出してみれば確率的に利用者が納得できる候補を出力できるはずではあるが、どうしても当てずっぽうになりがちな候補を５つ出そうが１０個出そうがまず当たらない。これもまた、的外れな結果を出力し続けていると、使い物にならないシステムとして利用者からソッポを向かれ、結局は利用されない不要な機能になってしまうという問題点があった。
【００２７】
かと言って、単純に前方一致検索用辞書の単語数を増やして多くの候補を一度に出せば良いというものでもない。多くの候補を一度に出すと利用者はそれらの候補の中に所望の候補があるか探そうとするが、利用者にとって所望する単語はたった一つであるために所望しないその他の候補を多くする結果となり、探し出す手間が増え、利用者がイライラし出すという問題点があった。
【００２８】
また、前方一致検索用辞書の単語数を増やすと利用者の期待が高まるのは間違いないが、無かった場合には期待が高まった分だけ失望が大きくなるので、前方一致検索処理によって期待をさせた結果「ありそうでなかった単語」は利用者の期待を最も裏切ってしまうことが隠れた問題点であった。使い方によっては便利な前方一致検索候補ではあるが、その候補の出し方に工夫が足りない。
【００２９】
【課題を解決するための手段】
本発明の本質は、入力されたかな文字列に対して前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）をそれぞれ少なくとも１候補以上は「最初の候補群」として表示画面の表示領域に前方一致検索候補重視の表示割合で表示するとともに、「最初の候補群」として表示領域に表示しきれなかった候補を「次の候補群」として表示する場合には、「最初の候補群」と前方一致検索候補とかな漢字変換候補との表示割合を変更して、前方一致検索候補の表示割合を減らして全候補の表示割合を増やすことである。
【００３０】
本発明は、情報入力部から入力された入力かな文字列を取得するかな文字列取得手段と、前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、前方一致検索処理を実行し、実行結果である前方一致検索候補を出力する前方一致検索処理手段と、前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、かな漢字変換処理を実行し、実行結果であるかな漢字変換処理候補を出力するかな漢字変換処理手段と、前記前方一致検索処理手段から出力された前記前方一致検索候補の文字長と前記かな漢字変換処理手段から出力された前記かな漢字変換候補の文字長をそれぞれ必要数取得する候補文字長取得手段と、前記候補文字長取得手段が取得した候補の文字長に基づき、それらの候補を表示する表示領域に合わせて、前記前方一致検索候補の表示割合と前記かな漢字変換候補の候補数の表示割合を決定する表示割合決定手段と、前記表示割合決定手段が決定した表示割合に基づいて、前記前方一致検索処理手段から前記前方一致検索候補を、前記かな漢字変換処理手段から前記かな漢字変換候補をそれぞれ取得する候補取得手段と、前記候補取得手段が取得した前記前方一致検索候補と前記かな漢字変換候補を前記表示領域に合わせて配置する候補配置手段と、前記候補配置手段が前記表示領域に合わせて配置した候補群を配置結果として前記表示領域に表示する表示手段と、前記表示領域に表示した候補に対して選択入力を受け付けると、選択入力を受け付けた候補を入力確定する入力確定手段とを有するようにした。
【００３１】
前記表示割合決定手段は、取得した各候補の文字長があらかじめ定める割合で前記表示領域に収まるか否かに基づいて、前記前方一致検索候補の表示割合と前記かな漢字変換候補の候補数の表示割合を決定するようにするとよい。前記表示割合決定手段は、取得した各候補の文字長があらかじめ定める割合で前記表示領域に収まらないと判断した場合には、あらかじめ定める表示割合に関する表示割合ルール（取り決め）を満たした上で表示割合を修正してもよい。また、前記表示領域に表示しきれなかった次の候補群への表示切替を要求する要求信号を受け付けると、前記表示割合決定手段は前記前方一致検索候補の表示割合を減らすようにするとよい。
【００３２】
少ない文字数で所望の文字が得られる前方一致検索処理は利用者にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るので、最初の候補群に前方一致検索候補とかな漢字変換候補とを少なくとも１つ以上は表示することにした。かな漢字変換候補は連文節変換候補と全候補から成るので、最初の候補群に連文節変換候補を１つと全候補を少なくとも１つ以上表示するとよい。なお、前方一致検索候補は、入力かな文字数を増やしていくと自動的に絞り込まれるので、２度ほど候補群を切り替えると諦めてしまうことが多い利用者心理に配慮して、最初の候補群には前方一致検索候補重視の表示割合として、次の候補群に切り替わるに従って段階的にその割合を減らすこととした。
【００３３】
なお、前方一致検索候補や連文節変換候補と全候補は重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどれかかの候補としてしまうとよい。この重複を削除する処理は、各処理部から候補が出力された直後に実行しておくと効率的である。このような前処理をしておくと、重複が削除された後の候補について表示割合を決定することになる。
【００３４】
また、前記表示割合決定手段は、前記入力かな文字列の入力された文字数の増加に応じて、前記前方一致検索候補の表示割合を減らすようにしてもよい。
【００３５】
より具体的には、かな漢字変換候補に比べ、入力かな文字数を増やすと候補数が減少する度合の大きい前方一致検索候補の特徴に配慮して、効率のよい候補表示をするために入力かな文字数に応じて、前方一致検索候補の表示割合を減らすようにした。
【００３６】
また、前記表示割合決定手段は、前記入力かな文字列の入力された先頭かな文字に応じて、前記前方一致検索候補の表示割合を変更するようにしてもよい。
【００３７】
より具体的には、先頭かな文字に応じてデータベースに記憶する候補数に大きなバラツキが生じる前方一致検索候補の特徴に配慮して、先頭かな文字に対応する候補数に応じた増減調整を前方一致検索候補数に加えるようにした。
【００３８】
また、前記入力確定した候補を入力履歴候補として記憶する入力履歴候補データベースをさらに有し、前記候補文字長取得手段は、前記前方一致検索候補の文字長と前記かな漢字変換候補の文字長を取得する際に、前記入力履歴候補データベースから前記入力履歴候補の文字長も必要数取得し、前記表示割合決定手段は、前記候補文字長取得手段が取得した候補の文字長に基づき、それらの候補を表示する表示領域に合わせて、前記前方一致検索候補と前記かな漢字変換候補および前記入力履歴候補の表示割合を決定するようにしてもよい。
【００３９】
また、前記候補配置手段は、前記表示領域において前記前方一致検索候補や前記かな漢字変換候補よりも優先的に前記入力履歴候補を表示するようにしてもよい。
【００４０】
より具体的には、入力履歴は同じ言葉を繰り返し使って文章作成する場合に利用頻度が高くなり、文章作成ではよくあることなので、前方一致検索候補とかな漢字変換候補とは別枠として表示領域に表示割合を確保した。また、直近の入力履歴候補は、同じ言葉を繰り返し使って文章作成する利用者にとって利便性の高いものであるので、その優先順位を高くした。なお、入力履歴候補は、前方一致検索候補やかな漢字変換候補と重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどちらかの候補としてしまうとよい。
【００４１】
【発明の実施の形態】
以下に、本発明に係る言語入力システムの具体的実施の形態を図面を参照して詳細に説明する。
【００４２】
（第１実施形態）
図７〜図１４を用いて、本発明における言語入力システムの基本となる第１実施形態を説明する。
【００４３】
図７は、本発明の実施形態における言語入力システムを備える携帯端末のハードブロック図である。
【００４４】
同図において、情報入力部１と情報出力部７は、携帯端末９と利用者２とが種々のやりとりをするための入出力機能を持つ部位である。情報入力部１における入力装置としては、例えばテンキーなどの各種スイッチ、手書き文字認識装置、音声入力装置などが該当し、利用者２の入力がシステムに対して情報を伝達するものなら、その種類は問わない。また、情報出力部７における出力装置としては、例えば表示画面（ディスプレイ）、音声出力装置などが該当し、利用者２に対してシステムから情報を伝達できるものなら、その種類は問わない。演算部１０とは、プログラムを実行することによって各機能を駆動、処理するための演算機能を持つ部位であり、一般にＣＰＵ（中央演算装置）で構成される。メモリ部１１とは、演算部１０が実行するプログラムの実行エリアの部位である。通信部１２とは、ネットワーク１３を介して他の端末やシステムとの間で情報の通信を制御する部位である。ＤＢ管理部１４とは、様々なデータ構造とデータ実体を管理する機能を持つ部位である。
【００４５】
ＤＢ管理部１４に管理される処理プログラム１５とは、携帯端末９の利用目的を達成するために必要なプログラムのことであり、ＯＳ（オペレーティングシステム）もここに含まれる。前方一致検索用辞書ＤＢ３とかな漢字変換用辞書ＤＢ５もＤＢ管理部１４に管理されている。同様に、表示割合情報ＤＢ１６とは、表示画面の表示領域に表示する前方一致検索候補数とかな漢字変換候補数との表示割合を記憶するデータベースのことである。同様に学習辞書ＤＢ１７とは、前方一致検索用辞書ＤＢ３とかな漢字変換用辞書ＤＢ５とがそれぞれ評価値のひとつに用いる入力履歴情報を記憶するデータベースのことである。
【００４６】
図８は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００４７】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８を有し、かな漢字変換処理部１８は、連文節変換候補取得処理部６と全候補取得処理部８から構成されている。前方一致検索処理部４は、情報入力部１からかな文字列の入力を受け付ける機能によって受け付けたかな文字列を取得する機能と、取得したかな文字列に基づいて前方一致検索用辞書ＤＢ３から候補を検索する機能と、検索した候補を出力する機能を有する。連文節変換候補取得処理部６は、情報入力部１からかな文字列の入力を受け付ける機能によって受け付けたかな文字列を取得する機能と、取得したかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出する機能と、抽出した自立語および付属語で構成可能な（抽出した自立語および付属語に付与された品詞に基づいて接続可能な）組み合わせを多文節（または全文節）で多文節解析する機能と、多文節解析した候補の中から最も評価値の高い候補を出力する機能とを有する。全候補取得処理部８は、連文節変換候補取得処理部６で解析した結果（多文節解析結果）から全候補を取得する機能と、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力する機能とを有する。このように情報入力部１で受け付けたかな文字列に対して、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）がそれぞれ出揃うことになる。
【００４８】
図９は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００４９】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長を取得して、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。図例では、９つの候補が表示できる表示領域に第１の候補群（初期候補群）には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群（第２候補群）には、前方一致検索候補を３候補、全候補を６候補を表示している。第２の候補群に続く第３の候補群（第３候補群）には、９候補すべてを全候補で表示している。
【００５０】
なお、前方一致検索候補や連文節変換候補と全候補は重複することもあるので、もちろんその場合には重複して候補を表示するのではなく、どれかかの候補としてしまうとよい。この重複を削除する処理は、各処理部から候補が出力された直後に実行しておくと効率的である。このような前処理をしておくと、重複が削除された後の候補について表示割合を決定することになる。
【００５１】
図１０は、図９に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００５２】
同図は、図９に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得（『前方一致検索処理部４から前方一致検索候補の文字長を、かな漢字変換処理部１８からかな漢字変換候補の文字長をそれぞれ必要数取得』と同意）する機能では、各処理部から多めの候補数を取得するようにあらかじめ定める数を決めておくと、表示領域に空きスペースが出来た場合に候補の文字長を取得し直さなくてもよくなる。ただし、かな漢字変換処理で得られる候補は極端に短くなることもなく、前方一致検索処理で得られる候補は登録される単語によっては長いこともあるので、処理としては取得した候補に対して表示領域が余るよりも足らなくなることの方が多いようである。
【００５３】
また、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能における「あらかじめ定める割合」とは、表示割合情報ＤＢ１６から取得する候補数の割合のことであり、割合で示されることもその割合を満たす候補数で示されることもある。具体的には、例えば９つの候補が表示できる表示領域に第１の候補群（初期候補群）として、前方一致検索候補と連文節変換候補と全候補の割合を６：１：２（６候補：１候補：２候補）で取得した候補の文字長が表示領域に収まるか否かを判断する。同様に、第１の候補群に続く第２の候補群（第２候補群）として、前方一致検索候補と全候補の割合を３：６（３候補：６候補）で取得した候補の文字長が表示領域に収まるか否かを判断し、第２の候補群に続く第３の候補群（第３候補群）として、９候補すべてを全候補で取得した候補の文字長が表示領域に収まるか否かを判断している。収まらないと判断された前方一致検索候補は次の候補群における前方一致候補の先頭に順送りされ、同様に収まらないと判断されたかな漢字変換候補は次の候補群のかな漢字変換候補の先頭に順送りされる。なお、連文節変換候補は入力されたかな文字列に対して基本的に１つしか存在しないので、表示領域に表示されるのは第１の候補群のみである。
【００５４】
表示割合情報ＤＢ１６から取得される各候補の表示割合情報は以下の配慮（表示割合ルールの取り決め）がなされている。
（１）入力されたかな文字列に対して前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）をそれぞれ少なくとも１候補以上は「最初の候補群」として表示画面の表示領域に表示し、表示割合は前方一致検索候補重視（前方一致検索候補の表示割合が、かな漢字変換候補の表示割合より少なくとも同等以上）とすること。
（２）「最初の候補群」として表示領域に表示しきれなかった候補となる「次の候補群」には、「最初の候補群」と前方一致検索候補とかな漢字変換候補との表示割合を変更し、前方一致検索候補の表示割合を減らして全候補の表示割合を増やすこと。
（３）前方一致検索候補の表示割合を減らして、前方一致検索候補として表示する候補数が０となった候補群以降は、すべて全候補であること。
【００５５】
このような表示割合情報に含まれる表示割合ルールによって、言語入力システムは「最初の候補群」ではかな漢字変換候補の表示割合よりも前方一致検索候補の表示割合を多くし、「次の候補群」への切り替わりに応じてかな漢字変換候補の表示割合が多くなり、そのうち表示領域に表示される候補がすべてかな漢字変換候補にする。別の言い方をすれば、始めは前方一致検索候補重視でそれぞれの候補を表示し、候補を追加する（つまり、候補群を切り替えていく）に従ってかな漢字変換候補重視での候補群の表示に変えていく。
【００５６】
表示割合という表現であるのは、前方一致検索候補は入力かな文字に対して比較的長い単語が出力されることもあり、前方一致検索候補重視にしているにも関わらず候補数はかな漢字変換候補の方が多いことがあり得ることによる。つまり、各候補を文字長（もしくは文字数）に換算した上での表示領域の占有率をここで言うところの「表示割合」と考えてもよい。
【００５７】
これらの表示割合ルールは、利用者２がかな文字を入力する際の行動における心理的分析から得られた見地を根拠としている。まず、表示割合ルール（１）では、少ない文字数で所望の文字が得られる前方一致検索処理は利用者２にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るという前方一致検索処理の落とし穴（盲点）に着目した。単漢字などの文字数の少ない漢字の入力を所望している場合の利用者２にとって、前方一致検索候補は無用の長物であって、表示領域すべてが前方一致検索候補で埋まっていたりすると、例えば「単なる漢字が欲しいだけなのに何でこんなに大袈裟なんだ」などと呆れるか、急いでいるときや慌てているときなどの心理的余裕の少ないときにはイライラしたり怒り出す傾向がある。よって、例えば「き」というかな文字が入力された場合に「木」という漢字は前方一致検索辞書にはまず登録されていないので、前方一致検索処理部４はかな文字「き」から始まる「今日、機能、昨日、規則、帰宅、気持ち、期待、キャッチフレーズ、ギブアンドテーク、・・・」を前方一致検索候補として出力する。よって、単に「木」という漢字を所望している利用者２にも配慮して、最初の候補群にかな漢字変換候補を少なくとも１つ以上は表示することにした。かな漢字変換候補は連文節変換候補と全候補から成るので、最初の候補群に連文節変換候補を１つと全候補を少なくとも１つ以上表示するとよい。
【００５８】
表示割合ルール（２）では、前方一致検索候補は入力かな文字数を増やせば自動的に絞り込まれることに着目した。利用者２の入力行動を実際に観察していると、入力したかな文字列に対して表示画面の表示領域に表示される最初の候補群に所望の候補が無かった場合に、次の候補群に切り替えるが、そこにもなくて再度切り替えて無いと諦めてしまうようである。つまり、利用者２が表示領域を切り替える回数はほとんどの場合２回までで、２回切替操作を実行して表示された候補の中に所望の候補が無かった場合にはかな文字列を追加入力することが多いことになる。よって、３つ分の表示領域にバランスよく前方一致検索候補とかな漢字変換候補を配置するために、最初の候補群には前方一致検索候補重視の表示割合として、次の候補群に切り替わるに従って段階的にその割合を減らすこととした。
【００５９】
表示割合ルール（３）では、表示割合ルール（２）を実行すると自明ではあるが、前方一致検索候補が表示領域に表示されなくなっても、なお次の候補群に切り替えているというのは、かな漢字変換候補を利用者２が探していることになるので、以降は全候補がなくなるまで候補群として表示領域に表示する。
【００６０】
図１１は、図８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６１】
同図において、言語入力システムは、情報入力部１からかな文字列の入力を受け付けると（ＳＴ１１０１）、受け付けたかな文字列を前方一致検索処理部４とかな漢字変換処理部１８に受け渡して（ＳＴ１１０２）、処理を終了する。前方一致検索処理部４では、かな文字列を取得すると、取得したかな文字列に基づいて前方一致検索用辞書ＤＢ３から候補を検索し（ＳＴ１１０３）、検索した候補を出力して（ＳＴ１１０４）、処理を終了する。連文節変換候補取得処理部６では、かな文字列を取得すると、取得したかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出し（ＳＴ１１０５）、抽出した自立語および付属語で構成可能な（抽出した自立語および付属語に付与された品詞に基づいて接続可能な）組み合わせを多文節（または全文節）で多文節解析し（ＳＴ１１０６）、多文節解析した候補の中から最も評価値の高い候補を出力して（ＳＴ１１０７）、処理を終了する。全候補取得処理部８では、連文節変換候補取得処理部６で解析した結果（多文節解析結果）から全候補を取得し（ＳＴ１１０８）、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力して（ＳＴ１１０９）、処理を終了する。
【００６２】
図１２は、図９に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６３】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１２０１）、各処理が出力する候補の文字長を取得し（ＳＴ１２０２）、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ１２０３）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１２０４）、取得した候補群を表示領域に表示して（ＳＴ１２０５）、処理を終了する。
【００６４】
図１３は、図１０に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６５】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１３０１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ１３０２）、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか否かを判定し（ＳＴ１３０３）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ１３０４）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１３０５）、取得した候補群を表示領域に表示して（ＳＴ１３０６）、処理を終了する。
【００６６】
図１４は、図１３のフローチャートに示す表示割合の修正をした場合の具体例を示す図である。
【００６７】
同図において、前方一致検索処理部４はかな文字「き」から始まる「キャッチフレーズ、今日、機能、ギブアンドテーク、昨日、規則、帰宅、気持ち、期待、・・・」を前方一致検索候補として出力している。すると、第１の候補群に前方一致検索候補が６候補収まりきれないので、前方一致検索候補を収まる分の４候補、連文節変換候補を１候補、全候補を２候補を表示し、収まらなかった前方一致検索候補の２候補は第２の候補群に回している。なお、図例に示すように第１の候補群に続く第２の候補群には、前方一致検索候補を３候補、全候補を６候補を表示して、第２の候補群に続く第３の候補群には、９候補すべてを全候補で表示するところを２候補分の前方一致検索候補を表示して、全候補を７候補としてもよい。
【００６８】
（第２実施形態）
図１５〜図２０を用いて、本発明における第２実施形態を説明する。第２実施形態の特徴は、かな文字列が追加入力された場合にも、表示画面の表示領域に表示する前方一致検索候補とかな漢字変換候補との表示割合を変更することである。これは、入力かな文字列の数に応じて表示割合ルールを変更することを意味する。
【００６９】
図１５は、入力されたかな文字数と前方一致検索用辞書の平均候補数の関係を示す図である。
【００７０】
同図において、平均的な語彙数である２０００語を収める前方一致検索用辞書において、入力されたかな文字列の文字数に対してどのくらいの語彙数の前方一致検索候補が納められているかを示す図である。図によると、かな文字列の文字数が１文字の場合は３４候補であり、同様に２文字の場合は６候補、３文字の場合は２候補、４文字の場合は１候補、５文字の場合は１候補である。このように、入力かな文字列の増加に伴い、前方一致検索候補の数が減少するので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（４）入力されたかな文字列の文字数に応じて、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）の表示割合を変更すること。
【００７１】
図１６は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００７２】
同図は、図８に示す処理に続いて情報入力部１からかな文字列が続けて入力された場合の処理を示す。同図において、言語入力システムは、情報入力部１からかな文字列の入力を受け付ける機能によって追加入力されたかな文字列を取得すると、追加入力されたかな文字列を加えたかな文字列に対して再度、前方一致検索処理とかな漢字変換処理を実行する。図１６に示す機能ブロック図に対応するフローチャートは、図１１に示すフローチャートと同様である。
【００７３】
図１７は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００７４】
同図において、言語入力システムは、入力されたかな文字列の文字数を取得する機能と、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長および入力されたかな文字列の文字数を取得して、取得した候補の文字長およびかな文字列の文字数とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。図例では、９つの候補が表示できる表示領域に第１の候補群（初期候補群）には、前方一致検索候補を４候補、連文節変換候補を１候補、全候補を４候補を表示している。第１の候補群に続く第２の候補群（第２候補群）には、前方一致検索候補を２候補、全候補を７候補を表示している。第２の候補群に続く第３の候補群（第３候補群）には、９候補すべてを全候補で表示している。
【００７５】
図１８は、図１７に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００７６】
同図は、図１７に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長およびかな文字列の文字数とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、入力されたかな文字列の文字数に基づいて表示割合情報を表示割合情報ＤＢ１６から取得する機能と、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。
【００７７】
図１９は、図１７に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００７８】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１９０１）、入力されたかな文字列の文字数を取得し（ＳＴ１９０２）、各処理が出力する候補の文字長を取得し（ＳＴ１９０３）、取得したかな文字列の文字数および取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ１９０４）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１９０５）、取得した候補群を表示領域に表示して（ＳＴ１９０６）、処理を終了する。
【００７９】
図２０は、図１８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００８０】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２００１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ２００２）、情報入力部１から入力されたかな文字列の文字数に基づいて表示割合情報ＤＢ１６から表示割合情報を取得し（ＳＴ２００３）、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか否かを判定し（ＳＴ２００４）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ２００５）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２００６）、取得した候補群を表示領域に表示して（ＳＴ２００７）、処理を終了する。
【００８１】
（第３実施形態）
図２１〜図２６を用いて、本発明における第３実施形態を説明する。第３実施形態の特徴は、かな文字列における先頭かな文字に応じて、表示画面の表示領域に表示する前方一致検索候補とかな漢字変換候補との表示割合を変更することである。これは、入力かな文字列の先頭かな文字が何であるかに応じて表示割合ルールを変更することを意味する。
【００８２】
図２１は、入力されたかな文字列における先頭かな文字と前方一致検索用辞書の候補数の関係を示す図である。
【００８３】
同図において、平均的な語彙数である２０００語を収める前方一致検索用辞書において、入力されたかな文字列における先頭かな文字に対してどのくらいの語彙数の前方一致検索候補が納められているかを示す図である。図によると、かな文字列における先頭かな文字が「き」１文字の場合は４８候補であるのに対して、先頭かな文字が「か」１文字の場合は１１８候補もある。このように、入力かな文字列における先頭かな文字によって、前方一致検索候補の数が増減するので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（５）入力されたかな文字列における先頭かな文字に応じて、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）の表示割合を変更すること。
【００８４】
図２２は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００８５】
同図において、言語入力システムは、入力されたかな文字列における先頭かな文字を取得する機能と、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長および入力されたかな文字列における先頭かな文字を取得して、取得した候補の文字長および先頭かな文字の種別とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。
【００８６】
図２３は、図２２に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００８７】
同図は、図１７に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長および入力されたかな文字列における先頭かな文字の種別とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、かな文字列における先頭かな文字の種別に基づいて表示割合情報を表示割合情報ＤＢ１６から取得する機能と、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。
【００８８】
図２４は、図２２に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００８９】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２４０１）、入力されたかな文字列における先頭かな文字の種別を取得し（ＳＴ２４０２）、各処理が出力する候補の文字長を取得し（ＳＴ２４０３）、取得した先頭かな文字の種別および取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ２４０４）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２４０５）、取得した候補群を表示領域に表示して（ＳＴ２４０６）、処理を終了する。
【００９０】
図２５は、図２３に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００９１】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２５０１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ２５０２）、情報入力部１から入力されたかな文字列における先頭かな文字の種別に基づいて表示割合情報ＤＢ１６から表示割合情報を取得し（ＳＴ２５０３）、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか否かを判定し（ＳＴ２５０４）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ２５０５）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２５０６）、取得した候補群を表示領域に表示して（ＳＴ２５０７）、処理を終了する。
【００９２】
図２６は、図２２に示す機能ブロック図における先頭かな文字の種別に応じて表示割合を変更した場合の具体例を示す図である。
【００９３】
同図において、かな文字列における先頭かな文字が「き」１文字の場合は、９つの候補が表示できる表示領域に第１の候補群には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、前方一致検索候補を３候補、全候補を６候補を表示している。第２の候補群に続く第３の候補群には、９候補すべてを全候補で表示している。対して、先頭かな文字が「か」１文字の場合は、第１の候補群には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、前方一致検索候補を４候補、全候補を５候補を表示している。第２の候補群に続く第３の候補群には、前方一致検索候補を２候補、全候補を７候補を表示している。図示されていないが、第３の候補群に続く第４の候補群には、９候補すべてを全候補で表示している。
【００９４】
（第４実施形態）
図２７〜図３０を用いて、本発明における第４実施形態を説明する。第４実施形態の特徴は、入力確定した候補を入力履歴候補として記憶する入力履歴候補データベースから直近の入力履歴候補を取得して、前方一致検索候補とかな漢字変換候補とともに表示画面の表示領域に表示することである。直近の入力履歴候補は、同じ言葉を繰り返し使って文章作成する利用者２にとって利便性の高いものである。入力履歴候補は、前方一致検索候補やかな漢字変換候補と重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどちらかの候補としてしまうとよい。
【００９５】
図２７は、入力履歴候補を記憶する学習辞書について機能ブロック図を用いて説明する図である。
【００９６】
同図において、言語入力システムは、表示領域に表示した候補の選択を情報入力部１から受け付ける機能と、受け付けた候補の選択によって文字を確定する機能とを有し、確定された文字はその後の処理の実行に用いられる。ここで言うところのその後の処理とは、例えば携帯端末９の利用目的そのものであると考えてよい。一方で言語入力システムは、表示領域に表示した候補の選択を情報入力部１から受け付ける機能から得られた選択結果を入力履歴情報として学習辞書ＤＢ１７に記憶する機能を有し、学習辞書ＤＢ１７に記憶された入力履歴情報に基づいて前方一致検索用辞書ＤＢ３やかな漢字変換用辞書ＤＢ５の利用頻度に関する評価値を更新する。
【００９７】
図２８は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００９８】
同図は、第１実施形態における図１０に示す機能ブロック図に対応する。同図において、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報の文字長を取得する機能と、取得した候補と入力履歴情報の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数および入力履歴数の割合を修正する機能とで構成されている。
【００９９】
図２９は、図２８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【０１００】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２９０１）、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報の文字長を取得し（ＳＴ２９０２）、各取得した候補と入力履歴情報の文字長が確定した表示領域にあらかじめ定める割合で収まるか否かを判定し（ＳＴ２９０３）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数および入力履歴数の割合を修正し（ＳＴ２９０４）、収まった場合にはそのまま、決定した候補および入力履歴の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８から取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報を入力履歴候補としてそれぞれ取得し（ＳＴ２９０５）、取得した候補群を表示領域に表示して（ＳＴ２９０６）、処理を終了する。
【０１０１】
図３０は、図２８に示す機能ブロック図における入力履歴を候補とする場合に具体例を示す図である。
【０１０２】
同図において、第１の候補群には、入力履歴候補を３候補、前方一致検索候補を３候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、入力履歴候補を２候補、前方一致検索候補を２候補、全候補を５候補を表示している。第２の候補群に続く第３の候補群には、入力履歴候補を１候補、前方一致検索候補を１候補、全候補を７候補を表示している。図示されていないが、第３の候補群に続く第４の候補群には、９候補すべてを全候補で表示している。入力履歴候補は、前方一致検索候補（およびかな漢字変換候補）よりも優先的に表示されるとよい。このように、入力履歴は同じ言葉を繰り返し使って文章作成する場合に利用頻度が高くなり、文章作成ではよくあることなので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（６）前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）に入力履歴候補加えた表示割合とすること。
（７）入力履歴候補が表示領域に表示される場合には、前方一致検索候補（およびかな漢字変換候補）よりも優先的に表示すること。
【０１０３】
（第５実施形態）
図３１〜図３３を用いて、本発明における第５実施形態を説明する。第５実施形態の特徴は、携帯端末９の情報出力部７における表示領域の画面偏移についてスクロール配列やセンタ配列にするなど候補群の配置に配慮したことである。
【０１０４】
図３１は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１０５】
同図において、各候補群はいわゆるスクロール配置で配置されており、第１の候補群から第２の候補群に切り替えた同じ方向に第３の候補群を配置している。順送りで候補群を表示しているので、第４の候補群、第５の候補群と切替操作を継続するような用途に適している。
【０１０６】
図３２は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１０７】
同図において、各候補群はいわゆるセンタ配置で配置されており、第１の候補群から第２の候補群に切り替えた逆の方向に第３の候補群を配置している。第１の候補群を第２の候補群と第３の候補群の中央に配置しているので、第３の候補群までで効率よく候補を探したいとする用途に適している。
【０１０８】
また、センタ配置に関する例として、全候補取得処理部８から出力される全候補について自立語の種類（例えば名詞、単漢字など）によって分けることも出来る。例えば、センタとなる第１の候補群には前方一致検索候補＋かな漢字変換候補＋（単漢字を除く）全候補を表示し、第２の候補群には前方一致候補＋（単漢字を除く）全候補を表示する。そして、第２の候補群とは逆の方向に表示する第３の候補群には単漢字の全候補を表示し、第３の候補群と同じ側はすべて単漢字の全候補を表示し続ける。よって、第１の候補群を中央とする片側にすべての単漢字が表示されるように、全候補の中でも特定の種類を持つ候補を表示することで効率よく候補を探すことが出来る。なお、第１の候補群を中央とするどちらかの方向に特徴的な全候補を揃える例はこれに限らず、言語入力システムの目的や利用者２の都合に合わせて変更できるようにしておいてもよい。
【０１０９】
図３３は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１１０】
同図において、図３２に示すセンタ配置の応用であり、入力履歴候補を片側に集めた場合である。前方一致検索候補やかな漢字変換候補ではなく、直近の入力履歴でよいとわかっている場合には便利な配置となる。
【０１１１】
【発明の効果】
以上記載の本発明によれば、少ない文字数で所望の文字が得られる前方一致検索処理は利用者にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るので、最初の候補群に前方一致検索候補とかな漢字変換候補とを少なくとも１つ以上は表示することにより、前方一致検索処理を所望する利用者にとっても単なるかな漢字変換を所望する利用者にとっても使い勝手のよい言語入力システムとすることが出来る。
【０１１２】
また、前方一致検索候補は、入力かな文字数を増やしていくと自動的に絞り込まれるので、最初の候補群には前方一致検索候補重視の表示割合として次の候補群に切り替わるに従って段階的にその割合を減らすことによって、簡単かつ効率のよい入力操作とすることが出来る。つまり、なるべく少ない入力かな文字数で利用者が所望する言葉を入力することが出来る。
【０１１３】
さらに、前方一致検索候補だけに頼ると「ありそうでない候補」は出力されないことが多いが、前方一致検索候補とかな漢字変換候補がその表示割合を変えながら、候補の追加（表示領域の切替）に対しても、入力されるかな文字の追加に対しても連続的につながっているので利用者が望む候補に一本化された操作で必ず辿り着けるという効果が期待できる。ここで言うところの一本化された操作とは、変換ボタンや切替ボタンの操作が不要であることを意味し、変換操作や切替操作が不要であるにも関わらず、利用者は追加の候補を表示する指示とかな文字列の追加による一連の動作のみで所望の言葉を入力できることになる。
【図面の簡単な説明】
【図１】 携帯電話に代表される、いわゆる１０キーデバイスでの日本語入力システムにおける入力方法を説明する図
【図２】 前方一致検索処理について説明する図
【図３】 かな文字が追加入力された場合の前方一致検索処理について説明する図
【図４】 かな漢字変換処理に用いるかな漢字変換辞書について説明する図
【図５】 かな漢字変換処理における連文節変換候補取得処理について説明する図
【図６】 かな漢字変換処理における全候補取得処理について説明する図
【図７】 本発明の実施形態における言語入力システムを備える携帯端末のハードブロック図
【図８】 本発明の実施形態における言語入力システムの機能ブロック図
【図９】 本発明の実施形態における言語入力システムの機能ブロック図
【図１０】 図９に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図１１】 図８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１２】 図９に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１３】 図１０に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１４】 図１３のフローチャートに示す表示割合の修正をした場合の具体例を示す図
【図１５】 入力されたかな文字数と前方一致検索用辞書の平均候補数の関係を示す図
【図１６】 本発明の実施形態における言語入力システムの機能ブロック図
【図１７】 本発明の実施形態における言語入力システムの機能ブロック図
【図１８】 図１７に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図１９】 図１７に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２０】 図１８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２１】 入力されたかな文字列における先頭かな文字と前方一致検索用辞書の候補数の関係を示す図
【図２２】 本発明の実施形態における言語入力システムの機能ブロック図
【図２３】 図２２に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図２４】 図２２に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２５】 図２３に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２６】 図２２に示す機能ブロック図における先頭かな文字の種別に応じて表示割合を変更した場合の具体例を示す図
【図２７】 入力履歴候補を記憶する学習辞書について機能ブロック図を用いて説明する図
【図２８】 本発明の実施形態における言語入力システムの機能ブロック図
【図２９】 図２８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図３０】 図２８に示す機能ブロック図における入力履歴を候補とする場合に具体例を示す図
【図３１】 本発明の実施形態における候補群の配置の具体例を示す図
【図３２】 本発明の実施形態における候補群の配置の具体例を示す図
【図３３】 本発明の実施形態における候補群の配置の具体例を示す図
【符号の説明】
１ 情報入力部
２ 利用者
３ 前方一致検索用辞書ＤＢ
４ 前方一致検索処理部
５ かな漢字変換用辞書ＤＢ
６ 連文節変換候補取得処理部
７ 情報出力部
８ 全候補取得処理部
９ 携帯端末
１３ ネットワーク
１６ 表示割合情報ＤＢ
１７ 学習辞書ＤＢ
１８ かな漢字変換処理部
【発明の属する技術分野】
本発明は、言語入力、特に前方一致検索処理手段とかな漢字変換処理手段をともに有する言語入力方法及びシステムに関する。
【０００２】
【従来の技術】
日本語入力を効率よく入力する先行技術として、特開２００１−３２５２５２号公報が挙げられる。この先行技術では、入力されたかな文字列に対して前方一致検索候補（予測候補検索変換）を出力し、追加のかな文字列を入力することによって前方一致検索候補に加えてかな漢字変換候補を混在して出力している。ただし、これは出力すべき前方一致検索候補が減少したために、またはかな漢字変換候補と一致したために前方一致検索処理をかな漢字変換処理に切り替えているに過ぎない。つまり、入力されたかな文字列に対して前方一致検索処理とかな漢字変換処理を実行しているとは言えない。
【０００３】
【特許文献１】
特開２００１―３２５２５２号公報（第１５頁、第図２０）
【０００４】
【発明が解決しようとする課題】
ハードウェアと通信インフラの目覚ましい進歩によって、携帯電話などの携帯端末によって場所を選ばずとも情報の送受信が出来るようになってきた。ところが、小型、軽量を重要な要素とする携帯端末は、複雑な文字入力のためであっても必要最小限の操作スイッチしか用意できない。例えば「０」キーから「９」キーまでの１０キーとその他少数キーに複数の機能を割り当てて、それらを使い分けている。図１〜図６を用いて必要最小限の操作スイッチによる文字入力技術について説明する。
【０００５】
図１は、携帯電話に代表される、いわゆる１０キーデバイスでの日本語入力システムにおける入力方法を説明する図である。
【０００６】
同図において、情報入力部１から利用者２の操作によって「２」「ＡＢＣ」「か」が割り当てられた入力キーが２回操作されると、かな文字列の入力を受け付ける機能によって対応する入力信号が出力され、入力されたかな文字列を取得する機能によって、言語入力システムはかな文字「き」を取得する。同様に「８」「ＴＵＶ」「や」が割り当てられた入力キーが６回操作されると、かな文字「ょ（小文字のよ）」を取得し、「１」「．＠／」「あ」が割り当てられた入力キーが３回操作されるとかな文字「う」を取得し、「４」「ＧＨＩ」「た」が割り当てられた入力キーが５回操作されると、かな文字「と」を取得する。よって、これら一連の処理によってかな文字列「きょうと」を取得することが出来る。このかな文字列「きょうと」をかな漢字変換処理することによって、「きょうと」が「京都」になる。
【０００７】
入力されたかな文字列を漢字混じりの文章に変換する処理がかな漢字変換処理であるが、変換対象となるかな文字列「きょうと」を確定させるまでに操作を繰り返す必要があり、さらにかな漢字変換処理実行を指示する操作も必要である。携帯端末として必須な携帯性を維持するために、このように煩雑な操作が必要では利便性が悪くて仕方がないので、考え出された処理が入力予測検索処理とも呼ばれる前方一致検索処理である。
【０００８】
図２は、前方一致検索処理について説明する図である。
【０００９】
同図において、前方一致検索用辞書ＤＢ３とは、前方一致検索処理部４が用いる単語が記憶された辞書データベースのことであり大量の文書から言語入力システムが扱う言語（図例では日本語）の文章として使用頻度の高い単語をあらかじめ記憶されている。なお、言語入力システムで確定した単語を記憶容量の範囲で追加的に記憶することもある。また、前方一致検索処理部４とは、情報入力部１から入力された「かな文字列」で始まる単語を前方一致検索候補として前方一致検索用辞書ＤＢ３から検索することによって抽出し、抽出した候補を出力する処理のことである。なお、前方一致検索処理部４が抽出する前方一致検索候補は、使用頻度の高さを評価値とする順番で並べられている。
【００１０】
図例では、かな文字「き」を入力しただけで、かな文字「き」から始まる「今日、機能、昨日、規則、帰宅、気持ち、期待、キャッチフレーズ、ギブアンドテーク、・・・」などの日本語としてよく使われる単語が前方一致検索候補として出力されている。
【００１１】
図３は、かな文字が追加入力された場合の前方一致検索処理について説明する図である。
【００１２】
同図において、前方一致検索処理部４では、かな文字「き」に続いてかな文字「ょ」が入力されると、かな文字列「きょ」から始まる「今日、教室、曲、教育、・・・」などの単語が前方一致検索候補として出力される。かな文字を追加入力することで前方一致検索候補は自動的に絞り込まれることになる。つまり、かな文字「き」につづいてかな文字「ょ」が前方一致検索処理部４に入力されると、かな文字「き」から始まる前方一致検索候補の中からかな文字列「きょ」以外で始まる前方一致検索候補は出力されなくなるので、出力される候補数が自動的に減少する。
【００１３】
ところが、前方一致検索処理には、少ない入力かな文字で所望の単語が得られるという利点がある反面、前方一致検索用辞書ＤＢ３に記憶する前方一致検索候補としての融通が利かないこともその特徴であり、例えば「キャッシュ」「キャッシュカード」「キャッシュフロー」「キャッシュディスペンサー（現金自動支払機）」はすべて違う単語として記憶している。もちろん、前方一致検索処理において「現金自動支払機」と「現金自動支払い機」、さらに「現金自動支払装置」は全く別の単語として認識されている。よって、登録単語数を増やせば増やすほどのデータベースの容量が必要となるのが最大の欠点であり、痒いところに手が届くような語彙数とするために単語を片っ端から登録すると膨大な数の記憶容量が必要となってしまう。
【００１４】
また、我々が日常使っている言葉は生き物であり、時とともに変化し続けている。つまり、言葉の組み合わせや言い回しおよび表現は多様化の方向に変化し、個々の利用者２によって使い慣れた言葉が異なっているので、利用者２にとって「これくらいはあるだろう」と思っても「実際にはなかった」という前方一致検索用辞書ＤＢ３に記憶されていない「ありそうでない単語」が増える一方であるとも言える。図例では、かな文字数４文字の「きょうと」について前方一致検索辞書ＤＢ３に候補がなかったので、前方一致検索処理部４は入力されたかな文字列「きょうと」をそのまま出力している。候補がなかった場合には「きょうと」「キョウト」のようにカタカナ表記も出力することもある。
【００１５】
図４は、かな漢字変換処理に用いるかな漢字変換辞書について説明する図である。
【００１６】
ここで、かな漢字変換処理についても説明しておく。同図では、まずかな漢字変換処理に用いるかな漢字変換用辞書を記憶するかな漢字変換辞書ＤＢ５について説明する。同図において、かな漢字変換用辞書ＤＢ５は、日本語として構成可能な自立語と付属語をその品詞とともに記憶している辞書データベースのことである。日本語は単文節または連文節（多文節）で構成されており、単文節はひとつの自立語またはひとつの自立語と付属語の組み合わせで構成されている。ここで言うところの自立語とは、名詞や動詞などの単語のことであり、動詞には活用によって語尾が変化する。また、付属語とは自立語に付属して文節を構成する助詞や助動詞の類のことである。「私は医者に行く」という文章において、先頭文節は「私は」であり、自立語「私」と付属語「は」で構成され、第２文節は「医者に」であり、自立語「医者」と付属語「に」で構成され、第３文節は「行く」であり、自立語「行」と付属語「く」で構成されている。
【００１７】
図５は、かな漢字変換処理における連文節変換候補取得処理について説明する図である。
【００１８】
かな漢字変換処理は連文節変換候補取得処理と全候補取得処理から構成されており、ここでは連文節変換候補取得処理について説明する。同図において、利用者２の変換ボタンの操作によってかな漢字変換の指示を受け付けると、受け付けた変換指示に基づいてかな漢字変換処理に切り替えることによって連文節変換候補取得処理が実行される。連文節変換候補取得処理部６とは、情報入力部１から入力されたかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出し、自立語および付属語に付与された品詞に基づいて接続可能な組み合わせを多文節（または全文節）で多文節解析し、多文節解析した候補の中から最も評価値の高い候補を出力する処理のことである。
【００１９】
「きょうとにいく」という入力かな文字列を例に説明すると、連文節変換候補取得部６は、入力されたかな文字列を取得すると、取得したかな文字列で構成できる自立語と付属語を抽出し、抽出した自立語と付属語を組み合わせてみると例えば「今日―と−に−行−く」や「京都−に−行−く」など様々な組み合わせの候補が出来る。その組み合わせをそれぞれ構成可能な品詞の接続について多文節（または全文節）で解析して、最も評価値の高い組み合わせである「京都−に−行−く」を候補として選択することを多文節解析と言い、多分析解析した解析結果として「京都に行く」という候補を出力する。
【００２０】
図例では「きょうと」という入力かな文字が入力された場合を示す。まず前方一致検索処理部４による処理が実行されたが、かな文字列「きょうと」に対応する前方一致候補がなかったために、そのまま「きょうと」と情報出力部７に表示されている。仕方がないので利用者２は、かな漢字変換処理を指示するために情報入力部１にある変換ボタンを操作すると、入力かな文字列に対する処理が前方一致検索処理から連文節変換候補取得処理に切り替えられ、そのとき評価値が最も高い候補であった「京都」が出力される。
【００２１】
図６は、かな漢字変換処理における全候補取得処理について説明する図である。
【００２２】
同図において、連文節変換候補取得処理部６によって、「京都」ではなく「今日と」が出力された場合には、利用者２は自らが所望する「京都」を得るために切替ボタンを操作する。情報入力部１にある切替ボタンが操作されると、受け付けた切替指示に基づいて全候補取得処理が実行される。全候補取得処理部８とは、連文節変換候補取得処理部６で解析した結果（多文節解析結果）を取得して、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力する処理のことである。
【００２３】
「今日と」と「京都」は連文節変換候補取得処理部６によって多文節解析をしても評価値に差がほとんどないことが多く、この場合にはどちらが頻繁に使用されているかという利用頻度によって評価値が決定されるので、「今日と」など所望しない候補が出力されてしまうこともよくある。そこで、全候補取得処理を実行すると、多文節解析結果から各文節の全候補が取得されるので「今日と、京と、京都・・・」が出力されることになる。利用者２はこの出力の中から自らが所望する「京都」を選択することが出来る。
【００２４】
前方一致検索処理にもかな漢字変換処理にも長所と短所があり、どちらかが優れているというわけではない。それぞれの良いところをうまく使い分ける仕組みが大切である。特開２００１―３２５２５２号公報のようにかな漢字変換処理の前に前方一致検索処理を実行するというのは理にかなっている。
【００２５】
ただし、入力かな文字または入力かな文字列に対して前方一致検索候補のみを出力して、表示領域に表示することは様々な問題がある。まず始めに挙げられるのは、少ない文字数で利用者が望む単語を当てることが現実的に非常に困難であることである。例えば「あ」と入力されたかな文字でどんな言葉を利用者が入力しようとしているかズバリ当てられるだろうか。文章の流れで予測する技術も数多く考案されてはいるものの膨大な処理の割には得られる効果、つまり利用者が納得できる候補を出力できることが稀である。的外れな結果を出力し続けていると、使い物にならないシステムとして利用者からソッポを向かれ、結局は利用されない不要な機能になってしまうという問題点があった。
【００２６】
さらに限られた表示領域に表示できる候補数で利用者が望む単語を当てることも困難であることである。色々な言葉を出してみれば確率的に利用者が納得できる候補を出力できるはずではあるが、どうしても当てずっぽうになりがちな候補を５つ出そうが１０個出そうがまず当たらない。これもまた、的外れな結果を出力し続けていると、使い物にならないシステムとして利用者からソッポを向かれ、結局は利用されない不要な機能になってしまうという問題点があった。
【００２７】
かと言って、単純に前方一致検索用辞書の単語数を増やして多くの候補を一度に出せば良いというものでもない。多くの候補を一度に出すと利用者はそれらの候補の中に所望の候補があるか探そうとするが、利用者にとって所望する単語はたった一つであるために所望しないその他の候補を多くする結果となり、探し出す手間が増え、利用者がイライラし出すという問題点があった。
【００２８】
また、前方一致検索用辞書の単語数を増やすと利用者の期待が高まるのは間違いないが、無かった場合には期待が高まった分だけ失望が大きくなるので、前方一致検索処理によって期待をさせた結果「ありそうでなかった単語」は利用者の期待を最も裏切ってしまうことが隠れた問題点であった。使い方によっては便利な前方一致検索候補ではあるが、その候補の出し方に工夫が足りない。
【００２９】
【課題を解決するための手段】
本発明の本質は、入力されたかな文字列に対して前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）をそれぞれ少なくとも１候補以上は「最初の候補群」として表示画面の表示領域に前方一致検索候補重視の表示割合で表示するとともに、「最初の候補群」として表示領域に表示しきれなかった候補を「次の候補群」として表示する場合には、「最初の候補群」と前方一致検索候補とかな漢字変換候補との表示割合を変更して、前方一致検索候補の表示割合を減らして全候補の表示割合を増やすことである。
【００３０】
本発明は、情報入力部から入力された入力かな文字列を取得するかな文字列取得手段と、前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、前方一致検索処理を実行し、実行結果である前方一致検索候補を出力する前方一致検索処理手段と、前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、かな漢字変換処理を実行し、実行結果であるかな漢字変換処理候補を出力するかな漢字変換処理手段と、前記前方一致検索処理手段から出力された前記前方一致検索候補の文字長と前記かな漢字変換処理手段から出力された前記かな漢字変換候補の文字長をそれぞれ必要数取得する候補文字長取得手段と、前記候補文字長取得手段が取得した候補の文字長に基づき、それらの候補を表示する表示領域に合わせて、前記前方一致検索候補の表示割合と前記かな漢字変換候補の候補数の表示割合を決定する表示割合決定手段と、前記表示割合決定手段が決定した表示割合に基づいて、前記前方一致検索処理手段から前記前方一致検索候補を、前記かな漢字変換処理手段から前記かな漢字変換候補をそれぞれ取得する候補取得手段と、前記候補取得手段が取得した前記前方一致検索候補と前記かな漢字変換候補を前記表示領域に合わせて配置する候補配置手段と、前記候補配置手段が前記表示領域に合わせて配置した候補群を配置結果として前記表示領域に表示する表示手段と、前記表示領域に表示した候補に対して選択入力を受け付けると、選択入力を受け付けた候補を入力確定する入力確定手段とを有するようにした。
【００３１】
前記表示割合決定手段は、取得した各候補の文字長があらかじめ定める割合で前記表示領域に収まるか否かに基づいて、前記前方一致検索候補の表示割合と前記かな漢字変換候補の候補数の表示割合を決定するようにするとよい。前記表示割合決定手段は、取得した各候補の文字長があらかじめ定める割合で前記表示領域に収まらないと判断した場合には、あらかじめ定める表示割合に関する表示割合ルール（取り決め）を満たした上で表示割合を修正してもよい。また、前記表示領域に表示しきれなかった次の候補群への表示切替を要求する要求信号を受け付けると、前記表示割合決定手段は前記前方一致検索候補の表示割合を減らすようにするとよい。
【００３２】
少ない文字数で所望の文字が得られる前方一致検索処理は利用者にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るので、最初の候補群に前方一致検索候補とかな漢字変換候補とを少なくとも１つ以上は表示することにした。かな漢字変換候補は連文節変換候補と全候補から成るので、最初の候補群に連文節変換候補を１つと全候補を少なくとも１つ以上表示するとよい。なお、前方一致検索候補は、入力かな文字数を増やしていくと自動的に絞り込まれるので、２度ほど候補群を切り替えると諦めてしまうことが多い利用者心理に配慮して、最初の候補群には前方一致検索候補重視の表示割合として、次の候補群に切り替わるに従って段階的にその割合を減らすこととした。
【００３３】
なお、前方一致検索候補や連文節変換候補と全候補は重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどれかかの候補としてしまうとよい。この重複を削除する処理は、各処理部から候補が出力された直後に実行しておくと効率的である。このような前処理をしておくと、重複が削除された後の候補について表示割合を決定することになる。
【００３４】
また、前記表示割合決定手段は、前記入力かな文字列の入力された文字数の増加に応じて、前記前方一致検索候補の表示割合を減らすようにしてもよい。
【００３５】
より具体的には、かな漢字変換候補に比べ、入力かな文字数を増やすと候補数が減少する度合の大きい前方一致検索候補の特徴に配慮して、効率のよい候補表示をするために入力かな文字数に応じて、前方一致検索候補の表示割合を減らすようにした。
【００３６】
また、前記表示割合決定手段は、前記入力かな文字列の入力された先頭かな文字に応じて、前記前方一致検索候補の表示割合を変更するようにしてもよい。
【００３７】
より具体的には、先頭かな文字に応じてデータベースに記憶する候補数に大きなバラツキが生じる前方一致検索候補の特徴に配慮して、先頭かな文字に対応する候補数に応じた増減調整を前方一致検索候補数に加えるようにした。
【００３８】
また、前記入力確定した候補を入力履歴候補として記憶する入力履歴候補データベースをさらに有し、前記候補文字長取得手段は、前記前方一致検索候補の文字長と前記かな漢字変換候補の文字長を取得する際に、前記入力履歴候補データベースから前記入力履歴候補の文字長も必要数取得し、前記表示割合決定手段は、前記候補文字長取得手段が取得した候補の文字長に基づき、それらの候補を表示する表示領域に合わせて、前記前方一致検索候補と前記かな漢字変換候補および前記入力履歴候補の表示割合を決定するようにしてもよい。
【００３９】
また、前記候補配置手段は、前記表示領域において前記前方一致検索候補や前記かな漢字変換候補よりも優先的に前記入力履歴候補を表示するようにしてもよい。
【００４０】
より具体的には、入力履歴は同じ言葉を繰り返し使って文章作成する場合に利用頻度が高くなり、文章作成ではよくあることなので、前方一致検索候補とかな漢字変換候補とは別枠として表示領域に表示割合を確保した。また、直近の入力履歴候補は、同じ言葉を繰り返し使って文章作成する利用者にとって利便性の高いものであるので、その優先順位を高くした。なお、入力履歴候補は、前方一致検索候補やかな漢字変換候補と重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどちらかの候補としてしまうとよい。
【００４１】
【発明の実施の形態】
以下に、本発明に係る言語入力システムの具体的実施の形態を図面を参照して詳細に説明する。
【００４２】
（第１実施形態）
図７〜図１４を用いて、本発明における言語入力システムの基本となる第１実施形態を説明する。
【００４３】
図７は、本発明の実施形態における言語入力システムを備える携帯端末のハードブロック図である。
【００４４】
同図において、情報入力部１と情報出力部７は、携帯端末９と利用者２とが種々のやりとりをするための入出力機能を持つ部位である。情報入力部１における入力装置としては、例えばテンキーなどの各種スイッチ、手書き文字認識装置、音声入力装置などが該当し、利用者２の入力がシステムに対して情報を伝達するものなら、その種類は問わない。また、情報出力部７における出力装置としては、例えば表示画面（ディスプレイ）、音声出力装置などが該当し、利用者２に対してシステムから情報を伝達できるものなら、その種類は問わない。演算部１０とは、プログラムを実行することによって各機能を駆動、処理するための演算機能を持つ部位であり、一般にＣＰＵ（中央演算装置）で構成される。メモリ部１１とは、演算部１０が実行するプログラムの実行エリアの部位である。通信部１２とは、ネットワーク１３を介して他の端末やシステムとの間で情報の通信を制御する部位である。ＤＢ管理部１４とは、様々なデータ構造とデータ実体を管理する機能を持つ部位である。
【００４５】
ＤＢ管理部１４に管理される処理プログラム１５とは、携帯端末９の利用目的を達成するために必要なプログラムのことであり、ＯＳ（オペレーティングシステム）もここに含まれる。前方一致検索用辞書ＤＢ３とかな漢字変換用辞書ＤＢ５もＤＢ管理部１４に管理されている。同様に、表示割合情報ＤＢ１６とは、表示画面の表示領域に表示する前方一致検索候補数とかな漢字変換候補数との表示割合を記憶するデータベースのことである。同様に学習辞書ＤＢ１７とは、前方一致検索用辞書ＤＢ３とかな漢字変換用辞書ＤＢ５とがそれぞれ評価値のひとつに用いる入力履歴情報を記憶するデータベースのことである。
【００４６】
図８は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００４７】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８を有し、かな漢字変換処理部１８は、連文節変換候補取得処理部６と全候補取得処理部８から構成されている。前方一致検索処理部４は、情報入力部１からかな文字列の入力を受け付ける機能によって受け付けたかな文字列を取得する機能と、取得したかな文字列に基づいて前方一致検索用辞書ＤＢ３から候補を検索する機能と、検索した候補を出力する機能を有する。連文節変換候補取得処理部６は、情報入力部１からかな文字列の入力を受け付ける機能によって受け付けたかな文字列を取得する機能と、取得したかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出する機能と、抽出した自立語および付属語で構成可能な（抽出した自立語および付属語に付与された品詞に基づいて接続可能な）組み合わせを多文節（または全文節）で多文節解析する機能と、多文節解析した候補の中から最も評価値の高い候補を出力する機能とを有する。全候補取得処理部８は、連文節変換候補取得処理部６で解析した結果（多文節解析結果）から全候補を取得する機能と、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力する機能とを有する。このように情報入力部１で受け付けたかな文字列に対して、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）がそれぞれ出揃うことになる。
【００４８】
図９は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００４９】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長を取得して、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。図例では、９つの候補が表示できる表示領域に第１の候補群（初期候補群）には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群（第２候補群）には、前方一致検索候補を３候補、全候補を６候補を表示している。第２の候補群に続く第３の候補群（第３候補群）には、９候補すべてを全候補で表示している。
【００５０】
なお、前方一致検索候補や連文節変換候補と全候補は重複することもあるので、もちろんその場合には重複して候補を表示するのではなく、どれかかの候補としてしまうとよい。この重複を削除する処理は、各処理部から候補が出力された直後に実行しておくと効率的である。このような前処理をしておくと、重複が削除された後の候補について表示割合を決定することになる。
【００５１】
図１０は、図９に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００５２】
同図は、図９に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得（『前方一致検索処理部４から前方一致検索候補の文字長を、かな漢字変換処理部１８からかな漢字変換候補の文字長をそれぞれ必要数取得』と同意）する機能では、各処理部から多めの候補数を取得するようにあらかじめ定める数を決めておくと、表示領域に空きスペースが出来た場合に候補の文字長を取得し直さなくてもよくなる。ただし、かな漢字変換処理で得られる候補は極端に短くなることもなく、前方一致検索処理で得られる候補は登録される単語によっては長いこともあるので、処理としては取得した候補に対して表示領域が余るよりも足らなくなることの方が多いようである。
【００５３】
また、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能における「あらかじめ定める割合」とは、表示割合情報ＤＢ１６から取得する候補数の割合のことであり、割合で示されることもその割合を満たす候補数で示されることもある。具体的には、例えば９つの候補が表示できる表示領域に第１の候補群（初期候補群）として、前方一致検索候補と連文節変換候補と全候補の割合を６：１：２（６候補：１候補：２候補）で取得した候補の文字長が表示領域に収まるか否かを判断する。同様に、第１の候補群に続く第２の候補群（第２候補群）として、前方一致検索候補と全候補の割合を３：６（３候補：６候補）で取得した候補の文字長が表示領域に収まるか否かを判断し、第２の候補群に続く第３の候補群（第３候補群）として、９候補すべてを全候補で取得した候補の文字長が表示領域に収まるか否かを判断している。収まらないと判断された前方一致検索候補は次の候補群における前方一致候補の先頭に順送りされ、同様に収まらないと判断されたかな漢字変換候補は次の候補群のかな漢字変換候補の先頭に順送りされる。なお、連文節変換候補は入力されたかな文字列に対して基本的に１つしか存在しないので、表示領域に表示されるのは第１の候補群のみである。
【００５４】
表示割合情報ＤＢ１６から取得される各候補の表示割合情報は以下の配慮（表示割合ルールの取り決め）がなされている。
（１）入力されたかな文字列に対して前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）をそれぞれ少なくとも１候補以上は「最初の候補群」として表示画面の表示領域に表示し、表示割合は前方一致検索候補重視（前方一致検索候補の表示割合が、かな漢字変換候補の表示割合より少なくとも同等以上）とすること。
（２）「最初の候補群」として表示領域に表示しきれなかった候補となる「次の候補群」には、「最初の候補群」と前方一致検索候補とかな漢字変換候補との表示割合を変更し、前方一致検索候補の表示割合を減らして全候補の表示割合を増やすこと。
（３）前方一致検索候補の表示割合を減らして、前方一致検索候補として表示する候補数が０となった候補群以降は、すべて全候補であること。
【００５５】
このような表示割合情報に含まれる表示割合ルールによって、言語入力システムは「最初の候補群」ではかな漢字変換候補の表示割合よりも前方一致検索候補の表示割合を多くし、「次の候補群」への切り替わりに応じてかな漢字変換候補の表示割合が多くなり、そのうち表示領域に表示される候補がすべてかな漢字変換候補にする。別の言い方をすれば、始めは前方一致検索候補重視でそれぞれの候補を表示し、候補を追加する（つまり、候補群を切り替えていく）に従ってかな漢字変換候補重視での候補群の表示に変えていく。
【００５６】
表示割合という表現であるのは、前方一致検索候補は入力かな文字に対して比較的長い単語が出力されることもあり、前方一致検索候補重視にしているにも関わらず候補数はかな漢字変換候補の方が多いことがあり得ることによる。つまり、各候補を文字長（もしくは文字数）に換算した上での表示領域の占有率をここで言うところの「表示割合」と考えてもよい。
【００５７】
これらの表示割合ルールは、利用者２がかな文字を入力する際の行動における心理的分析から得られた見地を根拠としている。まず、表示割合ルール（１）では、少ない文字数で所望の文字が得られる前方一致検索処理は利用者２にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るという前方一致検索処理の落とし穴（盲点）に着目した。単漢字などの文字数の少ない漢字の入力を所望している場合の利用者２にとって、前方一致検索候補は無用の長物であって、表示領域すべてが前方一致検索候補で埋まっていたりすると、例えば「単なる漢字が欲しいだけなのに何でこんなに大袈裟なんだ」などと呆れるか、急いでいるときや慌てているときなどの心理的余裕の少ないときにはイライラしたり怒り出す傾向がある。よって、例えば「き」というかな文字が入力された場合に「木」という漢字は前方一致検索辞書にはまず登録されていないので、前方一致検索処理部４はかな文字「き」から始まる「今日、機能、昨日、規則、帰宅、気持ち、期待、キャッチフレーズ、ギブアンドテーク、・・・」を前方一致検索候補として出力する。よって、単に「木」という漢字を所望している利用者２にも配慮して、最初の候補群にかな漢字変換候補を少なくとも１つ以上は表示することにした。かな漢字変換候補は連文節変換候補と全候補から成るので、最初の候補群に連文節変換候補を１つと全候補を少なくとも１つ以上表示するとよい。
【００５８】
表示割合ルール（２）では、前方一致検索候補は入力かな文字数を増やせば自動的に絞り込まれることに着目した。利用者２の入力行動を実際に観察していると、入力したかな文字列に対して表示画面の表示領域に表示される最初の候補群に所望の候補が無かった場合に、次の候補群に切り替えるが、そこにもなくて再度切り替えて無いと諦めてしまうようである。つまり、利用者２が表示領域を切り替える回数はほとんどの場合２回までで、２回切替操作を実行して表示された候補の中に所望の候補が無かった場合にはかな文字列を追加入力することが多いことになる。よって、３つ分の表示領域にバランスよく前方一致検索候補とかな漢字変換候補を配置するために、最初の候補群には前方一致検索候補重視の表示割合として、次の候補群に切り替わるに従って段階的にその割合を減らすこととした。
【００５９】
表示割合ルール（３）では、表示割合ルール（２）を実行すると自明ではあるが、前方一致検索候補が表示領域に表示されなくなっても、なお次の候補群に切り替えているというのは、かな漢字変換候補を利用者２が探していることになるので、以降は全候補がなくなるまで候補群として表示領域に表示する。
【００６０】
図１１は、図８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６１】
同図において、言語入力システムは、情報入力部１からかな文字列の入力を受け付けると（ＳＴ１１０１）、受け付けたかな文字列を前方一致検索処理部４とかな漢字変換処理部１８に受け渡して（ＳＴ１１０２）、処理を終了する。前方一致検索処理部４では、かな文字列を取得すると、取得したかな文字列に基づいて前方一致検索用辞書ＤＢ３から候補を検索し（ＳＴ１１０３）、検索した候補を出力して（ＳＴ１１０４）、処理を終了する。連文節変換候補取得処理部６では、かな文字列を取得すると、取得したかな文字列で構成できる自立語と付属語をかな漢字変換用辞書ＤＢ５から抽出し（ＳＴ１１０５）、抽出した自立語および付属語で構成可能な（抽出した自立語および付属語に付与された品詞に基づいて接続可能な）組み合わせを多文節（または全文節）で多文節解析し（ＳＴ１１０６）、多文節解析した候補の中から最も評価値の高い候補を出力して（ＳＴ１１０７）、処理を終了する。全候補取得処理部８では、連文節変換候補取得処理部６で解析した結果（多文節解析結果）から全候補を取得し（ＳＴ１１０８）、各文節の全候補を多文節解析で用いた評価値の高い順に並べて出力して（ＳＴ１１０９）、処理を終了する。
【００６２】
図１２は、図９に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６３】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１２０１）、各処理が出力する候補の文字長を取得し（ＳＴ１２０２）、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ１２０３）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１２０４）、取得した候補群を表示領域に表示して（ＳＴ１２０５）、処理を終了する。
【００６４】
図１３は、図１０に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００６５】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１３０１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ１３０２）、取得した候補の文字長が確定した表示領域にあらかじめ定める割合で収まるか否かを判定し（ＳＴ１３０３）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ１３０４）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１３０５）、取得した候補群を表示領域に表示して（ＳＴ１３０６）、処理を終了する。
【００６６】
図１４は、図１３のフローチャートに示す表示割合の修正をした場合の具体例を示す図である。
【００６７】
同図において、前方一致検索処理部４はかな文字「き」から始まる「キャッチフレーズ、今日、機能、ギブアンドテーク、昨日、規則、帰宅、気持ち、期待、・・・」を前方一致検索候補として出力している。すると、第１の候補群に前方一致検索候補が６候補収まりきれないので、前方一致検索候補を収まる分の４候補、連文節変換候補を１候補、全候補を２候補を表示し、収まらなかった前方一致検索候補の２候補は第２の候補群に回している。なお、図例に示すように第１の候補群に続く第２の候補群には、前方一致検索候補を３候補、全候補を６候補を表示して、第２の候補群に続く第３の候補群には、９候補すべてを全候補で表示するところを２候補分の前方一致検索候補を表示して、全候補を７候補としてもよい。
【００６８】
（第２実施形態）
図１５〜図２０を用いて、本発明における第２実施形態を説明する。第２実施形態の特徴は、かな文字列が追加入力された場合にも、表示画面の表示領域に表示する前方一致検索候補とかな漢字変換候補との表示割合を変更することである。これは、入力かな文字列の数に応じて表示割合ルールを変更することを意味する。
【００６９】
図１５は、入力されたかな文字数と前方一致検索用辞書の平均候補数の関係を示す図である。
【００７０】
同図において、平均的な語彙数である２０００語を収める前方一致検索用辞書において、入力されたかな文字列の文字数に対してどのくらいの語彙数の前方一致検索候補が納められているかを示す図である。図によると、かな文字列の文字数が１文字の場合は３４候補であり、同様に２文字の場合は６候補、３文字の場合は２候補、４文字の場合は１候補、５文字の場合は１候補である。このように、入力かな文字列の増加に伴い、前方一致検索候補の数が減少するので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（４）入力されたかな文字列の文字数に応じて、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）の表示割合を変更すること。
【００７１】
図１６は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００７２】
同図は、図８に示す処理に続いて情報入力部１からかな文字列が続けて入力された場合の処理を示す。同図において、言語入力システムは、情報入力部１からかな文字列の入力を受け付ける機能によって追加入力されたかな文字列を取得すると、追加入力されたかな文字列を加えたかな文字列に対して再度、前方一致検索処理とかな漢字変換処理を実行する。図１６に示す機能ブロック図に対応するフローチャートは、図１１に示すフローチャートと同様である。
【００７３】
図１７は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００７４】
同図において、言語入力システムは、入力されたかな文字列の文字数を取得する機能と、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長および入力されたかな文字列の文字数を取得して、取得した候補の文字長およびかな文字列の文字数とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。図例では、９つの候補が表示できる表示領域に第１の候補群（初期候補群）には、前方一致検索候補を４候補、連文節変換候補を１候補、全候補を４候補を表示している。第１の候補群に続く第２の候補群（第２候補群）には、前方一致検索候補を２候補、全候補を７候補を表示している。第２の候補群に続く第３の候補群（第３候補群）には、９候補すべてを全候補で表示している。
【００７５】
図１８は、図１７に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００７６】
同図は、図１７に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長およびかな文字列の文字数とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、入力されたかな文字列の文字数に基づいて表示割合情報を表示割合情報ＤＢ１６から取得する機能と、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。
【００７７】
図１９は、図１７に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００７８】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ１９０１）、入力されたかな文字列の文字数を取得し（ＳＴ１９０２）、各処理が出力する候補の文字長を取得し（ＳＴ１９０３）、取得したかな文字列の文字数および取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ１９０４）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ１９０５）、取得した候補群を表示領域に表示して（ＳＴ１９０６）、処理を終了する。
【００７９】
図２０は、図１８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００８０】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２００１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ２００２）、情報入力部１から入力されたかな文字列の文字数に基づいて表示割合情報ＤＢ１６から表示割合情報を取得し（ＳＴ２００３）、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか否かを判定し（ＳＴ２００４）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ２００５）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２００６）、取得した候補群を表示領域に表示して（ＳＴ２００７）、処理を終了する。
【００８１】
（第３実施形態）
図２１〜図２６を用いて、本発明における第３実施形態を説明する。第３実施形態の特徴は、かな文字列における先頭かな文字に応じて、表示画面の表示領域に表示する前方一致検索候補とかな漢字変換候補との表示割合を変更することである。これは、入力かな文字列の先頭かな文字が何であるかに応じて表示割合ルールを変更することを意味する。
【００８２】
図２１は、入力されたかな文字列における先頭かな文字と前方一致検索用辞書の候補数の関係を示す図である。
【００８３】
同図において、平均的な語彙数である２０００語を収める前方一致検索用辞書において、入力されたかな文字列における先頭かな文字に対してどのくらいの語彙数の前方一致検索候補が納められているかを示す図である。図によると、かな文字列における先頭かな文字が「き」１文字の場合は４８候補であるのに対して、先頭かな文字が「か」１文字の場合は１１８候補もある。このように、入力かな文字列における先頭かな文字によって、前方一致検索候補の数が増減するので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（５）入力されたかな文字列における先頭かな文字に応じて、前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）の表示割合を変更すること。
【００８４】
図２２は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００８５】
同図において、言語入力システムは、入力されたかな文字列における先頭かな文字を取得する機能と、前方一致検索処理部４とかな漢字変換処理部１８が出力する候補の文字長および入力されたかな文字列における先頭かな文字を取得して、取得した候補の文字長および先頭かな文字の種別とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能と、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、取得した候補群を表示領域に表示する機能とを有する。
【００８６】
図２３は、図２２に示す機能ブロック図の機能をより詳細に示す機能ブロック図である。
【００８７】
同図は、図１７に示す機能ブロック図における機能をより詳しく説明する。同図において、取得した候補の文字長および入力されたかな文字列における先頭かな文字の種別とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得する機能と、かな文字列における先頭かな文字の種別に基づいて表示割合情報を表示割合情報ＤＢ１６から取得する機能と、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正する機能とで構成されている。
【００８８】
図２４は、図２２に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００８９】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２４０１）、入力されたかな文字列における先頭かな文字の種別を取得し（ＳＴ２４０２）、各処理が出力する候補の文字長を取得し（ＳＴ２４０３）、取得した先頭かな文字の種別および取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定し（ＳＴ２４０４）、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２４０５）、取得した候補群を表示領域に表示して（ＳＴ２４０６）、処理を終了する。
【００９０】
図２５は、図２３に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【００９１】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２５０１）、あらかじめ定める数の候補についてその文字長を各処理部からそれぞれ取得し（ＳＴ２５０２）、情報入力部１から入力されたかな文字列における先頭かな文字の種別に基づいて表示割合情報ＤＢ１６から表示割合情報を取得し（ＳＴ２５０３）、取得した候補の文字長が確定した表示領域に取得した表示割合情報が定める情報割合で収まるか否かを判定し（ＳＴ２５０４）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数の割合を修正し（ＳＴ２５０５）、収まった場合にはそのまま、決定した候補の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得し（ＳＴ２５０６）、取得した候補群を表示領域に表示して（ＳＴ２５０７）、処理を終了する。
【００９２】
図２６は、図２２に示す機能ブロック図における先頭かな文字の種別に応じて表示割合を変更した場合の具体例を示す図である。
【００９３】
同図において、かな文字列における先頭かな文字が「き」１文字の場合は、９つの候補が表示できる表示領域に第１の候補群には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、前方一致検索候補を３候補、全候補を６候補を表示している。第２の候補群に続く第３の候補群には、９候補すべてを全候補で表示している。対して、先頭かな文字が「か」１文字の場合は、第１の候補群には、前方一致検索候補を６候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、前方一致検索候補を４候補、全候補を５候補を表示している。第２の候補群に続く第３の候補群には、前方一致検索候補を２候補、全候補を７候補を表示している。図示されていないが、第３の候補群に続く第４の候補群には、９候補すべてを全候補で表示している。
【００９４】
（第４実施形態）
図２７〜図３０を用いて、本発明における第４実施形態を説明する。第４実施形態の特徴は、入力確定した候補を入力履歴候補として記憶する入力履歴候補データベースから直近の入力履歴候補を取得して、前方一致検索候補とかな漢字変換候補とともに表示画面の表示領域に表示することである。直近の入力履歴候補は、同じ言葉を繰り返し使って文章作成する利用者２にとって利便性の高いものである。入力履歴候補は、前方一致検索候補やかな漢字変換候補と重複することもあるので、もちろんその場合には重複して候補を表示するのではなくどちらかの候補としてしまうとよい。
【００９５】
図２７は、入力履歴候補を記憶する学習辞書について機能ブロック図を用いて説明する図である。
【００９６】
同図において、言語入力システムは、表示領域に表示した候補の選択を情報入力部１から受け付ける機能と、受け付けた候補の選択によって文字を確定する機能とを有し、確定された文字はその後の処理の実行に用いられる。ここで言うところのその後の処理とは、例えば携帯端末９の利用目的そのものであると考えてよい。一方で言語入力システムは、表示領域に表示した候補の選択を情報入力部１から受け付ける機能から得られた選択結果を入力履歴情報として学習辞書ＤＢ１７に記憶する機能を有し、学習辞書ＤＢ１７に記憶された入力履歴情報に基づいて前方一致検索用辞書ＤＢ３やかな漢字変換用辞書ＤＢ５の利用頻度に関する評価値を更新する。
【００９７】
図２８は、本発明の実施形態における言語入力システムの機能ブロック図である。
【００９８】
同図は、第１実施形態における図１０に示す機能ブロック図に対応する。同図において、取得した候補の文字長とそれぞれの候補を表示する表示領域に基づいて表示する候補数の割合を決定する機能は、候補を出力するために使用可能な表示領域を確定する機能と、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報の文字長を取得する機能と、取得した候補と入力履歴情報の文字長が確定した表示領域にあらかじめ定める割合で収まるか判定する機能と、判定の結果、表示領域に収まりきらなかった場合には表示領域に合わせて候補数および入力履歴数の割合を修正する機能とで構成されている。
【００９９】
図２９は、図２８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャートである。
【０１００】
同図において、言語入力システムは、前方一致検索処理部４とかな漢字変換処理部１８がそれぞれ候補を出力すると（ＳＴ２９０１）、あらかじめ定める数の候補についてその文字長を前方一致検索処理部４とかな漢字変換処理部１８からそれぞれ取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報の文字長を取得し（ＳＴ２９０２）、各取得した候補と入力履歴情報の文字長が確定した表示領域にあらかじめ定める割合で収まるか否かを判定し（ＳＴ２９０３）、表示領域に収まりきらなかった場合には表示領域に合わせて候補数および入力履歴数の割合を修正し（ＳＴ２９０４）、収まった場合にはそのまま、決定した候補および入力履歴の割合に基づいて候補を前方一致検索処理部４とかな漢字変換処理部１８から取得するとともに学習辞書ＤＢ１７から直近の入力履歴情報を入力履歴候補としてそれぞれ取得し（ＳＴ２９０５）、取得した候補群を表示領域に表示して（ＳＴ２９０６）、処理を終了する。
【０１０１】
図３０は、図２８に示す機能ブロック図における入力履歴を候補とする場合に具体例を示す図である。
【０１０２】
同図において、第１の候補群には、入力履歴候補を３候補、前方一致検索候補を３候補、連文節変換候補を１候補、全候補を２候補を表示している。第１の候補群に続く第２の候補群には、入力履歴候補を２候補、前方一致検索候補を２候補、全候補を５候補を表示している。第２の候補群に続く第３の候補群には、入力履歴候補を１候補、前方一致検索候補を１候補、全候補を７候補を表示している。図示されていないが、第３の候補群に続く第４の候補群には、９候補すべてを全候補で表示している。入力履歴候補は、前方一致検索候補（およびかな漢字変換候補）よりも優先的に表示されるとよい。このように、入力履歴は同じ言葉を繰り返し使って文章作成する場合に利用頻度が高くなり、文章作成ではよくあることなので、表示割合情報ＤＢ１６から取得される各候補の表示割合情報に以下の配慮（表示割合ルールの取り決め）を追加する。
（６）前方一致検索候補とかな漢字変換候補（連文節変換候補と全候補）に入力履歴候補加えた表示割合とすること。
（７）入力履歴候補が表示領域に表示される場合には、前方一致検索候補（およびかな漢字変換候補）よりも優先的に表示すること。
【０１０３】
（第５実施形態）
図３１〜図３３を用いて、本発明における第５実施形態を説明する。第５実施形態の特徴は、携帯端末９の情報出力部７における表示領域の画面偏移についてスクロール配列やセンタ配列にするなど候補群の配置に配慮したことである。
【０１０４】
図３１は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１０５】
同図において、各候補群はいわゆるスクロール配置で配置されており、第１の候補群から第２の候補群に切り替えた同じ方向に第３の候補群を配置している。順送りで候補群を表示しているので、第４の候補群、第５の候補群と切替操作を継続するような用途に適している。
【０１０６】
図３２は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１０７】
同図において、各候補群はいわゆるセンタ配置で配置されており、第１の候補群から第２の候補群に切り替えた逆の方向に第３の候補群を配置している。第１の候補群を第２の候補群と第３の候補群の中央に配置しているので、第３の候補群までで効率よく候補を探したいとする用途に適している。
【０１０８】
また、センタ配置に関する例として、全候補取得処理部８から出力される全候補について自立語の種類（例えば名詞、単漢字など）によって分けることも出来る。例えば、センタとなる第１の候補群には前方一致検索候補＋かな漢字変換候補＋（単漢字を除く）全候補を表示し、第２の候補群には前方一致候補＋（単漢字を除く）全候補を表示する。そして、第２の候補群とは逆の方向に表示する第３の候補群には単漢字の全候補を表示し、第３の候補群と同じ側はすべて単漢字の全候補を表示し続ける。よって、第１の候補群を中央とする片側にすべての単漢字が表示されるように、全候補の中でも特定の種類を持つ候補を表示することで効率よく候補を探すことが出来る。なお、第１の候補群を中央とするどちらかの方向に特徴的な全候補を揃える例はこれに限らず、言語入力システムの目的や利用者２の都合に合わせて変更できるようにしておいてもよい。
【０１０９】
図３３は、本発明の実施形態における候補群の配置の具体例を示す図である。
【０１１０】
同図において、図３２に示すセンタ配置の応用であり、入力履歴候補を片側に集めた場合である。前方一致検索候補やかな漢字変換候補ではなく、直近の入力履歴でよいとわかっている場合には便利な配置となる。
【０１１１】
【発明の効果】
以上記載の本発明によれば、少ない文字数で所望の文字が得られる前方一致検索処理は利用者にとって魅力的な機能ではあるが、仮に１文字のかな文字が入力された場合であってもかな漢字変換処理が求められることがあり得るので、最初の候補群に前方一致検索候補とかな漢字変換候補とを少なくとも１つ以上は表示することにより、前方一致検索処理を所望する利用者にとっても単なるかな漢字変換を所望する利用者にとっても使い勝手のよい言語入力システムとすることが出来る。
【０１１２】
また、前方一致検索候補は、入力かな文字数を増やしていくと自動的に絞り込まれるので、最初の候補群には前方一致検索候補重視の表示割合として次の候補群に切り替わるに従って段階的にその割合を減らすことによって、簡単かつ効率のよい入力操作とすることが出来る。つまり、なるべく少ない入力かな文字数で利用者が所望する言葉を入力することが出来る。
【０１１３】
さらに、前方一致検索候補だけに頼ると「ありそうでない候補」は出力されないことが多いが、前方一致検索候補とかな漢字変換候補がその表示割合を変えながら、候補の追加（表示領域の切替）に対しても、入力されるかな文字の追加に対しても連続的につながっているので利用者が望む候補に一本化された操作で必ず辿り着けるという効果が期待できる。ここで言うところの一本化された操作とは、変換ボタンや切替ボタンの操作が不要であることを意味し、変換操作や切替操作が不要であるにも関わらず、利用者は追加の候補を表示する指示とかな文字列の追加による一連の動作のみで所望の言葉を入力できることになる。
【図面の簡単な説明】
【図１】 携帯電話に代表される、いわゆる１０キーデバイスでの日本語入力システムにおける入力方法を説明する図
【図２】 前方一致検索処理について説明する図
【図３】 かな文字が追加入力された場合の前方一致検索処理について説明する図
【図４】 かな漢字変換処理に用いるかな漢字変換辞書について説明する図
【図５】 かな漢字変換処理における連文節変換候補取得処理について説明する図
【図６】 かな漢字変換処理における全候補取得処理について説明する図
【図７】 本発明の実施形態における言語入力システムを備える携帯端末のハードブロック図
【図８】 本発明の実施形態における言語入力システムの機能ブロック図
【図９】 本発明の実施形態における言語入力システムの機能ブロック図
【図１０】 図９に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図１１】 図８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１２】 図９に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１３】 図１０に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図１４】 図１３のフローチャートに示す表示割合の修正をした場合の具体例を示す図
【図１５】 入力されたかな文字数と前方一致検索用辞書の平均候補数の関係を示す図
【図１６】 本発明の実施形態における言語入力システムの機能ブロック図
【図１７】 本発明の実施形態における言語入力システムの機能ブロック図
【図１８】 図１７に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図１９】 図１７に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２０】 図１８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２１】 入力されたかな文字列における先頭かな文字と前方一致検索用辞書の候補数の関係を示す図
【図２２】 本発明の実施形態における言語入力システムの機能ブロック図
【図２３】 図２２に示す機能ブロック図の機能をより詳細に示す機能ブロック図
【図２４】 図２２に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２５】 図２３に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図２６】 図２２に示す機能ブロック図における先頭かな文字の種別に応じて表示割合を変更した場合の具体例を示す図
【図２７】 入力履歴候補を記憶する学習辞書について機能ブロック図を用いて説明する図
【図２８】 本発明の実施形態における言語入力システムの機能ブロック図
【図２９】 図２８に示す機能ブロック図に対応する言語入力システムの演算部におけるフローチャート
【図３０】 図２８に示す機能ブロック図における入力履歴を候補とする場合に具体例を示す図
【図３１】 本発明の実施形態における候補群の配置の具体例を示す図
【図３２】 本発明の実施形態における候補群の配置の具体例を示す図
【図３３】 本発明の実施形態における候補群の配置の具体例を示す図
【符号の説明】
１ 情報入力部
２ 利用者
３ 前方一致検索用辞書ＤＢ
４ 前方一致検索処理部
５ かな漢字変換用辞書ＤＢ
６ 連文節変換候補取得処理部
７ 情報出力部
８ 全候補取得処理部
９ 携帯端末
１３ ネットワーク
１６ 表示割合情報ＤＢ
１７ 学習辞書ＤＢ
１８ かな漢字変換処理部
Claims (1)
- 情報入力部から入力された入力かな文字列に対して前方一致検索処理とかな漢字変換処理を実行する言語入力システムにおいて、
入力された入力かな文字列を取得するかな文字列取得手段と、
前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、前方一致検索処理を実行し、実行結果である前方一致検索候補を出力する前方一致検索処理手段と、前記かな文字列取得手段によって取得された前記入力かな文字列に基づいて、かな漢字変換処理を実行し、実行結果であるかな漢字変換候補を出力するかな漢字変換処理手段と、前記前方一致検索処理手段から出力された前記前方一致検索候補の文字長と前記かな漢字変換処理手段から出力された前記かな漢字変換候補の文字長をそれぞれ取得する候補文字長取得手段と、
前記候補文字長取得手段が取得した候補の文字長に基づき、それらの候補を表示する表示領域に、前記前方一致検索候補と前記かな漢字変換候補があらかじめ定める前記前方一致検索候補の候補数と前記かな漢字変換候補の候補数の割合で収まるか判定する手段と、
前記表示領域に収まりきらなかった場合には、前記表示領域に合わせて、表示する前記前方一致検索候補の候補数と前記かな漢字変換候補の候補数の前記割合を修正する表示割合決定手段と、
前記表示割合決定手段が決定した候補数の割合に基づいて、前記前方一致検索処理手段から前記前方一致検索候補を、前記かな漢字変換処理手段から前記かな漢字変換候補をそれぞれ取得する候補取得手段と、
前記候補取得手段が取得した前記前方一致検索候補と前記かな漢字変換候補を前記表示領域に合わせて配置する候補配置手段と、
前記候補配置手段が前記表示領域に合わせて配置した候補群を配置結果として前記表示領域に表示する表示手段と、
前記表示領域に表示した候補に対して選択入力を受け付けると、選択入力を受け付けた候補を入力確定する入力確定手段と、を有し、
前記表示領域に表示しきれなかった次の候補群への表示切替を要求する要求信号を受け付けると、前記判定する手段は、あらかじめ定める前記前方一致検索候補の候補数と前記かな漢字変換候補の候補数の割合であって、前記前方一致検索候補の候補数の割合を減らしたものを取得し、前記判定を行うことを特徴とする言語入力システム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002378899A JP3975914B2 (ja) | 2002-12-27 | 2002-12-27 | 言語入力システム |
| CNB2003101102786A CN100342373C (zh) | 2002-12-27 | 2003-12-29 | 语言输入方法及系统 |
| HK04110123A HK1066994A1 (en) | 2002-12-27 | 2004-12-21 | Language input method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002378899A JP3975914B2 (ja) | 2002-12-27 | 2002-12-27 | 言語入力システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004213120A JP2004213120A (ja) | 2004-07-29 |
| JP3975914B2 true JP3975914B2 (ja) | 2007-09-12 |
Family
ID=32815577
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002378899A Expired - Lifetime JP3975914B2 (ja) | 2002-12-27 | 2002-12-27 | 言語入力システム |
Country Status (3)
| Country | Link |
|---|---|
| JP (1) | JP3975914B2 (ja) |
| CN (1) | CN100342373C (ja) |
| HK (1) | HK1066994A1 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4597632B2 (ja) * | 2004-10-28 | 2010-12-15 | ジーイー・メディカル・システムズ・グローバル・テクノロジー・カンパニー・エルエルシー | 断層画像撮影装置 |
| JP5045446B2 (ja) * | 2008-01-10 | 2012-10-10 | 日本電気株式会社 | 文字入力装置および文字入力支援方法並びにプログラム |
| JP5454783B2 (ja) * | 2009-03-13 | 2014-03-26 | オムロン株式会社 | Ｐｌｃのプログラミングにおける変数名の入力支援方法、ｐｌｃのプログラミングにおける変数名の入力支援装置、及びコンピュータプログラム |
| JP2015172858A (ja) * | 2014-03-12 | 2015-10-01 | オムロン株式会社 | 情報処理装置および文字入力用のプログラムならびに入力文字列の変換候補の表示方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11161640A (ja) * | 1997-11-27 | 1999-06-18 | Toshiba Corp | 中国語入力変換処理装置、中国語入力変換処理方法、中国語入力変換処理プログラムを記録した記録媒体 |
| WO2000043861A1 (en) * | 1998-02-13 | 2000-07-27 | Zi Corporation Of Canada, Inc. | Method and apparatus for chinese character text input |
| JP2001229155A (ja) * | 2000-02-14 | 2001-08-24 | Toshiba Corp | 中国語入力変換処理装置、中国語入力変換処理方法及び記録媒体 |
| CN1330480A (zh) * | 2000-06-27 | 2002-01-09 | 索尼公司 | 字符输入方法及字符输入装置 |
| JP2002014954A (ja) * | 2000-06-28 | 2002-01-18 | Toshiba Corp | 中国語入力変換処理装置、中国語入力変換処理方法及び記録媒体 |
-
2002
- 2002-12-27 JP JP2002378899A patent/JP3975914B2/ja not_active Expired - Lifetime
-
2003
- 2003-12-29 CN CNB2003101102786A patent/CN100342373C/zh not_active Expired - Lifetime
-
2004
- 2004-12-21 HK HK04110123A patent/HK1066994A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| HK1066994A1 (en) | 2005-03-18 |
| CN100342373C (zh) | 2007-10-10 |
| CN1512303A (zh) | 2004-07-14 |
| JP2004213120A (ja) | 2004-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7277732B2 (en) | Language input system for mobile devices | |
| KR100891358B1 (ko) | 사용자의 다음 문자열 입력을 예측하는 글자 입력 시스템및 그 글자 입력 방법 | |
| JP5501625B2 (ja) | 不確定なテキスト入力から明確な文字をフィルタリングする装置及び方法 | |
| US8374850B2 (en) | Device incorporating improved text input mechanism | |
| US6636162B1 (en) | Reduced keyboard text input system for the Japanese language | |
| DK1783987T3 (en) | Method and apparatus for loading information | |
| CA2572215C (en) | Nonstandard text entry | |
| US20150269252A1 (en) | Nonstandard locality-based text entry | |
| JP5098304B2 (ja) | 特殊文字入力支援装置及びこれを備える電子機器 | |
| KR100709237B1 (ko) | 단말기의 문자열 처리 방법 | |
| WO2005013054A2 (en) | System and method for disambiguating phonetic input | |
| JP2001509290A (ja) | 減少型キーボード曖昧さ除去システム | |
| JP2003015803A (ja) | 小型キーパッド用日本語入力メカニズム | |
| JP2006323827A (ja) | 音楽フォント出力装置、フォントデータベース及び言語入力フロントエンドプロセッサ | |
| JP3975914B2 (ja) | 言語入力システム | |
| WO2003003184A1 (en) | Arabic-persian alphabet input apparatus | |
| JPH08272789A (ja) | 言語情報変換装置 | |
| WO2006094454A1 (fr) | Traitement de mots ambigus et procede interactif de saisie de langue par lettres sur un pave numerique | |
| JP3492981B2 (ja) | 音声仮名文字の入力順序を生成するための入力システム | |
| KR100373332B1 (ko) | 이동통신 단말기에서 한글문자 입력 방법 | |
| JP2005301699A (ja) | 文章入力装置、方法、及びプログラム、並びに携帯端末装置 | |
| JP2003141107A (ja) | 単語入力による文章作成方法と装置 | |
| KR100373330B1 (ko) | 이동통신 단말기에서 한글문자 입력 방법 | |
| KR100506523B1 (ko) | 듀얼 모드를 이용한 한글 입력 장치 및 방법 | |
| JP2003132053A (ja) | 文字列変換装置、文字列変換方法、および記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041124 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060703 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060808 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061006 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070316 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070316 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070529 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070611 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100629 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3975914 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100629 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110629 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110629 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120629 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130629 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |