• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
管理番号 1313311
審判番号 不服2015-12928  
総通号数 198 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-06-24 
種別 拒絶査定不服の審決 
審判請求日 2015-07-07 
確定日 2016-04-26 
事件の表示 特願2013-509957「ネットワーク、データ転送ノード、通信方法およびプログラム」拒絶査定不服審判事件〔平成24年10月18日国際公開、WO2012/141241、請求項の数(9)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は,2012年4月12日(国内優先による優先権主張 2011年4月13日)を国際出願日とする出願であって,平成26年8月8日付けで拒絶の理由が通知され,同年10月20日付けで手続補正がされ,平成27年3月23日付けで拒絶査定(以下「原査定」という。)がされ,これに対し,同年7月7日に拒絶査定不服審判が請求され,その後,当審により同年12月24日付けで拒絶の理由が通知され,平成28年3月7日付けで手続補正がされたものである。


第2 本願発明
本願の請求項1-9に係る発明は,平成28年3月7日付けの手続補正で補正された特許請求の範囲の請求項1-9に記載された事項により特定されるものと認められるところ,本願の請求項1に係る発明(以下,「本願発明」という。)は以下のとおりである。

「【請求項1】
物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する論理ネットワークトポロジ管理部と,
受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して,パケットの転送先を決定し,受信パケットを送信するパケット処理部と,
を備えたデータ転送ノードを含み,
前記論理ネットワークトポロジは,前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報,を適用して生成される
ことを特徴とするネットワーク。」


第3 原査定の理由について
1.原査定の理由の概要
原査定の拒絶の理由の概要は,以下のとおりである。

「 この出願の下記の請求項に係る発明は,その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

記 (引用文献等については引用文献等一覧参照)
請求項1?10に対して,引用文献1,2
備考:
引用文献1には,リンクや経路に複数のコスト(重み付け情報)を設定し,複数のトポロジーを生成するMT-OSPFが記載(1409ページ左欄?1410ページ左欄「5.1 MT-OSPF」,図4,図5)されている。
そして,引用文献2には,複数のサービス毎のトラヒックをマルチトポロジOSPFにより生成される異なる経路に分けることが記載(【0002】?【0003】,図8)されており,引用文献1に記載される複数のトポロジーをトラヒックの対応するサービスに基づいて選択することに,格別困難な点は認められない。
また,経路制御をポリシーに基づいて行うことは,ごく一般的な事項であり,引用文献1記載の複数のトポロジーをポリシーに基づいて生成することは,適宜なし得る事項にすぎない。

引 用 文 献 等 一 覧
1.藤枝 俊輔 他,UDLネットワークに適するMRIBを用いたPIM-SM経路制御の実現,電子情報通信学会論文誌,2008年11月 1日,第J91-B巻,第11号,p.1405?1416
2.特開2010-45680号公報」


また,拒絶査定の備考として,以下の記載がある。

「●理由(特許法第29条第2項)について
・請求項 1?10
・引用文献等 1,2
出願人は意見書において,「仮に引用文献1に,引用文献2のご指摘箇所の内容を適用しても,MT-OSPFの一般的な内容と,片方向回線を含む場合のメトリックの設定手法が把握されるに過ぎない」旨,主張する。
しかしながら,引用文献1には,複数のトポロジを生成するMT-OSPFが記載され,引用文献2には,複数のサービス毎のトラヒックをマルチトポロジOSPFにより生成される異なる経路に分けることが記載されている。
そして,引用文献1記載される,MT-OSPFにより生成される複数のトポロジを用いて,引用文献2に記載される,サービス毎のトラヒックを分ける異なる経路を生成することに,格別困難な点は認められない。
また,引用文献2においても,複数のサービスと選択すべき経路との対応を管理すべきものであり,経路とトポロジが対応することから,複数のサービスと,選択される経路に対応するトポロジとを対応付けて,その対応関係を管理することは,格別なこととは認められない。

よって,意見書の主張は採用することができず,本願請求項1?10に係る発明は,当業者が容易になし得たものと依然として認められる。」


2.原査定の理由の判断
(1)引用文献等の記載事項
[引用文献等1]
引用文献等1には,図面とともに以下の事項が記載されている。

ア 「5.1 MT-OSPF
RFC1583[12]では,リンクまたは経路にTOS(Type Of Service)[13]に応じた複数のメトリックを付与し,TOSごとに異なる経路を計算する機能が定義されている。しかし,IPのTOSフィールドは実用されなかったため,RFC2328[14]はTOS機能の利用を非推奨とし,RFC1583との下位互換性のためにパケットフォーマットと機能だけを残した。MT-OSPFはRFC1583のTOS機能を再利用し,OSPFにおいて複数トポロジーを計算する機能を,IPパケットのTOSフィールドとは関係なく任意の用途に用いることを提案している。
MT-OSPFはリンクや経路に複数のコストを設定し,そこから複数のSPT(Shortest Path Tree)を計算する。TOSの代わりに経路計算の対象をトポロジどと呼び,トポロジーの識別子にMT-ID(Multi-Topology ID)を利用する。MT-ID=0のトポロジーをデフォルトトポロジーと呼び,一般的なRIBの計算に利用する。それ以外のトポロジーから計算した経路をどのように扱うかは定まっていないが,MT-ID=1はデフォルトマルチキャストトポロジーとして予約されている。本研究では,この提案に沿ってMRIBの計算にMT-ID=1を使用する。
MT-OSPFでは,以下のLSA(Link State Adver-tisement)に複数のメトリックを付与して広告する。
・ルータLSA(タイプ1)
・サマリLSA(タイプ3,タイプ4)
・エクスターナルLSA(タイプ5,タイプ7)
例えばルータLSAでは,図4のように各リンク情報にMT-ID数を示すフィールドがある。その後ろには各トポロジーのMT-IDとメトリックが続く。なお,ルータLSAのMT-IDフィールドは8ビットであるが,エクスターナルLSAでは1ビットが別の用途に利用されているため,MT-IDは7ビット空間である。
経路計算では,SPTをトポロジーごとに個別に作成する。図5に,二つのトポロジー計算の例を示す。A,B,C,Dがルータであり,xとyがホストである。OSPFでは,あるリンクを経路として利用しないためには十分に大きいメトリックをルータのインタフェースに設定するため,これをM_(no_use)と表記する。MT-ID=0のメトリックによってRIB用のSPTが計算され,xからyへのユニキャスト経路はx⇒A⇒B⇒yになる。同時に,本手法ではMT-ID=1のメトリックによってMRIB用のSPTを計算する。xからyへのMRIBはx⇒A⇒D⇒C⇒B⇒yと設定される。これにより,yがマルチキャスト送信者でxが受信者の場合,配送木は下流から上流へx⇒A⇒D⇒C⇒B⇒yと構築され,トラヒックはy⇒B⇒C⇒D⇒A⇒xと配送される。
MT-OSPFのイコールコストマルチパス機能により,MRIBに同一メトリックの経路を複数提供することも可能である。マルチキャストにおけるイコールコストマルチパスへの対応はRFC2991[15]に定義されており,Highest Random Weight(HRW)によってネクストホップ(上流)が決定される,PIM-SMでは,同一リンク上で複数のルータが別の上流を選択するとトラヒックが重複するが,HRWが決定するネクストホップはマルチキャストグループと送信元の組合せごとに全ルータで一意であるため,この問題を回避できる。MT-OSPFのイコールコストマルチパス機能とHRWによるネクストホップの選択により,マルチキャストのトラヒックも負荷分散が可能になる。」

上記アの記載及び図面(特に図4及び図5)並びにこの分野における技術常識を考慮すると,

a 上記アの「MT-OSPFはリンクや経路に複数のコストを設定し,そこから複数のSPT(Shortest Path Tree)を計算する。」,及び図5並びに関連する記載からは,ホストx,y及びルータA,B,C,Dからなるネットワークにおいて,リンクに異なるコスト(メトリック)を付与し,当該異なるコストに基づいて複数の異なるSPT(Shortest Path Tree)を計算することが見て取れる。ここで,前記「リンク」が,前記ホストx,y及びルータA,B,C,Dの間の物理的な接続であることは図5から明らかであるから,前記「異なるSPTの計算」は,前記ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて行われているといえる。また,計算したSPTはルータにおけるルーティングに用いられるのであるから,当該ルータが前記SPTを管理することは明らかである。
したがって,引用文献等1には,「ルータが,ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて計算された2以上の異なるSPTを管理する」ことが記載されていると認められる。

b 上記アの「MT-ID=0のメトリックによってRIB用のSPTが計算され,xからyへのユニキャスト経路はx⇒A⇒B⇒yになる。」及び「同時に,本手法ではMT-ID=1のメトリックによってMRIB用のSPTを計算する。xからyへのMRIBはx⇒A⇒D⇒C⇒B⇒yと設定される。」から,ルータは,受信パケットがユニキャストかマルチキャストか,すなわち受信パケットに応じて,対応するSPTを選択して,パケットの転送先を決定して送信している。
したがって,引用文献等1には,「ルータが,受信パケットに対応するSPTを選択して,パケットの転送先を決定し,受信パケットを送信する」ことが記載されていると認められる。

c 図5から,引用文献等1には,「ルータを含むネットワーク」が記載されていると認められる。


以上を総合すると,引用文献等1には以下の発明(以下,「引用発明1」という。)が記載されていると認める。

「 ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて計算された2以上の異なるSPTを管理し,
受信パケットに対応するSPTを選択して,パケットの転送先を決定し,受信パケットを送信する
ルータを含む
ことを特徴とするネットワーク。」


[引用文献等2]
引用文献等2には,図面とともに以下の事項が記載されている。

イ 「【0002】
従来の一般的な,IP(Internet Protocol)ルーチング技術では,ノード(ルータ)は,送信されたパケットの宛先IPアドレスをもとに,自らが持つルーチングテーブルのエントリを検索し,該当するアドレス値に対し,最長一致の原則に基づき,エントリに記載されたインタフェースからパケットの中継がなされる。つまり,同じアドレス宛のパケットは同じルーチング経路をとるのが一般的である。しかし,同じアドレス(同じネットワーク)宛のパケットでも,そのパケットが用いられるサービスごとにルーチング経路を分けたい場合もある。図8は,比較例となるルーチング経路を示した図である。
【0003】
例えば,図8に示すように,サービスネットワーク同士が,バックボーンネットワーク経由で接続されるシステムを考える。ここで,サービスAとサービスBというサービスがあり,それぞれのサービスのサーバとクライアントがそれぞれ同じサービスネットワークにある場合,サービスAのトラヒックもサービスBのトラヒックも同じ境界ノードを経由し,破線に示す同じルーチング経路をとるのが一般的である。しかし,このように複数のサービスについて同じルーチング経路をとると,どちらか一方のサービスのトラヒック量が増加したときに,もう片方のサービスのトラヒックが影響を受けることもあり,サービスの品質が低下するおそれもある。そこで,図8の実線に示すようにサービスごとに,ルーチング経路を分けることができれば,それぞれのサービスの品質を保つことができ,大変便利である。ここで,このようにルータがサービスごとの経路選択を行う技術として,非特許文献1に開示されるマルチトポロジOSPF(Open Shortest Path First)がある。」

上記イの記載及び図面(特に図8)並びにこの分野における技術常識を考慮すると,引用文献等2には,以下の発明(以下,「引用発明2」という。)が記載されているものと認める。

「ルータが,複数のサービスのトラヒックについて,サービスごとにルーチング経路を分けること。」


(2)対比
本願発明と引用発明1とを対比すると,

(ア)引用発明1の「ホストx,y及びルータA,B,C,Dの間の物理的な接続」は,本願発明の「物理ネットワークトポロジ」に相当する。また,引用文献等1の図5から明らかなように,引用発明1のSPT(図5の右側)は,ホストx,y及びルータA,B,C,Dの間の物理的な接続(図5の左側)に基づいて計算された,ホストx,y及びルータA,B,C,Dの間の論理的な接続関係を表しているから,本願発明の「論理ネットワークトポロジ」に相当する。
したがって,本願発明と引用発明1とは,「論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係」を管理するか否か,及び「管理」を行う「論理ネットワークトポロジ管理部」を備えるか否かは別として,「物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジを管理」する点で共通する。

(イ)上記(ア)のとおり,引用発明1のSPTは,本願発明の「論理ネットワークトポロジ」に相当する。
したがって,本願発明と引用発明1とは,受信パケットに対応して選択される論理ネットワークトポロジが「受信パケットが属するデータトラヒックに対応する」か否か,及びパケットの処理を行う主体として「パケット処理部」を備えるか否かは別として,「受信パケットに対応する論理ネットワークトポロジを選択して,パケットの転送先を決定し,受信パケットを送信」する点で共通する。

(ウ)引用発明1の「ルータ」は,本願発明の「データ転送ノード」に相当する。

以上を総合すると,本願発明と引用発明1とは,以下の点で一致し,また,相違点1ないし4の点で相違している。

(一致点)
「 物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジを管理し,
受信パケットに対応する論理ネットワークトポロジを選択して,パケットの転送先を決定し,受信パケットを送信する
データ転送ノード含む
ことを特徴とするネットワーク。」

(相違点1)
一致点の「2以上の異なる論理ネットワークトポロジを管理」することに関し,本願発明は,更に,「論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係」を管理するのに対し,引用発明1は,当該構成が明らかではない点。

(相違点2)
一致点の「受信パケットに対応する論理ネットワークトポロジを選択」することに関し,本願発明は,「受信パケットが属するデータトラヒックに対応する」論理ネットワークトポロジを選択するのに対し,引用発明1は,当該構成が明らかではない点。

(相違点3)
一致点の「論理ネットワークトポロジ」に関し,本願発明は,「前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報,を適用して生成される」のに対し,引用発明1は,当該構成が明らかではない点。

(相違点4)
本願発明は,データ転送ノードが,一致点の「物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジを管理」する「論理ネットワークトポロジ管理部」,及び一致点の「受信パケットに対応する論理ネットワークトポロジを選択して,パケットの転送先を決定し,受信パケットを送信」する「パケット処理部」を備えるのに対し,引用発明1は,当該構成が明らかではない点。


(3)判断
上記相違点について検討する。

(相違点1及び2について)
上記「(1)引用文献の記載事項」の項で「引用発明2」として認定したとおり,「ルータが,複数のサービスのトラヒックについて,サービスごとにルーチング経路を分けること。」が公知である。
ここで,引用発明2の「サービスのトラヒック」は,本願発明の「データトラフィック」に相当するものの,引用発明2は,ルーチング経路を分けるために,「論理ネットワークトポロジと,論理ネットワークトポロジを適用するサービス(データトラフィック)との対応関係」を管理するものではない。
してみると,仮に,引用発明1に,上記引用発明2を適用したとしても,上記相違点1に係る本願発明の構成,すなわち,「物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する」という構成までは導出されない。
また,それにともない,上記相違点2に係る本願発明の構成,すなわち,「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択」する構成も導出されない。

また,他に,このような構成を設けることが当業者にとって容易であったと判断すべき理由を発見しない。


(4)小括
以上のとおりであるから,相違点3及び4について検討するまでもなく,本願発明は,当業者が引用発明1及び引用発明2に基づいて,当業者が容易に発明することができたとはいえない。

また,本願の請求項6,8,9に係る発明は,本願発明とカテゴリーが異なるに過ぎず,また本願の請求項2-5,7に係る発明は,本願発明ないし本願発明とカテゴリーが異なる発明をさらに限定したものであるので,同様に,当業者が引用発明1及び引用発明2に基づいて容易に発明をすることができたとはいえない。

よって,本願は,原査定の理由によって拒絶すべきものではない。


第4 当審により通知した拒絶の理由について
1.当審により通知した拒絶の理由の概要
当審により通知した拒絶の理由(以下,「当審拒絶理由」という。)の概要は,以下のとおりである。

「1.(進歩性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

2.(実施可能要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。

3.(明確性)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。

記 (引用文献等については引用文献等一覧参照)

●理由1(進歩性)について

・請求項 1,5,7,9,10
・引用文献等 1
・備考
引用例1には,ルータ(本願の「データ転送ノード」に相当)を含むネットワークにおける経路制御のための構成として,リンクまたは経路にTOS(Type Of Service。本願の「データトラフィック」に相当)に応じた複数のメトリックを付与し,TOSごとに異なる経路を計算すること(以下,「引用発明3」という。[当審注]:番号の重複を避けるために番号を振り直した。以下同じ。)が記載されている(「5.1 MT-OSPF」参照)。
また,引用例1の図5からは,ホストx,y及びルータA,B,C,Dからなるネットワークにおいて,リンクに異なるメトリックを付与し(図5では,ルータAとBとの間のリンクのメトリックが異なっている),当該異なるメトリックに基づいて異なるSPT(Shortest Path Tree。本願の「2以上の異なる論理ネットワークトポロジ」に相当)を計算すること(以下,「引用発明4」という。)が見て取れ,SPTを計算する際に,ネットワークを構成する機器同士の物理的な接続関係(本願の「物理ネットワークトポロジ」に相当)を考慮することは当然である。

してみると,引用発明3において,リンクにTOSに応じた複数のメトリックを付与して経路制御を行うための構成として,引用発明4の,異なるメトリックに基づいて異なるSPT(Shortest Path Tree。本願の「2以上の異なる論理ネットワークトポロジ」に相当)を計算する構成を適用し,ネットワークを構成する機器同士の物理的な接続関係及びTOSに応じたメトリックに基づいてTOSごとにSPTを計算するよう構成することは,当業者が容易に想到し得たことである。そしてその際,前記SPTと,当該SPTを適用するTOSとの対応関係を管理することは当然である。

また,引用発明3はルータを含むネットワークにおける経路制御のための構成であるから,パケットの経路制御を担うルータが,受信パケットのTOS(本願の「受信パケットが属するデータトラフィック」に相当)に対応する前記SPTを選択して,パケットの転送先を決定し,受信パケットを送信することは自明である。

よって,本願の請求項1,5,7,9,10に係る発明は,引用例1に記載された発明に基づき,当業者が容易に想到し得たものである。


・請求項 2-4,8
・引用文献等 1
・備考
引用発明3の「メトリック」は,本願発明の「重み付け情報」に相当し,本願発明の「ポリシー情報」に含まれる。

また,引用発明3において,リンクまたは経路にTOS(Type Of Service。本願の「データトラフィック」に相当)に応じた複数のメトリックを付与する以上,TOSとメトリックとを対応付けて管理することは当然である。

そして,引用発明3に引用発明4を適用することにより構成される「ネットワークを構成する機器同士の物理的な接続関係及びTOSに応じたメトリックに基づいてTOSごとにSPTを計算する」ことが,本願発明の「前記物理ネットワークトポロジと,前記ポリシー情報とを用いて前記2以上の論理ネットワークトポロジを生成する」ことに相当する。

よって,本願の請求項2-4,8に係る発明は,引用例1に記載された発明に基づき,当業者が容易に想到し得たものである。


・請求項 6
・引用文献等 1
・備考
引用発明3は,RFC1583(OSPF)を前提とするものであるところ,OSPFにおいて,経路情報を隣接するルータに通知するとともに,SPTと他のルータから受信した経路情報とに基づいて,自装置からのパケットの転送先を決定することは,一般的に行われていることに過ぎない。

よって,本願の請求項6に係る発明は,引用例1に記載された発明に基づき,当業者が容易に想到し得たものである。


・請求項 1,5,7,9,10
・引用文献等 2
・備考
引用例2には,バックボーンネットワーク内に,ツリー型トポロジで構成される複数の論理ネットワーク(本願の「論理ネットワークトポロジ」に相当)をサービス(本願の「データトラヒック」に相当)ごとに構築するとともに,各ノードすなわちルータ(本願の「データ転送ノード」に相当)は,当該論理ネットワークごとのルーティングテーブルとして,当該論理ネットワークのサービスIDと,その論理ネットワークにおける自身のノードの階層,ルートノードのアドレス,最大ツリー階層数,最大子ノード数,当該サービスの論理ネットワークにおける自身のノードの親ノードのアドレス及び子ノードアドレスを保持し(本願において,「論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する」ことに相当),受信パケットを解析して得られたサービスIDに対応する論理ネットワークを選択して,パケットの転送先を決定し,パケットを転送することが記載されている(【0002】-【0003】,【0020】-【0030】,【0041】,【0054】-【0059】,図1,図4,図7,図8参照)。
また,引用例2の図1から,論理ネットワークが,バックボーンネットワークのトポロジ(本願の「物理ネットワークトポロジ」に相当)に基づいて生成されることが見て取れる。

よって,本願の請求項1,5,7,9,10に係る発明は,引用例2に記載された発明に基づき,当業者が容易に想到し得たものである。


・請求項 2-4,8
・引用文献等 1,2
・備考
引用例1には,ルータを含むネットワークにおける経路制御のための構成として,リンクまたは経路にTOS(Type Of Service。本願の「データトラフィック」に相当)に応じた複数のメトリックを付与し,TOSごとに異なる経路を計算することが記載されている(「5.1 MT-OSPF」参照)。
ここで,引用例1の,「メトリック」は,本願発明の「重み付け情報」に相当し,本願発明の「ポリシー情報」に含まれる。
また,引用例1において,リンクまたは経路にTOS(Type Of Service。本願の「データトラフィック」に相当)に応じた複数のメトリックを付与する以上,TOSとメトリックとを対応付けて管理することは当然である。

してみると,引用例2に記載された発明における,複数の論理ネットワークをサービスごとに構築するための構成として,引用例1に記載された,リンクにTOSに応じた複数のメトリックを付与して経路を計算する構成を適用することは,当業者が容易に想到し得たことである。

よって,本願の請求項2-4,8に係る発明は,引用例1,2に記載された発明に基づき,当業者が容易に想到し得たものである。


●理由2(実施可能要件)について

請求項6の「前記経路計算部は,前記論理ネットワークトポロジと,他のデータ転送ノードの経路情報通信部から受信した前記データトラヒックとパケットの転送先との対応関係と,に基づいて,自装置からのパケットの転送先を決定する」なる構成に関し,明細書には,【0034】に「また経路計算部122は,経路情報通信部124より,他のデータ転送ノードが計算した経路計算の結果が通知されている場合には,当該計算結果も用いてパケットの転送経路を計算する。」と記載されているのみであって,「他のデータ転送ノードが計算した経路計算の結果」としてどのような情報が通知されるのか,及び当該「他のデータ転送ノードが計算した経路計算の結果」をどのように用いてパケットの転送経路を計算するのかに関して,いずれも明確な記載がない。

したがって,この出願の発明の詳細な説明は,当業者が請求項6に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。


●理由3(明確性)について

・請求項 8
請求項8の末尾は「請求項6のデータ転送ノード。」であるが,請求項6は「ネットワーク」の発明である。
してみると,請求項8に係る発明が「データ転送ノード」であるのか「ネットワーク」であるのか不明確であり,発明を明確に特定することができない。

したがって,請求項8に係る発明は,明確ではない。(明確性)

(「請求項7のデータ転送ノード。」の誤記と思われる。なお,「●理由1(進歩性)について」においては,誤記であると解釈して判断を行った。)


<引用文献等一覧>
1.藤枝俊輔他,UDLネットワークに適するMRIBを用いたPIM-SM経路制御の実現,電子情報通信学会論文誌,2008年11月1日,第J91-B巻,第11号,p.1405?1416
2.特開2010-45680号公報」
([当審注]:当審拒絶理由における引用文献等1及び2は,原査定の理由における引用文献1及び2と同一である。)


2.当審拒絶理由の判断

●理由1(進歩性)について
(1)引用文献等の記載事項
引用文献等1には,図面とともに以下の事項が記載されている。(再掲)

ア 「5.1 MT-OSPF
RFC1583[12]では,リンクまたは経路にTOS(Type Of Service)[13]に応じた複数のメトリックを付与し,TOSごとに異なる経路を計算する機能が定義されている。しかし,IPのTOSフィールドは実用されなかったため,RFC2328[14]はTOS機能の利用を非推奨とし,RFC1583との下位互換性のためにパケットフォーマットと機能だけを残した。MT-OSPFはRFC1583のTOS機能を再利用し,OSPFにおいて複数トポロジーを計算する機能を,IPパケットのTOSフィールドとは関係なく任意の用途に用いることを提案している。
MT-OSPFはリンクや経路に複数のコストを設定し,そこから複数のSPT(Shortest Path Tree)を計算する。TOSの代わりに経路計算の対象をトポロジどと呼び,トポロジーの識別子にMT-ID(Multi-Topology ID)を利用する。MT-ID=0のトポロジーをデフォルトトポロジーと呼び,一般的なRIBの計算に利用する。それ以外のトポロジーから計算した経路をどのように扱うかは定まっていないが,MT-ID=1はデフォルトマルチキャストトポロジーとして予約されている。本研究では,この提案に沿ってMRIBの計算にMT-ID=1を使用する。
MT-OSPFでは,以下のLSA(Link State Adver-tisement)に複数のメトリックを付与して広告する。
・ルータLSA(タイプ1)
・サマリLSA(タイプ3,タイプ4)
・エクスターナルLSA(タイプ5,タイプ7)
例えばルータLSAでは,図4のように各リンク情報にMT-ID数を示すフィールドがある。その後ろには各トポロジーのMT-IDとメトリックが続く。なお,ルータLSAのMT-IDフィールドは8ビットであるが,エクスターナルLSAでは1ビットが別の用途に利用されているため,MT-IDは7ビット空間である。
経路計算では,SPTをトポロジーごとに個別に作成する。図5に,二つのトポロジー計算の例を示す。A,B,C,Dがルータであり,xとyがホストである。OSPFでは,あるリンクを経路として利用しないためには十分に大きいメトリックをルータのインタフェースに設定するため,これをM_(no_use)と表記する。MT-ID=0のメトリックによってRIB用のSPTが計算され,xからyへのユニキャスト経路はx⇒A⇒B⇒yになる。同時に,本手法ではMT-ID=1のメトリックによってMRIB用のSPTを計算する。xからyへのMRIBはx⇒A⇒D⇒C⇒B⇒yと設定される。これにより,yがマルチキャスト送信者でxが受信者の場合,配送木は下流から上流へx⇒A⇒D⇒C⇒B⇒yと構築され,トラヒックはy⇒B⇒C⇒D⇒A⇒xと配送される。
MT-OSPFのイコールコストマルチパス機能により,MRIBに同一メトリックの経路を複数提供することも可能である。マルチキャストにおけるイコールコストマルチパスへの対応はRFC2991[15]に定義されており,Highest Random Weight(HRW)によってネクストホップ(上流)が決定される,PIM-SMでは,同一リンク上で複数のルータが別の上流を選択するとトラヒックが重複するが,HRWが決定するネクストホップはマルチキャストグループと送信元の組合せごとに全ルータで一意であるため,この問題を回避できる。MT-OSPFのイコールコストマルチパス機能とHRWによるネクストホップの選択により,マルチキャストのトラヒックも負荷分散が可能になる。」

上記アの記載及び図面(特に図4及び図5)並びにこの分野における技術常識を考慮すると,

d 上記アの「RFC1583[12]では,リンクまたは経路にTOS(Type Of Service)[13]に応じた複数のメトリック(コスト)を付与し,TOSごとに異なる経路を計算する機能が定義されている。」から,ルータは,受信パケットのTOSに対応してパケットの転送先を決定して送信している。また,上記アの「MT-OSPFはRFC1583のTOS機能を再利用し,OSPFにおいて複数トポロジーを計算する機能を,IPパケットのTOSフィールドとは関係なく任意の用途に用いることを提案している。」から,TOSは,パケットのTOSフィールドに格納されており,パケットのTOSは,当該TOSフィールドに基づいて特定されているといえる。
したがって,引用文献等1には,「ルータが,受信パケットのTOSフィールドに基づいて当該受信パケットのTOSを特定し,当該TOSに対応して,パケットの転送先を決定し,受信パケットを送信する」ことが記載されていると認められる。

e 図5から,引用文献等1には,「ルータを含むネットワーク」が記載されていると認められる。

以上を総合すると,引用文献等1には以下の発明(以下,「引用発明5」という。)が記載されていると認める。

「 受信パケットのTOSフィールドに基づいて当該受信パケットのTOSを特定し,当該TOSに対応して,パケットの転送先を決定し,受信パケットを送信する
ルータを含む
ことを特徴とするネットワーク。」


また,上記アの記載及び図面(特に図4及び図5)並びにこの分野における技術常識を考慮すると,

f 上記アの「MT-OSPFはリンクや経路に複数のコストを設定し,そこから複数のSPT(Shortest Path Tree)を計算する。」,及び図5並びに関連する記載からは,ホストx,y及びルータA,B,C,Dからなるネットワークにおいて,トラヒックがマルチキャストがユニキャストかに応じて,リンクに異なるコスト(メトリック)を付与し,当該異なるコストに基づいて,マルチキャストのトラヒックとユニキャストのトラヒックに対応する複数の異なるSPT(Shortest Path Tree)を計算することが見て取れる。ここで,前記「リンク」が,前記ホストx,y及びルータA,B,C,Dの間の物理的な接続であることは図5から明らかであるから,前記「異なるSPTの計算」は,前記ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて行われているといえる。また,計算したSPTは,トラヒックがマルチキャストがユニキャストかに応じて行われるルーティングに用いられるのであるから,ネットワークを構成するルータが,前記SPTをマルチキャストのトラヒック(データトラヒック)及びユニキャストのトラヒック(データトラヒック)に対応付けて管理することは明らかである。
したがって,引用文献等1には,「ルータが,ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて計算された2以上の異なるSPTと,前記SPTを適用するデータトラヒックとの対応関係を管理」することが記載されていると認められる。

g 上記アの「MT-ID=0のメトリックによってRIB用のSPTが計算され,xからyへのユニキャスト経路はx⇒A⇒B⇒yになる。」及び「同時に,本手法ではMT-ID=1のメトリックによってMRIB用のSPTを計算する。xからyへのMRIBはx⇒A⇒D⇒C⇒B⇒yと設定される。」から,ルータは,受信パケットがマルチキャストのトラヒック(データトラヒック)に属するかユニキャストのトラヒック(データトラヒック)に属するかに応じて,対応するSPTを選択して,パケットの転送先を決定して送信している。
したがって,引用文献等1には,「ルータが,受信パケットが属するデータトラヒックに対応するSPTを選択して,パケットの転送先を決定し,受信パケットを送信する」ことが記載されていると認められる。

以上を総合すると,引用文献等1には以下の発明(以下,「引用発明6」という。)が記載されていると認める。

「 ホストx,y及びルータA,B,C,Dの間の物理的な接続に基づいて計算された2以上の異なるSPTと,前記SPTを適用するトラヒックとの対応関係を管理し,
受信パケットが属するトラヒックに対応するSPTを選択して,パケットの転送先を決定し,受信パケットを送信すること。」


(2)対比
本願発明と引用発明5とを対比すると,

(エ)本願明細書の【0032】の「なお,図6中のD1,D2のデータトラヒック条件は,パケットヘッダの特定のフィールドの値など,データトラヒックを特定するための条件である。」なる記載から,本願発明の「データトラヒック」とは,少なくともパケットヘッダの特定のフィールドの値に基づいて特定されるものを含んでいる。してみると,引用発明5の,受信パケットのTOSフィールドに基づいて特定される当該受信パケットの「TOS」は,本願発明の「データトラヒック」に含まれる。また,「受信パケットのTOS」は「受信パケットが属するTOS」ともいえる。
したがって,本願発明と引用発明5とは,受信パケットが属するデータトラヒックに対応して行うパケットの転送先の決定を「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して」行うか否か,及びパケットの処理を行う主体として「パケット処理部」を備えるか否かは別として,「受信パケットが属するデータトラヒックに対応して,パケットの転送先を決定し,受信パケットを送信」する点で共通する。

(オ)引用発明5の「ルータ」は,本願発明の「データ転送ノード」に相当する。

以上を総合すると,本願発明と引用発明5とは,以下の点で一致し,また,相違点5ないし8の点で相違している。

(一致点)
「 受信パケットが属するデータトラヒックに対応して,パケットの転送先を決定し,受信パケットを送信する
データ転送ノード含む
ことを特徴とするネットワーク。」

(相違点5)
一致点の「データ転送ノード」に関し,本願発明は,更に,「物理ネットワークトポロジに基づいて生成した2以上の異なる論理ネットワークトポロジと,前記論理ネットワークトポロジを適用するデータトラヒックとの対応関係を管理する論理ネットワークトポロジ管理部」を備えるのに対し,引用発明5は,当該構成が明らかではない点。

(相違点6)
一致点の「受信パケットが属するデータトラヒックに対応して,パケットの転送先を決定」することに関し,本願発明は,「受信パケットが属するデータトラヒックに対応する論理ネットワークトポロジを選択して」行うのに対し,引用発明5は,当該構成が明らかではない点。

(相違点7)
相違点1の「論理ネットワークトポロジ」に関し,本願発明は,更に,「前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報,を適用して生成される」のに対し,引用発明5は,当該構成が明らかではない点。

(相違点8)
本願発明は,データ転送ノードが,一致点の「受信パケットに対応する論理ネットワークトポロジを選択して,パケットの転送先を決定し,受信パケットを送信」する「パケット処理部」を備えるのに対し,引用発明5は,当該構成が明らかではない点。


(3)判断
上記相違点について検討する。

(相違点7について)
上記引用文献等1及び2のいずれにも,「前記論理ネットワークトポロジは,前記データトラヒックの統計情報と顧客情報とに基づいて作成されたポリシー情報,を適用して生成される」ことは記載されておらず,引用発明5に,引用発明6を適用したとしても,上記の事項までは導出されない。

また,他に,このような構成を設けることが当業者にとって容易であったと判断すべき理由を発見しない。


(4)小括
以上のとおりであるから,相違点5,6及び8について検討するまでもなく,本願発明は,当業者が引用発明5及び引用発明6に基づいて,当業者が容易に発明することができたとはいえない。
また,本願の請求項6,8,9に係る発明は,本願発明とカテゴリーが異なるに過ぎず,また本願の請求項2-5,7に係る発明は,本願発明ないし本願発明とカテゴリーが異なる発明をさらに限定したものであるので,本願発明と同様に,当業者が引用発明5及び引用発明6に基づいて,当業者が容易に発明することができたとはいえない。


●理由2(実施可能要件)について
上記手続補正により,補正前の請求項6は削除された。
よって,当審拒絶理由の「●理由2(実施可能要件)について」は解消した。


●理由3(明確性)について
上記手続補正により,補正前の請求項8(補正後の請求項7)が引用する請求項6は「データ転送ノード」の発明となったため,補正後の請求項7に係る発明が「データ転送ノード」であることが明確となった。
よって,当審拒絶理由の「●理由3(明確性)について」は解消した。


そうすると,もはや本願は,当審拒絶理由のいずれによっても拒絶すべきものではない。


第5 むすび
以上のとおり,本願は,原査定の理由によって拒絶すべきものではない。

また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2016-04-11 
出願番号 特願2013-509957(P2013-509957)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 537- WY (H04L)
P 1 8・ 536- WY (H04L)
最終処分 成立  
前審関与審査官 衣鳩 文彦  
特許庁審判長 大塚 良平
特許庁審判官 ▲高▼橋 真之
山本 章裕
発明の名称 ネットワーク、データ転送ノード、通信方法およびプログラム  
代理人 加藤 朝道  

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