【事件の表示】
　特願２００４−１５５５４２「ＶＰＮシステム、リモート端末及びそれらに用いるリモートアクセス通信方法」拒絶査定不服審判事件〔平成１７年１２月　８日出願公開、特開２００５−３４１０８４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本件出願は、平成１６年５月２６日の出願であって、平成１９年４月９日付けで手続補正がなされたが、平成１９年８月３日付けで拒絶査定がなされ、これに対し、平成１９年９月２０日に拒絶査定に対する審判請求がなされるとともに平成１９年１０月２２日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成１９年１０月２２日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正は補正前の平成１９年４月９日付け手続補正書の特許請求の範囲の請求項１に記載された
「ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）トンネル技術にＩＰｓｅｃ（ＩＰ　ｓｅｃｕｒｉｔｙ　ｐｒｏｔｏｃｏｌ）のＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ　Ｓｅｃｕｒｉｔｙ　Ｐａｙｌｏａｄ）トンネル技術を適用したリモートアクセスＩＰｓｅｃＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を用いるＶＰＮシステムであって、
　リモート端末がリモートアクセス先の閉域ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）網内のノードと通信を行う際に前記閉域ＩＰ網内の境界ゲートウェイとの間で前記リモートアクセスＩＰｓｅｃＶＰＮ接続を行う手段を前記リモート端末に有し、
　前記リモート端末と前記閉域ＩＰ網内のノードとが仮想的に同じセグメント内に接続するとともに、
　前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて前記リモート端末上のユーザを特定し、対応する前記閉域ＩＰ網内のＩＰアドレスを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのＶＰＮアドレス払い出しにおいて前記ＶＰＮアドレスに前記閉域ＩＰ網内のＩＰアドレスを割当てることで前記閉域ＩＰ網内からの前記ＩＰアドレスの払い出しを行うことを特徴するＶＰＮシステム。」という発明（以下、「本願発明」という。）を、
「ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）トンネル技術にＩＰｓｅｃ（ＩＰ　ｓｅｃｕｒｉｔｙ　ｐｒｏｔｏｃｏｌ）のＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ　Ｓｅｃｕｒｉｔｙ　Ｐａｙｌｏａｄ）トンネル技術を適用したリモートアクセスＩＰｓｅｃＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を用いるＶＰＮシステムであって、
　リモート端末がリモートアクセス先の閉域ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）網内のノードと通信を行う際に前記閉域ＩＰ網内の境界ゲートウェイとの間で前記リモートアクセスＩＰｓｅｃＶＰＮ接続を行う手段を前記リモート端末に有し、
　前記リモート端末と前記閉域ＩＰ網内のノードとが仮想的に同じセグメント内に接続するとともに、
　前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて前記リモート端末上のユーザを特定し、対応する前記閉域ＩＰ網内のＩＰアドレスを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのＶＰＮアドレス払い出しにおいて前記ＶＰＮアドレスに前記閉域ＩＰ網内のＩＰアドレスを割当てることで前記閉域ＩＰ網内からの前記ＩＰアドレスの払い出しを行い、
　前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて前記リモート端末上のユーザを特定し、対応するコンフィグデータを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのメッセージに前記コンフィグデータを統合して前記閉域ＩＰ網内からの前記リモート端末のコンフィグデータの払い出しを行うことを特徴とするＶＰＮシステム。」という発明（以下、「補正後の発明」という。）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、本願発明に「前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて前記リモート端末上のユーザを特定し、対応するコンフィグデータを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのメッセージに前記コンフィグデータを統合して前記閉域ＩＰ網内からの前記リモート端末のコンフィグデータの払い出しを行うこと」を付加してＩＫＥ通信時のＩＳＡＫＭＰコンフィグレーションの認証通信にて行われる処理を限定することにより特許請求の範囲を減縮するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び第４項第２号（補正の目的）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
（２）引用発明
ａ．原査定の拒絶理由に引用された特開２００１−１６０８２８号公報（以下、「引用例１」という。）には「セキュリティ・ゲートウェイ装置におけるＶＰＮ通信方法」に関し、図面とともに以下の事項が記載されている。
　
イ．「【０００４】以下に、ＩＰｓｅｃを利用したＶＰＮ通信の概要を説明する。まず図４を参照しながら説明する。図４はＷＡＮを含む一般的なネットワークシステムを示す構成図である。
【０００５】図４において、１０１はプロバイダにダイヤルアップ接続した外部のＰＣ、１０２はＷＡＮ、１０３はＷＡＮ１０２と後述のＬＡＮ１０４を接続して集線・変換処理を行うセキュリティ・ゲートウェイ、１０４はセキュリティ・ゲートウェイ１０３配下のＬＡＮ、１０５はＬＡＮ１０４上のサーバ端末、１０６、１０７はＬＡＮ１０４上のクライアントＰＣ、１０８はＰＣ１０１とセキュリティ・ゲートウェイ１０３との間でＩＰｓｅｃ通信を行うために確立されたＶＰＮである。
【０００６】ダイヤルアップ接続したＰＣ１０１がＬＡＮ１０４上の端末にアクセスする場合、セキュリティ・ゲートウェイ１０３との間でＶＰＮ１０８を確立し、ＷＡＮ１０２上で仮想的な専用線環境を実現する。こうしてＷＡＮ１０２上で通信内容を盗聴・改竄できないようにし、ＬＡＮ１０４配下の端末と通信を行う。」（段落【０００４】−【０００６】）
　
ロ．「【０００７】次に、ＩＰｓｅｃ通信を行うために必要な通信内容の概要について図５を用いて解説する。図５はＷＡＮによる接続を示すＷＡＮ接続図である。
【０００８】図５において、ＰＣ１０１、ＷＡＮ１０２、セキュリティ・ゲートウェイ１０３は図４と同様のものである。
【０００９】ＰＣ１０１とセキュリティ・ゲートウェイ１０３との２点間でＩＰｓｅｃ通信を行う場合、データの秘匿性、コネクションレスな完全性（相手との論理的な通信路を構築せず、データの改ざんを防止すること）、改ざん防止などを保証するための暗号アルゴリズム、認証アルゴリズムに用いる鍵情報を両者がＩＰｓｅｃ通信を行う前に共有できてないといけない。両者で鍵情報を共有させる方法として、事前に両者で鍵情報を手動で設定する方法と、ＩＫＥ（ＩｎｔｅｒｎｅｔＫｅｙ  Ｅｘｃｈａｎｇｅ）プロトコルを用いて自動設定する方法の２通りがある。ここでは、現実的な方法であるＩＫＥプロトコルによる自動鍵情報交換方式のみを適用する。
【００１０】次に、図６を用いてＩＰｓｅｃ通信について説明する。図６はＩＰｓｅｃ通信開始のためのセキュリティ・ゲートウェイ１０３の動作を示すフローチャートである。
【００１１】ＩＰｓｅｃ通信を行うためには、２点間で双方向に論理的なコネクションＳＡ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ）を確立しなければならない。そのためにＩＫＥ通信は２つのフェーズに分かれていて、フェーズ１において安全なＩＫＥ通信を行うためのＩＫＥ−ＳＡを確立しようとし（Ｓ１１、Ｓ１２）、それに成功したら、フェーズ２において、ＩＰｓｅｃ通信するための鍵情報などのセキュリティ情報を交換する（Ｓ１３）。フェーズ２でＩＰｓｅｃ−ＳＡを確立することができれば（Ｓ１４）ＩＫＥ通信を終了し、ＩＰｓｅｃ通信が開始する（Ｓ１５）。ステップＳ１３のＩＫＥ（フェーズ２）通信においてＩＰｓｅｃ通信を行うために２点間で交換される情報を（表１）に示す。
【００１２】
【表１】（省略）
【００１３】但し動作モード（ＩＰｓｅｃ通信モード）については、セキュリティ・ゲートウェイ１０３はトンネルモード（ＩＰパケット全体をカプセリングする）でしか動作できないので、ここでは、ＩＰｓｅｃの動作モードはトンネルモードのみを想定する。」（段落【０００７】−【００１３】）
　
ハ．「【００３０】図３に示す通り、ＩＫＥ通信はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒ−ｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を使用して行われる。ＩＫＥデータは、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ  ＳｅｃｕｒｉｔｙＡｓｓｏｃｉａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔ−ｏｃｏｌ）ヘッダの後にＩＳＡＫＭＰペイロードが数珠つなぎの形態で続くことで構成される。ＩＫＥ通信は、鍵交換を要求する始動者（イニシエータ、Ｉｎｉｔｉａｔｏｒ）とそれに対して応答する応答者（リスポンダ、Ｒｅｓ−ｐｏｎｄｅｒ）によって行われる。本実施の形態においては、図４において、プロバイダにダイヤルアップしてインターネットに接続したＰＣ１０１がＩｎｉｔｉａｔｏｒとなり、ＬＡＮ１０４上の端末としてのクライアントＰＣ１０６、１０７にアクセスするために、セキュリティ・ゲートウェイ１０３にＩＫＥ通信を開始し、セキュリティ・ゲートウェイ１０３がＲｅｓｐｏｎｄｅｒとしてＩＫＥ通信を行う。（表１）に挙げた項目のうち、暗号鍵と認証鍵は、公開鍵暗号方式を用いてＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの間で鍵情報が交換されるが、それ以外の項目は、Ｉｎｉｔｉａｔｏｒが提案をし、ＲｅｓｐｏｎｄｅｒがＩｎｉｔｉａｔｏｒの提案の中から最適なものを選択して応答するというサーバ／クライアントモデルで行われる。ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）クライアントとしてのＰＣ１０１が取得すべき必須の情報として、ＩＰアドレス、サブネットマスク、ＩＰアドレスの有効期限、ドメイン名がある。これら４つの情報をＩＫＥ通信においてＲｅｓｐｏｎｄｅｒであるセキュリティ・ゲートウェイ１０３が通常のＩＫＥデータでオプションとして付加する。但し、ＩＰアドレスの有効期限はＩＫＥ通信によって確立されるＳＡの寿命と同じと考えることで省略することができる。またＤＨＣＰもＵＤＰの上位に位置するアプリケーションプロトコルなので、ＩＫＥに組み込んでも再送制御その他の問題は起こらない。
【００３１】図１は本発明の実施の形態１におけるＩＰｓｅｃ通信の概略を示す説明図である。
【００３２】図１において、ＰＣ１０１、セキュリティ・ゲートウェイ１０３、ＬＡＮ１０４、クライアントＰＣ１０６、ＶＰＮ１０８は図４と同様のものである。
【００３３】図１において、ＰＣ１０１、セキュリティ・ゲートウェイ１０３、クライアントＰＣ１０６のＩＰアドレスをそれぞれＡ、Ｂ、Ｃとする（ＡはプロバイダによってＰＣ１０１に付与されたＩＰアドレス）。また、ＩＰｓｅｃ通信に先立つＩＫＥ通信により、セキュリティ・ゲートウェイ１０３は、ＰＣ１０１にＩＰアドレスＤを配布する。ＬＡＮ１０４上のクライアントＰＣ１０６からＶＰＮ１０８を介してコネクションの張られたＰＣ１０１にＩＰパケットを送信する場合、まずクライアントＰＣ１０６において、ＬＡＮ１０４外部でプロバイダによってＰＣ１０１に割り当てられたＩＰアドレスＡを意識することなく、送信元ＩＰアドレスがＣ、宛先ＩＰアドレスがＤのＩＰパケット１０９が作成され、送信される。セキュリティ・ゲートウェイ１０３がこのパケット１０９を受信し、ＶＰＮ１０８を張られたＰＣ１０１宛てのパケットであることを識別すると、ＩＫＥ通信による交換した情報に基づいてＩＰパケット１０９をカプセリングする。元のＩＰアドレスの外側に、送信元ＩＰアドレスＢ、宛先ＩＰアドレスＡのＩＰヘッダが付加される。このとき交換した情報に基づいてカプセリングされたＩＰパケットへの認証情報の付加、暗号化が行われる。ＶＰＮ１０８を介してカプセリングされたパケットを受信したＰＣ１０１は、交換した情報に基づいてカプセリングされた元のＩＰパケット１０９を取り出し、ＩＫＥ通信により取得したサブネットマスク、ドメイン名を元にＩＰパケット１０９を処理する。
【００３４】図２はセキュリティ・ゲートウェイ１０３がＰＣ１０１にＩＰアドレスＤを配布する手順を示すフローチャートである。
【００３５】ＩＰｓｅｃ通信を行うためには、２点間で双方向に論理的なコネクションＳＡを確立しなければならない。そのためにＩＫＥ通信は２つのフェーズに分かれていて、フェーズ１において安全なＩＫＥ通信を行うためのＩＫＥ−ＳＡを確立しようとし（Ｓ１、Ｓ２）、それに成功したら、フェーズ２において、ＩＰｓｅｃ通信するための鍵情報などのセキュリティ情報を交換する（Ｓ３）。フェーズ２でＩＰアドレスＤを配布し、ＩＰｓｅｃ−ＳＡを確立することができれば（Ｓ４）ＩＫＥ通信を終了する（Ｓ５）。ステップＳ３のＩＫＥ（フェーズ２）通信においてＩＰｓｅｃ通信を行うために２点間で交換される情報は（表１）に示す通りである。
【００３６】以上のように本実施の形態によれば、ダイヤルアップ接続でＷＡＮ１０２に接続したＰＣ１０１に対してＩＰｓｅｃプロトコルによりＶＰＮ１０８を実現する際、ＩＰｓｅｃ通信に先立つＩＫＥ通信時に、ＤＨＣＰ通信オプションをＩＫＥデータに統合し、トンネリングされたＩＰパケットにおけるＩＰｓｅｃ処理される送信元ＩＰアドレスの指定（アドレスＣの指定）を実現するようにしたことにより、セキュリティ・ゲートウェイ１０３は、ダイアルアップ接続した外部のＰＣ１０１とＩＰｓｅｃ通信する際、そのＰＣの最終的な宛先ＩＰアドレスＡを制御可能にし、ＬＡＮ１０４配下のクライアント端末１０６への設定を不要とすることができるので、通信内容の盗聴、改竄のおそれが無くなり、安全性を確保することができる。」（段落【００３０】−【００３６】）
　
ニ．「【００３８】図１において、ＩＫＥ通信のＲｅｓｐｏｎｄｅｒであるセキュリティ・ゲートウェイ１０３からＩｎｉｔｉａｔｏｒであるＰＣ１０１にＤＨＣＰ情報を配布する際に、セキュリティ・ゲートウェイ１０３配下のＬＡＮ１０４と同じセグメントのＩＰアドレス、サブネットマスクを配布する。ＶＰＮ１０８確立後のＩＰｓｅｃ通信において、ＶＰＮ１０８上を流れるパケット以外は、ＬＡＮ１０４外部から接続するＰＣ１０１も、セキュリティ・ゲートウェイ１０３配下のクライアント端末１０６とネットワークセグメント上区別のない、しかも一意な端末として通信を行う。」（段落【００３８】）
　
　上記引用例１の記載及び図面ならびにこの分野における技術常識を考慮すると、
・上記「セキュリティ・ゲートウェイ装置におけるＶＰＮ通信方法」が適用される一般的なネットワークシステムとして、外部ＰＣ１０１、セキュリティ・ゲートウェイ１０３、セキュリティ・ゲートウェイ１０３配下のＬＡＮ１０４、ＬＡＮ１０４上のサーバ端末１０５、クライアントＰＣ１０６，１０７、ＰＣ１０１とセキュリティ・ゲートウェイ１０３との間でＩＰｓｅｃ通信を行うために確立されたＶＰＮ１０８、とからなるＶＰＮシステムが記載されており（段落５，図４）、
・ダイヤルアップ接続したＰＣ１０１がＬＡＮ１０４上の端末にアクセスする場合、セキュリティ・ゲートウェイ１０３との間でＶＰＮ１０８を確立しており（段落６）、
・動作モード（ＩＰｓｅｃ通信モード）としてトンネルモードを想定しており（段落１３）、その場合のセキュリティ・プロトコルとしてＥＳＰが用いられ（段落１２、表１）、
・ＰＣ１０１とセキュリティ・ゲートウェイ１０３との２点間でＩＰｓｅｃ通信を行う場合、鍵情報がＩＫＥプロトコルを用いて自動設定され（段落９）、
・ＤＨＣＰクライアントとしてＰＣ１０１が取得すべき必須の情報としてＩＰアドレス、サブネットマスク、ＩＰアドレスの有効期限、ドメイン名があり、これらの情報はＩＫＥデータでオプションとして付加され（段落３０）、また、上記ＩＰアドレスはセキュリティ・ゲートウェイ１０３配下のＬＡＮ１０４と同じセグメントのＩＰアドレスであり（段落００３８）、
・ＩＫＥ通信時のＩＫＥデータはＩＳＡＫＭＰヘッダとＩＳＡＫＭＰペイロードとで構成され（段落３０，図３）ている。
　
　したがって、上記引用例１には以下の発明（以下、「引用発明１」という。）が開示されている。
「ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）トンネル技術にＩＰｓｅｃ（ＩＰ　ｓｅｃｕｒｉｔｙ　ｐｒｏｔｏｃｏｌ）のＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ　Ｓｅｃｕｒｉｔｙ　Ｐａｙｌｏａｄ）トンネル技術を適用したリモートアクセスＩＰｓｅｃＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を用いるＶＰＮシステムであって、
　外部ＰＣ１０１がＬＡＮ１０４上の端末と通信を行う際に前記ＬＡＮ１０４内のセキュリティ・ゲートウェイ１０３との間で前記リモートアクセスＩＰｓｅｃＶＰＮ接続を行う手段を前記外部ＰＣ１０１に有し、
　前記外部ＰＣ１０１と前記ＬＡＮ１０４上の端末とが仮想的に同じセグメント内に接続するとともに、
　前記外部ＰＣ１０１が前記ＬＡＮ１０４内のセキュリティ・ゲートウェイ１０３と前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）ペイロードで対応するＬＡＮ１０４内からのＩＰアドレス等のＤＨＣＰ情報の払い出しを行うＶＰＮシステム」
　
ｂ．原査定の拒絶理由に引用された、「馬場達也、「ここが知りたいＶＰＮ　第３回リモートアクセスＶＰＮにＩＰｓｅｃを利用する」、株式会社ＩＤＧジャパン、ＮＥＴＷＯＲＫ　ＷＯＲＬＤ、第９巻、第５号、２００４年５月１日、ｐｐ．１３２−１３８」（以下、「引用例２」という。）には、「ＩＰｓｅｃを利用したリモートアクセスＶＰＮ」に関し、図面とともに以下の事項が記載されている。
　
ホ．「企業ネットワーク内で使用する内部ネットワーク情報をリモートアクセス端末に自動設定する仕組みとして、多くのリモートアクセス用ＩＰｓｅｃ製品で採用されているのがｍｏｄｅ−ｃｆｇである。ｍｏｄｅ−ｃｆｇはＩＫＥを拡張したプロトコルであり、前回解説したＩＫＥのフェーズ１とフェーズ２の間に行われる。ｍｏｄｅ−ｃｆｇを使用することで、企業ネットワークに関するネットワーク情報をリモートアクセス端末に通知し、企業ネットワークヘ接続できるようになる。通知するネットワーク情報は次のとおりだ。
●クライアントに割り当てる内部アドレスおよびネットマスク（ＩＰｖ４／ＩＰｖ６）
●割り当てた内部アドレスの有効期間（秒）
●内部ＤＮＳサーバのアドレス（ＩＰｖ４／ＩＰｖ６）
●内部ＷｌＮＳサーバのアドレス（ＩＰｖ４／ＩＰｖ６）
●内部ＤＨＣＰサーバのアドレス（ＩＰｖ４／ＩＰｖ６）
●内部ネットワークアドレス（ＩＰｖ４／ＩＰｖ６）
　ｍｏｄｅ−ｃｆｇを使用する場合、ＩＫＥの動作は次のようになる。まずリモートアクセス端末と企業ネットワークのセキュリティゲートウェイの間で、ＩＫＥのフェーズ１が行われる。フェーズ１が完了すると、リモートアクセス端末はｍｏｄｅ−ｃｆｇで定義されたＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＱＵＥＳＴメッセージに、通知を要求するネットワーク情報を指定してセキュリティゲートウェイヘ送信する（図１）。
　例えば内部ＩＰアドレスやネットマスク、内部ＤＮＳサーバのアドレスを要求する場合、リモートアクセス端末はＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＱＵＥＳＴメッセージに「ＩＮＴＥＲＮＡＬ＿ＩＰ４＿ＡＤＤＲＥＳＳ」「ＩＮＴＥＲＮＡＬ＿ＩＰ４＿ＮＥＴＭＡＳＫ」「ＩＮＴＥＲＮＡＬ＿ＩＰ４＿ＤＮＳ」といった属性を指定してセキュリティゲートウェイヘ送信する。このようにして、ＩＰアドレスの割り当てやネットマスクおよび内部ＤＮＳサーバのアドレスの通知をセキュリティゲートウェイに要求する。これらを受信したセキュリティゲートウェイは、リモートアクセス端末用の内部ＩＰアドレスを確保し、ＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＰＬＹメッセージを使用して要求されたネットワーク情報をリモートアクセス端末へ返答する。
　このｍｏｄｅ−ｃｆｇの交換内容は、フェーズ１で確立されるＩＳＡＫＭＰ　ＳＡによって保護される。また、セキュリティゲートウェイ側からｍｏｄｅ−ｃｆｇを開始することもできる（図２）。その場合はＩＳＡＫＭＰ＿ＣＦＧ＿ＳＥＴメッセージに、さきほどのＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＰＬＹメッセージと同じくリモートアクセス端末に設定するネットワーク情報を格納して送信する。これを受信したリモートアクセス端末は、その内容を確認してセキュリティゲートウェイにＩＳＡＫＭＰ＿ＣＦＧ＿ＡＣＫメッセージを返すという流れだ。」（第１３２−１３３頁）
　
ヘ．「ＩＰｓｅｃ−ＤＨＣＰによる処理の手順は次のとおりである（図３）。まずリモートアクセス端末は、企業ネットワークのセキュリティゲートウェイとの間でＩＫＥのフェーズ１を行い、その後フェーズ２において、ＤＨＣＰ　ＳＡと呼ばれるＤＨＣＰメッセージを交換するためだけに利用される一時的なＩＰｓｅｃトンネルを確立する。リモートアクセス端末は、このＤＨＣＰ　ＳＡを使用してＤＨＣＰメッセージの交換を行い、企業ネットワークのＤＨＣＰサーバから内部ＩＰアドレスの割り当てを受ける。ＤＨＣＰメッセージを交換する際、セキュリティゲートウェイはリモートアクセス端末とＤＨＣＰサーバとの間でＤＨＣＰトラフィックを中継するＤＨＣＰリレーとして動作する。ＤＨＣＰの設定が完了するとＤＨＣＰ　ＳＡは削除され、続いてＩＫＥのフェーズ２によってＩＰｓｅｃトンネルが確立される。リモートアクセス端末はＤＨＣＰサーバから割り当てられた内部ＩＰアドレスを使用し、ＩＰｓｅｃトンネルを経由して企業ネットワークヘアクセスすることになる。」（第１３４頁）
　
ト．「したがって、ＩＫＥの相手認証にレガシー認証システムを利用するために、ＩＫＥを拡張したＸＡＵＴＨプロトコルが多くのＩＰｓｅｃ製品で使用されている。・・・（中略）・・・ＸＡＵＴＨに加えｍｏｄｅ−ｃｆｇまたはＩＰｓｅｃ−ＤＨＣＰを利用する場合は、ＸＡＵＴＨによる認証が完了した直後にはｍｏｄｅ−ｃｆｇやＩＰｓｅｃ−ＤＨＣＰを行う（図４）。
　ＸＡＵＴＨを利用する時は、通常のＩＫＥのフェーズ１で行われる相手認証に加えＸＡＵＴＨによるユーザー認証を行う。ＸＡＵＴＨ認証におけるＩＫＥのフェーズ１の認証では、通常、事前共有鍵（ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ）認証が使用される。
　ユーザー認証において、通常のパスワードやＳｅｃｕｒＩＤなどの認証トークンを利用する場合は次のようになる（図５）。ＩＫＥのフェーズ１の完了後、セキュリティゲートウェイがリモートアクセス端末へＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＱＵＥＳＴメッセージを発行してユーザー名とパスワードを要求する。これに応答して、リモートアクセス端末はＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＰＬＹメッセージを使ってユーザー名とパスワードを送信する。」（第１３４−１３５頁）
　
　上記引用例２の記載及び図面ならびにこの分野における技術常識を考慮すると、上記引用例２には、「ＩＰｓｅｃを利用したリモートアクセスＶＰＮ」において、以下の事項が記載されている。
・セキュリティ・ゲートウェイは、ＩＳＡＫＭＰコンフィグレーションメッセージ（ＩＳＡＫＭＰ＿ＣＦＧ＿ＲＥＰＬＹ，ＩＳＡＫＭＰ＿ＣＦＧ＿ＳＥＴ等）を使用して、閉域ＩＰ網である企業ネットワークの内部ＤＮＳサーバのアドレスやクライアントに割り当てる内部ＩＰアドレスなどのネットワーク情報をリモートアクセス端末に送信すること（上記摘記事項ホ）
・セキュリティ・ゲートウェイは、閉域ＩＰ網である企業ネットワークのＤＨＣＰサーバからリモートアクセス端末に割り当てる内部ＩＰアドレスを取得することが可能であること（上記摘記事項ヘ及び図３）
・ＩＫＥを拡張したＸＡＵＴＨプロトコルでは、通常のＩＫＥのフェーズ１で行われる認証に加え、パスワードやＳｅｃｕｒｅＩＤなどの認証トークンを用いたユーザ認証をＩＳＡＫＭＰコンフィグレーションの認証通信にて行うこと（上記摘記事項ト）
　
（３）対比・判断
　補正後の発明と引用発明１とを対比すると、
・引用発明１の「外部ＰＣ１０１」、「ＬＡＮ１０４」、「ＬＡＮ１０４上の端末」はそれぞれ補正後の発明の「リモート端末」、「閉域ＩＰ網」、「閉域ＩＰ網内のノード」に相当し、
・引用発明１の「セキュリティ・ゲートウェイ」は閉域ＩＰ網であるＬＡＮ１０４上にあって外部ＰＣ１０１との間にＶＰＮを確立するものであるから「境界ゲートウェイ」であることは自明であり、
・両発明は「リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）の通信でＩＰアドレスの払い出しを行う」点で共通するから、
　
　補正後の発明と引用発明１とは、以下の点で一致ないし相違している。
　
（一致点）
　「ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）トンネル技術にＩＰｓｅｃ（ＩＰ　ｓｅｃｕｒｉｔｙ　ｐｒｏｔｏｃｏｌ）のＥＳＰ（Ｅｎｃａｐｓｕｌａｔｉｎｇ　Ｓｅｃｕｒｉｔｙ　Ｐａｙｌｏａｄ）トンネル技術を適用したリモートアクセスＩＰｓｅｃＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を用いるＶＰＮシステムであって、
　リモート端末がリモートアクセス先の閉域ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）網内のノードと通信を行う際に前記閉域ＩＰ網内の境界ゲートウェイとの間で前記リモートアクセスＩＰｓｅｃＶＰＮ接続を行う手段を前記リモート端末に有し、
　前記リモート端末と前記閉域ＩＰ網内のノードとが仮想的に同じセグメント内に接続するとともに、
　前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時に、ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）の通信にて前記閉域ＩＰ網内からの前記ＩＰアドレスの払い出しを行うＶＰＮシステム。」
　
（相違点１）
　補正後の発明は、「ＩＳＡＫＭＰコンフィグレーションの認証通信にてリモート端末上のユーザを特定」するのに対し、引用発明１はそのような処理を行わない点
（相違点２）
　補正後の発明は、「対応する閉域ＩＰ網内のＩＰアドレスを閉域ＩＰ網内のノードから取得」するのに対し、引用発明１では対応するＩＰアドレスをどのようにして取得するのかが明確ではない点
（相違点３）
　「閉域ＩＰ網内からの前記ＩＰアドレスの払い出し」に関し、補正後の発明は、「ＩＳＡＫＭＰコンフィグレーションのＶＰＮアドレス払い出しにおいて前記ＶＰＮアドレスに前記閉域ＩＰ網内のＩＰアドレスを割当てることで」行うのに対し、引用発明１は、「ＩＳＡＫＭＰペイロードで」行う点
（相違点４）
　「前記リモート端末が前記閉域ＩＰ網内の境界ゲートウェイと前記リモートアクセスＩＰｓｅｃＶＰＮ接続する際、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）通信時」の処理に関し、補正後の発明は、「ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて、対応するコンフィグデータを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのメッセージに前記コンフィグデータを統合して前記閉域ＩＰ網内からの前記リモート端末のコンフィグデータの払い出しを行う」のに対し、引用発明１は、「ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）ペイロードでＬＡＮ１０４内からのＤＨＣＰ情報の払い出しを行う」点
　
　そこで、相違点について検討する。
（相違点１）
　ＶＰＮ確立時にＩＫＥのフェーズ１で行われる認証に加え、パスワードやＳｅｃｕｒｅＩＤなどの認証トークンを用いたユーザ認証をＩＳＡＫＭＰコンフィグレーションの認証通信にて行う技術が引用例２に記載されており（上記（２）引用発明ｂ．の項参照）、引用例２に記載されたＶＰＮは引用発明１のＶＰＮシステムと同一の技術分野に属することは明白であり、上記「パスワードやＳｅｃｕｒｅＩＤなどの認証トークンを用いたユーザ認証」とは「リモート端末上のユーザを特定」することに他ならないから、上記相違点１は引用例２の記載に基づいて当業者が容易に想到し得たものと認められる。
（相違点２）
　引用例１には外部ＰＣ１０１がＤＨＣＰクライアントであることが記載されており（上記摘記事項ハ．、段落３０）、さらに、引用例２にはリモート端末に割り当てる内部ネットワークＩＰアドレスをＤＨＣＰサーバから取得することが記載されており（上記摘記事項ヘ及び図３）、該ＤＨＣＰサーバが閉域ＩＰ網である企業ネットワークのノードであることは自明であるから、引用発明１において、リモート端末に対応するＩＰアドレスを閉域ＩＰ網内のノードから取得することは引用例２の記載に基づいて当業者が容易に想到し得たものと認められる。
（相違点３）
　引用例２には、セキュリティ・ゲートウェイは、ＩＳＡＫＭＰコンフィグレーションメッセージを使用して、閉域ＩＰ網である企業ネットワークの内部ＩＰアドレスなどのネットワーク情報をリモートアクセス端末に送信すること（上記摘記事項ホ）が記載されており、該内部ＩＰアドレスが引用例２に記載されたＶＰＮにおいてリモート端末のＶＰＮアドレスとなることは自明であるから、引用例２に記載された「ＩＳＡＫＭＰコンフィグレーションメッセージを使用して内部ＩＰアドレスを送信すること」なる事項は、補正後の発明の「ＩＳＡＫＭＰコンフィグレーションのＶＰＮアドレス払い出しにおいてＶＰＮアドレスに閉域ＩＰ網内のＩＰアドレスを割当てること」なる事項に等しいと認められる。とすれば、引用発明１が「ＩＳＡＫＭＰペイロードで」内部ＩＰアドレスを払い出す際に引用例２に記載された事項を適用して、「ＩＳＡＫＭＰコンフィグレーションのＶＰＮアドレス払い出しにおいてＶＰＮアドレスに閉域ＩＰ網内のＩＰアドレスを割当てること」による内部ＩＰアドレスを払い出すようにすることは当業者であれば容易になし得たものと認められる。
（相違点４）
　そもそも引用発明１のＤＨＣＰ情報におけるＤＨＣＰとはＤｙｎａｍｉｃ　Ｈｏｓｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｐｒｏｔｏｃｏｌのことであるから、ＤＨＣＰ情報はコンフィグデータと言うことができるものであるが、引用例２には、ＩＳＡＫＭＰコンフィグレーションメッセージを使用して、閉域ＩＰ網である企業ネットワークの内部ＤＮＳサーバのアドレスなどのネットワーク情報をリモートアクセス端末に送信することが記載されており（摘記事項ホ）、ここで「内部ＤＮＳサーバのアドレス」はネットワークの「コンフィグデータ」と言い得るものであり、また、ＤＨＣＰサーバによりＤＮＳサーバのアドレスを付与することも普通に行われていることに過ぎない。また、引用例１には、ＩＳＡＫＭＰペイロードで認証手続を行うことが記載されている（上記摘記事項ハ、段落３０）。これらの記載に基づけば、引用発明１の「ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）ペイロードでＬＡＮ１０４内からのＤＨＣＰ情報の払い出しを行う」ことを、「ＩＳＡＫＭＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ　＆　Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）コンフィグレーションの認証通信にて、対応するコンフィグデータを前記閉域ＩＰ網内のノードから取得し、前記ＩＳＡＫＭＰコンフィグレーションのメッセージに前記コンフィグデータを統合して前記閉域ＩＰ網内からの前記リモート端末のコンフィグデータの払い出しを行う」と限定することは当業者であれば容易になし得たものと認められる。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１９年１０月２２日付けの手続補正は上記のとおり却下されたので、本願発明は上記「第２．補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用例１，２の記載に基づいて当業者が容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用例１，２の記載に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。