【事件の表示】
　特許第２７１５９０４号「計算機システム性能評価装置」の請求項１に係る特許に対する特許異議の申立てについて、次のとおり決定する。
【結　論】
　訂正を認める。
　特許第２７１５９０４号の請求項１に係る特許を維持する。
【理　由】
１．手続の経緯
　本件特許第２７１５９０４号の請求項１に係る発明についての出願は、平成６年４月２１日に特許出願され、平成９年１１月７日にその発明について特許権の設定登録がなされ、その後、その特許について、異議申立人金子和弘、根津仁より特許異議の申立てがなされ、取消の理由が通知され、その指定期間内である平成１１年２月２４日に訂正請求がなされたものである。
　
２．訂正の適否
　ア．訂正の内容
　特許請求の範囲に記載される「時系列データから複数プロセス間の依存関係を検出するプロセスの依存関係検出手段」を、「時系列データから、実行状態のプロセスが休止状態となる原因となるものあるいは休止状態のプロセスが実行可能状態となる原因となるものを求めることにより、複数プロセス間の依存関係を検出するプロセスの依存関係検出手段」に訂正する。
　イ．訂正の目的の適否、新規事項の有無、及び、拡張・変更の存否
　上記訂正事項に関連して、願書に添付した明細書（以下、「特許明細書」という。）の発明の詳細な説明には「プロセスの依存関係検出手段２０１では、測定データ記憶装置１０２に蓄えられているデータからプロセスの依存関係を検出し、依存関係のあるプロセスを一まとめの処理としてまとめる。本発明では、プロセスの依存関係として、実行状態のプロセスが休止状態となる原因となるもの、もしくは、休止状態のプロセスが実行可能状態ととなるものを用いる。」と記載されている。
　上記訂正は、依存関係検出手段を限定したものであるから特許請求の範囲の減縮に該当するものであり、また、依存関係検出手段を明確化するとともに、発明の詳細な説明に記載される効果との関係を明確にしたものであるから、不明瞭な記載の釈明に該当する。また、特許明細書に記載された事項の範囲内においてなされたものであるから新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。
　ウ．独立特許要件の存否
　訂正後の請求項１に係る発明（以下、「本件発明」という）は、次のとおりのものである。
「計算機システムの稼働状況をプロセスごとに時系列データとして測定する測定装置と、
　前記時系列データを用いて、プロセスを実行するのに使用するコンピュータ資源の種類を検出し、その使用時間の分布・平均値・分散をプロセスごとに算出するデータ処理手段と、
　前記データ処理手段で算出されたデータを保存するデータ格納装置と、
　時系列データから、実行状態のプロセスが休止状態となる原因となるものあるいは休止状態のプロセスが実行可能状態となる原因となるものを求めることにより、複数プロセス間の依存関係を検出するプロセスの依存関係検出手段と、
　プロセスごとの使用資源の種類・使用時間の分布・平均値・分散からなるデータを、前記プロセス間の依存関係を用いて簡約する簡約手段と、
　前記簡約手段からの処理ごとのデータをもとに、測定時とは負荷やシステム構成を変えた仮想的なシステム状態である予測条件を指定する手段と、
　前記処理毎のデータと前記予測条件をもとに性能予測を行う計算機システム性能予測演算手段と、
　を備えることを特徴とする計算機システム性能評価装置。」
　一方、取消理由に引用した刊行物１（Peter L. Haigh著「An Event Tracing Method for UNIX Performance Measurement」、CMG' 90 Proceedings. 1990 p.603-609）には、計算機システムでのプロセス毎の実行状態（稼働状況）をモニタした時系列データを用いて該システムの性能評価を行うものが記載されている。その要約（ｐ．６０３）によれば、「イベント（事象）追跡の方法は、カーネルでつくられたイベント告知、受動的なデータ記録とデータの簡約ソフトウェアを組み合わせることで示される。その方法は、各アプリケーションプロセス、システムコール及びデバイスドライブの実行時間を正確に測定するだけでなく、完全なシステム事象の時間順配列を与える。そこで生成された情報は、開発者のプログラムロジックの検証、全システムの実行時間の決定、プログラムロジックの検証、及びプログラムの欠陥の追跡において非常に貴重なものである。」ことが記載されており、そのＵＮＩＸイベントモニタ要求仕様（ｐ．６０４左欄）には、「２）システム内で発生するプロセスと関数、さらにそれらの相互依存関係（inter-relationships）（例えばどのプロセスがどの関数をコールしているか）を同定する」と記載されている。また、データ解析（ｐ．６０７左欄）に関して、「イベントを追跡し、要求される統計データを生成するために、イベント追跡プログラム（ＥＴ）は、各イベントを再構成しなければならない。さらに、イベント追跡プログラムは、プロセス、システムコール及び割り込みの分岐の時系列情報（ネスティングのヒストリ）を保持しなければならない。イベント追跡プログラム（ＥＴ）は、実際にはシステムのシミュレーションを実行しなければならない。」と記載されており、まとめ（ｐ．６０８右欄）においては、
「イベントモニタ技術は以下のタイプの測定に適用できる
−　アプリケーション、システムコール、ドライバー、割り込みによるＣＰＵ時間の蓄積
−　ＣＰＵのidle/busy
−　応答時間：ある２つのイベント間の時間
−　イベントの数えあげ：プロセス、システムコール、ドライバ／割り込みの利用数
−　ソフトウェアの検証：どんなイベントがどういう順で発生しているか
−　問題の解析。イベントトレースは、正確に、どんなプロセス、システムコール、割り込みの発生と、それらが発生する順番と、各々のアクティビティによる総消費時間と、各々のイベントの正確な時間を示すことができる、問題の原因を探す場合、イベントモニタが見るべき場所を示すことができる。」と記載されている。
　同じく刊行物２（特開平５−３２４３５８号公報）には、計算機システムから該計算機システムの稼働情報を採取し、その稼働情報に基づいて業務量変動時の平均レスポンスを求める第１の処理手段と、その算出された平均レスポンスと性能予測のために与えられたハードウェア構成による単位時間の処理能力の情報とに基づき業務量変動時及びハードウェア構成変更時の性能を予測する第２の処理手段とを備えた性能予測装置が記載されている。
　同じく刊行物３（特開昭６１−２７１５４６号公報）には、オンライン計算機システムの各タスク走行時間実績を測定し、かつあらかじめ決められたジョブごとのタスク相関により計算機負荷の寄与分をジョブ単位に分析する計算機負荷分析方法であって、分析に際しては、タスク相関検出部では該当タスクが起動したかいなかを検出することにより、ジョブを構成する一連のタスクが走行完了したかの判断がなされることが記載されている。
　同じく刊行物４（ＩＩＭ ＲＥＰＯＲＴ Ｎｏ．２４「コンピュータ・キャパシタ管理と数学（その３）」）には、システム・オーバヘッドの解析法が記載されている。
　本件発明と各刊行物に記載された発明とを対比すると、本件発明の「時系列データから、実行状態のプロセスが休止状態となる原因となるものあるいは休止状態のプロセスが実行可能状態となる原因となるものを求めることにより、複数プロセス間の依存関係を検出するプロセスの依存関係検出手段と、プロセスごとの使用資源の種類・使用時間の分布・平均値・分散からなるデータを、前記プロセス間の依存関係を用いて簡約する簡約手段」を備える点についてはいずれの刊行物にも記載ないし示唆されていない。そして、本件発明は、この点により明細書記載の作用効果を奏するものである。したがって、本件発明は、刊行物１ないし４に記載された発明に基づいて当業者が容易に発明をすることができたものではない。
　エ．むすび
　上記を総合して判断すると、上記訂正は、特許法第１２０条の４第２項第１号乃至第３号に掲げる事項を目的とし、且つ同条第３項で準用する特許法第１２６条第２項乃至第４項の規定に適合するので、当該訂正を認める。
　
３．特許異議の申立てについて
　異議申立人金子和弘は、証拠として甲第１号証（上記刊行物１）を提出し、本件請求項１に係る発明は、特許法第２９条第１項第３号または第２９条第２項の規定に違反してされたものであるから取り消すべきであり、また、請求項１に係る発明の特許は、その明細書が特許法第３６条第４項及び第５項第２号の規定に適合していない出願に違反してされたものであるから取り消すべき旨を主張している。
　また、異議申立人根津仁は、甲第１号証（上記刊行物２）、甲第２号証（上記刊行物３）及び甲第３号証（上記刊行物４）を提出し、請求項１に係る発明の特許は、特許法第２９条第２項の規定に違反してされたものであるから特許を取り消すべき旨を主張している。
　しかし、上記２．ウ．で示したように、訂正後の本件発明は、刊行物１ないし４に記載された発明でもなく、またこれらの刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものではないので、本件発明の特許は、特許法第２９条第１項第３号又は同法第２９条第２項の規定に違反してなされたものではない。
　また、上記２．イ．で示したように明細書の記載は訂正により明確となったから、本件発明の特許が、その明細書が特許法第３６条第４項及び第５項第２号に規定する要件を満たしていない特許出願に対してなされたものであるとすることはできない。
　以上のとおりであるから、特許異議申立の理由及び証拠によっては、本件発明についての特許を取り消すことはできない．
　
　また、他に本件発明についての特許を取り消すべき理由を発見しない。
　
　よって、結論のとおり決定する。
【異議決定日】
平成１３年５月７日（２００１．５．７）
【訂正の要旨】
訂正の要旨
　特許請求の範囲の請求項１中の「時系列データから複数プロセス間の依存関係を検出するプロセスの依存関係検出手段」を、「時系列データから、
実行状態のプロセスが休止状態となる原因となるものあるいは休止状態のプロセスが実行可能状態となる原因となるものを求めることにより、
（５４）【発明の名称】
計算機システム性能評価装置
（５７）【特許請求の範囲】
　【請求項１】
　計算機システムの稼働状況をプロセスごとに時系列データとして測定する測定装置と、
　前記時系列データを用いて、プロセスを実行するのに使用するコンピュータ資源の種類を検出し、その使用時間の分布・平均値・分散をプロセスごとに算出するデータ処理手段と、
　前記データ処理手段で算出されたデータを保存するデータ格納装置と、
　時系列データから
、実行状態のプロセスが休止状態となる原因となるものあるいは休止状態のプロセスが実行可能状態となる原因となるものを求めることにより、
　プロセスごとの使用資源の種類・使用時間の分布・平均値・分散からなるデータを、前記プロセス間の依存関係を用いて簡約する簡約手段と、
　前記簡約手段からの処理ごとのデータをもとに、測定時とは負荷やシステム構成を変えた仮想的なシステム状態である予測条件を指定する手段と、
　前記処理毎のデータと前記予測条件をもとに性能予測を行う計算機システム性能予測演算手段と、
　を備えることを特徴とする計算機システム性能評価装置。
【発明の詳細な説明】
　【０００１】
　【産業上の利用分野】
　本発明は、計算機システムの性能評価装置に関する。
　【０００２】
　【従来の技術】
　従来の性能評価方式では、適当なサンプリング間隔で得られたシステム全体の稼働状況データや、一つのプロセスについての稼働状況をソフトウエア的に測定したデータを、性能評価のための基礎データとして用いていた。
　【０００３】
　例えば、マイク・ルーカイズ（Ｍｉｋｅ　Ｌｏｕｋｉｄｅｓ）著、砂原秀樹監訳「ＵＮＩＸシステムチューニング」（１９９１）で述べられているようにＵＮＩＸオペレーティングシステムでは、ｓａｒ，ｐｓ，ｖｍｓｔａｔなどが、システム全体の稼働状況を測定するために備えられているツールであり、ｔｉｍｅ，ｔｉｍｅｘ，ｐｒｏｆなどが一つのプロセスの稼働状況を測定するツールである。
　【０００４】
　なお、ここではＵＮＩＸオペレーティングシステムを例に従来技術を説明したので「プロセス」という用語を用いたが、本発明で用いるプロセスという言葉は、何らかのプログラミング言語で記述されたプログラムが、処理を実行するための主体という意味で用いており、他のオペレーティングシステムで用いられているタスクやジョブ等により示される概念と同じと考えて差し支えない。
　【０００５】
　【発明が解決しようとする課題】
　以上説明した従来技術において、サンプリングによる測定には、サンプリングの間隔がＣＰＵのクロック程度に細かくなければ、測定データの信頼性に欠けるという欠点がある。またソフトウエア的な測定には、測定時のオーバヘッドが無視できないといため、サンプリングによる測定と同様にデータの信頼性に欠けるという欠点がある。
　【０００６】
　さらに、一つのプロセスについての稼働状況測定手段では、複数のプロセスが相互に協調して一つの処理を行う様な場合に、関連する複数のプロセスの稼働状況を一挙に測定することはできない。そのため、複数のプロセスの稼働状況は、プロセスの数だけ繰り返して測定を行わなければならず、測定に手間がかかるという問題がある。
　【０００７】
　【課題を解決するための手段】
　第１の発明は、計算機システムの稼働状況をプロセスごとに時系列データとして測定する測定装置と、前記時系列データを用いて、プロセスを実行するのに使用するコンピュータ資源の種類を検出し、その使用時間の分布・平均値・分散をプロセスごとに算出するデータ処理手段と、前記データ処理手段で算出されたデータを保存するデータ格納装置と、前記データをもとに、測定時とは負荷やシステム構成を変えた仮想的なシステム状態である予測条件を指定する手段と、前記プロセス毎のデータと前記予測条件をもとに性能予測を行う計算機システム性能予測演算手段と、からなることを特徴とする。
　【０００８】
　第２の発明は、第１の発明に加え、時系列データから複数プロセス間の依存関係を検出するプロセスの依存関係検出手段と、プロセスごとの使用資源の種類・使用時間の分布・平均値・分散からなるデータを、前記プロセス間の依存関係を用いて簡約する簡約手段からなることを特徴とする。
　【０００９】
　【実施例】
　第１の発明の一実施例について図１を用いて説明する。
　【００１０】
　測定装置１０１では、計算機システムで動いているプロセスごとの時系列データを計測し、それを測定データ記憶装置１０２に蓄える。蓄えられたデータは、プロセスごとのデータ処理手段１０３で、処理を実行するのに使用するコンピュータ資源の種類と、使用時間の分布・平均値・分散を算出する。算出されたデータはプロセスごとのデータ格納装置１０４に蓄えられる。
　【００１１】
　予測条件指定手段１０５では、測定データを用いて、予測したい仮想的な計算機システムの使用状態を指定する。
　【００１２】
　計算機システム性能予測演算手段１０６は、入力データとしてプロセスごとの稼働状況データ、もしくは処理ごとの稼働状況データを使用し、待ち行列理論や通信トラヒック理論に基づいた厳密解を用いた解法、もしくは数値的な解法、もしくはシミュレーションなどの手段により予測を行い、結果を出力手段１０７に出力する。
　【００１３】
　以下、第１の発明について更に詳細に説明する。
　【００１４】
　測定対象システムに、状態変化が起こるたびに信号を外部に出力するような手段を付加し、測定装置１０１が信号を検出し測定データ記憶装置１０２に記録する。このように測定対象システムの状態変化を外部に取り出す手法は、フィリップ・マッカロウ（Ｐｈｉｌｌｉｐ　ＭｃＫｅｒｒｏｗ）、「パフォーマンス・メジャメント・オブ・コンピュータ・システムズ（Ｐｅｒｆｏｒｍａｎｃｅ　Ｍｅａｓｕｒｅｍｅｎｔ　ｏｆ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍｓ）」（１９８７）にまとめられている。
　【００１５】
　測定データ記憶装置１０２に蓄えられているデータは、以下の情報を含む時系列データである。
１．プロセスの識別子
２．計算機システムを構成する資源の識別子
３．プロセスが使用している資源の識別子
４．プロセスの要求が待ち状態になっている資源の識別子
５．プロセス間の親子関係
６．プロセスの状態（資源を使用中か、待ち状態か、休止状態か）
７．プロセスの状態変化が起こった時の原因
プロセスごとのデータ処理手段１０３では、測定データ記憶装置１０２に蓄えられている時系列データを読み込み、各プロセスが使用する計算機資源を検出・分類し、各資源の使用時間・待ち時間に関して、分布・平均値・分散を算出する。また、システムを構成する資源数と、同時に動作するプロセスの数も算出する。
　【００１６】
　算出されたプロセスごとのデータはプロセスごとのデータ格納装置１０４に保存される。
　【００１７】
　予測条件指定手段１０５では、プロセスごとのデータ格納装置１０４に蓄えられているシステム稼働状況データをもとに、測定時とは負荷やシステム構成を変えた仮想的なシステムの状態を作り出す。
　【００１８】
　例えば、あるプロセスがどの資源をどの程度使用するかは、プロセスごとのデータ格納装置１０４に蓄えられているデータをみればわかる。そこで、資源使用時間の分布を変えずに平均値だけを変える、あるいは分布と平均値の両方を変えるというような、測定時の状況とは異なる使用条件を、この予測条件指定手段１０５で設定する。また、測定時に１台だったディスクを２台に増設した時のシステムの振る舞いを調べたい時には、システム構成資源の数とディスクの使用時間を変更して、測定対象システムとは異なるシステム構成を指定することもできる。
　【００１９】
　性能予測演算手段１０６は、前記プロセスごとのデータと予測条件をもとに性能予測を行う。この予測には、待ち行列・通信トラヒック理論による厳密解を用いた予測手段や、近似解を用いた予測手段や、シミュレーションによる予測手段などのいずれの手法を用いてもかまわない。これらの手法に関する具体的なことがらは、例えばステファン・レイベンバーグ（Ｓｔｅｐｈｅｎ　Ｓ．Ｌａｖｅｎｂｅｒｇ）、「コンピュータ・パフォーマンス・モデリング・ハンドブック（Ｃｏｍｐｕｔｅｒ　Ｐｅｒｆｏｒｍａｎｃｅ　Ｍｏｄｅｌｉｎｇ　Ｈａｎｄｂｏｏｋ）」（１９８３）にまとめられている。
　【００２０】
　性能予測演算手段１０６によって得られた結果は、出力手段１０７に出力される。
　【００２１】
　次に、第２の発明の一実施例について図２，図３を用いて説明する。
　【００２２】
　図２において、測定装置１０１と測定データ記憶装置１０２は、第１の発明と同様に、測定対象システムの状態を時系列データとして記録するための装置である。
　【００２３】
　プロセスの依存関係検出手段２０１では、プロセスごとの時系列データからプロセス間の依存関係を検出し、それをプロセスの依存関係格納装置２０２に蓄える。
　【００２４】
　データ簡約手段２０３では、プロセスの依存関係を用いて複数のプロセスを一つの処理としてまとめ、プロセスごとの稼働況データを利用して一つの処理に関する稼働状況データを算出する。このデータは処理ごとのデータ格納装置２０４に蓄えられる。
　【００２５】
　以下、第２の発明について更に詳細に説明する。
　【００２６】
　プロセスの依存関係検出手段２０１では、測定データ記憶装置１０２に蓄えられているデータからプロセスの依存関係を検出し、依存関係のあるプロセスを一まとめの処理としてまとめる。本発明では、プロセスの依存関係として、実行状態のプロセスが休止状態となる原因となるもの、もしくは、休止状態のプロセスが実行可能状態ととなるものを用いる。
　【００２７】
　複数のプロセスをひとまとめにする手続きのフローチャートを図３に示す。
　【００２８】
　このフローチャートの入力には、プロセスの識別子からなる集合Ｐが与えられる。プロセスの識別子として１からｎの数字を用いても一般性を失わないので、以下ではこれを用いて説明する。すると、Ｐ＝｛１，２，・・・　，ｎ｝と記述できる。ただし、ｎは、測定期間中にシステム内で動いたプロセスの数であり、フローチャート中では｜Ｐ｜と記述している。
　【００２９】
　フローチャートの説明は以下の通り。
　【００３０】
　まずプロセス番号を一つ定めて（これをｉと書く）、そのプロセスと依存関係のあるプロセス番号の集合（これをＰｉと書く）を算出する。この手続きが３０５，３０６，３０７，３０８，３０９，３１０である。３０６と３０７でプロセスｉとプロセスｊが依存関係があるかどうかを判断し、依存関係がある時には、Ｐ
ｉにｊを要素として加える。３０６，３０７，３０８の処理をｊがｉ＋１からｎまでの値の範囲で繰り返せば、プロセスｉと依存関係のあるプロセス番号からなる集合Ｐｉが得られる。
　【００３１】
　上記の手続きをｉが１からｎまでの値の範囲で単純に繰り返すだけでは、例えばプロセスｉとプロセスｊに依存関係がある場合に、ＰｉとＰｊが独立に算出されてしまう。
　【００３２】
　そこでｉの値を１からｎまで順番に増加させる時に、プロセス番号ｉが、既に算出されたＰｋ（ｋ＝１，２，・・・，ｉ−１）に含まれているかどうかを３０３で判断する。もしも含まれている場合には、以降の手続きではプロセスの集合としてＰｉではなく、その代わりとしてＰｋを用いれば良い。
　【００３３】
　この手段きにより、依存関係をなすプロセスをまとめた集合の集合｛Ｐｊ｝が得られる。以降では、この要素であるＰｊのことをひとまとめの処理と呼ぶ。
　【００３４】
　プロセスの依存関係検出手段２０１で得られた結果｛Ｐｊ｝は、プロセスの依存関係格納装置２０２に保存される。
　【００３５】
　データ簡約手段２０３では、プロセスごとのデータをプロセスのデータ格納装置１０４から読み込み、またプロセスの依存関係のデータをプロセスの依存関係格納装置２０２から読み込み、各ひとまとまりの処理が使用する計算機資源を検出・分類し、各資源の使用時間・待時間に関して、分布・平均値・分散を算出する。算出されたこれらのデータは処理ごとのデータ格納装置２０４に保存され、予測条件指定手段１０５で用いられる。
　【００３６】
　予測条件指定手段１０５では、プロセスごとのデータではなく、処理ごとのデータを扱うという点を除いて、実施例１で述べたことと同じ事を行う。つまり、負荷の程度やシステム構成を指定するということを行う。
　【００３７】
　以下、性能予測演算装置１０６と出力手段１０７の動作は、第１の発明と同じである。
　【００３８】
　【発明の効果】
　本発明では、システム性能予測を行うために必要なプロセスごとのデータが、精度良く簡単に測定できるので、このデータを用いて高精度の予測を行うことができる。
　【００３９】
　また、第１の発明においては、計算機システム内で複数のプロセスが協調して処理をするような場合に、予測に要する時間が長くなるという不都合があるが、第２の発明では、同時に動作するプロセスの数が増えた場合にも、プロセスの依存関係を検出してひとまとめの処理としてデータを簡約するために、短時間の計算で予測を行うことができる。
【図面の簡単な説明】
　【図１】第１の発明の一実施例を説明するための図である。
　【図２】第２の発明の一実施例を説明するための図である。
　【図３】図２のプロセスの依存関係検出手段２０１のアルゴリズムを示すフローチャートである。
　【符号の説明】
１０１　測定装置
１０２　測定データ記憶装置
１０３　プロセスごとのデータ処理手段
１０４　プロセスごとのデータ格納装置
１０５　予測条件指定手段
１０６　性能予測演算装置
１０７　出力装置
２０１　プロセスの依存関係検出手段
２０２　プロセスの依存関係格納装置
２０３　データ簡約手段
２０４　処理ごとのデータ格納装置