【事件の表示】
　特願２０１８−１９１４４７「通信システム、ノード、制御装置、通信方法及びプログラム」拒絶査定不服審判事件〔平成３１年　１月１０日出願公開、特開２０１９−　　４５２５、請求項の数（９）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続きの経緯
　本願は、２０１１年（平成２３年）９月１２日（優先権主張　平成２２年１２月１日）を国際出願日とする出願である特願２０１２−５２７５３５号の一部を、平成２５年５月２４日に新たな特許出願とした特願２０１３−１０９７０８号の一部を、平成２６年９月１６日に新たな特許出願とした特願２０１４−１８７６５５号の一部を、平成２８年４月２８日に新たな特許出願とした特願２０１６−０９０５０５号の一部を、平成２９年３月９日に新たな特許出願とした特願２０１７−０４４７２５号の一部を、平成３０年１０月１０日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。
　令和元年　７月３１日付け：拒絶理由通知
　令和元年１０月　７日　　：意見書、手続補正書の提出
　令和元年１１月２９日付け：拒絶理由通知
　令和２年　４月　６日　　：意見書、手続補正書の提出
　令和２年　５月　８日付け：拒絶査定（原査定）
　令和２年　８月１９日　　：審判請求書の提出
第２　原査定の概要
　原査定（令和２年５月８日付け拒絶査定）の概要は次のとおりである。
　本願請求項１−９に係る発明は、以下の引用文献１及び２に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
＜引用文献等一覧＞
１．特開２００１−２５１３４３号公報
２．米国特許出願公開第２００９／００４６７３２号明細書
第３　本願発明
　本願請求項１−９に係る発明（以下、それぞれ「本願発明１」−「本願発明９」という。）は、令和２年４月６日になされた手続補正で補正された特許請求の範囲の請求項１−９に記載された事項により特定される発明であり、本願発明１は、以下のとおりの発明である。
「　【請求項１】
　処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、予め設定された、パス識別子と対応付けられた処理規則に従ってパケットを処理する１または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を決定し、
　新規通信フローが発生した場合に、追加ヘッダを受信パケットに追加することを示す第１の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第１のエッジノードに送信し、
　前記追加ヘッダは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む
　ことを特徴とする制御装置。」
　また、本願発明４及び７は、それぞれ本願発明１に対応する通信システム、及び通信方法の発明であり、本願発明１と実質的にカテゴリ表現が異なるだけの発明である。
　また、本願発明２及び３は、本願発明１を減縮した発明であり、本願発明５及び６は、本願発明４を減縮した発明であり、本願発明８及び９は、本願発明７を減縮した発明である。
第４　引用文献、引用発明等
１．引用文献１、引用発明について
　原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている。（下線は、強調のために当審が付与した。以下同様。）
「【０００３】また、ＩＰパケットの転送処理に「ラベル」という新しい概念を導入し、ＩＰレベル（レイヤ３：Ｌ３）でのルーチング処理をＡＴＭ（Asynchronous Transfer Mode）、フレームリレー、及びＥｔｈｅｒｎｅｔ（登録商標）などの下位レイヤ（レイヤ２：Ｌ２）のスイッチング処理で実現する
ＭＰＬＳ（Multi Protocol Label Switching）
「【００３８】〔ラベルスイッチネットワークシステムの第１の具体的構成・動作〕
（第１の具体的構成）図４は上述したような基本構成を採る
ラベルスイッチネットワークシステム
【００３９】図４を参照すると、このシステムにおいては、
ポリシサーバＰＳＶと、複数のラベルスイッチングルータＬＳＲ１…ＬＳＲ５とからラベルスイッチネットワーク（ラベル網）としてのＭＰＬＳネットワークを構成している
【００４０】
ポリシサーバＰＳＶはＭＰＬＳネットワークの入口に配置されたルータＬＳＲ１と物理的な回線（物理リンク）によって接続され、ルータＬＳＲ１…ＬＳＲ５とポリシ制御プロトコル
に則って、状態情報及び設定指示を送受信す
このネットワークの入口に配置されたルータＬＳＲ１とネットワークの出口に配置されたルータＬＳＲ５とは、中継（コア）ルータＬＳＲ２，ＬＳＲ３，ＬＳＲ４及び物理的な回線（物理リンク）を通して接続され
入口ルータＬＳＲ１及び出口ルータＬＳＲ５は、エッジルータと称され
【００４１】このシステムにおけるポリシサーバＰＳＶ及びルータＬＳＲ１…ＬＳＲ５は、図３に基本構成を示すポリシサーバＰＳＶ及びノードＮＤ１…ＮＤ５とそれぞれ同一構成である。ただし、ルータＬＳＲ１…ＬＳＲ５においては、ノードＮＤ１…ＮＤ５を構成するラベルスイッチ機能部２２をＭＰＬＳ機能部２２と呼ぶ。
【００４２】
ポリシサーバＰＳＶは管理者及びルータＬＳＲ１…ＬＳＲ５からの要求、またはトポロジ変化などにより、自発的にＩＰフローのアグリゲート及び明示的な経路を決定し、この決定結果を入口ルータＬＳＲ１に通知す
【００４３】
入口ルータＬＳＲ１はＭＰＬＳネットワークに隣接ＩＰネットワークから到来するＩＰパケット（Ｌ３）をそのフローに応じて、Ｌ２パスのＬＳＰ（Label Switched Path）にマッピングし、ＭＰＬＳネットワーク内に転送する
このルータＬＳＲ１はポリシサーバＰＳＶからの経路決定結果の通知（設定指示）に従って、ＣＲ（Constraint-based Routing）−ＬＤＰ（Label Distribution Protocol）等のラベル配布プロトコルに則り、明示的なＬＳＰの設定または解放を実行す
【００４４】
中継ルータＬＳＲ２，３，４は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたＩＰパケットを高速にスイッチングし、他のルータに転送す
【００４５】
出口ルータＬＳＲ５はラベル付けされたＩＰパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、ＭＰＬＳネットワーク外の隣接のＩＰネットワークに転送する
【００４６】（ＩＰフローアグリゲート指示の動作例）
次に、上記第１の構成を採る
ラベルスイッチネットワークシステムにおけるＩＰフローのアグリゲート指示の動作例について、
【００４７】例えば、図４に示すように、ルータＬＳＲとポリシサーバＰＳＶとから構成されるＭＰＬＳネットワークを考える。ここでは、このネットワークを利用する
ユーザが
ＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知する場合
ここでの要求は動画像通信のための通信回線（帯域）を確保するものであ
【００４８】
この要求は、ポリシサーバＰＳＶが管理するＭＰＬＳネットワークに属するユーザ端末から要求されても、ポリシサーバＰＳＶの管理外の別ネットワークから要求されてもよ
また、
ＭＰＬＳネットワークの外部ネットワークのトポロジ状態が変化し、新しくＩＰフローがＭＰＬＳネットワークに流入することをポリシサーバＰＳＶがルータＬＳＲからの状態通知（状態情報）を検出することを契機にしてもよ
【００４９】手順１１：
ポリシサーバＰＳＶはユーザからの要求をユーザ要求受付処理部１１で受信す
この要求には宛先ＩＰアドレス及び発信元（発側）ＩＰアドレスの情報が含まれ
【００５０】また、ｅｎｄ（末端）のアドレスではなく、中継地点のアドレスであってもよいが、この場合、パス設定は一部分だけとなるが、パス検索の範囲も一部のため処理量が少ないという利点がある。しかし、検索範囲が狭いため、機能的には若干不利な代替手法である。
【００５１】手順１２：
ユーザからの要求には明示的に要求する通信品質が含まれ
【００５２】
また、ユーザ要求が来なくても、新しくルーティングテーブルのエントリが加えられたなど、ネットワーク状態の変化を
検出し、そのエントリに対するＬ２パス設定をユーザ要求とみなすことができ、これを契機にしてもよ
【００５３】手順１３：
ポリシサーバＰＳＶは、宛先及び発信元ＩＰアドレス情報からＩＰフローがＭＰＬＳネットワーク内の入口となるルータＬＳＲ１と出口となるルータＬＳＲ５を発見す
【００５４】ルーティングプロトコルを利用する場合、ポリシサーバＰＳＶがルーティングプロトコルをサポートする必要があるが、差分情報を収集するので、情報量が少なくて済み最良の手法である。
【００５５】ルーティングテーブルの収集は、差分情報が扱い難く、各ルータ毎に情報を収集する必要があるので、処理量及び情報量が多くなるが、代替手法に成り得る。また、予めルーティング情報をポリシサーバＰＳＶに持たせる手法は、上記二つ手法と異なり、動的にネットワークのトポロジが変化した場合には対応できないが、情報を収集する一切の処理が不要なため、最も簡単であり、代替手法に成り得る。
【００５６】手順１４：
各ルータＬＳＲ１…ＬＳＲ５はリンク（物理的回線）の利用状況やユーザによる資源予約状況をＳＮＭＰ（Simple Network Management Protocol）などの状態を通知できるプロトコルを利用してポリシサーバＰＳＶに通知す
ポリシサーバＰＳＶは各ルータＬＳＲから通知されたＭＰＬＳネットワークのリンク状態を収集し、これを管理す
各ルータＬＳＲ間の残り帯域量は、ポリシサーバＰＳＶがルータＬＳＲへパスの設定を指示した帯域をすべて記憶しておくことで、各リンクで設定されている帯域量を算出することができ
【００５７】手順１５：
ポリシサーバＰＳＶはユーザからの要求を受け付けるか否かについて、その要求に含まれているアドレス情報あるいはユーザ情報を基に判断す
要求を拒絶せずに処理する場合に、
新規にパスを設定するか否かの判断処理を行
【００５８】手順１６：
入口ルータＬＳＲ１から出口ルータＬＳＲ５に至る既存パス（既に呼が設定されているパス）が存在し、このパスを利用してユーザの要求するＩＰトラフィックを送信することができる場合には、ポリシサーバＰＳＶは、
入口ルータＬＳＲ１に対してユーザが要求するＩＰフローを既存パスを使って送信するように指示す
【００５９】しかし、
ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、新規にパスを設定しても良い
【００６０】手順１７：
ユーザの要求を満たすことができる入口ルータＬＳＲ１から出口ルータＬＳＲ５に至る経路を、トポロジ状態、ルーティング状態及びリンク状態を用いたダイクストラのアルゴリズムなどを利用して検索す
【００６１】ｔｒａｃｅｒｏｕｔｅの場合、トポロジ及びルーティングテーブルを持たずにパスを検索できる利点があるが、検索に時間がかかり、すべてのルータＬＳＲがｔｒａｃｅｒｏｕｔｅをサポートしている必要がある。したがって、ダイクストラのアルゴリズムなどとトレードオフの代替手法に成り得る。
【００６２】この動作例では、パス検索部１３は
ユーザ要求を満たすパスとして、
ルータＬＳＲ１→ＬＳＲ３→ＬＳＲ５を経由するパスを発見（検索）でき
【００６３】なお、ダイクストラのアルゴリズムの詳細については、文献：ＤｉｍｉｔｒｉＢｅｒｔｓｅｋａｓ, ｅｔ ａｌ., Ｄａｔａ Ｎｅｔｗｏｒｋｓ, ＰＲＥＮＴＩＣＥ−ＨＡＬＬ, １９８７を参照できる。また、ｔｒａｃｅｒｏｕｔｅの詳細については、文献：Ｇ．Ｋｅｓｓｌｅｒ, ｅｔ ａｌ., ＲＦＣ２１５１,Ａ Ｐｒｉｍｅｒ ｏｎ Ｉｎｔｅｒｎｅｔ ａｎｄ　ＴＣＰ／ＩＰ Ｔｏｏｌｓ ａｎｄ Ｕｔｉｌｉｔｉｅｓ， ＩＥＴＦ, １９９７を参照できる。
【００６４】手順１８：
ポリシサーバＰＳＶは発見した経路を明示し、ユーザの要求を満たす品質保証パラメータを含むＬ２のパスを設定するために、ＣＲ−ＬＤＰあるいはＲＳＶＰなどのプロトコルに則るパス設定メッセージをＭＰＬＳネットワークの入口から出口に向かって転送するように、入口ルータＬＳＲ１に指示す
【００６５】手順１９：
入口ルータＬＳＲ１はポリシサーバＰＳＶからの指示を受け取ると、ＣＲ−ＬＤＰあるいはＲＳＶＰなどの明示的なパス設定プロトコルを利用して、出口ルータＬＳＲ５に向かってＬ２パスを設定す
【００６６】手順２０：
入口ルータＬＳＲ１から発せられたパス設定メッセージは中継ルータＬＳＲ３にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータＬＳＲ５に向かって順次送信され
【００６７】手順２１：
ポリシサーバＰＳＶは、Ｌ２パスが設定されたことを認識した後、Ｌ２パスにユーザから要求されたＩＰフローをマッピングする指示をルータＬＳＲに送る
ＩＰフローを識別するための識別子としては、宛先及び送信元ＩＰアドレス、宛先及び送信元ポート番号、プロトコル種別などのＩＰヘッダ情報、あるいはペイロード情報が考えられ
【００６８】
この識別子がＩＰフローと１対１に対応してもよく、
【００６９】手順２２：
ＩＰパケットの転送を実現するためには、ＩＰフローを識別するエントリと転送するＬ２パスとを関連付ける「マッピング」と呼ぶ処理が必要とな
任意のＩＰフローを転送するＬ２パスを選択するために
ＩＰフローを一意に識別するエントリを持つＩＰフロー識別子テーブルＴＢＬ
を用意し、各エントリにはＩＰフローを転送するＬ２パスを一意に関連付けるポインタを用意す
【００７０】
この関連付けが「マッピング」処理であり、これによりエントリにヒットしたＩＰフローがどのＬ２パスを利用するかが、対応関係から判断でき
複数のＩＰフローが同一のＬ２パスを利用して転送される場合は、各ＩＰフローエントリのポインタは同一のＬ２パスを指し
【００７１】
各ルータＬＳＲの動作は、ＩＰパケットがルータに到着した際に、ＩＰフローを識別するエントリにヒットするかどうか、上記ＩＰフロー識別子テーブルＴＢＬを検索す
エントリにヒットした場合、エントリの中には、Ｌ２パスの識別子Ｌ２ＩＤが入っているため、この情報からそのＩＰパケットを転送すべきＬ２パスが求められ
【００７２】
ＩＰフロー（Ｌ３）とＬ２パスとのマッピングが終わると、最終的にユーザの要求するＩＰトラフィックはユーザの要求した品質で送信される
「【図２】
」
「【図３】
」
「【図４】
」
「【図５】
」
「【図６】
」
　したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。
＜引用発明＞
「ポリシサーバＰＳＶと、複数のラベルスイッチングルータＬＳＲ１…ＬＳＲ５とからラベルスイッチネットワーク（ラベル網）としてのＭＰＬＳ（Multi Protocol Label Switching）ネットワークを構成しているラベルスイッチネットワークシステムにおいて、
　ポリシサーバＰＳＶはＭＰＬＳネットワークの入口に配置されたルータＬＳＲ１と物理的な回線（物理リンク）によって接続され、ルータＬＳＲ１…ＬＳＲ５とポリシ制御プロトコルに則って、状態情報及び設定指示を送受信し、このネットワークの入口に配置されたルータＬＳＲ１とネットワークの出口に配置されたルータＬＳＲ５とは、中継（コア）ルータＬＳＲ２，ＬＳＲ３，ＬＳＲ４及び物理的な回線（物理リンク）を通して接続され、入口ルータＬＳＲ１及び出口ルータＬＳＲ５は、エッジルータと称され、
　ポリシサーバＰＳＶは管理者及びルータＬＳＲ１…ＬＳＲ５からの要求、またはトポロジ変化などにより、自発的にＩＰフローのアグリゲート及び明示的な経路を決定し、この決定結果を入口ルータＬＳＲ１に通知し、入口ルータＬＳＲ１はＭＰＬＳネットワークに隣接ＩＰネットワークから到来するＩＰパケット（Ｌ３）をそのフローに応じて、Ｌ２パスのＬＳＰ（Label Switched Path）にマッピングし、ＭＰＬＳネットワーク内に転送するものであって、このルータＬＳＲ１はポリシサーバＰＳＶからの経路決定結果の通知（設定指示）に従って、ＣＲ（Constraint-based Routing）−ＬＤＰ（Label Distribution Protocol）等のラベル配布プロトコルに則り、明示的なＬＳＰの設定または解放を実行し、中継ルータＬＳＲ２，３，４は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたＩＰパケットを高速にスイッチングし、他のルータに転送し、出口ルータＬＳＲ５はラベル付けされたＩＰパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、ＭＰＬＳネットワーク外の隣接のＩＰネットワークに転送するものであり、
　ラベルスイッチネットワークシステムにおけるＩＰフローのアグリゲート指示の動作例について、
　ユーザがＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知する場合、ここでの要求は動画像通信のための通信回線（帯域）を確保するものであり、この要求は、ポリシサーバＰＳＶが管理するＭＰＬＳネットワークに属するユーザ端末から要求されても、ポリシサーバＰＳＶの管理外の別ネットワークから要求されてもよく、また、ＭＰＬＳネットワークの外部ネットワークのトポロジ状態が変化し、新しくＩＰフローがＭＰＬＳネットワークに流入することをポリシサーバＰＳＶがルータＬＳＲからの状態通知（状態情報）を検出することを契機にしてもよく、
　ポリシサーバＰＳＶはユーザからの要求をユーザ要求受付処理部１１で受信し、この要求には宛先ＩＰアドレス及び発信元（発側）ＩＰアドレスの情報が含まれ、
　ユーザからの要求には明示的に要求する通信品質が含まれ、また、ユーザ要求が来なくても、新しくルーティングテーブルのエントリが加えられたなど、ネットワーク状態の変化を検出し、そのエントリに対するＬ２パス設定をユーザ要求とみなすことができ、これを契機にしてもよく、
　ポリシサーバＰＳＶは、宛先及び発信元ＩＰアドレス情報からＩＰフローがＭＰＬＳネットワーク内の入口となるルータＬＳＲ１と出口となるルータＬＳＲ５を発見し、
　各ルータＬＳＲ１…ＬＳＲ５はリンク（物理的回線）の利用状況やユーザによる資源予約状況をＳＮＭＰ（Simple Network Management Protocol）などの状態を通知できるプロトコルを利用してポリシサーバＰＳＶに通知し、ポリシサーバＰＳＶは各ルータＬＳＲから通知されたＭＰＬＳネットワークのリンク状態を収集し、これを管理し、各ルータＬＳＲ間の残り帯域量は、ポリシサーバＰＳＶがルータＬＳＲへパスの設定を指示した帯域をすべて記憶しておくことで、各リンクで設定されている帯域量を算出することができ、
　ポリシサーバＰＳＶはユーザからの要求を受け付けるか否かについて、その要求に含まれているアドレス情報あるいはユーザ情報を基に判断し、要求を拒絶せずに処理する場合に、新規にパスを設定するか否かの判断処理を行い、
　入口ルータＬＳＲ１から出口ルータＬＳＲ５に至る既存パス（既に呼が設定されているパス）が存在し、このパスを利用してユーザの要求するＩＰトラフィックを送信することができる場合には、ポリシサーバＰＳＶは、入口ルータＬＳＲ１に対してユーザが要求するＩＰフローを既存パスを使って送信するように指示し、
　ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、新規にパスを設定しても良く、ユーザの要求を満たすことができる入口ルータＬＳＲ１から出口ルータＬＳＲ５に至る経路を、トポロジ状態、ルーティング状態及びリンク状態を用いたダイクストラのアルゴリズムなどを利用して検索し、ユーザ要求を満たすパスとして、ルータＬＳＲ１→ＬＳＲ３→ＬＳＲ５を経由するパスを発見（検索）でき、
　ポリシサーバＰＳＶは発見した経路を明示し、ユーザの要求を満たす品質保証パラメータを含むＬ２のパスを設定するために、ＣＲ−ＬＤＰあるいはＲＳＶＰなどのプロトコルに則るパス設定メッセージをＭＰＬＳネットワークの入口から出口に向かって転送するように、入口ルータＬＳＲ１に指示し、
　入口ルータＬＳＲ１はポリシサーバＰＳＶからの指示を受け取ると、ＣＲ−ＬＤＰあるいはＲＳＶＰなどの明示的なパス設定プロトコルを利用して、出口ルータＬＳＲ５に向かってＬ２パスを設定し、
　入口ルータＬＳＲ１から発せられたパス設定メッセージは中継ルータＬＳＲ３にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータＬＳＲ５に向かって順次送信され、
　ポリシサーバＰＳＶは、Ｌ２パスが設定されたことを認識した後、Ｌ２パスにユーザから要求されたＩＰフローをマッピングする指示をルータＬＳＲに送り、
　ＩＰフローを識別するための識別子としては、宛先及び送信元ＩＰアドレス、宛先及び送信元ポート番号、プロトコル種別などのＩＰヘッダ情報、あるいはペイロード情報が考えられ、この識別子がＩＰフローと１対１に対応してもよく、
　ＩＰパケットの転送を実現するためには、ＩＰフローを識別するエントリと転送するＬ２パスとを関連付ける「マッピング」と呼ぶ処理が必要となり、任意のＩＰフローを転送するＬ２パスを選択するために、ＩＰフローを一意に識別するエントリを持つＩＰフロー識別子テーブルＴＢＬを用意し、各エントリにはＩＰフローを転送するＬ２パスを一意に関連付けるポインタを用意し、
　この関連付けが「マッピング」処理であり、これによりエントリにヒットしたＩＰフローがどのＬ２パスを利用するかが、対応関係から判断でき、複数のＩＰフローが同一のＬ２パスを利用して転送される場合は、各ＩＰフローエントリのポインタは同一のＬ２パスを指し、
　各ルータＬＳＲの動作は、ＩＰパケットがルータに到着した際に、ＩＰフローを識別するエントリにヒットするかどうか、上記ＩＰフロー識別子テーブルＴＢＬを検索し、エントリにヒットした場合、エントリの中には、Ｌ２パスの識別子Ｌ２ＩＤが入っているため、この情報からそのＩＰパケットを転送すべきＬ２パスが求められ、ＩＰフロー（Ｌ３）とＬ２パスとのマッピングが終わると、最終的にユーザの要求するＩＰトラフィックはユーザの要求した品質で送信される、
　ラベルスイッチネットワークシステムにおけるポリシサーバＰＳＶ。」
２．引用文献２について
　原査定の拒絶の理由に引用された引用文献２には、図面とともに次の事項が記載されている。
「[0048] 
In particular, the network manage 27 may define a set of directed graphs including one or more unidirectional communication paths, assign a graph identifier to each defined directed graph, and may communicate a relevant part of each graph definition to each corresponding network device, which may then update the device-specific, locally stored connection table 69.
the network devices 30 - 50 may then route data packets based on the graph identifier included in the headers or the trailers of the data packets.
each connection table 69 may only store routing information directly related to the corresponding network device, so that the network device does not know the complete definition of a directed graph which includes the network device.
（当審対訳）
「［0048］　
具体的には、ネットワークマネージャ27は、1つまたは複数の単方向通信経路を含む有向グラフのセットを定義し、定義された各有向グラフにグラフ識別子を割り当て、各グラフ定義の関連部分を対応する各ネットワークデバイスに通信することができ、次いで、デバイス固有のローカルに記憶された接続テーブル69を更新することができる
ネットワークデバイス30 - 50は、次いで、データパケットのヘッダまたはトレーラに含まれるグラフ識別子に基づいて、データパケットをルーティングし得
各接続テーブル69は、対応するネットワークデバイスに直接関連するルーティング情報のみを記憶することができ、その結果、ネットワークデバイスは、ネットワークデバイスを含む有向グラフの完全な定義を知らない。
「[0096] If, on the other hand, the procedure 350 determines in the block 354 that the data packet has a low latency requirement (or if the procedure 350 determines in the block 355 that complete path to the target device is unknown), the procedure 350 may identify an appropriate graph in the block 356.Referring back to FIG.7, for example, 
the wireless device 216 may identify the graph 240 as a possible path to the network access point 205B.
the wireless device 216 may store the information sufficient to make this determination in the connection table 69.
Next,
the procedure 350 may attach the graph identifier of the graph 240 to the header or trailer of the data packet.
（当審対訳）
「［0096］　一方、手順350が、ブロック354において、データパケットが低レイテンシ要件を有すると決定した場合(または、手順350が、ブロック355において、ターゲットデバイスへの完全な経路が未知であると決定した場合)、手順350は、ブロック356において適切なグラフを識別することができる。図7に戻って参照されるように、たとえば、
ワイヤレスデバイス216は、ネットワークアクセスポイント205Bへの可能な経路としてグラフ240を識別し得る
ワイヤレスデバイス216は、この決定を行うのに十分な情報を接続テーブル69に記憶し得
次に、
手順350は、グラフ240のグラフ識別子をデータパケットのヘッダまたはトレーラに付加することができる。
「[0097]
The procedure 350 may then identify the next hop in the communication path associated with the graph selected in the block 358 (block 360). Referring again to FIG. 7, 
the device-specific connection table 69 of the wireless device 216 may store the following entry
GRAPH IDENTIFIER NODE
 
GRAPH_240　　　 218
 
GRAPH_240 　　　242
In this particular case, the network device 252 may select between two options, both suitable for routing the data packet along the graph 240.
（当審対訳)
「［0097］　次いで、手順350は、ブロック358(ブロック360)で選択されたグラフに関連する通信経路内の次のホップを識別することができる。再び図７を参照し、
ワイヤレスデバイス216のデバイス固有接続テーブル69は、以下のエントリを記憶し得る
　
グラフＩＤ　　ノード
　
グラフ_240　　　218
　
グラフ_240　　　242
この特定のケースでは、ネットワークデバイス252（当審注：「216」の誤記と認められる)は、両方ともグラフ240に沿ってデータパケットをルーティングするのに適した2つのオプションの間で選択し得る
「[0098] If, in the block 354, the procedure 350 determines that enough information for specifying a complete path for the data packet is available, the procedure 350 may proceed to a block 364 and obtain the path information. For example, when the wireless device 214 (FIG. 7) is sending a data packet to the network access point 205A, the device 214 may retrieve the list including the addresses or other type of identifiers of the network devices 218 and 205A. Next, similar to a step 358 discussed above, the procedure 350 may attach the complete path information to the data packet as an ordered list specifying the network devices 218 and 205A, to continue with the same example. The procedure may then look up the next hop in the generated list (block 368), as illustrated in detail in FIG. 9 with respect to the list 310, for example. The procedure 350 may then proceed to the block 362, in which the network device transmits the data packet to the neighbor identified either in the block 360 or in the block 368.」
（当審対訳）
「［0098］　ブロック354において、プロシージャ350が、データパケットのための完全なパスを指定するための十分な情報が利用可能であると決定した場合、プロシージャ350は、ブロック364に進み、パス情報を取得し得る。例えば、無線装置214(図７)がネットワークアクセスポイント205Aにデータパケットを送信しているとき、デバイス214は、ネットワークデバイス218および205Aのアドレスまたは他のタイプの識別子を含むリストを取り出し得る。次に、上記で説明したステップ358と同様に、手順350は、同じ例を続けるために、ネットワークデバイス218および205Aを指定する順序付きリストとして、完全な経路情報をデータパケットに添付することができる。次いで、手順は、例えば、リスト310に関して図９に詳細に示すように、生成されたリスト(ブロック368)内の次のホップをルックアップすることができる。手順350は、次いで、ブロック362に進むことができ、ここで、ネットワークデバイスは、ブロック360またはブロック368のいずれかにおいて識別されたネイバーにデータパケットを送信する。」
「[0099] Upon receiving the data packet, the neighbor may in turn execute a  routing procedure 400 (FIG. 11) to either receive and process the data packet sent to the neighbor or forward the data packet to the next hop in the communication path. 
The procedure 400 may receive the data packet including the header, the trailer, or other priority-related and routing-related information in a block 402 and may check the type of routing in a block 404. To indicate the type of routing (graph routing, source routing, etc), the wireless protocol may use a flag in the header, for example, or any other known or desired means of signaling the type of information that is to follow in the packet. If the procedure 400 determines that graph routing is used, the procedure 400 may then check whether the graph identified in the header or trailer of the data packet terminates in the device (block 406). Referring back to FIG. 8, the wireless device 242 may, for example, receive a data packet including a graph identifier associated with the graph 290.
In the block 406 of the procedure 400, the wireless device 242 may check the device-specific routing table 69 to see whether the wireless device 242 is listed as a tail of the graph 290. In other words, the wireless device 242 may determine whether the data packets carrying the identification of the graph 290 are sent to the wireless device 242 or merely via the wireless device 242 to another network device.
（当審対訳)
「［0099］　データパケットを受信すると、ネイバーは、次いで、ルーティングプロシージャ400(図１１)を実行し得る。隣接ノードに送信されたデータパケットを受信して処理するか、またはデータパケットを通信経路内の次のホップに転送する。
手順400は、ブロック402において、ヘッダ、トレーラ、または他の優先度関連およびルーティング関連情報を含むデータパケットを受信することができ、ブロック404において、ルーティングのタイプをチェックすることができる。ルーティングのタイプ(グラフルーティング、ソースルーティングなど)を示すために、ワイヤレスプロトコルは、たとえば、ヘッダ中のフラグ、またはパケット中で後続すべき情報のタイプをシグナリングする任意の他の知られているもしくは所望の手段を使用し得る。手順400が、グラフルーティングが使用されると判定した場合、手順400は、データパケットのヘッダまたはトレーラにおいて識別されたグラフがデバイスにおいて終端するかどうかをチェックすることができる(ブロック406)。図8に示すように、ワイヤレスデバイス242は、たとえば、グラフ290に関連するグラフ識別子を含むデータパケットを受信し得る。手順400のブロック406において、ワイヤレスデバイス242は、ワイヤレスデバイス242がグラフ290の末尾としてリストされているかどうかを見るために、デバイス固有ルーティングテーブル69をチェックし得る。言い換えれば、ワイヤレスデバイス242は、グラフ290の識別を搬送するデータパケットがワイヤレスデバイス242に送られるか、または単にワイヤレスデバイス242を介して別のネットワークデバイスに送られるかを決定し得る。
「[0100] Alternatively, the procedure 400 may proceed to a block 412 upon identifying the type of routing as source routing in the block 404. In this case, the procedure 400 may traverse the list to locate the identity of the device executing the procedure 400. As discussed earlier in reference to FIG. 9, the list 310 may sequentially list every intermediate and possibly terminating network device in the corresponding communication path. Upon locating its own identity, the device executing the procedure 400 may then check whether this identity information is the last identity in the list 310 (block 414). It will be appreciated that the other methods of identifying the target or destination network device may also be used. For example, each data packet may include the destination information in addition to the list 310 or the graph identifier. However, the example procedure 400 may derive the target information from the position of the device identity relative to the end of the list 310. The procedure 400 may process or consume the data packet if the device identity is not followed by any information identifying further hops in the list 310 (block 410). Otherwise, the procedure 400 may attempt to extract the address of the next hop (block 416) and, if the procedure 400 finds the address and identifies a neighbor device corresponding to the address (block 417), the procedure 400 may send the data packet to the identified network node (block 418). 
If, on the other hand, the procedure 400 cannot successfully extract the next hop information in the block 417, the procedure 400 may attempt to use an appropriate graph route instead. In at least some of the embodiments, a data packet including source routing information such as the list 310 may additionally include a graph identifier. In this sense, the data packet may specify source routing as a primary routing method and graph routing as a secondary routing method.
（当審対訳）
「［0100］　あるいは、手順400は、ブロック404においてソースルーティングとしてルーティングのタイプを識別すると、ブロック412に進むことができる。この場合、プロシージャ400は、プロシージャ400を実行するデバイスの識別情報を見つけるためにリストをトラバースし得る。図９を参照して先に説明したように、本発明の方法は、以下のステップを含む。リスト310は、対応する通信経路内のすべての中間ネットワークデバイスおよび場合によっては終端ネットワークデバイスを順次リストすることができる。それ自体の識別情報を見つけると、手順400を実行するデバイスは、次いで、この識別情報がリスト310内の最後の識別情報であるかどうかをチェックすることができる(ブロック414)。ターゲットまたは宛先ネットワークデバイスを識別する他の方法も使用できることが理解されよう。たとえば、各データパケットは、リスト310またはグラフ識別子に加えて宛先情報を含み得る。しかしながら、例示的なプロシージャ400は、リスト310の末尾に対するデバイス識別情報の位置からターゲット情報を導出し得る。手順400は、デバイス識別情報の後にリスト310内のさらなるホップを識別する情報が続かない場合、データパケットを処理または消費し得る(ブロック410)。そうでない場合、手順400は、次のホップのアドレスを抽出しようと試みることができ(ブロック416)、手順400がアドレスを見つけ、アドレスに対応する隣接デバイスを識別する場合(ブロック417)、手順400は、識別されたネットワークノードにデータパケットを送ることができる(ブロック418)。
一方、手順400がブロック417において次のホップ情報を成功裏に抽出することができない場合、手順400は、代わりに適切なグラフルートを使用しようと試みることができる。少なくともいくつかの実施形態では、リスト310などのソースルーティング情報を含むデータパケットは、グラフ識別子をさらに含むことができる。この意味で、データパケットは、ソースルーティングを一次ルーティング方法として指定し、グラフルーティングを二次ルーティング方法として指定することができる。
「ＦＩＧ．１
」
「ＦＩＧ．７
」
　したがって、上記引用文献２には、特に上記下線で強調した記載を参照すると、
　データパケットをルーティングするための、データパケットのヘッダまたはトレーラに付加されるグラフ識別子について、当該グラフ識別子は、一意にルーティングのためのパスを指定するものではなく、同じグラフ識別子が付加された場合であっても、ネットワークデバイスが、複数のパスの中から異なるパスを選択することを許容するような識別子である技術的事項が開示されていると認められる。
第５　対比・判断
１．本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア　引用発明の「ＩＰパケット」は本願発明１の「パケット」に相当する。また、引用発明の「ＭＰＬＳネットワークの入口に配置されたルータＬＳＲ１」と、この「ネットワークの出口に配置されたルータＬＳＲ５」は、「エッジルータと称され」るルータであって、
　このうち、「入口ルータＬＳＲ１」は、
「ＭＰＬＳネットワークに隣接ＩＰネットワークから到来するＩＰパケット（Ｌ３）をそのフローに応じて、Ｌ２パスのＬＳＰ（Label Switched Path）にマッピングし、ＭＰＬＳネットワーク内に転送するものであって、このルータＬＳＲ１はポリシサーバＰＳＶからの経路決定結果の通知（設定指示）に従って、ＣＲ（Constraint-based Routing）−ＬＤＰ（Label Distribution Protocol）等のラベル配布プロトコルに則り、明示的なＬＳＰの設定または解放を実行」することから、「処理規則に従いパケットを処理する」と言い得るものである。
　また、「出口ルータＬＳＲ５」は、
「ラベル付けされたＩＰパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、ＭＰＬＳネットワーク外の隣接のＩＰネットワークに転送する」ことから、上記入口ルータと同様に、「処理規則に従いパケットを処理する」と言い得るものである。
　したがって、引用発明の「エッジルータと称され」る当該「入口ルータＬＳＲ１」と「出口ルータＬＳＲ５」は、本願発明１の「処理規則に従いパケットを処理する複数のエッジノード」に相当するといえる。
イ　引用発明では、「ネットワークの入口に配置されたルータＬＳＲ１とネットワークの出口に配置されたルータＬＳＲ５とは、中継（コア）ルータＬＳＲ２，ＬＳＲ３，ＬＳＲ４及び物理的な回線（物理リンク）を通して接続され」ていることから、引用発明の当該「中継（コア）ルータＬＳＲ２，ＬＳＲ３，ＬＳＲ４」は、「入口に配置されたルータＬＳＲ１」と「出口に配置されたルータＬＳＲ５」の間を中継するものである。したがって、引用発明の当該「中継（コア）ルータＬＳＲ２，ＬＳＲ３，ＬＳＲ４」は、本願発明１の「前記複数のエッジノード間を中継」する「１または複数のコアノード」に相当する。
ウ　引用発明では、当該「中継ルータＬＳＲ２，３，４は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたＩＰパケットを高速にスイッチングし、他のルータに転送」するものであり、当該「中継ルータＬＳＲ２，３，４」が当該「ラベル付けされたＩＰパケットを高速にスイッチング」することについて、引用発明では、「各ルータＬＳＲの動作は、ＩＰパケットがルータに到着した際に、ＩＰフローを識別するエントリにヒットするかどうか、上記ＩＰフロー識別子テーブルＴＢＬを検索し、エントリにヒットした場合、エントリの中には、Ｌ２パスの識別子Ｌ２ＩＤが入っているため、この情報からそのＩＰパケットを転送すべきＬ２パスが求められ、ＩＰフロー（Ｌ３）とＬ２パスとのマッピングが終わると、最終的にユーザの要求するＩＰトラフィックはユーザの要求した品質で送信される」とあることから、引用発明の上記「ラベル」と上記「Ｌ２パスの識別子」は同義であって、これらは本願発明１の「パス識別子」に相当する。
　したがって、引用発明の「中継ルータＬＳＲ２，３，４」は「上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたＩＰパケットを高速にスイッチングし、他のルータに転送」することから、本願発明１の「パス識別子と対応付けられた処理規則に従ってパケットを処理する」といえる。
エ　引用発明では、「
ユーザがＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知する場合、
　そして、引用発明の「ポリシサーバＰＳＶ」は、「ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、
新規にパスを設定
ルータＬＳＲ１→ＬＳＲ３→ＬＳＲ５を経由するパスを発見
Ｌ２のパスを設定
パス設定メッセージ
Ｌ２パスを設定
パス設定メッセージ
Ｌ２パスが設定
ＩＰフローを識別するための識別子
　要するに、引用発明は、「ポリシサーバＰＳＶ」が、「ＭＰＬＳネットワーク内の入口となるルータＬＳＲ１」から「出口となるルータＬＳＲ５」までの「ルータＬＳＲ１→ＬＳＲ３→ＬＳＲ５を経由するパスを発見」し、当該「パス」に従って「ＩＰフロー」を転送するための「Ｌ２パス」を「ＩＰフローを識別するための識別子」として「設定」するといえることから、本願発明１の「送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を
決定
定め
オ　上記イ、ウ及びエを踏まえると、引用発明と、本願発明１の「処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、
予め設定された、
決定
定め
カ　引用発明の「ＭＰＬＳネットワークに隣接ＩＰネットワークから到来するＩＰパケット」は、当該ＭＰＬＳネットワークの入口に配置された「入口ルータＬＳＲ１」が受信するパケットであることから、本願発明１の「受信パケット」に相当する。
　また、上記エで示した引用発明の「ユーザがＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知する場合」は、本願発明１の「新規通信フローが発生した場合」に相当する。そして、その場合、上記エで示したように、引用発明の「ポリシサーバＰＳＶ」は、「ユーザの要求を満たす品質保証パラメータを含むＬ２のパスを設定するために、ＣＲ−ＬＤＰあるいはＲＳＶＰなどのプロトコルに則るパス設定メッセージをＭＰＬＳネットワークの入口から出口に向かって転送するように、
入口ルータＬＳＲ１に指示し、入口ルータＬＳＲ１はポリシサーバＰＳＶからの指示を受け取る
追加ヘッダ
追加
ラベル
付加
キ　上記ウ及びエを踏まえると、引用発明の「ラベル」は、「ＩＰフローを識別するための識別子」を含むことは明らかであるから、引用発明と、本願発明１の「前記
追加ヘッダ
ラベル
ク　引用発明の「ポリシサーバＰＳＶ」は、ラベルスイッチネットワークシステムを制御するものといえることから、下記相違点を除き、本願発明１の「制御装置」に相当するといえる。
　したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。
＜一致点＞
「処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、パス識別子と対応付けられた処理規則に従ってパケットを処理する１または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を定め、
　新規通信フローが発生した場合に、ラベルを受信パケットに付加することを示す第１の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第１のエッジノードに送信し、
　前記ラベルは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む
　ことを特徴とする制御装置。」
＜相違点＞
（相違点１）
　「複数のエッジノード」と「１または複数のコアノード」とを含む、「送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子」について、本願発明１では、「予め設定された、」「パス識別子を決定」するものであるのに対し、引用発明では、「ユーザがＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知」し、「ポリシサーバＰＳＶ」が「新規にパスを設定」する際に、「ユーザの要求する通信品質」を「満たすパス」を発見して、「ポリシサーバＰＳＶ」が「Ｌ２パスの識別子」を「定め」ることから、本願発明１のように、「予め設定された、」「パス識別子を決定」するような特定はされていない点。
（相違点２）
　受信パケットにラベルを付加するのに、本願発明１では、「追加ヘッダ」を受信パケットに「追加」するのに対し、引用発明では、「追加ヘッダ」としてラベルを「追加」するものとの特定はされていない点。
＜相違点についての判断＞　
　相違点１について検討する。
　相違点１に係る本願発明１の「予め設定された、」「パス識別子を決定」するという構成は、上記「第５　引用文献、引用発明等」の「２．」で示した引用文献２に記載も示唆もされておらず、本願優先日前に周知技術であるともいえない。
　なお、引用発明については、「ユーザがＩＰ通信（ＩＰフロー）を新しく開始する要求をポリシサーバＰＳＶに通知」し、「ポリシサーバＰＳＶ」が「新規にパスを設定」する際に、「ユーザの要求する通信品質」を「満たすパス」を発見して、「ポリシサーバＰＳＶ」が「Ｌ２パスの識別子」を「設定」することから、当該「Ｌ２パスの識別子」は、「予め設定された」ものではなく、「ユーザがＩＰ通信を新しく開始する要求」を通知した後に、「設定」するものであり、本願発明１とは構成上相違している。
　また、引用発明では、「入口ルータＬＳＲ１から出口ルータＬＳＲ５に至る既存パス（既に呼が設定されているパス）が存在し、このパスを利用してユーザの要求するＩＰトラフィックを送信することができる場合には、ポリシサーバＰＳＶは、入口ルータＬＳＲ１に対してユーザが要求するＩＰフローを既存パスを使って送信するように指示」することも行うことができるが、その場合に使用する「既存パス」は、以前に別のＩＰトラフィックを送信するため設定したパスであって、当該「既存パス」が、今回、ユーザがＩＰ通信を新しく開始する要求をした際のユーザの要求する通信品質を、偶然に満たす場合に、使用することができるパスであるから、当該「既存パス」の「Ｌ２パスの識別子」を使用することは、本願発明１の「予め設定された、」「パス識別子を決定」するものとは異なるものである。
　したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても、引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２．本願発明２及び３について
　本願発明２及び３は、本願発明１を減縮した発明であり、上記相違点１に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
３．本願発明４及び７について
　本願発明４及び７は、それぞれ本願発明１に対応する通信システム、及び通信方法の発明であり、本願発明１と実質的にカテゴリ表現が異なるだけの発明であるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
４．本願発明５及び６について
　本願発明５及び６は、本願発明４を減縮した発明であるから、本願発明４と同様の理由により、当業者であっても、引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
５．本願発明８及び９について
　本願発明８及び９は、本願発明７を減縮した発明であるから、本願発明７と同様の理由により、当業者であっても、引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第６　むすび
　以上のとおり、本願発明１−９は、当業者が引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。