文書読み上げ支援装置、方法及びプログラム
【課題】読み上げスタイルのカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保し且つ読み上げの再現性を損なわないようにする。
【解決手段】実施形態によれば、文書取得部は、複数のテキストを含む文書データを取得し、メタデータ取得部は、ルールを適用すべきテキストに関する条件と該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得し、抽出部は、各々の定義情報を文書データに含まれるテキストに適用することで、文書データの特徴を抽出する。実行環境情報取得部は、読み上げを実行する実行環境情報を取得する。決定部は、文書データの特徴及び実行環境情報に基づいて、メタデータを文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する。ユーザ検証部は、パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付ける。
【解決手段】実施形態によれば、文書取得部は、複数のテキストを含む文書データを取得し、メタデータ取得部は、ルールを適用すべきテキストに関する条件と該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得し、抽出部は、各々の定義情報を文書データに含まれるテキストに適用することで、文書データの特徴を抽出する。実行環境情報取得部は、読み上げを実行する実行環境情報を取得する。決定部は、文書データの特徴及び実行環境情報に基づいて、メタデータを文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する。ユーザ検証部は、パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付ける。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、文書読み上げ支援装置、方法及びプログラムに関する。
【背景技術】
【０００２】
近年、計算機リソースの発達とハードウェアの進化により、書籍の電子化（電子書籍）が注目を浴びるようになった。そして、書籍の電子化が進むにつれて、電子書籍を閲覧するための端末又はソフトウェアが一般に出回るようになり、電子化された書籍コンテンツの販売が広まってきた。また、電子書籍の作成支援サービスも広まってきた。
【０００３】
電子書籍は、なおも紙媒体と比較して不便な点もある。しかし、大量の紙媒体であったものを電子データとすることによって、運搬、保管及び購入にかかる手間及びコストを削減することができ、また、検索又は辞書引きなどの新たな活用方法を提供することができる。
【０００４】
電子書籍に特有の活用方法の一つとして、音声合成システム（ＴＴＳ）を使用して文書を読み上げ、ユーザが電子書籍の朗読音声を聴くことができるサービスがある。従来からあるオーディオブックは、ナレーション収録を必要とするので、現実的には、限定された書籍だけしか提供することができなかった。これに対して、電子書籍の読み上げサービスによれば、任意のテキスト文書を（その内容によらずに）合成音で読み上げることができる。それゆえ、例えば、ナレーション収録をすることがコストに見合わないようなコンテンツ（例えば、頻繁に更新されるコンテンツなど）や、オーディオブックとして販売が期待できないようなコンテンツ（例えば、ユーザ所有の任意の書籍データ）なども、容易に朗読音声として聴いて楽しむことができる。
【０００５】
電子書籍の合成音朗読では、いくつかの技術が提案されている。
【０００６】
例えば、配信対象とするある作品のコンテンツデータ中に、その作品中に出てくる登場人物とそのセリフ（台詞）などとの対応が予め定義されており、その作品中に出てくる各登場人物と、そのコンテンツ視聴時に各登場人物のセリフを読み上げる合成音キャラクタとの対応付けを、複数の合成音キャラクタのキャラクタ画像が一覧表示された状態で、ユーザが自由に指定することができる技術が知られている。これによって、ユーザは、配信される作品の登場人物に、自分の好きな合成音キャラクタのキャラクタ音声を割り当てて、その作品を視聴することができる。
【０００７】
しかしながら、このようなコンテンツ配信とユーザカスタマイズ機能を実現しようとする場合には、いくつかの課題がある。
【０００８】
まず、配信されるコンテンツデータは、作品ごとに固有に、登場人物とセリフとがきめ細かく対応付けられている必要がある。それゆえ、ユーザが利用できるコンテンツとキャラクタ音声は、サービス提供者から配信されるものか、それらを組み合わせたものに限定されてしまう。
【０００９】
仮に各コンテンツに対する読み上げスタイルをユーザが自由に編集できるようにして、特定のコンテンツに応じた読み上げスタイルに関する情報を、サービス提供者に依存せずに、自由に配布・共有できる枠組みを考えた場合であっても、読み上げのスタイル情報において定義されているパラメータ及び使用する音声キャラクタは、作成者の環境に依存したものとなる。
【００１０】
そのため、あるコンテンツを視聴しようとするユーザにとって、共有されているスタイル情報を参照して、あるコンテンツの読み上げを再現するためには、作成者と同じ環境（同じキャラクタ音声のバリエーション、同等以上の機能をもつ音声合成エンジン）が利用できなければならない。
【００１１】
これは、ユーザにとって、ありとあらゆる音声キャラクタを所有している必要を強いることになり、現実的ではない。また、コンテンツ配信元の提供コンテンツと推奨環境でしか書籍データを読み上げられないことになり、先に述べたようなユーザの自由な読み上げ環境とは程遠いものとなる。
【００１２】
さらに、同一ユーザであっても、再生したい環境・機器は、状況によって異なる場合があり、常に同一の環境・機器で視聴されるとは限らない。たとえば、デスクトップＰＣなどの計算機リソースが充実した環境で、朗読音声をスピーカから聴く場合、または、屋外で携帯電話もしくはタブレットＰＣなどのモバイル機器を用いてヘッドホンもしくはイヤホンで聴く場合には、機器の制約上、たとえば、使用できるキャラクタ音声のバリエーションが限定されていたり、計算量を多く使用するような音声合成エンジンの機能の使用が制限されることが考えられる。
【００１３】
また、逆に特定の環境下においてのみ動作させたい機能（屋外でモバイル機器を利用するときにノイズリダクションを適用するなど）も考えられるが、こうしたユーザの環境の違い及び／又は利用可能な計算機リソースの違いに応じて、読み上げスタイル情報を柔軟に適用してコンテンツを再生することができなかった。
【００１４】
一方、こうしたメタデータの共有・作成がユーザ間で草の根的に広まり、公式・非公式を問わず、さまざまなバリエーションが存在する場合には、ユーザの楽しみ方の選択肢が増える一方で、実際に朗読音声として再生してみるまで、その読み上げ方あるいはキャラクタ特徴が分らないという懸念もある。
【００１５】
例えば、悪意をもったユーザが、コンテンツ内容と対応させて不適切な表現で読み上げるようなメタデータもしくは突然極端な音量変化を伴うようなメタデータを用意した場合、または、悪意はなくとも作品の演出上もしくは音声キャラクタの特性上、聞き苦しい朗読音声となる場合には、メタデータに従った朗読が、必ずしも全てのユーザにとってメリットとはならない場合がある。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２００３−１２２５５４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにする技術は、知られていなかった。
【００１８】
本実施形態は、文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにすることの可能な文書読み上げ支援装置、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１９】
実施形態によれば、文書読み上げ支援装置は、文書取得部と、メタデータ取得部と、抽出部と、実行環境情報取得部と、決定部と、ユーザ検証部と、音声合成器とを備える。文書取得部は、複数のテキストを含む文書データを取得する。メタデータ取得部は、ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得する。抽出部は、各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する。実行環境情報取得部は、前記文書データの読み上げを実行する環境に関する実行環境情報を取得する。決定部は、前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する。ユーザ検証部は、前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付ける。
【図面の簡単な説明】
【００２０】
【図１】実施形態に係る文書読み上げ支援装置の構成例を示す図である。
【図２】実施形態に係る文書読み上げ支援装置の処理手順の一例を示すフローチャートである。
【図３】入力文書の一例を示す図である。
【図４】メタデータの一例を示す図である。
【図５】メタデータ取得部の処理手順の一例を示すフローチャートである。
【図６】メタデータ取得部により得られる変換ルールの一例を示す図である。
【図７】入力文書特徴取得部の処理手順の一例を示すフローチャートである。
【図８】入力文書特徴取得部により得られる処理結果例を示す図である。
【図９】入力文書特徴取得部により得られる処理結果例を示す図である。
【図１０】実行環境取得部により得られる抽出結果例を示す図である。
【図１１】ユーザ設定制約取得部により得られる抽出結果例を示す図である。
【図１２】ユーザ設定制約取得部により得られる抽出結果例を示す図である。
【図１３】パラメータ決定部の処理手順の一例を示すフローチャートである。
【図１４】ユーザ検証部による提示例を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を参照しながら本発明の実施形態に係る文書読み上げ支援装置について詳細に説明する。
【００２２】
本実施形態では、電子書籍データを合成音声で読み上げる場合に、読み上げの工夫となる感情、調子、話者の違いなどを、メタデータとして定義し、必要に応じてこれらを参照することで、入力文書の内容、特徴に応じた多様な表現で、合成音による朗読を実現することを考える。その際、本実施形態に係る文書読み上げ支援装置は、コンテンツに対応した読み上げスタイルや、キャラクタボイスに特化した読み上げスタイルを、情報（メタデータ）を共有して利用する場合に、ユーザが実際に利用できる計算機リソースや機能、読み上げ対象とするコンテンツの違いを考慮して、再現性を確保した再生を試みる（あるいは、ユーザに適した条件下で再現性を高める）ことができるようになる。
【００２３】
図１に、本実施形態の文書読み上げ支援装置の概要図を示す。
【００２４】
図１に示されるように、文書読み上げ支援装置は、入力取得部１１、メタデータ取得部１２、入力文書特徴抽出部１３、実行環境取得部１４、ユーザ設定制約取得部１５、パラメータ決定部１６、ユーザ検証部１７、音声合成器１８を含む。
【００２５】
図２に、本実施形態の概略的な処理手順の一例を示す。
【００２６】
入力取得部１１は、入力文書１を入力し（ステップＳ１）、メタデータ取得部１２は、メタデータ２を入力する（ステップＳ２）。
【００２７】
入力文書１は、例えば、ボイスキャラクタによる読み上げ対象とする、複数のテキストを含む電子書籍である。入力文書１は、例えば、ＤＯＭ形式で格納される。
【００２８】
メタデータ２は、例えば、特定のコンテンツ読み上げと特定の音声キャラクタに依存してカスタマイズされている合成パラメータ、アクセント又は読みなどの特徴量とその適用条件などであり、例えば、取得された条件と特徴量が、後段のパラメータ決定処理で利用できる形式で格納される。
【００２９】
入力文書１は、例えば、インターネット又はイントラネットなどのネットワークを介して取得されても良いし、あるいは、例えば、記録媒体から取得されても良い。メタデータ２についても、同様である。入力文書１とメタデータ２が同じ作成者によるものである必要はない。また、入力文書１及び／又はメタデータ２が、ユーザ自身で作成したものであっても良い。
【００３０】
ステップＳ１とステップＳ２は、図２とは逆の順序で実行されても良いし、同時に実行されても良い。
【００３１】
入力文書特徴抽出部１３は、メタデータ２に基づいて、入力文書１の特徴を抽出する（ステップＳ３）。
【００３２】
実行環境取得部１４は、ボイスキャラクタによる読み上げを実行する当該のシステムに関する実行環境情報を取得する（ステップＳ４）。実行環境情報は、どのような方法で取得されても構わない。
【００３３】
ユーザ設定制約取得部１５は、読み上げに対するユーザ設定制約を取得する（ステップＳ５）。
【００３４】
ステップＳ４とステップＳ５は、次のパラメータ決定部１６による処理までに実行されれば良く、どのようなタイミングで実行されても構わない。
【００３５】
なお、このユーザ設定制約取得部１５を省く構成も可能である。
【００３６】
パラメータ決定部１６は、ここまでに獲得した処理結果を統合して、実際の読み上げに用いるためのパラメータ情報を決定する（ステップＳ６）。
【００３７】
ユーザ検証部１７は、ユーザがパラメータ情報を選択・確定するためのユーザ検証を実行する（ステップＳ７）。例えば、あるパラメータについて、ユーザが選択可能な候補が複数ある場合には、ユーザは、所望のパラメータを選択することによって、確定を行っても良い。
【００３８】
音声合成器１８は、上記メタデータ２及び上記パラメータ情報を使用して、入力文書１に対する合成音声を生成して、ボイスキャラクタによる読み上げ音声として出力する（ステップＳ８）。
【００３９】
以下、各部について説明する。
【００４０】
（入力取得部１１）
ユーザが利用対象とする、複数のテキストを含む書籍データは、入力取得部１１により、入力文書１として取得される。入力取得部１１は、該取得された書籍データから、テキスト情報を抽出する。該書籍データにレイアウト情報が含まれている場合には、該テキスト情報に加えて、レイアウト情報も取得する。
【００４１】
レイアウト情報は、例えば、描画されるページレイアウト内でのテキスト情報、位置、フォントサイズ、フォントスタイルなどのような情報である。また、例えば、ＸＨＴＭＬ又はスタイルシートによるフローティングレイアウトの場合には、例えば、論理要素としてテキストに付与されている改行、パラグラフ要素、タイトル要素、キャプション要素などのような情報である。
【００４２】
これらのような情報を含む入力文書１を、例えば、ＤＯＭ形式により木構造で格納しておいても良い。なお、レイアウト情報がない場合でも、例えば、改行ごとに行を表す論理要素を定義し、テキストをそれらの子要素としてぶら下げることによって、入力文書１をＤＯＭ形式で表現することができる。
【００４３】
図３に、ＤＯＭ化された入力文書の一例を示す。図３では、ＤＯＭ形式で格納された文書を、テキストノードごとにリスト表示している。この例では、個々のテキストノードは、個々の作品を識別する「作品ＩＤ」、その作品での出現順に付けられた「テキストノードＩＤ」、そのテキストノードの内容である「テキスト要素」、そのテキストが属する構造を示す「構造情報」、そのテキストがセリフ（dialogue）か地の文（description）かを示す「文タイプ」、そのテキストを話す作品中の登場人物等を示す「話者」を含む。なお、文タイプ及び話者については、例えば、既知の推定処理により又は人手により作成された情報を、属性及び属性値として埋め込んであるものとしても良い。
【００４４】
以下では、文書データをＤＯＭ形式で格納する場合を例にとって説明するが、これに制限されない。
【００４５】
（メタデータ取得部１２）
ユーザが利用対象とする上記書籍データに対するメタデータが、メタデータ取得部１２によりメタデータ２として取得される。
【００４６】
ここで、メタデータとは、例えば、コンテンツ中の文又はフレーズ又は単語の読み変え定義、特定の文脈においてキャラクタに発話させたい文又はフレーズ又は単語などの定義などを、列挙したものである。この列挙された内容から、以下の観点などに基づいて変換内容を取得し、後段で利用できる情報に変換して保持しておく。
（１）表記間の対応：コンテンツ中の部分文字列を条件として、変換内容を対応付けることができるもの。
（２）文節情報を条件とする対応：コンテンツ中の形態素又は品詞情報を条件として、変換内容を対応付けることができるもの。
３）その他の条件による対応：コンテンツ中の文字列又は形態素だけでは変換条件が一意に決まらず、対象文字列の文脈として、それが属する文書中の論理要素、近傍の単語、フレーズ、話者などと組み合わせて変換内容を対応付けることができるもの。
【００４７】
図４は、メタデータの一例を示す。この例では、メタデータ中に、適用条件と、適用条件が合致する文又はフレーズ又は単語に適用される変換（アクセント編集又は読み方定義）とが記載されたカスタマイズ定義が複数含まれている。具体的には、個々のカスタマイズ定義は、「作品ＩＤ」、「ルールＩＤ」、「条件文」、「アクセント編集」、「ボイスキャラクタ」、「読み方定義」、「文タイプ」を含む。図４の例では、使用されているボイスキャラクタとして、Ａ，Ｂ，Ｃ，Ｋ，Ｌが存在する。なお、図４の例において、ボイスキャラクタＡ，Ｂ，Ｃは、文タイプ属性として、セリフ向き（dialogue）、ボイスキャラクタＫ，Ｌは、文タイプ属性として、地の文向き（description）という特徴を持つものとする。
【００４８】
以下の説明では、図４のメタデータを具体例として用いるが、これに制限されない。
【００４９】
以下、メタデータ取得部１２の処理手順の具体的な流れについて説明する。
【００５０】
図５に、メタデータ取得部１２の処理手順の一例を示す。
【００５１】
まず、はじめに、カスタマイズ定義を順に取得する（ステップＳ１１）。
【００５２】
次に、読み込んだカスタマイズ定義の中で用いられているボイスキャラクタを確認する。同じボイスキャラクタがあれば、それらの条件も取得し、ボイスキャラクタ毎にまとめておく（ステップＳ１２）。
【００５３】
図４の具体例では、使用されているボイスキャラクタとして、Ａ，Ｂ，Ｃ，Ｋ，Ｌが存在するため、これらをそれぞれまとめておく。なお、図４は、説明の便宜上、すでにボイスキャラクタ毎にまとめられた状態で示している。
【００５４】
また、異なる条件で共通する部分表記があれば、まとめておく（ステップＳ１３）。
【００５５】
次に、表層の情報を取り出して、ルール化する（ステップＳ１４）。
【００５６】
図４の例では、まず、ルールＩＤ２，３のカスタマイズ定義にボイスキャラクタＢの“〜にゃー”という読み方定義があるため、それぞれ、この表記と条件文（条件文中の対応箇所）とを対応付けておく。
【００５７】
次に、品詞情報を取り出して、ルール化する（ステップＳ１５）。
【００５８】
上記例において、それらの表現に対して品詞レベルの情報を取り出して、条件文と読み方定義との間の関係を見る。
【００５９】
それぞれの条件表記部分の品詞情報を抜き出すと、
ルールＩＤ２：し＜動詞＞ます＜助動詞＞→“するにゃー”
ルールＩＤ３：の＜助詞＞→“にゃー”
となっており、これらを対応付けておく。
【００６０】
次に、文脈情報を取り出して、ルール化する（ステップＳ１６）。
【００６１】
上記例において、それらの条件文の文脈情報として、まず、ルールＩＤ２の条件文全体に形態素解析を適用すると、
“なんだか＜副詞＞／まったり＜副詞＞／し＜動詞＞／ます＜助動詞＞／。＜記号＞／”
と表記される。ここで、記号“／”は文節の境界を示し、山かっこで記載されたラベル名は、それぞれの形態素に対する品詞名を示しているものとする。
【００６２】
また、ルールＩＤ３の条件文に形態素解析を適用すると、
“それ＜名詞＞／は＜助詞＞／ちがう＜動詞＞／と＜助詞＞／おもう＜動詞＞／の＜助詞＞／。＜記号＞／”
となる。
【００６３】
文脈として、周辺の情報とより細かな品詞情報を利用すると、
“／し＜動詞＞／ます＜助動詞＞／”→“／する＜動詞（基本系）＞／にゃ＜助詞＞／ー＜名詞＞／”
“／おもう＜動詞＞／の＜助詞＞／”→“／おもう＜動詞（基本系）＞／にゃ＜助詞＞／ー＜名詞＞／”
となる。
【００６４】
次に、共通部分をマージする（ステップＳ１７）。
【００６５】
まず、同じボイスキャラクタのデータ内で共通部分のマージができるかをチェックする。
【００６６】
上記例において、チェックの結果、条件部と帰結部をそれぞれまとめ上げて、
“／＜動詞＞／＜助詞｜助動詞＞／”→“／＜動詞（基本系）＞／にゃ／ー／”
（ボイスキャラクタＢ）
としておく。なお、ここで、品詞ラベル間の縦棒は、論理和（ｏｒ）を示すものとする。
【００６７】
同様に、ボイスキャラクタＣに対して、
“／＜動詞＞／＜助詞｜助動詞＞／”→“／＜動詞（基本系）＞／です／の／ー／”
ボイスキャラクタＫに対して、
“／＜動詞＞／まし＜助動詞Ａ＞／＜助動詞Ｂ＞／＜助動詞Ｃ＞？／”→“／＜動詞（基本系）＞／＜助動詞Ｂ＞／で／ござる／”
といったまとめ上げ結果が得られる。
【００６８】
さらに、ルールＩＤ１の条件文に対しても、同様の処理を行う。まず、品詞情報を見ると、
“とても＜副詞＞”→“とてーも”
“です＜助動詞＞”→“ぴょん”
と表現されていることがわかる。しかし、文脈情報を用いても共通化できる部分がないため、この品詞付き表記を、まとめ上げ結果として格納しておく。
【００６９】
また、ルールＩＤ１０２の定義を見ると、アクセント表記が定義されている。これに関しても同様の処理を行い、
“ソレハチガウヨ＜名詞＞”→“ソ’レハチガ’ーウヨ”
とした対応付けを格納しておく。
【００７０】
なお、上記のアクセント表記は、’の直前にアクセントがあることを意味しているものとする。よって、上記具体例では、「ソ」と「ガ」にアクセントがある）。
【００７１】
まとめた結果（変換ルール）は、内部データとして格納し（ステップＳ１８）、すべての条件定義について処理が完了したか判定する（ステップＳ１９）。完了していないならば、ステップＳ１に戻って処理を繰り返し、完了しているならば、図５の処理を終了する。
【００７２】
図６に、図４の具体例に対する処理をまとめた結果（変換ルール）を例示する。この変換ルール例において、個々の変換ルールは、「変換ルールＩＤ」、「条件」、「帰結」、「ボイスキャラクタ」、「元ＩＤ（図４のメタデータにおけるルールＩＤ）」、「文タイプ」を含む。
【００７３】
（入力文書特徴抽出部１３）
次に、入力文書特徴抽出部１３について説明する。
【００７４】
入力文書特徴抽出部１３は、入力取得部１１により得られたＤＯＭ形式の文書データと、メタデータ取得部１２により得られた変換ルールとを入力として、各変換ルールが文書データに対してどのような影響を及ぼすかについての情報を獲得する。
【００７５】
以下、入力文書特徴抽出部１３の処理手順の一例について説明する。
【００７６】
図７に、入力文書特徴抽出部１３の処理手順の一例を示す。
【００７７】
まず、ＤＯＭ形式の文書データを受け取る（ステップＳ２１）。ここでは、一例として、図３に示される文書データが得られるものとする。
【００７８】
次に、格納済みメタデータを受け取る（ステップＳ２２）。ここでは、一例として、図６に示されるメタデータ取得結果が得られるものとする。
【００７９】
なお、図３の例におけるＪ，Ｐ，Ｑ，Ｒ，Ｔは、話者（作品中の登場人物等）であり、図６の例におけるＡ，Ｂ，Ｃ，Ｋ，Ｌは、ボイスキャラクタである。
【００８０】
続いて、格納されているメタデータから、順に、変換ルールを読み込み、文書データに適用していく（ステップＳ２３）。
【００８１】
各ノードに対してルールを適用し、条件部がマッチしたルールについては、その変換ルールＩＤと、適合したテキストノードとを対応付けて保持しておく（ステップＳ２４）。
【００８２】
次に、条件文が一致する話者との関連性を、枚挙する（ステップＳ２５）。条件文が一致しているルール中の話者（ボイスキャラクタ）と、文書データ中の話者（作品中の登場人物等）とを対応付けて保持しておく。
【００８３】
また、表記（文末表現）で類似しているルール中の話者と、文書データ中の話者との対応があれば、関連付けて保持しておく（ステップＳ２６）。
【００８４】
また、文のタイプで類似しているルール中の話者と、文書データ中の話者との対応があれば、関連付けて保持しておく（ステップＳ２７）。
【００８５】
また、文書要素（構造情報）で類似する話者との対応があれば、これを枚挙しておく（ステップＳ２８）。
【００８６】
全てのルールについて検証が完了したかどうか判定する（ステップＳ２９）。全てのルールについて検証が完了すれば、処理を終了する。一方、未検証のルール・文があれば、順にメタデータを読み込み、同様の処理を繰り返す。
【００８７】
図８と図９に、入力文書特徴抽出部１３の処理結果例を示す。
【００８８】
図８は、文書データ中の各テキストノードに対応して、ルールがマッチした変換ルールＩＤを示している。図８は、図３のような文書データにおいて、各テキストノードに適合する変換ルールＩＤを示す「適合ルールＩＤ」が更に追加されている。この具体例では、たとえば、テキストノードＩＤ４０に対して、適合ルールＩＤ５が、テキストノードＩＤ４２に対してルールＩＤ４が、さらにテキストノードＩＤ１０５に対して、ルールＩＤ１とＩＤ２とが適合していることが示されている。なお、テキストノードＩＤと適合ルールＩＤとの対応は、図３のような文書データに組み込んで保持しても良いし、図３のような文書データとは独立して保持しても良い。
【００８９】
図９は、これらの対応結果から、それぞれ異なる観点で得られた話者間の関連性についてまとめた結果である。個々の結果は、「番号」、「条件文の一致による話者との関連」、「文末表現による話者との関連」、「文タイプとの関連」、「構造情報による関連」を含む。なお、Ｐ＝＊は、Ｐは、すべてのボイスキャラクタと対応することを意味する。
【００９０】
例えば、図９の第一列では、条件文が一致することによる話者間の対応付けとして、それぞれルールと入力文書との対応付けから、第一行のＰとＡ、第二行のＲとＡ、第三行のＴとＢ、第四行のＴとＣがそれぞれ枚挙されている。
【００９１】
次に、文末表現での対応関係から、話者間の関連性を抽出する。
【００９２】
ここでは、ですます調と、だ・である調との区別を行い、同じグループに属するものを特定しておく。例えば、正規表現のマッチングにより、「.＋です。」または「.＋ます。」のいずれかにマッチしたものは「ですます調」と判定し、「.＋だ。」または「.＋である。」のいずれかにマッチしたものは「である調」と判定することによって、それらを区別することができる。この結果に基づいて、同じ性質を持っている話者を、対応付けるものとする。
【００９３】
例えば、まず、図８のテキストノードＩＤ４０が「ですます調」であることが分かるため、話者（作品中の登場人物等）Ｐと、図４における条件文で「ですます調」である話者（ボイスキャラクタ）Ａ，Ｂ，Ｃとの間に対応関係が見られたものとする。その結果、文末表現による話者との対応では、Ｐ＝Ａ，Ｂ，Ｃが得られる。
【００９４】
また、図８のテキストノードＩＤ１０５の話者Ｔは「ですます調」であることがわかり、これに対応する適合ルールＩＤ１，ＩＤ２は、図４における話者Ａ，Ｂに対応する。その結果、Ｔ＝Ａ，Ｂが得られる。
【００９５】
次に、文タイプに基づく関連情報を抽出しておく。
【００９６】
例えば、図９の番号（１）では、ここまでの関連として話者（作品中の登場人物等）Ｐと話者（ボイスキャラクタ）Ａとの対応が候補として挙がっているが、この話者Ｐのテキストノード「それじゃあ、あんまりです。」を見ると、この文タイプは「セリフ向き（dialogue）」であることがわかる。一方で、このテキストのノードにヒットしたルール（図６の変換ルールＩＤ５）における話者Ａも、文タイプ「セリフ向き（dialogue）」の特徴を有しているので、同一属性を保持していることになる。
【００９７】
また、番号（２）でも同様に、話者Ｒのテキストノード「だが、これはとても君たちの力では無理だと言っていたのではなかったかね？」についても文タイプは「セリフ向き（dialogue）」であり、このルールが適合している変換ルールにおける話者Ａも「セリフ向き（dialogue）」であり、同一の関係となっている。
【００９８】
一方で、番号（３）と（４）については、入力文のタイプが「地の文向き（description）であるが、それぞれに対応する変換ルール（ＩＤ１，２）の話者は、図６では「セリフ向き（dialogue）」のＢ，Ｃであったので、属性が異なることが分かる。
【００９９】
さらに、構造情報の関連について記載している。
【０１００】
ここでは、最小の汎化となる要素（section_body）のみを明示し、それ以外の差分を省略（＊）して記載している。
【０１０１】
以上を入力文書特徴抽出部１３の抽出結果として、後段の処理に渡す。
【０１０２】
（実行環境取得部１４）
次に、実行環境取得部１４について説明する。
【０１０３】
実行環境取得部１４では、ユーザが音声合成による読み上げを行うおうとしているシステムの環境に関する情報（システム環境情報）を取得する。
【０１０４】
システム環境情報は、具体的には、デバイスとＯＳの情報の他、ユーザが利用可能な、音声合成エンジン、ボイスキャラクタ、パラメータレンジなどの情報である。インストールされている音声合成エンジンから取得できるプロパティ情報として、例えば、音声合成エンジン（ＴＴＳ）の名称とバージョンがあり、利用可能な音声（ボイスキャラクタ）の属性として、キャラクタ名称、利用可能な言語、話者性別、話者年齢などがある。パラメータレンジは、音声合成エンジンがサポートするパラメータ情報として得られる。
【０１０５】
図１０に、この実行環境取得部１４による取得結果例を示す。
【０１０６】
ここでは、利用可能な２点の動作環境について例を示す。
【０１０７】
まず、デバイス（端末）の種類とＯＳ名、音声合成エンジン名の他、利用可能なキャラクタ、利用可能な言語（この例では、ＪＰ（日本語）とＥＮ（英語））、利用可能な性別（この例では、Ｍａｌｅ（男性）、Ｆｅｍａｌｅ（女性））、利用可能なキャラクタの声年代（この例では、Ａｄｕｌｔ（大人）、Ｃｈｉｌｄ（子供））といった属性が枚挙されている。
【０１０８】
さらに、音声合成用のパラメータとして、Ｖｏｌｕｍｅ（調整できる音量幅）が０から１００までの連続値であること、Ｐｉｔｃｈ情報については、図１０の上段に示されるリソースであれば、連続値として（−２０から２０）が設定できる一方で、図１０の下段に示されるリソースであれば、５段階の離散値しかサポートしない、といったことが示されているものとする。また、Ｒａｎｇｅ、Ｒａｔｅ、Ｂｒｅａｋ（ポーズ長）といったパラメータについても同様に、連続値（ｃｏｎｔｉｎｕｏｕｓ）か、離散値（ｄｅｓｃｒｅｔｅ）か、さらに連続値の場合は、値の幅や離散値の場合は、何段階の幅をとれるかの段数などが記載されているものとする。
【０１０９】
これらの取得結果を後段の処理に渡す。
【０１１０】
（ユーザ設定制約取得部１５）
次に、ユーザ設定制約取得部１５について説明する。
【０１１１】
ユーザ設定制約は、例えば、メタデータよりも優先して適用すべきユーザの指定条件及び／又は制約条件などである。具体的には、例えば、特定のパラメータの値を指定し、あるいは、特定のパラメータの値域を指定しても良い。
【０１１２】
図１１に、ユーザ設定制約取得部１５がユーザからの指示情報を取得するためのユーザインタフェースの例を示し、図１２に、取得した結果の格納例を示す。
【０１１３】
まず、ユーザは、図１１に例示するような、各項目に対応して自由に値を設定することができるユーザインタフェースを使用して、読み上げに影響を及ぼす項目について、あらかじめ制約を設定しておくことができるものとする。
【０１１４】
図１１の例において、項目“感情変化読み”では、例えば文書中の激怒、怒号、号泣等に相当する激しい感情表現について、合成音声として再現することをどの程度許容するかを指定する。この項目について、例えば“フル（制限なし）”と設定されていれば、メタデータ又はユーザカスタマイズ結果の激怒又は号泣等の定義に対して、それをそのまま感情韻律辞書などを適用したり、合成エンジンに与えるパラメータを変更するなどの手法で、読み上げ時に再現を試みる。一方、これ以外の値に設定されている場合は、その割合に応じて、感情表現の強さの度合いを調整する。例えば、微小であれば、感情表現の効果を９割方減じて読み上げを行い、穏やかであれば半分ほどの程度（激怒→怒）に抑えた読み上げを行う、などである。
【０１１５】
また、項目“ワード・表現”では、小説において又はストーリー上で出現する、ならず者又は乱暴者の残虐・乱暴・粗雑な表現、言い回し韻律などの程度情報を設定できるものとする。例えば、制限がなければ、メタデータ又はユーザカスタマイズ情報に沿った読み上げを実現する一方で、この設定値を下げている場合には、太くて低い凄みのある声の効果を低減したり、特定の表現又は文又はフレーズ又は単語を置き換えた読み上げを行う。
【０１１６】
また、項目“音量・テンポ変化”では、例えば、怪談クライマックス時の「わっ！」といった驚かせ表現、突然の叫び声、疾走・逃走中の激しい緊迫又は速度間のある読み上げ効果について、程度情報を指定する。先の例と同じように、“フル”であればメタデータ定義又はユーザのカスタマイズ情報にそのまま従うが、この設定に制約を掛けている場合には、これらの程度を落として読み上げを行う。
【０１１７】
図１２に、ユーザインタフェース上での設定を、ユーザ設定制約取得部１５で格納した場合の一例を示す。
【０１１８】
図１１に示すユーザインタフェース上のスライダ値に応じて、各項目の上限値（可変値）が設定されるものとする。ここでは、感情表現の程度がフルの場合の７５％程度、許容するワードや表現で３０％程度、音量やテンポ変化の度合いは、フルの場合の５５％程度までを許容するものと設定されたと仮定する。
【０１１９】
これらの結果を、後段のパラメータ決定部１６に渡す。
【０１２０】
（パラメータ決定部１６、ユーザ検証部１７）
次に、パラメータ決定部１６及びユーザ検証部１７について説明する。
【０１２１】
パラメータ決定部１６では、ここまでに獲得した処理結果を統合して、実際の読み上げに用いるためのパラメータ情報を決定する。
【０１２２】
図１３に、パラメータ決定部１６の処理手順の一例を示す。
【０１２３】
以下、パラメータ決定部１６の処理手順の一例について説明する。
【０１２４】
まず、前段までの処理結果であるメタデータの格納結果（ステップＳ３１）、入力文書特徴抽出部の処理結果（ステップＳ３２）、実行環境取得部１４の抽出結果（ステップＳ３３）およびユーザ設定制約取得部１５での抽出結果（ステップＳ３４）を受け取る。
【０１２５】
次に、ユーザに提示する各項目について、それぞれの再現度を計算する。なお、ステップＳ３６とステップＳ３７の一方又は両方を省く構成も可能である。
【０１２６】
ここで、再現度の比較対象とする推奨環境について説明する。
【０１２７】
推奨環境は、本実施形態では、ボイスキャラクタに関する推奨環境、読み上げの際の感情（表現）に関する推奨環境（オプション）、パラメータに関する推奨環境（オプション）の３つを想定しているが、これに制限されない。
【０１２８】
ボイスキャラクタに関する推奨環境について説明する。
【０１２９】
例えば、入力文書特徴抽出部１３による処理結果、例えば図８と図９の結果から、例えば、図３の電子書籍に図４のメタデータを適用する場合に推奨されるボイスキャラクタを選択することができる。例えば、図３の文書データ中の話者Ｐ，Ｒ，Ｔに、それぞれ、図４のメタデータ中のボイスキャラクタＢ，Ａ，Ｃを対応させる割り当てる方が可能であることが分る。また、例えば、文書データにおいて話者の属性（例えば、言語・性別・年齢・性格など）のデータがあり、かつ、メタデータにおいてボイスキャラクタの属性（例えば、言語・性別・年齢・性格など）のデータがある場合に、入力文書特徴抽出部１３による処理結果に加えて、それら属性のデータを考慮して、文書データ中の話者に、メタデータ中のボイスキャラクタを割り当てる方法も可能である。その他にも、推奨ボイスキャラクタを選択する様々な方法が可能である。
【０１３０】
図１４に、ボイスキャラクタの推奨環境を例示する（なお、図１４のボイスキャラクタの名称は、これまでとは異なる名称で例示しているが、これまでの例を使用すれば、図１４のボイスキャラクタの推奨環境に、ボイスキャラクタＡ，Ｂ，Ｃなどが記述されることになる。）
なお、図１４の例では、ボイスキャラクタのみリストされているが、各ボイスキャラクタに対応する文書データ中の話者を併せて提示しても良い。
【０１３１】
ところで、ユーザのシステム環境においては、ボイスキャラクタとして、Ａ，Ｂ，Ｃなどあるいは図１４で言えば「川崎太郎」などが利用可能とは限らない。ユーザが利用できるのは、ユーザのシステム環境において利用可能なボイスキャラクタのみである。
【０１３２】
そこで、推奨されるボイスキャラクタと、ユーザが利用可能なボイスキャラクタとを比較して、話者に関する再現度を計算する（ステップＳ３５）。
【０１３３】
話者に関する再現度は、例えば、入力文書に出現する話者の特徴量（及び／又は、該話者に対応するボイスキャラクタの特徴量）と、ユーザが音声合成器で利用可能なキャラクタボイスの特徴量の一致度として表現できる。具体的には、例えば、それぞれが属性としてもつ利用可能な言語・性別・年齢などの各項目を、適当に正規化して、ベクトルの要素として表現しておき、それらのベクトル間の類似度（例えば、コサイン距離）を求め、これを一致度の尺度として用いることができる。その他にも、種々の再現度計算方法が可能である。
【０１３４】
次に、利用するのが推奨されるパラメータのカバー幅のデータが例えばメタデータの一部として提供されている場合に、音声合成器で利用可能なパラメータのカバー幅について、再現度を計算する（ステップＳ３６）。これも、上記と同様、例えば、パラメータのカバー幅を、ベクトルの要素として、ベクトル間の類似度を求め、これを一致度の尺度として用いることができる。
【０１３５】
次に、利用するのが推奨される感情表現（例えば、平、驚、怒、哀、厭など）のデータが例えばメタデータの一部として提供されている場合に、音声合成器で利用可能な感情表現の有無について、再現度を計算する（ステップＳ３７）。これも、上記と同様、例えば、感情表現の有無を、ベクトルの要素として、ベクトル間の類似度を求め、これを一致度の尺度として用いることができる。
【０１３６】
なお、ステップＳ３５〜Ｓ３７は、どのような順序で計算を行っても良い。また、ステップＳ３６とＳ３７の一方又は両方を省く構成も可能である。
【０１３７】
また、統合した全体的な一致度（再現度）についても計算しておく（ステップＳ３８）。この総合的な再現度は、例えば、各機能に関する一致度の積として、以下のように定義することができる。
再現度＝話者特徴量の一致度×利用可能感情の一致度×再生可能なパラメータの一致度×メタデータ改変箇所の文書特徴カバー率
なお、総合的な再現度として、例えば、数値を示しても良いし、あるいは、数段階にレベル分けして、そのレベル値を示しても良い。
【０１３８】
ユーザ検証部１７は、上記のように算定された各機能に関する一致度について、例えば図１４に示すように、機能ごとに個別に提示するとともに、総合的な再現度を併せて提示する（ステップＳ３９）。
【０１３９】
例えば、第２行の作品において、推奨ボイスキャラクタ「岡山高知」に対して、実行環境においては、「岡山高知」が使用可能でなく、最も高い一致度をもつ「川崎太郎」が提示されている。また、ここでは、「川崎太郎」の横のボタンを押すことによって、次候補以降の推奨ボイスキャラクタに変更・選択できるようになっている。
【０１４０】
また、例えば、第１行の作品において、推奨ボイスキャラクタ「川崎太郎」に対して、実行環境においては、これと一致する「川崎太郎」が提示されている。この場合には、実行環境におけるボイスキャラクタの次候補は提示しないものとしている。
【０１４１】
なお、各機能について、一致度を明示的に提示するようにしても良い。あるいは、例えば、一致度の低い項目を提示する欄の枠内自体又は表示文字を、ハイライト表示しても良い。例えば、その際に、一致度を何段階かにレベル分けして、レベルごとに異なる色又は明るさを使用しても良い。逆に、一致度の高い項目を提示する欄の枠内自体又は表示文字を、ハイライト表示しても良い。
【０１４２】
また、総合的な再現度を提示するにあたって、総合的な再現度が高い場合と低い場合とで、異なる形態（例えば、異なる色）で表示しても良い。例えば、図１４の例で、「Excellent」「Good」「Okay」と、「Poor」「Bad」とで、異なる表示色を使用しても良い。
【０１４３】
これらの他にも、ユーザに結果を伝えやすくするための様々な表示方法が可能である。
【０１４４】
次に、ユーザの確認・修正を得る（ステップＳ４１）。
【０１４５】
例えば、第１候補として提示されているボイスキャラクタの横のボタンを押すことによって、次候補以降の推奨ボイスキャラクタに変更・選択する。
【０１４６】
ステップＳ４１のユーザの確認・修正は、ユーザが繰り返し行うことが可能であり、提示した結果に対してユーザによる確認・選択指定が完了すれば（ステップＳ４０）、この処理を終了する。
【０１４７】
なお、ユーザが、最終的な確定の指示を明示的に入力するようにしても良い。例えば、確定ボタンを設けても良い。
【０１４８】
処理結果は、制御パラメータとして音声合成器１８へ渡される。
【０１４９】
（音声合成器１８）
音声合成器１８は、制御用パラメータとして、各話者指定及び文書表現にマッチする変換ルールを適用しながら、合成音声を生成して、ボイスキャラクタによる読み上げ音声として出力する。
【０１５０】
以上の手順により、ユーザが実際に利用できる計算機リソースや機能、読み上げ対象とするコンテンツの違いを考慮して、再現性を確保した再生が実現できる。
【０１５１】
本実施形態によれば、文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにすることが可能になる。
【０１５２】
また、上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいて実行されることが可能である。汎用の計算機システムが、このプログラムを予め記憶しておき、このプログラムを読み込むことにより、上述した実施形態の文書読み上げ支援装置による効果と同様な効果を得ることも可能である。上述の実施形態で記述された指示は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷなど）、半導体メモリ、またはこれに類する記録媒体に記録される。コンピュータまたは組み込みシステムが読み取り可能な記録媒体であれば、その記憶形式は何れの形態であってもよい。コンピュータは、この記録媒体からプログラムを読み込み、このプログラムに基づいてプログラムに記述されている指示をＣＰＵで実行させれば、上述した実施形態の文書読み上げ支援装置と同様な動作を実現することができる。もちろん、コンピュータがプログラムを取得する場合または読み込む場合はネットワークを通じて取得または読み込んでもよい。
また、記録媒体からコンピュータや組み込みシステムにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワーク等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行してもよい。
さらに、本実施形態における記録媒体は、コンピュータあるいは組み込みシステムと独立した媒体に限らず、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードして記憶または一時記憶した記録媒体も含まれる。
また、記録媒体は１つに限られず、複数の媒体から本実施形態における処理が実行される場合も、本実施形態における記録媒体に含まれ、媒体の構成は何れの構成であってもよい。
【０１５３】
なお、本実施形態におけるコンピュータまたは組み込みシステムは、記録媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するためのものであって、パソコン、マイコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であってもよい。
また、本実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本実施形態における機能を実現することが可能な機器、装置を総称している。
【０１５４】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１５５】
１…入力文書、２…メタデータ、１１…入力取得部、１２…メタデータ取得部、１３…入力文書特徴抽出部、１４…実行環境取得部、１５…ユーザ設定制約取得部、１６…パラメータ決定部、１７…ユーザ検証部、１８…音声合成器。
【技術分野】
【０００１】
本発明の実施形態は、文書読み上げ支援装置、方法及びプログラムに関する。
【背景技術】
【０００２】
近年、計算機リソースの発達とハードウェアの進化により、書籍の電子化（電子書籍）が注目を浴びるようになった。そして、書籍の電子化が進むにつれて、電子書籍を閲覧するための端末又はソフトウェアが一般に出回るようになり、電子化された書籍コンテンツの販売が広まってきた。また、電子書籍の作成支援サービスも広まってきた。
【０００３】
電子書籍は、なおも紙媒体と比較して不便な点もある。しかし、大量の紙媒体であったものを電子データとすることによって、運搬、保管及び購入にかかる手間及びコストを削減することができ、また、検索又は辞書引きなどの新たな活用方法を提供することができる。
【０００４】
電子書籍に特有の活用方法の一つとして、音声合成システム（ＴＴＳ）を使用して文書を読み上げ、ユーザが電子書籍の朗読音声を聴くことができるサービスがある。従来からあるオーディオブックは、ナレーション収録を必要とするので、現実的には、限定された書籍だけしか提供することができなかった。これに対して、電子書籍の読み上げサービスによれば、任意のテキスト文書を（その内容によらずに）合成音で読み上げることができる。それゆえ、例えば、ナレーション収録をすることがコストに見合わないようなコンテンツ（例えば、頻繁に更新されるコンテンツなど）や、オーディオブックとして販売が期待できないようなコンテンツ（例えば、ユーザ所有の任意の書籍データ）なども、容易に朗読音声として聴いて楽しむことができる。
【０００５】
電子書籍の合成音朗読では、いくつかの技術が提案されている。
【０００６】
例えば、配信対象とするある作品のコンテンツデータ中に、その作品中に出てくる登場人物とそのセリフ（台詞）などとの対応が予め定義されており、その作品中に出てくる各登場人物と、そのコンテンツ視聴時に各登場人物のセリフを読み上げる合成音キャラクタとの対応付けを、複数の合成音キャラクタのキャラクタ画像が一覧表示された状態で、ユーザが自由に指定することができる技術が知られている。これによって、ユーザは、配信される作品の登場人物に、自分の好きな合成音キャラクタのキャラクタ音声を割り当てて、その作品を視聴することができる。
【０００７】
しかしながら、このようなコンテンツ配信とユーザカスタマイズ機能を実現しようとする場合には、いくつかの課題がある。
【０００８】
まず、配信されるコンテンツデータは、作品ごとに固有に、登場人物とセリフとがきめ細かく対応付けられている必要がある。それゆえ、ユーザが利用できるコンテンツとキャラクタ音声は、サービス提供者から配信されるものか、それらを組み合わせたものに限定されてしまう。
【０００９】
仮に各コンテンツに対する読み上げスタイルをユーザが自由に編集できるようにして、特定のコンテンツに応じた読み上げスタイルに関する情報を、サービス提供者に依存せずに、自由に配布・共有できる枠組みを考えた場合であっても、読み上げのスタイル情報において定義されているパラメータ及び使用する音声キャラクタは、作成者の環境に依存したものとなる。
【００１０】
そのため、あるコンテンツを視聴しようとするユーザにとって、共有されているスタイル情報を参照して、あるコンテンツの読み上げを再現するためには、作成者と同じ環境（同じキャラクタ音声のバリエーション、同等以上の機能をもつ音声合成エンジン）が利用できなければならない。
【００１１】
これは、ユーザにとって、ありとあらゆる音声キャラクタを所有している必要を強いることになり、現実的ではない。また、コンテンツ配信元の提供コンテンツと推奨環境でしか書籍データを読み上げられないことになり、先に述べたようなユーザの自由な読み上げ環境とは程遠いものとなる。
【００１２】
さらに、同一ユーザであっても、再生したい環境・機器は、状況によって異なる場合があり、常に同一の環境・機器で視聴されるとは限らない。たとえば、デスクトップＰＣなどの計算機リソースが充実した環境で、朗読音声をスピーカから聴く場合、または、屋外で携帯電話もしくはタブレットＰＣなどのモバイル機器を用いてヘッドホンもしくはイヤホンで聴く場合には、機器の制約上、たとえば、使用できるキャラクタ音声のバリエーションが限定されていたり、計算量を多く使用するような音声合成エンジンの機能の使用が制限されることが考えられる。
【００１３】
また、逆に特定の環境下においてのみ動作させたい機能（屋外でモバイル機器を利用するときにノイズリダクションを適用するなど）も考えられるが、こうしたユーザの環境の違い及び／又は利用可能な計算機リソースの違いに応じて、読み上げスタイル情報を柔軟に適用してコンテンツを再生することができなかった。
【００１４】
一方、こうしたメタデータの共有・作成がユーザ間で草の根的に広まり、公式・非公式を問わず、さまざまなバリエーションが存在する場合には、ユーザの楽しみ方の選択肢が増える一方で、実際に朗読音声として再生してみるまで、その読み上げ方あるいはキャラクタ特徴が分らないという懸念もある。
【００１５】
例えば、悪意をもったユーザが、コンテンツ内容と対応させて不適切な表現で読み上げるようなメタデータもしくは突然極端な音量変化を伴うようなメタデータを用意した場合、または、悪意はなくとも作品の演出上もしくは音声キャラクタの特性上、聞き苦しい朗読音声となる場合には、メタデータに従った朗読が、必ずしも全てのユーザにとってメリットとはならない場合がある。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２００３−１２２５５４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにする技術は、知られていなかった。
【００１８】
本実施形態は、文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにすることの可能な文書読み上げ支援装置、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１９】
実施形態によれば、文書読み上げ支援装置は、文書取得部と、メタデータ取得部と、抽出部と、実行環境情報取得部と、決定部と、ユーザ検証部と、音声合成器とを備える。文書取得部は、複数のテキストを含む文書データを取得する。メタデータ取得部は、ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得する。抽出部は、各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する。実行環境情報取得部は、前記文書データの読み上げを実行する環境に関する実行環境情報を取得する。決定部は、前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する。ユーザ検証部は、前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付ける。
【図面の簡単な説明】
【００２０】
【図１】実施形態に係る文書読み上げ支援装置の構成例を示す図である。
【図２】実施形態に係る文書読み上げ支援装置の処理手順の一例を示すフローチャートである。
【図３】入力文書の一例を示す図である。
【図４】メタデータの一例を示す図である。
【図５】メタデータ取得部の処理手順の一例を示すフローチャートである。
【図６】メタデータ取得部により得られる変換ルールの一例を示す図である。
【図７】入力文書特徴取得部の処理手順の一例を示すフローチャートである。
【図８】入力文書特徴取得部により得られる処理結果例を示す図である。
【図９】入力文書特徴取得部により得られる処理結果例を示す図である。
【図１０】実行環境取得部により得られる抽出結果例を示す図である。
【図１１】ユーザ設定制約取得部により得られる抽出結果例を示す図である。
【図１２】ユーザ設定制約取得部により得られる抽出結果例を示す図である。
【図１３】パラメータ決定部の処理手順の一例を示すフローチャートである。
【図１４】ユーザ検証部による提示例を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を参照しながら本発明の実施形態に係る文書読み上げ支援装置について詳細に説明する。
【００２２】
本実施形態では、電子書籍データを合成音声で読み上げる場合に、読み上げの工夫となる感情、調子、話者の違いなどを、メタデータとして定義し、必要に応じてこれらを参照することで、入力文書の内容、特徴に応じた多様な表現で、合成音による朗読を実現することを考える。その際、本実施形態に係る文書読み上げ支援装置は、コンテンツに対応した読み上げスタイルや、キャラクタボイスに特化した読み上げスタイルを、情報（メタデータ）を共有して利用する場合に、ユーザが実際に利用できる計算機リソースや機能、読み上げ対象とするコンテンツの違いを考慮して、再現性を確保した再生を試みる（あるいは、ユーザに適した条件下で再現性を高める）ことができるようになる。
【００２３】
図１に、本実施形態の文書読み上げ支援装置の概要図を示す。
【００２４】
図１に示されるように、文書読み上げ支援装置は、入力取得部１１、メタデータ取得部１２、入力文書特徴抽出部１３、実行環境取得部１４、ユーザ設定制約取得部１５、パラメータ決定部１６、ユーザ検証部１７、音声合成器１８を含む。
【００２５】
図２に、本実施形態の概略的な処理手順の一例を示す。
【００２６】
入力取得部１１は、入力文書１を入力し（ステップＳ１）、メタデータ取得部１２は、メタデータ２を入力する（ステップＳ２）。
【００２７】
入力文書１は、例えば、ボイスキャラクタによる読み上げ対象とする、複数のテキストを含む電子書籍である。入力文書１は、例えば、ＤＯＭ形式で格納される。
【００２８】
メタデータ２は、例えば、特定のコンテンツ読み上げと特定の音声キャラクタに依存してカスタマイズされている合成パラメータ、アクセント又は読みなどの特徴量とその適用条件などであり、例えば、取得された条件と特徴量が、後段のパラメータ決定処理で利用できる形式で格納される。
【００２９】
入力文書１は、例えば、インターネット又はイントラネットなどのネットワークを介して取得されても良いし、あるいは、例えば、記録媒体から取得されても良い。メタデータ２についても、同様である。入力文書１とメタデータ２が同じ作成者によるものである必要はない。また、入力文書１及び／又はメタデータ２が、ユーザ自身で作成したものであっても良い。
【００３０】
ステップＳ１とステップＳ２は、図２とは逆の順序で実行されても良いし、同時に実行されても良い。
【００３１】
入力文書特徴抽出部１３は、メタデータ２に基づいて、入力文書１の特徴を抽出する（ステップＳ３）。
【００３２】
実行環境取得部１４は、ボイスキャラクタによる読み上げを実行する当該のシステムに関する実行環境情報を取得する（ステップＳ４）。実行環境情報は、どのような方法で取得されても構わない。
【００３３】
ユーザ設定制約取得部１５は、読み上げに対するユーザ設定制約を取得する（ステップＳ５）。
【００３４】
ステップＳ４とステップＳ５は、次のパラメータ決定部１６による処理までに実行されれば良く、どのようなタイミングで実行されても構わない。
【００３５】
なお、このユーザ設定制約取得部１５を省く構成も可能である。
【００３６】
パラメータ決定部１６は、ここまでに獲得した処理結果を統合して、実際の読み上げに用いるためのパラメータ情報を決定する（ステップＳ６）。
【００３７】
ユーザ検証部１７は、ユーザがパラメータ情報を選択・確定するためのユーザ検証を実行する（ステップＳ７）。例えば、あるパラメータについて、ユーザが選択可能な候補が複数ある場合には、ユーザは、所望のパラメータを選択することによって、確定を行っても良い。
【００３８】
音声合成器１８は、上記メタデータ２及び上記パラメータ情報を使用して、入力文書１に対する合成音声を生成して、ボイスキャラクタによる読み上げ音声として出力する（ステップＳ８）。
【００３９】
以下、各部について説明する。
【００４０】
（入力取得部１１）
ユーザが利用対象とする、複数のテキストを含む書籍データは、入力取得部１１により、入力文書１として取得される。入力取得部１１は、該取得された書籍データから、テキスト情報を抽出する。該書籍データにレイアウト情報が含まれている場合には、該テキスト情報に加えて、レイアウト情報も取得する。
【００４１】
レイアウト情報は、例えば、描画されるページレイアウト内でのテキスト情報、位置、フォントサイズ、フォントスタイルなどのような情報である。また、例えば、ＸＨＴＭＬ又はスタイルシートによるフローティングレイアウトの場合には、例えば、論理要素としてテキストに付与されている改行、パラグラフ要素、タイトル要素、キャプション要素などのような情報である。
【００４２】
これらのような情報を含む入力文書１を、例えば、ＤＯＭ形式により木構造で格納しておいても良い。なお、レイアウト情報がない場合でも、例えば、改行ごとに行を表す論理要素を定義し、テキストをそれらの子要素としてぶら下げることによって、入力文書１をＤＯＭ形式で表現することができる。
【００４３】
図３に、ＤＯＭ化された入力文書の一例を示す。図３では、ＤＯＭ形式で格納された文書を、テキストノードごとにリスト表示している。この例では、個々のテキストノードは、個々の作品を識別する「作品ＩＤ」、その作品での出現順に付けられた「テキストノードＩＤ」、そのテキストノードの内容である「テキスト要素」、そのテキストが属する構造を示す「構造情報」、そのテキストがセリフ（dialogue）か地の文（description）かを示す「文タイプ」、そのテキストを話す作品中の登場人物等を示す「話者」を含む。なお、文タイプ及び話者については、例えば、既知の推定処理により又は人手により作成された情報を、属性及び属性値として埋め込んであるものとしても良い。
【００４４】
以下では、文書データをＤＯＭ形式で格納する場合を例にとって説明するが、これに制限されない。
【００４５】
（メタデータ取得部１２）
ユーザが利用対象とする上記書籍データに対するメタデータが、メタデータ取得部１２によりメタデータ２として取得される。
【００４６】
ここで、メタデータとは、例えば、コンテンツ中の文又はフレーズ又は単語の読み変え定義、特定の文脈においてキャラクタに発話させたい文又はフレーズ又は単語などの定義などを、列挙したものである。この列挙された内容から、以下の観点などに基づいて変換内容を取得し、後段で利用できる情報に変換して保持しておく。
（１）表記間の対応：コンテンツ中の部分文字列を条件として、変換内容を対応付けることができるもの。
（２）文節情報を条件とする対応：コンテンツ中の形態素又は品詞情報を条件として、変換内容を対応付けることができるもの。
３）その他の条件による対応：コンテンツ中の文字列又は形態素だけでは変換条件が一意に決まらず、対象文字列の文脈として、それが属する文書中の論理要素、近傍の単語、フレーズ、話者などと組み合わせて変換内容を対応付けることができるもの。
【００４７】
図４は、メタデータの一例を示す。この例では、メタデータ中に、適用条件と、適用条件が合致する文又はフレーズ又は単語に適用される変換（アクセント編集又は読み方定義）とが記載されたカスタマイズ定義が複数含まれている。具体的には、個々のカスタマイズ定義は、「作品ＩＤ」、「ルールＩＤ」、「条件文」、「アクセント編集」、「ボイスキャラクタ」、「読み方定義」、「文タイプ」を含む。図４の例では、使用されているボイスキャラクタとして、Ａ，Ｂ，Ｃ，Ｋ，Ｌが存在する。なお、図４の例において、ボイスキャラクタＡ，Ｂ，Ｃは、文タイプ属性として、セリフ向き（dialogue）、ボイスキャラクタＫ，Ｌは、文タイプ属性として、地の文向き（description）という特徴を持つものとする。
【００４８】
以下の説明では、図４のメタデータを具体例として用いるが、これに制限されない。
【００４９】
以下、メタデータ取得部１２の処理手順の具体的な流れについて説明する。
【００５０】
図５に、メタデータ取得部１２の処理手順の一例を示す。
【００５１】
まず、はじめに、カスタマイズ定義を順に取得する（ステップＳ１１）。
【００５２】
次に、読み込んだカスタマイズ定義の中で用いられているボイスキャラクタを確認する。同じボイスキャラクタがあれば、それらの条件も取得し、ボイスキャラクタ毎にまとめておく（ステップＳ１２）。
【００５３】
図４の具体例では、使用されているボイスキャラクタとして、Ａ，Ｂ，Ｃ，Ｋ，Ｌが存在するため、これらをそれぞれまとめておく。なお、図４は、説明の便宜上、すでにボイスキャラクタ毎にまとめられた状態で示している。
【００５４】
また、異なる条件で共通する部分表記があれば、まとめておく（ステップＳ１３）。
【００５５】
次に、表層の情報を取り出して、ルール化する（ステップＳ１４）。
【００５６】
図４の例では、まず、ルールＩＤ２，３のカスタマイズ定義にボイスキャラクタＢの“〜にゃー”という読み方定義があるため、それぞれ、この表記と条件文（条件文中の対応箇所）とを対応付けておく。
【００５７】
次に、品詞情報を取り出して、ルール化する（ステップＳ１５）。
【００５８】
上記例において、それらの表現に対して品詞レベルの情報を取り出して、条件文と読み方定義との間の関係を見る。
【００５９】
それぞれの条件表記部分の品詞情報を抜き出すと、
ルールＩＤ２：し＜動詞＞ます＜助動詞＞→“するにゃー”
ルールＩＤ３：の＜助詞＞→“にゃー”
となっており、これらを対応付けておく。
【００６０】
次に、文脈情報を取り出して、ルール化する（ステップＳ１６）。
【００６１】
上記例において、それらの条件文の文脈情報として、まず、ルールＩＤ２の条件文全体に形態素解析を適用すると、
“なんだか＜副詞＞／まったり＜副詞＞／し＜動詞＞／ます＜助動詞＞／。＜記号＞／”
と表記される。ここで、記号“／”は文節の境界を示し、山かっこで記載されたラベル名は、それぞれの形態素に対する品詞名を示しているものとする。
【００６２】
また、ルールＩＤ３の条件文に形態素解析を適用すると、
“それ＜名詞＞／は＜助詞＞／ちがう＜動詞＞／と＜助詞＞／おもう＜動詞＞／の＜助詞＞／。＜記号＞／”
となる。
【００６３】
文脈として、周辺の情報とより細かな品詞情報を利用すると、
“／し＜動詞＞／ます＜助動詞＞／”→“／する＜動詞（基本系）＞／にゃ＜助詞＞／ー＜名詞＞／”
“／おもう＜動詞＞／の＜助詞＞／”→“／おもう＜動詞（基本系）＞／にゃ＜助詞＞／ー＜名詞＞／”
となる。
【００６４】
次に、共通部分をマージする（ステップＳ１７）。
【００６５】
まず、同じボイスキャラクタのデータ内で共通部分のマージができるかをチェックする。
【００６６】
上記例において、チェックの結果、条件部と帰結部をそれぞれまとめ上げて、
“／＜動詞＞／＜助詞｜助動詞＞／”→“／＜動詞（基本系）＞／にゃ／ー／”
（ボイスキャラクタＢ）
としておく。なお、ここで、品詞ラベル間の縦棒は、論理和（ｏｒ）を示すものとする。
【００６７】
同様に、ボイスキャラクタＣに対して、
“／＜動詞＞／＜助詞｜助動詞＞／”→“／＜動詞（基本系）＞／です／の／ー／”
ボイスキャラクタＫに対して、
“／＜動詞＞／まし＜助動詞Ａ＞／＜助動詞Ｂ＞／＜助動詞Ｃ＞？／”→“／＜動詞（基本系）＞／＜助動詞Ｂ＞／で／ござる／”
といったまとめ上げ結果が得られる。
【００６８】
さらに、ルールＩＤ１の条件文に対しても、同様の処理を行う。まず、品詞情報を見ると、
“とても＜副詞＞”→“とてーも”
“です＜助動詞＞”→“ぴょん”
と表現されていることがわかる。しかし、文脈情報を用いても共通化できる部分がないため、この品詞付き表記を、まとめ上げ結果として格納しておく。
【００６９】
また、ルールＩＤ１０２の定義を見ると、アクセント表記が定義されている。これに関しても同様の処理を行い、
“ソレハチガウヨ＜名詞＞”→“ソ’レハチガ’ーウヨ”
とした対応付けを格納しておく。
【００７０】
なお、上記のアクセント表記は、’の直前にアクセントがあることを意味しているものとする。よって、上記具体例では、「ソ」と「ガ」にアクセントがある）。
【００７１】
まとめた結果（変換ルール）は、内部データとして格納し（ステップＳ１８）、すべての条件定義について処理が完了したか判定する（ステップＳ１９）。完了していないならば、ステップＳ１に戻って処理を繰り返し、完了しているならば、図５の処理を終了する。
【００７２】
図６に、図４の具体例に対する処理をまとめた結果（変換ルール）を例示する。この変換ルール例において、個々の変換ルールは、「変換ルールＩＤ」、「条件」、「帰結」、「ボイスキャラクタ」、「元ＩＤ（図４のメタデータにおけるルールＩＤ）」、「文タイプ」を含む。
【００７３】
（入力文書特徴抽出部１３）
次に、入力文書特徴抽出部１３について説明する。
【００７４】
入力文書特徴抽出部１３は、入力取得部１１により得られたＤＯＭ形式の文書データと、メタデータ取得部１２により得られた変換ルールとを入力として、各変換ルールが文書データに対してどのような影響を及ぼすかについての情報を獲得する。
【００７５】
以下、入力文書特徴抽出部１３の処理手順の一例について説明する。
【００７６】
図７に、入力文書特徴抽出部１３の処理手順の一例を示す。
【００７７】
まず、ＤＯＭ形式の文書データを受け取る（ステップＳ２１）。ここでは、一例として、図３に示される文書データが得られるものとする。
【００７８】
次に、格納済みメタデータを受け取る（ステップＳ２２）。ここでは、一例として、図６に示されるメタデータ取得結果が得られるものとする。
【００７９】
なお、図３の例におけるＪ，Ｐ，Ｑ，Ｒ，Ｔは、話者（作品中の登場人物等）であり、図６の例におけるＡ，Ｂ，Ｃ，Ｋ，Ｌは、ボイスキャラクタである。
【００８０】
続いて、格納されているメタデータから、順に、変換ルールを読み込み、文書データに適用していく（ステップＳ２３）。
【００８１】
各ノードに対してルールを適用し、条件部がマッチしたルールについては、その変換ルールＩＤと、適合したテキストノードとを対応付けて保持しておく（ステップＳ２４）。
【００８２】
次に、条件文が一致する話者との関連性を、枚挙する（ステップＳ２５）。条件文が一致しているルール中の話者（ボイスキャラクタ）と、文書データ中の話者（作品中の登場人物等）とを対応付けて保持しておく。
【００８３】
また、表記（文末表現）で類似しているルール中の話者と、文書データ中の話者との対応があれば、関連付けて保持しておく（ステップＳ２６）。
【００８４】
また、文のタイプで類似しているルール中の話者と、文書データ中の話者との対応があれば、関連付けて保持しておく（ステップＳ２７）。
【００８５】
また、文書要素（構造情報）で類似する話者との対応があれば、これを枚挙しておく（ステップＳ２８）。
【００８６】
全てのルールについて検証が完了したかどうか判定する（ステップＳ２９）。全てのルールについて検証が完了すれば、処理を終了する。一方、未検証のルール・文があれば、順にメタデータを読み込み、同様の処理を繰り返す。
【００８７】
図８と図９に、入力文書特徴抽出部１３の処理結果例を示す。
【００８８】
図８は、文書データ中の各テキストノードに対応して、ルールがマッチした変換ルールＩＤを示している。図８は、図３のような文書データにおいて、各テキストノードに適合する変換ルールＩＤを示す「適合ルールＩＤ」が更に追加されている。この具体例では、たとえば、テキストノードＩＤ４０に対して、適合ルールＩＤ５が、テキストノードＩＤ４２に対してルールＩＤ４が、さらにテキストノードＩＤ１０５に対して、ルールＩＤ１とＩＤ２とが適合していることが示されている。なお、テキストノードＩＤと適合ルールＩＤとの対応は、図３のような文書データに組み込んで保持しても良いし、図３のような文書データとは独立して保持しても良い。
【００８９】
図９は、これらの対応結果から、それぞれ異なる観点で得られた話者間の関連性についてまとめた結果である。個々の結果は、「番号」、「条件文の一致による話者との関連」、「文末表現による話者との関連」、「文タイプとの関連」、「構造情報による関連」を含む。なお、Ｐ＝＊は、Ｐは、すべてのボイスキャラクタと対応することを意味する。
【００９０】
例えば、図９の第一列では、条件文が一致することによる話者間の対応付けとして、それぞれルールと入力文書との対応付けから、第一行のＰとＡ、第二行のＲとＡ、第三行のＴとＢ、第四行のＴとＣがそれぞれ枚挙されている。
【００９１】
次に、文末表現での対応関係から、話者間の関連性を抽出する。
【００９２】
ここでは、ですます調と、だ・である調との区別を行い、同じグループに属するものを特定しておく。例えば、正規表現のマッチングにより、「.＋です。」または「.＋ます。」のいずれかにマッチしたものは「ですます調」と判定し、「.＋だ。」または「.＋である。」のいずれかにマッチしたものは「である調」と判定することによって、それらを区別することができる。この結果に基づいて、同じ性質を持っている話者を、対応付けるものとする。
【００９３】
例えば、まず、図８のテキストノードＩＤ４０が「ですます調」であることが分かるため、話者（作品中の登場人物等）Ｐと、図４における条件文で「ですます調」である話者（ボイスキャラクタ）Ａ，Ｂ，Ｃとの間に対応関係が見られたものとする。その結果、文末表現による話者との対応では、Ｐ＝Ａ，Ｂ，Ｃが得られる。
【００９４】
また、図８のテキストノードＩＤ１０５の話者Ｔは「ですます調」であることがわかり、これに対応する適合ルールＩＤ１，ＩＤ２は、図４における話者Ａ，Ｂに対応する。その結果、Ｔ＝Ａ，Ｂが得られる。
【００９５】
次に、文タイプに基づく関連情報を抽出しておく。
【００９６】
例えば、図９の番号（１）では、ここまでの関連として話者（作品中の登場人物等）Ｐと話者（ボイスキャラクタ）Ａとの対応が候補として挙がっているが、この話者Ｐのテキストノード「それじゃあ、あんまりです。」を見ると、この文タイプは「セリフ向き（dialogue）」であることがわかる。一方で、このテキストのノードにヒットしたルール（図６の変換ルールＩＤ５）における話者Ａも、文タイプ「セリフ向き（dialogue）」の特徴を有しているので、同一属性を保持していることになる。
【００９７】
また、番号（２）でも同様に、話者Ｒのテキストノード「だが、これはとても君たちの力では無理だと言っていたのではなかったかね？」についても文タイプは「セリフ向き（dialogue）」であり、このルールが適合している変換ルールにおける話者Ａも「セリフ向き（dialogue）」であり、同一の関係となっている。
【００９８】
一方で、番号（３）と（４）については、入力文のタイプが「地の文向き（description）であるが、それぞれに対応する変換ルール（ＩＤ１，２）の話者は、図６では「セリフ向き（dialogue）」のＢ，Ｃであったので、属性が異なることが分かる。
【００９９】
さらに、構造情報の関連について記載している。
【０１００】
ここでは、最小の汎化となる要素（section_body）のみを明示し、それ以外の差分を省略（＊）して記載している。
【０１０１】
以上を入力文書特徴抽出部１３の抽出結果として、後段の処理に渡す。
【０１０２】
（実行環境取得部１４）
次に、実行環境取得部１４について説明する。
【０１０３】
実行環境取得部１４では、ユーザが音声合成による読み上げを行うおうとしているシステムの環境に関する情報（システム環境情報）を取得する。
【０１０４】
システム環境情報は、具体的には、デバイスとＯＳの情報の他、ユーザが利用可能な、音声合成エンジン、ボイスキャラクタ、パラメータレンジなどの情報である。インストールされている音声合成エンジンから取得できるプロパティ情報として、例えば、音声合成エンジン（ＴＴＳ）の名称とバージョンがあり、利用可能な音声（ボイスキャラクタ）の属性として、キャラクタ名称、利用可能な言語、話者性別、話者年齢などがある。パラメータレンジは、音声合成エンジンがサポートするパラメータ情報として得られる。
【０１０５】
図１０に、この実行環境取得部１４による取得結果例を示す。
【０１０６】
ここでは、利用可能な２点の動作環境について例を示す。
【０１０７】
まず、デバイス（端末）の種類とＯＳ名、音声合成エンジン名の他、利用可能なキャラクタ、利用可能な言語（この例では、ＪＰ（日本語）とＥＮ（英語））、利用可能な性別（この例では、Ｍａｌｅ（男性）、Ｆｅｍａｌｅ（女性））、利用可能なキャラクタの声年代（この例では、Ａｄｕｌｔ（大人）、Ｃｈｉｌｄ（子供））といった属性が枚挙されている。
【０１０８】
さらに、音声合成用のパラメータとして、Ｖｏｌｕｍｅ（調整できる音量幅）が０から１００までの連続値であること、Ｐｉｔｃｈ情報については、図１０の上段に示されるリソースであれば、連続値として（−２０から２０）が設定できる一方で、図１０の下段に示されるリソースであれば、５段階の離散値しかサポートしない、といったことが示されているものとする。また、Ｒａｎｇｅ、Ｒａｔｅ、Ｂｒｅａｋ（ポーズ長）といったパラメータについても同様に、連続値（ｃｏｎｔｉｎｕｏｕｓ）か、離散値（ｄｅｓｃｒｅｔｅ）か、さらに連続値の場合は、値の幅や離散値の場合は、何段階の幅をとれるかの段数などが記載されているものとする。
【０１０９】
これらの取得結果を後段の処理に渡す。
【０１１０】
（ユーザ設定制約取得部１５）
次に、ユーザ設定制約取得部１５について説明する。
【０１１１】
ユーザ設定制約は、例えば、メタデータよりも優先して適用すべきユーザの指定条件及び／又は制約条件などである。具体的には、例えば、特定のパラメータの値を指定し、あるいは、特定のパラメータの値域を指定しても良い。
【０１１２】
図１１に、ユーザ設定制約取得部１５がユーザからの指示情報を取得するためのユーザインタフェースの例を示し、図１２に、取得した結果の格納例を示す。
【０１１３】
まず、ユーザは、図１１に例示するような、各項目に対応して自由に値を設定することができるユーザインタフェースを使用して、読み上げに影響を及ぼす項目について、あらかじめ制約を設定しておくことができるものとする。
【０１１４】
図１１の例において、項目“感情変化読み”では、例えば文書中の激怒、怒号、号泣等に相当する激しい感情表現について、合成音声として再現することをどの程度許容するかを指定する。この項目について、例えば“フル（制限なし）”と設定されていれば、メタデータ又はユーザカスタマイズ結果の激怒又は号泣等の定義に対して、それをそのまま感情韻律辞書などを適用したり、合成エンジンに与えるパラメータを変更するなどの手法で、読み上げ時に再現を試みる。一方、これ以外の値に設定されている場合は、その割合に応じて、感情表現の強さの度合いを調整する。例えば、微小であれば、感情表現の効果を９割方減じて読み上げを行い、穏やかであれば半分ほどの程度（激怒→怒）に抑えた読み上げを行う、などである。
【０１１５】
また、項目“ワード・表現”では、小説において又はストーリー上で出現する、ならず者又は乱暴者の残虐・乱暴・粗雑な表現、言い回し韻律などの程度情報を設定できるものとする。例えば、制限がなければ、メタデータ又はユーザカスタマイズ情報に沿った読み上げを実現する一方で、この設定値を下げている場合には、太くて低い凄みのある声の効果を低減したり、特定の表現又は文又はフレーズ又は単語を置き換えた読み上げを行う。
【０１１６】
また、項目“音量・テンポ変化”では、例えば、怪談クライマックス時の「わっ！」といった驚かせ表現、突然の叫び声、疾走・逃走中の激しい緊迫又は速度間のある読み上げ効果について、程度情報を指定する。先の例と同じように、“フル”であればメタデータ定義又はユーザのカスタマイズ情報にそのまま従うが、この設定に制約を掛けている場合には、これらの程度を落として読み上げを行う。
【０１１７】
図１２に、ユーザインタフェース上での設定を、ユーザ設定制約取得部１５で格納した場合の一例を示す。
【０１１８】
図１１に示すユーザインタフェース上のスライダ値に応じて、各項目の上限値（可変値）が設定されるものとする。ここでは、感情表現の程度がフルの場合の７５％程度、許容するワードや表現で３０％程度、音量やテンポ変化の度合いは、フルの場合の５５％程度までを許容するものと設定されたと仮定する。
【０１１９】
これらの結果を、後段のパラメータ決定部１６に渡す。
【０１２０】
（パラメータ決定部１６、ユーザ検証部１７）
次に、パラメータ決定部１６及びユーザ検証部１７について説明する。
【０１２１】
パラメータ決定部１６では、ここまでに獲得した処理結果を統合して、実際の読み上げに用いるためのパラメータ情報を決定する。
【０１２２】
図１３に、パラメータ決定部１６の処理手順の一例を示す。
【０１２３】
以下、パラメータ決定部１６の処理手順の一例について説明する。
【０１２４】
まず、前段までの処理結果であるメタデータの格納結果（ステップＳ３１）、入力文書特徴抽出部の処理結果（ステップＳ３２）、実行環境取得部１４の抽出結果（ステップＳ３３）およびユーザ設定制約取得部１５での抽出結果（ステップＳ３４）を受け取る。
【０１２５】
次に、ユーザに提示する各項目について、それぞれの再現度を計算する。なお、ステップＳ３６とステップＳ３７の一方又は両方を省く構成も可能である。
【０１２６】
ここで、再現度の比較対象とする推奨環境について説明する。
【０１２７】
推奨環境は、本実施形態では、ボイスキャラクタに関する推奨環境、読み上げの際の感情（表現）に関する推奨環境（オプション）、パラメータに関する推奨環境（オプション）の３つを想定しているが、これに制限されない。
【０１２８】
ボイスキャラクタに関する推奨環境について説明する。
【０１２９】
例えば、入力文書特徴抽出部１３による処理結果、例えば図８と図９の結果から、例えば、図３の電子書籍に図４のメタデータを適用する場合に推奨されるボイスキャラクタを選択することができる。例えば、図３の文書データ中の話者Ｐ，Ｒ，Ｔに、それぞれ、図４のメタデータ中のボイスキャラクタＢ，Ａ，Ｃを対応させる割り当てる方が可能であることが分る。また、例えば、文書データにおいて話者の属性（例えば、言語・性別・年齢・性格など）のデータがあり、かつ、メタデータにおいてボイスキャラクタの属性（例えば、言語・性別・年齢・性格など）のデータがある場合に、入力文書特徴抽出部１３による処理結果に加えて、それら属性のデータを考慮して、文書データ中の話者に、メタデータ中のボイスキャラクタを割り当てる方法も可能である。その他にも、推奨ボイスキャラクタを選択する様々な方法が可能である。
【０１３０】
図１４に、ボイスキャラクタの推奨環境を例示する（なお、図１４のボイスキャラクタの名称は、これまでとは異なる名称で例示しているが、これまでの例を使用すれば、図１４のボイスキャラクタの推奨環境に、ボイスキャラクタＡ，Ｂ，Ｃなどが記述されることになる。）
なお、図１４の例では、ボイスキャラクタのみリストされているが、各ボイスキャラクタに対応する文書データ中の話者を併せて提示しても良い。
【０１３１】
ところで、ユーザのシステム環境においては、ボイスキャラクタとして、Ａ，Ｂ，Ｃなどあるいは図１４で言えば「川崎太郎」などが利用可能とは限らない。ユーザが利用できるのは、ユーザのシステム環境において利用可能なボイスキャラクタのみである。
【０１３２】
そこで、推奨されるボイスキャラクタと、ユーザが利用可能なボイスキャラクタとを比較して、話者に関する再現度を計算する（ステップＳ３５）。
【０１３３】
話者に関する再現度は、例えば、入力文書に出現する話者の特徴量（及び／又は、該話者に対応するボイスキャラクタの特徴量）と、ユーザが音声合成器で利用可能なキャラクタボイスの特徴量の一致度として表現できる。具体的には、例えば、それぞれが属性としてもつ利用可能な言語・性別・年齢などの各項目を、適当に正規化して、ベクトルの要素として表現しておき、それらのベクトル間の類似度（例えば、コサイン距離）を求め、これを一致度の尺度として用いることができる。その他にも、種々の再現度計算方法が可能である。
【０１３４】
次に、利用するのが推奨されるパラメータのカバー幅のデータが例えばメタデータの一部として提供されている場合に、音声合成器で利用可能なパラメータのカバー幅について、再現度を計算する（ステップＳ３６）。これも、上記と同様、例えば、パラメータのカバー幅を、ベクトルの要素として、ベクトル間の類似度を求め、これを一致度の尺度として用いることができる。
【０１３５】
次に、利用するのが推奨される感情表現（例えば、平、驚、怒、哀、厭など）のデータが例えばメタデータの一部として提供されている場合に、音声合成器で利用可能な感情表現の有無について、再現度を計算する（ステップＳ３７）。これも、上記と同様、例えば、感情表現の有無を、ベクトルの要素として、ベクトル間の類似度を求め、これを一致度の尺度として用いることができる。
【０１３６】
なお、ステップＳ３５〜Ｓ３７は、どのような順序で計算を行っても良い。また、ステップＳ３６とＳ３７の一方又は両方を省く構成も可能である。
【０１３７】
また、統合した全体的な一致度（再現度）についても計算しておく（ステップＳ３８）。この総合的な再現度は、例えば、各機能に関する一致度の積として、以下のように定義することができる。
再現度＝話者特徴量の一致度×利用可能感情の一致度×再生可能なパラメータの一致度×メタデータ改変箇所の文書特徴カバー率
なお、総合的な再現度として、例えば、数値を示しても良いし、あるいは、数段階にレベル分けして、そのレベル値を示しても良い。
【０１３８】
ユーザ検証部１７は、上記のように算定された各機能に関する一致度について、例えば図１４に示すように、機能ごとに個別に提示するとともに、総合的な再現度を併せて提示する（ステップＳ３９）。
【０１３９】
例えば、第２行の作品において、推奨ボイスキャラクタ「岡山高知」に対して、実行環境においては、「岡山高知」が使用可能でなく、最も高い一致度をもつ「川崎太郎」が提示されている。また、ここでは、「川崎太郎」の横のボタンを押すことによって、次候補以降の推奨ボイスキャラクタに変更・選択できるようになっている。
【０１４０】
また、例えば、第１行の作品において、推奨ボイスキャラクタ「川崎太郎」に対して、実行環境においては、これと一致する「川崎太郎」が提示されている。この場合には、実行環境におけるボイスキャラクタの次候補は提示しないものとしている。
【０１４１】
なお、各機能について、一致度を明示的に提示するようにしても良い。あるいは、例えば、一致度の低い項目を提示する欄の枠内自体又は表示文字を、ハイライト表示しても良い。例えば、その際に、一致度を何段階かにレベル分けして、レベルごとに異なる色又は明るさを使用しても良い。逆に、一致度の高い項目を提示する欄の枠内自体又は表示文字を、ハイライト表示しても良い。
【０１４２】
また、総合的な再現度を提示するにあたって、総合的な再現度が高い場合と低い場合とで、異なる形態（例えば、異なる色）で表示しても良い。例えば、図１４の例で、「Excellent」「Good」「Okay」と、「Poor」「Bad」とで、異なる表示色を使用しても良い。
【０１４３】
これらの他にも、ユーザに結果を伝えやすくするための様々な表示方法が可能である。
【０１４４】
次に、ユーザの確認・修正を得る（ステップＳ４１）。
【０１４５】
例えば、第１候補として提示されているボイスキャラクタの横のボタンを押すことによって、次候補以降の推奨ボイスキャラクタに変更・選択する。
【０１４６】
ステップＳ４１のユーザの確認・修正は、ユーザが繰り返し行うことが可能であり、提示した結果に対してユーザによる確認・選択指定が完了すれば（ステップＳ４０）、この処理を終了する。
【０１４７】
なお、ユーザが、最終的な確定の指示を明示的に入力するようにしても良い。例えば、確定ボタンを設けても良い。
【０１４８】
処理結果は、制御パラメータとして音声合成器１８へ渡される。
【０１４９】
（音声合成器１８）
音声合成器１８は、制御用パラメータとして、各話者指定及び文書表現にマッチする変換ルールを適用しながら、合成音声を生成して、ボイスキャラクタによる読み上げ音声として出力する。
【０１５０】
以上の手順により、ユーザが実際に利用できる計算機リソースや機能、読み上げ対象とするコンテンツの違いを考慮して、再現性を確保した再生が実現できる。
【０１５１】
本実施形態によれば、文書データの読み上げに関するメタデータのユーザカスタマイズの容易性と、文書データの読み上げに使用するシステム環境の柔軟性を確保するとともに、読み上げの再現性を損なわないようにすることが可能になる。
【０１５２】
また、上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいて実行されることが可能である。汎用の計算機システムが、このプログラムを予め記憶しておき、このプログラムを読み込むことにより、上述した実施形態の文書読み上げ支援装置による効果と同様な効果を得ることも可能である。上述の実施形態で記述された指示は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷなど）、半導体メモリ、またはこれに類する記録媒体に記録される。コンピュータまたは組み込みシステムが読み取り可能な記録媒体であれば、その記憶形式は何れの形態であってもよい。コンピュータは、この記録媒体からプログラムを読み込み、このプログラムに基づいてプログラムに記述されている指示をＣＰＵで実行させれば、上述した実施形態の文書読み上げ支援装置と同様な動作を実現することができる。もちろん、コンピュータがプログラムを取得する場合または読み込む場合はネットワークを通じて取得または読み込んでもよい。
また、記録媒体からコンピュータや組み込みシステムにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワーク等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行してもよい。
さらに、本実施形態における記録媒体は、コンピュータあるいは組み込みシステムと独立した媒体に限らず、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードして記憶または一時記憶した記録媒体も含まれる。
また、記録媒体は１つに限られず、複数の媒体から本実施形態における処理が実行される場合も、本実施形態における記録媒体に含まれ、媒体の構成は何れの構成であってもよい。
【０１５３】
なお、本実施形態におけるコンピュータまたは組み込みシステムは、記録媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するためのものであって、パソコン、マイコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であってもよい。
また、本実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本実施形態における機能を実現することが可能な機器、装置を総称している。
【０１５４】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１５５】
１…入力文書、２…メタデータ、１１…入力取得部、１２…メタデータ取得部、１３…入力文書特徴抽出部、１４…実行環境取得部、１５…ユーザ設定制約取得部、１６…パラメータ決定部、１７…ユーザ検証部、１８…音声合成器。
【特許請求の範囲】
【請求項１】
複数のテキストを含む文書データを取得する文書取得部と、
ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するメタデータ取得部と、
各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する抽出部と、
前記文書データの読み上げを実行する環境に関する実行環境情報を取得する実行環境情報取得部と、
前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する決定部と、
前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるユーザ検証部とを備えることを特徴とする文書読み上げ支援装置。
【請求項２】
前記ユーザ検証部を介して確定された前記パラメータを使用して、前記文書データに対する読み上げ音声を生成する音声合成器を更に備えることを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項３】
前記メタデータよりも優先すべきユーザ設定制約をユーザから取得するためのユーザ設定制約取得部を更に備えることを特徴とする請求項１または２に記載の文書読み上げ支援装置。
【請求項４】
前記決定部は、前記ユーザ設定制約を考慮して、前記パラメータの取り得る値又は値域を限定することを特徴とする請求項３に記載の文書読み上げ支援装置。
【請求項５】
前記ユーザ設定制約は、読み上げで使用する感情表現の変化幅、感情種類、調子、読み上げ対象となる語又はフレーズ、音量又はテンポ変化の幅又は値の少なくとも一つを定義できることを特徴とする請求項３または４に記載の文書読み上げ支援装置。
【請求項６】
前記抽出部は、前記文書データの特徴を抽出するにあたって、前記メタデータに記載された対応関係を汎化して適用することによって、一部の前記定義情報から、関連情報全体に適用する抽出規則を生成することを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項７】
前記定義情報として、対象となる文又は単語と、それに対応する読み方又はアクセントが定義され、
前記抽出部は、前記定義情報から対応関係を段階的に汎化して適切な対応関係を取得することを特徴とする入力文書特徴抽出部を有する請求項１に記載の文書読み上げ支援装置。
【請求項８】
前記抽出部は、前記文書データの特徴を抽出するにあたって、表層表現、文末表現、品詞情報、文の構造情報又は文タイプを用いることを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項９】
前記決定部は、前記文書データ中に出現する話者の性質と、前記メタデータ中で定義される話者の性質との間の類似性に基づいて、前記パラメータの候補を決定することを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項１０】
文書取得部、メタデータ取得部、抽出部、実行環境情報取得部、決定部、ユーザ検証部及び音声合成器を備える文書読み上げ支援装置の文書読み上げ支援であって、
前記文書取得部が、複数のテキストを含む文書データを取得するステップと、
前記メタデータ取得部が、ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するステップと、
前記抽出部が、各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出するステップと、
前記実行環境情報取得部が、前記文書データの読み上げを実行する環境に関する実行環境情報を取得するステップと、
前記決定部が、前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定するステップと、
前記ユーザ検証部が、前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるステップとを有することを特徴とする文書読み上げ支援方法。
【請求項１１】
文書読み上げ支援装置としてコンピュータを機能させるためのプログラムであって、
複数のテキストを含む文書データを取得する文書取得部と、
ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するメタデータ取得部と、
各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する抽出部と、
前記文書データの読み上げを実行する環境に関する実行環境情報を取得する実行環境情報取得部と、
前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する決定部と、
前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるユーザ検証部とをコンピュータに実現させるためのプログラム。
【請求項１】
複数のテキストを含む文書データを取得する文書取得部と、
ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するメタデータ取得部と、
各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する抽出部と、
前記文書データの読み上げを実行する環境に関する実行環境情報を取得する実行環境情報取得部と、
前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する決定部と、
前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるユーザ検証部とを備えることを特徴とする文書読み上げ支援装置。
【請求項２】
前記ユーザ検証部を介して確定された前記パラメータを使用して、前記文書データに対する読み上げ音声を生成する音声合成器を更に備えることを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項３】
前記メタデータよりも優先すべきユーザ設定制約をユーザから取得するためのユーザ設定制約取得部を更に備えることを特徴とする請求項１または２に記載の文書読み上げ支援装置。
【請求項４】
前記決定部は、前記ユーザ設定制約を考慮して、前記パラメータの取り得る値又は値域を限定することを特徴とする請求項３に記載の文書読み上げ支援装置。
【請求項５】
前記ユーザ設定制約は、読み上げで使用する感情表現の変化幅、感情種類、調子、読み上げ対象となる語又はフレーズ、音量又はテンポ変化の幅又は値の少なくとも一つを定義できることを特徴とする請求項３または４に記載の文書読み上げ支援装置。
【請求項６】
前記抽出部は、前記文書データの特徴を抽出するにあたって、前記メタデータに記載された対応関係を汎化して適用することによって、一部の前記定義情報から、関連情報全体に適用する抽出規則を生成することを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項７】
前記定義情報として、対象となる文又は単語と、それに対応する読み方又はアクセントが定義され、
前記抽出部は、前記定義情報から対応関係を段階的に汎化して適切な対応関係を取得することを特徴とする入力文書特徴抽出部を有する請求項１に記載の文書読み上げ支援装置。
【請求項８】
前記抽出部は、前記文書データの特徴を抽出するにあたって、表層表現、文末表現、品詞情報、文の構造情報又は文タイプを用いることを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項９】
前記決定部は、前記文書データ中に出現する話者の性質と、前記メタデータ中で定義される話者の性質との間の類似性に基づいて、前記パラメータの候補を決定することを特徴とする請求項１に記載の文書読み上げ支援装置。
【請求項１０】
文書取得部、メタデータ取得部、抽出部、実行環境情報取得部、決定部、ユーザ検証部及び音声合成器を備える文書読み上げ支援装置の文書読み上げ支援であって、
前記文書取得部が、複数のテキストを含む文書データを取得するステップと、
前記メタデータ取得部が、ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するステップと、
前記抽出部が、各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出するステップと、
前記実行環境情報取得部が、前記文書データの読み上げを実行する環境に関する実行環境情報を取得するステップと、
前記決定部が、前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定するステップと、
前記ユーザ検証部が、前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるステップとを有することを特徴とする文書読み上げ支援方法。
【請求項１１】
文書読み上げ支援装置としてコンピュータを機能させるためのプログラムであって、
複数のテキストを含む文書データを取得する文書取得部と、
ルールを適用すべきテキストに関する条件と、該条件が適合するテキストに対する読み上げスタイルとを含む定義情報を複数含むメタデータを取得するメタデータ取得部と、
各々の前記定義情報を前記文書データに含まれるテキストに適用することによって、前記文書データの特徴を抽出する抽出部と、
前記文書データの読み上げを実行する環境に関する実行環境情報を取得する実行環境情報取得部と、
前記文書データの特徴及び前記実行環境情報に基づいて、前記メタデータを前記文書データに適用して読み上げを実行する際に使用するパラメータの候補を決定する決定部と、
前記パラメータの候補をユーザに提示し、選択又は確定を含む検証指示を受け付けるユーザ検証部とをコンピュータに実現させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１３−７２９５７（Ｐ２０１３−７２９５７Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１１１６０（Ｐ２０１１−２１１１６０）
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
[ Back to top ]