【事件の表示】
　特願２００３−３８３３７１「マルチクラスのサービスネットワーク中でホップごとの一方向のパケット損失および遅延を得るための測定アーキテクチャ」拒絶査定不服審判事件〔平成１６年１０月１４日出願公開、特開２００４−２８９７９１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１５年１１月１３日（パリ条約による優先権主張　２００２年１１月２９日，米国）の出願であって，平成２１年１２月２１日付けで拒絶査定がなされ，これに対し，平成２２年４月２２日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［結論］
　平成２２年４月２２日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正（以下，「本件補正」という。）は，平成２１年１２月８日付け手続補正書の特許請求の範囲の請求項１に記載された
「パケットベースのネットワーク中でホップごとの一方向の性能特性を測定する方法であって，
　測定に含めるべきパケットのタイプを指定するための集約仕様を定義し，
　第１の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し，
　第２の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し，
　第３の点を流れるパケットについて関連するタイムスタンプを伴うパケットヘッダを生成し，
　対応するパケットヘッダに関連する前記タイムスタンプに応答して，前記集約仕様に従って１つまたは複数の性能測定値を計算する，
　ことを含む方法。」
という発明（以下，「本願発明」という。）を，
「パケットベースのネットワーク中でホップごとの一方向の性能特性を測定する方法であって，
　測定に含めるべきパケットのタイプを指定するための集約仕様を定義し，
　第１の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し，
　第２の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し，
　第３の点を流れるパケットについて関連するタイムスタンプを伴うパケットヘッダを生成し，
　対応するパケットヘッダに関連する前記タイムスタンプに応答して，前記集約仕様に従って１つまたは複数の性能測定値を計算する，
　ことを含み，
　前記第１の点が，ノードの入力インターフェースであり，前記第２の点が，前記ノードの出力インターフェースである，方法。」
という発明（以下，「補正後の発明」という。）に変更することを含むものである。
　
２．補正の適否
（１）新規事項の有無，補正の目的要件
　本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内において，本願発明の「第１の点」，「第２の点」について，「前記第１の点が，ノードの入力インターフェースであり，前記第２の点が，前記ノードの出力インターフェースである」という限定を付加して特許請求の範囲を減縮するものであるから，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び同第１７条の２第４項第２号（補正の目的）の規定に適合している。
　
（２）独立特許要件
　本件補正は特許請求の範囲の減縮を目的とするものであるから，補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下検討する。
　
ア．補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
イ．引用発明
　原査定の拒絶の理由に引用された特開２００２−１３５３１９号公報（以下，「引用例」という。）には図面とともに以下の事項が記載されている。
　
（ア）「【００３７】本発明の作用を述べる。ネットワークの入口及び出口において，データ単位を補足した時点で，そのデータ単位の内容（宛先，発信元，プロトコルクラス等）を判別するが，このとき，予め登録されている捕捉パケット判別データを参照することにより，宛先や発信元，プロトコルクラスといった単位で当該データ単位を対象としてサービス品質の測定を「する／しない」を判断できるようにする。これにより，不要な報告事象（サービス品質を測定する必要の無いデータ単位に対する事象報告）を削減することが可能となり，より高速に，効率良くサービス品質測定ができることになる。
（中略）
【００４１】そこで，ネットワークを構成するリンク（転送経路）の複数箇所に「測定プローブ」を設置しておき，パケットの転送方向別に報告事象を測定しておく。そして，ネットワーク入口において当該データ単位を検出した際に，ネットワークの出口に向けて選択的に事象報告を通知すると同時に，ネットワークの経由地点に対しても選択的に事象報告を通知することにより，ネットワーク全体のサービス品質を測定するだけでなく，ネットワークを構成する各リンク毎のサービス品質の測定ができることになる。
【００４２】このことより，ネットワークが提供するサービス品質が低下（伝送遅延が大きくなる，データ単位が損失する等）した場合，ネットワークを構成するどのリンク（転送経路）でサービス品質が低下したかを知ることができ，ネットワークのサービス品質上問題となっている箇所（ボトルネック）を推定するためのデータを入手することができる。」（５頁８欄〜６頁９欄）
　
（イ）「【００５１】以下，本発明の実施形態の動作につき説明する。先ず，サーバＡ２１よりサーバＣ２３に向けてデータ単位（以下，パケットとする）が送信された場合のサービス品質測定の動作について，図２のフローを用いて説明する。
【００５２】サーバＡ２１よりサーバＣ２３に向けて送出されたパケットは，アクセスリンク１２１を介してルータ１１に送られる。この際，当該パケットはパケット・モニタ部３０で分岐され測定プローブ３１のネットワーク流入パケット処理部３１０に送られる。そして，パケット捕捉部３１１で捕捉されると（ステップＳ１），直ちにタイムスタンプ生成部３１２で当該パケットが捕捉された時刻のタイムスタンプを付与される（ステップＳ２）。
【００５３】次に，パケット判別部３１３において捕捉パケット判別データ３１４（図４参照）を参照することにより（ステップＳ３），捕捉したパケットがサービス品質測定対象のパケットであるかを判別し（ステップＳ４），捕捉対象パケットのみ特徴量抽出部３１５に送る。
【００５４】パケット判別部３１３においては，パケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別する。これにより，サービス品質測定対象外の不要なパケットを削減する。その結果，後述するパケットの一致対検出処理において比較すべきデータを削減し，特徴量一致判定識別部３３１におけるより高速な一致対検索処理を実現する。
【００５５】特徴量抽出部３１５において，パケット判別部３１３より送られたパケットから特徴量を抽出する。この特徴量は，後述する特徴量一致判定識別部３３１におけるパケットの一致対検出処理において，ネットワーク出口で捕捉したパケットと比較する際に必要となる。抽出する特徴量としては，ネットワーク入口から入り，ネットワーク出口から出るパケットのうち，同一のパケットを識別することを目的とし，ヘッダ情報，ＣＲＣ（cyclic redundancy check ）情報，データの一部，データサイズ，アプリケーションクラス，宛先アドレス，発信元アドレスなどが考えられ，図１６（Ａ）にその特徴量の一例を示している。
（中略）
【００５７】図１６（Ａ）に示した特徴量は，データ単位であるパケットのＩＰヘッダの内容（但し，生存時間は除くものとする。これは，生存時間はネットワーク入り口と出口とでは，相違しているからである）と，ＩＰデータの一部であるものとする。このＩＰデータの一部は，図１６（Ａ）の例では，ＩＰテータの先頭か２５６ビットとしているが，先頭，中間及び末尾の所定ビットとしても良い。すなわち，同一宛先へのパケットが複数存在することが多いので，ＩＰヘッダのみを特徴データとして扱うと，ネットワーク入り口と出口ではこれ等全てが同一（一致）パケットと判定されてしまうので，これを避けるために，ＩＰデータの内容の一部をも特徴データとして抽出して比較するようにするのである。
【００５８】パケットについての特徴データは，宛先判別部３１６に送られる。宛先判別部３１６では，当該パケットの宛先情報とネットワーク構成データ３１７を照合して（ステップＳ６），当該パケットがネットワークから流出する地点に設置された測定プローブの位置を検出する（ステップＳ７）。そして，検出した測定プローブ（この場合は，測定プローブ３１’’）に対して，当該パケットの特徴データ（抽出した特徴量とタイムスタンプなど）を特徴データ送信部３１８より監視ネットワーク７０を経由して送出する（ステップＳ８，Ｓ９）。この特徴データの例が図１６（Ｂ）に示されており，タイムスタンプと，特徴量（図１６（Ａ））と，プローブ識別コードと，予備とからなる。プローブ識別コードは，パケットをモニタしたプローブを識別するための識別コードである。
（中略）
【００６１】ここで，アクセスリンク１２３において，当該パケットはパケット・モニタ部３０’’により検出され測定プローブ３１’’のネットワーク流出パケット処理部３２０’’に送られる。以下，図３のフローを参照しつつこのネットワーク流出パケット処理部の動作を説明する。
【００６２】パケット捕捉部３２１’’で捕捉されると（ステップＳ１２），直ちにタイムスタンプ生成部３２２’’で当該パケットが捕捉された時刻のタイムスタンプを付与される（ステップＳ１３）。次に，パケット判別部３２３’’において捕捉パケット判別データ３１４’’を参照することにより（ステップＳ１４），捕捉したパケットがサービス品質測定対象のパケットであるかを判別し（ステップＳ１５），捕捉対象パケットのみ特徴量抽出部３２４’’に送る。
【００６３】パケット判別部３２３’’においても，ネットワーク流入パケット処理部３１０に含まれるパケット判別部３１３と同様のパケット判別処理を行うことにより，パケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により捕捉対象パケットを選別する。
【００６４】この実施例では，流入パケットと流出パケットの判別基準が等しくなるように同一の捕捉パケット判別データを使用している。また，この捕捉パケット判別データは，システム全体で整合性がとれている必要があるため，上位制御データ管理装置からダウンロードするなどして，常にシステム全体で整合性がとれるように管理される。
【００６５】パケット判別部３２３’’から特徴量抽出部３２４’’に送られたパケットは，ネットワークの入口において捕捉したパケットと比較できるように，その特徴となる情報が抽出される（ステップＳ１６）。抽出された特徴量とタイムスタンプは特徴データとしてＱｏＳ処理部３３０’’に送られ，流出パケットバッファ３３６’’に蓄積される（ステップＳ１７，Ｓ１８）。図１７はこのパケットバッファに蓄積される情報の例を，特徴量と特徴データとの関係において示している。特徴データにバッファ蓄積時間が付加されて，対応するバッファへ蓄積される。
【００６６】パケットのネットワーク流入側特徴データを前述したように，流入側に位置する測定プローブ３１の特徴データ送信部３１８から監視ネットワーク７０を経由して送信し，流出側に位置する測定プローブ３１’’の特徴データ受信部３３２’’で受信する（ステップＳ１９）。流出側に位置する測定プローブ３１’’において受信した特徴データ（当該パケットがネットワークの流入アクセスリンクに設置された測定プローブにより検出され，抽出された特徴データ）は，ＱｏＳ処理部３３０’’の特徴量一致判定識別部３３１’’において流入パケットバッファ３３５’’に蓄積される（ステップＳ２０，Ｓ２１）。
【００６７】特徴量一致判定識別部３３１’’では，流出パケットバッファ３３６’’に蓄積された特徴データと，流入パケットバッファ３３５’’に蓄積された特徴データを比較することにより一致対を検出する（ステップＳ２２，Ｓ２３）。
（中略）
【００６９】そして，一致対を検出したら，その一致対のセットをＱｏＳ測定部３３３’’に送ると同時に，バッファから削除する。」（７頁１１欄〜８頁１４欄）
　
（ウ）「【００８３】ＱｏＳ測定部３３３’’では，一致対が通知されると，そのタイムスタンプの時刻差より伝送遅延時間を検出するなどのＱｏＳ情報処理を行う（ステップＳ２４）。そしてＱｏＳ情報としてＱｏＳ情報送信部３３４’’より監視ネットワーク７０を介して上位ＱｏＳ管理装置５０に送信する（ステップＳ２５，Ｓ２７）。なお，タイムスタンプの時刻差より伝送遅延時間を検出するなどのＱｏＳ情報処理は，上位ＱｏＳ管理装置側で実施することもできる。」（９頁１６欄〜１０頁１７欄）
　
（エ）「【０１１３】ここで，測定したいサービス品質は，ネットワークのどの部分が提供するものであるかを考えると，事業所Ａから事業所Ｂまでの接続全体が提供するサービス（「被測定ネットワーク１０−１」＋「測定対象”外”ネットワーク１１」＋「被測定ネットワーク１０−２」が提供するサービス品質）が考えられる。しかし，複数のネットワークを経由した接続全体が提供するサービス品質だけでは，サービス品質が低下した際に，そのボトルネックとなっている箇所を特定することができない。
【０１１４】そのため，事業所Ａから事業所Ｂまでの接続を構成しているネットワーク個々のサービス品質を測定したいという要求がある。これは，ネットワーク個々のサービス品質を測定することにより，どのネットワークでサービス品質が低下しているのかが明確になり，適切な対処が可能となるからである。
【０１１５】この要求を満たすために，本実施例では，２種類の測定プローブを使用している。一つは測定プローブ（エッジ）３１ａ，３１ｄであり，二つ目は測定プローブ（コア）３１ｂ，３１ｃである。
【０１１６】測定プローブ（エッジ）３１ａ，３１ｄは，送信元サーバからネットワークに流入する地点，及びネットワークから宛先サーバに向けて最終的に流出する地点（ネットワークのエッジ，すなわちアクセスリンクであることが多い）に設置される。測定プローブ（コア）３１ｂ，３１ｃは，ネットワークを乗り換える地点や，ネットワークを構成するリンク部分（コアリンク）に設置される。
【０１１７】測定プローブ（エッジ）３１ａ，３１ｄでは，パケットがネットワークに流入した時刻，及び流出した時刻を測定する。測定プローブ（コア）３１ｂ，３１ｃでは，パケットがその地点を通過した時刻を測定する。これらの時刻（流入時刻，Ａ地点通過時刻，Ｂ地点通過時刻，…，ｘ地点通過時刻，流出時刻）を相互に比較することにより，事業所Ａから事業所Ｂまでの接続全体が提供するサービス品質だけでなく，パケットが経由した個々のネットワークのサービス品質や，さらには，個々のネットワークを構成するリンクのサービス品質を測定することが可能になるという効果が得られる。」（１２頁２２欄〜１３頁２３欄）
　
ａ．上記（ア）の【００４１】の「ネットワーク全体のサービス品質を測定するだけでなく，ネットワークを構成する各リンク毎のサービス品質の測定ができることになる。」，上記（イ）の【００５１】の「先ず，サーバＡ２１よりサーバＣ２３に向けてデータ単位（以下，パケットとする）が送信された場合のサービス品質測定の動作について，図２のフローを用いて説明する。」，上記（エ）の【０１１４】の「これは，ネットワーク個々のサービス品質を測定することにより，どのネットワークでサービス品質が低下しているのかが明確になり，適切な対処が可能となるからである。」の記載によれば，引用例にはネットワーク及びネットワークを構成する各リンク毎のサービス品質を測定することが記載されており，送信されるデータ単位はパケットであるから前記ネットワークはパケットベースのものといえ，サーバＡ２１よりサーバＣ２３に向けた送信におけるサービス品質の測定であるから一方向性の測定といえる。したがって，引用例には「パケットベースのネットワーク中で一方向のサービス品質を測定する方法」が記載されていると認められる。
ｂ．上記（ア）の【００３７】，上記（イ）の【００５３】，【００５４】，【００６２】，【００６３】，【００６４】には，パケット判別部３１３，３２３’’が「同一の捕捉パケット判別データ３１４を参照することにより」「パケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別する」ことが記載されている。したがって，「捕捉パケット判別データ」は，サービス品質の測定をする捕捉対象パケットを選別するためのものであり，図４の記載を参照すれば，「発信元アドレス，宛先アドレス，アプリケーション・クラスを含む」ものと認められる。そして，上記【００６４】には「捕捉パケット判別データ」は，システム全体で整合性がとれている必要があるため，「上位制御データ管理装置からダウンロードするなどして，常にシステム全体で整合性がとれるように管理される。」ことが記載されている。
ｃ．上記（イ）の【００５２】の「サーバＡ２１よりサーバＣ２３に向けて送出されたパケットは，アクセスリンク１２１を介してルータ１１に送られる。この際，当該パケットはパケット・モニタ部３０で分岐され測定プローブ３１のネットワーク流入パケット処理部３１０に送られる。そして，パケット捕捉部３１１で捕捉されると（ステップＳ１），直ちにタイムスタンプ生成部３１２で当該パケットが捕捉された時刻のタイムスタンプを付与される（ステップＳ２）。」の記載によれば，ルータ１１の流入パケットについてパケットが捕捉された時刻のタイムスタンプを付与することが記載されている。ここで，上記（ア）の【００４１】，【００４２】，上記（エ）の記載によれば，流入パケットとは，ネットワーク全体としての流入パケットのみならず，個々のネットワーク，個々のリンクの流入パケットを含み得ることは明らかである。したがって，引用例には「ルータの流入パケットについてパケットが捕捉された時刻のタイムスタンプを付与する」ことが記載されていると認められる。。
ｄ．上記（イ）の【００５５】には特徴量抽出部３１５がパケット判別部３１３より送られたパケットから特徴量を抽出することが記載されており，同【００５７】の「特徴量は，データ単位であるパケットのＩＰヘッダの内容（中略）と，ＩＰデータの一部であるものとする。」の記載によれば，少なくともパケットのＩＰヘッダから特徴量が抽出されるといえる。そして，同【００５８】の「検出した測定プローブ（この場合は，測定プローブ３１’’）に対して，当該パケットの特徴データ（抽出した特徴量とタイムスタンプなど）を特徴データ送信部３１８より監視ネットワーク７０を経由して送出する（ステップＳ８，Ｓ９）。」の記載によれば，引用例には「選別されたパケットのＩＰヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データ」が「生成」されていると認められる。
ｅ．上記（イ）の【００６１】〜【００６３】の記載によれば，ネットワーク流出側の測定プローブ３１’’においても，ネットワーク流入側の測定プローブ３１と同様の処理がなされるから，上記ｂ．〜ｄ．を参酌して，引用例には「流出パケットについてパケットが捕捉された時刻のタイムスタンプを付与し，前記捕捉パケット判別データを参照することによりパケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別し，選別されたパケットのヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データを生成」することが記載されていると認められる。
ｆ．上記（イ）の【００５８】，【００６１】，【００６５】，【００６６】，図１の記載によれば，流入パケットに係る特徴データは流出側に送信され流入パケットバッファ３３５’’に蓄積され，流出パケットに係る特徴データは流出側の流出パケットバッファ３３６’’に蓄積される。そして，上記（イ）の【００６７】の「特徴量一致判定識別部３３１’’では，流出パケットバッファ３３６’’に蓄積された特徴データと，流入パケットバッファ３３５’’に蓄積された特徴データを比較することにより一致対を検出する」，同【００６９】の「一致対を検出したら，その一致対のセットをＱｏＳ測定部３３３’’に送る」，上記（ウ）の「ＱｏＳ測定部３３３’’では，一致対が通知されると，そのタイムスタンプの時刻差より伝送遅延時間を検出するなどのＱｏＳ情報処理を行う」の記載によれば，引用発明は「一致対の特徴データのタイムスタンプの時刻差より伝送遅延時間を検出する」ことが記載されていると認められる。
　　
　したがって，以上の記載からみて，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認められる。
「パケットベースのネットワーク中で一方向のサービス品質を測定する方法であって，
　発信元アドレス，宛先アドレス，アプリケーション・クラスを含む捕捉パケット判別データを，上位制御データ管理装置からダウンロードするなどして，常にシステム全体で整合性がとれるように管理し，
　ルータの流入パケットについてパケットが捕捉された時刻のタイムスタンプを付与し，前記記捕捉パケット判別データを参照することによりパケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別し，選別されたパケットのＩＰヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データを生成し，
　流出パケットについてパケットが捕捉された時刻のタイムスタンプを付与し，前記捕捉パケット判別データを参照することによりパケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別し，選別されたパケットのＩＰヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データを生成し，
　一致対の特徴データのタイムスタンプの時刻差より伝送遅延時間を検出する，方法。」
　
ウ．対比・判断
（ア）まず，補正後の発明の「測定に含めるべきパケットのタイプを指定するための集約仕様を定義し」について，本願明細書の発明の詳細な説明の「上流ノード２０を通過して流れるどのパケットをトレースするかを指定するために，フローの定義を行う。」（【００２５】），「フィルタ回路３２および４０は，定義済みの集合体中のパケット，すなわちフローの定義に合致するパケットをグループ化する。フローの定義は，たとえば，ＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｃｏｄｅ  Ｐｏｉｎｔ，差別化サービスコードポイント），ソースアドレス，宛先アドレス，またはこれらのパラメータの任意の組合せを含むことができる。トレース生成回路３４および４２は，定義済みの集合体に属するパケットヘッダレコードのトレースを作成する。」（【００２７】），「フローをパケットの集合体として定義し，フローの定義に属するパケットだけを識別しフィルタにかける受動的測定技術を使用することにより，ホップごとの一方向パケット損失の測定を実施する。」（【００３４】），「フィルタ回路８０は，集約仕様に従ってパケットヘッダレコードをグループ化することによって分類を実施する。トレース生成回路８２は，各集合体に属するパケットヘッダレコードのトレースを作成する。」（【００３７】）の記載によれば，上記「測定に含めるべきパケットのタイプを指定するための集約仕様」とは，一方向の性能特性を測定するパケットを識別するためのものであり，ＤＳＣＰ，ソースアドレス，宛先アドレス，またはこれらのパラメータの任意の組合せを含むことができるものと認められる。
　一方，引用発明の「捕捉パケット判別データ」により規定される「パケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件」はサービス品質の測定をする捕捉対象パケットを選別するためのものであるから，補正後の発明の「測定に含めるべきパケットのタイプを指定するための集約仕様」に相当するものである。そして，「発信元アドレス，宛先アドレス，アプリケーション・クラスを含む捕捉パケット判別データを，上位制御データ管理装置からダウンロードなどして」「管理すること」は，常にシステム全体で整合性がとれるようにするためであることに鑑みれば，補正後の発明の「集約仕様を定義」することに相当する。
　したがって，「測定に含めるべきパケットのタイプを指定するための集約仕様を定義し」の点で両者に差異は無い。
（イ）まず，補正後の発明の「・・・の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し」なる構成について，本願明細書の発明の詳細な説明の【００２６】の「入力観測回路２４の
ヘッダコピー回路２８は，
ヘッダ情報のレコードを作成する
ヘッダコピー回路３６は，
ヘッダ情報のレコードを作成する
レコード５０は，
タイムスタンプフィールド５６，およびパケットヘッダ５８を含む
　一方，引用発明は，「ルータの流入パケットについてパケットが捕捉された時刻のタイムスタンプを付与」し，また，「流出パケットについてパケットが捕捉された時刻のタイムスタンプを付与」するものであり，タイムスタンプの付与の後，捕捉パケット判別データに基づく条件により選別され，「選別されたパケットのＩＰヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データ」が生成されるものである。したがって，引用発明は，タイムスタンプの付与後，選別前に，流入パケット及び流出パケットのＩＰヘッダのヘッダ情報にタイムスタンプが追加されたもの（すなわち，前記レコードに相当するもの。）が存在すると解するのが自然である。また，ルータ１１の流入パケットは「ノードの入力インターフェースを流れるパケット」といえ，当該流入パケットが捕捉される点を「第１の点」と称するのは任意である。
　したがって，「第１の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを生成し」，「前記第１の点が，ノードの入力インターフェースであり」の点で両者に差異は無い。
（ウ）引用発明の流出パケットは，データネットワークの一方向の性能特性を測定するために捕捉され，タイムスタンプが付され，選別されたパケットのヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データが生成されるものであり，当該流出パケットの捕捉される点を「第３の点」と称するのは任意であるから，下記の相違点１，２は別として「第３の点を流れるパケットについて関連するタイムスタンプを伴うパケットヘッダを生成し」の点で両者に差異は無い。
（エ）引用発明は「パケットが捕捉された時刻のタイムスタンプを付与し，前記捕捉パケット判別データを参照することによりパケットの宛先や発信元，パケットのアプリケーション・クラス（Telnet，FTP ，HTTPなど）といった条件により，捕捉対象パケットを選別し，選別されたパケットのＩＰヘッダから抽出した特徴量とタイムスタンプなどからなる特徴データを生成し」，「一致対の特徴データのタイムスタンプの時刻差より伝送遅延時間を検出する」ものであるから，当該検出処理は補正後の発明の「集約仕様」に相当する「条件」に従ったものといえる。そして，前記「タイムスタンプの時刻差」は計算により求められることは自明であり，前記「伝送遅延時間」は「性能測定値」に含まれることは明らかである。
　したがって，引用発明の「一致対の特徴データのタイムスタンプの時刻差を計算する」ことは，補正後の発明の「対応するパケットヘッダに関連する前記タイムスタンプに応答して，集約仕様に従って１つの性能測定値を計算する」ことに相当する。
　
　したがって，補正後の発明と引用例に記載された発明（以下，「引用発明」という。）とを対比すると，両者は，以下の点で一致し，また，相違している。
（一致点）
「パケットベースのネットワーク中で一方向の性能特性を測定する方法であって，
　測定に含めるべきパケットのタイプを指定するための集約仕様を定義し，
　第１の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを
生成し，
　第３の点を流れるパケットについて，関連するタイムスタンプを伴うパケットヘッダを
生成し，
　対応するパケットヘッダに関連する前記タイムスタンプに応答して，前記集約仕様に従って１つの性能測定値を計算する，
　ことを含み，
　前記第１の点が，ノードの入力インターフェースである，方法。」
　
（相違点１）
　補正後の発明はホップごとの一方向の性能特性を測定する方法であるのに対し，引用発明はホップごとに測定することについて言及していない点。
　
（相違点２）
　補正後の発明は第２の点を流れるパケットについて関連するタイムスタンプを伴うパケットヘッダを生成し，前記第２の点が前記ノードの出力インターフェースであり，第２の点に係るタイムスタンプも用いるのに対し，引用発明はネットワークの入口と出口の２点のタイムスタンプのみを用いる点。
　
（相違点３）
　補正後の発明は「１つまたは複数の性能測定値を計算する」ものであるのに対し，引用発明は複数の性能測定値については明らかにされていない点。
　
　以下，上記相違点について検討する。
（相違点１についての検討）
　引用発明は，隣接ルーター間の伝送遅延時間を検出することを包含するものであり（引用例の図６参照。），また，サービス品質が低下した際に，そのボトルネックとなっている箇所を特定することができるように，ネットワーク全体のサービス品質を測定するだけでなく，ネットワークを構成する各リンク毎のサービス品質の測定ができるようにするものである。ここで，遅延や異常の発生個所を容易に特定するためにノード毎の受信及び／又は送信時間情報を測定することは周知（例えば，原査定の拒絶の理由に引用された特開２００２−１３５２６２号公報の【００１０】，実施の形態５の特に【００６１】，【００６４】，【００６７】，図６〜８，及び特表２０００−５０７７７９号公報の要約，１４頁１６行〜１５頁２２行，Ｆｉｇ．３参照。）であることに鑑みれば，引用発明においても，更に細かく遅延発生箇所を特定するためホップごとの一方向の性能特性を測定するようにすることは，当業者が必要に応じて適宜なし得ることである。
　
（相違点２についての検討）
　ホップごとの遅延がノード内の遅延とノード間の遅延とからなることは当業者における技術常識であり，ノード内の遅延を計算するためにノード毎の受信及び送信時間情報を測定することは周知（例えば，原査定の拒絶の理由に引用された特開２００２−１３５２６２号公報の【００１０】，実施の形態５の特に【００６１】，【００６４】，【００６７】，図６〜８，及び特表２０００−５０７７７９号公報の要約，１４頁１６行〜１５頁２２行，Ｆｉｇ．３参照。）であるから，引用発明においても，更に細かく遅延発生箇所（ノード内又はノード間）を特定するためノードの入力インターフェース，出力インターフェース及び隣接ノードのインターフェースの３点のタイムスタンプを用いるようにすることは，当業者が必要に応じて適宜なし得ることである。
　
（相違点３についての検討）
　「１つまたは複数の性能測定値を計算する」は「１つの性能測定値を計算する」又は「複数の性能測定値を計算する」の選択的な記載であるところ，引用発明は前者に相当するから，相違点３は実質的な相違ではない。
　
　そして，補正後の発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測できる範囲のものである。
　
　したがって，補正後の発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
３．結語
　したがって，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２２年４月２２日付けの手続補正は上記のとおり却下されたので，本願発明は，上記「第２．補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は，上記「第２．補正却下の決定」の項中の「２．補正の適否」の項中の「（２）独立特許要件」の項中の「イ．引用発明」の項で認定したとおりである。
　
３．対比・判断
　そこで，本願発明と引用発明とを対比するに，本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると，本願発明の構成に当該補正に係る限定を付加した補正後の発明が，上記「第２．補正却下の決定」の項中の「２．補正の適否」の項中の「（２）独立特許要件」の項中の「ウ．対比・判断」の項で検討したとおり，引用発明及び周知技術に基づいて容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
　
４．むすび
　以上のとおり，本願発明は，引用発明び周知技術に基づいて当業者が容易に発明をすることができたものと認められるから，特許法第２９条第２項の規定により，特許を受けることができない。
　
　よって，結論のとおり審決する。