【事件の表示】
　特願２０１２−５５３４１８「ＰＣＣ／ＱＯＳ規則の生成」拒絶査定不服審判事件〔平成２３年　８月２５日国際公開、ＷＯ２０１１／１０１７４８、平成２５年　６月２０日国内公表、特表２０１３−５２６０９２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２３年(２０１１年)２月７日(優先権主張　２０１０年(平成２２年)２月１８日　米国)を国際出願日とする出願であって，平成２５年１０月２１日付けで拒絶の理由が通知され，平成２６年１月２８日付けで意見書とともに手続補正書の提出がなされ，同年２月１７日付けで拒絶査定され，同年６月２５日に拒絶査定不服審判の請求と同時に手続補正がなされたものである。
第２　補正却下の決定
［結論］
　平成２６年６月２５日付け手続補正を却下する。
［理由］
１．本件補正の概要
(１)　平成２６年６月２５日付け手続補正(以下「本件補正」という。)は，本件補正前(平成２６年１月２８日付け手続補正)の特許請求の範囲の次の記載を「＜本件補正後の＞」のように補正するものであり，その補正は次のとおりである。(下線は請求人が付与。)
＜本件補正前＞
　　【請求項１】
　少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成する目的で、アプリケーション要求メッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法であって、
　ＰＣＲＮにおいて、アプリケーション要求メッセージを受信するステップと、
　少なくとも１つの要求されたサービスフローをアプリケーション要求メッセージから決定するステップと、
　少なくとも１つの要求されたサービスフローの
うちの１つ
　
ポリシー決定結果のセットを生成するために、ポリシー決定を実行するステップであって、ポリシー決定が、アプリケーション要求メッセージ、既存のアプリケーションセッション、および加入者記録のうちの少なくとも１つに基づいている、実行するステップと、
　
ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正するステップと、
　
新
　　【請求項２】
　アプリケーション要求メッセージから加入者を識別するステップと、
　識別された加入者に対応する加入者記録を取り出すステップと、
　加入者記録に基づいて、新しいＰＣＣ規則を修正するステップと
をさらに含む、請求項１に記載の方法。
　　【請求項３】
　アプリケーション要求メッセージが、少なくとも１つの媒体構成要素を含み、少なくとも１つの要求されたサービスフローをアプリケーション要求メッセージから決定するステップが、
　それぞれの媒体構成要素に関して、少なくとも１つの要求されたサービスフローを媒体構成要素から決定するステップを含む、請求項１に記載の方法。
　　【請求項４】
　少なくとも１つの媒体構成要素が、少なくとも１つの媒体下位構成要素を含み、少なくとも１つの要求されたサービスフローを媒体構成要素から決定するステップが、
　それぞれの媒体下位構成要素に関して、要求されたサービスフローを媒体下位構成要素から決定するステップを含む、請求項
３
　　【請求項５】
　アプリケーション要求メッセージが、少なくとも１つのパケットフィルタ情報セクションを含み、少なくとも１つの要求されたサービスフローをアプリケーション要求メッセー
ジから決定するステップが、
　それぞれのパケットフィルタ情報セクションに関して、要求されたサービスフローをパケットフィルタ情報セクションから決定するステップを含む、請求項１に記載の方法。
　　【請求項６】
　アプリケーション要求メッセージが、ＱｏＳ情報セクションを含み、要求されたサービスフローをパケットフィルタ情報セクションから決定するステップが、
　要求されたサービスフローに関するＱｏＳ情報をＱｏＳ情報セクションから決定するステップを含む、請求項
５
　　【請求項７】
　少なくとも１つのパケットフィルタ情報セクションが、パケットフィルタ情報属性値の対（ＡＶＰ）およびＴＦＰパケットフィルタ情報ＡＶＰのうちの少なくとも１つを含む、請求項
５
　　【請求項８】
　
新
　媒体タイプをアプリケーション要求メッセージから決定するステップと、
　ＱｏＳクラス識別子（ＱＣＩ）を媒体タイプから決定するステップと、
　ＱＣＩを使用して、ＱｏＳ情報を生成するステップと、
　ＱｏＳ情報に基づいて、新しいＰＣＣ規則を修正するステップと
をさらに含む、請求項１に記載の方法。
　　【請求項９】
　
新
　ＰＣＣ規則からサービス品質（ＱｏＳ）部分を抽出するステップと、
　ＱｏＳ部分から新しいＱｏＳ規則を生成するステップと、
　新しいＱｏＳ規則をゲートウェイ制御ノードに送信するステップと
をさらに含む、請求項１に記載の方法。
＜本件補正後＞
　　【請求項１】
　少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成する目的で、アプリケーション要求メッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法であって、
　ＰＣＲＮにおいて、アプリケーション要求メッセージを受信するステップと、
　少なくとも１つの要求されたサービスフローをアプリケーション要求メッセージから決定するステップと、
　少なくとも１つの要求されたサービスフローのうちの１つの要求されたサービスフローに関して、アプリケーション要求メッセージに基づいて、新しいＰＣＣ規則を生成するステップと、
　ポリシー決定結果のセットを生成するために、ポリシー決定を実行するステップであって、ポリシー決定が、アプリケーション要求メッセージ、既存のアプリケーションセッション、および加入者記録のうちの少なくとも１つに基づいている、実行するステップと、
　ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正するステップと、
　新しいＰＣＣ規則をポリシーおよび課金施行ノード（ＰＣＥＮ）に提供するステップとを含
み
　
ポリシー決定を実行するステップは、新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、外部化された規則セットからの少なくとも１つのポリシー規則を評価するステップを含み、ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正するステップは、少なくとも１つのパラメータ値を新しいＰＣＣ規則に挿入するステップを含む、
　　【請求項２】
　アプリケーション要求メッセージから加入者を識別するステップと、
　識別された加入者に対応する加入者記録を取り出すステップと、
　加入者記録に基づいて、新しいＰＣＣ規則を修正するステップと
をさらに含む、請求項１に記載の方法。
　　【請求項３】
　アプリケーション要求メッセージが、少なくとも１つの媒体構成要素を含み、少なくとも１つの要求されたサービスフローをアプリケーション要求メッセージから決定するステップが、
　それぞれの媒体構成要素に関して、少なくとも１つの要求されたサービスフローを媒体構成要素から決定するステップを含む、請求項１に記載の方法。
　　【請求項４】
　少なくとも１つの媒体構成要素が、少なくとも１つの媒体下位構成要素を含み、少なくとも１つの要求されたサービスフローを媒体構成要素から決定するステップが、
　それぞれの媒体下位構成要素に関して、要求されたサービスフローを媒体下位構成要素から決定するステップを含む、請求項３に記載の方法。
　　【請求項５】
　アプリケーション要求メッセージが、少なくとも１つのパケットフィルタ情報セクションを含み、少なくとも１つの要求されたサービスフローをアプリケーション要求メッセージから決定するステップが、
　それぞれのパケットフィルタ情報セクションに関して、要求されたサービスフローをパケットフィルタ情報セクションから決定するステップを含む、請求項１に記載の方法。
　　【請求項６】
　アプリケーション要求メッセージが、ＱｏＳ情報セクションを含み、要求されたサービスフローをパケットフィルタ情報セクションから決定するステップが、
　要求されたサービスフローに関するＱｏＳ情報をＱｏＳ情報セクションから決定するステップを含む、請求項５に記載の方法。
　　【請求項７】
　少なくとも１つのパケットフィルタ情報セクションが、パケットフィルタ情報属性値の対（ＡＶＰ）およびＴＦＰパケットフィルタ情報ＡＶＰのうちの少なくとも１つを含む、請求項５に記載の方法。
　　【請求項８】
　新しいＰＣＣ規則に関して、
　媒体タイプをアプリケーション要求メッセージから決定するステップと、
　ＱｏＳクラス識別子（ＱＣＩ）を媒体タイプから決定するステップと、
　ＱＣＩを使用して、ＱｏＳ情報を生成するステップと、
　ＱｏＳ情報に基づいて、新しいＰＣＣ規則を修正するステップと
をさらに含む、請求項１に記載の方法。
　　【請求項９】
　新しいＰＣＣ規則に関して、
　ＰＣＣ規則からサービス品質（ＱｏＳ）部分を抽出するステップと、
　ＱｏＳ部分から新しいＱｏＳ規則を生成するステップと、
　新しいＱｏＳ規則をゲートウェイ制御ノードに送信するステップと
をさらに含む、請求項１に記載の方法。
(２)　本件補正は，請求項１に関し，１本件補正前の「ポリシー決定結果のセットを生成するために、ポリシー決定を実行するステップであって、ポリシー決定が、アプリケーション要求メッセージ、既存のアプリケーションセッション、および加入者記録のうちの少なくとも１つに基づいている、実行するステップ」における「ポリシー決定を実行するステップ」に対し，該「ポリシー決定を実行するステップ」は「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、外部化された規則セットからの少なくとも１つのポリシー規則を評価するステップを含み」とする事項(以下「本件補正事項１」という。)と，２本件補正前の「ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正するステップ」に対し，該「ステップ」は「少なくとも１つのパラメータ値を新しいＰＣＣ規則に挿入するステップを含む」とする事項(以下「本件補正事項２」という。)とを，それぞれ附加するものである。
　そして，上記本件補正事項１及び２は，本件補正前の請求項１に係る発明を特定する事項である「ポリシー決定を実行するステップ」，「ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正するステップ」を，それぞれ限定するものであると一応いえる。
　そうすると，本件補正後の請求項１に記載された事項により特定される発明は，特許出願の際独立して特許を受けることができるものでなければならない。そこで，本件補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するか否かについて検討する。
２．検討
(１)　本件補正事項１について
　本件補正後における請求項１の記載によれば，「ポリシー決定を実行するステップ」における「ポリシー決定」は，
あ「ポリシー決定結果のセットを生成するために」実行されるものであり，
い「アプリケーション要求メッセージ、既存のアプリケーションセッション、および加入者記録のうちの少なくとも１つ」に基づくものであり，
う「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、外部化された規則セットからの少なくとも１つのポリシー規則を評価する」ものである
と解される。
　ここで，上記うは，要するに，「ポリシー規則」を「評価する」ことによって，「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定する」ことを技術的に意図していると解することができる。
　また，上記うによれば，該「ポリシー規則」は「外部化された規則セットからの」ものであることを意味していると解される。
　そして，「外部化された規則セット」が，「規則セット」を「外部化する」あるいは「外部化した」ことを意味することは明白であるところ。
　「外部化」とは「内部」にあった状態から「外部」にあるようにすることを意味すると解するのが自然である。
　そうすると，「外部化された規則セット」とは，「規則セット」が
内部
外部
　しかし，該「規則セット」がどのようなものの内部にあったのか，あるいはどのようなものの外部となったのかは，本件補正後の請求項１の記載のみでは特定することができない。
　このことは，本件補正後の請求項１に記載された発明を特定する事項である「外部化された規則セット」が明確でないことを示している。
　つまり，本件補正後の請求項１に係る発明は明確でないことを示している。
　そこで，該「外部化された規則セット」の技術的意味について，更に検討する。
(２)　審判請求書における補正の説明
　請求人は，審判請求書の【補正の説明】及び【本願発明と引用発明との対比】において，本件補正に関する記載をしている。
　ここで，該記載を確認する(下線は当審が付与)。
ア　【補正の説明】における記載事項
　同日付け手続補正により、補正前の（平成２６年１月２８日付け手続補正書の）請求項１に、「ポリシー決定を実行するステップは、新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、
外部化された規則セット
この補正は、本願明細書段落［００３７］、［００６８］等の記載に基づく
イ　【本願発明と引用発明との対比】における記載
　審査官は、「引用文献１には、ユーザが使用しているＵＥの能力を取得し、サービスがＵＥ能力によって効果的にサポートされるように事前設定されたルールがフィルタされ、その結果生じたルールはＰＣＥＦに送信されることが記載されており、ポリシー決定を加入者記録に基づいて実行し、ポリシー決定結果のセットに基づいて、新しいＰＣＣ規則を修正することが開示されている」と認定されていた。
　しかしながら、引用文献１は、補正後の請求項１に記載の「ポリシー決定を実行するステップは、新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、
外部化された規則セット
　引用文献２〜６は、いずれも、請求項１に係る発明と引用文献１に記載の発明との間の上記差異を埋めるものではない。
　してみれば、いかに当業者が引用文献１〜６の記載を参酌したとしても、請求項１に係る発明を容易に想到できようはずがなく、請求項１に係る発明は引用文献１〜６に記載された発明に基づいて、当業者が容易に発明をすることができたものではない。
(３)　審判請求書における【補正の説明】の記載によれば，本件補正は，専ら，本件出願の明細書【００３７】及び【００６８】における記載を基にしていると解される。
　そこで，上記【００３７】及び【００６８】における記載を確認する。
　なお，【００３７】及び【００６８】は，補正も誤訳訂正書の提出による補正もなされていない。
ア　【００３７】における記載事項
　ポリシー決定規則修正器２５０は、
ポリシー決定モジュール２４０
イ　【００６８】における記載事項
(ア)　次いで、ステップ８２０において、
ポリシー決定モジュール２４０
ポリシー決定モジュール２４０
外部化された規則セット
(イ)　上記【００６８】における記載によれば，「外部化された規則セット」は，「ポリシー決定モジュール２４０」において「適用可能なパラメータ値のセット」を決定するために，利用されるものであると解される。
　そして，同じく【００６８】における記載からは「ポリシー決定モジュール２４０」は「パラメータ値のセット」を「アプリケーション要求、既存のアプリケーションセッション、加入プロファイルデータ、および／またはポリシー規則」から「パラメータ」を生成することの記載を読み取ることができるにとどまり，上記「アプリケーション要求、既存のアプリケーションセッション、加入プロファイルデータ、および／またはポリシー規則」が「外部化された規則セット」における「規則セット」に相当するとも解されるが，「外部化された」とまでいうことができるか否かは不明である。
　そして，「外部化された規則セット」との直接的記載は，本件出願の明細書【００６８】に存在するにとどまるところ，上記した「ポリシー決定モジュール２４０」との記載は，同【００３６】に発見したので，その記載を確認する。
エ　【００３６】における記載事項
(ア)　
ポリシー決定モジュール２４０
ポリシー決定モジュール２４０
規則記憶装置２６０内またはその他の場所（図示せず）に記憶されたポリシー決定規則
ポリシー決定モジュール２４０
ＳＰＲ１３８など、ＳＰＲから取り出された加入者データおよび／または既存のアプリケーションセッションに関するデータ
ポリシー決定モジュール２４０
(イ)　上記【００３６】における記載によれば，「ポリシー決定モジュール２４０」は，「規則記憶装置２６０内またはその他の場所（図示せず）に記憶されたポリシー決定規則」，「ＳＰＲ１３８など、ＳＰＲから取り出された加入者データおよび／または既存のアプリケーションセッションに関するデータ」(当審注　「ＳＰＲ」とは「加入プロファイルリポジトリ」(Subscription profile repository)を意味する。本件明細書【００１７】，【００２３】参照。)を利用し，ポリシー決定を行っていると解することができる。
　この解釈によれば，「ポリシー決定規則」，「加入者データおよび／または既存のアプリケーションセッションに関するデータ」が，「外部化された規則セット」における「規則セット」に相当すると解される。
　そうすると，「外部化された規則セット」における「外部化」とは，１「規則記憶装置２６０内」のものを利用すること，２その他の場所に「記憶された」ものを利用すること，３「ＳＰＲ１３８」から取り出すこと，のうちのいずれか，若しくは１ないし３のうちの少なくとも一の事項を意味しているとも解することができる。
オ　しかし，本件補正後の請求項１の記載には，上記１における「規則記憶装置２６０」，上記２における「「記憶された」その他の場所」，上記３における「ＳＰＲ１３８」に関する記載も示唆も発見しない。
　このことは，本件補正後の請求項１に記載された発明において，「外部化された規則セット」，つまり「規則セット」を「外部化」することが明確でないことを示している。
　したがって，本件補正後の請求項１に記載された発明は明確でない。
(３)　小活
　よって，本件補正後の請求項１に記載された発明は，特許法第３６条第６項第２号に規定する要件を満たしていないので，特許出願の際独立して特許を受けることができないものである。
(４)　追加的判断
ア　仮に，本件補正後の請求項１に記載された「外部化された規則セット」における「外部化」が，「記憶装置からの読み出し」，「ＳＰＲからの取り出し」のように解することができ，この点で，特許法第３６条第６項第２号に規定する要件を満たしているといえたとしても，以下の理由によって，上記した「特許法第３６条第６項第２号に規定する要件を満たしていないので，特許出願の際独立して特許を受けることができないものである」とした判断に影響を及ぼすものでない。
イ　本件補正によって，本件補正前の請求項１に記載された「ポリシー決定を実行するステップ」は，さらに「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために、外部化された規則セットからの少なくとも１つのポリシー規則を評価するステップ」を含むものとなった。
　ここで，「ポリシー決定を実行するステップ」に含まれる「評価するステップ」とは，要するに「外部化された規則セット」からの「ポリシー規則」を「評価する」ステップであり，該「評価する」ことによって「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定する」ことになると解される。
　このことは，つまり「外部化された規則セット」からの「ポリシー規則」を「評価する」ことによって，「新しいＰＣＣ規則」に挿入すべき「パラメータ値」を「決定する」ことを示しているといえる。
　しかし，本件補正前及び本件補正後における請求項１の記載をみても，「ポリシー規則」と「パラメータ値」との関係を特定する記載も，「外部化された規則セット」と「パラメータ値」との関係を特定する記載も発見しない。
　以上のことは，本件補正後の請求項１に記載された発明において，「外部化された規則セットからのポリシー規則を評価する」ことによって「新しいＰＣＣ規則に挿入すべきパラメータ値を決定する」ことが不明確であるといわざる得ないこと，つまり，「新しいＰＣＣ規則に挿入すべき少なくとも１つのパラメータ値を決定するために，外部化された規則セットからの少なくとも１つのポリシー規則を評価する」ことが明確でないといわざるを得ないことを示している。
　したがって，本件補正後の請求項１に記載された発明は明確でないといわざるを得ない。
ウ　追加的判断のまとめ
　以上のとおりであるから，上記したように，仮に，本件補正後の請求項１に記載された「外部化された規則セット」における「外部化」が，「記憶装置からの読み出し」，「ＳＰＲからの取り出し」のように解することができたとしても，本件補正後の請求項１に記載された発明は，特許法第３６条第６項第２号に規定する要件を満たしていないので，特許出願の際独立して特許を受けることができない。
３．補正却下の決定のまとめ
　以上に述べたとおりであるから，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明
　上記「第２」に述べたとおり，本件補正は却下された。
　よって，本件出願の請求項１に係る発明(以下「本願発明」という。)は，上記「第２」の[理由]の「１．本件補正の概要」の「本件補正前」における【請求項１】に記載された事項により特定されるとおりのものである。
第４　引用発明
　原査定の理由に引用文献１として引用された国際公開第２００８／０５５５４１号(２００８年(平成２０年)５月１５日国際公開。以下「引用文献」と表記する。)には，図面とともに次の事項が記載されている。
(なお，当審訳として，引用文献に対応する日本語公報の特表２０１０−５０８７３８号公報(平成２２年３月１８日公表)を参考する。)
１．[0001] The present invention generally relates to service requirements negotiated through a signalling layer, whereas said services are actually carried through a connectivity or bearer layer. In particular, the invention applies in scenarios where control rules are installed at the bearer layer for guaranteeing the service requirements for any user equipment.
(１ページ)
(当審訳
[０００１]【０００１】
　本発明は一般に、信号層を通じて交渉されるサービス要求条件であって、サービスは実際には接続層またはベアラ層を通じて伝わるサービス要求条件に関する。本発明は特に、任意のユーザ装置に対してサービス要求条件を保証するために、ベアラ層において制御ルールが導入されるシナリオに適用される。
(【０００１】))
２．[0004] On the other hand, a common architecture called Policy and Charging Control (hereinafter PCC) is being currently developed under 3GPP TS 23.203 V2.0.0. This PCC is supposedly addressing all different types of access networks and is intended to control how media transported through the bearer layer is treated in view of corresponding service requirements negotiated through the signalling layer. In other words, the basic PCC architecture is suitable for being applied in scenarios where services are negotiated through the signalling layer, between user equipments and servers in the control plane; whereas said services are actually carried through the connectivity or bearer layer, possibly between originating and destination user equipments. 
[0005] In accordance with 3GPP TS 23.203, the PCC architecture includes a so-called Policing and Charging Rules Function (hereinafter PCRF) in charge of defining network control for detection of particular IP flows associated with a given service, making decisions based on information received from the signalling layer by creating control rules to enforce the negotiated service requirements into the bearer layer, as well as notifying the service layer about significant events occurred in the bearer layer for the given service. This PCRF is preferably located in an intermediate entity enabled to communicate with a first entity in the control plane and with a second entity in the traffic plane. The PCC architecture also includes a so-called Policing and Charging Enforcement Function (hereinafter PCEF) in charge of detecting those particular IP flows associated with a given service, and 
enforcement at the bearer layer of those service requirements negotiated through the signalling layer by installing the above control rules received from the PCRF
The AF communicates with the PCRF to transfer dynamic session information, namely service information including the negotiated service requirements, required for PCRF decisions and for creation of the control rules
(２ページ〜３ページ)
(当審訳
[０００４]【０００４】
　一方、ポリシー及び課金制御(以下、ＰＣＣ)と呼ばれる共通のアーキテクチャが現在、３ＧＰＰのＴＳ２３.２０３ Ｖ２.０.０のもとで開発されている。このＰＣＣはすべての異なる種類のアクセスネットワークに対応しているといわれていて、ベアラ層を通じて輸送されるメディアが、シグナリング層を通じて交渉された対応するサ−ビス要求条件の観点でどのように扱われるかを制御することが意図される。言い換えると、基本的なＰＣＣアーキテクチャはユーザ装置と制御プレーン内のサーバとの間でシグナリング層を通じてサービスが交渉されるシナリオに適用されるのに適している。ここで、当該サービスは実際には接続層またはベアラ層を通じて、おそらくは発信ユーザ装置と宛先ユーザ装置との間で伝わる。
[０００５]【０００５】
　３ＧＰＰのＴＳ ２３.２０３に従うと、ＰＣＣアーキテクチャは、所与のサービスに関連付けられた特定のＩＰフローを検出するためのネットワーク制御を定義することを担当するいわゆるポリシー及び課金ルール機能(以下、ＰＣＲＦ)を含み、交渉されたサービス要求条件をベアラ層に施行する制御ルールを生成することによってシグナリング層から受信した情報に基づく決定を行い、さらに当該所与のサービスのためにベアラ層で発生した重大なイベントについてサービス層に通知する。このＰＣＲＦは好適には制御プレーン内の第１のエンティティとトラフィック・プレーン内の第２のエンティティとに通信可能な中間のエンティティ内に配置される。ＰＣＣアーキテクチャはまた、所与のサービスに関連付けられたこの特定のＩＰフローを検出することと、
ＰＣＲＦから受信した上記の制御ルールを導入することによりシグナリング層を通じて交渉されたサービス要求条件をベアラ層におけて施行すること
ＰＣＥＦおよびＰＣＲＦとは別に、ＰＣＣアーキテクチャはまた、ＩＰベアラのリソースの制御を要求するアプリケーションを提供するアプリケーション機能（以下、ＡＦ）を含む。特に、ＡＦは、交渉されたサービス要求条件を知っている制御プレーン内のサーバ内に存在してもよいし、当該サーバの一部分であってもよい。ＡＦは、ＰＣＲＦの決定のため及び制御ルールの生成のために要求される交渉された動的セッション情報、つまりサービス要求条件を含むサービス情報を転送するためにＰＣＲＦと通信する
３．[0017] The above objects are generally 
accomplished in accordance with the invention by providing a control server enabled to act as a PCRF 
[0018] 
This control server comprises a first receiver enabled to interface with an entity in the bearer layer, and arranged for receiving information about establishment of a bearer for bearing the service-related IP flows for a given user; and a second receiver enabled to interface with an entity in the signalling layer, and arranged for receiving service information about the media including those service requirements negotiated for the service
[0019] Regarding the entity in the bearer layer which informs the control server about the establishment of a bearer, such entity may be a GGSN where the IP-CAN is a GPRS network or a PDG where the IP-CAN is a WLAN network, or rather a PCEF in accordance with the PCC architecture, which may be included in the GGSN or PDG. 
[0020] Regarding the entity in the signalling layer which submits information about the media including the negotiated service requirements, such entity may be a P-CSCF where the user has accessed an IMS network, or an AS where the user has accessed, for example, a video streaming server for downloading video, or rather an AF in accordance with the PCC architecture, which may be included in the P-CSCF or AS. 
[0021] 
This control server also comprises in accordance with an aspect of the invention a capabilities handler arranged for obtaining UE capabilities of a user equipment currently used by the given user; a processor arranged for determining control rules to apply for guaranteeing the service requirements into the bearer, said control rules based on the service information received from the entity in the signalling layer, including the negotiated service requirements, and based on the UE capabilities of the user equipment; and an installer arranged for, depending on the UE capabilities of the user equipment, either submitting the control rules to be installed towards an entity enabled to act as a PCEF in the bearer layer, or waiting for establishment of a subsequent bearer to install the control rules therein. In this respect, both GGSN and PDG may be entities enabled to act as a PCEF, whereas both P-CSCF and AS may be entities enabled to act as an AF
[0022] The capabilities handler in this control server may obtain the UE capabilities from an external UE capabilities repository or from a local UE capabilities repository. The former may require the inclusion of a protocol handler in the capabilities handler to facilitate such external communication. Therefore, both capabilities handler in the control server and UE capabilities repository are arranged for respectively obtaining and providing at least one UE capability selected from a group of UE capabilities comprising: QoS management; supported services per user equipment; maximum number of bearers to be subsequently established; and supported QoS model. 
(６ページ〜８ページ)
(当審訳
[００１７]【００１７】
　上記目的は一般に、本発明に従って、シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラに保証する、
ＰＣＲＦとして動作可能である制御サーバを提供することによって達成される
[００１８]【００１８】
　
この制御サーバは、ベアラ層内のエンティティとインタフェースで接続可能であり、所与のユーザに対するサービス関連のＩＰフローを運ぶためのベアラの確立に関する情報を受信するように構成された第１の受信器と、シグナリング層内のエンティティとインタフェースで接続可能であり、サービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報を受信するように構成された第２の受信器とを備える
[００１９]【００１９】
　制御サーバにベアラの確立について知らせるベアラ層内のエンティティに関して、このようなエンティティは、ＩＰ−ＣＡＮがＧＰＲＳネットワークである場合にＧＧＳＮであってもよいし、ＩＰ−ＣＡＮがＷＬＡＮネットワークである場合にＰＤＧであってもよいし、もっと正確には、ＧＧＳＮまたはＰＤＧに含まれてもよい、ＰＣＣアーキテクチャに従うＰＣＥＦであってもよい。
[００２０]【００２０】
　交渉されたサービス要求条件を含むメディアに関する情報を送出するシグナリング層内のエンティティに関して、このようなエンティティは、ユーザがＩＭＳネットワークにアクセスしていた場合にＰ−ＣＳＣＦであってもよいし、ユーザが例えばビデオをダウンロードするためのビデオ・ストリーミング・サーバにアクセスしていた場合にＡＳであってもよいし、もっと正確には、Ｐ−ＣＳＣＦまたはＡＳに含まれてもよい、ＰＣＣアーキテクチャに従うＡＦであってもよい。
[００２１]【００２１】
　
本発明の態様に従って、この制御サーバはまた、所与のユーザにより現在使用されているユーザ装置についてのＵＥ能力（ｃａｐａｂｉｌｉｔｙ）を取得するように構成された能力ハンドラと、サービス要求条件をベアラに保証するために適用される制御ルールを決定するように構成されたプロセッサであって、当該制御ルールは交渉されたサービス要求条件を含み且つシグナリング層内のエンティティから受信されたサービス情報に基づき、且つユーザ装置についてのＵＥ能力に基づくプロセッサと、ユーザ装置のＵＥ能力に応じて、ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティに向けて導入される制御ルールを送出するか、制御ルールをそこに導入するための後続するベアラの確立を待つか、のいずれかを行うように構成されたインストーラとを備える。この点において、ＧＧＳＮとＰＤＧとの両方ともがＰＣＥＦとして動作可能なエンティティであってもいい一方で、Ｐ−ＣＳＣＦとＡＳとの両方ともがＡＦとして動作可能なエンティティであってもよい
[００２２]【００２２】
　この制御サーバ内の能力ハンドラは、外部のＵＥ能力レポジトリから、またはローカルのＵＥ能力レポジトリから、ＵＥ能力を取得してもよい。このような外部との通信を容易にするために、前者は能力ハンドラ内にプロトコル・ハンドラを含むことを要求するかもしれない。従って、制御サーバ内の能力ハンドラとＵＥ能力レポジトリとの両方が、ＱｏＳ管理、ユーザ装置ごとのサポートされるサービス、続いて確立されるベアラの最大数、およびサポートされるＱｏＳモデルを含むＵＥ能力群から選択された少なくとも一つのＵＥ能力をそれぞれ取得し提供するように構成される。
(【００１７】〜【００２２】))
４．[0035] The sequence of actions in this FIG. 2 starts when an entity 32 in the bearer layer, namely a PCEF which may be included in a GGSN 21 where the IP-CAN is a GPRS network or in a PDG 51 where the IP-CAN is a WLAN network as illustrated in FIGS. 5 and 6, submits in step 
S-121
S-121
[0036] To this end, 
the control server 31
[0037] At this stage, 
the control server 31
at the control server
the control server 31
the preconfigured rules can be advantageously filtered to assess that the supposedly supported services are effectively supported by the UE capabilities of the UE currently in use by the user
These preconfigured rules indicating services supported by the UE capabilities is an advantageous achievement over the currently existing mechanism since the services supported by the user subscription may be not supported by the UE currently in use by the user
[0038] To this end, 
the control server 31
the control server 31 may also include an installer 314, which amongst other tasks further commented, is also arranged for submitting in step S-124, towards the entity 32 acting as a PCEF, those resulting preconfigured rules indicating those services supported by the UE capabilities for the established bearer
the UE capabilities of user equipments obtainable from the capabilities handler 315 include information about those services supported per user equipment
the control server 31
[0039] In one embodiment of the invention illustrated in Fig. 4, 
the control server 31
[0040] In another embodiment of the invention illustrated in Fig. 3, the capabilities handler 315 
included in the control server 31
[0041] In accordance with embodiments of the invention, the UE capabilities repository 316 is arranged for providing UE capabilities of user equipments 11, 12 in use by a number of users. To this end, the UE capabilities repository has storage 3161 for the UE capabilities per user basis and a configuration unit 3162 for being provisioned with the UE capabilities of the user equipments 11, 12. In particular, the configuration unit 3162 may be provisioned with UE capabilities through an interface I-50 from a network operator provisioning system, or may as well be connected with dedicated configuration servers under premises of UE suppliers for being provisioned with UE capabilities on an equipment model basis. Where the UE capabilities repository 316 is provided as a local entity 
included in the control server 31
[0042] Once the entity 32 acting as a PCEF, which in particular may be the GGSN 21 where the IP-CAN is a GPRS network or the PDG 51 where the IP-CAN is a WLAN network as illustrated in Fig. 5 and 6, has received the preconfigured rules in step S-124 as illustrated in Fig. 2, the GGSN 21 or PDG 51 confirms towards the user the establishment of such bearer, and the user can start the negotiation of media through the signalling layer, namely through the AF 33 in accordance with the PCC architecture, at the control plane as illustrated in Fig. 5 and 6. 
[0043] The sequence of actions in Fig. 2 continues once the service requirements for the media have been negotiated through the AF 33 in the signalling layer, and 
the AF submits in step S-125 service information about the media, including those service requirements negotiated for the service, towards the control server 31
[0044] 
Once the service information about the media, including those service requirements negotiated for the service, has been received at the control server 31 during step S-125, the control server determines during step S-126 those control rules to apply for guaranteeing the service requirements into the bearer, the control rules being based on the service information received from the entity in the signalling layer, namely from the AF 33, and including the negotiated service requirements, and the control rules being also based on the UE capabilities of the user equipment 11 currently in use by the user, as likely obtained from the UE capabilities repository 316 in step S-123
[0045] To this end, the control server 31 includes as illustrated in Fig. 3 and 4, a second receiver 312 enabled to interface with an entity 33 acting as an AF in the signalling layer, which in particular may be a P-CSCF 41 or an AS 61 as illustrated in Fig. 5 and 6, this second receiver 312 being arranged for receiving service information about the media, including those service requirements negotiated for the service. 
The control server 31 also includes a processor 313 arranged for determining in step S-126 said control rules based on the service information, including the negotiated service requirements, received from the AF 33, and also based on the UE capabilities of the user equipment 11 currently in use by the user
[0046] Particularly applicable for this and other purposes, the UE capabilities obtainable per user equipment by the capabilities handler 315 include information about QoS management, which offers information to derive the QoS class; maximum number of bearers to be subsequently established that the UE can support; and the supported QoS model, which may be network-initiated (hereinafter NW-initiated) or UE-initiated. 
Regarding the information about QoS management, the service information received from the AF in step S-125 may, for example, indicate that the media type is 'video' and it corresponds to QoS class 'conversational', whereas the service information may also indicate that QoS class 'conversational' is not supported; in this situation, the media type 'video' is made correspond to QoS class 'streaming' provided that such QoS class 'streaming' is supported by the UE capabilities for the UE, since the mapping is preferably performed to the highest QoS class supported by the UE capabilities
[0047] 
The step S-126 of determining at the control server 31 the control rules to apply may offer two different outcomes depending on the UE capabilities of the UE 11 presently in use by the given user. On the one hand, the obtained UE capabilities may indicate that the UE is enabled to request the establishment of a subsequent bearer according to the service requirements. In order to determine whether a subsequent bearer can be established, the control server 31 may check whether the maximum number of bearers to be subsequently established, as indicated by the UE capabilities, has been already reached. If the control server finds out that this maximum had been reached, the UE can not request the establishment of a subsequent bearer and the control rules are installed in step S-127 for the bearer presently established at the PCEF 32, as illustrated in Fig. 2
On the other hand, as an alternative embodiment, if the UE capabilities indicate that the NW-initiated model is supported, the control server 31 may submit the control rules in step S-127 towards the PCEF 32 in the bearer layer along with an indication to either request the establishment of a new subsequent bearer and installing said control rules for the new subsequent bearer once established, if the maximum had not been reached yet; or install said control rules in the presently established bearer where the maximum had been already reached
(１０ページ〜１６ページ)
(当審訳
[００３５]【００３０】
　図２における一連の動作は、ベアラ層におけるエンティティ３２、すなわち図５および図６に説明されるようなＩＰ−ＣＡＮがＧＰＲＳネットワークであるＧＧＳＮ２１に含まれてもよいし、又はＩＰ−ＣＡＮがＷＬＡＮネットワークであるＰＤＧ５１に含まれてもよいＰＣＥＦは、
ステップＳ−１２１で、制御サーバ３１に向けて、所与のユーザに対するサービス関連のＩＰフローを運ぶベアラの確立に関する情報を、このようなベアラのための制御ルールを依頼するために送出することで始まる
[００３６]【００３１】
　この目的のために、図３および図４に説明されるように、
制御サーバ３１は、
[００３７]【００３２】
　この段階において、
制御サーバ３１は、
制御サーバにおいて、
制御サーバ３１が
サポートされると想定されるサービスが、ユーザにより現在使用されているＵＥのＵＥ能力によって効果的にサポートされることを評価するため
ユーザ加入契約によりサポートされるサービスはユーザにより現在使用されているＵＥによってサポートされないかもしれないからである
[００３８]【００３３】
　この目的のために、
制御サーバ３１は、
制御サーバ３１はまた、インストーラ３１４を含んでもよい。ここで、インストーラ３１４は他のタスクの中でさらに言及され、ステップＳ−１２４においてＰＣＥＦとして動作するエンティティ３２に向けて送出するように構成され、この結果生じる事前設定されたルールは確立されたベアラに対してＵＥ能力によってサポートされるサービスを示す
能力ハンドラ３１５から取得できるユーザ装置のＵＥ能力はユーザ装置ごとのサポートされるサービスに関する情報を含む
制御サーバ３１
[００３９]【００３４】
　図４に説明される本発明のある実施形態では、
制御サーバ３１は
[００４０]【００３５】
　図３に説明される本発明の別の実施形態では、
制御サーバ３１に含まれる
[００４１]【００３６】
　本発明の実施形態によれば、ＵＥ能力レポジトリ３１６は複数のユーザにより使用されるユーザ装置１１、１１２のＵＥ能力を提供するように構成される。この目的のために、ＵＥ能力レポジトリはユーザ単位のＵＥ能力のための記憶装置３１６１とユーザ装置１１、１２のＵＥ能力の供給を受けるための構成ユニット３１６２とを有する。特に、構成ユニット３１６２はシステムを供給するネットワーク事業者からインタフェースＩ−５０を通じてＵＥ能力を供給されてもよいし、装置モデルベースでＵＥ能力が供給されるＵＥサプライヤの前提のもとで専用の構成サーバに接続されてもよい。上記で言及され図４で説明される実施形態に従って、ＵＥ能力レポジトリ３１６が
制御サーバ３１に含まれる
[００４２]【００３７】
　図５および図６で説明されるように、特にＩＰ−ＣＡＮがＧＰＲＳネットワークである場合にＧＧＳＮ２１であってもよく、ＩＰ−ＣＡＮがＷＬＡＮネットワークである場合にＰＤＧ５１であってもよいＰＣＥＦとして動作するエンティティ３２が、図２で説明されるようにステップＳ−１２４において事前設定されたルールをひとたび受信すると、ＧＧＳＮ２１またはＰＤＧ５１はユーザに向けてこのようなベアラの確立を確認応答し、ユーザは、図５および図６に説明されるような制御プレーンにおいて、シグナリング層を通じて、つまりＰＣＣアーキテクチャに従えばＡＦ３３を通じてメディアの交渉を開始できる。
[００４３]【００３８】
　メディアに対するサービス要求条件がシグナリング層のＡＦ３３を通じてひとたび交渉されると、図２の一連の動作は継続し、
ステップＳ−１２５でＡＦはサービスについて交渉されるサービス要求条件を含むメディアに関する情報を制御サーバ３１に向けて送出する
[００４４]【００３９】
　
サービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報がステップＳ−１２５の間に制御サーバ３１においてひとたび受信されると、制御サーバはステップＳ−１２６の間にサービス要求条件をベアラに保証するために適用する制御ルールを決定する。制御ルールはシグナリング層内のエンティティすなわちＡＦ３３から受信したサービス情報に基づいており、交渉されたサービス要求条件を含む。制御ルールはまた、ステップＳ−１２３でＵＥ能力レポジトリ３１６から取得されているであろう、ユーザにより現在使用されているユーザ装置１１のＵＥ能力に基づく
[００４５]【００４０】
　この目的のために、図３および図４に説明されるように、制御サーバ３１は、シグナリング層のＡＦとして動作するエンティティ３３とインタフェースで接続可能な第２の受信器３１２を含む。ＡＦは特に図５および図６において説明されるようにＰ−ＣＳＣＦ４１またはＡＳ６１であってもよい。この第２の受信器３１２はサービスについて交渉されたサービス要求条件を含むメディアに関するサービス情報を受信するように構成される。
制御サーバ３１はまた、ＡＦ３３から受信され、交渉されたサービス要求条件を含むサービス情報に基づき、且つユーザにより現在使用されているユーザ装置のＵＥ能力にも基づく当該制御ルールをステップＳ−１２６において決定するように構成されたプロセッサ３１３を含む
[００４６]【００４１】
　この目的および他の目的のために特に適用できるように、能力ハンドラ３１５によりユーザ装置ごとに取得可能なＵＥ能力は、ＱｏＳクラスを引き出すための情報を提供するＱｏＳ管理に関する情報と、後続に確立されるベアラをＵＥがサポートできる最大数と、ネットワーク主導（以下、ＮＷ主導）であってもよいしＵＥ主導であってもよいサポートされるＱｏＳモデルと、を含む。
ＱｏＳ管理に関する情報について、ステップＳ−１２５でＡＦから受信された情報は、例えば、メディアタイプが「ビデオ」であることを示してもよく、これはＱｏＳクラス「会話型」に対応する。一方で、サービス情報はまた、ＱｏＳクラス「会話型」がサポートされないことを示してもよい。この状況では、このようなＱｏＳクラス「ストリーミング型」がＵＥに対するＵＥ能力によりサポートされるという条件で、メディアタイプ「ビデオ」はＱｏＳクラス「ストリーミング型」に対応付けされる
[００４７]【００４２】
　
適用する制御ルールを制御サーバ３１において決定するステップＳ−１２６は、所与のユーザにより現在使用されているＵＥ１１のＵＥ能力に基づいて二つの異なる結果を提供してもよい。一方の結果においては、取得されたＵＥ能力は、ＵＥがサービス要求条件に従って後続するベアラの確立を要求できることを示してもよい。後続するベアラが確立され得るかどうかを決定するために、制御サーバ３１は、ＵＥ能力に示されるような、後続して確立されるベアラの最大数にすでに到達しているかどうかを調べてもよい。この最大数に到達していることを制御サーバが見つけた場合に、ＵＥは後続するベアラの確立を要求することができず、図２に示されるように、ステップＳ−１２７で、ＰＣＥＦ３２において現在確立されているベアラに対してルールが導入される
一方、代替の実施形態として、ＮＷ始動のモデルがサポートされることをＵＥ能力が示す場合に、制御サーバ３１はステップＳ−１２７において、最大数にまだ到達していない場合に新たな後続するベアラの確立と当該新たな後続するベアラに対する当該制御ルールの導入とを要求するか、最大数にすでに到達している場合に現在確立されているベアラ内に当該制御ルールを導入することか、のいずれかを行うことの指標とともに、ベアラ層内のＰＣＥＦ３２に向けて制御ルールを送出してもよい
(【００３１】〜【００４２】)）
４．[0049] In another embodiment of the invention, the installer 314 is arranged for submitting, towards the entity 32 enabled to act as a PCEF in the bearer layer, the control rules to be installed either with an indication to install said control rules for the currently established bearer, where the maximum number of bearers to be subsequently established has been already reached; or 
with an indication to request establishment of a new subsequent bearer and installing said control rules for the new subsequent bearer once established
[0050] As already commented above, the installer 314 may be provided as a separate module in the control server 31 as exemplary shown in FIG. 4, or integrated into the Input/Output module 317 as exemplary shown in FIG. 3. 
[0051] This new behaviour at the control server 31, which in particular may be the PCRF of a PCC architecture, thus accomplishes the objects of the invention as identified above. Where the control server 31 is implemented with features of the PCRF, 
the control rules referred to throughout this specification may include other significant fields and parameters as those included in the so-called PCC rules as specified by 3GPP TS 23.203
(１６ページ〜１７ページ)
(当審訳
[００４９]【００４４】
　本発明の別の実施形態では、インストーラ３１４は、ベアラ層においてＰＣＥＦとして動作することができるエンティティ３２に向けて、後続して確立されるベアラの最大数にすでに到達している場合には現在確立されているベアラに対する当該制御ルールを導入することの指標とともに、または、後続して確立されるベアラの最大数にまだ到達していない場合には
新たな後続するベアラの確立とひとたび確立されたこの後続するベアラに対する当該制御ルールの導入とを要求することの指標とともに、導入される制御ルールを送出する
[００５０]【００４５】
　すでに前述したように、インストーラ３１４は図４に示された例のように制御サーバ３１内の分離したモジュールとして提供されてもよいし、図３に示された例のように入出力モジュール３１７に統合されてもよい。
[００５１]【００４６】
　従って、特にＰＣＣアーキテクチャのＰＣＲＦであってもよい制御サーバ３１におけるこの新たな振る舞いは、上述されたような本発明の目的を達成する。制御サーバ３１にＰＣＲＦの機能を実装する場合に、本明細書全体を通じて参照される
制御ルールは３ＧＰＰのＴＳ２３．２０３で規定されるようないわゆるＰＣＣルールに含まれるもののような、その他の重要なフィールドとパラメータとを含んでもよい
(【００４４】〜【００４６】))
５．(ＣＬＡＩＭＳ)17.　A method for guaranteeing into a bearer layer those service requirements negotiated for a service through a signalling layer, the bearer layer being a media transport layer capable of bearing a number of service-related IP flows, the signalling layer being used for negotiating how media transported through the bearer layer should be treated, the method comprising the steps of:
　- 
receiving (S-102, S-112, S-121), at a control server (31) enabled to act as a Policy and Charging Rules Function, information about establishment of a bearer for bearing the service-related IP flows for a given user from an entity (32, 21, 51) in the bearer layer
　- 
receiving (S-125), at the control server (31) and from an entity (33, 41, 61) in service requirements negotiated for the service;  and characterised in that it also comprises the steps of: obtaining (S-122, S-123) user equipment 
UE
 capabilities of a user equipment (11) currently used by the given user from a user equipment 
UE
 capabilities repository (316)
　- 
determining (S-126) at the control server (31) control rules to apply for guaranteeing the service requirements into the bearer, the control rules based on the service information received from the entity in the signalling layer, including the negotiated service requirements, and based on the UE capabilities of the user equipment (11)
　- 
depending on the UE capabilities of the user equipment (11), either submitting (S-127) the control rules to be installed towards an entity (32, 21, 51) enabled to act as a Policy and Charging Enforcement Function in the bearer layer, or waiting (S- 130) for establishment of a subsequent bearer to install the control rules therein
18.　The method of claim 17, further including 
a step of submitting (S-124), towards the entity (32, 21, 51) enabled to act as a Policy and Charging Enforcement Function, preconfigured rules indicating services supported by the UE capabilities for the established bearer
19.　The method of claim 17, wherein the bearer layer is provided by an IP connectivity access network IP-CAN operating in accordance with a GSM Packet Radio System GPRS, wherein the bearer is established by activating a Packet Data Protocol PDP Context, and wherein the entity (21) in the bearer layer submitting the information about establishment of the bearer is a Gateway GPRS Support Node GGSN.
20.　The method of claim 17, wherein the bearer layer is provided by an IP connectivity access network IP-CAN operating in accordance with a Wireless Local Area Network WLAN, and wherein the entity (51) in the bearer layer submitting the information about establishment of the bearer is a Packet Data Gateway PDG. 
21.　The method of claim 17, wherein the entity (32, 21) enabled to act as a Policy and Charging Enforcement Function in the bearer layer is a Gateway GPRS Support Node GGSN.
22.　The method of claim 17, wherein the entity (32, 51) enabled to act as a Policy and Charging Enforcement Function in the bearer layer is a Packet Data Gateway PDG.
23.　The method of claim 17, wherein 
the step of obtaining (S-122, S-123) UE capabilities of a user equipment (11) includes a step of querying an external UE capabilities repository (316) for the UE capabilities
24.　The method of claim 17, wherein 
the step of obtaining (S-122, S-123) UE capabilities of a user equipment (11) includes a step of consulting a local UE capabilities repository (316) for the UE capabilities
25.　The method of claim 17, further comprising a step of determining whether a Quality of Service QoS model to apply is network-initiated or UE-initiated based on the obtained UE capabilities.
26.　The method of claim 17, wherein 
the alternative step S-127 of submitting the control rules to be installed includes a step of indicating said control rules to be installed for the currently established bearer, when the maximum number of bearers to be subsequently established has been already reached
27.　The method of claim 17, wherein 
the alternative step S-127 of submitting the control rules to be installed includes a step of requesting establishment of a new subsequent bearer and installing said control rules for the new subsequent bearer once established, when the maximum number of bearers to be subsequently established has not been reached yet
28. The method of claim 17, wherein the UE capabilities obtainable from the UE capabilities repository (316) include at least one UE capability selected from a group of UE capabilities comprising: 
- QoS management; - supported services per user equipment; 
- maximum number of bearers to be subsequently established; and 
- supported QoS model. 
29. The method of claim 17, wherein 
the entity (33) in the signalling layer submitting the service information about the media and including those service requirements negotiated for the service is an application function 
AF
 device
30. The method of claim 17, wherein the entity (41, 33) in the signalling layer submitting the service information about the media and including those service requirements negotiated for the service is a Proxy Call Session Control Function P-CSCF of an IP Multimedia Subsystem IMS and is enabled to act as an application function AF. 
31. The method of claim 17, wherein the entity (61, 33) in the signalling layer submitting the service information about the media and including those service requirements negotiated for the service is an application server AS and is enabled to act as an application function AF. 
(２２ページ〜２５ページ)
(当審訳
【請求項１７】
　シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する方法であって，
　前記ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり，前記シグナリング層は前記ベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられ，以下の工程を含む方法，
　−
ポリシー及び課金ルール機能として動作可能な制御サーバ(３１)
　−
前記制御サーバ(３１)が，前記シグナリング層内のエンティティ(３３，４１，６１)から，前記サービスについて交渉されたサービス要求条件を含む前記メディアに関するサービス情報を受信する工程(Ｓ−１２５)と
　−前記所与のユーザにより現在使用されているユーザ装置(１１)についてのユーザ装置“ＵＥ”能力をＵＥ能力記憶装置(３１６)から取得する工程(Ｓ−１２２，Ｓ−１２３)と，
　−
前記制御サーバ(３１)が，前記サービス要求条件を前記ベアラに保証するために適用される制御ルールを決定する工程(Ｓ−１２６)であって，前記制御ルールは前記シグナリング層内の前記エンティティから受信された前記サービス情報と前記ユーザ装置(１１)についての前記ＵＥ能力とに基づく，工程(Ｓ−１２６)
　−
前記ユーザ装置の前記ＵＥ能力に応じて，前記ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティ(３２，２１，５１)に向けて導入される前記制御ルールを送出する工程(Ｓ−１２７)か，前記制御ルールを導入するための後続するベアラの確立を待つ工程(Ｓ−１３０)か，のいずれかを行う工程
を含むことを特徴とする方法。
【請求項１８】
　
ポリシー及び課金施行機能として動作可能な前記エンティティ(３２，２１，５１)に向けて，前記確立されたベアラに対して前記ＵＥ能力によりサポートされるサービスを示す事前設定されたルールを送出する工程(Ｓ−１２４)
【請求項１９】
　前記ベアラ層は汎用パケット無線システム“ＧＰＲＳ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され，前記ベアラはパケット・データ・プロトコル“ＰＤＰ”コンテキストを起動することにより確立され，前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ(２１)はゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１７に記載の方法。
【請求項２０】
　前記ベアラ層は無線ローカルエリアネットワーク“ＷＬＡＮ”に従って動作するＩＰ接続アクセスネットワーク“ＩＰ−ＣＡＮ”により提供され，前記ベアラの確立に関する前記情報を送出する前記ベアラ層内の前記エンティティ(５１)はパケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１７に記載の方法。
【請求項２１】
　
前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ(３２，２１)は，ゲートウェイＧＰＲＳサポート・ノード“ＧＧＳＮ”であることを特徴とする請求項１７に記載の方法
【請求項２２】
　前記ベアラ層内のポリシー及び課金施行機能として動作可能な前記エンティティ(３２，５１)は，パケットデータ・ゲートウェイ“ＰＤＧ”であることを特徴とする請求項１７に記載の方法。
【請求項２３】
　ユーザ装置(１１)のＵＥ能力を取得する前記工程(Ｓ−１２２，Ｓ−１２３)は，該ＵＥ能力のために外部のＵＥ能力レポジトリ(３１６)に問い合わせる工程を含むことを特徴とする請求項１７に記載の方法。
【請求項２４】
　ユーザ装置(１１)のＵＥ能力を取得する前記工程(Ｓ−１２２，Ｓ−１２３)は，該ＵＥ能力のためにローカルのＵＥ能力レポジトリ(３１６)を調べる工程を含むことを特徴とする請求項１７に記載の方法。
【請求項２５】
　前記取得したＵＥ能力に基づいて，適用されるサービス品質“ＱｏＳ”モデルがネットワーク主導とＵＥ主導とのいずれであるかを判定する工程をさらに含むことを特徴とする請求項１７に記載の方法。
【請求項２６】
　
導入される前記制御ルールを送出する前記二者択一の一方の工程(Ｓ−１２７)は，後続して確立されるベアラの最大数にすでに到達している場合に，現在確立されているベアラに対して該制御ルールが導入されることを示す工程を含む
【請求項２７】
　
導入される前記制御ルールを送出する前記二者択一の一方の工程(Ｓ−１２７)は，後続して確立されるベアラの最大数にまだ到達していない場合に，新たな後続するベアラの確立すること及び確立された時点で該新たな後続するベアラに対して該制御ルールを導入することを要求する工程を含む
【請求項２８】
　前記ＵＥ能力レポジトリ（３１６）から取得可能な前記ユーザ装置（１１）の前記ＵＥ能力は、
　−ＱｏＳ管理、
　−ユーザ装置ごとのサポートされるサービス、
　−後続して確立されるベアラの最大数、及び
　−サポートされるＱｏＳモデル
を含むＵＥ能力群から選択された少なくとも一つのＵＥ能力を含むことを特徴とする請求項１７に記載の方法。
【請求項２９】
　
前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（３３）は、アプリケーション機能“ＡＦ”装置である
【請求項３０】
　前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（４１，３３）は、ＩＰマルチメディア・サブシステム“ＩＭＳ”のプロキシ呼セッション制御機能“Ｐ−ＣＳＣＦ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１７に記載の方法。
【請求項３１】
　前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ（６１，３３）は、アプリケーション・サーバ“ＡＳ”であり、アプリケーション機能“ＡＦ”として動作可能であることを特徴とする請求項１７に記載の方法。)
６．引用文献におけるＦＩＧ.２(図２)には，次の事項が記載されているといえる。
１　「Ｓ−１２５」として，「ＡＦ(３３)」から「ＰＣＲＦ(３１)」に「Service Information」(「サービス情報」)が送信されること，
２　「Ｓ−１２６」において，「Creation and Decision on Contorol Rules」(「制御ルールに関する生成及び決定」)
３　「Ｓ−１２７」として，「ＰＣＲＦ」から「ＰＣＥＦ」に「Contorol Rules Installation Request」(「制御ルールインストール要求」)を送信すること，
７．引用発明
　上記引用文献によれば，次の発明(以下「引用発明」という。)が記載されているといえる。
　シグナリング層を通じてサービスについて交渉されたサービス要求条件をベアラ層に保証する方法であって，
　前記ベアラ層はサービス関連の複数のＩＰフローを運ぶことができるメディア・トランスポート層であり，前記シグナリング層は前記ベアラ層を通じて輸送されるメディアがどのように扱われるべきかを交渉するために用いられ，以下の工程を含む方法，
　−ポリシー及び課金ルール機能として動作可能な制御サーバ(３１)が，前記ベアラ層内のエンティティ(３２)から，所与のユーザに対するサービス関連の前記ＩＰフローを伝えるためのベアラの確立に関する情報を受信する工程(Ｓ−１０２，Ｓ−１１２，Ｓ−１２１)と，
　−前記制御サーバ(３１)が，前記シグナリング層内のエンティティ(３３)から，前記サービスについて交渉されたサービス要求条件を含む前記メディアに関するサービス情報を受信する工程(Ｓ−１２５)と，
　−前記所与のユーザにより現在使用されているユーザ装置(１１)についてのユーザ装置“ＵＥ”能力をＵＥ能力記憶装置(３１６)から取得する工程(Ｓ−１２２，Ｓ−１２３)と，
　−前記制御サーバ(３１)が，前記サービス要求条件を前記ベアラに保証するために適用される制御ルールを決定する工程(Ｓ−１２６)であって，前記制御ルールは前記シグナリング層内の前記エンティティから受信された前記サービス情報と前記ユーザ装置(１１)についての前記ＵＥ能力とに基づく，工程(Ｓ−１２６)と，
　−前記ユーザ装置の前記ＵＥ能力に応じて，前記ベアラ層内でポリシー及び課金施行機能として動作可能なエンティティ(３２)に向けて導入される前記制御ルールを送出する工程(Ｓ−１２７)か，前記制御ルールを導入するための後続するベアラの確立を待つ工程(Ｓ−１３０)か，のいずれかを行う工程と，を含み，
　前記サービスについて交渉されたサービス要求条件を含む前記メディアに関する前記サービス情報を送出する前記シグナリング層内の前記エンティティ(３３)は、アプリケーション機能“ＡＦ”装置であることを特徴とする方法。
第５　当審の判断
１．対比
　本願発明と引用発明を比較すると次のことがいえる。
(１)　引用発明における「ポリシー及び課金ルール機能(ＰＣＲＦ)」として動作可能である。
　このことは，引用発明における「制御サーバ(３１)」は，「ポリシー及び課金ルール機能」の「ノード」つまり「ポリシー及び課金規則ノード(ＰＣＲＮ)」といえることを示している。
(２)　引用発明における「ポリシー及び課金施行機能として動作可能なエンティティ(３２)」は，「ポリシー及び課金施行ノード(ＰＣＥＮ)」といえる。
(３)　引用発明における「ＩＰフロー」は，「サービス関連」のものであるから，「サービスフロー」といえる。
(４)　引用文献[００５１]における記載によれば，引用発明における「制御ルール」は，「３ＧＰＰのＴＳ２３．２０３で規定されるようないわゆる
ＰＣＣルール
　このことは，該「制御ルール」は「ＰＣＣルール」を含みうると解することができることを示している。
　そうすると，引用発明における「制御ルール」は，「ＰＣＣルール」つまり「ＰＣＣ規則」といいうることを示している。
　ここで，３ＧＰＰのＴＳ２３.２０３において，「ＰＣＣルール」が「Ｐｏｌｉｓｙ　ａｎｄ　Ｃｈａｒｇｉｎｇ　Ｃｏｎｔｏｒｏｌ　Ｒｕｌｅｓ」(「ポリシー及び課金制御規則」)を意味する。
(５)　引用発明において，「制御サーバ(３１)」が受信する「所与のユーザに対するサービス関連の前記ＩＰフローを伝えるためのベアラの確立に関する情報」は，引用文献[００３５]における記載によれば，「ベアラのための制御ルールを依頼するため」のものである。
　そして，引用発明では，「ポリシー及び課金施行機能として動作可能なエンティティ(３２)に向けて導入される前記制御ルール」を送出する。
　以上のことは，「制御サーバ(３１)」つまり「ＰＣＲＦ(３１)」が受信する「ベアラの確立に関する情報」が，「制御ルール」つまり「ＰＣＣ規則」を要求する情報といえることを示している。
　また，上記のごとき「要求する情報」を「メッセージ」として，つまり「要求メッセージ」として受信，送信するようにすることは，周知である。
　一方で，上記「ベアラの確立に関する情報」は，「サービス関連のＩＰフローを伝えるため」のものであるのだから，該「情報」から該「ＩＰフロー」を決定できることは当然であり，また，該「情報」が，「ＩＰフロー」が要求されることによって，「ＰＣＥＦ(３２)」から送出されるようになったことは明らかである。
　このことは，「ＰＣＲＦ」において，要求された「サービス関連のＩＰフロー」を伝えるための「ベアラの確立に関する情報」が「要求メッセージ」として受信されるといえることを示している。
　また，該「ＩＰフロー」が「少なくとも１つ」であることは当然である。
　以上から，引用発明には，「ＰＣＲＮにおいて，要求メッセージを受信すること」と，「要求されたサービスフローを要求メッセージから決定すること」とがそれぞれ開示されているといえる。
　そうすると，本願発明と引用発明は，「ＰＣＲＮにおいて，要求メッセージを受信するステップ」と，「少なくとも１つの要求されたサービスフローを要求メッセージから決定するステップ」とを有する点で共通するといえる。
(６)　引用発明においては，「制御サーバ(３１)」が，「ベアラの確立」に関する情報を受信することにより，「制御ルール」が生成及び決定され，「ＰＣＥＮ(３２)」に，該「制御ルール」は導入されることとなる。
　このことから次のことがいえる。
ア　「ＰＣＥＮ(３２)」に「制御ルール」が導入されることは，換言すれば，「制御ルール」つまり「ＰＣＣ規則」を「ＰＣＥＮ(３２)」に提供するといえることを示している。
　そうすると，本願発明と引用発明は，「ＰＣＣ規則をポリシー及び課金施行ノード(ＰＣＥＮ)に提供するステップ」を有する点で共通するといえる。
イ　上記(５)に述べたことを踏まえると，「制御ルール」を生成及び決定することは，「要求メッセージ」に基づいていることを示している。
　また，引用発明において，導入されることとなる「制御ルール」が「ＩＰフロー」に関するものであることは明らかである。
　以上のことは，引用発明には，「少なくとも１つの要求されたサービスフローに関して，要求メッセージに基づいて」，導入される「制御ルール」つまり「ＰＣＣ規則」を生成することが開示されているといえる。
　そうすると，本願発明と引用発明は，「少なくとも１つの要求されたサービスフローに関して，要求メッセージに基づいて，ＰＣＣ規則を生成するステップ」を有する点で共通するといえる。
ウ　上記イに述べたことを踏まえると，該「決定」つまり「実行」は，「ＰＣＣ規則」の決定の結果を生成するためであるといえる。
　このことから，引用発明には，「制御ルール」つまり「ＰＣＣ規則」の決定の結果を生成するために，「ＰＣＣ規則」の決定を実行することと，「ＰＣＣ規則」の決定が，要求メッセージに基づいていることとがそれぞれ開示されているといえる。
　なお，「ＰＣＣ規則」とは「ポリシー及び課金制御規則」を意味する(上記(４)参照。)のであるから，上記した「ＰＣＣ規則」の決定とは，「ポリシー制御規則」の決定及び「課金制御規則」の決定とを意味すると解することができる。
　そして，「ポリシー制御規則」が決定されるとは，「ポリシー」の決定であることは当然である。
　このことは，「ポリシー制御規則」の決定が「ポリシー」の決定といえることを示している。
　以上のことは，引用発明には，「ポリシー決定結果を生成するために，ポリシー決定をすること」と，「ポリシー決定が，要求メッセージに基づいている」ことが開示されているといえる。
　そうすると，本願発明と引用発明は，「ポリシー決定結果を生成するために，ポリシー決定を実行するステップであって，ポリシー決定が，要求メッセージに基づいている，実行ステップ」を有する点で共通するといえる。
　また，本願発明と引用発明は，「少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成する目的で、要求メッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法」の点で共通するといえる。
エ　引用文献[００４４]には，「制御サーバ(３１)」が，「メディアに関するサービス情報」を受信すると，「制御ルール」を決定する旨の記載と，「制御ルール」が「ＵＥ能力に基づく」とする旨の記載とがある。
　このことは，「制御ルール」が該「サービス情報」と「ＵＥ能力」と適合するものであることを示している。
　そうすると，生成された「制御ルール」の決定が「サービス情報」及び「ＵＥ能力」に適合するように修正されるようにすることは格別なことではなく，当然に必要な事項であるといえる。
　また，上記ウに述べたことを踏まえると，このような修正が，決定された「ポリシー」に基づいて，つまり「ポリシー決定結果」にもとづいて行われることは明らかである。
　以上から，本願発明と引用発明は，「ポリシー決定結果に基づいて，ＰＣＣ規則を修正するステップ」を有する点で共通するといえる。
(６)　上記(１)ないし(５)から，本願発明と引用発明は，次の点で一致し，相違するといえる。
［一致点］
　少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成する目的で、要求メッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法であって、
　ＰＣＲＮにおいて、要求メッセージを受信するステップと、
　少なくとも１つの要求メッセージから決定するステップと、
　少なくとも１つの要求されたサービスフローに関して、要求メッセージに基づいて、ＰＣＣ規則を生成するステップと、
　ポリシー決定結果を生成するために、ポリシー決定を実行するステップであって、ポリシー決定が、要求メッセージに基づいている、実行するステップと、
　ポリシー決定結果に基づいて、ＰＣＣ規則を修正するステップと、
　ＰＣＣ規則をポリシーおよび課金施行ノード（ＰＣＥＮ）に提供するステップとを含む、方法。
［相違点］
相違点１
　本願発明における「要求メッセージ」は「アプリケーション要求メッセージ」であるのに対して，引用発明は「ベアラの確立」を要求する「要求メッセージ」である点。
　そして，この相違によって，引用発明では，ア「ＰＣＲＮ」において受信する「要求メッセージ」，イ「ＰＣＣ規則」の生成の基にする「要求メッセージ」，ウ「ポリシー決定」の基にする「要求メッセージ」に，「アプリケーション要求メッセージ」との特定がない点。
相違点２
　本願発明において生成される「ＰＣＣ規則」は「新しい」ＰＣＣ規則であるのに対して，引用発明はＰＣＥＦ(３２)に「導入される」ＰＣＣ規則である点。
　そして，この相違によって，ア「ＰＣＣ規則を生成するステップ」における「ＰＣＣ規則」，イ「修正するステップ」における「ＰＣＣ規則」，ウ「提供するステップ」における「ＰＣＣ規則」にも「新しい」ＰＣＣ規則との特定がない点。
相違点３
　本願発明における「実行するステップ」で生成するためのものが，ポリシー決定結果の「セット」であるのに対して，引用発明にはそのような特定がない点。
　そして，この相違によって，「修正するステップ」において基にする「ポリシー決定結果」にもその「セット」との特定がない点。
相違点４
　本願発明における「ＰＣＣ規則を生成するステップ」で「生成する」のに関する「要求されたサービスフロー」が少なくとも１つの要求されたサービスフロー「のうちの１つ」のものであるのに対して，引用発明にはそのような特定がない点。
２．検討
(１)　相違点３について
　引用発明において，「修正するステップ」において基にする「ポリシー家体結果」をその「セット」としたことに，格別な技術的異議があるとはいえない。つまり，相違点３のように「セット」するか否かは当業者が適宜決めうる設計的事項にすぎない。
(２)　相違点１について
ア　引用発明において，「制御サーバ」が受信する「メディアに関するサービス情報」に関して，引用文献には次の記載がある。
ア引用文献の[０００５]には，「ＰＣＥＦおよびＰＣＲＦとは別に、ＰＣＣアーキテクチャはまた、
ＩＰベアラのリソースの制御を要求するアプリケーションを提供するアプリケーション機能（以下、ＡＦ）を含む
ＡＦは、
サービス情報を転送するためにＰＣＲＦと通信する
イ　引用文献の[００４６]には，「ＱｏＳ管理に関する情報について、ステップＳ−１２５で
ＡＦから受信された情報は、
メディアタイプが「ビデオ」であることを示してもよく
サービス情報はまた、
「会話型」がサポートされないことを示してもよい
ウ　上記アによれば，「ＡＦ(アプリケーション機能)(３３)」から提供され「制御サーバ」に受信されることとなる「メディアに関するサービス情報」は，「アプリケーション」ということができると解される。
　そして，該「アプリケーション」の提供が「ＡＦ(３３)」から行われるのは，「ベアラの確立に関する情報」が「制御サーバ」に受信されることによることは明らかである。
　このことは，引用発明において，「ＰＣＣ規則」を要求するメッセージといえる「ベアラの確立に関する情報」は，「アプリケーション」を要求するメッセージ，つまり「アプリケーション要求メッセージ」ともいいうることを示している。
　つまり，相違点１について，「要求メッセージ」を「アプリケーション要求メッセージ」とすることは単なる呼び方の変更にすぎないといわざるを得ない。
イ　よって，相違点１は実質的な相違とはいえない程度のものである。
(３)　相違点２及び４について
ア　引用発明において，「導入される」制御ルールが，「ポリシー及び課金施行機能として動作可能なエンティティ(３２)」に対して，該「制御ルール」を「新しい」ものとして導入されるか，あるいは，既存の制御ルールの「変更」つまり「変更する」ものとして導入されるもののいずれかを意味すると解することができる。
　このことは，「ＰＣＣ規則を生成するステップ」において生成される「ＰＣＣ規則」が，「新しい」ＰＣＣ規則，若しくは「既存の制御ルールを変更する」ＰＣＣ規則のいずれかを意味すると解することができることを示している。
　そうすると，引用発明における「ＰＣＣ規則を生成するステップ」において生成するのを「新しい制御ルール」つまり「新しいＰＣＣ規則」とすることは，当業者が適宜なしえたものであるといえる。
イ　引用発明における「サービス関連のＩＰフロー」はユーザに対するものである。
　そうすると，該「ＩＰフロー」は，ユーザにサービスを提供をＩＰで行うフローであると解される。
　また，引用発明における「ＰＣＥＦ(ポリシー及び課金施行機能として動作可能なエンティティ)(３２)」が，１つのユーザに対する１つのサービスに対してのみ機能するものではないことは当然である。
　しかし，上記アに述べたような「新しいＰＣＣ規則」の生成が，１つのユーザ，あるいは１つのサービスに対して行われうるとは，当業者に当然に想定しうることである。
　このことは，上記アに述べたような「新しいＰＣＣ規則を生成する」ステップにおいて生成するのに関する「要求されたサービスフロー」が少なくとも１つの要求されたサービスフロー「のうちの１つ」のものとすることは当業者が適宜なしえたことであるといえることを示している。
(４)　上記(１)ないし(３)に述べたとおりであり，また，本願発明のように構成したことによる効果も，格別なものではなく，引用発明から予測できる程度のものである。
　したがって，本願発明は，引用発明に基づいて，当業者が容易に発明をすることができたものである。
第６　むすび
　以上のとおりであるから，本願発明は，特許法第２９条第２項の規定により，特許を受けることができない。
　したがって，他の請求項について，論及するまでもなく，本願は拒絶すべきものである。
　よって，審決のとおり結論する。