【事件の表示】
　特願２００１−１３２１７７「セキュリティポリシー構築方法及び装置並びにセキュリティポリシー構築を支援する方法及び装置」拒絶査定不服審判事件〔平成１４年　２月２０日出願公開，特開２００２−　５６１７６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯・本願発明
　本願は，平成１３年４月２７日（優先権主張　平成１２年６月１日）の出願であって，その請求項１〜６７に係る発明は，平成１４年１０月２８日付け手続補正書により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１〜６７に記載された事項により，それぞれ特定されるものであるところ，請求項１，１６，４７及び５８の記載は，次のとおりである。
　
「【請求項１】所定の団体のセキュリティポリシーを構築する方法において，
　セキュリティポリシーのドラフトを構築するドラフト構築ステップと，
　前記セキュリティポリシーのドラフトと，団体の実態との差異を調査する分析ステップと，
　前記差異に基づき前記セキュリティポリシーのドラフトの調整，又は，前記差異に基づき前記団体の実際の情報システムの運用ルールの調整，を行う調整ステップと，
　を含み，
　前記ドラフト構築ステップは，
　団体に属するメンバーにするべき質問を，質問生成手段に生成させる生成ステップと，
　生成した前記質問に対する前記メンバーの回答を取得する回答取得ステップと，
　前記取得した回答に基づき，構築手段に，セキュリティポリシーのドラフトを構築させる構築ステップと，
　を含み，
　前記回答取得ステップは，
　回答保管手段に，前記取得した回答群中で，被質問者が同一である回答を統合させ，単一の被質問者の回答として記憶手段中に保管させるステップと，
　前記取得した回答群中に矛盾する回答が含まれている場合には，前記質問に対する前記メンバーの再回答に基づき，前記回答保管手段に，矛盾点を解決させ，前記記憶手段中に前記回答群を格納させるステップと，
　前記取得した回答群中に矛盾する回答が含まれている場合には，前記回答保管手段に，前記回答に被質問者の職務内容に基づく重み付けをさせることによって，回答を推定させ，推定した回答を示させるステップと，
　の少なくとも１のステップを含むことを特徴とするセキュリティポリシー構築方法。
　【請求項１６】セキュリティポリシーを構築するセキュリティポリシー構築装置において，
　団体に属するメンバーにするべき質問を生成する質問生成手段と，
　前記生成した質問に対する回答を保管する記憶手段と，
　前記生成した質問に対する回答を取得し，前記記憶手段に保管する回答保管手段と，
　前記記憶手段に保管される前記回答に基づき，セキュリティポリシーを構築する構築手段と，
　を含むセキュリティポリシー構築装置であって，
　前記質問生成手段は，被質問者の職務内容に基づき，前記被質問者にするべき質問を生成することを特徴とするセキュリティポリシー構築装置。
　【請求項４７】所定の団体のセキュリティポリシーを構築するのに必要な事項に関する質問であって，前記団体に属するメンバーにするべき質問を生成する質問生成手順と，
　前記生成した質問に対する回答を入力し，記憶手段に格納する回答保管手順と，
　前記記憶手段に保管される前記回答に基づき，セキュリティポリシーを構築する構築手順と，
　をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体において，
　前記質問生成手順は，被質問者の職務内容に基づき，前記被質問者にするべき質問を生成することを特徴とするコンピュータ読み取り可能な記録媒体。
　【請求項５８】所定の団体のセキュリティポリシーを構築するのに必要な事項に関する質問であって，前記団体に属するメンバーにするべき質問を生成する質問生成手順と，
　前記生成した質問に対する回答を入力し，記憶手段に保管する回答保管手順と，
　前記記憶手段に保管される前記回答に基づき，セキュリティポリシーを構築する構築手順と，
　をコンピュータに実行させるためのプログラムにおいて，
　前記質問生成手順は，被質問者の職務内容に基づき，前記被質問者にするべき質問を生成することを特徴とするプログラム。」
（以下，請求項１，１６，４７及び５８に係る発明を，それぞれ，「本願発明１」，「本願発明１６」，「本願発明４７」及び「本願発明５８」という。）
　
第２　原査定の理由
　原査定の拒絶の理由は，概略，次のとおりである。
　
〔理由Ａ〕略
〔理由Ｂ〕請求項１〜１５，２６，２７，２９，３０，３２〜３５，３８〜４１において，各ステップの動作主体が不明確であるから，特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。
　例えば，請求項１において，「セキュリティポリシーのドラフトを構築するドラフト構築ステップ」及び「前記ドラフト構築ステップは，団体に属するメンバーにするべき質問を，質問生成手段に生成させる生成ステップと...前記取得した回答に基づき，構築手段に，セキュリティポリシーのドラフトを構築させるステップ」との記載があるが，各ステップの動作主体が「人間」であるのか，計算機により自動的に行われるものであるのか，記載上明らかでない。
〔理由Ｃ〕請求項１６〜２２，２８，３１，３６，３７，４５，４６，４７〜５４，５８〜６４に係る発明は，本願出願前日本国内又は外国において頒布された刊行物である「杉本隆洋，ポリシーの作成から運用まで セキュリティ・システム導入の手引，SunWorld，1999年8月1日，第9巻第8号，pp.64-75」に記載された発明に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
第３　当審の判断
１　理由Ｂ（特許法第３６条第６項第２号）について
(1)　本願発明１の「セキュリティポリシーを構築する方法」を組成する各ステップについて検討するに，「ドラフト構築ステップ」，「分析ステップ」，「調整ステップ」，「生成ステップ」，「回答取得ステップ」，「構築ステップ」，「保管させるステップ」，「格納させるステップ」及び「回答を示させるステップ」のいずれのステップにおいても，各ステップの動作主体が特定されていないことは，請求項１の記載に照らし，明らかである。
　したがって，本願発明１の各ステップの動作主体が明確でないから，全体として技術的に不明確である。
　請求人は，審判請求理由において，「質問の生成は質問生成手段が行う」，「セキュリティポリシーのドラフトは構築手段が実行する」ことは，請求項でも明らかであると主張する。
　しかし，請求項１において，「生成ステップ」は，「質問生成手段が質問を生成するステップ」とは特定されておらず，「団体に属するメンバーにするべき質問を，質問生成手段に生成させる生成ステップ」と特定されているのであるから，請求項１の「生成ステップ」は，質問を「質問生成手段に生成させる」ステップであり，「質問生成手段に生成させる」動作主体は，「質問生成手段」以外のものと解すべきである。
　同様に，請求項１において，「構築ステップ」は，「構築手段がセキュリティポリシーのドラフトを構築するステップ」とは特定されておらず，「前記取得した回答に基づき，構築手段に，セキュリティポリシーのドラフトを構築させる構築ステップ」と特定されているのであるから，請求項１の「構築ステップ」は，「構築手段に，セキュリティポリシーのドラフトを構築させる」ステップであり，「構築手段に，セキュリティポリシーのドラフトを構築させる」動作主体は，「構築手段」以外のものと解すべきである。
　そして，「ドラフト構築ステップ」，「分析ステップ」，「調整ステップ」及び「回答取得ステップ」については，各ステップの動作主体が何も記載されていない。
　請求人の主張は，請求項１の記載に基づかないものである。
(2)　進んで検討するに，請求項１の記載は，上記第１のとおりであるところ，そこには，「コンピュータ」との用語そのものは記載されていないが，「質問生成手段」，「構築手段」及び「回答保管手段」との記載があり，発明の詳細な説明を参酌すれば，これら「質問生成手段」，「構築手段」及び「回答保管手段」は，ソフトウエアがコンピュータに読み込まれることにより構成される機能実現手段を意味するものと解することができる。
　そうだとすると，本願発明１は，コンピュータを用いて，「セキュリティポリシーを構築する方法」の発明であり，コンピュータ・ソフトウエア関連発明，すなわち，その発明の実施にソフトウエアを必要とする発明ということができる。
(3)　コンピュータ・ソフトウエア関連発明については，出願の審査において特有の判断，取り扱いがなされることが「特許・実用新案審査基準」の「第VII部　特定技術分野の審査基準，第１章　コンピュータ・ソフトウェア関連発明」において公示されているところであり，上記基準には，「1.1.3　発明が明確でない例」として，「(1)　請求項の記載自体が不明確である結果，発明が不明確となる場合」の「例１」に，
「（請求項に係る発明）
　コンピュータを用いて，顧客からの商品の注文を受け付けるステップと，注文された商品の在庫を調べるステップと，該商品の在庫がある場合には該商品が発送可能であることを前記顧客に返答し，該商品の在庫がない場合には該商品が発送不能であることを前記顧客に返答するステップを実行する受注方法。
　（説明）
　「コンピュータを用いて，…ステップ」という表現では，各ステップにおける動作の主体が特定されたことにならないために，「コンピュータを（計算道具として）用いて，（人間がコンピュータを操作して）顧客からの商品の注文を受け付けるステップと，（人間がコンピュータを操作して）注文された商品の在庫を調べるステップと，該商品の在庫がある場合には該商品が発送可能であることを（人間がコンピュータを操作して）前記顧客に返答し，該商品の在庫がない場合には該商品が発送不能であることを（人間がコンピュータを操作して）前記顧客に返答するステップを実行する受注方法」という「コンピュータという計算道具を操作する方法」とも，「コンピュータを用いて（構築された受注システムにおいて），（コンピュータが備える手段Ａが）顧客からの商品の注文を受け付けるステップと，（コンピュータが備える手段Ｂが）注文された商品の在庫を調べるステップと，該商品の在庫がある場合には該商品が発送可能であることを（コンピュータが備える手段Ｃが）前記顧客に返答し，該商品の在庫がない場合には該商品が発送不能であることを（コンピュータが備える手段Ｃが）前記顧客に返答するステップを実行する受注方法」という「コンピュータ・ソフトウエアによる情報処理方法」とも解釈できる
　したがって，本来別々の請求項に記載すべき「コンピュータという計算道具を操作する方法」及び「コンピュータ・ソフトウエアによる情報処理方法」という異なる概念を一の請求項に含んでいるために，請求項に係る発明を明確に把握することができない。」
と記載されている。
(4)　これを本願発明１についてみるに，本願発明１は，各ステップにおける動作の主体が特定されていないから，「コンピュータを計算道具として用いて，人間がコンピュータを操作して，ドラフト構築ステップ，分析ステップ，調整ステップ等の各ステップを実行するセキュリティポリシー構築方法」という「コンピュータという計算道具を操作する方法」とも，「コンピュータを用いて構築されたセキュリティポリシー構築装置において，コンピュータが備える各手段がドラフト構築ステップ，分析ステップ，調整ステップ等の各ステップを実行するセキュリティポリシー構築方法」という「コンピュータ・ソフトウェアによる情報処理方法」とも解釈できる。
　したがって，請求項１の記載は，本来別々の請求項に記載すべき「コンピュータという計算道具を操作する方法」及び「コンピュータ・ソフトウエアによる情報処理方法」という異なる概念を一の請求項に含んでいるために，本願発明１を明確に把握することができない。
(5)　特許法第３６条第６項第２号は，「特許を受けようとする発明が明確であること」を規定しており，その趣旨に照らせば，一の請求項から一の発明が明確に把握できることが必要である。
　してみると，「コンピュータという計算道具を操作する方法」及び「コンピュータ・ソフトウエアによる情報処理方法」という異なる概念を一の請求項に含んでいる請求項１の記載は，特許法第３６条第６項第２号の規定に違反するものである。
　
２　理由Ｃ（特許法第２９条第２項）について
２−１　引用例
　原査定の拒絶の理由に引用された「杉本隆洋，ポリシーの作成から運用まで セキュリティ・システム導入の手引，SunWorld，1999年8月1日，第9巻第8号，pp.64-75」（以下「引用例１」という。）には，図面とともに次の事項が記載されている。
　(ア)「●グローバル・ガイドライン
　インターネットがグローバルなネットワークであることには，いまさら議論の余地はない。インターネットによるパラダイム・シフトに備えて，セキュリティ・インフラストラクチャーを確立するために，いくつかの機関がセキュリティ・ポリシーのグローバル・ガイドラインの策定を進めている。「Ｃｏｂｉｔ」「ＧＡＳＳＰ」「ＧＭＩＴＳ」などがそれである。また，「ＣＣｖ２」のようにセキュリティ技術のグローバル・ガイドラインでありながら，セキュリティ・ポリシーのガイドラインを含むものもある。いずれにせよ，ＩＳＯ（国際標準化機構）では，セキュリティ・ポリシーに関するガイドラインの策定を間もなく終了するようだ。」（６８頁右欄１４〜２９行）
　(イ)「●セキュリティ・ポリシーとは何か
　セキュリティ・ポリシーとは，セキュリティ強度を高めるための全体的な基準である。企業の場合は，企業全体のセキュリティに関係する基準であり，上位から順に「エグゼクティブ・レベル・ポリシー」「コーポレート・レベル・ポリシー」「プロダクト・レベル・ポリシー」，そして「ポリシー・レビュー」に分類される（図３）。
　　(1)エグゼクティブ・レベル・ポリシー
　エグゼクティブ・レベル・ポリシーは，先に紹介したＣｏｂｉｔ，ＧＡＳＳＰ，ＧＭＩＴＳなどのグローバル・ガイドラインに対応するポリシーである。エグゼクティブ・レベル・ポリシー（あるいはグローバル・ガイドライン）は，セキュリティ原則に基づく上位のポリシーであり，国家における憲法のような役割を果たす。
　セキュリティ原則とは，理論的に最高のセキュリティ強度を得るための基準であり，企業のネットワーク・システムやコンピュータ・システム，実務処理の運用実態から独立した形で規定される。具体的には，表１に示した項目をさらに細分化した内容のものとなる。
　　(2)コーポレート・レベル・ポリシー
　エグゼクティブ・レベル・ポリシーが憲法に当たる部分であれば，コーポレート・レベル・ポリシーは法律に当たる部分である。コーポレート・レベル・ポリシーでは，エグゼクティブ・レベル・ポリシーによって定められた資産評価／分類基準に基づいて，セキュリティの対象となるネットワークやホスト，アプリケーションなどの企業リソースからプライオリティの高いリソースを決定する。資産評価／分類には，リソースを数値と質の両面から評価するＣＲＡＭＭやＣｏｕｒｔｅｎｙなどのリスク・アセスメント手法が利用されている。
　プライオリティの高いリソース（セキュリティ侵害から防御すべき対象）を明確にすることによって，セキュリティに対する予算と，セキュリティ強度の配分をプランニングすることが可能になる。
　実際には，プライオリティが付けられた企業リソースや企業活動の実体をエグゼクティブ・レベル・ポリシーの項目に対応させたものが，コーポレート・レベル・ポリシーになる。なお，コーポレート・レベル・ポリシーでは，エグゼクティブ・レベル・ポリシーの各項目のほかにサブポリシーが加えられるケースも多い。サブポリシーとしては，[1]ソフトウェア・ライセンス・コントロール，[2]ユーザＩＤ，[3]暗号化，[4]リモート・アクセス，[5]電子商取引，[6]電子メール，[7]リスク評価，[8]セキュリティ・テストなどがある。
　　(3)プロダクト・レベル・ポリシー
　プロダクト・レベル・ポリシーは，法律に基づいた実務体系と考えればよい。実際には，マーケットに供給されているセキュリティ製品や，フリー・ソフトウェアなどを使って上位ポリシーに沿ったセキュリティ対策を導入するプロセスとなる。
　現在のセキュリティ対策では，セキュリティ製品のセキュリティ・ルールを設定するだけで対応を済ませているのが普通である。しかし現実には，上位ポリシーとの連携を保ちながらプライオリティの高い企業リソースにどのようなセキュリティ対策を施せばよいのか，また，選定されたセキュリティ対策（製品）に対して，どのようなセキュリティ・ルールで上位ポリシーを実現し，個々に矛盾のない対策を施せるかによってセキュリティ強度が決まってくるのである。プロダクト・レベルのセキュリティ・ポリシーには表２に示すような項目が含まれる。当然，それぞれの項目の有無や区分け，内容は上位ポリシーによって変化する。
　　(4)ポリシー・レビュー
　ポリシー・レビューを現実の世界に当てはめると，法律を順守した運用が実際になされているかどうかをチェックする監査業務ということになる。ただし，セキュリティ・ポリシーのサイクルから見れば，単なる監査にとどまらず，常にセキュリティ強度を保ち続けるためのフィードバック・プロセスとしての役割も果たしている。仮に上位ポリシーに沿ってセキュリティ対策を施していたとしても，企業ネットワークやホスト，アプリケーションなど今日の企業リソースは日々変化を続けているため，単にポリシーが順守されていることの確認の意味だけではなく，上位ポリシーの見直しという観点からもポリシーへのフィードバックが必要になる。ポリシー・レビューは，[1]日常運用時のセキュリティ強度維持，[2]３〜６カ月単位でのポリシーへのフィードバックという２つの側面を持っている。
　また，たとえポリシー・アプローチによるセキュリティ・インテグレーションを行ったとしても，セキュリティ・システム導入時に得られるセキュリティ強度は，導入時の瞬間強度（写真のスナップショットのようなもの）にすぎない。そのため，ポリシー・フィードバックや日常運用管理のアプローチをとらなければ，セキュリティ強度は確実に低下してしまうことになる。」（６８頁右欄３０行〜７０頁左欄３８行）
　(ウ)「●ポリシー・アプローチによるセキュリティ・システム構築の手順
　それでは，セキュリティ・ポリシーは実際にどのように構築すればよいのだろうか。セキュリティ・ポリシーの構築には，かなりの専門知識とスキルが必要になるため，ノウハウを持ったシステム・インテグレーターに相談するのが最も確実なアプローチと言える。
　しかし，そのようなノウハウを持つシステム・インテグレーターは極めて少ないのが現状である。ここでは，セキュリティ・ポリシーの作成からセキュリティ・システム導入までの大まかな手順を紹介しておこう（図４）。
　　(1)グローバル・ガイドラインに基づいてエグゼクティブ・レベル・ポリシーを作成する。作成する際には，必ず企業経営陣へのインタビューを実施し，現状のセキュリティ認識（意識）を明確化する。経営陣へのインタビューは，企業全体のセキュリティ・ポリシーを作成してセキュリティ対策を実施するために必要なプロセスとなる。
　　(2)重要な企業リソースにプライオリティを付ける。プライオリティ付けにあたっては，各部門の責任者や担当者にインタビューを実施する。なお，インタビューを複数のレベルで実施し，インタビュー結果から各担当者の認識の違いや矛盾などを集約することにより，その精度を上げることができる。また，インタビューとは別に数値化されたリソース評価を必要とする場合には，最も価値の高いリソースに対してリスク・アセット・アセスメント手法を適用し，セキュリティ対策の費用根拠にすることも可能である。さらに，保管ツールとしてネットワーク構成を把握するネットワーク・ストラクチャ・ドローイング・ツールなどを利用するのも効果的な方法だ。
　　(3)プライオリティ付けを行った企業リソースおよび企業活動の実態をエグゼクティブ・レベル・ポリシーに対応させたコーポレート・レベル・ポリシーとサブポリシーを作成する。作成にあたっては，前項と同様のインタビュー・プロセスを実施する。
　　(4)プライオリティ付けを行ったリソース（守る対象）について，どのようなセキュリティ上の弱点があり，どのような対策が必要とされているかをコーポレート・レベル・ポリシーに基づいてプランニングする。補完ツールとしてネットワーク・スキャナおよびホスト・スキャナを利用してもよい。
　　(5)上位ポリシーを満たす具体的なセキュリティ製品の選定と導入を行う。この際，セキュリティ対象リソースを持つ各部門に「セキュリティ対策後はこのようなことができる，できない」というセキュリティ・ルールの確認をとるとよい。インタビュー・プロセスの精度が高ければ，実務部門の（ノンテクニカル）担当者が理解でき，実務上支障のないセキュリティ・ルールが確立されている。その後，具体的な各セキュリティ製品ごとのセキュリティ・スクリプトへの落とし込みと導入を行う。
　　(6)セキュリティ・システムがポリシーに矛盾することなく動作することを確認し，スキャナなどのツールを利用してセキュリティ・ホールが存在しないことを調査する。また，ホストなどのコンフィギュレーション情報や，各セキュリティ・ホール，運用・監視ガイダンスなどをドキュメント化する。」（７１頁右欄１行〜７３頁左欄９行）
　なお，引用例１中の特殊な文字は，近似する文字に置き換えた。
　
２−２　引用例記載発明
(1) 上記２−１の記載事項を検討するに，引用例１には，セキュリティ・ポリシー構築のノウハウを持ったシステム・インテグレーターによる，セキュリティ・ポリシーの作成の手順が記載されており，その手順は，次のとおりである。
　(i)　企業経営陣へのインタビューを実施し，グローバル・ガイドラインに基づいて，エグゼクティブ・レベル・ポリシーを作成する。
　(ii)　各部門の責任者や担当者にインタビューを実施し，重要な企業リソースにプライオリティを付ける。
　(iii)　各部門の責任者や担当者にインタビューを実施し，プライオリティ付けを行った企業リソース及び企業活動の実態をエグゼクティブ・レベル・ポリシーに対応させたコーポレート・レベル・ポリシーとサブポリシーを作成する。
(2) 上記(i)，(iii)の手順について検討するに，システム・インテグレーターは，企業経営陣及び各部門の責任者や担当者にインタビューを実施するところ，このインタビューで発する質問内容は，システム・インテグレーターが自己の知識として有する専門知識に基づくものであることは明らかである。
　そして，一般に，インタビューの実施においては，何らかの手段により回答が記録されるから，企業経営陣及び各部門の責任者や担当者に対するインタビューの実施においても，インタビューで得られる回答は，何らかの手段により記録されることも明らかである。
　また，企業経営陣に対する質問内容は，現状のセキュリティ認識（意識）を明確化し，エグゼクティブ・レベル・ポリシーを作成するのに必要な回答を得ることができるような内容であり，各部門の責任者や担当者に対する質問内容は，コーポレート・レベル・ポリシーとサブポリシーを作成するのに必要な回答を得ることができるような内容であるということができる。
　してみると，引用例１には，
「企業のエグゼクティブ・レベル・ポリシー，コーポレート・レベル・ポリシーとサブポリシーを作成するのに必要な事項に関する質問であって，前記企業に属する企業経営陣及び各部門の責任者や担当者にするべき質問を発するインタビュー実施手順と，
　前記発した質問に対する回答を取得し，記録手段に記録する回答記録手順と，
　前記記録手段に記録される前記回答に基づき，エグゼクティブ・レベル・ポリシー，コーポレート・レベル・ポリシーとサブポリシーを作成する作成手順と，
　をシステム・インテグレーターが実行する方法において，
　前記インタビュー実施手順は，企業経営陣に対する質問内容は，エグゼクティブ・レベル・ポリシーを作成するのに必要な回答を得ることができるような内容であり，各部門の責任者や担当者に対する質問内容は，コーポレート・レベル・ポリシーとサブポリシーを作成するのに必要な回答を得ることができるような内容である質問が発せられる方法。」
の発明（以下「引用例記載発明」という。）が記載されていると認められる。
　
２−３　対比・判断
２−３−１　本願発明５８について
(1) 本願発明５８（以下「前者」という。）と引用例記載発明（以下「後者」という。）とを対比すると，後者の「企業」，「エグゼクティブ・レベル・ポリシー，コーポレート・レベル・ポリシーとサブポリシー」，「作成」，「企業経営陣及び各部門の責任者や担当者」，「記録手段」が前者の「所定の団体」，「セキュリティポリシー」，「構築」，「メンバー」，「記憶手段」にそれぞれ相当する。
　また，後者の「インタビュー実施手順」は，システム・インテグレーターが自己の知識として有する専門知識に基づいて質問を生成し，該質問を発するといえるから，前者の「質問生成手順」に相当する。
　また，後者の「回答記録手順」は，取得した回答を記録手段に入力することにより記録し，保管しているといえるから，前者の「回答保管手順」に相当する。
(2) そうすると，両者は，
　「所定の団体のセキュリティポリシーを構築するのに必要な事項に関する質問であって，前記団体に属するメンバーにするべき質問を生成する質問生成手順と，
　前記生成した質問に対する回答を入力し，記憶手段に保管する回答保管手順と，
　前記記憶手段に保管される前記回答に基づき，セキュリティポリシーを構築する構築手順と，
　を実行する技術。」
である点で一致し，下記の点で相違する。
　〔相違点１〕前者の技術は，質問生成手順と回答保管手順と構築手順とを「コンピュータに実行させるためのプログラム」であるのに対し，後者の技術は，質問生成手順と回答保管手順と構築手順とをシステム・インテグレーターが実行する方法である点。
　〔相違点２〕前者の質問生成手順は，「被質問者の職務内容に基づき，前記被質問者にするべき質問を生成する」のに対し，後者の質問生成手順は，「企業経営陣に対する質問内容は，エグゼクティブ・レベル・ポリシーを作成するのに必要な回答を得ることができるような内容であり，各部門の責任者や担当者に対する質問内容は，コーポレート・レベル・ポリシーとサブポリシーを作成するのに必要な回答を得ることができるような内容である質問が発せられる」点。
(3)　相違点１について検討するに，コンピュータシステムを用いて，質問を自動生成し，回答を取得・保管し，回答に応じた何らかの処理結果を出力するものは，エキスパートシステムとして周知のものである。
　そして，エキスパートシステムは，現実のエキスパートが有する知識を活用できるものであれば，任意の分野に適用可能であるから，後者のシステム・インテグレーターが実行する方法を，エキスパートシステムで実現することは，当業者が容易に想到し得ることである。
　そして，後者の方法をエキスパートシステムで実現するのであれば，質問生成手順と回答保管手順と構築手順とをコンピュータに実行させるためのプログラムが必要となることは，当業者には自明の事項である。
　してみると，後者において，相違点１に係る構成を得ることは，当業者が容易に想到し得たことである。
(4)　相違点２について検討するに，後者の「企業経営陣」と「各部門の責任者や担当者」は，企業における階層を意味する用語であるところ，企業経営陣の職務が企業の経営であり，各部門の責任者や担当者の職務が各部門の処理であることは明らかであるから，「企業経営陣」と「各部門の責任者や担当者」は，それらの職務内容を含んだ用語である。
　そして，後者の質問生成手順が，企業経営陣に対して，エグゼクティブ・レベル・ポリシーを作成するのに必要な回答を得ることができるような内容の質問をし，各部門の責任者や担当者に対して，コーポレート・レベル・ポリシーとサブポリシーを作成するのに必要な回答を得ることができるような内容の質問をすることは，被質問者である企業経営陣及び各部門の責任者や担当者という異なる職務内容のメンバーに対して，それぞれに適合した質問を生成しているということができる。
　してみると，後者の質問生成手順を，被質問者の職務内容に基づき，前記被質問者にするべき質問を生成する構成とすることは，当業者が適宜なし得る事項である。
　したがって，後者において，相違点２に係る構成を得ることは，当業者が容易に想到し得たことである。
(5)　本願発明５８の作用効果についてみても，引用例記載発明から当業者が予測し得る程度のものであり，格別のものとはいえない。
　
２−３−２　本願発明１６について
　本願発明１６について検討するに，本願発明１６は，本願発明５８の「プログラム」をコンピュータに組み込むことによって構成される「セキュリティポリシー構築装置」であるところ，コンピュータへの組み込み自体に技術的特徴を有するものではない。
　してみると，本願発明１６は，上記本願発明５８について述べたのと同様の理由により，引用例記載発明及び周知事項に基づいて当業者が容易に発明をすることができたものである。
　
２−３−３　本願発明４７について
　本願発明４７について検討するに，本願発明４７は，本願発明５８の「プログラム」を記録した「コンピュータ読み取り可能な記録媒体」であるところ，コンピュータ読み取り可能な記録媒体への記録自体に技術的特徴を有するものではない。
　してみると，本願発明４７は，上記本願発明５８について述べたのと同様の理由により，引用例記載発明及び周知事項に基づいて当業者が容易に発明をすることができたものである。
　
２−４　まとめ
　したがって，本願発明１６，４７及び５８は，いずれも，引用例記載発明及び周知事項に基づいて当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により特許を受けることができない。
　
第４　むすび
　以上のとおり，本願は，特許請求の範囲の請求項１の記載が，特許法第３６条第６項第２号に規定する要件を満たしておらず，また，本願発明１６，４７，５８は，引用例記載発明及び周知事項に基づいて，当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。
　よって，結論のとおり審決する。