ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 H04L |
|---|---|
| 管理番号 | 1360249 |
| 審判番号 | 不服2018-16352 |
| 総通号数 | 244 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2020-04-24 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2018-12-07 |
| 確定日 | 2020-03-17 |
| 事件の表示 | 特願2016-575831「SDNネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法および装置」拒絶査定不服審判事件〔平成28年 1月 7日国際公開、WO2016/001727,平成29年 9月28日国内公表,特表2017-528938,請求項の数(14)〕について,次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は,特許すべきものとする。 |
| 理由 |
第1.手続の経緯 本願は,2015年5月22日(パリ条約による優先権主張外国庁受理2014年7月2日 中華人民共和国)を国際出願日とする出願であって, 平成29年2月27日付けで特許法184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,同日付けで審査請求がなされ,平成30年4月27日付けで審査官により拒絶理由が通知され,これに対して平成30年7月30日付けで意見書が提出されると共に手続補正がなされたが,平成30年8月6日付けで審査官により拒絶査定がなされ,これに対して平成30年12月7日付けで審判請求がなされると共に手続補正がなされ,平成31年2月25日付けで審査官により特許法164条3項の規定に基づく報告がなされたものである。 第2.原審拒絶査定の概要 原審における平成30年8月6日付けの拒絶査定(以下,これを「原審拒絶査定」という)は,概略,以下のとおりである。 本願の請求項1?本願の請求項14に係る発明は,以下の引用文献1?引用文献4に基づいて,その発明の属する技術の分野における通常の知識を有する者(以下,「当業者」という。)が容易に発明できたものであるから,特許法29条2項の規定により特許を受けることができない。 引用文献一覧 1.国際公開第2013/188665号 2.堀越功,Mｏbile Wｏｒld Cｏngｒeｓｓ2013報告,日経コミュニケーション,日本,日経BP社 Nikkei Bｕｓineｓｓ Pｕblicaｔiｏnｓ,Inc.,2013年 3月28日,第591号,p.37 3.Enabling Agile Seｒｖice Chainingｗiｔh Seｒｖice Baｓed Rｏｕｔing,[ｏnline],2013年,[平成30年4月24日検索],インターネット＜URL:hｔｔｐ://ｗｗｗ.hｕaｗei.cｏm/ilink/en/dｏｗnlｏad/HW_308622＞ 4.国際公開第2013/156931号 第3.本願発明について 本願の請求項1?本願の請求項14に係る発明(以下,これを「本願発明1?本願発明14」という)は,平成30年12月7日付けの手続補正により補正された特許請求の範囲の請求項1?請求項14に記載された事項により特定されるものであり,そのうち,本願発明1は,次のとおりのものである。 「SDNネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法であって, a.PCRFが,アプリケーションに対応する多次元コンテキスト情報に基づき,アプリケーションに関するアプリケーションサービスチェインを決定し,対応するアプリケーションサービスチェイン情報を,SDNコントローラに送信するステップであって,アプリケーションサービスチェインがサービス機能の順序付きリストである,ステップと, b.SDNコントローラが,アプリケーションサービスチェイン情報に基づき,アプリケーションに関する転送ルールを決定し,転送ルールを対応するサービスチェイニングインフラネットワークに送信するステップと, c.サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント(SCEP)が,転送ルールに基づき,対応するサービス機能を実行するステップとを含む,方法。」 第4.引用文献に記載の事項及び引用文献に記載の発明 1.引用文献1について (1)引用文献1に記載の事項 引用文献1には,関連する図面と共に,次の事項が記載されている。 A.「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.」(1頁26行?2頁18行) (【0004】 資本および運営経費を削減するための1つの可能な方法は,ソフトウェア定義ネットワーク(software defined network:SDN)を使用することである。SDNを用いて,フローを管理し,スイッチを制御し,ネットワークアクセスを制御し,ユーザの位置および動きを追跡することができる。SDNを用いて,ネットワーク構成要素を効率的に使用することもできる。たとえば,SDNを用いて,非ピーク期間中に使われていない機器の電源を切ってエネルギーを節約することができる。 【0005】 SDNモデルの中には,ルータおよびスイッチからインテリジェンスを取出し,そのインテリジェンスを集中化した場所に置くことによって,ルータおよびスイッチなどのネットワーク要素の制御を集中化するものがある。ルータおよびスイッチの集中化制御を提供する1つのそのような努力は,Openflow Switch Specification, Version 1.1.0, February28, 2011に記載されたオープンフローアーキテクチャであり,この文献の開示は,全文が引用によって本明細書に援用され,その写しがここに添付される。Openflow Switch Specificationによると,オープンフローコントローラがオープンフロー対応スイッチの機能を制御する。オープンフローはこれまで,電気通信ネットワーク要素を制御するためには使用されていない。したがって,オープンフローを電気通信ネットワークに拡大して運営および資本経費を削減し,ネットワークをよりスケーラブルにおよびより柔軟にすることが必要とされている。 【発明の概要】 【課題を解決するための手段】 【0006】 概要 ここに記載される主題は,PCRFに統合型オープンフローコントローラを提供するための方法,システム,およびコンピュータ読取可能媒体を含む。1つのシステムによると,ポリシーおよび課金ルール機能(policy and chargingrules function:PCRF)は,ネットワークセッションまたはユーザに適用すべきポリシーを決定するように構成される。オープンフローコントローラはPCRFに統合され,オープンフロープロトコルで電気通信ネットワーク要素に命令を与えて当該ポリシーを実現させるように構成される。<引用文献1の日本語公報である,特表2015-528228号公報より引用。以下,同じ。) B.「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.」(4頁3行?27行) (【0012】 図2は,統合型オープンフローコントローラ102を有するPCRF100を含むソフトウェア定義ネットワークの例示的なアーキテクチャを示すブロック図である。図2を参照して,PCRF100は,オープンフローを用いて,BRAS/BNG106,GGSN108A,PDN-GW/S-GW108B,eノードB104,Wi-Fiアクセスポイント114およびオープンフロースイッチ/ルータ116を制御する。PCRF100はさらに,Diameterなどの任意の好適なプロトコルを用いてDSR118およびHSS120と通信し得る。PCRF100は,コンテンツストリーミング122,ボイスオーバーLTE124,リッチコミュニケーションスイート(RCS)126,クラウドサービス128,およびビジネスアプリケーション130などのさまざまなアプリケーションをサポートし得る。 【0013】 図3は,BRAS/BNG106などのノードがオープンフローを用いるPCRF100によって制御される場合のエクスチェンジであり得る例示的なメッセージを示すフロー図である。図3を参照して,ライン1では,ユーザ要素300が最初のイーサネット(登録商標)フレームまたはIPパケットをネットワークに送信する。BRAS/BNG106は当該フレームまたはパケットを受信し,そのフローテーブルでルックアップを行い,一致するエントリがないと判断する。したがって,ライン2では,BRAS/BNG106は当該フレームまたはパケットをPCRF100に送信し,当該イーサネットフレームまたはIPパケットと同じフローで当該フレームまたはパケットおよびその後のフレームまたはパケットにどのポリシーを適用すべきか決定する。オープンフローコントローラ102は当該フレームまたはパケットを受信し,当該フレームまたはパケットに適用すべきポリシーを決定する。ライン3では,オープンフローコントローラ102はオープンフロー追加コマンドを送信し,BRAS/BNG106に,そのフローテーブルにエントリを追加し,受信したイーサネットフレームと同じフローに関連付けられたフレームのポリシーを実現することを命令する。同じフローに関連付けられたその後のイーサネットフレームまたはIPパケットは,オープンフローコントローラ102によってそのフローテーブルに追加されたエントリを用いるBRAS/BNG106によって切替えられ得る。) (2)引用文献1に記載の発明 上記A,および,上記Bに引用した,引用文献1の記載内容から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。 「ソフトウェア定義ネットワーク(software defined network:SDN)に関するポリシー及び課金ルール機能を実現させる方法であって, さまざまなアプリケーションをサポートし得るポリシーおよび課金ルール機能(policy and chargingrules function:PCRF)は,ネットワークセッションまたはユーザに適用すべきポリシーを決定し, オープンフローコントローラは,前記ポリシーを実現することを命令する,方法。」 2.引用文献2について 引用文献2には,関連する図面と共に,次の事項が記載されている。 C.「  」 3.引用文献3について 引用文献3には,関連する図面と共に,次の事項が記載されている。 D.「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.」(4頁1行?13行) (多次元ポリシ制御 ・・・・・サービス・ルーティング・ポリシは,契約に従って決定される。それ故,サービス・ルーティング・ポリシは,ユーザのプロファイルに関連している。ユーザの具体的なサービス・ルーティング・ポリシによって,トラフィックは,異なるユーザのカテゴリに分類される。たとえば,通常のユーザのビデオ・トラフィックが,直接,インターネットに向かう間に,VIPユーザのビデオ・トラフィックは,ビデオ最適化サービス・イネーブラに対して向かうようにすることができる。<当審にて訳出。>) 4.引用文献4について E.「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.」 (【請求項3】 受信された前記パケットを前記サービスセットに関連付けるステップは,受信された前記パケットに適用されるべきサービスの順序付きリストを割り当てることを含む,請求項1の方法。引用文献4の日本語公報である,特表2015-517272号公報より引用。以下,同じ。) F.「[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.」 (【0005】 サービスチェーン又はパスは,順序付きのサービスのセットである。トラフィックの誘導(traffic steering)は,トラフィックを分類し,様々なクラスのトラフィックを特定のサービスチェーンを通過するように方向付けるアクションである。大まかな3つのクラスの解決策が,今日,何らかの形態のトラフィックの誘導及びサービスの連鎖化(chaining)を実装するために使用されている。) G.「[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.」 (【0106】 図6は,本発明の別の実施形態を示すフローチャートである。ステップ600においてパケットを受信することにより処理が開始する。パケットが伝播する方向が610で判定される。受信されたパケットが伝播する方向はアップストリーム又はダウンストリームであることができ,パケットが受信された入口ポートに従って判定され得る。 【0107】 620で,受信されたパケットがサービスセットに関連付けられる。パケットをサービスセットに関連付けることは,パケットの少なくとも1つのヘッダフィールドに従って,パケットに適用されるべきサービスの順序付きリストを割り当てることを含み得る。少なくとも1つのヘッダフィールドは,送信元アドレス,宛て先アドレス,送信元ポート,宛て先ポート又はプロトコルを含む群から選択され得る。サービスセットも,判定されたパケットが向かう方向に従って割り当てられ得る。割り当てられたサービスの順序付きリストは,メタデータとして受信されたパケットに添付され得る。) 第5.本願発明と引用発明との対比及び相違点についての判断 1.本願発明1について (1)本願発明1と引用発明との対比 本願発明1と,引用発明とを対比すると,本願発明1と,引用発明との,一致点,及び,相違点は,以下のとおりである。 [一致点] SDNネットワークに対するポリシおよび課金制御の方法であって, PCRFが,条件を決定し, 条件実現部が,前記条件に従って,所定の機能を実行する,方法。 [相違点1] “ポリシおよび課金制御の方法”に関して, 本願発明1においては,「SDNネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法」であるのに対して, 引用発明においては,「アプリケーションサービスチェインに対するポリシおよび課金制御」に関する言及がない点。 [相違点2] “条件を決定し”に関して, 本願発明1においては,「PCRFが,アプリケーションに対応する多次元コンテキスト情報に基づき,アプリケーションに関するアプリケーションサービスチェインを決定」するものであるのに対して, 引用発明においては,「ネットワークセッションまたはユーザに適用すべきポリシーを決定」するものである点。 [相違点3] 本願発明1においては,「対応するアプリケーションサービスチェイン情報を,SDNコントローラに送信するステップであって,アプリケーションサービスチェインがサービス機能の順序付きリストである,ステップ」を有するものであるのに対して, 引用発明においては,そのような「ステップ」についての言及がない点。 [相違点4] 本願発明1においては,「SDNコントローラが,アプリケーションサービスチェイン情報に基づき,アプリケーションに関する転送ルールを決定し,転送ルールを対応するサービスチェイニングインフラネットワークに送信するステップ」を有するものであるのに対して, 引用発明においては,そのような「ステップ」についての言及がない点。 [相違点5] “条件実現部が,前記条件に従って,所定の機能を実行する”点に関して, 本願発明1においては,「サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント(SCEP)が,転送ルールに基づき,対応するサービス機能を実行する」ものであるのに対して, 引用発明においては,「SCEP」についての言及がない点。 (2)相違点についての当審の判断 事案に鑑みて,上記[相違点2]について先に検討すると,[相違点2]に係る本願発明1の構成は,上記引用文献1?上記引用文献4には記載されておらず,本願の第1国出願前において周知技術であるともいえない。 したがって,本願発明1は,他の相違点を検討するまでもなく,当業者であっても引用発明,引用文献2?引用文献4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 2.本願発明2?本願発明5について 本願の請求項2?本願の請求項5は,直接・間接に本願の請求項1を引用するものであるから,上記「第5.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」における「(2)相違点についての当審の判断」において検討した[相違点2]の構成を内包している。 したがって,本願発明2?本願発明5は,上記「第5.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」における「(2)相違点についての当審の判断」において検討したとおり,当業者であっても引用発明,引用文献2?引用文献4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 3.本願発明6?本願発明11について 本願発明6,本願発明8,及び,本願発明9は,上記「第5.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」における「(2)相違点についての当審の判断」において検討した[相違点2]の構成を内包し, 本願の請求項7は,本願の請求項6を引用し,本願の請求項10,及び,本願の請求項11は,本願の請求項9を引用しているので,本願発明7,本願発明10,及び,本願発明11は,本願発明6,本願発明8,及び,本願発明9と同じく,前記[相違点2]]の構成を内包している。 したがって,本願発明6?本願発明11は,上記「第5.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」における「(2)相違点についての当審の判断」において検討したとおり,当業者であっても引用発明,引用文献2?引用文献4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 4.本願発明12?本願発明14について (1)本願発明12と引用発明との対比 本願発明12は,上記「第5.本願発明と引用発明との対比及び相違点についての判断」の「1.本願発明1について」における「(1)本願発明1と引用発明との対比」において指摘した,[相違点5]における「サービスチェイニングインフラネットワーク内のサービスチェイニング実施ポイント(SCEP)」に関する構成を有するものである。 (2)相違点についての当審の判断 「SCEP」については,上記引用文献1?上記引用文献4には記載されておらず,本願の第1国出願前において周知技術であるともいえない。 したがって,本願発明12は,当業者であっても引用発明,引用文献2?引用文献4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 (3)本願発明13,及び,本願発明14について 本願の請求項13,及び,本願の請求項14は,本願の請求項12を直接・間接に引用するものであるから,上記(2)において検討した,「SCEP」に関する構成を内包している。 したがって,上記(2)において検討したとおり,本願発明13,及び,本願発明14は,当業者であっても引用発明,引用文献2?引用文献4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 第6.原審拒絶査定についての判断 本願発明1?本願発明11は,上記検討の[相違点2]に係る構成を有しており,また,本願発明12?本願発明14は,上記「4.本願発明12?本願発明14について」の「(2)相違点についての当審の判断」において検討した[相違点5]に係る構成を有するものであるから,当業者であっても,拒絶査定において引用された引用文献1?引用文献4に基づいて,容易に発明できたものとはいえない。したがって,原査定の理由を維持することはできない。 第7.むすび 以上のとおり,原審拒絶査定の理由によっては,本願を拒絶することはできない。 また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
| 審決日 | 2020-03-03 |
| 出願番号 | 特願2016-575831(P2016-575831) |
| 審決分類 |
P
1
8・
121-
WY
(H04L)
|
| 最終処分 | 成立 |
| 前審関与審査官 | 野元 久道 |
| 特許庁審判長 |
仲間 晃 |
| 特許庁審判官 |
石井 茂和 松平 英 |
| 発明の名称 | SDNネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法および装置 |
| 代理人 | 特許業務法人川口國際特許事務所 |