【事件の表示】
　平成　９年特許願第５３７５３４号「インターネット・プロトコル・フィルタ」拒絶査定不服審判事件〔平成　９年１０月３０日国際公開、ＷＯ９７／４０６１０、平成１１年　７月２７日国内公表、特表平１１−５０８７５３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　　
　本願は平成９年４月２３日（パリ条約による優先権主張外国庁受理１９９６年４月２４日、アメリカ合衆国）の出願であって、平成１４年３月２５日付けで審判請求がなされ、特許法第１７条の２第１項第３号の規定により、平成１４年４月２４日付けで手続補正がなされたものである。　
　　
第２．平成１４年４月２４日付けの手続補正について
　　
［補正却下の決定の結論］
　平成１４年４月２４日付けの手続補正を却下する。
　　
［理由］
　　
１．本件手続補正の内容
　平成１４年４月２４日付けの手続補正（以下、「本件手続補正」という。）は、補正前特許請求の範囲における請求項１、１０を削除し、請求項２〜９の項番を１〜８に変更し、請求項１１〜１２の項番を９〜１０に変更する補正を含むものである。これにより、補正前請求項１を引用する請求項２が補正後請求項１となり、そのため補正前請求項１を引用する請求項８は、引用していた請求項１が削除されたことにより、補正後請求項１を引用する請求項７となった。したがって、補正後請求項７は、補正前には含んでいなかった補正前請求項２の構成を付加したことになるから限定に当たる。また、同様に、補正前請求項８を引用する請求項９は、補正後請求項８となり、補正後請求項８は、補正前には含んでいなかった補正前請求項２の構成を含むこととなるから限定に当たる。
　また、本件手続補正は、補正前請求項２の「宛先情報」、「ソース情報」を、補正後請求項１の「宛先アドレス」、「ソース・アドレス」とする補正を含むものであり、「情報」を下位概念の「アドレス」にすることから限定に当たる。
　
２．本件手続補正の適否の検討
　本件手続補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてするものであるから、特許法第１７条の２第３項の規定に適合する。また、特許請求の範囲についてする補正は、本件手続補正が、特許法第１７条の２第４項第２号に規定する、特許請求の範囲の減縮を目的とするものであるので、本件手続補正により補正された特許請求の範囲の請求項１に記載された発明が独立して特許を受けることができるのか否かについて以下、検討する。
　　
３．特許法第２９条第２項についての検討
　　
（１）本件手続補正により補正された特許請求の範囲の請求項１に記載された発明（以下、「補正後の発明」という。）は、次のとおりのものである。 　
「第１のデータ通信ネットワークと第２のデータ通信ネットワークをインタフェースするインターネット・プロトコル・フィルタを動作させる方法において： 
　　（ａ）　第２のネットワーク内のノードに対応する宛先アドレスと第１のネットワーク中のノードに対応するソース・アドレスとを有するデータ・パケットを第１のネットワークから受信し、 
　　（ｂ）　データ・パケットからのソース・アドレスをルックアップ・テーブルにエントリとしてストアし、ソース・アドレスに関連するフィルタ・ノード・ポート値は、前記ルックアップ・テーブルにインデックスされることよってソース・アドレスを維持し、 
　　（ｃ）　データ・パケット内で、ソース・アドレスをフィルタ・ノードのアドレスと置き換え、 
　　（ｄ）　置き換えられたソース・アドレスを有するデータ・パケットを第２のネットワークに送り、それによってそのパケットは対応の第２のネットワーク・ノードにルーティングされ、 
　　（ｅ）　置き換えられたソース・アドレスを有するデータ・パケットに応じて、第２のネットワークからの戻りパケットを受信し、 
　　（ｆ）　戻りパケット内で、宛先アドレスと維持されたソース・アドレスとを置き換え、 
　　（ｇ）　置き換えられた宛先アドレスを有する戻りパケットを第１のネットワークに送り、それによってそのパケットは対応の第１のネットワーク・ノードにルーティングされ、 
　前記の戻りパケットを受信するステップは、さらに、そのデータ・パケット内の宛先アドレスの宛先ポートが、維持されたソース・アドレスと関連がなかった場合、第２のネットワークから受信されたデータ・パケットを無視することを特徴とするインターネット・プロトコル・フィルタを動作させる方法。」　
　　
（２）引用文献及び周知技術 
　　
（ア）これに対して、原査定の拒絶の理由に引用された、本願の優先権主張の日前である平成８年４月１日に頒布されたソフトバンク株式会社発行、「ＵＮＩＸ　ＵＳＥＲ　第５巻第４号（１９９６年４月号）」の特別付録ＣＤ−ＲＯＭ、「ＬｉｂＣＤ　Ｖｏｌ．２５」内収録ファイル/RENSAI/LINUX/LINUX135.TGZに含まれるlinux/net/ipv4/ip_fw.c、linux/include/linux/ip_fw.h、/linux/include/linux/ip.h等）（以下「引用例」という。）には、次の事項が記載されている。 
（なお、本審決添付の「参考資料」は、引用例であるＣＤ−ＲＯＭに含まれるプログラム・ファイル（linux/net/ipv4/ip_fw.c、linux/include/linux/ip_fw.h、/linux/include/linux/ip.hをプリントアウトしたものである。原文には、行番号は記載されていないが、審決との対比を容易にするために、左端に「１：」「２：」・・・と行番号を加筆してある。また、ＣＤ−ＲＯＭ中のプログラムにおいて、使用される空白記号やタブ記号は、一部省略して記載している。）
　 
（Ａ）プログラム・ファイルlinux/net/ipv4/ip_fw.c
（Ａ１）プログラムip_fw.cの第１〜６行には、
「/* 
* IP firewalling code. This is taken from 4.4BSD. Please note the  
* copyright message below. As per the GPL it must be maintained 
* and the licenses thus do not conflict. While this port is subject 
* to the GPL I also place my modifications under the original  
* license in recognition of the original copyright.  
」と記載されており、これらの注釈をまとめると、以下のようになる。
　以下のプログラムは、ＩＰのファイアウォールのプログラム・コードである。 
 　
（Ａ２）プログラムip_fw.cの第５３６〜５４４行には、
「/* 
* Create a new masquerade list entry, also allocate an 
* unused mport, keeping the portnumber between the 
* given boundaries MASQ_BEGIN and MASQ_END. 
* 
* FIXME: possible deadlock if all free ports are exhausted!  
*/ 
static struct ip_masq *alloc_masq_entry(void) 
{ 
」と記載されており、これらの注釈と動作をまとめると、以下のようになる。
　新しいマスカレード・リスト・エントリをつくる。MASQ_BEGINとMASQ_ENDの間のポート番号で、使われていないmportを割り当てる。 
　ip_fw_masqueradeで用いられる（（Ａ１０）参照）alloc_masq_entryという名前の関数（サブルーチン）の記述がここから始まる。
  　
（Ａ３）プログラムip_fw.cの第７９０〜７９１行には、 
「 
void ip_fw_masquerade(struct sk_buff **skb_ptr, struct device *dev) 
{ 
」と記載されており、これらの動作をまとめると、以下のようになる。
　ファイアウォールのマスカレードの動作を記述したip_fw_masqueradeという名前の関数（サブルーチン）がここから始まる。
　 　
（Ａ４）プログラムip_fw.cの第７９８〜８０３行には、
「 /* 
* We can only masquerade protocols with ports... 
*/ 
　　
if (iph-protocol!=IPPROTO_UDP  iph-protocol!=IPPROTO_TCP) 
return; 
」と記載されており、これらの注釈と動作をまとめると、以下のようになる。
　ＩＰヘッダ（iph）（ＩＰパケットの先頭部分、下記（Ｃ）を参照）を調べて、プロトコル（iph-protocol）がＵＤＰでもＴＣＰでも無い場合は、ip_fw_masqueradeという名前の関数（サブルーチン）からリターンする。つまり、ip_fw_masqueradeを終了する。 
　 　
（Ａ５）プログラムip_fw.cの第８０５〜８０７行には、
「 /* 
* Now hunt the list to see if we have an old entry 
*/ 
」と記載されており、これらの注釈をまとめると、以下のようになる。
　古いエントリがあるか探索する。
　 　
（Ａ６）プログラムip_fw.cの第８１８〜８１９行には、 
「 while (ms!=NULL)  
{ 
」と記載されており、これらの動作をまとめると、以下のようになる。
　msがNULLでない間（つまり、ポインタ（アドレス）msがNULLでない有効なアドレス値を持っている間）、下記（Ａ７）から（Ａ８）のループを繰り返す。 
　 　
（Ａ７）プログラムip_fw.cの第８２０〜８２６行には、 
「 if (iph-protocol == ms-protocol  
iph-saddr == ms-src  iph-daddr == ms-dst  
portptr[0] == ms-sport  portptr[1] == ms-dport)  
 { 
・・・
break; 
} 
」と記載されており、これらの動作をまとめると、以下のようになる。
　もし、ＩＰヘッダのプロトコル、ソース・アドレス、宛先アドレス、発信元ポート、宛先ポートがいずれも、現在、ポインタmsが指示しているエントリと一致しない場合は（Ａ８）に移行し、一致する場合は、「・・・」の処理を行い、そして、（Ａ６）からのループ処理を終了してループを抜け出だす（break）。すなわち、（Ａ９）に進む。 
　　
（Ａ８）プログラムip_fw.cの第８２７行〜８２８行には、
「 ms = ms-next; 
} 
」と記載されており、これらの動作をまとめると、以下のようになる。
　ポインタmsが指示しているエントリを次のエントリに更新して、（Ａ６）まで戻る。なお、次のエントリが無い場合には、nextがNULLなので、msはNULLとなり、（Ａ６）まで戻るが「while (ms!=NULL)」の判断の結果、（Ａ７）から（Ａ８）は実行されずに、次の（Ａ９）に移る。 
　つまり、（Ａ６）から（Ａ８）で、ＩＰヘッダのプロトコル、ソース・アドレス、宛先アドレス、発信元ポート、宛先ポートが一致する古いエントリがあるか探索する。つまり、パケットが事前に登録されているか探索する。 
　 　
（Ａ９）プログラムip_fw.cの第８３０〜８３２行には、
「 /* 
* Nope, not found, create a new entry for it 
*/　 
」と記載されており、これらの注釈をまとめると、以下のようになる。 
　見つからない場合は、新しいエントリを作る。 
　 
（Ａ１０）プログラムip_fw.cの第８３４〜８４７行には、 
「  
 if (ms==NULL)  
｛ 
ms = alloc_masq_entry(); 
・・・
ms-protocol = iph-protocol; 
ms-src = iph-saddr; 
ms-dst = iph-daddr; 
ms-sport = portptr[0]; 
ms-dport = portptr[1]; 
}  
」と記載されており、これらの動作をまとめると、以下のようになる。 
　もし、 msがNULLの場合（一致するものが見つからなかった場合）、以下の処理を行う。
　マスカレードのリスト構造に新しいエントリをアロケート（割り当て）して、そのポインタ（アドレス）をmsに代入する。（上記（Ａ２）を参照。） msを用いて、ＩＰヘッダの情報（プロトコル、ソース・アドレス、宛先アドレス、発信元ポート、宛先ポート　下記（Ｄ）を参照）を、msの各々の対応する場所へ代入することで、メモリ上に記録・維持する。このとき、mport（即ち、ms-mport）は、上記（Ａ２）を参照すると、 alloc_masq_entryを実行した時点で、MASQ_BEGINとMASQ_ENDの間で、使われていない新しいポート値が割り当てられている。 そして、portptr[0]をms-sport（発信元ポート）、portptr[1]をms-dport（宛先ポート）に対応させている。
　 　
（Ａ１１）プログラムip_fw.cの第８５７〜８９７行には、
「 /* 
* Adjust packet accordingly to protocol 
*/ 
・・・
｝
」と記載されており、これらの注釈と動作をまとめると、以下のようになる。
　パケットをプロトコルにしたがって調整する。 「・・・」の処理を行い、ip_fw_masqueradeの動作終了。
　　
（Ａ−１）上記（Ａ１）から（Ａ１１）のまとめ　 
　（Ａ１）から（Ａ１１）では、プロトコルがＵＤＰ又はＴＣＰのパケットに対して、パケットが事前に登録されているか探索する（Ａ８）。パケットが事前に登録されていなければ、新しいエントリをリスト構造に割り当て（Ａ１０）、パケットからのソース・アドレス（（Ａ１０）のiph-saddr）と新しいポート値（mport）を同じ新しいエントリに登録し記憶・維持する。そして、その新しいエントリにＩＰヘッダの情報を登録し記録・維持することが記載されている（Ａ１０）。 
　よって、ソース・アドレスと新しいポート値、発信元ポート、宛先ポートとを、同じエントリに記録することは、関連づけているから、「パケットからのソース・アドレスをリスト構造にエントリとして記憶し、ソース・アドレスに関連するポート値は、前記リスト構造にリンクしたエントリ内に記憶することによってソース・アドレスを維持している」が記載されている。 
　 
（Ｂ１）プログラムip_fw.cの第８９８〜９０６行には、 
「  
/* 
* Check if it's an masqueraded port, look it up, 
* and send it on it's way... 
* 
* Better not have many hosts using the designated portrange 
* as 'normal' ports, or you'll be spending lots of time in 
* this function. 
*/」と記載されており、これらの注釈をまとめると、以下のようになる。 
　マスカレードされたポートなら、調べ、そして、送る。また、使用法の注意が記載されている。 
　 
（Ｂ２）プログラムip_fw.cの第９０８〜９０９行には、 
「int ip_fw_demasquerade(struct sk_buff *skb_ptr) 
{ 
」と記載されており、これらの動作をまとめると、以下のようになる。 
　ファイアウォールのip_fw_demasqueradeという名前の関数（サブルーチン）がここから始まる。
　 
（Ｂ３）プログラムip_fw.cの第９１５〜９２１行には、 
「 if (iph-protocol!=IPPROTO_UDP  iph-protocol!=IPPROTO_TCP) 
return 0; 
・・・
 if (ntohs(portptr[1])  PORT_MASQ_BEGIN || 
ntohs(portptr[1])  PORT_MASQ_END) 
return 0; 
」と記載されており、これらの動作をまとめると、以下のようになる。
　もし、ＩＰヘッダを調べて、プロトコルがＵＤＰでもＴＣＰでもない場合は、数値０を戻り値としてip_fw_demasqueradeからリターンする。つまり、ip_fw_demasqueradeを終了する。 そして、パケットヘッダのportptr[1]（宛先ポート）が、所定の範囲内（PORT_MASQ_BIGINからPORT_MASQ_ENDの間)でなければ、数値０を戻り値としてip_fw_demasqueradeからリターンする。つまり、ip_fw_demasqueradeを終了する。（注：ntohs() 関数は unsigned short integer netshort をネットワークバイトオーダーからホストバイトオーダーに変換する。i80x86 のホストバイトオーダーでは最下位のバイトが先に配置されるが、 インターネットで用いられるネットワークバイトオーダーでは最上位のバイトが先に配置される。） 
　 
（Ｂ４）プログラムip_fw.cの第９２９〜９３８行には、 
「 
/* 
* reroute to original host:port if found... 
* 
* NB. Cannot check destination address, just for the incoming port. 
* reason: archie.doc.ac.uk has 6 interfaces, you send to 
* phoenix and get a reply from any other interface(==dst)! 
* 
* [Only for UDP] - AC 
*/ 
」と記載されており、これらの注釈をまとめると、以下のようになる。 
　もし、見つかれば、元の host:portにリルートする。
　 
（Ｂ５）プログラムip_fw.cの第９４０〜９４１行には、 
「 while (ms!=NULL)  
{ 
」と記載されており、これらの動作をまとめると、以下のようになる。 
　msがNULLでない間（つまり、ポインタ（アドレス）msがNULLでない有効なアドレス値を持っている間）、（Ｂ６）から（Ｂ７）のループを繰り返す。 
　 
（Ｂ６）プログラムip_fw.cの第９４２〜９４６行には、 
「 if (iph-protocol==ms-protocol  
(iph-saddr==ms-dst || iph-protocol==IPPROTO_UDP)   
(ms-dport==htons(FTP_DPORT_TBD) || portptr[0]==ms-dport)  
portptr[1]==ms-mport) 
{ 
」と記載されており、これらの動作をまとめると、以下のようになる。 
　下記ａ）〜ｄ）が全て満たされた場合、（Ｂ７）以下の処理を行う。一致しない場合は（Ｂ９）に移行する。
ａ）ＩＰヘッダのプロトコルがmsのプロトコルと一致 
ｂ）ＩＰヘッダのソース・アドレス（iph-saddr）がmsの宛先アドレス（ms-dst）と一致するか、または、ＩＰヘッダのプロトコルがＵＤＰ 
ｃ）msの宛先ポートがFTP_DPORT_TBDであるか、または、発信元ポートに対応するportptr[0]（（Ａ１０）参照）がmsの宛先ポートと一致 
ｄ）宛先ポートに対応するportptr[1]（（Ａ１０）参照）がmsのmportと一致 
（注：htons() 関数は unsigned short integer hostshort をホストバイトオーダーからネットワークバイトオーダーに変換する。）  
　 
（Ｂ７）プログラムip_fw.cの第９４８〜９５０行には、 
「
iph-daddr = ms-src; 
portptr[1] = ms-sport; 
」と記載されており、これらの動作をまとめると、以下のようになる。 
　ＩＰヘッダの宛先アドレスにmsのエントリに登録されたソース・アドレスを入力し、宛先ポートアドレスにmsに登録された発信元ポートを入力する。 
すなわち、マスカレードされたアドレスとポートを元に戻している。 
　 
（Ｂ８）プログラムip_fw.cの第９５１〜１００１行には、 
「 if(ms-dport==htons(FTP_DPORT_TBD)) 
{ 
・・・
} 
・・・
/* 
* Yug! adjust UDP/TCP and IP checksums 
*/ 
・・・
return 1; 
} 
」と記載されており、これらの注釈と動作をまとめると、以下のようになる。 
　msの宛先ポートがＦＴＰ、ＵＤＰ、ＴＣＰの所定の処理を行う。
　ip_fw_demasqueradeから、数値１を戻り値としてリターンする。つまり、ip_fw_demasqueradeを終了する。 
　
（Ｂ９）プログラムip_fw.cの第１００２〜１００３行には、 
「 ms = ms-next; 
} 
」と記載されており、これらの動作をまとめると、以下のようになる。 
　ポインタmsが指示しているエントリを次のエントリに更新して、（Ｂ５）まで戻る。なお、次のエントリが無い場合には、nextはNULLなので、msはNULLとなり、（Ｂ５）まで戻るが（Ｂ５）（while (ms!=NULL) ）の判断の結果、（Ｂ６）から（Ｂ９）は実行されずに、次の（Ｂ１０）に移行する。 
　 
（Ｂ１０）プログラムip_fw.cの第１００４〜１００７行には、 
「 
/* sorry, all this trouble for a no-hit :) */ 
return 0; 
} 
」と記載されており、これらの注釈と動作をまとめると、以下のようになる。 
　msがNULL、つまり、受信したＩＰパケットが、ip_fw_masqueradeで事前にエントリとして登録されていない場合、トラブルであり、数値０を戻り値としてリターンする。 
　 
（Ｂ−１）（Ｂ１）から（Ｂ１０）のまとめ
　（Ｂ１）から（Ｂ１０）では、「戻りパケットを受信するステップは、パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるか検査して、 
検査が偽であったパケットに対して、数値０を戻り値としてリターンし（Ｂ３）、検査が真であったパケットに対して、パケットが事前に登録されているか否かを、受信パケットの発信元（ＩＰヘッダのソースアドレス、（Ｂ６）のiph-saddr）がリスト構造に登録された宛先アドレス（ms-dst）と一致し（（Ｂ６）のｂ）、発信元ポート（portptr[0]）がリスト構造に登録された宛先ポート（ms-dport）と一致し（同　ｃ）、宛先ポート（portptr[1]）がリスト構造に登録されたマスカレードポート値（ms-mport）と一致するエントリとして探索し、 
　発見できた場合、宛先アドレス（iph-daddr）とポート値（portptr[1]）を記憶・維持していたソース・アドレス（ms-scr）とポート値(ms-sport)に戻して（Ｂ７）、そして、ＦＴＰ、ＵＤＰ、ＴＣＰに応じた処理を行い、数値１を戻り値としてリターンし（Ｂ８）、 
　発見できなかった場合、トラブルであり、パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるかの検査で偽のときと同様に、数値０を戻り値としてリターンする(Ｂ１０)」ことが記載されている。 
　 
（Ｃ）プログラム・ファイル/linux/include/net/ip.h 
（Ｃ１）プログラムip.h の第１行から第８行には、 
「/* 
* INET An implementation of the TCP/IP protocol suite for the LINUX 
* operating system. INET is implemented using the BSD Socket 
* interface as the means of communication with the user level. 
* 
* Definitions for the IP protocol. 
* 
* Version: @(#)ip.h 1.0.2 04/28/93」 
　 
（Ｃ２）プログラムip.h の第９０行から第１１０行には、 
「struct iphdr { 
#if defined(__LITTLE_ENDIAN_BITFIELD) 
__u8 ihl:4, 
version:4; 
#elif defined (__BIG_ENDIAN_BITFIELD) 
__u8 version:4, 
ihl:4; 
#else 
#error Please fix asm/byteorder.h 
#endif 
__u8 tos; 
__u16 tot_len; 
__u16 id; 
__u16 frag_off; 
__u8 ttl; 
__u8 protocol; 
__u16 check; 
__u32 saddr; 
__u32 daddr; 
/*The options start here. */ 
};」 と記載されており、これら（Ｃ１）（Ｃ２）の注釈と定義をまとめると、以下のようになる。 
　iphdrという名前のstruct（構造体）は、ＩＰversion４のヘッダを定義したデータ構造体である。 
　 
（Ｄ）プログラム・ファイルlinux/net/ipv4/ip_fw.h 
（Ｄ１）プログラムip_fw.hの第１５４〜１６６行には、 
「#ifdef CONFIG_IP_MASQUERADE 
struct ip_masq { 
struct ip_masq *next; /* next member in list */ 
struct timer_list timer; /* Expiration timer */ 
__u16 protocol; /* Which protocol are we talking? */ 
__u32 src, dst; /* Source and destination IP addresses */ 
__u16 sport,dport; /* Source and destination ports */ 
__u16 mport; /* Masquaraded port */ 
__u32 init_seq; /* Add delta from this seq. on */ 
short delta; /* Delta in sequence numbers */ 
short previous_delta; /* Delta in sequence numbers before last resized PORT command */ 
char sawfin; /* Did we saw an FIN packet? */ 
}; 」と記載されており、これらの注釈と定義をまとめると、以下のようになる。 
　ip_masq型の構造体は、ip_masqはプロトコル、ソース・アドレス、宛先アドレス、発信元ポート、宛先ポート、ポート値等の値を有するマスカレードに使うリスト構造の１つの要素（エントリ）を表し、ip_masq型のnextというポインタを含み、該nextで次の要素を指示して、全体としてリスト構造を構成している。
　 
　下記周知文献１は、引用例のようなプログラムが動作する、現実の通信ネットワークを構成するもので、ファイアウォールの技術常識と言えるものであるが、この周知技術１を加味することにより、引用例の（Ａ−１）（Ｂ−１）には、次の発明（以下、「引用発明」という。）が記載されているということができる。 
　 
「第１のデータ通信ネットワークと第２のデータ通信ネットワークをインタフェースするインターネットのファイアウォールを動作させる方法において： 
（ａ）第２のネットワーク内のノードに対応する宛先アドレスと第１のネットワーク中のノードに対応するソース・アドレスとを有するパケットを第１のネットワークから受信し、 
（ｂ）パケットからのソース・アドレスをリスト構造にエントリとして記憶し、ソース・アドレスに関連するポート値は、前記リスト構造としてリンクしたエントリ内に記憶することによってソース・アドレスを維持し、 
（ｃ）パケット内で、ソース・アドレスをファイアウォールのアドレスと置き換え、 
（ｄ）置き換えられたソース・アドレスを有するパケットを第２のネットワークに送り、それによってそのパケットは対応の第２のネットワーク・ノードにルーティングされ、 
（ｅ）置き換えられたソース・アドレスを有するパケットに応じて、第２のネットワークからの戻りパケットを受信し、 
（ｆ）戻りパケット内で、宛先アドレスと維持されたソース・アドレスとを置き換え、 
（ｇ）置き換えられた宛先アドレスを有する戻りパケットを第１のネットワークに送り、それによってそのパケットは対応の第１のネットワーク・ノードにルーティングされ、 
　前記の戻りパケットを受信するステップは、さらに、そのパケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるか検査して、検査が偽であったパケットに対して、数値０を戻り値としてリターンし、検査が真であったパケットに対して、パケットが事前に登録されているか否かを、受信パケットの発信元がリスト構造に登録された宛先アドレスと一致し、発信元ポートがリスト構造に登録された宛先ポートと一致し、宛先ポートがリスト構造に登録されたマスカレードポート値と一致するエントリとして探索し、発見できた場合、宛先アドレスとポート値を記憶・維持していたソース・アドレスとポート値に戻して、そして、ＦＴＰ、ＵＤＰ、ＴＣＰに応じた処理を行い、数値１を戻り値としてリターンし、発見できなかった場合、トラブルであり、パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるかの検査で偽のときと同様に、数値０を戻り値としてリターンするインターネットのファイアウォールを動作させる方法。」 
　 
（イ）例えば、周知文献として引用する日経コミュニケーション 第２１０号、日経ＢＰ社、１９９５年１１月２０日、第９９頁から第１０４頁（以下、「周知文献１」という。）には、図２−１において、「ααααが割り当てられた社内（第１のネットワーク）内のノードと、ＸＸＸＸが割り当てられた社外（第２のネットワーク）内のノードの間で、アドレス変換（ＮＡＴ）等を行うファイアウォールを介して、ＩＰパケットが、ＬＡＮとインターネットで送受信、したがって、ＬＡＮとインターネットでルーティングすること。」が記載されている。 
　つまり、「第１のデータ通信ネットワーク（社内）と第２のデータ通信ネットワーク（社外・インターネット）をインタフェース（アドレスの付け替え（ＮＡＴ）・パケット・フィルタリング等を）するファイアウォールを動作させる方法において： 
（ａ）第２のネットワーク（社外）内のノードに対応する宛先アドレス（ＸＸＸＸ）と第１のネットワーク（社内・ＬＡＮ）中のノードに対応するソース・アドレス（αααα）とを有するパケットを第１のネットワーク（社内）から受信し、 
（ｃ）パケット内で、ソース・アドレス（αααα）をファイアウォールのアドレス(ＺＺＺＺ)と置き換え、 
（ｄ）置き換えられたソース・アドレス（ＺＺＺＺ）を有するパケットを第２のネットワーク（社外・インターネット）に送り、それによってそのパケットは対応の第２のネットワーク・ノードにルーティングされ、 
（ｅ）置き換えられたソース・アドレス（ＺＺＺＺ）を有するパケットに応じて、第２のネットワークからの戻りパケットを受信し、 
（ｆ）戻りパケット内で、宛先アドレス（ＺＺＺＺ）と維持されたソース・アドレス（αααα）とを置き換え、 
（ｇ）置き換えられた宛先アドレス（αααα）を有する戻りパケットを第１のネットワーク（社内・ＬＡＮ）に送り、それによってそのパケットは対応の第１のネットワーク・ノードにルーティングされ、 
アドレスの付け替え・パケット・フィルタリング等するファイアウォールを動作させる方法。」が記載されており、当該技術は、出願前のファイアウォールとして周知の技術である。（以下、「周知技術１」という。） 
　  
（ウ）例えば、周知文献として引用する市原英也　外４名　著「ポイント図解式　標準インターネット教科書　初版」、株式会社アスキー、１９９６年３月１１日発行、第１６３頁第２１行から１６５頁第１行）（以下、「周知文献２」という。）には、次の記載がある。 
　
「 ◆７．４◆ ファイアウォール 
　ファイアウォール（防火壁） とは、セキュリティ・ポリシーを実現するシステムで、外部のネットワークと組織内のネットワークとの間に配置されます。外部との通信トラフィックのすべてがファイアウォールを介して行われなければなりません。外部との接続を一か所に集中することによって、セキュリティ管理もファイアウォールにおいて集中的に行うことを可能とします。ファイアウォールの構成にはいくつもの方法がありますが、基本的には次に解説するように、パケット・フィルタリング方式とアプリケーション・ゲートウェイ方式の二つに大別されます。通常は、この二つの組み合わせによってファイアウオールが構築されます。 
ファイアウオールの基本的な構成を図７−５に示します。図７−５の重要な点は次の通りです。 
マル１　インターネットとの接続ポイントを一か所に絞る 
マル２　バリア・セグメントを設ける 
マル３　外部からの侵入者をこのバリア・セグメントで食い止める 
マル４　バリア・セグメント上には、外部と接続されるサーバ（ＷＷＷサーバ／ネーム・サーバ／メール・サーバ／プロキシー・サーバなど）だけを設置する 
［１］パケット・フィルタリング方式 
（１）ルータのフィルタリング機能 
パケット・フィルタリング方式とは、ルータのもつフィルタリング機能（パケットを通過させる、させないなどの判断機能）を利用して、ＩＰレベルのセキュリティ制御を行うことを言います。インターネット接続を行う場合、ルータは不可欠な接続機器ですから、新たな投資を必要とせずに、既存のルータを使用してファイアウォールをつくることができるという意味で、 もっとも実現性の高いセキュリティ・システムと言えるかもしれません。 
ルータによるフィルタリング機能において、フィルタリング・パラメータとなる項目には次のようなものがあります。 
マル１　パケットを通すか通さないかについての許可（ｐｅｒｍｉｔ）／拒否（ｄｅｎｙ） 
マル２　送信元のＩＰアドレス 
マル３　宛先のＩＰアドレス 
マル４　上位プロトコル種別（ポート番号） 
これらのパラメータの組み合わせによってセキュリティ・ポリシーをテーブル形式で表現したアクセス制御リストを作成します。」
　
（なお、第１６３頁第２１行の「◆」は、原文においては、菱形を４個用いて記載されている。第１６３頁第３０行から３３行、及び、第１６４頁第１１行から１４行のマル１、マル２、・・・は、原文においては、丸数字の１、丸数字の２・・・で記載されている。）
　
　つまり、 
「ファイアウォールは、セキュリティ・ポリシーを実現するシステムで、外部のネットワークと組織内のネットワークとの間に配置され、パケット・フィルタリング（パケットを通過させる、させないなどの判断機能）を利用して、ＩＰレベルのセキュリティ制御を行う」ことは、出願当時周知の技術である。（以下、「周知技術２」という。） 
　 
（３）対比 
　補正後の発明と引用発明を対比すると、 
（イ）補正後の発明の「インターネット・プロトコル・フィルタを動作させる方法」と、引用発明の「インターネットのファイアウォールを動作させる方法」とは、「インターネットのプロトコルを動作させる方法」で一致する。
（ロ）引用発明の「パケット」は、補正後の発明の「データ・パケット」に相当する。 
（ハ）引用発明の「記憶」は、変数に対応するメモリ上にデータを記憶しており、そして、メモリに記憶することをストアということから「ストア」に相当する。 
（ニ）補正後の発明の「ルックアップ・テーブル」と、引用発明の「リスト構造」は、「データ構造」で一致する。 
（ホ）補正後の発明の「フィルタ・ノード・ポート値」と、引用発明の「ポート値」は、「ポート値」で一致する。 
（ヘ）補正後の発明の「前記ルックアップ・テーブルにインデックスされることよってソース・アドレスを維持し」と、引用発明の「前記リスト構造としてリンクしたエントリ内に記憶することによってソース・アドレスを維持し」は、前記（ニ）を参照し、「前記データ構造を用いて、ソース・アドレスを維持し」で一致する。 
（ト）補正後の発明の「フィルタ・ノードのアドレス」と、引用発明の「ファイアウォールのアドレス」とは、引用発明のファイアウォールはネットワークのノードとなっているから、「ノードのアドレス」で一致する。 
（チ）補正後の発明の「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持されたソース・アドレスと関連がなかった場合、第２のネットワークから受信されたデータ・パケットを無視する」と、引用発明の「そのパケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるか検査して、検査が偽であったパケットに対して、数値０を戻り値としてリターンし、検査が真であったパケットに対して、パケットが事前に登録されているか否かを、受信パケットの発信元がリスト構造に登録された宛先アドレスと一致し、発信元ポートがリスト構造に登録された宛先ポートと一致し、宛先ポートがリスト構造に登録されたマスカレードポート値と一致するエントリとして探索し、発見できた場合、宛先アドレスとポート値を記憶・維持していたソース・アドレスとポート値に戻して、そして、ＦＴＰ、ＵＤＰ、ＴＣＰに応じた処理を行い、数値１を戻り値としてリターンし、発見できなかった場合、トラブルであり、パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるかの検査で偽のときと同様に、プロトコルがＵＤＰでもＴＣＰでもない場合、又は、宛先ポートが所定の範囲内と同様に、数値０を戻り値としてリターンする」は、データ・パケット内の宛先アドレスの宛先ポートが発見できなかった場合は、維持されたエントリの情報と関連がなかった場合であるから、「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持された情報と関連がなかった場合、所定の処理を行う」で一致する。 
　 
　してみれば、補正後の発明と引用発明は次の点で、一致ないし相違するものと認められる。 
［一致点］ 
「第１のデータ通信ネットワークと第２のデータ通信ネットワークをインタフェースするインターネットのプロトコルを動作させる方法において： 
（ａ）第２のネットワーク内のノードに対応する宛先アドレスと第１のネットワーク中のノードに対応するソース・アドレスとを有するデータ・パケットを第１のネットワークから受信し、 
（ｂ）データ・パケットからのソース・アドレスをデータ構造にエントリとしてストアし、ソース・アドレスに関連するポート値は、前記データ構造を用いて、ソース・アドレスを維持し、 
（ｃ）データ・パケット内で、ソース・アドレスをノードのアドレスと置き換え、 
（ｄ）置き換えられたソース・アドレスを有するデータ・パケットを第２のネットワークに送り、それによってそのパケットは対応の第２のネットワーク・ノードにルーティングされ、 
（ｅ）置き換えられたソース・アドレスを有するデータ・パケットに応じて、第２のネットワークからの戻りパケットを受信し、 
（ｆ）戻りパケット内で、宛先アドレスと維持されたソース・アドレスとを置き換え、
（ｇ）置き換えられた宛先アドレスを有する戻りパケットを第１のネットワークに送り、それによってそのパケットは対応の第１のネットワーク・ノードにルーティングされ、 
　前記の戻りパケットを受信するステップは、さらに、そのデータ・パケット内の宛先アドレスの宛先ポートが、維持された情報と関連がなかった場合、所定の処理を行うインターネットのプロトコルを動作させる方法。」 
　 
［相違点］ 
相違点１ 
「インターネットのプロトコルを動作させる方法」に関して、補正後の発明が「インターネット・プロトコル・フィルタを動作させる方法」であるのに対して、引用発明では「インターネットのファイアウォールを動作させる方法」である点、 
　 
相違点２ 
「データ構造」に関して、補正後の発明が「ルックアップ・テーブル」であるのに対して、引用発明では「リスト構造」である点、 
　 
相違点３ 
「ポート値」に関して、補正後の発明が「フィルタ・ノード・ポート値」であるのに対して、引用発明では、「ポート値」である点、 
　 
相違点４ 
「前記データ構造を用いて、ソース・アドレスを維持し」に関して、補正後の発明が「前記ルックアップ・テーブルにインデックスされることよってソース・アドレスを維持し」であるのに対して、引用発明では「前記リスト構造としてリンクしたエントリ内に記憶することによってソース・アドレスを維持し」である点、 
　 
相違点５ 
「ノードのアドレス」に関して、補正後の発明が「フィルタ・ノードのアドレス」であるのに対して、引用発明の「ファイアウォールのアドレス」である点、 
　 
相違点６ 
「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持された情報と関連がなかった場合、所定の処理を行う」に関して、補正後の発明が「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持されたソース・アドレスと関連がなかった場合、第２のネットワークから受信されたデータ・パケットを無視する」であるのに対して、引用発明の「パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるか検査して、検査が偽であったパケットに対して、数値０を戻り値としてリターンし、検査が真であったパケットに対して、パケットが事前に登録されているか否かを、受信パケットの発信元がリスト構造に登録された宛先アドレスと一致し、発信元ポートがリスト構造に登録された宛先ポートと一致し、宛先ポートがリスト構造に登録されたマスカレードポート値と一致するエントリとして探索し、発見できた場合、宛先アドレスとポート値を記憶・維持していたソース・アドレスとポート値に戻して、そして、ＦＴＰ、ＵＤＰ、ＴＣＰに応じた処理を行い、数値１を戻り値としてリターンし、発見できなかった場合、トラブルであり、パケットのプロトコルがＵＤＰ又はＴＣＰであるか、そして、宛先ポートが所定の範囲内であるかの検査で偽のときと同様に、数値０を戻り値としてリターンする」である点。 
　 
（４）当審の判断 
　上記相違点について検討すると、 
　 
相違点２、４に関して、 
　通信及びコンピュータの分野において、データを維持、管理、検索するためのデータ構造として「リスト構造」も「ルックアップ・テーブル」も、ともに引用文献を用いるまでもなく周知であり、この周知のデータ構造を採用して、引用発明の「リスト構造」を「ルックアップ・テーブル」とすること（相違点２）、および、引用発明の「前記リスト構造としてリンクしたエントリ内に記憶することによってソース・アドレスを維持し」を「前記ルックアップ・テーブルにインデックスされることよってソース・アドレスを維持し」とすること（相違点４）は、容易になしえたものと認められる。 
　 
相違点６に関して、 
　上記周知技術２で示したように、「ファイアウォールは、セキュリティ・ポリシーを実現するシステムで、外部のネットワークと組織内のネットワークとの間に配置され、パケット・フィルタリング（パケットを通過させる、させないなどの判断機能）を利用して、ＩＰレベルのセキュリティ制御を行う」ことは、出願当時周知であるところ、引用発明の構成事項（ｇ）より明らかなように、引用発明では、パケットが事前に登録されているか否かを・・・・探索し、・・・発見できなかった場合は、トラブルであり、そのようなパケットは、ファイアウォールとしては、フィルタを通過させないで無視するのが望ましいことは明らかである。
　そして、引用発明の「パケットが事前に登録されているか否かを・・・・探索し、・・・発見できなかった場合」は、「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持されたソース・アドレスと関連がなかった場合」であることは自明である。
　したがって、引用発明の「パケットのプロトコルがＵＤＰ又はＴＣＰであるか、・・・、数値０を戻り値としてリターンする」を「そのデータ・パケット内の宛先アドレスの宛先ポートが、維持されたソース・アドレスと関連がなかった場合、第２のネットワークから受信されたデータ・パケットを無視する」とすることは、当業者であれば容易になしえたものと認められる。 
 　
相違点１、３、５に関して、 
　ファイアウォールは、インターネットのノード（ルータ等）であり、その動作の１つとしてフィルタ動作を含むことは、例えば、上記周知文献２から明らかなように周知であるから、引用発明の「インターネットのファイアウォールを動作させる方法」をより具体化して、「インターネット・プロトコル・フィルタを動作させる方法」とすることは当然になし得たものであり（相違点１）、その結果、「ポート値」を「フィルタ・ノード・ポート値」と称すること（相違点３）、「ファイアウォールのアドレス」を「フィルタ・ノードのアドレス」と称すること（相違点５）は、記載上、自明のことにすぎない。
　 
　そして、補正後の発明の構成によってもたらされる効果も、引用発明および周知技術から当業者ならば容易に予測できる程度のものであって格別なものとはいえない。 
 　
（５）よって、本件補正後の発明は、前記引用例に記載された発明および周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．以上のとおり、本件手続補正は、特許法第１７条の２第５項で準用する同法第１２６条第４項の規定に違反するので、同法１５９条第１項で準用する同法第５３条第１項の規定により却下する。
　　
第３．本願発明について
　　
１．本願発明
　　
　平成１４年４月２４日付けの手続補正は前記第２．記載のとおり却下されたので、
　　
　平成１３年１１月８日付けで補正された明細書および図面の記載からみて、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
　　
「第１のデータ通信ネットワークと第２のデータ通信ネットワークをインタフェースするインターネット・プロトコル・フィルタを動作させる方法において： 
　　（ａ）　第２のネットワーク内のノードに対応する宛先アドレスと第１のネットワーク中のノードに対応するソース・アドレスとを有するデータ・パケットを第１のネットワークから受信し、 
　　（ｂ）　データ・パケットから抽出されたソース・アドレスを維持し、 
　　（ｃ）　データ・パケット内で、ソース・アドレスをフィルタ・ノードのアドレスと置き換え、 
　　（ｄ）　置き換えられたソース・アドレスを有するデータ・パケットを第２のネットワークに送り、それによってそのパケットは対応の第２のネットワーク・ノードにルーティングされ、 
　　（ｅ）　置き換えられたソース情報を有するデータ・パケットに応じて、第２のネットワークからの戻りパケットを受信し、 
　　（ｆ）　戻りパケット内で、宛先アドレスと維持されたソース・アドレスとを置き換え、 
　　（ｇ）　置き換えられた宛先アドレスを有する戻りパケットを第１のネットワークに送り、それによってそのパケットは対応の第１のネットワーク・ノードにルーティングされ、 
　前記の戻りパケットを受信するステップは、さらに、そのデータ・パケット内の宛先情報の宛先ポートが、維持されたソース情報と関連がなかった場合、第２のネットワークから受信されたデータ・パケットを無視することを特徴とするインターネット・プロトコル・フィルタを動作させる方法。」　
　　
　２．引用文献及び周知技術
　　
　（１）原査定の拒絶の理由に引用された引用例、その記載事項及び「引用発明」は、前記「第２．３．（２）（ア）」に記載したとおりである。
　
　（２）周知文献として引用する周知文献１、その記載事項及び「周知技術１」は、前記「第２．３．（２）（イ）」に記載したとおりである。
　　
　（２）周知文献として引用する周知文献２、その記載事項及び「周知技術２」は、前記「第２．３．（２）（ウ）」に記載したとおりである。
　
　３．対比・判断
　　
　本願発明と引用発明とを対比すると、
　
　本願発明は、前記第２．で検討したように補正後の発明の（ｂ）の「データ・パケットからのソース・アドレスをルックアップ・テーブルにエントリとしてストアし、ソース・アドレスに関連するフィルタ・ノード・ポート値は、前記ルックアップ・テーブルにインデックスされることよってソース・アドレスを維持し」を、「データ・パケットからの抽出されたソース・アドレスを維持し」として、抽出の具体手段を省略し、また、補正後の発明の（ｇ）の「宛先アドレス」、「ソース・アドレス」を、「宛先情報」、「ソース情報」として、上位概念化したものである。
　　
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加限定したものに相当する補正後の発明が、前記「第２．３．（４）」に記載したとおり、引用例に記載された発明および周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例および周知技術に基づいて当業者が容易に発明をすることができたものである。
　　
　４． むすび
  　
　以上のとおりであるから、本願発明は、引用文献および周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができないものである。
　
　よって、結論の通り審決する。