【事件の表示】
　特願２０１５−５５５１８５「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシー情報を用いる方法、システムおよびコンピュータ読取可能媒体」拒絶査定不服審判事件〔平成２６年　７月３１日国際公開、ＷＯ２０１４／１１６４６５、平成２８年　３月２２日国内公表、特表２０１６−５０８６９０、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１４年（平成２６年）１月１４日（パリ条約による優先権主張外国庁受理２０１３年１月２４日、米国）を国際出願日とする出願であって、その手続きの経緯は以下のとおりである。
　平成２８年　８月１８日付け：拒絶理由通知書
　平成２８年１０月１２日　　：意見書、手続補正書の提出
　平成２８年１２月　９日付け：拒絶理由（最後の拒絶理由）通知書、
　平成２９年　１月３１日　　：意見書、手続補正書の提出
　平成２９年　２月　６日付け：平成２９年１月３１日の手続補正について
　　　　　　　　　　　　　　　の補正の却下の決定、拒絶査定
　平成２９年　６月１４日　　：審判請求書、手続補正書の提出
第２　平成２９年２月６日付けの補正の却下の決定及び原査定の概要
１　平成２９年２月６日付けの補正の却下の決定の概要は、以下のとおりである。
　平成２９年１月３１日付けの補正は、特許請求の範囲の限定的減縮を目的とするものであるが、当該補正後の本願請求項１−１０に係る発明は、引用文献１、２に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであり、独立特許要件を満たさないから、平成２９年１月３１日付けの補正は却下すべきものである。
＜引用文献等一覧＞
　１．林　偉夫、上野　洋史，将来のクラウド基盤技術を支える研究開発，
　　　ＮＥＣ技報　第６３巻　第２号，日本電気株式会社，
　　　２０１０年４月２３日，ｐｐ．１２４−１２８
　２．特表２０１２−５１１８４６号公報
２　原査定（平成２９年２月６日付け拒絶査定）の概要は、次のとおりである。
　本願請求項１−１０に係る発明は、上記引用文献１、２に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
第３　本願発明
　本願の請求項１−１０に係る発明（以下、それぞれ「本願発明１」−「本願発明１０」という。）は、平成２９年６月１４日付けで手続補正された特許請求の範囲の請求項１−１０に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。
「【請求項１】
　ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能（ＰＣＲＦ）のポリシー情報またはＰＣＲＦによって得られるポリシー情報を用いるシステムであって、
　ＰＣＲＦを含み、前記ＰＣＲＦは、
　　前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワークノードを識別するためのポリシーエンジンと、
　　セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも１つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータと、を含み、
　前記アプリケーションルーティングコンフィギュレータは、前記ＰＣＲＦ内に統合されたＯｐｅｎＦｌｏｗコンパチブルコントローラを含み、
　前記少なくとも１つの構成可能なネットワークエレメントは、ＯｐｅｎＦｌｏｗコンパチブルスイッチを含み、
　前記ＯｐｅｎＦｌｏｗコンパチブルスイッチは、
　　それぞれが他の各前記ネットワークノードに対応し、対応のネットワークノードから入来するパケットを受付ける第１ポートと、
　　それぞれが他の各前記ネットワークノードに関連付けられて、関連付けられたネットワークノードへパケットを出力する第２ポートと、を有し、
　前記少なくとも１つの構成可能なネットワークエレメントを構成するための命令は、ベアラセッションにおけるパケットを特定するためのパラメータを含むＯｐｅｎＦｌｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第１ポートを識別するポート識別子およびセッション識別子を有し、前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、
　当該実行する命令は、ＯｐｅｎＦｌｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第２ポートを介して出力するように指示し、前記一致するパケットは、前記ＯｐｅｎＦｌｏｗコンパチブルスイッチに入来するパケットであって、当該入来パケットは前記パラメータのポート識別子により識別される第１ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケットである、システム。」
　本願発明２−８は、本願発明１を減縮した発明である。
　本願発明９，１０は、それぞれ本願発明１に対応する方法の発明、コンピュータ読取可能なプログラムの発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。
第３　引用文献・引用発明等
１　引用文献１について
　原査定の拒絶理由に引用された引用文献１には、図面とともに次の事項が記載されている。（下線は当審により注目する点に付与した。以下、同様。）
Ａ．「２．１従来のネットワークノードやシステムの課題」の欄
「図１に、従来のデータセンターネットワークの構成を例として、ネットワークノード及びシステムの課題について示します。
　初めに、本稿で使用する用語について説明します。
ネットワークノードは、ルータやスイッチなどの通信機器に加えて、帯域制御装置や負荷分散装置などのアプライアンス機器など、ネットワークを構成する要素と定義します。ネットワークシステムは、ネットワークノードで構成されるシステムのことであり
　まず、ネットワークノードの課題について説明します。従来のネットワークノードは、通信回線の最大速度に対応できるように設計されています。そのため、実際のトラフィックが少ない場合でも、最大性能をもったノードを配備する必要があり、設備コストが増大するという課題があります。
　また、通信ニーズの多様化に合わせてネットワークノードの柔軟性を確保するために、汎用サーバでネットワーク処理を実現することが考えられますが、多くの通信処理にとっては、汎用サーバだけでは性能や機能が不足しており、特に性能の面では、要求性能の達成が難しいという課題があります。また、汎用サーバにおける通信処理は、電力効率が悪いという課題もあります。
　・・・（中略）・・・
　次に、ネットワークシステム構成における課題について説明します。クラウドごとの異なる多様な要件を満たすため、既存技術では、負荷分散装置、ファイアウォールなどのミドルボックスとサーバ、ストレージをネットワーク機器で接続して対応することが考えられます。しかしながら、このようなシステムは、構成変更の自由度が低いという課題があります。例えば、既存のネットワークにミドルボックスの導入を行う場合、ネットワークの物理的な接続や設定を変更する必要があります。そのため、ネットワークへの影響を事前に考慮してネットワークの再設計を行い、サービス断を伴って構成を変更することが一般的です。物理的な接続変更を伴うため人為的なミスが入る可能性もあります。このような理由から、従来のネットワークシステムは、要件変更が頻繁に発生するような状況に対応することが困難であるという課題があります。」
Ｂ．「３．ネットワークシステムにおける動的再構成」の欄
「
動的再構成は、前述したネットワークシステムの要件に対応する技術です。分解された機能の結合で処理を表現した場合、ネットワークシステムの動的再構成は、図２に示すような機能の追加、削除、移動、接続の変更という４つの要素があります。
　（１）機能の追加
　機能の追加は、新たな処理の提供や処理内容の変更要求を受けて、新たな機能を追加して機能間の再接続を行うことです。また、性能向上を目的として機能のコピーを作成して負荷分散を行うこともあります。
　（２）機能の削除
　機能の削除は、要件などの変更に伴い不要となった機能を削除し、機能間の再接続を行うことです。また、性能向上を目的とした複数の機能に対する負荷分散を行う状況で、負荷に応じて機能を削除する場合もあります。
　（以下、略）」
Ｃ．「４．動的再構成可能なネットワークノードアーキテクチャ」の欄
「本章では、動的再構成を可能とするネットワークノードアーキテクチャについて紹介します。図３に、動的再構成可能なネットワークノードアーキテクチャについて示します。
本アーキテクチャは、ネットワーク向けマルチコアプロセッサと汎用サーバをフロースイッチで結合したものです。フロースイッチには、データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用します。
　
動的再構成可能なネットワークノードは、１）受信したパケットに対して、適用すべき処理を判定するフロー識別処理、２）処理を構成する機能を実行するプロセッシング資源、３）機能間の柔軟な接続を実現するスイッチ機能（フロースイッチ、コア間スイッチ、仮想スイッチ（vswitchとも呼びます））、４）処理を機能の接続として管理し、ノードの資源管理と連携して機能配備と接続制御を行うノード管理から構成されます。
　図４に、提案するネットワークノードの動作フローを示します。
ノードが提供する処理は、機能の接続である処理フローとして管理されます。各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられます。機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録されます。フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されています。処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生します。ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定を行います。
　図４に示す例では、
処理フローは機能Ａ、Ｂ、Ｃの結合で構成されています。処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録されます。ネットワークノードにおいて、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、機能Ａ、Ｂ、Ｃの順番で処理が実行されます。
　図４では、フローテーブルは、コア間スイッチとフローテーブルと結合し仮想スイッチを統合したスイッチ機能に対するものとして記載していますが、実際には各スイッチのフローテーブルの情報に展開されて設定されています。（以下、略）」
　上記記載（特に下線部）及び図３、図４によれば、引用文献１には、以下の発明（以下、「引用発明１」という。）が記載されているといえる。
「１）受信したパケットに対して、適用すべき処理を判定するフロー識別処理、２）処理を構成する機能を実行するプロセッシング資源、３）機能間の柔軟な接続を実現するスイッチ機能（フロースイッチ（データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用する。））、４）処理を機能の接続として管理し、ノードの資源管理と連携して機能配備と接続制御を行うノード管理から構成される、動的再構成可能なネットワークノードであって、
　ネットワークノードが提供する処理は、機能の接続である処理フローとして管理され、各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられ、機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録され、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されており、処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生し、ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定を行うものであり、
　処理フローは機能の結合で構成され、処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録され、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、決定された処理が実行される、動的再構成可能なネットワークノード。」
２　引用文献２について
　同じく、原査定の拒絶理由に引用された引用文献２には、図面とともに次の事項が記載されている。
「【０００２】
　現代の
電気通信システムは、ポリシー及び課金制御（ＰＣＣ）アーキテクチャを組み込むことができる。ＰＣＣアーキテクチャは、３Ｇ電気通信システムを通じてユーザ機器であるＵＥによって確立されるＩＰ−ＣＡＮセッションにおけるパケットフロー群に関して、３ＧＰＰ  ＴＳ  ２３．２０３に記載されている。特定のアーキテクチャは、ポリシー及び課金ルール機能（ＰＣＲＦ）と、ポリシー及び課金執行機能（ＰＣＥＦ）を備えている。ＰＣＲＦはポリシー決定ポイント（ＰＤＰ）あるいはポリシーサーバ（ＰＳ）として動作し、かつＰＣＥＦはポリシー執行ポイント（ＰＥＰ）として動作する。ＰＣＲＦは、スタンドアローンノードとして実現することができる一方で、汎用パケット無線サービス（ＧＰＲＳ）コアネットワーク内のＧＰＲＳゲートウェイサポートノード（ＧＧＳＮ）のようなアクセスゲートウェイに一緒に配置されていることが好ましい。
【０００３】
　
ユーザ機器（ＵＥ）がデータセッションを開始する場合、ＩＰアドレスが適切なＡＧによって割り当てられる。ＡＧはこのＩＰアドレスを、例えば、ＮＡＩ、ＩＭＳＩ、あるいはＭＳＩＳＤＮとともに、ＰＳへ提供し、一方で、ＰＳはＡＧにデータセッションに適用されるべきポリシールール群のセットをダウンロードする。ＵＥが（最終）アプリケーション機能（ＡＦ）と通信する場合、ＡＦはセッション詳細をＰＳへ提供する。ＵＥが続いてＡＦによって提供されるサービスに対するリソース群をリクエストする場合、ＰＳはＡＧに、ＡＦによって提供されるセッション詳細に基づく更なるポリシールール群のセットをダウンロードする。３ＧＰＰネットワークでは、ＡＦはポリシー呼セッション制御機能であるＰ−ＣＳＣＦであっても良く、あるいは、ＡＧを通じてＩＰ−ＣＡＮセッション（群）を介するベアラ（群）セットアップを介してアプリケーション通信をＵＥと確立する任意の種類のアプリケーションサーバであっても良い。
【０００４】
　
典型的には、ポリシールールは、セッションを記述する５−タプルベクトルを備える（即ち、ｏｒｉｇ  ＩＰ−ａｄｄｒ／ｐｏｒｔ（発信元ＩＰアドレス／ポート）、ｄｅｓｔ  ＩＰ−ａｄｄｒ／ｐｏｒｔ（宛先ＩＰアドレス／ポート）、プロトコル−ＴＣＰ／ＵＤＰ）。ＰＣＥＦは、関連するタプル群を検出して、ルール群を適用するためにパケット群を検査する。
【０００５】
　より詳細なレベルでのパケット群の検査、いわゆる、詳細パケット検査（ＤＰＩ（Deep Packet Inspection））を可能であるが、より多くの時間とリソースを消費することは明らかであり、いくつかのサービスに対しては不必要である場合がある。例えば、オペレータは、「ピアツーピア」サービス群にＰＣＣルール群を適用することに関心がある場合があるが、他のインターネットベースのサービス群には関心がない場合もあるからである。ＤＰＩは、また、課金目的のために採用することができる。典型的には、ＤＰＩ機能群は受動素子群である。これは、それらがＩＰパケット群を「傍受」するだけであって、それらを操作することはないことを意味する。ここで、アップリンク方向（ＵＬ）における発信ＩＰパケット群がゲートウェアによって割り当てられるユーザＩＰアドレスを含んでいる場合、ダウンリンク（ＤＬ）における着信ＩＰパケット群はＡＧに直接転送されることになり、これによって、ＤＰＩノードの制御機能をスキップする。
【０００６】
　解決策としては、ネットワークアドレストランスレータ（ＮＡＴ）と協働するＤＰＩノードを実装することである。このようなアーキテクチャ（３ＧＰＰ  ＴＳ  ２３．２０３）が図１に示される。ＤＰＩは「Ｇｘ」インタフェースを実装して、そうすることで、
セッションが開始される場合にＰＳと通信し、
ＡＧはＰＳから、パケットがＮＡＴへ送信されるべきかあるいは適切なＡＦに向けて直接送信されるべきかについて（例えば、標準のルーティングテーブル群を使用して）のルール群を受信する。これは、例えば、１つのサービスに関連するパケット群をＮＡＴへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なＡＦ（図１の例ではＡＦ１）へ直接へ送信させることを可能にする。
【０００７】
　
ＤＰＩ要素に向けての所与のトラフィックのサブセットを転送するための決定は、ＰＳにおけるポリシー群のセットを評価することによって行うことができる。この決定は、例えば、プロトコル、ＴＣＰ／ＵＤＰポート、発信元／宛先ＩＰアドレス、ＲＡＴタイプ、加入者情報、ＱｏＳ情報及びサービス提供ネットワークに基づくことができる。
　上記記載（特に下線部）及び図１によれば、引用文献２には、以下の技術的事項が記載されているといえる。
「ユーザ機器（ＵＥ）がデータセッションを開始する場合、ＩＰアドレスが適切なアクセスゲートウェイＡＧによって割り当てられ、ＡＧはこのＩＰアドレスをポリシーサーバＰＳ（ＰＣＲＦ）へ提供し、ＰＳはＡＧにデータセッションに適用されるべきポリシールール群のセットをダウンロードし、ＵＥが（最終）アプリケーション機能（ＡＦ）と通信する場合、ＡＦはセッション詳細をＰＳへ提供し、ＵＥが続いてＡＦによって提供されるサービスに対するリソース群をリクエストする場合、ＰＳはＡＧに、ＡＦによって提供されるセッション詳細に基づく更なるポリシールール群のセットをダウンロードするポリシー及び課金制御（ＰＣＣ）アーキテクチャを組み込んだ電気通信システムであって、
　ＡＦはＡＧを通じてＩＰ−ＣＡＮセッション（群）を介するベアラ（群）セットアップを介してアプリケーション通信をＵＥと確立する任意の種類のアプリケーションサーバであってよく、
　ポリシールールは、セッションを記述する５−タプルベクトルを備え（即ち、ｏｒｉｇ  ＩＰ−ａｄｄｒ／ｐｏｒｔ（発信元ＩＰアドレス／ポート）、ｄｅｓｔ  ＩＰ−ａｄｄｒ／ｐｏｒｔ（宛先ＩＰアドレス／ポート）、プロトコル−ＴＣＰ／ＵＤＰ）、ポリシー及び課金執行機能（ＰＣＥＦ）は、関連するタプル群を検出して、ルール群を適用するためにパケット群を検査するものであり、
　ＡＧは、セッションが開始される場合にＰＳと通信し、ＰＳから、パケットがＮＡＴへ送信されるべきかあるいは適切なＡＦに向けて直接送信されるべきかについて（例えば、標準のルーティングテーブル群を使用して）のルール群を受信し、例えば、１つのサービスに関連するパケット群をＮＡＴへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なＡＦへ直接へ送信させることを可能にし、
　ＤＰＩ要素に向けての所与のトラフィックのサブセットを転送するための決定は、ＰＳにおけるポリシー群のセットを評価することによって行うことができ、この決定は、例えば、プロトコル、ＴＣＰ／ＵＤＰポート、発信元／宛先ＩＰアドレス、ＲＡＴタイプ、加入者情報、ＱｏＳ情報及びサービス提供ネットワークに基づくことができる、電気通信システム。」
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明１とを対比する。
（ア）引用発明１の「電気通信システム」と本願発明１の「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能（ＰＣＲＦ）のポリシー情報またはＰＣＲＦによって得られるポリシー情報を用いるシステム」とは、「電気通信システム」である点では共通するといえる。
（イ）引用発明１の「受信したパケットに対して、適用すべき処理」の「処理を構成する機能を実行するプロセッシング資源」は、「資源管理と連携して仮想マシンやプロセッサコア」であるが、各機能が割り当てられるから、本願発明１の「ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワークノード」と、「パケットを処理するのに必要とされるアアプリケーションをホストする０以上のネットワーク機能」である点では共通するといえる。
（ウ）引用発明１の「ノード管理部」は、「管理情報の更新を受けて、ノード内の機能」を割り当てているから、本願発明１の「前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワークノードを識別するためのポリシーエンジン」と、「パケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワーク機能を識別するためのエンジン」である点では共通するといえる。
（エ）引用発明１の「処理フロー管理情報」は、「処理フローは機能の結合で構成され、処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録され、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、決定された処理が実行される」から、本願発明１の「セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも１つの構成可能なネットワークエレメントを構成するための命令」と、「パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能のうちのいずれかにパケットを転送するように、または、パケットを処理するのに必要なものとしては識別されなかったネットワーク機能の全てをバイパスするように、少なくとも１つの構成可能なネットワークエレメントを構成するための命令」である点では共通するといえる。
（オ）引用発明１の「ノード管理部」は、「機能の接続である処理フロー」を管理しているから、本願発明１の「少なくとも１つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータ」に対応しているといえる。
（カ）引用発明１の「機能間の柔軟な接続を実現するスイッチ機能（フロースイッチ（データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用する。））、コア間スイッチ、仮想スイッチ」は、本願発明１の「ＯｐｅｎＦｌｏｗコンパチブルスイッチ」とは、「スイッチ機能」である点では共通するといえる。
（キ）引用発明１の「処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、」「フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納され」ている構成は、本願発明１の「少なくとも１つの構成可能なネットワークエレメントを構成するための命令」が、「ベアラセッションにおけるパケットを特定するためのパラメータを含むＯｐｅｎＦｌｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第１ポートを識別するポート識別子およびセッション識別子」を有し、「前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、当該実行する命令は、ＯｐｅｎＦｌｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第２ポートを介して出力するように指示」する構成と、「少なくとも１つの構成可能なネットワークエレメントを構成するための命令」が、「パケットを特定するためのパラメータを含むコマンドと、一致するパケットに対する処理を実行する命令を含み」、「前記実行する命令は、前記一致するパケットの転送先であるネットワーク機能の指定を含み、当該実行する命令は、スイッチ機能に、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能へ転送するように、当該一致するパケットを前記指定のネットワーク機能に出力するように指示」する構成である点では共通するといえる。
　したがって、本願発明１と引用発明１との間には、次の一致点及び相違点があるといえる。
（一致点）
「電気通信システムであって、
　パケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワーク機能を識別するためのエンジンと、
　パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能のうちのいずれかにパケットを転送するように、または、パケットを処理するのに必要なものとしては識別されなかったネットワーク機能の全てをバイパスするように、少なくとも１つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータと、を含み、
　前記少なくとも１つの構成可能なネットワークエレメントは、スイッチ機能を含み、
　少なくとも１つの構成可能なネットワークエレメントを構成するための命令が、パケットを特定するためのパラメータを含むコマンドと、一致するパケットに対する処理を実行する命令を含み、前記実行する命令は、前記一致するパケットの転送先であるネットワーク機能の指定を含み、
　当該実行する命令は、スイッチ機能に、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能へ転送するように、当該一致するパケットを前記指定のネットワーク機能に出力するように指示する、システム。」
（相違点１）
　本願発明１の「電気通信システム」が、「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能（ＰＣＲＦ）のポリシー情報またはＰＣＲＦによって得られるポリシー情報を用いるシステム」であるのに対し、引用発明１は、そのようなシステムではない点。
（相違点２）
　本願発明１は、「ＰＣＲＦ」を含み、前記ＰＣＲＦは、「前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする０以上のネットワークノードを識別するためのポリシーエンジン」と「アプリケーションルーティングコンフィギュレータ」を含むものであるのに対し、引用発明１は、上記のような「ＰＣＲＦ」を含むものではない点。
（相違点３）
　本願発明１の「パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能」が、「ネットワークノード」であるのに対し、引用発明１は、仮想マシンやプロセッサコアである点。
（相違点４）
　本願発明１は、「アプリケーションルーティングコンフィギュレータ」が「セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記ＰＣＲＦによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも１つの構成可能なネットワークエレメントを構成するための命令を与えるための」ものであるのに対し、引用発明１は、「ネットワークノードが提供する処理は、機能の接続である処理フローとして管理され、各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられ、機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録され、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されており、処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生し、ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定」を行い、「受信パケットは、フロー識別処理により適用する処理が決定され、フローテーブルをもとにフロースイッチで転送され、機能の処理が実行される」ものであり、上記のような構成ではない点。
（相違点５）
　本願発明１は、「前記ＰＣＲＦ内に統合されたＯｐｅｎＦｌｏｗコンパチブルコントローラ」を含むものであり、「ＯｐｅｎＦｌｏｗコンパチブルスイッチ」が「それぞれが他の各前記ネットワークノードに対応し、対応のネットワークノードから入来するパケットを受付ける第１ポートと、それぞれが他の各前記ネットワークノードに関連付けられて、関連付けられたネットワークノードへパケットを出力する第２ポートと」を有し、「前記少なくとも１つの構成可能なネットワークエレメントを構成するための命令」は、「ベアラセッションにおけるパケットを特定するためのパラメータを含むＯｐｅｎＦｌｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第１ポートを識別するポート識別子およびセッション識別子」を有し、「前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、当該実行する命令は、ＯｐｅｎＦｌｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第２ポートを介して出力するように指示」するものであり、「前記一致するパケットは、前記ＯｐｅｎＦｌｏｗコンパチブルスイッチに入来するパケットであって、当該入来パケットは前記パラメータのポート識別子により識別される第１ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケットである」のに対し、引用発明１の「スイッチ機能」は、ＯｐｅｎＦｌｏｗコンパチブルコントローラがＰＣＲＦ内に統合されておらず、また、「ＯｐｅｎＦｌｏｗ技術を採用した」スイッチではあるものの、文言上「ＯｐｅｎＦｌｏｗコンパチブルスイッチ」とは特定されておらず、さらに、上記のような第１ポートと第２ポートは特定されておらず、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されているが、「第１ポートを識別するポート識別子およびセッション識別子」を格納することは特定されておらず、フローテーブルには機能間の接続情報をもとにしたフロースイッチの転送情報が登録されているが、「ポート識別子により識別される第１ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケット」を「指定のネットワークノードに関連付けられた前記第２ポートを介して出力するように指示」することは特定されていない点。
（２）相違点についての判断
　事案に鑑みて先ず相違点５について検討する。
　引用文献２に記載された技術的事項は、「アクセスゲートウェイＡＧが、セッションが開始される場合にＰＳ（ＰＣＲＦ）と通信し、ＰＳ（ＰＣＲＦ）から、パケットがＮＡＴへ送信されるべきかあるいは適切なアプリケーション機能ＡＦに向けて直接送信されるべきかについて（例えば、標準のルーティングテーブル群を使用して）のルール群を受信し、例えば、１つのサービスに関連するパケット群をＮＡＴへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なＡＦへ直接へ送信させることを可能にし、ＤＰＩ要素に向けての所与のトラフィックのサブセットを転送するための決定は、ＰＳ（ＰＣＲＦ）におけるポリシー群のセットを評価することによって行うことができ、この決定は、例えば、プロトコル、ＴＣＰ／ＵＤＰポート、発信元／宛先ＩＰアドレス、ＲＡＴタイプ、加入者情報、ＱｏＳ情報及びサービス提供ネットワークに基づくことができる」ものであるが、上記相違点５に係る本願発明１のＯｐｅｎＦｌｏｗコンパチブルスイッチに関する具体的な構成は記載されておらず、示唆されてもいない。
　また、上記相違点５に係る本願発明１の構成が、本願優先日前に周知技術であったともいえない。
　したがって、上記相違点１〜４を検討するまでもなく、本願発明１は、当業者であっても、引用発明１及び引用文献２記載の技術的事項に基づいて容易に発明をすることができたとはいえない。
２．本願発明２−８について
　本願発明２−８は、上記相違点５に係る本願発明１の構成と同じ構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明に基づいて容易に発明できたものとはいえない。
３．本願発明９、１０について
　本願発明９、１０は、上記相違点５に係る本願発明１の構成と同様の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明に基づいて容易に発明できたものとはいえない。
第５　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。