【事件の表示】
　特願２００８−１３０９８３「アソシエーションルールマイニングを使用してコンピュータ環境内の計算エンティティ向けコンフィギュレーションルールを生成するための方法及び装置」拒絶査定不服審判事件〔平成２１年　３月　５日出願公開、特開２００９−　４８６１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本件審判請求に係る出願（以下、「本願」という。）は、平成２０年５月１９日（パリ条約による優先権主張外国庁受理、２００７年５月３１日、米国）を出願日とする、特許法第３６条の２第１項の規定による出願であって、
平成２０年７月３１日付けで特許法第３６条の２第２項の規定による翻訳文が提出されるとともに平成２３年４月８日付けで審査請求がなされ、
平成２４年１１月２１日付けで拒絶理由通知（平成２４年１１月２７日発送）がなされ、
これに対して、平成２５年３月２６日付けで意見書が提出されるとともに同日付けで手続補正がなされ、
平成２５年５月２日付けで最後の拒絶理由通知（平成２５年５月１４日発送）がなされ、
これに対して、平成２５年８月１４日付けで意見書が提出されるとともに同日付けで手続補正書が提出され、
平成２５年９月２日付けで上記平成２５年８月１４日付けの手続補正書による補正の却下の決定（平成２５年９月１０日謄本発送・送達）がなされるとともに同日付けで上記平成２５年５月２日付けの拒絶理由通知書に記載した理由３（特許法第３６条第６項第２号）及び４（同法第２９条の２）によって拒絶査定（平成２５年９月１０日謄本発送・送達）がなされたものである。
　これに対して、「原査定を取り消す。この出願の発明は特許をすべきものとする、との審決を求める。」ことを請求の趣旨として平成２６年１月１０日付けで審判請求がなされるとともに同日付けで手続補正がなされ、
平成２６年４月１８日付けで審査官により特許法第１６４条第３項に定める報告がなされたものである。
　
　
第２．平成２６年１月１０日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２６年１月１０日付けの手続補正を却下する。
［理由］
１．本件補正
　平成２６年１月１０日付けの手続補正（以下、「本件補正」という。）により、特許請求の範囲は次のように補正された。
（本件補正前の特許請求の範囲）
「　　【請求項１】
　データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、複数の属性と当該コンフィギュレーションを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップと、
　前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析するステップと、
　前記関係に基づいてコンフィギュレーションルールを生成するステップと
を含む方法。
　　【請求項２】
　前記受け取るステップが、前記計算エンティティをポーリングするステップと、前記計算エンティティにエージェントを適用するステップの少なくとも１つを通じてコンフィギュレーションデータを収集するステップとをさらに含む、請求項１に記載の方法。
　　【請求項３】
　前記受け取るステップが、データベース中に前記コンフィギュレーションデータを保存
するステップをさらに含む、請求項１に記載の方法。
　　【請求項４】
　前記解析するステップが、前記コンフィギュレーションデータを前処理するステップを含む、請求項１に記載の方法。
　　【請求項５】
　コンフィギュレーション表が前記コンフィギュレーションデータを含み、前記前処理ステップが前記コンフィギュレーション表から前記解析のためのコンフィギュレーションデータのサブセットを選択する、請求項４に記載の方法。
　　【請求項６】
　前記解析するステップが、前記複数の計算エンティティからの前記コンフィギュレーションデータ間の関係を推測する、請求項１に記載の方法。
　　【請求項７】
　前記解析するステップが、前記コンフィギュレーションデータに対して解析を行なう、請求項１に記載の方法。
　　【請求項８】
　前記コンフィギュレーションルールに対して統計解析を適用するステップをさらに含む、請求項１に記載の方法。
　　【請求項９】
　前記統計解析が前記コンフィギュレーションルールの各々の信頼性を求める、請求項８に記載の方法。
　　【請求項１０】
　前記コンフィギュレーションルールに対して後処理を行なうステップをさらに含む、請求項１に記載の方法。
　　【請求項１１】
　前記生成されたコンフィギュレーションルールをコンフィギュレーションデータと比較するステップと、
　前記コンフィギュレーションデータ中の前記コンフィギュレーションルールの違反を識別するステップとをさらに含む、請求項１に記載の方法。
　　【請求項１２】
　データセンタの複数の計算エンティティから収集されたコンフィギュレーションデータであって、複数の属性と当該コンフィギュレーションを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、前記コンフィギュレーションデータのセマンティクスとは無関係に解析して前記複数の属性間の関係を推測し、少なくとも１つのコンフィギュレーションルールを生成するアナライザを備える装置。
　　【請求項１３】
　前記複数の計算エンティティ向けコンフィギュレーションデータを収集するためのコンフィギュレーションデータ監視システムをさらに備える、請求項１２に記載の装置。
　　【請求項１４】
　前記コンフィギュレーションデータを前処理するためのプリプロセッサをさらに備える、請求項１２に記載の装置。
　　【請求項１５】
　前記アナライザが、前記複数の計算エンティティからの前記コンフィギュレーションデータ間の関係を推測する、請求項１２に記載の装置。
　　【請求項１６】
　前記アナライザが、前記コンフィギュレーションデータに対してマーケットバスケット解析を行なう、請求項１２に記載の装置。
　　【請求項１７】
　前記コンフィギュレーションルールの少なくとも１つに統計解析を適用して前記ルールを確認するポストプロセッサをさらに備える、請求項１２に記載の装置。
　　【請求項１８】
　前記統計解析が前記コンフィギュレーションルールの各々の信頼性を求める、請求項１７に記載の装置。
　　【請求項１９】
　生成されたコンフィギュレーションルールの少なくとも１つとコンフィギュレーションデータに対する所定のルールを比較して、前記コンフィギュレーションデータ中の、前記生成されたコンフィギュレーションルールの違反を識別するための違反アナライザをさらに備える、請求項１２に記載の装置。」
（本件補正後の特許請求の範囲）
（以下、本件補正により補正された特許請求の範囲に記載された各請求項を「補正後請求項」という。）
「　　【請求項１】
　データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップと、
　前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析するステップと、
　前記関係に基づいてコンフィギュレーションルールを生成するステップと
を含む方法。
　　【請求項２】
　前記受け取るステップが、前記計算エンティティをポーリングするステップと、前記計算エンティティにエージェントを適用するステップの少なくとも１つを通じてコンフィギュレーションデータを収集するステップとをさらに含む、請求項１に記載の方法。
　　【請求項３】
　前記受け取るステップが、データベース中に前記コンフィギュレーションデータを保存するステップをさらに含む、請求項１に記載の方法。
　　【請求項４】
　前記解析するステップが、前記コンフィギュレーションデータを前処理するステップを含む、請求項１に記載の方法。
　　【請求項５】
　コンフィギュレーション表が前記コンフィギュレーションデータを含み、
　前記前処理ステップが前記コンフィギュレーション表から前記解析のためのコンフィギュレーションデータのサブセットを選択する、請求項４に記載の方法。
　　【請求項６】
　前記コンフィギュレーションルールに対して統計解析を適用するステップをさらに含む、請求項１に記載の方法。
　　【請求項７】
　前記統計解析が前記コンフィギュレーションルールの各々の信頼性を求める、請求項６に記載の方法。
　　【請求項８】
　前記コンフィギュレーションルールに対して後処理を行なうステップをさらに含む、請求項１に記載の方法。
　　【請求項９】
　前記生成されたコンフィギュレーションルールをコンフィギュレーションデータと比較するステップと、
　前記コンフィギュレーションデータ中の前記コンフィギュレーションルールの違反を識別するステップとをさらに含む、請求項１に記載の方法。
　　【請求項１０】
　データセンタの複数の計算エンティティから収集されたコンフィギュレーションデータであって、複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて解析し、前記複数の属性間の関係を推測し、少なくとも１つのコンフィギュレーションルールを生成するアナライザを備える装置。
　　【請求項１１】
　前記複数の計算エンティティ向けコンフィギュレーションデータを収集するためのコンフィギュレーションデータ監視システムをさらに備える、請求項１０に記載の装置。
　　【請求項１２】
　前記コンフィギュレーションデータを前処理するためのプリプロセッサをさらに備える、請求項１０に記載の装置。
　　【請求項１３】
　前記アナライザが、前記複数の計算エンティティからの前記コンフィギュレーションデータ間の関係を推測する、請求項１０に記載の装置。
　　【請求項１４】
　前記アナライザが、前記コンフィギュレーションデータに対してマーケットバスケット解析を行なう、請求項１０に記載の装置。
　　【請求項１５】
　前記コンフィギュレーションルールの少なくとも１つに統計解析を適用して前記ルールを確認するポストプロセッサをさらに備える、請求項１０に記載の装置。
　　【請求項１６】
　前記統計解析が前記コンフィギュレーションルールの各々の信頼性を求める、請求項１５に記載の装置。
　　【請求項１７】
　生成されたコンフィギュレーションルールの少なくとも１つとコンフィギュレーションデータに対する所定のルールを比較して、前記コンフィギュレーションデータ中の、前記生成されたコンフィギュレーションルールの違反を識別するための違反アナライザをさらに備える、請求項１０に記載の装置。」
 
２．補正の適否
（１）新規事項の追加及び補正の目的要件
（１−１）本件補正の分析及び認定
　本件補正は、以下の変更を伴うものである。
補正１）補正前の請求項１の
「複数の属性と当該コンフィギュレーションを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップ」
を、
「複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップ」
へと変更するもの。要するに、補正前に記載した「コンフィギュレーション」を、「コンフィギュレーションデータ」へと改めるもの。
補正２）補正前の請求項１の
「前記コンフィギュレーションデータのセマンティクスとは無関係に前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する」
を、
「前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する」
へと変更するもの。要するに、補正前の「解析する」とした処理に対して、新たに「前記コンフィギュレーションデータの値に基づいて」とする特定事項を付すもの。
補正３）補正前の請求項９及び請求項１０を、削除し、以後の請求項の番号を繰り上げるもの。
補正４）補正前の請求項１２の「複数の属性と当該コンフィギュレーションを特徴づけるセマンティクスとを有するコンフィギュレーションデータ」及び「前記コンフィギュレーションデータのセマンティクスとは無関係に解析して」を、上記補正１及び補正２と同様に変更するもの
（１−２）検討／判断
　上記補正１〜補正４について、各々検討する。
補正１について：
　補正１の対象としている請求項１は、方法の発明とされており、当該方法の発明が果たそうとしている内容は、本件明細書の翻訳文（以下、単に「本件明細書」と呼ぶ。）【0001】に記載されているとおり、コンピュータ環境内の計算エンティティ向けコンフィギュレーションルールを生成する方法の提案である。
　そのために行うとされた最初のステップは、ルール生成に必要な原初のデータ収集であることは明らかであり、本件明細書では、特に【0022】及び【0023】にて、「コンフィギュレーション」とは、機能ユニットを配置することであり、「コンフィギュレーションデータ」とはシステム等に関して収集される、きめの細かいデータであると定義されている。
　また、「特徴づける」とされた、「セマンティクス」について、本件明細書では、【0029】、【0030】、【0046】、【0059】に当該用語を用いた説明がなされている。加えて、本件が属する技術分野における当該「セマンティクス」という語の通常用いられ方としては、『意味』あるいは『意味論』として用いられている事実がある。
　以上を総合すると、セマンティクスと複合して用いるべき対象は、何らかの情報／データの次元のものであるといえる。そして何より、当該「セマンティックス」に対して、情報ないしデータの形式値を超えて把握・認識できる事項を指すとして見た場合、本件明細書の上記該当箇所には「・・・・のセマンティクス」とした用法が複数確認でき、かつ、“コンフィギュレーション情報／データの意味”と読み替えた上で、本件明細書を読み解いた場合には、いずれの明細書の記載箇所も技術的なつじつまが合う状況とも認識できる。
　してみると、本件の請求項１の記載上、「セマンティクス」と合わさって記載すべき対象として、「コンフィギュレーション」が相応しいのか、それとも「コンフィギュレーションデータ」が相応しいのかを考えた場合、明確に「データ」の語を含む後者（＝「コンフィギュレーションデータ」）を選定するのが本来的であると言うべきであって、補正１により「コンフィギュレーション」が、「コンフィギュレーションデータ」とされた変更は、本件明細書の用語の定義、用語の扱われ方、本件が属する技術分野上の通常の扱い、の３点に適ったものと言うべきである。
　そうすると、補正１は、願書に最初に添付した明細書、特許請求の範囲又は図面の翻訳文に記載した事項の範囲内においてなされたものと扱って特段の支障はなく、特許法第１７条の２第３項の規定に適合していると認められる。
　
　そして、この補正１の目的を検討してみると、最後の拒絶理由を通知した通知書及び拒絶査定の理由３（特許法第３６条第６項第２号）とされた中の、（２）にて、指そうとする意味が不明確であるとされた記載箇所に対してした補正になるため、特許法第１７条の２第５項第４号でいう、明りょうでない記載の釈明を目的とするものと認められる。
補正２について：
　新たに追加された、解析を実行する上で必要となるパラメータを、「前記コンフィギュレーションデータの値」とする旨の特定事項は、明細書の【0038】に、
「ある実施形態では、アナライザソフトウェア２０６は、コンフィギュレーションデータを表わす表を解析し、表の列の値を基に列の間の関係を推測する。」
とされた箇所や、
【0040】の
「アナライザソフトウェア２０６は、関係を推測するためにＨＢＡ上のファームウェアのバージョンを選択する。アナライザソフトウェア２０６は、コンフィギュレーションデータの表を解析し、所与の記憶領域のネットワークエンティティに対して、ファームウェアのバージョン及びＨＢＡなどの表の列（或いはコンフィギュレーション属性又は属性値の対）間の関係を、それらの値を基に推測する。」
とされた箇所があることから、願書に最初に添付した明細書、特許請求の範囲又は図面の翻訳文に記載した事項の範囲内においてなされており、特許法第１７条の２第３項の規定に適合している。
　そして、この補正２の目的を検討してみると、形式的に補正前の「解析するステップ」に対して、そのルールを特定しないとする状態であったものを、当該事項を追加することで特許請求の範囲の限定的減縮を図ろうとしたものと考えられる。なお、当該特定事項の追加により、産業上の利用分野及び解決しようとする課題の変更に至るものではないことは明らかである。
　以上により、当該補正２は、特許法第１７条の２第５項第２号を目的とするものと認められる。
補正３について：
　当該補正３は、単に請求項の一部を削除するものであるから、特許法第１７条の２第５項第１号に示す、請求項の削除を目的とするものである。
補正４について：
　当該補正４は、上記「補正１について」及び「補正２について」で検討した各々の事項を同じく内容として含むものであるため、既に示したとおり、いわゆる新規事項を含む補正ではなく、目的要件も適うとされたものである。
　
（１−３）小括
　上記（１−２）で示すとおり、本件補正は特許請求の範囲の限定的減縮を目的とする内容を含むものである。
（２）独立特許要件についての判断
　上記（１）のとおり、本件補正は限定的減縮を目的とする内容を含むものであるので、本件補正後の請求項１及び１０に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否かについて、以下に検討する。
  
（２−１）本件補正発明
　本件補正後請求項１及び１０に記載された発明のうち、代表して請求項１に記載された発明（以下、「本件補正発明」という。）は、前記平成２６年１月１０日付けの手続補正（本件補正）により補正された特許請求の範囲の請求項１に記載されたとおりの次のものである。（再掲する。）
　
「　　【請求項１】
　データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップと、
　前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析するステップと、
　前記関係に基づいてコンフィギュレーションルールを生成するステップと
を含む方法。」
（２−２）特許請求の範囲の記載の明確性（特許法第３６条第６項第２号）についての検討
　本件補正発明の記載の「複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有する」について、その示す技術的意味が何であるのかを検討する。
　本件補正発明の記載は、コンフィギュレーションデータが、「複数の属性」と、「セマンティクス」との二者を「有する」といった、コンフィギュレーションそれ自体の構成に関する事項を宣言すると共に、コンフィギュレーションの一部とされた「セマンティクス」により、コンフィギュレーションデータ全体が何らかの特徴づけがなされるものであることを記載上では宣言している。
　ところが、ここで記載されている「複数の属性」、及び、「（当該）コンフィギュレーションデータを特徴づけるセマンティクス」が、第１パラグラフで「受け取る」とされた「コンフィギュレーションデータ」と如何なる関係にあるかについて、本件補正発明では請求項内に直接的に定義ないし特定した記載が見当たらない。
　そこで、これらの２つの語について、請求人が平成２６年２月２０日付け手続補正書（方式）にて補充した平成２６年１月１０日付け審判請求書の請求の理由（以下、単に「本件審判請求の理由」と言う。）に関する主張や、受信されたコンフィギュレーションデータの実施例とも照合しつつ検討を行った。
　そもそも、問題とされた２語の内、前者の「属性」は、コンフィギュレーションが通常扱う、システム内の個々のエンティティの、いわゆるプロパティそのものを指し、本件が属する分野で一般的にコンフィギュレーションと同時に扱われている情報／データであるといえ、特段定義することを要しない用語であるが、後者の「コンフィギュレーションデータを特徴づけるセマンティクス」については、「属性」と別個に記載された用語であり、「セマンティクス」の一般的な用法が、審判請求書の請求の理由で、電気工学ハンドブック等を引用しつつ請求人が主張する、“意味”であるとは解せるものの、当該記載を、『コンフィギュレーションデータを特徴づける意味』と読み替えてもなお、その指し示す内容が如何なるものであるかは依然として判然としないと言うべきである。
　加えて、コンフィギュレーションデータと、セマンティクスとの関係について、セマンティクスがコンフィギュレーションデータを“特徴づけ”る関係にあることは、決して一般的ではなく、請求人が請求の理由の「４．本願発明が特許されるべき理由」欄の（１）、２）にて直接的に示した段落【0030】、【0038】、【0040】のいずれにも、特徴づけに関係したり、解る程度に示唆した記述は見当たらず、請求人が主張する“明らか”な状態とは認められない。
　むしろ、実施例を参照する限り、データ上何らかの意味を付帯する項目はすべての列データについて認識できると言うべきであって、関係を分析されている列項目の二者の例を見ると、「アプリケーション」については、属性名表記であり、「ＨＢＡの数」は、数値データの形式での表記がなされているという点で、データ形式上の表記の違いは認められるものの、１つのデータ表記が数値である場合、数値表記とされたパラメータのデータが必ずそのエンティティ全体を特徴づけるパラメータとなる関係を有するものでもない。
　以上のことから、本件補正発明の「コンフィギュレーションデータ」に対して記載された事項である「（当該）コンフィギュレーションデータを特徴づけるセマンティクス」の記載は、特許法第３６条第６項第２号の規定に定めた、発明が明確であることに該当しない記載上の不備があると認められる。
　なお、請求項１０にも同様の表記が存在する関係上、請求項１０に係る発明についても同様の不備がある。
　よって、本件補正後の請求項１及び１０の記載は、特許法第３６条第６項第２号の規定の要件を満たしておらず、本件補正後の請求項１及び１０に係る発明は特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　上記（２−２）で検討したとおり、本件補正発明における「複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有する」との記載の技術的な意義は明確なものではないが、ここで、本件の発明の詳細な説明に記載した事項を解釈し、援用することにより、不明とされた「コンフィギュレーションデータ」が、少なくとも【表１】ないし【表３】の、名称データと、数値データの２種のデータを含むものであると扱った場合について、他の特許要件に関する検討を追加的に進めてみる。
（２−３）先の出願の記載事項及びその発明
　本願の最先の優先日前に出願され、本願の出願後に国際公開がされた特願２００７−５４６３２３号（国際公開第２００７／０６０７２１号、国際公開日は２００７年５月３１日、出願日とみなされる国際出願日は２００５年１１月２４日。）（以下、「先の出願」という。）には、図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で附加したものである。）
Ａ「
[0017] 　［管理支援対象ネットワーク２−１〜２−ｎ］
　
管理支援対象ネットワーク２−１〜２−ｎそれぞれは、ネットワーク２０を介して互いに接続されたＩＴインフラ環境２２、管理サーバ２４およびインフラデータベース（インフラＤＢ）２６を有する
　
ＩＴインフラ環境２２は、ネットワーク２２０を介して互いに接続された例えばサーバ２２２−１〜２２２−ｍ（ｍは整数）とＰＣ（パーソナルコンピュータ：クライアント）２２４−１〜２２４−ｌ（ｌは整数）とを有し
[0018]　なお、管理支援対象ネットワーク２−１〜２−ｎは、サーバ２２２およびＰＣ２２４の数がそれぞれ異なるものであってもよい。
　したがって、管理支援対象ネットワーク２−１〜２−ｎには、個々のネットワークを区別するために、例えば１〜ｎの固有のＩＤ（インフラＩＤ）がそれぞれ設定されている。
[0019]　
サーバ２２２−１〜２２２−ｍそれぞれは
図示しないＭＩＢ（Management Information Base）から後述する構成情報２６０（図３参照）および性能情報２６４（パフォーマンス情報：図４参照）などを管理サーバ２４に対して送信する
[0020]　
管理サーバ２４は、ＳＮＭＰマネージャとして機能するソフトウェアの監視部２４０を有し、自己およびサーバ２２２−１〜２２２−ｍなど（管理支援対象ネットワーク２内）の構成情報２６０および性能情報２６４などを所定のタイミングで取得し、インフラＤＢ２６に対して出力する
　また、管理サーバ２４には、自己を示す固有のサーバＩＤが設定されている。
[0021]　
インフラＤＢ２６は、管理サーバ２４から入力される構成情報２６０および性能情報２６４などを記憶し
　なお、インフラＤＢ２６は、管理サーバ２４に接続されたストレージであってもよいし、管理サーバ２４内に含まれてもよいし、独立したサーバであってもよい。」
Ｂ「
[0022]　管理支援システム３は、管理支援サーバ３０、システムデータベース（システムＤＢ）３２、規則記憶部３４および端末３６から構成される。
　
管理支援サーバ３０は、例えばデータ収集部３００、規則生成部３０２および情報抽出部３０４を有する
　データ収集部３００は、ネットワーク１０を介し、管理支援対象ネットワーク２−１〜２−ｎそれぞれのインフラＤＢ２６から構成情報２６０および性能情報２６４などを収集し、システムＤＢ３２に記憶させる。」
[0023]　
規則生成部３０２は、管理者による設定などの入力を、端末３６を介して受け入れ、システムＤＢ３２から管理支援対象ネットワーク２−１〜２−ｎそれぞれの構成情報および性能情報を取得し、例えばデータマイニングで用いられる決定木やニューラルネットワークなどの学習手法により、構成情報を稼動時の特徴的な性能情報に基づいて分類する分類規則を生成し、生成した分類規則を規則記憶部３４に記憶する
[0024]　情報抽出部３０４は、端末３６を介して入力される管理者の設定などに応じて規則記憶部３４から分類規則を取得し、例えばサーバ２２２いずれかの稼動時の必要性能条件を満たす他のサーバ２２２の構成情報２６０、またはサーバ２２２いずれかの稼動時の必要性能条件に対してボトルネックとなる構成情報２６０および性能情報２６４またはこれらのいずれかを端末３６に対して出力する。
[0025]　端末３６は、例えばコンピュータ本体３６０と、コンソールを表示する入出力装置（ＵＩ装置）３６２とを有するＰＣ（パーソナルコンピュータ）であり、管理者による設定などの入力を受け入れて管理支援サーバ３０に対して出力するとともに、管理支援サーバ３０から入力される情報を表示する。」
Ｃ「
[0026]　［ハードウェア］
　図２は、図１に示したサーバ２２２のハードウェア構成の概要を示すブロック図である。
　
図２に示すように、サーバ２２２は、処理部４０、メモリ部４２、制御部４４、記憶部４６、通信部４８およびシステムバス５０などを有する
　
処理部４０は、例えばマルチプロセシング可能な２つのＣＰＵ４００を有し、演算処理を行うとともにサーバ２２２を構成する各部を制御するＣＰＵサブシステムを構成する
Ｄ「
[0036]　［規則生成部３０２］
　次に、規則生成部３０２が行う処理について詳述する。規則生成部３０２では、データマイニング手法として一般に用いられる決定木生成アルゴリズムを採用する。
　図７は、規則生成部３０２がシステムＤＢ３２から取得した性能情報３２４のうち、決定木のクラスに指定する属性（目標属性と呼ぶ）の属性値（クラスと呼ぶ）を離散値化（２値化）した処理結果を示す図表である。目標属性の設定とクラスの離散化は、管理者が予め規則生成部３０２に設定するか、管理者が端末３６を介して入力する。
　例えば目標属性をプロセッサ使用率とし、プロセッサ使用率が７０％未満であるか否かを離散化の条件（境界値）とした２つのクラス（クラス：０−７０、クラス：７０−１００）が設定されている場合、規則生成部３０２は、管理者による所定の問い合わせ（図１３，１５を用いて後述）などの入力を端末３６を介して受け入れると、システムＤＢ３２から構成情報３２０および性能情報３２４を取得し、図７に示すようにプロセッサ使用率のクラスをクラス：０−７０と、クラス：７０−１００とに分類する離散値化（２値化）の処理を性能情報３２４に対して行う。
[0037]　また、規則生成部３０２は、構成情報３２０および性能情報３２４を用いて、サーバＩＤごと、サーバＩＤとＯＳの組み合わせごと、サーバ名とＯＳの組み合わせごと、または、ＣＰＵの名前、周波数、数量およびメモリサイズの組み合わせごとなどの所定の構成情報ごとに、性能情報３２４に対して離散値化の処理を行うようにされている。
　そして、
規則生成部３０２は、管理者が設定する所定の構成条件に応じてデータを集約して、クラスが規則の結論部になるように学習を行い、決定木を生成する
　規則生成部３０２が行う離散値化は、２値化に限定されることなく、例えば３値化または４値化するものであってもよい。
[0038]　ここで、管理者は、サーバ２２２に対するＣＰＵ４００の増設などの検討が必要な稼動状況であるか否かを判断するために、例えばプロセッサ使用率の境界値を７０％に設定している。
　また、規則生成部３０２が性能情報３２４を離散値化する条件は、プロセッサ使用率の境界値に限定されることなく、例えば１秒当たりの転送ページ数などの他の性能パラメータであってもよい。
[0039]　図８は、管理者が設定したサーバ２２２の所定の構成条件（構成情報）に対し、規則生成部３０２が生成する決定木の例である。
　図８に示すように、規則生成部３０２が生成する決定木６において、根となるノード６００は、属性と属性値のペアからなる条件（以下、属性条件）がアクティブセッション（同時接続ユーザ数）について設定されている。
　例えば、規則生成部３０２は、ノード６００において、性能情報を同時接続ユーザ数が４２以下となる枝と、同時接続ユーザ数が４２よりも大きい値となる枝とに分割する。
[0040]　また、規則生成部３０２は、２値化した結果のいずれか（クラス：０−７０またはクラス：７０−１００）が結論部として葉に位置するように、例えば属性条件がディスク使用率について設定されているノード６０２、属性条件が使用可能メモリ量について設定されているノード６０４、属性条件がメモリ使用量について設定されているノード６０６、属性条件が使用可能メモリ量について設定されているノード６０８および属性条件が１秒当たりの転送ページ数について設定されているノード６１０により、枝をさらに分割する。
[0041]　なお、
規則生成部３０２は、構成情報３２０および性能情報３２４を用いて、サーバＩＤごと、サーバＩＤとＯＳの組み合わせごと、サーバ名とＯＳの組み合わせごと、または、ＣＰＵの名前、周波数、数量およびメモリサイズの組み合わせごとなどの所定の構成情報ごとに複数の学習を行い、複数の決定木を生成するようにされている
　
つまり、規則生成部３０２は、所定の構成条件に対し、管理者が設定する目標属性およびクラスに応じて１つ以上の決定木を生成することにより、複数のＩＦ−ＴＨＥＮ規則で表現される分類規則を生成する
[0042]　
例えば、所定の構成情報に対して規則生成部３０２が生成した決定木６の最も左側（図８の左側）の枝を根から葉まで辿ることにより、同時接続ユーザ数が４２以下であり、かつ、ディスク使用率が５．５０％以下であり、かつ、メモリ使用量が２００ＭＢｙｔｅ以下である場合、管理者が設定する所定の構成条件におけるプロセッサ使用率は７０％未満（クラス：０−７０）であるというＩＦ−ＴＨＥＮ規則が示される
　
Ｅ「
[0004]　
本発明は
ネットワークの管理方法を提供することを目的とする
Ｆ「
[0029]　なお、サーバ２２２は、ＣＰＵ４００の数および処理能力、メモリ部４２および記憶部４６の記憶容量、ファームウェアならびに通信速度などの仕様が個々に異なるものであってもよく、ＣＰＵ４００の増設などの構成の変更も可能にされている。
　したがって、サーバ２２２−１〜２２２−ｍには、個々を区別するために、例えば１〜ｍの固有のＩＤ（サーバＩＤ）がそれぞれ設定されている。
　また、
管理サーバ２４および管理支援サーバ３０は、例えばサーバ２２２とほぼ同じハードウェア構成になっており、個々に所定数のＣＰＵ４００および処理能力などが設定されている
　上記Ａには、図2で図示された処理部を有するサーバ222（図2及び[0026]参照）を複数台含むものを、図1で図示される管理サーバ24が管理する、ネットワーク10及び20で統合されたＩＴインフラと称される構成（図1及び[0017]参照）が、上記Ｃには、当該処理部は演算処理を行う旨（[0026]参照）が、及び、上記Ａには他に、個々の管理サーバの下に存在してる複数のサーバ群に関する構成情報および性能情報を、インフラＤＢが受信し、記憶する旨（[0019]〜[0021]参照）が、各々記載されている。
　また、上記Ｂ、Ｄ及びＦには、管理支援サーバがCPUを有し、処理機能を有するものであること（[0029]参照）、当該管理支援サーバが規則生成部を有し（[0022]参照）、当該規則生成部がデータマイニングの手法で、構成情報を特徴的な性能情報に基づいて分類し、分類規則を生成すること（[0023]参照）、及び、データマイニングの手法の一つである決定木生成アルゴリズムを採用した態様として、ＩＦ−ＴＨＥＮ規則のＴＨＥＮを性能情報である同時接続ユーザ数とし、ＩＦを所定の構成情報とするデータの集約を図った例（[0037]、[0041]、[0042]参照）が記載されている。
　上記Ｅには、ネットワークの管理方法を目的とすることが記載されている。
　上記ＡないしＦの記載を踏まえると、先の出願には、次の発明（以下、「先の発明」という。）が記載されているものと認められる。
（先の発明）
「ネットワークで統合された複数の演算処理サーバからなるＩＴインフラの構成情報及び性能情報をインフラＤＢが受信して記憶し、
　ＣＰＵを有する管理支援サーバの規則生成部が、データマイニング手法の一つである決定木アルゴリズムを採用して、特徴的な前記性能情報に基づいて、前記構成情報とのＩＦ−ＴＨＥＮ規則が成立する構成情報を分類するデータ集約を行い、
　前記ＩＦ−ＴＨＥＮ規則を生成する
ネットワークの管理方法。」
　
（２−４）本件補正発明と先の発明との対比
　本件補正発明と先の発明とを対比する。
ア．本件補正発明の「データセンタの複数の計算エンティティ」とは、本件明細書の【0002】及び【0017】に記載された「データセンター」に関する記述及び定義、【0015】に記載された「計算エンティティ」に関する定義、【0021】に記載されている事項、及び【0025】に記載され参照された図１のデータセンター１１２を図示の一部に含む図面を見て解るとおり、ネットワークでコンピュータ及びリソースが統合された構成をなすものを条件に含むものである。
　また、一般的に「サーバ」と称するシステムは、ユーザーに対してある情報サービスを提供するものとされている関係から、コンピュータやデータベース等のコンピュータリソースのいずれか、あるいは双方にて代表されるものと認識されている。
　してみると、先の発明の「ネットワークで統合された複数の演算処理サーバからなるＩＴインフラ」は、本件補正発明の「データセンタの複数の計算エンティティ」に相当する関係にある。
　また、先の発明の「構成情報」は、システムの「構成」が、本件が属するＩＴ分野における一般的な別表現で「コンフィギュレーション」とされることを考えると、本件補正発明の「コンフィギュレーションデータ」に相当する。
　また、先の発明の「ネットワークで統合された複数の演算処理サーバからなるＩＴインフラの構成情報」「を受信し」と、本件補正発明の「データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、」「コンフィギュレーションデータを、受け取る」とは、コンフィギュレーション（＝構成）データ（＝情報）を受信すると言う点では双方共通する。
イ．先の発明の「ＣＰＵを有する管理支援サーバの規則生成部が、データマイニング手法の一つである決定木アルゴリズムを採用して、特徴的な前記性能情報に基づいて、前記構成情報とのＩＦ−ＴＨＥＮ規則が成立する構成情報を分類するデータ集約を行い」に関して、「ＣＰＵを有する管理支援サーバの規則生成部」とされたものは、プロセッサを有するシステムであることが明らかであるから、本件補正発明の「プロセッサを有する計算システム」に相当する。
　同様に、先の発明の「構成情報を分類するデータ集約を行い」は、対象として扱うデータが上記ア．の対応関係の整理で一致し、また、取扱いの処理態様としてあげられた「分類するデータ集約」は、一種の「解析」と言えるので、本件補正発明の「コンフィギュレーションデータを解析する」（ステップ）である点で共通するといえる。
ウ．先の発明の「ＩＦ−ＴＨＥＮ規則を生成する」は、直前の処理ステップで規則生成部が行うとされた「分類するデータ集約」の過程で生成されるものであり、本件補正発明における「コンフィギュレーションルールを生成する」（ステップ）と、連続して行われる処理、すなわち、前段の処理過程で生成される規則／ルールを生成する点で共通すると言える。
　以上から、本件補正発明と先の発明とは、以下の点で一致し、また、以下の点で相違する。
（一致点）
「　データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、コンフィギュレーションデータを、受け取るステップと、
　プロセッサを有する計算システムが前記コンフィギュレーションデータを解析するステップと、
　コンフィギュレーションルールを生成するステップと
を含む方法。」
（相違点１）
　冒頭の「コンフィギュレーションデータを、受け取るステップ」に関し、
本件補正発明が、当該「コンフィギュレーションデータ」に対して、「複数の属性と当該コンフィギュレーションデータを特徴づけるセマンティクスとを有する」とした特定事項を付しているのに対して、先の発明は、「ネットワークで統合された複数の演算処理サーバからなるＩＴインフラの構成情報及び性能情報」であるとしている点。
（相違点２）
　本件補正発明の第２パラグラフに記載された「前記コンフィギュレーションデータを解析するステップ」に関し、本件補正発明が、「前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して」解析するとしているのに対して、先の発明は、「データマイニング手法の一つである決定木アルゴリズムを採用して、特徴的な前記性能情報に基づいて、前記構成情報とのＩＦ−ＴＨＥＮ規則が成立する構成情報を分類する」としている点。
　これに伴い、第３パラグラフの「生成する」とされたステップも、本件補正発明は「前記関係に基づいて」ルールが生成されるとされているのに対して、先の発明で生成するルール（＝規則）は、「データマイニング手法の一つである決定木アルゴリズムを採用して、特徴的な前記性能情報に基づい」た「前記構成情報とのＩＦ−ＴＨＥＮ規則」となっている点。
（２−５）当審の判断
　上記相違点１及び相違点２について検討する。
（２−５−１）相違点１について
　先の発明との間で相違点１とされている事項は、本件補正発明に対して新たに扱うとされた特定事項と再度対比し直してみると、冒頭の「コンフィギュレーションデータを、受け取るステップ」に関し、
本件補正発明が、当該「コンフィギュレーションデータ」に対して、『【表１】ないし【表３】の、名称データと、数値データの２種のデータを含むもの』とした特定事項を付しているのに対して、先の発明は、「ネットワークで統合された複数の演算処理サーバからなるＩＴインフラの構成情報及び性能情報」であるとしている点、になる。
　本件補正発明の『名称データ』及び『数値データ』は、各々、前者が表で示す具体例として、『ホストとして働くアプリケーション』の項目中の『ORACLE』になり、後者は『ＨＢＡの数』の項目中の『２』を、対象の想定に含むことになる（注：この二者を実際に解析対象として扱っていることを説明した記載箇所は、翻訳文中の【0038】となる。）。
　そして、先の発明の特定事項と対比してみると、本件補正発明の名称データとされているORACLEは、ＩＴインフラの構成情報に該当し、ＨＢＡの数＝２は、ＩＴインフラの性能情報に該当することとなるのは、言うまでも無く明らかである。
　よって、当該相違点１は、実質的に相違したものではない。
（２−５−２）相違点２について
　続いて、相違点２について検討する。
　本件補正発明において、解析に対して付している特定事項は、「前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して」行うものとしているが、その処理内容を直接特定している箇所は、
「プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測」（する）
であり、それ以外の事項である
「前記コンフィギュレーションデータ中の関係を推測するために、」
は、処理の目的を叙述する形式として記載されたに留まると解釈される。なぜなら、語尾に「〜ために」が採用されており、当該「ために」は、目的を表す接続詞であるからである。
　そして、当該相違点２にも、前記「（２−５−１）相違点１について」で検討し、記載不明瞭とされた「前記コンフィギュレーションデータのセマンティクス」が、特定事項の中に含まれている関係であるため、同様に当該部分を、名称データであってコンフィギュレーション上、別なる意味を各々有している属性データ、であると扱った上で、処理を特定した箇所を分析してみると、
“プロセッサを有する計算システムが、名称データであってコンフィギュレーション上、別なる意味を各々有している属性データとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して”行うもの
であることとなる。
　該特定しようとした解析の内容がどのようなものを指すのかについて、本件明細書では【0038】に、
「・・・収集されたコンフィギュレーションデータを解析する。ある実施形態では、アナライザソフトウェア２０６は、コンフィギュレーションデータを表わす表を解析し、表の列の値を基に列の間の関係を推測する。例えば、いくつかのシナリオでは、表のデータは、ＯＲＡＣＬＥを実行するすべて（又は大部分）のコンピュータ１０２が少なくとも２つのＨＢＡを有することを示すことがある。というのは、データベースが、冗長性及び性能上の理由で、一般に記憶装置への複数の経路を与えられるからである。このデータを解析することによって、アナライザソフトウェアは、｛ＨＯＳＴＥＤ  ＡＰＰＬＩＣＡＴＩＯＮ＝ＯＲＡＣＬＥ｝→｛ＮＵＭＢＥＲ  ＯＦ  ＨＢＡ（Ｓ）≧２｝というアソシエーションルールを推測する。その後、ルールジェネレータ２０８は、コンフィギュレーションデータを基に前述のアソシエーションルールを生成する。」
と説明した箇所があり、また、本件の手続でも、本件審判請求の理由の「４．本願発明が特許されるべき理由」欄、（１）、２）に、
「たとえば、段落[0030]、［0038］には、コンフィギュレーションデータを解析するアナライザソフトウェア２０６が、コンフィギュレーションデータを表わす表、すなわち、データの型や属性を示す列によりデータの意味が示される表１（段落[0030]）において、列の意味ではなく、列の値を基に、列の間の関係を推測することが記載されています。すなわち、表１において、「ホストとして働くアプリケーション」と「ＨＢＡの数」という列の間の関係を、列の意味ではなく“ＯＲＡＣＬＥ”、“２”というそれぞれの値に基づいて、“｛ＨＯＳＴＥＤ ＡＰＰＬＩＣＡＴＩＯＮ＝ＯＲＡＣＬＥ｝→｛ＮＵＭＢＥＲ ＯＦ ＨＢＡ（Ｓ）≧２｝”と推測することが記載されています。また、段落［0040］には、アナライザソフトウェア２０６が、コンフィギュレーションデータの表、すなわちセマンティクスを解析し、表の列（或いはコンフィギュレーション属性又は属性値の対）間の関係を、それらの値を基に推測することが記載されています。」
と述べた箇所がある。
　要するに、本件補正発明の「解析するステップ」、及び、その過程で抽出されることで「生成する」とされた「コンフィギュレーションルール」についてまとめると、
　収集されたデータが、名称データと数値データの対であるデータであり、収集されたデータを解析する手法は、ある数値データの属性に着目し、同一数値を示すデータ群中の名称データあるいは数値データ内で、強い相関を示す関係にある属性の有無を調べ、関係性の存在が発見された場合には、数値属性と意味ある名称属性あるいは他の数値属性同士を、→で結ぶルールを、コンフィギュレーションルールとして扱う
とする一連の手順を、本件補正発明の「解析するステップ」及び「生成するステップ」が、具体的な内容として含むことになる。
　これに対し、「データマイニング手法の一つである決定木アルゴリズムを採用して、特徴的な前記性能情報に基づいて、前記構成情報とのＩＦ−ＴＨＥＮ規則が成立する構成情報を分類する」とした先の発明の特定事項は、その内容として、上記Ｂ及びＤに摘記されたとおり、同時接続数が４２以下、かつ、ディスク使用率が５．５０％以下、かつ、メモリ使用量が２００MByte以下とされる特徴的な複数の性能数値情報である構成条件と、管理者が設定した目標を満足する関係を示す他の属性であるプロセッサ使用率のクラスとの関係を、決定木という名称の、ＩＦ−ＴＨＥＮ規則として分類し、生成するものであるとされているから、先の発明の「性能数値情報」と「構成情報」との間で成立する「ＩＦ−ＴＨＥＮ規則」の「分類」及び「ＩＦ−ＴＨＥＮ規則の生成」は、本件補正発明の「ある数値データの属性に着目し、同一数値を示すデータ群中の名称データあるいは数値データ内で、強い相関を示す関係にある属性の有無を調べ」ること、及び「関係性の存在が発見された場合には、数値属性と意味ある名称属性あるいは他の数値属性同士を、→で結ぶルールを、コンフィギュレーションルールとして」ルールの生成とすることと、実質的になんら相違しないことになると認められる。
　してみると、相違点２は、内容を叙述する形式的な用語がわずかに異なって見えるだけであり、実質的にはなんら相違するものではない。
　そして、本件補正発明の奏する作用効果は、上述した「前記コンフィギュレーションデータ中の関係を推測するために、」とされた目的どおりの効果になり、上記先の発明が実行する処理が実質同一である以上、作用効果上異なるものとはならない。
（２−５−３）小括
　したがって、本件補正発明は、上記先の発明と実質的に同一であり、出願人が同一でもなく、発明者が同一でもないので、特許法第２９条の２の規定により、特許出願の際独立して特許を受けることができない。
　また、本件補正発明は、方法の発明であり、この方法を実施する装置とされた本件補正後の請求項１０に係る発明も、同様の理由により特許法第２９条の２の規定によって、特許出願の際独立して特許を受けることができない。
（２−５−４）審判請求書による請求人の主張等
　なお、審判請求人は、本件審判請求の理由において、
「４．本願発明が特許されるべき理由
（１）理由３：　法第３６条第６項第２号の拒絶理由について
　１）拒絶理由通知書において、「請求項１に係る発明は、『前記コンフィギュレーションデータのセマンティクスとは無関係に前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する』と、否定的表現により特定されているため、具体的にどのようにして複数の属性間の関係を推測するのかが不明である」と指摘されました。
　上記手続補正により、請求項１において「前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する」と肯定的な限定も加わりましたので、上記指摘事項は解消したものと思料いたします。　
　２）拒絶理由通知書において、「請求項１に記載の『コンフィギュレーションデータのセマンティクス』が具体的にどのようなものを意味するのか不明確である」と指摘されました。
　本願の補正後の請求項１では、上述したように、「前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する」ことを規定しました。このことにより、まず、コンフィギュレーションデータの「セマンティクス」がコンフィギュレーションデータの「値」とは異なることが明確化されました。また、一方で、「当該コンフィギュレーションデータを特徴づけるセマンティクス」と規定することにより、「セマンティクス」が、コンフィギュレーションデータの値ではないコンフィギュレーションデータを特徴づける“意味”であることが明確化されました。すなわち、「コンフィギュレーションデータのセマンティクス」が、コンフィギュレーションデータの値ではない、コンフィギュレーションデータの意味であることが明確化されました。
　なお、「セマンティクス」がコンフィギュレーションデータの意味であることは、明細書の段落[0030]、［0038］、［0040］等の記載を参酌することでも明らかです。たとえば、段落[0030]、［0038］には、コンフィギュレーションデータを解析するアナライザソフトウェア２０６が、コンフィギュレーションデータを表わす表、すなわち、データの型や属性を示す列によりデータの意味が示される表１（段落[0030]）において、列の意味ではなく、列の値を基に、列の間の関係を推測することが記載されています。すなわち、表１において、「ホストとして働くアプリケーション」と「ＨＢＡの数」という列の間の関係を、列の意味ではなく“ＯＲＡＣＬＥ”、“２”というそれぞれの値に基づいて、“｛ＨＯＳＴＥＤ ＡＰＰＬＩＣＡＴＩＯＮ＝ＯＲＡＣＬＥ｝→｛ＮＵＭＢＥＲ ＯＦ ＨＢＡ（Ｓ）≧２｝”と推測することが記載されています。また、段落［0040］には、アナライザソフトウェア２０６が、コンフィギュレーションデータの表、すなわちセマンティクスを解析し、表の列（或いはコンフィギュレーション属性又は属性値の対）間の関係を、それらの値を基に推測することが記載されています。
　さらに、出願時の技術常識として、たとえば、「コンピュータソフトウェア辞典、渡瀬健他編、丸善、１９９０年４月１５日発行、第３２４頁、４３５頁、４３８頁等」や「電気工学ハンドブック、社団法人電気学会、２００１年２月２０日、１４４４頁」には、「セマンティクス」がプログラミング言語の意味または意味論であることや、セマンティクス・アナライイザ（またはアナリシス）が、変数や関数のデータ型の整合性をプログラミング言語の意味規則に従って解析を行う「意味解析」であることなどが記載されています。
　このように、「コンフィギュレーションデータのセマンティクス」との記載について「セマンティクス」が「コンフィギュレーションデータ」を特徴づける“意味”であることが明確化されましたので、上記指摘事項は解消したものと思料いたします。
　３）拒絶理由通知書における、請求項１及び１２についての「『当該コンフィギュレーションを』との記載があるが、この記載よりも前に『コンフィギュレーション』の記載が無く、『当該コンフィギュレーション』が何を指し示しているのかが不明確である」との指摘は、「当該コンフィギュレーションデータ」と規定する上記手続補正により解消したものと思料いたします。
（２）理由４：　法第２９条の２の拒絶理由について
　引用例１（特願2007-546323号（国際公開第2007/060721号））には、決定木生成に関する例として同時接続ユーザ数に基づく枝の分割が記載されており、拒絶理由通知書では、本願発明の「複数の属性間の関係を推測」することに対応付けられています。
　しかしながら、仮に、同時接続ユーザ数をコンフィギュレーションデータの属性に対応付けたとしても、引用例１では、それぞれの属性がとりうる値を枝として場合分けしているのであって、「複数の属性間の関係」を「コンフィギュレーションデータの値に基づいて」推測するものではありません。
　このことは、たとえば段落００３７に、規則生成部３０２が、サーバＩＤごと、サーバＩＤとＯＳの組み合わせごと、サーバ名とＯＳの組み合わせごと、または、ＣＰＵの名前、周波数、数量およびメモリサイズの組み合わせごとなどの所定の構成情報ごとに、性能情報３２４に対して離散値化の処理を行い、構成情報３２０、すなわち「セマンティクス」を用いて、決定木を生成することが記載されていることからも、明らかです。
　また、段落００３７には、規則生成部３０２は、管理者が設定する所定の構成条件に応じてデータを集約して、クラスが規則の結論部になるように学習を行い、決定木を生成することが記載されています。すなわち、所定の構成条件は「複数の属性間の関係を推測」するのに先立って設定されるので、かかる所与の設定に従って決定木を生成することは、「複数の属性間の関係」を「コンフィギュレーションデータの値」に基づいて「推測」するものとは本質的に異なります。
　さらに、引用例１におけるＩＦ-ＴＨＥＮ規則を表す決定木について言及すると、段落００４２には、規則生成部３０２が、所定の構成条件に対し管理者が設定する目標属性およびクラスに応じて１つ以上の決定木を生成することが記載されており、ＩＦ−ＴＨＥＮ規則を表す決定木が所与の設定、すなわちセマンティクスに従って決定されることが記載されています。このことは、本願発明における「複数の属性間の関係」を「コンフィギュレーションデータのセマンティクスとは無関係に」「コンフィギュレーションデータの値」に基づいて「推測」することとは異なります。
　よって、引用例１には、「前記コンフィギュレーションデータのセマンティクスとは無関係に前記コンフィギュレーションデータの値に基づいて前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析する」ことは開示されていません。
　このように、本願の請求項１−１７に係る発明は引用例１には記載されていませんので、本願は、法第２９条の２の拒絶理由には該当しないものと思料いたします。」
　と主張している。
　しかしながら、法第３６条第６項第２号に関する主張（１）及び、法第２９条の２に関する主張（２）で請求人が示す論点については、上記（２−２）及び（２−５）において検討したとおり、その記載が明確であるとは言えず、かつ、先の出願に記載された発明と実質的な相違を形成するものではない。よって、上記審判請求書の主張は理由がなく、採用することができない。
（３）補正却下むすび
　上記で検討した通り、本件補正後の請求項１及び１０に係る発明は、本件補正後の請求項１、１０の記載が特許法第３６条第６項第２号の規定の要件を満たしておらず、加えて、特許法第２９条の２の規定により特許を受けることができないものであり、これら複数の理由により特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記結論のとおり決定する。
第３．本願発明について
１．平成２６年１月１０日付けの手続補正は前記のとおり却下されたので、本願の請求項１に係る発明は、平成２５年３月２６日付けの手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。（以下、「本願発明」という。）
「　データセンタの複数の計算エンティティ向けコンフィギュレーションデータであって、
複数の属性と当該コンフィギュレーションを特徴づけるセマンティクスとを有するコンフィギュレーションデータを、受け取るステップと、
　前記コンフィギュレーションデータ中の関係を推測するために、プロセッサを有する計算システムが前記コンフィギュレーションデータのセマンティクスとは無関係に前記複数の属性間の関係を推測して前記コンフィギュレーションデータを解析するステップと、
　前記関係に基づいてコンフィギュレーションルールを生成するステップと
を含む方法。」
２．先の出願の記載事項及びその発明
　本願の最先の優先日前に出願され、本願の出願後に国際公開がされた特願２００７−５４６３２３号には、前記「第２」の「２．」の（２−３）の項で摘記した事項が記載されている。
３．対比・判断
　本願発明は、前記「第２」の「２．」の（２−２）で検討した、本件補正発明における発明特定事項である「当該コンフィギュレーションデータを特徴づけるセマンティクス」に関して、「当該コンフィギュレーションデータ」が「当該コンフィギュレーション」へ戻った点、及び、「解析するステップ」に関する「前記コンフィギュレーションデータの値に基づいて」との限定を省いたものである。
　そこで、前記２点の変更を各々検討する。
　前記「第２」の「２．」の（２−２）で示したとおり、「当該コンフィギュレーションを特徴づけるセマンティクス」に対して、セマンティクスを“意味”とした同様の読み替えを施した場合であっても、本願発明に記載された「特徴づける」関係とは如何なる内容を指すのかは、依然として明らかとなるものではないので、本願の特許請求の範囲の請求項１の記載は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　加えて、当該請求項１の「・・・前記コンフィギュレーションデータを解析するステップ」に関して、当該解析を行うために如何なる規則／ルールを採用したのかについての特定はなく、単に「前記コンフィギュレーションデータのセマンティクスとは無関係に前記複数の属性間の関係を推測して」とする、否定的表現の記載とされている点についても、原審で拒絶の査定の理由とされたとおり、当該ステップを不明りょうとする記載と認められるので、同じく特許法第３６条第６項第２号に規定する要件を満たしていない。
　また、「解析するステップ」に関する「前記コンフィギュレーションデータの値に基づいて」との限定を省いた点についても、当該限定を付した本件補正発明が、前記「第２」の「２．」の（２−５）に記載したとおり、先の発明と実質同一であって特許法第２９条の２の規定により独立して特許を受けることができないとされた以上、本願発明も、同様の理由により、特許とすることができないと言うべきである。
第４．むすび
　以上のとおりであるから、本願の特許請求の範囲の請求項１の記載は、特許法第３６条第６項第２号に規定する要件を満たしておらず、及び、本願発明は同法第２９条の２の規定により特許を受けることができないものであるから、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。