• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
管理番号 1307327
審判番号 不服2014-8304  
総通号数 192 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-12-25 
種別 拒絶査定不服の審決 
審判請求日 2014-05-07 
確定日 2015-11-04 
事件の表示 特願2011-547928「ネットワークの外部からのプライベートネットワークリソースへのリモートアクセス」拒絶査定不服審判事件〔平成22年 8月12日国際公開,WO2010/090674,平成24年 7月12日国内公表,特表2012-516112〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯
本願は,2009年12月4日(パリ条約による優先権主張外国庁受理 2009年1月20日 米国)を国際出願日とする出願であって,平成26年1月6日付けで拒絶査定がなされ,これに対し,同年5月7日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。その後,同年6月17日付けで審査官により作成された前置報告書に対して,同年6月25日付け上申書及び平成27年3月6日付け上申書が提出された。


第2 補正却下の決定
[結論]
平成26年5月7日付けの手続補正を却下する。

[理由]
1 本願発明と補正後の発明
平成26年5月7日付けの手続補正(以下,「本件補正」という。)は,平成25年12月6日付け手続補正書により補正された特許請求の範囲の請求項1に記載された
「【請求項1】
プライベートネットワークの外部のクライアントコンピュータから,前記プライベートネットワークに接続される第1のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって,前記プライベートネットワークはエッジリソースを含む方法において,
(A)前記プライベートネットワークの前記エッジリソースにおいて,クライアントコンピュータから,前記第1のプライベートネットワークリソースに関連する識別子を含む第1の通信を受信するステップであって,前記識別子が,前記プライベートネットワーク上で前記第1のプライベートネットワークリソースのインターネットプロトコル(IP)アドレスに解決可能,かつ,前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である,ステップと,
(B)前記プライベートネットワーク上で,前記第1のプライベートネットワークリソースに関連する前記識別子を前記第1のプライベートネットワークリソースの前記IPアドレスに解決するステップであって,前記第1のプライベートネットワークリソース及び前記エッジリソースとは異なる第2のプライベートネットワークリソースから前記第1のプライベートネットワークリソースの前記IPアドレスを受け取るステップを含む,ステップと,
(C)前記第1の通信を前記第1のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」
という発明(以下,「本願発明」という。)を,
「【請求項1】
プライベートネットワークの外部のクライアントコンピュータから,前記プライベートネットワークに接続され,プライベートドメイン名に関連づけられている第1のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって,前記プライベートネットワークはエッジリソースを含む方法において,
(A)前記プライベートネットワークの前記エッジリソースにおいて,クライアントコンピュータから,前記第1のプライベートネットワークリソースに関連する識別子を含む第1の通信を受信するステップであって,前記識別子が,前記プライベートネットワーク上で前記第1のプライベートネットワークリソースのインターネットプロトコル(IP)アドレスに解決可能であり,かつ,前記識別子が前記プライベートドメイン名に関する場合に,前記識別子は前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である,ステップと,
(B)前記プライベートネットワーク上で,前記第1のプライベートネットワークリソースに関連する前記識別子を前記第1のプライベートネットワークリソースの前記IPアドレスに解決するステップであって,前記第1のプライベートネットワークリソース及び前記エッジリソースとは異なる第2のプライベートネットワークリソースから前記第1のプライベートネットワークリソースの前記IPアドレスを受け取るステップを含む,ステップと,
(C)前記第1の通信を前記第1のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」
という発明(以下,「補正後の発明」という。)に変更することを含むものである。

2 補正の適否
(1)新規事項の有無,シフト補正の有無,補正の目的要件
上記補正は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内において,本願発明の「第1のプライベートネットワークリソース」を「プライベートドメイン名に関連づけられている第1のプライベートネットワークリソース」に限定するとともに,本願発明の「かつ,前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である」を「かつ,前記識別子が前記プライベートドメイン名に関する場合に,前記識別子は前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である」に限定して,特許請求の範囲を減縮するものである。
この他,本件補正として,請求項7についての補正は,本件補正前の「前記クライアント」を「前記クライアントコンピュータ」に限定して,特許請求の範囲を減縮するものである。また,請求項12についての補正は,請求項1についての上記補正と同様である。
したがって,本件補正は,特許法第17条の2第3項及び第4項の規定に適合することは明らかであり,また,同法第17条の2第5項第2号に掲げる特許請求の範囲の減縮を目的とするものに該当する。

(2)独立特許要件
請求項1についての上記補正は,特許請求の範囲の減縮を目的とするものであるから,補正後の発明が特許出願の際独立して特許を受けることができるものであるのか否かについて,以下検討する。

ア 補正後の発明
補正後の発明は,上記「1 本願発明と補正後の発明」の項の「補正後の発明」のとおりのものと認める。

イ 引用発明及び公知の技術事項
[引用発明]
原査定の拒絶の理由に引用された特開2004-120534号公報(以下,「引用例」という。)には,「ルータと中継装置,フォワーディング方法」に関し,図面とともに以下の事項が記載されている。

(ア)「【0001】
【発明の属する技術分野】
本発明は,ブラウザから付加されるホスト名によってフォワーディングするためのローカルIPアドレスを決定するルータ,ネットワーク間を中継する中継装置と,及びホスト名によってフォワーディングするフォワーディング方法に関するものである。
【0002】
【従来の技術】
インターネット等の広域ネットワークへ常時接続するためADSL,CATVの普及が本格化し,ブロードバンドルータの普及も著しい。図8は従来のホストネームフォワーディング機能をもつルータの構成図,図9は従来のポートフォワーディング設定テーブルの説明図である。図8,9において,101はインターネット,102はLAN側のポートを複数備えたルータ,103はポート番号「80」でローカルIPアドレス「192.168.0.253」のサーバA,104はポート番号「81」でローカルIPアドレス「192.168.0.254」のサーバBである。このようにルータ102は,WAN側のポートをインターネット101,またLAN側のポートにサーバA103,サーバB104等の複数のユーザ機器を接続するものが主流である。
【0003】
ところで,現行のIPプロトコルIPｖ4ではグローバルIPアドレスの絶対数が不足しているため,NAT(Neｔｗｏｒk Addｒeｓｓ Tｒanｓlaｔiｏn)機能やポートフォワーディング機能(静的IPマスカレード)などを使用してグローバルIPアドレスの不足に対応している。このNAT機能は,LAN側の機器からインターネット101へアクセスするときには,そのローカルIPアドレスをルータ102のWAN側のグローバルIPアドレスへ変換するものである。
【0004】
また,インターネット101からLAN側の特定の機器へアクセスする場合は,ルータ102のポートフォワーディング機能(静的IPマスカレード機能)を用いることでアクセスが可能になる。すなわち,これにはまず予め,図9のようにルータ102にポート番号とローカルアドレスの変換テーブルを設定しておく必要がある。インターネット101からアクセスするときには,ルータ102のグローバルIPアドレスとポート番号を指定する。このアクセスを受け付けたルータ102は予め設定された変換テーブルに従い,グローバルIPアドレスをプライベートIPアドレスへの変換を行う。この変換によりインターネット101からローカルIPアドレスをもったLAN内の一つの機器にアクセスすることが可能となる。
【0005】
例えば,図8に示したルータ102のLAN側に接続したサーバA103,サーバB104にアクセスする場合,まず,上述したようなポートフォワーディング設定を予めルータ102に対して行っておく。続いて,インターネット101からサーバA103にアクセスする場合には「hｔｔｐ://ｓeｒｖeｒA.ｓeｒｖeｒ.neｔ:80/」と指定する。同様に,インターネット101からサーバB104にアクセスする場合は「hｔｔｐ://ｓeｒｖeｒA.ｓeｒｖeｒ.neｔ:81/」と指定する。これにより,図示しないインターネット101上のDNSサーバによって,ルータ102のグローバルIPアドレスに変換され,ルータへのアクセスが可能となる。ルータは変換テーブルに従いポート「80」,「81」へのアクセスをローカルアドレス「192.168.0.253」,「192.168.0.254」へフォワードすることによりサーバA103,B103へのアクセスが可能になる。なお,このようにポートフォワーディング機能によりインターネット101からサーバA103,サーバB104にアクセスするには各サーバに割り当てるポート番号が重複しないように番号を割り当てる必要がある。
【0006】
このように従来のルータ102は,ポートフォワーディング機能,NAT機能によりグローバルIPアドレスの枯渇を緩和し,複数のユーザ機器とインターネットとを接続したが,ユーザはLAN側の機器のポート番号を知って,その変更をフォローしなければならなかった。そこで,ディレクトリーを使い,グローバルIPアドレスによる管理端末とプライベートIPアドレスによる管理端末間の1対1の相互通信を可能とする通信ネットワークシステムが提案された(特許文献1を参照)。
【0007】
これは,インターネット等の公衆通信網と,プライベート・ネットワーク間に中継手段を設け,中継手段が,プライベート・ネットワークに接続された端末の識別子をディレクトリー(特許文献1ではサブアドレス)として識別して,外部からのアクセス要求をプライベート・アドレス空間で割り振られた個々の端末に接続することを可能としたものである。また,本構成と,NAT,IPマスカレード等の手法とを併用することにより,グローバルIPアドレスによって管理されているインターネットにおける端末と,プライベートIPアドレスによって管理されているプライベート・ネットワークの端末間での1対1の相互通信が可能にするものである。
【0008】
現在,グローバルIPアドレスは固定ではなく,DHCPサーバによって割り当てられることがほとんどである。従って次々と更新されるグローバルIPアドレスをホスト名に対応させるDDNSサーバがなければ,ホスト名によるアクセスはできない。(特許文献1)のシステムは,ディレクトリーを識別子として使うため,ディレクトリーが異なる端末の認識が行えるのは同一のDDNSサーバにホスト名が登録されている場合だけである。従って,このシステムではプライベート・ネットワーク内にDDNSサーバが設けられていなければならない。
【0009】
【特許文献1】
特開2001-345841号公報
【0010】
【発明が解決しようとする課題】
以上説明したように従来のルータのポートフォワーディング機能(静的IPマスカレード機能)は,LAN側の機器をポート番号を用いてアクセスできるものであるが,インターネット側のユーザはLAN側の機器のポート番号を知っておく必要があり,LAN側のシステム変更のためポート番号の変更があった場合,その変更を常にフォローしなければならなかった。
【0011】
一方,(特許文献1)のシステムは,ポート番号を用いずにLAN側の機器にアクセス可能であるものの,ディレクトリーを識別子として使うため,ホスト名に加え更に続けてディレクトリーを入力する必要があり,またホスト名自体は同一もののにならざるを得えず,LAN側に複数の機器がある場合にそれぞれ異なるホスト名を付与することができない。
【0012】
加えて,(特許文献1)では,ディレクトリー構造を使用しているため,例えば,「hｔｔｐ ://ｗｗｗ.caｒｒieｒ.ne.jｐ/ab001/indeｘ.hｔml」というアクセスを許可する場合,ルータ(中継手段)配下の端末は,「ab001/indeｘ.hｔml」のファイルの要求があったと認識し,ディレクトリab001からindeｘ.hｔmlを取出して,アクセス元に送信することになるため,この端末にも同じ構造でディレクトリー「ab001」を作る必要がある。言い換えれば,「ab001」のディレクトリーの中に「indeｘ.hｔml」というウェブページを端末に配置する必要がある。しかし市販されている端末にはディレクトリーを変更できないものが相当数存在し,この構造を採用して通信することはできない。そして,この問題を回避するために,ブラウザから端末への転送時にHTTPメッセージに含まれる上記したURIのうち「ab001」を取り除く処理が必要であり,また端末側からブラウザへの転送時には,逆に「ab001」をHTTPメッセージに付加する処理が必要となる。このような処理(アプリケーション層のデータの変換処理)はきわめて複雑であり,転送速度が低下することになる。
【0013】
そこで本発明は,複数の端末に対してそれぞれホスト名でアクセスでき,グローバルIPアドレスの更新があってもアクセス可能で,複数の端末間で共通のディレクトリーを使うことができるルータを提供することを目的とする。
【0014】
また本発明は,複数の端末に対してそれぞれホスト名でアクセスでき,グローバルIPアドレスの更新があってもアクセス可能で,複数の端末間で共通のディレクトリーを使うことができるフォワーディング方法を提供することを目的とする。」(2?4ページ)

(イ)「【0022】
(実施の形態1)
本発明の実施の形態1におけるホスト名によるフォワーディングを行うルータを配置したネットワークシステムについて説明する。図1は本発明の実施の形態1におけるルータ配下の端末にアクセスするネットワークシステムの構成図,図2はホスト名フォワーディングテーブルの説明図,図3は本発明の実施の形態1におけるルータによるホスト名検出の説明図,図4はHTTPリクエストヘッダの説明図,図5は本発明の実施の形態1におけるルータを配置したシステムでアクセスするときのシーケンスチャートである。
【0023】
1はインターネット(本発明の広域ネットワーク),2はインターネット1と接続可能なインターフェイスを有し,LAN側のポートを複数備えて配下の各機器,後述するサーバA3,サーバB4に対してインターネット1との間でルーティングを行うルータ(中継装置),2aはルータ2に設けられ,インターネット1から受信したIPパケット(データパケット)のHTTPヘッダからホスト名を取り出すホスト名検出手段,2bはホスト名検出手段2aにより取出したホスト名が後述する変換テーブル2cのホスト名と一致するか否かを判断し,一致するホスト名があればそのホスト名に対応するローカルIPアドレスを変換テーブル2cから取出し,更に受信したIPパケットの宛先アドレスを取出したローカルIPアドレスに置き換えて,LAN側へ送信するアドレス変換手段,2cはアドレス変換手段2bがホスト名をローカルIPアドレスに変換するために参照するホスト名フォワーディングテーブル(本発明の変換テーブル)である。ルータ2は実施の形態1の場合ブロードバンドルータである。
【0024】
3はポート番号「80」でホスト名「ｓeｒｖeｒA.ｓeｒｖeｒ.neｔ」のサーバA,4はポート番号「80」でホスト名「ｓeｒｖeｒB.ｓeｒｖeｒ.neｔ」のサーバBである。なお,これらのホスト名は後述のDDNSサーバ8により管理されている。5はインターネット1に接続してサーバA3,サーバB4にアクセスできる端末,6は所定のグローバルIPアドレスの中から端末5にグローバルIPアドレスを割り当てるDHCP(Dｙnamic Hｏｓｔ Cｏnfigｕｒaｔiｏn Pｒｏｔｏcｏl)サーバ,7はホスト名でアクセスするとグローバルIPアドレスを応答するDNS(Dｏmain Name Sｙｓｔem)サーバ,8はDHCPサーバ6が決定したグローバルIPアドレスとホスト名との対応をつけるDDNS(Dｙnamic Dｏmain Name Sｙｓｔem)サーバである。
【0025】
本実施の形態1のルータ2は,図3に示すように端末5のブラウザからインターネット1を介してサーバA3(若しくはサーバB4)にHTTPリクエストを送信すると,ホスト名検出手段2aによりサーバA3(若しくはサーバB4)のホスト名をIPパケットのHTTPリクエストヘッダから取り出し,アドレス変換手段2bによってローカルIPアドレスに変換して,端末5から受信したIPパケットを変換したローカルIPアドレスのサーバA3(若しくはサーバB4)にルーティングするものである。図3においては,後述するようにグローバルIPアドレス「1.1.1.1」を宛先IPアドレスに収め,ホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をHTTPリクエストヘッダに収めたHTTPリクエストがサーバA3に向けて送信され,ルータ2がルーティングを行う。
【0026】
すなわち,図4に示すようにHTTPリクエストでサーバA3にリクエストするときは,メソッド「GET」の後にURIとバージョン情報「HTTP1.0」,「Hｏｓｔ」の後にホスト名,最後に「CRLF」行を書き込んで,サーバA3からファイルを要求する。このようにHTTPリクエストヘッダの要求行にはホスト名が自動的に書き込まれるから,これをホスト名検出手段2aが取り出し,アドレス変換手段2bがローカルIPアドレスに変換するものである。
【0027】
そこで,サーバA3に対するHTTPリクエストとそのレスポンスが行われる一連の基本的な処理に関して,図5のシーケンスチャートに基づいてルータの説明を行う。まず,図5のS1において,ルータ2からDHCPサーバ6にグローバルIPアドレスを要求して,DHCPサーバ6がグローバルIPアドレス「1.1.1.1」をルータ2に制限時間付きで割り当てる。ルータ2はこのグローバルIPアドレス「1.1.1.1」とサーバA3のホスト名をDDNSサーバ8に通知する。さらに,ルータ2はこのグローバルIPアドレス「1.1.1.1」とサーバB4のホスト名をDDNSサーバ8に通知する。なお,ルータ2はホスト名による変換モードのモード設定ができる。また,ここでは,ルータ2がDDNS設定要求を行うようにしたが,ルータ2に代えてサーバA3やサーバB4が各々ルータ2に対しDDNS設定要求を行うようにしてもよい。S2において,サーバA3はDDNSサーバ8に更新要求する。DDNSサーバ8にはS3で,端末5のブラウザを用いて「hｔｔｐ://SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をURIに指定し,DNSサーバ7にグローバルIPアドレスを問い合わせると,DNSサーバ7はDDNSサーバ8に問い合わせる。S4においてDDNSサーバ8は,「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」に対応するグローバルIPアドレス「1.1.1.1」を回答し,DNSサーバ7が端末5に回答する。
【0028】
このルータ2のグローバルIPアドレス「1.1.1.1」を受け取った端末5はLAN内にあるサーバA3に対してHTTPによるアクセスを発生し,S5においてグローバルIPアドレス「1.1.1.1」を宛先IPアドレス,宛先ポート番号に「80」を収めて,図4のようなHTTPヘッダをデータ域にセットしたIPパケットをインターネット1に送信する。なお,ポート番号は従来のポートフォワーディング機能と異なり,サーバA3,サーバB4ともに共通の「80」を設定することができる。
【0029】
IPパケットがルータ2に到着しルータ2が受信する(S6)。ルータ2は図示しないルーティングテーブルを参照して,ホスト名から配下のサーバA3であることを知り,ローカルIPアドレスに変換してHTTPリクエストをサーバA3に転送する。図6は本発明の実施の形態1におけるルータの処理のフローチャートである。図6に示すようにルータがIPパケットを受信すると(S61),ホスト名による変換モードか否かがチェックされる(S62)。変換モードの場合,IPパケットからHTTPヘッダに含まれるホスト名を取り出し(S63),変換モードでない場合には宛先ポート番号に従って処理(ポートフォワーディング機能等)を行う(S66)。
【0030】
ホスト名を取り出すと,変換テーブルを読み出し(S64),取り出したホスト名が変換テーブルに存在するか否かをチェックする(S65)。なおルータ2には,図2に示すようなホスト名とLAN側のローカルIPアドレスの対応を記述した変換テーブルが予め設定してある。本実施の形態1の場合は,各グローバルIPアドレスもこれらに関係付けられている。ホスト名が変換テーブルにあった場合,変換テーブルから対応するローカルIPアドレスを取り出し(S68),ホスト名が変換テーブルになかった場合にはS66に進んで,宛先ポート番号に従って処理する。S67において,受信したIPパケットのIPヘッダの宛先IPアドレスを取出したローカルIPアドレスへ置き換え,IPパケットをHTTPリクエストとしてLANに送信する。図2の変換テーブルによれば,ホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」にはローカルIPアドレス「192.168.0.253」,ホスト名「SeｒｖeｒB.ｓeｒｖeｒ.neｔ」にはローカルIPアドレス「192.168.0.254」が対応づけられているため,S6でルータ2はホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をローカルIPアドレス「192.168.0.253」に変換し,その後,宛先IPアドレスに「192.168.0.253」をセットしたHTTPリクエストがサーバA3に送信されることになる。
【0031】
次いで,S7でサーバA3は端末5に向けてレスポンスを送信する。送信元IPアドレスに「192.168.0.253」をセットしたパケットを送信すると,ルータ2がこれを受け取る。S8において,ルータ2は端末5に向けたレスポンスであることを認識し,図示しないルーティングテーブルを参照して,送信元IPアドレスに「1.1.1.1」をセットしてIPパケットを送信し,端末5のブラウザが受信する。これにより,インターネット1を介してのLAN内のサーバA3等の機器への通信が可能となる。
【0032】
このように本発明の実施の形態1のルータは,HTTPリクエストヘッダに記載されたホスト名を取り出してローカルIPアドレスに変換するから,複数のサーバA,Bに対してそれぞれドメイン名を含んで通常通りホスト名でアクセスでき,DHCPサーバの使用によりDDNSサーバでグローバルIPアドレスの更新が次々とあっても,これに影響されることなくアクセスが可能である。また,複数のサーバA,B間で共通名のディレクトリーを使うことができる。
【0033】
そして実施の形態1のルータは,ブラウザから送信されるIPパケットのうち,アプリケーション層のデータを変換処理することなく,単に宛先IPアドレスを変更するだけでよく,きわめて簡単な構成で通信できる。すなわち,クライアント側は,ホスト名のみでルータ配下の端末を直接アクセスできる。HTTPヘッダを変更したり,サーバ側でディレクトリーの構造を採用して対応する必要がない。」(5?8ページ)

上記記載及び図面並びに当業者の技術常識を考慮すると,
a 上記(ア)の【0004】?【0008】の記載及び図8,9によれば,ルータ102は,インターネット等の公衆通信網と,プライベート・ネットワーク間の中継手段といえ,中継手段であるルータ102が,プライベート・ネットワークの外部であるインターネット101からプライベート・ネットワークに接続された端末であるサーバA103,サーバB104へのアクセス要求を可能とするものといえる。そして,図1,図2は,図8,図9に記載された従来例の課題(【0013】,【0014】)を解決するための構成であって,図8,図9と前提となる構成は同じと解されるから,ルータ2は,プライベート・ネットワークの外部の端末5から,前記プライベート・ネットワークに接続されている端末であるサーバA3,サーバB4へのアクセス要求を可能とするものといえる。
また,上記(ア)の【0004】の記載によれば,ローカルIPアドレスはプライベートIPアドレスと同義と認められ,また,上記(ア)の【0013】,上記(イ)の【0029】,【0030】の記載及び図2によれば,ローカルIPアドレスはホスト名に対応付けられているから,サーバA103,サーバB104はホスト名に関連付けられていることは明らかである。
したがって,引用例には,「プライベート・ネットワークの外部の端末5から,前記プライベート・ネットワークに接続され,ホスト名に関連づけられているサーバへのアクセスを可能にするための方法であって,インターネットとプライベート・ネットワーク間の中継手段としてルータ2を備える方法」が記載されていると認められる。

b 上記(イ)の【0025】?【0028】の記載及び図4,図5によれば,端末5のブラウザからインターネット1を介して,ホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をHTTPリクエストヘッダに収めたHTTPリクエストが,サーバA3(若しくはサーバB4)に向けて送信され,ルータ2がルーティングを行うものである。したがって,ルータ2において,端末5から,HTTPリクエストヘッダを含むHTTPリクエストを受信するといえる。
そして,上記(イ)の【0023】,【0029】?【0030】の記載及び図5,図6によれば,IPパケットがルータ2に到着しルータ2が受信すると,ルータ2はホスト名を取り出し,変換テーブルであるホスト名フォワーディングテーブルを読み出して,取り出したホスト名が図2に示すような変換テーブルに存在するか否かをチェックし,ホスト名から配下のサーバA3であることを知り,変換テーブルによりホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をローカルIPアドレス「192.168.0.253」に変換し,宛先IPアドレスにローカルIPアドレス「192.168.0.253」をセットしたHTTPリクエストがサーバA3に送信される。したがって,HTTPリクエストヘッダに収めた情報であるホスト名が,プライベート・ネットワーク上でサーバのローカルIPアドレスに解決可能であるといえる。
ここで,上記(イ)の【0030】の記載及び図2によれば,変換テーブルには,ホスト名とLAN側のローカルIPアドレスと各グローバルIPアドレスとが関係付けられていると認められる。
また,上記(イ)の【0027】の記載及び図5によれば,DDNSサーバ8には,端末5のブラウザを用いて「hｔｔｐ://SeｒｖeｒA.ｓeｒｖeｒ.neｔ」をURIに指定し,DNSサーバ7にグローバルIPアドレスを問い合わせると,DNSサーバ7はDDNSサーバ8に問い合わせ,DDNSサーバ8はホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」に対応するグローバルIPアドレス「1.1.1.1」を回答し,DNSサーバ7が端末5に回答するものである。そして,DHCPサーバ6がグローバルIPアドレス「1.1.1.1」をルータ2に割り当てるから,グローバルIPアドレス「1.1.1.1」はルータ2のIPアドレスといえる。したがって,HTTPリクエストヘッダに収めた情報であるホスト名は,プライベート・ネットワークの外部でルータ2のグローバルIPアドレスに解決可能であるといえる。
以上より,引用例には,「前記ルータ2において,端末5から,前記HTTPリクエストヘッダを含むHTTPリクエストを受信するステップであって,前記HTTPリクエストヘッダに収めた情報であるホスト名が,前記プライベート・ネットワーク上で前記サーバのローカルIPアドレスに解決可能であり,かつ,前記HTTPリクエストヘッダに収めた情報は前記プライベート・ネットワークの外部で前記ルータ2のグローバルIPアドレスに解決可能である,ステップ」が記載されていると認められる。

c 上記bのとおりであるから,ルータは,プライベート・ネットワーク上で,サーバに関連するHTTPリクエストヘッダに収めた情報をサーバのローカルIPアドレスに解決しているといえ,当該解決に当たり,変換テーブルであるホスト名フォワーディングテーブルからサーバのローカルIPアドレスを取り出していることは明らかである。そして,HTTPリクエストをサーバに伝送していることも明らかである。
したがって,引用例には,「前記プライベート・ネットワーク上で,前記サーバに関連する前記HTTPリクエストヘッダに収めた情報を前記サーバの前記ローカルIPアドレスに解決するステップであって,ホスト名フォワーディングテーブルから前記サーバの前記ローカルIPアドレスを取り出すステップを含む,ステップ」及び「前記HTTPリクエストを前記サーバに伝送するステップ」が記載されていると認められる。

以上を総合すると,引用例には以下の発明(以下,「引用発明」という。)が記載されていると認める。
「プライベート・ネットワークの外部の端末5から,前記プライベート・ネットワークに接続され,ホスト名に関連づけられているサーバへのアクセスを可能にするための方法であって,インターネットとプライベート・ネットワーク間の中継手段としてルータ2を備える方法において,
前記ルータ2において,端末5から,前記HTTPリクエストヘッダを含むHTTPリクエストを受信するステップであって,前記HTTPリクエストヘッダに収めた情報であるホスト名が,前記プライベート・ネットワーク上で前記サーバのローカルIPアドレスに解決可能であり,かつ,前記HTTPリクエストヘッダに収めた情報は前記プライベート・ネットワークの外部で前記ルータ2のグローバルIPアドレスに解決可能である,ステップと,
前記プライベート・ネットワーク上で,前記サーバに関連する前記HTTPリクエストヘッダに収めた情報を前記サーバの前記ローカルIPアドレスに解決するステップであって,ホスト名フォワーディングテーブルから前記サーバの前記ローカルIPアドレスを取り出すステップを含む,ステップと,
前記HTTPリクエストを前記サーバに伝送するステップと
を含む方法。」

[公知の技術事項]
同じく原査定の拒絶の理由に引用された国際公開第2005/029877号(以下,「公知例」という。)には,「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.」(5ページ19?24行)
([当審仮訳]:
Webサーバ230及び240( 「cｕbe」及び「nｏiｚi」)は,それぞれ,名前(「cｕｖe.ｐｒiｖaｔe.aｒｐa」及び「nｏiｚi.ｐｒiｖaｔe.aｒｐa」) を生成するために,プライベートにアドレスされたネットワークの名前(「.ｐｒiｖaｔe.aｒｐa」)に追加される。より一般的には,プライベートにアドレスされたネットワークに接続されたデバイス又はホストの名前は,ローカルアドレスに翻訳された内部名を作成するため,プライベートにアドレスされたネットワークの名前に追加される。)

(エ)「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: .private, arpa =

External: . =
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. 」(8ページ28行?9ページ27行)
([当審仮訳]:
図5は,図3のステップ310及び320のさらなる詳細を示すフロー図である。ステップ510において,DHCPサーバは,内部ホスト/デバイスから,インターネットプロトコル(IP)アドレスの要求を受ける。要求は,内部ホスト/デバイスのプライベート名を含む。ステップ520で,DHCPサーバは,内部ホスト/デバイスにIPアドレスを提供する。ステップ530で,内部ホスト/デバイスに関するデータがDHCPデータ(例えば,DHCPリースファイル)から取り出され,ステップ540で,内部ホスト/デバイスの名前及びアドレスが,DNSサーバとそれに関連する割り当てられたサービスに登録される。次のように分離したホスト名とアドレスのペアは,内部及び外部の使用のために関連され登録されている。
内部: <ホスト名>.ｐｒiｖaｔe.aｒｐa = <アドレス>
外部: <ホスト名>. = <ゲートウェイのアドレス>
説明のみを目的として,内部及び外部の使用のために分離したホスト名とアドレスのペアの関連及び登録の例が,図2を参照して以下に与えられる。内部ホスト(Webサーバ)230は,DCHPサーバに,名前(「cｕbe」)を提供する。DHCPサーバは,内部ホスト230に,アドレス192.168.1.43を割り当てる。アドレス192.168.1.43は内部リクエストのために名前 「cｕbe.ｐｒiｖaｔe.aｒｐa」に関連付けられており,名前「cｕbe.aiden.eg.ｏｒg」は外部リクエストのためにアドレス203.213.140.43に関連付けられている。
図6は,図3のステップ330のさらなる詳細を示すフロー図である。ステップ610で,外部のホスト/デバイスからの内部ホスト/デバイスへの要求がDNSサーバによって受信される。ステップ620で,DNSサーバは,外部ホスト/デバイスに対して,内部ホスト/デバイスが接続されているプライベートにアドレスされたネットワークのゲートウェイのアドレスを返す。ステップ630で,外部ホスト/デバイスは,ポート80を介してグローバルゲートウェイアドレス203.213.140.43(HTTP)への接続を開く。ステップ640で,ゲートウェイは接続を受け付ける。ステップ650で,ゲートウェイは内部ホスト/デバイスに向けられている要求のヘッダーを調べ,内部ホスト名を取り出す。ステップ660で,ゲートウェイはホスト名を内部的に解決し,内部ホスト/デバイスのプライベートアドレスを取得し,ステップ670で,ゲートウェイは内部ホスト/デバイスへの接続をオープンし,外部ホスト/デバイスと内部ホスト/デバイスとの間の通信をプロキシする。通信は,ゲートウェイによって変更することができる。)

上記(ウ),(エ)の記載によれば,「プライベートネットワーク内のリソースの名前による問い合わせに対して,プライベートネットワーク名を加えて,プライベートネットワーク内で名前解決すること」ことは,公知の技術事項といえる(以下,「公知事項1」という。)。

(オ)「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. 」(7ページ15?28行)
([当審仮訳]:
図4a及び4bを参照すると,プライベートにアドレスされたネットワーク(図示せず)の内部にあるホストデバイス410は,プライベートにアドレスされたネットワークのゲートウェイ420に接続されている。ゲートウェイ420は,DHCPサーバ422,DNS424,及びプロキシサーバ426を含む。ゲートウェイ420は,DHCPサーバ422,DNSサーバ424,プロキシサーバ426としての機能を実現するために,別個のコンピュータシステムを含む。当業者によって理解されるように,DHCPサーバ422の機能は,DNSサーバ424,プロキシサーバ426は,1つまたは複数のコンピュータシステム上で実行するソフトウェアを用いて実施することができる。また,DHCPサーバ422及びDNSサーバ424は,ゲートウェイ420の一部を形成する必要はなく,DHCPサーバ422及びDNSサーバ424のいずれか又は双方は,ゲートウェイ420とは異なるデバイス上に配置することができる。)

上記(オ)の記載によれば,「プライベートにアドレスされたネットワークのアドレス解決をするため手段(DHCPサーバ及び/又はDNSサーバ)は,ゲートウェイに含んでもよいし,ゲートウェイとは異なるデバイス上に配置してもよい。」ことは,公知の技術事項といえる(以下,「公知事項2」という。)。

ウ 対比・判断
補正後の発明と引用発明とを対比すると,
(ア)補正後の発明の「プライベートネットワーク」,「外部のクライアントコンピュータ」,「第1のプライベートネットワークリソース」と,引用発明の「プライベート・ネットワーク」,「外部の端末5」,「サーバ」とは,表現が異なるのみであり,実質的な差異は無い。
また,引用発明の外部の端末5からのプライベート・ネットワークに接続されているサーバへのアクセスを「リモートアクセス」と称することは任意である。
また,引用発明のルータ2は,インターネットとプライベート・ネットワーク間の中継手段であり,引用例の【0022】の記載(上記イ[引用発明](ア)参照。)に照らせば,プライベート・ネットワークのリソースといえるサーバA3,サーバB4は「ルータ配下の端末」であるから,ルータ2もプライベート・ネットワークに含まれると解するのが自然である。そうすると,ルータ2は,プライベート・ネットワークにおいてはエッジリソースといえる。したがって,補正後の発明の「前記プライベートネットワークはエッジリソースを含む」及び「前記プライベートネットワークの前記エッジリソース」と,引用発明の「インターネットとプライベート・ネットワーク間の中継手段としてルータ2を備える」及び「前記ルータ2」とは,実質的な差異は無い。

(イ)上記(ア)のとおりであるから,引用発明の「サーバのローカルIPアドレス」は,補正後の発明の「第1のプライベートネットワークリソースのインターネットプロトコル(IP)アドレス」に相当する。
また,引用発明の「HTTPリクエストヘッダ」は,HTTPリクエストヘッダに収めた情報としてホスト名を含んでおり,当該ホスト名は,サーバに関連する識別子といえ,それによりプライベート・ネットワーク上でサーバのローカルIPアドレスに解決可能であり,また,それによりプライベート・ネットワークの外部でルータ2のグローバルIPアドレスに解決可能である。したがって,引用発明の「HTTPリクエストヘッダに収めた情報」である「ホスト名」は,補正後の発明の「前記第1のプライベートネットワークリソースに関連する識別子」に相当する。
引用発明の「HTTPリクエスト」を「第1の通信」と称することは任意である。

(ウ)引用発明において「ホスト名フォワーディングテーブルから前記サーバの前記ローカルIPアドレスを取り出す」ことは,アドレス変換する側からみれば,ホスト名フォワーディングテーブルからサーバのローカルIPアドレスを受け取ることといえる。
そして,引用発明の「ホスト名フォワーディングテーブル」は,引用例の図1等を参酌すればルータ2内にあると認められるが,「前記サーバの前記ローカルIPアドレス」(補正後の発明の「前記第1のプライベートネットワークリソースの前記IPアドレス」に相当。)の受け取り先である点で,補正後の発明の「前記第1のプライベートネットワークリソース及び前記エッジリソースとは異なる第2のプライベートネットワークリソース」に対応する。
したがって,補正後の発明と引用発明とは,「前記第1のプライベートネットワークリソースの前記IPアドレス」の受け取り先の位置が異なる点は別として,「前記プライベートネットワーク上で,前記第1のプライベートネットワークリソースに関連する前記識別子を前記第1のプライベートネットワークリソースの前記IPアドレスに解決するステップであって,所定の手段から前記第1のプライベートネットワークリソースの前記IPアドレスを受け取るステップを含む,ステップ」の点で一致している。

(エ)上記(ア)?(ウ)のとおりであるから, 引用発明の「前記HTTPリクエストを前サーバに伝送するステップ」は,補正後の発明の「前記第1の通信を前記第1のプライベートネットワークリソースに伝送するステップ」に相当する。

以上を総合すると,補正後の発明と引用発明とは,以下の点で一致し,また,相違している。
(一致点)
「プライベートネットワークの外部のクライアントコンピュータから,前記プライベートネットワークに接続され,第1のプライベートネットワークリソースへのリモートアクセスを可能にするための方法であって,前記プライベートネットワークはエッジリソースを含む方法において,
(A)前記プライベートネットワークの前記エッジリソースにおいて,クライアントコンピュータから,前記第1のプライベートネットワークリソースに関連する識別子を含む第1の通信を受信するステップであって,前記識別子が,前記プライベートネットワーク上で前記第1のプライベートネットワークリソースのインターネットプロトコル(IP)アドレスに解決可能であり,かつ,前記識別子は前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である,ステップと,
(B)前記プライベートネットワーク上で,前記第1のプライベートネットワークリソースに関連する前記識別子を前記第1のプライベートネットワークリソースの前記IPアドレスに解決するステップであって,所定の手段から前記第1のプライベートネットワークリソースの前記IPアドレスを受け取るステップを含む,ステップ
(C)前記第1の通信を前記第1のプライベートネットワークリソースに伝送するステップと
を含むことを特徴とする方法。」

(相違点1)
一致点の「第1のプライベートネットワークリソース」に関し,補正後の発明は,「プライベートドメイン名に関連づけられている」のに対し,引用発明は,ホスト名に関連づけられているものの,当該構成が明らかでない点。

(相違点2)
一致点の「前記識別子は前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である」に関して,本願発明は「前記識別子が前記プライベートドメイン名に関する場合に,」との条件が存在するのに対して,引用発明には当該条件が明らかにされていない点。

(相違点3)
一致点の「所定の手段」に関し,補正後の発明は「前記第1のプライベートネットワークリソース及び前記エッジリソースとは異なる第2のプライベートネットワークリソース」であるのに対し,引用発明の「ホスト名フォワーディングテーブル」はルータ2内のものである点。

以下,上記各相違点について検討する。
(相違点1について)
本件明細書の発明の詳細な説明の【0006】?【0008】,【0023】,【0024】,【0042】,【0047】,【0060】,【0066】?【0071】等を参酌すると,プライベートドメイン名は,プライベートネットワーク106の外部では使用できない,すなわち,公的に解決可能ではない,例えば「hｒｗeb」(人事(HR)部のイントラネットウェブサイトをホストするウェブサーバのドメイン名)等を含むものであり,ウェブサーバ102等のプライベートネットワークリソースに関連付けることができるものである。そして,プライベートドメイン名と例えば「ｒemｏｔeacceｓｓ.cｏｒｐｏｒaｔe.cｏm」等のサフィックスとを使用して形成される完全修飾ドメイン名(hｒｗeb.ｒemｏｔeacceｓｓ.cｏｒｐｏｒaｔe.cｏm)により,公的に解決可能となるものである。したがって,補正後の発明の「プライベートドメイン名」は,完全修飾ドメイン名の内の最も左の部分である,ホストに付けられた名前等を含むものと認められる。
一方,引用発明の「ホスト名」は,サーバA3のホスト名として「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」が例示されており,当該「ホスト名」中の最も左の部分である「SeｒｖeｒA」は「サーバA3」を意味することは明らかである。また,「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」はインターネット1に接続されるDNS7により解決可能であるが,「SeｒｖeｒA」のみではDNS7により解決可能でないことは明らかである。してみると,「サーバA3」は,完全修飾ドメイン名といえるホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」の内の最も左の部分であり,それのみでは公的に解決可能ではない「SeｒｖeｒA」に関連づけられているといえる。
更にいえば,請求項1には名前解決の構成は明らかにされておらず,請求項1の記載からは,補正後の発明の「プライベートドメイン名」が,プライベートネットワーク内ではそれのみにより解決可能であることは読み取れないが,仮にそうであるとしても,ネットワークシステムの名前解決は階層的に為されることに鑑みれば,プライベートネットワーク内では名前解決に上位レベルのドメイン名が必要でないことは明らかである。また,公知事項1のとおり,プライベートネットワーク内のリソースの名前による問い合わせに対して,プライベートネットワーク名を加えて,プライベートネットワーク内で名前解決することは公知の技術事項である。したがって,仮に補正後の発明の「プライベートドメイン名」が,プライベートネットワーク内ではそれのみにより解決可能であるものだとしても,それにより進歩性が生じるものではない。
したがって,相違点1には実質的な相違はない,あるいは,当業者が容易になし得ることに過ぎない。

(相違点2について)
引用発明は,サーバA3を意味する「SeｒｖeｒA」を含むホスト名「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」が,プライベート・ネットワークの外部ではルータ2のグローバルIPアドレスに解決可能であるから,「前記識別子は前記プライベートネットワークの外部で前記エッジリソースのIPアドレスに解決可能である」とする条件として「前記識別子が前記プライベートドメイン名に関する場合に,」とすることは,引用発明に対して何ら相違をもたらすものではない。したがって,相違点2には実質的な相違はない。

(相違点3について)
公知事項2のとおり,「プライベートにアドレスされたネットワークのアドレス解決をするため手段(DHCPサーバ及び/又はDNSサーバ)は,ゲートウェイに含んでもよいし,ゲートウェイとは異なるデバイス上に配置してもよい。」ことは公知の技術事項であるから,相違点3は,格別困難なことではなく,当業者が適宜選択し得ることにすぎない。

そして,補正後の発明の作用効果も,引用発明及び公知の技術事項に基づいて当業者が予測できる範囲のものである。

以上のとおり,補正後の発明は,引用発明及び公知の技術事項に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。


なお,請求人は,平成27年3月6日付け上申書にて,審査官が作成した前置報告書に対して,「上記にご指摘された内容を斟酌すると,審査官殿は,審判請求書の「請求の理由」において,出願人が挙げた本願の請求項1,12に係る発明と,引用文献1-4との相違点を認めている。しかしながら,『本願の上記請求項には単に識別子がプライベートドメイン名に「関連する」ということが記載されているのみであるから,本願の上記請求項における「識別子」は,プライベートドメイン名と「関連する」という点で,引用文献1や引用文献3の「識別子」と差異はない。』旨ご指摘された。出願人は,本ご指摘に従って,本願の請求項1,12に係る発明と引用文献との相違点をより明確にするよう,以下「4.補正案」に示すように補正をする用意があります。補正案をご検討いただきますようお願い申し上げます。」と述べ,「プライベートドメイン名に関連づけられている第1のプライベートネットワークリソース」を「プライベートドメイン名を有する第1のプライベートネットワークリソース」とし,「前記識別子が前記プライベートドメイン名に関する場合に,」を「前記識別子が前記プライベートドメイン名である場合に,」とする補正案を提示している。
しかしながら,上記「(相違点1について)」にて述べたとおり,引用発明の「ホスト名」は,サーバA3のホスト名として「SeｒｖeｒA.ｓeｒｖeｒ.neｔ」が例示されており,当該ホスト名中の最も左の部分である「SeｒｖeｒA」は,サーバA3を意味し,また,それのみでは公的に解決可能ではないことは明らかであるから,「プライベートドメイン名」に含まれるものである。そして,「SeｒｖeｒA」がサーバA3を意味する以上,「第1のプライベートネットワークリソース」に相当するサーバA3は「プライベートドメイン名を有する」といえる。
また,公知例の記載(上記イ[公知の技術事項](ウ),(エ)参照。)によれば,プライベートネットワーク内のリソースの名前(例えば「cｕbe」)による問い合わせに対して,ネットワークの名前を加えて,名前解決することは公知の技術事項であるから,「前記識別子が前記プライベートドメイン名である」ようにすることも格別困難なことではない。このため,上記補正案によっても補正後の発明に進歩性を認めることはできない。

3 結語
したがって,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。


第3 本願発明について
1 本願発明
平成26年5月7日付けの手続補正は上記のとおり却下されたので,本願発明は,上記「第2 補正却下の決定」の項中の「1 本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。

2 引用発明
引用発明及び公知の技術事項は,上記「第2 補正却下の決定」の項中の「2 補正の適否」の項中の「(2)独立特許要件」の項中の「イ 引用発明及び公知の技術事項」の項で認定したとおりである。

3 対比・判断
そこで,本願発明と引用発明とを対比するに,本願発明は補正後の発明から当該補正に係る限定を省いたものである。
そうすると,本願発明の構成に当該補正に係る限定を付加した補正後の発明が,上記「第2 補正却下の決定」の項中の「2 補正の適否」の項中の「(2)独立特許要件」の項中の「ウ 対比・判断」の項で検討したとおり,引用発明及び公知の技術事項に基づいて容易に発明できたものであるから,本願発明も同様の理由により,容易に発明できたものである。

4 むすび
以上のとおり,本願発明は,引用発明及び公知の技術事項に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2015-06-05 
結審通知日 2015-06-08 
審決日 2015-06-25 
出願番号 特願2011-547928(P2011-547928)
審決分類 P 1 8・ 575- Z (H04L)
P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 玉木 宏治、松崎 孝大  
特許庁審判長 大塚 良平
特許庁審判官 林 毅
菅原 道晴
発明の名称 ネットワークの外部からのプライベートネットワークリソースへのリモートアクセス  
代理人 竹内 茂雄  
代理人 山本 修  
代理人 小野 新次郎  
代理人 松尾 淳一  
代理人 中西 基晴  
代理人 大房 直樹  
代理人 大牧 綾子  
代理人 上田 忠  
代理人 末松 亮太  
代理人 鳥居 健一  
代理人 小林 泰  
代理人 中村 彰吾  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ