• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1344262
審判番号 不服2017-8708  
総通号数 227 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-11-30 
種別 拒絶査定不服の審決 
審判請求日 2017-06-14 
確定日 2018-10-02 
事件の表示 特願2015-555185「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシー情報を用いる方法、システムおよびコンピュータ読取可能媒体」拒絶査定不服審判事件〔平成26年 7月31日国際公開、WO2014/116465、平成28年 3月22日国内公表、特表2016-508690、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本願は、2014年(平成26年)1月14日(パリ条約による優先権主張外国庁受理2013年1月24日、米国)を国際出願日とする出願であって、その手続きの経緯は以下のとおりである。

平成28年 8月18日付け:拒絶理由通知書
平成28年10月12日 :意見書、手続補正書の提出
平成28年12月 9日付け:拒絶理由(最後の拒絶理由)通知書、
平成29年 1月31日 :意見書、手続補正書の提出
平成29年 2月 6日付け:平成29年1月31日の手続補正について
の補正の却下の決定、拒絶査定
平成29年 6月14日 :審判請求書、手続補正書の提出

第2 平成29年2月6日付けの補正の却下の決定及び原査定の概要

1 平成29年2月6日付けの補正の却下の決定の概要は、以下のとおりである。

平成29年1月31日付けの補正は、特許請求の範囲の限定的減縮を目的とするものであるが、当該補正後の本願請求項1-10に係る発明は、引用文献1、2に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであり、独立特許要件を満たさないから、平成29年1月31日付けの補正は却下すべきものである。

＜引用文献等一覧＞
1.林 偉夫、上野 洋史,将来のクラウド基盤技術を支える研究開発,
NEC技報 第63巻 第2号,日本電気株式会社,
2010年4月23日,ｐｐ.124-128
2.特表2012-511846号公報

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

本願請求項1-10に係る発明は、上記引用文献1、2に基づいて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

第3 本願発明

本願の請求項1-10に係る発明(以下、それぞれ「本願発明1」-「本願発明10」という。)は、平成29年6月14日付けで手続補正された特許請求の範囲の請求項1-10に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能(PCRF)のポリシー情報またはPCRFによって得られるポリシー情報を用いるシステムであって、
PCRFを含み、前記PCRFは、
前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワークノードを識別するためのポリシーエンジンと、
セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも1つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータと、を含み、
前記アプリケーションルーティングコンフィギュレータは、前記PCRF内に統合されたOｐenFlｏｗコンパチブルコントローラを含み、
前記少なくとも1つの構成可能なネットワークエレメントは、OｐenFlｏｗコンパチブルスイッチを含み、
前記OｐenFlｏｗコンパチブルスイッチは、
それぞれが他の各前記ネットワークノードに対応し、対応のネットワークノードから入来するパケットを受付ける第1ポートと、
それぞれが他の各前記ネットワークノードに関連付けられて、関連付けられたネットワークノードへパケットを出力する第2ポートと、を有し、
前記少なくとも1つの構成可能なネットワークエレメントを構成するための命令は、ベアラセッションにおけるパケットを特定するためのパラメータを含むOｐenFlｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第1ポートを識別するポート識別子およびセッション識別子を有し、前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、
当該実行する命令は、OｐenFlｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第2ポートを介して出力するように指示し、前記一致するパケットは、前記OｐenFlｏｗコンパチブルスイッチに入来するパケットであって、当該入来パケットは前記パラメータのポート識別子により識別される第1ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケットである、システム。」

本願発明2-8は、本願発明1を減縮した発明である。
本願発明9,10は、それぞれ本願発明1に対応する方法の発明、コンピュータ読取可能なプログラムの発明であり、本願発明1とカテゴリ表現が異なるだけの発明である。

第3 引用文献・引用発明等

1 引用文献1について

原査定の拒絶理由に引用された引用文献1には、図面とともに次の事項が記載されている。(下線は当審により注目する点に付与した。以下、同様。)

A.「2.1従来のネットワークノードやシステムの課題」の欄
「図1に、従来のデータセンターネットワークの構成を例として、ネットワークノード及びシステムの課題について示します。
初めに、本稿で使用する用語について説明します。ネットワークノードは、ルータやスイッチなどの通信機器に加えて、帯域制御装置や負荷分散装置などのアプライアンス機器など、ネットワークを構成する要素と定義します。ネットワークシステムは、ネットワークノードで構成されるシステムのことであり、一例として、図に示すデータセンターネットワークがあります。
まず、ネットワークノードの課題について説明します。従来のネットワークノードは、通信回線の最大速度に対応できるように設計されています。そのため、実際のトラフィックが少ない場合でも、最大性能をもったノードを配備する必要があり、設備コストが増大するという課題があります。
また、通信ニーズの多様化に合わせてネットワークノードの柔軟性を確保するために、汎用サーバでネットワーク処理を実現することが考えられますが、多くの通信処理にとっては、汎用サーバだけでは性能や機能が不足しており、特に性能の面では、要求性能の達成が難しいという課題があります。また、汎用サーバにおける通信処理は、電力効率が悪いという課題もあります。
・・・(中略)・・・
次に、ネットワークシステム構成における課題について説明します。クラウドごとの異なる多様な要件を満たすため、既存技術では、負荷分散装置、ファイアウォールなどのミドルボックスとサーバ、ストレージをネットワーク機器で接続して対応することが考えられます。しかしながら、このようなシステムは、構成変更の自由度が低いという課題があります。例えば、既存のネットワークにミドルボックスの導入を行う場合、ネットワークの物理的な接続や設定を変更する必要があります。そのため、ネットワークへの影響を事前に考慮してネットワークの再設計を行い、サービス断を伴って構成を変更することが一般的です。物理的な接続変更を伴うため人為的なミスが入る可能性もあります。このような理由から、従来のネットワークシステムは、要件変更が頻繁に発生するような状況に対応することが困難であるという課題があります。」

B.「3.ネットワークシステムにおける動的再構成」の欄
「動的再構成は、前述したネットワークシステムの要件に対応する技術です。分解された機能の結合で処理を表現した場合、ネットワークシステムの動的再構成は、図2に示すような機能の追加、削除、移動、接続の変更という4つの要素があります。
(1)機能の追加
機能の追加は、新たな処理の提供や処理内容の変更要求を受けて、新たな機能を追加して機能間の再接続を行うことです。また、性能向上を目的として機能のコピーを作成して負荷分散を行うこともあります。
(2)機能の削除
機能の削除は、要件などの変更に伴い不要となった機能を削除し、機能間の再接続を行うことです。また、性能向上を目的とした複数の機能に対する負荷分散を行う状況で、負荷に応じて機能を削除する場合もあります。
(以下、略)」

C.「4.動的再構成可能なネットワークノードアーキテクチャ」の欄
「本章では、動的再構成を可能とするネットワークノードアーキテクチャについて紹介します。図3に、動的再構成可能なネットワークノードアーキテクチャについて示します。本アーキテクチャは、ネットワーク向けマルチコアプロセッサと汎用サーバをフロースイッチで結合したものです。フロースイッチには、データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用します。
動的再構成可能なネットワークノードは、1)受信したパケットに対して、適用すべき処理を判定するフロー識別処理、2)処理を構成する機能を実行するプロセッシング資源、3)機能間の柔軟な接続を実現するスイッチ機能(フロースイッチ、コア間スイッチ、仮想スイッチ(vswitchとも呼びます))、4)処理を機能の接続として管理し、ノードの資源管理と連携して機能配備と接続制御を行うノード管理から構成されます。提案するネットワークノードは、処理を機能の結合で管理し、各機能をプロセッシング資源に割り当て、機能間の接続を制御することで、動的再構成を実現します。各機能は、汎用サーバ上で動作する仮想マシン(VM)やネットワーク向けマルチコアプロセッサのプロセッサコアでソフトウェアとして動作します。
図4に、提案するネットワークノードの動作フローを示します。ノードが提供する処理は、機能の接続である処理フローとして管理されます。各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられます。機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録されます。フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されています。処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生します。ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定を行います。
図4に示す例では、処理フローは機能A、B、Cの結合で構成されています。処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録されます。ネットワークノードにおいて、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、機能A、B、Cの順番で処理が実行されます。
図4では、フローテーブルは、コア間スイッチとフローテーブルと結合し仮想スイッチを統合したスイッチ機能に対するものとして記載していますが、実際には各スイッチのフローテーブルの情報に展開されて設定されています。(以下、略)」

上記記載(特に下線部)及び図3、図4によれば、引用文献1には、以下の発明(以下、「引用発明1」という。)が記載されているといえる。

「1)受信したパケットに対して、適用すべき処理を判定するフロー識別処理、2)処理を構成する機能を実行するプロセッシング資源、3)機能間の柔軟な接続を実現するスイッチ機能(フロースイッチ(データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用する。))、4)処理を機能の接続として管理し、ノードの資源管理と連携して機能配備と接続制御を行うノード管理から構成される、動的再構成可能なネットワークノードであって、
ネットワークノードが提供する処理は、機能の接続である処理フローとして管理され、各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられ、機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録され、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されており、処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生し、ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定を行うものであり、
処理フローは機能の結合で構成され、処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録され、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、決定された処理が実行される、動的再構成可能なネットワークノード。」

2 引用文献2について

同じく、原査定の拒絶理由に引用された引用文献2には、図面とともに次の事項が記載されている。

「【0002】
現代の電気通信システムは、ポリシー及び課金制御(PCC)アーキテクチャを組み込むことができる。PCCアーキテクチャは、3G電気通信システムを通じてユーザ機器であるUEによって確立されるIP-CANセッションにおけるパケットフロー群に関して、3GPP TS 23.203に記載されている。特定のアーキテクチャは、ポリシー及び課金ルール機能(PCRF)と、ポリシー及び課金執行機能(PCEF)を備えている。PCRFはポリシー決定ポイント(PDP)あるいはポリシーサーバ(PS)として動作し、かつPCEFはポリシー執行ポイント(PEP)として動作する。PCRFは、スタンドアローンノードとして実現することができる一方で、汎用パケット無線サービス(GPRS)コアネットワーク内のGPRSゲートウェイサポートノード(GGSN)のようなアクセスゲートウェイに一緒に配置されていることが好ましい。関連するアーキテクチャは、3GPP2ネットワーク群とTISPAN次世代ネットワーク群に対して提供される。
【0003】
ユーザ機器(UE)がデータセッションを開始する場合、IPアドレスが適切なAGによって割り当てられる。AGはこのIPアドレスを、例えば、NAI、IMSI、あるいはMSISDNとともに、PSへ提供し、一方で、PSはAGにデータセッションに適用されるべきポリシールール群のセットをダウンロードする。UEが(最終)アプリケーション機能(AF)と通信する場合、AFはセッション詳細をPSへ提供する。UEが続いてAFによって提供されるサービスに対するリソース群をリクエストする場合、PSはAGに、AFによって提供されるセッション詳細に基づく更なるポリシールール群のセットをダウンロードする。3GPPネットワークでは、AFはポリシー呼セッション制御機能であるP-CSCFであっても良く、あるいは、AGを通じてIP-CANセッション(群)を介するベアラ(群)セットアップを介してアプリケーション通信をUEと確立する任意の種類のアプリケーションサーバであっても良い。
【0004】
典型的には、ポリシールールは、セッションを記述する5-タプルベクトルを備える(即ち、ｏｒig IP-addｒ/ｐｏｒｔ(発信元IPアドレス/ポート)、deｓｔ IP-addｒ/ｐｏｒｔ(宛先IPアドレス/ポート)、プロトコル-TCP/UDP)。PCEFは、関連するタプル群を検出して、ルール群を適用するためにパケット群を検査する。しかしながら、この技術は、パケット群の制限のある(粗)解析のみを許容している、これは、これらの5つのIPヘッダ以外のパケット検査を許容していないからである、例えば、ペイロードデータの検査を許容していないからである。
【0005】
より詳細なレベルでのパケット群の検査、いわゆる、詳細パケット検査(DPI(Deep Packet Inspection))を可能であるが、より多くの時間とリソースを消費することは明らかであり、いくつかのサービスに対しては不必要である場合がある。例えば、オペレータは、「ピアツーピア」サービス群にPCCルール群を適用することに関心がある場合があるが、他のインターネットベースのサービス群には関心がない場合もあるからである。DPIは、また、課金目的のために採用することができる。典型的には、DPI機能群は受動素子群である。これは、それらがIPパケット群を「傍受」するだけであって、それらを操作することはないことを意味する。ここで、アップリンク方向(UL)における発信IPパケット群がゲートウェアによって割り当てられるユーザIPアドレスを含んでいる場合、ダウンリンク(DL)における着信IPパケット群はAGに直接転送されることになり、これによって、DPIノードの制御機能をスキップする。
【0006】
解決策としては、ネットワークアドレストランスレータ(NAT)と協働するDPIノードを実装することである。このようなアーキテクチャ(3GPP TS 23.203)が図1に示される。DPIは「Gｘ」インタフェースを実装して、そうすることで、セッションが開始される場合にPSと通信し、かつそのPSからポリシールール群を受信する。逆に、AGはPSから、パケットがNATへ送信されるべきかあるいは適切なAFに向けて直接送信されるべきかについて(例えば、標準のルーティングテーブル群を使用して)のルール群を受信する。これは、例えば、1つのサービスに関連するパケット群をNATへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なAF(図1の例ではAF1)へ直接へ送信させることを可能にする。NATの機能は、発信元IPアドレスを、発信元アドレスにマップする新規の(「NAT変換済(NATed)」)IPアドレスへ変更することによって、UEによって送信されるIPパケット群を修正することである。NAT変換済アドレスは、NATによって「所有される」所与のIPアドレス範囲から選択される。NATは、修正したパケット群を検査用のDPIノードへ転送する。DPIは、そのパケット群を割り当てられたAF(図1の例におけるAF2)へ転送する。DPIノードに向けて割り当てられたIPアドレス範囲へ転送するために、ダウンリンク方向における着信トラフィックに対してエッジIPルータ(群)を構成設定することによって、この方法は、送信元UEへ宛先ノードによって送信されるパケット群が最初にDPIへ転送されることを補償する。つまり、発信パケット群と着信パケット群の両方のDPIが保証される一方で、同時に、不必要となるパケット群についてDPIを実行するための必要性を回避する。その結果としての、トラフィックフロー群、NAT変換及び非NAT変換が図2で示される。
【0007】
DPI要素に向けての所与のトラフィックのサブセットを転送するための決定は、PSにおけるポリシー群のセットを評価することによって行うことができる。この決定は、例えば、プロトコル、TCP/UDPポート、発信元/宛先IPアドレス、RATタイプ、加入者情報、QｏS情報及びサービス提供ネットワークに基づくことができる。」

上記記載(特に下線部)及び図1によれば、引用文献2には、以下の技術的事項が記載されているといえる。

「ユーザ機器(UE)がデータセッションを開始する場合、IPアドレスが適切なアクセスゲートウェイAGによって割り当てられ、AGはこのIPアドレスをポリシーサーバPS(PCRF)へ提供し、PSはAGにデータセッションに適用されるべきポリシールール群のセットをダウンロードし、UEが(最終)アプリケーション機能(AF)と通信する場合、AFはセッション詳細をPSへ提供し、UEが続いてAFによって提供されるサービスに対するリソース群をリクエストする場合、PSはAGに、AFによって提供されるセッション詳細に基づく更なるポリシールール群のセットをダウンロードするポリシー及び課金制御(PCC)アーキテクチャを組み込んだ電気通信システムであって、
AFはAGを通じてIP-CANセッション(群)を介するベアラ(群)セットアップを介してアプリケーション通信をUEと確立する任意の種類のアプリケーションサーバであってよく、
ポリシールールは、セッションを記述する5-タプルベクトルを備え(即ち、ｏｒig IP-addｒ/ｐｏｒｔ(発信元IPアドレス/ポート)、deｓｔ IP-addｒ/ｐｏｒｔ(宛先IPアドレス/ポート)、プロトコル-TCP/UDP)、ポリシー及び課金執行機能(PCEF)は、関連するタプル群を検出して、ルール群を適用するためにパケット群を検査するものであり、
AGは、セッションが開始される場合にPSと通信し、PSから、パケットがNATへ送信されるべきかあるいは適切なAFに向けて直接送信されるべきかについて(例えば、標準のルーティングテーブル群を使用して)のルール群を受信し、例えば、1つのサービスに関連するパケット群をNATへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なAFへ直接へ送信させることを可能にし、
DPI要素に向けての所与のトラフィックのサブセットを転送するための決定は、PSにおけるポリシー群のセットを評価することによって行うことができ、この決定は、例えば、プロトコル、TCP/UDPポート、発信元/宛先IPアドレス、RATタイプ、加入者情報、QｏS情報及びサービス提供ネットワークに基づくことができる、電気通信システム。」

第4 対比・判断

1 本願発明1について

(1)対比
本願発明1と引用発明1とを対比する。

(ア)引用発明1の「電気通信システム」と本願発明1の「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能(PCRF)のポリシー情報またはPCRFによって得られるポリシー情報を用いるシステム」とは、「電気通信システム」である点では共通するといえる。

(イ)引用発明1の「受信したパケットに対して、適用すべき処理」の「処理を構成する機能を実行するプロセッシング資源」は、「資源管理と連携して仮想マシンやプロセッサコア」であるが、各機能が割り当てられるから、本願発明1の「ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワークノード」と、「パケットを処理するのに必要とされるアアプリケーションをホストする0以上のネットワーク機能」である点では共通するといえる。

(ウ)引用発明1の「ノード管理部」は、「管理情報の更新を受けて、ノード内の機能」を割り当てているから、本願発明1の「前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワークノードを識別するためのポリシーエンジン」と、「パケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワーク機能を識別するためのエンジン」である点では共通するといえる。

(エ)引用発明1の「処理フロー管理情報」は、「処理フローは機能の結合で構成され、処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、それぞれのテーブルに登録され、受信パケットは、フロー識別処理により本ノードで適用される処理が決定され、フローテーブルをもとにフロースイッチで転送され、決定された処理が実行される」から、本願発明1の「セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも1つの構成可能なネットワークエレメントを構成するための命令」と、「パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能のうちのいずれかにパケットを転送するように、または、パケットを処理するのに必要なものとしては識別されなかったネットワーク機能の全てをバイパスするように、少なくとも1つの構成可能なネットワークエレメントを構成するための命令」である点では共通するといえる。

(オ)引用発明1の「ノード管理部」は、「機能の接続である処理フロー」を管理しているから、本願発明1の「少なくとも1つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータ」に対応しているといえる。

(カ)引用発明1の「機能間の柔軟な接続を実現するスイッチ機能(フロースイッチ(データ転送と制御部の間のインターフェースにOpenFlow技術を採用したプログラマブルフロースイッチを利用する。))、コア間スイッチ、仮想スイッチ」は、本願発明1の「OｐenFlｏｗコンパチブルスイッチ」とは、「スイッチ機能」である点では共通するといえる。

(キ)引用発明1の「処理フロー管理情報は、適用すべき処理を判断するためのフロー識別処理のテーブルと転送を制御するためのフローテーブルの設定に分解され、」「フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納され」ている構成は、本願発明1の「少なくとも1つの構成可能なネットワークエレメントを構成するための命令」が、「ベアラセッションにおけるパケットを特定するためのパラメータを含むOｐenFlｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第1ポートを識別するポート識別子およびセッション識別子」を有し、「前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、当該実行する命令は、OｐenFlｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第2ポートを介して出力するように指示」する構成と、「少なくとも1つの構成可能なネットワークエレメントを構成するための命令」が、「パケットを特定するためのパラメータを含むコマンドと、一致するパケットに対する処理を実行する命令を含み」、「前記実行する命令は、前記一致するパケットの転送先であるネットワーク機能の指定を含み、当該実行する命令は、スイッチ機能に、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能へ転送するように、当該一致するパケットを前記指定のネットワーク機能に出力するように指示」する構成である点では共通するといえる。

したがって、本願発明1と引用発明1との間には、次の一致点及び相違点があるといえる。

(一致点)
「電気通信システムであって、
パケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワーク機能を識別するためのエンジンと、
パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能のうちのいずれかにパケットを転送するように、または、パケットを処理するのに必要なものとしては識別されなかったネットワーク機能の全てをバイパスするように、少なくとも1つの構成可能なネットワークエレメントを構成するための命令を与えるためのアプリケーションルーティングコンフィギュレータと、を含み、
前記少なくとも1つの構成可能なネットワークエレメントは、スイッチ機能を含み、
少なくとも1つの構成可能なネットワークエレメントを構成するための命令が、パケットを特定するためのパラメータを含むコマンドと、一致するパケットに対する処理を実行する命令を含み、前記実行する命令は、前記一致するパケットの転送先であるネットワーク機能の指定を含み、
当該実行する命令は、スイッチ機能に、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能へ転送するように、当該一致するパケットを前記指定のネットワーク機能に出力するように指示する、システム。」

(相違点1)
本願発明1の「電気通信システム」が、「ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシーおよび課金ルール機能(PCRF)のポリシー情報またはPCRFによって得られるポリシー情報を用いるシステム」であるのに対し、引用発明1は、そのようなシステムではない点。

(相違点2)
本願発明1は、「PCRF」を含み、前記PCRFは、「前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、ベアラセッションのパケットを処理するのに必要とされるアプリケーションをホストする0以上のネットワークノードを識別するためのポリシーエンジン」と「アプリケーションルーティングコンフィギュレータ」を含むものであるのに対し、引用発明1は、上記のような「PCRF」を含むものではない点。

(相違点3)
本願発明1の「パケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワーク機能」が、「ネットワークノード」であるのに対し、引用発明1は、仮想マシンやプロセッサコアである点。

(相違点4)
本願発明1は、「アプリケーションルーティングコンフィギュレータ」が「セッションに関連付けられたパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードのうちのいずれかにベアラセッショントラフィックを転送するように、または、セッションに関連付けられたパケットを処理するのに必要なものとしては識別されなかったネットワークノードの全てをバイパスするように、前記PCRFによって維持されるポリシーデータベースに問合わせを行うことで得られるポリシー情報を用いて、少なくとも1つの構成可能なネットワークエレメントを構成するための命令を与えるための」ものであるのに対し、引用発明1は、「ネットワークノードが提供する処理は、機能の接続である処理フローとして管理され、各機能は、資源管理と連携して仮想マシンやプロセッサコアに割り当てられ、機能間の接続情報は、機能配備の結果をもとに、ノード内部のフロースイッチの転送情報に変換され、フローテーブルへ登録され、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されており、処理フロー管理情報は、サービスの要件の変更に伴い、更新が発生し、ノード管理部は、管理情報の更新を受けて、ノード内の機能割り当てや機能間接続の再設定」を行い、「受信パケットは、フロー識別処理により適用する処理が決定され、フローテーブルをもとにフロースイッチで転送され、機能の処理が実行される」ものであり、上記のような構成ではない点。

(相違点5)
本願発明1は、「前記PCRF内に統合されたOｐenFlｏｗコンパチブルコントローラ」を含むものであり、「OｐenFlｏｗコンパチブルスイッチ」が「それぞれが他の各前記ネットワークノードに対応し、対応のネットワークノードから入来するパケットを受付ける第1ポートと、それぞれが他の各前記ネットワークノードに関連付けられて、関連付けられたネットワークノードへパケットを出力する第2ポートと」を有し、「前記少なくとも1つの構成可能なネットワークエレメントを構成するための命令」は、「ベアラセッションにおけるパケットを特定するためのパラメータを含むOｐenFlｏｗコンパチブルコマンドと、一致するパケットに対する処理を実行する命令を含み、前記パラメータは、前記第1ポートを識別するポート識別子およびセッション識別子」を有し、「前記実行する命令は、前記一致するパケットの転送先であるネットワークノードの指定を含み、当該実行する命令は、OｐenFlｏｗコンパチブルスイッチに、一致するパケットを処理するのに必要なものとして識別されたアプリケーションをホストするものとして識別されるネットワークノードへ転送するように、当該一致するパケットを前記指定のネットワークノードに関連付けられた前記第2ポートを介して出力するように指示」するものであり、「前記一致するパケットは、前記OｐenFlｏｗコンパチブルスイッチに入来するパケットであって、当該入来パケットは前記パラメータのポート識別子により識別される第1ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケットである」のに対し、引用発明1の「スイッチ機能」は、OｐenFlｏｗコンパチブルコントローラがPCRF内に統合されておらず、また、「OｐenFlｏｗ技術を採用した」スイッチではあるものの、文言上「OｐenFlｏｗコンパチブルスイッチ」とは特定されておらず、さらに、上記のような第1ポートと第2ポートは特定されておらず、フロー識別部のテーブルには、ユーザを識別し、適用するサービスを判断する情報が格納されているが、「第1ポートを識別するポート識別子およびセッション識別子」を格納することは特定されておらず、フローテーブルには機能間の接続情報をもとにしたフロースイッチの転送情報が登録されているが、「ポート識別子により識別される第1ポートで受付けされて、および当該入来パケットのセッションタイプが前記パラメータのセッション識別子と一致するパケット」を「指定のネットワークノードに関連付けられた前記第2ポートを介して出力するように指示」することは特定されていない点。

(2)相違点についての判断

事案に鑑みて先ず相違点5について検討する。

引用文献2に記載された技術的事項は、「アクセスゲートウェイAGが、セッションが開始される場合にPS(PCRF)と通信し、PS(PCRF)から、パケットがNATへ送信されるべきかあるいは適切なアプリケーション機能AFに向けて直接送信されるべきかについて(例えば、標準のルーティングテーブル群を使用して)のルール群を受信し、例えば、1つのサービスに関連するパケット群をNATへ転送させることを可能にし、かつ別のサービスに関連するパケット群を適切なAFへ直接へ送信させることを可能にし、DPI要素に向けての所与のトラフィックのサブセットを転送するための決定は、PS(PCRF)におけるポリシー群のセットを評価することによって行うことができ、この決定は、例えば、プロトコル、TCP/UDPポート、発信元/宛先IPアドレス、RATタイプ、加入者情報、QｏS情報及びサービス提供ネットワークに基づくことができる」ものであるが、上記相違点5に係る本願発明1のOｐenFlｏｗコンパチブルスイッチに関する具体的な構成は記載されておらず、示唆されてもいない。

また、上記相違点5に係る本願発明1の構成が、本願優先日前に周知技術であったともいえない。

したがって、上記相違点1?4を検討するまでもなく、本願発明1は、当業者であっても、引用発明1及び引用文献2記載の技術的事項に基づいて容易に発明をすることができたとはいえない。

2.本願発明2-8について

本願発明2-8は、上記相違点5に係る本願発明1の構成と同じ構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明に基づいて容易に発明できたものとはいえない。

3.本願発明9、10について

本願発明9、10は、上記相違点5に係る本願発明1の構成と同様の構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明に基づいて容易に発明できたものとはいえない。

第5 むすび

以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2018-09-19 
出願番号 特願2015-555185(P2015-555185)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 松崎 孝大、速水 雄太  
特許庁審判長 千葉 輝久
特許庁審判官 稲葉 和生
▲吉▼田 耕一
発明の名称 ベアラセッショントラフィックを必要に応じてネットワークノードに転送するためにポリシー情報を用いる方法、システムおよびコンピュータ読取可能媒体  
代理人 特許業務法人深見特許事務所  

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