ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04W 審判 査定不服 1項3号刊行物記載 特許、登録しない(前置又は当審拒絶理由) H04W |
|---|---|
| 管理番号 | 1349963 |
| 審判番号 | 不服2017-5641 |
| 総通号数 | 233 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2019-05-31 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2017-04-19 |
| 確定日 | 2019-03-11 |
| 事件の表示 | 特願2015-540987「パケットに関する情報を取得するための方法およびネットワーク要素」拒絶査定不服審判事件〔平成26年 5月22日国際公開、WO2014/075214、平成28年 2月 4日国内公表、特表2016-503610〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、2012年(平成24年)11月13日を国際出願日とする特許出願であり、その手続の経緯は、概略、以下のとおりである。 平成28年6月2日付け : 拒絶理由通知書 平成28年9月6日 : 意見書、手続補正書の提出 平成28年12月15日付け: 拒絶査定 平成29年4月19日 : 拒絶査定不服審判の請求 平成30年6月11日付け : 拒絶理由通知書(当審) 平成30年9月10日 : 意見書、手続補正書の提出 第2 本願発明 本願の請求項に係る発明は、平成30年9月10日に提出された手続補正書により補正された特許請求の範囲の請求項1?13に記載された事項により特定され、その請求項1には以下の発明(以下、「本願発明」という)が記載されていると認める。 「 ユーザー装置UEがベアラーを確立した後に、第1の取得要求を第2のネットワーク要素に送信するように構成された送信機であって、前記第1の取得要求が、前記第2のネットワーク要素に、前記UEとパケット・データ・ネットワークPDNとの間で送信され、前記第2のネットワーク要素を通過するパケットに関する情報を取得することを指令するために使用される、送信機と、 前記送信機が前記第1の取得要求を送信した後に、パケットに関する情報を受信するように構成された受信機であって、前記パケットに関する前記情報が、前記第2のネットワーク要素によって送信され、前記パケットに関する前記情報が、前記第1の取得要求に従って前記第2のネットワーク要素によって収集される、受信機とを備え、 前記送信機は、フィルタリング条件を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記フィルタリング条件に従って、取得することを指令するために使用されるか、 または 指示情報を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記指示情報に従って、取得することを指令するために使用されるネットワーク要素。」 第3 拒絶の理由 平成30年6月11日付けの当審が通知した拒絶理由(以下、「当審拒絶理由」という。)のうちの理由4及び5は、 「4.(新規性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。 5.(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。」であるところ、請求項1に対して下記引用例が引用されている。 4.3GPP TS29.212V11.6.0(2012-09)、15、39?42ページ、2012年9月21日アップロード、http://www.3gpp.org/ftp/Specs/archive/29_series/29.212/29212-b60.zip 第4 引用例の記載及び引用発明 1 引用例の記載 当審拒絶理由で引用した3GPP TS29.212V11.6.0(2012-09)(以下「引用例」という。)には、以下の事項が記載されている。(下線は、当審で付した。) (1) 「3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions givien in 3GPP TR21.905[1] and the following apply: IP-CAN bearer: IP transmission path of defined capacity, delay and bit error rate, etc. See 3GPP TS 21.905[1] for the definition of bearer. IP-CAN session: association between a UE and an IP network. The association is identified by one or more UE IPv4 addresses/ and/or IPv6 prefix together with a UE identity information, if available, and a PDN represented by a PDN ID(e.g. an APN). An IP-CAN session incorporates one or more IP-CAN bearers. Support for multiple IP-CAN bearers per IP-CAN session is IP-CAN specific. An IP-CAN session exists as long as the related UE IPv4 address and/or IPv6 prefix are assigned and announced to the IP network. (中略) Monitoring Key: Identifies a usage monitoring control instance. (中略) Usage monitoring control instance: the monitoring and reporting of the usage threshold for input, output or total data volume for the IP-CAN session/TDF session or the service data flows/application's traffic associated with the same monitoring key.」(15ページ1?24行) (当審訳:3 定義及び略語 3.1 定義 本文献の目的のために、3GPP TR21.905[1]で与えられる用語及び定義と、以下の事項が適用される。 IP-CANベアラ: 定義された容量、遅延、ビットエラーレートなどのIP伝送経路。ベアラの定義については、3GPP TS21.905[1]を参照。 IP-CANセッション:UEとIPネットワークとの間の接続。 接続は、1つ又は複数のUEのIPｖ4アドレス/ 及び/又は、利用可能であればUE識別情報が加わったIPｖ6プレフィックス、とPDN ID(例えばAPN)によって表されるPDNとにより識別される。1つのIP-CANセッションは、1つ又は複数のIP-CANベアラを構成要素とする。IP-CANセッションごとの複数IP-CANベアラのサポートは、IP-CAN固有である。関連するUE IPｖ4アドレス及び/又はIPｖ6プレフィックスが割り当てられ、IPネットワークにアナウンスされる限り、IP-CANセッションは存続する。 (中略) 監視キー: 使用状況監視制御インスタンスを識別する。 (中略) 使用状況監視制御インスタンス: IP-CANセッション/TDFセッションに対する、入力、出力、又は合計データ量の使用状況しきい値、又は、同じ監視キーに関連付けられたサービスデータフロー/アプリケーションのトラフィックの監視と報告。) (2) 「4.5.16 Requesting Usage Monitoring Control The PCRF may indicate, via the Gx reference point, the need to apply monitoring control for the accumulated usage of network resources on an IP-CAN session basis. Usage is defined as volume of user plane traffic. The data collection for usage monitoring control shall be performed per monitoring key, which may apply for a single Service Data Flow, a set of Service Data Flows or for all the traffic in an IP-CAN session.」(39ページ42?46行) (当審訳:4.5.16使用状況監視制御要求 PCRFは、Gｘ基準点を介して、IP-CANセッションベースでネットワークリソースの蓄積された使用状況のための監視制御を適用する必要性を示すことができる。使用状況は、ユーザプレーントラフィックの量として定義される。使用状況監視制御のためのデータ収集は、単一のサービスデータフロー、サービスデータフローの集合、又はIP-CANセッション内の全てのトラフィックに対して適用される監視キーごとに実行される。 ) (3) 「4.5.17 Reporting Accumulated Usage When usage monitoring is enabled, the PCEF shall measure the volume of the IP-CAN session or the volume of the applicable service data flows and report accumulated usage to the PCRF in the following conditions: (中略) - when requested by PCRF; To report accumulated usage for a specific monitoring key the PCEF shall send a CC-Request with the Usage-Monitoring-Information AVP including the accumulated usage since the last report. For each of the enabled monitoring keys to be reported, the Usage-Monitoring-Information AVP shall include the monitoring key in the Monitoring-Key AVP and the accumulated volume usage in the Used-Service-Unit AVP. Accumulated volume reporting shall be done for the total volume, the uplink volume or the downlink volume as requested by the PCRF, and set in CC-Total-Octets, CC-Input-Octets or CC-Output-Octets AVPs of Used-Service-Unit AVP respectively. The PCEF shall continue to perform volume measurement after the report until instructed by the PCRF to stop the monitoring.」(41ページ8?23行) (当審訳:4.5.17 蓄積された使用状況の報告 使用状況監視が有効である場合、PCEFは、IP-CANセッションの量、又は適切なサービスデータフローの量を測定し、以下の条件に従って、蓄積された使用状況をPCRFに報告する。 (中略) - PCRFにより要求された場合。 特定の監視キーのための蓄積された使用状況を報告するために、PCEFは、最後の報告以来蓄積された使用状況を含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPと共にCC要求を送信する。それぞれの有効化された監視キーが報告されるために、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPは、Mｏniｔｏｒing-Keｙ AVPの中の監視キー、及び、Uｓed-Seｒｖice-Uniｔ AVPの中の累積されたボリューム使用状況を含む。累積されたボリューム報告は、PCRFによって要求された、総ボリューム、アップリンクボリューム、又はダウンリンクボリュームに対して行われ、Uｓed-Seｒｖice-Uniｔ AVPのCC-Tｏｔal-Ocｔeｔｓ、CC-Inｐｕｔ-Ocｔeｔｓ、又はCC-Oｕｔｐｕｔ-Ocｔeｔｓ AVPｓにそれぞれ設定される。PCEFは、監視を停止するようにPCRFにより指示されるまで、報告後にボリューム測定を継続する。) (4) 「4.5.17.5 PCRF Requested Usage Report When the PCEF receives the Usage-Monitoring-Information AVP including the Usage-Monitoring-Report AVP set to the value USAGE_MONITORING_REPORT_REQUIRED, the PCEF shall send a new CCR command with CC-Request Type AVP set to the value "UPDATE_REQUEST" and the Event-Trigger AVP set to "USAGE_REPORT" to report accumulated usage for the monitoring key received in the Usage-Monitoring-Information AVP using the procedures to report accumulated usage defined in clause 4.5.17. If the Monitoring-Key AVP was omitted in the received Usage-Monitoring-Information AVP, the PCEF shall send the accumulated usage for all the monitoring keys that were enabled at the time the Usage-Monitoring-Information was received.」(42ページ29?36行) (当審訳:4.5.17.5 PCRFにより要求された使用状況報告 PCEFは、USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを受信すると、 PCEFは、4.5.17節で定義された蓄積された使用状況報告する手順を使用して、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況を報告するために、CC-Reｑｕeｓｔ Tｙｐe AVPを”UPDATE_REQUEST”との値に設定し、Eｖenｔ-Tｒiggeｒ AVPを”USAGE_REPORT”に設定した新しいCCRコマンドを送信する。受信したUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPにおいてMｏniｔｏｒing-Keｙ AVPが省略された場合、PCEFは、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏnが受信された時点で有効化された全ての監視キーに対して蓄積された使用状況を送信する。) 2 引用発明 (1) 上記1(3)によれば、引用例には、「PCRFにより要求された場合」との条件に従って、PCEFは、IP-CANセッションの量を測定し、蓄積された使用状況をPCRFに報告する「4.5.17 蓄積された使用状況の報告」の手順が記載されている。 また、上記1(4)によれば、引用例には、PCEFは、USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを受信すると、PCEFは、4.5.17節で定義された蓄積された使用状況報告する手順を使用して、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況を報告する「PCRFにより要求された使用状況報告」の手順が記載されている。 引用例に記載された上記「PCRFにより要求された使用状況報告」の手順、及び上記「4.5.17 蓄積された使用状況の報告」の手順は、PCEFが蓄積された使用状況の報告の要求をPCRFから受信し、蓄積された使用状況の報告をPCRFへ送信する手順であるが、引用例には、PCRFがPCEFに蓄積された使用状況の報告を要求し、蓄積された使用状況の報告をPCEFから受信する手順として、 PCRFが、USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを送信し、当該Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを送信した後、PCEFによって送信され、PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告を受信する事項が、記載されているのも同然といえる。 また、引用例に記載された、PCRFが、上記Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPをPCEFに送信するように構成された送信機と、蓄積された使用状況の報告を受信するように構成された受信機とを備えることは明らかな事項といえる。 してみると、引用例には、 「 USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPをPCEFに送信するように構成された送信機と、 Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを送信した後、PCEFによって送信され、PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告を受信するように構成された受信機と、を備えるPCRF。」が記載されているといえる。 (2) 上記1(1)の記載によると引用例において、「IP-CANセッション」は、UEのIPｖ4アドレスと、PDN ID(例えばAPN)によって表されるPDNとにより識別され、1つ又は複数のIP-CANベアラを構成要素とする、UEとIPネットワークとの接続と定義されている。 (3) 上記1(1)の記載によれば、引用例において、監視キーは、使用状況監視制御インスタンスを識別するための情報と定義されている。 (4) 上記1(2)の記載によれば、引用例において、使用状況監視制御のためのデータ収集は、IP-CANセッション内の全てのトラフィックに対して適用される監視キーごとに実行されるといえる。 以上を踏まえると、引用例には、以下の発明(以下、「引用発明」という。)が記載されていると認める。 「 USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPをPCEFに送信するように構成された送信機と、 Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを送信した後、PCEFによって送信され、PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告を受信するように構成された受信機と、を備えるPCRFであって、 前記IP-CANセッションは、UEのIPｖ4アドレスと、PDN ID(例えばAPN)によって表されるPDNとにより識別され、1つ又は複数のIP-CANベアラを構成要素とする、UEとIPネットワークとの接続と定義され、 監視キーは、使用状況監視制御インスタンスを識別するための情報と定義され、 使用状況監視制御のためのデータ収集は、IP-CANセッション内の全てのトラフィックに対して適用される監視キーごとに実行される、 PCRF。」 第5 対比 本願発明と引用発明とを対比すると、以下のとおりとなる。 1 引用発明のネットワーク要素といえるPCRFが備える送信機について対比する。PCEFは、ネットワーク要素といえる上記PCRFとは異なるネットワーク要素であるから、引用発明のPCEFは第2のネットワーク要素といえる。 (1) 引用発明の「IP-CANセッション」は、UEのIPｖ4アドレスと、PDN ID(例えばAPN)によって表されるPDNとにより識別され、1つ又は複数のIP-CANベアラを構成要素とする、UEとIPネットワークとの接続と定義され、また、パケット・データ・ネットワークを意味するPDNとの通信がパケットにより行われることは明らかであるから、PCEFによって測定される引用発明の「IP-CANセッションの量」は、「UEとパケット・データ・ネットワークPDNとの間で送信され」る「パケットに関する情報」といえる。 また、引用発明の、PCEFによるIP-CANセッションの量の測定が、第2のネットワーク要素といえるPCEFを通過するパケットについて行われることも明らかな事項である。 してみると、引用発明の「PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告」は、本願発明の「前記UEとパケット・データ・ネットワークPDNとの間で送信され、前記第2のネットワーク要素を通過するパケットに関する情報」に相当する。 (2) 「USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」をPCEFに送信し、「PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告」をPCEFから受信する引用発明の「USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」は、PCEFに、蓄積された使用状況の報告を取得することを指令する要求といえるから、本願発明の「前記第2のネットワーク要素に、前記UEとパケット・データ・ネットワークPDNとの間で送信され、前記第2のネットワーク要素を通過するパケットに関する情報を取得することを指令するために使用される」「第1の取得要求」に相当する。 (3) 引用発明の「蓄積された使用状況の報告」は、IP-CANベアラを構成要素とするIP-CANセッションの量を測定するものであるから、「蓄積された使用状況の報告」を要求する「Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」の送信が、UEがIP-CANベアラを確立した後に行われることは明らかな事項といえる。 (4) 上記(1)?(3)を踏まえると、引用発明のPCRFが備える「USAGE_MONITORING_REPORT_REQUIREDとの値に設定されたUｓage-Mｏniｔｏｒing-Reｐｏｒｔ AVPを含むUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPをPCEFに送信するように構成された送信機」は、本願発明のネットワーク要素が備える「ユーザー装置UEがベアラーを確立した後に、第1の取得要求を第2のネットワーク要素に送信するように構成された送信機であって、前記第1の取得要求が、前記第2のネットワーク要素に、前記UEとパケット・データ・ネットワークPDNとの間で送信され、前記第2のネットワーク要素を通過するパケットに関する情報を取得することを指令するために使用される、送信機」に相当する。 2 「使用状況監視制御のためのデータ収集は、IP-CANセッション内の全てのトラフィックに対して適用される監視キーごとに実行される」引用発明の「PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告」は、第1の取得要求に相当する「Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」中で受信した監視キーに従ってPCEFによって収集される、すなわち「前記第1の取得要求に従って前記第2のネットワーク要素によって収集される」パケットに関する情報といえる。 また、引用発明の「蓄積された使用状況の報告」は、PCEFにより送信される、すなわち「前記第2のネットワーク要素によって送信され」るパケットに関する情報といえる。 してみると、引用発明のPCRFが備える「Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVPを送信した後、PCEFによって送信され、PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告を受信するように構成された受信機」は、本願発明のネットワーク要素が備える「前記送信機が前記第1の取得要求を送信した後に、パケットに関する情報を受信するように構成された受信機であって、前記パケットに関する前記情報が、前記第2のネットワーク要素によって送信され、前記パケットに関する前記情報が、前記第1の取得要求に従って前記第2のネットワーク要素によって収集される、受信機」に相当する。 3 「監視キーは、使用状況監視制御インスタンスを識別するための情報と定義され、使用状況監視制御のためのデータ収集は、IP-CANセッション内の全てのトラフィックに対して適用される監視キーごとに実行される」引用発明のUｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信する「監視キー」は、取得する「蓄積された使用状況」を特定する指示情報といえるから、本願発明の「前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記指示情報に従って、取得することを指令するために使用される」「指示情報」に相当し、また、第1の取得要求が備える「指示情報」に相当する。 してみると、引用発明は、送信機が送信する第1の取得要求がフィルタリング条件を備える点が特定されていないものの、引用発明の備える送信機は、 「指示情報を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記指示情報に従って、取得することを指令するために使用される」点で本願発明と共通する。 以上を踏まえると、本願発明と引用発明とは以下の点で一致し、相違する。 「ユーザー装置UEがベアラーを確立した後に、第1の取得要求を第2のネットワーク要素に送信するように構成された送信機であって、前記第1の取得要求が、前記第2のネットワーク要素に、前記UEとパケット・データ・ネットワークPDNとの間で送信され、前記第2のネットワーク要素を通過するパケットに関する情報を取得することを指令するために使用される、送信機と、 前記送信機が前記第1の取得要求を送信した後に、パケットに関する情報を受信するように構成された受信機であって、前記パケットに関する前記情報が、前記第2のネットワーク要素によって送信され、前記パケットに関する前記情報が、前記第1の取得要求に従って前記第2のネットワーク要素によって収集される、受信機とを備え、 前記送信機は、指示情報を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記指示情報に従って、取得することを指令するために使用されるネットワーク要素。」 相違点 一致点とした「送信機」に関し、本願発明は、「前記送信機は、フィルタリング条件を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記フィルタリング条件に従って、取得することを指令するために使用されるか、 または 指示情報を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記指示情報に従って、取得することを指令するために使用される」のに対し、 引用発明は、送信機は、第1の取得要求が上記「指示情報を備える」場合に相当する、「監視キー」を含む「Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」をPCEFに送信するように構成され、「Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP」は、PCEFに、「PCEFによってIP-CANセッションの量を測定した、Uｓage-Mｏniｔｏｒing-Infｏｒmaｔiｏn AVP中で受信した監視キーに対する蓄積された使用状況の報告」を取得することを指令するために使用される点。 第6 判断 本願発明が備える送信機が送信する第1の取得要求が備える「フィルタリング条件」及び「指示情報」は、「または」で接続された択一的な発明特定事項であり、本願発明は、送信機は、「フィルタリング条件を備える前記第1の取得要求を前記第2のネットワーク要素に送信するように構成され、前記第1の取得要求は、前記第2のネットワーク要素に、前記UEと前記PDNとの間で送信され、前記第2のネットワーク要素を通過する前記パケットに関する前記情報を、前記フィルタリング条件に従って、取得することを指令するために使用される」との事項を含まないものを包含するから、上記相違点は実質的な相違とはいえない。 したがって、本願発明は引用発明であり、また、引用発明に基づいて当業者が容易に発明をすることができたものといえる。 第7 むすび 以上のとおり、本願発明は、その出願前に日本国内又は外国において、頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。 また、本願発明は、その出願前に日本国内又は外国において、頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく拒絶すべきものである。 |
| 別掲 |
|
| 審理終結日 | 2018-10-12 |
| 結審通知日 | 2018-10-16 |
| 審決日 | 2018-10-30 |
| 出願番号 | 特願2015-540987(P2015-540987) |
| 審決分類 |
P
1
8・
121-
WZ
(H04W)
P 1 8・ 113- WZ (H04W) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 松野 吉宏 |
| 特許庁審判長 |
菅原 道晴 |
| 特許庁審判官 |
羽岡 さやか 松永 稔 |
| 発明の名称 | パケットに関する情報を取得するための方法およびネットワーク要素 |
| 代理人 | 吉元 弘 |
| 代理人 | 朝倉 悟 |
| 代理人 | 佐藤 泰和 |
| 代理人 | 中村 行孝 |
| 代理人 | 永井 浩之 |