【事件の表示】
　平成１１年特許願第１６５５６８号「ネットワークデバイス探索装置およびその方法、記憶媒体」拒絶査定不服審判事件〔平成１２年１２月１９日出願公開、特開２０００−３５３１３６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は平成１１年６月１１日の出願であって、平成１６年１０月２９日付けで拒絶査定がなされ、これに対して平成１６年１２月６日に拒絶査定に対する審判が請求されるとともに、平成１７年１月５日付けで手続補正がなされたものである。
　
２．平成１７年１月５日付け手続補正について
［補正却下の決定の結論］
　　平成１７年１月５日付け手続補正（以下「本件補正」という。）を却下する。
［理由］
　補正後の本願発明
　本件補正により、補正前の特許請求の範囲の請求項４は補正後の請求項１として次のとおり補正された。
「ネットワークデバイスを探索するネットワークデバイス探索方法であって、
　クライアントからの探索を指示する探索コマンドを受け付けるコマンド受付けステップと、
　前記探索コマンドを送信したクライアントのアドレスを取得するアドレス取得ステップと、
　前記アドレス取得ステップで取得されたアドレスをメモリに格納するアドレス格納ステップと、
　前記探索コマンドに応じて、ネットワークデバイスを探索するためのローカルブロードキャストパケットを送信するブロードキャストパケット送信ステップと、
　前記ローカルブロードキャストパケットに応答してネットワークデバイスが送信する応答パケットを受信する応答パケット受信ステップと、
　前記応答パケット受信ステップで受信された応答パケットから、当該応答パケットを送信したネットワークデバイスに関する情報を取得するデバイス情報取得ステップと、
　前記ローカルブロードキャストパケットの送信により、前記ネットワークデバイスが応答を返す締め切り時間をカウントするタイマーを起動し、当該ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、前記アドレス格納ステップでメモリに格納されたアドレスに従って、前記デバイス情報取得ステップで取得されたネットワークデバイスに関する情報を前記クライアントに通知する探索結果通知ステップと、 
　を有することを特徴とするネットワークデバイス探索方法。」
　
　上記補正は、補正前の請求項４に記載した発明を特定するために必要な事項である「探索結果通知ステップ」に関し、「ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、」とあるのを「前記ローカルブロードキャストパケットの送信により、前記ネットワークデバイスが応答を返す締め切り時間をカウントするタイマーを起動し、当該ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、」と限定するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（１）引用刊行物
　原査定の拒絶の理由に引用された、本願の出願日前に頒布された刊行物「特開平８−２６５３６７号公報」（以下「引用刊行物」という。）には、図面とともに以下の記載がある。
（イ）「【０００１】
【産業上の利用分野】本発明は、回線網に収容された情報処理機器や通信機器で構成されたネットワークの管理を行う方式に関し、特に、管理ノードにより被管理ノードから被管理ノードに繋がる装置の管理情報を収集するネットワーク管理・情報収集方式に関する。
【０００２】
【従来の技術】従来のＷＡＮ（広域ネットワーク）／ＬＡＮ（ローカルネットワーク）等のネットワークにおける基本的な保守情報等の情報収集方式を図１８及び図１９を用いて説明する。
【０００３】図１８において、２００は、ネットワーク（回線網）であり管理ノード１００及び複数の被管理ノード３００（図では、説明を簡略にするために一の被管理ノードのみ示されている）が収容されている。また、被管理ノード３００には、複数の監視対象装置３１０が接続されている（図において、同様に一の監視対象装置のみ示されている）。
【０００４】ここで、管理ノード１００から被管理ノード３００に管理情報の問い合わせを指示するデータ（例えば、ＱX インタフェースではｍ−ＧＥＴに相当し、以下問い合わせパケットＩＰと呼ぶ）を送る。
【０００５】上記問い合わせパケットＩＰには、図１９に示すように、管理の対象となる装置３１０の名前ａ（以下管理対象名称と呼ぶ）、当該装置３１０の中で収集対象となる情報の名前ｂ（以下属性名称と呼ぶ）、問い合わせパケットＩＰ自身の識別子ｃ（以下インボーグＩＤと呼ぶ）等を含む。
【０００６】上記問い合わせパケットＩＰを受信した被管理ノード３００は、パケット内の装置名称ａ／属性名称ｂに対応する情報（以下属性値と呼ぶ）を収集し、パケット内のインボーグＩＤと収集した時間ｄ（以下現在時刻と呼ぶ）を付与してデータを編集する。
【０００７】編集したデータを問い合わせパケットに対する応答として回線網２００を介して管理ノード１００に送る（以下、応答として送られるデータを応答パケットＲＰと呼ぶ。）
上記応答パケットＲＰを受信した管理ノード１００は、インボーグＩＤによりどの問い合わせパケットに対応するのかを判別し、所定の位置（例えば補助記憶装置）に属性値を格納する。以上のようにして情報収集が完了する。
【０００８】尚、管理の対象となる装置３１０としては、通信制御装置の如き周辺装置から被管理ノード内のＣＰＵ、プリンタ装置等も含まれる。」（第３頁）
　
（ロ）「【００１５】
【発明が解決しようとする課題】上記した各方式に基づいて管理情報の収集を行った場合、例えば管理ノードのアプリケーション利用者から「一定時間例えば、１０秒間隔で周期的に、適当な時間の間中、情報を取得して欲しい」という要求が発生するものとすると、ネットワーク内の負荷状態に関係なく周期的に管理ノード１００から問い合わせパケットＩＰとそれに対する応答パケットＲＰが被管理ノード３００から発生することになる。
【００１６】また、ＱX インタフェースでは、ｍ−Ｌｉｎｋｅｄ−Ｒｅｐｌｙというプロトコルを用いて応答の中間／最終を指定し、再度の問い合わせを省略するインタフェースが存在する。しかし、それでも収集回数分の応答パケットＲＰが発生してしまう。
【００１７】更に、上記のアプリケーション利用者の要求における問い合わせ先が複数となった場合（以下これを、ブロードキャストと呼ぶ）、問い合わせパケットＩＰとそれに対する応答パケットＲＰが、上記の周期に合わせて集中してネットワークの中に流れ込んでしまうという問題がある。
【００１８】かかる場合は、ネットワーク負荷が増大し、これに伴い、他の通信が遅延する等の悪影響が生じる。
【００１９】本発明は、上記の従来の問題点を解消するネットワーク管理・情報収集方式を提供することを目的とする。」（第４頁）
　
（ハ）「【００２０】
【課題を解決するための手段及び作用】したがって、上記目的を達成するために、本発明にしたがうネットワーク管理・情報収集方式は、管理ノード１００において、適当な蓄積回数を指定して問い合わせパケットを送信し、被管理ノード３００は、指定された時間間隔で上記の蓄積回数分情報を収集した後、収集した情報を一つの応答パケットにまとめて管理ノードに送信する。
【００２１】かかる方式により応答パケットの数を減らすことができ、集中してネットワークの中に流れ込んでしまうという問題が解決できる。
【００２２】更に、本発明にしたがうネットワーク管理・情報収集方式は、被管理ノードが、蓄積した情報を応答パケットにまとめる時に、連続して同じ属性値のデータが並んでいる場合にはその２つ目以降の属性値は削除して応答パケットを編集し、応答パケットを受け取った管理ノードは属性値に付与されている現在時刻を参照して削除された情報を復元する。
【００２３】これにより、ネットワークに流れるデータ量を縮小化できる。
【００２４】また、本発明にしたがうネットワーク管理・情報収集方式は、被管理ノードが、事前に自分で使っているネットワーク機器の負荷状態を監視して、応答パケット送信時に負荷が高い場合には編集を延期し、負荷が下がるまで蓄積を続け、下がった時点で編集し直して管理ノードへの応答パケットの送信を行う様にする。
【００２５】これにより、ネットワークに流れるデータ量を縮小化でき、更にネットワーク負荷の集中を回避することが出来る。
【００２６】更にまた本発明にしたがうネットワーク管理・情報収集方式は、前記課題で挙げたブロードキャストの問い合わせ要求に対して、管理ノードは、上記手段における蓄積回数に問い合わせ先毎に違った値を設定する。
【００２７】これにより問い合わせパケットを送信することにより、被管理ノードからの応答パケットが送られてくる時刻を適当に分散させることが出来る。
【００２８】更に、本発明にしたがうネットワーク管理・情報収集方式は、適当な分散の中で同時に応答パケットを送信する被管理ノードの組について、問い合わせパケットを被管理ノード同士の間で送受信し、続いて応答パケットも問い合わせパケットを伝達した被管理ノード同士で送受信して、各自の蓄積した情報を順次付加し、一番最後の被管理ノードからの応答パケットのみ、管理ノードへ送信する。
【００２９】これにより、管理ノードに送られてくる応答パケットの集中を回避することができる。」（第４頁）
　
（ニ）「【００３０】
【実施例】以下図面にしたがい本発明の好適な実施例を説明する。尚、図において同一または類似のものには同一の参照番号及び記号を付して説明する。
［実施例構成ブロック図の説明］図１は、本発明が適用されるネットワーク構成の一例のブロック図である。一つの管理ノード１００と、これに対応する複数（図では４つが示される）の被管理ノード３０１〜３０４がネットワーク２００に収容されている。更に、被管理ノード３０１〜３０４の各々には、複数の管理対象装置３１０〜３１７が繋がっている。
【００３１】管理ノード１００は、そのモジュール構成例が図２に示すごとくである。各被管理ノード３００（以下、図１の被管理ノード３０１〜３０４を代表して必要により参照数字３００で表す）は、図３に示すモジュール構成例を有するものである。
【００３２】図１に戻ると、被管理ノード３０１〜３０４の内、被管理ノード３０３と被管理ノード３０４は、条件によって呼４３４により論理的に接続されることを示している。即ち、後述する群管理制御により、呼４３４により論理的に接続されるように示されている。尚、４つの被管理ノード３０１〜３０４の内、２つのみ接続される状態は、本実施例ではありえないが、簡単化のため上記のような構成にして示している。
【００３３】図２と図３においては、管理ノード１００も被管理ノード３００も、それぞれソフトウェア・システム４００／４１０とタイマ１２０／３２０とメモリ１３０／３３０と、それらを繋ぐ伝送路１７０／３７０から構成される。
【００３４】この伝送路１７０／３７０によって、外付けの補助記憶装置１４０／３４０と繋がり、特に被管理ノード３００の場合は、対応する管理対象装置３１０〜３１７に接続される通信路５００に繋がっていることを示している。」（第４〜５頁）
　
（ホ）「【００３６】図２の例では、管理ノード１００はソフトウェア・システム４００の中にアプリケーション利用者１１０を有しており、上記管理ノード１００に対して外から要求が発せられることを示している。
【００３７】尚、実際のアプリケーション利用者１１０はＷＳ端末やコンソール端末に接続され、上記管理ノードをアクセスしながらメッセージの入出力を行うことが容易に想定される。」（第５頁）
　
（ヘ）「【００６２】＊：管理ノード１００は、応答パケットから被管理ノード３０５での作業の結果を取り出し、被管理ノード一覧ファイル１４２に反映して呼４０５を開放切断する（ステップＳ４）。
（３）一つの被管理ノードに収集を依頼する時のプロトコル：図７は、上記（１）管理開始時の情報分配処理のプロトコル：で示したプロトコルのフローによって図１のネットワーク構成が形成された後、アプリケーション利用者１１０より被管理ノード３０１で管理している装置の情報を収集するように依頼される時の管理ノード１００と被管理ノード３０１との間で行われるデータ送受信の様子を示すものである。
【００６３】＊：管理ノード１００の中で、要求管理モジュール１６１はアプリケーション利用者１１０から情報収集の要求を受け付けると、既に処理中になっている収集要求のスケジュールを確認する。
【００６４】被管理ノード一覧情報ファイル１４２の情報の一部を、メモリ１３０から切り出した領域１３１に展開した後、スケジューリングモジュール１６３に被管理ノード３０１のアクセスとなる契機の計算を依頼する（ステップＳ５）。
【００６５】スケジューリングモジュール１６３は、定義ファイル１４１を読み込み、その中の情報とアプリケーション利用者１１０から与えられた収集回数／収集間隔／応答許容時間をパラメータにして以下の値を計算する。
【００６６】ａ）問い合わせ数：被管理ノードに問い合わせパケットを送信する回数
ｂ）最終蓄積回数：最後の、問い合わせの応答で、被管理ノードから一度に渡してもらう情報の収集回数
ｃ）中間蓄積回数：最終以外の問い合わせの応答で、被管理ノードから一度に渡してもらう情報の収集回数
尚、これらの計算方法については、後に説明する。
【００６７】上記の値を算出後、メモリ領域１３１に展開されたテーブルに出力値を書き込み、要求管理モジュール１６１に制御を戻す。
【００６８】要求管理モジュール１６１は、返却された上記ｃ）の情報とアプリケーション利用者１１０から渡された収集間隔とを操作値＝Ｙの問い合わせパケット６２１１に展開して、装置を管理している被管理ノード３０１へ送信する（ステップＳ６）。
【００６９】＊：問い合わせパケット６２１１を受けた被管理ノード３０１では、要求受付けモジュール３６１が、補助記憶装置３４０に蓄積情報ファイル３４１を作成し、管理対象管理モジュール３６４に、対応する管理対象装置の属性値の収集を依頼する（ステップＳ７）。
【００７０】管理対象モジュール３６４から情報を受け取ると要求受付モジュール３６１は、上記で作成した蓄積情報ファイル３４１に現時刻と受け取った情報を書き込む。ついで、時計管理モジュール３６３に上記の問い合わせパケット６２１１に入っていた収集間隔で周期的に通知する様に依頼する。
【００７１】これに応じて、時計管理モジュール３６３がタイマ３２０を使用して周期的な通知を行い、要求受付モジュール３６１は管理対象管理モジュール３６４に、対応する管理対象装置の属性値の収集を、再度依頼する。
【００７２】管理対象管理モジュール３６４から収集情報を受け取ると、前回に収集した属性と比較して、違う値の場合には、蓄積情報ファイル３４１に現時刻と受け取った情報を追加して書き込みを行う。
【００７３】以上の処理を繰り返し、上記の蓄積回数分〔元は上記ｃ）の値〕の管理対象管理モジュール３６４に対する要求を終わる。そして、要求受付モジュール３６１は、次に管理対象管理モジュール３６４に、通信制御モジュール３５０の負荷状態の情報収集を依頼する。
【００７４】この負荷状態の値は、ＬＡＮの場合は衝突頻度、ＷＡＮの場合はフロー制御パケットの返却時間が反映される。負荷状態の値が、一定基準値（プログラム内に静的に保持される値）より高い場合は、応答パケットの送信を延期して、再度時計管理モジュール３６３からの情報収集のタイムアウト待ちを行う（ステップＳ７）。
【００７５】負荷が無いと判断した場合は、応答パケット６２１１に、蓄積情報ファイル３４１０内の情報の全てと現在の時刻を展開して、管理ノード１００へ送信し、時計管理モジュール３６３に対しては、上記により依頼していた周期的な通知を終了する様に依頼する（ステップＳ８）。」（第６〜７頁）
　
（ト）「【００８２】以上の処理の繰り返し終了後、管理ノード１００では、要求管理モジュール１６１が呼４０１を解放して処理を終了する（ステップＳ１２）。
（４）複数の被管理ノードに収集を依頼する時のプロトコル（要求受付時）：図８、図９は、（１）管理開始時の情報分配処理のプロトコル：で説明したフローによって図１のネットワーク構成が形成された後に、アプリケーション利用者１１０により各被管理ノード３０１〜３０４で管理している対象装置の情報を収集するよう依頼された時の、管理ノード１００と各被管理ノードとの間で行われるデータ送受信の様子を示したものである。尚、図面の大きさの関係で、フローを図８と図９に分割して示している。
【００８３】＊：管理ノード１００の中で、要求管理モジュール１６１はアプリケーション利用者１１０から情報収集の要求を受け付けると、上記（３）一つの被管理ノードに収集を依頼する時のプロトコル：の場合と全く同様にして、既に処理中になっている収集要求のスケジュールの確認、被管理ノード一覧情報ファイル１４２の情報の一部のメモリ領域１３１への展開、スケジューリングモジュール１６３に被管理ノードへのアクセス契機計算の依頼を行う（ステップＳ１３）。」（第７〜８頁）
　
（チ）「【０１８５】
【発明の効果】以上実施例にしたがい説明したように、本発明は、基本的構成として管理ノード１００において、適当な蓄積回数を指定して問い合わせパケットを送信し、被管理ノード３００は、指定された時間間隔で上記の蓄積回数分情報を収集した後、収集した情報を一つの応答パケットにまとめて管理ノードに送信するようにしている。
【０１８６】したがって、かかる構成によりネットワーク上を流れるパケット数の削減、ネットワーク上を流れるデータ量の削減更に、ネットワーク上の負荷の分散を図るネットワーク管理・情報収集方式が提供可能である。
【０１８７】また、上記実施例は、本発明の説明のためのものであり、本発明はかかる実施例に限定されるものではない。本発明の範囲は、特許請求の範囲の記載に基づき定められ、特許請求の範囲に記載のものと均等の範囲にあるものでは、本発明の保護の範囲に含まれるものである。」（第１３頁）
　
　これら引用刊行物の記載から、引用刊行物には以下の発明（以下、「引用発明」という。）が記載されているものと認められる。
「複数の被管理ノードがネットワークを介して管理ノードに接続され、被管理ノードは通信路を介して複数の管理対象装置に接続され、管理ノードにより被管理ノードから被管理ノードに繋がる管理対象装置の管理情報を収集するネットワーク管理・情報収集方式に関し、
　管理ノードは被管理ノードに情報収集を要求し、
　被管理ノードは管理ノードからの前記情報収集の要求を受け付け、
　被管理ノードは管理対象装置の属性値の収集を行い、
　被管理ノードは管理対象装置の属性値を前回に収集した属性値と比較して蓄積情報ファイルに蓄積し、
　被管理ノードは所定回数の属性値の収集が終了すると、ネットワークの負荷が一定基準値以下の場合に管理ノードに蓄積情報ファイル内の情報を展開した応答パケットを送信する、
　ネットワーク管理・情報収集方式。」
　
（２）対比
　本願補正発明と引用発明を対比すると、
　引用発明の「管理対象装置」、「管理対象装置の属性値」、及び「管理ノード」は、それぞれ、本願補正発明の「ネットワークデバイス」、「ネットワークデバイスに関する情報」、及び「クライアント」に相当する。
　引用発明は、クライアント（管理ノード）が被管理ノードに対して情報収集を要求し、被管理ノードがクライアント（管理ノード）からの情報収集の要求を受け付け、ネットワークデバイスに関する情報（管理対象装置の属性値）を収集してるのに対して、本願補正発明において、クライアントからの探索を指示する探索コマンドに応じて、ローカルブロードキャストパケットが送信され、ネットワークデバイスからネットワークデバイスに関する情報が送信され、クライアントに探索結果として通知されるから、引用発明の「情報収集」と本願補正発明の「探索」とはネットワークデバイスに関する「情報収集」という点で共通するものであり、「情報収集の要求」は、本願補正発明の探索「コマンド」に相当し、引用発明が「情報収集の要求を受け付ける」ことは、本願補正発明の、探索コマンドを受け付ける「コマンド受付ステップ」に相当する。
　また、引用発明は、被管理装置が被管理装置に繋がるネットワークデバイスに関する情報の収集を行っており、引用発明において情報の収集を行うために送信を行い、ネットワークデバイスからの応答を受信していることは明らかであるから、引用発明は本願補正発明の「ネットワークデバイスを探索するための送信ステップ」と「ネットワークデバイスが送信する応答を受信する応答受信ステップ」に相当するステップを有している。
　また、引用発明の被管理ノードはネットワークデバイスからの応答を受信してネットワークデバイスに関する情報を前回の情報と比較して蓄積しているから、引用発明は本願補正発明の、送信したネットワークデバイスに関する情報を取得する「デバイス情報取得ステップ」に相当するステップを有している。
　また、引用発明の、クライアントに蓄積情報ファイル内の情報を展開した応答パケットを送信することは、本願補正発明の「探索結果通知ステップ」に相当する。
　また、引用発明の「ネットワーク管理・情報収集方式」は、本願補正発明の「ネットワークデバイス探索方法」と、「ネットワークデバイス情報収集方法」である点で一致する。
　
　したがって、両者は
「ネットワークデバイスの情報を収集するネットワークデバイス情報収集方法であって、
　クライアントからの情報収集を指示するコマンドを受け付けるコマンド受付けステップと、
　前記コマンドに応じて、ネットワークデバイスの情報を収集するための送信をする送信ステップと、
　前記送信に応答してネットワークデバイスが送信する応答を受信する応答受信ステップと、
　前記応答受信ステップで受信された応答から、当該応答を送信したネットワークデバイスに関する情報を取得するデバイス情報取得ステップと、
　前記送信により、前記デバイス情報取得ステップで取得されたネットワークデバイスに関する情報を前記クライアントに通知する結果通知ステップと、 
　を有することを特徴とするネットワークデバイス情報収集方法。」の点で一致し、以下の点で相違している。
　
相違点１
　本願補正発明は、コマンドを送信したクライアントのアドレスを取得するアドレス取得ステップと、アドレス取得ステップで取得されたアドレスをメモリに格納するアドレス格納ステップとを有しており、結果通知ステップにおいて、当該アドレスに従って通知を行っているのに対して、引用発明では、クライアントのアドレスについて記載がない点。
　
相違点２
　本願補正発明は、ネットワークデバイスを探索するネットワークデバイス探索方法であって、クライアントからの探索を指示する探索コマンドを受け付けるコマンド受付ステップ、ネットワークデバイスを探索するためのローカルブロードキャストパケットを送信するブロードキャストパケット送信ステップ、探索結果通知ステップを有しているのに対して、引用発明は、クライアントからの情報収集を指示するコマンドを受け付けるコマンド受付けステップ、被管理装置から被管理装置に繋がるネットワークデバイスの情報を取得するための送信ステップ、ネットワークデバイスに関する情報をクライアントに通知する通知ステップを有しているが、被管理装置がローカルブロードキャストパケットを送信しているのかどうか明らかではなく、引用発明はネットワークデバイスの情報を収集する、ネットワークデバイス情報収集方法である点。
　
相違点３
　本願補正発明では、受信ステップはネットワークデバイスが送信する応答パケットを受信し、デバイス情報取得ステップは、応答パケットから当該応答パケットを送信したネットワークデバイスに関する情報を取得しているのに対して、引用発明では、応答が応答パケットであるのかどうか明らかではない点。
　
相違点４
　本願補正発明の探索結果通知ステップは、ローカルブロードキャストパケットの送信により、前記ネットワークデバイスが応答を返す締め切り時間をカウントするタイマーを起動し、当該ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、前記アドレス格納ステップでメモリに格納されたアドレスに従って、前記デバイス情報取得ステップで取得されたネットワークデバイスに関する情報を前記クライアントに通知しているのに対し、引用発明では、所定回数の属性値の収集が終了すると、ネットワークの負荷が一定基準値以下の場合にクライアントに応答パケットを送信している点。
　
（３）当審の判断
　以下、上記相違点について検討する。
相違点１について
　ネットワークにおいて所定の装置から情報の送信を依頼された場合に、当該装置のアドレスを取得して記憶し、当該記憶したアドレスに従って情報を送信することは周知であって、格別のことではないから、引用発明においてこの周知技術を適用して、コマンドを送信したクライアントのアドレスを取得するアドレス取得ステップと、取得されたアドレスをメモリに格納するアドレス格納ステップとを設けて本願補正発明のように構成することに格別の困難性はない。
　
相違点２について
　引用刊行物（記載事項（ロ）、【発明が解決しようとする課題】の項の段落【００１７】）には、クライアントからの問い合わせ先が複数になった場合を「ブロードキャスト」と呼ぶことが記載され、本願明細書にも従来例（段落【００６８】等）として記載され、特開平１０−１２４４２６号公報（以下、「周知刊行物１」という。）の【発明が解決しようとする課題】のすでに開発されている技術を記載した段落【０００７】に記載されているようにネットワーク上の装置の情報収集をブロードキャストにより行うことは周知であって、このブロードキャストによる情報収集はネットワークデバイスの探索ということができるから、引用発明において、情報収集を指示するコマンドを探索コマンドとし、被管理装置に繋がるネットワークデバイスに関する情報を取得するために、送信ステップにおいて、ローカルブロードキャストパケットを送信して本願補正発明のように構成することは当業者が周知技術に基づいて容易になし得ることである。
　
相違点３について
　ネットワークにおける応答をパケット通信により行うことは周知であって格別のことではないから引用発明において本願補正発明のように構成することに格別の困難性はない。
　
相違点４について
　一般に、ネットワーク等において相手装置に所定の応答を求めるための信号を送信する場合に、信号の送信からの時間により所定の動作、あるいは応答を行うことは以下に示すように周知である。
　即ち、本願の明細書の段落【００６４】〜【００７６】には、従来例におけるネットワーク管理プログラムにおける探索シーケンスについて、図１０を参照して記載されているところ、段落【００７２】には、探索を開始してから一定の時間が経過すると一次応答タイマー１０２３が満了し、さらに詳細な情報を取得すべく、パケットを送信することが記載され、段落【００７５】には、更に時間が経過してデバイス応答タイマー１０２１が満了した時点で、上位モジュールに対して、それまでに探索したデバイス情報を通知することが記載されている。また、特開平６−５３９６１号公報（以下、「周知刊行物２」という。）には、従来の技術を記載した段落【０００５】に、監視装置からコマンドを送信してからレスポンスが帰ってくるまでの時間を時計１４により見て、所定の時間を超えると異常と判断することが記載され、発明の作用を記載した段落【００１４】にも同様のことが記載されている。また、前記周知刊行物１の段落【０００７】には、照会メッセージをブロードキャストしたＰＣが、ブロードキャストから一定の期間中（タイムアウト期間中）に受信した情報を表示することが記載されている。
　また、ネットワークにおいて送信を行う場合にネットワーク負荷を考慮することなく送信を行うことも周知である。
　そうすると、引用発明において上記周知技術を適用して、ネットワークデバイスが応答を返す締め切り時間をカウントするタイマーを設け、当該ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、デバイス情報取得ステップで取得されたネットワークデバイスに関する情報をクライアントに通知するようにして、本願補正発明のように構成することは当業者が容易になし得ることである。
　
　そして、本願補正発明のように構成したことによる効果も引用発明及び周知技術から予測できる程度のものである。
　
　したがって、本願補正発明（請求項１に係る発明）は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおりであるから、本件補正は特許法第１７条の２第５項で準用する同法第１２６条第５項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１７年１月５日付け手続補正は上記のとおり却下されたので、本願の請求項４に係る発明（以下、「本願発明」という。）は、平成１６年１０月１２日付け手続補正書の特許請求の範囲の請求項４に記載された事項により特定される、以下のとおりのものである。
「ネットワークデバイスを探索するネットワークデバイス探索方法であって、
　クライアントからの探索を指示する探索コマンドを受け付けるコマンド受付けステップと、
　前記探索コマンドを送信したクライアントのアドレスを取得するアドレス取得ステップと、
　前記アドレス取得ステップで取得されたアドレスをメモリに格納するアドレス格納ステップと、
　前記探索コマンドに応じて、ネットワークデバイスを探索するためのローカルブロードキャストパケットを送信するブロードキャストパケット送信ステップと、
　前記ローカルブロードキャストパケットに応答してネットワークデバイスが送信する応答パケットを受信する応答パケット受信ステップと、
　前記応答パケット受信ステップで受信された応答パケットから、当該応答パケットを送信したネットワークデバイスに関する情報を取得するデバイス情報取得ステップと、
　ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、前記アドレス格納ステップでメモリに格納されたアドレスに従って、前記デバイス情報取得ステップで取得されたネットワークデバイスに関する情報を前記クライアントに通知する探索結果通知ステップと、 
　を有することを特徴とするネットワークデバイス探索方法。」
　
（１）引用刊行物
　原査定の拒絶の理由に引用された引用刊行物及びその記載事項は、前記「２．（１）」に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明の「探索結果通知ステップ」に関し、「ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、」とあるのを「前記ローカルブロードキャストパケットの送信により、前記ネットワークデバイスが応答を返す締め切り時間をカウントするタイマーを起動し、当該ネットワークデバイスが応答を返す締め切り時間が満了するのに応じて、」とする限定を削除したものである。
　そうすると、本願発明の構成要件を全て含みさらに限定を付したものに相当する本願補正発明が、前記「２．（３）」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明（請求項４に係る発明）は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　したがって、本願はその余の請求項について論及するまでもなく、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。