【事件の表示】
　特願２００６−２６０８３０「ＩＰアプリケーションサービス提供システム」拒絶査定不服審判事件〔平成２０年　４月１０日出願公開、特開２００８−　８５４７０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本件出願は、平成１８年９月２６日の出願であって、平成２２年９月１７日付け拒絶理由通知に対して同年１１月１０日付けで意見書と手続補正書が提出されたが、平成２３年２月７日付けで拒絶査定がなされ、これに対し、同年５月１２日に拒絶査定不服の審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成２３年５月１２日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　平成２３年５月１２日付けの手続補正は、補正前の平成２２年１１月１０日付け手続補正書の特許請求の範囲の請求項１に記載された
「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供システムであって；
　前記ゲートウェイ装置配下の前記内部ノードが、
　前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
　維持されている制御チャネルを通して、前記接続支援装置から前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と；
　前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくＩＰアプリケーションのデータチャネルをアクティブにオープンする手段とを備え；
　前記制御パケットを定期送信する処理及び前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は非同期で遂行され、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は実行される
ＩＰアプリケーションサービス提供システム。」
　という発明（以下、「本願発明」という。）を、補正後の特許請求の範囲の請求項１に記載された
「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするＩＰアプリケーションサービス提供システムであって；
　前記ゲートウェイ装置配下の前記内部ノードが、
　前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
　維持されている制御チャネルを通して、前記接続支援装置から前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と；
　前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくＩＰアプリケーションのデータチャネルをアクティブにオープンする手段とを備え；
　前記制御パケットを定期送信する処理及び前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は非同期で遂行され、前記非同期は、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることであるＩＰアプリケーションサービス提供システム。」
　という発明（以下、「補正後の発明」という。）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」が「前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されること」を付加することにより、該「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」を限定し、特許請求の範囲を減縮するものであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項(新規事項)及び特許法第１７条の２第４項第２号(補正の目的)の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
（２）引用発明
　原査定の拒絶理由に引用された特開２００４−１２０５４７号公報（以下、「引用例」という。）には、「インターネットに接続するサーバ、機器および通信システム」に関し、図面とともに以下の事項が記載されている。
　
ア．「【００４４】
（実施の形態１）
図１は本発明の実施の形態１の通信システムの通信シーケンスを説明した図である。図２は本発明の通信システムのネットワーク接続図である。本発明の通信システムはローカルエリアネットワーク（ＬＡＮ）１０６上の機器とインターネット１０５上の機器間の通信を実現するものであり、ＬＡＮ１０６に接続された機器１０１と、インターネット１０５上に接続されたサーバ１０４と、ＬＡＮ１０６とインターネットを接続するルータ１０３とを含む。インターネット１０５には通信端末１０２も接続されている。
【００４５】
ルータ１０３はＮＡＰＴ機能を実装している。機器１０１のＩＰアドレスはプライベートＩＰアドレス”１９２．１６８．１．２”であり、サーバ１０４のＩＰアドレスはグローバルＩＰアドレス”４．１７．１６８．６”であるとする。ルータ１０３のインターネット１０５側アドレスは一般にインターネットサービスプロバイダーからＤＨＣＰやＰＰＰ等のプロトコルにより割り当てられ、動的に変化するが、この時点でルータ１０３のインターネット側アドレスはグローバルＩＰアドレス”２０２．２２４．１５９．１４２”であるとする。説明の便宜上、ルータ１０３のインターネット１０５側アドレスは１つしかないとする。なお、本実施の形態において、ＩＰアドレスはＩＰｖｅｒ４に準拠している。
【００４６】
図１を参照し、本実施形態の通信シーケンスを説明する。
機器１０１はまず、サーバ１０４に対し最大アクセス確認周期情報要求１０７を送信する。サーバはこの応答として、最大アクセス確認周期情報通知１０８を送信する。これらの通信１０７、１０８はＵＤＰによってもＴＣＰによっても良く、ＬＡＮ１０６側に接続された機器１０１から開始されるため、ＮＡＰＴ機能を備えたルータ１０３を越えて支障なく通信できる。ここで、最大アクセス確認周期とは、機器１０１からサーバ１０４へ送信される通知ＵＤＰパケット（後述）の送信時間間隔の最大値を示すものであり、例えば「５分」というような値となる。
【００４７】
次に、機器１０１は周期的に通知ＵＤＰパケット１０９を送信する。この周期は先に取得した最大アクセス確認周期の値（例えば５分）より小さい間隔で送られる。通知ＵＤＰパケット１０９は機器１０１に固有に付与された機器識別子である「機器ＩＤ」を含む。通知ＵＤＰパケット１０９はルータ１０３により、往路のＮＡＰＴ変換が行なわれた後インターネット１０５に送出され、サーバ１０４にて受信される。
【００４８】
図３の（ａ）、（ｂ）に各々変換される前後の通知ＵＤＰパケットの内容を示す。通知ＵＤＰパケットの送信周期は、ルータ１０３がＵＤＰパケットのＮＡＰＴテーブルをタイムアウトにより破棄する時間よりも短く設定する。これによりルータ１０３には、図９（ｂ）に示したようなＮＡＰＴテーブルがタイムアウトせず継続的に保持される。
【００４９】
図１に戻り、サーバ１０４は、通知ＵＤＰパケット１０９を受信すると、ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを取り出し、図４に示すように、これらの情報を機器１０１（機器ＩＤ＝”１２３４”）に対応する１組のエントリとしてサーバ内に登録保存する（ステップＳ１１９）。また、ステップＳ１１９では、最終アクセス時刻をエントリに付加し、サーバ１０４が通知ＵＤＰパケット１０９を受信した時刻を記録する。以後、サーバ１０４は、通知ＵＤＰパケット１０９を受信するたびにステップＳ１２０に示すように機器に対応するエントリの最終アクセス時刻を更新する。また、この際、通知ＵＤＰパケット１０９のヘッダ内のＳＡ、ＳＰの各アドレスが変更されていた場合は、エントリ中のそれらのアドレスの値も更新する。これにより、ルータ１０３のインターネット（ＷＡＮ）１０５側ＩＰアドレスが動的に割り振られていても、最新のアドレスがエントリに保持される。以上のシーケンスの実行により、通信の準備が完了する。
【００５０】
以上の通信準備が完了している状況で、端末１０２から機器１０１に対する通信を開始したい場合、端末１０２は機器１０１の機器ＩＤをパラメータに指定して、サーバ１０４に対し機器接続要求１１０を送信する。なお、機器ＩＤは端末１０２が予め認識しているものとする。機器接続要求１１０を受信したサーバ１０４は、端末１０２により指定された機器ＩＤを検索キーとして図４に示すテーブルからサーバ内に登録された機器ＩＤを検索し、機器１０１が登録した対応エントリを得る（ステップＳ１２１）。
【００５１】
次に、サーバ１０４はエントリ内の最終アクセス時刻を確認し、現在時刻との差が最大アクセス確認周期を超えている場合は機器接続要求１１０を拒否し、最大アクセス確認周期以下の場合は、ステップＳ１２２以後に進んで機器１０１に接続要求ＵＤＰパケット１１１を送信する。
【００５２】
このように最終アクセス時刻を確認することで、機器１０１が正常に動作し、かつ、ごく最近まで正常に通信できていたか否かが直ちに確認できるため、機器接続要求１１０の受諾可否判定が高速にできる。また、ルータ１０３のインターネット（ＷＡＮ）１０５側ＩＰアドレスはＩＳＰによって動的に割り当てられているため、機器１０１の電源遮断後ある程度時間が経過すると、サーバ１０４に登録された機器１０１のＩＰアドレスが別の機器に割り当てられてしまう場合があるが、この場合でも誤って関係の無い別の機器に接続要求を行うことを防止できる。
【００５３】
次に、サーバ１０４は、一意なセッション識別子を生成してサーバ内に保存する（ステップＳ１２２）。さらに、サーバ１０４は機器１０１に対応するエントリからＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスを取得し、これらを用いてセッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１を送信する。ここで、接続要求ＵＤＰパケット１１１は通知ＵＤＰパケット１０９に対する応答として構成されている。図３（ｃ）にインターネット（ＷＡＮ）１０５上に送出された接続要求ＵＤＰパケットの内容を示す。図３（ｃ）に示すパケットのアドレスとポートの値は、それぞれ図３（ｂ）に示すパケットにおいてアドレスとポートのソースとディスティネーションの値を入れ替えた値となっている。これにより、接続要求ＵＤＰパケット１１１は通知ＵＤＰパケット１０９の応答パケットであることが分かる。接続要求ＵＤＰパケット１１１は、ルータ１０３において復路のＮＡＰＴ変換により図３（ｃ）に示す構成から図３（ｄ）に示す構成に変換され、機器１０１に転送される。
【００５４】
接続要求ＵＤＰパケット１１１を受信した機器１０１は、サーバ１０４に対してＴＣＰ接続要求１１２を送信する。ＴＣＰ接続要求１１２についての詳細な説明は省略するが、ｓｙｎ，ａｃｋ／ｓｙｎ，ａｃｋパケットによって接続を確立する通常のＴＣＰ接続確立手順である。ＴＣＰ接続要求１１２はＬＡＮ側からＷＡＮ側に対して行なわれるものであるため、ＮＡＰＴ機能を備えたルータ１０３を越えて支障なくＴＣＰ接続を確立することができる。
【００５５】
以上によりサーバ１０４と機器１０１の間でＴＣＰ接続が確立されたが、ＵＤＰパケットはコネクションレス型であるため、そのままではサーバ１０４において、ＴＣＰ接続が接続要求ＵＤＰパケット１１１に応えて確立されたか否かの判定ができない。そのために以下で説明する手順が実行される。
【００５６】
まず、機器１０１はそのＴＣＰ接続上で、接続要求ＵＤＰパケット１０９により通知されたセッション識別子を、セッション識別子通知１１３によってサーバへ返送する。サーバ１０４はセッション識別子を受信すると、ステップＳ１２３においてセッション識別子の照合を行う。照合の結果、このセッション識別子が機器接続要求１１０により生成されたものであることを検出すると、サーバ１０４はこのＴＣＰ接続を、接続要求１１０に答えて端末１０２と機器１０１間の通信の転送に使用することを決定する。
【００５７】
なお、セッション識別子に代えて機器ＩＤを用いてもＴＣＰ接続と接続要求ＵＤＰパケットを対応付けることはできるが、その場合はサーバ１０４と機器１０１の間には同時に複数のＴＣＰ接続を確立することができないという問題が生じる。本実施の形態によれば、サーバ１０４と機器１０１の間に複数のＴＣＰ接続を確立することができ、その際の個々のＴＣＰ接続上の通信内容を別々のセッション識別子で管理することで、複数の通信の内容を無秩序に混合してしまうことなく、別々のＴＣＰ接続上で各々一貫性を保持した通信の転送を行ない、端末１０２から機器１０１に対しセッション識別子毎に並列して複数の通信を行うことが可能となる。
【００５８】
以上述べた手順により、サーバ１０４と機器１０１の間でＴＣＰ接続が確立されると、サーバ１０４はそのＴＣＰ接続上で端末１０２と機器１０１間の通信の転送を開始する。すなわち、サーバ１０４は端末１０２からの通信１１４を通信１１５として機器１０１に転送し、機器１０１からの通信１１６を端末１０２に通信１１７として転送する。最後に、通信が完了すると、サーバ１０４または機器１０１からＴＣＰ切断１１８を行い、通常のＴＣＰ接続の切断を行なって一連のシーケンスが完了する。」（１４〜１６頁）
　
イ．「【００７２】
なお、本実施の形態では機器１０１からの接続先はサーバ１０４のみであり、サーバ１０４が端末１０２と機器１０１間の通信を転送したが、接続要求ＵＤＰパケット１０９により端末１０２のアドレスを通知すれば、機器１０１が端末１０２に対し直接ＴＣＰ接続要求１１０を送信する構成も可能である。この構成によれば、端末１０２と機器１０１が直接通信を行なうことが可能になり、サーバ１０４の転送負荷が低減されるなど別の効果がある。」（１７〜１８頁）
　
ウ．「【００７５】
（実施の形態２）
本発明に係る通信システムの別の実施形態を説明する。
本実施形態のネットワーク接続は図２で示したとおりである。アドレス付与も第１の実施の形態と同じであり、通信シーケンスのみが異なっている。本実施の形態では端末としてＷｅｂブラウザを備えたＰＣや携帯電話を用いており、これを用いてＬＡＮに接続された機器１０１とＨＴＴＰによる通信を行なって操作やコンテンツ取得などを行なうものである。
　
　・・・（中略）・・・
　
【００８６】
その後、サーバ１０４はＨＴＴＰリクエスト４１１に対する応答としてＨＴＴＰレスポンス４１５を端末１０２に送信する。このＨＴＴＰレスポンス４１５は、端末１０２に表示すべきＨＴＭＬコンテンツを含んでおり、かつ、このＨＴＭＬコンテンツにはセッション識別子”５６７８”が、例えば「＜Ａ　ＨＲＥＦ＝”ｃｏｎｔｒｏｌ．ｃｇｉ？ＳｅｓｓｉｏｎＩＤ＝５６７８＆Ｔａｒｇｅｔ＝ｄｅｖｉｃｅＦｕｎｃ．ｃｇｉ＆Ｐａｒａｍ＝ａｂｃｄ”＞リンク＜／Ａ＞」のようにリンクやボタンとして埋め込まれている。以上の手順により、端末１０２には機器１０１に対応するページ（画像）が表示される。
【００８７】
次に、ユーザが表示されたページ内のリンクをクリックすると、”ＧＥＴ　ｃｏｎｔｒｏｌ．ｃｇｉ？ＳｅｓｓｉｏｎＩＤ＝５６７８＆Ｔａｒｇｅｔ＝ｄｅｖｉｃｅＦｕｎｃ．ｃｇｉ＆Ｐａｒａｍ＝ａｂｃｄ”等のようにセッション識別子を含むＨＴＴＰリクエスト４１６が生成されてサーバ１０４に送信される。サーバ１０４はＨＴＴＰリクエスト４１６を受信すると、指定されたｃｏｎｔｒｏｌ．ｃｇｉが起動し、セッション識別子”５６７８”を照合する（ステップＳ４２６）。照合した結果、セッション識別子”５６７８”のＴＣＰ接続が既に確立済みであることを検出すると、サーバ１０４のｃｏｎｔｒｏｌ．ｃｇｉは、ＨＴＴＰリクエスト４１６の内容を”ＧＥＴ　ｄｅｖｉｃｅＦｕｎｃ．ｃｇｉ？Ｐａｒａｍ＝ａｂｃｄ”のように変換してＨＴＴＰリクエスト転送４１７としてそのＴＣＰ接続上に転送する。このようにして、端末１０２は、機器１０１に対するＨＴＴＰリクエストを送信できる。」（１８〜２０頁）
　
　上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、
ａ．上記引用例の図２に記載された通信システムは、ＮＡＰＴ機能を実装しＬＡＮ１０６とインターネット１０５とを接続するルータ１０３を介して、ＬＡＮ１０６に接続された機器１０１とインターネット１０５に接続された通信端末１０２との間で通信を行うものであるが（摘記事項ア．の段落【００４４】−【００４５】）、
ａ１．一般に、ＮＡＰＴ機能が、内部から外部向けへのアウトバウンド通信のみ許容し、内部ネットワークに属するノードを外部ネットワークから隠蔽するものであることは技術常識であり、
ａ２．「サーバ１０４はそのＴＣＰ接続上で端末１０２と機器１０１間の通信の転送を開始する。すなわち、サーバ１０４は端末１０２からの通信１１４を通信１１５として機器１０１に転送し」（摘記事項ア．の段落【００５８】）とあるように、ＬＡＮ１０６に接続された機器１０１とインターネット１０５に接続された通信端末１０２との間でのＴＣＰ接続上での通信端末１０２から機器１０１への通信も可能としており、
ｂ．機器１０１は、ＬＡＮ１０６を介してルータ１０３と接続するが、該機器１０１は、
ｂ１．「周期的に通知ＵＤＰパケット１０９を送信する」（摘記事項ア．の段落【００４７】）もので、「通知ＵＤＰパケット１０９はルータ１０３により、往路のＮＡＰＴ変換が行なわれた後インターネット１０５に送出され、サーバ１０４にて受信される」（摘記事項ア．の段落【００４７】）ものであり、また、「サーバ１０４は、通知ＵＤＰパケット１０９を受信すると、ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを取り出し、図４に示すように、これらの情報を機器１０１（機器ＩＤ＝”１２３４”）に対応する１組のエントリとしてサーバ内に登録保存する（ステップＳ１１９）。」（摘記事項ア．の段落【００４９】）及び「通知ＵＤＰパケットの送信周期は、ルータ１０３がＵＤＰパケットのＮＡＰＴテーブルをタイムアウトにより破棄する時間よりも短く設定する。これによりルータ１０３には、図９（ｂ）に示したようなＮＡＰＴテーブルがタイムアウトせず継続的に保持される。」（摘記事項ア．の段落【００４８】）の記載によれば、上記通知ＵＤＰパケット１０９は、ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを対応付けた情報の通知及びＮＡＰＴテーブルの維持を行うためのものといえるから、結局、機器１０１は、インターネット１０５上のサーバ１０４に対し、ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを対応付けた情報の通知及びＮＡＰＴテーブルの維持を目的とする通知ＵＤＰパケット１０９を周期的に送信し、
ｂ２．通信端末１０２から機器１０１に対する通信を開始したい場合、通信端末１０２は機器１０１の機器ＩＤをパラメータに指定して、サーバ１０４に対し機器接続要求１１０を送信し（摘記事項ア．の【００５０】）、該機器接続要求１１０を受信したサーバ１０４は、一意なセッション識別子を生成し、機器１０１に対応するエントリからＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスを取得し、これらを用いてセッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１を通知ＵＤＰパケット１０９に対する応答として送信する（図１および摘記事項ア．の段落【００５３】）から、結局、機器１０１は、通知ＵＤＰパケット１０９に対する応答として、前記サーバ１０４から前記セッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１を受信し、
ｂ３．機器１０１は、サーバ１０４に対してＴＣＰ接続要求１１２を送信してＴＣＰ接続を開始し（図１及び摘記事項ア．の段落【００５４】）、
ｂ４．機器１０１は、上記ｂ１．〜ｂ３．の動作を行う以上、そのための手段を備えていることは自明であり、
ｃ．上記ｂ２．の接続要求ＵＤＰパケット１１１の受信は、通信端末１０２がサーバ１０４に対して送信する機器接続要求１１０を契機として行われることは図１の記載から明らかであり、また、該機器接続要求１１０が上記ｂ１．の周期的な通知ＵＤＰパケット１０９の送信とは無関係に発生することも明らかであるから、通知ＵＤＰパケット１０９を周期的に送信する処理及び接続要求ＵＤＰパケット１１１を受信する処理は非同期に遂行されるといえ、
ｄ．上記ｃ．の非同期に遂行される処理に関し、
ｄ１．通信端末１０２からの機器接続要求１１０を受信したサーバ１０４は、通知ＵＤＰパケット１０９に基づくエントリを参照し、「エントリ内の最終アクセス時刻を確認し、現在時刻との差が最大アクセス確認周期を超えている場合は機器接続要求１１０を拒否し、最大アクセス確認周期以下の場合は、ステップＳ１２２以後に進んで機器１０１に接続要求ＵＤＰパケット１１１を送信する」（摘記事項ア．の段落【００５１】）が、「機器１０１は周期的に通知ＵＤＰパケット１０９を送信する。この周期は先に取得した最大アクセス確認周期の値（例えば５分）より小さい間隔で送られる」（摘記事項ア．の段落【００４７】）のであるから、通知ＵＤＰパケット１０９の周期的な送信の期間中にサーバ１０４が通信端末１０２から機器接続要求１１０を受信したときには、エントリ内の最終アクセス時刻と現在時刻との差が最大アクセス確認周期以下であることは自明であって、その場合、通知ＵＤＰパケット１０９に対する応答としてサーバ１０４から送信された接続要求ＵＤＰパケット１１１を機器１０１が受信する処理が実行され、
　
　以上を総合すれば、結局、上記引用例には、以下の発明（以下、「引用発明」という。）が開示されている。
　
「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているＮＡＰＴ機能を実装するルータ１０３により外部ネットワークから隠蔽され、かつＬＡＮ１０６に接続された機器１０１と、インターネット１０５に接続された通信端末１０２との間でのＴＣＰ接続上での通信端末１０２から機器１０１への通信も可能にする通信システムであって；
　前記ＬＡＮ１０６を介してルータ１０３と接続する機器１０１が、
　前記インターネット１０５上のサーバ１０４に対し、ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを対応付けた情報の通知及びＮＡＰＴテーブルの維持を目的とする通知ＵＤＰパケット１０９を周期的に送信する手段；
　前記通知ＵＤＰパケット１０９に対する応答として、前記サーバ１０４からセッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１を受信する手段；
　前記サーバ１０４とＴＣＰ接続を開始する手段とを備え；
　前記通知ＵＤＰパケット１０９を周期的に送信する処理及び前記接続要求ＵＤＰパケット１１１を受信する処理は非同期に遂行され、前記非同期に遂行される処理では、前記通知ＵＤＰパケット１０９の周期的な送信の期間中にサーバ１０４が通信端末１０２から機器接続要求１１０を受信したとき、前記通知ＵＤＰパケット１０９に対する応答として前記サーバ１０４から送信された前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理が実行される、
　通信システム。」
　
（３）対比・判断
　補正後の発明と引用発明とを対比すると、
ａ．引用発明の「ＮＡＰＴ機能を実装するルータ１０３」は、インターネット１０５とＬＡＮ１０６との境界に設けられた装置であって、補正後の発明の「ゲートウェイ装置」に含まれる。
ｂ．引用発明の「ＬＡＮ１０６」、「機器１０１」、「インターネット１０５」、「通信端末１０２」、「サーバ１０４」は、それぞれ、補正後の発明の「内部ネットワーク」、「内部ノード」、「外部ネットワーク」、「外部ノード」、「接続支援装置」に相当する。
ｃ．引用発明の「ネットワーク」に「接続された」は、補正後の発明の「ネットワーク」に「属する」と同義である。
ｄ．引用発明の「通信端末１０２から機器１０１への通信」は、外部から内部への通信であって、明らかに補正後の発明の「外部から内部向けへのインバウンド通信」に相当するから、引用発明の「ＴＣＰ接続上での通信端末１０２から機器１０１への通信」と補正後の発明の「意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信」とは、「外部から内部向けへのインバウンド通信」で共通する。
ｅ．補正後の発明の「ＩＰアプリケーションサービス提供システム」が、通信を行うシステムであることは明らかであって、引用発明の「通信システム」とは、「通信システム」である点で共通する。
ｆ．引用発明の「前記ＬＡＮ１０６を介してルータ１０３と接続する機器１０１」に関し、ルータ１０３は、ＮＡＰＴ機能を有し機器１０１のアドレス変換などを行うものであって、機器１０１を配下に置くものといえるから、引用発明の「前記ＬＡＮ１０６を介してルータ１０３と接続する機器１０１」と補正後の発明の「前記ゲートウェイ装置配下の前記内部ノード」との間に実質的な差異は無く、
ｇ．引用発明の「ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレス」は、機器１０１が周期的に送信する通知ＵＤＰパケット１０９が、ルータ１０３により往路のＮＡＰＴ変換された後のアドレスであるから（摘記事項ア．の段落【００４７】）、上記「ＳＰ」は、上記通知ＵＤＰパケット１０９を送信する際に使われた、機器１０１のための外部ネットワークにおけるポートであり、補正後の発明の「制御チャネルポート」に相当するといえる。
　とすると、引用発明の「ヘッダ内のＳＡ、ＤＡ、ＳＰ、ＤＰの各アドレスと機器ＩＤを対応付けた情報の通知」は、補正後の発明の「制御チャネルポートの通知」に含まれるといえる。
ｈ．引用発明の「ＮＡＰＴテーブル」とは、具体的には、機器１０１が周期的に送信する通知ＵＤＰパケット１０９が、ルータ１０３により往路のＮＡＰＴ変換されるときに作られる、図９のようなＮＡＰＴエントリであると認められるが（摘記事項ア．の段落【００４８】）、このようなＮＡＰＴエントリが、通知ＵＤＰパケット１０９に対する応答として構成された接続要求ＵＤＰパケット１１１（摘記事項ア．の段落【００５３】）の通信を許容するために用いられることは明らかであるから、結局、引用発明の「ＮＡＰＴテーブル」は補正後の発明の「制御チャネルパスの通信許容エントリ」に相当する。
ｉ．上記ｇ．及びｈ．における検討から、引用発明の「通知ＵＤＰパケット１０９」は明らかに補正後の発明の「制御パケット」に相当する。
ｊ．引用発明の「周期的に送信し」は補正後の発明の「定期送信する」と同義である。
ｋ．上記ｈ．における検討から明らかなように、引用発明の「前記通知ＵＤＰパケット１０９に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当する。
ｌ．引用発明の「セッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１」は、通信端末１０２からの機器接続要求１１０の送信を契機として作られるから（図１及び摘記事項ア．の段落【００５０】−【００５６】）、「通信端末１０２に関連する通知」といえる。一方、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」も「外部ノードに関連する通知」であることは明らかであるから、両者は、「外部ノードに関連する通知」である点で共通する。
ｍ．補正後の発明の「ＩＰアプリケーションのデータチャネルをアクティブにオープンする」に関し、本願明細書には、「第３の処理（第３のステップ）：内部ノードＡは、通知を受けた接続先ＩＰアドレス：ポートに対し、トランスポート層プロトコル（ＴＣＰ（Transmission Control Protocol）／ＵＤＰ(User Datagram Protocol)）接続を開始、すなわちＩＰアプリケーションデータチャネルをアクティブにオープンする。」（段落【００２７】）と記載されているから、「ＴＣＰ接続を開始する」を意味するものと認められる。
　とすると、引用発明の「前記サーバ１０４とＴＣＰ接続を開始する手段」と補正後の発明の「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくＩＰアプリケーションのデータチャネルをアクティブにオープンする手段」とは、「ＴＣＰ接続を開始する手段」である点で共通する。
ｎ．上記ｉ．及びｊ．における検討によれば、引用発明の「前記通知ＵＤＰパケット１０９を周期的に送信する処理」は、補正後の発明の「前記制御パケットを定期送信する処理」に相当し、
ｏ．上記ｌ．における検討によれば、引用発明の「前記接続要求ＵＤＰパケット１１１を受信する処理」と補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」とは、「前記外部ノードに関連する通知を受ける処理」で共通する。
ｐ．引用発明の「前記非同期に遂行される処理では」と補正後の発明の「前記非同期は」とは実質的に同義であり、
ｑ．上記ｉ．及びｊ．における検討によれば、引用発明の「前記通知ＵＤＰパケット１０９の周期的な送信の期間中に」は、補正後の発明の「前記制御パケットの定期送信の期間中に」に相当し、
ｒ．引用発明の「機器接続要求１１０」は、明らかに補正後の発明の「接続要求」に相当するから、引用発明の「サーバ１０４が通信端末１０２から機器接続要求１１０を受信したとき」と補正後の発明の「前記接続支援装置が前記外部ノードから接続要求を受信したとき」との間に差異は無く、
ｓ．引用発明の「前記通知ＵＤＰパケット１０９に対する応答として前記サーバ１０４から送信された前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理が実行される」と補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とを対比するに、
ｓ１．上記ｋ．における検討によれば、引用発明の「前記通知ＵＤＰパケット１０９に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当し、
ｓ２．上記ｌ．における検討によれば、引用発明の「接続要求ＵＤＰパケット１１１」と、補正後の発明の「外部ノード対応の接続先アドレス及びポートの通知」とは、「外部ノードに関連する通知」で共通し、
ｓ３．引用発明の接続要求ＵＤＰパケット１１１はサーバ１０４から送信されるから、引用発明の「前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理」は、「サーバ１０４を起点として」実行されると言い得るものであり、
ｓ４．上記ｓ１．〜ｓ３．より、結局、引用発明の「前記通知ＵＤＰパケット１０９に対する応答として前記サーバ１０４から送信された前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理が実行される」と、補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とは、「前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」点で共通している。
　
　以上をまとめると、両者は、以下の点で一致ないし相違している。
　
（一致点）
「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での外部から内部向けへのインバウンド通信も可能にする通信システムであって；
　前記ゲートウェイ装置配下の前記内部ノードが、
　前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と；
　維持されている制御チャネルを通して、前記接続支援装置から前記外部ノードに関連する通知を受ける手段と；
　ＴＣＰ接続を開始する手段とを備え；
　前記制御パケットを定期送信する処理及び前記外部ノードに関連する通知を受ける処理は非同期で遂行され、前記非同期は、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることである通信システム。」
　
（相違点１）
　「外部から内部向けへのインバウンド通信」が、
　補正後の発明では、「意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信」であるのに対し、
　引用発明では、「ＴＣＰ接続上での通信端末１０２から機器１０１への通信」である点。
　
（相違点２）
　「通信システム」が、
　補正後の発明では、「ＩＰアプリケーションサービス提供システム」であるのに対し、
　引用発明では、単に「通信システム」である点。
　
（相違点３）
　「外部ノードに関連する通知」が、
　補正後の発明では、「前記外部ノード対応の接続先アドレス及びポートの通知」であるのに対し、
　引用発明では、「セッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１」である点。
　
（相違点４）
　「ＴＣＰ接続を開始する手段」が、
　補正後の発明では、「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくＩＰアプリケーションのデータチャネルをアクティブにオープンする手段」であるのに対し、
　引用発明では、「前記サーバ１０４とＴＣＰ接続を開始する手段」である点。
　
（相違点５）
　「前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」が、
　補正後の発明では、「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることである」であるのに対し、
　引用発明では、「前記通知ＵＤＰパケット１０９に対する応答として前記サーバ１０４から送信された前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理が実行される」である点。
　
　以下に、上記各相違点につき検討する。
　
（相違点１）について
　まず、引用発明の「通信端末１０２から機器１０１への通信」が、補正後の発明の「外部から内部向けへのインバウンド通信」に相当することは明らかである。
　そして、引用発明の「ＴＣＰ接続上での通信端末１０２から機器１０１への通信」として、引用例には「ＨＴＴＰによる通信を行なって操作やコンテンツ取得などを行なう」（摘記事項ウ．の段落【００７５】）ことが例示され、さらに、ＨＴＴＰリクエストやＨＴＴＰレスポンスなどのメッセージにより端末１０２に表示すべきＨＴＭＬコンテンツを取得することが記載されている（摘記事項ウ．の段落【００８６】−【００８７】）。
　ここで、ＨＴＴＰがＩＰアプリケーションであることは技術常識であり、上記のような、ＨＴＴＰリクエストやＨＴＴＰレスポンスなどのメッセージにより端末１０２に表示すべきＨＴＭＬコンテンツを取得することは、「意図するＩＰアプリケーション通信」といいうるものである。また、上記の例では、端末１０２がＨＴＭＬコンテンツを取得しているが、これとは逆に、機器１０１がＨＴＭＬコンテンツを取得する通信も可能であることは当業者にとって明らかである。
　したがって、引用発明の「ＴＣＰ接続上での通信端末１０２から機器１０１への通信」を、補正後の発明の「意図するＩＰアプリケーション通信での外部から内部向けへのインバウンド通信」とすることは、引用例の記載に基づいて当業者が容易に想到し得るものである。
　
（相違点２）について
　上記「（相違点１）について」で検討したように、引用例には、「通信」の例としてＨＴＴＰによるコンテンツ取得が記載されているが、この通信を、コンテンツを取得する側から見れば、「ＩＰアプリケーションサービス」の「提供」を受けていると見ることができるから、引用発明の「通信システム」を補正後の発明のように「ＩＰアプリケーションサービス提供システム」とすることは、当業者が必要に応じて適宜なし得るものである。
　
（相違点３）及び（相違点４）について
　引用例には、「なお、本実施の形態では機器１０１からの接続先はサーバ１０４のみであり、サーバ１０４が端末１０２と機器１０１間の通信を転送したが、接続要求ＵＤＰパケット１０９により端末１０２のアドレスを通知すれば、機器１０１が端末１０２に対し直接ＴＣＰ接続要求１１０を送信する構成も可能である。この構成によれば、端末１０２と機器１０１が直接通信を行なうことが可能になり、サーバ１０４の転送負荷が低減されるなど別の効果がある。」（摘記事項イ．の段落【００７２】、なお、「接続要求ＵＤＰパケット１０９」は「接続要求ＵＤＰパケット１１１」の誤記と認められる。）と記載されており、機器１０１が、サーバ１０４を介することなく、通信端末１０２に直接ＴＣＰ接続を開始することが記載されている。
　この記載に基づけば、引用発明の接続要求ＵＤＰパケット１１１に含ませる情報を通信端末１０２のアドレスとすることにより、引用発明の「セッション識別子をペイロードに含む接続要求ＵＤＰパケット１１１」を、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」と変更すること（相違点３）は当業者が容易に想到し得るものである。
　また、該通知を受けた後のＴＣＰ接続について、接続先を通信端末１０２とすることにより、引用発明の「前記サーバ１０４とＴＣＰ接続を開始する手段」を、補正後の発明の「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくＩＰアプリケーションのデータチャネルをアクティブにオープンする手段」とすること（相違点４）も当業者が容易に想到し得るものである。
　
（相違点５）について
　まず、上記「ｋ．」で対比したように、引用発明の「前記通知ＵＤＰパケット１０９に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当する。
　また、引用発明の「前記サーバ１０４から送信された」は、明らかに、補正後の発明の「前記接続支援装置を起点として」に相当する。
　さらに、上記「（相違点３）及び（相違点４）について」で検討したように、引用発明の（セッション識別子をペイロードに含む）「接続要求ＵＤＰパケット１１１」を、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」とすることは当業者が容易に想到し得るものである。
　とすると、結局、引用発明の「前記通知ＵＤＰパケット１０９に対する応答として前記サーバ１０４から送信された前記接続要求ＵＤＰパケット１１１を前記機器１０１が受信する処理が実行される」を、補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とすることは、当業者が容易に想到し得るものである。
　
　そして、補正後の発明の作用・効果も引用発明から当業者が予測し得る範囲のものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２３年５月１２日付けの手続補正は上記のとおり却下されたので、本願発明は上記「第２．補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、
　本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明に基づいて当業者が容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用例の記載に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。