• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1378308
審判番号 不服2020-11493  
総通号数 263 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-11-26 
種別 拒絶査定不服の審決 
審判請求日 2020-08-19 
確定日 2021-10-12 
事件の表示 特願2018-191447「通信システム、ノード、制御装置、通信方法及びプログラム」拒絶査定不服審判事件〔平成31年 1月10日出願公開、特開2019- 4525、請求項の数(9)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続きの経緯

本願は、2011年(平成23年)9月12日(優先権主張 平成22年12月1日)を国際出願日とする出願である特願2012-527535号の一部を、平成25年5月24日に新たな特許出願とした特願2013-109708号の一部を、平成26年9月16日に新たな特許出願とした特願2014-187655号の一部を、平成28年4月28日に新たな特許出願とした特願2016-090505号の一部を、平成29年3月9日に新たな特許出願とした特願2017-044725号の一部を、平成30年10月10日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。
令和元年 7月31日付け:拒絶理由通知
令和元年10月 7日 :意見書、手続補正書の提出
令和元年11月29日付け:拒絶理由通知
令和2年 4月 6日 :意見書、手続補正書の提出
令和2年 5月 8日付け:拒絶査定(原査定)
令和2年 8月19日 :審判請求書の提出

第2 原査定の概要

原査定(令和2年5月8日付け拒絶査定)の概要は次のとおりである。

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

＜引用文献等一覧＞
1.特開2001-251343号公報
2.米国特許出願公開第2009/0046732号明細書

第3 本願発明

本願請求項1-9に係る発明(以下、それぞれ「本願発明1」-「本願発明9」という。)は、令和2年4月6日になされた手続補正で補正された特許請求の範囲の請求項1-9に記載された事項により特定される発明であり、本願発明1は、以下のとおりの発明である。

「 【請求項1】
処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、予め設定された、パス識別子と対応付けられた処理規則に従ってパケットを処理する1または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を決定し、
新規通信フローが発生した場合に、追加ヘッダを受信パケットに追加することを示す第1の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第1のエッジノードに送信し、
前記追加ヘッダは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む
ことを特徴とする制御装置。」

また、本願発明4及び7は、それぞれ本願発明1に対応する通信システム、及び通信方法の発明であり、本願発明1と実質的にカテゴリ表現が異なるだけの発明である。
また、本願発明2及び3は、本願発明1を減縮した発明であり、本願発明5及び6は、本願発明4を減縮した発明であり、本願発明8及び9は、本願発明7を減縮した発明である。

第4 引用文献、引用発明等

1.引用文献1、引用発明について
原査定の拒絶の理由に引用された引用文献1には、図面とともに次の事項が記載されている。(下線は、強調のために当審が付与した。以下同様。)

「【0003】また、IPパケットの転送処理に「ラベル」という新しい概念を導入し、IPレベル(レイヤ3:L3)でのルーチング処理をATM(Asynchronous Transfer Mode)、フレームリレー、及びEｔheｒneｔ(登録商標)などの下位レイヤ(レイヤ2:L2)のスイッチング処理で実現するMPLS(Multi Protocol Label Switching)技術が注目されている(Rｏｓen,eｔ al.,”Mｕlｔiｐｒｏｔｏcｏl Label Sｗiｔching Aｒchiｔecｔｕｒe”,ｗｏｒk in ｐｒｏgｒeｓｓ(IETF-Dｒafｔ),1999)。」

「【0038】〔ラベルスイッチネットワークシステムの第1の具体的構成・動作〕
(第1の具体的構成)図4は上述したような基本構成を採るラベルスイッチネットワークシステムの第1の具体的構成例を示す。
【0039】図4を参照すると、このシステムにおいては、ポリシサーバPSVと、複数のラベルスイッチングルータLSR1…LSR5とからラベルスイッチネットワーク(ラベル網)としてのMPLSネットワークを構成している。複数のラベルスイッチングルータLSR1…LSR5はネットワーク機器として、図2に示す対応のノードND1…ND5を構成している。
【0040】ポリシサーバPSVはMPLSネットワークの入口に配置されたルータLSR1と物理的な回線(物理リンク)によって接続され、ルータLSR1…LSR5とポリシ制御プロトコルCOPSに則って、状態情報及び設定指示を送受信する。このネットワークの入口に配置されたルータLSR1とネットワークの出口に配置されたルータLSR5とは、中継(コア)ルータLSR2,LSR3,LSR4及び物理的な回線(物理リンク)を通して接続されている。入口ルータLSR1及び出口ルータLSR5は、エッジルータと称されることもあり、他のIPネットワーク(図示省略)にそれぞれ接続される。
【0041】このシステムにおけるポリシサーバPSV及びルータLSR1…LSR5は、図3に基本構成を示すポリシサーバPSV及びノードND1…ND5とそれぞれ同一構成である。ただし、ルータLSR1…LSR5においては、ノードND1…ND5を構成するラベルスイッチ機能部22をMPLS機能部22と呼ぶ。
【0042】ポリシサーバPSVは管理者及びルータLSR1…LSR5からの要求、またはトポロジ変化などにより、自発的にIPフローのアグリゲート及び明示的な経路を決定し、この決定結果を入口ルータLSR1に通知する。なお、どのような決定を行うかと言ったポリシは予めディレクトリサーバに登録されていて、ポリシサーバPSVは必要に応じてキャシュしている。
【0043】入口ルータLSR1はMPLSネットワークに隣接IPネットワークから到来するIPパケット(L3)をそのフローに応じて、L2パスのLSP(Label Switched Path)にマッピングし、MPLSネットワーク内に転送する。このルータLSR1はポリシサーバPSVからの経路決定結果の通知(設定指示)に従って、CR(Constraint-based Routing)-LDP(Label Distribution Protocol)等のラベル配布プロトコルに則り、明示的なLSPの設定または解放を実行する。
【0044】中継ルータLSR2,3,4は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたIPパケットを高速にスイッチングし、他のルータに転送する。
【0045】出口ルータLSR5はラベル付けされたIPパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、MPLSネットワーク外の隣接のIPネットワークに転送する。
【0046】(IPフローアグリゲート指示の動作例)
次に、上記第1の構成を採るラベルスイッチネットワークシステムにおけるIPフローのアグリゲート指示の動作例について、図3,図4,図5及び図6を併用して説明する。図5はIPフローとL2パスとのマッピング手法を説明するための図である。また、図6はIPフローのアグリゲート指示の動作のフローチャートである。
【0047】例えば、図4に示すように、ルータLSRとポリシサーバPSVとから構成されるMPLSネットワークを考える。ここでは、このネットワークを利用するユーザが20Mbｐｓの帯域を要するIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知する場合を考える。一例として、ここでの要求は動画像通信のための通信回線(帯域)を確保するものである。
【0048】この要求は、ポリシサーバPSVが管理するMPLSネットワークに属するユーザ端末から要求されても、ポリシサーバPSVの管理外の別ネットワークから要求されてもよい。また、ユーザからの要求以外にも、MPLSネットワークの外部ネットワークのトポロジ状態が変化し、新しくIPフローがMPLSネットワークに流入することをポリシサーバPSVがルータLSRからの状態通知(状態情報)を検出することを契機にしてもよい。
【0049】手順11:ポリシサーバPSVはユーザからの要求をユーザ要求受付処理部11で受信する。通信先が一台のホストの場合、この要求には宛先IPアドレス及び発信元(発側)IPアドレスの情報が含まれているものとする。また、同一のサブネットに属する複数台のホストに対する(またはホストからの)要求である場合には、宛先及び発信元IPアドレスはネットワークアドレスである。これらはいずれであっても同様に処理できる。
【0050】また、end(末端)のアドレスではなく、中継地点のアドレスであってもよいが、この場合、パス設定は一部分だけとなるが、パス検索の範囲も一部のため処理量が少ないという利点がある。しかし、検索範囲が狭いため、機能的には若干不利な代替手法である。
【0051】手順12:ユーザからの要求には明示的に要求する通信品質が含まれているものとする。通信品質とは、帯域や遅延、遅延揺らぎ、廃棄率などである。ここでは、ユーザから20Mbｐｓの帯域を保証する要求があった場合を考える。ユーザの要求に明示的に通信品質が含まれていない場合は、要求あるいはIPパケットに含まれるアドレス情報やIP通信を利用するアプリケーション情報からポリシサーバPSVが通信品質を適切に決定しても良いが、この場合、ユーザが望む品質になるわけではない。
【0052】また、ユーザ要求が来なくても、新しくルーティングテーブルのエントリが加えられたなど、ネットワーク状態の変化をネットワーク資源状態管理部10を通してイベント検出部12で検出し、そのエントリに対するL2パス設定をユーザ要求とみなすことができ、これを契機にしてもよい。
【0053】手順13:ポリシサーバPSVは、宛先及び発信元IPアドレス情報からIPフローがMPLSネットワーク内の入口となるルータLSR1と出口となるルータLSR5を発見する機能を持つ。この機能は、事前にポリシサーバPSVがOSPF(Open Shortest Path First)またはBGP(Border Gateway Protocol)などのIPルーティングプロトコルにより収集したトポロジ・ルーティング情報を基に決定しても良く、ルータのルーティングテーブルを収集して決定しても良く、あるいは予め実際のトポロジと同一の情報をポリシサーバPSVに与えておいても良い。
【0054】ルーティングプロトコルを利用する場合、ポリシサーバPSVがルーティングプロトコルをサポートする必要があるが、差分情報を収集するので、情報量が少なくて済み最良の手法である。
【0055】ルーティングテーブルの収集は、差分情報が扱い難く、各ルータ毎に情報を収集する必要があるので、処理量及び情報量が多くなるが、代替手法に成り得る。また、予めルーティング情報をポリシサーバPSVに持たせる手法は、上記二つ手法と異なり、動的にネットワークのトポロジが変化した場合には対応できないが、情報を収集する一切の処理が不要なため、最も簡単であり、代替手法に成り得る。
【0056】手順14:各ルータLSR1…LSR5はリンク(物理的回線)の利用状況やユーザによる資源予約状況をSNMP(Simple Network Management Protocol)などの状態を通知できるプロトコルを利用してポリシサーバPSVに通知する手段を有する。ポリシサーバPSVは各ルータLSRから通知されたMPLSネットワークのリンク状態を収集し、これを管理する機能を持つ。この動作例では、各ルータLSR間の残り帯域量は、ポリシサーバPSVがルータLSRへパスの設定を指示した帯域をすべて記憶しておくことで、各リンクで設定されている帯域量を算出することができる。
【0057】手順15:ポリシサーバPSVはユーザからの要求を受け付けるか否かについて、その要求に含まれているアドレス情報あるいはユーザ情報を基に判断するためにユーザ要求受付処理部11を有する。この動作例では、ユーザからの要求を受け付けることをポリシサーバPSVで判断する。要求を拒絶せずに処理する場合に、L2パス作成判断部14は新規にパスを設定するか否かの判断処理を行う。
【0058】手順16:入口ルータLSR1から出口ルータLSR5に至る既存パス(既に呼が設定されているパス)が存在し、このパスを利用してユーザの要求するIPトラフィックを送信することができる場合には、ポリシサーバPSVは、設定送信部16により入口ルータLSR1に対してユーザが要求するIPフローを既存パスを使って送信するように指示することができる。
【0059】しかし、ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、新規にパスを設定しても良い。この動作例では、既存の15Mbｐｓの帯域を持つパスではユーザの要求を満たすことができないとポリシサーバPSVが判断し、新規にパスを設定する処理に移る。
【0060】手順17:ユーザの要求を満たすことができる入口ルータLSR1から出口ルータLSR5に至る経路を、トポロジ状態、ルーティング状態及びリンク状態を用いたダイクストラのアルゴリズムなどを利用して検索する。また、他のパス検索アルゴリズムや、ｔｒaceｒｏｕｔeを用いた検索方法でもよい。
【0061】ｔｒaceｒｏｕｔeの場合、トポロジ及びルーティングテーブルを持たずにパスを検索できる利点があるが、検索に時間がかかり、すべてのルータLSRがｔｒaceｒｏｕｔeをサポートしている必要がある。したがって、ダイクストラのアルゴリズムなどとトレードオフの代替手法に成り得る。
【0062】この動作例では、パス検索部13はユーザ要求を満たすパスとして、ダイクストラのアルゴリズムから、ルータLSR1→LSR3→LSR5を経由するパスを発見(検索)できる。
【0063】なお、ダイクストラのアルゴリズムの詳細については、文献:DimiｔｒiBeｒｔｓekaｓ, eｔ al., Daｔa Neｔｗｏｒkｓ, PRENTICE-HALL, 1987を参照できる。また、ｔｒaceｒｏｕｔeの詳細については、文献:G.Keｓｓleｒ, eｔ al., RFC2151,A Pｒimeｒ ｏn Inｔeｒneｔ and TCP/IP Tｏｏlｓ and Uｔiliｔieｓ, IETF, 1997を参照できる。
【0064】手順18:ポリシサーバPSVは発見した経路を明示し、ユーザの要求を満たす品質保証パラメータを含むL2のパスを設定するために、CR-LDPあるいはRSVPなどのプロトコルに則るパス設定メッセージをMPLSネットワークの入口から出口に向かって転送するように、入口ルータLSR1に指示する。この動作例では、ポリシサーバPSVはLSR1→LSR3→LSR5を経由する経路を通る帯域20Mbｐｓのパスを設定するように、入口ルータLSR1にCOPSプロトコルを利用して指示する。
【0065】手順19:入口ルータLSR1はポリシサーバPSVからの指示を受け取ると、CR-LDPあるいはRSVPなどの明示的なパス設定プロトコルを利用して、出口ルータLSR5に向かってL2パスを設定する機能(設定処理部20,MPLS機能部22)を持っている。
【0066】手順20:入口ルータLSR1から発せられたパス設定メッセージは中継ルータLSR3にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータLSR5に向かって順次送信される。
【0067】手順21:ポリシサーバPSVは、L2パスが設定されたことを認識した後、L2パスにユーザから要求されたIPフローをマッピングする指示をルータLSRに送る。このとき、IPフローを識別するための識別子としては、宛先及び送信元IPアドレス、宛先及び送信元ポート番号、プロトコル種別などのIPヘッダ情報、あるいはペイロード情報が考えられる。
【0068】この識別子がIPフローと1対1に対応してもよく、また複数フローを一つの識別子で指定する場合は、IPアドレスマスクを使ったネットワークアドレス単位でのIPフローの指定など、ワイルドカードを使った識別子で複数のIPフローを指定しても良い。これらは互いに等位の代替手法である。
【0069】手順22:IPパケットの転送を実現するためには、IPフローを識別するエントリと転送するL2パスとを関連付ける「マッピング」と呼ぶ処理が必要となる。任意のIPフローを転送するL2パスを選択するためには、例えば、IPフローを一意に識別するエントリを持つIPフロー識別子テーブルTBL(図5参照)を用意し、各エントリにはIPフローを転送するL2パスを一意に関連付けるポインタを用意する。
【0070】この関連付けが「マッピング」処理であり、これによりエントリにヒットしたIPフローがどのL2パスを利用するかが、対応関係から判断できる。複数のIPフローが同一のL2パスを利用して転送される場合は、各IPフローエントリのポインタは同一のL2パスを指している。他のL2パスについても、同様である。
【0071】各ルータLSRの動作は、IPパケットがルータに到着した際に、IPフローを識別するエントリにヒットするかどうか、上記IPフロー識別子テーブルTBLを検索する。エントリにヒットした場合、エントリの中には、L2パスの識別子L2IDが入っているため、この情報からそのIPパケットを転送すべきL2パスが求められる。
【0072】IPフロー(L3)とL2パスとのマッピングが終わると、最終的にユーザの要求するIPトラフィックはユーザの要求した品質で送信される。・・・(後略)」

「【図2】

」

「【図3】

」

「【図4】

」

「【図5】

」

「【図6】

」

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

＜引用発明＞
「ポリシサーバPSVと、複数のラベルスイッチングルータLSR1…LSR5とからラベルスイッチネットワーク(ラベル網)としてのMPLS(Multi Protocol Label Switching)ネットワークを構成しているラベルスイッチネットワークシステムにおいて、
ポリシサーバPSVはMPLSネットワークの入口に配置されたルータLSR1と物理的な回線(物理リンク)によって接続され、ルータLSR1…LSR5とポリシ制御プロトコルに則って、状態情報及び設定指示を送受信し、このネットワークの入口に配置されたルータLSR1とネットワークの出口に配置されたルータLSR5とは、中継(コア)ルータLSR2,LSR3,LSR4及び物理的な回線(物理リンク)を通して接続され、入口ルータLSR1及び出口ルータLSR5は、エッジルータと称され、
ポリシサーバPSVは管理者及びルータLSR1…LSR5からの要求、またはトポロジ変化などにより、自発的にIPフローのアグリゲート及び明示的な経路を決定し、この決定結果を入口ルータLSR1に通知し、入口ルータLSR1はMPLSネットワークに隣接IPネットワークから到来するIPパケット(L3)をそのフローに応じて、L2パスのLSP(Label Switched Path)にマッピングし、MPLSネットワーク内に転送するものであって、このルータLSR1はポリシサーバPSVからの経路決定結果の通知(設定指示)に従って、CR(Constraint-based Routing)-LDP(Label Distribution Protocol)等のラベル配布プロトコルに則り、明示的なLSPの設定または解放を実行し、中継ルータLSR2,3,4は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたIPパケットを高速にスイッチングし、他のルータに転送し、出口ルータLSR5はラベル付けされたIPパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、MPLSネットワーク外の隣接のIPネットワークに転送するものであり、
ラベルスイッチネットワークシステムにおけるIPフローのアグリゲート指示の動作例について、
ユーザがIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知する場合、ここでの要求は動画像通信のための通信回線(帯域)を確保するものであり、この要求は、ポリシサーバPSVが管理するMPLSネットワークに属するユーザ端末から要求されても、ポリシサーバPSVの管理外の別ネットワークから要求されてもよく、また、MPLSネットワークの外部ネットワークのトポロジ状態が変化し、新しくIPフローがMPLSネットワークに流入することをポリシサーバPSVがルータLSRからの状態通知(状態情報)を検出することを契機にしてもよく、
ポリシサーバPSVはユーザからの要求をユーザ要求受付処理部11で受信し、この要求には宛先IPアドレス及び発信元(発側)IPアドレスの情報が含まれ、
ユーザからの要求には明示的に要求する通信品質が含まれ、また、ユーザ要求が来なくても、新しくルーティングテーブルのエントリが加えられたなど、ネットワーク状態の変化を検出し、そのエントリに対するL2パス設定をユーザ要求とみなすことができ、これを契機にしてもよく、
ポリシサーバPSVは、宛先及び発信元IPアドレス情報からIPフローがMPLSネットワーク内の入口となるルータLSR1と出口となるルータLSR5を発見し、
各ルータLSR1…LSR5はリンク(物理的回線)の利用状況やユーザによる資源予約状況をSNMP(Simple Network Management Protocol)などの状態を通知できるプロトコルを利用してポリシサーバPSVに通知し、ポリシサーバPSVは各ルータLSRから通知されたMPLSネットワークのリンク状態を収集し、これを管理し、各ルータLSR間の残り帯域量は、ポリシサーバPSVがルータLSRへパスの設定を指示した帯域をすべて記憶しておくことで、各リンクで設定されている帯域量を算出することができ、
ポリシサーバPSVはユーザからの要求を受け付けるか否かについて、その要求に含まれているアドレス情報あるいはユーザ情報を基に判断し、要求を拒絶せずに処理する場合に、新規にパスを設定するか否かの判断処理を行い、
入口ルータLSR1から出口ルータLSR5に至る既存パス(既に呼が設定されているパス)が存在し、このパスを利用してユーザの要求するIPトラフィックを送信することができる場合には、ポリシサーバPSVは、入口ルータLSR1に対してユーザが要求するIPフローを既存パスを使って送信するように指示し、
ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、新規にパスを設定しても良く、ユーザの要求を満たすことができる入口ルータLSR1から出口ルータLSR5に至る経路を、トポロジ状態、ルーティング状態及びリンク状態を用いたダイクストラのアルゴリズムなどを利用して検索し、ユーザ要求を満たすパスとして、ルータLSR1→LSR3→LSR5を経由するパスを発見(検索)でき、
ポリシサーバPSVは発見した経路を明示し、ユーザの要求を満たす品質保証パラメータを含むL2のパスを設定するために、CR-LDPあるいはRSVPなどのプロトコルに則るパス設定メッセージをMPLSネットワークの入口から出口に向かって転送するように、入口ルータLSR1に指示し、
入口ルータLSR1はポリシサーバPSVからの指示を受け取ると、CR-LDPあるいはRSVPなどの明示的なパス設定プロトコルを利用して、出口ルータLSR5に向かってL2パスを設定し、
入口ルータLSR1から発せられたパス設定メッセージは中継ルータLSR3にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータLSR5に向かって順次送信され、
ポリシサーバPSVは、L2パスが設定されたことを認識した後、L2パスにユーザから要求されたIPフローをマッピングする指示をルータLSRに送り、
IPフローを識別するための識別子としては、宛先及び送信元IPアドレス、宛先及び送信元ポート番号、プロトコル種別などのIPヘッダ情報、あるいはペイロード情報が考えられ、この識別子がIPフローと1対1に対応してもよく、
IPパケットの転送を実現するためには、IPフローを識別するエントリと転送するL2パスとを関連付ける「マッピング」と呼ぶ処理が必要となり、任意のIPフローを転送するL2パスを選択するために、IPフローを一意に識別するエントリを持つIPフロー識別子テーブルTBLを用意し、各エントリにはIPフローを転送するL2パスを一意に関連付けるポインタを用意し、
この関連付けが「マッピング」処理であり、これによりエントリにヒットしたIPフローがどのL2パスを利用するかが、対応関係から判断でき、複数のIPフローが同一のL2パスを利用して転送される場合は、各IPフローエントリのポインタは同一のL2パスを指し、
各ルータLSRの動作は、IPパケットがルータに到着した際に、IPフローを識別するエントリにヒットするかどうか、上記IPフロー識別子テーブルTBLを検索し、エントリにヒットした場合、エントリの中には、L2パスの識別子L2IDが入っているため、この情報からそのIPパケットを転送すべきL2パスが求められ、IPフロー(L3)とL2パスとのマッピングが終わると、最終的にユーザの要求するIPトラフィックはユーザの要求した品質で送信される、
ラベルスイッチネットワークシステムにおけるポリシサーバPSV。」

2.引用文献2について
原査定の拒絶の理由に引用された引用文献2には、図面とともに次の事項が記載されている。

「[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. As explained in more detail below, 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. If desired, 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. In other words, the network device may not "see" the network beyond its immediate neighbors and, in this sense, the network device may be unaware of the complete topology of the wireless network 14. For example, the router device 60 illustrated in FIG. 1 may store a connection table 69A, which may only specify the routing information related to the neighboring network devices 32, 36, 50, and 34. Meanwhile, the WHA 50A may store a connection table 69B, which accordingly may specify the routing information related to the neighbors of the WHA 50A.」
(当審対訳)
「[0048] 具体的には、ネットワークマネージャ27は、1つまたは複数の単方向通信経路を含む有向グラフのセットを定義し、定義された各有向グラフにグラフ識別子を割り当て、各グラフ定義の関連部分を対応する各ネットワークデバイスに通信することができ、次いで、デバイス固有のローカルに記憶された接続テーブル69を更新することができる。以下でより詳細に説明するように、ネットワークデバイス30 - 50は、次いで、データパケットのヘッダまたはトレーラに含まれるグラフ識別子に基づいて、データパケットをルーティングし得る。必要に応じて、各接続テーブル69は、対応するネットワークデバイスに直接関連するルーティング情報のみを記憶することができ、その結果、ネットワークデバイスは、ネットワークデバイスを含む有向グラフの完全な定義を知らない。言い換えれば、ネットワークデバイスは、そのすぐ隣のものを越えてネットワークを見ることができず、この意味で、ネットワークデバイスは、ワイヤレスネットワーク14の完全なトポロジを知らないことがある。例えば、図1に示すルータ装置60は、近隣ネットワークデバイス32、36、50、および34に関連するルーティング情報のみを指定し得る接続テーブル69Aを記憶し得る。一方、WirelessHARTアダプタ(WHA) 50Aは、接続テーブル69Bを格納することができ、それに応じて、WHA 50Aの近隣に関するルーティング情報を指定することができる。」

「[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. As discussed above, the wireless device 216 may store the information sufficient to make this determination in the connection table 69. Next, in a block 358, the procedure 350 may attach the graph identifier of the graph 240 to the header or trailer of the data packet. It will be appreciated that, in general, the protocol servicing the wireless network (such as the WirelessHART protocol 70, for example) may provide various efficient means of associated routing information with a data packet. Thus, one of ordinary skill in the art will appreciate that the specific example of inserting the graph identifier into the header or trailer of a data packet is provided by way of example only, and that other alternatives are also contemplated.」
(当審対訳)
「[0096] 一方、手順350が、ブロック354において、データパケットが低レイテンシ要件を有すると決定した場合(または、手順350が、ブロック355において、ターゲットデバイスへの完全な経路が未知であると決定した場合)、手順350は、ブロック356において適切なグラフを識別することができる。図7に戻って参照されるように、たとえば、ワイヤレスデバイス216は、ネットワークアクセスポイント205Bへの可能な経路としてグラフ240を識別し得る。上記で説明したように、ワイヤレスデバイス216は、この決定を行うのに十分な情報を接続テーブル69に記憶し得る。次に、ブロック358において、手順350は、グラフ240のグラフ識別子をデータパケットのヘッダまたはトレーラに付加することができる。一般に、無線ネットワークをサービスするプロトコル(例えば、WirelessHARTプロトコル70等)は、データパケットと関連付けられたルーティング情報の種々の効率的手段を提供し得ることを理解されたい。したがって、当業者は、グラフ識別子をデータパケットのヘッダまたはトレーラに挿入する特定の例が、例としてのみ提供され、他の代替も企図されることを理解するであろう。」

「[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. As discussed above, the procedure 350 may use a number of methods to select between the available options in the block 360. Finally, the procedure 350 may send the packet to the next hop in a block 362. To continue with the example discussed above in reference to the network device 216 of FIG. 7, the procedure 350 may send the packet to the node 218.」
(当審対訳)
「[0097] 次いで、手順350は、ブロック358(ブロック360)で選択されたグラフに関連する通信経路内の次のホップを識別することができる。再び図7を参照し、ワイヤレスデバイス216のデバイス固有接続テーブル69は、以下のエントリを記憶し得る。

グラフID ノード
グラフ_240 218
グラフ_240 242

この特定のケースでは、ネットワークデバイス252(当審注:「216」の誤記と認められる)は、両方ともグラフ240に沿ってデータパケットをルーティングするのに適した2つのオプションの間で選択し得る。上述したように、手順350は、ブロック360において、利用可能なオプションの間で選択するためにいくつかの方法を使用することができる。最後に、手順350は、ブロック362において、パケットを次のホップに送信することができる。図7のネットワークデバイス216を参照して上記で説明した例を続けると、手順350は、パケットをノード218に送信することができる。」

「[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(図7)がネットワークアクセスポイント205Aにデータパケットを送信しているとき、デバイス214は、ネットワークデバイス218および205Aのアドレスまたは他のタイプの識別子を含むリストを取り出し得る。次に、上記で説明したステップ358と同様に、手順350は、同じ例を続けるために、ネットワークデバイス218および205Aを指定する順序付きリストとして、完全な経路情報をデータパケットに添付することができる。次いで、手順は、例えば、リスト310に関して図9に詳細に示すように、生成されたリスト(ブロック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. If the procedure 400 determines that the network device executing the procedure 400 is not the tail of the graph identified in the block 404, the wireless device 242 may determine the next hop in the list by checking the device-specific connection table 69, as discussed above in reference to FIG. 6 or 10 (block 408 ). Otherwise, the procedure 400 may proceed to processing, or #consuming# the data packet in the block 410.」

(当審対訳)
「[0099] データパケットを受信すると、ネイバーは、次いで、ルーティングプロシージャ400(図11)を実行し得る。隣接ノードに送信されたデータパケットを受信して処理するか、またはデータパケットを通信経路内の次のホップに転送する。手順400は、ブロック402において、ヘッダ、トレーラ、または他の優先度関連およびルーティング関連情報を含むデータパケットを受信することができ、ブロック404において、ルーティングのタイプをチェックすることができる。ルーティングのタイプ(グラフルーティング、ソースルーティングなど)を示すために、ワイヤレスプロトコルは、たとえば、ヘッダ中のフラグ、またはパケット中で後続すべき情報のタイプをシグナリングする任意の他の知られているもしくは所望の手段を使用し得る。手順400が、グラフルーティングが使用されると判定した場合、手順400は、データパケットのヘッダまたはトレーラにおいて識別されたグラフがデバイスにおいて終端するかどうかをチェックすることができる(ブロック406)。図8に示すように、ワイヤレスデバイス242は、たとえば、グラフ290に関連するグラフ識別子を含むデータパケットを受信し得る。手順400のブロック406において、ワイヤレスデバイス242は、ワイヤレスデバイス242がグラフ290の末尾としてリストされているかどうかを見るために、デバイス固有ルーティングテーブル69をチェックし得る。言い換えれば、ワイヤレスデバイス242は、グラフ290の識別を搬送するデータパケットがワイヤレスデバイス242に送られるか、または単にワイヤレスデバイス242を介して別のネットワークデバイスに送られるかを決定し得る。手順400を実行するネットワークデバイスがブロック404において識別されたグラフの末尾ではないと手順400が決定した場合、ワイヤレスデバイス242は、上記で説明したように、デバイス固有接続テーブル69をチェックすることによってリスト中の次のホップを決定し得る。これは、図6または図10に示されている(ブロック408)。そうでない場合、手順400は、ブロック410におけるデータパケットの処理または消費に進むことができる。」

「[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を実行するデバイスの識別情報を見つけるためにリストをトラバースし得る。図9を参照して先に説明したように、本発明の方法は、以下のステップを含む。リスト310は、対応する通信経路内のすべての中間ネットワークデバイスおよび場合によっては終端ネットワークデバイスを順次リストすることができる。それ自体の識別情報を見つけると、手順400を実行するデバイスは、次いで、この識別情報がリスト310内の最後の識別情報であるかどうかをチェックすることができる(ブロック414)。ターゲットまたは宛先ネットワークデバイスを識別する他の方法も使用できることが理解されよう。たとえば、各データパケットは、リスト310またはグラフ識別子に加えて宛先情報を含み得る。しかしながら、例示的なプロシージャ400は、リスト310の末尾に対するデバイス識別情報の位置からターゲット情報を導出し得る。手順400は、デバイス識別情報の後にリスト310内のさらなるホップを識別する情報が続かない場合、データパケットを処理または消費し得る(ブロック410)。そうでない場合、手順400は、次のホップのアドレスを抽出しようと試みることができ(ブロック416)、手順400がアドレスを見つけ、アドレスに対応する隣接デバイスを識別する場合(ブロック417)、手順400は、識別されたネットワークノードにデータパケットを送ることができる(ブロック418)。一方、手順400がブロック417において次のホップ情報を成功裏に抽出することができない場合、手順400は、代わりに適切なグラフルートを使用しようと試みることができる。少なくともいくつかの実施形態では、リスト310などのソースルーティング情報を含むデータパケットは、グラフ識別子をさらに含むことができる。この意味で、データパケットは、ソースルーティングを一次ルーティング方法として指定し、グラフルーティングを二次ルーティング方法として指定することができる。」

「FIG.1

」

「FIG.7

」

したがって、上記引用文献2には、特に上記下線で強調した記載を参照すると、
データパケットをルーティングするための、データパケットのヘッダまたはトレーラに付加されるグラフ識別子について、当該グラフ識別子は、一意にルーティングのためのパスを指定するものではなく、同じグラフ識別子が付加された場合であっても、ネットワークデバイスが、複数のパスの中から異なるパスを選択することを許容するような識別子である技術的事項が開示されていると認められる。

第5 対比・判断

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

ア 引用発明の「IPパケット」は本願発明1の「パケット」に相当する。また、引用発明の「MPLSネットワークの入口に配置されたルータLSR1」と、この「ネットワークの出口に配置されたルータLSR5」は、「エッジルータと称され」るルータであって、
このうち、「入口ルータLSR1」は、
「MPLSネットワークに隣接IPネットワークから到来するIPパケット(L3)をそのフローに応じて、L2パスのLSP(Label Switched Path)にマッピングし、MPLSネットワーク内に転送するものであって、このルータLSR1はポリシサーバPSVからの経路決定結果の通知(設定指示)に従って、CR(Constraint-based Routing)-LDP(Label Distribution Protocol)等のラベル配布プロトコルに則り、明示的なLSPの設定または解放を実行」することから、「処理規則に従いパケットを処理する」と言い得るものである。
また、「出口ルータLSR5」は、
「ラベル付けされたIPパケットからラベルを削除し、そのパケットをルーティングテーブルに従って、MPLSネットワーク外の隣接のIPネットワークに転送する」ことから、上記入口ルータと同様に、「処理規則に従いパケットを処理する」と言い得るものである。
したがって、引用発明の「エッジルータと称され」る当該「入口ルータLSR1」と「出口ルータLSR5」は、本願発明1の「処理規則に従いパケットを処理する複数のエッジノード」に相当するといえる。

イ 引用発明では、「ネットワークの入口に配置されたルータLSR1とネットワークの出口に配置されたルータLSR5とは、中継(コア)ルータLSR2,LSR3,LSR4及び物理的な回線(物理リンク)を通して接続され」ていることから、引用発明の当該「中継(コア)ルータLSR2,LSR3,LSR4」は、「入口に配置されたルータLSR1」と「出口に配置されたルータLSR5」の間を中継するものである。したがって、引用発明の当該「中継(コア)ルータLSR2,LSR3,LSR4」は、本願発明1の「前記複数のエッジノード間を中継」する「1または複数のコアノード」に相当する。

ウ 引用発明では、当該「中継ルータLSR2,3,4は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたIPパケットを高速にスイッチングし、他のルータに転送」するものであり、当該「中継ルータLSR2,3,4」が当該「ラベル付けされたIPパケットを高速にスイッチング」することについて、引用発明では、「各ルータLSRの動作は、IPパケットがルータに到着した際に、IPフローを識別するエントリにヒットするかどうか、上記IPフロー識別子テーブルTBLを検索し、エントリにヒットした場合、エントリの中には、L2パスの識別子L2IDが入っているため、この情報からそのIPパケットを転送すべきL2パスが求められ、IPフロー(L3)とL2パスとのマッピングが終わると、最終的にユーザの要求するIPトラフィックはユーザの要求した品質で送信される」とあることから、引用発明の上記「ラベル」と上記「L2パスの識別子」は同義であって、これらは本願発明1の「パス識別子」に相当する。
したがって、引用発明の「中継ルータLSR2,3,4」は「上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたIPパケットを高速にスイッチングし、他のルータに転送」することから、本願発明1の「パス識別子と対応付けられた処理規則に従ってパケットを処理する」といえる。

エ 引用発明では、「ユーザがIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知する場合、」「この要求には宛先IPアドレス及び発信元(発側)IPアドレスの情報が含まれ、ユーザからの要求には明示的に要求する通信品質が含まれ」る。
そして、引用発明の「ポリシサーバPSV」は、「ユーザの要求する通信品質を満たせない、あるいは混在することで既存のトラフィックが悪影響を受ける場合などは、既存のパスを利用せずに、新規にパスを設定」し、「ユーザの要求する通信品質」を「満たすパスとして、ルータLSR1→LSR3→LSR5を経由するパスを発見(検索)でき、」そして、「ユーザの要求を満たす品質保証パラメータを含むL2のパスを設定するために、CR-LDPあるいはRSVPなどのプロトコルに則るパス設定メッセージをMPLSネットワークの入口から出口に向かって転送するように、入口ルータLSR1に指示し、入口ルータLSR1はポリシサーバPSVからの指示を受け取ると、CR-LDPあるいはRSVPなどの明示的なパス設定プロトコルを利用して、出口ルータLSR5に向かってL2パスを設定し、入口ルータLSR1から発せられたパス設定メッセージは中継ルータLSR3にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータLSR5に向かって順次送信され、ポリシサーバPSVは、L2パスが設定されたことを認識した後、L2パスにユーザから要求されたIPフローをマッピングする指示をルータLSRに送り、IPフローを識別するための識別子としては、宛先及び送信元IPアドレス、宛先及び送信元ポート番号、プロトコル種別などのIPヘッダ情報、あるいはペイロード情報が考えられ、この識別子がIPフローと1対1に対応」するものである。
要するに、引用発明は、「ポリシサーバPSV」が、「MPLSネットワーク内の入口となるルータLSR1」から「出口となるルータLSR5」までの「ルータLSR1→LSR3→LSR5を経由するパスを発見」し、当該「パス」に従って「IPフロー」を転送するための「L2パス」を「IPフローを識別するための識別子」として「設定」するといえることから、本願発明1の「送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を決定」することとは、「送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を定め」る点で共通している。

オ 上記イ、ウ及びエを踏まえると、引用発明と、本願発明1の「処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、予め設定された、パス識別子と対応付けられた処理規則に従ってパケットを処理する1または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を決定」することとは、「処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、パス識別子と対応付けられた処理規則に従ってパケットを処理する1または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を定め」る点で共通している。

カ 引用発明の「MPLSネットワークに隣接IPネットワークから到来するIPパケット」は、当該MPLSネットワークの入口に配置された「入口ルータLSR1」が受信するパケットであることから、本願発明1の「受信パケット」に相当する。
また、上記エで示した引用発明の「ユーザがIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知する場合」は、本願発明1の「新規通信フローが発生した場合」に相当する。そして、その場合、上記エで示したように、引用発明の「ポリシサーバPSV」は、「ユーザの要求を満たす品質保証パラメータを含むL2のパスを設定するために、CR-LDPあるいはRSVPなどのプロトコルに則るパス設定メッセージをMPLSネットワークの入口から出口に向かって転送するように、入口ルータLSR1に指示し、入口ルータLSR1はポリシサーバPSVからの指示を受け取ると、CR-LDPあるいはRSVPなどの明示的なパス設定プロトコルを利用して、出口ルータLSR5に向かってL2パスを設定し、入口ルータLSR1から発せられたパス設定メッセージは中継ルータLSR3にてパス設定に利用され、メッセージ内に記述されている経路に従って、出口ルータLSR5に向かって順次送信され」ることにより、「中継ルータLSR2,3,4は上記ラベル配布プロトコルに則って設定されたラベル情報に基づき、ラベル付けされたIPパケットを高速にスイッチングし、他のルータに転送し、出口ルータLSR5はラベル付けされたIPパケットからラベルを削除」することから、本願発明1の「新規通信フローが発生した場合に、追加ヘッダを受信パケットに追加することを示す第1の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第1のエッジノードに送信」することとは、「新規通信フローが発生した場合に、ラベルを受信パケットに付加することを示す第1の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第1のエッジノードに送信」する点で共通している。

キ 上記ウ及びエを踏まえると、引用発明の「ラベル」は、「IPフローを識別するための識別子」を含むことは明らかであるから、引用発明と、本願発明1の「前記追加ヘッダは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む」こととは、「前記ラベルは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む」点で共通している。

ク 引用発明の「ポリシサーバPSV」は、ラベルスイッチネットワークシステムを制御するものといえることから、下記相違点を除き、本願発明1の「制御装置」に相当するといえる。

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

＜一致点＞
「処理規則に従いパケットを処理する複数のエッジノードと、前記複数のエッジノード間を中継し、パス識別子と対応付けられた処理規則に従ってパケットを処理する1または複数のコアノードとを含む、送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子を定め、
新規通信フローが発生した場合に、ラベルを受信パケットに付加することを示す第1の処理規則を、前記複数のエッジノードのうち、前記新規通信フローの送信側エッジノードである第1のエッジノードに送信し、
前記ラベルは、前記受信パケットが属する前記新規通信フローに割り当てられたパス識別子を含む
ことを特徴とする制御装置。」

＜相違点＞
(相違点1)
「複数のエッジノード」と「1または複数のコアノード」とを含む、「送信側エッジノードから受信側エッジノードまでのパスに従って前記パケットを転送するためのパス識別子」について、本願発明1では、「予め設定された、」「パス識別子を決定」するものであるのに対し、引用発明では、「ユーザがIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知」し、「ポリシサーバPSV」が「新規にパスを設定」する際に、「ユーザの要求する通信品質」を「満たすパス」を発見して、「ポリシサーバPSV」が「L2パスの識別子」を「定め」ることから、本願発明1のように、「予め設定された、」「パス識別子を決定」するような特定はされていない点。

(相違点2)
受信パケットにラベルを付加するのに、本願発明1では、「追加ヘッダ」を受信パケットに「追加」するのに対し、引用発明では、「追加ヘッダ」としてラベルを「追加」するものとの特定はされていない点。

＜相違点についての判断＞
相違点1について検討する。
相違点1に係る本願発明1の「予め設定された、」「パス識別子を決定」するという構成は、上記「第5 引用文献、引用発明等」の「2.」で示した引用文献2に記載も示唆もされておらず、本願優先日前に周知技術であるともいえない。
なお、引用発明については、「ユーザがIP通信(IPフロー)を新しく開始する要求をポリシサーバPSVに通知」し、「ポリシサーバPSV」が「新規にパスを設定」する際に、「ユーザの要求する通信品質」を「満たすパス」を発見して、「ポリシサーバPSV」が「L2パスの識別子」を「設定」することから、当該「L2パスの識別子」は、「予め設定された」ものではなく、「ユーザがIP通信を新しく開始する要求」を通知した後に、「設定」するものであり、本願発明1とは構成上相違している。
また、引用発明では、「入口ルータLSR1から出口ルータLSR5に至る既存パス(既に呼が設定されているパス)が存在し、このパスを利用してユーザの要求するIPトラフィックを送信することができる場合には、ポリシサーバPSVは、入口ルータLSR1に対してユーザが要求するIPフローを既存パスを使って送信するように指示」することも行うことができるが、その場合に使用する「既存パス」は、以前に別のIPトラフィックを送信するため設定したパスであって、当該「既存パス」が、今回、ユーザがIP通信を新しく開始する要求をした際のユーザの要求する通信品質を、偶然に満たす場合に、使用することができるパスであるから、当該「既存パス」の「L2パスの識別子」を使用することは、本願発明1の「予め設定された、」「パス識別子を決定」するものとは異なるものである。
したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2及び3について

本願発明2及び3は、本願発明1を減縮した発明であり、上記相違点1に係る本願発明1の構成と同一の構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.本願発明4及び7について

本願発明4及び7は、それぞれ本願発明1に対応する通信システム、及び通信方法の発明であり、本願発明1と実質的にカテゴリ表現が異なるだけの発明であるから、本願発明1と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

4.本願発明5及び6について

本願発明5及び6は、本願発明4を減縮した発明であるから、本願発明4と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

5.本願発明8及び9について

本願発明8及び9は、本願発明7を減縮した発明であるから、本願発明7と同様の理由により、当業者であっても、引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第6 むすび

以上のとおり、本願発明1-9は、当業者が引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。

 
審決日 2021-09-21 
出願番号 特願2018-191447(P2018-191447)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 中川 幸洋  
特許庁審判長 稲葉 和生
特許庁審判官 角田 慎治
富澤 哲生
発明の名称 通信システム、ノード、制御装置、通信方法及びプログラム  
代理人 加藤 朝道  
代理人 内田 潔人  

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