【事件の表示】
　特願２０１６−５４４３２１「Ｄｉａｍｅｔｅｒ負荷および過負荷情報ならびに仮想化のための方法、システムおよびコンピュータ読取可能媒体」拒絶査定不服審判事件〔平成２７年　３月２６日国際公開、ＷＯ２０１５／０４１７５０、平成２８年１１月２４日国内公表、特表２０１６−５３６９３９、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１４年（平成２６年）７月２９日（パリ条約による優先権主張外国庁受理２０１３年９月２３日、米国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
　平成３０年　７月　９日付け　：拒絶理由通知書
　平成３０年１２月１４日　　　：意見書、手続補正書の提出
　平成３１年　１月　４日付け　：拒絶理由通知書
　平成３１年　４月１５日　　　：意見書の提出
　平成３１年　４月２６日付け　：拒絶査定（以下、「原査定」という。）
　令和　元年　９月１３日　　　：審判請求書の提出
　令和　２年１０月　６日付け　：拒絶理由（以下、「当審拒絶理由」とい　　　　　　　　　　　　　　　　う。）通知書
　令和　３年　１月　７日　　　：意見書、手続補正書の提出
第２　原査定の概要
　原査定（平成３１年　４月２６日付け拒絶査定）の概要は、次のとおりである。
　本願請求項１ないし１５に係る発明は、以下の引用文献ＡないしＤに基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　引用文献等一覧
Ａ．米国特許出願公開第２０１２／０３００６１５号明細書
Ｂ．樋口　毅　他、「待機用リソース制御方式の検討」、電子情報通信学会
　　２０１０年通信ソサイエティ大会講演論文集２、2010年8月31日、p.368
Ｃ．米国特許出願公開第２０１１／００２３０２９号明細書
Ｄ．特表２０１１−５２１３３４号公報
第３　当審拒絶理由の概要
　当審拒絶理由は、概略、次のとおりのものである。
１．（進歩性）本願請求項１ないし１５に係る発明は、以下の引用文献１ないし６に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　引用文献等一覧
１．米国特許出願公開第２０１２／０３００６１５号明細書（原査定の文献Ａ）
２．特開２０１３−９８５９７号公報
３．国際公開第２０１３／０４１１２８号
４．樋口　毅　他、「待機用リソース制御方式の検討」、電子情報通信学会　２０１０年通信ソサイエティ大会講演論文集２、2010年8月31日、p.368（原査定の文献Ｂ）
５．米国特許出願公開第２０１１／００２３０２９号明細書（原査定の文献Ｃ）
６．特表２０１１−５２１３３４号公報（原査定の文献Ｄ）
第４　本願発明
　本願請求項１ないし１５に係る発明は、令和３年１月７日に提出された手続補正書の特許請求の範囲の請求項１ないし１５に記載された事項により特定されるものであると認められるところ、請求項１ないし１５に係る発明（以下、それぞれ「本願発明１」ないし「本願発明１５」という。）は、以下のとおりの発明である（補正箇所に下線を付した）。
「　　【請求項１】
　ネットワーク仮想化を管理するために過負荷情報を使用するための方法であって、
　ハードウェアプロセッサを含む、電気通信ネットワーク内の仮想ネットワークを管理するための仮想化オーケストレータ（ＶＯ）で、
　Diameter過負荷情報を受信することと、
　受信されたDiameter過負荷情報に基づいて、行なうべきネットワーク仮想化動作を判断することと、
　前記Diameter過負荷情報により示された過負荷に応答して、１つ以上のネットワーク仮想化モジュールを用いる電気通信ネットワークにおいて
、
チを
　　【請求項２】
　Diameter過負荷情報を受信することは、複数のDiameterクライアントと複数のDiameterサーバとの間の通信を容易にするためのDiameterエージェントからネットワーク負荷および過負荷情報を受信することを含む、請求項１に記載の方法。
　　【請求項３】
　Diameter過負荷情報を受信することは、ポリシーおよび課金規則機能（ＰＣＲＦ）プラグインモジュール、クラウド管理プラグイン、または情報収集モジュールのうちの少なくとも１つから情報を直接受信することを含む、請求項２に記載の方法。
　　【請求項４】
　Diameter過負荷情報を受信することは、属性値ペア（ＡＶＰ）またはDiameterメッセージを含む情報を受信することを含む、請求項１に記載の方法。
　　【請求項５】
　行なうべきネットワーク仮想化動作を判断することは、前記受信されたDiameter過負荷情報および前記電気通信ネットワークの現在のネットワークトポロジーのステータスを解析して、前記Diameter過負荷情報および前記現在のネットワークトポロジーのステータスに基づいて行なわれるべきネットワーク仮想化動作を特定するために、規則エンジンを使用することを含む、請求項１〜４のいずれか１項に記載の方法。
　　【請求項６】
　行なうべきネットワーク仮想化動作を判断することは、ネットワーク仮想化動作規則を提供するための規則データベース、ネットワーク状態情報を維持するための状態データベース、およびネットワークトポロジ情報を維持するためのトポロジデータベースのうちの少なくとも１つからの情報を使用することを含む、請求項１〜４のいずれか１項に記載の方法。
　　【請求項７】
　行なうべきネットワーク仮想化動作を判断することは、電気通信ネットワーク内から収集された情報を使用することを含む、請求項１〜４のいずれか１項に記載の方法。
　　【請求項８】
　行なうべきネットワーク仮想化動作を判断することは、前記電気通信ネットワークの外部のエンティティから受信された情報を使用することを含む、請求項１〜４のいずれか１項に記載の方法。
　　【請求項９】
　前記電気通信ネットワーク内で収集された情報を使用することは、イベントインターフェイスを介して収集された関連付けられたネットワークからの情報、ＰＣＲＦプラグインを介して送信されたネットワーク性能インジケータ、およびインターフェイスモジュールを介して収集された情報のうちの少なくとも１つを使用することを含む、請求項７に記載の方法。
　　【請求項１０】
　ネットワーク仮想化を管理するために過負荷情報を使用するためのシステムであって、
　電気通信ネットワーク内の仮想ネットワークを管理するための仮想化オーケストレータ（ＶＯ）を含み、前記ＶＯは、
　Diameter過負荷情報を受信するためのネットワークインターフェイスと、
　受信されたDiameter過負荷情報に基づいてネットワーク仮想化動作を判断し、前記Diameter過負荷情報により示された過負荷に応答して、１つ以上のネットワーク仮想化モジュールを用いる電気通信ネットワークにおいて
、１
チを
　　【請求項１１】
　前記規則エンジンは、ネットワーク仮想化モジュールを介して前記ネットワーク仮想化動作を行なう、請求項１０に記載のシステム。
　　【請求項１２】
　前記仮想化オーケストレータは、複数のDiameterクライアントと複数のDiameterサーバとの間の通信を容易にするためのDiameterノードから前記Diameter過負荷情報を受信する、請求項１０または請求項１１に記載のシステム。
　　【請求項１３】
　前記Diameter過負荷情報は、属性値ペア（ＡＶＰ）を含む情報を含む、請求項１０〜１２のいずれか１項に記載のシステム。
　　【請求項１４】
　受信されたDiameter過負荷情報は、Diameterメッセージを含む、請求項１０〜１２のいずれか１項に記載のシステム。
　　【請求項１５】
　請求項１〜
９
第５　引用文献、引用発明等
　１．引用発明、周知技術１、２、引用文献６
 （１）引用文献１記載事項
　下記の引用文献１には、図面とともに、次の事項が記載されている（下線は、強調のために当審で付加したものである。以下、同様。）。
ア　段落［0069］
「[0069]FIG. 13 is a diagram of one embodiment of the epc implemented in the cloud computing system. 
The epc control plane entities (MME, PCRF, HSS) 1307 and the control plane parts of the gateways (S-GW-C, P-GW-C) 1307, 
are implemented in the cloud computing system 1301
as part of the OpenFlow controller 1305. The control plane entites 1307 and the OpenFlow controller 1305 are packaged as VMs. 
 controller 1305 and the control plane entities 1307 can be a remote procedure call (RPC) interface or similar interface. This implementation technology is favorable for scalable management of the control plane entities within the cloud, since it allows execution of the control plane entities 1307 and the controller 1305 to be managed separately according to demand. The cloud manager 1303 can be a VM or an application executed within the cloud computing system 1301.」
（当審仮訳：[0069]図13は、クラウドコンピューティングシステムで実装されるEPCの一実施形態の図である。
EPC制御プレーン・エンティティ(MME, PCRF, HSS)1307とゲートウェイ(S-GW-C, P-GW-C)1307の制御プレーン部分、即ち、GTPシグナリングを処理する部分は、オープンフローコントローラ1305の一部をクラウドコンピューティングシステム1301において実施され
制御プレーンエンティティ1307とオープンフローコントローラ1305は、VMとしてパッケージされ
イ　段落［0070］
「[0070]
The cloud manager 1303 monitors the central processor unit (CPU) utilization of the epc control plane entities 1307 and the control plane traffic between the epc control plane entities 1307 within the cloud.
 If the epc control plane entities 1307 begin to exhibit signs of overloading, 
such as the utilization of too much CPU time, or the queueing up of too much traffic to be processed, the overloaded control plane entity 1307 requests that the cloud manager 1303 start up a new VM to handle the load. 
the epc control plane entities 1307 themselves can issue event notifications to the cloud manager 1303 if they detect internally that they are beginning to experience overloading.
（当審仮訳：[0070]
クラウドマネージャ1303は、制御プレーン・エンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視
EPC制御プレーンエンティティ1307は、例えば、過度のCPUの利用率、または、あまりに多くのトラフィックの待
ち行列化といった、過負荷の兆候を示し始める場合、過負荷状態にある制御プレーンエンティティ1307は、負荷を処理するためにクラウドマネージャ1303が新たなVMを起動することを要求
EPC制御プレーンエンティティ1307は、それら自身が過負荷を経験し始めていることを内部的に検出する場合、クラウドマネージャ1303にイベント通知を発行
ウ　段落［0071］
「［0071］
The cloud manager 1303 also provides reliability and failover by restarting a VM for a particular control plane entity 1307 or function if any of the epc control plane entities 1307 should crash. 
（当審仮訳：[0071] 
クラウドマネージャ1303はまた、任意のEPC制御プレーンエンティティ1307がクラッシュした場合、特定の制御プレーンエンティティ1307又は機能のためのVMを再起動することにより、信頼性およびフェイルオーバを提供する
トコルインタフェースを維持する。）
エ　図１３
「
」
（２）引用発明
　上記（１）を参照すると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる（なお、参考として、括弧内に、摘記箇所に対応する段落番号を示す。以下同様。）。
「　EPC制御プレーンエンティティ(MME, PCRF, HSS)1307とゲートウェイ(S-GW-C, P-GW-C)の制御プレーン部分1307は、オープンフローコントローラ1305の一部をクラウドコンピューティングシステム1301において実施され（[0069]）、
　制御プレーンエンティティ1307とオープンフローコントローラ1305は、VMとしてパッケージされ（[0069]）、
　クラウドマネージャ1303は、制御プレーンエンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視し（[0070]）、
　EPC制御プレーンエンティティ1307は、例えば、過度のCPUの利用率、または、あまりに多くのトラフィックの待ち行列化といった、過負荷の兆候を示し始める場合、過負荷状態にある制御プレーンエンティティ1307は、負荷を処理するためにクラウドマネージャ1303が新たなVMを起動することを要求し（[0070]）、
　EPC制御プレーンエンティティ1307は、それら自身が過負荷を経験し始めていることを内部的に検出する場合、クラウドマネージャ1303にイベント通知を発行し（[0070]）、
　クラウドマネージャ1303はまた、任意のEPC制御プレーンエンティティ1307がクラッシュした場合、特定の制御プレーンエンティティ1307又は機能のためのVMを再起動することにより、信頼性およびフェイルオーバを提供する（[0071]）、
　方法。」
 
（３）周知技術１について
　引用文献２（段落［００４７］−［００４８］、［００７７］等を参照）、引用文献３（第２１頁第３３行から第２２頁第３０行、第２５頁第２６行から第２６頁第３行，Ｆｉｇ．６等を参照）に記載されているように、オープンフローにDiameterプロトコルを適用したシステムは周知技術（以下、周知技術１という。）である。
（４）周知技術２について
　引用文献４（第３欄などを参照），引用文献５（要約などを参照）に記載されているように、収集した負荷情報に基づいて、仮想化を行うか否かを判断することは周知技術（以下、周知技術２という。）である。
（５）引用文献６について　引用文献６（要約、段落［０００２］、［００１６］−［００２０］などを参照）には、ダイアメータプロトコルによって過負荷情報を交換すること、また、ダイアメータのプロトコル要素にはAVP（属性値ペア）が含まれることが記載されている。
第６　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比する。
ア　引用発明の「クラウドマネージャ1303」は、「制御プレーンエンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視し」ており、「EPC制御プレーンエンティティ1307は、例えば、過度のCPUの利用率、または、あまりに多くのトラフィックの待ち行列化といった、過負荷の兆候を示し始める場合、過負荷状態にある制御プレーンエンティティ1307は、負荷を処理するためにクラウドマネージャ1303が新たなVMを起動することを要求し」ている。
　ここで、「クラウドマネージャ1303」が「CPUの利用」や「制御プレーントラフィック」を監視することにより取得する、過度のCPUの利用率、または、あまりに多くのトラフィックの待ち行列化といった過負荷の兆候を示す情報は、過負荷状態を示す情報であるから、過負荷情報といえる。
　また、クラウドマネージャ1303が負荷を処理するための新たなVMの起動は、仮想化されたネットワークのVM（仮想マシン）を管理することであるといえる。
　したがって、引用発明の「制御プレーンエンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視し」、「制御プレーンエンティティ1307は、過負荷が生じた場合に、クラウドマネージャ1303が負荷を処理するために新たなVMを起動するように要求する」ことは、ネットワーク仮想化を管理するために、過負荷情報を使用することであるといえるから、本願発明１の「ネットワーク仮想化を管理するために過負荷情報を使用するための方法」に相当する。
イ　引用発明の「クラウドマネージャ1303」は、クラウドコンピュータシステム1301の構成要素であり、クラウドコンピュータシステムがハードウェア演算装置（プロセッサ）により実現されることは技術常識であるから、引用発明の「クラウドマネージャ1303」にはハードウェア演算装置（プロセッサ）が含まれていることは自明である。
　そして、引用発明の「クラウドマネージャ1303」は、「制御プレーン・エンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視し」、「EPC制御プレーンエンティティは、クラウドマネージャ1303が負荷を処理するために新たなVMを起動することを要求」していることから、引用発明の「クラウドマネージャ1303」は、本願発明１の「ハードウェアプロセッサを含む、電気通信ネットワーク内の仮想ネットワークを管理するための仮想化オーケストレータ（ＶＯ）」に相当する。
ウ　引用発明の「クラウドマネージャ1303」は、「制御プレーンエンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視し」ており、過負荷が生じた場合においても監視は行われているから、過負荷情報を受信しているといえる。
　本願明細書の【０００３】には、「Diameterとは、コンピュータネットワーク用の認証、認可およびアカウンティング（authentication, authorization and accounting：ＡＡＡ）プロトコルであり、RADIUSの後継版である。」と記載され、本願明細書の【００１２】には、「「負荷情報」および「過負荷情報」という用語は同意語であり、Diameterノードまたはノード群が現在動作している負荷レベル、レート、スループットまたは容量を示す情報を指す。」と記載されていることからすると、本願発明１の「
Diameter
　一方、引用文献１には、「Diameter」プロトコルについて言及がなく、「Diameter」プロトコルの使用が自明ともいえない。
　よって、引用発明の「制御プレーンエンティティ1307の中央処理ユニット(CPU)利用、クラウド内のEPCの制御プレーンエンティティ1307との間で制御プレーントラフィックを監視」することと、本願発明１の「
Diameter
エ　引用発明の「過負荷状態のEPC制御プレーンエンティティ1307」は、「過負荷の兆候を示し始める場合」に、「負荷を処理するために、クラウドマネージャ1303が新たなVMを起動すること」を要求しているから、「クラウドマネージャ1303」は、過負荷状態に応答して、負荷を処理するために新たなVMを起動しているといえる。
　そして、引用発明の「EPC制御プレーンエンティティ1307」は、「ゲートウェイ（SC-GW-C，P-GW-C）」が含まれており、「EPC制御プレーンエンティティ1307」はVMとしてパッケージされるものであるから、引用発明の「EPC制御プレーンエンティティ1307」には、ゲートウェイがVMとしてパッケージされており、ＶＭとしてパッケージされるゲートウェイは、仮想リソースといいうるものである。
　したがって、引用発明の「新たなVMを起動すること」は、追加の仮想ゲートウェイを起動して負荷を処理することであるといえ、VMを用いていることから、引用発明のネットワークは、１つ以上のネットワーク仮想化モジュールを用いる電気通信ネットワークであるといえる。
　よって、引用発明の「過負荷状態のEPC制御プレーンエンティティ1307」が、「過負荷の兆候を示し始める場合」に、「負荷を処理するために、クラウドマネージャ1303が新たなVMを起動すること」は、本願発明１の「
前記Diameter過負荷情報
、
仮想スイッチ
前記Diameter過負荷情報
過負荷情報
、
リソース
過負荷情報
（２）一致点、相違点
　したがって、本願発明１と引用発明の一致点及び相違点は、次のとおりである。
［一致点］
「ネットワーク仮想化を管理するために過負荷情報を使用するための方法であって、
　ハードウェアプロセッサを含む電気通信ネットワーク内の仮想ネットワークを管理するための仮想化オーケストレータ（ＶＯ）で、
　過負荷情報を受信することと、
　前記過負荷情報により示された過負荷に応答して、１つ以上のネットワーク仮想化モジュールを用いる電気通信ネットワークにおいて、１つ以上の追加の仮想リソースを用いることにより、前記過負荷情報によって示される過負荷を緩和するための追加のリソースを使用するように前記電気通信ネットワークを管理するための前記ネットワーク仮想化動作を行なう、方法。」
［相違点１］
　受信する過負荷情報について、本願発明１が、「
Diameter
Diameter過負荷情報
［相違点２］
　本願発明１が、仮想化オーケストレータ（ＶＯ）が、「行なうべきネットワーク仮想化動作を判断」しているのに対して、引用発明のクラウドマネージャ1303が、「行うべきネットワーク仮想化動作を判断」していることが明記されていない点。
［相違点３］　本願発明１が、「前記Diameter過負荷情報」により示された過負荷に応答して、一つ以上の追加の「仮想スイッチ」を用いることにより、過負荷を緩和するための追加のリソースを使用するように仮想化動作を行っているのに対して、引用発明が「過負荷情報」により示された過負荷に応答して、一つ以上の追加の「仮想ゲートウェイ」を用いることにより、過負荷を緩和するための追加のリソースを使用するように仮想化動作を行っている点。
（３）判断
　事案に鑑みて、相違点３について、先に検討する。
　引用文献１−６には、「前記Diameter過負荷情報」により示された過負荷に応答して、一つ以上の追加の「仮想スイッチ」を用いることにより、過負荷を緩和するための追加のリソースを使用するように仮想化動作を行う構成は、記載されておらず、当該構成は、本願の優先日前において、周知技術であるともいえない。
　なお、周知技術１又は引用文献６に記載されているように、オープンフローにDiameterプロトコルを適用したシステム、及び、ダイアメータ（Diameter）プロトコルによって過負荷情報を交換することが本願優先日前における周知技術であるとしても、「スイッチ」を仮想化の対象としていない引用発明に当該周知技術（Diameterプロトコル）を適用した場合、直ちには「仮想スイッチ」を用いる構成とはならないし、また、引用発明において、「仮想ゲートウェイ」に替えて、又は「仮想ゲートウェイ」に加えて、「仮想スイッチ」を用いて過負荷を緩和するように構成を変更すべき動機付けも存在しない。
　したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用発明、引用文献２−６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２　本願発明２ないし９及び１５について
　本願発明２ないし９及び１５は、いずれも請求項１を引用しており、本願発明２ないし９及び１５も、相違点３に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献１−６に基いて容易に発明できたものとはいえない。
３　本願発明１０ないし１４について
　本願発明１０は、本願発明１に対応するシステムの発明であり、相違点３に係る本願発明１の構成と同様の構成（「前記Diameter過負荷情報」により示された過負荷に応答して、一つ以上の追加の「仮想スイッチ」を用いることにより、過負荷を緩和するための追加のリソースを使用するように仮想化動作を行う構成）を備えるものであるから、本願発明１と同様の理由により、当業者であっても引用文献１−６に基いて容易に発明できたものとはいえない。
　また、本願発明１１−１４は、いずれも本願発明１０を引用しており、相違点３に係る本願発明１と同様の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献１−６に基いて容易に発明できたものとはいえない。
第７　原査定について
　本願発明１−１５は、いずれも、上記相違点３に係る本願発明１の構成又は当該構成に対応するシステムの構成を備えるものとなり、上記引用文献Ａ−Ｄ（当審拒絶理由における、引用文献１及び４ないし６に相当）には、上記相違点３に係る本願発明１の構成又は当該構成に対応するシステムの構成のいずれも記載されておらず、本願の優先日前において周知技術であるともいえないから、上記引用文献Ａ−Ｄに基づいて、当業者が容易に発明することができたものではない。
　したがって、原査定を維持することはできない。
第８　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。