【事件の表示】
　平成１０年特許願第　５５６９８号「ソフトウェア部品開発支援装置」拒絶査定不服審判事件〔平成１１年　８月３１日出願公開、特開平１１−２３７９８２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１０年２月２３日の出願であって、平成１８年３月１４日付けで拒絶理由通知がなされ、同年５月２２日付けで意見書が提出されるとともに手続補正がなされたが、同年６月２８日付けで拒絶査定がなされ、これに対し、同年８月３日に審判請求がなされるとともに、同年９月４日付けで手続補正がなされ、同年１１月９日付けで前置報告がなされ、平成２０年１１月１２日付けで当審にて行った審尋に対する回答書が提出されなかったものである。
　
　
第２．平成１８年９月４日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１８年９月４日付けの手続補正を却下する。
　
［理由］
１．本件補正
　平成１８年９月４日付けの手続補正（以下、「本件補正」という。）は、平成１８年５月２２日付けの手続補正により補正された特許請求の範囲の記載
「【請求項１】　オブジェクト指向による再利用可能なソフトウェア部品の開発を支援するソフトウェア部品開発支援装置において，
　ある問題領域のアプリケーションに共通となる要求仕様の分析結果であり，アプリケーション毎に仕様が変更される変動部が示された分析モデルの入力を受け付ける分析モデル入力受付手段と，
　前記分析モデル入力受付手段により入力が受け付けられた前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段と，
　を備えたことを特徴とするソフトウェア部品開発支援装置。
　　【請求項２】　前記変換手段は，前記分析モデルに基づいて，前記変動部として設計された該抽象クラスのサブクラスとして具象クラスの定義を入力可能なクラス設計情報に変換することを特徴とする請求項１記載のソフトウェア部品開発支援装置。
　　【請求項３】　前記変換手段は，前記分析モデルに基づいて，個々のアプリケーションの前記変動部に含まれるパラメータ又は，前記変動部として当該アプリケーションの雛形若しくはコードに埋め込まれる設計情報を入力可能なアプリケーションジェネレータに変換することを特徴とする請求項１記載のソフトウェア部品開発支援装置。」（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
　
を、
　
「【請求項１】　オブジェクト指向による再利用可能なソフトウェア部品の開発を支援するソフトウェア部品開発支援装置において，
　ある問題領域のアプリケーションに共通となる要求仕様の分析結果であり，アプリケーション毎に仕様が変更される変動部を示す変動部指示情報を含むクラス図の入力を受け付ける分析モデル入力受付手段と，
　前記分析モデル入力受付手段により入力が受け付けられた前記クラス図に基づいて，アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて、前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報に変換する変換手段と，
　を備えたことを特徴とするソフトウェア部品開発支援装置。
　　【請求項２】　前記変換手段は，前記クラス図に基づいて，前記変動部として設計された該抽象クラスのサブクラスとして具象クラスの定義を入力可能な前記表示画面を提示し、当該表示画面に対して入力された当該サブクラスにおける前記パラメータ又は前記設定情報を用いて前記クラス設計情報に変換することを特徴とする請求項１記載のソフトウェア部品開発支援装置。」（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
に補正するものである。
　
２．補正の適否
(１)特許法第１７条の２第３項の規定に適合するかについての検討
　請求項１についてする本件補正が、願書に最初に添付した明細書又は図面（以下、「当初明細書等」という）に記載した事項の範囲内においてしたものであるかについて、検討する。
　
(１−１)請求項１についてする本件補正
　請求項１についてする本件補正は、
Ａ．補正前の請求項１における「変動部が示された分析モデル」を、補正後の請求項１においては「変動部を示す変動部指示情報を含むクラス図」と補正し、
Ｂ．補正前の請求項１における「変換手段」が「前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する」ものであったものを、補正後の請求項１における「変換手段」は「前記クラス図に基づいて，アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて、前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報に変換する」と補正する、
ものである。
　前記Ｂの本件補正において、「及びアプリケーションジェネレータのうち少なくともいずれか一方」の記載を削除することによって、「変換手段」は「クラス設計情報に変換する」手段に特定された。そして、補正後の請求項１には、当該「クラス設計情報」は「前記再利用可能ソフトウェア部品のクラス構成を示す」ものであると定義されている。
　
(１−２)検討
　一方、当初明細書等には、たとえば、段落【００１１】に「アプリケーション開発環境の要素となる再利用可能ソフトウェアの設計情報（フレームワークまたは／およびアプリケーションジェネレータ）」と、段落【００１４】に「フレームワークとは，変動部分を抽象クラスとして設計し，そのサブフラスで変動部を実装することによりアプリケーションを開発することができるようなクラス設計であり」と記載されている。したがって、補正後の請求項１における、前記「前記再利用可能ソフトウェア部品のクラス構成を示す」ところの「クラス設計情報」は、当初明細書等におけるフレームワークに該当すると認められる。
　また、補正後の請求項１において「変換手段」がする「変換」の出力からは削除された「アプリケーションジェネレータ」は、当初明細書等におけるアプリケーションジェネレータに該当することは明らかである。当初明細書等には、段落【００１４】に「アプリケーションジェネレータとは，アプリケーションの変動部分に関するパラメータや設計を入力することによってアプリケーションを自動生成するツールであり，変動部分に関する情報を記述することのできる簡易言語を定義することができるものである。」と、段落【００２６】に、「アプリケーションジェネレータとは，アプリケーションの仕様に基づく設計情報を入力として，アプリケーションを生成するツールである。設計情報の入力のためのユーザインターフェースを含んだ開発環境，あるいは設計情報を入力するための簡易言語と簡易言語で記述された設計情報からアプリケーションを生成するコマンド，といった形で提供される」と、それぞれ記載されている。よって、前記アプリケーションジェネレータとは、アプリケーションの変動部分に関するパラメータや設計を入力することによって当該アプリケーションを自動生成するツールであるから、補正後の請求項１記載の「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に該当するとは認められない。
　
　ところで、当初明細書等には、
　段落【００２８】に、「ここでは簡易言語ではなくＧＵＩを生成する場合を例とする。」と、
　段落【００２９】に、「さらにこのフレームワークを利用してアプリケーションを開発するのに必要な設計情報をリストアップして，これを入力するためのＧＵＩを生成する。
１
それぞれ、記載されている。
　前記各記載から、補正後の請求項１の「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面」に該当するのが「これ(すなわち、「必要な設計情報」)を入力するためのＧＵＩ」であることが、当初明細書等に記載されている。
　しかしながら、前記【００２６】〜【００２９】の記載は、アプリケーションジェネレータの生成について説明したものである。すなわち、補正後の請求項１に記載される「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示」することは、当初明細書等においては、本件補正によって補正後の請求項１から削除された「アプリケーションジェネレータ」の生成における手順の１つとして説明されたものにすぎない。
　
　そして、補正後の請求項１の「クラス設計情報」に該当するフレームワークの生成について当初明細書等には、たとえば、段落【００２５】に「本発明のソフトウェア部品開発支援装置は，入力されたモデル（図２参照）の中でvariant キーワードを付加された情報を検索してこれを解析し，上記の２つの設計案をグラフィックスで表示する。…(中略)…ユーザはこれらのうちから選択することによってフレームワーク設計を確定することができる。」と記載されているだけである。
　また、当初明細書等の他の記載を参照しても、前記「クラス設計情報」への「変換」を、補正後の請求項１のように、「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて」行うとの記載はなく、前記「クラス設計情報」への「変換」を補正後の請求項１のように行うことが、当初明細書等の記載内容から当業者において自明であるとも認められない。
　
(１−３)仮に、アプリケーションジェネレータも「クラス設計情報」に該当するとした場合の検討
　当初明細書等の段落【００１１】には「アプリケーション開発環境の要素となる再利用可能ソフトウェアの設計情報（フレームワークまたは／およびアプリケーションジェネレータ）」という記載が存在する。
　当該記載は「アプリケーションジェネレータ」も「再利用可能ソフトウェアの設計情報」であるというものであって、該「アプリケーションジェネレータ」が「再利用可能ソフトウェア部品のクラス構成を示す」ことまでを記載したものではないが、次に、アプリケーションジェネレータも「クラス設計情報」に該当すると仮定した場合について検討する。
　
　当初明細書等において「アプリケーションジェネレータの生成」について説明した段落【００２９】に「本発明のソフトウェア部品開発支援装置は，入力されたモデル（図２参照）の中でvariant キーワードを付加された情報を検索してこれを解析し，先ず，
３
１
　また、同様に「アプリケーションジェネレータの生成」について説明した、当初明細書等の段落【００３３】には「以上の設計情報を入力することのできるＧＵＩとして同様に図６に示すアプリケーションジェネレータを生成する。」と、同段落【００２７】には「アプリケーションジェネレータは，入力された設計情報を解析して，フレームワーク同様のアプリケーションの雛型となる設計あるいはコードに設計情報を埋め込むことによってアプリケーションを生成する。」と記載されている。
　前記各記載から、当初明細書等には、入力されたモデルを解析してフレームワークを生成し、前記フレームワークを利用してアプリケーションを開発するのに必要な設計情報を入力するためのＧＵＩとしてアプリケーションジェネレータを生成すること、入力された設計情報を前記ＧＵＩがアプリケーションの雛型となる設計あるいはコードに埋め込むことによってアプリケーションを生成すること、が記載されている。
　したがって、仮にアプリケーションジェネレータが補正後の請求項１の「クラス設計情報」に該当するとしても、当初明細書等には、アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面として再利用可能ソフトウェア部品のクラス設計情報に変換することが記載されているのであって、補正後の請求項１に記載の「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて、前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報に変換する」ことは、当初明細書等には記載されていないだけではなく、当初明細書等の記載内容から当業者において自明であるとも認められない。
　
　さらに、当初明細書等の段落【００１７】に、分析モデルは「変動部である場合，先頭にキーワードｖａｒｉａｎｔを記述」し、「クラスの関係」を「矩形を結ぶ折線で表す」ものであることが記載されているから、前記「入力されたモデル」は補正後の請求項１における「変動部を示す変動部指示情報を含むクラス図」に該当する。
　そして、上記のように、当初明細書等には、入力されたモデルを解析してフレームワークを生成し、前記フレームワークを利用してアプリケーションを開発するのに必要な設計情報を入力するためのＧＵＩとしてアプリケーションジェネレータを生成することが記載されている。
　すなわち、当初明細書等には、入力が受け付けられた前記「クラス図」に該当するモデルを解析して「クラス設計情報」に該当するフレームワークを生成し、前記フレームワークに基づいて、アプリケーション毎に前記フレームワークに含まれる変動部指示情報が示す変動部に対するパラメータ又は設計情報の入力を受け付ける「表示画面」を有するＧＵＩを提示することが記載されているだけである。
　したがって、「『入力が受け付けられた前記クラス図』に基づいて，アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示」することは、当初明細書等に記載されていないだけでなく、当初明細書の記載内容から自明なこととも認められない。
　
(１−４)小括
　以上から、請求項１についてする本件補正は、当初明細書等に記載した事項の範囲内においてなされたものではないので、特許法第１７条の２第３項の規定に違反している。
　
(２)特許法第１７条の２第４項の規定に適合するかについての検討
　前記(１)の検討から、請求項１についてする本件補正は、当初明細書等に記載した事項の範囲内においてなされたものではないことは明らかであるが、次に、仮に、請求項１についてする本件補正が特許法第１７条の２第３項の規定に適合するとしたときに、本件補正が許法第１７条の２第４項の規定に適合するかについて、以下に検討する。
　
　補正前の請求項と補正後の請求項の、それぞれの対応関係は次のとおりである。
　　　　　　　　　　補正前の請求項　　　補正後の請求項
　　　　　　　　　　　　　１　　　　→　　　　１
　　　　　　　　　　　　　２　　　　→　　　　２
　　　　　　　　　　　　　３　　　　　　　　（削除）
　
(２−１)特許法第１７条の２第４項第１号について
　上記のように補正前の請求項３は削除された。
　しかしながら、補正前の請求項３は、補正後の請求項１からは削除された「アプリケーションジェネレータ」に「変換する」ところの「ソフトウェア部品開発支援装置」に関するものである。さらに、本件補正により補正後の請求項１に追加された、発明を特定するために必要な事項である「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面」は、補正前の請求項３には記載されていない。
　したがって、請求項１についてする本件補正は、特許法第１７条の２第４項第１号に規定する請求項の削除を目的とするものとは認められない。
　
(２−２)特許法第１７条の２第４項第２号について
　請求項１についてする本件補正は、前記「（１）特許法第１７条の２第３項の規定に適合するかについての検討」において、その「(１−１)」の「Ｂ」に記載したように、補正前の請求項１における「変換手段」が「前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する」ものであったものを、補正後の請求項１における「変換手段」は「前記クラス図に基づいて，アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて、前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報に変換する」と補正する補正事項を含んでいる。
　審判請求人は審判請求書における「請求の理由」として、その「(3.2)  補正の根拠について」の項において、前記補正事項のうち、特に、「及びアプリケーションジェネレータのうち少なくともいずれか一方」の記載を削除する本件補正は「限定的減縮であると思料する」と主張している。
　
　ところで、前記補正事項は、
　補正前の請求項１においては、「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方」は「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能」という特性を備えていると限定するものの、前記「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方」にどのように「変換する」かについては限定がなかったものを、
　補正後の請求項１においては、「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」はどのような特性を備えているかは限定されていないものの、前記「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に「前記クラス図に基づいて，アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面を提示し、当該表示画面に対して入力されたパラメータ又は設定情報を用いて」、「変換する」と限定する、
ものである。
　そして、上記のように、「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」はどのような特性を備えているかの限定を削除し、代わって、前記「前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」をどのように「変換する」かを新たに追加する前記補正事項は、発明を特定するために必要な事項の限定を目的とするとは認められない。
　
　さらに、前記補正事項により、補正後の請求項１に追加された「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面」は、補正前の請求項１に記載されたいずれの発明を特定するために必要な事項にも対応せず、補正前の請求項１に記載されたいずれかの発明を特定するために必要な事項を下位概念化したものではない。
　したがって、前記補正事項を含む請求項１についてする本件補正は、発明を特定するために必要な事項の限定には当たらない。
　
　また、補正後の請求項１に係る発明は、前記「アプリケーション毎に前記クラス図に含まれる前記変動部指示情報が示す前記変動部に対するパラメータ又は設計情報の入力を受け付ける表示画面」との事項が追加されたことにより、審判請求人が主張するとおり、「変動部指示情報が示す変動部に対する入力を受け付ける表示画面を提示して、当該表示画面に対して入力されたパラメータ又は設定情報を用いて，再利用可能ソフトウェアのクラス設計情報を自動生成することができる。すなわち，再利用可能ソフトウェアの開発が容易に行えるようになる。」という、補正前の請求項１の記載からでは想起できない新たな課題が追加される。
　したがって、前記補正事項を含む請求項１についてする本件補正は、発明の解決しようとする課題を変更するものである。
　
　以上のように、請求項１についてする本件補正は、その補正事項の一部分は発明を特定するために必要な事項を限定的に減縮するものであったとしても、全体としてみれば、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野および解決しようとする課題が同一であるものに限る。）を目的とするものとは認められない。
　
(２−３)特許法第１７条の２第４項第３号及び第４号について
　請求項１についてする本件補正が、特許法第１７条の２第４項第３号の誤記の訂正に該当するものでないことは明らかである。
　さらに、請求項１についてする本件補正は、特許法第１７条の２第４項第４号の明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）に該当するものとも認められない。
　
(２−４)小括
　以上から、請求項１についてする補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当しない。
　したがって、本件補正は、特許法第１７条の２第４項の規定に違反するものである。 
　
３．むすび
　以上のとおりであるから、本件補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　そして、仮に、本件補正が前記特許法第１７条の２第３項の規定に適合するとしても、本件補正は、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
第３．本願明細書及び本願発明について
１．本願明細書及び本願発明
　平成１８年９月４日付けの手続補正は上記のとおり却下されたので、本願明細書及び図面は、平成１８年５月２２日付けの手続補正書により補正されたとおりのものであり、本願の請求項１に係る発明（以下、「本願発明」という。）は、前記平成１８年５月２２日付けの手続補正書により補正された明細書及び図面の記載からみて、前記補正前の請求項１に記載された以下のとおりのものと認める。
　
「【請求項１】　オブジェクト指向による再利用可能なソフトウェア部品の開発を支援するソフトウェア部品開発支援装置において，
　ある問題領域のアプリケーションに共通となる要求仕様の分析結果であり，アプリケーション毎に仕様が変更される変動部が示された分析モデルの入力を受け付ける分析モデル入力受付手段と，
　前記分析モデル入力受付手段により入力が受け付けられた前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段と，
　を備えたことを特徴とするソフトウェア部品開発支援装置。」
　
　
２．原審の拒絶理由
　平成１８年３月１４日付けで原審から通知した拒絶の理由の概要は、次のとおりである。
　
「１．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　……(中略)……
２．この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　　　……(中略)……
（２）請求項１〜４に係る発明の「分析モデルを入力してアプリケーション開発環境の要素となる再利用可能ソフトウェアの設計情報に変換する」ことについて、発明の詳細な説明には、例えば段落番号【００１７】及び【００２２】〜【００２５】を参照しても、変動部であることが記述された「属性」及び「振る舞い」を解析して、特定のデザインパターンに沿った抽象クラスの設計案を生成することが、抽象的に説明されている程度であり、どのような解析処理を行うことによって、前記設計案を生成するのか、具体的な説明がなく、その余の記載を参照しても、どのようにして「分析モデルを入力してアプリケーション開発環境の要素となる再利用可能ソフトウェアの設計情報に変換する」のか、当業者にとって、実現可能な程度に明確かつ十分に記載されているとは言えない。
　　　……(中略)……
　よって、この出願の発明の詳細な説明は、当業者が請求項１〜４に係る発明を実施することができる程度に明確かつ十分に記載されていない。
３．この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
（１）請求項１及び２について
　
・引用文献：１
　　　……(中略)……
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　　　　　　　　　　　引　用　文　献　等　一　覧
１．小田利彦，“ＩＰＳシステムドメインにおける組み込み型システムの再構築プロセス”，電子情報通信学会技術研究報告，社団法人電子情報通信学会，１９９６年９月３０日，第９６巻，第２８２号，ｐｐ．９−１６
　　　……(後略)……」
　
　
３．拒絶理由の２について
(１)審判請求人の主張
　前記当審の拒絶理由の２(２)に対する反論として、平成１８年５月２２日付けの意見書には、概略、次のように記載されている。
「そこで、当該箇所を、「前記分析モデル入力受付手段により入力が受け付けられた前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する」こととしました。つまり、分析モデルに基づいて、クラス設計情報及びアプリケーションジェネレータを生成することは、従来から用いられている技術を用いて実現可能です。そして、本願請求項１〜４にかかる発明においては、さらに生成された当該クラス設計情報及びアプリケーションジェネレータにおいて、分析モデル入力受付手段で分析モデルに対して示された変動部を入力可能としました。そして、このような構成は、本願明細書の記載から、当業者であれば実現することが可能です。」
　
　また、審判請求人は審判請求書における「請求の理由」として、その「(3.3)  記載不備について」の項において、概略、次のように主張している。
「審査官殿が言及されているように「ソフトウェア部品のクラス構成を示すクラス設計情報…に変換する」点について実施の形態において具体的に明示されていない。しかしながら、クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は、ＣＡＳＥツールの一機能として当業者において周知の技術である。
　例えば、Rational社のRoseは（段落０００２）、オブジェクト指向のソフトウェア開発を支援するＣＡＳＥツールとして周知であるが、当該ツールでクラス図からクラス構成が示されたプログラムのソースを出力する機能が備えられている。
　したがって、当業者であれば、クラス図に基づいて、「ソフトウェア部品のクラス構成を示すクラス設計情報…に変換する」ことは容易に想到できるものと思料する。上記の記載不備の拒絶理由は解消したものと思料する。」
　
(２)検討
　本願明細書の段落【０００５】には、「本発明は上記に鑑みてなされたものであって，ある問題領域のアプリケーションに共通となる要求仕様を分析して得られた仕様の不変／変動部に関する情報を利用して，再利用可能ソフトウェアの設計を自動生成することを目的とする。」と記載されている。
　したがって、装置発明である本願発明になる「ソフトウェア開発支援装置」が、「要求仕様を分析して得られた仕様の不変／変動部に関する情報を利用して」どのようにして「再利用可能ソフトウェアの設計を自動生成する」のかが、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に、本願明細書の発明の詳細な説明には記載されている必要があるものである。
　この点につき、以下に検討する。
　
(２−１)「クラス設計情報」への変換に関して
　本願発明における「クラス設計情報」は「再利用可能ソフトウェア部品のクラス構成を示す」情報である。したがって、前記「第２．平成１８年９月４日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「(２)検討」において記載したと同じ理由により、本願発明における「クラス設計情報」は、本願明細書に記載されたフレームワークに該当すると認められる。
　本願明細書には、前記フレームワーク、特にその生成、すなわち、フレームワークへの変換について、以下の記載がある。
Ａ．段落【００１９】〜【００２０】に、「各クラスの役割を以下に示す。」、「Controller　：システムを制御する。」こと、
Ｂ．段落【００１７】に、「仕様記述（分析モデル）の記述形式の記法」として、分析モデルの各クラスにおいて、その属性ないし振る舞いの動作が「変動部である場合，先頭にキーワードｖａｒｉａｎｔを記述する」こと、
Ｃ．段落【００２１】には、分析モデルに基づいて生成されたフレームワークは「その問題領域におけるアプリケーション群に共通する振る舞いは既に実装されていて，変動する部分が抽象クラスおよび抽象メソッドとして定義される」こと、
Ｄ．段落【００２２】に、「このようなフレームワークを設計するためにはデザインパターンを利用するのが有効である」こと、
Ｅ．段落【００２５】に「本発明のソフトウェア部品開発支援装置は，入力されたモデル（図２参照）の中でvariant キーワードを付加された情報を検索してこれを解析し，上記の２つの設計案をグラフィックスで表示する。各表示においては設計のポイントとなる部分をハイライトし，これをマウスでクリックすることによって解説を表示する機能を提供する。ユーザはこれらのうちから選択することによってフレームワーク設計を確定することができる。」こと、
Ｆ．前記「２つの設計案」について、段落【００２３】に、「例題では，センサーの種類が変動部分となっているので，Sensorクラスが抽象クラスとなり，メソッドtestが抽象メソッドとなる。さらにSensorオブジェクトの参照をControllerが知る方法として，例えば，２つの設計案が考えられる」こと、
がそれぞれ記載されている。
　
　しかしながら、前記Ａ〜Ｆは、「クラス設計情報」に該当すると認められるフレームワークの設計を確定するための手順を記載するに止まるものであって、確定されたフレームワークの設計に基づいて、具体的にどのようにして、フレームワークに変換するかを開示するものではない。
　そして、本願明細書の他の箇所を参照しても、「変換部１０４」はどのような構成を有し、入力された「仕様が変更される変動部が示された分析モデル」に基づいて「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」にどのように「変換する」のか、たとえば、デザインパターンを具体的にはどのように利用するのか、何ら記載されておらず、前記の点は本願明細書の記載からは不明である。
　
　ところで、上記のように、「フレームワークの生成」について説明した本願明細書の段落【００２１】〜【００２５】には、結局、前記「２つの設計案」を１つに確定することしか記載されていない。したがって、本願明細書の発明の詳細な説明に記載された前記「２つの設計案」ないしは前記「２つの設計案」の中の確定された１つが、本願発明の「ソフトウェア部品開発支援装置」の「変換手段」が生成する「再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に該当するとも考えられる。
　しかしながら、前記「２つの設計案」の生成については、前記Ｆのように、「Sensorクラスが抽象クラスとなり…(中略)…Sensorオブジェクトの参照をControllerが知る方法として，例えば，２つの設計案が考えられる」と記載されているのみであって、この「Sensorオブジェクトの参照をControllerが知る…(中略)…２つの設計案」を「考え」るのが、人間であるのか「変換手段」であるのかについても不明であり、仮に「変換手段」が「考え」るとしても、「Sensorオブジェクトの参照をControllerが知る」ことができる「２つの設計案」を、具体的に如何なる構成によって「考え」るのか何ら記載されていない。
　したがって、前記「２つの設計案」ないしはその中の確定された１つが、本願発明の「再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に該当するとしても、「変換部１０４」は、「変動部である場合，先頭にキーワードｖａｒｉａｎｔを記述する」分析モデルに基づいて、前記「Sensorクラスが抽象クラス」であるところの当該「Sensorオブジェクトの参照」をシステムを制御する役割を持つ「Controllerが知る」ことができる前記「設計案」に、具体的にどのようにして「変換」するのか、本願明細書の発明の詳細な説明には何ら記載されていない。
　
(２−２)「アプリケーションジェネレータ」への変換に関して
　本願明細書には、アプリケーションジェネレータの生成、すなわち、アプリケーションジェネレータへの変換について、前記「第２．平成１８年９月４日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「(３)アプリケーションジェネレータも「クラス設計情報」に該当すると仮定した場合の検討」において示したように、
Ｆ．段落【００２９】に、「本発明のソフトウェア部品開発支援装置は，入力されたモデル（図２参照）の中でvariant キーワードを付加された情報を検索してこれを解析し，先ず，
３
１
と記載されている。
　上記の「先ず，
３
　
　してみれば、前記(２−１)の検討において指摘したように、フレームワークにどのようにして「変換」するのか、本願明細書の記載からは不明である以上、該フレームワークを利用して生成するＧＵＩとしてのアプリケーションジェネレータに、具体的にどのようにして「変換」するのか、本願明細書の記載からは不明である。
　
(２−３)審判請求人の主張に対して
　審判請求人は、前記「(１)」のように、「分析モデルに基づいて、クラス設計情報及びアプリケーションジェネレータを生成することは、従来から用いられている技術を用いて実現可能です。」と主張している。
　そして、前記「従来から用いられている技術」として、「クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は、ＣＡＳＥツールの一機能として当業者において周知の技術である。例えば、Rational社のRoseは（段落０００２）、オブジェクト指向のソフトウェア開発を支援するＣＡＳＥツールとして周知であるが、当該ツールでクラス図からクラス構成が示されたプログラムのソースを出力する機能が備えられている。」と記載されている。
　
　上記「従来から用いられている技術」の具体例を挙げた記載は、「クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は、ＣＡＳＥツールの一機能として当業者において周知の技術」であるのは、「ＣＡＳＥツールとして周知」な「Rational社のRose」に「当該ツールでクラス図からクラス構成が示されたプログラムのソースを出力する機能が備えられている」からである、というものであると認められる。
　しかしながら、「ＣＡＳＥツールとして周知」な「Rational社のRose」に「当該ツールでクラス図からクラス構成が示されたプログラムのソースを出力する機能が備えられている」からと言って、何故、「クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は、ＣＡＳＥツールの一機能として当業者において周知の技術」となるのか、不明である。
　
　また、本願明細書の発明の詳細な説明に記載されたソフトウェア部品開発支援装置を実施するには、前記「(２−１)」及び「(２−２)」に記載したように、「変動部である場合，先頭にキーワードｖａｒｉａｎｔを記述する」分析モデルに基づいて、「Sensorクラスが抽象クラス」であるところの当該「Sensorオブジェクトの参照」をシステムを制御する役割を持つ「Controllerが知る」ことができる「設計案」に変換できる「変換器１０４」を備えることが必要である。
　そして、仮に、上位概念として「クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は、ＣＡＳＥツールの一機能として当業者において周知の技術」であるとしても、「仕様が変更される変動部が示された分析モデル」に基づいて、抽象クラスのオブジェクトの参照をシステムを制御する役割を持つクラスが知ることができるような設計案ないしはワークフレーム、すなわち、「クラス設計情報」に変換する「変換手段」がどのようなものとなるのか、本願明細書の発明の詳細な説明の記載及び前記「周知の技術」に基づいて、当業者であれば明らかであるとは認められない。
　
(３)小括
　以上のように、本願明細書には、「本発明は上記に鑑みてなされたものであって，ある問題領域のアプリケーションに共通となる要求仕様を分析して得られた仕様の不変／変動部に関する情報を利用して，再利用可能ソフトウェアの設計を自動生成することを目的とする。」と記載されながら、該「再利用可能ソフトウェアの設計」に不可欠な「クラス設計情報」ないしは「アプリケーションジェネレータ」に変換する「変換手段」の、実施可能な態様は何ら記載されていない。　
　そして、仮に「クラス図からソフトウェア部品のクラス構成を示すクラス設計情報に変換する技術は……当業者において周知の技術」であるとしても、「アプリケーション毎に仕様が変更される変動部が示された分析モデル」に基づいて「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段」の構成が具体的に如何なるものであるか、該周知の技術に基づいて当業者には明らかなものであるとも認められない。
　
　以上のとおりであるから、本願明細書の発明の詳細な説明を全体としてみても、該発明の詳細な説明には、入力が受け付けられた前記「アプリケーション毎に仕様が変更される変動部が示された分析モデル」に基づいて「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段」を発明を特定するために必要な事項として含む本願発明を、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されてはいない。
　
　
４．拒絶理由の３について
(１)引用発明
　原審の拒絶の査定に引用された刊行物である「小田利彦，“ＩＰＳシステムドメインにおける組み込み型システムの再構築プロセス”，電子情報通信学会技術研究報告，社団法人電子情報通信学会，１９９６年９月３０日，第９６巻，第２８２号，ｐｐ．９−１６」（以下、「引用文献」という。）には、図面とともに以下の記載がある。
　
Ａ．「あ ら ま し
　本論文では，ソフトウエア再利用による生産性向上を目指し，組み込み型システムで構成されたｌＰＳシステム群を対象にした再構築のプロセスを示す．そのプロセスは，システム間で共通な問題領域を同定してオブジェクト指向開発に基づくフレームワークをインクリメンタルに開発していくことである．」
　
Ｂ．「1 用語上，システムは製品に組み込まれるプログラム全体を表す．
2 IPS (Image Processing System)機器とは，ドキュメントを複写，読み込み、印刷，送受信する等の機能を持つ単体機能あるいは複合機能として備えるＯＡ機器の総称である．」（第１０頁左欄下から第８〜３行）
　
Ｃ．「●　ＩＰＳシステムドメインのシステム間に広く存在する共通／類似した問題領域を同定して再利用部品化する．
●　再利用部品として，プログラムの再利用ではなく専門知識や要求仕様，設計仕様といった高次情報の再利用が可能なオブジェクト指向フレームワーク（後述）を開発する．」（第１０頁右欄第６〜１２行）
　
Ｄ．「２．２．再利用部品としてのフレームワーク
　ソフトウエア生産性を向上させるＩＰＳシステムドメインの再構築では，共通性の高い問題領域に対して，再利用部品としてフレームワークを順次開発していく．この章ではフレームワークについて解説し，再利用部品としての有効性を示す．
２．２．１．フレームワーク
　フレームワークは，オブジェクト指向のソフトウエアであり，特定のアプリケーションにおいて再利用可能な抽象的設計を構成するクラスの集合である．フレームワーク内のクラスには抽象クラスと具象クラスがあり、抽象クラスで定義された抽象インターフェイスをサブクラスで実装することにより，個々のアプリケーションを開発する．抽象クラスを用いることによって，アプリケーションに共通の属性や制約を特定し，またアプリケーションの多様性を考慮することができる．また，フレームワークはアプリケーションに共通な機能や制御メカニズムの実装の大部分を既に含んでいる．」（第１１頁左欄第２１行〜同頁右欄第２行）
　
Ｅ．「この再構築シナリオでは，システムが徐々にオブジェクト指向技術に基づき実装された部分に変わっていく（図５参照）．次に再構築の主なステップを示す．ただし，ステップ２，３は並行するステップである．
Step1　再構築の調査
　1-1　システムドメイン内の各システムの問題領域を識別
　1-2　システム間での問題領域の共通性を評価して再構築対象として同定
　1-3　問題領域に開発順序のプライオリティを付与
Step2　再利用部品の開発
　すべての問題領域に対して，
　2-1　プライオリティに基づき問題領域を選択
　2-2　再利用部品の開発
　　 ・問題領域の要求仕様から分析モデルとしてＯＯＡモデルを作成
　　 ・設計モデルとしてフレームワークのクラス仕様を作成
　　 ・実装モデルをオブジェクト言語によりプログラミングして開発
　2-3　再利用部品の検証
　　 ・開発環境上の機能評価
　　 ・既存システムに組み込み実機上で性能評価
　2-4　リポジトリへの再利用部品を格納
Step3　再利用によるシステム開発
　新規システムの各モジュールに対して，
　3-1　リポジトリを検索してモジュールへの再利用部品を取り出す
　3-2　アプリケーションを開発
　　 ・分析モデルから問題領域を理解
　　 ・設計モデルから変更部分の設計
　　 ・実装モデルに対してアプリケーシヨン依存のプログラムを開発」（第１２頁右欄第５〜３８行）
　
Ｆ．「３．１．  Step1 再構築の調査
　……(中略)……
　次に，システム毎の問題領域関係図の比較分析を行い，共通性の高い問題領域を見つけ，再利用部品の開発候補として同定していく．再構築対象となる問題領域毎に対象範囲，要求仕様，制約仕様を定義する．さらに，問題領域における各アプリケーション毎に異なる仕様項目あるいは将来変更が予測される仕様項目を変動仕様としてリストアップする．
　最後に，再構築する効果を再利用頻度，問題領域の変動性，問題領域の知識の価値からなる３尺度を評価して総合的に順位付ける．
　再利用頻度は開発計画やシステム数から推定する．再利用時の理解や適用のコストを無視した場合，大規模部品（２ＫＬＯＣ以上）について再利用利得率（９２％）と開発コスト比（２５０％）から３回以上の再利用頻度であれば投資対効果が得られるという判断基準がある［磯田96］４ ．  　
　問題領域の変動性とは，問題領域におけるアプリケーション間で要求／制約仕様が変動する割合である．仕様変動が大きいと再利用時に改造や修正部分が大きくなり，再利用率の低下と再利用コストの増大を招くことになる．」（第１３頁右欄下から第５行目〜第１３頁右欄第４行）
　
Ｇ．「３．２．　Step2 再利用部品の開発
　インフラ開発部門においての部品開発では，問題領域毎に同時に並行して開発を行い，オブジェクト指向開発に基づき，分析モデル，設計モデル，実装モデルと段階を区切って開発する．
●分析フェーズ：分析モデルの目的は問題領域への要求を形式化すること，すなわち要求仕様を明確にして整理し，構成要素（オブジェクト）の識別と振る舞いをモデリングすることである．分析モデルは最終的な品質として機能完全性や無矛盾性，理解性について責任がある．
　分析モデルは，対象問題に存在する概念実体をオブジェクトとして識別し構造化したオブジェクトモデル，各オブジェクトの状態遷移を表現した状態モデル，機能をデータフローで表現したプロセスモデルから構成される［SM92］．
　分析モデルでは，１）対象世界の概念や構造を人間の認識に近く反映した理解性，２）問題領域の対象範囲をカバーしまたオーバーしない適度な抽象性，３）変更や拡張による影響範囲の局所化，の３ポイントを意識したモデリングを行う．
●設計フェーズ：設計モデルの目的は分析モデルに対してテスト容易性，信頼性，保守性，拡張性を反映したソフトウエア構造を決定することである．フレームワークの設計モデルは， クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成される．分析モデル中のオブジェクトはそのままかあるいは分割／併合されてクラスとして定義される一方，制約仕様から導かれるクラスが加わる．
　設計モデルではフレームワークの再利用性のために，変動部分に対して抽象クラスの定義，デザインパターン［GHJV95］の適用が鍵となる．
●実装フェーズ：実装モデルはプログラムである．設計モデルに対してオブジェクト関係の実装方法，アルゴリズムの選択，データ構造について決定し開発言語により記述する．
　……(中略)……
３．３．　Step3 再利用によるシステム開発
　製品開発では，リポジトリを検索して，システムを構成する問題領域毎に対応する再利用部品を取り出す．アプリケーションの開発では，再利用部品としてフレームワークだけでなく分析モデルや設計モデルという高次なモデルの利用により高い再利用効果が得られる．
　まず，分析モデルから問題領域の概念を理解し，次に設計モデルを調べて変更部分の設計と変更による影響範囲の分析を行う．この後，実装モデルすなわちフレームワークに対して，抽象ＩＦの実装あるいはサブクラスの定義を行いアプリケーションを実装する．」（第１３頁右欄第１４行〜第１４頁左欄第３６行）
　
Ｈ．「（３）フレームワークの品質
　ソフトウエアの品質特性に関しては多くの提案が知られているが，フレームワークについての品質特性をアプリケーション開発者の視点から調べる．重要な品質特性として，拡張性（更新性を含む），理解性，信頼性，性能の４点に注目する．
●   拡張性
　拡張性とは変化し続けるアプリケーションの要求仕様にフレームワークが対応できる能力である．フレームワークはアプリケーション固有部分だけを差分的に変更すればよい設計構造を持っているため，本来拡張性が高いとされる．しかし，あらかじめアプリケーションの仕様変動が把握できて確信的に抽象性やカプセル化の設計上の対応があってこそ可能なことである．」
　
Ｉ．「再利用部品の開発フロー」を図示した図７には、「固定」と「変動」からなる「要求仕様」を入力として、「分析モデル」を作成することが示されている。
　
　
ａ．Ａの「本論文では，ソフトウエア再利用による生産性向上を目指し，組み込み型システムで構成されたｌＰＳシステム群を対象にした再構築のプロセスを示す．そのプロセスは，システム間で共通な問題領域を同定してオブジェクト指向開発に基づくフレームワークをインクリメンタルに開発していくことである．」、
　Ｃの「再利用部品として，プログラムの再利用ではなく専門知識や要求仕様，設計仕様といった高次情報の再利用が可能なオブジェクト指向フレームワーク（後述）を開発する．」、
　Ｄの「ソフトウエア生産性を向上させるＩＰＳシステムドメインの再構築では，共通性の高い問題領域に対して，再利用部品としてフレームワークを順次開発していく．」から、
　引用文献には、
　再利用が可能な部品としてオブジェクト指向開発に基づくフレームワークを開発するソフトウェア開発方法、
が記載されている。
　
ｂ．Ｃの「ＩＰＳシステムドメインのシステム間に広く存在する共通／類似した問題領域を同定して再利用部品化する．」、
　Ｅの「Step1　再構築の調査
　1-1　システムドメイン内の各システムの問題領域を識別
　1-2　システム間での問題領域の共通性を評価して再構築対象として同定
　1-3　問題領域に開発順序のプライオリティを付与」、
　Ｆの「再構築対象となる問題領域毎に対象範囲，要求仕様，制約仕様を定義する．さらに，問題領域における各アプリケーション毎に異なる仕様項目あるいは将来変更が予測される仕様項目を変動仕様としてリストアップする．
　最後に，再構築する効果を再利用頻度，問題領域の変動性，問題領域の知識の価値からなる３尺度を評価して総合的に順位付ける．」及び「問題領域の変動性とは，問題領域におけるアプリケーション間で要求／制約仕様が変動する割合である．」から、
　引用文献には、再構築対象となる問題領域を調査して、対象範囲，要求仕様，制約仕様を定義するとともに、該問題領域における各アプリケーション毎に異なる仕様項目を変動仕様としてリストアップすること、問題領域毎の開発の順位付けを行うこと、が記載されている。
　
　そして、Ｆの上記の記載及びＩの図示態様から、問題領域におけるアプリケーション毎の要求仕様は、各アプリケーション毎に異なる仕様項目と、各アプリケーション間で固定の仕様項目とからなると解される。
　したがって、Ｅの「Step2　再利用部品の開発
　すべての問題領域に対して，
　2-1　プライオリティに基づき問題領域を選択
　2-2　再利用部品の開発
　　 ・問題領域の要求仕様から分析モデルとしてＯＯＡモデルを作成」の記載から、
　引用文献には、前記順位付けしたすべての問題領域に対して、各問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から分析モデルを作成することが記載されていると解される。
　
　さらに、Ｇの「分析モデルの目的は問題領域への要求を形式化すること，すなわち要求仕様を明確にして整理し，構成要素（オブジェクト）の識別と振る舞いをモデリングすることである．分析モデルは最終的な品質として機能完全性や無矛盾性，理解性について責任がある．…(中略)…分析モデルでは，１）対象世界の概念や構造を人間の認識に近く反映した理解性，２）問題領域の対象範囲をカバーしまたオーバーしない適度な抽象性，３）変更や拡張による影響範囲の局所化，の３ポイントを意識したモデリングを行う」との記載において、「問題領域への要求」とは、Ｅの「問題領域の要求仕様から分析モデルとしてＯＯＡモデルを作成」及びＩの図示態様から、問題領域におけるアプリケーション毎の要求仕様を指すことは明らかである。
　そして、Ｇの上記記載のように、「分析モデルは最終的な品質として機能完全性や無矛盾性，理解性について責任がある」とともに、「分析モデルでは…(中略)…変更や拡張による影響範囲の局所化…(中略)…を意識したモデリングを行う」のであるから、前記「問題領域への要求」を分析モデルにおいて「形式化する」に際して、「理解性」を保証し「変更や拡張による影響範囲の局所化」を意識するのであるから、当然に、分析モデルにおいて前記「各アプリケーション毎に異なる仕様項目」も形式化されるものと解される。
　
　したがって、引用文献には、
　再構築対象となる問題領域を調査して問題領域毎の開発の順位付けを行い、前記順位付けしたすべての問題領域に対して、各問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から、各アプリケーション毎に異なる仕様項目が形式化された分析モデルを作成する分析モデル作成工程、
が記載されていると解される。
　
ｃ．Ｇの「オブジェクト指向開発に基づき，分析モデル，設計モデル，実装モデルと段階を区切って開発する．」及び「設計モデルの目的は分析モデルに対してテスト容易性，信頼性，保守性，拡張性を反映したソフトウエア構造を決定することである．フレームワークの設計モデルは， クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成される．分析モデル中のオブジェクトはそのままかあるいは分割／併合されてクラスとして定義される一方，制約仕様から導かれるクラスが加わる．
　設計モデルではフレームワークの再利用性のために，変動部分に対して抽象クラスの定義，デザインパターン［GHJV95］の適用が鍵となる．」において、「変動部分」とは、Ｅ及びＦの上記の記載、Ｇの上記「分析モデル中のオブジェクトはそのままかあるいは分割／併合されてクラスとして定義される」から、分析モデルにおいて形式化されたアプリケーション毎に仕様項目が異なる部分を意味するものと認められる。
　したがって、引用文献には、
　前記作成された分析モデルに基づいて、分析モデルにおいて形式化されたアプリケーション毎に仕様項目が異なる部分に対して抽象クラスの定義が可能であり、クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成されるフレームワークの設計モデルを作成する設計モデル作成工程、
が記載されていると解される。
　
ｄ．Ｄの「フレームワークは，オブジェクト指向のソフトウエアであり，特定のアプリケーションにおいて再利用可能な抽象的設計を構成するクラスの集合である．フレームワーク内のクラスには抽象クラスと具象クラスがあり、抽象クラスで定義された抽象インターフェイスをサブクラスで実装することにより，個々のアプリケーションを開発する．抽象クラスを用いることによって，アプリケーションに共通の属性や制約を特定し，またアプリケーションの多様性を考慮することができる．」、Ｇの「●実装フェーズ：実装モデルはプログラムである．設計モデルに対してオブジェクト関係の実装方法，アルゴリズムの選択，データ構造について決定し開発言語により記述する．」及び「実装モデルすなわちフレームワーク」、Ｈの「フレームワークはアプリケーション固有部分だけを差分的に変更すればよい設計構造を持っている」から、引用文献には、
　前記作成された設計モデルに基づいて、アプリケーション固有部分だけを変更可能な設計構造を持ち、抽象的設計を構成する抽象クラスと具象クラスの集合としてのプログラムであるフレームワークを作成するフレームワーク作成工程、
が記載されている。
　
　ａ〜ｄから、引用文献には、次の発明(以下、「引用発明」という。)が記載されている。
　
　再利用が可能な部品としてオブジェクト指向開発に基づくフレームワークを開発するソフトウェア開発方法であって、
　再構築対象となる問題領域を調査して問題領域毎の開発の順位付けを行い、前記順位付けしたすべての問題領域に対して、各問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から、各アプリケーション毎に異なる仕様項目が形式化された分析モデルを作成する分析モデル作成工程と、
　前記作成された分析モデルに基づいて、前記分析モデルにおいて形式化されたアプリケーション毎に仕様項目が異なる部分に対して抽象クラスの定義が可能であり、クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成されるフレームワークの設計モデルを作成する設計モデル作成工程と、
　前記作成された設計モデルに基づいて、アプリケーション固有部分だけを変更可能な設計構造を持ち、抽象的設計を構成する抽象クラスと具象クラスの集合としてのプログラムであるフレームワークを作成するフレームワーク作成工程と、
を備えたことを特徴とするソフトウェア開発方法。
　
　
(２)対比
　本願発明と引用発明とを対比する。
　
　引用発明の「再利用が可能な部品」である「オブジェクト指向開発に基づくフレームワーク」は、本願発明の「オブジェクト指向による再利用可能なソフトウェア部品」に相当する。
　
　本願発明の「分析モデル」は「問題領域のアプリケーションに共通となる要求仕様の分析結果」である。
　しかしながら、該「分析モデル」の生成方法に関し、本願明細書には、段落【００１１】に「ある問題領域のアプリケーションに共通となる要求仕様の分析時に，仕様の変動性に関する情報を入力し，該情報を用いて要求仕様を分析して分析モデルを生成する」と、同段落【００１３】に「ある問題領域のアプリケーションに共通となる要求仕様を分析して得られた仕様の不変／変動部に関する情報を利用して」と記載され、本願明細書の発明の詳細な説明の記載においては、分析モデルは、ある問題領域のアプリケーションに共通となる要求仕様のみの分析結果に基づくものではなく、ある問題領域のアプリケーション毎に変動する要求仕様の分析結果にも基づくものである。
　してみれば、本願発明の「問題領域のアプリケーションに共通となる要求仕様の分析結果」とは、「問題領域のアプリケーションに共通となる要求仕様」を含む「分析結果」を意味していると解される。
　したがって、引用発明の「問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から」作成されたところの分析モデルとは、本願発明の「問題領域のアプリケーションに共通となる要求仕様の分析結果」である分析モデルと同義である。
　また、引用発明において、「再構築対象となる問題領域を調査して問題領域毎の開発の順位付けを行」うが、分析モデルは、結局、「すべての問題領域に対して」作成するものである。これに対して、本願発明における「ある問題領域」とは、本願明細書の段落【０００３】に「効率の良いアプリケーションソフトウェア開発を実現するためには再利用可能ソフトウェアを開発することが有効である。これを行うためには，その領域（問題領域）」との記載を参酌すれば、「再利用可能なソフトウェア部品の開発」の「ある問題領域」であると解される。
　したがって、引用発明の「再構築対象となる問題領域」の中の特定されない「各問題領域」の記載における「各」と、本願発明の「再利用可能なソフトウェア部品の開発」の「ある問題領域」の記載における「ある」とは、相違するところがない。
　引用発明において、分析モデルが「各アプリケーション毎に異なる仕様項目が形式化された」ので、仕様項目は「各アプリケーション毎に異なる」ように形式化できるものある。
　したがって、引用発明の、分析モデルが「各アプリケーション毎に異なる仕様項目が形式化された」ことと、本願発明の、分析モデルが「アプリケーション毎に仕様が変更される変動部が示された分析モデルの入力を受け付ける」ことと同義である。
　以上から、引用発明の「各問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から」作成する「各アプリケーション毎に異なる仕様項目が形式化された分析モデル」は、本願発明の「ある問題領域のアプリケーションに共通となる要求仕様の分析結果であり，アプリケーション毎に仕様が変更される変動部が示された分析モデル」に相当する。
　そして、引用発明において「分析モデルを作成する」ことは、該「分析モデル」が次の「設計モデル作成工程」で受け付けられることにつながるから、本願発明において「分析モデルの入力」をすることとは、「分析モデル」を受け付ける処理である点で共通する。
　
　引用発明の「クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成されるフレームワークの設計モデル」において、「クラス階層とクラスの操作とインターフェイスの完全な仕様の定義」は当該フレームワークについてのものであることは明らかである。そして、該「クラス階層とクラスの操作とインターフェイスの完全な仕様の定義」とは、フレームワークのクラス構成を示す情報に他ならない。
　そして、引用発明において、「フレームワークの設計モデル」が「分析モデルにおいて形式化されたアプリケーション毎に仕様項目が異なる部分に対して抽象クラスの定義が可能」であることは、本願発明において、「クラス設計情報」が「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能」であることと同義である。
　したがって、引用発明の「前記分析モデルにおいて形式化されたアプリケーション毎に仕様項目が異なる部分に対して抽象クラスの定義が可能であり、クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成されるフレームワークの設計モデル」は、本願発明の「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に相当する。
　
　また、本願発明の「分析モデルに基づいて……クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する」の記載は、何かを「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方」に変換するものではない。さらに、本願明細書の発明の詳細な説明の段落【００２１】〜【００３３】の記載を参酌すれば、「分析モデルに基づいて」、「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方」を「生成」すなわち作成することが記載されている。
　よって、本願発明の「変換」と、引用発明の「作成」との間に意味上の相違があるとは認められない。
　したがって、引用発明において「設計モデルを作成する」ことと、本願発明において「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する」をすることとは、クラス設計情報を作成する処理である点で一致する。
　
　引用発明が「再利用が可能な部品としてオブジェクト指向開発に基づくフレームワークを開発するソフトウェア開発方法」の発明であることと、本願発明が「オブジェクト指向による再利用可能なソフトウェア部品の開発を支援するソフトウェア部品開発支援装置」の発明であることとは、いずれも、オブジェクト指向による再利用可能なソフトウェア部品の開発についての発明である点で、共通する。
　
　
　以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の各点で相違している。
（一致点）
　オブジェクト指向による再利用可能なソフトウェア部品の開発についての発明において，
　ある問題領域のアプリケーションに共通となる要求仕様の分析結果であり，アプリケーション毎に仕様が変更される変動部が示された分析モデルの入力を受け付ける処理と，
　前記受け付けられた前記分析モデルに基づいて，アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報を作成する処理と，
　を備えたことを特徴とするソフトウェア部品の開発についての発明。
　
（相違点１）
　本願発明は「オブジェクト指向による再利用可能なソフトウェア部品の開発を支援するソフトウェア部品開発支援装置」の発明であるのに対し、引用発明は「再利用が可能な部品としてオブジェクト指向開発に基づくフレームワークを開発するソフトウェア開発方法」の発明である点。
　
（相違点２）
　本願発明は「分析モデルの入力を受け付ける分析モデル入力受付手段」を備えるのに対して、引用発明は「分析モデルを作成する分析モデル作成工程」を備える点。
　
（相違点３）
　本願発明は「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段」を備えるのに対して、引用発明は「設計モデルを作成する設計モデル作成工程」を備える点。
　
　
(３)判断
　相違点１〜３について
　本願出願前に頒布された刊行物である「Lockheed Martin Advanced Concepts Center Rational Software Corporation著，藤井拓 他監訳，オブジェクト指向開発自由自在−Ｒｏｓｅで実践するＯＭＴ法とＢｏｏｃｈ法，株式会社トッパン，１９９７年２月２４日，初版，ｐｐ．２４３−２５０」には、図面とともに以下の記載がある 。
　
ア．「市販のクラスライブラリの選定
　プロジェクトで再利用を行う最も手早い方法は、再利用可能なクラスライブラリを購入することです。今日の市場では、ＧＵＩ部品や通信のメカニズムから特定の業種向けのライブラリにいたるまで、多数の市販ライブラリがあります。しかしプロジェクトで使用するためにライブラリを選択するときには注意しなければなりません。ライブラリは、少なくとも以下の基準を用いて評価されなければなりません。
　■完全性−ライブラリは、提供するとうたっている全機能を網羅したクラス体系を提供していなければなりません。」（第２４４頁第１〜１３行）
　
イ．「モデルへの市販のライブラリクラスの追加
　市販のクラスライブラリは、Rational Roseアナライザーを使用してリバースエンジニアリングすることができます。このツールはＣ++コードを解析し、Rational Rose用のモデルファイル（＊.md1ファイル）を生成します。履修コース登録システムでは、Booch Componentsライブラリが、基本クラスライブラリとして選択されています。今回は、登録システムのモデルにこのライブラリを組み込みます。ライブラリを開発中のモデルに組み込むことによって、設計者は分析から得られたクラスが市販クラスとどのようにやり取りするかを、グラフイカルに表示することができます。」（第２４４頁第１９〜２６行）
　
ウ．「Rational Rose/C++アナライザーでのプロジェクトのセットアップ
　……(中略)……
　10．　ディレクトリ内のすべてのファイルをコード解析するには、［すべて追加］ボタンをクリックします。
　11．　選択したファイルだけをコード解析するには、そのファイルを選択して［追加］ボタンをクリックします。」（第２４４頁第２７行〜第２４５頁第１５行）
　
エ．「Rational Rose/C++アナライザーによるファイルのコード解析
　１．　コード解析したいファイルをリストから選択します。
　２．　［アクション］：［コードサイクル］コマンドを選択します。すると、ファイルを更新してよいかどうかたすねられます。［はい］ボタンをクリックします。この結果、Roseのコード生成機能が必要とするマーカーがファイルに挿入されます。
　３．　コード解析が終了すると、次の図のようにウインドウが更新されてファイルのコードサイクルが行われたことが示されます。」（第２４６頁第２〜８行）
　
オ．「Rational Rose/C++アナライザーからのファイルのエクスポート
　……(中略)……
　これで、アナライザーによってモデルが生成され、.md1ファイルをRoseにロードしてモデルを表示することができます。」（第４２６頁第９行〜第２４７頁第２行）
　
カ．「Rational Roseでのモデル管理ユニットのロード
　１．　［ファイル］：［開く］コマンドを選択します。
　２．　モデルファイル（.md1ファイル）の名前を選択して、［ＯＫ］ボタンを選択します。
　３．　［ファイル］：「モデル管理ユニット］：［ロード］コマンドを選択します。
　４．  ロードする.catファイルを選択します。
　５．　［ＯＫ］ボタンをクリックします。
　……(中略)……
　次ページの図29-6には、履修コース登録システムのトップレベルの図が示されています。」（第２４９頁第１〜１１行）
　
キ．「用語解説
クラスライブラリ    メーカーから購入したクラスの集合。」（第２５０頁第７〜８行）
　
　前記刊行物は、オブジェクト指向によるソフトウェア開発を支援するツールと周知なRational社のRoseを用いて、具体的にどのように「オブジェクト指向開発」を行うかを同社によって説明したものである。
　そして、ア〜カから、登録システムのモデルにメーカーから購入したクラスのライブラリを組み込んだものをRational Rose/C++アナライザーに入力することで、該Rational Rose/C++アナライザーは、登録システムのモデルにメーカーから購入したクラスを組み込んだものを、分析から得られたクラスが市販クラスとどのようにやり取りするかを示す新たなモデルに変換して、Rational Roseは、Rational Roseでのモデル管理ユニットによって、この新たなモデルをグラフイカルに表示することは、周知技術にすぎない。
　
　また、本願出願前に頒布された刊行物である「中谷多哉子著，オブジェクト指向分析・設計　２．例題によるオブジェクト指向のモデル化作法−オブジェクト指向分析の落し穴†−，情報処理，社団法人情報処理学会，１９９４年５月１５日，第３５巻，第５号，ｐｐ．４０２−４１１」には、図面とともに以下の記載がある 。
　
ク．「３．４再利用を考慮したモデルの進化
　オブジェクト．モデルの再利用を考慮すると，オブジェクトの構造も変化することがある．３．３で述べた要求変更は同一アプリケーションに対するものであるが，再利用は類似アプリケーションへのモデルの適用である．この場合は，実装の類似性よりも，オブジェクトの仕様の類似性に着目して抽象クラスを定義したほうが良い．
　分析時の限られた情報から，将来の再利用を予想することは困難であるが，最小限，継承構造が可読性を落とすようなモデル化の失敗は避ける必要がある．そのためには，実世界のインスタンスから定義したクラス間の継承に基づいて，将来の類似クラスへの再利用性を配慮するほうが良い．」（第４０８頁左欄第５〜１２行）
　
　同様に本願出願前に頒布された刊行物である「鰺坂恒夫 他著，ＯＯ’９７オブジェクト指向モデリングワークショップ報告，情報処理学会研究報告，社団法人情報処理学会，１９９７年９月１１日，第９７巻，第８４号，ｐｐ．３３−４３」には、図面とともに以下の記載がある 。
　
ケ．「３．３．３ 仕様変更への対応についての考察
　同じような操作や属性をもったクラスが複数出てきた金銭を処理する機器については抽象クラスを作成できたので、仕様変更に対して対応しやすいと考えられる。
　それ以外の部分に対しては抽象クラスを作成しなかったが、各クラス自体のもつ操作や属性が大きく変わらない範囲の仕様変更であれば、同様に抽象クラスを作成しておく事により対応出来ると考えられる。」（第３７頁右欄第１１〜１８行）
　
　ク、ケのように、オブジェクト指向によるソフトウェア開発におけるモデル化に際して、仕様変更が行われる部分に対しては抽象クラスを作成・定義することは、常套手段である。
　
　
　ところで、引用文献において、フレームワークの設計モデルをどのような手段により作成するかについての記載はないことから、分析モデルに基づく前記設計モデルの作成は人間の思考活動によって行うと認められる。
　しかしながら、コンピュータを利用して人間が行う思考活動を可能な限り支援しようとすることは、コンピュータ技術において通常なされる事項にすぎない。
　また、前記したように、ソフトウェアであるRational Roseアナライザーを利用して、登録システムのモデルに別のクラスを組み込んだものを、分析から得られたクラスが該別のクラスとどのようにやり取りするかを示す新たなモデルに変換することは周知技術である
　そして、上記のように、モデル化に際して、仕様変更が行われる部分に対しては抽象クラスを作成・定義することは、オブジェクト指向によるソフトウェア開発において常套手段であることを考慮すれば、引用発明の「ソフトウェア開発方法」をコンピュータを利用して支援するべく、当該コンピュータに分析モデルの入力手段を設けるとともに、該コンピュータにソフトウェアであるRational Roseアナライザーを搭載して該ソフトウェアであるRational Roseアナライザーによって、入力された「各問題領域における各アプリケーション間で固定の仕様項目と各アプリケーション毎に異なる仕様項目とからなる要求仕様から」作成した「各アプリケーション毎に異なる仕様項目が形式化された分析モデル」を、クラス間のやり取りを具体的に明示できるように、クラス階層とクラスの操作とインターフェイスの完全な仕様の定義を行い、かつ、アプリケーション毎に仕様項目が異なる部分に対しては抽象クラスの定義をした設計モデルに変換すること、すなわち、当該コンピュータを変換手段として機能させることは、当業者が容易に想到し得たものと認められる。
　
　以上から、相違点１〜３は格別のものではない。
　
　
(４)付記
　引用発明において、「抽象的設計を構成する抽象クラスと具象クラスの集合としてのプログラムであるフレームワーク」は、該フレームワークの作成に用いる「フレームワークの設計モデル」が「クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成される」ものであるから、単なる「抽象クラスと具象クラス」の集まりではなく、該「設計モデル」から、抽象的設計として、抽象クラスと具象クラスのクラス階層の情報や、インターフェイスの完全な仕様の情報を継承していることは明らかである。したがって、引用発明の「フレームワーク」も当然に「クラス構成情報」を有する。
　そして、引用発明の「フレームワーク」は「アプリケーション固有部分だけを変更可能な設計構造」を持つ。
　以上から、引用発明の「フレームワーク」が、本願発明の「アプリケーション毎に前記分析モデルに示された前記変動部に対して入力可能な，前記再利用可能ソフトウェア部品のクラス構成を示すクラス設計情報」に相当するとも考えられる。
　
　この場合、引用発明の「フレームワーク」は「設計モデルに基づいて」作成されるものであり、本願発明の「クラス設計情報」は「分析モデルに基づいて」変換される点で、一見、相違する。
　しかし、本願明細書の段落【００２５】に、入力された分析モデルを解析して「２つの設計案」を導き、該「２つの設計案」のいづれか一方を選択することで「フレームワーク設計を確定する」ことが記載されている。そして、フレームワーク自体は、「フレームワーク設計を確定する」ことで変換されるものと解される。
　してみれば、本願発明において、「分析モデルに基づいて」、「クラス設計情報……変換する」とは、分析モデルそのものを「クラス設計情報」に変換することを意味するのではなく、「分析モデルに基づいて」間接的に「クラス設計情報……変換する」ことを意味すると解される。
　
　したがって、このとき、本願発明と引用発明とは、前記一致点で一致するとともに前記相違点１及び相違点２で相違することに加え、前記相違点３に代えて、
（相違点３’）
　本願発明は「クラス設計情報及びアプリケーションジェネレータのうち少なくともいずれか一方に変換する変換手段」を備えるのに対して、引用発明は「フレームワークを作成するフレームワーク作成工程」を備える点。
で相違する。
　
　しかしながら、前記本願出願前に頒布された刊行物である「Lockheed Martin Advanced Concepts Center Rational Software Corporation著，藤井拓 他監訳，オブジェクト指向開発自由自在−Ｒｏｓｅで実践するＯＭＴ法とＢｏｏｃｈ法，株式会社トッパン，１９９７年２月２４日，初版，ｐｐ．２４３−２５０」には、図面とともに以下の記載がある 。
　
コ．「コード生成
　Rational Roseは、非常に強力なＣ++コードの生成機能を備えています。コードジェネレータのオプションは、［ツール］：［プロパティ］：［プロパティの編集］コマンドを使用して設定します。モデル、クラス、「集約／保有」関係、属性、および操作に関連するプロパティがあります。モデル全体に適用されるプロパティでは、ファイル名、デフォルトのコンテナ名、コードの生成先などが指定できます。また、クラスプロパテイにより、コンストラクタ、デストラクタ、コピーコンストラクタ、等価演算子、get／setのためのメソッドの生成が指定でき、保有関係のプロパティによりget／setのためのメソッドの生成、メソッドの可視性、および使用するコンテナクラスが指定できます。さらに操作プロパティにより、操作の種類−一般（common）、仮想（virtual）、抽象（abstract）、スタティック（static）、またはフレンド（friend）−や、操作にconstを指定することができます。
　これらのプロパティセットは編集することができ、プロジェクトに必要なＣ++機能を指定するために、新しいセットを生成することもできます。コード生成を実行すると各クラスごとに、ヘッダファイル（.h）と仕様ファイル（.cpp）の２つのファイルが生成されます。
　
Rational Roseでのコードの生成
　１．　クラス図上でクラスまたはカテゴリをクリックします。
　２．  必要があれば、該当する要素（クラス、関係、属性、または操作）をクリックして、［ツール］：［プロパティ］：［プロパティの編集］コマンドを選択し、プロパテイセットの編集または新規プロパティセットの生成を行います。
　３．　［ツール］：［Ｃ++コード生成］コマンドを選択します。コードが生成され、システムからのメッセージがすべてログに書き込まれます。」（第１１４頁第２行〜第１１５頁第１２行）
　
　コから、ソフトウェアであるRational Roseを利用して、クラス図で示されるモデルをプログラムのコードに変換することは、周知技術である。
　ところで、引用発明において、「フレームワーク」は「抽象的設計を構成する抽象クラスと具象クラスの集合としてのプログラム」である。そして、「設計モデル」は「クラス階層とクラスの操作とインターフェイスの完全な仕様の定義から構成される」のであるから、該設計モデルをクラス図として表現することは当業者であれば当然になし得たことである。
　してみれば、引用発明において、フレームワークの作成をコンピュータによって支援するため、当該コンピュータに分析モデルの入力手段を設けるとともに、該コンピュータ上で該分析モデルに基づいてクラス図として設計モデルを作成し、ソフトウェアであるRational Roseを用いて、該クラス図としての設計モデルを、クラス構成を示すプログラムのコードに変換することで、当該コンピュータを変換手段として機能させることは、当業者が容易に想到し得たものと認められる。
　したがって、相違点１〜３’は格別のものではない。
　
　
(５)小括
　以上のとおり、本願発明は、引用文献に記載された発明及び周知技術、常套手段から、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により、特許を受けることができない。
　
　
５．むすび
　したがって、本願は、明細書及び図面の記載が、特許法第３６条第４項に規定する要件を満たしていない。
　また、本願発明は、引用文献に記載された発明及び周知技術、常套手段から、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により、特許を受けることができない。
　
　よって、結論のとおり審決する。