【事件の表示】
　特願２０１６−１５９９３２「仮想ルータクラスタ、データ転送方法および装置」拒絶査定不服審判事件〔平成２９年　６月　１日出願公開、特開２０１７−　９８９３５、請求項の数（６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１６年（平成２８年）８月１７日（パリ条約による優先権主張　２０１５年１１月２０日、中国）を出願日とする出願であって、その手続の経緯は以下のとおりである。
　　　平成２９年　９月２６日付け：拒絶理由通知書
　　　平成３０年　３月　２日　　：意見書の提出
　　　平成３０年　６月　８日付け：拒絶査定（原査定）
　　　平成３０年１０月１５日　　：審判請求書、手続補正書の提出
　　　令和　元年１２月　２日付け：拒絶理由通知
　　　　　　　　　　　　　　　　（以下、「当審拒絶理由１」という。）
　　　令和　２年　２月２８日　　：意見書、手続補正書の提出
　　　令和　２年　６月３０日付け：拒絶理由通知（最後の拒絶理由）
　　　　　　　　　　　　　　　　（以下、「当審拒絶理由２」という。
　　　　　　　　　　　　　　　　なお、当審拒絶理由１，２を合わせて、　　　　　　　　　　　　　　　　「当審拒絶理由」という場合がある。）
　　　令和　２年１０月　５日　　：意見書、手続補正書の提出
第２　原査定の概要
　原査定（平成３０年６月８日付け拒絶査定）の概要は、次のとおりである。
１．（新規性）本願請求項１，５，８，１２，１５に係る発明は、その出願前に日本国内又は外国において、以下の引用文献Ａに記載された発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
２．（進歩性）本願請求項１−１８に係る発明は、以下の引用文献ＡないしＥに基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　＜引用文献等一覧＞
Ａ．特開２００５−０３９３８１号公報
Ｂ．特表２０１３−５１４７４４号公報
Ｃ．特開２００６−２０３４７１号公報
Ｄ．特開２００４−２５４１３２号公報
Ｅ．進藤智則，サーバーが通信機器に　業界を一変させるＮＦＶ，日経エレクトロニクス　第１１５０号，日経ＢＰ社，２０１４年１２月２２日，第４７−５４頁
第３　当審拒絶理由の概要
１．当審拒絶理由１の概要は、次のとおりである。
（１）本願の特許請求の範囲の請求項１ないし１８の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。
（２）本願の請求項１ないし１８にかかる発明が、以下の引用文献Ａ，Ｄ−Ｅ、又は、引用文献Ｂ−Ｆに基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　＜引用文献等一覧＞
Ａ．特開２００５−０３９３８１号公報
Ｂ．特表２０１３−５１４７４４号公報
Ｄ．開２００４−２５４１３２号公報
Ｃ．特開２００６−２０３４７１号公報
Ｅ．進藤智則，サーバーが通信機器に 業界を一変させるＮＦＶ，日経エレクトロニクス 第１１５０号，日経ＢＰ社，２０１４年１２月２２日，第４７−５４頁
Ｆ．特開２０１２−１７５４２５号公報
２．当審拒絶理由２の概要は、次のとおりである。
＜理由１−１＞本願請求項１ないし６に係る発明は、以下の引用文献１，３−５に基いて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
＜理由１−２＞本願請求項１ないし６に係る発明は、以下の引用文献２−６に基いて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　＜引用文献等一覧＞
１．特開２００５−０３９３８１号公報（原査定の文献Ａ）
２．特表２０１３−５１４７４４号公報（原査定の文献Ｂ）
３．特開２００４−２５４１３２号公報（原査定の文献Ｄ）
４．進藤智則，サーバーが通信機器に　業界を一変させるＮＦＶ，日経エレクトロニクス　第１１５０号，日経ＢＰ社，２０１４年１２月２２日，第４７−５４頁（原査定の文献Ｅ）
５．特開２００６−２０３４７１号公報（原査定の文献Ｃ）
６．特開２０１２−１７５４２５号公報（当審拒絶理由１の文献Ｆ）
第４　本願発明
　本願の請求項１−６に係る発明（以下、それぞれ「本願発明１」−「本願発明６」という。）は、令和２年１０月５日に提出された手続補正書に記載の特許請求の範囲の請求項１ないし６に記載された事項により特定される発明であり、本願発明１−６は、以下のとおりの発明である（補正された箇所に下線を付した。）。
「　　【請求項１】
　ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも２つの仮想ルータを備え、
　前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
　前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、
主従関係が無い
、
　前記第１の仮想ルータは、前記データパケットを受信して宛先ポートへ転送し、
　前記第１の仮想ルータが前記データパケットを受信することは、
　第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、前記第１のホストは、前記第１の仮想ルータを集積するための物理マシンであり、前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
　前記第１のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第１のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
　仮想ルータクラスタ。
　　【請求項２】
　前記ゲートウェイが、オープン・ショーテスト・パス・ファーストプロトコルに基づいて前記少なくとも２つの仮想ルータから前記データパケットに対応した第１の仮想ルータを選択することは、
　前記データパケットのアドレス情報を取得するステップと、
　前記データパケットのアドレス情報のハッシュ値に基づいて、前記データパケットに対応した第１の仮想ルータを選択するステップとを含むことを特徴とする
　請求項１に記載の仮想ルータクラスタ。
　　【請求項３】
　
主従関係が無い少なくとも２つの仮想ルータから、
　前記第１の仮想ルータにより宛先ポートへ前記データパケットを転送するステップとを含み、
　前記第１の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するステップは、
　第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、前記第１のホストは、前記第１の仮想ルータを集積するための物理マシンであり、前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
　前記第１のカーネルのうちのいずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第１のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
　データ転送方法。
　　【請求項４】
　前記オープン・ショーテスト・パス・ファーストプロトコルに基いて選択された第１の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信するステップは、
　前記データパケットのアドレス情報のハッシュ値に基いて、前記データパケットに対応した第１の仮想ルータを選択することを含むことを特徴とする
　請求項３に記載の方法。
　　【請求項５】
　
主従関係が無い少なくとも２つの仮想ルータから、
　宛先ポートへ前記データパケットを転送するように構成される転送モジュールとを備え、
　前記第１の仮想ルータにより、ゲートウェイから送信されたデータパケットを受信することは、
　第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、前記第１のホストは、前記第１の仮想ルータを集積するための物理マシンであり、前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップと、
　前記第１のカーネルのうちのいずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第１のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップとを含むことを特徴とする
　データ転送装置。
　　【請求項６】
　前記受信モジュールは、さらに、
　前記データパケットのアドレス情報のハッシュ値に基いて、前記データパケットに対応した第１の仮想ルータを選択するように構成されることを特徴とする
　請求項５に記載の装置。」
　第５　引用文献、引用発明等
１．引用文献１，３−５記載事項、引用発明１について
（１）引用文献１には、次の事項が記載されている。
ア．「【０００５】
これらルータ２０，３０は、故障時の安全対策として、ＯＳＰＦプロトコルの二重化を行う場合がある。この場合には、たとえば図１３に示すように、
物理的には１つのルータ（以下、「物理ルータ」という）２０を、データ中継の動作を行う上で論理的に２つのルータ（以下、「論理ルータ」という）２１，２２に設定し
【０００６】
この論理ルータは、動作がアクティブ状態にあり、メイン処理を行う論理ルータ（以下、「アクティブ側ルータ」という）２１と、動作がスタンバイ状態にあり、バックアップ処理を行う論理ルータ（以下、「スタンバイ側ルータ」という）２２とからなり、各論理ルータ２１，２２を他のルータ３０と接続させ
【０００７】
【非特許文献１】
Ｊｏｈｎ　Ｍｏｙ著、“ＲＦＣ２３２８ 　ＯＳＰＦ　Ｖｅｒｓｉｏｎ２”　［ｏｎｌｉｎｅ］、インターネット公式プロトコル（ＳＴＤ１）、１９９８年４月、ｐ．６−１５、ＡｌｔｅｒＮＩＣ　Ｔｈｅ　Ｎｅｔｗｏｒｋ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｃｅｎｔｅｒ、［平成１５年１月２２日検索］、インターネット＜ＵＲＬ：ＨＹＰＥＲＬＩＮＫ”ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒｎｉｃ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ２３００／ｒｆｃ２３２８．ｈｔｍｌ”＞
【０００８】
【発明が解決しようとする課題】
しかしながら、上記従来例では、他のルータとの経路情報の交換途中で故障が発生してパケットロスがでると、アクティブ側ルータとスタンバイ側ルータが完全に同期できなくなり、上記の状態切り替え時にトポロジー変化に伴う経路情報の受信が不可能となるので、スタンバイ側ルータが初期指定で初期ステートに戻って全体の経路情報を取得するまで、データの中継処理が不可能となり、サービスが停止してしまうという問題点があった。
【０００９】
この発明は、上記問題点に鑑みなされたもので、故障発生時にもトポロジー変化に伴う経路情報の受信を正確に行い、データの中継処理を極力停止させることなく、容易にデータ中継装置の二重化を図ることができるデータ中継方法、データ中継装置およびその装置を用いたデータ中継システムを提供することを目的とする。」
イ．「【００２７】
（実施の形態１）
図１は、この発明にかかるデータ中継システムの概略構成の一例を示すシステム構成図である。図において、この実施の形態の
データ中継システムは
ＡＳ内部の複数のルータ２０，３０がネットワーク１０上に設けられて接続されており、これらルータ２０，３０は、故障時の安全対策として、ＯＳＰＦプロトコルの二重化が行われている
【００２８】
このルータ２０は
データ中継装置
二重化されたＯＳＰＦプロトコルを搭載したアクティブ状態の論理ルータであるアクティブ側ルータ２１と、スタンバイ状態の論理ルータであるスタンバイ側ルータ２２
データ中継を行うために論理的に設けられた論理ルータである仮想ルータ２３
【００２９】
この実施の形態にかかるルータ２０では、図２に示すように、アクティブ側ルータ２１およびスタンバイ側ルータ２２と他のルータ３０間で別々に経路情報の交換を行うことによって経路情報を取得している。なお、
アクティブ側ルータ２１およびスタンバイ側ルータ２２がともに正常に動作している通常状態の場合には、最適経路のネクストホップとしては、アクティブ側ルータ２１が設定されて、相手ルータ３０および仮想ルータ２３の経路情報データベース内に記憶されている
ウ．「【００５０】
このように、この実施の形態では、スタンバイ側ルータ２２も異なるＯＳＰＦ論理ルータとして、アクティブ側ルータ２１とともに動作させ、この
アクティブ側ルータ２１およびスタンバイ側ルータ２２は、仮想ルータ２３を介在させたネットワーク全体のＬＳＡ情報を通知して、自ルータ２０経由で中継されるデータを全て仮想ルータ２３を介して送達可能とする
エ．引用発明１
　したがって、引用文献１には、次の発明（以下、「引用発明１」という。）が記載されている。
「物理的には１つのルータ（以下、「物理ルータ」という）２０を、データ中継の動作を行う上で論理的に２つのルータ（以下、「論理ルータ」という）２１，２２に設定し、
　この論理ルータは、動作がアクティブ状態にあり、メイン処理を行う論理ルータ（以下、「アクティブ側ルータ」という）２１と、動作がスタンバイ状態にあり、バックアップ処理を行う論理ルータ（以下、「スタンバイ側ルータ」という）２２とからなり、
　各論理ルータ２１，２２を他のルータ３０と接続させ、
　このルータ２０は、データ中継装置であり、二重化されたＯＳＰＦプロトコルを搭載したアクティブ状態の論理ルータであるアクティブ側ルータ２１と、スタンバイ状態の論理ルータであるスタンバイ側ルータ２２と、
　データ中継を行うために論理的に設けられた論理ルータである仮想ルータ２３を備え、
　アクティブ側ルータ２１およびスタンバイ側ルータ２２がともに正常に動作している通常状態の場合には、最適経路のネクストホップとしては、アクティブ側ルータ２１が設定されて、相手ルータ３０および仮想ルータ２３の経路情報データベース内に記憶され、
　アクティブ側ルータ２１およびスタンバイ側ルータ２２は、仮想ルータ２３を介在させたネットワーク全体のＬＳＡ情報を通知して、自ルータ２０経由で中継されるデータを全て仮想ルータ２３を介して送達可能とする、
　データ中継装置。」 
（２）引用文献３には、次の事項が記載されている。
「【００１４】
このような、ＩＰフローの制御に関して、帯域の広い経路に、流れている量の多いパケットが割り当られるようにし、ハッシュ演算を行って、負荷の分散を行う技術が、特許文献１に示されている図４は特許文献１に記載された発明の原理説明図であり、図４において、ルータ１−１，１−２間はマルチリンク接続されており、ルータ１−１は、パケットからヘッダ情報を抽出するヘッダ情報抽出部と、ヘッダ情報をキーとしてハッシュ演算するハッシュ演算部と、ハッシュ値に基づき、出力インタフェースを決定する出力インタフェース決定部を備えている。そして、他のルータヘ直接接続されている経路が複数存在するルータに対してルーティングを行う必要があるパケットが入ってきた場合、ヘッダ情報の１つ又は複数を抽出し読み込む。
読み込んだヘッダ情報をキーとしてハッシュ演算を行い、その計算結果であるハッシュ値に対応するインタフェースにパケットを出力する
【００１５】
また、使用されるＬＳＰの平均使用率がバランスするように、ハッシュ演算を行ってＩＰフローの振り分け処理を行う技術が、非特許文献１に示されている非特許文献１に示されている技術を図５を用いて説明する。非特許文献１には、設定されたエンジニアリングルートとデフォルトルート（最初に張られるＬＳＰ）間でトラフィックを均等に分散させるために、ＬＥＲでは、ＩＰフローの振り分けを行う。図５に示すように、
入ってきたＩＰパケットのあて先アドレス、送信元アドレス、送信ポートアドレス、受信ポートアドレス、通信プロトコル等をキーとして、ハッシュ演算
１６を用いている
 
（３）引用文献４には、次の事項が記載されている。
ア．（第４８頁右欄１６行目−第４９頁左欄１４行目、図１）
「ハードとソフトを分離
　ＮＦＶは、ソフトウエア的に見ると主に３つの層から成る。まず、大量のｘ８６サーバー上で、ハードの細かな違いを吸収するサーバー仮想化ソフト「ハイパーバイザー†」を動作させる。これが一番下の層である。次に、このハイパーバイザーが作り出す
仮想のサーバー環境「仮想マシン（ＶＭ）」上で、ＬｉｎｕｘなどのＯＳを「ゲストＯＳ」として動作させる。ＶＭは、１つのサーバー上で複数動作させることができる。ルーターやファイアウォールといった通信機能は、各ＶＭのゲストＯＳ上でアプリケーションとして動作させる。
ア−２．（第５１頁左欄３０行目ー３４行目）
「現在では仮想スイッチや仮想ルータなどＮＦＶ向けソフトの多くに、
ＤＰＤＫ
事実上、ＮＦＶの技術のデファクトスタンダードとなっている
イ．（第５２頁左欄１行目−１１行目）
「しかし、汎用のｘ８６サーバーを通信に特化した形で使うＮＦＶでは、割り込み処理はオーバーヘッドとなる。そこでＤＰＤＫでは、割り込み処理の代わりにポーリング処理を採用した。
ポーリング処理とは、割り込み処理のようなイベント駆動型ではなく、周期的に問い合わせる処理のことだ。受信パケットが来ているかをＮＩＣに一定周期で問い合わせ、パケットが来ていれば即、受信処理を始める。
ウ．（第５２頁中央欄２行目−１０行目）
「実は、ＤＰＤＫのように通信処理をポーリング処理で実装する仕組みは、Ｌｉｎｕｘでは以前からあった。「ＮＡＰＩ（ｎｅｗＡＰＩ）」という仕組みである。ただし、
ＮＡＰＩはＬｉｎｕｘカーネル（カーネル空間）においてポーリング処理を実装していた
ウ−２．（第５２頁中央欄１１行目−右欄１行目）
「
ＤＰＤＫがユーザ空間での実装を選択したのは、ＤＰＤＫ自体の利用のしやすさを考慮したからだ。
カーネル空間向けの開発では、
開発のハードルが高い
ユーザ空間であれば、そうした制限がなく、ＤＰＤＫを使った新たな通信機能の実装は比較的容易である
（５）　引用文献５には、次の事項が記載されている。
ア．「【０００６】
従来例(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アドレスを元にハッシュ値を計算し、この値に対応した送出パスを決定する。
２．引用文献２、６記載事項、引用発明２について
（１）引用文献２には、次の事項が記載されている。
ア．「【０００６】 
　一般的に記述すると、本開示は分散ルーティングアーキテクチャに対応する。具体的には、本開示は、
ネットワーク構成要素間のデータパケットの受信、処理および転送のための少なくとも２つの論理レベルまたは層を含む、階層分散ルーティングアーキテクチャに対応
【０００７】
　一実施形態では、コアレベルおよび分散レベルに関連付けられたルータ構成要素のそれぞれは、商品ベースのルータ構成要素／ハードウェアにより詳しく対応することが可能である。別の実施形態では、
コアレベルおよび分散レベルルータ構成要素は、必ずしも対応するハードウェアルータ構成要素を持たない論理ルータ構成要素に対応
イ．「【００１１】
　
第１の通信ネットワーク１０４と通信しているのは分散ルーティング環境１００の第１のレベルであり、通常コア層またはコアレベルと呼ばれ
コアレベルは、通常コアレベルルータ１０６Ａ、１０６Ｂ、および１０６Ｃと呼ばれる１つまたは複数の論理ルータ構成要素に対応
【００１２】
　
分散ルーティング環境１００は、概して分散層または分散レベルと呼ばれ
分散レベルルータ１０８Ａ、１０８Ｂ、および１０８Ｃは、１つまたは複数のハードウェア構成要素に実行される論理ルータ構成要素に対応
ウ．「【００１９】
　ここで図２Ａ〜図２Ｄを参照すると、分散ルーティング環境１００による受信するパケットの処理が示される。まず図２Ａおよび図２Ｂを参照すると、
着信パケットが通信ネットワーク１０４からコアレベルルータ１０６へ受信され
【００２０】
　
宛先アドレスの第１のサブセットの処理に基づき、コアレベルルータ１０６はパケットを分散レベルルータ、この場合は１０８Ａで示された「分散ルータ１」へ転送
分散レベルルータ１０８Ａはパケットを直接通信ネットワーク１１２へ伝送し
エ．「【００２５】
　なおさらなる実施形態では、複数の分散レベルルータ１０８を、ＩＰアドレスのサブセットに選択してもよい。この実施形態では、それぞれの
コアレベルルータ１０６は、等コストマルチパスルーティング（ＥＣＭＰ）技術に基づき複数の分散レベルルータ１０８から選択することができ、特定の分散レベルルータ１０８が標準負荷分担技術に基づき選択される
オ．引用発明２
　したがって、引用文献２には、次の発明（以下、「引用発明２」という。）が記載されている。
「ネットワーク構成要素間のデータパケットの受信、処理および転送のための少なくとも２つの論理レベルまたは層を含む、階層分散ルーティングアーキテクチャに対応し、
　コアレベルおよび分散レベルルータ構成要素は、必ずしも対応するハードウェアルータ構成要素を持たない論理ルータ構成要素に対応し、
　第１の通信ネットワーク１０４と通信しているのは分散ルーティング環境１００の第１のレベルであり、通常コア層またはコアレベルと呼ばれ、
　コアレベルは、通常コアレベルルータ１０６Ａ、１０６Ｂ、および１０６Ｃと呼ばれる１つまたは複数の論理ルータ構成要素に対応し、
　分散ルーティング環境１００は、概して分散層または分散レベルと呼ばれ、
　分散レベルルータ１０８Ａ、１０８Ｂ、および１０８Ｃは、１つまたは複数のハードウェア構成要素に実行される論理ルータ構成要素に対応し、
　着信パケットが通信ネットワーク１０４からコアレベルルータ１０６へ受信され、
　宛先アドレスの第１のサブセットの処理に基づき、コアレベルルータ１０６はパケットを分散レベルルータ、この場合は１０８Ａで示された「分散ルータ１」へ転送し、
　分散レベルルータ１０８Ａはパケットを直接通信ネットワーク１１２へ伝送し、
　コアレベルルータ１０６は、等コストマルチパスルーティング（ＥＣＭＰ）技術に基づき複数の分散レベルルータ１０８から選択することができ、特定の分散レベルルータ１０８が標準負荷分担技術に基づき選択される、
　階層分散ルーティングアーキテクチャ。」
（２）引用文献６には、次の事項が記載されている。
ア．「【０００４】
　
ＯＳＰＦにおいてはＥＣＭＰ
機能
を有しており、多くの場合ＥＣＭＰ機能は有効化されている。」
第６　対比・判断
１．本願発明１について
（１）引用発明１を主引用発明とする理由について
（１−１）対比
　本願発明１と引用発明１とを対比する。
ア．引用発明１の「仮想ルータ２３」は、ネットワーク１０と、アクティブ側ルータ２１との間で、データ中継を行っていることから、本願発明１の「外部機器から転送されたデータパケットを受信」する「ゲートウェイ」に相当する。
イ．引用発明１の「アクティブ側ルータ２１」と「スタンバイ側ルータ２２」とは、１つの物理ルータ２０において、データ中継の動作を行う上で論理的に２つのルータとして設定され、「仮想ルータ２３」と互いに接続していることから、本願発明１の「前記ゲートウェイと相互接続する少なくとも２つの仮想ルータ」に相当する。
 
ウ．引用発明１において、「二重化されたＯＳＰＦプロトコル」に基づいて、「アクティブ側ルータ２１およびスタンバイ側ルータ２２」から、「ネクストホップとしては、アクティブ側ルータ２１」を設定することは、本願発明１の「前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、
主従関係が無い
エ．引用発明１において、「アクティブ側ルータ２１およびスタンバイ側ルータ２２は、自ルータ２０経由で中継されるデータを全て仮想ルータ２３を介して送達」することは、本願発明１の「ゲートウェイ」が、「前記データパケットを、該データパケットに対応した前記第１の仮想ルータへ転送」する点、及び、本願発明１の「前記第１の仮想ルータが前記データパケットを受信する」点で共通するといえる。
オ．引用発明１における、「物理ルータ」は、「論理的に２つのルータ（以下、「論理ルータ」という）２１，２２」を設定し、データ中継を行っていることから、本願発明１の「
第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、
り、前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルであ
カ．引用発明１における、「データ中継装置」は、「アクティブ側ルータ２１」と、「スタンバイ側ルータ２２」と、「仮想ルータ２３」を備えていることから、本願発明１の「仮想ルータクラスタ」に相当する。
　したがって、本願発明１と引用発明１の一致点及び相違点は、次のとおりである。
［一致点]
「ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも２つの仮想ルータを備え、
　前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
　前記ゲートウェイは、さらに、オープン・ショーテスト・パス・ファーストプロトコルに基づいて、前記少なくとも２つの仮想ルータから、前記データパケットに対応した第１の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第１の仮想ルータへ転送し、
　前記第１の仮想ルータが前記データパケットを受信することは、
　前記第１のホストは、前記第１の仮想ルータを集積するための物理マシンである、ステップとを含むことを特徴とする
　仮想ルータクラスタ。」
［相違点１］
　本願発明１は、「
主従関係が無い
[相違点２]
　本願発明１は、「前記第１の仮想ルータは、前記データパケットを受信して宛先ポートへ転送し」ているのに対し、引用発明１には、「宛先ポート」へ転送しているか特定されていない点。
[相違点３]
　本願発明１は、「前記第１の仮想ルータが前記データパケットを受信すること」に、「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、」「前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」が含まれているのに対し、引用発明１には、「アクティブ側ルータ２１」及び「スタンバイ側ルータ２２」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。
[相違点４]
　本願発明１は、「前記第１の仮想ルータが前記データパケットを受信すること」に、「前記第１のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第１のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップ」が含まれているのに対し、引用発明１には、「アクティブ側ルータ２１」及び「スタンバイ側ルータ２２」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。
（１−２）．相違点についての判断
　事案に鑑みて先ず相違点１について検討する。
　引用発明１は、「アクティブ側ルータとスタンバイ側ルータと」から仮想ルータを選択するものであり、両者は、メイン処理とバックアップ処理という、主従の関係にある仮想ルータであると認められる。
　よって、引用発明１は、相違点１にかかる「主従関係がない前記少なくとも２つの仮想ルータ」から「第１の仮想ルータを選択する」なる構成と真逆の構成を示すものであり、当該構成を変更するための阻害要因があるというべきである。
　また、上記「第５」の「１．（１）ア．」を参照すると、引用文献１は、アクティブ側ルータとスタイバイ側ルータの両方を用いるシステムにおいて、故障発生時にもトポロジー変化に伴う経路情報の受信を正確に行うことを行うことを課題としており、当該課題を解決するための構成であるアクティブ側ルータ及びスタンバイ側ルータの両方を用いること、すなわち、主従の関係にある仮想ルータから（第１の）仮想ルータを選択することを変更する起因はないものと認められる。また、引用文献１の明細書及び図面における他の記載において、相違点１に係る構成を導くための記載や示唆もない。
　したがって、他の相違点を検討するまでもなく、本願発明１は、当業者であっても、引用発明１及び引用文献３−５記載の技術的事項に基づいて容易に発明をすることができたとはいえない。
（２）引用発明２を主引用発明とする理由について
（２−１）対比
　本願発明１と引用発明２とを対比する。
ア．引用発明２の「コアレベルルータ１０６」は、外部の「通信ネットワーク１０４から」パケットを着信し、「分散レベルルータ１０８Ａ」へパケットを転送していることから、本願発明１の「外部機器から転送されたデータパケットを受信」する「ゲートウェイ」に相当する。
イ．引用発明２の「分散レベルルータ１０８Ａ、１０８Ｂ、および１０８Ｃ」は、「コアレベルルータ１０６」からパケットを着信していることから、本願発明１の「ゲートウェイと相互接続する少なくとも２つの仮想ルータ」に相当する。
 
ウ．引用発明２において、「宛先アドレスの第１のサブセットの処理に基づき、コアレベルルータ１０６はパケットを分散レベルルータ、この場合は１０８Ａで示された「分散ルータ１」へ転送」することは、本願発明１の「前記ゲートウェイは、さらに、
オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係のない
エ．引用発明２において、「分散レベルルータ１０８Ａはパケットを直接通信ネットワーク１１２へ伝送」することは、本願発明１の「前記第１の仮想ルータは、前記データパケットを受信して宛先
ポート
オ．引用発明２における「ハードウェア構成要素」は、「論理ルータ構成要素」を「実行」していることから、本願発明１の「
第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、
り、前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルであ
カ．引用発明２における「階層分散ルーティングアーキテクチャ」は、「ネットワーク構成要素間のデータパケットの受信、処理および転送のため」に「２つの論理レベル」として「コアレベルルータ１０６」と「分散レベルルータ１０８Ａ」を備えていることから、本願発明１の「仮想ルータクラスタ」に相当する。
　したがって、本願発明１と引用発明２との一致点及び相違点は、次のとおりである。
[一致点]
「ゲートウェイ、および前記ゲートウェイと相互接続する少なくとも２つの仮想ルータを備え、
　前記ゲートウェイは、外部機器から転送されたデータパケットを受信し、
　前記ゲートウェイは、さらに、前記少なくとも２つの仮想ルータから、前記データパケットに対応した第１の仮想ルータを選択し、且つ前記データパケットを、該データパケットに対応した前記第１の仮想ルータへ転送し、
　前記第１の仮想ルータは、前記データパケットを受信して宛先へ転送し、
　前記第１の仮想ルータが前記データパケットを受信することは、
　前記第１のホストは、前記第１の仮想ルータを集積するための物理マシンである、ステップとを含むことを特徴とする
　仮想ルータクラスタ。」
[相違点５]
　本願発明１は、「オープン・ショーテスト・パス・ファーストプロトコルに基づいて、主従関係のない」第１の仮想ルータを選択しているのに対し、引用発明２は、「宛先アドレスの第１のサブセットの処理」や「等コストマルチパスルーティング（ＥＣＭＰ）技術」に基づいて「分散レベルルータ」を選択しており、オープン・ショーテスト・パス・ファーストプロトコルを用いていること、主従関係のない仮想ルータが選択されていることが特定されていない点。
[相違点６]
　本願発明１は、第１の仮想ルータが、受信したデータパケットを「宛先ポートへ」転送しているのに対し、引用発明２には、「宛先ポートへ」転送しているか特定されていない点。
[相違点７]
　本願発明１は、「前記第１の仮想ルータが前記データパケットを受信すること」に、「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングするステップであって、」「前記第１のカーネルは、前記第１のホストにおいて前記第１の仮想ルータによって独占される、データパケットの処理動作を行うためのカーネルである、ステップ」が含まれているのに対し、引用発明２には、「アクティブ側ルータ２１」及び「スタンバイ側ルータ２２」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。
[相違点８]
　本願発明１は、「前記第１の仮想ルータが前記データパケットを受信すること」に、「前記第１のカーネルのうちの、いずれかのカーネルが前記ネットワークインターフェースをアクセスする期間中に、前記ネットワークインターフェースが前記ゲートウェイから送信された前記データパケットを受信すると、前記第１のカーネルのうちの、前記ネットワークインターフェースをアクセスしている前記いずれかのカーネルが前記データパケットを取得するステップ」が含まれているのに対し、引用発明２には、「アクティブ側ルータ２１」及び「スタンバイ側ルータ２２」がパケットを受信することに、そのような「ステップ」が含まれていることが、特定されていない点。
（２−２）．相違点についての判断
　事案に鑑みて、先ず相違点７について検討する。
　上記「第５」の「１．（３）ア、イ」を参照すると、各仮想マシンのゲストＯＳ上でアプリケーションとして、動作する通信機能がポーリング処理を行う技術が記載されている。
　また、上記「第５」の「１．（３）ウ」を参照すると、引用文献４には、「Ｌｉｎｕｘカーネル（カーネル空間）においてポーリング処理」を行う技術が記載されている。
　しかしながら、当該ポーリング処理が仮想マシン上の、Ｌｉｎｕｘカーネル（カーネル空間）において行われることは記載されておらず、当該記載から自明であるともいえない。
　したがって、引用文献４には、本願発明１の「前記第１の仮想ルータが前記データパケットを受信すること」において「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングする」構成を備えることは、開示されておらず、本願優先日前において周知技術であったとも認められない。
　そして、仮に、「前記第１の仮想ルータが前記データパケットを受信すること」において「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングする」構成を備えること（ポーリング処理が仮想マシン上の、Ｌｉｎｕｘカーネル（カーネル空間）において行われること）が、上記記載から自明であるか、本願優先日前において周知技術であったとしても、上記「１．（３）アー２、ウ−２」を参照すると、（ユーザ空間においてポーリングを実装する）ＤＰＤＫがデファクトスタンダードとなっており、カーネル空間向けの開発がハードルが高いとの記載がある。
　よって、引用発明２において、ポーリングを実装する際に、デファクトスタンダードであり、開発の比較的容易な、ユーザ空間においてポーリングを実装するＤＰＤＫではなく、開発のハードルが高く、デファクトスタンダードでもない、仮想マシン上の、Ｌｉｎｕｘカーネル（カーネル空間）においてポーリング処理を行う技術をあえて採用する起因はないものと認められる。
　したがって、他の相違点を検討するまでもなく、引用発明２及び引用文献３−６に記載された技術的事項に基いて当業者が容易に発明できたものであるとはいえない。
（３）小括
　（１）、（２）における検討のとおり、本願発明１は、引用文献１−６に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。
２．本願発明３，５について
　本願発明３，５は、それぞれ、本願発明１に対応する、転送方法の発明と、データ転送装置の発明であり、本願発明１の「主従関係がない前記少なくと２つの仮想ルータ」から「第１の仮想ルータを選択する」構成及び「前記第１の仮想ルータが前記データパケットを受信すること」において「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングする」構成を備えることと同様の構成を備えているものであるから、本願発明１と同じ理由により、引用文献１−６に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。
３．本願発明２，４，６について
　本願発明２，４，６は、本願発明１，３，５を減縮した発明であるから、本願発明１と同様の理由により、引用文献１−６に記載された発明に基いて当業者が容易に発明できたものであるとはいえない。
第７　原査定についての判断
　令和２年２年１０月５日の補正により、補正後の請求項１−６に係る発明は、「主従関係がない前記少なくと２つの仮想ルータ」から「第１の仮想ルータを選択する」構成及び「前記第１の仮想ルータが前記データパケットを受信すること」において「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングする」構成を備えることを有するものとなった。
　そして、当該「主従関係がない前記少なくとも２つの仮想ルータ」から「第１の仮想ルータを選択する」構成及び「前記第１の仮想ルータが前記データパケットを受信すること」において「第１のカーネルが所定の時間間隔で第１のホストのネットワークインターフェースをポーリングする」構成を備えることとは、原査定において引用された文献Ａ−Ｅのいずれにも記載されておらず、本願優先日前におけて周知技術であったとも認められない。
　したがって、本願発明１−６は、当業者であっても、引用発明Ａ−Ｅ記載の技術的事項に基づいて容易に発明をすることができたとはいえない。
第８　むすび
　以上のとおり、原査定の理由によって、本願発明を拒絶することはできない。
　他に本願発明を拒絶すべき理由を発見しない。
　したがって、結論のとおり審決する。