• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 4項4号特許請求の範囲における明りょうでない記載の釈明 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
審判 査定不服 2号主要部同一 特許、登録しない。 G06F
審判 査定不服 1号課題同一 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 G06F
管理番号 1296070
審判番号 不服2013-15877  
総通号数 182 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-02-27 
種別 拒絶査定不服の審決 
審判請求日 2013-08-16 
確定日 2015-01-09 
事件の表示 特願2009- 34311「オペレーティング・システムのアプリケーション・プログラム・インターフェース」拒絶査定不服審判事件〔平成21年 6月25日出願公開、特開2009-140521〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯

1.手続の経緯の概要
本件に係る出願(以下「本願」と記す。)は
1998年3月23日(以下「優先日」と記す。)のアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権主張を伴い、
1999年3月22日を国際出願日とする国際出願による出願であるところの、特願2000-538298号を原出願とする特許法第44条第1項の規定による新たな特許出願として
平成21年2月17日付けで出願されたものであって、
平成21年2月18日付けで審査請求がなされ、
平成24年3月8日付けで拒絶理由通知(平成24年3月12日発送)がなされ、
平成24年6月12日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成24年12月13日付けで最後の拒絶理由通知(平成24年12月19日発送)がなされ、
平成25年3月19日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成25年4月11日付けで上記平成25年3月19日付けの手続補正書による補正の却下の決定(平成25年4月16日謄本発送・送達)がなされるとともに、
同日付けで、上記平成24年12月13日付けの拒絶理由通知書に記載した理由によって拒絶査定(平成25年4月16日謄本発送・送達)がなされたものである。

本件審判請求は、上記拒絶査定を不服とし、
平成25年8月16日付けで請求されたものであり、
同日付けで手続補正書が提出され、
平成25年9月4日付けで特許法第164条第3項に定める報告(前置報告)がなされ、
平成25年10月4日付けで当該報告に対する意見を求める旨の審尋(平成25年10月7日発送)がなされ、
平成26年1月7日付けで回答書が提出され、
平成26年3月10日付けで審尋(平成26年3月11日発送)がなされ、
平成26年5月16日付けで回答書が提出されたものである。


2.拒絶理由・補正の内容・請求人の主張等の概要

(1)平成24年6月12日付け手続補正
上記平成24年6月12日付けの手続補正書は特許請求の範囲を以下のとおりに補正するものである。
「 【請求項1】
コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと;を具備し、
前記アプリケーション・プログラム・インターフェースは:
アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項2】
請求項1に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは:
前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを停止するようにさせ、及び一組の保留テキストを再生待ち行列からクリアするようにさせる第3のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを一時停止するようにさせる第4のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを稼動させるのを再開するようにさせる第5のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項3】
請求項1に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは:
前記現在のスピーチ状態を示すフラグを戻す第6のインターフェースと;
第1の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第1の話し速度でテキストを出力するようにさせる第7のインターフェースと;
現在の話し速度を戻す第8のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき音声を示す第1の音声識別子を受け取る第9のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき前記現在の音声を示す第2の音声識別子を戻す第10のインターフェースと;を含む、
ことを特徴とするコンピュータ・システム。
【請求項4】
コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、音声認識コンポーネントを有する前記オペレーティング・システムと;
前記オペレーティング・システムの制御下でランする、アプリケーション・プログラムと;
前記音声認識コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと;を具備し、
前記アプリケーション・プログラム・インターフェースは:
可能化パラメータを前記アプリケーションから受け取る第1のインターフェースであって、前記可能化パラメータは、前記可能化パラメータが第1の値を有する時に、前記音声認識コンポーネントが、音声認識を可能にし、及び前記可能化パラメータが第2の値を有する時に、音声認識を不能にするようにさせるよう動作する第1のインターフェースと;
前記アプリケーションに第2のパラメータを戻す第2のインターフェースであって、前記第2のパラメータは、前記第2のパラメータが前記第1の値を有する時に音声認識が可能にされ、及び前記第2のパラメータが前記第2の値を有する時に音声認識が不能にされることを示すように動作する第2のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項5】
請求項4に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースが:
前記少なくとも一つの音声コマンド・メニューと関連するウィンドウのハンドル及び前記メニューがスピーチ認識状態と関連して活動状態であるべき時を示すフラグを受け取る第3のインターフェースと;
その各々が音声コマンドを説明するコマンド構造のリストを受け取り、及び前記少なくとも一つの音声コマンド・メニューに加えられた第1の音声コマンドと関連する数を戻す第4のインターフェースと;
前記少なくとも一つの音声コマンド・メニューを停止させる、第5のインターフェースと;
第1の音声コマンドに対応する数、除去する音声コマンドの数を受け取り、及び前記音声コマンドの数を、前記少なくとも一つの音声コマンド・メニューから除去する第6のインターフェースであって、前記除去は、前記第1の音声コマンドに対応する数で始まる第6のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項6】
請求項4に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは:
前記アプリケーションから、音声メニュー及びコマンド列を識別する第1の音声コマンド構造を受け取る第7のインターフェースであって、前記音声コマンド構造は、第2のアプリケーションと関連する第7のインターフェースと;
認識された音声コマンドの識別子、前記認識された音声コマンドと関連する音声メニューを識別する第2の音声コマンド構造、検査要求フラグ、動作データ列、前記認識された音声コマンドの少なくとも一つの認識されたフレーズを含むリストと、及び前記認識されたコマンドに対応するコマンド列とを受け取る第8のインターフェースと;
話されるフレーズが、前記音声認識コンポーネントによって検出される時に呼び出される第9のインターフェースと;
前記音声認識コンポーネントによって検出される干渉の一種を受け取る第10のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項7】
請求項4に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは、
アプリケーション名及び状態名を具備するメニュー識別子構造、言語識別子構造、及びモード・フラグをアプリケーションから受け取り、音声認識システムが、前記メニュー識別子構造によって識別される音声コマンド・メニューを生成するようにさせる第11のインターフェースと;
前記メニュー識別子構造をアプリケーションから受け取り、及び前記音声認識システムが、前記メニュー識別子構造によって識別される前記音声コマンド・メニューを削除するようにさせる第12のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。
【請求項8】
コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、メモリ外モジュールを有する前記オペレーティング・システムと;
前記メモリ外モジュールと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーション・プログラム・インターフェースは、前記オペレーティング・システムに、前記メモリ外モジュールが、低メモリ状態に応答するようにさせることを許可するように機能する前記アプリケーション・プログラム・インターフェースと;を具備し、
前記アプリケーション・プログラム・インターフェースは:
前記オペレーティング・システムから、前記メモリ外モジュールによって閉じられるべきウィンドウを識別するウィンドウ構造のリストを受け取る第1のインターフェースと;
前記オペレーティング・システムに、メモリが危機的に低いか決定するようにさせる前記メモリ外モジュールによって呼び出される第2のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。」


(2)原審拒絶理由
上記平成24年12月13日付けの拒絶理由通知書(以下「原審拒絶理由通知書」と記す。)によって通知された拒絶理由(以下「原審拒絶理由」と記す。)の内容は概略以下のとおりである。
『 理 由

1.この出願は、下記の点で特許法第37条に規定する要件を満たしていない。

2.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。

3.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

記 (引用文献等については引用文献等一覧参照)

[理由1]
請求項1-3に記載される発明(以下「特定発明」という。)と請求項4-7に記載される発明とに共通する課題は、段落【0014】等に記載されているように、可聴スピーチを出力するコンポーネントにデータを供給するAPIを提供することである。しかしながら、この課題は、本願出願前に解決されており(下記の引用文献2等参照)、本願出願時未解決の課題ではない。
よって、請求項4-7に記載される発明は、特定発明に対し、特許法第37条第1号に掲げる関係を有しない。
また、特定発明と請求項4-7に記載される発明とに共通する発明特定事項のうち、解決しようとする課題に対応した事項である「前記プロセッサにおいて動作するオペレーティング・システムであって、スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと;前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと;を具備」することは、新規でない(下記の引用文献2等参照)。
したがって、特定発明と請求項4-7に記載される発明との間に、解決しようとする課題に対応した新規な発明特定事項である主要部が、共通して存在しない。
よって、請求項4-7に記載される発明は、特定発明に対し、同条第2号に掲げる関係を有しない。
さらに、請求項4-7に記載される発明は、特定発明に対し、同条第3号、第4号、第5号に掲げるいずれの関係も有しない。

また、請求項1-3に記載される発明(以下「特定発明」という。)と請求項8に記載される発明とに共通する課題は、APIを提供することである。しかしながら、この課題は、本願出願前に解決されており(下記の引用文献2等参照)、本願出願時未解決の課題ではない。
よって、請求項8に記載される発明は、特定発明に対し、特許法第37条第1号に掲げる関係を有しない。
また、特定発明と請求項8に記載される発明とに共通する発明特定事項のうち、解決しようとする課題に対応した事項である「アプリケーション・プログラム・インターフェースと;を具備」することは、新規でない(下記の引用文献2等参照)。
したがって、特定発明と請求項8に記載される発明との間に、解決しようとする課題に対応した新規な発明特定事項である主要部が、共通して存在しない。
よって、請求項8に記載される発明は、特定発明に対し、同条第2号に掲げる関係を有しない。
さらに、請求項8に記載される発明は、特定発明に対し、同条第3号、第4号、第5号に掲げるいずれの関係も有しない。

この出願は特許法第37条の規定に違反しているので、請求項1-3以外の請求項に係る発明については特許法第37条以外の要件についての審査を行っていない。

なお、上記記載した理由と同様に、請求項4-7に係る発明と請求項8に係る発明が、特許法第37条第1号乃至第5号に規定するいずれの関係も有しないことも明らかである。

[理由2]
(a)請求項1-3に係る発明が、明細書のどの部分に対応するのか、また、日本語として明細書のどの部分に記載されているのか不明である。
したがって、本願請求項1-3に係る発明は、発明の詳細な説明中に記載も示唆もされていない。
(審査基準 第1部 第1章 明細書及び特許請求の範囲の記載要件 2.2.1.3 第36条第6項第1号違反の類型の (1)に該当する。)

よって、請求項1-3に係る発明は、発明の詳細な説明に記載したものでない。

[理由3]
請求項:1
引用文献:1,2
備考:
引用文献1には
「複数のアプリケーションから音声出力の対象となるアプリケーションを選択し、登録する手段と、
起動中のアプリケーションの アプリケーションのテキスト内容を共有領域に複写する手段と、
アプリケーションに優先順位を付け、優先順位順に、複写されたテキストデータを読み出し、音声データに変換し出力するシステム。」
の発明が記載されている。

したがって、本願請求項1に係る発明と引用文献1に記載された発明では、本願発明が、スピーチ・ツゥ・テキスト・コンポーネントとアプリケーションとがAPIを利用して通信するのに対して、引用文献1には「API」と特定されていない点で相違する。
上記相違点について検討する。
引用文献2に示されるように、アプリケーションがAPIを利用して、音声合成のモジュールと通信を行うことは周知であって、引用文献1に記載された発明に上記周知技術を適用して、本願発明の構成とすることは当業者が容易に想到しうることである。

請求項:2,3
引用文献:1,2
備考:
音声合成のシステムにおいて、音声の再生機能として、、一時停止機能や、再開機能、速度変更、や、声の変更等の機能を設けることは周知である。

拒絶の理由が新たに発見された場合には拒絶の理由が通知される。


引 用 文 献 等 一 覧
1.特開平8-263259号公報
2.近藤 玲史,パソコン向け音声認識合成プラットフォームの構築とアプリケーションの試作,第53回(平成8年後期)全国大会講演論文集(2) 平成8年9月4日?6日,日本,社団法人情報処理学会,1996年 9月 6日,p.2-363?2-364』


(3)平成25年3月19日付け手続補正
上記平成25年3月19日日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとしたものである。
『 【請求項1】
コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
前記アプリケーション・プログラム・インターフェースは:
前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す
ことを特徴とするコンピュータ・システム。
【請求項2】
請求項1に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは、話し速度を特定することを特徴とするコンピュータ・システム』


(4)平成25年3月19日付け意見
上記平成25年3月19日付けの意見書における意見の内容は、概略次のとおりである。
『【意見の内容】
1.平成24年12月13日付け(発送日12月19日)拒絶理由通知(最後)において、以下の理由1?3を指摘された。
・・・中略・・・
2.そこで、本出願人は、特許請求の範囲の記載を補正する手続補正書を作成し、本意見書とともに提出した。本出願人は、この手続補正により上記拒絶理由は全て解消されたものと思料する。

3.補正の内容、根拠、補正の目的の適合性
本補正は、補正前の請求項2、4?8を削除し、また、請求項1、3についてサポート要件違反(理由2)を解消すべく記載内容を整理し、請求項の番号を振り替えて、補正後の請求項1、2としたものであり、実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明、請求項の削除を目的とするものであるとともに、後述するように(「5.理由2(サポート要件違反)について」参照)、当初明細書等の記載の範囲内でなされたものである。
補正後の請求項1、2に係る発明(以下、「本願発明1」、「本願発明2」という。特許請求の範囲に記載された発明を総称して「本願発明」という場合もある)を、構成要件に分説すると以下のとおりである(A,B等の符号は分説の便宜上付したもの、下線は補正個所を示すために付したものである)。
(本願発明1)
A.コンピュータ・システムであって:
B.互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
C.前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと;
D.前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
E.前記アプリケーション・プログラム・インターフェースは:
E1.前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
E2.特定されたテキストの優先順位を示すフラグを受け取るように動作し、
E3.前記フラグは、
E31.再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
E32.別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
E33.別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す
A’.ことを特徴とするコンピュータ・システム。
(本願発明2)
F.請求項1に記載のコンピュータ・システムにおいて、
G.前記アプリケーション・プログラム・インターフェースは、話し速度を特定する
F’.ことを特徴とするコンピュータ・システム。

4.理由1(発明の単一性違反)について
審査官殿は、概略,補正前の請求項1-3に係る発明と、請求項4-7に係る発明及び請求項8に係る発明とは、特許法第37条各号に掲げる何れの関係も有していない旨指摘されている。
これに対し、本補正により、補正前の請求項4?8を削除した。
これにより、理由1は解消されたものと思料する。

5.理由2(サポート要件違反)について
審査官殿は、補正前の請求項1?3に係る発明について、サポート要件違反を指摘されている。
これに対し、補正前の請求項2を削除するとともに、請求項1及び3について、前記のような補正を行い、補正後の請求項1、2とした。
補正の根拠は、概略以下のとおりである。
(1)補正後の請求項1:明細書の段落〔0079〕(構成要件C)、〔表126〕、〔表127〕及び〔表130〕(構成要件E31?E33)
(2)補正後の請求項2:〔表181〕(構成要件G)
これにより、理由2も解消されたものと思料する。

6.理由3(進歩性欠如)について
6-1.理由3の概要
審査官殿は、補正前の請求項1?3に係る発明につき、引用文献1及び2を引用し、概略以下のような指摘をされている。
・・・中略・・・
6-2.本願発明の特徴
本願発明1は、特に、構成要件E2の『特定されたテキストの優先順位を示すフラグを受け取るように動作』する点、当該フラグの指示内容に係る、構成要件E31の『再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと』、構成要件E32の『別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること』、構成要件E33の『別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること』に特徴を有するものである。

6-3.各引用文献に記載された事項
引用文献1には、要約欄に〔構成〕として以下のような記載がある。
『登録手段1により、マルチウインドウで起動されているアプリケーション6から音声出力の対象を選択し、共用領域7に登録する。状態監視部3は起動中のアプリケーションの実行順位等のシステム状態情報を判定部4に供給する。判定部4は状態監視部3と登録領域7に登録されたアプリケーションとを比較し、音声出力の条件に叶うアプリケーションを選んで要求制御部5に通知する。要求制御部5は当該アプリケーションに対して、ウインドウ表示中のテキスト内容を共用領域7に複写させる。音声変換出力手段8は音声データに変換して出力する。』
引用文献2には、音声認識合成の機能を提供するプラットフォームとして、図1に、音声認識・合成エンジン及びAPIからなるプラットフォームが示されている。

6-4.本願発明1と引用文献1に記載された発明との対比・判断
引用文献1には、上記本願発明1の特徴は記載も示唆もされていない。
即ち、引用文献1には、審査官殿が説示されるような構成は記載されているとしても、上記特徴に相当する構成は一切開示されていない。
また、引用文献2にも、同様に、上記特徴に相当する構成は一切開示されていない。
以上のとおり、引用文献1及び2には、本願発明1の上記特徴が記載されていないのであるから、引用文献1及び2の記載内容を組み合わせたとしても、本願発明1の構成とすることはできない。
そして、本願発明1は、上記特徴点を含む構成により、明細書記載の作用効果を奏するものである。
したがって、本願発明1は、引用文献1及び2に記載された発明に基づいて当業者が容易に想到し得たものではなく、特許法第29条第2項に該当しないものである。

6-5.本願発明2について
本願発明2は、請求項1を引用するものであり、本願発明1の構成要件をすべて含み、更に他の構成要件を付加したものに相当するものであるから、本願発明1が、上記のとおり特許法第29条第2項に該当しないものである以上、本願発明2も、特許法第29条第2項に該当しないものである。
・・・後略・・・』


(5)原審補正却下理由
上記平成25年4月11日付けの補正の却下の決定の理由は概略次の通りのものである。
『 理 由

出願人は、補正前の請求項1の「前記アプリケーション・プログラム・インターフェース」を
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する」
から
「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」
と変更し、補正後の請求項1とする補正を行っている。

本件補正は、補正前の請求項1の「アプリケーション・プログラム・インターフェース」が「第1のインターフェース」と「第2のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。

また、出願人は本件補正が実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものである旨主張しているが、本件補正は、新規性進歩性を主張することを目的として、発明特定事項を追加する補正であって、明りょうでない記載の釈明を目的とするものとは認められない。

また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこも明らかである。

したがって、この補正は、特許法第17条の2第4項の各号に掲げるいずれの事項を目的とするものにも該当しない。
よって、この補正は同法第17条の2第4項の規定に違反するものであるから、同法第53条第1項の規定により上記結論のとおり決定する。』


(6)原審拒絶査定の理由
原審の拒絶査定の理由は次のとおりのものである。
『この出願については、平成24年12月13日付け拒絶理由通知書に記載した理由によって、拒絶をすべきものです。
なお、意見書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。

また、手続補正は、本拒絶査定と同日付けで補正却下となった。』


(7)審判請求理由
本件審判請求の趣旨は「原査定を取り消す、本願は特許をすべきものであるとの審決を求める」と言うものであり、その理由の概要は以下のとおりである。
「【請求の理由】
1.手続の経緯
・・・中略・・・
3.審判請求と同時になされた手続補正について
本請求人は、後述するように、上記補正却下の決定に承服するものではないが、これを措き、本審判請求と同時に、平成25年3月19日付けで提出した手続補正書と同内容の手続補正書を提出し、平成24年6月12日付け手続補正書をベースに特許請求の範囲の記載を修正した。この補正は、(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものであり、当初明細書等の記載の範囲内でなされたものである。

4.補正却下の決定について
4-1.ご指摘の概要
審査官殿は、補正却下の決定の理由において、概略以下のような指摘をされている。
『出願人は、補正前の請求項1の「前記アプリケーション・プログラム・インターフェース」を・・・ と変更し、補正後の請求項1とする補正を行っている。
本件補正は、補正前の請求項1の「アプリケーション・プログラム・インターフェース」が「第1のインターフェース」と「第2のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。
また、出願人は本件補正が実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものである旨主張しているが、本件補正は、新規性進歩性を主張することを目的として、発明特定事項を追加する補正であって、明りょうでない記載の釈明を目的とするものとは認められない。
また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこ(ママ)も明らかである。
したがって、この補正は、特許法第17条の2第4項の各号に掲げるいずれの事項を目的とするものにも該当しない。』

4-2.上記ご指摘の非妥当性
本出願人が、上記補正却下の対象となった平成25年3月19日付け手続補正を提出したのは、平成24年12月13日付け拒絶理由通知(最後)に対応するためのものであったところ、上記拒絶理由通知は、単一性要件違反(理由1)、サポート要件違反(理由2)、進歩性欠如(理由3)を指摘するものであった、
そして、上記理由中、サポート要件違反(理由2)の指摘内容は、以下のとおりのものであった。
・・・中略・・・
平成25年3月19日付け手続補正は、この指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものであることは明らかである(補正の根拠等については平成25年3月19日付け意見書に詳述してある)。
審査官殿は、本件補正(平成25年3月19日付け手続補正)が、特許請求の範囲を拡張するものであるから、発明の限定的減縮を目的とするものでないことは明らかである旨指摘されているが、上記のように、本件補正は、実質的に明りょうでない記載の釈明を目的としたものであり、特許請求の範囲の限定的減縮には相当しないものであるとしても、それにより、補正の目的違反を問われるべきものではない。
因みに、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成24年12月13日付け拒絶理由通知(最後)のサポート要件違反(理由2)に問われることは必至であり、これを回避する補正を行った点を捉えて目的違反との指摘を行うことは、極めて形式的な判断であって、妥当性を欠くものであると言わざるを得ない。
更に付言すれば、本補正後の特許請求の範囲に記載された発明が進歩性欠如の理由(理由3)に該当しないことを以って、本補正が、新規性進歩性を主張することを目的として、発明特定事項を追加する補正であるなどとも指摘しているが、本補正の趣旨は上記のとおりであり、この点も同様に妥当性を欠く指摘と言わざるを得ない。

5.補正後の特許請求の範囲に記載された発明について
本請求人は、上述のように、本審判請求と同時に、平成25年3月19日付けの手続補正と同内容の手続補正を再度行った。
そして、平成25年3月19日付け意見書において詳述したように、この手続補正は、平成24年12月13日付け拒絶理由通知(最後)において指摘された単一性要件違反(理由1)、サポート要件違反(理由2)、進歩性欠如(理由3)を全て解消しているものである。

6.むすび
よって、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求める。 」


(8)平成25年8月16日付け手続補正
上記平成25年8月16日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとするものである。
『 【請求項1】
コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
前記アプリケーション・プログラム・インターフェースは:
前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
特定されたテキストの優先順位を示すフラグを受け取るように動作し、 前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す
ことを特徴とするコンピュータ・システム。
【請求項2】
請求項1に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは、話し速度を特定することを特徴とするコンピュータ・システム』

すなわち、上記平成25年8月16日付けの手続補正書は上記審判請求書記載のとおり、上記平成25年3月19日付け手続補正書と同内容の補正をしようとするものである。


(9)前置報告
上記平成25年10月4日付けで意見を求める旨の審尋において援用された前置報告書における報告の概要は以下のとおりである。
『この審判請求に係る出願については、下記の通り報告します。



出願人は、補正前の請求項1の「前記アプリケーション・プログラム・インターフェース」を
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する」
から
「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
特定されたテキストの優先順位を示すフラグを受け取るように動作し、
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」
と変更し、補正後の請求項1とする補正を行っている。

本件補正は、補正前の請求項1の「アプリケーション・プログラム・インターフェース」が「第1のインターフェース」と「第2のインターフェース」を具備している点や、「アプリケーション・プログラム・インターフェース」が「テキストを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「テキスト・ツゥ・スピーチ制御タグを含むバッファ」を受け取る点、「アプリケーション・プログラム・インターフェース」が「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、サイト情報構造への参照」を受け取る点、「アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する」点等を削除するものであって、上記の点について特許請求の範囲を拡張するものであるから、本件補正が発明の限定的減縮を目的とするものでないことは明らかである。

また、出願人は本件補正が実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものであり、『本補正後の特許請求の範囲に記載された発明が進歩性欠如の理由(理由3)に該当しないことを以って、本補正が、新規性進歩性を主張することを目的として、発明特定事項を追加する補正であるなどとも指摘しているが、本補正の趣旨は上記のとおりであり、この点も同様に妥当性を欠く指摘と言わざるを得ない。』と主張しているが、本件補正は、新規性進歩性を主張することを目的として、補正前の「アプリケーション・プログラム・インターフェース」を異なる内容に変更しているものであることは明らかである。

また、本件補正が、誤記の訂正、請求項の削除を目的とするものでないこも明らかである。

したがって、この補正は、特許法第17条の2第4項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第17条の2第4項の規定に違反するものであるから、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下されるべきものである。
そして、この出願は原査定の理由に示したとおり拒絶されるべきものである。』


(10)平成26年1月7日付け回答書
上記平成26年1月7日付けの回答書による回答の概要は以下のとおりである。
「【回答の内容】
1.平成25年10月4日付け(発送日;10月7日)審尋において、<前置報告の内容>について、本請求人の意見を求められた。
前置報告の内容は、概略以下のとおりである。
・・・中略・・・
2.本請求人は、上記前置報告の内容に承服できるものではない。以下、審査官殿のご指摘が妥当でないことを詳述する。

3. 本願発明について
審判請求時の補正による請求項1に係る発明(以下、「本願発明1」という。全請求項に係る発明を総称して、「本願発明」ということもある)を、分説すると以下のとおりである。なお、A,B等の符号は分説の便宜上付したもの、下線は審判請求時の補正個所を示すために付したものである。
A.コンピュータ・システムであって:
B.互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
C.前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと;
D.前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
E.前記アプリケーション・プログラム・インターフェースは:
E1.前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
E2.特定されたテキストの優先順位を示すフラグを受け取るように動作し、
E3.前記フラグは、
E31.再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
E32.別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
E33.別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す
A’.ことを特徴とするコンピュータ・システム。

4.前置報告の非妥当性について
前置報告の内容は、平成25年4月11日付け補正却下の決定と略同内容のものであり、その内容が妥当でないことは、審判請求書中においても詳述したところであるが、その要点を以下再述する。

4-1.手続の経緯
・・・中略・・・
4-2.平成25年4月11日付け補正却下の決定の非妥当性
平成25年8月16日付け審判請求書中においても指摘したように、本請求人は、後述するように、平成25年4月11日付けの補正却下の決定に承服するものではないが、取敢えず、この点を措き、本審判請求と同時に、平成25年3月19日付けで提出した手続補正書と同内容の手続補正書を提出し、平成24年6月12日付け手続補正書をベースに特許請求の範囲の記載を修正した。
そして、本出願人が、補正却下の対象となった平成25年3月19日付け手続補正を提出したのは、平成24年12月13日付け拒絶理由通知(最後)に対応するためのものであったところ、上記拒絶理由通知は、単一性要件違反(理由1)、サポート要件違反(理由2)、進歩性欠如(理由3)を指摘するものであった、
そして、上記理由中、サポート要件違反(理由2)の指摘内容は、以下のとおりのものであった。
『(a)請求項1-3に係る発明が、明細書のどの部分に対応するのか、また、日本語として明細書のどの部分に記載されているのか不明である。
したがって、本願請求項1-3に係る発明は、発明の詳細な説明中に記載も示唆もされていない。
(審査基準 第1部 第1章 明細書及び特許請求の範囲の記載要件 2.2.1.3 第36条第6項第1号違反の類型の (1)に該当する。)
よって、請求項1-3に係る発明は、発明の詳細な説明に記載したものでない。』
平成25年3月19日付け手続補正は、この指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に(拒絶理由通知に係る拒絶の理由に示す事項についてした)明りょうでない記載の釈明を目的とするものであることは明らかである(補正の根拠等については平成25年3月19日付け意見書に詳述してある)。
審査官殿は、平成25年3月19日付け手続補正が、特許請求の範囲を拡張するものであるから、発明の限定的減縮を目的とするものでないことは明らかである旨指摘されているが、上記のように、本件補正は、実質的に明りょうでない記載の釈明を目的としたものであり、特許請求の範囲の限定的減縮には相当しないものであるとしても、それにより、補正の目的違反を問われるべきものではない。
因みに、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成24年12月13日付け拒絶理由通知(最後)のサポート要件違反(理由2)に問われることは必至であり、これを回避する補正を行った点を捉えて目的違反との指摘を行うことは、極めて形式的な判断であって、妥当性を欠くものであると言わざるを得ない。

4-3.本前置報告の非妥当性について
審査官殿は、上記本請求人の指摘に対し、『本件補正が発明の限定的減縮を目的とするものでないことは明らかである』等の主張を繰り返しているが、上述のように、仮に審査官殿の指摘に従い上記削除された記述をそのまま残して更なる減縮等の補正を行ったとすれば、平成24年12月13日付け拒絶理由通知(最後)のサポート要件違反(理由2)に問われることは必至であり、審査官殿の指摘は、本願の補正の可能性を全て滅却するに等しい暴論というべきものであって、妥当なものではない。

5.むすび
以上のとおりであるから、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求めるものである。」


(11)平成26年3月10日付け審尋
上記平成26年3月10日付けの審尋の内容は概略以下のとおりである。
『1.平成25年8月16日付けの手続補正書による手続補正後の特許請求の範囲に記載される発明を特定するための事項(以下「発明特定事項」と記す。)が、本願明細書、本願の願書に最初に添付した明細書、特許請求の範囲及び図面、本願の原出願の願書に最初に添付した明細書、特許請求の範囲及び図面(特許法第184条の12第2項において、同法第17条の2第3項中の「願書に最初に添付した明細書、特許請求の範囲又は図面」とあるのを、これに読み替える旨規定されるものであるところの、平成12年9月25日付けの国際出願日における明細書、請求の範囲、図面の翻訳文))(以下、これらを「明細書等」と総称する。)の何処に記載されているどの事項に相当するのか? また、これら明細書等のどこのどの記載からどの様にして導き出される事項なのか?を詳細に説明されたし。
(平成25年3月19日付けの意見書においては、補正の根拠として、
「補正の根拠は、概略以下のとおりである。
(1)補正後の請求項1:明細書の段落〔0079〕(構成要件C)、〔表126〕、〔表127〕及び〔表130〕(構成要件E31?E33)
(2)補正後の請求項2:〔表181〕(構成要件G)」
としか記載されていないため、例えば
・「優先順位を示すフラグ」は明細書等の【表126】記載の「種類フラグ」「優先順位フラグ」の何れに相当するのか?双方に相当するのか?いずれにも相当しないのか?
・「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」とは、上記明細書等の記載のどの事項に相当するのか?どこのどの記載からどの様にして導き出される事項なのか?
・「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」とは、上記明細書等の記載のどの事項に相当するのか?どこのどの記載からどの様にして導き出される事項なのか?
・「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」とは、上記明細書等の記載のどの事項に相当するのか?どこのどの記載からどの様にして導き出される事項なのか?
等を明確に把握することができない。)

2.平成24年6月12日付けの手続補正書の特許請求の範囲の請求項1に記載の「アプリケーション識別子と、・・・(中略)・・・第1のインタフェース」「テキストを含むバッファと、・・・(中略)・・・第2のインタフェース」の本来の意味内容や上記明細書等のどの記載を表現しようとしたものなのか(「第1のインタフェース」は、本来は上記明細書等の【表124】?【表126】に記載される「IVoiceText::Register」のAPIを、同「第2のインタフェース」は本来は【表126】?【表127】に記載される「IVoiceText::Speak」のAPIを意味し、これらを表現しようとしたものなのではないのか? そうでないならば、上記「第1のインタフェース」「第2のインタフェース」は上記明細書等のどこに記載されるAPIを表現しようとしたものなのか?)を説明されたし。』


(12)平成26年5月16日付け回答書
上記平成26年5月16日付け回答書による回答の概要は以下のとおりである。
『【回答の内容】
1.平成26年3月10日付け(発送日;3月11日)審尋において、回答書の提出を求められた。
審尋の内容は概略以下のとおりである。
・・・中略・・・
2.審尋への対応
上記各ご指摘点についての対応は以下のとおりである。
(ア)補正後の請求項1の補正の根拠について
(ア-1)補正後の請求項1
上記審尋中で指摘を受けた補正後の請求項1を構成要件に分説すると、以下のとおりである。但し、A,B等の符号は分説の便宜上付したものである。
A.コンピュータ・システムであって:
B.互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
C.前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有するオペレーティング・システムと;
D.前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
E.前記アプリケーション・プログラム・インターフェースは:
E1.前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、
E2.特定されたテキストの優先順位を示すフラグを受け取るように動作し、
E3.前記フラグは、
E31.再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
E32.別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
E33.別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す
A’.ことを特徴とするコンピュータ・システム。

(ア-2)補正の裏付をなす明細書の記載(下線付加)
・段落〔0079〕
『3.スピーチ関連API
前記アドオン技術モジュールは、アプリケーション使用のためにAPIを露出するいくつかのスピーチ関連コンポーネントを含む。これらのコンポーネントは、テキスト・ツゥ・スピーチ・コンポーネント、音声からテキストへのコンポーネント、及び音声コマンド・コンポーネントを含む。一般的に、これらのコンポーネントは、入力及び出力装置が制限され、及びユーザの前記埋め込み型システムへの相互作用がスピーチを介する環境のためのものである。そのような環境の一例は、AutoPCである。前記ドライバは、自動車の操作中に手を使わなければならないので、AutoPCとの相互作用は、スピーチ・インターフェースを介する一方で、入力コマンドは、ユーザによって話され、及び前記PCからの出力は、テキストからスピーチに変換される。』

・表〔126〕
『パラメータ
pszSpeak
[in]話すためのテキストを含むバッファのアドレスである。・・・このパラメータによって指(定)された列は、テキスト・ツゥ・スピーチ制御タグを含むことができる。
dwFlags
[in]前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類のフラグと一つの優先順位フラグとの組み合わせである。
・・・
VTXTSP_HIGH
現在話されているテキストの後だが、再生待ち行列にあるいかなる他のテキストよりも前に、できるだけ早く前記テキストを再生する。
VTXTSP_NORMAL(注;VTXTSP_VERYHIGHの誤記である)
もしあれば、現在話されているテキストに割り込んで、迅速に前記テキストを再生する。割り込まれたテキストは、正しく同期されないかもしれないが、割り込まれたテキストは、たいへん高い優先順位のテキストが終わってからすぐに、再生を再開する。

・表〔127〕
『註
他のテキストが再生されている時に、アプリケーションがSpeakを呼び出す場合、前記特定されたテキストは、前記アプリケーションがdwFlagsにおけるより高い優先順位を特定しないかぎり、再生待ち行列の最後に加えられる。』

・表〔130〕
『註
・・・
前記VTXTSP_HIGH及びVTXTSP_VERYHIGH
優先順位列が、適切な位置で待ち行列に挿入されることができるように、前記オブジェクトは、個別のバッファにおける各呼び出しから、データを取っておく。
例えば、VTXTSP_VERYHIGHの優先順位列は、高い又は通常の優先順位列に割り込むかもしれない。割り込まれた列は、たいへん高い優先順位列が終わった後に再開する。この実行の結果。音声出力は一時停止されたので、IsSpeakingは、待ち行列における一つのバッファの終わりと、次のバッファの始まりとの間の短い時間にFALSEを戻す。』

(ア-3)ご指摘事項への対応

(イ)補正後の請求項2の補正の根拠
(イ-1)補正後の請求項2
上記審尋中で指摘を受けた補正後の請求項2は、以下のとおりのものである。
『請求項1に記載のコンピュータ・システムにおいて、
前記アプリケーション・プログラム・インターフェースは、話し速度を特定することを特徴とするコンピュータ・システム。』

(イ-2)補正の裏付をなす明細書の記載
・表〔181〕
『VTSITEINFO
音声装置、テキスト・ツゥ・スピーチ・モード、及び音声-テキスト・サイトに対する話す速度を特定し、及び、音声テキストが前記サイトに対して使用可能か不能かを示す。』

(イ-3)ご指摘事項への対応
・構成要件Cの「テキスト・ツゥ・スピーチ・コンポーネント」は、スピーチ関連APIとして段落〔0079〕に明示されている。
・構成要件E2の「優先順位を示すフラグ」は、表〔126〕に記載された「優先順位フラグ」に相当するものである。
構成要件E31?E33は、「優先順位フラグ」の内容に応じた制御内容を規定するものであり、以下詳述する。
・構成要件E31の「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」は、「優先順位フラグ」が「VTXTSP_VERYHIGH」の場合に該当するものである。この「VTXTSP_VERYHIGH」のケースは、〔表126〕、〔130〕の記載からも明らかなように、現在話されているテキストに割り込んで、「VTXTSP_VERYHIGH」フラグを付されたテキストを再生し、再生完了後に割り込まれたテキストの再生を再開する。
・構成要件E32の「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」は、例えば、「優先順位フラグ」が「VTXTSP_HIGH」の場合に該当するものである。この「VTXTSP_VERYHIGH」のケースは、〔表126〕の記載からも明らかなように、「VTXTSP_VERYHIGH」フラグを付されたテキストが、再生待ち行列の先頭に加えられるものである。なお、明示はないものの、優先順位が中位のケースに関しては、優先順位が中位のテキストが、その優先順位に応じた再生待ち行列の位置に格納されることになる。
・構成要件E33の「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」は、「優先順位フラグ」が「VTXTSP_NORMAL」の場合に該当するものである。この「VTXTSP_NORMAL」のケースは、〔表127〕の記載からも明らかなように、「VTXTSP_NORMAL」フラグを付されたテキストが、再生待ち行列の最後に加えられるものである。
以上説明したところにより、補正の根拠は明らかなものと思料する。

(ウ)平成24年6月12日付け手続補正書による補正の根拠について
平成24年6月12日付け手続補正書により補正された請求項1は、以下のとおりのものである。
・・・中略・・・
「第1のインターフェース」及び「第2のインターフェース」に関する御指摘に対する見解は以下のとおりである。
・明細書には、「第1のインターフェース」及び「第2のインターフェース」という用語に関する明示はない。
・「第1のインターフェース」に関しては、「サイト上の音声テキストを使用するためのアプリケーションの登録」(〔表124〕)、「通知インターフェース」、「インターフェース識別子」、「アプリケーションが全ての通知を受け取る予定か否かを示すフラグ」、「音声や会話速度等のサイトに適用する設定を含むサイト情報構造」(〔表125〕)、「アプリケーションは、IVoiceTextインターフェースを呼び出すことができる前に、Registerを呼び出さなければならない」(〔表126〕)等の開示はあるものの、上記請求項1の「第1のインターフェース」に規定される要件の全てが必ずしも明細書の記載に相応するものではない。
・「第2のインターフェース」に関しては、「優先順位フラグ」、「テキスト・ツゥ・スピーチ制御タグ」、「テキストの再生」(〔表126〕)等の開示があり、上記請求項1の「第2のインターフェース」に規定される要件が概略開示されている。

3.むすび
以上のとおりであるから、原査定を取り消す、本願発明はこれを特許すべきものとする、との審決を求めるものである。』



第2.先行技術文献・引用発明

1.原審引用文献
本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成24年12月13日付けの拒絶理由通知書の理由3において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。)


<引用文献1>
特開平8-263259号公報(平成8年10月11日出願公開)

<引用文献記載事項1-1>
「【特許請求の範囲】
【請求項1】 マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも1以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも1以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備えることを特徴とする読み上げ装置。
【請求項2】 前記判定部は登録されたアプリケーションの中から、アクティブウインドウに移行したアプリケーションに対して、音声出力が可能な状態か否かの判定を行なうことを特徴とする請求項1記載の読み上げ装置。
【請求項3】 登録手段はアプリケーションの実行ファイル名を登録することを特徴とする請求項1記載の読み上げ装置。
【請求項4】 前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行うことを特徴とする請求項1記載の読み上げ装置。」

<引用文献記載事項1-2>
「【0001】
【産業上の利用分野】本発明はアプリケーションがディスプレイに表示したテキストを音声合成して出力する情報処理装置に関し、特にマルチウインドウシステムに対応した読み上げ装置に関する。」

<引用文献記載事項1-3>
「【0010】本発明はこのような点にかんがみて、操作規約を規約化することで操作の簡便化を図り、初心者ユーザが容易に利用できる音声出力機能を提供することを目的とし、また、音声出力機能を容易にアプリケーションに付与できる手段を提供することを目的とする。」

<引用文献記載事項1-4>
「【0019】図3は本発明の実施例構成ブロック図である。図において、10はキーボードやマウス等の入力指示具を含む実行ファイル名登録部、20は登録テーブル、30はシステム状態監視部、40は読み上げ判定部、50はクリップ要求発行部、60は複写部、61はテキスト、71はクリップボード、81は音声出力対象抽出部、82はテキストバッファ、83は音声データ変換部、84は音声バッファ、91は音声出力制御部、92は音声出力装置、200はウインドウシステムであり、その他同番号は同ー物を示す。」

<引用文献記載事項1-5>
「 【図3】



<引用文献記載事項1-6>
「 【図4】




<引用文献2>
近藤玲史,「パソコン向け音声認識合成プラットフォームの構築とアプリケーションの試作」,情報処理学会 第53回(平成8年後期)全国大会講演論文集(2) 平成8年9月4日?6日」,日本,社団法人情報処理学会,平成8年9月6日,p.2-363?2-364

<引用文献記載事項2-1>
「2. 音声認識合成プラットフォームとエンジン
2.1 プラットフォーム
音声認識合成の機能を提供するプラットフォームを用いることで、アプリケーションに同機能を付加することが容易に可能となる。このプラットフォームとして、音声認識・合成エンジンおよびAPIを提供する(図1)。
本プラットフォームにおけるAPIは、OSの定義する標準的な呼び出し方法に従っており、プログラミング上の特別な習熟の負担が少ない。」(2-363頁左欄第14行?右欄第1行)

<引用文献記載事項2-2>


」(2-363頁左欄)

<引用文献記載事項2-3>


」(2-363頁右欄)

<引用文献記載事項2-4>
「2.2 音声認識合成エンジン
本エンジンの基本仕様を表1に示す。
音声合成エンジンは、発声速度に依存しない韻律的特徴を用いることで自然なイントネーションやリズムを実現している。また、音声生成においては、波形編集方式を用いて少ない演算量で高い明瞭性を得ている[1]。
音声認識エンジンは、独自の半音節モデルを用いた混合ガウス分布HMMにより、不特定話者の連続単語認識が可能となっている。また話者適応を行い、高い認識率を得ている[2]。
さらに、本エンジンでは以下のような機能を強化している。
・OSの標準的な呼び出し手段に従ったAPI
・マルチタスク・マルチスレッド対応
本エンジンは、複数のアプリケーションから同時にロードされてマルチタスクで動作することができる。例えば、あるアプリケーションがパソコンに繋いだスピーカとマイクロフォンを使って音声対話を行っているのと同時に、システムのエージェントが電話回線に応答メッセージを送出するなどの使い方が可能である。
また、例えばあるアプリケーションにおいて、通常は男声の音声合成音を出力していて女声のヘルプメッセージが任意の時点に割り込む場合、従来のエンジンではヘルプの割り込み開始時点での話者情報を保存し、話者を変更してヘルプを女声で発声し、その後また話者を元に戻さねばならず、繁雑であった(図2)。本エンジンにおいては、アプリケーションの初期化時に男声および女声の音声合成エンジンのインスタンスを、男声オブジェクト・女声オブジェクトとして生成する。その後、男声で発声したい場面では男声オブジェクトに、女声で発声したい場面では女声オブジェクトにテキストを送ることで、直前の発声に影響されずに指定した声質(話者、ピッチなど)で発声を行うことができる。」(2-363頁右欄第2行?2-364頁左欄第14行)

<引用文献記載事項2-5>


」(2-364頁左欄)


2.参考文献
本願の出願前かつ上記優先日よりも前に頒布された下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。(下線は当審付与。)

<参考文献1>
特開平1-263734号公報(平成1年10月20日出願公開)

<参考文献記載事項1-1>
「システム内のすべてのタスクにとって使用可能なすべてのセグメントに対して使用されるテーブル6を、大域記述テーブル(GDT)と呼ぶ。IBM社のOS/2オペレーティング・システムのシステム・アーキテクチャ構造を示す第2図を参照すると、アプリケーションはアプリケーション・プログラム・インターフェース(API)11を使って、オペレーティング・システムにアクセスする。このシステムは、マルチ・タスク及び動的リンク機能を特徴とするオペレーティング・システムを示すものであり、その他の例には、AIX及び幾つかのバージョンのUNIXがある。以下で使用されるオペレーティング・システムという用語はこのようなシステムを指すものである。」(第4頁下左欄第12行?同頁下右欄第5行)

<参考文献記載事項1-2>
「オペレーティング・システム・カーネル・コード15及び共通サブシステム・サービス13に対するAPIのため必要とされるセグメントが、GDTに含まれている。オペレーティング・システムを拡張可能に設計する1つの方法は、アプリケーション10がそれら自体のサブシステム14を書いて、それらのAPI12をオペレーティング・システムの論理的拡張部分にすることができるようにすることである。これらのサブシステムにとって必要なセグメントもGDTに含まれる。」(第4頁下右欄第16行?第5頁上左欄第5行)

<参考文献記載事項1-3>


」(第10頁)


<参考文献2>
星光行,『インターラクティブ・デジタルTV用ソフトウェア「DAVID」』,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,平成6年8月2日,第94巻,第191号,P.1-7

<参考文献記載事項2-1>
「OS-9の特徴は、その性能もさることながら、モジュラ構造という世界に先駆けて開発したそのユニークな構造にある。OSを構成する要素を機能別にそれぞれ独立したモジュールという単位に分け、それらを自由に組み合わせて使用できるところにある。さらに、これらのモジュールは、すべてダイナミック・リンクになっていて、いつでも追加、削除ができる。したがって、サイズも小さく、用途に応じてモジュールを追加することでOSの機能を拡張できる。」(第3頁左欄第5行?第15行)


<参考文献3>
中川雅博編,「月刊コンピュータ・ダイジェスト」,第24巻,第3号,日本,株式会社ティ・エー・シー企画,平成10年3月10日,P.15

<参考文献記載事項3-1>
「【シリコンバレー8日=町田敏生】米マイクロソフトは自動車向け車載用コンピューター市場に参入する。今春出荷予定の携帯端末用OS(基本ソフト)の最新版「ウィンドウズCE2.0」を車載用にも適用、クラリオンなど日米のメーカーにライセンス供給を始める。また従来版に音声認識や手書き入力の機能を追加し、小型携帯端末OSとしても供給する。新OSでウィンドウズOSの領域を一段と広げる。」


<参考文献4>
特開平8-46935号公報(平成8年2月16日出願公開)

<参考文献記載事項4-1>
「【0019】図2は、図1に示す処理ユニット40により実行されるソフトウェア200の構造を示す。図2はオーディオ・ビデオ対話型処理マルチタスク・オペレーティングシステムを構成する主なソフトウェア・コンポーネントを示す。図2を説明する。コンポーネントは全てROM414に貯えられる。ただし、黒く塗られたアプリケーション・プログラムは除く。アプリケーション・プログラムは、オーディオ・ビデオ対話型信号のデータコンポーネントにより運ばれ、放送ロケーションから受信され、RAM412に貯えられる。図2に示すソフトウェア・コンポーネントは、実行可能なコードおよび関連する定数データを表す。コードが実行されると、変数データを生成し、変数データにアクセスする。変数データはRAM412に貯えられる。
【0020】提案されたオーディオ・ビデオ対話型放送システムでは、例えば、異なる製造業者からの異なる命令セットを用いて、異なるデコーダはCPUを使用することができる。このシステムでは、アプリケーション・プログラムは、プロセッサに無関係な中間コードである。各デコーダのソフトウェアは、アプリケーション中間コードを解釈するコンポーネント(INTERPRETER:インタプリタ)を含む。インタプリタにより、放送されたアプリケーション・プログラムは、どのような形式のCPU410を含むデコーダ上でも実行することができる。このインタープリタは、RAM412からオーディオ・ビデオ対話型データコンポーネント命令を中間コードの形で読み出し、メモリを操作し、API(application program interface)を介して、他のソフトウェア・コンポーネントを介してハードウェアと対話する。このAPIは、基本的には、アプリケーション・プログラムで利用可能なサブルーチンのリストであって、サブルーチンを呼び出すのに必要な情報である。APIはアプリケーション・プログラムにより発行され、デコーダ要素をアクセスするために、アプリケーション・プログラムにより使用することができる。」

<参考文献記載事項4-2>
「【0025】さらに、システムローダは引き続きデータコンポーネント・パケットサービスをスキャンし、伝送されたディレクトリ・モジュールと、RAM412内の現在のディレクトリ・モジュールとを比較する。伝送されたディレクトリ・モジュールがRAM412に格納されているディレクトリ・モジュールと異なる場合、データコンポーネント・パケットサービスが変更されたこと、例えば、視聴者がチャンネルを変えたときとか、対話型コマーシャルが放送されているときのようなことを示す。この場合、メッセージが、イベントマネジャを介して、APIを用いて、アプリケーション・プログラムに送られる。このメッセージに応答して、アプリケーション・プログラムは全ての資源の割り振りを解除し、処理要素40内に最小限存在するように維持する。例えば、コードモジュールとデータモジュールの全てを格納するために使用されるメモリを解放することができ、アプリケーションの実行状態だけがRAM412に保たれる。アプリケーション・プログラムの最小化が完了すると、メッセージがシステムローダに送られる。」

<参考文献記載事項4-3>
「【0031】また、フロー・オペレーティング・システムはコールしたアプリケーション・プログラムに直ちに戻る。次いで、アプリケーション・プログラムは他の処理、例えば、他のモジュールのリクエストを発し、他の初期化等の処理を実行することができる。リクエストされたモジュールへのアクセスが必要とされると、アプリケーション・プログラムは、ブロック304にて、カーネル内の待ち機能にAPIコールを発する。この機能により、リクエストされたモジュールのロードが成功したことを示すメッセージが、そのアプリケーション・プログラムにより受信されるまで、アプリケーション・プログラムの実行は中断させられる。そのようなメッセージが受信されると、アプリケーション・プログラムは再びアクティベートされ、そのメッセージを処理する。あるいはまた、例えば、より速くユーザ入力に応答するため、アプリケーション・プログラムはアクティブのままであり、そのメッセージキューを周期的にポーリングし、リクエストされたモジュールロードの成功を示すメッセージをチェックし、そのメッセージが受信されたとき、メッセージを処理するようにしてもよい。」

<参考文献記載事項4-4>
「 【図2】




<参考文献5>
特開昭64-59598号公報(平成1年3月7日出願公開)

<参考文献記載事項5-1>
「2.特許請求の範囲
プラント等の異常状態に対応するメッセージ表示要求情報に従い、該当するメッセージを複数のメッセージの中から選択して表示出力するメッセージ出力方式において、
前記メッセージ表示要求情報は表示の優先度をそれぞれ有し、表示要求にかかるメッセージの優先度が現在表示中のメッセージの優先度よりも高い場合に表示要求にかかるメッセージを優先的に表示し、表示要求にかかるメッセージの優先度が現在表示中のメッセージの優先度に等しいかまたはこれよりも低い場合には表示要求にかかるメッセージを表示待ちメッセージとして保持すると共に、現在表示中のメッセージの優先度に応じて予め設定された最低表示時間内においては、このメッセージよりも高い優先度のメッセージのみを表示することを特徴とするメッセージ出力方式。」(第1頁下左欄第4行?同頁下右欄第1行)

<参考文献記載事項5-2>
「また、現在表示中のメッセージは、前記優先度に応じて予め設定された最低表示時間の表示が原則的に確保される。この最低表示時間内に現在表示中のメッセージよりも優先度の高いメッセージにつき表示要求があった場合には、現在のメッセージの表示を中断して表示要求された優先度の高いメッセージが表示される。この場合、必要に応じて表示が中断されたメッセージを再表示することもできる。」(第2頁下左欄第9行?第17行)

<参考文献記載事項5-3>
「まず、上記の例では最も優先度の高いメッセージAの表示要求が最初に発生しているため、このメッセージAは、先の第1表に従って優先度1に対応する最低表示時間t_(1)の間、表示され続け、この間、メッセージB?Dの表示要求情報が優先度判定処理部1に順次送り込まれる。一方、現表示メッセージAにかかる情報は現表示メッセージ情報テーブル2に格納され、メッセージB?Dの表示要求情報は、各々の優先度がメッセージAの優先度と比較されてすべての優先性が否定されたうえ、メッセージB?D内で優先度の高い順、また同一優先度であれば表示要求の早い順に待ち行列管理され、各々の最低表示時間が待ち行列管理部3により付加されたうえで待ち行列管理テーブル5に表示待ちメッセージ情報として格納される。」(第3頁下右欄第16行?第4頁上左欄第10行)

<参考文献記載事項5-4>
「一方、表示要求にかかるメッセージの表示が不可能である場合には、最低表示時間テーブル4を参照してそのメッセージの優先度に応じた最低表示時間を取り出し(同S11)、これを付加した情報を表示待ちメッセージ情報として待ち行列管理テーブル5に組み込む(同S12)。なお、ステップS12において、同一優先度の表示待ちメッセージ情報が既にある場合には、今回の表示待ちメッセージ情報が最後尾に組み込まれる。」(第4頁上右欄第10行?第18行)


<参考文献6>
実願昭63-163275号(実開平2-83600号)のマイクロフィルム(平成2年6月28日発行)

<参考文献記載事項6-1>
「2.実用新案登録請求の範囲
(1)制御ステーション側から与えられた音声出力要求に従って外部へ音声メッセージを出力する音声出力駆動装置において、前記音声出力要求より音声情報及びそのレベル情報を音節定義ファイルから読み出してこのレベル毎に設定されている記憶領域に格納する格納手段と、新たに与えられた音声出力要求レベルが現在出力中の音声メッセージに設定されているレベルより高い場合は現在出力中の音声メッセージの出力を中断して新たに与えられた音声出力要求に対応する音声メッセージを出力指定する出力指定部とを有することを特徴とする音声出力駆動装置。」(明細書第1頁第4行?第16行)

<参考文献記載事項6-2>
「読み出し部421はこのレベル情報を参照してこのレベル毎に設定されている記憶領域mi(i=0,1,2,3のいずれか)にこの音声情報を格納する。この記憶領域はQueと呼ばれ、FIFOによって構成される。」(明細書第7頁第5行?第9行)


3.引用発明の認定
(1)引用文献1は上記引用文献記載事項1-3記載のとおり「操作規約を規約化することで操作の簡便化を図り、初心者ユーザが容易に利用できる音声出力機能を提供することを目的とし、また、音声出力機能を容易にアプリケーションに付与できる手段を提供することを目的とする」「読み上げ装置」に関する発明を説明する文献であるところ上記引用文献記載事項1-1の【請求項1】より、該「読み上げ装置」として
「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも1以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも1以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える読み上げ装置」
が記載されていると言える。

(2)同じく上記引用文献記載事項1-1の【請求項3】等より、引用文献1には、
「前記登録手段はアプリケーションの実行ファイル名を登録するもの」
であることも記載されていると言える。

(3)同じく上記引用文献記載事項1-1の【請求項4】等より、引用文献1には、
「前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行うもの」
であることも記載されていると言える。

(4)さらに、上記引用文献記載事項1-4、1-5等から、
「前記登録手段、状態監視部、判定部、要求制御部、音声変換出力手段はウインドウシステム上で動作するもの」
であると言える。

(5)よって、引用文献1には、下記引用発明が記載されていると認められる。

<引用発明>
「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも1以上のアプリケーションによる実行画面を有するシステムであって、
実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段と、
ウインドウで起動された少なくとも1以上のアプリケーションの状態を監視する状態監視部と、
前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定する判定部と、
前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、
前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える読み上げ装置であって、
前記登録手段はアプリケーションの実行ファイル名を登録するものであり、
前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行うものであり、
前記登録手段、状態監視部、判定部、要求制御部、音声変換出力手段はウインドウシステム上で動作するものである
読み上げ装置。」



第3.平成25年8月16日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]
平成25年8月16日付けの手続補正を却下する。


[理由]
1.本件補正の内容
平成25年8月16日付けの手続補正(以下「本件補正」と記す。)は、特許請求の範囲について、上記第1.(1)の平成24年6月12日付けの手続補正書に記載の特許請求の範囲から、上記第1.(8)の平成25年8月16日付けの手続補正書記載の特許請求の範囲に補正しようとするものである。


2.新規事項追加禁止要件
本件補正について検討するに、補正後の請求項1に記載される
「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」
との技術的事項は、本願の願書に最初に添付した明細書、特許請求の範囲又は図面には記載されておらず、また当初明細書等の記載からみて自明な事項でもない。
なお、請求人は、平成25年3月19日付け意見書や平成26年5月16日付け回答書において、平成25年3月19日付け手続補正の根拠として【表126】、【表127】及び【表130】を挙げている。そこで当該表の記載を検討するに、請求人が平成26年5月16日付け回答書の【回答の内容】2.(イ-3)で説明するとおり、「優先順位を示すフラグ」は、【表126】に記載された「優先順位フラグ」に相当するものであると認められる。しかしながら、【表127】及び【表130】の記載から「テキスト」が「再生待ち行列の最後に加えられる」ことや「適当な位置で待ち行列に挿入されること」などに「優先順位」が関与していることは認められるものの、【表126】の記載によれば、現在話されているテキストに割り込んで再生をするか、現在話されているテキストの後に再生するかを決めるのは、「優先順位フラグ」ではなく「種類フラグ」である。
すなわち、「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと」と、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」と、「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」の「何れか1つを表す」「優先順位を示すフラグ」は【表126】、【表127】及び【表130】のどこにも記載されていない。
また、当初明細書等の他の箇所を参酌しても、このような3つの再生態様を示す「優先順位を示すフラグ」を直接的にも間接的にも示唆する記載は見あたらない。
すなわち、当初明細書等のすべての記載を総合しても、上記の技術的事項を導き出し得るものではなく、本件補正は、当初明細書等の記載の範囲内においてするものではない。

したがって、本件補正は、特許法第17条の2第3項の規定に違反する。


3.目的要件
本件補正は、上記第1.1.のとおり本件審判の請求と同時にする補正であり、上記第1.(8)のとおり特許請求の範囲についてする補正をしようとするものであるから、以下に、本件補正の目的について検討する。

3-1.補正事項の分析

(1)本件の請求項1に係る補正は、
本件補正前の請求項1の「前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと;」との記載を削除し、
本件補正前の請求項1の「スピーチ・ツゥ・テキスト・コンポーネントを有する前記オペレーティング・システムと;」との記載を「テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースを有する」に変更するとともに、本件補正後の請求項1における「前記アプリケーション・プログラム・インターフェースは:」との記載の後に「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信し、」との記載を追加する補正をしようとするものであり、これは次の補正事項に分けてとらえることができる。

<補正事項1>
本件補正前の請求項1の「スピーチ・ツゥ・テキスト・コンポーネント」を、「テキスト・ツゥ・スピーチ・コンポーネント」に変更する補正。

<補正事項2>
本件補正前の請求項1の「前記アプリケーション」を、「前記アプリケーション・プログラム」に変更する補正。

<補正事項3>
本件補正前の請求項1における「オペレーティング・システム」が「有する」ものであった「スピーチ・ツゥ・テキスト・コンポーネント」を、「オペレーティング・システム」が「有する」ものから削除する補正。

<補正事項4>
本件補正前の請求項1においては単に「コンピュータ・システム」が「具備」するものであった「前記スピーチ・ツゥ・テキスト・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェース」との記載箇所を変更し、「テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェース」を「オペレーティング・システム」が「有する」ものとし、「前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信」するものである旨を「前記アプリケーション・プログラム・インターフェースは:」との記載の後に移動させる補正。

(2)本件の請求項1に係る補正は、さらに、
本件補正前の請求項1における
「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する、」
との記載を
「特定されたテキストの優先順位を示すフラグを受け取るように動作し、
前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」
との記載に変更する補正をしようとするものであり、これは次の補正事項に分けてとらえることができる。

<補正事項5>
本件補正前の請求項1におけるアプリケーション・プログラム・インターフェースが「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェース」を具備するものである旨の記載を削除するとともに、本件補正前の請求項1における「第2のインターフェース」に関する限定を「アプリケーション・プログラム・インターフェース」に関する限定に変更する補正。

<補正事項6>
本件補正前の請求項1における「第2のインターフェース」が「受け取」るものから「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」を削除する補正。

<補正事項7>
本件補正前の請求項1における「前記テキストの種類を示す優先順位フラグ」「を受け取」る旨の記載を「特定されたテキストの優先順位を示すフラグを受け取るように動作し」との記載に変更する補正。

<補正事項8>
本件補正前の請求項1における「前記テキストを含むバッファを音声出力に変換するようにさせる」旨の記載を削除するとともに、前記「フラグ」に関し、
「前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」との限定を追加する補正。


(3)また、本件補正後の請求項2に係る補正は、次の補正事項よりなるものと捉えることができる。

<補正事項9>
本件補正前の請求項2、請求項4?請求項8を削除し、請求項3を請求項2に変更する補正。

<補正事項10>
本件補正前の請求項3におけるアプリケーション・プログラム・インターフェースが、
「前記現在のスピーチ状態を示すフラグを戻す第6のインターフェースと;」
「現在の話し速度を戻す第8のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき音声を示す第1の音声識別子を受け取る第9のインターフェースと;
前記テキスト・ツゥ・スピーチ・コンポーネントによって使用されるべき前記現在の音声を示す第2の音声識別子を戻す第10のインターフェースと;」
を含むものである旨の記載を削除する補正。

<補正事項11>
本件補正前の請求項3におけるアプリケーション・プログラム・インターフェースが
「第1の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第1の話し速度でテキストを出力するようにさせる第7のインターフェース」
を含むものである旨の記載を
本件補正後の請求項2における
「前記アプリケーション・プログラム・インターフェースは、話し速度を特定する」
との記載に変更する補正。


3-2.上記各補正事項の目的について、以下に検討する。

(1)補正事項1について
本件補正前の請求項1における「スピーチ・ツゥ・テキスト・コンポーネント」との記載は、当該記載箇所以外の本件補正前の請求項1の記載などから見て、本来は「テキスト・ツゥ・スピーチ・コンポーネント」と記載すべきものの誤記であることは明らかである。
したがって、上記補正事項1は誤記の訂正を目的とするものである。

(2)補正事項2について
本件補正前の請求項1における「前記アプリケーション」との記載は、当該記載箇所以外の本件補正前の請求項1の記載などから見て、本来は「前記アプリケーション・プログラム」と記載すべきものの誤記であることは明らかである。
したがって、上記補正事項2は誤記の訂正を目的とするものである。

(3)補正事項3について
ア.補正事項3が請求項の削除を目的とするものでないことは明らかである。

イ.本件補正前の請求項1においては、「オペレーティング・システム」は「テキスト・ツゥ・スピーチ・コンポーネント」「を有する」ものに限定されたものであったところ、上記補正事項3によって、本件補正後の請求項1における「オペレーティング・システム」は、必ずしも「テキスト・ツゥ・スピーチ・コンポーネント」を有するものでは無くなった。
したがって、上記補正事項3は明らかに特許請求の範囲を拡張するものであり、特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項(以下「発明特定事項」とも記す。)を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)(以下、単に「限定的減縮」と記す。)を目的とするものではない。

ウ.また、「オペレーティング・システム」が「コンポーネント」「を有する」旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項1の「コンポーネントを有する」との記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
したがって、上記補正事項3は誤記の訂正を目的とするものでもない。

エ.また、「オペレーティング・システム」が「コンポーネント」「を有する」ことは、何ら不明瞭な記載ではなく、また、本願の発明の詳細な説明にも裏付けられている事項であることは明らかである。
したがって、上記補正事項3は明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)(以下、単に「不明瞭な記載の釈明」と記す。)を目的とするものではない。

オ.よって、上記補正事項3の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。

(4)補正事項4について
上記補正事項4は、本件補正前には「アプリケーション・プログラム・インターフェース」は単に「コンピュータ・システム」が「具備」しているものであったものを、本件補正後には「オペレーティング・システム」がアプリケーション・プログラム・インターフェースを有する」ものとするものであるから「アプリケーション・プログラム・インターフェース」あるいは「オペレーティング・システム」を概念的に下位のものに限定する補正であり、これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
したがって、上記補正事項4の目的は、限定的減縮と解することができる。

(5)補正事項5について
ア.補正事項5が請求項の削除を目的とするものでないことは明らかである。

イ.本件補正前の請求項1においては、「アプリケーション・プログラム・インターフェース」は「アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーションを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェース」を具備するものに限定されたものであったところ、上記補正事項5によって、本件補正後の請求項1における「オペレーティング・システム」は、必ずしも該「第1のインターフェース」を有するものでは無くなった。
したがって、上記補正事項5は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。

ウ.また、「アプリケーション・プログラム・インターフェース」がこのような「第1のインターフェース」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項1の「アプリケーション・プログラム・インターフェース」がこのような「第1のインターフェース」を含む旨の記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
したがって、上記補正事項5は誤記の訂正を目的とするものでもない。

エ.また、発明の詳細な説明を参酌すれば該「第1のインターフェース」とは本来は【表124】?【表126】に記載される「IVoiceText::Register」のAPIを意味するものであったことは明らかであり、「アプリケーション・プログラム・インターフェース」がこのような「第1のインターフェース」を含む旨の発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
したがって、上記補正事項5は不明瞭な記載の釈明を目的とするものではない。

オ.よって、上記補正事項5の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。

(6)補正事項6について
ア.補正事項6が請求項の削除を目的とするものでないことは明らかである。

イ.本件補正前の請求項1においては、「第2のインターフェース」は「優先順位フラグ」だけでなく「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取るものに限定されていたところ、上記補正事項6によって、本件補正後の請求項1における「アプリケーション・プログラム・インターフェース」は、必ずしも「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取るものでは無くなった。
したがって、上記補正事項6は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。

ウ.また、「第2のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載自体は、文法的あるいは技術的に格別不適切なものではなく、本件補正前の請求項1の「第2のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
したがって、上記補正事項6は誤記の訂正を目的とするものでもない。

エ.また、「バッファ」自体を受け取る旨の表現は発明の詳細な説明との対応関係に関して不整合はあるものの、発明の詳細な説明を参酌すればこの表現が本来は「アプリケーション・プログラム・インターフェース」が「バッファ」のアドレスを受け取ることに対応する記載であることは明らかであり、このような「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
したがって、上記補正事項6は不明瞭な記載の釈明を目的とするものではない。

オ.よって、上記補正事項6の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。

(7)補正事項7について
ア.本件の発明の詳細な説明の【表126】の「dwFlags」の説明における「前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類フラグと1つの優先順位フラグとの組合わせである。」との記載等からみて、「優先順位フラグ」は「テキストの種類を示す」フラグではなく、「優先順位」を示すフラグであることは明らかである。

イ.これに対し、本件補正前の請求項1においては「第2のインターフェース」が受け取る「優先順位フラグ」は「テキストの種類を示す」ものであるから、本件補正前の請求項1に係る発明は発明の詳細な説明に記載されているものではなく、このことは原審拒絶理由の2.に該当する不明瞭な記載と言えるものである。

ウ.そして、補正事項7は該不明瞭な記載をあらため、本件補正後の請求項1における「アプリケーション・プログラム・インターフェース」が受け取る「フラグ」を「特定されたテキストの優先順位を示す」ものと言う、本来の意味を明らかにする補正であると言える。

エ.したがって、上記補正事項7の目的は、不明瞭な記載の釈明と解することができる。

(8)補正事項8について
上記補正事項8によって、本件補正前の請求項1に係る発明の発明特定事項であった前記「フラグ」を「再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」フラグと言う概念的に下位のものに限定する補正であり、これによって当該発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
したがって、上記補正事項8の目的は、限定的減縮に該当する。

(9)補正事項9について
上記補正事項9の目的は、請求項の削除に該当する。

(10)補正事項10について
ア.補正事項10が請求項の削除を目的とするものでないことは明らかである。

イ.補正事項10は補正前の請求項3に記載されていた発明特定事項である「第6のインターフェース」「第8のインターフェース」「第9のインターフェース」「第10のインターフェース」を削除するものであるから限定的減縮にも該当しない。

ウ.「アプリケーション・プログラム・インターフェース」がこれら「第6のインターフェース」「第8のインターフェース」「第9のインターフェース」「第10のインターフェース」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項3の該記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
したがって、上記補正事項10は誤記の訂正を目的とするものでもない。

エ.また、「アプリケーション・プログラム・インターフェース」がこれら「第6のインターフェース」「第8のインターフェース」「第9のインターフェース」「第10のインターフェース」を含む旨の発明特定事項に格別不明瞭な点は見当たらず、また、該発明の詳細な説明にも裏付けられていることであるから、当該発明特定事項そのものを削除する補正を不明瞭な記載の釈明と認めることはできない。
したがって、上記補正事項10は不明瞭な記載の釈明を目的とするものではない。

オ.よって、上補正事項10の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。

(11)補正事項11について
ア.補正事項11が請求項の削除を目的とするものでないことは明らかである。

イ.本件補正前の請求項3においては「第7のインターフェース」が「第1の話し速度を受け取り」、「前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第1の話し速度でテキストを出力する」ものであったのに対し、上記補正事項11によって、本件補正後の請求項2においては必ずしも「第7のインターフェース」が「話し速度」を含むものではなく、しかも「アプリケーション・プログラム・インターフェース」は「話し速度」を「特定」するものの「話し速度でテキストを出力する」ものではなくなったのであるから、上記補正事項11は明らかに特許請求の範囲を拡張するものであり、限定的減縮を目的とするものではない。

ウ.本件補正前の請求項3における「第7のインターフェース」が「第1の話し速度を受け取り」、「前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第1の話し速度でテキストを出力する」を含む旨の記載自体は、文法的にも技術的にも十分に意味の通じる記載であって、何ら不適切なものではなく、本件補正前の請求項3の該記載が、本来は他の事項を記載すべき誤記であったとは到底言えない。
したがって、上記補正事項11は誤記の訂正を目的とするものでもない。

エ.また、「アプリケーション・プログラム・インターフェース」が「第1の話し速度を受け取り、前記テキスト・ツゥ・スピーチ・コンポーネントが、前記第1の話し速度でテキストを出力するようにさせる第7のインターフェース」を含む旨の発明特定事項に格別不明瞭な点は見当たらず、また、該発明の詳細な説明にも裏付けられていることであるから、上記補正事項11は不明瞭な記載の釈明を目的とするものではない。

オ.よって、上記補正事項11の目的は、請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しない。

(12)請求人の主張について
なお、上記補正事項5、6等に関連して、審判請求書や平成26年1月7日付けの回答書において、平成25年3月19日付け手続補正は、原審拒絶理由通知書で指摘されたサポート要件違反の指摘に対し、特許請求の範囲の記載を明細書の記載により裏付けられるように明確化したものであり、実質的に明りょうでない記載の釈明を目的とするものである旨の主張がなされている。
しかしながら、「明瞭でない記載の釈明」とは、明細書、特許請求の範囲又は図面中のそれ自体意味の不明瞭な記載、又は、明細書、特許請求の範囲又は図面中の他の記載との関係で不合理を生じているために不明瞭となっている記載等、明細書、特許請求の範囲又は図面に生じている記載上の不備を訂正し、その本来の意を明らかにすることをいうのであって、本件補正の如き発明特定事項の削除によって実質的に請求の範囲の拡張や変更を行う補正までもが、「その本来の意を明らかにすること」を目的とした補正であると認めることは到底できない。
また、特許法第17条の2第4項の規定の趣旨は、既に行われた審査の結果を有効に活用できる範囲内のものとすることにあるのであるから、当該規定における「明りょうでない記載の釈明」は、審査・審理の対象を変更するものであってはならないのであって、単に記載要件に関する拒絶理由を回避することを目的とした補正を全て「明りょうでない記載の釈明」であると認めることは、当該規定の趣旨に反する。
よって、上記請求人の主張は到底認め得るものではない。

(13)まとめ
以上のとおり、上記補正事項9の目的は請求項の削除、上記補正事項4、8の目的は限定的減縮、上記補正事項1、2の目的は誤記の訂正、上記補正事項7の目的は不明瞭な記載の釈明であるものの、上記補正事項3、5、6、10、11の目的は請求項の削除、限定的減縮、誤記の訂正、不明瞭な記載の釈明の何れにも該当しないものである。


3-3.小結
以上のとおりであるから、本件補正は、特許法第17条の2第4項第1号の請求項の削除、同条同項第2号の特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)、同条同項第3項の誤記の訂正、同条同項第4項の明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)を目的とするものに限られるものではない。

したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反する。


4.独立特許要件

本件補正は、限定的減縮を目的とする上記補正事項4、8を含むものである。そこで、本件補正後の請求項1に記載されている事項により特定される発明(以下、「本件補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか否かについて、以下に検討する。


4-1.特許法第36条(記載要件)について

(1)上記2.で述べたとおり、「前記フラグは、
再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、
別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、
別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表すこと」は当初明細書等のすべての記載を総合しても、導き出し得るものではない。
そして、本願の発明の詳細な説明及び図面に対しては出願の後に補正はなされていない。
してみると、本件補正後の請求項1?2に係る発明は、本件補正後の発明の詳細な説明に記載されていないものである。
また、このため、本件補正後の発明の詳細な説明は、本件補正後の請求項1?2に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項の経済産業省令で定めるところによる記載がされていないものであるとも言える。

(2)本件補正後の請求項1においては「フラグ」は、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」と「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」の「何れか1つを表す」旨の発明特定事項の記載があるところ、「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること」は「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること」に対して、概念的に上位の事項を意味しており、「フラグ」がこれら上位と下位の「何れか1つを表す」とは、如何なる対応付けを意味するのかが不明で(前者では「フラグ」だけでは「再生待ち行列」への挿入位置は決まらず他の要因で挿入位置が決まり、後者では「フラグ」だけで挿入位置が「再生待ち行列の最後」になるということなのか? 前者では挿入位置が「再生待ち行列の最後」以外のところに、後者では挿入位置が「再生待ち行列の最後」に決められているということなのか? 等々、様々な解釈が可能である。)、しかも、上記(1)記載のとおり発明の詳細な説明にも対応する記載が見当たらないため、該発明特定事項の意味は発明の詳細な説明を参酌しても明確に把握し得ないものである。
してみると、本件補正後の請求項1?2に係る発明は、明確でない。
また、このため、本件補正後の発明の詳細な説明は、本件補正後の請求項1?2に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項の経済産業省令で定めるところによる記載がされていないものであるとも言える。

(3)よって、本件補正後の発明の詳細な説明及び特許請求の範囲の記載は、特許法第36条第4項及び第6項第1号および第2項に規定する要件を満たしておらず、本件補正後の請求項1?2に係る発明は、特許出願の際独立して特許を受けることができないものである。


4-2.特許法第29条第2項(進歩性)について

4-2-1.本件補正発明
本件補正発明は、上記第1.2.(8)において【請求項1】として記載したとおりのものである。

4-2-2.先行技術文献・引用発明
上記第2.1.で示したとおり、本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成24年12月13日付けの拒絶理由通知書の理由3において引用された、上記引用文献にはそれぞれ上記引用文献記載事項が記載されており、上記第2.2.で示したとおり、本願の出願前かつ上記優先日よりも前に頒布された上記参考文献にはそれぞれ上記参考文献記載事項が記載されている。
そして、上記引用文献1には上記第2.3.で認定したとおりの引用発明が記載されているといえる。


4-2-3.対比
以下、本件補正発明と引用発明とを比較する。

(1)引用発明は、「マルチウインドウ上で走行し、共用領域へデータを複写する機能を備える少なくとも1以上のアプリケーションによる実行画面を有するシステム」である「読み上げ装置」であるから、本件補正発明と同様に「コンピュータ・システム」とも言えるものであり、また、本件補正発明と同様に「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは明らかである。

(2)引用発明における「ウインドウシステム」は本件補正発明における「オペレーティング・システム」に対応付けられるものであるところ、両者は「前記プロセッサにおいて動作するオペレーティング・システム」と言えるものであるから、引用発明と本件補正発明とは
「前記プロセッサにおいて動作するオペレーティング・システム」
を具備する点で共通する。

(3)引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」は本件補正発明における「テキスト・ツゥ・スピーチ・コンポーネント」に相当するものであるところ、これらと「アプリケーション」との間のインタフェースを行う手段があることは自明であり、該手段は本件補正発明における「アプリケーション・プログラム・インターフェース」に対応付けることができ、両者は「テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」と言えるものである。
したがって、引用発明と本件補正発明とは「テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」
を具備する点で共通する。

(4)引用発明における「マルチウインドウ上で走行」する「アプリケーション」は、本件補正発明における「アプリケーション・プログラム」に対応付けられるものであるところ、前者の「マルチウインドウ」が「ウインドウシステム」によって実現されるものであることは明らかであるから、前者も「前記オペレーティング・システムの制御下でランする」「プログラム」であると言える。
したがって、引用発明と本件補正発明とは
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備する点で共通する。

(5)
ア.引用発明においては「要求制御部」は「アプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行」し、「音声変換出力手段」は「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する」のであるから、引用発明における上記「インタフェース手段」と本件補正発明の「アプリケーション・プログラム・インターフェース」とは「前記アプリケーション・プログラムからデータを受信」するものである点で共通する。

イ.引用発明においては、「判定部」は「前記状態監視部からの監視情報に基づき、前記登録されたアプリケーションの音声出力が可能な状態か否かを判定」し、「要求制御部」は「前記判定部によって音声出力が可能な状態と判定されたアプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行」し、「音声変換出力手段」は「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する」ものであるところ、「前記判定部は登録されたアプリケーションに対する音声出力可能な状態か否かの判定を、予めアプリケーションに付与した優先順位で行う」のであるから、引用発明における上記「インタフェース手段」は「特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するもの」であると言える。
一方、本件補正発明における「アプリケーション・プログラム・インターフェース」は
「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」
のであるから、これも「特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するもの」であると言える。

ウ.したがって、引用発明と本件補正発明は
「前記インタフェース手段は:
前記アプリケーション・プログラムからデータを受信し、
特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するものである」
点で共通する。

(6)よって、本件補正発明は、下記の本件補正発明と引用発明との一致点で引用発明と一致し、下記の本件補正発明と引用発明との相違点で引用発明と相違する。

<本件補正発明と引用発明との一致点>
「コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムと
テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段と;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
を具備し、
前記インタフェース手段は:
前記アプリケーション・プログラムからデータを受信し、
特定されたテキストの優先順位に基づいた再生を行うための情報を受け取るように動作するものである
コンピュータ・システム。」

<本件補正発明と引用発明との相違点1>
本件補正発明におけるインタフェース手段は「オペレーティング・システム」が「有する」「アプリケーション・プログラム・インターフェース」である。
(これに対して、引用発明における「ウインドウシステム」は「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」とは別のものとして説明されているため、インタフェース手段は必ずしも「ウインドウシステム」が有する「アプリケーション・プログラム・インターフェース」とは言えないものである。)

<本件補正発明と引用発明との相違点2>
本件補正発明におけるアプリケーション・プログラム・インターフェースは「データを前記アプリケーション・プログラムに送信」する。
(これに対し、引用文献1には「データ」を「アプリケーション」に「送信」することを明示する記載は無い。)

<本件補正発明と引用発明との相違点3>
本件補正発明におけるアプリケーション・プログラム・インターフェースは、「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」ものである。
(これに対して、引用文献1には、「ウインドウレベルの入替えによる停止要求」との記載はあるものの(引用文献記載事項1-6)、読み上げ中の文への「割り込み」を明示する記載は無く、また、引用発明は優先順位で音声出力を行うものであるものの、優先順位を示す「フラグ」の記載や「待ち行列」に文を加える旨の記載も無い。)


4-2-4.判断
以下、上記相違点について検討する。

(1)本件補正発明と引用発明との相違点1について
上記優先日前には、引用文献2.(特に引用文献記載事項2-1、2-2参照)記載の如く、音声合成の機能のプラットフォームが知られており、また、必要なコンポーネントをOSに組み合わせてOSの機能を拡張したり、OSのバージョンアップに際して新しい機能を追加することも、従来から適宜になされてきたことである(必要があれば参考文献記載事項1-2、2-1、3-1参照)。
また、アプリケーションとのインタフェースのためにOSがAPIを提供することは技術常識にほかならないものである。
してみると、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」の機能を「オペレーティング・システム」が提供するものとし、これらのインタフェース手段を「オペレーティング・システム」が「有する」「アプリケーション・プログラム・インターフェース」とすること、すなわち、上記本件補正発明と引用発明との相違点1に係る構成を採用することは、当業者であれば容易に想到し得たことである。

(2)本件補正発明と引用発明との相違点2について
本件補正発明における「データを前記アプリケーション・プログラムに送信」することが、本願の発明の詳細な説明に記載されているどのAPIに対応するものなのかは必ずしも明確でないものの、一般的にAPIはエラーコードやデバイスの状態をアプリケーションに返す機能も備えるのが普通であり(例えば、引用文献記載事項2-5(特にヘルプルーチンとメインルーチン間の「現在の話者取得」との記載)、参考文献記載事項4-2、4-3等参照)、また、「オペレーティング・システム」においては、キーボードなどの入力手段や外部記憶装置等からのデータをアプリケーションに引き渡すAPIが設けられることは技術常識である。
してみると、アプリケーション・プログラム・インターフェースを「データを前記アプリケーション・プログラムに送信」するものとすること、すなわち上記本件補正発明と引用発明との相違点2に係る構成は、上記本件補正発明と引用発明との相違点1に係る構成の採用に伴い必然的に採用される構成にほかならない。

(3)本件補正発明と引用発明との相違点3について
複数の文を出力手段で出力する際に、出力要求された文を再生中のものに割り込んで再生するか否か、および、待ち行列の何処に挿入するかを決めるための情報も送受することは、従来から周知慣用の技術思想にほかならないものであり(必要があれば参考文献記載事項5-1?5-4、6-1、6-2参照)、係る周知慣用技術の引用発明への採用を試みることは、当業者であれば当然に想到する着想であり、その際に該情報を送受するためのインタフェースを定義・実装することは、必然的に採用される事項にほかならない。
本件補正発明におけるアプリケーション・プログラム・インターフェースを「特定されたテキストの優先順位を示すフラグを受け取るように動作し、」「前記フラグは、再生中のテキストが存在する場合、該再生中のテキストへの割り込みを含む、前記特定されたテキストの再生を行うこと、」「別のテキストが再生中の場合、再生待ち行列に前記特定されたテキストを加えること、」「別のテキストが再生中の場合、前記再生待ち行列の最後に前記特定されたテキストを加えること、の何れか1つを表す」ものとすることの技術的な意味は必ずしも明確なものではないものの、このようなインタフェースを定義・実装することと解することもできる。
してみると、引用発明を上記本件補正発明と引用発明との相違点3にかかる事項を備えるものとすることは、当業者が適宜に採用し得た設計的事項に過ぎないものである。

(4)よって、本件補正発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。
そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本件補正発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。


4-3.小結
上記4-1.のとおり、本件補正後の発明の詳細な説明及び特許請求の範囲の記載は、特許法第36条第4項、同条第6項第1号および第2号に規定する要件を満たしておらず、本件補正後の請求項1、2に係る発明は、この理由によって特許出願の際独立して特許を受けることができないものである。

上記4-2.のとおり、本件補正発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。

したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する。


5.中結
上記2.のとおり、本件補正は、特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

上記3.のとおり、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

上記4.のとおり、本件補正は、仮に平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号に掲げる事項を目的としたものであるとしても、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、上記補正却下の決定の結論のとおり決定する。



第4.原審補正却下の決定の適否
審判請求書の主張内容等からみて、請求人は平成25年4月11日付けの補正却下の決定(以下「原審補正却下」と記す。)に不服を申立ていると認められるので、その適否について検討するに、上記第3.において検討した上記平成25年8月16日付けの手続補正書は上記審判請求書記載のとおり、上記平成25年3月19日付け手続補正書と同内容の補正をしようとするものであるから、上記平成25年3月19日付け手続補正書も上記平成25年8月16日付けの手続補正書と同様の理由によって却下すべきものである。
したがって、上記平成25年3月19日付け手続補正書による補正を特許法第53条第1項の規定により却下するとした、原審補正却下の決定は適法なものであり、これは取り消すべきものではない。



第5.本願特許請求の範囲・明細書・図面
本願の経緯は上記第1.のとおりであり、上記第3.のとおり平成25年8月16日付けの手続補正は却下された。そして、上記第4.のとおり平成25年4月11日付けの原審補正却下の決定は適法なものであり、取り消すべきものではない。
したがって、本願の特許請求の範囲は平成24年6月12日付けの手続補正書によって補正された上記第1.1.(1)に記載のとおりのものである。
なお、本願の明細書及び図面については、手続補正はなされておらず、本願の願書に最初に添付した明細書及び図面のままである。



第6.原審拒絶理由1(特許法第37条)について

1.本願は、本願特許請求の範囲の請求項1?8に記載されたとおりの、2以上の発明について、1の願書で出願するものであるところ、その請求項1?8に係る発明は、上記第1.2.(1)に【請求項1】?【請求項8】として記載したとおりのものである。
そこで、本願特許請求の範囲の請求項1?8に係る発明が特許法第37条各号の関係を有しているか否かについて検討する。


2.特許法第37条第1号の関係について

(1)分野の共通性
本願請求項1?8に係る発明は、いずれも、本願発明の詳細な説明の【技術分野】の項の段落【0001】記載の「一般的にコンピュータ・オペレーティング・システムに関し、及びより特定的には、リソースが制限されたオペレーティング・システムに対するアプリケーション・プログラム・インターフェースに関する」ものであるから、本願請求項1?8に係る発明の産業上の利用分野は同一のものであると言える。

(2)課題の共通性
ア.本願明細書の発明の詳細な説明の
「【発明が解決しようとする課題】
【0012】
上述の短所、不都合、及び問題は、本発明によって検討され、それは、以下の明細書を読み及び研究することによって理解されるであろう。
リソースが制限された環境のための多くのソフトウェア・モジュール及びコンポーネントのために、一組のアプリケーション・プログラム・インターフェース(Application Program Interfaces)(API)を含むシステムが提示される。
リソースが制限された環境の一例は、埋め込み型システムであり、それは、ハンドヘルドまたはパームサイズのパーソナル・コンピュータとともに、様々な民生用機器及び専用産業用コントローラを具備する。」
との記載や、本願特許請求の範囲の記載等から、本願請求項1に係る発明と本願請求項8に係る発明は
「ソフトウェア・モジュール及びコンポーネントのためのアプリケーション・プログラム・インターフェースを含むシステムを提示すること」
を共通の課題としていると言える。
しかしながら、該課題は、引用文献2等を示すまでもなく、本願出願前には解決済みであった課題であり、本願出願時まで未解決であった技術上の課題であるとは言えない。

イ.また、他に、本願請求項1に係る発明と本願請求項8に係る発明との間に共通し、かつ、本願出願時まで未解決であった技術上の課題は見あたらない。

ウ.本願請求項2?3に係る発明は本願請求項1に係る発明に従属し、その下位概念に相当する発明であるところ、上記と同様に本願請求項2?3に係る発明と本願請求項8に係る発明との間に共通し、かつ、本願出願時まで未解決であった技術上の課題は見あたらない。

エ.よって、本願請求項1?3に係る発明を特定発明とした場合には、本願請求項8に係る発明は特許法第37条第1号に掲げる発明とは言えないものである。

オ.同様の理由により、本願請求項4?7に係る発明を特定発明とした場合にも、本願請求項8に係る発明は特許法第37条第1号に掲げる発明とは言えないものである。

カ.同様の理由により、本願請求項8に係る発明を特定発明とした場合にも本願請求項1?7に係る発明は特許法第37条第1号に掲げる発明とは言えないものである。


3.特許法第37条第2号の関係について

(1)分野の共通性
上記2.(1)で述べたとおり、本願請求項1?8に係る発明の産業上の利用分野は同一のものであると言える。

(2)主要部の共通性
ア.本願の特許請求の範囲の記載等から見て、本願請求項1に係る発明と本願請求項8に係る発明とは、次の共通事項を有する点で共通する。

<共通事項>
「コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、ソフトウエア部品を有する前記オペレーティング・システムと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
前記ソフトウエア部品と関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する前記アプリケーション・プログラム・インターフェースと;を具備し、
前記アプリケーション・プログラム・インターフェースは:
第1のインターフェースと;
第2のインターフェースと;を具備する、
コンピュータ・システム。」

イ.上記引用文献2等を挙げるまでもなく、本願優先日前には下記先行技術が周知慣用のものであったと言える。

<先行技術>
「パソコンにオペレーティング・システムとアプリケーションを搭載したコンピュータシステム」

ウ.対比
(ア)当該先行技術における「パソコン」が「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは技術常識にほかならない。

(イ)「オペレーティングシステム」が複数のソフトウエア部品で構成されていることも技術常識である(必要があれば参考文献記載事項1-3、2-1、4-1)から、先行技術は
「ソフトウエア部品を有する前記オペレーティング・システム」
を具備するものであることは明らかである。

(ウ)「アプリケーション」がオペレーティング・システムの制御下でランするプログラムであることも技術常識であるから、先行技術は
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備するものであることは明らかである。

(エ)「オペレーテイングシステム」がこれら複数のソフトウエア部品に関連するアプリケーション・プログラム・インターフェースを具備することも技術常識である(必要があれば参考文献記載事項1-1、4-1等参照)から、先行技術は、
「前記コンポーネントと関連するアプリケーション・プログラム・インターフェース」
を具備するものであることは明らかである。

(オ)また「アプリケーション・プログラム・インターフェース」が「前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する」ことも自明であり、先行技術における「アプリケーション・プログラム・インターフェース」が
「前記アプリケーションからデータを受信し及びデータを前記アプリケーションに送信するように動作する」
ものであることも明らかである。

(カ)さらに、「オペレーテイングシステム」はこのような「アプリケーション・プログラム・インターフェース」を複数提供していることも技術常識であるから、
「前記アプリケーション・プログラム・インターフェースは:
第1のインターフェースと;
第2のインターフェースと;を具備する」
ものであることも明らかである。

(キ)したがって、上記共通事項は上記先行技術と相違のないものであり、新規な事項とは言えないものである。

エ.してみると、上記共通事項は主要部、すなわち、解決しようとする課題に対応した新規な事項と言えるものではない。

オ.また、他に、本願請求項1に係る発明と本願請求項8に係る発明との間に共通の主要部と言える事項は見あたらない。

カ.本願請求項2?3に係る発明は本願請求項1に係る発明に従属し、その下位概念に相当する発明であるところ、上記と同様に本願請求項2?3に係る発明と本願請求項8に係る発明との間に共通の主要部と言える事項は見あたらない。

キ.よって、本願請求項1?3に係る発明を特定発明とした場合には、本願請求項8に係る発明は特許法第37条第2号に掲げる発明とは言えないものである。

ク.同様の理由により、本願請求項4?7に係る発明を特定発明とした場合にも、本願請求項8に係る発明は特許法第37条第2号に掲げる発明とは言えないものである。

ケ.同様の理由により、本願請求項8に係る発明を特定発明とした場合にも本願請求項1?7に係る発明は特許法第37条第2号に掲げる発明とは言えないものである。


4.特許法第37条第3号の関係について
本願請求項1?8に係る発明はいずれも「コンピュータ・システム」すなわち「物」の発明であるから、本願請求項1?8に係る発明のいずれを特定発明としても、他の請求項に係る発明は、該特定発明を生産する方法の発明とも、該特定発明を使用する方法の発明とも、該特定発明を取り扱う方法の発明とも言えるものではないことは明らかである。
また、本願請求項1?8に係る発明はいずれも、他の「コンピュータ・システム」を生産したり利用したりする「コンピュータ・システム」ではないので、本願請求項1?8に係る発明のいずれを特定発明としても、他の請求項に係る発明は、該特定発明を生産する機械、器具、装置、その他の物の発明とも、該特定発明の特定の性質を専ら利用する物の発明とも、該特定発明を取り扱う物の発明とも言えるものではないことは明らかである。
よって、本願請求項1?8に係る発明のいずれを特定発明としても、他の請求項に係る発明は特許法第37条第3号に掲げる発明とは言えない。


5.特許法第37条第4号の関係について
本願請求項1?8に係る発明はいずれも「コンピュータ・システム」すなわち「物」の発明であり、本願請求項1?8に係る発明のいずれも特許法第37条第4号における特定発明とはなり得ず、当然に本願請求項1?8に係る発明のいずれも特定発明の実施に直接使用する機械、器具、装置その他の物には該当しないことは明らかである。
よって、本願請求項1?8に係る発明のいずれを特定発明としても、他の請求項に係る発明は、特許法第37条第4号に掲げる発明とは言えない。


6.特許法第37条第5号の関係について
上記2.?5.のとおりであるから、本願請求項1?8に係る発明のいずれを特定発明としても、当該特定発明と他の請求項に係る発明とは特許法第37条第5号の経済産業省令で定める関係を有しない。


7.小結
以上のとおりであるから、本願請求項1?8に係る発明のいずれを特定発明としても、本願請求項1?8係る発明の中に特許法第37条各号の何れの関係も有しない発明が存在する。

よって、本願は特許法第37条に規定する要件を満たしていないものである。



第7.原審拒絶理由2(特許法第36条第6項第1号)について

1.上記原審拒絶理由通知書で通知した特許法第36条についての拒絶理由は上記第1.2.(2)の理由2.に記載のとおりのものである。

2.平成25年8月16日付けの手続補正は上記第3.のとおり却下されたのであるから、原審拒絶理由理由の2.において、明細書に記載されていないと指摘された、請求項1-3に係る発明は、依然として、特許請求の範囲に記載されたままのものである。

3.本願の請求項1について検討するに、その発明特定事項である「第2のインターフェース」が「テキストを含むバッファと、」「テキスト・ツゥ・スピーチ制御タグを含むバッファとを」受け取る旨の記載は本願の発明の詳細な説明中には見当たらない。
なお【表126】には
「pszSpeak
[in]話すためのテキストを含むバッファのアドレスである。アプリケーションは、Speakが返るとすぐに、前記バッファを解放し又は修正することができる。このパラメータによって指された列は、テキスト・ツゥ・スピーチ制御タグを含むことができる。」
『pszTags
[in]音声、言語、又はpszSpeakによって特定されるテキストのコンテクストを変更するためのテキスト・ツゥ・スピーチ制御タグ、又は前記テキスト・ツゥ・スピーチ音声に対してデフォルト設定を使用するためのNULLを含むバッファのアドレスである。制御タグに関するさらなる情報は、付録A「テキスト・ツゥ・スピーチ制御タグ」を参照のこと。』
との記載があるものの、このパラメータ「pszSpeak」「pszTags」は「バッファのアドレス」であり、バッファそのものではない。

4.本願の請求項1について検討するに、その発明特定事項である「前記テキストの種類を示す優先順位フラグ」に相当する記載は本願の発明の詳細な説明中には見当たらない。
なお、【表126】には
「dwFlags
[in]前記テキストの種類と優先順位を示すフラグである。このパラメータは、一つの種類のフラグと一つの優先順位フラグとの組み合わせである。」
との記載があるものの、ここに記載される「優先順位フラグ」は「優先順位を示す」ものであり、「前記テキストの種類を示す」ものではない。また、ここに記載される「種類のフラグ」は「テキストの種類」「を示すフラグ」であると認められるものの「優先順位フラグ」とは明らかに異なる用語であり、請求項1の記載と異なる。

5.以上のとおり、請求項1の記載は発明の詳細な説明と明らかに齟齬する記載を含み、発明の詳細な説明中に記載も示唆もされていない事項が記載されているもの、あるいは、請求項1と発明の詳細な説明に記載された用語が不統一であり、その結果、両者の対応関係が不明瞭となっているものであるから、請求項1?3に係る発明は、発明の詳細な説明に記載したものではないといえる。

6.よって、本願は、特許請求の範囲の記載が、特許法第36条第6項第1号に規定する要件を満たしていないものである。



第8.原審拒絶理由3(特許法第29条第2項)について

1.本願発明の認定・引用文献の記載内容・引用発明の認定

本願の請求項1に係る発明(以下、「本願発明」という。)は、上記平成24年6月12日付けの手続補正書によって補正された特許請求の範囲の記載等からみて次の通りのものであると認められる。

<本願発明>
「コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムであって、テキスト・ツゥ・スピーチ・コンポーネントを有する前記オペレーティング・システムと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
前記テキスト・ツゥ・スピーチ・コンポーネントと関連するアプリケーション・プログラム・インターフェースであって、前記アプリケーション・プログラムからデータを受信し及びデータを前記アプリケーション・プログラムに送信するように動作する前記アプリケーション・プログラム・インターフェースと;を具備し、
前記アプリケーション・プログラム・インターフェースは:
アプリケーション識別子と、通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照とを受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファと、前記テキストの種類を示す優先順位フラグと、テキスト・ツゥ・スピーチ制御タグを含むバッファとを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する、
ことを特徴とするコンピュータ・システム。」

(なお、上記平成24年6月12日付けの手続補正書の請求項1における「スピーチ・ツゥ・テキスト・コンポーネント」との記載は「テキスト・ツゥ・スピーチ・コンポーネント」の誤記と、「前記アプリケーション」との記載は「前記アプリケーション・プログラム」の誤記と認められるので、それぞれ、「テキスト・ツゥ・スピーチ・コンポーネント」「前記アプリケーション・プログラム」に正して認定した。)


2.先行技術文献・引用発明
上記第2.1.で示したとおり、本願の出願前かつ上記優先日よりも前に頒布され、原審の拒絶の査定の理由である上記平成24年12月13日付けの拒絶理由通知書の理由3において引用された、上記引用文献にはそれぞれ上記引用文献記載事項が記載されており、上記第2.2.で示したとおり、本願の出願前かつ上記優先日よりも前に頒布された上記参考文献にはそれぞれ上記参考文献記載事項が記載されている。
そして、上記引用文献1には上記第2.3.で認定したとおりの引用発明が記載されているといえる。


3.対比
以下に、本願発明と引用発明とを比較する。

(1)上記4-2-3.(1)での所論と同様に、引用発明は本願発明と同様に「コンピュータ・システム」とも言えるものであり、また、本願発明と同様に「互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータ」を具備するものであることは明らかである。

(2)上記4-2-3.(2)での所論と同様に、引用発明と本願発明とは「前記プロセッサにおいて動作するオペレーティング・システム」
を具備する点で共通する。

(3)上記4-2-3.(3)でも述べたように、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」は本願発明における「テキスト・ツゥ・スピーチ・コンポーネント」に相当する。
したがって、引用発明と本願発明とは
「テキスト・ツゥ・スピーチ・コンポーネント」
を具備する点で共通する。

(4)上記4-2-3.(4)での所論と同様に、引用発明と本願発明とは
「前記オペレーティング・システムの制御下でランするアプリケーション・プログラム」
を具備する点で共通する。

(5)
ア.上記4-2-3.(3)でも述べたように、引用発明にける「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」と「アプリケーション」との間のインタフェースを行う手段があることは自明であり、該手段は本願発明における「アプリケーション・プログラム・インターフェース」に対応付けることができるところ、両者は「前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段」と言えるものである点で共通する。

イ.上記4-2-3.(5)ア.で述べたように、引用発明における上記「インタフェース手段」と本願発明の「アプリケーション・プログラム・インターフェース」とは「前記アプリケーション・プログラムからデータを受信するように動作する」ものである点でも共通する。

ウ.したがって、引用発明と本願発明とは
「前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段であって、前記アプリケーション・プログラムからデータを受信するように動作する前記インタフェース手段」
を具備している点で共通する

(6)引用発明における「アプリケーションの実行ファイル名」は本願発明における「アプリケーション識別子」に相当するものであり、引用発明は「実行時のウインドウへの表示文を音声出力させる対象として、前記アプリケーションを登録領域に登録するする登録手段」を備え、「前記登録手段はアプリケーションの実行ファイル名を登録するもの」であるから、上記引用発明における「インタフェース手段」と本願発明における「アプリケーション・プログラム・インターフェース」は
「アプリケーション識別子を受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェース」
を具備する点で共通する。

(7)引用発明は「アプリケーションに対して、ウインドウ表示の文内容を前記共用領域に複写させる要求信号を発行する要求制御部と、」「前記共用領域に複写された文内容を抽出し、音声出力用データに変換して音声として出力する音声変換出力手段と、を備える」のであるから、上記引用発明における「インタフェース手段」と本願発明における「アプリケーション・プログラム・インターフェース」とは、
「テキストを含むバッファを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェース」
を具備するものである点で共通するといえる。

(8)よって、本願発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。

<一致点>
「コンピュータ・システムであって:
互いに動作可能に接続されたプロセッサ及びメモリを具備するコンピュータと;
前記プロセッサにおいて動作するオペレーティング・システムと;
テキスト・ツゥ・スピーチ・コンポーネントと;
前記オペレーティング・システムの制御下でランするアプリケーション・プログラムと;
前記テキスト・ツゥ・スピーチ・コンポーネントと関連するインタフェース手段であって、前記アプリケーション・プログラムからデータを受信するように動作する前記インタフェース手段と;を具備し、
前記インタフェース手段は:
アプリケーション識別子を受け取り、及び前記アプリケーション・プログラムを、テキスト・ツゥ・スピーチ・コンポーネントに登録する第1のインターフェースと;
テキストを含むバッファを受け取り、及び前記テキスト・ツゥ・スピーチ・コンポーネントが、前記テキストを含むバッファを音声出力に変換するようにさせる第2のインターフェースと;を具備する、
コンピュータ・システム。」

<相違点1>
本願発明におけるオペレーティング・システムは「テキスト・ツゥ・スピーチ・コンポーネントを有する」ものである。
(これに対して、引用発明における「ウインドウシステム」は「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」とは別のものとして説明されている。)

<相違点2>
本願発明におけるインタフェース手段は「アプリケーション・プログラム・インターフェース」である。
(これに対して、引用文献1には「アプリケーション・プログラム・インターフェース」の直接的な明示はない。)

<相違点3>
本願発明におけるアプリケーション・プログラム・インターフェースは「データを前記アプリケーション・プログラムに送信」する。
(これに対し、引用文献1にはデータをアプリケーションに「送信」することを明示する記載は無い。)

<相違点4>
本願発明における第1のインターフェースは「通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照」も受け取るものである。
(これに対して、引用文献1における「登録手段」がこのような情報を通知することは記載されていない。)

<相違点5>
本願発明における第2のインターフェースは、「前記テキストの種類を示す優先順位フラグ」も受け取る。
(これに対して引用文献1にはこのようなフラグをやりとりすることは記載されていない。)

<相違点6>
本願発明における第2のインターフェースは、「テキスト・ツゥ・スピーチ制御タグを含むバッファ」も受け取る。
(これに対して、引用文献1における「状態監視部」「判定部」「要求制御部」「音声変換出力手段」がこのような情報を通知することは記載されていない。)


4.判断
以下に、上記相違点について検討する。

(1)相違点1について
上記優先日前には、引用文献2.(特に引用文献記載事項2-1、2-2参照)記載の如く、音声合成の機能のプラットフォームが知られており、また、必要なコンポーネントをOSに組み合わせてOSの機能を拡張したり、OSのバージョンアップに際して新しい機能を追加することも、従来から適宜になされてきたことである(必要があれば参考文献記載事項1-2、2-1、3-1参照)。
してみると、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」を「ウインドウシステム」に含めることで、本願発明と同様に「オペレーティング・システム」が「テキスト・ツゥ・スピーチ・コンポーネントを有する」ものとすること、すなわち、上記相違点1に係る構成を採用することは、当業者であれば容易に想到し得たことである。

(2)相違点2について
アプリケーションやユーザとのインタフェースのためにオペレーティング・システムがアプリケーション・プログラム・インターフェースを提供することは技術常識にほかならないものであり、引用発明における「登録手段」「状態監視部」「判定部」「要求制御部」「音声変換出力手段」の「インタフェース手段」を「アプリケーション・プログラム・インターフェース」とすること、すなわち、上記相違点2に係る構成は、上記相違点1に係る構成の採用に伴い必然的に採用されるものにほかならない。

(3)相違点3について
本願発明における「データを前記アプリケーション・プログラムに送信」することが本願発明の詳細な説明に記載のどのAPIに対応するものなのかは必ずしも明確でないものの、一般的にAPIはエラーコードやデバイスの状態をアプリケーションに返す機能も備えるのが普通であり(例えば、引用文献記載事項2-5(特にヘルプルーチンとメインルーチン間の「現在の話者取得」との記載)、参考文献記載事項4-2、4-3等参照)、また、「オペレーティング・システム」においては、キーボードなどの入力手段や外部記憶装置等からのデータをアプリケーションに引き渡すAPIが設けられることは技術常識である。
してみると、アプリケーション・プログラム・インターフェースを「データを前記アプリケーション・プログラムに送信」するものとすること、すなわち上記相違点3に係る構成も、上記相違点1に係る構成の採用に伴い必然的に採用されるものにほかならない。

(4)相違点4について
一般に音声合成手段には、現在の話者などの自己の状態を利用手段に通知する機能を有しており、また、利用手段からテンポなどを設定できるように構成されるものである。(必要があれば引用文献記載事項2-3?2-5等参照。)
したがって、引用発明においても「音声変換出力手段」の状態などを「アプリケーション」に通知し、また、「音声変換出力手段」の話者や話速などを設定し得るようにするため、上記「第1のインターフェース」を「通知インターフェースと、前記通知インターフェースに対する識別子と、前記通知インターフェースに送られるべき一組の通知を識別するフラグと、サイト情報構造への参照」も受け取るものとすること、すなわち、上記相違点4に係る構成を採用することも、当業者であれば適宜に採用し得た設計的事項に過ぎない。

(5)相違点5について
本願発明における「前記テキストの種類を示す優先順位フラグ」との技術的意味は必ずしも明確なものではないものの、複数の文を出力手段で出力する際に、出力要求された文を再生中のものに割り込んで再生するか否かの情報や待ち行列の何処に挿入するかを決めるための情報を送受することは、従来から周知慣用の技術思想にほかならないものであり(必要があれば参考文献記載事項5-1?5-4、6-1、6-2参照)、本願発明における「前記テキストの種類を示す優先順位フラグ」とは、このような情報を包含するものと解することができる。
してみると、引用発明における第2のインターフェースを、「前記テキストの種類を示す優先順位フラグ」も受け取るものとすること、すなわち上記相違点6に係る事項を備えるものとすることは、当業者であれば適宜に採用し得た設計的事項にすぎない。

(6)相違点6について
音声合成手段を話者変更などの制御を可能にする機能を備えることも、当業者が通常採用する周知慣用技術であり(必要があれば引用文献記載事項2-4、2-5等参照。)、引用発明における第2のインターフェースを、「テキスト・ツゥ・スピーチ制御タグを含むバッファ」も受け取るものとすること、すなわち上記相違点6に係る事項を備えるものとすることも、当業者であれば適宜に採用し得た設計的事項にすぎない。

(7)よって、本願発明の構成は引用発明に基づいて、当業者が容易に想到し得たものである。
また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。


5.小結
以上のとおり、本願の請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものである。



第9.結び

1.上記第6.のとおり、本願は、特許法第37条に規定する要件を満たしていないものであるから、原審拒絶理由1によって拒絶すべきものである。

2.上記第7.のとおり、本願は、特許請求の範囲の記載が、特許法第36条第6項第1号に規定する要件を満たしていないものであるから、原審拒絶理由2によっても拒絶すべきものである。

3.上記第8.のとおり、本願請求項1に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により特許を受けることができないものであるから、本願は原審拒絶理由3によっても拒絶すべきものである。

4.なお、上記第3.4-1.(2)、および上記第3.4-2.において検討したとおりであるから、上記第3.の補正却下の決定がなされなかったと仮定した場合であっても、本願は原審拒絶理由2および3によって拒絶すべきものである。

5.したがって、原査定を取り消し、本願は特許をすべきものであるとの審決をすることはできない。

よって、上記結論のとおり審決する。
 
審理終結日 2014-08-01 
結審通知日 2014-08-04 
審決日 2014-09-01 
出願番号 特願2009-34311(P2009-34311)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 641- Z (G06F)
P 1 8・ 536- Z (G06F)
P 1 8・ 642- Z (G06F)
P 1 8・ 575- Z (G06F)
P 1 8・ 561- Z (G06F)
P 1 8・ 574- Z (G06F)
P 1 8・ 572- Z (G06F)
P 1 8・ 537- Z (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 辻本 泰隆
特許庁審判官 田中 秀人
山崎 達也
発明の名称 オペレーティング・システムのアプリケーション・プログラム・インターフェース  
代理人 小林 泰  
代理人 小野 新次郎  
代理人 上田 忠  
代理人 山本 修  
代理人 竹内 茂雄  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ