• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04M
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 H04M
管理番号 1308011
審判番号 不服2014-12310  
総通号数 193 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-01-29 
種別 拒絶査定不服の審決 
審判請求日 2014-06-26 
確定日 2015-11-24 
事件の表示 特願2011-533546「ポリシー及び課金制御方法、サーバ、及びコンピュータプログラム」拒絶査定不服審判事件〔平成22年 5月 6日国際公開、WO2010/049002、平成24年 3月22日国内公表、特表2012-507223〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は,2008年10月31日を国際出願日とする出願であって,平成26年2月28日付けで拒絶査定がなされ,これに対し,同年6月26日に拒絶査定に対する審判請求がなされるとともに,同日付で手続補正書が提出され,同年10月7日付けで上申書が提出されたものである。



第2 補正却下の決定
[補正却下の決定の結論]
平成26年6月26日付けの手続補正を却下する。

[理由]
1.本願発明と補正後の発明
平成26年6月26日付け手続補正(以下,「本件補正」という。)は,平成25年9月3日付け手続補正書の特許請求の範囲の請求項8に記載された,

「 【請求項8】
ポリシー及び課金ルール機能(PCRF)を実現するように構成されているサーバ(100)であって,
ユーザ機器(UE)とアプリケーション機能(AF)との間でネゴシエートされたセッション情報に基づいて,第1のポリシー及び課金制御(PCC)ルール群を作成するように構成されている作成ユニット(102)と,
ポリシー及び課金施行機能(PCEF)を実現し,かつ前記第1のポリシー及び課金制御(PCC)ルール群に従って前記ユーザ機器(UE)と関連付けられたサービスとして複数のメディアが介在するサービスを開始するように構成されているサーバ(200)における前記第1のポリシー及び課金制御(PCC)ルール群のインストールを,前記ユーザ機器(UE)と関連付けられたユーザプレーンセッションの確立時に,トリガーするように構成されているトリガーユニット(104)と,
前記ユーザプレーンセッションの有効期間内に,前記ユーザ機器(UE)から発信されるサービス品質(QｏS)変更リクエストとして前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストを受信するように構成されている受信ユニット(106)とを有し,
前記作成ユニット(102)は,更に,前記ユーザプレーンセッションの有効期間内に,メディア毎の前記サービス品質(QｏS)変更リクエストに基づいて,第2のポリシー及び課金制御(PCC)ルール群を作成するように構成され,
前記トリガーユニット(104)は,更に,前記ポリシー及び課金施行機能(PCEF)を実現するように構成されている前記サーバ(200)が,前記第2のポリシー及び課金制御(PCC)ルール群に従って,前記ユーザ機器(UE)と関連付けられたサービスを継続できるように,前記第2のポリシー及び課金制御(PCC)ルール群で前記第1のポリシー及び課金制御(PCC)ルール群を置換することによって,前記ポリシー及び課金施行機能(PCEF)を実現するように構成されている前記サーバ(200)において,前記第2のポリシー及び課金制御(PCC)ルール群のインストールを,前記ユーザプレーンセッションの有効期間内に,トリガーするように構成されている
ことを特徴とするサーバ(100)。」

という発明(以下,「本願発明」という。)を,本件補正の手続補正書の特許請求の範囲の請求項8に記載された,

「 【請求項8】
ポリシー及び課金ルール機能(PCRF)を実現するように構成されているサーバ(100)であって,
ユーザ機器(UE)とアプリケーション機能(AF)との間でネゴシエートされたセッション情報に基づいて,第1のポリシー及び課金制御(PCC)ルール群を作成するように構成されている作成ユニット(102)と,
ポリシー及び課金施行機能(PCEF)を実現し,かつ前記第1のポリシー及び課金制御(PCC)ルール群に従って前記ユーザ機器(UE)と関連付けられたサービスとして複数のメディアが介在するサービスを開始するように構成されているサーバ(200)における前記第1のポリシー及び課金制御(PCC)ルール群のインストールを,前記ユーザ機器(UE)と関連付けられたユーザプレーンセッションの確立時に,トリガーするように構成されているトリガーユニット(104)と,
前記ユーザプレーンセッションの有効期間内に,前記ユーザ機器(UE)から発信されるサービス品質(QｏS)変更リクエストとして前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストを受信するように構成されている受信ユニット(106)と,
アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて,前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット(108)と,を有し,
前記作成ユニット(102)は,更に,前記ユーザプレーンセッションの有効期間内に,メディア毎の前記サービス品質(QｏS)変更リクエストに基づいて,第2のポリシー及び課金制御(PCC)ルール群を作成するように構成され,
前記トリガーユニット(104)は,更に,前記ポリシー及び課金施行機能(PCEF)を実現するように構成されている前記サーバ(200)が,前記第2のポリシー及び課金制御(PCC)ルール群に従って,前記ユーザ機器(UE)と関連付けられたサービスを継続できるように,前記第2のポリシー及び課金制御(PCC)ルール群で前記第1のポリシー及び課金制御(PCC)ルール群を置換することによって,前記ポリシー及び課金施行機能(PCEF)を実現するように構成されている前記サーバ(200)において,前記第2のポリシー及び課金制御(PCC)ルール群のインストールを,前記ユーザプレーンセッションの有効期間内に,トリガーするように構成されている
ことを特徴とするサーバ(100)。」(下線は,請求人が手続補正書において補正箇所を示すものとして付加したものを援用したものである。)

という発明(以下,「補正後の発明」という。)に補正することを含むものである。


2.補正の適否
(1)新規事項・シフト補正の有無について
上記補正の内容は,「サーバ(100)」の構成要素として「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて,前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット(108)」を付加するものである。
そうしてみると,上記補正は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてなされた補正であり,特許法第17条の2第3項(新規事項)の規定に適合し,また,同法第17条の2第4項(シフト補正)の規定に適合することも明らかである。

(2)補正の目的について
上記補正は,上記(1)で検討したように,本件「サーバ(100)」の構成要素として新たに「決定ユニット(108)」を付加するものであるから,構成の外的付加に相当し,本件補正前の請求項8の構成の一部を限定的に減縮しているものということはできないし,また,請求項の削除,誤記の訂正,及び明りょうでない記載の釈明のいずれにも該当しないことは明らかである。
したがって,上記補正は,特許法第17条の2第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

(3)独立特許要件について
前記「(2)補正の目的について」において判断したように,上記補正はいわゆる目的外の補正を含むものであり,特許法の規定に違反するものであるが,仮に上記補正が,請求人が審判請求書において主張するように,特許請求の範囲の減縮を目的とするものであり適法な補正であるとした場合についても検討する。
上記補正が,特許請求の範囲の減縮を目的とするものとして,補正後の発明が特許出願の際に独立して特許を受けることができるものであるのかどうかについて,以下に検討する。

[補正後の発明]
上記「1.本願発明と補正後の発明」の項において,「補正後の発明」として認定したとおりである。

[引用発明]
原査定の拒絶理由に引用された文献であり,本願出願日前に公開された,3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architectures (Release 8),3GPP TS 23.203 [ONLINE],2008年3月,V8.1.1,P.23-32, P.45-48,URL,http://www.3gpp.org/ftp/Specs/2008-03/Rel-8/23_series/23203-811.zip(URLはhttp://www.qtc.jp/3GPP/Specs/23203-811.pdfに変更されている。以下,「引用例1」という。)には,図面とともに以下の事項が記載されている。

イ.「6.2 Functional entities
6.2.1 Policy Control and Charging Rules Function (PCRF)
The PCRF encompasses policy control decision and flow based charging control functionalities.
・・・・・・・・・
The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF.
・・・・・・・・・・・
The PCRF shall decide how a certain service data flow shall be treated in the PCEF, and ensure that the PCEF user plane traffic mapping and treatment is in accordance with the user's subscription profile.
If Gxx applies, the PCRF shall provide QoS rules with identical service data flow templates as provided to the PCEF in the PCC rules.
・・・・・・・・・
The PCRF may check that the service information provided by the AF is consistent with both the operator defined policy rules and the related subscription information as received from the SPR during IP-CAN session establishment before storing the service information. The service information shall be used to derive the QoS for the service.
・・・・・・・・・
The PCRF authorizes QoS resources. The PCRF uses the service information received from the AF (e.g. SDP information or other available application information) and/or the subscription information received from the SPR to calculate the proper QoS authorization (QoS class identifier, bitrates). The PCRF may also take into account the requested QoS received from the PCEF via Gx interface.」(23?24頁)
(当審仮訳:
6.2 機能エンティティ
6.2.1 ポリシー制御及び課金ルール機能(PCRF)
PCRFは,ポリシー制御決定と,フローベースの課金制御機能を含みます。
・・・・・・・・・
PCRFは、PCEFに向けた,サービス・データ・フロー検出、ゲーティング,QoS,及びフローベース課金(与信管理を除く)に関するネットワーク制御を提供します。
・・・・・・・・・
PCRFは,あるサービス・データ・フローがPCEFにおいて,どのように処理されるかを決定し,そして,PCEFユーザプレーントラフィックのマッピング及び処理が,ユーザの加入プロファイルに従っていることを確保しなければなりません。
Gxxが適用される場合,PCCルールによりPCEFに提供されるように,PCRFは,同一のサービス・データ・フロー・テンプレートを使用したQoSルールを提供しなければなりません。・・・・・・・・・
・・・・・・・・・
PCRFは,AFによって提供されるサービス情報が,オペレータが定義したポリシールール,及び,サービス情報を格納する前の,IP-CANセッション確立中にSPRから受信した関連する加入情報の両方と一致していることを確認することができます。サービス情報は,サービスのためのQoSを得るために使用されなければなりません。・・・・・・・・・
・・・・・・・・・
PCRFは,QoSリソースを許可します。 PCRFは,AFから受信したサービス情報(例えば,SDP情報又は他の利用可能なアプリケーションの情報),及び/または,適切なQoSの許可(QoSクラス識別子,ビットレート)を計算するためにSPRから受信した加入情報を使用します。 PCRFは,Gxインタフェースを介してPCEFから受信した要求されたQoSを考慮するかもしれません。)

ロ.「6.2.1.1 Input for PCC decisions
The PCRF shall accept input for PCC decision-making from the PCEF, SPR and if the AF is involved, from the AF, as well as the PCRF may use its own pre-defined information. These different nodes should provide as much information as possible to the PCRF.・・・・・
・・・・・・・・・
The AF, if involved, may provide the following application session related information, e.g. based on SIP and SDP:
- Subscriber Identifier;
- IP address of the UE;
- Media Type;
- Media Format, e.g. media format sub-field of the media announcement and all other parameter information (a=lines) associated with the media format;
- Bandwidth;
・・・・・・・・・
- AF Communication Service Identifier (e.g. IMS Communication Service Identifier), UE provided via AF;
- AF Application Event Identifier;
- AF Record Information;
- Flow status (for gating decision);
・・・・・・・・・
The QoS Class Identifier (see clause 6.3.1) in the PCC rule is derived by the PCRF from AF or SPR interaction if available. The input can be SDP information or other available application information, in line with operator policy.」(24?25頁)
(当審仮訳:
6.2.1.1 PCC決定のための入力
PCRFは,独自の事前定義された情報を使用することができるだけでなく,PCRFは,PCEF,SPR,そしてもしAFが関与している場合はAFから,PCC決定を行うために入力を受け入れるものとします。これらの異なるノードは,PCRFにできるだけ多くの情報を提供すべきです。・・・・・・・・・
・・・・・・・・・
AFは,もし関与しているなら,次のアプリケーションセッションに関連する,例えば,SIPとSDPに基づく情報を提供することができる:
- 加入者識別子。
- UEのIPアドレス。
- メディアタイプ。
- メディアフォーマット,例えば,メディアアナウンスメントのメディアフォーマットのサブフィールドと,メディアフォーマットに関連した他のすべてのパラメータ情報;
- 帯域幅;
・・・・・・・・・
- AF通信サービス識別子(例えばIMS通信サービス識別子),UEはAFを介して提供されます。
- AFアプリケーションイベント識別子。
- AFレコード情報。
- (意思決定のために)フローの状態。
・・・・・・・・・
PCCルールにおけるQoSクラス識別子(6.3.1節を参照)は,利用可能であれば,AFから,もしくはSPRを調べて,PCRFが取得します。入力は,オペレータポリシーに即して,SDP情報,またはその他の利用可能なアプリケーション情報とすることができます。)

ハ.「6.2.2 Policy and Charging Enforcement Function (PCEF)
6.2.2.1 General
The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities.
・・・・・・・・・
The PCEF is enforcing the Policy Control as indicated by the PCRF in two different ways:
・・・・・・・・・
- QoS enforcement:
・・・・・・・・・
- PCC rule QoS enforcement. The PCEF shall enforce the authorized QoS of a service data flow according to the active PCC rule (e.g. to enforce uplink DSCP marking).
・・・・・・・・・
The PCEF shall, on request from the PCRF, modify a PCC rule, using the equivalent PCEF behaviour as the removal of the old and the activation of the new (modified) PCC rule.
・・・・・・・・・
At IP-CAN session establishment the PCEF shall initiate the IP-CAN Session Establishment procedure, as defined in clause 7.2.・・・・
・・・・・・・・・
To support the different IP-CAN bearer establishment modes (UE-only, UE/NW or NW-only) the PCEF shall:
- forward the network capabilities and UE preferred bearer establishment mode to the PCRF;
- apply the IP-CAN bearer establishment mode for the IP-CAN session set by the PCRF.
During an IP-CAN session modification, the PCEF shall provide information (belonging to the IP-CAN bearer established or modified) to the PCRF as follows:
- in UE-only bearer establishment mode, the PCEF shall send the full QoS and traffic mapping information;
- in UE/NW bearer establishment mode, the PCEF shall:
- at UE-initiated bearer establishment, send the full QoS and traffic mapping information;
- at UE-initiated bearer modification, send information on the requested change to QoS bitrates and changes to the traffic mapping information;」(26?28頁)
(当審仮訳:
6.2.2 ポリシー及び課金施行機能(PCEF)
6.2.2.1 全般
PCEFは,サービス・データ・フロー検出,ポリシー施行,フローベースの課金機能を包含する。
・・・・・・・・・
以下の2つの異なる方法でPCRFによって示されるように,PCEFはポリシー制御を実施しています。
・・・・・・・・・
- QoSの施行:
・・・・・・・・・
- PCCルールのQoS施行。 PCEFは,アクティブなPCC規則に従って,サービスデータフローの許可されたQoSを実施しなければなりません。(例えば,アップリンクDSCPマーキングを施行することのように。)
・・・・・・・・・
PCEFは,PCRFからの要求に応じて,古いルールの除去と新しい(変更された)PCCルールの活性化と同様のPCEFの動作により,PCCルールを変更しなければなりません。
・・・・・・・・・
7.2で定義されているように、IP-CANセッション確立時PCEFが、IP-CANセッション確立手順を開始しなければなりません。・・・・・
・・・・・・・・・
異なるIP-CANベアラ確立モード(UE-のみ,UE/NWまたはNW-のみ)をサポートするために,PCEFは:
- ネットワーク能力と,UEの好むベアラの確立モードをPCRF転送します。
- PCRFにより設定されたIP-CANセッションのIP-CANベアラの確立モードを適用します。
IP-CANセッションの変更時には,PCEFが,情報を(確立される,または変更されるIP-CANベアラに属するものである)を以下のようにPCRFに提供しなければなりません。
- UE専用ベアラ確立モードでは,PCEFは完全なQoS及びトラフィックマッピング情報を送信しなければなりません。
- UE / NWベアラ確立モードでは, PCEFは:
- UE-開始ベアラ確立において,完全なQoSおよびトラフィックのマッピング情報を送信します。
- UE-開始ベアラ変更時に,要求されたQoSビットレートの変更とトラフィックのマッピング情報の変更情報を送信します。)

ニ.「6.2.2.4 QoS control
The PCEF enforces the authorized QoS for an IP-CAN bearer according to the information received via the Gx interface and depending on the bearer establishment mode.」(32頁)
(当審仮訳:
6.2.2.4 QoS制御
PCEFは,許可されたQoSをIP-CANベアラーのために,Gxインタフェースを介して受信した情報に従い,ベアラー確立モードに応じて実行します。)

ホ.「6.2.3 Application Function (AF)
The Application Function (AF) is an element offering applications that require dynamic policy and/or charging control over the IP-CAN user plane behaviour. The AF shall communicate with the PCRF to transfer dynamic session information, required for PCRF decisions as well as to receive IP-CAN specific information and notifications about IPCAN bearer level events. One example of an AF is the P-CSCF of the IM CN subsystem.
The AF may receive an indication that the service information is not accepted by the PCRF together with service information that the PCRF would accept. In that case, the AF rejects the service establishment towards the UE. If possible the AF forwards the service information to the UE that the PCRF would accept.」(32頁)
(当審仮訳:
6.2.3 アプリケーション機能(AF)
アプリケーション機能(AF)は,動的ポリシー及び/またはIP-CANユーザプレーンの動作における課金制御を要求するアプリケーションを提供する要素です。AFは,IP-CANベアラレベルのイベントに関するIP-CANの特定の情報や通知を受信するためだけでなく,PCRFの決定に必要な動的なセッション情報を転送するために,PCRFと通信しなければなりません。AFの一例は,IM CNサブシステムのP-CSCFです。
AFは,PCRFが受け入れるサービス情報に加えて,サービス情報がPCRFによって受け入れられないという指示を受信するかもしれません。その場合には,AFはUEに向けてサービスの確立を拒否します。可能な場合は,AFはPCRFが受け入れるサービス情報をUEに転送します。)

ヘ.「7.4 IP-CAN Session Modification
7.4.1 IP-CAN Session Modification; GW(PCEF) initiated
This sub-clause describes the signalling flow for the IP-CAN Session modification initiated by the GW(PCEF). ・・・・・・・・・
・・・・・・・・・
3. The GW(PCEF) makes an internal decision or receives a request for IP-CAN Bearer establishment, modification or termination.
4. The PCEF determines that the PCC interaction is required and sends the PCC Rules request to the PCRF. If there is a limitation or termination of the transmission resources for a PCC Rule, the PCEF reports this to the PCRF.
・・・・・・・・・
8. The PCRF makes the authorization and policy decision.
9. The PCRF sends the decision(s) to the PCEF. The GW(PCEF) enforces the decision.」(45?46頁)
(当審仮訳:
7.4 IP-CANセッション変更
7.4.1 IP-CANセッション変更。GW(PCEF)開始
このサブ条項は,GW(PCEF)によって開始されたIP-CANセッション変更のための信号の流れを説明します。・・・・・・・・・
・・・・・・・・・
3. GW(PCEF)は,内部決定を行うか,IP-CANベアラの確立,変更,または終了するための要求を受信します。
4. PCEFはPCCとの対話が必要であると判断し,PCRFにPCCルール要求を送信します。 PCCルールに対する送信リソースの制限または終了がある場合,PCEFは,PCRFにこれを報告します。
・・・・・・・・・
8. PCRFは,認可やポリシー決定を行います。
9. PCRFは,PCEFに決定(複数可)を送信します。 GW(PCEF)は,決定を実施します。)

ト.「7.4.2 IP-CAN Session Modification; PCRF initiated
This clause describes the signalling flow for the IP-CAN Session modification initiated by the PCRF. The AF may be involved. An example of the scenario is initiation and authorization of a session-based service for which an IP-CAN Session is modified. ・・・・・・・・・
・・・・・・・・・
3. The PCRF makes the authorization and policy decision.
4. The PCRF sends the decision(s) to the PCEF.
5. The PCEF enforces the decision.
・・・・・・・・・」(46?47頁)
(当審仮訳:
7.4.2 IP-CANセッション変更。PCRF開始
この条項は,PCRFによって開始されるIP-CANセッション変更のための信号の流れを説明します。 AFが関与し得ます。IP-CANセッションが変更されたセッションベースのサービスを開始するシナリオの例です。・・・・
・・・・・・・・・
3. PCRFは,認可やポリシー決定を行います。
4. PCRFは,PCEFに決定(複数可)を送信します。
5. PCEFは,その決定を実施します。
・・・・・・・・・)

上記摘記事項の記載及び図面並びにこの分野における技術常識を考慮すると,

a.上記摘記事項イ.?ト.によれば,引用例1に記載のものは,PCRF,PCEF,AF,及びUEの各機能を含んで構成されている。そしてPCRF及びPCEFをそれぞれ実現する具体的な構成が存在することは明らかである。

b.特に上記摘記事項イ.及びロ.によれば,PCRFがPCCルールを決定しており,上記摘記事項ホ.を参照すれば,そのためにAFからセッション情報が転送されてくるといえる。
またAFはUEに向けたサービスをするための構成であるから,PCRFにおいてPCCルールが決定されるより前に,AFとUEの間で,調整が行われ,その結果がAFからセッション情報としてPCRFに転送されると考えるのが自然である。
そして,引用例1に記載のものは,セッション情報に基づいてPCRFがPCCルールを決定しているから,PCRFは「PCCルールを生成する構成」を有しているといえる。(なお,3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architectures (Release 8),3GPP TS 23.203 [ONLINE],2008年3月,V8.1.1の77頁に「D.2.3.1 Overall description・・・・・・Based on session information provided by the AF via the Rxreference point, the PCRF determines the QoS requirements for each service by constructing PCC rules. The PCRF requests the WiMAX IP-CAN via Gx interface to enforce the authorized PCC rules on the WiMAX service flows. The PCEF function in the WiMAX IP-CAN enforces the PCC rules received from the PCRF.(仮訳:D.2.3.1全体の説明・・・・受信基準点を経由してAFが提供するセッション情報に基づき、PCRFはPCCルールを構築することによって、各サービスのQoS要件を決定します。 PCRFは、WiMAXサービスフローに認可されたPCC規則を施行するためにGxインタフェースを介して、WiMAXのIP-CANを要求します。 WiMAXのIP-CANにおけるPCEFは、PCRFから受信したPCC規則を施行します。)にも記載されている。)

c.上記摘記事項の特にハ.によれば,PCEFはポリシー施行,フローベースの課金機能を含み,PCCルールを実施するものである。そして,これらはUEへのサービスに関して行われることも明らかである。また,上記摘記事項イ.ニ.ヘ.ト.等も参照すれば,PCCルールはPCRFからPCEFに送られ,これによりPCEFが実行するものである。そうしてみると,PCEFはPCCルールに従って,UEに関連したサービスを開始するものということができる。また,PCRFがPCCルールをPCEFに転送することにより,PCEFではPCCルールが実施されるのであるから,このようなPCCルールの転送はセッションの確立時に行われると考えるのが自然である。
なお,この点に関し,上記摘記事項の特にハ.によれば7.2節にIP-CANセッション確立時のPCEFのIP-CANセッション確立手順を開始することについて定義されている旨記載があり,上記3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architectures (Release 8),3GPP TS 23.203 [ONLINE],2008年3月,V8.1.1の41頁の図7.2-1をみても(特にその手順6と7を参照),IP-CANセッションの確立時に行われることが明らかである。
さらに,当該PCCルールの転送により,PCEFはPCCルールを受信して保持するようになるのであるから,これをPCCルールのインストールをトリガーしているということもでき,そのための構成を有していることは明らかである。

d.上記摘記事項ヘ.及びト.によれば,セッションは変更することができ,ここで上記摘記事項ハ.などによれば,変更要求はUEによって開始されたものでも考慮されており,QｏSの変更を求めているものである。そして,上記摘記事項ヘ.ト.及び図7.4の記載から,PCRFは「新しいポリシー作成するために変更要求を受信する構成」を備えているということができる。

e.上記摘記事項ヘ.及びト.によれば,PCRFは新たなPCCルールを作成するが,これも,上記b.で言及した「PCCルールを作成する構成」が行うと考えるのが自然である。

f.上記摘記事項の特にハ.ト.ヘ.によれば,PCRFはPCRFが要求に応じて作成した新たなPCCルールをPCEFに転送することにより,PCEFは古いルールを除去して,変更したルールがPCEFにおいて実施されている。

したがって,摘記した引用例1の記載及び図面を総合すると,引用例1には以下のような発明(以下,「引用発明」という。)が記載されているものと認められる。

(引用発明)
「 PCRFを実現する構成であって,
UEとAFの間で,調整が行われ,その結果が前記AFからセッション情報としてPCRFに転送され,これに基づいて前記PCRFがPCCルールを作成する構成を有し,
前記PCEFが,前記PCCルールに従って前記UEに関連したサービスを開始するように,前記PCRFが前記PCEFに前記PCCルールの転送をセッションの確立時に行う構成と,
前記UEから発信されるQｏS変更要求を受信する構成と,
前記PCCルールを作成する構成は前記QｏS変更要求に基づいて新たなPCCルールを作成し,
前記PCEFが前記新たなPCCルールに従って,前記UEに関連したサービスを実施できるように,前記PCRFが前記新たなPCCルールをPCEFに転送すること,
を特徴とする構成。」


[技術事項]
また,原査定の拒絶理由に引用された文献であり,本願出願日前に公開された特開2007-189444号公報(以下,「引用例2」という。)には,図面とともに以下の事項が記載されている。

チ.「【0001】
この発明は,ネットワークに接続される通信機器の通信品質を利用者から受け付けた要求に応じて変更する通信品質変更システム,通信品質変更方法および通信品質変更プログラムに関する。」(3頁)

リ.「【0044】
また、変更要求受付部33aは、品質変更要求を受け付けた場合に、利用者認証を行う処理部でもある。具体的には、品質変更要求に含まれる電話番号(品質変更要求を送出した携帯電話装置10の電話番号)に基づいて利用者情報DB32a(図3参照)を参照し、かかる電話番号が利用者情報DB32aに記憶されているか否か、さらには、かかる電話番号に対応付けて記憶されているサービス契約内容が現に有効であるか否かを判定することで利用者を認証する。なお、電話番号が利用者情報DB32aに記憶されていない場合や、サービス契約内容が無効である場合には、品質変更要求を拒絶する。」

ヌ.「【0052】
この品質変更プログラム11は,通信品質変更サービスの利用に際して実行されるプログラムであり,かかるプログラムが組み込まれた携帯電話装置10は,例えば,品質変更要求を利用者から受け付けてネットワーク1に対して送出する処理を実行する。これを具体的に説明すると,携帯電話装置20との間で通話が開始された後,携帯電話装置10は,図7に示すように,音声品質アップの要求を受け付ける旨を表示部に表示する一方,操作部を介して利用者から音声品質アップの要求を受け付ける。そして,利用者の操作によって品質変更要求が入力されると,携帯電話装置10は,品質変更要求(例えば,音声品質アップの要求を示す制御信号を含んだ通信品質変更サーバ30宛のパケットなど)をネットワーク1Aに対して送出する。・・・・・・・・・
【0055】
その後,携帯電話装置10と携帯電話装置20との間で通話が開始され,さらに,発側の携帯電話装置10からネットワーク1Aに対して品質変更要求(例えば,音声品質変更の要求を示す制御信号を含んだ通信品質変更サーバ30宛のパケットなど)が送出されると(ステップS805),かかる品質変更要求を受け付けた通信品質変更サーバ30は,利用者認証を行う(ステップS806)。・・・・・・・・・」(11?12頁)

ル.「【0113】
(14)他の通信品質
また,図18に例示した各通信サービスにおいて本発明による変更受付が可能な通信品質の種類を説明すると,図19に示すように,例えば,電話(音声通話)サービスでは,接続品質(相手方の通信機器と円滑に回線が接続されるかに係る品質),音声品質(ノイズ,明瞭度,遅延に係る品質),安全性(通信内容が漏洩することがないかに係る品質)などについて品質変更要求を受け付けることができ,また,TV電話サービスや,コンテンツDL(ダウンロード)サービス,放送型配信サービスでも,同図に例示する各品質について品質変更要求を受け付けることができる。なお,図19は,通信サービスごとに,変更受付が可能な品質の例を示す図である。
【0114】
このように,一つの通信サービスであっても,複数の通信品質に対する相対的な変更要求を受け付けるようにすれば,複数の通信品質(例えば,接続品質,音声品質,画像品質および通信速度など)について変更を希望する利用者に対しても高い満足感を付与することが可能になる。
【0115】
(15)他の通信品質における通信因子
さらに,図19に例示した各品質において本発明により制御され得る通信因子の種類を説明すると,図20に示すように,例えば,接続品質を変更する場合には,優先度,帯域,サーバ(接続先)を通信因子として制御し,また,音声品質(ノイズ),音声品質(明瞭度),音声品質(遅延),画質(画像サイズ,圧縮レート,サンプリングレート,キャプチャーレート,ストリーミングレートなど),DL時間(遅延),安全性,料金(料金の高低,割引など)を変更する場合も,同図に例示する各通信因子を制御する。なお,図20は,通信品質ごとに,制御され得る通信因子の例を示す図である。」(21?22頁)

上記摘記事項チ.ヌ.ル.によれば,音声と画像という複数のメディアを有するTV電話について記載があり,音声品質,画質のそれぞれについて品質を変更することについて言及されているから,引用例2には以下のような事項(以下,「技術事項」という。)が記載されているものと認められる。

(技術事項)
「ネットワークに接続される通信機器の通信品質を通信確立後に要求に応じて変更するものにおいて,通信するサービスを複数のメディアから構成されるサービスとし,各メディア毎の品質を変更すること」


[対比]
補正後の発明を引用発明と対比すると,

a.引用発明の「PCRF」,「PCEF」,「AF」,「UE」及び「セッション情報」は,それぞれ補正後の発明の「ポリシー及び課金ルール機能(PCRF)」,「ポリシー及び課金施行機能(PCEF)」,「アプリケーション機能(AF)」,「ユーザ機器(UE)」及び「セッション情報」にそれぞれ相当する。

b.補正後の発明の「ポリシー及び課金ルール機能(PCRF)」は「サーバ」として構成されているのに対して,引用発明の「PCRF」の具体的な構成は明らかではないが,PCRFを実現する構成を有するという点では両者は共通する。
また,補正後の発明の「ポリシー及び課金施行機能(PCEF)を実現」する構成は「サーバ」であるのに対して,引用発明の「PCEF」の具体的な構成は明らかではないが,PCEFを実現する構成を有するという点では両者は共通する。

c.引用発明の「PCCルール」「新たなPCCルール」は複数のルールを含んでいることは明らかであるから,補正後の発明の「第1のポリシー及び課金制御(PCC)ルール群」「第2のポリシー及び課金制御(PCC)ルール群」にそれぞれ相当する。

d.引用発明の「UEとAFの間で,調整が行われ,その結果」得られる「セッション情報」が,補正後の発明の「ユーザ機器(UE)とアプリケーション機能(AF)との間でネゴシエートされたセッション情報」に相当する。
そして,引用発明では,PCRFがセッション情報に基づいてPCCルールを決定し,PCCルールを作成しているから,引用発明の「PCCルールを作成する構成」が,補正後の発明の「作成ユニット」に相当する。

e.引用発明の「前記PCEFが,前記PCCルールに従って前記UEに関連したサービスを開始するように,前記PCRFが前記PCEFに前記PCCルールの転送をセッションの確立時に行う構成」では,PCRFによるPCCルールの転送によって,PCCルールのPCEFへのインストールが行われるといえるが,当該インストールを,PCCルールの転送がトリガーしているということもできる。そして,このようなインストールはセッション確立時に行われることは明らかである。そうすると引用発明も,補正後の発明の「トリガーユニット」に対応する構成を有しているといえる。

f.引用発明の「QｏS変更要求を受信する構成」は,後述する点で相違するものの,補正後の発明の「サービス品質(QｏS)変更リクエストを受信するように構成されている受信ユニット(106)」に対応する。

g.引用発明の「前記PCCルールを作成する構成は前記QｏS変更要求に基づいて新たなPCCルールを作成」することは,補正後の発明の「作成ユニット(102)」が「前記サービス品質(QｏS)変更リクエストに基づいて,第2のポリシー及び課金制御(PCC)ルール群を作成する」ことに対応する。

h.引用発明の「前記PCEFが前記新たなPCCルールに従って,前記UEに関連したサービスを実施できるように,前記PCRFが前記新たなPCCルールをPCEFに転送すること」は,新たなPCCルールをPCEFに転送することによって,新たなPCCルールのPCEFへのインストールが行われるから,当該インストールを新たなPCCルールの転送がトリガーしているということもできるので,引用発明は上記e.で述べた「トリガーユニット」を有し,これによってトリガーしているといえる。

したがって,両者は以下の点で一致ないし相違する。

(一致点)
「ポリシー及び課金ルール機能(PCRF)を実現するように構成されているPCRFを実現する構成であって,
ユーザ機器(UE)とアプリケーション機能(AF)との間でネゴシエートされたセッション情報に基づいて,第1のポリシー及び課金制御(PCC)ルール群を作成するように構成されている作成ユニットと,
ポリシー及び課金施行機能(PCEF)を実現し,かつ前記第1のポリシー及び課金制御(PCC)ルール群に従って前記ユーザ機器(UE)と関連付けられたサービスを開始するように構成されているPCEFを実現する構成における前記第1のポリシー及び課金制御(PCC)ルール群のインストールを,前記ユーザ機器(UE)と関連付けられたユーザプレーンセッションの確立時に,トリガーするように構成されているトリガーユニットと,
前記ユーザ機器(UE)から発信されるサービス品質(QｏS)変更リクエストとしてサービス品質(QｏS)変更リクエストを受信するように構成されている受信ユニットと,
前記作成ユニット(102)は,前記サービス品質(QｏS)変更リクエストに基づいて,第2のポリシー及び課金制御(PCC)ルール群を作成するように構成され,
前記トリガーユニットは,更に,前記ポリシー及び課金施行(PCEF)を実現するように構成されている前記PCEFを実現する構成が,前記ポリシー及び課金施行機能(PCEF)を実現するように構成されているPCEFを実現する構成において,前記第2のポリシー及び課金制御(PCC)ルール群のインストールを,トリガーするように構成されている
ことを特徴とするPCRFを実現する構成。」

(相違点1)
「PCRFを実現する構成」及び「PCEFを実現する構成」に関して,補正後の発明では,それぞれサーバとして構成されているのに対して,引用発明では具体的構成が不明な点。

(相違点2)
「サービス」に関して,補正後の発明では,「複数のメディアが介在するサービス」であり,サービスへの「変更リクエスト」が,「メディア毎」「特定のメディアに専用」であるのに対して,引用発明では複数のメディアが介在するか不明な点。

(相違点3)
「変更リクエスト」の「受信」,「第2のポリシー及び課金制御(PCC)ルール群」の「作成」,及び「前記第2のポリシー及び課金制御(PCC)ルール群のインストール」の「トリガー」が,補正後の発明では「ユーザプレーンセッションの有効期間内」に行われているのに対して,引用発明では明示されていない点。

(相違点4)
補正後の発明は,「前記ユーザ機器(UE)と関連付けられたサービスを継続できるように,前記第2のポリシー及び課金制御(PCC)ルール群で前記第1のポリシー及び課金制御(PCC)ルール群を置換」しているのに対して,引用発明には明示されていない点。

(相違点5)
補正後の発明は,「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて,前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット(108)」を有しているのに対して,引用発明には明示されていない点。


[判断]
上記相違点1について検討する。
ネットワーク上の制御機能や管理機能をサーバに行わせることは技術常識にすぎず,「PCRFを実現する構成」及び「PCEFを実現する構成」をサーバで構成することは,実施にあたって適宜構成できる程度の事項にすぎない。

上記相違点2について検討する。
「技術事項」の項で述べたように「ネットワークに接続される通信機器の通信品質を通信確立後に要求に応じて変更するものにおいて,通信するサービスを複数のメディアから構成されるサービスとし,メディア毎の品質を変更すること」は公知の技術である。そうしてみると,引用発明において,同様の技術分野に属する上記公知技術を適用し,「サービス」を「複数のメディアが介在するサービス」とし,「変更リクエスト」を,「メディア毎」及び「特定のメディアに専用」のリクエストとすることは,ビデオが音声と画像という複数のメディアから構成されているように,サービスには複数のメディアが介在することは技術常識であり,またメディアが異なれば要求される品質が異なることは明らかであるから,当業者が容易に想到できた程度の事項にすぎない。

上記相違点3について検討する。
通信の継続中に,通信品質の変更要求を受け付けて通信品質を変更することは,例えば,特開2007-189444号公報(引用例2。図8及びこれに関連する発明の詳細な説明の記載を参照)にも記載されているように周知の技術事項にすぎない。そうしてみると,引用発明においてルールの変更に係る一連の動作を,それ以前の通信の継続中,すなわち「ユーザプレーンセッションの有効期間内」に行うようにすることは,技術常識を勘案して当業者が適宜なし得る事項にすぎない。

上記相違点4について検討する。
適用する構成を変更する際に,切替えを用いたり,置き換え(置換)によって行ったりすることは,適宜なし得る程度の一般的な技術事項にすぎないから,適用するルール群の置換によってルール群の変更を行うことは格別困難な事項とはいえない。
そして,ルール群の置換を行えば,ルール群の変更が切れ間なく行われることから,前記ユーザ機器(UE)と関連付けられたサービスは継続する。
したがって,相違点4とした補正後の発明の構成は,当業者が容易に想到できた程度の事項にすぎない。

上記相違点5について検討する。
変更要求を受け付ける際に,要求通りに変更可能かどうかを予め検討し,検討可能であることを決定することは,変更可能ではない場合に,予期しない結果が生じたりすることを予防するため,設計上許される範囲で適宜なされる程度の事項にすぎないものであり,例えば,引用例2に関する上記摘記事項リ.にも,予め変更要求を受け入れるか否かを判断することについて言及されている。そして,通信の分野において通信可能かどうかを,アクセスネットワーク状態や無線アクセス形式から判断することも,例えば,特開2007-81715号公報(【0128】段落参照)や,特開平11-98147号公報(【0025】?【0030】段落参照)に記載されているように技術常識にすぎない。そうすると,通信品質の変更要求を受け付ける際に,アクセスネットワーク状態や無線アクセス形式を参照して予め変更要求を受け入れるか否かを判断することは格別困難は事項とはいえない。
したがって,相違点5とした補正後の発明の構成は,当業者が引用発明と技術常識に基づいて容易に想到できた程度の事項にすぎない。


そして,補正後の発明が奏する効果も,引用発明,引用例2に記載された技術事項,及び周知の技術事項から,容易に予測できる範囲内のものである。

よって,補正後の発明は,引用発明,引用例2に記載された技術事項,及び周知の技術事項に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定によって,特許出願の際,独立して特許を受けることができないものである。


3.結語
以上のとおり,本件補正は,目的外の補正を含むものであるから,特許法第17条の2第5項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。仮に,請求人が審判請求書において主張するように,特許請求の範囲の減縮を目的とするものであり適法な補正であると仮定しても,補正後の発明は,特許出願の際,独立して特許を受けることができないものであるから,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。



第3 本願発明について
1.本願発明
平成26年6月26日付けの手続補正は上記のとおり却下されたので,本願発明は上記「第2 補正却下の決定」の項中の「1.本願発明と補正後の発明」の項で「本願発明」として認定したとおりのものである。

2.引用発明
引用発明,及び引用例2に記載された技術事項は,上記「第2 補正却下の決定」の項中の「(2)独立特許要件」の項で引用発明,及び引用例2に記載された技術事項として認定したとおりである。

3.対比・判断
上記「第2 補正却下の決定」の「(1)新規事項・シフト補正の有無について」で検討したように,本件補正は「サーバ(100)」の構成要素として「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて,前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質(QｏS)変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット(108)」に係る構成を付加するものである。
そうすると,本願発明は補正後の発明から,「・・・決定ユニット(108)」の構成を除いたものであり,本願発明の構成に本件補正に係る構成を付加した補正後の発明が,上記「第2 補正却下の決定」の項中の「(3)独立特許要件について」の項で検討したとおり,引用発明,引用例2に記載された技術事項,及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから,本願発明も同様の理由(ただし,「決定ユニット」についての判断を除く)により当業者が容易に発明をすることができたものである。

4.むすび
以上のとおり,本願発明は,引用発明,引用例2に記載された技術事項,及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,本願は,他の請求項について検討するまでもなく,拒絶すべきものである。
よって,結論のとおり審決する。
 
審理終結日 2015-06-17 
結審通知日 2015-06-22 
審決日 2015-07-13 
出願番号 特願2011-533546(P2011-533546)
審決分類 P 1 8・ 572- Z (H04M)
P 1 8・ 121- Z (H04M)
最終処分 不成立  
前審関与審査官 松原 徳久  
特許庁審判長 新川 圭二
特許庁審判官 山本 章裕
大塚 良平
発明の名称 ポリシー及び課金制御方法、サーバ、及びコンピュータプログラム  
代理人 高柳 司郎  
代理人 木村 秀二  
代理人 下山 治  
代理人 大塚 康弘  
代理人 大塚 康徳  

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