• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1352619
審判番号 不服2018-8820  
総通号数 236 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-08-30 
種別 拒絶査定不服の審決 
審判請求日 2018-06-27 
確定日 2019-07-08 
事件の表示 特願2016-542991「協働するネットワークコントローラに基づくマルチドメイン送信元ルート選択転送」拒絶査定不服審判事件〔平成27年 7月23日国際公開、WO2015/109284、平成29年 1月 5日国内公表、特表2017-500819、請求項の数(14)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成27年1月19日(パリ条約による優先権主張外国庁受理2014年1月20日)を国際出願日とする出願であって、平成29年6月22日付けで拒絶理由通知がされ、平成29年9月11日付けで手続補正がされ、平成30年2月16日付けで拒絶査定がなされ、これに対して平成30年6月27日に審判の請求がされると同時に手続補正がされたものである。

第2 原査定の概要
原査定(平成30年2月16日付け拒絶査定)の理由2-理由4の概要は次のとおりである。

理由2 本願請求項1-20に係る発明は、以下の引用文献1-2に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.米国特許出願公開第2012/0188906号明細書
2.Vasseur & Le Roux,Path Computation Element (PCE) Communication Protocol (PCEP)、RFC5440、2009年3月、p.1-15、27-30、https://tools.ietf.org/pdf/rfc5440.pdf

理由3 特許請求の範囲の請求項8-9、12、18、20に係る発明は、発明の詳細な説明に記載したものでないから、本願は、特許法第36条第6項第1号に規定する要件を満たしていない。

理由4 本願は、発明の詳細な説明の記載が、当業者が請求項8-9、12、18、20に係る発明を実施することができる程度に明確かつ十分に記載されたものでないから、特許法第36条第4項第1号に規定する要件を満たしていない。


第3 本願発明
本願請求項1-14に係る発明(以下、それぞれ「本願発明1」-「本願発明14」という。)は、平成30年6月27日付けの手続補正で補正された特許請求の範囲の請求項1-14に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
ネットワークにおける送信元ルート選択転送のための方法であって、
ドメイン内のエッジノードにより、インタードメイン経路を介してデータパケットを受信するステップであって、前記データパケットには、送信元ルートホップリストを伝送するパケットヘッダが付加され、前記送信元ルートホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、
前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、
前記パケットヘッダ中で前記経路識別子を前記ホップリストに置き換えるステップと、
前記ホップリストに従って、前記データパケットを前記イントラドメイン経路セグメントの次のホップに転送するステップと
を有し、
前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され、
前記方法は、
前記データパケットを前記イントラドメイン経路セグメントの前記次のホップに転送する前記ステップの後に、前記エッジノードにより、コントローラから制御メッセージを受信するステップであって、前記制御メッセージは、前記エントリを前記転送テーブルから除去するように前記エッジノードに命令する、ステップと
をさらに有する、方法。」

なお、本願発明2-14の概要は以下のとおりである。

本願発明2-7は、本願発明1を減縮した発明である。
本願発明8は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明1に対応する「エッジノード」の発明である。
本願発明9は、本願発明8を減縮した発明である。
本願発明10は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明1に対応する「送信元ルート選択転送の方法」の発明である。
本願発明11-13は、本願発明10を減縮した発明である。
本願発明14は、「送信元ルート選択転送の方法」の発明である本願発明10に対応する「コントローラ」の発明である。

第4 引用文献、引用発明等
1.引用文献1について
原査定の拒絶の理由に引用された引用文献1(米国特許出願公開第2012/0188906号明細書)には、図面とともに、以下の事項が記載されている(訳は当審訳。下線は当審付与。以下同様。)。

(1) 段落[0001]
「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. 」
(訳:
発明の分野
[0001] 本発明は、一般に通信ネットワークに関する。より詳細には、本発明は、マルチ・プロトコル・ラベル・スイッチング(MPLS)、一般化MPLS(GMPLS)、自動交換伝送ネットワーク(ASTN)、自動交換光ネットワーク(ASON)、光信号及びルーチングプロトコル(OSRP)等を利用するネットワークを含む異種マルチドメイン・ネットワーク上で動作する、経路計算システム及び方法に関する。)

(2) 段落[0030]-[0035]
「[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, V)」の誤記と認める。). It is assumed that the node 110 H has an address that is understandable to the domain 102 since it is the point of interconnection to the domain 104. When a setup request with the ERO reaches the node 110 H, it is able to parse and understand the UDSP since the UDSP is consistent with internal addressing and naming of the domain 104. The node 110 H can expand the ERO to be (A, F, H, I, J, M, Q, V)(当審注:「 (A, F, H, I, θ, M, Q, V)」の誤記と認める。).

[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).」

(訳:
[0030] 図5を参照すると、例示的な実施形態において、フローチャートは、未解析のドメイン特有の経路セグメントを利用した、マルチドメインの経路接続方法500を示している。具体的には、マルチドメインの経路接続方法500は、各ドメインが他ドメインの詳細を理解することを必要とせずに、複数の異種ドメインを横切る経路を計算できるようにする。さらに、マルチドメインの経路接続方法500は、E-NNI、PCE等の様々な経路計算技術に適用できる。例示の目的で、マルチドメインの経路接続方法500を、ここではPCEに関して記載する。

[0031] マルチドメインの経路接続方法500は、例えば、ドメインAのノードAからドメインZのノードZまでの経路の設定リクエストであるような、リクエストで開始する(ステップ502)。例示的に、マルチドメインの経路接続方法500は、複数のドメインA…Zからなるネットワーク内で実施されると仮定する。ここでAとZの間には、おそらく中間のドメインがあり、各ドメイン内には、複数のノードがあるであろう。ドメインAのPCEは、ドメインZ及びあらゆる中間ドメインのPCEにシグナリングを行う(ステップ504)。ここで、各PCEは、ノードAからノードZまでの経路を決定/計算するために任意の方法を用いてよい。ドメインZ及びあらゆる中間ドメインの1つ以上における未解析のドメイン特有の経路セグメントを有する明示的経路オブジェクトEROが、ドメインAのPCEに提供される(ステップ506)。ここで、本発明は、未解析のドメイン特有の経路(UDSP)セグメントを、明示的経路オブジェクトEROに付加することを提案している。UDSPとは、あるドメインを横切る経路セグメントであって、そのドメインには解析できるが、他のドメインには(すなわち、ドメイン種別が異なるために)解析できないかもしれない経路セグメントである。ノードAは、UDSPを含むEROを、そのフォーマットや中身を理解しないまま利用して、経路を確立させる(ステップ508)。UDSPは、フォーマットや符号化がドメインに特有であり、異なるアドレス空間を使用してもよい。発信元ノードAは、このERO中のUDSPを、そのフォーマットや中身を理解しないまま利用できる。なぜならば、送信元ノードがEROを送出して、そのEROを受信する特定のドメインでは(送信元ノードには解析できなくとも)、そのUDSPを解析できるからである。

[0032] マルチドメインの経路接続方法500によって、ネットワーク中の様々なドメインが、標準化プロトコルに強制的に従わされずに、任意の番号/アドレス指定の手順を使用できる。これによって、ドメイン内のプライバシーと独立性を維持でき、ドメイン外でのループを回避して、接続セットアップ中のPCEリクエスト/応答サイクルを不要化して、ドメインの入口ノードからPCEまでの到達可能性を不要化する。

[0033] 図6を参照すると、例示的な実施形態において、ドメイン102、104、106間の、経路計算要素(PCE)を用いる、マルチドメインネットワーク100と、マルチドメインの経路接続方法500が示されている。この例示的な実施形態において、ドメイン102とドメイン106は、第1の番号/アドレス指定方式を利用しており、ドメイン102内のノード110は、A、B、C、D、E、Fとラベル付けされ、ドメイン106内のノード110は、Q、R、S、T、U、Vとラベル付けされている。ドメイン104内のノード110は、ドメイン102、106と異なる方式を利用しており、すなわち、G、H、I、J、K、L、M、N、Pではなく、F、H、I、θ、K、A、M、N、とラベル付けされている。

[0034] マルチドメインの経路接続方法500を使用する例示的な実施形態において、ノード110Aはノード110Vまでの経路を望んでいる。ノード110Aは、PCE1(300)から経路をリクエストする。PCE1(300)は、リクエストをPCE2(300)とPCE3(300)に渡す。上述のように、ドメイン104は、IP以外のアドレス指定方式を使用し得る。そのため、PCE2(300)は、通常のEROセグメントに替えて、UDSPセグメントをPCE1(300)に返す。このUDSPは、EROに含まれる単一の未解析のオブジェクト、例えば(A、F、H、UDSP,V)として処理される。ドメイン104への相互接続点となっているので、ノード110Hは、ドメイン102に理解できるアドレスを有していると仮定する。ERO付きの設定リクエストが、ノード110Hに到達すると、UDSPはドメイン104内部のアドレスと名前の指定方式と合致しているため、ノード110Hは、UDSPを解析して理解できる。ノード110Hは、EROを(A、F、H、I、θ、M、Q、V)に拡張することができる。

[0035] 図7を参照すると、例示的な実施形態において、フローチャートは、あるドメイン内の経路を一時的に予約する一時的経路リソース予約方法700を示している。例えば、一時的経路リソース予約方法700を、マルチドメインの経路接続方法500と共に使用することで、計算された経路のリソース不足のため設定メッセージがブロックされる可能性を除き、また、クランクバックや経路再計算に起因するセットアップ遅延の可能性を減少させることができる。PCEは、ドメイン内の経路セグメントを計算する(ステップ702)。これは、マルチドメインの経路接続方法500の一部であってもよい。PCEは、経路セグメントを返して、ドメインの入口ノードに計算された経路セグメント上のリソースを一時的に予約するように要求する(ステップ704)。設定メッセージが、この計算された経路セグメントを用いて、他のドメインから受信されて、予約されていたリソースがそれに従い割当てられる(ステップ706)。所定時間が経過しても、設定メッセージが受信されない場合、新たな接続のためにリソースが解放される(ステップ708)。)

したがって、関連図面に照らし、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。

「ドメイン102、104、106間の、経路計算要素(PCE)を用いる、マルチドメインネットワーク100における、マルチドメインの経路接続方法500であって、
ドメイン102内のノード110は、A、B、C、D、E、Fとラベル付けされ、
ドメイン106内のノード110は、Q、R、S、T、U、Vとラベル付けされ、
ドメイン104内のノード110は、ドメイン102、106と異なる番号/アドレス指定方式を利用しており、すなわち、F、H、I、θ、K、A、M、N、とラベル付けされており、
ノード110Aはノード110Vまでの経路を望んでおり、
ノード110Aは、PCE1(300)から経路をリクエストし、
PCE1(300)は、リクエストをPCE2(300)とPCE3(300)に渡し、
PCE2(300)は、通常の明示的経路オブジェクトEROセグメントに替えて、未解析のドメイン特有の経路(UDSP)セグメントをPCE1(300)に返し、
このUDSPは、明示的経路オブジェクトEROに含まれる単一の未解析のオブジェクト、例えば(A、F、H、UDSP,V)として処理され、
ドメイン104への相互接続点となっているノード110Hに、明示的経路オブジェクトERO付きの設定リクエストが、到達すると、
ノード110Hは、UDSPを解析して理解でき、ノード110Hは、明示的経路オブジェクトEROを(A、F、H、I、θ、M、Q、V)に拡張する、
マルチドメインの経路接続方法500。」

2.引用文献2について
また、原査定の拒絶の理由に引用された、上記引用文献2(Vasseur & Le Roux,Path Computation Element (PCE) Communication Protocol (PCEP)、RFC5440、2009年3月、p.1-15、27-30、https://tools.ietf.org/pdf/rfc5440.pdf)には、29ページ下から4行目-30ページ8行に、以下の記載がある。

「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.)」
(訳:
PCEからの経路計算応答が受信されない場合(例えば、メモリ・オーバフローのために、PCEがリクエストを破棄した場合)であって、PCCがリクエストの再送を望む場合には、同一リクエストID番号を使用しなければならない。PCCから同一リクエストID番号の経路計算リクエストを受信した場合、PCEは、そのリクエストを新たなリクエストとして取り扱うべきである。インプリメンテーションにおいて、経路計算リクエストを2回処理することなく、迅速に再送信を処理するために、経路計算応答をキャッシュすることを選択してもよい。同一リクエストID番号の経路計算応答をPCEから受信した場合、PCCは静かにその経路計算応答を破棄すべきである。)

第5 対比・判断
1.本願発明1について
(1) 対比
本願発明1と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「マルチドメインネットワーク100における、マルチドメインの経路接続方法500」は、本願発明1の「ネットワークにおける送信元ルート選択転送のための方法」と「ネットワークにおける方法」である点で共通するといえる。

イ 引用発明の「ドメイン104への相互接続点となっているノード110H」は、本願発明1の「ドメイン内のエッジノード」に相当する。
引用発明の「設定リクエスト」は、本願発明1の「データパケット」と、「情報」である点で共通するといえる。
よって、引用発明の「ドメイン104への相互接続点となっているノード110Hに、明示的経路オブジェクトERO付きの設定リクエストが、到達する」ことは、本願発明1の「ドメイン内のエッジノードにより、インタードメイン経路を介してデータパケットを受信するステップ」と、「ドメイン内のエッジノードにより、インタードメイン経路を介して情報を受信するステップ」である点で共通するといえる。

ウ 引用発明における、「明示的経路オブジェクトERO」は、ドメイン102-106内のノード110のラベル「A」等と、ドメイン104に特有の経路セグメント「UDSP」を列挙した「(A、F、H、UDSP,V)」であるから、本願発明1の「送信元ルートホップリスト」と、「ホップリスト」である点で共通するといえる。
よって、引用発明の「設定リクエスト」が「明示的経路オブジェクトERO付きの設定リクエスト」であることは、本願発明1の「前記データパケットには、送信元ルートホップリストを伝送するパケットヘッダが付加され」ていることと、「前記情報には、ホップリストが付加され」ている点で共通するといえる。

エ 引用発明のドメイン104特有の経路セグメント「UDSP」は、本願発明1の「イントラドメイン経路セグメントの経路識別子」に相当する。
よって、引用発明の「明示的経路オブジェクトERO」である「(A、F、H、UDSP,V)」に対して、「ドメイン104への相互接続点となっているノード110Hに、明示的経路オブジェクトERO付きの設定リクエストが、到達すると、ノード110Hは、UDSPを解析して理解でき、ノード110Hは、明示的経路オブジェクトEROを(A、F、H、I、θ、M、Q、V)に拡張する」ことは、本願発明1の「前記送信元ルートホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、前記パケットヘッダ中で前記経路識別子を前記ホップリストに置き換えるステップ」と、「前記ホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、前記経路識別子を前記ホップリストに置き換えるステップ」である点で共通するといえる。

したがって、本願発明1と、引用発明との間には、次の一致点、相違点があるといえる。

[一致点]
「ネットワークにおける方法であって、
ドメイン内のエッジノードにより、インタードメイン経路を介して情報を受信するステップであって、前記情報には、ホップリストが付加され、前記ホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップと、
前記エッジノードにより、前記経路識別子に関連付けられたホップリストを識別するステップであって、前記ホップリストは、前記イントラドメイン経路セグメントに従って一連のホップを指定する、ステップと、
前記経路識別子を前記ホップリストに置き換えるステップと、
を有する、方法。」

[相違点1]
本願発明1は、「ネットワークにおける送信元ルート選択転送のための方法であって、ドメイン内のエッジノードにより、インタードメイン経路を介してデータパケットを受信するステップであって、前記データパケットには、送信元ルートホップリストを伝送するパケットヘッダが付加され、前記送信元ルートホップリストは、イントラドメイン経路セグメントに従って個々のホップを指定することなく、前記イントラドメイン経路セグメントの経路識別子を指定し、前記イントラドメイン経路セグメントは、前記ドメインを介して広がる前記インタードメイン経路の一部分である、ステップ」を備えるのに対して、引用発明は、「マルチドメインネットワーク100における、マルチドメインの経路接続方法500」において、「ドメイン104への相互接続点となっているノード110Hに、明示的経路オブジェクトERO付きの設定リクエストが、到達する」ものであって、「送信元ルート選択転送のための方法」において「送信元ルートホップリスト」が付加された「データパケット」を受信するものではない点。

[相違点2]
本願発明1は、「前記パケットヘッダ中で前記経路識別子を前記ホップリストに置き換えるステップ」を備えるのに対して、引用発明では、「前記パケットヘッダ中で」、ホップリストを置き換えるものではない点。

[相違点3]
本願発明1は、「前記ホップリストに従って、前記データパケットを前記イントラドメイン経路セグメントの次のホップに転送するステップ」を備えているのに対して、引用発明では、「前記データパケット」を次のホップに転送することが特定されていない点。

[相違点4]
本願発明1は、「前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され」ているのに対して、引用発明では、「前記経路識別子をホップリストに関連付けるエントリが、前記ドメイン内のエッジノードに格納された転送テーブル内に記憶され」ていることが特定されていない点。

[相違点5]
本願発明1は、「前記データパケットを前記イントラドメイン経路セグメントの前記次のホップに転送する前記ステップの後に、前記エッジノードにより、コントローラから制御メッセージを受信するステップであって、前記制御メッセージは、前記エントリを前記転送テーブルから除去するように前記エッジノードに命令する、ステップ」を備えるのに対して、引用発明では、エントリを除去する制御メッセージを受信するステップを備えていない点。

(2) [相違点1]についての判断
ア 本願発明1は、「インタードメイン経路」におけるデータパケットの転送について、「データパケット」に所定の「送信ルートホップリスト」を送信元で付加して送信する「送信元ルート選択転送」方式を用いる発明である。
このため、本願発明1の「送信ルートホップリスト」は、各「データパケット」(具体的には、データパケットの「パケットヘッダ部」)に対して付加されている。
一方、引用発明は、「マルチドメインネットワーク100における、マルチドメインの経路接続方法500」に係る発明であって、マルチドメインネットワークにおいて、データパケットの送信より先に行われることが明らかな、経路の設定段階に係る発明である。
このため、引用発明の「明示的経路オブジェクトERO」(これは、本願発明1の「送信ルートホップリスト」と「ホップリスト」である点では共通するといえる。)は、「経路接続」の段階で送信される「設定リクエスト」に対して付加されるものである。
ここで、一般に、データパケットに、ルートを指定する「ホップリスト」を送信元で付加して送信すること自体は、いわゆる「ソース・ルーチング方式」として、文献を挙げるまでもなく周知技術であるといえる。
しかし、引用文献1には(上記「第4、1(1)」項を参照。)、段落[0001]に、「マルチドメインの経路接続方法500」を、MPLS方式や、GMPLS方式などの各種ネットワークからなるマルチドメインネットワークにも適用できることは記載があるものの、これは「マルチドメインの経路計算方法500」が多様なネットワークに適用できることの開示にとどまるものである。引用文献1には、マルチドメインネットワークに「ソース・ルーチング方式」の周知技術を適用するために、「マルチドメインの経路接続方法500」において、ホップリストである「明示的経路オブジェクトERO」を「設定リクエスト」に付加することに替えて、「送信ルートホップリスト」を「データパケット」に付加するように構成することについては、記載も示唆もない。

イ 引用文献2には(上記「第4、2」項を参照。)、PCE(経路計算エレメント)側において、経路計算結果をキャッシュに記憶することが開示されている。
しかし、引用文献2には、「インタードメイン経路」におけるデータパケットの転送について、所定の「送信ルートホップリスト」を「データパケット」に送信元で付加するという「送信元ルート選択転送」方式に関する、本願発明1の上記[相違点1]に係る構成は記載されていない。

ウ よって、当業者といえども、引用発明及び引用文献2に記載された技術的事項、周知技術から、本願発明1の上記[相違点1]に係る構成を容易に想到することはできない。

(3) まとめ
したがって、本願発明1は、[相違点2]-[相違点5]について検討するまでもなく、当業者であっても、引用発明及び引用文献2に記載された技術的事項、周知技術に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-14について
本願発明2-14は、
本願発明2-7は、本願発明1を減縮した発明であり、
本願発明8は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明1に対応する「エッジノード」の発明であり、
本願発明9は、本願発明8を減縮した発明であり、
本願発明10は、「ネットワークにおける送信元ルート選択転送のための方法」の発明である本願発明1に対応する「送信元ルート選択転送の方法」の発明であり、
本願発明11-13は、本願発明10を減縮した発明であり、
本願発明14は、「送信元ルート選択転送の方法」の発明である本願発明10に対応する「コントローラ」の発明であるから、本願発明1の上記[相違点1]と同様の構成を備えるものである。よって、本願発明2-14も、本願発明1と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項、周知技術に基づいて容易に発明できたものであるとはいえない。

第6 原査定について
1.理由2(特許法第29条第2項)について
本願発明1-14は、審判請求時の補正により、本願発明1の上記[相違点1]に係る事項と同様の構成を有するものとなっており、上記「第5」で述べたのと同様の理由により、当業者であっても、拒絶査定において引用された引用文献1-2に基づいて、容易に発明できたものとはいえない。したがって、原査定の理由を維持することはできない。

2.理由3(特許法第36条第6項第1号)、理由4(特許法第36条第4項第1号)について
審判請求時の補正により、理由3、理由4に係る、請求項8-9、12、18、20がすべて削除されたことにより、原査定の理由3、理由4を維持することはできない。

第7 むすび
以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2019-06-25 
出願番号 特願2016-542991(P2016-542991)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 536- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 速水 雄太西村 純宮田 繁仁  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 稲葉 和生
梶尾 誠哉
発明の名称 協働するネットワークコントローラに基づくマルチドメイン送信元ルート選択転送  
代理人 木内 敬二  
代理人 実広 信哉  

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