JP4289080B2

JP4289080B2 - 音声データ提供装置、音声データ提供方法、および音声データ提供プログラム

Info

Publication number: JP4289080B2
Application number: JP2003298715A
Authority: JP
Inventors: 聡渡辺
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2003-08-22
Filing date: 2003-08-22
Publication date: 2009-07-01
Anticipated expiration: 2023-08-22
Also published as: JP2005070304A

Description

本発明は音声データ提供装置、音声データ提供方法、および音声データ提供プログラムに関し、例えば、Ｗｅｂページ上のテキストデータを音声合成技術を用いて音声データに変換した上でクライアント端末側（Ｗｅｂブラウザ側）へ配信する場合などに適用して好適なものである。

Ｗｅｂページ上のテキストデータを音声合成技術を用いて音声データに変換した上でクライアント端末側（Ｗｅｂブラウザ側）へ配信すること自体は比較的容易である。

１つのＷｅｂページ上には、さまざまなテキスト情報が含まれている。

例えば、１つのニュース記事が書かれたＷｅｂページにおいて、一般にユーザが音声出力したい内容は、記事のタイトルおよび本文に相当するテキスト情報であるが、このＷｅｂページ上には同時に、他のＷｅｂページへのハイパーリンク、著作権関連、広告などに相当するテキスト情報が存在する。

これらテキスト情報を全て音声出力すると、非常に聞きづらい音声合成になる可能性がある。

そのため、ユーザが音声出力したいＷｅｂページの内容に相当する文字列を適切に指定する必要がある。

Ｗｅｂページには、本来のＷｅｂページの内容（パソコンなどに画面表示される文字列など）以外に、この文字列をマークアップするためのタグが多数含まれているが、このタグ自体は、Ｗｅｂブラウザが画面表示などの処理を実行する際、制御に利用する制御情報であるから、通常、ユーザに見せるものではない。ただしＷｅｂページの本体である元々のＨＴＭＬソースでは、このタグも、前記Ｗｅｂページの内容と同様な文字列で記述されているため、前記音声合成技術の具体的な内容によっては、タグまで音声合成されて音声出力される可能性がある。本来、ユーザが知る必要のないタグまで音声出力されると非常に聞きづらいものとなるが、このようなタグを避け、前記Ｗｅｂページの内容に対応する所望の文字列だけを音声合成して出力する技術として、下記の特許文献１に記載されたものがある。

特許文献１では、予めＷｅｂページに所定の音声合成タグを配置して、音声合成の対象となる範囲を明示する構成となっている。この音声合成タグは、ＤＴＤ（Document Type Definition）に定義されておらず、ＨＴＭＬのタグには含まれない特殊なタグであるが、特許文献１の技術に対応したプロキシサーバでは、正確に解釈し、音声合成タグで指定された範囲を、音声合成の対象とすることができる。
特開２００１−１００９７６号公報

ところで、上述した特許文献１の技術の場合、Ｗｅｂページの提供元であるＷｅｂサーバ側（すなわち、Ｗｅｂコンテンツの提供者側）で、特殊な音声合成タグを含むＷｅｂページを予め作成しておくことが必要になる。この作成には、情報処理装置を利用して自動的に行う場合と、人手による場合とがあるが、情報処理装置を利用する場合、どのようなルールに基づいて処理にすればＷｅｂページ内の適切な位置に音声合成タグを配置することができるのかが、必ずしも明確ではなくその実行が困難である。また、人手による場合、これから新たに作成するＷｅｂページに音声合成タグを配置することは比較的容易であるとも考えられるが、すでに存在し、多数のユーザに提供されている膨大な数のＷｅｂページに対して音声合成タグを付加することは、多大な労力を要する作業となり、実現性が低い。

その一方で、音声データの提供を受けるユーザ側では、予め決められた順番で時系列に聞き取りするだけではなく、段落飛ばしによって、興味のない内容は聞かずに次の内容を聞いたり、すでに音声出力された内容を聞き返しによって、もう１度、聞き直したりしたいという要望があるが、前記特許文献１の技術などではこのような要望に十分に応えることは難しく、利便性や柔軟性が低い。

かかる課題を解決するために、第１の本発明では、記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供する音声データ提供装置において、（１）複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納しているルール格納部と、（２）文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成する第１のブロック記述内容生成部と、（３）前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換する第２のブロック記述内容生成部と、（４）前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換してファイルに収容する音声合成処理部とを備え、このファイルを、前記音声データとして提供することを特徴とする。

また、第２の本発明では、記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供する音声データ提供方法において、（１）ルール格納部は、複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納し、（２）第１のブロック記述内容生成部は、文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成し、（３）第２のブロック記述内容生成部は、前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換し、（４）音声合成処理部が、前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換してファイルに収容し、このファイルを、前記音声データとして提供することを特徴とする。

さらに、第３の本発明では、記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供するための音声データ提供プログラムであって、コンピュータを、（１）複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納しているルール格納部と、（２）文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成する第１のブロック記述内容生成部と、（３）前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換する第２のブロック記述内容生成部と、（４）前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換して、音声データとして提供するファイルに収容する音声合成処理部として機能させることを特徴とする。

本発明によれば、利便性、柔軟性、および実現性を高めることができる。

（Ａ）実施形態
以下、本発明にかかる音声データ提供装置、音声データ提供方法、および音声データ提供プログラムを、Ｗｅｂによる通信システムに適用した場合を例に、実施形態について説明する。

この通信システムによるサービスの提供方法は、リアルタイム型とバックグラウンド型に分けることができる。

リアルタイム型は、ユーザから要求が届くことを契機としてすべての処理を開始し、処理が終了したときに、処理の結果を返すものである。

これに対しバックグラウンド型は、予めユーザからの要求またはユーザからの要求に相当する情報を得ておき、その情報に基づいて処理を行って音声ファイルを蓄積しておくものである。したがってバックグラウンド型では、実際にユーザからの要求が届いたときには、すでに生成し蓄積済みの音声ファイルを即座に返すことができる。

音声ファイルを蓄積しておくための記憶容量が少ない点やコンテンツの最新性を確保できる点などでは、リアルタイム型のほうが有利であるが、ユーザからの要求が届いてから音声ファイルを返送するまでの応答時間の短さに対応するレスポンス性能の点では、バックグラウンド型のほうが有利である。本実施形態の通信システムは、リアルタイム型、バックグラウンド型のいずれを用いることも可能であるが、以下の説明では、主としてリアルタイム型を想定する。

（Ａ−１）第１の実施形態の構成
本実施形態にかかる通信システム１０の全体構成例を図１に示す。

図１において、当該通信システム１０は、インターネット１１と、音声データ配信サーバ１２と、音声データ合成サーバ１３と、情報サーバ群１４とを備えている。

このうちインターネット１１は、広域イーサネット（登録商標）網やＩＰ−ＶＰＮ網などのＷＡＮ（ワイドエリアネットワーク）であってもよく、比較的大規模なＬＡＮ（ローカルエリアネットワーク）などに置換することも可能であるが、ここでは、インターネットであるものとする。

また、情報サーバ群１４に含まれる各情報サーバ（例えば、１４Ａ）は、要求に応じてＷｅｂページを提供する機能を要するＷｅｂサーバであるものとする。例えば、ＦＴＰサーバなどを用いても、Ｗｅｂページに相当するＨＴＭＬファイルを提供することが可能であるため、当該情報サーバ群１４に含まれる全部または一部の情報サーバがＦＴＰサーバなどであってもかまわないが、ここでは説明を簡単にするため、情報サーバ１４Ａ〜１４Ｄはすべて、Ｗｅｂサーバであるものとする。

本実施形態の構成上、当該Ｗｅｂサーバ１４Ａ〜１４Ｄは、合成サーバ１３とのみ通信する。もちろん、利用者端末１５にＷｅｂブラウザが搭載されていれば、利用者端末１５から直接、Ｗｅｂサーバ（例えば、１４Ａ）にアクセスすることも可能であるが、そのアクセスで利用者端末１５がＷｅｂサーバから受信できるコンテンツは単なるＷｅｂページであり、本実施形態で提供する後述の音声ファイル（例えば、ＰＡ１１）ではない。

１つのＷｅｂサーバには多数のＷｅｂページが登録されていてよいが、ここでは、説明を簡単にするため、Ｗｅｂサーバ１４Ａには、ＷｅｂページＷＡ１とＷＡ２が登録され、Ｗｅｂサーバ１４ＢにはＷｅｂページＷＢ１が登録され、Ｗｅｂサーバ１４ＣにはＷｅｂページＷＣ１が登録され、Ｗｅｂサーバ１４ＤにはＷｅｂページＷＤ１が登録されているものとする。各Ｗｅｂサーバ１４Ａ〜１４Ｄは、ＨＴＴＰリクエストメッセージを受信すると、そのＨＴＴＰリクエストメッセージで指定されたＷｅｂページを、ＨＴＴＰレスポンスメッセージの本体として返送する。

本実施形態において、前記利用者端末１５は、ＷｅｂブラウザＢＲ１を搭載した通信端末で、利用者（ユーザ）Ｕ１によって操作される。具体的には、パーソナルコンピュータや携帯電話機などを、当該利用者端末１５として使用することが可能である。図１には１つの利用者端末１５のみを図示しているが、通信システム１０内に多数の利用者端末が含まれていてよいことは当然である。

なお、本来のＷｅｂブラウザの機能だけでは音声ファイルの再生出力を行うことはできないため、本実施形態のＷｅｂブラウザＢＲ１には補助機能ＡＤ１を付加する必要がある。この補助機能ＡＤ１は、プラグインソフトまたはヘルパーアプリケーションの形で実現することができる。

細かくみると、ヘルパーアプリケーションは、Ｗｅｂブラウザの外部に存在する独立したプログラムであって、必要が生じたときにＷｅｂブラウザによって自動的に起動されるのに対し、プラグインソフトはＷｅｂブラウザに付加されてＷｅｂブラウザと一体となって機能するプログラムであるという相違がある。この相違が重要なものとなるか否かは、利用者端末１５が一連の音声ファイル（例えば、同じＷｅｂページＷＡ１から生成された複数の音声ファイルＰＡ１１〜ＰＡ１４）に対する取得要求をどのようなタイミングで送信するかに依存する。

すなわち、これら一連の音声ファイルＰＡ１１〜ＰＡ１４をまとめて取得する場合ならば、この相違は重要ではなくなるが、１ファイルずつ取得し、その取得のためにＷｅｂブラウザＢＲ１の機能を必要とする場合ならば、プラグインソフトのほうが有利である。ヘルパーアプリケーションが処理した結果として表示される画面は、（ＷｅｂブラウザＢＲ１とは別個の）ヘルパーアプリケーション自身の画面であるのに対し、プラグインソフトが処理した結果として表示されるものは、ＷｅｂブラウザＢＲ１の画面上に表示されるからである。ここで、当該画面（音声再生画面）は、例えば、図１０に示すようなものとなる。

本実施形態において、利用者端末１５が一連の音声ファイルに対する取得要求を送信するタイミングには、これらの両方があり得るので、以下では、補助機能ＡＤ１には基本的にヘルパーアプリケーションおよびプラグインソフトの双方が対応するものとし、必要な場合にのみ、当該補助機能ＡＤ１が、ヘルパーアプリケーションを指すか、プラグインソフトを指すかを明示するものとする。

当該補助機能ＡＤ１は、当初から利用者端末１５にインストールされているものであってもよく、必要が生じたときに配信サーバ１２などから動的に送信して利用者端末１５にインストールされるものであってもよい。

合成サーバ１３は、利用者端末１５からの要求に応じて、該当するＷｅｂページを、タグを含まない音声データ（音声ファイル）に変換する機能を有するもので、一種のゲートウエイ装置である。

当該合成サーバ１３は、前記Ｗｅｂサーバ１４Ａ〜１４Ｄのほか、前記配信サーバ１２とも通信する。利用者端末１５からの要求は直接、この合成サーバ１３が利用者端末１５から受け取るようにしてもかまわない（これは、ユーザＵ１がＵＲＬを入力するためのＷｅｂページであるＵＲＬ送信画面の構成（例えば、図８（Ａ）に示すＷｅｂページのＨＴＭＬソースの内容（具体的には、＜ｆｏｒｍ＞タグのａｃｔｉｏｎ属性の属性値を合成サーバ１３内を指定するＵＲＬとすること））によって簡単に実現することができる）が、ここでは、配信サーバ１２経由で受け取るものとする。

利用者端末１５から直接、要求（ＵＲＬ）が合成サーバ１３に供給されるようにした場合、利用者端末１５側における操作の内容（ユーザＵ１がＵＲＬを入力して要求を出したか否か）を配信サーバ１２が知る方法がないため、配信サーバ１２は届くか否か不明な音声ファイルを常時、待ち受けなければならないが、配信サーバ１２経由で要求を合成サーバ１３へ届けるようにすれば、ユーザＵ１の操作内容を知ることができ、合成サーバ１３から届くことが分かっている音声ファイルだけを待ち受ければよくなる。これは、セキュリティ強度を高めることができる点などで、有利である。

配信サーバ１２経由で合成サーバ１３が受け取る利用者端末１５からの要求には、当該利用者端末１５を操作するユーザＵ１が指定したＵＲＬが含まれている。

また、Ｗｅｂサーバ群１４との通信は、当該ＵＲＬで指定されたＷｅｂページを、Ｗｅｂサーバ群１４に含まれる各Ｗｅｂサーバ１４Ａ〜１４Ｄから取得するための通信であるから、この通信のために、当該合成サーバ１３は、ＨＴＴＰクライアントの機能を備える必要がある。

配信サーバ１２は、利用者端末（ここでは、１５）からの要求に応じて音声ファイルを配信するサーバである。この音声ファイルは、前記合成サーバ１３によって生成されたものである。したがって本実施形態の構成上、サーバ１２，１３，１４Ａ〜１４Ｄのうち、利用者端末１５と直接通信するのは、当該配信サーバ１２のみである。

当該配信サーバ１２は、当該利用者端末１５および前記合成サーバ１３と通信する。当該配信サーバ１２は、利用者端末１５との通信では通常のＷｅｂサーバ（ＨＴＴＰサーバ）として機能する。ここで特殊な通信プロトコルを用いてしまうと、配信サーバ１２にアクセスしてくる多数の利用者端末にその通信プロトコルを処理するための特殊なモジュールを搭載することが必要となって、通信システム１０全体の実現性が低下するからである。

これに対し配信サーバ１２と合成サーバ１３のあいだで行う通信は、純粋にシステム内部の通信であるから、必ずしもＨＴＴＰを用いる必要はない。したがってこの通信のために配信サーバ１２がＷｅｂサーバとして機能する必要もない。ＦＴＰなど、ＨＴＴＰ以外の汎用的な通信プロトコルを使用してもよく、必要ならば、汎用性のないベンダ固有の通信プロトコルを使用してもよい。

配信サーバ１２と合成サーバ１３のあいだの通信には、配信サーバ１２から合成サーバ１３へ前記ＵＲＬを伝えるために行う通信と、合成サーバ１３から配信サーバ１２へ前記音声ファイルを転送するために行う通信が含まれる。

次に、前記配信サーバ１２の内部構成例について説明する。

（Ａ−１−１）音声データ配信サーバの内部構成例
図１において、当該配信サーバ１２は、制御プログラム部２０と、ＴＣＰ／ＩＰ部２１と、ＨＴＴＰ／ＣＧＩ部２２と、音声データ蓄積部２３と、音声データデータベース（音声データＤＢ）２４とを備えている。

このうち制御プログラム部２０と、ＴＣＰ／ＩＰ部２１とは、通常、ＯＳ（オペレーティングシステム）内に実装される機能に対応し、ハードウエア的には、当該配信サーバ１２のＣＰＵ（中央処理装置）などに対応する部分である。

制御プログラム部２０は、ＯＳのカーネル（スーパーバイザ）に相当する部分で、配信サーバ１２内で最もレベルの高い制御権を有し、配信サーバ１２内で実行されるすべての処理は、最終的には、この制御プログラム部２０によって制御される。

ＴＣＰ／ＩＰ部２１は、ＴＣＰプロトコルとＩＰプロトコルを処理する部分である。ＩＰプロトコルはＯＳＩ参照モデルのネットワーク層に相当する通信プロトコルの１つである。インターネット１１上ではこのＩＰプロトコルが使用される。

ＴＣＰプロトコルはＯＳＩ参照モデルのトランスポート層に相当する通信プロトコルの１つである。ＴＣＰプロトコルは通信する装置間でコネクションを設定した上で信頼性の高い通信を行う。ＯＳＩ参照モデルのセッション層からアプリケーション層で、ＨＴＴＰプロトコルやＦＴＰプロトコルなどを使用する場合には、トランスポート層で当該ＴＣＰプロトコルを使用する。

ＨＴＴＰ／ＣＧＩ部２２は、当該ＨＴＴＰプロトコルを処理する機能とＣＧＩ機能を有する部分である。通常の実装では、このＨＴＴＰ／ＣＧＩ部２２は、アプリケーションソフト（ここでは、Ｗｅｂサーバソフト）の一部として構成され得る。少なくとも利用者端末１５との通信では、このＨＴＴＰ／ＣＧＩ部２２のなかのＨＴＴＰプロトコルを処理する部分が機能する。ＣＧＩ機能は、利用者端末１５から供給されるＨＴＴＰリクエストメッセージに応じて何らかの処理を行い、その処理の結果をＨＴＴＰレスポンスメッセージに含めて返すために機能する部分である。上述したように、ユーザＵ１の指定に応じて利用者端末１５から供給されたＵＲＬを配信サーバ１２から合成サーバ１３へ伝える際にも、当該ＣＧＩ機能がはたらく。

また、上述したように、合成サーバ１３との通信にＦＴＰを使用したり、汎用性のないベンダ固有の通信プロトコルを使用する場合、配信サーバ１２上には、当該ＨＴＴＰ／ＣＧＩ部２２のほか、これらの通信プロトコルを処理するためのモジュールが搭載される必要があることは当然である。

なお、配信サーバ１２に搭載されるＯＳ内のモジュール分けは、必ずしも図１に示した通りである必要はない。

音声データ蓄積部２３は、前記合成サーバ１３から転送されてきた音声ファイルＰＡ１〜ＰＤ１の本体を一時的に蓄積する部分である。ハードウエア的には、ハードディスクや、揮発性または不揮発性の各種メモリによって当該音声データ蓄積部２３が構成されることになる。

音声データＤＢ２４は、利用者端末１５を用いてユーザＵ１がＵＲＬを指定してきたとき、そのＵＲＬに対応する音声ファイルを特定することができるものであればどのような構成を有するものであってもよいが、一例としては、図示したような構成とすることができる。

図１において、ＵＲＬＡ１はＷｅｂページＷＡ１を指すＵＲＬであるが、配信サーバ１２内では、当該ＷｅｂページＷＡ１に対応する音声ファイルＰＡ１を指す識別子として利用する。

同様に、ＵＲＬＡ２はＷｅｂページＷＡ２を指すＵＲＬであるが、配信サーバ１２内では、当該ＷｅｂページＷＡ２に対応する音声ファイルＰＡ１を指す識別子として利用し、…、ＵＲＬＤ１はＷｅｂページＷＤ１を指すＵＲＬであるが、配信サーバ１２内では、当該ＷｅｂページＷＤ１に対応する音声ファイルＰＤ１を指す識別子として利用する。

なお、多くの場合、１つのＷｅｂページから複数の音声ファイルが得られるため、例えば、ＷｅｂページＷＡ１から得られた各音声ファイルを区別するときには、前記ＰＡ１以外に、ＰＡ１１、ＰＡ１２，ＰＡ１３、ＰＡ１４などの符号を用いる。

前記ＵＲＬがグローバルなインターネット１１上で各Ｗｅｂページを一意に指定できるのに対し、音声データＤＢ２４内に図示した内部識別情報ＩＤＡ１〜ＩＤＤ１は、配信サーバ１２内でのみ通用するローカルな識別子である。必要に応じて、この内部識別情報ＩＤＡ１〜ＩＤＤ１はローカルな識別子であるだけでなく、テンポラリな（一時的な）識別子であってもよい。具体的には、音声データ蓄積部２３の記憶領域上において各音声ファイル（例えば、ＰＡ１）が記憶されている領域のアドレス番号などを当該内部識別情報として使用することが可能である。

ここで、内部識別情報ＩＤＡ１はＵＲＬＡ１（音声ファイルＰＡ１）に対応し、…、内部識別情報ＩＤＡ２はＵＲＬＡ２（音声ファイルＰＡ２）に対応し、内部識別情報ＩＤＤ１はＵＲＬＤ１（音声ファイルＰＤ１）に対応する。

次に、前記合成サーバ１３の内部構成例について説明する。

（Ａ−１−２）音声データ合成サーバの内部構成例
図１において、当該合成サーバ１３は、制御プログラム部３０と、ＴＣＰ／ＩＰ部３１と、ＨＴＴＰ部３２と、テキスト提供部３３と、音声合成部３４と、一時記憶部３５と、音声データ蓄積依頼部３６と、シナリオデータ生成部３７と、ルールデータベース（ルールＤＢ）３８とを備えている。

このうち制御プログラム部３０は前記制御プログラム部２０に対応し、ＴＣＰ／ＩＰ部３１は前記ＴＣＰ／ＩＰ部２１に対応し、ＨＴＴＰ／ＣＧＩ部３２は前記ＨＴＴＰ／ＣＧＩ部２２に対応するので、その詳しい説明は省略する。

ただしＨＴＴＰ／ＣＧＩ部３２のＣＧＩ機能は、配信サーバ１２経由でユーザＵ１から取得した前記ＵＲＬに応じてＷｅｂサーバ１４Ａ〜１４ＤからＷｅｂページＷＡ１〜ＷＤ１を取得したり、取得したＷｅｂページ（例えば、ＷＡ１）を処理して音声ファイル（例えば、ＰＡ１）を生成し、生成した音声ファイルを配信サーバ１２へ転送する場合にもはたらく。

テキスト提供部３３とルールＤＢ３８は、合成サーバ１３内で最も特徴的な構成要素である。

このうちテキスト提供部３３は、Ｗｅｂサーバ１４Ａ〜１４Ｄから受け取ったＷｅｂページＷＡ１〜ＷＤ１を処理して、タグを含まず、音声合成の対象となる文字列だけを含むプレーンテキスト形式のファイルを生成する部分である。しかもこのプレーンテキストファイルは、１つのＷｅｂページ（例えば、ＷＡ１）内の段落や見出しなどのブロックレベル要素の内容ごと（より好ましくは、後述する記事ごと）に別ファイルとして生成されるため、上述した段落飛ばしや、聞き返し等の操作に対応することも可能となる。

その理由は、ここで生成される１つのプレーンテキストファイルが、１つの音声ファイル（例えば、ＰＡ１１）になり、利用者端末１５を操作するユーザＵ１は、音声ファイル単位で、次回に再生するファイルを自由に選ぶことが可能になるからである。

このテキスト提供部３３の内部構成は、例えば、図１４に示す通りであってよい。

（Ａ−１−３）テキスト提供部の内部構成例
図１４において、当該テキスト提供部３３は、ブロックレベル要素抽出部４０と、音声合成用整形部４１と、ルール検索部４２と、ＵＲＬ保持部４３とを備えている。

このうちルール検索部４２は、ブロックレベル要素抽出部４０または音声合成用整形部４１からの検索要求に応じて、前記ルールＤＢ３８を検索し、その検索結果として得られたルールの本体を検索要求の供給元であるブロックレベル要素抽出部４０または音声合成用整形部４１に返す部分である。

この検索では、検索キーとして、前記ＵＲＬが使用される。このため、配信サーバ１２経由で利用者端末１５から届いたＵＲＬは、少なくともこのテキスト提供部３３における処理が終了するまで、ＵＲＬ保持部４３に保持しておく必要がある。

ＵＲＬ保持部４３は、取得した各ＷｅｂページＷＡ１〜ＷＤ１とそのＵＲＬの対応関係が分かる形式で、ＵＲＬの記憶を維持する部分である。例えば、ＷｅｂページＷＡ１をブロックレベル要素抽出部４０や音声合成用整形部４１で処理するときには、当該ＷｅｂページＷＡ１に対応するＵＲＬである前記ＵＲＬＡ１を検索キーとして、ルールＤＢ３８を検索することになる。

ルールＤＢ３８内に、各ＵＲＬと直接、対応づける形式でルールＲＬＡ１〜ＲＬＤ１の本体を登録しておくようにしてもよいが、ルールＲＬＡ１〜ＲＬＤ１の本体は一種のプログラムコード（プログラムファイル）であるから、前記音声データＤＢ２４の構成と同様に、所定の記憶装置（図示せず）上でこれら各プログラムファイルが記憶されている領域のアドレス番号などを当該ＲＬＡ１〜ＲＬＤ１の替わりにルールＤＢ３８に登録する構成としてもよい。

ルールＲＬＡ１〜ＲＬＤ１は、Ｗｅｂページ（例えば、ＷＡ１）からどのようにテキストデータを抽出し、どのような単位に分割するかの規則を示す情報である。

Ｗｅｂページの構造は多様であるため、基本的には、Ｗｅｂページごとにルールを決めておくことになる。

例えば、図２に示す構造を持つＷｅｂページに対しては、図３のフローチャートに示すルールを適用し、図４に示す構造を持つＷｅｂページに対しては、図５のフローチャートを示すルールを適用する。

なお、個別にルールを設定していないＷｅｂページが、ユーザＵ１から指定され、当該合成サーバ１３に取得される場合に備え、デフォルトのルールを登録しておくようするとよい。このデフォルトルールは、ルール検索部４２がＵＲＬを検索キーとしてルールＤＢ３８を検索した際、有効な検索結果が得られなかった場合に適用されるルールである。

前記ブロックレベル要素抽出部４０は、検索結果として得られたルール（例えば、ＲＬＡ１）に基づいて処理することにより、各Ｗｅｂページから１または複数のブロックレベル要素を抽出する部分である。通常は、１つのＷｅｂページにつき複数のブロックレベル要素が抽出される。多くの場合、１つのＷｅｂページには複数のブロックレベル要素が含まれているからである。

ここで、ブロックレベル要素とは、＜ｈ１＞タグなどによって範囲を指定される見出しや、＜ｐ＞タグなどによって範囲を指定される段落などを指す。一例として、図２のＷｅｂページの場合、３つの見出しと、７つの段落が含まれている。

また、Ｗｅｂページ作成者が自らの利便のために入れているコメント文（図１５（Ａ）参照）や、Ｗｅｂページ内のオブジェクト情報（図１５（Ｂ）参照）もここでは、ブロックレベル要素とする。

図１５（Ａ）は、コメント文をブロックレベル要素として使う場合の例である。

二つのコメント文の間のテキストデータが中間データＭＥ１となる。

この場合、ＭＥ１に＜ｈ１＞、＜ｐ＞等のブロックレベル要素が含まれる可能性がある。

これらのブロックレベル要素は、後述する整形処理（テキスト整形）において、インライン要素として削除する。

図１５（Ｂ）は、Ｗｅｂページ内のオブジェクトをブロックレベル要素として使う場合の例である。

＜ｉｍｇ＞タグ（タイトル画像）と＜ｈｒ＞タグ（水平線）の間のテキストデータが中間データＭＥ１となる。

＜ｈ１＞タグや＜ｐ＞タグは、ブロックレベル要素抽出部４０内で、処理対象のＷｅｂページ（ＨＴＭＬソース）上からブロックレベル要素を探索するために活用できるが、この探索が終了したあとは不要になるので除去することができる。

したがって、ブロックレベル要素抽出部４０から音声合成用整形部４１へ供給されるデータは、＜ｈ１＞タグや＜ｐ＞タグを含まないデータ（中間データ）ＭＥ１であってよい。また、基本的に、１つのブロックレベル要素を１つの音声ファイル（例えば、ＰＡ１１）に収容するが、必要ならば、記事ごとに音声ファイルに収容する場合のように、複数のブロックレベル要素を１つの音声ファイル（例えば、ＰＡ１１）に収容するようにしてもよい。より多くのブロックレベル要素を１つの音声ファイルに収容すれば、ファイルの数が減少し、ファイル管理のための負荷が小さくなるが、上述した段落飛ばしや、聞き返しを、より細かいレベルで行うには、音声ファイルの数が増加しても、より少数のブロックレベル要素を１つの音声ファイル（例えば、ＰＡ１１）に収容することが望ましい。

また、記事単位に音声ファイルに収容するなど、ユーザＵ１にとっての意味的な区切りに忠実な単位に分割した上で、各分割結果を１つの音声ファイルに収容することは、より有効である。ここで、１つの記事は、１つの見出しと、その見出しにつづく１つ以上の段落から構成されている。

音声合成用整形部４１は、前記ブロックレベル要素抽出部４０から受け取った中間データＭＥ１に対し、音声合成のための整形処理を施す部分で、この整形処理の結果として、中間データＭＥ２を出力する。当該中間データＭＥ２は、前記プレーンテキストファイルにあたる。

この整形処理の内容には様々なものがあり得るが、例えば、中間データＭＥ１に含まれる可能性のあるインライン要素のタグ（インラインタグ）を除去したり、中間データＭＥ１が見出しである場合などに欠けている可能性の高い読点「。」を付加したり、音声合成部３４が音声的な表現力を高めるために使用可能な各種の制御記号を付加したりするものであってよい。

前記インラインタグとは、ここでは、抽出した１つのブロック内部において１または複数の文字などを指定したりするタグのことである。主として、内容情報であるテキストに対し、インライン要素として用いられる。

具体的には、例えば、図２において、文字を強調する＜ｓｔｒｏｎｇ＞タグや改行を示す＜ｂｒ＞タグ、図６（Ａ）においてリンク先を示す＜ａ＞タグなどがインラインタグにあたる。

インラインタグもＷｅｂページの内容と同様な文字列で記述されるため、前記音声合成部３４の具体的な仕様によっては、タグの記述（要素名、属性名、属性値などの文字列や数字列）まで音声合成され、不要な情報が音声出力されたり、合成音に不要な区切りが入ったりする可能性がある。その場合、音声出力は、ユーザＵ１にとって聞きづらいものとなるため、この整形処理で除去するものである。

この点、前記＜ｈ１＞タグや＜ｐ＞タグなども同様であるから、もし前記ブロックレベル要素抽出部４０で除去しない場合には、当該音声合成用整形部４１で、＜ｈ１＞タグや＜ｐ＞タグなどを除去するようにしてもよい。

このようなテキストのインラインタグでなくとも、図６（Ａ）のように、ブロック内のオブジェクトを除去するようにしてもよい。この例は＜ｉｍｇ＞による画像を除去しているが、＜ｈｒ＞（水平線）等を除去してもよい。
また、整形処理で、読点を付加する理由は、音声合成部３４における処理で、当該読点に基づいて適切なポーズを挿入し、より自然な合成音声を得るためである。

さらに、前記整形処理で付加する制御記号は、例えば、ポーズ、声質（早さ、高さ、強さ、抑揚、話者等）、効果音などを音声合成部３４に指示するものである。

このようなテキスト提供部３３から中間データＭＥ２の供給を受ける前記音声合成部３４は、ＴＴＳ（Text-to-speech （Synthesis））方式により、テキストに基づいて音声データを合成する部分で、合成結果として、前記音声ファイル（例えば、ＰＡ１１など）を出力する。ここで、テキストとは、前記中間データＭＥ２すなわちプレーンテキストファイルを指す。

なお、当該音声合成部３４が合成する音声データ（音声ファイル）のデータ形式は、利用者端末１５の補助機能ＡＤ１により再生可能なものであればどのようなものであってもよい。例えば、ＰＣＭや、ＭＰ３などのデータ形式が使用可能である。

前記一時記憶部３５は、音声合成部３４から出力される各音声ファイル（例えば、ＰＡ１１など）を一時的に記憶する部分である。

一時記憶部３５に記憶されている音声ファイルは、音声データ蓄積依頼部３６により、ＴＣＰ／ＩＰ部３１を介して配信サーバ１２へ転送され、前記音声データ蓄積部２３に蓄積される。

シナリオデータ生成部３７は、複数の前記音声ファイル（例えば、ＰＡ１１，ＰＡ１２など）を利用者端末１５上で再生する際の順番（同期関係）を記述したシナリオデータＳＹ１を生成する部分である。通常、１つのＷｅｂページ（例えば、ＷＡ１）から得られる複数の音声ファイル（ここでは、ＰＡ１１，ＰＡ１２など）の再生順序（同期関係）は、当該Ｗｅｂページ上における記載順序に基づいて決めることができる。

このような再生順序は、１つのＷｅｂページ内でのみ決め、別なＷｅｂページ間では決めないようにしてもよいが、ハイパーリンクなどによって、あるＷｅｂページ（例えば、ＨＴＳ２（図４参照））の次に他のＷｅｂページ（例えば、ＨＴＳ３（図４参照））が閲覧される関係が明確である場合などには、そのような関係に基づいて複数のＷｅｂページ間にまたがる再生順序を決めることも可能である。

シナリオデータＳＹ１を記述する形式は、利用者端末１５で処理可能であれば、どのような形式を用いてもかまわないが、一例として、Ｗ３Ｃ勧告のＳＭＩＬ（ＳｙｎｃｈｒｏｎｉｚｅｄＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎＬａｎｇｕａｇｅ）形式を用い、ＳＭＩＬファイルとして当該シナリオデータＳＹ１を生成するようにしてもよい。

また、生成された音声ファイルが１つだった場合には、シナリオデータＳＹ１を、＜ｂｇｓｏｕｎｄ＞タグ等を用いたＨＴＭＬ形式で記述してもよい。

当該シナリオデータＳＹ１は、ＨＴＴＰ／ＣＧＩ部３２を介して当該合成サーバ１３から直接、利用者端末１５へ送信することもできるが、配信サーバ１２経由で送信することもできる。合成サーバ１３が前記ＵＲＬを配信サーバ１２経由で受け取った場合なら、シナリオデータＳＹ１の返送も、配信サーバ１２経由で行うようにするとよい。

前記＜ｂｇｓｏｕｎｄ＞タグ等を用いたＨＴＭＬ形式の場合などを除き、利用者端末１５が受信したあと、利用者端末１５上でこのシナリオデータＳＹ１を解釈し処理するのは、主として、前記補助機能ＡＤ１である。

前記利用者端末１５の内部構成例を図７に示す。図７では、利用者端末１５が据え置き型のパーソナルコンピュータである例を示す。

（Ａ−１−４）利用者端末の内部構成例
図７において、当該利用者端末１５は、制御プログラム部７０と、ＴＣＰ／ＩＰ部７１と、Ｗｅｂブラウザ部７２と、音声データ再生部７３と、Ｉ／Ｏ制御部７４のほか、ディスプレイ７５と、スピーカ７６と、マウス７７と、キーボード７８とを備えている。

このうち制御プログラム部７０は前記制御プログラム部２０に対応し、ＴＣＰ／ＩＰ部７１は前記ＴＣＰ／ＩＰ部２１に対応するので、その詳しい説明は省略する。

Ｗｅｂブラウザ部７２は、基本的に前記ＷｅｂブラウザＢＲ１に対応するが、補助機能ＡＤ１が前記プラグインソフトである場合には、補助機能ＡＤ１が持つ機能の少なくとも一部は、当該Ｗｅｂブラウザ部７２に含まれることになる。ＷｅｂブラウザＢＲ１も補助機能ＡＤ１も、当該利用者端末１５にインストールされたアプリケーションプログラムであるから、普段は、利用者端末１５のハードディスク（図示せず）に保存されており、起動時には、メモリ（図示せず）に読み込まれる。プラグインソフトの場合、通常は、Ｗｅｂブラウザが起動されると同時に起動される。

音声データ再生部７３は、前記音声ファイル（例えば、ＰＡ１１〜ＰＡ１４）の再生を行う部分で、もっぱら前記補助機能ＡＤ１に対応する。

Ｉ／Ｏ制御部７４は、パーソナルコンピュータである当該利用者端末１５への入出力を制御する部分である。周辺装置であるポインティングデバイス（ここでは、マウス７７）やキーボード７８と前記制御プログラム部７０とのあいだに、当該Ｉ／Ｏ制御部７４が介在する。

ディスプレイ７５は、例えば、液晶表示装置などによって構成され、Ｗｅｂブラウザ部７２が表示する画面を表示出力し、ユーザＵ１が閲覧することを可能にする。

スピーカ７６は、前記音声データ再生部７３の機能に応じて、前記音声ファイル（例えば、ＰＡ１１〜ＰＡ１４）に対応する音声出力を行うための周辺装置である。当該スピーカ７６は、ヘッドホンなどに置換可能である。

なお、当該利用者端末１５が、パーソナルコンピュータではなく前記携帯電話機である場合には、ＴＣＰ／ＩＰ部７１は他の通信プロトコルに対応したモジュールに置換され得る。各携帯電話ネットワーク内でどのような通信プロトコルを用いるかは、当該携帯電話ネットワークを構築し運営する携帯電話事業者の自由であるが、携帯電話ネットワーク内ではＩＰプロトコルが使用されないことも少なくないからである。

また、携帯電話機の場合、ディスプレイ７５やスピーカ７６は周辺装置として付加しなくても最初から携帯電話機に搭載されているし、マウスやキーボードは存在せず、いくつかの操作ボタン（図示せず）が配列されているのみである。携帯電話機では、当該ディスプレイ７５，スピーカ７６，操作ボタンなどが、ユーザＵ１の手のひらに収まる程度のコンパクトなボディに搭載されている。

なお、携帯電話機に関しては、Ｗｅｂページを記述する言語もＨＴＭＬ以外の言語（例えば、ＨＤＭＬなど）が使用され、携帯電話機にはその言語に対応したＷｅｂブラウザが搭載されることが多いが、これらの言語も、タグを利用したマークアップ言語である点で、ＨＴＭＬと同じである。

以下、上記のような構成を有する本実施形態の動作について、図３，図５，図９のフローチャートを参照しながら説明する。

図３は前記ルールの一例を示すフローチャートで、Ｓ１０〜Ｓ２１の各ステップから構成されている。また、図５は前記ルールの一例を示すフローチャートで、Ｓ３０〜Ｓ４３の各ステップから構成されている。さらに、図９は、合成サーバ１３の動作を示すフローチャートであり、Ｓ５０〜Ｓ５８の各ステップから構成されている。図９のステップＳ５３の詳細を示したものが、図３または図５のフローチャートであるとみることができる。

この図９のフローチャートは、前記リアルタイム型の提供方法に対応するものとなっている。ここでは、主としてリアルタイム型に基づいて動作を説明する。

（Ａ−２）第１の実施形態の動作
リアルタイム型の場合、まず最初に、ユーザＵ１が例えば図８（Ａ）または（Ｂ）のＷｅｂページ（ＵＲＬ送信画面）に基づいて、音声出力を希望するＷｅｂページのＵＲＬを伝える必要がある。このＵＲＬを伝える相手は、（配信サーバ１２経由でよいが、）最終的には、前記合成サーバ１３である。

図８（Ａ）に示すＵＲＬ送信画面の場合、ユーザＵ１は利用者端末１５の前記キーボード７８などを操作してフィールドＦ１に所望のＵＲＬを入力し、「送信」ボタンＢＴ１を押すことによって、フィールドＦ１に入力したＵＲＬを伝えることができる。フィールドＦ１内でテキスト編集を行う煩わしさはあるが、このＵＲＬ送信画面では、世界中に存在する任意のＷｅｂサーバに登録されている任意のＷｅｂページを指定することが可能である。

図８（Ｂ）に示すＵＲＬ送信画面の場合には、ユーザＵ１はハイパーリンクＬＫ１〜ＬＫ３のいずれかを選択し、選択したハイパーリンク（例えば、ＬＫ２）をマウス７７などで操作（クリック）するだけで、極めて簡単に、ＵＲＬを伝えることが可能である。この場合、予めＵＲＬ送信画面に用意されているハイパーリンクＬＫ１〜ＬＫ３のなかからしかＵＲＬを選択できないため、伝えることできるＵＲＬが限定されているが、操作が簡単な点が有利である。

図８（Ａ）および（Ｂ）のＵＲＬ送信画面の送信元は、配信サーバ１２であってよいが、必要に応じて、合成サーバ１３であってもよく、Ｗｅｂサーバ１４Ａ〜１４Ｄのいずれかであってもよい。また、図１に図示していないいずれかのＷｅｂサーバであってもよい。

また、前記フィールドＦ１に入力したＵＲＬ、または、前記ハイパーリンクＬＫ１〜ＬＫ３のいずれかに対応するＵＲＬの直接の宛先は、各ＵＲＬ送信画面のＨＴＭＬソースの記述内容（例えば、＜ｆｏｒｍ＞タグのａｃｔｉｏｎ属性の属性値の内容など）に応じて決まるものである。上述したように、ＵＲＬを、配信サーバ１２経由で合成サーバ１３に伝える場合には、直接の宛先は、配信サーバ１２になる。

図９において、ステップＳ５０では、合成サーバ１３がＵＲＬをＨＴＴＰリクエストメッセージの一部として利用者端末１５から受信しているが、ここでは上述したように、直接、当該利用者端末１５から受信するのではなく、配信サーバ１２経由で受信するものとする。ＨＴＴＰリクエストメッセージを直接受信するのが当該配信サーバ１２であれば、そのＨＴＴＰリクエストメッセージに対する応答であるＨＴＴＰレスポンスメッセージを送信するのも、配信サーバ１２にしておくことが望ましい。そのようにしないと、利用者端末１５と配信サーバ１２のあいだにファイアウオールなどが介在する場合、ＨＴＴＰレスポンスメッセージが当該ファイアウオールで遮断されて、利用者端末１５まで届かない可能性が高いからである。

なお、前記ＵＲＬ送信画面では、ユーザＵ１が同時に複数のＵＲＬを指定できるようにしてもよいが、図示した例では、同時には１つのＵＲＬしか指定できないので、ここでも、指定されたＵＲＬは１つであるものとして説明する。

このＵＲＬが、例えば、前記ＵＲＬＡ１であるものとすると、合成サーバ１３は前記Ｗｅｂサーバ１４ＡからＷｅｂページＷＡ１を取得することになる（Ｓ５１）。

また、合成サーバ１３内の前記テキスト提供部３３は、当該ＵＲＬＡ１を検索キーとしてルールＤＢ３８を検索し、当該ＷｅｂページＷＡ１に対応したルールを特定する。そして、特定したルールに基づいて処理することで当該ＷｅｂページＷＡ１のＨＴＭＬソースの内容からテキストデータを抽出し、分割する（Ｓ５３）。

このステップＳ５３の処理の詳細については後述するが、当該ステップＳ５３の処理により、１つのＷｅｂページＷＡ１のＨＴＭＬソースから、１または複数の前記中間データ（プレーンテキストファイル）ＭＥ２が得られる。前記ブロックレベル要素ごとに中間データＭＥ２が得ることもできるが、ここでは、記事毎に中間データＭＥ２を得るものとする。

図９のフローチャートでは、中間データＭＥ２が得られるたびに音声合成部３４で音声ファイルに変換し、その音声ファイルを、一時記憶部３５，音声データ蓄積依頼部３６を介して、前記配信サーバ１２の音声データ蓄積部２３に蓄積する処理を繰り返している（Ｓ５４，Ｓ５５，Ｓ５６）が、１つのＷｅｂページＷＡ１から得られた複数の音声ファイルをまとめて一時記憶部３５，音声データ蓄積依頼部３６で処理し、前記配信サーバ１２の音声データ蓄積部２３に蓄積するようにしてもよいことは当然である。

１つのＷｅｂページＷＡ１に対応するすべての音声ファイル（ここでは、ＰＡ１１〜ＰＡ１４とする）が得られたとき、ステップＳ５６はｙｅｓ側に分岐して、シナリオデータ生成部３７が、これらの音声ファイルＰＡ１１〜ＰＡ１４の再生順序を示す前記シナリオデータＳＹ１を生成する（Ｓ５６）。

このシナリオデータＳＹ１は、直接、合成サーバ１１から利用者端末１５に送信してもよいが、配信サーバ１２経由で送信することもできる（Ｓ５８）。

前記リアルタイム型に対応する動作の場合、このステップＳ５８におけるシナリオデータＳＹ１は、前記ステップＳ５０のＨＴＴＰリクエストメッセージに対する応答（ＨＴＴＰレスポンスメッセージ）の一部として送信されるものである。

これに対し、前記バックグラウンド型では、ステップＳ５０自体を省略できるか、ステップＳ５０のＨＴＴＰリクエストメッセージに対する応答としてのステップＳ５８のＨＴＴＰレスポンスメッセージは送信しない動作となる。

ステップＳ５０自体を省略した場合、予め決めた範囲のＵＲＬに基づいて合成サーバ１３がＷｅｂページ（例えば、ＷＡ１など）を取得する。また、ステップＳ５０を実行する場合には、ステップＳ５０のＨＴＴＰリクエストメッセージに対する応答としてのＨＴＴＰレスポンスメッセージとしては、前記ステップＳ５８のＨＴＴＰレスポンスメッセージに替えて、例えば、次のような文字列ＳＲ１を含むＨＴＭＬファイルを含めるとよい。

「あなたのリクエストは受け付けました。本サービスの規則にしたがって適正に処理し、できるだけ速く、あなたのリクエストに対応した音声ファイルを用意しておきます。ＵＲＬＸにアクセスして下さい。」 …（ＳＲ１）
ここで、ＵＲＬＸは、前記ＵＲＬＡ１とは別個のＵＲＬである。ＵＲＬＡ１にＨＴＴＰリクエストメッセージを送信してしまうと、その応答であるＨＴＴＰレスポンスメッセージとして、Ｗｅｂサーバ１４Ａから単なるＷｅｂページＷＡ１が利用者端末１５に返送されてしまうから、このように別個のＵＲＬを用意する必要がある。

あるいは、このようなＵＲＬＸを用いる替わりに、配信サーバ１２が提供するＷｅｂページの構成に基づいて、ユーザＵ１が目的の音声ファイル（例えば、ＰＡ１１など）やシナリオデータ（例えば、ＳＹ１）に辿り着けるようにしておいてもよい。

リアルタイム型、バックグラウンド型いずれであっても、シナリオデータＳＹ１が利用者端末１５に届けられると、例えば、図１０に示す音声再生画面が、前記ディスプレイ７５に画面表示される。このとき、ユーザＵ１がマウス７７などで、ボタンＢＴ１１〜ＢＴ１４のいずれかを操作することにより、ユーザＵ１が望む順番で、音声ファイルＰＡ１１〜ＰＡ１４を再生することができる。

例えば、「再生」ボタンＢＴ１３を操作したときに音声ファイルＰＡ１１から順番に再生出力を開始する。この状態で放置すると、再生順序にしたがってＰＡ１１，ＰＡ１２，ＰＡ１３，ＰＡ１４の順番で再生出力が継続されることになるが、「早送り」ボタンＢＴ１４を操作すると、そのたびにファイル単位で、次の再生順序の音声ファイル（例えば、ＰＡ１２）の再生出力を行い、また、「巻き戻し」ボタンＢＴ１１を操作すると、そのたびに再生順序を遡って、すでに再生の終わった音声ファイル（例えば、ＰＡ１１）を再生出力し、「停止」ボタンＢＴ１２を押すと再生出力を停止する。

したがってユーザＵ１は、この「早送り」ボタンＢＴ１４の操作に応じて前記段落飛ばしを行うことができ、「巻き戻し」ボタンＢＴ１１の操作に応じて前記聞き返しを行うことができる。これにより、興味のない内容は聞かずに次の内容を聞いたり、すでに音声出力された内容をもう１度、聞き直したりすることが可能になる。段落飛ばしを行う以上、ある音声ファイル（例えば、ＰＡ１２）が再生の途中であっても「早送り」ボタンＢＴ１４の操作を検知したときには、直ちにその再生を中止して、次の音声ファイル（ここでは、ＰＡ１３）の再生出力を開始できることは当然である。

なお、上述したように、これら一連の音声ファイルＰＡ１１〜ＰＡ１４をまとめて取得する場合ならば、このような段落飛ばしや聞き返しは、すでに受信している音声ファイルの再生の順番を制御するだけであり、純粋に利用者端末１５内部の処理になるため、ＷｅｂブラウザＢＲ１によるＨＴＴＰリクエストメッセージの送信は必要ないから、前記補助機能ＡＤ１がヘルパーアプリケーションであっても特に問題はない。

ただし、一連の音声ファイルＰＡ１１〜ＰＡ１４のうち、同時に利用者端末１５に受信するのは１つだけとし、ユーザＵ１が前記ボタン（例えば、ＢＴ１４やＢＴ１１）を操作するたびに、必要な音声ファイル（例えば、ＰＡ１１，ＰＡ１３など）を取得するためのＨＴＴＰリクエストメッセージを送信する場合ならば、ＷｅｂブラウザＢＲ１の機能を頻繁に利用する必要があるため、ＷｅｂブラウザＢＲ１利用時に画面の切り替えなどが不要なプラグインソフトを、前記補助機能ＡＤ１とするほうが、はるかに操作性が向上する。

なお、ＷｅｂブラウザＢＲ１が利用者端末１５内にキャッシュ領域を有する場合、音声ファイルＰＡ１１〜ＰＡ１４をキャッシュ領域に蓄積しておけば、１度、ＷｅｂブラウザＢＲ１が取得した音声ファイルは、配信サーバ１２にアクセスすることなく当該キャッシュ領域から取得することが可能（例えば、前記聞き返しを行う場合に対応）であるが、この場合でも、本質的な相違はない。当該キャッシュ領域にアクセスできるのは、通常、ＷｅｂブラウザＢＲ１だけだからである。

上述したステップＳ５３の詳細に相当する動作を、図３のフローチャートを用いて説明する。図３のフローチャートは、前記合成サーバ１３が前記ステップＳ５１で取得したＷｅｂページＷＡ１のＨＴＭＬソースが、例えば、図２に示すＨＴＳ１のようなものである場合に適用されるルールを示すものである。

分割単位は、ここでは、記事とする。１つの記事は、１つの見出しと、それにつづく１または複数の段落から構成されているから、例えば、図２の場合、見出しＨ１１とそれにつづく段落Ｐ１１およびＰ１２が１つの記事である。同様に、見出しＨ１２とそれにつづく段落Ｐ１３は、１つの記事である。さらに、見出しＨ１３とそれにつづく段落Ｐ１４，Ｐ１５，Ｐ１６は、１つの記事である。したがって、図２のＷｅｂページには、３つの記事が含まれていることになる。

図２では、ｂｏｄｙの範囲（＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞で囲まれた範囲）に、＜ｈ１＞と＜／ｈ１＞で囲まれた見出しが３つ存在し、各見出しのあとには、１または複数の段落がつづいている。ＨＴＭＬの文法上、段落は、＜ｐ＞と＜／ｐ＞で囲まれた範囲であるから、図２のＨＴＭＬソースＨＴＳ１の場合、段落の数は全部で７つである。

すなわち図２のＨＴＭＬソースＨＴＳ１において、見出しはＨ１１〜Ｈ１３の３つであり、段落はＰ１１〜Ｐ１７の７つである。

このような構成のＷｅｂページを処理する場合に適用されるルールでは、図３に示すように、まずポインタ変数ｎに０を代入して、対象領域を決める（Ｓ１１）。この対象領域は、前記ｂｏｄｙの範囲とする。ｂｏｄｙの範囲は、前記＜ｂｏｄｙ＞と＜／ｂｏｄｙ＞をもとに特定することができる。また、前記ポインタ変数ｎの値は、分割単位である各記事に、内部で使用する識別番号を与えるために用いるものである。

次に、ポインタ変数ｎにｎ＋１を代入して、ｂｏｄｙの範囲内の先頭にある見出しを抽出する（Ｓ１２）。ここでは、図２のＨＴＭＬソースＨＴＳ１を、図２上で上に位置する行から順番に処理していくので、先頭にある見出しとは、見出しＨ１１〜Ｈ１３のなかで最も上に位置する見出しＨ１１のことである。また、このときポインタ変数ｎの値は、１（＝０＋１）であるので、この見出しＨ１１の記事には、識別番号として１が付与されることになる。

このあと、見出しの内容であるテキストに対し、前記音声合成用整形部４１が上述した整形処理を施し、整形処理結果を第ｎブロックデータ（ここでは、ｎの値が１であるため、第１ブロックデータ）として書き出す（Ｓ１３、Ｓ１４）。ここでテキストとは、図２上で見出しＨ１１において＜ｈ１＞と＜／ｈ１＞に囲まれている「ＸＸＸＸＸＸＸＸＸ」である。もちろん実際には、この部分に、見出しとして適切な文字列が記述されることは当然である。また、ブロックデータとは、ここでは、１つの記事のことを指している。

つづいてｂｏｄｙの範囲内の先頭にある段落を抽出し（Ｓ１５）、その段落のテキストに対し前記音声合成用整形部４１が整形処理を施し（Ｓ１６）、整形処理の結果を前記ステップＳ１４で書き出した第ｎブロックデータ（ここでは、第１ブロックデータ）に追記する（Ｓ１７）。当該ステップＳ１５は前記ステップＳ１２に対応し、当該ステップＳ１６は前記ステップＳ１３に対応し、当該ステップＳ１７は前記ステップＳ１４に対応する。

当該ステップＳ１７につづくステップＳ１８は、当該記事（すなわち、第１ブロックデータ）内で後続の段落がある限り、ｙｅｓ側に分岐し、そのたびに前記ステップＳ１５〜Ｓ１７の処理が繰り返される。

図２に示す見出しＨ１１の記事の場合、段落はＰ１１とＰ１２の２つであるため、ステップＳ１８のｙｅｓ側への分岐は１回だけ発生する。

当該記事内で後続の段落がなくなると、ステップＳ１８はｎｏ側へ分岐し、第ｎブロックデータ（ここでは、第１ブロックデータ）の内容が確定する（Ｓ１９）。この内容が確定した第ｎブロックデータは、前記中間データＭＥ２として音声合成部３４へ供給されることになる。

ステップＳ１９につづくステップＳ２０では、前記ｂｏｄｙの範囲内で先頭から順番に調べることで、前記見出しＨ１１以外の新たな見出しを探索し、探索できなければｎｏ側に分岐してこの図２のＨＴＭＬソースＨＴＳ１に対する処理を終了するが（Ｓ２１）、探索できればｙｅｓ側の分岐して、前記ステップＳ１２〜Ｓ２０の処理を繰り返す。

図２のＨＴＭＬソースＨＴＳ１の場合、見出しの数はＨ１１〜Ｈ１３の３つであるため、その処理では、ステップＳ２０におけるｙｅｓ側への分岐が２回発生することになる。

一方、上述したステップＳ５３の詳細に相当するもう１つの動作は、図５のフローチャートに示す通りである。図５のフローチャートは、前記合成サーバ１３が前記ステップＳ５１で取得したＷｅｂページＷＡ１のＨＴＭＬソースが、例えば、図４に示すＨＴＳ２のようなものである場合に適用されるルールを示すものである。ここでも、分割単位は、前記記事である。

図５において、当該ＨＴＭＬソースＨＴＳ２からリンク部を抽出し、ＨＴＭＬソースＨＴＳ２中のリンク部の総数を、リンク総数変数Ｎに代入する（Ｓ３１）。図４のＨＴＭＬソースＨＴＳ２の場合、リンク部はＡ２１〜Ａ２３の３つであるから、リンク総数変数Ｎには、３が代入されることになる。

次にリンク部指定変数ｎに初期値として１を代入した上で、各リンク部Ａ２１〜Ａ２３に記載されたｈｒｅｆ属性の属性値であるＵＲＬによって指定される各ＨＴＭＬソースＨＴＳ３〜ＨＴＳ５につき、ステップＳ３２以降の処理を開始する。

当該ステップＳ３２では、ＨＴＭＬソースＨＴＳ２上で上からｎ番目（ここでは、１番目）のリンク部（ここでは、Ａ２１）から、前記ｈｒｅｆ属性の属性値として記述されているＵＲＬを取得し、つづくステップＳ３３で、そのＵＲＬを用いてＨＴＴＰリクエストメッセージを送信し、これに応えて該当するＷｅｂサーバ（例えば、１４Ｂ）が返信するＨＴＴＰレスポンスメッセージからＨＴＭＬソース（ここでは、ＨＴＳ３）を取得する（Ｓ３３）。

取得した当該ＨＴＭＬソースＨＴＳ３に対して行うステップＳ３４〜Ｓ４１の各処理は、すでに説明した図３の各ステップの処理と同様である。

すなわち、ステップＳ３４は前記ステップＳ１２に対応し、ステップＳ３５は前記ステップＳ１３に対応し、ステップＳ３６は前記ステップＳ１４に対応し、ステップＳ３７は前記ステップＳ１５に対応し、ステップＳ３８は前記ステップＳ１６に対応し、ステップＳ３９は前記ステップＳ１７に対応し、ステップＳ４０は前記ステップＳ１８に対応し、ステップＳ４１は前記ステップＳ１９に対応するので、その詳しい説明は省略する。

ステップＳ４１につづくステップＳ４２では、リンク部指定変数ｎ（今回は、１）の値が前記リンク総数変数Ｎ（ここでは、３）の値と一致するまでｎｏ側への分岐が繰り返され、そのたびに、リンク部指定変数ｎの値がインクリメントされて前記ステップＳ３２〜Ｓ４１の処理が繰り返される。

図４のＨＴＭＬソースＨＴＳ２の場合、リンク部の数は３つであるため、ステップＳ４２のｎｏ側への分岐は２回発生する。

リンク部指定変数ｎの値がリンク総数変数Ｎに一致すると、当該ステップＳ４２はｙｅｓ側に分岐して、当該ＨＴＭＬソースＨＴＳ２に対する処理を終了する。

ここでは、ＨＴＭＬソースの内容に対応した２つのルール（図３，図５）について説明したが、これ以外のルールを用いることができることは当然である。図３，図５以外のルールでは、ＨＴＭＬソースの内容など、必要に応じて、次のＳＸ１〜ＳＸ４の各処理をルールのなかに含めるようにしてもよい。

（ＳＸ１）…ブロックレベル要素の内容の中で、インラインタグ以外のものを削除して抽出する。

（ＳＸ２）…連続する複数の＜ｐ＞＜／ｐ＞のうち、Ｎ番目までを対象テキストとした上で、各種テキストタグを取り除き、対象テキストを１ブロック生成する。

（ＳＸ３）…コメントアウトされているテキスト（コメント文）の中から、上述した特許文献１で使用する音声合成タグに囲まれた部分を抽出する。

（ＳＸ４）…単に、当該音声合成タグで囲まれた部分を抽出する。

ここで、処理ＳＸ１の実行の様子を図６（Ａ）に示し、処理ＳＸ２の実行の様子を図６（Ｂ）に示し、処理ＳＸ３の実行の様子を図６（Ｃ）に示し、処理ＳＸ４の実行の様子を図６（Ｄ）に示す。なお、特許文献１では音声合成タグとして、＜ＶＳ＞タグを使用し、図６（Ｃ）や（Ｄ）では、ｔｔｓまたは＜ｔｔｓ＞タグを使用しているが、両者に本質的な差はない。

前記特許文献１にも記載されているように、音声合成タグのような、ＤＴＤで定義されていない特殊なタグは、＜！−−と−−＞で囲まれたコメント文のなかに記載するようにしないと、タグの解釈主体であるプロキシサーバなど（Ｗｅｂブラウザも含む）で正しく処理できない可能性があるため、通常、音声合成タグで囲まれたテキストは、前記処理ＳＸ３のように、コメント文のなかから抽出することになるが、もしも、ＨＴＭＬソースがそのような構成となっておらず、コメント文以外の箇所に音声合成タグを使っている場合には、前記処理ＳＸ４を適用する。

このほかにも、処理ＳＸ１〜ＳＸ４を１つのルールのなかで組み合わせて用いること等も可能である。

なお、上述したデフォルトルールも、これらの処理ＳＸ１〜ＳＸ４を利用して構成したり、タグ（ＤＴＤで定義されているものも、されていないものも含む）やキーワードに合わせて構成することができる。

（Ａ−３）第１の実施形態の効果
以上のように、本実施形態によれば、前記音声合成タグのような特殊なタグを付加しておく必要がなく、広く、通常のＷｅｂページ（例えば、ＨＴＳ１）に対して適用することができるため、実現性が高い。

また本実施形態では、利用者端末（１５）側における再生出力の際、上述した段落飛ばしや、聞き返しなどを、ユーザ（Ｕ１）の希望に合わせて行うことが可能であるため、利便性や柔軟性が高い。

（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。

第１の実施形態では利用者端末１５側で再生出力されるのは、音声のみであったが、本実施形態では、音声に対応したテキストも、音声に同期して表示出力させることができる点が相違する。

（Ｂ−１）第２の実施形態の構成および動作
本実施形態は第１の実施形態に比べ、音声データ合成サーバ（すなわち、合成サーバ）の内部構成が相違するだけである。

本実施形態の合成サーバ５３の内部構成例を図１１に示す。

図１１において、図１と同じ符号を付与した構成要素３０，３１，３２，３４，３５，３６，３７，３８，ＵＲＬＡ１〜ＵＲＬＤ１，ＲＬＡ１〜ＲＬＤ１、ＷＡ１〜ＷＤ１，ＭＥ２，ＰＡ１〜ＰＤ１，ＳＹ１の機能は基本的に第１の実施形態と同じであるので、その詳しい説明は省略する。

ただし本実施形態で使用するルールでは、前記中間データＭＥ２を生成する際、その中間データＭＥ２と同時に、利用者端末１５上で表示するためのテキストデータ（音声付随テキストデータ）ＳＴＡ１〜ＳＴＤ１も生成する。音声付随テキストデータは、利用者端末１５上で音声の再生出力を行うときに画面（音声再生画面）に表示させるテキストデータである。

この音声付随テキストデータ（例えば、ＳＴＤ１）は、もとになるＷｅｂページ（例えば、ＷＡ１）のＨＴＭＬソースから生成するのが基本である。一例としては、前記見出しの内容であるテキスト「ＸＸＸＸＸＸＸＸＸ」をそのまま、当該音声付随テキストデータとしてもよい。このテキストの具体的な内容は、例えば、図１２に示す「ワールドカップで日本初の勝ち点」などである。

見出しの内容は、その記事の１または複数の段落の内容を簡潔に表現しているのが普通であるため、図１２のように見出しの内容を前記再生順序に応じた順序で列挙して表示しておけば、ユーザＵ１が、前記段落飛ばし等の操作を行う際に便利で、目的の音声ファイルへ到達しやすくなる。

図１２は、音声を再生出力する際、利用者端末１５上で表示出力される音声再生画面の例である。この画面は、基本的に、第１の実施形態で使用した図１０の音声再生画面に対応する。したがって、図１２上で図１０と同じ符号ＢＴ１１〜ＢＴ１４を付与した各種のボタンの機能は第１の実施形態と同じである。

なお、ある音声ファイルを再生出力しているとき、その音声ファイルに対応する見出しの内容を、図１２の音声生成画面上で、視覚的に、他の見出しの内容とは異なるものとして表示することも望ましい。

このような音声付随テキストデータを得るためには、ルールに基づく処理の内容も、第１の実施形態から変更する必要があることは当然である。ただしこの変更は、極めて、軽微な変更で足りる。例えば、図３のフローチャートに対応するルールの場合、ステップＰ１２で見出しの内容であるテキストを抽出した際、このテキストを音声合成用のほか、音声付随テキストデータとしても活用するようにすればよいだけである。

また、もしも、利用者端末１５側で画面表示するためにそのほうが好都合であれば、当該音声付随テキストデータとしてのテキストは、タグ（＜ｈ１＞など）で囲まれた状態のデータであってもよい。

さらに、図１１の例では、音声付随テキストデータ（例えば、ＳＴＡ１）は、シナリオデータＳＹ１の一部として、シナリオデータＳＹ１とともに転送されているが、必要に応じて、音声ファイル（例えば、ＰＡ１）とともに転送するようにしてもよい。いずれにしても、音声ファイルと音声付随テキストデータの対応関係は維持できるようにしておく必要がある。

（Ｂ−３）第２の実施形態の効果
本実施形態では第１の実施形態の効果とほぼ同等な効果を得ることができる。

加えて、本実施形態では、利用者端末（１５）側で、音声付随テキストデータに応じた画面表示を行うことができるため、段落飛ばしや聞き返しを行う際、ユーザ（Ｕ１）が、目的の音声ファイルを見つけやすくなり、いっそう利便性が向上する。

（Ｃ）第３の実施形態
以下では、本実施形態が第１、第２の実施形態と相違する点についてのみ説明する。

第１、第２の実施形態は、主として、前記リアルタイム型に対応するものであったが、本実施形態は、前記バックグラウンド型に対応する。

また本実施形態では、同じデータに対する同じ処理を重ねて行わないようにして、処理能力を節約する点も、第１、第２の実施形態と相違する。

（Ｃ−１）第３の実施形態の構成および動作
本実施形態は第１、第２の実施形態に比べ、音声データ合成サーバ（すなわち、合成サーバ）の内部構成が相違するだけである。第１、第２の実施形態のなかでは、第２の実施形態の合成サーバ５３のほうが、本実施形態の合成サーバ６３に近い。

本実施形態の合成サーバ６３の内部構成例を図１３に示す。

図１３において、図１１と同じ符号を付与した構成要素３０，３１，３２，３４，３５，３６，３７，３８，ＵＲＬＡ１〜ＵＲＬＤ１，ＲＬＡ１〜ＲＬＤ１、ＷＡ１〜ＷＤ１，ＭＥ２，ＰＡ１〜ＰＤ１，ＳＹ１の機能は基本的に第２の実施形態と同じであるので、その詳しい説明は省略する。

本実施形態の合成サーバ６３はこれらの構成要素のほか、第２の実施形態の合成サーバ５３が持たなかった構成要素として、テキスト提供部６４と、取得スケジュールデータベース（取得スケジュールＤＢ）６５と、音声合成履歴管理部６６と、生成済みシナリオデータ蓄積部６７とを備えている。

当該テキスト合成部６４も、基本的には、第２の実施形態のテキスト合成部５４と同じ機能を持つが、音声合成履歴管理部６６に格納されている音声合成履歴情報ＨＹ１に応じた処理を行う点が相違する。

音声合成履歴管理部６６は、各ＨＴＭＬソースに対して、過去に、音声合成部３４で音声合成を行い音声ファイル（例えば、ＰＡ１１）を生成したか否かを示す音声合成履歴情報ＨＹ１を、例えば、ＵＲＬに対応づける形式で格納している。

過去に生成した音声ファイル（例えば、ＰＡ１１）を合成サーバ６３内、または配信サーバ１２内に保存しておけば、今回の配信でも再利用することができるため、過去に生成したものと同じ音声ファイルを再度、生成する必要がなくなる。

なお、ＨＴＭＬソースの内容は更新されることがあるため、更新された場合には、同じＵＲＬのＨＴＭＬソースであっても、新たに音声ファイルを生成する必要がある。更新の有無は、ＨＴＭＬソースの内容を実際に照合することによって検査してもよいが、送信したＨＴＴＰリクエストメッセージに応えてＷｅｂサーバ（例えば、１４Ａなど）から返送されてくるＨＴＴＰレスポンスメッセージに含まれるエンティティヘッダ中の更新日時情報などを利用すれば、いっそう効率的に検査することができる。

この検査では、例えば、同じＵＲＬへのＨＴＴＰリクエストメッセージに対し、前回、返送されてきたＨＴＴＰレスポンスメッセージの更新日時情報を記憶しておき、今回、返送されてきたＨＴＴＰレスポンスメッセージの更新日時情報が前回のものから変化しているか否かを調べるとよい。これによれば、前回と今回のＨＴＭＬソースの内容を実際に照合する場合に比べ、はるかに簡単に更新の有無を確認することができる。

前記生成済みシナリオデータ蓄積部６７は、過去に生成したシナリオデータ（例えば、ＳＹ１）を蓄積しておき、できるだけ再利用するための部分である。シナリオデータの再利用が可能か否かの条件は、基本的に、前記音声ファイルの再利用が可能か否かの条件と同じである。したがって、もとのＷｅｂページ（例えば、ＷＡ１）の内容が更新されている場合には、シナリオデータも新たに生成する必要がある。

前記取得スケジュールＤＢ６５は、各ＵＲＬに対応づけて、該当ＵＲＬが指定するＷｅｂページの取得スケジュール情報ＳＣＡ１〜ＳＣＤ１を登録したデータベースである。

取得スケジュールの本体は一種のプログラムコード（プログラムファイル）であるとみることができるから、第１の実施形態の音声データＤＢ２４の構成と同様に、所定の記憶装置（図示せず）上で各プログラムファイルが記憶されている領域のアドレス番号などを当該ＳＣＡ１〜ＳＣＤ１の替わりに取得スケジュールＤＢ６５に登録する構成としてもよい。

前記バックグラウンド型に対応する本実施形態の合成サーバ６３は、ＵＲＬごとに予め定めたこのスケジュール情報（例えば、ＳＣＡ１）にしたがって、該当するＷｅｂサーバ（例えば、１４Ａ）に、ＨＴＴＰリクエストメッセージを送信することで、ＨＴＴＰレスポンスメッセージに含まれる前記Ｗｅｂページ（例えば、ＷＡ１）を取得することになる。

用いるメソッドは必ずしもＧＥＴメソッドである必要はないので、ＨＥＡＤメソッドなどを用いて、ＨＴＴＰヘッダ情報（これには、前記更新日時情報なども含まれる）だけを取得するようにしてもよいことは当然である。ＨＴＴＰヘッダ情報だけを取得する場合、サイズの大きなエンティティボディ（ここでは、ＨＴＭＬファイル）を取得する必要がないため、通信トラフィックを抑制でき、合成サーバ６３内における処理も速い。

合成サーバ６３内で新たに生成した音声ファイルは、音声データ蓄積依頼部３６により、配信サーバ１２側に蓄積されるため、利用者端末１５からその音声ファイルを要求するＨＴＴＰリクエストメッセージが届けば、利用者端末１５へ返信される。この際、前提として、新たなシナリオデータ（ＳＹ１に相当）も、利用者端末１５へ送信されることは当然である。

本実施形態ではリアルタイム型に比べて、コンテンツの最新性はある程度、犠牲になるものの、レスポンス性能を著しく向上できる可能性がある。

コンテンツの最新性が犠牲になる理由は、利用者端末１５からＨＴＴＰリクエストメッセージが届いた時点で、すでに蓄積されている音声ファイルをそのまま返送することにある。この音声ファイルは、前記取得スケジュールにしたがって取得したＷｅｂページ（例えば、ＷＡ１）に基づいて生成されるため、例えばこの取得スケジュールが１週間置きにＷｅｂページを取得するものであれば、その１週間のあいだに行われたＷｅｂページの更新には対応することができないからである。

また、レスポンス性能を著しく向上できる理由は、リアルタイム型と異なり、利用者端末１５からのＨＴＴＰリクエストメッセージが届いてから、合成サーバ６３がＷｅｂページ（例えば、ＷＡ１など）を取得したり、音声合成を行ったりする必要はなく、すでに生成済みの音声ファイルを返送するだけでよいからである。

なお、本実施形態では、音声合成履歴情報ＨＹ１に基づいて、生成済みのシナリオデータや生成ずみの音声ファイルを再利用できるため、合成サーバ６３の処理能力を節約し、効率的に処理を進めることが可能である。これにより、取得スケジュールＤＢ６５に登録したＵＲＬの数がかなり多い場合でも、限られた処理能力で対応することが可能となる。

（Ｃ−２）第３の実施形態の効果
本実施形態によれば、第１、第２の実施形態と同等な効果を得ることができる。

加えて、本実施形態では、バックグラウンド型による高いレスポンス性能を、効率的に実現することが可能になる。

（Ｄ）他の実施形態
なお、上記第１〜第３の実施形態では、見出しとして、＜ｈ１＞タグを用いる文字サイズの大きな見出しのみを用いたが、同じＷｅｂページ上に＜ｈ２＞タグや、＜ｈ３＞タグ等を用いて、より文字サイズが小さい見出しも混在させることができることは当然である。その場合、文字サイズが最も大きい見出しに基づいて記事を分けることができるため、１つの記事内に複数の見出しが含まれているケースにも、容易に対応することが可能である。

また、上記第１〜第３の実施形態で使用した各種の画面の構成例は、一例を示しているだけであるので、種々の変形が可能である。例えば、図８（Ｂ）のハイパーリンクの数は、図示した３つより少なくてもよく、多くてもよい。

さらに、上記第１〜第３の実施形態にかかわらず、ルールは、ＵＲＬごとに設けるのではなく、Ｗｅｂページの構成をいくつかの類型に分け、この類型ごとに設けるようにしてもよい。その場合、各ＵＲＬのＷｅｂページがいずれの類型に属するかを判定し、判定結果に応じたルールを適用するようにするとよい。これによって、必要なルールの数を低減することができる。

また、上記第１〜第３の実施形態にかかわらず、合成サーバと配信サーバは、同一のサーバマシン上に搭載することができる。その場合、合成サーバと配信サーバ間の通信は、当該マシン内部の内部で実行される。

なお、上記第１〜第３の実施形態では、Ｗｅｂページに含まれるテキストデータに関する処理のみを行ったが、必要に応じて、他のデータも活用することが可能である。

例えば、図２のように、Ｗｅｂページに画像データが含まれている場合には、図１２のような音声生成画面上に、その画像を表示してもよい。また、画像には、写真、絵、図形などのほか、文字が画像として表現されたものも含まれる。文字認識の技術を活用すれば、このように画像としてＷｅｂページ上に配置された文字も、音声合成の対象とすることが可能である。

なお、前記配信サーバや合成サーバの機能は、利用者端末１５とＷｅｂサーバ（例えば、１４Ａ）のあいだに配置されることの多いプロキシサーバに配置することも可能である。

また、上記第１〜第３の実施形態では、Ｗｅｂサーバ群１４と利用者端末１５のあいだに、合成サーバ（例えば、１３）や配信サーバ１２が介在するゲートウエイ型の構成となっているが、合成サーバの持つ特徴的な機能（テキスト提供部（例えば、３３）や、ルールＤＢ３８などに対応する機能）は、利用者端末１５側に配置することもでき、Ｗｅｂサーバ（例えば、１４Ａ）側に配置することもできる。

さらにまた、上記第１〜第３の実施形態では、Ｗｅｂページがネットワーク経由で取得されることを前提としているが、ＣＤ−ＲＯＭなどの記録媒体から得たＷｅｂページにも本発明は適用できるので、対象とするＷｅｂページは、必ずしもネットワーク経由で入手されるものでなくてもかまわない。

なお、本発明がＨＴＭＬ以外のマークアップ言語に対応可能であることは、すでに説明した通りである。上述したＨＤＭＬのほか、例えば、ＸＭＬやＳＧＭＬなどにも対応可能である。

また、前記ＨＴＴＰは、その他の通信プロトコルに置換可能であり、前記ＴＣＰプロトコルは、その他のトランスポート層プロトコル（例えば、ＵＤＰプロトコルなど）に置換可能であり、前記ＩＰプロトコルはその他のネットワーク層プロトコル（例えば、ＩＰＸプロトコルなど）に置換可能である。

さらに、前記ＣＧＩは、その他のアプリケーション連携機能に置換可能である。

以上の説明では主としてソフトウエア的に本発明を実現したが、本発明はハードウエア的に実現することも可能である。

第１の実施形態にかかる通信システムの全体構成例を示す概略図である。第１の実施形態で使用するＷｅｂページの一例である。第１の実施形態で使用するルールの一例を示すフローチャートである。第１の実施形態で使用するＷｅｂページの一例である。第１の実施形態で使用するルールの一例を示すフローチャートである。第１の実施形態で使用する別な例に関するルールの概要を示す説明図である。第１の実施形態で使用する利用者端末の構成例を示す概略図である。第１の実施形態で使用するＵＲＬ送信画面の構成例を示す概略図である。第１の実施形態における音声データ合成サーバの動作例を示すフローチャートである。第１の実施形態で使用する音声再生画面の構成例を示す概略図である。第２の実施形態で使用する音声データ合成サーバの内部構成例を示す概略図である。第２の実施形態で使用する音声再生画面の構成例を示す概略図である。第３の実施形態で使用する音声データ合成サーバの内部構成例を示す概略図である。第１の実施形態で使用する音声データ合成サーバに含まれるテキスト提供部の内部構成例を示す概略図である。第１の実施形態で使用するＷｅｂページの一例である。

符号の説明

１０…通信システム、１１…インターネット、１２…音声データ配信サーバ、１３…音声データ合成サーバ、１４…情報サーバ群（Ｗｅｂサーバ群）、１４Ａ〜１４Ｄ…情報サーバ（Ｗｅｂサーバ）、２０，３０…制御プログラム部、２１，３１…ＴＣＰ／ＩＰ部、２２，３２…ＨＴＴＰ／ＣＧＩ部、２３…音声データ蓄積部、２４…音声データＤＢ、３３、５４，６４…テキスト提供部、３４…音声合成部、３５…一時記憶部、３６…音声データ蓄積依頼部、３７…シナリオデータ生成部、３８…ルールＤＢ、ＷＡ１〜ＷＤ１…Ｗｅｂページ、ＰＡ１〜ＰＤ１，ＰＡ１１〜ＰＡ１４…音声ファイル、ＳＹ１…シナリオデータ、ＭＥ１，ＭＥ２…中間データ。

Claims

記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供する音声データ提供装置において、
複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納しているルール格納部と、
文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成する第１のブロック記述内容生成部と、
前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換する第２のブロック記述内容生成部と、
前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換してファイルに収容する音声合成処理部とを備え、
このファイルを、前記音声データとして提供することを特徴とする音声データ提供装置。
請求項１の音声データ提供装置において、
前記第１の生成規則は、適用対象の構造化文書の記述内容に含まれているブロック記述内容の範囲を指定するブロック範囲指定用の構造化制御情報を基に、１または複数のブロック記述内容を生成する規則であることを特徴とする音声データ提供装置。
請求項１または２の音声データ提供装置において、
他の構造化文書へのリンク情報が張られた構造化文書に適用する前記第１の生成規則は、前記他の構造化文書をリンク情報に基づいて取り出し、取り出した他の構造化文書の記述内容に含まれているブロック記述内容の範囲を指定するブロック範囲指定用の構造化制御情報を基に、１または複数のブロック記述内容を生成する規則であることを特徴とする音声データ提供装置。
請求項１〜３のいずれかの音声データ提供装置において、
前記ファイルに関し、再生順序を指定する順序情報を生成する順序情報生成部を備えたことを特徴とする音声データ提供装置。
請求項１〜４のいずれかの音声データ提供装置において、
最終的に前記ファイルの提供を受けるクライアント端末に、前記ファイル内の音声データに対応する音声とともに出力させてユーザに目視させる表示用記述内容を、前記構造化文書から抽出する表示用記述内容抽出部を備えたことを特徴とする音声データ提供装置。
記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供する音声データ提供方法において、
ルール格納部は、複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納し、
第１のブロック記述内容生成部は、文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成し、
第２のブロック記述内容生成部は、前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換し、
音声合成処理部が、前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換してファイルに収容し、
このファイルを、前記音声データとして提供することを特徴とする音声データ提供方法。
請求項６の音声データ提供方法において、
前記第１の生成規則は、適用対象の構造化文書の記述内容に含まれているブロック記述内容の範囲を指定するブロック範囲指定用の構造化制御情報を基に、１または複数のブロック記述内容を生成する規則であることを特徴とする音声データ提供方法。
請求項６または７の音声データ提供方法において、
他の構造化文書へのリンク情報が張られた構造化文書に適用する前記第１の生成規則は、前記他の構造化文書をリンク情報に基づいて取り出し、取り出した他の構造化文書の記述内容に含まれているブロック記述内容の範囲を指定するブロック範囲指定用の構造化制御情報を基に、１または複数のブロック記述内容を生成する規則であることを特徴とする音声データ提供方法。
請求項６〜８のいずれかの音声データ提供方法において、
順序情報生成部が、前記ファイルに関し、当該ファイルに収容されている音声データの変換元であるブロック記述内容の前記構造化文書中における位置をもとに、再生順序を指定する順序情報を生成することを特徴とする音声データ提供方法。
請求項６〜９のいずれかの音声データ提供方法において、
最終的に前記ファイルの提供を受けるクライアント端末に、前記ファイル内の音声データに対応する音声とともに出力させてユーザに目視させる表示用記述内容を、表示内容抽出部が、前記構造化文書から抽出することを特徴とする音声データ提供方法。
記述内容を構造化するための所定の構造化制御情報と、この構造化制御情報によって構造化された記述内容とを少なくとも含む、ユニークな文書識別情報によって指定された構造化文書に関し、その記述内容に応じた音声データを提供するための音声データ提供プログラムであって、
コンピュータを、
複数の文書識別情報のそれぞれに対応付けて、その文書識別情報によって特定される構造化文書に適用する第１の生成規則及び第２の生成規則を格納しているルール格納部と、
文書識別情報によって指定された構造化文書に関し、前記ルール格納部に格納されている指定された構造化文書に適用する前記第１の生成規則に従い、音声データの提供単位となる１または複数のブロック記述内容を生成する第１のブロック記述内容生成部と、
前記ルール格納部に格納されている指定された構造化文書に適用する前記第２の生成規則に従い、ブロック記述内容の範囲内で使用される構造化制御情報である範囲内構造化制御情報が、前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容に含まれている場合、当該範囲内構造化制御情報を除去することにより、範囲内構造化制御情報を含まないブロック記述内容に変換する第２のブロック記述内容生成部と、
前記第２のブロック記述内容生成部の処理を経た１または複数のブロック記述内容、および、前記第２のブロック記述内容生成部の処理が不要な前記第１のブロック記述内容生成部が生成した１または複数のブロック記述内容を、所定のデータ形式の音声データに変換して、音声データとして提供するファイルに収容する音声合成処理部と
して機能させることを特徴とする音声データ提供プログラム。