【事件の表示】
　特願２０００−５８４６７９「通信データを収集して分析する装置および方法」拒絶査定不服審判事件〔平成１２年　６月　２日国際公開、ＷＯ００／３１９６３、平成１４年　９月１７日国内公表、特表２００２−５３１０１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明
　
　本願は、平成１１年１１月２３日（パリ条約による優先権主張１９９８年１１月２４日、米国）を国際出願日とする出願であって、特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成２０年９月５日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
　「（ａ）第１の通信回線から第１のデータを受信するステップと、
　（ｂ）前記第１のデータを複数のパケットに分離するステップと、
　（ｃ）複数の連続する第２の期間について、
　　（i）前記複数の連続する第２期間の中のそれぞれの第２期間の中で、複数の連続する第１の期間の中の各々の第１の期間の間に受信されたパケットに対応する第１の統計情報を発生するステップと、
　　（ii）前記複数の連続する第１の期間の中の各々の第１の期間について発生された前記第１の統計情報を別々に記憶するステップと、
　　（iii）記憶された複数の前記第１の統計情報を集めることによって第２の統計情報を発生するステップと、
を含む、方法。」
　
　
２．引用発明および周知技術
　
Ａ．これに対して、当審の拒絶理由に引用された、浅羽登志也，「ネットワークの運用技術」，インターフェース，ＣＱ出版株式会社，１９９３年８月１日，第１９巻 第８号，ｐ．１１３−１３７（以下、「引用例」という。）には図面とともに以下の事項（イ．〜ニ．）が記載されている。
　
　イ．「４　トラフィックの統計収集
　ここまでは，比較的リアルタイムなモニタリングを行うためのツールを紹介してきました．ここでは，もう少し長い時間軸でネットワーク上の事象をモニタするものとして，統計情報の収集ツール“ＮＮＳｔａｔ”について紹介します．
４．１　ＮＮＳｔａｔの概要
　ＮＮＳｔａｔは，南カリフォルニア大学のＲｏｂｅｒｔ　Ｂｒａｄｅｎ らにより開発された，ＴＣＰ／ＩＰを用いた通信トラフィックの統計情報を収拾するためのツールです．基本的なアイデアは，イーサネットのようなマルチアクセス型の媒体上を通過する，すべてのＩＰパケットを拾いあげて，それらをあらかじめ指定しておいた方法で分類し，分類ごとのパケット数やバイト数のような統計を計算するものです．
　ＮＮＳｔａｔを用いることによって，インターネット上に分散した，いくつかのイーサネット・セグメントやポイント・ツー・ポイント・リンクを通過するＩＰトラフィックのさまざまな統計情報を同時に収集することが可能となります．また，どのような統計情報を収集するかは，インタラクティブに，もしくはコンフィグレーション・ファイルで柔軟に指定することが可能です．」（１３１頁右欄１〜２３行）
　
　ロ．「ＮＮＳｔａｔの概念
　ＮＮＳｔａｔは概念的には，ＳＡＡ（Ｓｔａｔｉｓｔｉｃｓ　Ａｑｕｉｓｉｔｉｏｎ　Ａｇｅｎｔ）とＳＣＨ（Ｓｔａｔｉｓｔｉｃｓ　Ｃｏｌｌｅｃｔｉｏｎ　Ｈｏｓｔ）の二つの部分から構成されています．
　ＳＡＡ（Ｓｔａｔｉｓｔｉｃｓ　Ａｃｑｕｉｓｉｔｉｏｎ　Ａｇｅｎｔ）
　ネットワーク上に複数個分散配置され，各々配置された場所におけるＩＰトラフィックを監視し，コンフィグレーション・ファイルによる指定にしたがって，統計情報の収集を行います．ｓｔａｔｓｐｙというプログラムが，この役割を果たします．
　ＳＣＨ（Ｓｔａｔｉｓｔｉｃｓ　Ｃｏｌｌｅｃｔｉｏｎ　Ｈｏｓｔ）
　分散配置された複数のＳＡＡを定期的にポーリングし，各ＳＡＡにおいて収集された統計情報を一ヵ所に集め，ファイルに格納します．ｃｏｌｌｅｃｔというプログラムがこの役割を果たします．
　図９に，ｓｔａｔｓｐｙおよびｃｏｌｌｅｃｔを用いたＮＮＳｔａｔによる統計情報の収集の基本概念を示します．ｓｔａｔｓｐｙとｃｏｌｌｅｃｔの関係は，ＳＭＮＰにおける管理エージェントと管理ステーションの関係に似ています．」（１３１頁右欄２４行〜１３２頁左欄１５行）
　
　ハ．「ｃｏｌｌｅｃｔによるｓｔａｔｓｐｙへのアクセス
　４．１節で解説したように，統計をとりたい各ネットワーク上でｓｔａｔｓｐｙプログラムを動かし，ｃｏｌｌｅｃｔプログラムにより遠隔ホスト上で動作するｓｔａｔｓｐｙプログラムからおのおので収集されている統計情報を１ヵ所に集めることができます．
　ｃｏｌｌｅｃｔによるアクセスの種類には，基本的につぎの２種類があります．
（１）ｒｅａｄ
　指定したオブジェクトの現在の値を読み出す．
（２）ｒｅａｄｃｌｅａｒ
　指定したオブジェクトの現在の値を読み出し，オブジェクトの保持するデータをクリアする．
　したがって，ｃｏｌｌｅｃｔによるｓｔａｔｓｐｙへのアクセスの戦略としては，
　１　比較的短い周期で各ｓｔａｔｓｐｙに対して必要なオブジェクトに対するｒｅａｄアクセスを行い，得られたデータをファイルに書き出す．
　２　上記よりも長い周期で各ｓｔａｔｓｐｙに対して必要なオブジェクトを指定したｒｅａｄｃｌｅａｒアクセスを行い，得られたデータをファイルに書き出す．
という方法をとるのがいいでしょう．」（１３４頁右欄１０行〜１３５頁左欄１２行）
　
　ニ．「ｃｏｌｌｅｃｔによって作られる統計情報
　ｃｏｌｌｅｃｔによって作られる統計情報のファイルは，ｓｔａｔｓｐｙが動作しているホストごとに，さらに，オブジェクトごとに分割されて作られます．それぞれのファイルに書き出される内容は，そのオブジェクトの名前，オブジェクトが定義された時刻（統計をとり始めた時刻），以前にｒｅａｄｃｌｅａｒされたときの時刻，現在の時刻，オブジェクトの内容などです．
　リスト１５には，ｃｏｌｌｅｃｔにより作成されるファイルの例を示します．
　この例では１時間ごとにオブジェクトＩＰをｒｅａｄｃｌｅａｒしており，たとえば時刻１：００から２：００の間に１９２．２４４．１７６．０から１３３．１６０．０．０へのＩＰパケットが６７６１６個あり，それらのパケットによって運ばれたデータ量が９２６３３９２バイトあったことがわかります．
　統計情報ファイルの利用法
　これ以外にも同様に，オブジェクトＴｅｌｎｅｔやＳＭＴＰなどの統計情報のファイルも同時に作られるので，それぞれのファイルの内容を総合すれば，各ネットワーク間で各アプリケーションによるトラフィックが，１時間ごとにどのくらいあったかを調べることができます．
　これらのファイルに書き込まれた統計情報を，ｐｅｒｌ［］などのスクリプトを用いることにより集計し，アプリケーション別のトラフィックの表を作ったり，グラフを描いたりすることができ，それにより，データを収集したネットワークにおけるトラフィックの傾向を把握することができます．構成管理やアカウント管理，場合によっては障害管理にも役立てることができます．
　図１０は，ＮＮＳｔａｔによって収集されたデータをｐｅｒｌのスクリプトにより１日分集計して，ｘｇｒａｐｈを用いてグラフ化したものです．
　このような集計・グラフ化を１日，１月，１年などの期間で行うことにより長期的なトラフィック量の変動や，その内訳を把握することができるのです．」（１３５頁左欄１３行〜１３７頁左欄１１行）
　
　上記イ．によれば、ＮＮＳｔａｔは、「媒体上を通過する，すべてのＩＰパケットを拾いあげて」おり、媒体が通信回線を意味していること、拾いあげるためには受信するステップがあることは明らかである。
　上記ハ．には、「ｃｏｌｌｅｃｔによるアクセス」のひとつである「ｒｅａｄｃｌｅａｒ」というアクセスについて、「指定したオブジェクトの現在の値を読み出し，オブジェクトの保持するデータをクリアする」ものであることが記載されており、「上記よりも長い周期で各ｓｔａｔｓｐｙに対して必要なオブジェクトを指定したｒｅａｄｃｌｅａｒアクセスを行い，得られたデータをファイルに書き出す．」との記載があることから、アクセス「ｒｅａｄｃｌｅａｒ」は所定の周期で連続的に行われることが理解できる。
　上記ニ．には、「ｃｏｌｌｅｃｔによって作られる統計情報」との記載、および上記ハ．の記載から、「ｒｅａｄｃｌｅａｒ」というアクセスによって、統計情報が作られることが理解できる。
　同じく、上記ニ．には、「１時間ごとにオブジェクトＩＰをｒｅａｄｃｌｅａｒ」した例として、「たとえば時刻１：００から２：００の間に１９２．２４４．１７６．０から１３３．１６０．０．０へのＩＰパケットが６７６１６個あり，」と記載されているから、「ｒｅａｄｃｌｅａｒ」というアクセスによって作られる統計情報は、複数の連続する所定の期間（１時間）の中の各々の所定の期間の間に受信されたパケット計数値を含んでいる。
　また、同じく上記ニ．には、「それぞれのファイルに書き出される内容は，そのオブジェクトの名前，オブジェクトが定義された時刻（統計をとり始めた時刻），以前にｒｅａｄｃｌｅａｒされたときの時刻，現在の時刻，オブジェクトの内容などです．」との記載があるから、時刻ごとに分けて読むことが可能な情報として別々に書き出されていることが理解できる。
　さらに、同じく上記ニ．には、「ＮＮＳｔａｔによって収集されたデータをｐｅｒｌのスクリプトにより１日分集計して，ｘｇｒａｐｈを用いてグラフ化」することが記載されているから、上記所定の期間より長い別の期間について、上記統計情報を集計して、グラフ化することが記載されている。
　そして、上記の例において所定の期間より長い別の期間（１日）は複数の所定の期間（１時間）を含んでいることは明らかである。
　
　したがって、上記引用例には以下の発明（以下、「引用発明」という。）が記載されている。
　
　「通信回線からパケットを受信するステップと、
　所定の期間より長い別の期間について、
　前記所定の期間より長い別の期間の中で、複数の連続する所定の期間の中の各々の所定の期間の間に受信されたパケット計数値を統計情報として作るステップと、
　前記作られた統計情報をファイルに別々に書き出すステップと、
　ファイルに書き出された複数の前記統計情報を集めることによってグラフ化するステップと
を含む、方法」
　
Ｂ．また、原審の拒絶査定に引用された、大岸智彦 他，「インターネット用パフォーマンスモニタの実装とその解析例」，電子情報通信学会技術研究報告，ＳＳＥ９８−９７，ＩＮ９８−７８，ＣＳ９８−９４，１９９８年９月２５日（以下、「周知例１」という。）には、図面とともに以下の事項（ホ．）が記載されており、また、同じく原審の拒絶査定に引用された、「遠隔ＬＡＮ監視システム「ＭＯＮＳＴＲＥ」」，コンピュータ＆ネットワークＬＡＮ，株式会社オーム社，第１５巻，第８号，１９９７年８月１日，ｐ．８−１０（以下、「周知例２」という。）には、図面とともに以下の事項（ヘ．）が記載されている。
　
　ホ．「
２．特徴
（１）イーサネットまたはＡＴＭ回線上を流れるフレームを長時間収集する。対象とするＭＡＣアドレスやＰＶＣを指定することにより、特定のルータ宛てのトラヒックのみを測定することも可能とする。
（２）ＯＣ３ＭＯＮ［２］などのパフォーマンスモニタが収集したフレームのヘッダを蓄積しオフラインで解析を行うのに対し、本モニタは、収集したフレームをリアルタイムに解析し、統計情報に加工して蓄積する。
（３）統計情報は、一定時間毎、ネットワークを識別する発着のＩＰアドレスまたはネットワークＩＤの組毎、アプリケーションを識別するサーバ側のポート番号毎に集計されたＩＰ、ＴＣＰ、ＨＴＴＰのプロトコル毎の情報から構成される。識別された個々の統計情報をトラヒックデータと呼ぶ。
（４）ＴＣＰの統計情報としては、コネクション毎の情報も収集する。このため、本モニタは、個々のＴＣＰのコネクションテーブルを管理する。
（５）長時間運用のために、過去のトラヒックデータは１日や１カ月単位にまとめ、データ量を圧縮する。
（６）トラヒックデータをもとに、特定の端末またはネットワークが送受信したＩＰパケットの総数、スループット、回線使用率、パケット再送率、さらには、トラヒック量が多いネットワークのリストなどの情報を加工して表示することができる。これらの解析結果はＧＵＩを用いて表示する。
（７）高速な回線上でフレームを取りこぼさないためには、フレーム収集機能と画面表示機能を別々のマシンで動作させ、ＣＰＵの負荷を分散させる必要がある。本モニタは、フレーム収集やトラヒックデータの作成を行うプロセス、ログ蓄積を行うプロセス、画面表示を行うプロセス、トラヒックデータの圧縮を行うプロセスとを独立に設ける。ソケットインタフェースを用いてトラヒックデータを転送することにより、フレーム収集とログの蓄積の機能を、同一あるいは別々のマシン上で動作させることができる。」（周知例１、５０ページ左欄２１行〜右欄１５行）
　
　ヘ．「【２】統計の収集
　統計画面ではパケットやオクテットの総数，長さ別，種類別，エラー別のパケット数を定期的に収集し，収集開始からの積算値と最新収集分の値，および最大値をカウンターで，そしてパケット数の推移を折れ線グラフで表示します。過去の状況を知りたい場合には，収集時間をクリックすることで，その時間までの値を知ることができます（図２）。
　また，プロトコル統計画面では，プロトコル・ディレクトリで登録した各プロトコルごとの積算値を表示し，これによりネットワークの作業別の利用状況が確認できます。対応プロトコルはＴＣＰ／ＩＰ，ＩＰＸ，ＮｅｔＢＩＯＳ，ＡｐｐｌｅＴａｌｋなど１２８種類あり，カスタマイズによって追加も可能です（図３）。
　【３】履歴の収集
　パケット数やエラー数，ネットワーク帯域の使用率を，指定した間隔で履歴として保持し，特定時間内の状況を収集時刻をクリックすることで参照できます。
　ユーザー・ヒストリ画面では，特定のＩＰアドレス，プロトコル，送信か受信かを指定して履歴をとることができます（図４）。」（周知例２、１０頁左欄１０行〜中欄１行）
　
　上記ホ．の特に（２）、（３）、（６）には、一定時間毎に集計された統計情報をもとに、ネットワークが送受信したＩＰパケットの総数の情報（新たな統計情報）を得ることが記載されており、また、上記ヘ．には、パケットの総数の情報を定期的に収集し、さらに収集開始からの積算値（新たな統計情報）を得ることが記載されている。
　
　したがって、「一定時間毎に集計された統計情報を、さらに該一定時間より長い時間で集計して新たな統計情報を発生すること」は、周知である。
　
　
３．対比
　
　本願発明と引用発明とを対比するに、
　ａ．引用発明の「所定の通信回線」、「所定の期間」、「統計情報」は、本願発明の「第１の通信回線」、「第１の期間」、「第１の統計情報」に対応する構成であって、それぞれの間に実質的な差異はない。
　ｂ．本願発明の「（ａ）第１の通信回線から第１のデータを受信するステップと、（ｂ）前記第１のデータを複数のパケットに分離するステップ」は、パケットを受信するステップであり、
　ｃ．引用発明の「所定の期間より長い別の期間」と、本願発明の「第２の期間」を対比すると、両者は、第１の期間（所定の期間）より長い別の期間である点で一致し、
　ｄ．引用発明の「パケット計数値」は、パケットに対応する情報であり、また、「統計情報として作る」ことは、統計情報を発生することに他ならない。
　ｅ．引用発明の「ファイルに書き出す」ことは、コンピュータ内でまとまった情報として保存可能な状態にすることを意味しているから、「記憶する」ことと実質的な差異はない。
　ｆ．引用発明の「記憶された複数の前記第１の統計情報を集めることによってグラフ化するステップ」において、グラフ化することは、第１の統計情報から新たな別の情報を発生させることである。
　
　したがって、本願発明と引用発明は、以下の点で一致ないし相違する。
　
＜一致点＞
　「第１の通信回線からパケットを受信するステップと、
　第１の期間より長い特定の期間について
　複数の連続する第１の期間の中の各々の第１の期間の間に受信されたパケットに対応する第１の統計情報を発生するステップと、
　前記複数の連続する第１の期間の中の各々の第１の期間について発生された第１の統計情報を別々に記憶するステップと、
　記憶された複数の前記第１の統計情報を集めることによって新たな別の情報を発生するステップと
を含む、方法」
　
＜相違点１＞
　「第１の通信回線からパケットを受信するステップ」について、本願発明は「（ａ）第１の通信回線から第１のデータを受信するステップと、（ｂ）前記第１のデータを複数のパケットに分離するステップ」であるのに対し、引用発明では「第１の通信回線からパケットを受信するステップ」である点。
　
＜相違点２＞
　「第１の期間より長い別の期間」について、本願発明は「複数の連続する第２の期間」であるのに対し、引用発明では「複数の連続する」期間であるか特定されていない点。
　
＜相違点３＞
　「新たな別の情報」について、本願発明は「第２の統計情報」であるのに対し、引用発明では「グラフ」である点。
　
　
４．当審の判断
　
　そこで、まず、上記相違点１について検討する。一般に、「パケットを受信する」ことは、通信回線を伝送されているデータを受信して、受信された該データからパケットヘッダ等の識別情報を認識することによって、複数のパケットに分離するステップを含んでおり、このことは、例を挙げるまでもなく当業者の技術常識であるから、本願発明の「（ａ）第１の通信回線から第１のデータを受信するステップと、（ｂ）前記第１のデータを複数のパケットに分離するステップ」は、引用発明の「パケットを受信するステップ」を当業者の技術常識に基づいて言い換えた程度のことにすぎず、技術常識の単なる付加にすぎない。
　ついで、上記相違点２について検討する。引用発明の「第１の期間より長い別の期間」は、第１の統計情報を集めることによって新たな別の情報を発生する区切りにすぎず、この「第１の期間より長い特定の期間」を複数連続して設けることは、必要に応じて任意に設定すればよい事項であるから、当業者であれば適宜なし得ることである。
　ついで、上記相違点３について検討する。例えば、上記周知例１、２等にも開示されているように、「一定時間毎に集計された統計情報を、さらに該一定時間より長い時間で集計して新たな統計情報を発生すること」は周知であるところ、該周知技術を引用発明に適用する上での阻害要因は何ら見あたらないから、引用発明において、「記憶された複数の前記第１の統計情報を集めることによって第２の統計情報を発生するステップ」とすることは、当業者であれば適宜なし得ることである。
　そして、複数連続して設けた第２の期間のそれぞれの中で、記憶された複数の前記第１の統計情報を集めることによって第２の統計情報を発生するようにしたことにより生じる効果は、引用発明および周知技術から当業者が容易に予測し得る程度のものに過ぎない。
　
　
５．むすび
　
　以上のとおり、本願発明は、上記引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。