【事件の表示】
　特願２０１１−５４７９２８「ネットワークの外部からのプライベートネットワークリソースへのリモートアクセス」拒絶査定不服審判事件〔平成２２年　８月１２日国際公開，ＷＯ２０１０／０９０６７４，平成２４年　７月１２日国内公表，特表２０１２−５１６１１２〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００９年１２月４日（パリ条約による優先権主張外国庁受理　２００９年１月２０日　米国）を国際出願日とする出願であって，平成２６年１月６日付けで拒絶査定がなされ，これに対し，同年５月７日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。その後，同年６月１７日付けで審査官により作成された前置報告書に対して，同年６月２５日付け上申書及び平成２７年３月６日付け上申書が提出された。
　
　
第２　補正却下の決定
［結論］
　平成２６年５月７日付けの手続補正を却下する。
　
［理由］
１　本願発明と補正後の発明
　平成２６年５月７日付けの手続補正（以下，「本件補正」という。）は，平成２５年１２月６日付け手続補正書により補正された特許請求の範囲の請求項１に記載された
「【請求項１】
　プライベートネットワークの外部のクライアントコンピュータから，前記プライベートネットワークに接続される第１のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって，前記プライベートネットワークはエッジリソースを含む方法において，
　（Ａ）前記プライベートネットワークの前記エッジリソースにおいて，クライアントコンピュータから，前記第１のプライベートネットワークリソースに関連する識別子を含む第１の通信を受信するステップであって，前記識別子が，前記プライベートネットワーク上で前記第１のプライベートネットワークリソースのインターネットプロトコル（ＩＰ）アドレスに解決可能，かつ，前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である，ステップと，
　（Ｂ）前記プライベートネットワーク上で，前記第１のプライベートネットワークリソースに関連する前記識別子を前記第１のプライベートネットワークリソースの前記ＩＰアドレスに解決するステップであって，前記第１のプライベートネットワークリソース及び前記エッジリソースとは異なる第２のプライベートネットワークリソースから前記第１のプライベートネットワークリソースの前記ＩＰアドレスを受け取るステップを含む，ステップと，
　（Ｃ）前記第１の通信を前記第１のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」
という発明（以下，「本願発明」という。）を，
「【請求項１】
　プライベートネットワークの外部のクライアントコンピュータから，前記プライベートネットワークに接続され，プライベートドメイン名に関連づけられている第１のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって，前記プライベートネットワークはエッジリソースを含む方法において，
　（Ａ）前記プライベートネットワークの前記エッジリソースにおいて，クライアントコンピュータから，前記第１のプライベートネットワークリソースに関連する識別子を含む第１の通信を受信するステップであって，前記識別子が，前記プライベートネットワーク上で前記第１のプライベートネットワークリソースのインターネットプロトコル（ＩＰ）アドレスに解決可能であり，かつ，前記識別子が前記プライベートドメイン名に関する場合に，前記識別子は前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である，ステップと，
　（Ｂ）前記プライベートネットワーク上で，前記第１のプライベートネットワークリソースに関連する前記識別子を前記第１のプライベートネットワークリソースの前記ＩＰアドレスに解決するステップであって，前記第１のプライベートネットワークリソース及び前記エッジリソースとは異なる第２のプライベートネットワークリソースから前記第１のプライベートネットワークリソースの前記ＩＰアドレスを受け取るステップを含む，ステップと，
　（Ｃ）前記第１の通信を前記第１のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」
という発明（以下，「補正後の発明」という。）に変更することを含むものである。
　
２　補正の適否
（１）新規事項の有無，シフト補正の有無，補正の目的要件
　上記補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内において，本願発明の「第１のプライベートネットワークリソース」を「プライベートドメイン名に関連づけられている第１のプライベートネットワークリソース」に限定するとともに，本願発明の「かつ，前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である」を「かつ，前記識別子が前記プライベートドメイン名に関する場合に，前記識別子は前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である」に限定して，特許請求の範囲を減縮するものである。
　この他，本件補正として，請求項７についての補正は，本件補正前の「前記クライアント」を「前記クライアントコンピュータ」に限定して，特許請求の範囲を減縮するものである。また，請求項１２についての補正は，請求項１についての上記補正と同様である。
　したがって，本件補正は，特許法第１７条の２第３項及び第４項の規定に適合することは明らかであり，また，同法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当する。
（２）独立特許要件
　請求項１についての上記補正は，特許請求の範囲の減縮を目的とするものであるから，補正後の発明が特許出願の際独立して特許を受けることができるものであるのか否かについて，以下検討する。
ア　補正後の発明
　補正後の発明は，上記「１　本願発明と補正後の発明」の項の「補正後の発明」のとおりのものと認める。
イ　引用発明及び公知の技術事項
［引用発明］
　原査定の拒絶の理由に引用された特開２００４−１２０５３４号公報（以下，「引用例」という。）には，「ルータと中継装置，フォワーディング方法」に関し，図面とともに以下の事項が記載されている。
　
（ア）「【０００１】
【発明の属する技術分野】
本発明は，ブラウザから付加されるホスト名によってフォワーディングするためのローカルＩＰアドレスを決定するルータ，ネットワーク間を中継する中継装置と，及びホスト名によってフォワーディングするフォワーディング方法に関するものである。
【０００２】
【従来の技術】
インターネット等の広域ネットワークへ常時接続するためＡＤＳＬ，ＣＡＴＶの普及が本格化し，ブロードバンドルータの普及も著しい。図８は従来のホストネームフォワーディング機能をもつルータの構成図，図９は従来のポートフォワーディング設定テーブルの説明図である。図８，９において，１０１はインターネット，１０２はＬＡＮ側のポートを複数備えたルータ，１０３はポート番号「８０」でローカルＩＰアドレス「１９２．１６８．０．２５３」のサーバＡ，１０４はポート番号「８１」でローカルＩＰアドレス「１９２．１６８．０．２５４」のサーバＢである。このようにルータ１０２は，ＷＡＮ側のポートをインターネット１０１，またＬＡＮ側のポートにサーバＡ１０３，サーバＢ１０４等の複数のユーザ機器を接続するものが主流である。
【０００３】
ところで，現行のＩＰプロトコルＩＰｖ４ではグローバルＩＰアドレスの絶対数が不足しているため，ＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）機能やポートフォワーディング機能（静的ＩＰマスカレード）などを使用してグローバルＩＰアドレスの不足に対応している。このＮＡＴ機能は，ＬＡＮ側の機器からインターネット１０１へアクセスするときには，そのローカルＩＰアドレスをルータ１０２のＷＡＮ側のグローバルＩＰアドレスへ変換するものである。
【０００４】
また，インターネット１０１からＬＡＮ側の特定の機器へアクセスする場合は，ルータ１０２のポートフォワーディング機能（静的ＩＰマスカレード機能）を用いることでアクセスが可能になる。すなわち，これにはまず予め，図９のようにルータ１０２にポート番号とローカルアドレスの変換テーブルを設定しておく必要がある。インターネット１０１からアクセスするときには，ルータ１０２のグローバルＩＰアドレスとポート番号を指定する。このアクセスを受け付けたルータ１０２は予め設定された変換テーブルに従い，グローバルＩＰアドレスをプライベートＩＰアドレスへの変換を行う。この変換によりインターネット１０１からローカルＩＰアドレスをもったＬＡＮ内の一つの機器にアクセスすることが可能となる。
【０００５】
例えば，図８に示したルータ１０２のＬＡＮ側に接続したサーバＡ１０３，サーバＢ１０４にアクセスする場合，まず，上述したようなポートフォワーディング設定を予めルータ１０２に対して行っておく。続いて，インターネット１０１からサーバＡ１０３にアクセスする場合には「ｈｔｔｐ：／／ｓｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ：８０／」と指定する。同様に，インターネット１０１からサーバＢ１０４にアクセスする場合は「ｈｔｔｐ：／／ｓｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ：８１／」と指定する。これにより，図示しないインターネット１０１上のＤＮＳサーバによって，ルータ１０２のグローバルＩＰアドレスに変換され，ルータへのアクセスが可能となる。ルータは変換テーブルに従いポート「８０」，「８１」へのアクセスをローカルアドレス「１９２．１６８．０．２５３」，「１９２．１６８．０．２５４」へフォワードすることによりサーバＡ１０３，Ｂ１０３へのアクセスが可能になる。なお，このようにポートフォワーディング機能によりインターネット１０１からサーバＡ１０３，サーバＢ１０４にアクセスするには各サーバに割り当てるポート番号が重複しないように番号を割り当てる必要がある。
【０００６】
このように従来のルータ１０２は，ポートフォワーディング機能，ＮＡＴ機能によりグローバルＩＰアドレスの枯渇を緩和し，複数のユーザ機器とインターネットとを接続したが，ユーザはＬＡＮ側の機器のポート番号を知って，その変更をフォローしなければならなかった。そこで，ディレクトリーを使い，グローバルＩＰアドレスによる管理端末とプライベートＩＰアドレスによる管理端末間の１対１の相互通信を可能とする通信ネットワークシステムが提案された（特許文献１を参照）。
【０００７】
これは，インターネット等の公衆通信網と，プライベート・ネットワーク間に中継手段を設け，中継手段が，プライベート・ネットワークに接続された端末の識別子をディレクトリー（特許文献１ではサブアドレス）として識別して，外部からのアクセス要求をプライベート・アドレス空間で割り振られた個々の端末に接続することを可能としたものである。また，本構成と，ＮＡＴ，ＩＰマスカレード等の手法とを併用することにより，グローバルＩＰアドレスによって管理されているインターネットにおける端末と，プライベートＩＰアドレスによって管理されているプライベート・ネットワークの端末間での１対１の相互通信が可能にするものである。
【０００８】
現在，グローバルＩＰアドレスは固定ではなく，ＤＨＣＰサーバによって割り当てられることがほとんどである。従って次々と更新されるグローバルＩＰアドレスをホスト名に対応させるＤＤＮＳサーバがなければ，ホスト名によるアクセスはできない。（特許文献１）のシステムは，ディレクトリーを識別子として使うため，ディレクトリーが異なる端末の認識が行えるのは同一のＤＤＮＳサーバにホスト名が登録されている場合だけである。従って，このシステムではプライベート・ネットワーク内にＤＤＮＳサーバが設けられていなければならない。
【０００９】
【特許文献１】
特開２００１−３４５８４１号公報
【００１０】
【発明が解決しようとする課題】
以上説明したように従来のルータのポートフォワーディング機能（静的ＩＰマスカレード機能）は，ＬＡＮ側の機器をポート番号を用いてアクセスできるものであるが，インターネット側のユーザはＬＡＮ側の機器のポート番号を知っておく必要があり，ＬＡＮ側のシステム変更のためポート番号の変更があった場合，その変更を常にフォローしなければならなかった。
【００１１】
一方，（特許文献１）のシステムは，ポート番号を用いずにＬＡＮ側の機器にアクセス可能であるものの，ディレクトリーを識別子として使うため，ホスト名に加え更に続けてディレクトリーを入力する必要があり，またホスト名自体は同一もののにならざるを得えず，ＬＡＮ側に複数の機器がある場合にそれぞれ異なるホスト名を付与することができない。
【００１２】
加えて，（特許文献１）では，ディレクトリー構造を使用しているため，例えば，「ｈｔｔｐ　：／／ｗｗｗ．ｃａｒｒｉｅｒ．ｎｅ．ｊｐ／ａｂ００１／ｉｎｄｅｘ．ｈｔｍｌ」というアクセスを許可する場合，ルータ（中継手段）配下の端末は，「ａｂ００１／ｉｎｄｅｘ．ｈｔｍｌ」のファイルの要求があったと認識し，ディレクトリａｂ００１からｉｎｄｅｘ．ｈｔｍｌを取出して，アクセス元に送信することになるため，この端末にも同じ構造でディレクトリー「ａｂ００１」を作る必要がある。言い換えれば，「ａｂ００１」のディレクトリーの中に「ｉｎｄｅｘ．ｈｔｍｌ」というウェブページを端末に配置する必要がある。しかし市販されている端末にはディレクトリーを変更できないものが相当数存在し，この構造を採用して通信することはできない。そして，この問題を回避するために，ブラウザから端末への転送時にＨＴＴＰメッセージに含まれる上記したＵＲＩのうち「ａｂ００１」を取り除く処理が必要であり，また端末側からブラウザへの転送時には，逆に「ａｂ００１」をＨＴＴＰメッセージに付加する処理が必要となる。このような処理（アプリケーション層のデータの変換処理）はきわめて複雑であり，転送速度が低下することになる。
【００１３】
そこで本発明は，複数の端末に対してそれぞれホスト名でアクセスでき，グローバルＩＰアドレスの更新があってもアクセス可能で，複数の端末間で共通のディレクトリーを使うことができるルータを提供することを目的とする。
【００１４】
また本発明は，複数の端末に対してそれぞれホスト名でアクセスでき，グローバルＩＰアドレスの更新があってもアクセス可能で，複数の端末間で共通のディレクトリーを使うことができるフォワーディング方法を提供することを目的とする。」（２〜４ページ）
（イ）「【００２２】
（実施の形態１）
本発明の実施の形態１におけるホスト名によるフォワーディングを行うルータを配置したネットワークシステムについて説明する。図１は本発明の実施の形態１におけるルータ配下の端末にアクセスするネットワークシステムの構成図，図２はホスト名フォワーディングテーブルの説明図，図３は本発明の実施の形態１におけるルータによるホスト名検出の説明図，図４はＨＴＴＰリクエストヘッダの説明図，図５は本発明の実施の形態１におけるルータを配置したシステムでアクセスするときのシーケンスチャートである。
【００２３】
１はインターネット（本発明の広域ネットワーク），２はインターネット１と接続可能なインターフェイスを有し，ＬＡＮ側のポートを複数備えて配下の各機器，後述するサーバＡ３，サーバＢ４に対してインターネット１との間でルーティングを行うルータ（中継装置），２ａはルータ２に設けられ，インターネット１から受信したＩＰパケット（データパケット）のＨＴＴＰヘッダからホスト名を取り出すホスト名検出手段，２ｂはホスト名検出手段２ａにより取出したホスト名が後述する変換テーブル２ｃのホスト名と一致するか否かを判断し，一致するホスト名があればそのホスト名に対応するローカルＩＰアドレスを変換テーブル２ｃから取出し，更に受信したＩＰパケットの宛先アドレスを取出したローカルＩＰアドレスに置き換えて，ＬＡＮ側へ送信するアドレス変換手段，２ｃはアドレス変換手段２ｂがホスト名をローカルＩＰアドレスに変換するために参照するホスト名フォワーディングテーブル（本発明の変換テーブル）である。ルータ２は実施の形態１の場合ブロードバンドルータである。
【００２４】
３はポート番号「８０」でホスト名「ｓｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」のサーバＡ，４はポート番号「８０」でホスト名「ｓｅｒｖｅｒＢ．ｓｅｒｖｅｒ．ｎｅｔ」のサーバＢである。なお，これらのホスト名は後述のＤＤＮＳサーバ８により管理されている。５はインターネット１に接続してサーバＡ３，サーバＢ４にアクセスできる端末，６は所定のグローバルＩＰアドレスの中から端末５にグローバルＩＰアドレスを割り当てるＤＨＣＰ（Ｄｙｎａｍｉｃ　Ｈｏｓｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）サーバ，７はホスト名でアクセスするとグローバルＩＰアドレスを応答するＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバ，８はＤＨＣＰサーバ６が決定したグローバルＩＰアドレスとホスト名との対応をつけるＤＤＮＳ（Ｄｙｎａｍｉｃ　Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバである。
【００２５】
本実施の形態１のルータ２は，図３に示すように端末５のブラウザからインターネット１を介してサーバＡ３（若しくはサーバＢ４）にＨＴＴＰリクエストを送信すると，ホスト名検出手段２ａによりサーバＡ３（若しくはサーバＢ４）のホスト名をＩＰパケットのＨＴＴＰリクエストヘッダから取り出し，アドレス変換手段２ｂによってローカルＩＰアドレスに変換して，端末５から受信したＩＰパケットを変換したローカルＩＰアドレスのサーバＡ３（若しくはサーバＢ４）にルーティングするものである。図３においては，後述するようにグローバルＩＰアドレス「１．１．１．１」を宛先ＩＰアドレスに収め，ホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をＨＴＴＰリクエストヘッダに収めたＨＴＴＰリクエストがサーバＡ３に向けて送信され，ルータ２がルーティングを行う。
【００２６】
すなわち，図４に示すようにＨＴＴＰリクエストでサーバＡ３にリクエストするときは，メソッド「ＧＥＴ」の後にＵＲＩとバージョン情報「ＨＴＴＰ１．０」，「Ｈｏｓｔ」の後にホスト名，最後に「ＣＲＬＦ」行を書き込んで，サーバＡ３からファイルを要求する。このようにＨＴＴＰリクエストヘッダの要求行にはホスト名が自動的に書き込まれるから，これをホスト名検出手段２ａが取り出し，アドレス変換手段２ｂがローカルＩＰアドレスに変換するものである。
【００２７】
そこで，サーバＡ３に対するＨＴＴＰリクエストとそのレスポンスが行われる一連の基本的な処理に関して，図５のシーケンスチャートに基づいてルータの説明を行う。まず，図５のＳ１において，ルータ２からＤＨＣＰサーバ６にグローバルＩＰアドレスを要求して，ＤＨＣＰサーバ６がグローバルＩＰアドレス「１．１．１．１」をルータ２に制限時間付きで割り当てる。ルータ２はこのグローバルＩＰアドレス「１．１．１．１」とサーバＡ３のホスト名をＤＤＮＳサーバ８に通知する。さらに，ルータ２はこのグローバルＩＰアドレス「１．１．１．１」とサーバＢ４のホスト名をＤＤＮＳサーバ８に通知する。なお，ルータ２はホスト名による変換モードのモード設定ができる。また，ここでは，ルータ２がＤＤＮＳ設定要求を行うようにしたが，ルータ２に代えてサーバＡ３やサーバＢ４が各々ルータ２に対しＤＤＮＳ設定要求を行うようにしてもよい。Ｓ２において，サーバＡ３はＤＤＮＳサーバ８に更新要求する。ＤＤＮＳサーバ８にはＳ３で，端末５のブラウザを用いて「ｈｔｔｐ：／／ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をＵＲＩに指定し，ＤＮＳサーバ７にグローバルＩＰアドレスを問い合わせると，ＤＮＳサーバ７はＤＤＮＳサーバ８に問い合わせる。Ｓ４においてＤＤＮＳサーバ８は，「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」に対応するグローバルＩＰアドレス「１．１．１．１」を回答し，ＤＮＳサーバ７が端末５に回答する。
【００２８】
このルータ２のグローバルＩＰアドレス「１．１．１．１」を受け取った端末５はＬＡＮ内にあるサーバＡ３に対してＨＴＴＰによるアクセスを発生し，Ｓ５においてグローバルＩＰアドレス「１．１．１．１」を宛先ＩＰアドレス，宛先ポート番号に「８０」を収めて，図４のようなＨＴＴＰヘッダをデータ域にセットしたＩＰパケットをインターネット１に送信する。なお，ポート番号は従来のポートフォワーディング機能と異なり，サーバＡ３，サーバＢ４ともに共通の「８０」を設定することができる。
【００２９】
ＩＰパケットがルータ２に到着しルータ２が受信する（Ｓ６）。ルータ２は図示しないルーティングテーブルを参照して，ホスト名から配下のサーバＡ３であることを知り，ローカルＩＰアドレスに変換してＨＴＴＰリクエストをサーバＡ３に転送する。図６は本発明の実施の形態１におけるルータの処理のフローチャートである。図６に示すようにルータがＩＰパケットを受信すると（Ｓ６１），ホスト名による変換モードか否かがチェックされる（Ｓ６２）。変換モードの場合，ＩＰパケットからＨＴＴＰヘッダに含まれるホスト名を取り出し（Ｓ６３），変換モードでない場合には宛先ポート番号に従って処理（ポートフォワーディング機能等）を行う（Ｓ６６）。
【００３０】
ホスト名を取り出すと，変換テーブルを読み出し（Ｓ６４），取り出したホスト名が変換テーブルに存在するか否かをチェックする（Ｓ６５）。なおルータ２には，図２に示すようなホスト名とＬＡＮ側のローカルＩＰアドレスの対応を記述した変換テーブルが予め設定してある。本実施の形態１の場合は，各グローバルＩＰアドレスもこれらに関係付けられている。ホスト名が変換テーブルにあった場合，変換テーブルから対応するローカルＩＰアドレスを取り出し（Ｓ６８），ホスト名が変換テーブルになかった場合にはＳ６６に進んで，宛先ポート番号に従って処理する。Ｓ６７において，受信したＩＰパケットのＩＰヘッダの宛先ＩＰアドレスを取出したローカルＩＰアドレスへ置き換え，ＩＰパケットをＨＴＴＰリクエストとしてＬＡＮに送信する。図２の変換テーブルによれば，ホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」にはローカルＩＰアドレス「１９２．１６８．０．２５３」，ホスト名「ＳｅｒｖｅｒＢ．ｓｅｒｖｅｒ．ｎｅｔ」にはローカルＩＰアドレス「１９２．１６８．０．２５４」が対応づけられているため，Ｓ６でルータ２はホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をローカルＩＰアドレス「１９２．１６８．０．２５３」に変換し，その後，宛先ＩＰアドレスに「１９２．１６８．０．２５３」をセットしたＨＴＴＰリクエストがサーバＡ３に送信されることになる。
【００３１】
次いで，Ｓ７でサーバＡ３は端末５に向けてレスポンスを送信する。送信元ＩＰアドレスに「１９２．１６８．０．２５３」をセットしたパケットを送信すると，ルータ２がこれを受け取る。Ｓ８において，ルータ２は端末５に向けたレスポンスであることを認識し，図示しないルーティングテーブルを参照して，送信元ＩＰアドレスに「１．１．１．１」をセットしてＩＰパケットを送信し，端末５のブラウザが受信する。これにより，インターネット１を介してのＬＡＮ内のサーバＡ３等の機器への通信が可能となる。
【００３２】
このように本発明の実施の形態１のルータは，ＨＴＴＰリクエストヘッダに記載されたホスト名を取り出してローカルＩＰアドレスに変換するから，複数のサーバＡ，Ｂに対してそれぞれドメイン名を含んで通常通りホスト名でアクセスでき，ＤＨＣＰサーバの使用によりＤＤＮＳサーバでグローバルＩＰアドレスの更新が次々とあっても，これに影響されることなくアクセスが可能である。また，複数のサーバＡ，Ｂ間で共通名のディレクトリーを使うことができる。
【００３３】
そして実施の形態１のルータは，ブラウザから送信されるＩＰパケットのうち，アプリケーション層のデータを変換処理することなく，単に宛先ＩＰアドレスを変更するだけでよく，きわめて簡単な構成で通信できる。すなわち，クライアント側は，ホスト名のみでルータ配下の端末を直接アクセスできる。ＨＴＴＰヘッダを変更したり，サーバ側でディレクトリーの構造を採用して対応する必要がない。」（５〜８ページ）
　上記記載及び図面並びに当業者の技術常識を考慮すると，
ａ　上記（ア）の【０００４】〜【０００８】の記載及び図８，９によれば，ルータ１０２は，インターネット等の公衆通信網と，プライベート・ネットワーク間の中継手段といえ，中継手段であるルータ１０２が，プライベート・ネットワークの外部であるインターネット１０１からプライベート・ネットワークに接続された端末であるサーバＡ１０３，サーバＢ１０４へのアクセス要求を可能とするものといえる。そして，図１，図２は，図８，図９に記載された従来例の課題（【００１３】，【００１４】）を解決するための構成であって，図８，図９と前提となる構成は同じと解されるから，ルータ２は，プライベート・ネットワークの外部の端末５から，前記プライベート・ネットワークに接続されている端末であるサーバＡ３，サーバＢ４へのアクセス要求を可能とするものといえる。
　また，上記（ア）の【０００４】の記載によれば，ローカルＩＰアドレスはプライベートＩＰアドレスと同義と認められ，また，上記（ア）の【００１３】，上記（イ）の【００２９】，【００３０】の記載及び図２によれば，ローカルＩＰアドレスはホスト名に対応付けられているから，サーバＡ１０３，サーバＢ１０４はホスト名に関連付けられていることは明らかである。
　したがって，引用例には，「プライベート・ネットワークの外部の端末５から，前記プライベート・ネットワークに接続され，ホスト名に関連づけられているサーバへのアクセスを可能にするための方法であって，インターネットとプライベート・ネットワーク間の中継手段としてルータ２を備える方法」が記載されていると認められる。
　
ｂ　上記（イ）の【００２５】〜【００２８】の記載及び図４，図５によれば，端末５のブラウザからインターネット１を介して，ホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をＨＴＴＰリクエストヘッダに収めたＨＴＴＰリクエストが，サーバＡ３（若しくはサーバＢ４）に向けて送信され，ルータ２がルーティングを行うものである。したがって，ルータ２において，端末５から，ＨＴＴＰリクエストヘッダを含むＨＴＴＰリクエストを受信するといえる。
　そして，上記（イ）の【００２３】，【００２９】〜【００３０】の記載及び図５，図６によれば，ＩＰパケットがルータ２に到着しルータ２が受信すると，ルータ２はホスト名を取り出し，変換テーブルであるホスト名フォワーディングテーブルを読み出して，取り出したホスト名が図２に示すような変換テーブルに存在するか否かをチェックし，ホスト名から配下のサーバＡ３であることを知り，変換テーブルによりホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をローカルＩＰアドレス「１９２．１６８．０．２５３」に変換し，宛先ＩＰアドレスにローカルＩＰアドレス「１９２．１６８．０．２５３」をセットしたＨＴＴＰリクエストがサーバＡ３に送信される。したがって，ＨＴＴＰリクエストヘッダに収めた情報であるホスト名が，プライベート・ネットワーク上でサーバのローカルＩＰアドレスに解決可能であるといえる。
　ここで，上記（イ）の【００３０】の記載及び図２によれば，変換テーブルには，ホスト名とＬＡＮ側のローカルＩＰアドレスと各グローバルＩＰアドレスとが関係付けられていると認められる。
　また，上記（イ）の【００２７】の記載及び図５によれば，ＤＤＮＳサーバ８には，端末５のブラウザを用いて「ｈｔｔｐ：／／ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」をＵＲＩに指定し，ＤＮＳサーバ７にグローバルＩＰアドレスを問い合わせると，ＤＮＳサーバ７はＤＤＮＳサーバ８に問い合わせ，ＤＤＮＳサーバ８はホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」に対応するグローバルＩＰアドレス「１．１．１．１」を回答し，ＤＮＳサーバ７が端末５に回答するものである。そして，ＤＨＣＰサーバ６がグローバルＩＰアドレス「１．１．１．１」をルータ２に割り当てるから，グローバルＩＰアドレス「１．１．１．１」はルータ２のＩＰアドレスといえる。したがって，ＨＴＴＰリクエストヘッダに収めた情報であるホスト名は，プライベート・ネットワークの外部でルータ２のグローバルＩＰアドレスに解決可能であるといえる。
　以上より，引用例には，「前記ルータ２において，端末５から，前記ＨＴＴＰリクエストヘッダを含むＨＴＴＰリクエストを受信するステップであって，前記ＨＴＴＰリクエストヘッダに収めた情報であるホスト名が，前記プライベート・ネットワーク上で前記サーバのローカルＩＰアドレスに解決可能であり，かつ，前記ＨＴＴＰリクエストヘッダに収めた情報は前記プライベート・ネットワークの外部で前記ルータ２のグローバルＩＰアドレスに解決可能である，ステップ」が記載されていると認められる。
ｃ　上記ｂのとおりであるから，ルータは，プライベート・ネットワーク上で，サーバに関連するＨＴＴＰリクエストヘッダに収めた情報をサーバのローカルＩＰアドレスに解決しているといえ，当該解決に当たり，変換テーブルであるホスト名フォワーディングテーブルからサーバのローカルＩＰアドレスを取り出していることは明らかである。そして，ＨＴＴＰリクエストをサーバに伝送していることも明らかである。
　したがって，引用例には，「前記プライベート・ネットワーク上で，前記サーバに関連する前記ＨＴＴＰリクエストヘッダに収めた情報を前記サーバの前記ローカルＩＰアドレスに解決するステップであって，ホスト名フォワーディングテーブルから前記サーバの前記ローカルＩＰアドレスを取り出すステップを含む，ステップ」及び「前記ＨＴＴＰリクエストを前記サーバに伝送するステップ」が記載されていると認められる。
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認める。
「プライベート・ネットワークの外部の端末５から，前記プライベート・ネットワークに接続され，ホスト名に関連づけられているサーバへのアクセスを可能にするための方法であって，インターネットとプライベート・ネットワーク間の中継手段としてルータ２を備える方法において，
　前記ルータ２において，端末５から，前記ＨＴＴＰリクエストヘッダを含むＨＴＴＰリクエストを受信するステップであって，前記ＨＴＴＰリクエストヘッダに収めた情報であるホスト名が，前記プライベート・ネットワーク上で前記サーバのローカルＩＰアドレスに解決可能であり，かつ，前記ＨＴＴＰリクエストヘッダに収めた情報は前記プライベート・ネットワークの外部で前記ルータ２のグローバルＩＰアドレスに解決可能である，ステップと，
　前記プライベート・ネットワーク上で，前記サーバに関連する前記ＨＴＴＰリクエストヘッダに収めた情報を前記サーバの前記ローカルＩＰアドレスに解決するステップであって，ホスト名フォワーディングテーブルから前記サーバの前記ローカルＩＰアドレスを取り出すステップを含む，ステップと，
　前記ＨＴＴＰリクエストを前記サーバに伝送するステップと
を含む方法。」
［公知の技術事項］
　同じく原査定の拒絶の理由に引用された国際公開第２００５／０２９８７７号（以下，「公知例」という。）には，「USE OF AN AUTOCONFIGURED NAMESPACE FOR AUTOMATIC PROTOCOL PROXYING」（［当審仮訳］：自動プロトコル・プロキシ処理のための自動設定ネーム・スペースの使用）に関し，図面とともに以下の事項が記載されている。
（ウ）「The web servers 230 and 240 ('cube' and 'noizi', respectively) are added to the name of the privately addressed network ('. private. arpa') to produce names 'cube.private.arpa' and 'noizi.private.arpa', respectively. More generally, the names of devices or hosts connected to a privately addressed network are added to the privately addressed network's name to create internal names, which are translated into local addresses.」（５ページ１９〜２４行）
（［当審仮訳］：
　Ｗｅｂサーバ２３０及び２４０（ 「ｃｕｂｅ」及び「ｎｏｉｚｉ」）は，それぞれ，名前（「ｃｕｖｅ．ｐｒｉｖａｔｅ．ａｒｐａ」及び「ｎｏｉｚｉ．ｐｒｉｖａｔｅ．ａｒｐａ」） を生成するために，プライベートにアドレスされたネットワークの名前（「．ｐｒｉｖａｔｅ．ａｒｐａ」）に追加される。より一般的には，プライベートにアドレスされたネットワークに接続されたデバイス又はホストの名前は，ローカルアドレスに翻訳された内部名を作成するため，プライベートにアドレスされたネットワークの名前に追加される。）
（エ）「Fig. 5 is a flow diagram showing additional detail of steps 310 and 320 of Fig. 3. At step 510, a DHCP server receives a request from an internal host/device for an Internet Protocol (IP) address. The request comprises the private name of the internal host/device. At step 520, the DHCP server provides an IP address to the internal host/device. Data relating to the internal host/device is extracted from DHCP data (e.g., a DHCP lease file) at step 530 and the name and address of the internal host/device is registered with a DNS server and its associated distributed service at step 540. Separate hostname and address pairs are associated and registered for internal and external use as follows: 
　Internal: hostname .private, arpa = address 
　External: hostname.external.network.name = gateway.address 
　　For illustration purposes only, an example of the association and registration of separate hostname and address pairs for internal and external use with reference to Fig. 2 is provided hereinafter. An internal host (web server) 230 provides its name ('cube') to the DCHP server. The DHCP server assigns the private address 192.168.1.43 to the internal host 230. The address 192.168.1.43 is associated with the name 'cube. private. arpa ' for internal requests and the name 'cube.aidan.eg.org' is associated with the address 203.213.140.43 (the global address of the gateway 220) for external requests. 
　　Fig. 6 is a flow diagram showing additional detail of step 330 of Fig. 3. At step 610, a request for an internal host/device is received by a DNS server from an external host/device. At step 620, the DNS server returns the address of a gateway, which is the gateway of a privately addressed network to which the internal host/device is connected, to the external host/device. At step 630, the external host/device opens a connection to the global gateway address 203.213.140.43 via port 80 (HTTP). At step 640, the gateway accepts the connection. At step 650, the gateway examines the request header that is directed to the internal host/device and extracts the internal hostname. The gateway resolves the hostname internally and obtains the internal host/devices 's private address, at step 660. At step 670, the gateway opens a connection to the internal host/device and proxies communications between the external host/device and the internal host/device. The communications may be modified by the gateway. 」（８ページ２８行〜９ページ２７行）
（［当審仮訳］：
　図５は，図３のステップ３１０及び３２０のさらなる詳細を示すフロー図である。ステップ５１０において，ＤＨＣＰサーバは，内部ホスト／デバイスから，インターネットプロトコル（ＩＰ）アドレスの要求を受ける。要求は，内部ホスト／デバイスのプライベート名を含む。ステップ５２０で，ＤＨＣＰサーバは，内部ホスト／デバイスにＩＰアドレスを提供する。ステップ５３０で，内部ホスト／デバイスに関するデータがＤＨＣＰデータ（例えば，ＤＨＣＰリースファイル）から取り出され，ステップ５４０で，内部ホスト／デバイスの名前及びアドレスが，ＤＮＳサーバとそれに関連する割り当てられたサービスに登録される。次のように分離したホスト名とアドレスのペアは，内部及び外部の使用のために関連され登録されている。
　内部： ホスト名．ｐｒｉｖａｔｅ．ａｒｐａ = アドレス 
　外部： ホスト名．ｅｘｔｅｒｎａｌ．ｎｅｔｗｏｒｋ．ｎａｍｅ = ゲートウェイのアドレス
　説明のみを目的として，内部及び外部の使用のために分離したホスト名とアドレスのペアの関連及び登録の例が，図２を参照して以下に与えられる。内部ホスト（Ｗｅｂサーバ）２３０は，ＤＣＨＰサーバに，名前（「ｃｕｂｅ」）を提供する。ＤＨＣＰサーバは，内部ホスト２３０に，アドレス１９２．１６８．１．４３を割り当てる。アドレス１９２．１６８．１．４３は内部リクエストのために名前 「ｃｕｂｅ．ｐｒｉｖａｔｅ．ａｒｐａ」に関連付けられており，名前「ｃｕｂｅ．ａｉｄｅｎ．ｅｇ．ｏｒｇ」は外部リクエストのためにアドレス２０３．２１３．１４０．４３に関連付けられている。
　図６は，図３のステップ３３０のさらなる詳細を示すフロー図である。ステップ６１０で，外部のホスト／デバイスからの内部ホスト／デバイスへの要求がＤＮＳサーバによって受信される。ステップ６２０で，ＤＮＳサーバは，外部ホスト／デバイスに対して，内部ホスト／デバイスが接続されているプライベートにアドレスされたネットワークのゲートウェイのアドレスを返す。ステップ６３０で，外部ホスト／デバイスは，ポート８０を介してグローバルゲートウェイアドレス２０３．２１３．１４０．４３（ＨＴＴＰ）への接続を開く。ステップ６４０で，ゲートウェイは接続を受け付ける。ステップ６５０で，ゲートウェイは内部ホスト／デバイスに向けられている要求のヘッダーを調べ，内部ホスト名を取り出す。ステップ６６０で，ゲートウェイはホスト名を内部的に解決し，内部ホスト／デバイスのプライベートアドレスを取得し，ステップ６７０で，ゲートウェイは内部ホスト／デバイスへの接続をオープンし，外部ホスト／デバイスと内部ホスト／デバイスとの間の通信をプロキシする。通信は，ゲートウェイによって変更することができる。）
　上記（ウ），（エ）の記載によれば，「プライベートネットワーク内のリソースの名前による問い合わせに対して，プライベートネットワーク名を加えて，プライベートネットワーク内で名前解決すること」ことは，公知の技術事項といえる（以下，「公知事項１」という。）。
（オ）「Referring to Figs. 4a and 4b, a host device 410 that is internal to a privately addressed network (not shown) is connected to a gateway 420 of the privately addressed network. The gateway 420 comprises a DHCP server 422, a DNS server 424, and a proxy server 426. The gateway 420 comprises separate computer systems to implement the functionality of the DHCP server 422, the DNS server 424, and the proxy server 426. As would be understood by persons skilled in the art, the functionality of the DHCP server 422, the DNS server 424, and the proxy server 426 can be implemented using software executing on one or more computer systems. Moreover, the DHCP server 422 and the DNS server 424 need not form part of the gateway 420. That is, either or both of the DHCP server 422 and the DNS server 424 can be located on a different device to the gateway 420. 」（７ページ１５〜２８行）
（［当審仮訳］：
　図４ａ及び４ｂを参照すると，プライベートにアドレスされたネットワーク（図示せず）の内部にあるホストデバイス４１０は，プライベートにアドレスされたネットワークのゲートウェイ４２０に接続されている。ゲートウェイ４２０は，ＤＨＣＰサーバ４２２，ＤＮＳ４２４，及びプロキシサーバ４２６を含む。ゲートウェイ４２０は，ＤＨＣＰサーバ４２２，ＤＮＳサーバ４２４，プロキシサーバ４２６としての機能を実現するために，別個のコンピュータシステムを含む。当業者によって理解されるように，ＤＨＣＰサーバ４２２の機能は，ＤＮＳサーバ４２４，プロキシサーバ４２６は，１つまたは複数のコンピュータシステム上で実行するソフトウェアを用いて実施することができる。また，ＤＨＣＰサーバ４２２及びＤＮＳサーバ４２４は，ゲートウェイ４２０の一部を形成する必要はなく，ＤＨＣＰサーバ４２２及びＤＮＳサーバ４２４のいずれか又は双方は，ゲートウェイ４２０とは異なるデバイス上に配置することができる。）
　上記（オ）の記載によれば，「プライベートにアドレスされたネットワークのアドレス解決をするため手段（ＤＨＣＰサーバ及び／又はＤＮＳサーバ）は，ゲートウェイに含んでもよいし，ゲートウェイとは異なるデバイス上に配置してもよい。」ことは，公知の技術事項といえる（以下，「公知事項２」という。）。
ウ　対比・判断
　補正後の発明と引用発明とを対比すると，
（ア）補正後の発明の「プライベートネットワーク」，「外部のクライアントコンピュータ」，「第１のプライベートネットワークリソース」と，引用発明の「プライベート・ネットワーク」，「外部の端末５」，「サーバ」とは，表現が異なるのみであり，実質的な差異は無い。
　また，引用発明の外部の端末５からのプライベート・ネットワークに接続されているサーバへのアクセスを「リモートアクセス」と称することは任意である。
　また，引用発明のルータ２は，インターネットとプライベート・ネットワーク間の中継手段であり，引用例の【００２２】の記載（上記イ［引用発明］（ア）参照。）に照らせば，プライベート・ネットワークのリソースといえるサーバＡ３，サーバＢ４は「ルータ配下の端末」であるから，ルータ２もプライベート・ネットワークに含まれると解するのが自然である。そうすると，ルータ２は，プライベート・ネットワークにおいてはエッジリソースといえる。したがって，補正後の発明の「前記プライベートネットワークはエッジリソースを含む」及び「前記プライベートネットワークの前記エッジリソース」と，引用発明の「インターネットとプライベート・ネットワーク間の中継手段としてルータ２を備える」及び「前記ルータ２」とは，実質的な差異は無い。
（イ）上記（ア）のとおりであるから，引用発明の「サーバのローカルＩＰアドレス」は，補正後の発明の「第１のプライベートネットワークリソースのインターネットプロトコル（ＩＰ）アドレス」に相当する。
　また，引用発明の「ＨＴＴＰリクエストヘッダ」は，ＨＴＴＰリクエストヘッダに収めた情報としてホスト名を含んでおり，当該ホスト名は，サーバに関連する識別子といえ，それによりプライベート・ネットワーク上でサーバのローカルＩＰアドレスに解決可能であり，また，それによりプライベート・ネットワークの外部でルータ２のグローバルＩＰアドレスに解決可能である。したがって，引用発明の「ＨＴＴＰリクエストヘッダに収めた情報」である「ホスト名」は，補正後の発明の「前記第１のプライベートネットワークリソースに関連する識別子」に相当する。
　引用発明の「ＨＴＴＰリクエスト」を「第１の通信」と称することは任意である。
（ウ）引用発明において「ホスト名フォワーディングテーブルから前記サーバの前記ローカルＩＰアドレスを取り出す」ことは，アドレス変換する側からみれば，ホスト名フォワーディングテーブルからサーバのローカルＩＰアドレスを受け取ることといえる。
　そして，引用発明の「ホスト名フォワーディングテーブル」は，引用例の図１等を参酌すればルータ２内にあると認められるが，「前記サーバの前記ローカルＩＰアドレス」（補正後の発明の「前記第１のプライベートネットワークリソースの前記ＩＰアドレス」に相当。）の受け取り先である点で，補正後の発明の「前記第１のプライベートネットワークリソース及び前記エッジリソースとは異なる第２のプライベートネットワークリソース」に対応する。
　したがって，補正後の発明と引用発明とは，「前記第１のプライベートネットワークリソースの前記ＩＰアドレス」の受け取り先の位置が異なる点は別として，「前記プライベートネットワーク上で，前記第１のプライベートネットワークリソースに関連する前記識別子を前記第１のプライベートネットワークリソースの前記ＩＰアドレスに解決するステップであって，所定の手段から前記第１のプライベートネットワークリソースの前記ＩＰアドレスを受け取るステップを含む，ステップ」の点で一致している。
（エ）上記（ア）〜（ウ）のとおりであるから，　引用発明の「前記ＨＴＴＰリクエストを前サーバに伝送するステップ」は，補正後の発明の「前記第１の通信を前記第１のプライベートネットワークリソースに伝送するステップ」に相当する。
　以上を総合すると，補正後の発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「プライベートネットワークの外部のクライアントコンピュータから，前記プライベートネットワークに接続され，第１のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって，前記プライベートネットワークはエッジリソースを含む方法において，
　（Ａ）前記プライベートネットワークの前記エッジリソースにおいて，クライアントコンピュータから，前記第１のプライベートネットワークリソースに関連する識別子を含む第１の通信を受信するステップであって，前記識別子が，前記プライベートネットワーク上で前記第１のプライベートネットワークリソースのインターネットプロトコル（ＩＰ）アドレスに解決可能であり，かつ，前記識別子は前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である，ステップと，
　（Ｂ）前記プライベートネットワーク上で，前記第１のプライベートネットワークリソースに関連する前記識別子を前記第１のプライベートネットワークリソースの前記ＩＰアドレスに解決するステップであって，所定の手段から前記第１のプライベートネットワークリソースの前記ＩＰアドレスを受け取るステップを含む，ステップ
　（Ｃ）前記第１の通信を前記第１のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」
（相違点１）
　一致点の「第１のプライベートネットワークリソース」に関し，補正後の発明は，「プライベートドメイン名に関連づけられている」のに対し，引用発明は，ホスト名に関連づけられているものの，当該構成が明らかでない点。
（相違点２）　
　一致点の「前記識別子は前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である」に関して，本願発明は「前記識別子が前記プライベートドメイン名に関する場合に，」との条件が存在するのに対して，引用発明には当該条件が明らかにされていない点。
（相違点３）
　一致点の「所定の手段」に関し，補正後の発明は「前記第１のプライベートネットワークリソース及び前記エッジリソースとは異なる第２のプライベートネットワークリソース」であるのに対し，引用発明の「ホスト名フォワーディングテーブル」はルータ２内のものである点。
　以下，上記各相違点について検討する。
（相違点１について）
　本件明細書の発明の詳細な説明の【０００６】〜【０００８】，【００２３】，【００２４】，【００４２】，【００４７】，【００６０】，【００６６】〜【００７１】等を参酌すると，プライベートドメイン名は，プライベートネットワーク１０６の外部では使用できない，すなわち，公的に解決可能ではない，例えば「ｈｒｗｅｂ」（人事（ＨＲ）部のイントラネットウェブサイトをホストするウェブサーバのドメイン名）等を含むものであり，ウェブサーバ１０２等のプライベートネットワークリソースに関連付けることができるものである。そして，プライベートドメイン名と例えば「ｒｅｍｏｔｅａｃｃｅｓｓ．ｃｏｒｐｏｒａｔｅ．ｃｏｍ」等のサフィックスとを使用して形成される完全修飾ドメイン名（ｈｒｗｅｂ．ｒｅｍｏｔｅａｃｃｅｓｓ．ｃｏｒｐｏｒａｔｅ．ｃｏｍ）により，公的に解決可能となるものである。したがって，補正後の発明の「プライベートドメイン名」は，完全修飾ドメイン名の内の最も左の部分である，ホストに付けられた名前等を含むものと認められる。
　一方，引用発明の「ホスト名」は，サーバＡ３のホスト名として「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」が例示されており，当該「ホスト名」中の最も左の部分である「ＳｅｒｖｅｒＡ」は「サーバＡ３」を意味することは明らかである。また，「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」はインターネット１に接続されるＤＮＳ７により解決可能であるが，「ＳｅｒｖｅｒＡ」のみではＤＮＳ７により解決可能でないことは明らかである。してみると，「サーバＡ３」は，完全修飾ドメイン名といえるホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」の内の最も左の部分であり，それのみでは公的に解決可能ではない「ＳｅｒｖｅｒＡ」に関連づけられているといえる。
　更にいえば，請求項１には名前解決の構成は明らかにされておらず，請求項１の記載からは，補正後の発明の「プライベートドメイン名」が，プライベートネットワーク内ではそれのみにより解決可能であることは読み取れないが，仮にそうであるとしても，ネットワークシステムの名前解決は階層的に為されることに鑑みれば，プライベートネットワーク内では名前解決に上位レベルのドメイン名が必要でないことは明らかである。また，公知事項１のとおり，プライベートネットワーク内のリソースの名前による問い合わせに対して，プライベートネットワーク名を加えて，プライベートネットワーク内で名前解決することは公知の技術事項である。したがって，仮に補正後の発明の「プライベートドメイン名」が，プライベートネットワーク内ではそれのみにより解決可能であるものだとしても，それにより進歩性が生じるものではない。
　したがって，相違点１には実質的な相違はない，あるいは，当業者が容易になし得ることに過ぎない。
（相違点２について）
　引用発明は，サーバＡ３を意味する「ＳｅｒｖｅｒＡ」を含むホスト名「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」が，プライベート・ネットワークの外部ではルータ２のグローバルＩＰアドレスに解決可能であるから，「前記識別子は前記プライベートネットワークの外部で前記エッジリソースのＩＰアドレスに解決可能である」とする条件として「前記識別子が前記プライベートドメイン名に関する場合に，」とすることは，引用発明に対して何ら相違をもたらすものではない。したがって，相違点２には実質的な相違はない。
（相違点３について）
　公知事項２のとおり，「プライベートにアドレスされたネットワークのアドレス解決をするため手段（ＤＨＣＰサーバ及び／又はＤＮＳサーバ）は，ゲートウェイに含んでもよいし，ゲートウェイとは異なるデバイス上に配置してもよい。」ことは公知の技術事項であるから，相違点３は，格別困難なことではなく，当業者が適宜選択し得ることにすぎない。
　そして，補正後の発明の作用効果も，引用発明及び公知の技術事項に基づいて当業者が予測できる範囲のものである。
　以上のとおり，補正後の発明は，引用発明及び公知の技術事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　なお，請求人は，平成２７年３月６日付け上申書にて，審査官が作成した前置報告書に対して，「上記にご指摘された内容を斟酌すると，審査官殿は，審判請求書の「請求の理由」において，出願人が挙げた本願の請求項１，１２に係る発明と，引用文献１−４との相違点を認めている。しかしながら，『本願の上記請求項には単に識別子がプライベートドメイン名に「関連する」ということが記載されているのみであるから，本願の上記請求項における「識別子」は，プライベートドメイン名と「関連する」という点で，引用文献１や引用文献３の「識別子」と差異はない。』旨ご指摘された。出願人は，本ご指摘に従って，本願の請求項１，１２に係る発明と引用文献との相違点をより明確にするよう，以下「４．補正案」に示すように補正をする用意があります。補正案をご検討いただきますようお願い申し上げます。」と述べ，「プライベートドメイン名に
関連づけられている
有する
である
　しかしながら，上記「（相違点１について）」にて述べたとおり，引用発明の「ホスト名」は，サーバＡ３のホスト名として「ＳｅｒｖｅｒＡ．ｓｅｒｖｅｒ．ｎｅｔ」が例示されており，当該ホスト名中の最も左の部分である「ＳｅｒｖｅｒＡ」は，サーバＡ３を意味し，また，それのみでは公的に解決可能ではないことは明らかであるから，「プライベートドメイン名」に含まれるものである。そして，「ＳｅｒｖｅｒＡ」がサーバＡ３を意味する以上，「第１のプライベートネットワークリソース」に相当するサーバＡ３は「プライベートドメイン名を有する」といえる。
　また，公知例の記載（上記イ［公知の技術事項］（ウ），（エ）参照。）によれば，プライベートネットワーク内のリソースの名前（例えば「ｃｕｂｅ」）による問い合わせに対して，ネットワークの名前を加えて，名前解決することは公知の技術事項であるから，「前記識別子が前記プライベートドメイン名である」ようにすることも格別困難なことではない。このため，上記補正案によっても補正後の発明に進歩性を認めることはできない。
３　結語
　したがって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成２６年５月７日付けの手続補正は上記のとおり却下されたので，本願発明は，上記「第２　補正却下の決定」の項中の「１　本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。
２　引用発明
　引用発明及び公知の技術事項は，上記「第２　補正却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件」の項中の「イ　引用発明及び公知の技術事項」の項で認定したとおりである。
３　対比・判断
　そこで，本願発明と引用発明とを対比するに，本願発明は補正後の発明から当該補正に係る限定を省いたものである。
　そうすると，本願発明の構成に当該補正に係る限定を付加した補正後の発明が，上記「第２　補正却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件」の項中の「ウ　対比・判断」の項で検討したとおり，引用発明及び公知の技術事項に基づいて容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
４　むすび
　以上のとおり，本願発明は，引用発明及び公知の技術事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。