ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
---|---|
管理番号 | 1237418 |
審判番号 | 不服2008-18631 |
総通号数 | 139 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2011-07-29 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2008-07-22 |
確定日 | 2011-05-23 |
事件の表示 | 特願2002-132053「ウェブ対応認識アーキテクチャを有するシステムおよびその方法」拒絶査定不服審判事件〔平成15年 3月 7日出願公開、特開2003- 67177〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
1.手続の経緯 本願は、平成14年5月7日(パリ条約による優先権主張2001年5月4日、米国、2001年9月20日、米国、2002年4月5日、米国)の出願であって、平成19年12月6日付けの拒絶理由通知に対し、平成20年3月12日付けで手続補正されたが、同年4月17日付けで拒絶査定され、これに対し、同年7月22日に拒絶査定不服の審判が請求されるとともに、同日付けで手続補正がされたものである。 2.平成20年7月22日付けの手続補正について 平成20年7月22日付けの手続補正(以下、「本件補正」という。)は、 (1)請求項1に「前記クライアント」とあったところを、「前記第1のクライアントデバイス」と補正し、 (2)請求項2,3,7に「前記クライアントデバイス」とあったところを、「前記第1のクライアントデバイス」と補正し、 (3)請求項6に「前記入力データを」とあったところを、「前記第1のクライアントデバイスは、前記入力データを」と補正し、 (4)請求項6に「前記入力データを正規化するように、前記クライアントが適応されること」とあったところを「前記入力データを正規化すること」と補正し、 (5)請求項10,11に「前記クライアントデバイス」とあったところを、「前記第1及び第2のクライアントデバイス」と補正し、 (6)本件補正前の請求項16に「第1のクライアントデバイス」とあったところを、「クライアントデバイス」と補正し、 (7)本件補正前の請求項16,20、21に「前記クライアント」とあったところを、「クライアントデバイス」と補正し、 (8)請求項12?14を削除し、該請求項の削除に応じて、本件補正前の請求項15?24を繰り上げて請求項12?21とするとともに、各請求項にて引用する請求項を、繰り上げ後の請求項へと補正するものである。 よって、平成20年7月22日付けの手続補正は、審判請求書【本願発明が特許されるべき理由】(2)欄に「請求項1、13、18の補正は・・・クライアントデバイスと、ウェブサーバと、認識サーバとの関係を明確にしたものです。」、「請求項12-14に記載の発明は、削除致しました。」とあるとおり、特許法第17条の2第第4項第1号(請求項の削除)及び同項第4号(明りょうでない記載の釈明)に掲げる事項を目的とするものである。 3.本願発明 本願の請求項1?21に係る発明は、平成20年7月22日付け手続補正書により補正された明細書の特許請求の範囲の請求項1?21に記載されたとおりのものであるところ、請求項1に係る発明(以下、「本願発明」という。)は、次のとおりのものである。 「【請求項1】 データを処理するサーバ/クライアントシステムであって、前記システムはネットワークを備え、前記ネットワークは、 リモートでアクセスすることのでき、1組のフィールドを具備する情報を有するウェブサーバと、 認識サーバと、 前記ウェブサーバから前記情報を受信するように適応される第1のクライアントデバイスであって、前記第1のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示すると、前記フィールドの各々と関連付けられた入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信するように適応された第1のクライアントデバイスとを備え、 前記認識サーバは、前記第1のクライアントデバイスからリモートに位置され、前記第1のクライアントデバイスから前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第1のクライアントデバイスおよび前記ウェブサーバの少なくとも1つに戻すように構成され、前記認識結果が前記第1のクライアントデバイスからの前記入力の認識がないことを指示するとき、前記ユーザに使用されるためのプロンプトを指示するデータを受信し、前記認識結果が前記第1のクライアントデバイスから前記入力の認識がないことを指示するとき、前記プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第1のクライアントデバイスに音声データを送信することを特徴とするシステム。」 4.引用例 原査定の拒絶の理由に引用された、本願の優先日前に頒布された刊行物である、中野崇広 外2名,WWW上のフォーム型情報検索サービスのための音声インタフェースの検討,情報処理学会研究報告、第99巻、第14号、社団法人情報処理学会発行,1999年2月6日,第1?6頁(以下、「引用例」という。)には、図面とともに、以下の技術事項が記載されている。 (イ)「1 はじめに WWW上の情報を閲覧したり情報検索サービスを利用するために、一般にマウスによる操作が可能なGUIを備えたWWWブラウザが利用されている。近年、WWWの利用が広がり、用途や利用環境(例えば携帯情報端末機器)も多様化していることから、WWWブラウザにおける音声インタフェースの拡張がいくつか検討されてきた[1,2,3,4,5,6,7,8]。」(第2頁左欄第1?8行) (ロ)「本研究では、特にWebぺージ中に選択メニューを持った情報検索サービスを対象として、特定の情報検索タスクに依存した対話モデルや言語モデルなどを使わず、汎用的な音声インタフェースを実現する方法を検討する。これまでにも同様なシステム例[4,10]や、HTMLの記述の段階でぺージ内で必要な音声認識文法を指定するタスク依存の方法によるシステム例[8]などの報告がある。提案するシステムは、対話のためのシステムのプロンプトを生成する機能を持たせると共に、Webブラウザへの表示を併用して汎用性を持たせていること、クライアント側のシステムを汎用のWebブラウザをメインとして軽量な実装を実現している点が主な特徴である。評価のために試作したシステムは、WWWブラウザで動作するJava appletを利用するとともに、クライアント・サーバ構成によって音声認識やフォームの解析等をリモート・サーバで実行するように実装を行なった。以下の節では、初めに音声インタフェースの設計について述べ、次に試作したシステムの構成と実行例および課題等について述べる。」(第2頁左欄第17?36行) (ハ)「HTML(Hyper Text Markup Language)の規格では、これらのGUIをWebぺージ上に配置して機能させるために、フォームと呼ばれる書式を用意している。フォームの記述では、テキスト入カフィールドや、セレクトボックス(選択メニュー)、チェックボックス、ラジオボタンなどの種類がある。ここでは、フォームを利用してユーザが情報検索を行なえるように記述されたWebぺージを対象として、汎用的な音声インタフェースを提供する方法を検討する。」(第2頁右欄第3?12行) (ニ)「2.2 フォーム入カへの音声利用 フォームの記述では、一般に、ユーザが指定するべき複数の項目についての記述から構成されている。従って、フォームの記述を含むぺージ上でユーザが行なう情報検索の作業の流れは、情報検索において指定可能な属性に対する穴埋め(メニュー選択)のタスクとして見ることができる。そこで、この穴埋めのタスクを簡単な音声対話によって実現することを考える。」(第2頁右欄第13?21行) (ホ)「ここでは、前述のようなフォーム入力のGUIを備えた情報検索ぺージにおいて、通常はマウスやキーボードを用いて行う一連のフォーム上の操作を、音声のみによって代替するための汎用的なインタフェースを提供することを検討する。また、可能な範囲で、ユーザが入力する必要がある項目について、システムからの音声による問合わせを可能にすることを考える。 音声だけでブラウザ上のフォームに対する入力を行うには、フォーム内のセレクトボックスなど各入力毎に、システムから入力を促す方法が考えられる。このとき、ユーザには以下のような情報を提示する必要がある。 ・フォーム中のどの部分を入力しているのか ・音声入力できるキーワードの一覧 このキーワードは、入力するフォームの種類によって変化する。チェックボックスであればチェックボックスに対応する項目名、セレクトボックスであればセレクトボックス内で選択可能な項目名、テキストボックスならばキーワードは自由入力となる。しかし、チェックボックスやラジオボタンの場合、HTMLにおいて項目名の指定に関する明確な定義がないため、項目名を自動的に抽出することは困難である。また、テキストボックスについては、音声による自由入力の実装は容易ではない。但し、音声インタフェース用に文法を指定できるなど、マークアップ記述言語の規格の拡張を考えれば[11]、将来的にはより実用的になると考える。セレクトボックスの場合は、現在のHTMLの書式においても、項目名を自動的に抽出することは比較的容易である。そこで、特にフォームの中にセレクトボックスを含むWebぺージをここで扱う対象とする。」(第2頁右欄第27行?第3頁左欄第24行) (ヘ)「2.3 選択型メニューのための音声インタフェース 任意のフォームに対して音声インタフェースを実現するには、フォームの記述内容に応じて対話に必要なユーザ発話の文法やシステムの発話を自動的に生成する必要がある。選択型メニューのGUIであるセレクトボックスについて音声インタフェースを作成するには、具体的に次のような処理が必要である。 ・選択リストに含まれるキーワード名の抽出 ・音声入力の認識用文法・辞書の生成 ・選択リストの入力項目の名前や種類の認識・抽出 ・システムからの問合わせ・応答文の生成 ・複数の選択リストに対する入力の対話管理 一番目のキーワード名については、HTMLのタグの情報を用いてほぼ正確に対象ぺージの記述内容から抽出することができる。また、二番目の文法・辞書の生成については、以前に開発したシステム[9]で用いた方法とほぼ同じように、キーワードの形態素解析を行なった後、名詞の連続を主な単位とする一定の規則で、元のキーワードを形態素単位の系列からなる断片に分割したものを辞書に登録する。文法については、それらのキーワードの断片の単語発話の他、対話的な入力において必要となるユーザのコマンド発話等を定義する。」(第3頁左欄第25行?同頁右欄第6行) (ト)「抽出されたテキストによる項目の情報には、おもに次のような種類が存在する。 ・箇条書き(例:「年齢:」、「出発地」) ・疑問調の文(例:「出発地はどちらですか?」) ・依頼調の文(例:「選択してください」) これらの情報は、対話的にシステムからの問合わせを行なうために利用できると考えられる。図2(a)の例では、「搭乗日」、「出発地」などが項目名とみなすことができるので、項目名を問合わせるシステムの発話文のテンプレートに基づいて、「搭乗日を入力してください」や「出発地を入力してください」というように文を生成し、音声合成による問合わせを行なう。」(第4頁左欄第20?32行)」 (チ)「3 音声インタフェースシステムの試作 3.1 システム構成 図4に試作したシステムの全体の構成を示す。ユーザの計算機に相当するクライアント側では、WWWブラウザと音声入出力を受け持つ部分のみから構成される。また、試作システムでの主な処理は、リモートのハブ・ホスト上で行なう。このハブ・ホストでは、WWWサーバ、音声認識サーバとして機能する他、クライアント側で指定するWebぺージのHTMLファイルの取得および解析、WWWサーバのCGI(Common Gateway Interface)機能を用いて文法・辞書生成、システム応答Webぺージ、システム応答発話文章の生成の処理などを行なう。生成されたシステムの発話文は、クライアント側にテキストまたは音声として送られ、クライアント側で再生される。 音声認識サーバとしては、ネットワークベースで利用可能な音声認識システムSPOJUS[12,13]を利用している。音声認識サーバは、音節単位のHMMをべースとした不特定話者のシステムで、音声の取り込み及び分析を行なう音声入カサーバから音声データを受信しながら時間同期的に処理を行なう。音声入カサーバが音声認識サーバに送る音声データは、マイクから入力された音声信号を8msec周期で14次のLPC分析を行ない、10次元のメルケプストラム係数に変換したもので、4バイトのfloat型を2バイトに近似している。また、形態素解析サーバには茶筅[14]を用いた。 3.2 システムの実行例 図5に、試作したシステムでのWWWブラウザの画面表示の例を示す。本システムのGUIは、全て一般的なWWWブラウザ上で実装されている。図のように、WWWブラウザは縦三段のフレームで構成され、最上段のフレームは、フォーム入力を提供しているWebぺージを選択するためのインタフェースとしてJavaアプレットが動作している。この部分が、音声入出力、音声認識部との通信、他のフレームの表示制御などを行う。中段のフレームは、最上段のフレームで指定されている、フォーム入力を含んだWebぺージが表示される。下段のフレームには、音声入力できるキーワードの一覧が表示される。 ユーザは、システムからの音声による問合わせとブラウザ上に示されたキーワード一覧に基づいて、キーワードの一部または、入力項目を訂正・変更するためのコマンドを音声で入力できる。用意されている音声コマンドは、現在のところ、入力対象のセレクタの変更のためのもので、「戻る」、「つぎ」の2つである。 図6に、JALのホームページ[?]での音声インタフェースによる対話例を示す。WWWブラウザ上の表示では、ユーザの発話毎に検索ぺージ内の入力箇所を指し示す点滅のポインタが移動し、キーワード一覧の表示も切り替わる。」(第4頁左欄第33行?第5頁左欄第3行) (リ)「・セレクトボックス以外のフォーム入力 情報検索のぺージには、セレクトボックス以外に、ボタン、チェックボックス、テキストボックス等を含む場合がある。特に前者2つについては、項目名についての情報の抽出が困難であり、特別な音声操作インタフェースが必要である。従って、マウス、キーボード等との併用によるユーザインタフェースも考える必要がある。音声インタフェースとブラウザをより融合するには、音声入力や携帯端末でのユーザインタフェースを想定し拡張されたマークアップ記述言語が望まれる。」(第6頁左欄第5?16行) また、引用例第5頁、図4には、ハブ・ホストが、クライアント・ホストへ「HTMLファイル,Java applet,システム応答」を送り、クライアント・ホストから「音声特徴パラメータ,制御コマンド」を受け取り、ハブ・ホストが、「WWWサーバ・ホスト1」、「WWWサーバ・ホスト2」等の「WWWサーバ・ホスト」から「HTMLファイル」を受け取り、「WWWサーバ・ホスト」へ「フォーム入力データ」を送る、システムの構成が記載され、さらに、「ハブ・ホスト」が「HTTPプロキシ」の機能を備えていることが記載されている。 また、引用例第5頁、図6には「音声インタフェースによる対話例」として 「システム:「搭乗日を入力してください。」 ユーザ:「2月」 システム:(注:システムからのプロンプトなし) ユーザ:「16日」 システム:「出発地を入力してください。」 ユーザ:「東京です。」(注:“東京羽田”を省略) システム:「到着地を入力してください。」 ユーザ:「えーと、名古屋です」 システム:「利用時間帯を入力してください。」 ユーザ:「もどる」(注:到着地を訂正) システム:「到着地を入力してください。」 :」 と記載されている。 上記引用例記載事項及び図面の記載を総合勘案すると、引用例には、次の発明(以下、「引用発明」という。)が記載されていると認められる。 「クライアント・サーバ構成によって、リモートのハブ・ホストが、音声認識や、WWWサーバ・ホストから受け取ったHTMLファイルのフォームの解析等を実行し、ユーザは音声だけでブラウザ上のフォームに対する入力を行ない、ハブ・ホストがWWWサーバ・ホストへフォーム入力データを送るシステムにおいて、 フォームは、「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目についての記述から構成され、 ユーザの計算機に相当するクライアント側では、WWWブラウザと音声入出力を受け持つ部分のみから構成され、 WWWブラウザは縦三段のフレームで構成され、最上段のフレームは、フォーム入力を提供しているWebぺージを選択するためのインタフェースとしてJavaアプレットが動作し、この部分が、音声入出力、音声認識部との通信、他のフレームの表示制御などを行ない、中段のフレームは、フォーム入力を含んだWebぺージが表示され、下段のフレームには、音声入力できるキーワードの一覧が表示され、ユーザは、システムからの音声による問合わせとブラウザ上に示されたキーワード一覧に基づいて、キーワードの一部または、入力項目を訂正・変更するためのコマンドを、音声で入力でき、入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ、音声コマンドは、入力対象のセレクタの変更のためのもので、「戻る」、「つぎ」の2つであり、WWWブラウザ上の表示では、ユーザの発話毎に検索ぺージ内の入力箇所を指し示す点滅のポインタが移動し、フォーム内のセレクトボックスなど各入力毎に、システムから入力が促がされ、 ハブ・ホストは、WWWサーバ、音声認識サーバとして機能する他、クライアント側で指定するWebぺージのHTMLファイルの取得および解析を行い、さらに、フォームの記述内容に応じて対話に必要な、音声入力の認識用文法や、「搭乗日を入力してください」や「出発地を入力してください」というような、システムからの問合わせ・応答文を生成し、生成された問合わせ・応答文は、クライアント側に音声として送られ、文法については、キーワードの断片の単語発話の他、対話的な入力において必要となるユーザのコマンド発話等が定義され、さらにハブ・ホストは、WWWサーバ・ホストへフォーム入力データを送る、 システム。」 5.対比 本願発明を、引用発明と対比する。 引用発明における「システム」は、「クライアント・サーバ構成」であって、「フォーム入力データ」についての処理を行っているから、本願発明の「データを処理するサーバ/クライアントシステム」に相当する。 また、「クライアントサーバー・システム」とは、「ネットワーク上で動作する各種のシステムのうち、クライアントコンピューターとサーバーコンピューターで処理を分担するシステム」(日経パソコン新語辞典 99年版、1999年3月16日、初版第三刷、第470?471頁「クライアントサーバー・システム」の項目)を意味するから、引用発明における、「クライアント・サーバ構成」の「システム」が、ネットワークを備えていることは明らかである。 次に、引用発明において、「「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目」に対応した「検索ぺージ内の入力箇所」が、本願発明の「フィールド」に相当する。 次に、引用発明において、「フォームは、「搭乗日」、「出発地」などの、ユーザが指定するべき複数の項目についての記述から構成され」ているから、引用発明において「検索ぺージ内の入力箇所」が「一組」あることは明らかである。よって、引用発明における、かかる「フォーム入力を含んだWebぺージ」が、本願発明の「1組のフィールドを具備する情報」に相当する。 次に、WWWサーバはネットワークを介してアクセスされるものであるから、引用発明において、「フォーム入力を含んだWebぺージ」を有する「WWWサーバ・ホスト」が、本願発明の「リモートでアクセスすることのでき、1組のフィールドを具備する情報を有するウェブサーバ」に相当する。 次に、引用発明の「リモートのハブ・ホスト」は、「音声認識サーバとして機能」する点で、本願発明の「前記第1のクライアントデバイスからリモートに位置され」た「認識サーバ」に相当する。 次に、引用発明における「クライアント側」の「ユーザの計算機」は、「フォーム入力を含んだWebぺージ」の選択と表示とを行っているが、該「Webぺージ」を記述したHTMLファイルは、引用例図4に記載のとおり、「WWWサーバ・ホスト」から「ハブ・ホスト」のHTTPプロキシを中継して「クライアント側」の「ユーザの計算機」が取得したものであると認められるから、引用発明における「クライアント側」の「ユーザの計算機」は、本願発明の「前記ウェブサーバから前記情報を受信するように適応される第1のクライアントデバイス」に相当するといえる。 次に、引用発明における「クライアント側」の「ユーザの計算機」において、「ユーザ」が、「戻る」、「つぎ」という「音声コマンド」によって「入力対象のセレクタ」の「変更」を行ない、「検索ぺージ内の入力箇所」を移動させることが、本願発明の「前記第1のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示する」ことに相当する。 次に、引用発明の「音声データの音声特徴パラメータ」は、本願明細書第【0030】段落に「デジタル化したオーディオ信号または音声特徴などの音声データ」と記載されていることから、本願発明の「入力音声データ」に相当する。 次に、引用発明において、「ユーザ」が、「検索ぺージ内の入力箇所」に関連する「キーワードの一部」を「音声で入力」し、「入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ」ることと、本願発明の「前記フィールドの各々と関連付けられた入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信する」こととは、前記フィールドの各々と関連付けられた入力音声データを前記認識サーバに送信する点で一致する。 次に、本願明細書第【0047】段落には「本明細書で使用する場合、「文法」とは認識を行うための情報を含み、別の実施形態では、例えば特定のフィールドに入力されることが予想される入力に対応する情報を含む。)」と記載されているから、引用発明において、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」が本願発明の「フィールドの文法」に相当する。 次に、音声認識とは、「音声による情報をコンピュータ処理が可能なディジタルデータに変換する」(最新版エレクトロニクス用語事典、株式会社オーム社、平成9年12月20日、第1版第6刷、第77頁「音声認識装置」の項目)ことであるから、引用発明において、「リモートのハブ・ホスト」が、「音声認識サーバとして」の機能により、「リモートのハブ・ホスト」で生成された、「キーワードの断片の単語発話」を含む「音声入力の認識用文法」を使用し、何が認識されたかを表すデータを生成していることは明らかである。よって、引用発明において、「入力された音声データの音声特徴パラメータがクライアント・ホストからハブ・ホストの音声認識サーバに送られ」、「リモートのハブ・ホスト」が、「音声認識サーバとして」の機能により、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」を使用して音声認識を行ない、「WWWサーバ・ホストへフォーム入力データを送る」ことと、本願発明の「認識サーバ」が、「前記第1のクライアントデバイスから前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第1のクライアントデバイスおよび前記ウェブサーバの少なくとも1つに戻す」こととは、認識サーバが、前記第1のクライアントデバイスから前記入力音声データを受信し、フィールドの文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第1のクライアントデバイスおよび前記ウェブサーバの少なくとも1つに戻す点で一致する。 次に、引用発明の「ハブ・ホスト」は、音声認識サーバとして機能する他、「クライアント側で指定するWebぺージのHTMLファイルの取得および解析を行い」、「「搭乗日を入力してください」や「出発地を入力してください」というような、システムからの問合わせ・応答文を生成し、生成された問合わせ・応答文は、クライアント側に音声として送られ」ているが、該「システムからの問合わせ・応答文」が、音声合成により音声データに変換され、ネットワークを介してクライアント側に音声として送られていることは、前記「4.引用例」の摘記事項(ト)、(チ)より明らかである。 よって、引用発明の「リモートのハブ・ホスト」と本願の「認識サーバ」とは、プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第1のクライアントデバイスに音声データを送信する点で一致するといえる。 すると、本願発明と、引用発明とは、次の点で一致する。 <一致点> データを処理するサーバ/クライアントシステムであって、前記システムはネットワークを備え、前記ネットワークは、 リモートでアクセスすることのでき、1組のフィールドを具備する情報を有するウェブサーバと、 認識サーバと、 前記ウェブサーバから前記情報を受信するように適応される第1のクライアントデバイスであって、前記第1のクライアントデバイスのユーザがその後行う入力の対象とするフィールドを指示すると、前記フィールドの各々と関連付けられた入力音声データを前記認識サーバに送信するように適応された第1のクライアントデバイスとを備え、 前記認識サーバは、前記第1のクライアントデバイスからリモートに位置され、前記第1のクライアントデバイスから前記入力音声データを受信し、フィールドの文法を使用して前記入力音声データを処理し、何が認識されたかを表すデータを、前記入力音声データを提供する第1のクライアントデバイスおよび前記ウェブサーバの少なくとも1つに戻すように構成され、プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第1のクライアントデバイスに音声データを送信することを特徴とするシステム。 一方で、両者は次の相違点で相違する。 <相違点1> 本願発明では、「第1のクライアントデバイス」が、「入力音声データを記録するように構成され、かつ前記入力音声データと文法の指示を前記認識サーバに送信するように適応され」、「認識サーバ」が「前記入力音声データおよび前記フィールドの文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理」しているのに対し、引用発明では、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)が、「入力された音声データの音声特徴パラメータ」(入力音声データ)を「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からハブ・ホスト(認識サーバ)に送り、「ハブ・ホスト」(認識サーバ)が前記「入力された音声データの音声特徴パラメータ」(入力音声データ)を、「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」(フィールドの文法)を使用して処理しているものの、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)が「入力された音声データの音声特徴パラメータ」(入力音声データ)を記録しているか明らかではなく、また、「音声入力の認識用文法」(文法)は、ハブ・ホスト(認識サーバ)で生成されているため、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からハブ・ホスト(認識サーバ)にフィールドの文法の指示が送られていない点。 <相違点2> 本願発明では、「認識サーバ」が、「前記認識結果が前記第1のクライアントデバイスからの前記入力の認識がないことを指示するとき、前記ユーザに使用されるためのプロンプトを指示するデータを受信し、前記認識結果が前記第1のクライアントデバイスから前記入力の認識がないことを指示するとき、前記プロンプトを指示するデータを音声データに変換し、前記ネットワークを介して前記第1のクライアントデバイスに音声データを送信する」のに対し、引用発明では、「ハブ・ホスト」(認識サーバ)が、「システムからの問合わせ・応答文」を、音声合成により「音声」に変換し、ネットワークを介してクライアント側に音声として送っていることは明らかであるものの、引用発明には、「ハブ・ホスト」(認識サーバ)が、「音声認識サーバとして」の機能により音声認識を行った結果、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からの入力の認識がない場合についての言及が無いため、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からの入力の認識がない場合、前記ユーザに使用されるための「システムからの問合わせ・応答文」(プロンプト)を指示するデータを受信し、前記「システムからの問合わせ・応答文」(プロンプト)を指示するデータを音声データに変換し、前記ネットワークを介して前記第1のクライアントデバイスに音声データを送信しているか否か明らかでない点。 6.判断 <相違点1>について: 「文法」について、本願明細書第【0047】段落に「本明細書で使用する場合、「文法」とは認識を行うための情報を含み、別の実施形態では、例えば特定のフィールドに入力されることが予想される入力に対応する情報を含む。)」と記載されていることを踏まえれば、入力音声データを記録し、かつ前記入力音声データと文法の指示を音声認識サーバに送信し、音声認識サーバが前記入力音声データと文法の指示を受信し、前記指示された文法を使用して前記入力音声データを処理することは、本願の優先日前において周知技術である(例えば、特開平10-240493号公報(フロントページ、【解決手段】欄)、渕 武志、加藤恒昭、WWWブラウザの音声による制御、情報処理学会研究報告 97-SLP-16、第97巻、第52号、1997年5月26日、第37?42頁(「マイクからの入力があると、これを音声データとして記録する。そして、音声認識サーバとの通信を開始し、認識単語候補と音声データを送信する。音声認識サーバは認識単語候補の中から音声データに最も近い単語を算出し、この単語を音声入力プロセスに返す。」(第40頁第14?16行))。 したがって、かかる周知技術を引用発明に適用し、引用発明において、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)が、「入力された音声データの音声特徴パラメータ」(入力音声データ)を記録し、前記「入力された音声データの音声特徴パラメータ」(入力音声データ)と「音声入力の認識用文法」(文法)の指示を「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からハブ・ホスト(認識サーバ)に送り、「ハブ・ホスト」(認識サーバ)が前記「入力された音声データの音声特徴パラメータ」(入力音声データ)及び「検索ページの入力箇所」に関連する「キーワードの断片の単語発話」を含んだ「音声入力の認識用文法」(フィールド文法)の指示を受け、該「音声入力の認識用文法」(文法)の指示を使用して該「入力された音声データの音声特徴パラメータ」(入力音声データ)を処理するようにすることは、当業者が容易になし得たことである。 <相違点2>について: 電話の声でインターネットを検索 「音声ポータル」が登場、日経コンピュータ、2001年3月12日、第517号、p.28?30には、「図2●VoiceXMLの記述例。ニュース,天気,株価,レストランという4種類のサービスから一つを選択するシナリオである。最初に「ご利用になりたいサービスは何ですか」というガイダンスを読み上げる。利用者が「どんなサービスがあるの」などと聞き返した場合は「help」,言った言葉を認識できなかった場合は「nomatch」というタグで定義されているメッセージを読み上げる。VoiceXML1.0の仕様は,標準化団体「VoiceXMLフォーラム」が2000年3月に決定し,Web関連技術の標準化団体W3Cが同5月に承認した」(第29頁図2の説明)と記載され、第29頁図2の「VoiceXMLの記述例」中に「<nomatch>申しわけありません,聞き取れませんでした。もう一度,お願いします。</nomatch>」と記載されている。 さらに、「インタプリタでシナリオを実行 音声ポータル・サービスを実現するシステムの基本的な構成は,図3のようになる。中核となるのは,「VoiceXMLインタプリタ」と「音声応答用ミドルウエア」という2種類のソフトウエアである。音声応答用ミドルウエアは,利用者が発した音声を受け取り,音声認識ソフトでテキスト・データに変換してから,そのテキストをVoiceXMLインタプリタに渡す。VoiceXMLインタプリタは,テキストの内容に従って,VoiceXMLで記述されたWebコンテンツをコンテンツ提供会社のWebサーバーなどから読み込み,シナリオを実行する。得られた検索結果などは音声応答用ミドルウエアが受け取り,利用者に伝える。音声で読み上げる部分は,音声合成ソフトを使ってテキスト・データを音声データに変換する。」(第30頁左欄第11?31行)と記載され、第30頁図3の説明には、「●音声ポータル・システムの基本的な構成。音声ポータル・サイトは,音声応答システムだけをもつ。コンテンツ提供会社のWebサーバーやアプリケーション・サーバーには,インターネットを介してアクセスする。通常,音声応答サーバーにはWindows NTサーバーを使う。この上で,VoiceXMLインタプリタ,音声応答用ミドルウエアといったソフトウエアを動かす。音声認識ソフトは音声応答サーバーで実行することもできるが,音声ポータルでは同時に処理しなければならない音声の件数が増えるので,独立したサーバーにするのが一般的。VoiceXMLインタプリタは「VoiceXMLブラウザ」とも言う」と記載されている。 上記文献中の上記記載は、音声応答システムに関する一般的な記載であるから、本願の優先日前において、音声認識ソフトを実行するサーバーが、利用者の言った言葉を認識できなかった場合、マークアップ言語で記述されたページ中に定義されている「申し訳ありません,聞き取れませんでした。もう一度,お願いします。」といったメッセージのテキスト・データを音声応答用ミドルウエアが受け取り、音声合成ソフトを使って該テキスト・データを音声データに変換して利用者に伝えることは周知技術であったものと認められる。 したがって、かかる周知技術を引用発明に適用し、引用発明において、「ハブ・ホスト」(認識サーバ)が、「音声認識サーバとして」の機能により音声認識を行った結果、「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)からの入力の認識がない場合、「申し訳ありません,聞き取れませんでした。もう一度,お願いします。」といった、利用者に伝えるメッセージのテキスト・データ(ユーザに使用されるためのプロンプトを指示するデータ)を受け取り、該メッセージのテキスト・データ(プロンプトを指示するデータ)を、引用発明の「システムからの問合わせ・応答文」と同様に、音声合成により音声データに変換し、ネットワークを介して「クライアント側」の「ユーザの計算機」(第1のクライアントデバイス)に音声データとして送るようにすることは、当業者が容易になし得たことである。 また、本願発明の作用効果も、引用発明及び周知技術に基づいて当業者が容易に予測しうるものである。 7.むすび 以上のとおり、本願の請求項1に係る発明は、特許法第29条第2項の規定により特許を受けることができないものである。 したがって、その余の請求項について論及するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。 |
審理終結日 | 2010-12-14 |
結審通知日 | 2010-12-17 |
審決日 | 2011-01-06 |
出願番号 | 特願2002-132053(P2002-132053) |
審決分類 |
P
1
8・
121-
Z
(G06F)
|
最終処分 | 不成立 |
前審関与審査官 | 田中 慎太郎、山崎 慎一 |
特許庁審判長 |
水野 恵雄 |
特許庁審判官 |
丸山 高政 清水 稔 |
発明の名称 | ウェブ対応認識アーキテクチャを有するシステムおよびその方法 |
代理人 | 阿部 和夫 |
復代理人 | 濱中 淳宏 |
代理人 | 谷 義一 |
復代理人 | 合田 潔 |