【事件の表示】
　特願２００９−　３４３１１「オペレーティング・システムのアプリケーション・プログラム・インターフェース」拒絶査定不服審判事件〔平成２１年　６月２５日出願公開、特開２００９−１４０５２１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　
１．手続の経緯の概要
　本件に係る出願（以下「本願」と記す。）は
１９９８年３月２３日（以下「優先日」と記す。）のアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権主張を伴い、
１９９９年３月２２日を国際出願日とする国際出願による出願であるところの、特願２０００−５３８２９８号を原出願とする特許法第４４条第１項の規定による新たな特許出願として
平成２１年２月１７日付けで出願されたものであって、
平成２１年２月１８日付けで審査請求がなされ、
平成２４年３月８日付けで拒絶理由通知（平成２４年３月１２日発送）がなされ、
平成２４年６月１２日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２４年１２月１３日付けで最後の拒絶理由通知（平成２４年１２月１９日発送）がなされ、
平成２５年３月１９日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２５年４月１１日付けで上記平成２５年３月１９日付けの手続補正書による補正の却下の決定（平成２５年４月１６日謄本発送・送達）がなされるとともに、
同日付けで、上記平成２４年１２月１３日付けの拒絶理由通知書に記載した理由によって拒絶査定（平成２５年４月１６日謄本発送・送達）がなされたものである。
　
　本件審判請求は、上記拒絶査定を不服とし、
平成２５年８月１６日付けで請求されたものであり、
同日付けで手続補正書が提出され、
平成２５年９月４日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２５年１０月４日付けで当該報告に対する意見を求める旨の審尋（平成２５年１０月７日発送）がなされ、
平成２６年１月７日付けで回答書が提出され、
平成２６年３月１０日付けで審尋（平成２６年３月１１日発送）がなされ、
平成２６年５月１６日付けで回答書が提出されたものである。
　
　
２．拒絶理由・補正の内容・請求人の主張等の概要
　
（１）平成２４年６月１２日付け手続補正
　上記平成２４年６月１２日付けの手続補正書は特許請求の範囲を以下のとおりに補正するものである。
「　【請求項１】
　コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと；
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと；を具備
し
　
前記アプリケーション・プログラム・インターフェースは：
　
アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する、
　ことを特徴とするコンピュータ・システム。
　　【請求項２】
　請求項
１
　前記アプリケーション・プログラム・インターフェースは：
　前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを停止するようにさせ、及び一組の保留テキストを再生待ち行列からクリアするようにさせる第３のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを一時停止するようにさせる第４のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを再開するようにさせる第５のインターフェースと；を具備する、
　ことを特徴とするコンピュータ・システム。
　　【請求項３】
　請求項
１
　前記アプリケーション・プログラム・インターフェースは：
　前記現在のスピーチ状態を示すフラグを戻す第６のインターフェースと；
第１の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第１の話し速度でテキストを出力するようにさせる第７のインターフェースと；
　現在の話し速度を戻す第８のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき音声を示す第１の音声識別子を受け取る第９のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき前記現在の音声を示す第２の音声識別子を戻す第１０のインターフェースと；を含む、
　ことを特徴とするコンピュータ・システム。
　　【請求項４】
　コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、音声認識コンポーネントを有する前記オペレーティング・システムと；
前記オペレーティング・システムの制御下でランする、アプリケーション・プログラムと；
　前記音声認識コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと；を具備
し
　
前記アプリケーション・プログラム・インターフェースは：
　
可能化パラメータを前記アプリケーションから受け取る第１のインターフェースであって、前記可能化パラメータは、前記可能化パラメータが第１の値を有する時に、前記音声認識コンポーネントが、音声認識を可能にし、及び前記可能化パラメータが第２の値を有する時に、音声認識を不能にするようにさせるよう動作する第１のインターフェースと；
　
前記アプリケーションに第２のパラメータを戻す第２のインターフェースであって、前記第２のパラメータは、前記第２のパラメータが前記第１の値を有する時に音声認識が可能にされ、及び前記第２のパラメータが前記第２の値を有する時に音声認識が不能にされることを示すように動作する第２のインターフェースと；を具備する、
　ことを特徴とするコンピュータ・システム。
　　【請求項５】
　請求項
４
　前記アプリケーション・プログラム・インターフェースが：
　前記少なくとも一つの音声コマンド・メニューと関連するウィンドウのハンドル及び前記メニューがスピーチ認識状態と関連して活動状態であるべき時を示すフラグを受け取る第
３
　その各々が音声コマンドを説明するコマンド構造のリストを受け取り、及び前記少なくとも一つの音声コマンド・メニューに加えられた第１の音声コマンドと関連する数を戻す第
４
　前記少なくとも一つの音声コマンド・メニューを停止させる、第
５
　第１の音声コマンドに対応する数、除去する音声コマンドの数を受け取り、及び前記音声コマンドの数を、前記少なくとも一つの音声コマンド・メニューから除去する第
６
第６の
　ことを特徴とするコンピュータ・システム。
　　【請求項６】
　請求項
４
　前記アプリケーション・プログラム・インターフェースは：
　前記アプリケーションから、音声メニュー及びコマンド列を識別する第１の音声コマンド構造を受け取る第
７
第７の
　認識された音声コマンドの識別子、前記認識された音声コマンドと関連する音声メニューを識別する第２の音声コマンド構造、検査要求フラグ、動作データ列、前記認識された音声コマンドの少なくとも一つの認識されたフレーズを含むリストと、及び前記認識されたコマンドに対応するコマンド列とを受け取る第
８
　話されるフレーズが、前記音声認識コンポーネントによって検出される時に呼び出される第
９
前記音声認識コンポーネントによって検出される干渉の一種を受け取る第
１０
ことを特徴とするコンピュータ・システム。
　　【請求項７】
　請求項
４
　前記アプリケーション・プログラム・インターフェースは、
　アプリケーション名及び状態名を具備するメニュー識別子構造、言語識別子構造、及びモード・フラグをアプリケーションから受け取り、音声認識システムが、前記メニュー識別子構造によって識別される音声コマンド・メニューを生成するようにさせる第
１１
　前記メニュー識別子構造をアプリケーションから受け取り、及び前記音声認識システムが、前記メニュー識別子構造によって識別される前記音声コマンド・メニューを削除するようにさせる第
１２
　ことを特徴とするコンピュータ・システム。
　　【請求項８】
　コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、メモリ外モジュールを有する前記オペレーティング・システムと；
　前記メモリ外モジュールと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーション・プログラム・インターフェースは、前記オペレーティング・システムに、前記メモリ外モジュールが、低メモリ状態に応答するようにさせることを許可するように機能する前記アプリケーション・プログラム・インターフェースと；を具備
し
　
前記アプリケーション・プログラム・インターフェースは：
　
前記オペレーティング・システムから、前記メモリ外モジュールによって閉じられるべきウィンドウを識別するウィンドウ構造のリストを受け取る第１のインターフェースと；
　
前記オペレーティング・システムに、メモリが危機的に低いか決定するようにさせる前記メモリ外モジュールによって呼び出される第２のインターフェースと；を具備する、
　ことを特徴とするコンピュータ・システム。」
　
　
（２）原審拒絶理由
　上記平成２４年１２月１３日付けの拒絶理由通知書（以下「原審拒絶理由通知書」と記す。）によって通知された拒絶理由（以下「原審拒絶理由」と記す。）の内容は概略以下のとおりである。
『　　　　　　　　　　　　　　　理　由
　
１．この出願は、下記の点で特許法第３７条に規定する要件を満たしていない。
　
２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　
３．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
［理由１］
　請求項１−３に記載される発明（以下「特定発明」という。）と請求項４−７に記載される発明とに共通する課題は、段落【００１４】等に記載されているように、可聴スピーチを出力するコンポーネントにデータを供給するＡＰＩを提供することである。しかしながら、この課題は、本願出願前に解決されており（下記の引用文献２等参照）、本願出願時未解決の課題ではない。
　よって、請求項４−７に記載される発明は、特定発明に対し、特許法第３７条第１号に掲げる関係を有しない。
　また、特定発明と請求項４−７に記載される発明とに共通する発明特定事項のうち、解決しようとする課題に対応した事項である「前記プロセッサにおいて動作するオペレーティング・システムであって、スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと；前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと；を具備」することは、新規でない（下記の引用文献２等参照）。
　したがって、特定発明と請求項４−７に記載される発明との間に、解決しようとする課題に対応した新規な発明特定事項である主要部が、共通して存在しない。
　よって、請求項４−７に記載される発明は、特定発明に対し、同条第２号に掲げる関係を有しない。
　さらに、請求項４−７に記載される発明は、特定発明に対し、同条第３号、第４号、第５号に掲げるいずれの関係も有しない。
　
　また、請求項１−３に記載される発明（以下「特定発明」という。）と請求項８に記載される発明とに共通する課題は、ＡＰＩを提供することである。しかしながら、この課題は、本願出願前に解決されており（下記の引用文献２等参照）、本願出願時未解決の課題ではない。
　よって、請求項８に記載される発明は、特定発明に対し、特許法第３７条第１号に掲げる関係を有しない。
　また、特定発明と請求項８に記載される発明とに共通する発明特定事項のうち、解決しようとする課題に対応した事項である「アプリケーション・プログラム・インターフェースと；を具備」することは、新規でない（下記の引用文献２等参照）。
　したがって、特定発明と請求項８に記載される発明との間に、解決しようとする課題に対応した新規な発明特定事項である主要部が、共通して存在しない。
　よって、請求項８に記載される発明は、特定発明に対し、同条第２号に掲げる関係を有しない。
　さらに、請求項８に記載される発明は、特定発明に対し、同条第３号、第４号、第５号に掲げるいずれの関係も有しない。
　
　この出願は特許法第３７条の規定に違反しているので、請求項１−３以外の請求項に係る発明については特許法第３７条以外の要件についての審査を行っていない。
　
　なお、上記記載した理由と同様に、請求項４−７に係る発明と請求項８に係る発明が、特許法第３７条第１号乃至第５号に規定するいずれの関係も有しないことも明らかである。
　
［理由２］
（ａ）請求項１−３に係る発明が、明細書のどの部分に対応するのか、また、日本語として明細書のどの部分に記載されているのか不明である。
　したがって、本願請求項１−３に係る発明は、発明の詳細な説明中に記載も示唆もされていない。
（審査基準　第１部　第１章　明細書及び特許請求の範囲の記載要件　２．２．１．３　第３６条第６項第１号違反の類型の　（１）に該当する。）
　
　よって、請求項１−３に係る発明は、発明の詳細な説明に記載したものでない。
　
［理由３］
請求項：１
引用文献：１，２
備考：
　引用文献１には
「複数のアプリケーションから音声出力の対象となるアプリケーションを選択し、登録する手段と、
　起動中のアプリケーションの　アプリケーションのテキスト内容を共有領域に複写する手段と、
　アプリケーションに優先順位を付け、優先順位順に、複写されたテキストデータを読み出し、音声データに変換し出力するシステム。」
　の発明が記載されている。
　
　したがって、本願請求項１に係る発明と引用文献１に記載された発明では、本願発明が、スピーチ・ツゥ・テキスト・コンポーネントとアプリケーションとがＡＰＩを利用して通信するのに対して、引用文献１には「ＡＰＩ」と特定されていない点で相違する。
　上記相違点について検討する。
　引用文献２に示されるように、アプリケーションがＡＰＩを利用して、音声合成のモジュールと通信を行うことは周知であって、引用文献１に記載された発明に上記周知技術を適用して、本願発明の構成とすることは当業者が容易に想到しうることである。
　
請求項：２，３
引用文献：１，２
備考：
　音声合成のシステムにおいて、音声の再生機能として、、一時停止機能や、再開機能、速度変更、や、声の変更等の機能を設けることは周知である。
　
　拒絶の理由が新たに発見された場合には拒絶の理由が通知される。
　
　　　　　　　　　　　
　　　　　　　　　　　引　用　文　献　等　一　覧
１.特開平８−２６３２５９号公報
２.近藤　玲史，パソコン向け音声認識合成プラットフォームの構築とアプリケーションの試作，第５３回（平成８年後期）全国大会講演論文集（２）　平成８年９月４日〜６日，日本，社団法人情報処理学会，１９９６年　９月　６日，p.2-363〜2-364』
　
　
（３）平成２５年３月１９日付け手続補正
　上記平成２５年３月１９日日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとしたものである。
『　【請求項１】
　コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、
テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　
を
し
　前記アプリケーション・プログラム・インターフェースは：
　前記アプリケーション
・プログラム
・プログラム
し、
　
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
　
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す
ことを特徴とするコンピュータ・システム。
　　【請求項２】
　請求項１に記載のコンピュータ・システムにおいて、
　前記アプリケーション・プログラム・インターフェースは
、話し速度を特定する
　
　
（４）平成２５年３月１９日付け意見
　上記平成２５年３月１９日付けの意見書における意見の内容は、概略次のとおりである。
『【意見の内容】
１．平成２４年１２月１３日付け（発送日１２月１９日）拒絶理由通知（最後）において、以下の理由１〜３を指摘された。
・・・中略・・・
２．そこで、本出願人は、特許請求の範囲の記載を補正する手続補正書を作成し、本意見書とともに提出した。本出願人は、この手続補正により上記拒絶理由は全て解消されたものと思料する。
 
３．補正の内容、根拠、補正の目的の適合性
　本補正は、補正前の請求項２、４〜８を削除し、また、請求項１、３についてサポート要件違反（理由２）を解消すべく記載内容を整理し、請求項の番号を振り替えて、補正後の請求項１、２としたものであり、実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明、請求項の削除を目的とするものであるとともに、後述するように（「５．理由２（サポート要件違反）について」参照）、当初明細書等の記載の範囲内でなされたものである。
　補正後の請求項１、２に係る発明（以下、「本願発明１」、「本願発明２」という。特許請求の範囲に記載された発明を総称して「本願発明」という場合もある）を、構成要件に分説すると以下のとおりである（Ａ，Ｂ等の符号は分説の便宜上付したもの、下線は補正個所を示すために付したものである）。
（本願発明１）
Ａ．コンピュータ・システムであって：
Ｂ．互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
Ｃ．前記プロセッサにおいて動作するオペレーティング・システムであって、
テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース
Ｄ．前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　
を
し
Ｅ．前記アプリケーション・プログラム・インターフェースは：
Ｅ１．前記アプリケーション
・プログラム
・プログラム
し、
Ｅ２．
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
Ｅ３．
前記フラグは、
Ｅ３１．
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
Ｅ３２．
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
Ｅ３３．
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す
Ａ’．ことを特徴とするコンピュータ・システム。
　（本願発明２）
Ｆ．請求項１に記載のコンピュータ・システムにおいて、
Ｇ．前記アプリケーション・プログラム・インターフェースは
、話し速度を特定する
Ｆ’．ことを特徴とするコンピュータ・システム。
 
４．理由１（発明の単一性違反）について
　審査官殿は、概略，補正前の請求項１−３に係る発明と、請求項４−７に係る発明及び請求項８に係る発明とは、特許法第３７条各号に掲げる何れの関係も有していない旨指摘されている。
　これに対し、本補正により、補正前の請求項４〜８を削除した。
　これにより、理由１は解消されたものと思料する。
 
５．理由２（サポート要件違反）について
　審査官殿は、補正前の請求項１〜３に係る発明について、サポート要件違反を指摘されている。
　これに対し、補正前の請求項２を削除するとともに、請求項１及び３について、前記のような補正を行い、補正後の請求項１、２とした。
　補正の根拠は、概略以下のとおりである。
（１）補正後の請求項１：明細書の段落〔００７９〕（構成要件Ｃ）、〔表１２６〕、〔表１２７〕及び〔表１３０〕（構成要件Ｅ３１〜Ｅ３３）
（２）補正後の請求項２：〔表１８１〕（構成要件Ｇ）
　これにより、理由２も解消されたものと思料する。
 
６．理由３（進歩性欠如）について
６−１．理由３の概要
　審査官殿は、補正前の請求項１〜３に係る発明につき、引用文献１及び２を引用し、概略以下のような指摘をされている。
・・・中略・・・
６−２．本願発明の特徴
　本願発明１は、特に、構成要件Ｅ２の『特定されたテキストの優先順位を示すフラグを受け取るように動作』する点、当該フラグの指示内容に係る、構成要件Ｅ３１の『再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと』、構成要件Ｅ３２の『別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること』、構成要件Ｅ３３の『別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること』に特徴を有するものである。
 
６−３．各引用文献に記載された事項
　引用文献１には、要約欄に〔構成〕として以下のような記載がある。
『登録手段１により、マルチウインドウで起動されているアプリケーション６から音声出力の対象を選択し、共用領域７に登録する。状態監視部３は起動中のアプリケーションの実行順位等のシステム状態情報を判定部４に供給する。判定部４は状態監視部３と登録領域７に登録されたアプリケーションとを比較し、音声出力の条件に叶うアプリケーションを選んで要求制御部５に通知する。要求制御部５は当該アプリケーションに対して、ウインドウ表示中のテキスト内容を共用領域７に複写させる。音声変換出力手段８は音声データに変換して出力する。』
　引用文献２には、音声認識合成の機能を提供するプラットフォームとして、図１に、音声認識・合成エンジン及びAPIからなるプラットフォームが示されている。
 
６−４．本願発明１と引用文献１に記載された発明との対比・判断
　引用文献１には、上記本願発明１の特徴は記載も示唆もされていない。
　即ち、引用文献１には、審査官殿が説示されるような構成は記載されているとしても、上記特徴に相当する構成は一切開示されていない。
　また、引用文献２にも、同様に、上記特徴に相当する構成は一切開示されていない。
　以上のとおり、引用文献１及び２には、本願発明１の上記特徴が記載されていないのであるから、引用文献１及び２の記載内容を組み合わせたとしても、本願発明１の構成とすることはできない。
　そして、本願発明１は、上記特徴点を含む構成により、明細書記載の作用効果を奏するものである。
　したがって、本願発明１は、引用文献１及び２に記載された発明に基づいて当業者が容易に想到し得たものではなく、特許法第２９条第２項に該当しないものである。
 
６−５．本願発明２について
　本願発明２は、請求項１を引用するものであり、本願発明１の構成要件をすべて含み、更に他の構成要件を付加したものに相当するものであるから、本願発明１が、上記のとおり特許法第２９条第２項に該当しないものである以上、本願発明２も、特許法第２９条第２項に該当しないものである。
・・・後略・・・』
　
　
（５）原審補正却下理由
　上記平成２５年４月１１日付けの補正の却下の決定の理由は概略次の通りのものである。
『　　　　　　　　　　　　　　　理　由
　
　出願人は、補正前の請求項１の「前記アプリケーション・プログラム・インターフェース」を
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する」
　から
「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
　特定されたテキストの優先順位を示すフラグを受け取るように動作し、
　前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」
　と変更し、補正後の請求項１とする補正を行っている。
　
　本件補正は、補正前の請求項１の「アプリケーション・プログラム・インターフェース」が「第１のインターフェース」と「第２のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。
　
　また、出願人は本件補正が実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものである旨主張しているが、本件補正は、新規性・進歩性を主張することを目的として、発明特定事項を追加する補正であって、明りょうでない記載の釈明を目的とするものとは認められない。
　
　また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこも明らかである。
　
　したがって、この補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当しない。
　よって、この補正は同法第１７条の２第４項の規定に違反するものであるから、同法第５３条第１項の規定により上記結論のとおり決定する。』
　
　
（６）原審拒絶査定の理由
　原審の拒絶査定の理由は次のとおりのものである。
『この出願については、平成２４年１２月１３日付け拒絶理由通知書に記載した理由によって、拒絶をすべきものです。
　なお、意見書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
　また、手続補正は、本拒絶査定と同日付けで補正却下となった。』
　
　
（７）審判請求理由
　本件審判請求の趣旨は「原査定を取り消す、本願は特許をすべきものであるとの審決を求める」と言うものであり、その理由の概要は以下のとおりである。
「【請求の理由】 
 １．手続の経緯 
・・・中略・・・
 ３．審判請求と同時になされた手続補正について 
 本請求人は、後述するように、上記補正却下の決定に承服するものではないが、これを措き、本審判請求と同時に、平成２５年３月１９日付けで提出した手続補正書と同内容の手続補正書を提出し、平成２４年６月１２日付け手続補正書をベースに特許請求の範囲の記載を修正した。この補正は、（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものであり、当初明細書等の記載の範囲内でなされたものである。 
　
 ４．補正却下の決定について 
 ４−１．ご指摘の概要 
 　審査官殿は、補正却下の決定の理由において、概略以下のような指摘をされている。 
 『出願人は、補正前の請求項１の「前記アプリケーション・プログラム・インターフェース」を・・・　と変更し、補正後の請求項１とする補正を行っている。 
 　本件補正は、補正前の請求項１の「アプリケーション・プログラム・インターフェース」が「第１のインターフェース」と「第２のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。 
 　また、出願人は本件補正が実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものである旨主張しているが、本件補正は、新規性・進歩性を主張することを目的として、発明特定事項を追加する補正であって、明りょうでない記載の釈明を目的とするものとは認められない。 
 　また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこ（ママ）も明らかである。 
 　したがって、この補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当しない。』 
　
 ４−２．上記ご指摘の非妥当性 
 　本出願人が、上記補正却下の対象となった平成２５年３月１９日付け手続補正を提出したのは、平成２４年１２月１３日付け拒絶理由通知（最後）に対応するためのものであったところ、上記拒絶理由通知は、単一性要件違反（理由１）、サポート要件違反（理由２）、進歩性欠如（理由３）を指摘するものであった、 
 　そして、上記理由中、サポート要件違反（理由２）の指摘内容は、以下のとおりのものであった。 
・・・中略・・・
 　平成２５年３月１９日付け手続補正は、この指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものであることは明らかである（補正の根拠等については平成２５年３月１９日付け意見書に詳述してある）。 
 　審査官殿は、本件補正（平成２５年３月１９日付け手続補正）が、特許請求の範囲を拡張するものであるから、発明の限定的減縮を目的とするものでないことは明らかである旨指摘されているが、上記のように、本件補正は、実質的に明りょうでない記載の釈明を目的としたものであり、特許請求の範囲の限定的減縮には相当しないものであるとしても、それにより、補正の目的違反を問われるべきものではない。 
 　因みに、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成２４年１２月１３日付け拒絶理由通知（最後）のサポート要件違反（理由２）に問われることは必至であり、これを回避する補正を行った点を捉えて目的違反との指摘を行うことは、極めて形式的な判断であって、妥当性を欠くものであると言わざるを得ない。 
 　更に付言すれば、本補正後の特許請求の範囲に記載された発明が進歩性欠如の理由（理由３）に該当しないことを以って、本補正が、新規性・進歩性を主張することを目的として、発明特定事項を追加する補正であるなどとも指摘しているが、本補正の趣旨は上記のとおりであり、この点も同様に妥当性を欠く指摘と言わざるを得ない。 
　
 ５．補正後の特許請求の範囲に記載された発明について 
 　本請求人は、上述のように、本審判請求と同時に、平成２５年３月１９日付けの手続補正と同内容の手続補正を再度行った。 
 　そして、平成２５年３月１９日付け意見書において詳述したように、この手続補正は、平成２４年１２月１３日付け拒絶理由通知（最後）において指摘された単一性要件違反（理由１）、サポート要件違反（理由２）、進歩性欠如（理由３）を全て解消しているものである。 
 　 
 ６．むすび 
 　よって、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求める。 」
　
　
（８）平成２５年８月１６日付け手続補正
　上記平成２５年８月１６日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとするものである。
『　【請求項１】
　コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、
テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　
を
し
　前記アプリケーション・プログラム・インターフェースは：
　前記アプリケーション
・プログラム
・プログラム
し、
　
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す
ことを特徴とするコンピュータ・システム。
　　【請求項２】
　請求項１に記載のコンピュータ・システムにおいて、
　前記アプリケーション・プログラム・インターフェースは
、話し速度を特定する
　
　すなわち、上記平成２５年８月１６日付けの手続補正書は上記審判請求書記載のとおり、上記平成２５年３月１９日付け手続補正書と同内容の補正をしようとするものである。
　
　
（９）前置報告
　上記平成２５年１０月４日付けで意見を求める旨の審尋において援用された前置報告書における報告の概要は以下のとおりである。
『この審判請求に係る出願については、下記の通り報告します。
　
　　　　　　　　　　　　　　　　　記
　
　出願人は、補正前の請求項１の「前記アプリケーション・プログラム・インターフェース」を
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する」
　から
「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
　特定されたテキストの優先順位を示すフラグを受け取るように動作し、
　前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」
　と変更し、補正後の請求項１とする補正を行っている。
　
　本件補正は、補正前の請求項１の「アプリケーション・プログラム・インターフェース」が「第１のインターフェース」と「第２のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。
　
　また、出願人は本件補正が実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものであり、『本補正後の特許請求の範囲に記載された発明が進歩性欠如の理由（理由３）に該当しないことを以って、本補正が、新規性・進歩性を主張することを目的として、発明特定事項を追加する補正であるなどとも指摘しているが、本補正の趣旨は上記のとおりであり、この点も同様に妥当性を欠く指摘と言わざるを得ない。』と主張しているが、本件補正は、新規性・進歩性を主張することを目的として、補正前の「アプリケーション・プログラム・インターフェース」を異なる内容に変更しているものであることは明らかである。
　
　また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこも明らかである。
　
　したがって、この補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第１７条の２第４項の規定に違反するものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　そして、この出願は原査定の理由に示したとおり拒絶されるべきものである。』
　
　
（１０）平成２６年１月７日付け回答書
　上記平成２６年１月７日付けの回答書による回答の概要は以下のとおりである。
「【回答の内容】
１．平成２５年１０月４日付け（発送日；１０月７日）審尋において、＜前置報告の内容＞について、本請求人の意見を求められた。
　前置報告の内容は、概略以下のとおりである。
・・・中略・・・
２．本請求人は、上記前置報告の内容に承服できるものではない。以下、審査官殿のご指摘が妥当でないことを詳述する。
　
３． 本願発明について
　審判請求時の補正による請求項１に係る発明（以下、「本願発明１」という。全請求項に係る発明を総称して、「本願発明」ということもある）を、分説すると以下のとおりである。なお、Ａ，Ｂ等の符号は分説の便宜上付したもの、下線は審判請求時の補正個所を示すために付したものである。
Ａ．コンピュータ・システムであって：
Ｂ．互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
Ｃ．前記プロセッサにおいて動作するオペレーティング・システムであって、
テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース
Ｄ．前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　
を
し
Ｅ．前記アプリケーション・プログラム・インターフェースは：
Ｅ１．前記アプリケーション
・プログラム
・プログラム
し
Ｅ２．
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
Ｅ３．
前記フラグは、
Ｅ３１．
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
Ｅ３２．
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
Ｅ３３．
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す
Ａ’．ことを特徴とするコンピュータ・システム。
　
４．前置報告の非妥当性について
　前置報告の内容は、平成２５年４月１１日付け補正却下の決定と略同内容のものであり、その内容が妥当でないことは、審判請求書中においても詳述したところであるが、その要点を以下再述する。
　
４−１．手続の経緯
・・・中略・・・
４−２．平成２５年４月１１日付け補正却下の決定の非妥当性
　平成２５年８月１６日付け審判請求書中においても指摘したように、本請求人は、後述するように、平成２５年４月１１日付けの補正却下の決定に承服するものではないが、取敢えず、この点を措き、本審判請求と同時に、平成２５年３月１９日付けで提出した手続補正書と同内容の手続補正書を提出し、平成２４年６月１２日付け手続補正書をベースに特許請求の範囲の記載を修正した。
　そして、本出願人が、補正却下の対象となった平成２５年３月１９日付け手続補正を提出したのは、平成２４年１２月１３日付け拒絶理由通知（最後）に対応するためのものであったところ、上記拒絶理由通知は、単一性要件違反（理由１）、サポート要件違反（理由２）、進歩性欠如（理由３）を指摘するものであった、
　そして、上記理由中、サポート要件違反（理由２）の指摘内容は、以下のとおりのものであった。
『（ａ）請求項１−３に係る発明が、明細書のどの部分に対応するのか、また、日本語として明細書のどの部分に記載されているのか不明である。
　したがって、本願請求項１−３に係る発明は、発明の詳細な説明中に記載も示唆もされていない。
（審査基準　第１部　第１章　明細書及び特許請求の範囲の記載要件　２．２．１．３　第３６条第６項第１号違反の類型の　（１）に該当する。）
　よって、請求項１−３に係る発明は、発明の詳細な説明に記載したものでない。』
　平成２５年３月１９日付け手続補正は、この指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に（拒絶理由通知に係る拒絶の理由に示す事項についてした）明りょうでない記載の釈明を目的とするものであることは明らかである（補正の根拠等については平成２５年３月１９日付け意見書に詳述してある）。
　審査官殿は、平成２５年３月１９日付け手続補正が、特許請求の範囲を拡張するものであるから、発明の限定的減縮を目的とするものでないことは明らかである旨指摘されているが、上記のように、本件補正は、実質的に明りょうでない記載の釈明を目的としたものであり、特許請求の範囲の限定的減縮には相当しないものであるとしても、それにより、補正の目的違反を問われるべきものではない。
　因みに、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成２４年１２月１３日付け拒絶理由通知（最後）のサポート要件違反（理由２）に問われることは必至であり、これを回避する補正を行った点を捉えて目的違反との指摘を行うことは、極めて形式的な判断であって、妥当性を欠くものであると言わざるを得ない。
　
４−３．本前置報告の非妥当性について
　審査官殿は、上記本請求人の指摘に対し、『本件補正が発明の限定的減縮を目的とするものでないことは明らかである』等の主張を繰り返しているが、上述のように、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成２４年１２月１３日付け拒絶理由通知（最後）のサポート要件違反（理由２）に問われることは必至であり、審査官殿の指摘は、本願の補正の可能性を全て滅却するに等しい暴論というべきものであって、妥当なものではない。
　
５．むすび
　以上のとおりであるから、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求めるものである。」
　
　
（１１）平成２６年３月１０日付け審尋
　上記平成２６年３月１０日付けの審尋の内容は概略以下のとおりである。
『１．平成２５年８月１６日付けの手続補正書による手続補正後の特許請求の範囲に記載される発明を特定するための事項（以下「発明特定事項」と記す。）が、本願明細書、本願の願書に最初に添付した明細書、特許請求の範囲及び図面、本願の原出願の願書に最初に添付した明細書、特許請求の範囲及び図面（特許法第１８４条の１２第２項において、同法第１７条の２第３項中の「願書に最初に添付した明細書、特許請求の範囲又は図面」とあるのを、これに読み替える旨規定されるものであるところの、平成１２年９月２５日付けの国際出願日における明細書、請求の範囲、図面の翻訳文））（以下、これらを「明細書等」と総称する。）の何処に記載されているどの事項に相当するのか？　また、これら明細書等のどこのどの記載からどの様にして導き出される事項なのか？を詳細に説明されたし。
（平成２５年３月１９日付けの意見書においては、補正の根拠として、
「補正の根拠は、概略以下のとおりである。
（１）補正後の請求項１：明細書の段落〔００７９〕（構成要件Ｃ）、〔表１２６〕、〔表１２７〕及び〔表１３０〕（構成要件Ｅ３１〜Ｅ３３）
（２）補正後の請求項２：〔表１８１〕（構成要件Ｇ）」
としか記載されていないため、例えば
・「優先順位を示すフラグ」は明細書等の【表１２６】記載の「種類フラグ」「優先順位フラグ」の何れに相当するのか？双方に相当するのか？いずれにも相当しないのか？
・「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」とは、上記明細書等の記載のどの事項に相当するのか？どこのどの記載からどの様にして導き出される事項なのか？
・「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」とは、上記明細書等の記載のどの事項に相当するのか？どこのどの記載からどの様にして導き出される事項なのか？
・「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」とは、上記明細書等の記載のどの事項に相当するのか？どこのどの記載からどの様にして導き出される事項なのか？
等を明確に把握することができない。）
　
２．平成２４年６月１２日付けの手続補正書の特許請求の範囲の請求項１に記載の「アプリケーション識別子と、・・・（中略）・・・第１のインタフェース」「テキストを含むバッファと、・・・（中略）・・・第２のインタフェース」の本来の意味内容や上記明細書等のどの記載を表現しようとしたものなのか（「第１のインタフェース」は、本来は上記明細書等の【表１２４】〜【表１２６】に記載される「ＩＶｏｉｃｅＴｅｘｔ：：Ｒｅｇｉｓｔｅｒ」のＡＰＩを、同「第２のインタフェース」は本来は【表１２６】〜【表１２７】に記載される「ＩＶｏｉｃｅＴｅｘｔ：：Ｓｐｅａｋ」のＡＰＩを意味し、これらを表現しようとしたものなのではないのか？　そうでないならば、上記「第１のインタフェース」「第２のインタフェース」は上記明細書等のどこに記載されるＡＰＩを表現しようとしたものなのか？）を説明されたし。』
　
　
（１２）平成２６年５月１６日付け回答書
　上記平成２６年５月１６日付け回答書による回答の概要は以下のとおりである。
『【回答の内容】
１．平成２６年３月１０日付け（発送日；３月１１日）審尋において、回答書の提出を求められた。
　審尋の内容は概略以下のとおりである。
・・・中略・・・
２．審尋への対応
　上記各ご指摘点についての対応は以下のとおりである。
（ア）補正後の請求項１の補正の根拠について
（ア−１）補正後の請求項１
　上記審尋中で指摘を受けた補正後の請求項１を構成要件に分説すると、以下のとおりである。但し、Ａ，Ｂ等の符号は分説の便宜上付したものである。
Ａ．コンピュータ・システムであって：
Ｂ．互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
Ｃ．前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと；
Ｄ．前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　を具備し、
Ｅ．前記アプリケーション・プログラム・インターフェースは：
Ｅ１．前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
Ｅ２．特定されたテキストの優先順位を示すフラグを受け取るように動作し、
Ｅ３．前記フラグは、
Ｅ３１．再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
Ｅ３２．別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
Ｅ３３．別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す
Ａ’．ことを特徴とするコンピュータ・システム。
　
（ア−２）補正の裏付をなす明細書の記載（下線付加）
・段落〔００７９〕
『３．スピーチ関連ＡＰＩ
　前記アドオン技術モジュールは、アプリケーション使用のためにＡＰＩを露出するいくつかのスピーチ関連コンポーネントを含む。これらのコンポーネントは、
テキスト・ツゥ・スピーチ・コンポーネント
ＰＣからの出力は、テキストからスピーチに変換される
　
・表〔１２６〕
『パラメータ
　　pszSpeak
　[in]
話すためのテキスト
テキスト・ツゥ・スピーチ
　　dwFlags
　[in]前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類のフラグと
一つの優先順位フラグ
　・・・
　　VTXTSP_HIGH
　
現在話されているテキストの後だが、再生待ち行列にあるいかなる他のテキストよりも前に、できるだけ早く前記テキストを再生する
　　VTXTSP_NORMAL（注；VTXTSP_VERYHIGHの誤記である）
　もしあれば、
現在話されているテキストに割り込んで、迅速に前記テキストを再生する
割り込まれたテキストは、たいへん高い優先順位のテキストが終わってからすぐに、再生を再開する
　
・表〔１２７〕
『註
　他のテキストが再生されている時に、アプリケーションがSpeakを呼び出す場合、
前記特定されたテキストは、前記アプリケーションがdwFlagsにおけるより高い優先順位を特定しないかぎり、再生待ち行列の最後に加えられる
　
・表〔１３０〕
『註
　・・・
　前記VTXTSP_HIGH及びVTXTSP_VERYHIGH
　優先順位列が、適切な位置で待ち行列に挿入されることができるように、前記オブジェクトは、個別のバッファにおける各呼び出しから、データを取っておく。
　例えば、
VTXTSP_VERYHIGHの優先順位列は、高い又は通常の優先順位列に割り込むかもしれない。割り込まれた列は、たいへん高い優先順位列が終わった後に再開する
　
（ア−３）ご指摘事項への対応
　
（イ）補正後の請求項２の補正の根拠
（イ−１）補正後の請求項２
　上記審尋中で指摘を受けた補正後の請求項２は、以下のとおりのものである。
『請求項１に記載のコンピュータ・システムにおいて、
　前記アプリケーション・プログラム・インターフェースは、話し速度を特定することを特徴とするコンピュータ・システム。』
　
（イ−２）補正の裏付をなす明細書の記載
・表〔１８１〕
『VTSITEINFO
　音声装置、
テキスト・ツゥ・スピーチ・モード
に対する話す速度を特定
　
（イ−３）ご指摘事項への対応
・構成要件Ｃの「テキスト・ツゥ・スピーチ・コンポーネント」は、スピーチ関連APIとして段落〔００７９〕に明示されている。
・構成要件Ｅ２の「優先順位を示すフラグ」は、表〔１２６〕に記載された「優先順位フラグ」に相当するものである。
　構成要件Ｅ３１〜Ｅ３３は、「優先順位フラグ」の内容に応じた制御内容を規定するものであり、以下詳述する。
・構成要件Ｅ３１の「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」は、「優先順位フラグ」が「VTXTSP_VERYHIGH」の場合に該当するものである。この「VTXTSP_VERYHIGH」のケースは、〔表１２６〕、〔１３０〕の記載からも明らかなように、現在話されているテキストに割り込んで、「VTXTSP_VERYHIGH」フラグを付されたテキストを再生し、再生完了後に割り込まれたテキストの再生を再開する。
・構成要件Ｅ３２の「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」は、例えば、「優先順位フラグ」が「VTXTSP_HIGH」の場合に該当するものである。この「VTXTSP_VERYHIGH」のケースは、〔表１２６〕の記載からも明らかなように、「VTXTSP_VERYHIGH」フラグを付されたテキストが、再生待ち行列の先頭に加えられるものである。なお、明示はないものの、優先順位が中位のケースに関しては、優先順位が中位のテキストが、その優先順位に応じた再生待ち行列の位置に格納されることになる。
・構成要件Ｅ３３の「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」は、「優先順位フラグ」が「VTXTSP_NORMAL」の場合に該当するものである。この「VTXTSP_NORMAL」のケースは、〔表１２７〕の記載からも明らかなように、「VTXTSP_NORMAL」フラグを付されたテキストが、再生待ち行列の最後に加えられるものである。
　以上説明したところにより、補正の根拠は明らかなものと思料する。
　
（ウ）平成２４年６月１２日付け手続補正書による補正の根拠について
　平成２４年６月１２日付け手続補正書により補正された請求項１は、以下のとおりのものである。
・・・中略・・・
　「第１のインターフェース」及び「第２のインターフェース」に関する御指摘に対する見解は以下のとおりである。
・明細書には、「第１のインターフェース」及び「第２のインターフェース」という用語に関する明示はない。
・「第１のインターフェース」に関しては、「サイト上の音声テキストを使用するためのアプリケーションの登録」（〔表１２４〕）、「通知インターフェース」、「インターフェース識別子」、「アプリケーションが全ての通知を受け取る予定か否かを示すフラグ」、「音声や会話速度等のサイトに適用する設定を含むサイト情報構造」（〔表１２５〕）、「アプリケーションは、IVoiceTextインターフェースを呼び出すことができる前に、Registerを呼び出さなければならない」（〔表１２６〕）等の開示はあるものの、上記請求項１の「第１のインターフェース」に規定される要件の全てが必ずしも明細書の記載に相応するものではない。
・「第２のインターフェース」に関しては、「優先順位フラグ」、「テキスト・ツゥ・スピーチ制御タグ」、「テキストの再生」（〔表１２６〕）等の開示があり、上記請求項１の「第２のインターフェース」に規定される要件が概略開示されている。
　
３．むすび
　以上のとおりであるから、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求めるものである。』
　
　
　
第２．先行技術文献・引用発明
　
１．原審引用文献
　本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成２４年１２月１３日付けの拒絶理由通知書の理由３において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
　
＜引用文献１＞
　特開平８−２６３２５９号公報（平成８年１０月１１日出願公開）
　
　＜引用文献記載事項１−１＞
「【特許請求の範囲】
【請求項１】　
マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも１以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも１以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える
読み上げ装置
【請求項２】　前記判定部は登録されたアプリケーションの中から、アクティブウインドウに移行したアプリケーションに対して、音声出力が可能な状態か否かの判定を行なうことを特徴とする請求項１記載の読み上げ装置。
【請求項３】　
登録手段はアプリケーションの実行ファイル名を登録する
【請求項４】　
前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行う
　
　＜引用文献記載事項１−２＞
「【０００１】
【産業上の利用分野】本発明はアプリケーションがディスプレイに表示したテキストを音声合成して出力する情報処理装置に関し、
特にマルチウインドウシステムに対応した読み上げ装置
　
　＜引用文献記載事項１−３＞
「【００１０】本発明はこのような点にかんがみて、
操作規約を規約化することで操作の簡便化を図り、初心者ユーザが容易に利用できる音声出力機能を提供することを目的とし、また、音声出力機能を容易にアプリケーションに付与できる手段を提供することを目的とする
　
　＜引用文献記載事項１−４＞
「【００１９】図３は本発明の実施例構成ブロック図である。図において、１０はキーボードやマウス等の入力指示具を含む実行ファイル名登録部、２０は登録テーブル、３０はシステム状態監視部、４０は読み上げ判定部、５０はクリップ要求発行部、６０は複写部、６１はテキスト、７１はクリップボード、８１は音声出力対象抽出部、８２はテキストバッファ、８３は音声データ変換部、８４は音声バッファ、９１は音声出力制御部、９２は音声出力装置、
２００はウインドウシステム
　
　＜引用文献記載事項１−５＞
「　　　　　　　　　　　【図３】
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
　
　＜引用文献記載事項１−６＞
「　　　　　　　　　　　【図４】
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
　
　
＜引用文献２＞
　近藤玲史，「パソコン向け音声認識合成プラットフォームの構築とアプリケーションの試作」，情報処理学会　第５３回（平成８年後期）全国大会講演論文集（２）　　平成８年９月４日〜６日」，日本，社団法人情報処理学会，平成８年９月６日，ｐ．２−３６３〜２−３６４
　
　＜引用文献記載事項２−１＞
「２．　音声認識合成プラットフォームとエンジン
２．１　プラットフォーム
　
　本プラットフォームにおけるＡＰＩは、ＯＳの定義する標準的な呼び出し方法に従っており、プログラミング上の特別な習熟の負担が少ない。」（２−３６３頁左欄第１４行〜右欄第１行）
　
　＜引用文献記載事項２−２＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」（２−３６３頁左欄）
　
　＜引用文献記載事項２−３＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」（２−３６３頁右欄）
　
　＜引用文献記載事項２−４＞
「２．２　音声認識合成エンジン
　
　
　
　
　
　
　
　
　
　＜引用文献記載事項２−５＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」（２−３６４頁左欄）
　
　
２．参考文献
　本願の出願前かつ上記優先日よりも前に頒布された下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。（下線は当審付与。）
　
＜参考文献１＞
　特開平１−２６３７３４号公報（平成１年１０月２０日出願公開）
　
　＜参考文献記載事項１−１＞
「システム内のすべてのタスクにとって使用可能なすべてのセグメントに対して使用されるテーブル６を、大域記述テーブル（ＧＤＴ）と呼ぶ。ＩＢＭ社のＯＳ／２オペレーティング・システムのシステム・アーキテクチャ構造を示す第２図を参照すると、
アプリケーションはアプリケーション・プログラム・インターフェース（ＡＰＩ）１１を使って、オペレーティング・システムにアクセスする。
　
　＜参考文献記載事項１−２＞
「オペレーティング・システム・カーネル・コード１５及び共通サブシステム・サービス１３に対するＡＰＩのため必要とされるセグメントが、ＧＤＴに含まれている。
オペレーティング・システムを拡張可能に設計する１つの方法は、アプリケーション１０がそれら自体のサブシステム１４を書いて、それらのＡＰＩ１２をオペレーティング・システムの論理的拡張部分にすることができるようにすることである。
　
　＜参考文献記載事項１−３＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」（第１０頁）
　
　
＜参考文献２＞
　星光行,『インターラクティブ・デジタルＴＶ用ソフトウェア「ＤＡＶＩＤ」』，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，平成６年８月２日，第９４巻，第１９１号，Ｐ．１−７
　
　＜参考文献記載事項２−１＞
「ＯＳ−９の特徴は、その性能もさることながら、モジュラ構造という世界に先駆けて開発したそのユニークな構造にある。ＯＳを構成する要素を機能別にそれぞれ独立したモジュールという単位に分け、それらを自由に組み合わせて使用できるところにある。さらに、これらのモジュールは、すべてダイナミック・リンクになっていて、いつでも追加、削除ができる。したがって、サイズも小さく、
用途に応じてモジュールを追加することでＯＳの機能を拡張できる。
　
　
＜参考文献３＞
　中川雅博編,「月刊コンピュータ・ダイジェスト」，第２４巻，第３号，日本，株式会社ティ・エー・シー企画，平成１０年３月１０日，Ｐ．１５
　
　＜参考文献記載事項３−１＞
「【シリコンバレー８日＝町田敏生】米マイクロソフトは自動車向け車載用コンピューター市場に参入する。今春出荷予定の携帯端末用ＯＳ（基本ソフト）の最新版「ウィンドウズＣＥ２．０」を車載用にも適用、クラリオンなど日米のメーカーにライセンス供給を始める。
また従来版に音声認識や手書き入力の機能を追加し、小型携帯端末ＯＳとしても供給する。
　
　
＜参考文献４＞
　特開平８−４６９３５号公報（平成８年２月１６日出願公開）
　
　＜参考文献記載事項４−１＞
「【００１９】図２は、図１に示す処理ユニット４０により実行されるソフトウェア２００の構造を示す。
図２はオーディオ・ビデオ対話型処理マルチタスク・オペレーティングシステムを構成する主なソフトウェア・コンポーネントを示す。
【００２０】提案されたオーディオ・ビデオ対話型放送システムでは、例えば、異なる製造業者からの異なる命令セットを用いて、異なるデコーダはＣＰＵを使用することができる。このシステムでは、アプリケーション・プログラムは、プロセッサに無関係な中間コードである。各デコーダのソフトウェアは、アプリケーション中間コードを解釈するコンポーネント（ＩＮＴＥＲＰＲＥＴＥＲ：インタプリタ）を含む。インタプリタにより、放送されたアプリケーション・プログラムは、どのような形式のＣＰＵ４１０を含むデコーダ上でも実行することができる。
このインタープリタは、ＲＡＭ４１２からオーディオ・ビデオ対話型データコンポーネント命令を中間コードの形で読み出し、メモリを操作し、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ　ｐｒｏｇｒａｍ　ｉｎｔｅｒｆａｃｅ）を介して、他のソフトウェア・コンポーネントを介してハードウェアと対話する。
ＡＰＩはアプリケーション・プログラムにより発行され、デコーダ要素をアクセスするために、アプリケーション・プログラムにより使用することができる。
　
　＜参考文献記載事項４−２＞
「【００２５】さらに、システムローダは引き続きデータコンポーネント・パケットサービスをスキャンし、伝送されたディレクトリ・モジュールと、ＲＡＭ４１２内の現在のディレクトリ・モジュールとを比較する。伝送されたディレクトリ・モジュールがＲＡＭ４１２に格納されているディレクトリ・モジュールと異なる場合、データコンポーネント・パケットサービスが変更されたこと、例えば、視聴者がチャンネルを変えたときとか、対話型コマーシャルが放送されているときのようなことを示す。
この場合、メッセージが、イベントマネジャを介して、ＡＰＩを用いて、アプリケーション・プログラムに送られる。
　
　＜参考文献記載事項４−３＞
「【００３１】また、フロー・オペレーティング・システムはコールしたアプリケーション・プログラムに直ちに戻る。次いで、アプリケーション・プログラムは他の処理、例えば、他のモジュールのリクエストを発し、他の初期化等の処理を実行することができる。
リクエストされたモジュールへのアクセスが必要とされると、アプリケーション・プログラムは、ブロック３０４にて、カーネル内の待ち機能にＡＰＩコールを発する。この機能により、リクエストされたモジュールのロードが成功したことを示すメッセージが、そのアプリケーション・プログラムにより受信されるまで、アプリケーション・プログラムの実行は中断させられる。
　
　＜参考文献記載事項４−４＞
「　　　　　　　　　　　　【図２】
　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
　
　
＜参考文献５＞
　特開昭６４−５９５９８号公報（平成１年３月７日出願公開）
　
　＜参考文献記載事項５−１＞
「２．特許請求の範囲
　プラント等の異常状態に対応するメッセージ表示要求情報に従い、該当するメッセージを複数のメッセージの中から選択して表示出力するメッセージ出力方式において、
　
前記メッセージ表示要求情報は表示の優先度をそれぞれ有し、表示要求にかかるメッセージの優先度が現在表示中のメッセージの優先度よりも高い場合に表示要求にかかるメッセージを優先的に表示し、表示要求にかかるメッセージの優先度が現在表示中のメッセージの優先度に等しいかまたはこれよりも低い場合には表示要求にかかるメッセージを表示待ちメッセージとして保持すると共に、現在表示中のメッセージの優先度に応じて予め設定された最低表示時間内においては、このメッセージよりも高い優先度のメッセージのみを表示する
　
　＜参考文献記載事項５−２＞
「また、現在表示中のメッセージは、前記優先度に応じて予め設定された最低表示時間の表示が原則的に確保される。
この最低表示時間内に現在表示中のメッセージよりも優先度の高いメッセージにつき表示要求があった場合には、現在のメッセージの表示を中断して表示要求された優先度の高いメッセージが表示される。
　
　＜参考文献記載事項５−３＞
「まず、上記の例では最も優先度の高いメッセージＡの表示要求が最初に発生しているため、このメッセージＡは、先の第１表に従って優先度１に対応する最低表示時間ｔ１の間、表示され続け、この間、メッセージＢ〜Ｄの表示要求情報が優先度判定処理部１に順次送り込まれる。一方、現表示メッセージＡにかかる情報は現表示メッセージ情報テーブル２に格納され、メッセージＢ〜Ｄの表示要求情報は、各々の優先度がメッセージＡの優先度と比較されてすべての優先性が否定されたうえ、
メッセージＢ〜Ｄ内で優先度の高い順、また同一優先度であれば表示要求の早い順に待ち行列管理され、各々の最低表示時間が待ち行列管理部３により付加されたうえで待ち行列管理テーブル５に表示待ちメッセージ情報として格納される。
　
　＜参考文献記載事項５−４＞
「一方、表示要求にかかるメッセージの表示が不可能である場合には、最低表示時間テーブル４を参照してそのメッセージの優先度に応じた最低表示時間を取り出し（同Ｓ１１）、これを付加した情報を表示待ちメッセージ情報として待ち行列管理テーブル５に組み込む（同Ｓ１２）。
なお、ステップＳ１２において、同一優先度の表示待ちメッセージ情報が既にある場合には、今回の表示待ちメッセージ情報が最後尾に組み込まれる。
　
　
＜参考文献６＞
　実願昭６３−１６３２７５号（実開平２−８３６００号）のマイクロフィルム（平成２年６月２８日発行）
　
　＜参考文献記載事項６−１＞
「２．実用新案登録請求の範囲
（１）制御ステーション側から与えられた音声出力要求に従って外部へ音声メッセージを出力する音声出力駆動装置において、
前記音声出力要求より音声情報及びそのレベル情報を音節定義ファイルから読み出してこのレベル毎に設定されている記憶領域に格納する格納手段と、新たに与えられた音声出力要求レベルが現在出力中の音声メッセージに設定されているレベルより高い場合は現在出力中の音声メッセージの出力を中断して新たに与えられた音声出力要求に対応する音声メッセージを出力指定する出力指定部とを有する
　
　＜参考文献記載事項６−２＞
「読み出し部４２１はこのレベル情報を参照してこのレベル毎に設定されている記憶領域ｍｉ（ｉ＝０，１，２，３のいずれか）にこの音声情報を格納する。
この記憶領域はＱｕｅと呼ばれ、ＦＩＦＯによって構成される。
　
　
３．引用発明の認定
（１）引用文献１は上記引用文献記載事項１−３記載のとおり「操作規約を規約化することで操作の簡便化を図り、初心者ユーザが容易に利用できる音声出力機能を提供することを目的とし、また、音声出力機能を容易にアプリケーションに付与できる手段を提供することを目的とする」「読み上げ装置」に関する発明を説明する文献であるところ上記引用文献記載事項１−１の【請求項１】より、該「読み上げ装置」として
「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも１以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも１以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える読み上げ装置」
が記載されていると言える。
　
（２）同じく上記引用文献記載事項１−１の【請求項３】等より、引用文献１には、
「前記登録手段はアプリケーションの実行ファイル名を登録するもの」
であることも記載されていると言える。
　
（３）同じく上記引用文献記載事項１−１の【請求項４】等より、引用文献１には、
「前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行うもの」
であることも記載されていると言える。
　
（４）さらに、上記引用文献記載事項１−４、１−５等から、
「前記登録手段、状態監視部、判定部、要求制御部、音声変換出力手段はウインドウシステム上で動作するもの」
であると言える。
　
（５）よって、引用文献１には、下記引用発明が記載されていると認められる。
　
＜引用発明＞
「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも１以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも１以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える読み上げ装置であって、
　前記登録手段はアプリケーションの実行ファイル名を登録するものであり、
　前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行うものであり、
　前記登録手段、状態監視部、判定部、要求制御部、音声変換出力手段はウインドウシステム上で動作するものである
読み上げ装置。」
　
　
　
第３．平成２５年８月１６日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成２５年８月１６日付けの手続補正を却下する。
　
　
［理由］
１．本件補正の内容
　平成２５年８月１６日付けの手続補正（以下「本件補正」と記す。）は、特許請求の範囲について、上記第１．（１）の平成２４年６月１２日付けの手続補正書に記載の特許請求の範囲から、上記第１．（８）の平成２５年８月１６日付けの手続補正書記載の特許請求の範囲に補正しようとするものである。
　
　
２．新規事項追加禁止要件
　本件補正について検討するに、補正後の請求項１に記載される
「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」
との技術的事項は、本願の願書に最初に添付した明細書、特許請求の範囲又は図面には記載されておらず、また当初明細書等の記載からみて自明な事項でもない。
　なお、請求人は、平成２５年３月１９日付け意見書や平成２６年５月１６日付け回答書において、平成２５年３月１９日付け手続補正の根拠として【表１２６】、【表１２７】及び【表１３０】を挙げている。そこで当該表の記載を検討するに、請求人が平成２６年５月１６日付け回答書の【回答の内容】２．（イ−３）で説明するとおり、「優先順位を示すフラグ」は、【表１２６】に記載された「優先順位フラグ」に相当するものであると認められる。しかしながら、【表１２７】及び【表１３０】の記載から「テキスト」が「再生待ち行列の最後に加えられる」ことや「適当な位置で待ち行列に挿入されること」などに「優先順位」が関与していることは認められるものの、【表１２６】の記載によれば、現在話されているテキストに割り込んで再生をするか、現在話されているテキストの後に再生するかを決めるのは、「優先順位フラグ」ではなく「種類フラグ」である。
　すなわち、「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」と、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」と、「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」の「何れか１つを表す」「優先順位を示すフラグ」は【表１２６】、【表１２７】及び【表１３０】のどこにも記載されていない。
　また、当初明細書等の他の箇所を参酌しても、このような３つの再生態様を示す「優先順位を示すフラグ」を直接的にも間接的にも示唆する記載は見あたらない。
　すなわち、当初明細書等のすべての記載を総合しても、上記の技術的事項を導き出し得るものではなく、本件補正は、当初明細書等の記載の範囲内においてするものではない。
　
　したがって、本件補正は、特許法第１７条の２第３項の規定に違反する。
　
　
３．目的要件
　本件補正は、上記第１．１．のとおり本件審判の請求と同時にする補正であり、上記第１．（８）のとおり特許請求の範囲についてする補正をしようとするものであるから、以下に、本件補正の目的について検討する。
　
３−１．補正事項の分析
　
（１）本件の請求項１に係る補正は、
　本件補正前の請求項１の「前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと；」との記載を削除し、
本件補正前の請求項１の「スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと；」との記載を「テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有する」に変更するとともに、本件補正後の請求項１における「前記アプリケーション・プログラム・インターフェースは：」との記載の後に「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、」との記載を追加する補正をしようとするものであり、これは次の補正事項に分けてとらえることができる。
　
＜補正事項１＞
　本件補正前の請求項１の「スピーチ・ツゥ・テキスト・コンポーネント」を、「テキスト・ツゥ・スピーチ・コンポーネント」に変更する補正。
　
＜補正事項２＞
　本件補正前の請求項１の「前記アプリケーション」を、「前記アプリケーション・プログラム」に変更する補正。
　
＜補正事項３＞
　本件補正前の請求項１における「オペレーティング・システム」が「有する」ものであった「スピーチ・ツゥ・テキスト・コンポーネント」を、「オペレーティング・システム」が「有する」ものから削除する補正。
　
＜補正事項４＞
　本件補正前の請求項１においては単に「コンピュータ・システム」が「具備」するものであった「前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェース」との記載箇所を変更し、「テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース」を「オペレーティング・システム」が「有する」ものとし、「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信」するものである旨を「前記アプリケーション・プログラム・インターフェースは：」との記載の後に移動させる補正。
　
（２）本件の請求項１に係る補正は、さらに、
本件補正前の請求項１における
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する、」
との記載を
「特定されたテキストの優先順位を示すフラグを受け取るように動作し、
　前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」
との記載に変更する補正をしようとするものであり、これは次の補正事項に分けてとらえることができる。
　
＜補正事項５＞
　本件補正前の請求項１におけるアプリケーション・プログラム・インターフェースが「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェース」を具備するものである旨の記載を削除するとともに、本件補正前の請求項１における「第２のインターフェース」に関する限定を「アプリケーション・プログラム・インターフェース」に関する限定に変更する補正。
　
＜補正事項６＞
　本件補正前の請求項１における「第２のインターフェース」が「受け取」るものから「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」を削除する補正。
　
＜補正事項７＞
　本件補正前の請求項１における「前記テキストの種類を示す優先順位フラグ」「を受け取」る旨の記載を「特定されたテキストの優先順位を示すフラグを受け取るように動作し」との記載に変更する補正。
　
＜補正事項８＞
　本件補正前の請求項１における「前記テキストを含むバッファを音声出力に変換するようにさせる」旨の記載を削除するとともに、前記「フラグ」に関し、
「前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」との限定を追加する補正。
　
　
（３）また、本件補正後の請求項２に係る補正は、次の補正事項よりなるものと捉えることができる。
　
＜補正事項９＞
　本件補正前の請求項２、請求項４〜請求項８を削除し、請求項３を請求項２に変更する補正。
　
＜補正事項１０＞
　本件補正前の請求項３におけるアプリケーション・プログラム・インターフェースが、
「前記現在のスピーチ状態を示すフラグを戻す第６のインターフェースと；」
「現在の話し速度を戻す第８のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき音声を示す第１の音声識別子を受け取る第９のインターフェースと；
　前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき前記現在の音声を示す第２の音声識別子を戻す第１０のインターフェースと；」
を含むものである旨の記載を削除する補正。
　
＜補正事項１１＞
　本件補正前の請求項３におけるアプリケーション・プログラム・インターフェースが
「第１の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第１の話し速度でテキストを出力するようにさせる第７のインターフェース」
を含むものである旨の記載を
本件補正後の請求項２における
「前記アプリケーション・プログラム・インターフェースは、話し速度を特定する」
との記載に変更する補正。
　
　
３−２．上記各補正事項の目的について、以下に検討する。
　
（１）補正事項１について
　本件補正前の請求項１における「スピーチ・ツゥ・テキスト・コンポーネント」との記載は、当該記載箇所以外の本件補正前の請求項１の記載などから見て、本来は「テキスト・ツゥ・スピーチ・コンポーネント」と記載すべきものの誤記であることは明らかである。
　したがって、上記補正事項１は誤記の訂正を目的とするものである。
　
（２）補正事項２について
　本件補正前の請求項１における「前記アプリケーション」との記載は、当該記載箇所以外の本件補正前の請求項１の記載などから見て、本来は「前記アプリケーション・プログラム」と記載すべきものの誤記であることは明らかである。
　したがって、上記補正事項２は誤記の訂正を目的とするものである。
　
（３）補正事項３について
ア．補正事項３が請求項の削除を目的とするものでないことは明らかである。
　
イ．本件補正前の請求項１においては、「オペレーティング・システム」は「テキスト・ツゥ・スピーチ・コンポーネント」「を有する」ものに限定されたものであったところ、上記補正事項３によって、本件補正後の請求項１における「オペレーティング・システム」は、必ずしも「テキスト・ツゥ・スピーチ・コンポーネント」を有するものでは無くなった。
　したがって、上記補正事項３は明らかに特許請求の範囲を拡張するものであり、特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項（以下「発明特定事項」とも記す。）を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）（以下、単に「限定的減縮」と記す。）を目的とするものではない。
　
ウ．また、「オペレーティング・システム」が「コンポーネント」「を有する」旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項１の「コンポーネントを有する」との記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
　したがって、上記補正事項３は誤記の訂正を目的とするものでもない。
　
エ．また、「オペレーティング・システム」が「コンポーネント」「を有する」ことは、何ら不明瞭な記載ではなく、また、本願の発明の詳細な説明にも裏付けられている事項であることは明らかである。
　したがって、上記補正事項３は明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）（以下、単に「不明瞭な記載の釈明」と記す。）を目的とするものではない。
　
オ．よって、上記補正事項３の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。
　
（４）補正事項４について
　上記補正事項４は、本件補正前には「アプリケーション・プログラム・インターフェース」は単に「コンピュータ・システム」が「具備」しているものであったものを、本件補正後には「オペレーティング・システム」がアプリケーション・プログラム・インターフェースを有する」ものとするものであるから「アプリケーション・プログラム・インターフェース」あるいは「オペレーティング・システム」を概念的に下位のものに限定する補正であり、これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
　したがって、上記補正事項４の目的は、限定的減縮と解することができる。
　
（５）補正事項５について
ア．補正事項５が請求項の削除を目的とするものでないことは明らかである。
　
イ．本件補正前の請求項１においては、「アプリケーション・プログラム・インターフェース」は「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェース」を具備するものに限定されたものであったところ、上記補正事項５によって、本件補正後の請求項１における「オペレーティング・システム」は、必ずしも該「第１のインターフェース」を有するものでは無くなった。
　したがって、上記補正事項５は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。
　
ウ．また、「アプリケーション・プログラム・インターフェース」がこのような「第１のインターフェース」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項１の「アプリケーション・プログラム・インターフェース」がこのような「第１のインターフェース」を含む旨の記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
　したがって、上記補正事項５は誤記の訂正を目的とするものでもない。
　
エ．また、発明の詳細な説明を参酌すれば該「第１のインターフェース」とは本来は【表１２４】〜【表１２６】に記載される「ＩＶｏｉｃｅＴｅｘｔ：：Ｒｅｇｉｓｔｅｒ」のＡＰＩを意味するものであったことは明らかであり、「アプリケーション・プログラム・インターフェース」がこのような「第１のインターフェース」を含む旨の発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
　したがって、上記補正事項５は不明瞭な記載の釈明を目的とするものではない。
　
オ．よって、上記補正事項５の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。
　
（６）補正事項６について
ア．補正事項６が請求項の削除を目的とするものでないことは明らかである。
　
イ．本件補正前の請求項１においては、「第２のインターフェース」は「優先順位フラグ」だけでなく「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取るものに限定されていたところ、上記補正事項６によって、本件補正後の請求項１における「アプリケーション・プログラム・インターフェース」は、必ずしも「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取るものでは無くなった。
　したがって、上記補正事項６は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。
　
ウ．また、「第２のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載自体は、文法的あるいは技術的に格別不適切なものではなく、本件補正前の請求項１の「第２のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
　したがって、上記補正事項６は誤記の訂正を目的とするものでもない。
　
エ．また、「バッファ」自体を受け取る旨の表現は発明の詳細な説明との対応関係に関して不整合はあるものの、発明の詳細な説明を参酌すればこの表現が本来は「アプリケーション・プログラム・インターフェース」が「バッファ」のアドレスを受け取ることに対応する記載であることは明らかであり、このような「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
　したがって、上記補正事項６は不明瞭な記載の釈明を目的とするものではない。
　
オ．よって、上記補正事項６の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。
　
（７）補正事項７について
ア．本件の発明の詳細な説明の【表１２６】の「ｄｗＦｌａｇｓ」の説明における「前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類フラグと１つの優先順位フラグとの組合わせである。」との記載等からみて、「優先順位フラグ」は「テキストの種類を示す」フラグではなく、「優先順位」を示すフラグであることは明らかである。
　
イ．これに対し、本件補正前の請求項１においては「第２のインターフェース」が受け取る「優先順位フラグ」は「テキストの種類を示す」ものであるから、本件補正前の請求項１に係る発明は発明の詳細な説明に記載されているものではなく、このことは原審拒絶理由の２．に該当する不明瞭な記載と言えるものである。
　
ウ．そして、補正事項７は該不明瞭な記載をあらため、本件補正後の請求項１における「アプリケーション・プログラム・インターフェース」が受け取る「フラグ」を「特定されたテキストの優先順位を示す」ものと言う、本来の意味を明らかにする補正であると言える。
　
エ．したがって、上記補正事項７の目的は、不明瞭な記載の釈明と解することができる。
　
（８）補正事項８について
　上記補正事項８によって、本件補正前の請求項１に係る発明の発明特定事項であった前記「フラグ」を「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」フラグと言う概念的に下位のものに限定する補正であり、これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
　したがって、上記補正事項８の目的は、限定的減縮に該当する。
　
（９）補正事項９について
　上記補正事項９の目的は、請求項の削除に該当する。
　
（１０）補正事項１０について
ア．補正事項１０が請求項の削除を目的とするものでないことは明らかである。
　
イ．補正事項１０は補正前の請求項３に記載されていた発明特定事項である「第６のインターフェース」「第８のインターフェース」「第９のインターフェース」「第１０のインターフェース」を削除するものであるから限定的減縮にも該当しない。
　
ウ．「アプリケーション・プログラム・インターフェース」がこれら「第６のインターフェース」「第８のインターフェース」「第９のインターフェース」「第１０のインターフェース」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項３の該記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
　したがって、上記補正事項１０は誤記の訂正を目的とするものでもない。
　
エ．また、「アプリケーション・プログラム・インターフェース」がこれら「第６のインターフェース」「第８のインターフェース」「第９のインターフェース」「第１０のインターフェース」を含む旨の発明特定事項に格別不明瞭な点は見当たらず、また、該発明の詳細な説明にも裏付けられていることであるから、当該発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
　したがって、上記補正事項１０は不明瞭な記載の釈明を目的とするものではない。
　
オ．よって、上補正事項１０の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。
　
（１１）補正事項１１について
ア．補正事項１１が請求項の削除を目的とするものでないことは明らかである。
　
イ．本件補正前の請求項３においては「第７のインターフェース」が「第１の話し速度を受け取り」、「前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第１の話し速度でテキストを出力する」ものであったのに対し、上記補正事項１１によって、本件補正後の請求項２においては必ずしも「第７のインターフェース」が「話し速度」を含むものではなく、しかも「アプリケーション・プログラム・インターフェース」は「話し速度」を「特定」するものの「話し速度でテキストを出力する」ものではなくなったのであるから、上記補正事項１１は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。
　
ウ．本件補正前の請求項３における「第７のインターフェース」が「第１の話し速度を受け取り」、「前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第１の話し速度でテキストを出力する」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項３の該記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
　したがって、上記補正事項１１は誤記の訂正を目的とするものでもない。
　
エ．また、「アプリケーション・プログラム・インターフェース」が「第１の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第１の話し速度でテキストを出力するようにさせる第７のインターフェース」を含む旨の発明特定事項に格別不明瞭な点は見当たらず、また、該発明の詳細な説明にも裏付けられていることであるから、上記補正事項１１は不明瞭な記載の釈明を目的とするものではない。
　
オ．よって、上記補正事項１１の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。
　
（１２）請求人の主張について
　なお、上記補正事項５、６等に関連して、審判請求書や平成２６年１月７日付けの回答書において、平成２５年３月１９日付け手続補正は、原審拒絶理由通知書で指摘されたサポート要件違反の指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に明りょうでない記載の釈明を目的とするものである旨の主張がなされている。
　しかしながら、「明瞭でない記載の釈明」とは、明細書、特許請求の範囲又は図面中のそれ自体意味の不明瞭な記載、又は、明細書、特許請求の範囲又は図面中の他の記載との関係で不合理を生じているために不明瞭となっている記載等、明細書、特許請求の範囲又は図面に生じている記載上の不備を訂正し、その本来の意を明らかにすることをいうのであって、本件補正の如き発明特定事項の削除によって実質的に請求の範囲の拡張や変更を行う補正までもが、「その本来の意を明らかにすること」を目的とした補正であると認めることは到底できない。
　また、特許法第１７条の２第４項の規定の趣旨は、既に行われた審査の結果を有効に活用できる範囲内のものとすることにあるのであるから、当該規定における「明りょうでない記載の釈明」は、審査・審理の対象を変更するものであってはならないのであって、単に記載要件に関する拒絶理由を回避することを目的とした補正を全て「明りょうでない記載の釈明」であると認めることは、当該規定の趣旨に反する。
　よって、上記請求人の主張は到底認め得るものではない。
　
（１３）まとめ
　以上のとおり、上記補正事項９の目的は請求項の削除、上記補正事項４、８の目的は限定的減縮、上記補正事項１、２の目的は誤記の訂正、上記補正事項７の目的は不明瞭な記載の釈明であるものの、上記補正事項３、５、６、１０、１１の目的は請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しないものである。
　
　
３−３．小結
　以上のとおりであるから、本件補正は、特許法第１７条の２第４項第１号の請求項の削除、同条同項第２号の特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）、同条同項第３項の誤記の訂正、同条同項第４項の明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）を目的とするものに限られるものではない。
　
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反する。
　
　
４．独立特許要件
　
　本件補正は、限定的減縮を目的とする上記補正事項４、８を含むものである。そこで、本件補正後の請求項１に記載されている事項により特定される発明（以下、「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか否かについて、以下に検討する。
　
　
４−１．特許法第３６条（記載要件）について
　
（１）上記２．で述べたとおり、「前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
　別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
　別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表すこと」は当初明細書等のすべての記載を総合しても、導き出し得るものではない。
　そして、本願の発明の詳細な説明及び図面に対しては出願の後に補正はなされていない。
　してみると、本件補正後の請求項１〜２に係る発明は、本件補正後の発明の詳細な説明に記載されていないものである。
　また、このため、本件補正後の発明の詳細な説明は、本件補正後の請求項１〜２に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものであるとも言える。
　
（２）本件補正後の請求項１においては「フラグ」は、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」と「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」の「何れか１つを表す」旨の発明特定事項の記載があるところ、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」は「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」に対して、概念的に上位の事項を意味しており、「フラグ」がこれら上位と下位の「何れか１つを表す」とは、如何なる対応付けを意味するのかが不明で（前者では「フラグ」だけでは「再生待ち行列」への挿入位置は決まらず他の要因で挿入位置が決まり、後者では「フラグ」だけで挿入位置が「再生待ち行列の最後」になるということなのか？　前者では挿入位置が「再生待ち行列の最後」以外のところに、後者では挿入位置が「再生待ち行列の最後」に決められているということなのか？　等々、様々な解釈が可能である。）、しかも、上記（１）記載のとおり発明の詳細な説明にも対応する記載が見当たらないため、該発明特定事項の意味は発明の詳細な説明を参酌しても明確に把握し得ないものである。
　してみると、本件補正後の請求項１〜２に係る発明は、明確でない。
　また、このため、本件補正後の発明の詳細な説明は、本件補正後の請求項１〜２に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものであるとも言える。
　
（３）よって、本件補正後の発明の詳細な説明及び特許請求の範囲の記載は、特許法第３６条第４項及び第６項第１号および第２項に規定する要件を満たしておらず、本件補正後の請求項１〜２に係る発明は、特許出願の際独立して特許を受けることができないものである。
　
　
４−２．特許法第２９条第２項（進歩性）について
　
４−２−１．本件補正発明
　本件補正発明は、上記第１．２．（８）において【請求項１】として記載したとおりのものである。
　
４−２−２．先行技術文献・引用発明
　上記第２．１．で示したとおり、本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成２４年１２月１３日付けの拒絶理由通知書の理由３において引用された、上記引用文献にはそれぞれ上記引用文献記載事項が記載されており、上記第２．２．で示したとおり、本願の出願前かつ上記優先日よりも前に頒布された上記参考文献にはそれぞれ上記参考文献記載事項が記載されている。
　そして、上記引用文献１には上記第２．３．で認定したとおりの引用発明が記載されているといえる。
　
　
４−２−３．対比
　以下、本件補正発明と引用発明とを比較する。
　
（１）引用発明は、「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも１以上のアプリケーションによる実行画面を有するシステム」である「読み上げ装置」であるから、本件補正発明と同様に「コンピュータ・システム」とも言えるものであり、また、本件補正発明と同様に「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは明らかである。
　
（２）引用発明における「ウインドウシステム」は本件補正発明における「オペレーティング・システム」に対応付けられるものであるところ、両者は「前記プロセッサにおいて動作するオペレーティング・システム」と言えるものであるから、引用発明と本件補正発明とは
「前記プロセッサにおいて動作するオペレーティング・システム」
を具備する点で共通する。
　
（３）引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」は本件補正発明における「テキスト・ツゥ・スピーチ・コンポーネント」に相当するものであるところ、これらと「アプリケーション」との間のインタフェースを行う手段があることは自明であり、該手段は本件補正発明における「アプリケーション・プログラム・インターフェース」に対応付けることができ、両者は「テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」と言えるものである。
　したがって、引用発明と本件補正発明とは「テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」
を具備する点で共通する。
　
（４）引用発明における「マルチウインドウ上で走行」する「アプリケーション」は、本件補正発明における「アプリケーション・プログラム」に対応付けられるものであるところ、前者の「マルチウインドウ」が「ウインドウシステム」によって実現されるものであることは明らかであるから、前者も「前記オペレーティング・システムの制御下でランする」「プログラム」であると言える。
　したがって、引用発明と本件補正発明とは
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備する点で共通する。
　
（５）
ア．引用発明においては「要求制御部」は「アプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行」し、「音声変換出力手段」は「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する」のであるから、引用発明における上記「インタフェース手段」と本件補正発明の「アプリケーション・プログラム・インターフェース」とは「前記アプリケーション・プログラムからデータを受信」するものである点で共通する。
　
イ．引用発明においては、「判定部」は「前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定」し、「要求制御部」は「前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行」し、「音声変換出力手段」は「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する」ものであるところ、「前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行う」のであるから、引用発明における上記「インタフェース手段」は「特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するもの」であると言える。
　一方、本件補正発明における「アプリケーション・プログラム・インターフェース」は
「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」
のであるから、これも「特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するもの」であると言える。
　
ウ．したがって、引用発明と本件補正発明は
「前記インタフェース手段は：
　前記アプリケーション・プログラムからデータを受信し、
　特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するものである」
点で共通する。
　
（６）よって、本件補正発明は、下記の本件補正発明と引用発明との一致点で引用発明と一致し、下記の本件補正発明と引用発明との相違点で引用発明と相違する。
　
＜本件補正発明と引用発明との一致点＞
「コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムと
　テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段と；
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　を具備し、
　前記インタフェース手段は：
　前記アプリケーション・プログラムからデータを受信し、
　特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するものである
コンピュータ・システム。」
　
＜本件補正発明と引用発明との相違点１＞
　本件補正発明におけるインタフェース手段は「オペレーティング・システム」が「有する」「アプリケーション・プログラム・インターフェース」である。
（これに対して、引用発明における「ウインドウシステム」は「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」とは別のものとして説明されているため、インタフェース手段は必ずしも「ウインドウシステム」が有する「アプリケーション・プログラム・インターフェース」とは言えないものである。）
　
＜本件補正発明と引用発明との相違点２＞
　本件補正発明におけるアプリケーション・プログラム・インターフェースは「データを前記アプリケーション・プログラムに送信」する。
（これに対し、引用文献１には「データ」を「アプリケーション」に「送信」することを明示する記載は無い。）
　
＜本件補正発明と引用発明との相違点３＞
　本件補正発明におけるアプリケーション・プログラム・インターフェースは、「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」ものである。
（これに対して、引用文献１には、「ウインドウレベルの入替えによる停止要求」との記載はあるものの（引用文献記載事項１−６）、読み上げ中の文への「割り込み」を明示する記載は無く、また、引用発明は優先順位で音声出力を行うものであるものの、優先順位を示す「フラグ」の記載や「待ち行列」に文を加える旨の記載も無い。）
　
　
４−２−４．判断
　以下、上記相違点について検討する。
　
（１）本件補正発明と引用発明との相違点１について
　上記優先日前には、引用文献２．(特に引用文献記載事項２−１、２−２参照)記載の如く、音声合成の機能のプラットフォームが知られており、また、必要なコンポーネントをＯＳに組み合わせてＯＳの機能を拡張したり、ＯＳのバージョンアップに際して新しい機能を追加することも、従来から適宜になされてきたことである（必要があれば参考文献記載事項１−２、２−１、３−１参照）。
　また、アプリケーションとのインタフェースのためにＯＳがＡＰＩを提供することは技術常識にほかならないものである。
　してみると、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」の機能を「オペレーティング・システム」が提供するものとし、これらのインタフェース手段を「オペレーティング・システム」が「有する」「アプリケーション・プログラム・インターフェース」とすること、すなわち、上記本件補正発明と引用発明との相違点１に係る構成を採用することは、当業者であれば容易に想到し得たことである。
　
（２）本件補正発明と引用発明との相違点２について
　本件補正発明における「データを前記アプリケーション・プログラムに送信」することが、本願の発明の詳細な説明に記載されているどのＡＰＩに対応するものなのかは必ずしも明確でないものの、一般的にＡＰＩはエラーコードやデバイスの状態をアプリケーションに返す機能も備えるのが普通であり（例えば、引用文献記載事項２−５（特にヘルプルーチンとメインルーチン間の「現在の話者取得」との記載）、参考文献記載事項４−２、４−３等参照）、また、「オペレーティング・システム」においては、キーボードなどの入力手段や外部記憶装置等からのデータをアプリケーションに引き渡すＡＰＩが設けられることは技術常識である。
　してみると、アプリケーション・プログラム・インターフェースを「データを前記アプリケーション・プログラムに送信」するものとすること、すなわち上記本件補正発明と引用発明との相違点２に係る構成は、上記本件補正発明と引用発明との相違点１に係る構成の採用に伴い必然的に採用される構成にほかならない。
　
（３）本件補正発明と引用発明との相違点３について
　複数の文を出力手段で出力する際に、出力要求された文を再生中のものに割り込んで再生するか否か、および、待ち行列の何処に挿入するかを決めるための情報も送受することは、従来から周知慣用の技術思想にほかならないものであり（必要があれば参考文献記載事項５−１〜５−４、６−１、６−２参照）、係る周知慣用技術の引用発明への採用を試みることは、当業者であれば当然に想到する着想であり、その際に該情報を送受するためのインタフェースを定義・実装することは、必然的に採用される事項にほかならない。
　本件補正発明におけるアプリケーション・プログラム・インターフェースを「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか１つを表す」ものとすることの技術的な意味は必ずしも明確なものではないものの、このようなインタフェースを定義・実装することと解することもできる。
　してみると、引用発明を上記本件補正発明と引用発明との相違点３にかかる事項を備えるものとすることは、当業者が適宜に採用し得た設計的事項に過ぎないものである。
　
（４）よって、本件補正発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。
　そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本件補正発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
４−３．小結
　上記４−１．のとおり、本件補正後の発明の詳細な説明及び特許請求の範囲の記載は、特許法第３６条第４項、同条第６項第１号および第２号に規定する要件を満たしておらず、本件補正後の請求項１、２に係る発明は、この理由によって特許出願の際独立して特許を受けることができないものである。
　
　上記４−２．のとおり、本件補正発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する。
　
　
５．中結
　上記２．のとおり、本件補正は、特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　上記３．のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　上記４．のとおり、本件補正は、仮に平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号に掲げる事項を目的としたものであるとしても、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、上記補正却下の決定の結論のとおり決定する。
　
　
　
第４．原審補正却下の決定の適否
　審判請求書の主張内容等からみて、請求人は平成２５年４月１１日付けの補正却下の決定（以下「原審補正却下」と記す。）に不服を申立ていると認められるので、その適否について検討するに、上記第３．において検討した上記平成２５年８月１６日付けの手続補正書は上記審判請求書記載のとおり、上記平成２５年３月１９日付け手続補正書と同内容の補正をしようとするものであるから、上記平成２５年３月１９日付け手続補正書も上記平成２５年８月１６日付けの手続補正書と同様の理由によって却下すべきものである。
　したがって、上記平成２５年３月１９日付け手続補正書による補正を特許法第５３条第１項の規定により却下するとした、原審補正却下の決定は適法なものであり、これは取り消すべきものではない。
　
　
　
第５．本願特許請求の範囲・明細書・図面
　本願の経緯は上記第１．のとおりであり、上記第３．のとおり平成２５年８月１６日付けの手続補正は却下された。そして、上記第４．のとおり平成２５年４月１１日付けの原審補正却下の決定は適法なものであり、取り消すべきものではない。
　したがって、本願の特許請求の範囲は平成２４年６月１２日付けの手続補正書によって補正された上記第１．１．（１）に記載のとおりのものである。
　なお、本願の明細書及び図面については、手続補正はなされておらず、本願の願書に最初に添付した明細書及び図面のままである。
　
　
　
第６．原審拒絶理由１（特許法第３７条）について
　
１．本願は、本願特許請求の範囲の請求項１〜８に記載されたとおりの、２以上の発明について、１の願書で出願するものであるところ、その請求項１〜８に係る発明は、上記第１．２．（１）に【請求項１】〜【請求項８】として記載したとおりのものである。
　そこで、本願特許請求の範囲の請求項１〜８に係る発明が特許法第３７条各号の関係を有しているか否かについて検討する。
　
　
２．特許法第３７条第１号の関係について
　
（１）分野の共通性
　本願請求項１〜８に係る発明は、いずれも、本願発明の詳細な説明の【技術分野】の項の段落【０００１】記載の「一般的にコンピュータ・オペレーティング・システムに関し、及びより特定的には、リソースが制限されたオペレーティング・システムに対するアプリケーション・プログラム・インターフェースに関する」ものであるから、本願請求項１〜８に係る発明の産業上の利用分野は同一のものであると言える。
　
（２）課題の共通性
ア．本願明細書の発明の詳細な説明の
「【発明が解決しようとする課題】
【００１２】
　上述の短所、不都合、及び問題は、本発明によって検討され、それは、以下の明細書を読み及び研究することによって理解されるであろう。
　リソースが制限された環境のための多くのソフトウェア・モジュール及びコンポーネントのために、一組のアプリケーション・プログラム・インターフェース（Application Program Interfaces）（ＡＰＩ）を含むシステムが提示される。
リソースが制限された環境の一例は、埋め込み型システムであり、それは、ハンドヘルドまたはパームサイズのパーソナル・コンピュータとともに、様々な民生用機器及び専用産業用コントローラを具備する。」
との記載や、本願特許請求の範囲の記載等から、本願請求項１に係る発明と本願請求項８に係る発明は
「ソフトウェア・モジュール及びコンポーネントのためのアプリケーション・プログラム・インターフェースを含むシステムを提示すること」
を共通の課題としていると言える。
　しかしながら、該課題は、引用文献２等を示すまでもなく、本願出願前には解決済みであった課題であり、本願出願時まで未解決であった技術上の課題であるとは言えない。
　
イ．また、他に、本願請求項１に係る発明と本願請求項８に係る発明との間に共通し、かつ、本願出願時まで未解決であった技術上の課題は見あたらない。
　
ウ．本願請求項２〜３に係る発明は本願請求項１に係る発明に従属し、その下位概念に相当する発明であるところ、上記と同様に本願請求項２〜３に係る発明と本願請求項８に係る発明との間に共通し、かつ、本願出願時まで未解決であった技術上の課題は見あたらない。
　
エ．よって、本願請求項１〜３に係る発明を特定発明とした場合には、本願請求項８に係る発明は特許法第３７条第１号に掲げる発明とは言えないものである。
　
オ．同様の理由により、本願請求項４〜７に係る発明を特定発明とした場合にも、本願請求項８に係る発明は特許法第３７条第１号に掲げる発明とは言えないものである。
　
カ．同様の理由により、本願請求項８に係る発明を特定発明とした場合にも本願請求項１〜７に係る発明は特許法第３７条第１号に掲げる発明とは言えないものである。
　
　
３．特許法第３７条第２号の関係について
　
（１）分野の共通性
　上記２．（１）で述べたとおり、本願請求項１〜８に係る発明の産業上の利用分野は同一のものであると言える。
　
（２）主要部の共通性
ア．本願の特許請求の範囲の記載等から見て、本願請求項１に係る発明と本願請求項８に係る発明とは、次の共通事項を有する点で共通する。
　
＜共通事項＞
「コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、ソフトウエア部品を有する前記オペレーティング・システムと；
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　前記ソフトウエア部品と関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと；を具備し、
　前記アプリケーション・プログラム・インターフェースは：
　第１のインターフェースと；
　第２のインターフェースと；を具備する、
　コンピュータ・システム。」
　
イ．上記引用文献２等を挙げるまでもなく、本願優先日前には下記先行技術が周知慣用のものであったと言える。
　
＜先行技術＞
「パソコンにオペレーティング・システムとアプリケーションを搭載したコンピュータシステム」
　
ウ．対比
（ア）当該先行技術における「パソコン」が「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは技術常識にほかならない。
　
（イ）「オペレーティングシステム」が複数のソフトウエア部品で構成されていることも技術常識である（必要があれば参考文献記載事項１−３、２−１、４−１）から、先行技術は
「ソフトウエア部品を有する前記オペレーティング・システム」
を具備するものであることは明らかである。
　
（ウ）「アプリケーション」がオペレーティング・システムの制御下でランするプログラムであることも技術常識であるから、先行技術は
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備するものであることは明らかである。
　
（エ）「オペレーテイングシステム」がこれら複数のソフトウエア部品に関連するアプリケーション・プログラム・インターフェースを具備することも技術常識である（必要があれば参考文献記載事項１−１、４−１等参照）から、先行技術は、
「前記コンポーネントと関連するアプリケーション・プログラム・インターフェース」
を具備するものであることは明らかである。
　
（オ）また「アプリケーション・プログラム・インターフェース」が「前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する」ことも自明であり、先行技術における「アプリケーション・プログラム・インターフェース」が
「前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する」
ものであることも明らかである。
　
（カ）さらに、「オペレーテイングシステム」はこのような「アプリケーション・プログラム・インターフェース」を複数提供していることも技術常識であるから、
「前記アプリケーション・プログラム・インターフェースは：
　第１のインターフェースと；
　第２のインターフェースと；を具備する」
ものであることも明らかである。
　
（キ）したがって、上記共通事項は上記先行技術と相違のないものであり、新規な事項とは言えないものである。
　
エ．してみると、上記共通事項は主要部、すなわち、解決しようとする課題に対応した新規な事項と言えるものではない。
　
オ．また、他に、本願請求項１に係る発明と本願請求項８に係る発明との間に共通の主要部と言える事項は見あたらない。
　
カ．本願請求項２〜３に係る発明は本願請求項１に係る発明に従属し、その下位概念に相当する発明であるところ、上記と同様に本願請求項２〜３に係る発明と本願請求項８に係る発明との間に共通の主要部と言える事項は見あたらない。
　
キ．よって、本願請求項１〜３に係る発明を特定発明とした場合には、本願請求項８に係る発明は特許法第３７条第２号に掲げる発明とは言えないものである。
　
ク．同様の理由により、本願請求項４〜７に係る発明を特定発明とした場合にも、本願請求項８に係る発明は特許法第３７条第２号に掲げる発明とは言えないものである。
　
ケ．同様の理由により、本願請求項８に係る発明を特定発明とした場合にも本願請求項１〜７に係る発明は特許法第３７条第２号に掲げる発明とは言えないものである。
　
　
４．特許法第３７条第３号の関係について
　本願請求項１〜８に係る発明はいずれも「コンピュータ・システム」すなわち「物」の発明であるから、本願請求項１〜８に係る発明のいずれを特定発明としても、他の請求項に係る発明は、該特定発明を生産する方法の発明とも、該特定発明を使用する方法の発明とも、該特定発明を取り扱う方法の発明とも言えるものではないことは明らかである。
　また、本願請求項１〜８に係る発明はいずれも、他の「コンピュータ・システム」を生産したり利用したりする「コンピュータ・システム」ではないので、本願請求項１〜８に係る発明のいずれを特定発明としても、他の請求項に係る発明は、該特定発明を生産する機械、器具、装置、その他の物の発明とも、該特定発明の特定の性質を専ら利用する物の発明とも、該特定発明を取り扱う物の発明とも言えるものではないことは明らかである。
　よって、本願請求項１〜８に係る発明のいずれを特定発明としても、他の請求項に係る発明は特許法第３７条第３号に掲げる発明とは言えない。
　
　
５．特許法第３７条第４号の関係について
　本願請求項１〜８に係る発明はいずれも「コンピュータ・システム」すなわち「物」の発明であり、本願請求項１〜８に係る発明のいずれも特許法第３７条第４号における特定発明とはなり得ず、当然に本願請求項１〜８に係る発明のいずれも特定発明の実施に直接使用する機械、器具、装置その他の物には該当しないことは明らかである。
　よって、本願請求項１〜８に係る発明のいずれを特定発明としても、他の請求項に係る発明は、特許法第３７条第４号に掲げる発明とは言えない。
　
　
６．特許法第３７条第５号の関係について
　上記２．〜５．のとおりであるから、本願請求項１〜８に係る発明のいずれを特定発明としても、当該特定発明と他の請求項に係る発明とは特許法第３７条第５号の経済産業省令で定める関係を有しない。
　
　
７．小結
　以上のとおりであるから、本願請求項１〜８に係る発明のいずれを特定発明としても、本願請求項１〜８係る発明の中に特許法第３７条各号の何れの関係も有しない発明が存在する。
　
　よって、本願は特許法第３７条に規定する要件を満たしていないものである。
　
　
　
第７．原審拒絶理由２（特許法第３６条第６項第１号）について
　
１．上記原審拒絶理由通知書で通知した特許法第３６条についての拒絶理由は上記第１．２．（２）の理由２．に記載のとおりのものである。
　
２．平成２５年８月１６日付けの手続補正は上記第３．のとおり却下されたのであるから、原審拒絶理由理由の２．において、明細書に記載されていないと指摘された、請求項１−３に係る発明は、依然として、特許請求の範囲に記載されたままのものである。
　
３．本願の請求項１について検討するに、その発明特定事項である「第２のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載は本願の発明の詳細な説明中には見当たらない。
なお【表１２６】には
「pszSpeak
　[in]話すためのテキストを含むバッファのアドレスである。アプリケーションは、Ｓｐｅａｋが返るとすぐに、前記バッファを解放し又は修正することができる。このパラメータによって指された列は、テキスト・ツゥ・スピーチ制御タグを含むことができる。」
『pszTags
　[in]音声、言語、又はｐｓｚＳｐｅａｋによって特定されるテキストのコンテクストを変更するためのテキスト・ツゥ・スピーチ制御タグ、又は前記テキスト・ツゥ・スピーチ音声に対してデフォルト設定を使用するためのＮＵＬＬを含むバッファのアドレスである。制御タグに関するさらなる情報は、付録Ａ「テキスト・ツゥ・スピーチ制御タグ」を参照のこと。』
との記載があるものの、このパラメータ「pszSpeak」「pszTags」は「バッファのアドレス」であり、バッファそのものではない。
　
４．本願の請求項１について検討するに、その発明特定事項である「前記テキストの種類を示す優先順位フラグ」に相当する記載は本願の発明の詳細な説明中には見当たらない。
なお、【表１２６】には
「dwFlags
　[in]前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類のフラグと一つの優先順位フラグとの組み合わせである。」
との記載があるものの、ここに記載される「優先順位フラグ」は「優先順位を示す」ものであり、「前記テキストの種類を示す」ものではない。また、ここに記載される「種類のフラグ」は「テキストの種類」「を示すフラグ」であると認められるものの「優先順位フラグ」とは明らかに異なる用語であり、請求項１の記載と異なる。
　
５．以上のとおり、請求項１の記載は発明の詳細な説明と明らかに齟齬する記載を含み、発明の詳細な説明中に記載も示唆もされていない事項が記載されているもの、あるいは、請求項１と発明の詳細な説明に記載された用語が不統一であり、その結果、両者の対応関係が不明瞭となっているものであるから、請求項１〜３に係る発明は、発明の詳細な説明に記載したものではないといえる。
　
６．よって、本願は、特許請求の範囲の記載が、特許法第３６条第６項第１号に規定する要件を満たしていないものである。
　
　
　
第８．原審拒絶理由３（特許法第２９条第２項）について
　
１．本願発明の認定・引用文献の記載内容・引用発明の認定
　
　本願の請求項１に係る発明（以下、「本願発明」という。）は、上記平成２４年６月１２日付けの手続補正書によって補正された特許請求の範囲の記載等からみて次の通りのものであると認められる。
　
＜本願発明＞
「コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントを有する前記オペレーティング・システムと；
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　前記テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信するように動作する前記アプリケーション・プログラム・インターフェースと；を具備し、
　前記アプリケーション・プログラム・インターフェースは：
　アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する、
　ことを特徴とするコンピュータ・システム。」
　
（なお、上記平成２４年６月１２日付けの手続補正書の請求項１における「スピーチ・ツゥ・テキスト・コンポーネント」との記載は「テキスト・ツゥ・スピーチ・コンポーネント」の誤記と、「前記アプリケーション」との記載は「前記アプリケーション・プログラム」の誤記と認められるので、それぞれ、「テキスト・ツゥ・スピーチ・コンポーネント」「前記アプリケーション・プログラム」に正して認定した。）
　
　
２．先行技術文献・引用発明
　上記第２．１．で示したとおり、本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成２４年１２月１３日付けの拒絶理由通知書の理由３において引用された、上記引用文献にはそれぞれ上記引用文献記載事項が記載されており、上記第２．２．で示したとおり、本願の出願前かつ上記優先日よりも前に頒布された上記参考文献にはそれぞれ上記参考文献記載事項が記載されている。
　そして、上記引用文献１には上記第２．３．で認定したとおりの引用発明が記載されているといえる。
　
　
３．対比
　以下に、本願発明と引用発明とを比較する。
　
（１）上記４−２−３．（１）での所論と同様に、引用発明は本願発明と同様に「コンピュータ・システム」とも言えるものであり、また、本願発明と同様に「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは明らかである。
　
（２）上記４−２−３．（２）での所論と同様に、引用発明と本願発明とは「前記プロセッサにおいて動作するオペレーティング・システム」
を具備する点で共通する。
　
（３）上記４−２−３．（３）でも述べたように、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」は本願発明における「テキスト・ツゥ・スピーチ・コンポーネント」に相当する。
　したがって、引用発明と本願発明とは
「テキスト・ツゥ・スピーチ・コンポーネント」
を具備する点で共通する。
　
（４）上記４−２−３．（４）での所論と同様に、引用発明と本願発明とは
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備する点で共通する。
　
（５）
ア．上記４−２−３．（３）でも述べたように、引用発明にける「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」と「アプリケーション」との間のインタフェースを行う手段があることは自明であり、該手段は本願発明における「アプリケーション・プログラム・インターフェース」に対応付けることができるところ、両者は「前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」と言えるものである点で共通する。
　
イ．上記４−２−３．（５）ア．で述べたように、引用発明における上記「インタフェース手段」と本願発明の「アプリケーション・プログラム・インターフェース」とは「前記アプリケーション・プログラムからデータを受信するように動作する」ものである点でも共通する。
　
ウ．したがって、引用発明と本願発明とは
「前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段であって、前記アプリケーション・プログラムからデータを受信するように動作する前記インタフェース手段」
を具備している点で共通する
　
（６）引用発明における「アプリケーションの実行ファイル名」は本願発明における「アプリケーション識別子」に相当するものであり、引用発明は「実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段」を備え、「前記登録手段はアプリケーションの実行ファイル名を登録するもの」であるから、上記引用発明における「インタフェース手段」と本願発明における「アプリケーション・プログラム・インターフェース」は
「アプリケーション識別子を受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェース」
を具備する点で共通する。
　
（７）引用発明は「アプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、」「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える」のであるから、上記引用発明における「インタフェース手段」と本願発明における「アプリケーション・プログラム・インターフェース」とは、
「テキストを含むバッファを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェース」
を具備するものである点で共通するといえる。
　
（８）よって、本願発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。
　
＜一致点＞
「コンピュータ・システムであって：
　互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと；
　前記プロセッサにおいて動作するオペレーティング・システムと；
　テキスト・ツゥ・スピーチ・コンポーネントと；
　前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと；
　前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段であって、前記アプリケーション・プログラムからデータを受信するように動作する前記インタフェース手段と；を具備し、
　前記インタフェース手段は：
　アプリケーション識別子を受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第１のインターフェースと；
　テキストを含むバッファを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第２のインターフェースと；を具備する、
　コンピュータ・システム。」
　
＜相違点１＞
　本願発明におけるオペレーティング・システムは「テキスト・ツゥ・スピーチ・コンポーネントを有する」ものである。
（これに対して、引用発明における「ウインドウシステム」は「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」とは別のものとして説明されている。）
　
＜相違点２＞
　本願発明におけるインタフェース手段は「アプリケーション・プログラム・インターフェース」である。
（これに対して、引用文献１には「アプリケーション・プログラム・インターフェース」の直接的な明示はない。）
　
＜相違点３＞
　本願発明におけるアプリケーション・プログラム・インターフェースは「データを前記アプリケーション・プログラムに送信」する。
（これに対し、引用文献１にはデータをアプリケーションに「送信」することを明示する記載は無い。）
　
＜相違点４＞
　本願発明における第１のインターフェースは「通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照」も受け取るものである。
（これに対して、引用文献１における「登録手段」がこのような情報を通知することは記載されていない。）
　
＜相違点５＞
　本願発明における第２のインターフェースは、「前記テキストの種類を示す優先順位フラグ」も受け取る。
（これに対して引用文献１にはこのようなフラグをやりとりすることは記載されていない。）
　
＜相違点６＞
　本願発明における第２のインターフェースは、「テキスト・ツゥ・スピーチ制御タグを含むバッファ」も受け取る。
（これに対して、引用文献１における「状態監視部」「判定部」「要求制御部」「音声変換出力手段」がこのような情報を通知することは記載されていない。）
　
　
４．判断
　以下に、上記相違点について検討する。
　
（１）相違点１について
　上記優先日前には、引用文献２．(特に引用文献記載事項２−１、２−２参照)記載の如く、音声合成の機能のプラットフォームが知られており、また、必要なコンポーネントをＯＳに組み合わせてＯＳの機能を拡張したり、ＯＳのバージョンアップに際して新しい機能を追加することも、従来から適宜になされてきたことである（必要があれば参考文献記載事項１−２、２−１、３−１参照）。
　してみると、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」を「ウインドウシステム」に含めることで、本願発明と同様に「オペレーティング・システム」が「テキスト・ツゥ・スピーチ・コンポーネントを有する」ものとすること、すなわち、上記相違点１に係る構成を採用することは、当業者であれば容易に想到し得たことである。
　
（２）相違点２について
　アプリケーションやユーザとのインタフェースのためにオペレーティング・システムがアプリケーション・プログラム・インターフェースを提供することは技術常識にほかならないものであり、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」の「インタフェース手段」を「アプリケーション・プログラム・インターフェース」とすること、すなわち、上記相違点２に係る構成は、上記相違点１に係る構成の採用に伴い必然的に採用されるものにほかならない。
　
（３）相違点３について
　本願発明における「データを前記アプリケーション・プログラムに送信」することが本願発明の詳細な説明に記載のどのＡＰＩに対応するものなのかは必ずしも明確でないものの、一般的にＡＰＩはエラーコードやデバイスの状態をアプリケーションに返す機能も備えるのが普通であり（例えば、引用文献記載事項２−５（特にヘルプルーチンとメインルーチン間の「現在の話者取得」との記載）、参考文献記載事項４−２、４−３等参照）、また、「オペレーティング・システム」においては、キーボードなどの入力手段や外部記憶装置等からのデータをアプリケーションに引き渡すＡＰＩが設けられることは技術常識である。
　してみると、アプリケーション・プログラム・インターフェースを「データを前記アプリケーション・プログラムに送信」するものとすること、すなわち上記相違点３に係る構成も、上記相違点１に係る構成の採用に伴い必然的に採用されるものにほかならない。
　
（４）相違点４について
　一般に音声合成手段には、現在の話者などの自己の状態を利用手段に通知する機能を有しており、また、利用手段からテンポなどを設定できるように構成されるものである。（必要があれば引用文献記載事項２−３〜２−５等参照。）
　したがって、引用発明においても「音声変換出力手段」の状態などを「アプリケーション」に通知し、また、「音声変換出力手段」の話者や話速などを設定し得るようにするため、上記「第１のインターフェース」を「通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照」も受け取るものとすること、すなわち、上記相違点４に係る構成を採用することも、当業者であれば適宜に採用し得た設計的事項に過ぎない。
　
（５）相違点５について
　本願発明における「前記テキストの種類を示す優先順位フラグ」との技術的意味は必ずしも明確なものではないものの、複数の文を出力手段で出力する際に、出力要求された文を再生中のものに割り込んで再生するか否かの情報や待ち行列の何処に挿入するかを決めるための情報を送受することは、従来から周知慣用の技術思想にほかならないものであり（必要があれば参考文献記載事項５−１〜５−４、６−１、６−２参照）、本願発明における「前記テキストの種類を示す優先順位フラグ」とは、このような情報を包含するものと解することができる。
　してみると、引用発明における第２のインターフェースを、「前記テキストの種類を示す優先順位フラグ」も受け取るものとすること、すなわち上記相違点６に係る事項を備えるものとすることは、当業者であれば適宜に採用し得た設計的事項にすぎない。
　
（６）相違点６について
　音声合成手段を話者変更などの制御を可能にする機能を備えることも、当業者が通常採用する周知慣用技術であり（必要があれば引用文献記載事項２−４、２−５等参照。）、引用発明における第２のインターフェースを、「テキスト・ツゥ・スピーチ制御タグを含むバッファ」も受け取るものとすること、すなわち上記相違点６に係る事項を備えるものとすることも、当業者であれば適宜に採用し得た設計的事項にすぎない。
　
（７）よって、本願発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。
　また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
５．小結
　以上のとおり、本願の請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　
　
　
第９．結び
　
１．上記第６．のとおり、本願は、特許法第３７条に規定する要件を満たしていないものであるから、原審拒絶理由１によって拒絶すべきものである。
　
２．上記第７．のとおり、本願は、特許請求の範囲の記載が、特許法第３６条第６項第１号に規定する要件を満たしていないものであるから、原審拒絶理由２によっても拒絶すべきものである。
　
３．上記第８．のとおり、本願請求項１に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものであるから、本願は原審拒絶理由３によっても拒絶すべきものである。
　
４．なお、上記第３．４−１．（２）、および上記第３．４−２．において検討したとおりであるから、上記第３．の補正却下の決定がなされなかったと仮定した場合であっても、本願は原審拒絶理由２および３によって拒絶すべきものである。
　
５．したがって、原査定を取り消し、本願は特許をすべきものであるとの審決をすることはできない。
　
　よって、上記結論のとおり審決する。