【事件の表示】
　特願２０１８−　　３５５５「ＯｐｅｎＦｌｏｗプロトコルとＵＤＰポート番号アドレス変換を用いてマルチキャストパケットに非マルチキャストネットワークをトラバースさせるシステム及び方法」拒絶査定不服審判事件〔平成３１年　１月３１日出願公開、特開２０１９−　１７００４、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成３０年１月１２日（パリ条約による優先権主張外国庁受理２０１７年（平成２９年）７月７日、台湾）を出願日とする出願であって、その手続の経緯は以下のとおりである。
　　平成３０年１１月　７日付け：拒絶理由通知書
　　平成３１年　１月３０日　　：意見書、手続補正書の提出
　　平成３１年　３月　４日付け：拒絶査定（以下、「原査定」という。）
　　令和　元年　６月１１日　　：審判請求書の提出
　　令和　２年　９月２９日付け：拒絶理由（以下、「当審拒絶理由」と
　　　　　　　　　　　　　　　　いう。）通知書
　　令和　２年１２月２８日　　：意見書、手続補正書の提出
第２　原査定の概要
　原査定（平成３１年３月４日付け拒絶査定）の概要は、次のとおりである。
　本願請求項１−１０に係る発明は、以下の引用文献Ａに基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　引用文献等一覧
Ａ. 特開２００１−２４４９７６号公報
第３　当審拒絶理由の概要
●理由１（サポート要件違反）
　本願請求項１−１０に係る発明は、発明の詳細な説明に記載されたものでないから、特許法第３６条第６項第１号に規定する要件を満たしていない。
●理由２（明確性要件違反）　本願請求項１−１０に係る発明は、明確でないから、特許法第３６条第６項第２号に規定する要件を満たしていない。
●理由３（進歩性欠如）
　本願請求項１ないし１０に係る発明は、以下の引用文献１、２に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　引用文献等一覧
１．柳瀬　駿　他，OpenFlowを利用した対多通信トポロジの動的構築,電気情報通信学会技術研究報告，２０１５年１２月１０日，pp.43-48，Vol.115,No.371, IA2015-76
２．特開２００１−２４４９７６号公報（原査定の引用文献Ａ）
第４　本願発明
　本願請求項１−１０に係る発明は、令和２年１２月２８日に提出された手続補正書による手続補正（以下、「本件補正」という。）の特許請求の範囲の請求項１−１０に記載された事項により特定されるものであると認められるところ、請求項１−１０に係る発明（以下、それぞれ「本願発明１」−「本願発明１０」という。）は、以下のとおりの発明である（補正箇所に下線を付した）。
「　　【請求項１】　ＯｐｅｎＦｌｏｗプロトコルとＵＤＰポート番号アドレス変換を用いて
、クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
、
　非マルチキャストネットワークを介して互いに接続される複数のＯｐｅｎＦｌｏｗスイッチと、
　アドレス変換に用いられるユニキャストアドレスポート番号を格納するアドレスポート番号データベースと、
　前記アドレスポート番号データベースに接続され、前記複数のＯｐｅｎＦｌｏｗスイッチのうちの第一のＯｐｅｎＦｌｏｗスイッチおよび複数の第二のＯｐｅｎＦｌｏｗスイッチにルーチングをさせるように、予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールおよび予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールをそれぞれ前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチのそれぞれのルーチングテーブルに書き込むＯｐｅｎＦｌｏｗコントローラと、を備え、
　マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のＯｐｅｎＦｌｏｗスイッチを介し、前記第一のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールに基づいて、前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のＯｐｅｎＦｌｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャストパケットを生成し、前記非マルチキャストネットワークは、アドレス変換された前記ユニキャストパケットを前記複数の第二のＯｐｅｎＦｌｏｗスイッチに転送し、前記複数の第二のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールに基づいて、前記ユニキャストパケットにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する、システム。
　【請求項２】　前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールおよび前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールは、前記マルチキャストアドレスポート番号と前記ユニキャストアドレスポート番号の変換を含む、請求項１に記載のシステム。
　【請求項３】　前記第一のＯｐｅｎＦｌｏｗスイッチは、前記マルチキャストパケットの送信先ＩＰアドレスとＵＤＰポート番号が前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールに符合しないと判断すると、前記マルチキャストパケットを前記ＯｐｅｎＦｌｏｗコントローラに転送し、前記ＯｐｅｎＦｌｏｗコントローラは、前記マルチキャストパケットのソースが属するマルチキャストネットワークに基づいて、前記アドレスポート番号データベースの中から前記マルチキャストネットワークおよび前記マルチキャストネットワークの境界スイッチにルーチングできる使用可能ユニキャストのポート番号を取得することにより、前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールおよび前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールを更新する、請求項１に記載のシステム。
　【請求項４】　前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールおよび前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールの更新は、前記ＯｐｅｎＦｌｏｗコントローラが、ＯｐｅｎＦｌｏｗプロトコルにより、前記マルチキャストパケットのマルチキャストアドレスポート番号と取得したユニチキャストアドレスポート番号との変換関係を前記第一のＯｐｅｎＦｌｏｗスイッチに書き込むことと、前記ＯｐｅｎＦｌｏｗコントローラが、前記ＯｐｅｎＦｌｏｗプロトコルにより、前記ユニキャストアドレスポート番号と前記マルチチキャストパケットのマルチチキャストアドレスポート番号との変換関係を前記複数の第二のＯｐｅｎＦｌｏｗスイッチに書き込むことを含む、請求項３に記載のシステム。　
　【請求項５】　前記使用可能ユニキャストアドレスは、前記非マルチキャストネットワークにおいてユニキャストＩＰアドレスを提供し、前記マルチキャストネットワークへルーチングする境界スイッチである、請求項３に記載のシステム。　
　【請求項６】　ＯｐｅｎＦｌｏｗプロトコルとＵＤＰポート番号アドレス変換を用いて
、クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
、
　マルチキャストパケット送信端がマルチキャストパケットを生成し、マルチキャストネットワークにおいてマルチキャストルーチングを行なうステップと、
　マルチキャストパケットを前記マルチキャストネットワークの境界にある第一のＯｐｅｎＦｌｏｗスイッチに送信するステップと、
　前記第一のＯｐｅｎＦｌｏｗスイッチは、予め格納された第一のＯｐｅｎＦｌｏｗルーチングルールに基づいて、前記マルチキャストパケットのマルチキャストアドレスポート番号を非マルチキャストネットワークにルーチング可能なユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号のユニキャストパケットを生成するステップと、
　前記ユニキャストパケットは前記ユニキャストアドレスポート番号を用いて前記非マルチキャストネットワークにおいてルーチング送信を行なうステップと、
　前記ユニキャストパケットを複数の第二のＯｐｅｎＦｌｏｗスイッチにルーチングするステップと、
　前記複数の第二のＯｐｅｎＦｌｏｗスイッチは、予め格納された第二のＯｐｅｎＦｌｏｗルーチングルールに基づいて、前記ユニキャストパケットの前記ユニキャストアドレスポート番号を元の前記マルチキャストパケットに対応するマルチキャストアドレスポート番号に戻すステップと、
　戻された前記マルチキャストパケットを、そのマルチキャストアドレスポート番号により、それぞれマルチキャストネットワークにおけるマルチキャストパケット受信端に転送するステップとを含む、方法。　
　【請求項７】　前記第一のＯｐｅｎＦｌｏｗスイッチは、前記マルチキャストパケットのマルチキャストアドレスポート番号を非マルチキャストネットワークにルーチング可能なユニキャストアドレスポート番号に変換する場合、前記マルチキャストパケットの送信先ＩＰアドレスとＵＤＰポート番号が予め格納された前記第一のＯｐｅｎＦｌｏｗルーチングルールに符合しないと判断した場合、
　前記第一のＯｐｅｎＦｌｏｗスイッチは、前記マルチキャストパケットを前記ＯｐｅｎＦｌｏｗコントローラに転送するステップと、
　前記ＯｐｅｎＦｌｏｗコントローラは、前記マルチキャストパケットのソースが属するマルチキャストネットワークに基づいて、前記アドレスポート番号データベースの中から前記マルチキャストネットワークおよび前記マルチキャストネットワークの境界スイッチにルーチングできる使用可能ユニキャストのポート番号を取得するステップと、
　前記ＯｐｅｎＦｌｏｗコントローラは、ＯｐｅｎＦｌｏｗプロトコルにより、前記ユニキャストパケットのマルチキャストアドレスポート番号と取得したユニキャストアドレスポート番号との変換関係を前記第一のＯｐｅｎＦｌｏｗスイッチにおける前記第一のＯｐｅｎＦｌｏｗルーチングルールに書き込むステップと、
　前記ＯｐｅｎＦｌｏｗコントローラは、前記ＯｐｅｎＦｌｏｗプロトコルにより、前記ユニキャストパケットアドレスポート番号とマルチキャストパケットのマルチキャストアドレスポート番号との変換関係を前記複数の第二のＯｐｅｎＦｌｏｗスイッチにおける前記第二のＯｐｅｎＦｌｏｗルーチングルールに書き込むステップと、をさらに含む、請求項６に記載の方法。
　【請求項８】　前記マルチキャストパケットがマルチキャストルーチングを行なう前に、
　前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチにおいて前記ＯｐｅｎＦｌｏｗスイッチの情報を設定することにより、前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチとの接続を構築するステップと、
　前記ＯｐｅｎＦｌｏｗコントローラが、前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチとの接続が正常であるか否かを確認するステップと、
　前記ＯｐｅｎＦｌｏｗコントローラが、予め設定されたＯｐｅｎＦｌｏｗのルーチングルールを前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチのルーチングテーブルに書き込むステップと、
　前記ＯｐｅｎＦｌｏｗコントローラが前記マルチキャストアドレスポート番号と前記ユニキャストアドレスポート番号との変換を行なう時、使用可能ユニキャストアドレスのポート番号を検索できるように、未配置かつルーチングに使用可能なアドレスポート番号をアドレスポート番号データベースに格納するステップと、をさらに含む、請求項６に記載の方法。　
　【請求項９】　前記ＯｐｅｎＦｌｏｗスイッチが前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチのルーチングテーブルに書き込む前記第一と第二のルーチングルールは、Matchエントリにおける送信先ＩＰアドレスはマルチキャストアドレスであり、Actionエントリは前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記複数の第二のＯｐｅｎＦｌｏｗスイッチと前記ＯｐｅｎＦｌｏｗコントローラとが接続している出口ポートにパケットをリダレクトすることであり、前記第一と第二のルーチングルールの優先権値は最小値に設定されることを指す、請求項８に記載の方法。
　【請求項１０】　前記使用可能ユニキャストアドレスは、前記非マルチキャストネットワークにおいて、ユニキャストアドレスルーチングを前記マルチキャストネットワークに提供する境界スイッチであることを指す、請求項７に記載の方法。」
第５　当審拒絶理由の理由１（サポート要件違反）、理由２（明確性要件違反）について
１　理由１について
　本願発明は、「クラスＤのマルチキャスト専用のＩＰアドレス」を用いていない（すなわち、課題を生じることのなく、明細書等に開示のない）マルチキャストパケットに関する態様をも含むものであり、そのような場合には、課題を解決しているとはいえないから、本願発明は、本願発明の課題を解決できることを当業者が認識できるように記載された範囲を超えているといえるとの指摘に対して、本件補正により、請求項１−１０に係る発明の「マルチキャストパケット」を「
クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
２　理由２について
　補正前の請求項１ないし１２に記載の「マルチキャストパケット」の定義が明確でないとの指摘に対して、本件補正により、「
クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
　以上の１及び２により、当審拒絶理由の理由１（サポート要件違反）、理由２（明確性要件違反）は解消した。
第６　引用文献、引用発明等
１．引用発明１について
（１）引用文献１記載事項
　当審拒絶理由で引用された引用文献１には、次の事項が記載されている。
ア　セクション2.1
「2. 1 IPマルチキャストとアプリケーションレイヤマルチキャスト
　まず，図1にIPマルチキャスト，アプリケーションレイヤマルチキャストにおけるパケット転送の概念を示す．IPマルチキャストの場合，ノード間をつなぐルータがパケットの複製を行う(図1(a))．図1(a)ではN1が送信サーバ，N2〜5が受信者であり，ルータR1〜R3がマルチキャストアドレス宛のパケットを複製することで全受信者にパケットを転送している．
任意のノードがマルチキャストトラフィックを受信するには，トポロジを構築する全ルータがマルチキャストに対応している必要があ
大規模なネットワークにおいて，全ルータをマルチキャスト対応に変更することは現実的ではな
対応していないルータが中間に存在する場合は，トンネリング等によって回避できるが，ネットワークの変更や，規模の大きさによって管理に大きなコストを要
IPマルチキャストを利用するサービスはISP内に閉じているか，連携関係にあるISP間に制限されて
イ　セクション　２．２
「2.2 OpenFlowによるマルチキャスト
　上記の問題点を解決する手法として，OpenFlow[5]を利用した，ユニキャストパケットの宛先書き換えと，複製・転送によるマルチキャスト技術が提案されている[6][7]．
OpenFlowはコントローラ(以下OFC)とスイッチ(以下OFSW)から構成され
OFSWでは，マッチルールに基づいてパケットの転送を行う．マッチルールが存在しないパケットを受信した場合，OFCに転送先を問い合わせ，OFSWに新たなフローエントリ(マッチルールとアクションの組)を追加することで柔軟な経路制御が可能とな
ウ　セクション３
「3. 提案手法
　提案手法では，サービス利用者からの受信要求に対応して，コントローラが最適なスイッチを選択し，フローエントリを制御することでサービス用トポロジを動的に構築する．
3. 1 想定するシナリオ
　はじめに，本研究で，想定しているシナリオについて説明する．2.1節で
記したように，全ルータをマルチキャストに対応したものに変更することは現実的ではな
そのため，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の順に，受信要求を行った場合について説明したが，各ホストの受信要求送信の間隔において，エントリの新規追加が可能な十分な時間間隔が存在する場合，受信要求の順序に依存せず，最終的には同じトポロジを構築可能である．」
エ　図４
「
」
　図４において、ホスト１から、ホスト２−６に対してパケットがマルチキャストされている点、及び、ＯＦＳＷ１，２間で、非ＯＦＳＷのルータを介して、パケットが転送（トラバース）されている点に着目すると、「マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせるＯｐｅｎＦｌｏｗプロトコルを用いたシステムであって、マルチキャスト非対応のルータを介して互いに接続されるＯＦＳＷ１，２と、ＯＦＳＷ１−３とＯＦＣとを備え」るシステムであって、「ホスト１からマルチキャストパケットを送信する場合、マルチキャストパケットはＯＦＳＷ１を介し、マルチキャスト非対応のルータはパケットをＯＦＳＷ２に転送し、ＯＦＳＷ２は、ホスト２，３へ転送するシステム」が開示されていると認定できる。
オ　図５
「
」
　図５には、「ＯＦＳＷ１−３は、ＵＤＰのsrc（送信元）ポート番号が２２２２３であった場合、ＯＦＣに問い合わせるというフローエントリが設定されていること」が開示されていると認定できる。
（２）引用発明
　よって、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「　任意のノードがマルチキャストトラフィックを受信するには，トポロジを構築する全ルータがマルチキャストに対応している必要があり、大規模なネットワークにおいて，全ルータをマルチキャスト対応に変更することは現実的ではなく，対応していないルータが中間に存在する場合は，トンネリング等によって回避できるが，ネットワークの変更や，規模の大きさによって管理に大きなコストを要し、現在では，ＩＰマルチキャストを利用するサービスはISP内に閉じているか，連携関係にあるISP間に制限されており（セクション2.1）、
　ＯｐｅｎＦｌｏｗは、ＯＦＳＷ（ＯｐｅｎＦｌｏｗスイッチ）とＯＦＣ（ＯｐｅｎＦｌｏｗコントローラ）から構成され、ＯＦＳＷではマッチルールに基づいてパケットの転送を行い、マッチルールが存在しないパケットを受信した場合、ＯＦＣに転送先を問い合わせ、ＯＦＳＷに新たなフローエントリ（マッチルールとアクションの組）を追加することで柔軟な経路制御が可能となり（セクション２．２）、
　上記したように、全ルータをマルチキャストに対応したものに変更することは現実的ではなく、そのため、ＯＦＳＷと通常のルータが混在するようなネットワーク環境を想定し、ＯＦＳＷは、特定の通信を除き、レイヤ２、３、４によるマルチレイヤルーティングを行い、同じＩＰアドレス宛への通信でも、トランスポートレイヤのプロトコル、ポート番号によって異なる経路を取得し、トランスポートレイヤにはＵＤＰを用いており（セクション３．１）、
　マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせるＯｐｅｎＦｌｏｗプロトコルを用いたシステムであって、
　マルチキャストパケットにマルチキャスト非対応のスイッチをトラバースさせるＯｐｅｎＦｌｏｗプロトコルを用いたシステムであって
　マルチキャスト非対応のルータを介して互いに接続されるＯＦＳＷ１，２と、
　ＯＦＳＷ１−３とＯＦＣとを備え（図４，セクション３．２）、
　ＯＦＳＷ１−３は、ＵＤＰのsrc（送信元）ポート番号が２２２２３であった場合、ＯＦＣに問い合わせるというフローエントリが設定されており（図５）、
　ホスト１からマルチキャストパケットを送信する場合、マルチキャストパケットはＯＦＳＷ１を介し、マルチキャスト非対応のルータはパケットをＯＦＳＷ２に転送し、ＯＦＳＷ２は、ホスト２，３へ転送する（図４，セクション３）、
　システム。」
２　引用文献２について
　当審拒絶理由で引用された引用文献２（特に、段落【０００２】−段落【０００５】、段落【００１２】−段落【００２６】、図１−４を参照）には、
「マルチキャストパケットを転送する際に、カプセル化（トンネリング）を行うとフラグメントが生じるという課題を解決するために（段落【０００３】、段落【０００４】）、
　ヘッダの書き換えを行うために、転送に使用するポートを記憶する記憶部３を備え（段落【００１５】、段落【００１８】、図２）、
　転送装置１０１に届いたグループ（宛先）アドレスG1、宛先ポートP1、送信者（始点）アドレスS1、送信（始点）ポートP2及びデータで構成される、マルチキャストパケット３０は（段落【００２０】−段落【００２１】）、
　宛先アドレスR2、送信元（始点）アドレスR1、宛先ポートP1とは異なる宛先ポートP3、転送元ポートP4及びデータにより構成される、ヘッダが書き換えられたパケット４０は転送装置２０１にユニキャストパケットとして送信され（段落【００２５】−段落【００２６】）、 
　転送装置２０１は、宛先ポートP3宛のパケット４０を転送装置１０１から受信すると、それをマルチキャスト転送パケットであると判断し、転送装置２０１は受信した転送パケット４０の転送元ポートP4から転送パケット情報表３２を検索して、元のマルチキャストパケット３０のグループアドレスG1、宛先ポートP1、送信者アドレスS1、送信ポートP2を取得し、これを用いて元のマルチキャストパケット３０を復元すること（段落【００２６】−段落【００２７】）」、
「ヘッダの書き換えにおいては、ＵＤＰヘッダ（P1-P4）及びＩＰヘッダのアドレス書き換えを行うこと」（図３，４、段落【００２５】）、
「転送装置において記憶部３とヘッダ書き換えなどを行うデータ処理装置２とが接続されていること」（図２、段落【００１５】−段落【００１７】）が記載されている。
第７．対比、判断
１．本願発明１について
（１）対比
　本願発明１と引用発明とを対比する。
ア　引用発明の「マルチキャストパケット」に「ＯｐｅｎＦｌｏｗ」を用いたシステムは、「マルチキャストパケットにマルチキャスト非対応のルータをトラバースさせ」ており、マルチキャスト非対応のルータは、非マルチキャストネットワークの要素であるから、本願発明１の「ＯｐｅｎＦｌｏｗプロトコルと
ＵＤＰポート番号アドレス変換
、クラスＤのマルチキャスト専用のＩＰアドレスでパケット送信が行われる
、
ネットワーク要素
イ　引用発明の「マルチキャスト非対応のルータを介して互いに接続されるＯＦＳＷ１，２」は、非マルチキャストネットワーク要素を介して互いに接続される複数のＯｐｅｎＦｌｏｗスイッチといえるから、本願発明１の「非マルチキャスト
ネットワーク
ネットワーク要素
ウ　引用発明の「ＯＦＣ（ＯｐｅｎＦｌｏｗコントローラ）」は、「マッチルールが存在しないパケットを受信した場合，OFCに転送先を問い合わせ，ＯＦＳＷに新たなフローエントリ(マッチルールとアクションの組)を追加することで柔軟な経路制御が可能とな」っており、「経路制御」とはルーチングであり、「ＯｐｅｎＦｌｏｗ」システムにおいて、フローエントリの集合はフローテーブルと呼ばれるルーチングテーブルであることは技術常識であるから、引用発明の「ＯＦＣ（ＯｐｅｎＦｌｏｗコントローラ）」は、ＯｐｅｎＦｌｏｗルーチングルールを各ＯｐｅｎＦｌｏｗスイッチ（OFS）のルーチングルールテーブルに書き込み、ＯｐｅｎＦｌｏｗスイッチは当該ルーチングルールに基づいてパケットを生成して転送するものであると認められる。
　また、引用発明は、「ＯＦＳＷ１−３」を備えており、ＯＦＳＷ１−２はそれぞれ、第１のＯｐｅｎＦｌｏｗスイッチ、第２のＯｐｅｎＦｌｏｗスイッチと言いうるものである。
　そして、引用発明においては、「ＯＦＳＷ１−３は、ＵＤＰのsrc（送信元）ポート番号が２２２２３であった場合、OFCに問い合わせるというフローエントリが設定されて」おり、当該フローエントリは、予め設定されたルーチングルールといえ、各々第１の予め設定されたルーチングルール、第２の予め設定されたルーチングルールと言いうるものである。
　よって、引用発明の「ＯＦＣ（ＯｐｅｎＦｌｏｗコントローラ）」は、本願発明１の「
前記アドレスポート番号データベースに接続され、
エ　引用発明は、「ホスト１からマルチキャストパケットを送信する場合、マルチキャストパケットはＯＦＳＷ１を介し、マルチキャスト非対応のルータはパケットをＯＦＳＷ２に転送し、ＯＦＳＷ２は、転送されたパケットそれぞれをホスト２，３へ転送し」ている。
　ここで、ホスト１は、マルチキャストパケット送信端に相当し、ＯＦＳＷ１,ＯＦＳＷ２は、それぞれ、第１のＯｐｅｎＦｌｏｗスイッチ、第２のＯｐｅｎＦｌｏｗスイッチと言いうるものであり、（３）で検討したとおり、各ＯｐｅｎＦｌｏｗスイッチは、予め設定されたルーチングルールに基づいてパケットを生成して転送するものであり、マルチキャスト非対応のルータは非マルチキャストネットワーク要素といえ、ホスト２，３はマルチキャストパケット受信端に相当する。
　したがって、引用発明は、ホスト１（マルチキャストパケット送信端）からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第１のＯｐｅｎＦｌｏｗスイッチを介し、第１のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第一のルーチングルールに基づいてパケットを生成して転送し 、マルチキャスト非対応ルータ（非マルチキャストネットワーク要素）は、生成されたパケットをＯＦＳＷ２（第２のＯｐｅｎＦｌｏｗスイッチ）に転送し、ＯＦＳＷ２（第２のＯｐｅｎＦｌｏｗスイッチ）は、前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールに基づいて、それぞれをホスト２，３（マルチキャストパケット受信端）に転送していると認められる。
　したがって、引用発明は、本願発明１の「マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のＯｐｅｎＦｌｏｗスイッチを介し、前記第一のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールに基づいて、
前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のＯｐｅｎＦｌｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャスト
ネットワーク
アドレス変換された
ユニキャスト
複数の
複数の
前記ユニキャストパケットにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後、
（２）一致点・相違点
　以上から、本願発明１と引用発明とは、以下の点において一致、及び相違する。
［一致点］
「ＯｐｅｎＦｌｏｗプロトコルを用いてマルチキャストパケットに非マルチキャストネットワーク要素をトラバースさせるシステムであって、
　非マルチキャストネットワーク要素を介して互いに接続される複数のＯｐｅｎＦｌｏｗスイッチと、
　前記複数のＯｐｅｎＦｌｏｗスイッチのうちの第一のＯｐｅｎＦｌｏｗスイッチおよび第二のＯｐｅｎＦｌｏｗスイッチにルーチングをさせるように、予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールおよび予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールをそれぞれ前記第一のＯｐｅｎＦｌｏｗスイッチおよび前記第二のＯｐｅｎＦｌｏｗスイッチのそれぞれのルーチングテーブルに書き込むＯｐｅｎＦｌｏｗコントローラと、
　を備え、
　マルチキャストパケット送信端からマルチキャストパケットを送信する場合、前記マルチキャストパケットは、前記第一のＯｐｅｎＦｌｏｗスイッチを介し、前記第一のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第一のＯｐｅｎＦｌｏｗルーチングルールに基づいて、パケットを生成し、前記非マルチキャストネットワーク要素は、前記パケットを前記第二のＯｐｅｎＦｌｏｗスイッチに転送し、前記第二のＯｐｅｎＦｌｏｗスイッチは、前記予め設定された第二のＯｐｅｎＦｌｏｗルーチングルールに基づいて、それぞれをマルチキャストネットワークにおけるマルチキャストパケット受信端に転送する、システム。」
［相違点１］共通点である、トラバースされる「非マルチキャストネットワーク要素」が、本願発明１は「非マルチキャスト
ネットワーク
ルータ
［相違点２］本願発明１が、「ＵＤＰポート番号アドレス変換を用いて、クラスＤのマルチキャスト専用のＩＰアドレスで送信が行われる」マルチキャストパケットを、トラバースさせているのに対して、引用発明にはそのようなことが特定されていない点。
［相違点３］本願発明１が、「アドレス変換に用いられるユニキャストアドレスポート番号を格納するアドレスポート番号データベース」を備えているのに対して、引用発明にはそのようなことが特定されていない点。
［相違点４］本願発明１が、第１のＯｐｅｎＦｌｏｗスイッチからのパケットを転送する「第２のＯｐｅｎＦｌｏｗスイッチ」を「複数」備えているのに対して、引用発明にはそのようなことが特定されていない点。
［相違点５］本願発明１の「ＯｐｅｎＦｌｏｗコントローラ」が、「前記アドレスポート番号データベースに接続され」ているのに対して、引用発明にはそのようなことが特定されていない点。
［相違点６］本願発明１の「第一のＯｐｅｎＦｌｏｗスイッチ」が、「前記マルチキャストパケットにおけるマルチキャストアドレスポート番号を前記複数の第二のＯｐｅｎＦｌｏｗスイッチのユニキャストアドレスポート番号に変換することにより、前記ユニキャストアドレスポート番号を有するユニキャストパケットを生成し」、「第２のＯｐｅｎＦｌｏｗスイッチ」が「前記ユニキャストパケッ トにおける前記ユニキャストアドレスポート番号を元の前記マルチキャストアドレスポート番号に変換した後」、転送するのに対して、引用発明にはそのようなことが特定されていない点。
（３）相違点についての判断
　事案に鑑みて、［相違点２］より検討を行う。
　引用発明は、マルチキャストパケットをトラバースする点は本願発明1と共通している。また、引用文献１には、「トランスポートレイヤにはＵＤＰを用い、ＵＤＰ ポート番号はコンテンツを一意に識別するのに用いる」こと、すなわち、コンテンツの識別にＵＤＰ ポート番号を利用すること、及び、「大規模なネットワークにおいて，全ルータをマルチキャスト対応に変更することは現実的ではなく，対応していないルータが中間に存在する場合は，トンネリング等によって回避できるが，ネットワークの変更や，規模の大きさによって管理に大きなコストを要」すること、すなわち、マルチキャストに対応しないネットワーク要素をトンネリングで通過させることが示唆されている。
　また、引用文献２に記載の「ヘッダが書き換えられたパケット４０」は、ＵＤＰヘッダのポート番号が書き換えられていることから、引用文献２には、ドメイン間でマルチキャストパケットを伝送する場合に、ＵＤＰポート番号の変換を用いて、マルチキャストアドレスが付加されたパケットを、ユニキャストアドレスにヘッダの書き換え（アドレス変換）を行ってから、トンネリングすることが記載されているといえる。
　しかしながら、引用発明は、要するに、「大規模なネットワークにおいて，全ルータをマルチキャスト対応に変更することは現実的ではな」いとの課題を解決するために、すなわち、マルチキャストのための「特別な」ＩＰアドレスである「マルチキャストアドレス」を用いることなしにマルチキャスト伝送を実現するために、ＯｐｅｎＦｌｏｗネットワークにおけるマルチキャスト技術と、非ＯｐｅｎＦｌｏｗ区間での、通常の（ユニキャスト）ＩＰアドレスを用いたトラバースとを組み合わせるという構成であるから、引用発明において、マルチキャストのための「特別な」ＩＰアドレスである「マルチキャストアドレス」を採用することは想定されておらず、むしろ阻害要因があるといえる。また、「ＵＤＰポート番号アドレス変換を用いて、クラスＤのマルチキャスト専用のＩＰアドレスで送信が行われる」マルチキャストパケットをトラバースさせることは本願優先日前において、周知技術であったともいえない。
　したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用発明、引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２．　本願発明２−１０について
　本願発明２−１０も、相違点２に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明、引用文献２に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第８　原査定について
　本願発明１―１０は、前記「第７」で検討したとおり、当業者であっても、原査定において引用された引用文献Ａ（当審拒絶理由の引用文献２）に記載された発明に基づいて、容易に発明できたものとはいえない。
　したがって、原査定の理由を維持することはできない。
第８　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。