【事件の表示】
　平成１１年特許願第１５３４９６号「ネットワーク機器」拒絶査定不服審判事件〔平成１２年１２月　８日出願公開、特開２０００−３４１３６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯
　本願は，平成１１年６月１日の出願であって，平成１６年１０月２５日付けで拒絶査定がなされ，これに対し，平成１６年１２月２日に拒絶査定に対する審判請求がなされるとともに，平成１６年１２月２８日付けで手続補正がなされたものである。
　
２　平成１６年１２月２８日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１６年１２月２８日付けの手続補正を却下する。
［理由］
（１）補正後の本願発明
　本件補正により，特許請求の範囲の請求項１は，
　「【請求項１】　リピータ機能部からトラフィックカウンタ情報を取得してネットワーク状況の監視を行うネットワーク状況監視機能部と，ネットワーク状況監視機能部によるトラップ発生検知でトラップ発生情報を指定メール宛先に送信するメール送信機能部とを備えていることを特徴とするネットワーク用ハブ。」と補正された。
　上記補正は，本件補正前の請求項１に記載された発明の「・・・ネットワーク機器」を，「・・・ネットワーク用ハブ」とするものであり，「機器」を「用ハブ」という下位概念とするものであって，特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで，本件補正後の請求項１に記載された発明（以下，「本願補正発明１」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
（２）引用刊行物に記載された発明
　原査定の拒絶の理由に引用された特開平１１−１２２１９８号公報（以下，「引用刊行物１」という。）には，次の事項が記載されている。
　記載事項１　　
　「【００４０】図１において，通信線１０には被通知端末２０，３０と，集線装置４０，５０とを接続してあり，所定のプロトコルに従って各々パケットの転送を可能としてある。
【００４１】被通知端末２０，３０は，それぞれ図示しないＣＰＵやＲＡＭやＲＯＭ等を備えて所定のオペレーティングシステムのもとで各種アプリケーションを実行可能としてある。具体的には，それぞれマネージャプログラム２１ａ，３１ａを記録したハードディスク２１，３１を備え，同マネージャプログラム２１ａ，３１ａを常駐している。このマネージャソフト２１ａ，３１ａは，集線装置４０，５０との間で独自のプロトコルに従って通信可能であり，詳しくは後述する。
【００４２】集線装置４０は，Ｐ１〜Ｐ８からなる八個の通信ポートを備えており，いま集線装置４０の通信ポートＰ１〜Ｐ８のそれぞれには所定の通信線を介して端末Ｔ１〜Ｔ８を接続してある。集線装置５０も集線装置４０と同一構成であり，通信ポートＰ１〜Ｐ８のそれぞれには同様に端末ｔ１〜ｔ８を接続してある。以下，集線装置４０を例示してその構成を説明する。」（５頁７欄２〜２１行）
　記載事項２
　「【００４３】図２において，ＨＵＢコントローラ４１は，通常のリピータハブとしての動作を行うものであり，通信線を介して入力されるパケットを通過させて他の通信線に転送することにより，同一通信線上にない端末間またはその他のネットワーク機器間との通信を可能とする。例えば，端末Ｔ１〜Ｔ８相互間や，端末Ｔ１〜Ｔ８と通信線１０上のネットワーク機器間等の通信が可能となる。この意味において，ＨＵＢコントローラ４１がハブ手段を構成する。
【００４４】さらに，このＨＵＢコントローラ４１は，通過パケットを監視して各種のマネージメントデータを生成する。このマネージメントデータは，いわゆるパーティションエラーや，トラフィック過多や，コリジョン過多などのネットワークエラーを検出するためのソースデータであり，簡単な例を挙げればトラフィック過多を検出するためには単位時間あたりの通過パケット数をカウントすればよい。そして，生成されたマネージメントデータは後述するようにしてＣＰＵ４４に適宜読み込まれ，このＣＰＵ４４にて実際のエラー判定がなされる。
【００４５】ＬＡＮコントローラ４２は，ＨＵＢコントローラ４１を介して被通知端末２０，３０の常駐プログラムであるマネージャプログラム２１ａ，３１ａと独自のプロトコルに従って通信を行うものであり，次にこのプロトコルについて説明する。」（５頁７欄２２〜４５行）
　記載事項３
　「【００６０】以上のことから，被通知端末２０にエラー内容および設置情報を通知するためのＨＵＢコントローラ４１およびＬＡＮコントローラ４２とが通知手段を構成し，上記エラー通知プログラムを実行するＣＰＵ４４と，同エラー通知プログラムを記録したフラッシュメモリ４５と，ワークエリアとしてのＳＲＡＭ４６とが制御手段を構成する。」（６頁１０欄１５〜２１行）
　記載事項４
　「【００６８】集線装置４０のＨＵＢコントローラ４１は，常時，通信線を介して入力されるパケットを通過させて他の通信線に転送するとともに，通過パケットを監視して各種のマネージメントデータを生成している。
【００６９】ＣＰＵ４４は，電源投入後，まずチェックサムによるプログラムチェックや，ＳＲＡＭのビットチェックや，通信ポートＰ１〜Ｐ８のループバックチェックなど，ファームウェアを含めたハードウェアのエラーチェックを行うとともに，ＤＣ電源の電圧値を監視することによりＡＣ電源側の異常の有無を検知する（ステップＳ１１０）。
【００７０】エラーが検出されなければ（ステップＳ１２０），次に上記マネージメントデータを読み込み（ステップＳ１３０），フラッシュメモリ４５に記憶されたエラー内容設定情報に応じて同マネージメントデータからパーティションエラーや，トラフィック過多や，コリジョン過多や，ＣＲＣエラーの多発や，ショートパケットおよびロングパケットの多発や，ＩＦＧエラー多発のエラー解析を行う（ステップＳ１４０）。
【００７１】エラーが検出された場合（ステップＳ１２０，ステップＳ１５０），ＣＰＵ４４はエラー内容とフラッシュメモリ４５に記憶された設置情報とを，ＬＡＮコントローラ４２およびＨＵＢコントローラ４１を介してエラー通知先である被通知端末２０に通知する。図６のシーケンス図に示すように，被通知端末２０からのＡＣＫが返送されなければ，１０秒間待ってから再び同エラー内容と設置情報とを通知する。被通知端末２０からＡＣＫが返送された場合，所定のフラグをセットして同一のエラー内容を１０分間通知しないようにしてから（ステップＳ１６０），再び上述したようなハードウェアのエラーチェックを行い，以降，同様の処理を繰り返す。」（７頁１１欄１７行〜１２欄１行）
　上記摘記事項２中の段落段落【００４３】に，「ＨＵＢコントローラ４１」は「リピータハブ」としての動作を行うと記載されているから，リピータ機能部があり，
　同【００４４】には，「ＨＵＢコントローラ４１」は「トラフィック過多を検出するためには単位時間あたりの通過パケット数をカウント」すると記載されているから，カウントされたものは，当然，トラフィックカウンタ情報であり，
　上記摘記事項４を参照すると，「ＣＰＵ４４」，「フラッシュメモリ４５」及び「ＳＲＡＭ４６」からなる「制御手段」は，前記トラフィックカウンタ情報を取得してネットワーク状況の監視をしており，
　摘記事項３，４によれば，監視の結果としてエラー発生が検知されると，このエラー検知に係る「エラー発生情報」を「ＨＵＢコントローラ４１およびＬＡＮコントローラ４２」が「被通知端末」に送信している。
　したがって，上記摘記事項１〜４，及び関係図面である図１，図２，図４，並びにこの分野の技術常識を加味すると，引用刊行物１には，「リピータ機能部からトラフィックカウンタ情報を取得してネットワーク状況の監視を行う制御手段と，制御手段によるエラー発生検知でエラー発生情報を被通知端末に送信するＨＵＢコントローラ４１およびＬＡＮコントローラ４２とを備えている集線装置。」（以下，「引用刊行物１に記載された発明１」という。）が記載されている。
（３）対比
　本願補正発明１と引用刊行物１に記載された発明１を対比する。
　引用刊行物１に記載された発明１の「制御手段」はネットワーク状況の監視をしており，ネットワーク状況監視機能部であるから，記載表現は相違するものの，本願補正発明１の「ネットワーク状況監視機能部」と実質的に同じものであり，
　引用刊行物１に記載された発明１の「ＨＵＢコントローラ４１およびＬＡＮコントローラ４２」は，送信している以上，当然，送信機能部があり，
　引用刊行物１に記載された発明１の「集線装置」は，ネットワークで用いられているから，ネットワーク用ハブであり，
　本願補正発明１の「トラップ発生情報」も引用刊行物１に記載された発明１の「エラー発生情報」も，ともにイベント発生情報といえ，
　本願補正発明１の「指定メール宛先」は指定されたメールの宛先であり，引用刊行物１に記載された発明１の「被通知端末」はエラー情報の送信先であって，指定された宛先であるから，前者の「指定メール宛先」も後者「被通知端末」も，ともに指定宛先である。
　したがって，両者は，「リピータ機能部からトラフィックカウンタ情報を取得してネットワーク状況の監視を行うネットワーク状況監視機能部と，イベント発生情報を指定宛先に送信する送信機能部とを備えているネットワーク用ハブ。」である点で一致し，
　次の点で相違する。
　ａ）イベント発生情報を送信する契機に関して，本願補正発明１では「ネットワーク状況監視機能部によるトラップ発生検知」であるのに対し，引用刊行物１に記載された発明１では，「制御手段によるエラー発生検知」である点。
　ｂ）送信機能部における送信の手段として，本願補正発明１では「メール」を用いているのに対し，引用刊行物１に記載された発明１では，具体的な構成が不明である点。
　ｃ）指定宛先に関し，本願補正発明１では「指定メール宛先」であるのに対し，引用刊行物１に記載された発明１では，「被通知端末」である点。
　ｄ）送信機能部に関し，本願補正発明１では「メール送信機能部」であるのに対し，引用刊行物１に記載された発明１では，「ＨＵＢコントローラ４１およびＬＡＮコントローラ４２」である点。
（４）判断　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　相違点ａ）〜ｄ）について検討する。
　ネットワーク用ハブにおいて一般的に採用されているＳＮＭＰでは，通信ネットワークにおけるエラー等のイベント発生を通知するため，ネットワーク状況監視機能部によるトラップを用いており，このことは，特開平１０−５１４５１号公報，特開平１１−４２２２号公報，特開平９−２４７１４４号公報等に記載されているように，周知技術である。また，エラー等のイベント発生情報を通知するために，メールを用いることも，例えば，特開平１０−１７３６５５号公報，特開平８−２８６９９０号公報，特開平９−１３４２９７号公報，特開平９−３３０２８３号公報等に記載されているように，周知技術である。
　してみると，引用刊行物１に記載された発明１がハブに係るものあることから，上記ＳＮＭＰ対応とすることは，当業者であれば，最も普通に採用する技術的手段ということができるし，一方で，上記したように，エラー等のイベント発生情報を通知するために，メールを用いることも，周知技術であるから，イベント発生情報を送信する契機に関して，引用刊行物１に記載された発明１中の「制御手段によるエラー発生検知」を，「ネットワーク状況監視機能部によるトラップ発生検知」とし，そのトラップ発生情報をメールの形式にする程度のことに，格別な創意工夫を見出すことはできない。（相違点ａ），ｂ））
　また，エラー等のイベント発生情報を通知するためにメールを用いる場合，引用刊行物１に記載された発明１中の「被通知端末」をメール対応の「指定メール宛先」とすること，及び，引用刊行物１に記載された発明１中の「ＨＵＢコントローラ４１およびＬＡＮコントローラ４２」をメール対応の「メール送信機能部」とすることは，メールを利用する以上自明な事項でしかない。（相違点ｃ），ｄ））
　そして，本願補正発明１の作用効果も，引用刊行物１及び周知技術から当業者が予測できる範囲のものである。
　したがって，本願補正発明１は，引用刊行物１に記載された発明１に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
（５）むすび
　以上のとおり，本件補正は，特許法第１７条の２第５項で準用する同法第１２６条第５項の規定に違反するものであり，特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３　本願発明について
　平成１６年１２月２８日付けの手続補正は上記のとおり却下されたので，本願の請求項１，２に係る発明（以下，「本願発明１，２」という。）は，平成１６年９月１３日付けの手続補正により補正された明細書の特許請求の範囲の請求項１，２に記載された事項により特定される次のとおりのものである。
　「【請求項１】　リピータ機能部からトラフィックカウンタ情報を取得してネットワーク状況の監視を行うネットワーク状況監視機能部と，ネットワーク状況監視機能部によるトラップ発生検知でトラップ発生情報を指定メール宛先に送信するメール送信機能部とを備えていることを特徴とするネットワーク機器。
【請求項２】　リピータ機能部からトラフィックカウンタ情報を取得してトラフィック情報蓄積メモリに蓄積するトラフィック情報蓄積手段と，トラフィック情報蓄積メモリに蓄積されたトラフィック蓄積情報を必要に応じて読み出すためのトラフィック蓄積情報読み出し手段とを備えていることを特徴とするネットワーク機器。」
（Ａ）本願発明１に対して
（１）引用刊行物に記載された発明
　原査定の拒絶の理由に引用された引用刊行物１及びその記載事項は，前記「２」の「（２）」に記載したとおりである。
（２）対比・判断
　本願発明１は，前記「２」で検討した本願補正発明１の，「用ハブ」を上位概念である「機器」としたものである。
　そうすると，本願発明１の構成要件を全て含み，さらに下位概念化したものに相当する本願補正発明１が，前記「２」の「（４）」に記載したとおり，引用刊行物１に記載された発明１に基づいて当業者が容易に発明をすることができたものであるから，本願発明１も同様の理由により，引用刊行物１に記載された発明１に基づいて，当業者が容易に発明をすることができたものである。
（３）むすび
　以上のとおり，本願発明１は，引用刊行物１に記載された発明１に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
（Ｂ）本願発明２に対して
（１）引用刊行物に記載された発明
　原査定の拒絶の理由に引用された特開平１１−１２２１９８号公報（以下，「引用刊行物１」という。）には，前記「２」の「（２）」に，記載事項１〜４と摘記したとおりであって，
　このうち記載事項２中の段落【００４４】には，「生成されたマネージメントデータは後述するようにしてＣＰＵ４４に適宜読み込まれ」ると記載されており，そのためには，「マネージメントデータ」を蓄積しておくことが自明であるから，「トラフィック情報蓄積メモリ」及びその蓄積のための「トラフィック情報蓄積手段」が実質的に開示されている。
　また，記載事項４中の段落【００７０】には，「エラーが検出されなければ（ステップＳ１２０），次に上記マネージメントデータを読み込み（ステップＳ１３０），フラッシュメモリ４５に記憶されたエラー内容設定情報に応じて同マネージメントデータからパーティションエラーや，トラフィック過多や，コリジョン過多や，ＣＲＣエラーの多発や，ショートパケットおよびロングパケットの多発や，ＩＦＧエラー多発のエラー解析を行う（ステップＳ１４０）。・・・」と記載されており，トラフィックエラー解析を行う時には上記メモリからトラフィック蓄積情報を読み出すことは当然行うことであるので，引用刊行物１には「トラフィック情報蓄積メモリに蓄積されたトラフィック蓄積情報を読み出すためのトラフィック蓄積情報読み出し手段」が実質的に開示されている。
　したがって，引用刊行物１には，「リピータ機能部からトラフィックカウンタ情報を取得してトラフィック情報蓄積メモリに蓄積するトラフィック情報蓄積手段と，トラフィック情報蓄積メモリに蓄積されたトラフィック蓄積情報を読み出すためのトラフィック蓄積情報読み出し手段とを備えている集線装置。」（以下，「引用刊行物１に記載された発明２」という。）が記載されている。
（２）対比
　本願発明２と引用刊行物１に記載された発明２を対比すると，引用刊行物１に記載された発明２の「集線装置」は，ネットワーク機器の一種であるから，
　両者は，「リピータ機能部からトラフィックカウンタ情報を取得してトラフィック情報蓄積メモリに蓄積するトラフィック情報蓄積手段と，トラフィック情報蓄積メモリに蓄積されたトラフィック蓄積情報を読み出すためのトラフィック蓄積情報読み出し手段とを備えていることを特徴とするネットワーク機器」である点で一致し，
　次の点で相違する。
　トラフィック蓄積情報読み出し手段がトラフィック蓄積情報を読み出すタイミングとして，本願発明２は必要に応じて実行しているのに対し，引用刊行物１に記載された発明２は必要に応じて実行しているのか不明である。
（３）判断　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　相違点について検討する。
　通信ネットワークにおいて，トラフィック蓄積情報読み出し手段がトラフィック蓄積情報を読み出すタイミングとして，必要に応じて実行することは，例えば，特開昭６０−２３２７４０号公報に記載されているように，周知技術であり，その周知技術を引用刊行物１に記載された発明２に適用することに格別の困難性が存在しないので，上記相違点に係る構成は，当業者が容易に想到し得ることである。
　そして，本願発明２の作用効果も，引用刊行物１及び周知技術から当業者が予測できる範囲のものである。
　したがって，本願発明２は，引用刊行物１に記載された発明２に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができないものである。
　
　よって，結論のとおり審決する。