【事件の表示】
　平成　６年特許願第２９３５６５号「シスプレックスおよびデータを報告する方法」拒絶査定に対する審判事件〔平成　７年　９月１２日出願公開、特開平　７−２３９７９３、請求項の数（５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成６年１１月２８日（パリ条約による優先権主張１９９４年２月２２日、ドイツ国）の出願であって、その請求項１ないし５に係る発明は、平成９年１２月２６日付け手続補正によって補正された特許請求の範囲の請求項１ないし５に記載された事項により特定される次のとおりのものである。
「【請求項１】接続手段（410）を通して接続された複数のオペレーティング・システム・イメージ（20）を持ち、シスプレックス（10）からの動作中のデータを報告するために第１の上記オペレーティング・システム・イメージ（20）上で稼働する一のレポータ機構（160）を持つシスプレックス（10）であって、
　各上記オペレーティング・システム・イメージ（20）内に、報告可能なデータを含むデータ・グループ（40、60）を持ち、
　上記第１のオペレーティング・システム・イメージ（20）における第１のデータ・サーバ（170）と、
　報告可能なデータを含む上記データ・グループ（40、60）を持ち且つ上記第１のオペレーティング・システム・イメージ（20）とは異なる上記オペレーティング・システム・イメージ（20）における第２のデータ・サーバ（170）と、
を有し、
　上記第２のデータ・サーバ（170）が、上記第１のデータ・サーバ（170）から上記報告可能なデータを収集するための一の要求を受け取ると、上記異なるオペレーティング・システム・イメージ（20）における上記データ・グループ（40、60）から上記報告可能なデータを収集し、上記接続手段（410）を通して上記第１のデータ・サーバ（170）へ上記報告可能なデータを渡し、上記第１のデータ・サーバ（170）が上記報告可能なデータを上記レポータ機構（160）に渡す、上記シスプレックス。
【請求項２】各上記オペレーティング・システム・イメージ（20）が２つの上記データ・グループ（40、60）を有し、
　上記要求が、上記データ・グループ（40、60）のどちらに上記報告可能なデータがあるかを指示する、
　請求項１に記載のシスプレックス（10）。
【請求項３】上記第１のデータ・サーバ（170）によって生成され、上記報告可能なデータが記憶される応答領域（800、1000）を有する、請求項１または２に記載のシスプレックス（10）。
【請求項４】上記レポータ機構（160）を含む上記シスプレックス（10）内の資源を監視するための監視機構を有し、
　上記データ・グループ（40、60）が、上記シスプレックス（10）内の資源の使用およびロードに関するデータを含む、
　請求項１乃至３のいずれか１項に記載のシスプレックス（10）。
【請求項５】複数のオペレーティング・システム・イメージを持つシスプレックスにおけるデータを報告する方法であって、
　第１のオペレーティング・システム・イメージから、どのオペレーティング・システム・イメージ内に報告可能なデータが存在するかを示す検索基準を持つ一の要求を送る、第１のステップ（1120）と、
　上記検索基準と、上記要求を受け取った各オペレーティング・システム・イメージ内の上記報告可能なデータを突き合わせる、第２のステップ（1130）と、
　上記報告可能なデータがその内部に存在するオペレーティング・システム・イメージの一のイメージ・リストを、上記第１のオペレーティング・システム・イメージに返す、第３のステップ（1140）と、
　上記イメージ・リスト内にリストされたオペレーティング・システム・イメージに、当該オペレーティング・システム・イメージ内の上記報告可能なデータを収集するための一の要求を送る、第４のステップ（1220）と、
　上記リストされたオペレーティング・システム・イメージから上記第１のオペレーティング・システム・イメージに上記報告可能なデータを返す、第５のステップ（1240）と、
　上記報告可能なデータを、上記第１のオペレーティング・システム・イメージ内の応答領域に記憶する、第６のステップ（1260）と、
　を含む上記方法。」
　なお、平成１０年６月３日付け手続補正は、同日付けで却下された。
２．原審の拒絶の理由１について
（１）引用例の記載
　本願の請求項１ないし４に係る発明に対し、原審の拒絶の理由１に引用された特開平６−１２２８８号公報（以下「引用例１」という。）、特開平３−１３１１５７号公報（以下「引用例２」という。）、ＩＥＥＥ　ＴＲＡＮＳＡＣＴＩＯＮＳ　ＯＮ　ＳＯＦＴＷＡＲＥ　ＥＮＧＩＮＥＥＲＩＮＧ、Ｖｏｌ．１５、Ｎｏ．１２（１９８９）、ｐ．１６１５〜１６２９（以下「引用例３」という。）、特開平３−２５５６０号公報（以下、「引用例４」という。）、特開平３−１７６７５５号公報（以下「引用例５」という。）、特開平３−２５７６３９号公報（以下、「引用例６」という）、特開昭６２−２４３７７号公報（以下「引用例７」という。）、特開昭５９−２０８６６１号公報（以下「引用例８」という。）、前置報告書に引用された特開平５−３３４１３７号公報（以下「引用例９」という。）には以下の事項が記載されている。
（引用例１）
『【００３１】図１に示す情報処理システムは、オンライン業務を行う複数の処理装置４−１，４−２と、前記処理装置の監視を行う監視装置２と、前記処理装置と前記監視装置を接続する通信手段３（例えばＦＤＤＩ）と、前記監視装置が収集した監視結果を表示する表示装置１（例えばＣＲＴディスプレイ装置）により構成される。
【００３２】処理装置４−１，４−２内の構成は同一であり、よって説明は処理装置４−１について行う。また、処理装置の重要項目送信手段と、自己監視結果送信手段は図１上ではそれぞれ複数存在するが、これらについては、後述する「６．複数の監視装置による監視方法」の項で説明を行うこととし、本項ではそれぞれ一つずつしかないものとして説明する。説明には重要項目送信手段６−１−１、及び自己監視結果送信手段７−１−１を用いる。
【００３３】処理装置４−１は、通常の処理装置としての構成のほかに、処理装置４−１自身の状態を監視し得られた監視情報を送信手段に渡す自己監視手段５−１と、監視情報のうち見逃してはならない重要なもののみを送信する重要項目送信手段６−１−１と、重要な監視情報も含めた全ての監視情報を送信する自己監視結果送信手段７−１−１の３種の構成要素を持つ。ここでいう監視情報とは、計算機等の処理装置の処理状態，障害メッセージ，ジョブ状態，ネットワーク（回線）状態などのシステム状態を表わす情報をいう。さらに、重要な監視情報とは、ＯＳ障害やハード障害を知らせるメッセージのように、それを見逃すことによりシステム全体、又はシステムの機能の一部が停止する可能性がある情報である。監視情報が重要か否かの判定は自己監視手段５−１が行い、判定の結果重要な監視情報であれば、重要項目送信手段と自己監視結果送信手段の両方に渡し、重要でない監視情報であれば自己監視結果送信手段のみに渡す。各送信手段は自己監視手段より渡された監視情報を監視装置２に対して送信する。送信方法については「４．監視情報の通信方式」の項にて詳細に示す。
【００３４】監視装置２は、処理装置４−１，４−２の重要項目送信手段６−１−１，６−２−１より送信された監視情報を受信する重要項目受信収集手段１３と、前記処理装置の自己監視結果送信手段７−１−１，７−２−１より送信された監視情報を受信する監視対象別監視結果受信手段１４−１，１４−２と、前記重要項目受信収集手段により収集した監視情報を表示装置１へ出力して表示する重要項目表示手段１２と、前記監視対象別監視結果受信手段により受信した監視情報を表示装置１に表示するために出力する監視対象別監視結果表示手段１５−１，１５−２の４種類の構成要素を持つ。この時、処理装置４−１の重要項目送信手段６−１−１から送信された監視情報と、処理装置４−２の重要項目送信手段６−２−１から送信された監視情報は、いずれも監視装置２の重要項目受信収集手段１３により受信され、重要項目表示手段１２により表示装置１上の重要項目表示Window１７に表示されるように出力される。また、処理装置４−１の自己監視結果送信手段７−１−１より送信された監視情報は監視装置２の監視対象別監視結果受信手段１４−１により受信され、監視対象別監視結果表示手段１５−１によって監視結果表示Window（処理装置１）１８−１に表示され、処理装置４−２の自己監視結果送信手段７−２−１より送信された監視情報は監視装置２の監視対象別監視結果受信手段１４−２により受信され、監視対象別監視結果表示手段１５−２によって監視結果表示Window（処理装置２）１８−２に表示される。前記監視対象別監視結果受信手段及び監視対象別監視結果表示手段及び監視結果表示Windowは監視対象となる処理装置の数と同数作成される。このように、監視対象毎に独立して受信手段，表示手段，表示Windowを持つことにより、監視装置がこれらの要素を一つしか持たない場合のように一つの処理装置からの大量な監視情報の受信表示のために前記３手段が占有されて、他の処理装置からの監視情報の受信遅れや受信漏れが発生することを防止できる。』
（引用例２）
「各プロセッサにおいて収集される生起情報の生起情報記憶域への書き込みの際に、各プロセッサの識別情報登録域１０ｉの識別情報対応の一方の生起情報記憶域へ為される。・・・その後に、生起情報が書き込まれた生起情報記憶域からの読み出しは、該生起情報が書き込まれた生起情報記憶域でない他方の生起情報記憶域から前記書き込みが行なわれている間に、行なわれる。該他方の生起情報記憶域についての当該プロセッサによる認識は、前記反転された識別情報登録域１０ｉの識別情報を反転した識別情報によって為される。」（第４頁左上欄第１７行〜右上欄第１５行）
（引用例３）
　クリティカルパス解析の例として、Fig.2.に、３つのプロセスからなる分散プログラムの実行履歴が示され、プロセスレベルでのプログラム履歴が図示され、またクリティカルパス（太線）がパフォーマンス上最良の効果のプログラムのパスを示し、さらにテーブルIIに、Total CPU time 、Total waiting time、等のパフォーマンス・メトリクスが記載されている。
（引用例４）
「複数のコンピュータが接続されているネットワークの稼働状況をこれらのコンピュータが把握する方法において、
　ネットワークに接続される複数のコンピュータと、前記ネットワークに接続されこのネットワークを管理するネットワーク管理サーバとを設け、このネットワーク管理サーバは定期的に前記複数のコンピュータにブロードキャストモードで前回の稼動情報を配送すると共に現在の各コンピュータの稼動状況を問合わせ、各コンピュータから送信された稼動状況からネットワークの稼動情報を編集して保持するようにしたことを特徴とするネットワークの稼働状況管理方法。」（特許請求の範囲）
（引用例５）
「被管理計算機１３の通信制御部１４は、管理計算機１の通信制御部５からの送信要求情報を受信すると、要求情報受信制御部１５に対して送信要求情報を受信したことを通知する。要求情報受信制御部１５は送信要求情報の受信を受け取ると、通信制御部１４から管理計算機１より送られてきた送信要求情報を受け取り、送信要求された内容を資源情報送信制御部１６へ伝達する。」（第３頁左下欄第２０行〜右下欄第７行）
（引用例６）
「システム状態取得手段１１・２１・３１は、それぞれの計算機の障害メッセージ・ジョブ状態・回線状態などのシステム状態を取得する。システム状態通知手段１２・２２は取得したシステム状態を、ローカル計算機の状態に変化が発生した時、通知を行う。」（第２頁右上欄第６行〜第１１行）
（引用例７）
「１台又は複数台の情報収集プロセッサと、該情報収集プロセッサと接続される情報収集指示装置で構成されるデータ通信ネットワークの制御情報収集システムにおいて、複数個の収集対象データを有する情報収集プロセッサ内に複数個の収集対象データに関しカテゴリを鍵とした収集対象データを収集するための管理情報を蓄積する管理情報蓄積部を、また情報収集指示装置内に、情報収集指示タスクを設け、情報収集指示装置内で発生する情報収集要求に対して情報収集指示タスクから１つの情報収集プロセッサへ１個又は複数個の要求情報のカテゴリを指定する情報を含めた情報収集信号を送信し、情報収集プロセッサから情報収集指示装置へ情報収集要求信号で指定されたすべてのカテゴリの収集データを含む情報収集応答信号を返送することを特徴とするデータ通信ネットワークの情報収集方式。」（特許請求の範囲）
「第２図は情報要求信号１１に付加する要求情報のカテゴリを指示するフォーマット例を示したものである。・・・収集対象データに対応するビットが“１”の場合のみ収集する。」（第２頁右上欄第１１行〜第１７行）
（引用例８）
「マルチプログラミング機能を有する計算機システムにおいて、中央処理装置より演算が実行中であることを示す信号とその演算を行なうプログラムが格納されている主記憶装置におけるアドレスを示す信号を受信し、予め指定されたアドレス内の区分毎に各処理について実行時間を処理ステップ毎に計測し、中央処理装置の負荷率をＯＳプログラムとアプリケーションプログラムに分類して測定することを特徴とする計算機の負荷測定方法。」（特許請求の範囲）
（引用例９）
「【００１６】その後、上位計算機１の端末装置１５から負荷測定指示プログラム１６に対して、時報・定刻報・日報・週報・月報のいずれかの表示を指定して下位計算機２のシステム負荷測定データの出力を行うように要求する。」
（２）対比・判断
　本願の請求項１〜４に係る発明と、上記引用例１〜９に記載された発明とを対比すると、これらの引用例に記載された発明は、本願の請求項１〜４に係る発明を特定する事項である「各上記オペレーティング・システム・イメージ（20）内に、報告可能なデータを含むデータ・グループ（40、60）を持ち、
　上記第１のオペレーティング・システム・イメージ（20）における第１のデータ・サーバ（170）と、
　報告可能なデータを含む上記データ・グループ（40、60）を持ち且つ上記第１のオペレーティング・システム・イメージ（20）とは異なる上記オペレーティング・システム・イメージ（20）における第２のデータ・サーバ（170）と、
を有し、
　上記第２のデータ・サーバ（170）が、上記第１のデータ・サーバ（170）から上記報告可能なデータを収集するための一の要求を受け取ると、上記異なるオペレーティング・システム・イメージ（20）における上記データ・グループ（40、60）から上記報告可能なデータを収集し、上記接続手段（410）を通して上記第１のデータ・サーバ（170）へ上記報告可能なデータを渡し、上記第１のデータ・サーバ（170）が上記報告可能なデータを上記レポータ機構（160）に渡す」ことは備えておらず、また、これを示唆する記載も認められない。
　そして、本願の請求項１〜４に係る発明は、上記事項を備えることにより、「連続的なデータ通信量が避けられ、シスプレックス上の負荷、特にオペレーティング・システム・イメージ間の接続上の負荷が少ない時に、データを要求することができ、オペレーティング・システム・イメージ間の接続をより効率的に利用することができる」（段落【００１６】）という効果を奏するものである。
（３）むすび
　したがって、本願の請求項１ないし４に係る発明は、上記各引用例に記載された発明に基いて、当業者が容易に発明をすることができたものと認めることはできない。
３．原審の拒絶の理由２について
（１）拒絶の理由２
　拒絶の理由２は次のとおりである。
『この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第５項及び第６項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　（１）請求項５の「検索基準を持つ要求を送る」、「検索基準と、・・突き合わせる」、「報告可能な・・・イメージ・リストを返す」、「リストされた・・・イメージに・・・収集する要求を送る」という記載が、発明の詳細な説明（特に実施例）の具体的にどの構成に対応しているのか対応関係が不明である（図１９、図２０とその説明文を参照すると、報告して貰いたいデータの種別を示した要求をアプリケーション１６０が各ホスト１７０へ送り、各ホスト１７０は指定された種別のデータを収集してアプリケーション１６０へ報告していることは読み取れるものの、上で指摘した請求項５内の個々の記載に厳密に対応する記載が図１９、図２０やその説明文中には見受けられない）。』
　原査定の備考欄には次のとおり記載されている。
『（ａ）明細書第１０６コラムには、「検索基準」という語があるが、これがどのようなものであるのか具体的な説明は無く、したがって、請求項５の「検索基準」の技術的な裏付けとなる事項と、発明の詳細な説明中の開示事項との関係が不明である。意見書では、「「検索基準」を実効的に指定」、「実効的に含まれる「検索基準」」という説明があるが、この説明の意味するところが不明である（「実効的」とは、何か？）。
　（ｂ）第１９図、第２０図は、それぞれ別個のサービスの処理手順であり、第１９図の処理手順と第２０図の処理手順を途中から組み合わせる手法は、発明の詳細な説明では開示されていない（第１９図のステップ１１４０でデータが返ってきた時点で、第２０図のステップ１２２０の要求送信を行うというような手法は説明されていないし自明でもない）が、請求項５では第１９図の処理手順に対応する第１〜第３のステップと、第２０図の処理手順に対応する第４〜第６のステップが混在して記載されており、請求項５に記載されている第１〜第６のステップ全体に対応する手法は発明の詳細な説明に記載されておらず、請求項５と発明の詳細な説明との対応関係が不明である。また、意見書では、「これまでに得られた情報を処理して、どのオペレーティング・システム・イメージ内に報告可能なデータが存在するかを特定することができるので、「第４のステップ（1220）」では・・・できます」と説明しているが、この説明は、発明の詳細な説明の記載と矛盾している（何故ならば、第１のステップ（ステップ１１２０）を行う時点で、すでにオペレーティング・システム・イメージは特定されている（ステップ１１２０で使用するパラメータの説明（第６４コラム）参照）からである）。
　したがって、拒絶の「理由２」も、依然として解消されていない。』
（２）当審の判断
　段落【０１０５】には、「アプリケーション・プログラム１６０はまた、収集するデータの形式を指定しなければならない。これは、上記のREQUEST＿TYPE、START＿TIME、END＿TIMEおよびSMF＿RECORD＿TYPE＿INFOパラメータによって与えられる。」ことが記載され、上記「REQUEST＿TYPE」は段落【００５９】に、上記「START＿TIME」は段落【００６０】に、上記「END＿TIME」は段落【００６１】に、上記「SMF＿RECORD＿TYPE＿INFO」は段落【００６２】に、それぞれ説明されている。
　段落【０１０６】には、「ステップ1120において、・・・指定されたオペレーティング・システム・イメージ20上で実行しているシスプレックス・データ・サーバ170に、データに対する要求を送る。」と記載され、そのデータには上記パラメータも含まれ、これらのパラメータを基に収集するデータの検索を行い、「検索基準との一致が見つかったオペレーティング・システム・イメージ20において、シスプレックス・データ・サーバ170は、開始シスプレックス・データ・サーバ170に、SMFデータ・レコード310からSMFレコード・ヘッダ652および要求される場合RMF生成セクション655を返す（ステップ1140）。」ことになるから、これらのパラメータを総称して「検索基準」といっていると認められる。
　図１９に関する説明に続けて、段落【０１０９】には、「アプリケーション・プログラム160はここで、生成された応答領域に記憶された情報を処理することができる。情報の典型的な使用は、各オペレーティング・システム・イメージ20上の各データ・バッファ40からSMFレコード・データを要求することである。この目的のために、シスプレックス・データ・サーバ170は、ERBDSREC GUPIを提供するERBDSRECサービスを備える。アプリケーション・プログラム160によるこのサービスの呼出しを、図２０を参照して記述する。」と記載されている。この「生成された応答領域」は、図１９のステップ1110 で生成された応答領域であり、この「記憶された情報」は、図１９のステップ1160で記憶された情報であり、この情報を処理することを図２０において説明している。
　そうすると、図１９と図２０は上記のように関連しており、それぞれ別個のサービスの処理手順ということはできない。
（３）むすび
　したがって、本願は、特許法第３６条第５項及び第６項に規定する要件を満たしていないとすることはできない。
４．むすび
　以上のとおりであるから、本願発明は、特許法第２９条第２項の規定に該当し、又は、本願は、同法第３６条第５項及び第６項に規定する要件を満たしていないとした原審の判断は妥当でない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。