【事件の表示】
　平成１０年特許願第１１０５８５号「動的移動エージェント」拒絶査定不服審判事件〔平成１０年１２月４日出願公開、特開平１０−３２０３６１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１０年４月２１日（パリ条約による優先権主張１９９７年５月１日、アメリカ合衆国）の出願であって、平成１２年６月９日付けで拒絶査定がなされ、これに対し、同年９月１８日に拒絶査定に対する審判請求がなされるとともに、同日付けで手続補正がなされたものである。
　
　
２．平成１２年９月１８日付けの手続補正についての補正却下の決定
【補正却下の決定の結論】
　平成１２年９月１８日付けの手続補正を却下する。
　
【理由】
（１）補正後の本願発明
　本件補正により、特許請求の範囲の請求項１は、本件補正前の、
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
　ａ）実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
　ｂ）前記名前および前記属性の関数としての１つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップと、
　ｃ）前記実行可能ユニットを実行するために選択された目標ロケーションへエージェントをディスパッチするステップと、
　を含む方法。」
から、
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
　ａ）実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
　ｂ）前記名前および前記属性の関数としての１つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップと、
　ｃ）前記実行可能ユニットを実行するために選択された目標ロケーションへ１つの移動エージェントをディスパッチするステップと、
　を含む方法。」
へと補正された。
　上記補正は、請求項１に記載した発明を特定するために必要な事項である、
ｉ）ステップ「ｂ）」の「１つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップ」について、「取得する」を「選択して取得する」との限定を付加し、また、
ii）ステップ「ｃ）」の「選択された目標ロケーションへ」「ディスパッチする」対象の「エージェント」について、「１つの移動エージェント」との限定を付加するものであるから、
特許法第１７条の２第４項第２号に係る特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか）について以下に検討する。
　
（２）引用例
１）原査定の拒絶の理由に引用された、特開平７−１８２１７４号公報（以下、「引用例１」という。）には、図面とともに、次の事項が記載されている。
１-1）「【請求項１】　エージェントクラス及びプレイスクラスを含む複数のオブジェクト指向クラスを定義し、
前記オブジェクト指向クラス、該オブジェクト指向クラスのサブクラス及び go オペレーションを含む、コンピュータプロセスのためのインストラクションを形成し、該コンピュータネットワーク中のプロセッサによって前記インストラクションをインタープリートし、
前記 go オペレーションに応答して、エージェントプロセスがプレイスプロセスに転送され、前記エージェントプロセスが、前記エージェントクラスの１つのメンバであり、前記プレイスプロセスは前記プレイスクラスの１つのメンバであることを特徴とするコンピュータネットワークにおけるリモートプログラミングの実施方法。」（第1頁左欄2〜14行目）
１-2）「【請求項７】　前記プレイスプロセスをチケット手段によって指定することを特徴とすることを請求項第１項記載のリモートプログラミングの実施方法。
【請求項８】　前記チケット手段を前記エージェントプロセス内において形成することを特徴とする請求項第７項記載のリモートプログラミングの実施方法。
【請求項９】　前記チケット手段中において前記プレイスプロセスのアドレスを形成することを特徴とする請求項第７項記載のリモートプログラミングの実施方法。
【請求項１０】　前記アドレスがテレアドレスであることを特徴とする請求項第９項記載のリモートプログラミングの実施方法。
【請求項１１】　前記チケット手段中において前記プレイスプロセスのネームを形成することを特徴とする請求項第７項記載のリモートプログラミングの実施方法。
【請求項１２】　前記ネームがテレネームであることを特徴とする請求項第１１項記載のリモートプログラミングの実施方法。」（第1頁左欄36行目〜右欄3行目）
１-3）「【０００１】
【産業上の利用分野】本発明は、リモートプログラミングの実施方法に関し、特に分散型計算環境であって、オブジェクト指向環境において複数のプロセスがつくり出され、コンピュータネットワークを通じてそれ自身の運動を差し向けるようにしたリモートプログラミングの実施方法等に関する。」（第11頁右欄32〜38行目）
１-4）「【０２１０】コンピュータプロセスのインストラクションは、データオブジェクトの定義、生成及び操作と、目的点のコンピュータシステムによって実行される他のコンピュータシステムとの相互作用とを含む複雑なオペレーションを遂行するために、目的点のコンピュータシステムによって実行される。コンピュータプロセスはネットワーク全体を通じて一様に解釈され、コンピュータシステムの間に転送されるようにエンコードされかつデコードされるので、本発明のコンピュータプロセス（複数）は、コンピュータ間の通信において新しいレベルの機能性及び多様性を供与する。
【０２１１】一実施例によれば、本発明のコンピュータインストラクションのセットに組み込まれた２つのクラスは、エージェントクラスとプレイスクラスである。エージェントクラスを用いて形成されたインストラクションは、エンジンによって解釈され、エージェントプロセス（本明細書中において単にエージェント）と呼ばれることもある。エージェントは、エージェントが生成されたときにエンジンがその実行を開始するという点でアクティブオブジェクトである。エージェントクラスは、エージェントが（ｉ）それ自身を検査して変更し、（ｉｉ）ネットワーク中の以下にそれを詳細に説明する第１のプレイスプロセスから同じネットワーク中の第２のプレイスプロセスまでそれ自身を転送し、（ｉｉｉ）第２のプレイスプロセスに見出される他のエージェントと相互作用することを可能にするインストラクション（複数）を供与する。第１のプレイスプロセス及び第２のプレイスプロセスはネットワークの２つの別々のコンピュータシステム内において実行される。したがってあるエージェントは第１のコンピュータシステムから第２のコンピュータシステムに移動することができる。」（第25頁左欄45行目〜右欄25行目）
１-5）「【０４１６】エージェント（agent）： エージェントは、あるプレイスをしめ、可動である、すなわち第１のプレイスから第２のプレイスに移動することのできるプロセスである。」（第38頁左欄29〜32行目）
１-6）「【０４１８】属性（attribute）：属性は、あるオブジェクトの内部状態に関する情報を検索し又はセットするフィーチャである。通常情報はオブジェクト自身に所属するが、時には、情報は、属性を呼び出す際にオブジェクトを特定化するためのリフエランス（参照）に関する。属性は一対のオペレーションであり、一方のオペレーションはレスポンダの内部状態に関する情報をセットし他のオペレーションは、レスポンダの内部状態に関する情報を検索する。」（第38頁左欄40〜48行目）
１-7）「【０４２５】フィーチャ（feature）：フィーチャはあるオブジェクトが遂行するように指示されることのできるタスクである。タスクは、一組のコンピュータインストラクションを含む方法によって遂行される。あるフィーチャの遂行は、そのフィーチャの方法のコンピュータ指令の実行によって達成される。あるフィーチャは、ある特定のオブジェクトのクラスと関係があり、あるフィーチャの遂行は、そのフィーチャを遂行するオブジェクトの特定的な内部状態と共に変化しうる。フィーチャは、概念的には、次の２つのカテゴリすなわち（ｉ）属性及び（ｉｉ）オペレーションに分類される。」（第38頁右欄41行目〜第39頁左欄1行目）
１-8）「【０４３６】プレイス（place）：プレイスは、ゼロ又はそれ以上の方法の場所（locale）であるプロセスである。あるプレイスは第２のプレイスを占有しうる。初めに述べたプレイスは、第２のプレイスのサブプレイスであり、第２のプレイスは第１のプレイスのスーパープレイスである。」（第39頁右欄11〜16行目）
１-9）「【０４３８】プロセス（process）：プロセスは、自律的な計算を構成するオブジェクトである。プロセスは別のオブジェクトによってそのように要求されえることなしに方法を遂行するので、自律的である。あるプロセスは、そのプロセスの創設と共に中央方法の遂行を開始し、中央方法の完成と共にそのプロセスは破壊される。各々のオブジェクトは正確に１つの方法によって所有される。各々のプロセスはそれ自身によって所有される。この明細書で使用する”コンピュータプロセス”と言う用語は、より一般的な周知の定義である、コンピュータシステムによって遂行される一連のインストラクションを意味する。」（第39頁右欄21〜32行目）
１-10）「【０４６２】あるエージェントはそれ自身の運動をネットワークを通じて差し向けることすなわち転送することができるので、第１のコンピュータシステムから第２のコンピュータシステムへのトリップ（旅行）のある数のパラメータを特定するための手段を設けなければならない。この旅行の第１のパラメータは、エージェントがそれに向かって移送されるプレイスすなわち旅行の目的地である。一実施例によれば、トリップの目的値は、ネーム、クラス又はアドレスによって指定することができる。アドレスは一例としてローカルエリアネットワーク内のある番地（ロケーション）である。」（第42頁右欄41行目〜第43頁左欄1行目）
１-11）「【０４６６】一実施例によれば、チケット１３０６（図６）は、エージェント１５０Ａの転送を制御し、目的プレイスとしてのプレイス２２０Ｂを特定する。」（第43頁左欄34〜36行目）
１-12）「チケット１３０６（図３５）によって規定されたトリップの行程において、エージェント１５０（図３４）は１つのエンジンから次のエンジンへと移送される。従って、”移送目的点”は１つのエンジンである。一般にトリップには、エージェントがトリップ目的点を含むエンジンに到達するまでにエージェントの何回かの転送を必要とすることが有り得る。」（第53頁左欄15〜21行目）
１-13）「【０５４４】エンジンを領域に分類することは、大型の複雑なネーットワークにおいてエージェントをルーティングする上に有用である。あるエージェントが複数の領域の間を移動する場合、移送目的エンジンについての情報をソースエンジンが有していることは不可欠ではない。どの領域にエージェントが移動しているかをソースエンジンが定めることができ、そしてそのエージェントをその領域内のあるエンジンに向かって移送させることができれば十分である。トリップの目的点であるプレイスを含む領域にエンジンが移送されたら、エージェントは一層容易にそのプリスを含むエンジンに向かってルーティングさせることができる。」（第53頁左欄45行目〜右欄6行目）
１-14）「【０６６９】オペレーション”send”
あるエージェントは、オペレーション”send”を遂行することによって同時にいくつかのプレイスに移行することができる。」（第70頁右欄30〜33行目）
１-15）「【１００８】１．１  テレスクリプトインストラクションセット
ここに”インストラクションセット”としてときには呼ばれる、テレスクリプトインストラクションセットは、適用分野を分散型システム及びアプリケーションにしようとするプログラミング言語を集合的に形成するコンピュータインストラクションの組である。インストラクションセットは、オブジェクト指向でインタプリタされるものである。マイクロフィルムのアペンディックス　Ｅ、Ｆにおいて、インストラクションセットはときには”言語”とも言われる。
【１００９】インストラクションセットの中に組み込まれる最も顕著なクラスは、クラス”エージェント（Agent）”及び”プレイス（Place）”である。エージェント、すなわちクラス”エージェント”のメンバであるコンピュータプロセスは、それ自身を検査変更し、それ自身をネットワーク中の一方のプレイスから他方のプレイスに転送し、そしてそこに見い出される他のエージェントと相互作用することのできるアクティブなオブジェクトである。この能力は、特別な場合において特別なエージェントに対して特別な能力のみをプログラマまたは管理者のどちらか一方が許可できるようにする、パーミットによってバランスされる。プレイスすなわちクラス”プレイス”の一つのメンバであるコンピュータプロセスは、それ自身を検査変更することができ、エージェントに対する地域（venue）及びエージェントが相互作用するコンテキストとして取り扱う活動的なオブジェクトである。
【１０１０】あるエージェントは、あるプレイスに行き、そこでそのプレイス及びそのプレイスの他の占有者と相互作用する。エージェントとプレイスとはある距離をおいては相互作用できない。このようにリモートプログラミング（以下、単にRemote ProgrammingをRPという）を実行するインストラクションセットは、より親しみのあるリモートプロシージャコーリング（以下、単にRemote Procedure callingをRPC という）パラダイムを実行するのではない。RPは、可能なシステムの要素をコミュニケーションなしに相互作用させることによってRPC を改善し、その待ち時間（latency ）を減少させることによって相互作用の兼ね合いを改善する。等価的には、RPは、システムの要素が、他の領域内に存在するそれ自身のエージェント−そしてこのようにそれら自身−によって他のものをあつらえる。」（第115頁左欄3〜45行目）
　したがってこれら記載事項によると、引用例１には、
「複数のプレイスプロセスに対して転送されるエージェントをルーティングする方法であって、
　ａ）目的とするプレイスプロセスを指定するネーム（名前）を決定するステップと、
　ｂ）前記ネーム（名前）によって特定される１つまたは複数のプレイスをシステムの構成に応じて選択して取得するステップと、
　ｃ）前記プレイスプロセスを実行するために選択されたプレイスへ１つのエージェントを相互作用させるステップと、
を含む方法。」
の発明（以下「引用例１に記載の発明」という。）が記載されている。
　
２）また、原査定の拒絶の理由に引用された、特開平８−２４９２９０号公報（以下、「引用例２」という。）には、図面とともに、次の事項が記載されている。
２-1）「【００３１】ネットワーク上に複数個のコンピュータが接続された分散システムであって、アプリケーションプログラム間連携処理に関わる個々のアプリケーションプログラム本体にアプリケーションプログラム間連携処理手続きを実行するための連携インタフェースを付与したサービスエンティティと、連携させるサービスエンティティ間の移動先を表す利用順序とサービスエンティティの利用手続きを有するサービスエージェントと、サービスエージェントをそれが有する利用順序に記述された移動先に移動させる通信路を生成、維持、管理するルーティングマネージャとを備える。」（第5頁左欄21〜31行目）
２-2）「【００３４】そのルーティングマネージャは、コンピュータ起動時に他のコンピュータと通信するための論理的な通信路を確立する論理的通信路確立手段と、他のコンピュータとの間の該論理的通信路を切り放す手段と、他のコンピュータからの接続要求を受け取る手段と、ルーティングマネージャを停止させることなく、任意のコンピュータ間で論理的通信路の接続先コンピュータを変更する手段と、該ルーティングマネージャの動作するコンピュータ上で動作するサービスエンティティを管理する手段と、受信したサービスエージェントの要求するサービスエンティティの名称を取得して、該ルーティングマネージャの動作するコンピュータ上で動作するサービスエンティティと該サービスエージェントが要求するサービスエンティティの名称を比較し、該コンピュータ上で該サービスエージェントが要求するサービスエンティティが実行できるか否かを判定する手段と、該サービスエージェントの要求するサービスエンティティが実行できない場合には、論理的に接続された他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる手段と、該サービスエージェントの要求するサービスエンティティが実行できる場合には、該サービスエンティティに該サービスエージェントを移動させる手段とを備える。」（第5頁右欄7〜29行目）
２-3）「【０１０３】接続要求プログラム４２は、管理テーブル作成プログラム４１により処理装置１６のメモリ１５上に作成された接続先管理テーブル４６に格納されたコンピュータ名の一覧の先頭から順に接続先コンピュータ名を取得し、その接続先コンピュータに対して接続を要求する。
【０１０４】接続ができない場合には、次の接続先コンピュータ名を取得し、接続ができるまで順次接続要求を行う。
【０１０５】また、接続先管理テーブルに格納された接続先コンピュータ名がなくなるまで、順次、接続要求を行っても接続できない場合、エラーメッセージを出力し、処理を終了する。」（第10頁左欄19〜31行目）
　したがってこれら記載事項から、引用例２には、「ネットワーク上に複数個のコンピュータが接続された分散システムにおいて、サービスエージェントが要求するサービスエンティティをルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には、他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる」技術が記載されている。
　
（３）対比
　そこで、本件補正発明（以下、「前者」という。）と引用例１に記載の発明（以下、「後者」という。）とを対比すると、
イ）後者の「プレイスプロセス」は、上記（２）の１-9）で示した「プロセス」に関する説明記載から、前者の「実行可能ユニット」に相当する。
ロ）後者の「エージェント」は、コンピュータネットワーク中を移動するものであるから、前者の「移動エージェント」に相当する。
ハ）前者の「実行可能ユニットの論理要件を指定する」ことは、目的対象とする要件を備えた「実行可能ユニット」を指定することと認められ、一方、後者の「目的とするプレイスプロセスを指定する」ことも、「プレイスプロセス」が有する要件をその目的対象として指定することであるから、後者の「目的とするプレイスプロセスを指定する」は、前者の「実行可能ユニットの論理要件を指定する」に相当する。
二）後者の「プレイス」は、前者の「目標ロケーション」に相当する。
ホ）後者の「１つまたは複数のプレイス」が「ネーム（名前）」「によって特定される」ことは、該「１つまたは複数のプレイス」が該「ネーム（名前）」の関数という形で表されることを意味することは明らかであるから、後者の「前記ネーム（名前）によって特定される１つまたは複数のプレイス」は、前者の「前記名前の関数としての１つまたは複数の目標ロケーション」に相当する。
へ）後者の「相互作用させる」ことは、上記（２）の１-4）、及び１-15）の記載内容より、移動したエージェントが他のコンピュータシステムで実行されることを意味することと解されるから、前者の「ディスパッチする」ことに相当する。
　したがって、両者は、
「複数の実行可能ユニットを含む移動エージェントをルーティングする方法であって、
　ａ）実行可能ユニットの論理要件を指定する名前を決定するステップと、
　ｂ）前記名前の関数としての１つまたは複数の目標ロケーションをシステムの構成に応じて選択して取得するステップと、
　ｃ）前記実行可能ユニットを実行するために選択された目標ロケーションへ１つの移動エージェントをディスパッチするステップと、
　を含む方法。」
である点において一致し、次の点で相違する。
ｉ)「実行可能ユニットの論理要件を指定する」ために「決定する」ものが、前者は「名前および属性」であるのに対し、後者は、「名前」である点、
ii）「１つまたは複数の目標ロケーションを」「選択して取得する」ことを、前者では、「システムの動的構成に応じて」行うことにより「移動エージェントを動的にルーティングする」のに対し、後者では、「システムの構成に応じて」が「動的」か否か明らかでなく、よって「移動エージェントをルーティングする」ことが「動的」か否かについて記載がない点。
　
（４）相違点に対する判断
　次に、相違点について以下に検討する。
Ａ）相違点ｉ）について
　前者でいう「属性」の意味するところは、本願明細書によれば、「マシン・アーキテクチャ・タイプや負荷標識などの」、サポート対象とするコンポーネントの機能を記述するものと解されるが（発明の詳細な説明【００１８】）、情報処理分野においては、ハードウェア等を構成するコンポーネント（要素）を指定する際に、そのコンポーネント（要素）の属性を用いることは慣用の手法に過ぎない。
　また、（２）の１-6）で示したように、後者でも「属性」について定義がなされており、後者において、「実行可能ユニットの論理要件」を指定する際に、「名前」のみではなく、「属性」も指定可能とし、前者のように「名前および属性を決定する」ことは、当業者ならば適宜に採用し得る設計的事項であると認められ、当該相違点は格別のものではない。
　
Ｂ）相違点ii）について
　上記（２）の２）で示した、引用例２に記載の「ネットワーク上に複数個のコンピュータが接続された分散システムにおいて、サービスエージェントが要求するサービスエンティティをルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には、他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる」技術は、移動するサービスエージェントに対して、ルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には動的にルーティングさせていることから、システムの動的構成に応じて目標コンピュータを選択していることに相当するものと認められる。
　ここで、当該引用例２に記載の技術が、本願補正発明が課題としているような、コンポーネント・ホストの障害、過負荷、属性の変更といった動的な変化に対応できるものであるかについては明記されていないので、以下に検討を加える。
　一般に、ネットワーク上のエージェントに関する技術分野において、端末やサーバといったリソースの障害や負荷などの状況、構成変更に応じて動的にルーティングを行う、換言すれば、本願補正発明のように、システムの動的構成に応じて目標とする端末やサーバといった実行可能ユニットを選択取得する技術は、周知の技術である。当該周知の技術を裏付ける文献としては、例えば、以下のものを掲げることができる。
　
Ｂ-1）周知文献Ａ：
電子情報通信学会技術研究報告 Vol.95 No.215 (1995-8-24) p.33-38
　「パーソナルエージェントに基づく通信網DUETの試作」
　特に、５−２．(p.36)には、
「サービスを実行する際、ＰＡ間でのメッセージ転送、ＰＡと既存網制御部（リソースマネージャ）との間のメッセ一ジ転送が行われる。
ＰＡの位置や端末の位置を意識することなくＰＡから制御可能とする為に、メッセージのルーティング機構が必要である。
また、端末の空塞状態やエリアに誰がいてどの端末が使用可能かといった動的に変化する情報の管理も必要である。
DUETでは、ルーティング機構とデータベース機能を合わせ持つDOP(Distributed Object Pool)によりこれらの機能を実現した。」
と記載されており、システムの動的変更に対応するルーティングに関する技術が示されている。
　
Ｂ-2）周知文献Ｂ：
　日経コンピュータ　No.393　(1996-6-10)　日経BP社　p.122-132
　「ネットワーク・エージェント」
　特に、日本ユニシスSYSTEMνの分散オブジェクト技術について、
「ＴＡは各サーバー上に常駐して，クライアントやサーバーのオブジェクトの位置を分散管理する。ＴＡがオブジェクト間でメッセージ授受を仲介するのに最適なルートを自動的に決める。あるサーバーに障害が発生した際には，自動的にそのサーバーをう回してメッセージをやり取りする機能も提供する。」(p.130)
「図６●日本ユニシスのクライアント/サーバー型システム開発・実行環境SYSTEMν（ニュ−）の構成。オブジェクトの場所を示すディレクトリ管理テーブルを各サーバー上のトランスファ・エージェント（TA）が分散管理するので特定の管理サーバーに負荷が集中しない」(p.128)
と記載されており、サーバーの障害等に対応した動的ルーティングの技術が示されている。
　
Ｂ-3）周知文献Ｃ：
　電子情報通信学会1997年総合大会講演論文集　情報・システム１
　(1997-3-27)　p.208
　D-9-15　「分散マルチメディアDBの仮想データベース化と検索制御技術」
　「2.1」には、「ユーザ／端末は論理データベースの窓口Retrieval Managerに対して検索要求を出す（このとき各分散データベースの位置情報は流通しない）。要求を受けた論理データベースはその時点の状況（ネットワーク状態、サーバ状態など）により各データベースへの検索パスやデータ送出サーバ（Contents Server）などを動的に構成し、並列処理する。データ送出サーバはコンテンツデータを他のサーバを経由せずに端末に直接送出する。
このモデルを適用することによって、前述の1.，2.のような問題は発生しない。分散構造変更時には、Directory Serverに格納されているディレクトリ情報（サーバアドレスなどの位置情報）を書き換えるだけでよく、ユーザ操作の変更、端末処理の変更、データベース間のリンク構造の変更などは必要ないため、常に最適な分散構造に維持可能である柔軟なシステムを実現でき、性能上も有利である。
このモデルはエージェントシステムの１形式といえるであろう。」
と記載されており、システムの動的な構成に対応してサーバを選択する分散システムの技術が示されている。
　
　してみれば、後者の「１つまたは複数の目標ロケーションをシステムの構成に応じて選択して取得するステップ」において、引用例２に記載の技術及び上述した周知の技術を適用して、前者のように「１つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップ」とし、「移動エージェントを動的にルーティングする」ことは、当業者が容易に想到し得ることであり、当該相違点は格別のものとは認められない。
　
　そして、本願補正発明の作用効果も、引用例１、引用例２及び上述した周知の技術から、当業者が予測できる範囲のものである。
　したがって、本願補正発明は、引用例１に記載の発明、引用例２に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下されるべきものである。
　
　
３．本願発明について
　平成１２年９月１８日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１２年２月２８日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
　ａ）実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
　ｂ）前記名前および前記属性の関数としての１つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップと、
　ｃ）前記実行可能ユニットを実行するために選択された目標ロケーションへエージェントをディスパッチするステップと、
　を含む方法。」
　
（１）引用例
　原査定の拒絶の理由に引用された引用例、および、その記載事項は、上記２．（２）に記載したとおりのものである。
　
（２）対比・判断
　本願発明は、上記２．で検討した本願補正発明から、「ｂ）前記名前および前記属性の関数としての１つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップ」における限定事項である「選択して」の構成を省き、「ｃ）前記実行可能ユニットを実行するために選択された目標ロケーションへ１つの移動エージェントをディスパッチするステップ」における限定事項である「１つの移動エージェント」を「エージェント」とするものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．（４）に記載したとおり、引用例１に記載の発明、引用例２に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１に記載の発明、引用例２に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用例１に記載の発明、引用例２に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。