• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1243862
審判番号 不服2009-9950  
総通号数 143 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2011-11-25 
種別 拒絶査定不服の審決 
審判請求日 2009-05-15 
確定日 2011-09-21 
事件の表示 特願2004-514867「トランザクション・パイプライン分解のための方法およびシステム」拒絶査定不服審判事件〔平成15年12月31日国際公開、WO2004/001601、平成17年10月 6日国内公表、特表2005-530260〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成15年5月13日(パリ条約による優先権主張2002年6月20日、米国)を国際出願日とする出願であって、出願後の手続きの経緯は次のとおりである。
拒絶理由通知 平成20年9月25日
意見書、手続補正書 平成20年12月25日
拒絶査定(起案) 平成21年2月10日
拒絶査定(送達日) 平成21年2月17日
審判請求 平成21年5月15日

2.本願請求項1に係る発明
本願特許請求の範囲に記載された請求項1に係る発明は、平成20年12月25日付け手続補正書により補正されたとおりの次の事項により特定されるものである。(以下「本願発明」という。)

「トランザクション・パイプラインを構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って1組のエージェントを提供するステップと、
前記1組のエージェント中の各エージェントを、前記分散データ処理システム内の1組のサーバ中のサーバと関連づけるステップであって、前記1組のサーバ中の各サーバが、前記1組のサーバ中の後続サーバに後続トランザクションを要求した後、要求されたトランザクションを完了するステップと、
トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップと
を含む方法。」

3.引用文献
原審の拒絶の理由に引用された本願優先権主張日前に頒布された刊行物である特開2000-315198号公報(以下「引用文献1」という。)には、図面とともに次の記載がある。
A.「【0008】このように従来技術では各計算機、各オブジェクトのようにポイントの性能データは収集できるが、分散オブジェクトシステム全体を対象とした性能モニタリングはできないという問題点がある。
【0009】本発明は、上記のような事情に鑑み為されたもので、その目的とするところは、分散処理システム全体を対象とした性能モニタリングを行う方法及びそのような分散処理システムを提供することにある。
【0010】また性能のボトルネックを絞り込める分散処理システムの性能モニタリング方法を提供することを目的とする。」
B.「【0011】
【課題を解決するための手段】本発明は、各計算機上に配置されるモニタリング手段によつて計測対象となるプログラム実体について他プログラム実体からのメッセージの受信時刻及び他プログラム実体へのメッセージの送信時刻の少なくとも一方を性能データとして収集し、各モニタリング手段によって収集された性能データを集約して処理フローを構成する各プログラム実体の処理時間及びプログラム実体間の通信時間を算出し、表示装置上に表示する分散処理システムの性能モニタリング方法を特徴とする。
…(中略)…
【0014】(1)第1の実施形態
図1は、本実施形態の性能モニタリング方法を実現する計算機システムの構成図である。本計算機システムは、採取した性能に関するデータの処理と表示を行うプログラムであるマネージャ130を実行する計算機103と、性能モニタリングを行う対象であるオブジェクトを搭載する計算機101,102および計算機間を接続するLAN140から成る。本例ではモニタリングの対象となる計算機は2台であるが、その台数に制約はない。また各計算機はLAN140によって相互通信が可能であるが、通信を実現する手段もLANに限定されるわけではない。コレクタ131,132は、マネージャ130から指示を受け、必要に応じて性能データの採取、採取データのマネージャへの転送を行うプログラムである。121から126までは実際にモニタリングの対象となるプログラム実体であるオブジェクトである。マネージャはそれぞれのオブジェクトに対してオブジェクトIDと呼ばれる一意のIDを用いることによってこれを区別する。オブジェクトIDとして、例えば分散オブジェクト技術の標準の一つであるCORBAで用いられているオブジェクトリファレンスを用いる。
…(中略)…
【0018】図2は、第1の実施形態のシステム全体の処理の概略手順を示す図である。この処理手順はマネージャ130の担当部分であるブロック201とコレクタ131,132の担当部分であるブロック202の2つのブロックから成る。
【0019】まずマネージャ130が実行するブロック201について説明する。マネージャ130は最初にステップ210においてオブジェクトの一覧を表示し、性能データを採取するオブジェクトの選択入力を受け付ける。次にステップ220において、ステップ210で入力された性能データを採取するオブジェクトのオブジェクトIDを全てのコレクタ131,132にブロードキャストによつて通知する。マネージャ130はステップ230において、コレクタ131,132から転送されてくる性能データの到着を待つ。性能データを受信すると、ステップ240で各コレクタから送信される断片的な性能データの対応づけを行う。ここで対応づけとは、同一処理シーケンスに属する性能データをグループにまとめ、かつ時系列に従って配列することである。…(中略)…
【0020】続いてコレクタ131,132が実行するブロック202について説明する。コレクタ131,132はステップ270において、マネージャ130によってブロードキャストされた少なくとも1つのオブジェクトIDからなるデータを受信する。コレクタ131,132は、そのコレクタが実行されている計算機101,102内に受信したオブジェクトIDと同じオブジェクトIDを持つオブジェクトがあれば、そのオブジェクトの監視を開始する。以下このオブジェクトを計測対象オブジェクトと呼ぶ。コレクタ131,132はステップ280で計測対象オブジェクトに処理が発生すると、性能に係わるデータを採取し、採取したデータをステップ290においてマネージャに送信する。…(中略)…
【0021】図3は、計算機103の表示装置上に表示される計測対象オブジェクト選択画面301の例を示す図である。オブジェクト一覧ウィンドウ302上には性能データを取得する対象候補としてオブジェクトのIDが複数個表示され、その中から計測対象とする1個又は1個以上のオブジェクトを選択可能である。同時に複数のオブジェクトが選択される場合には、選択される複数のオブジェクトは通常オブジェクト間通信によつて関連づけられるオブジェクトのグループである。」
C.「【0023】図4は、コレクタ131,132が各々計算機101,102のメモリ上に作成する採取データリスト501のデータ構成を示す図である。採取データリスト501は、オブジェクトID502、受信側オブジェクトID503、受信側メッセージID504、受信時刻505、送信側オブジェクトID506、送信側メッセージID507および送信時刻508の各フィールドから成る。採取データリスト501は、計測対象オブジェクトが他のオブジェクトからメッセージを受信するか、他のオブジェクトにメッセージを送信するか、またはメッセージ受信に続いてメッセージ送信をするごとに1つ生成される。…(中略)…
【0024】計測対象オブジェクトは、データ入力等のイベントが発生し、処理開始する時点でその計算機に設けられるコレクタへその計測対象オブジェクトのID及び処理開始時刻を通知する。また計測対象オブジェクトは、他のオブジェクトにメッセージを送信する時点でそのコレクタへその計測対象オブジェクトのID、相手オブジェクトのID、送信するメッセージID及びメッセージ送信時刻を通知する。また他のオブジェクトからメッセージを受信した時点でそのコレクタへ計測対象オブジェクトのID、相手オブジェクトのID、受信したメッセージID、メッセージ受信時刻、および引き続きメッセージ送信が発生するか否かを示すフラグを通知する。また一連の処理を終了する時点で計測対象オブジェクトのID及び処理終了時刻をコレクタに通知する。コレクタは、マネージャ130から計測対象オブジェクトの通知を受けた後、計測対象オブジェクトに指令を送付してオブジェクトの時刻などの通知を開始させる。
…(中略)…
【0028】図6は、マネージャ130が計算機103のメモリ上に作成するリクエストフローテーブル701のデータ構成を示す図である。リクエストフローテーブル701は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ130に到着した採取データリスト501を処理が行われた順に従って時系列に配列されるようにソートしたものである。リクエストフローテーブル701の各行は採取データリスト501そのものであり、…(中略)…またある行の送信側オブジェクトID706に格納されるオブジェクトIDが次の行のオブジェクトID702であり、次の行の受信側オブジェクトID703に格納されるオブジェクトIDがある行のオブジェクトID702であり、送信側のメッセージIDと受信側のメッセージIDが一致する場合、同一トランザクションについての処理の流れの中で両方の計測対象オブジェクト間に通信が行われたことを示し、ある行の送信時刻708と次の行の受信時刻705との差が両オブジェクト間の通信時間である。リクエストフローテーブル701は一連の処理の流れごとに各々作成される。
…(中略)…
【0030】図8は、リクエストフローテーブル701を作成し表示するマネージャ130の処理の流れを示すフローチャートである。マネージャ130はコレクタ131,132から採取データリスト501が到着するのを待つ(ステップ610)。採取データリスト501が到着すると(ステップ610Yes)、その受信側オブジェクトID503をチェックし、このIDが選択された計測対象オブジェクトのIDのいずれかと一致しているか否かを判定する(ステップ620)。一致していない場合(ステップ620No)、計算機103のメモリ上に新規にリクエストフローテーブル701の領域を確保し、到着した採取データリスト501をその先頭の要素とする(ステップ635)。なおこの完成していないリクエストフローテーブル701を以降、作成中リクエストフローテーブルと呼ぶ。作成中リクエストフローテーブルは、図8に示された処理が行われている間、複数作成され得る。
【0031】一致している場合(ステップ620Yes)、作成中リクエストフローテーブルを探索し、その中にテーブルの最後尾を構成する採取データリストの送信側メッセージIDと、今取得した採取データリストの受信メッセージIDが一致しているテーブルがあるかどうかをチェックする(ステップ645)。チェックの結果、一致するものがあれば(ステップ645Yes)、当該作成中リクエストフローテーブルの最後尾に今取得した採取データリストを付加する(ステップ647)。また一致するものがなければ(ステップ645No)、採取データリストをメモリ上の一時保存領域である採取データリストバッファに保存し(ステップ649)、ステップ610に戻って新たな採取データリストの到着を待つ。
【0032】ステップ635、ステップ647に続くステップ650において、作成中リクエストフローテーブルの最後尾に付加された採取データリストの送信側オブジェクトID706をチェックする(ステップ650)。これが選択された計測対象オブジェクトのIDでなければ(ステップ650No)、このリクエストフローテーブルはこれで完結するので、このリクエストフローテーブルの表示を行う(ステップ652)。表示後、あらかじめ設定された時間を超えていないかをチェックする(ステップ654)。超えていなければ(ステップ654Yes)、ステップ610に戻って新たな採取データリストの到着を待つ。超えていれば(ステップ654No)、マネージャ130の処理を終了する。
【0033】ステップ650のチェックの結果、送信側オブジェクトが選択された計測対象オブジェクトのIDであった場合には(ステップ650Yes)、送信側メッセージID707と同じ受信側メッセージIDを持つ採取データリストを採取データリストバッファから探索する(ステップ655)。採取データリストが見つかれば(ステップ655有)、この採取データリストをステップ635又は647で対象とした作成中リクエストフローテーブルの最後尾に付加し、その後ステップ650に戻る。採取データリストがなければ(ステップ655無し)、ステップ610に戻り新たな採取データリストの到着を待つ。
【0034】図8に示すマネージャ130の処理手順によれば、複数のトランザクションに属する採取データリスト501が混在してマネージャ130に到着したり、各オブジェクトの処理のシーケンスと採取データリスト501到着のシーケンスとが異なっても、各トランザクションごとにリクエストフローテーブル701が作成され、リクエストフローテーブル701を構成する採取データリストは処理のシーケンスに従って時系列に配列される。」
D.「【0037】(2)第2の実施形態
第1の実施形態では、処理フローを取得したい場合に、ユーザはその処理フローに関与するすべてのオブジェクトを計測対象として指定しなければならないという面倒がある。第2の実施形態では、ユーザはオブジェクトを1つ指定することによってそのオブジェクトが行う処理から後の一連の処理について処理フローを得ることができる。この機能を実現するためにコレクタ131,132がリクエストフローテーブルを作成する。すなわちオブジェクト間を移動するメッセージにリクエストフローテーブルを付加し、各オブジェクトで処理が行われるごとにリクエストフローテーブルに採取データリストを追加する。以下に図1で示される分散オブジェクト環境について第2の実施形態の構成及び動作を説明する。
【0038】図9は、第2の実施形態のシステム全体の処理の概略手順を示すフロー図である。この処理手順はマネージャ130の担当部分であるブロック901とコレクタ131,132の担当部分であるブロック902の2つのブロックから成る。
【0039】まずマネージャ130が実行するブロック901について説明する。マネージャ130は最初にステップ910において処理フローの最初に処理を行うオブジェクトの選択入力を受け付ける。この入力方法は第1の実施形態で説明した方法と同じである。ただし指定するオブジェクトの数は1つに限定される。次にステップ920において、ステップ910で入力された性能データを採取するオブジェクトのオブジェクトIDを全てのコレクタ131,132にブロードキャストによつて通知する。マネージャ130はステップ930において、コレクタ131,132から転送されてくるデータの到着を待つ。…(中略)…マネージャ130が最初にコレクタ131,132より性能データを受け取ってからあらかじめ設定された一定時間、繰り返し行われる。
【0040】続いてコレクタ131,132が実行するブロック902について説明する。コレクタ131,132はステップ970において、マネージャ130によってブロードキャストされたオブジェクトIDを受信する。コレクタ131,132は、そのコレクタが実行されている計算機101,102内で実行されているオブジェクトの監視を開始する。コレクタ131,132はステップ980でオブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、採取したデータによって処理フローデータを作成する。次にステップ990で作成した処理フローデータをマネージャに送信する。…(中略)…このようにステップ980および990の処理は、コレクタ131,132がマネージャ130からオブジェクトIDのデータを受け取ってからあらかじめ設定された一定時間、繰り返し行われる。
【0041】図10は、第2の実施形態で用いる採取データリスト1101のデータ構成を示す図である。採取データリスト1101はオブジェクトID1110、受信時刻1120及び送信時刻1130の各フィールドから構成される。オブジェクトID1110はユーザによって指定されたオブジェクト又は処理フローを構成するいずれかのオブジェクトのIDである。受信時刻1120はそのオブジェクトについて処理開始時刻又はメッセージ受信時刻である。送信時刻1130はそのオブジェクトについてメッセージ送信時刻又は処理終了時刻である。
【0042】図11は、第2の実施形態で用いるリクエストフローテーブル1201のデータ構成を示す図である。リクエストフローテーブル1201は採取データリスト1101を処理が行われた順に従って時系列に配列したテーブルである。リクエストフローテーブル1201は各処理フローについて1つ作成される。
…(中略)…
【0052】以上説明した第2の実施形態によれば、ユーザはオブジェクトを1つ指定することによって、そのオブジェクトの処理から後の処理フローを得ることが可能となる。これにより例えばあるクライアントオブジェクトがどのサーバオブジェクトにアクセスするかわからなくても、そのクライアントオブジェクトを指定するだけでそのクライアントからの要求によって始まる一連の処理の処理フローを得ることが可能となる。また第1の実施形態のように特定のオブジェクトによって処理された処理フローを抽出することも可能である。」

(A)C.の【0034】段落には、複数のトランザクションに属する採取データリスト501が混在してマネージャ130に到着しても、ソートして各トランザクションごとにリクエストフローテーブル701が作成される旨記載されているから、この各トランザクションごとの複数の「リクエストフローテーブル」(リクエストフローテーブル701の内容にみられるようなメッセージの送受信)はトランザクションにあたる。
また、C.には、マネージャが作成するリクエストフローテーブル(図6のリクエストフローテーブル)に関連して、リクエストフローテーブル701は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ130に到着した採取データリスト501を処理が行われた順に従って時系列に配列されるようにソートしたものであり、リクエストフローテーブル701は一連の処理の流れごとに各々作成される旨記載され、図6のリクエストフローテーブルは、これを図式化した図7の処理フローに示されたようにオブジェクトIDで示されたオブジェクト間で線形にオブジェクト間通信接続される様子が示されており、D.には、第2の実施形態が記載され、オブジェクト間を移動するメッセージにリクエストフローテーブルを付加して各オブジェクトで処理が行われるごとに採取データリストを追加して収集されるリクエストフローテーブルが記載され、この第2の実施形態リクエストフローテーブルは第1の実施形態とは採取の仕方やリクエストフローテーブルの構成(図11参照)が異なるが、リクエストフローテーブルの内容は図7のように図式化でき、前記図6のリクエストフローテーブルと同様の線形の、複数のリクエストフローテーブルである。
前記複数のトランザクション、前記線形に接続されたリクエストフローテーブル(トランザクション)、A.に分散処理システム全体を対象とした性能モニタリング(性能監視)を行う方法、と記載されていることを合わせると、トランザクションの線形を構成する分散データ処理システムを監視する方法が認められる。
(B)A.の「分散オブジェクトシステム全体を対象とした性能モニタリングを行う方法」、B.の「性能モニタリングを行う対象であるオブジェクトを搭載する計算機101,102」、各計算機上に配置されるモニタリング手段(各コレクタのこと)によつて計測対象となるプログラム実体について他のプログラム実体からのメッセージの受信時刻及び他プログラム実体へのメッセージ送信時刻の少なくとも一方を性能データとして収集する旨(図1を参照すると、オブジェクトを実行する各計算機にそれぞれコレクタが配置されている)の記載と、コレクタ131、132は、マネージャから指示を受け必要に応じて性能データの採取を行う(【0014】参照)ことから、コレクタ131、132の集合は分散オブジェクトシステム全体を対象とした性能データの採取を行う1組のコレクタと解される。これらから、分散データ処理システム全体に渡って1組のコレクタ131、132が提供されていることが認められる。
(C)B.の「性能モニタリングを行う対象であるオブジェクトを搭載する計算機101,102」「各計算機上に配置されるモニタリング手段」(図1参照)からすると、各オブジェクトを搭載する計算機と各計算機の各コレクタとが配置において関連しており、1組のコレクタ中の各コレクタを、前記分散データ処理システム(図1)内の1組の計算機中の計算機と関連づけるステップがよみとれる。さらに、各計算機に搭載されたオブジェクト(各オブジェクトを搭載する計算機も意味は同様)とコレクタに関して、「マネージャ130は最初にステップ210においてオブジェクトの一覧を表示し、性能データを採取するオブジェクトの選択入力を受け付ける。次にステップ220において、ステップ210で入力された性能データを採取するオブジェクトのオブジェクトIDを全てのコレクタ131,132にブロードキャストによつて通知する。」「コレクタ131,132はステップ270において、マネージャ130によってブロードキャストされた少なくとも1つのオブジェクトIDからなるデータを受信する。コレクタ131,132は、そのコレクタが実行されている計算機101,102内に受信したオブジェクトIDと同じオブジェクトIDを持つオブジェクトがあれば、そのオブジェクトの監視を開始する。以下このオブジェクトを計測対象オブジェクトと呼ぶ。コレクタ131,132はステップ280で計測対象オブジェクトに処理が発生すると、性能に係わるデータを採取し、採取したデータをステップ290においてマネージャに送信する。」と記載され、同様に、D.【0040】に、コレクタ131,132は、マネージャ130によってブロードキャストされたオブジェクト(計測対象オブジェクト)IDを受信し、コレクタ131,132は、そのコレクタが実行されている計算機101,102内で実行されているオブジェクトの監視を開始し、コレクタ131,132はオブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、採取したデータによって処理フローデータを作成し、次に作成した処理フローデータをマネージャに送信する旨記載されていることから、各計算機に搭載されたオブジェクトと各計算機上に配置されたコレクタと関連づけるステップであって、各コレクタは計測対象オブジェクトに対して監視するよう関連づけられる。
そして、B.【0020】C.【0023】【0024】段落には、コレクタ131,132は当該コレクタ131,132が実行されている計算機101,102(計算機の組)内で実行されているオブジェクトを監視し、オブジェクトに処理が発生すると、処理開始時刻又はメッセージ受信時刻、メッセージ送信時刻又は処理終了時刻を必要に応じて採取し、計測対象オブジェクトのID及び処理終了時刻をコレクタに通知し(図5ステップ465処理終了時刻入力を参照)、C.【0034】段落と図8の、マネージャにより時系列に配列された各トランザクションごとのリクエストフローテーブル701の作成における手順における、ステップ650で、「リクエストフローテーブルはこれで完結する」(【0032】段落)と記載されており、コレクタで収集された監視データが前記完結であるものが含まれる。これらをふまえると、前記1組の計算機中の各計算機が、リクエストフローテーブル(リクエスト;要求)に対応する処理を終了ないし完結しており、少なくとも、要求されたトランザクションを完結、終了するステップがよみとれる。
(D)前記のように、C.【0024】段落には、計測対象オブジェクトは、データ入力等のイベントが発生し、処理開始する時点でその計算機に設けられるコレクタへその計測対象オブジェクトのID及び処理開始時刻を通知し、…(中略)…また、一連の処理を終了する時点で計測対象オブジェクトのID及び処理終了時刻をコレクタに通知する旨記載されており、前記一連の処理とリクエストフロー(トランザクション)とが対応しており、コレクタがトランザクションについての開始時刻と処理終了時刻を収集することが示され、【0032】段落には選択された計測対象オブジェクトのIDでなければ当該リクエストフローテーブルは完結する旨記載されている。前記マネージャにより時系列に配列された各トランザクションごとのリクエストフローテーブルの内容はコレクタで収集された内容と等価な内容を含む点、リクエストフローテーブルには受信側オブジェクト、受信側メッセージ、送信側オブジェクト、送信側メッセージを有し(図6参照)、通信の方向を有していてトランザクションが向けられるにあたる事項がよみとれる点をふまえると、トランザクション(リクエストフロー)を開始し、前記トランザクションについての完了情報(終了時刻、完結判断のための計測対象オブジェクトでないID)を取得するように、前記1組のコレクタ中の各コレクタを構成するステップであって、前記コレクタが関連づけられる前記オブジェクトが搭載された計算機によってトランザクションが向けられるに相当する事項が示されている。

(A)?(D)をふまえると、引用文献1には、分散処理システム全体を対象とした性能モニタリングを行うことができ、性能のボトルネックを絞り込める分散処理システムの性能モニタリング方法を提供することを目的とした次の発明(以下「引用文献1発明」という。)が示されている。

トランザクションの線形を構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って1組のコレクタ(131,132)を提供するステップと、
前記1組のコレクタ中の各コレクタを、前記分散データ処理システム内の1組の計算機中の計算機と関連づけるステップであって、オブジェクトを搭載する計算機で実行される計測対象オブジェクトは、マネージャからコレクタに通知され、各コレクタは、そのコレクタが実行されている計算機内の計測対象オブジェクトを監視し、処理開始する時点でその計算機に設けられるコレクタへ計測対象オブジェクトのID及び処理開始時刻、一連の処理を終了する時点で計測対象オブジェクトのID及び処理終了時刻を通知し、前記1組の計算機中の各計算機が、要求されたトランザクションを完結ないし終了するステップと、
トランザクションを開始し、前記トランザクションについての完結情報ないし終了情報を取得するように、前記1組のコレクタ中の各コレクタを構成するステップであって、前記コレクタが関連づけられる前記オブジェクトを搭載する計算機によってトランザクションが向けられる、ステップと
を含む方法。

[対比]
ア.引用文献1発明の「トランザクションの線形の組を構成する分散データ処理システムを監視する方法」は、トランザクション・パイプラインを構成するとまではいえないまでも、トランザクションを構成しており、一方、本願発明の「トランザクション・パイプラインを構成する」も、トランザクションを構成するから、両発明は「トランザクションを構成する分散データ処理システムを監視する方法」である点で共通する。
イ.引用文献1発明の「分散データ処理システム全体に渡って1組のコレクタを提供するステップ」における、当該コレクタはエージェントとは記載されていないがモニタリングの対象となるオブジェクトとは別の性能データの収集等を行うプログラム(引用文献の【0014】段落参照)であり、一方、本願発明の「エージェント」は、その【0023】段落に、エージェントとは、別のエンティティに代わって情報を集めまたはタスクを実施するソフトウェア・プログラムまたはそれに類似するエンティティのことであると記載されているから、オブジェクトに代わって情報を採取する「コレクタ」と「エージェント」とに技術的に格別な差異はない。したがって、引用文献1発明の前記ステップと本願発明の「前記分散データ処理システム全体に渡って1組のエージェントを提供するステップ」と実質的な差異はない。しかも、後記するようにエージェント自体は周知技術である。
ウ.引用文献1発明の「前記1組のコレクタ中の各コレクタを、前記分散データ処理システム内の1組の計算機中の計算機と関連づけるステップであって、オブジェクトを搭載する計算機で実行される計測対象オブジェクトは、マネージャからコレクタに通知され、各コレクタは、そのコレクタが実行されている計算機内の計測対象オブジェクトを監視し、処理開始する時点でその計算機に設けられるコレクタへ計測対象オブジェクトのID及び処理開始時刻、一連の処理を終了する時点で計測対象オブジェクトのID及び処理終了時刻を通知し、前記1組の計算機中の各計算機が、要求されたトランザクションを完結ないし終了するステップ」は、「1組の計算機中の後続計算機に後続トランザクションを要求した後、」を有しない点で本願発明と相違し、引用文献1発明の「計算機」はそれぞれ「サーバ」とまではいえないまでもネットワークに接続された計算機装置であり、一方、本願発明のサーバも、計算機装置(【0009】段落参照)と記載されていることから、いずれも計算機装置である点で共通する。
これらをふまえると、両発明は「前記1組のエージェント(コレクタ)中の各エージェントを、前記分散データ処理システム内の1組の計算機装置中の計算機装置と関連づけるステップであって、前記1組の計算機装置中の各計算機装置が、要求されたトランザクションを完了するステップ」で共通する。
エ.引用文献1発明の「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップ」と本願発明の「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって後続トランザクションが要求される前記後続サーバ、に対して前記トランザクションが向けられる、ステップ」とは、「トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップであって、前記エージェントが関連づけられる前記サーバによって前記トランザクションが向けられる、ステップ」で共通する。
以上の点を総合すると、本願発明と引用文献1発明とは、次の点で一致し、そして、次の点で相違する。
〈一致点〉
トランザクションの線形の接続を構成する分散データ処理システムを監視する方法であって、
前記分散データ処理システム全体に渡って1組のエージェントを提供するステップと、
前記1組のエージェント中の各エージェントを、前記分散データ処理システム内の1組の計算機装置中の計算機装置と関連づけるステップであって、前記1組の計算機装置中の各計算機装置が、要求されたトランザクションを完了するステップと、
トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップと
を含む方法。

〈相違点1〉トランザクションを構成するのが、本願発明は「トランザクション・パイプライン」を構成するのに対し、引用文献1発明は「トランザクションの線形の接続」を構成している点。
〈相違点2〉分散データ処理システム内の1組の計算機装置中のそれぞれの計算機装置が、本願発明は「サーバ」であるのに対し、引用文献1発明は「計算機」である点。
〈相違点3〉1組の計算機装置中の各計算機装置について、要求されたトランザクションを完了するステップが、本願発明が「1組のサーバ中の各サーバが、前記1組のサーバ中の後続サーバに後続トランザクションを要求した後、」完了するのに対し、引用文献1発明はこの点が不明である点。
〈相違点4〉トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップが、本願発明は「後続トランザクションが要求される前記後続サーバ、に対して」前記トランザクションが向けられる、のに対して、引用文献1発明は、この点が不明である点。

[当審判断]
〈相違点1〉について
本願発明における「トランザクション・パイプライン」は、本願発明の詳細な説明【0018】段落に記載される如く、その流れがほぼ線形であるトランザクションの流れを意味すると解される。マネージャも複数のトランザクションを対象としている。
してみると、引用文献1発明におけるトランザクションも該「トランザクション・パイプライン」を構成していると解することができ、前記相違点は単なる表現の相違にすぎないもので実質的な相違点といえるものではない。
〈相違点2〉について
D.の【0052】段落には、クライアントオブジェクトがどのサーバオブジェクトにアクセスするのかわからなくても、クライアントからの要求によって始まる一連の処理の処理フローを得ることが可能になる旨記載され、E.には、複数の計算機上で多数のオブジェクトが動作する場合に、どのオブジェクトがどのオブジェクトと関連をもって動作するかとか、どの処理フローにトランザクションが集中するかなど把握が困難であり、前記処理フローの態様がある旨記載されている。これらをふまえると、引用文献1発明の、計算機のオブジェクトがサーバのオブジェクトである場合が示唆されている。また、分散処理システム内の複数の計算機に関し、計算機がサーバであるものは周知である。例えば、特開2001-202303号公報図1には、ネットワークサービスを行う複数のサーバ101、102が示され、特開2002-41376号公報図7には、種々のサイト112-1・・・112-nと、1つのサイトには1以上のサーバ132-1・・・132-mが接続されたもの(【0033】段落参照)が示されている。また、特開2002-41376号公報には「【0047】・・・第2の実施の形態においては、特定のサーバ(たとえば、符号132-1参照)に、エージェントプログラムをダウンロードし、当該サーバの動作状況や接続されているローカルIP領域の状況を監視でいるようになっている。」と記載され、複数の「サーバ」の監視、複数の「サーバ」が示されている。
引用文献1発明において、関連するステップについてのそれぞれの計算機を「サーバ」とすることは、前記周知技術を参酌することにより当業者が容易になし得ることである。
〈相違点3〉について
B.【0014】段落には「図1は、・・・性能モニタリングを行う対象であるオブジェクトを搭載する計算機101,102・・・121から126までは実際にモニタリングの対象となるプログラム実体であるオブジェクトである。マネージャはそれぞれのオブジェクトに対してオブジェクトIDと呼ばれる一意のIDを用いることによってこれを区別する。」と記載され、【0021】段落には「図3は、・・・オブジェクト一覧ウィンドウ302上には性能データを取得する対象候補としてオブジェクトのIDが複数個表示され、その中から計測対象とする1個又は1個以上のオブジェクトを選択可能である。同時に複数のオブジェクトが選択される場合には、選択される複数のオブジェクトは通常オブジェクト間通信によつて関連づけられるオブジェクトのグループである。」と記載され、C.【0028】段落には「図6は、・・・リクエストフローテーブル701は、通信によつて関連づけられる計測対象オブジェクトのグループについてマネージャ130に到着した採取データリスト501を処理が行われた順に従って時系列に配列されるようにソートしたものである。」「リクエストフローテーブル701は一連の処理の流れごとに各々作成される。」と記載され、【0030】段落にはステップ620で受信側オブジェクトIDが選択された計測対象オブジェクトであるかの判断がされ、NOなら新規リクエストフローテーブルが作成されるとともに「ステップ650において、作成中リクエストフローテーブルの最後尾に付加された採取データリストの送信側オブジェクトID706をチェックする(ステップ650)(【0032】段落)。これが選択された計測対象オブジェクトのIDでなければ(ステップ650でNO)、このリクエストフローテーブルはこれで完結する」と記載されている。これらの記載によれば、オブジェクトの選択により選択された計測対象オブジェクトは、計算機101に搭載されたオブジェクト121?124(図1参照)のみを対象とすることができ、その場合、選択されなかった計算機102のオブジェクト125、126は計測対象オブジェクトでないので、マネージャの処理手順(図8)のステップ650の送信側オブジェクトID706をチェックする判断で、リクエストフローテーブルはこれで完結することになる(計算機102のオブジェクトを選択した場合も同様)。そして、1組のオブジェクトを搭載した計算機中の計算機101が後続計算機102に処理要求(トランザクションを要求)することは分散処理システムの業務形態などに応じて適宜設計プログミングされる事項にすぎず(例えば、国際公開02/13007号160頁(クレーム14)には「comprising passing individual transactions among individual application servers」[訳;個々のアプリケーション・サーバの間で個々のトランザクションを渡すステップを含む]と記載されている。米国特許6108700号(本願発明の詳細な説明【0066】段落参照)ABSTRACT(要約)には、「transaction decomposition」[訳;トランザクション分解]「end-to-end business application transactions」[訳;エンドツーエンド・ビジネス・アプリケーション・トランザクション]と記載されている。)、前記のように計測対象オブジェクトが選択されていると、1組の計算機(サーバ)中の後続計算機(サーバ)に後続トランザクションを要求した後、要求されたトランザクションを完了することになる。
これらをふまえると、1組の計算機装置中の各計算機装置について、要求されたトランザクションを完了するステップを、「1組のサーバ中の各サーバが、前記1組のサーバ中の後続サーバに後続トランザクションを要求した後、」完了すると成すことは前記事項を参酌することにより当業者が容易になし得ることである。
〈相違点4〉について
前記〈相違点3〉で言及した、1組のオブジェクトを搭載した計算機中の計算機101が後続計算機102に処理要求(トランザクションを要求)することは分散処理システムの業務形態などに応じて適宜プログミングする事項において、トランザクションを開始し、前記トランザクションについての完了情報を取得するように、前記1組のエージェント中の各エージェントを構成するステップが、「後続トランザクションが要求される前記後続サーバ、に対して」前記トランザクションが向けられる、と成すことは、前記トランザクションからして自明の事項であり、当業者が容易になし得ることである。

そして、本願発明の構成により奏する効果も、引用文献1発明に前記周知技術を適用することにより当然得られる程度のものであり、格別顕著なものとは認められない。

なお、本願発明の詳細な説明には、2つのエージェント間でデータ要求及び収集を行うものが例示されているところ、各サーバに設けた情報収集手段間でデータの要求及び収集を行うことは周知(例えば、特開2001-92766号公報には、「【0002】・・・クライアントに対するサーバあるいはサーバオブジェクトの割り当て(以下、ネーミングと言う。)・・・【0007】・・・本発明の1実施例によれば、上記複数のサーバマシンのうちの1つが、負荷情報連絡メッセージを生成するマスタ用ネーミングサービスオブジェクトを有し、上記各交信手段が、上記マスタ用ネーミングサービスオブジェクトで生成した負荷情報連絡メッセージを複数のネーミングサービスオブジェクトに循環させるように順次に次のネーミングサービスオブジェクトに転送し、上記負荷情報連絡メッセージを介して各サーバマシンの負荷情報を交信する。
【0008】上記構成によれば、各ネーミングサービスオブジェクトが、上記負荷情報連絡メッセージから他のサーバマシンの負荷情報を取得し、該負荷情報連絡メッセージに自サーバマシンの新たな負荷情報を設定して次のネーミングサービスオブジェクトに転送することによって、負荷情報連絡メッセージの受信の都度、他の複数のサーバマシンの負荷状態を把握することが可能となる。」「【0067】・・・サーバマシンにネーミングサービス機能を装備」と記載されている。)であるから、仮に本願発明がエージェント間でのデータの要求及び収集の限定がなされたものであるとしても、その出願前に日本国内又は外国において頒布された刊行物記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて当業者が容易になし得るものである。

4.むすび
以上のとおり、本願発明は、その出願前に日本国内又は外国において頒布された刊行物記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2011-04-22 
結審通知日 2011-04-26 
審決日 2011-05-09 
出願番号 特願2004-514867(P2004-514867)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 殿川 雅也  
特許庁審判長 山崎 達也
特許庁審判官 ▲吉▼田 美彦
冨吉 伸弥
発明の名称 トランザクション・パイプライン分解のための方法およびシステム  
代理人 市位 嘉宏  
代理人 太佐 種一  
代理人 上野 剛史  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ