【事件の表示】
　特願２０１３−１９３５８５「ワイヤレス通信ネットワーク内の複数クラスタのモビリティ管理」拒絶査定不服審判事件〔平成２６年　３月　６日出願公開，特開２０１４−　４２２５６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００８年９月１９日（パリ条約による優先権主張外国庁受理　２００７年９月２４日　米国，２００７年９月２４日　米国，２００７年９月２４日　米国，２００８年９月１７日　米国）を国際出願日とする出願である特願２０１０−５２７０４７号の一部を，平成２５年９月１８日に新たな特許出願としたものであって，平成２６年１１月１４日付けで拒絶査定がされ，これに対し，平成２７年３月１８日に拒絶査定不服審判が請求されるとともに同日付けで手続補正がされ，その後，当審において平成２８年２月２６日付けで拒絶理由（以下，「当審拒絶理由」という。）が通知され，同年５月２７日付けで手続補正がされたものである。
　
　
第２　当審において通知した拒絶理由
　当審拒絶理由の概要は，以下のとおりである。
理由１　（明確性，サポート要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号，同第２号に規定する要件を満たしていない。 
（中略）
　　　　　　　　　　　　　　　　　記 
［理由１について］ 
（中略）
（３）「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２のリソースユニット上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御する」（請求項１，１５〜１７）について，発明の詳細な説明をみても，当該記載の裏付けが不明確であり，また，制御動作が不明確である。 
　「第１のリソースユニット」，「第２のリソースユニット」との記載，及び請求項１４を参酌すれば，両者は物理リソースとして重複していないものと解される。このため，たとい第１のクラスタに属するセクタと第２のクラスタに属するセクタが重複していたとしても，「第１のリソースユニット」と「第２のリソースユニット」とは重複していないのであるから，マルチキャスト・セッションの搬送において衝突が生じるはずはない。また，仮に両者の物理リソースが重複していたとしても，第１及び第２のクラスタでは同一の「所与のマルチキャスト・セッション」が搬送されるのであるから，いわゆる「衝突」は生じないはずである。したがって，特段の制御をしなくても，そもそも「前記第１のクラスタが，前記第１の複数のセクタの各々内でダウンリンク・ブロードキャスト・チャネルの第１のリソースユニット上で所与のマルチキャスト・セッションを搬送し，前記第２のクラスタが，前記第２の複数のセクタの各々内で前記ダウンリンク・ブロードキャスト・チャネルの第２のリソースユニット上で前記所与のマルチキャスト・セッションを搬送する」ことは可能であるはずである。このため，「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２のリソースユニット上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御すること」なる記載は矛盾しており，また，いかなる制御をなすことにより「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２のリソースユニット上で前記所与のマルチキャスト・セッションを搬送することを可能となる」のか不明であって，制御動作を特定することができない。 
　請求項１を引用する各請求項についても同様である。 
（　各請求項に係る発明は，【００９３】，図２２以降に開示された実施形態に対応するものと推察され，その動作は図２４，図２６，図２７に記載されたものと推察されるが，各請求の記載は図２４，図２６，図２７の動作と対応しない。すなわち，図２６のステップ２６００，２６０５のＢＯＭ，又は図２７のステップ２７００，２７０５のＢＯＭが送信されるだけであって，何らかの「制御」がなされているとは認められない。） 
第３　請求人の対応
　当審拒絶理由に対して，請求人は，平成２８年５月２７日付けで，特許請求の範囲を補正する手続補正書及び意見書を提出した。
１　補正後の特許請求の範囲
　平成２８年５月２７日付けで手続補正された特許請求の範囲（抜粋）は以下のとおりである。
　なお，補正により補正前の請求項１２，１３が削除されたため，当審拒絶理由の上記理由１（３）に記載中の「請求項１，１５〜１７」は，補正後の請求項１，１３〜１５に対応する。
「【請求項１】
　ワイヤレス通信システムにおける
重複する
　前記ワイヤレス通信システム内の第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかを判断することと，ここにおいて，前記第１のクラスタが第１の複数のセクタを含み，前記第２のクラスタが第２の複数のセクタを含み，前記第１のクラスタが，前記第１の複数のセクタの各々内でダウンリンク・ブロードキャスト・チャネルの第１の
物理チャネル
物理チャネル
　前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２の
物理チャネル
を備える方法。
（中略）
【請求項１３】
　ワイヤレス通信システムの複数のセクタを管理するように構成されたアクセス・ネットワークであって，
　前記ワイヤレス通信システム内の第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかを判断するように構成された論理と，ここにおいて，前記第１のクラスタが第１の複数のセクタを含み，前記第２のクラスタが第２の複数のセクタを含み，前記第１のクラスタが，前記第１の複数のセクタの各々内でダウンリンク・ブロードキャスト・チャネルの第１の
物理チャネル
物理チャネル
　前記判
断に
物理チャネル
を備えるアクセス・ネットワーク。
【請求項１４】
　ワイヤレス通信システムの複数のセクタを管理するように構成されたアクセス・ネットワークであって，
　前記ワイヤレス通信システム内の第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかを判断するための手段と，ここにおいて，前記第１のクラスタが第１の複数のセクタを含み，前記第２のクラスタが第２の複数のセクタを含み，前記第１のクラスタが，前記第１の複数のセクタの各々内でダウンリンク・ブロードキャスト・チャネルの第１の
物理チャネル
物理チャネル
　前記判
断に
物理チャネル
を備えるアクセス・ネットワーク。
【請求項１５】
　ワイヤレス通信システム内の第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかをコンピュータに判断させるための少なくとも１つの命令と，ここにおいて，前記第１のクラスタが第１の複数のセクタを含み，前記第２のクラスタが第２の複数のセクタを含み，前記第１のクラスタが，前記第１の複数のセクタの各々内でダウンリンク・ブロードキャスト・チャネルの第１の
物理チャネル
物理チャネル
　前記判
断に
物理チャネル
前記
を備えるコンピュータ可読記憶媒体。」
（［当審注］：下線部は補正箇所を示す。）
２　意見書の主張
　当審拒絶理由の上記理由１（３）に対して，請求人は平成２８年５月２７日付け意見書で以下のとおり主張している。
「（３−１−３）理由１の（３）について
　審判官殿は，「「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２のリソースユニット上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御する」（請求項１，１５〜１７）について，発明の詳細な説明をみても，当該記載の裏付けが不明確であり，また，制御動作が不明確である」と指摘されました。
　これに対し，審判請求人は，クラスタの重複は，リソースユニット（または物理チャネル／ＩＭ対）の重複とは同じでないことを主張します。例として本願の独立請求項１において，第１および第２のクラスタが両方，同じセクタ中の
異なる
第１および第２のクラスタはしたがって，同じセクタ中の同じリソースユニット（または物理チャネル／ＩＭ対）を使用すること（または，使用することを試みること）によってではなく，同じセクタのうちの１つまたは複数を共有することによって重複しています。
　本願の独立請求項１の「制御すること」の特徴に関して，制御は，以下の図２４，２６，および２７に関して説明されるようにＢＯＭを使用して知的セッション広告（intelligent session advertisement）を介して実施されます。
・
図２２
・
図２６
・
図２７
　これらのシナリオの各々が，両方のＩＭ対上で重複するセクタの送信を許可しますが，これらのＩＭ対が広告される方法は，クラスタと重複するセクタの関係（例えば，図２２）に基づいて，または実施形態の選択（implementation preferences）（例えば，図２６−２７）に基づいて変わることができます。例えば，サポートセクタのクラスタのＩＭ対が，図２６で広告されていないという事実は，そのセクタ中のＡＴがターゲットセクタのクラスタにシフトすることとなり，サポートセクタのクラスタのＩＭ対が，サポートセクタのクラスタのそのネイバリングセクタにソフトウェアと結合の利益を提供するためだけに使用されることを意味します。このことが，ＡＴアクションがＢＯＭ中のＩＭ対の広告を介して処理される（manipulated）ため，どのようにぞれぞれのクラスタが「増大する（grow）」こととなるのかを変更します。それによって，クラスタは，本願の独立請求項１に記載されているような，および独立請求項１５−１７（補正後の独立請求項１３−１５）に同様に記載されているような重複するセクタの「判断」に基づいて様々な方法で
制御されます
　審判官殿は，以下を指摘されました。
　・・・（各請求項に係る発明は，［００９３］，図２２以降に開示された実施形態に対応するものと推察され，その動作は図２４，図２６，図２７に記載されたものと推察されるが，各請求の記載は図２４，図２６，図２７の動作と対応しない。すなわち，図２６のステップ２６００，２６０５のＢＯＭ，又は図２７のステップ２７００，２７０５のＢＯＭが送信されるだけであって，何らかの「制御」がなされているとは認められない。）（理由１の（３）を参照）
　上記のように，ＩＭ対がＢＯＭ中に広告される処理は，それらのセクタ中のＢＯＭを受信するＡＴの動作を変更し，次に，それは，クラスタそれら自身を制御します。例えば，図２６を例にとれば，ＡＴが第１のクラスタ中の「所与のマルチキャスト・セッション」を監視し，その後に，ＡＴが，第１のクラスタのサポートセクタであり，また第２のクラスタのターゲットセクタである新しいセクタにハンドオフするシナリオを検討します。図２６にしたがって第２のクラスタ用のＩＭ対を広告することのみによって，ＡＴが，新しいセクタ中の「所与のマルチキャスト・セッション」を搬送する第１のクラスタのリソースユニットを特定することができなくなるため，ＡＴは，第２のクラスタに切り替えざるを得ません。ＢＯＭ中に広告されるＩＭ対はしたがって，それぞれのクラスタにわたる制御が得られるメカニズムです。
　したがって，本願明細書の記載を参酌すれば，不明確であるとされた記載は明確であると思料いたします。」
第４　当審の判断
１　本願明細書の記載
　本願明細書には以下の記載がある。なお，下線部は合議体が付加した。
「【００２７】
　ユーザが確立された呼グループに加入すると，所与のマルチキャスト・グループに話したいという所与のアクセス端末の要望を伝達するために，移動局またはアクセス端末は適切な制御メッセージをアプリケーション・サーバ１７０に送信し，アプリケーション・サーバ１７０は，プッシュツートーク（ＰＴＴ）機能をサポートするように構成でき，それによって「ＰＴＴアプリケーション・サーバ」と呼ばれることがある。
ユーザにフロアを与えられると，ユーザのボイスまたは他のデータはＲＡＮ１２０に送信され，ＰＴＴアプリケーション・サーバ１７０上に送信される。次に，データは，ＰＴＴアプリケーション・サーバ１７０によって処理され，ブロードキャスト・マルチキャスト・サービス（ＢＣＭＣＳ）フローとして呼グループ中の他の移動局またはアクセス端末に送信するためにＲＡＮ１２０に戻される。本明細書で使用する「ＢＣＭＣＳフロー」は，ＢＣＭＣＳプロトコル／手順に従って送信されるパケットデータ・ストリームである。
（中略）
【００２９】
　従来のＢＣＭＣＳシステム中で１ｘＥＶＤＯ順方向リンクを介して搬送される
ブロードキャストオーバーヘッドメッセージ（ＢＯＭ）は，移動局またはアクセス端末に特定のセクタで現在搬送されているＢＣＭＣＳフローについて通知する。
ＢＯＭは，１つまたは複数のＢＣＭＣＳフロー用のＢＣＨ上で１つまたは複数のどのスロットを「同調させる」べきかについてマルチキャスト・グループ・メンバーに通知する。
【００３０】
　従来，アクセス端末は，（たとえば，電源投入時，ハンドオフ後などに）新しいセルまたはセクタに入ると，
受信したＢＯＭを復号し，その静的マルチキャスト・グループに関連するフロー識別子を探す。１つまたは複数の所望のＢＣＭＣＳフローがＢＯＭ中で示されない場合，アクセス端末９０は，１つまたは複数のＢＣＭＣＳフローを要求する自律ＢＣＭＣＳフロー登録メッセージを送信することができる。
【００３１】
　一般に，ＲＦＤＢが，ＢＯＭ内のＢＣＭＣＳフロー１Ａ用に第１の論理レベル（たとえば，論理「１」またはより高い論理レベル）に設定された場合（たとえば，ＲＦＤＢ＝１，ＢＣＭＣＳフロー＝１Ａ），ＢＯＭを受信しているセクタ内のすべてのマルチキャスト・グループ・メンバーおよびＢＣＭＣＳフロー１Ａに対応するマルチキャスト・グループのメンバーは，ＢＣＭＣＳフロー１ＡのＢＣＭＣＳフロー登録の送信または再送信のいずれかを行う。あるいは，ＲＦＤＢがＢＯＭ内のＢＣＭＣＳフロー１Ａ用に第２の論理レベル（たとえば，論理「０」またはより低い論理レベル）に設定された場合（たとえば，ＲＦＤＢ＝０，ＢＣＭＣＳフロー＝１Ａ），ＢＯＭを受信しているセクタ内のＢＣＨ上のＢＣＭＣＳフロー１Ａを監視しているマルチキャスト・グループ・メンバーは，ＢＣＭＣＳフロー１ＡのＢＣＭＣＳフロー登録を送信または再送信しない。
【００３２】
　所与のＢＣＭＣＳフローがＢＯＭ上で搬送され，ＲＦＤＢ＝１でＲＦＤＢフィールドに関連する場合，ＢＣＭＣＳフロー登録メッセージをセクタ内の１つまたは複数のＡＴからトリガすることができる。ただし，所与のセクタ内のＡＴの数が増加するにつれて，ＢＣＭＣＳフロー登録メッセージの数が同様に増加することがあり，それによりアクセスチャネル上のシステムリソースを浪費することがある。
（中略）
【００４８】
　図７に，本発明の一実施形態によるターゲットセクタの挙動を示す。図７を参照すると，所与の初期クラスタ（４１０において決定された初期ターゲットセクタおよび４１５において決定された初期サポートセクタ）用のＲＡＮ１２０は，ＢＣＭＣＳフロー登録メッセージがセクタの１つの中の１つまたは複数のアクセス端末から受信されたかどうかを判断する。
ＲＡＮが所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）用のＢＣＭＣＳフロー登録メッセージが受信されたと判断した場合，プロセスは７０５に進み，そこで，所与の初期ターゲットセクタがターゲットセクタ（「ＴＡＲＧＥＴ」）に移行する。
【００４９】
　図７の７１０において，ＲＡＮ１２０は，ターゲットセクタＴＡＲＧＥＴ用の第１のタイマＴＩＭＥＲ１を初期化する。一例では，第１のタイマＴＩＭＥＲ１は，（たとえば，ＢＣＭＣＳフローをより長く広告し，輻輳を減らすためにより長い周期を選択するなど）任意のよく知られているパフォーマンス基準に基づいてシステム設計者によって確立できる。７１５において，ターゲットセクタＴＡＲＧＥＴ中のＲＡＮ１２０は，ＢＣＭＣＳフローＴ＿ＦＬＯＷを広告し，ＲＦＤＢを０に設定し，ＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０］と示されるＢＯＭを送信する。ＢＯＭを送信した後，図７の７２０において，ターゲットセクタＴＡＲＧＥＴ用のＲＡＮ１２０は，所与のＢＯＭ周期（たとえば，システム設計者が決定した連続したＢＯＭ間の周期的間隔）の間待機する。次に，７２５において，ＲＡＮ１２０は，第１のタイマＴＩＭＥＲ１が期限切れになったかどうかを判断する。第１のタイマＴＩＭＥＲ１が期限切れになっていなかった場合，プロセスは図７の７１５に戻り，さもなければ，プロセスは図７の７３０に進む。
【００５０】
　図７の７３０において，ＲＡＮ１２０は，ターゲットセクタＴＡＲＧＥＴ用の第２のタイマＴＩＭＥＲ２を初期化する。一例では，第２のタイマＴＩＭＥＲ２は，（たとえば，サポートセクタに移行する前により長い時間期間，ＢＣＭＣＳフロー登録メッセージを待つために，より長い周期を選択するなど）任意のよく知られているパフォーマンス基準に基づいてシステム設計者によって確立できる。たとえば，第２のタイマＴＩＭＥＲ２は，少なくとも１つのＢＯＭが送信されることを保証するＢＯＭ周期の周期よりも長い周期に設定できる。したがって，７３５において，ターゲットセクタＴＡＲＧＥＴ中のＲＡＮ１２０は，ＲＦＤＢを１に設定することによって，ＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝１］と示されるＢＯＭを送信する。ＢＯＭを送信した後，図７の７４０において，ＲＡＮ１２０は，タイマＴＩＭＥＲ２が期限切れになる前にターゲットセクタＴＡＲＧＥＴ用にＢＣＭＣＳフロー登録メッセージが受信されたかどうかを判断する。１つまたは複数のＢＣＭＣＳフロー登録メッセージが，第２のタイマＴ２の期限切れの前に受信された場合，プロセスは図７の７１０に戻る。あるいは，ＢＣＭＣＳフロー登録メッセージが，第２のタイマＴＩＭＥＲ２の期限切れの前に受信されなかった場合，プロセスは７４５に進み，ターゲットセクタＴＡＲＧＥＴはサポートセクタ（「ＳＵＰＰＯＲＴ」）に移行する。
【００５１】
　図７に示し，上述したように，第１のタイマＴＩＭＥＲ１は，ＢＯＭがＢＣＭＣＳフローＴ＿ＦＬＯＷを広告し，ＡＴフィードバックを抑制するようにＲＦＤＢ＝０を設定する周期に対応するが，第２のタイマＴＩＭＥＲ２は，ＢＯＭがＢＣＭＣＳフローＴ＿ＦＬＯＷを広告し，ＲＦＤＢ＝−１を設定する周期に対応する。ただし，一代替実施形態では，第２のタイマＴＩＭＥＲ２は，ＢＯＭが全く広告されない周期に対応することがある。したがって，この代替実施形態では，フィードバックは，ＢＣＭＣＳフローの広告の欠如によって促進される。上述の代替実施形態は，たとえば，輻輳を減らすことができる。
【００５２】
　図８に，本発明の一実施形態によるサポートセクタの挙動を示す。サポートセクタは，ターゲットセクタと同じ方法でＢＣＨ上でＢＣＭＣＳフローを搬送し，以下で説明するようにＢＯＭを送信する。たとえば，サポートセクタは，その中に存在することが知られている実際のマルチキャスト・グループ・メンバーがなくても，「結合」または「ソフト結合」効果をもたらすために，ＢＣＨ上でＢＣＭＣＳフローを搬送するように構成でき，（たとえば，隣接しているか，所与の近傍にあるなどの）サポートセクタ補助ＡＴで生成されるＢＣＭＣＳフローを集合的に使用して，ＢＣＭＣＳフローの復号を助ける。結合およびソフト結合は当技術分野でよく知られており，簡潔のためにより詳細に説明しない。
【００５３】
　図８を参照すると，８００において，サポートセクタＳＵＰＰＯＲＴ中のＲＡＮ１２０は，ＢＣＭＣＳフローＴ＿ＦＬＯＷを広告し，ＲＦＤＢを１に設定し，ＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝１］と示されるＢＯＭを送信する。次に，８０５において，サポートセクタＳＵＰＰＯＲＴ中のＲＡＮ１２０は，Ｔ＿ＦＬＯＷ用のＢＣＭＣＳフロー登録が受信されたかどうかを判断する。Ｔ＿ＦＬＯＷ用の１つまたは複数のＢＣＭＣＳフロー登録メッセージが受信されたと判断した場合，プロセスは図７の７０５に進み，サポートセクタＳＵＰＰＯＲＴはターゲットセクタＴＡＲＧＥＴに移行する。さもなければ，プロセスは８１０に進む。図８の８１０において，ＲＡＮ１２０は，隣接するターゲットセクタがサポートセクタＳＵＰＰＯＲＴに対して存在するかどうかを判断する。隣接するターゲットセクタが検出されない場合，プロセスは８１５に進む。図８の８１５において，サポートセクタＳＵＰＰＯＲＴは，非サポートセクタ（「ＮＯＮ−ＳＵＰＰＯＲＴ」）に移行する。非サポートセクタＮＯＮ−ＳＵＰＰＯＲＴに移行した後，非セクタサポートセクタＮＯＮ−ＳＵＰＰＯＲＴは，ＢＣＨ上でＴ＿ＦＬＯＷ用のＢＣＭＣＳフローを搬送せず，ＢＣＭＣＳフローＴ＿ＦＬＯＷ用のＢＯＭを送信しない。
【００５４】
　８１０に戻ると，１つまたは複数の隣接するターゲットセクタが存在すると判断された場合，８２０において，サポートセクタＳＵＰＰＯＲＴ用のＲＡＮ１２０は，所与のＢＯＭ周期の間待機し，次いで８００に戻る。
（中略）
【００９２】
　上記の説明から諒解されるように，
クラスタは，所与のマルチキャスト・セッションをサポートする複数のセクタに対応し，複数のセクタは少なくとも１つのターゲットセクタおよび少なくとも１つのサポートセクタを含む。「クラスタ」は，（ｉ）連続しており，（ｉｉ）ダウンリンクＢＣＨの同じインターレース多重（ＩＭ）対上の所与のマルチキャスト・セッションをサポートする，複数のターゲットおよびサポートセクタに対応するものとしてさらに規定できる。
ＩＭ対は，広告されたＢＣＭＣＳフローに関連するＢＯＭ内に含まれる。ＩＭ対は，関連する広告されたＢＣＭＣＳフローを監視するためにダウンリンクＢＣＨに「同調させる」方法に関してＡＴに指示する。異なるＩＭ対を使用して異なるＢＣＭＣＳフローを搬送する方法は，当技術分野でよく知られており，（すなわち，背景技術セクションにおいて参照により組み込まれる）公開第２００７／００４９３１４号内でより詳細に記述されている。
【００９３】
　図２２に，本発明の一実施形態による２つのクラスタを含むワイヤレス通信システム２２００を示す。図２２に示すように，ワイヤレス通信システム２２００は，
第１のクラスタ２２０５および第２のクラスタ２２１０
（中略）
【００９６】
　
最も単純なシナリオでは，衝突するかまたは重複する各クラスタは，同じＩＭ対上で所与のマルチキャスト・セッションをサポートするように構成される。この例では，ＲＡＮ１２０は，クラスタの衝突中に特殊な動作を行う必要はない。
（中略）
【００９８】
　図２３に，本発明の一実施形態による，第１のクラスタのサポートセクタが第２のクラスタのサポートセクタと重複するワイヤレス通信システム２３００を示す。説明の便宜のために，
第１のクラスタは以下クラスタＸと呼び，第２のクラスタは以下クラスタＹと呼ぶ。したがって，クラスタＸ内のセクタは表示「Ｘ＿」から始まり，クラスタＹ内のセクタは表示「Ｙ＿」から始まる。
【００９９】
　図２３で，クラスタＸはターゲットセクタＸ＿Ｔ１およびＸ＿Ｔ２ならびにサポートセクタＸ＿Ｎ１〜Ｘ＿Ｎ８を含む。ＡＴ  ＣはターゲットセクタＸ＿Ｔ１内に実際に配置されるか，または配置されることが予想され，ＡＴ  ＡおよびＡＴ  ＢはターゲットセクタＸ＿Ｔ２内に実際に配置されるかまたは配置されることが予想される。一例として，簡単のために，クラスタＸは，サポートセクタが，ターゲットセクタに隣接している非ターゲットセクタに対応する実施形態に対応するように構成されている。クラスタＹは，ターゲットセクタＹ＿Ｔ３およびサポートセクタＹ＿Ｎ９〜Ｙ＿Ｎ１４を含む。ＡＴ  ＤおよびＡＴ  Ｅは，ターゲットセクタＹ＿Ｔ３内に実際に配置されるか，または配置されることが予想される。一例として，簡単のために，クラスタＹは，サポートセクタが，ターゲットセクタに隣接している非ターゲットセクタに対応する実施形態に対応するように構成されている。ただし，クラスタＸまたはＹのいずれかは，シングルティアネイバクラスタ（たとえば，図１５および図１６を参照），ダブルティアネイバクラスタ（たとえば，図１７および図１８を参照），サポートセクタ値によって変更されたシングルティアネイバクラスタ（たとえば，図１９〜図２１を参照），および／または任意のそれらの組合せとして再構成できることを諒解されたい。
【０１００】
　図２３のワイヤレス通信システム２３００内で，
クラスタＸは，第１のＩＭ対（「ＩＭ＿１」）を用いて所与のマルチキャスト・セッションをサポートし，クラスタＹは，第２のＩＭ対（「ＩＭ＿２」）を用いて所与のマルチキャスト・セッションをサポートすると仮定する。さらに，図２３に示すように，クラスタＸのサポートセクタＸ＿Ｎ４は，クラスタＹのサポートセクタＹ＿Ｎ１３と重複するか，またはＹ＿Ｎ１３と同じセクタである。
【０１０１】
　上記の仮定を用いて，図２４に，本発明の一実施形態による，
重複するサポートセクタＸ＿Ｎ４／Ｙ＿Ｎ１３
【０１０２】
　図２４を参照すると，２４００において，
サポートセクタＸ＿Ｎ４／Ｙ＿Ｎ１３中のＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを１に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔが２に等しく，ＩＭ＿１およびＩＭ＿２を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝１，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝２，ＩＭ＿１，ＩＭ＿２］と示される。ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔパラメータは，その上でサポートセクタＸ＿Ｎ４／Ｙ＿Ｎ１３中の所与のマルチキャスト・セッションが搬送されている，ＩＭ対または物理チャネルの数を示す。
【０１０３】
　図２４の２４１０において，ＲＡＮ１２０は，サポートセクタＸ＿Ｎ４およびＹ＿Ｎ１３が重複したままかどうかを判断する。たとえば，隣接するターゲットセクタがクラスタＸまたはクラスタＹのいずれかから欠落したかまたは削除された場合，サポートセクタは，クラスタＸとＹとの間でもはや重複していない。サポートセクタが重複している状態のままである場合，２４１５において，サポートセクタＸ＿Ｎ４／Ｙ＿Ｎ１３用のＲＡＮ１２０は所与のＢＯＭ周期の間待機し，次いで，２４００に戻る。
【０１０４】
　さもなければ，プロセスは２４２０に進む。２４２０において，ＲＡＮ１２０は，隣接するターゲットセクタがクラスタＸ用またはクラスタＹ用のいずれかのサポートセクタに対して存在するかどうかを判断する。隣接するターゲットセクタが残っていない場合，プロセスは２４２５に進み，サポートセクタは非サポートセクタに移行する。非サポートセクタに移行した後，非サポートセクタは，ＢＣＨ上でＴ＿ＦＬＯＷ用のＢＣＭＣＳフローを搬送せず，ＢＣＭＣＳフローＴ＿ＦＬＯＷ用のＢＯＭを送信しない。あるいは，ＲＡＮ１２０が，クラスタＸまたはクラスタＹのうちの１つの少なくとも１つの隣接するターゲットセクタが存在すると判断した場合，プロセスは，図８の８００に進み，単一のクラスタ（すなわち，重複しない）サポートセクタ用のサポートセクタ・プロセスを実行する。
【０１０５】
　次に，図２５のワイヤレス通信システム２３００内で，ＡＴ  ＤがターゲットセクタＹ＿Ｔ３からサポートセクタＸ＿Ｎ４／Ｙ＿Ｎ１３に移動すると仮定する。したがって，ＲＡＮ１２０がクラスタＹ内でＡＴ  Ｄを維持すると仮定すると，サポートセクタＹ＿Ｎ１３は，クラスタＸのサポートセクタＸ＿Ｎ４と依然として重複するターゲットセクタＹ＿Ｔ４に移行する。同様に，サポートセクタＸ＿Ｎ３およびＸ＿Ｎ５はそれぞれ，
重複するサポートセクタＸ＿Ｎ３／Ｙ＿Ｎ１６およびＸ＿Ｎ５／Ｙ＿Ｎ１５になる
重複するサポートセクタＸ＿Ｎ３／Ｙ＿Ｎ１６とＸ＿Ｎ５／Ｙ＿Ｎ１５
【０１０６】
　図２６に，本発明の一実施形態による別のクラスタのサポートセクタと重複するターゲットセクタの挙動を示す。図２６のプロセスは，ステップ７１５の代わりにステップ２６００を使用し，ステップ７３５の代わりにステップ２６０５を使用することを除いて，図７に関して上述したプロセスに対応する。したがって，２６００および２６０５以外の図２６のステップについては，簡潔のためにさらに説明しない。
【０１０７】
　２６００において，セ
クタＸ＿Ｔ２／Ｙ＿Ｎ１７の場合，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを０に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔを１に等しく，ＩＭ＿１を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿１］と示される。したがって，２６００において送信されるＢＯＭは，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿２上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿２上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
２６０５において送信されるＢＯＭは，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿２上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿２上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
【０１０８】
　同様に，
２６００において，セクタＸ＿Ｎ４／Ｙ＿Ｔ４の場合，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを０に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔを１に等しく，ＩＭ＿２を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿２］と示される。したがって，２６００において送信されるＢＯＭは，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＩＭ＿１上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿１上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
２６０５において送信されるＢＯＭは，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿１上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿１上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
【０１０９】
　
このようにして，ＢＣＭＣＳフローがセクタＸ＿Ｔ２／Ｙ＿Ｎ１７内のＩＭ＿２上で搬送されることを諒解されたい。したがって，ＩＭ＿２上のＢＣＭＣＳフローは，たとえば，ターゲットセクタＹ＿Ｔ４内のクラスタＹのＡＴ  Ｄを結合またはソフト結合することによって，クラスタＹのターゲットセクタＹ＿Ｔ４を「サポート」するのに利用可能である。ただし，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＢＣＭＣＳフローは，ＢＯＭ中のＩＭ＿２上で搬送されるものとして広告されず，したがって，ＡＴ  ＡおよびＡＴ  Ｂは，ＩＭ＿２上の所与のマルチキャスト・セッションを復号しようと試みない。したがって，ＡＴ  ＡおよびＡＴ  Ｂは，同じパケットを二回（すなわち，異なるそれぞれのＩＭ対上で）復号しようと試みることによる「過負荷」をそれら自体にかけず，冗長な復号の取り組みおよび／または二重のパケット処理手順をなくすことによって，バッテリ消費を低減するこ
とができる。同様に，ＢＣＭＣＳフローＴ＿ＦＬＯＷ用のＩＭ＿１がそのセクタ中のＢＯＭ中で広告されないので，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＡＴ  ＡおよびＡＴ  Ｂは，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中で搬送されるＩＭ＿１上のＢＣＭＣＳフローによって助けられ，ＡＴ  Ｄは，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＩＭ＿１上で信号を復号しようと試みることによる過負荷をかけられない。
【０１１０】
　図２７に，本発明の別の実施形態による別のクラスタのサポートセクタと重複するターゲットセクタの挙動を示す。図２７のプロセスは，ステップ７１５の代わりにステップ２７００を使用し，ステップ７３５の代わりにステップ２７０５を使用することを除いて，図７に関して上述したプロセスに対応する。したがって，２７００および２７０５以外の図２７のステップについては，簡潔のためにさらに説明しない。次に図２７について，図２５のワイヤレス通信システム２３００に関して説明する。
【０１１１】
　２７００において，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７の場合，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを０に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔが２に等しく，ＩＭ＿１とＩＭ＿２の両方を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝２，ＩＭ＿１，ＩＭ＿２］と示される。したがって，２７００において送信されるＢＯＭは，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿２上で搬送されるＢＣＭＣＳフローを広告し，ＩＭ＿２（およびＩＭ＿１）上のＢＣＭＣＳフローはセクタ内で依然として搬送される。同様に，２７０５において，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを１に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔが２に等しく，ＩＭ＿１とＩＭ＿２の両方を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝１，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿１，ＩＭ＿２］と示される。したがって，２７００と同様に，２７０５において送信されるＢＯＭは，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿２上で搬送されるＢＣＭＣＳフローを広告し，ＩＭ＿２（およびＩＭ＿１）上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
【０１１２】
　同様に，２７００において，セクタＸ＿Ｎ４／Ｙ＿Ｔ４の場合，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを０に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔが２に等しく，ＩＭ＿１とＩＭ＿２の両方を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝２，ＩＭ＿１，ＩＭ＿２］と示される。したがって，２７００において送信されるＢＯＭは，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＩＭ＿１上で搬送されるＢＣＭＣＳフローを広告し，ＩＭ＿１（およびＩＭ＿２）上のＢＣＭＣＳフローはセクタ内で依然として搬送される。同様に，２７０５において，ＲＡＮ１２０は，所与のＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を広告し，ＲＦＤＢを１に設定し，さらにＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔが２に等しく，ＩＭ＿１とＩＭ＿２の両方を含むＢＯＭを送信し，ＢＯＭはＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝１，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿１，ＩＭ＿２］と示される。したがって，２７００と同様に，２７０５において送信されるＢＯＭは，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＩＭ＿１上で搬送されるＢＣＭＣＳフローを広告し，ＩＭ＿１（およびＩＭ＿２）上のＢＣＭＣＳフローはセクタ内で依然として搬送される。
【０１１３】
　したがって，図２６の実施形態とは対照的に，重複するサポートセクタを有するターゲットセクタ中で送信されるＢＯＭは，（ｉ）ターゲットセクタのクラスタに関連するＩＭ対と，（ｉｉ）サポートセクタのクラスタに関連するＩＭ対の両方によってサポートされているマルチキャスト・セッションを広告することができる。二重のＩＭ対が広告されるＢＯＭに応答して，ＡＴは，両方のＩＭ対においてマルチキャスト・セッションを復号しようと試みる。上記のように，これにより，ＡＴにおける二重の復号化の作業および処理を生じることがある。ただし，少なくともいくつかの状況では，たとえば，ダイバーシティ効果による二重の送信／復号によって，復号レートを有利に助けることも可能である。たとえば，所与のＡＴにおいて，一方のＩＭ対の信号品質が不十分であるが，他方のＩＭ対の信号品質が良好である場合，異なるＩＭ対における二重の復号により，パケットを正常に復号することができる。図２６の単一のＩＭ対実装形態または図２７の二重のＩＭ対実装形態を使用可能にすべきかどうかに関する判断を，システム設計者がいくつかの基準のいずれかに基づいて行うことができる。
【０１１４】
　さらに，本発明の上記の実施形態は，クラスタの衝突中またはクラスタの重複中に異なるＩＭ対上で動作している２つのクラスタをサポートすることを対象とする。ただし，
一代替実施形態では，ＲＡＮ１２０は，クラスタのＩＭ対の一方を選択して，他方のクラスタを同じＩＭ対上に転送するかまたは切り替えようと試みることができる。このようにして，２つのクラスタを「マージ」することができ，上記のプロセスを実装する必要はない。
２　判断
　【００９２】，【００９８】の記載及び図２２，図２３によれば，請求項１，１３〜１５に記載中の「第１のクラスタ」，「第２のクラスタ」は，それぞれ「クラスタＸ」，「クラスタＹ」を含んでいると認められる。
　【００９８】，【０１００】，【０１０１】，【０１０５】の記載及び図２３，図２５によれば，請求項１，１３〜１５に記載中の「重複セクタ」は，同じセクタに複数のクラスタを含むものであり，図２３の「Ｘ＿Ｎ４／Ｙ＿Ｎ１３」，図２５の「Ｘ＿Ｎ３／Ｙ＿Ｎ１６」，「Ｘ＿Ｎ５／Ｙ＿Ｎ１５」，「Ｘ＿Ｔ２／Ｙ＿Ｎ１７」，「Ｘ＿Ｎ４／Ｙ＿Ｔ４」は「重複セクタ」に該当するものである。
　【００９２】，【０１００】の記載によれば，請求項１，１３〜１５に記載中の「第１の物理チャネル」，「第２の物理チャネル」は，それぞれ「第１のＩＭ（インターレース多重）対（「ＩＭ＿１」）」，「第２のＩＭ（インターレース多重）対（「ＩＭ＿２」）」を含んでいると認められる。
　【００９２】の記載によれば，請求項１，１３〜１５に記載中の「所与のマルチキャスト・セッション」は，クラスタを構成する複数のセクタ（ターゲットセクタ及びサポートセクタ）によりサポートされるものであり，【００９６】，【０１０２】の記載によれば，異なるクラスタで同じＩＭ対上又は別のＩＭ対上にて同じ「所与のマルチキャスト・セッション」をサポート（搬送）し得るものである。ここで，本願明細書の【００９２】より前には「（所与の）マルチキャスト・セッション」なる用語は存在しないが，【００２７】，【００２９】，【００３０】，【００４８】，【０１０２】の記載によれば，本願明細書の【００９２】より前では「（所与の）ＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）」と表現されているものに対応すると認められる。
　してみると，例えば請求項１の
「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御すること」は，
「クラスタＸおよびクラスタＹが少なくとも部分的に互いに重複するかどうかを判断することに基づいて，前記クラスタＸおよびクラスタＹの両方に属する１つまたは複数の重複セクタ（例えば図２５の「Ｘ＿Ｎ３／Ｙ＿Ｎ１６」，「Ｘ＿Ｎ５／Ｙ＿Ｎ１５」，「Ｘ＿Ｔ２／Ｙ＿Ｎ１７」，「Ｘ＿Ｎ４／Ｙ＿Ｔ４」）が，それぞれ，前記ＩＭ＿１およびＩＭ＿２上でＢＣＭＣＳフロー（「Ｔ＿ＦＬＯＷ」）を搬送することを可能となるように，クラスタＸおよびクラスタＹを制御すること」を含んでいると認められる。
　一方，本願明細書では，別のクラスタのサポートセクタと重複するターゲットセクタの挙動について【０１０６】〜【０１１４】，図２６，図２７に開示されているが，ターゲットセクタの挙動を示す図７のものとはブロードキャストオーバーヘッドメッセージ（ＢＯＭ）の内容が異なる，すなわち，【０１０２】のとおり，その上でセクタ中の所与のマルチキャスト・セッションが搬送されているＩＭ対又は物理チャネル，及びその数を示す，例えば「ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝２，ＩＭ＿１，ＩＭ＿２」なる表示がＢＯＭに追加されているだけで，第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかを判断することに基づいて何らかの特段の「制御」を行うことは明らかにされていない。
　また，【０１０７】，【０１０９】の記載によれば，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７にて送信されるＢＯＭは「ＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿１］」であり，所与のマルチキャスト・セッションである「ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ」に関して「ＩＭ−１」しか広告されず，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＩＭ＿２上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿２上のＢＣＭＣＳフローはセクタ内で依然として搬送されるものである。また，【０１０８】の記載によれば，セクタＸ＿Ｎ４／Ｙ＿Ｔ４にて送信されるＢＯＭは「ＢＯＭ［ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ；ＲＦＤＢ＝０，ＰｈｙｓｉｃａｌＣｈａｎｎｅｌＣｏｕｎｔ＝１，ＩＭ＿２］」であり，所与のマルチキャスト・セッションである「ＢＣＭＣＳ：Ｔ＿ＦＬＯＷ」に関して「ＩＭ−２」しか広告されず，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＩＭ＿１上で搬送されるＢＣＭＣＳフローを広告しないが，ＩＭ＿１上のＢＣＭＣＳフローはセクタ内で依然として搬送されるものである。
　すなわち，ＢＯＭにおける広告の有無と物理チャネル上でのＢＣＭＣＳフローの搬送とは，直接関係するものではなく，第１および第２のクラスタが重複するか否かにかかわらず，セクタが第１のクラスタであれば第１の物理チャネル上で所与のマルチキャスト・セッションを搬送し，セクタが第２のクラスタであれば第２の物理チャネル上で所与のマルチキャスト・セッションを搬送するものである。そして，第１および第２のクラスタが少なくとも部分的に互いに重複するかどうかを判断することに基づいて，何らかの制御を行うことにより，第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送することを可能とするものではない。
　そして，そもそも第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送しているのであるから，「第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御する」とは，クラスタに対していかなる制御をしているのかも不明である。
　ここで，【００２９】の記載によれば，ＢＯＭは，移動局またはアクセス端末に特定のセクタで現在搬送されているＢＣＭＣＳフローについて通知するものであり，１つまたは複数のＢＣＭＣＳフロー用のＢＣＨ上で１つまたは複数のどのスロットを「同調させる」べきかについてマルチキャスト・グループ・メンバーに通知するものである。また，【００３０】の記載によれば，受信したＢＯＭを復号し，その静的マルチキャスト・グループに関連するフロー識別子を探し，１つまたは複数の所望のＢＣＭＣＳフローがＢＯＭ中で示されない場合，アクセス端末は１つまたは複数のＢＣＭＣＳフローを要求する自律ＢＣＭＣＳフロー登録メッセージを送信することを可能とするものであり，【００４８】の記載によれば，当該ＢＣＭＣＳフロー登録メッセージによりセクタはターゲットセクタに移行するものである。そして，セクタがターゲットセクタに移行することにより，ターゲットセクタ及びサポートセクタなるクラスタが形成され，当該クラスタにおいて所与のＩＭ対にて所与のＢＣＭＣＳフローが搬送されるものである。更に，【０１０９】の記載によれば，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７中のＢＣＭＣＳフローはＢＯＭ中のＩＭ＿２上で搬送されるものとして広告されないことにより，クラスタＸでサポートされるＡＴ  ＡおよびＡＴ  Ｂは，ＩＭ＿２上の所与のマルチキャスト・セッションを復号しようと試みず，また，セクタＸ＿Ｎ４／Ｙ＿Ｔ４中のＢＣＭＣＳフローはＢＯＭ中のＩＭ＿１上で搬送されるものとして広告されないことにより，クラスタＹでサポートされるＡＴ  Ｄは，ＩＭ＿１上で信号を復号しようと試みず，これによりバッテリ消費を低減することができることが理解できる。
　したがって，仮にＡＴ  Ｄが現在位置しているセクタＸ＿Ｎ４／Ｙ＿Ｔ４からセクタＸ＿Ｔ２／Ｙ＿Ｎ１７に移動した場合，セクタＸ＿Ｔ２／Ｙ＿Ｎ１７においてもＢＣＭＣＳフローがＩＭ＿２上で搬送されていることにより，ソフト結合が可能となるものの，上述のＢＯＭに基づくＡＴの動作に鑑みれば，図２６の例では，ＡＴ  ＤはＢＯＭによりＩＭ＿１に同調させるように制御されることが推察される。そうすると，意見書にて主張する「そのセクタ中のＡＴがターゲットセクタのクラスタにシフトすることとなり」，「ＡＴが，新しいセクタ中の「所与のマルチキャスト・セッション」を搬送する第１のクラスタのリソースユニットを特定することができなくなるため，ＡＴは，第２のクラスタに切り替えざるを得ません。」との事態が生じる可能性はあるかもしれない。そして，それにより，その後のＡＴ  ＤのＢＣＭＣＳフロー登録動作に伴うターゲットセクタの形成（ひいてはクラスタの形成）に影響が生じる可能性はあるかもしれない。すなわち，ＲＡＮ１２０が，ＢＯＭにより，クラスタのＩＭ対の一方を選択して，他方のクラスタを同じＩＭ対上に転送するかまたは切り替えようと試みることによって２つのクラスタを「マージ」するよう制御することはあるかもしれない。
　しかしながら，仮に，これらの事態が生じたとしても，重複セクタにおいてＩＭ＿２上でのＢＣＭＣＳフローの
搬送が不要になる
搬送することを可能となるように
　更にいえば，請求項１，１３〜１５には，ＢＯＭも，ＢＯＭに基づくＡＴの上記動作はなんら規定されてないから，上述のクラスタの「マージ」を認めることはできない。
　また，請求項１を引用する請求項３は，図２６ではなく図２７の例に対応するものであり，もともとＩＭ＿１およびＩＭ＿２上でＢＣＭＣＳフローが搬送されているところ，「特定のメッセージ」は「前記所与のマルチキャスト・セッションが前記第１の物理チャネルと前記第２の物理チャネルの両方の上で搬送されることを示す」ものであるから，マルチキャスト・セッションの搬送についてなんら制御はなされないものである。そして，請求項１を引用する請求項８も「少なくとも前記第１の物理チャネル上で搬送されることを示す」に留まり，請求項９のように図２６の例に対応する「前記所与のマルチキャスト・セッションが前記ダウンリンク・ブロードキャスト・チャネルの前記第２の物理チャネル上で搬送されることを示さない」ことまでは特定していない。したがって，図２７の例を含む請求項１，１３〜１５について，専ら図２６の例に基づいて主張する意見書の主張は，請求項１，１３〜１５の記載に基づくものではないから，採用できない。
　以上のとおりであるから，本願明細書には「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御すること」は記載されていないから，請求項１に係る発明は，発明の詳細な説明に記載されたものではない。請求項１３〜１５に係る発明についても同様である。
　また，「前記判断することに基づいて，前記第１および第２のクラスタの両方に属する１つまたは複数の重複セクタが，それぞれ，前記第１および第２の物理チャネル上で前記所与のマルチキャスト・セッションを搬送することを可能となるように，前記第１および第２のクラスタを制御すること」なる制御動作が不明確である。
第５　むすび
　以上のとおり，本件出願は，特許請求の範囲の記載に不備があり，特許法第３６条第６項第１号，第２号に規定する要件を満たしていないから，特許を受けることができない。
　よって，結論のとおり審決する。