【事件の表示】
　特願２００２−５３３０８２「通信情報記録装置及び方法」拒絶査定不服審判事件〔平成１４年　４月１１日国際公開、ＷＯ０２／２９５７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は、２００１年１０月３日（優先権主張２０００年１０月３日、日本国）を国際出願日とする出願であって、平成１８年９月２８日付け拒絶理由通知に対して、平成１８年１２月１日付けで手続補正がされたが、平成２０年９月８日付けで拒絶査定され、これに対し、平成２０年１１月４日に拒絶査定不服の審判が請求されるとともに、平成２０年１２月２日に手続補正がなされたものである。 
　 
第２　平成２０年１２月２日付けの手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
　平成２０年１２月２日付けの手続補正（以下、「本件補正」という。）を却下する。 
　 
［理由］ 
１．本件補正前及び本件補正後の本願発明 
　本件補正は、特許請求の範囲についてするもので、 
（１）本件補正前の請求項１及び請求項１０に「対象ネットワークを流れる全データ通信をパケットとして継続的に順次傍受し、当該傍受したパケットを所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する」とあったところを「対象ネットワークを流れる全データ通信を、パケットを単位として、蓄積前に、個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、当該傍受した複数のパケットに対し、所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する」と限定し、 
（２）本件補正前の請求項１及び請求項１０に「上記ワークメモリに蓄積したパケットを傍受ファイル名に基づいて読み出し」とあったところを「上記ワークメモリに蓄積した後に当該パケットを傍受ファイル名に基づいて読み出し」と限定し、 
（３）本件補正前の請求項１及び請求項１０に「パケットがもつ通信情報による解析を行い」とあったところを「個々のパケットがもつ情報による解析を行い」と限定し、 
（４）本件補正前の請求項１及び請求項１０に「その結果得られた解析結果データを通信項目ごとに通信項目データとして解析結果データベースに蓄積する」とあったところを「その結果得られた解析結果データを、通信項目ごとに、通信項目データとして、解析結果データベースに蓄積する」と読点を挿入し、 
（５）本件補正前の請求項１及び請求項１０に「上記対象ネットワークで行われた通信結果を確認する」とあったところを「上記対象ネットワークで行われた通信の内容及び結果を確認する」と限定するものである。 
　 
　よって、上記（１）〜（３）、（５）は特許法第１７条の２第４項第２号に掲げる事項を目的とするものであり、（４）は特許法第１７条の２第４項第４号に掲げる事項を目的とするものである。 
　そこで、本件補正後における特許請求の範囲に記載されている事項により特定される発明が、特許出願の際、独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）否かを、請求項１に係る発明（以下、「本願補正発明」という。）について以下に検討する。 
　 
　本願補正発明は、次のとおりのものである。 
「【請求項１】 
　対象ネットワークを流れる全データ通信を、パケットを単位として、蓄積前に、個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、当該傍受した複数のパケットに対し、所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する手段と、 
　上記ワークメモリに蓄積した後に当該パケットを傍受ファイル名に基づいて読み出し、個々のパケットがもつ情報による解析を行い、その結果得られた解析結果データを、通信項目ごとに、通信項目データとして、解析結果データベースに蓄積する手段と、 
　外部から与えられた検索リクエストに応じて上記解析結果データベースから該当するデータを抽出し、上記対象ネットワークで行われた通信の内容及び結果を確認する手段と 
　を具備することを特徴とする通信情報記録装置。」 
　 
２．引用例 
　原査定の拒絶の理由に引用された、本願の優先日前に頒布された刊行物である国際公開第００／０５８５２号（以下、「引用例１」という。）には、図面とともに、次の技術的事項が記載されている。 
（イ）「In addition, the system of FIGURE 1, may decode FTP, HTTP and TELNET, POP3, SMTP, NNTP, and IMAP sessions in near real time and/or after the fact. The modular architecture of the present invention allows plug-in modules to be added to further enhance and expand protocol decodes to include session reconstruction. This feature permits the analysis system 10 to automatically determine the context of information traveling on an Intranet. This information is then put into nodal diagrams for Network Security personnel to determine what information needs further protection. It also can be used to answer the questions like : are illegal businesses being conducted within the Intranet ; what if any harassment is taking place from an employee to another individual ; where are employees spending their time on the World Wide web. 」（第９頁第１９〜３３行）（訳： さらに、図１のシステムは、FTP、HTTP及びTELNET、POP3、SMTP、NNTP、及びIMAPセッションをほぼリアルタイムで及び/又は事後、デコードしてもよい。本発明のモジュラーアーキテクチャは、セッションリコンストラクションを含む、プロトコルデコードをさらに高く広げるプラグインモジュールが加えられることを許容する。この特徴により、該解析システム10は自動的にイントラネット上を行き来するインフォメーションの状況を識別することができる。それからこのインフォメーションは、どのインフォメーションがさらなる保護を必要とするかをネットワーク保安要員が識別するため、ノーダルダイアグラムの中に置かれる。また次のような質問に答えるために使用されることもできる：不法なビジネスがイントラネット内で行われているか；もしある従業員からもう一人の個人に対して何らかの嫌がらせが行われていたらどうするか；従業員はワールドワイドウェブのどこで時間を過ごしているか。）
（ロ）「Referring to FIGURE 3 there is shown the architecture of a typical discovery tool 12 of FIGURE 1 as illustrated in the application flow diagram of FIGURE 2. One or more sensors are controlled by means of a specialized sensor to provide setup, collection, and transmit control. For the local Ethernet sensor an Ethernet driver sits above the NDIS layer to provide raw packets of network data. Packets of data are queued by a sensor manager 32 and then provided to all the tools in a tool suite 34. An internal packet- processing engine 36 decodes data packets and converts the raw data to information elements that are accessible to all the tools in a tool suite 34. In addition, a script, engine 38 filters particularly interesting information and enters knowledge into the knowledge base 16. This database is also accessible by all the tools in the tool suite 34. 」（第１２頁第２６行〜第１３頁第３行）（訳：図３を参照すると、図２のアプリケーションフローダイアグラム中に示されるような図１の検知ツール１２の典型的なアーキテクチャーが示されている。特殊なセンサーによる、セットアップの提供、コレクション、及び制御の伝達により、１以上のセンサーがコントロールされる。ローカルなイーサネットセンサーのため、イーサネットドライバーは、NDISレイヤー上にあって、ネットワークデータの生パケットを提供する。データのパケットは、センサーマネジャー３２によりキューに入れられ、続いて、ツール一式３４中の全てのツールに提供される。内部パケットプロセッシングエンジン３６は、データパケットをデコードし、生データを、ツール一式３４中の全てのツールにアクセス可能である情報エレメントに転換する。さらに、スクリプトエンジン３８は、特に興味ある情報をフィルターし、知識を知識ベース１６に入れる。このデータベースはまた、ツール一式３４中の全てのツールによりアクセス可能である。）、 
（ハ）「The session recorder tool 92 enables packet reassembly, TCP/IP session management, and knowledge discovery. This tool is a mechanism for observing multiple session types which cannot easily be handled at the packet level, for example : HTTP, POP3, SMTP, SNMP, TELNET, NNTP, and IMAP. By reassembling packets and looking for key aspects of information across the reassembled packets, the session recorder tool 92 provides the capability for observing and learning about application level entities on the network.  
 In operation, the session recorder tool 92 reassembles connection-oriented flows, or sessions. These layer-4 (e. g., TCP) and above sessions consist of multiple packets, to be reassembled and parsed to expose application-level information. Packet and cell reconstruction techniques provide the user with state information (for example, call progress and session monitoring), as well as application layer information (for example, e-mail addresses).  
Utilizing session search techniques within the session recorder tool 92, combined with alert processing, capabilities (such as seeing when a certain user gets e-mail) can be flexibly constructed. In one implementation of a session recorder tool 92 there is provided viewing of the following sessions : HTTP, POP3, TELNET, FTP, SMTP, NNTP, and IMAP. During operation of the session recorder tool 92 data can be added to the knowledge base 16 as the tool detects, processes and scans sessions for various pieces of information. 」（第１６頁第８〜３５行）（訳： セッションレコーダツール９２は、パケットの再アセンブリー、ＴＣＰ／ＩＰセッションのマネージメント、および知識検知を可能にする。このツールは、パケットレベルでは容易に扱われ得ない複数のセッションタイプ、例えば、HTTP、POP3、SMTP、SNMP、TELNET、NNTP、およびIMAPを観察するためのメカニズムである。 
　パケットを再アセンブリーし、再アセンブリーされたパケットにわたって情報のキーアスペクトを探すことによって、セッションレコーダツール９２は、ネットワーク上のアプリケーションレベルエンティティーについての観察および学習のための能力を提供する。 
オペレーションにおいて、セッションレコーダツール９２は、コネクション指向型フロー、またはセッションを再アセンブリーする。これらのレイヤー４（例えば、TCP）以上のセッションは複数パケットからなり、再アセンブリーされ、アプリケーション−レベル情報を露出するよう解析される。パケットおよびセル再構築技術は、ユーザーに、状態情報（例えば、コールプログレスおよびセッションモニタリング）、並びにアプリケーションレイヤー情報（例えば、電子メールアドレス）を提供する。 
　アラートプロセッシングと組み合わせてセッションレコーダツール９２内のセッションサーチ技術を利用すると、能力（特定のユーザーが何時e-メールを得たか、を知るようなこと）は、フレキシブルに構築され得る。セッションレコーダツール９２の１つの実施では、次のセッション：HTTP、POP3、TELNET、FTP、SMTP、NNTP、およびIMAPを観察することが提供される。セッションレコーダツール９２のオペレーションの間、該ツールが、情報の様々な断片を求めてセッションを検出し、プロセスし、スキャンするにつれ、データは知識ベース１６に加えられ得る。） 
（ニ）「In addition to the tool suite 34, the discovery tool 12 includes a knowledge base parsing tool set 96 as shown in Figure 3.」（第１７頁第９〜１１行）（訳：ツール一式３４に加えて、検知ツール１２は、図３に示されるように、知識ベース解析ツールセット９６を含む。）、 
（ホ）「Individual tools in the knowledge base parsing tool set 96 are available to parse data from the knowledge base 16 and extract information from saved log files and reassembled session files. The knowledge base parsing tool set 96 comprises eight tools : KB parsing, E-mail extraction, session joining, web extraction, graphics extraction, KB summing, file manipulation, and column splitting. 
 The network discovery tool generates the knowledge base 16 of data assembled about a network. This data is stored in a flat text file and saved for reuse by the discovery tool 12 for display of a network. The format of the text, however, is not useful for follow on processing.  
The KB parsing tool, parses the data to be output for display in a columnar file, to be imported to a database, or to the analytical engines 20. In addition, the KB parsing tool is utilized as a key word search to generate data in various categories. 
 As explained, the session recorder tool 92 is a mechanism for observing multiple session types and generates files containing reassembled session data. The number of files created during a single data collection may, for example, exceed 10, 000. The E-mail extraction tool of a knowledge base tool in the tool set 96 provides for organizing POP3 and SMTP files into summary descriptions. The summary descriptions are then imported to a database or to the analytical engine 20. The E-mail extraction tool contains a key word search mechanism as well as other types of data parsing.  
 As mentioned, the discovery tool 12 generates a knowledge base of flat file data collected about a network.  
The web extraction tool of a knowledge base tool set 96 facilitates the parsing and formatting of data from HTML flat files that are then imported to a database or to the analytical engines 20. The web extraction tool contains a tag (similar to a key word) search mechanism as well as other types of data processing algorithms.  
 The graphics extraction tool of the knowledge base tool set 96 provides for reassembling image files from a recorded format. The display of the session recorder tool 92 provides for the recording of HTTP sessions. These session files contain a header describing the session and the data associated with the session. When a JPG or GIF image is downloaded, the data is reassembled in the session. However, this data is not displayable in the recorded format. The graphic extraction tool converts the reassembled HTTP session file containing JPG and GIF data and creates a new log file containing the names and images. 」（第１７頁第１６行〜第１８頁第２６行）（訳：知識ベース解析ツールセット９６中の個々のツールは、知識ベース１６からのデータの解析と、セーブされたログファイルおよび再アセンブリーされたセッションファイルからの情報の抽出とに利用可能である。知識ベース解析ツールセット９６は、８つのツール：知識ベース解析、電子メール抽出、セッションジョイニング、ウェブ抽出、グラフィックス抽出、知識ベースサミング、ファイルマニピュレーション、およびカラムスプリッティングを含む。 
　ネットワーク検知ツールは、ネットワークに関して集められたデータで知識ベース１６を作成する。このデータは、フラットテキストファイル中に貯蔵され、ネットワークの表示のため、検知ツール１２によって、再使用のためにセーブされる。しかしながら、テキストのフォーマットは、引き続く処理には有用でない。知識ベース解析ツールは、データが、ディスプレイ用にカラムファイル中にアウトプットされるよう、データベース、または解析エンジン２０にインポートされるよう、解析する。さらに、知識ベース解析ツールは、様々なカテゴリーのデータを作成するためのキーワードサーチとして、利用される。 
　説明されたように、セッションレコーダツール９２は、複数のセッションタイプを観察するためのメカニズムであり、再アセンブリーされたセッションデータを含むファイルを作成する。１つのデータ収集の間に作成されたファイルの数は、例えば、10,000を超えるかも知れない。ツールセット９６中の知識ベースツールに属する電子メール抽出ツールは、POP3およびSMTPファイルをサマリーディスクリプションに編成することを提供する。サマリーデスクリプションは、続いて、データベースまたは解析エンジン２０にインポートされる。電子メール抽出ツールは、キーワードサーチメカニズム並びに他のタイプのデータ解析を含む。 
　言及したように、検知ツール１２は、ネットワークについての集約されたフラットファイルデータで知識ベースを作成する。知識ベースツールセット９６のウェブ抽出ツールは、HTMLフラットファイルからのデータの解析およびフォーマット化を容易にし、それらは、続いて、データベースまたは解析エンジン２０にインポートされる。ウェブ抽出ツールは、タグ（キーワードに類似する）サーチメカニズム並びに他のタイプのデータプロセッシングアルゴリズムを含む。 
　知識ベースツールセット９６のグラフィックス抽出ツールは、記録されたフォーマットから画像ファイルの再アセンブリーを提供する。セッションレコーダツール９２のディスプレイは、HTTPセッションのレコーディングを提供する。これらのセッションファイルは、セッションを記述するヘッダとセッションに関連するデータとを含む。JPGまたはGIF画像がダウンロードされるとき、そのデータは、そのセッション中に再アセンブリーされる。しかしながら、このデータは、記録されたフォーマットではディスプレイ可能でない。グラフィック抽出ツールは、JPGおよびGIFデータを含む、再アセンブリーされたHTTPセッションファイルをコンバートし、名称と画像とを含む新しいログファイルを作成する。）
（ヘ）「The analysis system 10 of the present invention running on the terminal 46, monitors through the discovery tool 12 the Ethernet level inbound e-Mail. The analysis system 10 records inbound e-mail traffic as part of the knowledge base 16 such as post office protocol version 3 (POP3) and the simple mail transfer protocol (SMTP). In addition, the analysis system 10 examines meta data associated with inbound E-Mail and further examines SMTP/POP3 packets inbound to the target terminal 48. Identified SMTP/POPS packets inbound for the target terminal 48 are passed to the analytical engine 20 for analysis. As previously explained, the analytical engine 20 imports the meta data passed by the discovery tool 12 for analysis and display.」（第２１頁第７〜１９行）（訳：ターミナル４６上で実行される本発明の解析システム１０は、検知ツール１２により、イーサネットレベルの着信電子メールをモニタリングする。解析システム１０は、着信電子メールトラフィックを、ポストオフィスプロトコルバージョン３（ＰＯＰ３）及びシンプルメールトランスファプロトコル（ＳＭＴＰ）のような、知識ベース１６の一部として記録する。さらに、解析システム１０は、着信電子メールに関するメタデータを検査し、そしてその上、ターゲットターミナル４８に着信したＳＭＴＰ／ＰＯＰ３パケットを検査する。ターゲットターミナル４８に向けて着信したと特定されたＳＭＴＰ／ＰＯＰ３パケットは、解析のため解析エンジン２０に渡される。前に説明した通り、解析エンジン２０は、解析及び画面表示のため、検知ツール１２から渡されたメタデータをインポートする。）
（ト）「In this example the analysis system 10 as running on the terminal 70 monitors the level of intranet traffic and records packets of data from each of the terminals of the various nodes. 」（第２１頁第３０〜３３行）（訳：本例において、ターミナル７０上で実行中の解析システム１０は、イントラネットレベルのトラフィックをモニタリングし、種々のノードの各ターミナルからのパケットデータを記録する。） 
　また、引用例１ＦＩＧ．３には、TOOL SUITE 34（ツール一式３４）としてSESSION RECORDER 92（セッションレコーダ９２）が記載され、さらに、LOCAL SENSOR（ローカルセンサ）内の「NDIS」の上には、「PROMISCUOUS MODE PACKET DRIVER」（プロミスキャスモード　パケット　ドライバー）と記載されている。 
　以上の記載を総合すると、引用例１には，次の発明（以下、「引用例１記載発明」という。）が記載されていると認められる。 
「ローカルなイーサネットセンサーのためのイーサネットドライバーは、プロミスキャスモード　パケット　ドライバーであり、ネットワークデータの生パケットを提供し、内部パケットプロセッシングエンジン３６は、データパケットをデコードし、生データを、ツール一式３４の中の全てのツールにアクセス可能である情報エレメントに転換し、FTP、HTTP及びTELNET、POP3、SMTP、NNTP、及びIMAPセッションを、ほぼリアルタイムで及び/又は事後、プロトコルデコードすることができ、ツール一式３４の中のセッションレコーダツール９２は、例えば、次のセッションタイプ：HTTP、POP3、SMTP、SNMP、TELNET、NNTP、およびIMAPを観察するためのメカニズムであって、複数のパケットからなるセッションを再アセンブリーし、セッションは、アプリケーション−レベル情報を露出するよう解析され、ユーザーに、アプリケーションレイヤー情報(例えば、電子メールアドレス)を提供し、前記セッションレコーダツール９２はセッションデータを含むファイル、すなわちセッションファイルを作成し、知識ベース解析ツールセット９６中の個々のツールは、知識ベース１６からのデータの解析と、セーブされたログファイルおよび再アセンブリーされたセッションファイルからの情報の抽出とに利用可能であって、知識ベース解析ツールセット９６の電子メール抽出ツールは、キーワードサーチメカニズム並びに他のタイプのデータ解析を含み、POP3およびSMTPファイルをサマリーディスクリプションに編成することを提供し、知識ベースツールセット９６のウェブ抽出ツールは、HTMLフラットファイルからのデータの解析およびフォーマット化を容易にし、知識ベースツールセット９６のグラフィック抽出ツールは、JPGおよびGIFデータを含む、再アセンブリーされたHTTPセッションファイルをコンバートし、名称と画像とを含む新しいログファイルを作成する、ターミナル上で実行される解析システム。」
　
３．対比 
　本願補正発明を、引用例１記載発明と比較する。 
　引用例１記載発明において、「ローカルなイーサネットセンサー」の設けられた「イーサネット」が、本願補正発明の「対象ネットワーク」に相当する。
　次に、「プロミスキャスモード」とは、特開２０００−２７００４０号公報第５欄第３４〜３７行に「アドレスとは無関係に、すべてのパケットを取り込むようにし（これは、プロミスキャスモードと呼ばれ、パケット解析ツールなどで利用されているモードである）」と記載されているように、すべてのパケットを取り込むモードであるから、引用例１記載発明の「プロミスキャスモード　パケット　ドライバー」である「イーサネットドライバー」は、イーサネット上のすべてのパケットを取り込むように動作しているといえる。
　そして、本願補正発明でいう、「パケットを単位として、」「個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、」とは、当該記載についての補正の根拠である、本願の出願当初の明細書第５頁第１２〜１７行（「データストリームＤ０は、図３に示すように・・・、ワークメモリ１０に記憶する。」）、第２２頁第１１〜１３行（「以上の構成において、通信情報記録装置６（図１）は、・・・ワークメモリ１０に取り込み」）、及び図２、図３の記載よりみて、データストリーム（全データの流れ）を、細分化してパケットデータとして、そのまま取り込み、傍受することの言い換えに過ぎないと認められる。
　そして、本願補正発明において、「デコード」とは、パケットが規則的に持つ情報を抽出することを意味していると解されるところ、引用例１記載発明において、データパケットの「デコード」は「イーサネットドライバー」より後の「内部パケットプロセッシングエンジン３６」にて行われているから、引用例１記載発明において、「イーサネット」上のすべてのパケットを「プロミスキャスモード」の「イーサネットドライバー」が取り込んで「ネットワークデータの生パケット」を提供することが、本願補正発明の「対象ネットワークを流れる全データ通信」を「パケットを単位として、」「個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受」することに相当し、引用例１記載発明の「イーサネットドライバー」が「提供する」「ネットワークデータの生パケット」が、本願補正発明の「当該傍受した複数のパケット」に相当するものといえる。 
　次に、本願補正発明でいう「解析」とは、パケットの内容に関する情報の解析までも含む意味と解されるから、引用例１記載発明において、「セッションレコーダツール９２」が、複数の「セッションタイプ」（HTTP、POP3、SMTP、SNMP、TELNET、NNTP、およびIMAP）を「観察」し、「複数のパケットからなるセッション」を「再アセンブリー」すること、及び、該「セッション」を「アプリケーション−レベル情報を露出するよう解析」し、「ユーザーに、アプリケーションレイヤー情報(例えば、電子メールアドレス)を提供」することと、本願補正発明の「当該傍受した個々のパケットがもつ情報による解析を行」うことに相当する。
　次に、引用例１記載発明において、「セッション」を「アプリケーション−レベル情報を露出するよう解析」して「ユーザーに」「提供」される「アプリケーションレイヤー情報(例えば、電子メールアドレス)」が、本願補正発明の「その結果得られた解析結果データ」に相当する。
　次に、本願明細書において、メールヘッダＳ１３の「Ｔｏ」項目、「Ｃｃ」項目、「Ｆｒｏｍ」項目は「通信項目データ」とされている（例えば、「発明を実施するための最良の形態　（３）メールデータ解析処理手順」欄のステップＳＰ３６に関する説明参照。）から、引用例１記載発明の「アプリケーションレイヤー情報」として例示された「電子メールアドレス」は、本願補正発明の「通信項目データ」に相当する。よって、引用例１記載発明と本願補正発明とは「解析結果データは通信項目データを含んでいる」点で一致する。 
　次に、引用例１記載発明において、「解析システム１０」が実行される「ターミナル」が、後記の相違点は除いて、本願補正発明の「通信情報記録装置」に相当する。 
　
　すると、本願補正発明と引用例１記載発明とは、次の点で一致する。
＜一致点＞ 
　対象ネットワークを流れる全データ通信を、パケットを単位として、個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、当該傍受した複数のパケットに対し、個々のパケットがもつ情報による解析を行い、その結果得られた解析結果データは、通信項目データを含んでいる通信情報記録装置。
　 
　一方で、両者は、次の相違点１、相違点２の点で相違する。 
　 
＜相違点１＞ 
　本願補正発明では、
（ａ）「対象ネットワークを流れる全データ通信を、パケットを単位として、」
（ｂ）「蓄積前に、」
（ｃ）「個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、」
（ｄ）「当該傍受した複数のパケットに対し、所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する手段と、」
　を具備し、
（ｅ）「上記ワークメモリに蓄積した後に当該パケットを傍受ファイル名に基づいて読み出し」
（ｆ）「個々のパケットがもつ情報による解析」を行っている
　のに対し、引用例１記載発明では、データパケットの「デコード」を行う前に、「イーサネット」上のすべてのパケットを「プロミスキャスモード」の「イーサネットドライバー」が取り込んで「ネットワークデータの生パケット」を提供し（本願補正発明の、上記（ａ）及び（ｃ）に相当する。）、その後、該「ネットワークデータの生パケット」に対し、「デコード」を行い、「複数のパケットからなるセッションを再アセンブリー」し、該「再アセンブリーし」た「セッション」を「アプリケーション−レベル情報を露出するよう解析」し、「ユーザーに、アプリケーションレイヤー情報(例えば、電子メールアドレス)を提供」を行なっている（本願補正発明の、上記（ｆ）に相当する。）ものの、引用例１記載発明には、上記（ｄ）及び（ｅ）のとおり「当該傍受した複数のパケットに対し、所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する手段」を具備し、「上記ワークメモリに蓄積した後に当該パケットを傍受ファイル名に基づいて読み出し」て行うこと、及び、該「蓄積」が、上記（ｂ）のとおり上記（ａ）及び（ｃ）の「傍受」後であって、かつ（ｆ）の「解析」の前に行われることが記載されていない点。 
　 
＜相違点２＞ 
　本願補正発明では、「解析結果データを、通信項目ごとに、通信項目データとして、解析結果データベースに蓄積する手段と、外部から与えられた検索リクエストに応じて上記解析結果データベースから該当するデータを抽出し、上記対象ネットワークで行われた通信の内容及び結果を確認する手段とを具備」しているのに対し、引用例１記載発明では、「例えば、電子メールアドレス」（通信項目データ）を含む「アプリケーションレイヤー情報」（解析結果データ）を、「ユーザー」に提供しているものの、「アプリケーションレイヤー情報」（解析結果データ）を「電子メールアドレス」などの通信項目ごとに、通信項目データとして解析結果データベースに蓄積する手段と、外部から与えられた検索リクエストに応じて上記解析結果データベースから該当するデータを抽出し、上記対象ネットワークで行われた通信の内容及び結果を確認する手段とを具備していない点。
　 
４．判断 
＜相違点１＞について： 
　塩田紳二、ＨＡＣＫｉＮＧ ＳＴＡＲ ９９ 第５回、ＴＣＰ／ＩＰを観察せよ　ＰＡＲＴ２、インターネットＡＳＣＩＩ、第４巻、第８号、１９９９年８月１日、ｐ．２０６〜２０９に「tcpdumpの具体的な使用方法」として「“-r”と“-w”は対で使います。これは、 
tcpdump -w filename expression 
でパケットを解釈しないで（もちろんexpressionによるパケットの選択は行われます）、ファイルに書き出すものです。こうして作ったファイルを 
tcpdump -r filename 
を使って、あとでヘッダなどを解釈させて出力することができます。」（第２０７頁中欄第７〜１５行）、「最後に重要なのが“-s”オプションです。tcpdumpは標準では、パケットの先頭の69バイト（ヘッダ部分）のみを読み込み、後半は読み込みません。どんなパケットが流れているのかはヘッダだけで分かりますが、どんな内容なのかは、パケット本体を見ないことには分かりません。ただし、このパケット本体を解釈するには、TCP/IPより上のプロトコルを理解している必要があります。 
　フィルタ式
（filter expression） 
　tcpdumpでは、流れているパケットすべてを取り込むことができますが、これでは、数が多すぎて調べるのも大変です。多くの場合、特定のプロトコルやホストから出るパケットのみを観察することになるので、filter expressionを指定して、条件に合ったパケットのみを取り込むことにします。」（第２０７頁右欄第１３〜３０行）と記載され、また、「表１　tcpdumpのオプション」（２０７頁）中に、オプション「-r filename」の動作について「-wでファイルに記録されたファイルを読み込む。」と記載され、オプション「-w filename 」の動作について「パケットを解釈せずにそのままfilenameに出力する。」と記載され、オプション「-s snaplen」の動作について「各パケットを読み込み出力するサイズ（標準は先頭から69バイトのみを読み込む）」と記載されている。 
　そして、“-s”オプションを適宜の値に設定することで、パケット本体を読み込み得ること、filter expressionを指定せず全てのパケットを取り込み得ること、「ヘッダなどを解釈」することが、本願補正発明の「デコード」、つまり、パケットが規則的に持つ情報を抽出することに相当すること、「TCP/IPより上のプロトコルを理解して」「パケット本体を解釈する」ことが本願補正発明の「個々のパケットがもつ情報による解釈を行なうこと」に相当することは上記記載より明らかである。
　よって、対象ネットワークを流れる全パケットを、ヘッダなどを解釈せず（デコードせず）、そのままfilename（ファイル名）を付けて、記録（蓄積）する手段と、記録（蓄積）した後に当該パケットをfilename（ファイル名）に基づいて読み込み、「ヘッダなどを解釈」し、「TCP/IPより上のプロトコルを理解して」「パケット本体を解釈する」（個々のパケットがもつ情報による解釈を行なう）ことは、ネットワーク上のパケットを解析するツールとしてよく知られた「tcpdump」に用いられているとおり、周知技術であると認められる。 
　次に、Akira KATO, Jun MURAI, Satoshi KATSUNO, An Internet Traffic Data Repository: The Architecture and the Design Policy, In Proceedings of the INET'99. San Jose, Calif., June 22-25, 1999, 4. Technology, Measurement II, [online]、［平成２２年４月８日検索］、インターネットURL:http://web.archive.org/web/20000817030335/http://www.isoc.org/inet99/proceedings/4h/4h_1.htm、には、ネットワークのトラフィックを捕捉するシステムについて「The system consists of two processes, as shown in Figure 4. ntap process captures the traffic through a BPF, converts the data to an appropriate format, and writes the data to the file. ntap is configured with a list of file systems. When ntap changes the file to be output periodically, for example, once an hour, it checks the remaining space of the current file system. If necessary, it changes next available file system.」（4.Software structure欄）（訳：図４に示されるように、システムは２つのプロセスから成っています。ntapプロセスはBPF（当審注：BSD Packet Filterの略語）によってトラフィックを捕捉し、データを適切なフォーマットに変換し、ファイルにデータを書きます。ntapはファイルシステムのリストを含めて形成されます。ntapが、周期的に、例えば１時間に一度、出力されるファイルを変更する場合、それは現在のファイルシステムの残りのスペースをチェックします。必要ならば、それは次の利用可能なファイルシステムを変更します。）と、「捕捉されたトラフィックのデータの出力されるファイルを、周期的に、例えば１時間に一度、変更すること」が記載され、また、Simon Patarin, Messac Makpangou, Pandora:A Flexible Network Monitoring Platform , Proceedings of 2000 USENIX Annual Technical Conference, ２０００年６月（http://www.usenix.org/events/usenix2000/general/full_papers/patarin/patarin.pdf）には、純粋にパッシブな技術を用いてパケットを捕捉するネットワークモニタリングプラットフォームである「Ｐａｎｄｏｒａ」（Abstract欄第１文参照。）のモニタリングコンポーネントについて、「Table 1: Existing components and Packet types in Pandora. 」「Monitoring Componens」には、「Monitoring Components ・・・（中略）・・・Output Outputs packets to log files(dealing with file rotation),console or to another instance of Pandora through the network」（Table 1:Existing components and packet types in Pandora.）（訳：モニタリングコンポーネント・・・（中略）・・・出力　パケットを、ログファイル（ファイルローテーションを取り扱っている）、コンソール、又はネットワークを介してPandoraのもう一つの実体へ出力）と、「パケットを、ログファイル（ファイルローテーションを取り扱っている）に出力すること」が記載されている（なお、「ローテーション」については、谷口圭司、Ｗｅｂサーバー構築術、第６回、Ｗｅｂサーバーのログ・メインテナンス、ＵＮＩＸ　ＵＳＥＲ，第７巻、第２号、ソフトバンク株式会社、１９９８年２月１日、ｐ．９７〜１０５の「ログをある期間ごとに分別し、別々のファイルに保存する処理を、ログ・ローテーションという。」（第１０１頁左上欄第５〜６行）参照。）。 
　よって、トラフィックに関するデータをファイルに出力する際、所定の時間間隔ごとにファイルを変更して出力することは、周知技術であると認められる。 
　さらに、デ−タ蓄積媒体をＦＤ、ＨＤとするか、メインメモリ（ワークメモリ）とするかは、例えば、特開平６−２５２９２６号公報の【従来の技術】欄に「卓上パ−ソナルコンピュ−タを用いてバス上の電文受信を行ないながら受信電文デ−タの表示、蓄積を行なうことはパ−ソナルコンピュ−タのデ−タ蓄積媒体の動作速度が遅いためバス上の電文を取りこぼすなどの問題があり、又電文受信速度の高速化をはかるためには画面表示機能の削除や、デ−タ蓄積媒体をパ−ソナルコンピュ−タ上のＲＡＭ（メインメモリ）としなければならず、この場合、デ−タ蓄積媒体の容量がＦＤ、ＨＤなどに比較して少なくなるという問題があった。」と記載されているように、当業者が適宜選択しうることである。 
　よって、引用例１記載発明において、これらの周知技術を適用し、「プロミスキャスモード」にある「イーサネットドライバー」から「提供」される「ネットワークデータの生パケット」（傍受した複数のパケット）について、ヘッダなどを解釈せず（デコードせず）、そのままfilename（傍受ファイル名）を付けてメインメモリ（ワークメモリ）に、記録（蓄積）し、その記録（蓄積）を、ファイルを変更しつつ所定の時間間隔ごとにすること（上記＜相違点１＞に記載した本願補正発明の（ａ）（ｂ）（ｃ）（ｄ）に相当する。）、及び、上記メインメモリ（ワークメモリ）に記録すなわち蓄積した後、当該パケットをfilename（傍受ファイル名）に基づいて読み込み（上記＜相違点１＞に記載した本願補正発明の（ｅ）に相当する。）、その後、「ヘッダなどを解釈」し、「TCP/IPより上のプロトコルを理解して」「パケット本体を解釈する」こと（上記＜相違点１＞に記載した本願補正発明の（ｆ）に相当する。）は、当業者にとって容易になし得たことである。 
　 
＜相違点２＞について： 
　一般に、セッションデータの解析は各プロトコル毎に行われ（本願補正発明の一実施の形態においても、図２に記載されているように、各プロトコル（SMTP, POP3, HTTP）毎に解析サブルーチンＳＰ５、ＳＰ７、ＳＰ８が実行されている。）、その解析結果は各プロトコル毎の通信項目を含むものであるが、例えば、ＳＭＴＰに着目すると、番野邦彦、電子メール情報監視・分析ツール「ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔ」 私用メールか、業務メールか、内容を自動分別、情報端末、日本工業出版株式会社、平成１２年２月１日、第２巻、第２号、ｐ．７３〜７６（以下、「記事」という。）には、「１．電子メールの利用実態（問題点）」として「（１）私用メールの横行」「（２）セクハラの温床、足の引っぱり合い」「（３）機密情報の社外への漏洩」が示され、続いて、「４．電子メール情報監視・分析ツールＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔ 
　ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔは、パケットモニタ方式によりメールサーバが送受信するメールを監視する。既存のネットワークを変更する必要はなく、負荷もかからない。監視・分析結果は、管埋者ＰＣのＷｅｂブラウザで参照する。 
（１） ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔの機能 
ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔの基本機能を第１表にまとめる。
［１］メールの使用目的を分析する 
　電子メールの本文やＷｏｒｄ、Ｅｘｃｅｌなどの添付ファイルの日本語文章を分析し、業務メールか、私用メールか、その傾向を数値やグラフで示す。 
　第１図は、使用目的分析結果ログで、監視した各メールのヘッダー情報とともに、使用目的の評価結果を私用指数、業務指数、その他指数として数値で示す。私用指数が高いほど、私用メールの可能性が高くなる。」（第７５頁中欄第３〜２５行）（当審注：丸数字の１を［１］と記載した。）、 
「［３］メールを保存し内容を閲覧する 
　監視したメールの本体や添付ファイルをすべてディスクに自動保存する。必要があれば、管理者ＰＣのＷｅｂブラウザで内容を閲覧できる。添付ファイルについては、管理者ＰＣにダウンロードした上で対応するアプリケーション・ソフトで内容を確認する。ディスクに保存されたメールデータは、年単位、月単位または日単位でテープ等にバックアップすることができる。」（第７５頁右欄第３８行〜第７６頁左欄第７行）（当審注：丸数字の３を［３］と記載した。）、 
「ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔは、パケットモニタ方式により、監視対象のメールサーバが送受信する電子メールのパケット（ＳＭＴＰパケット）を監視する。」（第７６頁中欄第２８〜３２行）と記載され、さらに第７３頁の第１図には、「監視結果閲覧−メールログ閲覧・削除」、反転した「使用目的分析結果ログ」ボタン、「機密情報漏洩検査ログ」ボタン、「保存メールログ」ボタン、「バックアップログ閲覧」ボタンと、「年月の選択」の表示及び「１９９７年０６月」とのプルダウンと、「選択」ボタン及び「削除」ボタンと、「年月日の選択」との表示と「１９９７年０６月３０日（２７５件）」とのプルダウンと、「表示形式」との表示と「２０件ずつ表示」「すべてのメールを表示」とのラジオボタンと、「メールアドレス」との表示とその入力欄と、「閲覧」ボタン及び「削除」ボタンとが表示され、「１９９７年０６月３０日使用目的分析結果ログ（２７５件）」とのタイトルの下部に「時刻」、「サイズ」、「発信者（データとしては、「氏名＜メールアドレス＞」。以下同じ。）、標題、日付、受取人（メールアドレス）、同報者」、「業務指数」、「私用指数」、「その他指数」を項目及び項目データとした表形式のリストが表示されている。 
　そして、上記記事の上記記載を本願補正発明と対比すると、「メールの本体や添付ファイル」、「各メールのヘッダー情報」に含まれる「発信者（氏名＜メールアドレス＞）、標題、日付、受取人（メールアドレス）、同報者」が、本願補正発明でいう「解析結果データ」であって、「通信項目ごと」の「通信項目データ」に相当すること、以下、同様に、上記「メールの本体や添付ファイル」、「発信者、標題、日付、受取人、同報者」を保存する「ディスク」が、「解析結果データ」を「蓄積」した「解析結果データベース」に相当すること、「管理者ＰＣ」が、「ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔ」の設置されたハードウェアの「外部」にあること、「年月の選択」、及び「年月日の選択」や「メールアドレス」の入力を行い「閲覧」ボタンを押下することが、「検索リクエスト」に相当すること、表形式のリストとして表示された「使用目的分析結果ログ」が、メールによる通信が行われたことの証拠、すなわち「通信の結果」を確認する手段を提供していること、「管理者ＰＣのＷｅｂブラウザで内容を閲覧できる」手段が「通信の内容」を確認する手段に相当することは明らかである。
　よって、ＳＭＴＰに基づいた解析により得られたデータを、「メールの本体や添付ファイル」、「各メールのヘッダー情報」に含まれる「発信者（氏名＜メールアドレス＞）、標題、日付、受取人（メールアドレス）、同報者」として（解析結果データを、通信項目ごとに、通信項目データとして）として、ディスク（解析結果データベース）に保存（蓄積）する手段と、管理者ＰＣから「年月の選択」、及び「年月日の選択」や「メールアドレス」の入力を行い「閲覧」ボタンを押下すること（外部から与えられた検索リクエスト）に応じて上記ディスク（解析結果データベース）から該当するデータを抽出して、「使用目的分析結果ログ」を表示させ、管理者ＰＣのＷｅｂブラウザで内容を閲覧できる（上記対象ネットワークで行われた通信の内容及び結果を確認する手段を具備する）ようにすることは、上記記事によって紹介された電子メール情報監視・分析ツール「ＭａｉｌＧｕａｒｄｉａｎ／Ａｕｄｉｔ」によって周知であったものと認められる。 
　そして、引用例１記載発明が「キーワードサーチメカニズム並びに他のタイプのデータ解析を含」む「電子メール抽出ツール」を備えている点、及び引用例１の前記摘記事項（イ）に「不法なビジネスがイントラネット内で行われているか；もしある従業員からもう一人の個人に対して何らかの嫌がらせが行われていたらどうするか」と、ネットワークで行われた通信の内容及び結果を確認をすることの必要性が示唆されている点に鑑みれば、引用例１記載発明に上記周知技術を適用し、引用例１記載発明において、例えば、SMTPタイプの「セッションファイル」、すなわち「SMTPファイル」について、「アプリケーション−レベル情報を露出するよう解析」し、ユーザーに、「アプリケーションレイヤー情報(例えば、電子メールアドレス)」（解析結果データ）を提供する際、「アプリケーションレイヤー情報(例えば、電子メールアドレス)」（解析結果データ）を、「メールの本体や添付ファイル」、「各メールのヘッダー情報」に含まれる「発信者（氏名＜メールアドレス＞）、標題、日付、受取人（メールアドレス）、同報者」のデータとして（通信項目ごとに、通信項目データとして）、ディスク（解析結果データベース）に保存（蓄積）する手段と、管理者ＰＣから「年月の選択」、及び「年月日の選択」や「メールアドレス」の入力を行い「閲覧」ボタンを押下すること（外部から与えられた検索リクエスト）に応じて上記ディスク（解析結果データベース）から該当するデータを抽出して、「使用目的分析結果ログ」を表示させ、管理者ＰＣのＷｅｂブラウザで内容を閲覧できる（上記対象ネットワークで行われた通信の内容及び結果を確認する手段を具備する）ようにすることは、当業者にとって容易になし得たことである。 
　さらに、引用例１記載発明に記載された「HTTPセッションファイル」等の他のプロトコルのセッションファイルについても、「従業員はワールドワイドウェブのどこで時間を過ごしているか」（引用例１前記摘記事項（イ）参照。）といった質問に、ウェブ上のHTMLファイルや画像等を含めて答えるべく、上記周知技術に倣い、HTTP等に対応した解析を行い、その解析結果データを、「ワールドワイドウェブのどこ」かを特定するURLや、当該ウェブ上の「HTMLフラットファイル」、「画像」等のデータとして（通信項目ごとに、通信項目データとして）、データベース（解析結果データベース）に蓄積し、管理者ＰＣ（外部）から与えられた検索リクエストに応じて上記データベース（解析結果データベース）から該当するデータを抽出し、「従業員」が「ワールドワイドウェブ」で「時間を過ごしていた」証拠、及び「従業員」が「時間を過ごしてい」たワールドワイドウェブの場所、すなわちURLや、当該ウェブ上の「HTMLフラットファイル」、「画像」等（対象ネットワークで行われた通信の内容及び結果）を確認する手段を具備するようになすことも、当業者にとって容易になし得たことである。
 
　また、本願補正発明の作用効果も、引用例１記載発明及び周知技術から予測しうるものである。 
　 
５．本件補正についての結び 
　以上のとおり、本願補正発明は、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　 
第３　本願発明について 
１．本願発明 
　平成２０年１２月２日付けの手続補正は上記のとおり却下されたので、本願の請求項１〜１０に係る発明は、平成１８年１２月１日付け手続補正書により補正された明細書の特許請求の範囲の請求項１〜１０に記載された事項により特定されるとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。 
「【請求項１】 
　対象ネットワークを流れる全データ通信をパケットとして継続的に順次傍受し、当該傍受したパケットを所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する手段と、 
　上記ワークメモリに蓄積したパケットを傍受ファイル名に基づいて読み出し、パケットがもつ通信情報による解析を行い、その結果得られた解析結果データを通信項目ごとに通信項目データとして解析結果データベースに蓄積する手段と、 
　外部から与えられた検索リクエストに応じて上記解析結果データベースから該当するデータを抽出し、上記対象ネットワークで行われた通信結果を確認する手段と 
　を具備することを特徴とする通信情報記録装置。」 
　 
２．引用例 
　原査定の拒絶の理由で引用された引用例及びその記載事項は、前記「第２　［理由］２．」に記載したとおりである。 
　 
３．対比・判断 
　本願発明は、上記「第２　［理由］」で検討した本願補正発明から、 
（１）「対象ネットワークを流れる全データ通信を、パケットを単位として、蓄積前に、個々のパケットに対し情報の一部抽出、及びデコードをすることなく単位としての状態を維持し、かつ継続的に、順次傍受し、当該傍受した複数のパケットに対し、所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する」とあったところを「対象ネットワークを流れる全データ通信をパケットとして継続的に順次傍受し、当該傍受したパケットを所定の時間間隔ごとに傍受ファイル名を付けて、ワークメモリに蓄積する」と限定を解除し、 
（２）「上記ワークメモリに蓄積した後に当該パケットを傍受ファイル名に基づいて読み出し」とあったところを「上記ワークメモリに蓄積したパケットを傍受ファイル名に基づいて読み出し」と限定を解除し、 
（３）「個々のパケットがもつ情報による解析を行い」とあったところを「パケットがもつ通信情報による解析を行い」と限定を解除し、 
（４）「その結果得られた解析結果データを、通信項目ごとに、通信項目データとして、解析結果データベースに蓄積する」とあったところを「その結果得られた解析結果データを通信項目ごとに通信項目データとして解析結果データベースに蓄積する」と読点を削除し、 
（５）「上記対象ネットワークで行われた通信の内容及び結果を確認する」とあったところを「上記対象ネットワークで行われた通信結果を確認する」と限定を解除したものに相当する。 
　 
　すると、本願発明の発明特定事項を全て含み、更に他の要件及び読点を付加したものに相当する本願補正発明が前記「第２　［理由］４．」に記載したとおり、引用例１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。 
　 
４．むすび 
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。 
　従って、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。 
　よって、結論のとおり審決する。