【事件の表示】
　特願２０１３−５１５５８０「ホームＮｏｄｅＢのモビリティをサポートするための方法および装置」拒絶査定不服審判事件〔平成２３年１２月２２日国際公開、ＷＯ２０１１／１６０１２０、平成２５年　８月１５日国内公表、特表２０１３−５３２４４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，２０１１年６月２０日（パリ条約による優先権主張外国庁受理　２０１０年６月１８日　（ＵＳ）アメリカ合衆国，２０１０年８月２３日　（ＵＳ）アメリカ合衆国，２０１０年１０月１日　（ＵＳ）アメリカ合衆国，２０１０年１１月５日　（ＵＳ）アメリカ合衆国，２０１１年２月１１日　（ＵＳ）アメリカ合衆国，２０１１年４月２９日　（ＵＳ）アメリカ合衆国）を国際出願日とする出願であって，平成２６年１０月３０日付けで拒絶査定がなされ，これに対し，平成２７年３月１１日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
第２　補正却下の決定
［結論］
　平成２７年３月１１日付けの手続補正を却下する。
［理由］
１　本願発明と補正後の発明
　平成２７年３月１１日付けの手続補正（以下，「本件補正」という。）は，平成２６年４月１４日付け手続補正書により補正された特許請求の範囲の請求項１７に記載された
「【請求項１７】
　ホームＮｏｄｅＢ（ＨＮＢ）のモビリティをサポートするための方法であって，
　ソースＨＮＢが，無線送信／受信ユニット（ＷＴＲＵ）を前記ソースＨＮＢからターゲットＨＮＢにハンドオーバすることを判定するステップと，
　前記ソースＨＮＢが，アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップと，
　前記ソースＨＮＢが，前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップと
　を備えたことを特徴とする方法。」
という発明（以下，「本願発明」という。）を，
「【請求項１７】
　ホームＮｏｄｅＢ（ＨＮＢ）のモビリティをサポートするための方法であって，
　ソースＨＮＢが，無線送信／受信ユニット（ＷＴＲＵ）を前記ソースＨＮＢからターゲットＨＮＢにハンドオーバすることを判定するステップと，
　前記ソースＨＮＢが，アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップと，
　前記ソースＨＮＢが，前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップと，
　前記ソースＨＮＢが，適切な要因値とともにリロケーションの成功を示す登録解除メッセージを受信するステップと
　を備えたことを特徴とする方法。」
という発明（以下，「補正後の発明」という。）に変更することを含むものである。
２　補正の適否
（１）新規事項の有無，シフト補正の有無，補正の目的要件
　本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内において，補正前の特許請求の範囲の請求項１７に記載された発明に「前記ソースＨＮＢが，適切な要因値とともにリロケーションの成功を示す登録解除メッセージを受信するステップ」なる新たな構成を付加するものであって，特許法第１７条の２第３項（新規事項）及び第４項（シフト補正）の規定に適合する。
　しかしながら，上記補正は，補正前の特許請求の範囲の請求項１７に記載された発明に新たな構成を付加するものであるから，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当しない。また，上記補正の目的は，特許法第１７条の２第５項各号に掲げる他のいずれの事項を目的とするものにも該当しない。
　よって，本件補正は，特許法第１７条の２第５項各号に掲げるいずれの事項をも目的とするものではない。
　したがって，本件補正は，特許法第１７条の２第３項及び同第４項の規定には適合するものの，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
（２）独立特許要件について
　上記（１）のとおりであるが，更に進めて，仮に上記補正の目的が特許請求の範囲の減縮に該当するとした場合について，独立特許要件を満たしているか否かについて検討する。
ア　補正後の発明
　上記「１　本願発明と補正後の発明」の項にて「補正後の発明」とした，以下のとおりのものと認める。
「【請求項１７】
　ホームＮｏｄｅＢ（ＨＮＢ）のモビリティをサポートするための方法であって，
　ソースＨＮＢが，無線送信／受信ユニット（ＷＴＲＵ）を前記ソースＨＮＢからターゲットＨＮＢにハンドオーバすることを判定するステップと，
　前記ソースＨＮＢが，アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップと，
　前記ソースＨＮＢが，前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップと，
　前記ソースＨＮＢが，適切な要因値とともにリロケーションの成功を示す登録解除メッセージを受信するステップと
　を備えたことを特徴とする方法。」
イ　引用発明及び技術常識
［引用発明１］
　原査定の拒絶の理由に引用された「Kineto Wireless Inc.，GW Terminated HO Signaling（［当審仮訳］：ＧＷ（ゲートウェイ）で終端されるＨＯ（ハンドオーバ）シグナリング）[online]，3GPP TSG-RAN WG3 Meeting #64 R3-091179，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_64/Docs/R3-091179.zip＞，２００９年５月８日」（以下，「引用例１」という。）には，図面とともに以下の事項が記載されている。
（ア）「2.2.1　Connected mode mobility from one HNB to another HNB (Intra HNB-GW)
1. The UE has established an active CS/PS session to the CN via the source HNB and HNB-GW.
2. At some point, the source HNB makes a decision to relocate the UE session (e.g. based on the Measurement Reports from the UE or any other implementation specific reason at the source HNB). 
3. The source HNB triggers a relocation of the UE session by sending the RANAP Relocation Required message encapsulated in the RUA Direct Transfer message. The target RNC-Id and target Cell-Identity information along with relocation information is included by the source HNB in the RANAP Relocation Required message.
4. The HNB-GW determines that this is an inter-HNB relocation request since the target RNC-Id is the RNC-Id of the HNB-GW. The HNB-GW then verifies that the target HNB (based on the target Cell Identity) is also registered within the HNB-GW. The HNB-GW also performs access control for that particular UE. The access control can be based on the following logic:
　・If the UE and HNBs are CSG capable, then HNB-GW ensures the CSG identity of the source HNB and target HNB is the same (intra CSG)
　・If the UE is not CSG capable (e.g. pre-release 8 UE), then the HNB-GW anyway has the information to perform the mandatory access control.
5. The HNB-GW then constructs the appropriate RANAP Relocation Request message and routes the RANAP message encapsulated in the RUA Direct Transfer message to the target HNB. 
6. The target HNB performs an implicit registration for the incoming UE session (see [3] for details and possible mechanisms on network triggered UE registration) and also allocated the appropriate resource for handling the relocation. 
7. The target HNB acknowledges successful resource allocation to the HNB-GW via an appropriately constructed RANAP Relocation Request Ack message encapsulated in the RUA Direct Transfer message to the HNB-GW.
8. The HNB-GW constructs the appropriate RANAP Relocation Command message and routes the RANAP message encapsulated in the RUA Direct Transfer message to the source HNB.
9-13. the rest of the relocation procedure continues as shown in the corresponding steps in the above figure.
14. The HNB-GW upon getting an indication that the UE has been successfully relocated to the target HNB deregisters the UE from the source HNB. The source HNB releases the resources assigned to the UE and deletes all stored context information associated with the UE」（２〜３ページ）
（［当審仮訳］：
２．２．１　あるＨＮＢから別のＨＮＢへの接続モードモビリティ（ＨＮＢ−ＧＷ内）
（図２は省略）
図２　ＨＮＢ間のＨＮＢ−ＧＷ内接続モードモビリティ
１．ＵＥは，ソースＨＮＢとＨＮＢ−ＧＷを経由して，ＣＮへのアクティブなＣＳ／ＰＳセッションを確立している。
２．ある時点で，ソースＨＮＢはＵＥセッションのリロケーションを決定する（例えば，ＵＥからの測定報告又はソースＨＮＢにおける実装に特有なその他の理由に基づく）。
３．ソースＨＮＢはＲＵＡ直接転送メッセージ内にカプセル化されたＲＡＮＡＰリロケーション要請メッセージを送信することにより，ＵＥセッションのリロケーションをトリガする。リロケーション情報に加えてターゲットＲＮＣ−Ｉｄ及びターゲットセル識別子情報が，ソースＨＮＢにより，ＲＡＮＡＰリロケーション要請メッセージに含められる。
４．ＨＮＢ−ＧＷは，ターゲットＲＮＣ−Ｉｄが前記ＨＮＢ−ＧＷのＲＮＣ−Ｉｄであるため，これがＨＮＢ間のリロケーション要求であることを決定する。その後，ＨＮＢ−ＧＷは，ターゲットＨＮＢも（ターゲットセル識別子に基づいて）前記ＨＮＢ−ＧＷに登録されていることを確認する。ＨＮＢ−ＧＷはその特定のＵＥのためのアクセス制御も実行する。アクセス制御は次の論理に基づくことができる：
　・もし前記ＵＥとＨＮＢ（複数）がＣＳＧ能力ありの場合，ＨＮＢ−ＧＷはソースＨＮＢとターゲットＨＮＢのＣＳＧ識別子が同一であることを保証する（ＣＳＧ内）。
　・もしＵＥがＣＳＧ能力ありではない場合（例えばリリース８より前のＵＥ），いずれにせよＨＮＢ−ＧＷは義務的なアクセス制御を実行するための情報を有している。
５．ＨＮＢ−ＧＷは，その後，適切なＲＡＮＡＰリロケーション要求メッセージを構築し，ＲＵＡ直接転送メッセージ内にカプセル化された前記ＲＡＮＡＰメッセージをターゲットＨＮＢへルーティングする。
６．ターゲットＨＮＢは到来するＵＥセッションの暗示的な登録を実行し（詳細及びネットワークによりトリガされるＵＥ登録における可能なメカニズムは［３］参照），リロケーションを扱うための適切なリソースも割り当てられる。
７．ターゲットＨＮＢは，ＨＮＢ−ＧＷに対し，ＨＮＢ−ＧＷに対するＲＵＡ直接転送メッセージ内にカプセル化され適切に構築されたＲＡＮＡＰリロケーション要求確認応答メッセージを介して，リソース割当ての成功を確認応答する。
８．ＨＮＢ−ＧＷは，適切なＲＡＮＡＰリロケーション命令メッセージを構築し，ＲＵＡ直接転送メッセージ内にカプセル化された前記ＲＡＮＡＰメッセージをソースＨＮＢへルーティングする。
９−１３．残りのリロケーション手順が上記の図に示されるように，対応する手順において継続される。
１４．ＨＮＢ−ＧＷは，ＵＥがターゲットＨＮＢに成功裏にリロケーションしたことの表示を得ると，ソースＨＮＢから前記ＵＥの登録を解除する。ソースＨＮＢは前記ＵＥに割り当てられたリソースを解放し，前記ＵＥに関連付けられた，記憶しているすべてのコンテキスト情報を削除する）
（イ）「2.2.2　Connected mode mobility from one HNB to another HNB (Intra HNB-GW and Inter CSG)
It needs to be further determined whether connected mode mobility from one HNB to another HNB with inter CSG scenarios need to be supported in release 9 timeframe. The following possibilities exist for handling such a scenario of intra HNB-GW and inter CSG (i.e. source and target HNB have different CSG identities)
1. If it is determined that such scenarios do not need to be supported in release 9 timeframe, then it essentially implies that connected mode inter HNB mobility with inter CSG should not be allowed. This check (i.e. inter CSG) can be performed (for e.g.) by the HNB-GW in step 4 of the scenario described in section 2.2.1 and upon determination of inter CSG mobility, the HNB-GW can reject the incoming relocation request from the source HNB using the appropriate RANAP failure message (e.g. via new cause code indicating that inter CSG is not allowed).
2. If it is determined that intra HNB-GW inter CSG should be supported in release 9 timeframe, one of the following options can be utilized at the HNB-GW to determine eligibility of the target HNB as potential relocation target based on the CSG identity of the target HNB:
a. Introduce new RANAP messages (e.g. RANAP Allowed CSG List Request and Allowed CSG List Response) to retrieve from the CN the allowed CSG list for that particular UE. The HNB-GW can then use the new RANAP procedures to retrieve the CSG list and perform the access control for that particular UE and make a determination to proceed with the relocation (step 4 in section 2.2.1)
（以下略）」（３ページ）
（［当審仮訳］：
２．２．２　あるＨＮＢから別のＨＮＢへの接続モードモビリティ（ＨＮＢ−ＧＷ内及びＣＳＧ間）
ＣＳＧ間シナリオにおけるあるＨＮＢから別のＨＮＢへの接続モードモビリティが，リリース９タイムフレームにおいてサポートされる必要があるか否かについて，更に決定される必要がある。そのようなＨＮＢ−ＧＷ内及びＣＳＧ間（すなわちソースとターゲットＨＮＢが異なるＣＳＧ識別子を有する）のシナリオのために次の可能性が存在する。
１．もしそのようなシナリオがリリース９タイムフレームにおいてサポートされる必要がないと決定されるなら，ＣＳＧ間の接続モードＨＮＢ間モビリティが許可されないことを本質的に暗示する。このチェック（すなわちＣＳＧ間）は，（例えば）ＨＮＢ−ＧＷにより２．２．１節で述べたシナリオのステップ４で実行され得，ＣＳＧ間モビリティの決定により，ＨＮＢ−ＧＷは，適切なＲＡＮＡＰ失敗メッセージを用いて，ソースＨＮＢから到来リロケーション要求を拒否することができる（例えば，ＣＳＧ間が許可されないことを表示する新しい要因コードを介して）。
２．もしＨＮＢ−ＧＷ内ＣＳＧ間がリリース９タイムフレームにおいてサポートされるべきであると決定されるなら，次のうち１つオプションが，ターゲットＨＮＢの潜在的なリロケーションターゲットとしての適格性をターゲットＨＮＢのＣＳＧ識別子に基づいて決定するために，ＨＮＢ−ＧＷにおいて利用され得る：
ａ．その特定のＵＥのための許可ＣＳＧリストをＣＮから取得するための新しいＲＡＮＡＰメッセージの導入（例えば，ＲＡＮＡＰ許可ＣＳＧリスト要求及び許可ＣＳＧリスト応答）。ＨＮＢ−ＧＷはＣＳＧリストを取得しその特定のＵＥのためのアクセス制御を実施するために新しいＲＡＮＡＰ手順を利用し，リロケーションを進めることを決定を行う（２．２．１節のステップ４）
（以下略））
　上記（ア）の記載及び図面（特に図２）並びにこの分野における技術常識を考慮すると，
ａ　上記（ア）及び図２から，引用例１には，ＵＥが接続するＨＮＢをソースＨＮＢからターゲットＨＮＢに移動することを可能にするための方法，すなわち「ＨＮＢのモビリティをサポートするための方法」が記載されていると認められる。
ｂ　上記（ア）の１．及び図２の「2.Decision to relocate the UE to Target HNB（［当審仮訳］：ＵＥのターゲットＨＮＢへのリロケーションの決定）」から，ソースＨＮＢが，ＵＥを前記ソースＨＮＢからターゲットＨＮＢへリロケーションすることを決定している。
　したがって，引用例１には，「ソースＨＮＢが，ＵＥを前記ソースＨＮＢからターゲットＨＮＢへリロケーションすることを決定する」ことが記載されていると認められる。
ｃ　上記（ア）の４．並びに上記（イ）の２．及びａ．から，ＨＮＢ−ＧＷは，特定のＵＥのための許可ＣＳＧリストをＣＮから取得してアクセス制御を実行することにより，ターゲットＨＮＢがその特定のＵＥにとって潜在的なリロケーションターゲットとして適格であるかどうかを決定し，適格な場合にはリロケーションを進めている。ここで，「ターゲットＨＮＢがその特定のＵＥにとって潜在的なリロケーションターゲットとして適格であるかどうか」は，当該特定のＵＥのための「許可ＣＳＧリスト」を用いて決定され，該ＣＳＧがClosed Subscriber Groupの略であって，ＨＮＢへのアクセスを許可されたグループを意味することは技術常識であることから，「その特定のＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されるかどうか」であることは明らかである。
　また，（ア）の４．及び５．並びに図２から，アクセス制御のあとにＨＮＢ−ＧＷが行うリロケーションの手順とは，ＲＡＮＡＰリロケーション要求メッセージをターゲットＨＮＢへ送信することである。
　したがって，引用例１には，「ＨＮＢ−ＧＷが，アクセス制御を実行して，前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されるかどうかを決定する」こと，及び「ＨＮＢ−ＧＷが，前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されると決定すると，ＲＡＮＡＰリロケーション要求メッセージをターゲットＨＮＢへ送信する」こと，が記載されていると認められる。
ｄ　上記（ア）の１４．及び図２から，ＨＮＢ−ＧＷが，ＵＥがターゲットＨＮＢに成功裏にリロケーションしたことの表示を得ると，ソースＨＮＢから前記ＵＥの登録を解除するために，ソースＨＮＢに対して，HNBAP UE DE-REGISTERメッセージ（［当審仮訳］：ＨＮＢＡＰ　ＵＥ登録解除メッセージ）を送信している。
　したがって，引用例１には，「前記ソースＨＮＢが，ＨＮＢＡＰ　ＵＥ登録解除メッセージを受信する」ことが記載されていると認められる。
　以上を総合し，各処理を「ステップ」で表現すると，引用例１には以下の発明（以下，「引用発明１」という。）が記載されていると認める。
「　ＨＮＢのモビリティをサポートするための方法であって，
　ソースＨＮＢが，ＵＥを前記ソースＨＮＢからターゲットＨＮＢへリロケーションすることを決定するステップと，
　ＨＮＢ−ＧＷが，アクセス制御を実行して，前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されるかどうかを決定するステップと，
　ＨＮＢ−ＧＷが，前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されると決定すると，ＲＡＮＡＰリロケーション要求メッセージをターゲットＨＮＢへ送信するステップと，
　前記ソースＨＮＢが，ＨＮＢＡＰ　ＵＥ登録解除メッセージを受信するステップと
　を備えたことを特徴とする方法。」
［引用発明２］
　原査定の拒絶の理由に引用された「Panasonic，UE access control in CSG cell（［当審仮訳］：ＣＳＧセル内のＵＥアクセス制御）[online]，3GPP TSG RAN WG2 #62 R2-082238，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_62/Docs/R2-082238.zip＞，２００８年５月９日」（以下，「引用例２」という。）には，図面とともに以下の事項が記載されている。
（ウ）「2.1.　Access check initiation by source cell (macro cell)
In this subsection, the access check initiation by source cell is discussed. In this procedure, the source cell checks UE accessibility and transmits HO request to only accessible CSG cell. Source cell needs to have 2 kinds of information in order to check UE accessibility of CSG cell.
　・Whitelist (i.e. tracking area code(TA ID) list) for each UE in order to know UE accessibility
　・Mapping information between GCI (or/and L1 cell ID) and TA ID in order to know TA ID of neighbour cell from UE's reported GCI(or L1 cell ID)
The procedures are slightly different depending on whether mapping information is based on GCI, or L1 cell ID. Therefore, we discuss two procedures separately. Firstly, we discuss the case that GCI is used as baseline procedure. The procedure is illustrated in Figure 1.
　Step1. Source cell obtains the whitelist for each UE from MME in advance.
　Step2. UE sends measurement report including only L1 cell ID. If network signalling is required to read GCI from CSG cell (e.g. gap configuration/activation), source cell triggers the procedure, when UE reports L1 cell ID for CSG cell in measurement report. In case UE can autonomously reads GCI from CSG cell, source cell does not need to have this procedure.
　Step3. UE obtains GCI from the CSG cell.
　Step4. UE sends measurement report with GCI in addition to L1 cell ID.
　Step5. Source cell checks UE accessibility by using measurement report with GCI from UE and the whitelist from MME. If source cell considers that the cell is an accessible CSG cell and the cell is good radio condition from mobility perspective, source cell send Handover Request to MME via S1 interface.
　Step6. MME receives Handover Request from Source cell, and forwards the message to Target CSG cell.
　Step7. Target cell receives HO request and transmits HO response to source cell after judgement of HO possibility.
　Step8. Source cell transmits HO commands including HO response from CSG cell to UE. 
　Step9. UE executes handover as normal handover. 
In this procedure, MME sends whitelist to source cell and source cell keeps the whitelist in order to UE accessibility check. Therefore, drawback is the additional signalling between MME and eNB for call setup and signalling between eNBs for mobility procedure. In addition, source cell needs to manage whitelist for each UE. 
Possible benefit would be that eNB can judge gap configuration necessity based on stored UE accessibility list. Therefore, the need of gap is reduced.
（以下略）」（１〜２ページ）
（［当審仮訳］：
２．１．　ソースセル（マクロセル）によるアクセスチェックの開始
この節では，ソースセルによるアクセスチェックの開始が検討される。この手順において，ソースセルはＵＥのアクセス可能性をチェックし，ＨＯ（ハンドオーバ）要求をアクセス可能なＣＳＧセルにのみ送信する。ソースセルは，ＣＳＧセルのＵＥのアクセス可能性をチェックするために，２種類の情報を必要とする。
　・ＵＥのアクセス可能性を認識するための，各ＵＥのためのホワイトリスト（すなわちトラッキングエリアコード（ＴＡ　ＩＤ）リスト）
　・ＵＥのレポートされたＧＣＩ（又はＬ１セルＩＤ）から近隣セルのＴＡ　ＩＤを認識するための，ＧＣＩ（又は／及びＬ１セルＩＤ）とＴＡ　ＩＤとの間のマッピング情報
この手順はマッピング情報がＧＣＩ又はＬ１セルＩＤのどちらに基づくかに依存してわずかに異なる。ゆえに，２つの手順を分けて検討する。最初に，基本となる手順として，ＧＣＩが用いられるケースを検討する。この手順は図１に示されている。
　ステップ１．ソースセルは事前に各ＵＥのためのホワイトリストをＭＭＥから取得する。
　ステップ２．ＵＥはＬ１セルＩＤのみを含む測定報告を送信する。もしＧＣＩを読むためにＣＳＧセルからのネットワークシグナリング（例えばギャップ設定／アクティブ化）が必要ならば，ＵＥがＣＳＧセルのＬ１セルＩＤを測定報告内で報告するとき，ソースセルはその手順をトリガする。ＵＥがＣＳＧセルからＧＣＩを自律的に読むことができる場合は，ソースセルはこの手順を行う必要がない。
　ステップ３．ＵＥはＣＳＧセルからＧＣＩを取得する。
　ステップ４．ＵＥはＬ１セルＩＤに加えてＧＣＩを含む測定報告を送信する。
　ステップ５．ソースセルは，ＵＥからのＧＣＩを含む測定報告及びＭＭＥからのホワイトリストを用いて，ＵＥのアクセス可能性をチェックする。もしソースセルが，セルがアクセス可能なＣＳＧセルでかつそのセルが移動性の見通しから無線条件が良いとみなすならば，ソースセルはＳ１インターフェースを介してＭＭＥにハンドオーバ要求を送信する。
　ステップ６．ＭＭＥはソースセルからハンドオーバ要求を受信し，そのメッセージをターゲットＣＳＧセルに転送する。
　ステップ７．ターゲットセルはＨＯ（ハンドオーバ）要求を受信し，ＨＯ可能性の判定の後，ＨＯ応答をソースセルに送信する。
　ステップ８．ソースセルはＣＳＧセルからのＨＯ応答を含むＨＯ命令をＵＥに送信する。
　ステップ９．ＵＥは通常のハンドオーバとしてハンドオーバを実行する。
この手順において，ＭＭＥはホワイトリストをソースセルに送信し，ソースセルはＵＥのアクセス可能性チェックのためにそのホワイトリストを保存する。ゆえに，短所はＭＭＥとｅＮＢとの間の呼設定のための追加的なシグナリング及びｅＮＢ間のモビリティ手順のためのシグナリングである。加えて，ソースセルは各ＵＥのホワイトリストを管理する必要がある。
可能性のある長所は，ｅＮＢが記録されたＵＥのアクセス可能性リストに基づいて，ギャップ設定の必要性を判定できることである。ゆえに，ギャップの必要性は低減される。
（図１は省略）
図１　ＧＣＩとＴＡ　ＩＤとの間のマッピングを用いたソースセルによるアクセスチェックの開始（検出されたセルがアクセス可能なＣＳＧセルのケース）
（以下略））
　上記引用例２の記載及び図面並びにこの分野における技術常識を考慮すると，
ｅ　上記（ウ）の「ソースセルはＵＥのアクセス可能性をチェックし，ＨＯ（ハンドオーバ）要求をアクセス可能なＣＳＧセルにのみ送信する。」及びステップ５の記載から，ソースセルが，測定報告に含まれる近隣セルすなわちターゲットセルに対するＵＥのアクセス可能性をチェックし，当該ターゲットセルがアクセス可能なＣＳＧセルである場合にハンドオーバ要求を送信している。
　したがって，引用例２には，「ソースセルが，ターゲットセルに対するＵＥのアクセス可能性のチェックを実行して，ソースセルが，ＵＥが，前記ターゲットセルにアクセス可能であると確認すると，ハンドオーバ要求を送信する」ことが記載されていると認められる。
　したがって，引用例２には，ハンドオーバ時のターゲットセルに対するアクセス制御に関する以下の発明（以下，「引用発明２」という。）が記載されているものと認める。  
「ソースセルが，アクセス可能性のチェックを実行して，ソースセルが，ハンドオーバ要求を送信すること。」
［技術常識］
　本件の優先権主張の日前に電気通信回線を通じて公衆に利用可能となった「UTRAN Iuh interface Home Node B Application Part (HNBAP) signalling (Release 9)（［当審仮訳］：ＵＴＲＡＮ　ＩｕｈインターフェースホームノードＢアプリケーションパート（ＨＮＢＡＰ）シグナリング（リリース９））[online]，3GPP TS 25.469 V9.0.0 (2009-12)，インターネット＜URL:http://www.3gpp.org/ftp/Specs/archive/25_series/25.469/25469-900.zip＞，２００９年１２月１８日」には，図面とともに以下の事項が記載されている。
（エ）「8.5.3　Successful Operation (HNB-GW Originated)
The HNB-GW shall initiate the procedure by sending a UE DE-REGISTER message. When receiving the UE DE-REGISTER message the HNB shall release the included Context-ID.
Typical Cause values:
Radio Network Layer Cause:
　-　UE Registered in another HNB
　-　Unspecified
　-　UE not allowed on this HNB」（１５ページ）
（［当審仮訳］：
８．５．３　成功裏の操作（ＨＮＢ−ＧＷによる開始）
（図８は省略）
図８　ＵＥ登録解除手順：ＨＮＢ−ＧＷにより開始された成功裏の操作
ＨＮＢ−ＧＷはＵＥ登録解除メッセージを送信することによりこの手順を開始する。ＵＥ登録解除メッセージを受信したとき，ＨＮＢは含まれたコンテキストＩＤを解放する。
典型的な要因値：
無線ネットワークレイヤ要因：
　−ＵＥが他のＨＮＢに登録された
　−特定されていない
　−ＵＥがこのＨＮＢにおいて許可されない）
　（エ）の記載及び図面並びに当業者の技術常識を考慮すると，ＵＥ登録解除時に，「ＨＮＢが，『ＵＥが他のＨＮＢに登録された』，『特定されていない』，又は『ＵＥがこのＨＮＢにおいて許可されない』のいずれかを示す要因値を含むＵＥ登録解除メッセージを受信すること。」は，３ＧＰＰの仕様において定義されている事項であり，仕様は多数の提案に基づいて規定され，規定された仕様に対応するように技術開発がなされることに鑑みれば，当該事項は技術常識（以下，「技術常識１」という。）であると認める。
ウ　対比・判断
　補正後の発明と引用発明１とを対比すると，
（ア）補正後の発明と引用発明１とは，「ホームＮｏｄｅＢ（ＨＮＢ）のモビリティをサポートするための方法」である点で共通する。
（イ）本願明細書の【００１０】の「たとえばＷＴＲＵ１０２ａ，１０２ｂ，１０２ｃおよび１０２ｄは，無線信号を送信および／または受信するように構成することができ，ユーザ機器（ＵＥ），移動局，固定式または移動式のサブスクライバーユニット，ページャー，携帯電話，ＰＤＡ（personal digital assistant），スマートフォン，ラップトップ，ネットブック，パーソナルコンピュータ，無線センサ，家庭用電化製品などを含むことができる。」なる記載から明らかなように，補正後の発明の「無線送信／受信ユニット（ＷＴＲＵ）」は，引用発明１の「ＵＥ」を含んでいる。また，本願明細書の【００３８】の「図３は，ＷＴＲＵのためのＨＮＢからＨＮＢへのハンドオーバ（すなわち，リロケーション）に関する例示的な信号伝達図である。」なる記載から，補正後の発明の「ハンドオーバ」は，引用発明１の「リロケーション」に対応する。さらに，補正後の発明の「判定」と引用発明１の「決定」とは，表現が異なるのみであって，実質的に同義である。
　したがって，補正後の発明の「ソースＨＮＢが，無線送信／受信ユニット（ＷＴＲＵ）を前記ソースＨＮＢからターゲットＨＮＢにハンドオーバすることを判定するステップ」は，引用発明１の「ソースＨＮＢが，ＵＥを前記ソースＨＮＢからターゲットＨＮＢへリロケーションすることを決定するステップ」を含んでいる。
（ウ）補正後の発明の「アクセス制御またはメンバーシップ確認を実行して」は，引用発明１の「アクセス制御を実行して」を含んでいる。また，引用発明１における「通信」が，ターゲットｅＮＢを介して提供される「サービス」であることは明らかであるから，補正後の発明の「前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるか」は，引用発明１の「前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されるかどうか」を含んでいる。
　したがって，補正後の発明と引用発明１とは，ステップの実行の主体がソースＨＮＢであるか否かは別として，「アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップ」の点で共通している。
（エ）上記（ウ）で述べたとおりであるから，補正後の発明の「前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定する」は，引用発明１の「前記ＵＥが，ターゲットＨＮＢに接続して通信を行うことを許可されると決定する」を含んでいる。また，引用発明１の「ＲＡＮＡＰリロケーション要求メッセージ」は，補正後の発明の「リロケーション要求」に含まれる。
　したがって，補正後の発明と引用発明１とは，ステップの実行の主体がソースＨＮＢであるか否かは別として，「前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップ」の点で共通している。
（オ）補正後の発明の「登録解除メッセージ」は，引用発明１の「ＨＮＢＡＰ　ＵＥ登録解除メッセージ」を含んでいる。
　したがって，補正後の発明と引用発明１とは，登録解除メッセージが「適切な要因値とともにリロケーションの成功を示す」ことが明らかであるか否かは別として，「前記ソースＨＮＢが，登録解除メッセージを受信するステップ」の点で共通している。
　以上を総合すると，補正後の発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「　ホームＮｏｄｅＢ（ＨＮＢ）のモビリティをサポートするための方法であって，
　ソースＨＮＢが，無線送信／受信ユニット（ＷＴＲＵ）を前記ソースＨＮＢからターゲットＨＮＢにハンドオーバすることを判定するステップと，
　アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップと，
　前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップと，
　前記ソースＨＮＢが，登録解除メッセージを受信するステップと
　を備えたことを特徴とする方法。」
（相違点１）
　一致点の「アクセス制御またはメンバーシップ確認を実行して，前記ＷＴＲＵが，前記ターゲットＨＮＢを介して提供されるサービスを受けることを許可されるかを判定するステップ」の実行の主体に関し，補正後の発明は，「ソースＨＮＢ」であるのに対し，引用発明１は，「ＨＮＢ−ＧＷ」である点。
（相違点２）
　一致点の「前記ＷＴＲＵが，前記ターゲットＨＮＢを介したサービスを受けることを許可されると判定すると，リロケーション要求を前記ターゲットＨＮＢへ送信するステップ」の実行の主体に関し，補正後の発明は，「ソースＨＮＢ」であるのに対し，引用発明１は，「ＨＮＢ−ＧＷ」である点。
（相違点３）
　一致点の「登録解除メッセージ」に関し，補正後の発明は，「適切な要因値とともにリロケーションの成功を示す」ものであるのに対し，引用発明１は当該構成が明らかではない点。
　以下，上記各相違点について検討する。
（相違点１及び２について）
　引用発明１は，ＵＥをハンドオーバさせる際のターゲットＨＮＢに対するアクセス制御に関するものであるが，ハンドオーバ時のターゲットセルに対するアクセス制御の方法として，上記「イ　引用発明及び技術常識」の項で「引用発明２」として認定したとおり，「ソースセルが，ターゲットセルに対するＵＥのアクセス可能性のチェックを実行して，ソースセルが，ＵＥが，前記ターゲットセルにアクセス可能であると確認すると，ハンドオーバ要求を送信すること。」が公知である。引用例１，２の摘記事項を参酌すれば，両発明は，ＵＥをハンドオーバさせる際のターゲットＨＮＢ（ＣＳＧセル）に対するアクセス制御に関するものである点で共通しており，引用発明１におけるアクセス制御の実行の主体として，引用発明２を適用して，補正後の発明のように，「ソースＨＮＢ」が行うようにすることは，当業者が容易になし得たことである。
　また，アクセス制御の結果に基づいて送信されるリロケーション要求の送信を，「ソースＨＮＢ」が行うようにすることも，アクセス制御の実行の主体を「ソースＨＮＢ」とすることにともなって自ずと導き出せる事項にすぎない。
　したがって，上記相違点１及び２は格別困難なことではなく，当業者が容易になし得ることにすぎない。
（相違点３について）
　上記「イ　引用発明及び技術常識」の［技術常識］の項で示したとおり，ＵＥ登録解除時に，「ＨＮＢが，『ＵＥが他のＨＮＢに登録された』，『特定されていない』，又は『ＵＥがこのＨＮＢにおいて許可されない』のいずれかを示す要因値を含むＵＥ登録解除メッセージを受信すること。」（技術常識１）は，技術常識である。そして，引用発明１においてソースＨＮＢが受信する「ＵＥ登録解除メッセージ」は，引用例１の図２のステップ１３の記載から，ＨＮＢ−ＧＷが「RANAP Relocation Complete」（［当審仮訳］：ＲＡＮＡＰ　リロケーション完了）を示すメッセージを受信した後，すなわちリロケーションが完了した後にソースＨＮＢに送信されていることから，引用発明１において，ＵＥ登録解除メッセージに，リロケーションの成功を意味する「ＵＥが他のＨＮＢに登録された」を示す要因値を含めるよう構成することに格別の困難はなく，そのような要因値を「適切な要因値」と称することは任意である。
　したがって，上記相違点３は格別困難なことではなく，当業者が容易になし得ることにすぎない。
　そして，補正後の発明の作用効果も，引用発明１及び引用発明２並びに技術常識に基づいて当業者が予測できる範囲のものである。
エ　むすび
　以上のとおり，補正後の発明は，引用発明１及び引用発明２並びに技術常識に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　したがって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
３　結語
　以上のとおり，本件補正は，特許法第１７条の２第５項の規定に違反し，また同第６項において準用する同法第１２６条第７項の規定にも違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成２７年３月１１日付けの手続補正は上記のとおり却下されたので，本願発明は，上記「第２　補正却下の決定」の項中の「１　本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。
２　引用発明及び技術常識
　引用発明及び技術常識は，上記「第２　補正却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件について」の項中の「イ　引用発明及び技術常識」の項で認定したとおりである。
３　対比・判断
　そこで，本願発明と引用発明とを対比するに，本願発明は補正後の発明から当該補正において新たに付加された構成を省いたものである。
　そうすると，本願発明の構成に当該補正に係る新たに付加された構成を付加した補正後の発明が，上記「第２　補正却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件について」の項中の「ウ　対比・判断」の項で検討したとおり，引用発明１及び引用発明２並びに技術常識に基づいて容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
４　むすび
　以上のとおり，本願発明は，引用発明１及び引用発明２並びに技術常識に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。