【事件の表示】
　特願２００２−１３２０５３「ウェブ対応認識アーキテクチャを有するシステムおよびその方法」拒絶査定不服審判事件〔平成１５年　３月　７日出願公開、特開２００３−　６７１７７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１４年５月７日（パリ条約による優先権主張２００１年５月４日、米国、２００１年９月２０日、米国、２００２年４月５日、米国）の出願であって、平成１９年１２月６日付けの拒絶理由通知に対し、平成２０年３月１２日付けで手続補正されたが、同年４月１７日付けで拒絶査定され、これに対し、同年７月２２日に拒絶査定不服の審判が請求されるとともに、同日付けで手続補正がされたものである。
　
２．平成２０年７月２２日付けの手続補正について
　 平成２０年７月２２日付けの手続補正（以下、「本件補正」という。）は、
（１）請求項１に「前記クライアント」とあったところを、「前記第１のクライアントデバイス」と補正し、
（２）請求項２，３，７に「前記クライアントデバイス」とあったところを、「前記第１のクライアントデバイス」と補正し、
（３）請求項６に「前記入力データを」とあったところを、「前記第１のクライアントデバイスは、前記入力データを」と補正し、
（４）請求項６に「前記入力データを正規化するように、前記クライアントが適応されること」とあったところを「前記入力データを正規化すること」と補正し、
（５）請求項１０，１１に「前記クライアントデバイス」とあったところを、「前記第１及び第２のクライアントデバイス」と補正し、
（６）本件補正前の請求項１６に「第１のクライアントデバイス」とあったところを、「クライアントデバイス」と補正し、
（７）本件補正前の請求項１６，２０、２１に「前記クライアント」とあったところを、「クライアントデバイス」と補正し、
（８）請求項１２〜１４を削除し、該請求項の削除に応じて、本件補正前の請求項１５〜２４を繰り上げて請求項１２〜２１とするとともに、各請求項にて引用する請求項を、繰り上げ後の請求項へと補正するものである。
　よって、平成２０年７月２２日付けの手続補正は、審判請求書【本願発明が特許されるべき理由】（２）欄に「請求項１、１３、１８の補正は・・・クライアントデバイスと、ウェブサーバと、認識サーバとの関係を明確にしたものです。」、「請求項１２−１４に記載の発明は、削除致しました。」とあるとおり、特許法第１７条の２第第４項第１号（請求項の削除）及び同項第４号（明りょうでない記載の釈明）に掲げる事項を目的とするものである。
　
３．本願発明
　本願の請求項１〜２１に係る発明は、平成２０年７月２２日付け手続補正書により補正された明細書の特許請求の範囲の請求項１〜２１に記載されたとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
「【請求項１】　データを処理するサーバ／クライアントシステムであって、前記システムはネットワークを備え、前記ネットワークは、
　リモートでアクセスすることのでき、１組のフィールドを具備する情報を有するウェブサーバと、
　認識サーバと、
　前記ウェブサーバから前記情報を受信するように適応される第１のクライアントデバイスであって、前記第１のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示すると、前記フィールドの各々と関連付けられた入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信するように適応された第１のクライアントデバイスとを備え、
　前記認識サーバは、前記第１のクライアントデバイスからリモートに位置され、前記第１のクライアントデバイスから前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第１のクライアントデバイスおよび前記ウェブサーバの少なくとも１つに戻すように構成され、前記認識結果が前記第１のクライアントデバイスからの前記入力の認識がないことを指示するとき、前記ユーザに使用されるためのプロンプトを指示するデータを受信し、前記認識結果が前記第１のクライアントデバイスから前記入力の認識がないことを指示するとき、前記プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第１のクライアントデバイスに音声データを送信することを特徴とするシステム。」
　
４．引用例
　原査定の拒絶の理由に引用された、本願の優先日前に頒布された刊行物である、中野崇広 外２名，ＷＷＷ上のフォーム型情報検索サービスのための音声インタフェースの検討，情報処理学会研究報告、第９９巻、第１４号、社団法人情報処理学会発行，１９９９年２月６日，第１〜６頁（以下、「引用例」という。）には、図面とともに、以下の技術事項が記載されている。
（イ）「１　はじめに
　ＷＷＷ上の情報を閲覧したり情報検索サービスを利用するために、一般にマウスによる操作が可能なＧＵＩを備えたＷＷＷブラウザが利用されている。近年、ＷＷＷの利用が広がり、用途や利用環境（例えば携帯情報端末機器）も多様化していることから、ＷＷＷブラウザにおける音声インタフェースの拡張がいくつか検討されてきた［１，２，３，４，５，６，７，８］。」（第２頁左欄第１〜８行）
　
（ロ）「本研究では、特にＷｅｂぺージ中に選択メニューを持った情報検索サービスを対象として、特定の情報検索タスクに依存した対話モデルや言語モデルなどを使わず、汎用的な音声インタフェースを実現する方法を検討する。これまでにも同様なシステム例［４，１０］や、ＨＴＭＬの記述の段階でぺージ内で必要な音声認識文法を指定するタスク依存の方法によるシステム例［８］などの報告がある。提案するシステムは、対話のためのシステムのプロンプトを生成する機能を持たせると共に、Ｗｅｂブラウザへの表示を併用して汎用性を持たせていること、クライアント側のシステムを汎用のＷｅｂブラウザをメインとして軽量な実装を実現している点が主な特徴である。評価のために試作したシステムは、ＷＷＷブラウザで動作するＪａｖａ　ａｐｐｌｅｔを利用するとともに、クライアント・サーバ構成によって音声認識やフォームの解析等をリモート・サーバで実行するように実装を行なった。以下の節では、初めに音声インタフェースの設計について述べ、次に試作したシステムの構成と実行例および課題等について述べる。」（第２頁左欄第１７〜３６行）
　
（ハ）「ＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）の規格では、これらのＧＵＩをＷｅｂぺージ上に配置して機能させるために、フォームと呼ばれる書式を用意している。フォームの記述では、テキスト入カフィールドや、セレクトボックス（選択メニュー）、チェックボックス、ラジオボタンなどの種類がある。ここでは、フォームを利用してユーザが情報検索を行なえるように記述されたＷｅｂぺージを対象として、汎用的な音声インタフェースを提供する方法を検討する。」（第２頁右欄第３〜１２行）
　
（ニ）「２．２　フォーム入カへの音声利用
　フォームの記述では、一般に、ユーザが指定するべき複数の項目についての記述から構成されている。従って、フォームの記述を含むぺージ上でユーザが行なう情報検索の作業の流れは、情報検索において指定可能な属性に対する穴埋め（メニュー選択）のタスクとして見ることができる。そこで、この穴埋めのタスクを簡単な音声対話によって実現することを考える。」（第２頁右欄第１３〜２１行）
　
（ホ）「ここでは、前述のようなフォーム入力のＧＵＩを備えた情報検索ぺージにおいて、通常はマウスやキーボードを用いて行う一連のフォーム上の操作を、音声のみによって代替するための汎用的なインタフェースを提供することを検討する。また、可能な範囲で、ユーザが入力する必要がある項目について、システムからの音声による問合わせを可能にすることを考える。
　音声だけでブラウザ上のフォームに対する入力を行うには、フォーム内のセレクトボックスなど各入力毎に、システムから入力を促す方法が考えられる。このとき、ユーザには以下のような情報を提示する必要がある。
　・フォーム中のどの部分を入力しているのか
　・音声入力できるキーワードの一覧
このキーワードは、入力するフォームの種類によって変化する。チェックボックスであればチェックボックスに対応する項目名、セレクトボックスであればセレクトボックス内で選択可能な項目名、テキストボックスならばキーワードは自由入力となる。しかし、チェックボックスやラジオボタンの場合、ＨＴＭＬにおいて項目名の指定に関する明確な定義がないため、項目名を自動的に抽出することは困難である。また、テキストボックスについては、音声による自由入力の実装は容易ではない。但し、音声インタフェース用に文法を指定できるなど、マークアップ記述言語の規格の拡張を考えれば［１１］、将来的にはより実用的になると考える。セレクトボックスの場合は、現在のＨＴＭＬの書式においても、項目名を自動的に抽出することは比較的容易である。そこで、特にフォームの中にセレクトボックスを含むＷｅｂぺージをここで扱う対象とする。」（第２頁右欄第２７行〜第３頁左欄第２４行）
　
（ヘ）「２．３　選択型メニューのための音声インタフェース
　任意のフォームに対して音声インタフェースを実現するには、フォームの記述内容に応じて対話に必要なユーザ発話の文法やシステムの発話を自動的に生成する必要がある。選択型メニューのＧＵＩであるセレクトボックスについて音声インタフェースを作成するには、具体的に次のような処理が必要である。
　・選択リストに含まれるキーワード名の抽出
　・音声入力の認識用文法・辞書の生成
　・選択リストの入力項目の名前や種類の認識・抽出
　・システムからの問合わせ・応答文の生成
　・複数の選択リストに対する入力の対話管理
一番目のキーワード名については、ＨＴＭＬのタグの情報を用いてほぼ正確に対象ぺージの記述内容から抽出することができる。また、二番目の文法・辞書の生成については、以前に開発したシステム［９］で用いた方法とほぼ同じように、キーワードの形態素解析を行なった後、名詞の連続を主な単位とする一定の規則で、元のキーワードを形態素単位の系列からなる断片に分割したものを辞書に登録する。文法については、それらのキーワードの断片の単語発話の他、対話的な入力において必要となるユーザのコマンド発話等を定義する。」（第３頁左欄第２５行〜同頁右欄第６行）
　
（ト）「抽出されたテキストによる項目の情報には、おもに次のような種類が存在する。
　・箇条書き（例：「年齢：」、「出発地」）
　・疑問調の文（例：「出発地はどちらですか？」）
　・依頼調の文（例：「選択してください」）
これらの情報は、対話的にシステムからの問合わせを行なうために利用できると考えられる。図２（ａ）の例では、「搭乗日」、「出発地」などが項目名とみなすことができるので、項目名を問合わせるシステムの発話文のテンプレートに基づいて、「搭乗日を入力してください」や「出発地を入力してください」というように文を生成し、音声合成による問合わせを行なう。」（第４頁左欄第２０〜３２行）」
　
（チ）「３　音声インタフェースシステムの試作
３．１　システム構成
　図４に試作したシステムの全体の構成を示す。ユーザの計算機に相当するクライアント側では、ＷＷＷブラウザと音声入出力を受け持つ部分のみから構成される。また、試作システムでの主な処理は、リモートのハブ・ホスト上で行なう。このハブ・ホストでは、ＷＷＷサーバ、音声認識サーバとして機能する他、クライアント側で指定するＷｅｂぺージのＨＴＭＬファイルの取得および解析、ＷＷＷサーバのＣＧＩ（Ｃｏｍｍｏｎ　Ｇａｔｅｗａｙ　Ｉｎｔｅｒｆａｃｅ）機能を用いて文法・辞書生成、システム応答Ｗｅｂぺージ、システム応答発話文章の生成の処理などを行なう。生成されたシステムの発話文は、クライアント側にテキストまたは音声として送られ、クライアント側で再生される。
　音声認識サーバとしては、ネットワークベースで利用可能な音声認識システムＳＰＯＪＵＳ［１２，１３］を利用している。音声認識サーバは、音節単位のＨＭＭをべースとした不特定話者のシステムで、音声の取り込み及び分析を行なう音声入カサーバから音声データを受信しながら時間同期的に処理を行なう。音声入カサーバが音声認識サーバに送る音声データは、マイクから入力された音声信号を８ｍｓｅｃ周期で１４次のＬＰＣ分析を行ない、１０次元のメルケプストラム係数に変換したもので、４バイトのｆｌｏａｔ型を２バイトに近似している。また、形態素解析サーバには茶筅［１４］を用いた。
　
３．２　システムの実行例
　図５に、試作したシステムでのＷＷＷブラウザの画面表示の例を示す。本システムのＧＵＩは、全て一般的なＷＷＷブラウザ上で実装されている。図のように、ＷＷＷブラウザは縦三段のフレームで構成され、最上段のフレームは、フォーム入力を提供しているＷｅｂぺージを選択するためのインタフェースとしてＪａｖａアプレットが動作している。この部分が、音声入出力、音声認識部との通信、他のフレームの表示制御などを行う。中段のフレームは、最上段のフレームで指定されている、フォーム入力を含んだＷｅｂぺージが表示される。下段のフレームには、音声入力できるキーワードの一覧が表示される。
　ユーザは、システムからの音声による問合わせとブラウザ上に示されたキーワード一覧に基づいて、キーワードの一部または、入力項目を訂正・変更するためのコマンドを音声で入力できる。用意されている音声コマンドは、現在のところ、入力対象のセレクタの変更のためのもので、「戻る」、「つぎ」の２つである。
　図６に、ＪＡＬのホームページ［？］での音声インタフェースによる対話例を示す。ＷＷＷブラウザ上の表示では、ユーザの発話毎に検索ぺージ内の入力箇所を指し示す点滅のポインタが移動し、キーワード一覧の表示も切り替わる。」（第４頁左欄第３３行〜第５頁左欄第３行）
　
（リ）「・セレクトボックス以外のフォーム入力
情報検索のぺージには、セレクトボックス以外に、ボタン、チェックボックス、テキストボックス等を含む場合がある。特に前者２つについては、項目名についての情報の抽出が困難であり、特別な音声操作インタフェースが必要である。従って、マウス、キーボード等との併用によるユーザインタフェースも考える必要がある。音声インタフェースとブラウザをより融合するには、音声入力や携帯端末でのユーザインタフェースを想定し拡張されたマークアップ記述言語が望まれる。」（第６頁左欄第５〜１６行）
　
　また、引用例第５頁、図４には、ハブ・ホストが、クライアント・ホストへ「ＨＴＭＬファイル，Ｊａｖａ　ａｐｐｌｅｔ，システム応答」を送り、クライアント・ホストから「音声特徴パラメータ，制御コマンド」を受け取り、ハブ・ホストが、「ＷＷＷサーバ・ホスト１」、「ＷＷＷサーバ・ホスト２」等の「ＷＷＷサーバ・ホスト」から「ＨＴＭＬファイル」を受け取り、「ＷＷＷサーバ・ホスト」へ「フォーム入力データ」を送る、システムの構成が記載され、さらに、「ハブ・ホスト」が「ＨＴＴＰプロキシ」の機能を備えていることが記載されている。
　
　また、引用例第５頁、図６には「音声インタフェースによる対話例」として
「システム：「搭乗日を入力してください。」
ユーザ：「２月」
システム：（注：システムからのプロンプトなし）
ユーザ：「１６日」
システム：「出発地を入力してください。」
ユーザ：「東京です。」（注：“東京羽田”を省略）
システム：「到着地を入力してください。」
ユーザ：「えーと、名古屋です」
システム：「利用時間帯を入力してください。」
ユーザ：「もどる」（注：到着地を訂正）
システム：「到着地を入力してください。」
　：」
と記載されている。
　
　上記引用例記載事項及び図面の記載を総合勘案すると、引用例には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「クライアント・サーバ構成によって、リモートのハブ・ホストが、音声認識や、ＷＷＷサーバ・ホストから受け取ったＨＴＭＬファイルのフォームの解析等を実行し、ユーザは音声だけでブラウザ上のフォームに対する入力を行ない、ハブ・ホストがＷＷＷサーバ・ホストへフォーム入力データを送るシステムにおいて、
　フォームは、「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目についての記述から構成され、
　ユーザの計算機に相当するクライアント側では、ＷＷＷブラウザと音声入出力を受け持つ部分のみから構成され、
　ＷＷＷブラウザは縦三段のフレームで構成され、最上段のフレームは、フォーム入力を提供しているＷｅｂぺージを選択するためのインタフェースとしてＪａｖａアプレットが動作し、この部分が、音声入出力、音声認識部との通信、他のフレームの表示制御などを行ない、中段のフレームは、フォーム入力を含んだＷｅｂぺージが表示され、下段のフレームには、音声入力できるキーワードの一覧が表示され、ユーザは、システムからの音声による問合わせとブラウザ上に示されたキーワード一覧に基づいて、キーワードの一部または、入力項目を訂正・変更するためのコマンドを、音声で入力でき、入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ、音声コマンドは、入力対象のセレクタの変更のためのもので、「戻る」、「つぎ」の２つであり、ＷＷＷブラウザ上の表示では、ユーザの発話毎に検索ぺージ内の入力箇所を指し示す点滅のポインタが移動し、フォーム内のセレクトボックスなど各入力毎に、システムから入力が促がされ、
　ハブ・ホストは、ＷＷＷサーバ、音声認識サーバとして機能する他、クライアント側で指定するＷｅｂぺージのＨＴＭＬファイルの取得および解析を行い、さらに、フォームの記述内容に応じて対話に必要な、音声入力の認識用文法や、「搭乗日を入力してください」や「出発地を入力してください」というような、システムからの問合わせ・応答文を生成し、生成された問合わせ・応答文は、クライアント側に音声として送られ、文法については、キーワードの断片の単語発話の他、対話的な入力において必要となるユーザのコマンド発話等が定義され、さらにハブ・ホストは、ＷＷＷサーバ・ホストへフォーム入力データを送る、
　システム。」
　
５．対比
　本願発明を、引用発明と対比する。
　引用発明における「システム」は、「クライアント・サーバ構成」であって、「フォーム入力データ」についての処理を行っているから、本願発明の「データを処理するサーバ／クライアントシステム」に相当する。
　また、「クライアントサーバー・システム」とは、「ネットワーク上で動作する各種のシステムのうち、クライアントコンピューターとサーバーコンピューターで処理を分担するシステム」（日経パソコン新語辞典　９９年版、１９９９年３月１６日、初版第三刷、第４７０〜４７１頁「クライアントサーバー・システム」の項目）を意味するから、引用発明における、「クライアント・サーバ構成」の「システム」が、ネットワークを備えていることは明らかである。
　次に、引用発明において、「「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目」に対応した「検索ぺージ内の入力箇所」が、本願発明の「フィールド」に相当する。
　次に、引用発明において、「フォームは、「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目についての記述から構成され」ているから、引用発明において「検索ぺージ内の入力箇所」が「一組」あることは明らかである。よって、引用発明における、かかる「フォーム入力を含んだＷｅｂぺージ」が、本願発明の「１組のフィールドを具備する情報」に相当する。
　次に、ＷＷＷサーバはネットワークを介してアクセスされるものであるから、引用発明において、「フォーム入力を含んだＷｅｂぺージ」を有する「ＷＷＷサーバ・ホスト」が、本願発明の「リモートでアクセスすることのでき、１組のフィールドを具備する情報を有するウェブサーバ」に相当する。
　次に、引用発明の「リモートのハブ・ホスト」は、「音声認識サーバとして機能」する点で、本願発明の「前記第１のクライアントデバイスからリモートに位置され」た「認識サーバ」に相当する。
　次に、引用発明における「クライアント側」の「ユーザの計算機」は、「フォーム入力を含んだＷｅｂぺージ」の選択と表示とを行っているが、該「Ｗｅｂぺージ」を記述したＨＴＭＬファイルは、引用例図４に記載のとおり、「ＷＷＷサーバ・ホスト」から「ハブ・ホスト」のＨＴＴＰプロキシを中継して「クライアント側」の「ユーザの計算機」が取得したものであると認められるから、引用発明における「クライアント側」の「ユーザの計算機」は、本願発明の「前記ウェブサーバから前記情報を受信するように適応される第１のクライアントデバイス」に相当するといえる。
　次に、引用発明における「クライアント側」の「ユーザの計算機」において、「ユーザ」が、「戻る」、「つぎ」という「音声コマンド」によって「入力対象のセレクタ」の「変更」を行ない、「検索ぺージ内の入力箇所」を移動させることが、本願発明の「前記第１のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示する」ことに相当する。
　次に、引用発明の「音声データの音声特徴パラメータ」は、本願明細書第【００３０】段落に「デジタル化したオーディオ信号または音声特徴などの音声データ」と記載されていることから、本願発明の「入力音声データ」に相当する。
　次に、引用発明において、「ユーザ」が、「検索ぺージ内の入力箇所」に関連する「キーワードの一部」を「音声で入力」し、「入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ」ることと、本願発明の「前記フィールドの各々と関連付けられた入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信する」こととは、前記フィールドの各々と関連付けられた入力音声データを前記認識サーバに送信する点で一致する。
　次に、本願明細書第【００４７】段落には「本明細書で使用する場合、「文法」とは認識を行うための情報を含み、別の実施形態では、例えば特定のフィールドに入力されることが予想される入力に対応する情報を含む。）」と記載されているから、引用発明において、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」が本願発明の「フィールドの文法」に相当する。
　次に、音声認識とは、「音声による情報をコンピュータ処理が可能なディジタルデータに変換する」（最新版エレクトロニクス用語事典、株式会社オーム社、平成９年１２月２０日、第１版第６刷、第７７頁「音声認識装置」の項目）ことであるから、引用発明において、「リモートのハブ・ホスト」が、「音声認識サーバとして」の機能により、「リモートのハブ・ホスト」で生成された、「キーワードの断片の単語発話」を含む「音声入力の認識用文法」を使用し、何が認識されたかを表すデータを生成していることは明らかである。よって、引用発明において、「入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ」、「リモートのハブ・ホスト」が、「音声認識サーバとして」の機能により、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」を使用して音声認識を行ない、「ＷＷＷサーバ・ホストへフォーム入力データを送る」ことと、本願発明の「認識サーバ」が、「前記第１のクライアントデバイスから前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第１のクライアントデバイスおよび前記ウェブサーバの少なくとも１つに戻す」こととは、認識サーバが、前記第１のクライアントデバイスから前記入力音声データを受信し、フィールドの文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第１のクライアントデバイスおよび前記ウェブサーバの少なくとも１つに戻す点で一致する。
　次に、引用発明の「ハブ・ホスト」は、音声認識サーバとして機能する他、「クライアント側で指定するＷｅｂぺージのＨＴＭＬファイルの取得および解析を行い」、「「搭乗日を入力してください」や「出発地を入力してください」というような、システムからの問合わせ・応答文を生成し、生成された問合わせ・応答文は、クライアント側に音声として送られ」ているが、該「システムからの問合わせ・応答文」が、音声合成により音声データに変換され、ネットワークを介してクライアント側に音声として送られていることは、前記「４．引用例」の摘記事項（ト）、（チ）より明らかである。
　よって、引用発明の「リモートのハブ・ホスト」と本願の「認識サーバ」とは、プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第１のクライアントデバイスに音声データを送信する点で一致するといえる。
　
　すると、本願発明と、引用発明とは、次の点で一致する。
＜一致点＞
　データを処理するサーバ／クライアントシステムであって、前記システムはネットワークを備え、前記ネットワークは、
　リモートでアクセスすることのでき、１組のフィールドを具備する情報を有するウェブサーバと、
　認識サーバと、
　前記ウェブサーバから前記情報を受信するように適応される第１のクライアントデバイスであって、前記第１のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示すると、前記フィールドの各々と関連付けられた入力音声データを前記認識サーバに送信するように適応された第１のクライアントデバイスとを備え、
　前記認識サーバは、前記第１のクライアントデバイスからリモートに位置され、前記第１のクライアントデバイスから前記入力音声データを受信し、フィールドの文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第１のクライアントデバイスおよび前記ウェブサーバの少なくとも１つに戻すように構成され、プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第１のクライアントデバイスに音声データを送信することを特徴とするシステム。
　
　一方で、両者は次の相違点で相違する。
＜相違点１＞
　本願発明では、「第１のクライアントデバイス」が、「入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信するように適応され」、「認識サーバ」が「前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理」しているのに対し、引用発明では、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）が、「入力された音声データの音声特徴パラメータ」（入力音声データ）を「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からハブ・ホスト（認識サーバ）に送り、「ハブ・ホスト」（認識サーバ）が前記「入力された音声データの音声特徴パラメータ」（入力音声データ）を、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」（フィールドの文法）を使用して処理しているものの、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）が「入力された音声データの音声特徴パラメータ」（入力音声データ）を記録しているか明らかではなく、また、「音声入力の認識用文法」（文法）は、ハブ・ホスト（認識サーバ）で生成されているため、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からハブ・ホスト（認識サーバ）にフィールドの文法の指示が送られていない点。
　
＜相違点２＞
　本願発明では、「認識サーバ」が、「前記認識結果が前記第１のクライアントデバイスからの前記入力の認識がないことを指示するとき、前記ユーザに使用されるためのプロンプトを指示するデータを受信し、前記認識結果が前記第１のクライアントデバイスから前記入力の認識がないことを指示するとき、前記プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第１のクライアントデバイスに音声データを送信する」のに対し、引用発明では、「ハブ・ホスト」（認識サーバ）が、「システムからの問合わせ・応答文」を、音声合成により「音声」に変換し、ネットワークを介してクライアント側に音声として送っていることは明らかであるものの、引用発明には、「ハブ・ホスト」（認識サーバ）が、「音声認識サーバとして」の機能により音声認識を行った結果、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からの入力の認識がない場合についての言及が無いため、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からの入力の認識がない場合、前記ユーザに使用されるための「システムからの問合わせ・応答文」（プロンプト）を指示するデータを受信し、前記「システムからの問合わせ・応答文」（プロンプト）を指示するデータを音声データに変換し、前記ネットワークを介して前記第１のクライアントデバイスに音声データを送信しているか否か明らかでない点。
　
６．判断
＜相違点１＞について：
　「文法」について、本願明細書第【００４７】段落に「本明細書で使用する場合、「文法」とは認識を行うための情報を含み、別の実施形態では、例えば特定のフィールドに入力されることが予想される入力に対応する情報を含む。）」と記載されていることを踏まえれば、入力音声データを記録し、かつ前記入力音声データと文法の指示を音声認識サーバに送信し、音声認識サーバが前記入力音声データと文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理することは、本願の優先日前において周知技術である（例えば、特開平１０−２４０４９３号公報（フロントページ、【解決手段】欄）、渕　武志、加藤恒昭、ＷＷＷブラウザの音声による制御、情報処理学会研究報告　９７−ＳＬＰ−１６、第９７巻、第５２号、１９９７年５月２６日、第３７〜４２頁（「マイクからの入力があると、これを音声データとして記録する。そして、音声認識サーバとの通信を開始し、認識単語候補と音声データを送信する。音声認識サーバは認識単語候補の中から音声データに最も近い単語を算出し、この単語を音声入力プロセスに返す。」（第４０頁第１４〜１６行））。
　したがって、かかる周知技術を引用発明に適用し、引用発明において、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）が、「入力された音声データの音声特徴パラメータ」（入力音声データ）を記録し、前記「入力された音声データの音声特徴パラメータ」（入力音声データ）と「音声入力の認識用文法」（文法）の指示を「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からハブ・ホスト（認識サーバ）に送り、「ハブ・ホスト」（認識サーバ）が前記「入力された音声データの音声特徴パラメータ」（入力音声データ）及び「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」（フィールド文法）の指示を受け、該「音声入力の認識用文法」（文法）の指示を使用して該「入力された音声データの音声特徴パラメータ」（入力音声データ）を処理するようにすることは、当業者が容易になし得たことである。
　
＜相違点２＞について：
　電話の声でインターネットを検索　「音声ポータル」が登場、日経コンピュータ、２００１年３月１２日、第５１７号、ｐ．２８〜３０には、「図２●ＶｏｉｃｅＸＭＬの記述例。ニュース，天気，株価，レストランという４種類のサービスから一つを選択するシナリオである。最初に「ご利用になりたいサービスは何ですか」というガイダンスを読み上げる。利用者が「どんなサービスがあるの」などと聞き返した場合は「ｈｅｌｐ」，言った言葉を認識できなかった場合は「ｎｏｍａｔｃｈ」というタグで定義されているメッセージを読み上げる。ＶｏｉｃｅＸＭＬ１．０の仕様は，標準化団体「ＶｏｉｃｅＸＭＬフォーラム」が２０００年３月に決定し，Ｗｅｂ関連技術の標準化団体Ｗ３Ｃが同５月に承認した」（第２９頁図２の説明）と記載され、第２９頁図２の「ＶｏｉｃｅＸＭＬの記述例」中に「＜ｎｏｍａｔｃｈ＞申しわけありません，聞き取れませんでした。もう一度，お願いします。＜／ｎｏｍａｔｃｈ＞」と記載されている。
　さらに、「インタプリタでシナリオを実行　音声ポータル・サービスを実現するシステムの基本的な構成は，図３のようになる。中核となるのは，「ＶｏｉｃｅＸＭＬインタプリタ」と「音声応答用ミドルウエア」という２種類のソフトウエアである。音声応答用ミドルウエアは，利用者が発した音声を受け取り，音声認識ソフトでテキスト・データに変換してから，そのテキストをＶｏｉｃｅＸＭＬインタプリタに渡す。ＶｏｉｃｅＸＭＬインタプリタは，テキストの内容に従って，ＶｏｉｃｅＸＭＬで記述されたＷｅｂコンテンツをコンテンツ提供会社のＷｅｂサーバーなどから読み込み，シナリオを実行する。得られた検索結果などは音声応答用ミドルウエアが受け取り，利用者に伝える。音声で読み上げる部分は，音声合成ソフトを使ってテキスト・データを音声データに変換する。」（第３０頁左欄第１１〜３１行）と記載され、第３０頁図３の説明には、「●音声ポータル・システムの基本的な構成。音声ポータル・サイトは，音声応答システムだけをもつ。コンテンツ提供会社のＷｅｂサーバーやアプリケーション・サーバーには，インターネットを介してアクセスする。通常，音声応答サーバーにはＷｉｎｄｏｗｓ　ＮＴサーバーを使う。この上で，ＶｏｉｃｅＸＭＬインタプリタ，音声応答用ミドルウエアといったソフトウエアを動かす。音声認識ソフトは音声応答サーバーで実行することもできるが，音声ポータルでは同時に処理しなければならない音声の件数が増えるので，独立したサーバーにするのが一般的。ＶｏｉｃｅＸＭＬインタプリタは「ＶｏｉｃｅＸＭＬブラウザ」とも言う」と記載されている。
  
　上記文献中の上記記載は、音声応答システムに関する一般的な記載であるから、本願の優先日前において、音声認識ソフトを実行するサーバーが、利用者の言った言葉を認識できなかった場合、マークアップ言語で記述されたページ中に定義されている「申し訳ありません，聞き取れませんでした。もう一度，お願いします。」といったメッセージのテキスト・データを音声応答用ミドルウエアが受け取り、音声合成ソフトを使って該テキスト・データを音声データに変換して利用者に伝えることは周知技術であったものと認められる。
　
　したがって、かかる周知技術を引用発明に適用し、引用発明において、「ハブ・ホスト」（認識サーバ）が、「音声認識サーバとして」の機能により音声認識を行った結果、「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）からの入力の認識がない場合、「申し訳ありません，聞き取れませんでした。もう一度，お願いします。」といった、利用者に伝えるメッセージのテキスト・データ（ユーザに使用されるためのプロンプトを指示するデータ）を受け取り、該メッセージのテキスト・データ（プロンプトを指示するデータ）を、引用発明の「システムからの問合わせ・応答文」と同様に、音声合成により音声データに変換し、ネットワークを介して「クライアント側」の「ユーザの計算機」（第１のクライアントデバイス）に音声データとして送るようにすることは、当業者が容易になし得たことである。
　
　また、本願発明の作用効果も、引用発明及び周知技術に基づいて当業者が容易に予測しうるものである。
　
７．むすび
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、その余の請求項について論及するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。