• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
管理番号 1371647
審判番号 不服2019-7712  
総通号数 256 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-04-30 
種別 拒絶査定不服の審決 
審判請求日 2019-06-11 
確定日 2021-03-23 
事件の表示 特願2018- 3555「OｐenFlｏｗプロトコルとUDPポート番号アドレス変換を用いてマルチキャストパケットに非マルチキャストネットワークをトラバースさせるシステム及び方法」拒絶査定不服審判事件〔平成31年 1月31日出願公開、特開2019- 17004、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成30年1月12日(パリ条約による優先権主張外国庁受理2017年(平成29年)7月7日、台湾)を出願日とする出願であって、その手続の経緯は以下のとおりである。
平成30年11月 7日付け:拒絶理由通知書
平成31年 1月30日 :意見書、手続補正書の提出
平成31年 3月 4日付け:拒絶査定(以下、「原査定」という。)
令和 元年 6月11日 :審判請求書の提出
令和 2年 9月29日付け:拒絶理由(以下、「当審拒絶理由」と
いう。)通知書
令和 2年12月28日 :意見書、手続補正書の提出

第2 原査定の概要
原査定(平成31年3月4日付け拒絶査定)の概要は、次のとおりである。
本願請求項1-10に係る発明は、以下の引用文献Aに基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
A. 特開2001-244976号公報

第3 当審拒絶理由の概要
●理由1(サポート要件違反)
本願請求項1-10に係る発明は、発明の詳細な説明に記載されたものでないから、特許法第36条第6項第1号に規定する要件を満たしていない。
●理由2(明確性要件違反) 本願請求項1-10に係る発明は、明確でないから、特許法第36条第6項第2号に規定する要件を満たしていない。
●理由3(進歩性欠如)
本願請求項1ないし10に係る発明は、以下の引用文献1、2に基づいて、当業者が容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.柳瀬 駿 他,OpenFlowを利用した対多通信トポロジの動的構築,電気情報通信学会技術研究報告,2015年12月10日,pp.43-48,Vol.115,No.371, IA2015-76
2.特開2001-244976号公報(原査定の引用文献A)

第4 本願発明
本願請求項1-10に係る発明は、令和2年12月28日に提出された手続補正書による手続補正(以下、「本件補正」という。)の特許請求の範囲の請求項1-10に記載された事項により特定されるものであると認められるところ、請求項1-10に係る発明(以下、それぞれ「本願発明1」-「本願発明10」という。)は、以下のとおりの発明である(補正箇所に下線を付した)。

「 【請求項1】 OｐenFlｏｗプロトコルとUDPポート番号アドレス変換を用いて、クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われるマルチキャストパケットに、非マルチキャストネットワークをトラバースさせるシステムであって、
非マルチキャストネットワークを介して互いに接続される複数のOｐenFlｏｗスイッチと、
アドレス変換に用いられるユニキャストアドレスポート番号を格納するアドレスポート番号データベースと、
前記アドレスポート番号データベースに接続され、前記複数のOｐenFlｏｗスイッチのうちの第一のOｐenFlｏｗスイッチおよび複数の第二のOｐenFlｏｗスイッチにルーチングをさせるように、予め設定された第一のOｐenFlｏｗルーチングルールおよび予め設定された第二のOｐenFlｏｗルーチングルールをそれぞれ前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチのそれぞれのルーチングテーブルに書き込むOｐenFlｏｗコントローラと、を備え、
マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のOｐenFlｏｗスイッチを介し、前記第一のOｐenFlｏｗスイッチは、前記予め設定された第一のOｐenFlｏｗルーチングルールに基づいて、前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のOｐenFlｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャストパケットを生成し、前記非マルチキャストネットワークは、アドレス変換された前記ユニキャストパケットを前記複数の第二のOｐenFlｏｗスイッチに転送し、前記複数の第二のOｐenFlｏｗスイッチは、前記予め設定された第二のOｐenFlｏｗルーチングルールに基づいて、前記ユニキャストパケットにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する、システム。
【請求項2】 前記予め設定された第一のOｐenFlｏｗルーチングルールおよび前記予め設定された第二のOｐenFlｏｗルーチングルールは、前記マルチキャストアドレスポート番号と前記ユニキャストアドレスポート番号の変換を含む、請求項1に記載のシステム。
【請求項3】 前記第一のOｐenFlｏｗスイッチは、前記マルチキャストパケットの送信先IPアドレスとUDPポート番号が前記予め設定された第一のOｐenFlｏｗルーチングルールに符合しないと判断すると、前記マルチキャストパケットを前記OｐenFlｏｗコントローラに転送し、前記OｐenFlｏｗコントローラは、前記マルチキャストパケットのソースが属するマルチキャストネットワークに基づいて、前記アドレスポート番号データベースの中から前記マルチキャストネットワークおよび前記マルチキャストネットワークの境界スイッチにルーチングできる使用可能ユニキャストのポート番号を取得することにより、前記予め設定された第一のOｐenFlｏｗルーチングルールおよび前記予め設定された第二のOｐenFlｏｗルーチングルールを更新する、請求項1に記載のシステム。
【請求項4】 前記予め設定された第一のOｐenFlｏｗルーチングルールおよび前記予め設定された第二のOｐenFlｏｗルーチングルールの更新は、前記OｐenFlｏｗコントローラが、OｐenFlｏｗプロトコルにより、前記マルチキャストパケットのマルチキャストアドレスポート番号と取得したユニチキャストアドレスポート番号との変換関係を前記第一のOｐenFlｏｗスイッチに書き込むことと、前記OｐenFlｏｗコントローラが、前記OｐenFlｏｗプロトコルにより、前記ユニキャストアドレスポート番号と前記マルチチキャストパケットのマルチチキャストアドレスポート番号との変換関係を前記複数の第二のOｐenFlｏｗスイッチに書き込むことを含む、請求項3に記載のシステム。
【請求項5】 前記使用可能ユニキャストアドレスは、前記非マルチキャストネットワークにおいてユニキャストIPアドレスを提供し、前記マルチキャストネットワークへルーチングする境界スイッチである、請求項3に記載のシステム。
【請求項6】 OｐenFlｏｗプロトコルとUDPポート番号アドレス変換を用いて、クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われるマルチキャストパケットに、非マルチキャストネットワークをトラバースさせる方法において、
マルチキャストパケット送信端がマルチキャストパケットを生成し、マルチキャストネットワークにおいてマルチキャストルーチングを行なうステップと、
マルチキャストパケットを前記マルチキャストネットワークの境界にある第一のOｐenFlｏｗスイッチに送信するステップと、
前記第一のOｐenFlｏｗスイッチは、予め格納された第一のOｐenFlｏｗルーチングルールに基づいて、前記マルチキャストパケットのマルチキャストアドレスポート番号を非マルチキャストネットワークにルーチング可能なユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号のユニキャストパケットを生成するステップと、
前記ユニキャストパケットは前記ユニキャストアドレスポート番号を用いて前記非マルチキャストネットワークにおいてルーチング送信を行なうステップと、
前記ユニキャストパケットを複数の第二のOｐenFlｏｗスイッチにルーチングするステップと、
前記複数の第二のOｐenFlｏｗスイッチは、予め格納された第二のOｐenFlｏｗルーチングルールに基づいて、前記ユニキャストパケットの前記ユニキャストアドレスポート番号を元の前記マルチキャストパケットに対応するマルチキャストアドレスポート番号に戻すステップと、
戻された前記マルチキャストパケットを、そのマルチキャストアドレスポート番号により、それぞれマルチキャストネットワークにおけるマルチキャストパケット受信端に転送するステップとを含む、方法。
【請求項7】 前記第一のOｐenFlｏｗスイッチは、前記マルチキャストパケットのマルチキャストアドレスポート番号を非マルチキャストネットワークにルーチング可能なユニキャストアドレスポート番号に変換する場合、前記マルチキャストパケットの送信先IPアドレスとUDPポート番号が予め格納された前記第一のOｐenFlｏｗルーチングルールに符合しないと判断した場合、
前記第一のOｐenFlｏｗスイッチは、前記マルチキャストパケットを前記OｐenFlｏｗコントローラに転送するステップと、
前記OｐenFlｏｗコントローラは、前記マルチキャストパケットのソースが属するマルチキャストネットワークに基づいて、前記アドレスポート番号データベースの中から前記マルチキャストネットワークおよび前記マルチキャストネットワークの境界スイッチにルーチングできる使用可能ユニキャストのポート番号を取得するステップと、
前記OｐenFlｏｗコントローラは、OｐenFlｏｗプロトコルにより、前記ユニキャストパケットのマルチキャストアドレスポート番号と取得したユニキャストアドレスポート番号との変換関係を前記第一のOｐenFlｏｗスイッチにおける前記第一のOｐenFlｏｗルーチングルールに書き込むステップと、
前記OｐenFlｏｗコントローラは、前記OｐenFlｏｗプロトコルにより、前記ユニキャストパケットアドレスポート番号とマルチキャストパケットのマルチキャストアドレスポート番号との変換関係を前記複数の第二のOｐenFlｏｗスイッチにおける前記第二のOｐenFlｏｗルーチングルールに書き込むステップと、をさらに含む、請求項6に記載の方法。
【請求項8】 前記マルチキャストパケットがマルチキャストルーチングを行なう前に、
前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチにおいて前記OｐenFlｏｗスイッチの情報を設定することにより、前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチとの接続を構築するステップと、
前記OｐenFlｏｗコントローラが、前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチとの接続が正常であるか否かを確認するステップと、
前記OｐenFlｏｗコントローラが、予め設定されたOｐenFlｏｗのルーチングルールを前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチのルーチングテーブルに書き込むステップと、
前記OｐenFlｏｗコントローラが前記マルチキャストアドレスポート番号と前記ユニキャストアドレスポート番号との変換を行なう時、使用可能ユニキャストアドレスのポート番号を検索できるように、未配置かつルーチングに使用可能なアドレスポート番号をアドレスポート番号データベースに格納するステップと、をさらに含む、請求項6に記載の方法。
【請求項9】 前記OｐenFlｏｗスイッチが前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチのルーチングテーブルに書き込む前記第一と第二のルーチングルールは、Matchエントリにおける送信先IPアドレスはマルチキャストアドレスであり、Actionエントリは前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチと前記OｐenFlｏｗコントローラとが接続している出口ポートにパケットをリダレクトすることであり、前記第一と第二のルーチングルールの優先権値は最小値に設定されることを指す、請求項8に記載の方法。
【請求項10】 前記使用可能ユニキャストアドレスは、前記非マルチキャストネットワークにおいて、ユニキャストアドレスルーチングを前記マルチキャストネットワークに提供する境界スイッチであることを指す、請求項7に記載の方法。」

第5 当審拒絶理由の理由1(サポート要件違反)、理由2(明確性要件違反)について
1 理由1について
本願発明は、「クラスDのマルチキャスト専用のIPアドレス」を用いていない(すなわち、課題を生じることのなく、明細書等に開示のない)マルチキャストパケットに関する態様をも含むものであり、そのような場合には、課題を解決しているとはいえないから、本願発明は、本願発明の課題を解決できることを当業者が認識できるように記載された範囲を超えているといえるとの指摘に対して、本件補正により、請求項1-10に係る発明の「マルチキャストパケット」を「クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われるマルチキャストパケット」に変更する補正が行われることにより、マルチキャストパケットが「クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われる」という発明の詳細な説明に記載された構成となった。

2 理由2について
補正前の請求項1ないし12に記載の「マルチキャストパケット」の定義が明確でないとの指摘に対して、本件補正により、「クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われるマルチキャストパケット」と補正され、当該マルチキャストパケットが「クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われる」ことが明らかとされた。

以上の1及び2により、当審拒絶理由の理由1(サポート要件違反)、理由2(明確性要件違反)は解消した。

第6 引用文献、引用発明等
1.引用発明1について
(1)引用文献1記載事項
当審拒絶理由で引用された引用文献1には、次の事項が記載されている。

ア セクション2.1
「2. 1 IPマルチキャストとアプリケーションレイヤマルチキャスト
まず,図1にIPマルチキャスト,アプリケーションレイヤマルチキャストにおけるパケット転送の概念を示す.IPマルチキャストの場合,ノード間をつなぐルータがパケットの複製を行う(図1(a)).図1(a)ではN1が送信サーバ,N2?5が受信者であり,ルータR1?R3がマルチキャストアドレス宛のパケットを複製することで全受信者にパケットを転送している.任意のノードがマルチキャストトラフィックを受信するには,トポロジを構築する全ルータがマルチキャストに対応している必要がある.しかし,大規模なネットワークにおいて,全ルータをマルチキャスト対応に変更することは現実的ではない.また,対応していないルータが中間に存在する場合は,トンネリング等によって回避できるが,ネットワークの変更や,規模の大きさによって管理に大きなコストを要する.上記のような理由から,現在では,IPマルチキャストを利用するサービスはISP内に閉じているか,連携関係にあるISP間に制限されている.マルチキャスト対応ルータを必要としないという点に着目して,アプリケーションレイヤでマルチキャストを実現する手法(以下ALMと呼ぶ)が提案されている[1].ALMでは,ルータ等のネットワーク機器でパケットを複製するのではなく,受信ノードが受信と同時にエンドノードに対してデータ送信を繰り返すことで,同時配信機能を実現している(図1(b)).図1(b)では受信者N2,N4が受信と送信を行うノードとなっている.ALMではノード間のデータ転送はユニキャストであるため,ルータの設定や構成の変更を必要とせず,またISP間をまたぐ配信網の構築が可能という利点がある.一方で,IPマルチキャストと比べて,使用帯域の効率が悪い.オリジナルの送信サーバ直下の帯域は削減できるが,総転送データ量は全データをユニキャストで送信する場合と変わらない.また,ALMではエンドユーザをノードとしたオーバーレイ・ネットワークを構築する.そのため,通信品質の信頼性やエンドユーザのネットワーク環境を考慮したオーバーレイ・ネットワーク構築の方法に関する研究が多数行われている[2][3].しかし,エンドユーザ側のコンピューティング資源,ネットワーク資源による,遅延時間のばらつき,グループの参加,離脱等による通信品質の悪化といった問題はユーザ依存であり,全ユーザの通信品質を保証するトポロジを構築することは難しい[2][4].以上のIPマルチキャスト,ALMにおける問題点から,全ルータをマルチキャスト対応ルータに変更するといった大規模な移行を必要としない.また,送信サーバは受信者まで直接データ転送を行うようなようなマルチキャスト技術が求められる.」

イ セクション 2.2
「2.2 OpenFlowによるマルチキャスト
上記の問題点を解決する手法として,OpenFlow[5]を利用した,ユニキャストパケットの宛先書き換えと,複製・転送によるマルチキャスト技術が提案されている[6][7].OpenFlowはコントローラ(以下OFC)とスイッチ(以下OFSW)から構成され,経路制御機能のコントロールプレーンとデータ転送機能のデータプレーンが分離していることが特徴である.OFSWでは,マッチルールに基づいてパケットの転送を行う.マッチルールが存在しないパケットを受信した場合,OFCに転送先を問い合わせ,OFSWに新たなフローエントリ(マッチルールとアクションの組)を追加することで柔軟な経路制御が可能となる.文献[6]では,OFSWの配下に受信者が存在する場合に,受信者を収容する全ての物理ポートにパケットを出力する.また,出力の際は,イーサネットフレームとIPパケット中の宛先アドレスを,それぞれ受信者のMACアドレスとIPアドレスに書き換える.例として図2を使って説明する.図2ではOFSW4台,ホスト1-5(うちホスト1が送信サーバ)からネットワークが構成されている.実線は物理的なリンクを示す.ホスト1はIPアドレス’10.0.0.10’に対して,データ送信を行う(矢印付き実線).OFSW1,2では,宛先IPアドレスが’10.0.0.10’のパケットを配下のOFSWに複製して転送する(矢印付き実線).OFSW3,4では,宛先IPアドレスが’10.0.0.10’のパケットを,ヘッダの宛先を配下のそれぞれのノード宛に変更し,複製・転送する(矢印付き破線).OFCから以上のような動作を行うフローエントリを各OFSWに投入し,コンテンツ配信用のトポロジを構築することで,データプレーン上でユニキャストパケットによるマルチキャストを実現している.また,文献[7]では実際に実機のOpenFlowスイッチで実証実験を行い,可用帯域幅,ジッタに関して,パケットコピーで発生するオーバーヘッドについて評価している.実験では受信者数が2人のみではあるが,ジッタに関して,ユニキャストの場合と同等の結果が得られたことを示している.OFSWがデータプレーン上にコンテンツ配信用トポロジを構築するためにはOFCによるフローエントリの設定が必要である.文献[6]ではOFSWにあらかじめ静的に設定を投入しておくことで,コンテンツ配信用のトポロジを構築している.しかし,動画配信等のサービスへの応用を想定する場合,受信者の参加,離脱は頻繁に発生する.そのため,参加,離脱に合わせて,コンテンツ配信用のトポロジを動的に構築する必要がある.そこで,本研究では,受信ノードによる受信要求に合わせ,コンテンツ配信用トポロジを動的に構築する手法を提案する.」

ウ セクション3
「3. 提案手法
提案手法では,サービス利用者からの受信要求に対応して,コントローラが最適なスイッチを選択し,フローエントリを制御することでサービス用トポロジを動的に構築する.
3. 1 想定するシナリオ
はじめに,本研究で,想定しているシナリオについて説明する.2.1節で記したように,全ルータをマルチキャストに対応したものに変更することは現実的ではない.しかし,ネットワークを構成するルータ中の複数台をOFSWに変更することは現実的であると考えられる.そのため,OFSWと通常のルータが混在するようなネットワーク環境を想定する.この際,OFSWは,特定の通信を除き,レイヤ2,3,4によるマルチレイヤルーティングを行うものとする.つまり,同じIPアドレス宛への通信でも,トランスポートレイヤのプロトコル,ポート番号によって異なる経路を取得する.また,通信コンテンツとしては,ストリーミング配信等のリアルタイムアプリケーション用サービスを想定しており,トランスポートレイヤにはUDPを用いる.
3. 2 トポロジの動的構築のアルゴリズム
提案手法のアルゴリズムのフローチャートを図3に示す.また,本稿では,コンテンツの最初の受信者およびOFSWごとに最初に出現するコンテンツ配信先を初期ノードと呼ぶ.以降では図3のフローチャートを,図4のネットワーク構成より,初期ノード(ホスト2),2人目以降の追加クライアント(ホスト3)の配信設定を行う例を利用して説明する.図4のネットワークは想定シナリオの通りOFSWと非OFSWによって構成される.また,各スイッチには物理ポートに番号を割り当てている.
1. 受信要求
事前に送信サーバ(ホスト1)側でコンテンツ送信に用いるUDPポート番号(例として30000とする)を決定する.このUDPポート番号はコンテンツを一意に識別するのに用いる.受信要求者(ホスト2,3)は受信要求送信用のクライアントアプリケーションを利用し,コンテンツ送信サーバ(ホスト1)に対して,srcポート22223,dstポート30000に設定したUDPパケットを送信する.また,このような形式のパケットを受信要求パケットとする.
3. 初期ノードとしてユニキャストでコンテンツ配信
最初の受信者による受信要求の場合は,そのクライアントを初期ノード (ホスト2)として,送信サーバはホスト2宛にコンテンツ配信を行う.ホスト2宛へのコンテンツ配信により,OFSW1,OFSW2ではコンテンツ配信用のフローエントリが新規に登録される.以降の受信要求者(ホスト3)が受信要求を行った際には,受信クライアントの追加を行うため,フローチャートの4.以降へ移行する.
4.OFSWがOFCに受信要求パケット転送
コンテンツ送信サーバ(ホスト1)までの経路にOFSWが存在する場合,OFSWは受信要求パケットを受信する.OFSWがsrcポート22223のUDPパケット(受信要求パケット)を受信した場合は,Packet In としてOFCに転送する.この設定はOFSWがOFCに接続された段階で設定として投入する.
5.OFSW中に要求コンテンツのフローが存在するか
OFCは受信要求を転送したOFSWのフローエントリ内にUDP,送信元ポート30000かつ宛先アドレスが受信要求者(ホスト3)のアドレスと異なるマッチルールを持つエントリが存在するか検索する.存在すれば,当該OFSWのエントリにアクションを追加するために6.へ.存在しなければ上流のOFSWで転送するため7.へ移行する.ホスト3の受信要求では,OFSW2において,マッチするエントリがすでに存在するため,6.へ移行する.
6.OFSWのフローエントリの変更
OpenFlowでは複数のアクションを指定することが可能であり,アクションテーブルに追加された順に逐次的に処理を実行することが可能である.転送元のOFSWの該当エントリのアクションに以下を追加する.
SET DL DST: 送信先 MAC アドレスを次ホップの MACアドレスに変更
SET NW DST: 送信先 IP アドレスを受信要求者のIPアドレス(ホスト3)に変更
OUTPUT: 送信先物理ポートに次ホップへの経路を追加
7. ルーティングテーブルに基づいて次ホップへ転送
OFCは転送元のOFSWに対して,受信要求パケットをユニキャストのルーティングテーブルに基づいて次ホップへ転送するようにメッセージを送信する.
上記のように,本アルゴリズムでは,コンテンツ配信者(送信サーバ)と最初にデータ受信関係を確立した初期ノード間の経路について,順次受信クライアントを追加することにより,動的にトポロジを構成するものである.
このアルゴリズムにおいて,図4中のホスト2-6のトポロジの構築を動的に行った際の各OFSWのフローエントリの変化例を図5に示す.ここでは,ホスト2-6の順に受信要求を行っている.ホスト2は初期ノードであるため,OFSW1とOFSW2において,新規のフローエントリが登録される.
ホスト3の受信要求では,直近のOFSW2にて,コンテンツ用のフローエントリがすでに存在するため,既存のエントリに対し,アクションの追加を行う.ホスト4の受信要求も同様に,直近のOFSW1のフローエントリに追加される.
ホスト5の受信要求では,直近のOFSW3で,コンテンツ用のフローエントリが存在しないため,一旦上流に転送し,OFSW1でアクションの追加を行った後に,上流からのコンテ ンツ転送によって,OFSW3で,新規のフローエントリが登録される.
ホスト6の受信要求では,ホスト5によってコンテンツ用のフローエントリが OFSW3 に設定されたため,直近の OFSW3のエントリにアクションを追加する.一方で,上流からのコンテンツ転送によって OFSW3でコンテンツ用エントリが追加される前に,ホスト6からの受信要求がOFSW3へ到達する場合が考えられる.この際には,受信要求がOFSW1まで到達するので,帯域の利用効率は悪化するが,ホスト5,6宛へのパケットのコピーはOFSW1で行うことで対応可能である.
このアルゴリズムの動作説明では,ホスト2-6の順に,受信要求を行った場合について説明したが,各ホストの受信要求送信の間隔において,エントリの新規追加が可能な十分な時間間隔が存在する場合,受信要求の順序に依存せず,最終的には同じトポロジを構築可能である.」


エ 図4
「

」
図4において、ホスト1から、ホスト2-6に対してパケットがマルチキャストされている点、及び、OFSW1,2間で、非OFSWのルータを介して、パケットが転送(トラバース)されている点に着目すると、「マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせるOｐenFlｏｗプロトコルを用いたシステムであって、マルチキャスト非対応のルータを介して互いに接続されるOFSW1,2と、OFSW1-3とOFCとを備え」るシステムであって、「ホスト1からマルチキャストパケットを送信する場合、マルチキャストパケットはOFSW1を介し、マルチキャスト非対応のルータはパケットをOFSW2に転送し、OFSW2は、ホスト2,3へ転送するシステム」が開示されていると認定できる。

オ 図5
「

」
図5には、「OFSW1-3は、UDPのsrc(送信元)ポート番号が22223であった場合、OFCに問い合わせるというフローエントリが設定されていること」が開示されていると認定できる。

(2)引用発明
よって、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。
「 任意のノードがマルチキャストトラフィックを受信するには,トポロジを構築する全ルータがマルチキャストに対応している必要があり、大規模なネットワークにおいて,全ルータをマルチキャスト対応に変更することは現実的ではなく,対応していないルータが中間に存在する場合は,トンネリング等によって回避できるが,ネットワークの変更や,規模の大きさによって管理に大きなコストを要し、現在では,IPマルチキャストを利用するサービスはISP内に閉じているか,連携関係にあるISP間に制限されており(セクション2.1)、
OｐenFlｏｗは、OFSW(OｐenFlｏｗスイッチ)とOFC(OｐenFlｏｗコントローラ)から構成され、OFSWではマッチルールに基づいてパケットの転送を行い、マッチルールが存在しないパケットを受信した場合、OFCに転送先を問い合わせ、OFSWに新たなフローエントリ(マッチルールとアクションの組)を追加することで柔軟な経路制御が可能となり(セクション2.2)、
上記したように、全ルータをマルチキャストに対応したものに変更することは現実的ではなく、そのため、OFSWと通常のルータが混在するようなネットワーク環境を想定し、OFSWは、特定の通信を除き、レイヤ2、3、4によるマルチレイヤルーティングを行い、同じIPアドレス宛への通信でも、トランスポートレイヤのプロトコル、ポート番号によって異なる経路を取得し、トランスポートレイヤにはUDPを用いており(セクション3.1)、
マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせるOｐenFlｏｗプロトコルを用いたシステムであって、
マルチキャストパケットにマルチキャスト非対応のスイッチをトラバースさせるOｐenFlｏｗプロトコルを用いたシステムであって
マルチキャスト非対応のルータを介して互いに接続されるOFSW1,2と、
OFSW1-3とOFCとを備え(図4,セクション3.2)、
OFSW1-3は、UDPのsrc(送信元)ポート番号が22223であった場合、OFCに問い合わせるというフローエントリが設定されており(図5)、
ホスト1からマルチキャストパケットを送信する場合、マルチキャストパケットはOFSW1を介し、マルチキャスト非対応のルータはパケットをOFSW2に転送し、OFSW2は、ホスト2,3へ転送する(図4,セクション3)、
システム。」

2 引用文献2について
当審拒絶理由で引用された引用文献2(特に、段落【0002】-段落【0005】、段落【0012】-段落【0026】、図1-4を参照)には、
「マルチキャストパケットを転送する際に、カプセル化(トンネリング)を行うとフラグメントが生じるという課題を解決するために(段落【0003】、段落【0004】)、
ヘッダの書き換えを行うために、転送に使用するポートを記憶する記憶部3を備え(段落【0015】、段落【0018】、図2)、
転送装置101に届いたグループ(宛先)アドレスG1、宛先ポートP1、送信者(始点)アドレスS1、送信(始点)ポートP2及びデータで構成される、マルチキャストパケット30は(段落【0020】-段落【0021】)、
宛先アドレスR2、送信元(始点)アドレスR1、宛先ポートP1とは異なる宛先ポートP3、転送元ポートP4及びデータにより構成される、ヘッダが書き換えられたパケット40は転送装置201にユニキャストパケットとして送信され(段落【0025】-段落【0026】)、
転送装置201は、宛先ポートP3宛のパケット40を転送装置101から受信すると、それをマルチキャスト転送パケットであると判断し、転送装置201は受信した転送パケット40の転送元ポートP4から転送パケット情報表32を検索して、元のマルチキャストパケット30のグループアドレスG1、宛先ポートP1、送信者アドレスS1、送信ポートP2を取得し、これを用いて元のマルチキャストパケット30を復元すること(段落【0026】-段落【0027】)」、
「ヘッダの書き換えにおいては、UDPヘッダ(P1-P4)及びIPヘッダのアドレス書き換えを行うこと」(図3,4、段落【0025】)、
「転送装置において記憶部3とヘッダ書き換えなどを行うデータ処理装置2とが接続されていること」(図2、段落【0015】-段落【0017】)が記載されている。

第7.対比、判断
1.本願発明1について
(1)対比
本願発明1と引用発明とを対比する。
ア 引用発明の「マルチキャストパケット」に「OｐenFlｏｗ」を用いたシステムは、「マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせ」ており、マルチキャスト非対応のルータは、非マルチキャストネットワークの要素であるから、本願発明1の「OｐenFlｏｗプロトコルとUDPポート番号アドレス変換を用いて、クラスDのマルチキャスト専用のIPアドレスでパケット送信が行われるマルチキャストパケットに、非マルチキャストネットワークをトラバースさせるシステム」と「OｐenFlｏｗプロトコルを用いてマルチキャストパケットに非マルチキャストネットワーク要素をトラバースさせるシステム」という点で共通している。

イ 引用発明の「マルチキャスト非対応のルータを介して互いに接続されるOFSW1,2」は、非マルチキャストネットワーク要素を介して互いに接続される複数のOｐenFlｏｗスイッチといえるから、本願発明1の「非マルチキャストネットワークを介して互いに接続される複数のOｐenFlｏｗスイッチ」と「非マルチキャストネットワーク要素を介して互いに接続される複数のOｐenFlｏｗスイッチ」である点で共通している。

ウ 引用発明の「OFC(OｐenFlｏｗコントローラ)」は、「マッチルールが存在しないパケットを受信した場合,OFCに転送先を問い合わせ,OFSWに新たなフローエントリ(マッチルールとアクションの組)を追加することで柔軟な経路制御が可能とな」っており、「経路制御」とはルーチングであり、「OｐenFlｏｗ」システムにおいて、フローエントリの集合はフローテーブルと呼ばれるルーチングテーブルであることは技術常識であるから、引用発明の「OFC(OｐenFlｏｗコントローラ)」は、OｐenFlｏｗルーチングルールを各OｐenFlｏｗスイッチ(OFS)のルーチングルールテーブルに書き込み、OｐenFlｏｗスイッチは当該ルーチングルールに基づいてパケットを生成して転送するものであると認められる。
また、引用発明は、「OFSW1-3」を備えており、OFSW1-2はそれぞれ、第1のOｐenFlｏｗスイッチ、第2のOｐenFlｏｗスイッチと言いうるものである。
そして、引用発明においては、「OFSW1-3は、UDPのsrc(送信元)ポート番号が22223であった場合、OFCに問い合わせるというフローエントリが設定されて」おり、当該フローエントリは、予め設定されたルーチングルールといえ、各々第1の予め設定されたルーチングルール、第2の予め設定されたルーチングルールと言いうるものである。
よって、引用発明の「OFC(OｐenFlｏｗコントローラ)」は、本願発明1の「前記アドレスポート番号データベースに接続され、前記複数のOｐenFlｏｗスイッチのうちの第一のOｐenFlｏｗスイッチおよび複数の第二のOｐenFlｏｗスイッチにルーチングをさせるように、予め設定された第一のOｐenFlｏｗルーチングルールおよび予め設定された第二のOｐenFlｏｗルーチングルールをそれぞれ前記第一のOｐenFlｏｗスイッチおよび前記複数の第二のOｐenFlｏｗスイッチのそれぞれのルーチングテーブルに書き込むOｐenFlｏｗコントローラ」とは、「前記複数のOｐenFlｏｗスイッチのうちの第一のOｐenFlｏｗスイッチおよび第二のOｐenFlｏｗスイッチにルーチングをさせるように、予め設定された第一のOｐenFlｏｗルーチングルールおよび予め設定された第二のOｐenFlｏｗルーチングルールをそれぞれ前記第一のOｐenFlｏｗスイッチおよび前記第二のOｐenFlｏｗスイッチのそれぞれのルーチングテーブルに書き込むOｐenFlｏｗコントローラ」である点で共通している。

エ 引用発明は、「ホスト1からマルチキャストパケットを送信する場合、マルチキャストパケットはOFSW1を介し、マルチキャスト非対応のルータはパケットをOFSW2に転送し、OFSW2は、転送されたパケットそれぞれをホスト2,3へ転送し」ている。
ここで、ホスト1は、マルチキャストパケット送信端に相当し、OFSW1,OFSW2は、それぞれ、第1のOｐenFlｏｗスイッチ、第2のOｐenFlｏｗスイッチと言いうるものであり、(3)で検討したとおり、各OｐenFlｏｗスイッチは、予め設定されたルーチングルールに基づいてパケットを生成して転送するものであり、マルチキャスト非対応のルータは非マルチキャストネットワーク要素といえ、ホスト2,3はマルチキャストパケット受信端に相当する。
したがって、引用発明は、ホスト1(マルチキャストパケット送信端)からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第1のOｐenFlｏｗスイッチを介し、第1のOｐenFlｏｗスイッチは、前記予め設定された第一のルーチングルールに基づいてパケットを生成して転送し 、マルチキャスト非対応ルータ(非マルチキャストネットワーク要素)は、生成されたパケットをOFSW2(第2のOｐenFlｏｗスイッチ)に転送し、OFSW2(第2のOｐenFlｏｗスイッチ)は、前記予め設定された第二のOｐenFlｏｗルーチングルールに基づいて、それぞれをホスト2,3(マルチキャストパケット受信端)に転送していると認められる。
したがって、引用発明は、本願発明1の「マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のOｐenFlｏｗスイッチを介し、前記第一のOｐenFlｏｗスイッチは、前記予め設定された第一のOｐenFlｏｗルーチングルールに基づいて、前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のOｐenFlｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャストパケットを生成し、前記非マルチキャストネットワークは、アドレス変換された前記ユニキャストパケットを前記複数の第二のOｐenFlｏｗスイッチに転送し、前記複数の第二のOｐenFlｏｗスイッチは、前記予め設定された第二のOｐenFlｏｗルーチングルールに基づいて、前記ユニキャストパケットにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する」ことと、「マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のOｐenFlｏｗスイッチを介し、前記第一のOｐenFlｏｗスイッチは、前記予め設定された第一のOｐenFlｏｗルーチングルールに基づいて、パケットを生成し、前記非マルチキャストネットワーク要素は、前記パケットを前記第二のOｐenFlｏｗスイッチに転送し、前記第二のOｐenFlｏｗスイッチは、前記予め設定された第二のOｐenFlｏｗルーチングルールに基づいて、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する」の点で共通している。

(2)一致点・相違点
以上から、本願発明1と引用発明とは、以下の点において一致、及び相違する。

[一致点]
「OｐenFlｏｗプロトコルを用いてマルチキャストパケットに非マルチキャストネットワーク要素をトラバースさせるシステムであって、
非マルチキャストネットワーク要素を介して互いに接続される複数のOｐenFlｏｗスイッチと、
前記複数のOｐenFlｏｗスイッチのうちの第一のOｐenFlｏｗスイッチおよび第二のOｐenFlｏｗスイッチにルーチングをさせるように、予め設定された第一のOｐenFlｏｗルーチングルールおよび予め設定された第二のOｐenFlｏｗルーチングルールをそれぞれ前記第一のOｐenFlｏｗスイッチおよび前記第二のOｐenFlｏｗスイッチのそれぞれのルーチングテーブルに書き込むOｐenFlｏｗコントローラと、
を備え、
マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のOｐenFlｏｗスイッチを介し、前記第一のOｐenFlｏｗスイッチは、前記予め設定された第一のOｐenFlｏｗルーチングルールに基づいて、パケットを生成し、前記非マルチキャストネットワーク要素は、前記パケットを前記第二のOｐenFlｏｗスイッチに転送し、前記第二のOｐenFlｏｗスイッチは、前記予め設定された第二のOｐenFlｏｗルーチングルールに基づいて、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する、システム。」

[相違点1]共通点である、トラバースされる「非マルチキャストネットワーク要素」が、本願発明1は「非マルチキャストネットワーク」であるのに対して、引用発明が「マルチキャスト非対応のルータ」である点。

[相違点2]本願発明1が、「UDPポート番号アドレス変換を用いて、クラスDのマルチキャスト専用のIPアドレスで送信が行われる」マルチキャストパケットを、トラバースさせているのに対して、引用発明にはそのようなことが特定されていない点。

[相違点3]本願発明1が、「アドレス変換に用いられるユニキャストアドレスポート番号を格納するアドレスポート番号データベース」を備えているのに対して、引用発明にはそのようなことが特定されていない点。

[相違点4]本願発明1が、第1のOｐenFlｏｗスイッチからのパケットを転送する「第2のOｐenFlｏｗスイッチ」を「複数」備えているのに対して、引用発明にはそのようなことが特定されていない点。

[相違点5]本願発明1の「OｐenFlｏｗコントローラ」が、「前記アドレスポート番号データベースに接続され」ているのに対して、引用発明にはそのようなことが特定されていない点。

[相違点6]本願発明1の「第一のOｐenFlｏｗスイッチ」が、「前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のOｐenFlｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャストパケットを生成し」、「第2のOｐenFlｏｗスイッチ」が「前記ユニキャストパケッ トにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後」、転送するのに対して、引用発明にはそのようなことが特定されていない点。

(3)相違点についての判断
事案に鑑みて、[相違点2]より検討を行う。
引用発明は、マルチキャストパケットをトラバースする点は本願発明1と共通している。また、引用文献1には、「トランスポートレイヤにはUDPを用い、UDP ポート番号はコンテンツを一意に識別するのに用いる」こと、すなわち、コンテンツの識別にUDP ポート番号を利用すること、及び、「大規模なネットワークにおいて,全ルータをマルチキャスト対応に変更することは現実的ではなく,対応していないルータが中間に存在する場合は,トンネリング等によって回避できるが,ネットワークの変更や,規模の大きさによって管理に大きなコストを要」すること、すなわち、マルチキャストに対応しないネットワーク要素をトンネリングで通過させることが示唆されている。
また、引用文献2に記載の「ヘッダが書き換えられたパケット40」は、UDPヘッダのポート番号が書き換えられていることから、引用文献2には、ドメイン間でマルチキャストパケットを伝送する場合に、UDPポート番号の変換を用いて、マルチキャストアドレスが付加されたパケットを、ユニキャストアドレスにヘッダの書き換え(アドレス変換)を行ってから、トンネリングすることが記載されているといえる。
しかしながら、引用発明は、要するに、「大規模なネットワークにおいて,全ルータをマルチキャスト対応に変更することは現実的ではな」いとの課題を解決するために、すなわち、マルチキャストのための「特別な」IPアドレスである「マルチキャストアドレス」を用いることなしにマルチキャスト伝送を実現するために、OｐenFlｏｗネットワークにおけるマルチキャスト技術と、非OｐenFlｏｗ区間での、通常の(ユニキャスト)IPアドレスを用いたトラバースとを組み合わせるという構成であるから、引用発明において、マルチキャストのための「特別な」IPアドレスである「マルチキャストアドレス」を採用することは想定されておらず、むしろ阻害要因があるといえる。また、「UDPポート番号アドレス変換を用いて、クラスDのマルチキャスト専用のIPアドレスで送信が行われる」マルチキャストパケットをトラバースさせることは本願優先日前において、周知技術であったともいえない。
したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2. 本願発明2-10について
本願発明2-10も、相違点2に係る本願発明1の構成と同一の構成を備えるものであるから、本願発明1と同じ理由により、当業者であっても、引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第8 原査定について
本願発明1?10は、前記「第7」で検討したとおり、当業者であっても、原査定において引用された引用文献A(当審拒絶理由の引用文献2)に記載された発明に基づいて、容易に発明できたものとはいえない。
したがって、原査定の理由を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-03-04 
出願番号 特願2018-3555(P2018-3555)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 玉木 宏治  
特許庁審判長 稲葉 和生
特許庁審判官 林 毅
太田 龍一
発明の名称 OｐenFlｏｗプロトコルとUDPポート番号アドレス変換を用いてマルチキャストパケットに非マルチキャストネットワークをトラバースさせるシステム及び方法  
代理人 石川 貴之  
代理人 村井 康司  

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