【事件の表示】
　特願２００９−　９９９９１「プログラム開発支援装置」拒絶査定不服審判事件〔平成２２年１１月　４日出願公開，特開２０１０−２５０５９８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２１年４月１６日を出願日とする出願であって，平成２４年１月１８日付けで審査請求がなされ，平成２５年６月１４日付けで拒絶理由通知（同年６月１８日発送）がなされ，これに対して同年７月８日付けで意見書が提出されると共に手続補正書が提出されたが，同年８月２９日付けで拒絶査定（同年９月３日謄本送達）がなされた。　
　これに対して，「原査定を取り消す，本願は特許をすべきものであるとの審決を求める。」との請求の趣旨で，平成２５年１０月１７日付けで審判請求がなされると共に，同日付けで手続補正がなされたものである。
　そして，平成２６年１月１０日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされた。　
　
　
第２　平成２５年１０月１７日付けの手続補正についての補正却下の決定 
　
 ［補正却下の決定の結論］ 
　
　平成２５年１０月１７日付けの手続補正を却下する。
　
 ［理由］ 
　
 １．補正の内容
　
　平成２５年１０月１７日付けの手続補正（以下，「本件補正」という。）の内容は，平成２５年７月８日付けの手続補正により補正された特許請求の範囲の請求項１乃至４の記載
　
「　　【請求項１】
　入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置であって，
　上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段，
　この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部，
　上記プログラムの関数の関数仕様は，上記下位関数を呼び出すときの入出力条件を含み，
　上記入出力条件を上記入力によって編集し，上記関数仕様編集手段に送る入出力条件編集手段，
　この入出力条件編集手段によって編集された上記入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を上記入出力条件編集手段に送る入出力条件検査手段，
　編集済みの上記プログラムの関数の関数仕様の上記入出力条件から上記下位関数のスタブ関数を生成するスタブ関数生成手段，
　このスタブ関数生成手段によって生成されたスタブ関数を格納するスタブ関数記憶部を備えたことを特徴とするプログラム開発支援装置。
　　【請求項２】
　上記プログラムの関数の関数仕様に含まれる入出力条件には，上記下位関数の関数仕様に入力された入出力条件の一部の情報が自動入力されることを特徴とする請求項１に記載のプログラム開発支援装置。
　　【請求項３】
　上記入出力条件編集手段は，上記入出力条件検査手段によるチェックの結果，不整合がある場合には，不整合箇所を上記プログラムの関数の関数仕様上に表示することを特徴とする請求項１または請求項２に記載のプログラム開発支援装置。
　　【請求項４】
　上記スタブ関数生成手段による上記スタブ関数の生成を行わないように指定する手段を備えたことを特徴とする請求項１〜請求項３のいずれかに記載のプログラム開発支援装置。」（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
　
を，
　
「　　【請求項１】
　入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置であって，
　上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段，
　この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部，
　上記プログラムの関数の関数仕様は，上記下位関数を呼び出すときの入出力条件を含み，
　上記入出力条件を上記入力によって編集し，上記関数仕様編集手段に送る入出力条件編集手段，
　この入出力条件編集手段によって編集された上記入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を上記入出力条件編集手段に送る入出力条件検査手段，
　
上記関数仕様編集手段により
直接
　このスタブ関数生成手段によって生成されたスタブ関数を格納するスタブ関数記憶部を備えたことを特徴とするプログラム開発支援装置。
　　【請求項２】
　上記プログラムの関数の関数仕様に含まれる入出力条件には，上記下位関数の関数仕様に入力された入出力条件の一部の情報が自動入力されることを特徴とする請求項１に記載のプログラム開発支援装置。
　　【請求項３】
　上記入出力条件編集手段は，上記入出力条件検査手段によるチェックの結果，不整合がある場合には，不整合箇所を上記プログラムの関数の関数仕様上に表示することを特徴とする請求項１または請求項２に記載のプログラム開発支援装置。
　　【請求項４】
　上記スタブ関数生成手段による上記スタブ関数の生成を行わないように指定する手段を備えたことを特徴とする請求項１〜請求項３のいずれか一項に記載のプログラム開発支援装置。」（以下，この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
　
に補正するものである。
　
　そして，本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてなされており，特許法第１７条の２第３項の規定に適合している。
　
　
２．目的要件
　
　本件補正が，特許法１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。　
　
　本件補正は，補正前の請求項１に記載した発明を特定するために必要な事項である「編集済みの上記プログラムの関数の関数仕様の上記入出力条件から上記下位関数のスタブ関数を生成するスタブ関数生成手段」を「
上記関数仕様編集手段により
直接
　また，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
　したがって，本件補正は，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当することから，特許法１７条の２第５項の規定を満たすものである。
　
　
３．独立特許要件
　
　以上のように，本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）は，補正前の請求項１に対して，限定的減縮を行ったものと認められる。そこで，本件補正発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。
　
（１）本件補正発明
　
　本件補正発明は，上記平成２５年１０月１７日付け手続補正書により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。　
　
「入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置であって，
　上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段，
　この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部，
　上記プログラムの関数の関数仕様は，上記下位関数を呼び出すときの入出力条件を含み，
　上記入出力条件を上記入力によって編集し，上記関数仕様編集手段に送る入出力条件編集手段，
　この入出力条件編集手段によって編集された上記入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を上記入出力条件編集手段に送る入出力条件検査手段，
　上記関数仕様編集手段により編集済みの上記プログラムの関数の関数仕様の上記入出力条件から直接上記下位関数のスタブ関数を生成するスタブ関数生成手段，
　このスタブ関数生成手段によって生成されたスタブ関数を格納するスタブ関数記憶部を備えたことを特徴とするプログラム開発支援装置。」　
　
　
（２）引用文献
　
（２−１）引用発明及び引用文献１に記載されている技術的事項
　
　本願出願前に頒布され，原審の拒絶査定の理由である上記平成２５年６月１４日付けの拒絶理由通知において引用された，特開平４−１６８５２５号公報（平成４年６月１６日出願公開，以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「
この発明は，このような事情に鑑みてなされたものであって，複数のモジュール間でのデータ定義を一括して管理することにより，各モジュール間でのデータ定義の検証を迅速に行うことができるプログラム部品生成システム提供することを目的としている。
　
Ｂ　「Ｆ．実施例
　以下，この発明の一実施例を図面に基づいて説明する。
　
第１図は，プログラム部品生成システムの概略構成を示したブロック図である。
　
図中，符号１は，ディスプレイ２とキーボード３とを備えて，オペレータによるモジュール仕様書の作成を支援するモジュール仕様書作成支援部である。
　
ここで作成されるモジュール仕様書は，メインプログラムおよび，これに呼び出されて利用されるサブプログラムの仕様を記述したものである。
　
以下，メインプログラムの仕様を記述した仕様書を最上位モジュール仕様書，サブプログラムの仕様を記述したものを下位モジュール仕様書と称する。
　
Ｃ　「最上位モジュール仕様書Ａの一例を第２図に，下位モジュール仕様書ａの一例を第３図に示し，以下に説明する。
　すなわち，モジュール仕様書は，
［１］モジュールの名称
［２］機能概要
［３］データ定義
［４］関数定義
［５］処理手順
などの項目で構成されている。
…（中略）…
　［４］の関数定義項目は，下位モジュールを有するモジュールのみに記述されるもので，最上位モジュールはもちろんのこと，その下位モジュールがさらに下位のモジュールを有する場合には，下位モジュールにも記述される。」（第３頁左下欄第４行〜右下欄第１３行）
　
Ｄ　「次に，上述した装置の動作を説明する。
　
まず，オペレータはモジュール仕様書作成支援部１を起動して，モジュール仕様書を作成する。
　
ここで，作成されるモジュール仕様書が，第２図に示す最上位モジュール仕様書Ａ，第３図に示す下位モジュールａであったとする。これらのモジュール仕様書はモジュール仕様書記憶部４に格納される。
　
Ｅ　「
次に，最上位モジュール仕様書Ａと下位モジュール仕様書ａとの間での入出力データ定義が一致しているかどうかの検証処理について，第７図のフローチャートを参照して説明する。なお，この検証処理は第１図示の検証部８によって実行される処理である。
…（中略）…
　
すなわち，このステップＴ４では，最上位モジュールＡが下位モジュールａに受け渡す入出力データ名と，下位モジュール仕様書ａ内で記述されている入出力データ名が一致しているかどうかの判断を行う。一致していなければ，ステップＴ７に進んでモジュール仕様書作成支援部１を介し，モニタディスプレイ２にエラー表示を行う。一致していれば次のステップＴ５に進む。
　
ステップＴ５：ステップＴ２で抽出した入出力データ名，型で，データ定義記憶部６内を検索していき，そこで登録されているかどうを判断する。すなわち，このステップでは，最上位モジュール仕様書Ａで定義されている入出力データ名，型が，下位モジュール仕様書ａでも同じ名称，型で記述されているかの検証を行う。同じ名称，型のデータが，データ定義記憶部６内に登録されていなければ，異なった名称，型で記述されているとして先と同様にステップＴ７に進んでエラー表示を行う，登録されていればステップＴ６に進み，下位モジュール仕様書ａをソースコード生成部９に送出する。なお，上記エラー表示の結果，オペレータはモジュール仕様書作成支援部１を起動してモジュール仕様書の修正を行う。
　
　ここで，上記引用文献１に記載されている事項を検討する。　
　
（ア）上記Ａの「この発明は，このような事情に鑑みてなされたものであって，複数のモジュール間でのデータ定義を一括して管理することにより，各モジュール間でのデータ定義の検証を迅速に行うことができるプログラム部品生成システム提供することを目的としている。」との記載，上記Ｂの「第１図は，プログラム部品生成システムの概略構成を示したブロック図である。図中，符号１は，ディスプレイ２とキーボード３とを備えて，オペレータによるモジュール仕様書の作成を支援するモジュール仕様書作成支援部である。」との記載からすると，「プログラム部品生成システム」はディスプレイとキーボードとを備えて，モジュール間でのデータ定義などを記述した「モジュール仕様書」の作成を支援するものであると解され，また，上記Ｂの「ここで作成されるモジュール仕様書は，メインプログラムおよび，これに呼び出されて利用されるサブプログラムの仕様を記述したものである。以下，メインプログラムの仕様を記述した仕様書を最上位モジュール仕様書，サブプログラムの仕様を記述したものを下位モジュール仕様書と称する。」との記載からすると，「モジュール仕様書」は「最上位モジュール仕様書」と「下位モジュール仕様書」を含むことは明らかであるから，引用文献１には，
「ディスプレイとキーボードとを備えて，最上位モジュール仕様書と下位モジュール仕様書を含むモジュール仕様書の作成を支援するプログラム部品生成システム」
が記載されていると解される。
　
（イ）上記Ｂの「図中，符号１は，ディスプレイ２とキーボード３とを備えて，オペレータによるモジュール仕様書の作成を支援するモジュール仕様書作成支援部である。ここで作成されるモジュール仕様書は，メインプログラムおよび，これに呼び出されて利用されるサブプログラムの仕様を記述したものである。以下，メインプログラムの仕様を記述した仕様書を最上位モジュール仕様書，サブプログラムの仕様を記述したものを下位モジュール仕様書と称する。」との記載からすると，「モジュール仕様書作成支援部」が「最上位モジュール仕様書」と「下位モジュール仕様書」を作成し，「下位モジュール」は「最上位モジュール」により呼び出される関係性を有することが読みとれる。
　また，上記Ｅの「すなわち，このステップＴ４では，最上位モジュールＡが下位モジュールａに受け渡す入出力データ名と，下位モジュール仕様書ａ内で記述されている入出力データ名が一致しているかどうかの判断を行う。一致していなければ，ステップＴ７に進んでモジュール仕様書作成支援部１を介し，モニタディスプレイ２にエラー表示を行う。一致していれば次のステップＴ５に進む。…（中略）…すなわち，このステップでは，最上位モジュール仕様書Ａで定義されている入出力データ名，型が，下位モジュール仕様書ａでも同じ名称，型で記述されているかの検証を行う。」との記載からすると，最上位モジュールが下位モジュールを呼び出す時には，最上位モジュール仕様書，下位モジュール仕様書のそれぞれに記述されている入出力データ名，型が受け渡されると解され，さらに，上記Ｅの「なお，上記エラー表示の結果，オペレータはモジュール仕様書作成支援部１を起動してモジュール仕様書の修正を行う。」との記載からすると，「最上位モジュール仕様書」と「下位モジュール仕様書」を含む「モジュール仕様書」に記述された「入出力データ名，型」は「モジュール仕様書作成支援部」により修正されることが読みとれるから，引用文献１には，
「最上位モジュール仕様書と，最上位モジュールに呼び出される下位モジュールの下位モジュール仕様書を作成するとともに，該最上位モジュール仕様書，該下位モジュール仕様書のそれぞれに記述され，該最上位モジュールが該下位モジュールを呼び出す時に受け渡される入出力データ名，型を修正するモジュール仕様書作成支援部」
が記載されていると解される。
　
（ウ）上記Ｄの「まず，オペレータはモジュール仕様書作成支援部１を起動して，モジュール仕様書を作成する。ここで，作成されるモジュール仕様書が，第２図に示す最上位モジュール仕様書Ａ，第３図に示す下位モジュールａであったとする。これらのモジュール仕様書はモジュール仕様書記憶部４に格納される。」との記載からすると，「モジュール仕様書作成支援部」によって作成あるいは修正された「モジュール仕様書」は「モジュール仕様書記憶部」に格納されることは明らかであるから，引用文献１には，
「モジュール仕様書作成支援部によって作成，修正されたモジュール仕様書を格納するモジュール仕様書記憶部」
が記載されていると解される。
　
（エ）上記Ｅの「次に，最上位モジュール仕様書Ａと下位モジュール仕様書ａとの間での入出力データ定義が一致しているかどうかの検証処理について，第７図のフローチャートを参照して説明する。なお，この検証処理は第１図示の検証部８によって実行される処理である。」との記載からすると，「検証部」が最上位モジュール仕様書と下位モジュール仕様書との間での入出力データ名，型などの入出力データ定義が一致しているかどうかの検証処理を実行すると解され，また，上記Ｅの「同じ名称，型のデータが，データ定義記憶部６内に登録されていなければ，異なった名称，型で記述されているとして先と同様にステップＴ７に進んでエラー表示を行う，登録されていればステップＴ６に進み，下位モジュール仕様書ａをソースコード生成部９に送出する。なお，上記エラー表示の結果，オペレータはモジュール仕様書作成支援部１を起動してモジュール仕様書の修正を行う。」との記載からすると，「検証部」が検証結果を「モジュール仕様書作成支援部」に送り，ディスプレイに表示することが読みとれるから，引用文献１には，
「最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証し，検証結果を前記モジュール仕様書作成支援部に送り，ディスプレイに表示する検証部」
が記載されていると解される。　
　
　以上，（ア）乃至（エ）で指摘した事項から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「ディスプレイとキーボードとを備えて，最上位モジュール仕様書と下位モジュール仕様書を含むモジュール仕様書の作成を支援するプログラム部品生成システムであって，
　最上位モジュール仕様書と，最上位モジュールに呼び出される下位モジュールの下位モジュール仕様書を作成するとともに，該最上位モジュール仕様書，該下位モジュール仕様書のそれぞれに記述され，該最上位モジュールが該下位モジュールを呼び出す時に受け渡される入出力データ名，型を修正するモジュール仕様書作成支援部，
　前記モジュール仕様書作成支援部によって作成，修正されたモジュール仕様書を格納するモジュール仕様書記憶部，
　前記最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証し，検証結果を前記モジュール仕様書作成支援部に送り，ディスプレイに表示する検証部
を備えたプログラム部品生成システム。」　　
　
（２−２）引用文献２に記載されている技術的事項
　
　本願出願前に頒布され，原審の拒絶査定の理由である上記平成２５年６月１４日付けの拒絶理由通知において引用された，特開２００８−１４０２６３号公報（平成２０年６月１９日出願公開，以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｆ　「【０００２】
　従来の高級言語プログラムの単体試験方法として，下位の関数からプログラムを実装して試験を実施するボトムアップ方式の試験方法と，上位の関数からプログラムを実装して試験を実施するトップダウン方式の試験方法がある。一般に，ボトムアップ方式の試験では，試験対象の関数を呼び出す上位の関数を擬似するドライバ関数と呼ばれる関数の実装が必要となる。ドライバ関数は試験対象の関数の実行に必要な変数等に値を設定し，試験対象の関数を呼び出す。
一方，トップダウン方式の試験では，試験対象の関数が呼び出す下位の関数を擬似するスタブ関数と呼ばれる関数の実装が必要となる。スタブ関数は，試験対象の関数からの呼び出しに対して，試験対象の関数の実行を継続できるように，出力引数等の値を設定する。
　
Ｇ　「【００２０】
　スタブ関数生成部５は，スタブ関数Ｉ／Ｆ記憶部９に記憶されたＩ／Ｆ，及びＩ／Ｆの分析結果に基づき，スタブ関数を生成する。
【００２１】
　また，スタブ関数出力値生成部６は，スタブ関数Ｉ／Ｆ記憶部９に記憶されたＩ／Ｆ，Ｉ／Ｆ分析結果，及びソースコード記憶部８に記憶された試験対象プログラムに基づいて，スタブ関数の出力変数の出力値を生成し，出力変数及び出力値はスタブ関数記憶部１０に記憶される。」　
　
Ｈ　「【００３７】
　本実施の形態の効果について説明する。本実施の形態によれば，
スタブ関数を用いたソフトウェアの単体試験において，試験対象関数とこの試験関数が呼び出す下位関数との間のＩ／Ｆを実装したスタブ関数を自動的に生成することができる。これにより，スタブ関数の生成作業の効率が向上し，ソフトウェアの効率的な単体試験が可能となる。
　
　
（３）参考文献　
　
　本願出願前に頒布された，特開２００３−２９６１３９号公報（平成１５年１０月１７日出願公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｊ　「【００１４】
この技術思想は，検査対象を含む処理プログラムに対し，少なくとも関数コールの面で整合性の確認されたスタブ化対象ファイルが存在することを前提とするものである。
したがって，開発中の処理プログラムの関数コール部分に変更がなければ，既存の分野外プログラムを用いてスタブ関数を作成でき，整合性が保障されることになる。
　
Ｋ　「【００１９】なお，
スタブ関数は実質的な処理を行わないダミーの関数であるが，処理プログラムとの関数コールの整合性という意味においては，ダミーの戻り値を用意する必要が生じる。そこで，スタブ作成手段は，関数記述に基づき，当該関数の型を認識し，戻り値があるか否かを判断して，戻り値がある場合には，戻り値のための変数宣言及びリターン命令を追加することにより，スタブ関数を作成する構成にするとよい
　
Ｌ　「【００３１】スタブ化対象ファイルは，ソースプログラム８１とは別に用意される分野外プログラムであり，上述したＰＦなどを含む。ここにある技術思想は，
開発中のソースプログラム８１に対し，少なくとも関数コールの面で整合性の確認された分野外プログラムが存在することを前提とし，この分野外プログラムを用いてスタブ関数を作成するというものである。
　
　
（４）対比
　
　本件補正発明と引用発明とを対比する。
　
（４−１）引用発明の「モジュール仕様書」は，引用文献１の上記Ｃの記載からすると，関数定義を含むプログラムの仕様書であると解されることから，本件補正発明の「プログラムの関数の関数仕様」に相当するといえる。また，引用発明の「ディスプレイとキーボード」は「プログラム部品生成システム」の入出力を行うための手段であるから，本件補正発明の「入出力装置」に相当するものである。
　そうすると，引用発明の「ディスプレイとキーボードとを備えて，最上位モジュール仕様書と下位モジュール仕様書を含むモジュール仕様書の作成を支援するプログラム部品生成システム」は，本件補正発明の「入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置」に相当するといえる。
　
（４−２）引用発明の「下位モジュール」は「最上位モジュール」に呼び出される関係性を有し，「モジュール仕様書」は関数定義を含むプログラムの仕様書であると解されることから，引用発明の「最上位モジュール仕様書」，「下位モジュール仕様書」は，本件補正発明の「プログラムの関数の関数仕様」，「プログラムの関数の下位関数の関数仕様」に相当するといえる。　
　そうすると，引用発明の「最上位モジュール仕様書と，最上位モジュールに呼び出される下位モジュールの下位モジュール仕様書を作成するとともに，該最上位モジュール仕様書，該下位モジュール仕様書のそれぞれに記述され，該最上位モジュールが該下位モジュールを呼び出す時に受け渡される入出力データ名，型を修正するモジュール仕様書作成支援部」と，本件補正発明の「上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段」とは，後記する点で相違するものの，“プログラムの関数の関数仕様及びプログラムの関数の下位関数の関数仕様を入力によって編集する関数仕様編集手段”である点で共通しているといえる。
　
（４−３）上記（４−１）での検討により，引用発明の「モジュール仕様書」は，本件補正発明の「プログラムの関数の関数仕様」に相当するといえ，また，引用発明の「モジュール仕様書記憶部」は作成，あるいは修正された「モジュール仕様書」を格納するものであることが読みとれる。　
　そうすると，引用発明の「前記モジュール仕様書作成支援部によって作成，修正されたモジュール仕様書を格納するモジュール仕様書記憶部」は，本件補正発明の「この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部」に相当するといえる。　
　
（４−４）引用発明では，該最上位モジュールが該下位モジュールを呼び出す時に該最上位モジュール仕様書，該下位モジュール仕様書のそれぞれに記述された入出力データ名，型が受け渡されることから，引用発明の「入出力データ名，型」は本件補正発明の「入出力条件」に対応するといえる。
　また，引用発明では，編集された最上位モジュール仕様書の入出力データ名，型について検証を行うことに特定されていないものの，最上位モジュール仕様書と下位モジュール仕様書のそれぞれに記述された「入出力データ名，型」の整合性を検証し，チェック結果を「入出力データ名，型」の編集が可能な手段である「モジュール仕様書作成支援部」に送っているといえる。
　そうすると，本件補正発明の「この入出力条件編集手段によって編集された上記入出力条件」は，下位関数を呼び出す「関数の関数仕様に入力された入出力条件」であることは明らかであるから，引用発明の「前記最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証し，検証結果を前記モジュール仕様書作成支援部に送り，ディスプレイに表示する検証部」と，本件補正発明の「この入出力条件編集手段によって編集された上記入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を上記入出力条件編集手段に送る入出力条件検査手段」とは，後記する点で相違するものの，“関数の関数仕様に入力された入出力条件と，下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を入出力条件を編集する手段に送る検査手段”である点で共通しているといえる。
　
　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。 
　
（一致点） 
　
　「入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置であって，　
　上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段，　
　この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部，
　上記関数の関数仕様に入力された入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を入出力条件を編集する手段に送る検査手段
を備えたプログラム開発支援装置。」　
　
（相違点１）
　
　関数仕様の編集に関して，本件補正発明では，プログラムの関数の関数仕様及びプログラムの関数の下位関数の関数仕様を入出力装置の入力によって編集する関数仕様編集手段とは別に入出力条件編集手段を有し，プログラムの関数の関数仕様のうち下位関数を呼び出すときの入出力条件については，入出力装置の入力によって編集し，関数仕様編集手段に送るのに対して，引用発明では，モジュール仕様書作成支援部が，最上位モジュールが下位モジュールを呼び出す時に受け渡される入出力データ名，型の修正も含め，最上位モジュール仕様書と，最上位モジュールに呼び出される下位モジュールの下位モジュール仕様書を作成する点。
　
（相違点２）
　
　入出力条件の整合性のチェックに関して，本件補正発明では，プログラムの関数の関数仕様の編集された入出力条件と，下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックするのに対して，引用発明では，編集された最上位モジュール仕様書の入出力データ名，型に限定されることなく，最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証している点。
　
（相違点３）
　
　スタブ関数の生成に関して，本件補正発明では，「関数仕様編集手段により編集済みの上記プログラムの関数の関数仕様の上記入出力条件から直接上記下位関数のスタブ関数を生成するスタブ関数生成手段」，「このスタブ関数生成手段によって生成されたスタブ関数を格納するスタブ関数記憶部」を備えているのに対して，引用発明では，最上位モジュールが該下位モジュールを呼び出す時に受け渡される入出力データ名，型からスタブ関数を生成することについて特に記載されていない点。
　
　
（５）当審の判断
　
　上記相違点１乃至３について検討する。
　
（５−１）相違点１について
　
　引用文献１の上記Ｅの記載からすると，最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証し，一致していなければエラー表示を行って，モジュール仕様書作成支援部を起動してモジュール仕様書の修正を行うと解されることから，引用発明の「モジュール仕様書作成支援部」は，最上位モジュール仕様書と，最上位モジュールに呼び出される下位モジュールの下位モジュール仕様書を作成する場合のほか，最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型を一致させるための修正を行う目的で起動される場合があるといえる。
　そうすると，一般に，支援システムが通常と異なる契機で起動する場合に，特別な処理フローを介して通常処理フローを実行することは当該技術分野における常套手段であることから，引用発明において，最上位モジュールが下位モジュールを呼び出す時に受け渡される入出力データ名，型を修正する場合には，「モジュール仕様書作成支援部」とは異なる処理部を介して修正を行い，修正された入出力データ名，型を，「モジュール仕様書作成支援部」に送ること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点１は格別なものではない。
　
（５−２）相違点２について
　
　引用発明では，検証部が最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証しているが，その契機は特に明記されていない。
　しかしながら，引用発明では，最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型についてそれぞれ修正可能であることから，データ不整合の可能性の高まるいずれかの入出力データ名，型の修正後に上記の検証が必要であることは自明である。　
　してみると，引用発明において，整合性チェックを，適宜，最上位モジュール仕様書の入出力データ名，型が修正された時に，修正された最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証すること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たことである。　
　
　よって，相違点２は格別なものではない。
　
（５−３）相違点３について
　
　引用発明では，正確で迅速なプログラム部品の生成のために，最上位モジュール仕様書の入出力データ名，型と，下位モジュール仕様書の入出力データ名，型が一致しているかどうか検証することにより，上位モジュール仕様書と下位モジュール仕様書の入出力条件の整合性を保障しているといえる。
　ところで，プログラム開発における試験・検査に関して，下位関数である呼び出し関数に受け渡される入出力条件に基づいて，必要に応じて下位関数を疑似するスタブ関数を生成して利用する旨の技術は，例えば引用文献２（上記Ｆ，Ｇ，Ｈ参照），参考文献１（上記Ｋ参照）に記載されているように，本願出願日前には周知技術であった。また，スタブ関数を用いたプログラム試験において，下位関数のスタブ関数を生成する際に，検査対象プログラムと呼び出される下位関数との整合性がとれている必要があることは，参考文献１（上記Ｊ，Ｌ参照）に記載されているように，当業者にとって周知の事項であった。すなわち，プログラム開発において，上位の関数と呼び出し関数である下位関数との間に整合性がとれている場合に，呼び出し関数にスタブ関数を利用するか否かは必要に応じて選択し得た設計的事項であったといえる。
　そうすると，引用発明において，上記周知技術に基づき，適宜，整合性が保障された最上位モジュール仕様書の入出力データ名，型から直接下位モジュールを疑似するスタブ関数を生成し，所定の記憶手段に格納すること，すなわち，相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点３は格別なものではない。
　
（５−４）小括
　
　上記で検討したごとく，相違点１乃至３は格別のものではなく，そして，本件補正発明の奏する作用効果は，上記引用発明及び引用文献２，参考文献１に記載の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び引用文献２，参考文献１に記載の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
　
　
４．むすび 
　
　以上のように，本件補正は，上記「３．独立特許要件」で指摘したとおり，補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，特許法第１７条の２第６項の規定において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって，上記補正却下の決定の結論のとおり決定する。
　
　
第３　本件審判請求の成否について  
  
１．本願発明の認定 
  
　平成２５年１０月１７日付けの手続補正は上記のとおり却下されたので，本件補正後の請求項１に対応する本件補正前の請求項に係る発明（以下，「本願発明」という。）は，平成２５年７月８日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「入出力装置に表示された画面に入力することにより，プログラムの関数の関数仕様を作成するプログラム開発支援装置であって，
　上記プログラムの関数の関数仕様及び上記プログラムの関数の下位関数の関数仕様を上記入力によって編集する関数仕様編集手段，
　この関数仕様編集手段によって編集された上記関数仕様を格納する関数仕様記憶部，
　上記プログラムの関数の関数仕様は，上記下位関数を呼び出すときの入出力条件を含み，
　上記入出力条件を上記入力によって編集し，上記関数仕様編集手段に送る入出力条件編集手段，
　この入出力条件編集手段によって編集された上記入出力条件と，上記下位関数の関数仕様に入力された入出力条件とを照合して，整合性をチェックし，チェック結果を上記入出力条件編集手段に送る入出力条件検査手段，
　編集済みの上記プログラムの関数の関数仕様の上記入出力条件から上記下位関数のスタブ関数を生成するスタブ関数生成手段，
　このスタブ関数生成手段によって生成されたスタブ関数を格納するスタブ関数記憶部を備えたことを特徴とするプログラム開発支援装置。」　　
　
２．引用文献に記載されている技術的事項及び引用発明の認定 
　
　原査定の拒絶の理由に引用された，引用発明は，前記「第２　平成２５年１０月１７日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献」に記載したとおりである。
　
３．対比・判断  
　
　本願発明は，前記「第２　平成２５年１０月１７日付けの手続補正についての補正却下の決定」の「３．独立特許要件」で検討した本件補正発明の「
上記関数仕様編集手段により
直接
上記関数仕様編集手段により
直接
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２５年１０月１７日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献」乃至「（５）当審の判断」に記載したとおり，引用発明及び引用文献２，参考文献１に記載の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び引用文献２，参考文献１に記載の周知技術に基づいて，当業者が容易に発明をすることができたものである。 
　
４．むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。