【事件の表示】
　特願２００４−５１４８６７「トランザクション・パイプライン分解のための方法およびシステム」拒絶査定不服審判事件〔平成１５年１２月３１日国際公開、ＷＯ２００４／００１６０１、平成１７年１０月　６日国内公表、特表２００５−５３０２６０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１５年５月１３日（パリ条約による優先権主張２００２年６月２０日、米国）を国際出願日とする出願であって、出願後の手続きの経緯は次のとおりである。
拒絶理由通知　　　　　　平成２０年９月２５日
意見書、手続補正書　　　平成２０年１２月２５日
拒絶査定（起案）　　　　平成２１年２月１０日
拒絶査定（送達日）　　　平成２１年２月１７日
審判請求　　　　　　　　平成２１年５月１５日
　
２．本願請求項１に係る発明
　本願特許請求の範囲に記載された請求項１に係る発明は、平成２０年１２月２５日付け手続補正書により補正されたとおりの次の事項により特定されるものである。（以下「本願発明」という。）
　
「トランザクション・パイプラインを構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って１組のエージェントを提供するステップと、
前記１組のエージェント中の各エージェントを、前記分散データ処理システム内の１組のサーバ中のサーバと関連づけるステップであって、前記１組のサーバ中の各サーバが、前記１組のサーバ中の後続サーバに後続トランザクションを要求した後、要求されたトランザクションを完了するステップと、
トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップと
を含む方法。」
　
３．引用文献
　原審の拒絶の理由に引用された本願優先権主張日前に頒布された刊行物である特開２０００−３１５１９８号公報（以下「引用文献１」という。）には、図面とともに次の記載がある。　
Ａ．「【０００８】このように従来技術では各計算機、各オブジェクトのようにポイントの性能データは収集できるが、分散オブジェクトシステム全体を対象とした性能モニタリングはできないという問題点がある。
【０００９】本発明は、上記のような事情に鑑み為されたもので、その目的とするところは、分散処理システム全体を対象とした性能モニタリングを行う方法及びそのような分散処理システムを提供することにある。
【００１０】また性能のボトルネックを絞り込める分散処理システムの性能モニタリング方法を提供することを目的とする。」
Ｂ．「【００１１】
【課題を解決するための手段】本発明は、各計算機上に配置されるモニタリング手段によつて計測対象となるプログラム実体について他プログラム実体からのメッセージの受信時刻及び他プログラム実体へのメッセージの送信時刻の少なくとも一方を性能データとして収集し、各モニタリング手段によって収集された性能データを集約して処理フローを構成する各プログラム実体の処理時間及びプログラム実体間の通信時間を算出し、表示装置上に表示する分散処理システムの性能モニタリング方法を特徴とする。
…（中略）…
【００１４】（１）第１の実施形態
図１は、本実施形態の性能モニタリング方法を実現する計算機システムの構成図である。本計算機システムは、採取した性能に関するデータの処理と表示を行うプログラムであるマネージャ１３０を実行する計算機１０３と、性能モニタリングを行う対象であるオブジェクトを搭載する計算機１０１，１０２および計算機間を接続するＬＡＮ１４０から成る。本例ではモニタリングの対象となる計算機は２台であるが、その台数に制約はない。また各計算機はＬＡＮ１４０によって相互通信が可能であるが、通信を実現する手段もＬＡＮに限定されるわけではない。コレクタ１３１，１３２は、マネージャ１３０から指示を受け、必要に応じて性能データの採取、採取データのマネージャへの転送を行うプログラムである。１２１から１２６までは実際にモニタリングの対象となるプログラム実体であるオブジェクトである。マネージャはそれぞれのオブジェクトに対してオブジェクトＩＤと呼ばれる一意のＩＤを用いることによってこれを区別する。オブジェクトＩＤとして、例えば分散オブジェクト技術の標準の一つであるＣＯＲＢＡで用いられているオブジェクトリファレンスを用いる。
…（中略）…
【００１８】図２は、第１の実施形態のシステム全体の処理の概略手順を示す図である。この処理手順はマネージャ１３０の担当部分であるブロック２０１とコレクタ１３１，１３２の担当部分であるブロック２０２の２つのブロックから成る。
【００１９】まずマネージャ１３０が実行するブロック２０１について説明する。マネージャ１３０は最初にステップ２１０においてオブジェクトの一覧を表示し、性能データを採取するオブジェクトの選択入力を受け付ける。次にステップ２２０において、ステップ２１０で入力された性能データを採取するオブジェクトのオブジェクトＩＤを全てのコレクタ１３１，１３２にブロードキャストによつて通知する。マネージャ１３０はステップ２３０において、コレクタ１３１，１３２から転送されてくる性能データの到着を待つ。性能データを受信すると、ステップ２４０で各コレクタから送信される断片的な性能データの対応づけを行う。ここで対応づけとは、同一処理シーケンスに属する性能データをグループにまとめ、かつ時系列に従って配列することである。…（中略）…
【００２０】続いてコレクタ１３１，１３２が実行するブロック２０２について説明する。コレクタ１３１，１３２はステップ２７０において、マネージャ１３０によってブロードキャストされた少なくとも１つのオブジェクトＩＤからなるデータを受信する。コレクタ１３１，１３２は、そのコレクタが実行されている計算機１０１，１０２内に受信したオブジェクトＩＤと同じオブジェクトＩＤを持つオブジェクトがあれば、そのオブジェクトの監視を開始する。以下このオブジェクトを計測対象オブジェクトと呼ぶ。コレクタ１３１，１３２はステップ２８０で計測対象オブジェクトに処理が発生すると、性能に係わるデータを採取し、採取したデータをステップ２９０においてマネージャに送信する。…（中略）…
【００２１】図３は、計算機１０３の表示装置上に表示される計測対象オブジェクト選択画面３０１の例を示す図である。オブジェクト一覧ウィンドウ３０２上には性能データを取得する対象候補としてオブジェクトのＩＤが複数個表示され、その中から計測対象とする１個又は１個以上のオブジェクトを選択可能である。同時に複数のオブジェクトが選択される場合には、選択される複数のオブジェクトは通常オブジェクト間通信によつて関連づけられるオブジェクトのグループである。」　
Ｃ．「【００２３】図４は、コレクタ１３１，１３２が各々計算機１０１，１０２のメモリ上に作成する採取データリスト５０１のデータ構成を示す図である。採取データリスト５０１は、オブジェクトＩＤ５０２、受信側オブジェクトＩＤ５０３、受信側メッセージＩＤ５０４、受信時刻５０５、送信側オブジェクトＩＤ５０６、送信側メッセージＩＤ５０７および送信時刻５０８の各フィールドから成る。採取データリスト５０１は、計測対象オブジェクトが他のオブジェクトからメッセージを受信するか、他のオブジェクトにメッセージを送信するか、またはメッセージ受信に続いてメッセージ送信をするごとに１つ生成される。…（中略）…
【００２４】計測対象オブジェクトは、データ入力等のイベントが発生し、処理開始する時点でその計算機に設けられるコレクタへその計測対象オブジェクトのＩＤ及び処理開始時刻を通知する。また計測対象オブジェクトは、他のオブジェクトにメッセージを送信する時点でそのコレクタへその計測対象オブジェクトのＩＤ、相手オブジェクトのＩＤ、送信するメッセージＩＤ及びメッセージ送信時刻を通知する。また他のオブジェクトからメッセージを受信した時点でそのコレクタへ計測対象オブジェクトのＩＤ、相手オブジェクトのＩＤ、受信したメッセージＩＤ、メッセージ受信時刻、および引き続きメッセージ送信が発生するか否かを示すフラグを通知する。また一連の処理を終了する時点で計測対象オブジェクトのＩＤ及び処理終了時刻をコレクタに通知する。コレクタは、マネージャ１３０から計測対象オブジェクトの通知を受けた後、計測対象オブジェクトに指令を送付してオブジェクトの時刻などの通知を開始させる。
…（中略）…
【００２８】図６は、マネージャ１３０が計算機１０３のメモリ上に作成するリクエストフローテーブル７０１のデータ構成を示す図である。リクエストフローテーブル７０１は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ１３０に到着した採取データリスト５０１を処理が行われた順に従って時系列に配列されるようにソートしたものである。リクエストフローテーブル７０１の各行は採取データリスト５０１そのものであり、…（中略）…またある行の送信側オブジェクトＩＤ７０６に格納されるオブジェクトＩＤが次の行のオブジェクトＩＤ７０２であり、次の行の受信側オブジェクトＩＤ７０３に格納されるオブジェクトＩＤがある行のオブジェクトＩＤ７０２であり、送信側のメッセージＩＤと受信側のメッセージＩＤが一致する場合、同一トランザクションについての処理の流れの中で両方の計測対象オブジェクト間に通信が行われたことを示し、ある行の送信時刻７０８と次の行の受信時刻７０５との差が両オブジェクト間の通信時間である。リクエストフローテーブル７０１は一連の処理の流れごとに各々作成される。
…（中略）…
【００３０】図８は、リクエストフローテーブル７０１を作成し表示するマネージャ１３０の処理の流れを示すフローチャートである。マネージャ１３０はコレクタ１３１，１３２から採取データリスト５０１が到着するのを待つ（ステップ６１０）。採取データリスト５０１が到着すると（ステップ６１０Ｙｅｓ）、その受信側オブジェクトＩＤ５０３をチェックし、このＩＤが選択された計測対象オブジェクトのＩＤのいずれかと一致しているか否かを判定する（ステップ６２０）。一致していない場合（ステップ６２０Ｎｏ）、計算機１０３のメモリ上に新規にリクエストフローテーブル７０１の領域を確保し、到着した採取データリスト５０１をその先頭の要素とする（ステップ６３５）。なおこの完成していないリクエストフローテーブル７０１を以降、作成中リクエストフローテーブルと呼ぶ。作成中リクエストフローテーブルは、図８に示された処理が行われている間、複数作成され得る。
【００３１】一致している場合（ステップ６２０Ｙｅｓ）、作成中リクエストフローテーブルを探索し、その中にテーブルの最後尾を構成する採取データリストの送信側メッセージＩＤと、今取得した採取データリストの受信メッセージＩＤが一致しているテーブルがあるかどうかをチェックする（ステップ６４５）。チェックの結果、一致するものがあれば（ステップ６４５Ｙｅｓ）、当該作成中リクエストフローテーブルの最後尾に今取得した採取データリストを付加する（ステップ６４７）。また一致するものがなければ（ステップ６４５Ｎｏ）、採取データリストをメモリ上の一時保存領域である採取データリストバッファに保存し（ステップ６４９）、ステップ６１０に戻って新たな採取データリストの到着を待つ。
【００３２】ステップ６３５、ステップ６４７に続くステップ６５０において、作成中リクエストフローテーブルの最後尾に付加された採取データリストの送信側オブジェクトＩＤ７０６をチェックする（ステップ６５０）。これが選択された計測対象オブジェクトのＩＤでなければ（ステップ６５０Ｎｏ）、このリクエストフローテーブルはこれで完結するので、このリクエストフローテーブルの表示を行う（ステップ６５２）。表示後、あらかじめ設定された時間を超えていないかをチェックする（ステップ６５４）。超えていなければ（ステップ６５４Ｙｅｓ）、ステップ６１０に戻って新たな採取データリストの到着を待つ。超えていれば（ステップ６５４Ｎｏ）、マネージャ１３０の処理を終了する。
【００３３】ステップ６５０のチェックの結果、送信側オブジェクトが選択された計測対象オブジェクトのＩＤであった場合には（ステップ６５０Ｙｅｓ）、送信側メッセージＩＤ７０７と同じ受信側メッセージＩＤを持つ採取データリストを採取データリストバッファから探索する（ステップ６５５）。採取データリストが見つかれば（ステップ６５５有）、この採取データリストをステップ６３５又は６４７で対象とした作成中リクエストフローテーブルの最後尾に付加し、その後ステップ６５０に戻る。採取データリストがなければ（ステップ６５５無し）、ステップ６１０に戻り新たな採取データリストの到着を待つ。
【００３４】図８に示すマネージャ１３０の処理手順によれば、複数のトランザクションに属する採取データリスト５０１が混在してマネージャ１３０に到着したり、各オブジェクトの処理のシーケンスと採取データリスト５０１到着のシーケンスとが異なっても、各トランザクションごとにリクエストフローテーブル７０１が作成され、リクエストフローテーブル７０１を構成する採取データリストは処理のシーケンスに従って時系列に配列される。」
Ｄ．「【００３７】（２）第２の実施形態
第１の実施形態では、処理フローを取得したい場合に、ユーザはその処理フローに関与するすべてのオブジェクトを計測対象として指定しなければならないという面倒がある。第２の実施形態では、ユーザはオブジェクトを１つ指定することによってそのオブジェクトが行う処理から後の一連の処理について処理フローを得ることができる。この機能を実現するためにコレクタ１３１，１３２がリクエストフローテーブルを作成する。すなわちオブジェクト間を移動するメッセージにリクエストフローテーブルを付加し、各オブジェクトで処理が行われるごとにリクエストフローテーブルに採取データリストを追加する。以下に図１で示される分散オブジェクト環境について第２の実施形態の構成及び動作を説明する。
【００３８】図９は、第２の実施形態のシステム全体の処理の概略手順を示すフロー図である。この処理手順はマネージャ１３０の担当部分であるブロック９０１とコレクタ１３１，１３２の担当部分であるブロック９０２の２つのブロックから成る。
【００３９】まずマネージャ１３０が実行するブロック９０１について説明する。マネージャ１３０は最初にステップ９１０において処理フローの最初に処理を行うオブジェクトの選択入力を受け付ける。この入力方法は第１の実施形態で説明した方法と同じである。ただし指定するオブジェクトの数は１つに限定される。次にステップ９２０において、ステップ９１０で入力された性能データを採取するオブジェクトのオブジェクトＩＤを全てのコレクタ１３１，１３２にブロードキャストによつて通知する。マネージャ１３０はステップ９３０において、コレクタ１３１，１３２から転送されてくるデータの到着を待つ。…（中略）…マネージャ１３０が最初にコレクタ１３１，１３２より性能データを受け取ってからあらかじめ設定された一定時間、繰り返し行われる。
【００４０】続いてコレクタ１３１，１３２が実行するブロック９０２について説明する。コレクタ１３１，１３２はステップ９７０において、マネージャ１３０によってブロードキャストされたオブジェクトＩＤを受信する。コレクタ１３１，１３２は、そのコレクタが実行されている計算機１０１，１０２内で実行されているオブジェクトの監視を開始する。コレクタ１３１，１３２はステップ９８０でオブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、採取したデータによって処理フローデータを作成する。次にステップ９９０で作成した処理フローデータをマネージャに送信する。…（中略）…このようにステップ９８０および９９０の処理は、コレクタ１３１，１３２がマネージャ１３０からオブジェクトＩＤのデータを受け取ってからあらかじめ設定された一定時間、繰り返し行われる。
【００４１】図１０は、第２の実施形態で用いる採取データリスト１１０１のデータ構成を示す図である。採取データリスト１１０１はオブジェクトＩＤ１１１０、受信時刻１１２０及び送信時刻１１３０の各フィールドから構成される。オブジェクトＩＤ１１１０はユーザによって指定されたオブジェクト又は処理フローを構成するいずれかのオブジェクトのＩＤである。受信時刻１１２０はそのオブジェクトについて処理開始時刻又はメッセージ受信時刻である。送信時刻１１３０はそのオブジェクトについてメッセージ送信時刻又は処理終了時刻である。
【００４２】図１１は、第２の実施形態で用いるリクエストフローテーブル１２０１のデータ構成を示す図である。リクエストフローテーブル１２０１は採取データリスト１１０１を処理が行われた順に従って時系列に配列したテーブルである。リクエストフローテーブル１２０１は各処理フローについて１つ作成される。
…（中略）…
【００５２】以上説明した第２の実施形態によれば、ユーザはオブジェクトを１つ指定することによって、そのオブジェクトの処理から後の処理フローを得ることが可能となる。これにより例えばあるクライアントオブジェクトがどのサーバオブジェクトにアクセスするかわからなくても、そのクライアントオブジェクトを指定するだけでそのクライアントからの要求によって始まる一連の処理の処理フローを得ることが可能となる。また第１の実施形態のように特定のオブジェクトによって処理された処理フローを抽出することも可能である。」
　
（Ａ）Ｃ．の【００３４】段落には、複数のトランザクションに属する採取データリスト５０１が混在してマネージャ１３０に到着しても、ソートして各トランザクションごとにリクエストフローテーブル７０１が作成される旨記載されているから、この各トランザクションごとの複数の「リクエストフローテーブル」（リクエストフローテーブル７０１の内容にみられるようなメッセージの送受信）はトランザクションにあたる。
　また、Ｃ．には、マネージャが作成するリクエストフローテーブル（図６のリクエストフローテーブル）に関連して、リクエストフローテーブル７０１は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ１３０に到着した採取データリスト５０１を処理が行われた順に従って時系列に配列されるようにソートしたものであり、リクエストフローテーブル７０１は一連の処理の流れごとに各々作成される旨記載され、図６のリクエストフローテーブルは、これを図式化した図７の処理フローに示されたようにオブジェクトＩＤで示されたオブジェクト間で線形にオブジェクト間通信接続される様子が示されており、Ｄ．には、第２の実施形態が記載され、オブジェクト間を移動するメッセージにリクエストフローテーブルを付加して各オブジェクトで処理が行われるごとに採取データリストを追加して収集されるリクエストフローテーブルが記載され、この第２の実施形態リクエストフローテーブルは第１の実施形態とは採取の仕方やリクエストフローテーブルの構成（図１１参照）が異なるが、リクエストフローテーブルの内容は図７のように図式化でき、前記図６のリクエストフローテーブルと同様の線形の、複数のリクエストフローテーブルである。
　前記複数のトランザクション、前記線形に接続されたリクエストフローテーブル（トランザクション）、Ａ．に分散処理システム全体を対象とした性能モニタリング（性能監視）を行う方法、と記載されていることを合わせると、トランザクションの線形を構成する分散データ処理システムを監視する方法が認められる。
（Ｂ）Ａ．の「分散オブジェクトシステム全体を対象とした性能モニタリングを行う方法」、Ｂ．の「性能モニタリングを行う対象であるオブジェクトを搭載する計算機１０１，１０２」、各計算機上に配置されるモニタリング手段（各コレクタのこと）によつて計測対象となるプログラム実体について他のプログラム実体からのメッセージの受信時刻及び他プログラム実体へのメッセージ送信時刻の少なくとも一方を性能データとして収集する旨（図１を参照すると、オブジェクトを実行する各計算機にそれぞれコレクタが配置されている）の記載と、コレクタ１３１、１３２は、マネージャから指示を受け必要に応じて性能データの採取を行う（【００１４】参照）ことから、コレクタ１３１、１３２の集合は分散オブジェクトシステム全体を対象とした性能データの採取を行う１組のコレクタと解される。これらから、分散データ処理システム全体に渡って１組のコレクタ１３１、１３２が提供されていることが認められる。
（Ｃ）Ｂ．の「性能モニタリングを行う対象であるオブジェクトを搭載する計算機１０１，１０２」「各計算機上に配置されるモニタリング手段」（図１参照）からすると、各オブジェクトを搭載する計算機と各計算機の各コレクタとが配置において関連しており、１組のコレクタ中の各コレクタを、前記分散データ処理システム（図１）内の１組の計算機中の計算機と関連づけるステップがよみとれる。さらに、各計算機に搭載されたオブジェクト（各オブジェクトを搭載する計算機も意味は同様）とコレクタに関して、「マネージャ１３０は最初にステップ２１０においてオブジェクトの一覧を表示し、性能データを採取するオブジェクトの選択入力を受け付ける。次にステップ２２０において、ステップ２１０で入力された性能データを採取するオブジェクトのオブジェクトＩＤを全てのコレクタ１３１，１３２にブロードキャストによつて通知する。」「コレクタ１３１，１３２はステップ２７０において、マネージャ１３０によってブロードキャストされた少なくとも１つのオブジェクトＩＤからなるデータを受信する。コレクタ１３１，１３２は、そのコレクタが実行されている計算機１０１，１０２内に受信したオブジェクトＩＤと同じオブジェクトＩＤを持つオブジェクトがあれば、そのオブジェクトの監視を開始する。以下このオブジェクトを計測対象オブジェクトと呼ぶ。コレクタ１３１，１３２はステップ２８０で計測対象オブジェクトに処理が発生すると、性能に係わるデータを採取し、採取したデータをステップ２９０においてマネージャに送信する。」と記載され、同様に、Ｄ．【００４０】に、コレクタ１３１，１３２は、マネージャ１３０によってブロードキャストされたオブジェクト（計測対象オブジェクト）ＩＤを受信し、コレクタ１３１，１３２は、そのコレクタが実行されている計算機１０１，１０２内で実行されているオブジェクトの監視を開始し、コレクタ１３１，１３２はオブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、採取したデータによって処理フローデータを作成し、次に作成した処理フローデータをマネージャに送信する旨記載されていることから、各計算機に搭載されたオブジェクトと各計算機上に配置されたコレクタと関連づけるステップであって、各コレクタは計測対象オブジェクトに対して監視するよう関連づけられる。
　そして、Ｂ．【００２０】Ｃ．【００２３】【００２４】段落には、コレクタ１３１，１３２は当該コレクタ１３１，１３２が実行されている計算機１０１，１０２（計算機の組）内で実行されているオブジェクトを監視し、オブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、計測対象オブジェクトのＩＤ及び処理終了時刻をコレクタに通知し（図５ステップ４６５処理終了時刻入力を参照）、Ｃ．【００３４】段落と図８の、マネージャにより時系列に配列された各トランザクションごとのリクエストフローテーブル７０１の作成における手順における、ステップ６５０で、「リクエストフローテーブルはこれで完結する」（【００３２】段落）と記載されており、コレクタで収集された監視データが前記完結であるものが含まれる。これらをふまえると、前記１組の計算機中の各計算機が、リクエストフローテーブル（リクエスト；要求）に対応する処理を終了ないし完結しており、少なくとも、要求されたトランザクションを完結、終了するステップがよみとれる。
（Ｄ）前記のように、Ｃ．【００２４】段落には、計測対象オブジェクトは、データ入力等のイベントが発生し、処理開始する時点でその計算機に設けられるコレクタへその計測対象オブジェクトのＩＤ及び処理開始時刻を通知し、…（中略）…また、一連の処理を終了する時点で計測対象オブジェクトのＩＤ及び処理終了時刻をコレクタに通知する旨記載されており、前記一連の処理とリクエストフロー（トランザクション）とが対応しており、コレクタがトランザクションについての開始時刻と処理終了時刻を収集することが示され、【００３２】段落には選択された計測対象オブジェクトのＩＤでなければ当該リクエストフローテーブルは完結する旨記載されている。前記マネージャにより時系列に配列された各トランザクションごとのリクエストフローテーブルの内容はコレクタで収集された内容と等価な内容を含む点、リクエストフローテーブルには受信側オブジェクト、受信側メッセージ、送信側オブジェクト、送信側メッセージを有し（図６参照）、通信の方向を有していてトランザクションが向けられるにあたる事項がよみとれる点をふまえると、トランザクション（リクエストフロー）を開始し、前記トランザクションについての完了情報（終了時刻、完結判断のための計測対象オブジェクトでないＩＤ）を取得するように、前記１組のコレクタ中の各コレクタを構成するステップであって、前記コレクタが関連づけられる前記オブジェクトが搭載された計算機によってトランザクションが向けられるに相当する事項が示されている。
　
（Ａ）〜（Ｄ）をふまえると、引用文献１には、分散処理システム全体を対象とした性能モニタリングを行うことができ、性能のボトルネックを絞り込める分散処理システムの性能モニタリング方法を提供することを目的とした次の発明（以下「引用文献１発明」という。）が示されている。
　
　トランザクションの線形を構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って１組のコレクタ（１３１，１３２）を提供するステップと、
前記１組のコレクタ中の各コレクタを、前記分散データ処理システム内の１組の計算機中の計算機と関連づけるステップであって、オブジェクトを搭載する計算機で実行される計測対象オブジェクトは、マネージャからコレクタに通知され、各コレクタは、そのコレクタが実行されている計算機内の計測対象オブジェクトを監視し、処理開始する時点でその計算機に設けられるコレクタへ計測対象オブジェクトのＩＤ及び処理開始時刻、一連の処理を終了する時点で計測対象オブジェクトのＩＤ及び処理終了時刻を通知し、前記１組の計算機中の各計算機が、要求されたトランザクションを完結ないし終了するステップと、
トランザクションを開始し、前記トランザクションについての完結情報ないし終了情報を取得するように、前記１組のコレクタ中の各コレクタを構成するステップであって、前記コレクタが関連づけられる前記オブジェクトを搭載する計算機によってトランザクションが向けられる、ステップと
を含む方法。
　
［対比］
ア．引用文献１発明の「トランザクションの線形の組を構成する分散データ処理システムを監視する方法」は、トランザクション・パイプラインを構成するとまではいえないまでも、トランザクションを構成しており、一方、本願発明の「トランザクション・パイプラインを構成する」も、トランザクションを構成するから、両発明は「トランザクションを構成する分散データ処理システムを監視する方法」である点で共通する。
イ．引用文献１発明の「分散データ処理システム全体に渡って１組のコレクタを提供するステップ」における、当該コレクタはエージェントとは記載されていないがモニタリングの対象となるオブジェクトとは別の性能データの収集等を行うプログラム（引用文献の【００１４】段落参照）であり、一方、本願発明の「エージェント」は、その【００２３】段落に、エージェントとは、別のエンティティに代わって情報を集めまたはタスクを実施するソフトウェア・プログラムまたはそれに類似するエンティティのことであると記載されているから、オブジェクトに代わって情報を採取する「コレクタ」と「エージェント」とに技術的に格別な差異はない。したがって、引用文献１発明の前記ステップと本願発明の「前記分散データ処理システム全体に渡って１組のエージェントを提供するステップ」と実質的な差異はない。しかも、後記するようにエージェント自体は周知技術である。
ウ．引用文献１発明の「前記１組のコレクタ中の各コレクタを、前記分散データ処理システム内の１組の計算機中の計算機と関連づけるステップであって、オブジェクトを搭載する計算機で実行される計測対象オブジェクトは、マネージャからコレクタに通知され、各コレクタは、そのコレクタが実行されている計算機内の計測対象オブジェクトを監視し、処理開始する時点でその計算機に設けられるコレクタへ計測対象オブジェクトのＩＤ及び処理開始時刻、一連の処理を終了する時点で計測対象オブジェクトのＩＤ及び処理終了時刻を通知し、前記１組の計算機中の各計算機が、要求されたトランザクションを完結ないし終了するステップ」は、「１組の計算機中の後続計算機に後続トランザクションを要求した後、」を有しない点で本願発明と相違し、引用文献１発明の「計算機」はそれぞれ「サーバ」とまではいえないまでもネットワークに接続された計算機装置であり、一方、本願発明のサーバも、計算機装置（【０００９】段落参照）と記載されていることから、いずれも計算機装置である点で共通する。
　これらをふまえると、両発明は「前記１組のエージェント（コレクタ）中の各エージェントを、前記分散データ処理システム内の１組の計算機装置中の計算機装置と関連づけるステップであって、前記１組の計算機装置中の各計算機装置が、要求されたトランザクションを完了するステップ」で共通する。
エ．引用文献１発明の「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップ」と本願発明の「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップ」とは、「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって前記トランザクションが向けられる、ステップ」で共通する。
　以上の点を総合すると、本願発明と引用文献１発明とは、次の点で一致し、そして、次の点で相違する。
〈一致点〉
トランザクションの線形の接続を構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って１組のエージェントを提供するステップと、
前記１組のエージェント中の各エージェントを、前記分散データ処理システム内の１組の計算機装置中の計算機装置と関連づけるステップであって、前記１組の計算機装置中の各計算機装置が、要求されたトランザクションを完了するステップと、
トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップと
を含む方法。
　
〈相違点１〉トランザクションを構成するのが、本願発明は「トランザクション・パイプライン」を構成するのに対し、引用文献１発明は「トランザクションの線形の接続」を構成している点。
〈相違点２〉分散データ処理システム内の１組の計算機装置中のそれぞれの計算機装置が、本願発明は「サーバ」であるのに対し、引用文献１発明は「計算機」である点。
〈相違点３〉１組の計算機装置中の各計算機装置について、要求されたトランザクションを完了するステップが、本願発明が「１組のサーバ中の各サーバが、前記１組のサーバ中の後続サーバに後続トランザクションを要求した後、」完了するのに対し、引用文献１発明はこの点が不明である点。
〈相違点４〉トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップが、本願発明は「後続トランザクションが要求される前記後続サーバ、に対して」前記トランザクションが向けられる、のに対して、引用文献１発明は、この点が不明である点。
　
［当審判断］
〈相違点１〉について
　本願発明における「トランザクション・パイプライン」は、本願発明の詳細な説明【００１８】段落に記載される如く、その流れがほぼ線形であるトランザクションの流れを意味すると解される。マネージャも複数のトランザクションを対象としている。
　してみると、引用文献１発明におけるトランザクションも該「トランザクション・パイプライン」を構成していると解することができ、前記相違点は単なる表現の相違にすぎないもので実質的な相違点といえるものではない。
〈相違点２〉について
　Ｄ．の【００５２】段落には、クライアントオブジェクトがどのサーバオブジェクトにアクセスするのかわからなくても、クライアントからの要求によって始まる一連の処理の処理フローを得ることが可能になる旨記載され、Ｅ．には、複数の計算機上で多数のオブジェクトが動作する場合に、どのオブジェクトがどのオブジェクトと関連をもって動作するかとか、どの処理フローにトランザクションが集中するかなど把握が困難であり、前記処理フローの態様がある旨記載されている。これらをふまえると、引用文献１発明の、計算機のオブジェクトがサーバのオブジェクトである場合が示唆されている。また、分散処理システム内の複数の計算機に関し、計算機がサーバであるものは周知である。例えば、特開２００１−２０２３０３号公報図１には、ネットワークサービスを行う複数のサーバ１０１、１０２が示され、特開２００２−４１３７６号公報図７には、種々のサイト１１２−１・・・１１２−ｎと、１つのサイトには１以上のサーバ１３２−１・・・１３２−ｍが接続されたもの（【００３３】段落参照）が示されている。また、特開２００２−４１３７６号公報には「【００４７】・・・第２の実施の形態においては、特定のサーバ（たとえば、符号１３２−１参照）に、エージェントプログラムをダウンロードし、当該サーバの動作状況や接続されているローカルＩＰ領域の状況を監視でいるようになっている。」と記載され、複数の「サーバ」の監視、複数の「サーバ」が示されている。
　引用文献１発明において、関連するステップについてのそれぞれの計算機を「サーバ」とすることは、前記周知技術を参酌することにより当業者が容易になし得ることである。
〈相違点３〉について
　Ｂ．【００１４】段落には「図１は、・・・性能モニタリングを行う対象であるオブジェクトを搭載する計算機１０１，１０２・・・１２１から１２６までは実際にモニタリングの対象となるプログラム実体であるオブジェクトである。マネージャはそれぞれのオブジェクトに対してオブジェクトＩＤと呼ばれる一意のＩＤを用いることによってこれを区別する。」と記載され、【００２１】段落には「図３は、・・・オブジェクト一覧ウィンドウ３０２上には性能データを取得する対象候補としてオブジェクトのＩＤが複数個表示され、その中から計測対象とする１個又は１個以上のオブジェクトを選択可能である。同時に複数のオブジェクトが選択される場合には、選択される複数のオブジェクトは通常オブジェクト間通信によつて関連づけられるオブジェクトのグループである。」と記載され、Ｃ．【００２８】段落には「図６は、・・・リクエストフローテーブル７０１は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ１３０に到着した採取データリスト５０１を処理が行われた順に従って時系列に配列されるようにソートしたものである。」「リクエストフローテーブル７０１は一連の処理の流れごとに各々作成される。」と記載され、【００３０】段落にはステップ６２０で受信側オブジェクトＩＤが選択された計測対象オブジェクトであるかの判断がされ、ＮＯなら新規リクエストフローテーブルが作成されるとともに「ステップ６５０において、作成中リクエストフローテーブルの最後尾に付加された採取データリストの送信側オブジェクトＩＤ７０６をチェックする（ステップ６５０）（【００３２】段落）。これが選択された計測対象オブジェクトのＩＤでなければ（ステップ６５０でＮＯ）、このリクエストフローテーブルはこれで完結する」と記載されている。これらの記載によれば、オブジェクトの選択により選択された計測対象オブジェクトは、計算機１０１に搭載されたオブジェクト１２１〜１２４（図１参照）のみを対象とすることができ、その場合、選択されなかった計算機１０２のオブジェクト１２５、１２６は計測対象オブジェクトでないので、マネージャの処理手順（図８）のステップ６５０の送信側オブジェクトＩＤ７０６をチェックする判断で、リクエストフローテーブルはこれで完結することになる（計算機１０２のオブジェクトを選択した場合も同様）。そして、１組のオブジェクトを搭載した計算機中の計算機１０１が後続計算機１０２に処理要求（トランザクションを要求）することは分散処理システムの業務形態などに応じて適宜設計プログミングされる事項にすぎず（例えば、国際公開０２／１３００７号１６０頁（クレーム１４）には「comprising passing individual transactions among individual application servers」[訳；個々のアプリケーション・サーバの間で個々のトランザクションを渡すステップを含む］と記載されている。米国特許６１０８７００号（本願発明の詳細な説明【００６６】段落参照）ABSTRACT（要約）には、「transaction decomposition」[訳；トランザクション分解］「end-to-end business application transactions」[訳；エンドツーエンド・ビジネス・アプリケーション・トランザクション］と記載されている。）、前記のように計測対象オブジェクトが選択されていると、１組の計算機（サーバ）中の後続計算機（サーバ）に後続トランザクションを要求した後、要求されたトランザクションを完了することになる。
　これらをふまえると、１組の計算機装置中の各計算機装置について、要求されたトランザクションを完了するステップを、「１組のサーバ中の各サーバが、前記１組のサーバ中の後続サーバに後続トランザクションを要求した後、」完了すると成すことは前記事項を参酌することにより当業者が容易になし得ることである。
〈相違点４〉について
　前記〈相違点３〉で言及した、１組のオブジェクトを搭載した計算機中の計算機１０１が後続計算機１０２に処理要求（トランザクションを要求）することは分散処理システムの業務形態などに応じて適宜プログミングする事項において、トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記１組のエージェント中の各エージェントを構成するステップが、「後続トランザクションが要求される前記後続サーバ、に対して」前記トランザクションが向けられる、と成すことは、前記トランザクションからして自明の事項であり、当業者が容易になし得ることである。
　
　そして、本願発明の構成により奏する効果も、引用文献１発明に前記周知技術を適用することにより当然得られる程度のものであり、格別顕著なものとは認められない。
　
　なお、本願発明の詳細な説明には、２つのエージェント間でデータ要求及び収集を行うものが例示されているところ、各サーバに設けた情報収集手段間でデータの要求及び収集を行うことは周知（例えば、特開２００１−９２７６６号公報には、「【０００２】・・・クライアントに対するサーバあるいはサーバオブジェクトの割り当て（以下、ネーミングと言う。）・・・【０００７】・・・本発明の１実施例によれば、上記複数のサーバマシンのうちの１つが、負荷情報連絡メッセージを生成するマスタ用ネーミングサービスオブジェクトを有し、上記各交信手段が、上記マスタ用ネーミングサービスオブジェクトで生成した負荷情報連絡メッセージを複数のネーミングサービスオブジェクトに循環させるように順次に次のネーミングサービスオブジェクトに転送し、上記負荷情報連絡メッセージを介して各サーバマシンの負荷情報を交信する。
【０００８】上記構成によれば、各ネーミングサービスオブジェクトが、上記負荷情報連絡メッセージから他のサーバマシンの負荷情報を取得し、該負荷情報連絡メッセージに自サーバマシンの新たな負荷情報を設定して次のネーミングサービスオブジェクトに転送することによって、負荷情報連絡メッセージの受信の都度、他の複数のサーバマシンの負荷状態を把握することが可能となる。」「【００６７】・・・サーバマシンにネーミングサービス機能を装備」と記載されている。）であるから、仮に本願発明がエージェント間でのデータの要求及び収集の限定がなされたものであるとしても、その出願前に日本国内又は外国において頒布された刊行物記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて当業者が容易になし得るものである。
　
４．むすび
　以上のとおり、本願発明は、その出願前に日本国内又は外国において頒布された刊行物記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。