JP2016122467A - 情報処理装置 - Google Patents

Abstract

【課題】入力部に入力される音声を発した人に関する情報を表示部に表示することで、ユーザをアシストすることが可能で、ユーザにとって使い勝手の良い情報処理装置を実現する。【解決手段】本明細書に記載の情報処理装置は、情報を表示する表示部と、音声を入力する入力部と、前記音声の声紋を解析する解析部の解析結果に応じて前記音声に関連する情報を前記表示部に表示させる制御部と、を有することを特徴とする情報処理装置である。【選択図】図１

Description

本発明は、情報処理装置に関する。

従来より、ユーザをアシストする携帯情報端末が提案されている。例えば、特許文献１には、使用者が携帯電話を介して第１サーバに音声メッセージを録音し、この録音されたメッセージを複数に分割し、分割後の各メッセージを複数の社外秘書がテキスト化した後、第２サーバに記憶することで、使用者のスケジュール管理を行う技術が提案されている。

また、特許文献２には、携帯型情報端末に音声入力手段と、通信手段とを設け、音声入力手段から入力された音声を通信手段により音声認識サーバに送信し、音声認識サーバで音声から生成された文字情報を携帯型情報端末で受信する技術が提案されている。

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

しかしながら、従来の携帯情報端末は、セキュリィティへの配慮が乏しかったり、操作が複雑であったりして、必ずしも使い勝手の良いものとはいえなかった。

そこで本発明は上記の課題に鑑みてなされたものであり、使い勝手の良い情報処理装置を提供することを目的とする。

本発明の情報処理装置は、情報を表示する表示部（１４）と、音声を入力する入力部（４２）と、前記音声の声紋を解析する解析部（５５）の解析結果に応じて前記音声に関連する情報を前記表示部に表示させる制御部（７０，３０）と、を有している。

なお、本発明をわかりやすく説明するために、上記においては一実施形態を表す図面の符号に対応つけて説明したが、本発明は、これに限定されるものではなく、後述の実施形態の構成を適宜改良しても良く、また、少なくとも一部を他の構成物に代替させても良い。更に、その配置について特に限定のない構成要件は、実施形態で開示した配置に限らず、その機能を達成できる位置に配置することができる。

本発明は、使い勝手の良い情報処理装置を提供することができるという効果を奏する。

一実施形態に係るパーソナルアシスタントシステム１００の機能ブロック図である。 図２（ａ）〜図２（ｄ）は、音声入力部から入力される音声の録音処理を示すフローチャートである。 声紋ＤＢを示す図である。 音声データの処理に関するフローチャートである。 記憶データＤＢを示す図である。 図４のステップＳ７６の具体的処理を示すフローチャートである。 キーワードＤＢを示す図である。 図４のステップＳ８４の具体的処理を示すフローチャートである。 図８のステップＳ１２２の具体的処理を示すフローチャートである。 図９のステップＳ１４２，Ｓ１４８の具体的処理を示すフローチャートである。 特定変換ワードＤＢを示す図である。 図１０のステップＳ１６４，Ｓ１６６，Ｓ１７８，Ｓ１８０の具体的処理を示すフローチャートである。 地名ＤＢを示す図である。 キーワード格納ＤＢを示す図である。 図１５（ａ）〜図１５（ｄ）は、重みテーブルの例を示す図である。 キーワード記録ＤＢを示す図である。 コマンドＤＢを示す図である。 図１８（ａ）は、タスクリストの表示例を示す図であり、図１８（ｂ）は、録音音声リストの表示例を示す図である。 ステップＳ９６において同時並行的に行われる処理（その１）を示すフローチャートである。 ステップＳ９６において同時並行的に行われる処理（その２）を示すフローチャートである。 ステップＳ９６において同時並行的に行われる処理（その３）を示すフローチャートである。 セキュリティ確保可能範囲ＤＢを示す図である。 曖昧ワードＤＢを示す図である。 携帯型端末側でのデータの消去処理を示すフローチャートである。 サーバ側での音声データの消去処理を示すフローチャートである。

以下、パーソナルアシスタントシステム１００の一実施形態について、図１〜図２５に基づいて詳細に説明する。図１には、パーソナルアシスタントシステム１００のブロック図が示されている。この図１に示すように、パーソナルアシスタントシステム１００は、携帯型端末１０と、サーバ５０と、を備えている。

携帯型端末１０は、ユーザが携帯可能な端末であり、例えば、携帯電話、スマートフォン、ＰＨＳ（Personal Handy-phone System）、ＰＤＡ（Personal Digital Assistant）などの端末である。この携帯型端末１０の大きさは、例えば胸ポケットに入る程度とされている。携帯型端末１０は、図１に示すように、入力部１２と、表示部１４と、再生部１６と、警告部１８と、生体情報入力部２０と、位置検出部２２と、時刻検出部２４と、カレンダ部２６と、フラッシュメモリ２８と、通信部３２と、端末側制御部３０と、を有する。また、携帯型端末１０は、これら各部の少なくとも一部を格納する、携帯可能な携帯端末筐体を有している。

入力部１２は、音声入力部４２と、テキストデータ入力部４４とを有する。音声入力部４２は、マイクロフォンを含み、ユーザの音声や、ユーザの周辺で発せられる音声を取得する。テキストデータ入力部４４は、キーボードやタッチパネルなどの入力インタフェースを含み、ユーザの入力操作に応じたテキストデータを取得する。なお、入力部１２は、タッチパネルなどからのユーザの操作指示を受け付ける機能も有している。

表示部１４は、液晶ディスプレイや有機ＥＬディスプレイなどのディスプレイを含んでいる。表示部１４は、ディスプレイに対して画像データや文字データなどのデータを表示したり、ユーザが操作を行うためのメニュー表示をしたりする。

再生部１６は、スピーカを含み、音声や音を出力する。警告部１８は、携帯型端末１０においてエラーが発生したときなどにおいて、ユーザに対して警告を行うものであり、例えば、再生部１６を介した警告音の出力や、表示部１４を介した警告表示などを行う。

生体情報入力部２０は、例えば、ユーザの筋肉の状態（緊張度及び弛緩度）、あるいは血圧、心拍数、脈拍、体温などの生体情報の少なくとも１つを取得して、端末側制御部３０に対して入力する装置である。なお、生体情報を検出する方法としては、例えば、特開２００５-２７０５４３号公報に記載されているような腕時計型を採用することができる。なお、血圧や脈拍は赤外線を用いた脈波検出センサにより検出すればよく、心拍数は振動センサにより検出すればよい。心拍数が通常よりも上昇したときが緊張状態であり、減少したときが弛緩状態である。また、緊張状態では瞳孔が拡大し、弛緩状態では瞳孔が縮小するので、瞳孔を検出して、緊張状態か弛緩状態かを判別するような構成を適用してもよい。

位置検出部２２は、ユーザの位置（絶対位置）を検出するものであり、ここでは、例えばＧＰＳ（Global Positioning System：全地球測位システム）が採用されている。なお、位置検出部２２としては、ＲＦＩＤ（Radio Frequency IDentification）などを用いた絶対位置計測システムを採用することとしても良い。

時刻検出部２４は、現在の時刻を検出する計時機能を有している。カレンダ部２６は、日付と曜日などとを対応付けて記憶している。フラッシュメモリ２８は、データを一時記憶するメモリである。通信部３２は、ＷｉＦｉ通信でアクセスポイントへアクセスするための無線ＬＡＮユニットや、イーサネット（登録商標）ケーブルによる有線接続のユニット、あるいは、コンピュータ等の外部機器と通信を行うＵＳＢ接続のユニットを有している。本実施形態では、通信部３２は、サーバ５０の通信部５２と通信を行うことが可能である。

端末側制御部３０は、携帯型端末１０の構成各部を統括的に制御し、携帯型端末１０側の処理を実行するものである。例えば、端末側制御部３０は、音声データが音声入力部４２に入力されたときの時刻を時刻検出部２４を介して取得するとともに、音声データが入力されたときの携帯型端末１０の位置を位置検出部２２を介して取得する。そして、端末側制御部３０は、サーバ５０側に音声データを送信する際に、音声データとともに時刻及び位置の情報も送信する。

サーバ５０は、例えば、携帯型端末１０を使用するユーザが勤務する会社内に設置されるものである。ただし、これに限らず、サーバ５０は、システム管理会社に設置することとしても良い。このサーバ５０は、図１に示すように、通信部５２と、テキストデータ生成部５４と、声紋分析部５５と、重み付け部５６と、抽出部５８と、分類部６０と、変換部６２と、フラッシュメモリ６４と、ハードディスク６６と、サーバ側制御部７０と、を有する。

通信部５２は、携帯型端末１０側の通信部３２と同様であり、本実施形態では、携帯型端末１０側の通信部３２との通信を行うことが可能である。通信部５２が受信したデータ（音声データやテキストデータ）は、サーバ側制御部７０を介して、フラッシュメモリ６４に格納される。すなわち、通信部５２は、サーバ５０において、音声入力部やテキストデータ入力部として機能している。

テキストデータ生成部５４は、フラッシュメモリ６４に格納された音声データを取得し、当該音声データを変換してテキストデータを生成するものである。生成されたテキストデータは、サーバ側制御部７０を介して、フラッシュメモリ６４に格納される。

声紋分析部５５は、音声の大きさ（強さ）、周波数、長さを用いて、登録済みの声紋データとのパターンマッチングすることで声紋分析を行い、音声を発した人物を特定するものである。なお、声紋分析では、音声の大きさ（強さ）、周波数、長さの全てを用いなくても良く、少なくとも音声の周波数を用いることで、音声を発した人物を特定することとしても良い。

重み付け部５６は、フラッシュメモリ６４に格納されている音声データ及び音声データから生成されたテキストデータ、又はテキストデータ入力部４４から入力されたテキストデータを取得し、各テキストデータの重み付けを行う。重み付け部５６は、重み付けにより得られた数値（タスク優先度）をテキストデータとともに、フラッシュメモリ６４に格納する。

重み付け部５６による重み付けは、例えば、音声の大きさや周波数、テキストデータの意味に基づいて行われる。具体的には、重み付け部５６は、音声の大きさや周波数に基づいて声紋分析部５５で分析された結果（音声を発した人物が誰かという情報）から重み付けをしたり、テキストデータの意味から守秘性に応じた重み付けを行ったりする。なお、本実施形態において守秘性とは、他人（不特定の第三者）に見られないほうが好ましい度合いを意味する。

重み付け部５６には、変更部７２と設定部７４が接続されている。変更部７２は、重み付け部５６の重み付けに関する設定を変更するものであり、設定部７４は、ユーザの指示に基づいて、重み付け部５６の重み付けに関する設定を変更するものである。なお、設定部７４は、サーバの入力部（キーボード等）から入力されるユーザの指示に基づいて、設定を変更することとしても良いし、通信部５２，３２を介して携帯型端末１０の入力部１２から入力されるユーザの指示を受けて、設定を変更することとしても良い。

抽出部５８は、フラッシュメモリ６４に格納されているテキストデータから、所定のワードを抽出する。すなわち、携帯型端末１０の入力部１２に入力された情報から、所定のワードを抽出する。この所定のワードとは、他人に見られないほうが好ましいワード、すなわち守秘性が比較的高いワードを意味し、当該ワードは、ハードディスク６６に格納されたキーワードＤＢ（図７参照）において、予め定められている。

分類部６０は、抽出部５８により抽出したワードを守秘性レベルの高いワード（第１ワード）と守秘性レベルがやや高い（中位の）ワード（第２ワード）とに分類する。この分類は、ハードディスク６６に格納されているキーワードＤＢ（図７参照）に基づいて、行われる。変換部６２は、守秘性レベルが「高」のワードと、守秘性レベルが「中」のワードとを、所定のルールに基づいて変換し、フラッシュメモリ６４に格納する。

フラッシュメモリ６４は、サーバ５０内で処理するデータを一時的に記憶するものである。フラッシュメモリ６４には、消去部７６が接続されている。消去部７６は、サーバ側制御部７０の指示に基づいて、所定のタイミングで、フラッシュメモリ６４に格納された音声データやテキストデータを消去する。なお、データを消去する具体的なタイミングについては、後述する。なお、フラッシュメモリ６４に代えて、その他の揮発性メモリを用いることもできる。

ハードディスク６６には、各種処理で用いるデータベースなどのデータが格納される。なお、ハードディスク６６に代えて、その他の不揮発性メモリを用いることとしても良い。

サーバ側制御部７０は、サーバ５０内の各部を統括的に制御し、サーバ５０側における処理を実行するものである。なお、サーバ５０は、実際には、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等を有しており、ＲＯＭ等に格納（インストール）されたプログラムをＣＰＵが実行することで、前述したテキストデータ生成部５４、重み付け部５６、抽出部５８、分類部６０、変換部６２、声紋分析部５５などの各部の機能を実現する。

次に、本実施形態のパーソナルアシスタントシステム１００における処理について、図２〜図２５に基づいて、詳細に説明する。

まず、音声入力部４２から入力される音声をサーバ５０側のフラッシュメモリ６４に格納する処理（録音処理）について図２（ａ）〜図２（ｄ）に基づいて説明する。なお、録音処理は、常時行うこととしても良いのは勿論であるが、省電力化を図り、効率的な録音を行うため、本実施形態では、図２（ａ）〜図２（ｄ）の処理のうち、少なくとも２つの処理を同時並行的に行ったり、いずれか１つの処理のみを行ったりする。

（録音タイミング例１）
図２（ａ）は、ある人物が音声を発している間だけ、録音を実行する処理を示すフローチャートである。なお、音声入力部４２に入力される音声は、通信部３２、５２を介して、サーバ側制御部７０に入力されているものとする。

この図２（ａ）の処理では、ステップＳ１０において、サーバ側制御部７０が、音声入力部４２から音声が入力されたか否かを判断する。ここでの判断が肯定されると、ステップＳ１２では、サーバ側制御部７０の指示の下、声紋分析部５５が、入力された音声の声紋分析を行う。この声紋分析では、ハードディスク６６に格納されている声紋ＤＢ（図３参照）に含まれる音声データと、入力された音声データとを照合（パターンマッチング）することにより、入力された音声を発した人物を特定する。ここで、図３の声紋ＤＢには、人物名と、その人物の声紋データとが対応付けられている。なお、本システムをビジネス用として用いる場合には、例えば、会社の社員全員の声紋データを声紋ＤＢに登録しておくなどすることができる。また、本システムをプライベート用として用いる場合には、各ユーザが個別に、家族や親戚、友人等の声紋データを声紋ＤＢに登録しておくなどすることができる。この登録は、携帯型端末１０の音声入力部４２から行う。

次いで、ステップＳ１４では、サーバ側制御部７０が、ステップＳ１２において人物が特定されたか否か、すなわち、声紋ＤＢに登録された人物の音声であったか否かを判断する。ここでの判断が肯定された場合には、サーバ側制御部７０は、ステップＳ１６において録音（フラッシュメモリ６４への格納）を開始する。なお、録音された音声データは、テキストデータ生成部５４においてテキストデータに変換されることから、この録音開始のタイミングは、テキストデータ生成のタイミングであるともいえる。一方、ステップＳ１４における判断が否定された場合には、ステップＳ１０に戻る。

ステップＳ１４の判断が肯定され、ステップＳ１６に移行した後は、サーバ側制御部７０は、ステップＳ１８において音声入力が所定秒間途絶えるまで、録音を続ける。そして、音声入力が所定秒間なかった場合、すなわち、音声入力が終了したとみなされた場合に、ステップＳ１８の判断が肯定される。ステップＳ１８の判断が肯定されると、端末側制御部３０は、ステップＳ２０において録音を終了して、ステップＳ１０に戻る。

その後は、上記処理を繰り返すことで、声紋ＤＢに登録されている人物が音声を発するタイミングごとに、録音が実行されるようになっている。なお、録音タイミングを決定する人物は、声紋ＤＢとは別のＤＢにて管理しても良い。これにより、例えば、録音タイミングを決定する人物を、会議の主催者などに限定することが可能である。

なお、図２（ａ）では、声紋に基づいて、ある人物が発声したタイミングで、録音を開始する場合について説明したが、これに限らず、例えば、電話に関連した周波数（例えば着信音の周波数）が音声入力部４２から入力された時点から録音を開始することとしても良い。これにより、電話での会話を漏らすことなく録音することができるようになる。

（録音タイミング例２）
図２（ｂ）は、予め登録されている時刻において録音を実行する処理を示すフローチャートである。なお、この図２（ｂ）の処理は、図２（ａ）の場合と異なり、携帯型端末１０側の通信部３２から音声データをサーバ５０側に送信するか、しないかを切り替えることで、録音タイミングを切り替えるものである。

図２（ｂ）では、ステップＳ２４において、端末側制御部３０が、時刻検出部２４を介して、現在時刻を検出する。次いで、ステップＳ２６では、端末側制御部３０が、予め定められた録音開始時刻か否かを判断する。ここで、録音開始時刻は、携帯型端末１０の出荷時に予め定められていても良いし、ユーザ等が、入力部１２から予め入力しても良い。この録音開始時刻としては、例えば、人との会話などが多く、情報量が多いと考えられる時間（例えば、会社に出社した直後の１時間）や、集中力が途切れやすい時間（例えば、昼休み前後３０分や、疲労がピークに達する残業時間（午後８時以降など））とすることができる。

ステップＳ２６の判断が肯定された場合には、ステップＳ２８に移行し、通信部３２が、端末側制御部３０の指示の下、音声入力部４２に入力された音声データをサーバ５０側へ送信し始める。この場合、通信部５２及びサーバ側制御部７０を介して、音声データがフラッシュメモリ６４に格納される（録音される）。

次いで、ステップＳ３０では、端末側制御部３０が、時刻検出部２４を介して、現在時刻を検出する。そして、次のステップＳ３２では、端末側制御部３０が、予め定められている録音終了時刻が到来したか否かを判断する。ここでの判断が肯定されると、ステップＳ３４に移行するが、判断が否定されると、ステップＳ３０に戻る。ステップＳ３４に移行した場合、通信部３２は、端末側制御部３０の指示の下、サーバ５０側への音声データ送信を停止する。これにより、録音が終了する。その後は、ステップＳ２４に戻り、上記処理を繰り返す。これにより、録音開始時刻が到来するたびに、録音を行うことができる。

（録音タイミング例３）
図２（ｃ）は、予め登録されている会議の終盤に録音を実行する処理を示すフローチャートである。なお、この図２（ｃ）の処理も、図２（ｂ）と同様、通信部３２から音声データをサーバ５０側に送信するか、しないかを切り替えることで、録音タイミングを切り替えるものである。

図２（ｃ）では、ステップＳ３６において、端末側制御部３０が、時刻検出部２４を介して、現在時刻を検出する。次いで、ステップＳ３８では、端末側制御部３０が、フラッシュメモリ２８に格納されているタスクリスト（後述する）の中から、会議の予定を抽出し、当該会議の終了時刻よりも所定時間前（例えば１０分前）か否かを判断する。ここでの判断が肯定された場合には、ステップＳ４０において、図２（ｂ）のステップＳ２８と同様の方法で録音を開始する。

次のステップＳ４２では、端末側制御部３０が、時刻検出部２４を介して、現在時刻を検出する。そして、次のステップＳ４４では、端末側制御部３０が、ステップＳ３８の判断に用いた会議の終了時刻が到来したか否かを判断する。ここでの判断が肯定されると、ステップＳ４６に移行するが、判断が否定されると、ステップＳ４２に戻る。ステップＳ４６に移行した場合、通信部３２は、端末側制御部３０の指示の下、サーバ５０側への音声データ送信を停止する。その後は、ステップＳ３６に戻り、上記処理を繰り返す。これにより、会議の終盤の所定時間における録音が可能となる。なお、会議の終盤に録音を行うこととしたのは、会議の終盤ほど、会議の結論が発言されたり、次の会議の予定がアナウンスされたりする可能性が高いからである。

なお、図２（ｃ）の処理では、会議が実施されている時間中、継続して録音を行うこととしても良い。また、その会議の司会者や発表者などがタスクリストに登録されている場合には、図２（ａ）の処理と組み合わせて、登録されている司会者や発表者の音声のみを録音するようにしても良い。

（録音タイミング例４）
図２（ｄ）には、生体情報入力部２０から入力される情報（ここでは、ユーザの筋肉の状態（緊張度及び弛緩度）とする）に基づいて、録音を実行する処理を示すフローチャートである。なお、この図２（ｄ）の処理も、図２（ｂ）、図２（ｃ）と同様、通信部３２から音声データをサーバ５０側に送信するか、しないかを切り替えることで、録音タイミングを切り替えるものである。

図２（ｄ）では、ステップＳ５０において、端末側制御部３０が、生体情報入力部２０を介して、ユーザの筋肉の状態を取得する。次いで、ステップＳ５２では、端末側制御部３０が、筋肉の状態と予め定められている閾値とを比較して、所定の弛緩状態か否かを判断する。ここでの判断が肯定された場合には、ステップＳ５４において、図２（ｂ）のステップＳ２８と同様の方法で録音を開始する。

次のステップＳ５６において、端末側制御部３０が、再度、筋肉の状態を取得すると、次のステップＳ５８では、端末側制御部３０が、筋肉の状態と予め定められている閾値とを比較して、所定の緊張状態か否かを判断する。ここでの判断が肯定されると、ステップＳ６０に移行するが、判断が否定されると、ステップＳ５６に戻る。ステップＳ６０に移行した場合、通信部３２は、端末側制御部３０の指示の下、サーバ５０側への音声データ送信を停止する。その後は、ステップＳ５０に戻り、上記処理を繰り返す。以上の処理により、筋肉の状態から、ユーザの緊張度合いを判断し、ユーザがリラックスしすぎており、他人の話を聞いていないような状況（例えば居眠りをしている状況）での、音声の自動的な録音を行うことが可能となる。

なお、図２（ｄ）では、リラックスしすぎているときにのみ、音声を録音することとしたが、これとともに又はこれに代えて、適度に緊張しているときに音声を録音することとしても良い。適度に緊張している場合には、重要な話がされている可能性が高いからである。

なお、受話器（携帯型端末筐体）に発汗センサと圧力センサとの少なくとも一方を設けて受話器を保持する手の発汗量や、受話器の保持力からユーザが緊張状態または弛緩状態であることを検出してもよい。

この発汗センサと圧力センサとの出力を端末側制御部３０に送信し、端末側制御部３０はユーザが緊張状態または弛緩状態であると判断したときに音声入力部４２による録音を開始するようにしてもよい。

発汗センサとしては複数の電極を設けて手のインピーダンスを測定するようにすれば良い。感動、興奮、緊張といったような精神性発汗は、発汗量が少なく、発汗時間も短いので、指よりも発汗量が多い中手の掌側に対応して受話器に発汗センサを設ければよい。

圧力センサとしては、静電容量型、歪ゲージ、電歪素子のいずれを用いてもよく、ユーザが通常受話器を握る圧力よりも例えば１０％以上大きな圧力で受話器を握ったときに緊張状態と判断するようにすればよい。

また、発汗センサと圧力センサの少なくとも一方は、携帯型端末１０に設けてもよく、携帯電話などに設けてもよい。

なお、上述したように、図２（ａ）〜図２（ｄ）の処理において録音開始タイミングとなった場合でも、例えば、携帯型端末１０が録音禁止位置に存在している場合などにおいては、録音を開始しないようにしても良い。録音禁止位置としては、例えば、ユーザが勤務する会社以外の会社内などを採用することができる。

（音声データの処理）
次に、音声データが録音された後に行われる音声データの処理について、図４〜図２３に基づいて説明する。図４は、音声データの処理に関するフローチャートである。

図４のステップＳ７０では、サーバ側制御部７０が、フラッシュメモリ６４に音声データが録音されたか否かを判断する。ここでの判断が肯定されると、ステップＳ７２に移行し、テキストデータ生成部５４が、サーバ側制御部７０の指示の下、音声データをテキスト化する。この場合、音声データが所定時間途切れるたびにテキスト化される。また、サーバ側制御部７０は、音声データをテキスト化したデータ（テキストデータ）と、音声データが音声入力部４２に入力された時刻と、音声データが入力された位置と、音声データの音声レベルを、フラッシュメモリ６４内の記憶データＤＢ（図５）に登録する。なお、ここで登録される時刻や位置の情報は、前述のように、音声データとともに通信部３２から送信されているものである。次いで、ステップＳ７４では、声紋分析部５５が、サーバ側制御部７０の指示の下、声紋分析をして音声を発した人物を特定し、記憶データＤＢに登録する。なお、図２（ａ）のステップＳ１２の処理を経ている場合には、ステップＳ７４を行わずに、ステップＳ１２の内容を記憶データＤＢに登録することとしても良い。

図５には、記憶データＤＢのデータ構造が示されている。記憶データＤＢには前述した、時刻、位置、テキストデータ、発声人物、音声レベル、並びにタスクフラグ、タスク優先度が格納される。なお、タスクフラグ及びタスク優先度の項目については、後述する。

図４に戻り、次のステップＳ７６では、タスク判定のサブルーチンを実行する。タスク判定のサブルーチンでは、一例として、図６の処理を実行する。図６の処理では、ステップＳ１１０において、サーバ側制御部７０が、テキストデータに日時が含まれているか否かを判断する。なお、ここでの日時には、何年何月何日何時という具体的な日時のほか、明日、明後日、午前、午後などの日時も含まれる。ここでの判断が肯定された場合には、ステップＳ１１４においてタスクと判定された後に、図４のステップＳ７８に移行するが、判断が否定された場合には、ステップＳ１１２に移行する。

ステップＳ１１２では、サーバ側制御部７０がテキストデータに、特定のワードが含まれているか否かを判断する。ここで、特定のワードは、タスクに関連するワードであり、例えば、「すること」、「してください」、「しなさい」、「しろ」、「やれ」、「しよう」、「します」、「しましょう」、「予定しています」などのワードである。この特定のワードは、装置出荷時に予めハードディスク６６内にテーブルとして格納されていても良いし、ユーザが随時追加するようにしても良い。ステップＳ１１２の判断が肯定された場合には、ステップＳ１１４においてタスクと判定された後に、図４のステップＳ７８に移行する。一方、ステップＳ１１２の判断が否定された場合には、ステップＳ１１６においてタスクでないと判定された後に図４のステップＳ７８に移行する。

図４に戻り、ステップＳ７８では、サーバ側制御部７０が、図６の処理の結果、タスクと判定されたか否かを判断する。以下、ステップＳ７８の判断が肯定された場合と、否定された場合の処理について説明する。

（ステップＳ７８の判断が肯定された場合（タスクであった場合））
ステップＳ７８の判断が肯定されると、ステップＳ８０に移行し、サーバ側制御部７０は、記憶データＤＢ（図５）のタスクフラグをオンに設定する。次いで、ステップＳ８２では、抽出部５８が、サーバ側制御部７０の指示の下、ハードディスク６６に格納されているキーワードＤＢ（図７）に基づいて、キーワードを抽出する。図７に示すように、キーワードＤＢには、キーワードと、そのキーワードの詳細情報、属性、守秘性のレベルと、が紐付けられている。したがって、抽出部５８は、このキーワードＤＢのキーワードの項目に着目し、テキストデータから、キーワードＤＢに登録されているキーワードを抽出するようにする。

例えば、テキストデータが、
『１１月２０日１３時に、クールブルースピーカ２のソフトウェア仕様について、大東京株式会社の青山一郎さんと打合せ予定』
であったとする。

この場合、抽出部５８は、図７のキーワードＤＢに登録されている「クールブルースピーカ２」、「ソフトウェア」、「仕様」、「大東京株式会社」、「青山一郎」を、キーワードとして抽出する。

なお、キーワードＤＢは、事前に予め作成しておく必要がある。また、キーワードＤＢの登録内容は、適宜（例えば、メンテナンス時等において）追加・変更が可能であるものとする。また、図７では、個人名、会社名、技術用語などの属性以外にも、特許情報や予算情報、商談情報などの属性でキーワードを登録しても良い。

図４に戻り、次のステップＳ８４では、各キーワードの解析サブルーチンが実行される。図８には、ステップＳ８４の解析サブルーチンの具体的処理がフローチャートにて示されている。

この図８では、ステップＳ１２０において、分類部６０が、サーバ側制御部７０の指示の下、キーワードＤＢから、キーワードの守秘性のレベルを取得する。具体的には、分類部６０は、キーワードＤＢから「クールブルースピーカ２」の守秘性レベルとして「中」を取得し、「ソフトウェア」の守秘性レベルとして「中」を取得し、「仕様」の守秘性レベルとして「中」を取得し、「大東京株式会社」の守秘性レベルとして「高」を取得し、「青山一郎」のレベルとして「高」を取得する。

次いで、ステップＳ１２２では、変換部６２が、サーバ側制御部７０の指示の下、ステップＳ１２０で取得された守秘性に基づいてキーワードを変換し、変換後のキーワードを、フラッシュメモリ６４に記憶するサブルーチンを実行する。

図９は、ステップＳ１２２のサブルーチンの具体的処理を示すフローチャートである。図９に示すように、変換部６２は、まず、ステップＳ１３８において、抽出部５８で抽出されたキーワードの中から１つのキーワードを選択する。なお、ここでは、一例として、「大東京株式会社」が選択されたものとする。

次いで、ステップＳ１４０では、変換部６２が、選択したキーワードの守秘性レベルが「高」であるか否かを判断する。「大東京株式会社」は、前述のように、守秘性レベルが「高」であるので、ここでの判断は肯定され、ステップＳ１４２に移行する。ステップＳ１４２では、変換部６２が、キーワードを守秘性に応じて変換するサブルーチンを実行する。具体的には、図１０に示すフローチャートに沿って処理を実行する。

図１０のステップＳ１６０では、変換部６２が、選択したキーワードに特定変換ワードが含まれているか否かを判断する。ここで、特定変換ワードとは、例えば、図１１の特定変換ワードＤＢに定義されているような、会社名に頻繁に用いられるワード（株式会社、有限会社、（株）、（有）など）や、国等の機関に頻繁に用いられるワード（機構、省、庁など）や、教育機関に頻繁に用いられるワード（大学、高等学校など）等を意味する。

選択されたキーワード「大東京株式会社」の場合、特定変換ワード「株式会社」を含んでいるので、ステップＳ１６０の判断は肯定され、ステップＳ１６２に移行する。ステップＳ１６２では、変換部６２は、特定変換ワードを特定変換ワードＤＢに基づいて変換する。この場合、「大東京株式会社」のうちの「株式会社」の部分が「社」に変換される。次いで、ステップＳ１６４では、特定変換ワード以外の変換サブルーチンを実行する。

図１２は、ステップＳ１６４の変換サブルーチンの具体的処理を示すフローチャートである。この図１２に示すように、変換部６２は、ステップＳ１９０において、変換対象部分（特定変換ワード以外の部分）が、地名であるか否かを判断する。ここで、変換対象部分「大東京」は、地名を含んではいるものの、地名そのものではないので、判断は否定され、ステップＳ１９４に移行する。

ステップＳ１９４では、変換部６２は、変換対象部分が氏名であるかを判断する。ここでは、氏名ではないので、判断は否定されステップＳ１９８に移行する。そして、ステップＳ１９８では、変換部６２は、変換対象部分「大東京」をイニシャル変換して「Ｄ」とする。ステップＳ１９８の処理が終了すると、図１０のステップＳ１６５に移行する。

ステップＳ１６５では、変換部６２が、ステップＳ１６２，Ｓ１６４の変換後のワードを組み合わせる。具体的には、「Ｄ」と「社」とを組み合わせて「Ｄ社」とする。

次いで、ステップＳ１６８では、変換部６２が、変換対象のキーワード「大東京株式会社」に情報が付帯しているか否かを判断する。ここで、情報が付帯しているとは、図７のキーワードＤＢの情報の欄に、情報が入力されている場合を意味する。ここでは、「大東京株式会社」に、「電機 東京都品川区」が付帯しているため、ステップＳ１６８の判断は肯定され、ステップＳ１７０に移行する。

ステップＳ１７０では、変換部６２が、付帯している情報のうちで、未だ選択されていない情報を１つ選択する。次いで、変換部６２は、ステップＳ１７２において、選択した情報（例えば、「電機」）の守秘性レベルが「高」又は「中」であるか否かを判断する。ここで、「電機」が守秘性レベルが「低」であるとすると、ステップＳ１７２の判断は否定されるので、ステップＳ１８２に移行する。ステップＳ１８２では、変換部６２は、全ての情報が選択済みであるか否かを判断する。ここでは、まだ、「東京都品川区」が未選択であるので、判断は否定されて、ステップＳ１７０に戻る。

次いで、変換部６２は、ステップＳ１７０において、未選択の情報「東京都品川区」を選択するとともに、ステップＳ１７２において、「東京都品川区」の守秘性レベルが「高」又は「中」か否かを判断する。ここで、図７のキーワードＤＢに示すように、地名は、「低」又は付帯するキーワードの守秘性レベルに準じると定義されているため、「東京都品川区」は、キーワード「大東京株式会社」に準じて、守秘性レベルは「高」となる。したがって、ステップＳ１７２の判断は肯定され、ステップＳ１７４に移行する。ステップＳ１７４では、変換部６２は、「東京都品川区」に特定変換ワードが含まれているか否かを判断する。ここでの判断が否定されると、ステップＳ１８０に移行して、情報を変換する変換サブルーチンを実行する。このステップＳ１８０の変換サブルーチンは、基本的には、前述したステップＳ１６４と同様の処理（図１２）である。

すなわち、図１２では、変換部６２が、ステップＳ１９０において、「東京都品川区」が地名か否かを判断する。ここでの判断が肯定されると、変換部６２は、ステップＳ１９２において、図１３に示す地名ＤＢに基づいて変換処理を実行する。具体的には、変換部６２は、「東京都品川区」を、守秘性レベルが「高」の変換方法で変換することで、「関東南部」と変換する。なお、図１３の地名ＤＢでは、守秘性レベルが「高」の場合、当該地名を、比較的広い区域の中での位置として表現し、守秘性レベルが「中」の場合には、当該地名を、守秘性レベルが「高」の場合よりも狭い区域の中での位置として表現している。

ステップＳ１９２の処理が終了すると、その後は、図１０のステップＳ１８２に移行する。このステップＳ１８２の段階では、既に全ての情報（電機、東京都品川区）が選択済みであるので、ステップＳ１８２の判断が肯定されて、ステップＳ１８４に移行する。ステップＳ１８４では、変換部６２が、変換後の情報を、変換後のキーワード（ステップＳ１６５又はＳ１６６）に対応付ける。ここでは、「Ｄ社（電機，関東南部）」となる。その後、図９のステップＳ１４４に移行する。

図９のステップＳ１４４では、変換後のキーワードを、フラッシュメモリ６４に記憶されているキーワード格納ＤＢ（図１４参照）の領域Ａに格納する。なお、図１４に示すように、キーワード格納ＤＢには、領域Ａのほか、領域Ｏ、Ｂ、Ｃの格納領域が設けられている。領域Ｏには、キーワードの生データ（変換前キーワード）が、格納される。当該格納処理が完了すると、ステップＳ１５４に移行し、抽出部５８で抽出されたキーワードの全てが選択済みであるか否かを判断する。ここでの判断が否定されると、ステップＳ１３８に戻る。

次に、ステップＳ１３８において、変換部６２が、キーワードとして「クールブルースピーカ２」を選択した場合について説明する。この場合、キーワードは、「クールブルースピーカ２」であり、守秘性レベルが「中」であるので、ステップＳ１４０の判断が否定される一方、ステップＳ１４６の判断が肯定されて、ステップＳ１４８に移行する。

ステップＳ１４８では、キーワードを守秘性に応じて変換するサブルーチンを実行する。具体的には、ステップＳ１４２と同様、図１０の処理を実行することになる。図１０の処理では、ステップＳ１６０において、変換部６２が、「クールブルースピーカ２」に特定変換ワードが含まれているか否かを判断するが、ここでの判断は否定されるので、ステップＳ１６６に移行し、変換サブルーチンを実行する。このステップＳ１６６の変換サブルーチンでは、前述したステップＳ１６４、Ｓ１８０と同様に、図１２の処理を実行する。図１２では、「クールブルースピーカ２」は地名でも人名でもないので、ステップＳ１９０，Ｓ１９４の判断が否定され、変換部６２は、ステップＳ１９８においてイニシャル変換を行う。この場合、キーワードＤＢにおいて、「クールブルースピーカ２」に併記されている英語表記「Cool Blue Speaker2」をイニシャル変換（大文字部分をイニシャル変換）して「ＣＢＳ２」と変換する。

以上のようにして図１２の処理が終了すると、図１０のステップＳ１６８に移行するが、図７のキーワードＤＢでは、「クールブルースピーカ２」には何ら情報が付帯していないので、ステップＳ１６８の判断が否定されて、図９のステップＳ１５０に移行する。ステップＳ１５０では、変換後のキーワードを、図１４に示すフラッシュメモリ６４の領域Ｂに格納する。すなわち、変換部６２は、領域Ｏにキーワードそのものを格納するとともに、当該キーワードに対応して領域Ｂに、「ＣＢＳ２」を格納する。当該格納処理が完了すると、ステップＳ１５４に移行し、抽出部５８で抽出されたキーワードの全てが選択済みであるか否かを判断する。ここでの判断が否定されると、再度、ステップＳ１３８に戻る。

次に、ステップＳ１３８において、変換部６２が、キーワード「青山一郎」を選択した場合について説明する。この場合、「青山一郎」は守秘性レベルが「高」であるので、ステップＳ１４０の判断が肯定されて、ステップＳ１４２に移行する。

ステップＳ１４２では、前述したのと同様、図１０の処理を実行する。図１０の処理では、ステップＳ１６０が否定されて、ステップＳ１６６（図１２の処理）に移行する。図１２のステップＳ１９０では、その判断が否定され、ステップＳ１９４に移行する。ステップＳ１９４では、変換部６２が、「青山一郎」が氏名か否かを判断する。そして、ここでの判断が肯定されると、ステップＳ１９６に移行する。なお、ステップＳ１９４において、「青山一郎」が氏名であると判断されるのは、図７のキーワードＤＢにおいて「青山一郎」の属性が、取引先の人名となっているからである。

ステップＳ１９６では、変換部６２が、「青山一郎」をイニシャル変換する。なお、ステップＳ１９６では、キーワードの守秘性レベルが「高」の場合には、氏及び名の両方をイニシャル変換する。すなわち、「青山一郎」は「ＡＩ」に変換されることになる。一方、例えば、図７のキーワードＤＢに登録されている「上田三郎」のように、キーワードの守秘性レベルが「中」であった場合には、名のみをイニシャル変換する。すなわち、「上田三郎」は「上田Ｓ」にイニシャル変換される。なお、氏のみをイニシャル変換して、「Ｕ三郎」と変換しても良い。

ステップＳ１９６の処理が完了すると、図１０のステップＳ１６８に移行する。ここで、キーワード「青山一郎」には、図７に示すように、情報として「大東京株式会社 カメラ ＡＦモータ ２００９年１０月１５日特許研修会（東京）」が付帯しているので、ステップＳ１６８の判断は肯定され、ステップＳ１７０に移行する。そして、ステップＳ１７０では、例えば、情報「大東京株式会社」が選択される。「大東京株式会社」は前述したように守秘性レベルが「高」であるので、ステップＳ１７２の判断は肯定されて、ステップＳ１７４に移行する。そして、「大東京株式会社」は、特定変換ワード「株式会社」を含んでいるので、ステップＳ１７４の判断が肯定されて、当該特定変換ワードの変換（ステップＳ１７６）、及び特定変換ワード以外の変換（ステップＳ１７８）を実行する。なお、ステップＳ１７６，Ｓ１７８は、前述したステップＳ１６２、Ｓ１６４と同様である。そして、ステップＳ１８２の判断が否定されると、ステップＳ１７０に戻る。

その後は、全ての情報が選択済みとなるまで、ステップＳ１７０〜ステップＳ１８２を繰り返す。そして、全ての情報が選択済みとなった後は、ステップＳ１８４において、変換後のキーワードに変換後の情報を対応付ける。ここでは、例えば、「ＡＩ（カメラ，ＡＦＭ，２００９年１０月１５日Ｔ会（東京））」と対応付けられる。そして、図９のステップＳ１４４で、領域Ａへの格納が完了すると、ステップＳ１５４に移行し、抽出部５８で抽出されたキーワードの全てが選択済みであるか否かを判断する。ここでの判断が否定されると、再度、ステップＳ１３８に戻る。

なお、上記処理において、図９のステップＳ１４６の判断が否定された場合、すなわち、キーワードの守秘性レベルが「低」であった場合には、ステップＳ１５２において、当該キーワードをそのまま領域Ｃ（及び領域Ｏ）に格納する。なお、キーワードに情報が付帯している場合には、当該情報も領域Ｃに格納する。例えば、図１４に示すように、キーワード「エスブイエス社」であれば、領域Ｃには、「エスブイエス社 機械 ドイツ ミュンヘン」として格納される。

また、上記処理において、例えば、ステップＳ１３８において選択されたキーワードが「ソフトウェア」であった場合には、ソフトウェアをイニシャル変換し、「ＳＷ」とするとともに、図７に示す情報＜スポンジ＞を変換せずに、ＳＷに対応付ける。この場合において、＜○○＞という表記は、キーワードと対等で取り扱うワードであることを意味するものとする。すなわち、「ソフトウェア」と「スポンジ」のいずれかを用いるという意味であるものとする。したがって、キーワード「ソフトウェア」に対して上記処理を行った場合、フラッシュメモリ６４の領域Ｂには、「ＳＷ」と「スポンジ」が対等に格納されることになる。なお、「ＳＷ」と「スポンジ」の使い分けについては、後述する。

以上の処理をその他のキーワード（ここでは「仕様」）に対しても行い、図９のステップＳ１５４の判断が肯定されると、図８のステップＳ１２４に移行する。

ステップＳ１２４では、サーバ側制御部７０が、発言者の属性に関する重みを取得する。この場合、図１５（ａ）に示す属性に関する重みテーブルに基づいて、発言者の役職から、重み（Ｔｗ）を取得する。例えば、発言者が、図７の上田三郎である場合には、重み（Ｔｗ）としてマネジャー（Ｍ）の「２」を取得する。

次いで、ステップＳ１２６では、サーバ側制御部７０が、音声レベルに関する重みを取得する。この場合、サーバ側制御部７０は、図１５（ｂ）に示す音声レベルに関する重みテーブルと、記憶データＤＢ（図５参照）に記憶されている音声レベルと、に基づいて重み（Ｖｗ）を取得する。図５のように、音声レベルが７０ｄｂの場合には、重み（Ｖｗ）は３となる。なお、音声レベルが大きいほど重み（Ｖｗ）が大きいのは、音声レベルが大きいほど、頼まれ方が強く、重要度が高い場合が多いからである。

次いで、図８のステップＳ１２８では、サーバ側制御部７０が、キーワードに関する重みを取得する。この場合、サーバ側制御部７０は、図１５（ｃ）に示すキーワードに関する重みテーブルと、記憶データＤＢのテキストデータに含まれるキーワードと、に基づいて重み（Ｋｗ）を取得する。図１５（ｃ）では、「大切」「重要」や、「とても大切」「とても重要」が登録されているので、これらのキーワードがテキストデータに含まれていれば、重み（Ｋｗ）として、２又は３を取得する。また、ステップＳ１２８では、サーバ側制御部７０は、テキストデータ中に、守秘性レベルが「高」のキーワード、守秘性レベルが「中」のキーワードがいくつ含まれていたかを判定し、その判定結果と、図１５（ｄ）に示すキーワードの守秘性に関する重みテーブルと、に基づいて、テキストデータの守秘性に関する重み（Ｃｗ）を取得する。例えば、テキストデータに、守秘性レベルが「高」のキーワードが２個、守秘性レベルが「中」のキーワードが１個含まれていた場合には、サーバ側制御部７０は、Ｃｗ＝８（＝３×２＋２×１）を取得する。

図８のステップＳ１２８の処理が完了すると、図４のステップＳ８６に移行する。ステップＳ８６では、サーバ側制御部７０は、タスク優先度（Ｔｐ）を算出し、記憶データＤＢ（図５）に登録する。具体的には、サーバ側制御部７０は、タスク優先度（Ｔｐ）を、次式（１）を用いて、算出する。
Ｔｐ＝Ｕｖｗ×Ｖｗ＋Ｕｔｗ×Ｔｗ
＋Ｕｆｗ×Ｆｗ＋Ｕｋｗ×Ｋｗ＋Ｕｃｗ×Ｃｗ …（１）

なお、上式（１）のＵｖｗ、Ｕｔｗ、Ｕｆｗ、Ｕｋｗ、Ｕｃｗは、各重み（Ｖｗ，Ｔｗ，Ｆｗ，Ｋｗ，Ｃｗ）の重要度を加味した重み付け係数であり、当該重み付け係数は、ユーザ等が設定部７４を介して、設定することができるようになっている。

次いで、図４のステップＳ８８に移行し、サーバ側制御部７０は、テキストデータ中に含まれていたキーワードの、図１６に示すキーワード記録ＤＢへの登録を行う。なお、この図１６のキーワード記録ＤＢは、例えば、１週間、１ヶ月単位又は１年単位で作成されるものである。この図１６のキーワード記録ＤＢでは、テキストデータ中に含まれていたキーワード（登録キーワードと呼ぶ）と同時に使用されたキーワードや、登録キーワードの発言者、登録キーワードが発言された日時、場所、などの関連情報を逐一記録する。また、登録キーワードと関連情報が関連付けられた回数を関連度合いとして、記録する。更に、登録キーワードが発せられた回数を出現頻度として記録する。なお、図１６のキーワード記録ＤＢの検索頻度の項目については、後述する。

なお、ステップＳ８８の処理が完了した後は、ステップＳ７０に戻る。

（ステップＳ７８の判断が否定された場合（タスクでなかった場合））
次に、ステップＳ７８の判断が否定された場合について、説明する。ステップＳ７８が否定されると、ステップＳ９０に移行して、サーバ側制御部７０が、タスクフラグをオフにする。次いで、ステップＳ９２では、サーバ側制御部７０が、発声者がユーザ自身であるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ９４に移行し、ユーザが発した言葉はコマンドであるか否かを判断する。ここでは、例えば、図１７のコマンドＤＢに示すように、「タスクリスト」という言葉が、タスクリストを表示するコマンドであり、「音声録音テキスト」という言葉が、音声録音リストを表示するコマンドであり、「変換」という言葉が、変換処理のコマンドであるものとする。なお、このコマンドＤＢは、携帯型端末１０側のフラッシュメモリ２８又はサーバ５０側のハードディスク６６に格納されているものとする。このコマンドＤＢでは、例えば、ユーザの音声が「タスクリスト」であった場合に、図１８（ａ）に示すようなタスクリストを表示することが定義されている。なお、タスクリストの詳細については後述する。また、コマンドＤＢでは、ユーザの音声が「音声録音テキスト」であった場合に、図１８（ｂ）に示すような音声録音リストを表示することが定義されている。なお、この音声録音リストの詳細についても後述する。

図４に戻り、ステップＳ９４の判断が否定された場合には、ステップＳ７０に戻るが、ステップＳ９４の判断が肯定された場合には、ステップＳ９６に移行して、サーバ側制御部７０が、コマンドに応じた処理を実行するサブルーチンを実行する。具体的には、図１９、図２０、図２１の処理が同時並行的に実行される。

まず、図１９のフローチャートに沿って、サーバ５０側での処理について説明する。サーバ５０側では、ステップＳ２０２において、サーバ側制御部７０が、コマンドは、表示要求であったか否かを判断する。この場合、前述のように、「タスクリスト」や「音声録音テキスト」というコマンドが、表示要求に該当する。

次いで、ステップＳ２０４では、サーバ側制御部７０が、コマンドに応じた表示を行うのに必要なデータを、フラッシュメモリ６４から抽出する。例えば、コマンドが「タスクリスト」であれば、タスクリストに表示すべきテキストデータ（図５におけるタスクフラグがオンになっているテキストデータ）をフラッシュメモリ６４から抽出する。なお、この場合のタスクフラグがオンになっているテキストデータには、音声データから変換されたテキストデータのみならず、テキストデータ入力部４４から直接入力されたテキストデータも含んでいる。なお、直接入力されたテキストデータのタスクフラグのオンオフは、前述した図６と同様の処理により実行する。

次いで、ステップＳ２０６では、サーバ側制御部７０が、ユーザの現在位置を取得する。この場合、携帯型端末１０が有する位置検出部２２において検出される位置情報を、端末側制御部３０、通信部３２，５２などを介して取得する。

次いで、ステップＳ２０８では、サーバ側制御部７０が、取得した位置情報（現在位置）に基づいて、セキュリティ確保可能な場所であるかを判断する。ここで、セキュリティ確保可能な場所としては、例えば、会社内が挙げられる。なお、会社の位置の登録は、以下の方法で行われる。

例えば、ユーザは、携帯型端末１０をＵＳＢ等によりＰＣ（Personal Computer）に接続して、ＰＣ上で地図情報を用いた専用のアプリケーションを起動する。そして、当該アプリケーションで、会社の所在地を指定することで、会社の位置を登録する。なお、所在地の指定は、マウス等を用いたドローイング操作などにより行う。この会社の位置は所定面積の領域として表される。したがって、会社の位置としては、図２２のセキュリティ確保可能範囲ＤＢに示すように、矩形の領域の対角の２地点（緯度、経度）で表すことができる。この図２２のセキュリティ確保可能範囲ＤＢは、サーバ側制御部７０のハードディスク６６に格納される。

すなわち、ステップＳ２０８では、サーバ側制御部７０が、図２２のセキュリティ確保可能範囲ＤＢを参照して、ユーザが当該範囲内に入っている場合に、セキュリティ確保可能な場所内に位置していると判断される。

ステップＳ２０８の判断が肯定された場合には、ステップＳ２１０に移行する。このステップＳ２１０では、サーバ側制御部７０は、抽出したデータに含まれるキーワードに対応付けられた変換ワードを領域Ｏ，Ａ，Ｂ、Ｃから取得し、ステップＳ２１４に移行する。一方、ステップＳ２０８の判断が否定された場合には、ステップＳ２１２に移行する。このステップＳ２１２では、サーバ側制御部７０は、抽出したデータに含まれるキーワードに対応付けられた変換ワードを領域Ａ，Ｂから取得し、ステップＳ２１４に移行する。

ステップＳ２１４では、サーバ側制御部２１４が通信部５２を介して、抽出したデータ及びキーワードに対応付けられた変換ワードを携帯型端末１０に向けて送信する。

なお、ステップＳ２０２の判断が否定された場合、すなわち、コマンドが表示要求以外のコマンドであった場合には、サーバ側制御部７０は、ステップＳ２１６においてコマンドに従った処理を実施する。

次に、図２０に基づいて、携帯型端末１０における処理について説明する。図２０のステップＳ２２０では、端末側制御部３０が、サーバ側からデータが送信されてきたか否かを判断する。本ステップでは、図１９のステップＳ２１４が実行された後に、判断が肯定されることになる。

次いで、ステップＳ２２１では、端末側制御部３０が、領域Ａ，Ｂ，Ｃの変換ワードが送信されてきたか否かを判断する。ここでは、図１９のステップＳ２１０を経た場合に判断が肯定され、ステップＳ２１２を経た場合に判断が否定される。

ステップＳ２２１の判断が肯定された場合、ステップＳ２２２において、端末側制御部３０が、抽出したデータに含まれるキーワードを領域Ａ，Ｂ、Ｃの変換ワードで変換する。すなわち、例えば、抽出したデータが、
『１１月２０日１３時に、クールブルースピーカ２のソフトウェア仕様について、大東京株式会社の青山一郎さんと打合せ予定』
であったとする。この場合、領域Ａ，Ｂ、Ｃの変換ワードを用いて、
『１１月２０日１３時に、ＣＢＳ２のＳＷＳＰについて、Ｄ社（電機，関東南部）のＡＩ（カメラ，ＡＦＭ，2009年10月15日Ｔ会（東京））さんと打合せ予定』
と変換される。

一方、ステップＳ２２１の判断が否定された場合、ステップＳ２２３において、端末側制御部３０が、抽出したデータを、領域Ｂの変換ワードで変換するとともに、領域Ａのワードを削除する。この場合、上記抽出したデータは、
『１１月２０日１３時に、ＣＢＳ２のＳＷＳＰについて、 の さんと打合せ予定』
と変換される。このように、本実施形態では、セキュリティが確保されているか否かによって、データの表示態様が変更されるようになっている。

上記のようにして、ステップＳ２２２又はステップＳ２２３の処理が行われた後は、ステップＳ２２４に移行し、端末側制御部３０は、変換後のテキストデータを、表示部１４の所定の位置に表示する処理を実行する。この表示においては、単にタスクの時刻（日時）が現在時刻（日時）に近い順に表示することとしても良いが、本実施形態では、これに代えて、タスク優先度の高い順に表示することとする。これにより、ユーザは、重要なタスクの見落としを低減することができるとともに、複数の予定をダブルブッキングしてしまった場合でも優先度の高いタスクを優先して予定を組むことができるようになる。なお、ダブルブッキングしている場合には、端末側制御部３０が警告部１８を介して警告を発しても良いし、優先度の低い方の予定に関わる人がタスクに含まれているような場合には、その人に対して、端末側制御部３０がタスクの日程の変更依頼通知を電子メールにて自動で依頼するようにしてもよい。ただし、上記のようにタスク優先度の高い順に表示する場合に限られるものではなく、日時順に表示しても勿論良い。また、日時順に表示して、タスク優先度の高いタスクのフォント、色、大きさなどを変更して目立つように表示することとしても良い。また、タスク優先度の高い順に並べた上で、タスク優先度が同一であるタスクについては、日時順に表示することとしても良い。

以上、図１９、図２０の処理により、図１８（ａ）や図１８（ｂ）に示すような画面表示がなされる。なお、図１８（ｂ）の録音音声リストには、タスクの項目が設けられている。ユーザは、当該タスクの項目をタッチパネル上でタッチしたりすることで、タスクフラグのオンオフを切り替えることができる。この場合、サーバ側制御部７０は、ユーザによるタスクフラグの切り替え操作を認識したときには、図５のタスクフラグを変更するものとする。これにより、図６の処理の結果、タスクフラグのオンオフがユーザの認識と異なっていたとしても、ユーザは、タスクフラグを手動で変更することができるようになる。なお、ユーザがタスクフラグをオンにした場合には、それ以降、そのタスクのテキストデータと類似するテキストデータについては、サーバ側制御部７０がタスクフラグを自動でオンにすることとしても良い。

なお、図２０の処理では、端末側制御部３０は、位置検出部２２で取得される現在位置をサーバ側制御部７０側に送信し、サーバ側制御部７０から送信されてくる変換ワードを用いて、テキストデータを変換して表示することとしている。したがって、本実施形態では、端末側制御部３０が、位置検出部２２で取得される現在位置に応じて、表示部１４への表示を制限していると言うことができる。

次に、図２１に基づいて、図２０の処理と並行して行われる処理について説明する。図２１では、ステップＳ２３２において、端末側制御部３０が、ユーザによって、文書変換ボタンが押されたか否かを判断する。なお、文書変換ボタンは、図１８（ａ）、図１８（ｂ）では、右上端に表示されているボタンである。ユーザは、タッチパネル操作や、キーボード操作等により、文書変換ボタンを押す。このステップＳ２３２における判断が肯定されると、ステップＳ２３４に移行し、否定されると、ステップＳ２３８に移行する。

ステップＳ２３４では、端末側制御部３０が、変換可能なキーワードが表示されているか否かを判断する。ここで、変換可能なキーワードとは、前述した、図１４に示す「ＳＷ」と「スポンジ」のように、１つのキーワードに対し複数の変換ワードが対応付けられているようなキーワードを意味する。したがって、表示部１４に表示されているテキストデータに、このようなキーワードが含まれている場合には、ここでの判断が肯定され、ステップＳ２３６に移行する。一方、ステップＳ２３４の判断が否定された場合には、ステップＳ２３８に移行する。

ステップＳ２３６に移行した場合、端末側制御部３０が、キーワードを変換する。具体的には、例えば、
『１１月２０日１３時に、ＣＢＳ２のＳＷＳＰについて、Ｄ社（電機，関東南部）のＡＩ（カメラ，ＡＦＭ，2009年10月15日Ｔ会（東京））さんと打合せ予定』
と表示されている文章では、「ＳＷ」を「スポンジ」に変換することができるので、端末側制御部３０は、
『１１月２０日１３時に、ＣＢＳ２のスポンジＳＰについて、Ｄ社（電機，関東南部）のＡＩ（カメラ，ＡＦＭ，2009年10月15日Ｔ会（東京））さんと打合せ予定』
と、変換して表示する。

ユーザは、「ＳＷ」という表示では、ソフトウェアを想起できない場合でも、文書変換ボタンを押して、「スポンジ」という表記を見ることで、スポンジ→柔らかい→ソフトというような連想により、ソフトウェアを想起できるようになる。なお、スポンジという言葉を初めて見た場合には、このような連想はできないかもしれないが、社内で当該連想の方法を周知させておけば、ソフトウェアの想起は容易である。

次に、ステップＳ２３８では、端末側制御部３０が、変換前表示ボタン（図１８（ａ）、図１８（ｂ）参照）が押されたか否かを判断する。なお、ユーザが、変換前表示ボタンを押す場合とは、キーワードが変換されていない文章を見たい場合である。ここでの判断が否定された場合には、ステップＳ２３２に戻るが、ここでの判断が肯定された場合には、ステップＳ２４０に移行する。ステップＳ２４０では、端末側制御部３０が、ユーザの現在位置を取得し、ステップＳ２４２では、現在位置がセキュリティ確保可能な場所か否かを判断する。ここでの判断が否定された場合、すなわちユーザがセキュリティ確保できない場所にいる場合には、ユーザに変換前の文章を見せるのを制限する必要があるので、ステップＳ２５２において表示不可能な旨をユーザに通知して、ステップＳ２３２に戻る。なお、ステップＳ２５２の通知の方法としては、表示部１４への表示や警告部１８を介した警告などを採用することができる。

ステップＳ２４２の判断が肯定された場合には、ステップＳ２４４に移行し、端末側制御部３０は、質問事項（ユーザであれば簡単に解答ができる質問）を表示部１４に表示する。なお、質問事項については、サーバ５０側のハードディスク６６に格納されているものとし、端末側制御部３０は、当該質問事項をハードディスク６６から読み出して、表示部１４に表示する。この質問事項及び回答例は、例えば、ユーザが事前に登録しておけば良い。

次いで、ステップＳ２４６では、端末側制御部３０は、入力部１２に対し、ユーザが、音声で回答を入力したか否かを判断する。ここでの判断が肯定されると、端末側制御部３０は、ステップＳ２４８において、ユーザの声であり、かつ回答が正しいか否かを判断する。ユーザの声か否かは、前述したサーバ５０側の声紋分析部５５において音声を分析した結果を用いて判断する。ここでの判断が否定された場合には、ステップＳ２５２において、表示不可能な旨をユーザに通知する。一方、ステップＳ２４８の判断が肯定された場合には、ステップＳ２５０に移行し、領域Ｏの変換ワードで、キーワードを変換前の状態となるように変換して表示する。具体的には、音声で入力されたままの文章、すなわち、上記の例では、
『１１月２０日１３時に、クールブルースピーカ２のソフトウェア仕様について、大東京株式会社の青山一郎さんと打合せ予定』
と表示する。その後は、ステップＳ２３２に移行し、上記処理を繰り返す。なお、上記においては、ユーザが声で質問に回答する場合について説明したが、これに限らず、キーボード等から回答を入力することとしても良い。この場合、端末側制御部３０は、質問の回答に加えて、指紋認証などの生体認証の結果に基づいて、変換前の状態の表示を行うか否かを判断しても良い。

以上のようにして、図４のステップＳ９６の処理が終了すると、ステップＳ７０に戻る。

一方、図４のステップＳ９２の判断が否定された場合、すなわち、発声者がユーザでなかった場合には、ステップＳ１００に移行して、端末側制御部３０が、発声者の情報を表示する。なお、ここでは、端末側制御部３０は、サーバ側制御部７０から受け取った情報に基づいた表示を行う。具体的には、発声者が青山一郎であれば、端末側制御部３０は、その情報をサーバ側制御部７０から受け取って、「青山一郎」と表示する。なお、青山一郎に付帯する情報を受け取った場合には、その情報も表示することとしても良い。また、青山一郎に関連するタスクを、サーバ側制御部７０から受け取った場合には、そのタスクも併せて表示することとしても良い。

このようにすることで、例えば、青山一郎氏が「おはよう」などとユーザに声を掛けてきたときに、表示部１４上に、名前や、関連する情報、タスクなどを表示することができる。これにより、ユーザが人の名前や情報、あるいはその人に関連してやるべきことなどを思い出すのを支援することができる。

次いで、ステップＳ１０２では、サーバ側制御部７０が、図２３に示す曖昧ワードＤＢに登録されているワードが発言されたか否かを判断する。ここでの判断が否定されると、ステップＳ７０に戻るが、判断が肯定されると、ステップＳ１０４に移行する。

ステップＳ１０４では、サーバ側制御部７０及び端末側制御部３０が、図２３の曖昧ワードＤＢに基づいて、発言されたワードに対応する処理を実行する。具体的には、「あの件」や「例の件」と発言された場合には、サーバ側制御部７０は、キーワード記録ＤＢを参照し、発言者が関連情報に含まれるキーワードのうち、出現頻度が所定の閾値よりも高いキーワードを抽出し、端末側制御部３０に送信する。そして、端末側制御部３０は、受信したキーワードを、表示部１４に表示する。例えば、発言者が山口部長であり、出現頻度の閾値が１０であるような場合には、図１６のキーワード記録ＤＢにおけるキーワード「プロジェクトＡ」が表示部１４に表示されることになる。また、図２３に示すように、「（地名）の件」、例えば、「北海道の件」と発言されたような場合には、発言者が関連情報に含まれており、かつ、音声データが入力された位置（緯度、経度）が所定範囲（例えば北海道内）であるキーワード、又は、発言者が関連情報に含まれており、かつ、「北海道」というワードが関連情報に含まれているようなキーワードを抽出して、表示部１４に表示するようにする。更に、例えば、「○月○日の件」と発言されたような場合には、発言者が関連情報に含まれており、かつ、音声データが入力された日時が○月○日と一致するキーワード、又は、発言者が関連情報に含まれており、かつ、「○月○日」というワードが関連情報に含まれているようなキーワードを抽出して、表示部１４に表示するようにする。更には、ある人がある時刻（日時）に話すことが、図１６のキーワード記録ＤＢから容易に推定できるような場合もある。このような場合には、発言者と現在時刻とから、関連するキーワードを表示するようにしても良い。

ステップＳ１０４では、以上のような処理を実行することで、発言者が曖昧な問いかけをしてきたとしても、その問いかけで、何を聞いているのかを自動で判断して、ユーザに対して表示することが可能となる。なお、ステップＳ１０４において、キーワードを表示するたびに、サーバ側制御部７０は、キーワード記録ＤＢの検索頻度を更新する。この検索頻度は、例えば、検索頻度の多いキーワードほど優先的に表示する場合などにおいて利用することができる。

次に、携帯型端末１０及びサーバ５０で取得するデータの消去処理について、図２４、図２５に基づいて説明する。

（データの消去処理（その１：変換データの消去））
図２４には、携帯型端末１０がサーバ５０側から取得した情報を消去する処理がフローチャートにて示されている。この図２４に示すように、端末側制御部３０は、ステップＳ２６０において、データ取得から一定時間（例えば２〜３時間）経過したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２６２に移行し、端末側制御部３０は、フラッシュメモリ２８に記憶されているテキストデータ（変換前のワード及び変換後のワードを含む）を消去する。一方、ステップＳ２６０の判断が否定された場合でも、端末側制御部３０は、ステップＳ２６４においてユーザが会社内から社外に移動したか否かを判断する。そして、ここでの判断が肯定された場合には、ステップＳ２６２に移行して、上記と同様にデータを消去する。なお、ステップＳ２６４の判断が否定された場合には、ステップＳ２６０に戻る。このように、データを取得してから所定時間経過した場合、又はセキュリティが確保できなくなった場合に、データを消去することで、重要なデータの流出等を防止することができる。なお、上記においては、テキストデータのすべてを消去する場合について説明したが、これに限らず、ステップＳ２６２では、最重要のデータのみを消去することとしても良い。例えば、領域Ａのデータと領域Ｏのデータのみを消去することとしても良い。

なお、図２４の処理では、ユーザ（携帯型端末１０）が初めから会社外に存在しているときには、変換データを表示部１４上に表示した直後に、フラッシュメモリ２８から消去することとしても良い。

（データの消去処理（その２：音声データの消去））
サーバ側制御部７０では、各音声データに対して、図２５の消去処理を実行する。サーバ側制御部７０は、図２５のステップＳ２７０において、テキストデータ生成部５４が音声データをテキストデータに変換したか（できたか）否かを判断する。ここでの判断が否定された場合には、ステップＳ２８０に移行するが、判断が肯定された場合には、ステップＳ２７２に移行し、サーバ側制御部７０は、音声データを発声した人物名を取得する。ここでは、サーバ側制御部７０は、声紋分析部５５から、発声した人物名を取得し、ステップＳ２７４に移行する。

ステップＳ２７４では、サーバ側制御部７０は、発声した人物がユーザ自身以外であるか否かを判断する。ここでの判断が肯定された場合には、サーバ側制御部７０は、ステップＳ２７６において、テキストデータに変換された音声データを消去する。一方、ステップＳ２７４の判断が否定された場合、すなわち、ユーザ自身の音声データであった場合には、ステップＳ２７８に移行して、所定時間経過後に音声データを消去し、図２５の全処理を終了する。

一方、ステップＳ２７０の判断が否定されてステップＳ２８０に移行した場合には、サーバ側制御部７０は、音声データを再生可能にする。具体的には、サーバ側制御部７０は、携帯型端末１０のフラッシュメモリ２８に対して音声データを送信する。なお、このステップＳ２８０では、音声データがテキストデータに変換できなかったことを、警告部１８を介して、ユーザに警告する。この警告に基づいて、ユーザが、ユーザが携帯型端末１０の入力部１２から音声データを再生する指示を入力した場合、フラッシュメモリ２８に格納された音声データを再生部１６を介して再生する。

次いで、ステップＳ２８２では、サーバ側制御部７０が、フラッシュメモリ２８に送信した音声データ（すなわち再生部１６において再生された音声データ）を消去し、図２５の全処理を終了する。

以上のようにして音声データの消去処理を実行することにより、サーバ５０における音声データの保存量を減らすことができるので、サーバ５０のフラッシュメモリ６４の記憶容量を低減することが可能である。また、ユーザ以外の音声データを、テキストデータ化した直後に消去することで、プライバシーに対して配慮することもできる。

（データの消去処理（その３：タスクの消去））
サーバ側制御部７０では、以下に示すルールに従って、タスクを消去する。
（１）タスクが社外での会議に関するものである場合
この場合、位置検出部２２が検出する現在位置がタスクで特定されている会議開催場所と一致し、かつ時刻検出部２４の検出する現在時刻がタスクで規定されている会議開始時刻を過ぎた場合に、タスクを消去する。なお、現在時刻が会議開始時刻を過ぎているのに、現在位置が会議開催場所と一致していない場合には、サーバ側制御部７０は、端末側制御部３０を介して、警告部１８からユーザに対して警告を発するようにする。これにより、タスクの実行し忘れを抑制することができる。また、これに限らず、例えば、タスクの所定時間前（３０分前など）に、警告を発するようにしても良い。これにより、タスクの実行し忘れを未然に防止することができる。
（２）タスクが社内での会議に関するものである場合
この場合、位置検出部２２としてＲＦＩＤのように会議室に入ったことを検出できるような位置検出部を採用しておき、位置検出部２２が検出する現在位置がタスクで特定されている会議室と一致し、かつ時刻検出部２４の検出する現在時刻がタスクで規定されている会議開始時刻を過ぎた場合に、タスクを消去する。この場合にも、上記（１）のように警告を併用することができる。
（３）タスクが買い物に関するものであり、買い物をする場所が特定されている場合
この場合、位置検出部２２が検出する現在位置がタスクで特定されている場所と一致し、かつ、「ありがとうございました」などの音声が音声入力部４２から入力されたり、あるいはＰＯＳレジ端末から購入情報が入力部１２に無線等で入力された場合に、タスクを消去する。なお、ＰＯＳレジ端末からの入力以外に、例えば、携帯型端末が電子マネー機能を有している場合には、当該機能により支払いを済ませた段階で、タスクを消去することとしても良い。
（４）その他、タスクにおいて時間が特定されている場合
この場合、時刻検出部２４の検出する現在時刻が、タスクで規定されている実施時刻を過ぎた場合に、タスクを消去する。

以上説明したように、本実施形態によると、情報が入力される通信部５２と、通信部５２に入力されたデータから所定のキーワードを抽出する抽出部５８と、抽出部５８により抽出したキーワードを守秘性レベルが「高」のキーワードと守秘性レベルが「中」のキーワードとに分類する分類部６０と、守秘性レベルが「高」のキーワードを所定の変換方法で変換するとともに、守秘性レベルが「中」のキーワードを守秘性レベルが「高」のキーワードとは異なる変換方法で変換する変換部６２と、を備えている。このように、守秘性レベルに応じてキーワードを分類し、それぞれのレベルに応じて異なる変換を行うことで、守秘性レベルを考慮したデータの表示等を行うことが可能となる。これにより、使い勝手の向上を図ることが可能となる。

また、本実施形態では、携帯型端末１０と通信する通信部５２が、変換部６２で変換した結果を携帯型端末１０に送信するため、携帯型端末１０では、データの処理を行わなくとも、守秘性レベルが考慮されたデータを表示等することができる。

また、本実施形態では、音声データからテキストデータを生成するテキストデータ生成部５４を備えており、抽出部５８は、テキストデータ生成部５４で生成したテキストデータからキーワードを抽出することとしているので、キーワードの抽出を簡易に行うことができる。

また、本実施形態では、キーワードをイニシャル変換することとしているので、キーワードごとに特別な変換テーブルを作成しなくても、各キーワードを簡易に変換することができる。また、キーワードが氏名の場合、守秘性レベルが「高」であれば、氏と名の両方をイニシャルに変換し、守秘性レベルが「中」であれば、氏と名のいずれか一方をイニシャルに変換することとしているので、守秘性レベルに応じた表示を行うことが可能となる。更に、キーワードが地名の場合、守秘性レベルが「高」であれば、所定の区域の情報（広い範囲内での位置情報）に変換し、守秘性レベルが「中」であれば、所定の区域よりも狭い区域の情報（狭い範囲内での位置情報）に変換することとしているので、この点からも、守秘性レベルに応じた表示を行うことが可能となる。

また、本実施形態では、位置情報を検出する位置検出部２２と、入力を行う入力部１２と、入力に関連した情報を表示する表示部１４と、位置検出部２２が検出した位置に応じて、表示部１４への表示を制限する端末側制御部３０と、を備えている。このように、位置に応じた表示制限を行うことにより、セキュリティを考慮した表示を行うことができ、ひいては使い勝手の向上を図ることが可能となる。

また、本実施形態では、端末側制御部３０は、位置検出部２２の出力に基づいてセキュリティが保たれないと判断した際に、表示部１４への表示を制限することから、セキュリティを適切に考慮した表示制限を行うことができる。また、本実施形態では、位置検出部２２の出力に基づいてセキュリティが保たれると判断した際に、表示部１４への表示の制限の少なくとも一部を解除するので、この点からも、セキュリティを適切に考慮した表示制限を行うことができる。

また、本実施形態のパーソナルアシスタントシステム１００が、上記のようにセキュリティを考慮した表示制限を行う携帯型端末１０と、携帯型端末１０から入力されたデータの少なくとも一部に表示制限を加えるサーバ５０と、を備えているので、携帯型端末１０で、データの少なくとも一部に表示制限を加えなくても、携帯型端末１０の表示部１４に表示制限が加えられたデータを表示することができる。これにより、携帯型端末１０での処理負担を軽減することができ、結果的に携帯型端末１０の簡素化、及び小型・軽量化等を図ることが可能となる。

また、本実施形態では、テキストデータを表示する表示部１４と、音声を入力する音声入力部４２と、音声の声紋を分析する声紋分析部５５の解析結果に応じて前記音声に関連する情報を前記表示部に表示させる端末側制御部３０と、を有しているので、図４のステップＳ１００のように、ある人が、例えば「おはよう」などの声を発したときに、その人の情報（名前や、その他登録されている情報、あるいはその人に対して行うべきタスクなど）を表示部１４に表示することができる。これにより、ユーザは、声を発した人を忘れてしまっていた場合でも、表示部１４を見ることで、その人を思い出すことが可能となる。このように、本実施形態によれば、使い勝手の良いパーソナルアシスタントシステム１００及び携帯型端末１０を提供することができる。

また、本実施形態では、端末側制御部３０及びサーバ側制御部７０は、声紋分析部５５の分析結果に応じて音声データに含まれる所定のワード（例えば、「あの件」や「北海道の件」など）に関連する情報を、表示部１４に表示させるので、「あの件」や「北海道の件」などの曖昧な問いかけをされた場合でも、表示部１４を確認することで、当該用件を思い出すことが可能となる。本実施形態では、この点からも、使い勝手の良いパーソナルアシスタントシステム１００及び携帯型端末１０を提供することができるといえる。また、本実施形態では、所定のワード（「北海道の件」など）に関連する情報を、所定のワード（例えば「北海道」などのワード）とともに入力部に入力された頻度に応じて選択し、表示部１４に表示する（図４のステップＳ１０４）ので、適切な情報表示が可能となる。

また、図４のステップＳ１０４では、音声データが入力されたときの位置に応じた情報を表示部１４に表示させるようにもしているので、この点からも適切な情報表示が可能である。

また、図４のステップＳ１０４では、音声データが入力された時刻に応じた情報（音声データが入力された時刻から所定時間内に入力された情報など）を表示部１４に表示させるようにもしているので、この点からも適切な情報表示が可能である。

また、本実施形態では、音声を入力する音声入力部４２と、音声入力部４２に入力した音声データに基づいてテキストデータを生成するテキストデータ生成部５４と、音声入力部４２に入力した音声データの声紋データを分析する声紋分析部５５と、声紋分析部５５による分析結果に応じてテキストデータ生成部５４によりテキストデータが生成された後の音声データを消去する消去部７６と、を備えている。これにより、テキストデータが生成された後の音声データを消去することで、フラッシュメモリ６４に必要な記憶容量を低減することができる。また、本実施形態では、声紋分析部５５による分析結果に応じて音声データを消去するため、ある特定人物の音声データを消去することにより、プライバシーに配慮した良好な使い勝手を実現することが可能となる。

また、本実施形態では、情報が入力される通信部５２と、通信部５２に入力されたデータから所定のキーワードを抽出する抽出部５８と、抽出部５８により抽出したキーワードを守秘性レベルが「高」のキーワードと守秘性レベルが「中」のキーワードとに分類する分類部６０と、守秘性レベルが「高」のキーワードを所定の変換方法で変換するとともに、守秘性レベルが「中」のキーワードを守秘性レベルが「高」のキーワードとは異なる変換方法で変換する変換部６２と、を備えている。このように、守秘性レベルに応じてキーワードを分類し、それぞれのレベルに応じて異なる変換を行うことで、守秘性レベルを考慮したデータの表示等を行うことが可能となる。

また、本実施形態では、声紋分析部５５は、音声データの声紋データが、登録されたユーザの声紋データであるか否かを解析し、消去部７６は、ユーザ以外の音声を消去するので、フラッシュメモリ６４の記憶可能な記憶容量を効果的に低減するとともに、プライバシーへの配慮をより高めることができる。

また、本実施形態では、消去部７６は、ユーザの音声とユーザ以外の音声とで、分析後、消去するまでの時間を異ならせている（ステップＳ２７６、Ｓ２７８）。これにより、ユーザの音声も所定時間後に消去するので、記憶容量の低減を更に図ることができる。

また、本実施形態では、テキストデータ生成部５４が音声データからテキストデータを生成できない場合に、警告部１８が警告を発するので、ユーザは、音声データからテキストデータを生成できなかったことを認識することができる。また、テキストデータ生成部５４が音声データからテキストデータを生成できなかった場合（ステップＳ２７０が否定された場合）に、ユーザの指示に応じて、再生部１６が音声データを再生するため、ユーザは、テキストデータにできなかった内容を音声データの再生で確認することができる。

また、本実施形態によると、表示を行う表示部１４と、音声を入力する音声入力部４２と、前記入力した音声の大きさ、周波数および意味の少なくとも１つに基づいて重み付けを行う重み付け部５６と、音声入力部４２が入力した音声と、重み付け部５６の重み付けとに基づいて、表示部におけるタスクの表示態様を変更する制御部７０、３０と、を備えている。これにより、音声データの入力され方や音声データの内容等に応じて重み付け部５６が行った重み付けに基づいて、表示部１４におけるタスクの表示態様を変更するので、音声データの重み（重要度）に応じた表示態様を実現できる。これにより、使い勝手の向上を図ることが可能である。

また、本実施形態によると、重み付け部５６は、少なくとも音声データの周波数を用いて、音声を発した人を特定し、当該人（本実施形態では役職）に応じた重み付けを行うこととしているので、音声データの重要度に関する適切な重み付けを行うことができる。

また、本実施形態によると、重み付け部５６は、音声の意味に基づく守秘性に応じた重み付けを行うこととしているので、この点からも、音声データの重要度に関する適切な重み付けを行うことができる。

また、本実施形態では、音声入力部４２から入力された音声に日付情報が含まれている場合に、該日付情報に基づいてタスクの表示を行うこともできるため、通常の予定表としての機能も満足することができる。また、本実施形態では、時刻検出部２４において検出される時刻に関する情報を考慮して、又はカレンダ部２６の日付情報を考慮して、タスクの表示を行うタスクの表示を行うため、現在の時刻に近い順又は現在の時刻から遠い順などの順番で、行うべきタスクを表示することが可能となる。

また、本実施形態では、音声入力部４２から入力された音声をテキストデータに変換するテキストデータ生成部５４を備えているので、重み付け部５６は、テキストデータに対する重み付けを行うことができる。これにより、音声データを扱う場合よりも簡易に重み付けを行うことができる。

また、本実施形態では、表示順序や、色、表示サイズ、表示フォントなどを重み付け結果に基づいて変更するので、重み付け結果を様々な方法で表現することができる。

また、本実施形態では、位置を検出する位置検出部２２の出力に応じて、表示部への表示態様を変更する、すなわち、現在位置に基づいて、タスクを実行したと判断されるような場合に、そのタスクを表示しない（削除する）ようにすることとしているので、記憶容量の低減を図ることが可能である。

更に、本実施形態では、音声データに定型ワードが含まれているか否かに基づいて、タスクか否かを判断し、この判断結果を用いて、表示部１４への表示をするか否かを決定するので、タスクか否かを自動的に判別することができるとともに、表示部への表示を行うか否かも自動的に決定することができる。

また、本実施形態では、重み付けをユーザが設定することを可能にするために、サーバ５０に設定部７４が設けられているので、ユーザは、自己の好みに応じた重み付けに関する設定を行うことが可能である。

また、本実施形態によると、音声を入力する音声入力部４２と、入力した音声をテキストデータに変換するテキストデータ生成部５４と、音声入力部４２が特定の周波数を入力した際に、テキストデータ生成部５４による変換を開始、すなわち録音を開始し、テキストデータへの変換を開始するサーバ側制御部７０と、を備えている。したがって、ある人物が発声して、特定の周波数の音声が入力された場合に、その音声の入力に基づいて、録音、テキストデータへの変換を開始するので（図２（ａ）参照）、自動で、録音、テキストデータへの変換を開始することができる。これにより、ユーザの操作が簡素化され、使い勝手の向上を図ることが可能となる。

また、本実施形態では、音声入力部４２が電話に関連した周波数を入力した際にテキストデータへの変換を開始することもできるため、例えば、電話の着信音がなった時点から、電話の音声を録音し、テキストデータへの変換を行うことが可能となる。これにより、電話での会話を漏らすことなく録音、テキストデータへの変換をすることができる。

また、本実施形態では、タスクに基づいて、例えば会議の日時になったときなどの適切なタイミングで録音やテキストデータへの変換を開始することができるので、この点からも、ユーザの操作を簡素化することができ、使い勝手を向上することが可能となる。また、例えば会議の終了時刻に応じて録音やテキストデータへの変換を行うこともできるので（図２（ｃ）参照）、会議において最も重要なことが話される可能性がある時間帯の音声データの録音及びテキストデータへの変換を自動的に開始することが可能となる。

また、本実施形態では、ユーザの生体情報に基づいて、適切なタイミングで録音やテキストデータへの変換を開始することができるので（図２（ｄ）参照）、この点からも、ユーザの操作を簡素化することができ、使い勝手を向上することが可能となる。

更に、本実施形態では、現在時刻が、予め定めておいた時刻になったときに、録音やテキストデータへの変換を開始することができるので（図２（ｂ）参照）、この点からも、ユーザの操作を簡素化することができ、使い勝手を向上することが可能となる。

また、本実施形態では、位置検出部２２の検出結果に応じて、テキストデータ生成部５４による変換を禁止することができるため、例えば、社外の会議など、録音することに問題があるような場合に、録音を自動的に禁止することができる。これにより、より使い勝手を向上することが可能となる。

なお、上記実施形態では、ワードごとに、守秘性の高低を決める場合について説明したが、これに限られるものではなく、例えば、分類部６０では、ビジネスで用いるワードを守秘性レベルの高いワード、プライベートで用いるワードを守秘性レベルの低いワードというように分類しても良い。

なお、上記実施形態では、携帯型端末１０の位置検出部２２で検出された現在位置が、セキュリティが保たれない位置であったときに、キーワードを変換して表示する場合、すなわち、表示部１４における表示が制限される場合について説明したが、これに限られるものではない。例えば、時刻検出部２４において検出された時刻が所定時刻（例えば勤務時間内）であった場合に、表示部１４における表示が制限されるようにしても良い。このようにしても、上記実施形態と同様、セキュリティを考慮した表示を行うことが可能となる。なお、このような制御を行う場合には、図１９のステップＳ２０６において、ユーザの現在位置を取得する代わりに、現在時刻を取得し、ステップＳ２０８においてセキュリティ確保可能な場所か否かを判断する代わりに、セキュリティ確保可能な時刻か否かを判断するようにすれば良い。

なお、上記実施形態では、音声データがタスクか否かの判定を、日時情報の有無、及び音声データの語尾の種類に基づいて行うこととしたが、これに限らず、例えば、音声データの抑揚に基づいて、タスク判定を行うこととしても良い。

なお、上記実施形態では、守秘性レベル「高」のワード及び「中」のワードを、その上位概念であるイニシャルに変換する場合について説明したが、これに限られるものではない。例えば、キーワードＤＢにおいて、各ワードに対する変換後のワードを定義しておいても良い。この場合、例えば、キーワード「カメラ」に対する変換後のワードとして、カメラの上位概念である「精密機器」やそれよりも下位概念である「撮影装置」などを定義しておくことができる。この場合、「カメラ」が守秘性レベル「高」であれば、「精密機器」と変換し、「カメラ」が守秘性レベル「中」であれば、「撮影装置」と変換するなどすることができる。このように、守秘性レベルに応じて、上位概念のワードと中位概念のワードに変換することで、セキュリティレベルを考慮した表示を行うことができる。また、キーワードＤＢにおいて、予算などの金額情報が登録される場合、当該金額情報の上位概念である桁数で表現したものを定義しておいても良い。

なお、上記実施形態では、音声が日本語の場合について説明したが、例えば英語などの外国語であっても良い。外国語（例えば、英語）では、所定の単語の有無や、所定の構文の有無に基づいてタスクか否かを判断することとしても良い。

なお、上記実施形態では、携帯型端末１０の小型・軽量化を図るため、フラッシュメモリ２８を搭載する場合について説明したが、これとともに又はこれに代えて、ハードディスクなどの記憶装置を携帯型端末１０に搭載することとしても良い。

なお、上記実施形態では、会社の位置などの設定を行う際に、携帯型端末１０を外部のＰＣに接続し、外部のＰＣ上で設定を行う場合について説明した。しかしながら、これに限られるものではなく、例えば、サーバ５０のハードディスク６６に予め会社の位置を登録しておき、そのハードディスク６６から、会社の位置をダウンロードしても良い。また、例えば携帯型端末１０に会社の位置などを設定するためのアプリケーションをインストールしておくことで、携帯型端末１０上で、会社の位置などの設定ができるようにしても良い。

なお、上記実施形態では、タスク優先度を上式（１）に基づいて算出することとしたが、これに限らず、その他の式を用いて、タスク優先度を算出しても良い。例えば、各重みを加算したり、あるいは乗算したりするのみでも良い。また、上式（１）などを用いてタスク優先度を求める場合に限らず、重みのうちのいずれかを選択し、その選択された重みの大きい順にタスク優先度を決定しても良い。この場合、どの重みでタスク優先度を決定するかをユーザが設定できるようにしても良い。

なお、上記実施形態では、キーワードをイニシャル化したもの（例えばソフトウェアにおける「ＳＷ」）と、イメージに基づくもの（例えばソフトウェアにおける「スポンジ」）のうち、イニシャル化したものの方を最初に表示する場合について説明したが、これに限らず、イメージに基づくものを最初に表示することとしても良い。また、イニシャル化したものとイメージに基づくものを同時に表示しても良い。

なお、上記実施形態では、ユーザ以外の人の音声が入力部１２に入力されたときに、当該発声者の名前や情報が表示される場合について説明したが、これに限らず、例えば、発声者の顔写真など、発声者に関する画像を表示するようにしても良い。この場合、例えばサーバ５０のハードディスク６６にそれら画像を格納しておき、かつ当該画像を、キーワードＤＢの情報の項目に登録しておく必要がある。

なお、上記実施形態では、重みとして、ユーザとの親密度を用いることとしても良い。この場合、例えば、音声が比較的多く入力される人物や、携帯型端末を持っている人のうち、接近する機会が多い人物などを、親密度の高い人物とすることができる。

なお、上記実施形態で説明した構成は一例である。すなわち、上記実施形態で説明したサーバ５０の構成の少なくとも一部を携帯型端末１０側に設けることとしても良いし、上記実施形態で説明した携帯型端末１０の構成の少なくとも一部をサーバ５０側に設けることとしても良い。具体的には、例えば、サーバ５０の声紋分析部５５やテキストデータ生成部５４などを携帯型端末１０に持たせることとしてもよい。

なお、上記実施形態では、本発明をビジネス用として用いる場合を中心に説明したが、プライベートで用いることとしても良いし、あるいは、プライベートとビジネスの両方で用いることとしても勿論良い。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１０…携帯型端末、１２…入力部、１４…表示部、１６…再生部、１８…警告部、２０…生体情報入力部、２２…位置検出部、２４…時刻検出部、２６…カレンダ部、２８…フラッシュメモリ、３０…端末側制御部、３２…通信部、５０…サーバ、５２…通信部、５４…テキストデータ生成部、５５…声紋分析部、５６…重み付け部、５８…抽出部、６０…分類部、６２…変換部、６４…フラッシュメモリ、６６…ハードディスク、７０…サーバ側制御部、７２…変更部、７４…設定部。

Claims (1)

1. 情報を表示する表示部と、
   音声を入力する入力部と、
   前記音声の声紋を解析する解析部の解析結果に応じて前記音声に関連する情報を前記表示部に表示させる制御部と、
   を有することを特徴とする情報処理装置。

Images