【事件の表示】
　特願２０１３−５０２８０９「中継ノードを介した通信をサポートするための方法および装置」拒絶査定不服審判事件〔平成２３年１０月　６日国際公開、ＷＯ２０１１／１２３５４９、平成２５年　６月１７日国内公表、特表２０１３−５２４６４３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，
平成２３年３月３０日(優先権主張　２０１０年(平成２２年)４月２日　米国(ＵＳ)，同日　米国(ＵＳ)，同年８月１３日　米国(ＵＳ))を国際出願日とする外国語特許出願であって，平成２４年１２月３日付けで手続補正書の提出がなされ，平成２５年９月２６日付けで拒絶の理由が通知され，平成２６年２月１７日付けで意見書とともに手続補正書の提出がなされ，同年６月２３日付けで拒絶査定され，同年１１月４日に拒絶査定不服審判の請求と同時に手続補正がなされ，同年１２月１９日付けで前置報告書が提出され，平成２７年４月１３日付けで上申書の提出がなされたものである。
第２　補正却下の決定
［結論］
　平成２６年１１月４日付け手続補正を却下する。
［理由］
　　１．本件補正
　　　平成２６年１１月４日付け手続補正(以下「本件補正」という。)は，特許請求の範囲を，次の「本件補正前」から「本件補正後」のように補正することを含むものである。なお，請求人の附した下線は省略。
　　［本件補正前の特許請求の範囲］
　　【請求項１】
　中継ノードによって実施される、通信をサポートする方法であって、
　１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックを、別個の報告グループとして含む中継ノードバッファステータス報告(ＢＳＲ)を生成するステップと、
　前記中継ノードＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るステップと
を含むことを特徴とする方法。
　　【請求項２】
　前記中継ノードＢＳＲは、前記中継ノードにおける、中継ノードアップリンクバッファステータスおよび／または中継ノードダウンリンクバッファステータスを含むことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記中継ノードアップリンクバッファステータスは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ無線ベアラ(ＲＢ)についての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、アップリンクバッファ蓄積の合計に基づいて生成され、前記中継ノードダウンリンクバッファステータスは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ　ＲＢについての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、ダウンリンクバッファ蓄積の合計に基づいて生成されることを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記報告グループは、ＷＴＲＵごとに、またはＷＴＲＵ　ＤＲＢに関連するサービス品質(ＱｏＳ)ごとに編成されることを特徴とする請求項３に記載の方法。
　　【請求項５】
　前記中継ノードＢＳＲは、定期的に、構成されたトリガイベントの発生に基づいて、または、定期的なタイマと構成されたトリガイベントの発生との組合せに基づいて、トリガされることを特徴とする請求項１に記載の方法。
　　【請求項６】
　中継ノードを介した通信をサポートする方法であって、
　中継ノードがバッファステータス報告(ＢＳＲ)を生成するステップであって、前記ＢＳＲがワイヤレス送受信ユニット(ＷＴＲＵ)へのダウンリンク送信についての前記中継ノードにおけるバッファステータスに関する情報を含む、ステップと、
　前記中継ノードが前記ＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るステップと、
　前記中継ノードがそのリソース割振りに満足しているか否かを示す満足インジケータを送るステップと、
を含むことを特徴とする方法。
　　【請求項７】
　中継ノードによって実施される、通信をサポートする方法であって、
　ワイヤレス送受信ユニット(ＷＴＲＵ)アプリケーションがサービス品質要件を変更すること、ＷＴＲＵ−中継ノードインタフェースに対する調整が中継ノード−ドナーｅノードＢ(ＤｅＮＢ)インタフェース構成に影響を及ぼすこと、または、システム情報パラメータ値が変化することを条件として、前記中継ノードと前記ＤｅＮＢとの間のリンク、または前記中継ノードと前記ＷＴＲＵとの間のリンクの構成または再構成の必要性を示すために無線リソース制御(ＲＲＣ)メッセージを前記ＤｅＮＢに送るステップであって、前記システム情報パラメータ値が変化することは、前記中継ノードと前記ＤｅＮＢとの間の前記リンクの周波数リソースの中継ノード使用に影響を及ぼすダウンリンク帯域幅変化、ＷＴＲＵ電力ヘッドルームに影響を及ぼす最大送信電力制限変化、中継ノードアップリンク動作に影響を及ぼすアップリンク帯域幅変化もしくはアップリンク搬送波周波数変化、または前記中継ノードと前記ＤｅＮＢとの間のサブフレーム割振りに影響を及ぼすＭＢＳＦＮ(単一周波数ネットワークを介したマルチメディアブロードキャスト)サブフレーム構成リスト変化を含む、ステップをさらに含むことを特徴とする方法。
　　【請求項８】
　前記中継ノードからハンドオーバターゲットへの前記ＷＴＲＵのハンドオーバの要求に応答してハンドオーバ要求肯定応答メッセージが前記ＤｅＮＢから受け取られること、前記ＷＴＲＵについて前記ＤｅＮＢへのデータ転送が完了すること、エンドマーカが受け取られること、またはＷＴＲＵコンテキスト解放メッセージが受け取られることを条件として、前記中継ノードが、前記ＲＲＣメッセージを送るステップを含むことを特徴とする請求項７に記載の方法。
　　【請求項９】
　送受信機と、
　１つまたは複数の制御プレーンベアラによって搬送され、中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックを、別個の報告グループとして含む中継ノードバッファステータス報告(ＢＳＲ)を生成し、前記中継ノードＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るように構成されたプロセッサと、
を備える中継ノード。
　　【請求項１０】
　前記中継ノードＢＳＲは、前記中継ノードにおける、中継ノードアップリンクバッファステータスおよび／または中継ノードダウンリンクバッファステータスを含むことを特徴とする請求項９に記載の中継ノード。
　　【請求項１１】
　前記プロセッサは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ無線ベアラ(ＲＢ)についての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、アップリンクバッファ蓄積の合計に基づいて、前記中継ノードアップリンクバッファステータスを生成し、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ　ＲＢについての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、ダウンリンクバッファ蓄積の合計に基づいて、前記中継ノードダウンリンクバッファステータスを生成するように構成されたことを特徴とする請求項１０に記載の中継ノード。
　　【請求項１２】
　前記報告グループは、ＷＴＲＵごとに、またはＷＴＲＵ　ＤＲＢに関連するサービス品質(ＱｏＳ)ごとに編成されることを特徴とする請求項１１に記載の中継ノード。
　　【請求項１３】
　前記中継ノードＢＳＲは、定期的に、構成されたトリガイベントの発生に基づいて、または、定期的なタイマと構成されたトリガイベントの発生との組合せに基づいて、トリガされることを特徴とする請求項９に記載の中継ノード。
　　【請求項１４】
　送受信機と、
　バッファステータス報告(ＢＳＲ)を生成し、前記ＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るように構成され、前記ＢＳＲがワイヤレス送受信ユニット(ＷＴＲＵ)へのダウンリンク送信についての前記中継ノードにおけるバッファステータスに関する情報を含む、プロセッサと、を備え、
　前記プロセッサは、前記中継ノードがそのリソース割振りに満足しているか否かを示す満足インジケータを送るように構成されたことを特徴とする中継ノード。
　　【請求項１５】
　送受信機と、
　プロセッサと、を備え、
　前記プロセッサは、ワイヤレス送受信ユニット(ＷＴＲＵ)アプリケーションがサービス品質要件を変更すること、ＷＴＲＵ−中継ノードインタフェースに対する調整が中継ノード−ドナーｅノードＢ(ＤｅＮＢ)インタフェース構成に影響を及ぼすこと、または、システム情報パラメータ値が変化することを条件として、前記中継ノードと前記ＤｅＮＢとの間のリンク、または前記中継ノードと前記ＷＴＲＵとの間のリンクの構成または再構成の必要性を示すために無線リソース制御(ＲＲＣ)メッセージを前記ＤｅＮＢに送るように構成され、前記システム情報パラメータ値が変化することは、前記中継ノードと前記ＤｅＮＢとの間の前記リンクの周波数リソースの中継ノード使用に影響を及ぼすダウンリンク帯域幅変化、ＷＴＲＵ電力ヘッドルームに影響を及ぼす最大送信電力制限変化、中継ノードアップリンク動作に影響を及ぼすアップリンク帯域幅変化もしくはアップリンク搬送波周波数変化、または前記中継ノードと前記ＤｅＮＢとの間のサブフレーム割振りに影響を及ぼすＭＢＳＦＮ(単一周波数ネットワークを介したマルチメディアブロードキャスト)サブフレーム構成リスト変化を含む、ことを特徴とする中継ノード。
　　【請求項１６】
　前記プロセッサは、前記中継ノードからハンドオーバターゲットへの前記ＷＴＲＵのハンドオーバの要求に応答してハンドオーバ要求肯定応答メッセージが前記ＤｅＮＢから受け取られること、前記ＷＴＲＵについて前記ＤｅＮＢへのデータ転送が完了すること、エンドマーカが受け取られること、またはＷＴＲＵコンテキスト解放メッセージが受け取られることを条件として、前記ＲＲＣメッセージを送るように構成されたことを特徴とする請求項１５に記載の中継ノード。
　　【請求項１７】
　前記中継ノードＢＳＲは、前記中継ノードによってサービスされるＷＴＲＵから受信されるＷＴＲＵ　ＢＳＲを含み、前記ＷＴＲＵ　ＢＳＲは、前記ＷＴＲＵにおけるアップリンクバッファステータスを示すことを特徴とする請求項１に記載の方法。
　　【請求項１８】
　前記中継ノードが、そのリソース割振りに満足しているか否かを示す満足インジケータを送るステップをさらに含むことを特徴とする請求項１に記載の方法。
　　【請求項１９】
　前記プロセッサは、前記中継ノードによってサービスされるＷＴＲＵから受信されるＷＴＲＵ　ＢＳＲを含み、前記ＷＴＲＵ　ＢＳＲは、前記ＷＴＲＵにおけるアップリンクバッファステータスを示すように構成されたことを特徴とする請求項９に記載の中継ノード。
　　【請求項２０】
　前記プロセッサは、前記中継ノードが、そのリソース割振りに満足しているか否かを示す満足インジケータを送るように構成されたことを特徴とする請求項９に記載の中継ノード。
　　【請求項２１】
　前記ＲＲＣメッセージは、前記ＷＴＲＵのハンドオーバの間に送られることを特徴とする請求項７に記載の方法。
　　【請求項２２】
　前記プロセッサは、前記ＲＲＣメッセージを、前記ＷＴＲＵのハンドオーバの間に送るように構成されたことを特徴とする請求項１５に記載の中継ノード。
　　［本件補正後の特許請求の範囲］
　　【請求項１】
　中継ノードによって実施される、通信をサポートする方法であって、
　１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループと、１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループと、を含む中継ノードバッファステータス報告(ＢＳＲ)を生成するステップと、
　前記中継ノードＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るステップと
を含むことを特徴とする方法。
　　【請求項２】
　前記中継ノードＢＳＲは、前記中継ノードにおける、中継ノードアップリンクバッファステータスおよび／または中継ノードダウンリンクバッファステータスを含むことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記中継ノードアップリンクバッファステータスは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ無線ベアラ(ＲＢ)についての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、アップリンクバッファ蓄積の合計に基づいて生成され、前記中継ノードダウンリンクバッファステータスは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ　ＲＢについての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、ダウンリンクバッファ蓄積の合計に基づいて生成されることを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記報告グループは、ＷＴＲＵごとに、またはＷＴＲＵ　ＤＲＢに関連するサービス品質(ＱｏＳ)ごとに編成されることを特徴とする請求項３に記載の方法。
　　【請求項５】
　前記中継ノードＢＳＲは、定期的に、構成されたトリガイベントの発生に基づいて、または、定期的なタイマと構成されたトリガイベントの発生との組合せに基づいて、トリガされることを特徴とする請求項１に記載の方法。
　　【請求項６】
　送受信機と、
　１つまたは複数の制御プレーンベアラによって搬送され、中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループと、１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループと、を含む中継ノードバッファステータス報告(ＢＳＲ)を生成するように構成されたプロセッサと、
を備え、
　前記プロセッサは、前記中継ノードＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るようにさらに構成された、中継ノード。
　　【請求項７】
　前記中継ノードＢＳＲは、前記中継ノードにおける、中継ノードアップリンクバッファステータスおよび／または中継ノードダウンリンクバッファステータスを含むことを特徴とする請求項６に記載の中継ノード。
　　【請求項８】
　前記プロセッサは、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ無線ベアラ(ＲＢ)についての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、アップリンクバッファ蓄積の合計に基づいて、前記中継ノードアップリンクバッファステータスを生成し、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ　ＲＢについての、または１つもしくは複数の報告グループに属するアクティブなＷＴＲＵ　ＲＢについての、ダウンリンクバッファ蓄積の合計に基づいて、前記中継ノードダウンリンクバッファステータスを生成するように構成されたことを特徴とする請求項７に記載の中継ノード。
　　【請求項９】
　前記報告グループは、ＷＴＲＵごとに、またはＷＴＲＵ　ＤＲＢに関連するサービス品質(ＱｏＳ)ごとに編成されることを特徴とする請求項８に記載の中継ノード。
　　【請求項１０】
　前記中継ノードＢＳＲは、定期的に、構成されたトリガイベントの発生に基づいて、または、定期的なタイマと構成されたトリガイベントの発生との組合せに基づいて、トリガされることを特徴とする請求項６に記載の中継ノード。
　　【請求項１１】
　前記中継ノードＢＳＲは、前記中継ノードによってサービスされるＷＴＲＵから受信されるＷＴＲＵ　ＢＳＲを含み、前記ＷＴＲＵ　ＢＳＲは、前記ＷＴＲＵにおけるアップリンクバッファステータスを示すことを特徴とする請求項１に記載の方法。
　　【請求項１２】
　前記プロセッサは、前記中継ノードによってサービスされるＷＴＲＵから受信されるＷＴＲＵ　ＢＳＲを含み、前記ＷＴＲＵ　ＢＳＲは、前記ＷＴＲＵにおけるアップリンクバッファステータスを示すように構成されたことを特徴とする請求項６に記載の中継ノード。
　　２．本件補正に関する検討
　本件補正により，請求項１に記載された「中継ノードバッファステータス報告(ＢＳＲ)を生成するステップ」が含む「報告グループ」が，
本件補正前では
本件補正後では
　「報告グループ」に関し，本件補正前の請求項１記載の「前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックを、
別個の
　そうすると，本件補正は，上記のように推定できる「別の報告グループ」を，上記「第２の報告グループ」として明示するようにしたものであると解することも一応できる。
　しかし，当該「別の報告グループ」がいかなる技術的特徴を有する「報告グループ」であるかを本件補正前の請求項１の記載は特定しない。
　このことは，本件補正において，上記「別の報告グループ」を上記のような「第２の報告グループ」とすることが，当該「別の報告グループ」を実質的に下位概念化するもの，つまり「発明を特定するために必要な事項を限定するもの」であるということができないことを示している。
　したがって，本件補正は，本件補正前の請求項１に記載された発明を特定するために必要な事項を限定するものでない事項を含むものであるといわざるを得ない。
　　３．まとめ
　以上のとおりであるから，本件補正は，特許請求の範囲を減縮するものであるということはできない。
　また，請求項１に対してなされた補正は，誤記の訂正，若しくは明りょうでない記載の釈明ということもできないことは明らかであり，そして，本件補正が，請求項の削除のみを目的とするものでもないことも明らかである。
　したがって，本件補正は，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　　４．請求項１に対する本件補正に関する補足的検討
　本件補正について，当審は，上記「２．」及び「３．」に述べたように判断したところ，仮に，本件補正前の請求項１に対してなされた補正が，「別の報告グループ」を限定するものであって，特許請求の範囲を減縮するものであるといえたとしても，上記「３．まとめ」において述べた事項には，次の検討より，影響を及ぼさないといえる。
　以上を前提とすると，本件補正後の請求項１に記載された発明(以下「本件補正発明」という。)は，特許出願の際独立して特許を受けることができるものでなければならない。これを踏まえ，本件補正について，補足的検討をする。
　　　(１)　補足的検討１(３６条について)
　　　　ア　上記「２．」にも述べたとおり，本件補正によって，本件補正発明における「中継ノードバッファステータス報告(ＢＳＲ)」は，１「１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループと、１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループと」を含むものとなり，２「ドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)」に送られるものとなった。
　上記１に関連し，請求人は，審判請求書の【本願発明が特許されるべき理由】の「(１)　補正について」，及び上申書の【上申の内容】の「(２)　請求人の意見」において，それぞれ，次のように述べている(下線は当審が付与。)。
　　　　イ　審判請求書における記載
　「上記
補正は、例えば、本願明細書の段落００８３、００８４、００９７、０１１１−０１１３、０１３２、０１３７、等の記載に基づいて行った
　　　　ウ　上申書における記載
「　出願人は、上記前置報告書における審査官殿のご認定には承服しかねますので、以下、意見を述べさせていただきます。
　本願の独立請求項１および６（以下、本願発明という）は、審査官殿が前置報告書で言及された段落に加えて、少なくとも、
段落００８３、００８４、０１１２、０１１３、０１３７、等に開示されています
段落００８３には
例えば、本願の段落００８７−００９２、０１２１、０１５８、０１５９等においても、複数のＲＮ　ＢＳＲ報告グループについての記載があります
　また、前置報告書にも挙げられていたように、
段落０１３２には、複数の報告グループには、ＷＴＲＵ制御プレーントラフィックが存在することができます
「ＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループ」は、段落００９７等に開示されています
「ＷＴＲＵユーザプレーンデータトラフィックに関する」報告グループは、段落００８３、００８４、００８７−００９２に明確に開示されています
　以上の通り、本願発明は出願当初の明細書等に十分に開示されていると思料します。
　審判請求人は以上の通り思料致しますので、上記意見をご参酌の上、審理頂きたくお願い申し上げます。」
　　　　エ　当審の見解
　上記「イ」及び「ウ」を検討するに，請求人は，要するに，本願明細書における段落【００８３】−【００８４】，【００８７】−【００９２】，【００９７】，【０１１１】−【０１１３】，【０１２１】，【０１３２】，【０１３７】，【０１５８】−【０１５９】における記載を基に，本件補正をなした旨述べていると解される。
　なお，上記段落に対しては，国内書面及び国際出願翻訳文の提出以降，本件審判請求のときまで，補正も誤訳訂正もなされていない。
　ここで，上記段落における記載事項を確認する(下線は当審が付与。)。
　　　　　　(ア)　段落【００８３】−【００８４】
　【００８３】　あるいは、
ＲＮ　ＢＳＲは、複数のＲＮ　ＤＲＢ報告グループのバッファステータスを含んでもよい
　【００８４】　あるいは、ＲＮ　ＢＳＲは、１つもしくは
複数の個別ＲＮ　ＤＲＢのバッファステータス
複数のＲＮ　ＤＲＢ報告グループの個別バッファステータス
複数のＲＮ　ＤＲＢ報告グループからのバッファステータス
　　　　　　(イ)　段落【００８７】−【００９２】
　【００８７】　あるいは、ＲＮ　ＢＳＲは、いくつかの報告ＷＴＲＵグループのバッファステータス（１つの報告ＷＴＲＵグループにつき１つのバッファステータス）を含んでもよく、各バッファステータスは、報告ＷＴＲＵグループに属する１つまたは複数のＲＮ　ＤＲＢにマッピングされる１つまたは複数のＲＮ　ＷＴＲＵからのアクティブなＲＢのアップリンクバッファ蓄積の合計（または、合計もしくは範囲の指示）である。報告は、報告中の各報告ＷＴＲＵグループの報告ＷＴＲＵグループ識別子（または等価物）を含んでよい。あるいは、報告は、報告ＷＴＲＵグループ識別子を省略できるように、各報告ＷＴＲＵグループのバッファステータスを所定の順序で含んでもよい（例えば、この順序はＲＮにシグナリングされてもよく、または標準で構成済みであってもよい）。あるいは、１組の所定の順序（例えば、ＲＮへのシグナリングに基づく、または標準で定義された）がある場合、報告は、これらの順序のうちの１つを使用し、どの順序が使用されるかを報告中で示すことができ、報告ＷＴＲＵグループ識別子は省略することができる。
　【００８８】　あるいは、ＲＮ　ＢＳＲは、１つもしくは複数の個別ＲＮ　ＤＲＢのバッファステータス、および／または１つもしくは
複数の報告ＷＴＲＵグループ
複数の報告ＷＴＲＵグループ
　【００８９】　ＲＮ　ＤＲＢがＱｏＳごとに（例えばＤＲＢ優先順位もしくはＱＣＩ値によって）編成される場合、ＲＮ　ＢＳＲは、１つのＲＮ−ＤＲＢにマッピングされる１つまたは複数のＱｏＳを有するアクティブなＷＴＲＵ　ＲＢのアップリンクバッファ蓄積の合計（または、合計もしくは範囲の指示）を含んでよい。
　【００９０】　あるいは、ＲＮ　ＢＳＲは、報告ＱｏＳグループに属する１つまたは複数のＲＮ−ＤＲＢにマッピングされる１つまたは複数のＱｏＳを有するアクティブなＷＴＲＵ　ＲＢのアップリンクバッファ蓄積の合計（または、合計もしくは範囲の指示）を含んでもよい。これらのＲＮ　ＤＲＢおよび／または関連するＷＴＲＵ　ＲＢには、同じ報告ＱｏＳグループ識別子を割り当てることができる。
　【００９１】　あるいは、ＲＮ　ＢＳＲは、いくつかの報告ＱｏＳグループそれぞれのバッファステータス（１つの報告ＱｏＳグループにつき１つのバッファステータス）を含んでもよく、各バッファステータスは、報告ＱｏＳグループに属する１つまたは複数のＲＮ　ＤＲＢにマッピングされる１つまたは複数のＱｏＳを有するアクティブなＷＴＲＵ　ＲＢのアップリンクバッファ蓄積の合計（または、合計もしくは範囲の指示）である。報告は、報告中の各報告ＱｏＳグループの報告ＱｏＳグループ識別子（または等価物）を含んでよい。あるいは、報告は、報告ＱｏＳグループ識別子を省略できるように、各報告ＱｏＳグループのバッファステータスを所定の順序で含んでもよい（例えば、この順序はＲＮにシグナリングされてもよく、または標準で固定であってもよい）。あるいは、１組の所定の順序（例えば、ＲＮへのシグナリングに基づく、または標準で定義された）がある場合、報告は、これらの順序のうちの１つを使用し、どの順序が使用されるかを報告中で示すことができ、報告ＱｏＳグループ識別子は省略することができる。
　【００９２】　あるいは、ＲＮ　ＢＳＲは、１つもしくは複数の個別ＲＮ　ＤＲＢのバッファステータス、および／または１つもしくは
複数の報告ＱｏＳグループ
複数の報告ＱｏＳグループ
　　　　　　(ウ)　段落【００９７】
　【００９７】　ＲＮ　ＤＬバッファステータスは、ＲＮ中の総ダウンリンクバッファリング済みデータ
（制御プレーンおよび／またはユーザプレーンデータを含む）
複数の報告ＷＴＲＵグループ
ＷＴＲＵの、ダウンリンク報告ＷＴＲＵグループへのグループ化は、アップリンク報告ＷＴＲＵグループと同様であってもよく
ダウンリンク報告ＱｏＳグループ化構成は、アップリンク報告ＱｏＳグループと同様であってもよく
　　　　　　(エ)　段落【０１１１】−【０１１３】
　【０１１１】　以下、ＲＮ　ＢＳＲ報告をグループ化するための実施形態を開示する。上に開示したように、ＲＮ　ＤＢＲを複数の報告グループにグループ化することができ、各報告グループのバッファ蓄積ステータスをＤｅＮＢに報告することができる。ＢＳＲ報告は、ＱｏＳごとおよびＷＴＲＵごとにグループ化することができる。
　【０１１２】　ＲＮ　ＤＲＢがＱｏＳごとに編成される場合、例えばＲＮ　ＤＲＢ確立時に、ＤｅＮＢによって専用シグナリングを介して報告ＱｏＳグループＩＤを各ＲＮ　ＤＲＢに割り当てることができる。ＲＮ　ＤＲＢがＷＴＲＵごとに編成される場合、例えばＲＮ　ＤＲＢ確立時に、ＤｅＮＢによって専用シグナリングを介して報告ＷＴＲＵグループＩＤを各ＲＮ　ＤＲＢに割り当てることができる。報告グループへのＲＮ　ＤＲＢの割当ては、再割当てまたは取消しができる。取り消された報告グループＩＤを有するＲＮ　ＤＲＢは、報告グループＩＤを割り当てられなかったかのように扱うことができる。
　【０１１３】　ＲＮ　ＤＲＢは、報告グループに割り当てられないこともある。この場合、ＲＮは、ＲＮ　ＤＲＢ　ＢＳＲを単独で、または他の割り当てられた報告グループ（複数可）のＢＳＲと共に、報告することができる。個別のＲＮ　ＤＲＢ　ＢＳＲ報告を独立してトリガすることもできる。
　　　　　　(オ)　段落【０１２１】
　【０１２１】　ＲＮ　ＢＳＲがトリガされると、
ＲＮは、報告グループ（複数可）
　　　　　　(カ)　段落【０１３２】
　【０１３２】　
ＲＮ中で終端しないＷＴＲＵ制御プレーントラフィックは、１つの報告グループとしてグループ化することができる
　　　　　　(ク)　段落【０１３７】
　【０１３７】　別の実施形態では、ＤｅＮＢは、ＲＮ　ＢＳＲを求めてＲＮを明確にトリガすることができる。例えば、構成されたＢＳＲトリガが、十分に頻繁に発生しない場合、またはＤｅＮＢが、セルを再構成する前に何らかの即座のＢＳＲを必要とする場合、ＤｅＮＢは、特定のＲＮ（複数可）に対してＢＳＲをトリガすることができる。ＤｅＮＢがＲＮ　ＢＳＲ報告をトリガするとき、ＤｅＮＢは、報告中の必要とされるステータスタイプ（例えば、報告が、アップリンクＢＳＲかダウンリンクＢＳＲもしくはこの両方、またはＷＴＲＵ　ＢＳＲ、または満足インジケータ、またはこれらの組合せを含み得るかどうか）、および／または報告グループ（どのＤＲＢグループ（ＷＴＲＵごともしくはＱｏＳごと）か、どのＳＲＢグループか、またはこれらの組合せなど）を、指定することができる。ＲＮからの応答は、ＲＲＣメッセージまたはＭＡＣメッセージを介して送ることができる。
　　　　　　(ケ)　段落【０１５８】−【０１５９】
　【０１５８】　５．中継ノードアップリンクバッファステータスが、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ無線ベアラ（ＲＢ）についての、または１つもしくは
複数の報告グループ
　【０１５９】　６．中継ノードダウンリンクバッファステータスが、１つもしくは複数のＷＴＲＵのアクティブなＷＴＲＵ　ＲＢについての、または１つもしくは
複数の報告グループ
　　　　　　(コ)　当審の「請求人の主張」に対する見解
　以上によれば，上申書において請求人が主張するように，「報告グループ」が「複数」存在しうること，つまり「第１の報告グループ」及び「第２の報告グループ」といいうるものが存在することが，本願明細書には記載されているといえる。
　ここで，本願明細書段落【０１３２】(上記(カ)参照。)における記載によれば，「報告グループ」として，「中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する」ものが記載されている，つまり，本件補正発明における「第１の報告グループ」が記載されていると解することができる。
　しかし，当該段落【０１３２】に，「報告グループ」として，「データ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する」ものは明示的に記載されているということはできない。
　この点，請求人は，本願明細書段落【００９７】(上記(ウ)参照。)における記載も根拠としていると解されるので，更に検討する。
　当該段落【００９７】における記載のうち，「ＲＮ　ＤＬバッファステータスは、
ＲＮ中の総
データ
ＲＮ中の総
データ
　これが技術的に意味するところは，「ユーザプレーンデータ」が，「ＲＮ　ＤＬバッファ」においてどのような「状態」となっているか，つまり，当該「ＲＮ　ＤＬバッファ」において，「どの程度バッファされているのか」を示すことができることを意味していると解される。
　このことは，当該段落【００９７】における記載からは，「データ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する」事項が記載されているといえるにとどまり，当該事項に関する「報告グループ」が生成されることの記載が明示的に記載されているとまではいうことのできないことを示しているといえる。
　つまり，本件補正発明における「第２の報告グループ」は，本願明細書に記載された事項ではないことを示しているといえる。
　更に，本件補正発明における「１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループ」が本願明細書に記載された事項であったとしても，本件補正発明における「ドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るステップ」で送られる「中継ノードＢＳＲ」が，本件補正発明における「第１の報告グループ」及び「第２の報告グループ」の両方の「報告グループ」を含む「中継ノードＢＳＲ」として，「ドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)」に送ることに関する記載を，本願明細書の記載から発見することもできない。
　　　　オ　まとめ
　以上のとおりであるから，本件補正発明が，発明の詳細な説明に記載されたものであるということはできない。
　また，発明の詳細な説明の記載が，本件補正発明について，当業者が実施することができる程度に明確かつ十分に記載したものであるということもできない。
　したがって，本件出願は，本件補正発明に関して，特許法第３６条第４項第１号，同条第６項第１号に規定する要件を満たしていないものに該当するといえる。
　よって，本件補正発明は，特許出願の際独立して特許を受けることができないものに該当する。
　　　(２)　補足的検討２(２９条２項について)
　　　　ア　引用例及び引用発明
　原査定の理由に引用された国際公開第２００９／０８８９３７号(２００９年(平成２１年)７月１６日国際公開。以下「引用例」という。)には，図面とともに次の事項が記載されている。なお，当審訳として対応する日本語公報特表２０１１−５０９０５２号公報(平成２３年３月１７日公表)を参考する。
(下線は，引用例に附されたものを除き，当審が付与。)
　　　　◇ａ　記載事項１
　　[0002] TECHNOLOGY FIELD
　　[0003] The present disclosure is related to wireless communications.
(国際公開１ページ)
(当審訳
　［０００２］　技術分野
　［０００３］　本開示は、無線通信に関する。
(【０００１】))
　　　　◇ｂ　記載事項２
　　[0022] SUMMARY
　　[0023] A method and apparatus for cooperation in wireless communications. Cooperation is considered among a number of network elements, including at least one wireless transmit-receive unit, at least one relay station, and at least one base station.
(国際公開５ページ)
(当審訳
　［００２２］要約
　［００２３］　無線通信における協調のための方法および装置。協調は、少なくとも１つの無線送受信ユニット、少なくとも１つの中継局、および少なくとも１つの基地局を含むいくつかのネットワーク要素の中で考えられる。
(【００１９】))
　　　　◇ｃ　記載事項３
　　[0079] When referred to hereafter, the terminology wireless transmit/receive unit (WTRU) includes but is not limited to a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology base station includes but is not limited to a Node-B, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment. When referred to hereafter, the terminology relay station may be referred to as a relay or a RS.
　　[0080] Although this disclosure is described in the context of a Third Generation (3G) cellular wireless system, it should not be construed as limited to that system, the 3G system serves only as an example.
　　[0081] 
Relay Physical Architectures
　　[0082] Relays may be used in Cellular Systems in a number of ways. In this section, 4 major architectures are described and depicted in Figure 1. These 4 example architectures may be used alone or in any combination. These example architectures are referred to as Architecture-1: forwarding relay architecture 110; Architecture-2: multiple-WTRU-serving-relay architecture 120 (also shown in more detail in Figure 3); Architecture-3: cooperative relay architecture 130 (also shown in more detail in Figure 2); and Architecture-4: multiple-BS- shared-relay architecture 140. Each example architecture includes at least one WTRU 150, at least one relay station (RS) 160, and a base station (BS) 195.
　　[0083] Each WTRU 150 may contain a transmitter 165, a receiver 170, and a processor 175. Each RS 160 may contain a transmitter 180, a receiver 185, and a processor 190.
　　[0084] Various signals may be transmitted and received by the various nodes in each of these architectures and are described in detail below. In fact, several signaling embodiments may exist per each architecture. We shall refer to these embodiments collectively as relay transmission schemes or simply as transmission schemes. The advantages and applications of the above 4 architectures are discussed below.
　　[0085] In Architecture-1 110, the WTRU may receive signals only from the RS 160, but not directly from the BS 195. In other words, the WTRU 110 is in a deeply shadowed region of the BS coverage or simply in a BS coverage hole. It is also an architecture useful to serve WTRUs at the edge of a cell, where the inter-cell interference from adjacent cells can be large. In such cases, the forwarding relay 160 receives the DL data from the BS 195 and simply forwards it to the WTRU 150 and vice versa for UL data. A variation to the forwarding relay architecture is one where there are multiple relays connected (wirelessly) in series. This is depicted in Figure 4.
　　[0086] In Architecture-2 120, the RS 160 serves multiple WTRUs 150, that are located in the coverage region of the RS 160. The advantage of this architecture is that the BS-RS data communication may be pooled together, to reduce overhead. For example, the overhead associated with various packet headers may be reduced by defining a combined header for the pooled packets.
　　[0087] In Architecture-3 130, the WTRU 150 may also be able to receive and process signals directly from the BS 195, although typically weaker than the signals received from the RS 160. Such a configuration has two important implications. First, as the BS 195 is sending DL data to the RS 160, the WTRU 150 may monitor and receive some of the data or all of the data with a certain probability of error. This type of data is often referred to as 'soft' data. This reduces the amount of data to be 'forwarded' by the RS 160 or it increases the probability of successful reception of the data 'forwarded' by the RS 160. Second, the BS 195 and the RS 160 may simultaneously transmit two 'cooperative' signals to the WTRU 150, emulating a multiple antenna scenario. Since the 'multiple antennas' in this case are not collocated, we refer to this as 'distributed MIMO' configuration. The advantages of this Architecture are similar to the benefits of using MIMO.
　　[0088] Architecture-4 140 allows multiple RSs 160 to assist a WTRU 150. This example may also be viewed as a distributed-MIMO configuration, with its consequent improvements in performance.
　　[0089] Combining two or more of the 4 basic architectures in a technically straight-forward manner may yield practical configurations to overcome the problems discussed above.
(国際公開８ページ〜１１ページ)
(当審訳
　［００７９］　以下で言及するとき、「ＷＴＲＵ(無線送受信ユニット)」という用語は、それだけには限定されないが、ＵＥ(ユーザ機器)、移動局、固定式または携帯式の加入者ユニット、ページャ、セルラ電話、ＰＤＡ(携帯情報端末)、コンピュータ、または無線環境で動作することができる他の任意のタイプのユーザ装置を含む。以下で言及するとき、「基地局」という用語は、それだけに限定されないが、Ｎｏｄｅ−Ｂ、サイトコントローラ、ＡＰ(アクセスポイント)、または無線環境で動作することができる他の任意のタイプのインターフェイス装置を含む。以下で言及するとき、「中継局」という用語は、リレーまたはＲＳと呼ぶこともある。
　［００８０］　本開示は、３Ｇ(第３世代)のセルラ無線システムの文脈で説明されているが、そのシステムに限定されると解釈されるべきではなく、３Ｇシステムは、一例としての役割を果たすにすぎない。
　［００８１］　
リレーの物理的アーキテクチャ
　［００８２］　リレーは、セルラシステムにおいていくつかの方法で使用され得る。このセクションでは、４つの主なアーキテクチャについて説明し、図１に示す。こうした４つのアーキテクチャ例は、単独で、または任意の組み合わせで使用することができる。こうしたアーキテクチャ例は、アーキテクチャ１：転送リレーアーキテクチャ１１０、アーキテクチャ２：複数ＷＴＲＵサービングリレーアーキテクチャ１２０（図３にもより詳しく示される）、アーキテクチャ３：協調リレーアーキテクチャ１３０（図２にもより詳しく示される）、およびアーキテクチャ４：複数ＢＳ共有リレーアーキテクチャ１４０と呼ばれる。各アーキテクチャ例は、少なくとも１つのＷＴＲＵ１５０、少なくとも１つの中継局(ＲＳ)１６０、および基地局(ＢＳ)１９５を含む。
　［００８３］　各ＷＴＲＵ１５０は、送信機１６５、受信機１７０、およびプロセッサ１７５を含み得る。各ＲＳ１６０は、送信機１８０、受信機１８５、およびプロセッサ１９０を含み得る。
　［００８４］　様々な信号は、これらのアーキテクチャのそれぞれにおいて、様々なノードによって送受信することができ、以下で詳しく説明される。実際に、いくつかのシグナリングの実施形態は、アーキテクチャごとに存在し得る。これらの実施形態をまとめて「リレー送信方式」または単に「送信方式」とも呼ぶ。上記の４つのアーキテクチャの利点および用途について、以下で説明する。
　［００８５］　アーキテクチャ１　１１０において、ＷＴＲＵは、ＢＳ１９５から直接ではなく、ＲＳ１６０からのみ信号を受信することができる。言い換えれば、ＷＴＲＵ１１０は、ＢＳカバレージの深く影になっている範囲、または単にＢＳカバレージホールにある。これは、隣接セルからのセル間干渉が大きい可能性のあるセルの端部にあるＷＴＲＵにサービスを提供するのに有用なアーキテクチャでもある。こうした場合、転送リレー１６０は、ＢＳ１９５からＤＬデータを受信し、単にそれをＷＴＲＵ１５０に転送し、ＵＬデータについては、この逆を行う。転送リレーアーキテクチャの変形は、
直列で（無線で）接続された複数のリレーがあるものである。これは、図４に示される
　［００８６］　アーキテクチャ２　１２０において、ＲＳ１６０は、ＲＳ１６０のカバレージ範囲内にある複数のＷＴＲＵ１５０にサービスを提供する。このアーキテクチャの利点は、ＢＳ−ＲＳデータ通信が一緒にプールされて、オーバヘッドを低減することができることである。例えば、様々なパケットヘッダに関連付けられたオーバヘッドは、プールされたパケットのために結合されたヘッダを定義することによって低減することができる。
　［００８７］　アーキテクチャ３　１３０において、ＷＴＲＵ１５０は、ＢＳ１９５から直接信号を受信し、処理することもできるが、通常、ＲＳ１６０から受信された信号より弱い。こうした構成には、２つの重要な意味がある。第１に、ＢＳ１９５がＲＳ１６０にＤＬデータを送信しているとき、ＷＴＲＵ１５０は、ある確率の誤りを有するデータの一部またはすべてを監視し、受信し得る。このタイプのデータは、しばしば「ソフト」なデータと呼ばれる。これによって、ＲＳ１６０によって「転送」されるデータの量が低減され、または、ＲＳ１６０によって「転送」されるデータの受信の成功率が増加する。第２に、ＢＳ１９５およびＲＳ１６０は、マルチアンテナのシナリオをまねて、２つの「協調」信号をＷＴＲＵ１５０に同時に送信することができる。この場合の「マルチアンテナ」は、連結されていないため、これを「分散ＭＩＭＯ」構成と呼ぶ。このアーキテクチャの利点は、ＭＩＭＯを使用する利点と似ている。
　［００８８］　アーキテクチャ４　１４０では、複数のＲＳ１６０が１つのＷＴＲＵ１５０を補助することができる。この例は、分散ＭＩＭＯ構成と見なすこともでき、その結果として性能が向上する。
　［００８９］　技術的に簡単な方法で４つの基本的なアーキテクチャのうちの２つ以上を結合することによって、上述した問題を克服するための実用的な構成がもたらされ得る。
(【００２２】〜【００３１】))
　　　　◇ｄ　記載事項４
　　[00210] 
Relay Protocol Architectures
　　[00211] The following example operations in 
the user plane
　　[00212] The BS treats the relay as a WTRU and communicates with it. The relay, on the other hand, acts as a BS towards the WTRU and conducts the communication. In order to describe the next level of communication actions, it is necessary to assume the protocol layers supported by the relay.
　　[00213] Consider the BS-side of the RS. Since this side simulates the WTRU, there are choices in terms of how much of the WTRU protocol stack is implemented. Following are various alternatives.
　　[00214] Figure 19 shows a first alternative 1900. The BS-side of the relay 1910 implements the WTRU protocol stack up to the PHY level. The PHY processing at the RS may be performed in alternative ways. A first alternative, denoted amplify and forward (AF) relay, involves simple amplification at the RF level and forwarding. A second alternative is demodulate-remodulate-and-forward. In this alternative noise may be removed or suppressed but only in those cases when the link to the relay is of very high fidelity (i.e. a channel code is effectively not necessary). A third alternative is decode-reencode-and-forward (DF) relay. Here there is further processing of the signal such that the errors are corrected at the RS.
　　[00215] During the relaying process, the radio signal characteristics on the BS-RS link and the RS-WTRU link need not be the same. In a first option, the RS-WTRU link may use different frequencies or codes compared to the BS-RS link. In a second option, the modulations on the RS-WTRU link may be different from the modulation on the BS-RS link. In a third option, the error protection (i.e. detecting and/or correcting) codes may be different on the BS-RS and RS-WTRU links.
(国際公開３８ページ〜３９ページ)
(当審訳
　［００２１０］　
リレープロトコルアーキテクチャ
　［００２１１］　
ユーザプレーン
　［００２１２］　ＢＳは、リレーをＷＴＲＵと見なし、それと通信する。一方、リレーは、ＷＴＲＵに対するＢＳとして働き、通信を行う。次のレベルの通信アクションについて説明するために、リレーによってサポートされるプロトコルレイヤを想定する必要がある。
　［００２１３］　ＲＳのＢＳサイドについて検討する。このサイドは、ＷＴＲＵをシミュレーションするため、どれだけのＷＴＲＵプロトコルスタックが実装されるかに関する選択肢がある。以下は、様々な代替である。
　［００２１４］　図１９は，
第１の代替１９００を示す。ＢＳサイドのリレー１９１０は，ＰＨＹレベルまでＷＴＲＵプロトコルスタックを実装する。ＲＳでのＰＨＹ処理は，代替的方法で実行され得る。第１の代替は，ＡＦ（増幅及び転送）リレーとして表され，ＲＦレベルでの簡単な増幅，及び転送することを伴う
　［００２１５］　中継プロセス中，ＢＳ−ＲＳリンク及びＲＳ−ＷＴＲＵリンクにおける無線信号の特性が同じである必要はない。第１の選択肢において，ＲＳ−ＷＴＲＵリンクは，ＢＳ−ＲＳリンクに比べて，異なる周波数又は符号を使用することができる。第２の選択肢において，ＲＳ−ＷＴＲＵリンクにおける変調は，ＢＳ−ＲＳリンクにおける変調とは異なり得る。第３の選択肢において，誤り保護（すなわち，検出及び／又は訂正）符号は，ＢＳ−ＲＳリンク及びＲＳ−ＷＴＲＵリンクにおいて異なり得る。
(【０２２５】〜【０２２９】))
　　　　◇ｅ　記載事項５
　　[00230] Figure 23 is a diagram of an example illustrating the sequence of events 2300 involved for a MAC-level RS. Figure 23 shown does not address the problem of potential buffer overflows at the relay's MAC. Specifically, because the BS 2310 does not know when the relay has successfully (or unsuccessfully) forwarded the data to the WTRU 2320, it may attempt to push more data than the RS's buffer can handle. To prevent this, one or more of the following options may be used. These options are not exclusive and may be combined.
　　[00231] In a first embodiment, the BS 2310 autonomously maintains an estimate as to the state of the relay buffer by knowing the maximal number of attempts the RS 2330 makes to transmit data and how long it takes. It can also take into account the average time to deliver packets from the RS 2330 to the WTRU 2320, which can be periodically updated by the relay.
　　[00232] In a second embodiment, 
the RS 2330 periodically communicates buffer occupancy status to the BS 2310
　　[00233] In a third embodiment, 
the RS 2330 incorporates buffer occupancy status into the feedback (together with, e.g. channel state information) that the BS 2310 uses to schedule its transmissions
　　[00234] In a fourth embodiment, if its buffer is full, the RS 2330 responds with a special buffer full NACK whenever the BS 2310 attempts to push data to it. This is performed at the time of first BS-to-relay attempt and prevents the BS 2310 from re-transmitting until either a specified back-off time period has elapsed, or the relay issues a special data request communication to the BS 2310, or a free buffer is reported above.
　　[00235] A fifth embodiment, similar to the fourth, is to have a special ACK that indicates that the buffer is almost full. In this example, the RS 2330 will accept this packet, but not the next one. The BS 2310 behavior is then similar to above - it can back off and/or wait for the RS 2330 to report that its buffer is OK.
　　[00236] A sixth embodiment introduces a delayed secondary ACK/NACK from the RS 2330 to the BS 2310 that may report to the BS 2310 when a delivery of particular packet to the WTRU 2320 succeeded or was abandoned. This allows the BS 2310 to maintain the state of the relay buffer and schedule accordingly.
(国際公開４２ページ〜４３ページ)
(当審訳
　［００２３０］　図２３は、ＭＡＣレベルのＲＳについて関与するイベント２３００のシーケンスを示す一例の図である。示される図２３は、リレーのＭＡＣでの潜在的なバッファオーバフローの問題に対処しない。具体的に、ＢＳ２３１０は、リレーがいつデータを正常に(あるいは不成功に)ＷＴＲＵ２３２０に転送したかを知らないため、ＲＳのバッファが扱うことができるより多くのデータをプッシュしようと試みる場合がある。これを防ぐために、以下の選択肢のうちの１つまたは複数を使用することができる。これらの選択肢は、排他的ではなく、結合されてもよい。
　［００２３１］　第１の実施形態において、ＢＳ２３１０は、データを送信するためにＲＳ２３３０が行う試行の最大数、およびそれがどのぐらいかかるかを知ることによって、リレーバッファの状態に関する推定を自発的に維持する。また、それは、ＲＳ２３３０からＷＴＲＵ２３２０にパケットを配信するための平均時間を考慮に入れることができ、これは、リレーによって定期的に更新することができる。
　［００２３２］　第２の実施形態において、
ＲＳ２３３０は、ＢＳ２３１０にバッファ占有状況を定期的に伝える
　［００２３３］　第３の実施形態において、
ＲＳ２３３０は、ＢＳ２３１０がその送信をスケジュールするために使用するフィードバックに(例えばチャネル状態情報と共に)バッファ占有状況を組み込む
　［００２３４］　第４の実施形態において、そのバッファがいっぱいである場合、ＲＳ２３３０は、ＢＳ２３１０がそれにデータをプッシュしようと試みるときはいつでも、特別な「バッファがいっぱい」ＮＡＣＫで応答する。これは、第１のＢＳ−リレーの試行のときに行われ、指定されたバックオフ期間が経過するまで、リレーがＢＳ２３１０に特別なデータ要求通信を発行するまで、または空のバッファが上に報告されるまで、ＢＳ２３１０が再送できないようにする。
　［００２３５］　第５の実施形態は、第４の実施形態と似ており、バッファがほぼいっぱいであることを示す特別なＡＣＫを有するものである。この例において、ＲＳ２３３０は、次のものではなくこのパケットを受け入れる。次いでＢＳ２３１０の挙動は、上記に似ており、これはバックオフすることができ、および／またはＲＳ２３３０がそのバッファがＯＫであることを報告するのを待つことができる。
　［００２３６］　第６の実施形態は、ＷＴＲＵ２３２０への特定のパケットの配信が成功した、または破棄されたとき、ＢＳ２３１０に報告することができる、ＲＳ２３３０からＢＳ２３１０への遅れた２次ＡＣＫ／ＮＡＣＫを導入する。これによってＢＳ２３１０は、リレーバッファの状態を維持し、それに応じてスケジュールすることができる。
(【０２４４】〜【０２５０】))
　　　　◇ｆ　記載事項６
　　[00333] 
HSUPA Serving Grant Methodology
　　[00334] The HSUPA channel is the Enhanced Dedicated Physical Channel (EPDCH). The BS controls the allocation of the E-DPCH among all WTRUs and this controlled scheduling is based on a set of rules on how the WTRU shall behave with respect to specific signaling.
　　　[00335] 
The BS sends a resource indication in the downlink called a 
scheduling grant
 (SG)
This SG indicates to the WTRU the maximum amount of uplink resources it may use
　　[00336] The scheduling grants have the following characteristics: scheduling grants control the maximum allowed E-DPD CH/DPC CH power ratio, and scheduling grants can be sent once per TTI or slower. There are two types of grants.
　　[00337] The absolute grants provide an absolute limitation of the maximum amount of UL resources the WTRU may use. The second grant is the relative grant which directs the WTRU to increase or decrease the resource limitation compared to the previously used value. Absolute grants are sent by the serving E-DCH cell. They are valid for one WTRU, for a group of WTRUs or for all WTRUs in the cell. This is done by allocating up to two identities (called primary and secondary) for each WTRU, and by the UTRAN allocating the same identity to a group of WTRUs. Relative grants may be sent by the serving and non-serving node-Bs as a complement to absolute grants. The WTRU behaviour is exactly the same for relative grants for one WTRU, for a group of WTRUs and for all WTRUs. The relative grant from the serving E-DCH RLS may take one of the three values: UP, HOLD or DOWN'. The relative grant from the non-serving E-DCH RL may take one of the two values: HOLD or DOWN'.
　　[00338] 
The following information is provided by the WTRU to the BS to assist in the scheduling grant allocation
This information is provided in the scheduling information (SI)
Some examples of information in the SI include the WTRU Buffer occupancy (in bytes), total buffer status, buffer status for the highest priority logical channel with data in the buffer, as a fraction of the total reported buffer, and WTRU Power Headroom (UPH)
(国際公開６８ページ〜６９ページ)
(当審訳
　［００３３３］　
ＨＳＵＰＡサービング許可方法
　［００３３４］　ＨＳＵＰＡチャネルは、ＥＰＤＣＨ(拡張専用物理チャネル)である。ＢＳは、すべてのＷＴＲＵ中のＥ−ＤＰＣＨの割り当てを制御し、この制御されたスケジューリングは、ＷＴＲＵが特定のシグナリングに関してどのように挙動すべきかについての１組のルールに基づく。
　［００３３５］　
ＢＳは、「ＳＧ」(スケジューリング許可)と呼ばれるリソース指示を、ダウンリンクにおいて送信する
このＳＧは、ＷＴＲＵに、それが使用できる最大量のアップリンクリソースを指示する
　［００３３６］　スケジューリング許可は、以下の特徴を有する。スケジューリング許可は、最大許容Ｅ−ＤＰＤＣＨ／ＤＰＣＣＨ電力比を制御し、ＴＴＩ当たり１回以下で送信され得る。２つのタイプの許可がある。
　［００３３７］　絶対的な許可は、ＷＴＲＵが使用し得る最大量のＵＬリソースの絶対的な制限を提供する。第２の許可は、以前使用された値に比べて、リソース制限を増減するようＷＴＲＵに指示する相対的な許可である。絶対的な許可は、サービングＥ−ＤＣＨセルによって送信される。これらは、１つのＷＴＲＵについて、１グループのＷＴＲＵについて、またはセル内のすべてのＷＴＲＵについて有効である。これは、ＷＴＲＵごとに２つまでの識別(「１次」および「２次」と呼ばれる)を割り当て、ＵＴＲＡＮが同じ識別を１グループのＷＴＲＵに割り当てることによって行われる。相対的な許可は、絶対的な許可に対する補完としてサービングおよび非サービングｎｏｄｅ−Ｂによって送信され得る。ＷＴＲＵ挙動は、１つのＷＴＲＵ、１グループのＷＴＲＵ、およびすべてのＷＴＲＵについての相対的な許可について正確に同じである。サービングＥ−ＤＣＨ　　ＲＬＳからの相対的な許可は、３つの値「アップ」、「ホールド」、「ダウン」のうちの１つを取り得る。非サービングＥ−ＤＣＨ　　ＲＬからの相対的な許可は、２つの値「ホールド」または「ダウン」のうちの１つを取り得る。
　［００３３８］　
以下の情報は、スケジューリング許可割り当てを補助するために、ＷＴＲＵによってＢＳに提供される
この情報は、ＳＩ(スケジューリング情報)で提供される
ＳＩ内の情報のいくつかの例は、ＷＴＲＵバッファ使用量(バイト単位)、合計バッファ状況、合計報告バッファの一部としてバッファ内にデータを有する優先順位が最も高い論理チャネルのバッファ状況、およびＷＴＲＵ　　ＵＰＨ(電力余分)を含む
(【０３４５】〜【０３４９】))
　　　　◇ｇ　記載事項７
　　[00342] 
Link between BS and Relay
　　[00343] An important piece of the communication is the link between the relay and the BS. For example, if the bandwidth available for communication between the relay- BS link is lower than the bandwidth available for communication between the relay and the WTRUs, the system might become unbalanced and the relay will start to queue and possibly drop the WTRU packets because it is not able to forward such packets to the BS.
　　[00344] 
Some signaling messages between the relay and the BS are defined in the table below
　　　the table(表)は省略。
　　[00345] The objective of these messages is to help the BS to perform allocations to the WTRUs associated with a single relay, allocations for communication between each relay and the BS, and balance the allocations between WTRUs associated with different relays. 
　　[00346] 
Example 1: WTRU Communicates with Relay Only
　　[00347] 
Centralized Scheduling
　　[00348] In the centralized scheduling the BS allocates a scheduling grant (SG) to each WTRU and this SG is sent from the BS to the WTRU via the relay. The relay will simply forward the allocation to the WTRUs.
　　[00349] 
Because the WTRU communicates directly with the relay, the SI sent by the WTRU will reflect the link between the WTRU and the relay and the BS can use that information to perform the grant allocation
　　[00350] In order to account for that, 
we introduce a 
relay SI,
 which will reflect the capacity of that relay
The 
relay SI,
, together with the higher layer signaling messages defined above, can be used to control not only the SG allocation to the WTRUs but also the bandwidth allocated to the BS-relay channel
　　[00351] Figure 51 is a diagram of an example frame structure for an SI 5100. Referring to Figure 51, the frame structure for SI reporting from the relay to the BS includes a relay SI 5110, at least one WTRU ID 5120, and at least one SI 5130.
　　[00352] 
Hierarchical Scheduling
　　[00353] In the hierarchical scheduling the BS assigns grants to the relays, which in turn, based on the grant received, the SIs received from the WTRUs, and some other QoS information related to the WTRUs, assigns grants to the different WTRUs associated to that relay. Note that in this case control of serving grant allocation to the WTRUs is given to the relays.
　　[00354] In order to guarantee that the BS assigns enough grants to the relays, the relay needs to send a combined SI, which contains the SI combined from all WTRUs.
　　[00355] 
Difference between 
Combined SI
 and 
Relay SI
　　[00356] Note that the combined SI and the relay SI described above may be different because they serve different purposes.
　　[00357] The relay SI is used to reflect the capacity of the relay, so it contains information such as how full the relay buffer and the channel condition between the relay and BS. The BS then uses that information in conjunction with the WTRUs' SIs.
　　[00358] 
The 
combined SI
 contains information related to the buffer and channel condition for all WTRUs combined, so that the BS can allocate enough resources to the BS, which will then divide that among the WTRUs. In that case the BS uses the 
combined SI
 (and not the WTRUs SIs) to assign the Serving Grant to the relay
　　[00359] Note that for the hierarchical scheduling, the relay could also send the relay SI information to the BS, in which case the BS could use both the combined SI and the relay SI to perform grant allocation to the relay.
　　[00360] In other words, 
the 
relay SI
 contains information necessary to control the communication between the relay and the BS (used for both the centralized and hierarchical case). The 
combined SI
 simply replaces the WTRUs' SIs by combining information for all WTRUs in one SI (used for hierarchical case only)
(国際公開７０ページ〜７３ページ)
(当審訳
　［００３４２］　
ＢＳとリレーとの間のリンク
　［００３４３］　通信の重要な部分は、リレーとＢＳとの間のリンクである。例えば、リレー−ＢＳリンク間の通信に使用可能な帯域幅がリレーとＷＴＲＵとの間の通信に使用可能な帯域幅より低い場合、システムはアンバランスになる場合があり、リレーは、ＷＴＲＵパケットをキューに入れ始め、場合によってドロップする。というのは、それは、こうしたパケットをＢＳに転送することができないからである。
　［００３４４］　リレーとＢＳとの間の
シグナリングメッセージのいくつかは、以下の表において定義される
　　　the table(表【０３５４】【表３】)は省略。
　［００３４５］　これらのメッセージの目的は、ＢＳが単一リレーに関連付けられたＷＴＲＵへの割り当て、各リレーとＢＳとの間の通信のための割り当てを行い、異なるリレーに関連付けられたＷＴＲＵ間で割り当てのバランスをとるのを助けることである。
　［００３４６］　
例１：リレーのみとのＷＴＲＵの通信
　［００３４７］　
中央スケジューリング
　［００３４８］　中央スケジューリングにおいて、ＢＳは、ＳＧ(スケジューリング許可)を各ＷＴＲＵに割り当て、このＳＧは、リレーを介してＢＳからＷＴＲＵに送信される。リレーは、単に割り当てをＷＴＲＵに転送する。
　［００３４９］　
ＷＴＲＵがリレーに直接通信するので、ＷＴＲＵによって送信されたＳＩは、ＷＴＲＵとリレーとの間のリンクを反映し、ＢＳは、許可割り当てを行うために，その情報を使用することができる
　［００３５０］　それを考慮に入れるために、
「リレーＳＩ」を導入し，この「リレーＳＩ」はそのリレーの容量を反映する
「リレーＳＩ」を、上記で定義した上位層シグナリングメッセージ(the higher layer signaling messages)と共に、ＷＴＲＵへのＳＧ割り当てだけではなく、ＢＳ−リレーチャネルに割り当てられた帯域幅を制御するために使用することができる
　［００３５１］　図５１は、ＳＩ５１００のフレーム構造の一例の図である。
図５１を参照すると、リレーからＢＳに報告するＳＩのフレーム構造は、リレーＳＩ５１１０、少なくとも１つのＷＴＲＵ　ＩＤ５１２０、および少なくとも１つのＳＩ５１３０を含む
　［００３５２］　
階層スケジューリング
　［００３５３］　階層スケジューリングにおいて、ＢＳは、許可をリレーに割り当て、次いでリレーは、受信された許可、ＷＴＲＵから受信されたＳＩ、およびＷＴＲＵに関連する他の何らかのＱｏＳ情報に基づいて、そのリレーに関連する異なるＷＴＲＵに許可を割り当てる。この場合、ＷＴＲＵへのサービング許可割り当ての制御がリレーに提供されることに留意されたい。
　［００３５４］　【０３６１】　
ＢＳが、リレーに十分な許可を割り当てることを保証するために、リレーは、「結合されたＳＩ」を送信する必要があり，当該「結合されたＳＩ」は，すべてのＷＴＲＵから結合されるＳＩを含む
　［００３５５］　
「結合されたＳＩ」と「リレーＳＩ」との間の違い
　［００３５６］　上述した「結合されたＳＩ」および「リレーＳＩ」は、それらが異なる目的を果たすために異なり得ることに留意されたい。
　［００３５７］　
「リレーＳＩ」は、リレーの容量を反映するために使用されるので、「リレーＳＩ」は、リレーバッファがどれだけいっぱいであるか、リレーとＢＳとの間のチャネル状態などの情報を含む
　［００３５８］　
「結合されたＳＩ」は、結合されたＷＴＲＵすべてに対するバッファおよびチャネル状態に関連する情報を含み、そのため、ＢＳは、ＢＳに十分なリソースを割り当てることができ、次いでＢＳは、ＷＴＲＵ(WTRUs)間でリソースを分ける。その場合、ＢＳは、サービング許可をリレーに割り当てるために，「結合されたＳＩ」(ＷＴＲＵ　ＳＩではない)を使用する
　［００３５９］　階層スケジューリングについて、次のことに留意されたい，
リレーは、「リレーＳＩ」情報をＢＳに送信することもでき、この場合、ＢＳは、リレーに対する許可割り当てを実行するために，「結合されたＳＩ」および「リレーＳＩ」の両方を使用することができる
　［００３６０］　言い換えると、
「リレーＳＩ」は、リレーとＢＳとの間の通信を制御するために必要な情報を含む(中央および階層の両方のケースに使用される)。「結合されたＳＩ」は、単に、ＷＴＲＵ(ＷＴＲＵｓ)のＳＩ(ＳＩｓ)を、すべてのＷＴＲＵ(ＷＴＲＵｓ)についての情報を１つのＳＩに結合することによって，置き換える(階層のケースのみに使用される)
(【０３５２】〜【０３６６】))
　　　　◇ｈ　図４記載事項
　　　　◇ｉ　図５１記載事項
　　　　◇ｊ　引用発明
　以上によれば，引用例には次の発明(以下「引用発明」という。)が記載されているといえる。
　ＷＴＲＵがリレーに直接通信するので，ＷＴＲＵによって送信されたＳＩは，ＷＴＲＵとリレーとの間のリンクを反映し，ＢＳは，許可割り当てを行うために，その情報を使用することができ，
　「リレーＳＩ」はそのリレーの容量を反映し，「リレーＳＩ」を，定義された上位層シグナリングメッセージと共に，ＷＴＲＵへのＳＧ割り当てだけではなく，ＢＳ−リレーチャネルに割り当てられた帯域幅を制御するために使用することができ，
　リレーからＢＳに報告するＳＩのフレーム構造は，リレーＳＩ，少なくとも１つのＷＴＲＵ　ＩＤ，および少なくとも１つのＳＩ含み，
　ＢＳが，リレーに十分な許可を割り当てることを保証するために，リレーは，すべてのＷＴＲＵから結合されたＳＩを含む「結合されたＳＩ」を送信する必要があり，
　「リレーＳＩ」は，リレーの容量を反映するために使用されるので，「リレーＳＩ」は，リレーバッファがどれだけいっぱいであるか，リレーとＢＳとの間のチャネル状態などの情報を含み，
　「結合されたＳＩ」は，結合されたすべてのＷＴＲＵについてのバッファ及びチャネル状態に関連する情報を含み，
　「リレーＳＩ」は，リレーとＢＳとの間の通信を制御するために必要な情報を含み，「結合されたＳＩ」は，単に，ＷＴＲＵ(ＷＴＲＵｓ)のＳＩ(ＳＩｓ)を，すべてのＷＴＲＵ(ＷＴＲＵｓ)についての情報を１つのＳＩに結合することによって，置き換える
　方法。
　　　　イ　参考文献及び参考技術
　　　　　(ア)　参考文献１
　本件出願の優先権主張日前に公知である「3GPP TSG-RAN3#64，R3-091228，Title:　Relay Requirements  Use Case Study in LTE-Advanced」(２００９年(平成２１年)４月２９日発行)(以下「参考文献１」という。)
には，次の記載がある。
1.　　Introduction
In the last RAN2 meeting (RAN2#65bis), RAN2 agreed the definition of Nodes and interfaces. 
　　Nodes:
　　　-　
Donor-eNB: eNB to which Relay-Node connects wirelessly to
　　　-　
Relay-Node: entity which exists between Donor-eNB and UE
　　　-　UE: could be LTE Rel-8 UE (i.e. backward compatibility is supported)
　　Interfaces:
　　　-　Uu: interface between UE and Relay-Node
　　　-　Un: interface between Relay-Node and Donor-eNB
RAN2 also concluded following protocol architecture issues. 
　1)　On Uu interface, all AS control plane protocols are terminated in the Relay-Node
　2)　On Uu interface, all AS user plane protocols are terminated in the Relay-Node
　3)　Un interface should be standardized in 3GPP specification
　4)　On Un interface, user plane will have MAC, RLC and PDCP. It is FFS if they are identical to Uu MAC, RLC and PDCP
　5)　On Un interface, control plane is still FFS
Based on above agreements, this document discusses high level requirements for Relay architecture and priority of use cases and mobility scenarios. This document also identifies issues to be clarified for the architecture study based on the prioritized use cases and mobility scenarios. 
(当審訳
１．はじめに
　最後のＲＡＮ２会議(ＲＡＮ２＃６５ｂｉｓ)において，ＲＡＮ２は，ノード(Nodes)とインタフェース(interfaces)の定義に合意した。
ノード(Nodes)：
　　−　
ドナーｅＮＢ(Donor-eNB)：リレーノードが無線で接続するｅＮＢ
　　−　
リレーノード(Relay-Node)：ドナーｅＮＢとＵＥとの間に存在するエンティティ
　　−　ＵＥ：ＬＴＥのＲｅｌ−８のＵＥとなり得る(すなわち，下位互換性がサポートされている)
インタフェース(Interfaces)：
　　−　Ｕｕ：ＵＥとリレーノードとの間のインタフェース
　　−　Ｕｎ：リレーノードとドナーｅＮＢとの間のインタフェース
　ＲＡＮ２はまた，次のプロトコル・アーキテクチャの問題を終わりにした。
　　１)　Ｕｕインタフェース上で，コントロールプレーンプロトコルは，リレーノードで終端されるＡＳ(アクセス・ストレータム)のすべて
　　２)　Ｕｕインタフェース上で，ユーザプレーンプロトコルは，リレーノードで終端されるＡＳ(アクセス・ストレータム)のすべて
　　３)　Ｕｎインターフェースは，３ＧＰＰ仕様で標準化する必要がある
　　４)　Ｕｎインターフェース上で，ユーザプレーンは，ＭＡＣ，ＲＬＣ及びＰＤＣＰを持つことになる。それらがＵｕ，ＭＡＣ，ＲＬＣ及びＰＤＣＰに同一である場合，ＦＦＳ(さらなる検討)である
　　５)　Ｕｎインターフェース上で，コントロールプレーンは，まだＦＦＳのままである
　上記の合意に基づき，このドキュメントは，リレーアーキテクチャとユースケースの優先度とモビリティのシナリオに対する高レベルの要求を論じる。)
　更に，上記に関連して次の事項を参考に記す。
「ＦＦＳ」＝「for further study」(更なる検討)の略語。
「ＡＳ」＝「Access Stratum」の略語であり，当該「Access Stratum」について，3GPP TS 23.101 V9.0.0 (2009-12)には，次の記載がある。
「6.2　　
Access Stratum
　　　This is the functional groupings consisting of the parts in the infrastructure and in the user equipment and the protocols between these parts being specific to the access technique (i.e. the way the specific physical media between the User Equipment and the Infrastructure is used to carry information). The access stratum provides services related to the transmission of data over the radio interface and the management of the radio interface to the other parts of UMTS.
　　　The access stratum includes the following protocols:
　　-　Mobile Termination - Access Network
This protocol supports transfer of detailed radio-related information to co-ordinate the use of radio resources between the MT and the access network.
　　-　Access Network - Serving Network
This protocol supports the access from the serving network to the resources provided by the access network. It is independent of the specific radio structure of the access network.」
(当審訳
６.２　アクセス・ストレータム
　これは，インフラストラクチャ内及びユーザ機器内の部品と，アクセス技術に特有であるこれら部品間のプロトコル(すなわち，ユーザ機器とインフラとの間の特定の物理メディア(媒体)が情報を搬送するために使用される方法)とで構成する機能的なグループである。アクセス・ストレータムは，無線インタフェースを介したデータの送信と，ＵＭＴＳの他の部分への無線インターフェースの管理とに関連するサービスを提供する。
　アクセス・ストレータムは，次のプロトコルを含んでいる。
　　−　モバイル端末−アクセスネットワーク
　　このプロトコルは，ＭＴ(モバイル端末)とアクセスネットワークとの間の無線リソースの使用を調整するために詳細な無線関連情報の送信をサポートする。
　　−　アクセスネットワーク−サービング・ネットワーク
　　このプロトコルは，サービスネットワークからアクセスネットワークによって提供されるリソースへのアクセスをサポートする。それは，アクセスネットワークの特定の無線構造と無関係である。)
　　　　　(イ)　参考文献２
　本件出願の優先権主張日前に公知の「インプレス標準教科書シリーズ　ワイヤレス・ブロードバンド　ＨＳＰＡ＋／ＬＴＥ／ＳＡＥ教科書」，服部武／藤岡雅宣　編著，株式会社インプレスＲ＆Ｄ　発行(２００８年(平成２０年)８月１日　第１版第１刷，２０１０年１２月１１日　第１版第３刷発行)(以下「参考文献２」という。)には，次の記載がある。
　　　　　　◇ａ　記載事項１
　　６.５　ＵＭＴＳにおけるパケット交換(ＰＳ)ドメインの構成要素とプロトコル構成
　　［１］ユーザー・プレーンのプロトコル構成
　図６−３に，ＵＭＴＳ　ＰＳドメインの
ユーザー・プレーン(Ｕプレーン：ユーザー情報を送受信するプロトコル)
　そのＩＰパックボーン・ネットワークの上で，ＲＮＣ−ＳＧＳＮ間，ＳＧＳＮ−ＧＧＳＮ間のそれぞれに，ＧＴＰ(ＧＰＲＳ　Ｔｕｎｎｅｌｉｎｇ　Ｐｒｏｔｏｃｏｌ)トンネルと呼ばれる論理的な直通パスが構成され，ユーザーＩＰパケットをそれらの機能要素間で転送します。ＧＴＰトンネルは，ＵＥに関して複数本設定可能です。ＧＴＰトンネルを用いることで，ユーザーＩＰパケットのヘッダで使用する送信元ＩＰアドレスや宛先ＩＰアドレスを，ＵＭＴＳ内のＩＰパックボーンでＲＮＣ，ＳＧＳＮ，ＧＧＳＮ装置へ割り当てられるＩＰアドレスとは独立に設定でき，自由度や柔軟性が向上します。
　　［２］制御プレーンのプロトコル構成
　図６−４に，ＵＭＴＳ　ＰＳドメインにおける
制御プレーン(Ｃプレーン：制御のための信号用プロトコル)
(１８７ページ〜１８８ページ)
(当審注　上記「ＩＰ
パック
バック
　　　　　　◇ｂ　記載事項２
　表６−５　第６章，第７章の本文・図表に登場する主な用語(その１)，同(その２)及び同(その７)には次の記載がある。
　　　◇(その１)において
　　Ｂｅａｒｅｒ，　ベアラとは，ユーザーの通信情報を転送するための一連の物理的あるいは論理的なパス(通信路)
　　Ｃプレーン，　Ｃｏｎｔｒｏｌ　Ｐｌａｎｅ，　制御プレーン。ネットワーク内の制御に利用される信号用のプロトコル。
(２０８ページ)
　　　◇(その２)において
　　ｅＮｏｄｅＢ(ｅＮＢとも書く)，　ｅｖｏｌｖｅｄ　ＮｏｄｅＢ，　発展的ノードＢ。Ｅ−ＵＴＲＡＮを構成する機能要素で，具体的には無線基地局装置である。
(２０９ページ)
　　　◇(その７)において
　　　Ｕプレーン，　Ｕｓｅｒ　Ｐｌａｎｅ，　ユーザー・プレーン。ユーザー情報を送受信するプロトコル。
(２１４ページ)
　　　◇　
当審注
　　　　ウ　対比
　本件補正発明と引用発明を比較すると，次のことがいえる。
　　　　　(ア)　引用発明における「リレー」は，引用発明における「ＢＳ」及び「ＷＴＲＵ」間の通信を中継するものであることは明らかであるので，「中継ノード」といい得る。
　また，引用発明における「ＢＳ」は，引用例の[００８５](上記「ア」の「◇ｃ　記載事項３」参照。)における記載，及び図４の記載を参酌すれば，「リレー」(ＲＳ)と無線で接続されうるものであるから，当該「ＢＳ」は「ドナーｅＮＢ」(「ＤｅＮＢ」)といい得る。(参考文献１参照。)
　そして，引用発明における「リレー」が「ＢＳ」と「ＷＴＲＵ」の間の通信を「サポート」し，当該「サポート」に関する方法を，引用発明が開示しているといえることは明らかである。
　　　　　(イ)　引用例の[００３３８](上記「ア」の「◇ｆ　記載事項６」参照。)には，「以下の情報は、スケジューリング許可割り当てを補助するために、ＷＴＲＵによってＢＳに提供される。この情報は、ＳＩ(スケジューリング情報)で提供される。」との記載がある。
　当該記載によれば，引用発明における「ＳＩ」は，「ＷＴＲＵ」から「ＢＳ」へ送られるものであると解される。
　そして，引用例の[００３５８](上記「ア」の「◇ｇ　記載事項７」参照。)には，「「結合されたＳＩ」を基にして，「ＷＴＲＵ」にリソースを割り当てること」が記載されていると解される。
　このことは，当該「結合されたＳＩ」がリソース制御のための信号であるといえることを示している。
　してみると，引用発明には，リソースの制御のための信号用のプロトコル，つまり，「制御プレーン」が開示，示唆されているといい得ることを示している。
　そして，上記の「結合されたＳＩ」において結合される「ＳＩ」は，ＷＴＲＵからのものであるのだから，当該「ＳＩ」は，リレー中で終端しない「ＷＴＲＵ制御プレーントラフィック」といい得る。
　上記のごとく結合される「ＳＩ」はすべてのＷＴＲＵのものであるから，上記「結合されたＳＩ」はＷＴＲＵからＢＳへの「報告グループ」といい得る。
　ここで，引用例の[００３５７](上記「ア」の「◇ｇ　記載事項７」参照。)における記載によると，「リレーＳＩ」は，リレーバッファの状態を示し，また，同[００３５８]における記載によると，「結合されたＳＩ」は，結合されたＷＴＲＵすべてに対するバッファの状態を示すものであると解される。
　また，引用例の[００３５１](上記「ア」の「◇ｇ　記載事項７」参照。)における記載によると，「リレーからＢＳに報告するＳＩのフレーム」は，「リレーＳＩ」及び各ＷＴＲＵの「ＳＩ」を含むものであることは明らかである。
　このことは，当該「リレーからＢＳに報告するＳＩのフレーム」が「リレーバッファステータス報告」といい得ることを示している。
　　　　　(ウ)　引用例の[００２１１]ないし[００２１４](上記「ア」の「◇ｄ　記載事項４」参照。)における記載によれば，「ユーザプレーン」における操作例として，引用発明における「リレー」が，「ＢＳ」及び「ＷＴＲＵ」間の「ＡＦ(増幅及び転送)リレー」として機能することが開示されていると解される。
　このことは，「リレー」を介して，「ＢＳ」及び「ＷＴＲＵ」間のユーザ情報を送受信されることを，引用発明が予定していることを示唆しているといえる。(参考文献２の「[２]ユーザー・プレーンのプロトコルの構成」参照。)
　そして，上記のごとく送受信される「ユーザ情報」が「データ無線ベアラによって搬送される」ことは当然である。
　また，引用発明における「リレー」が各ＷＴＲＵの「ＳＩ」を結合し，「結合されたＳＩ」として，「リレー」から「ＢＳ」へ送信することに鑑みると，上記「ユーザ情報」も各ＷＴＲＵのものであることは明らかであるのだから，「結合されたＳＩ」と同様，各ＷＴＲＵの「ユーザ情報」を「リレー」において，結合し「報告グループ」として，「ＢＳ」へ送信するようにすることも当然といえる。
　　　　　(エ)　上記(ア)ないし(ウ)に述べた事項を踏まえると，本件補正発明と引用発明は，次の点で一致し，相違するといえる。
［一致点］
　中継ノードによって実施される、通信をサポートする方法であって、
　前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループと、１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループと、を含む中継ノードバッファステータス報告(ＢＳＲ)を生成するステップと、
　前記中継ノードＢＳＲをドナー高度化(ｅｖｏｌｖｅｄ)ノードＢ(ＤｅＮＢ)に送るステップと
を含むことを特徴とする方法。
［相違点］
　「制御プレーントラフィック」が「制御プレーンベアラ」によって搬送されることは技術常識であるから，本件補正発明においては，「中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループ」が「１つまたは複数の制御プレーンベアラによって搬送され」る特定があるのに対して，引用発明にはそのような特定がない点。
　　　　エ　検討
　上記相違点について検討するに，上記[相違点]に記載したように，「制御プレーントラフィック」が「制御プレーンベアラ」によって搬送されることは技術常識であるのだから，引用発明における「ＷＴＲＵから送信される「ＳＩ」」を，「制御プレーンベアラ」によって搬送されるものとすることに格別な技術的困難があるとは認められない。
　よって，上記相違点のように構成することは，引用発明に基づいて当業者が容易に想到し得たものであるといえる。
　そして，本件補正発明のように構成したことによる効果も，引用発明から予測できる程度のものである。
　　　　オ　まとめ
　したがって，本件補正発明は，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものに該当する。
　　　(３)　補足的検討のまとめ
　上記「(１)　補足的検討１(３６条について)」の「オ　まとめ」及び上記「(２)　補足的検討２(２９条２項について)」の「オ　まとめ」に述べたとおりであり，本件補正発明は，特許法第３６条第４項第１号，同条第６項第１号に規定する要件を満たしていないものに該当し，若しくは，同法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものに該当する。
　したがって，上記「４．請求項１に対する本件補正に関する補足的検討」の前書きのとおり，本件補正前の請求項１に対してなされた補正が，「別の報告グループ」を限定するものであって，特許請求の範囲を減縮するものであるといえたとしても，上記「３．まとめ」において述べた事項には，影響を及ぼさないといえる。
第３　本願発明
　上記第２に述べたとおり，本件補正は却下された。
　したがって，本願の請求項１に係る発明(以下「本願発明」という。)は，本件補正前の特許請求の範囲の請求項１に記載された事項(上記「第２」の「１．本件補正」における［本件補正前の特許請求の範囲］参照。)により特定されるとおりのものである。
第４　当審の判断
　　１．引用例及び引用発明
　引用例及び引用発明は，上記「第２」の「４．請求項１に対する本件補正に関する補足的検討」の「(２)　補足的検討２(２９条２項について)」の「ア　引用例及び引用発明」に記載のとおりである。
　　２．検討
　本願発明は，本件補正発明における「中継ノードバッファステータス報告(ＢＳＲ)」が，「１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックに関する第１の報告グループ」と、「１つまたは複数のデータ無線ベアラによって搬送されるＷＴＲＵユーザプレーンデータトラフィックに関する少なくとも第２の報告グループ」と、を含むものであるのに対して，「１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックを、
別個の
　つまり，本願発明は，本件補正発明における「ＢＳＲ」が含む「第２の報告グループ」に係る特定がないものに相当するといえる。
　ここで，上記「第２」の「４．」の「(２)」に述べたとおり，本件補正発明は，引用発明に基づいて，当業者が容易に発明をすることができたものである。
　そうすると，上記「第２」の「４．」の「(２)」の「ウ　対比」に述べたとおり，引用発明における「ＢＳＲ」も，２つの「報告グループ」を含むものであるのだから，本願発明のように，「１つまたは複数の制御プレーンベアラによって搬送され、前記中継ノード中で終端しないワイヤレス送受信ユニット(ＷＴＲＵ)制御プレーントラフィックを、
別個の
　そして，本願発明のように構成したことによる効果も引用発明から予測できる程度のものであるといえる。
　　３．まとめ
　以上のとおりであるから，本願発明は，引用発明に基づいて，当業者が容易に発明をすることができたものに該当するといえる。
第５　むすび
　以上から，本願発明は，特許法第２９条第２項の規定に該当し，特許を受けることができない。
　したがって，その余の請求項について論及するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。