ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 H04L |
---|---|
管理番号 | 1347436 |
審判番号 | 不服2018-5045 |
総通号数 | 230 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2019-02-22 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2018-04-12 |
確定日 | 2019-01-28 |
事件の表示 | 特願2016-544700「経路制御方法、デバイス、およびシステム」拒絶査定不服審判事件〔平成27年 4月 2日国際公開、WO2015/043327、平成28年12月 1日国内公表、特表2016-537925、請求項の数(11)〕について、次のとおり審決する。 |
結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
理由 |
第1 手続の経緯 本願は、2014年(平成26年)8月14日(パリ条約による優先権主張外国庁受理 2013年9月30日、中国)を国際出願日とする出願であって、平成28年5月10日に手続補正がされ、平成29年4月4日付けの拒絶理由の通知に対し、平成29年7月11日に意見書が提出されるとともに手続補正がなされたが、、平成29年12月5日付けで拒絶査定(原査定)がされ、これに対し、平成30年4月12日に拒絶査定不服審判の請求がされると同時に手続補正がされたものである。 第2 原査定の概要 原査定(平成29年12月5日付け拒絶査定)の概要は次のとおりである。 本願請求項1-11に係る発明は、以下の引用文献1-3に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献等一覧 1.特開2004-289647号公報 2.特開2006-203904号公報 3.特開2002-223235号公報 第3 本願発明 本願請求項1-11に係る発明(以下、それぞれ「本願発明1」-「本願発明11」という。)は、平成30年4月12日付けの手続補正で補正された特許請求の範囲の請求項1-11に記載された事項により特定される発明であり、以下のとおりの発明である。 「 【請求項1】 ネットワークノードが、サービス・データ・パケットを受信するステップと、 前記ネットワークノードが、ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索するステップであって、前記集約識別子は1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有し、前記転送テーブルは、前記集約識別子および前記集約識別子に対応する前記ネクストホップ情報を含む、ステップと、 前記ネットワークノードが、前記獲得されたネクストホップ情報に従って前記サービス・データ・パケットを転送するステップとを含み、 前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む、 経路制御方法。 【請求項2】 前記ネットワークノードが、ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索する前記ステップの前に、 前記ネットワークノードが前記ネットワークノードはインテリジェント経路制御ネットワークシステムのファーストホップであると判定したときに、前記ネットワークノードが、前記サービス・データ・パケットのサービスフロー特徴情報に対応する集約識別子を獲得するために、前記サービスフロー特徴情報に従ってネットワーク要件集約マッピングテーブルを探索するステップであって、前記ネットワーク要件集約マッピングテーブルは、前記サービスフロー特徴情報、および前記サービスフロー特徴情報に対応する前記集約識別子を含む、ステップと、 前記獲得された集約識別子を前記サービス・データ・パケットに追加するステップとをさらに含む、請求項1に記載の経路制御方法。 【請求項3】 前記獲得された集約識別子を前記サービス・データ・パケットに追加する前記ステップは、 前記獲得された集約識別子を、ユーザ・データグラム・プロトコル(UDP)パケットの拡張フィールドに追加するステップを含む、請求項2に記載の経路制御方法。 【請求項4】 前記ネットワークノードが前記インテリジェント経路制御ネットワークシステムのファーストホップとラストホップとの間の中間ノードである場合に、前記ネットワークノードによって受信される前記サービス・データ・パケットは前記集約識別子を搬送し、 前記ネットワークノードが、ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索する前記ステップは、 前記ネットワークノードが、前記ネクストホップ情報を獲得するために、前記ネットワークノードによって受信された前記サービス・データ・パケットで搬送された前記集約識別子に従って前記転送テーブルを探索するステップを含む、請求項1から3のいずれか一項に記載の経路制御方法。 【請求項5】 前記サービスフロー特徴情報は、前記サービス・データ・パケットで搬送される宛先IPアドレスおよび送信元インターネットプロトコル(IP)アドレスのうちの少なくとも1つを含む、請求項2または3に記載の経路制御方法。 【請求項6】 ネットワークノードが、サービス・データ・パケットを受信する前記ステップの前に、 前記ネットワークノードが、制御エンティティから前記転送テーブルを取得するステップ、 をさらに含む、請求項1から5のいずれか一項に記載の経路制御方法。 【請求項7】 経路制御を制御するための方法であって、 制御エンティティが、転送テーブルを生成するステップであって、前記転送テーブルは、集約識別子および前記集約識別子に対応するネクストホップ情報を含み、前記集約識別子は1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有する、ステップと、 前記制御エンティティが、前記転送テーブルをネットワークノードへ送信するステップとを含み、 前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む、 方法。 【請求項8】 サービス・データ・パケットを受信するように構成された受信部と、 ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索するように構成された転送テーブル探索部であって、前記集約識別子は1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有し、前記転送テーブルは、前記集約識別子および前記集約識別子に対応する前記ネクストホップ情報を含む、転送テーブル探索部と、 前記獲得されたネクストホップ情報に従って前記サービス・データ・パケットを転送するように構成された送信部とを含み、 前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む、 ネットワークノード。 【請求項9】 前記ネットワークノードが前記ネットワークノードはインテリジェント経路制御ネットワークシステムのファーストホップであると判定した場合に、前記サービス・データ・パケットのサービスフロー特徴情報に対応する集約識別子を獲得するために、前記サービスフロー特徴情報に従って、前記サービスフロー特徴情報および前記サービスフロー特徴情報に対応する前記集約識別子を含むネットワーク要件集約マッピングテーブルを探索し、 前記獲得された集約識別子を前記サービス・データ・パケットに追加する、ように構成された、集約識別子追加部をさらに含む、請求項8に記載のネットワークノード。 【請求項10】 前記集約識別子追加部は、 前記獲得された集約識別子をユーザ・データグラム・プロトコル(UDP)パケットの拡張フィールドに追加するように特に構成されている、請求項9に記載のネットワークノード。 【請求項11】 ネットワークにおいて集中式または分散式で配置された制御エンティティであって、 複数のネットワークノード間のリアルタイムのネットワーク状況情報を収集するように構成された受信部と、 前記ネットワーク状況情報に従って転送テーブルを生成するように構成された処理部であって、前記転送テーブルは、集約識別子および前記集約識別子に対応するネクストホップ情報を含み、前記集約識別子は1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有する、処理部と、 前記転送テーブルをネットワークノードへ送信するように構成された送信部とを含み、 前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む、 制御エンティティ。」 第4 引用文献1、引用発明について 原査定の拒絶の理由に引用された引用文献1には、図面とともに次の事項が記載されている。なお、下線は当審にて付与したものである。 「【0001】 【発明の属する技術分野】 この発明は、MPLS(Multi Protocol Label Switching)を用いてネットワーク上に複数のトンネリングを張り、その中から所定のトンネリングを選出してパケットのデータ中継を行うデータ中継方法、データ中継装置およびその装置を用いたデータ中継システムに関するものである。」 「【0020】 (実施の形態) 図3は、この発明にかかるデータ中継システムの一実施の形態の構成を示すシステム構成図である。図において、この実施の形態では、それぞれ特定のユーザ端末11,21が設けられたローカルネットワーク10,20と、バックボーンネットワークであるMPLSネットワーク30とを、各ネットワークの境界に設けたエッジルータ40,50で接続させるとともに、MPLSネットワーク30内には、複数のコアルータ60?80が設けられ、これらコアルータ60?80は、エッジルータ40,50と接続されている。この実施の形態では、上述した構成によって、特定ユーザのローカルネットワーク10,20間でMPLSのラベルスイッチング方式によってLSPのトンネリングを張って、パケットのデータ中継を行うことが可能となる。 【0021】 ここで、ユーザ端末11がパケットの送信元の端末で、ユーザ端末21がこのパケットの宛先の端末とすると、送信側エッジルータ40は、ローカルネットワーク10から受信したパケットにMPLSラベルを付与して、MPLSネットワーク30に転送するMPLS Ingress Edge ルータの機能を有し、宛先側エッジルータ50は、転送されてきたパケットからMPLSラベルをはずして、ローカルネットワーク20に転送するMPLS Egress Edge ルータの機能を有している。また、コアルータ60?80は、受信したパケットのMPLSラベルから出力ポートを決定して新しいラベルを付与する機能を有している。 【0022】 このMPLS Ingress Edge ルータの機能を有する送信側エッジルータ40は、図4の構成図に示すように、ルーティングプロトコル処理部41と、MPLS処理部42と、ユーザインターフェース処理部43と、ルートテーブル44とラベル選択テーブル45の2つのテーブルと、ルートテーブル44の検索を行うルートテーブル検索部46と、ラベル選択テーブル45の検索結果に基づいてラベル情報リストを選択するMPLSラベル選択部47とから構成されている。また、このエッジルータ40は、宛先側エッジルータとしての機能を有する場合もあるので、後述するエッジルータ50の構成を備えることも可能である。 【0023】 ルーティングプロトコル処理部41は、たとえばOSPFなどのルーティングプロトコルを用いて、隣り合う他のルータとシグナリングを行い、宛先のネットワークとサービスタイプに対応する経路情報を決定し、その経路情報をMPLS処理部42に通知している。また、ルーティングプロトコル処理部41は、MPLSを使用しない通常の経路情報をルートテーブル44にエントリする処理も行っている。 【0024】 MPLS処理部42は、ルートテーブル44を管理しており、このテーブル44のエントリの追加、削除処理を行っている。すなわち、MPLS処理部42は、ルーティングプロトコル処理部41またはユーザインターフェース処理部43からのLSPの追加または削除の要求に対して、ルートテーブル44を検索して、この要求に対応するエントリの追加または削除を行う。 【0025】 ユーザインターフェース処理部43は、ラベル選択テーブル45を管理しており、このテーブル45のエントリの追加、削除処理を行っている。すなわち、ユーザインターフェース処理部43は、自ルータの管理元からの所定ヘッダ情報に対応するサービスタイプ情報の追加または削除の要求があると、ラベル経路情報、たとえば宛先ネットワーク、サービスタイプ、その経路を利用すべきトラフィックを特徴付ける情報(この実施の形態では、送信元アドレス)をMPLS処理部42に通知するとともに、このサービスタイプと対応する送信元アドレスをラベル選択テーブル45に追加または削除する。 【0026】 ルートテーブル44は、図4に示すように、IPパケットのパケットヘッダの情報である宛先アドレスA1,A2と、複数のラベル情報からなるラベル情報リストB1,B2とが対応付けられて格納されており、ルートテーブル検索部46は、取り込んだIPパケットのヘッダから宛先アドレスを抽出し、この抽出した宛先アドレスに基づいて、ルートテーブル44を検索し、該当するラベル情報リストを選出し、このIPパケットとともに、MPLSラベル選択部47に出力している。 【0027】 図5は、図4に示したラベル情報リストB1,B2の構成の一例に示す構成図である。図において、ラベル情報リストB1,B2は、ある宛先ネットワーク(ローカルネットワーク)に対する複数のLSP情報を保持しているリストの1つであり、同一経路に対する複数経路を区別するための指標となるサービスタイプD1,D2と、ラベル情報とがそれぞれ対応付けられてた構成になっており、ラベル情報には、IPパケットを出力する、図示しない自ルータ内の出力I/F1,2と、IPパケットに付与されるラベルE1,E2の情報が含まれている。 【0028】 ラベル選択テーブル45は、図4に示すように、IPパケットのパケットヘッダの情報である送信元アドレスC1,C2と、ラベル情報の1つであり、同一経路に対する複数経路を区別するための指標となるサービスタイプD1,D2とが対応付けられて格納されており、MPLSラベル選択部47は、ルートテーブル検索部46から入力するIPパケットのヘッダから送信元アドレスを抽出し、この抽出した送信元アドレスに基づいて、ラベル選択テーブル45を検索し、該当するサービスタイプを選出し、さらにこの選出したサービスタイプに基づいて、パケットとともに入力したラベル情報リストを参照して、該当するラベル情報を選出している。さらに、MPLSラベル選択部47は、この選出したラベル情報からMPLSラベルを生成して、このMPLSラベルをIPパケットに付与して、該当する出力I/F(選出したラベル情報内の出力I/F)からMPLSネットワーク30に転送している。 【0029】 なお、この実施の形態では、出力I/F1がコアルータ60と接続されており、出力I/F2がコアルータ70と接続されている。したがって、サービスタイプD1が選出された場合には、パケットはコアルータ60を通る経路に転送され、サービスタイプD2が選出された場合には、パケットはコアルータ70を通る経路に転送される。 【0030】 また、MPLS Egress Edge ルータの機能を有する宛先側エッジルータ50は、たとえば図示しないルーティングプロトコル処理部と、MPLS処理部と、ルートテーブルと、ラベル除去部とを有し、このラベル除去部によって、コアルータから転送されてきたパケットからMPLSラベルをはずして、宛先側のローカルネットワーク20に転送している。なお、このエッジルータ50は、送信側エッジルータとしての機能を有する場合もあるので、図4に示したエッジルータ40の構成を備えることも可能である。 【0031】 新しいラベルを付与する機能を有するコアルータ60?80は、同一の構成からなっており、ここでは代表してコアルータ60の構成の一例を図6の構成図に示す。図において、コアルータ60は、ルーティングプロトコル処理部61と、MPLS処理部62と、ラベル変換テーブル63と、このラベル変換テーブル63の検索を行うラベル変換テーブル検索部64とから構成されている。 【0032】 ルーティングプロトコル処理部61は、送信側エッジルータ40のルーティングプロトコル処理部41と同様の処理を行っている。また、MPLS処理部62も、MPLS処理部42と同様の処理を行っているが、このMPLS処理部1では、ルーティングプロトコル処理部61および送信側エッジルータからのラベル設定または削除要求に対して、ラベル変換テーブル63を検索して、この要求に対するエントリの設定または削除を行う。また、このMPLS処理部62は、このような要求に対しては、隣り合うルータと入力ラベル情報および出力ラベル情報の送受信を行っている。 【0033】 ラベル変換テーブル63は、図6に示すように、IPパケットに付与されたラベルの情報である入力ラベルE1,E2の情報と、たとえば出力I/Fおよび新たにIPパケットに付与されるラベルの情報が含まれる出力ラベル情報F1,F2とがそれぞれ対応付けられて格納されており、ラベル変換テーブル検索部64は、取り込んだIPパケットのラベルのフィールドからラベルの情報を抽出し、この抽出したラベルの情報に基づいて、ラベル変換テーブル63を検索し、該当する出力ラベル情報を選出し、このIPパケットのラベルをこの出力ラベル情報内のラベルに変換して、該当する出力I/F(選出した出力ラベル情報内の出力I/F)から宛先側のMPLSネットワーク30に転送している。」 以上の記載、特に下線部によれば、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。 「 送信側エッジルータ40は、ローカルネットワーク10から受信したパケットにMPLSラベルを付与して、MPLSネットワーク30に転送するMPLS Ingress Edge ルータの機能を有し、宛先側エッジルータ50は、転送されてきたパケットからMPLSラベルをはずして、ローカルネットワーク20に転送するMPLS Egress Edge ルータの機能を有し、また、コアルータ60?80は、受信したパケットのMPLSラベルから出力ポートを決定して新しいラベルを付与する機能を有しており、 送信側エッジルータ40は、ルーティングプロトコル処理部41と、MPLS処理部42と、ユーザインターフェース処理部43と、ルートテーブル44とラベル選択テーブル45の2つのテーブルと、ルートテーブル44の検索を行うルートテーブル検索部46と、ラベル選択テーブル45の検索結果に基づいてラベル情報リストを選択するMPLSラベル選択部47とから構成され、 ルートテーブル44は、IPパケットのパケットヘッダの情報である宛先アドレスA1,A2と、複数のラベル情報からなるラベル情報リストB1,B2とが対応付けられて格納されており、ルートテーブル検索部46は、取り込んだIPパケットのヘッダから宛先アドレスを抽出し、この抽出した宛先アドレスに基づいて、ルートテーブル44を検索し、該当するラベル情報リストを選出し、このIPパケットとともに、MPLSラベル選択部47に出力し、 MPLSラベル選択部47は、ルートテーブル検索部46から入力するIPパケットのヘッダから送信元アドレスを抽出し、この抽出した送信元アドレスに基づいて、ラベル選択テーブル45を検索し、該当するサービスタイプを選出し、さらにこの選出したサービスタイプに基づいて、パケットとともに入力したラベル情報リストを参照して、該当するラベル情報を選出し、さらに、MPLSラベル選択部47は、この選出したラベル情報からMPLSラベルを生成して、このMPLSラベルをIPパケットに付与して、該当する出力I/F(選出したラベル情報内の出力I/F)からMPLSネットワーク30に転送し、 コアルータ60は、ルーティングプロトコル処理部61と、MPLS処理部62と、ラベル変換テーブル63と、このラベル変換テーブル63の検索を行うラベル変換テーブル検索部64とから構成され、 ラベル変換テーブル63は、IPパケットに付与されたラベルの情報である入力ラベルE1,E2の情報と、たとえば出力I/Fおよび新たにIPパケットに付与されるラベルの情報が含まれる出力ラベル情報F1,F2とがそれぞれ対応付けられて格納されており、ラベル変換テーブル検索部64は、取り込んだIPパケットのラベルのフィールドからラベルの情報を抽出し、この抽出したラベルの情報に基づいて、ラベル変換テーブル63を検索し、該当する出力ラベル情報を選出し、このIPパケットのラベルをこの出力ラベル情報内のラベルに変換して、該当する出力I/F(選出した出力ラベル情報内の出力I/F)から宛先側のMPLSネットワーク30に転送する、 データ中継方法。」 第5 対比・判断 1.本願発明1について (1)対比 本願発明1と引用発明とを対比すると、次のことがいえる。 引用発明はIPパケットのラベルを参照して出力I/Fを決定してデータの中継を行うものであるから、引用発明における「データ中継方法」は本願発明1における「経路制御方法」に相当する。 また、引用発明における「ラベル」は、送信側エッジルータ40において、「宛先アドレスに基づいて、ルートテーブル44を検索し、該当するラベル情報リストを選出」するとともに、「送信元アドレスに基づいて、ラベル選択テーブル45を検索し、該当するサービスタイプを選出し、さらにこの選出したサービスタイプに基づいて、パケットとともに入力したラベル情報リストを参照して、該当するラベル情報を選出」することによって得られたものであり、「宛先アドレス」と「サービスタイプ」の両方に基づいて決定されるものであるから、本願発明1における、「1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有」する、「集約識別子」に相当する。 そして、引用発明における「コアルータ60」、「IPパケット」、「ラベル変換テーブル」、「出力I/F」がそれぞれ本願発明1における「ネットワークノード」、「サービス・データ・パケット」、「転送テーブル」、「ネクストホップ情報」に相当するから、引用発明において「コアルータ60」が「IPパケット」を受信することは、本願発明1における「ネットワークノードが、サービス・データ・パケットを受信するステップ」に相当し、引用発明において「取り込んだIPパケットのラベルのフィールドからラベルの情報を抽出し、この抽出したラベルの情報に基づいて、ラベル変換テーブル63を検索し、該当する出力ラベル情報を選出し、このIPパケットのラベルをこの出力ラベル情報内のラベルに変換して、該当する出力I/F(選出した出力ラベル情報内の出力I/F)から宛先側のMPLSネットワーク30に転送する」ことは、本願発明1における「前記ネットワークノードが、ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索するステップ」であって、「前記転送テーブルは、前記集約識別子および前記集約識別子に対応する前記ネクストホップ情報を含む、ステップ」、および、「前記ネットワークノードが、前記獲得されたネクストホップ情報に従って前記サービス・データ・パケットを転送するステップ」に相当する。 したがって、本願発明1と引用発明との間には、次の一致点、相違点があるといえる。 (一致点) ネットワークノードが、サービス・データ・パケットを受信するステップと、 前記ネットワークノードが、ネクストホップ情報を獲得するために、集約識別子に従って転送テーブルを探索するステップであって、前記集約識別子は1つのタイプのサービス・データ・フローを識別するのに使用され、前記サービス・データ・フローは同じネットワーク要件タイプおよび同じ宛先を有し、前記転送テーブルは、前記集約識別子および前記集約識別子に対応する前記ネクストホップ情報を含む、ステップと、 前記ネットワークノードが、前記獲得されたネクストホップ情報に従って前記サービス・データ・パケットを転送するステップとを含む、 経路制御方法。 (相違点) 本願発明1は、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」ものであるのに対し、引用発明ではそのような特定はなされていない点。 (2)相違点についての判断 相違点に係る本願発明1の、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」のに対し、引用発明の「ラベル」は、「宛先アドレス」および「サービスタイプ」に基づいて決定されるものではあるものの、本願発明1のように「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含」むものではなく、また、宛先として宛先エッジ・ネットワーク・ノードを用いるものでもない。引用文献1には、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含」むとともに、「前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子」とすることは記載されておらず、また、引用文献2,3にも「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含」むとともに、「前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子」とすることは記載されていない。 本願発明1は、相違点に係る構成により、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含」むとともに、「前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子」とすることによって、宛先エッジ・ネットワーク・ノードが同一でかつネットワーク要件タイプが同一であるものには同じ集約識別子が付与されることになるため、サービス制御ノードの経路制御エントリの量を著しく低減できるという格別の効果を奏するものであるから、このような構成とすることが単なる設計的事項であるとはいえない。 よって、相違点に係る、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という構成を引用発明に採用することが容易に想到し得たとはいえない。 したがって、本願発明1は、当業者であっても、引用発明、及び、引用文献2,3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 2.本願発明2-6について 本願発明2-6も、本願発明1と同様に、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という構成を有するものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、及び、引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。 3.本願発明7について 本願発明7も、本願発明1の相違点に係る構成に対応する、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という構成を有するものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、及び、引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。 4.本願発明8-10について 本願発明8-10も、本願発明1の相違点に係る構成に対応する、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という構成を有するものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、及び、引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。 5.本願発明11について 本願発明11も、本願発明1の相違点に係る構成に対応する、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という構成を有するものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、及び、引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。 第6 原査定について 審判請求時の補正により、本願発明1-6は、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という事項を有するものとなっており、本願発明7は、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という事項を有するものとなっており、本願発明8-10は、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、前記サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という事項を有するものとなっており、本願発明11は、「前記集約識別子は、宛先識別子およびネットワーク要件タイプ識別子を含み、前記宛先識別子は、宛先エッジ・ネットワーク・ノードの識別子であり、前記ネットワーク要件タイプ識別子は、サービス・データ・パケットのネットワーク要件タイプを識別するのに使用され、前記ネットワーク要件タイプは、遅延に敏感なタイプ、パケット損失に敏感なタイプ、ジッタに敏感なタイプ、帯域幅に敏感なタイプ、遅延+帯域幅に敏感なタイプ、およびパケット損失+遅延に敏感なタイプのうちの1つを含む」という事項を有するものとなっているため、本願発明1-11は、当業者であっても、拒絶査定において引用された引用文献1-3に基づいて、容易に発明できたものとはいえない。したがって、原査定の理由を維持することはできない。 第7 むすび 以上のとおり、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
審決日 | 2019-01-16 |
出願番号 | 特願2016-544700(P2016-544700) |
審決分類 |
P
1
8・
121-
WY
(H04L)
|
最終処分 | 成立 |
前審関与審査官 | 速水 雄太、西村 純 |
特許庁審判長 |
千葉 輝久 |
特許庁審判官 |
菊地 陽一 山田 正文 |
発明の名称 | 経路制御方法、デバイス、およびシステム |
代理人 | 木内 敬二 |
代理人 | 実広 信哉 |