【事件の表示】
　特願２００１−３２９５１６「情報処理装置、デバイス管理方法及び記憶媒体」拒絶査定不服審判事件〔平成１５年　５月　９日出願公開、特開２００３−１３１９５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年１０月２６日の出願であって、平成１６年１０月２６日に手続補正がなされ、平成１９年３月１２日付けの拒絶の理由の通知に対して、同年５月１８日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年８月７日付けで拒絶をすべき旨の査定がされ、これに対し同年９月１３日に拒絶査定不服審判の請求がなされるとともに、同年１０月１５日付けで手続補正がなされたものである。
　
２．平成１９年１０月１５日付けの手続補正についての却下の決定
［結論］
　平成１９年１０月１５日付けの手続補正を却下する。
［理由］
（１）本件補正
　平成１９年１０月１５日付けの手続補正（以下「本件補正」という。）は、平成１９年５月１８日付けの手続補正書の特許請求の範囲の請求項（以下「補正前の請求項」という。）１〜１２並びに【００１３】〜【００２４】を、平成１９年１０月１５日付けの手続補正書の特許請求の範囲の請求項（以下「補正後の請求項」という。）１〜１０並びに【００１３】〜【００２４】に補正したものである。補正後の請求項１は、以下のとおりである。
　
「デバイスを管理するデバイス管理方法であって、
　情報処理装置にて、複数のデバイスのそれぞれに対応して起動されて並行に実行される複数のデバイス制御プロセスのうち、特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を求める第１の要求をクライアントソフトウェアから受信する受信ステップと、
　情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であるかどうかを判断する判断ステップと、
　前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態でないと前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスを起動する起動ステップと、
　情報処理装置にて、前記起動ステップで起動されたデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第１の送信ステップと、
　前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であると前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プログラムを前記第１の要求を受信した後に起動することなく、前記特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第２の送信ステップと、
　を有し、
　前記クライアントソフトウェアは、前記第１の送信ステップ又は前記第２の送信ステップで送信された情報に基づいて、前記特定のデバイスに対応するデバイス制御プロセスに、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を求める第２の要求を送信し、
　前記特定のデバイスに対応するデバイス制御プロセスは、前記第２の要求に従って、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を行うことを特徴とするデバイス管理方法。」
　
　本件補正による請求項１は、補正前の請求項１に記載した発明を特定するために必要な事項である「複数のデバイスのそれぞれに対応する複数のデバイス制御プロセス」について「対応して起動されて並行に実行される」との限定を付加する補正をしたものであり、本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の請求項１に記載された発明（以下「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２）引用例の記載
　原査定の拒絶の理由に引用された特開２００１−２８２６５６号公報（平成１３年１０月１２日公開。以下「引用例１」という。）には、図面とともに次の事項が記載されている。
　
Ａ．「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、コンピュータ・ネットワークに関し、具体的にはネットワーク管理ソフトウェアを含むネットワーク・デバイス制御装置、ネットワーク・デバイス制御方法および、ネットワーク管理ソフトウェアのプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【０００２】
【従来の技術】ネットワーク・デバイスを管理する方法として、ＳＮＭＰ／ＭＩＢを使用する方法がある。（ＳＮＭＰ／ＭＩＢの詳細に関しては「ＴＣＰ／ＩＰ  ネットワーク管理入門  実用的な管理をめざして」Ｍ．Ｔ．ローズ＝著／西田竹志＝訳  （株）トッパン発行  １９９２年８月２０日初版を参照のこと）。
【０００３】ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク管理技術によれば、ネットワーク管理システムには、少なくとも１つのネットワーク管理ステーション（ＮＭＳ）、各々がエージェントを含むいくつかの管理対象ノード、および管理ステーションやエージェントが管理情報を交換するために使用するネットワーク管理プロトコルが含まれる。ユーザは、ＮＭＳ上でネットワーク管理ソフトウェアを用いて管理対象ノード上のエージェント・ソフトウェアと通信することにより、ネットワーク上のデバイスに関するデータを得、またそのデバイス内のデータを変更することができる。
【０００４】このようなネットワーク管理ソフトウェアを分散環境で使用する場合、ＳＮＭＰネットワーク管理機能を持つサーバー・アプリケーションと各端末で起動されるＧＵＩ部分である複数のクライアント・アプリケーションによる構成をとることが一般的である。
【０００５】異なる端末間でクライアント・アプリケーションとサーバー・アプリケーションでプロセス間通信を行う標準としてＲＦＣ１０５７  ＲＰＣ（ＲｅｍｏｔｅＰｒｏｃｅｄｕｒｅ  Ｃａｌｌ）が定義されている。ＲＰＣとは、ネットワーク・サービスを提供する関数群をサーバー側で用意し、その中の関数をローカル・マシン内の関数と同様に、ネットワーク上の別端末のクライアント・プロセスから呼び出せるようにしたものである。ＲＰＣにおけるプロセス間通信の流れは以下のようになる。クライアントは、サーバーに対するサービス要求として、サーバーに用意されているＲＰＣ関数を呼び出す。この時点で、関数の呼び出し情報を格納したデータ・パケットがサーバーに送られ、クライアントのプログラムは中断される。サーバーがパケットを受け取ると、呼び出された関数をディスパッチ（ｄｉｓｐａｔｃｈ；サーバーがクライアントに計算結果を返すこと。ここでは、ＯＳが動作の割り当てなどの制御を行うことを指す）し、関数の引数を取り出した後、その引数をもとにサービスを実行して、その結果をクライアントに返す。クライアントは関数の結果を受け取った後で、プログラムの実行を再開する。ＲＰＣにおけるクライアントとサーバーの接続形体には、コネクション型とコネクションレス型の２種類がある。」（第３ページ左欄第１２行目〜第３ページ右欄第１６行目）
　
Ｂ．「【００２３】
【発明の実施の形態】先ず、本発明が適用されるネットワークについて説明する。図１は、プリンタをネットワークに接続するためのネットワーク・ボード（ＮＢ）１０１を、開放型アーキテクチャを持つプリンタ１０２へつなげた場合を示す図である。ＮＢ１０１はローカル・エリア・ネットワーク（ＬＡＮ）１００へ、たとえば、同軸コネクタをもつＥｔｈｅｒｎｅｔ（登録商標）インターフェース１０Ｂａｓｅ−２や、ＲＪ−４５を持つ１０Ｂａｓｅ−Ｔ等のＬＡＮインターフェースを介して接続されている。
【００２４】ＰＣ１０３やＰＣ１０４等の複数のパーソナル・コンピュータ（ＰＣ）もまた、ＬＡＮ１００に接続されており、ネットワークオペレーティングシステムの制御のもと、これらのＰＣ１０３，１０４はＮＢ１０１と通信することができる。またＰＣ１０３に、ＰＣ１０４に接続されているプリンタ１０５のようなプリンタを接続してもよい。
【００２５】また、ＬＡＮ１００にファイル・サーバー１０６が接続されており、これは大容量（たとえば１００億バイト）のネットワーク・ディスク１０７に記憶されたファイルへのアクセスを管理する。プリント・サーバー１０８は、接続されたプリンタ１０９ａおよび１０９ｂ、または遠隔地にあるプリンタ１０５などのプリンタに印刷を行わせる。
【００２６】さらに詳しくは、図１に示すネットワークは、様々なネットワーク・メンバ間で効率良く通信を行うために、ＮｏｖｅｌｌやＵＮＩＸ（登録商標）のソフトウェアなどのネットワーク・ソフトウェアを使用することができる。どのネットワーク・ソフトウェアを使用することも可能であるが、たとえば、Ｎｏｖｅｌｌ社のＮｅｔＷａｒｅ（Ｎｏｖｅｌｌ社の登録商標。以下省略）ソフトウェアを使用することができる。このソフトウェアパッケージに関する詳細な説明は、ＮｅｔＷａｒｅパッケージに同梱されているオンラインドキュメンテーションを参照のこと。これは、Ｎｏｖｅｌｌ社からＮｅｔＷａｒｅパッケージとともに購入可能である。
【００２７】図１の構成について簡潔に説明すると、ファイル・サーバー１０６は、ＬＡＮメンバ間でデータのファイルの受信または、記憶、キューイング、キャッシング、および送信を行うファイル管理部としての役割を果たす。たとえば、ＰＣ１０３およびＰＣ１０４のそれぞれによって作られたデータファイルは、ファイル・サーバー１０６へ送られ、ファイル・サーバー１０６はこれらのデータファイルを順に並べ、そしてプリント・サーバー１０８からのコマンドにしたがって、並べられたデータファイルをプリンタ１０９ａへ送信する。
【００２８】またＰＣ１０３とＰＣ１０４はそれぞれ、データファイルの生成や、生成したデータファイルのＬＡＮ１００への送信や、また、ＬＡＮ１００からのファイルの受信や、更にそのようなファイルの表示及び／又は処理を行うことのできる通常のＰＣで構成される。なお、図１ではパーソナル・コンピュータ機器が示されているが、ネットワーク・ソフトウェアを実行するのに適切であるような、他のコンピュータ機器を含んでもよい。たとえば、ＵＮＩＸのソフトウェアを使用している場合に、ＵＮＩＸワークステーションをネットワークに含んでもよく、これらのワークステーションは、適切な状況下で、図示されているＰＣと共に使用することができる。
【００２９】通常、ＬＡＮ１００などのＬＡＮは、１つの建物内の１つの階または連続した複数の階でのユーザグループ等の、幾分ローカルなユーザグループにサービスを提供する。たとえば、ユーザが他の建物や他県にいるなど、あるユーザが他のユーザから離れるにしたがって、ワイドエリアネットワーク（ＷＡＮ）を作ってもよい。ＷＡＮは、基本的には、いくつかのＬＡＮを高速度サービス総合デジタルネットワーク（ＩＳＤＮ）電話線等の高速度デジタルラインで接続して形成された集合体である。したがって、図１に示すように、ＬＡＮ１００と、ＬＡＮ１１０と、ＬＡＮ１２０とは変調／復調（ＭＯＤＥＭ）／トランスポンダ１３０およびバックボーン１４０を介して接続されてＷＡＮを形成する。これらの接続は、数本のバスによる単純な電気的接続である。それぞれのＬＡＮは専用のＰＣを含み、また、必ずしも必要なわけではないが、通常はファイル・サーバーおよびプリント・サーバーを含む。
【００３０】したがって図１に示すように、ＬＡＮ１１０は、ＰＣ１１１と、ＰＣ１１２と、ファイル・サーバー１１３と、ネットワーク・ディスク１１４と、プリント・サーバー１１５と、プリンタ１１６およびプリンタ１１７とを含む。対照的に、ＬＡＮ１２０はＰＣ１２１とＰＣ１２２のみを含む。ＬＡＮ１００と、ＬＡＮ１１０と、ＬＡＮ１２０とに接続されている機器は、ＷＡＮ接続を介して、他のＬＡＮの機器の機能にアクセスすることができる。
【００３１】前述したプリンタ１０２には、ネットワークに接続するためのネットワーク・ボードＮＢが実装され、このボード上にエージェントが実装されている。これにより、プリンタをネットワーク管理ソフトウェアによる管理の対象とすることができる。ユーザは、ネットワーク管理ソフトウェアを用いて制御対象のプリンタの情報を得、また状態を変更することができる。より具体的には、たとえばプリンタの液晶ディスプレイに表示されている文字列を取得したり、デフォルトの給紙カセットを変更したりすることができる。
【００３２】ネットワーク管理ソフトウェアが稼動するＰＣについて、以下に説明する。図２において、２００はネットワーク管理ソフトウェアが稼動するＰＣであり、図１における１０３と同等のものである。
【００３３】本発明の実施形態によるネットワーク管理装置は、図２に示したような従来のネットワーク管理装置を実現可能なＰＣ（パーソナル・コンピュータ）と同様の構成のＰＣ上に、実現される。ハード・ディスク（ＨＤ）２１１には、後述のすべての説明で動作主体となる本願に係るネットワーク管理ソフトウェアのプログラムが格納される。後述のすべての説明において、とくに断りのない限り、実行の主体は、ハード上はＣＰＵ２０１である。一方、ソフトウェア上の制御の主体は、ハード・ディスク（ＨＤ）２１１に格納されたネットワーク管理ソフトウェアである。本実施例においては、ＯＳ（オペレイティング・システム）はたとえば、ウィンドウズ９５（マイクロソフト社製）を想定しているが、これに限るものではない。
【００３４】なお本願に係るネットワーク管理プログラムは、フロッピー（登録商標）ディスクやＣＤ−ＲＯＭなどの記憶媒体に格納された形で供給されても良く、その場合には図２に示すフロッピーディスク・コントローラ（ＦＤ）２１２または不図示のＣＤ−ＲＯＭドライブなどによって記憶媒体からプログラムが読み取られ、ハード・ディスク（ＨＤ）２１１にインストールされる。
【００３５】以下の説明において、本願に係るネットワーク管理ソフトウェアのＧＵＩ部分のプロセスを「ＮｅｔＳｐｏｔ  ＧＵＩ」、デバイスと通信する部分のプロセスを「ＶＤＣ」と呼称する。
【００３６】図３あるいは図１において、ＰＣ１０３上でＮｅｔＳｐｏｔ  ＧＵＩのプロセス、ＰＣ１２１上でＶＤＣのプロセスをそれぞれ起動してプリンタ１０２（ＳＮＭＰエージェントが実装されている）を管理する。ＮｅｔＳｐｏｔ  ＧＵＩは、プロセス間通信の機能を使用してＶＤＣと通信を行い、ＶＤＣはＳＮＭＰプロトコルを使用してデバイスと通信を行う。
【００３７】デバイスから情報を取得するために、ＮｅｔＳｐｏｔ  ＧＵＩはプロキシを用いてプロセス間通信をし、ＶＤＣに取得したいデバイス情報を送信する。ＶＤＣはスタブから送信された情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスからＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ；自分の状態に関するデータであり、ここではデバイスの状態に関するデータ・ベースを指す）情報を取得する。取得した情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ  ＧＵＩにコールバック通知される。ＮｅｔＳｐｏｔ  ＧＵＩは、ＶＤＣからコールバック通知された情報を基にビットマップ表示等を行ってデバイス情報を表示する。この例を図４に示す。この例では、管理対象範囲に６個のデバイスの存在と、それぞれのデバイスの製品名、ネットワーク・アドレス、そしてＭＡＣアドレスを表示し、そして最下段に表示されたデバイスの状態が、スリープモードであることを示している。
【００３８】デバイスに情報を設定するために、ＮｅｔＳｐｏｔ  ＧＵＩはプロキシを用いてプロセス間通信をし、ＶＤＣに設定したいデバイス情報を送信する。ＶＤＣはスタブから送信された情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスにＭＩＢ情報を設定する。設定が成功したか失敗したかを示す情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ  ＧＵＩにコールバック通知される。ＮｅｔＳｐｏｔ  ＧＵＩは、ＶＤＣからコールバック通知された情報を基にビットマップ表示等を行って設定情報を表示する。この例を図５に示す。デバイスとしてのプリンタの状態(Status)シートの表示例を示している。この図は、ネットワーク周辺機器を管理・制御するためのウィンドウ、すなわちデバイス詳細ウィンドウであり、ユーザがＮｅｔＳｐｏｔを管理者モードで起動したときに、ユーザの指示に応じてＮｅｔＳｐｏｔが順次表示していくウィンドウの１つの表示状態を示す例である。ここでは、図４に表示されたデバイス（最下段のデバイス）であるＬＡＳＥＲ  ＳＨＯＴ  ＬＢＰ−９３０の状態を示している。このウィンドウから、他にジョブ・シート、情報・シート、ネットワーク・シートを選択表示することが可能である。ここでは、プリンタの図の下方に表示されているエラーに関する表示エリアを示そうとしている。ＮｅｔＳｐｏｔはユーザからの指示がない場合でも、ＮｅｔＳｐｏｔの動作状況やネットワークから得られた情報に応じて、各種のウィンドウを自動的に表示するが、それらのウィンドウについては、ここでは説明しない。」（第４ページ右欄第４１行目〜第６ページ右欄第１８行目）
　
　以上の記載によれば、引用例１には、次の発明（以下「引用発明」という。）が記載されている。
　
「ネットワーク・デバイス制御方法に関し、
　ネットワーク管理ソフトウェアのＧＵＩ部分のプロセスを「ＮｅｔＳｐｏｔ  ＧＵＩ」、デバイスと通信する部分のプロセスを「ＶＤＣ」と呼称し、
　ＰＣ１０３上でＮｅｔＳｐｏｔ  ＧＵＩのプロセス、ＰＣ１２１上でＶＤＣのプロセスをそれぞれ起動し、
　ＮｅｔＳｐｏｔ  ＧＵＩは、プロセス間通信の機能を使用してＶＤＣと通信を行い、
　ＶＤＣはＳＮＭＰプロトコルを使用してデバイスと通信を行い、
　デバイスから情報を取得するために、ＮｅｔＳｐｏｔ  ＧＵＩはプロキシを用いてプロセス間通信をし、ＶＤＣに取得したいデバイス情報を送信し、
　ＶＤＣはスタブから送信された情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスからＭＩＢ情報を取得し、
　取得した情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ  ＧＵＩにコールバック通知され、
　ＮｅｔＳｐｏｔ  ＧＵＩは、ＶＤＣからコールバック通知された情報を基にビットマップ表示等を行ってデバイス情報を表示する、
　ネットワーク・デバイス制御方法。」
　
　また、原査定の拒絶査定時に周知例として示された特開平１１−１４３８４０号公報（平成１１年５月２８日公開。以下「引用例２」という。）の段落【０００２】−【００１２】には【従来の技術】として、次の事項が記載されている
　
Ｃ．「【０００２】
【従来の技術】情報通信機器の発達により、学校や企業のような組織では、ワークステーションやパソコン等の端末を相互に接続したローカルエリアネットワーク（ＬＡＮ）が普及している。これに伴い、コンピュータの利用形態も、スタンドアロン型からクライアント・サーバ型（分散コンピューティング型）へと急速に移行している。
【０００３】クライアント・サーバシステムは、スタンドアロン型に比べ、複数のユーザ（クライアント端末利用者）による協調作業を容易に実現することができ、また、高度な処理能力を必要とする作業をサーバに行わせることで、クライアント端末に上記のような処理能力が要求されず、コストパフォーマンスがよいなどの利点を有する。さらに、システム開発においても、サービス提供側とサービス利用側を明確に切り分けることができるので、ソフトウェアの部品化がしやすく開発効率がよいという利点もある。
【０００４】近年、これらクライアント・サーバシステム（分散コンピューティングシステム）とオブジェクト指向技術とを結び付けた分散オブジェクトシステムが脚光を浴びはじめている。
【０００５】従来のクライアントサーバシステムでは、クライアントアプリケーションとサーバプログラムとの間に密接な関係がある。例えば、クライアントアプリケーションは、あらかじめサーバプログラムがどこで（どのサーバマシンで）動作しているかを知っている必要がある。また、システムの拡張などが行われた場合に、クライアント側でもそれに対応した修正が必要となる。
【０００６】これに対し、分散オブジェクトシステムでは、クライアントアプリケーション（クライアントオブジェクト）は、サーバプログラム（サーバオブジェクト）がどこで動作しているかということをあらかじめ知っている必要はなく、また、システムの拡張が行われた場合でもクライアント側はほとんど修正する必要がないなど柔軟性に富んだシステムを構築することができる。
【０００７】このような分散オブジェクトシステムの柔軟性とその仕組みについては、例えば、「ＣＯＲＢＡとＪａｖａ  分散オブジェクト技術」（著者：成田　雅彦、保西　義孝、勝亦　章善、島村　政義、島村　真己子、杉能　康明、発行元：ソフト・リサーチ・センター）の５８ページから５９ページに記載されている。この文献での記載を図１を参照して簡単に説明すると、以下のようである。
【０００８】サーバオブジェクト１０１がどこで動作しているかわからない場合、クライアントオブジェクト１００は、オブジェクト仲介プログラム１０２に対し、サーバオブジェクト１０１の名前を用いてサーバオブジェクト１０１の位置情報を問い合わせる（ステップ１１０）。
【０００９】オブジェクト仲介プログラム１０２は、自分が管理するすべてのオブジェクトの名前と位置情報との対応関係を保持しており、その情報を用いて、問い合わせのあったサーバオブジェクト１０１の位置情報をクライアントオブジェクト１００に通知する（ステップ１１１）。それとともにサーバオブジェクト１０１が起動しているかどうかを確認し、もしサーバオブジェクト１０１が起動していなければ起動する（ステップ１１２）。
【００１０】クライアントオブジェクト１００は、受け取った位置情報に基づいてサーバオブジェクト１０１とセッションを張り、サーバオブジェクト１０１を呼び出してサービスを利用する（ステップ１１３）。
【００１１】ただし、この文献での記述は、あくまで分散オブジェクトシステムの概念を説明したものであり、実際には、クライアントオブジェクトとサーバオブジェクトとの間のすべての通信は、オブジェクト仲介プログラムを経由して行われる場合が多い。
【００１２】以上のように、分散オブジェクトシステムでは、クライアントオブジェクトとサーバオブジェクトとの間に仲介者を設けることにより、柔軟性に富んだシステムの構築を可能としている。」（第４ページ第５欄第１７行目〜第４ページ第６欄第３８行目）
　
　上記の記載において、各オブジェクトは、通常は情報処理装置内で起動している一般的なプロセスであり、サーバオブジェクトの位置情報は、クライントに送信されるプロセスに要求を送信するための情報に相当するものである。また、サーバオブジェクトが起動している場合は、そのまま、受け取った位置情報に基づいてサーバオブジェクトとセッションを張り、サーバオブジェクトを呼び出してサービスを利用することは明らかである。
　さらに、上記の記載における分散オブジェクトは、複数のプロセスを対象としている。
　
　そのため、引用例２には、周知技術として次の事項が記載されている。
　
「情報処理装置内における複数からなる一般的なプロセス間の通信を行う手順において、プロセスに要求を送信するための情報を求める要求をクライアントから受信し、そのプロセスが起動されているかどうかを判断し、そのプロセスが起動されている状態でない場合には、そのプロセスを起動し、プロセスに要求を送信するための情報をクライアントソフトウェアに送信し、クライアントが、送信されたプロセスに要求を送信するための情報に基づいてそのプロセスに要求を送信する。」
　
　また、原査定の拒絶の理由に周知例として示された特開平６−６７９０７号公報（平成６年３月１１日公開。以下「引用例３」という。）の段落【０００９】−【００１１】には、次の事項が記載されている
　
Ｄ．「【０００９】
【実施例】図２に実施例のシステム構成図を示す。図２は、処理装置30と、稼働記録ファイル39-1，2 ，3 を有する外部記憶装置37と、入出力機能を持つディスプレイ装置等から構成されるシステムコンソール36と、制御対象機器Ａ，Ｂ，Ｃとから構成される計算機制御システムの１例を示しており、処理装置30は、プロセス実行記録部1-ｉ( ｉ＝1,2,3 ）をそれぞれ有するプロセス実行部3-ｉ( ｉ＝1,2,3 ）と、作業順位格納部２と、実行制御部38とから構成される。
【００１０】プロセス実行部3-ｉ( ｉ＝1,2,3 ）は、それぞれが制御する制御対象機器Ａ，Ｂ，Ｃに対応してコマンドを発信するタスク（プロセスとも呼ばれる）から構成されている。即ち制御対象機器Ａに対するコマンドは、プロセス実行部3-１のみから発信され、他の制御対象機器Ａ，Ｂについてもそれぞれプロセス実行部3-２，3-３のみからコマンドが発信される。また制御対象機器がｎ台ある場合のプロセス実行部3-ｉは、ｎ台の制御対象機器に対応してプロセス実行部3-1,2,3・・・ｎから構成されることになる。
【００１１】制御対象機器Ａ，Ｂ，Ｃは例えば部品装着搬送装置、プレス加工機、自動溶接機等であって、処理装置30からの指令即ちコマンドによって制御されるファクトリオートメィション（ＦＡ）を構成する各種装置である」（第２ページ第３欄第１１行目〜第２ページ第３欄第３５行目）
　
　以上の記載によれば、引用例３には、周知技術として「複数のデバイスのそれぞれに対応して起動されるデバイス制御プロセスを並行に実行すること」が記載されている。
　
　
（３）対比
　本願補正発明と引用発明を対比する。
　
　引用発明は「ネットワーク・デバイス制御方法」に関するものであるので、引用発明と本願補正発明は、「デバイスを管理するデバイス管理方法」である点で共通する。
　引用発明の「デバイス」は、本願補正発明の「特定のデバイス」に相当する。
　引用発明は、デバイスと通信する部分のプロセスである「ＶＤＣ」は、ＰＣ１２１上でＶＤＣのプロセスが起動され、ＳＮＭＰエージェントが実装されているプリンタ１０２を管理し、さらに、ＶＤＣはＳＮＭＰプロトコルを使用してデバイスと通信を行うものであるので、引用発明の「ＶＤＣのプロセス」は本願補正発明の「特定のデバイスに対応するデバイス制御プロセス」に相当する。
　また、引用発明は、ＰＣ１０３上でＮｅｔＳｐｏｔ  ＧＵＩのプロセス、ＰＣ１２１上でＶＤＣのプロセスをそれぞれ起動するものであり、ＰＣ１０３とＰＣ１２１は情報処理装置であるので、引用発明と本願補正発明は、情報処理装置におけるプロセスを対象とする点で共通する。
　引用発明は、ＰＣ１０３上でＮｅｔＳｐｏｔ  ＧＵＩのプロセスが起動され、デバイスから情報を取得するために、ＮｅｔＳｐｏｔ  ＧＵＩはプロキシを用いてプロセス間通信をし、ＶＤＣに取得したいデバイス情報を送信するので、引用発明の「ＮｅｔＳｐｏｔ  ＧＵＩのプロセス」は本願補正発明の「クライアントソフトウェア」に相当し、また、「ＮｅｔＳｐｏｔ  ＧＵＩはプロキシを用いてプロセス間通信をし、ＶＤＣに取得したいデバイス情報を送信」することは、本願補正発明の「特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を求める第２の要求を送信」することに相当する。そのため、引用発明の「ＶＤＣに取得したいデバイス情報を送信」することは、本願補正発明の「第２の要求を送信」することに相当することとなる。
　さらに、引用発明の、「ＶＤＣに取得したいデバイス情報を送信し、ＶＤＣはスタブから送信された情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスからＭＩＢ情報を取得する」ことは、デバイスへのデータの送信とデバイスからのデータを取得を行っていることになるので、本願補正発明の「特定のデバイスに対応するデバイス制御プロセスは、前記第２の要求に従って、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を行うこと」に相当する。
　
　すると、本願補正発明と引用発明とは、次の点で一致する。
　
一致点
「デバイスを管理するデバイス管理方法であって、
　情報処理装置にて、
　クライアントソフトウェアは、特定のデバイスに対応するデバイス制御プロセスに、特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を求める第２の要求を送信し、
　前記特定のデバイスに対応するデバイス制御プロセスは、前記第２の要求に従って、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を行うことを特徴とするデバイス管理方法。」
　
　一方、両者は次の点で相違する。
　
相違点１
　本願補正発明は、複数のデバイスのそれぞれに対応して起動されて並行に実行される複数のデバイス制御プロセスを対象としているが、引用発明は、デバイスと通信する１つのプロセスであるＶＤＣを対象としている点。
　
相違点２
　本願補正発明は、情報処理装置にて、特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を求める第１の要求をクライアントソフトウェアから受信する受信ステップと、
　情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であるかどうかを判断する判断ステップと、
　情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態でないと前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスを起動する起動ステップと、
　情報処理装置にて、前記起動ステップで起動されたデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第１の送信ステップと、
　前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であると前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プログラムを前記第１の要求を受信した後に起動することなく、前記特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第２の送信ステップを有し、
　前記クライアントソフトウェアは、前記第１の送信ステップ又は前記第２の送信ステップで送信された情報に基づいて第２の要求を送信しているが、引用発明はこれらの各ステップを有していない点。
　
　
（４）当審の判断
　上記相違点について検討する。
　
（相違点１についての検討）
　情報処理装置において、複数からなる一般的なプロセスの制御、及び、管理を行うことは前記の引用例２に記載されているように周知の技術であり、また、複数のデバイスのそれぞれに対応して起動されるデバイス制御プロセスを並行に実行することも前記の引用例３に記載されているように周知の技術である。
　そのため、引用発明において、複数のデバイスのそれぞれに対応して起動されて並行に実行される複数のデバイス制御プロセスからなるものとして、本願補正発明のように構成することは、当業者であれば容易に成し得ることである。
　
（相違点２についての検討）
　情報処理装置内における複数からなる一般的なプロセス間の通信を行う手順において、プロセスに要求を送信するための情報を求める要求をクライアントから受信し、そのプロセスが起動されているかどうかを判断し、そのプロセスが起動されている状態でない場合には、そのプロセスを起動し、プロセスに要求を送信するための情報をクライアントソフトウェアに送信し、クライアントが、送信されたプロセスに要求を送信するための情報に基づいてそのプロセスに要求を送信することは、前記の引用例２に記載されているように周知の技術である。また、「ＣＯＲＢＡとＪａｖａ　分散オブジェクト技術、成田雅彦他、ソフト・リサーチ・センター、１９９８年１１月２５日発行、ｐ．５５−ｐ．５９」、及び、特開平８−２７２７２５号公報：段落【００１６】−【００１８】にも、同様に周知の技術として記載されている。
　そのため、プロセス間通信に関する当該周知の技術を引用発明のデバイス制御プロセスに適用して、本願補正発明のように構成することは、当業者であれば容易に成し得ることである。
　
　また、本願補正発明の構成によって生じる効果も、当業者が予測できるものである。
　
　したがって、本願補正発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
３．本願発明について
　平成１９年１０月１５日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下「本願発明」という。）は、同年５月１８日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「デバイスを管理するデバイス管理方法であって、
　情報処理装置にて、複数のデバイスのそれぞれに対応する複数のデバイス制御プロセスのうち、特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を求める第１の要求をクライアントソフトウェアから受信する受信ステップと、
　情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であるかどうかを判断する判断ステップと、
　前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態でないと前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プロセスを起動する起動ステップと、
　情報処理装置にて、前記起動ステップで起動されたデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第１の送信ステップと、
　前記特定のデバイスに対応するデバイス制御プロセスが起動されている状態であると前記判断ステップで判断されるのに従って、情報処理装置にて、前記特定のデバイスに対応するデバイス制御プログラムを前記第１の要求を受信した後に起動することなく、前記特定のデバイスに対応するデバイス制御プロセスに要求を送信するための情報を前記クライアントソフトウェアに送信する第２の送信ステップと、
　を有し、
　前記クライアントソフトウェアは、前記第１の送信ステップ又は前記第２の送信ステップで送信された情報に基づいて、前記特定のデバイスに対応するデバイス制御プロセスに、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を求める第２の要求を送信し、
　前記特定のデバイスに対応するデバイス制御プロセスは、前記第２の要求に従って、前記特定のデバイスに対するデータの送信又は前記特定のデバイスからのデータの取得を行うことを特徴とするデバイス管理方法。」
　
（１）引用例
　原査定の拒絶の理由に引用された引用例及びその記載事項は、前記２．（２）に記載したとおりである。
　
（２）当審の判断
　本願発明は、前記２．で検討した本願補正発明から、「複数のデバイスのそれぞれに対応して起動されて並行に実行される複数のデバイス制御プロセス」の限定事項である「対応して起動されて並行に実行される」との構成を省いたものである。　
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．（４）に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。