2022-020449

特願２０２０－５７１４０１「光ファイバカットオーバー方法、装置、ＳＤＮコントローラ、システム、及び記憶媒体」拒絶査定不服審判事件〔令和 ２年 ６月１８日国際公開、ＷＯ２０２０／１１９６２５、令和 ３年１０月２８日国内公表、特表２０２１－５２９４５３、請求項の数（１５）〕について、次のとおり審決する。

結 論 原査定を取り消す。 本願の発明は、特許すべきものとする。

理 由 第１ 手続の経緯 本願は、２０１９年（令和元年）１２月９日（パリ条約による優先権主張外国庁受理２０１８年１２月１２日、中国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。 令和２年１２月２４日 ：手続補正書の提出 令和４年 ２月１６日付け：拒絶理由通知書 令和４年 ５月１８日 ：意見書、手続補正書の提出 令和４年 ８月 ３日付け：拒絶査定 令和４年１２月１６日 ：審判請求書の提出 第２ 本願発明 本願請求項１－１５に係る発明は、令和４年５月１８日提出の手続補正書により補正された特許請求の範囲の請求項１－１５に記載された事項により特定される次のとおりの発明である。 「 【請求項１】 対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバカットオーバー要求を取得することと、 前記光ファイバカットオーバー要求に応じて、前記光ファイバカットオーバー情報に対応するトポロジリソースを特定し、前記トポロジリソースに基づいて、前記対象光ファイバに対応する関連トラヒックの遷移ルートを特定することと、 前記遷移ルートに従って、前記関連トラヒックを遷移することと、を含み、 前記の前記遷移ルートに従って前記関連トラヒックを遷移するステップは、 関連トラヒックが正常トラヒックである場合、前記正常トラヒックを、対応する遷移ルートに遷移することと、 関連トラヒックが非正常トラヒックである場合または前記正常トラヒックが遷移失敗した場合、新たに実行した遷移の回数が閾値に達する、又は、前記関連トラヒックの対応する遷移が完了するまで、設定された時間間隔に従って、前記非正常トラヒック又は遷移失敗した前記正常トラヒックに対する遷移を新たに実行することと、を含み、 ここで、前記非正常トラヒックは最適化中、回復中、待機中のトラヒックを含む ことを特徴とする光ファイバカットオーバー方法。 【請求項２】 前記方法において、前記の前記遷移ルートに従って前記関連トラヒックを遷移した後に、 前記関連トラヒックの遷移ルートの影響種別を解析し、前記影響種別を端末に返信することを含み、ここで、前記影響種別は、対象光ファイバをカットオーバーする時に影響を受けているトラヒックの状況に基づいて確定する ことを特徴とする請求項１に記載の光ファイバカットオーバー方法。 【請求項３】 前記方法において、前記の対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバカットオーバー要求を取得する前に、 対象光ファイバの識別情報を載せたメンテナンスウィンドウ作成要求を取得することと、 前記作成要求が成功に検証された場合、メンテナンスウィンドウオブジェクトを作成し、前記メンテナンスウィンドウの対応するステートマシンの初期状態を設定して記憶することと、を含み、そのうち、前記メンテナンスウィンドウが、前記対象光ファイバの光ファイバカットオーバー情報を含み、前記ステートマシンの状態が、対応する動作モードをトリガーするために用いられる ことを特徴とする請求項１に記載の光ファイバカットオーバー方法。 【請求項４】 前記方法において、前記の前記光ファイバカットオーバー要求に応じて、前記光ファイバカットオーバー情報に対応するトポロジリソースを特定する前に、 前記光ファイバカットオーバー要求に応じて、前記対象光ファイバに対応するメンテナンスウインドウを特定し、前記メンテナンスウィンドウのステートマシンの相応の状態により、光ファイバカットオーバー動作モードへの移行をトリガーすることを含み、 前記の前記遷移ルートに従って前記関連トラヒックを遷移した後に、 次の設定された動作モードをトリガーするために、前記メンテナンスウィンドウのステートマシンの状態を更新することを含む ことを特徴とする請求項３に記載の光ファイバカットオーバー方法。 【請求項５】 前記方法において、前記の対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバカットオーバー要求を取得する前に、以下のウィンドウメンテナンス操作の少なくとも一つが実行されることを含み、 ウィンドウ識別情報を載せたメンテナンスウィンドウ削除要求を取得し、前記削除要求に応じて、対応するメンテナンスウィンドウを探し出し、前記対応するメンテナンスウィンドウを削除することと、 ウィンドウ識別情報を載せたメンテナンスウィンドウ更新要求を取得し、前記更新要求が成功に検証されたと判断すると、前記更新要求に応じて、対応するメンテナンスウィンドウを更新して記憶することと、 ウィンドウ識別情報を載せたメンテナンスウィンドウ問い合わせ要求を取得し、前記問い合わせ要求に応じて、対応するメンテナンスウィンドウの問い合わせ結果を特定することである ことを特徴とする請求項３に記載の光ファイバカットオーバー方法。 【請求項６】 前記方法において、前記の対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバカットオーバー要求を取得する前に、 対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバシミュレーションカットオーバー要求を取得することと、 前記光ファイバシミュレーションカットオーバー要求に応じて、前記光ファイバカットオーバー情報に対応するトポロジリソースを特定し、前記トポロジリソースに基づいて、前記対象光ファイバに対応する関連トラヒックのルーティング計算結果を特定することと、 前記ルーティング計算結果に基づいて、対応するシミュレーションカットオーバー結果を特定して端末に返信することと、を含む ことを特徴とする請求項１に記載の光ファイバカットオーバー方法。 【請求項７】 前記の前記ルーティング計算結果に基づいて、対応するシミュレーションカットオーバー結果を特定して端末に返信することは、 前記ルーティング計算結果に基づいて前記関連トラヒックを遷移することができると特定した場合、前記関連トラヒックが遷移したトラヒック経路を、シミュレーションカットオーバー結果として端末に返信することを含む ことを特徴とする請求項６に記載の光ファイバカットオーバー方法。 【請求項８】 前記の前記ルーティング計算結果に基づいて、対応するシミュレーションカットオーバー結果を特定して端末に返信することは、さらに、 関連トラヒックが遷移失敗した場合、新たに実行した遷移の回数が閾値に達する、又は、前記関連トラヒックの対応する遷移が完了するまで、設定された時間間隔に従って、前記遷移失敗した前記関連トラヒックに対する遷移を新たに実行することと、 前記ルーティング計算結果に基づいて前記関連トラヒックが遷移不能であることを特定した場合、前記関連トラヒックが遷移不能であることを、シミュレーションカットオーバー結果として端末に返信することと、を含む ことを特徴とする請求項７に記載の光ファイバカットオーバー方法。 【請求項９】 前記方法において、前記の前記遷移ルートに従って前記関連トラヒックを遷移した後に、 前記対象光ファイバの識別情報を載せたカットオーバーリターン要求を取得することと、 前記カットオーバーリターン要求に応じて、前記対象光ファイバのカットオーバー前のトラヒック経路が正常であると特定した場合、前記関連トラヒックを、前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えることと、を含む ことを特徴とする請求項１に記載の光ファイバカットオーバー方法。 【請求項１０】 前記方法において、前記の前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えた後に、 前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えたことに対応して形成されたカットオーバーリターン結果を端末に送信することを含む ことを特徴とする請求項９に記載の光ファイバカットオーバー方法。 【請求項１１】 前記の前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えたことに対応して形成されたカットオーバーリターン結果を端末に送信することは、 前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えることが成功した場合、カットオーバーリターンが成功した結果を端末に送信することと、 前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えることが成功しなかった場合、繰り返し実行の回数が予め設定された値に達するまで、前記関連トラヒックを前記対象光ファイバのカットオーバー前のトラヒック経路に切り替えるステップを設定サイクルに従って繰り返し実行し、対応する関連トラヒックのカットオーバーリターン不成功の結果を端末に送信し、あるいは、繰り返し実行の回数が前記予め設定された値に達する前に、カットオーバーリターンが成功していると判定し、カットオーバーリターンが成功した結果を端末に送信することと、を含む ことを特徴とする請求項１０に記載の光ファイバカットオーバー方法。 【請求項１２】 対象光ファイバの光ファイバカットオーバー情報を載せた光ファイバカットオーバー要求を取得するように構成された変換モジュールと、 前記光ファイバカットオーバー要求に応じて、前記光ファイバカットオーバー情報に対応するトポロジリソースを特定し、前記トポロジリソースに応じて、前記対象光ファイバに対応する関連トラヒックの遷移ルートを特定し、前記遷移ルートに従って前記関連トラヒックを遷移するように構成された光ファイバカットオーバーモジュールと、を備え、 前記光ファイバカットオーバーモジュールは、関連トラヒックが正常トラヒックである場合、前記正常トラヒックを、対応する遷移ルートに遷移し、関連トラヒックが非正常トラヒックである場合または前記正常トラヒックが遷移失敗した場合、新たに実行した遷移の回数が閾値に達する、又は、前記関連トラヒックの対応する遷移が完了するまで、設定された時間間隔に従って、前記非正常トラヒック又は遷移失敗した前記正常トラヒックに対する遷移を新たに実行するようにさらに構成され、ここで、前記非正常トラヒックは最適化中、回復中、待機中のトラヒックを含む ことを特徴とする光ファイバカットオーバー装置。 【請求項１３】 プロセッサと、プロセッサ上で実行可能なコンピュータプログラムを記憶するためのメモリーとを備えるＳＤＮコントローラであって、 前記プロセッサは、前記コンピュータプログラムを実行する際に、請求項１～１１のいずれか１項に記載の光ファイバカットオーバー方法を実行することに用いられる ことを特徴とするＳＤＮコントローラ。 【請求項１４】 光ファイバカットオーバーシステムであって、 アプリケーションサーバと請求項１３に記載のＳＤＮコントローラとを含み、 前記アプリケーションサーバは、端末が送信した命令を受信し、前記命令を前記ＳＤＮコントローラのノースバウンドインターフェースに送信することに用いられ、 前記ＳＤＮコントローラは、サウスバウンドインターフェースを介して機器側と通信する ことを特徴とする光ファイバカットオーバーシステム。 【請求項１５】 記憶媒体であって、 前記記憶媒体には実行可能な命令が記憶され、 前記実行可能な命令がプロセッサにより実行された場合、請求項１～１１のいずれか１項に記載の光ファイバカットオーバー方法を実現する、 ことを特徴とする記憶媒体。」 第３ 原査定の概要 原査定（令和４年８月３日付け拒絶査定）の概要は次のとおりである。 この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 １ 請求項１、１２には、「正常トラヒック」、「非正常トラヒック」との記載がある。 発明の詳細な説明や技術常識を踏まえても、「非正常トラヒック」とは技術的にどのようなものなのか不明である。 特に、発明の詳細な説明（段落［００２０］等参照。）には、「非正常トラヒック」の具体例として、「最適化中、回復中、待機中のトラヒック」が挙げられているが、「最適化中、回復中、待機中のトラヒック」についても、発明の詳細な説明や技術常識を踏まえても、技術的にどのようなものなのか不明である。 また、「非正常トラヒック」自体や「非正常トラヒック」の具体例が、技術的にどのようなものなのか不明であることに起因して、どのようなトラヒックであれば、「非正常トラヒック」といえ、あるいは、「非正常トラヒック」とはいえないのか、明瞭に把握（区別）することができない。 さらに、「非正常トラヒック」が、技術的にどのようなものなのか不明であることに起因して、「非正常トラヒック」の補集合と思料される「正常トラヒック」についても、どのようなトラヒックであれば、「正常トラヒック」といえ、あるいは、「正常トラヒック」とはいえないのか、明瞭に把握（区別）することができない。 よって、請求項１、１２及び請求項１に従属する請求項２－１１、１３－１５に係る発明は明確でない。 ２ 請求項２には、「関連トラヒックの遷移ルートの影響種別」との記載があるが、発明の詳細な説明や技術常識を踏まえても、「影響種別」とは技術的にどのようなものなのか不明である。 特に、発明の詳細な説明（段落［００３７］等参照。）には、「影響種別」を用いてどのような動作を行うのか開示されてはいるが、そのような記載からも、「影響種別」自体がどのようなものなのか、把握することができない。 また、「影響種別」が、技術的にどのようなものなのか不明であることに起因して、どのような種別であれば、「影響種別」といえ、あるいは、「影響種別」とはいえないのか、明瞭に把握（区別）することができない。 よって、請求項２及び従属する請求項１３－１５に係る発明は明確でない。 第４ 原査定についての判断 １ 「非正常トラヒック」及び「最適化中、回復中、待機中のトラヒック」が不明であるという点については、令和４年１２月１６日提出の審判請求書における、 「以下に、「非正常トラヒック」における「最適化中」のトラヒック、「回復中」のトラヒック、「待機中」のトラヒックについて、説明しながら例示します。 最適化中のトラヒック：トラヒックを最適化する、とは、より優れたルーティングポリシーの経路を使用してトラヒックを載せることです。 例えば、中国特許１７１０９９３Ｂ（公開日：２００５年１２月２１日）の段落［００１２］、［００２６］と「００３２」には、以下が記載されています。 ［００１２］ ．．．ＬＳＰに障害が発生していないが、ネットワークトポロジーの変化に伴い、既存のトラヒック経路が最適でなくなる可能性がある場合には；または、ネットワークメンテナンスのため、一時的にいくつかのトラヒックを別の経路に遷移する必要がある場合には．．．。 ［００２６］ ．．．まず、無障害のＬＳＰに最適化機能を提供することにより、より優れた又は必要な路経にトラヒックを切り替え；次に、本発明の切り替えはシームレスな切り替えであるので、トラヒックの中断時間を短縮させる。 ［００３２］ 本発明では、トラヒックの中断時間をできるだけ短縮するように、１＋１保護などのデュアル送信選択受信メカニズムにより最適化することができ、即ち、最適化後のＬＳＰトラヒックの作成が成功した後、トラヒックをスイッチングし、そして最適化前のＬＳＰトラヒックを削除することにより、トラヒックの最適化プロセス全体を完了する。 上記から理解されるように、より優れた又はより必要な路経へ遷移されているトラヒックは「最適化中のトラヒック」です。 回復中のトラヒック：トラヒックを回復する、とは、トラヒックが何らかの理由で中断されてから再開することです。 例えば、中国特許１０２４８７３２９Ｂ（公開日：２０１２年６月６日）の段落［０００５］には以下が記載されています。 ［０００５］ ＡＳＯＮネットワークにおける広範な無保護トラヒックについては、トラヒックが通過するあるリンクに障害が発生すると、トラヒックを回復する必要があります。通常の方法は、回復に必要なトラヒックの最初のノードで、元のＬＳＰ（Ｌａｂｅｌ Ｓｗｉｔｃｈｅｄ Ｐａｔｈ，ラベルスイッチパス）と同じ最初のノードと最後のノードとを有する新しいＬＳＰを動的に作成して、そして故障のあるＬＳＰから当該新しいＬＳＰにトラヒックをスイッチングする、ということである。 以上から理解されるように、リンクの故障から回復されているトラヒックは、「回復中のトラヒック」です。 待機中のトラヒック：トラヒックが待機する、とは、トラヒックが最適化または回復されるまでの無効期間を指します。 例えば、中国特許１９８３８９０Ｂ（公開日：２００７年６月２０日）の段落［０００２］には、以下が記載されています。 ［０００２］ ＳＤＨ保護はチャネル保護、単方向多重段保護、２光ファイバ双方向多重段保護、４光ファイバ双方向多重段保護などを含み、ここで、２光ファイバ双方向多重段保護は、ノードにおいて無効とした後、このノード前後のトラヒックがすべて中断される。ノードが回復しても、このノードのトラヒックがすぐに回復せず、ＷＴＲ（ｗａｉｔ ｔｏ ｒｅｓｔｏｒｅ，回復待ち時間）がタイムアウトになった後でトラヒックが回復されるので、トラヒックの回復には非常に時間がかかる。 以上から理解されるように、回復待ち時間（ＷＴＲ）におけるトラヒックは、「回復中のトラヒック」です。 上記の説明と例示によれば、「非正常トラヒック」における「最適化中のトラヒック」、「回復中のトラヒック」及び「待機中のトラヒック」がいずれも、本願出願当時に、当業者にとって既知であるため、「非正常トラヒック」は明確であり、その補集合「正常トラヒック」も明確である、と思量致します。」 との主張、また、本願の特許請求の範囲、明細書及び図面（以下「本願明細書等」という。）の記載並びに本願優先日の技術常識を踏まえれば、上記「非正常トラヒック」及び「最適化中、回復中、待機中のトラヒック」という記載は、第三者に不測の不利益を及ぼすほどに不明確であるとはいえない。 ２ 「影響種別」が不明であるという点については、令和４年１２月１６日提出の審判請求書における、 「以下に、「影響種別」について、説明しながら例示します。（１）「影響種別」は光ファイバの減衰程度であってよく、例えば、光ファイバの減衰程度が過大である場合、システムが警告を発することができ、その時、ネットワーク管理者は迅速に認知し、トラヒックの一部の遷移を特定することにより、光ファイバの減衰を低減することができます。 例えば、中国特許１０６６０３２６３Ｂ（公開日：２０１７年４月２６日）の要約書および段落［００４８］には以下の記載があります。 ［要約書］ 本発明は、トラヒックをカットオーバーするための方法、装置および設備を提供する。本方法は、ネットワーク管理者を介してカットオーバー組をカットオーバーするトラヒックの配置を受信することと、カットオーバー組における各トラヒックの光パワーを検索して、検索結果に基づいて各トラヒックの基準光パワーと閾値を設定することと、カットオーバー組のカットオーバートラヒックに対してカットオーバーすることと、カットオーバー成功後、再度検索されたカットオーバー組における各トラヒックの現在の光パワーと基準光パワーとを比較し、光パワーの偏差が閾値範囲以内である場合、カットオーバー後のトラヒックが正常に運行していると判断し、閾値範囲以内でない場合、カットオーバー後のトラヒックに異常が発生したと判断して、エラーメッセージを送信することとを含む。本発明が提供するトラヒックをカットオーバーするための方法により、一括トラヒックのカットオーバーを実現でき、大幅にトラヒックをカットオーバーする効率を向上させる。また、カットオーバー前後のトラヒックの光パワー偏差を比較して、作業員がカットオーバー後のトラヒックが正常に運行するか否かを迅速に確認するのを容易にし、カットオーバーの成功率を保証する。［００４８］ ．．．光パワー偏差判断モジュールは、トラヒックをカットオーバーした後、トラヒックの光パワーが需要を満たすかどうかを判断するために用いられる。光パワー偏差が正常である場合、カットオーバー後のトラヒックが正常に運行していると確認し、逆に、光パワー偏差が比較的大きく、正常な偏差範囲をオーバーする場合、エラーメッセージを送信し、作業員に当該トラヒックを調整する必要があることを注意し、または増幅器の利得やＬＡＣの減衰を調整する。ネットワーク管理者は当該エラーメッセージを受信して、光パワー偏差が偏差閾値を超えるトラヒックを赤でハイライトして警告して、カットオーバー人員が迅速に異常なトラヒックの位置を決めて適時に調整することを容易にする。（２）「影響種別」は関連トラヒックの中断であってもよく、例えば、対象光ファイバがカットオーバーされた後、関連トラヒックが中断されており、その場合、ネットワーク管理者は関連トラヒックの中断といった影響種別によってリンクのロックを解除することができます。この関連トラヒックの中断は当技術分野において公知であり、また、トラヒックが中断している時にリンクに対してロックを解除することも当技術分野において公知である、ということにご留意ください。 上記の説明および例示によれば、「影響種別」は当業者にとって既知であるので、「影響種別」は明確であると思量致します。」 との主張、また、本願明細書等の記載及び本願優先日の技術常識を踏まえれば、上記「影響種別」という記載は、第三者に不測の不利益を及ぼすほどに不明確であるとはいえない。 したがって、本願請求項１－１５に係る発明は明確である。 第５ むすび 以上のとおり、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。