【事件の表示】
　特願２０１６−５４２９９１「協働するネットワークコントローラに基づくマルチドメイン送信元ルート選択転送」拒絶査定不服審判事件〔平成２７年　７月２３日国際公開、ＷＯ２０１５／１０９２８４、平成２９年　１月　５日国内公表、特表２０１７−５００８１９、請求項の数（１４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２７年１月１９日（パリ条約による優先権主張外国庁受理２０１４年１月２０日）を国際出願日とする出願であって、平成２９年６月２２日付けで拒絶理由通知がされ、平成２９年９月１１日付けで手続補正がされ、平成３０年２月１６日付けで拒絶査定がなされ、これに対して平成３０年６月２７日に審判の請求がされると同時に手続補正がされたものである。
第２　原査定の概要
　原査定（平成３０年２月１６日付け拒絶査定）の理由２−理由４の概要は次のとおりである。
理由２　本願請求項１−２０に係る発明は、以下の引用文献１−２に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
　１．米国特許出願公開第２０１２／０１８８９０６号明細書
　２．Ｖａｓｓｅｕｒ　＆　Ｌｅ　Ｒｏｕｘ，Ｐａｔｈ　Ｃｏｍｐｕｔａｔｉｏｎ　Ｅｌｅｍｅｎｔ　（ＰＣＥ）　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ　（ＰＣＥＰ）、ＲＦＣ５４４０、２００９年３月、ｐ．１−１５、２７−３０、ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｐｄｆ／ｒｆｃ５４４０．ｐｄｆ
理由３　特許請求の範囲の請求項８−９、１２、１８、２０に係る発明は、発明の詳細な説明に記載したものでないから、本願は、特許法第３６条第６項第１号に規定する要件を満たしていない。
理由４　本願は、発明の詳細な説明の記載が、当業者が請求項８−９、１２、１８、２０に係る発明を実施することができる程度に明確かつ十分に記載されたものでないから、特許法第３６条第４項第１号に規定する要件を満たしていない。
第３　本願発明
　本願請求項１−１４に係る発明（以下、それぞれ「本願発明１」−「本願発明１４」という。）は、平成３０年６月２７日付けの手続補正で補正された特許請求の範囲の請求項１−１４に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。
「【請求項１】
　ネットワークにおける送信元ルート選択転送のための方法であって、
　ドメイン内のエッジノードにより、インタードメイン経路を介してデータパケットを受信するステップであって、前記データパケットには、送信元ルートホップリストを伝送するパケットヘッダが付加され、前記送信元ルートホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、
　前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、
　前記パケットヘッダ中で前記経路識別子を前記ホップリストに置き換えるステップと、
　前記ホップリストに従って、前記データパケットを前記イントラドメイン経路セグメントの次のホップに転送するステップと
　を有し、
　前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され、
　前記方法は、
　前記データパケットを前記イントラドメイン経路セグメントの前記次のホップに転送する前記ステップの後に、前記エッジノードにより、コントローラから制御メッセージを受信するステップであって、前記制御メッセージは、前記エントリを前記転送テーブルから除去するように前記エッジノードに命令する、ステップと
　をさらに有する、方法。」
　なお、本願発明２−１４の概要は以下のとおりである。
　本願発明２−７は、本願発明１を減縮した発明である。
　本願発明８は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明１に対応する「エッジノード」の発明である。
　本願発明９は、本願発明８を減縮した発明である。
　本願発明１０は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明１に対応する「送信元ルート選択転送の方法」の発明である。
　本願発明１１−１３は、本願発明１０を減縮した発明である。
　本願発明１４は、「送信元ルート選択転送の方法」の発明である本願発明１０に対応する「コントローラ」の発明である。
第４　引用文献、引用発明等
１．引用文献１について
　原査定の拒絶の理由に引用された引用文献１（米国特許出願公開第２０１２／０１８８９０６号明細書）には、図面とともに、以下の事項が記載されている（訳は当審訳。下線は当審付与。以下同様。）。
（１）　段落［０００１］
「FIELD OF THE INVENTION 
[0001]　The present invention relates generally to communication networks. More particularly, the present invention relates to path computation systems and methods operating over heterogeneous multi-domain networks including networks using Multiprotocol Label Switching (MPLS), Generalized MPLS (GMPLS), Automatic Switched Transport Network (ASTN), Automatically Switched Optical Network (ASON), Optical Signal and Routing Protocol (OSRP), and the like. 」
（訳：
発明の分野
［０００１］　本発明は、一般に通信ネットワークに関する。より詳細には、本発明は、マルチ・プロトコル・ラベル・スイッチング（
ＭＰＬＳ
ＧＭＰＬＳ
ＡＳＴＮ
ＡＳＯＮ
ＯＳＲＰ
異種マルチドメイン・ネットワーク上で
経路計算システム及び方法
（２）　段落［００３０］−［００３５］
「[0030]　Referring to FIG. 5, in an exemplary embodiment, a flowchart illustrates a multi-domain path connection method 500 utilizing unparsed domain-specific path segments in EROS. Specifically, the multi-domain path connection method 500 enables a path computation across a plurality of heterogeneous domains without requiring each domain to understand particularities of the other domains. Further, the multi-domain path connection method 500 may be applied to different path computation techniques such as E-NNI, PCE, etc. For illustration purposes, the multi-domain path connection method 500 is described herein with respect to PCE.
[0031]　The multi-domain path connection method 500 begins with a request, such as a request to set up a path from node A in domain A to node Z in domain Z (step 502). For example, assume the multi-domain path connection method 500 is implemented in a network with a plurality of domains A . . . Z with possibly intermediate domains between A and Z and with a plurality of nodes in each domain. The PCE in domain A signals to PCEs in domain Z and in any intermediate domains (step 504). Here, the PCEs may use any method to determine/compute a path from nodes A to Z. An ERO is provided to the PCE in domain A with unparsed domain-specific path segments in one or more of Domain Z and any intermediate domains (step 506). Here, the present invention proposes to add unparsed domain-specific path segment (UDSP) to the ERO. The UDSP is a path segment through a particular domain that is parseable by that particular domain, but may not be parseable by another domain (i.e. since the domains are heterogeneous). The node A uses the ERO with the UDSP without understanding its format or contents to establish the path (step 508). The UDSP is domain-specific in format and encoding and it may use a different addressing space. The source node A is able to use this UDSP in its ERO without understanding its format or contents since the source node is sending out the ERO, and the particular domain that receives the ERO will be able to parse the UDSP even though the source node A cannot. 
[0032]　Using the multi-domain path connection method 500 enables the various domains in the network to use any numbering/addressing procedure including not having to follow standard protocols. This maintains privacy and independence within the domain, maintains loop-avoidance outside the domain, avoids need for PCE request/response cycle during connection setup, and avoids need for PCE reachability from the domain ingress node.
[0033]　Referring to FIG. 6, in an exemplary embodiment, the multi-domain network 100 is illustrated using Path Computation Elements (PCEs) 300 between the domains 102, 104, 106 and the multi-domain path connection method 500. In this exemplary embodiment, the domains 102, 106 utilize a first number/addressing scheme denoted by the nodes 110 labeled as A, B, C, D, E, F in the domain 102 and as Q, R, S, T, U, V in the domain 106. The nodes 110 in the domain 104 utilize a different scheme from the domains 102, 104, e.g. the nodes 110 in the domain 104 are labeled as F, H, I, θ, K, A, M, N, H rather than G, H, I, J, K, L, M, N, P.
[0034]　In an exemplary embodiment using the multi-domain path connection method 500, the node 110 A wants a path to the node 110 V. The node 110 A requests a path from the PCE1 300. The PCE1 300 passes the request on to the PCE2 300 and the PCE3 300. As described above, the domain 104 may use a non-IP address scheme. Thus, the PCE2 300 returns a UDSP segment to PCE1 300 rather than a normal ERO segment. This UDSP is treated as a single, non-parsed object to be included in the ERO, e.g. (A, F, H, UDSP2), V)（当審注：「 (A, F, H,  
UDSP
θ
[0035]　Referring to FIG. 7 , in an exemplary embodiment, a flowchart illustrates a temporary path resource reservation method 700 that may temporarily reserve paths through a domain. For example, the temporary path resource reservation method 700 may be used in conjunction with the multi-domain path connection method 500 to remove the potential that a setup message is blocked due to lack of resources in a computed path and to reduce potential setup delay due to crankback or path recomputation. A PCE computes a path segment within its domain (step 702). This may be part of the multi-domain path connection method 500. The PCE returns the path segment and requests an ingress node in the domain to temporarily reserve resources on the computed path segment (step 704). A setup message is received from another domain using this computed path segment and the reserved resources are allocated accordingly (step 706). If no setup message is received after a predetermined time, the resources are released for new connections (step 708).」
（訳：
［００３０］　図５を参照すると、例示的な実施形態において、フローチャートは、未解析のドメイン特有の経路セグメントを利用した、マルチドメインの経路接続方法５００を示している。具体的には、マルチドメインの経路接続方法５００は、各ドメインが他ドメインの詳細を理解することを必要とせずに、複数の異種ドメインを横切る経路を計算できるようにする。さらに、マルチドメインの経路接続方法５００は、Ｅ−ＮＮＩ、ＰＣＥ等の様々な経路計算技術に適用できる。例示の目的で、マルチドメインの経路接続方法５００を、ここではＰＣＥに関して記載する。
［００３１］　マルチドメインの経路接続方法５００は、例えば、ドメインＡのノードＡからドメインＺのノードＺまでの経路の設定リクエストであるような、リクエストで開始する（ステップ５０２）。例示的に、マルチドメインの経路接続方法５００は、複数のドメインＡ…Ｚからなるネットワーク内で実施されると仮定する。ここでＡとＺの間には、おそらく中間のドメインがあり、各ドメイン内には、複数のノードがあるであろう。ドメインＡのＰＣＥは、ドメインＺ及びあらゆる中間ドメインのＰＣＥにシグナリングを行う（ステップ５０４）。ここで、各ＰＣＥは、ノードＡからノードＺまでの経路を決定／計算するために任意の方法を用いてよい。ドメインＺ及びあらゆる中間ドメインの１つ以上における未解析のドメイン特有の経路セグメントを有する
明示的経路オブジェクトＥＲＯ
未解析のドメイン特有の経路（ＵＤＳＰ）セグメント
［００３２］　マルチドメインの経路接続方法５００によって、ネットワーク中の様々なドメインが、標準化プロトコルに強制的に従わされずに、任意の番号／アドレス指定の手順を使用できる。これによって、ドメイン内のプライバシーと独立性を維持でき、ドメイン外でのループを回避して、接続セットアップ中のＰＣＥリクエスト／応答サイクルを不要化して、ドメインの入口ノードからＰＣＥまでの到達可能性を不要化する。
［００３３］　図６を参照すると、例示的な実施形態において、
ドメイン１０２、１０４、１０６間の、経路計算要素（ＰＣＥ）を用いる、マルチドメインネットワーク１００
マルチドメインの経路接続方法５００
番号／アドレス指定方式
ドメイン１０２内のノード１１０は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆとラベル付けされ
ドメイン１０６内のノード１１０は、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖとラベル付けされ
ドメイン１０４内のノード１１０は、ドメイン１０２、１０６と異なる方式を利用しており、すなわち、
Ｆ、Ｈ、Ｉ、θ、Ｋ、Ａ、Ｍ、Ｎ、とラベル付けされて
［００３４］　マルチドメインの経路接続方法５００を使用する例示的な実施形態において、
ノード１１０Ａはノード１１０Ｖまでの経路を望んで
ノード１１０Ａは、ＰＣＥ１（３００）から経路をリクエスト
ＰＣＥ１（３００）は、リクエストをＰＣＥ２（３００）とＰＣＥ３（３００）に渡
ＰＣＥ２（３００）は、
ＵＤＳＰセグメントをＰＣＥ１（３００）に返
このＵＤＳＰは、ＥＲＯに含まれる単一の未解析のオブジェクト、例えば（Ａ、Ｆ、Ｈ、ＵＤＳＰ，Ｖ）として処理され
ドメイン１０４への相互接続点となっている
ノード１１０Ｈ
ＥＲＯ付きの設定リクエストが、
到達すると、
ノード１１０Ｈは、ＵＤＳＰを解析して理解でき
ノード１１０Ｈは、ＥＲＯを（Ａ、Ｆ、Ｈ、Ｉ、θ、Ｍ、Ｑ、Ｖ）に拡張する
［００３５］　図７を参照すると、例示的な実施形態において、フローチャートは、あるドメイン内の経路を一時的に予約する一時的経路リソース予約方法７００を示している。例えば、一時的経路リソース予約方法７００を、マルチドメインの経路接続方法５００と共に使用することで、計算された経路のリソース不足のため設定メッセージがブロックされる可能性を除き、また、クランクバックや経路再計算に起因するセットアップ遅延の可能性を減少させることができる。ＰＣＥは、ドメイン内の経路セグメントを計算する（ステップ７０２）。これは、マルチドメインの経路接続方法５００の一部であってもよい。ＰＣＥは、経路セグメントを返して、ドメインの入口ノードに計算された経路セグメント上のリソースを一時的に予約するように要求する（ステップ７０４）。設定メッセージが、この計算された経路セグメントを用いて、他のドメインから受信されて、予約されていたリソースがそれに従い割当てられる（ステップ７０６）。所定時間が経過しても、設定メッセージが受信されない場合、新たな接続のためにリソースが解放される（ステップ７０８）。）
　したがって、関連図面に照らし、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「ドメイン１０２、１０４、１０６間の、経路計算要素（ＰＣＥ）を用いる、マルチドメインネットワーク１００における、マルチドメインの経路接続方法５００であって、
　ドメイン１０２内のノード１１０は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆとラベル付けされ、
　ドメイン１０６内のノード１１０は、Ｑ、Ｒ、Ｓ、Ｔ、Ｕ、Ｖとラベル付けされ、
　ドメイン１０４内のノード１１０は、ドメイン１０２、１０６と異なる番号／アドレス指定方式を利用しており、すなわち、Ｆ、Ｈ、Ｉ、θ、Ｋ、Ａ、Ｍ、Ｎ、とラベル付けされており、
　ノード１１０Ａはノード１１０Ｖまでの経路を望んでおり、
　ノード１１０Ａは、ＰＣＥ１（３００）から経路をリクエストし、
　ＰＣＥ１（３００）は、リクエストをＰＣＥ２（３００）とＰＣＥ３（３００）に渡し、
　ＰＣＥ２（３００）は、通常の明示的経路オブジェクトＥＲＯセグメントに替えて、未解析のドメイン特有の経路（ＵＤＳＰ）セグメントをＰＣＥ１（３００）に返し、
　このＵＤＳＰは、明示的経路オブジェクトＥＲＯに含まれる単一の未解析のオブジェクト、例えば（Ａ、Ｆ、Ｈ、ＵＤＳＰ，Ｖ）として処理され、
　ドメイン１０４への相互接続点となっているノード１１０Ｈに、明示的経路オブジェクトＥＲＯ付きの設定リクエストが、到達すると、
　ノード１１０Ｈは、ＵＤＳＰを解析して理解でき、ノード１１０Ｈは、明示的経路オブジェクトＥＲＯを（Ａ、Ｆ、Ｈ、Ｉ、θ、Ｍ、Ｑ、Ｖ）に拡張する、
マルチドメインの経路接続方法５００。」
２．引用文献２について
　また、原査定の拒絶の理由に引用された、上記引用文献２（Ｖａｓｓｅｕｒ　＆　Ｌｅ　Ｒｏｕｘ，Ｐａｔｈ　Ｃｏｍｐｕｔａｔｉｏｎ　Ｅｌｅｍｅｎｔ　（ＰＣＥ）　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ　（ＰＣＥＰ）、ＲＦＣ５４４０、２００９年３月、ｐ．１−１５、２７−３０、ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｐｄｆ／ｒｆｃ５４４０．ｐｄｆ）には、２９ページ下から４行目−３０ページ８行に、以下の記載がある。
「If no path computation reply is received from the PCE (e.g., the request is dropped by the PCE because of memory overflow), and the PCC wishes to resend its request, the same Request-ID-number MUST be used.  Upon receiving a path computation request from a PCC with the same Request-ID-number, the PCE SHOULD treat the request as a new request.  An implementation MAY choose to cache path computation replies in order to quickly handle retransmission without having to process a path computation request twice (in the case that the first request was dropped or lost).  Upon receiving a path computation reply from a PCE with the same Request-ID-number, the PCC SHOULD silently discard the path computation reply.)」
（訳：
　ＰＣＥからの経路計算応答が受信されない場合（例えば、メモリ・オーバフローのために、ＰＣＥがリクエストを破棄した場合）であって、ＰＣＣがリクエストの再送を望む場合には、同一リクエストＩＤ番号を使用しなければならない。ＰＣＣから同一リクエストＩＤ番号の経路計算リクエストを受信した場合、
ＰＣＥは、
経路計算リクエストを２回処理することなく、迅速に再送信を処理するために、経路計算応答をキャッシュすることを選択してもよ
第５　対比・判断
１．本願発明１について
（１）　対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア　引用発明の「マルチドメイン
ネットワーク１００における
方法５００
送信元ルート選択転送のための
イ　引用発明の「ドメイン１０４への相互接続点となっているノード１１０Ｈ」は、本願発明１の「ドメイン内のエッジノード」に相当する。
　引用発明の「設定リクエスト」は、本願発明１の「データパケット」と、「情報」である点で共通するといえる。
　よって、引用発明の「ドメイン１０４への相互接続点となっているノード１１０Ｈに、明示的経路オブジェクトＥＲＯ付きの設定リクエストが、到達する」ことは、本願発明１の「ドメイン内のエッジノードにより、インタードメイン経路を介して
データパケットを
情報を
ウ　引用発明における、「明示的経路オブジェクトＥＲＯ」は、ドメイン１０２−１０６内のノード１１０のラベル「Ａ」等と、ドメイン１０４に特有の経路セグメント「ＵＤＳＰ」を列挙した「（Ａ、Ｆ、Ｈ、ＵＤＳＰ，Ｖ）」であるから、本願発明１の「
送信元ルートホップリスト
　よって、引用発明の「設定リクエスト」が「明示的経路オブジェクトＥＲＯ付きの設定リクエスト」であることは、本願発明１の「前記
データパケット
送信元ルートホップリストを伝送するパケットヘッダ
情報
ホップリスト
エ　引用発明のドメイン１０４特有の経路セグメント「ＵＤＳＰ」は、本願発明１の「イントラドメイン経路セグメントの経路識別子」に相当する。
　よって、引用発明の「明示的経路オブジェクトＥＲＯ」である「（Ａ、Ｆ、Ｈ、ＵＤＳＰ，Ｖ）」に対して、「ドメイン１０４への相互接続点となっているノード１１０Ｈに、明示的経路オブジェクトＥＲＯ付きの設定リクエストが、到達すると、ノード１１０Ｈは、ＵＤＳＰを解析して理解でき、ノード１１０Ｈは、明示的経路オブジェクトＥＲＯを（Ａ、Ｆ、Ｈ、Ｉ、θ、Ｍ、Ｑ、Ｖ）に拡張する」ことは、本願発明１の「前記
送信元ルート
前記パケットヘッダ中で
ホップリスト
、前
　したがって、本願発明１と、引用発明との間には、次の一致点、相違点があるといえる。
［一致点］
「ネットワークにおける方法であって、
　ドメイン内のエッジノードにより、インタードメイン経路を介して情報を受信するステップであって、前記情報には、ホップリストが付加され、前記ホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、
　前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、
　前記経路識別子を前記ホップリストに置き換えるステップと、
　を有する、方法。」
［相違点１］
　本願発明１は、「ネットワークにおける
送信元ルート選択転送
データパケット
データパケット
送信元ルートホップリストを伝送するパケットヘッダ
前記送信元ルートホップリスト
ネットワーク１００における
経路接続
設定リクエストが
［相違点２］
　本願発明１は、「
前記パケットヘッダ中で
［相違点３］
　本願発明１は、「前記ホップリストに従って、前記データパケットを前記イントラドメイン経路セグメントの次のホップに転送するステップ」を備えているのに対して、引用発明では、「前記データパケット」を次のホップに転送することが特定されていない点。
［相違点４］
　本願発明１は、「前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され」ているのに対して、引用発明では、「前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され」ていることが特定されていない点。
［相違点５］
　本願発明１は、「前記データパケットを前記イントラドメイン経路セグメントの前記次のホップに転送する前記ステップの後に、前記エッジノードにより、コントローラから制御メッセージを受信するステップであって、前記制御メッセージは、前記エントリを前記転送テーブルから除去するように前記エッジノードに命令する、ステップ」を備えるのに対して、引用発明では、エントリを除去する制御メッセージを受信するステップを備えていない点。
（２）　［相違点１］についての判断
ア　本願発明１は、「インタードメイン経路」におけるデータパケットの転送について、「データパケット」に所定の「送信ルートホップリスト」を送信元で付加して送信する「送信元ルート選択転送」方式を用いる発明である。
　このため、本願発明１の「送信ルートホップリスト」は、各「データパケット」（具体的には、データパケットの「パケットヘッダ部」）に対して付加されている。
　一方、引用発明は、「マルチドメインネットワーク１００における、マルチドメインの経路接続方法５００」に係る発明であって、マルチドメインネットワークにおいて、データパケットの送信より先に行われることが明らかな、経路の設定段階に係る発明である。
　このため、引用発明の「明示的経路オブジェクトＥＲＯ」（これは、本願発明１の「送信ルートホップリスト」と「ホップリスト」である点では共通するといえる。）は、「経路接続」の段階で送信される「設定リクエスト」に対して付加されるものである。
　ここで、一般に、データパケットに、ルートを指定する「ホップリスト」を送信元で付加して送信すること自体は、いわゆる「ソース・ルーチング方式」として、文献を挙げるまでもなく周知技術であるといえる。
　しかし、引用文献１には（上記「第４、１（１）」項を参照。）、段落［０００１］に、「マルチドメインの経路接続方法５００」を、ＭＰＬＳ方式や、ＧＭＰＬＳ方式などの各種ネットワークからなるマルチドメインネットワークにも適用できることは記載があるものの、これは「マルチドメインの経路計算方法５００」が多様なネットワークに適用できることの開示にとどまるものである。引用文献１には、マルチドメインネットワークに「ソース・ルーチング方式」の周知技術を適用するために、「マルチドメインの経路接続方法５００」において、ホップリストである「明示的経路オブジェクトＥＲＯ」を「設定リクエスト」に付加することに替えて、「送信ルートホップリスト」を「データパケット」に付加するように構成することについては、記載も示唆もない。
イ　引用文献２には（上記「第４、２」項を参照。）、ＰＣＥ（経路計算エレメント）側において、経路計算結果をキャッシュに記憶することが開示されている。
　しかし、引用文献２には、「インタードメイン経路」におけるデータパケットの転送について、所定の「送信ルートホップリスト」を「データパケット」に送信元で付加するという「送信元ルート選択転送」方式に関する、本願発明１の上記［相違点１］に係る構成は記載されていない。
ウ　よって、当業者といえども、引用発明及び引用文献２に記載された技術的事項、周知技術から、本願発明１の上記［相違点１］に係る構成を容易に想到することはできない。
（３）　まとめ
　したがって、本願発明１は、［相違点２］−［相違点５］について検討するまでもなく、当業者であっても、引用発明及び引用文献２に記載された技術的事項、周知技術に基づいて容易に発明できたものであるとはいえない。
２．本願発明２−１４について
　本願発明２−１４は、
本願発明２−７は、本願発明１を減縮した発明であり、
本願発明８は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明１に対応する「エッジノード」の発明であり、
本願発明９は、本願発明８を減縮した発明であり、
本願発明１０は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明１に対応する「送信元ルート選択転送の方法」の発明であり、
本願発明１１−１３は、本願発明１０を減縮した発明であり、
本願発明１４は、「送信元ルート選択転送の方法」の発明である本願発明１０に対応する「コントローラ」の発明であるから、本願発明１の上記［相違点１］と同様の構成を備えるものである。よって、本願発明２−１４も、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２に記載された技術的事項、周知技術に基づいて容易に発明できたものであるとはいえない。
第６　原査定について
１．理由２（特許法第２９条第２項）について
　本願発明１−１４は、審判請求時の補正により、本願発明１の上記［相違点１］に係る事項と同様の構成を有するものとなっており、上記「第５」で述べたのと同様の理由により、当業者であっても、拒絶査定において引用された引用文献１−２に基づいて、容易に発明できたものとはいえない。したがって、原査定の理由を維持することはできない。
２．理由３（特許法第３６条第６項第１号）、理由４（特許法第３６条第４項第１号）について
　審判請求時の補正により、理由３、理由４に係る、請求項８−９、１２、１８、２０がすべて削除されたことにより、原査定の理由３、理由４を維持することはできない。
第７　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。