【事件の表示】
　特願２０１１−５３３５４６「ポリシー及び課金制御方法、サーバ、及びコンピュータプログラム」拒絶査定不服審判事件〔平成２２年　５月　６日国際公開、ＷＯ２０１０／０４９００２、平成２４年　３月２２日国内公表、特表２０１２−５０７２２３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００８年１０月３１日を国際出願日とする出願であって，平成２６年２月２８日付けで拒絶査定がなされ，これに対し，同年６月２６日に拒絶査定に対する審判請求がなされるとともに，同日付で手続補正書が提出され，同年１０月７日付けで上申書が提出されたものである。
第２　補正却下の決定
［補正却下の決定の結論］
　平成２６年６月２６日付けの手続補正を却下する。
［理由］
１．本願発明と補正後の発明
　平成２６年６月２６日付け手続補正（以下，「本件補正」という。）は，平成２５年９月３日付け手続補正書の特許請求の範囲の請求項８に記載された，
「　【請求項８】
　ポリシー及び課金ルール機能（ＰＣＲＦ）を実現するように構成されているサーバ（１００）であって，
　ユーザ機器（ＵＥ）とアプリケーション機能（ＡＦ）との間でネゴシエートされたセッション情報に基づいて，第１のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成されている作成ユニット（１０２）と，
　ポリシー及び課金施行機能（ＰＣＥＦ）を実現し，かつ前記第１のポリシー及び課金制御（ＰＣＣ）ルール群に従って前記ユーザ機器（ＵＥ）と関連付けられたサービスとして複数のメディアが介在するサービスを開始するように構成されているサーバ（２００）における前記第１のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，前記ユーザ機器（ＵＥ）と関連付けられたユーザプレーンセッションの確立時に，トリガーするように構成されているトリガーユニット（１０４）と，
　前記ユーザプレーンセッションの有効期間内に，前記ユーザ機器（ＵＥ）から発信されるサービス品質（ＱｏＳ）変更リクエストとして前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストを受信するように構成されている受信ユニット（１０６）とを有し，
　前記作成ユニット（１０２）は，更に，前記ユーザプレーンセッションの有効期間内に，メディア毎の前記サービス品質（ＱｏＳ）変更リクエストに基づいて，第２のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成され，
　前記トリガーユニット（１０４）は，更に，前記ポリシー及び課金施行機能（ＰＣＥＦ）を実現するように構成されている前記サーバ（２００）が，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群に従って，前記ユーザ機器（ＵＥ）と関連付けられたサービスを継続できるように，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群で前記第１のポリシー及び課金制御（ＰＣＣ）ルール群を置換することによって，前記ポリシー及び課金施行機能（ＰＣＥＦ）を実現するように構成されている前記サーバ（２００）において，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，前記ユーザプレーンセッションの有効期間内に，トリガーするように構成されている
　ことを特徴とするサーバ（１００）。」
 という発明（以下，「本願発明」という。）を，本件補正の手続補正書の特許請求の範囲の請求項８に記載された，
「　【請求項８】
　ポリシー及び課金ルール機能（ＰＣＲＦ）を実現するように構成されているサーバ（１００）であって，
　ユーザ機器（ＵＥ）とアプリケーション機能（ＡＦ）との間でネゴシエートされたセッション情報に基づいて，第１のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成されている作成ユニット（１０２）と，
　ポリシー及び課金施行機能（ＰＣＥＦ）を実現し，かつ前記第１のポリシー及び課金制御（ＰＣＣ）ルール群に従って前記ユーザ機器（ＵＥ）と関連付けられたサービスとして複数のメディアが介在するサービスを開始するように構成されているサーバ（２００）における前記第１のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，前記ユーザ機器（ＵＥ）と関連付けられたユーザプレーンセッションの確立時に，トリガーするように構成されているトリガーユニット（１０４）と，
　前記ユーザプレーンセッションの有効期間内に，前記ユーザ機器（ＵＥ）から発信されるサービス品質（ＱｏＳ）変更リクエストとして前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストを受信するように構成されている受信ユニット（１０６）と
，
　
アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて，前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット（１０８）と，
　前記作成ユニット（１０２）は，更に，前記ユーザプレーンセッションの有効期間内に，メディア毎の前記サービス品質（ＱｏＳ）変更リクエストに基づいて，第２のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成され，
　前記トリガーユニット（１０４）は，更に，前記ポリシー及び課金施行機能（ＰＣＥＦ）を実現するように構成されている前記サーバ（２００）が，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群に従って，前記ユーザ機器（ＵＥ）と関連付けられたサービスを継続できるように，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群で前記第１のポリシー及び課金制御（ＰＣＣ）ルール群を置換することによって，前記ポリシー及び課金施行機能（ＰＣＥＦ）を実現するように構成されている前記サーバ（２００）において，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，前記ユーザプレーンセッションの有効期間内に，トリガーするように構成されている
　ことを特徴とするサーバ（１００）。」（下線は，請求人が手続補正書において補正箇所を示すものとして付加したものを援用したものである。）
という発明（以下，「補正後の発明」という。）に補正することを含むものである。
２．補正の適否
（１）新規事項・シフト補正の有無について
　上記補正の内容は，「サーバ（１００）」の構成要素として「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて，前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット（１０８）」を付加するものである。
　そうしてみると，上記補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてなされた補正であり，特許法第１７条の２第３項（新規事項）の規定に適合し，また，同法第１７条の２第４項（シフト補正）の規定に適合することも明らかである。
（２）補正の目的について
　上記補正は，上記（１）で検討したように，本件「サーバ（１００）」の構成要素として新たに「決定ユニット（１０８）」を付加するものであるから，構成の外的付加に相当し，本件補正前の請求項８の構成の一部を限定的に減縮しているものということはできないし，また，請求項の削除，誤記の訂正，及び明りょうでない記載の釈明のいずれにも該当しないことは明らかである。
　したがって，上記補正は，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
（３）独立特許要件について
　前記「（２）補正の目的について」において判断したように，上記補正はいわゆる目的外の補正を含むものであり，特許法の規定に違反するものであるが，仮に上記補正が，請求人が審判請求書において主張するように，特許請求の範囲の減縮を目的とするものであり適法な補正であるとした場合についても検討する。
　上記補正が，特許請求の範囲の減縮を目的とするものとして，補正後の発明が特許出願の際に独立して特許を受けることができるものであるのかどうかについて，以下に検討する。
［補正後の発明］
　上記「１．本願発明と補正後の発明」の項において，「補正後の発明」として認定したとおりである。
［引用発明］
　原査定の拒絶理由に引用された文献であり，本願出願日前に公開された，3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architectures (Release 8)，3GPP TS 23.203　[ONLINE]，２００８年３月，V8.1.1，P.23-32, P.45-48，ＵＲＬ，http://www.3gpp.org/ftp/Specs/2008-03/Rel-8/23_series/23203-811.zip（ＵＲＬはhttp://www.qtc.jp/3GPP/Specs/23203-811.pdfに変更されている。以下，「引用例１」という。）には，図面とともに以下の事項が記載されている。
イ．「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.」（２３〜２４頁）
（当審仮訳：
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.」（２４〜２５頁）
（当審仮訳：
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;」（２６〜２８頁）
（当審仮訳：
6.2.2 ポリシー及び課金施行機能（PCEF）
6.2.2.1 全般
PCEFは，サービス・データ・フロー検出，ポリシー施行，フローベースの課金機能を包含する。
・・・・・・・・・
以下の２つの異なる方法で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.」（３２頁）
（当審仮訳：
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.」（３２頁）
（当審仮訳：
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.」（４５〜４６頁）
（当審仮訳：
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.
・・・・・・・・・」（４６〜４７頁）
（当審仮訳：
7.4.2 IP-CANセッション変更。PCRF開始
この条項は，PCRFによって開始されるIP-CANセッション変更のための信号の流れを説明します。 AFが関与し得ます。IP-CANセッションが変更されたセッションベースのサービスを開始するシナリオの例です。・・・・
・・・・・・・・・
3. PCRFは，認可やポリシー決定を行います。
4. PCRFは，PCEFに決定（複数可）を送信します。
5. PCEFは，その決定を実施します。
・・・・・・・・・）
　上記摘記事項の記載及び図面並びにこの分野における技術常識を考慮すると， 
ａ．上記摘記事項イ．〜ト．によれば，引用例１に記載のものは，ＰＣＲＦ，ＰＣＥＦ，ＡＦ,及びＵＥの各機能を含んで構成されている。そしてＰＣＲＦ及びＰＣＥＦをそれぞれ実現する具体的な構成が存在することは明らかである。
ｂ．特に上記摘記事項イ．及びロ．によれば，ＰＣＲＦがＰＣＣルールを決定しており，上記摘記事項ホ．を参照すれば，そのためにＡＦからセッション情報が転送されてくるといえる。
　またＡＦはＵＥに向けたサービスをするための構成であるから，ＰＣＲＦにおいてＰＣＣルールが決定されるより前に，ＡＦとＵＥの間で，調整が行われ，その結果がＡＦからセッション情報としてＰＣＲＦに転送されると考えるのが自然である。
　そして，引用例１に記載のものは，セッション情報に基づいてＰＣＲＦがＰＣＣルールを決定しているから，ＰＣＲＦは「ＰＣＣルールを生成する構成」を有しているといえる。（なお，3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architectures (Release 8)，3GPP TS 23.203　[ONLINE]，２００８年３月，V8.1.1の７７頁に「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におけるＰＣＥＦは、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]，２００８年３月，V8.1.1の４１頁の図７．２−１をみても（特にその手順６と７を参照），ＩＰ−ＣＡＮセッションの確立時に行われることが明らかである。
　さらに，当該ＰＣＣルールの転送により，ＰＣＥＦはＰＣＣルールを受信して保持するようになるのであるから，これをＰＣＣルールのインストールをトリガーしているということもでき，そのための構成を有していることは明らかである。
ｄ．上記摘記事項ヘ．及びト．によれば，セッションは変更することができ，ここで上記摘記事項ハ．などによれば，変更要求はＵＥによって開始されたものでも考慮されており，ＱｏＳの変更を求めているものである。そして，上記摘記事項ヘ．ト．及び図７．４の記載から，ＰＣＲＦは「新しいポリシー作成するために変更要求を受信する構成」を備えているということができる。
ｅ．上記摘記事項ヘ．及びト．によれば，ＰＣＲＦは新たなＰＣＣルールを作成するが，これも，上記ｂ．で言及した「ＰＣＣルールを作成する構成」が行うと考えるのが自然である。
ｆ．上記摘記事項の特にハ．ト．ヘ．によれば，ＰＣＲＦはＰＣＲＦが要求に応じて作成した新たなＰＣＣルールをＰＣＥＦに転送することにより，ＰＣＥＦは古いルールを除去して，変更したルールがＰＣＥＦにおいて実施されている。
　したがって，摘記した引用例１の記載及び図面を総合すると，引用例１には以下のような発明（以下，「引用発明」という。）が記載されているものと認められる。 
（引用発明）
「　ＰＣＲＦを実現する構成であって，
　ＵＥとＡＦの間で，調整が行われ，その結果が前記ＡＦからセッション情報としてＰＣＲＦに転送され，これに基づいて前記ＰＣＲＦがＰＣＣルールを作成する構成を有し，
　前記ＰＣＥＦが，前記ＰＣＣルールに従って前記ＵＥに関連したサービスを開始するように，前記ＰＣＲＦが前記ＰＣＥＦに前記ＰＣＣルールの転送をセッションの確立時に行う構成と，
　前記ＵＥから発信されるＱｏＳ変更要求を受信する構成と，
　前記ＰＣＣルールを作成する構成は前記ＱｏＳ変更要求に基づいて新たなＰＣＣルールを作成し，
　前記ＰＣＥＦが前記新たなＰＣＣルールに従って，前記ＵＥに関連したサービスを実施できるように，前記ＰＣＲＦが前記新たなＰＣＣルールをＰＣＥＦに転送すること，
を特徴とする構成。」
［技術事項］
　また，原査定の拒絶理由に引用された文献であり，本願出願日前に公開された特開２００７−１８９４４４号公報（以下，「引用例２」という。）には，図面とともに以下の事項が記載されている。
チ．「【０００１】
  この発明は，ネットワークに接続される通信機器の通信品質を利用者から受け付けた要求に応じて変更する通信品質変更システム，通信品質変更方法および通信品質変更プログラムに関する。」（３頁） 
リ．「【００４４】
  また、変更要求受付部３３ａは、品質変更要求を受け付けた場合に、利用者認証を行う処理部でもある。具体的には、品質変更要求に含まれる電話番号（品質変更要求を送出した携帯電話装置１０の電話番号）に基づいて利用者情報ＤＢ３２ａ（図３参照）を参照し、かかる電話番号が利用者情報ＤＢ３２ａに記憶されているか否か、さらには、かかる電話番号に対応付けて記憶されているサービス契約内容が現に有効であるか否かを判定することで利用者を認証する。なお、電話番号が利用者情報ＤＢ３２ａに記憶されていない場合や、サービス契約内容が無効である場合には、品質変更要求を拒絶する。」
ヌ．「【００５２】
  この品質変更プログラム１１は，通信品質変更サービスの利用に際して実行されるプログラムであり，かかるプログラムが組み込まれた携帯電話装置１０は，例えば，品質変更要求を利用者から受け付けてネットワーク１に対して送出する処理を実行する。これを具体的に説明すると，携帯電話装置２０との間で通話が開始された後，携帯電話装置１０は，図７に示すように，音声品質アップの要求を受け付ける旨を表示部に表示する一方，操作部を介して利用者から音声品質アップの要求を受け付ける。そして，利用者の操作によって品質変更要求が入力されると，携帯電話装置１０は，品質変更要求（例えば，音声品質アップの要求を示す制御信号を含んだ通信品質変更サーバ３０宛のパケットなど）をネットワーク１Ａに対して送出する。・・・・・・・・・
【００５５】
  その後，携帯電話装置１０と携帯電話装置２０との間で通話が開始され，さらに，発側の携帯電話装置１０からネットワーク１Ａに対して品質変更要求（例えば，音声品質変更の要求を示す制御信号を含んだ通信品質変更サーバ３０宛のパケットなど）が送出されると（ステップＳ８０５），かかる品質変更要求を受け付けた通信品質変更サーバ３０は，利用者認証を行う（ステップＳ８０６）。・・・・・・・・・」（１１〜１２頁）
ル．「【０１１３】
（１４）他の通信品質
  また，図１８に例示した各通信サービスにおいて本発明による変更受付が可能な通信品質の種類を説明すると，図１９に示すように，例えば，電話（音声通話）サービスでは，接続品質（相手方の通信機器と円滑に回線が接続されるかに係る品質），音声品質（ノイズ，明瞭度，遅延に係る品質），安全性（通信内容が漏洩することがないかに係る品質）などについて品質変更要求を受け付けることができ，また，ＴＶ電話サービスや，コンテンツＤＬ（ダウンロード）サービス，放送型配信サービスでも，同図に例示する各品質について品質変更要求を受け付けることができる。なお，図１９は，通信サービスごとに，変更受付が可能な品質の例を示す図である。
【０１１４】
  このように，一つの通信サービスであっても，複数の通信品質に対する相対的な変更要求を受け付けるようにすれば，複数の通信品質（例えば，接続品質，音声品質，画像品質および通信速度など）について変更を希望する利用者に対しても高い満足感を付与することが可能になる。
【０１１５】
（１５）他の通信品質における通信因子
  さらに，図１９に例示した各品質において本発明により制御され得る通信因子の種類を説明すると，図２０に示すように，例えば，接続品質を変更する場合には，優先度，帯域，サーバ（接続先）を通信因子として制御し，また，音声品質（ノイズ），音声品質（明瞭度），音声品質（遅延），画質（画像サイズ，圧縮レート，サンプリングレート，キャプチャーレート，ストリーミングレートなど），ＤＬ時間（遅延），安全性，料金（料金の高低，割引など）を変更する場合も，同図に例示する各通信因子を制御する。なお，図２０は，通信品質ごとに，制御され得る通信因子の例を示す図である。」（２１〜２２頁）
　上記摘記事項チ．ヌ．ル．によれば，音声と画像という複数のメディアを有するＴＶ電話について記載があり，音声品質，画質のそれぞれについて品質を変更することについて言及されているから，引用例２には以下のような事項（以下，「技術事項」という。）が記載されているものと認められる。
（技術事項）
「ネットワークに接続される通信機器の通信品質を通信確立後に要求に応じて変更するものにおいて，通信するサービスを複数のメディアから構成されるサービスとし，各メディア毎の品質を変更すること」
［対比］
　補正後の発明を引用発明と対比すると，
ａ．引用発明の「ＰＣＲＦ」，「ＰＣＥＦ」，「ＡＦ」，「ＵＥ」及び「セッション情報」は，それぞれ補正後の発明の「ポリシー及び課金ルール機能（ＰＣＲＦ）」，「ポリシー及び課金施行機能（ＰＣＥＦ）」，「アプリケーション機能（ＡＦ）」，「ユーザ機器（ＵＥ）」及び「セッション情報」にそれぞれ相当する。
ｂ．補正後の発明の「ポリシー及び課金ルール機能（ＰＣＲＦ）」は「サーバ」として構成されているのに対して，引用発明の「ＰＣＲＦ」の具体的な構成は明らかではないが，ＰＣＲＦを実現する構成を有するという点では両者は共通する。
　また，補正後の発明の「ポリシー及び課金施行機能（ＰＣＥＦ）を実現」する構成は「サーバ」であるのに対して，引用発明の「ＰＣＥＦ」の具体的な構成は明らかではないが，ＰＣＥＦを実現する構成を有するという点では両者は共通する。
ｃ．引用発明の「ＰＣＣルール」「新たなＰＣＣルール」は複数のルールを含んでいることは明らかであるから，補正後の発明の「第１のポリシー及び課金制御（ＰＣＣ）ルール群」「第２のポリシー及び課金制御（ＰＣＣ）ルール群」にそれぞれ相当する。
ｄ．引用発明の「ＵＥとＡＦの間で，調整が行われ，その結果」得られる「セッション情報」が，補正後の発明の「ユーザ機器（ＵＥ）とアプリケーション機能（ＡＦ）との間でネゴシエートされたセッション情報」に相当する。
　そして，引用発明では，ＰＣＲＦがセッション情報に基づいてＰＣＣルールを決定し，ＰＣＣルールを作成しているから，引用発明の「ＰＣＣルールを作成する構成」が，補正後の発明の「作成ユニット」に相当する。
ｅ．引用発明の「前記ＰＣＥＦが，前記ＰＣＣルールに従って前記ＵＥに関連したサービスを開始するように，前記ＰＣＲＦが前記ＰＣＥＦに前記ＰＣＣルールの転送をセッションの確立時に行う構成」では，ＰＣＲＦによるＰＣＣルールの転送によって，ＰＣＣルールのＰＣＥＦへのインストールが行われるといえるが，当該インストールを，ＰＣＣルールの転送がトリガーしているということもできる。そして，このようなインストールはセッション確立時に行われることは明らかである。そうすると引用発明も，補正後の発明の「トリガーユニット」に対応する構成を有しているといえる。
ｆ．引用発明の「ＱｏＳ変更要求を受信する構成」は，後述する点で相違するものの，補正後の発明の「サービス品質（ＱｏＳ）変更リクエストを受信するように構成されている受信ユニット（１０６）」に対応する。
ｇ．引用発明の「前記ＰＣＣルールを作成する構成は前記ＱｏＳ変更要求に基づいて新たなＰＣＣルールを作成」することは，補正後の発明の「作成ユニット（１０２）」が「前記サービス品質（ＱｏＳ）変更リクエストに基づいて，第２のポリシー及び課金制御（ＰＣＣ）ルール群を作成する」ことに対応する。
ｈ．引用発明の「前記ＰＣＥＦが前記新たなＰＣＣルールに従って，前記ＵＥに関連したサービスを実施できるように，前記ＰＣＲＦが前記新たなＰＣＣルールをＰＣＥＦに転送すること」は，新たなＰＣＣルールをＰＣＥＦに転送することによって，新たなＰＣＣルールのＰＣＥＦへのインストールが行われるから，当該インストールを新たなＰＣＣルールの転送がトリガーしているということもできるので，引用発明は上記ｅ．で述べた「トリガーユニット」を有し，これによってトリガーしているといえる。
　したがって，両者は以下の点で一致ないし相違する。
（一致点）
「ポリシー及び課金ルール機能（ＰＣＲＦ）を実現するように構成されているＰＣＲＦを実現する構成であって，
　ユーザ機器（ＵＥ）とアプリケーション機能（ＡＦ）との間でネゴシエートされたセッション情報に基づいて，第１のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成されている作成ユニットと，
　ポリシー及び課金施行機能（ＰＣＥＦ）を実現し，かつ前記第１のポリシー及び課金制御（ＰＣＣ）ルール群に従って前記ユーザ機器（ＵＥ）と関連付けられたサービスを開始するように構成されているＰＣＥＦを実現する構成における前記第１のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，前記ユーザ機器（ＵＥ）と関連付けられたユーザプレーンセッションの確立時に，トリガーするように構成されているトリガーユニットと，
　前記ユーザ機器（ＵＥ）から発信されるサービス品質（ＱｏＳ）変更リクエストとしてサービス品質（ＱｏＳ）変更リクエストを受信するように構成されている受信ユニットと，
　前記作成ユニット（１０２）は，前記サービス品質（ＱｏＳ）変更リクエストに基づいて，第２のポリシー及び課金制御（ＰＣＣ）ルール群を作成するように構成され，
　前記トリガーユニットは，更に，前記ポリシー及び課金施行（ＰＣＥＦ）を実現するように構成されている前記ＰＣＥＦを実現する構成が，前記ポリシー及び課金施行機能（ＰＣＥＦ）を実現するように構成されているＰＣＥＦを実現する構成において，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群のインストールを，トリガーするように構成されている
　ことを特徴とするＰＣＲＦを実現する構成。」
（相違点１）
　「ＰＣＲＦを実現する構成」及び「ＰＣＥＦを実現する構成」に関して，補正後の発明では，それぞれサーバとして構成されているのに対して，引用発明では具体的構成が不明な点。
（相違点２）
　「サービス」に関して，補正後の発明では，「複数のメディアが介在するサービス」であり，サービスへの「変更リクエスト」が，「メディア毎」「特定のメディアに専用」であるのに対して，引用発明では複数のメディアが介在するか不明な点。
（相違点３）
　「変更リクエスト」の「受信」，「第２のポリシー及び課金制御（ＰＣＣ）ルール群」の「作成」，及び「前記第２のポリシー及び課金制御（ＰＣＣ）ルール群のインストール」の「トリガー」が，補正後の発明では「ユーザプレーンセッションの有効期間内」に行われているのに対して，引用発明では明示されていない点。
（相違点４）
　補正後の発明は，「前記ユーザ機器（ＵＥ）と関連付けられたサービスを継続できるように，前記第２のポリシー及び課金制御（ＰＣＣ）ルール群で前記第１のポリシー及び課金制御（ＰＣＣ）ルール群を置換」しているのに対して，引用発明には明示されていない点。
（相違点５）
　補正後の発明は，「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて，前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット（１０８）」を有しているのに対して，引用発明には明示されていない点。
［判断］
　上記相違点１について検討する。
　ネットワーク上の制御機能や管理機能をサーバに行わせることは技術常識にすぎず，「ＰＣＲＦを実現する構成」及び「ＰＣＥＦを実現する構成」をサーバで構成することは，実施にあたって適宜構成できる程度の事項にすぎない。
　上記相違点２について検討する。
　「技術事項」の項で述べたように「ネットワークに接続される通信機器の通信品質を通信確立後に要求に応じて変更するものにおいて，通信するサービスを複数のメディアから構成されるサービスとし，メディア毎の品質を変更すること」は公知の技術である。そうしてみると，引用発明において，同様の技術分野に属する上記公知技術を適用し，「サービス」を「複数のメディアが介在するサービス」とし，「変更リクエスト」を，「メディア毎」及び「特定のメディアに専用」のリクエストとすることは，ビデオが音声と画像という複数のメディアから構成されているように，サービスには複数のメディアが介在することは技術常識であり，またメディアが異なれば要求される品質が異なることは明らかであるから，当業者が容易に想到できた程度の事項にすぎない。
　上記相違点３について検討する。
　通信の継続中に，通信品質の変更要求を受け付けて通信品質を変更することは，例えば，特開２００７−１８９４４４号公報（引用例２。図８及びこれに関連する発明の詳細な説明の記載を参照）にも記載されているように周知の技術事項にすぎない。そうしてみると，引用発明においてルールの変更に係る一連の動作を，それ以前の通信の継続中，すなわち「ユーザプレーンセッションの有効期間内」に行うようにすることは，技術常識を勘案して当業者が適宜なし得る事項にすぎない。
　上記相違点４について検討する。
　適用する構成を変更する際に，切替えを用いたり，置き換え（置換）によって行ったりすることは，適宜なし得る程度の一般的な技術事項にすぎないから，適用するルール群の置換によってルール群の変更を行うことは格別困難な事項とはいえない。
　そして，ルール群の置換を行えば，ルール群の変更が切れ間なく行われることから，前記ユーザ機器（ＵＥ）と関連付けられたサービスは継続する。
　したがって，相違点４とした補正後の発明の構成は，当業者が容易に想到できた程度の事項にすぎない。
　上記相違点５について検討する。
　変更要求を受け付ける際に，要求通りに変更可能かどうかを予め検討し，検討可能であることを決定することは，変更可能ではない場合に，予期しない結果が生じたりすることを予防するため，設計上許される範囲で適宜なされる程度の事項にすぎないものであり，例えば，引用例２に関する上記摘記事項リ．にも，予め変更要求を受け入れるか否かを判断することについて言及されている。そして，通信の分野において通信可能かどうかを，アクセスネットワーク状態や無線アクセス形式から判断することも，例えば，特開２００７−８１７１５号公報（【０１２８】段落参照）や，特開平１１−９８１４７号公報（【００２５】〜【００３０】段落参照）に記載されているように技術常識にすぎない。そうすると，通信品質の変更要求を受け付ける際に，アクセスネットワーク状態や無線アクセス形式を参照して予め変更要求を受け入れるか否かを判断することは格別困難は事項とはいえない。
　したがって，相違点５とした補正後の発明の構成は，当業者が引用発明と技術常識に基づいて容易に想到できた程度の事項にすぎない。
　そして，補正後の発明が奏する効果も，引用発明，引用例２に記載された技術事項，及び周知の技術事項から，容易に予測できる範囲内のものである。
　よって，補正後の発明は，引用発明，引用例２に記載された技術事項，及び周知の技術事項に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定によって，特許出願の際，独立して特許を受けることができないものである。 
３．結語
　以上のとおり，本件補正は，目的外の補正を含むものであるから，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。仮に，請求人が審判請求書において主張するように，特許請求の範囲の減縮を目的とするものであり適法な補正であると仮定しても，補正後の発明は，特許出願の際，独立して特許を受けることができないものであるから，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１．本願発明
　平成２６年６月２６日付けの手続補正は上記のとおり却下されたので，本願発明は上記「第２　補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりのものである。
２．引用発明
　引用発明，及び引用例２に記載された技術事項は，上記「第２　補正却下の決定」の項中の「（２）独立特許要件」の項で引用発明，及び引用例２に記載された技術事項として認定したとおりである。
３．対比・判断
　上記「第２　補正却下の決定」の「（１）新規事項・シフト補正の有無について」で検討したように，本件補正は「サーバ（１００）」の構成要素として「アクセスネットワーク状態及び無線アクセス形式の少なくとも一方に基づいて，前記サービスが介在する前記複数のメディアの内の特定のメディアに専用となるサービス品質（ＱｏＳ）変更リクエストが前記ユーザプレーンセッションに適用できることを決定するように構成されている決定ユニット（１０８）」に係る構成を付加するものである。
　そうすると，本願発明は補正後の発明から，「・・・決定ユニット（１０８）」の構成を除いたものであり，本願発明の構成に本件補正に係る構成を付加した補正後の発明が，上記「第２　補正却下の決定」の項中の「（３）独立特許要件について」の項で検討したとおり，引用発明，引用例２に記載された技術事項，及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから，本願発明も同様の理由（ただし，「決定ユニット」についての判断を除く）により当業者が容易に発明をすることができたものである。
４．むすび
　以上のとおり，本願発明は，引用発明，引用例２に記載された技術事項，及び周知の技術事項に基いて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。
　よって，結論のとおり審決する。