2022-003962

理 由

第２ 原査定の概要

原査定（令和３年１１月２５日付け拒絶査定）の概要は次のとおりである。

本願請求項１－１８に係る発明は、以下の引用文献１－２に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

＜引用文献等一覧＞

１．KUKREJA NAVIN ET AL，Demonstration of SDN-based orchestration for multi-domain Segment Routing networks，2016 18TH INTERNATIONAL CONFERENCE ON TRANSPARENT OPTICAL NETWORKS (ICTON)，IEEE，2016年07月10日，1-4，https://swan-network.it/download/publication/ICTON-2016.pdf

２．E. Rosen et al，The BGP Tunnel Encapsulation Attribute, draft-ietf-idr-tunnel-encaps-06，The BGP Tunnel Encapsulation Attribute draft-ietf-idr-tunnel-encaps-06，2017年06月14日，1-21，https://tools.ietf.org/pdf/draft-ietf-idr-tunnel-encaps-06.pdf

第３ 本願発明

本願請求項１－１８に係る発明（以下、それぞれ「本願発明１」－「本願発明１８」という。）は、令和４年３月１６日付けの手続補正で補正された特許請求の範囲の請求項１－１８に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。

「【請求項１】

パス計算要素（ＰＣＥ）により、第１のパス計算要素通信プロトコル（ＰＣＥＰ）メッセージを生成するステップであり、前記第１のＰＣＥＰメッセージは、明示的経路オブジェクト（ＥＲＯ）を含み、前記ＥＲＯは、指示情報及び複数のセグメント識別子（ＳＩＤ）を含み、前記指示情報は、前記ＳＩＤのそれぞれがそれぞれパス内のノードのＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）プレフィックスであることを示すために使用され、前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される、ステップと、

前記ＰＣＥにより、前記ＳＩＤ及び前記指示情報に従って第１のパス計算クライアント（ＰＣＣ）から第２のＰＣＣへのＩＰｖ６フォワーディングプレーン用セグメントルーティング（ＳＲｖ６）パスを確立するために、前記第１のＰＣＥＰメッセージを前記第１のＰＣＣに送信するステップと

を含む方法。」

なお、本願発明２－１８の概要は以下のとおりである。

本願発明２－４は、本願発明１を減縮した発明である。

本願発明５－８は、それぞれ本願発明１－４のパス計算要素（ＰＣＥ）による方法を、パス計算クライアント（ＰＣＣ）による方法に置き換えた発明である。

本願発明９－１２は、それぞれ本願発明１－４に対応するＰＣＥの発明であり、本願発明１－４とカテゴリ表現が異なるだけの発明である。

本願発明１３－１６は、それぞれ本願発明５－８に対応するＰＣＣの発明であり、本願発明５－８とカテゴリ表現が異なるだけの発明である。

本願発明１７は、本願発明９－１２のいずれかと本願発明１３－１６のいずれかとを含むシステムの発明である。

本願発明１８は、本願発明１－８に対応するコンピュータ読み取り可能記憶媒体の発明であり、本願発明１－８とカテゴリ表現が異なるだけの発明である。

第４ 引用文献、引用発明等

１ 引用文献１について

原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている（下線は、当審で付した。以下同じ。）。

ア 「3.HIERARCHICAL ARCHITECTURE

Figure 1(a) shows the architecture of our multi-domain hierarchal SDN-based Segment Routing network. The data-plane layer is at the moment represented by a multi-domain MPLS network (which will be extended to include other layers, such as the optical layer, in future developments). In each domain, an SDN controller provides abstraction and control of data plane. We use standard southbound interfaces; BGP-LS and PCEP of SDN controller to get network topology and to push MPLS SR tunnels. One router in each domain runs BGL-LS speaker and advertises the network topology to the controller, while every router in the network runs Path Computation Client (PCC) to enable tunnel creation and modification using PCEP.」（第２ページ第３１行から第３８行）

［当審訳］

「３．階層アーキテクチャ

図１（ａ）は、本発明のマルチドメイン階層ＳＤＮベースのセグメントルーティングネットワークのアーキテクチャを示す。データプレーン層は、現時点では、マルチドメインＭＰＬＳネットワーク（将来の開発では、光層などの他の層を含むように拡張される）によって表される。各ドメインにおいて、ＳＤＮコントローラは、データプレーンの抽象化及び制御を提供する。ネットワークトポロジを取得し、ＭＰＬＳ ＳＲトンネルをプッシュするために、ＳＤＮコントローラの標準サウスバウンドインタフェース、ＢＧＰ－ＬＳ及びＰＣＥＰを使用する。各ドメイン内の１つのルータは、ＢＧＬ－ＬＳスピーカを実行し、ネットワークトポロジをコントローラに宣伝し、一方、ネットワーク内のすべてのルータは、ＰＣＥＰを使用してトンネル作成及び修正を可能にするためにパス計算クライアント（ＰＣＣ）を実行する。」

イ 「5.RESULTS

Figure 2(a) presents an example of multi-domain TE using SR. Domain 1 has ECMP policies to maximize network utilization, while domain 2 have strict policies to enable better QoS. There are two servers, each running two different applications. Orchestrator application, based on the input policies, finds suitable SID stack and via PCEP sends that SID path to source router, which encodes the path in each packet from client. Orchestrator encodes the path as an Explicit Route Object (ERO), then using northbound PCEP tunnel-create message, it sends the path to the domain controller of source node. Figure 2(b) shows an example of ERO with prefix SID and adjacent SID. SDN controller uses PCEP protocol messages to push the path to source router creating a Label Switched Path (LSP) tunnel from source to destination. Figure 2(a) depicts the SID stack and traffic path for two applications. Application 1 has SID stack [4,45,56,68] and it takes shortest path from router 1 to router 4, then it follows a strict path crossing router 5, 6 and router 8. Application 2 has SID stack [4,45,57,78] and it also takes shortest path from router 1 to router 4 but in domain 2 it takes a strict path crossing router 5, 7 and router 8. Domain 1 does ECMP for the traffic and evenly distributes the traffic on both paths. In our implementation, we do per-destination ECMP. Traffic for server 1 takes path 1-2-4 and traffic for server 2 takes path 1-3-4. Using static routing or policy-based routing, we can map client’s traffic to different tunnels that Orchestrator creates. Figure 2(c) shows the paths that client’s traffic will take depending on the server and application type.」（第３ページ下から第５行から第４ページ第１１行）

［当審訳］

「５．結果

図２（ａ）は、ＳＲを使用するマルチドメインＴＥの例を示す。ドメイン１は、ネットワーク利用を最大化するためのＥＣＭＰポリシーを有し、ドメイン２は、より良いＱｏＳを可能にするための厳格なポリシーを有する。２つのサーバがあり、それぞれが２つの異なるアプリケーションを実行する。オーケストレータアプリケーションは、入力ポリシーに基づいて、適切なＳＩＤスタックを見つけ、ＰＣＥＰを介して、そのＳＩＤパスをソースルータに送信し、ソースルータは、クライアントからの各パケット内のパスを符号化する。オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信する。図２（ｂ）は、ＥＲＯがプレフィックスＳＩＤ及び隣接ＳＩＤを有する例を示す。ＳＤＮコントローラは、ＰＣＥＰプロトコルメッセージを使用して、パスをソースルータにプッシュし、ソースから宛先へのラベルスイッチパス（ＬＳＰ）トンネルを作成する。図２（ａ）は、２つのアプリケーションのＳＩＤスタック及びトラフィック経路を示す。アプリケーション１は、ＳＩＤスタック［４，４５，５６，６８］を有し、ルータ１からルータ４への最短経路をとり、次いで、ルータ５ ６とルータ８とを横切る厳密な経路をたどる。アプリケーション２は、ＳＩＤスタック［４，４５，５７，７８］を有し、ルータ１からルータ４への最短経路も取るが、ドメイン２では、ルータ５、７とルータ８を横切る厳密な経路を取る。ドメイン１は、トラフィックに対してＥＣＭＰを行い、トラフィックを両方の経路に均等に分配する。本実施形態では、宛先毎のＥＣＭＰを行う。サーバ１のトラフィックは経路１－２－４をとり、サーバ２のトラフィックは経路１－３－４をとる。静的ルーティング又はポリシーベースのルーティングを使用して、オーケストレータが作成する異なるトンネルにクライアントのトラフィックをマッピングすることができる。図２（ｃ）は、クライアントのトラフィックがサーバ及びアプリケーションのタイプに応じてとる経路を示す。」

ウ 「図１（ａ）

［図：0001389311000001.jpg］

」

エ 「図２（ａ）

［図：0001389311000002.jpg］

」

オ 「図２（ｂ）

［図：0001389311000003.jpg］

」

カ 「図２（ｃ）

［図：0001389311000004.jpg］

」

ここで、上記ア－カの記載から、引用文献１には、「通信に関する方法」が記載されていると認められる。

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

「ネットワーク内のすべてのルータは、ＰＣＥＰを使用してトンネル作成および修正を可能にするためにパス計算クライアント（ＰＣＣ）を実行し、

オーケストレータアプリケーションは、入力ポリシーに基づいて、適切なＳＩＤスタックを見つけ、ＰＣＥＰを介して、そのＳＩＤパスをソースルータに送信し、ソースルータは、クライアントからの各パケット内のパスを符号化し、

オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信し、

ＥＲＯがプレフィックスＳＩＤ及び隣接ＳＩＤを有し、

ＳＤＮコントローラは、ＰＣＥＰプロトコルメッセージを使用して、パスをソースルータにプッシュし、ソースから宛先へのラベルスイッチパス（ＬＳＰ）トンネルを作成する

ことを含む方法。」

２ 引用文献２について

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

「3.7. Prefix-SID Sub-TLV

[Prefix-SID-Attribute] defines a BGP Path attribute known as the "Prefix-SID Attribute". This attribute is defined to contain a sequence of one or more TLVs, where each TLV is either a "Label-Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator SRGB (Source Routing Global Block)" TLV.」（第２０ページ第４０行から第４６行）

［当審訳］

「３．７ プレフィックスＳＩＤサブＴＬＶ

［プレフィックスＳＩＤ属性］は、「プレフィックスＳＩＤ属性」として知られるＢＧＰパス属性を定義する。この属性は、１つ以上のＴＬＶのシーケンスを含むように定義される。各ＴＬＶは、「ラベルインデックス」ＴＬＶ、「ＩＰｖ６ＳＩＤ（セグメント識別子）」ＴＬＶ、又は「発信元ＳＲＧＢ（ソースルーティンググローバルブロック）」のいずれかである。」

３ その他の文献について

また、前置報告書において周知技術を示す文献として引用された引用文献３（A. SGAMBELLURI ET AL，SDN and PCE implementations for segment routing，2015 20TH EUROPEAN CONFERENCE ON NETWORKS AND OPTICAL COMMUNICATIONS，米国，IEEE，2015年06月01日，pages 1-4）には、図面とともに次の事項が記載されている。

「Fig. 4 shows a Wireshark capture at the SR Controller

detailing the PCEP session between the Controller (IP address 172.16.101.3) and the PCC (IP address 172.16.101.1). The details of PCRep message are highlighted. In particular the novel SR-ERO subobject specifies the SID type (ST set to 1, IPv4 Node ID) and the flag S is set (i.e., the SID value is null). The loose flag L is not set.」（第４ページ左欄第１行から第７行）

［当審訳］

「図４は、コントローラ（ＩＰアドレス１７２．１６．１０１．３）とＰＣＣ（ＩＰアドレス１７２．１６．１０１．１）との間のＰＣＥＰセッションを詳述するＳＲコントローラにおけるＷｉｒｅｓｈａｒｋキャプチャを示す。ＰＣＲｅｐメッセージの詳細が強調されている。特に、新規のＳＲ－ＥＲＯサブオブジェクトは、ＳＩＤタイプ（ＳＴが１に設定され、ＩＰｖ４ノードＩＤ）を指定し、フラグＳが設定される（すなわち、ＳＩＤ値がヌルである）。ルーズフラグＬはセットされない。」

「図４

［図：0001389311000005.jpg］

」

第５ 対比・判断

１ 本願発明１について

（１）対比

本願発明１と引用発明とを対比すると、次のことがいえる。

ア 引用発明において、「オーケストレータアプリケーションは、入力ポリシーに基づいて、適切なＳＩＤスタックを見つけ、ＰＣＥＰを介して、そのＳＩＤパスをソースルータに送信」していること、及び「オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信し」ていることから、引用発明の「オーケストレータアプリケーション」及び「オーケストレータ」は、本願発明１の「パス計算要素（ＰＣＥ）」に相当する。

イ 引用発明において、「オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信し」ていることから、引用発明の「ノースバウンドＰＣＥＰトンネル作成メッセージ」は、本願発明１の「第１のパス計算要素通信プロトコル（ＰＣＥＰ）メッセージ」に相当する。

ウ 引用発明において、「オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信し」ていることから、オーケストレータはノースバウンドＰＣＥＰトンネル作成メッセージを生成していることは明らかである。

エ 上記ア－ウを踏まえると、本願発明１と引用発明は、「パス計算要素（ＰＣＥ）により、第１のパス計算要素通信プロトコル（ＰＣＥＰ）メッセージを生成するステップ」を含む点で一致する。

オ 引用発明において、「オーケストレータは、パスを明示的経路オブジェクト（ＥＲＯ）として符号化し、次いで、ノースバウンドＰＣＥＰトンネル作成メッセージを使用して、パスをソースノードのドメインコントローラに送信し」ていることから、ノースバウンドＰＣＥＰトンネル作成メッセージは明示的経路オブジェクト（ＥＲＯ）を含んでいることは明らかである。

カ 引用発明において、「ＥＲＯがプレフィックスＳＩＤ及び隣接ＳＩＤを有し」ていることから、ＥＰＯは複数のセグメント識別子（ＳＩＤ）を含んでいることは明らかである。

キ 上記オ－カを踏まえると、本願発明１と引用発明は、「前記第１のＰＣＥＰメッセージは、明示的経路オブジェクト（ＥＲＯ）を含み、前記ＥＲＯは、」「複数のセグメント識別子（ＳＩＤ）を含」む点で一致する。

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

（一致点）

「パス計算要素（ＰＣＥ）により、第１のパス計算要素通信プロトコル（ＰＣＥＰ）メッセージを生成するステップであり、前記第１のＰＣＥＰメッセージは、明示的経路オブジェクト（ＥＲＯ）を含み、前記ＥＲＯは、複数のセグメント識別子（ＳＩＤ）を含む

方法。」

（相違点１）

本願発明１では「前記ＥＲＯは、指示情報」を含むのに対し、引用発明では、ＥＲＯが指示情報を含むのか明確に特定されていない点。

（相違点２）

本願発明１では「前記指示情報は、前記ＳＩＤのそれぞれがそれぞれパス内のノードのＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）プレフィックスであることを示すために使用され」るのに対し、引用発明では、前記ＳＩＤのそれぞれがそれぞれパス内のノードのＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）プレフィックスであることを示す指示情報について特定されていない点。

（相違点３）

本願発明１では「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」のに対し、引用発明では、ＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトについて特定されていない点。

（相違点４）

本願発明１では「前記ＰＣＥにより、前記ＳＩＤ及び前記指示情報に従って第１のパス計算クライアント（ＰＣＣ）から第２のＰＣＣへのＩＰｖ６フォワーディングプレーン用セグメントルーティング（ＳＲｖ６）パスを確立するために、前記第１のＰＣＥＰメッセージを前記第１のＰＣＣに送信する」のに対し、引用発明では、ソース（本願発明１の「第１のパス計算クライアント（ＰＣＣ）」に相当。）から宛先（本願発明１の「第２のＰＣＣ」に相当。）へのラベルスイッチパス（ＬＳＰ）トンネルを作成しているが、前記ＳＩＤ及び前記指示情報に従って第１のパス計算クライアント（ＰＣＣ）から第２のＰＣＣへのＩＰｖ６フォワーディングプレーン用セグメントルーティング（ＳＲｖ６）パスを確立する構成について特定されていない点。

（２）相違点についての判断

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

引用文献２には、ＳＲｖ６ＥＲＯサブオブジェクトについて記載も示唆もない。

また、上記第４の３のとおり、引用文献３には、ＥＲＯサブオブジェクトにＩＰｖ４ノードＩＤを含む技術的事項が記載されている。しかしながら、引用文献３には、相違点３に係る本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成が記載されているとはいえず、このような構成を示唆する記載もない。

そうすると、相違点３に係る本願発明１の構成は、引用文献２－３に記載されたものではなく、周知技術であるともいえないから、当業者といえども、引用発明及び引用文献２－３に記載された技術的事項から、相違点３に係る本願発明１の構成を容易に想到することはできない。

したがって、上記相違点１、２、４について判断するまでもなく、本願発明１は、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

２ 本願発明２－４について

本願発明２－４も、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

３ 本願発明５－８について

本願発明５－８は、それぞれ本願発明１－４のパス計算要素（ＰＣＥ）による方法を、パス計算クライアント（ＰＣＣ）による方法に置き換えた発明であり、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成と同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

４ 本願発明９－１２について

本願発明９－１２は、それぞれ本願発明１－４に対応するＰＣＥの発明であり、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

５ 本願発明１３－１６について

本願発明１３－１６は、それぞれ本願発明５－８に対応するＰＣＣの発明であり、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

６ 本願発明１７について

本願発明１７は、本願発明９－１２のいずれかと本願発明１３－１６のいずれかとを含むシステムの発明であり、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

７ 本願発明１８について

本願発明１８は、本願発明１－８に対応するコンピュータ読み取り可能記憶媒体の発明であり、本願発明１の「前記ＥＲＯは、複数のＩＰｖ６用セグメントルーティング（ＳＲｖ６）明示的経路オブジェクト（ＥＲＯ）サブオブジェクトを含み、前記複数のＳＲｖ６ ＥＲＯサブオブジェクトのそれぞれは、前記指示情報と、前記複数のＳＩＤのうち１つとを搬送するために使用される」構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第６ むすび

以上のとおり、本願発明１－１８は、当業者が引用発明及び引用文献２－３に記載された技術的事項に基づいて容易に発明をすることができたものではない。

したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。