【事件の表示】
　特願２０１２−５５６３５９「ユーザ機器のサービス品質を制御するための方法および装置」拒絶査定不服審判事件〔平成２３年　９月１５日国際公開、ＷＯ２０１１／１０９９３４、平成２５年　６月１０日国内公表、特表２０１３−５２１５８６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２０１０年（平成２２年）３月９日を国際出願日とする出願であって、平成２４年１０月３０日付けで審査請求がなされ、平成２５年１２月１３日付けで拒絶理由通知がなされ、平成２６年５月１４日付けで意見書が提出されるとともに、同日付で手続補正がなされたが、同年１２月１日付けで拒絶査定がなされたものである。
　これに対して、平成２７年４月１日付けで拒絶査定不服審判が請求されたものである。
第２　本願発明について
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２６年５月１４日付けの手続補正書によって補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
「ポリシーおよび課金ルール機能エンティティ内で、ユーザ機器に対応するサービス品質を制御する方法であって、
　Ａ．　前記ユーザ機器に関する課金関連情報を入手するステップと、
　Ｂ．　前記課金関連情報に従って前記ユーザ機器に対応するサービス品質を決定するステップとを含み、
　前記課金関連情報が、前記ユーザ機器の料金一括契約タイプ、前記ユーザ機器のリチャージ額、複数の期間に対応する前記ユーザ機器の複数の使用料、および複数の地理的領域に対応する前記ユーザ機器の複数の使用料のうちの少なくとも１つを含む、方法。」
第３　当審の判断
１．引用例について
（１）引用例１の記載について
　平成２５年１２月１３日付けの拒絶理由通知で引用された国際公開第２００９／０８９４５５号（以下、「引用例１」という。）には、図面とともに、以下のことが記載されている。（なお、下線は、当審において付与した。以下、同じ。）　
（ア）「[0008] In one aspect, 
a method operable by a network in configuring quality of service (QoS) for an access terminal comprises receiving, at a network, a request for packet data access from an access terminal.
（当審訳：［0008］一態様では、
アクセス端末のためにサービス品質（ＱｏＳ）の構成を設定することにおいて、ネットワークにより実施可能な方法
（イ）「[0014] In some aspects of the apparatus and methods described herein, the preconfigured information comprises subscriber information including a QoS user profile. Further, in some aspects, the initial QoS parameters may be derived from the QoS user profile based on an access network used by the access terminal. For example, 
the initial QoS parameters may comprise at least one of maximum authorized aggregate bandwidth for best effort traffic, authorized flow profile IDs for each direction, maximum per flow priority, allowed differentiated services markings, inter-user priority for best effort, mapping between QoS claims (such as QoSFlowProfilelD or QoS Class Indicator (QCI)) and Differentiated Services Code Point (DSCP), and mapping between QoS class and Token Bucket Parameters
（当審訳：［0014］ここに記載の装置および方法の幾つかの態様では、前記事前構成情報がＱｏＳユーザプロフィールを含む加入者情報を備える。さらに、幾つかの態様では、前記初期ＱｏＳパラメータが前記アクセス端末によって用いられるアクセスネットワークに基づいて前記ＱｏＳユーザプロフィールから取得されてよい。例えば、
前記初期ＱｏＳパラメータはベストエフォートトラフィックのための最大許可総帯域幅、各方向についての許可フロープロフィールＩＤ、最高のフロー毎の優先度、許容差別化サービスのマーキング、ベストエフォートのためのユーザ間優先度、ＱｏＳクレーム（例えば、ＱｏＳＦｌｏｗＰｒｏｆｉｌｅＩＤまたはＱｏＳクラスインジケータ（ＱＣＩ））と差別化サービスコードポイント（ＤＳＣＰ）との間におけるマッピング、およびＱｏＳクラスとトークンバケットパラメータとの間におけるマッピングのうちの少なくとも１つを備えてよい。
（ウ）「[0032] For example, referring to Fig. 2, in one aspect, 
policy function 20 includes a policy determination module 24 operable to generate initial QoS policy configuration 22 based on subscriber information 26 and/or network information 28.
[0033] Further, for example, 
subscriber information 26 and/or network information 28 is information relevant to determining one or more QoS parameters to an IP flow. 
subscriber information 26 may include all or a part of a subscriber profile 30, which may be obtained from a subscriber database 32 on the network. 
subscriber profile 30 may include parameters defining AT-specific capabilities and/or allowances, also referred to as a QoS user profile 34, with respect to one or more applications 36 operable on the respective AT.
QoS user profile 34 may include, but is not limited to, parameters such as maximum authorized aggregate bandwidth for best effort traffic, authorized flow profile IDs for each direction, maximum per flow priority, allowed differentiated services markings, inter-user priority for best effort, mapping between QoS class (such as QoSFlowProfilelD or QoS Class Indicator (QCI)) and Differentiated Services Code Point (DSCP), and mapping between QoS claims (such as QoSFlowProfilelD or QCI) and policing rules such as Token Bucket Parameters including, but not limited to, peak rate, bucket size, token rate, maximum latency, etc. In addition, other relevant QoS characteristics can be implemented in accordance with aspects disclosed herein.
（当審訳：[0032]例えば、図２を参照すると、一態様では、
ポリシー機能２０が、加入者情報２６および／またはネットワーク情報２８に基づいて初期ＱｏＳポリシー構成２２を生成するように動作可能なポリシー決定モジュール２４を含む。
[0033]さらに、例えば、
加入者情報２６および／またはネットワーク情報２８はＩＰフローへの１つ以上のＱｏＳパラメータを決定することに関連する情報である。
加入者情報２６はネットワーク上において加入者データベース３２から得ることができる加入者プロフィール３０の全体または一部を含み得る。
加入者プロフィール３０は該当ＡＴにおいて動作可能な１つ以上のアプリケーション３６に関して、ＱｏＳユーザプロフィール３４とも呼ばれるＡＴ固有の能力および／または許容範囲を定義するパラメータを含み得る。
ＱｏＳユーザプロフィール３４は、限定されるものでないが、パラメータ、例えば、ベストエフォートトラフィックのための最大の許可総帯域幅、各方向のための許可フロープロフィールＩＤ、フローごとの最高優先度、許容差別化サービスのマーキング、ベストエフォートのためのユーザ間優先度、ＱｏＳクラス（例えば、ＱｏｓＦｌｏｗＰｒｏｆｉｌｅＩＤまたはＱｏＳクラスインジケータ（ＱＣＩ））と差別化サービスコードポイント（ＤＳＣＰ）との間におけるマッピング、およびＱｏＳクレーム（例えば、ＱｏｓＦｌｏｗＰｒｏｆｉｌｅＩＤまたはＱＣＩ）と、例えば限定されるものでないが、ピークレート、バケットサイズ、トークンレート、最大レーテンシー等を含むトークンバケットパラメータのようなポリシー規則との間におけるマッピングを含み得る。
（エ）「[0043] Additionally, referring to Figs. 6A, 6B, 7A and 7B, aspects of specific examples in an Ultra Mobile Broadband (UMB) network include respective message flows for carrying out the above-described methods. It should be understood, however, that the described aspects are not limited to a UMB system architecture, but instead may be applied to any system architecture, such as but not limited to 3GPP, 3GPP2, Long Term Evolution (LTE), WCDMA, wired networks, etc. Further, in Figs. 6A, 6B, 7A and 7B, serving AN 16 includes a serving enhanced base station (S-eBS), a data access point (DAP), and a signaling radio network controller (SRNC). Additionally, 
the policy function 20 includes an authentication and authorization (AAA) server and a policy and charging rules function (PCRF). 
（当審訳：［0043］加えて、図６Ａ、６Ｂ、７Ａおよび７Ｂを参照すると、ウルトラモバイルブロードバンド（ＵＭＢ）ネットワークにおける具体例の態様が上述の方法を実行するための該当メッセージフローを含む。しかしながら、記載の態様はＵＭＢシステムアーキテクチャに限定されず、例えば３ＧＰＰ、３ＧＰＰ２、ロングタームエボリューション（ＬＴＥ）、ＷＣＤＭＡ、有線ネットワーク等であってこれらに限定されない任意のシステムアーキテクチャに対して適用可能であることが理解されるべきである。さらに、図６Ａ、６Ｂ、７Ａおよび７Ｂにおいて、サービング(serving)ＡＮ１６は、サービング拡張基地局（Ｓ−ｅＢＳ）、データアクセスポイント（ＤＡＰ）、およびシグナリング無線ネットワークコントローラ（ＳＲＮＣ）を含む。加えて、
ポリシー機能２０は、認証および許可（ＡＡＡ）サーバ、並びにポリシーおよび課金規則機能（ＰＣＲＦ）を含む。
　上記（ア）〜（エ）の記載を参照すると、次のことがいえる。
（あ）上記（ア）の記載から、アクセス端末のためにサービス品質（ＱｏＳ）の構成を設定することにおいて、ネットワークにより実施可能な方法であることがわかる。
（い）上記（イ）の記載から、初期ＱｏＳパラメータはベストエフォートトラフィックのための最大許可総帯域幅、各方向についての許可フロープロフィールＩＤ、最高のフロー毎の優先度、許容差別化サービスのマーキング、ベストエフォートのためのユーザ間優先度、ＱｏＳクレーム（例えば、ＱｏＳＦｌｏｗＰｒｏｆｉｌｅＩＤまたはＱｏＳクラスインジケータ（ＱＣＩ））と差別化サービスコードポイント（ＤＳＣＰ）との間におけるマッピング、およびＱｏＳクラスとトークンバケットパラメータとの間におけるマッピングのうちの少なくとも１つを備えていることがわかる。
（う）上記（ウ）の記載から、ポリシー機能が加入者情報および／またはネットワーク情報に基づいて初期ＱｏＳポリシー構成を生成するように動作可能なポリシー決定モジュールを含むことがわかる。
　加えて、加入者情報は、ネットワーク上において加入者データベースから得ることができる加入者プロフィールの全体または一部を含むことがわかる。
　さらに、加入者プロフィールは、該当アクセス端末において動作可能な１つ以上のアプリケーションに関して、ＱｏＳユーザプロフィールとも呼ばれるアクセス端末固有の能力および／または許容範囲を定義する、ベストエフォートトラフィックのための最大の許可総帯域幅に関するパラメータを含んでいることがわかる。
（え）上記（エ）の記載から、ポリシー機能は、認証および許可（ＡＡＡ）サーバ、並びにポリシーおよび課金ルール機能（ＰＣＲＦ）を含むことがわかる。
　上記（あ）〜（え）の事項を踏まえると、引用例１には、実質的に次の発明（以下、「引用例１発明」という。）が記載されているものと認められる。
アクセス端末のためにサービス品質（ＱｏＳ）の構成を設定することにおいて、ネットワークにより実施可能な方法であって、
加入者データベースから得られる、該当アクセス端末において動作可能な１つ以上のアプリケーションに関して、アクセス端末固有の能力および／または許容範囲を定義する、ベストエフォートトラフィックのための最大の許可総帯域幅に関するパラメータである、ＱｏＳユーザプロフィールとも呼ばれる、加入者プロフィールの全体または一部を含む加入者情報と、
ポリシーおよび課金ルール機能（ＰＣＲＦ）を含むポリシー機能が加入者情報に基づいて初期ＱｏＳポリシー構成を生成する、
方法。
（２）同じく原審の拒絶理由に引用された特表２００９−５４１８７２号公報（以下、「引用例２」という。）には図面とともに以下の事項が記載されている。
（オ）「【０００８】
　図２から見て取れるように、ＱｏＳおよび課金ポリシー制御に対する３ＧＰＰのポリシー・アーキテクチャは加入者（ユーザ）固有の加入データが課金ポリシーと、アプリケーション機能ＡＦからユーザ装置ＵＥ（図２に不図示）へのサービスの提供方法に関するポリシーとに影響を及ぼすことを可能にする。よって、
ＳＰＲ（Ｓｕｂｓｃｒｉｐｔｉｏｎ  Ｐｏｌｉｃｙ  Ｒｅｐｏｓｉｔｏｒｙ、加入ポリシー・レポジトリ）は加入者に関連するポリシーとデータとのみを記憶する。このようなデータの例は加入タイプおよびＱｏＳである。例えば、ユーザとアプリケーション機能ＡＦのオペレータとの間の合意（図１ｂの合意Ｓ７を参照）が、ユーザが支払いを要する特定のサービス品質ＱｏＳの提供を受けようとするというようなものであれば、続いて、伝送品質（ＱｏＳ）に対する支払いに伴うサービスが提供され、（ＩＭＳＩ、ＭＳＩＳＤＮ、ＡＰＮ、およびＲＡＴの種類などのユーザ識別情報により特定されるような）このユーザに適用される課金レートに従ってユーザに課金することをＰＣＥＦ施行ユニットは保証するであろう。
（カ）「【００５２】
  図４におけるすべてのサービス提供特性は提供される実際のコンテンツ・プロバイダおよびサービスに関連する。サービス提供特性は特定のユーザ（加入者）に関連していてもよいし、していなくてもよい。すなわち、図４におけるような入力は、ユーザ固有ベースで提供されることもでき、以下で説明するように、収集コントローラＳＰＣ−ＣＮＴＬはこれら入力をサービス提供のためにユーザ関連ベースで実装してもよい。しかしながら、図４におけるすべてのサービス提供特性は提供されるコンテンツ・プロバイダおよびサービスに関連するので、サービス提供特性はユーザ・データベースＵＤＢに通常記憶されるユーザ固有の加入データとは本質的に異なる。
例えば図２を参照して既に上述したように、当然ながら、元々の加入処理において、ユーザとアプリケーション機能ＡＦのオペレータとは−契約または合意を通じて−所定の帯域幅（サービス品質；ＱｏＳ）および所定の課金レートに関して合意してもよい。
 （え）上記（オ）（カ）の記載によれば、引用例２には、次の事項が記載されているといえる。
　ユーザとアプリケーション機能ＡＦのオペレータとの間の契約を通じ、ユーザが支払いを要する特定のサービス品質ＱｏＳの提供を受けようとするさいに、所定の帯域幅（サービス品質：ＱｏＳ）および所定の課金レートに合意する。
（３）国際公開第２００９／１４９１１１号（以下、「引用例３」という。）には図面とともに以下の事項が記載されている。
（キ）「[0058] As discussed supra, the UE 202 can give rise to various data flows. Some flows can be user data generated at the UE 202 while other flows can relate to data received by the UE 202 that should be forwarded further to a network element. For example, one flow can facilitate browsing the Internet, while another flow can facilitate VoIP (Voice over Internet Protocol) services. By the way of illustration and not limitation, unidirectional flow of IP packets with the same source IP address and the same destination IP address and the same transport protocol can be referred to as an IP flow. The IP flows can be encapsulated and transported across various networks via communication channels that can be termed as IP tunnels. Additionally, 
each of these flows has specific rules to be implemented such as, QoS considerations or rules for charging a subscriber for services rendered associated therewith. In accordance with further aspects, these rules can be predetermined or they can be determined dynamically. For example, the QoS considerations can depend on the type of data being generated or type of service plan associated with the UE 202. These rules are determined by the PCRF (Policy and Charging Rules Function)
（当審訳：[0058］以上に議論されたように、UE202は様々なデータフローを生成しうる。いくつかのフローはUE202で生成されるユーザーデータであり、別のフローは、ネットワークエレメントにさらに転送されるべき、UE202によって受信されるデータに関係する。例えば、1つのフローはインターネットのブラウジングを容易にし、別のフローはVoIP（Voice over Internet Protocol）サービスを容易にする。それに制限されない例として、同一のソースIPアドレス、同一の宛先IPアドレス、および同一のトランスポートプロトコルを有するIPパケットの単一方向フローはIPフローと呼ばれる。IPフローはカプセル化され、IPトンネルと呼ばれる通信チャネルを介して様々なネットワークをまたいで移送される。加えて、
これらのフローの各々は、それらと関連付けされたサービスの料金を加入者に課金するためのQoS考慮またはルールなどの実施されるべき固有ルールを有する。さらなる態様に従って、これらのルールは予め決定され、または、それらは動的に決定される。例えば、QoS考慮は、生成されているデータのタイプ、またはUE202に関連付けられたサービスプランのタイプに依存する。これらのルールは、PCRF（ポリシーおよび課金ルール機能）によって決定され
 （お）上記（キ）の記載によれば、引用例３には、次の事項が記載されているといえる。
　QoS考慮は、PCRF（ポリシーおよび課金ルール機能）によって決定される。
（４）国際公開第２００９／１５５３６５号（以下、「引用例４」という。）には図面とともに以下の事項が記載されている。
（ク）「[0050] In one aspect, in a NW-initiated resource setup (as depicted in Sequence A in Fig. 2), 
when the PCRF 206 receives the service information from the application function 202, the PCRF 206 can create authorized PCC/QoS rules in accordance with the received service information, where the PCC/QoS rules can comprise information that can facilitate enabling detection of service data flow and providing parameters for policy, charging, and QoS control. 
（当審訳：[0050］一態様では、ＮＷ始動のリソースセットアップにおいて（図２のシーケンスＡで図示されている）、
ＰＣＲＦ２０６がアプリケーション機能２０２からサービス情報を受信するとき、ＰＣＲＦ２０６は、受信サービス情報にしたがって認可されたＰＣＣ／ＱｏＳルールを作成することができ、ＰＣＣ／ＱｏＳルールは、サービスデータフローの検出をイネーブルすることと、ポリシ、チャージング、及びＱｏＳ制御のためのパラメータを提供することと、を容易にすることができる情報を備えることができる。
 （か）上記（ク）の記載によれば、引用例４には、次の事項が記載されているといえる。
　ＰＣＲＦは、ＱｏＳルールを作成する。
（５）国際公開第２０１０／０２２０８５号（以下、「引用例５」という。）には図面とともに以下の事項が記載されている。
（ケ）「[0057] In operation, 
the PCRF 408 receives information from the gateways (e.g., 404, 406, or 410), or an application function in the network, such as an application request,  and based on the received information the PCRF 408 derives the QoS rules. 
（当審訳：[0057］動作中、
ＰＣＲＦ４０８は、ゲートウェイ（例えば、４０４、４０６、または４１０）、あるいは、ネットワーク内のアプリケーション機能から、例えばアプリケーション要求のような情報を受信し、この受信した情報に基づいて、ＱｏＳルールを導出する。
 （き）上記（ケ）の記載によれば、引用例５には、次の事項が記載されているといえる。
　ＰＣＲＦは、ＱｏＳルールを導出する。
３．対比・判断
（１）本願発明と引用例１発明とを対比する
（ア）引用例１発明は、アクセス端末のために、初期ＱｏＳポリシー構成を生成することによって、サービス品質（ＱｏＳ）の構成を設定することを行っているから、本願発明の「ユーザ機器に対応するサービス品質を制御する方法」と同様の方法であると認められる。
（イ）引用例１発明は、加入者データベースから、該当アクセス端末において動作可能な１つ以上のアプリケーションに関して、アクセス端末固有の能力および／または許容範囲を定義する、ベストエフォートトラフィックのための最大の許可総帯域幅に関するパラメータである、ＱｏＳユーザプロフィールとも呼ばれる、加入者プロフィールの全体または一部を含む加入者情報を得ているから、本願発明の「前記ユーザ機器に関する課金関連情報を入手するステップ」と、ユーザ機器に関する情報を入手するステップを有している点で共通する。
（ウ）引用例１発明は、ポリシー機能が加入者情報に基づいて初期ＱｏＳポリシー構成を生成し、これによりサービス品質（ＱｏＳ）の構成を設定しているから、本願発明の「前記課金関連情報に従って前記ユーザ機器に対応するサービス品質を決定するステップ」と、前記情報に従って前記ユーザ機器に対応するサービス品質を決定するステップを有している点で共通する。
（２）以上（ア）〜（ウ）のことから、本願発明と引用例１発明とは、以下の点で一致し、また、相違する。
　
［一致点］
ユーザ機器に対応するサービス品質を制御する方法であって、
　Ａ．　前記ユーザ機器に関する情報を入手するステップと、
　Ｂ．　前記情報に従って前記ユーザ機器に対応するサービス品質を決定するステップとを含む、
方法。
［相違点１］
　本願発明のユーザ機器に関する情報は、「ユーザ機器に関する課金関連情報」であって、この「課金関連情報」が、「前記ユーザ機器の料金一括契約タイプ、前記ユーザ機器のリチャージ額、複数の期間に対応する前記ユーザ機器の複数の使用料、および複数の地理的領域に対応する前記ユーザ機器の複数の使用料のうちの少なくとも１つを含む」情報であるのに対して、引用例１発明のユーザ機器に関する情報はそのようになっていない点。
［相違点２］
　本願発明は、「ポリシーおよび課金ルール機能エンティティ内で、ユーザ機器に対応するサービス品質を制御する方法」であるのに対して、引用例１発明は「ユーザ機器に対応するサービス品質を制御する方法」であるが、「ポリシーおよび課金ルール機能エンティティ内」で「ユーザ機器に対応するサービス品質を制御する方法」を行っているのか明らかでない点。
（３）当審の判断
　以下、相違点について検討する。
（ア）［相違点１］について
　引用例２に記載されているように、ユーザとアプリケーション機能ＡＦのオペレータとの間の契約を通じ、ユーザが支払いを要する特定のサービス品質ＱｏＳの提供を受けようとするさいに、所定の帯域幅（サービス品質：ＱｏＳ）および所定の課金レートに合意することは、公知の事項である。
　引用例２記載の公知事項は、契約を通じ所定の帯域幅（サービス品質：ＱｏＳ）および所定の課金レートに合意した契約であること、および、合意された内容に所定の帯域幅（サービス品質：ＱｏＳ）が含まれることから、「契約」および「契約」に含まれる「帯域幅」は、本願発明の「ユーザ機器の料金一括契約タイプ」の契約および「課金関連情報」に相当する。
　そして、引用例１発明おいても、引用例２記載の公知事項のように、合意された契約に基づいてサービス品質を異なるものとすることに阻害要因はないから、引用例１発明の「加入者情報」として、上記公知の事項である、「契約」に含まれる「帯域幅」の情報を採用し、本願発明と同様の発明とすることに、格別の困難性は認められない。
（イ）［相違点２］について
　引用例１発明は、初期ＱｏＳポリシー構成は、ポリシーおよび課金ルール機能（ＰＣＲＦ）を含むポリシー機能が生成しており、また、ポリシーおよび課金ルール機能（ＰＣＲＦ）が、サービス品質であるＱｏＳを決定することは、引用例３乃至５に記載されているように、周知の事項である。
　そうすると、引用例１発明に、上記周知事項を適用し、ポリシー機能が初期ＱｏＳポリシー構成を生成する際に、ポリシー機能に含まれる、ポリシーおよび課金ルール機能（ＰＣＲＦ）がサービス品質であるＱｏＳを決定（制御）するようにすることに、格別の困難性は認められない。
　そして、本願発明の作用効果も、引用例１発明、および、公知の技術、並びに、周知の技術に基づいてから当業者が予測できる範囲のものである。
４．むすび
　以上のとおり、本願発明は、引用例１発明、および、公知の技術、並びに、周知の技術に基づいて、当業者が容易に発明をすることが出来たものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は他の請求項について検討するまでもなく拒絶されるべきものである。
　よって、結論のとおり審決する。