特許 6596891 送信装置、送信方法、受信装置、及び、受信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6596891

(24)【登録日】2019年10月11日

(45)【発行日】2019年10月30日

(54)【発明の名称】送信装置、送信方法、受信装置、及び、受信方法

(51)【国際特許分類】

   H04N 21/235 20110101AFI20191021BHJP

   H04N 21/435 20110101ALI20191021BHJP

【ＦＩ】

   H04N21/235

   H04N21/435

【請求項の数】15

【全頁数】30

(21)【出願番号】特願2015-79603(P2015-79603)

(22)【出願日】2015年4月8日

(65)【公開番号】特開2016-201643(P2016-201643A)

(43)【公開日】2016年12月1日

【審査請求日】2018年3月28日

【前置審査】

(73)【特許権者】

【識別番号】000002185

【氏名又は名称】ソニー株式会社

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【識別番号】100082131

【弁理士】

【氏名又は名称】稲本 義雄

(74)【代理人】

【識別番号】100168686

【弁理士】

【氏名又は名称】三浦 勇介

(72)【発明者】

【氏名】山根 武敏

(72)【発明者】

【氏名】山岸 靖明

【審査官】 後藤 嘉宏

(56)【参考文献】

【文献】 特開平０９−２５８７６３（ＪＰ，Ａ）

【文献】 特開平０９−３０５１９８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１２８３２３（ＵＳ，Ａ１）

【文献】 特開２００４−３１２５０７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／００１９１３５（ＵＳ，Ａ１）

【文献】 特開２００５−３０９１６４（ＪＰ，Ａ）

【文献】 特開２０１５−０２７００４（ＪＰ，Ａ）

【文献】 特開２０１２−０８０４７５（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０３９９６２（ＷＯ，Ａ１）

【文献】 特開平０９−３３００９３（ＪＰ，Ａ）

【文献】 特開２００９−２０４７１１（ＪＰ，Ａ）

【文献】 データ放送と音声合成を用いた視覚障害者向け緊急速報スーパー読み上げサービス，映像情報メディア学会 ２００７年年次大会講演予稿集，２００７年 ８月 １日，１２−１０

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００−２１／８５８

(57)【特許請求の範囲】

【請求項1】

緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を取得する緊急情報源情報取得部と、
前記緊急情報源情報を処理する処理部と、
前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られるアドレス情報を放送信号に含めて送信する送信部と
を備え、
前記メタデータは、前記緊急情報のメッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、
前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む
送信装置。

【請求項2】

前記メタデータは、読み方が一意に定まらない文字列、又は固有名詞の発話に関するファイルの取得先を示す前記アドレス情報を含んでいる
請求項１に記載の送信装置。

【請求項3】

前記緊急情報源情報は、前記メッセージを含み、
前記緊急情報を受信する受信装置において、前記メッセージが表示されるとともに、前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じた音声が出力される
請求項２に記載の送信装置。

【請求項4】

コンテンツを取得するコンテンツ取得部をさらに備え、
前記送信部は、放送信号として、前記コンテンツを送信するとともに、緊急時となった場合には、前記緊急情報を送信する
請求項３に記載の送信装置。

【請求項5】

前記緊急情報源情報は、OASIS(Organization for the Advancement of Structured Information Standards)で規定されたCAP(Common Alerting Protocol)に準拠したCAP情報である
請求項１に記載の送信装置。

【請求項6】

前記緊急情報は、前記CAP情報を、ATSC(Advanced Television Systems Committee)で規定される所定のフォーマットに準拠した形式に変換して得られる、前記メッセージと前記アドレス情報を含むシグナリング情報である
請求項５に記載の送信装置。

【請求項7】

前記緊急情報は、前記メッセージと前記アドレス情報を含む前記CAP情報である
請求項５に記載の送信装置。

【請求項8】

送信装置の送信方法において、
前記送信装置が、
緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を取得し、
前記緊急情報源情報を処理し、
前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られるアドレス情報を放送信号に含めて送信する
ステップを含み、
前記メタデータは、前記緊急情報のメッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、
前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む
送信方法。

【請求項9】

緊急時において、送信装置から放送信号として送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、アドレス情報を含む前記緊急情報を受信する受信部と、
前記緊急情報を処理して、前記メッセージを表示させるとともに、前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じた音声を出力させる処理部と
を備え、
前記緊急情報は、前記メッセージと、前記メッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を処理することで得られ、
前記メタデータは、前記メッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、
前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む
受信装置。

【請求項10】

前記メタデータは、読み方が一意に定まらない文字列、又は固有名詞の発話に関するファイルの取得先を示す前記アドレス情報を含んでいる
請求項９に記載の受信装置。

【請求項11】

前記受信部は、前記送信装置から送信されてくる放送信号として、コンテンツを受信するとともに、緊急時となった場合に送信されてくる前記緊急情報を受信する
請求項１０に記載の受信装置。

【請求項12】

前記緊急情報源情報は、OASISで規定されたCAPに準拠したCAP情報である
請求項９に記載の受信装置。

【請求項13】

前記緊急情報は、前記CAP情報を、ATSCで規定される所定のフォーマットに準拠した形式に変換して得られるシグナリング情報であり、
前記シグナリング情報に含まれる前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じて、前記シグナリング情報に含まれる前記メッセージを読み上げる音声読み上げ部をさらに備える
請求項１２に記載の受信装置。

【請求項14】

前記緊急情報は、前記CAP情報であり、
前記CAP情報に含まれる前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じて、前記CAP情報に含まれる前記メッセージを読み上げる音声読み上げ部をさらに備える
請求項１２に記載の受信装置。

【請求項15】

受信装置の受信方法において、
前記受信装置が、
緊急時において、送信装置から放送信号として送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、アドレス情報を含む前記緊急情報を受信し、
前記緊急情報を処理して、前記メッセージを表示させるとともに、前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じた音声を出力させる
ステップを含み、
前記緊急情報は、前記メッセージと、前記メッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を処理することで得られ、
前記メタデータは、前記メッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、
前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む
受信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本技術は、送信装置、送信方法、受信装置、及び、受信方法に関し、特に、視覚障がい者に対するアクセシビリティを向上させることができるようにした送信装置、送信方法、受信装置、及び、受信方法に関する。

【背景技術】

【0002】

デジタル放送の分野では、視覚障がい者に対するアクセシビリティが求められている(例えば、特許文献１参照)。

【0003】

特に、米国では、いわゆる米国アクセシビリティ法(CVAA：The 21st Century Communications and Video Accessibility Act of 2010)が制定され、連邦通信委員会(FCC：Federal Communications Commission)により、この法律をベースとした映像番組のアクセシビリティに関する様々な規制が発表されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００９−２０４７１１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、米国では、EAS(Emergency Alerting System)と呼ばれる緊急告知のシステムが整備されており、大統領からの最優先事項からローカルな告知事項まで、様々なレベルの緊急情報を、様々なメディアにより告知できるようになっている。

【0006】

デジタル放送において、このような緊急情報を告知する場合にも、視覚障がい者に対するアクセシビリティが求められるが、既存のTTS(Text To Speech)エンジンでは、緊急情報の制作者が意図した通りに、テキスト情報が読み上げられるとは限らず、視覚障がい者が、健常者と同等の情報を得られる保証がない。そのため、確実に、緊急情報の制作者が意図した通りの発話が行われて、視覚障がい者が、健常者と同様の情報を得られるようにするための技術が求められていた。

【0007】

本技術はこのような状況に鑑みてなされたものであり、確実に、緊急情報の制作者が意図した通りの発話が行われるようにすることで、視覚障がい者に対するアクセシビリティを向上させることができるようにするものである。

【課題を解決するための手段】

【0008】

本技術の第１の側面の送信装置は、緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を取得する緊急情報源情報取得部と、前記緊急情報源情報を処理する処理部と、前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られるアドレス情報を放送信号に含めて送信する送信部とを備え、前記メタデータは、前記緊急情報のメッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む送信装置である。

【0009】

本技術の第１の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の送信方法は、上述した本技術の第１の側面の送信装置に対応する送信方法である。

【0010】

本技術の第１の側面の送信装置、及び、送信方法においては、緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報が取得され、前記緊急情報源情報が処理され、前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られるアドレス情報が放送信号に含めて送信される。また、前記メタデータには、前記緊急情報のメッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報が含まれ、前記アドレス情報には、通信経由で配信される前記ファイルの取得先が含まれる。

【0011】

本技術の第２の側面の受信装置は、緊急時において、送信装置から放送信号として送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、アドレス情報を含む前記緊急情報を受信する受信部と、前記緊急情報を処理して、前記メッセージを表示させるとともに、前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じた音声を出力させる処理部とを備え、前記緊急情報は、前記メッセージと、前記メッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を処理することで得られ、前記メタデータは、前記メッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報を含み、前記アドレス情報は、通信経由で配信される前記ファイルの取得先を含む受信装置である。

【0012】

本技術の第２の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の受信方法は、上述した本技術の第２の側面の受信装置に対応する受信方法である。

【0013】

本技術の第２の側面の受信装置、及び、受信方法においては、緊急時において、送信装置から放送信号として送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、アドレス情報を含む前記緊急情報が受信され、前記緊急情報を処理して、前記メッセージが表示されるとともに、前記アドレス情報に基づいて取得された前記メッセージに対する制作者が意図する音声の発話に応じた音声が出力される。また、前記緊急情報は、前記メッセージと、前記メッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を処理することで得られ、前記メタデータには、前記メッセージに対する制作者が意図する音声の発話に関するファイルの取得先を示す前記アドレス情報が含まれ、前記アドレス情報には、通信経由で配信される前記ファイルの取得先が含まれる。

【発明の効果】

【0014】

本技術の第１の側面、及び、第２の側面によれば、視覚障がい者に対するアクセシビリティを向上させることができる。

【0015】

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

【図面の簡単な説明】

【0016】

【図1】緊急情報の伝送の概要を示す図である。

【図2】緊急情報の表示例を示す図である。

【図3】従来のTTSエンジンによるテキスト情報の読み上げ例を説明する図である。

【図4】従来のTTSエンジンによるテキスト情報の読み上げ例を説明する図である。

【図5】本技術を適用したTTSエンジンによるテキスト情報の読み上げ例を説明する図である。

【図6】本技術を適用したTTSエンジンによるテキスト情報の読み上げ例を説明する図である。

【図7】本技術を適用した放送システムの構成例を示す図である。

【図8】本技術を適用した送信装置の構成例を示す図である。

【図9】本技術を適用した受信装置の構成例を示す図である。

【図10】CAP情報の構造の例を示す図である。

【図11】CAP情報の記述例を示す図である(Common Alerting Protocol Version 1.2 01 July 2010 Appendix A より抜粋)。

【図12】拡張CAP情報で追加される要素と属性の例を示す図である。

【図13】拡張CAP情報のXMLスキーマの記述例を示す図である。

【図14】拡張CAP情報における名前空間の指定を説明する図である。

【図15】拡張CAP情報の記述例を示す図である。

【図16】送信処理を説明するフローチャートである。

【図17】受信処理を説明するフローチャートである。

【図18】コンピュータの構成例を示す図である。

【発明を実施するための形態】

【0017】

以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。

【0018】

１．本技術の音声発話メタデータの概要
２．システムの構成
３．CAP情報の拡張による音声発話メタデータの配置
４．各装置で実行される処理の流れ
５．変形例
６．コンピュータの構成

【0019】

＜１．本技術の音声発話メタデータの概要＞

【0020】

米国アクセシビリティ法に関係する連邦通信委員会(FCC)の規制では、放送事業者(サービス事業者)に対して緊急情報(Emergency Alerts)を、視覚障がい者に対してアクセシブルにするために、メッセージ等のテキスト情報とは別に、音声情報での送信を義務づけている。

【0021】

連邦通信委員会(FCC)の規制では、この音声情報を用いた緊急情報の生成方法として、TTS(Text To Speech)エンジンの使用を認めているが、このTTSエンジンで生成された音声については、明瞭さと正しい発音が求められている。ここで、TTSエンジンは、テキスト情報から、人間の音声を人工的に作り出すことができる音声合成機(Text To Speech Synthesizer)である。

【0022】

一方で、緊急情報は、CAP(Common Alerting Protocol)方式の緊急告知の情報(以下、「CAP情報」ともいう)として、放送局に伝達されることになる。すなわち、米国では、EASと呼ばれる緊急告知のシステムが整備されているので、このEASを利用して、大統領からの最優先事項からローカルな告知事項まで、様々なレベルの緊急情報(CAP情報)が、様々なメディアにより告知(通知)されることになる。

【0023】

なお、CAP情報は、構造化情報標準促進協会(OASIS：Organization for the Advancement of Structured Information Standards)で規定されているCAPに準拠したものとなる。

【0024】

例えば、図１において、緊急情報源(Alerting Sources)から告知(通知)される緊急情報源情報がCAP情報に変換され、放送局(のEASシステム)(Emergency Alert System at Station)に提供される。放送局(のEASシステム)は、緊急情報源からのCAP情報を、緊急情報の映像(メッセージ)や音声情報としてレンダリングやエンコードするか、あるいは所定のフォーマットに変換するか、あるいはそのままの形式で、ローカル放送局(Local Broadcast)に提供する。そして、ローカル放送局(の送信機)は、このようにして伝達されてくる緊急情報を、放送エリア内の多数の受信機に対して送信することになる。

【0025】

例えば、緊急情報源には、気象業務を担当する国家機関(例えば米国国立気象局(NWS：National Weather Service))等が該当し、気象警報を提供する。この場合、放送局、又は放送局(の送信機)からの緊急情報を受信した受信機では、放送番組に、気象警報を重畳表示させることになる(図２Ａ)。また、例えば、緊急情報源が、ある地方の機関等が該当する場合、その地方に関する緊急情報源情報を提供する。この場合、放送局、又は放送局(の送信機)からの緊急情報を受信した受信機では、放送番組に、その地方に関する緊急情報を重畳表示させることになる(図２Ｂ)。

【0026】

ここで、放送局側で、CAP情報を用い、TTSエンジンを使用した音声での緊急情報を生成する場合に、連邦通信委員会(FCC)の規制で要求されている、明瞭で正しい発音が保証できないという問題がある。すなわち、TTSエンジンでは、緊急情報の制作者が意図した通りに、テキスト情報が読み上げられるとは限らず、視覚障がい者が、健常者と同等の情報が得られる保証はない。

【0027】

具体的には、図３に示すように、例えば、"AAA"であるテキスト情報は、"triple A"又は"A A A"と読めるため、その読み方が一意に定まらないので、TTSエンジンでは、どのように読み上げてよいかを判断できず、結果として、制作者が意図した通りに、テキスト情報が読み上げられない可能性が出てくる。

【0028】

また、図４に示すように、例えば、"Caius College"であるテキスト情報は、その発音が難解な固有名詞等であるため、TTSエンジンでは、どのように読み上げていいのかが判断できず、制作者が意図した通りに、テキスト情報が読み上げられない可能性がある。

【0029】

このように、テキスト情報(緊急情報のメッセージ)の読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などには、制作者が意図した通りにテキスト情報が読み上げられない可能性があるため、確実に、制作者が意図した通りの発話が行われて、視覚障がい者が、健常者と同等の緊急情報を得られるようにする技術が求められていた。

【0030】

そこで、本技術では、確実に、緊急情報に対する制作者が意図した通りの音声の発話が行われるようにするために、制作者が意図する音声の発話に関する情報(以下、「音声発話メタデータ」という)を、TTSエンジンに提供して、当該TTSエンジンが、制作者が意図する音声を発話できるようにする。なお、当該音声発話メタデータは、CAP情報に含めて提供することができる。

【0031】

具体的には、図５に示すように、例えば、"AAA"であるテキスト情報について、その音声の読み方を示した"triple A"を、音声発話メタデータとして、TTSエンジンに提供されるようにすることで、当該TTSエンジンは、音声発話メタデータに基づいて、"triple A"と読み上げることができる。

【0032】

すなわち、図３において、"AAA"であるテキスト情報を入力した場合、TTSエンジンは、"triple A"と、"A A A"のどちらで読み上げるのが正しいかを判断することができなかったが、図５においては、音声発話メタデータとしての"triple A"を入力することで、TTSエンジンは、音声発話メタデータに従い、"triple A"を読み上げることができる。その結果、制作者が意図する音声が発話されることになる。

【0033】

また、図６に示すように、例えば、"Caius College"であるテキスト情報について、その音素情報を、音声発話メタデータとして、TTSエンジンに提供されるようにすることで、当該TTSエンジンは、音声発話メタデータに基づいて、"keys college"と読み上げることができる。

【0034】

すなわち、図４において、"Caius College"であるテキスト情報を入力した場合、TTSエンジンは、その発音が難解な固有名詞等であるため、どのように読み上げるのが正しいかを判断することができなかったが、図６においては、音声発話メタデータとしての音素情報を入力することで、TTSエンジンは、音声発話メタデータに従い、"keys college"と読み上げることができる。その結果、制作者が意図する音声が発話されることになる。

【0035】

このように、音声発話メタデータをTTSエンジンに提供することで、例えば、テキスト情報(緊急情報のメッセージ)の読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などであっても、確実に、制作者が意図した通りにテキスト情報が読み上げられるため、視覚障がい者が、健常者と同等の情報を得られるようになる。

【0036】

＜２．システムの構成＞

【0037】

（放送システムの構成例）
図７は、本技術を適用した放送システムの構成例を示す図である。

【0038】

図７において、放送システム１は、放送番組等のコンテンツを提供するとともに、緊急に告知する必要がある情報である緊急情報を、視覚障がい者に対してアクセシブルにすることが可能なシステムである。放送システム１は、送信側の送信装置１０及びCAP情報提供装置１１と、受信側の受信装置２０から構成される。ただし、受信装置２０は、インターネット５０を介してサーバ４０と相互に通信することが可能である。

【0039】

送信装置１０は、例えば地上デジタル放送サービスを提供する放送局により運営される。送信装置１０は、放送番組等のコンテンツを、デジタル放送信号により送信する。この送信装置１０は、図１の放送局(Station)とローカル放送局(Local Broadcast)に相当するものである。

【0040】

CAP情報提供装置１１は、緊急時において、音声発話メタデータを含むCAP情報(以下、「拡張CAP情報」ともいう)を生成して、送信装置１０に送信する。なお、CAP情報提供装置１１により生成される拡張CAP情報は、図１の緊急情報源(Alerting Sources)からのCAP情報に相当するものである。

【0041】

緊急時において、送信装置１０は、CAP情報提供装置１１から送信されてくる拡張CAP情報を受信し、当該拡張CAP情報に基づいた所定のデータ形式の緊急情報を、デジタル放送信号に含めて送信する。ただし、上述した連邦通信委員会(FCC)の規制に対応するためには、緊急情報のメッセージ(テキスト情報)を、視覚障がい者に対してアクセシブルにするために、当該メッセージの音声に関する情報を送信する必要がある。そこで、本技術では、緊急情報のメッセージの音声に関する情報を送信するための方式として、次の３つの方式を提案するものとする。

【0042】

第１の方式としては、拡張CAP情報に含まれるメッセージに対して、映像として受信装置２０の画面に表示させるためのレンダリングやエンコード等の処理を行い、緊急情報として送信されるようにする。また、このとき、拡張CAP情報に基づいて、緊急情報として送信されるメッセージの音声情報を生成するためのデコード等の処理を行い、それにより得られる音声情報が、緊急情報として送信されるようにする。すなわち、第１の方式では、緊急情報として、メッセージとともにその音声情報(音声に関する情報)が送信されることになる。

【0043】

なお、この場合、送信側の送信装置１０のTTSエンジンが、拡張CAP情報に含まれる音声発話メタデータに従い、メッセージを読み上げることになるため、例えば、テキスト情報の読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などであっても、確実に、制作者が意図した通りに読み上げられることになる。

【0044】

第２の方式としては、拡張CAP情報を、米国のデジタル放送規格であるATSC(Advanced Television Systems Committee)で規定される所定のフォーマットに準拠した形式に変換して、それにより得られるATSCの規定に対応した情報(以下、「ATSCシグナリング情報」という)が、緊急情報として送信されるようにする。なお、ここでは、例えば、米国の次世代デジタル放送規格であるATSC3.0に規定されるフォーマットを採用することができる。すなわち、第２の方式では、緊急情報として、メッセージとその音声発話メタデータ(音声に関する情報)を含むATSCシグナリング情報が送信されることになる。

【0045】

第３の方式としては、拡張CAP情報が、そのままの形式で、緊急情報として送信されるようにする。すなわち、第３の方式では、緊急情報として、メッセージとその音声発話メタデータ(音声に関する情報)を含む拡張CAP情報が送信されることになる。

【0046】

受信装置２０は、例えばテレビ受像機やセットトップボックス、録画機等から構成され、ユーザの各家庭等に設置される。受信装置２０は、伝送路３０を介して、送信装置１０から送信されてくるデジタル放送信号を受信し、放送番組等のコンテンツの映像や音声を出力する。

【0047】

また、緊急時において、受信装置２０は、送信装置１０から送信されてくる緊急情報を受信した場合、その緊急情報のメッセージを表示する。この場合に、送信装置１０からの緊急情報は、上述した第１の方式乃至第３の方式のいずれかの方式で伝送されてくることになる。

【0048】

第１の方式では、映像に重畳されたメッセージの音声情報が送信されてくるので、受信装置２０は、当該音声情報に対応した音声を出力することになる。この場合、当該音声情報は、送信側の送信装置１０において、音声発話メタデータに従い、TTSエンジンが読み上げたものとなるので、映像に重畳表示されたメッセージは、制作者が意図した通りに読み上げられることになる。

【0049】

第２の方式では、拡張CAP情報を変換して得られる、ATSCシグナリング情報が送信されてくるので、受信装置２０は、ATSCシグナリング情報に含まれる音声発話メタデータに従い、ATSCシグナリング情報に含まれるメッセージであって、表示中のメッセージを読み上げることができる。また、第３の方式では、拡張CAP情報が送信されてくるので、受信装置２０は、拡張CAP情報に含まれる音声発話メタデータに従い、拡張CAP情報に含まれるメッセージであって、表示中のメッセージを読み上げることができる。

【0050】

ここで、第２の方式と第３の方式においては、受信側の受信装置２０のTTSエンジンが、音声発話メタデータに従い、緊急情報のメッセージを読み上げることになるため、例えば、テキスト情報の読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などであっても、確実に、制作者が意図した通りに読み上げられることになる。

【0051】

また、ATSCシグナリング情報又は拡張CAP情報に格納される音声発話メタデータとしては、音声発話メタデータを取得するためのアドレス情報を記述したものと、音声発話メタデータの内容そのものを記述したものの２種類が存在する。そして、音声発話メタデータに、アドレス情報を記述した場合には、音声発話メタデータの内容は、当該アドレス情報に従い取得されるファイル(以下、「音声発話メタデータファイル」という)に記述されていることになる。

【0052】

このアドレス情報としては、例えば、インターネット５０上のサーバ４０にアクセスするためのURL(Uniform Resource Locator)が指定される。ここで、サーバ４０は、音声発話メタデータファイルを管理している。受信装置２０は、ATSCシグナリング情報又は拡張CAP情報に含まれる音声発話メタデータに記述されたアドレス情報(例えばURL)に従い、インターネット５０を介してサーバ４０にアクセスし、音声発話メタデータファイルを取得することができる。

【0053】

なお、上述した第１の方式乃至第３の方式は、緊急情報として送信されるメッセージの音声に関する情報を送信するためのデータ形式の一例であって、他のデータ形式を採用してもよい。また、第１の方式又は第２の方式を採用する場合には、緊急情報として、地理データ等の地域情報に基づいた、ローカル放送局ごとの情報が生成されるようにしてもよい。

【0054】

また、図７の放送システム１では、１台の送信装置１０のみを図示しているが、実際には、複数の放送局ごとに送信装置１０が設置され、各送信装置１０が、CAP情報提供装置１１から供給される拡張CAP情報を取得することになる。同様に、図７の放送システム１では、１台の受信装置２０のみを図示しているが、実際には、複数のユーザの家庭ごとに、受信装置２０が設置されている。

【0055】

（送信側の構成例）
図８は、図７の送信側の送信装置１０とCAP情報提供装置１１の構成例を示す図である。

【0056】

図８において、送信装置１０は、コンテンツ取得部１１１、ストリーム生成部１１２、送信部１１３、CAP情報取得部１１４、TTSエンジン１１５、及び、緊急情報フォーマット変換部１１６から構成される。

【0057】

コンテンツ取得部１１１は、放送番組等のコンテンツを取得して、ストリーム生成部１１２に供給する。また、コンテンツ取得部１１１は、コンテンツに対して、例えばエンコードやフォーマット形式の変換処理などを実行することができる。

【0058】

なお、コンテンツ取得部１１１においては、例えば、既に収録されたコンテンツの保管場所から、放送時間帯に応じて該当するコンテンツが取得されたり、あるいはスタジオやロケーション場所からライブのコンテンツが取得されたりする。

【0059】

ストリーム生成部１１２は、コンテンツ取得部１１１から供給されるコンテンツデータに、シグナリングデータなどを多重化することで、ATSCの規定に準拠したストリームを生成し、送信部１１３に供給する。

【0060】

送信部１１３は、ストリーム生成部１１２から供給されるストリームに対して、例えばデジタル変調等の処理を施して、アンテナ１１７を介して、デジタル放送信号として送信する。

【0061】

ここで、緊急時においては、CAP情報提供装置１１からの拡張CAP情報が、送信装置１０に送信される。図８において、CAP情報提供装置１１は、音声発話メタデータ生成部１３１、CAP情報生成部１３２、及び、送信部１３３から構成される。

【0062】

音声発話メタデータ生成部１３１は、緊急時に、例えば緊急情報の制作者等からの指示に従い、音声発話メタデータを生成して、CAP情報生成部１３２に供給する。なお、音声発話メタデータとしては、例えば、テキスト情報の読み方が一意に定まらない場合にその音声の読み方を示した情報や、発音が難解な固有名詞等である場合にその音素情報が生成される。

【0063】

CAP情報生成部１３２は、緊急時において、緊急情報源から伝達されてくる緊急情報源情報に基づいて、拡張CAP情報を生成し、送信部１３３に供給する。ここでは、例えば、CAP情報生成部１３２によって、緊急情報のメッセージを含むCAP情報に、音声発話メタデータ生成部１３１から供給される音声発話メタデータが格納(配置)されることで、拡張CAP情報が生成される。送信部１３３は、音声発話メタデータを含む拡張CAP情報を、送信装置１０に送信する。

【0064】

送信装置１０において、CAP情報取得部１１４は、緊急時に、CAP情報提供装置１１から送信されてくる拡張CAP情報を取得(受信)する。CAP情報取得部１１４は、拡張CAP情報を、ストリーム生成部１１２、TTSエンジン１１５、又は緊急情報フォーマット変換部１１６に供給する。

【0065】

ここで、先に述べた通り、連邦通信委員会(FCC)の規制に対応するためには、上述した第１の方式乃至第３の方式のうちのいずれかの方式を用いて、緊急情報のメッセージの音声に関する情報を送信する必要がある。

【0066】

具体的には、第１の方式を採用する場合、CAP情報取得部１１４からの拡張CAP情報は、ストリーム生成部１１２とTTSエンジン１１５に供給される。TTSエンジン１１５は、拡張CAP情報に含まれる音声発話メタデータに基づいて、拡張CAP情報に含まれるメッセージをデコードする(読み上げる)ことで得られる音声情報(音声に関する情報)を、緊急情報としてストリーム生成部１１２に供給する。この場合、TTSエンジン１１５が、音声発話メタデータに従い、テキスト情報を読み上げることになるため、確実に、制作者が意図した通りに読み上げられることになる。

【0067】

そして、ストリーム生成部１１２は、CAP情報取得部１１４からの拡張CAP情報に含まれるメッセージが重畳された映像のコンテンツデータ等を含むストリームに、TTSエンジン１１５からの音声情報をさらに多重化して、ATSCの規定に準拠したストリームを生成する。

【0068】

また、第２の方式を採用する場合、CAP情報取得部１１４からの拡張CAP情報は、緊急情報フォーマット変換部１１６に供給される。緊急情報フォーマット変換部１１６は、拡張CAP情報を、ATSC(例えばATSC3.0)で規定される所定のフォーマットに準拠した形式に変換して、それにより得られる、メッセージとその音声発話メタデータ(音声に関する情報)を含むATSCシグナリング情報を、緊急情報として、ストリーム生成部１１２に供給する。そして、ストリーム生成部１１２は、緊急情報フォーマット変換部１１６から供給される緊急情報を、コンテンツデータやシグナリングデータなどとともに多重化して、ATSCの規定に準拠したストリームを生成する。

【0069】

また、第３の方式を採用する場合、CAP情報取得部１１４からの拡張CAP情報(メッセージとその音声発話メタデータ(音声に関する情報)を含む拡張CAP情報)は、そのままの形式で、緊急情報として、ストリーム生成部１１２に供給される。そして、ストリーム生成部１１２は、CAP情報取得部１１４から供給される緊急情報を、コンテンツデータやシグナリングデータなどとともに多重化して、ATSCの規定に準拠したストリームを生成する。

【0070】

送信部１１３は、緊急時に、ストリーム生成部１１２から供給される、緊急情報を含むストリームを、アンテナ１１７を介して、デジタル放送信号として送信する。

【0071】

なお、図８の送信装置１０は、図１の放送局(Station)とローカル放送局(Local Broadcast)に相当するが、例えば、緊急情報に関する処理は、図１の放送局側で行われる処理であり、受信装置２０に対してデジタル放送信号を送信する処理は、図１のローカル放送局側で行われる処理である。ただし、図８の送信装置１０で行われる処理が、図１の放送局側又はローカル放送局側で行われるかどうかによって、本技術の内容が限定されるものではない。

【0072】

また、図８の送信装置１０とCAP情報提供装置１１においては、すべての機能ブロックが、単一の装置内に配置される必要はなく、少なくとも一部の機能ブロックが他の機能ブロックとは独立した装置として構成されるようにしてもよい。例えば、音声発話メタデータ生成部１３１やCAP情報生成部１３２は、インターネット５０上のサーバ（例えばサーバ４０）の機能として提供されるようにしてもよい。その場合、送信装置１０やCAP情報提供装置１１は、当該サーバから提供される音声発話メタデータやCAP情報(拡張CAP情報)を取得して処理することになる。

【0073】

（受信側の構成例）
図９は、図７の受信側の受信装置２０の構成例を示す図である。

【0074】

図９において、受信装置２０は、受信部２１２、ストリーム分離部２１３、再生部２１４、表示部２１５、スピーカ２１６、緊急情報取得部２１７、音声発話メタデータ取得部２１８、TTSエンジン２１９、及び、通信部２２０から構成される。

【0075】

受信部２１２は、アンテナ２１１で受信されたデジタル放送信号に対して復調処理等を行い、それにより得られるストリームを、ストリーム分離部２１３に供給する。ストリーム分離部２１３は、受信部２１２から供給されるストリームから、シグナリングデータとコンテンツデータを分離して、再生部２１４に供給する。

【0076】

再生部２１４は、ストリーム分離部２１３により分離されたシグナリングデータに基づいて、ストリーム分離部２１３から供給されるコンテンツデータの映像を表示部２１５に表示させるとともに、コンテンツデータの音声をスピーカ２１６から出力させる。これにより、放送番組等のコンテンツの再生が行われる。

【0077】

また、緊急時において、ストリーム分離部２１３は、受信部２１２から供給されるストリームから、コンテンツデータなどと、拡張CAP情報を分離して、コンテンツデータを再生部２１４に、拡張CAP情報を緊急情報取得部２１７にそれぞれ供給する。ここで、緊急時においては、上述した送信側で採用される第１の方式乃至第３の方式に対応した処理が行われる。

【0078】

具体的には、第１の方式を採用した場合、ストリーム分離部２１３により分離されるストリームに含まれるコンテンツデータの映像には、緊急情報のメッセージが重畳されているので、再生部２１４は、メッセージ(の字幕)を、表示部２１５に表示させる。また、ストリーム分離部２１３により分離されるストリームには、緊急情報のメッセージの音声情報(音声に関する情報)が含まれているので、再生部２１４は、当該音声情報に対応する音声を、スピーカ２１６から出力する。

【0079】

なお、この音声情報は、送信側の送信装置１０において、拡張CAP情報に含まれる音声発話メタデータに従い、TTSエンジン１１５が、メッセージをデコードした(読み上げた)ものとなるので、表示部２１５に表示されているメッセージ(の字幕)は、制作者が意図した通りに読み上げられることになる。

【0080】

また、第２の方式を採用した場合、緊急情報取得部２１７は、ストリーム分離部２１３により分離された緊急情報(ATSCシグナリング情報)を取得する。緊急情報取得部２１７は、ATSCシグナリング情報を処理して、緊急情報のメッセージを、再生部２１４に供給する。再生部２１４は、緊急情報取得部２１７から供給されるメッセージ(の字幕)を、表示部２１５に表示させる。

【0081】

緊急情報取得部２１７は、ATSCシグナリング情報に含まれる音声発話メタデータを、音声発話メタデータ取得部２１８に供給する。音声発話メタデータ取得部２１８は、緊急情報取得部２１７から供給される音声発話メタデータを取得して処理する。

【0082】

ここで、音声発話メタデータには、音声発話メタデータを取得するためのアドレス情報を記述したものと、音声発話メタデータの内容そのものを記述したものの２種類が存在するのは、先に述べた通りである。

【0083】

すなわち、音声発話メタデータ取得部２１８は、音声発話メタデータがその内容を含んでいる場合には、当該音声発話メタデータをそのまま、TTSエンジン２１９に供給する。一方、音声発話メタデータ取得部２１８は、音声発話メタデータにアドレス情報が含まれている場合、通信部２２０を制御して、当該アドレス情報(例えばURL)に従い、インターネット５０を介してサーバ４０にアクセスし、音声発話メタデータファイルを取得する。音声発話メタデータ取得部２１８は、音声発話メタデータファイルから得られる内容を含んでいる音声発話メタデータをTTSエンジン２１９に供給する。

【0084】

TTSエンジン２１９は、音声発話メタデータ取得部２１８から供給される音声発話メタデータに基づいて、ATSCシグナリング情報に含まれるメッセージを読み上げて、その音声を、スピーカ２１６から出力する。この音声は、表示部２１５に表示されているメッセージ(の字幕)に対応した音声であって、音声発話メタデータに従い、TTSエンジン２１９が読み上げたものとなるので、制作者が意図した通りに読み上げられることになる。

【0085】

また、第３の方式を採用した場合、緊急情報取得部２１７は、ストリーム分離部２１３により分離された緊急情報(拡張CAP情報)を取得する。緊急情報取得部２１７は、拡張CAP情報を処理して、緊急情報のメッセージを再生部２１４に供給する。再生部２１４は、緊急情報取得部２１７から供給されるメッセージ(の字幕)を、表示部２１５に表示させる。

【0086】

また、緊急情報取得部２１７は、拡張CAP情報に含まれる音声発話メタデータを、音声発話メタデータ取得部２１８に供給する。音声発話メタデータ取得部２１８は、緊急情報取得部２１７から供給される音声発話メタデータを取得して処理する。

【0087】

音声発話メタデータ取得部２１８は、音声発話メタデータがその内容を含んでいる場合には、当該音声発話メタデータをそのまま、TTSエンジン２１９に供給する。一方、音声発話メタデータ取得部２１８は、音声発話メタデータにアドレス情報(例えばURL)が含まれている場合には、通信部２２０を制御して、インターネット５０上のサーバ４０から音声発話メタデータファイルを取得し、そこから得られる内容を含んでいる音声発話メタデータをTTSエンジン２１９に供給する。

【0088】

TTSエンジン２１９は、音声発話メタデータ取得部２１８から供給される音声発話メタデータに基づいて、拡張CAP情報に含まれるメッセージを読み上げて、その音声を、スピーカ２１６から出力する。この音声は、表示部２１５に表示されているメッセージ(の字幕)に対応した音声であって、音声発話メタデータに従い、TTSエンジン２１９が読み上げたものとなるので、制作者が意図した通りに読み上げられることになる。

【0089】

例えば、第２の方式と第３の方式においては、図２Ａや図２Ｂなどの緊急情報のメッセージ(の字幕)が表示部２１５に表示されている場合において、視覚障がい者に対してアクセシブルにするために、そのメッセージを読み上げるに際して、テキスト情報の読み方が一意に定まらないときなどに、TTSエンジン２１９は、音声発話メタデータに従い、テキスト情報が、制作者の意図した通りに読み上げられるようにする。これにより、視覚障がい者が、健常者と同等の情報を得られるようになる。

【0090】

なお、図９の受信装置２０においては、表示部２１５とスピーカ２１６が内部に設けられている構成を示したが、例えば受信装置２０がセットトップボックスや録画機などである場合には、表示部２１５とスピーカ２１６は、外部の別の装置として設けられるようにしてもよい。

【0091】

＜３．CAP情報の拡張による音声発話メタデータの配置＞

【0092】

（CAPの構造）
図１０は、CAP情報の構造の例を示す図である。なお、このCAP情報は、構造化情報標準促進協会(OASIS)により策定されたものである。また、CAP情報は、緊急情報源情報の一例である。

【0093】

図１０に示すように、CAP情報は、alertセグメント、infoセグメント、resourceセグメント、及び、areaセグメントから構成される。なお、alertセグメントには、１以上のinfoセグメントを含めることができる。また、resourceセグメントとareaセグメントを、infoセグメントに含めるかどうかは任意である。

【0094】

alertセグメントにおいて、alert要素は、その子要素として、identifier要素、sender要素、sent要素、status要素、msgType要素、source要素、scope要素、restriction要素、addresses要素、code要素、note要素、references要素、及び、incidents要素を有している。

【0095】

alert要素には、CAP情報に関する基本的な情報が記述される。すなわち、alert要素は、CAP情報を構成する全てのコンポーネントのコンテナとなる。なお、alert要素は、必須の要素とされる。

【0096】

identifier要素は、CAP情報を識別するためのIDが指定される。sender要素は、CAP情報の提供者を識別するIDが指定される。sent要素は、CAP情報の提供日時が指定される。status要素は、CAP情報の取り扱いを示すコードが指定される。このstatus要素のコードとしては、"Actual"，"Exercise"，"System"，"Test"，"Draft"が指定される。

【0097】

msgType要素は、CAP情報のタイプを示すコードが指定される。このmsgType要素のコードとしては、"Alert"，"Update"，"Cancel"，"Ack"，"Error"が指定される。source要素は、CAP情報のソースを示す情報が指定される。scope要素は、CAP情報の範囲を示すコードが指定される。このscope要素のコードとしては、"Public"，"Restricted"，"Private"が指定される。

【0098】

restriction要素は、制限されたCAP情報の配布を制限するための規則が指定される。addresses要素は、CAP情報を受信するユーザのグループのリストが指定される。code要素は、CAP情報の特別な処理を表すコードが指定される。note要素は、CAP情報の目的や意義を説明する情報が指定される。references要素は、CAP情報の参照先のメッセージに関する情報が指定される。incidents要素は、CAP情報の命名規則に関する情報が指定される。

【0099】

infoセグメントにおいて、info要素は、その子要素として、language要素、category要素、event要素、responseType要素、urgency要素、severity要素、certainty要素、audience要素、eventCode要素、effective要素、onset要素、expires要素、senderName要素、headline要素、description要素、instruction要素、web要素、contact要素、及び、parameter要素を有している。

【0100】

info要素は、CAP情報に関する実体的な情報が記述される。すなわち、info要素は、CAP情報のinfo要素を構成する全てのコンポーネント(子要素)のコンテナとなる。なお、info要素は、オプショナルな要素とされるが、ほとんどのalert要素には、少なくとも１つのinfo要素が含まれている。

【0101】

language要素は、CAP情報のサブ要素の言語を表すコードが指定される。なお、この言語コードとしては、RFC 3066に規定されたコードが参照されることになる。category要素は、CAP情報のカテゴリを示すコードが指定される。このcategory要素のコードとしては、"Geo(Geophysical)"，"Met(Meteorological)"，"Safety"，"Security"，"Rescue"，"Fire"，"Health"，"Env(Pollution and other environmental)"，"Transport(Public and private transportation)"，"Infra(Utility, telecommunication, other non-transport infrastructure)"，"CBRNE(Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack)"，"Other"が指定される。

【0102】

event要素は、CAP情報のイベントのタイプを示す情報が指定される。responseType要素は、ユーザに推奨される行動を表すコードが指定される。このresponseType要素のコードとしては、"Shelter"，"Evacuate"，"Prepare"，"Execute"，"Avoid"，"Monitor"，"Assess"，"All Clear"，"None"が指定される。urgency要素は、CAP情報の緊急度を表すコードが指定される。このurgency要素のコードとしては、"Immediate"，"Expected"，"Future"，"Past"，"Unknown"が指定される。

【0103】

severity要素は、CAP情報の深刻度を表すコードが指定される。このseverity要素のコードとしては、"Extreme"，"Severe"，"Moderate"，"Minor"，"Unknown"が指定される。certainty要素は、CAP情報の確実性を表すコードが指定される。このcertainty要素のコードとしては、"Observed"，"Likely"，"Possible"，"Unlikely"，"Unknown"が指定される。

【0104】

audience要素は、CAP情報の対象となるユーザを説明する情報が指定される。eventCode要素は、CAP情報のイベントのタイプを識別するシステム固有の識別子が指定される。effective要素は、CAP情報の内容の有効期間を示す情報が指定される。onset要素は、CAP情報のイベントの開始予定時刻を示す情報が指定される。expires要素は、CAP情報の内容の有効期限を示す情報が指定される。

【0105】

senderName要素は、CAP情報の提供者の名称を示す情報(テキスト情報)が指定される。headline要素は、CAP情報の内容の見出しを示す情報(テキスト情報)が指定される。description要素は、CAP情報の内容の詳細を示す情報(テキスト情報)が指定される。instruction要素は、CAP情報を確認したユーザがとるべき行動(推奨される行動)を示す情報(テキスト情報)が指定される。

【0106】

web要素は、CAP情報の追加情報の取得先を示すURLが指定される。contact要素は、CAP情報のフォローアップや確認の連絡先を示す情報が指定される。parameter要素は、CAP情報に関連付けられる追加のパラメータが指定される。

【0107】

resourceセグメントにおいて、resource要素は、その子要素として、resourceDesc要素、mimeType要素、size要素、uri要素、derefUri要素、及び、digest要素を有している。

【0108】

resource要素は、info要素に記述される情報に関連する追加情報として、画像や音声ファイル等のリソースファイルを提供する。すなわち、resource要素は、CAP情報のresource要素を構成する全てのコンポーネント(子要素)のコンテナとなる。なお、resource要素は、オプショナルな要素とされる。

【0109】

resourceDesc要素は、リソースファイルの種類と内容を示す情報(テキスト情報)が指定される。mimeType要素は、リソースファイルのMIMEタイプが指定される。なお、このMIMEタイプとしては、RFC 2046に規定されたタイプが参照されることになる。

【0110】

size要素は、リソースファイルのサイズを示す値が指定される。uri要素は、リソースファイルの取得先のURI(Uniform Resource Identifier)が指定される。derefUri要素は、Base64で符号化されたリソースファイルに関する情報が指定される。digest要素は、リソースファイルから求められるハッシュ値を表すコードが指定される。

【0111】

areaセグメントにおいて、area要素は、その子要素として、areaDesc要素、polygon要素、circle要素、geocode要素、altitude要素、及び、ceiling要素を有している。

【0112】

area要素は、info要素に記述される情報に関連する地域的範囲に関する情報を提供する。すなわち、area要素は、CAP情報のarea要素を構成する全てのコンポーネント(子要素)のコンテナとなる。なお、area要素は、オプショナルな要素とされる。

【0113】

areaDesc要素は、CAP情報の影響を受ける地域に関する情報が指定される。polygon要素は、CAP情報の影響を受ける地域をポリゴンにより定義した情報が指定される。circle要素は、CAP情報の影響を受ける地域を半径(radius)により定義した情報が指定される。geocode要素は、CAP情報の影響を受ける地域を地域コード(位置情報)により定義した情報が指定される。

【0114】

altitude要素は、CAP情報の影響を受ける地域の特定の高度又は最低の高度を示す情報が指定される。ceiling要素は、CAP情報の影響を受ける地域の最高の高度を示す情報が指定される。

【0115】

（CAP情報の記述例）
ここで、図１１には、XML(Extensible Markup Language)文書として記述されるCAP情報の記述例が示されている。図１１のalert要素内のinfo要素において、senderName要素には、CAP情報の提供者の名称が記述され、headline要素には、CAP情報の内容の見出しが記述され、description要素には、CAP情報の内容の詳細が記述されている。また、alert要素内のinfo要素のinstruction要素には、CAP情報を確認したユーザがとるべき行動(推奨される行動)を示す情報が記述されている。

【0116】

ここで、受信装置２０においては、これらのテキスト情報を表示する際には、視覚障がい者に対してアクセシブルにするために、TTSエンジンにより読み上げる必要があるが、例えば、テキスト情報の読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合に、制作者が意図した通りにテキスト情報が読み上げられない可能性があることは、先に述べた通りである。

【0117】

そして、本技術では、音声発話メタデータをTTSエンジンに提供することで、制作者が意図した通りにテキスト情報が読み上げられるようにするが、この音声発話メタデータは、CAP情報を拡張して格納(配置)されるようにしている。以下、音声発話メタデータが配置されたCAP情報(拡張CAP情報)の詳細な構成について説明する。

【0118】

（拡張CAP情報の構成例）
図１２は、音声発話メタデータ又はその取得先を示すアドレス情報を格納するために拡張CAP情報で追加される要素と属性の例を示す図である。なお、図１２の拡張CAP情報で追加される要素や属性は、例えば、info要素のsenderName要素、headline要素、description要素、及び、instruction要素などの要素が対象とされる。

【0119】

すなわち、拡張CAP情報においては、これらのsenderName要素、headline要素、description要素、又は、instruction要素などの子要素として、SpeechInfoURI要素又はSpeechInfo要素を追加する拡張が行われるようにする。

【0120】

SpeechInfoURI要素は、音声発話メタデータを取得するためのアドレス情報が指定される。このアドレス情報としては、例えば、URIが指定される。また、例えば、音声発話メタデータファイルが、インターネット５０上のサーバ４０から取得される場合には、サーバ４０にアクセスするためのURLが、アドレス情報として指定される。

【0121】

なお、音声発話メタデータは、音声合成マークアップ言語である、SSML(Speech Synthesis Markup Language)により記述することができる。このSSMLは、W3C(World Wide Web Consortium)によって、より高品質な音声合成機能を利用可能にすることを目的として勧告されたものである。SSMLを用いることで、発音や音量、調子など、音声合成に必要な要素をきめ細かく、かつ適度に制御することが可能となる。

【0122】

Content-type属性と、Content-enc属性は、SpeechInfoURI要素とペアで使用される。Content-type属性は、URI等のアドレス情報を参照することで取得される音声発話メタデータの種別を示すタイプ情報が指定される。また、Content-enc属性は、アドレス情報を参照することで取得される音声発話メタデータの符号化方式を示す情報が指定される。

【0123】

SpeechInfo要素は、音声発話メタデータの内容そのものが記述される。例えば、この音声発話メタデータの内容は、SSMLで記述される。また、SpeechInfo要素にも、ペアで使用されるContent-type属性と、Content-enc属性が指定可能である。Content-type属性は、SpeechInfo要素に記述される音声発話メタデータの種別を示すタイプ情報が指定される。また、Content-enc属性は、SpeechInfo要素に記述される音声発話メタデータの符号化方式を示す情報が指定される。

【0124】

なお、図１２において、出現数(Cardinality)であるが、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。また、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。したがって、SpeechInfoURI要素とSpeechInfo要素は、オプショナルな要素であって、SpeechInfoURI要素とSpeechInfo要素は、一方の要素のみが配置されるだけでなく、その両方の要素が配置されるようにしてもよい。また、SpeechInfoURI要素及びSpeechInfo要素に付随するContent-type属性とContent-enc属性を配置するかどうかも任意である。

【0125】

（XMLスキーマの記述例）
図１３は、XML文書(XMLインスタンス)としての拡張CAP情報の構造を定義するXMLスキーマ(CAPのXMLスキーマ)の記述例を示す図である。

【0126】

図１３においては、ComplexType要素により要素の型定義を行っている。すなわち、xsd:sequence要素の内容(開始タグと終了タグの間の内容)に、追加する子要素と属性を指定するための型として、"XXXXType"を定義している。

【0127】

３行目のxs:element要素のname属性には、"SpeechInfoURI"が指定されており、SpeechInfoURI要素が宣言されている。このSpeechInfoURI要素は、minOccurs属性により最低出現回数が"0"であることと、maxOccurs属性により最高出現回数に制限がないことが宣言されている。

【0128】

７行目のattribute要素のname属性には、"content-type"が指定されており、SpeechInfoURI要素の属性として、Content-type属性が宣言されている。このContent-type属性は、type属性により文字列型(String)であることと、use属性によりオプショナルな属性であることが宣言されている。

【0129】

８行目のattribute要素のname属性には、"content-enc"が指定されており、SpeechInfoURI要素の属性として、Content-enc属性が宣言されている。このContent-enc属性は、type属性により文字列型(String)であることと、use属性によりオプショナルな属性であることが宣言されている。

【0130】

１３行目のxs:element要素のname属性には、"SpeechInfo"が指定されており、SpeechInfo要素が宣言されている。このSpeechInfo要素は、minOccurs属性により最低出現回数が"0"であることと、maxOccurs属性により最高出現回数に制限がないことが宣言されている。

【0131】

１７行目のattribute要素のname属性には、"content-type"が指定されており、SpeechInfo要素のContent-type属性が宣言されている。このContent-type属性は、type属性により文字列型(String)であることと、use属性によりオプショナルな属性であることが宣言されている。

【0132】

１８行目のattribute要素のname属性には、"content-enc"が指定されており、SpeechInfo要素のContent-enc属性が宣言されている。このContent-enc属性は、type属性により文字列型(String)であることと、use属性によりオプショナルな属性であることが宣言されている。

【0133】

（XMLスキーマの名前空間の指定）
また、XMLスキーマの名前空間の指定であるが、例えば、図１４のXMLスキーマのように記述することができる。なお、図１４のXMLスキーマにおいて、ComplexType要素により定義される要素の型を記述する領域５０には、上述した図１３のComplexType要素の内容(開始タグと終了タグの間の内容)が記述される。

【0134】

図１４において、schema要素のtargetNamespace属性により、当該XMLスキーマが、拡張CAP情報の構造を定義していることが指定されている。ここでは、現状のCAP情報(拡張していないCAP情報)の名前空間(Namespace)が、"urn:oasis:names:tc:emergency:cap:1.2"で表される場合に、本技術で提案する拡張CAP情報の名前空間が、"urn:oasis:names:tc:emergency:cap:1.3"で定義されるものとする。また、"xmlns:cap"により、拡張CAP情報として用いられるXMLスキーマの名前空間接頭辞が、「cap」であることを宣言している。

【0135】

また、図１４においては、element要素により、alert要素、info要素、resource要素、及び、area要素などの要素が宣言される。また、element要素では、senderName要素、headline要素、description要素、及び、instruction要素が宣言されている。

【0136】

ここで、senderName要素には、type属性として、"cap:XXXXType"が指定されており、senderName要素に付随する要素や属性などの内容は、当該XMLスキーマのComplexType要素で定義された"XXXXType"の型により指定されることを意味している。

【0137】

図１４のXMLスキーマにおいては、ComplexType要素により定義される要素の型を記述する領域５０に、上述した図１３のComplexType要素の内容が記述されているので、senderName要素には、その子要素として、SpeechInfoURI要素又はSpeechInfo要素を指定することが可能となる。また、SpeechInfoURI要素とSpeechInfo要素には、Content-type属性及びContent-enc属性を指定することができる。なお、element要素のminOccurs属性は、senderName要素の最低出現回数が"0"であることを表している。

【0138】

同様に、headline要素、description要素、及び、instruction要素についても、当該XMLスキーマのComplexType要素で定義された"XXXXType"の型に従い、その子要素として、SpeechInfoURI要素又はSpeechInfo要素を指定することができる。また、SpeechInfoURI要素とSpeechInfo要素には、Content-type属性及びContent-enc属性を指定することができる。

【0139】

このようなXMLスキーマを定義することで、例えば、図１１に示したCAP情報の記述例において、２行目のalert要素のxmlns属性で指定される名前空間を、"urn:oasis:names:tc:emergency:cap:1.2"から、"urn:oasis:names:tc:emergency:cap:1.3"に変更することで、図１４のXMLスキーマ(CAPのXMLスキーマ)で定義された"XXXXType"を利用することが可能となる。この場合、senderName要素、headline要素、description要素、及び、instruction要素において、SpeechInfoURI要素又はSpeechInfo要素を指定することが可能となり、いわば、CAP情報が、拡張CAP情報に拡張されたことになる。この拡張CAP情報の記述例を、図１５に示している。

【0140】

以上のようにして、info要素のsenderName要素、headline要素、description要素、及び、instruction要素の子要素として、SpeechInfoURI要素又はSpeechInfo要素が指定されるようにすることで、これらのテキスト情報が指定される要素に対して、制作者が意図する音声の発話に関する情報としての音声発話メタデータを設定することができるようにしている。

【0141】

これにより、緊急時において、受信装置２０では、例えば、拡張CAP情報を処理することで得られる緊急情報の提供者の名称、緊急情報の内容の見出し、緊急情報の内容の詳細、又はユーザが取るべき行動を示す情報などの視認可能なメッセージ(テキスト情報)を表示する際に、音声発話メタデータに従い、制作者が意図した通りにメッセージ(テキスト情報)が読み上げられることになる。その結果、視覚障がい者は、健常者と同等の情報を得ることができるため、視覚障がい者に対するアクセシビリティを向上させることができる。

【0142】

なお、上述した説明では、SpeechInfoURI要素又はSpeechInfo要素を指定可能な要素として、info要素のsenderName要素、headline要素、description要素、及び、instruction要素を一例に説明したが、拡張CAP情報において、例えばresourceDesc要素などのメッセージ(テキスト情報)が指定される要素や属性であれば、それらの要素や属性のメッセージ(テキスト情報)が読み上げられる対象とされるようにしてもよい。

【0143】

＜４．各装置で実行される処理の流れ＞

【0144】

次に、図７の放送システム１を構成する送信装置１０と受信装置２０で実行される処理の流れを説明する。

【0145】

（送信処理）
まず、図１６のフローチャートを参照して、図７の送信装置１０により実行される、送信処理の流れを説明する。ただし、図１６の送信処理は、送信装置１０において、緊急時となる場合に、CAP情報提供装置１１からの拡張CAP情報が送信されてきたときの処理とされる。

【0146】

ステップＳ１１１において、CAP情報取得部１１４は、CAP情報提供装置１１から送信されてくる拡張CAP情報を取得(受信)する。

【0147】

ステップＳ１１２においては、上述した第１の方式乃至第３の方式のいずれかの方式に応じて、ステップＳ１１１の処理で取得された拡張CAP情報が処理される。

【0148】

具体的には、第１の方式を採用する場合、TTSエンジン１１５は、ステップＳ１１１の処理で取得された拡張CAP情報に含まれる音声発話メタデータに基づいて、拡張CAP情報に含まれるメッセージをデコードする(読み上げる)ことで得られる音声情報(音声に関する情報)を、緊急情報としてストリーム生成部１１２に供給する。ストリーム生成部１１２は、拡張CAP情報に含まれるメッセージが重畳された映像のコンテンツデータ等を含むストリームに、TTSエンジン１１５からの音声情報をさらに多重化して、ATSCの規定に準拠したストリームを生成する。

【0149】

また、第２の方式を採用する場合、緊急情報フォーマット変換部１１６は、ステップＳ１１１の処理で取得された拡張CAP情報を、ATSCで規定される所定のフォーマット形式に変換して、それにより得られる、メッセージとその音声発話メタデータ(音声に関する情報)を含むATSCシグナリング情報を、緊急情報としてストリーム生成部１１２に供給する。ストリーム生成部１１２は、緊急情報フォーマット変換部１１６から供給される緊急情報を、コンテンツデータやシグナリングデータなどとともに多重化して、ATSCの規定に準拠したストリームを生成する。

【0150】

また、第３の方式を採用する場合、CAP情報取得部１１４は、ステップＳ１１１の処理で取得された拡張CAP情報(メッセージとその音声発話メタデータ(音声に関する情報)を含む拡張CAP情報)を、そのままの形式で、緊急情報としてストリーム生成部１１２に供給する。ストリーム生成部１１２は、CAP情報取得部１１４から供給される緊急情報を、コンテンツデータやシグナリングデータなどとともに多重化して、ATSCの規定に準拠したストリームを生成する。

【0151】

ステップＳ１１３において、送信部１１３は、ステップＳ１１２の処理で拡張CAP情報を処理することで得られる緊急情報(を含むストリーム)を、アンテナ１１７を介して、デジタル放送信号として送信する。

【0152】

なお、ステップＳ１１１の処理で取得される拡張CAP情報に含まれる音声発話メタデータに、その内容が記述されていない場合には、音声発話メタデータファイルを取得するためのアドレス情報として、インターネット５０上のサーバ４０にアクセスするためのURLが記述されることになる。

【0153】

以上、緊急時の送信処理の流れについて説明した。この送信処理では、拡張CAP情報に含まれる、制作者が意図する音声の発話に関する音声発話メタデータに応じた音声情報、又は音声発話メタデータを含むATSCシグナリング情報若しくは拡張CAP情報が、緊急情報として送信される。

【0154】

これにより、受信側の受信装置２０では、音声発話メタデータに応じた音声情報に対応した音声を出力するか、又は、音声発話メタデータに従ってメッセージを読み上げるので、例えば、緊急情報のメッセージの読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などであっても、確実に、制作者が意図した通りにテキスト情報が読み上げられる。その結果、視覚障がい者が、健常者と同等の情報(緊急情報)を得られるようになる。

【0155】

（受信処理）
次に、図１７のフローチャートを参照して、図７の受信装置２０により実行される、受信処理の流れを説明する。ただし、図１７の受信処理は、ユーザにより選局された放送番組等のコンテンツを再生中に、緊急時となって、送信装置１０から送信されてくる緊急情報を受信したときの処理とされる。

【0156】

ステップＳ２１１において、緊急情報取得部２１７は、緊急時に、ストリーム分離部２１３から供給される緊急情報を受信(取得)する。

【0157】

ステップＳ２１２においては、上述した送信側で採用される第１の方式乃至第３の方式のいずれかの方式に応じて、ステップＳ２１１の処理で取得された緊急情報が処理される。また、ステップＳ２１３においては、ステップＳ２１２の処理での緊急情報の処理結果に応じて、緊急情報が出力される。

【0158】

具体的には、第１の方式を採用した場合、ストリーム分離部２１３により分離されるストリームに含まれるコンテンツデータの映像には、緊急情報として、緊急情報のメッセージが重畳されているので、再生部２１４は、メッセージ(の字幕)を、表示部２１５に表示させる（Ｓ２１２，Ｓ２１３）。また、ストリーム分離部２１３により分離されるストリームには、緊急情報のメッセージの音声情報(音声に関する情報)が含まれているので、再生部２１４は、当該音声情報に対応する音声を、スピーカ２１６から出力する（Ｓ２１２，Ｓ２１３）。

【0159】

また、第２の方式を採用した場合、緊急情報として、ATSCシグナリング情報が取得されるので、緊急情報取得部２１７は、ATSCシグナリング情報を処理して、緊急情報のメッセージを、再生部２１４に供給する。再生部２１４は、緊急情報取得部２１７から供給される緊急情報のメッセージ(の字幕)を、表示部２１５に表示させる（Ｓ２１２，Ｓ２１３）。

【0160】

一方で、緊急情報取得部２１７は、ATSCシグナリング情報に含まれる音声発話メタデータを、音声発話メタデータ取得部２１８に供給する。音声発話メタデータ取得部２１８は、緊急情報取得部２１７から供給される音声発話メタデータを取得して処理する（Ｓ２１２）。そして、TTSエンジン２１９は、音声発話メタデータ取得部２１８から供給される音声発話メタデータに基づいて、ATSCシグナリング情報に含まれるメッセージを読み上げて、その音声を、スピーカ２１６から出力する（Ｓ２１３）。

【0161】

また、第３の方式を採用した場合、緊急情報として、拡張CAP情報が取得されるので、緊急情報取得部２１７は、拡張CAP情報を処理して、緊急情報のメッセージを、再生部２１４に供給する。再生部２１４は、緊急情報取得部２１７から供給される緊急情報のメッセージ(の字幕)を、表示部２１５に表示させる（Ｓ２１２，Ｓ２１３）。

【0162】

一方で、緊急情報取得部２１７は、拡張CAP情報に含まれる音声発話メタデータを、音声発話メタデータ取得部２１８に供給する。音声発話メタデータ取得部２１８は、緊急情報取得部２１７から供給される音声発話メタデータを取得して処理する（Ｓ２１２）。そして、TTSエンジン２１９は、音声発話メタデータ取得部２１８から供給される音声発話メタデータに基づいて、拡張CAP情報に含まれるメッセージを読み上げて、その音声を、スピーカ２１６から出力する（Ｓ２１３）。

【0163】

なお、第２の方式と第３の方式において、ステップＳ２１１の処理で取得される緊急情報(ATSCシグナリング情報又は拡張CAP情報)に含まれる音声発話メタデータに、その内容が記述されていない場合には、音声発話メタデータファイルを取得するためのアドレス情報が記述されている。この場合、音声発話メタデータ取得部２１８は、通信部２２０を制御して、当該アドレス情報(例えばURL)に従い、インターネット５０を介してサーバ４０にアクセスし、音声発話メタデータファイルを取得し、そこから得られる内容を含んでいる音声発話メタデータをTTSエンジン２１９に供給する。

【0164】

以上、緊急時の受信処理の流れについて説明した。この受信処理では、送信側の送信装置１０から送信されてくる、制作者が意図する音声の発話に関する音声発話メタデータに応じた音声情報、又は音声発話メタデータを含むATSCシグナリング情報若しくは拡張CAP情報が、緊急情報として受信される。

【0165】

これにより、受信装置２０では、音声発話メタデータに応じた音声情報に対応した音声を出力するか、又は、音声発話メタデータに従ってメッセージを読み上げるので、例えば、緊急情報のメッセージの読み方が一意に定まらない場合や、発音が難解な固有名詞等である場合などであっても、確実に、制作者が意図した通りにテキスト情報が読み上げられる。その結果、視覚障がい者が、健常者と同等の情報(緊急情報)を得られるようになる。

【0166】

＜５．変形例＞

【0167】

上述した説明としては、デジタルテレビ放送の規格として、米国等で採用されている方式であるATSC(例えばATSC3.0)を説明したが、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、伝送路３０(図７)としては、地上デジタルテレビ放送に限らず、衛星デジタルテレビ放送やデジタル有線テレビ放送などで採用するようにしてもよい。

【0168】

また、上述した説明では、CAP情報提供装置１１により拡張CAP情報が生成されるとして説明したが、CAP情報提供装置１１に限らず、例えば、送信装置１０やサーバ４０等が、緊急情報源伝達されてくる緊急情報源情報に基づいて、拡張CAP情報を生成するようにしてもよい。なお、送信側の送信装置１０において、拡張CAP情報を処理する際に、音声発話メタデータに音声発話メタデータファイルを取得するためのアドレス情報が記述されている場合には、当該アドレス情報(例えばURL)に従い、インターネット５０を介してサーバ４０にアクセスし、音声発話メタデータファイルを取得するようにしてもよい。

【0169】

さらにまた、上述した説明では、緊急情報源情報として、米国で運用されているCAP方式の情報が伝達される場合を説明したが、CAP方式の情報に限らず、他のフォーマットの緊急情報源情報を利用するようにしてもよい。例えば、日本や欧州の各国でも、視覚障がい者に対するアクセシビリティが求められることが想定されるが、その場合には、CAP情報(拡張CAP情報)ではなく、その国に適合した他のフォーマットの緊急情報源情報が用いられるようにすることができる。

【0170】

また、上述した説明では、音声発話メタデータにアドレス情報(例えばURL)が含まれている場合には、インターネット５０上のサーバ４０から音声発話メタデータファイルが取得されるとして説明したが、音声発話メタデータファイルは、デジタル放送信号に含めて送信されるようにしてもよい。すなわち、音声発話メタデータファイルは、放送経由又は通信経由で配信され、受信装置２０により受信されることになる。ここで、音声発話メタデータファイルが放送経由で配信される場合には、例えば、ROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送されるようにすることができる。なお、ROUTEは、バイナリファイルを一方向でマルチキャスト転送するのに適したプロトコルであるFLUTE(File Delivery over Unidirectional Transport)を拡張したプロトコルである。

【0171】

さらに、上述した説明では、音声発話メタデータは、SSMLにより記述されるとして説明したが、SSMLに限らず、他のマークアップ言語により記述されるようにしてもよい。ただし、音声発話メタデータをSSMLにより記述する場合には、SSMLで規定されているsub要素、phoneme要素、又はaudio要素などの要素や属性を用いることができる。なお、W3Cにより勧告されているSSMLの詳細な内容については、下記のウェブサイトに公開されている。

【0172】

Speech Synthesis Markup Language (SSML) Version 1.1，W3C Recommendation 7 September 2010，URL："http://www.w3.org/TR/speech-synthesis11/"

【0173】

また、上述した説明では、受信装置２０は、テレビ受像機やセットトップボックス、録画機などの固定受信機であるとして説明したが、受信装置２０としては、固定受信機に限らず、例えば、スマートフォンや携帯電話機、タブレット型コンピュータ、ノート型のパーソナルコンピュータ、自動車内で利用される端末などのモバイル受信機であってもよい。

【0174】

＜６．コンピュータの構成＞

【0175】

上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図１８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。

【0176】

コンピュータ９００において、CPU(Central Processing Unit)９０１，ROM(Read Only Memory)９０２，RAM(Random Access Memory)９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。

【0177】

入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。

【0178】

以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。

【0179】

コンピュータ９００(CPU９０１)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。

【0180】

コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。

【0181】

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含む。また、プログラムは、１のコンピュータ(プロセッサ)により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。

【0182】

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

【0183】

また、本技術は、以下のような構成をとることができる。

【0184】

（１）
緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を取得する緊急情報源情報取得部と、
前記緊急情報源情報を処理する処理部と、
前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られる前記メッセージの音声に関する情報を送信する送信部と
を備える送信装置。
（２）
前記メタデータは、読み方が一意に定まらない文字列、又は発音が難解な文字列の発話に関する情報を含んでいる
（１）に記載の送信装置。
（３）
前記緊急情報源情報は、前記メッセージを含み、
前記緊急情報を受信する受信装置において、前記メッセージが表示されるとともに、前記メッセージの音声に関する情報に基づいた前記メッセージに対する制作者が意図する音声の発話に応じた音声が出力される
（１）又は（２）に記載の送信装置。
（４）
コンテンツを取得するコンテンツ取得部をさらに備え、
前記送信部は、デジタル放送信号として、前記コンテンツを送信するとともに、緊急時となった場合には、前記緊急情報を送信する
（１）乃至（３）のいずれかに記載の送信装置。
（５）
前記緊急情報源情報は、
OASIS(Organization for the Advancement of Structured Information Standards)で規定されたCAP(Common Alerting Protocol)に準拠したCAP情報であり、
前記CAP情報は、前記メタデータのファイルの取得先を示すアドレス情報、又は前記メタデータの内容そのものを含む
（１）乃至（４）のいずれかに記載の送信装置。
（６）
前記緊急情報は、前記CAP情報に含まれる前記メタデータに基づいて、前記CAP情報に含まれる前記メッセージを読み上げることで得られる音声情報を含んでいる
（５）に記載の送信装置。
（７）
前記緊急情報は、前記CAP情報を、ATSC(Advanced Television Systems Committee)で規定される所定のフォーマットに準拠した形式に変換して得られる、前記メッセージと前記メタデータを含むシグナリング情報である
（５）に記載の送信装置。
（８）
前記緊急情報は、前記メッセージと前記メタデータを含む前記CAP情報である
（５）に記載の送信装置。
（９）
送信装置の送信方法において、
前記送信装置が、
緊急時において、緊急に告知する必要がある緊急情報のメッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を取得し、
前記緊急情報源情報を処理し、
前記緊急情報として、前記メッセージとともに、前記緊急情報源情報を処理して得られる前記メッセージの音声に関する情報を送信する
ステップを含む送信方法。
（１０）
緊急時において、送信装置から送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、前記メッセージの音声に関する情報を含む前記緊急情報を受信する受信部と、
前記緊急情報を処理して、前記メッセージを表示させるとともに、前記メッセージの音声に関する情報に基づいた前記メッセージに対する制作者が意図する音声の発話に応じた音声を出力させる処理部と
を備える受信装置。
（１１）
前記緊急情報は、前記メッセージと、前記メッセージに対する制作者が意図する音声の発話に関するメタデータを含む緊急情報源情報を処理することで得られる
（１０）に記載の受信装置。
（１２）
前記メタデータは、読み方が一意に定まらない文字列、又は発音が難解な文字列の発話に関する情報を含んでいる
（１１）又は（１２）に記載の受信装置。
（１３）
前記受信部は、前記送信装置から送信されてくるデジタル放送信号として、コンテンツを受信するとともに、緊急時となった場合に送信されてくる前記緊急情報を受信する
（１０）乃至（１２）のいずれかに記載の受信装置。
（１４）
前記緊急情報源情報は、
OASISで規定されたCAPに準拠したCAP情報であり、
前記CAP情報は、前記メタデータのファイルの取得先を示すアドレス情報、又は前記メタデータの内容そのものを含む
（１１）乃至（１３）のいずれかに記載の受信装置。
（１５）
前記緊急情報は、前記送信装置において、前記CAP情報に含まれる前記メタデータに基づいて、前記CAP情報に含まれる前記メッセージを読み上げることで得られた音声情報を含んでおり、
前記処理部は、前記音声情報に対応する音声を出力させる
（１４）に記載の受信装置。
（１６）
前記緊急情報は、前記CAP情報を、ATSCで規定される所定のフォーマットに準拠した形式に変換して得られるシグナリング情報であり、
前記シグナリング情報に含まれる前記メタデータに基づいて、前記シグナリング情報に含まれる前記メッセージを読み上げる音声読み上げ部をさらに備える
（１４）に記載の受信装置。
（１７）
前記緊急情報は、前記CAP情報であり、
前記CAP情報に含まれる前記メタデータに基づいて、前記CAP情報に含まれる前記メッセージを読み上げる音声読み上げ部をさらに備える
（１４）に記載の受信装置。
（１８）
受信装置の受信方法において、
前記受信装置が、
緊急時において、送信装置から送信されてくる、緊急に告知する必要がある緊急情報のメッセージと、前記メッセージの音声に関する情報を含む前記緊急情報を受信し、
前記緊急情報を処理して、前記メッセージを表示させるとともに、前記メッセージの音声に関する情報に基づいた前記メッセージに対する制作者が意図する音声の発話に応じた音声を出力させる
ステップを含む受信方法。

【符号の説明】

【0185】

１ 放送システム， １０ 送信装置， ２０ 受信装置， ３０ 伝送路， ４０ サーバ， ５０ インターネット， １１１ コンテンツ取得部， １１２ ストリーム生成部， １１３ 送信部， １１４ CAP情報取得部， １１５ TTSエンジン， １１６ 緊急情報フォーマット変換部， １３１ 音声発話メタデータ生成部， １３２ CAP情報生成部， １３３ 送信部， ２１２ 受信部， ２１３ ストリーム分離部， ２１４ 再生部， ２１５ 表示部， ２１６ スピーカ， ２１７ 緊急情報取得部， ２１８ 音声発話メタデータ取得部， ２１９ TTSエンジン， ２２０ 通信部， ９００ コンピュータ， ９０１ CPU

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】