ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 5項独立特許用件 特許、登録しない。 H04L 審判 査定不服 2項進歩性 特許、登録しない。 H04L |
---|---|
管理番号 | 1328992 |
審判番号 | 不服2016-4314 |
総通号数 | 211 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2017-07-28 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2016-03-22 |
確定日 | 2017-06-08 |
事件の表示 | 特願2014- 43134「情報システム,制御サーバ,仮想ネットワーク管理方法およびプログラム」拒絶査定不服審判事件〔平成26年 7月10日出願公開,特開2014-131347〕について,次のとおり審決する。 |
結論 | 本件審判の請求は,成り立たない。 |
理由 |
第1 手続の経緯 本願は,2010年(平成22年)10月7日(国内優先権主張 平成21年10月7日)を国際出願日とする出願である特願2011-535449号の一部を,平成26年3月5日に新たな特許出願としたものであって,平成26年11月28日付けで拒絶理由が通知され,平成27年2月2日付けで手続補正がされ,同年4月23日付けで拒絶理由が通知され,同年7月7日付けで手続補正がされ,同年9月11日付けで最後の拒絶理由が通知され,同年11月30日付けで手続補正がされたが,同年12月15日付けで補正の却下の決定がされ,同日付けで拒絶査定がされ,これに対し,平成28年3月22日に拒絶査定不服審判が請求され,同時に手続補正がされたものである。 第2 補正の却下の決定 [結論] 平成28年3月22日付けの手続補正を却下する。 [理由] 1 本願発明と補正後の発明 平成28年3月22日付けの手続補正(以下,「本件補正」という。)は,平成27年7月7日付けの手続補正により補正された特許請求の範囲の請求項1に記載された 「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと,当該仮想ネットワークのユーザに対応するパケットの識別条件とを設定可能な第一の手段と, 前記複数の通信機能の各々に対応するパケット処理を,前記識別条件に対応するパケットに対して実行することを,前記複数の仮想ノードを構成する物理ノードに指示する第二の手段と を含む制御装置。」(以下,「本願発明」という。) を, 「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと,当該仮想ネットワークのユーザに対応するパケットの識別条件とを設定可能な第一の手段と, 前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を,前記識別条件に対応する当該受信パケットに対して実行することを,前記複数の仮想ノードを構成する物理ノードのうち,当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する第二の手段と を含む制御装置。」(以下,「補正後の発明」という。) に変更することを含むものである。([当審注]:下線部は補正箇所を示す。) 2 補正の適否 (1)新規事項の有無,シフト補正の有無,補正の目的要件 請求項1についての上記補正は,本件補正前の「パケット処理を,前記識別条件に対応するパケットに対して実行する」を,「パケット処理のうち受信パケットに対するパケット処理を,前記識別条件に対応する当該受信パケットに対して実行する」と限定し,また,「物理ノードに指示する」を「物理ノードのうち,当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する」と限定して,特許請求の範囲を減縮するものである。したがって,当該補正の目的は,特許法第17条の2第5項第2号に掲げる事項に該当する。 独立請求項である請求項3,5,7?12についての補正も,請求項1についての上記補正と同様である。 そして,これらの補正は,特許法第17条の2第3項,第4項に違反するところはない。 (2)独立特許要件 請求項1についての上記補正は,特許請求の範囲の減縮を目的とするものであるから,本件補正後の請求項1に係る発明が特許出願の際独立して特許を受けることができるものであるのか否かについて,以下検討する。 ア 補正後の発明 補正後の発明は,上記「1 本願発明と補正後の発明」の項の「補正後の発明」のとおりのものと認める。 イ 引用発明等 [引用発明] 原査定の拒絶の理由に引用されたSaurav Das et al.,Simple Unified Control for Packet and Circuit Networks([当審仮訳]:パケット及び回線ネットワークのための簡単な統一された制御),IEEE/LEOS Summer Topical Meeting, 2009 (LEOSST '09),pp.147-148,2009年7月,IEEE, (ア)「 」(147ページ左欄下から9行?右欄3行) ([当審仮訳]: OpenFlow 基本的な考え方は簡単である:OpenFlowは,内部フローテーブルとフローテーブルエントリ(図1)を追加/編集/削除するための標準化されたインタフェースとを備えたパケットスイッチに基づいている。それは,最新のスイッチング機器には,回線速度で動作し,入来トラフィックを発信ポートにマッピングするテーブルが含まれているという事実を利用している。各ベンダーの機器は様々であるが,OpenFlowは全てのスイッチに実装されている共通の機能セットを利用している。更に,オープンに標準化されたインタフェイス(OpenFlowプロトコル)は,スイッチの制御を箱の外に出し,ネットワークオペレータの制御下にあるコントローラに配置する。 (図1は省略) ) (イ)「 」(147ページ右欄4?10行) ([当審仮訳]: OpenFlowは完全に後方互換性がある。OpenFlowスイッチのデータパスは,ヘッダにおいてまさにフローを構成しているものを識別するエントリに加えて,そのようなフローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルで構成される。OpenFlowスイッチは,IPルータ,イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる。) (ウ)「 (中略) 」(148ページ右欄28?38行,45?48行) ([当審仮訳]: 研究コミュニティは,ネットワークの彼らの「スライス」を実験することで,新しいアイデアを大規模に試すことができれば,恩恵を受けることができる。このようなスライスは,ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化によって使用可能にすることができる。このような分割化/仮想化は,コンピュータ内のオペレーティングシステムがユーザ空間とカーネル空間とを分割するのと丁度同じように,コントローラ内で実施され得る。うまくいけば,プロダクションスライスに導入する前に新しいアイデアをネットワークの1つのスライスで徹底的にテストすることができ,研究から産業への技術移転となる(そのようなものは現在殆ど存在していない)。 (中略) 参考文献 [1](文献名については省略。) [2](文献名については省略。) ) 引用例の上記各記載及び各図面並びに当該技術分野の技術常識を考慮すると, 上記(ア)の記載によれば,OpenFlowは,標準化されたインタフェース(OpenFlowプロトコル)により,スイッチの制御をスイッチの外のコントローラにて行うものである。図1を見ると,OpenFlowスイッチとコントローラがセキュアチャネルでOpenFlowプロトコルにより通信すること,OpenFlowスイッチがフローテーブルを持つことが見てとれる。そして,標準化されたインタフェース(OpenFlowプロトコル)は,OpenFlowスイッチのフローテーブルエントリを追加/編集/削除するためのものである。したがって,コントローラは,「標準化されたインタフェースを通じてOpenFlowスイッチのフローテーブルエントリを追加/編集/削除するよう,OpenFlowスイッチを制御する」といえる。 また,上記(イ)の記載によれば,標準化されたインタフェース(OpenFlowプロトコル)を備えたOpenFlowスイッチは,フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し,IPルータ,イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できるものである。したがって,OpenFlowスイッチは,「フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し,IPルータ,イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる」といえる。 また,上記(ウ)の記載によれば,ネットワークのスライスは,ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化によって使用可能にすることができ,仮想化はコントローラ内で実施され得るものである。したがって,コントローラは,「コントローラ内で,ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより,ネットワークのスライスを使用可能にすることができるものである」といえる。 以上を総合すると,引用例には以下の発明(以下,「引用発明」という。)が記載されていると認める。 「コントローラ内で,ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより,ネットワークのスライスを使用可能とし, 標準化されたインタフェースを通じてOpenFlowスイッチのフローテーブルエントリを追加/編集/削除するよう,OpenFlowスイッチを制御する, ここで,前記OpenFlowスイッチは,フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し,IPルータ,イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できる, コントローラ。」 [周知技術] 引用例に参考文献(References[1])として引用され,本願明細書において背景技術を示す「【非特許文献1】」とされている,Nick McKeown外7名,“OpenFlow: Enabling Innovation in Campus Networks”([当審仮訳]:キャンパスネットワークにおけるイノベーションの実現),200年3月14日,〈URL:http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉(以下,「周知例1」という。)には,図面とともに以下の事項が記載されている。 (エ)「 」(2葉目右欄4行?3葉目左欄13行) ([当審仮訳]: 2.OpenFlowスイッチ 基本的な考え方は簡単である:最新のイーサネットスイッチ及びルータの殆どは,ファイアウォール,NAT,QoSを実装し,統計情報を収集するために,回線速度で動作するフローテーブル(通常はTCAMsで構築されている)を使用している。各ベンダーのフローテーブルは様々であるが,多くのスイッチやルータで実行される関心のある共通の機能セットを特定している。OpenFlowは,この共通の機能を利用している。 OpenFlowは,様々なスイッチやルータのフローテーブルをプログラムするオープンプロトコルを提供する。ネットワーク管理者は,トラフィックを製品フローとリサーチフローとに分割できる。研究者は,彼らのパケットが従う経路及び受信した処理を選択することにより,彼ら独自のフローを制御できる。このようにして,研究者は,新しいルーティングプロトコル,セキュリティモデル,アドレス指定スキーム,更にはIPの代替手段を試すことができる。同じネットワーク上で,製品トラフィックは,分離され,現在と同じ方法で処理される。 OpenFlowスイッチのデータパスは,フローテーブルと,各フローエントリに関連付けられたアクションで構成される。OpenFlowスイッチによりサポートされるアクションのセットは拡張可能であるが,以下では全てのスイッチについての最小要件について説明する。高性能で低コストであるためには,データパスは慎重に規定された程度の柔軟性を備えていなければならない。これは,各パケットの任意の処理を指定する能力を控え,より限定された,しかし依然として有用なアクションの範囲を探すことを意味する。したがって,本書の後半では,全てのOpenFlowスイッチについての基本的な必要とされるアクションセットを定義する。 OpenFlowスイッチは,少なくとも次の3つの部分からなる。:(1) 各フローエントリに関連付けられたアクションを有し,フローにどのように処理するかをスイッチに指示する,フローテーブル,(2) スイッチをリモート制御プロセス(コントローラと呼ばれる)に接続し,コントローラと使用するスイッチ間でコマンドとパケットを送信できるようにする,セキュアチャネル,(3) コントローラがスイッチと通信するためのオープンで標準的な方法を提供する,OpenFlowプロトコル。フローテーブルのエントリを外部で定義できる標準インタフェース(OpenFlowプロトコル)を指定することにより,OpenFlowスイッチは研究者がスイッチをプログラムする必要性を回避する。 スイッチを,通常のレイヤ2及びレイヤ3処理をサポートしない専用のOpenFlowスイッチと,OpenFlowプロトコルとインタフェースが新たな機能として追加された,OpenFlowが可能な汎用の市販イーサネットスイッチ及びルータとに分類することは有用である。) (オ)「 (中略) 」(3葉目左欄下から17行?3行,6葉目右欄下から11行?10行) ([当審仮訳]: フローテーブルのエントリは,次の3つのフィールドを有している。(1) フローを定義するパケットヘッダ,(2) パケットの処理方法を定義するアクション,(3) 各フローのパケット数やバイト数及び(非アクティブフローの削除を支援するため)最後のパケットがフローに一致してからの時間の情報をずっと得る,統計情報。 第1世代「タイプ0」スイッチでは,フローヘッダは表1に示す10タプルである。TCPフローは10個のフィールド全てで指定できるが,IPフローには定義内にトランスポート・ポートが含まれていない可能性がある。VLAN IDだけが定義されたフローが特定のVLAN上の全てのトラフィックに適用されるように,各ヘッダーフィールドはフローの集約を可能にするワイルドカードとなることができる。 OpenFlowスイッチの詳細な要件は,OpenFlow Switch Specification [6]で定義されている。 (中略) [6](文献名は省略。) ) (カ)「 」(3葉目右欄下から17行?5行) ([当審仮訳]: コントローラ。 コントローラは,実験のためにフローテーブルからフローエントリを追加及び削除する。例えば,静的コントローラは,実験期間中,テストコンピュータのセットを相互接続するフローを静的に確立するために,PC上で実行される単純なアプリケーションであってもよい。この場合,フローは,現在のネットワークにおけるVLANに似ており,製品ネットワークから実験トラフィックを分離する簡単なメカニズムを提供する。このように,OpenFlowはVLANの一般化である。) (キ)「 」(4葉目左欄5行?25行) ([当審仮訳]: 3.OpenFlowの使用 OpenFlowスイッチの使い方の簡単な例として,Amy(研究者)がOSPF([当審注]:Open shortest Path First)に置き換える新しいルーティングプロトコルとしてAmy-OSPFを発明したとする。彼女はエンドホストのソフトウェアを変更することなく,OpenFlowスイッチのネットワークで彼女のプロトコルを試してみたいと思っている。Amy-OSPFはコントローラで動作し,新しいアプリケーションフローが開始するたびに,Amy-OSPFは一連のOpenFlowスイッチを通してルートを選択し,パスに沿う各スイッチにフローエントリを追加する。彼女の実験では,Amyは自分のデスクトップPCからOpenFlowネットワークに入るトラフィックに対してAmy-OSPFを使用すると決めたので,他の人のネットワークを混乱させることはない。これを行うために,彼女は自分のPCが接続されているスイッチポートを介してOpenFlowスイッチに入る全てのトラフィックを1つのフローとして定義し,「全てのパケットをカプセル化してコントローラに転送する」というアクションを持つフローエントリを追加する。パケットがコントローラに到達すると,新しいプロトコルがルートを選択し,選択したパスに沿う全てのスイッチに新しいフローエントリ(アプリケーションフロー用)を追加する。後続のパケットがスイッチに到着すると,それらはフローテーブルによって迅速に(及び回線速度で)処理される。) (ク)「 」 ([当審仮訳]: 3.2 更なる例 (中略) 例2:VLANs OpenFlowは,VLANと同様に,ユーザに独自の隔離されたネットワークを簡単に提供できる。最も簡単な方法は,所与のVLAN ID上のトラフィックがアクセス可能なポートを指定するフローのセットを静的に宣言することである。(例えば,特定のスイッチポート又はMACアドレスから発信された)単一ユーザから入来したと識別されたトラフィックは,スイッチによって(アクションを介して)適切なVLAN IDがタグ付けされる。 より動的な方法は,ユーザの資格検証の管理にコントローラを用い,回線速度のタグ付けされたトラフィックのためにユーザの一の知識を用いることができる。) 原査定の拒絶の理由に引用されたNick McKeown,Software-defined Networking,2009年4月, (ケ)「 」(48?56番目のスライド) 引用例に参考文献(References[2])として引用され,周知例1に参考文献(References[6])として引用された技術仕様OpenFlow Switch Specificationであって,本件の最先の優先日前に公知となった技術仕様であるOpenFlow Switch Specification Version0.9.0(Wire Protocol 0x98),2009年7月20日, (コ)「 (中略) (中略) (中略) (中略) (中略) (中略) (中略) (中略) 」(1?3,4,5,7,9,10ページ) ([当審仮訳]: 2 スイッチ部品 OpenFlowスイッチは,パケットルックアップとフォワーディングを実行するフローテーブルと,外部コントローラ(図1)へのセキュアなチャネルで構成される。コントローラは,OpenFlowプロトコルを使用して安全なチャネルを介してスイッチを管理する。 フローテーブルには,フローエントリ(パケットと一致するヘッダ値)のセット,アクティビティカウンタ及び一致するパケットに適用する0個以上のアクションのセットが含まれている。スイッチによって処理された全てのパケットは,フローテーブルと比較される。一致するエントリが見つかった場合,そのエントリに対する任意のアクションがパケットに対して実行される(例えば,アクションは特定のポートからパケットを転送することである)。一致するものが見つからない場合,パケットは安全なチャネルを介してコントローラに転送される。コントローラは,有効なフローエントリのないパケットの処理方法を決定し,フローエントリを追加及び削除してスイッチフローテーブルを管理する。 (図1は省略) 3 フローテーブル この節では,フローテーブルエントリのコンポーネントと,入来パケットがフローテーブルのエントリと照合されるプロセスについて説明する。 (表1は省略) 各フローテーブルエントリ(表1参照)には,次のものが含まる。 ・パケットと一致するヘッダフィールド ・一致するパケットを更新するカウンタ ・一致するパケットに適用するアクション 3.1 ヘッダフィールド (表2は省略) 表2は,入来パケットが比較されるヘッダフィールドを示す。各エントリには,任意の値に一致する特定の値又はANYが含まれる。スイッチがIPソース及び/又は宛先フィールドでサブネットマスクをサポートしている場合,これらはより正確に一致を指定できる。OpenFlowの11タプルのフィールドを表2に,各フィールドのプロパティの詳細を表3に示す。 (中略) 3.3 アクション 各フローエントリは,スイッチが一致するパケットをどのように処理するかを指示するゼロ以上のアクションに関連付けられている。アクションは,フローエントリで指定された順序で実行する必要はない。アクションが存在しない場合,パケットは廃棄される。 (中略) 必要なアクション:転送。OpenFlowスイッチは,パケットを物理ポート及び次の仮想ポートに転送する機能をサポートしている必要がある。 (中略) オプションのアクション:転送。スイッチは,オプションで次の仮想ポートをサポートする。 (中略) 必要なアクション:廃棄。指定されたアクションのないフローエントリは,一致する全てのパケットを破棄する必要があることを示す。 オプションのアクション:フィールドの変更。厳密には必要とされていないが,表5に示すアクションは,OpenFlow実装の有用性を大幅に高める。既存のネットワークとの統合を支援するために,VLAN変更アクションをサポートすることを提案する。 (中略) 4.1 OpenFlowプロトコルの概要 OpenFlowプロトコルは,それぞれが複数のサブタイプを持つ,コントローラからスイッチ,非同期及び対称の3つのメッセージタイプをサポートする。コントローラからスイッチへのメッセージは,コントローラによって開始され,スイッチの状態を直接管理又は検査するために使用される。非同期メッセージは,スイッチによって開始され,ネットワークイベントのコントローラ及びスイッチ状態の変更を更新するために使用される。対称メッセージは,スイッチ又はコントローラのいずれかによって開始され,懇願なしに送信される。OpenFlowで使用されるメッセージの種類は以下のとおり。 (中略) Packet-in:一致するフローエントリを持たない全てのパケットについて,パケットインイベントがコントローラに送信される(又はパケットが「コントローラへ送信」アクションを持つエントリと一致する場合)。コントローラに送信されたパケットをバッファするために十分なメモリがスイッチが有している場合,パケットインイベントには,パケットヘッダの一部(デフォルトでは128バイト)と,スイッチにパケットを送信するよう準備させるときにコントローラによって使用されるバッファIDが含まれる。スイッチを切り替えてパケットを転送します。内部にバッファを持たない(又は内部のバッファが使い果たされている)スイッチは,イベントの一部として,全てのパケットをコントローラに送信する必要がある。) 上記(エ)?(コ)の記載によれば,本件の優先日前に以下の事項は技術常識ともいえる周知事項であると認められる。 「OpenFlowという技術の規格化が進められており,OpenFlowは,通信をフローとして捉え,フロー単位で経路制御等を行うものである。転送ノードとして機能するOpenFlowスイッチは,OpenFlowプロトコルに従ってOpenFlowコントローラにより追加・更新されるフローテーブルに従って動作する。フローテーブルには,パケットを特定するパケットマッチングルールと,特定のポートに出力する,廃棄する,ヘッダを書き換えるといったアクションの組がフローエントリとして登録される。フローエントリにより,OpenFlowスイッチは,スイッチング,ファイアフォール,VLAN等として機能し得る。OpenFlowスイッチは,該当するフローエントリがあった場合,フローエントリに記載されたアクションに従って受信パケットの処理を行い,該当フローエントリがない場合は,OpenFlowプロトコルのPacket-inによりコントローラに通知する。通知を受けたコントローラは,該当フローエントリのないパケットの処理方法を決定し,関連するOpenFlowスイッチのフローテーブルにフローエントリの追加等を指示する。」(以下,「周知事項1」という。), 「OpenFlowでは,ネットワークは,フローテーブルにより,例えば各研究者毎のVLANとして分割化することができる。」(以下,「周知事項2」という。), 「OpenFlowは,ヘッダフィールドにVLAN IDを備え,VLANと同様に,ユーザに独自の隔離されたネットワークを簡単に提供できる。」(以下,「周知事項3」という。) ウ 対比・判断 補正後の発明と引用発明とを対比すると, (ア)本願明細書の【0006】,【0018】,【0020】,【0022】,【0023】等によれば,補正後の発明の「制御装置」は,「【非特許文献1】」に開示された,「OpenFlowコントローラ」を含むことは明らかである。 一方,引用発明の「コントローラ」は,OpenFlowに関するコントローラであり,引用例の参考文献(References)として,上記「【非特許文献1】」と同一の文献(周知例1)が挙げられていることから,「【非特許文献1】」(周知例1)に開示された,「OpenFlowコントローラ」と解するのが自然である。 (イ)本願明細書の【0034】,【0042】【0043】,図10,図13等によれば,補正後の発明の「仮想ノード」は,「物理ノード」であるOpenFlowスイッチと対応付けられることは自明であるから,「複数の通信機能を実行可能な複数の仮想ノード」との事項は,複数の仮想ノードと対応付けられる複数のOpenFlowスイッチが複数の通信機能を実行可能であることに他ならない。 そして,本願明細書の【0004】に示されるOpenFlowにおける技術常識及び【0060】,【0061】によれば,補正後の発明の「複数の通信機能」とは,フローテーブルに登録されたパケットを特定するパケットマッチングルールと,特定のポートに出力する,廃棄する,ヘッダを書き換えるといったアクションの組に従った動作を含むことは明らかである。 一方,引用発明は,コントローラ内で,ネットワーク内のスイッチ及び他のリソースのフローレベルの仮想化を実施することにより,ネットワークのスライスを使用可能とするものであるから,フローレベルの仮想化を実施することにより複数の仮想ノードを含む仮想ネットワークを構築しているといえ,コントローラは仮想化を実施する手段を備えているといえる。 また,引用発明においても,仮想化されたスイッチと実際のスイッチ(OpenFlowスイッチ)とが対応するものであることは明らかである。そして,引用発明に係るOpenFlowスイッチは,フローテーブルエントリと一致する入来パケットに対して実行される関連アクションを備えるフローテーブルを有し,IPルータ,イーサネットスイッチ又はスタンドアロンのアプリケーションレイヤファイアウォールとして動作できるものであり,OpenFlowにおける技術常識(周知技術1)を参酌すれば,これらの動作はOpenFlowスイッチがフローテーブルに従って動作することにより為されることは明らかである。 (ウ)本願明細書の【0004】に示されるOpenFlowにおける技術常識,【0042】,【0045】?【0049】,図14等によれば,補正後の発明の「パケットの識別条件」は,フローテーブルに登録されたパケットを特定するパケットマッチングルールを含むものである。 一方,引用発明のコントローラは,OpenFlowスイッチのフローテーブルエントリを追加/編集/削除するようOpenFlowスイッチを制御するものであり,OpenFlowにおける技術常識(周知技術1)を参酌すれば,フローテーブルエントリはフローテーブルに登録されたパケットを特定するパケットマッチングルールを有しているから,パケットの識別条件を設定可能であると解するのが自然である。そして,引用発明のコントローラは,当該動作をなす手段を備えているといえる。 (エ)本願明細書の【0004】に示されるOpenFlowにおける技術常識及び【0042】?【0058】,図14?17によれば,補正後の発明の「前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を,前記識別条件に対応する当該受信パケットに対して実行することを,前記複数の仮想ノードを構成する物理ノードのうち,当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する」とは,OpenFlowスイッチが,フローテーブルに対応するエントリが登録されていない受信パケットについて,OpenFlowコントローラに対してPacket-Inにてフローエントリの生成・送信を要求した場合に,OpenFlowコントローラが,当該要求に基づいて生成したフローエントリをFlowMod(Add)にて関係するOpenFlowスイッチに送信し,そのフローテーブルに追加させることを含むものである。すなわち,OpenFlowにおけるPacket-Inの場合の動作に他ならない。 一方,引用発明のコントローラはOpenFlowに係るものであり,標準化されたインタフェースを通じてOpenFlowスイッチのフローテーブルエントリを追加/編集/削除するよう,OpenFlowスイッチを制御するものであるところ,OpenFlowにおける技術常識(周知技術1)を参酌すれば,追加はOpenFlowにおけるPacket-Inの場合の動作に対応することは明らかである。 してみると,引用発明のコントローラも,「前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を,前記識別条件に対応する当該受信パケットに対して実行することを,前記複数の仮想ノードを構成する物理ノードのうち,当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する」「手段」を備えているといえる。 以上を総合すると,補正後の発明と引用発明とは,以下の点で一致し,また,相違している。 (一致点) 「複数の通信機能を実行可能な複数の仮想ノードを含む仮想ネットワークと,パケットの識別条件とを設定可能な第一の手段と, 前記複数の通信機能の各々に対応するパケット処理のうち受信パケットに対するパケット処理を,前記識別条件に対応する当該受信パケットに対して実行することを,前記複数の仮想ノードを構成する物理ノードのうち,当該受信パケットの識別条件に基づいて特定された仮想ネットワークに対応する物理ノードに指示する第二の手段と を含む制御装置。」 (相違点) 一致点の「・・・パケットの識別条件とを設定可能な第一の手段」に関し,補正後の発明はパケットが「当該仮想ネットワークのユーザに対応するパケット」であるのに対し,引用発明は当該事項が明らかでない点。 以下,上記相違点について検討する。 「当該仮想ネットワークのユーザに対応するパケット」なる記載は日本語として不明瞭であるため,発明の詳細な説明を参酌すると,本願明細書には「ユーザ」について以下の記載がある。 「【0024】外部ノード30は,外部ネットワークからアクセスするユーザ端末に対して各種のサービスを提供するサーバによって構成される。」, 「【0031】図7に示したような仮想ノードの設定は,仮想ネットワークの使用権限を与えられたユーザに変更させることができる。一方,後記する物理ノードと仮想ネットワークとの対応関係等は,ユーザから隠蔽することで,ユーザとしては,仮想ネットワーク上の仮想ノードをあたかも物理的なノードと同様に利用することができる。」, 「【0035】図8のようなテーブルを仮想ネットワークの数だけ用意することで複数の仮想ネットワークを構築することができる。そして,図9のようなテーブルで,ユーザ毎のパケットの特徴と当該ユーザが使用権限を有する仮想ネットワークとを定義しておくことで,仮想ネットワークを論理的に分離された形態で複数のユーザに提供することができる。」, 「【0043】・・・例えば,図13の下段に示す物理ノード10#1のリプレースを行った場合,図10に例示した物理仮想変換で用いるテーブルを修正すればよく,ユーザに見えている仮想ネットワークの構成(図13の上段参照)には影響を与えない。」 以上の記載によれば,補正後の発明における「ユーザ」は,外部ネットワークからアクセスするユーザ端末,すなわち,物理ノード10に入来するユーザパケットのソースであり,仮想ネットワークの使用権限を有し仮想ノードの設定を変更できる者であり,仮想ネットワークを論理的に分離された形態で提供される者であることを含むといえる。 そして,補正後の発明はOpenFlowを前提とするものを含むと認められるところ,本願明細書の【0004】,【0006】に挙げられた「【非特許文献1】」(周知例1)の記載内容(上記イ(キ),(ク)参照)を参酌すれば,補正後の発明の「当該仮想ネットワークのユーザに対応するパケット」とは,仮想ネットワークを設定したユーザから発信されたパケット(すなわち,周知例1の例では,ネットワークのスライス(VLAN)にて扱われる,1つのフローとして定義される,AmyのPCが接続されているスイッチポートを介してOpenFlowスイッチに入る全てのトラフィックを構成するパケット。)を含むと解するのが自然である。そして,当該パケットは,OpenFlowのヘッダフィールドの「VLAN ID」により識別されるパケットを含むと解される。 一方,引用発明は,(i) コントローラは,ネットワーク内のスイッチ等のフローレベルの仮想化を実施することによりネットワークのスライスを使用可能とするものであり,引用例の図1にはヘッダとして「VLAN ID」が示されていること,(ii)引用例の「研究コミュニティは,ネットワークの彼らの「スライス」を実験することで,新しいアイデアを大規模に試すことができれば,恩恵を受けることができる。」との記載(上記イ(ウ)参照。)と,引用例が参考文献(References)として挙げている周知例1の記載(上記イ(キ),(ク)参照。),及び周知事項2,3を参酌すれば,引用発明のコントローラにより,研究コミュニティ(各研究者,例えば周知例1の例のAmyに相当。)が彼らの「スライス」(VLAN)にて実験するためにネットワークのスイッチ等を仮想化し,「VLAN ID」にて識別されるパケットを当該「スライス」にて実験するようにすることは,格別困難なことではない。 すなわち,引用発明のコントローラが,「当該仮想ネットワークのユーザに対応するパケットの識別条件を設定可能」とすることは,当業者が容易になし得ることである。 そして,補正後の発明の作用効果も,引用発明及び周知技術に基づいて当業者が予測できる範囲のものである。 3 結語 したがって,本件補正は,補正後の発明が特許出願の際独立して特許を受けることができないものであるから,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3 本願発明について 1 本願発明 平成28年3月22日付けの手続補正は上記のとおり却下されたので,本願発明は,上記「第2 補正の却下の決定」の項中の「1 本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。 2 引用発明等 引用発明及び周知技術は,上記「第2 補正の却下の決定」の項中の「2 補正の適否」の項中の「(2)独立特許要件」の項中の「イ 引用発明等」の項で認定したとおりである。 3 対比・判断 そこで,本願発明と引用発明とを対比するに,本願発明は補正後の発明から当該補正に係る限定を省いたものである。 そうすると,本願発明の構成に当該補正に係る限定を付加した補正後の発明が,上記「第2 補正の却下の決定」の項中の「2 補正の適否」の項中の「(2)独立特許要件」の項中の「ウ 対比・判断」の項で検討したとおり,引用発明及び周知技術に基づいて容易に発明できたものであるから,本願発明も同様の理由により,容易に発明できたものである。 4 むすび 以上のとおり,本願発明は,引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許を受けることができない。 よって,結論のとおり審決する。 |
審理終結日 | 2017-03-30 |
結審通知日 | 2017-04-04 |
審決日 | 2017-04-24 |
出願番号 | 特願2014-43134(P2014-43134) |
審決分類 |
P
1
8・
121-
Z
(H04L)
P 1 8・ 575- Z (H04L) |
最終処分 | 不成立 |
前審関与審査官 | 浦口 幸宏、永井 啓司 |
特許庁審判長 |
大塚 良平 |
特許庁審判官 |
菅原 道晴 吉田 隆之 |
発明の名称 | 情報システム、制御サーバ、仮想ネットワーク管理方法およびプログラム |
代理人 | 加藤 朝道 |