• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1372245
審判番号 不服2019-17648  
総通号数 257 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-05-28 
種別 拒絶査定不服の審決 
審判請求日 2019-12-26 
確定日 2021-04-06 
事件の表示 特願2018- 23098「通信システム、制御システム、及び光通信ネットワークシステム」拒絶査定不服審判事件〔令和 1年 8月22日出願公開、特開2019-140562、請求項の数(5)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成30年2月13日の出願であって、その手続の経緯は以下のとおりである。
平成31年 2月21日付け:拒絶理由通知書
平成31年 4月24日 :意見書、手続補正書の提出
令和 元年 9月20日付け:拒絶査定(原査定)
令和 元年12月26日 :審判請求書、手続補正書の提出
令和 2年12月 9日付け:拒絶理由(当審拒絶理由)通知書
令和 3年 2月15日 :意見書の提出

第2 原査定の概要
原査定(令和元年9月20日付け拒絶査定)の概要は次のとおりである。

本願請求項1、4及び5に係る発明は、以下の引用文献A及びBに記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

[引用文献等一覧]
A 特開2014-165614号公報
B 特開2011-14960号公報(周知技術を示す文献)

第3 当審拒絶理由の概要
当審拒絶理由の概要は次のとおりである。

本願請求項3ないし5に係る発明は、以下の引用文献1ないし4に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

[引用文献等一覧]
1 特開2014-165614号公報(拒絶査定の引用文献A)
2 国際公開第2018/011607号(当審において新たに引用した文献)
3 ITU-T Focus Group IMT-2020 Deliverables, ITU, 2017年、pp.227-229(当審において新たに引用した文献)
4 ITU-T Y.3150, ITU, 2018年1月,pp.11-12(当審において新たに引用した文献)

第4 本願発明
本願請求項1ないし5に係る発明(以下、それぞれ「本願発明1」ないし「本願発明5」という。)は、令和元年12月26日に提出された手続補正書に係る手続補正(以下、「本件補正」という。)により補正された特許請求の範囲の請求項1ないし5に記載された事項により特定される発明であり、本願発明1ないし5は以下のとおりの発明である。(なお、下線は、本件補正により補正された箇所を示す。)

「 【請求項1】
1つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムと、
それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせた仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段とを有し、
前記仮想光通信ネットワークシステム制御手段は、前記光通信ネットワークシステムに、複数の前記仮想子局通信装置で共有する共有通信帯域を設定した第1の前記仮想光通信ネットワークシステムと、それぞれの前記子局通信装置に別個の固有通信帯域を設定した第2の前記仮想光通信ネットワークシステムとを同時に設定可能であり、
前記光伝送路ではTDMA方式で光信号が伝送されており、
前記仮想光通信ネットワークシステム制御手段は、前記第1の前記仮想光通信ネットワークシステムに対して、同じ波長で連続したタイムスロットの通信帯域を優先して割り当て、
前記仮想光通信ネットワークシステム制御手段は、複数の前記仮想子局通信装置で共有する共有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、可能な限り、1波長内で連続したタイムスロットの通信帯域を割当てるという第1の帯域設定ポリシーと、それぞれの前記子局通信装置で別個の固有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、複数波長にまたがった通信帯域を設定してもよいという第2の帯域設定ポリシーと、前記第1の帯域設定ポリシー及び前記第2の帯域設定ポリシーの範囲で、可能な限り、それぞれの前記仮想光通信ネットワークシステムに対して連続したタイムスロットの空き通信帯域を残す帯域割当てを行うという第3の帯域設定ポリシーに従って、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てる
ことを特徴とする通信システム。
【請求項2】
前記仮想光通信ネットワークシステム制御手段は、バースト性が高く、かつ、トラヒックが発生しない期間が長いという第1のトラヒック特性の前記仮想光通信ネットワークシステムの通信帯域については、可能な限り同一波長に集めて通信帯域割当てを行い、当該波長に、常時トラヒックが発生するという第2のトラヒック特性の前記仮想光通信ネットワークシステムの通信帯域を混在させないという第4の帯域設定ポリシーを加えて、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てることを特徴とする請求項1に記載の通信システム。
【請求項3】
1つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うものであって、それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段を有することを特徴とする制御システム。
【請求項4】
前記仮想光通信ネットワークシステム制御手段は、前記カスタマ端末による前記仮想光通信ネットワークシステムに対する管理の処理として、前記仮想光通信ネットワークシステムに対する構築、監視、改変、削除のうち少なくとも一つの処理を受け付け、受付けた管理の処理に基づいて前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を設定することを特徴とする請求項3に記載の制御システム。
【請求項5】
1つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムにおいて、請求項3又は4に記載の制御システムの制御に応じて動作することを特徴とする光通信ネットワークシステム。」

なお、本件発明1ないし5と、本件補正前の請求項1ないし5に係る発明との対応関係について述べると、本願発明1、2及び3はそれぞれ、本件補正前の請求項2、3及び4に係る発明に対応し、本願発明4は、本件補正前の請求項4を限定的に減縮した発明に対応し、また、本願発明5は、本件補正前の請求項5に係る発明に対応する。
また、請求人が、審判請求書第5ページ末行?第6ページ第1行において「請求項1に係る発明は、上述の通り補正前(平成31年4月24日付け提出の手続補正書提出時)の請求項2に係る発明を独立項に書き直した内容となっている」と主張するように、原査定時の請求項1は、本件補正により削除された。
(よって、本件発明1及び2は、原査定の対象には含まれない。)

第5 引用文献、引用発明等
1 引用文献1について
(1)引用文献1記載事項
当審拒絶理由に引用された引用文献1(拒絶査定の引用文献A)には、図面とともに次の事項が記載されている。

「【0001】
本発明は、光通信ネットワークシステム、親局光通信装置及び子局光通信装置が光伝送路を介して1対Nの通信を行う受動光ネットワーク(PON:Passive Optical Network)に関するものである。」

「【0029】
図1の分散型無線通信基地局システムでは、1は親局装置としてのBBU、2-1?2-Nは子局装置としてRRH、3-0?3-Aは、PONシステム30が有する全ての光を平等に分配するパワースプリッタである。4はPONシステムで分岐元の親機を構成するOLT部、5-1?5-Nは4と同じくPONシステムで分岐先の子機を構成するONU部である。6-1?6-Mは、OLT部4に設置される光送受信部LC(Line Card)である。7は上部ネットワークからの複数の信号を並列に処理するために信号を分配するスイッチである。BBUが複数ではなく1つの信号のみを処理するのであればスイッチ7は不要である。8-1?8-NはPONからの複数の信号を分配するスイッチである。9-1?9-KはONU部5内のLCである。スイッチ8はONU部5のLCの数によって有無が決まる。ONU部5のLC9が複数あればスイッチ8が必要で、LC9が1つであればスイッチ8は不要である。10は波長設定を制御する制御部である。
【0030】
OLT部4の中のLC6はそれぞれ、光源の先に設置する波長可変フィルタの透過帯域波長を設定することで、別の波長の光で通信することが可能である。このとき、制御部10はONU部5をOLT部4のLC6の数のグループに分ける。例えば、OLT部4のLC6が3つだったら、ONU部5を3つのグループに分ける。そしてそれぞれのグループ内のONU部5は通信する相手のOLT部4のLC6の波長に応じてONU部5内の波長可変フィルタの透過帯域波長を設定する。これにより、OLT部4のLC6の数だけ、仮想的にPONのネットワークを構成することができる。それぞれの仮想PON内では従来のPONと同じように時間多重(TDM)によってOLT部4と各ONU部5は通信できる。また、同じグループでない通信(異なる仮想PONの通信)は波長が異なるため、LC6やLC9のフィルタでカットされるので自動的に無視される。各ONU部5が接続されたスプリッタなどは考慮する必要がないため、柔軟に自由にネットワークを構成できる。」

「【0032】
例えば、LC6やLC9が波長可変フィルタを利用しているので波長の組み合わせや、各仮想PONの組み合わせも自由にできる。例えば、ある仮想PONの通信帯域がひっ迫してきた場合は、その仮想PONに所属しているONU部5で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想PONに変更し、効率的な帯域設定をすることができる。」

「【0037】
これらの制御は、制御部10で行われる。制御部10は、親局装置1又は子局装置2から無線端末のアクセス状態に関するアクセス状態情報を取得し、波長管理を行う。制御部10は、子局装置2が収容する無線端末数を前記アクセス状態情報としており、グループに帰属する無線端末数が均一になるように前記波長管理を行ってもよい。また、制御部10は、グループ毎の単位時間の平均通信量を前記アクセス状態情報としており、グループ毎の前記平均通信量が均一になるように前記波長管理を行ってもよい。」

「【図1】



(2)引用発明
したがって、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「 親局光通信装置及び子局光通信装置が光伝送路を介して1対Nの通信を行う受動光ネットワーク(PON:Passive Optical Network)に関する分散型無線通信基地局システムにおいて、
3-0?3-Aは、PONシステム30が有する全ての光を平等に分配するパワースプリッタ、4はPONシステムで分岐元の親機を構成するOLT部、5-1?5-NはPONシステムで分岐先の子機を構成するONU部、6-1?6-Mは、OLT部4に設置される光送受信部LC(Line Card)、9-1?9-KはONU部5内のLC、10は波長設定を制御する制御部であり、
OLT部4の中のLC6はそれぞれ、光源の先に設置する波長可変フィルタの透過帯域波長を設定することで、別の波長の光で通信することが可能であり、
制御部10はONU部5をOLT部4のLC6の数のグループに分け、それぞれのグループ内のONU部5は通信する相手のOLT部4のLC6の波長に応じてONU部5内の波長可変フィルタの透過帯域波長を設定し、これにより、OLT部4のLC6の数だけ、仮想的にPONのネットワークを構成することができ、それぞれの仮想PON内では従来のPONと同じように時間多重(TDM)によってOLT部4と各ONU部5は通信でき、
LC6やLC9が波長可変フィルタを利用しているので波長の組み合わせや、各仮想PONの組み合わせも自由にでき、例えば、ある仮想PONの通信帯域がひっ迫してきた場合は、その仮想PONに所属しているONU部5で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想PONに変更し、効率的な帯域設定をすることができ、
これらの制御は、制御部10で行われる、
分散型無線通信基地局システム。」

2 引用文献2ないし4及び引用文献Bについて
(1)引用文献2について
引用文献2には、図面とともに、以下の事項が記載されている。なお、当審訳として、対応する日本語が記載されている特表2020-510325号公報の記載を採用した。また、これに際し、当該公報の段落番号も併せて記載する。
また、引用文献2の摘記中、登録商標であることを示す、”R”を○で囲む記号をここでは「(R)」と置き換えて表記した。

(第1ページ第3行)
「The present application relates to a virtualization device」
[当審訳]
「【0001】
本出願は仮想化デバイスに関する。」

(第1ページ第9?19行)
「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.」
[当審訳]
「【0003】
ネットワーク仮想化技術は、この課題に対処することを目的とする。それにより、基盤プロバイダが自社のネットワークリソース(すなわち、スイッチ、ルータ、ポート、リンク、および帯域幅)を仮想リソースに分割または集約し、それらを任意の所望のまたは必要なトポロジーで一緒に接続することが可能になる。そのため、ネットワーク仮想化技術により、共有された物理基盤上で実行されている、複数共存するが分離された仮想ネットワークの構成が可能になる。ネットワーク仮想化技術により、同じ物理基盤上の様々なアプリケーションおよびサービス用の特注仮想ネットワークの構成が可能になり、各仮想ネットワークの独立制御が可能になる。仮想化技術を利用すると、ネットワーク基盤プロバイダは、基礎となる物理基盤に大きな投資または変更を加えることなく、アプリケーション固有の仮想ネットワークを作成および運用することができる。」

(第2ページ第9?13行)
「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).」
[当審訳]
「【0007】
図1は、ネットワーク仮想化の概念を示す概略図である。ネットワーク仮想化は、通常、2つの手法:(1)集約または(2)スライシングのうちの1つを使用して実現される。図1では、仮想基盤は、2つのタイプの仮想ノード、すなわち、集約された物理ノードからなる仮想ノード(仮想ノードAおよびB)と、物理ノードのスライスからなる仮想ノード(仮想ノードCおよびD)とを備える。」

(第7ページ第4?9行)
「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.」
[当審訳]
「【0027】
物理ネットワーク基盤は、以下のデバイス:光ファイバスイッチ、光WDM(波長分割多重)スイッチ、光フレキシWDMスイッチ、光固定グリッドWSS(波長選択切替え)デバイス、光フレキシグリッドWSSデバイス、(WiFi(登録商標)コントローラ、またはLTE(ロングタームエボリューション)もしくはLTE-A(LTEアドバンスト)ネットワークのeノードB(拡張ノードB)を含む)ワイヤレスアクセスポイントコントローラ、ワイヤレスアクセスポイント、およびパケットスイッチのうちの1つまたは複数を備えてもよい。」

(第13ページ第3行?同ページ下から3行目)
「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.」
[当審訳]
「【0051】
図3から分かるように、仮想化デバイス300は、仮想ネットワーク制御および監視モジュール310と、仮想ネットワーク構成モジュール320と、トランスポート品質検査モジュール330と、アグリゲータモジュール340と、スライサモジュール350と、チャネル認識経路計算要素(PCE)モジュール360と、ネットワークモデリングモジュール370と、ノード機能および制約データベースモジュール380と、リンク制約データベースモジュール390とを含む。モジュール310?390は、ハードウェアプラットフォーム上で実行されるソフトウェアモジュールとして、または個々のハードウェアモジュールとして実装されてもよい。
【0052】
仮想化デバイス300はまた、1つまたは複数のネットワークコントローラに仮想化デバイス300を接続する第1のノースバウンドインターフェース305と、光、パケット、またはワイヤレスのトラフィックまたは帯域幅の切替えおよび/またはルーティングの機能を有するネットワークデバイスに、それらのデバイスの制御および管理インターフェースを介して仮想化デバイス300を接続する第2のサウスバウンドインターフェース395とを含む。
【0053】
ノースバウンドインターフェース305は、以下のインターフェースおよびプロトコル:RESTful APIまたはOpenFlow(登録商標)バージョン1.0補遺0.3、バージョン1.3、バージョン1.4以降をサポートするAPIの任意の組合せをサポートする1つまたは複数のネットワークコントローラに接続される。インターフェースはイーサネットソケットレイヤ上でサポートされる。
【0054】
ノースバウンドインターフェース305は、同時に複数の外部ネットワークコントローラに接続することができ、任意の外部ネットワークコントローラが、仮想化デバイス300によって構成された仮想ネットワークを制御、監視、および操作することを可能にする。さらに、ノースバウンドインターフェース305は、任意の外部ネットワークコントローラが、いつでも新しい仮想ネットワークを要求するか、または既存の仮想ネットワークの修正を要求することを可能にする。」

(第15ページ第4?15行)
「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.」
[当審訳]
「【0061】
仮想ネットワーク制御および監視モジュール310は、仮想化デバイス300の外部のコントローラから、ノースバウンドインターフェース305を介して、(限定されないが)OpenFlow(登録商標)バージョン1.0補遺0.3、バージョン1.3、バージョン1.4以降、またはRESTful APIなどのSDNベースのプロトコルを通して、制御および監視メッセージを受信し、これらのメッセージを、サウスバウンドインターフェース395を介して、仮想ネットワークをマッピングするために使用される物理基盤の部分(ノードおよびリンク)に送信する。
【0062】
さらに、仮想ネットワーク制御および監視モジュール310は、外部ネットワークコントローラが、既存の(既に構成されている)仮想ネットワークに対する修正を要求することを可能にする。仮想ネットワーク制御および監視モジュール310は、既存の仮想ネットワークのトポロジー、リンク容量、およびノードサイズならびに機能を変更することができる。これを行うために、仮想ネットワーク制御および監視モジュール310は、修正を必要とする仮想ネットワークの部分を「マッピング解除」(すなわち、閉鎖)し、修正された部分に対する(下記に記載される)マッピングプロセスをトリガする。」

「(Fig.3)


[当審訳](省略)

前記アより、引用文献2には、次の技術的事項(以下、「引用文献2記載事項」という。)が記載されていると認められる。

「 仮想化デバイスであって、
ネットワーク仮想化技術により、基盤プロバイダが自社のネットワークリソース(すなわち、スイッチ、ルータ、ポート、リンク、および帯域幅)を仮想リソースに分割または集約し、それらを任意の所望のまたは必要なトポロジーで一緒に接続することが可能になり、
ネットワーク仮想化は、通常、2つの手法:(1)集約または(2)スライシングのうちの1つを使用して実現され、
物理ネットワーク基盤は、以下のデバイス:光ファイバスイッチ、光WDM(波長分割多重)スイッチ、光フレキシWDMスイッチ、光固定グリッドWSS(波長選択切替え)デバイス、光フレキシグリッドWSSデバイス、(WiFi(登録商標)コントローラ、またはLTE(ロングタームエボリューション)もしくはLTE-A(LTEアドバンスト)ネットワークのeノードB(拡張ノードB)を含む)ワイヤレスアクセスポイントコントローラ、ワイヤレスアクセスポイント、およびパケットスイッチのうちの1つまたは複数を備えてもよく、
仮想化デバイス300は、仮想ネットワーク制御および監視モジュール310と、仮想ネットワーク構成モジュール320と、トランスポート品質検査モジュール330と、アグリゲータモジュール340と、スライサモジュール350と、チャネル認識経路計算要素(PCE)モジュール360と、ネットワークモデリングモジュール370と、ノード機能および制約データベースモジュール380と、リンク制約データベースモジュール390とを含み、
仮想化デバイス300はまた、1つまたは複数のネットワークコントローラに仮想化デバイス300を接続する第1のノースバウンドインターフェース305を含み、ノースバウンドインターフェース305は、同時に複数の外部ネットワークコントローラに接続することができ、任意の外部ネットワークコントローラが、仮想化デバイス300によって構成された仮想ネットワークを制御、監視、および操作することを可能し、さらに、ノースバウンドインターフェース305は、任意の外部ネットワークコントローラが、いつでも新しい仮想ネットワークを要求するか、または既存の仮想ネットワークの修正を要求することを可能し、
仮想ネットワーク制御および監視モジュール310は、外部ネットワークコントローラが、既存の(既に構成されている)仮想ネットワークに対する修正を要求することを可能にし、既存の仮想ネットワークのトポロジー、リンク容量、およびノードサイズならびに機能を変更するために、修正を必要とする仮想ネットワークの部分を「マッピング解除」(すなわち、閉鎖)し、修正された部分に対するマッピングプロセスをトリガする、
仮想化デバイス。」

(2)引用文献3について
当審拒絶理由に引用された引用文献3には、図面とともに次の事項が記載されている。

(第227ページ下から3行目?第229ページ第6行)
「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.」
[当審訳]
「8 IMT-2020スライスライフサイクル管理機能アーキテクチャ

この節は、スライスライフサイクル管理(SLCM)機能コンポーネントにおける詳細な管理機能について記述する。

IMT-2020スライスライフサイクル管理カスタマケアサポート
IMT-2020スライスライフサイクル管理サポート(SLM-S)機能要素は、そのカスタマ(customers)及びアプリケーションに対して、スライスライフサイクル管理機能への標準インターフェースを提供し、SLMにおける管理制御及び関連する情報を要求ないし受信する機能をサポートする。

スライス容量プランニング&最適化
スライス容量プランニング及び最適化(SCPO)機能要素は、要求されたスライスプロビジョニングに必要なリソースのプランニングと、スライスの作成および保守のためのリソースの使用の最適化を担当し、以下の機能を提供する:
・スライスリソース監視&分析機能要素によって発見される利用可能なリソースとカスタマ(customers)の要求に基づくプランニングの決定
・カスタマの要求に一致する、適切な利用可能なリソースの定常的な探索
・提供されたスライスの品質の監視及び保証、及び、リソースの再最適化に必要な場合に必要なアクション(再プロビジョニング又は既存のスライスリソースの修正を含む。)をとること

スライスプロビジョニング
スライスプロビジョニング(SP)機能要素は、カスタマによって要求されたスライスのプロビジョニングを担当し、次の能力を提供する:
・カスタマ(customers)により要求されたスライスのプロビジョニング
・カスタマの高レベルスライスプロビジョニングプロファイルを、技術を考慮したスライスプロビジョニングポリシーにマップし、変換すること
・プロビジョニングポリシーライフサイクルの管理
注: スライスプロビジョニングには、管理の境界及び基盤となるスライスリソースによっては、MANO NFVオーケストラレータ、他のNFV管理システム、及び/又は、SDNコントローラとの相互作用が含まれる可能性がある。
スライスプロビジョニング機能要素が、全てのプロビジョニングの機能を提供する場合は、スライスプロビジョニングを、それ自身で内部で実行できる。外部のプロビジョニング機能要素との相互作用が必要とされる場合は、外部のIMT-2020管理システムへのインタフェースである、IMT-2020MPS機能要素を介して実行できる。」

以上より、引用文献3には、次の技術的事項(以下、「引用文献3記載事項」という。)が記載されていると認められる。

「 カスタマ(customers)の要求に基づいて、
スライスプロビジョニングに必要なリソースをプランニングし、
スライスをプロビジョニングすること。」

(3)引用文献4について
引用文献4には、図面とともに、以下の事項が記載されている。

(第11?12ページ)
「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 LCM&O).
3. The slice lifecycle management and orchestration (slice LCM&O) 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 LCM&O 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 LCM&O.
3. The slice LCM&O 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 LCM&O 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.」
[当審訳]
「8.2 機能公開及びAPI
IMT-2020システムは、様々な業界に属する様々なタイプのデバイスに対応する。新しい多様なユースケースは、ネットワークによってサポートされる必要がある。新しいユースケースには、ネットワーク上で様々な要件が伴うことが予想される。たとえば、課金、ポリシー制御、セキュリティ、モビリティなどの機能には様々な要件がある。拡張モバイルブロードバンド(eMBB)などの一部のユースケースでは、アプリケーション固有のモビリティとポリシー制御が必要になる場合があるが、他のユースケースは、より単純なモビリティまたはポリシーで処理できる。ユースケースによって、パフォーマンス要件にも大きな違いがある。
ネットワークのソフトウェア化に基づく機能公開は、オペレータが、例えば、機能性及びパフォーマンスの領域において異なる要求を有する異なる市場シナリオに最適な解決を提供するために、カスタマイズされたネットワーク(例えば、ネットワークスライス)を作成することを可能にする。
潜在的な運用上の要求は次のとおり:
・IMT-2020システムは、スライス内のネットワーク機能を、サードパーティ(例えば、企業、サービス提供者、コンテンツ提供者、など)の多様性に基づいて動的にカスタマイズ可能とすることが求められる。
・IMT-2020システムは、スライス内で、サードパーティのアプリケーション要求ごとに、運用者のポリシーに従って、リソース(例えば、計算、ネットワーク及び記憶媒体のリソース)の動的な利用をサポートすることも求められる。

図8-5は、スライス管理のための機能公開のアーキテクチャを示す。
(図の中の説明の訳は省略)

ユースケース1:サードパーティのトリガによるスライスの作成またはインスタンス化
1.サードパーティは、スライス構築APIを介してスライスを作成するための機能とパフォーマンスの要件を指示する。実装に関しては、サービステンプレートプロファイルがAPIによって送信される場合がある。また、このテンプレートには、機能とパフォーマンスの要件を説明するパラメーターが含まれる。
2.ネットワーク機能公開機能は、上記のスライス構築要求をスライスライフサイクル管理及びオーケストレーション(スライスLCM&O)に転送する。
3.スライスのライフサイクル管理及びオーケストレーション(スライスLCM&O)は、オペレータとサードパーティの間の合意に基づいて、機能とパフォーマンスの要件を満たすためにスライスの作成要求を承認する。要求が許可される場合、スライスLCM&Oはリソース要件をスライスサポートに転送し、それに応じてスライスサポートは必要なリソース(ハードウェアとソフトウェア)を割り当てて専用スライスを作成またはインスタンス化する。

ユースケース2:ネットワークスライスの機能とパフォーマンス構成の動的な変更
1.サードパーティは、スライス変更APIを介して、事前に作成されたスライスの機能又はパフォーマンスの変更を指示する。スライス内のサードパーティが必要とするリソース又は新しい機能が不足しているために、変更がトリガされる場合がある。実装に関しては、サービステンプレートプロファイルがAPIによって送信される場合がある。また、このテンプレートには、機能とパフォーマンスの変更要件を説明するパラメーターが含まれている。
2.ネットワーク機能公開機能は、上記のスライス変更要求をスライスLCM&Oに転送する。
3.スライスLCM&Oは、オペレータとサードパーティの間の合意に基づいて、機能及びパフォーマンスの変更の要求を承認する。要求が許可される場合、スライスLCM&Oはリソース要件をスライスサポートに転送し、それに応じてスライスサポートは必要なリソース(ハードウェアとソフトウェア)を再割り当てして専用スライスを変更する。スライスのカスタマーとネットワーク機能公開プラットフォーム間の承認が必要である。スライスサポートは、リソース管理およびオーケストレーションとして機能することができ、ネットワーク接続を含むネットワークスライス機能の配備を実現する。トランスポートSDNは、インスタンス化されたネットワークスライスで全体的な帯域幅保証を提供する基盤となるテクノロジーである。」

引用文献4において、「サードパーティ(例えば、企業、サービス提供者、コンテンツ提供者、など)」は、図面(Figure.8-5)からすると、(通信事業者の)「Customers」すなわち「カスタマ」と同一視できる。
以上から、引用文献4には、次の技術的事項(以下、「引用文献4記載事項」という。)が記載されているといえる。

「 カスタマ(Customers)(サードパーティ)が、API(スライス構築API又はスライス変更API)を介して送信するサービステンプレートプロファイルに基づいて、専用スライスを作成し又は変更すること。」

(4)周知技術
引用文献3及び4はいずれも、通信技術の標準化を行う国際的な団体であるITUにより作成された文書であること、及び、上記引用文献3記載事項及び引用文献4記載事項からすると、以下の事項は、本願出願時における周知技術といえる。

「カスタマ(customers)の要求に従って、スライスを作成又は変更すること。」

3 引用文献Bについて
原査定に引用された引用文献Bには、図面とともに次の事項が記載されている。

「【0010】
前記課題を解決するために、本発明は、ユーザ側の要求に応じた帯域変更が低コスト且つ柔軟に行える加入者側終端装置、局側終端装置、及び光通信システムを提供することを目的とする。」

「【0063】
バンドアロケーションコントローラは上り拡張波長及び下り拡張波長の一波あるいは複数波を1ユーザ(1の加入者側終端装置)に排他的に接続し、専用線的に使用することが可能である。このとき、他ユーザ(他の加入者側終端装置)は排他接続された波長以外の波長を使用し、広帯域通信を行う。」

「【0069】
次に、バンドアロケーションコントローラが行う波長の振り分けについての詳細を説明する。図8?図13は波長割当て方法についてまとめた図である。図8?図13の光通信システムは、特定ONU13-cが4つ接続されている。これら4つの特定ONU13-cをそれぞれONU1、ONU2、ONU3、及びONU4で示している。それぞれの特定ONU13-cのユーザは複数波長に渡る帯域を契約しているものとする。なお、図8?図13では上り原光信号Lu0(波長λ0)と上り拡張光信号Lua-1?7(波長λ1?7)のみを示しているが、上り拡張光信号の数はこれに限定されない。また、下り拡張光信号についても同様なシグナリングが行われる。
【0070】
それぞれの波長割当について説明する。図8は、既存PONシステムのみで下りTDM(Time Division Multiplexing)、上りTDMA(Time Division Multiple Access)の通信している場合である。図9は、ONU4のみが、拡張PONシステム上で上り拡張波長λ1を利用している場合である。図10は、ONU1?4が拡張PONシステム上でそれぞれ上り拡張波長λ1?4を使用している場合である。この場合、拡張PONシステムはWDMである。図11は、ONU1?4が拡張PONシステム上で上り拡張波長を使用し、かつONU3が複数の上り拡張波長を使用している場合である。この場合、拡張PONシステムはWDMである。図12は、ONU1?4が拡張PONシステム上で上り拡張波長を使用し、かつONU3とONU4が複数の上り拡張波長を使用している場合である。この場合、拡張PONシステムはWDMである。」

「【図8】



以上から、引用文献Bには、次の技術的事項が記載されているといえる。

「 ユーザ側の要求に応じた帯域変更が低コスト且つ柔軟に行える光通信システムにおいて、
バンドアロケーションコントローラは上り拡張波長及び下り拡張波長の一波あるいは複数波を1ユーザ(1の加入者側終端装置)に排他的に接続し、専用線的に使用することが可能であり、このとき、他ユーザ(他の加入者側終端装置)は排他接続された波長以外の波長を使用し、広帯域通信を行い、
バンドアロケーションコントローラが行う波長の振り分けについて、既存PONシステムのみで下りTDM(Time Division Multiplexing)、上りTDMA(Time Division Multiple Access)の通信している場合があること。」

第6 当審拒絶理由について
1 本願発明3について
(1)対比
本願発明3と引用発明とを対比する。

(ア)引用発明の「OLT部4」、「ONU部5」(5-1?5-N)はそれぞれ、本願発明3の「1つの親局通信装置」、「複数の子局通信装置」に相当する。

(イ)引用発明において、「PONシステム30が有する全ての光を平等に分配するパワースプリッタ」(3-0?3-A)は、引用文献1の【図1】を参酌すると、1つの「OLT部4」と複数の「ONU部5」(5-1?5-N)との間を分岐して接続するものであり、また、引用発明の「親局光通信装置及び子局光通信装置が光伝送路を介して1対Nの通信を行う受動光ネットワーク(PON)に関する分散型無線通信基地局システム」において、「光伝送路」は、前記「パワースプリッタ」(3-0?3-A)を含むものである。
そうすると、引用発明の前記「パワースプリッタ」(3-0?3-A)を含む「光伝送路」は、「光伝送路」といい得るものである。
また、引用発明の「PON:Passive Optical Network)システム30」は、「光通信ネットワークシステム」といい得るものである。

(ウ)引用発明においては、「LC6やLC9が波長可変フィルタを利用しているので波長の組み合わせや、各仮想PONの組み合わせも自由にでき、例えば、ある仮想PONの通信帯域がひっ迫してきた場合は、その仮想PONに所属しているONU部5で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想PONに変更し、効率的な帯域設定をする」という、「PONシステム30」に対する制御が「制御部10」で行われるものである。 よって、引用発明の「制御部10」は、「PONシステム30」(光通信ネットワークシステム)に対する制御を行うものといい得るものである。

(エ)前記(ア)ないし(ウ)より、引用発明は、本願発明3の「1つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うもの」との構成を備える。

(オ)本願明細書の段落【0020】には、「ネットワークシステム1は、移動体ネットワークシステム100をスライスアーキテクチャによりスライス(論理的に分割)したシステム」と記載されていることから、「スライス」とは、ネットワークを論理的に分割すること又は分割したもの(仮想ネットワーク)を意味する。
引用発明において、「仮想PON」は、「ONU部5をOLT部4のLC6の数のグループに分け」ること、すなわち、物理的な光通信ネットワークシステムを論理的に分割(スライス)することにより「OLT部4のLC6の数だけ、仮想的にPONのネットワークを構成」した「スライス」といい得るものである。
よって、前記(ア)を参酌すると、引用発明において、「仮想PON」を構成する「ONU部5」及び「OLT部4」はそれぞれ、「仮想子局通信装置」及び「仮想親局通信装置」といい得るものであり、また、「ONU部5をOLT部4のLC6の数のグループに分け」ることは、「それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定」する制御といい得るものである。

(カ)前記(オ)を参酌すると、引用発明の「仮想PON」は、本願発明1の「複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステム」に相当する。

(キ)前記(エ)で述べたように、引用発明の「制御部10」は、「LC6やLC9が波長可変フィルタを利用しているので波長の組み合わせや、各仮想PONの組み合わせも自由にでき、例えば、ある仮想PONの通信帯域がひっ迫してきた場合は、その仮想PONに所属しているONU部5で通信量が多いものを、その通信波長を変更することにより、帯域に余裕がある他の仮想PONに変更し、効率的な帯域設定をする」といった制御をするものであるから、前記(オ)を参酌すると、「仮想光通信ネットワークシステムごとの制御を行うものであって、
それぞれの前記仮想光通信ネットワークシステムに対して」「別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」といい得るものである。

(ク)前記(オ)ないし(キ)より、引用発明と本願発明3の「それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」とは、「それぞれの前記子局通信
装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段」との構成を備える点において共通する。

(ケ)引用発明の「分散型無線通信基地局システム」又は「制御部10」自体は、「制御部10」を有するものであるから、本願発明3の「制御システム」に相当する。

(2)一致点、相違点
したがって、本願発明3と引用発明とは、以下の点において一致ないし相違する。

[一致点]
「 1つの親局通信装置と複数の子局通信装置と前記親局通信装置から前記子局通信装置に分岐して接続された光伝送路とを備える光通信ネットワークシステムに対する制御を行うものであって、それぞれの前記子局通信装置に仮想子局通信装置を設定し、前記親局通信装置に仮想親局通信装置を設定し、複数の前記仮想子局通信装置及び1つの前記仮想親局通信装置を組み合わせたスライスである仮想光通信ネットワークシステムごとの制御を行うものであって、それぞれの前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段を有することを特徴とする制御システム。」

[相違点]
「別個の前記光伝送路の通信帯域を設定する」ことが、本願発明3は、「別個に定められたカスタマ端末の管理に基づいて」なされるのに対し、引用発明は、この点を特定するものではない点。

(3)相違点についての判断
本願発明3において、「別個に定められたカスタマ端末」における「カスタマ端末」が、「仮想光通信ネットワークシステムごとの制御を行う」こと、及び、「前記仮想光通信ネットワークシステムに対して別個の前記光伝送路の通信帯域を設定する」こととの関係において、いかなる観点において「別個に定められた」ものであるのか必ずしも明確とはいえないので、本願明細書の記載を参照する。

本願明細書には、「カスタマ」ないし「カスタマ端末」について、次のような記載がある。

「【0021】
カスタマは、例えば、仮想移動体通信システムの提供を受けてエンドユーザ(エンドユーザが所持する端末ET)に移動体通信網を提供する事業者である。すなわち、カスタマは、例えば、MVNO(Mobile Virtual Network Operator)事業者の様に、自前の設備を有する通信キャリアにスライスを要求して受け取り、管理する機能や人(組織)であり、端末ETを使用するのは上述の通りエンドユーザ(カスタマのカスタマ)となる。各端末ETは、移動体ネットワークシステム100に接続するが、加入するカスタマの仮想移動体通信システムのみを利用することになる。」

「【0023】
ネットワークシステム1では、例えば、非特許文献1と同様のスライスアーキテクチャにより、Network Slice Blueprintとしての移動体ネットワークシステム100がスライスされるものとして説明する。ネットワークシステム1には、スライスアーキテクチャにおいてオーケストレータ機能を担うLCM&O2(IMT2020 Slice Lifecycle Management & Orchestration)が配置されている。また、図1では、2つのカスタマが利用する端末としてカスタマ端末CT-1、2000-2が配置されている。LCM&O2は、カスタマ端末CT-1、CT-2からの要求に応じて、移動体ネットワークシステム100をスライスする制御を行い、それぞれのカスタマにスライスされた仮想移動体通信システムを提供する。」

「【0033】
繰り返しになるが、カスタマに提供されるスライスは、LCM&O2が、VIM5やVNFM4から提供された資源やデータプレーンや制御プレーンに、さらにサービスとスライス管理機能等を組み合わせて構築したものである。仮想PON提供システム3により提供されるvPONは、これらの要素のうち、データプレーン及び制御プレーンの一部に相当する。すなわち、ネットワークシステム1では、仮想PON提供システム3を含む移動体ネットワークシステム100を仮想化(VNF化)することにより構成される「仮想移動体通信システム」が、各カスタマに提供される各スライスのデータプレーン及び制御プレーンの一部に相当することになる。」

「【0120】
カスタマ端末CT-2、CT-1は、それぞれ、LCM&O2に対して、自社のMVNOサービスの仕様(例えば、ネットワークシステム1を所有するキャリアとの契約の範囲内の仕様)に必要な能力を有するスライスを提供するように要求する。なお、カスタマ端末CT-2、CT-1とLCM&O2との間のインタフェースの仕様については限定されないものであり、種々のスライスアーキテクチャの構成を適用することができる。ここでは、第1のカスタマ端末CT-1は、LCM&O2に対して、仮想アンテナ装置群800-1の各仮想アンテナ装置500と仮想基地局700-2との間(すなわち、vPON600-1の区間)に固定的な帯域を用意しないタイプ(すなわち帯域共有タイプ)の仮想移動体ネットワークシステム1000-1を要求したものとする。また、第2のカスタマ端末CT-2は、LCM&O2に対して、仮想アンテナ装置群800-2の各仮想アンテナ装置500と仮想基地局700-2との間(すなわち、vPON600-2の区間)に固定的な帯域を用意するタイプ(すなわち、帯域固有タイプ)の仮想移動体ネットワークシステム1000-2を要求したものとする。
【0121】
そして、LCM&O2は、要求された各スライスの要求条件を達成するのに必要な各要素のVNF(仮想移動体ネットワークシステム1000-1、1000-2を構成する各要素のVNF)の能力を求め、各要素のINF&VNFMに必要なVNFと資源を提供するように指示する。」

上記の記載によれば、「カスタマ」は、自前の設備を有する通信キャリアにスライスを要求して受け取る事業者(機能、人、組織)であり、「カスタマ端末」は、「カスタマ」が利用する端末であり、各「仮想移動体ネットワークシステム」(本願発明3の「仮想光通信ネットワークシステム」に相当。)は、各「カスタマ(端末)」に対応しており、各「カスタマ」は、各「カスタマ端末」(CT-1、CT-2)を利用して自身に対応する「仮想移動体ネットワークシステム」の構成に関する要求を、通信キャリアの「LCM&O2」(本願発明3の「仮想光通信ネットワークシステム制御手段」に相当。)を介して、各「仮想移動体ネットワークシステム」が備える光伝送路の通信帯域を設定するものである。
そうすると、本願発明3の「カスタマ端末」は、その文言どおりの、「カスタマ」が自身に対応する「仮想光通信ネットワークシステム」の構成(光伝送路の通信帯域)を(「仮想光通信ネットワークシステム制御手段」を介して)個別に制御する端末として定められたものであるとの観点において「別個に定められた」ものであると理解することができる。
請求人も、令和3年2月15日に提出した意見書において、
「請求項3に係る発明では『(d)それぞれの前記仮想光通信ネットワークシステムに対して別個に定められたカスタマ端末の管理に基づいて別個の前記光伝送路の通信帯域を設定する仮想光通信ネットワークシステム制御手段』を備えていますが、刊行物2では、請求項3における『別個』の要件(概念)については開示も示唆もされていません。本願明細書では、段落『0102』以降等に例示されている通り、カスタマ端末CT1とCT2は、CT1は図4の第1のカスタマ向けユーザープレーン及び制御プレーンしか制御できず、CT2は図4の第2のカスタマ向けユーザープレーン及び制御プレーンしか制御できない等の設定できる範囲が限定された構成を『別個』と定義しています。しかしながら、刊行物2において、請求項3における『別個』に相当する上記のような概念は開示も示唆もされていません。」
と主張しており、当該主張は、上記の理解に整合する。

この理解に基づいて上記相違点について検討するに、引用文献2には、引用文献2記載事項にあるように、「任意の外部ネットワークコントローラ」の制御に基づいて仮想ネットワークの構成を制御することが記載されているといえるが、当該「任意の外部ネットワークコントローラ」は、各仮想ネットワークに対応して「別個に定められた」ものには限定されていないし、そのことが自明とはいえない。
また、引用文献3記載事項及び引用文献4記載事項にあるように、「カスタマ(customers)の要求に従って、スライスを作成又は変更すること。」は本願出願時における周知技術であるが、ここで、「カスタマ(customers)」としては複数のカスタマの存在を想定しているものの、引用文献3又は引用文献4は、各スライスに対応して「別個に定められた」「カスタマ端末」をも開示するものではない。
よって、上記相違点に係る本願発明3の構成は、引用発明及び引用文献2ないし4には記載されておらず、本願出願前において周知技術であるともいえない。
したがって、本願発明3は、当業者であっても引用発明及び引用文献2ないし4に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。

2 本願発明4および5について
本願発明4及び5は、上記相違点に係る本願発明3の構成を備えるものであるから、本願発明3と同じ理由により、当業者であっても引用発明及び引用文献2ないし4に記載された技術的事項に基づいて容易に発明をすることができたものであるとはいえない。

以上のとおり、当審拒絶理由は、解消した。
なお、本願発明1及び2については、当審拒絶理由の対象ではなく、また、本願発明1及び2が備える「前記仮想光通信ネットワークシステム制御手段は、複数の前記仮想子局通信装置で共有する共有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、可能な限り、1波長内で連続したタイムスロットの通信帯域を割当てるという第1の帯域設定ポリシーと、それぞれの前記子局通信装置で別個の固有通信帯域が設定された前記仮想光通信ネットワークシステムに対しては、複数波長にまたがった通信帯域を設定してもよいという第2の帯域設定ポリシーと、前記第1の帯域設定ポリシー及び前記第2の帯域設定ポリシーの範囲で、可能な限り、それぞれの前記仮想光通信ネットワークシステムに対して連続したタイムスロットの空き通信帯域を残す帯域割当てを行うという第3の帯域設定ポリシーに従って、それぞれの前記仮想光通信ネットワークシステムに対して前記光伝送路の通信帯域を割当てる」との構成は、引用文献1ないし4には記載されておらず、かつ、当業者であってもこれらの記載から容易に想到し得るものでもなく、さらに、本願出願前における周知技術であるともいえない。

第7 原査定についての判断
本件補正により、補正後の請求項3ないし5は、上記相違点に係る本願発明3の構成を有するものとなった。当該構成は、原査定における引用文献A(当審拒絶理由の引用文献1)及び引用文献Bには記載されておらず、本願出願時における周知技術でもないので、本願発明3ないし5は、当業者であっても、原査定における引用文献A及びBに基づいて容易に発明をすることができたものではない。
また、原査定時の請求項1は、本件補正により削除され、原査定時の請求項2(本願発明1に対応。)は、原査定の対象ではない。
したがって、原査定を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-03-16 
出願番号 特願2018-23098(P2018-23098)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 野元 久道  
特許庁審判長 稲葉 和生
特許庁審判官 小田 浩
林 毅
発明の名称 通信システム、制御システム、及び光通信ネットワークシステム  
代理人 吉田 倫太郎  
代理人 若林 裕介  

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