【事件の表示】
　特願２００７−　２５５８１「双方向パスの設定方法とそれを実現する通信システムとノード装置」拒絶査定不服審判事件〔平成２０年　８月２１日出願公開，特開２００８−１９３３９５〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１９年２月５日の出願であって，平成２３年１２月２８日付けで拒絶査定がなされ，これに対し平成２４年４月１０日に審判請求がなされるとともに手続補正書が提出され，当審において，同年１０月２４日付けで審尋がなされ，これに対し同年１２月２５日に回答書が提出されたものである。
　
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成２４年４月１０日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正（以下，「本件補正」という。）は，平成２３年５月９日付けの手続補正書の特許請求の範囲の請求項５に記載された，
　
「　【請求項５】
　第１のノードと第２のノードの間に双方向のパスを確立する際の第２のノードにおける双方向パス確立方法であって，
　第１のノードからの，第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを受信し，
　第２のパスの確立を要求する第２のパスメッセージであって，第２のノードにおいて第１のパスメッセージが受信されたときこの第１のパスメッセージの受信に応答する際，第１のパスメッセージから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として挿入された第２のパスメッセージを，第２のノードから第１のノードに送信することを含む方法。」
という発明（以下，「本願発明」という。）を，
　
「　【請求項５】
　第１のノードと第２のノードの間に双方向のパスを確立する際の第２のノードにおける双方向パス確立方法であって，
　第１のノードからの，第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを受信し，
　ＲＳＶＰ−ＴＥ（Resource reservation Protocol-Traffic Engineering）プロトコルにおけるＥＲＯ（Explicit Route Object）を少なくとも含み第２のパスの確立を要求する第２のパスメッセージであって，ＲＳＶＰ−ＴＥプロトコルにおけるＲＲＯ（Record Route Object）を少なくとも含む第１のパスメッセージが第２のノードにおいて受信されたときこの第１のパスメッセージの受信に応答する際，第１のパスメッセージに含まれる前記ＲＲＯから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として前記ＥＲＯに挿入された第２のパスメッセージを，第２のノードから第１のノードに送信することを含む方法。」
という発明（以下，「補正後の発明」という。）に補正することを含むものである。
　
　
２．補正の適否
（１）新規事項の有無，補正の目的
　上記補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内において，補正前の特許請求の範囲の請求項５において，
「第２のパスの確立を要求する第２のパスメッセージ」を「ＲＳＶＰ−ＴＥ（Resource reservation Protocol-Traffic Engineering）プロトコルにおけるＥＲＯ（Explicit Route Object）を少なくとも含み第２のパスの確立を要求する第２のパスメッセージ」として限定し，
「第２のノードにおいて第１のパスメッセージが受信されたとき」を「ＲＳＶＰ−ＴＥプロトコルにおけるＲＲＯ（Record Route Object）を少なくとも含む第１のパスメッセージが第２のノードにおいて受信されたとき」として限定し，
「第１のパスメッセージから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として挿入された第２のパスメッセージ」という構成を「第１のパスメッセージに含まれる前記ＲＲＯから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として前記ＥＲＯに挿入された第２のパスメッセージ」と限定することにより特許請求の範囲を減縮するものであるから，上記補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項），及び同法第１７条の２第４項第２号（補正の目的）の規定に適合している。
　
（２）独立特許要件
　本件補正は，特許請求の範囲の減縮を目的とするものであるから，本件補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて，以下に検討する。
　
［補正後の発明］
　上記「１．本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
［引用発明］
　原審の拒絶理由に引用された特開２００２−１５２２６３号公報（以下，「引用例」という。）には，「ラベル・スイッチング・ルータ」として図面とともに以下の事項が記載されている。
　
イ．「【０００１】
【発明の属する技術分野】本発明は、ラベル・スイッチング・ルータ(Label Switching Router：以下、LSR)に関し、特にLSP(Label Switched Path)の一端に位置するラベル・スイッチング・ルータに関する。」
　
ロ．「【００４２】これにより，上り方向LSPは，従来から行われているように，外部からの要求に応じたQoS保証及びLSP経路を有するようになる。
実施例(1)
実施例(1)は，LSPの一端に位置するラベル・スイッチング・ルータによる１回のLSP設定要求にて双方向LSPを確立する実施例である。
【００４３】図2は，実施例(1)を説明するためのネットワーク構成例(1)を示したものであり，端末A及び端末BがそれぞれLSR1及びLSR3に接続されており，各LSR1〜4は図示の如く接続されてネットワークを構成しているものとする。また，LSR1及びLSR3は，図1のLSR100及びLSR200にそれぞれ相当し，双方向LSP設定機能を有しているものとする。
【００４４】LSR1対し，外部から，端末A−端末B間に対する双方向LSP設定要求S1が発生すると，LSR1のLSP設定受付部10内の双方向LSP設定受付部11がこの要求S1を受け付ける。図3は，このときの双方向LSP設定受付部11の処理フローを示したものである。まず，双方向LSP設定受付部11は，双方向LSP処理部61へLSR3の双方向LSP設定機能の有無識別を問い合せる(ステップS100)。
【００４５】双方向LSP処理部61では，LSR3を図4に示す双方向LSP設定機能無しLSR一覧テーブルより検索し，LSR3がこのテーブルに含まれていないことから，双方向LSP設定機能を有することを，双方向LSP設定受付部11へ通知する。なお，双方向LSP設定機能無しLSR一覧テーブルの登録動作については，実施例(6)で説明する。
【００４６】次に，双方向LSP設定受付部11は，双方向LSP処理部61からの通知に基づきLSR3が双方向LSP設定機能を有していることを認識し(同S110)，メッセージ送信部20に対して，上り方向のラベル要求メッセージの送信を要求する（同S120）。なお，LSR3が双方向LSP設定機能を有していない場合，双方向LSP設定受付部11は外部に対し双方向LSP設定不可通知を送信することになる(同S130)。
【００４７】次に，図5を参照して，双方向LSP設定受付部11から上り方向のラベル要求メッセージ送信要求を受けたメッセージ送信部20の処理動作について説明する。メッセージ送信部20は，内蔵する双方向LSP設定TLV作成部21に対して，双方向LSP設定を行うためにラベル要求メッセージ内に含めるべきベンダー・プライベート(Vendor Private)TLVの作成を要求し（同S200），作成されたベンダー・プライベートTLVを含めた上り方向ラベル要求メッセージを送信する（同S210）。
【００４８】図６は，双方向設定の情報を含めたベンダー・プライベートTLVのフォーマットを示したものである。このベンダー・プライベートTLVは，Uビット，Fビット，タイプ，長さ，ベンダーID，及びデータによって構成されている。本発明で使用するベンダー・プライベートTLVでは，中継LSRがベンダー・プライベートTLVを破棄せずに出口LSRまで中継できるよう，Uビット及びFビットの値は1に固定する。
【００４９】また，ベンダー・プライベートTLVとして使用可能なタイプの値は0x3E00-0x3EFFであるが，実施例(1)では，双方向設定であることを示す値として0x3E00を設定する。また，長さはベンダーIDとデータフィールドの合計をオクテット表示したものであり，データフィールドには，送信元IPアドレス，送信先IPアドレス，プロトコル，送信元ポート番号，及び，送信先ポート番号から成るフロー情報や，後述するトラフィック・パラメータTLV又は明示的ルート・パラメータTLVが必要に応じて設定される。
【００５０】なお，実施例(1)では，下り方向のサービス品質や明示的ルートの指定を行わないこととし，同図のデータフィールドにはトラフィック・パラメータTLV及び明示的ルート・パラメータTLVを含めない。LSR1から送信されたラベル要求メッセージは，LSR2を経由してLSR3によって受信される。
【００５１】図7は，LSR3における，ラベル要求メッセージ受信時のメッセージ受信部30の処理フローを示したものである。まず，メッセージ受信部30は内蔵する双方向LSP設定TLV分析部31に対し，受信したラベル要求メッセージ内のベンダー・プライベートTLVに下り方向LSP設定情報が有るか否かの分析を要求する（同S300）。
【００５２】次に，メッセージ受信部30は，双方向LSP設定TLV分析部31による分析結果を受け，下り方向LSP設定情報の有無を判断する（同S310）。下り方向LSP設定情報が無い場合（双方向LSP設定要求ではない場合），メッセージ受信部30は，MPLS処理部60に対してラベル・マッピング・メッセージの送信を要求する（同S330）。MPLS処理部60では，従来と同様の処理により，ラベル管理部50へラベルの割当を要求し，完了通知を受けると，ラベル設定をスイッチ設定部40に依頼した後，LSR1へラベル・マッピング・メッセージを送信する。
【００５３】下り方向LSP設定情報が有る場合，メッセージ受信部30は，双方向LSP処理部61に対して双方向LSP処理要求を行う（同S320）。図7は，双方向LSP処理部61の処理フローを示したものである。まず，双方向LSP処理部61は，ラベル・マッピング・メッセージが送信済みであるか否かを判定する（同S400）。
【００５４】ラベル・マッピング・メッセージ未送信の場合，双方向LSP処理部61は，LSR1へ送信するラベル・マッピング・メッセージ内に含めるべきベンダー・プライベートTLV内に双方向LSP設定要求を受け付けたことを示す設定受付情報を設定（同S410）した後，MPLS処理部60に対してラベル・マッピング・メッセージの送信を要求する（同S420）。この要求を受けたMPLS処理部60では，従来処理と同様に，LSR1へラベル・マッピング・メッセージを送信する。
【００５５】なお，図9には，設定受付を示すタイプ0x3E02が設定されたベンダー・プライベートTLVのフォーマットが示されている。なお，このベンダー・プライベートTLVには，データフィールドは設定されていない。ラベル・マッピング・メッセージ送信済の場合，双方向LSP処理部61は，上り方向ラベル要求メッセージ内のベンダー・プライベートTLVに明示的ルート情報が存在するか否かを判定する（同S430）。
【００５６】実施例(1)の場合は明示的ルートが存在しないため，双方向LSP処理部61は，明示的ルート作成部62に対し明示的ルートの作成を要求する（同S480）。この場合，明示的ルート作成部62では，上り方向ラベル要求メッセージ内のパス・ベクトルTLVの情報に基づき明示的ルートを作成し，作成完了通知を双方向LSP処理部61へ通知する。
【００５７】これにより，双方向LSP処理部61は，下り方向の明示的ルートを下り方向ラベル要求メッセージ内の明示的ルートTLVに設定する（同S440）。なお，図10は，パス・ベクトルTLVのフォーマットを示したものであり，図示の如くパス・ベクトルであることを示すタイプ0x0104，及び値として上り方向で中継したLSRのIDが設定されている。
【００５８】その後，双方向LSP処理部61では，上り方向ラベル要求メッセージ内のLSPを識別するためのLSP・ID(例えば1)と，下り方向へ送信するラベル要求メッセージ内のLSP・ID(例えば2)との対応関係を記憶し，図11に示す如くLSP・ID対応テーブルに追加する（同S450）。
【００５９】さらに，双方向LSP処理部61では，受信したラベル要求メッセージ内のベンダー・プライベートTLVに含まれる送信元IPアドレス，送信先IPアドレス，プロトコル番号，送信元ポート番号，及び送信先ポート番号をフロー情報として読み出し保持する（同S460）。
【００６０】その後，双方向LSP処理部61では，LSP設定受付部10に対しLSPの設定を要求する（同S470）。その後は，LSP設定受付部10からのメッセージ送信要求により，メッセージ送信部20は，下り方向ラベル要求メッセージを送信する。そして，LSR1よりラベル・マッピング・メッセージを受信すると，LSR3はLSR1の指定による下り方向LSPを確立する。その後，LSR3では確立した下り方向LSPに対して，保持していたフロー情報を設定する。」（５頁８欄８行〜６頁１０欄４８行）
　
　
　上記引用例の記載及び関連する図面並びにこの分野における技術常識を考慮すると，
ａ．上記摘記事項【０００１】段落に「本発明は・・・特にLSP(Label Switched Path)の一端に位置するラベル・スイッチング・ルータに関する。」と記載され，同【００４２】段落に「LSPの一端に位置するラベル・スイッチング・ルータによる１回のLSP設定要求にて双方向LSPを確立する実施例である。」と記載されていることから，引用例には「双方向LSP(Label Switched Path)を確立する方法」について記載されていることがわかり，当該双方向LSPは上記摘記事項【００４２】〜【００４４】段落によれば，端末A及び端末Bがそれぞれ接続されたLSR1とLSR3の間に確立するものである。したがって，引用例に記載されたものは「LSR1とLSR3の間に双方向LSPを確立する方法」である。
ｂ．上記摘記事項【００５６】〜【００５７】段落によれば，上り方向ラベル要求メッセージはパス・ベクトルTLVを有しており，当該パス・ベクトルTLVには上り方向で中継したLSR のIDが設定されており，また，摘記事項【００４７】，【００５０】段落によれば，上り方向ラベル要求メッセージはLSR1から送信されLSR3が受信している。また，上り方向ラベル要求メッセージは，これをLSR3が受信したことによって摘記事項【００５４】段落にあるようにLSR1へラベル・マッピング・データを送信することからして，LSR1からLSR3へのパスの確立を要求するメッセージであるといえる。したがって，引用例に記載されたものは「LSR1からの，LSR1からLSR3へのパスの確立を要求する上り方向ラベル要求メッセージであって，それを上り方向で中継したLSR のIDが設定されたものをLSR3が受信する」ものといえる。
ｃ．上記摘記事項【００６０】段落によれば，下り方向ラベル要求メッセージは下り方向LSPの確立を要求するものであり，また，上記摘記事項【００５７】段落によれば，下り方向ラベル要求メッセージは下り方向の明示的ルートが設定された明示的ルートTLVを含んでいる。
ｄ．上記ｂ．で検討したように，引用例記載のものは，パス・ベクトルTLVを有する上り方向ラベル要求メッセージを，LSR3が受信するものである。この受信に対する応答としての下り方向ラベル要求メッセージの作成は，上記摘記事項【００５６】〜【００５７】段落に「上り方向ラベル要求メッセージ内のパス・ベクトルTLVの情報に基づき明示的ルートを作成し，・・・下り方向の明示的ルートを下り方向ラベル要求メッセージ内の明示的ルートTLVに設定する（同S440）。」と記載され，ここでパス・ベクトルTLVの情報とは上り方向で中継したLSRのIDであることを踏まえれば，上り方向ラベル要求メッセージ内のパス・ベクトルTLVから上り方向で中継したLSRのIDを抽出し，抽出したIDを明示的ルートを示すものとして下り方向ラベル要求メッセージの明示的ルートTLVに設定していると考えるのが自然である。そしてこの下り方向ラベル要求メッセージは，【００６０】段落によればLSR3からLSR1へ送信されることは明らかである。
　
　したがって，上記引用例には以下の発明（以下，「引用発明」という。）が開示されているものと認められる。
　
（引用発明）
「LSR1とLSR3の間に双方向LSPを確立する方法であって，
　LSR1からの，LSR1からLSR3へのパスの確立を要求する上り方向ラベル要求メッセージであって，それを上り方向で中継したLSR のIDが設定された上り方向ラベル要求メッセージをLSR3が受信し，
　明示的ルートTLVを含み下り方向LSPの確立を要求する下り方向ラベル要求メッセージであって，パス・ベクトルTLVを有する上り方向ラベル要求メッセージがLSR3において受信されたときこの上り方向ラベル要求メッセージの受信に応答する際，上り方向ラベル要求メッセージ内のパス・ベクトルTLVから上り方向で中継したLSRのIDを抽出し，抽出したLSRのIDを明示的ルートを示すものとして下り方向ラベル要求メッセージの明示的ルートTLVに設定した下り方向ラベル要求メッセージを，LSR3からLSR1へ送信することを含む方法。」
　
　
［対比］
　補正後の発明と引用発明を対比すると， 
　引用発明の「LSR1」，「LSR3」はその間に双方向のパスが形成されるノードとして機能するから，補正後の発明の「第１のノード」，「第２のノード」にそれぞれ相当する。
　引用発明の「双方向LSP」は，補正後の発明の「双方向のパス」に相当する。
　引用発明の「双方向LSPを確立する方法」は，上り方向ラベル要求メッセージをLSR3が受信し，LSR3が下り方向ラベル要求メッセージ作成し，LSR3がLSR1へ送信する方法であり，これはLSR3の動作を規定しているから「双方向LSPを確立する際のLSR3における双方向LSPを確立する方法」といえ，補正後の発明の「双方向のパスを確立する際の第２のノードにおける双方向パス確立方法」に相当する。
　引用発明の「LSR1からLSR3へのパス」は，補正後の発明の「第１のパス」に相当する。
　引用発明の「上り方向ラベル要求メッセージ」はLSR1からLSR3へのパスの確立を要求するものであるから，補正後の発明において第１のパスの確立を要求する「第１のパスメッセージ」に相当する。
　引用発明の「それを上り方向で中継したLSR のID」は，上り方向ラベル要求メッセージがどのような経路を通ってきたかを記録していると言えるから，補正後の発明の「それが通った経路の記録」に相当する。
　引用発明の「明示的ルートTLV」と補正後の発明の「ＲＳＶＰ−ＴＥ（Resource reservation Protocol-Traffic Engineering）プロトコルにおけるＥＲＯ（Explicit Route Object）」とは「明示的にルートを示す情報」であるという点では共通する。
　引用発明の「下り方向LSP」はLSR3からLSR1へのLSPだから，補正後の発明の「第２のパス」に相当し，引用発明の「下り方向ラベル要求メッセージ」は，下り方向のLSPの確立を要求する点で，補正後の発明の「第２のパスメッセージ」に対応する。
　引用発明の「パス・ベクトルTLV」は，「上り方向で中継したLSRのID」を含むものだから，補正後の発明の「ＲＳＶＰ−ＴＥプロトコルにおけるＲＲＯ（Record Route Object）」とは，「第１のパスメッセージが通った経路の記録を格納するもの」であるという点で共通する。
　そして，引用発明の「上り方向ラベル要求メッセージ内のパス・ベクトルTLVから上り方向で中継したLSRのIDを抽出し，抽出したIDを明示的ルートを示すものとして下り方向ラベル要求メッセージの明示的ルートTLVに設定」することと，補正後の発明における「第１のパスメッセージに含まれる前記ＲＲＯから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として（第２のパスメッセージの）前記ＥＲＯに挿入」することとは，「第１のパスメッセージに含まれる前記第１のパスメッセージが通った経路の記録を格納するものから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として第２のパスメッセージの前記明示的にルートを示す情報に挿入」するという点で対応する。
　
　したがって，両者は以下の点で一致ないし相違する。
　
（一致点）
「第１のノードと第２のノードの間に双方向のパスを確立する際の第２のノードにおける双方向パス確立方法であって，
　第１のノードからの，第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを受信し，
　明示的にルートを示す情報を少なくとも含み第２のパスの確立を要求する第２のパスメッセージであって，第１のパスメッセージが通った経路の記録を格納するものを少なくとも含む第１のパスメッセージが第２のノードにおいて受信されたときこの第１のパスメッセージの受信に応答する際，第１のパスメッセージに含まれる前記第１のパスメッセージが通った経路の記録を格納するものから前記経路の記録を抽出すると共に，抽出した前記経路の記録が経路指定として前記明示的にルートを示す情報に挿入された第２のパスメッセージを，第２のノードから第１のノードに送信することを含む方法。」
　
（相違点）
（１）「明示的にルートを示す情報」が，引用発明では「明示的ルートTLV」であるのに対して，補正後の発明では「ＲＳＶＰ−ＴＥ（Resource reservation Protocol-Traffic Engineering）プロトコルにおけるＥＲＯ（Explicit Route Object）」である点。
（２）「第１のパスメッセージが通った経路の記録を格納するもの」が，引用発明では「パス・ベクトルTLV」であるのに対して，補正後の発明では「ＲＳＶＰ−ＴＥプロトコルにおけるＲＲＯ（Record Route Object）」である点。
　
　
［判断］
　引用発明はLSR（ラベル・スイッチング・ルータ）を有するラベル・スイッチング・ネットワークに関する発明である。ところで，原審の拒絶理由に引用された文献である「松浦伸昭　他，IN2002-37　フォトニックネットワークにおけるシグナリング方法の提案，電子情報通信学会技術研究報告，２００２年７月１１日，第102巻，第213号，p.25〜28」にも開示されているように，ラベル・スイッチングを行うネットワークで，シグナリングプロトコルとしてRSVP-TEを使うことや，Explicit Route Object(ERO)やRecord route Object(RRO)を使用することも周知の技術事項である。
　そうしてみると，ラベル・スイッチング・ネットワークに関する発明である引用発明を，上記文献に記載されたようなRSVP-TEを使うラベル・スイッチングを行う周知のネットワークに適用することは，これらが類似のネットワークであるを勘案すれば，当業者にとって格別の創意工夫を要することなく容易に想到し発明しうる程度の事項にすぎない。そしてこのように周知のネットワークに適用する際に，当該ネットワークには明示的なルート指定を行うEROや，たどったルートを記録するRROが存在するのであるから，明示的ルートTLVやパス・ベクトルTLVをしてこれらを使うようにすることも格別な事項とはいえない。したがって，上記相違点（１）（２）とした点は引用発明を周知のネットワークに適用することによって当業者が容易に想到できた事項である。
　
　そして，補正後の発明が奏する効果も引用発明及び周知技術から容易に予測できる範囲のものである。
　
　よって補正後の発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものである。
　したがって，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
第３．本願発明について
　
１．本願発明
　平成２４年４月１０日付けの手続補正は上記のとおり却下されたので，本願発明は上記「第２．補正却下の決定」の項の中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
　
２．引用発明
　引用発明は，上記「第２．補正却下の決定」の項の中の「（２）独立特許要件」の項中の［引用発明］の項で認定したとおりである。
　
　
３．対比・判断 
　本願発明は，上記補正後の発明から本件補正に係る限定を省いたものである。そうすると，上記「第２．補正却下の決定」の項の中の「（２）独立特許要件」で検討したことを踏まえると，引用発明との相違点であると認定した「ＲＳＶＰ−ＴＥ（Resource reservation Protocol-Traffic Engineering）プロトコルにおけるＥＲＯ（Explicit Route Object）」及び，「ＲＳＶＰ−ＴＥプロトコルにおけるＲＲＯ（Record Route Object）」の特定は本願発明にはないのであるから，本願発明は引用発明に基づいて当業者が容易に発明することができたものである。
　
　
４．むすび
　以上のとおり，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって結論のとおり審決する。