【事件の表示】
　特願２０１６−５７５８３１「ＳＤＮネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法および装置」拒絶査定不服審判事件〔平成２８年　１月　７日国際公開、ＷＯ２０１６／００１７２７，平成２９年　９月２８日国内公表，特表２０１７−５２８９３８，請求項の数（１４）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　本願は，２０１５年５月２２日（パリ条約による優先権主張外国庁受理２０１４年７月２日　中華人民共和国）を国際出願日とする出願であって，
　平成２９年２月２７日付けで特許法１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，同日付けで審査請求がなされ，平成３０年４月２７日付けで審査官により拒絶理由が通知され，これに対して平成３０年７月３０日付けで意見書が提出されると共に手続補正がなされたが，平成３０年８月６日付けで審査官により拒絶査定がなされ，これに対して平成３０年１２月７日付けで審判請求がなされると共に手続補正がなされ，平成３１年２月２５日付けで審査官により特許法１６４条３項の規定に基づく報告がなされたものである。
　
第２．原審拒絶査定の概要
　原審における平成３０年８月６日付けの拒絶査定（以下，これを「原審拒絶査定」という）は，概略，以下のとおりである。
　
　本願の請求項１〜本願の請求項１４に係る発明は，以下の引用文献１〜引用文献４に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法２９条２項の規定により特許を受けることができない。
　
　引用文献一覧
１．国際公開第２０１３／１８８６６５号
２．堀越功，Ｍｏｂｉｌｅ  Ｗｏｒｌｄ  Ｃｏｎｇｒｅｓｓ２０１３報告，日経コミュニケーション，日本，日経ＢＰ社 　Ｎｉｋｋｅｉ　Ｂｕｓｉｎｅｓｓ　Ｐｕｂｌｉｃａｔｉｏｎｓ，Ｉｎｃ．，２０１３年　３月２８日，第５９１号，p.37
３．Ｅｎａｂｌｉｎｇ　Ａｇｉｌｅ　Ｓｅｒｖｉｃｅ　Ｃｈａｉｎｉｎｇｗｉｔｈ　Ｓｅｒｖｉｃｅ　Ｂａｓｅｄ　Ｒｏｕｔｉｎｇ，［ｏｎｌｉｎｅ］，２０１３年，[平成３０年４月２４日検索],インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｈｕａｗｅｉ．ｃｏｍ／ｉｌｉｎｋ／ｅｎ／ｄｏｗｎｌｏａｄ／ＨＷ＿３０８６２２＞
４．国際公開第２０１３／１５６９３１号
　
第３．本願発明について
　本願の請求項１〜本願の請求項１４に係る発明（以下，これを「本願発明１〜本願発明１４」という）は，平成３０年１２月７日付けの手続補正により補正された特許請求の範囲の請求項１〜請求項１４に記載された事項により特定されるものであり，そのうち，本願発明１は，次のとおりのものである。
　
「ＳＤＮネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法であって，
　ａ．ＰＣＲＦが，アプリケーションに対応する多次元コンテキスト情報に基づき，アプリケーションに関するアプリケーションサービスチェインを決定し，対応するアプリケーションサービスチェイン情報を，ＳＤＮコントローラに送信するステップであって，アプリケーションサービスチェインがサービス機能の順序付きリストである，ステップと，
　ｂ．ＳＤＮコントローラが，アプリケーションサービスチェイン情報に基づき，アプリケーションに関する転送ルールを決定し，転送ルールを対応するサービスチェイニングインフラネットワークに送信するステップと，
　ｃ．サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント（ＳＣＥＰ）が，転送ルールに基づき，対応するサービス機能を実行するステップとを含む，方法。」
　
第４．引用文献に記載の事項及び引用文献に記載の発明
１．引用文献１について
（１）引用文献１に記載の事項
　引用文献１には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「One possible method for reducing capital and operational expensesis to use software defined networks (SDNs). SDNs can be used to manage flows, control switches, control network access, and track user location and motion. SDNs can also be used to efficiently use network components. For example, SDNs may be used to power off unused equipment during non-peak periodsto conserve energy.
　Some SDN models centralize the control of network elements, such as routers and switches, by removing intelligence from the routers and switches and placing that intelligence in a centralized location. One such effort to  provide centralized control of routers and switches is the openflow architecture described in the Openflow Switch Specification, Version1.1.0, February 28, 2011 , the disclosure of which is incorporated herein by reference in its entirety and a copy of which is attached hereto.According to the Openflow Switch Specification, an openflow controller controls functions of openflow-enabled switches. Openflow has not been used to control telecommunications network elements. Accordingly, there exists a need for extending openflow into telecommunications networks to reduce operating and capital expenses and to make networks more scalable and more flexible.
　
　　　　　　　　　　　　　　　SUMMARY 
　The subject matter described herein includes methods, systems, and computer readable media for providing a PCRF with an integrated openflow controller. According to one system,a policy and charging rules function (PCRF) is configured to determine policies to apply to network sessions or users. An openflow controller is integrated with the PCRF and configured to provide instructions to telecommunications network elements in an openflow protocol to implement the policies.」（１頁２６行〜２頁１８行）
（【０００４】
　資本および運営経費を削減するための１つの可能な方法は，ソフトウェア定義ネットワーク（software defined network：ＳＤＮ）を使用することである。ＳＤＮを用いて，フローを管理し，スイッチを制御し，ネットワークアクセスを制御し，ユーザの位置および動きを追跡することができる。ＳＤＮを用いて，ネットワーク構成要素を効率的に使用することもできる。たとえば，ＳＤＮを用いて，非ピーク期間中に使われていない機器の電源を切ってエネルギーを節約することができる。
【０００５】
　ＳＤＮモデルの中には，ルータおよびスイッチからインテリジェンスを取出し，そのインテリジェンスを集中化した場所に置くことによって，ルータおよびスイッチなどのネットワーク要素の制御を集中化するものがある。ルータおよびスイッチの集中化制御を提供する１つのそのような努力は，Openflow Switch Specification, Version 1.1.0, February28, 2011に記載されたオープンフローアーキテクチャであり，この文献の開示は，全文が引用によって本明細書に援用され，その写しがここに添付される。Openflow Switch Specificationによると，オープンフローコントローラがオープンフロー対応スイッチの機能を制御する。オープンフローはこれまで，電気通信ネットワーク要素を制御するためには使用されていない。したがって，オープンフローを電気通信ネットワークに拡大して運営および資本経費を削減し，ネットワークをよりスケーラブルにおよびより柔軟にすることが必要とされている。
【発明の概要】
【課題を解決するための手段】
【０００６】
　概要
　ここに記載される主題は，ＰＣＲＦに統合型オープンフローコントローラを提供するための方法，システム，およびコンピュータ読取可能媒体を含む。１つのシステムによると，ポリシーおよび課金ルール機能（policy and chargingrules function：ＰＣＲＦ）は，ネットワークセッションまたはユーザに適用すべきポリシーを決定するように構成される。オープンフローコントローラはＰＣＲＦに統合され，オープンフロープロトコルで電気通信ネットワーク要素に命令を与えて当該ポリシーを実現させるように構成される。引用文献１の日本語公報である，特表２０１５−５２８２２８号公報より引用。以下，同じ。）
　
Ｂ．「Figure 2 is a block diagram illustrating an exemplary architecture for a software-defined network including PCRF 100 with integrated openflow controller 102. Referring to Figure 2, PCRF 100 controls BRAS/BNG106, GGSN 108A,PDN-GW/S-GW 108B, eNodeB 104, Wi-Fi access point 114 and openflow switches/routers 116 using openflow. PCRF 100 may also communicate with DSR 118 and HSS 120 using any suitable protocol, such as Diameter. PCRF 100 may support various applications, such as content streaming 122, voice over LTE 124, rich communications suite (RCS) 126, cloud services 128, and business applications 130. 
　Figure 3 is a flow diagram illustrating exemplary messages that may be exchanges when a node such as BRAS/BNG 106 is controlled by PCRF 100 using openflow. Referring to Figure 3, in line 1 , a user element 300 sends an initial Ethernet frame or an IP packet to the network. BRAS/BNG 106 receives the frame or packet, performs a lookup in its flow table, and determines that there are no matching entries. Accordingly, in line 2, BRAS/BNG 106 sends the frame or packet to PCRF 100 to determine what policy to apply to the frame or packet and to subsequent frames or packets in the same flow as the Ethernet frame or IP packet. Openflow controller 102 receives the frame or packet and determines the policy to apply to the frame or packet. In line 3, openflow controller 102 sends an openflow add command instructing BRAS/BNG 106 to add an entry to its flow table to implement a policy for frames associated with the same flow as the received Ethernet frame. Subsequent Ethernet frames or IP packets associated with the same flow may be switched by BRAS/BNG 106 using the entry added to its flow table by openflow controller 102.」（４頁３行〜２７行）
（【００１２】
  図２は，統合型オープンフローコントローラ１０２を有するＰＣＲＦ１００を含むソフトウェア定義ネットワークの例示的なアーキテクチャを示すブロック図である。図２を参照して，ＰＣＲＦ１００は，オープンフローを用いて，ＢＲＡＳ／ＢＮＧ１０６，ＧＧＳＮ１０８Ａ，ＰＤＮ−ＧＷ／Ｓ−ＧＷ１０８Ｂ，ｅノードＢ１０４，Ｗｉ−Ｆｉアクセスポイント１１４およびオープンフロースイッチ／ルータ１１６を制御する。ＰＣＲＦ１００はさらに，Diameterなどの任意の好適なプロトコルを用いてＤＳＲ１１８およびＨＳＳ１２０と通信し得る。ＰＣＲＦ１００は，コンテンツストリーミング１２２，ボイスオーバーＬＴＥ１２４，リッチコミュニケーションスイート（ＲＣＳ）１２６，クラウドサービス１２８，およびビジネスアプリケーション１３０などのさまざまなアプリケーションをサポートし得る。
【００１３】
  図３は，ＢＲＡＳ／ＢＮＧ１０６などのノードがオープンフローを用いるＰＣＲＦ１００によって制御される場合のエクスチェンジであり得る例示的なメッセージを示すフロー図である。図３を参照して，ライン１では，ユーザ要素３００が最初のイーサネット(登録商標）フレームまたはＩＰパケットをネットワークに送信する。ＢＲＡＳ／ＢＮＧ１０６は当該フレームまたはパケットを受信し，そのフローテーブルでルックアップを行い，一致するエントリがないと判断する。したがって，ライン２では，ＢＲＡＳ／ＢＮＧ１０６は当該フレームまたはパケットをＰＣＲＦ１００に送信し，当該イーサネットフレームまたはＩＰパケットと同じフローで当該フレームまたはパケットおよびその後のフレームまたはパケットにどのポリシーを適用すべきか決定する。オープンフローコントローラ１０２は当該フレームまたはパケットを受信し，当該フレームまたはパケットに適用すべきポリシーを決定する。ライン３では，オープンフローコントローラ１０２はオープンフロー追加コマンドを送信し，ＢＲＡＳ／ＢＮＧ１０６に，そのフローテーブルにエントリを追加し，受信したイーサネットフレームと同じフローに関連付けられたフレームのポリシーを実現することを命令する。同じフローに関連付けられたその後のイーサネットフレームまたはＩＰパケットは，オープンフローコントローラ１０２によってそのフローテーブルに追加されたエントリを用いるＢＲＡＳ／ＢＮＧ１０６によって切替えられ得る。）
　
（２）引用文献１に記載の発明
　上記Ａ，および，上記Ｂに引用した，引用文献１の記載内容から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「ソフトウェア定義ネットワーク（software defined network：ＳＤＮ）に関するポリシー及び課金ルール機能を実現させる方法であって，
　さまざまなアプリケーションをサポートし得るポリシーおよび課金ルール機能（policy and chargingrules function：ＰＣＲＦ）は，ネットワークセッションまたはユーザに適用すべきポリシーを決定し，
　オープンフローコントローラは，前記ポリシーを実現することを命令する，方法。」
　
２．引用文献２について
　引用文献２には，関連する図面と共に，次の事項が記載されている。
　
Ｃ．「
」
　
３．引用文献３について
　引用文献３には，関連する図面と共に，次の事項が記載されている。
　
Ｄ．「2.2 Multi-Dimensional Policy Control
・・・・・The service routing policy is decided according to the subscription. So the service routing policy is associated with user profile.With the user specific service routing policy, the traffic can be classified into differnt user categories. For example, the video traffic of VIP user can be steered via a video optimizer service enabler,while the video taffic of regular user goes directly to the internet.」（４頁１行〜１３行）
（多次元ポリシ制御
・・・・・サービス・ルーティング・ポリシは，契約に従って決定される。それ故，サービス・ルーティング・ポリシは，ユーザのプロファイルに関連している。ユーザの具体的なサービス・ルーティング・ポリシによって，トラフィックは，異なるユーザのカテゴリに分類される。たとえば，通常のユーザのビデオ・トラフィックが，直接，インターネットに向かう間に，ＶＩＰユーザのビデオ・トラフィックは，ビデオ最適化サービス・イネーブラに対して向かうようにすることができる。当審にて訳出。）
　
４．引用文献４について
Ｅ．「3. The method of claim 1, wherein the step of associating the received packet with the service set includes assigning an ordered list of services to be applied to the received packet.」
（【請求項３】
  受信された前記パケットを前記サービスセットに関連付けるステップは，受信された前記パケットに適用されるべきサービスの順序付きリストを割り当てることを含む，請求項１の方法。引用文献４の日本語公報である，特表２０１５−５１７２７２号公報より引用。以下，同じ。）
　
Ｆ．「[0005] A service chain, or path,is an ordered set of services. Traffic steering is the action of classifying traffic and directing the different classes of traffic through specific service chains.Three broad classes of solutions are used today to implement some form of traffic steering and service chaining.」
（【０００５】
  サービスチェーン又はパスは，順序付きのサービスのセットである。トラフィックの誘導（traffic  steering）は，トラフィックを分類し，様々なクラスのトラフィックを特定のサービスチェーンを通過するように方向付けるアクションである。大まかな３つのクラスの解決策が，今日，何らかの形態のトラフィックの誘導及びサービスの連鎖化（chaining）を実装するために使用されている。）
　
Ｇ．「[0099] Figure 6 is a flow chart illustrating another embodiment of the presentinvention. The process begins by receiving a packet in step 600. The direction the packet is traveling is determined in 610. The direction the received packet is traveling  can be upstream or downstream, and can be determined in accordance with the ingressport the packet was received on. 
[00100] In 620, the received packet is associated with a serviceset. Associating the packet with the service set can include assigning an ordered list of services to be applied to the packet in accordance with at least one header field of the packet. The at least one header field can be selected from a group including: a source address,a destination address, a source port, a destination port or a protocol. The service set can also be assigned in accordance with the determined direction the packet is heading. The assigned ordered list of services can be attached to the received packet as metadata.」
（【０１０６】
　図６は，本発明の別の実施形態を示すフローチャートである。ステップ６００においてパケットを受信することにより処理が開始する。パケットが伝播する方向が６１０で判定される。受信されたパケットが伝播する方向はアップストリーム又はダウンストリームであることができ，パケットが受信された入口ポートに従って判定され得る。
【０１０７】
　６２０で，受信されたパケットがサービスセットに関連付けられる。パケットをサービスセットに関連付けることは，パケットの少なくとも１つのヘッダフィールドに従って，パケットに適用されるべきサービスの順序付きリストを割り当てることを含み得る。少なくとも１つのヘッダフィールドは，送信元アドレス，宛て先アドレス，送信元ポート，宛て先ポート又はプロトコルを含む群から選択され得る。サービスセットも，判定されたパケットが向かう方向に従って割り当てられ得る。割り当てられたサービスの順序付きリストは，メタデータとして受信されたパケットに添付され得る。）
　
第５．本願発明と引用発明との対比及び相違点についての判断
１．本願発明１について
（１）本願発明１と引用発明との対比
　本願発明１と，引用発明とを対比すると，本願発明１と，引用発明との，一致点，及び，相違点は，以下のとおりである。
　
［一致点］
　ＳＤＮネットワークに対するポリシおよび課金制御の方法であって，
　ＰＣＲＦが，条件を決定し，
　条件実現部が，前記条件に従って，所定の機能を実行する，方法。
　
［相違点１］
“ポリシおよび課金制御の方法”に関して，
　本願発明１においては，「ＳＤＮネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法」であるのに対して，
　引用発明においては，「アプリケーションサービスチェインに対するポリシおよび課金制御」に関する言及がない点。
　
［相違点２］
“条件を決定し”に関して，
　本願発明１においては，「ＰＣＲＦが，アプリケーションに対応する多次元コンテキスト情報に基づき，アプリケーションに関するアプリケーションサービスチェインを決定」するものであるのに対して，
　引用発明においては，「ネットワークセッションまたはユーザに適用すべきポリシーを決定」するものである点。
　
［相違点３］
　本願発明１においては，「対応するアプリケーションサービスチェイン情報を，ＳＤＮコントローラに送信するステップであって，アプリケーションサービスチェインがサービス機能の順序付きリストである，ステップ」を有するものであるのに対して，
　引用発明においては，そのような「ステップ」についての言及がない点。
　
［相違点４］
　本願発明１においては，「ＳＤＮコントローラが，アプリケーションサービスチェイン情報に基づき，アプリケーションに関する転送ルールを決定し，転送ルールを対応するサービスチェイニングインフラネットワークに送信するステップ」を有するものであるのに対して，
　引用発明においては，そのような「ステップ」についての言及がない点。
　
［相違点５］
“条件実現部が，前記条件に従って，所定の機能を実行する”点に関して，
　本願発明１においては，「サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント（ＳＣＥＰ）が，転送ルールに基づき，対応するサービス機能を実行する」ものであるのに対して，
　引用発明においては，「ＳＣＥＰ」についての言及がない点。
　
（２）相違点についての当審の判断
　事案に鑑みて，上記［相違点２］について先に検討すると，［相違点２］に係る本願発明１の構成は，上記引用文献１〜上記引用文献４には記載されておらず，本願の第１国出願前において周知技術であるともいえない。
　したがって，本願発明１は，他の相違点を検討するまでもなく，当業者であっても引用発明，引用文献２〜引用文献４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
２．本願発明２〜本願発明５について
　本願の請求項２〜本願の請求項５は，直接・間接に本願の請求項１を引用するものであるから，上記「第５．本願発明と引用発明との対比及び相違点についての判断」の「１．本願発明１について」における「（２）相違点についての当審の判断」において検討した［相違点２］の構成を内包している。
　したがって，本願発明２〜本願発明５は，上記「第５．本願発明と引用発明との対比及び相違点についての判断」の「１．本願発明１について」における「（２）相違点についての当審の判断」において検討したとおり，当業者であっても引用発明，引用文献２〜引用文献４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
３．本願発明６〜本願発明１１について
　本願発明６，本願発明８，及び，本願発明９は，上記「第５．本願発明と引用発明との対比及び相違点についての判断」の「１．本願発明１について」における「（２）相違点についての当審の判断」において検討した［相違点２］の構成を内包し，
　本願の請求項７は，本願の請求項６を引用し，本願の請求項１０，及び，本願の請求項１１は，本願の請求項９を引用しているので，本願発明７，本願発明１０，及び，本願発明１１は，本願発明６，本願発明８，及び，本願発明９と同じく，前記［相違点２］］の構成を内包している。
　したがって，本願発明６〜本願発明１１は，上記「第５．本願発明と引用発明との対比及び相違点についての判断」の「１．本願発明１について」における「（２）相違点についての当審の判断」において検討したとおり，当業者であっても引用発明，引用文献２〜引用文献４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
４．本願発明１２〜本願発明１４について
（１）本願発明１２と引用発明との対比
　本願発明１２は，上記「第５．本願発明と引用発明との対比及び相違点についての判断」の「１．本願発明１について」における「（１）本願発明１と引用発明との対比」において指摘した，［相違点５］における「サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント（ＳＣＥＰ）」に関する構成を有するものである。
　
（２）相違点についての当審の判断
　「ＳＣＥＰ」については，上記引用文献１〜上記引用文献４には記載されておらず，本願の第１国出願前において周知技術であるともいえない。
　したがって，本願発明１２は，当業者であっても引用発明，引用文献２〜引用文献４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
（３）本願発明１３，及び，本願発明１４について
　本願の請求項１３，及び，本願の請求項１４は，本願の請求項１２を直接・間接に引用するものであるから，上記（２）において検討した，「ＳＣＥＰ」に関する構成を内包している。
　したがって，上記（２）において検討したとおり，本願発明１３，及び，本願発明１４は，当業者であっても引用発明，引用文献２〜引用文献４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
第６．原審拒絶査定についての判断
　本願発明１〜本願発明１１は，上記検討の［相違点２］に係る構成を有しており，また，本願発明１２〜本願発明１４は，上記「４．本願発明１２〜本願発明１４について」の「（２）相違点についての当審の判断」において検討した［相違点５］に係る構成を有するものであるから，当業者であっても，拒絶査定において引用された引用文献１〜引用文献４に基づいて，容易に発明できたものとはいえない。したがって，原査定の理由を維持することはできない。
　
第７．むすび
　以上のとおり，原審拒絶査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。