【事件の表示】
　特願２０１８−　２３０９８「通信システム、制御システム、及び光通信ネットワークシステム」拒絶査定不服審判事件〔令和　１年　８月２２日出願公開、特開２０１９−１４０５６２、請求項の数（５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成３０年２月１３日の出願であって、その手続の経緯は以下のとおりである。
　平成３１年　２月２１日付け：拒絶理由通知書
　平成３１年　４月２４日　　：意見書、手続補正書の提出
　令和　元年　９月２０日付け：拒絶査定（原査定）
　令和　元年１２月２６日　　：審判請求書、手続補正書の提出
　令和　２年１２月　９日付け：拒絶理由（当審拒絶理由）通知書
　令和　３年　２月１５日　　：意見書の提出
第２　原査定の概要
　原査定（令和元年９月２０日付け拒絶査定）の概要は次のとおりである。
　本願請求項１、４及び５に係る発明は、以下の引用文献Ａ及びＢに記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
［引用文献等一覧］
Ａ　特開２０１４−１６５６１４号公報
Ｂ　特開２０１１−１４９６０号公報（周知技術を示す文献）
第３　当審拒絶理由の概要
　当審拒絶理由の概要は次のとおりである。
　本願請求項３ないし５に係る発明は、以下の引用文献１ないし４に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
［引用文献等一覧］
１　特開２０１４−１６５６１４号公報（拒絶査定の引用文献Ａ）
２　国際公開第２０１８／０１１６０７号（当審において新たに引用した文献）
３　ITU-T Focus Group IMT-2020 Deliverables, ITU, 2017年、pp.227-229（当審において新たに引用した文献）
４　ITU-T Y.3150, ITU, 2018年１月，pp.11-12（当審において新たに引用した文献）
第４　本願発明
　本願請求項１ないし５に係る発明（以下、それぞれ「本願発明１」ないし「本願発明５」という。）は、令和元年１２月２６日に提出された手続補正書に係る手続補正（以下、「本件補正」という。）により補正された特許請求の範囲の請求項１ないし５に記載された事項により特定される発明であり、本願発明１ないし５は以下のとおりの発明である。（なお、下線は、本件補正により補正された箇所を示す。）
「　　【請求項１】
　１つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムと、
　それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせた仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段とを有し、
　前記仮想光通信ネットワークシステム制御手段は、前記光通信ネットワークシステムに、複数の前記仮想子局通信装置で共有する共有通信帯域を設定した第１の前記仮想光通信ネットワークシステムと、それぞれの前記子局通信装置に別個の固有通信帯域を設定した第２の前記仮想光通信ネットワークシステムとを同時に設定可能であり、
　前記光伝送路ではＴＤＭＡ方式で光信号が伝送されており、
　前記仮想光通信ネットワークシステム制御手段は、前記第１の前記仮想光通信ネットワークシステムに対して、同じ波長で連続したタイムスロットの通信帯域を優先して割り当て
、
　
前記仮想光通信ネットワークシステム制御手段は、複数の前記仮想子局通信装置で共有する共有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、可能な限り、１波長内で連続したタイムスロットの通信帯域を割当てるという第１の帯域設定ポリシーと、それぞれの前記子局通信装置で別個の固有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、複数波長にまたがった通信帯域を設定してもよいという第２の帯域設定ポリシーと、前記第１の帯域設定ポリシー及び前記第２の帯域設定ポリシーの範囲で、可能な限り、それぞれの前記仮想光通信ネットワークシステムに対して連続したタイムスロットの空き通信帯域を残す帯域割当てを行うという第３の帯域設定ポリシーに従って、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てる
　ことを特徴とする通信システム。
　　【請求項２】
　前記仮想光通信ネットワークシステム制御手段は、バースト性が高く、かつ、トラヒックが発生しない期間が長いという第１のトラヒック特性の前記仮想光通信ネットワークシステムの通信帯域については、可能な限り同一波長に集めて通信帯域割当てを行い、当該波長に、常時トラヒックが発生するという第２のトラヒック特性の前記仮想光通信ネットワークシステムの通信帯域を混在させないという第４の帯域設定ポリシーを加えて、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てることを特徴とする請求項
１
　　【請求項３】
　１つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うものであって、それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせた
スライスである
別個に定められたカスタマ端末の管理に基づいて
　　【請求項４】
　
前記仮想光通信ネットワークシステム制御手段は、前記カスタマ端末による前記仮想光通信ネットワークシステムに対する管理の処理として、前記仮想光通信ネットワークシステムに対する構築、監視、改変、削除のうち少なくとも一つの処理を受け付け、受付けた管理の処理に基づいて前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を設定することを特徴とする請求項３に記載の制御システム。
　　【請求項５】
　１つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムにおいて、請求項
３又は４に
　なお、本件発明１ないし５と、本件補正前の請求項１ないし５に係る発明との対応関係について述べると、本願発明１、２及び３はそれぞれ、本件補正前の請求項２、３及び４に係る発明に対応し、本願発明４は、本件補正前の請求項４を限定的に減縮した発明に対応し、また、本願発明５は、本件補正前の請求項５に係る発明に対応する。
　また、請求人が、審判請求書第５ページ末行〜第６ページ第１行において「請求項１に係る発明は、上述の通り補正前（平成３１年４月２４日付け提出の手続補正書提出時）の請求項２に係る発明を独立項に書き直した内容となっている」と主張するように、原査定時の請求項１は、本件補正により削除された。
（よって、本件発明１及び２は、原査定の対象には含まれない。）
第５　引用文献、引用発明等
１　引用文献１について
（１）引用文献１記載事項
　当審拒絶理由に引用された引用文献１（拒絶査定の引用文献Ａ）には、図面とともに次の事項が記載されている。
「【０００１】
　本発明は、光通信ネットワークシステム、
親局光通信装置及び子局光通信装置が光伝送路を介して１対Ｎの通信を行う受動光ネットワーク（ＰＯＮ：Ｐａｓｓｉｖｅ　Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ）に関する
「【００２９】
　図１の
分散型無線通信基地局システムでは
３−０〜３−Ａは、ＰＯＮシステム３０が有する全ての光を平等に分配するパワースプリッタ
４はＰＯＮシステムで分岐元の親機を構成するＯＬＴ部
５−１〜５−Ｎは
ＰＯＮシステムで分岐先の子機を構成するＯＮＵ部
６−１〜６−Ｍは、ＯＬＴ部４に設置される光送受信部ＬＣ（Ｌｉｎｅ　Ｃａｒｄ）
９−１〜９−ＫはＯＮＵ部５内のＬＣ
１０は波長設定を制御する制御部である
【００３０】
　
ＯＬＴ部４の中のＬＣ６はそれぞれ、光源の先に設置する波長可変フィルタの透過帯域波長を設定することで、別の波長の光で通信することが可能である
制御部１０はＯＮＵ部５をＯＬＴ部４のＬＣ６の数のグループに分け
それぞれのグループ内のＯＮＵ部５は通信する相手のＯＬＴ部４のＬＣ６の波長に応じてＯＮＵ部５内の波長可変フィルタの透過帯域波長を設定する
これにより、ＯＬＴ部４のＬＣ６の数だけ、仮想的にＰＯＮのネットワークを構成することができ
それぞれの仮想ＰＯＮ内では従来のＰＯＮと同じように時間多重（ＴＤＭ）によってＯＬＴ部４と各ＯＮＵ部５は通信でき
「【００３２】
　例えば、
ＬＣ６やＬＣ９が波長可変フィルタを利用しているので波長の組み合わせや、各仮想ＰＯＮの組み合わせも自由にでき
例えば、ある仮想ＰＯＮの通信帯域がひっ迫してきた場合は、その仮想ＰＯＮに所属しているＯＮＵ部５で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想ＰＯＮに変更し、効率的な帯域設定をすることができ
「【００３７】
　
これらの制御は、制御部１０で行われる
「【図１】
」
（２）引用発明
　したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。
「　親局光通信装置及び子局光通信装置が光伝送路を介して１対Ｎの通信を行う受動光ネットワーク（ＰＯＮ：Ｐａｓｓｉｖｅ　Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ）に関する分散型無線通信基地局システムにおいて、
　３−０〜３−Ａは、ＰＯＮシステム３０が有する全ての光を平等に分配するパワースプリッタ、４はＰＯＮシステムで分岐元の親機を構成するＯＬＴ部、５−１〜５−ＮはＰＯＮシステムで分岐先の子機を構成するＯＮＵ部、６−１〜６−Ｍは、ＯＬＴ部４に設置される光送受信部ＬＣ（Ｌｉｎｅ　Ｃａｒｄ）、９−１〜９−ＫはＯＮＵ部５内のＬＣ、１０は波長設定を制御する制御部であり、
　ＯＬＴ部４の中のＬＣ６はそれぞれ、光源の先に設置する波長可変フィルタの透過帯域波長を設定することで、別の波長の光で通信することが可能であり、
　制御部１０はＯＮＵ部５をＯＬＴ部４のＬＣ６の数のグループに分け、それぞれのグループ内のＯＮＵ部５は通信する相手のＯＬＴ部４のＬＣ６の波長に応じてＯＮＵ部５内の波長可変フィルタの透過帯域波長を設定し、これにより、ＯＬＴ部４のＬＣ６の数だけ、仮想的にＰＯＮのネットワークを構成することができ、それぞれの仮想ＰＯＮ内では従来のＰＯＮと同じように時間多重（ＴＤＭ）によってＯＬＴ部４と各ＯＮＵ部５は通信でき、
　ＬＣ６やＬＣ９が波長可変フィルタを利用しているので波長の組み合わせや、各仮想ＰＯＮの組み合わせも自由にでき、例えば、ある仮想ＰＯＮの通信帯域がひっ迫してきた場合は、その仮想ＰＯＮに所属しているＯＮＵ部５で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想ＰＯＮに変更し、効率的な帯域設定をすることができ、
　これらの制御は、制御部１０で行われる、
　分散型無線通信基地局システム。」
２　引用文献２ないし４及び引用文献Ｂについて
（１）引用文献２について
　引用文献２には、図面とともに、以下の事項が記載されている。なお、当審訳として、対応する日本語が記載されている特表２０２０−５１０３２５号公報の記載を採用した。また、これに際し、当該公報の段落番号も併せて記載する。
　また、引用文献２の摘記中、登録商標であることを示す、”R”を○で囲む記号をここでは「(R)」と置き換えて表記した。
（第１ページ第３行）
「The present application relates to a virtualization device」
［当審訳］
「【０００１】
　本出願は
仮想化デバイス
（第１ページ第９〜１９行）
「Network virtualization technology aims to address this challenge. It enables infrastructure providers to partition or aggregate their network resources (i.e. switches, routers, ports, links and bandwidth) into virtual resources and connect them together in any desired or required topology. As such, network virtualization technology permits the composition of multiple coexisting, but isolated, virtual networks running over a shared physical infrastructure. Network virtualization technology permits the composition of bespoke virtual networks for different applications and services over the same physical infrastructure, and allows independent control of each virtual network. Utilising virtualization technology, network infrastructure providers can create and operate application specific virtual networks without significant investment or change in the underlying physical infrastructure.」
［当審訳］
「【０００３】
　
ネットワーク仮想化技術
により、基盤プロバイダが自社のネットワークリソース（すなわち、スイッチ、ルータ、ポート、リンク、および帯域幅）を仮想リソースに分割または集約し、それらを任意の所望のまたは必要なトポロジーで一緒に接続することが可能になる
（第２ページ第９〜１３行）
「Figure 1 is a schematic diagram illustrating the concept of network virtualization. Network virtualization is typically achieved using one of two approaches: (1) aggregation or (2) slicing. In Figure 1, a virtual infrastructure comprises two types of virtual nodes, namely virtual nodes made of aggregated physical nodes (virtual nodes A and B) and virtual nodes made of slices of physical nodes (virtual nodes C and D).」
［当審訳］
「【０００７】
　図１は、ネットワーク仮想化の概念を示す概略図である。
ネットワーク仮想化は、通常、２つの手法：（１）集約または（２）スライシングのうちの１つを使用して実現される
（第７ページ第４〜９行）
「The physical network infrastructure may comprise one or more of the following devices: an optical fibre switch; an optical WDM (Wavelength Division Multiplexing) switch; an optical flexi WDM switch; an optical fixed grid WSS (Wavelength Selective Switching) device, an optical flexi grid WSS device, a wireless access point controller (including a WiFi(R) controller or an eNodeB (Enhanced Node B) of an LTE (Long-Term Evolution) or LTE-A (LTE advanced) network); a wireless access point; and a packet switch.」
［当審訳］
「【００２７】
　
物理ネットワーク基盤は、以下のデバイス：光ファイバスイッチ、光ＷＤＭ（波長分割多重）スイッチ、光フレキシＷＤＭスイッチ、光固定グリッドＷＳＳ（波長選択切替え）デバイス、光フレキシグリッドＷＳＳデバイス、（ＷｉＦｉ（登録商標）コントローラ、またはＬＴＥ（ロングタームエボリューション）もしくはＬＴＥ−Ａ（ＬＴＥアドバンスト）ネットワークのｅノードＢ（拡張ノードＢ）を含む）ワイヤレスアクセスポイントコントローラ、ワイヤレスアクセスポイント、およびパケットスイッチのうちの１つまたは複数を備えてもよい
（第１３ページ第３行〜同ページ下から３行目）
「As can be seen from Figure 3, the virtualization device 300 includes a virtual network control and monitoring module 3 10, a virtual network composition module 320, a transport quality checking module 330, an aggregator module 340, a slicer module 350, a channel aware path computation element (PCE) module 360, a network modelling module 370, a node functionality and constraint database module 380 and a link constraint database module 390. The modules 3 10 - 390 may be implemented as software modules executing on the hardware platform, or as individual hardware modules.
The virtualization device 300 also includes a first, northbound, interface 305, which connects the virtualization device 300 to one or more network controllers and a second, southbound, interface 395, which connects the virtualization device 300 to network devices with optical, packet or wireless traffic or bandwidth switching and/or routing capability, via the control and management interfaces of those devices.
The northbound interface 305 is connected to one or more network controllers supporting any combination of the following interfaces and protocols: a RESTful API; or an API supporting OpenFlow(R) protocol Version 1.0 addendum 0.3, Version 1.3, Version 1.4 or higher. The interface is supported over an Ethernet socket layer.
The northbound interface 305 can be connected to multiple external network controllers at the same time, and enables any external network controller to control, monitor and operate virtual networks composed by the virtualization device 300. Further, the northbound interface 305 enables any external network controller to request a new virtual network at any time, or to request modification of an existing virtual network.」
［当審訳］
「【００５１】
　図３から分かるように、
仮想化デバイス３００は、仮想ネットワーク制御および監視モジュール３１０と、仮想ネットワーク構成モジュール３２０と、トランスポート品質検査モジュール３３０と、アグリゲータモジュール３４０と、スライサモジュール３５０と、チャネル認識経路計算要素（ＰＣＥ）モジュール３６０と、ネットワークモデリングモジュール３７０と、ノード機能および制約データベースモジュール３８０と、リンク制約データベースモジュール３９０とを含む
【００５２】
　
仮想化デバイス３００はまた、１つまたは複数のネットワークコントローラに仮想化デバイス３００を接続する第１のノースバウンドインターフェース３０５
を含む
【００５３】
　ノースバウンドインターフェース３０５は、以下のインターフェースおよびプロトコル：ＲＥＳＴｆｕｌ　ＡＰＩまたはＯｐｅｎＦｌｏｗ（登録商標）バージョン１．０補遺０．３、バージョン１．３、バージョン１．４以降をサポートするＡＰＩの任意の組合せをサポートする１つまたは複数のネットワークコントローラに接続される。インターフェースはイーサネットソケットレイヤ上でサポートされる。
【００５４】
　
ノースバウンドインターフェース３０５は、同時に複数の外部ネットワークコントローラに接続することができ、任意の外部ネットワークコントローラが、仮想化デバイス３００によって構成された仮想ネットワークを制御、監視、および操作することを可能にする。さらに、ノースバウンドインターフェース３０５は、任意の外部ネットワークコントローラが、いつでも新しい仮想ネットワークを要求するか、または既存の仮想ネットワークの修正を要求することを可能にする
（第１５ページ第４〜１５行）
「The virtual network control and monitoring module 310 receives, from a controller external to the virtualization device 300, via the northbound interface 305 and through an SDN based protocol such as (but not limited to) OpenFlow(R) Version 1.0 addendum 0.3, Version 1.3, Version 1.4 or higher or a RESTful API, control and monitoring messages, and transmits these messages to those parts of the physical infrastructure (nodes and links) that are used for mapping the virtual network, via the southbound interface 395.
Further, the virtual network control and monitoring module 310 allows an external network controller to request modifications to an existing (already composed) virtual network. The virtual network control and monitoring module 310 can change the topology, link capacity and node size and features of an existing virtual network. To do this, it un-maps (i.e. decommissions) those parts of the virtual network that require modification and triggers the mapping process (described below) for the modified parts.」
［当審訳］
「【００６１】
　仮想ネットワーク制御および監視モジュール３１０は、仮想化デバイス３００の外部のコントローラから、ノースバウンドインターフェース３０５を介して、（限定されないが）ＯｐｅｎＦｌｏｗ（登録商標）バージョン１．０補遺０．３、バージョン１．３、バージョン１．４以降、またはＲＥＳＴｆｕｌ　ＡＰＩなどのＳＤＮベースのプロトコルを通して、制御および監視メッセージを受信し、これらのメッセージを、サウスバウンドインターフェース３９５を介して、仮想ネットワークをマッピングするために使用される物理基盤の部分（ノードおよびリンク）に送信する。
【００６２】
　さらに、
仮想ネットワーク制御および監視モジュール３１０は、外部ネットワークコントローラが、既存の（既に構成されている）仮想ネットワークに対する修正を要求することを可能にする
既存の仮想ネットワークのトポロジー、リンク容量、およびノードサイズならびに機能を変更する
ために
修正を必要とする仮想ネットワークの部分を「マッピング解除」（すなわち、閉鎖）し、修正された部分に対する
マッピングプロセスをトリガする
「（Fig.3）
」
［当審訳］（省略）
　前記アより、引用文献２には、次の技術的事項（以下、「引用文献２記載事項」という。）が記載されていると認められる。
「　仮想化デバイスであって、
　ネットワーク仮想化技術により、基盤プロバイダが自社のネットワークリソース（すなわち、スイッチ、ルータ、ポート、リンク、および帯域幅）を仮想リソースに分割または集約し、それらを任意の所望のまたは必要なトポロジーで一緒に接続することが可能になり、
　ネットワーク仮想化は、通常、２つの手法：（１）集約または（２）スライシングのうちの１つを使用して実現され、
　物理ネットワーク基盤は、以下のデバイス：光ファイバスイッチ、光ＷＤＭ（波長分割多重）スイッチ、光フレキシＷＤＭスイッチ、光固定グリッドＷＳＳ（波長選択切替え）デバイス、光フレキシグリッドＷＳＳデバイス、（ＷｉＦｉ（登録商標）コントローラ、またはＬＴＥ（ロングタームエボリューション）もしくはＬＴＥ−Ａ（ＬＴＥアドバンスト）ネットワークのｅノードＢ（拡張ノードＢ）を含む）ワイヤレスアクセスポイントコントローラ、ワイヤレスアクセスポイント、およびパケットスイッチのうちの１つまたは複数を備えてもよく、
　仮想化デバイス３００は、仮想ネットワーク制御および監視モジュール３１０と、仮想ネットワーク構成モジュール３２０と、トランスポート品質検査モジュール３３０と、アグリゲータモジュール３４０と、スライサモジュール３５０と、チャネル認識経路計算要素（ＰＣＥ）モジュール３６０と、ネットワークモデリングモジュール３７０と、ノード機能および制約データベースモジュール３８０と、リンク制約データベースモジュール３９０とを含み、
　仮想化デバイス３００はまた、１つまたは複数のネットワークコントローラに仮想化デバイス３００を接続する第１のノースバウンドインターフェース３０５を含み、ノースバウンドインターフェース３０５は、同時に複数の外部ネットワークコントローラに接続することができ、任意の外部ネットワークコントローラが、仮想化デバイス３００によって構成された仮想ネットワークを制御、監視、および操作することを可能し、さらに、ノースバウンドインターフェース３０５は、任意の外部ネットワークコントローラが、いつでも新しい仮想ネットワークを要求するか、または既存の仮想ネットワークの修正を要求することを可能し、
　仮想ネットワーク制御および監視モジュール３１０は、外部ネットワークコントローラが、既存の（既に構成されている）仮想ネットワークに対する修正を要求することを可能にし、既存の仮想ネットワークのトポロジー、リンク容量、およびノードサイズならびに機能を変更するために、修正を必要とする仮想ネットワークの部分を「マッピング解除」（すなわち、閉鎖）し、修正された部分に対するマッピングプロセスをトリガする、
　仮想化デバイス。」
（２）引用文献３について
　当審拒絶理由に引用された引用文献３には、図面とともに次の事項が記載されている。
（第２２７ページ下から３行目〜第２２９ページ第６行）
「8 IMT-2020 Slice Life Cycle Management Functional Architecture
This clause describes detailed management functionality in the Slice Lifecycle Management (SLCM) functional component. Figure 5 shows its functional elements.
IMT-2020 Slice Lifecycle Management Customer Care Support
The IMT-2020 Slice Lifecycle Management Support (SLM-S) functional element provides a standard interface to the Slice Lifecycle Management functionality to its customers and applications, it supports requesting and receiving management operations and associated information in SLM.
Slice Capacity Planning  Optimization
The Slice Capacity Planning and Optimization (SCPO) functional element is responsible for planning of necessary resources for the requested slice provisioning and optimizing usage of resources for creating and maintaining slices. It provides capabilities as follows:
・ making planning decisions based on the available resources discovered by the Slice Resource Monitoring  Analytics functional element and customers' requests.
・ trying always to find optimal available resource matches against the customer's requests.
・ monitoring and ensuring quality of the provisioned slices and take necessary actions (including reprovisioning or modification of the existing slice resource) if resource re-optimization is needed.
Slice Provisioning
The Slice Provisioning (SP) functional element is responsible for provisioning requested slices by the customers and provides capabilities for:
・ provisioning the requested slices by the customers.
・ mapping and translating customer’s high-level slice provisioning profile into technology-aware slice provisioning policies
・ managing provisioning policy lifecycle.
NOTE - Slice provisioning can involve interactions with the MANO NFV orchestrator, other NFV management systems, and/or SDN controllers depending on administration boundaries of the underlying slice resources.
If the SP functional element provides full provisioning capabilities, the slice provisioning can be done internally by itself. If interactions with external provisioning functional entities are needed, it can be done through IMT-2020MPS functional element which is the interface to the external IMT-2020 management
systems.」
［当審訳］
「８　ＩＭＴ−２０２０
スライスライフサイクル管理機能アーキテクチャ
　この節は、スライスライフサイクル管理（ＳＬＣＭ）機能コンポーネントにおける詳細な管理機能について記述する。
ＩＭＴ−２０２０スライスライフサイクル管理カスタマケアサポート
　ＩＭＴ−２０２０スライスライフサイクル管理サポート（ＳＬＭ−Ｓ）機能要素は、
そのカスタマ（customers）
に対して、スライスライフサイクル管理機能への標準インターフェースを提供し、ＳＬＭにおける管理制御及び関連する情報を要求ないし受信する機能
スライス容量プランニング＆最適化
　スライス容量プランニング及び最適化（ＳＣＰＯ）機能要素は、
要求されたスライスプロビジョニングに必要なリソースのプランニング
・スライスリソース監視＆分析機能要素によって発見される利用可能なリソースと
カスタマ（customers）の要求に基づくプランニング
・カスタマの要求に一致する、適切な利用可能なリソースの定常的な探索
・提供されたスライスの品質の監視及び保証、及び、リソースの再最適化に必要な場合に必要なアクション（再プロビジョニング又は既存のスライスリソースの修正を含む。）をとること
スライスプロビジョニング
　スライスプロビジョニング（ＳＰ）機能要素は、カスタマによって要求されたスライスのプロビジョニングを担当し、次の能力を提供する：
・
カスタマ（customers）により要求されたスライスのプロビジョニング
・カスタマの高レベルスライスプロビジョニングプロファイルを、技術を考慮したスライスプロビジョニングポリシーにマップし、変換すること
・プロビジョニングポリシーライフサイクルの管理
注：　スライスプロビジョニングには、管理の境界及び基盤となるスライスリソースによっては、ＭＡＮＯ　ＮＦＶオーケストラレータ、他のＮＦＶ管理システム、及び／又は、ＳＤＮコントローラとの相互作用が含まれる可能性がある。
スライスプロビジョニング機能要素が、全てのプロビジョニングの機能を提供する場合は、スライスプロビジョニングを、それ自身で内部で実行できる。外部のプロビジョニング機能要素との相互作用が必要とされる場合は、外部のＩＭＴ-２０２０管理システムへのインタフェースである、ＩＭＴ−２０２０ＭＰＳ機能要素を介して実行できる。」
　以上より、引用文献３には、次の技術的事項（以下、「引用文献３記載事項」という。）が記載されていると認められる。
「　カスタマ（customers）の要求に基づいて、
　スライスプロビジョニングに必要なリソースをプランニングし、
　スライスをプロビジョニングすること。」
（３）引用文献４について
　引用文献４には、図面とともに、以下の事項が記載されている。
（第１１〜１２ページ）
「8.2 Capability exposure and APIs
IMT-2020 system will accommodate a lot of various types of devices, which belong to different industries. New diverse use cases will need to be supported by the network. The new use cases are expected to come with a high variety of requirements on the network. For example, there will be different requirements on functionality such as charging, policy control, security, mobility etc. Some use cases such as enhanced Mobile Broadband (eMBB) may require application-specific mobility and policy control while other use cases can be handled with simpler mobility or policies. The use cases will also have huge differences in performance requirements.
Capability exposure based on network softwarization enables the operator to create customised network (e.g., a network slice) to provide optimized solutions for different market scenarios which have diverse requirements, e.g., in the areas of functionality and performance.
The potential operational requirements are as follows:
・ The IMT-2020 system is required to be able to customize the network functions within a slice dynamically based on the variation of the third party (e.g., enterprises, service providers, contents providers, etc.) demands.
・ The IMT-2020 system is required to also support dynamic utilization of resources (compute, network and storage resources) within a slice as per the third party application requirement, subject to operator's policy.
     
Figure 8-5 illustrates the capability exposure architecture for slice management.
Use Case 1: The creation or instantiation of a slice triggered by the third party
1. The third party indicates the functionality and performance requirements to create a slice via slice building API. In terms of implementation, a service template profile may be sent to by the API. And this template contains parameters to describe the functionality and performance requirements.
2. The network capability exposure function transfers the above slice building request to the slice lifecycle management and orchestration (slice LCMO).
3. The slice lifecycle management and orchestration (slice LCMO) authorizes the creation request of the slice to meet the functionality and performance requirements based on the agreement between the operator and the third party. If the request is allowed, the slice LCMO forwards resource requirement to slice support and accordingly the Slice support allocate the required resource (hardware and software) to create or instantiate the dedicated slice.
Use Case 2: The dynamic modification of functionality and performance configuration of network slice
1. The third party indicates the modification of functionality or performance for a pre-created slicing via slice modification API. The modification may be triggered for the reason of lack of resource or new function needed by the third party in the slice. In terms of implementation, a service template profile may be sent to by the API. And this temple（当審注：前後の文脈から「template」の誤記と認められる。） contains the parameters to describe the functionality and performance modification requirement.
2. The network capability exposure function transfers the above slice modification request to the slice LCMO.
3. The slice LCMO authorizes the request of functionality and performance modification based on the agreement between the operator and the third party. If the request is allowed, the slice LCMO forwards resource requirement to the slice support and accordingly the slice support re-allocates the required resources (hardware and software) to modify the dedicated slice.
Authorization between slice customer and network capability exposure platform is needed. Slice support can act as the resource management and orchestration, which realizes the deployment of network slice functions including network connectivity. Transport SDN is an underlying technology of providing the overall bandwidth guarantee on an instantiated network slice.」
［当審訳］
「８．２　機能公開及びＡＰＩ
　ＩＭＴ−２０２０システムは、様々な業界に属する様々なタイプのデバイスに対応する。新しい多様なユースケースは、ネットワークによってサポートされる必要がある。新しいユースケースには、ネットワーク上で様々な要件が伴うことが予想される。たとえば、課金、ポリシー制御、セキュリティ、モビリティなどの機能には様々な要件がある。拡張モバイルブロードバンド（ｅＭＢＢ）などの一部のユースケースでは、アプリケーション固有のモビリティとポリシー制御が必要になる場合があるが、他のユースケースは、より単純なモビリティまたはポリシーで処理できる。ユースケースによって、パフォーマンス要件にも大きな違いがある。
　ネットワークのソフトウェア化に基づく機能公開は、オペレータが、例えば、機能性及びパフォーマンスの領域において異なる要求を有する異なる市場シナリオに最適な解決を提供するために、カスタマイズされたネットワーク（例えば、ネットワークスライス）を作成することを可能にする。
　潜在的な運用上の要求は次のとおり：
・ＩＭＴ−２０２０システムは、スライス内のネットワーク機能を、サードパーティ（例えば、企業、サービス提供者、コンテンツ提供者、など）の多様性に基づいて動的にカスタマイズ可能とすることが求められる。
・ＩＭＴ−２０２０システムは、スライス内で、サードパーティのアプリケーション要求ごとに、運用者のポリシーに従って、リソース（例えば、計算、ネットワーク及び記憶媒体のリソース）の動的な利用をサポートすることも求められる。
　図８−５は、スライス管理のための機能公開のアーキテクチャを示す。
（図の中の説明の訳は省略）
ユースケース１：
サードパーティのトリガによるスライスの作成またはインスタンス化
１．サードパーティは、スライス構築ＡＰＩを介してスライスを作成するための機能とパフォーマンスの要件を指示
サービステンプレートプロファイルがＡＰＩによって送信される
２．
ネットワーク機能公開機能は、上記のスライス構築要求をスライスライフサイクル管理及びオーケストレーション（スライスＬＣＭ＆Ｏ）に転送する
３．スライスのライフサイクル管理及びオーケストレーション（スライスＬＣＭ＆Ｏ）は、オペレータとサードパーティの間の合意に基づいて、機能とパフォーマンスの要件を満たすためにスライスの作成要求を承認する。要求が許可される場合、
スライスＬＣＭ＆Ｏはリソース要件をスライスサポートに転送し、それに応じてスライスサポートは必要なリソース（ハードウェアとソフトウェア）を割り当てて専用スライスを作成またはインスタンス化する
ユースケース２：ネットワークスライスの機能とパフォーマンス構成の動的な変更
１．
サードパーティは、スライス変更ＡＰＩを介して、事前に作成されたスライスの機能又はパフォーマンスの変更を指示する
サービステンプレートプロファイルがＡＰＩによって送信される
２．
ネットワーク機能公開機能は、上記のスライス変更要求をスライスＬＣＭ＆Ｏに転送する
３．スライスＬＣＭ＆Ｏは、オペレータとサードパーティの間の合意に基づいて、機能及びパフォーマンスの変更の要求を承認する。要求が許可される場合、
スライスＬＣＭ＆Ｏはリソース要件をスライスサポートに転送し、それに応じてスライスサポートは必要なリソース（ハードウェアとソフトウェア）を再割り当てして専用スライスを変更する
　引用文献４において、「サードパーティ（例えば、企業、サービス提供者、コンテンツ提供者、など）」は、図面（Figure.8-5）からすると、（通信事業者の）「Customers」すなわち「カスタマ」と同一視できる。
　以上から、引用文献４には、次の技術的事項（以下、「引用文献４記載事項」という。）が記載されているといえる。
「　カスタマ（Customers）（サードパーティ）が、ＡＰＩ（スライス構築ＡＰＩ又はスライス変更ＡＰＩ）を介して送信するサービステンプレートプロファイルに基づいて、専用スライスを作成し又は変更すること。」
（４）周知技術
　引用文献３及び４はいずれも、通信技術の標準化を行う国際的な団体であるＩＴＵにより作成された文書であること、及び、上記引用文献３記載事項及び引用文献４記載事項からすると、以下の事項は、本願出願時における周知技術といえる。
　「カスタマ（customers）の要求に従って、スライスを作成又は変更すること。」
３　引用文献Ｂについて
　原査定に引用された引用文献Ｂには、図面とともに次の事項が記載されている。
「【００１０】
　前記課題を解決するために、本発明は、
ユーザ側の要求に応じた帯域変更が低コスト且つ柔軟に行える
光通信システム
「【００６３】
　
バンドアロケーションコントローラは上り拡張波長及び下り拡張波長の一波あるいは複数波を１ユーザ（１の加入者側終端装置）に排他的に接続し、専用線的に使用することが可能である。このとき、他ユーザ（他の加入者側終端装置）は排他接続された波長以外の波長を使用し、広帯域通信を行う
「【００６９】
　次に、
バンドアロケーションコントローラが行う波長の振り分けについて
【００７０】
　それぞれの波長割当について説明する。図８は、
既存ＰＯＮシステムのみで下りＴＤＭ（Ｔｉｍｅ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅｘｉｎｇ）、上りＴＤＭＡ（Ｔｉｍｅ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅ　Ａｃｃｅｓｓ）の通信している場合
「【図８】
」   
  
　以上から、引用文献Ｂには、次の技術的事項が記載されているといえる。
「　ユーザ側の要求に応じた帯域変更が低コスト且つ柔軟に行える光通信システムにおいて、
　バンドアロケーションコントローラは上り拡張波長及び下り拡張波長の一波あるいは複数波を１ユーザ（１の加入者側終端装置）に排他的に接続し、専用線的に使用することが可能であり、このとき、他ユーザ（他の加入者側終端装置）は排他接続された波長以外の波長を使用し、広帯域通信を行い、
　バンドアロケーションコントローラが行う波長の振り分けについて、既存ＰＯＮシステムのみで下りＴＤＭ（Ｔｉｍｅ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅｘｉｎｇ）、上りＴＤＭＡ（Ｔｉｍｅ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅ　Ａｃｃｅｓｓ）の通信している場合があること。」
第６　当審拒絶理由について
１　本願発明３について
（１）対比
　本願発明３と引用発明とを対比する。
（ア）引用発明の「ＯＬＴ部４」、「ＯＮＵ部５」（５−１〜５−Ｎ）はそれぞれ、本願発明３の「１つの親局通信装置」、「複数の子局通信装置」に相当する。
（イ）引用発明において、「ＰＯＮシステム３０が有する全ての光を平等に分配するパワースプリッタ」（３−０〜３−Ａ）は、引用文献１の【図１】を参酌すると、１つの「ＯＬＴ部４」と複数の「ＯＮＵ部５」（５−１〜５−Ｎ）との間を分岐して接続するものであり、また、引用発明の「親局光通信装置及び子局光通信装置が光伝送路を介して１対Ｎの通信を行う受動光ネットワーク（ＰＯＮ）に関する分散型無線通信基地局システム」において、「光伝送路」は、前記「パワースプリッタ」（３−０〜３−Ａ）を含むものである。
　そうすると、引用発明の前記「パワースプリッタ」（３−０〜３−Ａ）を含む「光伝送路」は、「光伝送路」といい得るものである。
　また、引用発明の「ＰＯＮ：Ｐａｓｓｉｖｅ　Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ）システム３０」は、「光通信ネットワークシステム」といい得るものである。
（ウ）引用発明においては、「ＬＣ６やＬＣ９が波長可変フィルタを利用しているので波長の組み合わせや、各仮想ＰＯＮの組み合わせも自由にでき、例えば、ある仮想ＰＯＮの通信帯域がひっ迫してきた場合は、その仮想ＰＯＮに所属しているＯＮＵ部５で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想ＰＯＮに変更し、効率的な帯域設定をする」という、「ＰＯＮシステム３０」に対する制御が「制御部１０」で行われるものである。　よって、引用発明の「制御部１０」は、「ＰＯＮシステム３０」（光通信ネットワークシステム）に対する制御を行うものといい得るものである。
（エ）前記（ア）ないし（ウ）より、引用発明は、本願発明３の「１つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うもの」との構成を備える。
（オ）本願明細書の段落【００２０】には、「ネットワークシステム１は、移動体ネットワークシステム１００をスライスアーキテクチャによりスライス（論理的に分割）したシステム」と記載されていることから、「スライス」とは、ネットワークを論理的に分割すること又は分割したもの（仮想ネットワーク）を意味する。
　引用発明において、「仮想ＰＯＮ」は、「ＯＮＵ部５をＯＬＴ部４のＬＣ６の数のグループに分け」ること、すなわち、物理的な光通信ネットワークシステムを論理的に分割（スライス）することにより「ＯＬＴ部４のＬＣ６の数だけ、仮想的にＰＯＮのネットワークを構成」した「スライス」といい得るものである。
　よって、前記（ア）を参酌すると、引用発明において、「仮想ＰＯＮ」を構成する「ＯＮＵ部５」及び「ＯＬＴ部４」はそれぞれ、「仮想子局通信装置」及び「仮想親局通信装置」といい得るものであり、また、「ＯＮＵ部５をＯＬＴ部４のＬＣ６の数のグループに分け」ることは、「それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定」する制御といい得るものである。
（カ）前記（オ）を参酌すると、引用発明の「仮想ＰＯＮ」は、本願発明１の「複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステム」に相当する。
（キ）前記（エ）で述べたように、引用発明の「制御部１０」は、「ＬＣ６やＬＣ９が波長可変フィルタを利用しているので波長の組み合わせや、各仮想ＰＯＮの組み合わせも自由にでき、例えば、ある仮想ＰＯＮの通信帯域がひっ迫してきた場合は、その仮想ＰＯＮに所属しているＯＮＵ部５で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想ＰＯＮに変更し、効率的な帯域設定をする」といった制御をするものであるから、前記（オ）を参酌すると、「仮想光通信ネットワークシステムごとの制御を行うものであって、
それぞれの前記仮想光通信ネットワークシステムに対して」「別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」といい得るものである。
（ク）前記（オ）ないし（キ）より、引用発明と本願発明３の「それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」とは、「それぞれの前記子局通信
装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」との構成を備える点において共通する。
（ケ）引用発明の「分散型無線通信基地局システム」又は「制御部１０」自体は、「制御部１０」を有するものであるから、本願発明３の「制御システム」に相当する。
（２）一致点、相違点
　したがって、本願発明３と引用発明とは、以下の点において一致ないし相違する。
［一致点］
「　１つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うものであって、それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び１つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段を有することを特徴とする制御システム。」
［相違点］
　「別個の前記光伝送路の通信帯域を設定する」ことが、本願発明３は、「別個に定められたカスタマ端末の管理に基づいて」なされるのに対し、引用発明は、この点を特定するものではない点。
（３）相違点についての判断
　本願発明３において、「別個に定められたカスタマ端末」における「カスタマ端末」が、「仮想光通信ネットワークシステムごとの制御を行う」こと、及び、「前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する」こととの関係において、いかなる観点において「別個に定められた」ものであるのか必ずしも明確とはいえないので、本願明細書の記載を参照する。
　本願明細書には、「カスタマ」ないし「カスタマ端末」について、次のような記載がある。
「【００２１】
　
カスタマは、
事業者である
カスタマは、
自前の設備を有する通信キャリアにスライスを要求して受け取り、管理する機能や人（組織）であり
「【００２３】
　ネットワークシステム１では、例えば、非特許文献１と同様のスライスアーキテクチャにより、Ｎｅｔｗｏｒｋ　Ｓｌｉｃｅ　Ｂｌｕｅｐｒｉｎｔとしての移動体ネットワークシステム１００がスライスされるものとして説明する。ネットワークシステム１には、スライスアーキテクチャにおいてオーケストレータ機能を担うＬＣＭ＆Ｏ２（ＩＭＴ２０２０　Ｓｌｉｃｅ　Ｌｉｆｅｃｙｃｌｅ　Ｍａｎａｇｅｍｅｎｔ　＆　Ｏｒｃｈｅｓｔｒａｔｉｏｎ）が配置されている。また、図１では、
２つのカスタマが利用する端末としてカスタマ端末ＣＴ−１、２０００−２
ＬＣＭ＆Ｏ２は、カスタマ端末ＣＴ−１、ＣＴ−２からの要求に応じて、移動体ネットワークシステム１００をスライスする制御を行い、それぞれのカスタマにスライスされた仮想移動体通信システムを提供する
「【００３３】
　繰り返しになるが、カスタマに提供されるスライスは、ＬＣＭ＆Ｏ２が、ＶＩＭ５やＶＮＦＭ４から提供された資源やデータプレーンや制御プレーンに、さらにサービスとスライス管理機能等を組み合わせて構築したものである。仮想ＰＯＮ提供システム３により提供されるｖＰＯＮは、これらの要素のうち、データプレーン及び制御プレーンの一部に相当する。すなわち、ネットワークシステム１では、仮想ＰＯＮ提供システム３を含む移動体ネットワークシステム１００を仮想化（ＶＮＦ化）することにより構成される「仮想移動体通信システム」が、
各カスタマに提供される各スライス
「【０１２０】
　カスタマ端末ＣＴ−２、ＣＴ−１は、それぞれ、ＬＣＭ＆Ｏ２に対して、自社のＭＶＮＯサービスの仕様（例えば、ネットワークシステム１を所有するキャリアとの契約の範囲内の仕様）に必要な能力を有するスライスを提供するように要求する。なお、カスタマ端末ＣＴ−２、ＣＴ−１とＬＣＭ＆Ｏ２との間のインタフェースの仕様については限定されないものであり、種々のスライスアーキテクチャの構成を適用することができる。ここでは、
第１のカスタマ端末ＣＴ−１は、ＬＣＭ＆Ｏ２に対して、仮想アンテナ装置群８００−１の各仮想アンテナ装置５００と仮想基地局７００−２との間（すなわち、ｖＰＯＮ６００−１の区間）に固定的な帯域を用意しないタイプ（すなわち帯域共有タイプ）の仮想移動体ネットワークシステム１０００−１を要求
第２のカスタマ端末ＣＴ−２は、ＬＣＭ＆Ｏ２に対して、仮想アンテナ装置群８００−２の各仮想アンテナ装置５００と仮想基地局７００−２との間（すなわち、ｖＰＯＮ６００−２の区間）に固定的な帯域を用意するタイプ（すなわち、帯域固有タイプ）の仮想移動体ネットワークシステム１０００−２を要求
【０１２１】
　そして、
ＬＣＭ＆Ｏ２は、要求された各スライスの要求条件を達成するのに必要な各要素のＶＮＦ（仮想移動体ネットワークシステム１０００−１、１０００−２を構成する各要素のＶＮＦ）の能力を求め、各要素のＩＮＦ＆ＶＮＦＭに必要なＶＮＦと資源を提供するように指示する
　上記の記載によれば、「カスタマ」は、自前の設備を有する通信キャリアにスライスを要求して受け取る事業者（機能、人、組織）であり、「カスタマ端末」は、「カスタマ」が利用する端末であり、各「仮想移動体ネットワークシステム」（本願発明３の「仮想光通信ネットワークシステム」に相当。）は、各「カスタマ（端末）」に対応しており、各「カスタマ」は、各「カスタマ端末」（ＣＴ−１、ＣＴ−２）を利用して自身に対応する「仮想移動体ネットワークシステム」の構成に関する要求を、通信キャリアの「ＬＣＭ＆Ｏ２」（本願発明３の「仮想光通信ネットワークシステム制御手段」に相当。）を介して、各「仮想移動体ネットワークシステム」が備える光伝送路の通信帯域を設定するものである。
　そうすると、本願発明３の「カスタマ端末」は、その文言どおりの、「カスタマ」が自身に対応する「仮想光通信ネットワークシステム」の構成（光伝送路の通信帯域）を（「仮想光通信ネットワークシステム制御手段」を介して）個別に制御する端末として定められたものであるとの観点において「別個に定められた」ものであると理解することができる。
　請求人も、令和３年２月１５日に提出した意見書において、
「請求項３に係る発明では『（ｄ）それぞれの前記仮想光通信ネットワークシステムに対して
別個に
別個の
ＣＴ１は
第２のカスタマ向けユーザープレーン及び制御プレーンしか制御できない
設定できる範囲が限定された構成を『別個』と定義しています。しかしながら、刊行物２において、請求項３における『別個』に相当する上記のような概念は開示も示唆もされていません。」
と主張しており、当該主張は、上記の理解に整合する。
　この理解に基づいて上記相違点について検討するに、引用文献２には、引用文献２記載事項にあるように、「任意の外部ネットワークコントローラ」の制御に基づいて仮想ネットワークの構成を制御することが記載されているといえるが、当該「任意の外部ネットワークコントローラ」は、各仮想ネットワークに対応して「別個に定められた」ものには限定されていないし、そのことが自明とはいえない。
　また、引用文献３記載事項及び引用文献４記載事項にあるように、「カスタマ（customers）の要求に従って、スライスを作成又は変更すること。」は本願出願時における周知技術であるが、ここで、「カスタマ（customers）」としては複数のカスタマの存在を想定しているものの、引用文献３又は引用文献４は、各スライスに対応して「別個に定められた」「カスタマ端末」をも開示するものではない。
　よって、上記相違点に係る本願発明３の構成は、引用発明及び引用文献２ないし４には記載されておらず、本願出願前において周知技術であるともいえない。
　したがって、本願発明３は、当業者であっても引用発明及び引用文献２ないし４に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。
２　本願発明４および５について
　本願発明４及び５は、上記相違点に係る本願発明３の構成を備えるものであるから、本願発明３と同じ理由により、当業者であっても引用発明及び引用文献２ないし４に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。
　以上のとおり、当審拒絶理由は、解消した。
　なお、本願発明１及び２については、当審拒絶理由の対象ではなく、また、本願発明１及び２が備える「前記仮想光通信ネットワークシステム制御手段は、複数の前記仮想子局通信装置で共有する共有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、可能な限り、１波長内で連続したタイムスロットの通信帯域を割当てるという第１の帯域設定ポリシーと、それぞれの前記子局通信装置で別個の固有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、複数波長にまたがった通信帯域を設定してもよいという第２の帯域設定ポリシーと、前記第１の帯域設定ポリシー及び前記第２の帯域設定ポリシーの範囲で、可能な限り、それぞれの前記仮想光通信ネットワークシステムに対して連続したタイムスロットの空き通信帯域を残す帯域割当てを行うという第３の帯域設定ポリシーに従って、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てる」との構成は、引用文献１ないし４には記載されておらず、かつ、当業者であってもこれらの記載から容易に想到し得るものでもなく、さらに、本願出願前における周知技術であるともいえない。
第７　原査定についての判断
　本件補正により、補正後の請求項３ないし５は、上記相違点に係る本願発明３の構成を有するものとなった。当該構成は、原査定における引用文献Ａ（当審拒絶理由の引用文献１）及び引用文献Ｂには記載されておらず、本願出願時における周知技術でもないので、本願発明３ないし５は、当業者であっても、原査定における引用文献Ａ及びＢに基づいて容易に発明をすることができたものではない。
　また、原査定時の請求項１は、本件補正により削除され、原査定時の請求項２（本願発明１に対応。）は、原査定の対象ではない。
　したがって、原査定を維持することはできない。
第８　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。