以下、本発明の各実施の形態による実世界コミュニケーション管理技術について、図面を参照しつつ説明を行う。本明細書において、情報処理装置は、パーソナルコンピュータ(PC)、携帯端末(携帯電話機を含む)などを含む広い概念である。
まず、本発明の第1の実施の形態による実世界コミュニケーション管理技術について説明する。
本実施の形態による発話通知装置である情報処理装置は、ユーザの発話を検知する発話検知手段と、この発話検知手段によってユーザの発話が検知された際に、ユーザの発話を近接する他の端末に通知する発話通知手段とを備えている。上記発話通知手段が通知する情報は、発話者を識別する発話者識別子を含むことを特徴とする。発話者識別子を含むことにより、「誰に」話しかけられたのかについて、装置は認識することができる。
各ユーザは上記情報処理装置を常時携帯する。この情報処理装置を携帯する監視対象ユーザが発話を行うと、上記発話検知手段によってユーザの発話が検出される。実際の発話の検出方法には様々な手法が考えられるが、典型的な周知の手法として、マイクを用いて監視対象ユーザの音声を検出する方法がある。ここで他者の発話や環境音などのノイズの分離が課題となる場合もあるが、音量レベルなどで適切にフィルタリングすることによって、高精度に監視対象ユーザの発話を検出することは可能である。ピンマイクなどを監視対象ユーザが身につけるだけでも、実用的な精度で発話を検出できる。
さらにカメラによる周囲の画像の取得、声帯振動の検知、声紋分析などを組み合わせることで、発話検知の精度を上げることも可能である。尚、発話時にはユーザが何らかのボタンを押すなどして、発話をシステムに通知してもよい。発話検知の方法に関しては、上記の記載は単なる例示であり、公知の様々な方法を用いることが可能である。
情報処理装置は、発話を検出すると近接するユーザ(実際にはユーザが携帯している携帯端末)に対してその発話の発生を通知する。本来、発話の通知は、発話者が発話を行っている対象のユーザのみに行うことが望ましい。しかしながら、コンピュータが対話相手を特定することは通常困難であるし、発話内容はその場に居合わせている他人にも傍受可能である。そこで、本実施の形態においては、発話ユーザに近接するすべてのユーザに対して発話の通知を行う。本明細書における「近接」とは、ユーザの発話の音声が届く(記録可能である)範囲のことを指す。
発話の通知に関しては、さまざまな方法が考えられるが、たとえば近距離無線通信を用いて、通信範囲内の任意の端末に対して、発話を通知するメッセージを送信することで、通知を行うことが考えられる。発話の通知は、対話相手にさえ届けばよいため、通信半径は一般的な対話における平均的な距離である1〜2m程度が適当である。但し、拡声器などにより音量が上がっている場合には、通知領域は広くなるべきであるし、ひそひそ声の場合には通知領域は狭くなるべきである。従って、発話音量レベルとの関連において通知領域の大きさは可変となる。実際には発話音量レベルを検出し、それに応じて通知領域の大きさを変更する仕組みを備えても良い。
図2は、本実施の形態による発話通知において、無指向性の近距離無線通信システムを用いた場合の概念図である。図2に示すように、本実施の形態による無指向性の近距離無線通信システムにおいては、例えばA〜Fまでの6台の端末が存在している場合を考える。端末A201と端末D204、端末C203と端末F206が、それぞれ対話を行っている。矢印で示すように、端末B202、C203、F206は、図2の上方に向かって移動している。ここで、端末A201のユーザが発話をしたとする。その場合、端末A201は自己の発話通知領域内に存在する端末に対して、発話を通知する。ここで、発話通知領域内の端末B202と端末D204がその通知を受信し、端末A201が発話したことを知る。一方、端末C203、E205、F206は端末A201の発話通知領域外に存在するため、端末A201の発話を認識することができない。
図3は、本実施の形態において、発話通知に指向性の近距離無線通信システムを用いた場合の概念を示す図である。この場合、端末A301の発話通知領域内に存在するのは端末D304だけとなり、端末B302は領域外の端末となる。一般的に、発話は対話相手の方向を向いて行われることが多いという事実を考慮すると、発話通知はユーザが向いている方向に向けて行われることが望ましい。この場合には、発話通知領域AR2は、図に示すように扇型になる。
さらに、前述のように、発話通知半径を音声レベルに応じて調整することができれば、コミュニケーション相手ではない端末に対しては極力発話通知を行わずに、コミュニケーション相手だけに発話通知を行うことが可能になる。
一方、ユーザが通信路を介して遠距離発話を行っている場合には、発話者識別子を含む発話通知も通信路を介して、受話者に送信される必要がある。発話通知は、発話の伝達に利用される通信路を介して送信されてもよいし(図25A)、別の通信路を介して送信されても良い(図25B)。たとえば電話回線を介して発話者と受話者が会話をしている場合、発話者の発話は電話回線を通して受話者まで到達するが、発話通知は電話回線を通して送信してもよいし、インターネット網などの他のネットワークを通して送信しても良い。他の通信路を利用することができれば、発話を伝達する通信路が、発話通知の伝送を認めない場合でも、発話通知を受話者に伝達することが可能になる。通信路を介した遠距離発話の場合、通信路の状態によっては、発話通知の伝達が話に比べて遅延する状況が発生することが考えられる。そこで発話とその発話通知を関連付けるため、発話通知には発話発生時刻などの発話を特定するための情報が含まれていることが望ましい。
発話の通知を行うパケットには、発話者を識別する発話者識別子(発話者ID)が付加される。発話者を識別できれば良いので、氏名やニックネームなどを利用しても良いが、プライバシ保護を考慮すると英数字の羅列などの機械的なIDのほうが望ましい。その場合、各ユーザはこの発話者IDをある期間使い続けることができるが、任意のタイミングで新たな発話者IDを取得することもできる。同じ発話者IDを長時間使い続けると、第三者によって行動を追跡される可能性が大きくなるため、インターネットにおけるcookieのように定期的にリフレッシュするのが好ましい。無論、固有の発話者IDを長期間使い続けることも可能である。
このように、発話者の発話と同期して、その発話という事象の発生と、発話者を示す発話者IDとを、発話を聞いている受話者(の所有する端末)に通知することができる。従って、「誰に」話しかけられているのかに関して受話者(の所有する端末)が認識することが可能になる。
次に、本発明の第2の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、発話を識別する発話識別子(発話ID)を割り当てる発話識別子割当手段を有し、上記発話通知手段が通知する情報は、この発話IDを含むことを特徴とする。この発話IDは上記の発話者を識別する発話者識別子(発話者ID)を内包していても良い(具体例については後述する)。
発話IDは継続する発話に対して一意に割り当てられる。ここで述べる継続する発話とは、同一の発話者によって行われる時間的に連続する発話のことを指す。継続する発話の検出方法としては、例えば、発話の検出が中断して、閾値(たとえば0.5秒)以上の時間、新たな発話が検出されなければ、そこで一連の発話は完了したと判断することができる。ただし、本明細書においては、特に区別する必要の無い限り、「継続する発話」を単に「発話」と表記することにする。
ここで継続する発話という定義は、例えば、「おはようございます」という発言があった場合に、「O-HA-YO-U-GO-ZA-I-MA-SU」という音韻ごとに発話IDを振るのではなく、それ全体に一つの発話IDを割り当てることを意図したものである。もちろん音韻ごとに個別にIDを振ってもよいが(上記の例で閾値を極端に小さくすれば、発話IDは細かく振られる)、煩雑さを避けるためには全体に一つの発話IDを割り当てるのが好ましい。すなわち、発話IDは、発話のまとまりごとにIDを振ることを意味し、そのまとまりの意味は任意である。
ある発話者の発話を受けて、別の発話者が発話を行うと対話が成立する。発話は、「おはようございます、○×さん」程度の長さが一般的である。それに対し、対話は、「おはようございます、○×さん」「おはようございます。今日もいい天気ですね」「そうですね。洗濯ものがよく乾いて嬉しいです」…と続くひとまとまりとして定義することができる。ある発話の継続中に、他者の発話が割り込んで発話が中断したり、一方で他者の発話の割り込みにもかかわらず、発話は中断せず継続したりすることもある。特に多人数における対話を考えると、各人の発話は、時間的に重複することが多い。対話を構成する発話が終了して、ある閾値(例えば3秒)以上の時間、発話が再開されなければ、そこで対話は完了したと判断することができる。
図8は、ユーザA、B、Cによる対話の例を示す図である。横軸が時間軸であり、この時間軸上の発話と記されている矩形はその時間だけユーザによる発話が行われたことを示している。それぞれの発話には、発話IDが付加される。本実施の形態による例では、発話IDは発話者IDを含み、発話IDを見れば、どのユーザの発話か分かるようになっている。例えば、ID:A01はユーザAによる発話であることを示す。
まずユーザAが発話ID:A01で識別される発話を開始し、発話ID:A01の終了後、Δt1後に、ユーザBおよびCがそれぞれ発話ID:B01、C01を同時に開始している。発話が衝突したことに気がついたユーザCは発話を中断し、ユーザBのみが発話を継続し、発話ID:B01の終了後、Δt2後に改めてユーザCが発話ID:C02を開始している。ここで、それぞれの発話の中断時間Δt1、 Δt2、 Δt3に関しては、対話の区切りの判別基準となる閾値を超えておらず、Δt4のみが閾値を超えている。従って、発話ID:A01、 B01、 C01、 C02、 A02をひとまとまりの発話群、すなわち対話として扱うことができる。発話ID:C03とそれに続く発話(図示されていない)は別の対話に分類される。本実施例では、対話を単純に時間的ギャップの大小に基づいて判別しているが、本来は発話内容により判別できることが望ましい。また、対話への参加者の変化、位置の移動などからも対話の区切りを判別することができる。
ここで、一連の発話に発話IDが付加されるため、後日その発話を参照する場合などに、そのIDを用いることができる。たとえば、あるユーザが「今年のボーナスは10か月分支給することを約束します。」と発言したとして、その一連の発話に発話ID:KJ3002-200503241923が付加されたとする。後日、実際には2か月分のボーナスしか支給されなかったことに憤った社員が、発話ID:KJ3002-200503241923を引用した上で、「先日このように仰いましたが、あの約束はどうなりましたか?」と主張することができる。発話IDは、その発話が発生したときに近接するユーザに対して通知されているので、その発話を聞いた人はその発話を特定することができる。発話IDと関連付けて発話を録音しておけば、発話IDの引用時に録音内容を関連付けて提示することも可能である。
次に、本発明の第3の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置において、発話通知手段は、発話が継続している間、間欠的に発話通知を行う。発話は時間的に継続するので、通常、発話通知も時間的に継続して行われる必要がある。図13は発話の継続と発話通知とのタイミングを示す図である。
図13(A)は、ユーザが発話を開始したときに発話通知が発信される例を示している。ここで発話者ID:S125753をもつユーザは、時間tsからteにかけて発話を行っている。その発話には、発話ID:200503241923が付加されている。このように発話開始時に一度だけ発話通知を行う方式では、発話が継続中に途中から会話に入ってきた人(発話通知領域内に移動してきた人)には発話通知が送信されないことになる。そのため、途中参加者(のもつ端末)は、その発話を検知することができない。各発話が短時間で終了する場合にはそれほど大きな問題にならないが、長時間にわたる発話を行う場合には、問題になる場合もある。図示していないが、発話終了時に一度だけ発話通知を送信しても良い。この場合は、発話開始時に送信する方法と比較して、発話の継続時間を併せて送信することができるというメリットがある。
図13(B)は、発話の開始時と終了時とに、それぞれ発話開始通知と発話終了通知とを発信する例である。この例では、発話終了と同時に発話終了通知が送信されているが、一定時間以上の発話の中断をもって発話終了と判断する場合には、少なくとも待機時間分のタイムラグが生じる。発話開始通知と発話終了通知とを両方受け取った人は、その発話(この例の場合、発話ID:200503241923の発話)を聞いたとみなすことができる。一方、どちらか一方の発話通知しか受け取らなかった人は、その発話の一部を聞いたとみなすことができる。ただし、先の例と同様に長時間にわたる発話の場合には、発話の途中で参加し、発話が終了するまでに去った人は、発話通知を受けられないという問題がある。
図13(C)は、発話の継続中、一定時間ごとに発話通知を発信している例である。この場合、発話の途中から参加した人も発話通知を受け取ることができる。発話において送信される各発話通知に通し番号を付加しておけば、発話のどの割合を聞くことができたか知ることができる。図13(C)では発話通知が途絶えることで発話終了と認識することを想定しているが、図13(D)に示すように発話終了通知を発話終了時に発信するようにしても良い。このようにすると、発話検知漏れを防ぐことはできるが、通信量が増大するという問題が生じる。平均的な発話継続時間から発話通知の発信間隔t0を適切に調節する必要がある。ユーザが移動していない場合には発話間隔t0を大きくして、通信量を減らすこともできる。また、発話者識別子に関してもすべての発話通知で通知するわけではなく、適当に間引く(たとえば2回に1回だけ送信する等)ことも可能である。
尚、図13(A)は図13(C)においてt0が発話継続時間よりも長い場合、図13(B)は図13(D)においてt0が発話継続時間よりも長い場合を示していると考えることもできる。
ここに挙げるように発話通知の方式はさまざまなパターンが存在するが、発話の継続時間の長短(長い発話が多い場合には図13(C)や図13(D)の方法が望ましいが、短い発話が多い場合には図13(A)や図13(B)が望ましい)やユーザ移動の有無(ユーザが移動しないのであれば図13(A)や図13(B)のようにしても問題ない)などを勘案して、適応的に選択することが好ましい。
次に、本発明の第4の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置において、他の端末から発信された発話通知を受信する発話受理手段をさらに備え、発話受理手段により受信した他の発話通知を、記録するコミュニケーション記録管理手段を備えることも可能である。発話通知を記録しておくことにより、誰から(Who)話しかけられたのかということを記録することができる。
さらに発話通知手段により通知した自らの発話通知に関してもコミュニケーション記録管理手段において記録するようにすることで、誰に(Who)話しかけたかということも記録することができる。
また、情報処理装置において、発話通知を発した端末に対して、受話通知を返信する受話通知手段をさらに備え、コミュニケーション記録管理手段は、自らの発話通知に対して返信された受話通知を発話通知に関連付けて記録することも可能である。
発話通知を受信した際に、受信端末がユーザID(発話者IDと同一。受話者を示すので特に受話者IDとも呼ぶ)を含む受話通知を返信するようにすれば、その発話が誰に聞かれたのかということも知ることができる。但し、通常の対話において、発話は参加者双方から行われることを考えると、受話通知を導入しなくても発話通知だけでも、ある程度までは対話相手を特定することが可能である。
情報処理装置において、コミュニケーション記録管理手段が管理する発話記録は、発話時刻と対応付けられて管理することができる。時刻情報を含むことにより、いつ(When)話しかけられたのか(話しかけたのか)について機械が認識することが可能になる。もちろん、通知される情報の中に時刻情報が含まれていなくても、通知情報を受け取った時刻を確認すれば良い。
また、情報処理装置において、コミュニケーション記録管理手段が管理する発話記録は、発話場所と対応付けられて管理されることも可能である。場所情報を含むことにより、どこで(Where)話しかけられたのか(話しかけたのか)機械が認識することが可能になる。もちろん、通知される情報の中に場所情報が含まれていなくても、受信端末が現在位置を取得する手段を有している場合にはその情報を使うこともできる。例えば、受信端末はGPSなどを利用して位置を取得することができるし、あるいは環境中に配置されているシビルマーカー等からの位置情報を受信することで、位置を取得することができる。
また、情報処理装置において、発話内容を記録する発話内容記録手段をさらに備え、コミュニケーション記録管理手段は、発話内容記録手段により録音された発話内容も発話通知に対応付けて記録することもできる。会話を録音するマイクやその様子を撮影するカメラがあれば何を(What)どのように(How)話しかけられたのか(話しかけたのか)蓄積することができる。これらの情報は前述の発話IDや発話時刻を手がかりにして、後に参照することができ、会話内容を再確認したり、引用したりすることが可能になる。
但し、発話内容を記録した録音データや録画データをそのまま保持している必要は無く、音声認識や、意味解析が利用可能であるならば、発話内容をテキスト化したり、要約したり、キーワードを付加したりすることもできる。例えば、発話に頻繁に出現するキーワードを抽出するだけでも、後に検索する場合などに有用である。
一方で、一人の人間が一生のうちに処理するデータ量は高々Pbit(Pは1015)のオーダという研究結果もあり、全ての発話記録を圧縮してコンピュータに蓄積することも不可能ではないし、10数年後には当たり前になっている可能性もある。
2005年現在、個人が所有するPCのHDDの最大値は1TB(=1,000GB)程度だと思われる。1PBは1,000TBなので、記憶容量が1,000倍になれば一生の出来事すべてを記録できる。HDDの容量は毎年2倍弱ぐらいのペースで伸張しているので、同じペースが維持できれば10数年で必要な容量がまかなえる計算になる。適切に圧縮すれば、より小さな容量でもすべての記録は可能だと思われる。
図15は、発話記録を管理する表の一例を示す図である。各発話には、発話ID1501、発話者1502、受話者1503、発話時刻1504、発話場所1505、発話継続時間1506、発話内容を記録した音声ファイル1507、がそれぞれ関連付けられて記録されている。発話ID1501は発話に機械的に割り当てられる一意のIDである。発話者1502は発話通知に含まれる発話者のIDから知ることができる。図15では、後述するユーザ名取得手段によって、既知のIDに関しては対応するユーザ名を取得し、IDの代わりに記述している。発話時刻1504や発話場所1505に関しては、前述のように発話通知に記述されていても良いし、端末が備える別の手段により取得しても良い。発話継続時間1506は発話開始時刻と終了時刻とから求めることができる。発話内容を記録した音声ファイルは、発話の継続中稼動するマイクによって記録された音声を含む。詳細については、後述する実施例において説明する。
ここで、受話者が取得できているのは、前述の受話通知を導入しているからであり、受話通知を利用しない場合には、受話者の取得は行えない。しかしながら、対話が継続している間の発話者を発話通知によって知ることにより、受話者を推測することは可能である。
次に、本発明の第5の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置は、発話記録に電子署名を施す電子署名手段を有する。すなわち、発話の引用に証拠能力を付与するために、発話の参加者による合議印的な電子署名を付加することもできる。
図14は、ユーザA1411とユーザB1415との間で交わされた対話記録に付加される電子署名の例を示す図である。対話記録1403には、対話時刻、対話場所、対話の参加者(対話者)、対話に含まれる発話IDなどが記録される。対話記録はその対話を構成する発話記録を統合することで構成される。対話開始時刻は、対話を構成する最初の発話の発話開始時刻であるし、対話終了時刻は、対話を構成する最後の発話の発話終了時刻である。対話場所は、対話を構成する発話の発話場所を統合したものであって、対話参加者が移動しながら対話をしていた場合には、移動軌跡として示される。対話の参加者は、対話を構成する発話の発話者ということになるが、一切発話をせず聞くだけというユーザも参加者として扱ってもよい(尚,こうしたユーザを認識するためには前述の受話通知を導入する必要がある)。
対話記録には前述の情報に加えて、発話内容を記録したバイナリファイルが付加されても良い。発話内容の録音ファイルが対話記録に含まれれば、きわめて高い精度をもって、その発話が誰によって行われたかを特定することが可能になる。特に証拠能力が求められる場合には、必ず付加することが望ましい。
対話の参加者が、互いに、その時刻、その場所においてその対話が交わされたことを確認した上で、電子署名を施す。ユーザA1411とユーザB1415の両者の電子署名が付加された対話記録を、両者が保持することにより簡易的な証明になる。
より厳密性を期すならば、第三者のタイムスタンプ局(TSA: Time Stamping Authority)によるタイムスタンプを付与することが望ましい。対話への参加者(図14の例ではユーザA1411とユーザB1415)の電子署名が付加された対話記録はTSA1417に送信される。TSA1417は、対話記録のハッシュ値に(1421)タイムスタンプを付与し(1422)、デジタル署名をする(1423)ことで、電子レシートを発行する(1424)。タイムスタンプは、たとえばRFC3161に準拠したものが利用されることが望ましい。電子レシートを付与された対話記録はユーザに返信されるので、それを交互が保持することにより(レシートの原本は、TSA1417が保持する(1425))。その対話が、いつ(When)、どこで(Where)、誰によって(Who)、何を(What)、どのように(How)行われたのかを証明することが可能になる。
情報処理装置において、コミュニケーション記録管理手段に記録されている発話記録を外部に出力する発話記録出力手段を備えることにより、情報処理装置内部に十分な記憶領域が無くても、出力手段を用いて外部に出力することで大量の情報を蓄積できる。外部出力はインターネットや電話網などのネットワークを通じて行っても良いし、不揮発性メモリを利用したUSBメモリやカード型メモリなどの記憶媒体を通じて行っても良い。
以上では、基本的に人間の発話者の発話を検知し、発話通知を行う発話通知装置について述べてきたが、本発明の第5の実施の形態によれば、発話を含むコンテンツを再生するコンテンツ再生装置が、前述の構成と同様の発話通知を行うことができる。
例えば、テレビやラジオなどのコンテンツ再生装置で、出演者が話しているときに、その発話に対応する発話通知をテレビやラジオが行うことができる。発話通知を行うのに必要な発話者識別はコンテンツ再生装置が行ってもいいが、コンテンツに発話者を識別する情報があらかじめ埋め込まれており、コンテンツ再生装置がそれに基づいて発話通知を行うことが望ましい。所定のフォーマットで構成された発話通知そのものをコンテンツに埋め込む、あるいはコンテンツと同様に配信しても良い。発話を行うものが実人間であっても、テレビなどのコンテンツ再生装置であっても、同様の発話通知が送信されることで、それらの記録を分け隔てなく扱うことが可能になる。
さらに発話通知に対応する前述の受話通知をコンテンツ再生装置が受信し、発話者ないしはコンテンツ作成者に転送するようにすれば、発話者やコンテンツ作成者が、発話が誰に聞かれたのか遠隔地からでも知ることが可能になる。転送先のアドレスは受話通知に記述されるが、これは元の発話通知に指定されていることが望ましい。
単に受話通知を転送しているだけで、何も特別なことをしていない。受話通知には送信先のアドレスが含まれるので、別にこのコンテンツ再生装置を通さなくても、別の手段(インターネットなど)を介して普通に送信できる。しかしながら、近くにあるネットワークに接続された通信可能なコンテンツ再生装置に、受話通知を転送する機能を付与するのが好ましい。送受信される発話通知、受話通知などの特性は前述の構成と変わらないため、説明を省略する。
次に、本発明の第6の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、発話者を識別する発話者識別子と発話の発生時刻とを含む発話記録を管理するコミュニケーション記録管理手段と、前記コミュニケーション記録管理手段に管理されている時間的に近接する発話記録を、対話記録としてグループ化する発話統合手段を有し、前記発話統合手段により生成された対話記録の一部または全部を、対話発生時刻に基づき時系列に並べてユーザに提示することを特徴とする。
本実施の形態による情報処理装置においては、コミュニケーション記録提示手段は、コミュニケーション記録管理手段に記録されている発話記録において時間的に近接する発話を対話としてグループ化する。会話による対人コミュニケーションを考えた場合、対話はいくつかの発話のやりとりによって構成される。対話にはひとつないし複数の話題があり、その話題に対して、対話への参加者による発話が交互に行われる。発話記録の管理においては、個々の発話単位でなく、意味的・時間的まとまりである対話単位で行うことが、煩雑さを避けるうえでも望ましい。
図19は、夏目漱石の「こころ」の一節であり、図22は、これに対応する対話記録である(発話時刻など原作に含まれていない情報に関しては、説明のために例として追記した)。引用した節では「私」と「先生」との合計9つの発話が存在する。複数の発話の組み合わせで対話が成立するが、単純に発話間の時間間隔が閾値(たとえば5秒)を越えた時点で区切って対話を認識する場合、
1)対話1(対話ID:TALK01):私発話1+先生発話1
2)対話2(対話ID:TALK02):私発話2+先生発話2+私発話3+先生発話3
3)対話3(対話ID:TALK03):先生発話4+私発話4+先生発話5
の3つの対話が認識できる。
図23(A)は、図22で示した発話記録を対話単位で表した例である。図23(A)においては、対話ID2301と、主な対話者2302と、対話時刻2303と、対話場所2304と、対話継続時間2305と、音声2306と、を含んでいる。
対話継続時間2305は一つの対話ID2301により特定される対話に含まれる最初の発話の開始時刻を最後の発話の終了時刻から減算した時間として算出しているが、個々の発話継続時間を累積しても良い。
図22の単一の発話(たとえばID:T002の先生の発話「いいえ」)だけをあとで参照したとしても意味が分からないが、ID:T002を含む対話2(ID:TALK02図23(A))を参照すると、話の内容を理解することができる。また、発話記録を参照するときに図22のように個別の発話が大量に並んでいるよりも、図23のように対話ごとにグループ化されて表示されている方が内容を理解しやすい。対話の区切り方には多様な方法が考えられる。図23(B)の符号2311〜2316までは、いったん図23(A)のように分類した対話を、対話者が同一で、時間的に連続する(対話間隔が5分未満であり、かつ、間に他の対話が挟まれない)対話同士をさらにまとめて、大対話を形成した例である。
さらに対話記録を時系列で並べることでユーザは直感的に対話記録を閲覧することが可能になる。日付、週、月ごとに分割して表示することも有効である。この情報処理装置において、コミュニケーション記録管理手段に記録されている発話記録に含まれる発話者を識別する発話者IDと対応するユーザ名を取得するユーザ名取得手段を有し、コミュニケーション記録提示手段は、各発話に対応するユーザ名を提示することもできる。
前述のように、IDは必ずしも人間が容易に個人を特定できるように記述されているわけではないため、既知のIDに関しては、ユーザが理解可能な名前やニックネームなどで表示されることが望ましい。プライバシに関する懸念の無い環境(すべての構成員が互いに顔見知りであるオフィスのような環境)では、重複する恐れが無ければ氏名をIDとして使うことも可能だが、パブリックな環境で利用する場合に、自分の氏名を周囲の見ず知らずの他人に発信することは問題が大きい。そのためIDは他人が個人を識別できないような、機械的な英数字の羅列となることが望ましい。
そこで、互いに面識があり、両者が同意した場合には、自分のIDと自分の氏名との対応関係を相手に教える必要がある。情報処理装置は、図18に示すようなID1801と名前1802とから構成されるID変換テーブルを保持しており、既知の(登録済みの)IDに関しては名前に変換してユーザに提示する。プライバシ保護の観点からIDは定期的に変更される場合には、IDには有効期限1803を設定しておく。有効期限を過ぎたIDは消去され、再取得されることが望ましい。ただし、公人などのIDは互いに面識が無くても、公知されるので、消去しなくても良い場合もある。ID情報の受け渡しは、電子名刺の交換時などにあわせて行われることが望ましい。あるいは、ある部署の所属員全員のID情報をまとめて全員に配布することもできる。
図7は電子名刺フォーマットとして最もよく利用されているvCard方式で記述した電子名刺データの例である。名前や所属などの一般的な名刺データに加え、5行目には現在利用しているID(AC2658703552)とその有効期限(20050312)を記述している。ここでは、IDは現在利用中の1つのみを通知しているが、過去に利用したことのあるID一覧も併せて相手に渡せば、過去意外なところで遭っていたことが判明するかもしれない。例えば、以下のような会話が交わされる可能性もある。「あっ、10年前、オーストラリアに旅行に行ったとき、道順を聞いた人ですね?」
「おや、そうでしたか、世間は狭いですなあ(笑)」
ID情報に信頼性を求める場合には、第三者機関による認証が必要になる。各ユーザは自分が使用するIDに認証機関の証明書を添付して配布を行う。証明書はそのIDが確実にそのユーザによって利用されたということを保障するので、当該IDを有する発話記録はそのユーザによる発話であったことが高い信頼性を持って保障される。
一方、プライバシ保護の目的で、既知の(登録済みの)IDをもつ発話通知のみ記録し、未知のIDをもつ発話通知は受信しないという受信側の対応、ないしは、既知の(登録済みの)IDをもつ端末にのみ発話通知を行う送信側の対応を行うこともできる。このようにすると、登録されたユーザの発話のみ記録されることになる。従って、プライバシを保護すると同時に、発話記録におけるノイズ(関係ない第三者の会話記録)を減らすことができる。
次に、本発明の第7の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態の情報処理装置は、コミュニケーション記録提示手段において、対話の参加者のうち、グループ内で頻繁に発話した発話者を、当該対話の代表的な発話者として提示するようにすることもできる。対話単位で発話記録を管理する場合、その対話を特徴付けるラベルがあるほうが、アクセスする上で望ましい。ある対話において、アクティブに発言した人の名前は、その対話の特徴を表現する一つの指標となりえる。各対話は時空間情報を付加されて、例えば、次のように表現される。
「2005年03月24日12時23分〜34分@食堂 稗田、首藤、上田(ほか4名)」
代表的な発話者の判別としては、対話における各発話者の総発話時間を算出し、発話時間が長い順に必要数だけユーザ名を取得することによって行える。必要数に満たない場合でも総発話時間(あるいは対話継続時間におけるその発話者の発話時間の割合)が規定値に満たない場合には提示を取りやめたり、発話時間だけではなく発話回数をパラメタとして加味したりすることも可能である。
次に、本発明の第8の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、前記コミュニケーション記録管理手段が管理する発話記録は、発話の受話者を示す情報をさらに含み、前記発話統合手段により生成された対話記録は、発話の受話者と併せて提示されることを特徴とする。
コミュニケーション記録においては、その発話が誰に聞かれていたのかを取得することが重要になる場合が多い。発話者のみを記録すると、対話には居合わせたが、発言をしなかったユーザは記録から漏れてしまうことになるが、そうしたユーザに関しても記録を行うことでこの問題を回避することができる。
次に、本発明の第9の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、前記コミュニケーション記録管理手段が管理する発話記録は、発話の発生場所を示す情報をさらに含み、前記発話統合手段により生成された対話記録は、対話の発生場所と併せて提示されることを特徴とする。
コミュニケーション記録においては、その発話(対話)がどこで行われていたのかを取得することが重要になる場合が多い。発話ごとに発話場所を取得し、記録しておくことで対話の発生場所を提示することが可能になる。対話参加者が移動しながら対話を行っている場合には、対話の発生場所は、広い範囲に分散する可能性がある。その場合は、場所A→場所B→場所Cというように代表的な場所の遷移を示すことができる。
次に、本発明の第10の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、前記コミュニケーション記録管理手段が管理する発話記録は、発話内容をさらに含み、前記発話統合手段により生成された対話記録は、発話内容から構成される対話内容と併せて提示されることを特徴とする。発話内容をマイクにより録音することで発話内容を記録することが可能であり、それを対話記録と関連づけて保存しておくことで、あとから発話内容を呼び出すことが可能になる。
次に、本発明の第11の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、前記コミュニケーション記録管理手段が管理する発話記録は、発話者の精神状態の推定情報をさらに含み、前記発話統合手段により生成された対話記録は、前記推定情報と併せて提示されることを特徴とする。
発話は、人間のさまざまな感情を含んでいる。通常の自然発話における人間の感情認識率は60%〜70%と言われているが、機械でも会話速度、声量、話のトーンなどを定量的に解析することによってほぼ同等レベルの感情認識が可能になっている。たとえば、幸福、驚きなどの場合は発話音声の基本周波数の平均値は高く、嫌悪の場合には低いという特徴がある。また発話音声の基本周波数の標準偏差と感情の種類にも一定の関係があることが知られている。そこで、例えば、図4の装置が携帯電話機であれば、音声記録用のマイクを用いて、会話速度、声量、話のトーンなどを定量的に解析することが可能である。この解析結果も、発話内容と関連付けして記録しておくことができる。
発話内容を記録する際に感情認識をあわせて行い、発話記録をユーザに提示する際に、各発話に対する感情情報をユーザに合わせて提示することにより、ユーザが情報を閲覧するときの手がかりとして利用できる。例えば、怒りの感情のこもった発話は赤色で記述し、悲しみの感情のこもった発話は青色で記述する。これにより、ユーザが必要な発話記録を見つけ出すための大きな手がかりとなる。また、後日、発話記録を閲覧したときに、ある人がその発話中、(受話者には)意外な感情を有していたことが分かるかもしれない。特にこの感情情報は、電子メールなどのテキストメッセージにおいては利用しにくい特性であるため、発話記録における大きな特長となる。
同様に、発話に関連してキーワードを自動抽出することにより、記録を簡潔にすることができる。或いは、このキーワードを、後日に検索をする場合の検索キーとして利用することも可能である。
次に、本発明の第12の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、グループ化された発話の継続時間を見積る対話継続時間算出手段をさらに備え、コミュニケーション記録提示手段は、対話継続時間算出手段により見積られた継続時間をあわせて提示する。 それぞれの対話がどの程度の時間継続したかという情報は、対話を管理する上で重要な指標となる。長時間継続した対話ほど重要である可能性が大きいからである。一言、二言で終わるような対話は、挨拶などほとんど意味を成さない場合も多いが、例えば1時間も継続した対話は、その内容がどんなものであれ、それなりに意味がある場合が多いと考えられる。
対話継続時間は、対話中に含まれる最初の発話の開始時刻から、対話中に含まれる最後の発話の終了時刻までとして算出できる。それぞれの開始時刻、終了時刻には若干の誤差が含まれると考えられるが、精度は特に要求されないので問題にはならない。1分未満、1分以上10分未満、10分以上の3段階程度の分類で、表示色やフォントサイズを異ならせて提示することもユーザによる認識のしやすさという観点から有効である。また、コミュニケーション記録提示手段は、対話継続時間算出手段により算出された継続時間が、規定の閾値以上のグループ化された発話のみを提示するようにしても良い。人は、一日に細かな対話を大量に行っている。それらの全てを提示されると、情報量が多すぎるため、目的の対話を見つけることは困難になる。例えば、継続時間が1分以下の対話をフィルタリングすれば、残る対話の量は著しく減少していると期待される。フィルタリングの閾値はユーザによって変更可能であることが望ましい。
また、コミュニケーション記録提示手段は、対話継続時間算出手段により算出された継続時間に従い、昇順、あるいは、降順にグループ化された発話を提示するようにすることもできる。例えば、発話継続時間の長い順に発話を提示することができれば、比較的重要度の大きい順に対話記録が並ぶことが期待される。
次に、本発明の第13の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理装置においては、コミュニケーション記録提示手段は、コミュニケーション記録管理手段により記録されている発話記録からユーザによって指定された特定の発話者を含む発話記録のみを検索するユーザ検索手段を有する。対話は、人と人とが行うものである。従って、ある人と行った対話のみを抽出したいという要求が生じる場合がある。そこで、ユーザ検索手段を備えることにより、ある特定の人との対話又はグループ間での対話を、簡単に抽出し呼び出すことが可能になる。
次に、本発明の第14の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理端末は、前記コミュニケーション記録管理手段は、電子メール記録を発話記録に加えて管理し、前記コミュニケーション記録提示手段は、前記コミュニケーション記録管理手段により管理されている電子メール記録と対話記録の一部または全部を、電子メール送信時刻および対話発生時刻に基づき、時系列に並べてユーザに提示することを特徴とする。
ユーザは、日々送受信するメールを、メール管理ソフトウェアすなわちメーラを用いて管理している。一般的なメーラは、時系列にメールを提示したり、発信者などの属性で検索したりすることができる。これらのメーラで管理されているメールと発話記録とを同一の画面内で統合して扱うことができれば、ユーザはメールと実世界上の対話という2通りのコミュニケーションを、別々の手段で分離して扱う必要が無くなる。無論、分離して扱うほうが便利な場合もあるため、コミュニケーションの手段ごとに表示を分離するモードと統合するモードとを有することが望ましい。
操作に関しても、例えば、ある発話記録に対する返信として電子メールを新規作成し、発話記録を引用するような、双方のコミュニケーション記録を分け隔てなく扱えることが望ましい。そのためには少なくともメーラのアドレス帳の電子メールアカウント情報と、発話記録(受話記録)の発話者IDを相互に関連付けて管理するアカウント管理手段を持つ必要がある。例えば、ある発話者に対する返信を電子メールで行う際には、その発話者に対応する電子メールアドレスを取得し、その電子メールアドレスを宛先に設定したメールを作成する必要がある。これは単純に発話者識別子と電子メールアドレスとを対応付けるテーブルを持つことにより解決される。
一方、対話に対して電子メールで返信を行う場合には、その対話の参加者のユーザID(発話者IDと受話者ID)に基づき電子メールアドレスを取得し、その電子メールアドレスを宛先に設定したメールを作成する必要がある。対話の参加者は通常多くの人間が含まれるため、ユーザは不必要なアドレスを削除するなどの処理を行う必要がある可能性があるが、その際、電子メールアドレスが発話時間順などにソートされていれば、取捨選択が行いやすくなる(前述の対話代表者の抽出処理と同様の処理を行えばよい)。
また、引用や返答を行う際に、発話やメールなどのコミュニケーション記録に関連付けられているIDを記述することは、コンピュータで処理を行う上で非常に役に立つ。電子メールには、Message-IDと呼ばれる枠組みがあり、RFC2822で定義されている。あるメールに対して返答するときには、In-Reply-Toヘッダに元メールのMessage-IDを記述することで、そのメールを受け取ったメーラは、そのメールが該当するMessage-IDを有するメールへの返答であることを知り、スレッド表示などを行うことができる。また、メールの一部を引用する場合にもReferencesヘッダに引用元のメールのMessage-IDを記述することで、そのメールを受け取ったメーラは、そのメールが該当するMessage-IDを有するメールを引用していることを知るため、2つのメールを関連付けることが可能になる。
電子メールにおいて標準化されている上記の処理は、本発明の各実施の形態で述べている発話に対しても発話IDを用いることで可能になる。発話IDはその発話を聞いた人に周知されているため、後日、発話IDを示すことで、どの発話を指しているのか判断することができる。対話の中で、ある発話に続いて行われた別の発話は、先の発話に対する返答となっている場合が多いので、In-Reply-Toヘッダに相当する情報(元の発話の発話ID)を発話通知に含めることができれば、後日、発話記録を参照する際に、発話間のつながりを知ることができるため有用である。
また、過去に行われた発話を呼び出して、それに対してコメントをする際には、Referenceヘッダに相当する情報(引用元の発話の発話ID)を発話通知に含められれば有用である。本発明の各実施の形態で述べる情報処理装置に記録されている発話記録に含まれる発話内容を視聴した後に続けて発話を行った場合、Referenceヘッダに相当する情報を発話通知に含めることができる。
尚、ここでは発話単位で発話記録を扱う方法を記載したが、対話単位で扱う場合も対話IDを用いることで、同様の処理が可能であることはいうまでもない。
一般的な電子メールには、その他にも、送信元アドレス、送信先アドレス、送信日、サブジェクト、本文という要素がある。これらの要素と、本発明の対象とする発話における、発話者識別子、受話者ID、発話時間、話題、発話内容の各要素が対応する。このうち、電子メールのサブジェクトに該当する話題以外の要素に関しては、前述の構成で取得、管理することが可能である。話題に関しても、発話内容から音声認識、キーワード抽出などを行うことにより、ある程度は推定可能であし、また、特になくても問題がない場合も多い。
以上に説明したように、電子メールと発話とは、それぞれ共通する要素を有するため、それぞれの記録の保持形式さえ共通化又は変換しさえすれば、電子メールと発話とを、統一されたインタフェースにより取り扱うことが可能になる。現在利用しているメーラに、メールに混じって発話記録が並んでいる状態を想像するとわかりやすい(後述する)。それぞれのコミュニケーション記録は、別々のページに分けるなどして分割して表示することもできるが、単一のページに混在して表示することも可能である。
あるユーザによる発話や電子メールを一覧する場合には、そのユーザの発話者識別子と電子メールアドレス双方を認識する必要があり、それらのアカウントが同一人物であることを機械が認識していることが望ましい。たとえば「山田さん」のコミュニケーション記録を検索する場合、山田さんの電子メールアドレスのyamada@dokodemo.netと発話者識別子:Y094897870を検索キーとして検索することになるが、ユーザが各々のアカウントを認識しなくても、機械が適切なアカウントを引き出して検索を行うことが望ましい。
ユーザはコミュニケーションの違いを意識する必要はなく、たとえば、ある発話記録に対する返答として、電子メールを作成することも容易である(その場合、該当する発話記録の発話IDをIn-Reply-Toヘッダに記述する)。ある発話IDを有する発話への返答を電子メールで行う場合には、その発話IDに対応する電子メールアドレスが自動的に割り当てられることが望ましい。上述のように、電子メール記録と発話記録を統合して利用するためには、それぞれのアカウントを相互に変換、同一視するための枠組みが必要である。それは対応テーブルを保持することで解決できる。
次に、本発明の第15の実施の形態による実世界コミュニケーション管理技術について説明する。本実施の形態による情報処理端末は、前記コミュニケーション記録管理手段は、ネットワークを通して行われるコミュニケーション記録を発話記録に加えて管理し、
前記コミュニケーション記録提示手段は、前記コミュニケーション記録管理手段により管理されているコミュニケーション記録と対話記録の一部または全部を、コミュニケーション開始時刻ないしは対話発生時刻に基づき時系列に並べてユーザに提示することを特徴とする。すなわち、電子メールだけではなく、電話やチャット、ビデオ会議などの他のコミュニケーション手段も統合できれば、ユーザが行うさまざまなコミュニケーションを統一的に扱うことができる。本実施の形態による情報処理端末は、ユーザの仮想上、実世界上のコミュニケーションを記録し、統合されたユーザインタフェースで、あらゆるコミュニケーション記録にアクセスすることを可能とする。人間のコミュニケーションの記録は、その人物の人生の多くを記録しているものと期待される。その人物が死んだ後においても、その人物のコミュニケーション記録を紐解くことで、その人物の人生の多くの部分を知ることができる。
電話の通話記録を統合する場合を考えると、電話の発信・着信記録(発信元、発信先、発信日時、通話時間)などはすでに利用可能である。通話内容に関しても同時に録音しておけば記録可能である。従って、前述の発話や電子メールと統合されたインタフェースで通話記録を扱うことができる。相互運用性を高めるために、それぞれの通話に対し、固有のIDを与えることと、ユーザアカウント(この場合電話番号)を他のコミュニケーション手段のアカウント(たとえば電子メールのアドレス、発話の発話者ID)とマッピングする必要がある。
以上に説明したように、本発明の各実施の形態によれば、ユーザが誰とコミュニケーションをとったかを記録することができるため、実世界上のコミュニケーションを仮想世界上のコミュニケーションと同様に扱うことができるようになり、後からコミュニケーション記録を見直すことによって、実世界上のユーザ行動を確認することが可能になる。
以下、さらに詳細かつ具体的な説明を行う。
送受信した発話通知は記録する必要がある。必ずしも送受信したすべてのパケットをそのまま記録する必要は無く、必要な部分だけ管理しやすい形式で保存すればよい。
本実施例は、監視対象ユーザの発話を検知する発話検知手段と、発話検知手段によってユーザの発話が検知された際に、ユーザの発話を近接する他の端末に通知する発話通知手段とを備え、発話通知手段が通知する情報は、発話者を識別するIDを含むことを特徴とする情報処理装置において、他の端末から発信された発話通知を受信する発話受理手段をさらに備え、発話通知手段により通知した自らの発話通知と、発話受理手段により受信した他の発話通知とを、記録するコミュニケーション記録管理手段を備えることを特徴とする。
図4(A)は、本実施例による情報処理装置の概観を示した図である。情報処理端末400は無線LAN通信モジュール405を備え、近接する他端末とアドホック無線通信を行うことができる。さらにマイクロフォン406を備えており、対話内容を録音することができる。録音された対話内容は機器内部に格納されている記憶装置408に格納され、外部出力コネクタ404や無線LAN通信モジュール405を介して外部端末に出力することができる。
図4(B)に示すように、ユーザは、声帯の振動を検知する発話検知パッド407を喉部に貼り付ける。発話検知パッド407によって声帯の振動を検知すると、情報処理端末400は、近接する端末に発話通知を行うためにspeech.msgと呼ぶメッセージを生成し、無線LAN通信モジュール405を介して近接端末にspeech.msgを送信する。Speech.msgの発信は発話が継続している間、一定期間ごとに行われ、発話が終了すると停止される。一方で発話の継続中はマイクロフォン406によって発話内容が取得され、speech.msgの情報と関連付けられて記憶装置408に記録される。表示画面401には、図に示すように、発話者識別子(EA9206454592)、発話者名称(さっちゃん)、発話継続時間(02’13”)、および、録音音声レベルが表示されている。自分が発話している場合には、発話者は自分になる。
一方、情報処理端末400は、近接端末が送信するspeech.msgを、無線LANモジュール404を介して受信することができる。Speech.msgには、発話者を特定するIDが含まれているので、speech.msgを計測することによって、発話者を知ることができる。この端末は内部記憶装置内に既知のIDと名前との変換テーブルを保持しており、既知のIDに関しては図4に示すように、名前に変換してユーザに表示する。さらにマイクロフォン406に自分以外の発話が計測され、speech.msgを受信する間、録音された発話内容は、speech.msgの情報と関連付けられて記憶装置408に蓄積される。
記憶装置408内に蓄積された発話記録は、表示画面401内に表示することもできるため、入力デバイス403を操作することにより、所望の発話記録を選択し、記録されている発話内容をスピーカ402を介して聞くことができる。
図20(a)は、2005年4月1日(金)に記録された発話記録を、発話開始時刻に基づいてソートして、表示画面2001上に表示させた例である。画面左より発話開始時刻(TIME)、発話者識別子または名前(NAME)、発話継続時間(DUR)の順に情報が表示されている。ユーザは図4に示す入力デバイス403を操作することによりカーソル行(反転表示)を上下し、時間を遡ったり進めたりすることで、所望の発話記録を選択し、発話内容を聞くことができる。
この例では、発話者識別子に対応する名前を端末が所持していないユーザによる発話(ID:340087BおよびID:129086C)も表示されているが、発話者識別子に対応する名前を端末が所持していない未知の発話IDを有する発話は表示しないように制御する、もしくは、最初から記録しないように制御することも可能である。このように制御することにより、有用でない情報をフィルタリングし、S/N比を改善することもできる。さらに、継続時間が一定時間に満たない発話を表示しなかったり、削除したりすることもできる。挨拶など数秒で完了するような発話は重要でないことが多いので、それらを表示しないことで重要な発話を見つけやすくなる。ここでは1日の発話記録を対象にソートを行っているが、発話記録は発話開始日時と対応付けして記録するため、1週や1月、任意の期間などにおける発話記録を対象に同様の提示を行うことができる。
図20(b)に示す表示画面2002は、4月1日に記録された発話記録を、発話継続時間でソートして表示した例を示す図である。重要な発話ほど長時間に及ぶことが多いため、発話継続時間でソートすることにより、重要な発話を見つけやすくなるという効果がある。表示画面2002には、画面左より発話開始時刻(TIME)、発話者識別子または名前(NAME)、発話継続時間(DUR)の順に情報が表示されており、発話継続時間の降順にソートされている。 ここでは1日の発話記録を対象にソートを行っているが、1週や1月、任意の期間における発話記録を対象に同様の提示が行うことができる。
図21(c)は、4月1日に記録された発話記録をユーザごとに総発話時間でソートして表示した表示例2101を示す図である。長時間発話する人は重要な人であると推定されるため、総発話時間でソートすることにより、重要な発話、重要な人を見つけやすくなるという効果がある。ここでは1日の発話記録を対象にソートを行っているが、1週や1月、任意の期間における発話記録を対象に同様の提示が行うことができる。
図21(d)は、ある特定のユーザ(ここでは、「さっちゃん」)の発話を発話記録から検索して表示した表示例2102を示す図である。ここでは、時系列にソートして表示しているが、発話継続時間によりソートして表示しても良い。ここでは数日の発話記録を対象にソートを行っているが、1週や1月、任意の期間における発話記録を対象に同様の提示が行うこととできる。
図1は、本発明の各実施の形態による情報処理装置の構成例を示す機能ブロック図である。図1に示すように、情報処理装置は、通信部101aと発話通知部102を含む発話通知手段と、発話状態検出部103を含む発話検知手段と、対話相手取得部104と通信部101bとを含む通知受理手段と、受話通知部110と通信部101dを含む受話通知手段と、対話管理部105と対話記録部108とを含むコミュニケーション記録管理手段兼発話識別子割当手段と、通信部101cと名前管理部106と名前解決部107とを含むユーザ名取得手段と、対話取得部110を含む発話内容記録手段と、通信部101を含むコミュニケーション記録出力手段と、ユーザインタフェース部109と、を有している。
ユーザは、図1に示す各部を備える情報処理装置Aを常に持ち歩く。発話状態検出部103を含む発話検知手段は、ユーザの発話を監視し、ユーザの発話を検出すると発話通知手段である発話通知部102に発話の検出を伝える。発話通知部102は、近接する他の端末に発話を通知するために図5に示すメッセージ(speech.msg)を生成し、通信部101aを介して近接する端末に発信する。発話状態検出部103は同時にコミュニケーション記録管理手段である対話管理部105に発話の検出を伝える。対話管理部105は発話の発生を時刻と関連付けて、対話記録部108に記録する。
一方、通知受理手段に該当する対話相手取得部104は、通信部101bを介して他端末から送信されるspeech.msgを受信し、speech.msgに含まれる発話者識別子などの発話者に関する情報を対話管理部105に伝える。対話管理部105は他者の発話の発生を、時刻および上記発話者に関する情報とともに、対話記録部108に記録する。対話記録部108は、発話記録出力手段である通信部101に接続されており、通信部101を介して記録されている対話記録を外部端末に出力することができる。ここで、対話取得部101は、発話内容記録手段であり、発話通知の送受信と同期して、マイクロフォンにより音声を取得する。取得された音声は対話管理部105によって発話通知と関連付けられ、対話記録部108に蓄積される。
さらに、通信部101を介して取得されるユーザIDと名前との対応情報は、名前解決部により管理され、対話管理部105及び対話記録部108で扱われる対話記録に含まれる既知のユーザIDに対して名前を関連付ける(ユーザ名取得手段)。対話管理部105及び対話記録部108で扱われる対話記録は、ユーザインタフェース109を介してユーザに提示される。
図5は、発信通知として利用されるspeech.msgのデータ構成例を示す図である。Speech.msgは、発話ID、発話No、発話者識別子、その他の情報から構成される。発話ID501は、一連の発話に付加される固有のIDである。長時間継続する発話の場合には、発話継続中に複数のspeech.msgが発信される場合があるが、その場合は同一の発話IDが記載される。発話が途切れると、次の発話には新たな発話IDが付加される。
発話No502は、同一の発話ID501を有する一連の発話におけるspeech.msgの通し番号であり、1より始まり、インクリメントされる。発話No502は、長時間連続して発話すると、増加していくが、発話を中断すると1に戻る。発話者識別子503は、発話者を識別するためのIDである。前述のように発話者識別子503は発話ID501に内包されていてもよい。
その他の情報504としては以下にあげるものがある。
1) 発話開始時刻:一連の発話が開始した発話開始時刻を記述する。
2) 発話継続時間:一連の発話の継続時間を記述する。
3) 発話通知発信間隔:発話通知を発信する時間間隔を記述する。発話通知を受け取って、次に期待する時間に発話通知が受信できなかった場合には、発話が終了したとみなす。
4) 発話通知領域の大きさ:発話通知を発信している領域の大きさを記述する。
5) 発話場所:発話を行っている場所を記述する。
6) 受話通知要求:受話通知が必要かどうかを記述する。
7) 受話通知送信先アドレス:受話通知を送信すべきアドレスを記述する。
8) 受話者ID:受話者として発話端末が認識しているユーザIDを記述する。一連の発話中の先行するspeech.msgに対する受話通知を受け取ったユーザIDを記載する。
9) In-Reply-To: 対話が形成されている場合に、直前の発話の発話IDを記述する。電子メールに対する返答である場合には、該当する電子メールのMessage-IDを記述する。
10) References: 引用する発話IDを記述する。電子メールを引用する場合には、該当する電子メールのMessage-IDを記述する。
11) Subject: 話題を記述する。電子メールのサブジェクトに該当。電子メールへの返答時には「Re:」という接頭辞をつけて、サブジェクトを自動生成できるが、一般的な会話でサブジェクトを自動生成することは難しい。ただし、ユーザが自分でサブジェクトを設定することは可能である。たとえば、多くの人に囲まれている人気者に話しかけるタイミングを計るために、サブジェクトを明示してその人に話しかける。人気者がもつ端末には興味のあるサブジェクトがあらかじめ設定されていて、該当するサブジェクトを有する発話を検知すると、ユーザに通知するなどの使い方が想定できる。
11)キーワード: キーワードに関しても上記と同様であるし、発話から音声認識により自動的に抽出してもよい。
12)関連URL: 関連情報へのポインタ。発話に対するリンクとして機能する。ある発話が概要しか述べられていない場合に、詳細な情報がほしい場合には、発話に設定されているリンクをたどって、詳細情報が記載されたWebページを閲覧するなどの使い方ができる。
図10、11は、図2における端末A-D間の発話通知のやり取りを示した図である。それぞれの端末はそれぞれのユーザが発話している間(発話状態)、所定の時間ごとに発話通知領域内に存在する端末に対して発話通知を行う。ここではspeech.msgを発話通知領域内に配布することで、通知を行っている。端末A、Dは互いの発話通知領域内に存在するため、ともに相手の発する発話通知を受信する。ここでユーザAの2回の発話にはそれぞれ発話ID:A001とA002が割り当てられており、ユーザDの発話には発話ID:D032が割り当てられている。発話の継続中には定期的にspeech.msgが発信され、ここでは端末Aは端末Dが送信したspeech.msgを5回、端末Dは端末Aが送信したspeech.msgを10回受信する。それぞれのspeech.msgには、発話No(括弧内数字)が振られており、同一の発話IDを有するspeech.msgでもそれぞれを区別することができる。
図6は、このspeech.msgの送信手順を示すフローチャート図である。図6に示すように、ステップS1において処理を開始し(Start)、発話検知手段により発話を検出すると(ステップS2)、それが新規発話であるか、継続する一連の発話の続きであるかを判断する(ステップS3)。例えば、同一話者による発話間隔が3秒以上離れていると、新規発話と判断する。新規発話の場合には(Yes)、発話IDを生成し(ステップS4)、発話Noに新たに1を割り当てる(ステップS5)。新規発話でない場合には(No)、以前の発話IDを継続して利用し(ステップS8)、発話Noには1を加えたものを割り当てる(ステップS9)。
発話の直前(ここでは3秒以内)に、他の発話通知を受信していた場合には(ステップS6でYes)、In-Reply-Toに受信した発話IDを記載する(ステップS10)。図11の例では、Dの発話ID:D032はAの発話ID:A001を受けて行われたものなので、In-Reply-ToフィールドにID:A001を記述する。同様にAの発話ID:A001にはIn-Reply-To: D032が記述されている。
さらに、発話の直前(ここでは3秒以内)に発話記録を視聴していた場合には(Yes)、Referencesに該当する発話IDを記載する(ステップS11)。その後、前述したその他の情報を加えて、speech.msgを作成する(ステップS12)。Speech.msgは通信領域内に存在する端末に対して送信され(ステップS13)、規定時間待機(ここでは200ms)する(ステップS14)。ステップS2で発明を検出しない場合(No)も、ステップS14に進む。ステップS14からステップS2に戻り処理を繰り返す。
ここでは発話が継続中200msごとに発話通知が発信されるため、発話通知1つごとに200ms該当ユーザの発話を聞いたと見積もることができる。発話Noを見ればどの程度その発話が継続しているかを知ることもできるし、途中の発話Noから受信を始めたときには、発話の途中に割り込んだことを知ることができる。
図10では、speech.msgの送信に対して、受信側は何の応答もしておらず、一方的な通知となっているため、自分の発話をどの端末が聞いていたかを発話者が知ることはできない。しかしながら、通常対話は相互の発話で行われることを考えると、自分の発話の受話者は、その時間の前後に発話することが想定されるため、受話者を高い精度で推測することができる。図10の例では端末A、Dとも端末A-D間で対話が行われたことを認識できる。
それでも聞いているだけの人などを管理したい場合など、より厳密に受話者を管理したい場合には、各端末が発話通知を受信したときに、該当する発話IDとユーザIDを含む受話通知を返すようにすることができる。図11は、受話通知であるACKを発話端末に返すときのメッセージのやり取りを示している(ACKは点線の矢印で示されている)。受話通知を導入することにより、発話者端末は、該当する発話がどの端末によって受話されたかを正確に管理することができる。
図12は、図2においてユーザA-Dの対話の最中に、別のユーザEと対話しながら近くを通りかかった無関係のユーザFと、ユーザA間のspeech.msgのやり取りを示したものである。ユーザFとの間の発話通知はノイズであるため、こうした情報は可能な限りフィルタリングすることがS/N比を向上させる上で望ましい。この方法を以下に示す。
1)まず、ユーザFのユーザIDがユーザAにとって未知であるならば、その発話通知は無視するという解決策がある。2)また、一連の発話Noが1から始まらずに途中から始まっていた場合には、発話の途中で割り込んだと判断し、フィルタリングすることも有効である。3)さらに図12で示すように、発話タイミングが長時間にわたって重なっている場合には、それぞれ別の相手と話していると判断し、フィルタリングすることができる。
図30は受話通知を送信するフローを示した図である。処理を開始し(ステップS31:START)、ステップS32において発話通知を受信した端末は、ステップS33において発話通知を記録するともに、ステップS34において受話通知が必要かどうか判断を行う。端末の設定が受話通知の通知を認めており、発話通知に含まれる受話通知要求が真の場合には(Yes)、対応する発話の発話IDと受話者IDを含む受話通知を生成し(ステップS35)、受話通知を送信する(ステップS36)。受話通知の送信先は通常、発話通知の送信元端末となるが、発話通知に別の受話通知送信先が指定されている場合にはそれに従う。受話通知が不要であれば(ステップS34:No)、処理を終了する(ステップS37)。
図31は受話通知を受信した場合のフローを示した図である。処理を開始し(ステップS41:START)、ステップS42において受話通知を受信すると受話通知に含まれる発話IDと受話者IDを識別し、発話と受話者を特定する(ステップS43)。続いて該当する発話IDに対応する発話記録に受話者を記録し(ステップS44)、処理を終了する(ステップS45)。
前述のように、図15は、蓄積された発話記録の一例を示す図である。ここでユーザA1508、ユーザB1509、ユーザC1510が喫茶ファミーユ内の6番テーブル1511を囲んで話をしており、途中、未知の店員1511が6番テーブル1511の近くを通り過ぎている。ここでは図11に示すように、発話通知に対する受話通知を導入しているので、各発話に対する受話者の情報も取得されている。図15の表には記載されていないが、前述のspeech.msgに含まれる各種情報も同様に管理される。この表に示すように、発話ごとに管理すると、記録が膨大になる。そこで、発話同士をある程度まとめて対話として管理する方がユーザにとって理解しやすい。図16は発話同士をまとめて対話として表示した例を示す図である。図16は図15に対応する表であるが、対話ID1601と、主な対話者1602と、対話時刻1603と、対話場所1604と、対話継続時間1605と、音声1606と、によりまとめられている。図15の喫茶店ファミーユでの対話は、TALK0001と、TALK0002との2つの対話にまとめられている。図15と図16とのいずれが理解しやすいかは、目的によるが、まず、図16をみて、その項目の内のいずれかの詳細を知りたい場合に、図15を参照するのが一般的な利用法である。
A…情報処理装置、101a、101b、101c…通信部、102…発話通知部、103…発話状態検出部、104…対話相手取得部、105…対話管理部、106…名前管理部、107…名前解決部、108…対話記録部、109…ユーザインタフェース部。