JP2002169750A - ブラウザ搭載装置 - Google Patents

Abstract

(57)【要約】 【課題】 表示画面を見ないでも操作可能なブラウザ搭
載装置を得る。 【解決手段】 ブラウザ５１の指示で、通信手段５２を
介して、ネットワーク５８に接続し、インターネット上
のＷｅｂサーバにアクセスし、ダウンロードしたＨＴＭ
Ｌテキストを一旦記憶手段５３に格納する。音声ブラウ
ザ１は、これを読取り、最適化された読み上げ文章を構
築後、音声合成手段２に転送し、音声出力手段３を通し
て、音声出力させる。他方、使用者が発した音声は、音
声入力手段５に取込まれる。取込まれた音声は、音声認
識手段４により音声認識される。認識結果が、音声ブラ
ウザ１に対する制御指示の候補として認められる場合に
は、音声認識手段４は音声ブラウザ１に対して割込みを
行い、併せて、認識された制御指示の候補を音声ブラウ
ザ１に伝達する

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ブラウザ搭載装置
に関し、特に、ＨＴＭＬテキスト、あるいは、その応用
テキストを閲覧可能な「ブラウザ」を搭載した情報処理
機能を有するブラウザ搭載装置に関する。

【０００２】

【従来の技術】従来、ブラウザ搭載装置は、例えば、イ
ンターネットへ適用される。ここでのインターネットと
は、コンピュータ間通信のネットワークであり、様々な
ネットワークが相互に接続し、大規模なネットワークと
なったものである。その歴史は、１９６０年代に米国国
防省の関連機関であるＤＡＲＰＡ（Ｄｅｆｅｎｓｅ ｏ
ｆ Ａｄｖａｎｃｅｄ Ｒｅｓｅａｒｃｈ Ｐｒｏｊｅ
ｃｔｓ Ａｇｅｎｃｙ）が実験的に開始したＡＲＰＡｎ
ｅｔに端を発する。

【０００３】１９８０年代初め、一般利用者にＡＲＰＡ
ｎｅｔの利用を認めるに伴い、コンピュータのＯＳの一
つ：ＢＳＤ ＵＮＩＸ（登録商標）で利用される通信プ
ロトコル：ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ
Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ
Ｐｒｏｔｏｃｏｌ）が、同ネットにも採用され、この
結果、同ネット接続時のコンピュータ機種依存性が排除
された。また、同時期、大学や研究機関を中心に、学術
的な利用を目的としたＬＡＮ（Ｌｏｃａｌ Ａｒｅａ
Ｎｅｔｗｏｒｋ）の構築が始まっており、研究者間での
情報交換を積極的に行うため、これらのＬＡＮは相互に
接続され、ＡＲＰＡｎｅｔとも接続され、最終的には全
米に跨る大規模なネットワークへと発展した。この大規
模ネットワークこそがインターネットであり、その拡大
は現在も全世界の隅々に向けて進んでいる。

【０００４】インターネット通信技術とは、インターネ
ット上の別のコンピュータと、インターネットを介し
て、通信を行う上で必要となる技術群を指し、単にハー
ドウェアに留まらず、広くインターネット・プロトコル
をも含む。

【０００５】インターネット・プロトコルとは、インタ
ーネット上で通信を行うためのプロトコル（通信手順）
であり、上述のＴＣＰ／ＩＰが最も基本的なプロトコル
である。これをベースとして、例えば、ファイル転送を
行う場合は、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐ
ｒｏｔｏｃｏｌ：ファイル転送プロトコル）と呼ばれる
プロトコルを使用し、ｅ−Ｍａｉｌを送信する場合は、
ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ
Ｐｒｏｔｏｃｏｌ：簡易メール転送プロトコル）と呼
ばれるプロトコルを使用し、ＷＷＷ（Ｗｏｒｌｄ Ｗｉ
ｄｅ Ｗｅｂ）サービスを提供するコンピュータを意味
する、Ｗｅｂサーバにアクセスする場合は、ＨＴＴＰ
（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏ
ｃｏｌ：ハイパーテキスト転送プロトコル）と呼ばれる
プロトコルを使用する。

【０００６】ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋ
ｕｐ Ｌａｎｇｕａｇｅ：ハイパーテキスト記述言語）
とは、ハイパーテキストを記述するための言語体系であ
る。Ｗｅｂページには、ハイパーテキストが用いられる
が、今や世界のデジタル・コンテンツの９９％が、イン
ターネットの世界標準であるＨＴＭＬで記述されている
ことから、最近では、インターネット接続が可能な装置
と言えば、単にインターネットに接続できるだけではな
く、インターネット上のＷｅｂサイトからＨＴＴＰプロ
トコルを用いてダウンロードしたＨＴＭＬテキストをハ
イパーテキストとして閲覧できる装置、即ち、「ブラウ
ザ」と呼ばれる閲覧ソフトを予め搭載した装置（或い
は、オプションとして別途搭載できる装置）を指すよう
に、その解釈が変わり始めてきている。

【０００７】ブラウザを搭載したコンピュータの動作概
要を、図１１に記す。コンピュータ５０は、キーボード
５５やマウス５６等から構成される入力手段５７、ＣＲ
Ｔや液晶ディスプレイ等の表示手段５４、メモリや磁気
ディスク装置等の記憶手段５３、及び、内蔵モデム等の
通信手段５２を有し、ブラウザ５１がこれらを制御す
る。ブラウザ５１は、通信手段５２を介して、ネットワ
ーク５８に接続し、インターネット上のＷｅｂサーバに
アクセスする。ＷｅｂサーバからダウンロードしたＨＴ
ＭＬテキストは、一旦記憶手段５３に格納される。ブラ
ウザ５１は、これを解析し、ハイパーテキストとして、
表示手段５４に表示する。また、読みたいページのアド
レスを指定するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓ
ｏｕｒｃｅＬｏｃａｔｏｒ）入力や、ハイパーテキスト
中に含まれるリンクやアイコンのクリック等は、入力手
段５７を介して行う。

【０００８】当初、インターネットに接続される装置は
コンピュータだけであったが、昨今では、携帯式の情報
端末に加えて、テレビやゲームマシン、更に携帯電話に
おいても、ブラウザの装備を含めて、インターネットへ
の接続機能を装備するものが現れた。

【０００９】携帯電話が搭載するブラウザは、携帯電話
がパソコンと比較して処理能力やメモリ容量が乏しい。
例えば、最初のブラウザ対応携帯電話機に搭載されたロ
ーパワーＳＲＡＭは８Ｍｂｉｔｓに過ぎず、カラー化が
実現された昨今でも最大１６Ｍｂｉｔｓに過ぎない。加
えて、表示能力、表示サイズ、操作方法等にも制限があ
ることから、携帯電話機用に性能を特化した「マイクロ
ブラウザ」が使用されている。本ブラウザを用いて、携
帯電話用に操作面での仕様拡張が行われた「コンパクト
ＨＴＭＬ」を閲覧できる。

【００１０】携帯電話からインターネットに接続する場
合、「携帯電話網」の中にインターネット接続を中継す
る機能があり、ここを経由して、インターネットへの接
続を行う。

【００１１】具体的には、１９９９年２月２２日、株式
会社ＮＴＴドコモが「ｉモードサービス」を開始した
が、これが、携帯電話からインターネットへの乗入れを
可能とした最初のサービスである。

【００１２】なお、ｉモードサービスには、ＵＲＬの直
接入力により、インターネット上のＷｅｂサイトへのア
クセスを実現する「インターネット接続サービス」以外
にも、ｅ−Ｍａｉｌ（呼称：ｉモードメール）、簡易メ
ール（呼称：ショートメール）等の受発信や転送機能を
司る「メール・サービス」、及び、簡単なボタン操作だ
けで、コンテンツ・プロバイダが提供する、以下のコン
テンツへのアクセスを実現する「オンライン・サービス
（別名：サイト接続サービス）」等がサポートされてい
る。

【００１３】（１）銀行振込や航空券・ホテル・チケッ
ト予約等の取引系サービスを提供するコンテンツ。 （２）乗換え案内や字引等のデータベース系サービスを
提供するコンテンツ。 （３）ニュース・天気予報や株価情報等の生活情報系サ
ービスを提供するコンテンツ。 （４）ＦＭ局情報やゲーム・占い等のエンターテイメン
ト系サービスを提供するコンテンツ。

【００１４】即ち、ｉモードサービスとは、上記サービ
スを提供するシステムが、インターネット上に直接構築
されている訳ではなく、図１２に記すとおり、インター
ネット１５０とは異なる、ＮＴＴドコモ社独自のネット
ワークである「ＰＤＣ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔ
ａｌ Ｃｅｌｌｕｌａｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａ
ｔｉｏｎ Ｓｙｓｔｅｍ：デジタル移動通信方式）移動
パケット通信ネットワーク」（呼称：ＰＤＣ−Ｐネット
ワーク）１５１上に、インターネットとの中継機能を有
する「ｉモードサーバ」１０１を配した形で、構築され
たシステムである。ここで、ＰＤＣ−Ｐネットワーク１
５１は、同社が「ＤｏＰａ」／ドーパと命名したパケッ
ト通信サービスを行う目的で、予め構築していた全国パ
ケット通信網に過ぎない。しかし、ＰＤＣ−Ｐネットワ
ーク１５１上でｉモード通信を行う場合には、ＰＤＣ−
Ｐネットワーク１５１上のデータ転送プロトコルとし
て、ｉモード通信に特化したインターネット・プロトコ
ルを採用し、データ転送の効率化に心掛けている。具体
的には、以下のとおりである（図１３参照）。

【００１５】（１）ｉモード携帯電話機１００とＰＤＣ
−Ｐネットワーク１５１を接続するプロトコルとして、
ベアラ（データ転送プロトコルの最下位層に当たり、物
理層とデータリンク層を含む）の上位に、ＴＬＰ（Ｔｒ
ａｎｓｐｏｒｔ ＬａｙｅｒＰｒｏｔｏｃｏｌ：トラン
スポート層プロトコル）を採用。ＴＬＰは、インターネ
ットプロトコルを簡略化して、ｉモード通信向けに最適
化したものである。

【００１６】（２）ＰＤＣ−Ｐネットワーク１５１とｉ
モードサーバ１０１との接続には、ＴＣＰ／ＩＰに加え
て、ＵＩＴＰ（Ｕｓｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｔ
ｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：加入者情報伝達プ
ロトコル）とＮＷＭＰ（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅ
ｍｅｎｔ Ｐｒｏｔｏｃｏｌ：ネットワーク管理プロト
コル）の３プロトコルを採用。ＵＩＴＰとＮＷＭＰは、
ＴＬＰがインターネットプロトコルを簡略化したもので
あるために生じる不具合を補いつつ、しかも、課金制御
や保守機能を実現するなど、ｉモード通信向けに最適化
を施したものである。

【００１７】（３）ｉモードサービスのアプリケーショ
ン通信プロトコルとして、ＡＬＰ（Ａｐｌｉｃａｔｉｏ
ｎ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ：アプリケーション
層プロトコル）を採用。これは、インターネット・プロ
トコルの世界標準であるＨＴＴＰを改良し、ｉモード通
信向けに最適化を施したものである。

【００１８】なお、ＡＬＰは、通信フォーマットをＨＴ
ＴＰと同一にすることで、インターネットへの乗入れを
容易化している反面、ｉモードサービスに特有の機能の
実現と通信データ量の削減を図るため、以下の機能が付
加されている。

【００１９】（ａ）サービス上は不要な「ＨＴＴＰヘッ
ダ」を付与しない。この結果、データ量が削減される。 （ｂ）ｅ−Ｍａｉｌの送受信は、ＨＴＴＰで行う。即
ち、ｅ−Ｍａｉｌは、ＨＴＴＰフォーマットに変換の
上、転送される。

【００２０】（ｃ）着信通知信号を付与している。この
結果、例えば、メールサーバ機能を併せ持つｉモードサ
ーバ１０１に、加入者宛のｅ−Ｍａｉｌが届いた場合、
ｉモードサーバ１０１から加入者のｉモード携帯電話機
１００に着信通知信号が送付され、その旨が通知され
る。なお、ｉモード携帯電話機１００からｉモードサー
バ１０１へのサービス要求を「プル型」と呼ぶのに対
し、ｉモードサーバ１０１からｉモード携帯電話機１０
０へのサービス要求を「プッシュ型」と呼ぶ。

【００２１】ｉモードサービスのシステム構成を理解す
ることで、インターネット通信技術が、インターネット
の世界に限らず、携帯電話網等の他のネットワークにも
広がり始めてきている事実を理解できる。これは、他の
ネットワークからインターネットへの乗入れを容易に実
現して、インターネット世界の内外に存在する、種々の
ネットワーク資産を利用するためである。

【００２２】従来のｉモード携帯電話機のブロック図
を、図１４に記す。特開平１１−１１２６３３号に記さ
れる、従来の携帯電話機のブロック図と同一の図である
が、ｉモード処理機能をＰＤＣ−Ｐ制御部７３としてＬ
ＳＩ６５の内部に含めた形で記述している。

【００２３】即ち、ｉモード携帯電話機は、通常の携帯
電話機として使用するための機能として、受話器に相当
するマイク６１とレシーバ６０、操作部６７、表示部６
８、無線部６６、入出力音声をアナログ〜ディジタルの
双方向に変換可能なＡ／Ｄコンバータ６２、各種固定デ
ータを記録するＲＯＭ６９、各種可変データを記録する
ＲＡＭ７０、及び、ＬＳＩ６５に内蔵され、携帯電話の
通常の通話機能を司るＰＤＣ制御部７１とを有する。

【００２４】次いで、ｉモードで使用するための機能と
して、ｉモード通信機能を司るＰＤＣ−Ｐ制御部７３
を、ＬＳＩ６５に内蔵している。尚、ｉモードで使用す
る場合、マイク６１とレシーバ６０は使用しない。最近
の装置では、着メロ演奏機能が付加されたが、本機能
は、レシーバ６０のみを流用する。

【００２５】最後に、電話番号の音声入力、登録済電話
番号の別名による音声呼出し（「ボイスサーチ」と呼ば
れる）、ファンクション機能の音声呼出し等の音声処理
機能として、音声認識／合成ＬＳＩ６４と、音声情報の
伝達方向を切換えるスイッチ６３、及び、ＬＳＩ６５に
内蔵され、音声処理を司る音声処理部７２とを有する。

【００２６】ＬＳＩ６５の内部にある、ＰＤＣ制御部７
１、音声処理部７２及びＰＤＣ−Ｐ制御部７３は、使用
者の立場からは、見掛け上、同時に動作するものではな
く、各々を切換えながら使用するものとして映ってい
る。具体例を挙げれば、ボイスサーチによる登録済電話
番号の読出し時は、音声処理部７２のみが動作し、ＰＤ
Ｃ制御部７１とＰＤＣ−Ｐ制御部７３は休止中となる。
読出された電話番号に発信（発呼）し、通常電話を開始
する場合は、ＰＤＣ制御部７１が起動し、音声処理部７
２とＰＤＣ−Ｐ制御部７３は休止状態となる。待受け受
信時にｉモードボタンを押下することで、ＰＤＣ−Ｐ制
御部７３が起動し、ＰＤＣ制御部７１と音声処理部７２
は休止状態となる。ｉモード処理中に電話の着信があれ
ば（着呼）、ＰＤＣ制御部７１が起動し、音声処理部７
２とＰＤＣ−Ｐ制御部７３は休止状態となる。

【００２７】ここで、簡易メール（ＮＴＴ呼称：ショー
トメール）機能についても、説明する。本機能は、ｉモ
ードに固有の通信機能ではない。簡易メールとは、電話
により、音声ではなく、文字をやり取りする通信方式で
ある。その通信原理は、特定の文字を、複数のプッシュ
ボタンの各々の押下回数に応じて表現するものである。
即ち、プッシュボタン音の組み合せで、文字を表す。こ
のため、メーカに依存せず、通常の携帯電話や自動車電
話、更にプッシュボタン式の一般電話や公衆電話からで
も、簡易メールを送信することができる。

【００２８】簡易メールの送受信動作を、図１４を用い
て説明する。送信時、操作部６７を介して入力されたテ
キストは、ＲＡＭ７０上に蓄積されると共に、表示部６
８にも表示される。操作部６７上の発信キーの押下によ
り、ＲＡＭ７０上に蓄積された入力テキストは、ＰＤＣ
制御部７１で、各々の文字が、複数のプッシュボタン
の、各々の押下回数の組み合わせへと変換され、無線部
６６を介して、簡易メールとして、メールセンタ（ＮＴ
Ｔの場合、ショートメールセンタ）宛に発信される。一
方、簡易メールの受信時は、相手局は、メールセンタか
らの着信通知を受けて、ＰＤＣ制御部７１の制御の下、
簡易メールを、無線部６６を介してＲＡＭ７０上にダウ
ンロードする。ＲＡＭ７０上に蓄積された簡易メール
は、ＰＤＣ制御部７１によって、複数のプッシュボタン
の各々の押下回数の組み合わせから、特定の文字へと一
つずつ逆変換され、最後に、受信テキストとして表示部
６８に表示される。

【００２９】ＰＤＣ制御部７１が有する入力されたテキ
ストを、上記の特定の文字を表現する複数のプッシュボ
タンの、各々の押下回数の組み合わせへと変換する機能
を、「ショートメール符号化機能」と呼び、その逆の変
換を行う機能を、「ショートメール複合化機能」と呼
ぶ。

【００３０】インターネット、あるいは、ｉモードのＰ
ＤＣ−Ｐネットワークに代表されるインターネット通信
技術を応用したネットワークに接続し、インターネット
プロトコルの世界標準であるＨＴＴＰ、或いは、ｉモー
ドのＡＬＰに代表されるＨＴＴＰを応用したプロトコル
を用いて、本ネットワーク上で運営されている各種サー
ビスにアクセスする。さらに、インターネットの世界標
準であるＨＴＭＬ、或いは、ｉモードのコンパクトＨＴ
ＭＬに代表される、ＨＴＭＬを応用した記述言語によっ
て構築された各種コンテンツの中から、自分達にとって
必要な情報を入手し、本サービスの恩恵を得る。

【００３１】これらの利用形態は、今後更なる発展と広
がりを見せる方向にある。例えば、固定電話、ファック
ス、公衆電話、受信チューナ、ビデオ、カメラ、冷蔵
庫、電子レンジ、クーラー、洗濯機／乾燥機、医療機
器、ＣＤ／ＡＴＭ、自動車、ロボット等の各種装置にお
いて、上記ネットワークへの接続機能の装備と、アクセ
スの結果得られた情報を実際のユーザに提供する際の方
法（サービス内容）の検討が、既に開始されている。こ
れら装置の増加は、上記サービスへのアクセスに一層の
拍車を掛けるものとして、通信事業者やコンテンツプロ
バイダ等からも期待されている。

【００３２】本発明は、上記ＨＴＭＬ、あるいは、ＨＴ
ＭＬを応用した記述言語の閲覧が可能なブラウザ機能を
装備した装置全般に関するものである。

【００３３】なお、インターネットと似た言葉であるイ
ントラネットとは、インターネット通信技術を採り入れ
て構築した、企業（等の）「内部」のネットワークを意
味しており、他方、反意語のエクストラネットは、企業
「間」のネットワークを表すが、いずれもインターネッ
トの一部である。

【００３４】本発明と技術分野が類似する先願発明例と
して、例えば下記のものがある。 （１）特開平１１−１１２６３３号公報の図１ （２）特開平１１−１６３９９５号公報の図１ （３）特開平１０−１９０７９７号公報の図１ （４）特許第２６５５０８６号の図１ （５）特開２０００−１０５６８１号公報の図１

【００３５】

【発明が解決しようとする課題】しかしながら、上記の
従来技術は、下記の各種の問題を伴う。第１の問題点
は、上記装置に提供される各種サービスは、目の不自由
な方々にとって、益々使いづらいものとなっていく点で
ある。その理由は、マルチメディアがインターネットの
基盤となっていることから、提供されるサービス内容に
おいても、当然マルチメディア的なものが多用される方
向にあるが、マルチメディアの中には、文字や画像／映
像（図、静止画、動画等）等の視覚を利用したものが多
々あり、これらは目の不自由な方々にとって、大きな障
壁（バリア）になるためである。特に、携帯電話機は、
従来から、目の不自由な方々に対する配慮が脈々となさ
れていた機器である（携帯電話機自身については、特開
平１１−１６３９９５号を、その収容ホルダについて
は、特開平１０−１９０７９７号公報を参照）にもかか
わらず、インターネット接続機能のサポートに関して
は、この配慮が全くなされておらず、目の不自由な方々
の期待を裏切る、心地良くない機能追加として、受け止
められていた。

【００３６】携帯電話機の例を具体的に記す。音声通話
機能しかない従来型の携帯電話機を用いて電話を掛ける
分には、０〜９及び発信ボタンを操作するだけなので、
目の不自由な方々でも何とかこれを使用することができ
た。加えて、携帯電話機にワンタッチ（又はツータッ
チ）ダイヤル機能やボイスサーチ機能（音声認識に基づ
く登録済電話番号の読出し／発呼機能）等を追加するこ
とで、目の不自由な方々の負担を一層軽減することがで
きた。更に、特開平１１−１６３９９５号では、ボタン
部分への突起物の付与が提案されており、特開平１０−
１９０７９７号では、収容ホルダのボタン部に点字状の
突起物を付与し、携帯電話機を収納したまま、使用する
ことが提案されている。

【００３７】しかし、簡易メール機能（ショートメール
等）を使用する場合には、送信時、メール文章のデータ
入力が必要となるが、送信したい文字の選択が、ボタン
の押下順序や回数を組み合せて行う方式であるため、複
雑なボタン操作がどうしても必要となり、目の不自由な
方々には、とても扱える代物ではなかった。最近では、
外付けのキーボード（呼称：ｉボード）や、タッチペン
形式のポインティング・デバイスが、オプションで提供
されている機種もあるが、あくまでもボタン操作に不慣
れな人向けの支援機能に過ぎず、目の不自由な方々にと
って、これらは大差がない。いわんや、受信したデータ
については、画面に表示されるだけであり、目の不自由
な方々は、これを読むことができない。

【００３８】更に、ｉモードサービスに至っては、送信
時、データ入力以前に、画面上に表示される案内文を一
旦読み、理解した上で、案内文中に指定されるボタン操
作を、適切に行う事が要求されるが、目の不自由な方々
には、要求された操作を、その通りに行う事が出来な
い。

【００３９】第２の問題点は、目の不自由な方々向けに
適切なコンテンツを提供することが、コンテンツ・プロ
バイダには不可能であったり、あるいは、コンテンツの
作成に時間が掛かり、高価になる点である。その理由
は、目の不自由な方々に文字や画像／映像から構成され
るコンテンツをそのまま提供することは失礼な話である
ため、別法を採るとした場合、残された有効な情報提供
手段は、現技術水準では音声のみである。このため、作
成済のコンテンツを音声のみから構成される形に作り替
えなければならず、その分、費用がかさみ、時間を要す
ることとなる。

【００４０】携帯電話機の例を具体的に記せば、ｉモー
ドサービスの場合、コンテンツ・プロバイダは、ＨＴＭ
Ｌ４．０の機能縮小版である「コンパクトＨＴＭＬ」を
用いてコンテンツを記述すれば良い。このため、普通に
ウェブ（Ｗｅｂ）ページを作れる人にとっては、特別に
覚えなければならない事柄はほとんどなく、コンテンツ
の作成は比較的容易であった。他方、これを目の不自由
な方々向けに、音声情報だけを用いた形に書き直す、と
すれば、例えば、案内音声を記録したＷＡＶファイル
（等）をダウンロードさせ、これを再生させるようにコ
ンテンツを作り替える必要がある。しかし、現在の携帯
電話機は、ピアノやギターなどの音色再生を目的とした
ＦＭ音源や多重和音機能等をサポートするのみであり、
加えて、ダウンロードによって再生可能なサウンド系フ
ァイルも、着メロ用のＭＩＤファイル（ＭＩＤＩ Ｄａ
ｔａ Ｆｉｌｅ）のみである事から、音声は再生でき
ず、音声案内を実現できない。

【００４１】そもそも、ｉモードサービスの形態は、目
の不自由な方々に情報を提供することが想定されていな
い。それは、ｉモードサービスのコンセプトが「話すケ
ータイから使うケータイへ」だからである。そのことを
考え合わせると、目の不自由な方々には使えないケータ
イが、一概に悪いとは責められない。むしろ、目の不自
由な方々には、従来の音声通話機能で電話を掛けて頂
き、コンテンツ・プロバイダの側では、その目的専用
に、音声案内人を雇用して、教育後、その任に当たらせ
るなり、或いは、音声応答装置を購入し、その目的向け
の専用記述言語を用いて、音声応答の手順等をプログラ
ミングして運用するなりした方が簡便ですらある。勿
論、その分、費用が嵩み、時間を要するが、それは止む
を得ない。

【００４２】本発明は、音声合成及び音声認識処理回路
を効率化し、ブラウザ搭載装置の小型・軽量化を廉価に
実現することを目的とする。その上で、本発明は、特性
・性能向上、文字入力の高速化、操作性向上、文字入力
の簡易化等を図ったブラウザ搭載装置を提供することを
目的とする。

【００４３】本発明の究極的な目的は、マンマシンイン
タフェースの改善（眼の不自由な方々でも操作可能とす
る）を図り、コンテンツ・プロバイダ側で発生する負担
を極力抑えながら、眼の不自由な方々を、インターネッ
トの世界に誘うことにある。

【００４４】

【課題を解決するための手段】かかる目的を達成するた
め、請求項１に記載の発明のブラウザ搭載装置は、ＨＴ
ＭＬテキストを解析し、解析結果からＨＴＭＬテキスト
の読み上げ方法を最適化し、ＨＴＭＬテキストの読み上
げ音声の合成を指示するブラウザと、ブラウザが最適化
した読み上げ方法によりＨＴＭＬテキストの読み上げ音
声をブラウザの指示により合成する音声合成手段と、音
声合成手段が合成した音声を出力する音声出力手段と、
携帯電話の通常の通話機能を司るＰＤＣ制御手段と、イ
ンターネットプロトコルを応用したｉモードサービス等
への接続処理機能を司るＰＤＣ−Ｐ制御手段と、音声処
理を司る音声処理手段と、音声認識を行う音声認識手段
と、ＰＤＣ制御手段およびＰＤＣ−Ｐ制御手段および音
声処理手段の各部と前記音声認識手段との間を選択的に
接続するスイッチとを有した構成としている。

【００４５】また、請求項２に記載の発明は、請求項１
の発明に加えて、使用者が発した音声を取込む音声入力
手段をさらに有し、この音声認識手段は、音声入力手段
が取込んだ音声からブラウザに対する制御指示を認識
し、この制御指示をブラウザに伝達し、ブラウザが音声
認識手段から伝達された制御指示を解析し、適切な次の
アクションを行うことを特徴とする。

【００４６】請求項３に記載の発明は、請求項２の発明
に加えて、発声される可能性のある語彙を記憶する認識
語彙記憶手段をさらに有し、音声認識時に認識語彙の辞
書として認識語彙記憶手段を音声認識手段が使用してＨ
ＴＭＬテキストを解析し、解析結果から音声認識手段が
行う音声認識の認識率を向上させ得る語彙を抽出し、こ
の抽出した語彙を認識語彙記憶手段にブラウザが記憶さ
せることを特徴とする。

【００４７】請求項４に記載の発明は、請求項３の発明
に加えて、ＨＴＭＬテキスト中に語彙が直接含まれる場
合に、該語彙を抽出し、認識語彙記憶手段に記憶させる
ブラウザを有した構成としている。

【００４８】請求項５に記載の発明は、請求項１から４
の何れか１項に記載のブラウザ搭載装置において、音声
処理に伴う話者の性別、音声のピッチ／スピード、読み
上げピッチの加速具合い等については、設定で変更可能
としている。

【００４９】請求項６に記載の発明は、請求項１から５
の何れか１項に記載のブラウザ搭載装置において、絵文
字等の外字の読み上げ方を、設定で変えられることとし
ている。

【００５０】

【発明の実施の形態】次に、添付図面を参照して本発明
によるブラウザ搭載装置の実施の形態を詳細に説明す
る。図１から図１０を参照すると、本発明のブラウザ搭
載装置の一実施形態が示されている。

【００５１】図１は、本発明の第１の実施形態を示すブ
ロック図である。図１を参照すると、本発明の第１の実
施形態は、従来技術を表す図１１に対して、ＨＴＭＬテ
キストを解析し、解析結果からＨＴＭＬテキストの読み
上げ方法を最適化し、音声合成手段に対し、ＨＴＭＬテ
キストの読み上げ音声の合成を指示する音声ブラウザ１
と、音声ブラウザ１が最適化した読み上げ方法により、
ＨＴＭＬテキストの読み上げ音声を合成する音声合成手
段２と、音声合成手段２が合成した音声を出力する音声
出力手段３とを追加している。

【００５２】図２は、本発明の第２の実施形態を示すブ
ロック図である。図２は、第１の実施形態を示す図１に
対して、使用者が発した音声を取込む音声入力手段５
と、音声入力手段５が取込んだ音声から、音声ブラウザ
１に対する制御指示を認識し、制御指示を音声ブラウザ
１に伝達する音声認識手段４とを追加し、更に、音声認
識手段４から伝達された制御指示を解析し、適切なアク
ションを行うように音声ブラウザ１を変更している。

【００５３】図３は、本発明の第３の実施形態を示すブ
ロック図である。図３は、第２の実施形態を示す図２に
対して、発声される可能性のある語彙を記憶する認識語
彙記憶手段６を追加し、更に、音声認識時、認識語彙の
辞書として、認識語彙記憶手段６を使用するように音声
認識手段４を変更し、加えて、ＨＴＭＬテキストを解析
し、解析結果から、音声認識手段４が行う音声認識の認
識率の向上させ得る語彙を抽出し、該抽出した語彙を認
識語彙記憶手段６に記憶させるように音声ブラウザ１を
変更している。

【００５４】図４は、本発明の第４の実施形態を示すブ
ロック図である。図４は、第３の実施形態を示す図３に
対して、ＨＴＭＬテキスト中に語彙が直接含まれる場合
に、該語彙を抽出し、認識語彙記憶手段６に記憶させる
ように音声ブラウザ１を変更している。

【００５５】（動作例）図１に示す本発明の一実施例を
表すブロック図、及び、図５に示す音声ブラウザ１の動
作例を示すフローチャートを用いて、本発明の第１の実
施形態における動作内容を説明する。

【００５６】ブラウザ搭載装置５０は、ブラウザ５１の
指示で、通信手段５２を介して、ネットワーク５８に接
続し、インターネット上のＷｅｂサーバにアクセスし、
ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３
に格納する。音声ブラウザ１は、これを読取り、一次解
析し（図５のステップＳ１）、ＨＴＭＬテキストに文法
誤り等がなければ（ステップＳ２）、ＨＴＭＬテキスト
上の表示開始位置（通常は、ＨＴＭＬテキストの先頭位
置。尚、ＨＴＭＬテキスト内で、＜Ａ ＮＡＭＥ＝…＞
タグにより、ラベル名が定義されており、且つ、そのラ
ベル名にリンクするようにブラウザ５１が指示されてい
た場合には、そのラベル位置。）から、順次ＨＴＭＬテ
キストを二次解析し、読み上げ文書を構築し、最適化す
る（ステップＳ３）。具体的には、通常のテキスト部分
とＨＴＭＬタグ部分を分解し、ＨＴＭＬタグ部分は、更
に、その属性と属性の値とを読取り、個々のＨＴＭＬタ
グの、全文における位置付けをも把握しながら、目の不
自由な方々に理解されやすい、文章表現と読み上げ方法
とをデザインする。その要領は、例えばｉモード携帯電
話で使用されるコンパクトＨＴＭＬを用いれば、以下の
とおりである。

【００５７】（機能１）読み上げ方は、基本的には、ハ
イパーテキストとして表示されたＨＴＭＬテキストを、
通常の人が自然に読むのと同じ要領で読み上げる。例え
ば、ＦＲＡＭＥタグにより、画面が左右に分割されてい
る場合には、左側のＦＲＡＭＥの内部を先に全て読み上
げる（これは、通常のブラウザ５１が画面表示をデザイ
ンする際に用いる方法）のではなく、表示面積の大きい
側の画面から順に、ブロック（段落等）毎に交互に、読
み上げるものとする。具体的には、左右のＦＲＡＭＥの
内部で、読み上げるブロックを各々まとめ、仮に右側の
画面がより表示面積が大きいと仮定すれば、右側から読
み始めるものとし、右１ブロック→左１ブロック→１ブ
ロック分下に降りて、右１ブロック→左１ブロック→１
ブロック分下に降りて、右１ブロック→…という要領で
読み上げる。尚、上記読み上げ方法は、本願出願者にと
っては自然な流れだが、本ブラウザ搭載装置の実際の使
用者にとっては、不自然な読み上げ方かも知れない。こ
の為、本読み上げの方法は、設定で変えられることが望
ましい。

【００５８】（機能２）通常テキストは、男性が低い声
で読み上げる。リンクのある部分は、女性の声で読み上
げる。一度訪問した実績のあるリンクの部分は、女性が
高めの声で早口に読み上げる。accesskey 等の操作方法
の指示部は、男性が普通の声で読み上げる。例えば、Ｈ
ＴＭＬテキストが、 「メニューリスト<BR> <A accesskey="1" HREF="http://…">１．ニュース／情
報</A><BR> <A accesskey="2" HREF="http://…">２．モバイルバン
キング</A><BR> <A accesskey="3" HREF="http://…">３．カード／証券
／保険</A><BR>」 の場合、読み上げ方は以下のとおり、男性が低い声で、
「メニューリスト」と読み上げた後、女性の声で「１
ニュース情報」と読み上げ、その直後に、男性が普通の
声で「１キーで アクセスします」と操作方法を解説す
る。話者の性別や、音声のピッチ／スピードは、設定で
変えられることが望ましい。

【００５９】（機能３）操作方法の解説が連続する場合
には、解説文の読み上げ方を省略する。例えば、（機能
２）の例では、以下、女性の声で「２ モバイルバンキ
ング」、男性が普通の声で「２です」、女性の声で「３
カード 証券 保険」、男性の普通の声で「３です」
と読み上げる。なお、具体的な省略の仕方や、解説が連
続状態に入った場合の読み上げピッチの加速具合い等に
ついては、設定で変えられることが望ましい。

【００６０】（機能４）表示の位置に関するＨＴＭＬタ
グ及び属性は、（機能１）のブロック位置の算出を除
き、読み上げの際には無視する。例えば、タグ<CENTER
>、属性 align、等は無視する。

【００６１】（機能５）絵文字は外字につき、その「意
味」を読み上げる。例えば、ハートマーク（絵文字コー
ド：＆＃６３７２６。本コードは、メーカに依存する）
の場合は、「ハート」と読み上げる。なお、その読み上
げ方は、設定で変えられることが望ましい。

【００６２】（機能６）画像（ｉモード携帯電話の場
合、ＧＩＦのみ）は、無視する。但し、ＨＴＭＬテキス
ト中で、 「<IMG SRC="http:// …" ALT=" 彼氏"><BR>」 のように、ＡＬＴ属性で代替文字の指定があった場合に
は、男性の普通の声で「彼氏の絵」等の解説を加える。
（機能１）の作用により、本解説文を読み上げる場所
は、文脈に沿った、適切な場所で、読み上げる。なお、
解説の有無及び解説の内容は、設定で変えられることが
望ましい。

【００６３】（機能７）文字等に対する装飾は、無視す
る。例えば、タグ<PRE> 、<H1>〜<H6>、属性 bgcolor、
等である。

【００６４】（機能８）リスト（タグ：UL,OL,LI,DL,D
T,DD ）やテーブル（タグ：TABLE,TR,TH,TD,CAPTION）
については、その部分を読み上げる前に、「続いて リ
スト（テーブル）の読み上げを行います」等の解説を加
える。ただし、リストやテーブルがネスト（ｎｅｓｔ）
になる場合には、聞き手に混乱を与えないために解説は
省略する。また、項目が行頭に当たる場合は、話者を変
える等して、その項目が行頭に当たることを聞き手に印
象付ける。

【００６５】（機能９）フォームについては、読み上げ
完了後、一括して入力（または、選択）して頂くことと
なるため、読み上げ中は、「後で 入力（または、選
択）して下さい」又は「後で 変更できます」等と、簡
単に読み上げる。全文読み上げ終了時、フォーム部分に
限定して、会話形式による読み上げと、テキスト入力
（または、選択）を行わせ、最後にＲｅｓｅｔ相当又は
Ｓｕｂｍｉｔ相当ボタン（アイコン）の入力を行わせる
ような音声案内を行う。

【００６６】具体例として、以下のＨＴＭＬテキストが
あった場合、 「<H1 align="center"> 全製品の検索画面</H1> <FORM method=POST action="search.cgi"> 検索型番：<INPUT type=text name=word size=32 value
="N502it Hyper"><INPUT accesskey="0" type=submit v
alue="検索"> <INPUT accesskey="1" type=reset value=" クリア"><B
R> 並べ方（複数指定時）：<INPUT accesskey="2" type=ra
dio name=srt value="1" checked> 型番昇順 <INPUT accesskey="3" type=radio name=srt value="2"
> 発売日降順<BR> </FORM> 」

【００６７】全文読み上げ時は、上記の部分は以下のと
おり、読み上げる。 「（男性の声) …。全製品の検索画面。 （女性の声) ここから先は、後でまとめて入力して下さ
い。 （男性の声) 検索型番 N502it Hyper。 （女性の声) 後で変更できます。 （男性の声) 並べ方。複数指定時。型番昇順。発売日降
順。お奨めは、型番昇順。 （女性の声) 後で変更できます。 （INPUT タグの type=submit,reset部に関しては、この
段階では読み上げない。） （次いで、フォーム部の終了を示すチャイムの鳴動音
等）。 （男性の声) …。（残りのテキストを読み上げる）。」

【００６８】次いで、全文読み上げ完了時、以下のとお
り、読み上げる。 「（女性の声) では、先程お話ししたまとめ入力をこれ
から行いましょう。 （男性の声) 検索型番 N502it Hyper。 （女性の声) 変更する場合は今入力して下さい。変更し
ない場合は、０キーを押して下さい。 （入力の完了を待つ。暫くして、何の入力もなければ、
再度音声で入力を促す。尚、「変更しない場合の０キ
ー」とは、INPUT タグの type=submit部にある属性acce
sskey の値を使用することが初期設定されていることを
仮定）。

【００６９】（男性の声) 並べ方。複数指定時。 （女性の声) 次の２つの中からいずれかを選択して下さ
い。 （男性の声) 型番昇順。 （女性の声) ２キーで選択します。 （男性の声) 販売日降順。お奨めは、型番昇順。 （女性の声) ３キーです。いずれかを今選択して下さ
い。０キーでお奨めを選択することもできます。 （入力の完了を待つ。暫くして、何の入力もなければ、
再度音声で入力を促す。尚、「０キーでお奨めを選択す
る」とは、INPUT タグのtype=submit 部にある属性acce
sskey の値を使用することが初期設定されていることを
仮定）。

【００７０】（女性の声) 最後に、まとめ入力の内容を
確認します。 （男性の声) 検索型番（上記で入力された型番の読み上
げ）。並べ方。複数指定時（上記で選択された並べ方を
読み上げ）。 （女性の声) 「検索」を行う場合は、０キーを押して下
さい。「クリア」を行う場合は、１キーを押して下さ
い。 （入力の完了を待つ。暫くして、何の入力もなければ、
再度音声で入力を促す）

【００７１】（機能１０）入力手段５７からの適切な指
示（ボタン押下等）により、通常テキスト部分の読み上
げを行わず、リンクの部分だけを読返す機能を、音声ブ
ラウザ１に付与することが望ましい。本機能の追加によ
り、最初に全文を聞き終えた後、本機能を起動して、リ
ンクの部分だけを必要なだけ読返すことが可能となり、
リンク先の指定（ボタン押下等）を、さほど混乱するこ
となく正確に行うことができる。

【００７２】（機能１１）警告メッセージの発生時は、
読み上げ処理を一旦中断し、警告メッセージの読み上げ
を行い、必要があれば文字入力や選択等を会話形式で行
い、最後にボタン押下やアイコン・クリックを行わせる
ように音声案内を行う。なお、本ボタンの押下後は、必
要に応じて中断していた読み上げ処理を再開する。

【００７３】音声ブラウザ１は、ステップＳ３で最適化
された読み上げ文章を、ステップＳ４で音声合成手段２
に転送し、音声出力手段３を通して音声出力させる。

【００７４】また、ステップＳ２でＨＴＭＬテキストに
文法誤り等があれば、読み上げのできない旨を音声合成
手段２に伝えて、音声出力手段３を通して、その旨を音
声出力させる（ステップＳ５）。

【００７５】読みたいページのアドレスを指定するため
のＵＲＬ入力や、ハイパーテキスト中に含まれるリンク
やアイコンのクリック等は、従来同様、入力手段５７を
介して行う。

【００７６】次に、図２に示す本発明の一実施例を表す
ブロック図、及び、図６に示す音声ブラウザ１の動作例
を示すフローチャートを用いて、本発明の第２の実施形
態における動作内容を説明する。

【００７７】ブラウザ搭載装置５０は、ブラウザ５１の
指示で、通信手段５２を介して、ネットワーク５８に接
続し、インターネット上のＷｅｂサーバにアクセスし、
ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３
に格納する。音声ブラウザ１は、これを読取り、第１の
実施形態に示すとおり、最適化された読み上げ文章を構
築後、音声合成手段２に転送し、音声出力手段３を通し
て、音声出力させる。

【００７８】他方、使用者が発した音声は、音声入力手
段５に取込まれる。取込まれた音声は、音声認識手段４
により音声認識される。本音声認識は、単に話者音声を
テキスト形式に変換するのみならず、音声ブラウザ１に
対する制御指示の候補として認められるか否かを含めて
認識される。認識結果が、音声ブラウザ１に対する制御
指示の候補として認められる場合には、音声認識手段４
は音声ブラウザ１に対して割込みを行い、併せて、認識
された制御指示の候補を音声ブラウザ１に伝達する。音
声ブラウザ１は、本割込みを受けて、その状態を遷移さ
せ、図６に記すフローチャートに従い、割込みの処理を
開始する。以下に、そのフローチャートを図６を用いて
説明する。

【００７９】音声ブラウザ１は、音声認識手段４から伝
達された音声認識結果が、音声ブラウザ１に対する制御
指示として有効か否かを確認する（ステップＳ６）。

【００８０】有効と認められた場合は、本割込みが、音
声合成手段２による読み上げ処理の最中に発生した割込
みであるか否かを調べる（ステップＳ７）。

【００８１】本割込みが、音声合成手段２による読み上
げ処理の最中に発生した割込みである場合には、音声認
識手段４から伝達された制御指示が、音声合成手段２に
よる読み上げ処理をわざわざ中断し、直ちに実行する必
要性があるか否かを調べる（ステップＳ８）。

【００８２】音声認識手段４から伝達された制御指示を
慌てて実行する必要性がない場合には、音声合成手段２
による読み上げ処理が終了した時点で、受取った制御指
示（その時点では、制御指示は複数に増えている可能性
もある）を（順番に）解析し、次のアクションとして
（一つずつ順番に）実行して行けば良いので、受取った
制御指示を一時的に保留（ステップＳ１２）し、本割込
みから復帰する。

【００８３】ステップＳ８での判定の結果、音声認識手
段４から伝達された制御指示を直ちに実行する必要性が
ある場合には、音声合成手段２に読み上げ処理の中止を
指示し（ステップＳ９）、読み上げ処理を中止させた緊
急性の高い制御指示に限定してその内容を解析し、次の
アクションとして実行しても矛盾が生じなければ、その
アクションを実行する（ステップＳ１０）。このこと
は、既に制御指示が複数蓄積された状態にある場合は、
緊急性の高い制御指示を古いものから順に探索して行く
ことを意味しているが、探索して検出される迄の間に存
在した、緊急性が低くて読飛ばされた制御指示について
は、もはや不要な制御指示と見なして、これらは廃棄し
（ステップＳ１１）その上で、本割込みから復帰する。

【００８４】ステップＳ７の判定の結果、本割込みが、
音声合成手段２による読み上げ処理の最中に発生した割
込みではない場合には、ステップＳ１２で一時的に保留
とした制御指示も含めて、受取った制御指示の内容を古
いものから順に解析し、次のアクションとして実行して
も矛盾しない内容であれば、そのアクションを実行する
（ステップＳ１３）。全ての制御指示の解析を終えた段
階で、本割込みから復帰する。

【００８５】ステップＳ６の結果、音声認識手段４から
伝達された内容が制御指示として無効な場合には何もせ
ず、そのまま本割込みから復帰する。音声合成手段２が
読み上げを完了した時点で、音声ブラウザ１は、音声認
識手段４から受け取った制御指示で一時的に保留されて
いる物が未だ残っていないかを確認する。未だ残ってい
る場合には、ステップＳ１３同様に、受け取った制御指
示の内容を古い物から順に解析し、次のアクションとし
て実行しても矛盾しない内容であれば、そのアクション
を順次実行する。この結果、文字入力（例．読みたいペ
ージのアドレスを指定するためのＵＲＬ入力）や、クリ
ック操作（例．ハイパーテキスト中に含まれるリンクや
送信ボタン・アイコン等のクリック操作）を、入力手段
５７からではなく、音声入力手段５を介して、音声で行
うことが可能となる。

【００８６】第１の実施形態の動作説明の中にある、
（機能２）と（機能３）で使用したＨＴＭＬテキスト
を、具体例として用いれば、以下のとおりである。

【００８７】音声ブラウザ１は、「１ ニュース 情
報。」「１キーで アクセスします。」「２ モバイル
バンキング。」「２です。」「３ カード 証券 保
険。」「３です。」と読み上げ続ける。使用者は、途中
で「２。」と発声する。使用者の発した音声は、音声入
力手段５に取込まれ、音声認識手段４により、音声認識
され、音声ブラウザ１へと割込む。音声ブラウザ１は、
ＨＴＭＬテキスト中に、「<A accesskey="2" HREF="htt
p://…">２．モバイルバンキング</A><BR>」とあること
から、「２」キーが押されたのと同等と解釈して、指定
のリンク先にジャンプする。

【００８８】また、第１の実施形態における（機能９）
で使用したＨＴＭＬテキストを、具体例として用いれ
ば、以下のとおりである。フォーム部分は、最初の全文
読み上げ中には、「後で 入力（または、選択）して下
さい」又は「後で 変更できます」等と、簡単に読み上
げる。全文読み上げ終了時、フォーム部分に限定して、
会話形式による読み上げと、テキスト入力待やボタン類
の選択待ちが発生する。即ち、入力や選択が必要となる
箇所では、その都度、音声案内が停止するので、使用者
からの音声指示により、音声認識を用いてテキスト入力
や選択を行わせることができる。最後に、Ｒｅｓｅｔ相
当又はＳｕｂｍｉｔ相当ボタン（アイコン）の押下案内
が流れるため、これもまた音声で指示する。

【００８９】第２の実施形態の場合、音声入力指示が効
果的に行われるようにするため、コンテンツ（ＨＴＭＬ
テキスト）の設計側でも、十分に注意を払う必要があ
る。

【００９０】例えば、マウス等のポインティング・デバ
イスで、画面上のアイコンやイメージ等をクリックし、
その位置等を指定する（これを「フォーカスする」と言
う）使用方法は、汎用的なブラウザでは一般的なもので
あるが、これを音声入力指示で代用するとなると、位置
指定が難しく、相当使い勝手の悪い、非実用的な代物と
なってしまう。従って、ＨＴＭＬテキストの設計側で
は、そのようなＨＴＭＬタグの使用（例．イメージ上の
クリック位置で、そのアクションを異ならせるような、
イメージマップ処理を実現するための「ＭＡＰ」タグの
使用等）を慎むように、注意する必要がある。

【００９１】ところが、近年になり、ポインティング・
デバイスを装備しない携帯電話機からもインターネット
に乗り入れることができるようになった。この目的のた
めに、ＨＴＭＬを応用して開発された「コンパクトＨＴ
ＭＬ」と、コンパクトＨＴＭＬの閲覧が可能な「マイク
ロブラウザ」の登場により、上記設計上の注意点が自然
に緩和される結果となり、第２の実施形態は一層現実味
を帯びた。

【００９２】即ち、ポインティング・デバイスを装備し
ていないｉモード携帯電話機に搭載されるマイクロブラ
ウザには、汎用的なブラウザに存在する、「戻る」
「次」「再読込み」又は「ホーム」等のボタンのアイコ
ンが画面上になく、仮に存在しても、キー操作で代用で
きる。例えば、「戻る」「次」機能は、←、→等の矢印
キーの押下で、代用できる。加えて、コンパクトＨＴＭ
Ｌでは、イメージマップ処理を行わせる「ＭＡＰ」タグ
をサポートしていないのみならず、「Ａ」タグや「ＩＮ
ＰＵＴ」タグに、accesskey 属性を追加し、キー操作だ
けで位置指定が行えるように、「イージーフォーカス機
能」が強化されている。なお、ｉモード携帯電話機によ
る、第２の実施形態の具体的な実施例は、本発明の他の
実施形態の章で説明することにする。

【００９３】第２の実施形態の場合、音声認識手段４に
よる音声認識率を向上させる必要がある。この後に述べ
る、第３の実施形態は、音声認識率の向上を目的とした
ものである。最近の音声認識装置のブロック図を図１５
に示す。

【００９４】不特定話者認識、大語彙認識、連続音声認
識を実現する音声認識方法の一つとして、半音節単位を
用いた音声認識が効果的である。半音節単位とは、音節
をその母音中心で分割した結果得られるＣＶ（子音(con
sonant) ＋母音(vowel) ）区間とＶＣ（母音＋子音）区
間とを音の基本単位として使用するものである。各半音
節は、ＨＭＭ(Hidden Markov Model）と呼ばれるモデル
で表現され、ＨＭＭは、音の時間軸上及び周波数軸上の
揺らぎを統計的に表現できるモデルである。今、各読み
の半音節モデルと、認識対象となる単語（かな文字で表
記されている）とが予め装置に登録されている状態にお
いて、登録済の認識対象となる単語の各々の読みに対応
して、半音節モデルを連結した単語モデルを作り、これ
を入力音声と個々に比較しながら、最もよく照合するも
の（即ち、似ているもの）を選び出すこと（算術的に
は、対数尤度を比較し、値が最大となるものを選ぶ）に
よって、最善の認識結果を得る。更に、単語の並び方を
表す文法モデルを与えることで、文法により許される範
囲内での連続音声認識が可能となる。

【００９５】このため、認識率の向上には、各読みの半
音節モデルの充実、認識対象となる単語の充実、及び、
単語の並び方を表す文法の充実とが、重要である。この
後に述べる、第３の実施形態は、特に認識対象となる単
語、即ち、語彙の充実方法について、述べるものであ
る。

【００９６】図１５に記す、最近の音声認識装置は、半
音節モデルとして、不特定話者半音節モデル記憶部８４
と話者適応後半音節モデル記憶部８５を併せ持つ。不特
定話者半音節モデル記憶部８４には、予め多数の人の声
（学習データ）を用いて作成された不特定話者の半音節
モデルが登録されている。これにより、特定話者の少量
の音声を用いて、不特定話者モデルをその話者に適応
（話者適応）させ、認識性能をより向上させるように努
めている。

【００９７】音声入力手段５を介して入力された音声
は、分析、雑音除去部８０で分析され、２段スペクトル
・サブストラクション法等を用いて、周囲雑音の影響を
除去された後、認識処理部８１及び話者適応制御部８６
へと送付される。

【００９８】認識処理部８１は、不特定話者半音節モデ
ル記憶部８４及び話者適応後半音節モデル記憶部８５に
記録される各々の半音節モデル、語彙辞書部８２に登録
される語彙（認識対象となる単語を意味し、かな文字で
表記されている）、及び、文法モデル部８３に登録され
る文法とを用いて、音声認識を行う。

【００９９】話者適応制御部８６は、話者適応のための
学習機能を司ると共に、現在入力されている音声を解析
し、半音節モデル学習時からの環境差を推定し、使用さ
れる半音節モデルを、現在入力されている音声に速やか
に適合させるように制御する（高速環境適応法）。

【０１００】次に、図３に示す本発明の一実施例を表す
ブロック図、及び、図７に示す音声ブラウザ１の動作例
を示すフローチャートを用いて、第３の実施形態の動作
内容を説明する。

【０１０１】ブラウザ搭載装置５０は、ブラウザ５１の
指示で、通信手段５２を介して、ネットワーク５８に接
続し、インターネット上のＷｅｂサーバにアクセスし、
ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３
に格納する。音声ブラウザ１は、これを読取り、第１の
実施形態に記すとおり最適化された読み上げ文章を構築
した後（図７のステップＳ３）、ＨＴＭＬテキストの解
析結果から、音声認識手段４で行われる音声認識の認識
率を向上させる語彙を抽出し、抽出された語彙を認識語
彙記憶手段６に登録する（ステップＳ１４）。その上
で、音声ブラウザ１は、最適化された読み上げ文章を、
音声合成手段２に転送し、音声出力手段３を通して、音
声出力する（ステップＳ４）。使用者が発した音声指示
は、第２の実施形態に示すとおり、音声入力手段５に取
り込まれ、認識語彙の辞書として、認識語彙記憶手段６
に登録された語彙を使用する音声認識手段４によって音
声認識された後、音声ブラウザ１により、次のアクショ
ンが実行される。

【０１０２】ＨＴＭＬテキストの解析結果から、音声認
識率を向上させる語彙を抽出し、認識語彙記憶手段６に
登録するステップＳ１４において、目的の語彙の抽出要
領は、例えば、ｉモード携帯電話で使用されるコンパク
トＨＴＭＬの場合には、以下のとおりである。

【０１０３】（機能１２） ＜Ａ＞＜／Ａ＞タグに含まれるテキスト。例えば、 「<A HREF="http://…">ニュース／情報</A><BR>」 の場合には、「にゅうす」、「じょおほお」を登録す
る。

【０１０４】（機能１３）属性アクセスキー（ａｃｃｅ
ｓｓｋｅｙ）があれば、その値。例えば、「<A accessk
ey="1" HREF="http://…">ニュース／情報</A><BR>」の
場合は、accesskey="1" につき、「いち」を登録する。

【０１０５】（機能１４） ＜ＩＰＵＴ＞タグの場合は、以下のとおりである。 （ａ）属性ＴＹＰＥの値がＳＵＢＭＩＴ又はＲＥＳＥＴ
であり、しかも、属性ＶＡＬＵＥがあれば、その値。例
えば、 「<INPUT type="Submit" value="記録"> <INPUT type="Reset" value="クリア">」 の場合は、「きろく」と「くりあ」を登録する。また、
属性ＶＡＬＵＥがなければ、属性ＴＹＰＥの値。例え
ば、 「<INPUT type="Submit"> <INPUT type="Reset">」 の場合は、「さぶみっと」「さぶみっとぅ」及び「りせ
っと」「りせっとぅ」等を登録する。

【０１０６】（ｂ）属性ＴＹＰＥの値がＴＥＸＴ又はＰ
ＡＳＳＷＯＲＤであり、しかも、属性ＶＡＬＵＥがあれ
ば、その値。例えば、 「<INPUT type=text name=word size=32 value="Hyper"
> 」 の場合は、「はいぱあ」を登録する。 （ｃ）属性ＴＹＰＥの値がＲＡＤＩＯ又はＣＨＥＣＫＢ
ＯＸの場合、次のタグ迄の間のテキスト。例えば、 「<INPUT type=radio name=srt value="2" checked> 型
番昇順 <INPUT type=radio name=srt value="3"> 連絡日降順<B
R> 」の場合は、「かたばん」「しょおじゅん」「れん
らくび」「こおじゅん」を登録する。

【０１０７】さて、音声認識手段４は、認識語彙記憶手
段６から語彙を抽出し、音声認識処理を行うが、本処理
を高速化するため、音声認識率の高い語彙から順に抽出
する必要がある。第３の実施形態では、文脈に沿った形
で、語彙の登録が行われることになるため、語彙の登録
時期が古くなればなる程、音声認識処理時にヒットする
可能性が低くなる。従って、最新の登録語彙から順に抽
出することが望ましい。

【０１０８】また、認識語彙記憶手段６には物理的な容
量制限が存在するため、いつかは登録語彙が満タン状態
となり、追加登録不能となる。この対策として、語彙記
憶手段６内の記憶領域を、固定的に保持し続ける分とそ
うでない分とに分ける方法、保持内容が変動する分のみ
を認識語彙記憶手段６内に登録し、固定的に保持し続け
る分は、音声認識手段４内の語彙辞書部８２（図１５参
照）等の別の場所を利用する方法がある（後者の場合、
例えば、工場出荷時に、装置に予め登録された分のみ
が、固定的に保持されることになる）。尚、保持内容が
変動する部分の記憶方式としては、登録語彙が古くなる
程、音声認識処理時にヒットする可能性が低くなること
から、最も古い登録情報から順番に最新情報が上書きさ
れる、リングバッファ記憶形式を用いることが望まし
い。

【０１０９】第３の実施形態の場合、音声ブラウザ１
が、ＨＴＭＬテキストの解析結果から、音声認識率を向
上させる語彙を抽出しているが、語彙の抽出には時間が
掛かる上に、漢字、外国語及び特殊文字の読み方を仮名
文字に変換するための、変換規則を記した巨大な辞書を
保持する必要があるという課題があった。次に述べる、
第４の実施形態は、語彙の抽出を簡略化する目的で、語
彙自身をＨＴＭＬテキスト内に埋め込むことを提案する
ものである。

【０１１０】次に、図４に示す本発明の一実施例を表す
ブロック図、及び、図８に示す音声ブラウザ１の動作例
を示すフローチャートを用いて、第４の実施形態の動作
内容を説明する。

【０１１１】ブラウザ搭載装置５０は、ブラウザ５１の
指示で、通信手段５２を介して、ネットワーク５８に接
続し、インターネット上のＷｅｂサーバにアクセスし、
ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３
に格納する。音声ブラウザ１は、これを読取り、第１の
実施形態に記すとおり最適化された読み上げ文章を構築
する（図８のステップＳ３）。その後、ＨＴＭＬテキス
トを解析し、語彙抽出を行うが、その方法は以下のとお
り。ＨＴＭＬテキストを検索し、個々のＨＴＭＬタグに
対して、「語彙を指定する属性」を含むか否かを調べる
（ステップＳ１５）。ＨＴＭＬタグが、語彙を指定する
属性を含む場合、属性の値、即ち、語彙を読取り、読取
られた語彙を認識語彙記憶手段６に登録する（ステップ
Ｓ１６）。

【０１１２】他方、ＨＴＭＬタグが、語彙を指定する属
性を含まない場合、第３の実施形態で示したとおり、音
声認識手段４で行われる音声認識の認識率を向上させる
語彙を抽出し、抽出された語彙を認識語彙記憶手段６に
登録する（ステップＳ１４）。その上で、音声ブラウザ
１は、最適化された読み上げ文章を、音声合成手段２に
転送し、音声出力手段３を通して、音声出力する（ステ
ップＳ４）。使用者が発した音声指示は、第２の実施形
態に記すとおり、音声入力手段５に取込まれ、認識語彙
の辞書として、認識語彙記憶手段６に登録された語彙を
使用する音声認識手段４によって音声認識された後、音
声ブラウザ１により、次のアクションが実行される。

【０１１３】ステップＳ１５に記した、語彙を指定する
属性を含むか否かを調べるくだりに関して、例えば、語
彙を指定する属性をＶＯＣＡＢＵＬＡＲＹと仮定すれ
ば、ＨＴＭＬテキストは以下のとおりとなる。

【０１１４】（機能１５） 「<INPUT type="Submit" value="記録" vocabulary="き
ろく"> <INPUT type="Reset" value="クリア"> 」

【０１１５】この場合、type="Submit" で指定されるＩ
ＮＰＵＴタグ側では、ステップＳ１６が実行され、属性
ＶＯＣＡＢＵＬＡＲＹの値”きろく”が、認識語彙記憶
手段６に登録される。他方、type="Reset"で指定される
ＩＮＰＵＴタグ側では、ステップＳ１４が実行され、属
性ＶＡＬＵＥの値”クリア”から抽出される語彙”くり
あ”が、認識語彙記憶手段６に登録される。

【０１１６】第４の実施形態に関して、認識に必要な語
彙文法情報を、電話回線ネットワークを介して、情報サ
ービスシステム側からユーザ端末側に送り込むという発
明の基本部分は、先に特許第２６５５０８６号にて開示
されている。従って、第４の実施形態は、特許第２６５
５０８６号を具体的な装置の形態に展開した発明である
といえる。尚、特許第２６５５０８６号を応用し、別の
装置の形態に展開した先願例であり、しかも第４の実施
形態に最も構造が似ている発明としては、図１６に示す
特開２０００−１０５６８１号がある。しかし、本発明
から、第４の実施形態を容易に類推することは、以下の
理由により困難である。

【０１１７】（理由１）図１６の発明は、装置を車載用
情報端末に限定していること。 （理由２）情報端末３０から情報センタ３２に送信され
る情報は、ＵＲＬではなく、「情報コード」（例えば、
コンビニエンスストアの場合、ＦＦ００７Ａ８Ｅ等の特
殊なコード）であること。即ち、複数の情報センタ３２
にアクセスできるように考慮されていない点が、インタ
ーネット通信技術を応用したブラウザ搭載装置を対象と
した本発明からかけ離れていること。

【０１１８】（理由３）上記情報コードを受けて、情報
センタ３２から情報端末３０に返信される情報は、ＨＴ
ＭＬではなく、その情報コードに対応したデータ（例え
ば、コンビニエンスストアに関する一連の情報）である
が、それを音声で読み上げることは触れていないこと。
特に、目の不自由な方々の便宜を考慮した読み上げ方の
記述は、見出せないこと。

【０１１９】（理由４）情報センタ３２から情報端末３
０に送信される語彙情報は、単に最新版であるだけに過
ぎないこと。即ち、情報コードに対応するデータに合わ
せて、音声認識率を最も向上させ得る語彙を、その都度
送信するという発想が存在しないこと。

【０１２０】最後に、既存のブラウザ５１に音声ブラウ
ザ１の機能を持たせ、ただ一つのブラウザのみを搭載し
た装置とすることは、同業他社には容易類推可能な範囲
である。

【０１２１】また、音声認識手段４による音声認識率が
１００％にならない場合等に、認識結果（テキスト形
式）を、音声合成手段２にも転送し、音声出力手段３を
通して、音声出力させることで、話者に認識結果を確認
させることも、容易類推可能な範囲である。この場合、
仮に音声合成手段２が、最適化された読み上げ文章を読
み上げ中であったとした場合には、（１）読み上げを中
止し、認識結果を音声出力させることも、（２）全ての
読み上げ処理が完了してから、認識結果を音声出力させ
ることも、（３）読み上げを一時的に中断し、認識結果
の音声出力後、中断した読み上げを再開させることも可
能であり、いずれも容易類推可能な範囲である。

【０１２２】（他の実施例）図９は、ｉモード携帯電話
機による第２の実施形態を示すブロック図である。図９
を参照すると、本第２の実施形態は、従来技術を表す図
１４に対して、ＬＳＩ６５に内蔵される、ＰＤＣ制御部
７１、音声処理部７２及びＰＤＣ−Ｐ制御部７３と、音
声認識／合成ＬＳＩ６４との間の接続を切換えるスイッ
チ７が追加されており、加えて、ＰＤＣ−Ｐ制御部７３
が、ＲＯＭ６９及びＲＡＭ７０と連携し、音声ブラウザ
１の機能をより効果的に果たすようにと変更されてい
る。

【０１２３】スイッチ７は、通常は、音声認識／合成Ｌ
ＳＩ６４と音声処理部７２が接続されるように切り換え
られている。この結果、従来技術を表す図１４と回路が
等価になり、従来のｉモード携帯電話機として使用する
ことができる。

【０１２４】第１の実施形態及び第２の実施形態で使用
する場合には、音声認識／合成ＬＳＩ６４と、音声ブラ
ウザ１の機能を果たすＰＤＣ−Ｐ制御部７３が接続され
るように、スイッチ７を切り換える（図９は、その時の
状態を示した図である）。

【０１２５】無線部６６を介して受信されたＨＴＭＬテ
キストは一旦ＲＡＭ７０に蓄積される。ＰＤＣ−Ｐ制御
部７３の音声ブラウザ機能を用いて解析されたＨＴＭＬ
テキストは、ハイパーテキストとして表示部６８に表示
されると共に、最適化された読み上げ音声テキストに変
換され、音声認識／合成ＬＳＩ６４に送付される。音声
認識／合成ＬＳＩ６４はＡＤＰＣＭ複号機能を用いて、
これを複号化し、Ａ／Ｄコンバータ６２に送付する。Ａ
／Ｄコンバータ６２は、これをＤ／Ａ変換し、レシーバ
６０を通して、読み上げ音声として出力する。一方、使
用者からの音声指示は、マイク６１を通して入力され、
Ａ／Ｄコンバータ６２でＡ／Ｄ変換（符号化）された
後、音声認識／合成ＬＳＩ６４により、音声認識結果と
してテキスト化され、ＰＤＣ−Ｐ制御部７３に渡され
る。ＰＤＣ−Ｐ制御部７３は、音声ブラウザ機能を用い
て、これを解析し、音声指示と認められれた場合、その
指示を実行する。

【０１２６】尚、本発明の別の応用例として、図９のス
イッチ７を切換えて、音声認識／合成ＬＳＩ６４とＰＤ
Ｃ制御部７１が接続されるようにした場合を想定するこ
とができる。この場合、ＰＤＣ制御部７１単体で、音声
認識によりテキスト化された音声情報を、相手局にテキ
スト形式で送信し、逆に受信されたテキスト形式の情報
を音声に再現して、音声出力するという通信方式が可能
になる。これは、もはやブラウザ装置の枠組みから外れ
てしまうが、一つの発明として、その具体的な動作内容
を、以下に記す。

【０１２７】簡易メール（ＮＴＴ呼称：ショートメー
ル）が、電話により、文字をやり取りする通信方式であ
ることは、従来技術の中で述べたとおりである。一方、
目の不自由な方々にとって、簡易メールは、送信時、メ
ール文章のデータ入力が必要であるが、送信したい文字
の選択が、ボタンの押下順序や回数を組み合せて行う方
式であるため、複雑なボタン操作がどうしても必要であ
り、苦痛な代物であった。加えて、受信したデータは、
受信テキストが画面に表示されるだけであり、目の不自
由な方々には読むことができなかった。

【０１２８】図９の発明に拠れば、使用者からの音声情
報は、マイク６１を通して入力され、Ａ／Ｄコンバータ
６２でＡ／Ｄ変換（符号化）された後、音声認識／合成
ＬＳＩ６４により、音声認識されて、テキスト化され
る。該テキスト化された音声情報を、スイッチ７を介し
て、ＰＤＣ制御部７１に取込み、ＲＡＭ７０に格納す
る。ＰＤＣ制御部７１は、ショートメール符号化機能を
用いて、これを、複数のプッシュボタンの、各々の押下
回数の組み合わせ、即ち、プッシュボタン音の組み合せ
へと変換し、無線部６６を介して、簡易メールとして、
メールセンタ（ＮＴＴの場合、ショートメールセンタ）
宛に発信する。

【０１２９】他方、相手局は、メールセンタからの着信
通知を受けて、ＲＡＭ７０上にダウンロードした簡易メ
ールを、ＰＤＣ制御部７１が有するショートメール複合
化機能を用いて、テキストに逆変換し、更に、スイッチ
７を介して、音声認識／合成ＬＳＩ６４へ送付し、ここ
で複号化した後、Ａ／Ｄコンバータ６２でＤ／Ａ変換
し、レシーバ６０で読み上げ音声として出力する。

【０１３０】この結果、受信した簡易メールは装置自身
が読み上げ、また送信時には、音声で入力すると、装置
自身が自動的に簡易メールに変換して、メールセンタ宛
に発信するため、複雑なボタン操作に煩わされる必要も
なくなり、目の不自由な方々は勿論のこと、目に不自由
しない方々でさえも、その恩恵を享受できる。加えて、
目の不自由な方々も、簡易メール（ショートメール）に
よるコミュニケーションの輪に参加する事が出来る様に
なり、逆に、目に不自由しない、従来からの簡易メール
（ショートメール）利用者にとっては、相手の目が不自
由か否かを意識する必要はない為、通常の電話同様、両
者にとって、バリアフリーなコミュニケーション関係を
構築・維持出来るものと期待される。尚、本効果は、ｅ
−Ｍａｉｌ（呼称：ｉモードメール）の場合でも、同様
に得られる。

【０１３１】図１０は、ｉモード携帯電話機による第４
の実施形態の一実施例を示すブロック図である。図１０
を参照すると、本第４の実施形態は、第２の実施形態を
表す図９に対して、発声される可能性のある語彙を記憶
する認識語彙記憶部８を追加し、加えて、音声認識／合
成ＬＳＩ６４を、音声認識時、認識語彙の辞書として、
認識語彙記憶部８を使用するものへと変更し、更に、Ｐ
ＤＣ−Ｐ制御部７３を、解析したＨＴＭＬテキスト中に
語彙が直接含まれる場合には、その語彙を抽出し、語彙
が直接含まれない場合には、音声認識／合成ＬＳＩ６４
で行われる音声認識の認識率の向上させ得る語彙を抽出
し、抽出した語彙を認識語彙記憶部８に記憶させるよう
なものへと変更している。

【０１３２】第４の実施形態で使用する場合には、音声
認識／合成ＬＳＩ６４と、音声ブラウザ１の機能を果た
すＰＤＣ−Ｐ制御部７３が接続されるように、スイッチ
７を切り換える（図１０は、その時の状態を示した図で
ある。）。

【０１３３】無線部６６を介して受信されたＨＴＭＬテ
キストは、一旦ＲＡＭ７０に蓄積される。ＰＤＣ−Ｐ制
御部７３の音声ブラウザ機能を用いて解析されたＨＴＭ
Ｌテキストは、ハイパーテキストとして表示部６８に表
示されると共に、語彙が抽出されて認識語彙記憶部８に
記憶され、その上で最適化された読み上げ音声テキスト
へと変換を行い、音声認識／合成ＬＳＩ６４へと送付す
る。音声認識／合成ＬＳＩ６４は、ＡＤＰＣＭ複号機能
を用いてこれを複号化し、Ａ／Ｄコンバータ６２に送付
する。Ａ／Ｄコンバータ６２は、これをＤ／Ａ変換し、
レシーバ６０を通して読み上げ音声として出力する。一
方、使用者からの音声指示は、マイク６１を通して入力
され、Ａ／Ｄコンバータ６２でＡ／Ｄ変換（符号化）さ
れた後、音声認識／合成ＬＳＩ６４により、音声認識結
果としてテキスト化され、ＰＤＣ−Ｐ制御部７３に渡さ
れる。音声認識／合成ＬＳＩ６４は、音声認識時、認識
語彙の辞書として、認識語彙記憶部８に登録された語彙
を使用する。ＰＤＣ−Ｐ制御部７３は、音声ブラウザ機
能を用いてこれを解析し、音声指示と認められた場合、
その指示を実行する。

【０１３４】尚、上述の実施形態は本発明の好適な実施
の一例である。但し、これに限定されるものではなく、
本発明の要旨を逸脱しない範囲内において種々変形実施
が可能である。

【０１３５】

【発明の効果】以上の説明より明らかなように、請求項
１記載の発明のブラウザ搭載装置は、ＨＴＭＬテキスト
を解析し、解析結果からＨＴＭＬテキストの読み上げ方
法を最適化し、ＨＴＭＬテキストの読み上げ音声の合成
を指示するブラウザと、このブラウザが最適化した読み
上げ方法により、ＨＴＭＬテキストの読み上げ音声を合
成し、合成した音声を出力する。

【０１３６】第１の効果は、ブラウザ搭載装置の小型・
軽量化を廉価に実現できる点にある。その理由は、ＰＤ
Ｃ制御部、ＰＤＣ−Ｐ制御部及び音声処理部が使用す
る、音声合成及び音声認識処理回路を効率化する事で、
部品点数を削減できるためである。第２の効果は、目の
不自由な方々をもインターネットの世界へ誘うことがで
きる点にある。その理由は、ブラウザがＨＴＭＬテキス
トを解析し、目の不自由な方々にとって理解しやすい文
章をデザインし、読み上げてくれるからである。加え
て、ブラウザは、使用者の発した音声を認識し、適切な
音声指示である場合には、それを実行するため、目の不
自由な方々にとって苦痛な、文字入力やクリック操作
が、大幅に不要となるためである。

【０１３７】第３の効果は、コンテンツ・プロバイダに
とって、目の不自由な方々を対象としたコンテンツをデ
ザインすることが、それほど負担にはならない点にあ
る。その理由は、コンテンツ・プロバイダが目の不自由
な方々向けに適切なコンテンツを提供することは、従来
は不可能であったり、あるいは、コンテンツの作成に時
間が掛かり、高価になるが、本発明によって、その制約
は比較的容易に緩和されるためである。加えて、ｉモー
ド携帯電話機向けに開発されたコンパクトＨＴＭＬでコ
ンテンツをデザインすることができれば、コンパクトＨ
ＴＭＬが有する諸機能との相乗効果により、その制約が
一層軽減されるためである。

【図面の簡単な説明】

【図１】本発明のブラウザ搭載装置の実施形態を表すブ
ロック構成図である。

【図２】第２の発明の一実施例を表すブラウザ搭載装置
のブロック図である。

【図３】第３の発明の一実施例を表すブラウザ搭載装置
のブロック図である。

【図４】第４の発明の一実施例を表すブラウザ搭載装置
のブロック図である。

【図５】第１の実施形態のブラウザ搭載装置に搭載され
る音声ブラウザの動作例を示すフローチャートである。

【図６】第２の実施形態のブラウザ搭載装置に搭載され
る音声ブラウザの動作例を示すフローチャートである。

【図７】第３の実施形態のブラウザ搭載装置に搭載され
る音声ブラウザの動作例を示すフローチャートである。

【図８】第４の実施形態のブラウザ搭載装置に搭載され
る音声ヴラウザの動作例を示すフローチャートである。

【図９】第１および第２の実施形態の一実施例を表すｉ
モード携帯電話機のブロック図である。

【図１０】第３および第４の実施形態の一実施例を表す
ｉモード携帯電話機のブロック図である。

【図１１】従来のブラウザ搭載装置のブロック図であ
る。

【図１２】従来のｉモードサービスのネットワーク構成
図である。

【図１３】従来のｉモードサービスのプロトコルスタッ
クである。

【図１４】従来のｉモード携帯電話機のブロック図であ
る。

【図１５】従来の音声認識装置のブロック図である。

【図１６】従来例であり第４の実施形態に類似する先願
発明例の音声情報処理装置のブロック図である。

【符号の説明】

１ 音声ブラウザ ２ 音声合成手段 ３ 音声出力手段 ４ 音声認識手段 ５ 音声入力手段 ６ 認識語彙記憶手段 ７ スイッチ ８ 認識語彙記憶部 ３０ 情報端末 ３１ ネットワーク ３２ 情報センタ ３３ 音声入力手段 ３４ 音声認識手段 ３５ 音声認識用テーブル ３６ 音声合成手段 ３７ 通信手段 ３８ ＣＰＵ ３９ 表示手段 ４０ 音声出力手段 ４１ 通信手段 ４２ ＣＰＵ ４３ 音声認識用テーブル ４４ 情報提供メニューテーブル＆ＤＢ ５０ ブラウザ搭載装置 ５１ ブラウザ ５２ 通信手段 ５３ 記憶手段 ５４ 表示手段 ５５ キーボード ５６ マウス ５７ 入力手段 ５８ ネットワーク ６０ レシーバ ６１ マイク ６２ Ａ／Ｄコンバータ ６３ スイッチ ６４ 音声認識／合成ＬＳＩ ６５ ＬＳＩ ６６ 無線部 ６７ 操作部 ６８ 表示部 ６９ ＲＯＭ ７０ ＲＡＭ ７１ ＰＤＣ制御部 ７２ 音声処理部 ７３ ＰＤＣ−Ｐ制御部 ８０ 分析、雑音除去部 ８１ 認識処理部 ８２ 語彙辞書部 ８３ 文法モデル部 ８４ 不特定話者半音節モデル記憶部 ８５ 話者適応後半音節モデル記憶部 ８６ 話者適応制御部 １００ ｉモード携帯電話機 １０１ ｉモードサーバ １０２ コンテンツ １５０ インターネット １５１ ＰＤＣ−Ｐネットワーク １５２ ＰＤＣネットワーク １５３ 専用線 １５４ パケット通信

【手続補正書】

【提出日】平成１２年１２月７日（２０００．１２．
７）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図１１

【補正方法】変更

【補正内容】

【図１１】

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ１０Ｌ 13/08 Ｇ１０Ｌ 3/00 Ｒ 15/06 Ｈ 15/00 ５２１Ｓ Ｈ０４Ｍ 11/00 ３０２ ５５１Ａ Ｆターム(参考） 5D015 BB02 GG01 KK01 5D045 AA07 AB04 AB30 5E501 AA04 AA13 AB03 AB15 AC25 BA11 CA08 CB15 EA21 FA32 FA43 5K101 KK16 LL12 NN07 NN08 NN16 NN22 SS07 UU19

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ＨＴＭＬテキストの閲覧を行うブラウザ
   を搭載する装置において、 前記ＨＴＭＬテキストを解析し、解析結果から前記ＨＴ
   ＭＬテキストの読み上げ方法を最適化し、前記ＨＴＭＬ
   テキストの読み上げ音声の合成を指示するブラウザと、 前記ブラウザが最適化した読み上げ方法により前記ＨＴ
   ＭＬテキストの読み上げ音声を前記ブラウザの指示によ
   り合成する前記音声合成手段と、 前記音声合成手段が合成した音声を出力する音声出力手
   段と、 携帯電話の通常の通話機能を司るＰＤＣ制御手段と、 インターネットプロトコルを応用したｉモードサービス
   等への接続処理機能を司るＰＤＣ−Ｐ制御手段と、 音声処理を司る音声処理手段と、 音声認識を行う音声認識手段と、 前記ＰＤＣ制御手段および前記ＰＤＣ−Ｐ制御手段およ
   び前記音声処理手段の各部と前記音声認識手段との間を
   選択的に接続するスイッチとを有し、 前記音声合成および前記音声認識の処理回路の効率化を
   図ったことを特徴とするブラウザ搭載装置。
2. 【請求項２】 使用者が発した音声を取込む音声入力手
   段をさらに有し、 前記音声認識手段は、前記音声入力手段が取込んだ前記
   音声から前記ブラウザに対する制御指示を認識し、該制
   御指示を前記ブラウザに伝達し、前記ブラウザが前記音
   声認識手段から伝達された前記制御指示を解析し、適切
   な次のアクションを行うことを特徴とする請求項１記載
   のブラウザ搭載装置。
3. 【請求項３】 発声される可能性のある語彙を記憶する
   認識語彙記憶手段をさらに有し、 前記音声認識時に認識語彙の辞書として前記認識語彙記
   憶手段を前記音声認識手段が使用して前記ＨＴＭＬテキ
   ストを解析し、 前記解析結果から前記音声認識手段が行う音声認識の認
   識率を向上させ得る語彙を抽出し、該抽出した語彙を前
   記認識語彙記憶手段に前記ブラウザが記憶させることを
   特徴とする請求項２に記載のブラウザ搭載装置。
4. 【請求項４】 前記ＨＴＭＬテキスト中に語彙が直接含
   まれる場合に、該語彙を抽出して前記認識語彙記憶手段
   に前記ブラウザが記憶させることを特徴とする請求項３
   に記載のブラウザ搭載装置。
5. 【請求項５】 前記音声処理に伴う話者の性別、音声の
   ピッチ／スピード、読み上げピッチの加速具合い等につ
   いては、設定で変更可能としたことを特徴とする請求項
   １から４の何れか１項に記載のブラウザ搭載装置。
6. 【請求項６】 絵文字等の外字の読み上げ方を、設定で
   変えられることとしたことを特徴とする請求項１から５
   の何れか１項に記載のブラウザ搭載装置。