【事件の表示】
　特願２０１４−１５６４７２「長期進化型（ＬＴＥ）システムにおけるアップリンク欠乏状態回避を支援するための方法および装置」拒絶査定不服審判事件〔平成２６年１２月１１日出願公開、特開２０１４−２３３０８２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００８年（平成２０年）３月１２日（パリ条約による優先権主張外国庁受理２００７年３月１４日　 米国）を国際出願日とした特願２００９−５５３６０７号の一部を、平成２３年８月１１日に新たな特許出願とした特願２０１１−１７５９１６号の一部を、平成２４年５月２１日に新たな特許出願とした特願２０１２−１１６００８号の一部を、更に平成２６年７月３１日に新たな特許出願としたものであって、平成２７年７月９日付けで拒絶理由が通知され、同年１１月２０日付けで意見書及び手続補正書が提出され、平成２８年３月８日付けで拒絶査定されたところ、同年７月１５日に拒絶査定不服審判の請求がなされ、同時に手続補正がなされたものである。
第２　原査定の概要
　原査定（平成２８年３月８日付け拒絶査定）の概要は、平成２７年７月９日付け拒絶理由通知書も参照すれば次のとおりである。
　・・・・・・
２．（サポート要件）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　・・・・・・
備考
　・・・・・・
●理由２．１（特許法第３６条第６項第１号）について
・請求項　１−３０
　・・・・・請求項１記載の
『前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと、およびに前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが前記ＵＬ　ＲＢｓの第１のグループの前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していること基づいて、バッファー状態報告（ＢＳＲ）を提供すること』
は、発明の詳細な説明に記載されていない。
　請求項１６、及び、これらの請求項を引用する請求項２−１５，１７−３０も、同様である。
●理由２．３（特許法第３６条第６項第１号）について
・請求項　２−１５，１７−３０
　・・・・・請求項２記載の
『送信のための前記ＵＬ　ＲＢｓの第１のグループのいずれかのＵＬに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったことに基づいて、ＢＳＲを提供すること』は、発明の詳細な説明に記載されていない。
　請求項１７、及び、これらの請求項を引用する請求項３−１５，１８−３０も、同様である。
　・・・・・・
第３　請求人の主張
　請求人は審判請求書（平成２８年８月３０日付け手続補正書を参照。）において、審判請求時の補正を前提として、概略以下のように主張している。
「・・・・
（ｃ−３）理由２．１について
　拒絶査定において、補正前の請求項１について、“『前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと、およびに前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが前記ＵＬ　ＲＢｓの第１のグループの前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していること基づいて、バッファー状態報告（ＢＳＲ）を提供すること』は、発明の詳細な説明に記載されていない。”
と認定されました。
　上記のとおり、補正前の請求項１の「ＵＬ無線ベアラ（ＲＢ）の第１のグループ」の記載は削除されており、補正後の請求項１には存在しません。また、補正後の請求項１の第３段落において、バッファー状態報告（ＢＳＲ）は、ＷＴＲＵの状況（ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となった状況）に応じて生じるイベントに応じて提供されることが明確にされました。
　また、拒絶査定において、“出願人が主張するように、明細書の段落[0024]には、高優先度のＲＢのみ報告することが記載されている。”と認定されました。
　しかしながら、この認定は、明細書全体からの把握される事項が考慮されていないと思料いたします。
　上記のように、本願の開示において、本質的に、報告をトリガーするためのイベントは
、ＷＴＲＵに関する情報の値があるレベルまで上昇する（閾値を超過する）場合に発生するイベント、すなわち、このイベントが適用されなければタイムリーな報告を行うことができなくなり、適切に許可（grant）のサイズ調整を行うことができなくなり、結果として、ＵＬの欠乏及び／または許可ロスを生じさせることつながるようなイベントを含みます。そして、本願は、ネットワークが、適切にサイズ調整された許可を発行し、複数のＵＬ無線リソース（ＢＲ）のバッファーの報告されたバッファーレベルに対して、各々のＱｏＳレベルに従って対処しており、ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となった状況において、レポートがトリガーされるようにできることを開示します（例えば、本願明細書の第０００４、００１０、
００２４
　より詳細には、本願により開示されているように、アプリケーションの間で許可された資源を如何に分配するかに関してネットワークは制御しません。許可された資源（ＷＴＲＵが既に報告しているより低い優先度のＲＢに基づいて許可された資源）がより高い優先度のＲＢのデータのために使われる結果として、より低い優先度のフローに欠乏が生じます（例えば、本願の第０００４段落参照）。しかしながら、本願は、さらに開示されているように、ＷＴＲＵが、ネットワークが状況を把握した状態を維持することができれば、このような欠乏を回避できることを開示します（例えば、本願の第００２４段落参照）。ネットワークに状況を把握させるため、ＷＴＲＵは、バッファー状態報告を提供します（例えば、本願の第００２４−００２５段落参照）。また、本願は、バッファー状態報告が、予め定義されたイベントによりトリガーされることを開示します（例えば、本願の第００２５段落参照）。本願は、報告をトリガーするために使用され得るイベントは、予め記述された情報についての値が閾値を超えたかまたは下回るイベントを含むことを開示します（例えば、本願の第
００２５
００２０
００２５
　以上のように、本願の発明の詳細な説明は、補正後の請求項１の第３段落（補正前の第４段落に対応）に記載の事項を十分に、開示しているものと思料いたします。補正後の請求項１６も同様です。
（ｃ−４）理由２．３について
　拒絶査定において、“請求項２記載の『送信のための前記ＵＬ　ＲＢｓの第１のグループのいずれかのＵＬに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったことに基づいて、ＢＳＲを提供すること』は、発明の詳細な説明に記載されていない。請求項１７、及び、これらの請求項を引用する請求項３−１５，１８−３０も、同様である。”と認定されました。
　本願の開示において、本質的に、報告をトリガーするためのイベントは、ＷＴＲＵに関する情報の値があるレベルまで上昇する（閾値を超過する）場合に発生するイベント、すなわち、このイベントが適用されなければタイムリーな報告を行うことができなくなり、適切に許可（grant）のサイズ調整を行うことができなくなり（または許可を与えなくなり）、結果として、ＵＬの欠乏及び／または許可ロスを生じさせることつながるようなイベントを含みます。そして、本願発明は、周期的な報告が複数のＵＬ無線ベアラ（ＲＢｓ）のバッファーレベルにおいて、データを欠いていることを示す故、ネットワークが許可を発行していない状況において、ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となったＷＴＲＵの状況に対処するために、報告がトリガーされることを開示します。第００２５段落に開示されているようなバッファー状況報告（ＢＳＲ）および第００３４段落（当審注：記載内容から見て「第００２４段落」の誤記であると認められる。）に開示されているようなＢＳＲは、複数のＲＢｓに関連づけられたデータを欠いているため許可を受け取っていない状況において、ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となったＷＴＲＵの状況が意図されています。
　したがって、請求項２は、本願の発明の詳細な説明に記載された発明であると思料いたします。請求項１７についても同様です。」（当審注：下線は、平成２９年２月２７日付け上申書によって請求人が訂正した箇所である。）
第４　当審の判断
１　補正の適否について
　平成２８年７月１５日付けでなされた手続補正（以下、「本件補正」という。）は、請求項１、２、４、６−８、１１、１５−１９、２１−２３，２６，３０については、明りょうではない記載の釈明を目的とし、請求項３１−５８については請求項の削除を目的としたものであるから、特許法第１７条の２第５項第１号及び第４号（補正の目的）の規定に適合するものであり、また、同法第１７条の２第３項（新規事項）、同法第１７条の２第４項（シフト補正）の規定に違反しないことも明らかである。
　したがって、平成２８年７月１５日付けでなされた手続補正は適法になされたものである。
２　補正後の請求項
　補正後の請求項１、２は以下のとおりのものである。
「　【請求項１】
　無線送受信ユニット（ＷＴＲＵ）からのアップリンク（ＵＬ）のデータをスケジューリングする方法であって、
　複数のＵＬ無線ベアラ（ＲＢｓ）に関連付けられた、現在のバッファー状態情報を、各々のビットレートに対する前記複数のＵＬ　ＲＢｓの各々のトークンバケットのサイズに基づいて、判定することであって、前記現在のバッファー状態情報は、（ｉ）前記ＷＴＲＵにおけるバッファーが送信のための前記複数のＵＬ　ＲＢｓのうちの少なくとも１つのＵＬ　ＲＢに関連付けられた未処理のＵＬのデータを含んでいること、および（ｉｉ）前記複数のＵＬ　ＲＢｓのうちの第２のＵＬ　ＲＢに関連付けられたＵＬのデータが送信のために利用可能になったことを示す、ことと、
　前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと、および前記第２のＵＬ　ＲＢが前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していることに基づいてトリガーされるイベントに応答して、バッファー状態報告（ＢＳＲ）を提供することと、
　提供した前記ＢＳＲに応答して、前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータの送信の許可を受信することと
を具備する方法。
　　【請求項２】
　前記複数のＵＬ無線ベアラ（ＲＢｓ）に関連付けられた、第２の現在のバッファー状態情報を、各々のビットレートに対する前記複数のＲＢｓの各々のトークンバケットのサイズに基づいて、判定することと、
　前記第２の現在のバッファー状態情報が、送信のための前記少なくとも１つのＵＬ　ＲＢに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示すこと、および前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったことに基づいてトリガーされるイベントに応答して、ＢＳＲを提供することをさらに備えた、請求項１に記載の方法。」
３　理由２．１について
　理由２．１は、本件補正前の請求項１に記載された
「前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと、および前記第２のＵＬ　ＲＢが前記ＵＬ　ＲＢｓの第１のグループの前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していることに基づいて、バッファー状態報告（ＢＳＲ）を提供すること」は、発明の詳細な説明に記載されていないというものである。
　当該記載は、本件補正により以下のように補正された。
「前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと、および前記第２のＵＬ　ＲＢが前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していることに基づいてトリガーされるイベントに応答して、バッファー状態報告（ＢＳＲ）を提供すること」
　上記本件補正後の記載によれば、バッファー状態報告（ＢＳＲ）の提供を行うためのイベントのトリガーが、
（１）第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったこと（以下、「条件１」という。）、および、
（２）前記第２のＵＬ　ＲＢが前記少なくとも１つのＵＬ　ＲＢの優先度よりも高い優先度を有していること（以下、「条件２」という。）、
という２つの条件に基づいて行われることが特定されている。
　これに対して、発明の詳細な説明において、イベントのトリガーに関して記述されているのは【００２５】であり、そこには次のように記載されている。
「【００２５】
　ＷＴＲＵ２１０は、自身の報告またはトークン・バケット情報を定期的に送信する（ステップ４１０）ことができ、または予め定義されたイベントによりそれをトリガーすることができる。報告をトリガーするために利用することができるイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントを含む。例えば、あるＲＢまたはＲＢ群に対するトークンの量が、予め定義された閾値を下回るなら、報告するべくＷＴＲＵ２１０をトリガーすることができる。閾値は、ＲＢ確立にてＲＲＣ信号方式により設定することができ、そしてトークン・バケットの最大のサイズの一部分（ｆｒａｃｔｉｏｎ）であると定義することができる。」
　上記記載によれば、報告をトリガーするイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントであって、例えば、あるＲＢまたはＲＢ群に対するトークンの量が、予め定義された閾値を下回るというイベントをトリガーの条件とすることが例示されているのみである。そうしてみると、上述した請求項１におけるバッファー状態報告（ＢＳＲ）の提供を行うためのイベントをトリガーする２つの条件（条件１、条件２）については何ら記載されていない。また、仮にバッファー状態を報告する必要が生じたのであるから、条件１の「第２のＵＬ　ＲＢに関連付けられたＵＬのデータが送信のために利用可能になったこと」が報告するためのイベントに当然なり得るといえたとしても、「第２のＵＬ　ＲＢに関連付けられたＵＬのデータ」の優先度を、他のＵＬ　ＲＢの優先度との関係において規定する条件２については、発明の詳細な説明に記載されているということはできない。
　したがって、本願の請求項１に係る発明は、発明の詳細な説明に記載したものではない。
　請求項１と同様の記載を有する請求項１６、及び請求項１、１６を引用する請求項２−１５、１７−３０に係る発明についても発明の詳細な説明に記載したものとはいえない。
　なお、請求人は審判請求書において「ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となった状況において、レポートがトリガーされるようにできることを開示します（例えば、本願明細書の第０００４、００１０、００２４段落参照）。」と主張する。
　しかしながら、本願明細書の【０００４】には高優先度フローが利用可能な帯域幅まで拡大すると低優先度のフローが欠乏状態になると言うことが、また【００１０】には許可ロスがどのように発生するかと言うことが、それぞれ本願発明の背景技術として記載されているのみである。【００２４】をみてもＷＴＲＵ２１０がＷＴＲＵ２１０に関連する情報をｅＮＢ２２０に報告することにより許可ロスを回避する支援をすることが可能であると言うことや、ＷＴＲＵ２１０が「それぞれのＲＢ、ＲＢのグループ、すべてのＲＢ、高優先度のＲＢのみ、または任意の組合せに対して報告する」ことについて記載されているのみであって、バッファー状態報告を行うためのイベントのトリガーが上述した条件１及び条件２に基づいて行われることについて記載されていない。
　したがって、請求人の上記主張を採用することはできない。
４　理由２．３について
　理由２．３は、本件補正前の請求項２に記載された
「送信のための前記ＵＬ　ＲＢｓの第１のグループのいずれかのＵＬに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったことに基づいて、ＢＳＲを提供すること」は、発明の詳細な説明に記載されていないというものである。
　当該記載は、本件補正により以下のように補正された。
「　前記複数のＵＬ無線ベアラ（ＲＢｓ）に関連付けられた、第２の現在のバッファー状態情報を、各々のビットレートに対する前記複数のＲＢｓの各々のトークンバケットのサイズに基づいて、判定することと、
　前記第２の現在のバッファー状態情報が、送信のための前記少なくとも１つのＵＬ　ＲＢに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示すこと、および前記第２のＵＬ　ＲＢに関連付けられた前記ＵＬのデータが送信のために利用可能になったことに基づいてトリガーされるイベントに応答して、ＢＳＲを提供すること」
　当該記載によれば、ＢＳＲを提供するためのイベントのトリガーが「第２の現在のバッファー状態情報が、送信のための前記少なくとも１つのＵＬ　ＲＢに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示すこと」（以下、「条件Ａ」という。）を条件の一つとすることが特定されている。
　しかしながら、上記「３　理由２．１について」で検討したように、発明の詳細な説明には、バッファー状態報告の提供を行うためのイベントのトリガーは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントであって、例えば、あるＲＢまたはＲＢ群に対するトークンの量が、予め定義された閾値を下回るということをトリガーの条件とすることが例示されているのみである。そして、上記条件Ａに基づいてトリガーされるイベントに応答してＢＳＲを提供することについては、本願の発明の詳細な説明に記載も示唆もなく、また自明のことともいえない。
　したがって、本願の請求項２に係る発明は、発明の詳細な説明に記載されたものではない。
　請求項２と同様の記載を有する請求項１７、及び請求項２、１７を引用する請求項３−７、９−１５、１８−３０に係る発明についても発明の詳細な説明に記載したものとはいえない。
　なお、請求人は審判請求書において、「第００２５段落に開示されているようなバッファー状況報告（ＢＳＲ）および第００３４段落（当審注：記載内容から見て「第００２４段落」の誤記であると認められる。）に開示されているようなＢＳＲは、複数のＲＢｓに関連づけられたデータを欠いているため許可を受け取っていない状況において、ＷＴＲＵが既に報告している他のＲＢｓよりも高い優先度を有しているＲＢについてのデータが利用可能となったＷＴＲＵの状況が意図されています。」と主張しているが、【００２４】及び【００２５】をみても、「前記第２の現在のバッファー状態情報が、送信のための前記少なくとも１つのＵＬ　ＲＢに関連付けられた未処理のＵＬのデータをバッファーが欠いていることを示すこと」をトリガーの条件としていることは記載されていない。
　したがって、請求人の主張を採用することはできない。
第５　むすび
　以上のとおり、本件出願は、特許請求の範囲の記載に不備があり、特許法第３６条第６項第１号に規定する要件を満たしていないから、特許を受けることができない。
　よって、結論のとおり審決する