• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1370292
審判番号 不服2018-13677  
総通号数 255 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-03-26 
種別 拒絶査定不服の審決 
審判請求日 2018-10-15 
確定日 2021-02-05 
事件の表示 特願2016-159932「仮想ルータクラスタ、データ転送方法および装置」拒絶査定不服審判事件〔平成29年 6月 1日出願公開、特開2017- 98935、請求項の数(6)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2016年(平成28年)8月17日(パリ条約による優先権主張 2015年11月20日、中国)を出願日とする出願であって、その手続の経緯は以下のとおりである。

平成29年 9月26日付け:拒絶理由通知書
平成30年 3月 2日 :意見書の提出
平成30年 6月 8日付け:拒絶査定(原査定)
平成30年10月15日 :審判請求書、手続補正書の提出
令和 元年12月 2日付け:拒絶理由通知
(以下、「当審拒絶理由1」という。)
令和 2年 2月28日 :意見書、手続補正書の提出
令和 2年 6月30日付け:拒絶理由通知(最後の拒絶理由)
(以下、「当審拒絶理由2」という。
なお、当審拒絶理由1,2を合わせて、 「当審拒絶理由」という場合がある。)
令和 2年10月 5日 :意見書、手続補正書の提出

第2 原査定の概要
原査定(平成30年6月8日付け拒絶査定)の概要は、次のとおりである。

1.(新規性)本願請求項1,5,8,12,15に係る発明は、その出願前に日本国内又は外国において、以下の引用文献Aに記載された発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。
2.(進歩性)本願請求項1-18に係る発明は、以下の引用文献AないしEに基いて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

<引用文献等一覧>
A.特開2005-039381号公報
B.特表2013-514744号公報
C.特開2006-203471号公報
D.特開2004-254132号公報
E.進藤智則,サーバーが通信機器に 業界を一変させるNFV,日経エレクトロニクス 第1150号,日経BP社,2014年12月22日,第47-54頁

第3 当審拒絶理由の概要
1.当審拒絶理由1の概要は、次のとおりである。
(1)本願の特許請求の範囲の請求項1ないし18の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。

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

<引用文献等一覧>
A.特開2005-039381号公報
B.特表2013-514744号公報
D.開2004-254132号公報
C.特開2006-203471号公報
E.進藤智則,サーバーが通信機器に 業界を一変させるNFV,日経エレクトロニクス 第1150号,日経BP社,2014年12月22日,第47-54頁
F.特開2012-175425号公報

2.当審拒絶理由2の概要は、次のとおりである。
<理由1-1>本願請求項1ないし6に係る発明は、以下の引用文献1,3-5に基いて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。
<理由1-2>本願請求項1ないし6に係る発明は、以下の引用文献2-6に基いて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。
<引用文献等一覧>
1.特開2005-039381号公報(原査定の文献A)
2.特表2013-514744号公報(原査定の文献B)
3.特開2004-254132号公報(原査定の文献D)
4.進藤智則,サーバーが通信機器に 業界を一変させるNFV,日経エレクトロニクス 第1150号,日経BP社,2014年12月22日,第47-54頁(原査定の文献E)
5.特開2006-203471号公報(原査定の文献C)
6.特開2012-175425号公報(当審拒絶理由1の文献F)

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

「 【請求項1】
ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも2つの仮想ルータを備え、
前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係が無い前記少なくとも2つの仮想ルータから、前記データパケットに対応した第1の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送し、
前記第1の仮想ルータは、前記データパケットを受信して宛先ポートへ転送し、
前記第1の仮想ルータが前記データパケットを受信することは、
第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンであり、前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
前記第1のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第1のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
仮想ルータクラスタ。
【請求項2】
前記ゲートウェイが、オープン・ショーテスト・パス・ファーストプロトコルに基づいて前記少なくとも2つの仮想ルータから前記データパケットに対応した第1の仮想ルータを選択することは、
前記データパケットのアドレス情報を取得するステップと、
前記データパケットのアドレス情報のハッシュ値に基づいて、前記データパケットに対応した第1の仮想ルータを選択するステップとを含むことを特徴とする
請求項1に記載の仮想ルータクラスタ。
【請求項3】
主従関係が無い少なくとも2つの仮想ルータから、オープン・ショーテスト・パス・ファーストプロトコルに基いて選択された第1の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するステップと、
前記第1の仮想ルータにより宛先ポートへ前記データパケットを転送するステップとを含み、
前記第1の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するステップは、
第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンであり、前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
前記第1のカーネルのうちのいずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第1のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
データ転送方法。
【請求項4】
前記オープン・ショーテスト・パス・ファーストプロトコルに基いて選択された第1の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するステップは、
前記データパケットのアドレス情報のハッシュ値に基いて、前記データパケットに対応した第1の仮想ルータを選択することを含むことを特徴とする
請求項3に記載の方法。
【請求項5】
主従関係が無い少なくとも2つの仮想ルータから、オープン・ショーテスト・パス・ファーストプロトコルに基いて選択された第1の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するように構成される受信モジュールであって、前記ゲートウェイに少なくとも2つの仮想ルータが相互接続される、受信モジュールと、
宛先ポートへ前記データパケットを転送するように構成される転送モジュールとを備え、
前記第1の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信することは、
第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンであり、前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
前記第1のカーネルのうちのいずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第1のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
データ転送装置。
【請求項6】
前記受信モジュールは、さらに、
前記データパケットのアドレス情報のハッシュ値に基いて、前記データパケットに対応した第1の仮想ルータを選択するように構成されることを特徴とする
請求項5に記載の装置。」

第5 引用文献、引用発明等
1.引用文献1,3-5記載事項、引用発明1について
(1)引用文献1には、次の事項が記載されている。
ア.「【0005】
これらルータ20,30は、故障時の安全対策として、OSPFプロトコルの二重化を行う場合がある。この場合には、たとえば図13に示すように、物理的には1つのルータ(以下、「物理ルータ」という)20を、データ中継の動作を行う上で論理的に2つのルータ(以下、「論理ルータ」という)21,22に設定し、この二重化されたOSPFプロトコル(OSPF処理部21a,22aに内蔵)によって、これら論理ルータ21,22が他のルータ30とルーティング制御データ(以下、「経路情報」という)の交換を行うものがある。
【0006】
この論理ルータは、動作がアクティブ状態にあり、メイン処理を行う論理ルータ(以下、「アクティブ側ルータ」という)21と、動作がスタンバイ状態にあり、バックアップ処理を行う論理ルータ(以下、「スタンバイ側ルータ」という)22とからなり、各論理ルータ21,22を他のルータ30と接続させ、他のルータ30から受信した経路情報を即座にコピーして、論理ルータ21,22のOSPF処理部21a,22aに転送していた。また、アクティブ側ルータ21側で生成したデータに関しては、ルータ21,22でアクティブ状態とスタンバイ状態を切り替えるときに、すぐにスタンバイ側ルータ22でアクティブ状態の動作を開始できるように、ルータ21,22間で逐次同期をとる必要がある。
【0007】
【非特許文献1】
John Moy著、“RFC2328 OSPF Version2” [online]、インターネット公式プロトコル(STD1)、1998年4月、p.6-15、AlterNIC The Network Information Center、[平成15年1月22日検索]、インターネット<URL:HYPERLINK”http://www.alternic.org/rfcs/rfc2300/rfc2328.html”>
【0008】
【発明が解決しようとする課題】
しかしながら、上記従来例では、他のルータとの経路情報の交換途中で故障が発生してパケットロスがでると、アクティブ側ルータとスタンバイ側ルータが完全に同期できなくなり、上記の状態切り替え時にトポロジー変化に伴う経路情報の受信が不可能となるので、スタンバイ側ルータが初期指定で初期ステートに戻って全体の経路情報を取得するまで、データの中継処理が不可能となり、サービスが停止してしまうという問題点があった。
【0009】
この発明は、上記問題点に鑑みなされたもので、故障発生時にもトポロジー変化に伴う経路情報の受信を正確に行い、データの中継処理を極力停止させることなく、容易にデータ中継装置の二重化を図ることができるデータ中継方法、データ中継装置およびその装置を用いたデータ中継システムを提供することを目的とする。」

イ.「【0027】
(実施の形態1)
図1は、この発明にかかるデータ中継システムの概略構成の一例を示すシステム構成図である。図において、この実施の形態のデータ中継システムは、図13と同様に、AS内部の複数のルータ20,30がネットワーク10上に設けられて接続されており、これらルータ20,30は、故障時の安全対策として、OSPFプロトコルの二重化が行われている。
【0028】
このルータ20は、この発明の実施の形態にかかるデータ中継装置であり、この二重化されたOSPFプロトコルを搭載したアクティブ状態の論理ルータであるアクティブ側ルータ21と、スタンバイ状態の論理ルータであるスタンバイ側ルータ22と、これらルータ21,22との間で制御データであるトポロジー情報(以下、「LSA情報」という。LSA:Link Status Advertisement)ならびに経路情報の取得、およびデータ中継を行うために論理的に設けられた論理ルータである仮想ルータ23とから構成されている。
【0029】
この実施の形態にかかるルータ20では、図2に示すように、アクティブ側ルータ21およびスタンバイ側ルータ22と他のルータ30間で別々に経路情報の交換を行うことによって経路情報を取得している。なお、アクティブ側ルータ21およびスタンバイ側ルータ22がともに正常に動作している通常状態の場合には、最適経路のネクストホップとしては、アクティブ側ルータ21が設定されて、相手ルータ30および仮想ルータ23の経路情報データベース内に記憶されている。また、アクティブ側ルータ21およびスタンバイ側ルータ22は、AS内の ネットワーク10側の経路情報を取得するとともに、仮想ルータ23との間で経路情報の交換を行うことによってAS以外のネットワーク40側の経路情報の取得も行っている。」

ウ.「【0050】
このように、この実施の形態では、スタンバイ側ルータ22も異なるOSPF論理ルータとして、アクティブ側ルータ21とともに動作させ、このアクティブ側ルータ21およびスタンバイ側ルータ22は、仮想ルータ23を介在させたネットワーク全体のLSA情報を通知して、自ルータ20経由で中継されるデータを全て仮想ルータ23を介して送達可能とするので、故障発生時にもトポロジー変化に伴う経路情報の受信を正確に行い、データの中継処理を極力停止させることなく、容易にデータ中継装置の二重化を図ることができる。なお、この実施の形態では、最適経路情報を書き替える僅かな時間、停止させるだけでデータ中継を再開させることができる。」

エ.引用発明1
したがって、引用文献1には、次の発明(以下、「引用発明1」という。)が記載されている。
「物理的には1つのルータ(以下、「物理ルータ」という)20を、データ中継の動作を行う上で論理的に2つのルータ(以下、「論理ルータ」という)21,22に設定し、
この論理ルータは、動作がアクティブ状態にあり、メイン処理を行う論理ルータ(以下、「アクティブ側ルータ」という)21と、動作がスタンバイ状態にあり、バックアップ処理を行う論理ルータ(以下、「スタンバイ側ルータ」という)22とからなり、
各論理ルータ21,22を他のルータ30と接続させ、
このルータ20は、データ中継装置であり、二重化されたOSPFプロトコルを搭載したアクティブ状態の論理ルータであるアクティブ側ルータ21と、スタンバイ状態の論理ルータであるスタンバイ側ルータ22と、
データ中継を行うために論理的に設けられた論理ルータである仮想ルータ23を備え、
アクティブ側ルータ21およびスタンバイ側ルータ22がともに正常に動作している通常状態の場合には、最適経路のネクストホップとしては、アクティブ側ルータ21が設定されて、相手ルータ30および仮想ルータ23の経路情報データベース内に記憶され、
アクティブ側ルータ21およびスタンバイ側ルータ22は、仮想ルータ23を介在させたネットワーク全体のLSA情報を通知して、自ルータ20経由で中継されるデータを全て仮想ルータ23を介して送達可能とする、
データ中継装置。」

(2)引用文献3には、次の事項が記載されている。
「【0014】
このような、IPフローの制御に関して、帯域の広い経路に、流れている量の多いパケットが割り当られるようにし、ハッシュ演算を行って、負荷の分散を行う技術が、特許文献1に示されている図4は特許文献1に記載された発明の原理説明図であり、図4において、ルータ1-1,1-2間はマルチリンク接続されており、ルータ1-1は、パケットからヘッダ情報を抽出するヘッダ情報抽出部と、ヘッダ情報をキーとしてハッシュ演算するハッシュ演算部と、ハッシュ値に基づき、出力インタフェースを決定する出力インタフェース決定部を備えている。そして、他のルータヘ直接接続されている経路が複数存在するルータに対してルーティングを行う必要があるパケットが入ってきた場合、ヘッダ情報の1つ又は複数を抽出し読み込む。読み込んだヘッダ情報をキーとしてハッシュ演算を行い、その計算結果であるハッシュ値に対応するインタフェースにパケットを出力する。従って、抽出したヘッダ情報が同一であるパケットの出力インタフェースは常に同一となる。このため、従来のようにパケットの順序逆転が起こることがない。また、上記ハッシュ演算式として、流れている量の多いパケットに帯域の広い経路が割り当てられるような関数を用いることにより、負荷集中を回避することができ、負荷分散を図ることが可能となる。
【0015】
また、使用されるLSPの平均使用率がバランスするように、ハッシュ演算を行ってIPフローの振り分け処理を行う技術が、非特許文献1に示されている非特許文献1に示されている技術を図5を用いて説明する。非特許文献1には、設定されたエンジニアリングルートとデフォルトルート(最初に張られるLSP)間でトラフィックを均等に分散させるために、LERでは、IPフローの振り分けを行う。図5に示すように、入ってきたIPパケットのあて先アドレス、送信元アドレス、送信ポートアドレス、受信ポートアドレス、通信プロトコル等をキーとして、ハッシュ演算(ここでは、CRC(Cyclic Redundancy Check)16を用いているので、その値は、0?65535となる。)により、LSPを選択する。このハッシュ演算の結果の取り得る値の範囲を、同一のLER側のLSRに対し既に設定されているLSPの本数で分割しており、この区切をハッシュ境界値と呼ぶ。図5では、ハッシュ値が0?V1の場合は、そのパケットはLSP1のパスを用いて送信し、ハッシュ値がV1?V2の場合は、そのパケットはLSP2のパスを用いて送信し、ハッシュ値がV2?65535の場合は、そのパケットはLSP3のパスを用いて送信する。このハッシュ境界値をLSP1?LSP3の使用率に応じて動かすことで、LSP間での動的なロードバランシングが可能となる。」

(3)引用文献4には、次の事項が記載されている。
ア.(第48頁右欄16行目-第49頁左欄14行目、図1)
「ハードとソフトを分離
NFVは、ソフトウエア的に見ると主に3つの層から成る。まず、大量のx86サーバー上で、ハードの細かな違いを吸収するサーバー仮想化ソフト「ハイパーバイザー^(†)」を動作させる。これが一番下の層である。次に、このハイパーバイザーが作り出す仮想のサーバー環境「仮想マシン(VM)」上で、LinuxなどのOSを「ゲストOS」として動作させる。VMは、1つのサーバー上で複数動作させることができる。ルーターやファイアウォールといった通信機能は、各VMのゲストOS上でアプリケーションとして動作させる。これが3つ目の層である。」

ア-2.(第51頁左欄30行目ー34行目)
「現在では仮想スイッチや仮想ルータなどNFV向けソフトの多くに、DPDKが使われている(表1)。事実上、NFVの技術のデファクトスタンダードとなっている。」

イ.(第52頁左欄1行目-11行目)
「しかし、汎用のx86サーバーを通信に特化した形で使うNFVでは、割り込み処理はオーバーヘッドとなる。そこでDPDKでは、割り込み処理の代わりにポーリング処理を採用した。ポーリング処理とは、割り込み処理のようなイベント駆動型ではなく、周期的に問い合わせる処理のことだ。受信パケットが来ているかをNICに一定周期で問い合わせ、パケットが来ていれば即、受信処理を始める。」

ウ.(第52頁中央欄2行目-10行目)
「実は、DPDKのように通信処理をポーリング処理で実装する仕組みは、Linuxでは以前からあった。「NAPI(newAPI)」という仕組みである。ただし、NAPIはLinuxカーネル(カーネル空間)においてポーリング処理を実装していた。これに対し、DPDKはユーザー空間においてポーリング処理を実装しているのが特徴である。」

ウ-2.(第52頁中央欄11行目-右欄1行目)
「DPDKがユーザ空間での実装を選択したのは、DPDK自体の利用のしやすさを考慮したからだ。LinuxはC言語で実装されているが、カーネル空間向けの開発では、通常のC言語の標準ライブラリなどが一切使えないため、開発のハードルが高い。ユーザ空間であれば、そうした制限がなく、DPDKを使った新たな通信機能の実装は比較的容易である。」

(5) 引用文献5には、次の事項が記載されている。
ア.「【0006】
従来例(1):ハッシュ方式負荷分散(図16)
図16において、端末300_1及び300_2(以後、符号300で総称することがある。)が、それぞれ、サーバ200に対してデータのダウンロードを要求した場合(ステップS500参照。)、サーバ200から送出された端末300_1及び300_2宛のパケット(データ)は、エッジルータ100a_1を経由して端末300_1及び300_2に送信される。このとき、ルータ100a_1は、入力側の100Mbps回線500_2から受信したパケットをハッシュ方式で負荷分散して出力側の10Mbps回線(パス)510_1又は10Mbps回線510_2に送出する(ステップS510参照。)。すなわち、ルータ100a_1は、受信したパケットの送信元IPアドレス又は宛先IPアドレスを元にハッシュ値を計算し、この値に対応した送出パスを決定する。」

2.引用文献2、6記載事項、引用発明2について
(1)引用文献2には、次の事項が記載されている。
ア.「【0006】
一般的に記述すると、本開示は分散ルーティングアーキテクチャに対応する。具体的には、本開示は、ネットワーク構成要素間のデータパケットの受信、処理および転送のための少なくとも2つの論理レベルまたは層を含む、階層分散ルーティングアーキテクチャに対応する。一実施形態では、2つの論理レベルは、コアレベルおよび分散レベルに対応することができる。実例として、コアレベルは、ネットワーク構成要素から着信パケットを受信し、受信されたパケットに関連付けられた宛先アドレス情報を処理する、1つまたは複数のルータ構成要素に対応する。コアレベルルータ構成要素は、それから、受信されたパケットに関連付けられた宛先アドレスのサブセットに基づき、分散レベルルータ構成要素を識別する。分散レベルは、コアレベルルータ構成要素から転送されたパケットを受信し、受信されたパケットに関連付けられた宛先アドレス情報をさらに処理する1つまたは複数のルータ構成要素に対応する。分散レベルルータ構成要素は、階層分散ルーティングアーキテクチャから適切な通過ルートを識別する。それぞれの分散レベルルータ構成要素は、分散ルーティングアーキテクチャに関連付けられたFIBのサブセットに関連付けられ、またはそうでなければ対応する。分散ルーティング環境に関連付けられたFIBの部分のマッピング、または他の割り当ては、ルータ管理構成要素が管理する。
【0007】
一実施形態では、コアレベルおよび分散レベルに関連付けられたルータ構成要素のそれぞれは、商品ベースのルータ構成要素/ハードウェアにより詳しく対応することが可能である。別の実施形態では、コアレベルおよび分散レベルルータ構成要素は、必ずしも対応するハードウェアルータ構成要素を持たない論理ルータ構成要素に対応する。例えば、それぞれのレベル内の1つまたは複数の論理ルータ構成要素は、同一のハードウェアルータ構成要素内に実装されてもよい。同様に、分散ルーティングアーキテクチャの異なるレベルに関連付けられた論理ルータ構成要素は、同一のハードウェアルータ構成要素内に実装されてもよい。さらなる例では、コアレベルおよび分散レベルルータ構成要素は、着信パケットを受信し適切な分散レベルルータ構成要素を判断するコアレベルルータ構成要素として、および分散レベルルータ構成要素としての両方で作動するルータ構成要素に対応してもよい。」

イ.「【0011】
第1の通信ネットワーク104と通信しているのは分散ルーティング環境100の第1のレベルであり、通常コア層またはコアレベルと呼ばれる。1つの実施形態では、コアレベルは、通常コアレベルルータ106A、106B、および106Cと呼ばれる1つまたは複数の論理ルータ構成要素に対応する。前述したように、分散ルーティング環境100内では、コアレベルルータ106A、106B、106Cはネットワーク104からの構成要素から着信パケットを受信し、受信されたパケットに関連付けられた宛先アドレスのサブセットに基づき分散レベルルータ構成要素を識別することにより宛先アドレスを処理する。実例として、宛先アドレスのサブセトは、IPアドレスの最上位ビットの値のように、宛先IPアドレス全体より少なく対応することができる。前述したように、コアレベルルータ106A、106B、106Cは、1つまたは複数のハードウェア構成要素に実行される論理ルータ構成要素に対応することができる。1つの実施形態では、それぞれの論理ルータ構成要素は、専用の物理ルータ構成要素に対応することができる。別の実施形態では、それぞれの論理ルータ構成要素は、分散ルータ環境100内で少なくとも1つの他の論理ルータ構成要素に共用される物理ルータ構成要素に対応することができる。代替的な実施形態で、コア層の少なくもいくつかの部分は、分散ルータ環境100の外側の構成要素により実行されてもよい。そのような実施形態では、そのような外部の構成要素は分散ルータ環境100の分散レベルルータ構成要素(後述)を直接アドレス指定することになる。
【0012】
分散ルーティング環境100は、概して分散層または分散レベルと呼ばれる論理ルータ構成要素の第2のレベルをさらに含むことができる。一実施形態では、分散レベルは、概して分散レベルルータ108A、108Bおよび108Cと呼ばれる1つまたは複数のルータ構成要素に対応する。前述したように、分散ルーティング環境100内で、分散レベルルータ108A、108Bおよび108Cは、コアルーティング構成要素102から着信パケットを受信し、および受信されたパケットの1つまたは属性による着信パケットを処理する。実例として、宛先アドレスのサブセットは、コアレベルルータ106A、106B、106Cにより使用される宛先IPアドレスのより大きなサブセットに対応することができる。この実施形態で、分散レベルにより実行されるルーティングは、コアレベルルーティングに関連する受信されたパケットのより改良されたルーティングに対応することができる。コアレベルルータ106A、106B、106Cについて前述したように、分散レベルルータ108A、108B、および108Cは、1つまたは複数のハードウェア構成要素に実行される論理ルータ構成要素に対応することができる。1つの実施形態では、それぞれの論理ルータ構成要素は、専用の物理ルータ構成要素に対応することができる。他の実施形態では、それぞれの論理ルータ構成要素は、分散ルータ環境100内の少なくとも1つの他の論理ルータ構成要素に共用される物理ルータ構成要素に対応することができる。」

ウ.「【0019】
ここで図2A?図2Dを参照すると、分散ルーティング環境100による受信するパケットの処理が示される。まず図2Aおよび図2Bを参照すると、着信パケットが通信ネットワーク104からコアレベルルータ106へ受信される。着信パケットを受信するコアレベルルータ106は、負荷分散、無作為抽出、ラウンドロビン、ハッシング、および他のパケット分散技術を含むさまざまな技術により選択してもよいが、技術はそれらに限定されない。受信すると、コアレベルルータ106は宛先IPアドレスを処理し、宛先IPアドレスのサブセットを使用してルーティングの第2のレベルを実行する第2のレベル宛先ルータ構成要素を識別する。例示の実施形態では、コアレベルルータ106は、宛先アドレスの最上位8ビットのような、IPアドレスの最上位ビットを使用する。最上位ビットの選択に対応するIPアドレスのサブセットの選択は、概してプレフィクスと呼ばれる。例えば、最上位8ビットの選択は、プレフィクス長"8"に対応する。最上位16ビットの選択は、プレフィクス長"16"に対応する。当業者は、コアレベルルータ106が使用するビットの数が変わってもよいことを理解するであろう。また、代わりの実施形態では、コアレベルルータ106は異なる方法論を使用して、分散ルーティング環境100がサービスするアドレススペースを割り振り、またはそうでなければ細分してもよく、例えばIPフローレベル情報またはIPフロー記述子に基づく細分を含む。そのようなIPフローレベル情報は、送信元および宛先IPアドレス情報またはポート情報を含むことができる。
【0020】
宛先アドレスの第1のサブセットの処理に基づき、コアレベルルータ106はパケットを分散レベルルータ、この場合は108Aで示された「分散ルータ1」へ転送する。 前述したように、受信する分散レベルルータ108Aは受信されたパケットの宛先アドレスを処理し、また宛先IPアドレスのサブセットを使用して、受信されたパケットを次のネットワーク宛先(分散ルーティング環境100の外側)へ転送する。コアレベルルータ106と同様に、受信する分散レベルルータをIPアドレスの最上位ビット(例えばプレフィクス)の選択を使用しパケットをルーティングするように構成することができる。例示の実施形態では、分散レベルルータ108Aが使用するプレフィクスは、コアレベルルータ106が使用するプレフィクスより大きい。図2Aに示されるように、外部の通過構成要素110を移送の促進のために使用してもよい。代わりに、また図2Bを参照すると、分散レベルルータ108Aはパケットを直接通信ネットワーク112へ伝送してもよい。」

エ.「【0025】
なおさらなる実施形態では、複数の分散レベルルータ108を、IPアドレスのサブセットに選択してもよい。この実施形態では、それぞれのコアレベルルータ106は、等コストマルチパスルーティング(ECMP)技術に基づき複数の分散レベルルータ108から選択することができ、特定の分散レベルルータ108が標準負荷分担技術に基づき選択される。複数の割り当てられた分散レベルルータ108から選択するのに使用可能な他の因子は、通信媒体の選好性、インターネットウェザー、リソース使用率/正常性レポート、割り振られた、または判断されたルーティングコスト、サービスレベルアグリーメント(SLA)、または他の基準を含む。」

オ.引用発明2
したがって、引用文献2には、次の発明(以下、「引用発明2」という。)が記載されている。

「ネットワーク構成要素間のデータパケットの受信、処理および転送のための少なくとも2つの論理レベルまたは層を含む、階層分散ルーティングアーキテクチャに対応し、
コアレベルおよび分散レベルルータ構成要素は、必ずしも対応するハードウェアルータ構成要素を持たない論理ルータ構成要素に対応し、
第1の通信ネットワーク104と通信しているのは分散ルーティング環境100の第1のレベルであり、通常コア層またはコアレベルと呼ばれ、
コアレベルは、通常コアレベルルータ106A、106B、および106Cと呼ばれる1つまたは複数の論理ルータ構成要素に対応し、
分散ルーティング環境100は、概して分散層または分散レベルと呼ばれ、
分散レベルルータ108A、108B、および108Cは、1つまたは複数のハードウェア構成要素に実行される論理ルータ構成要素に対応し、
着信パケットが通信ネットワーク104からコアレベルルータ106へ受信され、
宛先アドレスの第1のサブセットの処理に基づき、コアレベルルータ106はパケットを分散レベルルータ、この場合は108Aで示された「分散ルータ1」へ転送し、
分散レベルルータ108Aはパケットを直接通信ネットワーク112へ伝送し、
コアレベルルータ106は、等コストマルチパスルーティング(ECMP)技術に基づき複数の分散レベルルータ108から選択することができ、特定の分散レベルルータ108が標準負荷分担技術に基づき選択される、
階層分散ルーティングアーキテクチャ。」

(2)引用文献6には、次の事項が記載されている。
ア.「【0004】
OSPFにおいてはECMP(Equal Cost Multi Path)機能(ある宛先までの最短経路が複数存在している場合、その全部もしくは2以上のパスを現用パスとして負荷分散を行う機能)を有しており、多くの場合ECMP機能は有効化されている。」

第6 対比・判断
1.本願発明1について
(1)引用発明1を主引用発明とする理由について
(1-1)対比
本願発明1と引用発明1とを対比する。
ア.引用発明1の「仮想ルータ23」は、ネットワーク10と、アクティブ側ルータ21との間で、データ中継を行っていることから、本願発明1の「外部機器から転送されたデータパケットを受信」する「ゲートウェイ」に相当する。

イ.引用発明1の「アクティブ側ルータ21」と「スタンバイ側ルータ22」とは、1つの物理ルータ20において、データ中継の動作を行う上で論理的に2つのルータとして設定され、「仮想ルータ23」と互いに接続していることから、本願発明1の「前記ゲートウェイと相互接続する少なくとも2つの仮想ルータ」に相当する。

ウ.引用発明1において、「二重化されたOSPFプロトコル」に基づいて、「アクティブ側ルータ21およびスタンバイ側ルータ22」から、「ネクストホップとしては、アクティブ側ルータ21」を設定することは、本願発明1の「前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係が無い前記少なくとも2つの仮想ルータから、前記データパケットに対応した第1の仮想ルータを選択」することと「前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、前記少なくとも2つの仮想ルータから前記データパケットに対応した第1の仮想ルータを選択」する点で共通するといえる。

エ.引用発明1において、「アクティブ側ルータ21およびスタンバイ側ルータ22は、自ルータ20経由で中継されるデータを全て仮想ルータ23を介して送達」することは、本願発明1の「ゲートウェイ」が、「前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送」する点、及び、本願発明1の「前記第1の仮想ルータが前記データパケットを受信する」点で共通するといえる。

オ.引用発明1における、「物理ルータ」は、「論理的に2つのルータ(以下、「論理ルータ」という)21,22」を設定し、データ中継を行っていることから、本願発明1の「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンであり、前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」と、「前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンである、ステップ」である点で共通するといえる。

カ.引用発明1における、「データ中継装置」は、「アクティブ側ルータ21」と、「スタンバイ側ルータ22」と、「仮想ルータ23」を備えていることから、本願発明1の「仮想ルータクラスタ」に相当する。

したがって、本願発明1と引用発明1の一致点及び相違点は、次のとおりである。

[一致点]
「ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも2つの仮想ルータを備え、
前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、前記少なくとも2つの仮想ルータから、前記データパケットに対応した第1の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送し、
前記第1の仮想ルータが前記データパケットを受信することは、
前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンである、ステップとを含むことを特徴とする
仮想ルータクラスタ。」

[相違点1]
本願発明1は、「主従関係が無い前記少なくとも2つの仮想ルータ」から「第1の仮想ルータを選択」するの対し、引用発明1は、「メイン処理を行う論理ルータ(以下、「アクティブ側ルータ」という)21と、動作がスタンバイ状態にあり、バックアップ処理を行う論理ルータ(以下、「スタンバイ側ルータ」という)」から「第1の仮想ルータを選択」する点。

[相違点2]
本願発明1は、「前記第1の仮想ルータは、前記データパケットを受信して宛先ポートへ転送し」ているのに対し、引用発明1には、「宛先ポート」へ転送しているか特定されていない点。

[相違点3]
本願発明1は、「前記第1の仮想ルータが前記データパケットを受信すること」に、「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、」「前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」が含まれているのに対し、引用発明1には、「アクティブ側ルータ21」及び「スタンバイ側ルータ22」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。

[相違点4]
本願発明1は、「前記第1の仮想ルータが前記データパケットを受信すること」に、「前記第1のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第1のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップ」が含まれているのに対し、引用発明1には、「アクティブ側ルータ21」及び「スタンバイ側ルータ22」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。

(1-2).相違点についての判断
事案に鑑みて先ず相違点1について検討する。
引用発明1は、「アクティブ側ルータとスタンバイ側ルータと」から仮想ルータを選択するものであり、両者は、メイン処理とバックアップ処理という、主従の関係にある仮想ルータであると認められる。
よって、引用発明1は、相違点1にかかる「主従関係がない前記少なくとも2つの仮想ルータ」から「第1の仮想ルータを選択する」なる構成と真逆の構成を示すものであり、当該構成を変更するための阻害要因があるというべきである。
また、上記「第5」の「1.(1)ア.」を参照すると、引用文献1は、アクティブ側ルータとスタイバイ側ルータの両方を用いるシステムにおいて、故障発生時にもトポロジー変化に伴う経路情報の受信を正確に行うことを行うことを課題としており、当該課題を解決するための構成であるアクティブ側ルータ及びスタンバイ側ルータの両方を用いること、すなわち、主従の関係にある仮想ルータから(第1の)仮想ルータを選択することを変更する起因はないものと認められる。また、引用文献1の明細書及び図面における他の記載において、相違点1に係る構成を導くための記載や示唆もない。
したがって、他の相違点を検討するまでもなく、本願発明1は、当業者であっても、引用発明1及び引用文献3-5記載の技術的事項に基づいて容易に発明をすることができたとはいえない。

(2)引用発明2を主引用発明とする理由について
(2-1)対比
本願発明1と引用発明2とを対比する。

ア.引用発明2の「コアレベルルータ106」は、外部の「通信ネットワーク104から」パケットを着信し、「分散レベルルータ108A」へパケットを転送していることから、本願発明1の「外部機器から転送されたデータパケットを受信」する「ゲートウェイ」に相当する。

イ.引用発明2の「分散レベルルータ108A、108B、および108C」は、「コアレベルルータ106」からパケットを着信していることから、本願発明1の「ゲートウェイと相互接続する少なくとも2つの仮想ルータ」に相当する。

ウ.引用発明2において、「宛先アドレスの第1のサブセットの処理に基づき、コアレベルルータ106はパケットを分散レベルルータ、この場合は108Aで示された「分散ルータ1」へ転送」することは、本願発明1の「前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係のない前記少なくとも2つの仮想ルータから、前記データパケットに対応した第1の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送」することと、「前記ゲートウェイは、さらに、前記少なくとも2つの仮想ルータから前記データパケットに対応した第1の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送」する点で共通するといえる。

エ.引用発明2において、「分散レベルルータ108Aはパケットを直接通信ネットワーク112へ伝送」することは、本願発明1の「前記第1の仮想ルータは、前記データパケットを受信して宛先ポートへ転送」されることと、「前記第1の仮想ルータは、前記データパケットを受信して宛先へ転送」される点で共通するといえる。

オ.引用発明2における「ハードウェア構成要素」は、「論理ルータ構成要素」を「実行」していることから、本願発明1の「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンであり、前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」と、「前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンである、ステップ」である点で共通するといえる。

カ.引用発明2における「階層分散ルーティングアーキテクチャ」は、「ネットワーク構成要素間のデータパケットの受信、処理および転送のため」に「2つの論理レベル」として「コアレベルルータ106」と「分散レベルルータ108A」を備えていることから、本願発明1の「仮想ルータクラスタ」に相当する。

したがって、本願発明1と引用発明2との一致点及び相違点は、次のとおりである。

[一致点]
「ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも2つの仮想ルータを備え、
前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
前記ゲートウェイは、さらに、前記少なくとも2つの仮想ルータから、前記データパケットに対応した第1の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第1の仮想ルータへ転送し、
前記第1の仮想ルータは、前記データパケットを受信して宛先へ転送し、
前記第1の仮想ルータが前記データパケットを受信することは、
前記第1のホストは、前記第1の仮想ルータを集積するための物理マシンである、ステップとを含むことを特徴とする
仮想ルータクラスタ。」


[相違点5]
本願発明1は、「オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係のない」第1の仮想ルータを選択しているのに対し、引用発明2は、「宛先アドレスの第1のサブセットの処理」や「等コストマルチパスルーティング(ECMP)技術」に基づいて「分散レベルルータ」を選択しており、オープン・ショーテスト・パス・ファーストプロトコルを用いていること、主従関係のない仮想ルータが選択されていることが特定されていない点。

[相違点6]
本願発明1は、第1の仮想ルータが、受信したデータパケットを「宛先ポートへ」転送しているのに対し、引用発明2には、「宛先ポートへ」転送しているか特定されていない点。

[相違点7]
本願発明1は、「前記第1の仮想ルータが前記データパケットを受信すること」に、「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングするステップであって、」「前記第1のカーネルは、前記第1のホストにおいて前記第1の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」が含まれているのに対し、引用発明2には、「アクティブ側ルータ21」及び「スタンバイ側ルータ22」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。

[相違点8]
本願発明1は、「前記第1の仮想ルータが前記データパケットを受信すること」に、「前記第1のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第1のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップ」が含まれているのに対し、引用発明2には、「アクティブ側ルータ21」及び「スタンバイ側ルータ22」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。

(2-2).相違点についての判断
事案に鑑みて、先ず相違点7について検討する。
上記「第5」の「1.(3)ア、イ」を参照すると、各仮想マシンのゲストOS上でアプリケーションとして、動作する通信機能がポーリング処理を行う技術が記載されている。
また、上記「第5」の「1.(3)ウ」を参照すると、引用文献4には、「Linuxカーネル(カーネル空間)においてポーリング処理」を行う技術が記載されている。
しかしながら、当該ポーリング処理が仮想マシン上の、Linuxカーネル(カーネル空間)において行われることは記載されておらず、当該記載から自明であるともいえない。
したがって、引用文献4には、本願発明1の「前記第1の仮想ルータが前記データパケットを受信すること」において「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングする」構成を備えることは、開示されておらず、本願優先日前において周知技術であったとも認められない。

そして、仮に、「前記第1の仮想ルータが前記データパケットを受信すること」において「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングする」構成を備えること(ポーリング処理が仮想マシン上の、Linuxカーネル(カーネル空間)において行われること)が、上記記載から自明であるか、本願優先日前において周知技術であったとしても、上記「1.(3)アー2、ウ-2」を参照すると、(ユーザ空間においてポーリングを実装する)DPDKがデファクトスタンダードとなっており、カーネル空間向けの開発がハードルが高いとの記載がある。
よって、引用発明2において、ポーリングを実装する際に、デファクトスタンダードであり、開発の比較的容易な、ユーザ空間においてポーリングを実装するDPDKではなく、開発のハードルが高く、デファクトスタンダードでもない、仮想マシン上の、Linuxカーネル(カーネル空間)においてポーリング処理を行う技術をあえて採用する起因はないものと認められる。

したがって、他の相違点を検討するまでもなく、引用発明2及び引用文献3-6に記載された技術的事項に基いて当業者が容易に発明できたものであるとはいえない。

(3)小括
(1)、(2)における検討のとおり、本願発明1は、引用文献1-6に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。

2.本願発明3,5について
本願発明3,5は、それぞれ、本願発明1に対応する、転送方法の発明と、データ転送装置の発明であり、本願発明1の「主従関係がない前記少なくと2つの仮想ルータ」から「第1の仮想ルータを選択する」構成及び「前記第1の仮想ルータが前記データパケットを受信すること」において「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングする」構成を備えることと同様の構成を備えているものであるから、本願発明1と同じ理由により、引用文献1-6に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。

3.本願発明2,4,6について
本願発明2,4,6は、本願発明1,3,5を減縮した発明であるから、本願発明1と同様の理由により、引用文献1-6に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。

第7 原査定についての判断
令和2年2年10月5日の補正により、補正後の請求項1-6に係る発明は、「主従関係がない前記少なくと2つの仮想ルータ」から「第1の仮想ルータを選択する」構成及び「前記第1の仮想ルータが前記データパケットを受信すること」において「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングする」構成を備えることを有するものとなった。
そして、当該「主従関係がない前記少なくとも2つの仮想ルータ」から「第1の仮想ルータを選択する」構成及び「前記第1の仮想ルータが前記データパケットを受信すること」において「第1のカーネルが所定の時間間隔で第1のホストのネットワークインターフェースをポーリングする」構成を備えることとは、原査定において引用された文献A-Eのいずれにも記載されておらず、本願優先日前におけて周知技術であったとも認められない。
したがって、本願発明1-6は、当業者であっても、引用発明A-E記載の技術的事項に基づいて容易に発明をすることができたとはいえない。

第8 むすび
以上のとおり、原査定の理由によって、本願発明を拒絶することはできない。
他に本願発明を拒絶すべき理由を発見しない。
したがって、結論のとおり審決する。
 
審決日 2021-01-22 
出願番号 特願2016-159932(P2016-159932)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 速水 雄太玉木 宏治  
特許庁審判長 稲葉 和生
特許庁審判官 太田 龍一
小田 浩
発明の名称 仮想ルータクラスタ、データ転送方法および装置  
代理人 森本 聡二  
代理人 奥山 尚一  
代理人 中村 綾子  
代理人 田中 祐  
代理人 松島 鉄男  
代理人 有原 幸一  
  • この表をプリントする

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