【事件の表示】
　特願２０１３−５０９９５７「ネットワーク、データ転送ノード、通信方法およびプログラム」拒絶査定不服審判事件〔平成２４年１０月１８日国際公開、ＷＯ２０１２／１４１２４１、請求項の数（９）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，２０１２年４月１２日（国内優先による優先権主張　２０１１年４月１３日）を国際出願日とする出願であって，平成２６年８月８日付けで拒絶の理由が通知され，同年１０月２０日付けで手続補正がされ，平成２７年３月２３日付けで拒絶査定（以下「原査定」という。）がされ，これに対し，同年７月７日に拒絶査定不服審判が請求され，その後，当審により同年１２月２４日付けで拒絶の理由が通知され，平成２８年３月７日付けで手続補正がされたものである。
第２　本願発明
　本願の請求項１−９に係る発明は，平成２８年３月７日付けの手続補正で補正された特許請求の範囲の請求項１−９に記載された事項により特定されるものと認められるところ，本願の請求項１に係る発明（以下，「本願発明」という。）は以下のとおりである。
「【請求項１】
　物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する論理ネットワークトポロジ管理部と，
　受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して，パケットの転送先を決定し，受信パケットを送信するパケット処理部と，
　を備えたデータ転送ノードを含み，
　前記論理ネットワークトポロジは，前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報，を適用して生成される
　ことを特徴とするネットワーク。」
第３　原査定の理由について
１．原査定の理由の概要
　原査定の拒絶の理由の概要は，以下のとおりである。
「　この出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
請求項１〜１０に対して，引用文献１，２
備考：
　引用文献１には，リンクや経路に複数のコスト（重み付け情報）を設定し，複数のトポロジーを生成するＭＴ−ＯＳＰＦが記載（１４０９ページ左欄〜１４１０ページ左欄「５．１ ＭＴ−ＯＳＰＦ」，図４，図５）されている。
　そして，引用文献２には，複数のサービス毎のトラヒックをマルチトポロジＯＳＰＦにより生成される異なる経路に分けることが記載（【０００２】〜【０００３】，図８）されており，引用文献１に記載される複数のトポロジーをトラヒックの対応するサービスに基づいて選択することに，格別困難な点は認められない。
　また，経路制御をポリシーに基づいて行うことは，ごく一般的な事項であり，引用文献１記載の複数のトポロジーをポリシーに基づいて生成することは，適宜なし得る事項にすぎない。
　　　　　　　　　　　引　用　文　献　等　一　覧
１.藤枝  俊輔　他，ＵＤＬネットワークに適するＭＲＩＢを用いたＰＩＭ−ＳＭ経路制御の実現，電子情報通信学会論文誌，２００８年１１月　１日，第J91-B巻,第11号，p.1405〜1416
２.特開２０１０−４５６８０号公報」
　また，拒絶査定の備考として，以下の記載がある。
「●理由（特許法第２９条第２項）について
・請求項　１〜１０
・引用文献等　１，２
　出願人は意見書において，「仮に引用文献１に，引用文献２のご指摘箇所の内容を適用しても，ＭＴ−ＯＳＰＦの一般的な内容と，片方向回線を含む場合のメトリックの設定手法が把握されるに過ぎない」旨，主張する。
　しかしながら，引用文献１には，複数のトポロジを生成するＭＴ−ＯＳＰＦが記載され，引用文献２には，複数のサービス毎のトラヒックをマルチトポロジＯＳＰＦにより生成される異なる経路に分けることが記載されている。
　そして，引用文献１記載される，ＭＴ−ＯＳＰＦにより生成される複数のトポロジを用いて，引用文献２に記載される，サービス毎のトラヒックを分ける異なる経路を生成することに，格別困難な点は認められない。
　また，引用文献２においても，複数のサービスと選択すべき経路との対応を管理すべきものであり，経路とトポロジが対応することから，複数のサービスと，選択される経路に対応するトポロジとを対応付けて，その対応関係を管理することは，格別なこととは認められない。
　よって，意見書の主張は採用することができず，本願請求項１〜１０に係る発明は，当業者が容易になし得たものと依然として認められる。」
２．原査定の理由の判断
（１）引用文献等の記載事項
［引用文献等１］
　引用文献等１には，図面とともに以下の事項が記載されている。
ア　「５．１  ＭＴ−ＯＳＰＦ
　ＲＦＣ１５８３［１２］では，リンクまたは経路にＴＯＳ（Ｔｙｐｅ　Ｏｆ　Ｓｅｒｖｉｃｅ）［１３］に応じた複数のメトリックを付与し，ＴＯＳごとに異なる経路を計算する機能が定義されている。しかし，ＩＰのＴＯＳフィールドは実用されなかったため，ＲＦＣ２３２８［１４］はＴＯＳ機能の利用を非推奨とし，ＲＦＣ１５８３との下位互換性のためにパケットフォーマットと機能だけを残した。ＭＴ−ＯＳＰＦはＲＦＣ１５８３のＴＯＳ機能を再利用し，ＯＳＰＦにおいて複数トポロジーを計算する機能を，ＩＰパケットのＴＯＳフィールドとは関係なく任意の用途に用いることを提案している。
　ＭＴ−ＯＳＰＦはリンクや経路に複数のコストを設定し，そこから複数のＳＰＴ（Ｓｈｏｒｔｅｓｔ　Ｐａｔｈ　Ｔｒｅｅ）を計算する。ＴＯＳの代わりに経路計算の対象をトポロジどと呼び，トポロジーの識別子にＭＴ−ＩＤ（Ｍｕｌｔｉ−Ｔｏｐｏｌｏｇｙ　ＩＤ）を利用する。ＭＴ−ＩＤ＝０のトポロジーをデフォルトトポロジーと呼び，一般的なＲＩＢの計算に利用する。それ以外のトポロジーから計算した経路をどのように扱うかは定まっていないが，ＭＴ−ＩＤ＝１はデフォルトマルチキャストトポロジーとして予約されている。本研究では，この提案に沿ってＭＲＩＢの計算にＭＴ−ＩＤ＝１を使用する。
　ＭＴ−ＯＳＰＦでは，以下のＬＳＡ（Ｌｉｎｋ　Ｓｔａｔｅ　Ａｄｖｅｒ−ｔｉｓｅｍｅｎｔ）に複数のメトリックを付与して広告する。
　・ルータＬＳＡ（タイプ１）
　・サマリＬＳＡ（タイプ３，タイプ４）
　・エクスターナルＬＳＡ（タイプ５，タイプ７）
例えばルータＬＳＡでは，図４のように各リンク情報にＭＴ−ＩＤ数を示すフィールドがある。その後ろには各トポロジーのＭＴ−ＩＤとメトリックが続く。なお，ルータＬＳＡのＭＴ−ＩＤフィールドは８ビットであるが，エクスターナルＬＳＡでは１ビットが別の用途に利用されているため，ＭＴ−ＩＤは７ビット空間である。
　経路計算では，ＳＰＴをトポロジーごとに個別に作成する。図５に，二つのトポロジー計算の例を示す。Ａ，Ｂ，Ｃ，Ｄがルータであり，ｘとｙがホストである。ＯＳＰＦでは，あるリンクを経路として利用しないためには十分に大きいメトリックをルータのインタフェースに設定するため，これをＭｎｏ＿ｕｓｅと表記する。ＭＴ−ＩＤ＝０のメトリックによってＲＩＢ用のＳＰＴが計算され，ｘからｙへのユニキャスト経路はｘ⇒Ａ⇒Ｂ⇒ｙになる。同時に，本手法ではＭＴ−ＩＤ＝１のメトリックによってＭＲＩＢ用のＳＰＴを計算する。ｘからｙへのＭＲＩＢはｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと設定される。これにより，ｙがマルチキャスト送信者でｘが受信者の場合，配送木は下流から上流へｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと構築され，トラヒックはｙ⇒Ｂ⇒Ｃ⇒Ｄ⇒Ａ⇒ｘと配送される。
　ＭＴ−ＯＳＰＦのイコールコストマルチパス機能により，ＭＲＩＢに同一メトリックの経路を複数提供することも可能である。マルチキャストにおけるイコールコストマルチパスへの対応はＲＦＣ２９９１［１５］に定義されており，Ｈｉｇｈｅｓｔ　Ｒａｎｄｏｍ　Ｗｅｉｇｈｔ（ＨＲＷ）によってネクストホップ（上流）が決定される，ＰＩＭ−ＳＭでは，同一リンク上で複数のルータが別の上流を選択するとトラヒックが重複するが，ＨＲＷが決定するネクストホップはマルチキャストグループと送信元の組合せごとに全ルータで一意であるため，この問題を回避できる。ＭＴ−ＯＳＰＦのイコールコストマルチパス機能とＨＲＷによるネクストホップの選択により，マルチキャストのトラヒックも負荷分散が可能になる。」
　上記アの記載及び図面（特に図４及び図５）並びにこの分野における技術常識を考慮すると，
ａ　上記アの「ＭＴ−ＯＳＰＦはリンクや経路に複数のコストを設定し，そこから複数のＳＰＴ（Ｓｈｏｒｔｅｓｔ　Ｐａｔｈ　Ｔｒｅｅ）を計算する。」，及び図５並びに関連する記載からは，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄからなるネットワークにおいて，リンクに異なるコスト（メトリック）を付与し，当該異なるコストに基づいて複数の異なるＳＰＴ（Ｓｈｏｒｔｅｓｔ　Ｐａｔｈ　Ｔｒｅｅ）を計算することが見て取れる。ここで，前記「リンク」が，前記ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続であることは図５から明らかであるから，前記「異なるＳＰＴの計算」は，前記ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて行われているといえる。また，計算したＳＰＴはルータにおけるルーティングに用いられるのであるから，当該ルータが前記ＳＰＴを管理することは明らかである。
　したがって，引用文献等１には，「ルータが，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて計算された２以上の異なるＳＰＴを管理する」ことが記載されていると認められる。
ｂ　上記アの「ＭＴ−ＩＤ＝０のメトリックによってＲＩＢ用のＳＰＴが計算され，ｘからｙへのユニキャスト経路はｘ⇒Ａ⇒Ｂ⇒ｙになる。」及び「同時に，本手法ではＭＴ−ＩＤ＝１のメトリックによってＭＲＩＢ用のＳＰＴを計算する。ｘからｙへのＭＲＩＢはｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと設定される。」から，ルータは，受信パケットがユニキャストかマルチキャストか，すなわち受信パケットに応じて，対応するＳＰＴを選択して，パケットの転送先を決定して送信している。
　したがって，引用文献等１には，「ルータが，受信パケットに対応するＳＰＴを選択して，パケットの転送先を決定し，受信パケットを送信する」ことが記載されていると認められる。
ｃ　図５から，引用文献等１には，「ルータを含むネットワーク」が記載されていると認められる。
　以上を総合すると，引用文献等１には以下の発明（以下，「引用発明１」という。）が記載されていると認める。
「　ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて計算された２以上の異なるＳＰＴを管理し，
　受信パケットに対応するＳＰＴを選択して，パケットの転送先を決定し，受信パケットを送信する
　ルータを含む
　ことを特徴とするネットワーク。」
［引用文献等２］
　引用文献等２には，図面とともに以下の事項が記載されている。
イ　「【０００２】
  従来の一般的な，ＩＰ（Internet Protocol）ルーチング技術では，ノード（ルータ）は，送信されたパケットの宛先ＩＰアドレスをもとに，自らが持つルーチングテーブルのエントリを検索し，該当するアドレス値に対し，最長一致の原則に基づき，エントリに記載されたインタフェースからパケットの中継がなされる。つまり，同じアドレス宛のパケットは同じルーチング経路をとるのが一般的である。しかし，同じアドレス（同じネットワーク）宛のパケットでも，そのパケットが用いられるサービスごとにルーチング経路を分けたい場合もある。図８は，比較例となるルーチング経路を示した図である。
【０００３】
  例えば，図８に示すように，サービスネットワーク同士が，バックボーンネットワーク経由で接続されるシステムを考える。ここで，サービスＡとサービスＢというサービスがあり，それぞれのサービスのサーバとクライアントがそれぞれ同じサービスネットワークにある場合，サービスＡのトラヒックもサービスＢのトラヒックも同じ境界ノードを経由し，破線に示す同じルーチング経路をとるのが一般的である。しかし，このように複数のサービスについて同じルーチング経路をとると，どちらか一方のサービスのトラヒック量が増加したときに，もう片方のサービスのトラヒックが影響を受けることもあり，サービスの品質が低下するおそれもある。そこで，図８の実線に示すようにサービスごとに，ルーチング経路を分けることができれば，それぞれのサービスの品質を保つことができ，大変便利である。ここで，このようにルータがサービスごとの経路選択を行う技術として，非特許文献１に開示されるマルチトポロジＯＳＰＦ（Open Shortest Path First）がある。」
　上記イの記載及び図面（特に図８）並びにこの分野における技術常識を考慮すると，引用文献等２には，以下の発明（以下，「引用発明２」という。）が記載されているものと認める。
「ルータが，複数のサービスのトラヒックについて，サービスごとにルーチング経路を分けること。」
（２）対比
　本願発明と引用発明１とを対比すると，
（ア）引用発明１の「ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続」は，本願発明の「物理ネットワークトポロジ」に相当する。また，引用文献等１の図５から明らかなように，引用発明１のＳＰＴ（図５の右側）は，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続（図５の左側）に基づいて計算された，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の論理的な接続関係を表しているから，本願発明の「論理ネットワークトポロジ」に相当する。
　したがって，本願発明と引用発明１とは，「論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係」を管理するか否か，及び「管理」を行う「論理ネットワークトポロジ管理部」を備えるか否かは別として，「物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジを管理」する点で共通する。
（イ）上記（ア）のとおり，引用発明１のＳＰＴは，本願発明の「論理ネットワークトポロジ」に相当する。
　したがって，本願発明と引用発明１とは，受信パケットに対応して選択される論理ネットワークトポロジが「受信パケットが属するデータトラヒックに対応する」か否か，及びパケットの処理を行う主体として「パケット処理部」を備えるか否かは別として，「受信パケットに対応する論理ネットワークトポロジを選択して，パケットの転送先を決定し，受信パケットを送信」する点で共通する。
（ウ）引用発明１の「ルータ」は，本願発明の「データ転送ノード」に相当する。
　以上を総合すると，本願発明と引用発明１とは，以下の点で一致し，また，相違点１ないし４の点で相違している。
（一致点）
「　物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジを管理し，
　受信パケットに対応する論理ネットワークトポロジを選択して，パケットの転送先を決定し，受信パケットを送信する
　データ転送ノード含む
　ことを特徴とするネットワーク。」
（相違点１）
　一致点の「２以上の異なる論理ネットワークトポロジを管理」することに関し，本願発明は，更に，「論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係」を管理するのに対し，引用発明１は，当該構成が明らかではない点。
（相違点２）
　一致点の「受信パケットに対応する論理ネットワークトポロジを選択」することに関し，本願発明は，「受信パケットが属するデータトラヒックに対応する」論理ネットワークトポロジを選択するのに対し，引用発明１は，当該構成が明らかではない点。
（相違点３）
　一致点の「論理ネットワークトポロジ」に関し，本願発明は，「前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報，を適用して生成される」のに対し，引用発明１は，当該構成が明らかではない点。
（相違点４）
　本願発明は，データ転送ノードが，一致点の「物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジを管理」する「論理ネットワークトポロジ管理部」，及び一致点の「受信パケットに対応する論理ネットワークトポロジを選択して，パケットの転送先を決定し，受信パケットを送信」する「パケット処理部」を備えるのに対し，引用発明１は，当該構成が明らかではない点。
（３）判断
　上記相違点について検討する。
（相違点１及び２について）
　上記「（１）引用文献の記載事項」の項で「引用発明２」として認定したとおり，「ルータが，複数のサービスのトラヒックについて，サービスごとにルーチング経路を分けること。」が公知である。
　ここで，引用発明２の「サービスのトラヒック」は，本願発明の「データトラフィック」に相当するものの，引用発明２は，ルーチング経路を分けるために，「論理ネットワークトポロジと，論理ネットワークトポロジを適用するサービス（データトラフィック）との対応関係」を管理するものではない。
　してみると，仮に，引用発明１に，上記引用発明２を適用したとしても，上記相違点１に係る本願発明の構成，すなわち，「物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する」という構成までは導出されない。
　また，それにともない，上記相違点２に係る本願発明の構成，すなわち，「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択」する構成も導出されない。
　また，他に，このような構成を設けることが当業者にとって容易であったと判断すべき理由を発見しない。
（４）小括
　以上のとおりであるから，相違点３及び４について検討するまでもなく，本願発明は，当業者が引用発明１及び引用発明２に基づいて，当業者が容易に発明することができたとはいえない。
　また，本願の請求項６，８，９に係る発明は，本願発明とカテゴリーが異なるに過ぎず，また本願の請求項２−５，７に係る発明は，本願発明ないし本願発明とカテゴリーが異なる発明をさらに限定したものであるので，同様に，当業者が引用発明１及び引用発明２に基づいて容易に発明をすることができたとはいえない。
　よって，本願は，原査定の理由によって拒絶すべきものではない。
第４　当審により通知した拒絶の理由について
１．当審により通知した拒絶の理由の概要
　当審により通知した拒絶の理由（以下，「当審拒絶理由」という。）の概要は，以下のとおりである。
「１．（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
２．（実施可能要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。
３．（明確性）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
●理由１（進歩性）について
・請求項　１，５，７，９，１０
・引用文献等　１
・備考
　引用例１には，ルータ（本願の「データ転送ノード」に相当）を含むネットワークにおける経路制御のための構成として，リンクまたは経路にＴＯＳ（Type Of Service。本願の「データトラフィック」に相当）に応じた複数のメトリックを付与し，ＴＯＳごとに異なる経路を計算すること（以下，「引用発明３」という。［当審注］：番号の重複を避けるために番号を振り直した。以下同じ。）が記載されている（「５．１　ＭＴ−ＯＳＰＦ」参照）。
　また，引用例１の図５からは，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄからなるネットワークにおいて，リンクに異なるメトリックを付与し（図５では，ルータＡとＢとの間のリンクのメトリックが異なっている），当該異なるメトリックに基づいて異なるＳＰＴ（Shortest Path Tree。本願の「２以上の異なる論理ネットワークトポロジ」に相当）を計算すること（以下，「引用発明４」という。）が見て取れ，ＳＰＴを計算する際に，ネットワークを構成する機器同士の物理的な接続関係（本願の「物理ネットワークトポロジ」に相当）を考慮することは当然である。
　してみると，引用発明３において，リンクにＴＯＳに応じた複数のメトリックを付与して経路制御を行うための構成として，引用発明４の，異なるメトリックに基づいて異なるＳＰＴ（Shortest Path Tree。本願の「２以上の異なる論理ネットワークトポロジ」に相当）を計算する構成を適用し，ネットワークを構成する機器同士の物理的な接続関係及びＴＯＳに応じたメトリックに基づいてＴＯＳごとにＳＰＴを計算するよう構成することは，当業者が容易に想到し得たことである。そしてその際，前記ＳＰＴと，当該ＳＰＴを適用するＴＯＳとの対応関係を管理することは当然である。
　また，引用発明３はルータを含むネットワークにおける経路制御のための構成であるから，パケットの経路制御を担うルータが，受信パケットのＴＯＳ（本願の「受信パケットが属するデータトラフィック」に相当）に対応する前記ＳＰＴを選択して，パケットの転送先を決定し，受信パケットを送信することは自明である。
　よって，本願の請求項１，５，７，９，１０に係る発明は，引用例１に記載された発明に基づき，当業者が容易に想到し得たものである。
・請求項　２−４，８
・引用文献等　１
・備考
　引用発明３の「メトリック」は，本願発明の「重み付け情報」に相当し，本願発明の「ポリシー情報」に含まれる。
　また，引用発明３において，リンクまたは経路にＴＯＳ（Type Of Service。本願の「データトラフィック」に相当）に応じた複数のメトリックを付与する以上，ＴＯＳとメトリックとを対応付けて管理することは当然である。
　そして，引用発明３に引用発明４を適用することにより構成される「ネットワークを構成する機器同士の物理的な接続関係及びＴＯＳに応じたメトリックに基づいてＴＯＳごとにＳＰＴを計算する」ことが，本願発明の「前記物理ネットワークトポロジと，前記ポリシー情報とを用いて前記２以上の論理ネットワークトポロジを生成する」ことに相当する。
　よって，本願の請求項２−４，８に係る発明は，引用例１に記載された発明に基づき，当業者が容易に想到し得たものである。
・請求項　６
・引用文献等　１
・備考
　引用発明３は，ＲＦＣ１５８３（ＯＳＰＦ）を前提とするものであるところ，ＯＳＰＦにおいて，経路情報を隣接するルータに通知するとともに，ＳＰＴと他のルータから受信した経路情報とに基づいて，自装置からのパケットの転送先を決定することは，一般的に行われていることに過ぎない。
　よって，本願の請求項６に係る発明は，引用例１に記載された発明に基づき，当業者が容易に想到し得たものである。
・請求項　１，５，７，９，１０
・引用文献等　２
・備考
　引用例２には，バックボーンネットワーク内に，ツリー型トポロジで構成される複数の論理ネットワーク（本願の「論理ネットワークトポロジ」に相当）をサービス（本願の「データトラヒック」に相当）ごとに構築するとともに，各ノードすなわちルータ（本願の「データ転送ノード」に相当）は，当該論理ネットワークごとのルーティングテーブルとして，当該論理ネットワークのサービスＩＤと，その論理ネットワークにおける自身のノードの階層，ルートノードのアドレス，最大ツリー階層数，最大子ノード数，当該サービスの論理ネットワークにおける自身のノードの親ノードのアドレス及び子ノードアドレスを保持し（本願において，「論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する」ことに相当），受信パケットを解析して得られたサービスＩＤに対応する論理ネットワークを選択して，パケットの転送先を決定し，パケットを転送することが記載されている（【０００２】−【０００３】，【００２０】−【００３０】，【００４１】，【００５４】−【００５９】，図１，図４，図７，図８参照）。
　また，引用例２の図１から，論理ネットワークが，バックボーンネットワークのトポロジ（本願の「物理ネットワークトポロジ」に相当）に基づいて生成されることが見て取れる。
　よって，本願の請求項１，５，７，９，１０に係る発明は，引用例２に記載された発明に基づき，当業者が容易に想到し得たものである。
・請求項　２−４，８
・引用文献等　１，２
・備考
　引用例１には，ルータを含むネットワークにおける経路制御のための構成として，リンクまたは経路にＴＯＳ（Type Of Service。本願の「データトラフィック」に相当）に応じた複数のメトリックを付与し，ＴＯＳごとに異なる経路を計算することが記載されている（「５．１　ＭＴ−ＯＳＰＦ」参照）。
　ここで，引用例１の，「メトリック」は，本願発明の「重み付け情報」に相当し，本願発明の「ポリシー情報」に含まれる。
　また，引用例１において，リンクまたは経路にＴＯＳ（Type Of Service。本願の「データトラフィック」に相当）に応じた複数のメトリックを付与する以上，ＴＯＳとメトリックとを対応付けて管理することは当然である。
　してみると，引用例２に記載された発明における，複数の論理ネットワークをサービスごとに構築するための構成として，引用例１に記載された，リンクにＴＯＳに応じた複数のメトリックを付与して経路を計算する構成を適用することは，当業者が容易に想到し得たことである。
　よって，本願の請求項２−４，８に係る発明は，引用例１，２に記載された発明に基づき，当業者が容易に想到し得たものである。
●理由２（実施可能要件）について
　請求項６の「前記経路計算部は，前記論理ネットワークトポロジと，他のデータ転送ノードの経路情報通信部から受信した前記データトラヒックとパケットの転送先との対応関係と，に基づいて，自装置からのパケットの転送先を決定する」なる構成に関し，明細書には，【００３４】に「また経路計算部１２２は，経路情報通信部１２４より，他のデータ転送ノードが計算した経路計算の結果が通知されている場合には，当該計算結果も用いてパケットの転送経路を計算する。」と記載されているのみであって，「他のデータ転送ノードが計算した経路計算の結果」としてどのような情報が通知されるのか，及び当該「他のデータ転送ノードが計算した経路計算の結果」をどのように用いてパケットの転送経路を計算するのかに関して，いずれも明確な記載がない。
　したがって，この出願の発明の詳細な説明は，当業者が請求項６に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。
●理由３（明確性）について
・請求項　８
　請求項８の末尾は「請求項６のデータ転送ノード。」であるが，請求項６は「ネットワーク」の発明である。
　してみると，請求項８に係る発明が「データ転送ノード」であるのか「ネットワーク」であるのか不明確であり，発明を明確に特定することができない。
　したがって，請求項８に係る発明は，明確ではない。（明確性）
（「請求項７のデータ転送ノード。」の誤記と思われる。なお，「●理由１（進歩性）について」においては，誤記であると解釈して判断を行った。）
　　　　　　　　　　　　　＜引用文献等一覧＞
１．藤枝俊輔他，ＵＤＬネットワークに適するＭＲＩＢを用いたＰＩＭ−ＳＭ経路制御の実現，電子情報通信学会論文誌，２００８年１１月１日，第J91-B巻,第11号，p.1405〜1416
２．特開２０１０−４５６８０号公報」
（［当審注］：当審拒絶理由における引用文献等１及び２は，原査定の理由における引用文献１及び２と同一である。）
２．当審拒絶理由の判断
●理由１（進歩性）について
（１）引用文献等の記載事項
　引用文献等１には，図面とともに以下の事項が記載されている。（再掲）
ア　「５．１  ＭＴ−ＯＳＰＦ
　ＲＦＣ１５８３［１２］では，リンクまたは経路にＴＯＳ（Ｔｙｐｅ　Ｏｆ　Ｓｅｒｖｉｃｅ）［１３］に応じた複数のメトリックを付与し，ＴＯＳごとに異なる経路を計算する機能が定義されている。しかし，ＩＰのＴＯＳフィールドは実用されなかったため，ＲＦＣ２３２８［１４］はＴＯＳ機能の利用を非推奨とし，ＲＦＣ１５８３との下位互換性のためにパケットフォーマットと機能だけを残した。ＭＴ−ＯＳＰＦはＲＦＣ１５８３のＴＯＳ機能を再利用し，ＯＳＰＦにおいて複数トポロジーを計算する機能を，ＩＰパケットのＴＯＳフィールドとは関係なく任意の用途に用いることを提案している。
　ＭＴ−ＯＳＰＦはリンクや経路に複数のコストを設定し，そこから複数のＳＰＴ（Ｓｈｏｒｔｅｓｔ　Ｐａｔｈ　Ｔｒｅｅ）を計算する。ＴＯＳの代わりに経路計算の対象をトポロジどと呼び，トポロジーの識別子にＭＴ−ＩＤ（Ｍｕｌｔｉ−Ｔｏｐｏｌｏｇｙ　ＩＤ）を利用する。ＭＴ−ＩＤ＝０のトポロジーをデフォルトトポロジーと呼び，一般的なＲＩＢの計算に利用する。それ以外のトポロジーから計算した経路をどのように扱うかは定まっていないが，ＭＴ−ＩＤ＝１はデフォルトマルチキャストトポロジーとして予約されている。本研究では，この提案に沿ってＭＲＩＢの計算にＭＴ−ＩＤ＝１を使用する。
　ＭＴ−ＯＳＰＦでは，以下のＬＳＡ（Ｌｉｎｋ　Ｓｔａｔｅ　Ａｄｖｅｒ−ｔｉｓｅｍｅｎｔ）に複数のメトリックを付与して広告する。
　・ルータＬＳＡ（タイプ１）
　・サマリＬＳＡ（タイプ３，タイプ４）
　・エクスターナルＬＳＡ（タイプ５，タイプ７）
例えばルータＬＳＡでは，図４のように各リンク情報にＭＴ−ＩＤ数を示すフィールドがある。その後ろには各トポロジーのＭＴ−ＩＤとメトリックが続く。なお，ルータＬＳＡのＭＴ−ＩＤフィールドは８ビットであるが，エクスターナルＬＳＡでは１ビットが別の用途に利用されているため，ＭＴ−ＩＤは７ビット空間である。
　経路計算では，ＳＰＴをトポロジーごとに個別に作成する。図５に，二つのトポロジー計算の例を示す。Ａ，Ｂ，Ｃ，Ｄがルータであり，ｘとｙがホストである。ＯＳＰＦでは，あるリンクを経路として利用しないためには十分に大きいメトリックをルータのインタフェースに設定するため，これをＭｎｏ＿ｕｓｅと表記する。ＭＴ−ＩＤ＝０のメトリックによってＲＩＢ用のＳＰＴが計算され，ｘからｙへのユニキャスト経路はｘ⇒Ａ⇒Ｂ⇒ｙになる。同時に，本手法ではＭＴ−ＩＤ＝１のメトリックによってＭＲＩＢ用のＳＰＴを計算する。ｘからｙへのＭＲＩＢはｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと設定される。これにより，ｙがマルチキャスト送信者でｘが受信者の場合，配送木は下流から上流へｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと構築され，トラヒックはｙ⇒Ｂ⇒Ｃ⇒Ｄ⇒Ａ⇒ｘと配送される。
　ＭＴ−ＯＳＰＦのイコールコストマルチパス機能により，ＭＲＩＢに同一メトリックの経路を複数提供することも可能である。マルチキャストにおけるイコールコストマルチパスへの対応はＲＦＣ２９９１［１５］に定義されており，Ｈｉｇｈｅｓｔ　Ｒａｎｄｏｍ　Ｗｅｉｇｈｔ（ＨＲＷ）によってネクストホップ（上流）が決定される，ＰＩＭ−ＳＭでは，同一リンク上で複数のルータが別の上流を選択するとトラヒックが重複するが，ＨＲＷが決定するネクストホップはマルチキャストグループと送信元の組合せごとに全ルータで一意であるため，この問題を回避できる。ＭＴ−ＯＳＰＦのイコールコストマルチパス機能とＨＲＷによるネクストホップの選択により，マルチキャストのトラヒックも負荷分散が可能になる。」
　上記アの記載及び図面（特に図４及び図５）並びにこの分野における技術常識を考慮すると，
ｄ　上記アの「ＲＦＣ１５８３［１２］では，リンクまたは経路にＴＯＳ（Ｔｙｐｅ　Ｏｆ　Ｓｅｒｖｉｃｅ）［１３］に応じた複数のメトリック（コスト）を付与し，ＴＯＳごとに異なる経路を計算する機能が定義されている。」から，ルータは，受信パケットのＴＯＳに対応してパケットの転送先を決定して送信している。また，上記アの「ＭＴ−ＯＳＰＦはＲＦＣ１５８３のＴＯＳ機能を再利用し，ＯＳＰＦにおいて複数トポロジーを計算する機能を，ＩＰパケットのＴＯＳフィールドとは関係なく任意の用途に用いることを提案している。」から，ＴＯＳは，パケットのＴＯＳフィールドに格納されており，パケットのＴＯＳは，当該ＴＯＳフィールドに基づいて特定されているといえる。
　したがって，引用文献等１には，「ルータが，受信パケットのＴＯＳフィールドに基づいて当該受信パケットのＴＯＳを特定し，当該ＴＯＳに対応して，パケットの転送先を決定し，受信パケットを送信する」ことが記載されていると認められる。
ｅ　図５から，引用文献等１には，「ルータを含むネットワーク」が記載されていると認められる。
　以上を総合すると，引用文献等１には以下の発明（以下，「引用発明５」という。）が記載されていると認める。
「　受信パケットのＴＯＳフィールドに基づいて当該受信パケットのＴＯＳを特定し，当該ＴＯＳに対応して，パケットの転送先を決定し，受信パケットを送信する
　ルータを含む
　ことを特徴とするネットワーク。」
　また，上記アの記載及び図面（特に図４及び図５）並びにこの分野における技術常識を考慮すると，
ｆ　上記アの「ＭＴ−ＯＳＰＦはリンクや経路に複数のコストを設定し，そこから複数のＳＰＴ（Ｓｈｏｒｔｅｓｔ　Ｐａｔｈ　Ｔｒｅｅ）を計算する。」，及び図５並びに関連する記載からは，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄからなるネットワークにおいて，トラヒックがマルチキャストがユニキャストかに応じて，リンクに異なるコスト（メトリック）を付与し，当該異なるコストに基づいて，マルチキャストのトラヒックとユニキャストのトラヒックに対応する複数の異なるＳＰＴ（Shortest Path Tree）を計算することが見て取れる。ここで，前記「リンク」が，前記ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続であることは図５から明らかであるから，前記「異なるＳＰＴの計算」は，前記ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて行われているといえる。また，計算したＳＰＴは，トラヒックがマルチキャストがユニキャストかに応じて行われるルーティングに用いられるのであるから，ネットワークを構成するルータが，前記ＳＰＴをマルチキャストのトラヒック（データトラヒック）及びユニキャストのトラヒック（データトラヒック）に対応付けて管理することは明らかである。
　したがって，引用文献等１には，「ルータが，ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて計算された２以上の異なるＳＰＴと，前記ＳＰＴを適用するデータトラヒックとの対応関係を管理」することが記載されていると認められる。
ｇ　上記アの「ＭＴ−ＩＤ＝０のメトリックによってＲＩＢ用のＳＰＴが計算され，ｘからｙへのユニキャスト経路はｘ⇒Ａ⇒Ｂ⇒ｙになる。」及び「同時に，本手法ではＭＴ−ＩＤ＝１のメトリックによってＭＲＩＢ用のＳＰＴを計算する。ｘからｙへのＭＲＩＢはｘ⇒Ａ⇒Ｄ⇒Ｃ⇒Ｂ⇒ｙと設定される。」から，ルータは，受信パケットがマルチキャストのトラヒック（データトラヒック）に属するかユニキャストのトラヒック（データトラヒック）に属するかに応じて，対応するＳＰＴを選択して，パケットの転送先を決定して送信している。
　したがって，引用文献等１には，「ルータが，受信パケットが属するデータトラヒックに対応するＳＰＴを選択して，パケットの転送先を決定し，受信パケットを送信する」ことが記載されていると認められる。
　以上を総合すると，引用文献等１には以下の発明（以下，「引用発明６」という。）が記載されていると認める。
「　ホストｘ，ｙ及びルータＡ，Ｂ，Ｃ，Ｄの間の物理的な接続に基づいて計算された２以上の異なるＳＰＴと，前記ＳＰＴを適用するトラヒックとの対応関係を管理し，
　受信パケットが属するトラヒックに対応するＳＰＴを選択して，パケットの転送先を決定し，受信パケットを送信すること。」
（２）対比
　本願発明と引用発明５とを対比すると，
（エ）本願明細書の【００３２】の「なお，図６中のＤ１，Ｄ２のデータトラヒック条件は，パケットヘッダの特定のフィールドの値など，データトラヒックを特定するための条件である。」なる記載から，本願発明の「データトラヒック」とは，少なくともパケットヘッダの特定のフィールドの値に基づいて特定されるものを含んでいる。してみると，引用発明５の，受信パケットのＴＯＳフィールドに基づいて特定される当該受信パケットの「ＴＯＳ」は，本願発明の「データトラヒック」に含まれる。また，「受信パケットのＴＯＳ」は「受信パケットが属するＴＯＳ」ともいえる。
　したがって，本願発明と引用発明５とは，受信パケットが属するデータトラヒックに対応して行うパケットの転送先の決定を「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して」行うか否か，及びパケットの処理を行う主体として「パケット処理部」を備えるか否かは別として，「受信パケットが属するデータトラヒックに対応して，パケットの転送先を決定し，受信パケットを送信」する点で共通する。
（オ）引用発明５の「ルータ」は，本願発明の「データ転送ノード」に相当する。
　以上を総合すると，本願発明と引用発明５とは，以下の点で一致し，また，相違点５ないし８の点で相違している。
（一致点）
「　受信パケットが属するデータトラヒックに対応して，パケットの転送先を決定し，受信パケットを送信する
　データ転送ノード含む
　ことを特徴とするネットワーク。」
（相違点５）
　一致点の「データ転送ノード」に関し，本願発明は，更に，「物理ネットワークトポロジに基づいて生成した２以上の異なる論理ネットワークトポロジと，前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する論理ネットワークトポロジ管理部」を備えるのに対し，引用発明５は，当該構成が明らかではない点。
（相違点６）
　一致点の「受信パケットが属するデータトラヒックに対応して，パケットの転送先を決定」することに関し，本願発明は，「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して」行うのに対し，引用発明５は，当該構成が明らかではない点。
（相違点７）
　相違点１の「論理ネットワークトポロジ」に関し，本願発明は，更に，「前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報，を適用して生成される」のに対し，引用発明５は，当該構成が明らかではない点。
（相違点８）
　本願発明は，データ転送ノードが，一致点の「受信パケットに対応する論理ネットワークトポロジを選択して，パケットの転送先を決定し，受信パケットを送信」する「パケット処理部」を備えるのに対し，引用発明５は，当該構成が明らかではない点。
（３）判断
　上記相違点について検討する。
（相違点７について）
　上記引用文献等１及び２のいずれにも，「前記論理ネットワークトポロジは，前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報，を適用して生成される」ことは記載されておらず，引用発明５に，引用発明６を適用したとしても，上記の事項までは導出されない。
　また，他に，このような構成を設けることが当業者にとって容易であったと判断すべき理由を発見しない。
（４）小括
　以上のとおりであるから，相違点５，６及び８について検討するまでもなく，本願発明は，当業者が引用発明５及び引用発明６に基づいて，当業者が容易に発明することができたとはいえない。
　また，本願の請求項６，８，９に係る発明は，本願発明とカテゴリーが異なるに過ぎず，また本願の請求項２−５，７に係る発明は，本願発明ないし本願発明とカテゴリーが異なる発明をさらに限定したものであるので，本願発明と同様に，当業者が引用発明５及び引用発明６に基づいて，当業者が容易に発明することができたとはいえない。
●理由２（実施可能要件）について
　上記手続補正により，補正前の請求項６は削除された。
　よって，当審拒絶理由の「●理由２（実施可能要件）について」は解消した。
●理由３（明確性）について
　上記手続補正により，補正前の請求項８（補正後の請求項７）が引用する請求項６は「データ転送ノード」の発明となったため，補正後の請求項７に係る発明が「データ転送ノード」であることが明確となった。
　よって，当審拒絶理由の「●理由３（明確性）について」は解消した。
　そうすると，もはや本願は，当審拒絶理由のいずれによっても拒絶すべきものではない。
第５　むすび
　以上のとおり，本願は，原査定の理由によって拒絶すべきものではない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。