ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F 審判 査定不服 ５項１、２号及び６項 請求の範囲の記載不備 取り消して特許、登録 G06F |
|---|---|
| 管理番号 | 1059303 |
| 審判番号 | 審判1998-8604 |
| 総通号数 | 31 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 1995-09-12 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 1998-06-03 |
| 確定日 | 2002-06-24 |
| 事件の表示 | 平成 6年特許願第293565号「シスプレックスおよびデータを報告する方法」拒絶査定に対する審判事件〔平成 7年 9月12日出願公開、特開平 7-239793、請求項の数(5)〕について、次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
| 理由 |
1.手続きの経緯・本願発明 本願は、平成6年11月28日(パリ条約による優先権主張1994年2月22日、ドイツ国)の出願であって、その請求項1ないし5に係る発明は、平成9年12月26日付け手続補正によって補正された特許請求の範囲の請求項1ないし5に記載された事項により特定される次のとおりのものである。 「【請求項1】接続手段(410)を通して接続された複数のオペレーティング・システム・イメージ(20)を持ち、シスプレックス(10)からの動作中のデータを報告するために第1の上記オペレーティング・システム・イメージ(20)上で稼働する一のレポータ機構(160)を持つシスプレックス(10)であって、 各上記オペレーティング・システム・イメージ(20)内に、報告可能なデータを含むデータ・グループ(40、60)を持ち、 上記第1のオペレーティング・システム・イメージ(20)における第1のデータ・サーバ(170)と、 報告可能なデータを含む上記データ・グループ(40、60)を持ち且つ上記第1のオペレーティング・システム・イメージ(20)とは異なる上記オペレーティング・システム・イメージ(20)における第2のデータ・サーバ(170)と、 を有し、 上記第2のデータ・サーバ(170)が、上記第1のデータ・サーバ(170)から上記報告可能なデータを収集するための一の要求を受け取ると、上記異なるオペレーティング・システム・イメージ(20)における上記データ・グループ(40、60)から上記報告可能なデータを収集し、上記接続手段(410)を通して上記第1のデータ・サーバ(170)へ上記報告可能なデータを渡し、上記第1のデータ・サーバ(170)が上記報告可能なデータを上記レポータ機構(160)に渡す、上記シスプレックス。 【請求項2】各上記オペレーティング・システム・イメージ(20)が2つの上記データ・グループ(40、60)を有し、 上記要求が、上記データ・グループ(40、60)のどちらに上記報告可能なデータがあるかを指示する、 請求項1に記載のシスプレックス(10)。 【請求項3】上記第1のデータ・サーバ(170)によって生成され、上記報告可能なデータが記憶される応答領域(800、1000)を有する、請求項1または2に記載のシスプレックス(10)。 【請求項4】上記レポータ機構(160)を含む上記シスプレックス(10)内の資源を監視するための監視機構を有し、 上記データ・グループ(40、60)が、上記シスプレックス(10)内の資源の使用およびロードに関するデータを含む、 請求項1乃至3のいずれか1項に記載のシスプレックス(10)。 【請求項5】複数のオペレーティング・システム・イメージを持つシスプレックスにおけるデータを報告する方法であって、 第1のオペレーティング・システム・イメージから、どのオペレーティング・システム・イメージ内に報告可能なデータが存在するかを示す検索基準を持つ一の要求を送る、第1のステップ(1120)と、 上記検索基準と、上記要求を受け取った各オペレーティング・システム・イメージ内の上記報告可能なデータを突き合わせる、第2のステップ(1130)と、 上記報告可能なデータがその内部に存在するオペレーティング・システム・イメージの一のイメージ・リストを、上記第1のオペレーティング・システム・イメージに返す、第3のステップ(1140)と、 上記イメージ・リスト内にリストされたオペレーティング・システム・イメージに、当該オペレーティング・システム・イメージ内の上記報告可能なデータを収集するための一の要求を送る、第4のステップ(1220)と、 上記リストされたオペレーティング・システム・イメージから上記第1のオペレーティング・システム・イメージに上記報告可能なデータを返す、第5のステップ(1240)と、 上記報告可能なデータを、上記第1のオペレーティング・システム・イメージ内の応答領域に記憶する、第6のステップ(1260)と、 を含む上記方法。」 なお、平成10年6月3日付け手続補正は、同日付けで却下された。 2.原審の拒絶の理由1について (1)引用例の記載 本願の請求項1ないし4に係る発明に対し、原審の拒絶の理由1に引用された特開平6-12288号公報(以下「引用例1」という。)、特開平3-131157号公報(以下「引用例2」という。)、IEEE TRANSACTIONS ON SOFTWARE ENGINEERING、Vｏl.15、Nｏ.12(1989)、ｐ.1615〜1629(以下「引用例3」という。)、特開平3-25560号公報(以下、「引用例4」という。)、特開平3-176755号公報(以下「引用例5」という。)、特開平3-257639号公報(以下、「引用例6」という)、特開昭62-24377号公報(以下「引用例7」という。)、特開昭59-208661号公報(以下「引用例8」という。)、前置報告書に引用された特開平5-334137号公報(以下「引用例9」という。)には以下の事項が記載されている。 (引用例1) 『【0031】図1に示す情報処理システムは、オンライン業務を行う複数の処理装置4-1,4-2と、前記処理装置の監視を行う監視装置2と、前記処理装置と前記監視装置を接続する通信手段3(例えばFDDI)と、前記監視装置が収集した監視結果を表示する表示装置1(例えばCRTディスプレイ装置)により構成される。 【0032】処理装置4-1,4-2内の構成は同一であり、よって説明は処理装置4-1について行う。また、処理装置の重要項目送信手段と、自己監視結果送信手段は図1上ではそれぞれ複数存在するが、これらについては、後述する「6.複数の監視装置による監視方法」の項で説明を行うこととし、本項ではそれぞれ一つずつしかないものとして説明する。説明には重要項目送信手段6-1-1、及び自己監視結果送信手段7-1-1を用いる。 【0033】処理装置4-1は、通常の処理装置としての構成のほかに、処理装置4-1自身の状態を監視し得られた監視情報を送信手段に渡す自己監視手段5-1と、監視情報のうち見逃してはならない重要なもののみを送信する重要項目送信手段6-1-1と、重要な監視情報も含めた全ての監視情報を送信する自己監視結果送信手段7-1-1の3種の構成要素を持つ。ここでいう監視情報とは、計算機等の処理装置の処理状態,障害メッセージ,ジョブ状態,ネットワーク(回線)状態などのシステム状態を表わす情報をいう。さらに、重要な監視情報とは、OS障害やハード障害を知らせるメッセージのように、それを見逃すことによりシステム全体、又はシステムの機能の一部が停止する可能性がある情報である。監視情報が重要か否かの判定は自己監視手段5-1が行い、判定の結果重要な監視情報であれば、重要項目送信手段と自己監視結果送信手段の両方に渡し、重要でない監視情報であれば自己監視結果送信手段のみに渡す。各送信手段は自己監視手段より渡された監視情報を監視装置2に対して送信する。送信方法については「4.監視情報の通信方式」の項にて詳細に示す。 【0034】監視装置2は、処理装置4-1,4-2の重要項目送信手段6-1-1,6-2-1より送信された監視情報を受信する重要項目受信収集手段13と、前記処理装置の自己監視結果送信手段7-1-1,7-2-1より送信された監視情報を受信する監視対象別監視結果受信手段14-1,14-2と、前記重要項目受信収集手段により収集した監視情報を表示装置1へ出力して表示する重要項目表示手段12と、前記監視対象別監視結果受信手段により受信した監視情報を表示装置1に表示するために出力する監視対象別監視結果表示手段15-1,15-2の4種類の構成要素を持つ。この時、処理装置4-1の重要項目送信手段6-1-1から送信された監視情報と、処理装置4-2の重要項目送信手段6-2-1から送信された監視情報は、いずれも監視装置2の重要項目受信収集手段13により受信され、重要項目表示手段12により表示装置1上の重要項目表示Window17に表示されるように出力される。また、処理装置4-1の自己監視結果送信手段7-1-1より送信された監視情報は監視装置2の監視対象別監視結果受信手段14-1により受信され、監視対象別監視結果表示手段15-1によって監視結果表示Window(処理装置1)18-1に表示され、処理装置4-2の自己監視結果送信手段7-2-1より送信された監視情報は監視装置2の監視対象別監視結果受信手段14-2により受信され、監視対象別監視結果表示手段15-2によって監視結果表示Window(処理装置2)18-2に表示される。前記監視対象別監視結果受信手段及び監視対象別監視結果表示手段及び監視結果表示Windowは監視対象となる処理装置の数と同数作成される。このように、監視対象毎に独立して受信手段,表示手段,表示Windowを持つことにより、監視装置がこれらの要素を一つしか持たない場合のように一つの処理装置からの大量な監視情報の受信表示のために前記3手段が占有されて、他の処理装置からの監視情報の受信遅れや受信漏れが発生することを防止できる。』 (引用例2) 「各プロセッサにおいて収集される生起情報の生起情報記憶域への書き込みの際に、各プロセッサの識別情報登録域10iの識別情報対応の一方の生起情報記憶域へ為される。・・・その後に、生起情報が書き込まれた生起情報記憶域からの読み出しは、該生起情報が書き込まれた生起情報記憶域でない他方の生起情報記憶域から前記書き込みが行なわれている間に、行なわれる。該他方の生起情報記憶域についての当該プロセッサによる認識は、前記反転された識別情報登録域10iの識別情報を反転した識別情報によって為される。」(第4頁左上欄第17行〜右上欄第15行) (引用例3) クリティカルパス解析の例として、Fig.2.に、3つのプロセスからなる分散プログラムの実行履歴が示され、プロセスレベルでのプログラム履歴が図示され、またクリティカルパス(太線)がパフォーマンス上最良の効果のプログラムのパスを示し、さらにテーブルIIに、Total CPU time 、Total waiting time、等のパフォーマンス・メトリクスが記載されている。 (引用例4) 「複数のコンピュータが接続されているネットワークの稼働状況をこれらのコンピュータが把握する方法において、 ネットワークに接続される複数のコンピュータと、前記ネットワークに接続されこのネットワークを管理するネットワーク管理サーバとを設け、このネットワーク管理サーバは定期的に前記複数のコンピュータにブロードキャストモードで前回の稼動情報を配送すると共に現在の各コンピュータの稼動状況を問合わせ、各コンピュータから送信された稼動状況からネットワークの稼動情報を編集して保持するようにしたことを特徴とするネットワークの稼働状況管理方法。」(特許請求の範囲) (引用例5) 「被管理計算機13の通信制御部14は、管理計算機1の通信制御部5からの送信要求情報を受信すると、要求情報受信制御部15に対して送信要求情報を受信したことを通知する。要求情報受信制御部15は送信要求情報の受信を受け取ると、通信制御部14から管理計算機1より送られてきた送信要求情報を受け取り、送信要求された内容を資源情報送信制御部16へ伝達する。」(第3頁左下欄第20行〜右下欄第7行) (引用例6) 「システム状態取得手段11・21・31は、それぞれの計算機の障害メッセージ・ジョブ状態・回線状態などのシステム状態を取得する。システム状態通知手段12・22は取得したシステム状態を、ローカル計算機の状態に変化が発生した時、通知を行う。」(第2頁右上欄第6行〜第11行) (引用例7) 「1台又は複数台の情報収集プロセッサと、該情報収集プロセッサと接続される情報収集指示装置で構成されるデータ通信ネットワークの制御情報収集システムにおいて、複数個の収集対象データを有する情報収集プロセッサ内に複数個の収集対象データに関しカテゴリを鍵とした収集対象データを収集するための管理情報を蓄積する管理情報蓄積部を、また情報収集指示装置内に、情報収集指示タスクを設け、情報収集指示装置内で発生する情報収集要求に対して情報収集指示タスクから1つの情報収集プロセッサへ1個又は複数個の要求情報のカテゴリを指定する情報を含めた情報収集信号を送信し、情報収集プロセッサから情報収集指示装置へ情報収集要求信号で指定されたすべてのカテゴリの収集データを含む情報収集応答信号を返送することを特徴とするデータ通信ネットワークの情報収集方式。」(特許請求の範囲) 「第2図は情報要求信号11に付加する要求情報のカテゴリを指示するフォーマット例を示したものである。・・・収集対象データに対応するビットが“1”の場合のみ収集する。」(第2頁右上欄第11行〜第17行) (引用例8) 「マルチプログラミング機能を有する計算機システムにおいて、中央処理装置より演算が実行中であることを示す信号とその演算を行なうプログラムが格納されている主記憶装置におけるアドレスを示す信号を受信し、予め指定されたアドレス内の区分毎に各処理について実行時間を処理ステップ毎に計測し、中央処理装置の負荷率をOSプログラムとアプリケーションプログラムに分類して測定することを特徴とする計算機の負荷測定方法。」(特許請求の範囲) (引用例9) 「【0016】その後、上位計算機1の端末装置15から負荷測定指示プログラム16に対して、時報・定刻報・日報・週報・月報のいずれかの表示を指定して下位計算機2のシステム負荷測定データの出力を行うように要求する。」 (2)対比・判断 本願の請求項1〜4に係る発明と、上記引用例1〜9に記載された発明とを対比すると、これらの引用例に記載された発明は、本願の請求項1〜4に係る発明を特定する事項である「各上記オペレーティング・システム・イメージ(20)内に、報告可能なデータを含むデータ・グループ(40、60)を持ち、 上記第1のオペレーティング・システム・イメージ(20)における第1のデータ・サーバ(170)と、 報告可能なデータを含む上記データ・グループ(40、60)を持ち且つ上記第1のオペレーティング・システム・イメージ(20)とは異なる上記オペレーティング・システム・イメージ(20)における第2のデータ・サーバ(170)と、 を有し、 上記第2のデータ・サーバ(170)が、上記第1のデータ・サーバ(170)から上記報告可能なデータを収集するための一の要求を受け取ると、上記異なるオペレーティング・システム・イメージ(20)における上記データ・グループ(40、60)から上記報告可能なデータを収集し、上記接続手段(410)を通して上記第1のデータ・サーバ(170)へ上記報告可能なデータを渡し、上記第1のデータ・サーバ(170)が上記報告可能なデータを上記レポータ機構(160)に渡す」ことは備えておらず、また、これを示唆する記載も認められない。 そして、本願の請求項1〜4に係る発明は、上記事項を備えることにより、「連続的なデータ通信量が避けられ、シスプレックス上の負荷、特にオペレーティング・システム・イメージ間の接続上の負荷が少ない時に、データを要求することができ、オペレーティング・システム・イメージ間の接続をより効率的に利用することができる」(段落【0016】)という効果を奏するものである。 (3)むすび したがって、本願の請求項1ないし4に係る発明は、上記各引用例に記載された発明に基いて、当業者が容易に発明をすることができたものと認めることはできない。 3.原審の拒絶の理由2について (1)拒絶の理由2 拒絶の理由2は次のとおりである。 『この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第5項及び第6項に規定する要件を満たしていない。 記 (1)請求項5の「検索基準を持つ要求を送る」、「検索基準と、・・突き合わせる」、「報告可能な・・・イメージ・リストを返す」、「リストされた・・・イメージに・・・収集する要求を送る」という記載が、発明の詳細な説明(特に実施例)の具体的にどの構成に対応しているのか対応関係が不明である(図19、図20とその説明文を参照すると、報告して貰いたいデータの種別を示した要求をアプリケーション160が各ホスト170へ送り、各ホスト170は指定された種別のデータを収集してアプリケーション160へ報告していることは読み取れるものの、上で指摘した請求項5内の個々の記載に厳密に対応する記載が図19、図20やその説明文中には見受けられない)。』 原査定の備考欄には次のとおり記載されている。 『(a)明細書第106コラムには、「検索基準」という語があるが、これがどのようなものであるのか具体的な説明は無く、したがって、請求項5の「検索基準」の技術的な裏付けとなる事項と、発明の詳細な説明中の開示事項との関係が不明である。意見書では、「「検索基準」を実効的に指定」、「実効的に含まれる「検索基準」」という説明があるが、この説明の意味するところが不明である(「実効的」とは、何か?)。 (b)第19図、第20図は、それぞれ別個のサービスの処理手順であり、第19図の処理手順と第20図の処理手順を途中から組み合わせる手法は、発明の詳細な説明では開示されていない(第19図のステップ1140でデータが返ってきた時点で、第20図のステップ1220の要求送信を行うというような手法は説明されていないし自明でもない)が、請求項5では第19図の処理手順に対応する第1〜第3のステップと、第20図の処理手順に対応する第4〜第6のステップが混在して記載されており、請求項5に記載されている第1〜第6のステップ全体に対応する手法は発明の詳細な説明に記載されておらず、請求項5と発明の詳細な説明との対応関係が不明である。また、意見書では、「これまでに得られた情報を処理して、どのオペレーティング・システム・イメージ内に報告可能なデータが存在するかを特定することができるので、「第4のステップ(1220)」では・・・できます」と説明しているが、この説明は、発明の詳細な説明の記載と矛盾している(何故ならば、第1のステップ(ステップ1120)を行う時点で、すでにオペレーティング・システム・イメージは特定されている(ステップ1120で使用するパラメータの説明(第64コラム)参照)からである)。 したがって、拒絶の「理由2」も、依然として解消されていない。』 (2)当審の判断 段落【0105】には、「アプリケーション・プログラム160はまた、収集するデータの形式を指定しなければならない。これは、上記のREQUEST_TYPE、START_TIME、END_TIMEおよびSMF_RECORD_TYPE_INFOパラメータによって与えられる。」ことが記載され、上記「REQUEST_TYPE」は段落【0059】に、上記「START_TIME」は段落【0060】に、上記「END_TIME」は段落【0061】に、上記「SMF_RECORD_TYPE_INFO」は段落【0062】に、それぞれ説明されている。 段落【0106】には、「ステップ1120において、・・・指定されたオペレーティング・システム・イメージ20上で実行しているシスプレックス・データ・サーバ170に、データに対する要求を送る。」と記載され、そのデータには上記パラメータも含まれ、これらのパラメータを基に収集するデータの検索を行い、「検索基準との一致が見つかったオペレーティング・システム・イメージ20において、シスプレックス・データ・サーバ170は、開始シスプレックス・データ・サーバ170に、SMFデータ・レコード310からSMFレコード・ヘッダ652および要求される場合RMF生成セクション655を返す(ステップ1140)。」ことになるから、これらのパラメータを総称して「検索基準」といっていると認められる。 図19に関する説明に続けて、段落【0109】には、「アプリケーション・プログラム160はここで、生成された応答領域に記憶された情報を処理することができる。情報の典型的な使用は、各オペレーティング・システム・イメージ20上の各データ・バッファ40からSMFレコード・データを要求することである。この目的のために、シスプレックス・データ・サーバ170は、ERBDSREC GUPIを提供するERBDSRECサービスを備える。アプリケーション・プログラム160によるこのサービスの呼出しを、図20を参照して記述する。」と記載されている。この「生成された応答領域」は、図19のステップ1110 で生成された応答領域であり、この「記憶された情報」は、図19のステップ1160で記憶された情報であり、この情報を処理することを図20において説明している。 そうすると、図19と図20は上記のように関連しており、それぞれ別個のサービスの処理手順ということはできない。 (3)むすび したがって、本願は、特許法第36条第5項及び第6項に規定する要件を満たしていないとすることはできない。 4.むすび 以上のとおりであるから、本願発明は、特許法第29条第2項の規定に該当し、又は、本願は、同法第36条第5項及び第6項に規定する要件を満たしていないとした原審の判断は妥当でない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
| 審決日 | 2002-06-06 |
| 出願番号 | 特願平6-293565 |
| 審決分類 |
P
1
8・
534-
WY
(G06F)
P 1 8・ 121- WY (G06F) |
| 最終処分 | 成立 |
| 前審関与審査官 | 吉岡 浩、久保 光宏 |
| 特許庁審判長 |
馬場 清 |
| 特許庁審判官 |
吉見 信明 大橋 隆夫 |
| 発明の名称 | シスプレックスおよびデータを報告する方法 |
| 代理人 | 坂口 博 |
| 代理人 | 市位 嘉宏 |