JP2008262046A - 会議可視化システム、会議可視化方法、及び集計処理サーバ - Google Patents

Abstract

【課題】
会議中の複数の参加者の音声を取得して，刻々と変わる参加者の会話状況をリアルタイムに表示することで，より積極的な議論を誘発するような会議可視化システムを提供する。
【解決手段】
複数の会議参加者に対応した複数の音声収集部から収集した音声データを音声処理サーバ４０で処理し、発話情報を抽出する。この発話情報を集計処理サーバ２００に順次入力する。処理サーバ２００のストリームデータ処理部で、この発話情報に対して、クエリ処理を施すことにより会議参加者の会議における発言回数累積値などのアクティビティデータを生成する。表示処理部２０３は、このアクティビティデータに基づき、会議参加者の対話状況を円の大きさや線の太さなどを用いて可視化して表示する。
【選択図】図１

Description

本発明は、複数のメンバが集まる会議等において、音声データの収集および解析を行なうことによって、リアルタイムにメンバ間のインタラクション状況を表示するための会議可視化技術に関する。

知識労働者の生産性、創造性を向上させる手法が注目を集めている。新規のアイデアや知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議論を重ねることが重要である。その中でも、個人の持つ知恵を組織の財産として共有・管理していくための方法としてナレッジマネジメントと呼ばれる方法論が注目されている。ナレッジマネジメントは、組織文化・風土の改革までを含めた考え方であり、情報技術による知識共有の支援ツールとしてナレッジマネジメント支援ツールと呼ばれるソフトウェアが開発・販売されている。現在販売されているナレッジマネジメント支援ツールの多くはオフィスで生産された文書を効率的に管理する機能が中心である。また、オフィス内の知識の多くがメンバ間のコミュニケーションの中に存在することに注目したものがある。特許文献１には、組織のメンバ間でなされる対話の状況を蓄積する技術が開示されている。更に、電子的なコミュニケーションの場を提供することで知識の表出化を促進するツールが開発されている。特許文献２には、電子的なインタラクションという観点において、電子メールの送受信数カウントの比較結果によってメンバ間の影響を表示する技術が開示されている。

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

新規のアイデアや知識（ナレッジ）を創出するためには、異分野の専門家が集まり、議論を重ねることが重要であり、有限の時間を有効に使った実りのある議論のプロセスが重要である。従来のナレッジマネジメントツールは、議論の過程に着目したものではなく、その結果に対しての情報共有に主眼をおいている。特許文献１では、参加者もしくは参加者以外のものが蓄積された対話状況を再現することが目的であり、対話のプロセス自体に注目したものではない。また、特許文献２では、メンバ間の影響度合いを計算しているが、電子メールの送受信数という単純な数値に基づいており、議論のプロセスにまで踏み込んだものではない。しかも、電子メールによるインタラクションは、一般的に深い議論を行なうには、適しておらず、例え、高精細なテレビ会議システムなど、電子的なインタラクション技術が成熟したとしても、フェイス・トゥ・フェイスでの議論を完全に置換するものにはなり得ない。オフィスでのナレッジ創出には電子的なメディアを介さないフェイス・トゥ・フェイスでの会話や会議が必須となっている。

本発明は、複数のメンバが集まる会議等において、アイデアやナレッジの創出を促進・誘発するための情報処理システムに関するものである。会議中の音声を取得して、発言者（発話者）および、その発言回数、対話シーケンス、会議の活性度を計算して、刻々と変わる会議の状況をリアルタイムに表示することで、参加者自身にフィードバックがかかり、より積極的な議論を誘発するする会議可視化システムの提供を目的とする。

上記目的を達成するため、本発明においては、会議における複数の会議参加者間の対話状況を可視化して表示する会議可視化システムであって、会議参加者に対応した複数の音声収集部と、音声収集部から収集した音声データを処理し、発話情報を抽出する音声処理部と、音声処理部で抽出された発話情報が順次入力され、この発話情報に対してクエリ処理を施すことにより会議参加者の会議におけるアクティビティデータを生成するストリーム処理部と、このアクティビティデータに基づき、前記会議参加者の対話状況を可視化して表示させる表示処理部とを有する
会議可視化システムを提供する。

本発明においては、音声データに所定の処理を行ない、発言者およびその発言回数、対話回数を特定し、発言回数を円の大きさで、対話回数を線の太さで、リアルタイムに表示する。さらに、キーストローク情報から得られた議論内容、発言者毎の発言回数累積、活性度を同時に表示する。

本発明によれば、議論状況をリアルタイムに把握しながら、議論を行なうことにより、発言量が足りないメンバに対しては発言を促すようなフィードバックがかかる。もしくは、会議の調停者が、議論状況をリアルタイムに把握しつつ、より多く参加者からのアイデアを出してもらうようなコントロールを行なうことで、議論の活性化および有効なナレッジ創出が期待できる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図３に第一の実施例の会議可視化システムを利用した会議シーンの一例を示す。４人のメンバ（メンバＡ、メンバＢ、メンバＣ、メンバＤ）が会議を行なっている。会議卓に設置されたマイク（マイクＡ、マイクＢ、マイクＣ、マイクＤ）より各メンバの発話がセンシングされて、これらの発話データは音声処理サーバ４０を経由したのち、集計処理サーバ２００で所定の処理が行なわれ、最終的に、この会議の状況がモニタ画面３００にリアルタイムに表示されている。参加メンバが可視化された会議状況から直接フィードバックを受けることで、各メンバが発言のモチベーションを高めたり、司会者がより多くのアイデアが集まるような会議進行を行なう、といった効果が期待される。なお、ここで音声処理サーバ４０や集計処理サーバ２００などのサーバは、通常のコンピュータシステムと同義であり、例えば、集計処理サーバ２００は、処理部（ＣＰＵ）、記憶部（半導体メモリや磁気記憶装置）、キーボードやマウスなどの入力部、ネットワークと接続される通信部などの入出力インタフェース部、更に必要ならＣＤやＤＶＤなどのメディアの読取書込み部などが内部バスで接続されている構成を有する。この音声処理サーバ４０と集計処理サーバ２００は、一個のサーバ（コンピュータシステム）で構成して良いことはいうまでもない。

図１に第一の実施例の会議可視化システムの全体図を示す。会議可視化システムは、活動状況のセンシング、センシングデータの集計・解析処理、および、結果の表示、という大きく分けて３つの機能より構成される。以下、これらの順番に従ってシステムの詳細を説明する。会議卓３０には、メンバの着座位置に応じて音声収集部であるセンサ（マイク）２０が設置されており、メンバが会議にて発言を行なった場合には、これらセンサ２０にて発言のセンシングを行なう。また、会議卓３０には、パーソナルコンピュータ（ＰＣ）１０が設置されている。このＰＣ１０は、キーストローク情報出力部として機能し、会議の記録係が会議録を記述する際のキーストロークデータを出力する。このキーストロークデータは、集計処理サーバ２００の入出力インタフェース部を介して、サーバ２００内に入力される。

図１の例においては、４つのセンサ（センサ２０−０〜２０−３）が設置されており、それぞれ、メンバＡ〜メンバＤの発話音声を取得する。センサ２０から取得された音声データは音声処理サーバ４０に転送される。音声処理サーバ４０においては、その内部に設置されたサウンドボード４１にて音声データのサンプリング処理が行なわれ、その後、音声処理部４２にて、音の特徴量データ（具体的には、音声エネルギーの大きさ等）が抽出される。通常この音声処理部４２は、音声処理サーバ４０内の図示されていない処理部（ＣＰＵ）におけるプログラム処理として構成される。そして、音声処理サーバ４０にて生成された特徴量データは、その入出力インタフェース部を介して、メンバの発話情報として集計処理サーバ２００の入出力インタフェース部に転送される。転送される音声特徴量データ５２は、時刻５２Ｔ、センサＩＤ（識別子）５２Ｓ、および、エネルギー５２Ｅを含んでいる。また、発言者発言内容出力部であるＰＣ１０から取得されたキーストロークデータ５１も、集計処理サーバ２００に転送され、これは、時刻５１Ｔ、発言者５１Ｎ、および、発言内容５１Ｗを含んでいる。

これらのセンシングデータは、集計処理サーバ２００内のストリームデータ処理部１００にて、会議の状況を可視化するためのデータである、アクティビティデータＡＤに変換される。ストリームデータ処理１００では、それぞれのデータソースに対応したＷｉｎｄｏｗ１１０を持っており、一定時間メモリに蓄えられている時系列のデータセットに対して、所定の数値演算処理を行なう。この演算処理は、リアルタイムクエリ処理１２０と呼ばれ、具体的なクエリの設定や、参加者とデータのＩＤとの対応付けは、それぞれ、クエリ登録インタフェース２０２、参加者登録インタフェース２０１を通して行なわれる。なお、上述のストリームデータ処理部１００、参加者登録インタフェース２０１、クエリ登録インタフェース２０２は、先に説明した集計処理サーバ２００の図示されない処理部（ＣＰＵ）で実行されるプログラムとして構成される。

通常、ストリームデータ処理部１００で生成されたアクティビティデータＡＤは、集計処理サーバ２００中の図示されない記憶部中のテーブルなどに記憶され、順次、表示処理部２０３の処理対象なる。本実施例では、具体的な、アクティビティデータＡＤとして、４つのデータが生成される。

１つ目は、議論活性化度５４であり、これは、時刻５４Ｔと、その時刻での議論の活性化度５４Ａより構成される複数のリストである。議論活性化度５４Ａは、その議論に関しての発言量総和やメンバ参加数等をパラメータにして、計算される。例えば、単位時間当たりの、発言総回数と発言を行なった参加者総数によって決定される。同図１では、一分当たりの議論活性化度５４を例示している。２つ目のアクティビティデータは、発言内容データ５５であり、これは、時刻５５Ｔと、その時刻に対応する発言者５５Ｓと発言内容５５Ｃ、および、重要性５５Ｆより構成されている。実際には、ＰＣ１０からのキーストロークデータ５１に含まれる、時刻５１Ｔ、発言者５１Ｎ、および、発言内容５１Ｗが、それぞれ、時刻５５Ｔ、発言者５５Ｓ、発言内容５５Ｃにマッピングされる。３つ目のアクティビティデータは、発言回数データ５６であり、これは、時刻５６Ｔと、その時刻に対応する、発言者５６Ｎと、発言者５６Ｎに対応する発言累積（回数）５６Ｃより構成されている。４つ目のアクティビティデータは、発言シーケンスデータ５７であり、これは、時刻５７Ｔと、その時刻に対応する、発言者の発話の順序関係である。具体的には、その時刻にて、発言者（前）５７Ｂの発話の直後に、発言者（後）５７Ａが発話を行なった回数５７Ｎを、あるウィンドウ時間内で求めたものである。

さて、ストリームデータ処理部１００で生成されたアクティビティデータＡＤに基づき、表示処理部２０３にて描画処理が行なわれる。即ち、アクティビティデータＡＤは、次段の表示処理部２０３にて、描画処理の素材データとして使用される。この表示処理部２０３も集計処理サーバ２００の処理部（ＣＰＵ）で実行される描画処理プログラムとして提供される。例えば、Ｗｅｂベースでの表示を行なう場合には、表示処理部２０３でＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｋｅｕｐ Ｌａｎｇｕａｇｅ）画像の生成処理等が行なわれる。表示処理部２０３で生成された画像は、入出力インタフェース部を介して、モニタに出力され、モニタ画面３００に示される画面構成で表示される。会議の様子は、モニタ画面３００にて、活性度・発言表示３１０、発言累積３２０、および、発言シーケンス３３０の３つの要素として表示される。

以下、素材データであるアクティビティデータを用いて表示される３つの要素について説明する。活性度・発言表示３１０では、時間軸に沿って、リアルタイムにその会議の活性度３１１と発言３１３が表示される。活性度３１１は、アクティビティデータＡＤの議論活性化度５４の表示を行なったものであり、発言３１３はアクティビティデータＡＤ発言内容データ５５を表示したものである。また、会議の統計データなどに基づいて、活性度の指標３１２を表示することも可能である。発言累積３２０は、アクティビティデータＡＤの発言回数データ５６に基づいて、会議開始からの参加者毎の発言回数を累積として表示したものである。最後に、発言シーケンス３３０は、アクティビティデータＡＤの発言回数データ５６と発言シーケンスデータ５７を使用して、参加者間の発話のやり取りを可視化したものである。

具体的には、この発言シーケンス３３０で図示されている参加者毎の円の大きさ（３３１Ａ、３３１Ｂ、３３１Ｃ、および、３３１Ｄ）は、過去から現在までの一定期間（例えば５分間）においての発言回数を円の大きさとして表しており、円と円との間のリンクの太さは、参加者間での会話が多いか少ないか（会話のインタラクションの量）を可視化したものである。例えば、ＡとＢとの間のリンク３３２は細く、ＡとＤとの間のリンク３３３は太く描かれており、ＡとＤとのインタラクションが多いことが示されている。本例では、Ａの発言の後にＤが発言した場合と、Ｄの発言の後にＡが発言した場合とは区別されてはいないが、発言シーケンスデータ５７を使用することによりこれらを区別するような表示方法も可能である。素材データ各々を用いて、これら活性度・発言表示３１０、発言累積３２０、および発言シーケンス３３０の各要素を適宜表示することは、通常の図形描画処理プログラムを、集計処理サーバ２００の図示されない処理部（ＣＰＵ）で実行することにより実現できることは言うまでもない。

図２は、図１で示した全体図における代表的な機能モジュールでの処理シーケンスを示したものである。まず音声収集部としてのセンサ（マイク）２０では音声データが取得される（２０Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる（４１Ａ）。次に音声処理部４２にて、発話情報としての特徴量の抽出（具体的にはエネルギーへの変換）が行なわれる（４２Ａ）。エネルギーは、例えば数ミリ秒の音波形の絶対値の２乗を全範囲に渡って積分したものである。なお後段にてより確度の高い音声処理を行なうために、ここで、音声／非音声の識別を行なうことも可能である（４２Ｂ）。音声／非音声の識別方法として、時間におけるエネルギーの変化度合いによる識別があげられる。音声には音波形エネルギーの強弱とその変化パターンがあり、それらを用いることで音声と非音声の識別を行なう。上述の通り、特徴量抽出４２Ａ、更には音声／非音声判別４２Ｂは、図示されない処理部（ＣＰＵ）のプログラム処理として実行される。

次に、ストリームデータ処理部１００にて、音源の選択（１００Ａ）、スムージング処理（１００Ｂ）、アクティビティデータ生成（１００Ｃ）が行なわれる。最後に、表示処理部２０３にて、アクティビティデータＡＤに基づいた、画面データ生成（２０３Ａ）が行なわれる。なお、これらの具体的構成は他の実施例とも共通する部分が多いので後述する。

図４は参加者の登録画面６０を示したものである。会議卓３０のそれぞれの座席に座るメンバとマイク（２０）とを対応させるために、画面の座席位置（６１Ａ〜６１Ｆ）の空欄に参加者の名前を入力して登録を行なう（６２）。図４では、座席位置６１Ａ、６１Ｂ、６１Ｃ、６１Ｄに、それぞれ、参加者の名前Ａ、Ｂ、Ｃ、Ｄを登録している例を示している。なお、この登録画面６０は、上述したＰＣの画面や、各自の座席位置に設置した手書き文字入力タブレットの入力画面等を用いれば良い。これらの登録作業は、これらの手段によって入力された名前データに基づき、集計処理サーバ２００の参加者登録インタフェース２０１を使用して行なわれる。

以上説明した第一の実施例の会議可視化システムにより、発言者および、その発言回数、対話シーケンス、会議の活性度を計算して、刻々と変わる会議の状況をリアルタイムに表示することが可能となるため、参加者にフィードバックがかかって、より積極的で活性度の高い議論を誘発することができる。

第一の実施例では、マイク２０から取得した音声データをベースに会議を可視化する方法を示した。第二の実施例においては、会議の参加メンバに無線センサノードと呼ばれるデバイスを与えることで、音声以外の情報も加味してより詳細に会議の状況を可視化する会議可視化システムを提供する。

まず、無線センサノードの構成について図１１を用いて説明する。図１１は、無線センサノード７０の構成の一例を示すブロック図である。無線センサノード７０は、メンバ自身の動きの測定（加速度を使用）、音声の測定（マイクロホンを使用）、着席位置の測定（赤外線の送受信を使用）を行なうセンサ７４と、センサ７４を制御するコントローラ７３と、無線基地局７６と通信を行なう無線処理部７３と、これらの各ブロックに電力を供給する電源７１、無線データの送受信を行なうアンテナ７５より構成される。センサ７４には具体的には、加速度センサ７４１、マイクロホン７４２、赤外線送受信器７４３が搭載されている。

コントローラ７３は、予め設定された周期、もしくは不定期にセンサ７４の測定データを読み込み、この測定データに予め設定したセンサノードのＩＤを加えて無線処理部７２に転送する。測定データにはセンシングを行った時間情報をタイムスタンプとして与える場合もある。無線処理部７２は、コントローラ７３から送られたデータを基地局７６（図１２に示す）に送信する。電源７１は、電池を使用する場合や、太陽電池や振動発電などの自律発電機構を具備する構成としても良い。

図１２に示すように、この無線センサノード７０を名札型に加工した名札型センサノード７０Ａをユーザが装着することにより、ユーザの状態（動き等）に関するセンシングデータを、リアルタイムに無線基地局７６を経由して、集計処理サーバ２００に送信することが可能となる。さらに、図１２に示すように、会議卓の各座席位置に設置された赤外線送信器７７からのＩＤ情報を、名札型センサノード７０Ａが赤外線送受信器７４３にて定期的に検出することで、着席位置の情報を自律的に集計処理サーバ２００に送信することも可能となる。このように、本実施例においては、名札型センサノード７０が、ユーザの着席位置を、自動的に集計処理サーバ２００に送付すれば、登録画面６０を使用した参加者登録処理（図４）を自動化することが可能となる。

さて次に、図５以下の図面を用いて、上述した会議可視化システムを実現するストリームデータ処理部１００について詳述する。上述の各実施例におけるアクティビティデータ生成にはストリームデータ処理を用いる。このストリームデータ処理と呼ばれる技術自身は公知の技術であり、Ｂ．Ｂａｂｃｏｃｋ、Ｓ．Ｂａｂｕ、Ｍ．Ｄａｔａｒ、Ｒ．Ｍｏｔｗａｎｉ ａｎｄ Ｊ．Ｗｉｄｏｍ、“Ｍｏｄｅｌｓ ａｎｄ ｉｓｓｕｅｓ ｉｎ ｄａｔａ ｓｔｒｅａｍ ｓｙｓｔｅｍｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＰＯＤＳ ２００２、 ｐｐ．１−１６．（２００２）、Ａ．Ａｒａｓｕ、Ｓ．Ｂａｂｕ ａｎｄ Ｊ．Ｗｉｄｏｍ、“ＣＱＬ： Ａ Ｌａｎｇｕａｇｅ ｆｏｒ Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｉｅｓ ｏｖｅｒ Ｓｔｒｅａｍｓ ａｎｄ Ｒｅｌａｔｉｏｎｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＤＢＰＬ ２００３、 ｐｐ．１−１９ （２００３）、などの文献に開示されている。

図５は図１のストリームデータ処理部１００の機能動作を説明するための図である。ストリームデータ処理は、絶え間なく到来するデータの流れを対象に、フィルタリング処理や集計処理などを、継続的に実行する技術である。個々のデータにはタイムスタンプが付与されており、データはタイムスタンプの昇順に並んで流れる。以下では、このようなデータの流れをストリームと呼び、個々のデータをストリームタプル、あるいは単にタプルと呼ぶ。ある一つのストリーム上を流れるタプルは、単一のデータ型に従う。このデータ型をスキーマと呼ぶ。スキーマとは任意個のカラムの組合せであり、各カラムは一つの基本型（整数型、実数型、文字列型など）と、一つの名前（カラム名）の組合せである。

ストリームデータ処理は、スキーマが定義されたストリーム上のタプルを対象に、リレーショナルデータベースの計算モデルである関係代数に準じて、射影、選択、結合、集計、和集合、差集合などの演算を実施する。但し、関係代数はデータの集合に対して定義されるので、絶え間なくデータ列が続く（即ち、無限に集合の要素が増え続ける）ストリームに対して関係代数を継続的に処理するには、処理対象となるタプルの集合を常に限定しながら実行する必要がある。

このために、ストリームデータ処理では、ある時刻において処理対象となるタプル集合を限定する、ウィンドウ演算が定義されている。このように、ストリーム上のタプルは、関係代数で処理される前に、まずウィンドウ演算によって、処理対象となる期間を定義される。以下では、この期間をタプルの生存期間と呼び、生存期間を定義されたタプルの集合をリレーションと呼ぶ。そして、このリレーションに対して関係代数が実施される。

ウィンドウ演算の例を、５０１〜５０３を用いて説明する。５０１はストリームを、５０２および５０３は、ストリーム５０１に対してウィンドウ演算を施した結果である、リレーションを示している。ウィンドウ演算は、生存期間の定義の仕方によって、時間ウィンドウと個数ウィンドウに分かれる。時間ウィンドウは、各タプルの生存期間を定数時間に定める。一方、個数ウィンドウは、同時に生存するタプルの個数を定数個に制限する。リレーション５０２および５０３は、ストリーム５０１を時間ウィンドウ（５２１）と個数ウィンドウ（５２２）で処理した結果を、それぞれ示している。

ストリームの図における各黒丸はストリームタプルを表す。ストリーム５０１には、１時２分３秒、４秒、７秒、８秒、１０秒、および１１秒に流れてくる、６つのストリームタプルが存在する。一方、リレーションの図における、黒丸を起点、白丸を終点とする各線分は、タプルの生存期間を表す。なお、丁度終点の時刻は生存期間に含まれない。リレーション５０２は、ストリーム５０１を、生存期間３秒の時間ウィンドウで処理した結果である。例として、１時２分３秒のタプルの生存期間は、１時２分３秒から１時２分６秒までとなる。但し１時２分６秒丁度は生存期間に含まれない。リレーション５０３は、ストリーム５０１を、同時生存数３個の個数ウィンドウで処理した結果である。例として、１時２分３秒のタプルの生存期間は、１時２分３秒から、その３個後に流れてくるタプルのタイムスタンプ１時２分８秒までとなる。但し１時２分８秒丁度は生存期間に含まれない。

リレーション上の関係代数は、入力のリレーションに対する演算結果として、次のような性質を持つ結果リレーションを出力する。まず、入力リレーションにおいて、ある時刻に生存するタプルの集合に対し、従来の関係代数を実施した結果を、該時刻における結果タプル集合と呼ぶ。このとき、任意の時刻において、該時刻における結果タプル集合が、結果リレーションにおいて該時刻に生存するタプルの集合と一致する。

リレーション上の関係代数の例を、５０４〜５０８を用いて説明する。この例は、リレーション５０４とリレーション５０５の間の差集合演算を示し、リレーション５０６、５０７、５０８は、その結果を示している。例えば、入力リレーション５０４と５０５において、１時２分８秒に生存するタプル集合は、それぞれ２個のタプルと１個のタプルから成る。従って、１時２分８秒の結果タプル集合（即ち、両タプル集合の差集合）は、２−１＝１個のタプルから成るタプル集合である。このような関係が、１時２分７秒から１時２分９秒までの期間で成立する（但し、１時２分９秒丁度は含まず）。従って、結果リレーションにおいて、この期間に生存するタプルは１個となる。結果リレーションの例として、５０６、５０７、５０８は、全てこの性質を持つ。このように、一般に、リレーション上の関係代数の結果は、一意には定まらない。但し、ストリームデータ処理においては、その何れも、リレーション上の関係代数の対象として等価である。

以上のように、リレーション上の関係代数の結果は一意には定まらないため、そのままアプリケーションに渡すことは好ましくない。これに対し、ストリームデータ処理では、リレーションをアプリケーションに渡す前に、再びストリームに変換する演算が用意されている。これを、ストリーム化演算と呼ぶ。ストリーム化演算は、等価な結果リレーションの全てを同一のストリームに変換する。

ストリーム化演算によってリレーションから変換されたストリームを、さらにウィンドウ演算でリレーションに変換することも可能である。このように、ストリームデータ処理の中では、リレーション化とストリーム化を任意に組合せることが可能である。

ストリーム化演算は、ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、ＲＳｔｒｅａｍの３種類に分かれる。ＩＳｔｒｅａｍは、リレーションにおいて、ある時刻に生存するタプル集合に、タプルの増加があった場合に、その増加分のタプルを、該時刻をタイムスタンプとするストリームタプルとして出力する。ＤＳｔｒｅａｍは、リレーションにおいて、ある時刻に生存するタプル集合に、タプルの減少があった場合に、その減少分のタプルを、該時刻をタイムスタンプとするストリームタプルとして出力する。ＲＳｔｒｅａｍは、一定時間間隔で、リレーションにおいてその時点で生存するタプル集合を、ストリームタプルとして出力する。

ストリーム化演算の例を、５０９〜５１１を用いて説明する。ストリーム５０９は、リレーション５０６〜５０８を、ＩＳｔｒｅａｍ（５２３）でストリーム化した結果である。例として、リレーション５０６では、１時２分３秒にタプルが０個から１個に、１時２分５秒に１個から２個に増える。このため、ストリーム５０９には１時２分３秒と１時２分５秒に、それぞれ増分１個のストリームタプルが出力される。この結果は、リレーション５０７に対して処理しても変らない。例えば、リレーション５０７においては、１時２分９秒に一つのタプルの生存期間が始まっているが、同時に、別のタプル（１時２分３秒から生存期間が始まるタプル）の生存期間が終わる。このとき、後者のタプルの生存期間に１時２分９秒丁度は含まれないため、１時２分９秒に生存するタプルは、丁度１個である。従って、１時２分９秒にはタプルの増減は無いことになり、リレーション５０６に対する結果と同じく、１時２分９秒のストリームタプルは出力されない。ＤＳｔｒｅａｍ（５２４）とＲＳｔｒｅａｍ（５２５）についても同様に、リレーション５０６、５０７、５０８の何れを対象としても、ストリーム化した結果は、それぞれストリーム５１０およびストリーム５１１になる（但し、ＲＳｔｒｅａｍのストリーム化間隔は１秒）。このように、一意には定まらない結果リレーションを、ストリーム化演算によって、一意のストリームに変換することが可能である。なお、以降の図では、生存期間終了の白丸を省略する。

ストリームデータ処理では、データ処理の内容をＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）という宣言型言語で定義する。ＣＱＬの文法は、リレーショナルデータベースにおいて標準的に利用される、関係代数に基づくクエリ言語ＳＱＬに、ウィンドウ演算、およびストリーム化演算の記法を追加した形式をとる。ＣＱＬ文法の詳細な定義は、ｈｔｔｐ：／／ｉｎｆｏｌａｂ．ｓｔａｎｆｏｒｄ．ｅｄｕ／ｓｔｒｅａｍ／ｃｏｄｅ／ｃｑｌ−ｓｐｅｃ．ｔｘｔに開示されている。ここでは、その概要を説明する。次の４行は、ＣＱＬ文法に従うクエリの一例である。

ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓｔ［ＲＯＷＳ ３］
ＷＨＥＲＥ ｃ２＝５）
ＦＲＯＭ句の“ｓｔ”は、ストリームを表す識別子（以下、ストリーム識別子、あるいはストリーム名と呼ぶ）である。ストリーム名に続く“［“と”］”に囲まれた部分は、ウィンドウ演算を表す記法である。例中の記述“ｓｔ［ＲＯＷＳ ３］”は、ストリームｓｔを、同時生存数３個の個数ウィンドウによって、リレーションに変換することを示している。従って、この記述全体では、リレーションを出力する表現となる。なお、時間ウィンドウは“［ＲＡＮＧＥ ３ ｓｅｃ］”のように、“ＲＡＮＧＥ”以降に生存期間を示す記法となる。この他の記法として、“［ＮＯＷ］”と、“［ＵＮＢＯＵＮＤＥＤ］”があり、それぞれ、非常に短い（但し、０ではない）生存期間と、永続を意味する。

ＦＲＯＭ句のリレーションを対象に、関係代数が実施される。例中の記述“ＷＨＥＲＥ ｃ２＝５”は、カラムｃ２が５であるタプルを選択することを示している。また、例中の記述“ＳＥＬＥＣＴ ｃ１”は、選択されたタプルのｃ１カラムのみを残して、結果リレーションとすることを示している。つまり、これらの記述の意味はＳＱＬと全く同じである。

さらに、ＳＥＬＥＣＴ句からＷＨＥＲＥ句までの、リレーションを生成する表現全体を、“（“と”）”で囲い、その前にストリーム化指定（例中の記述“ＩＳＴＲＥＡＭ”）を置く記法は、該リレーションのストリーム化演算を示している。ストリーム化指定は、他に“ＤＳＴＲＥＡＭ”と“ＲＳＴＲＥＡＭ”があり、“ＲＳＴＲＥＡＭ”では、“［“、”］”で囲って、ストリーム化間隔を指定する。

この例のクエリは、以下のように分解して定義することも可能である。

ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｓ ＡＳ
ｓｔ［ＲＯＷＳ ３］
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｒ ＡＳ
ＳＥＬＥＣＴ ｃ１
ＦＲＯＭ ｓ
ＷＨＥＲＥ ｃ２＝５
ＲＥＧＩＳＴＥＲ ＱＵＥＲＹ ｑ ＡＳ
ＩＳＴＲＥＡＭ（ｒ）
ここで、ウィンドウ演算の前に置けるのはストリームを生成する表現、ＦＲＯＭ句に登場できるのはリレーションを生成する表現、ストリーム化演算の引数はリレーションを生成する表現に、それぞれ限定される。

図５中のストリームデータ処理部１００は、以上のようなストリームデータ処理を実現するためのソフトウェア構成を示す。ストリームデータ処理部１００は、ＣＱＬで定義されたクエリが、クエリ登録インタフェース２０２に与えられると、クエリ解析部１２２でクエリを構文解析し、クエリ生成部１２１によって、木構造の実行形式（以下、実行木と呼ぶ）に展開する。該実行木は、各種演算を行なう演算子（ウィンドウ演算子１１０、関係代数演算子１１１、ストリーム化演算子１１２）をノードとし、オペレータ間を繋ぐタプルキュー（ストリームキュー１１３、リレーションキュー１１４）をエッジとして構成される。ストリームデータ処理部１００は、該実行木上の各演算子の処理を、適当な順番で実行することで、処理を進める。

上述したストリームデータ処理技術に対応し、各実施例において、音声処理サーバ４０から送られる発話情報であるストリーム５２、参加者登録インタフェース２０１を介して登録されるストリーム５３、５８などの、ストリームデータ処理１００の外部から送られるストリームタプルは、まず、ストリームキュー１１３に入る。これらタプルは、ウィンドウ演算子１１０によって生存期間を定義され、リレーションキュー１１４に入る。リレーションキュー１１４上のタプルは、関係代数演算子１１１によって、リレーションキュー１１４を介してパイプライン的に処理される。リレーションキュー１１４上のタプルは、ストリーム化演算子１１２によってストリーム化され、ストリームキュー１１３に入る。ストリームキュー１１３上のタプルは、ストリームデータ処理部１００の外部へ送られるか、ウィンドウ演算子１１０で処理される。ウィンドウ演算子１１０からストリーム化演算子１１２までのパスには、リレーションキュー１１４で接続された任意個の関係代数演算子１１１が置かれる。一方、ストリーム化演算子１１２からウィンドウ演算子１１０へは、一つのストリームキュー１１３で直接つながる。

次に、図１５を用いて、実施例の会議可視化システムにおけるストリームデータ処理部１００による会議可視化データ処理の実現方法を具体的に開示する。

１５００〜１５２１は、ストリーム、またはリレーションの、識別名、およびスキーマを表す。上側の太枠四角が識別名を、下側の四角の並びがスキーマを構成するカラム名を示している。７１０、７２０、７３０、８１０、８２０、８３０、８４０、８５０、９１０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１３２０、１３３０の角丸四角は、データ処理の基本処理単位を示している。基本処理単位のそれぞれを、ＣＱＬ文法に従うクエリで実現する。クエリ定義、および動作の説明は、図７〜１０、および図１３を用いて後述する。発話情報である音声特徴量データストリーム１５００は、音声処理サーバ４０から、音量補正値ストリーム１５０１、および参加者ストリーム１５０２は、参加者登録インタフェース２０１から、身振り強度ストリーム１５０３、およびうなずきストリーム１５０４は、名札型センサノード７０から、発言ログストリーム１５０５は、ＰＣ（キーストロークセンシング）１０から、それぞれ送られてくる。これらを、音源選択１００Ａ、スムージング処理１００Ｂ、およびアクティビティデータ生成１００Ｃの、各プロセスで順に処理して、出力となるストリーム１５１７〜１５２１を生成する。１５０６〜１５１６は、中間データとなるストリーム、またはリレーションである。

音源選択１００Ａの処理は、基本処理単位７１０、７２０、７３０から構成される。各処理の実現形態については、図７を用いて後述する。スムージング処理１００Ｂは、基本処理単位８１０、８２０、８３０、８４０、８５０から構成される。各処理の実現形態については、図８を用いて後述する。アクティビティデータ生成１００Ｃの処理は、基本処理単位９１０、９２０、９３０、９４０、１０００、１０１０、１０２０、１３１０、１３２０、１３３０から構成される。基本処理単位９１０〜９４０は、モニタ画面３００の３２０に可視化される発言数１５１７、３３０に可視化される発言時間１５１８、および会話数１５１９を生成する。これら基本処理単位については、図９を用いて後述する。基本処理単位１０００〜１０２０は、モニタ画面３００の３１１に可視化される活性度１５２０を生成する。これら基本処理単位については、図１０を用いて後述する。基本処理単位１３１０〜１３３０は、モニタ画面３００の３１３に可視化される発言ログ１５２１を生成する。これら基本処理単位については、図１３を用いて後述する。

次に、図６を用いて、入力ストリームのスキーマ登録について開示する。

コマンド６００を、例えば、集積解析処理サーバ２００の入力部からなどからクエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、入力ストリーム１５００〜１５０５を受け付ける６本のストリームキュー１１３が生成される。ＲＥＧＩＳＴＥＲ ＳＴＲＥＡＭ の直後はストリーム名を、括弧内はスキーマを示している。スキーマの、“，”に区切られた個々の記述は、カラムの名称と型の組合せを示している。

６０１は、音声特徴量データストリーム１５００（ｖｏｉｃｅ）に入るストリームタプルの例を示している。本例では、１０ミリ秒毎に、４つのマイクから、センサＩＤ（ｉｄカラム）と音量（ｅｎｅｒｇｙカラム）を組み合わせたストリームタプルが生成される様子を示している。

次に、図７を用いて、音源選択処理１００Ａの基本処理単位７１０、７２０、７３０の実現方法を開示する。

コマンド７００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、基本処理単位７１０、７２０、７３０を実現する実行木が生成される。コマンド７００は、３つのクエリ登録書式７１０、７２０、７３０に分けられ、それぞれ、基本処理単位７１０、７２０、７３０の処理内容を定義する（以下同様に、基本処理単位と、その処理内容を定義するクエリの登録書式を、同義として扱い、同一の番号で示す。また、クエリ登録書式を、単にクエリと呼ぶ）。

クエリ７１０は、１０ミリ秒ごとの各時刻において、最大の音量を記録するマイク２０を選択する。まず好適には、各マイクの音量に、定数の補正値を加算する。会議卓に取り付けられた各マイクの感度は、会議卓の形状、材質、壁に対する位置関係、マイク自体の品質、など様々な要因により、バラつきを持つため、該加算処理により、マイクの感度を均等化する。マイク毎に異なる補正値は、音量補正値ストリーム１５０１（ｏｆｆｓｅｔ）として参加者登録インタフェース２０１より登録される。図１のストリーム５８は、音量補正値ストリームの例である（センサＩＤカラム５８Ｓ、および補正値カラム５８Ｖが、それぞれ音量補正値ストリーム１５０１のｉｄカラム、およびｖａｌｕｅカラムを示す）。音声データストリーム１５００と、音量補正値ストリーム１５０１とを、ｉｄカラムに関する結合演算により結合し、ストリーム１５００の音量カラム（ｅｎｅｒｇｙ）の値に、ストリーム１５０１の補正値カラム（ｖａｌｕｅ）の値を加算し、この値を改めてｅｎｅｒｇｙカラムとする。該ｅｎｅｒｇｙカラムと、ｉｄカラムとを組み合わせたタプルから成る、ストリームを、ｖｏｉｃｅ＿ｒとする。ストリーム６０１とストリーム５８に対する、このクエリの結果をストリーム６０１Ｒに示す。

該ストリームｖｏｉｃｅ＿ｒから、集計演算“ＭＡＸ（ｅｎｅｒｇｙ）”によって最大音量を算出し、その値と同じ音量のタプルを、ｅｎｅｒｇｙカラムに関する結合演算により抽出する。ストリーム６０１Ｒに対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ＿ｓｅｔ）を、リレーション７１１に示す（クエリ７１０ではＮＯＷウィンドウを用いており、リレーション７１１の各タプルの生存期間は非常に短いため、点で図示する。以下、ＮＯＷウィンドウによって定義されるタプルの生存期間は点で示す。なお、本クエリに関しては、ＮＯＷウィンドウの代わりに、１０ミリ秒未満の時間ウィンドウを用いても構わない）。

同時刻に最大音量を記録するマイクが２つ以上存在する場合もある。これに対し、クエリ７２０は、クエリ７１０の結果から、センサＩＤが最小のマイクのデータのみを選択することで、マイクを一つに絞り込む。まず、集計演算“ＭＩＮ（ｉｄ）”によって最小ＩＤを算出し、その値と同じＩＤのタプルを、ｉｄカラムに関する結合演算により抽出する。リレーション７１１に対するこのクエリの結果（ｖｏｉｃｅ＿ｍａｘ）を、リレーション７２１に示す。

クエリ７３０は、クエリ７２０の結果から、閾値を超えるデータのみを音源として残す。また、センサＩＤを参加者データ５３と付き合わせて、参加者名に変換する。まず、ｅｎｅｒｇｙカラムに関して範囲選択（＞１．０）をかけ、ｉｄカラムに関する結合演算とｎａｍｅカラムの射影演算で、音源となる発話者名のストリームを生成する。リレーション７２１に対するこのクエリの結果（ｖｏｉｃｅ＿ｏｖｅｒ＿ｔｈｒｅｓｈｏｌｄ）を、ストリーム７３１に示す。以上で、音源選択１００Ａの処理が完了する。

次に、図８を用いて、スムージング処理１００Ｂの基本処理単位８１０、８２０、８３０、８４０、８５０の実現方法を開示する。

コマンド８００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、基本処理単位８１０、８２０、８３０、８４０、８５０を実現する実行木が生成される。

クエリ８１０は、クエリ７３０で得られた音源データにおける、同一発言者の連続する音源断片について、間欠部分を補完し、平滑化された発言期間を抽出する。まず、ウィンドウ演算“［ＲＡＮＧＥ ２０ ｍｓｅｃ］”によって、ストリーム７３１上の各タプルに２０ミリ秒の生存期間を与え、“ＤＩＳＴＩＮＣＴ”（重複排除演算）によって、同一発言者のタプル重複を排除する。ストリーム７３１に対するこのクエリの結果（ｖｏｉｃｅ＿ｆｒａｇｍｅｎｔ）を、リレーション８１１に示す。リレーション８１２は、該結果に至る中間状態であり、ストリーム７３１上の、ｎａｍｅカラムの値が“Ｂ”であるタプルについて、ウィンドウ演算で生存期間を定義した結果である。ストリーム７３１上では、９時２分５．０３秒、５．０５秒、および５．０７秒において、ｎａｍｅカラムＢのタプルが抜けているが、リレーション８１２では、２０ミリ秒の生存期間によって補完される。一方、９時２分５．０８秒と５．０９秒のようにデータが連続する箇所では、生存期間の重複が発生するが、ＤＩＳＴＩＮＣＴによって排除される。その結果、ｎａｍｅカラムＢのタプルは、生存期間が９時２分５．０２秒から５．１１秒までの、一本のタプル８１３に平滑化される。ｎａｍｅカラムＡ、Ｄのタプルのように、散発的に現れるタプルについては、タプル８１４、８１５、８１６のように、２０ミリ秒の生存期間が定義されたタプルが散在する結果となる。

クエリ８２０は、クエリ８１０の結果から、持続時間が非常に短い瞬間的な発言（期間）を、ノイズとして除去する。まず、リレーション８１１の各タプルについて、ストリーム化演算“ＩＳＴＲＥＡＭ”とウィンドウ演算“［ＲＡＮＧＥ ５０ ｍｓｅｃ］”によって、タプルの開始時刻から５０ミリ秒の生存期間を持つコピー（ｎａｍｅカラムの値が、元のタプルと同一のタプル）を生成し、差集合演算“ＥＸＣＥＰＴ”によって、リレーション８１１から差し引くことで、生存期間が５０ミリ秒以下のタプルを除去する。リレーション８１１に対するこのクエリの結果（ｓｐｅｅｃｈ）を、リレーション８２１に示す。リレーション８２２は、該結果に至る中間状態であり、リレーション８１１上の各タプルについて、生存期間５０ミリ秒のコピーを作成した結果である。リレーション８１１と８２２の差集合を取ると、タプル８１４、８１５、８１６は、タプル８２４、８２５、８２６によって完全に消去される。一方、タプル８１３については、タプル８２３の生存期間を差引かれて、９時２分５．０７秒から９時２分５．１１秒までの生存期間を持つタプル８２７が残る。このように、生存期間が５０ミリ秒以下のタプルは全て除去され、それ以上の生存期間を持つタプルのみが、実際の発言データとして残る。

クエリ８３０、８４０、および８５０は、クエリ８２０の結果から、ストリーム化演算ＩＳｔｒｅａｍ、ＤＳｔｒｅａｍ、およびＲＳｔｒｅａｍによって、それぞれ、発言の開始時刻、終了時刻、および発言中の時刻をタイムスタンプとする、ストリームタプルを生成する。リレーション８２１に対する、各クエリの結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ、ｓｔｏｐ＿ｓｐｅｅｃｈ、およびｏｎ＿ｓｐｅｅｃｈ）を、それぞれストリーム８３１、８４１、８５１に示す。以上で、スムージング処理１００Ｂが完了する。

次に、図９を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位９１０、９２０、９３０、９４０の実現方法を開示する。コマンド９００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理１００に投入することで、基本処理単位９１０、９２０、９３０、９４０を実現する実行木が生成される。

クエリ９１０は、クエリ８３０の結果から、会議中の累積発言回数をカウントする。まず、ウィンドウ演算“［ＲＯＷＳ １］”によって、発言開始タプルが発生する度にｎａｍｅカラムの値が切替るリレーションを生成する。但し、同一発言者の発言開始タプルが連続する場合には、リレーションは切替らない。このリレーションをストリーム化演算“ＩＳＴＲＥＡＭ”でストリーム化することで、発言者に変化があった際の、発言開始時刻を切り出す。さらに、該ストリームをウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続化し、ｎａｍｅカラムでグルーピングして、集計演算“ＣＯＵＮＴ”でカウントすることによって、発言者ごとの累積発話回数を算出する。

ｓｐｅｅｃｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｃｏｕｎｔ）を、リレーション９１１に示す。ストリーム９１２は、リレーション９０１に対するクエリ８３０の結果（ｓｔａｒｔ＿ｓｐｅｅｃｈ）である。リレーション９１３は、ストリーム９１２を［ＲＯＷＳ １］のウィンドウ演算で処理した結果である。ストリーム９１４は、リレーション９１３をＩＳｔｒｅａｍでストリーム化した結果である。このとき、タプル９１５の開始時刻に対して、ストリームタプル９１７が生成されるが、タプル９１５と９１６は、同一発言者“Ｂ”のリレーションであり、タプル９１５の終点とタプル９１６の始点は同一時刻（９時１８分１５秒）になるため、９時１８分１５秒のタプルは生成されない。ストリーム９１４を、ｎａｍｅでグルーピングして永続化してカウントした結果が、リレーション９１１となる。永続化したリレーションをカウントするので、ストリーム９１４にタプルが発生する度に、発言数が累積される。

クエリ９２０は、クエリ８５０の結果から、過去５分間における発言者ごとの発言時間を算出する。まず、ｏｎ＿ｓｐｅｅｃｈストリームの各タプルに対し、ウィンドウ演算“［ＲＡＮＧＥ ５ ｍｉｎ］”で、５分間の生存期間を定義し、ｎａｍｅカラムでグルーピングして、集計演算“ＣＯＵＮＴ”によってカウントする。この処理は、過去５分間において、ｏｎ＿ｓｐｅｅｃｈストリーム上に存在したタプルの個数を数えることに相当する。なお、ｏｎ＿ｓｐｅｅｃｈストリームタプルは、秒間１００個のレートで生成されるため、ＳＥＬＥＣＴ句でこの個数を１００で割って、秒単位の発言時間を算出する。

クエリ９３０は、クエリ８３０および８４０の結果から、ある発言の終了後３秒以内に、別の発言者の発言が開始されたケースを、二者間の会話として抽出する。まず、ｓｔｏｐ＿ｓｐｅｅｃｈストリームとｓｔａｒｔ＿ｓｐｅｅｃｈストリームの各タプルに対し、それぞれウィンドウ演算“［ＲＡＮＧＥ ３ ｓｅｃ］”と“［ＮＯＷ］”で、生存期間を定義し、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）により、ｓｔｏｐ＿ｓｐｅｅｃｈタプル発生の３秒以内に、ｓｔａｒｔ＿ｓｐｅｅｃｈタプルが発生する組合せを抽出する。結果は、ｓｔｏｐ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｒｅカラムに、ｓｔａｒｔ＿ｓｐｅｅｃｈ．ｎａｍｅをｐｏｓｔカラムに射影して出力する。ｓｐｅｅｃｈリレーション９０１に対するこのクエリの結果（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）を、ストリーム９３１に示す。ストリーム９３２は、リレーション９０１に対するクエリ８４０の結果（ｓｔｏｐ＿ｓｐｅｅｃｈ）であり、リレーション９３３は、ストリーム９３２の各タプルに３秒間の生存期間を定義した中間状態である。また、ストリーム９１２をＮＯＷウィンドウでリレーションに変換した結果は、９１２と同一の図になる。該リレーションと、リレーション９３３の結合演算の結果を、さらにＩＳｔｒｅａｍでストリーム化した結果が、ストリーム９３１となる。

クエリ９４０は、クエリ９３０の結果から、会議中の累積会話回数を、二者の組合せ別にカウントする。まず、ウィンドウ演算“［ＵＮＢＯＵＮＤＥＤ］”で永続化し、“Ｇｒｏｕｐ ｂｙ ｐｒｅ，ｐｏｓｔ”で、ｐｒｅカラムとｐｏｓｔカラムの組合せ別にグルーピングし、集計演算“ＣＯＵＮＴ”によってカウントする。永続化したリレーションをカウントするので、ストリーム９３１にタプルが発生する度に、会話数が累積される。

次に、図１０を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１０００、１０１０、１０２０の実現方法を開示する。クエリ１０００、１０１０、および１０２０を、クエリ登録インタフェース２０２を介して、ストリームデータ処理部１００に投入することで、それぞれ、基本処理単位１０００、１０１０、および１０２０を実現する実行木が生成される。これら３種のクエリは、全て会議の盛り上り度を算出する。但し、盛り上り度の定義は各クエリで異なる。

クエリ１０００は、ストリーム１５００（ｖｏｉｃｅ）の全マイクの音量値を、過去３０秒間累積した値として、盛り上り度を算出する。本クエリは、ウィンドウ演算“［ＲＡＮＧＥ ３０ ｓｅｃ］”と、集計演算“ＳＵＭ（ｅｎｅｒｇｙ）”により、過去３０秒間におけるストリーム１５００上のタプルのｅｎｅｒｇｙカラム値の和を計算する。また、ストリーム化演算“ＲＳＴＲＥＡＭ［３ ｓｅｃ］”によって、結果の出力を３秒間隔としている（以下、クエリ１０１０、１０２０についても同様）。以上、クエリ１０００では、会議出席者の発言エネルギーの総和を、盛り上り度の指標としている。

クエリ１０１０は、過去３０秒間における、発言者数と会話回数の積として、盛り上り度を算出する。この盛り上り度は先に説明した単位時間当たりの発言総回数と発言者総数の積から算出する議論活性化度５４の一具体例となる。クエリ１０１１は、ストリーム１５１４（ｓｐｅｅｃｈ＿ｓｅｑｕｅｎｃｅ）の、過去３０秒間のタプルをカウントする。該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとする。クエリ１０１２は、ストリーム１５１１（ｓｔａｒｔ＿ｓｐｅｅｃｈ）の、過去３０秒間のタプルをカウントする。該クエリの結果のリレーション名をｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔとする。クエリ１０１３は、両者の積を算出する。ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔとｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔのどちらのリレーションにおいても、自然数の値を持つｃｎｔカラムのみから成るタプルが、常に丁度一つ生存することになる。従って、両者の積を取った結果も、常に丁度一つのタプルが生存するリレーションとなる。

但し、この積を単純に“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＊ ｒｅｃｅｎｔ＿ｓｐｅａｋｅｒｓ＿ｃｏｕｎｔ．ｃｎｔ”で計算すると、一人の発言者が長時間話している期間では、会話数が０になるので、結果も０となってしまう。これを回避するため、“ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ”の代わりに、“（ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ ＋１／（１＋ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ））”を利用する。“＋”以降の、“＋１／（１＋ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔ）”の部分は、整数の商であるため、ｒｅｃｅｎｔ＿ｓｅｑｕｅｎｃｅｓ＿ｃｏｕｎｔ．ｃｎｔが０の場合に＋１、０より大きい場合に＋０となる。その結果、誰も発言者が居ない沈黙の期間は盛り上り度が０、一人の発言者が長時間話している期間は１、二人以上の発言者がいる期間は発言者数と会話数の積となる。以上、クエリ１０１０では、会議出席者の中で議論に参加している人数が多いこと、および、意見の交換が頻繁であることを、盛り上がり度の指標としている。

クエリ１０２０は、発言者の身振りの強度として、盛り上り度を算出する。クエリ１０２１は、身振りの瞬間強度を表すストリーム１５０３（ｍｏｔｉｏｎ）をＮＯＷウィンドウで処理した結果のリレーションと、発言者の発言期間を表すリレーション１５１０（ｓｐｅｅｃｈ）とを、ｎａｍｅカラムに関する結合演算にかけることで、発言中の出席者について身振り強度を抽出する。クエリ１０２２は、過去３０秒間における、発言者の身振り強度を累積する。以上、クエリ１０２０では、発言者の身振りの強弱が、議論の白熱度を反映すると仮定し、盛り上り度の指標としている。

ここで示した盛り上り度の定義は一例であり、会議の盛り上り度の数値化は、確立した定義のない、人間の主観に関わるデータであるため、試行を繰返し的確な定義を探索する必要がある。新しい定義を試行する度に、算出ロジックを、Ｃ、Ｃ＃、Ｊａｖａ（登録商標）などの手続き型言語でコーディングするのでは、開発工数が甚大である。特に、クエリ１０１０のような、発言間の順序関係に基づいた指標を算出するロジックは、コードが複雑化し、デバグも困難となる。これに対し、議論活性化度などを例示して説明した本実施例のように、ストリームデータ処理を利用することで、簡潔な宣言型クエリによる定義が可能となるため、このような工数を大幅に軽減する。

次に、図１３を用いて、アクティビティデータ生成１００Ｃ中の基本処理単位１３１０、１３２０、１３３０の実現方法を開示する。

コマンド１３００を、クエリ登録インタフェース２０２を介して、ストリームデータ処理１００に投入することで、基本処理単位１３１０、１３２０、１３３０を実現する実行木が生成される。

多くの出席者から賛同を得た発言は、会議中の重要発言であると捉える。このような発言を抽出するために、クエリ１３１０は、リレーション１５１０（ｓｐｅｅｃｈ）と、うなずき状態を表すストリーム１５０４（ｎｏｄ）から、発言者の意見が多数の出席者に賛同されている（＝うなずかれている）状態を抽出する。うなずき状態の検出は、名札型センサノード７０が備える加速度センサ７４１で計測する加速度値より、パターン認識技術を利用して、実現することが可能である。本実施例では、１秒間隔で、その時刻において出席者がうなずき動作中である場合に、該出席者名をｎａｍｅカラムに示すタプルが発生する、と仮定する。まず、ストリーム１５０４上の各タプルに対し、ウィンドウ演算“［ＲＡＮＧＥ １ ｓｅｃ］”によって１秒の生存期間を定義することで、出席者ごとのうなずき期間を表すリレーションが得られる（例：リレーション１３０２）。

該リレーションと、発言期間を表すリレーション１５１０（例：リレーション１３０１）を、ｎａｍｅカラムに関する結合演算（一致しないことを条件とする）にかけることで、発言者以外の出席者がうなずいている期間を、タプルの生存期間とするリレーション（例：リレーション１３１２）が得られる。該リレーションにおいて、生存タプルが２個以上ある（＝２人以上の出席者が、うなずきながら聞いている）期間を、ＨＡＶＩＮＧ句によって抽出する。このとき、射影演算によって、発言者の名前（ｓｐｅｅｃｈ．ｎａｍｅカラム）と、定数文字列’ｙｅｓ’の値を持つｆｌａｇカラムから成るタプルを出力する（例：リレーション１３１３）。この結果をＩＳｔｒｅａｍでストリーム化し、クエリ１３１０の結果を得る（例：ストリーム１３１１）。ストリーム１３１１は、発言者Ｂの発言が、他の出席者ＣとＤの二人にうなずかれたタイミングで、タプルが発生する様子を示している。

クエリ１３１０によって、重要発言の発生を抽出する一方、発言の内容は、ストリーム１５０５（ｓｔａｔｅｍｅｎｔ）としてＰＣ１０から入力される。発言内容は議事録係のキーストロークから抽出されるため、音声解析と加速度解析から自動抽出した重要発言の発生タイミングに対し、数十秒遅れて入力されることになる。これに対し、クエリ１３２０、およびクエリ１３３０は、ある発言者の重要発言が検出された後、最初に入力された該発言者の発言内容に、重要発言のフラグを立てる処理である。

クエリ１３２０は、発言者ごとに、発言重要度を表すフラグを保持するトグルスイッチの役目を果たす。該クエリの結果リレーションａｃｃｅｐｔａｎｃｅ＿ｔｏｇｇｌｅは、次にストリーム１５０５（ｓｔａｔｅｍｅｎｔ）から入力される発言内容が、重要発言となるか否かを、発言者ごとに表している（例：リレーション１３２１）。ｎａｍｅカラムは発言者名を示し、ｆｌａｇカラムは、’ｙｅｓ’／’ｎｏ’によって重要性を示している。クエリ１３３０は、ストリーム１５０５をＮＯＷウィンドウでリレーション化した結果と、クエリ１３２０の結果リレーションを、ｎａｍｅカラムに関する結合演算で処理し、発言内容に重要性の指標を付加して出力する（例：ストリーム１３３１）。

クエリ１３２０では、まず、ストリーム１５０５から発言内容の入力があった際に、その発言者に関する重要度のフラグを’ｎｏ’にクリアするタプルを生成する。但し、該タプルのタイムスタンプは、元となる発言内容タプルのタイムスタンプから、若干時刻を遅らせる。この処理を、“ＤＳＴＲＥＡＭ（ｓｔａｔａｍｅｎｔ［ＲＡＮＧＥ １ ｍｓｅｃ］）”の記述によって定義している。例として、ｓｔａｔｅｍｅｎｔストリーム１３０３上のストリームタプル１３０４が入力されると、そこから１ ｍｓｅｃ分タイムスタンプのずれたストリームタプル１３２４が、中間状態ストリーム１３２２上に発生する。このような’ｎｏ’タプルのストリームと、クエリ１３１０の結果を、和集合演算“ＵＮＩＯＮ ＡＬＬ”でマージする。例として、該ストリーム１３２２と、ストリーム１３１１のマージ結果が、ストリーム１３２３となる。このストリームを、ウィンドウ演算“ＰＡＲＴＩＴＩＯＮ ＢＹ ｎａｍｅ ＲＯＷＳ １］”でリレーション化する。このウィンドウ演算は、ｎａｍｅカラムの値に基づいて分けた各グループを、同時生存数１個の個数ウィンドウでリレーション化する。これにより、各発言者別に、重要度’ｙｅｓ’か’ｎｏ’どちらか一方のフラグが立つことになる。例として、ストリーム１３２３をリレーション化した結果が、リレーション１３２１となる。ここで、’ｎｏ’タプルのタイムスタンプを若干ずらす理由は、クエリ１３３０において、’ｎｏ’タプルと、その元となるｓｔａｔｅｍｅｎｔタプル自身が、結合するのを避けるためである。以上で、アクティビティデータ生成１００Ｃの処理が完了する。

続いて、アクティビティデータ生成１００Ｃによって得られたアクティビティデータに基づいて、表示処理部２０３、即ち集計処理サーバ２００の処理部（ＣＰＵ）で実行される描画処理プログラムによって得られる画面イメージを図１６、１７を用いて説明する。

図１６は、発言者の動きに基づいたアクティビティデータ１５２０を、動きの活性度３１１Ｍとして、活性度・発言表示３１０Ａに反映した画面イメージである。本画面により、会議内での活動について、単なる音声だけではなくメンバの行動面を併せて可視化することができる。

また、図１７は、うなずきによる発言の重要度を示すアクティビティデータ１５２１を、重要発言指標３１１ａとして、活性度・発言表示３１０Ｂに反映した画面イメージである。メンバの発言３１３と重要発言指標３１１ａとをリンクさせて表示することにより、どの発言が参加メンバの納得感を得たものなのかを可視化することができる。このように、本画面により、単なる音声だけではなく、メンバの納得度を併せて会議状況を可視化することができる。

さて図１４は、図２で示した機能モジュールでの処理シーケンスの別の実施例を示したものである。本実施例における処理シーケンスでは、音声処理部４２において、特徴量データを取得した後、音声処理サーバ４０において、音声／非音声判別処理、スムージング処理、及び音源選択処理を実行する。好適には、これらの処理も、音声処理サーバ４０の図示されない処理部（ＣＰＵ）のプログラム処理として実行される。

図１４において、図２同様、センサ（マイク）２０では音声データが取得される（２０Ａ）。次に、サウンドボード４１にて、音声のサンプリング処理が行なわれる（４１Ａ）。次に音声処理部４２にて、特徴量の抽出（エネルギーへの変換）が行なわれる（４２Ａ）。エネルギーは数ミリ秒の音波形の絶対値の２乗を全範囲に渡って積分したものである。

本実施例においては、音声処理サーバ４０の音声処理４２として、特徴量抽出（４２Ａ）から取得した特徴量データをもとに、音声／非音声の識別を行なう（４２Ｂ）。音声／非音声の識別方法として、数秒時間におけるエネルギーの変化度合いによる識別があげられる。音声には特有の音波形エネルギーの強弱とその変化パターンがあり、それらを用いることで音声と非音声の識別を行なう。

また、数秒単位の音声/非音声識別結果をそのまま用いると、数１０秒からなる意味のかたまりとしての1発話単位の区間を求めることが難しい。そこで、スムージング処理（４２Ｃ）を導入することにより、１発話単位の区間を求め，これを音源選択に使用する。

上述の部分は音声処理４２で、センサ（マイク）２０毎に行なう処理であり、最終的にどのセンサ（マイク）２０から音声が入力されたかを判断する必要がある。そこで本実施例においては、音声処理４２において、スムージング処理（４２Ｃ）に引続き音源選択４２Ｄを行ない、センサ（マイク）２０の中から実際に発話されたセンサ（マイク）２０を選択する。一番近くのセンサ（マイク）２０に届く音声は、その他のセンサ（マイク）２０より音声と判断される区間が長い。よって、本実施例においては、それぞれのセンサ（マイク）２０のスムージング処理４２Ｃの結果から一番長かったセンサ（マイク）２０を音源選択４２Ｄの出力とした。次に、ストリームデータ処理部１００にて、アクティビティデータ生成（１００Ｃ）が行なわれ、最後に、表示処理部２０３にて、アクティビティデータＡＤに基づいた、画面データ生成（２０３Ａ）が行なわれることは先に説明した通りである。

第一の実施例の会議可視化システムの構成図。 第一の実施例の会議可視化システムのシーケンス図。 第一の実施例の会議可視化システムの使用例を示す図。 第一の実施例の参加者登録画面のイメージ図。 実施例の一般的なストリームデータ処理の構成図。 実施例の入力ストリームのスキーマ登録例を説明するための図。 実施例の音源選択処理の実現形態を説明するための図。 実施例のスムージング処理の実現形態を説明するための図。 実施例のアクティビティデータ生成処理の実現形態を説明するための図。 実施例のアクティビティデータ生成処理の実現形態を説明するための図。 第二の実施例の無線センサノードのブロック図。 第二の実施例の名札型センサノードの使用形態を説明するための図。 実施例のアクティビティデータ生成処理の実現形態を説明するための図。 会議可視化システムの処理シーケンスの他の実施例を示す図。 ストリームデータ処理による、会議可視化データ処理の実現例を詳細に説明するための図。 会議可視化システムの各実施例における会議の活性化度表示の他の表示例を示す図。 会議可視化システムの各実施例における会議の活性化度表示の他の表示例を示す図。

符号の説明

１０…ＰＣ、２０…センサ（マイク）、３０…会議卓、４０…音声処理サーバ、１００…ストリームデータ処理部、２００…集計処理サーバ、３００…モニタ画面、３１０…会議活性度・発言内容表示、３２０…発言累積表示、３３０…発言シーケンス表示。

Claims (20)

1. 会議における複数の会議参加者間の対話状況を可視化して表示する会議可視化システムであって、
   前記会議参加者に対応した複数の音声収集部と、
   前記音声収集部から収集した音声データを処理し、発話情報を抽出する音声処理部と、
   前記音声処理部で抽出された前記発話情報が順次入力され、前記発話情報に対して、クエリ処理を施すことにより前記会議参加者の会議におけるアクティビティデータを生成するストリーム処理部と、
   前記ストリーム処理部で生成された前記アクティビティデータに基づき、前記会議参加者の対話状況を可視化して表示させる表示処理部とを有する
   会議可視化システム。
2. 請求項１記載の会議可視化システムであって、
   前記アクティビティデータは、前記会議参加者毎の発言累積回数と、前記会議参加者間の対話回数とを含む
   会議可視化システム。
3. 請求項１記載の会議可視化システムであって、
   複数の前記会議参加者中の発言者と発言内容をキーストローク情報として入力するキーストローク情報入力部を更に有し、
   前記ストリーム処理部は、前記キーストローク情報に対してクエリ処理を施すことにより、前記アクティビティデータとして前記会議参加者の前記発言内容を抽出する
   会議可視化システム。
4. 請求項１記載の会議可視化システムであって、
   前記発話情報は前記音声データから抽出した音声エネルギーである
   会議可視化システム。
5. 請求項４記載の会議可視化システムであって、
   前記ストリーム処理部は、前記音声エネルギーの最大値を出力する前記音声収集部に対応する前記会議参加者を発言者と判断する
   会議可視化システム。
6. 請求項１記載の会議可視化システムであって、
   前記ストリーム処理部は、前記音声収集部と前記会議参加者の対応付けを行なうための参加者登録インタフェースを有する
   会議可視化システム。
7. 請求項６記載の会議可視化システムであって、
   前記会議参加者の着席位置を示すＩＤ（識別子）を検出する検出器を有し、
   前記ストリーム処理部の前記参加者登録インタフェースは、前記検出器からの前記ＩＤに基づき、前記音声収集部と前記会議参加者の対応付けを行なう
   会議可視化システム。
8. 会議における複数の会議参加者に対応する複数のマイクからの音声データを音声処理、並びに集計処理し、前記会議参加者間の対話状況を表示させるサーバにおける会議可視化方法であって、
   前記会議参加者に対応した複数の前記マイクから収集した前記音声データを音声処理し、発話情報のストリームデータを抽出する工程と、
   前記発話情報のストリームデータに対して、クエリ処理を施すことにより前記会議参加者の会議におけるアクティビティデータを生成する工程と、
   前記アクティビティデータに基づき、前記会議参加者間の対話状況を表示させる工程とからなる
   会議可視化方法。
9. 請求項８記載の会議可視化方法であって、
   前記発話情報は前記音声データから抽出した音声エネルギーである
   会議可視化方法。
10. 請求項８記載の会議可視化方法であって、
    複数の前記会議参加者中の発言者と発言内容をキーストローク情報として受信する工程と、
    前記キーストローク情報に対してクエリ処理を施すことにより、前記アクティビティデータとして前記会議参加者の前記発言内容を生成する
    会議可視化方法。
11. 請求項８記載の会議可視化方法であって、
    前記アクティビティデータは、前記会議参加者毎の発言累積と、前記会議参加者間の対話回数とを含む
    会議可視化方法。
12. 請求項８記載の会議可視化方法であって、
    前記アクティビティデータは、単位時間当たりの、前記会議参加者の発言総回数と、発言を行なった前記会議参加者総数で決定される議論活性化度を含む
    会議可視化方法。
13. 請求項９記載の会議可視化方法であって、
    前記マイクと前記会議参加者の対応付けを行なう工程を更に有する
    会議可視化方法。
14. 請求項１３記載の会議可視化方法であって、
    前記アクティビティデータ生成工程において、複数の前記マイクに対応する前記音声エネルギーの最大値を出力する前記マイクに対応する前記会議参加者を発言者と判断する
    会議可視化方法。
15. 会議可視化システムにおける集計処理サーバであって、
    会議における複数の会議参加者の音声データを処理して抽出されたストリームデータである発話情報に対してクエリ処理を施すことにより前記会議参加者の会議におけるアクティビティデータを算出するストリーム処理部と、
    前記ストリーム処理部から入力される前記アクティビティデータを可視化して表示させる表示処理部とを有する
    集計処理サーバ。
16. 請求項１５記載の集計処理サーバであって、
    前記ストリーム処理部は、発言者と発言内容についてのキーストローク情報に対してクエリ処理を施すことにより、前記アクティビティデータとして前記会議参加者の発言内容を抽出する
    集計処理サーバ。
17. 請求項１５記載の集計処理サーバであって、
    前記ストリーム処理部は、前記発話情報に対する前記クエリ処理として、
    所定の時刻における複数の前記会議参加者に対応する前記発話情報の最大値を検出するクエリと、
    検出された前記発話情報の最大値に対応する前記会議参加者を発話者として特定し、前記発話者のストリームを生成するクエリとを実行する
    集計処理サーバ。
18. 請求項１７記載の集計処理サーバであって、
    前記ストリーム処理部は、前記発話情報に対する前記クエリ処理として、前記発話者のストリームを生成するクエリを実行するに際し、
    検出された前記発話情報の最大値が所定の閾値を越える場合にのみ、前記発話者を特定する
    集計処理サーバ。
19. 請求項１７記載の集計処理サーバであって、
    前記ストリーム処理部は、
    生成された前記発話者のストリームにおける、連続する同一の前記発話者の間欠部分を補完して平滑化された発言期間を抽出する
    集計処理サーバ。
20. 請求項１９記載の集計処理サーバであって、
    前記ストリーム処理部は、
    生成された前記発話者のストリームから、前記平滑化された発言期間を抽出するに際し、瞬間的な発言期間を削除する
    集計処理サーバ。

Images