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

Description

【０００１】
【発明の属する技術分野】
本発明は、ブラウザ搭載装置に関し、特に、ＨＴＭＬテキスト、あるいは、その応用テキストを閲覧可能な「ブラウザ」を搭載した情報処理機能を有するブラウザ搭載装置に関する。
【０００２】
【従来の技術】
従来、ブラウザ搭載装置は、例えば、インターネットへ適用される。ここでのインターネットとは、コンピュータ間通信のネットワークであり、様々なネットワークが相互に接続し、大規模なネットワークとなったものである。その歴史は、１９６０年代に米国国防省の関連機関であるＤＡＲＰＡ（Ｄｅｆｅｎｓｅ ｏｆ Ａｄｖａｎｃｅｄ Ｒｅｓｅａｒｃｈ Ｐｒｏｊｅｃｔｓ Ａｇｅｎｃｙ）が実験的に開始したＡＲＰＡｎｅｔに端を発する。
【０００３】
１９８０年代初め、一般利用者にＡＲＰＡｎｅｔの利用を認めるに伴い、コンピュータのＯＳの一つ：ＢＳＤ ＵＮＩＸで利用される通信プロトコル：ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）が、同ネットにも採用され、この結果、同ネット接続時のコンピュータ機種依存性が排除された。また、同時期、大学や研究機関を中心に、学術的な利用を目的としたＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の構築が始まっており、研究者間での情報交換を積極的に行うため、これらのＬＡＮは相互に接続され、ＡＲＰＡｎｅｔとも接続され、最終的には全米に跨る大規模なネットワークへと発展した。この大規模ネットワークこそがインターネットであり、その拡大は現在も全世界の隅々に向けて進んでいる。
【０００４】
インターネット通信技術とは、インターネット上の別のコンピュータと、インターネットを介して、通信を行う上で必要となる技術群を指し、単にハードウェアに留まらず、広くインターネット・プロトコルをも含む。
【０００５】
インターネット・プロトコルとは、インターネット上で通信を行うためのプロトコル（通信手順）であり、上述のＴＣＰ／ＩＰが最も基本的なプロトコルである。これをベースとして、例えば、ファイル転送を行う場合は、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ファイル転送プロトコル）と呼ばれるプロトコルを使用し、ｅ−Ｍａｉｌを送信する場合は、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：簡易メール転送プロトコル）と呼ばれるプロトコルを使用し、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスを提供するコンピュータを意味する、Ｗｅｂサーバにアクセスする場合は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ハイパーテキスト転送プロトコル）と呼ばれるプロトコルを使用する。
【０００６】
ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：ハイパーテキスト記述言語）とは、ハイパーテキストを記述するための言語体系である。Ｗｅｂページには、ハイパーテキストが用いられるが、今や世界のデジタル・コンテンツの９９％が、インターネットの世界標準であるＨＴＭＬで記述されていることから、最近では、インターネット接続が可能な装置と言えば、単にインターネットに接続できるだけではなく、インターネット上のＷｅｂサイトからＨＴＴＰプロトコルを用いてダウンロードしたＨＴＭＬテキストをハイパーテキストとして閲覧できる装置、即ち、「ブラウザ」と呼ばれる閲覧ソフトを予め搭載した装置（或いは、オプションとして別途搭載できる装置）を指すように、その解釈が変わり始めてきている。
【０００７】
ブラウザを搭載したコンピュータの動作概要を、図１１に記す。コンピュータ５０は、キーボード５５やマウス５６等から構成される入力手段５７、ＣＲＴや液晶ディスプレイ等の表示手段５４、メモリや磁気ディスク装置等の記憶手段５３、及び、内蔵モデム等の通信手段５２を有し、ブラウザ５１がこれらを制御する。ブラウザ５１は、通信手段５２を介して、ネットワーク５８に接続し、インターネット上のＷｅｂサーバにアクセスする。ＷｅｂサーバからダウンロードしたＨＴＭＬテキストは、一旦記憶手段５３に格納される。ブラウザ５１は、これを解析し、ハイパーテキストとして、表示手段５４に表示する。また、読みたいページのアドレスを指定するためのＵＲＬ（Ｕｎｉｆｏｒｍ ＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）入力や、ハイパーテキスト中に含まれるリンクやアイコンのクリック等は、入力手段５７を介して行う。
【０００８】
当初、インターネットに接続される装置はコンピュータだけであったが、昨今では、携帯式の情報端末に加えて、テレビやゲームマシン、更に携帯電話においても、ブラウザの装備を含めて、インターネットへの接続機能を装備するものが現れた。
【０００９】
携帯電話が搭載するブラウザは、携帯電話がパソコンと比較して処理能力やメモリ容量が乏しい。例えば、最初のブラウザ対応携帯電話機に搭載されたローパワーＳＲＡＭは８Ｍｂｉｔｓに過ぎず、カラー化が実現された昨今でも最大１６Ｍｂｉｔｓに過ぎない。加えて、表示能力、表示サイズ、操作方法等にも制限があることから、携帯電話機用に性能を特化した「マイクロブラウザ」が使用されている。本ブラウザを用いて、携帯電話用に操作面での仕様拡張が行われた「コンパクトＨＴＭＬ」を閲覧できる。
【００１０】
携帯電話からインターネットに接続する場合、「携帯電話網」の中にインターネット接続を中継する機能があり、ここを経由して、インターネットへの接続を行う。
【００１１】
具体的には、１９９９年２月２２日、株式会社ＮＴＴドコモが「ｉモードサービス」を開始したが、これが、携帯電話からインターネットへの乗入れを可能とした最初のサービスである。
【００１２】
なお、ｉモードサービスには、ＵＲＬの直接入力により、インターネット上のＷｅｂサイトへのアクセスを実現する「インターネット接続サービス」以外にも、ｅ−Ｍａｉｌ（呼称：ｉモードメール）、簡易メール（呼称：ショートメール）等の受発信や転送機能を司る「メール・サービス」、及び、簡単なボタン操作だけで、コンテンツ・プロバイダが提供する、以下のコンテンツへのアクセスを実現する「オンライン・サービス（別名：サイト接続サービス）」等がサポートされている。
【００１３】
（１）銀行振込や航空券・ホテル・チケット予約等の取引系サービスを提供するコンテンツ。
（２）乗換え案内や字引等のデータベース系サービスを提供するコンテンツ。
（３）ニュース・天気予報や株価情報等の生活情報系サービスを提供するコンテンツ。
（４）ＦＭ局情報やゲーム・占い等のエンターテイメント系サービスを提供するコンテンツ。
【００１４】
即ち、ｉモードサービスとは、上記サービスを提供するシステムが、インターネット上に直接構築されている訳ではなく、図１２に記すとおり、インターネット１５０とは異なる、ＮＴＴドコモ社独自のネットワークである「ＰＤＣ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ｃｅｌｌｕｌａｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：デジタル移動通信方式）移動パケット通信ネットワーク」（呼称：ＰＤＣ−Ｐネットワーク）１５１上に、インターネットとの中継機能を有する「ｉモードサーバ」１０１を配した形で、構築されたシステムである。ここで、ＰＤＣ−Ｐネットワーク１５１は、同社が「ＤｏＰａ」／ドーパと命名したパケット通信サービスを行う目的で、予め構築していた全国パケット通信網に過ぎない。しかし、ＰＤＣ−Ｐネットワーク１５１上でｉモード通信を行う場合には、ＰＤＣ−Ｐネットワーク１５１上のデータ転送プロトコルとして、ｉモード通信に特化したインターネット・プロトコルを採用し、データ転送の効率化に心掛けている。具体的には、以下のとおりである（図１３参照）。
【００１５】
（１）ｉモード携帯電話機１００とＰＤＣ−Ｐネットワーク１５１を接続するプロトコルとして、ベアラ（データ転送プロトコルの最下位層に当たり、物理層とデータリンク層を含む）の上位に、ＴＬＰ（Ｔｒａｎｓｐｏｒｔ ＬａｙｅｒＰｒｏｔｏｃｏｌ：トランスポート層プロトコル）を採用。ＴＬＰは、インターネットプロトコルを簡略化して、ｉモード通信向けに最適化したものである。
【００１６】
（２）ＰＤＣ−Ｐネットワーク１５１とｉモードサーバ１０１との接続には、ＴＣＰ／ＩＰに加えて、ＵＩＴＰ（Ｕｓｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：加入者情報伝達プロトコル）とＮＷＭＰ（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ：ネットワーク管理プロトコル）の３プロトコルを採用。ＵＩＴＰとＮＷＭＰは、ＴＬＰがインターネットプロトコルを簡略化したものであるために生じる不具合を補いつつ、しかも、課金制御や保守機能を実現するなど、ｉモード通信向けに最適化を施したものである。
【００１７】
（３）ｉモードサービスのアプリケーション通信プロトコルとして、ＡＬＰ（Ａｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ：アプリケーション層プロトコル）を採用。これは、インターネット・プロトコルの世界標準であるＨＴＴＰを改良し、ｉモード通信向けに最適化を施したものである。
【００１８】
なお、ＡＬＰは、通信フォーマットをＨＴＴＰと同一にすることで、インターネットへの乗入れを容易化している反面、ｉモードサービスに特有の機能の実現と通信データ量の削減を図るため、以下の機能が付加されている。
【００１９】
（ａ）サービス上は不要な「ＨＴＴＰヘッダ」を付与しない。この結果、データ量が削減される。
（ｂ）ｅ−Ｍａｉｌの送受信は、ＨＴＴＰで行う。即ち、ｅ−Ｍａｉｌは、ＨＴＴＰフォーマットに変換の上、転送される。
【００２０】
（ｃ）着信通知信号を付与している。この結果、例えば、メールサーバ機能を併せ持つｉモードサーバ１０１に、加入者宛のｅ−Ｍａｉｌが届いた場合、ｉモードサーバ１０１から加入者のｉモード携帯電話機１００に着信通知信号が送付され、その旨が通知される。なお、ｉモード携帯電話機１００からｉモードサーバ１０１へのサービス要求を「プル型」と呼ぶのに対し、ｉモードサーバ１０１からｉモード携帯電話機１００へのサービス要求を「プッシュ型」と呼ぶ。
【００２１】
ｉモードサービスのシステム構成を理解することで、インターネット通信技術が、インターネットの世界に限らず、携帯電話網等の他のネットワークにも広がり始めてきている事実を理解できる。これは、他のネットワークからインターネットへの乗入れを容易に実現して、インターネット世界の内外に存在する、種々のネットワーク資産を利用するためである。
【００２２】
従来のｉモード携帯電話機のブロック図を、図１４に記す。特開平１１−１１２６３３号に記される、従来の携帯電話機のブロック図と同一の図であるが、ｉモード処理機能をＰＤＣ−Ｐ制御部７３としてＬＳＩ６５の内部に含めた形で記述している。
【００２３】
即ち、ｉモード携帯電話機は、通常の携帯電話機として使用するための機能として、受話器に相当するマイク６１とレシーバ６０、操作部６７、表示部６８、無線部６６、入出力音声をアナログ〜ディジタルの双方向に変換可能なＡ／Ｄコンバータ６２、各種固定データを記録するＲＯＭ６９、各種可変データを記録するＲＡＭ７０、及び、ＬＳＩ６５に内蔵され、携帯電話の通常の通話機能を司るＰＤＣ制御部７１とを有する。
【００２４】
次いで、ｉモードで使用するための機能として、ｉモード通信機能を司るＰＤＣ−Ｐ制御部７３を、ＬＳＩ６５に内蔵している。尚、ｉモードで使用する場合、マイク６１とレシーバ６０は使用しない。最近の装置では、着メロ演奏機能が付加されたが、本機能は、レシーバ６０のみを流用する。
【００２５】
最後に、電話番号の音声入力、登録済電話番号の別名による音声呼出し（「ボイスサーチ」と呼ばれる）、ファンクション機能の音声呼出し等の音声処理機能として、音声認識／合成ＬＳＩ６４と、音声情報の伝達方向を切換えるスイッチ６３、及び、ＬＳＩ６５に内蔵され、音声処理を司る音声処理部７２とを有する。
【００２６】
ＬＳＩ６５の内部にある、ＰＤＣ制御部７１、音声処理部７２及びＰＤＣ−Ｐ制御部７３は、使用者の立場からは、見掛け上、同時に動作するものではなく、各々を切換えながら使用するものとして映っている。具体例を挙げれば、ボイスサーチによる登録済電話番号の読出し時は、音声処理部７２のみが動作し、ＰＤＣ制御部７１とＰＤＣ−Ｐ制御部７３は休止中となる。読出された電話番号に発信（発呼）し、通常電話を開始する場合は、ＰＤＣ制御部７１が起動し、音声処理部７２とＰＤＣ−Ｐ制御部７３は休止状態となる。待受け受信時にｉモードボタンを押下することで、ＰＤＣ−Ｐ制御部７３が起動し、ＰＤＣ制御部７１と音声処理部７２は休止状態となる。ｉモード処理中に電話の着信があれば（着呼）、ＰＤＣ制御部７１が起動し、音声処理部７２とＰＤＣ−Ｐ制御部７３は休止状態となる。
【００２７】
ここで、簡易メール（ＮＴＴ呼称：ショートメール）機能についても、説明する。本機能は、ｉモードに固有の通信機能ではない。簡易メールとは、電話により、音声ではなく、文字をやり取りする通信方式である。その通信原理は、特定の文字を、複数のプッシュボタンの各々の押下回数に応じて表現するものである。即ち、プッシュボタン音の組み合せで、文字を表す。このため、メーカに依存せず、通常の携帯電話や自動車電話、更にプッシュボタン式の一般電話や公衆電話からでも、簡易メールを送信することができる。
【００２８】
簡易メールの送受信動作を、図１４を用いて説明する。送信時、操作部６７を介して入力されたテキストは、ＲＡＭ７０上に蓄積されると共に、表示部６８にも表示される。操作部６７上の発信キーの押下により、ＲＡＭ７０上に蓄積された入力テキストは、ＰＤＣ制御部７１で、各々の文字が、複数のプッシュボタンの、各々の押下回数の組み合わせへと変換され、無線部６６を介して、簡易メールとして、メールセンタ（ＮＴＴの場合、ショートメールセンタ）宛に発信される。一方、簡易メールの受信時は、相手局は、メールセンタからの着信通知を受けて、ＰＤＣ制御部７１の制御の下、簡易メールを、無線部６６を介してＲＡＭ７０上にダウンロードする。ＲＡＭ７０上に蓄積された簡易メールは、ＰＤＣ制御部７１によって、複数のプッシュボタンの各々の押下回数の組み合わせから、特定の文字へと一つずつ逆変換され、最後に、受信テキストとして表示部６８に表示される。
【００２９】
ＰＤＣ制御部７１が有する入力されたテキストを、上記の特定の文字を表現する複数のプッシュボタンの、各々の押下回数の組み合わせへと変換する機能を、「ショートメール符号化機能」と呼び、その逆の変換を行う機能を、「ショートメール複合化機能」と呼ぶ。
【００３０】
インターネット、あるいは、ｉモードのＰＤＣ−Ｐネットワークに代表されるインターネット通信技術を応用したネットワークに接続し、インターネットプロトコルの世界標準であるＨＴＴＰ、或いは、ｉモードのＡＬＰに代表されるＨＴＴＰを応用したプロトコルを用いて、本ネットワーク上で運営されている各種サービスにアクセスする。さらに、インターネットの世界標準であるＨＴＭＬ、或いは、ｉモードのコンパクトＨＴＭＬに代表される、ＨＴＭＬを応用した記述言語によって構築された各種コンテンツの中から、自分達にとって必要な情報を入手し、本サービスの恩恵を得る。
【００３１】
これらの利用形態は、今後更なる発展と広がりを見せる方向にある。例えば、固定電話、ファックス、公衆電話、受信チューナ、ビデオ、カメラ、冷蔵庫、電子レンジ、クーラー、洗濯機／乾燥機、医療機器、ＣＤ／ＡＴＭ、自動車、ロボット等の各種装置において、上記ネットワークへの接続機能の装備と、アクセスの結果得られた情報を実際のユーザに提供する際の方法（サービス内容）の検討が、既に開始されている。これら装置の増加は、上記サービスへのアクセスに一層の拍車を掛けるものとして、通信事業者やコンテンツプロバイダ等からも期待されている。
【００３２】
本発明は、上記ＨＴＭＬ、あるいは、ＨＴＭＬを応用した記述言語の閲覧が可能なブラウザ機能を装備した装置全般に関するものである。
【００３３】
なお、インターネットと似た言葉であるイントラネットとは、インターネット通信技術を採り入れて構築した、企業（等の）「内部」のネットワークを意味しており、他方、反意語のエクストラネットは、企業「間」のネットワークを表すが、いずれもインターネットの一部である。
【００３４】
本発明と技術分野が類似する先願発明例として、例えば下記のものがある。
（１）特開平１１−１１２６３３号公報の図１
（２）特開平１１−１６３９９５号公報の図１
（３）特開平１０−１９０７９７号公報の図１
（４）特許第２６５５０８６号の図１
（５）特開２０００−１０５６８１号公報の図１
【００３５】
【発明が解決しようとする課題】
しかしながら、上記の従来技術は、下記の各種の問題を伴う。
第１の問題点は、上記装置に提供される各種サービスは、目の不自由な方々にとって、益々使いづらいものとなっていく点である。その理由は、マルチメディアがインターネットの基盤となっていることから、提供されるサービス内容においても、当然マルチメディア的なものが多用される方向にあるが、マルチメディアの中には、文字や画像／映像（図、静止画、動画等）等の視覚を利用したものが多々あり、これらは目の不自由な方々にとって、大きな障壁（バリア）になるためである。特に、携帯電話機は、従来から、目の不自由な方々に対する配慮が脈々となされていた機器である（携帯電話機自身については、特開平１１−１６３９９５号を、その収容ホルダについては、特開平１０−１９０７９７号公報を参照）にもかかわらず、インターネット接続機能のサポートに関しては、この配慮が全くなされておらず、目の不自由な方々の期待を裏切る、心地良くない機能追加として、受け止められていた。
【００３６】
携帯電話機の例を具体的に記す。音声通話機能しかない従来型の携帯電話機を用いて電話を掛ける分には、０〜９及び発信ボタンを操作するだけなので、目の不自由な方々でも何とかこれを使用することができた。加えて、携帯電話機にワンタッチ（又はツータッチ）ダイヤル機能やボイスサーチ機能（音声認識に基づく登録済電話番号の読出し／発呼機能）等を追加することで、目の不自由な方々の負担を一層軽減することができた。更に、特開平１１−１６３９９５号では、ボタン部分への突起物の付与が提案されており、特開平１０−１９０７９７号では、収容ホルダのボタン部に点字状の突起物を付与し、携帯電話機を収納したまま、使用することが提案されている。
【００３７】
しかし、簡易メール機能（ショートメール等）を使用する場合には、送信時、メール文章のデータ入力が必要となるが、送信したい文字の選択が、ボタンの押下順序や回数を組み合せて行う方式であるため、複雑なボタン操作がどうしても必要となり、目の不自由な方々には、とても扱える代物ではなかった。最近では、外付けのキーボード（呼称：ｉボード）や、タッチペン形式のポインティング・デバイスが、オプションで提供されている機種もあるが、あくまでもボタン操作に不慣れな人向けの支援機能に過ぎず、目の不自由な方々にとって、これらは大差がない。いわんや、受信したデータについては、画面に表示されるだけであり、目の不自由な方々は、これを読むことができない。
【００３８】
更に、ｉモードサービスに至っては、送信時、データ入力以前に、画面上に表示される案内文を一旦読み、理解した上で、案内文中に指定されるボタン操作を、適切に行う事が要求されるが、目の不自由な方々には、要求された操作を、その通りに行う事が出来ない。
【００３９】
第２の問題点は、目の不自由な方々向けに適切なコンテンツを提供することが、コンテンツ・プロバイダには不可能であったり、あるいは、コンテンツの作成に時間が掛かり、高価になる点である。その理由は、目の不自由な方々に文字や画像／映像から構成されるコンテンツをそのまま提供することは失礼な話であるため、別法を採るとした場合、残された有効な情報提供手段は、現技術水準では音声のみである。このため、作成済のコンテンツを音声のみから構成される形に作り替えなければならず、その分、費用がかさみ、時間を要することとなる。
【００４０】
携帯電話機の例を具体的に記せば、ｉモードサービスの場合、コンテンツ・プロバイダは、ＨＴＭＬ４．０の機能縮小版である「コンパクトＨＴＭＬ」を用いてコンテンツを記述すれば良い。このため、普通にウェブ（Ｗｅｂ）ページを作れる人にとっては、特別に覚えなければならない事柄はほとんどなく、コンテンツの作成は比較的容易であった。他方、これを目の不自由な方々向けに、音声情報だけを用いた形に書き直す、とすれば、例えば、案内音声を記録したＷＡＶファイル（等）をダウンロードさせ、これを再生させるようにコンテンツを作り替える必要がある。しかし、現在の携帯電話機は、ピアノやギターなどの音色再生を目的としたＦＭ音源や多重和音機能等をサポートするのみであり、加えて、ダウンロードによって再生可能なサウンド系ファイルも、着メロ用のＭＩＤファイル（ＭＩＤＩ Ｄａｔａ Ｆｉｌｅ）のみである事から、音声は再生できず、音声案内を実現できない。
【００４１】
そもそも、ｉモードサービスの形態は、目の不自由な方々に情報を提供することが想定されていない。それは、ｉモードサービスのコンセプトが「話すケータイから使うケータイへ」だからである。そのことを考え合わせると、目の不自由な方々には使えないケータイが、一概に悪いとは責められない。むしろ、目の不自由な方々には、従来の音声通話機能で電話を掛けて頂き、コンテンツ・プロバイダの側では、その目的専用に、音声案内人を雇用して、教育後、その任に当たらせるなり、或いは、音声応答装置を購入し、その目的向けの専用記述言語を用いて、音声応答の手順等をプログラミングして運用するなりした方が簡便ですらある。勿論、その分、費用が嵩み、時間を要するが、それは止むを得ない。
【００４２】
本発明は、音声合成及び音声認識処理回路を効率化し、ブラウザ搭載装置の小型・軽量化を廉価に実現することを目的とする。その上で、本発明は、特性・性能向上、文字入力の高速化、操作性向上、文字入力の簡易化等を図ったブラウザ搭載装置を提供することを目的とする。
【００４３】
本発明の究極的な目的は、マンマシンインタフェースの改善（眼の不自由な方々でも操作可能とする）を図り、コンテンツ・プロバイダ側で発生する負担を極力抑えながら、眼の不自由な方々を、インターネットの世界に誘うことにある。
【００４４】
【課題を解決するための手段】
かかる目的を達成するため、請求項１の発明は、ｉモードサービスを提供するパケット通信網であるＰＤＣ−Ｐネットワークとの接続処理を制御するＰＤＣ−Ｐ制御手段によりＰＤＣ−Ｐネットワークに接続され、該ＰＤＣ−Ｐネットワークを介して接続されたインターネット等の通信ネットワークから受信したＨＴＭＬテキストを解析し、該解析結果を基に、前記ＨＴＭＬテキストを、音声として読み上げる方法を所定の基準により決定し、該決定された読み上げ方法により、前記受信したＨＴＭＬテキストを音声として合成する旨の指示を、音声合成手段に対して行うブラウザと、使用者が発した音声を取込む音声入力手段と、前記ブラウザの指示により、前記ＨＴＭＬテキストを音声として合成し、又は、前記音声入力手段により取り込まれた音声を認識する音声認識手段としても動作する音声合成手段と、前記音声合成手段により合成された音声を出力する音声出力手段と、前記ブラウザ、前記音声合成手段、及び、前記音声出力手段が実行する前記ＨＴＭＬテキストの音声出力動作の制御をする前記ＰＤＣ−Ｐ制御手段と、携帯電話の発信先の電話番号をボタン操作で入力する代わりに電話番号自体を音声により入力する場合、携帯電話に予め登録された発信先の電話番号を該電話番号と関連付けられた別名の音声により入力する場合、又は、携帯電話の使用中に所定のファンクション機能を動作させるために、該携帯電話に設置された各ファンクションキーを押下する代わりに、各ファンクション機能を音声により入力する場合に、それぞれ必要とされる所定の音声処理を行う音声処理手段と、携帯電話の待ち受け時、発信時、着信時、又は、通話時の、各モードにおける所定動作を制御するＰＤＣ制御手段と、前記ＰＤＣ−Ｐ制御手段、前記音声処理手段、及び、前記ＰＤＣ制御手段の各部と、前記音声合成手段との間を選択的に接続するスイッチと、を具備し、前記スイッチを介して、前記音声合成手段（兼前記音声認識手段）と前記ＰＤＣ制御手段とが接続される場合に、受信した簡易メールを音声として音声合成し、又は、前記音声入力手段により入力された音声を前記音声認識手段により認識して前記ＰＤＣ制御手段により簡易メールを作成し、前記スイッチを介して、前記音声認識手段と前記音声処理手段とが接続される場合に、前記所定の音声処理が実行され、前記スイッチを介して、前記音声認識手段と前記ＰＤＣ―Ｐ制御手段とが接続される場合に、前記ＨＴＭＬテキストの音声出力動作が実行され、又は、前記音声認識手段は、前記音声入力手段が取込んだ前記音声から前記ブラウザに対する制御指示を認識し、該制御指示を前記ブラウザに伝達し、前記ブラウザが前記音声認識手段から伝達された前記制御指示を解析し、適切な次のアクションを行うブラウザ搭載装置としたことを特徴とする。
【００４６】
請求項２記載の発明は、発声される可能性のある語彙を記憶する認識語彙記憶手段をさらに有し、前記音声認識手段は、認識語彙の辞書として前記認識語彙記憶手段を使用して前記ＨＴＭＬテキストを解析し、前記解析結果を基に、前記音声認識手段が行う音声認識の認識率を向上させ得る語彙を抽出し、前記ブラウザは、前記音声認識手段が抽出した語彙を前記認識語彙記憶手段に記憶させる請求項１記載のブラウザ搭載装置としたことを特徴とする。
【００４７】
請求項３記載の発明は、前記ＨＴＭＬテキスト中に語彙が直接含まれる場合に、前記ブラウザは、該語彙を抽出して前記認識語彙記憶手段に記憶させる請求項２記載のブラウザ搭載装置としたことを特徴とする。
【００４８】
請求項４に記載の発明は、前記音声出力手段により出力される音声において、話者の性別、音声のピッチ／スピード、及び、読み上げピッチの加速具合いについての設定及び設定変更を可能とした出力音声設定手段を更に具備した請求項１から３のいずれか１項に記載のブラウザ搭載装置としたことを特徴とする。
【００４９】
請求項５に記載の発明は、絵文字等の外字の読み上げ方法についての設定及び設定変更を可能とした外字読み上げ方法設定手段を更に具備した請求項１から４のいずれか１項に記載のブラウザ搭載装置としたことを特徴とする。
【００５０】
【発明の実施の形態】
次に、添付図面を参照して本発明によるブラウザ搭載装置の実施の形態を詳細に説明する。図１から図１０を参照すると、本発明のブラウザ搭載装置の一実施形態が示されている。
【００５１】
図１は、本発明の第１の実施形態を示すブロック図である。図１を参照すると、本発明の第１の実施形態は、従来技術を表す図１１に対して、ＨＴＭＬテキストを解析し、解析結果からＨＴＭＬテキストの読み上げ方法を最適化し、音声合成手段に対し、ＨＴＭＬテキストの読み上げ音声の合成を指示する音声ブラウザ１と、音声ブラウザ１が最適化した読み上げ方法により、ＨＴＭＬテキストの読み上げ音声を合成する音声合成手段２と、音声合成手段２が合成した音声を出力する音声出力手段３とを追加している。
【００５２】
図２は、本発明の第２の実施形態を示すブロック図である。図２は、第１の実施形態を示す図１に対して、使用者が発した音声を取込む音声入力手段５と、音声入力手段５が取込んだ音声から、音声ブラウザ１に対する制御指示を認識し、制御指示を音声ブラウザ１に伝達する音声認識手段４とを追加し、更に、音声認識手段４から伝達された制御指示を解析し、適切なアクションを行うように音声ブラウザ１を変更している。
【００５３】
図３は、本発明の第３の実施形態を示すブロック図である。図３は、第２の実施形態を示す図２に対して、発声される可能性のある語彙を記憶する認識語彙記憶手段６を追加し、更に、音声認識時、認識語彙の辞書として、認識語彙記憶手段６を使用するように音声認識手段４を変更し、加えて、ＨＴＭＬテキストを解析し、解析結果から、音声認識手段４が行う音声認識の認識率の向上させ得る語彙を抽出し、該抽出した語彙を認識語彙記憶手段６に記憶させるように音声ブラウザ１を変更している。
【００５４】
図４は、本発明の第４の実施形態を示すブロック図である。図４は、第３の実施形態を示す図３に対して、ＨＴＭＬテキスト中に語彙が直接含まれる場合に、該語彙を抽出し、認識語彙記憶手段６に記憶させるように音声ブラウザ１を変更している。
【００５５】
（動作例）
図１に示す本発明の一実施例を表すブロック図、及び、図５に示す音声ブラウザ１の動作例を示すフローチャートを用いて、本発明の第１の実施形態における動作内容を説明する。
【００５６】
ブラウザ搭載装置５０は、ブラウザ５１の指示で、通信手段５２を介して、ネットワーク５８に接続し、インターネット上のＷｅｂサーバにアクセスし、ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３に格納する。音声ブラウザ１は、これを読取り、一次解析し（図５のステップＳ１）、ＨＴＭＬテキストに文法誤り等がなければ（ステップＳ２）、ＨＴＭＬテキスト上の表示開始位置（通常は、ＨＴＭＬテキストの先頭位置。尚、ＨＴＭＬテキスト内で、＜Ａ ＮＡＭＥ＝…＞タグにより、ラベル名が定義されており、且つ、そのラベル名にリンクするようにブラウザ５１が指示されていた場合には、そのラベル位置。）から、順次ＨＴＭＬテキストを二次解析し、読み上げ文書を構築し、最適化する（ステップＳ３）。具体的には、通常のテキスト部分とＨＴＭＬタグ部分を分解し、ＨＴＭＬタグ部分は、更に、その属性と属性の値とを読取り、個々のＨＴＭＬタグの、全文における位置付けをも把握しながら、目の不自由な方々に理解されやすい、文章表現と読み上げ方法とをデザインする。その要領は、例えばｉモード携帯電話で使用されるコンパクトＨＴＭＬを用いれば、以下のとおりである。
【００５７】
（機能１）
読み上げ方は、基本的には、ハイパーテキストとして表示されたＨＴＭＬテキストを、通常の人が自然に読むのと同じ要領で読み上げる。例えば、ＦＲＡＭＥタグにより、画面が左右に分割されている場合には、左側のＦＲＡＭＥの内部を先に全て読み上げる（これは、通常のブラウザ５１が画面表示をデザインする際に用いる方法）のではなく、表示面積の大きい側の画面から順に、ブロック（段落等）毎に交互に、読み上げるものとする。具体的には、左右のＦＲＡＭＥの内部で、読み上げるブロックを各々まとめ、仮に右側の画面がより表示面積が大きいと仮定すれば、右側から読み始めるものとし、右１ブロック→左１ブロック→１ブロック分下に降りて、右１ブロック→左１ブロック→１ブロック分下に降りて、右１ブロック→…という要領で読み上げる。尚、上記読み上げ方法は、本願出願者にとっては自然な流れだが、本ブラウザ搭載装置の実際の使用者にとっては、不自然な読み上げ方かも知れない。この為、本読み上げの方法は、設定で変えられることが望ましい。
【００５８】
（機能２）
通常テキストは、男性が低い声で読み上げる。リンクのある部分は、女性の声で読み上げる。一度訪問した実績のあるリンクの部分は、女性が高めの声で早口に読み上げる。accesskey 等の操作方法の指示部は、男性が普通の声で読み上げる。例えば、ＨＴＭＬテキストが、
「メニューリスト
<A accesskey="1" HREF="http://…">１．ニュース／情報</A>
<A accesskey="2" HREF="http://…">２．モバイルバンキング</A>
<A accesskey="3" HREF="http://…">３．カード／証券／保険</A>」
の場合、読み上げ方は以下のとおり、男性が低い声で、「メニューリスト」と読み上げた後、女性の声で「１ ニュース情報」と読み上げ、その直後に、男性が普通の声で「１キーで アクセスします」と操作方法を解説する。話者の性別や、音声のピッチ／スピードは、設定で変えられることが望ましい。
【００５９】
（機能３）
操作方法の解説が連続する場合には、解説文の読み上げ方を省略する。例えば、（機能２）の例では、以下、女性の声で「２ モバイルバンキング」、男性が普通の声で「２です」、女性の声で「３ カード 証券 保険」、男性の普通の声で「３です」と読み上げる。なお、具体的な省略の仕方や、解説が連続状態に入った場合の読み上げピッチの加速具合い等については、設定で変えられることが望ましい。
【００６０】
（機能４）
表示の位置に関するＨＴＭＬタグ及び属性は、（機能１）のブロック位置の算出を除き、読み上げの際には無視する。例えば、タグ<CENTER>、属性 align、等は無視する。
【００６１】
（機能５）
絵文字は外字につき、その「意味」を読み上げる。例えば、ハートマーク（絵文字コード：＆＃６３７２６。本コードは、メーカに依存する）の場合は、「ハート」と読み上げる。なお、その読み上げ方は、設定で変えられることが望ましい。
【００６２】
（機能６）
画像（ｉモード携帯電話の場合、ＧＩＦのみ）は、無視する。但し、ＨＴＭＬテキスト中で、
「<IMG SRC="http:// …" ALT=" 彼氏">」
のように、ＡＬＴ属性で代替文字の指定があった場合には、男性の普通の声で「彼氏の絵」等の解説を加える。（機能１）の作用により、本解説文を読み上げる場所は、文脈に沿った、適切な場所で、読み上げる。なお、解説の有無及び解説の内容は、設定で変えられることが望ましい。
【００６３】
（機能７）
文字等に対する装飾は、無視する。例えば、タグ<PRE> 、<H1>〜<H6>、属性 bgcolor、等である。
【００６４】
（機能８）
リスト（タグ：UL,OL,LI,DL,DT,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 value="検索">
<INPUT accesskey="1" type=reset value=" クリア">
並べ方（複数指定時）：<INPUT accesskey="2" type=radio name=srt value="1" checked> 型番昇順
<INPUT accesskey="3" type=radio name=srt value="2"> 発売日降順
</FORM> 」
【００６７】
全文読み上げ時は、上記の部分は以下のとおり、読み上げる。
「（男性の声) …。全製品の検索画面。
（女性の声) ここから先は、後でまとめて入力して下さい。
（男性の声) 検索型番 N502it Hyper。
（女性の声) 後で変更できます。
（男性の声) 並べ方。複数指定時。型番昇順。発売日降順。お奨めは、型番昇順。
（女性の声) 後で変更できます。
（INPUT タグの type=submit,reset部に関しては、この段階では読み上げない。）
（次いで、フォーム部の終了を示すチャイムの鳴動音等）。
（男性の声) …。（残りのテキストを読み上げる）。」
【００６８】
次いで、全文読み上げ完了時、以下のとおり、読み上げる。
「（女性の声) では、先程お話ししたまとめ入力をこれから行いましょう。
（男性の声) 検索型番 N502it Hyper。
（女性の声) 変更する場合は今入力して下さい。変更しない場合は、０キーを押して下さい。
（入力の完了を待つ。暫くして、何の入力もなければ、再度音声で入力を促す。尚、「変更しない場合の０キー」とは、INPUT タグの type=submit部にある属性accesskey の値を使用することが初期設定されていることを仮定）。
【００６９】
（男性の声) 並べ方。複数指定時。
（女性の声) 次の２つの中からいずれかを選択して下さい。
（男性の声) 型番昇順。
（女性の声) ２キーで選択します。
（男性の声) 販売日降順。お奨めは、型番昇順。
（女性の声) ３キーです。いずれかを今選択して下さい。０キーでお奨めを選択することもできます。
（入力の完了を待つ。暫くして、何の入力もなければ、再度音声で入力を促す。尚、「０キーでお奨めを選択する」とは、INPUT タグのtype=submit 部にある属性accesskey の値を使用することが初期設定されていることを仮定）。
【００７０】
（女性の声) 最後に、まとめ入力の内容を確認します。
（男性の声) 検索型番（上記で入力された型番の読み上げ）。並べ方。複数指定時（上記で選択された並べ方を読み上げ）。
（女性の声) 「検索」を行う場合は、０キーを押して下さい。「クリア」を行う場合は、１キーを押して下さい。
（入力の完了を待つ。暫くして、何の入力もなければ、再度音声で入力を促す）
【００７１】
（機能１０）
入力手段５７からの適切な指示（ボタン押下等）により、通常テキスト部分の読み上げを行わず、リンクの部分だけを読返す機能を、音声ブラウザ１に付与することが望ましい。本機能の追加により、最初に全文を聞き終えた後、本機能を起動して、リンクの部分だけを必要なだけ読返すことが可能となり、リンク先の指定（ボタン押下等）を、さほど混乱することなく正確に行うことができる。
【００７２】
（機能１１）
警告メッセージの発生時は、読み上げ処理を一旦中断し、警告メッセージの読み上げを行い、必要があれば文字入力や選択等を会話形式で行い、最後にボタン押下やアイコン・クリックを行わせるように音声案内を行う。なお、本ボタンの押下後は、必要に応じて中断していた読み上げ処理を再開する。
【００７３】
音声ブラウザ１は、ステップＳ３で最適化された読み上げ文章を、ステップＳ４で音声合成手段２に転送し、音声出力手段３を通して音声出力させる。
【００７４】
また、ステップＳ２でＨＴＭＬテキストに文法誤り等があれば、読み上げのできない旨を音声合成手段２に伝えて、音声出力手段３を通して、その旨を音声出力させる（ステップＳ５）。
【００７５】
読みたいページのアドレスを指定するためのＵＲＬ入力や、ハイパーテキスト中に含まれるリンクやアイコンのクリック等は、従来同様、入力手段５７を介して行う。
【００７６】
次に、図２に示す本発明の一実施例を表すブロック図、及び、図６に示す音声ブラウザ１の動作例を示すフローチャートを用いて、本発明の第２の実施形態における動作内容を説明する。
【００７７】
ブラウザ搭載装置５０は、ブラウザ５１の指示で、通信手段５２を介して、ネットワーク５８に接続し、インターネット上のＷｅｂサーバにアクセスし、ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３に格納する。音声ブラウザ１は、これを読取り、第１の実施形態に示すとおり、最適化された読み上げ文章を構築後、音声合成手段２に転送し、音声出力手段３を通して、音声出力させる。
【００７８】
他方、使用者が発した音声は、音声入力手段５に取込まれる。取込まれた音声は、音声認識手段４により音声認識される。本音声認識は、単に話者音声をテキスト形式に変換するのみならず、音声ブラウザ１に対する制御指示の候補として認められるか否かを含めて認識される。認識結果が、音声ブラウザ１に対する制御指示の候補として認められる場合には、音声認識手段４は音声ブラウザ１に対して割込みを行い、併せて、認識された制御指示の候補を音声ブラウザ１に伝達する。音声ブラウザ１は、本割込みを受けて、その状態を遷移させ、図６に記すフローチャートに従い、割込みの処理を開始する。以下に、そのフローチャートを図６を用いて説明する。
【００７９】
音声ブラウザ１は、音声認識手段４から伝達された音声認識結果が、音声ブラウザ１に対する制御指示として有効か否かを確認する（ステップＳ６）。
【００８０】
有効と認められた場合は、本割込みが、音声合成手段２による読み上げ処理の最中に発生した割込みであるか否かを調べる（ステップＳ７）。
【００８１】
本割込みが、音声合成手段２による読み上げ処理の最中に発生した割込みである場合には、音声認識手段４から伝達された制御指示が、音声合成手段２による読み上げ処理をわざわざ中断し、直ちに実行する必要性があるか否かを調べる（ステップＳ８）。
【００８２】
音声認識手段４から伝達された制御指示を慌てて実行する必要性がない場合には、音声合成手段２による読み上げ処理が終了した時点で、受取った制御指示（その時点では、制御指示は複数に増えている可能性もある）を（順番に）解析し、次のアクションとして（一つずつ順番に）実行して行けば良いので、受取った制御指示を一時的に保留（ステップＳ１２）し、本割込みから復帰する。
【００８３】
ステップＳ８での判定の結果、音声認識手段４から伝達された制御指示を直ちに実行する必要性がある場合には、音声合成手段２に読み上げ処理の中止を指示し（ステップＳ９）、読み上げ処理を中止させた緊急性の高い制御指示に限定してその内容を解析し、次のアクションとして実行しても矛盾が生じなければ、そのアクションを実行する（ステップＳ１０）。このことは、既に制御指示が複数蓄積された状態にある場合は、緊急性の高い制御指示を古いものから順に探索して行くことを意味しているが、探索して検出される迄の間に存在した、緊急性が低くて読飛ばされた制御指示については、もはや不要な制御指示と見なして、これらは廃棄し（ステップＳ１１）その上で、本割込みから復帰する。
【００８４】
ステップＳ７の判定の結果、本割込みが、音声合成手段２による読み上げ処理の最中に発生した割込みではない場合には、ステップＳ１２で一時的に保留とした制御指示も含めて、受取った制御指示の内容を古いものから順に解析し、次のアクションとして実行しても矛盾しない内容であれば、そのアクションを実行する（ステップＳ１３）。全ての制御指示の解析を終えた段階で、本割込みから復帰する。
【００８５】
ステップＳ６の結果、音声認識手段４から伝達された内容が制御指示として無効な場合には何もせず、そのまま本割込みから復帰する。音声合成手段２が読み上げを完了した時点で、音声ブラウザ１は、音声認識手段４から受け取った制御指示で一時的に保留されている物が未だ残っていないかを確認する。未だ残っている場合には、ステップＳ１３同様に、受け取った制御指示の内容を古い物から順に解析し、次のアクションとして実行しても矛盾しない内容であれば、そのアクションを順次実行する。この結果、文字入力（例．読みたいページのアドレスを指定するためのＵＲＬ入力）や、クリック操作（例．ハイパーテキスト中に含まれるリンクや送信ボタン・アイコン等のクリック操作）を、入力手段５７からではなく、音声入力手段５を介して、音声で行うことが可能となる。
【００８６】
第１の実施形態の動作説明の中にある、（機能２）と（機能３）で使用したＨＴＭＬテキストを、具体例として用いれば、以下のとおりである。
【００８７】
音声ブラウザ１は、「１ ニュース 情報。」「１キーで アクセスします。」「２ モバイルバンキング。」「２です。」「３ カード 証券 保険。」「３です。」と読み上げ続ける。使用者は、途中で「２。」と発声する。使用者の発した音声は、音声入力手段５に取込まれ、音声認識手段４により、音声認識され、音声ブラウザ１へと割込む。音声ブラウザ１は、ＨＴＭＬテキスト中に、
「<A accesskey="2" HREF="http://…">２．モバイルバンキング</A>」
とあることから、「２」キーが押されたのと同等と解釈して、指定のリンク先にジャンプする。
【００８８】
また、第１の実施形態における（機能９）で使用したＨＴＭＬテキストを、具体例として用いれば、以下のとおりである。フォーム部分は、最初の全文読み上げ中には、「後で 入力（または、選択）して下さい」又は「後で 変更できます」等と、簡単に読み上げる。全文読み上げ終了時、フォーム部分に限定して、会話形式による読み上げと、テキスト入力待やボタン類の選択待ちが発生する。即ち、入力や選択が必要となる箇所では、その都度、音声案内が停止するので、使用者からの音声指示により、音声認識を用いてテキスト入力や選択を行わせることができる。最後に、Ｒｅｓｅｔ相当又はＳｕｂｍｉｔ相当ボタン（アイコン）の押下案内が流れるため、これもまた音声で指示する。
【００８９】
第２の実施形態の場合、音声入力指示が効果的に行われるようにするため、コンテンツ（ＨＴＭＬテキスト）の設計側でも、十分に注意を払う必要がある。
【００９０】
例えば、マウス等のポインティング・デバイスで、画面上のアイコンやイメージ等をクリックし、その位置等を指定する（これを「フォーカスする」と言う）使用方法は、汎用的なブラウザでは一般的なものであるが、これを音声入力指示で代用するとなると、位置指定が難しく、相当使い勝手の悪い、非実用的な代物となってしまう。従って、ＨＴＭＬテキストの設計側では、そのようなＨＴＭＬタグの使用（例．イメージ上のクリック位置で、そのアクションを異ならせるような、イメージマップ処理を実現するための「ＭＡＰ」タグの使用等）を慎むように、注意する必要がある。
【００９１】
ところが、近年になり、ポインティング・デバイスを装備しない携帯電話機からもインターネットに乗り入れることができるようになった。この目的のために、ＨＴＭＬを応用して開発された「コンパクトＨＴＭＬ」と、コンパクトＨＴＭＬの閲覧が可能な「マイクロブラウザ」の登場により、上記設計上の注意点が自然に緩和される結果となり、第２の実施形態は一層現実味を帯びた。
【００９２】
即ち、ポインティング・デバイスを装備していないｉモード携帯電話機に搭載されるマイクロブラウザには、汎用的なブラウザに存在する、「戻る」「次」「再読込み」又は「ホーム」等のボタンのアイコンが画面上になく、仮に存在しても、キー操作で代用できる。例えば、「戻る」「次」機能は、←、→等の矢印キーの押下で、代用できる。加えて、コンパクトＨＴＭＬでは、イメージマップ処理を行わせる「ＭＡＰ」タグをサポートしていないのみならず、「Ａ」タグや「ＩＮＰＵＴ」タグに、accesskey 属性を追加し、キー操作だけで位置指定が行えるように、「イージーフォーカス機能」が強化されている。なお、ｉモード携帯電話機による、第２の実施形態の具体的な実施例は、本発明の他の実施形態の章で説明することにする。
【００９３】
第２の実施形態の場合、音声認識手段４による音声認識率を向上させる必要がある。この後に述べる、第３の実施形態は、音声認識率の向上を目的としたものである。最近の音声認識装置のブロック図を図１５に示す。
【００９４】
不特定話者認識、大語彙認識、連続音声認識を実現する音声認識方法の一つとして、半音節単位を用いた音声認識が効果的である。半音節単位とは、音節をその母音中心で分割した結果得られるＣＶ（子音(consonant) ＋母音(vowel) ）区間とＶＣ（母音＋子音）区間とを音の基本単位として使用するものである。各半音節は、ＨＭＭ(Hidden Markov Model）と呼ばれるモデルで表現され、ＨＭＭは、音の時間軸上及び周波数軸上の揺らぎを統計的に表現できるモデルである。今、各読みの半音節モデルと、認識対象となる単語（かな文字で表記されている）とが予め装置に登録されている状態において、登録済の認識対象となる単語の各々の読みに対応して、半音節モデルを連結した単語モデルを作り、これを入力音声と個々に比較しながら、最もよく照合するもの（即ち、似ているもの）を選び出すこと（算術的には、対数尤度を比較し、値が最大となるものを選ぶ）によって、最善の認識結果を得る。更に、単語の並び方を表す文法モデルを与えることで、文法により許される範囲内での連続音声認識が可能となる。
【００９５】
このため、認識率の向上には、各読みの半音節モデルの充実、認識対象となる単語の充実、及び、単語の並び方を表す文法の充実とが、重要である。この後に述べる、第３の実施形態は、特に認識対象となる単語、即ち、語彙の充実方法について、述べるものである。
【００９６】
図１５に記す、最近の音声認識装置は、半音節モデルとして、不特定話者半音節モデル記憶部８４と話者適応後半音節モデル記憶部８５を併せ持つ。不特定話者半音節モデル記憶部８４には、予め多数の人の声（学習データ）を用いて作成された不特定話者の半音節モデルが登録されている。これにより、特定話者の少量の音声を用いて、不特定話者モデルをその話者に適応（話者適応）させ、認識性能をより向上させるように努めている。
【００９７】
音声入力手段５を介して入力された音声は、分析、雑音除去部８０で分析され、２段スペクトル・サブストラクション法等を用いて、周囲雑音の影響を除去された後、認識処理部８１及び話者適応制御部８６へと送付される。
【００９８】
認識処理部８１は、不特定話者半音節モデル記憶部８４及び話者適応後半音節モデル記憶部８５に記録される各々の半音節モデル、語彙辞書部８２に登録される語彙（認識対象となる単語を意味し、かな文字で表記されている）、及び、文法モデル部８３に登録される文法とを用いて、音声認識を行う。
【００９９】
話者適応制御部８６は、話者適応のための学習機能を司ると共に、現在入力されている音声を解析し、半音節モデル学習時からの環境差を推定し、使用される半音節モデルを、現在入力されている音声に速やかに適合させるように制御する（高速環境適応法）。
【０１００】
次に、図３に示す本発明の一実施例を表すブロック図、及び、図７に示す音声ブラウザ１の動作例を示すフローチャートを用いて、第３の実施形態の動作内容を説明する。
【０１０１】
ブラウザ搭載装置５０は、ブラウザ５１の指示で、通信手段５２を介して、ネットワーク５８に接続し、インターネット上のＷｅｂサーバにアクセスし、ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３に格納する。音声ブラウザ１は、これを読取り、第１の実施形態に記すとおり最適化された読み上げ文章を構築した後（図７のステップＳ３）、ＨＴＭＬテキストの解析結果から、音声認識手段４で行われる音声認識の認識率を向上させる語彙を抽出し、抽出された語彙を認識語彙記憶手段６に登録する（ステップＳ１４）。その上で、音声ブラウザ１は、最適化された読み上げ文章を、音声合成手段２に転送し、音声出力手段３を通して、音声出力する（ステップＳ４）。使用者が発した音声指示は、第２の実施形態に示すとおり、音声入力手段５に取り込まれ、認識語彙の辞書として、認識語彙記憶手段６に登録された語彙を使用する音声認識手段４によって音声認識された後、音声ブラウザ１により、次のアクションが実行される。
【０１０２】
ＨＴＭＬテキストの解析結果から、音声認識率を向上させる語彙を抽出し、認識語彙記憶手段６に登録するステップＳ１４において、目的の語彙の抽出要領は、例えば、ｉモード携帯電話で使用されるコンパクトＨＴＭＬの場合には、以下のとおりである。
【０１０３】
（機能１２）
＜Ａ＞＜／Ａ＞タグに含まれるテキスト。例えば、
「<A HREF="http://…">ニュース／情報</A>」
の場合には、「にゅうす」、「じょおほお」を登録する。
【０１０４】
（機能１３）
属性アクセスキー（ａｃｃｅｓｓｋｅｙ）があれば、その値。例えば、
「<A accesskey="1" HREF="http://…">ニュース／情報</A>」の場合は、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"> 連絡日降順 」の場合は、「かたばん」「しょおじゅん」「れんらくび」「こおじゅん」を登録する。
【０１０７】
さて、音声認識手段４は、認識語彙記憶手段６から語彙を抽出し、音声認識処理を行うが、本処理を高速化するため、音声認識率の高い語彙から順に抽出する必要がある。第３の実施形態では、文脈に沿った形で、語彙の登録が行われることになるため、語彙の登録時期が古くなればなる程、音声認識処理時にヒットする可能性が低くなる。従って、最新の登録語彙から順に抽出することが望ましい。
【０１０８】
また、認識語彙記憶手段６には物理的な容量制限が存在するため、いつかは登録語彙が満タン状態となり、追加登録不能となる。この対策として、語彙記憶手段６内の記憶領域を、固定的に保持し続ける分とそうでない分とに分ける方法、保持内容が変動する分のみを認識語彙記憶手段６内に登録し、固定的に保持し続ける分は、音声認識手段４内の語彙辞書部８２（図１５参照）等の別の場所を利用する方法がある（後者の場合、例えば、工場出荷時に、装置に予め登録された分のみが、固定的に保持されることになる）。尚、保持内容が変動する部分の記憶方式としては、登録語彙が古くなる程、音声認識処理時にヒットする可能性が低くなることから、最も古い登録情報から順番に最新情報が上書きされる、リングバッファ記憶形式を用いることが望ましい。
【０１０９】
第３の実施形態の場合、音声ブラウザ１が、ＨＴＭＬテキストの解析結果から、音声認識率を向上させる語彙を抽出しているが、語彙の抽出には時間が掛かる上に、漢字、外国語及び特殊文字の読み方を仮名文字に変換するための、変換規則を記した巨大な辞書を保持する必要があるという課題があった。次に述べる、第４の実施形態は、語彙の抽出を簡略化する目的で、語彙自身をＨＴＭＬテキスト内に埋め込むことを提案するものである。
【０１１０】
次に、図４に示す本発明の一実施例を表すブロック図、及び、図８に示す音声ブラウザ１の動作例を示すフローチャートを用いて、第４の実施形態の動作内容を説明する。
【０１１１】
ブラウザ搭載装置５０は、ブラウザ５１の指示で、通信手段５２を介して、ネットワーク５８に接続し、インターネット上のＷｅｂサーバにアクセスし、ダウンロードしたＨＴＭＬテキストを一旦記憶手段５３に格納する。音声ブラウザ１は、これを読取り、第１の実施形態に記すとおり最適化された読み上げ文章を構築する（図８のステップＳ３）。その後、ＨＴＭＬテキストを解析し、語彙抽出を行うが、その方法は以下のとおり。ＨＴＭＬテキストを検索し、個々のＨＴＭＬタグに対して、「語彙を指定する属性」を含むか否かを調べる（ステップＳ１５）。ＨＴＭＬタグが、語彙を指定する属性を含む場合、属性の値、即ち、語彙を読取り、読取られた語彙を認識語彙記憶手段６に登録する（ステップＳ１６）。
【０１１２】
他方、ＨＴＭＬタグが、語彙を指定する属性を含まない場合、第３の実施形態で示したとおり、音声認識手段４で行われる音声認識の認識率を向上させる語彙を抽出し、抽出された語彙を認識語彙記憶手段６に登録する（ステップＳ１４）。その上で、音声ブラウザ１は、最適化された読み上げ文章を、音声合成手段２に転送し、音声出力手段３を通して、音声出力する（ステップＳ４）。使用者が発した音声指示は、第２の実施形態に記すとおり、音声入力手段５に取込まれ、認識語彙の辞書として、認識語彙記憶手段６に登録された語彙を使用する音声認識手段４によって音声認識された後、音声ブラウザ１により、次のアクションが実行される。
【０１１３】
ステップＳ１５に記した、語彙を指定する属性を含むか否かを調べるくだりに関して、例えば、語彙を指定する属性をＶＯＣＡＢＵＬＡＲＹと仮定すれば、ＨＴＭＬテキストは以下のとおりとなる。
【０１１４】
（機能１５）
「<INPUT type="Submit" value="記録" vocabulary="きろく">
<INPUT type="Reset" value="クリア"> 」
【０１１５】
この場合、type="Submit" で指定されるＩＮＰＵＴタグ側では、ステップＳ１６が実行され、属性ＶＯＣＡＢＵＬＡＲＹの値”きろく”が、認識語彙記憶手段６に登録される。他方、type="Reset"で指定されるＩＮＰＵＴタグ側では、ステップＳ１４が実行され、属性ＶＡＬＵＥの値”クリア”から抽出される語彙”くりあ”が、認識語彙記憶手段６に登録される。
【０１１６】
第４の実施形態に関して、認識に必要な語彙文法情報を、電話回線ネットワークを介して、情報サービスシステム側からユーザ端末側に送り込むという発明の基本部分は、先に特許第２６５５０８６号にて開示されている。従って、第４の実施形態は、特許第２６５５０８６号を具体的な装置の形態に展開した発明であるといえる。尚、特許第２６５５０８６号を応用し、別の装置の形態に展開した先願例であり、しかも第４の実施形態に最も構造が似ている発明としては、図１６に示す特開２０００−１０５６８１号がある。しかし、本発明から、第４の実施形態を容易に類推することは、以下の理由により困難である。
【０１１７】
（理由１）図１６の発明は、装置を車載用情報端末に限定していること。
（理由２）情報端末３０から情報センタ３２に送信される情報は、ＵＲＬではなく、「情報コード」（例えば、コンビニエンスストアの場合、ＦＦ００７Ａ８Ｅ等の特殊なコード）であること。即ち、複数の情報センタ３２にアクセスできるように考慮されていない点が、インターネット通信技術を応用したブラウザ搭載装置を対象とした本発明からかけ離れていること。
【０１１８】
（理由３）上記情報コードを受けて、情報センタ３２から情報端末３０に返信される情報は、ＨＴＭＬではなく、その情報コードに対応したデータ（例えば、コンビニエンスストアに関する一連の情報）であるが、それを音声で読み上げることは触れていないこと。特に、目の不自由な方々の便宜を考慮した読み上げ方の記述は、見出せないこと。
【０１１９】
（理由４）情報センタ３２から情報端末３０に送信される語彙情報は、単に最新版であるだけに過ぎないこと。即ち、情報コードに対応するデータに合わせて、音声認識率を最も向上させ得る語彙を、その都度送信するという発想が存在しないこと。
【０１２０】
最後に、既存のブラウザ５１に音声ブラウザ１の機能を持たせ、ただ一つのブラウザのみを搭載した装置とすることは、同業他社には容易類推可能な範囲である。
【０１２１】
また、音声認識手段４による音声認識率が１００％にならない場合等に、認識結果（テキスト形式）を、音声合成手段２にも転送し、音声出力手段３を通して、音声出力させることで、話者に認識結果を確認させることも、容易類推可能な範囲である。この場合、仮に音声合成手段２が、最適化された読み上げ文章を読み上げ中であったとした場合には、（１）読み上げを中止し、認識結果を音声出力させることも、（２）全ての読み上げ処理が完了してから、認識結果を音声出力させることも、（３）読み上げを一時的に中断し、認識結果の音声出力後、中断した読み上げを再開させることも可能であり、いずれも容易類推可能な範囲である。
【０１２２】
（他の実施例）
図９は、ｉモード携帯電話機による第２の実施形態を示すブロック図である。図９を参照すると、本第２の実施形態は、従来技術を表す図１４に対して、ＬＳＩ６５に内蔵される、ＰＤＣ制御部７１、音声処理部７２及びＰＤＣ−Ｐ制御部７３と、音声認識／合成ＬＳＩ６４との間の接続を切換えるスイッチ７が追加されており、加えて、ＰＤＣ−Ｐ制御部７３が、ＲＯＭ６９及びＲＡＭ７０と連携し、音声ブラウザ１の機能をより効果的に果たすようにと変更されている。
【０１２３】
スイッチ７は、通常は、音声認識／合成ＬＳＩ６４と音声処理部７２が接続されるように切り換えられている。この結果、従来技術を表す図１４と回路が等価になり、従来のｉモード携帯電話機として使用することができる。
【０１２４】
第１の実施形態及び第２の実施形態で使用する場合には、音声認識／合成ＬＳＩ６４と、音声ブラウザ１の機能を果たすＰＤＣ−Ｐ制御部７３が接続されるように、スイッチ７を切り換える（図９は、その時の状態を示した図である）。
【０１２５】
無線部６６を介して受信されたＨＴＭＬテキストは一旦ＲＡＭ７０に蓄積される。ＰＤＣ−Ｐ制御部７３の音声ブラウザ機能を用いて解析されたＨＴＭＬテキストは、ハイパーテキストとして表示部６８に表示されると共に、最適化された読み上げ音声テキストに変換され、音声認識／合成ＬＳＩ６４に送付される。音声認識／合成ＬＳＩ６４はＡＤＰＣＭ複号機能を用いて、これを複号化し、Ａ／Ｄコンバータ６２に送付する。Ａ／Ｄコンバータ６２は、これをＤ／Ａ変換し、レシーバ６０を通して、読み上げ音声として出力する。一方、使用者からの音声指示は、マイク６１を通して入力され、Ａ／Ｄコンバータ６２でＡ／Ｄ変換（符号化）された後、音声認識／合成ＬＳＩ６４により、音声認識結果としてテキスト化され、ＰＤＣ−Ｐ制御部７３に渡される。ＰＤＣ−Ｐ制御部７３は、音声ブラウザ機能を用いて、これを解析し、音声指示と認められれた場合、その指示を実行する。
【０１２６】
尚、本発明の別の応用例として、図９のスイッチ７を切換えて、音声認識／合成ＬＳＩ６４とＰＤＣ制御部７１が接続されるようにした場合を想定することができる。この場合、ＰＤＣ制御部７１単体で、音声認識によりテキスト化された音声情報を、相手局にテキスト形式で送信し、逆に受信されたテキスト形式の情報を音声に再現して、音声出力するという通信方式が可能になる。これは、もはやブラウザ装置の枠組みから外れてしまうが、一つの発明として、その具体的な動作内容を、以下に記す。
【０１２７】
簡易メール（ＮＴＴ呼称：ショートメール）が、電話により、文字をやり取りする通信方式であることは、従来技術の中で述べたとおりである。一方、目の不自由な方々にとって、簡易メールは、送信時、メール文章のデータ入力が必要であるが、送信したい文字の選択が、ボタンの押下順序や回数を組み合せて行う方式であるため、複雑なボタン操作がどうしても必要であり、苦痛な代物であった。加えて、受信したデータは、受信テキストが画面に表示されるだけであり、目の不自由な方々には読むことができなかった。
【０１２８】
図９の発明に拠れば、使用者からの音声情報は、マイク６１を通して入力され、Ａ／Ｄコンバータ６２でＡ／Ｄ変換（符号化）された後、音声認識／合成ＬＳＩ６４により、音声認識されて、テキスト化される。該テキスト化された音声情報を、スイッチ７を介して、ＰＤＣ制御部７１に取込み、ＲＡＭ７０に格納する。ＰＤＣ制御部７１は、ショートメール符号化機能を用いて、これを、複数のプッシュボタンの、各々の押下回数の組み合わせ、即ち、プッシュボタン音の組み合せへと変換し、無線部６６を介して、簡易メールとして、メールセンタ（ＮＴＴの場合、ショートメールセンタ）宛に発信する。
【０１２９】
他方、相手局は、メールセンタからの着信通知を受けて、ＲＡＭ７０上にダウンロードした簡易メールを、ＰＤＣ制御部７１が有するショートメール複合化機能を用いて、テキストに逆変換し、更に、スイッチ７を介して、音声認識／合成ＬＳＩ６４へ送付し、ここで複号化した後、Ａ／Ｄコンバータ６２でＤ／Ａ変換し、レシーバ６０で読み上げ音声として出力する。
【０１３０】
この結果、受信した簡易メールは装置自身が読み上げ、また送信時には、音声で入力すると、装置自身が自動的に簡易メールに変換して、メールセンタ宛に発信するため、複雑なボタン操作に煩わされる必要もなくなり、目の不自由な方々は勿論のこと、目に不自由しない方々でさえも、その恩恵を享受できる。加えて、目の不自由な方々も、簡易メール（ショートメール）によるコミュニケーションの輪に参加する事が出来る様になり、逆に、目に不自由しない、従来からの簡易メール（ショートメール）利用者にとっては、相手の目が不自由か否かを意識する必要はない為、通常の電話同様、両者にとって、バリアフリーなコミュニケーション関係を構築・維持出来るものと期待される。尚、本効果は、ｅ−Ｍａｉｌ（呼称：ｉモードメール）の場合でも、同様に得られる。
【０１３１】
図１０は、ｉモード携帯電話機による第４の実施形態の一実施例を示すブロック図である。図１０を参照すると、本第４の実施形態は、第２の実施形態を表す図９に対して、発声される可能性のある語彙を記憶する認識語彙記憶部８を追加し、加えて、音声認識／合成ＬＳＩ６４を、音声認識時、認識語彙の辞書として、認識語彙記憶部８を使用するものへと変更し、更に、ＰＤＣ−Ｐ制御部７３を、解析したＨＴＭＬテキスト中に語彙が直接含まれる場合には、その語彙を抽出し、語彙が直接含まれない場合には、音声認識／合成ＬＳＩ６４で行われる音声認識の認識率の向上させ得る語彙を抽出し、抽出した語彙を認識語彙記憶部８に記憶させるようなものへと変更している。
【０１３２】
第４の実施形態で使用する場合には、音声認識／合成ＬＳＩ６４と、音声ブラウザ１の機能を果たすＰＤＣ−Ｐ制御部７３が接続されるように、スイッチ７を切り換える（図１０は、その時の状態を示した図である。）。
【０１３３】
無線部６６を介して受信されたＨＴＭＬテキストは、一旦ＲＡＭ７０に蓄積される。ＰＤＣ−Ｐ制御部７３の音声ブラウザ機能を用いて解析されたＨＴＭＬテキストは、ハイパーテキストとして表示部６８に表示されると共に、語彙が抽出されて認識語彙記憶部８に記憶され、その上で最適化された読み上げ音声テキストへと変換を行い、音声認識／合成ＬＳＩ６４へと送付する。音声認識／合成ＬＳＩ６４は、ＡＤＰＣＭ複号機能を用いてこれを複号化し、Ａ／Ｄコンバータ６２に送付する。Ａ／Ｄコンバータ６２は、これをＤ／Ａ変換し、レシーバ６０を通して読み上げ音声として出力する。一方、使用者からの音声指示は、マイク６１を通して入力され、Ａ／Ｄコンバータ６２でＡ／Ｄ変換（符号化）された後、音声認識／合成ＬＳＩ６４により、音声認識結果としてテキスト化され、ＰＤＣ−Ｐ制御部７３に渡される。音声認識／合成ＬＳＩ６４は、音声認識時、認識語彙の辞書として、認識語彙記憶部８に登録された語彙を使用する。ＰＤＣ−Ｐ制御部７３は、音声ブラウザ機能を用いてこれを解析し、音声指示と認められた場合、その指示を実行する。
【０１３４】
尚、上述の実施形態は本発明の好適な実施の一例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施が可能である。
【０１３５】
【発明の効果】
以上の説明より明らかなように、請求項１記載の発明のブラウザ搭載装置は、ＨＴＭＬテキストを解析し、解析結果からＨＴＭＬテキストの読み上げ方法を最適化し、ＨＴＭＬテキストの読み上げ音声の合成を指示するブラウザと、このブラウザが最適化した読み上げ方法により、ＨＴＭＬテキストの読み上げ音声を合成し、合成した音声を出力する。
【０１３６】
第１の効果は、ブラウザ搭載装置の小型・軽量化を廉価に実現できる点にある。その理由は、ＰＤＣ制御部、ＰＤＣ−Ｐ制御部及び音声処理部が使用する、音声合成及び音声認識処理回路を効率化する事で、部品点数を削減できるためである。第２の効果は、目の不自由な方々をもインターネットの世界へ誘うことができる点にある。その理由は、ブラウザがＨＴＭＬテキストを解析し、目の不自由な方々にとって理解しやすい文章をデザインし、読み上げてくれるからである。加えて、ブラウザは、使用者の発した音声を認識し、適切な音声指示である場合には、それを実行するため、目の不自由な方々にとって苦痛な、文字入力やクリック操作が、大幅に不要となるためである。
【０１３７】
第３の効果は、コンテンツ・プロバイダにとって、目の不自由な方々を対象としたコンテンツをデザインすることが、それほど負担にはならない点にある。その理由は、コンテンツ・プロバイダが目の不自由な方々向けに適切なコンテンツを提供することは、従来は不可能であったり、あるいは、コンテンツの作成に時間が掛かり、高価になるが、本発明によって、その制約は比較的容易に緩和されるためである。加えて、ｉモード携帯電話機向けに開発されたコンパクトＨＴＭＬでコンテンツをデザインすることができれば、コンパクトＨＴＭＬが有する諸機能との相乗効果により、その制約が一層軽減されるためである。
【図面の簡単な説明】
【図１】本発明のブラウザ搭載装置の実施形態を表すブロック構成図である。
【図２】第２の発明の一実施例を表すブラウザ搭載装置のブロック図である。
【図３】第３の発明の一実施例を表すブラウザ搭載装置のブロック図である。
【図４】第４の発明の一実施例を表すブラウザ搭載装置のブロック図である。
【図５】第１の実施形態のブラウザ搭載装置に搭載される音声ブラウザの動作例を示すフローチャートである。
【図６】第２の実施形態のブラウザ搭載装置に搭載される音声ブラウザの動作例を示すフローチャートである。
【図７】第３の実施形態のブラウザ搭載装置に搭載される音声ブラウザの動作例を示すフローチャートである。
【図８】第４の実施形態のブラウザ搭載装置に搭載される音声ヴラウザの動作例を示すフローチャートである。
【図９】第１および第２の実施形態の一実施例を表すｉモード携帯電話機のブロック図である。
【図１０】第３および第４の実施形態の一実施例を表すｉモード携帯電話機のブロック図である。
【図１１】従来のブラウザ搭載装置のブロック図である。
【図１２】従来のｉモードサービスのネットワーク構成図である。
【図１３】従来のｉモードサービスのプロトコルスタックである。
【図１４】従来のｉモード携帯電話機のブロック図である。
【図１５】従来の音声認識装置のブロック図である。
【図１６】従来例であり第４の実施形態に類似する先願発明例の音声情報処理装置のブロック図である。
【符号の説明】
１ 音声ブラウザ
２ 音声合成手段
３ 音声出力手段
４ 音声認識手段
５ 音声入力手段
６ 認識語彙記憶手段
７ スイッチ
８ 認識語彙記憶部
３０ 情報端末
３１ ネットワーク
３２ 情報センタ
３３ 音声入力手段
３４ 音声認識手段
３５ 音声認識用テーブル
３６ 音声合成手段
３７ 通信手段
３８ ＣＰＵ
３９ 表示手段
４０ 音声出力手段
４１ 通信手段
４２ ＣＰＵ
４３ 音声認識用テーブル
４４ 情報提供メニューテーブル＆ＤＢ
５０ ブラウザ搭載装置
５１ ブラウザ
５２ 通信手段
５３ 記憶手段
５４ 表示手段
５５ キーボード
５６ マウス
５７ 入力手段
５８ ネットワーク
６０ レシーバ
６１ マイク
６２ Ａ／Ｄコンバータ
６３ スイッチ
６４ 音声認識／合成ＬＳＩ
６５ ＬＳＩ
６６ 無線部
６７ 操作部
６８ 表示部
６９ ＲＯＭ
７０ ＲＡＭ
７１ ＰＤＣ制御部
７２ 音声処理部
７３ ＰＤＣ−Ｐ制御部
８０ 分析、雑音除去部
８１ 認識処理部
８２ 語彙辞書部
８３ 文法モデル部
８４ 不特定話者半音節モデル記憶部
８５ 話者適応後半音節モデル記憶部
８６ 話者適応制御部
１００ ｉモード携帯電話機
１０１ ｉモードサーバ
１０２ コンテンツ
１５０ インターネット
１５１ ＰＤＣ−Ｐネットワーク
１５２ ＰＤＣネットワーク
１５３ 専用線
１５４ パケット通信

Claims (5)

1. ｉモードサービスを提供するパケット通信網であるＰＤＣ−Ｐネットワークとの接続処理を制御するＰＤＣ−Ｐ制御手段によりＰＤＣ−Ｐネットワークに接続され、該ＰＤＣ−Ｐネットワークを介して接続されたインターネット等の通信ネットワークから受信したＨＴＭＬテキストを解析し、該解析結果を基に、前記ＨＴＭＬテキストを、音声として読み上げる方法を所定の基準により決定し、該決定された読み上げ方法により、前記受信したＨＴＭＬテキストを音声として合成する旨の指示を、音声合成手段に対して行うブラウザと、
   使用者が発した音声を取込む音声入力手段と、
   前記ブラウザの指示により、前記ＨＴＭＬテキストを音声として合成し、又は、前記音声入力手段により取り込まれた音声を認識する音声認識手段としても動作する音声合成手段と、
   前記音声合成手段により合成された音声を出力する音声出力手段と、
   前記ブラウザ、前記音声合成手段、及び、前記音声出力手段が実行する前記ＨＴＭＬテキストの音声出力動作の制御をする前記ＰＤＣ−Ｐ制御手段と、
   携帯電話の発信先の電話番号をボタン操作で入力する代わりに電話番号自体を音声により入力する場合、携帯電話に予め登録された発信先の電話番号を該電話番号と関連付けられた別名の音声により入力する場合、又は、携帯電話の使用中に所定のファンクション機能を動作させるために、該携帯電話に設置された各ファンクションキーを押下する代わりに、各ファンクション機能を音声により入力する場合に、それぞれ必要とされる所定の音声処理を行う音声処理手段と、
   携帯電話の待ち受け時、発信時、着信時、又は、通話時の、各モードにおける所定動作を制御するＰＤＣ制御手段と、
   前記ＰＤＣ−Ｐ制御手段、前記音声処理手段、及び、前記ＰＤＣ制御手段の各部と、前記音声合成手段との間を選択的に接続するスイッチと、を具備し、
   前記スイッチを介して、前記音声合成手段（兼前記音声認識手段）と前記ＰＤＣ制御手段とが接続される場合に、受信した簡易メールを音声として音声合成し、又は、前記音声入力手段により入力された音声を前記音声認識手段により認識して前記ＰＤＣ制御手段により簡易メールを作成し、
   前記スイッチを介して、前記音声認識手段と前記音声処理手段とが接続される場合に、前記所定の音声処理が実行され、
   前記スイッチを介して、前記音声認識手段と前記ＰＤＣ―Ｐ制御手段とが接続される場合に、前記ＨＴＭＬテキストの音声出力動作が実行され、又は、前記音声認識手段は、前記音声入力手段が取込んだ前記音声から前記ブラウザに対する制御指示を認識し、該制御指示を前記ブラウザに伝達し、前記ブラウザが前記音声認識手段から伝達された前記制御指示を解析し、適切な次のアクションを行うことを特徴とするブラウザ搭載装置。
2. 発声される可能性のある語彙を記憶する認識語彙記憶手段をさらに有し、
   前記音声認識手段は、認識語彙の辞書として前記認識語彙記憶手段を使用して前記ＨＴＭＬテキストを解析し、前記解析結果を基に、前記音声認識手段が行う音声認識の認識率を向上させ得る語彙を抽出し、前記ブラウザは、前記音声認識手段が抽出した語彙を前記認識語彙記憶手段に記憶させることを特徴とする請求項１記載のブラウザ搭載装置。
3. 前記ＨＴＭＬテキスト中に語彙が直接含まれる場合に、前記ブラウザは、該語彙を抽出して前記認識語彙記憶手段に記憶させることを特徴とする請求項２記載のブラウザ搭載装置。
4. 前記音声出力手段により出力される音声において、話者の性別、音声のピッチ／スピード、及び、読み上げピッチの加速具合いについての設定及び設定変更を可能とした出力音声設定手段を更に具備したことを特徴とする請求項１から３のいずれか１項に記載のブラウザ搭載装置。
5. 絵文字等の外字の読み上げ方法についての設定及び設定変更を可能とした外字読み上げ方法設定手段を更に具備したことを特徴とする請求項１から４のいずれか１項に記載のブラウザ搭載装置。

Images