【事件の表示】
　特願２００９−　９７６２３「プロキシ・ベースの双方向ウェブサービス・ルータ・ゲートウェイ」拒絶査定不服審判事件〔平成２１年１２月１０日出願公開、特開２００９−２９０８６１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成２１年　４月１４日（パリ条約による優先権主張、２００８年　５月２７日、（ＵＳ）米国、２００９年　２月１９日、（ＵＳ）米国）の出願であって、平成２５年　２月２５日付けで拒絶査定がなされ、これに対し、平成２５年　６月２７日付けで審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［結論］
　　平成２５年　６月２７日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　平成２５年　６月２７日付け手続補正（以下、「本件補正」という。）は、補正前の特許請求の範囲の請求項１に記載された
「　　（Ａ）第１トンネル（１３１−１）を確立するステップと、
　　　　　　前記第１トンネル（１３１−１）は、第１企業ドメイン（１１０−１）にある第１トンネル・ゲートウェイ（１２３−１）から、第１ファイアウォール（１１１−１）を介して、パブリック・ドメイン（１０１）にあるトンネル・ハブ（１１２）までの間であり、
　　　　　　前記第１トンネル（１３１−１）は、前記第１ファイアウォール（１１１−１）の背後から、前記第１トンネル・ゲートウェイ（１２３−１）により、前記第１企業ドメイン（１１０−１）の内側から前記トンネル・ハブ（１１２）まで、確立され、
　　　（Ｂ）第２トンネル（１３１−２）を確立するステップと、
　　　　　　前記第２トンネル（１３１−２）は、第２企業ドメイン（１１０−２）にある第２トンネル・ゲートウェイ（１２３−２）から、第２ファイアウォール（１１１−２）を介して、前記トンネル・ハブ（１１２）までであり、
　　　　　　前記第２トンネル（１３１−２）は、前記第２ファイアウォール（１１１−２）の背後から、前記第２トンネル・ゲートウェイ（１２３−２）により、前記第２企業ドメイン（１１０−２）の内側から前記トンネル・ハブ（１１２）まで、確立され、
を有する
ことを特徴とするトンネルを確立する方法。」
という発明（以下、「本願発明」という。）を
「　　（Ａ）第１企業ドメイン（１１０−１）にある第１トンネル・ゲートウェイ（１２３−１）から、第１ファイアウォール（１１１−１）を介して、パブリック・ドメイン（１０１）にあるトンネル・ハブ（１１２）まで第１トンネル（１３１−１）を確立するステップと、
　　　（Ｂ）第２企業ドメイン（１１０−２）にある第２トンネル・ゲートウェイ（１２３−２）から、第２ファイアウォール（１１１−２）を介して、前記トンネル・ハブ（１１２）まで第２トンネル（１３１−２）を確立するステップと
を有し、
　　　　　　前記第１トンネル（１３１−１）は、前記第１ファイアウォール（１１１−１）の背後からの前記第１トンネル・ゲートウェイ（１２３−１）により、前記第１企業ドメイン（１１０−１）の内側から前記トンネル・ハブ（１１２）まで、確立され、
　　　　　　前記第２トンネル（１３１−２）は、前記第２ファイアウォール（１１１−２）の背後からの前記第２トンネル・ゲートウェイ（１２３−２）により、前記第２企業ドメイン（１１０−２）の内側から前記トンネル・ハブ（１１２）まで、確立される
ことを特徴とするトンネルを確立する方法。」
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．補正の適否
（１）補正の目的要件
　請求人が審判請求書において、「この補正は実質的なものではない。新請求項は、旧請求項の文章を短く区切っていたものを、一文にまとめただけである。」と主張しているように、上記補正は、補正後の発明と本願発明との間に実質的な差異をもたらすものではなく、特許法第１７条の２第５項（補正の目的）の各号のいずれにも該当しない。
　
（２）独立特許要件
　上記（１）に記載したとおり、本件補正は、特許法第１７条の２第５項（補正の目的）の各号のいずれにも該当しない補正を含むものであって、却下すべきものであるが、上記補正が、仮に、特許請求の範囲の減縮を目的とするものであるとして、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのか否かについても、以下検討する。
　
［補正後の発明］
　上記「１．本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりのものである。
　
［引用発明］
　原査定の拒絶理由に引用された国際公開第２００６／０９３０２１号（以下、「引用例」という。）には、「通信装置、通信システム、通信方法、及びプログラム」として、図面とともに以下の事項が記載されている。
　
イ．「［０００２］
　まず、従来技術１について説明する。
　従来、Ｅｔｈｅｒ  ｏｖｅｒ  ＳＳＬ通信により、インターネット等により相互に接続された複数のイントラネットを相互に結び、同一のＬＡＮセグメントとして利用できるようにする技術が提案（非特許文献１）されている。
［０００３］
　図１は、かかる従来技術におけるネットワークの構成を示すブロック図である。
［０００４］
　インターネット１は、セッション中継装置１０、Ｆｉｒｅｗａｌｌ２３、及びＦｉｒｅｗａｌｌ３３、若しくはその他の機器で構成され、これら機器の相互間で通信を行うワイドエリアネットワーク（ＷＡＮ）である。図１において、インターネット１内の各機器は、ＨＵＢ１１を介して相互に接続されており、Ｆｉｒｅｗａｌｌ２３やＦｉｒｅｗａｌｌ３３を通じて、イントラネット２やイントラネット３とも接続されている。
［０００５］
　セッション中継装置１０は、ＳｏｆｔＥｔｈｅｒ仮想ＨＵＢソフトウェアがインストールされたコンピュータである。セッション中継装置１０は、ＨＵＢ１１を介して、インターネット１内の各機器と接続されている。セッション中継装置１０は、ゲートウェイ装置２０とセッション中継装置１０の間で設定されるＳＳＬセッション内を流れるＥｔｈｅｒｎｅｔフレームを、ゲートウェイ装置３０とセッション中継装置１０の間で設定されるＳＳＬセッションに転送し、又、逆に、ゲートウェイ装置３０とセッション中継装置１０の間で設定されるＳＳＬセッション内を流れるＥｔｈｅｒｎｅｔフレームを、ゲートウェイ装置２０とセッション中継装置１０の間で設定されるＳＳＬセッションに転送する、セッション中継動作を行う。
［０００６］
　ＨＵＢ１１は、セッション中継装置１０、Ｆｉｒｅｗａｌｌ２３、Ｆｉｒｅｗａｌｌ３３の各装置から入力されたＥｔｈｅｒｎｅｔフレームのＭＡＣ  ＤＡヘッダを参照し、適切な宛先ポート（適切な装置）に転送する、ブリッジ動作を行う。」（１頁）
　
ロ．「［０００７］
　イントラネット２は、ゲートウェイ装置２０、端末２１、ＨＵＢ２２、及びＦｉｒｅｗａｌｌ２３で構成され、これら機器の相互間で通信を行うローカルエリアネットワーク（ＬＡＮ）である。イントラネット２は、インターネット１と、Ｆｉｒｅｗａｌｌ２３を介して相互に接続されており、Ｆｉｒｅｗａｌｌ２３の動作により、インターネット１とイントラネット２の間の通信は、あらかじめ決められた設定に従って制限されている。
［０００８］
　イントラネット２内の各装置は、ＨＵＢ２２を介して相互に接続されており、イントラネット２内の各装置間は、前述のＦｉｒｅｗａｌｌ２３等の制限を受けることなく、自由に通信を行うことができる。又、図においては、ゲートウェイ装置２０、ゲートウェイ装置３０、及びセッション中継装置１０により、イントラネット２とイントラネット３は、同一のＬＡＮとして動作するよう相互に接続されている為、イントラネット２内の各装置と、イントラネット３内の各装置間も、前述のＦｉｒｅｗａｌｌ２３等の制限を受けることなく、自由に通信を行うことができる。
［０００９］
　ゲートウェイ装置２０は、ＳｏｆｔＥｔｈｅｒクラアントがインストールされたコンピュータである。ゲートウェイ装置２０は、ＨＵＢ２２を介して、イントラネット２内の各機器と接続されている。ゲートウェイ装置２０は、イントラネット２内を流れるＥｔｈｅｒｎｅｔフレームを、ゲートウェイ装置２０とセッション中継装置１０の間で設定されるＳＳＬセッション内に転送し、又、逆に、ゲートウェイ装置２０とセッション中継装置１０の間で設定されるＳＳＬセッション内を流れるＥｔｈｅｒｎｅｔフレームをイントラネット２内に転送する、ゲートウェイ動作を行う。
［００１０］
　端末２１は、イントラネットの利用者が通常利用するコンピュータであり、イントラネット内の各機器（例えばサーバ３１）との間で通信を行う為のソフトウェア（例えば、インターネットブラウザやメーラー等）が動作する。端末２１は、ＨＵＢ２２を介してイントラネット２上の各機器と接続されている。
［００１１］
　ＨＵＢ２２は、ＨＵＢ１１と同様に、ゲートウェイ装置２０、端末２１、Ｆｉｒｅｗａｌｌ２３の各装置から入力されたＥｔｈｅｒｎｅｔフレームのＭＡＣ  ＤＡヘッダを参照し、適切な宛先ポート（適切な装置）に転送する、ブリッジ動作を行う。
［００１２］
　Ｆｉｒｅｗａｌｌ２３は、イントラネット２とインターネット１とを相互に接続するための機器であり、ＨＵＢ２２を介してイントラネット２上の各機器と接続され、ＨＵＢ１１を介してインターネット１上の各機器と接続されている。Ｆｉｒｅｗａｌｌ２３は、インターネット１とイントラネット２の間の通信を、予め決められた設定に従って制限する動作を行う。例えば、イントラネット２内部の装置からインターネット１の各装置へＴＣＰを用いて通信開始の要求をした場合、以降の通信は双方向で自由に行えるが、逆に、インターネット１の各装置からイントラネット２の各装置へＴＣＰを用いて通信開始の要求を行った場合、この要求は遮断され、以降の通信も双方向で遮断される。」（２〜３頁）
　
ハ．「［００１３］
　イントラネット３は、ゲートウェイ３０、サーバ３１、ＨＵＢ３２、およびＦｉｒｅｗａｌｌ３３で構成され、これら機器の相互間で通信を行うローカルエリアネットワーク（ＬＡＮ）である。イントラネット３は、インターネット１と、Ｆｉｒｅｗａｌｌ３３を介して相互に接続されており、Ｆｉｒｅｗａｌｌ３３の動作により、インターネット１とイントラネット３の間の通信は、予め決められた設定に従って制限されている。
［００１４］
　イントラネット３内の各装置は、ＨＵＢ３２を介して相互に接続されており、イントラネット３内の各装置間は、前述のＦｉｒｅｗａｌｌ３３等の制限を受けることなく、自由に通信を行うことができる。又、図１においては、ゲートウェイ装置２０、ゲートウェイ装置３０、及びセッション中継装置１０により、イントラネット２とイントラネット３は、同一のＬＡＮとして動作するよう相互に接続されている為、イントラネット３内の各装置と、イントラネット２内の各装置間も、前述のＦｉｒｅｗａｌｌ３３等の制限を受けることなく、自由に通信を行うことができる。
［００１５］
　ゲートウェイ装置３０は、ゲートウェイ装置２０と同様の構成を有し、同様の動作を行うコンピュータである。図番号については、ゲートウェイ装置３０における３０００番台のものは、ゲートウェイ装置２０の２０００番台のものに、そのまま対応する。例えば、中間ドライバ３００６の構成および動作は、中間ドライバ２００６の構成および動作と同一である。ゲートウェイ装置３０は、ＳｏｆｔＥｔｈｅｒクラアントがインストールされ、ＨＵＢ３２を介して、イントラネット３内の各機器と接続されている。ゲートウェイ装置３０は、イントラネット３内を流れるＥｔｈｅｒｎｅｔフレームを、ゲートウェイ装置３０とセッション中継装置１０の間で設定されるＳＳＬセッション内に転送し、又、逆に、ゲートウェイ装置３０とセッション中継装置１０の間で設定されるＳＳＬセッション内を流れるＥｔｈｅｒｎｅｔフレームをイントラネット３内に転送する、ゲートウェイ動作を行う。
［００１６］
　サーバ３１は、イントラネット内の端末からのアクセスを受けるコンピュータであり、イントラネット内の各端末（例えば端末２１）からの通信受け付ける為のソフトウェア（例えば、ＷＷＷサーバやＰＯＰサーバ等）が動作する。サーバ３１は、ＨＵＢ３２を介してイントラネット３上の各機器と接続されている。
［００１７］
　ＨＵＢ３２は、ＨＵＢ１１やＨＵＢ２２と同様に、ゲートウェイ装置３０、サーバ３１、Ｆｉｒｅｗａｌｌ３３の各装置から入力されたＥｔｈｅｒｎｅｔフレームのＭＡＣ  ＤＡヘッダを参照し、適切な宛先ポート（適切な装置）に転送する等のブリッジ動作を行う。
［００１８］
　Ｆｉｒｅｗａｌｌ３３は、イントラネット３とインターネット１とを相互に接続する為の機器であり、ＨＵＢ３２を介してイントラネット３上の各機器と接続され、ＨＵＢ１１を介してインターネット１上の各機器と接続されている。Ｆｉｒｅｗａｌｌ３３は、インターネット１とイントラネット３の間の通信を、予め決められた設定に従って制限する動作を行う。例えば、イントラネット３内部の装置からインターネット１の各装置へＴＣＰを用いて通信開始の要求をした場合、以降の通信は双方向で自由に行えるが、逆にインターネット１の各装置からイントラネット３の各装置へＴＣＰを用いて通信開始の要求を行った場合、この要求は遮断され、以降の通信も双方向で遮断される。」（３〜４頁）
　
ニ．「［００３０］
　［従来技術１の動作例］
　図１を用いて、端末２１からサーバ３１への通信（フレーム転送）を行う場合を例に、従来技術１の動作について説明する。
［００３１］
　ここでは、サーバ３１と端末２１との間では、すでに何度か通信が行われており、ＨＵＢ２２やＨＵＢ３２がすでに端末２１、サーバ３１、Ｆｉｒｅｗａｌｌ２３のＬＡＮ側，Ｆｉｒｅｗａｌｌ３３のＬＡＮ側、ゲートウェイ装置２０、ゲートウェイ装置３０のＭＡＣアドレスを学習しているものとする。又、ＨＵＢ１１は、Ｆｉｒｅｗａｌｌ２３のＷＡＮ側、Ｆｉｒｅｗａｌｌ３３のＷＡＮ側、セッション中継装置１０の各装置のＭＡＣアドレスを学習しているものとする。更に、ゲートウェイ装置２０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）が既に設定されており、同様にゲートウェイ装置３０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）も、既に設定されているものとする。又、Ｆｉｒｅｗａｌｌ２３およびＦｉｒｅｗａｌｌ３３は、イントラネット内部の装置（ＬＡＮ側）からインターネットの各装置（ＷＡＮ側）へＴＣＰを用いて通信開始の要求をした場合、以降の通信は双方向で自由に行えるが、逆にインターネットの各装置（ＷＡＮ側）からイントラネットの各装置（ＬＡＮ側）へＴＣＰを用いて通信開始の要求を行った場合、この要求は遮断され、以降の通信も双方向で遮断されるとする。
［００３２］
　先ず、端末２１からサーバ３１宛のフレームを送信する。このフレームはＥｔｈｅｒｎｅｔフレームＦ２０のフォーマットを有し、ＬＡＮ  ＭＡＣ  Ｆ２１内のＭＡＣ  ＤＡにはサーバ３１のＭＡＣアドレスが設定され、ＬＡＮ  ＭＡＣ  Ｆ２１内のＭＡＣ  ＳＡには端末２１のＭＡＣアドレスが設定される。又、ＬＡＮ  ＩＰ  Ｆ２２内のＩＰ  ＤＡには、サーバ３１のＩＰアドレスが設定され、ＬＡＮ  ＩＰ  Ｆ２２内のＩＰ  ＳＡには、端末２１のＩＰアドレスが設定される。
［００３３］
　ＨＵＢ２２は、端末２１からのフレームを受信すると、Ｆ２１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがサーバ３１のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままゲートウェイ装置２０側のポートに出力する。
［００３４］
　ゲートウェイ装置２０は、ＨＵＢ２２からフレームを受信すると、このフレームを、予めセッション中継装置１０との間で設定しているＳＳＬセッションに流す。つまり、Ｆ２０のフォーマットでゲートウェイ装置２０に入力されたフレームは、暗号化された上でＦ１４の領域に格納され、Ｅｔｈｅｒ  ｏｖｅｒ  ＳＳＬフレームＦ１０のフォーマットで、ゲートウェイ装置２０からＨＵＢ２２に転送される。
［００３５］
　この時、ＩＮＥＴ  ＭＡＣ  Ｆ１１内のＭＡＣ  ＤＡにはＦｉｒｅｗａｌｌ２３のＬＡＮ側のＭＡＣアドレスが設定され、Ｆ１１内のＭＡＣ  ＳＡにはゲートウェイ装置２０のＭＡＣアドレスが設定される。又、ＩＮＥＴ  ＩＰ  Ｆ１２内のＩＰ  ＤＡにはセッション中継装置１０のＩＰアドレスが設定され、Ｆ１２内のＩＰ  ＳＡにはゲートウェイ装置２０のＩＰアドレスが設定される。Ｆ２１〜Ｆ２４の内容には変化がない。
［００３６］
　ＨＵＢ２２は、ゲートウェイ装置２２からのフレームを受信すると、Ｆ１１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがＦｉｒｅｗａｌｌ２３のＬＡＮ側のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままＦｉｒｅｗａｌｌ２３側のポートに出力する。
［００３７］
　Ｆｉｒｅｗａｌｌ２３は、ＨＵＢ２２からのフレームを受信すると、Ｆ１２内のＩＰ  ＤＡを参照し、ＩＰ  ＤＡがインターネット１側に存在するものであることから、Ｆ１１内のＭＡＣ  ＤＡをセッション中継装置１０のＭＡＣアドレスに書き換え、更にＦ１１内のＭＡＣ  ＳＡをＦｉｒｅｗａｌｌ２３のＷＡＮ側のＭＡＣアドレスに書き換えて、Ｆ１０のフレームフォーマットのまま、ＨＵＢ１１に転送する。Ｆ２１〜Ｆ２４の内容には変化がない。」（５〜７頁）
　
ホ．「［００３８］
　ＨＵＢ１１は、Ｆｉｒｅｗａｌｌ２３からのフレームを受信すると、Ｆ１１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがセッション中継装置１０のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままセッション中継装置１０側のポートに出力する。
［００３９］
　セッション中継装置１０は、ＨＵＢ１１からフレームを受信すると、Ｆ１４の暗号化を一旦解除し、Ｆ２１内のＭＡＣ  ＤＡを参照して、ＭＡＣ  ＤＡがサーバ３１のものであることから、過去のルーティング学習結果に基づき、このフレームを予めゲートウェイ装置３０との間で設定しているＳＳＬセッションに流す。つまり、Ｆ１０のフォーマットでセッション中継装置１０に入力されたフレームは、暗号化を解除されてＦ２０のフォーマットになり、再び暗号化にされて、Ｆ１０のフォーマットにおけるＦ１４の領域に格納され、Ｆ１０のフォーマットで、セッション中継装置１０からＨＵＢ１１に転送される。
［００４０］
　この時、ＩＮＥＴ  ＭＡＣ  Ｆ１１内のＭＡＣ  ＤＡにはＦｉｒｅｗａｌｌ３３のＷＡＮ側のＭＡＣアドレスが設定され、Ｆ１１内のＭＡＣ  ＳＡにはセッション中継装置１０のＭＡＣアドレスが設定される。又、ＩＮＥＴ  ＩＰ  Ｆ１２内のＩＰ  ＤＡにはゲートウェイ装置３０のＩＰアドレスが設定され、Ｆ１２内のＩＰ  ＳＡにはセッション中継装置１０のＩＰアドレスが設定される。Ｆ２１〜Ｆ２４の内容には変化がない。
［００４１］
　ＨＵＢ１１は、セッション中継装置１０からのフレームを受信すると、Ｆ１１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがＦｉｒｅｗａｌｌ３３のＷＡＮ側のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままＦｉｒｅｗａｌｌ３３側のポートに出力する。
［００４２］
　Ｆｉｒｅｗａｌｌ３３は、ＨＵＢ１１からのフレームを受信すると、Ｆ１２内のＩＰ  ＤＡを参照し、ＩＰ  ＤＡがイントラネット３側に存在するものであることから、Ｆ１１内のＭＡＣ  ＤＡをゲートウェイ装置３０のＭＡＣアドレスに書き換え、更にＦ１１内のＭＡＣ  ＳＡをＦｉｒｅｗａｌｌ３３のＬＡＮ側のＭＡＣアドレスに書き換えて、Ｆ１０のフレームフォーマットのまま、ＨＵＢ３２に転送する。Ｆ２１〜Ｆ２４の内容には変化がない。」（７〜８頁）
　
ヘ．「［００４３］
　ＨＵＢ３２は、Ｆｉｒｅｗａｌｌ３３からのフレームを受信すると、Ｆ１１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがゲートウェイ装置３０のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままゲートウェイ装置３０側のポートに出力する。
［００４４］
　ゲートウェイ装置３０は、ＨＵＢ３２からＦ１０のフォーマットでフレームを受信すると、Ｆ１４の暗号化を解除してＦ１４に格納されているＥｔｈｅｒｎｅｔフレームＦ２０を取り出し、このフレームをＦ２０のフォーマットでＨＵＢ３２に転送する。
［００４５］
　このフレームは、端末２１から送信された時の状態そのままに保たれており、ＬＡＮ  ＭＡＣ  Ｆ２１内のＭＡＣ  ＤＡにはサーバ３１のＭＡＣアドレスが設定され、ＬＡＮ  ＭＡＣ  Ｆ２１内のＭＡＣ  ＳＡには端末２１のＭＡＣアドレスが設定されている。又、ＬＡＮ  ＩＰ  Ｆ２２内のＩＰ  ＤＡには、サーバ３１のＩＰアドレスが設定され、ＬＡＮ  ＩＰ  Ｆ２２内のＩＰ  ＳＡには、端末２１のＩＰアドレスが設定されている。
［００４６］
　ＨＵＢ３２は、ゲートウェイ装置３０からのフレームを受信すると、Ｆ２１内のＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがサーバ３１のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままサーバ３１側のポートに出力する。
［００４７］
　サーバ３１は、ＨＵＢ３２から送信されたフレームを受信し、端末２１からサーバ３１への一連のフレーム転送が完了する。
［００４８］
　サーバ３１から端末２１へのフレーム転送も、上記の逆の経路をたどることで、同様に実現される。
［００４９］
　以上のようにして、従来技術１を用いると、端末２１とサーバ３１は、あたかも同一ＬＡＮ上に存在しているかのように、Ｆｉｒｅｗａｌｌ等による制限を受けることなく通信できる。」（８〜９頁）
　
ト．「［００９６］
　［第１の実施の形態］
　本発明の第１の実施の形態は、図３３に示すように、ＳＳＬセッションを確立させる際、セッション中継装置１０内のＣＰＵ１００のＴＣＰと中間ドライバのＴＣＰとの間でＴＣＰセッションを確立させ、更にゲートウェイ装置２０のＴＣＰと中間ドライバのＴＣＰとの間でＴＣＰセッションを確立させ、セッション中継装置１０とゲートウェイ装置２０との間でＴＣＰにおける輻輳制御を行わないようにしている。・・・（中略）・・・尚、本発明において、ＣＰＵ内のＴＣＰと中間ドライバのＴＣＰとの間でＴＣＰセッションを確立させることをＴＣＰのセッションを終端させるという。
　更に、ゲートウェイ装置２０内のＮＩＣ（Network
Interface Card）２０１に高速化エンジンを備えている。これらにより、ゲートウェイ装置２０におけるカプセル化処理や、暗号化／復号化処理を高速化する他、ＴＣＰ  ｏｖｅｒ　ＴＣＰ問題を回避し、更に、暗号化／復号化処理とカプセル化処理を同一箇所で実現し、又、ＮＩＣ内の比較的安価なインタフェース上に実装することで、低価格化を実現する。
［００９７］
　第１の実施の形態のネットワーク構成は、図１に示す従来技術１と同様である。
［００９８］
　しかしながら、ゲートウェイ装置２０と、セッション中継装置１０の内部構成が、従来技術に対して異なっている。」（１９〜２０頁）
　
チ．「［０２１８］
　［動作の説明］
　［ＳＳＬセッションの確立動作］
　図１６を用いて、第１の実施の形態において、ゲートウェイ装置２０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）を確立する場合を例に挙げて、動作の説明を行う。
［０２１９］
　この際、ＨＵＢ２２やＨＵＢ３２が、既に、端末２１、サーバ３１、Ｆｉｒｅｗａｌｌ２３のＬＡＮ側，Ｆｉｒｅｗａｌｌ３３のＬＡＮ側、ゲートウェイ装置２０、ゲートウェイ装置３０のＭＡＣアドレスを学習しているものとする。又、ＨＵＢ１１は、Ｆｉｒｅｗａｌｌ２３のＷＡＮ側、Ｆｉｒｅｗａｌｌ３３のＷＡＮ側、セッション中継装置１０の各装置のＭＡＣアドレスを学習しているものとする。又、Ｆｉｒｅｗａｌｌ２３およびＦｉｒｅｗａｌｌ３３は、イントラネット内部の装置（ＬＡＮ側）からインターネットの各装置（ＷＡＮ側）へＴＣＰを用いて通信開始の要求をした場合、通信開始の要求以降の通信は双方向で自由に行えるが、逆に、インターネットの各装置（ＷＡＮ側）からイントラネットの各装置（ＬＡＮ側）へＴＣＰを用いて通信開始の要求を行った場合、この要求は遮断され、以降の通信も双方向で遮断されるとする。
・・・（中略）・・・
［０２２２］
　ゲートウェイ装置２０内の高速化エンジン制御２００１は、ユーザからのセッション中継装置１０内の中継アプリケーション１００１への接続要求を受け、ＳＳＬ２００２にセッション中継装置１０内の中継アプリケーション１００１への通信開始を指示する。同時に、中間ドライバ２００６に対して、セッション中継装置１０内の中継アプリケーション１００１への通信開始を通知する。この通知には、セッション中継装置１０のＩＰアドレス、中継アプリケーション１００１のポート番号、及び高速化エンジン制御２００１の送信元ポート番号、更にゲートウェイ装置２０のＩＰアドレスが含まれる。
［０２２３］
　ＳＳＬ２００２は、高速化エンジン制御２００１からの通信開始指示を受け、ＳＳＬ１００２との間でＳＳＬセッションを確立する為に、ＴＣＰ２００３にセッション中継装置１０内の中継アプリケーション１００１への通信開始を指示する。
［０２２４］
　ＴＣＰ２００３は、ＳＳＬ２００２からの通信開始指示を受け、ＴＣＰ１００３との間でＴＣＰセッションを確立する為に、ＩＰルーティング２００４に対して、ＴＣＰ１００３とのＴＣＰセッション確立要求パケット（ＳＹＮ）を送信する。このパケットはＴＣＰ規格に沿ったものであり、宛先ＩＰアドレスにセッション中継装置１０宛、宛先ポート番号にＴＣＰ１００３が設定されている。・・・（後略）・・・
［０２２５］
　ＩＰルーティング２００４は、ＴＣＰ２００３から受信したパケットの宛先ＩＰアドレスと宛先ポート番号を参照し、パケットをＩＰスタック２００５に転送する。
［０２２６］
　ＩＰスタック２００５は、ＩＰルーティング２００４より受信したパケットに、Ｆｉｒｅｗａｌｌ２３内のイントラネット２側のＭＡＣアドレスを宛先ＭＡＣアドレスとして付加し、更に送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを設定してフレームを作成し、中間ドライバ２００６に転送する。
［０２２７］
　中間ドライバ２００６は、ＩＰスタック２００５からフレームを受信し、フレーム解析を行う。解析の結果、フレームは予め高速化エンジン制御２００１より通知された宛先ＩＰ、宛先ポート、送信元ＩＰ、送信元ポートが付加されたフレームであるので、カプセル化解除においてＭＡＣヘッダを取り外し、パケットにする。そして、中間ドライバ２００６のＴＣＰでＴＣＰ２００３からＴＣＰ１００３へのＴＣＰ処理を終端させる。すなわち、ＴＣＰ２００３は、元々は、ＴＣＰ１００３に対してＴＣＰセッション確立要求を送信したが、実際は、この要求に対して中間ドライバ２００６内のＴＣＰが受信して保留し、ＴＣＰ２００３と中間ドライバ２００６内のＴＣＰとの間で、ＴＣＰセッションの確立を終端する。
［０２２８］
　中間ドライバ２００６は、上記確立要求の処理を終端させる際、中間ドライバ１００８に対して、ＴＣＰ１００３との間でセッション（ＵＤＰ等の輻輳制御の無いセッション）の接続を要求する為に、ドライバ２００７に接続要求のパケットを送る。尚、この接続要求パケットはＴＣＰ規格に沿ったパケットではなく、本発明の通信システムにおける独自のパケットである。この接続要求パケットには宛先ＩＰアドレスとしてセッション中継装置１０を、宛先ポート番号としてＴＣＰ１００３を設定する。そしてこのパケットにＦｉｒｅｗａｌｌ２３内のイントラネット２側のＭＡＣアドレスを宛先ＭＡＣアドレスとして付加し、更に送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを設定して、接続要求フレームが生成する。
［０２２９］
　ドライバ２００７は中間ドライバ２００６から接続要求フレームを受信し、ＭＡＣ２０１１に転送する。
［０２３０］
　ＭＡＣ２０１１はドライバ２００７から接続要求フレームを受信し、高速化エンジン２０１４に転送する。
［０２３１］
　高速化エンジン２０１４は、ＭＡＣ２０１１から接続要求フレームを受信し、そのままＰＨＹ２０１２に転送する。
［０２３２］
　ＰＨＹ２０１２は、高速化エンジン２０１４から接続要求フレームを受信し、ポート２０１３に転送する。
［０２３３］
　ポート２０１３は、ＰＨＹ２０１２から接続要求フレームを受信し、イーサネットケーブルを経由してポート２２２に転送する。
［０２３４］
　ポート２２２は、ポート２０１３から接続要求フレームを受信し、ブリッジ２２４に転送する。
［０２３５］
　ブリッジ２２４は、ポート２２２からの接続要求フレームを受信すると、ＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがＦｉｒｅｗａｌｌ２３のＬＡＮ側のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままＦｉｒｅｗａｌｌ２３側のポート（ポート２２３）に出力する。
［０２３６］
　ポート２２３は、ブリッジ２２４から接続要求フレームを受信し、イーサネットケーブルを経由してＦｉｒｅｗａｌｌ２３内のポート２３１３に転送する。
［０２３７］
　Ｆｉｒｅｗａｌｌ２３は、ＨＵＢ２２内のポート２２３から接続要求フレームを受信し、ポート２３１３、ＰＨＹ２３１２、ＭＡＣ２３１１、ドライバ２３０４、ＩＰスタック２３０２、ＩＰルーティング２３０１、ＩＰスタック２３０４、ドライバ２３０５、ＭＡＣ２３２１、ＰＨＹ２３２２、ポート２３２３の経路でフレームを転送し、ＨＵＢ１１内のポート１１に転送する。
［０２３８］
　ＨＵＢ１１内のポート１１１は、ポート２３２３から接続要求フレームを受信し、ブリッジ１１４に転送する。
［０２３９］
　ブリッジ１１４は、ポート１１１からの接続要求フレームを受信すると、ＭＡＣ  ＤＡを参照し、ＭＡＣ  ＤＡがセッション中継装置１０側のものであることから、過去のルーティング学習結果に基づき、このフレームをそのままセッション中継装置１０側のポート（ポート１１２）に出力する。
［０２４０］
　ポート１１２は、ブリッジ１１４から接続要求フレームを受信し、イーサネットケーブルを経由してセッション中継装置１０内のポート１０１３に転送する。
［０２４１］
　セッション中継装置１０は、ＨＵＢ２２内のポート１１２から接続要求フレームを受信し、ポート１０１３、ＰＨＹ１０１２、ＭＡＣ１０１１、ドライバ１００９の経路でフレームを転送し、中間ドライバ１００８に転送する。
［０２４２］
　中間ドライバ１００８は、ドライバ１００９から接続要求フレームを受信し、フレームの解析を行う。
解析の結果、このフレームは予め中継アプリケーション１００１より通知された、中継アプリケーション１００１への宛先ＩＰ、及び宛先ポートが付加されたフレームであるので、このフレームを受信し、カプセル化解除においてＭＡＣヘッダを取り外し、パケットにする。このパケットは、中間ドライバ２００６から中間ドライバ１００８に向けて送信された、ＴＣＰ１００３への接続要求パケットである為、中間ドライバ１００８内のＴＣＰは、ＴＣＰ１００３との間でＴＣＰセッションを確立する為に、ＴＣＰ１００３とのセッション確立に必要なパケットを送信する。このパケットはＴＣＰ規格に沿ったものであり、宛先ＩＰアドレスにセッション中継装置１０宛、宛先ポート番号にＴＣＰ１００３が設定され、更に送信元ＩＰアドレスにはゲートウェイ装置２０のＩＰアドレスが設定され、送信元ポート番号にはＴＣＰ２００３のポート番号が設定される。そしてこのパケットには、中間ドライバ１００８内の再カプセル化１００８ＥによってＭＡＣアドレスが付加され、フレームの形にしてＩＰスタック１００７に転送される。・・・（後略）・・・
［０２４３］・・・（中略）・・・
［０２４４］
　ＩＰスタック１００７は、中間ドライバからフレームを受信し、ＭＡＣヘッダを外してパケットにしてＩＰルーティング１００６に転送する。
［０２４５］
　ＩＰルーティング１００６は、ＩＰスタック１００７より受信したパケットの宛先ポート番号を参照し、ＴＣＰ１００３側のポート番号が付加されていることから、このパケットをＴＣＰ１００３に転送する。
［０２４６］
　ＴＣＰ１００３は、ＩＰルーティング１００６よりパケットを受信する。このパケットはＴＣＰセッション確立要求パケット（ＳＹＮ）であるので、ＴＣＰプロトコルに従い、セッションの確立要求に対して応答パケット（ＳＹＮ＋ＡＣＫ）を返送する。・・・（後略）・・・
［０２４７］
　従って、ＴＣＰ１００３は、応答パケット（ＳＹＮ＋ＡＣＫ）を、ＴＣＰ２００３宛てに送信する。すなわち、応答パケットの宛先ＩＰはゲートウェイ装置２０のＩＰアドレスが設定され、応答パケットの宛先ポートは、ＴＣＰ２００３のポート番号が設定される。
［０２４８］
　応答パケットは、ＩＰルーティング１００６を経由して、ＩＰスタック１００７に送られ、ここでＭＡＣヘッダを付加されて応答フレームとなり、中間ドライバ１００８に届く。
［０２４９］
　中間ドライバ１００８は、応答フレームを受信すると、中間ドライバ１００８内のカプセル化解除において応答フレームのＭＡＣヘッダを外して応答パケットを取り出し、ＴＣＰでこの応答パケット（ＳＹＮ＋ＡＣＫ）を受信してＡＣＫパケットを返答してＴＣＰ処理を終端する。そして中間ドライバ２００６に対して、セッション（ＵＤＰ等の輻輳制御の無いセッション）の接続完了通知の為の接続完了通知パケットを送信する。この接続完了通知パケットは、ＴＣＰ規格に沿ったパケットではなく、本発明の通信システムにおける独自のパケットであり、宛先ＩＰアドレスとしてゲートウェイ送装置２０を、宛先ポート番号としてＴＣＰ２００３を、送信元ＩＰアドレスとしてセッション中継装置１０を、送信元ポート番号としてＴＣＰ１００３を設定する。そして中間ドライバ１００８内の再カプセル化１００８Ｄにおいて、接続完了通知パケットにＭＡＣヘッダを付加し、接続完了通知フレームを生成する。
［０２５０］
　接続完了通知フレームは、接続要求とは逆の経路、即ち、ドライバ１００９，ＮＩＣ１０１，ＨＵＢ１１，ＮＩＣ２３２、ＣＰＵ２３０，ＮＩＣ２３１、ＨＵＢ２２，ＮＩＣ２０１を経由して、ＣＰＵ２００内の中間ドライバ２００６に届く。
［０２５１］
　中間ドライバ２００６は、接続完了通知フレームを受信し、フレーム解析を行う。解析の結果、受信したフレームは予め高速化エンジン制御２００１より通知された、高速化エンジン制御２００１への宛先ＩＰ、及び宛先ポートが付加されたフレームであるので、このパケットを受信し、カプセル化解除においてＭＡＣヘッダを取り外し、パケットにする。パケットは、中間ドライバ１００８から中間ドライバ２００６に向けて送信された、ＴＣＰ１００３と中間ドライバ１００８との間の接続完了通知パケットである為、中間ドライバ２００６内のＴＣＰは、ＴＣＰプロトコルに従い、セッション確立の為に必要な応答パケット（ＳＹＮ＋ＡＣＫ）をＴＣＰ２００３に送る為、ＩＰスタック２００５に対して、応答パケットを送信する。
［０２５２］
　応答パケットは、ＩＰスタック２００５、ＩＰルーティング２００４を経由し、ＴＣＰ２００３に到達する。
［０２５３］
　ＴＣＰ２００３は、ＩＰルーティング２００４より応答パケット（ＳＹＮ＋ＡＣＫ）を受信する。このパケットはＴＣＰセッションの確立要求に対する応答パケットであるので、ＳＳＬ２００２に対して、ＴＣＰ１００３とのＴＣＰセッション接続完了を通知する。・・・（後略）・・・
［０２５４］
　ＴＣＰ２００３は応答パケット（ＳＹＮ＋ＡＣＫ）を受信すると、この応答パケットに対してＡＣＫパケットを生成してＴＣＰ１００３宛に送信する。このＡＣＫパケットは、中間ドライバ２００６のＴＣＰがＩＰルーティング２００４及びＩＰスタック２００５を介して受信し、ＴＣＰ処理を終端させる。」（４２〜４８頁）
　
リ．「［０２５５］
　ＳＳＬ２００２は、ＴＣＰ２００３からの接続完了通知を受け、ＳＳＬ１００２との間でＳＳＬセッションを確立する為、ＳＳＬプロトコルに従い、ＳＳＬセッションの確立要求の為のパケット（ＳＳＬセッション確立要求パケット）を送信する。
［０２５６］
　ＳＳＬセッション確立要求パケットは、ＴＣＰ２００３で受信されると、ＴＣＰ２００３と中間ドライバ２００６内のＴＣＰとの間で設定されたＴＣＰセッションを通り、中間ドライバ２００６に到着する。
［０２５７］
　中間ドライバ２００６は、ＳＳＬセッション確立要求パケットのＴＣＰを終端し、ＵＤＰ等の輻輳制御の掛からないヘッダを付け、パケットを中間ドライバ１００８に向け送信する。パケットはＮＩＣ２０１、ＨＵＢ２２，ＮＩＣ２３１，ＣＰＵ２３０，ＮＩＣ２３２、ＨＵＢ１１、ＮＩＣ１０１を経由して、中間ドライバ１００８に到着する。この際、ＮＩＣ２０１内の高速化エンジン２０１４は、ＭＡＣ１０１１から受信したパケットを、そのままＰＨＹ２０１２に転送する。
［０２５８］
　中間ドライバ１００８は、ＳＳＬセッション確立要求パケットを受信すると、中間ドライバ１００８内のＴＣＰとＴＣＰ１００３との間で設定されたＴＣＰセッションを通り、ＴＣＰ１００３に到着する。
［０２５９］
　ＴＣＰ１００３は、パケットをＳＳＬ１００２に転送する。
［０２６０］
　ＳＳＬ１００２は、ＳＳＬセッション確立要求の内容を検証し、問題が無ければ、中継アプリケーション１００１に対して、ＳＳＬ２００２とのセッション確立を通知すると同時に、ＳＳＬプロトコルに従い、ＳＳＬ２００２に対してＳＳＬセッション確立応答パケットを送信する。
［０２６１］
　ＳＳＬセッション確立応答パケットは、ＳＳＬセッション確立要求パケットとは逆の経路、即ち、ＴＣＰ１００３と中間ドライバ１００８との間のＴＣＰセッションを経由して中間ドライバ１００８に到達し、中間ドライバ１００８と中間ドライバ２００６の間のＵＤＰ等の輻輳制御のないセッションを経由して中間ドライバ２００６に到達する。更に、中間ドライバ２００６とＴＣＰ２００３との間のＴＣＰセッションを経由して、ＳＳＬ２００２に到達する。
［０２６２］
　ＳＳＬ２００２は、ＳＳＬセッション確立要求の内容をＳＳＬプロトコルに従って検証し、問題が無ければ、高速化エンジン制御２００１に対して、ＳＳＬ２００２とＳＳＬ１００２との間のＳＳＬセッション確立を通知する。
・・・（中略）・・・
［０２７１］
　以上により、第１の実施の形態において、ゲートウェイ装置２０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）を確立する場合の動作が完了する。」（４８〜５１頁）
　
ヌ．「［０２７２］
　尚、上述した実施例では、ゲートウェイ装置２０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）を確立する場合を例に挙げて、動作の説明をしたが、ゲートウェイ装置３０からセッション中継装置１０へのＳＳＬセッション（セキュアＴＣＰセッション）を確立する動作は、同様の動作が行われる。
・・・（後略）・・・」（５１頁）
　
　上記引用例の記載及び図面並びにこの分野の技術常識を考慮すると、
ａ．上記イ．〜ト．の記載及び図１、３３から、引用例には、「ＨＵＢ２２」に接続される「ゲートウェイ装置２０」、「端末２１」、「Ｆｉｒｅｗａｌｌ２３」を備えた「イントラネット２」と、「ＨＵＢ１１」に接続される「セッション中継装置１０」を備えた「インターネット１」と、「ＨＵＢ３２」に接続される「ゲートウェイ装置３０」、「サーバ３１」、「Ｆｉｒｅｗａｌｌ３３」を備えた「イントラネット３」とを接続する方法が記載されていると認められる。
ｂ．上記チ．リ．の記載及び図１６から、引用例の方法では、「ゲートウェイ装置２０」から、「セッション中継装置１０」に対して「ＳＳＬセッション（セキュアＴＣＰセッション）」を確立するものと認められる。
　そして、同チ．［０２３３］〜［０２４１］の記載から、引用例の方法では、「ＳＳＬセッション（セキュアＴＣＰセッション）」が、「Ｆｉｒｅｗａｌｌ２３」を介して確立されることは明らかである。
　また、引用例の「ゲートウェイ装置２０」が「Ｆｉｒｅｗａｌｌ２３」の背後にあることは自明である。
ｃ．上記ヌ．の記載から、引用例の方法では、「ゲートウェイ装置２０」から、「セッション中継装置１０」に対して「ＳＳＬセッション（セキュアＴＣＰセッション）」を確立するのと同様に、「ゲートウェイ装置３０」から「セッション中継装置１０」に対して「ＳＳＬセッション（セキュアＴＣＰセッション）」を確立するものと認められる。
　
　以上を総合すると、上記引用例には、以下の発明（以下、「引用発明」という。）が記載されていると認められる。
　
「イントラネット２にあるＨＵＢ２２に接続されるゲートウェイ装置２０から、Ｆｉｒｅｗａｌｌ２３を介して、インターネット１にあるＨＵＢ１１に接続されるセッション中継装置１０までＳＳＬセッション（セキュアＴＣＰセッション）を確立し、
　イントラネット３にあるＨＵＢ３２に接続されるゲートウェイ装置３０から、Ｆｉｒｅｗａｌｌ３３を介して、インターネット１にあるＨＵＢ１１に接続されるセッション中継装置１０までＳＳＬセッション（セキュアＴＣＰセッション）を確立し、
　前記ＨＵＢ２２に接続されるゲートウェイ装置２０から前記ＨＵＢ１１に接続されるセッション中継装置１０までのＳＳＬセッション（セキュアＴＣＰセッション）は、前記Ｆｉｒｅｗａｌｌ２３の背後にある前記ＨＵＢ２２に接続されるゲートウェイ装置２０により、イントラネット２の内側から前記ＨＵＢ１１に接続されるセッション中継装置１０まで、確立され、
　前記ＨＵＢ３２に接続されるゲートウェイ装置３０から前記ＨＵＢ１１に接続されるセッション中継装置１０までＳＳＬセッション（セキュアＴＣＰセッション）は、前記Ｆｉｒｅｗａｌｌ３３の背後にある前記ＨＵＢ３２に接続されるゲートウェイ装置３０により、イントラネット３の内側から前記ＨＵＢ１１に接続されるセッション中継装置１０まで、確立される
方法。」
　
［対比・判断］
　補正後の発明と引用発明とを対比すると、
イ．引用発明の「イントラネット２」、「イントラネット３」と補正後の発明の「第１企業ドメイン（１１０−１）」、「第２企業ドメイン（１１０−２）」は、いずれもファイアウォールによってインターネットからのアクセスを阻止するよう構築されたイントラネットといえ、それぞれ「第１イントラネット」、「第２イントラネット」という点で一致する。
ロ．引用発明の「インターネット１」、「Ｆｉｒｅｗａｌｌ２３」、「Ｆｉｒｅｗａｌｌ３３」は、補正後の発明の「パブリック・ドメイン（１０１）」、「第１ファイアーウォール」、「第２ファイアーウォール」に、それぞれ相当する。
ハ．引用発明の「ＨＵＢ２２に接続されるゲートウェイ装置２０」、「ＨＵＢ３２に接続されるゲートウェイ装置３０」と補正後の発明の「第１トンネル・ゲートウェイ（１２３−１）」、「第２トンネル・ゲートウェイ（１２３−２）」は、いずれも所定の通信接続を実行し、他のネットワーク宛のデータを中継する「第１ゲートウェイ」、「第２ゲートウェイ」という点で一致する。
ニ．引用発明の「ＨＵＢ１１に接続されるセッション中継装置１０」と補正後の発明の「トンネルハブ（１１２）」は、所定の通信接続を実行し、他のネットワーク宛のデータを中継する「ハブ装置」という点で一致する。
ホ．引用発明の「ＳＳＬセッション（セキュアＴＣＰセッション）」と補正後の発明の「トンネル」は、いずれも他のネットワーク宛のデータを伝送するために設定される「通信接続」という点で一致する。
　すると、引用発明の「前記ＨＵＢ２２に接続されるゲートウェイ装置２０から前記ＨＵＢ１１に接続されるセッション中継装置１０までのＳＳＬセッション（セキュアＴＣＰセッション）」及び「前記ＨＵＢ３２に接続されるゲートウェイ装置３０から前記ＨＵＢ１１に接続されるセッション中継装置１０までＳＳＬセッション（セキュアＴＣＰセッション）」と、補正後の発明の「第１トンネル（１３１−１）」及び「第２トンネル（１３１−２）」とは、それぞれ「第１通信接続」及び「第２通信接続」という点で一致する。
ヘ．引用発明の「Ｆｉｒｅｗａｌｌ２３（３３）の背後にある前記ＨＵＢ２２（３２）に接続されるゲートウェイ装置２０（３０）」と補正後の発明の「第１（２）ファイアウォール（１１１−１）（（１１１−２））の背後からの前記第１（２）トンネル・ゲートウェイ（１２３−１）（（１２３−２））により」において、引用発明の「背後にある」と補正後の発明の「背後からの」という表現の差異による構成上の相違は認められない。
ト．引用発明の「方法」と補正後の発明の「トンネルを確立する方法」とは、いずれも「通信接続を確立する方法」といえる。
　したがって、補正後の発明と引用発明は、以下の点で一致ないし相違する。
　
　＜一致点＞
「　（Ａ）第１イントラネットにある第１ゲートウェイから、第１ファイアウォールを介して、パブリック・ドメインにあるハブ装置まで第１通信接続を確立するステップと、
　　（Ｂ）第２イントラネットにある第２ゲートウェイから、第２ファイアウォールを介して、前記ハブ装置まで第２通信接続を確立するステップと
を有し、
　　　　　前記第１通信接続は、前記第１ファイアウォールの背後からの前記第１ゲートウェイにより、前記第１イントラネットの内側から前記ハブ装置まで、確立され、
　　　　　前記第２通信接続は、前記第２ファイアウォールの背後からの前記第２ゲートウェイにより、前記第２イントラネットの内側から前記ハブ装置まで、確立される
ことを特徴とする通信接続を確立する方法。」
　
　＜相違点＞　
ａ．上記「イントラネット」に関し、補正後の発明は、「企業ドメイン」と称するのに対して、引用発明は、「企業ドメイン」についての言及はない点。
ｂ．上記「通信接続」に関し、補正後の発明は、「トンネル」であるのに対し、引用発明は、「ＳＳＬセッション（セキュアＴＣＰセッション）」である点。
ｃ．上記「ゲートウェイ」、「ハブ装置」に関し、前記ｂ．に関連して、補正後の発明は、「トンネル・ゲートウェイ」、「トンネル・ハブ」と称するのに対し、引用発明は、「トンネル」についての言及はない点。
　
　まず、上記相違点ａ．について検討する。
　会社や組織において、セキュリティを考慮して、通信ネットワークをイントラネットとして構築することは周知であり、引用発明の「イントラネット２（３）」を企業ドメインとすることは、当業者が適宜なし得ることである。
　次に、上記相違点ｂ．及びｃ．について検討する。
　発明の要旨の認定、すなわち特許請求の範囲に記載された技術的事項の確定は、まず特許請求の範囲の記載に基づくべきであり、その記載が一義的に明確であり、その記載により発明の内容を的確に理解できる場合には、発明の詳細説明に記載された事項を加えて発明の要旨を認定することは許されず、特許請求の範囲の記載の文言自体から直ちにその技術的意味を確定するのに十分といえないときにはじめて発明の詳細な説明中の記載を参酌できるに過ぎないと解される。
　そして、補正後の発明を特定する、本件補正により補正された特許請求の範囲の請求項１に記載の「トンネル」なる用語の技術的な意味内容は、本願出願時の技術常識を参酌しても、一義的に明確であるとはいえず、その記載から発明の内容を的確に理解できるということはできない。
　そこで、特許請求の範囲の請求項１に記載の「トンネル」なる用語について、本願明細書の発明の詳細な説明の記載を参酌すると、当該「トンネル」に関し、明細書［００２１］には「トンネル（例えば、永続的なＴＣＰ接続、保護されたＴＣＰ接続等）」との記載、及び「トンネルの確立が成功すると、・・・企業ドメインを超えて、ウェッブサービスにアクセスできる。更に、サーバ１２２−ｊは、クライアント１２１−ｉ上のアプリケーションと、トンネル・ゲートウェイ１２３−ｊとトンネル・ゲートウェイ１２３−ｉを介して通信を確立できる。・・・双方向ウェブサービス通信は、クライアントとサーバが異なる企業ドメインに属する場合でも、達成できる。」との記載があり、さらに、同［０００９］には「全てのトンネルは、企業のファイアウォールの背後から構築されているために、双方向ウェブサービスは、企業のネットワーク−アドレス−変換・ファイアウォールの構築をほとんど変更せずに、ファイアウォールを乗り越えることができる。」との記載がある。
　そうすると、補正後の発明の「トンネル」なる用語の技術的な意味内容は、特許請求の範囲の請求項１の記載からは、一義的に明確でないものの、本願明細書の発明の詳細な説明の記載を参酌すれば、永続的なＴＣＰ接続、保護されたＴＣＰ接続等であって、ファイアウォールを変更せずに、ファイアウォールを乗り越えて、異なるネットワーク間の通信を可能にするものと解することができる。
　他方、引用発明の「ＳＳＬセッション（セキュアＴＣＰセッション）」は、保護されたＴＣＰ接続といえることは明らかであって、上記［引用発明］のイ．〜ヌ．の記載を参酌すると、ファイアウォールを変更せずに、ファイアウォールを乗り越えて、異なるネットワーク間の通信を可能するものである点において、補正後の発明の「トンネル」との間に差異はない。
　さらに、引用発明の「ＳＳＬセッション（セキュアＴＣＰセッション）」を特定の目的の通信に必要な時間だけ維持することは一般的なことであるから、目的に応じて、当該「ＳＳＬセッション（セキュアＴＣＰセッション）」を維持する時間を変えたり、永続的な接続とすることは、適宜なし得ることである。
　よって、引用発明の「ＳＳＬセッション（セキュアＴＣＰセッション）」を補正後の発明の「トンネル」とすることは、当業者が容易になし得ることであり、その際、引用発明の「ＨＵＢ２２（３２）に接続されるゲートウェイ装置２０（３０）」、「ＨＵＢ１１に接続されるセッション中継装置１０」を「第１（第２）トンネル・ゲートウェイ」、「トンネル・ハブ」と称することは、適宜なし得ることである。
　そして、補正後の発明の作用効果も、引用発明から想到し得る構成から当業者が予測できる範囲のものである。
　
　したがって、補正後の発明は上記引用発明に基づいて当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
３．結語
　以上のとおり、本件補正は、特許法第１７条の２第５項（補正の目的）の各号のいずれにも該当せず、また、本件補正が、仮に、特許請求の範囲の減縮を目的とするものであるとしてしても、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、同法第１７条の２第６項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２５年　６月２７日付けの手続補正は上記のとおり却下されたので、本願発明は、「第２．１．本願発明と補正後の発明」の項で、「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は、上記「第２．２．（２）独立特許要件」の項中の［引用発明］の項で、引用発明として認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、上記「第２．２．（１）補正の目的要件」に記載したとおり、本願発明と補正後の発明との間に実質的な差異はない。
　そうすると、補正後の発明が、上記「第２．２．（２）独立特許要件」の項で検討したとおり、上記引用例に基づいて容易に発明できたものであるから、本願発明も同様の理由により、当業者が容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、上記引用例に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。