• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1375421
審判番号 不服2019-7872  
総通号数 260 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-08-27 
種別 拒絶査定不服の審決 
審判請求日 2019-06-12 
確定日 2021-07-06 
事件の表示 特願2017-534974「ビットフォワーディングイングレスルータ、ビットフォワーディングルータ及び運用管理保守テスト方法」拒絶査定不服審判事件〔平成28年 7月 7日国際公開、WO2016/107444、平成30年 1月11日国内公表、特表2018-500842、請求項の数(24)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2015年(平成27年)12月21日(パリ条約による優先権主張外国庁受理 2014年12月30日 中国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。

平成29年 8月23日 :手続補正書の提出
平成30年 8月21日付け:拒絶理由通知書
平成30年11月28日 :意見書、手続補正書の提出
平成31年 2月 6日付け:拒絶査定
令和 元年 6月12日 :拒絶査定不服審判請求書、手続補正書の提出
令和 2年 9月 8日付け:拒絶理由通知書
令和 2年12月15日 :意見書、手続補正書の提出
令和 2年12月23日付け:拒絶理由(最後の拒絶理由)通知書
令和 3年 4月26日 :意見書、手続補正書の提出

以降では、平成31年2月6日付けの拒絶査定を「原査定」、令和2年9月8日付けの拒絶理由通知書により通知された拒絶理由を「当審拒絶理由1」、令和2年12月23日付けの拒絶理由通知書により通知された拒絶理由(最後の拒絶理由)を「当審拒絶理由2」、令和3年4月26日に提出された手続補正書に係る手続補正を「本件補正」という。

第2 原査定の概要
原査定の概要は次のとおりである。

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

[引用文献等一覧]
A IJ. Wijnands,ED ,他,Encapsulation for Bit Index Explicit Replication in MPLS Networks,米国,Internet Engineering Task Force,2014年12月 4日,draft-wijnands-mpls-bier-encapsulation02,whole document,URL,https://tools.ietf.org/html/draft-wijnands-mpls-bier-encapsulation-02
B 特開2013-150342号公報
C 国際公開第2013/065210号

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

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

[引用文献等一覧]
1 国際公開第2013/065210号(拒絶査定の引用文献C)
2 IJ. Wijnands,ED ,他,Encapsulation for Bit Index Explicit Replication in MPLS Networks,米国,Internet Engineering Task Force,2014年12月 4日,draft-wijnands-mpls-bier-encapsulation02,whole document,URL,https://tools.ietf.org/html/draft-wijnands-mpls-bier-encapsulation-02(拒絶査定時の引用文献A)
3 国際公開第2011/064884号(当審において新たに引用した文献、周知技術を示す文献)

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

本願請求項1ないし24に係る発明は、以下の点において明確ではないから、特許法第36条第6項第2号に規定する要件を満たしていない。
(1)本願請求項1、12の記載において、「ビット列の長さ」が「第1のOAMリクエストパケット」のどこに含まれるのか明確ではない。
(2)本願請求項5、16の記載において、「ビット列の長さ」を含まない「第1のOAMレスポンスパケット」の技術的意義が明確ではない。
(3)本願請求項3、4、14、15の記載において、「ビット列の長さ」を含まない「(第1の)OAMレスポンスパケット」の技術的意義が明確ではない。
(4)本願請求項7、18の記載において、「TLV」によって搬送される情報と、「OAMリクエストパケット」に含まれる情報との関係が明確ではない。

第5 本願発明
本願請求項1ないし24に係る発明(以下、それぞれ「本願発明1」ないし「本願発明24」という。)は、本件補正により補正された特許請求の範囲の請求項1ないし24に記載された事項により特定される発明であり、このうち本願発明1は以下のとおりの発明である。(なお、下線部は、補正された箇所を示す。

「 ビットフォワーディングイングレスルータ(BFIR)であって、前記BFIRはビット・インデックスド・イクスプリシット・レプリケーション(BIER)ベースネットワークにあり、当該ルータは、
少なくとも1つのビットフォワーディングエグレスルータ(BFER)の識別子(ID)に従って第1の運用管理保守(OAM)リクエストパケットを取得するよう構成される第1の取得ユニットであって、前記第1のOAMリクエストパケットは、前記BFIRのID、設定識別子、前記少なくとも1つのBFERに対応するビット列及び前記ビット列の長さを含み、前記設定識別子は前記少なくとも1つのBFERに対応し、前記第1のOAMリクエストパケットは、前記BFIRと前記少なくとも1つのBFERとの間のリンクをテストするのに利用される、第1の取得ユニットと、
前記第1のOAMリクエストパケットを前記少なくとも1つのBFERに送信するよう構成される第1の送信ユニットと、
を有し、
前記第1の取得ユニットは、
前記少なくとも1つのBFERのIDに従って前記設定識別子及び前記ビット列を取得し、
前記ビット列に従って第2のOAMリクエストパケットを取得し、前記第2のOAMリクエストパケットのパケットヘッダは前記ビット列及び前記BFIRのIDを含み、前記第2のOAMリクエストパケットのペイロードは前記設定識別子、前記ビット列及び前記ビット列の前記長さを含むOAMパケットを含み、
前記設定識別子に従って第1のビット・インデックスド・イクスプリシット・レプリケーション・マルチプロトコル・ラベル・スイッチング・ラベル(BIER-MPLS Label)を前記第2のOAMリクエストパケットに挿入することによって、前記第1のOAMリクエストパケットを取得するよう構成され、前記第1のBIER-MPLS Labelは前記設定識別子に対応するラベルを含むBFIR。」

なお、本願発明2ないし4は、本願発明1の構成をすべて含むものであり、本願発明5は、本願発明1を「第1のビットフォワーディングルータ(BFR)」の発明として特定したものであり、本願発明6ないし11は、本願発明5の構成をすべて含むものであり、本願発明12は、本願発明1を「運用管理保守(OAM)テスト方法」の発明として特定したものであり、本願発明13ないし15は、本願発明12の構成をすべて含むものであり、本願発明16は、本願発明5を「運用管理保守(OAM)テスト方法」の発明として特定したものであり、本願発明17ないし22は、本願発明16の構成をすべて含むものであり、本願発明23は、本願発明12ないし15及び本願発明16ないし22を「プログラム」の発明として特定したものであり、本願発明24は、本願発明12ないし15及び本願発明16ないし22を「コンピュータ可読記憶媒体」の発明として特定したものである。

第6 引用文献、引用発明等
1 引用文献1(引用文献C)について
(1)引用文献1(引用文献C)記載事項
当審拒絶理由1に引用された引用文献1(原査定の引用文献C)には、図面とともに次の事項が記載されている。(下線は、強調のために当審が付与した。以降の下線についても同様。)

(ア)「[技術分野]
[0001]
本発明は、イーサネット(登録商標)網と、MPLS-TP(Multi Protocol Label Switching Transport Profile)網と、が接続された通信システムに関する。」

(イ)「[発明を実施するための形態]
[0032]
以下、本発明に係る、通信システム、通信方法、エッジ装置、エッジ装置制御方法、エッジ装置制御プログラム、非エッジ装置、非エッジ装置制御方法、及び、非エッジ装置制御プログラム、の各実施形態について図1?図11を参照しながら説明する。」

(ウ)「[0033]
<第1実施形態>
(構成)
図1に示したように、第1実施形態に係る通信システム1は、複数の通信装置C1,CE1,PE1,P1,P2,PE2,CE2,C2を備える。本例では、複数の通信装置C1,CE1,PE1,P1,P2,PE2,CE2,C2のそれぞれは、フレームを中継するルータ装置である。なお、複数の通信装置C1,CE1,PE1,P1,P2,PE2,CE2,C2のそれぞれは、ネットワーク・スイッチであってもよい。
[0034]
通信装置C1、及び、通信装置CE1は、イーサネット(登録商標)網EN1を構成している。また、通信装置PE1、通信装置P1、通信装置P2、及び、通信装置PE2は、MPLS-TP(Multi Protocol Label Switching Transport Profile)網MNを構成している。また、通信装置CE2、及び、通信装置C2は、イーサネット網EN2を構成している。
[0035]
通信装置PE1は、通信装置CE1、及び、通信装置P1のそれぞれと接続されている。即ち、通信装置PE1は、MPLS-TP網MNを構成する通信装置のうちの、イーサネット網EN1と接続されているエッジ装置である。また、通信装置PE1は、MEP(Maintenance End Point)を構成している。
[0036]
また、通信装置PE2は、通信装置CE2、及び、通信装置P2のそれぞれと接続されている。即ち、通信装置PE2は、MPLS-TP網MNを構成する通信装置のうちの、イーサネット網EN2と接続されているエッジ装置である。また、通信装置PE2は、MEPを構成している。
…(中略)…
[0038]
また、通信装置P1は、通信装置PE1、及び、通信装置P2のそれぞれと接続されている。即ち、通信装置P1は、MPLS-TP網MNを構成する通信装置のうちの、当該MPLS-TP網MNを構成する通信装置のみと接続されている非エッジ装置である。また、通信装置P1は、MIP(Maintenance Intermediate Point)を構成している。
[0039]
また、通信装置P2は、通信装置PE2、及び、通信装置P1のそれぞれと接続されている。即ち、通信装置P2は、MPLS-TP網MNを構成する通信装置のうちの、当該MPLS-TP網MNを構成する通信装置のみと接続されている非エッジ装置である。また、通信装置P2は、MIPを構成している。」

(エ)「[図1]



(オ)「[0045]
…(中略)…
OAMフレームは、図3に示したように、Dest(Destination) MAC(Medium Access Control)と、Source MACと、Type、OAM PDU(Protocol Data Unit)(EFP)と、を含む。
[0046]
Dest MACは、フレームの宛先を特定するための宛先MACアドレスである。
Source MACは、フレームの送信元を特定するための送信元MACアドレスである。
Typeは、フレームの種別を表すフレーム種別情報である。ここでは、Typeは、フレームの種別がOAMフレームであることを表すフレーム種別情報である。
[0047]
図3に示したように、OAM PDU(EFP)は、Op codeと、Target MEP/MIP ID TLVと、を含む。Op codeは、処理の内容を表す処理内容情報である。本例では、Op codeは、ループバック処理を表す処理内容情報である。ループバック処理は、フレームの送信元である通信装置へ当該フレームを送り返す処理である。
[0048]
Target MEP/MIP ID TLVは、MPLS-TP網MNを構成する通信装置を識別するためのMPLS通信装置識別情報である。」

(カ)「[0052]
OAMフレーム送信部12aは、図3に示したOAMフレームを生成する。
OAMフレームEFに含まれるOAM PDU(EFP)は、当該OAMフレームの宛先がMEPである場合、MPLS通信装置識別情報EFT1を含む。MPLS通信装置識別情報EFT1は、MEP ID(EFT11)を含む。MEP IDは、MPLS-TP網MNにおいて、MEPとしての通信装置を識別するための情報と、ポートを識別するための情報と、を含む。
[0053]
また、OAMフレームEFに含まれるOAM PDU(EFP)は、当該OAMフレームの宛先がMIPである場合、MPLS通信装置識別情報EFT2を含む。MPLS通信装置識別情報EFT2は、Node-ID(EFT21)と、IF-Numと、ICCと、を含む。
[0054]
Node-IDは、MPLS-TP網MNにおいて、MIPとしての通信装置を識別するための情報を含む。IF-Numは、ポートを識別するための情報を含む。ICCは、ITUT(International Telecommunication Union Telecommunication Standardization Sector)により定められたキャリア・コードである。」

(キ)「[図3]



(ク)「[0059]
図4に示したように、通信装置PE1は、フレーム制御部21と、MPLS制御部22と、クロスバースイッチ23と、を備える。」

(ケ)「[図4]



(コ)「[0064]
カプセル化処理実行部22aは、ヘッダ情報として、OAM識別子と、Source MACと、Typeと、MPLSラベルと、を含む情報を用いる。
[0065]
OAM識別子MFOは、図5に示したように、通信装置PE1がイーサネット網EN1(本例では、通信装置CE1)から受信したフレーム(即ち、イーサネットフレーム)がOAMフレームである(即ち、フレームの種別がOAMフレームであることを、フレームに含まれるフレーム種別情報が表す)場合、当該フレームに含まれる(本例では、OAM PDUに含まれる)MPLS通信装置識別情報を含む。
[0066]
具体的には、OAM識別子MFO1は、MPLS通信装置識別情報により識別される通信装置がMEPである場合、MEP ID(MFO11)と、識別子と、を含む。識別子は、OAMフレームであるか否かを表す情報と、フレームの宛先がMEP及びMIPのいずれであるかを表す情報と、を含む。
[0067]
ここでは、識別子は、フレームの宛先がMEPであることを表す情報を含む。また、識別子は、フレームがOAMフレームである場合、OAMフレームであることを表す情報を含み、一方、フレームがユーザフレームである場合、OAMフレームでないことを表す情報を含む。
[0068]
また、OAM識別子MFO2は、MPLS通信装置識別情報により識別される通信装置がMIPである場合、Node-ID(MFO21)と、識別子と、を含む。ここでは、識別子は、フレームの宛先がMIPであることを表す情報を含む。
[0069]
即ち、カプセル化処理実行部22aは、OAM識別子を、宛先MACアドレスとして(即ち、OAM識別子を宛先MACアドレスに代えて)ヘッダ情報に含ませるように構成されている、と言うことができる。」

(サ)「[図5]



(シ)「[0071]
OAM処理実行部22bは、通信装置PE1がMPLSフレームを受信した場合、又は、カプセル化処理実行部22aがMPLSフレームを生成した場合、当該MPLSフレームがOAMフレームであるか否かを判定する。具体的には、OAM処理実行部22bは、MPLSフレームが含むOAM識別子に基づいて、MPLSフレームがOAMフレームであるか否かを判定する。
[0072]
OAM処理実行部22bは、MPLSフレームがOAMフレームであると判定した場合において、MPLSフレームのヘッダ情報に含まれるOAM識別子に含まれるMPLS通信装置識別情報により識別される通信装置が自装置であるとき、OAM処理を実行する。具体的には、OAM処理実行部22bは、MPLSフレームに含まれるポート特定情報により特定されるポートが自ポート(即ち、MPLS制御部22が備えるポート)である場合、OAM処理を実行する。
[0073]
ポート特定情報は、OAM処理の対象となるポートを特定するための情報である。ここでは、ポート特定情報は、MEP IDである。
なお、OAM処理は、上記フレームに含まれる処理内容情報が表す処理の内容に基づく処理である。
[0074]
フレーム転送部22cは、通信装置PE1がMPLSフレームを受信した場合、又は、カプセル化処理実行部22aがMPLSフレームを生成した場合、当該MPLSフレームがOAMフレームであるか否かを判定する。具体的には、フレーム転送部22cは、MPLSフレームがOAM識別子に基づいて、MPLSフレームがOAMフレームであるか否かを判定する。
[0075]
フレーム転送部22cは、MPLSフレームがOAMフレームであると判定した場合において、MPLSフレームのヘッダ情報に含まれるOAM識別子に含まれるMPLS通信装置識別情報により識別される通信装置が自装置でないとき、当該MPLSフレームを他の通信装置へ転送する。」

(ス)「[0077]
なお、MPLS-TP網MNを構成する、エッジ装置PE2も、通信装置PE1と同様の構成を備える。」

(セ)「[0081]
通信装置P1は、MPLS制御部31に接続された通信装置PE1と、MPLS制御部32に接続された通信装置P2と、の間の通信を中継する。
MPLS制御部31は、フレーム転送部(フレーム転送手段)31aと、OAM処理実行部(OAM処理実行手段)31bと、を含む。
[0082]
フレーム転送部31aは、通信装置P1がMPLSフレームを受信した場合、当該MPLSフレームがOAMフレームであるか否かを判定する。具体的には、フレーム転送部31aは、MPLSフレームが含むOAM識別子に基づいて、MPLSフレームがOAMフレームであるか否かを判定する。
[0083]
フレーム転送部31aは、MPLSフレームがOAMフレームであると判定した場合において、MPLSフレームのヘッダ情報に含まれるOAM識別子に含まれるMPLS通信装置識別情報により識別される通信装置が自装置でないとき、当該MPLSフレームを他の通信装置へ転送する。
[0084]
また、フレーム転送部31aは、MPLSフレームがユーザフレームであると判定した場合、MPLSフレームのヘッダ情報に含まれるMPLSラベルに従って、当該MPLSフレームを他の通信装置へ転送する。
[0085]
OAM処理実行部31bは、通信装置P1がMPLSフレームを受信した場合、当該MPLSフレームがOAMフレームであるか否かを判定する。具体的には、OAM処理実行部31bは、MPLSフレームが含むOAM識別子に基づいて、MPLSフレームがOAMフレームであるか否かを判定する。
[0086]
OAM処理実行部31bは、MPLSフレームがOAMフレームであると判定した場合において、MPLSフレームのヘッダ情報に含まれるOAM識別子に含まれるMPLS通信装置識別情報により識別される通信装置が自装置であるとき、OAM処理を実行する。具体的には、OAM処理実行部31bは、MPLSフレームに含まれるポート特定情報により特定されるポートが自ポート(即ち、MPLS制御部31が備えるポート)である場合、OAM処理を実行する。ここでは、ポート特定情報は、OAM PDUに含まれるIF-Numである。」

(ソ)「[0088]
また、MPLS-TP網MNを構成する、非エッジ装置P2も、通信装置P1と同様の構成を備える。」

(タ)「[0115]
次に、通信装置C1が、通信装置P1のMPLS制御部31が備えるポートに対するOAMフレーム(イーサネットフレーム)を送信した場合を想定する。即ち、このOAMフレームは、通信装置P1を識別するためのNode-IDと、通信装置P1のMPLS制御部31が備えるポートを特定するためのIF-Numと、を含む。
[0116]
この場合、通信装置C1により送信されたOAMフレームは、通信装置CE1を経由して通信装置PE1により受信される。
[0117]
従って、通信装置PE1は、イーサネットフレームを受信すると、図7のステップS101にて、「Yes」と判定してステップS102へ進み、カプセル化処理を実行する(ステップS102)。
[0118]
ここでは、イーサネットフレームに含まれるフレーム種別情報は、フレームの種別が、OAMフレームであることを表す。従って、通信装置PE1は、カプセル化処理を実行することによって、OAMフレームであることを表す識別子と、通信装置P1を識別するためのNode-IDと、を含むOAM識別子と、Source MACと、Typeと、MPLSラベルと、を含むヘッダ情報を、イーサネットフレームに付加する。これにより、通信装置PE1は、MPLSフレームを生成する。
[0119]
次いで、通信装置PE1は、生成されたMPLSフレームがOAMフレームであるか否かを判定する(ステップS103)。ここでは、OAMフレームに含まれるOAM識別子は、OAMフレームであることを表す。
[0120]
従って、通信装置PE1は、「Yes」と判定してステップS104へ進み、宛先が自装置であるか否かを判定する。具体的には、通信装置PE1は、MPLSフレームのヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定する。
[0121]
ここでは、OAM識別子は、通信装置P1を識別するためのNode-IDを含む。従って、通信装置PE1は、「No」と判定してステップS108へ進み、MPLSフレームをヘッダ情報に含まれるMPLSラベルに従って、他の通信装置(ここでは、通信装置P1)へ転送(送信)する。
その後、通信装置PE1は、ステップS101へ戻り、ステップS101?ステップS109の処理を繰り返し実行する。
[0122]
この時点では、通信装置PE1により送信されたMPLSフレーム(OAMフレーム)は、通信装置P1により受信される。
[0123]
従って、通信装置P1は、MPLSフレームを受信すると、図8のステップS201にて、「Yes」と判定してステップS202へ進み、受信されたMPLSフレームがOAMフレームであるか否かを判定する。ここでは、OAMフレームに含まれるOAM識別子は、OAMフレームであることを表す。
[0124]
従って、通信装置P1は、「Yes」と判定してステップS203へ進み、宛先が自装置であるか否かを判定する。具体的には、通信装置P1は、MPLSフレームのヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定する。
[0125]
ここでは、OAM識別子は、通信装置P1を識別するためのNode-IDを含む。従って、通信装置P1は、「Yes」と判定してステップS204へ進み、MPLSフレームから、MPLS-TP網MNにてフレームを転送するためのヘッダ情報を除去するデカプセル化処理を実行する。これにより、通信装置P1は、イーサネットフレームを生成する。
[0126]
次いで、通信装置P1は、OAM処理の対象となるポートを特定する(ステップS205)。ここでは、通信装置P1は、デカプセル化処理を実行することによって生成されたイーサネットフレームに含まれるIF-Numに基づいてポートを特定する。
[0127]
そして、通信装置P1は、上記特定されたポートに対応付けられたICCと、デカプセル化処理を実行することによって生成されたイーサネットフレームに含まれるICCと、が一致している場合、当該特定されたポートに対してOAM処理を実行する(ステップS206)。このOAM処理は、デカプセル化処理を実行することによって生成されたイーサネットフレームに含まれる処理内容情報が表す処理の内容に基づく処理である。本例では、通信装置P1は、通信装置P1のMPLS制御部31が備えるポートにてループバック処理を実行する。
[0128]
これにより、通信装置P1は、OAMフレームを通信装置C1へ向けて送り返す。
その後、通信装置P1は、ステップS201へ戻り、ステップS201?ステップS208の処理を繰り返し実行する。」

(チ)[0134]
従って、通信装置P1は、「Yes]と判定してステップS203へ進み、宛先が自装置であるか否かを判定する。具体的には、通信装置P1は、MPLSフレームのヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定する。
[0135]
ここでは、OAM識別子は、通信装置P2を識別するためのNode-IDを含む。従って、通信装置P1は、「No」と判定してステップS207へ進み、MPLSフレームをヘッダ情報に含まれるMPLSラベルに従って、他の通信装置(ここでは、通信装置P2)へ転送する。
その後、通信装置P1は、ステップS201へ戻り、ステップS201?ステップS208の処理を繰り返し実行する。」

(ツ)「[0139]
次に、通信装置C1が、通信装置PE2のMPLS制御部22が備えるポートに対するOAMフレーム(イーサネットフレーム)を送信した場合を想定する。即ち、このOAMフレームは、通信装置PE2を識別するとともに、通信装置PE2のMPLS制御部22が備えるポートを特定するためのMEP IDを含む。
[0140]
この場合、通信装置C1により送信されたOAMフレームは、通信装置CE1、通信装置PE1、通信装置P1、及び、通信装置P2を経由して通信装置PE2により受信される。
[0141]
従って、通信装置PE2は、MPLSフレームを受信すると、図9のステップS301にて、「Yes」と判定してステップS302へ進み、受信されたMPLSフレームがOAMフレームであるか否かを判定する。ここでは、OAMフレームに含まれるOAM識別子は、OAMフレームであることを表す。
[0142]
従って、通信装置PE2は、「Yes」と判定してステップS303へ進み、宛先が自装置であるか否かを判定する。具体的には、通信装置PE2は、MPLSフレームのヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定する。
[0143]
ここでは、OAM識別子は、通信装置PE2を識別するとともに、通信装置PE2のMPLS制御部22が備えるポートを特定するためのMEP IDを含む。従って、通信装置PE2は、「Yes」と判定してステップS304へ進み、OAM処理の対象となるポートを特定する。ここでは、通信装置PE2は、MPLSフレームのヘッダ情報に含まれるMEP IDに基づいてポートを特定する。
[0144]
そして、通信装置PE2は、MPLSフレームから、MPLS-TP網MNにてフレームを転送するためのヘッダ情報を除去するデカプセル化処理を実行する(ステップS305)。これにより、通信装置PE2は、イーサネットフレームを生成する。
[0145]
次いで、通信装置PE2は、生成されたイーサネットフレームに含まれる処理内容情報が表す処理の内容に基づくOAM処理を、上記特定されたポートに対して実行する(ステップS306)。本例では、通信装置PE2は、通信装置PE2のMPLS制御部22が備えるポートにてループバック処理を実行する。
[0146]
これにより、通信装置PE2は、MPLSフレームとしてのOAMフレームを通信装置C1へ向けて送り返す。
その後、通信装置PE2は、ステップS301へ戻り、ステップS301?ステップS310の処理を繰り返し実行する。
[0147]
なお、通信装置C1が、通信装置PE2のフレーム制御部21が備えるポートに対するOAMフレーム(イーサネットフレーム)を送信した場合も、通信システム1は、上述した場合と同様に作動する。これにより、通信装置PE2は、通信装置PE2のフレーム制御部21が備えるポートにてループバック処理を実行する。本例では、通信装置PE2は、OAMフレームを通信装置C1へ向けて送り返す。」

(テ)「[0148]
次に、通信装置C1が、通信装置CE2のフレーム制御部12が備えるポートに対するOAMフレーム(イーサネットフレーム)を送信した場合を想定する。この場合、通信装置PE2は、図9のステップS303に進んだとき、「No」と判定してステップS307へ進む。
[0149]
そして、通信装置PE2は、MPLSフレームから、MPLS-TP網MNにてフレームを転送するためのヘッダ情報を除去するデカプセル化処理を実行する。これにより、通信装置PE2は、イーサネットフレームを生成する。
[0150]
次いで、通信装置PE2は、生成されたイーサネットフレームを通信装置CE2へ転送する(ステップS308)。
その後、通信装置PE2は、ステップS301へ戻り、ステップS301?ステップS310の処理を繰り返し実行する。」

(ト)「[0152]
このようにして、通信システム1によれば、図10に示したように、通信装置C1により送信されたOAMフレームに基づいて、通信システム1を構成する他の通信装置CE1,PE1,P1,P2,PE2,CE2,C2のそれぞれに、当該通信装置が備える各ポートにてOAM処理を実行させることができる。」

(ナ)「[図10]



(ニ)「[0155]
更に、通信システム1によれば、MPLS-TP網MN網において、OAMフレームのヘッダ情報がMPLS通信装置識別情報を含む。従って、MPLS-TP網MNを構成する通信装置PE1,P1,P2,PE2は、OAMフレームに対して、MPLS-TP網MNにてフレームを転送するためのヘッダ情報を除去するデカプセル化処理を実行することなく、当該OAMフレームを転送するか否かを決定することができる。この結果、MPLS-TP網MNにおいて、比較的高速にフレームを転送することもできる。」

(ヌ)「[0169]
なお、上記各実施形態において通信装置の各機能は、回路等のハードウェアにより実現されていた。ところで、通信装置は、処理装置と、プログラム(ソフトウェア)を記憶する記憶装置と、を備えるとともに、処理装置がそのプログラムを実行することにより、各機能を実現するように構成されていてもよい。この場合、プログラムは、コンピュータが読み取り可能な記録媒体に記憶されていてもよい。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。」

上記(ア)、(ウ)の[0034]より、引用文献1は、「イーサネット網EN1、EN2とMPLS-TP網MNとが接続されたシステム」に関するものである。
上記(ウ)の[0034]、(タ)の [0116]より、引用文献1は、「イーサネット網EN1の通信装置(C1)」から「OAMフレーム」が送信される場合を想定した処理が記載されている。
また、上記(ウ)の[0034]、[0035] [0038]より、引用文献1には、「MPLS-TP網MN」を構成する「通信装置」として、「エッジ装置」(MEP)である「PE1」と「PE2」、「非エッジ装置」(MIP)である「P1」と「P2」が例示されている。
上記(オ)の[0047]より、「OAMフレーム」は、フレームを送信元へ送り返す「ループバック処理」のためのものであって、上記(シ)の[0071]及び[0072]、並びに、上記(セ)の[0081]及び[0086]には、それぞれ、通信装置PE1及び通信装置P1が、自装置あてのOAMフレームを受信した場合、「OAM処理」を実行することが記載されている。また、上記(タ)の[0127]の記載より、上記「OAM処理」とは、具体的には「ループバック処理」のことである。さらに、上記(ス)より、「通信装置PE2」は「通信装置PE1」と同様の構成を備え、上記(ソ)より、「非エッジ装置P2」(通信装置P2)は、「通信装置P1」と同様の構成を備えるものである。
そうすると、引用文献1には、「イーサネット網EN1の通信装置(C1)から送信されるOAMフレームにより、MPLS-TP網MNにある通信装置である非エッジ装置(MIP)(P1、P2)又はエッジ装置(MEP)(PE1、PE2)に対するOAM処理(ループバック処理)を行う通信システム」が記載されており、また、上記(イ)の[0032]より、引用文献1には、当該「通信システム」における「エッジ装置」に係る発明を開示するものと認められる。
上記(ウ)の[0033]より、引用文献1に記載の「各通信装置(C1、P1、P2、PE1、PE2等)」は、「ルータ装置」である。

上記(オ)(加えて上記(キ)を参照。)より、「OAMフレーム」は、「宛先MACアドレス」(Dest MAC)と、「フレーム種別情報」(Type)、「OAM PDU」を含むものであり、さらに、上記「OAM PDU」は、「処理内容情報」(Op Code)及び「MPLS通信装置識別情報」(Target MEP/MIP ID TLV)を含むものである。
上記(タ)の[0118]より、「通信装置PE1」の「カプセル化実行部22a」は、「イーサネットフレーム」(「OAMフレーム」)に「ヘッダ情報」を付加して「MPLSフレーム」を生成するものである。また、上記(コ)の[0064]より、当該「MPLSフレーム」の「ヘッダ情報」は、「OAM識別子MFO」と、「送信元MACアドレス」(Source MAC)と、「フレーム種別情報」(Type)と、「MPLSラベル」とを含むものである。
上記(コ)の[0065]より、「OAM PDU」は、「MPLS通信装置識別情報」を含むものである。また、上記(コ)の[0066]ないし[0069]より、「OAM識別子MFO」には2種類あり、このうち「OAM識別子MFO1」は、前記「MPLS通信装置識別情報」により識別される通信装置がMEPである場合のものであって、「MEP ID」とフレームの宛先がMEPであることを表す「識別子」とを含み、「OAM識別子MFO2」は、前記「MPLS通信装置識別情報」により識別される通信装置がMIPである場合のものであって、「Node-ID」とフレームの宛先がMIPであることを表す「識別子」とを含むものである。
よって、引用文献1には、「OAM PDUに含まれるMPLS通信装置識別情報がMEPである場合のOAM識別子MFO1は、MEP IDと、フレームの宛先がMEPであることを表す識別子とを含み、OAM PDUに含まれるMPLS通信装置識別情報がMIPである場合のOAM識別子MFO2は、フレームの宛先がMIPであることを表す識別子とNode-IDを含み」との構成が記載されているといえる。
上記(カ)の[0052]及び[0053]より、引用文献1には、「OAM PDUに含まれるMPLS通信装置識別情報は、宛先がMEPである場合、MEPとしての通信装置を識別するための情報とポートを識別するための情報とを含むMPLS通信装置識別情報EFT1であり、宛先がMIPである場合、Node-IDと、IF-Numと、ICCとを含むMPLS通信装置識別情報EFT2であり」との構成が記載されているといえる。
上記(タ)の[0118]及び(コ)の[0064]及び[0065]より、エッジ装置である「通信装置PE1」は、イーサネット網EN1の「通信装置C1」から「通信装置CE1」を介して、「OAMフレーム」を受信した場合、その「カプセル化実行部22a」が、「イーサネットフレーム」(「OAMフレーム」)に「ヘッダ情報」を付加して、すなわち、カプセル化処理を実行して、「MPLSフレーム」を生成するものである。また、上記(シ)の[0072]及び[0075]並びに上記(タ)の[0121]より、「通信装置PE1」のOAM処理実行部22bは、MPLSフレームのヘッダ情報に含まれるOAM識別子に含まれるMPLS通信装置識別情報により識別される通信装置が自装置であるとき、OAM処理(ループバック処理)を実行し、「通信装置PE1」のフレーム転送部22cは、自装置でないときは、当該MPLSフレームをヘッダ情報に含まれるMPLSラベルに従って他の通信装置である「通信装置P1」へ転送(送信)するものである。
よって、引用文献1には、「エッジ装置である通信装置PE1は、イーサネット網EN1の通信装置C1から通信装置CE1を介してOAMフレームを受信した場合、カプセル化処理実行部22aが、OAMフレームに、MPLS-TP網にてフレームを転送するためのヘッダ情報を付加してMPLSフレームを生成するカプセル化処理を実行して、フレーム転送部22cが、MPLSフレームが自装置宛てでないと判定すると、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網MNの通信装置P1へ転送し」との構成が記載されているといえる。
上記(カ)の[0054]、(セ)の[0086]、(タ)の[0123]ないし[0128]、及び上記(チ)より、引用文献1には、「非エッジ装置である通信装置P1は、MPLSフレームを受信すると、OAM処理実行部31bが、ヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定し、宛先が自装置である場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、イーサネットフレームに含まれるIF-Numに基づいてポートを特定し、特定されたポートに対応付けられたキャリア・コードICCと、イーサネットフレームに含まれるICCとが一致している場合、当該特定されたポートに対して、イーサネットフレームに含まれる処理内容情報が表す処理の内容であるループバック処理を実行して、OAMフレームを通信装置C1へ向けて送り返し、一方、宛先が自装置でない場合、フレーム転送部31aが、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網の通信装置P2へ転送し」との構成が記載されているといえる。
上記(ツ)の[0141]ないし[0146]及び上記(テ)より、引用文献1には、「エッジ装置である通信装置PE2は、MPLSフレームを受信すると、ヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定し、宛先が自装置である場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、イーサネットフレームに含まれるMEP IDに基づいてポートを特定し、当該特定されたポートに対して、イーサネットフレームに含まれる処理内容情報が表す処理の内容であるループバック処理を実行して、OAMフレームを通信装置C1へ向けて送り返し、一方、宛先が自装置でない場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、生成されたイーサネットフレームをイーサネット網の通信装置CE2へ転送する」との構成が記載されているといえる。

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

「 イーサネット網EN1、EN2とMPLS-TP網MNとが接続され、
イーサネット網EN1の通信装置C1から送信されるOAMフレームにより、MPLS-TP網MNにある通信装置である非エッジ装置(MIP)P1、P2又はエッジ装置(MEP)PE1、PE2に対するOAM処理(ループバック処理)を行う通信システムにおけるエッジ装置であって、
各通信装置(C1、P1、P2、PE1、PE2等)は、ルータ装置であり、
OAMフレームは、宛先MACアドレスと、送信元MACアドレスと、フレーム種別情報と、OAM PDUを含むものであり、さらに、上記OAM PDUは、処理内容情報(Op code)及びMPLS通信装置識別情報(Target MEP/MIP ID TLV)を含み、
MPLSフレームのヘッダ情報は、OAM識別子MFOと、送信元MACアドレスと、フレーム種別情報と、MPLSラベルとを含み、
OAM PDUに含まれるMPLS通信装置識別情報がMEPである場合のOAM識別子MFO1は、MEP IDと、フレームの宛先がMEPであることを表す識別子とを含み、OAM PDUに含まれるMPLS通信装置識別情報がMIPである場合のOAM識別子MFO2は、フレームの宛先がMIPであることを表す識別子とNode-IDを含み、
OAM PDUに含まれるMPLS通信装置識別情報は、宛先がMEPである場合、MEPとしての通信装置を識別するための情報とポートを識別するための情報とを含むMPLS通信装置識別情報EFT1であり、宛先がMIPである場合、Node-IDと、IF-Numと、ICCとを含むMPLS通信装置識別情報EFT2であり、
エッジ装置である通信装置PE1は、イーサネット網EN1の通信装置C1から通信装置CE1を介してOAMフレームを受信した場合、カプセル化処理実行部22aが、OAMフレームに、MPLS-TP網にてフレームを転送するためのヘッダ情報を付加してMPLSフレームを生成するカプセル化処理を実行して、フレーム転送部22cが、MPLSフレームが自装置宛てでないと判定すると、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網MNの通信装置P1へ転送し、
非エッジ装置である通信装置P1は、MPLSフレームを受信すると、OAM処理実行部31bが、ヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定し、宛先が自装置である場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、イーサネットフレームに含まれるIF-Numに基づいてポートを特定し、特定されたポートに対応付けられたキャリア・コードICCと、イーサネットフレームに含まれるICCとが一致している場合、当該特定されたポートに対して、イーサネットフレームに含まれる処理内容情報が表す処理の内容であるループバック処理を実行して、OAMフレームを通信装置C1へ向けて送り返し、一方、宛先が自装置でない場合、フレーム転送部31aが、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網の通信装置P2へ転送し、
エッジ装置である通信装置PE2は、MPLSフレームを受信すると、ヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定し、宛先が自装置である場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、イーサネットフレームに含まれるMEP IDに基づいてポートを特定し、当該特定されたポートに対して、イーサネットフレームに含まれる処理内容情報が表す処理の内容であるループバック処理を実行して、OAMフレームを通信装置C1へ向けて送り返し、一方、宛先が自装置でない場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、生成されたイーサネットフレームをイーサネット網の通信装置CE2へ転送する、
エッジ装置。」

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

「Abstract
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies the BIER encapsulation to be used in an MPLS network.」(page1)
[当審訳]
「要約
ビット・インデックスド・イクスプリシット・レプリケーション(BIER)は、中間のルータによるフローごとの管理又は明示的な木構造プロトコルの使用を要することなく、「マルチキャストドメイン」を通じて最適なマルチキャスト転送を提供するアーキテクチャである。マルチキャストデータパケットが当該ドメインに入ると、入り口ルータが宛先となる複数の出口ルータを決定する。次に、入り口ルータは、BIERヘッダによりパケットをカプセル化する。BIERヘッダは、各ビットの各々がそのドメイン内の一の出口ルータに対応し、パケットを指定された複数の出口ルータへパケットを転送するためのビット列を含み、そのビットは、BIERヘッダ内に設定されたルータ群に対応している。カプセル化の詳細は、マルチキャストドメインを実現するために使用されるネットワークの種類に依存するが、この文書は、MPLS網に使用されるBIERカプセル化について説明する。」

「1. Introduction
…(中略)…
A router that supports BIER is known as a "Bit-Forwarding Router" (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix is a routable IP address of a BFR, and is used by BIER to identify a BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and leaves the BIER domain at one or more egress BFRs (BFERs). As specified in [BIER_ARCH], each BFR of a given BIER domain is provisioned to be in one or more "sub-domains". In the context of a given sub-domain, each BFIR and BFER must have a BFR-id that is unique within that sub-domain. A BFR-id is just a number in the range [1,65535] that, relative to a BIER sub-domain, identifies a BFR uniquely. As described in [BIER_ARCH], BIER requires that multicast data packets be encapsulated with a header that provides the information needed to support the BIER forwarding procedures. This information includes the sub-domain to which the packet has been assigned, a Set-Id (SI), a BitString, and a BitStringLength. Together these values identify the set of BFERs to which the packet must be delivered.」(page2-3)
[当審訳]
「1.序章
…(中略)…
BIERをサポートするルータは、「ビット・フォワーディング・ルータ」(BFR)として知られる。「BIERドメイン」は、複数のビット・フォワーディング・ルータ(BFRs)が接続されたものであり、その各々が、BFRプレフィクスを割り当てられる。BFRプレフィクスは、ルーティング可能なIPアドレスであり、BFRを識別するBIERによって使用される。パケットは、入り口のBFR(BFIR)からBIERドメインに入り、1又は複数の出口のBFR(BFERs)からBIERドメインを出て行く。[BIER_ARCH]に特定されているように、あるBIERドメインの各BFRは、1又は複数の「サブドメイン」に分割される。サブドメインにおいて、各BFIR及びBFERは、そのサブドメイン内でユニークなBFR-IDを有する。BFR-IDは、1?65535の範囲の数字であり、BIERドメインにおいて、BFRをユニークに識別する。[BIER_ARCH]に記載されているように、BIERにおいて、マルチキャストデータパケットは、BIER転送手続を支援するための情報を提供するヘッダによりカプセル化される。その情報は、パケットの宛先となるサブドメイン、設定識別子(SI)、ビット列、及び、ビット列長を含む。これらの値は一体として、パケットが転送される複数のBFERを識別する。」

「This document is applicable when a given BIER domain is both an IGP domain and an MPLS network. In this environment, the BIER encapsulation consists of two components:
・ an MPLS label (which we will call the "BIER-MPLS label"); this label appears at the bottom of a packet’s MPLS label stack
・ a BIER header, as specified in Section 3.
Following the BIER header is the "payload". The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, or an MPLS packet. If it is an MPLS packet, then an MPLS label stack immediately follows the BIER header. The top label of this MPLS label stack may be either a downstream-assigned label ([RFC3032]) or an upstream-assigned label ([RFC5331]). The BIER header contains information identifying the type of the payload.」(page3)
[当審訳]
「 この文書は、対象のBIERドメインが、IGPドメインとMPLS網のいずれの場合においても適用可能である。この環境において、BIERのカプセル化は、以下の2つの要素を含む。
・ MPLSラベル(これを「BIER-MPLSラベル」と呼ぶ。);このラベルはパケットのMPLSラベルスタックの底に位置する。
・ BIERヘッダ(セクション3に記載する。)
BIERヘッダに続いて「ペイロード」がある。ペイロードは、IPv4パケット、IPv6パケット、イーサネットフレーム又はMPLSパケットのいずれでもよい。MPLSパケットである場合、BIERヘッダの次に直ちにMPLSラベルのスタックが続く。MPLSラベルのスタックのトップラベルは、下流に割り当てられたラベル([RFC3032])、又は、上流に割り当てられたラベル([RFC5331])のいずれかである。BIERヘッダは、ペイロードの種類を識別する情報を含む。」

「When a BFR receives an MPLS packet, and the next label to be processed
is one of its BIER-MPLS labels, it will assume that a BIER header (see Section 3) immediately follows the stack. It will also infer the packet's sub-domain, SI, and BitStringLength from the label. The packet's "incoming TTL" (see below) is taken from the TTL field of the label stack entry that contains the BIER-MPLS label.
The BFR MUST perform the MPLS TTL processing correctly. If the packet is forwarded to one or more BFR adjacencies, the BIER-MPLS label carried by the forwarded packet MUST have a TTL field whose value is one less than that of the incoming TTL. (Of course, if the incoming TTL is 1, the packet will not be forwarded at all, but will be discarded as an MPLS packet whose TTL has been exceeded.)」(page 5)
[当審訳]
「BFRがMPLSパケットを受信し、そのBIER-MPLSラベルのうちの1つが次に処理されるラベルであるとき、BIERヘッダ(セクション3参照)が直ちにスタックに続く。当該ラベルからパケットのサブドメイン、SI及びビット列長を推測することができる。パケットの「TTL」(以下を参照)は、BIER-MPLSラベルを含むラベルスタックエントリのTTLフィールドから「着信TTL」を取り出すことができる。
BFRは、MPLS TTL処理を正確に実行しなければならない。パケットを1又は複数の隣接BFRに転送するときに、転送するパケットに含まれるBIER-MPLSラベルは、前記着信TTLの値よりも1つ小さい値のTTLフィールドを有さなければならない。(もちろん、着信TTLが1である場合、パケットはさらに転送されることはなく、代わりにTTLが超過したMPLSパケットは破棄される。」

「3. BIER Header
The BIER header is shown in Figure 1. This header appears after the end of the MPLS label stack, immediately after the MPLS-BIER label.」(page5)
[当審訳]
「3.BIERヘッダ
BIERのヘッダは図1に示されるとおりである。このヘッダは、MPLSラベルスタックの最後であって、MPLS-BIERラベルの直後に現れる。」

「Figure 1

」(page 6)
(訳は省略)

「Len:
This 4-bit field encodes the length in bits of the BitString. If k is the length of the BitString, the value of this field is log2(k)-5. However, only certain values are supported:
…(中略)…
BitString:
The BitString that, together with the packet's SI, identifies the destination BFERs for this packet. Note that the SI for the packet is inferred from the BIER-MPLS label that precedes the BIER header.
BFIR-id
By default, this is the BFR-id of the BFIR, in the sub-domain to which the packet has been assigned. The BFR-id is encoded in the 16-bit field as an unsigned integer in the range [1,65535].
Certain applications may require that the BFIR-id field contain the BFRid of a BFR other than the BFIR. However, that usage of the BFIR-id field is outside the scope of the current document.」(page 6-8)
[当審訳]
「長さ:
この4ビットは、ビット列のビット長を符号化したフィールドである。kをビット列の長さとすると、このフィールドの値は、log(k)-5となる。しかしながら、特定の値のみがサポートされている。
…(中略)…
ビット列:
ビット列は、パケットのSIと共に、このパケットの宛先のBFERを指定する。パケットのSIは、BIERヘッダに先立つBIER-MPLSラベルから推測されることに注意されたい。
BFIR-id
デフォルトでは、パケットが割り当てられるサブドメイン中の、BFIRのBFR-idである。BFR-idは、「1、65535」の範囲の符号なし整数として、16ビットのフィールドに符号化される。
特定のアプリケーションにおいては、BFIR-idフィールドがBFIR以外のBFRのBFR-idを含むように構成される。しかしながら、そのようなBFIR-idフィールドの使用は、この文書の範囲外である。」

「4. Imposing and Processing the BIER Encapsulation
When a BFIR receives a multicast packet from outside the BIER domain, the BFIR carries out the following procedure:
1. By consulting the "multicast flow layer" ([BIER_ARCH]), it determines the value of the "Proto" field.
2. By consulting the "multicast flow layer", it determines the set of BFERs that must receive the packet.
3. If more than one sub-domain is supported, the BFIR assigns the packet to a particular sub-domain. Procedures for determining the sub-domain to which a particular packet should be assigned are outside the scope of this document.
4. The BFIR looks up the BFR-id, in the given sub-domain, of each of those BFERs.
5. The BFIR converts each such BFR-id into (SI, BitString) format, as described in [BIER_ARCH].
6. All such BFR-ids that have the same SI can be encoded into the same BitString. Details of this encoding can be found in [BIER_ARCH]. For each distinct SI that occurs in the list of the packet's destination BFERs:
a. The BFIR makes a copy of the multicast data packet, and encapsulates the copy in a BIER header (see Section 3). The BIER header contains the BitString that represents all the destination BFERs whose BFR-ids (in the given sub-domain) correspond to the given SI. It also contains the BFIR's BFIR-id in the sub-domain to which the packet has been assigned.
N.B.: For certain applications, it may be necessary for the BFIR-id field to contain the BFR-id of a BFR other than the BFIR that is creating the header. Such uses are outside the scope of this document, but may be discussed in future revisions.
b. The BFIR then applies to that copy the forwarding procedure of [BIER_ARCH]. This may result in one or more copies of the packet (possibly with a modified BitString) being transmitted to a neighboring BFR.
c. Before transmitting a copy of the packet to a neighboring BFR, the BFIR finds the BIER-MPLS label that was advertised by the neighbor as corresponding to the given SI, subdomain, and BitStringLength. An MPLS label stack is then preprended(当審注:"prepended"の誤記と認められる。) to the packet. This label stack [RFC3032] will contain
one label, the aforementioned BIER-MPLS label. The "S" bit MUST be set, indicating the end of the MPLS label stack. The TTL field of this label stack entry is set according to policy. The packet may then be transmitted to the neighboring BFR. (This may result in additional MPLS labels being pushed on the stack. For example, if an RSVPTE tunnel is used to transmit packets to the neighbor, a label representing that tunnel would be pushed onto the stack.)
When an intermediate BFR is processing a received MPLS packet, and one of the BFR’s own BIER-MPLS labels rises to the top of the label stack, the BFR infers the sub-domain, SI, and BitStringLength from the label. The BFR then follows the forwarding procedures of [BIER_ARCH]. If it forwards a copy of the packet to a neighboring BFR, it first swaps the label at the top of the label stack with the BIER-MPLS label, advertised by that neighbor, that corresponds to the same SI, sub-domain, and BitStringLength. Note that when this swap operation is done, the TTL field of the BIER-MPLS label of the outgoing packet MUST be one less than the "incoming TTL" of the packet, as defined in Section 2.」(page 8-9)
[当審訳]
「4.BIERカプセル化の実行
BFIRは、マルチキャストパケットをBIERドメインの外部から受信すると、以下の手続を実行する。
1.「マルチキャストフロー層」([BIER_ARCH])を参照して、「Proto」フィールドの値を決定する。
2.「マルチキャストフロー層」を参照して、パケットを受信する複数のBFERの組を決定する。
3.1つ以上のサブドメインをサポートしている場合、BFIRは、パケットを特定のサブドメインに割り当てる。割り当ての手続はこの文書の範囲外である。
4.BFIRは、所定のサブドメインにおける、前記複数のBFERの各々のBFR-idを探す。
5.BFIRは、各BFR-idを、[BIER_ARCH]に記載されているように、(SI、ビット列)の書式に変換する。
6.同じSIを有するすべてのBFR-idを、同じビット列にコード化する。詳細は、[BIER_ARCH]を参照のこと。パケットの宛先BFERのリストに存在する個々のSIに対して:、
a.BFIRは、マルチキャストデータパケットの複製を作成し、BIERヘッダ(セクション3参照)によってその複製をカプセル化する。BIERヘッダは、そのBFR-id(所定のサブドメインにおけるもの)が所定のSIに対応する、すべての宛先BFERを表現するビット列を含む。BIERヘッダは、さらに、当該パケットが割り当てられるサブドメインにおけるBFIRのBFIR-idを含む。
注意:特定のアプリケーションにおいては、BFIR-idフィールドは、ヘッダを作成するBFIR以外のBFRのBFR-idを含む。このような使用は、この文書の範囲外であるが、将来のリビジョンで議論する余地がある。
b.次に、BFIRは、[BIER_ARCH]の複製による転送手続を実行する。それにより、(修正されたビット列を伴う)パケットの1又は複数の複製を隣接するBFRに転送する。
c.パケットの複製を隣接するBFRに転送する前に、BFIRは、所定のSI、サブドメイン及びビット列長に対応する隣接者によって報知されたBIER-MPLSラベルを発見する。次に、MPLラベルスタックは、付加される。このラベルスタック([RFC3032])は、1のラベルを含み、これは前述のBIERMPLSラベルである。MPLSラベルスタックの末尾を示す「S」ビットが設定されなければならない。このラベルスタックエントリのTTLフィールドが、ポリシーに従ってセットされる。次にパケットは隣接するBFRに転送される。(このことにより、追加のMPLSラベルがスタックにプッシュされることになる。例えば、RSVP-TEトンネルがパケットを隣接するBFRに転送するために使用される場合、トンネルを表現するラベルがスタックにプッシュされる。)
中間のBFRが受信したMPLSパケットを処理し、BFR自身のBIER-MPLSラベルの一つがラベルスタックのトップに上昇するとき、BFRは、当該ラベルから、サブドメイン、SI及びビット列長を推測する。次に、BFRは、[BIER_ARCH]の転送手続に従う。もし、隣接のBFRにパケットの複製を転送するとき、最初に、ラベルスタックのトップにあるラベルを、その隣接のBFR(同じSI、サブドメイン及びビット列長に対応する。)によって報知されたBIER-MPLSラベルに置換する。この置換処理がなされると、セクション2で定義したように、送信されるパケットのBIER-MPLSラベルのTTLフィールドは、パケットの「受信TTL」より1小さくなければならない。」

「The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, or an MPLS packet. If it is an MPLS packet, the BIER header is followed by a second MPLS label stack; this stack is separate from the stack that precedes the BIER header. For an example of an application where it is useful to carry an MPLS packet as the BIER payload, see [BIER_MVPN].」(page 9)
[当審訳]
「ペイロードは、IPv4パケット、IPv6パケット、イーサネットフレーム、又はMPLSパケットである。もし、MPLSパケットである場合、BIERヘッダは、2番目のMPLOSラベルスタック(このスタックは、BIERヘッダに先行するスタックから分離されたスタックである。)に続く。適用例として、BIERペイロードとしてMPLSパケットを搬送するのに有用である([BIER_MVPN]参照)。」

(2)引用発明2
前記ウより、引用文献2には、次の発明(以下、「引用発明2」という。)が記載されているといえる。

「 複数のビット・フォワーディング・ルータ(BFRs)が接続されたビット・インデックスド・イクスプリシット・レプリケーション(BIER)ドメインがMPLS網である場合において、
入り口側ルータであるBFIRが、マルチキャストパケットをBIERドメインの外部から受信すると、パケットの宛先となる出口側ルータである複数のBFERのBFR-idのそれぞれを(SI、ビット列)の書式に変換し、同じSIを有するすべてのBFR-idを、同じビット列にコード化し、SIごとに、マルチキャストパケットを複製して、BIERヘッダとBIER-MPLSラベルとによりカプセル化するとともに、ラベルスタックエントリのTTLフィールドにTTLを設定し、カプセル化したマルチキャストパケットを隣接するBFRに転送し、
BIERヘッダは、宛先のBFERを指定するビット列と、ビット列のビット長を符号化したフィールドと、BFIR-idを含み、
BIER-MPLSラベルは、SIとビット列長の組み合わせに対応するものであり、
中間のBFRがカプセル化されたマルチキャストパケットを受信し、これを隣接するBFRに転送する場合、BIER-MPLSラベルと、隣接するBFRから報知されたラベルに置換するとともに、当該パケットのTTLの値を、受信TTLの値を1小さくした値に変更し、
ペイロードは、IPv4パケット、IPv6パケット、イーサネットフレーム、又はMPLSパケットである、
BIERのアーキテクチャ。」

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

「[0005]OAMの機能は、障害検出、障害箇所特定、網の性能測定などの機能に大別される。特に、高い稼働率を求められる専用線サービスなどへの適用を考慮すると、装置部品の修理や交換が必要となる深刻な障害による通信断時間を最小化することが必須であり、障害発生箇所を迅速に特定するOAM機能が重要な役割を果たす。故障個所を特定するOAMとしては、網内の途中ノードで折返し、接続性試験を行うLB(Loop Back)やLT(Link Trace)、PT(Path Trace)がある。だだし、上述のようにMPLSは網内の経路(線)を指定するプロトコルであるため、網内での折返し位置を点で指定することが困難であるという特徴を有する。
[0006]このため、従来のMPLSでも使用されたPing(RFC4379:非特許文献1)などでは、転送用のMPLSラベルに存在するTTL(Time To Live)を用いて実現されている。TTLは、本来網内でループが発生した場合に無限に網内に留まることを防止するため、有限回数装置を経由(ホップ)した場合に廃棄するために導入された。パケットがLSRをホップする毎に転送用の1段目のMPLSラベルのTTLが’1’減算され、’0’になると当該装置内で当該パケットは廃棄されるという性質を有している。この性質を利用し、従来のMPLSのPingやTrace Routeは、OAMパケットを送信するノードが折返し点となるノードでちょうど’0’となるように1段目のMPLSラベルのTTLを設定することで、折返し点の指定を実現している。折返し点となるLSRでは、転送用の1段目のMPLSラベルのTTLが’0’となるため当該パケットを廃棄することになる。しかし、PingやTrace RouteをサポートしているLSRの場合、TTL’0’となったパケットは単に廃棄されるのではなく、ペイロードのチェックが行われ、PingやTrace Routeパケットであると判定すると当該パケットの折返し処理を実施する。以上のように、従来のMPLSのOAMでは、折返し処理を転送用の1段目のMPLSラベルのTTLを用いることで実現しており、現在標準化が進められているMPLS-TPのOAMにおいても同様の手法が取り入れられている。」

よって、引用文献3には、次の技術事項が記載されているといえる。

「 転送用のMPLSラベルに存在するTTLは、網内でループが発生した場合に無限に網内に留まることを防止するため、有限回数装置を経由(ホップ)した場合に廃棄するために導入され、パケットがLSRをホップする毎に転送用の1段目のMPLSラベルのTTLが’1’減算され、’0’になると当該装置内で当該パケットは廃棄されるという性質を有しているが、
PingやTrace RouteをサポートしているLSRの場合、TTL’0’となったパケットは単に廃棄されるのではなく、ペイロードのチェックが行われ、PingやTrace Routeパケットであると判定すると当該パケットの折返し処理を実施し、
MPLS-TPのOAMにおいても同様の手法が取り入れられていること。」

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

「【0023】
本図では、MPLSパスMP1の接続性をチェックするため、折返し用のOAMパケットを通信装置10AからMPLS網MP1内の折返し点を指定して折返して試験を実行するシーケンスを示している。
【0024】
第一に、通信装置10Aから1ホップの通信装置10Bのインタフェース(NIF)10B-1のIngress側を折返し用のOAMパケットの折返し点とする場合の処理の流れを説明する。
【0025】
まず通信装置10Aから折返し要求用のOAMパケット42を挿入する(P100)。この際、通信装置10Aの管理者(オペレータ)が折返しポイントや試験対象となるユーザを指定し、折返し試験の実行命令を通信装置10Aに対して実行する。この命令を通信装置10Aが受信すると、図6に示す以下の機能ブロックにより挿入処理が実施される。ノード管理部12が挿入するNIF 10B-1上のNIF管理部110に対して、挿入するポート101-n、および折返しポイントや挿入対象となるユーザを指定し、挿入命令を発行する。それを受けたNIF管理部110がOAMパケットを生成し、出力スケジューラ108に挿入要求を発行し、当該OAMパケットが挿入される。尚、OAMパケットのパケットフォーマットは図5に示しており、後述する。折返し要求用OAMパケット42は、転送用MPLSラベル(図4に示す)414-1として、LSP ID:4141にMPLSパスMP1を示すID、TC:4142にデフォルト値(本実施例では任意の値でよい)、Sビット4143に’0’、TTL:4144に’1’が付与される。さらに、ユーザ識別用MPLSラベル414-2として、LSP ID:4141にユーザを示すID、TC:4142にデフォルト値(本実施例では任意の値でよい)、Sビット4143に’0’、TTL:4144にデフォルト値(本実施例では任意の値でよい)が付与される。さらに、OAM識別用MPLSラベル414-3として、LSP ID:4141にOAMを示すID(例えば”14”)、TC:4142に’0’、Sビット4143に’1’、TTL:4144にデフォルト値(本実施例では任意の値でよい)が付与される。ペイロード部424は、本パケットが折返し要求用のOAMパケットであることを示す情報を含むフィールドである。これにより、転送用MPLSラベル414-1のTTL:4144により折返し装置として通信装置10Aから1ホップのLSRである通信装置10Bが指定され、さらにOAM識別用MPLSラベル414 ?3のTC:4142により、折返し点として通信装置10BのIngress側のNIF:10B-1が指定されたことになる。」

よって、引用文献Bには、次の技術事項が記載されているといえる。

「 MPLSパスMP1の接続性をチェックするため、折返し用のOAMパケットを通信装置10AからMPLS網MP1内の折返し点を指定して折返して試験を実行するシーケンスにおいて、通信装置10Aから1ホップの通信装置10Bのインタフェース(NIF)10B-1のIngress側を折返し用のOAMパケットの折返し点とする場合、
通信装置10Aから折返し要求用のOAMパケット42を挿入し、
折返し要求用OAMパケット42は、転送用MPLSラベル414-1として、LSP ID:4141にMPLSパスMP1を示すID、TC:4142にデフォルト値、Sビット4143に’0’、TTL:4144に’1’が付与され、
さらに、ユーザ識別用MPLSラベル414-2として、LSP ID:4141にユーザを示すID、TC:4142にデフォルト値、Sビット4143に’0’、TTL:4144にデフォルト値が付与され、
さらに、OAM識別用MPLSラベル414-3として、LSP ID:4141にOAMを示すID、TC:4142に’0’、Sビット4143に’1’、TTL:4144にデフォルト値が付与され、
これにより、転送用MPLSラベル414-1のTTL:4144により折返し装置として通信装置10Aから1ホップのLSRである通信装置10Bが指定され、さらにOAM識別用MPLSラベル414 ?3のTC:4142により、折返し点として通信装置10BのIngress側のNIF:10B-1が指定されたことになること。」

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

ア 本願発明1の「ビットフォワーディングイングレスルータ(BFIR)」は、「イングレス」の「ルータ」、すなわち、入り口側のルータといえる。
一方、引用発明において、「エッジ装置」である「通信装置PE1」は、「イーサネット網EN1の通信装置C1から通信装置CE1を介してOAMフレームを受信した場合、カプセル化処理実行部22aが、OAMフレームに、MPLS-TP網にてフレームを転送するためのヘッダ情報を付加してMPLSフレームを生成するカプセル化処理を実行して、フレーム転送部22cが、MPLSフレームが自装置宛てでないと判定すると、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網MNの通信装置P1へ転送」するものであって、かつ、「各通信装置は、ルータ装置」であるから、引用発明の「通信装置PE1」は、「MPLS-TP網MN」の入口側のルータ装置といえる。
そうすると、引用発明の「通信装置PE1」と本願発明1の「ビットフォワーディングイングレスルータ(BFIR)」とは、「入り口側のルータ」である点において共通する。

イ 引用発明において、「エッジ装置」である「通信装置PE1」は、「MPLS-TP網MN」のエッジに存在するものであり、「MPLS-TP網MN」はネットワークである。
よって、前記アを参酌すれば、引用発明と、本願発明1の「前記BFIRはビット・インデックスド・イクスプリシット・レプリケーション(BIER)ベースネットワークにあり」とは、「前記入り口側のルータはネットワークにあり」との構成を備える点において共通する。

ウ 本願発明1の「ビットフォワーディングエグレスルータ(BFER)」は、「エグレス」の「ルータ」すなわち出口側のルータといえる。
一方、引用発明において、「エッジ装置」である「通信装置PE2」は、「MPLSフレームを受信すると、ヘッダ情報に含まれるOAM識別子に基づいて宛先が自装置であるか否かを判定し」「宛先が自装置でない場合、ヘッダ情報を除去するデカプセル化処理を実行してイーサネットフレームを生成し、生成されたイーサネットフレームをイーサネット網EN2の通信装置CE2へ転送する」ものであって、かつ、「各通信装置(C1、P1、P2、PE1、PE2等)は、ルータ装置であり」であるから、引用発明の「通信装置PE2」は、「MPLS-TP網MN」の出口側のルータ装置といえる。
そうすると、引用発明の「通信装置PE2」と、本願発明1の「ビットフォワーディングエグレスルータ(BFER)」とは、「出口側のルータ」である点において共通する。

エ 引用発明において、「OAMフレーム」に含まれる「OAM PDU」に含まれる「MPLS通信装置識別情報」は、「宛先がMEPである場合、MEPとしての通信装置を識別するための情報とポートを識別するための情報とを含むMPLS通信装置識別情報EFT1であり、宛先がMIPである場合、Node-IDと、IF-Numと、ICCとを含むMPLS通信装置識別情報EFT2」であるから、「MPLS通信装置識別情報」は、「MPLS-TP網MN」の通信装置を識別するための情報すなわち「識別子(ID)」といい得るものである。
よって、前記ウを参酌すると、引用発明の「少なくとも1つのMPLS通信装置識別情報EFT1」と本願発明1の「ビットフォワーディングエグレスルータ(BFER)の識別子(ID)」とは、「少なくとも1つの出口側のルータの識別子(ID)」である点において共通する。

オ 引用発明においては、「通信装置PE1」の「カプセル化処理実行部22a」は、受信した「OAMフレーム」の「MPLS通信装置識別情報」が「MEP」であることを示す「MPLS通信装置識別情報EFT1」である場合、「OAM識別子」として「OAM識別子MFO1」を含む「ヘッダ情報」を「OAMフレーム」に付加して「MPLSフレーム」を生成している。そうすると、引用発明の「カプセル化処理実行部22a」は、「OAMフレーム」に含まれる「MPLS通信装置識別情報」に従って「MPLSフレーム」を生成するように構成されたものといえる。
ここで、「フレーム」と「パケット」とは、いずれも通信における単位データであって、前者がデータリンク層における呼称であり、後者がネットワーク層における呼称であるだけで、実質的な相違はないから、引用発明の「OAMフレーム」及び「MPLSフレーム」は、それぞれ、「OAMパケット」及び「MPLSパケット」と同一視できるものである。
また、「OAMフレーム」に「ヘッダ情報」が付加された「MPLSフレーム」(MPLSパケット)は、「OAM」すなわち「運用管理保守」を要求(リクエスト)するパケットであるから、「運用管理保守(OAM)リクエストパケット」といい得るものである。
また、引用発明において、「MPLSフレーム」を生成することは、「MPLSフレーム」を取得することにほかならず、「MPLSフレーム」を生成する機能を備える「カプセル化処理実行部22a」は、「MPLSフレーム」を取得する「取得ユニット」といい得るものである。
さらに、引用発明の「MPLSフレーム」は、「OAMフレーム」と「ヘッダ情報」のそれぞれに「当該MPLS通信装置識別情報」すなわち「出口側のルータの識別子(ID)」を含むものである。
また、「OAM処理」及び「ループバック処理」を実行するための「OAMフレーム」(OAMパケット)は、通信装置間のリンクをテストするために利用されるものであることは技術常識であり、引用発明において、「MPLSフレーム」を受信した「通信装置PE2」は、「ループバック処理」を実行して、「OAMフレーム」を通信装置C1へ向けて送り返すことから、入り口側のルータである「通信装置PE1」は、送り返された「OAMフレーム」を受信することにより、「通信装置PE1」と「通信装置PE2」との間でリンクが正しく設定されていることをテストすることができることは明らかである。
以上より、前記アないしエを参酌すると、引用発明の「カプセル化処理実行部22a」と本願発明1の「少なくとも1つのビットフォワーディングエグレスルータ(BFER)の識別子(ID)に従って第1の運用管理保守(OAM)リクエストパケットを取得するよう構成される第1の取得ユニットであって、前記第1のOAMリクエストパケットは、前記BFIRのID、設定識別子、前記少なくとも1つのBFERに対応するビット列及び前記ビット列の長さを含み、前記設定識別子は前記少なくとも1つのBFERに対応し、前記第1のOAMリクエストパケットは、前記BFIRと前記少なくとも1つのBFERとの間のリンクをテストするのに利用される、第1の取得ユニット」とは、「少なくとも1つの出口側のルータの識別子(ID)に従って第1の運用管理保守(OAM)リクエストパケットを取得するよう構成される取得ユニットであって、前記第1のOAMリクエストパケットは、前記出口側のルータのIDを含み、前記第1のOAMリクエストパケットは、前記入り口側のルータと前記少なくとも1つの出口側のルータとの間のリンクをテストするのに利用される、取得ユニット」である点において共通する。

カ 引用発明の「フレーム転送部22c」は、「MPLSフレームが自装置宛てでないと判定すると、ヘッダ情報に含まれるMPLSラベルに従って、MPLSフレームをMPLS-TP網MNの通信装置P1へ転送」する機能を備えるものであるから、「送信ユニット」といい得るものである。
よって、前記アないしオを参酌すると、本願発明1の「第1の送信ユニット」と、引用発明の「フレーム転送部2c」とは、「前記OAMリクエストパケットを前記少なくとも1つの出口側のルータに送信するよう構成される送信ユニット」である点において共通する。

キ 前記オを参酌すれば、引用発明の「OAMフレーム」も、「OAMリクエストパケット」といい得るものであるから、引用発明において、「イーサネット網EN1の通信装置C1から通信装置CE1を介してOAMフレームを受信」することは、「(第2の)OAMリクエストパケット」を「取得」するものといえる。
また、引用発明において、「OAM PDU」は、「処理内容情報(Op code)及びMPLS通信装置識別情報(Target MEP/MIP ID TLV)を含む」ものであるから、「OAMパケット」を含む「ペイロード」といい得るものである。
さらに、引用発明の「ヘッダ情報」は、「OAMフレーム」に付加されるものであるが、「付加」は「挿入」に含まれる概念である。
また、引用発明の「ヘッダ情報」に含まれる「MPLSラベル」は、「MPLS」の「ラベル」である点において、本願発明1の「第1のBIER-MPLS Label」と共通する。
そうすると、引用発明と本願発明1の
「 前記第1の取得ユニットは、
前記少なくとも1つのBFERのIDに従って前記設定識別子及び前記ビット列を取得し、
前記ビット列に従って第2のOAMリクエストパケットを取得し、前記第2のOAMリクエストパケットのパケットヘッダは前記ビット列及び前記BFIRのIDを含み、前記第2のOAMリクエストパケットのペイロードは前記設定識別子、前記ビット列及び前記ビット列の前記長さを含むOAMパケットを含み、
前記設定識別子に従って第1のビット・インデックスド・イクスプリシット・レプリケーション・マルチプロトコル・ラベル・スイッチング・ラベル(BIER-MPLS Label)を前記第2のOAMリクエストパケットに挿入することによって、前記第1のOAMリクエストパケットを取得するよう構成され、前記第1のBIER-MPLS Labelは前記設定識別子に対応するラベルを含む」とは、前記オを参酌すると、
「前記取得ユニットは、第2のOAMリクエストパケットを取得し、前記第2のOAMリクエストパケットのペイロードはOAMパケットを含み、MPLSのラベルを前記第2のOAMリクエストパケットに挿入することによって、前記第1のOAMリクエストパケットを取得するよう構成される」との構成を備える点において共通する。

(2)一致点・相違点
以上より、本願発明1と引用発明とは、以下の点において一致ないし相違する。

[一致点]
「 入り口側のルータであって、前記入り口側のルータはネットワークにあり、
当該ルータは、
少なくとも1つの出口側のルータの識別子(ID)に従って運用管理保守(OAM)リクエストパケットを取得するよう構成される取得ユニットであって、前記第1のOAMリクエストパケットは、前記出口側のルータのIDを含み、前記第1のOAMリクエストパケットは、前記BFIRと前記少なくとも1つのBFERとの間のリンクをテストするのに利用される、取得ユニットと、
前記第1のOAMリクエストパケットを前記少なくとも1つの出口側のルータに送信するよう構成される送信ユニットと、
前記取得ユニットは、
第2のOAMリクエストパケットを取得し、前記第2のOAMリクエストパケットのペイロードはOAMパケットを含み、
MPLSのラベルを前記第2のOAMリクエストパケットに挿入することによって、前記第1のOAMリクエストパケットを取得するよう構成される、
入り口側のルータ。」

[相違点]
<相違点1>
本願発明1は、「ビット・インデックスド・イクスプリシット・レプリケーション(BIER)ベースネットワーク」に関する発明であるのに対し、引用発明1は、「MPLS-TP網」に関する発明である点。
したがって、一致点である「入り口側のルータ」及び「出口側のルータ」がそれぞれ、本願発明1は、「ビットフォワーディングイングレスルータ(BFIR)」及び「ビットフォワーディングエグレスルータ(BFER)」であるのに対し、引用発明1は、「MPLS-TP網」の入り口側にある「エッジ装置」である「通信装置PE1」及び出口側にある「エッジ装置」である「通信装置PE2」である点。

<相違点2>
一致点である「第1のOAMリクエストパケット」は、本願発明1においては、「前記BFIRのID、設定識別子及び前記少なくとも1つのBFERに対応するビット列を含み、前記設定識別子は前記少なくとも1つのBFERに対応」するものであるのに対し、引用発明1における「MPLSフレーム」は、上記の「設定識別子」及び「ビット列」に相当する情報を備えない点。

<相違点3>
一致点である「取得ユニット」は、本願発明1においては、「前記少なくとも1つのBFERのIDに従って前記設定識別子及び前記ビット列を取得し、前記ビット列に従って第2のOAMリクエストパケットを取得」する「第1の取得ユニット」であるのに対し、引用発明における「カプセル化処理実行部22a」は、このような機能を備えない点。

<相違点4>
「第2のOAMリクエストパケットのペイロード」に含まれる「OAMパケット」が、本願発明1は、「前記設定識別子、前記ビット列及び前記ビット列の前記長さを含む」のに対し、引用発明は、このような構成を備えない点。

<相違点5>
「第1のOAMリクエストパケット」を「取得」するために「第2のOAMリクエストパケット」に「挿入」される「MPLSのラベル」が、本願発明1においては、「第1のビット・インデックスド・イクスプリシット・レプリケーション・マルチプロトコル・ラベル・スイッチング・ラベル(BIER-MPLS Label)であり、「前記第1のBIER-MPLS Labelは前記設定識別子に対応するラベル」であるのに対し、引用発明は、このような構成を備えない点。

(3)相違点についての判断
事案に鑑みて、先に上記相違点4について検討する。
引用発明2は、「BIERのアーキテクチャ」における「BIER」パケットに関するものであって、「BIER」パケットの「BIERヘッダ」は、「ビット列」と「ビット列のビット長を符号化したフィールド」(ビット列長)と「BFIR-id」を含み、「BIER」パケットをカプセル化する「BIER-MPLSラベル」は、「SI」(設定識別子)と「ビット列長」の組み合わせに対応するものであるが、「BIER」パケットのペイロードが「設定識別子」、「ビット列」及び「ビット列の長さ」を含むことは、引用文献2には記載も示唆もされていない。すなわち、引用発明2は「ペイロードは、IPv4パケット、IPv6パケット、イーサネットフレーム、又はMPLSパケットである」との構成を含むが、本願優先日における技術常識からして「Pv4パケット、IPv6パケット、イーサネットフレーム、又はMPLSパケット」は、「設定識別子」、「ビット列」及び「ビット列の長さ」を含むものとはいえない。
また、引用発明に、「SI」(設定識別子)、「ビット列」及び「ビット列長」(ビット列の長さ)が、「BIER」パケットの「ペイロード」とは異なる「BIERヘッダ」又は「BIER-MPLSラベル」に含まれる又は対応する引用発明2の構成を適用するにあたり、「設定識別子」、「ビット列」及び「ビット列の長さ」を、「BIER」パケットの「ペイロード」に含むように変更ないし拡張すべき理由はない。
また、上記相違点4に係る本願発明1の構成は、引用文献3にも記載されておらず、また、本願優先日前に周知技術であったともいえない。
したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

2 本願発明2ないし4について
本願発明2ないし4は、上記相違点4に係る本願発明1の構成(「第2のOAMリクエストパケット」の「ペイロード」に含まれる「OAMパケット」が、「前記設定識別子、前記ビット列及び前記ビット列の前記長さを含む」こと。)と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

3 本願発明5ないし11について
本願発明5は、本願発明1を「第1のビットフォワーディングルータ(BFR)」の発明として特定したものであって、当該「BFR」が取得する「第2のOAMレスポンスパケット」の「ペイロード」が「前記設定識別子、前記ビット列及び前記ビット列の前記長さを含むOAMパケットを含」む、という、上記相違点4に係る本願発明1の構成に対応する構成を備えるものであり、請求項6ないし11は、本願発明5の構成をすべて備えるものである。
よって、本願発明1と同じ理由により、当業者であっても、引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

4 本願発明12ないし15について
本願発明12は、本願発明1を「運用管理保守(OAM)テスト方法」の発明として特定したものであって、上記相違点4に係る本願発明1の構成を備えるものであり、また、請求項13ないし15は、本願発明12の構成をすべて備えるものである。
よって、本願発明12ないし15は、本願発明1と同じ理由により、当業者であっても、引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

5 本願発明16ないし22について
本願発明16は、本願発明5を「運用管理保守(OAM)テスト方法」の発明として特定したものであって、上記相違点4に係る本願発明1の構成に対応する構成を備えるものであり、請求項17ないし22は、本願発明16の構成をすべて備えるものである。
よって、本願発明16ないし22は、本願発明5(本願発明1)と同じ理由により、当業者であっても、引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

6 本願発明23及び24について
本願発明23は、本願発明12ないし15及び本願発明16ないし22を「プログラム」の発明として特定したものであって、また、本願発明24は、本願発明12ないし15及び本願発明16ないし22を「コンピュータ可読記憶媒体」の発明として特定したものであって、いずれも上記相違点4に係る本願発明1の構成又はこれに対応する構成を備えるものである。
よって、本願発明23及び24は、本願発明1と同じ理由により、当業者であっても、引用文献1ないし3に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

以上のとおりであるから、当審拒絶理由1は、解消した。

第8 当審拒絶理由2についての判断
(1)本件補正により、本件補正後の請求項1及び12の記載において、「ビット列の長さ」が、「第1のOAMリクエストパケット」に含まれる(「BIER-MPLS Label」を挿入する前の)「第2のOAMリクエストパケット」の「ペイロード」である「OAMパケット」に含まれることが明確となった。
(2)本件補正により、本件補正後の請求項5及び16の記載において、「第1のOAMレスポンスパケット」に「ビット列の長さ」が含まれることが明確となった。
(3)本件補正により、請求項3、4、15及び15の記載において、「(第1の)OAMレスポンスパケット」に「ビット列の長さ」が含まれることが明確となった。
(4)本件補正により、請求項7の記載において、「TLV」が「OAMリクエストパケット」の「ペイロード」に含まれることが明確となった。(請求項18は、本件補正により補正されていないが、請求項18が間接的に引用する本件補正後の請求項16の記載から、同様に理解することができる。)

以上のとおりであるから、当審拒絶理由2は、解消した。

第9 原査定についての判断
本件補正により、補正後の請求項1ないし24に係る発明は、「第2のOAMリクエストパケット」の「ペイロード」に含まれる「OAMパケット」が、「前記設定識別子、前記ビット列及び前記ビット列の前記長さを含む」という構成又はこれに対応する構成を有するものとなった。これらの構成は、原査定における引用文献AないしC(当審拒絶理由における引用文献1及び3を含む。)には記載されておらず、本願優先日前における周知技術でもないので、本願発明1ないし24は、当業者であっても、原査定における引用文献AないしCに基いて容易に発明をすることができたものではない。
したがって、原査定を維持することはできない。

第10 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-06-15 
出願番号 特願2017-534974(P2017-534974)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 大石 博見  
特許庁審判長 稲葉 和生
特許庁審判官 小田 浩
林 毅
発明の名称 ビットフォワーディングイングレスルータ、ビットフォワーディングルータ及び運用管理保守テスト方法  
代理人 大貫 進介  
代理人 伊東 忠重  
代理人 伊東 忠彦  
  • この表をプリントする

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