【事件の表示】
　平成８年特許願第６１８３８号「緊急時ネットワーク運用方法」拒絶査定不服審判事件〔平成９年９月５日出願公開、特開平９−２３１２８２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・請求項１に係る発明
　
　本件出願は、平成８年２月２３日の出願であって、平成１４年８月１６日付で拒絶査定がなされ、これに対し、平成１４年１０月１０日に拒絶査定に対する審判請求がなされた。そして、当審において平成１６年１１月３０日付で拒絶理由通知がなされ、平成１７年２月２１日付で手続補正がなされたものである。
　
　そして、平成１７年２月２１日付け手続補正書により補正された特許請求の範囲の請求項１に係る発明（以下、「本願発明」という）は、次のとおりである。
「緊急時ネットワーク運用方法であって、
  緊急事態の現状分析を行う第１のステップと、
  予め設けられた事例データベースに蓄えられている事例を、第１のステップの結果を用いて検索する第２のステップと、
  第２のステップにおいて１の事例を決定する第３のステップと、
  第３のステップで決定した事例から、初期運用案を作成する第４のステップと、
  初期運用案に基づいて、シミュレーションを行い、仮想的に配分計画を実施する第５のステップと、
  第５のステップの実施計画に基づいて、第３のステップで決定した事例の一部を修正するための修正方法を選択する第６のステップと、
  第６のステップでオペレータ修正が選択された場合には、オペレータによる修正が行われ、第５のシミュレーションに戻る第７のステップと、
  第６のステップで配分計画修正が選択された場合には、第３のステップで決定した事例のコスト呼出しを行い、入力すべきデータを準備して、配分計画を実行し、第５のシミュレーションに戻る第８のステップと、
を有することを特徴とする緊急時ネットワーク運用方法。」
　
２．当審が通知した拒絶の理由
　
　当審が平成１６年１１月３０日付けで通知した拒絶の理由の概要は、以下のとおりである。
『＜理由Ａ＞ 
　本件出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
（１）略
（２）請求項１、５、６の「コンピュータは、入力された緊急時の現状データを分析することにより現状特徴量を求め」なる記載は、コンピュータがどのような情報処理を行うのかが不明（「緊急時の現状データ」がどのようなデータであり、「分析」としてどのような情報処理を行い、その結果としてどのようなデータを「現状特徴量」として得るのかが不明。）である。 
（３）請求項１、５、６の「（コンピュータは、）予め定められた緊急時における運用方法と事例インデックスを組とする事例を格納した事例データベースを前記現状特徴量により検索し」なる記載、及び、「（コンピュータは、）該現状特徴量に最も類似する事例インデックスに対応する事例を抽出し」なる記載は、それぞれコンピュータがどのような情報処理を行うのかが不明（略）である。 
（４）〜（８）略
（９）請求項６の「（コンピュータは、）該抽出した事例の運用方法と前記入力された緊急時の現状データを融合して初期運用案を作成し」なる記載、「（コンピュータは、）該作成した初期運用案をシミュレーションにより評価し」なる記載は、それぞれコンピュータがどのような具体的情報処理を行うのかが不明である。 
（１０）請求項６の「（コンピュータは、）評価の結果、満足できない場合は、入力された修正データにより前記作成した初期運用案を修正し、あるいは事例の運用方法にリンクするコストを格納したコストデータベースから前記抽出した事例の運用方法にリンクするコストを抽出し、該抽出したコストに基づき配分計画処理を実行して運用計画を立案し」なる記載は、コンピュータがいかなる具体的情報処理を行うことを意味するのかが不明（「あるいは」で択一的に記載された事項、すなわち、「入力された修正データにより前記作成した初期運用案を修正し」なる事項、「事例の運用方法にリンクするコストを格納したコストデータベースから前記抽出した事例の運用方法にリンクするコストを抽出し、該抽出したコストに基づき配分計画処理を実行して運用計画を立案し」なる事項のいずれも、コンピュータによるどのような具体的情報処理であるのかが不明。（以下略））である。 
（１１）請求項６の「（コンピュータは、）該修正した初期運用案あるいは該立案した運用計画を再度シミュレーションにより評価し」なる記載、及び、「（コンピュータは、）評価の結果、満足できる場合、該修正した初期運用案あるいは該立案した運用計画をネットワーク運用の運用計画とする」なる記載は、それぞれコンピュータがどのような具体的情報処理を行うのかが不明である。 
　よって、請求項１−６に係る発明は明確でないから、本件出願は、特許請求の範囲の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。 
　なお、出願当初の特許請求の範囲のごとく、「コンピュータ」との記載がなくても、どのような具体的処理手順からなる「緊急時ネットワーク運用方法」であるのかは明確でない。
　
 ＜理由Ｂ＞ 
　本件出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。 
　　　　　　　　　　　　　　　　　 記 
（１）略
（２）明細書及び図面の記載からは（「コンピュータ」の利用如何に関わらず）、本件出願の「緊急時ネットワーク運用方法」が、いかなる具体的手段を用いてどのような具体的手順を実行することで、その課題を解決するのかが明らかでない。以下、請求項毎に理由を記す。 
…（中略）…
　本件出願の請求項６に係る発明は、「知識ベースにない事項については推論不能となってしまい、現状ではオペレータの要望を満足させるほどには計画立案を支援できていない」ことを、その解決すべき課題とし、「該抽出した事例の運用方法（と前記入力された緊急時の）現状データを融合して初期運用案を作成し、該作成した初期運用案をシミュレーションにより評価し、評価の結果、満足できない場合は、（入力された修正データにより）前記作成した初期運用案を修正し、あるいは事例の運用方法にリンクするコストを格納したコストデータベースから前記抽出した事例の運用方法にリンクするコストを抽出し、該抽出したコストに基づき配分計画（処理）を実行して運用計画を立案し、該修正した初期運用案あるいは該立案した運用計画を再度シミュレーションにより評価し、評価の結果、満足できる場合、該修正した初期運用案あるいは該立案した運用計画をネットワーク運用の運用計画とする」としている。 
　しかしながら、この請求項に関する記載とみられる本件出願の明細書の段落【００２０】及び図１０には、「初期運用案の作成」は、単に「既に公知」であるとし、どのような「事例の運用方法」と、どのような「現状データ」から、どのような処理（融合なる表現自体もその処理内容が不明。）により「初期運用案」を作成するのか、また作成された「初期運用案」がどのようなものであるのかが記載されておらず、「初期運用案をシミュレーションにより評価し」なる事項についても、その「シミュレーション」をどのような具体的処理として構成し、その結果としてどのようなものが得られ、それに「満足できない場合」がどのような基準で判定されるのかが明らかでなく、また、オペレータにより行うとする「初期運用案の修正」も、オペレータが自らの知識に基づいて手作業により修正することが示唆されるに留まり、その修正作業に対する支援は具体的に記載されていないし、修正結果を用いて再度シミュレーションを行うことについても、先に述べたとおり、シミュレーション自体がどのような具体的処理で構成され、その評価をどのように行うのかが明らかでないから、オペレータに対する計画立案の支援を具体化したものは開示されていない。
　また、オペレータによる修正を行わない場合、「初期運用案の作成に用いた事例にリンクするコストを用いた配分計画を実行する」としているが、それにより得られた運用計画が、初期運用案を修正したものとして、どのような意味を有し、初期運用案とどのような関係を有するものとなるかも明らかでない（「事例にリンクするコスト」及びこれを用いた「配分計画」自体が不明であることは、先に請求項１−４について述べたとおりである。）から、やはり計画立案の支援を構成するものと解することができない。 
　してみれば、本件出願の明細書は、この請求項に係る発明が実現する「計画立案の支援」が具体的に何を意味し、「知識ベースにない事項については推論不能」なる課題をどのように解決し、どのようにして「オペレータの要望を満足させ」るものであるのかを具体的に開示していない。 
　以上のとおりであるから、本件出願の発明の詳細な説明の記載は、請求項１−６の「緊急時ネットワーク運用方法」を、いかなる具体的手段を用いてどのような具体的手順を実行するものとして具体化し、その課題を解決するのかを明らかにしておらず、当業者が請求項１−６に係る発明を実施することができる程度に明確かつ十分に記載されているものとは認められない。
　したがって、本件出願は、発明の詳細な説明の記載が、特許法第３６条第４項に規定する要件を満たしていない。 
　
＜理由Ｃ＞ 
　この出願の下記の請求項に記載されたものは、下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないから、特許を受けることができない。
 　　　　　　　　　　　　　　　　　 記
　本件出願の請求項１−６には、コンピュータのハードウエア資源がどのように（how to）用いられて処理されるかを直接的又は間接的に示す具体的な事項が記載されていないから、請求項に係る発明が解決しようとする課題に対する解決手段が、「ハードウエア資源を用いて処理すること」等の自然法則を利用した手段であるとはいえず、「コンピュータを用いて処理すること」のみであるから、自然法則を利用した技術的思想の創作であることを要件とする特許法上の「発明」に該当しない。 
　よって、本件出願の請求項１−６に記載されたものは、特許法第２９条第１項柱書に規定する要件を満たしていないから、特許を受けることができないものである。 
…（中略）…
　なお、出願当初の請求項１−６も、「方法」を特定する各処理手順について、その主体が特定されておらず、人が「データベース」を用いて行う業務手順を特定したものと解されるから、自然法則を利用した技術的思想の創作ではない。 
　 
＜理由Ｄ＞ 略
　
＜理由Ｅ＞ 略
 　 
＜理由Ｆ＞ 
　本件出願の請求項１−６に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　　　　　　　　　　　　　　　　　 記 
 　　　　　　　　　１．特開平５−３５７１４号公報 
 　　　　　　　　　２．特開平７−１１３２５３号公報 
備考：
（略）』
　
３．請求人の主張
　
　上記拒絶の理由に対し、請求人は、平成１７年２月２１日付けの意見書において、以下の主張をしている。
　『審判長殿は平成１６年１２月２１日発送の拒絶理由通知書により拒絶理由を提示されました。
  これに対して本意見書と同時に提出した手続補正書により、明細書の特許請求の範囲の欄を補正し、本願発明の構成を一層明確に致しました。
  すなわち、旧請求項１−６を削除し、新請求項１のみとし、本願方法発明の構成を明瞭なものと致しました。新請求項１に対応する明細書の記載は、出願当初の明細書の段落［００２０］の記載です。
  以上のとおりでありますから、本願を速やかに特許されるようお願い致します。』
　
４．当審の判断
　
４−１．理由Ａ（第３６条６項２号違反）について
　
　請求人は、当審が通知した拒絶の理由に対し、請求項１−６に係る発明を全て削除し、新たな請求項１に係る発明に補正したので、補正後の請求項１の記載が、特許法第３６条第６項第２号の規定を満たしているかどうかを以下に検討する。
　補正後の請求項１に記載した、それぞれのステップにて実行される処理について検討すると、以下に記すように、各ステップの処理は依然として明確でない。
（ア）「緊急事態の現状分析」なる記載では、「第１のステップ」が、どのような情報をどのように処理し、どのような結果を得る処理であるのかが明らかでない（上記理由Ａ（２））。
（イ）「予め設けられた事例データベースに蓄えられている事例」なる記載では、「事例」がどのような具体的情報であるのかが不明であり、また、「第１のステップの結果」なる記載では、それがどのような内容であるのかが明らかでないから、「第２のステップ」が、どのような構成のデータベースをどのような情報により検索し、どのような情報を得る処理を意味するのかが不明である（上記理由Ａ（３））。
（ウ）「第２のステップにおいて１の事例を決定する」なる記載では、「第３のステップ」が「第２のステップ」とどのような関係を有するのかが明らかでなく、「１の事例を決定する」なる記載も、いかなる情報に基づいてどのように決定するのかを特定していないから、「第３のステップ」が、どのような具体的処理を意味するのかが不明である（上記理由Ａ（３））。
（エ）「第３のステップで決定した事例から、初期運用案を作成する」なる記載では、「第４のステップ」が、「事例」に対していかなる具体的処理を施すことにより「初期運用案」を得る処理を意味するのか、また、作成される「初期運用案」がどのような情報であるのかが不明である（上記理由Ａ（９））。
（オ）「初期運用案に基づいて、シミュレーションを行い、仮想的に配分計画を実施する」なる記載では、「第５のステップ」が、いかなる具体的処理であるのか、また、その処理結果としていかなるものが得られるのかが不明である（上記理由Ａ（９））。
（カ）「第５のステップの実施計画」自体がいかなるものかが不明であるとともに、「第５のステップの実施計画に基づいて、第３のステップで決定した事例の一部を修正するための修正方法を選択する」なる記載では、「第５のステップの実施計画」に基づいて行われることが、「（第３のステップで決定した事例の一部を）修正する」のか、「（修正方法を）選択する」のかも明らかでないから、「第６のステップ」が、いかなる具体的処理であるのかが不明である。また、修正の対象となる「第３のステップで決定した事例の一部」がいかなるものかも不明である（上記理由Ａ（１０））。
（キ）「オペレータによる修正」なる記載では、何に対してどのような修正を行うものかが不明であり、このステップを経た後に、「第５のシミュレーションに戻る」ことにより、第５のステップでどのような処理が行われることになるのかも不明であるから、「第７のステップ」が、いかなる具体的処理であるのかが不明である（上記理由Ａ（１０）（１１））。
（ク）「第３のステップで決定した事例のコスト呼出しを行い、入力すべきデータを準備して、配分計画を実行」なる記載では、「事例のコスト呼出し」、「入力すべきデータを準備」、「配分計画を実行」のそれぞれが、いかなる具体的処理であるのかが不明であり、このステップを経た後に、「第５のシミュレーションに戻る」ことにより、第５のステップでどのような処理が行われることになるのかも不明であるから、「第８のステップ」が、いかなる具体的処理であるのかが不明である（上記理由Ａ（１０）（１１））。
　また、上記した各ステップのいずれについても、そのステップを実行する主体が明らかでなく、それぞれのステップが、人による業務として行われるものとも、何らかの装置による処理として実行されるものとも解釈し得るものであり、この請求項に記載した「緊急時ネットワーク運用方法」が、いかなる具体的手段によるどのような処理から構成されたものかが明確でない。
　よって、補正後の請求項１の記載は、特許を受けようとする発明が明確でないから、本件出願の特許請求の範囲の記載は、依然として、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
４−２．理由Ｂ（第３６条４項違反）について
　
　補正後の請求項１に係る発明について、発明の詳細な説明の記載が、これを当業者が実施することができる程度に明確かつ十分に記載されているか検討する。
　補正後の請求項１に記載した、「初期運用案を作成」、「シミュレーションを行い」、「仮想的な配分計画の実施」及び「配分計画の実行」等について、この出願の発明の詳細な説明及び図面の記載が、これらをどのように具体化するのかを明らかにしていないことは、上記した拒絶の理由Ｂ（２）において述べたとおりである。
　よって、本件出願の発明の詳細な説明は、補正後の請求項１に係る発明を当業者が実施することができる程度に明確かつ十分に記載したものではないから、本件出願は、依然として発明の詳細な説明の記載が、特許法第３６条第４項に規定する要件を満たしていない。
　
４−３．理由Ｃ（第２９条第１項柱書き違反）について
　
　上記した理由Ｃは、補正前の各請求項に係る「緊急時ネットワーク運用方法」が、「コンピュータ」が各処理ステップを実行するものとして特定されていたので、各請求項に係る発明をコンピュータ・ソフトウエア関連発明とみて、「自然法則を利用した技術的思想の創作」に該当するか否かを検討した結果を記載した上で、「コンピュータ」との明記がない場合についても検討を加え、「なお、出願当初の請求項１−６も、「方法」を特定する各処理手順について、その主体が特定されておらず、人が「データベース」を用いて行う業務手順を特定したものと解されるから、自然法則を利用した技術的思想の創作ではない。」と説示し、請求人に意見を述べる機会を与えたものである。
　補正後の請求項１に係る発明は、「コンピュータは」との記載が削除され、それぞれの処理ステップを実行する主体を特定していないことは、既に４−１．において検討したとおりであり、この請求項の記載により特定される「緊急時ネットワーク運用方法」は、出願当初明細書における各請求項と同様に、人がデータベースを用いて行う業務の手順を特定したものを含むと解される。
　そして、この請求項に記載された業務の手順を、人が行う手順を特定したものと解した場合、その手順は人為的に取り決められたものであって、自然法則を利用した技術的思想の創作であるとみることはできない。
　なお、当業者の技術常識からみれば、「シミュレーション」や「配分計画」等、請求項１に記載した各ステップのうち一部の手順において、コンピュータにより実行される処理が含まれることも想定されるから、これを前提として検討してみるに、たとえ、このような「一部の処理がコンピュータにより実行されること」を、「自然法則を利用している部分」としてみたとしても、全体として自然法則を利用していないと判断されるから、請求項１に記載の「緊急時ネットワーク運用方法」は、自然法則を利用したものとはいえない。
　また、請求項１に記載の「緊急時ネットワーク運用方法」を特定する各ステップのすべてがコンピュータにより実行されるものと解した場合でも、請求項１に記載の方法の中で、自然法則を利用した部分が「コンピュータを用いて処理すること」のみに留まるから、やはり自然法則を利用した技術的思想の創作であるとは認められないことは、上記拒絶の理由Ｃにて述べたとおりである。
　よって、補正後の請求項１に記載した「緊急時ネットワーク運用方法」は、自然法則を利用した技術的思想の創作であることを要件とする特許法第２条に規定する「発明」に該当しないから、特許法第２９条第１項柱書に規定する要件を満たしていない。
　
４−４．理由Ｆ（第２９条第２項違反）について
　
（１）本願発明
　本願発明は、上記１．にて記載した通りのものである。
　
（２）引用例
　本件出願前に頒布された刊行物であって、上記拒絶理由にて引用された特開平７−１１３２５３号公報（以下、「引用例」という。には、「水運用立案支援システム」に関して、次の事項が図面とともに記載されている。
（ａ）「【請求項１】水システムの水運用を算出する水運用立案支援システムにおいて、運用事例を格納する事例ＤＢと、水システムの監視制御に関するデータを格納する監視制御システムＤＢと、事例検索部と、運用案生成部とから成り、前記事例検索部は、入力された運用立案条件に基づき、前記監視制御システムＤＢ内データを参照して関連する運用事例を前記事例ＤＢから検索し、前記運用案生成部は、前記検索された運用事例をもとにして、前記運用立案条件と前記監視制御システムＤＢ内データとを参照して運用案を生成することを特徴とする水運用立案支援システム。
【請求項２】請求項１記載のシステムにおいて、前記事例検索部がインデクスベース検索部とモデルベース検索部とから成り、前記インデクスベース検索部は、運用立案条件と運用事例データとの間での類似検索を行うことで、運用立案条件に適した運用事例を検索し、前記モデルベース検索部は、運用事例データと監視制御データとを用いてモデル実行を行い、その実行結果と運用立案条件との間で関連度判定を行うことで、運用立案条件に適した運用事例を検索することを特徴とする水運用立案支援システム。
…（中略）…
【請求項６】請求項１或いは請求項４に記載のシステムにおいて、前記運用生成部が運用原案生成部と運用改良部とから成り、前記運用原案生成部は運用事例データと監視制御システムＤＢ内データとから運用案初期値を生成し、前記運用改良部は、運用立案条件と監視制御システムＤＢ内データとに基づいて、運用立案条件に適した運用案を生成することを特徴とする水運用立案支援システム。
【請求項７】請求項６に記載のシステムにおいて、前記運用改良部は、運用案データと監視制御データとを用いてモデル実行を行い、その実行結果と運用立案条件との間で関連度判定を行うことで、運用立案条件に適した運用案を生成することを特徴とする水運用立案支援システム。
【請求項８】請求項１或いは請求項４に記載のシステムにおいて、請求項２或いは請求項３或いは請求項５に記載の特徴と、請求項６或いは請求項７に記載の特徴と、を合わせ持つことを特徴とする水運用立案支援システム。」（公報【特許請求の範囲】）
（ｂ）「【産業上の利用分野】本発明は水運用を立案するための計算機支援システムに係わる。特に、運用実績や運用方法机上検討の結果を運用事例としてＤＢ蓄積し、その運用事例を活用するというやり方で水運用を立案する場面に有効である。
…（中略）…
　水運用の難しさは、上記の通り、広域水システムが多変数・多制約である点にある。つまり、設備面では、多数設備のネットワークであり、しかも設備能力や貯水容量が設備毎にアンバランスである。また、環境面では、需要量の地域差や、需要量の日変動（季節性、曜日性、天気依存）等が見られる。特に、緊急時水運用としては、次ぎのような難しさがある。つまり、多変数・多制約・多目的(運用戦略、評価メジャー)であり、かつ、その時の状況や環境に依存するということである。さらに、管路系統の変更（平素は使用していない輸送経路の採用）が必要なこともありうる。
…（中略）…
　つまり、平常時や緊急時ともに、運用事例が存在し、それを活用している、ということである。これにより、緊急時用の特別な計画アルゴリズムの開発や、平常時用計画アルゴリズムの緊急時向けチューニングなどが、不要となる。更に、関与者に対して、安心感・速応性・納得性といった、心理的な面での効果を与える。」（公報段落番号【０００１】〜【０００６】）
（ｃ）「本水運用立案支援システムを用いた場合の水運用立案の手順を図７に示す。図中、楕円で囲んであるデータ項目（運用立案条件、事例指定、運用改良値）は利用者が入力するものである。大きな流れは次ぎの通りである。先ず事例検索を行い、次ぎに運用案生成を行う。最後に、必要があれば、その運用案を事例ＤＢに登録する。
　事例検索段階は、運用立案条件に適合する事例を事例ＤＢから検索する段階である。
…（中略）…
　運用案生成段階は、事例検索段階の出力結果の事例をもとにして、状況に適した運用案を生成する段階である。内部は、対象事例選定段階、運用原案生成段階、運用改良段階から成る。対象事例選定段階は、第２次検索結果の事例の中から、運用案の元とする事例を指定する。運用原案生成段階は、その事例をもとにし、水システムの状況を加味して（つまり、監視制御システムＤＢを参照して）、運用案の初期データを生成する。運用改良段階は、運用案の内容を状況に適するように改良する。その結果、運用案の最終値が決定される。尚、運用改良段階では、運用案がどの程度運用立案条件に適合しているかの適合度の判定のために、モデルを起動しその計算結果を利用することがある。モデルは、必要に応じて監視制御システムＤＢを参照する。
　本実施例の動作の概略を、上記の手順に従って説明する。利用者は、表示入力装置１０３から運用立案条件を入力する。事例検索部１１１は、事例ＤＢ１２１、検索知識ＤＢ１２２、監視制御システムＤＢ１２３を参照して、運用立案条件を満足する事例群１１７を検索結果として出力する。この事例群１１７は内部ファイルとして記憶される。事例検索部１１１の処理フローは後述する。
　さらに利用者は、表示入力装置１０３から選択事例と運用改良値を入力する。選択事例の入力方法は事例番号や事例名称を指定することで行う。運用改良値の入力は運用内容の変更修正の指定値を入力することで行う。運用案生成部１１２は、検索事例群１１７の中の選択事例に対し、運用改良値を適用したり、監視制御システムＤＢ１２３を参照してモデル実行を行ったりして、運用案１１８を出力する。この運用案１１８が本水運用立案支援システムの出力となり、表示入力装置１０３から利用者に提示される運用案生成部１１２の処理フローは後述する。
…（中略）…
　事例検索部１１１内でモデルベース検索を行う時や運用案生成部１１２内で運用改良を行う時は、検索事例や運用案がどの程度運用立案条件に適合しているかの適合度の判定のために、モデルを起動しその計算結果を利用することがある。そのために、モデル実行部１１４や特徴量抽出部１１５の中の各種プログラムを起動する。モデル実行部１１４には、シミュレータや数量変換プログラム（例えば、日間値から時間値への展開ルーチン）等が含まれている。それらのプログラムは、それぞれの特徴に応じて、運用立案条件や事例ＤＢ１２１、検索知識ＤＢ１２２、監視制御システムＤＢ１２３を参照して計算処理を行う。その結果は内部テーブル１１９に出力される。各モデルは一般に複数のデータ項目についての計算を行う。従って、それらの中から評価や判定に必要な項目値を取り出すことが必要である。そのために、特徴量抽出部１１５には、適合度の判定に必要なデータ項目ごとにその値を算出するプログラムが含まれている。それらのプログラムは、それぞれの特徴に応じて、運用立案条件や事例ＤＢ１２１、監視制御システムＤＢ１２３、内部テーブル１１９を参照して計算処理を行う。」（公報段落番号【００２９】〜【００３５】）
　したがって、引用例には、
「緊急時の水運用立案方法であって、
予め設けられた事例ＤＢに蓄えられている運用事例を、運用立案条件に基づき検索する事例検索段階と、
事例検索段階で得られた事例から、運用案の元とする事例を選定する対象事例選定段階と、
対象事例選定段階で選定した事例から、運用案の初期データを生成する運用原案生成段階と、
運用案の初期データに基づいて、モデル実行を行う段階と、
モデル実行の結果に基づいて、オペレータにより運用案の修正を行い、再度モデル実行を行う運用改良段階と
を有することを特徴とする緊急時の水運用立案方法。」
との発明（以下、「引用例発明」という。）が開示されていると認められる。
　
（３）対比
　本願発明（以下、「前者」という。）と引用例発明（以下、「後者」という。）とを対比すると、後者の「緊急時の水運用立案方法」は、ネットワークとして把握される水システムの運用方法の一部をなすものであることは明らかであるから、前者の「緊急時ネットワーク運用方法」に相当し、後者の「運用事例」は、前者の「事例」に、後者の「事例ＤＢ」は、前者の「事例データベース」に、後者の「運用案の元とする事例を選定する」ことは、前者の「１の事例を決定する」ことに、それぞれ相当する。
　また、後者の「運用案の初期データ」は、前者の「初期運用案」に、後者の「モデル実行を行う」ことは、前者の「シミュレーションを行い、仮想的に配分計画を実施する」ことに、後者の「モデル実行の結果」は、前者の「実施計画」に、それぞれ相当する。
　そして、後者の「事例検索段階」、「対象事例選定段階」、「運用原案生成段階」、「（モデル実行を行う）段階」、「運用改良段階」は、それぞれ、前者の「第２のステップ」、「第３のステップ」、「第４のステップ」、「第５のステップ」、「第７のステップ」に対応し、後者の運用改良段階における「再度モデル実行を行う」ことは、前者の「第５のシミュレーションに戻る」ことに相当するから、両者は、
「緊急時ネットワーク運用方法であって、
予め設けられた事例データベースに蓄えられている事例を検索する第２のステップと、
第２のステップにおいて１の事例を決定する第３のステップと、
第３のステップで決定した事例から、初期運用案を作成する第４のステップと、
初期運用案に基づいて、シミュレーションを行い、仮想的に配分計画を実施する第５のステップと、
第５のステップの実施計画に基づいて、オペレータによる修正が行われ、第５のシミュレーションに戻る第７のステップと、
を有することを特徴とする緊急時ネットワーク運用方法。」
である点で一致し、以下の点で相違する。
［相違点１］前者は、事例データベースの検索に先立って、現状分析（第１のステップ）を行い、その結果に基づいて検索するのに対し、後者は運用立案条件に基づいて検索するとされ、当該運用立案条件が、現状分析の結果であるか否か明らかでない点。
［相違点２］前者は、シミュレーションの結果に基づいて行う修正処理の対象が、初期運用案の作成に用いられる事例であるのに対し、後者は運用案そのものである点。
［相違点３］前者は、修正方法として、「オペレータ修正」と選択的に利用可能な「第３のステップで決定した事例のコスト呼出しを行い、入力すべきデータを準備して、配分計画を実行」する「配分計画修正」（第８のステップ）を備えるとともに、修正の実行に先立ちいずれかを選択させるステップ（第６のステップ）を備えるのに対し、後者はそうでない点。
　
（４）判断
［相違点１］について
　運用案を作成するに際して、現状を分析し、その結果を考慮することは、一般的に行われていることであるので、引用例発明において、事例ＤＢの検索に用いる運用立案条件の設定を、現状分析を行った後、その結果に基づいて行う手順とすることは、当業者が容易に想到し得ることである。
［相違点２］について
　シミュレーションの再実行に用いる運用案を変更するに際し、運用案を直接変更するか、運用案を生成するための事例を変更するかは、当業者が適宜に定める事項である。
［相違点３］について
　本件出願前に頒布された刊行物であって、上記拒絶理由にて引用された特開平５−３５７１４号公報には、コストを用いた配分計画により運用計画を立案することが記載されており、引用例発明におけるオペレータ修正に加えて、このような配分計画を実行する仕組みを採用し、選択的に利用する手順とすることは、当業者が容易に想到し得ることである。
　そして、本願発明の作用効果も、上記した引用例の記載及び周知技術から当業者が予測できる範囲のものである。
　
（５）むすび
　したがって、本件出願の請求項１に係る発明は、引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　
５．まとめ
　
　上記したとおり、本件出願の明細書の記載は、特許法第３６条第６項第２号及び同条第４項の規定を満たしていない。
　また、請求項１の記載は明確でないものの、請求項１の記載から把握されるものは、特許法第２条第１項にいう「自然法則を利用した技術的思想の創作」に該当しないから、特許法第２９条第１項柱書の規定により特許を受けることができない。
　さらに、仮に請求項１に記載されたものを、特許法第２９条第１項柱書にいう「発明」として認めたとしても、その出願前に頒布された刊行物に記載された発明に基いて、その出願前に当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論の通り審決する。