【事件の表示】
　平成　８年特許願第　　９６１６号「モックアップ方法及びその制御装置」拒絶査定不服審判事件〔平成　９年　７月３１日出願公開、特開平　９−１９８２４０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成８年１月２３日の出願であって、平成１６年３月１１日付けで拒絶査定がなされ、これに対し、同年４月１５日に審判請求がなされ、その後、当審より平成１８年２月２日付けで拒絶理由が通知され、同年４月７日付けで手続補正がなされ、同年４月１７日付けで当審より最後の拒絶理由が通知され、同年６月１９日に手続補正がなされたものである。
　その請求項１に係る発明は、特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものと認める。（以下、「本願発明」という。）
　
「コンピュータが、プログラムの開発手順においてプログラムの擬似動作を可能とし、プログラム開発を支援するプログラム開発支援方法において、
　作成された画面レイアウトに含まれている項目ごとに、該項目への入力されたデータの形式、桁数および定義情報を、ユーザからの入力若しくは、項目に関する各種の定義情報を記憶しているテーブルの参照により対応付けて記憶し、
　前記画面レイアウトの項目への入力に対して、画面制御の処理を前記対応付けて記憶した内容に基づき擬似的に実行し、
　前記処理が適切でないために、ユーザが処理の変更内容を入力した場合に、ユーザから入力された処理の変更内容を作成された画面レイアウトに含まれている項目ごとに記憶し、
　前記処理が適切であるために、ユーザが処理の変更内容を入力しない場合に、前記記憶した内容をプログラム開発に用いる
ことを特徴とするプログラム開発支援方法。」
　
２．当審の拒絶理由
　当審より通知した平成１８年４月１７日付けの拒絶理由は、次のとおりである。
「１．本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項並びに第６項第１号及び第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
（１）…（中略）…
（５）請求項１の記載「前記処理が適切でない場合に、ユーザから入力された処理の変更内容を前記入出力定義ファイルに保存し」からすると、「画面制御の処理を前記入出力情報定義ファイルの内容に基づき擬似的に実行し」における「前記入出力情報定義ファイルの内容」とは、実質的には「項目への入力に対する処理内容」であると認められる。つまり、「擬似的に実行」するためには、「項目への入力に対する処理内容」は必須である。
　一方、「作成された項目ごとに、該項目への入力に対する処理内容、入力されたデータの形式、桁数および定義情報のうちいずれか１つ以上を対応付けて記憶する入出力情報定義ファイル」の記載からすると、「入出力情報定義ファイル」において、「項目への入力に対する処理内容」は必須ではない。
　よって、この点において、請求項１及び２に係る発明は不明確である。
（６）…（中略）…
　
２．本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
　
［引用文献］
１．ＳＥＷＢ３　概説　第４版、（株）日立製作所、１９９５年１２月３１日、第９３−９８頁
　
（１）請求項１及び２について
　引用文献１
　
…（以下略）」
　
　つまり、上記拒絶理由は、請求項１の記載には不備があるので、本願は、特許法第３６条第４項並びに第６項第１号及び第２号に規定する要件を満たしていない（以下「理由１」という。）というものと、請求項１及び２に係る発明は、引用文献１に記載された発明に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない（以下「理由２」という。）というものを含んでいる。
　以下、理由１及び理由２が解消したか否かについて検討する。
　
３．理由１について
　理由１の（５）の趣旨は、項目への入力に対する処理を「擬似的に実行」するためには、「項目への入力に対する処理内容」が定義されていることは必須であるが、請求項１には、該「項目への入力に対する処理内容」が定義されていない態様を含んでいるので不明確であり、かつ、発明の詳細な説明に記載したものではない、というものである。
　一方、請求項１の記載においては、「画面レイアウトに含まれている項目ごとに、該項目への入力されたデータの形式、桁数および定義情報を、…（中略）…対応付けて記憶し」及び「画面レイアウトの項目への入力に対して、画面制御の処理を前記対応付けて記憶した内容に基づき擬似的に実行し」からすると、「データの形式」、「桁数」及び「定義情報」に基づいて画面制御の処理を「模擬的に実行」することとなるが、前記の「項目への入力に対する処理内容」は「対応付けて記憶した内容」には含まれていないから、項目への入力に対して、どのような処理を行うべきかを、処理内容を含まない「データの形式」、「桁数」及び「定義情報」をどのように用いてどのように判断するのか不明である。
　また、請求項１に記載の「前記処理が適切でないために、ユーザが処理の変更内容を入力した場合に、ユーザから入力された処理の変更内容を作成された画面レイアウトに含まれている項目ごとに記憶し、」において、「前記処理」は、項目の入力に対する「画面制御の処理」を指し、「処理の変更内容」とは、この「画面制御の処理」の「変更内容」の意味と認められ、さらに、「変更」とは、既存のものが存在し、これに対して追加、削除、置換等を行うことを意味するから、項目の入力に対する画面制御の「処理」が、どこかに「項目ごと」に予め記憶されていることを示唆している。しかしながら、請求項１の記載において、該「処理」は、どこに記憶されているのか不明であり、また、このように記憶される態様は、発明の詳細な説明のどの部分に記載されているのか不明である。つまり、発明の詳細な説明には、例えば段落【００４４】において、モックアップ制御（擬似的実行）の際に行われる「処理」として、「属性チェック」、「桁数チェック」、「必須チェック」、「コード参照入力及びコードチェック名称表示」、「グループ遷移」、「メッセージボタン表示」が記載されているが、これらの「処理」及び当該「処理」の「変更内容」が、「項目」に対応付けて記憶されていること、及び、当該「処理」の「変更内容」（例えば、各「処理」を実現するルーチンの変更）をユーザが入力することは、発明の詳細な説明にどの箇所に記載されているのか不明である。
　以上のとおり、請求項１の記載は、項目への入力に対する処理を擬似的に実行するためにどこに記憶されたどのような情報に基づいて制御するのか依然として不明確であり、かつ、発明の詳細な説明との対応関係も不明確である。
　したがって、請求項１の記載は依然として不明確であり、かつ、発明の詳細な説明に記載したものではない。
　よって、本願は、特許請求の範囲の記載に不備があるので、特許法第３６条第６項第１号及び第２号に規定する要件を満たしておらず、特許を受けることができない。
　
４．理由２について
（１）引用発明
　当審より通知された上記拒絶理由に引用された、本願の出願日前である平成７年１２月３１日に頒布された刊行物である、ＳＥＷＢ３　概説　第４版、（株）日立製作所、第９３−９８頁（以下「引用文献」という。）には、次の事項が記載されている。
　
（ア）「（１）画面遷移図の設計
　オンライン業務の実行に必要な画面と、画面の遷移条件を決めるには、ＳＥＷＢ３オンラインプロトタイピング（ＳＥＷＢ３／ＯＮＰＲＯＴ）を使います。ＳＥＷＢ３オンラインプロトタイピングには、次の特長があります。
・シンボルを利用して画面遷移図を作成できる。
・個々の画面遷移の条件を、表形式で遷移条件表に定義できる。
・画面遷移図の作成中に、画面・帳票仕様書を参照できる。
・一つの業務の画面遷移を、複数の画面遷移図を使って定義できる。
　画面遷移図作成ウィンドウを、図６．２−１１に示します。」
（第９３頁第２−１０行）
　
（イ）「●画面遷移の条件
　画面遷移の条件を表形式で定義します。遷移元欄と遷移先欄には、画面遷移図に従って画面・帳票名が自動的に表示されます。遷移条件の欄に入力条件やキー名称を入力すれば遷移条件が定義できます。
・記述誤りの検査
　遷移条件文に文法誤りがないかどうかを調べ、誤りのあった場合はエラーメッセージを表示します。」
（第９３頁下から７行目〜最下行）
　
（ウ）「（２）画面・帳票の定義
　画面・帳票の設計には、ＳＥＷＢ３システム設計支援（ＳＥＷＢ３／ＳＹＳＴＥＭ）、又はＳＷＥＢ３画面・帳票定義（ＳＥＷＢ３／ＸＭＡＰＤＲＡＷ）を使います。
　…（中略）…
　ＳＥＷＢ３システム設計支援とＳＥＷＢ３画面・帳票定義には、次の特長があります。
・画面のレイアウトを、直接ワークステーションのウィンドウに描くことができます。
・ＧＵＩ（グラフィカルユーザインタフェース）機能付きの画面を定義できる。
・作成した画面を早期にワークステーション上で確認できる。
・類似画面を再利用しながら、画面・帳票を作成できる。
　また、画面・帳票は、レイアウトと、画面中の文字属性（タイプやＩＯ区分などの情報）の二つに分けて作成します。レイアウト定義ウィンドウを図６．２−１２に、フィールド属性定義ウィンドウを図６．２−１３に示します。）
（第９４頁第１３行〜最下行）
　
（エ）第９４頁の図６．２−１２の「レイアウト定義ウィンドウ」には、商品コード、商品名、売掛入金額といったフィールドが画面の位置に配置され、図６．２−１３の「フィールド属性定義ウィンドウ」には、前記「レイアウト定義ウィンドウ」に含まれたフィールドごとに、長さ、タイプ、ＩＯ区分、ＤＦＣ変更、レベル、色、印字といった属性が各フィールドに対応付けて定義されていることが読み取れる。
　
（オ）「●レイアウトの作成・編集
　画面のレイアウトを、直接画面に描きます。
●フィールド属性定義
　フィールド内の文字の属性（タイプやＩＯ区分など）を定義します。あらかじめ設定されている仮定値を利用して、属性を定義できます。
・入力チェック条件定義
　画面への入力データの以上を検出できるように、あらかじめ条件式などでデータの範囲を設定できます。これを入力チェック条件といいます。
●データ項目辞書の利用
　画面・帳票を定義するときに、リポジトリ内のデータ項目辞書からデータ項目名やタイプを転記して利用できます。
…（中略）…
●テスト表示
　サンプルデータを使用した実物に近い画面が表示できます。定数フィールド以外のフィールドに、サンプルデータの入力ができます。（ただし、ＧＵＩ機能付きの画面はテスト表示ができません）。
…（以下略）」
（第９５頁下から１１行目〜第９６頁第２６行）
　
（オ）「（３）画面遷移シミュレーションの実行
　設計した画面は、ＳＥＷＢ３オンラインプロトタイピング（ＳＥＲＢ３／ＯＮＰＲＯＴ）の画面遷移図を使ってシミュレーションします。
　画面遷移図で定義した順に、作成した画面の遷移を確認できます。
　一つの業務の画面遷移を複数の画面遷移図を使って定義している場合には、一度に複数の画面遷移をシミュレーションできます。」
（第９６頁下から１２行目〜下から７行目）
　
（カ）「（４）プログラム遷移図の編集
　画面遷移図を基に生成したプログラム遷移図に、ファイルの入出力やプログラムの処理を追加して、プログラム遷移図を完成します。
　…（中略）…
●プログラム遷移テーブルの生成
　作成したプログラム遷移図から、プログラムの遷移をソースプログラム（プログラム遷移テーブル）として生成できます。
●ＰＦキーテーブルの生成
　プログラム遷移図を編集しながら、プログラム遷移に使うＰＦキーを表形式で定義できます。また、定義したＰＦキーの内容を基に、ＰＦキーテーブルをソースプログラムとして生成できます。
●プログラム仕様書の生成
　作成したプログラム遷移図から、シンボルごとにプログラム仕様書を作成できます。
・プログラム仕様書の上書き生成
　プログラム仕様書を生成した後でプログラム遷移図に変更があった場合、プログラム仕様書中の遷移条件の部分だけを再生成できます。
（第９６頁下から６行目〜第９８頁第６行）
　
　上記（ア）、（ウ）及び（オ）及び引用文献のタイトルからして、引用文献１には、ＳＥＷＢ３というシステム設計支援ツールについて記載されており、当該ツールが、コンピュータ上で動作し、システム設計支援方法を提供することは自明である。
　上記（エ）の「テスト表示」及び（オ）の「シミュレーション」からして、引用文献１のシステム設計支援ツールは、画面表示を擬似的に実行する機能を有し、特に、上記（エ）の「定数フィールド以外のフィールドに、サンプルデータの入力ができます」及び上記（オ）の「入力チェック条件定義」に係る説明からして、前記擬似的実行の際には、前記「入力チェック条件定義」に基づいて、フィールドへの入力に対する入力チェックが行われることは自明である。また、前記「入力チェック条件定義」は、「データの範囲」が定義されるものであるが、フィールドに入力可能な値は、フィールド毎に異なると考えることが合理的であるから、前記「入力チェック条件定義」は、各フィールドに対応付けて記憶されていることは自明である。ただし、引用文献では、該「入力チェック条件定義」に係る説明は上記（オ）の「●フィールド属性定義」の項目の下に記載されているものの、図６．２−１３の「フィールド属性定義ウィンドウ」において、どの属性が入力チェック条件定義」に該当するのか不明であるが、引用文献に記載のシステム設計支援ツールがコンピュータ上で動作するものである以上、該「入力チェック条件定義」が、フィールドに対応付けてどこかに記憶されていることは必然的事項である。
　上記（オ）の「●データ項目辞書」に係る説明からして、「フィールド属性定義ウィンドウ」の各フィールドの属性は、ユーザからの入力のみならず、「データ項目辞書」を参照することにより設定できることがわかる。
　また、技術常識からして、前記模擬実行は、プログラム仕様書を生成する前に、プログラムの動作を検証すること目的としているから、当該模擬実行により所望の結果が得られない場合は、ユーザが各定義情報を変更して再設定することは自明であり、その変更の対象には、フィールドに対応付けてどこかに記憶された前記「入力チェック条件」も含まれ、その場合、ユーザが入力するのは、「入力チェック条件」の変更内容となることは自明である。
　
　よって、上記（ア）乃至（カ）からして、引用文献には次の発明（以下「引用発明」という。）が記載されている。
　
　コンピュータが、プログラム仕様書の作成過程においてプログラムの擬似動作を可能とし、プログラム仕様書の作成を支援するシステム設計支援方法において、
　作成された画面レイアウトに含まれているフィールドごとに、ＩＯ区分、長さ、および入力チェック条件を、ユーザからの入力若しくは、データ項目名やタイプを記憶したデータ項目辞書の参照により対応付けて記憶し、
　前記画面レイアウトのフィールドへの入力に対して、入力チェックを前記対応付けて記憶した内容に基づき擬似的に実行し、
　前記入力チェックが適切でないために、ユーザが入力チェック条件の変更内容を入力した場合に、ユーザから入力された入力チェック条件の変更内容を作成された画面レイアウトに含まれている項目ごとに記憶し、
　前記入力チェックが適切であるために、ユーザが入力チェック条件の変更内容を入力しない場合に、前記記憶した内容をプログラム仕様書の作成に用いる
ことを特徴とするシステム設計支援方法。
　
（２）対比
　ここで、引用発明と本願発明を対比すると、引用発明の「フィールド」、「ＩＯ区分」、「長さ」、「入力チェック条件」及び「入力チェック」はそれぞれ、本願発明の「項目」、「項目への入力されたデータの形式」、「桁数」、「定義情報」及び「画面制御の処理」に対応している。
　また、引用発明の「プログラム仕様書の作成」及び「システム設計」は、プログラムに関するものの開発である点で、本願発明の「プログラム開発」と一致する。
　よって、両者は、
　
「コンピュータが、プログラムに関するものの開発手順においてプログラムの擬似動作を可能とし、プログラムに関するものの開発を支援するプログラムに関するものの開発支援方法において、
　作成された画面レイアウトに含まれている項目ごとに、該項目への入力されたデータの形式、桁数および定義情報を、ユーザからの入力若しくは、項目に関する各種の定義情報を記憶しているテーブルの参照により対応付けて記憶し、
　前記画面レイアウトの項目への入力に対して、画面制御の処理を前記対応付けて記憶した内容に基づき擬似的に実行し、
　前記処理が適切でないために、ユーザが変更内容を入力した場合に、ユーザから入力された変更内容を作成された画面レイアウトに含まれている項目ごとに記憶し、
　前記処理が適切であるために、ユーザが変更内容を入力しない場合に、前記記憶した内容をプログラムに関するものの開発に用いる
ことを特徴とするプログラムに関するものの開発支援方法。」
　
　の点で一致し、以下の点で相違している。
　
［相違点１］
　本願発明は、「プログラム開発」を支援する方法であり、記憶した内容が、「プログラム開発」に用いられるのに対し、引用発明では、「プログラム仕様書」の作成を支援するシステム開発を支援する方法であり、記憶した内容が、「プログラム仕様書」の作成に用いられる点。
　
［相違点２］
　本願発明は、「処理」の変更内容が、ユーザから入力され、記憶されるのに対し、引用発明は、「処理」（入力チェック）自体の変更内容ではなく、「処理」（入力チェック）の「入力チェック条件」の変更内容がユーザから入力され、記憶される点。
　
（３）判断
　以下、上記各相違点について検討する。
　
［相違点１について］
　プログラム仕様書がプログラムの開発に用いられるのは技術常識であり、実際、引用文献を含む書籍（ＳＥＷＢ３　概説　第４版、（株）日立製作所、１９９５年１２月３１日）の第８０頁には、システム開発の流れ図が記載されており、「画面・帳票定義」が、プログラム合成等のプログラム開発に使用される様子が見て取れるから、引用発明において、作成した各種定義情報を、プログラム開発に用いるようにすることに格別な困難性はない。
　
［相違点２について］
　引用発明において、「入力チェック条件」を変更すれば、「入力チェック」の処理の内容（結果）が変更されることとなるから、該「入力チェック条件の変更内容」は、本願発明の「処理の変更内容」と実質的な差違がない。
　
　そして、本願発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲内のものである。
　
　したがって、本願発明は、引用発明及び周知技術に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　　
（４）むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。