【事件の表示】
　特願２０１０−１１３９２０「マルチキャステイング・コンテントのための選択ダイバーシチを提供する方法及びシステム」拒絶査定不服審判事件〔平成２２年１０月　７日出願公開、特開２０１０−２２６７４８、請求項の数（１８）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯
　本願は、平成１５年１０月２７日を国際出願日とする特願２００４−５４６３０５号の一部を平成２２年５月１８日に新たに特許出願したものであって、平成２４年１２月３日付けで拒絶査定がなされ、これに対し、平成２５年４月８日に審判請求がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年５月１９日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「同一のマルチキャスティング・コンテントを送信する無線送信器のセルを示すセル情報を少なくとも２つの無線送信器のセルから受信するステップ
と、
　前記少なくとも２つの無線送信器のセルからの受信クオリティを比較するステップと、
　マルチキャスティング・コンテントを受信するための２以上の無線送信器のセルを前記受信クオリティ及び前記セル情報に基づいて選択するステップと、を含む方法であって、
　前記受信クオリティを比較するステップは、前記少なくとも２つの無線送信器のセルから受信したパイロット信号の強度及びエラーの少なさのうちの少なくとも１つを比較することを含む、
ことを特徴とする方法。」
　
３．原査定の理由
　原査定の理由となった、平成２３年１１月１８日付けで通知された拒絶理由は、以下のとおりである。
　
「この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
・引用文献
　１.国際公開第０３／０６３４１８号
　（公表特許公報：特表２００５−５１６４７４号公報）
　２.特開平０７−１６２９３６号公報
　
・請求項：１−１８
　引用例１には、複数の基地局から複数の信号を受信できる端末が、同一のマルチキャストストリームを送信する複数の基地局のセクタから、マルチ
キャストサービスが継続して利用できるか否かの指示情報（引用例１の「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」であって、本願の「セル情報」に相
当）を受信し、マルチキャストストリームを受信するための基地局を、該指示情報に基づいて選択することが記載されている（引用例１の公表特許公報の【0017】,【0070】,【0099】-【0101】,図26を参照）。
　引用例２には、移動機が、複数の基地局のセルから信号を受信し、各信号の受信電界強度（本願の「受信クオリティ」に相当）を比較し、通信するための２つの基地局を該受信電界強度に基づいて選択してダイバーシチ受信を行うことが記載されており（引用例２の【0006】-【0009】を参照）、２つ
以上の基地局を選択して通信することは、システムの仕様や移動機の要求性能等により当業者が適宜定める事項である。
　
　引用例１の端末に対して引用例２の移動機の構成を適用し、マルチキャストストリームを受信するための２つ以上の基地局を、受信電界強度及び指示情報に基づいて選択することで、本願請求項に係る発明とすることは、当業者が容易に想到しうることである。」
　
４．引用例
　原査定の拒絶の理由に引用された国際公開第０３／０６３４１８号（以
下、「引用例」という。）には、図面とともに以下の記載がなされている。
　
（１）「[1038] Broadcast services may also be used for multicasting. Multicast may refer to the ability to broadcast information to 
a specific set of users based on their subscription to a user group. The user group may be maintained by an administrator. In addition, the user group may be publicly subscribable (e.g., sign-up for 
advertisement, stock quotes, etc.), or it may be closed to public 
subscription (e.g., corporate list). The multicast list may also be configured to have the mobile device acknowledge receipt of the 
message as defined by the user group administrator. This could be 
considered addressable messaging.
 [1039] Multicast user groups are generally considered to be closed groups. In these groups a member typically subscribes to the service (public multicast group) by sending a request to the administrator, by some web interface, or other mechanism. A private multicast 
group is restricted to membership explicitly by the administrator 
manually adding members.」
　
（２）「[1057] Referring to FIG. 4, a broadcast/multicast service 
provided by a CS 402 includes transmitting broadcast content 404. 
The broadcast content 404 may be a fixed set of data or may be a 
continuous stream of data. The broadcast/multicast service typically has a broadcast/multicast service name 406 used to identify the 
broadcast service. In the embodiment illustrated in FIG. 4, the 
service name 406 is a text-based name that users can read and 
interpret. For example, possible service names 406 include CNN News, NBC Sports, etc. 
[1058] The service name 406 is associated with a service 
identification (service ID) 408. The service ID 408 is typically 
a number and is used to identify the particular broadcast/multicast service. The service ID 408 is an identifier for the broadcast/
multicast service and in particular embodiments herein may be 
referred to as the BCMCS_ID. Accordingly, the term service ID 408 is a broad term that encompasses the BCMCS_ID as described herein. 
[1059] The CS 402 of FIG. 4 provides a single broadcast/multicast 
service. FIG. 5 illustrates a CS 502 that provides more than one 
broadcast/multicast service. The CS 502 of FIG. 5 provides two 
broadcast/multicast streams of broadcast content 504a, 504b where 
each broadcast has an associated service name 506a, 506b and service ID 508a, 508b. As shown in FIG. 5, the service may have more than 
one service name 506b. Synonymous service names 506b(1), 506b(2), 
506b(3) may all be used to identify the same broadcast content 
504b.」
　
（３）「[1070] FIG. 11 is a flow diagram of a method for advertising the availability of certain broadcast/multicast services. The CS 
202 sends 1102 the BCMCS_ID 804 to PDSNs 206 via the IP Network 204. The PDSNs 206 receive this information and send 1104 it on to one 
or more BSs 208. A BS 208 receives 1106 the BCMCS_ID 804 and 
configures a Broadcast Service Parameters Message (BSPM) to transmit to MSs 210 within the cell/sector. The BS 208 then sends 1108 the 
BSPM out over an overhead channel. The MS 210 receives 1110 the BSPM and determines the broadcast/multicast services that are available and the details for tuning it to and receiving the services. 
[1071] A BCMCS_ID 804 has one or more IP multicast addresses 908 
associated with it. The mapping between BCMCS_ID 804 and IP 
multicast address 908 may be one-to-one, many-to-one, or 
one-to-many. As shown in FIG. 12, a BCMCS_ID 804 may be associated 
with one IP multicast address 908 to form a one-to-one relationship.[1072] As shown in FIG. 13, multiple BCMCS_IDs 804a, 804b may be 
mapped to a single IP multicast address 908. For example, a CS 202 
may send multiple services via the same IP multicast address 908 and the different services may be distinguished via UDP port numbers.
[1073] Referring now to FIG. 14, a single BCMCS_ID 804 may be mapped to multiple IP multicast addresses 908a, 908b. For example, a CS 
202 may want to provide a global multicast/broadcast service spanned across multiple carriers and geographic regions. The CS 202 may use regional servers (one per geographic region which may be shared by multiple carriers) to distribute the content more efficiently, 
in order to avoid the delay if a single server (with single IP 
multicast address 908) would be used for all regions and carriers in the world. It is possible that in different regions, different IP 
multicast addresses 908 may be assigned to the same BCMCS_ID 804. 
In the embodiment where a BCMCS_ID 804 maps to multiple IP multicast addresses 908a, 908b, within a same region the BCMCS_ID 804 is only associated with a single IP multicast address 908. One disadvantage of this one-to-many mapping from BCMCS_ID 804 to IP multicast 
addresses 908 is that when a MS 210 moves to a new region, the MS 
210 needs to find out, manually or automatically, the new IP 
multicast address 908 and other parameters (e.g. security 
association) of the service via some out-of-band mechanisms. This 
disadvantage may lead to long service interruption if the MS 210 is being hard-handoff from one region to another.」
　
（４）「[1091] FIG. 20 illustrates four adjacent sectors, sector A 
2002, sector B 2004, sector C 2006 and sector D 2008. The BS in each sector transmits a BSPM specific to that sector. The BS 2010 in 
sector A 2002 transmits BSPM A 2012, the BS 2014 in sector B 2004 
transmits BSPM B 2016 and the BS 2018 in sector C 2006 transmits 
BSPM C 2020. Similarly, BSPM D 2024 is transmitted in sector D 2008. The BSPM in each sector is configured to include information about the broadcast services in each adjacent sector. As a result, an MS 
210 moving from one sector to another sector may obtain the 
information in the BSPM to determine what broadcast services are 
available in the destination sector, what BCMCS_IDs are available, 
and other related parameters.
[1092] FIG. 21 illustrates a method 2100 of providing broadcast 
service parameter and protocol information using a BSPM. At step 
2102 the MS 210 receives the BSPM from the CS 202. An embodiment of a BSPM is described below with respect to FIG. 26. The MS 210 
extracts the SO number from the BSPM at step 2104. The SO number is mapped to a set of parameters and protocols sufficient for the MS 
210 to receive the desired broadcast. The MS 210 then initiates the protocol stack corresponding to the selected SO number at step 2106. Once the protocol stack is initiated, the MS 210 is able to receive and decode information received on the broadcast channel at step 
2108. Note that the BSPM is transmitted on a separate Walsh channel known to the subscribers.」
　
（５）「[1128] As stated above, when the MS moves from sector A to 
sector B the MS needs to determine the relationship between the 
BCMCS_IDs transmitted in sector A and the BCMCS_IDs transmitted in 
sector B in order to properly handle the broadcast service it is 
currently monitoring. The following describes such BCMCS_ID related 
handoff issues.
[1129] Referring to the embodiment where the BCMCS_ID is globally 
unique, the handoff procedures are straightforward. When the MS 
moves from sector A to sector B (refer to FIG. 20) one of the 
following may occur. If sector B transmits the same BCMCS_ID as 
sector A, then the MS may conclude that the broadcast service 
session transmitted by sector B is the same as sector A. If sector B does not transmit the same BCMCS_ID as sector A, then the MS can 
conclude that the broadcast service that it is currently monitoring cannot be continued in sector B.
[1130] The BS may set the NGHBR_HSBS_CONFIG field as specified in 
FIG. 27 to indicate the configuration of this HSBS session in this 
neighbor BS. As a result, the MS may examine the value of 
HSBS_NGHBR_CONFIG received in the BSPM to determine handoff.
[1131] FIG. 28 illustrates a flow diagram of the MS examining the 
value of HSBS_NGHBR_CONFIG received in the BSPM to determine 
handoff. At step 2802 the MS is receiving broadcast service and is 
moving into another sector. The MS consults the BSPM of the current sector at step 2804. At step 2806 the MS examines HSBS_NGHBR_CONFIG. Depending upon the value of HSBS_NGHBR_CONFIG, the MS may perform 
the following. If HSBS_NGHBR_CONFIG is '000' (i.e. unknown), the MS stops 2810 HSBS reception and performs an idle handoff to the 
neighbor BS and searches for the same BCMCS_ID. If HSBS_NGHBR_CONFIG is '001/010' (i.e. service available in neighbor BS), the MS can 
continue 2808 reception in the neighbor BS.
[1132] In the embodiments where the BCMCS_ID is locally unique, the handoff procedures are more detailed because the MS may not know the relationship between BCMCS_IDs transmitted in different sectors. 
For locally unique BCMCS_IDs and handoff, there are three cases. The first case is where the broadcast service transmitted in the two 
sectors are not related to each other. One example of this would be two carriers with no roaming agreement. The second case is where the same broadcast service is available in both sectors, but the 
BCMCS_IDs used for the service in each sector are different. 
An example of this case is where a roaming agreement exists between carriers but they selected the BCMCS_IDs independently. The third 
case is where the same broadcast service is available in both 
sectors and the BCMCS_IDs used are identical. One example of this 
third case is where both sectors belong to the same carrier. Another example is where there is a roaming agreement between both carriers and they coordinated to select the same BCMCS_ID. In the second and third cases broadcast service reception can be continued in the new sector. In case one the broadcast service reception is terminated. [1133] Because the MS cannot determine which of the above three 
cases applies as it crosses a sector boundary, the BS explicitly 
signals to the MS the relationship between BCMCS_IDs transmitted in both sectors. This information can be carried in the BSPM 
transmitted in each sector. 
[1134] Recall that the BSPM, shown in FIG. 26, sent by a given BS 
contains information about HSBS sessions in each of its neighbor 
BSs. Specifically, for each logical-to-physical mapping of BCMCS_ID being transmitted in the current BS, the neighbor info listed in the BSPM contains NUM_NGHBR occurrences of NGHBR_PN and NGHBR_HSBS_
CONFIG. The information in the BSPM may be enhanced to include 
information on whether the neighbor BS uses the same BCMCS_ID for 
this session. Two new fields may be included in the BSPM: NGHBR_
BCMCS_ID_MAPPING_INCL 2902 and NGHBR_BCMCS_ID 2904. FIG. 29 
illustrates where these fields may be placed in the BSPM. 
[1135] When NGHBR_HSBS_CONFIG is set to '000' (i.e. Unknown), the 
current BS is not knowledgeable about the neighbor BS HSBS setup. 
As such, the MS assumes there is no relation between the BCMCS_IDs 
transmitted on the neighbor BS with respect to those transmitted on the current BS. Thus, the field NGHBR_BCMCS_ID_MAPPING_INCL is not 
included in this case. 
[1136] When NGHBR_HSBS_CONFIG equals '001 (i.e. being transmitted 
but cannot soft-combine), the field NGHBR_BCMCS_ID_MAPPING_INCL is 
included and is set as follows. If the neighbor BS is using the same BCMCS_ID value for this session, then set it to '0'. If the 
neighbor BS is using a different BCMCS_ID value for this session, 
then set it to '1' and include the NGHBR_BCMCS_ID corresponding to 
this session.
[1137] When NGHBR_HSBS_CONFIG equals '010 (i.e. being transmitted 
and can soft-combine), then all parameters on the neighbor BS are 
identical to the current BS since soft-combining is allowed. Thus, 
the MS assumes the same BCMCS_ID is used in the neighbor BS for this HSBS session. The field NGHBR_BCMCS_ID_MAPPING_INCL is not included in this case. 
[1138] FIG. 30 is a flow diagram illustrating a method for an MS to process BCMCS_IDs during handoff. At step 3002 the MS is receiving 
broadcast service and is moving into another sector. The MS consults the BSPM of the current sector at step 3004. At step 3006 the MS 
examines NGHBR_HSBS_CONFIG. Depending upon the value of NGHBR_HSBS_
CONFIG, the MS may perform the following. 
[1139] If NGHBR_HSBS_CONFIG=000, the MS may stop 3008 reception and perform an idle handoff to the neighbor BS, and then read the new 
sector's BSPM. If the same BCMCS_ID is found on the neighbor BS, the MS assumes 3010 there is no relation to the HSBS session with same BCMCS_ID in previous BS.
[1140] If NGHBR_HSBS_CONFIG=001 , then the MS examines the value for NGHBR_BCMCS_ID_MAPPING_INCL 
NGHBR_BCMCS_ID_MAPPING_INCL=0, the MS assumes 3012 that an HSBS 
session using the same BCMCS_ID in the neighbor BS corresponds to 
the same HSBS session. If NGHBR_BCMCS_ID_MAPPING_INCL=1 , upon 
performing handoff to the neighbor BS, the MS treats 3014 the 
session with NGHBR_BCMCS_ID as being equal to the session with 
BCMCS_ID and continues reception across handoff. The MS may need to update the upper layer service instance of the new NGHBR_BCMCS_ID 
(since the upper layer also uses the BCMCS_ID for other purposes 
such as security). 
[1141] If NGHBR_HSBS_CONFIG=010, then the MS assumes 3016 the same 
BCMCS_ID is used in the neighbor BS.
[1142] As described herein, the foregoing scheme provides several 
advantages. HSBS session continuation is possible even if the BCMCS_ID used by two carriers are not identical. In addition, carriers can define BCMCS_ID boundaries as they please. This provides carriers 
flexibility in reusing values in the face of BCMSC_ID shortages. 
Finally, the MS does not need to be concerned about crossing 
a carrier boundary. That is, the MS doesn't have to pay attention to SID/NID changes, etc.」
　
（６）「[1145] The following describes handoff procedures for the 
embodiments where the BCMCS_ID may be either locally or globally 
unique. As described in relation to FIGS. 17-19, the BCMCS_ID may be either globally unique or locally unique as indicated by the global indicator 1704. The handoff issues in this case are similar to the handoff issues for services using globally-unique BCMCS_IDs and 
similar to handoff issues for services using locally-unique 
BCMCS_IDs.
[1146] The rules for the BS setting the NGHBR_BCMCS_ID_MAPPING_INCL and NGHBR_BCMCS_ID fields of the BSPM may be similar to the methods described above in relation to FIG. 29 with the following addition: the NGHBR_BCMCS_ID_MAPPING_INCL field may be omitted from the BSPM 
for globally-unique BCMCS_IDs. 
[1147] FIG. 31 illustrates an embodiment of a method for the MS to 
process the BSPM with respect to the BCMCS_IDs. At step 3102 the MS is receiving broadcast service and is moving into another sector. 
The MS consults the BSPM of the current sector at step 3104. At step 3106 the MS examines dual BCMCS_ID to determine whether it is 
globally unique or locally unique. If the MS determines that the 
BCMCS_ID is globally unique, then MS follows the steps as outlined 
in FIG. 28 to handle the broadcast service across handoff. If the MS determines that the BCMCS_ID is not globally unique, then MS 
follows the steps as outlined in FIG. 30 to handle the broadcast 
service across handoff. Note that the alternative mechanism 
described for locally unique BSMCSJDs is applicable to the 
locally-unique BCMCS_IDs in this embodiment as well.」
　
　引用例のパテントファミリである特表２００５−５１６４７４号公報の対応する記載は以下のとおりである。
　
（１’）「【０００８】
　放送サービスは、マルチキャスティングに対しても使用される可能性がある。マルチキャストは、ユーザグループへの加入に基づいてユーザの特定のセットに対して情報を放送する能力を呼ぶ可能性がある。そのユーザグループは、管理者によって維持される可能性がある。付け加えると、ユーザグ
ループは、公然と応募できる（例えば、宣伝申込み、株式取引、等）可能性があり、若しくは公開申込み(public subscription)（例えば、共通リスト
(corporate list)）が締め出される可能性がある。マルチキャストリスト
は、ユーザグループ管理者により規定されたようにメッセージの受信を知らせる移動装置を所有するために構成される可能性がある。これは、アドレスで呼び出せるメッセージングと考えられるはずである。
【０００９】
　マルチキャストユーザグループは、クローズドグループであると一般に考えられる。これらのグループでは、メンバーは、管理者に要求を送ることによって、ある種のウェブインターフェースによって、若しくは他のメカニズムでサービス（公開マルチキャストグループ）に一般に加入する。非公開の(private)マルチキャストグループは、管理者がメンバーを手動で追加する
ことによって厳格にメンバーシップを制限される。」
　
（２’）「【００２７】
　図４を参照して、ＣＳ４０２によって提供された放送／マルチキャスト
サービスは、放送コンテント４０４を送信することを含む。放送コンテント４０４は、データの固定セットである可能性がある、若しくはデータの連続したストリームである可能性がある。放送／マルチキャストサービスは、一般に、放送サービスを認識するために使用される放送／マルチキャストサービスネーム４０６を有する。図４に図示された実施形態では、サービスネーム４０６は、ユーザが読み出せインタープリットできるテキストに基づいた名前である。例えば、可能性のあるサービスネーム４０６は、ＣＮＮニュース、ＮＢＣスポーツ、等、を含む。
【００２８】
　サービスネーム４０６は、サービスアイデンティフィケーション（サービスＩＤ）４０８に関連付けられる。サービスＩＤ４０８は、一般に数字であり、そして特定の放送／マルチキャストサービスを認識するために使用される。サービスＩＤ４０８は、放送／マルチキャストサービスに対するアイデンティファイアであり、ここでの特定の実施形態では、ＢＣＭＣＳ＿ＩＤとして呼ばれる可能性がある。したがって、用語サービスＩＤ４０８
は、ここで述べられたようにＢＣＭＣＳ＿ＩＤを含む広い用語である。
【００２９】
　図４のＣＳ４０２は、単一の放送／マルチキャストサービスを提供する。図５は、1以上の放送／マルチキャストサービスを提供するＣＳ５０２を示
す。図５のＣＳ５０２は、放送コンテント５０４ａ，５０４ｂの２つの放送／マルチキャストストリームを提供する。ここで各放送は、関連付けたサービスネーム５０６ａ，５０６ｂ及びサービスＩＤ５０８ａ、５０８ｂを有する。図５に示されたように、サービスは、１以上のサービスネーム５０６ｂを有する可能性がある。類似のサービスネーム５０６ｂ（１），５０６ｂ
（２），５０６ｂ（３）は、全て同一の放送コンテント５０４ｂを認識するために使用される可能性がある。」
　
（３’）「【００４０】
　図１１は、ある種の放送／マルチキャストサービスが利用できることを宣伝するための方法のフロー図である。ＣＳ２０２は、ＩＰネットワーク２０４を介してＰＤＳＮｓ２０６へＢＣＭＣＳ＿ＩＤ８０４を送信する１１０
２。ＰＤＳＮｓ２０６は、この情報を受信し、そして1若しくはそれ以上の
ＢＳｓ２０８へそれを送信する１１０４。ＢＳ２０８は、ＢＣＭＣＳ＿ＩＤ８０４を受信し１１０６、そしてセル／セクタ内のＭＳｓ２１０へ送信するために放送サービスパラメータメッセージ（ＢＳＰＭ）を構成する。ＢＳ２０８は、オーバーヘッドチャネルを介してＢＳＰＭを外へ送信する１１０
８。ＭＳ２１０は、ＢＳＰＭを受信し１１１０、そして利用可能な放送／マルチキャストサービス及びそのサービスに同調するためそして受信するための詳細を決定する。
【００４１】
　ＢＣＭＣＳ＿ＩＤ８０４は、それに関連付けられた1若しくはそれ以上の
ＩＰマルチキャストアドレス９０８を有する。ＢＣＭＣＳ＿ＩＤ８０４とＩＰマルチキャストアドレス９０８との間のマッピングは、１−対−１、複数−対−１、若しくは１−対−複数である可能性がある。図１２に示されたように、ＢＣＭＣＳ＿ＩＤ８０４は、１のＩＰマルチキャストアドレス９０８に関連付けられる可能性があり、１−対−１の関係を形成する。
【００４２】
　図１３に示されたように、複数のＢＣＭＣＳ＿ＩＤｓ８０４ａ，８０４ｂは、単一のＩＰマルチキャストアドレス９０８に対してマップされる可能性がある。例えば、ＣＳ２０２は、同一のＩＰマルチキャストアドレス９０８を介して複数のサービスを送信する可能性があり、そして異なるサービス
は、ＵＤＰポート番号を介して識別される可能性がある。
【００４３】
　ところで図１４を参照して、単一のＢＣＭＣＳ＿ＩＤ８０４は、複数のＩＰマルチキャストアドレス９０８ａ，９０８ｂに対してマップされる可能性がある。例えば、ＣＳ２０２は、複数のキャリア及び地理的領域にわたりまたがったグローバルマルチキャスト／放送サービスを提供することを望む可能性がある。（単一のＩＰマルチキャストアドレス９０８を有する）単一のサーバが、世界中の全ての領域及びキャリアに対して使用されるはずであるのであれば、遅延を回避するために、ＣＳ２０２は、（複数のキャリアにより共有される可能性がある地理的領域あたり１の）地域的なサーバを使用する可能性があり、より効率的にコンテントを配送する。異なる領域におい
て、異なるＩＰマルチキャストアドレス９０８が同一のＢＣＭＣＳ＿ＩＤ８０４に対して割り当てられる可能性があることは可能である。ＢＣＭＣＳ＿ＩＤ８０４が複数のＩＰマルチキャストアドレス９０８ａ，９０８ｂに対してマップする実施形態では、同一の領域内で、ＢＣＭＣＳ＿ＩＤ８０４は、単一のＩＰマルチキャストアドレス９０８に関連付けられるだけである。ＢＣＭＣＳ＿ＩＤ８０４からＩＰマルチキャストアドレス９０８へのこの１−対−複数マッピングの１つの欠点は、ＭＳ２１０が新しい領域に移動する場合に、ＭＳ２１０が、アウト−オブ−バンドメカニズムを介して新しいＩＰマルチキャストアドレス９０８及びサービスの他のパラメータ（例えば、安全提携(security association)）を、手動若しくは自動的に、見つけ出すことが必要である。この欠点は、ＭＳ２１０が１つの地域から他へハードハンドオフをしようとするのであれば、長いサービスの中断を生じる可能性がある。」
　
（４’）「【００６１】
　図２０は、４つの隣接するセクタ、セクタＡ２００２、セクタＢ２００
４、セクタＣ２００６及びセクタＤ２００８を図示する。各セクタ中のＢＳは、そのセクタに特定のＢＳＰＭを送信する。セクタＡ２００２中のＢＳ２０１０は、ＢＳＰＭ  Ａ２０１２を送信し、セクタＢ２００４中のＢＳ２０１４は、ＢＳＰＭ　Ｂ２０１６を送信し、そしてセクタＣ２００６中のＢＳ２０１８は、ＢＳＰＭ　Ｃ２０２０を送信する。同様に、ＢＳＰＭ　Ｄ２０２４は、セクタＤ２００８において送信される。各セクタにおけるＢＳＰＭは、各隣接のセクタにおける放送サービスに関する情報を含んで構成され
る。その結果、１つのセクタから他のセクタへ移動しているＭＳ２１０は、ＢＳＰＭ中の情報を得る可能性があり、どんな放送サービスが目的地のセクタで利用できるか、どんなＢＣＭＣＳ＿ＩＤが利用できるか、及び他の関連するパラメータを決定する。
【００６２】
　図２１は、ＢＳＰＭを使用して放送サービスパラメータ及びプロトコルを提供する方法２１００を図示する。ステップ２１０２において、ＭＳ２１０は、ＣＳ２０２からＢＳＰＭを受信する。ＢＳＰＭの実施形態は、図２６に関連付けて以下に説明される。ＭＳ２１０は、ステップ２１０４においてＢＳＰＭからＳＯ番号を抽出する。ＳＯ番号は、ＭＳ２１０が希望する放送を受信するために十分なパラメータ及びプロトコルのセットにマップされる。ＭＳ２１０は、その後、ステップ２１０６において、選択されたＳＯ番号に対応するプロトコルスタックを開始する。プロトコルスタックが一旦開始されると、ＭＳ２１０は、ステップ２１０８において、放送チャネルにおいて受信し、受信した情報をデコードすることができる。ＢＳＰＭが加入者に通知された別々のウォルシュチャネルにおいて送信されることに注意する。」
　
（５’）「【００９８】
　上述したように、ＭＳがセクタＡからセクタＢへ移動する場合に、現在モニタリングされている放送サービスを適切に取り扱うために、セクタＡにおいて送信されたＢＣＭＣＳ＿ＩＤｓとセクタＢにおいて送信されたＢＣＭＣＳ＿ＩＤｓとの間の関係を決定する必要がある。以下のものは、ハンドオフ問題に関係するそのようなＢＣＭＣＳ＿ＩＤを説明する。
【００９９】
　ＢＣＭＣＳ＿ＩＤがグローバルに固有である実施形態を参照すると、ハンドオフ手順は、単純明快である。ＭＳがセクタＡからセクタＢへ移動する場合に（図２０参照）、以下の１つが生じる可能性がある。セクタＢがセクタＡと同一のＢＣＭＣＳ＿ＩＤを送信するのであれば、セクタＢによって送信された放送サービスセッションがセクタＡと同一であると、ＭＳは、決定する可能性がある。セクタＢがセクタＡと同一のＢＣＭＣＳ＿ＩＤを送信しないのであれば、現在モニタしている放送サービスがセクタＢにおいて継続できないと決定できる。
【０１００】
　ＢＳは、この隣接するＢＳにおいてこのＨＳＢＳセッションの構成を指示するために、図２７に明記されたようにＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧフィールドを設定する。その結果、ＭＳは、ハンドオフを決定するためにＢＳＰＭにおいて受信されたＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧの値を検査する可能性がある。
【０１０１】
　図２８は、ハンドオフを決定するためにＢＳＰＭにおいて受信されたＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧの値をＭＳが検査するフロー図を示す。ステップ２８０２において、ＭＳは、放送サービスを受信しながら、他のセクタへ移動する。ＭＳは、ステップ２８０４において現在のセクタのＢＳＰＭを調査する。ステップ２８０６において、ＭＳは、ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧを検査する。ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧの値に依存して、ＭＳは、以下を実施する可能性がある。ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧが‘０００’である（すなわち、未知である）ならば、ＭＳは、ＨＳＢＳ受信を中止し、そして隣接するＢＳへアイドルハンドオフを実施して同一のＢＣＭＣＳ＿ＩＤを検索する２８１０。ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧが‘００１／０１０’である（すなわち、隣接のＢＳにおいてサービスが利用できる）ならば、ＭＳは、隣接するＢＳにおいて受信を継続できる２８０８。
【０１０２】
　ＢＣＭＣＳ＿ＩＤがローカルに固有である実施形態では、ＭＳが異なるセクタにおいて送信されたＢＣＭＣＳ＿ＩＤ間の関係を知らない可能性があるため、ハンドオフ手順は、より詳細に説明される。ローカルに固有なＢＣＭＣＳ＿ＩＤｓ及びハンドオフに関して、３つのケースがある。第１のケースは、２つのセクタにおいて送信された放送サービスが、互いに関係しない場合である。この１例は、ローミング取り決めをしていない２つのキャリアがあるはずである。第２のケースは、同一の放送サービスが両方のセクタにおいて利用できるが、各セクタにおけるサービスに対して使用されたＢＣＭＣＳ＿ＩＤｓが異なる場合である。このケースの１例は、ローミング取り決めがキャリア間で存在するが、それらが別々にＢＣＭＣＳ＿ＩＤｓを選択する場合である。第３のケースは、同一の放送サービスが両方のセクタにおいて利用可能であり、使用されるＢＣＭＣＳ＿ＩＤｓが同じで
ある場合である。この第３のケースの１例は、両方のセクタが、同一のキャリアに属する場合である。他の例は、両方のキャリア間でローミング取り決めがあり、同一のＢＣＭＣＳ＿ＩＤを選択するために調整した場合である。第２及び第３のケースでは、放送サービス受信は、新しいセクタにおいて継続されることができる。ケース１では、放送サービス受信は、終了する。
【０１０３】
　ＭＳがセクタ境界を横切るときに、上記の３つのケースのどれを適用するかをＭＳが決定できないために、ＢＳは、両方のセクタにおいて送信されたＢＣＭＣＳ＿ＩＤｓの間の関係をＭＳへ明確に信号を送る。この情報は、各セクタにおいて送信されたＢＳＰＭ中で搬送されることができる。
【０１０４】
　図２６に示されたように、所定のＢＳによって送信されたＢＳＰＭは、その隣接するＢＳｓの各々におけるＨＳＢＳセッションに関する情報を含むことを思い出す。具体的には、現在のＢＳ中にこれから送信されるＢＣＭＣＳ＿ＩＤの各論理的−対−物理的マッピングに対して、ＢＳＰＭ中にリストされた隣接情報は、ＮＧＨＢＲ＿ＰＮ及びＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧのＮＵＭ＿ＮＧＨＢＲ発生数を含む。ＢＳＰＭ中の情報は、隣接するＢＳがこのセッションに対して同一のＢＣＭＣＳ＿ＩＤを使用するかどうかの情報を含むために促進される可能性がある。２つの新しいフィールドは、ＢＳＰＭ中に含まれる可能性がある：ＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬ２９０２及びＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ２９０４である。図２９は、ＢＳＰＭ中のどこにこれらのフィールドが置かれる可能性があるかを図示する。
【０１０５】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧが‘０００’に設定される（すなわち、未知である）場合に、現在のＢＳは、隣接するＢＳ  ＨＳＢＳセット
アップに関する見識がない。そのようにして、ＭＳは、現在のＢＳに送信されたものに対して隣接するＢＳに送信されたＢＣＭＣＳ＿ＩＤｓとの間に関係が存在しないと仮定する。それゆえ、フィールドＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬは、この場合には含まれない。
【０１０６】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧが‘００１’に等しい（すなわち、これから送信されるが、ソフト統合できない）場合には、フィールドＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬは含まれ、そして以下のように設定される。隣接するＢＳが、このセッションに対して同一のＢＣＭＣＳ＿ＩＤを使用しているのであれば、それを‘０’に設定する。隣接するＢＳが、このセッションに対して異なるＢＣＭＣＳ＿ＩＤを使用しているのであれば、それを‘１’に設定し、そしてこのセッションに対応するＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤを含む。
【０１０７】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧが‘０１０’に等しい（すなわち、これから送信され、そしてソフト統合できる）場合には、隣接するＢＳの全てのパラメータは、ソフト統合が可能であるので、現在のＢＳと同じであ
る。このようにして、ＭＳは、同一のＢＣＭＣＳ＿ＩＤがこのＨＳＢＳセッションに対して隣接するＢＳにおいて使用されると仮定する。フィールドＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬは、このケースには含まれない。
【０１０８】
　図３０は、ＭＳがハンドオフの間にＢＣＭＣＳ＿ＩＤｓを処理する方法を示すフロー図である。ステップ３００２において、ＭＳは、放送サービスを受信しながら、他のセクタへ移動している。ＭＳは、ステップ３００４において現在のセクタのＢＳＰＭを調べる。ステップ３００６において、ＭＳ
は、ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧを検査する。ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧの値に依存して、ＭＳは、以下を実施する可能性がある。
【０１０９】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝０００であれば、ＭＳは、３００８で受信を中止して隣接するＢＳにアイドルハンドオフを実施して、その
後、新しいセクタのＢＳＰＭを読む。同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳで見つけらるのであれば、ＭＳは、３０１０で以前のＢＳ中と同一のＢＣＭＣＳ＿ＩＤを有するＨＳＢＳセッションに関係ないと仮定する。
【０１１０】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝００１であれば、ＭＳは、ＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬに対する値を検査す
る。
【０１１１】
ＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬ＝０、ＭＳは、３０１２において隣接するＢＳ中の同一のＢＣＭＣＳ＿ＩＤを使用するＨＳＢＳセッションが同一のＨＳＢＳセッションに対応すると仮定する。ＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬ＝１であれば、隣接するＢＳにハンドオフを実施するに伴い、ＭＳは、ＢＣＭＣＳ＿ＩＤを有するセッションと同等になるとしてＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤを有するセッションを取り扱い、そしてハンドオフにわたって受信を継続する３０１４。（上位レイヤーも安全性のような他の目的に対してＢＣＭＣＳ＿ＩＤを使用するため）ＭＳは、新しいＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤの上位レイヤー
サービスインスタンスをアップデートする必要がある可能性がある。
【０１１２】
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝０１０であれば、ＭＳは、同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳにおいて使用されると仮定する３０１６。
【０１１３】
　ここで説明したように、これまでのスキームは、いくつかの利点を与え
る。ＨＳＢＳセッションの継続は、２つのキャリアによって使用されるＢＣＭＣＳ＿ＩＤが同じでない場合であっても可能である。付け加えると、キャリアは、希望するようにＢＣＭＣＳ＿ＩＤ境界を規定できる。これは、ＢＣＭＣＳ＿ＩＤ不足に直面して結果としての値についての自由度をキャリアに与える。最終的に、ＭＳは、キャリア境界を横切ることに関して懸念する必要がない。すなわち、ＭＳは、ＳＩＤ／ＮＩＤ変更、等に注意を払う必要性がない。」
　
（６’）「【０１１６】
　以下は、ＢＣＭＣＳ＿ＩＤがローカルに若しくはグローバルに固有のいずれかである可能性がある実施形態に対するハンドオフ手順を説明する。図１７−１９に関連して説明したように、ＢＣＭＣＳ＿ＩＤは、グローバルインディケータ１７０４によって指示されたようにグローバルに固有な若しくはローカルに固有のいずれかである可能性がある。この
ケースにおけるハンドオフ問題は、グローバルに固有なＢＣＭＣＳ＿ＩＤｓを使用するサービスに対するハンドオフ問題と同様であり、そしてローカルに固有なＢＣＭＣＳ＿ＩＤｓを使用するサービスに対するハンドオフ問題と同様である。
【０１１７】
　ＢＳＰＭのＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬ及びＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤフィールドをＢＳが設定することに対するルールは、図２９に関連して上記した方法に以下を追加した方法と同様である可能性がある：ＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤ＿ＭＡＰＰＩＮＧ＿ＩＮＣＬフィールドがグローバルに固有なＢＣＭＣＳ＿ＩＤｓに対するＢＳＰＭから省略される可能性があることである。
【０１１８】
　図３１は、ＢＣＭＣＳ＿ＩＤｓに関連してＭＳがＢＳＰＭを処理するための方法の実施形態を示す。ステップ３１０２において、ＭＳは、放送サービスを受信しながら、他のセクタへ移動している。ＭＳは、ステップ３１０４において、現在のセクタのＢＳＰＭを調べる。ステップ３１０６において、ＭＳは、デュアルＢＣＭＣＳ＿ＩＤを検査して、それがグローバルに固有であるか若しくはローカルに固有であるかどうかを決定する。ＭＳが、ＢＣＭＣＳ＿ＩＤがグローバルに固有であると決定するのであれば、ＭＳは、図２８に概略示されたステップにしたがって、ハンドオフにわたって放送サービスを取り扱う。ＭＳが、ＢＣＭＣＳ＿ＩＤがグローバルに固有でないと決定するのであれば、ＭＳは、図３０に概略示されたステップにしたがって、ハンドオフにわたって放送サービスを取り扱う。ローカルに固有なＢＣＭＣＳ＿ＩＤｓに対して説明された代わりのメカニズムが、この実施形態におけるローカルに固有なＢＣＭＣＳ＿ＩＤｓに対して同様に適用できることに注意する。」
　
　したがって、引用例には次の発明（以下、「引用発明」という。）が記載されているといえる。
　
　放送／マルチキャストサービスが利用できるための方法であって、
　ＭＳがセクタＡからセクタＢへ移動する場合に、現在モニタリングされている放送サービスを適切に取り扱うために、セクタＡにおいて送信されたＢＣＭＣＳ＿ＩＤとセクタＢにおいて送信されたＢＣＭＣＳ＿ＩＤとの間の関係を決定するために、（ここで、ＢＣＭＣＳ＿ＩＤは、放送／マルチキャストサービスに対するアイデンティファイアである。）
　ＭＳは、ハンドオフを決定するために現在のセクタのＢＳＰＭを調べ、ＢＳＰＭにおいて受信されたＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧの値を検査し、（ここで、ＢＳＰＭは、各隣接のセクタにおける放送サービスに関する情報を含んで構成され、その結果、１つのセクタから他のセクタへ移動しているＭＳは、ＢＳＰＭ中の情報を得る可能性があり、どんな放送サービスが目的地のセクタで利用できるか、どんなＢＣＭＣＳ＿ＩＤが利用できるか、及び他の関連するパラメータを決定するためのものであり、ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧは隣接するＢＳにおいてＨＳＢＳセッションの構成を指示するためのものである。）
　ＭＳはＢＣＭＣＳ＿ＩＤを検査し、ＢＣＭＣＳ＿ＩＤがグローバルに固有である場合に、
　ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧの値が‘０００’である（すなわ
ち、未知である）ならば、ＭＳは、ＨＳＢＳ受信を中止し、そして隣接するＢＳへアイドルハンドオフを実施して同一のＢＣＭＣＳ＿ＩＤを検索し、
　ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧが‘００１／０１０’である（すなわち、隣接のＢＳにおいてサービスが利用できる）ならば、ＭＳは、隣接するＢＳにおいて受信を継続し、
　ＭＳはＢＣＭＣＳ＿ＩＤを検査し、ＢＣＭＣＳ＿ＩＤがローカルに固有である場合に、
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝０００であれば、ＭＳは、受信を中止して隣接するＢＳにアイドルハンドオフを実施して、その後、新しいセクタのＢＳＰＭを読み、同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳで見つけらるのであれば、ＭＳは、以前のＢＳ中と同一のＢＣＭＣＳ＿ＩＤを有するＨＳＢＳセッションに関係ないと仮定し、
　ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝００１であれば、ＭＳは、隣接するＢＳ中の同一のＢＣＭＣＳ＿ＩＤを使用するＨＳＢＳセッションが同一のＨＳＢＳセッションに対応すると仮定するか、隣接するＢＳにハンドオフを実施するに伴い、ＭＳは、ＢＣＭＣＳ＿ＩＤを有するセッションと同等になるとしてＮＧＨＢＲ＿ＢＣＭＣＳ＿ＩＤを有するセッションを取り扱い、そしてハンドオフにわたって受信を継続し、
ＮＧＨＢＲ＿ＨＳＢＳ＿ＣＯＮＦＩＧ＝０１０であれば、ＭＳは、同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳにおいて使用されると仮定する、
　方法。
　
５．対比
　引用発明は「放送／マルチキャストサービスが利用できるための方法」であり、その「ＢＳＰＭ」は、「各隣接のセクタにおける放送サービスに関する情報を含んで構成され」とするものであるから、セル情報といえ、「ＭＳは、ハンドオフを決定するために現在のセクタのＢＳＰＭを調べ」とするので、本願発明とは、マルチキャスティング・コンテントを送信する無線送信器のセル情報を無線送信器のセルから受信するステップ、を有する点で共通するといえる。
　引用発明は「ＭＳがセクタＡからセクタＢへ移動する場合に」とあるように、ハンドオフを実施するものであるから、ハンドオフ先として「セクタ
Ｂ」を選択することは、明示的な記載はないが当然行っているはずである。
　したがって、本願発明と引用発明とを対比すると、次の点で一致する。
　
　マルチキャスティング・コンテントを送信する無線送信器のセル情報を無線送信器のセルから受信するステップと、
　マルチキャスティング・コンテントを受信するための無線送信器のセルを選択するステップと、を含む、
ことを特徴とする方法。」
　
　また次の点で相違する。
　
　相違点１
　本願発明は「セル情報」が「同一のマルチキャスティング・コンテントを送信する無線送信器のセルを示すセル情報」であり、「少なくとも２つの無線送信器のセルから受信する」とするのに対して、引用発明のセル情報である「ＢＳＰＭ」は、「各隣接のセクタにおける放送サービスに関する情報を含んで構成され」とするもので「どんな放送サービスが目的地のセクタで利用できるか、どんなＢＣＭＣＳ＿ＩＤが利用できるか、及び他の関連するパラメータを決定するためのもの」であり、「ＭＳは、ハンドオフを決定するために現在のセクタのＢＳＰＭを調べ」とあるように、少なくとも２つの無線送信器のセルから受信することの特定はない点。
　
　相違点２
　本願発明は「前記少なくとも２つの無線送信器のセルからの受信クオリ
ティを比較するステップ」を含み、「前記受信クオリティを比較するステップは、前記少なくとも２つの無線送信器のセルから受信したパイロット信号の強度及びエラーの少なさのうちの少なくとも１つを比較することを含む」とするのに対して、引用発明では受信クオリティに関する特定はない点。
　
　相違点３
　本願発明は「マルチキャスティング・コンテントを受信するための２以上の無線送信器のセルを前記受信クオリティ及び前記セル情報に基づいて選択するステップ」を含むのに対して、引用発明では選択を２以上とすること及び「前記受信クオリティ及び前記セル情報に基づいて選択する」とすることについての特定がない点。
　
６．相違点に対する判断
　相違点１について
　引用発明のセル情報である「ＢＳＰＭ」は、「各隣接のセクタにおける放送サービスに関する情報を含んで構成され」とするもので「どんな放送サービスが目的地のセクタで利用できるか、どんなＢＣＭＣＳ＿ＩＤが利用できるか、及び他の関連するパラメータを決定するためのもの」であるから、それを調べることにより、「各隣接のセクタ」で同一のマルチキャスティン
グ・コンテントが送信されているかどうか判明するが、同一のマルチキャスティング・コンテントを送信する無線送信器のセルを直接示すものではな
い。
　また、引用発明では、隣接のＢＳにおいてサービスが利用できることを示す「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」が‘００１／０１０’である場合だけでなく、未知であることを示す「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」の値が‘０００’である場合にも、「ＭＳは、ＨＳＢＳ受信を中止し、そして隣接するＢＳへアイドルハンドオフを実施して同一のＢＣＭＣＳ＿ＩＤを検索し」（ＢＣＭＣＳ＿ＩＤがグローバルに固有である場合）、または「ＭＳは、受信を中止して隣接するＢＳにアイドルハンドオフを実施して、その後、新しいセクタのＢＳＰＭを読み、同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳで見つけらるのであれば、ＭＳは、以前のＢＳ中と同一のＢＣＭＣＳ＿ＩＤを有するＨＳＢＳセッションに関係ないと仮定し」（ＢＣＭＣＳ＿ＩＤがローカルに固有である場合）と、「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」の値が‘０００’である場合にも、その隣接するＢＳへハンドオフを実施して、新しいセクタで処理を行うのであるから、引用発明の「ＢＳＰＭ」を、本願発明の「セル情報」のように「同一のマルチキャスティング・コンテントを送信する無線送信器のセルを示すセル情報」とすると、未知であることを示す「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」の値が‘０００’である場合は、その隣接するセルは「同一のマルチキャスティング・コンテントを送信する無線送信器のセル」とはいえないから、そのセルに関する情報が得られなくなるので、引用発明において、「ＢＳＰＭ」を、本願発明の「セル情報」のようにすることは、阻害要因があるといえる。
　
　相違点２について
　相違点１について判断したように、引用発明では本願発明のような「セル情報」を受信することはないから、「……セル情報を少なくとも２つの無線送信器のセルから受信する」とある「前記少なくとも２つの無線送信器のセル」はありえないから、引用発明において、相違点２を本願発明のようにすることできない。
　ただし、少なくとも２つの無線送信器のセルから受信したパイロット信号の強度及びエラーの少なさのうちの少なくとも１つを比較することで、受信クオリティを比較して、ハンドオフ先の無線送信器のセルを選択すること自体は周知のことであり、格別の点はない。
　
　相違点３について
　相違点１について判断したように、引用発明では本願発明のような「セル情報」を受信することはないから、引用発明において、本願発明のように
「…前記セル情報に基づいて選択する」ことはできない。
　仮に、セル情報の内容についての相違を考慮しないとしても、引用発明では、隣接のＢＳにおいてサービスが利用できることを示す「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」が‘００１／０１０’である場合だけでなく、未知であることを示す「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」の値が‘００
０’である場合にも、「ＭＳは、ＨＳＢＳ受信を中止し、そして隣接するＢＳへアイドルハンドオフを実施して同一のＢＣＭＣＳ＿ＩＤを検索し」（ＢＣＭＣＳ＿ＩＤがグローバルに固有である場合）、または「ＭＳは、受信を中止して隣接するＢＳにアイドルハンドオフを実施して、その後、新しいセクタのＢＳＰＭを読み、同一のＢＣＭＣＳ＿ＩＤが隣接するＢＳで見つけらるのであれば、ＭＳは、以前のＢＳ中と同一のＢＣＭＣＳ＿ＩＤを有するＨＳＢＳセッションに関係ないと仮定し」（ＢＣＭＣＳ＿ＩＤがローカルに固有である場合）と、するもので、「ＨＳＢＳ＿ＮＧＨＢＲ＿ＣＯＮＦＩＧ」の値に関わりなく隣接セルへハンドオフを実施するのであるから、セル情報に基づいてセルを選択することはない。
　また、２つの基地局を選択してダイバーシチ受信を行うことが周知のことであるとしても、セル情報に基づいてセルを選択することの理由とはなりえない。
　
　したがって、本願発明は、引用発明に基いて、当業者が容易に発明をすることができたとはいえない。
　また、他の請求項に係る発明についても、引用発明に基いて、当業者が容易に発明をすることができたとはいえない。
　
７．むすび
　以上のとおり、本願発明は、引用発明に基いて、当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。