(57)【要約】【課題】ネットワーク上でのカード形式による番組の提供【解決手段】番組コンテンツをＸＭＬ形式で受け取り、記述されたカード単位でコンシューマに情報提供を行う。（ａ）に示されているように、カード内のテキストが、音声合成サーバ１４８により、テキストから音声合成され、端末側にストリーミング・サーバ１４２から送られる。視覚素材表示２１０では、映像又は画像を表示する。エージェント２１４は、カードに記述されたテキストを、ジェスチャを伴いながら音声で伝える。また、（ｂ）に示されているように、バッファを設けることによって待機時間を削減している。番組を構成している１枚目のカードを処理している間に、２，３，…枚目のカードで指定された映像３３０，画像３２０，エージェント・アニメーションのデータ３５０等をあらかじめ、磁気ディスク２３０上にあるバッファに転送しておく。【選択図】図５
2005165438.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・コンテンツ流通システムのサーバ・システムにおいて、
表示すべき画像又は映像の指定，エージェント・アニメーションの動作，及びテキストを記述した複数のカードで構成された番組を格納した番組記憶手段と、
前記画像，前記映像，前記エージェント・アニメーションの動作のライブラリを格納した記憶手段と、
前記テキストを音声合成する音声合成手段と、
前記番組記憶手段から、番組を構成するカードを読み出して、該カードのテキストを前記音声合成手段で音声合成させるとともに、カードで指定された画像又は映像を読み出し、エージェント・アニメーションの動作を前記ライブラリから読み出して、カード・データ，画像又は映像のデータ，音声及びエージェント・アニメーションの動作データを送信する番組表示手段と
を備え、該番組表示手段は、画像又は映像及びエージェントのアニメーションの動作データを、表示されるべきカードより先に送信していることを特徴とするマルチメディア・コンテンツ流通システムのサーバ・システム。
【請求項２】
マルチメディア・コンテンツ流通システムの端末システムにおいて、
カードを受信する手段と、映像，画像，音声及びエージェントのアニメーションの動作データを受信するデータ受信手段と、
カード処理手段と、映像表示手段と、画像表示手段と、音声再生手段と、エージェント表示手段とを備え、
前記データ受信手段は、受信したデータをバッファするバッファ手段を有しており、カード処理手段で処理されたカードで指定された映像又は画像及びアニメーションの動作データは、前記バッファ手段から読み出されることを特徴とするマルチメディア・コンテンツ流通システムの端末システム。
【請求項３】
請求項２に記載の端末システムにおいて、
前記カードで指定された画像又は映像は、ファイル，位置及び拡大・縮小率で指定しており、
前記画像表示手段又は映像表示手段は、指定されたファイルが前のカードと同じファイルである場合、位置及び拡大・縮小率の差を求めて、該差から求めた変化率で変化させるカメラワーク生成手段を含むことを特徴とする端末システム。
【請求項４】
請求項２に記載の端末システムにおいて、
前記カードで指定されたエージェントの動作は、開始時間情報を含んでおり、
前記カード処理手段が読み出したエージェントの動作データを受け取った前記エージェント表示手段は、前記音声再生手段から経過時間情報を得て、前記開始時間により該データの動作の表示を開始することで、音声とエージェントの動作を同期させることを特徴とする端末システム。
【請求項５】
請求項４に記載の端末システムにおいて、
前記送られてきたエージェントの動作データは、エージェントを複数の部分に分割した、それぞれの部分ごとの動作データであり、
前記カードで指定する動作データは、部分ごとの動作データを指定しており、
前記エージェント表示手段は、部分ごとの動作データをバッファから読み出して表示することを特徴とする端末システム。
【請求項６】
請求項１に記載のサーバ・システムにおいて、
さらに、カード編集手段を備えており、
該カード編集手段は、カードに入力されたテキストを解析し、該解析の結果を用いて、所定の動作選択ルールによりエージェントの動作を前記動作のライブラリから選択するとともに、テキストを前記音声合成手段により音声合成し、対応する動作の開始時間を音声合成の経過時間から得ることで、エージェントの動作を生成するエージェント動作生成手段を含むことを特徴とするサーバ・システム。  
【請求項７】
請求項１又は６に記載のサーバ・システム、若しくは請求項２〜請求項５のいずれかに記載された端末システムを、コンピュータ・システムに構築させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストーリーを基にしたマルチメディア・コンテンツ流通システムに関するものである。
【背景技術】
【０００２】
メーリングリストや、電子掲示板システムなど、ネットワークを利用したコミュニティを通じて膨大な情報が流通している。このようなアプリケーションを利用して、より豊富で質の高い情報を流通させ、知識として蓄積していくためには、システムデザインにおいて、コミュニティ内のコミュニケーションを活性化させるための工夫が必要である。この問題への1つのアプローチが、チャットシステムやテレビ会議システム等へのエージェント技術の適用である（非特許文献１，２参照）。これらのシステムでは、擬人化エージェントが仮想空間でユーザの分身として振舞い、人間同士のコミュニケーションを媒介する。一方、擬人化エージェントを用いて、人対コンピュータのコミュニケーションの円滑化を目指すシステムもある。ｗｅｂページ上でのコマーシャル・エージェントや、ニュースキャスター・エージェント等は最近多く見かけられる例である（非特許文献３参照）。これらはコミュニティ・メンバーに情報提供を行うエージェントである。しかし、従来、このような情報提供エージェントを実装する際には、エージェントの動作やその実行のタイミングを記したスクリプトを人手で作成する必要があり、コンテンツが日々更新されるようなサービスに利用することは難しかった。
【０００３】
さて、従来のシステムとして、放送型コミュニティ支援システム（Public Opinion Channel：ＰＯＣ)（非特許文献４参照）がある。ＰＯＣは、１００字程度のメッセージ，ＵＲＬ，画像からなる知識カードを情報発信の最小単位とする。ユーザが知識カードをＰＯＣシステムに投稿すると、それがコミュニティのメンバーにも視聴可能となる。また、ＰＯＣの拡張であるEgoChatシステム（非特許文献５参照）では、２人の分身エージェントが番組内容を会話的に演じることが可能になった。
しかし、これまでのシステムでは、映像コンテンツが扱えないなど、テレビ放送型システムとして最も重要である、動的なコンテンツの表現が不十分であった。
【０００４】
【非特許文献１】Hideyuki Nakanishi, Chikara Yoshida, Toshikazu Nishimura and Toru Ishida. FreeWalk: A 3D Virtual Space for Casual Meetings. IEEE Multimedia, Vol.6, No.2, pp.20-28, 1999.
【非特許文献２】高橋徹  武田英明  TelMeA: 非同期コミュニティシステムにおけるAvatar-likeエージェントの効果とWebベースシステムへの実装,電子情報通信学会論文誌 D-I, Vol.J84-D-I No.8 pp.1244-1255, 2001.
【非特許文献３】ANANOVA, http://www.ananova.com.
【非特許文献４】FUKUHARA, T., FUJIHARA, N., AZECHI, S., KUBOTA, H., and NISHIDA, T.:Public Opinion Channel: A network-based interactive broadcasting system for supporting a knowledge-creating community, In R.J.Howlett, N.S.Ichalkaranje, L.C.Jain, and G.Tonfoni(eds.); Internet-Based Intelligent Information Processing Systems, World Scientific Publishing, chapter 7(pp.227-268)(2003).
【非特許文献５】久保田秀和  西田豊明 ユーザの過去の発言を利用した複数エージェントによる創造的な対話の生成, 電子情報通信学会論文誌, Vol. J84-D-I, No.8, 2001.
【非特許文献６】M. Onishi H et al., "Automatic Image Production Using Digital Camera Work,"Meeting on Image Recognition and Understanding 2002 (MIRU2000),  vol.I2002,pp.331-336.
【非特許文献７】Cassell, J., Vilhjalmsson, H., Bickmore, T. "BEAT: the Behavior Expression Animation Toolkit." Proceedings of SIGGRAPH '01, pp. 477-486, 2001.
【非特許文献８】Sadao Kurohashi and Makoto Nagao. 1994. A Syntactic Analysis Method of Long Japanese Sentences Based on the Detection of Conjunctive Structures. Computational Linuguistics, 20(4): 507-534, 1994.
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、カードで表現された番組における映像表現を向上させるとともに、ネットワークを介して接続されている端末側の処理を軽減することである。
【課題を解決するための手段】
【０００６】
上述の目的を達成するために、本発明は、マルチメディア・コンテンツ流通システムのサーバ・システムにおいて、表示すべき画像又は映像の指定，エージェント・アニメーションの動作，及びテキストを記述した複数のカードで構成された番組を格納した番組記憶手段と、前記画像，前記映像，前記エージェント・アニメーションの動作のライブラリを格納した記憶手段と、前記テキストを音声合成する音声合成手段と、前記番組記憶手段から、番組を構成するカードを読み出して、該カードのテキストを前記音声合成手段で音声合成させるとともに、カードで指定された画像又は映像を読み出し、エージェント・アニメーションの動作を前記ライブラリから読み出して、カード・データ，画像又は映像のデータ，音声及びエージェント・アニメーションの動作データを送信する番組表示手段とを備え、該番組表示手段は、画像又は映像及びエージェントのアニメーションの動作データを、表示されるべきカードより先に送信することを特徴とする。
また、マルチメディア・コンテンツ流通システムの端末システムにおいて、カードを受信する手段と、映像，画像，音声及びエージェントのアニメーションの動作データを受信するデータ受信手段と、カード処理手段と、映像表示手段と、画像表示手段と、音声再生手段と、エージェント表示手段とを備え、前記データ受信手段は、受信したデータをバッファするバッファ手段を有しており、カード処理手段で処理されたカードで指定された映像又は画像及びアニメーションの動作データは、前記バッファ手段から読み出されることを特徴とする。
【０００７】
前記カードで指定された画像又は映像は、ファイル，位置及び拡大・縮小率で指定しており、前記画像表示手段又は映像表示手段は、指定されたファイルが前のカードと同じファイルである場合、位置及び拡大・縮小率の差を求めて、該差から求めた変化率で変化させるカメラワーク生成手段を含むこともできる。
そして、前記カードで指定されたエージェントの動作は、開始時間情報を含んでおり、前記カード処理手段が読み出したエージェントの動作データを受け取った前記エージェント表示手段は、前記音声再生手段から経過時間情報を得て、前記開始時間により該データの動作の表示を開始することで、音声とエージェントの動作を同期させることもできる。
前記送られてきたエージェントの動作データは、エージェントを複数の部分に分割した、それぞれの部分ごとの動作データであり、前記カードで指定する動作データは、部分ごとの動作データを指定しており、前記エージェント表示手段は、部分ごとの動作データをバッファから読み出して表示してもよい。
その上、サーバ・システムにおいて、さらに、カード編集手段を備えており、該カード編集手段は、カードに入力されたテキストを解析し、該解析の結果を用いて、所定の動作選択ルールによりエージェントの動作を前記動作のライブラリから選択するとともに、テキストを前記音声合成手段により音声合成し、対応する動作の開始時間を音声合成の経過時間から得ることで、エージェントの動作を生成するエージェント動作生成手段を含んでもよい。
上述したこれらのシステムを構築させるプログラムも本発明である。
【発明の効果】
【０００８】
上述した本発明の構成により、端末側では、特別な環境を用意する必要がなく、映像やエージェント・アニメーションによる番組を視聴することができる。
また、提供された番組の視覚表現として、カメラワークや音声による情報と同期したエージェント・アニメーション等を楽しむことができる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施形態を、図面に基づいて説明する。
＜マルチメディア・コンテンツ流通システム（ＳＰＯＣ）の概要＞
図１は、本発明の実施形態である、ネットワーク上において、ストーリーに基づくマルチメディア・コンテンツ流通システム（ＳＰＯＣ）の概要を示す図である。
ＳＰＯＣは、大きく分けて図１のように３つのアプリケーションに分けられる。
（Ａ）作成者（デザイナ）がコンテンツに用いる画像や映像を複雑な作業なしで容易に収集、蓄積できるよう支援するためのアプリケーションである素材収集ツール（Material Collector）１１０
（Ｂ）デザイナが（Ａ）の機能によって収集した画像や映像を用いてコンテンツを作成するためのアプリケーションであるカード編集ツール（Editor）１２０
（Ｃ）作成されたコンテンツをエージェントによってコンシューマに提供するためのアプリケーションである番組表示ツール（Viewer）１３０
次に、それぞれの機能とコンテンツの構造について説明する。
（Ａ）素材収集ツール（Material Collector）１１０
パソコンやデジタルカメラ、デジタルムービー・カメラの普及によって画像や映像を併せた意見や情報を表現する機会は増えてきている。しかし、特に映像をネットワーク上で情報公開に利用するには一般に次のような作業が必要である。
（１）撮影
（２）ストリーミング形式のファイルに変換
（３）ファイルのネットワーク上公開領域へのアップロード
これらの作業は、特別な技術を持たないユーザがデザイナになる際に障害となることが考えられる。そのため作業の簡略化を行うための機能を持たせた。現在、多くのパソコンやモバイルの多くがＷＥＢブラウザをサポートしているため、ＵＳＢカメラとマイクを使い、ＷＥＢブラウザ越しに直接ネットワークを介して、撮影しながら公開領域に映像ファイルを作成することによって、撮影直後に、コンテンツの作成に映像ファイルを用いることができることとした。
（Ｂ）カード編集ツール（Editor）１２０
この機能は、デザイナがコンテンツを作成するための機能である。ＰＯＣでは、画像と１００文字程度のテキストからなるＰＯＣカードと呼ばれるデータ単位によって、ユーザからの投稿を管理している。ＳＰＯＣでもこのカード形式を引き継いだ。このカードについては、後で詳しく説明する。
コンテンツは番組と呼ばれる単位で管理される。番組は１枚以上のカードから成る。カードはそれぞれ表示していく順番をつけることによって構成される。カードには、映像の時間軸に対する断片（ｅｘ．計３分の映像ファイルの内、２０秒目から３２秒目の映像部分を指定するなど）、または映像・画像は拡大率、縮小率、表示する範囲を指定する（ｅｘ．６００×４８０ピクセルの画像を２倍に拡大し、表示する範囲を座標（４００，４００）中心とするなど）、エージェントのアニメーション動作等の加工した資料とテキストからなる。エディタ１２０の機能は大きく分けて以下のようなものが含まれている。
（１）カードの作成
（２）カードに付加する映像ファイル、画像ファイルの指定と映像部分の抜き出し、または映像や画像の拡大率、縮小率の指定と表示範囲の指定、及びテキストの入力
（３）エージェント・アニメーションの作成
（４）作成されたカードの表示する並び順の決定
以上がコンテンツである番組の作成に必要な手順である。このエディタ１２０についても、後で詳しく説明する。
（Ｃ）番組表示ツール（Viewer）１３０
ユーザがコンテンツの番組を見るための機能である。ビューア１３０は、大きく分けて２つの部分に分かれる。エージェント部分と映像や画像の表示部分である。
エージェントは、テキストからの音声合成から得られた音声ファイルとジェスチャーによって見る、聞くことができる情報提供を行う。カードがメディアに映像を指定していれば、エージェントの音声に併せてカードで定義された映像部分をユーザに対して提供する。エージェント・アニメーションについては、後で詳しく説明する。
また、ＳＰＯＣでは、静的な画像を動的な視覚変化のある画像に変化させるためにデジタルカメラワークを利用した。カメラワークは、ＴＶ番組などでは重要な役割を果たす。大西はデジタルカメラワークというテクニックを提案した（非特許文献６参照）。これは静的な画像が擬似的にチルトやズームといったカメラワークのように見えるよう描画していくテクニックである。これを、ＳＰＯＣシステムでは自動的に行うようにした。これについては後で詳しく説明する。
【００１０】
先に述べたＳＰＯＣの機能（Ａ）素材コレクタ１１０、（Ｂ）エディタ１２０、（Ｃ）ビューア１３０は、バックグラウンドのサーバによって必要な処理を行っている。主なサーバは、図２に示すように、ウエブサーバ（ＨＴＴＰサーバ）１４０、データベース・サーバ１４４、ストリーミングサーバ１４２、音声合成サーバ１４８である。ウエブサーバ１４０は、主に端末とサーバとのトランザクション（例えば、カードの新規作成や修正、削除）のＣＧＩによる処理と、ユーザに対するウエブ・ブラウザを通した端末側のインターフェイスの公開を行う。また、ユーザの特定に必要なセッション管理の機能も提供している。データベース・サーバ１４４は、ウエブサーバ１４０のＣＧＩを通したユーザ毎のカードのデータの作成、修正、削除、また、番組に必要なＸＭＬデータを一括に管理する。ストリーミング・サーバ１４２は、ＷＥＢアプリケーションから送られる映像データのストリーミング形式での保存、管理、カードによって指定された部分の映像ファイルの作成、管理、また、ビューアへの映像やエージェントの音声のストリーミング・サービスを行う。音声合成サーバ１４８はエージェントの会話に必要な音声をユーザの音声合成環境に依存させないためにある。基本的にはカードのテキスト作成時にテキストから音声ファイルを作成し、ストリーミング・サーバ１４２を通じてビューア１３０に送られる。
【００１１】
＜ビューアによる番組の表示＞
図面図３〜図９を用いて番組表示を説明する。
図３に、サーバ側のビューア１３０から端末側に、カード形式による番組構成１５０が送られて、ウエブのブラウザ内のインターフェース２００で表示されている様子を示す。このブラウザ内のインターフェース２００は、例えば、ブラウザ内に表示する表示ソフトとして、普及しているMacromedia flashで実装することができる。本実施形態でも、このMacromedia flashで実装している。
図４にインターフェース２００の番組表示２１０内の詳細が示されている。図４において、番組表示２１０内には、視覚素材表示２１２と、音声と同期して動くエージェント・アニメーション２１４が表示されている。
図５（ａ）には、カードと表示との関係を示しており、図５（ｂ）には、端末側の構成を示している。図５（ａ）に示されているように、カード内のテキストが、音声合成サーバ１４８により、テキストから音声合成され、端末側にストリーミング・サーバ１４２から送られる。視覚素材表示２１２では、映像、画像、および映像や画像を動くカメラで写したように表示する。
【００１２】
サーバ側のビューア１３０は、番組コンテンツをＸＭＬ形式で受け取り、記述されたカード単位で端末側のコンシューマに情報提供を行う。エージェント２１４は、カードに記述されたテキストを、ジェスチャを伴いながら音声で伝える。これに合わせてカードで定義された映像や画像、またはカード間をつなぐカメラワークによる動的な画像を作りながらの視覚変化のある番組コンテンツによる情報提供を行う。
映像データや画像データなど、テキストに比べ容量の多いファイルによる情報提供を行う場合に問題となるのが、カードとカードの間における映像・画像ファイルのサーバからファイルへの転送に必要な待機時間である。このシステムでは、バッファを設けることによって待機時間を削減している。これは番組を構成している１枚目のカードで指定された映像・画像ファイルを表示している間に、２，３，…枚目のカードで指定された映像ファイル３３０，画像ファイル３２０，エージェント・アニメーションのデータ（アニメーション・ライブラリ）３５０等をあらかじめ、磁気ディスク２３０上にあるバッファに転送しておく。これによって、カードからカードへの処理の切れ目でも転送待ちが生じにくくなる。
サーバ側のビューア１３０から、番組を構成するカード、画像ファイル，映像ファイル，音声ファイルや、アニメーションを表示するためのアニメーション・データ等が送られてくる。端末側のアプリケーション（ブラウザ＋表示ソフト（Macromedia flash）＋ストリーミングで送られた映像の表示ソフト＋音声再生ソフト（例えばＭＰ３プレイヤー））で、送られてきたカードを順次解析しながら、テレビの番組のように、図４に示した様に表示する。
【００１３】
＜デジタル・カメラワーク＞
カメラワークは対象となる画像や映像に定義されている拡大・縮小率と表示範囲を利用して自動的に行われる。図６に、このシステムでのデジタルカメラワークの概要を示す。カメラワークは、同一の画像ファイル３３０から異なる拡大・縮小率（拡縮率）、異なる表示範囲３３２，３３３の指定によって作成された視覚素材を含む、２枚のカード（１）３１２、カード（２）３１３が連続して並べられたときに行われる。このように、同一画像を基に作成されたカードが続く時は、何らかのカード間の関係があるとみなす。そして、画像の拡縮率を、表示範囲をいきなり変更するのではなく、徐々に変化していくように画像の描画を行い、ターゲットＡからターゲットＢに表示を徐々に移動させ、２枚のカードをつなげる。仮に、異なる画像ファイルによるカードが間に入った場合、カメラワーク処理は起らない。
【００１４】
図７に示した、フローチャートで、デジタル・カメラワーク処理の詳細を説明する。図７において、カード（１）の画像Ａの表示が終了する（Ｓ４０２）と、次のカード（２）の画像Ｂが、カード（１）の画像Ａと同じファイルかチェックする（Ｓ４０４）。同じファイルでない場合、デジタル・カメラワークの処理は行われず、カード（２）の画像を表示する。
カード（１）とカード（２）の画像が同じファイルである場合、デジタル・カメラワークが行われる（Ｓ４１０）。その場合、まず、カード（１）とカード（２）の、ｘ，ｙ座標と拡大・縮小率（拡縮率）の差を求める。
例えば、図７（ａ）に示されているカード（１）の画像Ａの座標（画像の左上の座標を画像の座標としている）は（ｘ，ｙ）＝（１００，３００）であり、拡縮率は１００％である。なお、ｘ，ｙ座標の単位はピクセル（ｐｉｘ）である。図７（ｂ）に示されているように、カード（２）の画像Ｂの座標（画像の左上の座標を画像の座標としている）は（ｘ，ｙ）＝（４００，６００）であり、拡縮率は１５０％である。したがって、カード（１）とカード（２）の、ｘ座標の差は３００で、ｙ座標の差は３００であり、拡縮率の差は５０％である。
次に、カード（１）の画像の、ｘ座標，ｙ座標，拡縮率のそれぞれの差から、次のカード（カード（２））の画像を表示する時間（所定時間）で割ることにより、変化分ΔｐｉｘやΔ％を求める。
この変化分づつ、カード（１）の画像Ａを変化させて表示して（図７（ｃ）参照）、所定時間後に、カード（２）の画像Ｂとなる（Ｓ４１２）。
なお、映像においても、同じ映像ファイルを指定したカード（１），カード（２）に対して、カード（１）で指定した映像の終了フレームの画像と、カード（２）で指定した映像の開始フレームの画像に対して、上述と同様の処理を行うことで、同様にデジタル・カメラワークの処理を実現することができる。
【００１５】
＜エージェント・アニメーション＞
図８に、図４に示した番組表示２１０内のエージェント２１４のアニメーション例を示す。
ウエブを基としたアプリケーションを介して、アニメーション化したキャラクタを制御するために、ＲＩＳＡアニメーション・システムをマクロメディア・フラッシュ（Macromedia Flash）で実装している。ＲＩＳＡが行ったジェスチャと顔の表情の変化のスナップ・ショットが、図８に示されている。
このアニメーション・システムの基礎的アイディアは、各身体部分のアニメーション断片を集合することで、エージェント・アニメーションを構成する。エージェントの身体は、１２の部分（頭，２つの眉、２つの目，２つの瞳，口，２つの手，２つの腕）に分割される。小さいアニメーション断片が各身体部分に定義される（例えば、右の眉を３０度上に動かす，右腕を身体の前に動かす）。動作ライブラリの全体の数は、手のジェスチャに対する逆の動作を含んで、３００以上である。これらのアニメーションを組み合わせることで、様々な種類のエージェント動作が作成される。組み合わせ自体はほとんど無限であるが、これらのいくつかは、非言語の合図としては意味ある動作として表現されていないと思われる。
【００１６】
図９を用いて、ＲＩＳＡアニメーション・システムが、カード上のアクション表示から、音声と同期したアニメーションを表示しているかを説明する。
ＲＩＳＡアニメーション・システムは、ＸＭＬで記述されているカード３１０中の<agent>タグの中に書かれたスクリプトを、時間順に順次実行することにより、エージェン・アニメーションと台詞の音声（ＭＰ３等の形式）とをビューアー上で同期させることを実現している。
図９において、音声再生ソフト（例えば、ＭＰ３プレーヤー）で音声ファイル３４０の再生が開始されると、音声ファイルのプレーヤーに対して、音声ファイル中の現在のポジションを問い合わせることにより、音声開始後の経過時間を知ることができる。
アクション・コマンド（actionタグで記述）中のアニメーション開始時間が、音声経過時間と一致したら、エージェント・アニメーション・ライブラリ（体の部分的なアニメーションの集合）３５０の中から、該当するＩＤのアニメーションを実行する。
例えば、以下のようなアクション・コマンドがカード中のエージェント・タグに記述されているとする。
<Action ID="188" Srt="0.02" /> 
<Action ID="189" Srt="0.06" /> 
音声再生開始と同時に、ＲＩＳＡアニメーション・システムは、音声ファイルのプレーヤーへの問い合わせを開始する。音声ファイルのプレーヤーに問い合わせ、音声の再生が開始後０．０２秒経過したことがわかると、アニメーション・ライブラリの中から１８８というＩＤのアニメーションを実行する。同様に、音声開始後０．０６秒経過したことがわかると、１８９番のアニメーションを実行する。これにより、音声と同期してアニメーションを表示することが可能になる。
【００１７】
＜編集ツール（エディタ）１２０の詳細＞
図１０〜図１６を用いて、エディタの詳細について説明する。
まず、図１０，図１１を用いて、エディタの概要と視覚素材の編集について説明する。
図１０は、エディタ１２０の概要を説明する図である。
素材収集ツール１１０によって収集された映像や画像は、エディタ１２０によってカード形式の情報単位として編集されて、番組コンテンツに組み込まれる。エディタ１２０には、カードの並び順番を決定し、番組構成を行う番組エディタ、個々のカードの編集を行うカード・エディタがある。
図１０において、番組コンテンツは、次の手順によって作成される。
まず、番組エディタで新規カードを作成する。
(１）−１  カード・エディタを呼び出し、収集した映像や画像を見ながら、映像の場合は、開始と終了のフレームを特定することで、カードに必要な部分を指定して抜き出す。
（１）−２  拡大・縮小率、表示範囲を指定する。
(２）テキストを加える。
このようにして、順次、カードの編集を行っていく。
(３)編集後のカード群を、ドラッグ＆ドロップで順番を入れ替えながら、必要に応じて、カードの編集を繰り返すことによって番組コンテンツが作成される。
作成されたコンテンツのデータはデータベースサーバに記録される。
【００１８】
図１１に、視覚素材（映像及び画像）のズーム・スケールと焦点された領域を特定することの操作例を示す。図１１において、同じ画像３２０に対して、カード１では、ターゲットＡに焦点を当ててズームしており、カード２では、ターゲットＢに焦点を当ててズームしている。ユーザは、この処理を直感的にＧＵＩ（ズーム・バー）を操作することで行うことができる。映像においても同様に指定することができる。
【００１９】
＜エージェント・アニメーション＞
このシステムでは、番組に語り手を実装するため、エージェント動作生成システム（ＣＡＳＴ）を開発した。ＣＡＳＴは、エディタ１２０により起動されて、エージェント・アニメーション・スケジュールを自動的に計算するとともに、エージェントに対する同期した音声を合成する。ＣＡＳＴへの入力は、エディタ１２０のテキスト・フィールドにタイプされたテキストである。ユーザがテキストをタイプすると、ＣＡＳＴに送られる。
ＣＡＳＴは、次に示す４つの主なモジュールで構成されている。
（１）エージェント動作選択モジュール（Agent Behavior Selection Module：ABS）
（２）言語タグ付与モジュール（Language Tagging Module：LTM）
（３）フラッシュ対応キャラクタ・アニメーション・システム（Flash-based character animation system：RISA （RIStex animated Agent system））
（４）テキスト音声エンジン（Text-to-Speech engine：TTS）（音声合成ツール）
ＣＡＳＴの処理を図１２のフローチャートに示す。図１２において、テキスト入力を受け取る（Ｓ５０２）と、テキストをエージェント動作選択モジュール（ＡＢＳ）へ送る。ＡＢＳは、言語タグ付与モジュール（ＬＴＭ）により分析して（Ｓ５０４）、言語情報を得る。そして、この言語情報に基づき、適切な身振りと顔の表情を選択する（Ｓ５０６）。
エージェント動作選択モジュール（ＡＢＳ）は、テキスト音声エンジン（ＴＴＳ）を呼び出すことで、タイミング情報を得て（Ｓ５０８）、エージェントの動きセットのために、タイム・スケジュールを計算する（Ｓ５１０）。エージェント動作選択モジュール（ＡＢＳ）からの出力は、ＲＩＳＡにより解釈され実行できる、アニメーション命令の集合である（Ｓ５１２）。
以下に、各モジュールにおける処理を詳しく説明する。
【００２０】
＜エージェント動作選択モジュール（ＡＢＳ）＞
エージェント動作選択モジュール（ＡＢＳ）への入力は単純なテキストであり、出力は、ＲＩＳＡアニメーション・システムに対する命令の集合である。ＡＢＳに対するシステム・アーキテクチャは、ＢＥＡＴ（非特許文献７参照）に基づいている。しかしながら、ＢＥＡＴは英語用として開発されており、日本語の言語情報に対する適切な非言語動作を選択することはできない。このため、日本語のテキストを用いて、適切なエージェントの動きを選択する機構を設計・開発する必要があった。このため、次のような機構が必要である。
−−非言語動作を決定する日本語言語情報を注釈
−−動作選択ルールを日本語テキストに適用して非言語動作を選択
−−日本語特有の構文単位である文節単位ごとに動作を割り当て
これらの各々に対して、次の節で説明する。
【００２１】
（言語情報を注釈）
言語情報を入力テキストに対して注釈するために、日本語に対する自然言語処理ツール（非特許文献８参照）を使用して、言語タグ・モジュール（Language Tagging Module(LTM))を実装した。言語タグ・モジュール（ＬＴＭ）では、入力テキストは文（sentence）に分割されて、１つずつ処理される。
最も大きい注釈の単位は、発話（UTTERANCE）であり、これは句（CLAUSE）に分割される。アクション（ACTION）タグは動詞句に割り当てられ、目的（OBJECT）タグは名詞句に割り当てられる。文節（BUNSETSU）タグは各文節単位に割り当てられる。最小の単位は単語自身であり、音声情報と見出し語を含んでいる。システムは、前に出てくる単語の履歴を残しており、入力された単語が与えれられたカード内で処理されていない場合、新規（NEW）と示す。
言語理論によると、文の情報構造は、２つの部分、主題（theme）と題述（rheme）で構成されている。
主題（theme）は、先行する句又は文と首尾一貫した関連を形成する文の部分である。題述（rheme）は、主題部分で導入された議論に新しい情報を提出する部分である。題述は新しい情報を表現しているので、身振りや顔の表情を用いて強調している可能性が高い。
一般的に、主題は文の始まり部分に置かれており、題述部分は主題に続いている。日本語では、「は」のような話題指標後置詞（topic marking postposition）で、主題部の最後が印されている。日本語のこの特徴を利用して、与えられた主題を特定している。主題は、文の始めで開始し、話題指標後置詞で終了する。題述部分は、文の残りの部分である。
さらに、実際の人間の表現やニュース・キャスタの動作を分析し、我々のアイディアに対して、さらに知見を得た。例えば、ビート・ジェスチャ（beat gesture）は、しばしば、疑問又は強調の副詞と同時に生じている。
【００２２】
（動作の選択）
これらの全ての知見に基づいて、図１３に示す動作選択ルールを作成した。ルール１として、強調する概念に対する特定の映像的ジェスチャ（iconic gesture：形や概念を表現するジェスチャ）は、ジェスチャ・ライブラリ（例えば、「大きい」を表現するジェスチャ・アニメーションがライブラリ中にある）に定義されており、これはビート・ジェスチャ（beat gesture：拍子を取る様なジェスチャ）に優先して選択される。特定のジェスチャが概念に対して定義されていない場合は、ビート・ジェスチャがデフォルトとして使用される。複数のルールが適用できる場合、システムは、異なる身体の部品を使用して、適用できる全ての非言語動作を選択する。例えば、テキストのある部分が題述（rheme）であるとともに新規情報（new）である場合、ビート・ジェスチャ（ルール１），「眉を上げる」（ルール５），「見つめる」（ルール１０）が同時に表示される。もっとルールが追加される必要があるが、これらのルールは、エージェントの多様な非言語表現を生成することができる。
出力の例が図１４に示されている。終了（end）タグは、場所を節約するために省略されている。
図１４において、最初に、発話（utterance）が主題（theme）とともに開始される（Ａの部分）と、エージェントはユーザから目をそらすとともに話し始める（タグ（１）参照）。次に、題述（rheme）の開始（Ｂの部分）で、見つめる動作が選択される（タグ（２）参照）。題述の部分に指示詞があるので、直示的ジェスチャ（deictic gesture）が文節単位に対して選択される（タグ（３）参照）。その上、「眉を上げる」もルール５にしたがって選択される（タグ（４））。このようにして、エージェントは、直示的ジェスチャをしている間、眉を上げる。
【００２３】
（アクション・スケジュール）
非言語動作を決定後、次のステップは、アニメーション・システムにより実行されるタイム・スケジュールを作成することである。非言語動作とエージェントの話とを同期させるため、ＡＢＳ中のスケジュール・モジュールは、ＴＳＳエンジンにアクセスして、各音素のタイミング情報（音素タイプ，開始時刻，及び持続時間）と文節境界を得る。リップ・シンクに対するViseme（口の形状）は音素タイプにより割り当てられる。スケジュール・モジュールの出力は、ＲＩＳＡアニメーション・システムにより実行されるインストラクション・セットの形式とされる。インストラクション・セットの各命令は、アニメーションの動作のタイプと開始時刻を特定する。図１４に示した部分の命令の例が、図１５に示されている。
例えば、動作  ＡＩＤ＝'Ａ６６９'において、右手の指差ジェスチャ（タグ（２）参照）は２．８７９９秒に開始し、元の位置に３．４００３秒に戻る（タグ（１３）参照）。動作タイプがVISEMEである場合（例えば、タグ（４）参照）、口の形状タイプと開始時刻は、リップシンクに対して特定する。最後に、アニメーション動作命令は、カード・エディタに戻され、カード内に格納される。
【００２４】
＜カード構成の詳細＞
カードの構成を説明する。前で述べた、エディタの２段階処理の結果、カードが生成され、カード・データベースに格納される。カード情報は、ＸＭＬ形式で記述されている。ＸＭＬの例を図１６に示す。
図１６において、<CARDS>（タグ（２）参照）は、新規の番組の始まりを意味する。これは、多数のCARD要素から構成されている。<CARD>要素（タグ（３）参照）は番組の構成ブロックであり、ID，BOX，IMAGE，AGENT，及びCOMMENT要素から構成されている。
<ID>（タグ（４）参照）は、CARDのＩＤを特定する。<BOX>（タグ（５）参照）は、番組中のカードの順番を特定している。<IMAGE>要素（タグ（６））は、いくつかの副要素から構成されており、これらは視覚素材の詳細を特定している。<IMAGEURL>（タグ（７）参照）は、画像およびビデオ・クリップ（映像）が格納されているＵＲＬアドレスを特定している。<XSCALE>と<YSCALE>（タグ（８），（９）参照）は、水平と垂直のズーム・スケールを割合（％）で特定している。<XPOS>と<YPOS>（タグ（１０），（１１）参照）は、表示内における、素材の水平と垂直の位置を特定している。<INIPOS>と<ENDPOS>（タグ（１２），（１３）参照）は、映像素材の開始／終了フレームを特定している。画像の場合、データの値は「０」である。これらのタグのデータは、視覚素材を編集するときに特定される。
<AGENT>要素（タグ（１５）参照）は、ＣＡＳＴにより生成されたアニメーション命令群が含まれており、所定のカードに対するエージェントの動作を特定している。最後に、<COMMENT>（タグ（２７）参照）は、カードに対応したナレーションを特定している。
ビューア１３０がカードを受け取ると、上述のように記述されたＸＭＬタグを解釈して、その内容に従って全ての素材を取得し、端末に対して送る。この処理を繰り返すことにより、このシステムは、連続したカードからテレビのような番組を生成する。
【図面の簡単な説明】
【００２５】
【図１】実施形態のシステム（ＳＰＯＣ）の概要を示す図である。
【図２】サーバサイドの構成を示す図である。
【図３】カードによる番組の提供を説明する図である。
【図４】番組の表示構成を示す図である。
【図５】端末側で番組を表示するための構成を示す図である。
【図６】デジタル・カメラワークを説明する図である。
【図７】デジタル・カメラワークの処理を説明するフローチャートである。
【図８】エージェント・アニメーションの表示例である。
【図９】エージェント・アニメーションの処理を説明する図である。
【図１０】エディタの機能概要を説明する図である。
【図１１】視覚素材の編集を説明する図である。
【図１２】エージェント・アニメーションの生成処理を説明するフローチャートである。
【図１３】アニメーションの動作選択ルールを示す図である。
【図１４】テキストに対して、注釈と動作選択ルールを適用した結果の出力例を示す図である。
【図１５】動作選択の結果を動作命令とした結果の出力例を示す図である。
【図１６】ＸＭＬで記述されたカードの例を示す図である。
【図１】
2005165438.tif 000003
【図２】
2005165438.tif 000004
【図６】
2005165438.tif 000005
【図７】
2005165438.tif 000006
【図１２】
2005165438.tif 000007
【図１３】
2005165438.tif 000008
【図１４】
2005165438.tif 000009
【図１５】
2005165438.tif 000010
【図１６】
2005165438.tif 000011
【図３】
2005165438.tif 000012
【図４】
2005165438.tif 000013
【図５】
2005165438.tif 000014
【図８】
2005165438.tif 000015
【図９】
2005165438.tif 000016
【図１０】
2005165438.tif 000017
【図１１】
2005165438.tif 000018