【事件の表示】
　特願２０１４−　４３１３４「情報システム，制御サーバ，仮想ネットワーク管理方法およびプログラム」拒絶査定不服審判事件〔平成２６年　７月１０日出願公開，特開２０１４−１３１３４７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２０１０年（平成２２年）１０月７日（国内優先権主張　平成２１年１０月７日）を国際出願日とする出願である特願２０１１−５３５４４９号の一部を，平成２６年３月５日に新たな特許出願としたものであって，平成２６年１１月２８日付けで拒絶理由が通知され，平成２７年２月２日付けで手続補正がされ，同年４月２３日付けで拒絶理由が通知され，同年７月７日付けで手続補正がされ，同年９月１１日付けで最後の拒絶理由が通知され，同年１１月３０日付けで手続補正がされたが，同年１２月１５日付けで補正の却下の決定がされ，同日付けで拒絶査定がされ，これに対し，平成２８年３月２２日に拒絶査定不服審判が請求され，同時に手続補正がされたものである。
第２　補正の却下の決定
［結論］
　平成２８年３月２２日付けの手続補正を却下する。
［理由］
１　本願発明と補正後の発明
　平成２８年３月２２日付けの手続補正（以下，「本件補正」という。）は，平成２７年７月７日付けの手続補正により補正された特許請求の範囲の請求項１に記載された
「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと，当該仮想ネットワークのユーザに対応するパケットの識別条件とを設定可能な第一の手段と，
　前記複数の通信機能の各々に対応するパケット処理を，前記識別条件に対応するパケットに対して実行することを，前記複数の仮想ノードを構成する物理ノードに指示する第二の手段と
　を含む制御装置。」（以下，「本願発明」という。）
を，
「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと，当該仮想ネットワークのユーザに対応するパケットの識別条件とを設定可能な第一の手段と，
　前記複数の通信機能の各々に対応するパケット処理
のうち受信パケットに対するパケット処理
当該受信
のうち，当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノード
　を含む制御装置。」（以下，「補正後の発明」という。）
に変更することを含むものである。（［当審注］：下線部は補正箇所を示す。）
２　補正の適否
（１）新規事項の有無，シフト補正の有無，補正の目的要件
　請求項１についての上記補正は，本件補正前の「パケット処理を，前記識別条件に対応するパケットに対して実行する」を，「パケット処理
のうち受信パケットに対するパケット処理
当該受信
のうち，当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノード
　独立請求項である請求項３，５，７〜１２についての補正も，請求項１についての上記補正と同様である。
　そして，これらの補正は，特許法第１７条の２第３項，第４項に違反するところはない。
（２）独立特許要件
　請求項１についての上記補正は，特許請求の範囲の減縮を目的とするものであるから，本件補正後の請求項１に係る発明が特許出願の際独立して特許を受けることができるものであるのか否かについて，以下検討する。
ア　補正後の発明
　補正後の発明は，上記「１　本願発明と補正後の発明」の項の「補正後の発明」のとおりのものと認める。
イ　引用発明等
［引用発明］
　原査定の拒絶の理由に引用されたSaurav Das et al.，Simple Unified Control for Packet and Circuit Networks（［当審仮訳］：パケット及び回線ネットワークのための簡単な統一された制御），IEEE/LEOS Summer Topical Meeting, 2009 (LEOSST '09)，pp.147-148，２００９年７月，IEEE，URL: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5226211（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。
（ア）「
」（１４７ページ左欄下から９行〜右欄３行）
（［当審仮訳］：
ＯｐｅｎＦｌｏｗ
　基本的な考え方は簡単である：ＯｐｅｎＦｌｏｗは，内部フローテーブルとフローテーブルエントリ（図１）を追加／編集／削除するための標準化されたインタフェースとを備えたパケットスイッチに基づいている。それは，最新のスイッチング機器には，回線速度で動作し，入来トラフィックを発信ポートにマッピングするテーブルが含まれているという事実を利用している。各ベンダーの機器は様々であるが，ＯｐｅｎＦｌｏｗは全てのスイッチに実装されている共通の機能セットを利用している。更に，オープンに標準化されたインタフェイス（ＯｐｅｎＦｌｏｗプロトコル）は，スイッチの制御を箱の外に出し，ネットワークオペレータの制御下にあるコントローラに配置する。
（図１は省略）　）
（イ）「
」（１４７ページ右欄４〜１０行）
（［当審仮訳］：
　ＯｐｅｎＦｌｏｗは完全に後方互換性がある。ＯｐｅｎＦｌｏｗスイッチのデータパスは，ヘッダにおいてまさにフローを構成しているものを識別するエントリに加えて，そのようなフローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルで構成される。ＯｐｅｎＦｌｏｗスイッチは，ＩＰルータ，イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる。）
（ウ）「
（中略）
」（１４８ページ右欄２８〜３８行，４５〜４８行）
（［当審仮訳］：
　研究コミュニティは，ネットワークの彼らの「スライス」を実験することで，新しいアイデアを大規模に試すことができれば，恩恵を受けることができる。このようなスライスは，ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化によって使用可能にすることができる。このような分割化／仮想化は，コンピュータ内のオペレーティングシステムがユーザ空間とカーネル空間とを分割するのと丁度同じように，コントローラ内で実施され得る。うまくいけば，プロダクションスライスに導入する前に新しいアイデアをネットワークの１つのスライスで徹底的にテストすることができ，研究から産業への技術移転となる（そのようなものは現在殆ど存在していない）。
（中略）
参考文献
[1]（文献名については省略。）
[2]（文献名については省略。）　）
　引用例の上記各記載及び各図面並びに当該技術分野の技術常識を考慮すると， 
　上記（ア）の記載によれば，ＯｐｅｎＦｌｏｗは，標準化されたインタフェース（ＯｐｅｎＦｌｏｗプロトコル）により，スイッチの制御をスイッチの外のコントローラにて行うものである。図１を見ると，ＯｐｅｎＦｌｏｗスイッチとコントローラがセキュアチャネルでＯｐｅｎＦｌｏｗプロトコルにより通信すること，ＯｐｅｎＦｌｏｗスイッチがフローテーブルを持つことが見てとれる。そして，標準化されたインタフェース（ＯｐｅｎＦｌｏｗプロトコル）は，ＯｐｅｎＦｌｏｗスイッチのフローテーブルエントリを追加／編集／削除するためのものである。したがって，コントローラは，「標準化されたインタフェースを通じてＯｐｅｎＦｌｏｗスイッチのフローテーブルエントリを追加／編集／削除するよう，ＯｐｅｎＦｌｏｗスイッチを制御する」といえる。
　また，上記（イ）の記載によれば，標準化されたインタフェース（ＯｐｅｎＦｌｏｗプロトコル）を備えたＯｐｅｎＦｌｏｗスイッチは，フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し，ＩＰルータ，イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できるものである。したがって，ＯｐｅｎＦｌｏｗスイッチは，「フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し，ＩＰルータ，イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる」といえる。
　また，上記（ウ）の記載によれば，ネットワークのスライスは，ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化によって使用可能にすることができ，仮想化はコントローラ内で実施され得るものである。したがって，コントローラは，「コントローラ内で，ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより，ネットワークのスライスを使用可能にすることができるものである」といえる。
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認める。
「コントローラ内で，ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより，ネットワークのスライスを使用可能とし，
　標準化されたインタフェースを通じてＯｐｅｎＦｌｏｗスイッチのフローテーブルエントリを追加／編集／削除するよう，ＯｐｅｎＦｌｏｗスイッチを制御する，
　　ここで，前記ＯｐｅｎＦｌｏｗスイッチは，フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し，ＩＰルータ，イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる，
　コントローラ。」
［周知技術］
　引用例に参考文献（References[1]）として引用され，本願明細書において背景技術を示す「【非特許文献１】」とされている，Nick McKeown外７名，“OpenFlow: Enabling Innovation in Campus Networks”（［当審仮訳］：キャンパスネットワークにおけるイノベーションの実現），２００年３月１４日，〈URL：http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉（以下，「周知例１」という。）には，図面とともに以下の事項が記載されている。
（エ）「
」（２葉目右欄４行〜３葉目左欄１３行）
（［当審仮訳］：
２．ＯｐｅｎＦｌｏｗスイッチ
　基本的な考え方は簡単である：最新のイーサネットスイッチ及びルータの殆どは，ファイアウォール，ＮＡＴ，ＱｏＳを実装し，統計情報を収集するために，回線速度で動作するフローテーブル（通常はＴＣＡＭｓで構築されている）を使用している。各ベンダーのフローテーブルは様々であるが，多くのスイッチやルータで実行される関心のある共通の機能セットを特定している。ＯｐｅｎＦｌｏｗは，この共通の機能を利用している。
　ＯｐｅｎＦｌｏｗは，様々なスイッチやルータのフローテーブルをプログラムするオープンプロトコルを提供する。ネットワーク管理者は，トラフィックを製品フローとリサーチフローとに分割できる。研究者は，彼らのパケットが従う経路及び受信した処理を選択することにより，彼ら独自のフローを制御できる。このようにして，研究者は，新しいルーティングプロトコル，セキュリティモデル，アドレス指定スキーム，更にはＩＰの代替手段を試すことができる。同じネットワーク上で，製品トラフィックは，分離され，現在と同じ方法で処理される。
　ＯｐｅｎＦｌｏｗスイッチのデータパスは，フローテーブルと，各フローエントリに関連付けられたアクションで構成される。ＯｐｅｎＦｌｏｗスイッチによりサポートされるアクションのセットは拡張可能であるが，以下では全てのスイッチについての最小要件について説明する。高性能で低コストであるためには，データパスは慎重に規定された程度の柔軟性を備えていなければならない。これは，各パケットの任意の処理を指定する能力を控え，より限定された，しかし依然として有用なアクションの範囲を探すことを意味する。したがって，本書の後半では，全てのＯｐｅｎＦｌｏｗスイッチについての基本的な必要とされるアクションセットを定義する。
　ＯｐｅｎＦｌｏｗスイッチは，少なくとも次の３つの部分からなる。：(1) 各フローエントリに関連付けられたアクションを有し，フローにどのように処理するかをスイッチに指示する，フローテーブル，(2) スイッチをリモート制御プロセス（コントローラと呼ばれる）に接続し，コントローラと使用するスイッチ間でコマンドとパケットを送信できるようにする，セキュアチャネル，(3) コントローラがスイッチと通信するためのオープンで標準的な方法を提供する，ＯｐｅｎＦｌｏｗプロトコル。フローテーブルのエントリを外部で定義できる標準インタフェース（ＯｐｅｎＦｌｏｗプロトコル）を指定することにより，ＯｐｅｎＦｌｏｗスイッチは研究者がスイッチをプログラムする必要性を回避する。
　スイッチを，通常のレイヤ２及びレイヤ３処理をサポートしない専用のＯｐｅｎＦｌｏｗスイッチと，ＯｐｅｎＦｌｏｗプロトコルとインタフェースが新たな機能として追加された，ＯｐｅｎＦｌｏｗが可能な汎用の市販イーサネットスイッチ及びルータとに分類することは有用である。）
（オ）「
（中略）
」（３葉目左欄下から１７行〜３行，６葉目右欄下から１１行〜１０行）
（［当審仮訳］：
　フローテーブルのエントリは，次の３つのフィールドを有している。(1) フローを定義するパケットヘッダ，(2) パケットの処理方法を定義するアクション，(3) 各フローのパケット数やバイト数及び（非アクティブフローの削除を支援するため）最後のパケットがフローに一致してからの時間の情報をずっと得る，統計情報。
　第１世代「タイプ０」スイッチでは，フローヘッダは表１に示す１０タプルである。ＴＣＰフローは１０個のフィールド全てで指定できるが，ＩＰフローには定義内にトランスポート・ポートが含まれていない可能性がある。ＶＬＡＮ　ＩＤだけが定義されたフローが特定のＶＬＡＮ上の全てのトラフィックに適用されるように，各ヘッダーフィールドはフローの集約を可能にするワイルドカードとなることができる。
　ＯｐｅｎＦｌｏｗスイッチの詳細な要件は，OpenFlow Switch Specification [6]で定義されている。
（中略）
[6]（文献名は省略。）　）
（カ）「
」（３葉目右欄下から１７行〜５行）
（［当審仮訳］：
コントローラ。
　コントローラは，実験のためにフローテーブルからフローエントリを追加及び削除する。例えば，静的コントローラは，実験期間中，テストコンピュータのセットを相互接続するフローを静的に確立するために，ＰＣ上で実行される単純なアプリケーションであってもよい。この場合，フローは，現在のネットワークにおけるＶＬＡＮに似ており，製品ネットワークから実験トラフィックを分離する簡単なメカニズムを提供する。このように，ＯｐｅｎＦｌｏｗはＶＬＡＮの一般化である。）
（キ）「
」（４葉目左欄５行〜２５行）
（［当審仮訳］：
３．ＯｐｅｎＦｌｏｗの使用
　ＯｐｅｎＦｌｏｗスイッチの使い方の簡単な例として，Ａｍｙ（研究者）がＯＳＰＦ（［当審注］：Open shortest Path First）に置き換える新しいルーティングプロトコルとしてＡｍｙ−ＯＳＰＦを発明したとする。彼女はエンドホストのソフトウェアを変更することなく，ＯｐｅｎＦｌｏｗスイッチのネットワークで彼女のプロトコルを試してみたいと思っている。Ａｍｙ−ＯＳＰＦはコントローラで動作し，新しいアプリケーションフローが開始するたびに，Ａｍｙ−ＯＳＰＦは一連のＯｐｅｎＦｌｏｗスイッチを通してルートを選択し，パスに沿う各スイッチにフローエントリを追加する。彼女の実験では，Ａｍｙは自分のデスクトップＰＣからＯｐｅｎＦｌｏｗネットワークに入るトラフィックに対してＡｍｙ−ＯＳＰＦを使用すると決めたので，他の人のネットワークを混乱させることはない。これを行うために，彼女は自分のＰＣが接続されているスイッチポートを介してＯｐｅｎＦｌｏｗスイッチに入る全てのトラフィックを１つのフローとして定義し，「全てのパケットをカプセル化してコントローラに転送する」というアクションを持つフローエントリを追加する。パケットがコントローラに到達すると，新しいプロトコルがルートを選択し，選択したパスに沿う全てのスイッチに新しいフローエントリ（アプリケーションフロー用）を追加する。後続のパケットがスイッチに到着すると，それらはフローテーブルによって迅速に（及び回線速度で）処理される。）
（ク）「
」
（［当審仮訳］：
３．２　更なる例
（中略）
例２：ＶＬＡＮｓ
　ＯｐｅｎＦｌｏｗは，ＶＬＡＮと同様に，ユーザに独自の隔離されたネットワークを簡単に提供できる。最も簡単な方法は，所与のＶＬＡＮ　ＩＤ上のトラフィックがアクセス可能なポートを指定するフローのセットを静的に宣言することである。（例えば，特定のスイッチポート又はＭＡＣアドレスから発信された）単一ユーザから入来したと識別されたトラフィックは，スイッチによって（アクションを介して）適切なＶＬＡＮ　ＩＤがタグ付けされる。
　より動的な方法は，ユーザの資格検証の管理にコントローラを用い，回線速度のタグ付けされたトラフィックのためにユーザの一の知識を用いることができる。）
　原査定の拒絶の理由に引用されたNick McKeown，Software-defined Networking，２００９年４月，URL: http://www.cs.rutgers.edu/~badri/552dir/papers/intro/nick09.pdf（以下，「周知例２」という。）には，以下の図面が記載されている。
（ケ）「
」（４８〜５６番目のスライド）
　引用例に参考文献（References[2]）として引用され，周知例１に参考文献（References[6]）として引用された技術仕様OpenFlow Switch Specificationであって，本件の最先の優先日前に公知となった技術仕様であるOpenFlow Switch Specification Version0.9.0(Wire Protocol 0x98)，２００９年７月２０日，URL: http://archive.openflow.org/documents/openflow-spec-v0.9.0.pdf（以下，「周知例３」という。）には，以下の事項が記載されている。
（コ）「
（中略）
（中略）
（中略）
（中略）
（中略）
（中略）
（中略）
（中略）
」（１〜３，４，５，７，９，１０ページ）
（［当審仮訳］：
２　スイッチ部品
　ＯｐｅｎＦｌｏｗスイッチは，パケットルックアップとフォワーディングを実行するフローテーブルと，外部コントローラ（図１）へのセキュアなチャネルで構成される。コントローラは，ＯｐｅｎＦｌｏｗプロトコルを使用して安全なチャネルを介してスイッチを管理する。
　フローテーブルには，フローエントリ（パケットと一致するヘッダ値）のセット，アクティビティカウンタ及び一致するパケットに適用する０個以上のアクションのセットが含まれている。スイッチによって処理された全てのパケットは，フローテーブルと比較される。一致するエントリが見つかった場合，そのエントリに対する任意のアクションがパケットに対して実行される（例えば，アクションは特定のポートからパケットを転送することである）。一致するものが見つからない場合，パケットは安全なチャネルを介してコントローラに転送される。コントローラは，有効なフローエントリのないパケットの処理方法を決定し，フローエントリを追加及び削除してスイッチフローテーブルを管理する。
（図１は省略）
３　フローテーブル
　この節では，フローテーブルエントリのコンポーネントと，入来パケットがフローテーブルのエントリと照合されるプロセスについて説明する。
（表１は省略）
　各フローテーブルエントリ（表１参照）には，次のものが含まる。
　 ・パケットと一致するヘッダフィールド
 　・一致するパケットを更新するカウンタ
 　・一致するパケットに適用するアクション
３．１　ヘッダフィールド
（表２は省略）
　表２は，入来パケットが比較されるヘッダフィールドを示す。各エントリには，任意の値に一致する特定の値又はＡＮＹが含まれる。スイッチがＩＰソース及び／又は宛先フィールドでサブネットマスクをサポートしている場合，これらはより正確に一致を指定できる。ＯｐｅｎＦｌｏｗの１１タプルのフィールドを表２に，各フィールドのプロパティの詳細を表３に示す。
（中略）
３．３　アクション
　各フローエントリは，スイッチが一致するパケットをどのように処理するかを指示するゼロ以上のアクションに関連付けられている。アクションは，フローエントリで指定された順序で実行する必要はない。アクションが存在しない場合，パケットは廃棄される。
（中略）
必要なアクション：転送。ＯｐｅｎＦｌｏｗスイッチは，パケットを物理ポート及び次の仮想ポートに転送する機能をサポートしている必要がある。
（中略）
オプションのアクション：転送。スイッチは，オプションで次の仮想ポートをサポートする。
（中略）
必要なアクション：廃棄。指定されたアクションのないフローエントリは，一致する全てのパケットを破棄する必要があることを示す。
オプションのアクション：フィールドの変更。厳密には必要とされていないが，表５に示すアクションは，ＯｐｅｎＦｌｏｗ実装の有用性を大幅に高める。既存のネットワークとの統合を支援するために，ＶＬＡＮ変更アクションをサポートすることを提案する。
（中略）
４．１　ＯｐｅｎＦｌｏｗプロトコルの概要
　ＯｐｅｎＦｌｏｗプロトコルは，それぞれが複数のサブタイプを持つ，コントローラからスイッチ，非同期及び対称の３つのメッセージタイプをサポートする。コントローラからスイッチへのメッセージは，コントローラによって開始され，スイッチの状態を直接管理又は検査するために使用される。非同期メッセージは，スイッチによって開始され，ネットワークイベントのコントローラ及びスイッチ状態の変更を更新するために使用される。対称メッセージは，スイッチ又はコントローラのいずれかによって開始され，懇願なしに送信される。ＯｐｅｎＦｌｏｗで使用されるメッセージの種類は以下のとおり。
（中略）
Ｐａｃｋｅｔ−ｉｎ：一致するフローエントリを持たない全てのパケットについて，パケットインイベントがコントローラに送信される（又はパケットが「コントローラへ送信」アクションを持つエントリと一致する場合）。コントローラに送信されたパケットをバッファするために十分なメモリがスイッチが有している場合，パケットインイベントには，パケットヘッダの一部（デフォルトでは１２８バイト）と，スイッチにパケットを送信するよう準備させるときにコントローラによって使用されるバッファＩＤが含まれる。スイッチを切り替えてパケットを転送します。内部にバッファを持たない（又は内部のバッファが使い果たされている）スイッチは，イベントの一部として，全てのパケットをコントローラに送信する必要がある。）
　上記（エ）〜（コ）の記載によれば，本件の優先日前に以下の事項は技術常識ともいえる周知事項であると認められる。
「ＯｐｅｎＦｌｏｗという技術の規格化が進められており，ＯｐｅｎＦｌｏｗは，通信をフローとして捉え，フロー単位で経路制御等を行うものである。転送ノードとして機能するＯｐｅｎＦｌｏｗスイッチは，ＯｐｅｎＦｌｏｗプロトコルに従ってＯｐｅｎＦｌｏｗコントローラにより追加・更新されるフローテーブルに従って動作する。フローテーブルには，パケットを特定するパケットマッチングルールと，特定のポートに出力する，廃棄する，ヘッダを書き換えるといったアクションの組がフローエントリとして登録される。フローエントリにより，ＯｐｅｎＦｌｏｗスイッチは，スイッチング，ファイアフォール，ＶＬＡＮ等として機能し得る。ＯｐｅｎＦｌｏｗスイッチは，該当するフローエントリがあった場合，フローエントリに記載されたアクションに従って受信パケットの処理を行い，該当フローエントリがない場合は，ＯｐｅｎＦｌｏｗプロトコルのＰａｃｋｅｔ−ｉｎによりコントローラに通知する。通知を受けたコントローラは，該当フローエントリのないパケットの処理方法を決定し，関連するＯｐｅｎＦｌｏｗスイッチのフローテーブルにフローエントリの追加等を指示する。」（以下，「周知事項１」という。），
「ＯｐｅｎＦｌｏｗでは，ネットワークは，フローテーブルにより，例えば各研究者毎のＶＬＡＮとして分割化することができる。」（以下，「周知事項２」という。），
「ＯｐｅｎＦｌｏｗは，ヘッダフィールドにＶＬＡＮ　ＩＤを備え，ＶＬＡＮと同様に，ユーザに独自の隔離されたネットワークを簡単に提供できる。」（以下，「周知事項３」という。）
ウ　対比・判断
　補正後の発明と引用発明とを対比すると，
（ア）本願明細書の【０００６】，【００１８】，【００２０】，【００２２】，【００２３】等によれば，補正後の発明の「制御装置」は，「【非特許文献１】」に開示された，「ＯｐｅｎＦｌｏｗコントローラ」を含むことは明らかである。
　一方，引用発明の「コントローラ」は，ＯｐｅｎＦｌｏｗに関するコントローラであり，引用例の参考文献（References）として，上記「【非特許文献１】」と同一の文献（周知例１）が挙げられていることから，「【非特許文献１】」（周知例１）に開示された，「ＯｐｅｎＦｌｏｗコントローラ」と解するのが自然である。
（イ）本願明細書の【００３４】，【００４２】【００４３】，図１０，図１３等によれば，補正後の発明の「仮想ノード」は，「物理ノード」であるＯｐｅｎＦｌｏｗスイッチと対応付けられることは自明であるから，「複数の通信機能を実行可能な複数の仮想ノード」との事項は，複数の仮想ノードと対応付けられる複数のＯｐｅｎＦｌｏｗスイッチが複数の通信機能を実行可能であることに他ならない。
　そして，本願明細書の【０００４】に示されるＯｐｅｎＦｌｏｗにおける技術常識及び【００６０】，【００６１】によれば，補正後の発明の「複数の通信機能」とは，フローテーブルに登録されたパケットを特定するパケットマッチングルールと，特定のポートに出力する，廃棄する，ヘッダを書き換えるといったアクションの組に従った動作を含むことは明らかである。
　一方，引用発明は，コントローラ内で，ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより，ネットワークのスライスを使用可能とするものであるから，フローレベルの仮想化を実施することにより複数の仮想ノードを含む仮想ネットワークを構築しているといえ，コントローラは仮想化を実施する手段を備えているといえる。
　また，引用発明においても，仮想化されたスイッチと実際のスイッチ（ＯｐｅｎＦｌｏｗスイッチ）とが対応するものであることは明らかである。そして，引用発明に係るＯｐｅｎＦｌｏｗスイッチは，フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し，ＩＰルータ，イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できるものであり，ＯｐｅｎＦｌｏｗにおける技術常識（周知技術１）を参酌すれば，これらの動作はＯｐｅｎＦｌｏｗスイッチがフローテーブルに従って動作することにより為されることは明らかである。
（ウ）本願明細書の【０００４】に示されるＯｐｅｎＦｌｏｗにおける技術常識，【００４２】，【００４５】〜【００４９】，図１４等によれば，補正後の発明の「パケットの識別条件」は，フローテーブルに登録されたパケットを特定するパケットマッチングルールを含むものである。
　一方，引用発明のコントローラは，ＯｐｅｎＦｌｏｗスイッチのフローテーブルエントリを追加／編集／削除するようＯｐｅｎＦｌｏｗスイッチを制御するものであり，ＯｐｅｎＦｌｏｗにおける技術常識（周知技術１）を参酌すれば，フローテーブルエントリはフローテーブルに登録されたパケットを特定するパケットマッチングルールを有しているから，パケットの識別条件を設定可能であると解するのが自然である。そして，引用発明のコントローラは，当該動作をなす手段を備えているといえる。
（エ）本願明細書の【０００４】に示されるＯｐｅｎＦｌｏｗにおける技術常識及び【００４２】〜【００５８】，図１４〜１７によれば，補正後の発明の「前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を，前記識別条件に対応する当該受信パケットに対して実行することを，前記複数の仮想ノードを構成する物理ノードのうち，当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する」とは，ＯｐｅｎＦｌｏｗスイッチが，フローテーブルに対応するエントリが登録されていない受信パケットについて，ＯｐｅｎＦｌｏｗコントローラに対してＰａｃｋｅｔ−Ｉｎにてフローエントリの生成・送信を要求した場合に，ＯｐｅｎＦｌｏｗコントローラが，当該要求に基づいて生成したフローエントリをＦｌｏｗＭｏｄ（Ａｄｄ）にて関係するＯｐｅｎＦｌｏｗスイッチに送信し，そのフローテーブルに追加させることを含むものである。すなわち，ＯｐｅｎＦｌｏｗにおけるＰａｃｋｅｔ−Ｉｎの場合の動作に他ならない。
　一方，引用発明のコントローラはＯｐｅｎＦｌｏｗに係るものであり，標準化されたインタフェースを通じてＯｐｅｎＦｌｏｗスイッチのフローテーブルエントリを追加／編集／削除するよう，ＯｐｅｎＦｌｏｗスイッチを制御するものであるところ，ＯｐｅｎＦｌｏｗにおける技術常識（周知技術１）を参酌すれば，追加はＯｐｅｎＦｌｏｗにおけるＰａｃｋｅｔ−Ｉｎの場合の動作に対応することは明らかである。
　してみると，引用発明のコントローラも，「前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を，前記識別条件に対応する当該受信パケットに対して実行することを，前記複数の仮想ノードを構成する物理ノードのうち，当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する」「手段」を備えているといえる。
　以上を総合すると，補正後の発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと，パケットの識別条件とを設定可能な第一の手段と，
　前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を，前記識別条件に対応する当該受信パケットに対して実行することを，前記複数の仮想ノードを構成する物理ノードのうち，当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する第二の手段と
　を含む制御装置。」
（相違点）
　一致点の「・・・パケットの識別条件とを設定可能な第一の手段」に関し，補正後の発明はパケットが「当該仮想ネットワークのユーザに対応するパケット」であるのに対し，引用発明は当該事項が明らかでない点。
　以下，上記相違点について検討する。
　「当該仮想ネットワークのユーザに対応するパケット」なる記載は日本語として不明瞭であるため，発明の詳細な説明を参酌すると，本願明細書には「ユーザ」について以下の記載がある。
「【００２４】外部ノード３０は，外部ネットワークからアクセスするユーザ端末に対して各種のサービスを提供するサーバによって構成される。」，
「【００３１】図７に示したような仮想ノードの設定は，仮想ネットワークの使用権限を与えられたユーザに変更させることができる。一方，後記する物理ノードと仮想ネットワークとの対応関係等は，ユーザから隠蔽することで，ユーザとしては，仮想ネットワーク上の仮想ノードをあたかも物理的なノードと同様に利用することができる。」，
「【００３５】図８のようなテーブルを仮想ネットワークの数だけ用意することで複数の仮想ネットワークを構築することができる。そして，図９のようなテーブルで，ユーザ毎のパケットの特徴と当該ユーザが使用権限を有する仮想ネットワークとを定義しておくことで，仮想ネットワークを論理的に分離された形態で複数のユーザに提供することができる。」，
「【００４３】・・・例えば，図１３の下段に示す物理ノード１０＃１のリプレースを行った場合，図１０に例示した物理仮想変換で用いるテーブルを修正すればよく，ユーザに見えている仮想ネットワークの構成（図１３の上段参照）には影響を与えない。」
　以上の記載によれば，補正後の発明における「ユーザ」は，外部ネットワークからアクセスするユーザ端末，すなわち，物理ノード１０に入来するユーザパケットのソースであり，仮想ネットワークの使用権限を有し仮想ノードの設定を変更できる者であり，仮想ネットワークを論理的に分離された形態で提供される者であることを含むといえる。
　そして，補正後の発明はＯｐｅｎＦｌｏｗを前提とするものを含むと認められるところ，本願明細書の【０００４】，【０００６】に挙げられた「【非特許文献１】」（周知例１）の記載内容（上記イ（キ），（ク）参照）を参酌すれば，補正後の発明の「当該仮想ネットワークのユーザに対応するパケット」とは，仮想ネットワークを設定したユーザから発信されたパケット（すなわち，周知例１の例では，ネットワークのスライス（ＶＬＡＮ）にて扱われる，１つのフローとして定義される，ＡｍｙのＰＣが接続されているスイッチポートを介してＯｐｅｎＦｌｏｗスイッチに入る全てのトラフィックを構成するパケット。）を含むと解するのが自然である。そして，当該パケットは，ＯｐｅｎＦｌｏｗのヘッダフィールドの「ＶＬＡＮ　ＩＤ」により識別されるパケットを含むと解される。
　一方，引用発明は，(i) コントローラは，ネットワーク内のスイッチ等のフローレベルの仮想化を実施することによりネットワークのスライスを使用可能とするものであり，引用例の図１にはヘッダとして「ＶＬＡＮ　ＩＤ」が示されていること，(ii)引用例の「研究コミュニティは，ネットワークの彼らの「スライス」を実験することで，新しいアイデアを大規模に試すことができれば，恩恵を受けることができる。」との記載（上記イ（ウ）参照。）と，引用例が参考文献（References）として挙げている周知例１の記載（上記イ（キ），（ク）参照。），及び周知事項２，３を参酌すれば，引用発明のコントローラにより，研究コミュニティ（各研究者，例えば周知例１の例のＡｍｙに相当。）が彼らの「スライス」（ＶＬＡＮ）にて実験するためにネットワークのスイッチ等を仮想化し，「ＶＬＡＮ　ＩＤ」にて識別されるパケットを当該「スライス」にて実験するようにすることは，格別困難なことではない。
　すなわち，引用発明のコントローラが，「当該仮想ネットワークのユーザに対応するパケットの識別条件を設定可能」とすることは，当業者が容易になし得ることである。
　そして，補正後の発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測できる範囲のものである。
３　結語
　したがって，本件補正は，補正後の発明が特許出願の際独立して特許を受けることができないものであるから，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成２８年３月２２日付けの手続補正は上記のとおり却下されたので，本願発明は，上記「第２　補正の却下の決定」の項中の「１　本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。
２　引用発明等
　引用発明及び周知技術は，上記「第２　補正の却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件」の項中の「イ　引用発明等」の項で認定したとおりである。
３　対比・判断
　そこで，本願発明と引用発明とを対比するに，本願発明は補正後の発明から当該補正に係る限定を省いたものである。
　そうすると，本願発明の構成に当該補正に係る限定を付加した補正後の発明が，上記「第２　補正の却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件」の項中の「ウ　対比・判断」の項で検討したとおり，引用発明及び周知技術に基づいて容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
４　むすび
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。