【事件の表示】
　特願２００２−　　２７０４「通信システムと暗号処理機能付きＬＡＮ制御装置、及び通信制御プログラム」拒絶査定不服審判事件〔平成１５年　７月１８日出願公開、特開２００３−２０４３２６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１４年１月９日の出願であって、平成１７年８月２５日付けで拒絶理由が通知され、同年１１月４日付けで手続補正がなされ、同年１１月２９日付けで拒絶査定がなされ、これに対し、同年１２月２７日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成１７年１２月２７日付けの手続補正を却下する。
　
［理由］
１．補正の内容
　平成１７年１２月２７日付けの手続補正（以下、「本件補正」という。）は、明細書の段落番号【０００１】、【０００２】、【０００５】、【０００６】、【０００７】、【０００８】、【００３６】、【００４１】、【００４２】、【００４３】、【００４５】、【００４９】、【００５２】、【００５３】、【００６２】、【００６５】、【００６７】、【００７３】、【００７８】、【００８１】、【００９１】、【０１０３】、【０１０４】、【０１１１】、【０１１２】、【０１３３】、【０１３４】における、「ＩＰ−ＳＥＣ暗号化」及び「復号」の記載を、それぞれ「ＩＰ-ＳＥＣ暗号化（ＩＰ−ＳＥＣ認証ヘッダ（ＡＨ）の付加）」及び「復号（パケット送信元の認証と完全性の確保）」と補正することを含むものである。
　
２．補正の適否 
（１）新規事項の有無についての判断 
　願書に最初に添付した明細書には、本願発明の解決しようとする課題として、
「【０００６】
　第２に、従来のＬＡＮ制御装置９００では、上位装置から送られた送信データは、ＬＡＮ規格に基づきＬＡＮインタフェースに送信したり、またＩＰ−ＳＥＣの規格に基づいてＩＰ−ＳＥＣ暗号化した上で送信する動作のみである。ここで、送信パケットのＩＰ−ＳＥＣ暗号化済データを復号するためのデータが、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されているため、その結果、ＬＡＮインタフェースを介してＬＡＮネット網に送出された送信パケットが、第三者に盗み取られてＩＰ−ＳＥＣ暗号化が復号されることにより重要な機密のデータが比較的容易に漏洩してしまう危険があった。」と記載されているように、
　ＬＡＮネット網に送出された、ＩＰ−ＳＥＣ暗号化済データの送信パケットは、当該暗号を復号するためのデータが、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されているため、当該送信パケットを、ＬＡＮネット網上において、第三者が盗み取って、その送信パケットのＩＰ−ＳＥＣヘッダの認証データを用いて、ＩＰ−ＳＥＣ暗号化を復号することにより重要な機密のデータが比較的容易に漏洩してしまう危険を防ぐことを挙げている。
　
　そして、願書に最初に添付した明細書には、前記課題を解決するための解決手段として
「【０１３４】
　第２に、ＩＰ−ＳＥＣ暗号方式により暗号化した送信パケットを復号するための情報であるその送信パケットのＩＰ−ＳＥＣヘッダの認証データを暗号化した上で送信することにより、一般のＩＰ−ＳＥＣに対応するのみの機器では、本発明における送信パケットを復号することができないようにしたた。これにより、極めてセキュリティの高い信頼性の高いシステムを実現できる。」と記載されているように、
　暗号化した送信パケットを復号するための情報である認証データを暗号化した上でＬＡＮネット網に送出することで、仮にＬＡＮネット網上において、第三者が前記送信パケットを盗み取った場合においても、前記認証データが暗号化されているために、一般のＩＰ−ＳＥＣに対応するのみの機器では、前記暗号化された認証データを復号することができず、したがって前記暗号化した送信パケットを復号することができないようにする通信システム、ＬＡＮ制御装置、または通信制御プログラムを提供するものである。
　
　そして、願書に最初に添付した明細書には、前記通信システム、ＬＡＮ制御装置、または通信制御プログラムの第１の実施形態として、
「【００３７】
　図１を参照すると、本実施の形態のＬＡＮ制御装置１００は、制御部１０１、通信制御プログラム１０２、ＭＡＣアドレス記憶部１０３、ＬＡＮインタフェース送受信部１０４、送信データ記憶部Ａ１１０、ＩＰ−ＳＥＣ暗号化部１１１、送信データ記憶部Ｂ１１２、受信データ記憶部Ｂ１１３、ＩＰ−ＳＥＣ復号部１１４、受信データ記憶部Ａ１１５、認証データ暗号化部Ａ１２１、Ｂ１２２、Ｃ１２３、Ｄ１２４、認証データ復号部Ｄ１３１、Ｃ１３２、Ｂ１３３、Ａ１３４を備えている。
　　　【００３８】
　制御部１０１は、プログラム制御されるＣＰＵ等で実現され、ＬＡＮ制御装置１００の各部を制御する。
　　　【００３９】
　通信制御プログラム１０２は、ＬＡＮ制御装置１００の処理を制御する機能を備えるコンピュータプログラムであり、制御部１０１のメモリにロードされることでその機能を実現することができる。　・・・（中略）・・・
　　　【００４０】
　・・・（中略）・・・
　　　【００４１】
　・・・（中略）・・・　ＩＰ−ＳＥＣ暗号化部１１１は、送信パケットをＩＰ−ＳＥＣ暗号化する。
　　　【００４２】
　　・・・（中略）・・・　ＩＰ−ＳＥＣヘッダの認証データを暗号化する。
　　　【００４３】
　このＩＰ−ＳＥＣ暗号化し、そのＩＰ−ＳＥＣヘッダの認証データを暗号化した送信パケットは、送信データ記憶部Ｂ１１２に記憶され、ＬＡＮインタフェース送受信部１０４からＬＡＮ８００上に送出する。
　　　【００４４】
　また、ＬＡＮ８００から上述の暗号化が行なわれたパケットを受信した場合には、ＬＡＮインタフェース送受信部１０４がそのパケットを受信して、受信データ記憶部Ｂ１１３に記憶し、各認証データ復号部Ｄ１３１、Ｃ１３２、Ｂ１３３、Ａ１３４により、制御部１０１の制御に応じてそれぞれの暗号キーＤ１３１−１、Ｃ１３２−１、Ｂ１３３−１、Ａ１３４−１を用いて、ＩＰ−ＳＥＣヘッダの認証データを復号する。
　　　【００４５】
　そして、復号された認証データを用いて、ＩＰ−ＳＥＣ復号部１１４が、そのパケットのＩＰ−ＳＥＣ暗号化を復号する。復号されたパケットは受信データ記憶部Ａ１１５に記憶され、上位の装置に送られる。」と記載されているように、
　前記通信システム、ＬＡＮ制御装置、または通信制御プログラムにおいて、認証データを用いて、送信パケットをＩＰ−ＳＥＣ暗号化し、また復号化することは、明らかである。
　同様に、願書に最初に添付した明細書の段落【００４６】〜【００６４】にも、前記通信システム、ＬＡＮ制御装置、または通信制御プログラムの実施形態が記載されている。
　
　そして、願書に最初に添付した明細書に（注：下線部は、便宜上当審で付与したもの。）、
「【００６７】
　この
認証データ６２９は
ＩＰ−ＳＥＣ暗号化を復号するために用いるデータ
「【００７３】
　このため、ＬＡＮ８００に送信した送信パケット６００を第三者が不正に取得し、ＩＰ−ＳＥＣを駆使してその実送信データ６３０の解読を企てた場合でも、
ＩＰ−ＳＥＣにて復号に必要な暗号パラメータである認証データ
　認証データが、ＩＰ−ＳＥＣパケット６００の実送信データにおけるＩＰ−ＳＥＣ暗号化を復号するために用いる暗号パラメータであることが、明確に記載されている。
　
　そして、本願発明の解決しようとする課題が、「ＬＡＮネット網に送出された、ＩＰ−ＳＥＣ暗号化済データの送信パケットにおいて、当該暗号を復号するためのデータが、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されているため、当該送信パケットを、ＬＡＮネット網上において、第三者が盗み取って、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されている当該暗号を復号するためのデータを用いて、ＩＰ−ＳＥＣ暗号化を復号することにより重要な機密のデータが比較的容易に漏洩してしまう」ことを防ぐことにあることからすると、
　願書に最初に添付した明細書及び図面には、パケットの「暗号化」が、パケット自体を
暗号パラメータである認証データを用いて
暗号パラメータである認証データを用いて
　
　以上のように、願書に最初に添付した明細書及び図面には、パケットの「暗号化」が、パケット自体を
暗号パラメータである認証データを用いて
暗号パラメータである認証データを用いて
　さらに、パケットの「暗号化」として、パケット自体を暗号化するのではなく、「パケットに認証ヘッダを付加する」こと、及びパケットの「復号」として、暗号化されたパケットを復号化するのではなく、パケットの「認証や完全性の確保」を行うとすることは、そもそも、本願発明の目的に矛盾するものである。
　
　そして、暗号化とは、対象となるデータを変換して元のデータが推測できないランダムなデータとすることであり、認証ヘッダの付加とは、対象となるデータから当該データが改竄されていないこと、及び、当該データが正当な送信元から送信されたものであることを検証するためのデータを、対象となるデータとは別に生成し対象となるデータに付加することであり、復号とは、ランダムなデータを元のデータに逆変換することであり、送信元の認証と完全性の確保とは、生成し付加されたデータから、対象となるデータが改竄されておらず正当な送信元から送信されたものであることを検証することを意味し、「暗号化」と「認証ヘッダの付加」、また「復号」と「認証と完全性の確保」とが、それぞれ、異なる概念であることは、当業者に明らかな事項である。
　
　してみると、願書に最初に添付した明細書及び図面に接した当業者にとって、本願におけるパケットの「暗号化」が、パケット自体を暗号化するのではなく、「パケットに認証ヘッダを付加する」ことであり、パケットの「復号」が、暗号化されたパケットを復号化するのではなく、パケットの「認証や完全性の確保」を行うことであることを意味することが明らかであるという根拠はない。
　
　したがって、「ＩＰ−ＳＥＣ暗号化」及び「復号」の記載を、それぞれ「ＩＰ-ＳＥＣ暗号化（ＩＰ−ＳＥＣ認証ヘッダ（ＡＨ）の付加）」及び「復号（パケット送信元の認証と完全性の確保）」と補正することは、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてするものとはいえない。
　
　よって、本件補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものではないから、特許法第１７条の２第３項（新規事項）の規定に適合していない。 
　 
３．結語 
　以上のとおり、本件補正は、特許法第１７条の２第３項（新規事項）の規定に適合していないから、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。 
　したがって、本件補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。 
　 
第３．本願について 
１．本願明細書・図面
　平成１７年１２月２７日付けの手続補正は上記のとおり却下されたので、本願の明細書は平成１７年１１月４日付け手続補正書により補正された明細書となり、図面は出願当初のものとなる。
　そして、本願の特許請求の範囲は、以下のとおりである。
　
「【請求項１】　ＩＰ−ＳＥＣ暗号化方式により暗号化した送信パケットを用いて通信を行なう通信システムにおいて、
　ＩＰ−ＳＥＣ暗号化の際に生成されたデータを、所定の方法で暗号化した上で、前記送信パケットを送信することを特徴とする通信システム。
　　【請求項２】　暗号化の対象であるＩＰ−ＳＥＣ暗号化の際に生成された前記データが、前記送信パケットのＩＰ−ＳＥＣヘッダ中の認証データであることを特徴とする請求項１に記載の通信システム。
　　【請求項３】　前記送信パケットのＩＰ−ＳＥＣヘッダ中の指定された未使用部分に、暗号化した前記認証データの復号に用いる情報を記録することを特徴とする請求項２に記載の通信システム。
　　【請求項４】　前記送信パケットのＩＰ−ＳＥＣヘッダ中の、ペイロード長の記録領域とセキュリティパラメータインデックスの記録領域との間に、暗号化した前記認証データの復号に用いる情報を記録することを特徴とする請求項２に記載の通信システム。
　　【請求項５】　受信した前記送信パケットの前記認証データを、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された前記認証データの復号に用いる情報を用いて復号し、前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号することを特徴とする請求項３又は請求項４に記載の通信システム。
　　【請求項６】　前記認証データの復号に用いる複数個の暗号キーを、前記認証データの復号に用いる情報として、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録することを特徴とする請求項３から請求項５のいずれか１つに記載の通信システム。
　　【請求項７】　前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録する前記認証データの復号に用いる情報に、前記認証データの復号に各前記暗号化キーをどのように用いるかを指定するフラグを含めることを特徴とする請求項６に記載の通信システム。
　　【請求項８】　前記認証データの復号に用いる各前記暗号キーの一部を、前記送信パケットの送信元の端末から受信先の端末へ通知し、
　前記送信パケットの受信先の端末にて、通知された前記暗号キーと、受信した前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された他の前記暗号キーとを用いて、受信した前記送信パケットの前記認証データを復号することを特徴とする請求項６又は請求項７に記載の通信システム。
　　【請求項９】　各前記暗号キーが、「０」から「Ｆ」までの１桁の１６進数を示す４ビットのデータであることを特徴とする請求項６から請求項８のいずれか１つに記載の通信システム。
　　【請求項１０】　前記送信パケットの前記認証データを４ビット毎に、各前記暗号キーによる排他的論理和を順次取ることにより暗号化し、
　受信した前記送信パケットの暗号化された前記認証データを４ビット毎に、暗号化時と同一の各前記暗号キーによる排他的論理和を順次取ることにより復号することを特徴とする請求項９に記載の通信システム。
　　【請求項１１】　前記送信パケットの前記認証データを定められたビット長毎に、各前記暗号キーを前後につなげることにより生成される複数種類の各暗号化データにより排他的論理和を順次取ることにより暗号化し、
　受信した前記送信パケットの前記認証データを定められたビット長毎に、暗号化時と同一の各前記暗号化データによる排他的論理和を取ることにより復号することを特徴とする請求項９に記載の通信システム。
　　【請求項１２】　前記送信パケットを通信するネットワークが、ＬＡＮであることを特徴とする請求項１から請求項１１のいずれか１つに記載の通信システム。
　　【請求項１３】　前記送信パケットの送信元の端末のＬＡＮ制御装置において、前記送信パケットのＩＰ−ＳＥＣ暗号化と、ＩＰ−ＳＥＣ暗号化された前記送信パケットの前記ヘッダデータの暗号化を行ない、
　前記送信パケットの受信先の端末のＬＡＮ制御装置において、受信した前記送信パケットの前記ヘッダデータの復号と、復号された前記ヘッダデータを用いて前記送信パケットのＩＰ−ＳＥＣ暗号化を復号することを特徴とする請求項１２に記載の通信システム。
　　【請求項１４】　上位装置をＬＡＮに接続しＩＰ−ＳＥＣ暗号化方式により暗号化した送信パケットを用いて通信を行なうＬＡＮ制御装置において、
　送信するパケットをＩＰ−ＳＥＣ暗号化する手段と、
　ＩＰ−ＳＥＣ暗号化の際に生成されたデータを、所定の方法で暗号化する手段を備えることを特徴とするＬＡＮ制御装置。
　　【請求項１５】　暗号化の対象であるＩＰ−ＳＥＣ暗号化の際に生成された前記データが、前記送信パケットのＩＰ−ＳＥＣヘッダ中の認証データであることを特徴とする請求項１４に記載のＬＡＮ制御装置。
　　【請求項１６】　前記送信パケットのＩＰ−ＳＥＣヘッダ中の指定された未使用部分に、暗号化した前記認証データの復号に用いる情報を記録する手段を備えることを特徴とする請求項１５に記載のＬＡＮ制御装置。
　　【請求項１７】　受信した前記送信パケットの前記認証データを、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された前記認証データの復号に用いる情報を用いて復号する手段と、
　前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号する手段を備えることを特徴とする請求項１６に記載のＬＡＮ制御装置。
　　【請求項１８】　前記認証データの復号に用いる複数個の暗号キーを、前記認証データの復号に用いる情報として、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録することを特徴とする請求項１６又は請求項１７に記載のＬＡＮ制御装置。
　　【請求項１９】　前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録する前記認証データの復号に用いる情報に、前記認証データの復号に各前記暗号化キーをどのように用いるかを指定するフラグを含めることを特徴とする請求項１８に記載のＬＡＮ制御装置。
　　【請求項２０】　前記認証データの復号に用いる各前記暗号キーの一部を、前記送信パケットの送信元から受信する手段と、
　受信した前記送信パケットの送信元から受信した前記暗号キーと、受信した前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された他の前記暗号キーとを用いて、当該送信パケットの前記認証データを復号する手段を備えることを特徴とする請求項１８又は請求項１９に記載のＬＡＮ制御装置。
　　【請求項２１】　各前記暗号キーが、「０」から「Ｆ」までの１桁の１６進数を示す４ビットのデータであることを特徴とする請求項１８から請求項２０のいずれか１つに記載のＬＡＮ制御装置。
　　【請求項２２】　前記送信パケットの前記認証データを４ビット毎に、各前記暗号キーによる排他的論理和を順次取ることにより暗号化する手段と、
　受信した前記送信パケットの暗号化された前記認証データを４ビット毎に、暗号化時と同一の各前記暗号キーによる排他的論理和を順次取ることにより復号する手段を備えることを特徴とする請求項２１に記載のＬＡＮ制御装置。
　　【請求項２３】　前記送信パケットの前記認証データを定められたビット長毎に、各前記暗号キーを前後につなげることにより生成される複数種類の各暗号化データにより排他的論理和を順次取ることにより暗号化する手段と、
　受信した前記送信パケットの前記認証データを定められたビット長毎に、暗号化時と同一の各前記暗号化データによる排他的論理和を取ることにより復号する手段を備えることを特徴とする請求項２１に記載のＬＡＮ制御装置。
　　【請求項２４】　コンピュータを制御することにより、上位装置をＬＡＮに接続しＩＰ−ＳＥＣ暗号化方式により暗号化した送信パケットを用いて通信を行なう通信制御プログラムにおいて、
　送信するパケットをＩＰ−ＳＥＣ暗号化する機能と、
　ＩＰ−ＳＥＣ暗号化の際に生成された、前記送信パケットのＩＰ−ＳＥＣヘッダ中の認証データを、所定の方法で暗号化する機能を備えることを特徴とする通信制御プログラム。
　　【請求項２５】　前記送信パケットのＩＰ−ＳＥＣヘッダ中の指定された未使用部分に、暗号化した前記認証データの復号に用いる情報を記録する機能を備えることを特徴とする請求項２４に記載の通信制御プログラム。
　　【請求項２６】　受信した前記送信パケットの前記認証データを、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された前記認証データの復号に用いる情報を用いて復号する機能と、
　前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号する機能を備えることを特徴とする請求項２５に記載の通信制御プログラム。
　　【請求項２７】　前記認証データの復号に用いる複数個の暗号キーを、前記認証データの復号に用いる情報として、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録する機能を備えることを特徴とする請求項２５又は請求項２６に記載の通信制御プログラム。
　　【請求項２８】　前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録する前記認証データの復号に用いる情報に、前記認証データの復号に各前記暗号化キーをどのように用いるかを指定するフラグを含める機能を備えることを特徴とする請求項２７に記載の通信制御プログラム。
　　【請求項２９】　前記認証データの復号に用いる各前記暗号キーの一部を、前記送信パケットの送信元から受信する機能と、
　受信した前記送信パケットの送信元から受信した前記暗号キーと、受信した前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された他の前記暗号キーとを用いて、当該送信パケットの前記認証データを復号する機能を備えることを特徴とする請求項２７又は請求項２８に記載の通信制御プログラム。
　　【請求項３０】　各前記暗号キーが、「０」から「Ｆ」までの１桁の１６進数を示す４ビットのデータであることを特徴とする請求項２７から請求項２９のいずれか１つに記載の通信制御プログラム。
　　【請求項３１】　前記送信パケットの前記認証データを４ビット毎に、各前記暗号キーによる排他的論理和を順次取ることにより暗号化する機能と、
　受信した前記送信パケットの暗号化された前記認証データを４ビット毎に、暗号化時と同一の各前記暗号キーによる排他的論理和を順次取ることにより復号する機能を備えることを特徴とする請求項３０に記載の通信制御プログラム。
　　【請求項３２】　前記送信パケットの前記認証データを定められたビット長毎に、各前記暗号キーを前後につなげることにより生成される複数種類の各暗号化データによる排他的論理和を順次取ることにより暗号化する機能と、
　受信した前記送信パケットの前記認証データを定められたビット長毎に、暗号化時と同一の各前記暗号化データによる排他的論理和を順次取ることにより復号する機能を備えることを特徴とする請求項３０に記載の通信制御プログラム。」
　 
２．原審の拒絶理由 
　原審における平成１７年８月２５日付けの拒絶理由の概要は以下のとおりである。 
　 
「Ａ．この出願は、下記の点で特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
　本願の請求項１−３２に係る発明は、ＩＰ−ＳＥＣ暗号化の際に生成されたヘッダデータを暗号化するものであるが、かかるヘッダデータとは、ＩＰ−ＳＥＣ暗号化されたパケットの復号に用いるものであり、ＩＰ−ＳＥＣヘッダ中の認証データである。
　ところでＩＰｓｅｃのプロトコルとしては、認証ヘッダ（ＡＨ）を用いるものと暗号ペイロード（ＥＳＰ）を用いるものとがある。認証ヘッダ（ＡＨ）を用いるプロトコルにおいては、認証へッダ中に認証データ（Authentication Data）が含まれる。しかしながら、かかる認証ヘッダを用いるプロトコルにおいては、パケットの暗号化は行われず、当然に復号も行われない。認証ヘッダ中の認証データとは、パケットの送信元の認証と完全性の確保、すなわちパケットが正当な送信元から送られてきたものであるか、及び、改ざんされていないか、ということを検証するために用いられるのであって、暗号化されたパケットの復号に用いられるものではない。暗号ペイロード（ＥＳＰ）を用いるプロトコルにおいては暗号化を行うが、ヘッダデータに認証データは含まれない。ＥＳＰ認証データが付加されることはあるが、それはパケットの末尾に付加されるのであり、ヘッダデータに含まれることはない。また、かかるＥＳＰ認証データとは、認証ヘッダの認証データと同様に送信元の認証と完全性の確保に用いるものであり、暗号化されたパケットの復号に用いるものではない。
　してみれば、ＩＰ−ＳＥＣ暗号化されたパケットの復号に用いるＩＰ−ＳＥＣヘッダ中の認証データとは、いかなるデータであるのか全く不明であるから、本願の請求項１−３２に係る発明は、発明を特定するための事項が不明確である。
　
Ｂ．この出願は、下記の点で特許法第３６条第４項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
　本願の請求項１−３２に係る発明は、ＩＰ−ＳＥＣヘッダ中の認証データを用いてＩＰ−ＳＥＣ暗号化されたパケットを復号するものである。しかしながら、ＩＰ−ＳＥＣ暗号化されたパケットを復号するにあたってＩＰ−ＳＥＣヘッダ中の認証データをどのように用いるのか、という点は、本願明細書の発明の詳細な説明に何ら記載されておらず、周知の事項であるとも認められない。してみれば、本願明細書の発明の詳細な説明には、請求項１−３２に係る発明を当業者が実施できる程度に明確かつ十分に記載がなされてない。　・・・（後略）」 
　 
３．当審の判断 
　上記拒絶理由について検討する。
　
（１）理由Ａ．について 
　請求項５〜１３に係る発明における発明特定事項「受信した前記送信パケットの前記認証データを、前記送信パケットのＩＰ−ＳＥＣヘッダ中に記録された前記認証データの復号に用いる情報を用いて復号し、前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号すること」、
　請求項１７〜２３に係る発明における発明特定事項「前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号する手段」、及び
　請求項２６〜３２に係る発明における発明特定事項「前記送信パケットのＩＰ−ＳＥＣ暗号化を、復号済前記認証データを用いて復号する機能」において、
　詳細な説明及び図面を参酌しても、ＩＰ−ＳＥＣ暗号化されたパケットの復号に用いるＩＰ−ＳＥＣヘッダ中の認証データとは、具体的にどのようなデータであるのか不明であり、送信パケットのＩＰ−ＳＥＣ暗号化を、認証データを用いて具体的にどのように復号するのか、不明であり、発明が明確でない。
　
　してみれば、前記原審における平成１７年８月２５日付けの拒絶理由の理由理由Ａ．において「ＩＰ−ＳＥＣ暗号化されたパケットの復号に用いるＩＰ−ＳＥＣヘッダ中の認証データとは、いかなるデータであるのか全く不明であるから、本願の請求項１−３２に係る発明は、発明を特定するための事項が不明確である。」と指摘したとおり、
　請求項５〜１３、請求項１７〜２３、及び請求項２６〜３２に係る発明は依然として明確でないから、この出願は、特許法第３６条第６項第２号に規定する要件を満たしていない。 
　
（２）理由Ｂ．について 
　 発明の詳細な説明の段落【０００６】における記載
　「第２に、従来のＬＡＮ制御装置９００では、上位装置から送られた送信データは、ＬＡＮ規格に基づきＬＡＮインタフェースに送信したり、またＩＰ−ＳＥＣの規格に基づいてＩＰ−ＳＥＣ暗号化した上で送信する動作のみである。ここで、送信パケットのＩＰ−ＳＥＣ暗号化済データを復号するためのデータが、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されているため、その結果、ＬＡＮインタフェースを介してＬＡＮネット網に送出された送信パケットが、第三者に盗み取られてＩＰ−ＳＥＣ暗号化が復号されることにより重要な機密のデータが比較的容易に漏洩してしまう危険があった。」を参酌すると、送信パケットのＩＰ−ＳＥＣ暗号化済データを復号するためのデータが、その送信パケットのＩＰ−ＳＥＣヘッダの認証データとして記録されていることが明記されている。
　しかしながら、認証データを用いてどのように復号するのか、明細書及び図面を参酌しても、その具体的な態様とその構成は、記載も示唆もない。
　
　なお、請求人は、平成１７年１１月４日付け手続補正書と同日付の意見書において
「上記ご指摘の「データ」が含む認証データが、セキュリティアソシエーション（ＳＡ）を識別するセキュリティパラメータインデックス（ＳＰＩ）値を有する場合に、識別したＳＡで指定された暗号化アルゴリズム及び鍵で送信パケットの復号化が可能となることも当業者にとって明らかな事項であります。」と主張しているが、
　図面（特に、【図６】、【図９】〜【図１２】、【図１４】〜【図１７】、【図１９】、【図２０】、及び【図２２】〜【図２４】）を参酌しても、認証データがセキュリティパラメータインデックス（ＳＰＩ）値を
含まない
　以上のように、請求人の前記主張は、本願の明細書及び図面に基づかない主張であって、採用することはできない。
　してみれば、前記原審における平成１７年８月２５日付けの拒絶理由の理由Ｂ．において「ＩＰ−ＳＥＣ暗号化されたパケットを復号するにあたってＩＰ−ＳＥＣヘッダ中の認証データをどのように用いるのか、という点は、本願明細書の発明の詳細な説明に何ら記載されておらず、周知の事項であるとも認められない。してみれば、本願明細書の発明の詳細な説明には、請求項１−３２に係る発明を当業者が実施できる程度に明確かつ十分に記載がなされてない。」と指摘したとおり、
　この出願の発明の詳細な説明は、当業者がその実施をすることができる程度に明確かつ十分に記載されていないから、特許法第３６条第４項に規定する要件を満たしていない。
　 
４．むすび 
　以上のとおり、本願の出願は、明細書の記載が特許法第３６条第４項および第６項第２号に規定する要件を満たしていないから、特許を受けることができない。
　よって、結論のとおり審決する。