• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1120905
審判番号 不服2000-14840  
総通号数 69 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 1998-12-04 
種別 拒絶査定不服の審決 
審判請求日 2000-09-18 
確定日 2005-08-10 
事件の表示 平成10年特許願第110585号「動的移動エージェント」拒絶査定不服審判事件〔平成10年12月4日出願公開、特開平10-320361〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成10年4月21日(パリ条約による優先権主張1997年5月1日、アメリカ合衆国)の出願であって、平成12年6月9日付けで拒絶査定がなされ、これに対し、同年9月18日に拒絶査定に対する審判請求がなされるとともに、同日付けで手続補正がなされたものである。


2.平成12年9月18日付けの手続補正についての補正却下の決定
【補正却下の決定の結論】
平成12年9月18日付けの手続補正を却下する。

【理由】
(1)補正後の本願発明
本件補正により、特許請求の範囲の請求項1は、本件補正前の、
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
a)実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
b)前記名前および前記属性の関数としての1つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップと、
c)前記実行可能ユニットを実行するために選択された目標ロケーションへエージェントをディスパッチするステップと、
を含む方法。」
から、
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
a)実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
b)前記名前および前記属性の関数としての1つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップと、
c)前記実行可能ユニットを実行するために選択された目標ロケーションへ1つの移動エージェントをディスパッチするステップと、
を含む方法。」
へと補正された。
上記補正は、請求項1に記載した発明を特定するために必要な事項である、
i)ステップ「b)」の「1つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップ」について、「取得する」を「選択して取得する」との限定を付加し、また、
ii)ステップ「c)」の「選択された目標ロケーションへ」「ディスパッチする」対象の「エージェント」について、「1つの移動エージェント」との限定を付加するものであるから、
特許法第17条の2第4項第2号に係る特許請求の範囲の減縮を目的とするものに該当する。
そこで、本件補正後の前記請求項1に記載された発明(以下、「本願補正発明」という。)が、特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第5項において準用する同法第126条第4項の規定に適合するか)について以下に検討する。

(2)引用例
1)原査定の拒絶の理由に引用された、特開平7-182174号公報(以下、「引用例1」という。)には、図面とともに、次の事項が記載されている。
1-1)「【請求項1】 エージェントクラス及びプレイスクラスを含む複数のオブジェクト指向クラスを定義し、
前記オブジェクト指向クラス、該オブジェクト指向クラスのサブクラス及び go オペレーションを含む、コンピュータプロセスのためのインストラクションを形成し、該コンピュータネットワーク中のプロセッサによって前記インストラクションをインタープリートし、
前記 go オペレーションに応答して、エージェントプロセスがプレイスプロセスに転送され、前記エージェントプロセスが、前記エージェントクラスの1つのメンバであり、前記プレイスプロセスは前記プレイスクラスの1つのメンバであることを特徴とするコンピュータネットワークにおけるリモートプログラミングの実施方法。」(第1頁左欄2〜14行目)
1-2)「【請求項7】 前記プレイスプロセスをチケット手段によって指定することを特徴とすることを請求項第1項記載のリモートプログラミングの実施方法。
【請求項8】 前記チケット手段を前記エージェントプロセス内において形成することを特徴とする請求項第7項記載のリモートプログラミングの実施方法。
【請求項9】 前記チケット手段中において前記プレイスプロセスのアドレスを形成することを特徴とする請求項第7項記載のリモートプログラミングの実施方法。
【請求項10】 前記アドレスがテレアドレスであることを特徴とする請求項第9項記載のリモートプログラミングの実施方法。
【請求項11】 前記チケット手段中において前記プレイスプロセスのネームを形成することを特徴とする請求項第7項記載のリモートプログラミングの実施方法。
【請求項12】 前記ネームがテレネームであることを特徴とする請求項第11項記載のリモートプログラミングの実施方法。」(第1頁左欄36行目〜右欄3行目)
1-3)「【0001】
【産業上の利用分野】本発明は、リモートプログラミングの実施方法に関し、特に分散型計算環境であって、オブジェクト指向環境において複数のプロセスがつくり出され、コンピュータネットワークを通じてそれ自身の運動を差し向けるようにしたリモートプログラミングの実施方法等に関する。」(第11頁右欄32〜38行目)
1-4)「【0210】コンピュータプロセスのインストラクションは、データオブジェクトの定義、生成及び操作と、目的点のコンピュータシステムによって実行される他のコンピュータシステムとの相互作用とを含む複雑なオペレーションを遂行するために、目的点のコンピュータシステムによって実行される。コンピュータプロセスはネットワーク全体を通じて一様に解釈され、コンピュータシステムの間に転送されるようにエンコードされかつデコードされるので、本発明のコンピュータプロセス(複数)は、コンピュータ間の通信において新しいレベルの機能性及び多様性を供与する。
【0211】一実施例によれば、本発明のコンピュータインストラクションのセットに組み込まれた2つのクラスは、エージェントクラスとプレイスクラスである。エージェントクラスを用いて形成されたインストラクションは、エンジンによって解釈され、エージェントプロセス(本明細書中において単にエージェント)と呼ばれることもある。エージェントは、エージェントが生成されたときにエンジンがその実行を開始するという点でアクティブオブジェクトである。エージェントクラスは、エージェントが(i)それ自身を検査して変更し、(ii)ネットワーク中の以下にそれを詳細に説明する第1のプレイスプロセスから同じネットワーク中の第2のプレイスプロセスまでそれ自身を転送し、(iii)第2のプレイスプロセスに見出される他のエージェントと相互作用することを可能にするインストラクション(複数)を供与する。第1のプレイスプロセス及び第2のプレイスプロセスはネットワークの2つの別々のコンピュータシステム内において実行される。したがってあるエージェントは第1のコンピュータシステムから第2のコンピュータシステムに移動することができる。」(第25頁左欄45行目〜右欄25行目)
1-5)「【0416】エージェント(agent): エージェントは、あるプレイスをしめ、可動である、すなわち第1のプレイスから第2のプレイスに移動することのできるプロセスである。」(第38頁左欄29〜32行目)
1-6)「【0418】属性(attribute):属性は、あるオブジェクトの内部状態に関する情報を検索し又はセットするフィーチャである。通常情報はオブジェクト自身に所属するが、時には、情報は、属性を呼び出す際にオブジェクトを特定化するためのリフエランス(参照)に関する。属性は一対のオペレーションであり、一方のオペレーションはレスポンダの内部状態に関する情報をセットし他のオペレーションは、レスポンダの内部状態に関する情報を検索する。」(第38頁左欄40〜48行目)
1-7)「【0425】フィーチャ(feature):フィーチャはあるオブジェクトが遂行するように指示されることのできるタスクである。タスクは、一組のコンピュータインストラクションを含む方法によって遂行される。あるフィーチャの遂行は、そのフィーチャの方法のコンピュータ指令の実行によって達成される。あるフィーチャは、ある特定のオブジェクトのクラスと関係があり、あるフィーチャの遂行は、そのフィーチャを遂行するオブジェクトの特定的な内部状態と共に変化しうる。フィーチャは、概念的には、次の2つのカテゴリすなわち(i)属性及び(ii)オペレーションに分類される。」(第38頁右欄41行目〜第39頁左欄1行目)
1-8)「【0436】プレイス(place):プレイスは、ゼロ又はそれ以上の方法の場所(locale)であるプロセスである。あるプレイスは第2のプレイスを占有しうる。初めに述べたプレイスは、第2のプレイスのサブプレイスであり、第2のプレイスは第1のプレイスのスーパープレイスである。」(第39頁右欄11〜16行目)
1-9)「【0438】プロセス(process):プロセスは、自律的な計算を構成するオブジェクトである。プロセスは別のオブジェクトによってそのように要求されえることなしに方法を遂行するので、自律的である。あるプロセスは、そのプロセスの創設と共に中央方法の遂行を開始し、中央方法の完成と共にそのプロセスは破壊される。各々のオブジェクトは正確に1つの方法によって所有される。各々のプロセスはそれ自身によって所有される。この明細書で使用する”コンピュータプロセス”と言う用語は、より一般的な周知の定義である、コンピュータシステムによって遂行される一連のインストラクションを意味する。」(第39頁右欄21〜32行目)
1-10)「【0462】あるエージェントはそれ自身の運動をネットワークを通じて差し向けることすなわち転送することができるので、第1のコンピュータシステムから第2のコンピュータシステムへのトリップ(旅行)のある数のパラメータを特定するための手段を設けなければならない。この旅行の第1のパラメータは、エージェントがそれに向かって移送されるプレイスすなわち旅行の目的地である。一実施例によれば、トリップの目的値は、ネーム、クラス又はアドレスによって指定することができる。アドレスは一例としてローカルエリアネットワーク内のある番地(ロケーション)である。」(第42頁右欄41行目〜第43頁左欄1行目)
1-11)「【0466】一実施例によれば、チケット1306(図6)は、エージェント150Aの転送を制御し、目的プレイスとしてのプレイス220Bを特定する。」(第43頁左欄34〜36行目)
1-12)「チケット1306(図35)によって規定されたトリップの行程において、エージェント150(図34)は1つのエンジンから次のエンジンへと移送される。従って、”移送目的点”は1つのエンジンである。一般にトリップには、エージェントがトリップ目的点を含むエンジンに到達するまでにエージェントの何回かの転送を必要とすることが有り得る。」(第53頁左欄15〜21行目)
1-13)「【0544】エンジンを領域に分類することは、大型の複雑なネーットワークにおいてエージェントをルーティングする上に有用である。あるエージェントが複数の領域の間を移動する場合、移送目的エンジンについての情報をソースエンジンが有していることは不可欠ではない。どの領域にエージェントが移動しているかをソースエンジンが定めることができ、そしてそのエージェントをその領域内のあるエンジンに向かって移送させることができれば十分である。トリップの目的点であるプレイスを含む領域にエンジンが移送されたら、エージェントは一層容易にそのプリスを含むエンジンに向かってルーティングさせることができる。」(第53頁左欄45行目〜右欄6行目)
1-14)「【0669】オペレーション”send”
あるエージェントは、オペレーション”send”を遂行することによって同時にいくつかのプレイスに移行することができる。」(第70頁右欄30〜33行目)
1-15)「【1008】1.1 テレスクリプトインストラクションセット
ここに”インストラクションセット”としてときには呼ばれる、テレスクリプトインストラクションセットは、適用分野を分散型システム及びアプリケーションにしようとするプログラミング言語を集合的に形成するコンピュータインストラクションの組である。インストラクションセットは、オブジェクト指向でインタプリタされるものである。マイクロフィルムのアペンディックス E、Fにおいて、インストラクションセットはときには”言語”とも言われる。
【1009】インストラクションセットの中に組み込まれる最も顕著なクラスは、クラス”エージェント(Agent)”及び”プレイス(Place)”である。エージェント、すなわちクラス”エージェント”のメンバであるコンピュータプロセスは、それ自身を検査変更し、それ自身をネットワーク中の一方のプレイスから他方のプレイスに転送し、そしてそこに見い出される他のエージェントと相互作用することのできるアクティブなオブジェクトである。この能力は、特別な場合において特別なエージェントに対して特別な能力のみをプログラマまたは管理者のどちらか一方が許可できるようにする、パーミットによってバランスされる。プレイスすなわちクラス”プレイス”の一つのメンバであるコンピュータプロセスは、それ自身を検査変更することができ、エージェントに対する地域(venue)及びエージェントが相互作用するコンテキストとして取り扱う活動的なオブジェクトである。
【1010】あるエージェントは、あるプレイスに行き、そこでそのプレイス及びそのプレイスの他の占有者と相互作用する。エージェントとプレイスとはある距離をおいては相互作用できない。このようにリモートプログラミング(以下、単にRemote ProgrammingをRPという)を実行するインストラクションセットは、より親しみのあるリモートプロシージャコーリング(以下、単にRemote Procedure callingをRPC という)パラダイムを実行するのではない。RPは、可能なシステムの要素をコミュニケーションなしに相互作用させることによってRPC を改善し、その待ち時間(latency )を減少させることによって相互作用の兼ね合いを改善する。等価的には、RPは、システムの要素が、他の領域内に存在するそれ自身のエージェント-そしてこのようにそれら自身-によって他のものをあつらえる。」(第115頁左欄3〜45行目)
したがってこれら記載事項によると、引用例1には、
「複数のプレイスプロセスに対して転送されるエージェントをルーティングする方法であって、
a)目的とするプレイスプロセスを指定するネーム(名前)を決定するステップと、
b)前記ネーム(名前)によって特定される1つまたは複数のプレイスをシステムの構成に応じて選択して取得するステップと、
c)前記プレイスプロセスを実行するために選択されたプレイスへ1つのエージェントを相互作用させるステップと、
を含む方法。」
の発明(以下「引用例1に記載の発明」という。)が記載されている。

2)また、原査定の拒絶の理由に引用された、特開平8-249290号公報(以下、「引用例2」という。)には、図面とともに、次の事項が記載されている。
2-1)「【0031】ネットワーク上に複数個のコンピュータが接続された分散システムであって、アプリケーションプログラム間連携処理に関わる個々のアプリケーションプログラム本体にアプリケーションプログラム間連携処理手続きを実行するための連携インタフェースを付与したサービスエンティティと、連携させるサービスエンティティ間の移動先を表す利用順序とサービスエンティティの利用手続きを有するサービスエージェントと、サービスエージェントをそれが有する利用順序に記述された移動先に移動させる通信路を生成、維持、管理するルーティングマネージャとを備える。」(第5頁左欄21〜31行目)
2-2)「【0034】そのルーティングマネージャは、コンピュータ起動時に他のコンピュータと通信するための論理的な通信路を確立する論理的通信路確立手段と、他のコンピュータとの間の該論理的通信路を切り放す手段と、他のコンピュータからの接続要求を受け取る手段と、ルーティングマネージャを停止させることなく、任意のコンピュータ間で論理的通信路の接続先コンピュータを変更する手段と、該ルーティングマネージャの動作するコンピュータ上で動作するサービスエンティティを管理する手段と、受信したサービスエージェントの要求するサービスエンティティの名称を取得して、該ルーティングマネージャの動作するコンピュータ上で動作するサービスエンティティと該サービスエージェントが要求するサービスエンティティの名称を比較し、該コンピュータ上で該サービスエージェントが要求するサービスエンティティが実行できるか否かを判定する手段と、該サービスエージェントの要求するサービスエンティティが実行できない場合には、論理的に接続された他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる手段と、該サービスエージェントの要求するサービスエンティティが実行できる場合には、該サービスエンティティに該サービスエージェントを移動させる手段とを備える。」(第5頁右欄7〜29行目)
2-3)「【0103】接続要求プログラム42は、管理テーブル作成プログラム41により処理装置16のメモリ15上に作成された接続先管理テーブル46に格納されたコンピュータ名の一覧の先頭から順に接続先コンピュータ名を取得し、その接続先コンピュータに対して接続を要求する。
【0104】接続ができない場合には、次の接続先コンピュータ名を取得し、接続ができるまで順次接続要求を行う。
【0105】また、接続先管理テーブルに格納された接続先コンピュータ名がなくなるまで、順次、接続要求を行っても接続できない場合、エラーメッセージを出力し、処理を終了する。」(第10頁左欄19〜31行目)
したがってこれら記載事項から、引用例2には、「ネットワーク上に複数個のコンピュータが接続された分散システムにおいて、サービスエージェントが要求するサービスエンティティをルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には、他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる」技術が記載されている。

(3)対比
そこで、本件補正発明(以下、「前者」という。)と引用例1に記載の発明(以下、「後者」という。)とを対比すると、
イ)後者の「プレイスプロセス」は、上記(2)の1-9)で示した「プロセス」に関する説明記載から、前者の「実行可能ユニット」に相当する。
ロ)後者の「エージェント」は、コンピュータネットワーク中を移動するものであるから、前者の「移動エージェント」に相当する。
ハ)前者の「実行可能ユニットの論理要件を指定する」ことは、目的対象とする要件を備えた「実行可能ユニット」を指定することと認められ、一方、後者の「目的とするプレイスプロセスを指定する」ことも、「プレイスプロセス」が有する要件をその目的対象として指定することであるから、後者の「目的とするプレイスプロセスを指定する」は、前者の「実行可能ユニットの論理要件を指定する」に相当する。
二)後者の「プレイス」は、前者の「目標ロケーション」に相当する。
ホ)後者の「1つまたは複数のプレイス」が「ネーム(名前)」「によって特定される」ことは、該「1つまたは複数のプレイス」が該「ネーム(名前)」の関数という形で表されることを意味することは明らかであるから、後者の「前記ネーム(名前)によって特定される1つまたは複数のプレイス」は、前者の「前記名前の関数としての1つまたは複数の目標ロケーション」に相当する。
へ)後者の「相互作用させる」ことは、上記(2)の1-4)、及び1-15)の記載内容より、移動したエージェントが他のコンピュータシステムで実行されることを意味することと解されるから、前者の「ディスパッチする」ことに相当する。
したがって、両者は、
「複数の実行可能ユニットを含む移動エージェントをルーティングする方法であって、
a)実行可能ユニットの論理要件を指定する名前を決定するステップと、
b)前記名前の関数としての1つまたは複数の目標ロケーションをシステムの構成に応じて選択して取得するステップと、
c)前記実行可能ユニットを実行するために選択された目標ロケーションへ1つの移動エージェントをディスパッチするステップと、
を含む方法。」
である点において一致し、次の点で相違する。
i)「実行可能ユニットの論理要件を指定する」ために「決定する」ものが、前者は「名前および属性」であるのに対し、後者は、「名前」である点、
ii)「1つまたは複数の目標ロケーションを」「選択して取得する」ことを、前者では、「システムの動的構成に応じて」行うことにより「移動エージェントを動的にルーティングする」のに対し、後者では、「システムの構成に応じて」が「動的」か否か明らかでなく、よって「移動エージェントをルーティングする」ことが「動的」か否かについて記載がない点。

(4)相違点に対する判断
次に、相違点について以下に検討する。
A)相違点i)について
前者でいう「属性」の意味するところは、本願明細書によれば、「マシン・アーキテクチャ・タイプや負荷標識などの」、サポート対象とするコンポーネントの機能を記述するものと解されるが(発明の詳細な説明【0018】)、情報処理分野においては、ハードウェア等を構成するコンポーネント(要素)を指定する際に、そのコンポーネント(要素)の属性を用いることは慣用の手法に過ぎない。
また、(2)の1-6)で示したように、後者でも「属性」について定義がなされており、後者において、「実行可能ユニットの論理要件」を指定する際に、「名前」のみではなく、「属性」も指定可能とし、前者のように「名前および属性を決定する」ことは、当業者ならば適宜に採用し得る設計的事項であると認められ、当該相違点は格別のものではない。

B)相違点ii)について
上記(2)の2)で示した、引用例2に記載の「ネットワーク上に複数個のコンピュータが接続された分散システムにおいて、サービスエージェントが要求するサービスエンティティをルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には、他のコンピュータ上で動作しているルーティングマネージャに該サービスエージェントを移動させる」技術は、移動するサービスエージェントに対して、ルーティングマネージャの動作するコンピュータで実行できるか否か判定し、実行できない場合には動的にルーティングさせていることから、システムの動的構成に応じて目標コンピュータを選択していることに相当するものと認められる。
ここで、当該引用例2に記載の技術が、本願補正発明が課題としているような、コンポーネント・ホストの障害、過負荷、属性の変更といった動的な変化に対応できるものであるかについては明記されていないので、以下に検討を加える。
一般に、ネットワーク上のエージェントに関する技術分野において、端末やサーバといったリソースの障害や負荷などの状況、構成変更に応じて動的にルーティングを行う、換言すれば、本願補正発明のように、システムの動的構成に応じて目標とする端末やサーバといった実行可能ユニットを選択取得する技術は、周知の技術である。当該周知の技術を裏付ける文献としては、例えば、以下のものを掲げることができる。

B-1)周知文献A:
電子情報通信学会技術研究報告 Vol.95 No.215 (1995-8-24) p.33-38
「パーソナルエージェントに基づく通信網DUETの試作」
特に、5-2.(p.36)には、
「サービスを実行する際、PA間でのメッセージ転送、PAと既存網制御部(リソースマネージャ)との間のメッセ一ジ転送が行われる。
PAの位置や端末の位置を意識することなくPAから制御可能とする為に、メッセージのルーティング機構が必要である。
また、端末の空塞状態やエリアに誰がいてどの端末が使用可能かといった動的に変化する情報の管理も必要である。
DUETでは、ルーティング機構とデータベース機能を合わせ持つDOP(Distributed Object Pool)によりこれらの機能を実現した。」
と記載されており、システムの動的変更に対応するルーティングに関する技術が示されている。

B-2)周知文献B:
日経コンピュータ No.393 (1996-6-10) 日経BP社 p.122-132
「ネットワーク・エージェント」
特に、日本ユニシスSYSTEMνの分散オブジェクト技術について、
「TAは各サーバー上に常駐して,クライアントやサーバーのオブジェクトの位置を分散管理する。TAがオブジェクト間でメッセージ授受を仲介するのに最適なルートを自動的に決める。あるサーバーに障害が発生した際には,自動的にそのサーバーをう回してメッセージをやり取りする機能も提供する。」(p.130)
「図6●日本ユニシスのクライアント/サーバー型システム開発・実行環境SYSTEMν(ニュ-)の構成。オブジェクトの場所を示すディレクトリ管理テーブルを各サーバー上のトランスファ・エージェント(TA)が分散管理するので特定の管理サーバーに負荷が集中しない」(p.128)
と記載されており、サーバーの障害等に対応した動的ルーティングの技術が示されている。

B-3)周知文献C:
電子情報通信学会1997年総合大会講演論文集 情報・システム1
(1997-3-27) p.208
D-9-15 「分散マルチメディアDBの仮想データベース化と検索制御技術」
「2.1」には、「ユーザ/端末は論理データベースの窓口Retrieval Managerに対して検索要求を出す(このとき各分散データベースの位置情報は流通しない)。要求を受けた論理データベースはその時点の状況(ネットワーク状態、サーバ状態など)により各データベースへの検索パスやデータ送出サーバ(Contents Server)などを動的に構成し、並列処理する。データ送出サーバはコンテンツデータを他のサーバを経由せずに端末に直接送出する。
このモデルを適用することによって、前述の1.,2.のような問題は発生しない。分散構造変更時には、Directory Serverに格納されているディレクトリ情報(サーバアドレスなどの位置情報)を書き換えるだけでよく、ユーザ操作の変更、端末処理の変更、データベース間のリンク構造の変更などは必要ないため、常に最適な分散構造に維持可能である柔軟なシステムを実現でき、性能上も有利である。
このモデルはエージェントシステムの1形式といえるであろう。」
と記載されており、システムの動的な構成に対応してサーバを選択する分散システムの技術が示されている。

してみれば、後者の「1つまたは複数の目標ロケーションをシステムの構成に応じて選択して取得するステップ」において、引用例2に記載の技術及び上述した周知の技術を適用して、前者のように「1つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップ」とし、「移動エージェントを動的にルーティングする」ことは、当業者が容易に想到し得ることであり、当該相違点は格別のものとは認められない。

そして、本願補正発明の作用効果も、引用例1、引用例2及び上述した周知の技術から、当業者が予測できる範囲のものである。
したがって、本願補正発明は、引用例1に記載の発明、引用例2に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。

(5)むすび
以上のとおり、本件補正は、特許法第17条の2第5項において準用する同法第126条第4項の規定に違反するものであり、特許法第159条第1項において準用する同法第53条第1項の規定により却下されるべきものである。


3.本願発明について
平成12年9月18日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、同項記載の発明を「本願発明」という。)は、平成12年2月28日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。
「複数の実行可能ユニットを含む移動エージェントを動的にルーティングする方法であって、
a)実行可能ユニットの論理要件を指定する名前および属性を決定するステップと、
b)前記名前および前記属性の関数としての1つまたは複数の目標ロケーションをシステムの動的構成に応じて取得するステップと、
c)前記実行可能ユニットを実行するために選択された目標ロケーションへエージェントをディスパッチするステップと、
を含む方法。」

(1)引用例
原査定の拒絶の理由に引用された引用例、および、その記載事項は、上記2.(2)に記載したとおりのものである。

(2)対比・判断
本願発明は、上記2.で検討した本願補正発明から、「b)前記名前および前記属性の関数としての1つまたは複数の目標ロケーションをシステムの動的構成に応じて選択して取得するステップ」における限定事項である「選択して」の構成を省き、「c)前記実行可能ユニットを実行するために選択された目標ロケーションへ1つの移動エージェントをディスパッチするステップ」における限定事項である「1つの移動エージェント」を「エージェント」とするものである。
そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記2.(4)に記載したとおり、引用例1に記載の発明、引用例2に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例1に記載の発明、引用例2に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものである。

(3)むすび
以上のとおり、本願発明は、引用例1に記載の発明、引用例2に記載の技術、及び、上述した周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2005-03-08 
結審通知日 2005-03-15 
審決日 2005-03-28 
出願番号 特願平10-110585
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 石井 茂和  
特許庁審判長 岩崎 伸二
特許庁審判官 竹中 辰利
篠原 功一
発明の名称 動的移動エージェント  
復代理人 間山 進也  
代理人 市位 嘉宏  
代理人 坂口 博  

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