JP5258697B2 - 携帯電子機器 - Google Patents

Description

本発明は、音声認識辞書を有する携帯電子機器に関する。

従来、携帯電話機やナビゲーション装置等の電子機器において、音声認識により所定の処理を実行させる機能が搭載されている。例えば、電子機器のユーザは、選択操作をすることなく、音声によりメール機能の呼び出しやアドレス帳からの選択等の指示を行うことができる。

このような電子機器は、音声認識の結果と照合させる認識辞書を備える。しかしながら、認識辞書を変更しなければならない状況も生じうる。特許文献１においては、携帯型の電子機器に対して音声認識サービスを実現する上で用いられる、分散処理型の音声認識サーバにおける認識辞書の更新処理について記載されており、特に複数の音声認識処理部を保有する場合の認識辞書更新の効率の向上を図ることが提案されている。

特開２００８−１５２０９号公報

特許文献１に記載されているように、認識辞書の更新には大きな処理負荷を必要としている。一方で、音声認識処理の機能ブロック自体がコンパクト化され、携帯型の電子機器そのものに搭載されるようになりつつある。当然ながら携帯電子機器は、サーバに比べて処理能力が低いため、認識辞書の更新処理に関してはさらなる高効率化が必要とされる。

本発明は、認識辞書の更新をさらに効率良く行うことができる携帯電子機器を提供することを目的とする。

本発明に係る携帯電子機器は、所定の処理と編集可能な読み仮名とが対応付けられた読み仮名対応データを記憶する読み仮名記憶部と、音声認識の結果と照合する読み仮名の選択肢を含む認識辞書を、前記読み仮名対応データと関連付けて記憶する認識辞書記憶部と、前記音声認識結果と照合された読み仮名に対応する前記所定の処理を実行する実行部と、前記読み仮名対応データと前記認識辞書との読み仮名の差分を示す更新データを記憶する更新データ記憶部と、前記読み仮名対応データが更新された場合に、当該更新の内容を示す更新データを前記更新データ記憶部へ記憶し、所定のタイミングで、前記更新データに基づいて前記認識辞書を更新する更新部と、を備え、前記更新部は、前記認識辞書の更新前に前記読み仮名対応データが複数回更新された場合に、前記所定の処理に対して最後に更新された読み仮名へ前記認識辞書を更新するための差分を、１つの更新データに最適化して記憶することを特徴とする。

また、前記最適化された更新データは、前記認識辞書に対する、変更なし、追加、変更または削除のいずれかを示すデータであることが好ましい。

また、前記読み仮名記憶部は、通信相手と当該通信相手の読み仮名とが対応付けられたアドレス帳を前記読み仮名対応データとして記憶し、前記実行部は、前記所定の処理として、前記照合された読み仮名に対する通信相手を前記アドレス帳から選択することが好ましい。

また、前記更新部は、前記更新データ記憶部に更新データを記憶すると共に、前記認識辞書を更新する必要があることを示すデータを記憶することが好ましい。

また、前記更新部は、前記認識辞書を更新する必要がある件数データを記憶し、前記所定のタイミングにおいて当該件数が所定以上である場合には、前記更新データによらず前記読み仮名対応データに基づいて前記認識辞書を一括して上書き更新することが好ましい。

また、前記更新データ記憶部は、複数のアプリケーションがそれぞれ有する前記読み仮名対応データおよび前記認識辞書に対して、前記更新データの記憶領域を備え、前記更新部は、前記認識辞書が更新されたアプリケーションを判別し、対応する記憶領域に前記更新データを記憶することが好ましい。

また、本発明に係る携帯電子機器は、前記読み仮名対応データと前記認識辞書とを対比し、一致していない読み仮名に対して前記更新データを再生成するリカバリ部をさらに備えることが好ましい。

また、前記リカバリ部は、電源がオンとなったときに、前記読み仮名対応データと前記認識辞書とを対比し、読み仮名の不一致が１件以上あった場合に、前記更新データの再生成が必要であることを示すデータを記憶し、前記所定のタイミングで前記更新データの再生成を行うことが好ましい。

本発明によれば、認識辞書の更新を効率良く行うことができる。

本発明の実施形態に係る携帯電話機の外観斜視図である。 本発明の実施形態に係る携帯電話機の機能を示すブロック図である。 本発明の実施形態に係るアドレス帳データの編集に伴う認識辞書データの更新方法を示す概要図である。 本発明の実施形態に係る更新データの生成処理を示すフローチャートである。 本発明の実施形態に係る更新データの最適化処理を示すフローチャートである。 本発明の実施形態に係る更新データの最適化方法の一例を示す図である。 本発明の実施形態に係る更新データの最適化ルールを示す図である。 本発明の実施形態に係るリカバリ要否判定処理を示すフローチャートである。 本発明の実施形態に係るリカバリ処理を示すフローチャートである。

以下、本発明の好適な実施形態の一例について説明する。なお、本実施形態では、携帯電子機器の一例として、携帯電話機１を説明する。なお、本発明の携帯電子機器はこれには限られず、例えば、ＰＨＳ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ゲーム機、ナビゲーション装置やパーソナルコンピュータ等、様々な携帯電子機器に適用可能である。

図１は、本実施形態に係る携帯電話機１（携帯電子機器）の外観斜視図である。なお、図１は、いわゆる折り畳み型の携帯電話機の形態を示しているが、本発明に係る携帯電話機の形態はこれに限られない。例えば、両筐体を重ね合わせた状態から一方の筐体を一方向にスライドさせるようにしたスライド式や、重ね合せ方向に沿う軸線を中心に一方の筐体を回転させるようにした回転式（ターンタイプ）や、操作部と表示部とが１つの筐体に配置され、連結部を有さない形式（ストレートタイプ）でもよい。

携帯電話機１は、操作部側筐体２と、表示部側筐体３と、を備えて構成される。操作部側筐体２は、表面部１０に、操作部１１と、携帯電話機１の使用者が通話時や音声認識アプリケーションを利用時に発した音声が入力されるマイク１２と、を備えて構成される。操作部１１は、各種設定機能や電話帳機能やメール機能等の各種機能を作動させるための機能設定操作ボタン１３と、電話番号の数字やメールの文字等を入力するための入力操作ボタン１４と、各種操作における決定やスクロール等を行う決定操作ボタン１５と、から構成されている。

また、表示部側筐体３は、表面部２０に、各種情報を表示するための表示部２１と、通話の相手側の音声を出力するレシーバ２２と、を備えて構成されている。

また、操作部側筐体２の上端部と表示部側筐体３の下端部とは、ヒンジ機構４を介して連結されている。また、携帯電話機１は、ヒンジ機構４を介して連結された操作部側筐体２と表示部側筐体３とを相対的に回転することにより、操作部側筐体２と表示部側筐体３とが互いに開いた状態（開放状態）にしたり、操作部側筐体２と表示部側筐体３とを折り畳んだ状態（折畳み状態）にしたりできる。

図２は、本実施形態に係る携帯電話機１の機能を示すブロック図である。携帯電話機１は、操作部１１と、表示部２１と、制御部３０と、音声認識処理部４０と、記憶部５０と、通信部６０と、音声部７０と、を備える。さらに、音声認識処理部４０は、実行部４１と、更新部４２と、リカバリ部４３と、を備える。また、記憶部５０は、読み仮名ＤＢ（データベース）５１と、認識辞書ＤＢ５２と、更新情報ＤＢ５３と、を備える。

制御部３０は、携帯電話機１の全体を制御しており、例えば、表示部２１、通信部６０等に対して所定の制御を行う。また、制御部３０は、操作部１１等から入力を受け付けて、各種処理を実行する。そして、制御部３０は、処理実行の際には、記憶部５０を制御し、各種プログラムおよびデータの読み出し、およびデータの書き込みを行う。

音声認識処理部４０は、制御部３０からの指令に基づいて、実行部４１により音声認識処理の実行と、更新部４２により認識辞書の管理を行う。また、リカバリ部４３は、後述の更新データを再生成して復元する機能を備え、更新データが破損した場合の不都合を回避する。

記憶部５０は、本実施形態に係る各種プログラムを記憶し、また、制御部３０による演算処理に利用される。さらに、記憶部５０は、読み仮名ＤＢ５１により音声認識の関連データである読み仮名対応データ（例えば、アドレス帳データ、データフォルダの読み仮名データ、メールフォルダの読み仮名データ等）を記憶し、認識辞書ＤＢ５２により認識辞書データを記憶し、更新情報ＤＢ５３により読み仮名対応データと認識辞書データとの差分を示す更新データを記憶する。

なお、更新情報ＤＢ５３は、複数のアプリケーションがそれぞれ有する読み仮名対応データおよび認識辞書データに対して、更新データの記憶領域を備える。そして、更新部４２は、読み仮名対応データが更新されたアプリケーションを判別し、対応する記憶領域に更新データを記憶する。これにより、アドレス帳やデータフォルダ等のそれぞれによって異なる音声認識の関連データに対して、独自の管理手法を適用することができる。

ここで、例えば、アドレス帳データの場合、通話やメール等の通信相手を識別するデータ（例えば、電話番号やメールアドレス、名称等）と読み仮名とが対応付けられている。実行部４１は、この読み仮名が入力されることにより、通信相手の選択処理（所定の処理）を実行する。

また、認識辞書データは、音声認識の結果として得られるテキスト情報と照合する読み仮名の選択肢を含むデータである。この読み仮名のそれぞれは、読み仮名対応データと関連付けられており、選択肢の中に音声認識の結果と同一の読み仮名があった場合に、関連付けられている読み仮名対応データ（例えば、アドレス帳データ）が読み出される。

また、更新データは、認識辞書データと読み仮名対応データの読み仮名を一致させるための差分を示すデータであり、読み仮名対応データの読み仮名が変更された場合に更新部４２により生成される。したがって、更新部４２が更新データを認識辞書データに適用することにより、認識辞書データの読み仮名が更新されてアドレス帳等の読み仮名対応データと一致する。

通信部６０は、所定の使用周波数帯（例えば、２ＧＨｚ帯や８００ＭＨｚ帯等）で外部装置（基地局）と通信を行う。通信部６０は、アンテナより受信した信号を復調処理し、処理後の信号を制御部３０に供給する。また、制御部３０から供給された信号を変調処理し、アンテナを介して外部装置に送信する。

音声部７０は、制御部３０の制御に従って、通信部６０から供給された信号に対して所定の音声処理を行い、処理後の信号をレシーバ２２に出力する。レシーバ２２は、音声部７０から供給された信号を外部に出力する。なお、この信号は、レシーバ２２に代えて、または、レシーバ２２と共に、スピーカ（図示せず）から出力されるとしてもよい。また、音声部７０は、制御部３０の制御に従って、マイク１２から入力された信号を処理し、処理後の信号を通信部６０に出力する。通信部６０は、音声部７０から供給された信号に所定の処理を行い、処理後の信号をアンテナから出力する。

図３は、本実施形態に係るアドレス帳データの編集に伴う認識辞書データの更新方法を示す概要図である。

ユーザによりアドレス帳データの読み仮名が追加、削除、変更された場合、この変更を認識辞書データに対しても同様に行う必要がある。第１パターンの場合には、アドレス帳データの更新に応じて即時に認識辞書データを更新する。しかしながら、ユーザにとっては、アドレス帳の更新処理のみの場合に比べて、待ち時間が長くなっていた。

一方、第２パターンの場合には、認識辞書用の更新データを介在させることにより、認識辞書データの更新は、バックグラウンドまたは音声認識処理の起動時に行うことができる。すなわち、アドレス帳データの更新時には、更新データを生成しておき、更新に時間のかかる認識辞書データは、別の所定のタイミングで実行する。その結果、アドレス帳の更新時の待ち時間を低減し、認識辞書の更新をユーザに意識させないようにできる。

ここで、所定のタイミングとは、予め許可されているアプリケーション以外のアプリケーションが実行されていない場合、および所定時間ユーザからの操作入力がなかった場合である。なお、予め許可されているアプリケーションは、例えば、電波状態表示や時刻表示等、常時実行されており処理負荷が比較的小さいアプリケーションとする。例えば、携帯電話機１が省電力モードとなった際に、これらのアプリケーションのバックグラウンドで、認識辞書データの更新が実行される。

認識辞書データの更新には大きな処理負荷とメモリ消費を伴うため、ユーザ操作中やアプリケーションの実行中に更新されるのを抑制することにより、ユーザの操作性やアプリケーションのスムーズな処理を損なうおそれ（例えば、画面表示の遅延や、音声再生の途切れ等）を回避することができる。

以下、更新データの生成方法について説明する。更新部４２は、同一の読み仮名対応データ（例えば、アドレス帳データ）の読み仮名に対して複数回の変更が加えられた場合に、最後に更新された読み仮名へ認識辞書データを更新するための差分を、１つの更新データに最適化して記憶する。

図４は、本実施形態に係る読み仮名対応データが変更された場合の更新データの生成処理を示すフローチャートである。

ステップＳ１では、更新部４２は、アドレス帳やデータフォルダ等に関する読み仮名対応データが変更されたことを示す通知を受信する。

ステップＳ２では、更新部４２は、ステップＳ１で受信した通知に基づいて、変更されたデータの種類を識別する。具体的には、アドレス帳であるのか、データフォルダであるのか、メールフォルダであるのか、等を識別する。

ステップＳ３では、更新部４２は、ステップＳ２で識別されたデータの種類に応じたデータ選定を行う。具体的には、例えば、アドレス帳が変更された場合に、変更された部分が音声認識に関係する読み仮名であるのかどうかを選定する（ステップＳ３ａ）。データフォルダの場合（ステップＳ３ｂ）やメールフォルダの場合（ステップＳ３ｃ）も同様である。

ステップＳ４では、更新部４２は、ステップＳ３のデータ選定により、音声認識処理に関係する読み仮名の変更があったか否かを判定する。更新部４２は、この判定がＹＥＳの場合は処理をステップＳ５に移し、判定がＮＯの場合は認識辞書データの更新が不要であるため処理を終了する。

ステップＳ５では、更新部４２は、読み仮名の変更を更新データとして記憶するが、このとき、複数の更新情報を１つに最適化して記憶する（図５参照）。

図５は、本実施形態に係る更新データの最適化処理を示すフローチャートである。本処理では、対象の読み仮名に対する更新データが既に生成されており、新たな更新情報を元にこの更新データを最適化する。

ステップＳ１１では、更新部４２は、対象の読み仮名に対する更新データを更新情報ＤＢ５３から読み出す。

ステップＳ１２では、更新部４２は、対象の読み仮名およびステップＳ１で読み出した更新データの種類を識別する。具体的には、対象がアドレス帳であるのか、データフォルダであるのか、メールフォルダであるのか、等を識別する。

ステップＳ１３では、更新部４２は、ステップＳ１２で識別されたデータの種類に応じた最適化を行う。具体的には、対象がアドレス帳であればアドレス帳に適した最適化（ステップＳ１３ａ）を行い、対象がデータフォルダの場合（ステップＳ１３ｂ）やメールフォルダの場合（ステップＳ１３ｃ）も同様である。

ステップＳ１４では、ステップＳ１３で最適化された更新データを、更新情報ＤＢ５３へ記憶する。

図６は、本実施形態に係る更新データの最適化方法の一例を示す図である。この例は、アドレス帳データに対する更新データの最適化を示している。

処理前の更新データ８１は、１行目から順に「ＮＯＮＥ」（変更なし）、「ＡＤＤ」（追加）、「ＭＯＤ」（変更）、「ＤＥＬ」（削除）となっている。ここへ、１行目に対する更新情報８２ａ（ＭＯＤ）、２行目に対する更新情報８２ｂ（ＤＥＬ）、３行目に対する更新情報８２ｃ（ＭＯＤ）、４行目に対する更新情報８２ｄ（ＡＤＤ）が入力されると、最適化処理により、処理後の更新データ８３が生成される。

処理後の更新データ８３において、１行目は「ＮＯＮＥ」の状態に対して「ＭＯＤ」の更新があったので、最適化すると元の状態から「ＭＯＤ」の更新があったと表現できる。２行目は、「ＡＤＤ」の状態に対して「ＤＥＬ」の更新があり、結局は元の状態に戻ったので、最適化すると「ＮＯＮＥ」と表現できる。３行目は、「ＭＯＤ」の状態に対して「ＭＯＤ」の更新があったので、最適化すると元の状態から「ＭＯＤ」の更新があったと表現できる。４行目は、「ＤＥＬ」の状態に対して「ＡＤＤ」の更新があったので、最適化すると元の状態からは「ＭＯＤ」の更新があったと表現できる。

図７は、本実施形態に係る更新データの最適化ルールを示す図である。
ここでは、変更前の更新データの種類（ＮＯＮＥ、ＡＤＤ、ＤＥＬまたはＭＯＤ）それぞれに対して、変更通知情報（ＡＤＤ、ＤＥＬまたはＭＯＤ）のそれぞれが入力された場合について、最適化処理後の更新データの種類を示している。

例えば、図６で示した例の他、「ＡＤＤ」の状態に対して「ＭＯＤ」の更新があれば、元の状態に対しては「ＡＤＤ」と最適化できる。また、「ＭＯＤ」の状態に対して「ＤＥＬ」の更新があれば、元の状態に対しては「ＤＥＬ」と最適化できる。

なお、図中の「−」は、変更通知情報として入力されない組合せを示している。例えば、変更前が「ＡＤＤ」や「ＭＯＤ」で既に読み仮名の登録がある場合には、さらに「ＡＤＤ」とはなり得ない。また、変更前が「ＤＥＬ」で読み仮名の登録がない場合には、さらに「ＤＥＬ」や「ＭＯＤ」とはなり得ない。

このように最適化された更新データは、上述のようにバックグラウンドで認識辞書データに反映されるが、更新中の電源断やその他の要因により更新データが破損する可能性がある。この事態に備えるため、携帯電話機１の電源がＯＮとなった際に、リカバリ部４３は、更新データを再生成し、正しく認識辞書データを更新できるように準備する。なお、以下では、アドレス帳に対する更新データについて例示する。

図８は、本実施形態に係る携帯電話機１の電源がＯＮとなった際のリカバリ要否判定処理を示すフローチャートである。

ステップＳ２１では、リカバリ部４３は、アドレス帳データの読み仮名と認識辞書データの読み仮名とを順に１件ずつ抽出して比較する。

ステップＳ２２では、リカバリ部４３は、ステップＳ２１で抽出した読み仮名が一致しているか否かを判定する。リカバリ部４３は、この判定がＹＥＳの場合は処理をステップＳ２３に移し、判定がＮＯの場合は処理をステップＳ２４に移す。

ステップＳ２３では、リカバリ部４３は、アドレス帳データの読み仮名と認識辞書データの読み仮名とを全て比較したか否かを判定する。リカバリ部４３は、この判定がＹＥＳの場合は処理をステップＳ２５に移し、判定がＮＯの場合は処理をステップＳ２１に戻して比較を継続する。

ステップＳ２４では、リカバリ部４３は、ステップＳ２２で読み仮名の不一致を検出したので、リカバリが必要と判断する。そして、リカバリ部４３は、リカバリ要求フラグをＯＮに設定して処理を終了する。

ステップＳ２５では、リカバリ部４３は、読み仮名の不一致を検出しなかったので、リカバリは不要、すなわち更新データは必要ないと判断する。そして、リカバリ部４３は、リカバリ要求フラグをＯＦＦに設定して処理を終了する。なお、このとき認識辞書データの更新処理を要する更新データが存在している場合には、認識辞書データの更新処理が実行されないように、この更新データを初期化する。

図９は、本実施形態に係る更新データを再生成するリカバリ処理を示すフローチャートである。
認識辞書データの更新タイミングとなった際に、リカバリ部４３は、リカバリ要否判定処理（図８）のステップＳ２４またはステップＳ２５で設定されたリカバリ要求フラグを参照する。そして、リカバリ部４３は、このリカバリ要求フラグがＯＮとなっている場合に、アドレス帳データと認識辞書データを比較し、これらの差分により更新データを生成する。

ステップＳ３１では、リカバリ部４３は、アドレス帳データの読み仮名と認識辞書データの読み仮名とを順に１件ずつ抽出して比較する。

ステップＳ３２では、リカバリ部４３は、ステップＳ３１で抽出した読み仮名が一致しているか否かを判定する。リカバリ部４３は、この判定がＹＥＳの場合は処理をステップＳ３４に移し、判定がＮＯの場合は処理をステップＳ３３に移す。

ステップＳ３３では、リカバリ部４３は、ステップＳ３２で不一致と判定された読み仮名について、認識辞書データの読み仮名をアドレス帳データの読み仮名へ更新するための更新データを再生成する。

ステップＳ３４では、リカバリ部４３は、アドレス帳データの読み仮名と認識辞書データの読み仮名とを全て比較したか否かを判定する。リカバリ部４３は、この判定がＹＥＳの場合は処理をステップＳ３５に移し、判定がＮＯの場合は処理をステップＳ３１に戻して比較を継続する。

ステップＳ３５では、更新部４２は、再生成された更新データを用いて、認識辞書データを更新する。

このように、携帯電話機１の電源ＯＮ時には、リカバリ要求フラグのみを設定し、リカバリ処理は、認識辞書データの更新タイミングで行うことにより、携帯電話機１の起動までにかかる時間の増加を抑制することができる。

以上のように、本実施形態によれば、最適化された更新データを用いることにより、認識辞書データの更新に係る読み仮名の変更履歴データを効率的に記憶できる。したがって、携帯電話機１のメモリ使用量を低減し、さらに認識辞書データの更新に係る処理負荷および時間を低減することができる。その結果、消費電力の低減も期待できる。

なお、本実施形態において、更新部４２は、更新情報ＤＢ５３に更新データを記憶すると共に、認識辞書データを更新する必要があることを示すデータ（フラグ）を記憶することとしてよい。このことにより、更新部４２は、更新データ全体を確認することなく、このフラグを参照することにより、効率的に認識辞書データの更新の要否を判定できる。

また、更新部４２は、認識辞書データを更新する必要がある件数データを記憶することとしてもよい。この場合、更新部４２は、認識辞書データの更新タイミングにおいて、この記憶されている件数が所定以上（例えば、全１０００件中２４０件以上）である場合には、更新データによらず読み仮名対応データ（例えば、アドレス帳データ）に基づいて認識辞書データを一括して上書き更新する。

更新件数が増加すると、１件ずつ更新データに基づいて処理するよりも、一括して上書き更新した方が処理時間の短縮を期待できる。したがって、この方法により、更新部４２は、効率的に認識辞書データを更新できる可能性がある。

また、本実施形態においてはアドレス帳への更新が発生した場合を例に説明を行った。しかしながらアドレス帳以外でも、例えばナビゲーション用の目的地辞書、アプリケーションの実行指示用の読み仮名辞書、データフォルダやメールフォルダの呼び出し指示用の読み仮名辞書等、ユーザによって自由に内容変更可能なユーザ辞書であれば、本発明は適用可能である。

本発明によれば、認識辞書がアドレス帳等のユーザ辞書とは別に構成されている場合において、特に有用である。具体的には、音声認識処理に関する機能の処理プログラムがユニット化されたケースも想定され、このケースにおいて、音声認識処理機能部が参照し易い形に認識辞書が構成され、この認識辞書が音声認識処理のユニット内に共にパッケージ化されて収められている場合が考えられる。この場合、ユーザ辞書とは別系統の管理下に認識辞書が置かれることになる。このように、音声認識処理がユニット化されていた場合には、ユーザ辞書が更新される都度、認識辞書にアクセスするために音声認識処理ユニットを起動しなければならなくなるが、本発明によれば音声認識処理ユニットの起動回数を必要最小限に済ませることができる。また、更新部分が多い場合には音声認識処理ユニットを起動している時間が長くなるが、本発明によれば更新部分を最小限に抑えることが出来るため、音声認識処理ユニットを起動している時間を短くすることができる。すなわち総合的に見て、携帯電子機器における省電力化にも繋がる。さらに、音声認識処理ユニット側への改変を必要としないため、このようなユニットを他の音声認識処理ユニットに置き換えることも容易にすることができ、携帯電子機器の開発上の自由度を向上させることにも繋がる。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。

１ 携帯電話機
１１ 操作部
２１ 表示部
３０ 制御部
４０ 音声認識処理部
４１ 実行部
４２ 更新部
４３ リカバリ部
５０ 記憶部
５１ 読み仮名ＤＢ（読み仮名記憶部）
５２ 認識辞書ＤＢ（認識辞書記憶部）
５３ 更新情報ＤＢ（更新データ記憶部）
６０ 通信部
７０ 音声部

Claims (8)

1. 所定の処理と編集可能な読み仮名とが対応付けられた読み仮名対応データを記憶する読み仮名記憶部と、
   音声認識の結果と照合する読み仮名の選択肢を含む認識辞書を、前記読み仮名対応データと関連付けて記憶する認識辞書記憶部と、
   前記音声認識結果と照合された読み仮名に対応する前記所定の処理を実行する実行部と、
   前記読み仮名対応データと前記認識辞書との読み仮名の差分を示す更新データを記憶する更新データ記憶部と、
   前記読み仮名対応データが更新された場合に、当該更新の内容を示す更新データを前記更新データ記憶部へ記憶し、所定のタイミングで、前記更新データに基づいて前記認識辞書を更新する更新部と、を備え、
   前記更新部は、前記認識辞書の更新前に前記読み仮名対応データが複数回更新された場合に、前記所定の処理に対して最後に更新された読み仮名へ前記認識辞書を更新するための差分を、１つの更新データに最適化して記憶することを特徴とする携帯電子機器。
2. 前記最適化された更新データは、前記認識辞書に対する、変更なし、追加、変更または削除のいずれかを示すデータであることを特徴とする請求項１に記載の携帯電子機器。
3. 前記読み仮名記憶部は、通信相手と当該通信相手の読み仮名とが対応付けられたアドレス帳を前記読み仮名対応データとして記憶し、
   前記実行部は、前記所定の処理として、前記照合された読み仮名に対する通信相手を前記アドレス帳から選択することを特徴とする請求項１または請求項２に記載の携帯電子機器。
4. 前記更新部は、前記更新データ記憶部に更新データを記憶すると共に、前記認識辞書を更新する必要があることを示すデータを記憶することを特徴とする請求項１から請求項３のいずれか１項に記載の携帯電子機器。
5. 前記更新部は、前記認識辞書を更新する必要がある件数データを記憶し、前記所定のタイミングにおいて当該件数が所定以上である場合には、前記更新データによらず前記読み仮名対応データに基づいて前記認識辞書を一括して上書き更新することを特徴とする請求項４に記載の携帯電子機器。
6. 前記更新データ記憶部は、複数のアプリケーションがそれぞれ有する前記読み仮名対応データおよび前記認識辞書に対して、前記更新データの記憶領域を備え、
   前記更新部は、前記認識辞書が更新されたアプリケーションを判別し、対応する記憶領域に前記更新データを記憶することを特徴とする請求項１から請求項５のいずれか１項に記載の携帯電子機器。
7. 前記読み仮名対応データと前記認識辞書とを対比し、一致していない読み仮名に対して前記更新データを再生成するリカバリ部をさらに備える請求項１から請求項６のいずれか１項に記載の携帯電子機器。
8. 前記リカバリ部は、電源がオンとなったときに、前記読み仮名対応データと前記認識辞書とを対比し、読み仮名の不一致が１件以上あった場合に、前記更新データの再生成が必要であることを示すデータを記憶し、前記所定のタイミングで前記更新データの再生成を行うことを特徴とする請求項７に記載の携帯電子機器。

Images