【事件の表示】
　平成９年特許願第２８８２４４号「ネットワークにおけるアドレス自動設定システムおよび方法」拒絶査定に対する審判事件［平成１１年５月１１日出願公開、特開平１１−１２７１５９］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年１０月２１日の出願であって、特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、出願当初の明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「ホスト装置と複数の端末装置とこれらのホスト装置と端末装置とを接続しているネットワーク回線とを有するネットワークにおいて、
　前記ホスト装置のホストアドレスを変更する場合に前記ホストアドレスを変更する前に前記ホストアドレスを変更することを通知をするためのホストアドレス変更通知信号に通知先リストに従って前記端末装置を指定する端末アドレスを付加しこの端末アドレスを有する前記ホストアドレス変更通知信号を送信するアドレス変更通知手段と、前記ホスト装置のホストアドレスを変更をした場合にこの変更ホストアドレスを送信する変更ホストアドレス送信手段と、前記アドレス変更通知手段からの前記ホストアドレス変更通知信号を受けた場合に前記変更ホストアドレス送信手段からの変更ホストアドレスを受けた時に前記ホストアドレス変更通知信号が有する前記端末アドレスの前記端末装置が保持するホストアドレスを前記変更ホストアドレスに変更設定するアドレス変更設定手段とを有することを特徴とするネットワークにおけるアドレス自動設定システム。」
　
２．引用例
　これに対して、原審の拒絶理由に引用された電子情報通信学会技術研究報告、Ｖｏｌ.９６　Ｎｏ．３２４、ＳＳＥ９６−１０５、山野繁樹他「大規模ＡＴＭ網におけるＮＨＲＰシステムの自動設定方式」、ｐｐ．１９−２４（１９９６年１０月２５日発行）（以下、「引用例」という。）には、次の事項が記載されている。
（１）大規模ＩＰ網においてルータの設定が複雑になるのと同様に、このＮＨＲＰを用いた大規模ＡＴＭ網が構築された場合、ＮＨＲＰのサーバであるＮＨＳ（ＮＨＲＰ　Ｓｅｒｖｅｒ）の設定も複雑なものになる。現在ではＮＨＳの設定は、ＩＰルータと同様にすべて手動で行われており、ＬＩＳ内のＮＨＳの追加、各種サーバのＡＴＭアドレスの変更などの環境変化のたびにＬＩＳ内のすべてのＮＨＳの設定を変更する作業が必要となっている。
　このようなＮＨＳの設定の繁雑さを解消するため、本稿ではＮＨＳの設定および再設定の自動化を行なうＲＯＣＳ（ＲＯｕｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｓｅｒｖｅｒ）を用いるシステムを提案する。ＲＯＣＳは、ＮＨＳの設定の他に、ＮＨＣ（ＮＨＲＰ　Ｃｌｉｅｎｔ）の設定、ｂｒｏａｄｃａｓｔ環境のための設定、ＡＴＭＡＲＰ（ＡＴＭ　Ａｄｄｒｅｓｓ　Ｒｅｓｏｌｕｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）端末の設定も自動化する。また、ＲＯＣＳはＮＨＲＰ環境の設定を可能にするだけでなく、ＬＡＮ　Ｅｍｕｌａｔｉｏｎ［４］、ＭＰＯＡ（ＭｕｌｔｉＰｒｏｔｏｃｏｌ　Ｏｖｅｒ　ＡＴＭ）［５］などＡＴＭ網の各種ノードの自動設定を実現可能とするサーバとして使用可能となるよう設計を行なっている［１１］［１２］。（２０頁左欄「１　はじめに」の項）
（２）また、各ノードへの自動設定は各ノードの立ち上げ時だけではなく、各種サーバのＡＴＭアドレスの変更、ポリシーの変化などによって立ち上げ後に設定が変更される場合にも必要である。
　この設定変更時のＲＯＣＳの自動設定動作を図８に示す。
　ＲＯＣＳは自分の保持しているＭＩＢ内の設定が変更された場合には、ＳＮＭＰ　Ｔｒａｐを用いて、設定変更が起こったことを自分の担当するＲＯＣＳ−Ｃｌｉｅｎｔに通知する。この通知を受けとったＲＯＣＳ−Ｃｌｉｅｎｔは再びＧｅｔＮｅｘｔリクエストをＲＯＣＳに送信し、設定データを取得した後、設定ファイルを生成する。この設定ファイルを元にＮＨＳ、ＮＨＣなどの必要な機能を再起動することによって、ＲＯＣＳ上の設定変更が各ノードに反映される。（２３頁右欄「５．５設定変更処理」の項）
　
　以上の記載及び図１、図８ならびにこの分野における技術常識を考慮すると、上記「ＮＨＲＰシステム」は「サーバ」と「端末」と「ＡＴＭ網」からなるネットワークにおいて、各種サーバのＡＴＭアドレス等を自動設定するシステムであり、上記「ＲＯＣＳ」はＮＨＳの設定および再設定の自動化を行なうサーバ（ＲＯｕｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｓｅｒｖｅｒ）であり、上記「ＲＯＣＳ−Ｃｌｉｅｎｔ」はいわゆる「端末」のことである。また、「ネットワーク」が「ネットワーク回線」により「サーバ」と複数の「端末」を接続していることは自明のことであり、上記「設定データを取得」するためには「ＲＯＣＳ」が「設定データの送信手段」を有していることも自明のことである。
　したがって、上記引用例には以下の発明（以下、「引用発明」という。）が記載されているといえる。
「ＲＯＣＳと複数のＲＯＣＳ−ＣｌｉｅｎｔとこれらのＲＯＣＳとＲＯＣＳ−Ｃｌｉｅｎｔとを接続しているネットワーク回線とを有するネットワークにおいて、
　前記ＲＯＣＳの設定データを変更する場合に、ＲＯＣＳは前記設定データを変更することを自分の担当するＲＯＣＳ−Ｃｌｉｅｎｔに通知する設定データ変更通知手段と、ＲＯＣＳ−Ｃｌｉｅｎｔがこの通知を受けとると、ＧｅｔＮｅｘｔリクエストをＲＯＣＳに送信する手段と、
　変更設定データを送信する変更設定データ送信手段と、
　送信された変更設定データを取得し、ＲＯＣＳ−Ｃｌｉｅｎｔに設定されているＲＯＣＳの設定データを更新する設定データ変更手段とを有することを特徴とするネットワークにおける設定データ自動設定システム。」
　
３．対比
　そこで、本願発明と引用発明とを対比するに、
　本願発明の「ホスト装置」、「端末装置」と引用発明の「ＲＯＣＳ」、「ＲＯＣＳ−Ｃｌｉｅｎｔ」はそれぞれ「ネットワーク」における「サーバ」と「端末」という関係であるから同じものである。
　また、本願発明の「ホストアドレス」は「設定データ」の一種であるから、この点で引用発明の「設定データ」と同じものである。
　
　したがって、本願発明と引用発明は、
「ホスト装置と複数の端末装置とこれらのホスト装置と端末装置とを接続しているネットワーク回線とを有するネットワークにおいて、
　前記ホスト装置の設定データを変更する場合に、前記設定データを変更することを通知をするための設定データ変更通知手段と、
　変更後の設定データを送信する変更設定データ送信手段と、
　設定データ変更設定手段と
を有することを特徴とするネットワークにおける設定データ自動設定システム。」
の点で一致し、以下の点で相違する。
　
＜相違点＞
（１）「設定データ」に関し、本願発明は「ホストアドレス」であるのに対し、引用発明は単に「設定データ」である点。
（２）「設定データ変更通知手段」に関し、本願発明は「ホストアドレスを変更する前に前記ホストアドレスを変更することを通知をするためのホストアドレス変更通知信号に通知先リストに従って前記端末装置を指定する端末アドレスを付加しこの端末アドレスを有する前記ホストアドレス変更通知信号を送信する」ものであるのに対し、引用発明の「設定データ変更通知手段」は「ＲＯＣＳは前記設定データを変更することを自分の担当するＲＯＣＳ−Ｃｌｉｅｎｔに通知する」ものであり、また、当該通知に対して「ＧｅｔＮｅｘｔリクエストをＲＯＣＳに送信する」ものである点。
（３）「変更設定データ送信手段」に関し、本願発明は「ホスト装置のホストアドレスを変更をした場合にこの変更ホストアドレスを送信する」ものであるのに対し、引用発明は単に「変更設定データを送信する」ものである点。
（４）「設定データ変更設定手段」に関し、本願発明は「アドレス変更通知手段からの前記ホストアドレス変更通知信号を受けた場合に前記変更ホストアドレス送信手段からの変更ホストアドレスを受けた時に前記ホストアドレス変更通知信号が有する前記端末アドレスの前記端末装置が保持するホストアドレスを前記変更ホストアドレスに変更設定する」ものであるのに対し、引用発明は「送信された変更設定データを取得し、ＲＯＣＳ−Ｃｌｉｅｎｔに設定されているＲＯＣＳの設定データを更新する」ものである点。
　
４．当審の判断
　そこで、相違点（１）の「設定データ」について検討するに、本願発明の「ホストアドレス」も引用発明の「設定データ」の具体例である「ＡＴＭアドレス」もともにホスト（サーバ）が管理するアドレスであり、端末装置に対する自動設定データの一種であるから、これらのデータを本願発明のように「ホストアドレス」に限定する程度のことは単なる設計的事項である。
　
　ついで、相違点（２）の「設定データ変更通知手段」について検討するに、引用発明の「アドレスを変更することを自分の担当するＲＯＣＳ−Ｃｌｉｅｎｔに通知する」ということは、複数の「ＲＯＣＳ−Ｃｌｉｅｎｔ」の中から自分の担当する「ＲＯＣＳ−Ｃｌｉｅｎｔ」を選択して通知することであるから、選択に際し、自分の担当する「ＲＯＣＳ−Ｃｌｉｅｎｔ」を通知先リストとして保持し、当該リストを用いて「アドレス変更通知信号」を送信するように構成することは容易なことである。また、「アドレスを変更する前にアドレスを変更することを通知をする」ことは、作業の流れから、自明の手順であり、「通知先端末装置を指定する端末アドレスを通知信号に付加して送信する」ことは通信の基本であって、単なる慣用手段に過ぎないものである。
　また、引用発明では当該通知に対して「ＧｅｔＮｅｘｔリクエスト」をＲＯＣＳに送信する手段を有しているが、該「ＧｅｔＮｅｘｔリクエスト」は一般の通信手順において汎用されている単なる「受信通知」にほかならず、当該「受信通知」を発行するか否かはシステムの信頼性とその処理に要する負荷量・処理時間等を勘案して適宜決めるべき事項である。したがって、「ＧｅｔＮｅｘｔリクエスト」の送信手順を省略して本願発明のように構成することは容易なことである。また、省略した場合、その分処理時間が早くなることは自明のことである。
　
　また、相違点（３）の「変更設定データ送信手段」について検討するに、本願発明の「ホスト装置のホストアドレスを変更をした場合にこの変更ホストアドレスを送信する」ことは、データ変更の作業の流れから当然に導出される自明の手順である。
　
　また、相違点（４）の「設定データ変更設定手段」について検討するに、変更通知は選択的に出されているのであり、変更通知を受けた端末は自端末に設定されているデータの変更が終了するまでの一連の作業を支障なく行うために何らかの状況認識を行うのが通例であるから、これらの技術内容を「アドレス変更通知手段からの前記ホストアドレス変更通知信号を受けた場合に前記変更ホストアドレス送信手段からの変更ホストアドレスを受けた時に前記ホストアドレス変更通知信号が有する前記端末アドレスの前記端末装置が保持するホストアドレスを前記変更ホストアドレスに変更設定する」ものとして本願発明のように構成する程度のことは当業者であれば容易に想到し得ることである。
　
５．むすび
　以上のとおりであるから、本願発明は、上記引用例に記載された発明ならびに上記慣用手段に基づいて、当業者が容易に発明をすることができたものと認められるので、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。