【事件の表示】
　特願２０１２−５５４１９７「端末測定データを収集するための方法およびシステム」拒絶査定不服審判事件〔平成２３年　８月２５日国際公開，ＷＯ２０１１／１００８８４，平成２５年　６月　６日国内公表，特表２０１３−５２０８８６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２０１０年１２月１６日（パリ条約による優先権主張外国庁受理　２０１０年２月２２日　中国）を国際出願日とする出願であって，平成２６年７月２２日に最後の拒絶理由が通知され，平成２７年１月２９日付けで手続補正がなされたが，同年６月２９日付けで補正の却下の決定がされるとともに同日付けで拒絶査定がされ，これに対し，同年１１月９日に拒絶査定不服審判が請求されるとともに同日付けで手続補正がなされたものである。その後，審査官が平成２８年１月２７日付けで作成した前置報告書に対して，同年５月９日付けで上申書が提出された。
第２　補正の却下の決定
［結論］
　平成２７年１１月９日付けの手続補正を却下する。
　
［理由］
１　本願発明と補正後の発明
　平成２７年１１月９日付けの手続補正（以下，「本件補正」という。）は，平成２６年２月２１日付け手続補正書により補正された特許請求の範囲の請求項４０に記載された
「【請求項４０】
　端末測定データ収集するために使用される構成パラメータ，またはノードBによって送信された端末測定停止インジケータを受信して，端末測定データ報告を前記ノードBに送信するように構成されたトランシーバであって，前記構成パラメータがドライブテストの最小化(MDT)コンフィギュレーションである，トランシーバと，
　端末測定データを収集するために使用される前記構成パラメータによって端末測定データを測定するように，または前記端末測定停止インジケータによって前記端末測定データの測定を終了するように構成された測定ユニットとを備える，ユーザ装置。」
という発明（以下，「本願発明」という。）を，
「【請求項３２】
　
eノードBによって送信された
タを
e
　端末測定データを収集するために使用される前記構成パラメータによって端末測定データを測定するよう
に構
，
　端末測定データを収集するために使用される前記構成パラメータが，
　端末測定データインジケータ，報告されたUE測定情報，端末測定データ収集の範囲リスト，端末測定データ収集の優先順位，およびターゲットユーザアイデンティティ(IMSI, IMEI)またはターゲットユーザアイデンティティのリストのパラメータのうちの任意の組合せのうちのいずれか1つを備える
という発明（以下，「補正後の発明」という。）に変更することを含むものである。
２　補正の適否
（１）新規事項の有無，シフト補正の有無，補正の目的要件
　請求項４０についての上記補正は，(i) 本願発明の「端末測定データ収集するために使用される構成パラメータ」について，「eノードBによって送信された」との限定を付し，(ii)本願発明の択一的な選択肢の他方であった「またはノードBによって送信された端末測定停止インジケータ」の受信を削除し，これに伴い，「測定ユニット」の構成から「または前記端末測定停止インジケータによって前記端末測定データの測定を終了する」事項を削除し，(iii) 本願発明の「端末測定データを収集するために使用される前記構成パラメータ」について，「端末測定データインジケータ，報告されたUE測定情報，端末測定データ収集の範囲リスト，端末測定データ収集の優先順位，およびターゲットユーザアイデンティティ(IMSI, IMEI)またはターゲットユーザアイデンティティのリストのパラメータのうちの任意の組合せのうちのいずれか1つを備える」との限定を付すものである。
　したがって，上記補正は，全体として，特許請求の範囲を減縮するものである。
　独立請求項である請求項１，２６，３０，３１，３４，３７，３８についての補正も，基本的に上記(i)〜(iii) の補正と同様の内容であり，ただし，上記(i) の点は，ネットワークアーキテクチャ上の位置により，それぞれの送信元等が限定されている。
　請求項４，５，３２についての補正も，上記(ii)の補正と同様の内容である。
　請求項２７，２９についての補正も，上記(i) ，(ii)の補正と同様の内容であり，ただし，上記(i) の点は，ネットワークアーキテクチャ上の位置により，それぞれの送信元等が限定されている。
　請求項６，８，９，１２，１６についての補正は，用語を統一するものであり，誤記の訂正を目的とするものといえる。
　請求項２，３，１０，１２，１４，１５，１７，３９についての補正は，請求項の削除を目的とするものであり，これに伴い請求項の項番が繰り上げられている。
　また，特許法第１７条の２第３項，第４項に違反するところはない。
（２）独立特許要件
　請求項４０についての上記補正は，特許請求の範囲の減縮を目的とするものであるから，補正後の発明が特許出願の際独立して特許を受けることができるものであるのか否かについて，以下検討する。
ア　補正後の発明
　上記「１　本願発明と補正後の発明」の項の「補正後の発明」の「端末測定データを収集するために使用される前記構成パラメータが，・・・，報告されたUE測定情報，・・・のうちの任意の組合せのうちのいずれか1つを備える」は，「端末測定データを収集するために使用される構成パラメータ」が端末測定データを収集した結果である「報告されたUE測定情報」を備えることは矛盾しており，本願明細書の【０１６７】の【表１】，【０１７３】の【表２】，【０１７６】の【表３】中の「報告されるべき，選択されたUE測定情報（Selected UE measurements Info）」の記載を参酌すれば，上記記載中の「報告されたUE測定情報」は「報告されるべきUE測定情報」の誤記であることは明らかである。
　したがって，補正後の発明は，「報告されたUE測定情報」は「報告されるべきUE測定情報」の誤記として，その余は上記「１　本願発明と補正後の発明」の項の「補正後の発明」のとおりのものと認める。
イ　引用発明及び周知事項
［引用発明］
　原査定の拒絶の理由に引用された.“Telecommunication management; Integration of device management information with Itf-N (Release 9)”（［当審仮訳］：電気通信管理；Itf-Nを用いたデバイス管理情報の統合（リリース９）），3GPP TR 32.827 V0.4.0，２０１０年１月，pp.10-15（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。
（ア）「4.1.1.1　Device management aspect 
Selection of devices participating in data collection
　　Mobile devices are expected to be used for data collection for MDT and SON purposes.  （中略）Consequently, devices involvement in data collection for MDT/SON will need to be controlled by the operator according to specific policies, which will need to be configurable on a per-device basis. 」（６ページ）
（［当審仮訳］：
4.1.1.1　デバイス管理の側面
データ収集に参加するデバイスの選択
　モバイルデバイスは，MDT及びSON目的のためのデータ収集に使用されることが期待される。　（中略）　その結果，MDT/SONのためのデータ収集におけるデバイスの関与は，事業者により特定のポリシーに応じて制御される必要があり，それはデバイス毎に構成可能にされる必要がある。）
（イ）「4.1.1.2　Device management aspect of data collection 
　　According to [1], Section 4, operators must have the ability to configure measurement logging/reporting for MDT independently from RRM tasks. The following considerations must be addressed with respect to the management of data collection for MDT/SON:
（中略）
Type of data to be collected
　　Operator may also need to have the ability to configure which data needs to be collected and when.（中略）
Selection of geographic areas inside which the data will be collected 
　　Operators may want to limit the scope of data collection for MDT/SON to within specific geographic areas. 」（６〜７ページ）
（［当審仮訳］：
4.1.1.2　データ収集のデバイス管理の側面
　文献[1]の第4節によると，事業者は，RRMのタスクから独立して，MDTの測定ログ／レポート機能を構成する機能を持っている必要がある。次の考慮事項は，MDT/SONのためのデータ収集の管理に関して対処する必要がある。
（中略）
収集されるデータの種類
　事業者はまた，どのデータを，いつ，収集する必要があるかを構成する能力を持っている必要がある。（中略）
データが収集される内部の地理的領域の選択
　事業者は，MDT/SONのためのデータ収集の範囲を特定の地理的領域内に制限することを望むことができる。）
（ウ）「4.3.1　eNB involved solution for UE measurement collection
4.3.1.1　General 
　The eNB involved architecture is shown in figure X.
4.3.1.2　Definitions
Immediate reporting from UE to eNB:
　　The UE will report immediately at the end of the collection period the measurements to the connected eNB through RRC whenever UE is in active mode (collection period = reporting period).
Logging and reporting from UE to eNB: 
　　The UE performs separate measurement collection and reporting. The time interval for measurement collection and reporting can be separately configurable in order to limit the impact on the UE battery consumption and the network signalling load.
4.3.1.3　Operator configured policy
　The operator sends the measurement configuration to the eNB, which may include:
　1.　Evaluation area(s) (e.g. a region, a limited group of cells, one cell)
　2.　Collection period
　3.　Collected measurements
　4.　Reporting triggers (e.g. RSRP  Threshold)  
　5.　Probability that measurements are reported or logged when trigger condition(s) are met
　6.　Reporting period
　7.　Immediate or logging mode configuration.
　8.　Other constraints like UE/eNB memory usage, UE battery, UE type etc. 
4.3.1.4　Selection of devices participating in data collection
　　Two methods for configuration of UEs selected for participation in data collection are possible; one involving unicast configuration messages from the eNB to the UEs and one using broadcast messages. Using either method, the eNB can direct UEs to perform measurements, either as a result of being directed to do so by the IRPManager, or autonomously in order to gather data for distributed SON applications.
　　The first alternative is that the eNB selects UEs to perform measurement for drive test minimization according to operator’s policy.
　　The eNB selects suitable UEs to perform measurements and the policy configured by the operator is then transferred to the selected UEs via dedicated unicast. 
　　The second method for selection of UEs is for the eNB to broadcast the policy configured by the operator to all the UEs in the service area of that eNB.（中略）
4.3.1.5　Data collection from UE to eNB
　　According to immediate/logging mode configuration, the UE will collect and report the measurements to the connected eNB. 
　　The measurement reports include time information, location information if available, radio environment measurements.
4.3.1.6　Data collection from eNB to Network Manager through Itf-N
　　The eNB transmits the measurement reports of drive test minimization to the Network Manager through Itf-N according to preconfigured reporting period. The reports may be compressed by the eNB.
　　The eNB can make use of the UE measurements for SON or other functionality purpose. In case the eNB does not need to use UE measurements, the eNB will only forward those measurements to OAM. 」（９〜１０ページ）
（［当審仮訳］：
4.3.1　UE測定の収集のためのeNBが含まれた解決策
4.3.1.1　概論
　eNBが含まれたアーキテクチャは図Xに示される。
（図Xは省略。）
4.3.1.2　定義
UEからeNBへの即時報告：
　UEがアクティブモード（収集期間＝報告期間）であるときはいつでも，UEは，収集期間の終了時に，接続されたeNBに，RRCを通じて，測定を直ちに報告する。
ロギング及びUEからeNBへの報告：
　UEは測定の収集と報告を別々に行う。測定の収集と報告のための時間間隔は，UEのバッテリー消費量とネットワークのシグナリング負荷への影響を制限するために，個別に構成することができる。
4.3.1.3　事業者が構成したポリシー
　事業者は，以下のものを含み得る測定構成を，eNBに送信する。
　1．評価領域（例えば，地域，限られたグループのセル，１つのセル）
　2．収集期間
　3．収集された測定値
　4．報告のトリガ（例えば，RSRP＜しきい値）
　5．トリガ条件が満たされたときの測定値が報告されたか又はログされた確率
　6．報告期間
　7．即時又はロギングモードの構成。
　8．UE/ eNBのメモリ使用量，UEのバッテリー，UEタイプ等のような他の制約）
4.3.1.4　データ収集に参加するデバイスの選択
　データ収集に参加するために選択されたUEの構成のための２つの方法が可能である。
　１つはeNBからUEへのユニキャスト・コンフィギュレーション・メッセージを含むものであり，もう１つはブロードキャスト・メッセージを使用するものである。
　いずれかの方法を使用しても，分散型SONアプリケーションのためのデータを収集するために，IRPManagerによってそうするように指示された又は自律的になした結果として，eNBは測定を実行するためにUEに指示することができる。
　第１の選択肢は，eNBは，事業者のポリシーに従って，ドライブテストの最小化のための測定を実行するようにUEを選択することである。
　eNBは，測定を実行するために好適なUEを選択し，その後，事業者により構成されたポリシーが，専用ユニキャストを介して選択されたUEに転送される。
　UEを選択するための第２の方法は，eNBにとって，当該eNBのサービスエリア内の全てのUEに，事業者によって構成されたポリシーをブロードキャストすることである。（中略）
4.3.1.5　UEからeNBへのデータ収集
　即時／ロギングモードの構成に従って，UEは，測定結果を収集し，接続されたeNBに報告する。
　測定報告は，時刻情報，可能であれば位置情報，無線環境の測定を含む。
4.3.1.6　Itf-Nを介したeNBからネットワーク・マネージャへのデータ収集
　eNBは，事前構成された報告期間に従い，Itf-Nを介して，ネットワーク・マネージャに，ドライブテストの最小化の測定報告を送信する。報告はeNBによって圧縮され得る。
　eNBは，SONや他の機能の目的のために，UE測定を利用することができる。eNBがUE測定を利用する必要がない場合は，eNBはそれらの測定をOAMに転送するだけである。）
（エ）「4.3.2.1　High-level Description
　Figure 4-x provides a high-level view of the user plane architecture for MDT management. 
The following are the entities in this architecture and their roles:
Device Management Server (DMS)
DMS provides the following functionalities:
　1.　MDT management services to network operator, including: 
　　●Configuration of policy for selecting UEs to be included in the MDT campaign, based on:
（中略）
　　●Configuration of logging and reporting policies
　　　○types of measurements and/or events to be logged
　　　○logging/reporting triggering and ending conditions, date/time, amount of data collected etc.
　　　○logfile upload target (e.g. file server URL) 
　　●Fault and performance management related to MDT functionality
　　　　The above services may be offered directly or DMS can implement the functionality of IRPAgent, which provides MDT management services over Itf-N to IRPManager located in the NM. In this case, MDT management can be performed at the NM level.
　2.Management of the MDT function in the UE. In this role, the DMS:
　　●selects the UEs to be included in the MDT campaign based on the criteria configured by operator/NM
　　●establishes and manages connections with selected UEs via a user plane protocol. These connections are transparent to RAN and core network and they do not require constant RAN/CN connectivity;
　　●translates MDT configuration requests received from the operator/NM to requests to the selected UEs. The requests include configuring: type of measurements to be logged, logging/reporting triggering conditions (e.g. entering/leaving target area, time, occurrence of an event, amount of data collected, battery/memory status etc.), logfile upload server’s URL etc.;
Network Manager (NM)
　　NM implements the functionality of IRPManager that uses MDT management services offered by IRPAgent in the DMS, described above, over Itf-N. This allows the operator to integrate their MDT management into their network management platform at the NM level. 
UE
　　UE implements the functionality of an agent that provides the DMS with the services described in the previous section. 」（１０〜１１ページ）
（［当審仮訳］：
4.3.2.1　ハイレベル説明
　図4-xはMDT管理のためのユーザ・プレーン・アーキテクチャの高レベルの説明を提供する。
（図4-xは省略。）
　このアーキテクチャのエンティティとその役割は次のとおりである：
デバイス管理サーバー（DMS）
　DMSは，以下の機能を提供する。
　1．以下を含む，ネットワーク・事業者へのMDT管理サービス：
　　●以下に基づく，MDTキャンペーンに含まれるUEを選択するためのポリシーの構成（中略）
　　●ロギング及びレポーティング・ポリシーの構成
　　　○ログされる測定及び／又はイベントのタイプ
　　　○ロギング／報告のトリガ及び終了条件，日付／時刻，収集されるデータの量等
　　　○ログファイルのアップロード先（例えば，ファイルサーバURL）
　　●MDT機能に関連した障害及びパフォーマンス管理
　　　上記のサービスは直接提供されることができるか，又は，DMSは，MDT管理サービスをNMに位置するIRPManagerにItf-Nで提供するIRPAgentの機能を実装することができる。この場合，MDT管理はNMレベルで行うことができる。
　2．UEにおけるMDT機能の管理。この役割の中で，DMSは：
　　●事業者／NMにより構成された基準に基づいて，MDTキャンペーンに含まれるUEを選択。
　　●ユーザプレーン・プロトコルを介して，選択されたUEとの接続を確立し管理する。これらの接続は，RAN及びコアネットワークに対して透過的であり，コンスタントなRAN/CN接続性を必要としない。
　　●選択されたUEへ要求するため，事業者／ NMから受信したMDT構成要求を翻訳する。要求は以下の構成を含む：ログされる測定のタイプ，ロギング／報告のトリガ条件（例えば，標的領域への侵入／退出，時間，イベントの発生，収集されたデータの量，バッテリ／メモリの状態等），ログファイルのアップロードサーバのURL等;
ネットワークマネージャ（NM）
　NMは，上述のように，Itf-Nを介してDMSのIRPAgentにより申し出されたMDT管理サービスを使用するIRPManagerの機能を実装する。これは，事業者が，MDT管理を，ネットワーク管理プラットフォームにNMレベルで統合することを，可能にする。
UE
　UEは，前のセクションで説明したサービスをDMSにもたらすエージェントの機能を実装する。）
（オ）「4.3.2.3　Example of a flow of an MDT campaign using user plane transport solution
Step 1: Configuration of MDT in DMS by NW operator (directly or via Itf-N) 
　・NW operator configures the policy for selecting UEs to participate in the MDT campaign. As described above, this can be based on subscription profile, device type/capabilities, device status, customer complaints etc.
　・NW operator configures the NW area in which the MDT campaign should be executed
　・NW operator configures the type of measurements/events to be logged, logging/reporting triggers
Step 2: Configuration of MDT in selected UEs by DMS via user plane protocol
　・DMS selects the UEs to participate in the campaign. This can be based on UE IMSI, IMEI, phone number etc.(customer complaints), phone number area code, user locations obtained from the location server, information received from OAM via Itf-N or other information available to DMS or supplied to it. 
　・DMS establishes connections with selected UEs
　・DMS configures each UE with the MDT target area, type of measurements/events to be logged, logging/reporting triggers and file server URL for logfile upload
　・DMS terminates the connection with the selected UEs
Step 3: Measurement collection and reporting
　・UE logs measurements/events based on logging triggers without the need for constant connectivity with RAN/CN
　・UE uploads logfiles to the file server based on reporting triggers 
Step 4: MDT campaign termination
　・DMS pre-configures MDT campaign termination criteria (e.g. time, amount of data etc.) UE locally terminates the MDT campaign instance based on the termination criteria, hence no need for interaction between DMS and UE or RAN/CN connectivity.」（１２ページ）
（［当審仮訳］：
4.3.2.3　ユーザプレーン・トランスポート・ソリューションを用いたMDTキャンペーンのフローの一例
ステップ1：NW事業者（直接又はItf-Nを介して）によるDMSにおけるMDTの構成
　・NW事業者は，MDTのキャンペーンに参加するUEを選択するためのポリシーを構成する。上述したように，これは加入プロファイル，デバイスタイプ／能力，装置の状態，顧客の苦情等に基づくことができる。
　・NW事業者は，MDTのキャンペーンを実行すべきNW領域を構成する。
　・NW事業者は，ログされる測定／イベントのタイプ，ロギング／報告のトリガを構成する。
ステップ2：DMSによる，ユーザ・プレーン・プロトコルを介した，選択されたUEにおけるMDTの構成
　・DMSは，キャンペーンに参加するUEを選択する。これは，UEのIMSI，IMEI，電話番号等（顧客からの苦情），電話番号の市外局番，ロケーションサーバから取得したユーザーの場所，Itf-Nを介してOAMから受信した情報又はDMSが利用可能あるいはDMSに供給された他の情報に基づくことができる。
　・DMSは，選択されたUEとの接続を確立する。
　・DMSは，各UEについて，MDT対象領域，ログされる測定／イベントのタイプ，ロギング／報告のトリガ，及びログファイルをアップロードするファイルサーバのURLを構成する。
　・DMSは，選択されたUEとの接続を終了する。
ステップ3：測定収集と報告
　・UEは，ロギング・トリガに基づいて，RAN/CNとの常時接続を必要とせずに，測定／イベントをログする。
　・UEは，報告トリガに基づいて，ファイルサーバにログファイルをアップロードする。
ステップ4：MDTキャンペーンの終了
　・DMSは，MDTキャンペーン終了基準（例えば，時間，データの量等）を事前構成する。UEは終了基準に基づいて，MDTキャンペーン・インスタンスをローカルに終了する。そのため，DMSと，UE又はRAN/CNとの間の接続性に係る相互作用は必要ない。）
（カ）「4.3.3.2　Issues needing resolution
4.3.3.2.1　General
　　The inclusion of MDT can be done with either a control plane solution or a use plane soltution.
（中略）
4.3.3.2.2　User plane solution
　　The user plane solution is to establish a normal connection between the DM and UE (comparable to a connection between a UE and a web-server) and send data as user data over the Uu interface.
（中略）
4.3.3.2.3　Control plane solution
　　The control plane solution is that the communicatin between the management system and the UE is done via existing management interfaces, the traffic control signalling interfaces, which implies RRC signalling over the Uu interface.」（１３〜１４ページ）
（［当審仮訳］：
4.3.3.2　解像度を必要とする問題
4.3.3.2.1　概論
　MDTの包含は，制御プレーン・ソリューション又はユーザプレーン・ソリューションのいずれかで行うことができる。
（中略）
4.3.3.2.2　ユーザプレーン・ソリューション
　ユーザプレーン・ソリューションは，DMとUEとの間の正常な接続を確立し（UEとウェブサーバ間の接続と同様），Uuインタフェースを介してユーザデータ等のデータを送信する。
（中略）
4.3.3.2.3　制御プレーン・ソリューション
　制御プレーン・ソリューションは，管理システムとUEとの間の通信は，既存の管理インターフェース，トラフィック制御インターフェイスを介して行われ，それはUuインタフェース上でのRRCシグナリングを意味する。）
　上記記載及び図面並びに当業者の技術常識を考慮すると，
　上記（ア），上記（ウ）の図X及び4.3.1.2，4.3.1.5の記載によれば，UEは，MDTに係る測定を行い，UE測定をログし，eNBにUE測定を報告することが見て取れる。また，上記（ウ）の4.3.1.4の記載によれば，eNBはUEに対して事業者によって構成されたポリシーを送信することが見て取れる。そして，UEが，測定するための測定手段及びeNBとの間で送受信するための手段を備えることは明らかである。
　上記（ウ）の4.3.1.3の記載によれば，事業者によって構成されたポリシーには，評価領域（例えば，地域，限られたグループのセル，１つのセル），収集期間，収集された測定値，報告のトリガ（例えば，RSRP＜しきい値），トリガ条件が満たされたときの測定値が報告されたか又はログされた確率，報告期間，即時又はロギングモードの構成，UE/ eNBのメモリ使用量，UEのバッテリー，UEタイプ等のような他の制約）が含まれ，上記（エ）の4.3.2.1の2.，上記（オ）の4.3.2.3のステップ2の記載によれば，UEに要求するために，このうちの少なくともMDT対象領域，ログされる測定／イベントのタイプ，ロギング／報告のトリガ，及びログファイルをアップロードするファイルサーバのURLは，eNBを介してUEに送信されると解するのが自然である。そして，上記（オ）の4.3.2.3のステップ3，4の記載によれば，UEは当該情報に基づいて，MDTに係る測定，ロギング，報告，終了を行っていると解されるから，当該情報はMDTのために使用される情報といえる。
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認める。
「eNBによって送信された情報を受信して，UE測定の報告を前記eNBに送信するように構成された，eNBとの間で送受信するための手段であって，前記情報がMDTのために使用される情報である，eNBとの間で送受信するための手段と，
　MDTのために使用される前記情報によってUE測定を測定するように構成された測定手段とを備え，
　MDTのために使用される前記情報が，
　MDT対象領域，ログされる測定／イベントのタイプ，ロギング／報告のトリガ，及びログファイルをアップロードするファイルサーバのURLを備える，UE。」
［周知事項］
　原査定の拒絶の理由に引用された“Telecommunication management; Subscriber and equipment trace; Trace control and configuration management (Release 9)”（［当審仮訳］：電気通信管理；加入者及び装置のトレース；トレース制御及び構成管理（リリース９）），3GPP TS 32.422 V9.0.1，２０１０年１月，pp.29-33（以下，「周知例１」という。）には，図面とともに以下の事項が記載されている。
（キ）「4.1.2.10EPC activation mechanism
Figure 4.1.2.10.1 summarizes the Trace Session activation procedure in EPC:
（中略）
When HSS activates the trace to the MME the following trace control and configuration parameters shall be included in the message:
　・IMSI or IMEISV
　・Trace Reference
　・Triggering events for MME, Serving GW, PDN GW
　・Trace Depth
　・List of NE types to trace
　・List of Interfaces for MME, Serving GW, PDN GW, eNB
　・IP address of Trace Collection Entity
When MME activates the trace to the SGW the following trace control and configuration parameters shall be included in the message::
　・IMSI or IMEISV
　・Trace Reference
　・Triggering events for Serving GW, PDN GW
　・Trace Depth
　・List of NE types to trace
　・List of Interfaces for Serving GW, PDN GW
　・IP address of Trace Collection Entity
When SGW activates the trace to the PGW the following trace control and configuration parameters shall be included in the message:
　・IMSI or IMEISV 
　・Trace Reference
　・Triggering events for PDN GW
　・Trace Depth
　・List of Interfaces for PDN GW
　・IP address of Trace Collection Entity
When MME sends the trace control and configuration parameters to the eNB the following information shall be included in the message:
　・Trace Reference
　・Trace Recording Session Reference
　・Trace Depth
　・IP Address of Trace Collection Entity
and the following information may be included in the message:
　・List of Interfaces for eNB　」（２９〜３１ページ）
（［当審仮訳］：
4.1.2.10　EPCアクティベーション・メカニズム
　図4.1.2.10.1はEPCにおけるトレース・セッション・アクティベーション・手続を要約している。
（図4.1.2.10.1は省略。）
（中略）
　HSSがMMEへのトレースをアクティブにするとき，次のトレース制御及び構成パラメータがメッセージに含まれるものとする。
　　・IMSI又はIMEISV
　　・トレースリファレンス
　　・MME，サービングGW，PDN GWのためのトリガ・イベント
　　・トレースの深さ
　　・トレースするNEタイプのリスト
　　・MME，サービングGW，PDN GW，eNBのためのインタフェースのリスト
　　・トレース収集エンティティのIPアドレス
　MMEがSGWへのトレースをアクティブにするとき，次のトレース制御及び構成パラメータがメッセージに含まれるものとする。
　　・IMSI又はIMEISV
　　・トレースリファレンス
　　・サービングGW，PDN GWのためのトリガ・イベント
　　・トレースの深さ
　　・トレースするNEタイプのリスト
　　・サービングGW，PDN GWのためのインタフェースのリスト
　　・トレース収集エンティティのIPアドレス
　SGWがPGWへのトレースをアクティブにするとき，次のトレース制御及び構成パラメータがメッセージに含まれるものとする。
　　・IMSI又はIMEISV
　　・トレースリファレンス
　　・PDN GWのためのトリガ・イベント
　　・トレースの深さ
　　・トレースするNEタイプのリスト
　　・PDN GWのためのインタフェースのリスト
　　・トレース収集エンティティのIPアドレス
　MMEがeNBにトレース制御及び構成パラメータを送信するとき，以下の情報がメッセージに含まれるものとする。
　　・トレースリファレンス
　　・トレース記録セッションリファレンス
　　・トレースの深さ
　　・トレース収集エンティティのIPアドレス
そして次の情報がメッセージに含まれ得る。
　　・eNBのためのインターフェイスのリスト　）
　原査定の拒絶の理由に引用されたTeliaSonera, T-Mobile，“Necessary measurements for minimising drive tests”（［当審仮訳］：ドライブテストの最小化のための必要な測定），3GPP TSG-RAN WG2 #66, R2-092820，２００９年５月（以下，「周知例２」という。）には，図面とともに以下の事項が記載されている。
（ク）「4.　Proposed measurements
　There are some examples of events that we would like to be recorded by the UE which is difficult or impossible to measure in the network.  These events should have configurable parameters and need detailed definition. 
　・Coverage loss (no suitable cell present). Recorded with timestamp, last camped cell and GPS position.
（中略）
　・Pilot pollution. Several equally strong cells which cause mutual interference. Recorded with serving cell, physical cell identity of involved cells, timestamp and position.
（中略）
　・Ping pong cell reselections between cells and networks. Recorded with involved cells, timestamp and position.
（中略）
　・PS service access failure. Number of attempts from application layer in UE until successful Radio Bearer establishment and payload flow using the requested QoS. Recorded with cell, timestamp and position.
（中略）
　・User throughput per QCI. Recorded with latency and packet loss, cell, timestamp and position.」（１〜２葉）
（［当審仮訳］：
4.　提案する測定
　ネットワークで測定することが困難又は不可能である，UEによって記録されることが望まれるいくつかのイベントの例がある。これらのイベントは，構成可能なパラメータを持つべきであり，詳細な定義を必要とする。
　・カバレッジ損失（適切なセルが存在しない）。タイムスタンプ，最後にキャンプしたセル及びGPSの位置を記録。
（中略）
　・パイロット汚染。相互干渉を引き起こすいくつかの同等の強さのセル。サービング・セル，関与するセルの物理セル識別情報，タイムスタンプ及び位置を記録。
（中略）
　・セルとネットワークの間のピンポン・セル再選択。関与するセル，タイムスタンプ及び位置を記録。
（中略）
　・PSサービスへのアクセス失敗。無線ベアラの確立及び要求されたQoSを使用したペイロードのフローの成功までになされたUEのアプリケーション層からの試行回数。セル，タイムスタンプ及び位置を記録。
（中略）
　・QCI当たりのユーザのスループット。待ち時間及びパケット損失，セル，タイムスタンプ及び位置を記録。）
　上記（ウ）の4.3.1.2，上記（エ）の4.3.2.1の2.，上記（オ）の4.3.2.3のステップ2，上記（キ），上記（ク）の記載によれば，「MDTのために事業者により構成される情報として，評価領域（例えば，地域，限られたグループのセル，１つのセル）（MDT対象領域），IMSI又はIMEISV，トレースするNEタイプのリスト，トレースリファレンス，収集期間，収集された測定値（ログされる測定／イベントのタイプ），タイムスタンプ，位置情報，成功までになされたUEのアプリケーション層からの試行回数，待ち時間，パケット損失，ロギング／報告のトリガ（例えば，RSRP＜しきい値），トリガ条件が満たされたときの測定値が報告されたか又はログされた確率，報告期間，即時又はロギングモードの構成，UE/ eNBのメモリ使用量，UEのバッテリー，UEタイプ等のような他の制約），トレースの深さ，ログファイルをアップロードするファイルサーバのURL等，種々のものがある。」ことは周知の事項といえる（以下，「周知事項１」という。）。
　原査定の拒絶の理由に引用されたNokia Siemens Networks,  Nokia Corporation，“Architectures comparison”（［当審仮訳］：MDT要求及び期待されるステージ2/3作業），3GPP TSG-RAN WG2 Meeting #68, R2-097020，２００９年１１月（以下，「周知例３」という。）には，図面とともに以下の事項が記載されている。
（ケ）「2.2　Control plane-solution
　In this approach measurements are configured to the UE by eNB by normal RRC signalling, based on Network Management Systems measurement definitions configured to eNB. The configuration in Network management system is expected to be on cell and Node B level, so that desired results are obtained from all or part of the terminals accessing to the cell. 
　In typical situation measurement configuration to the UEs is done by using dedicated RRC signalling in RRC Connected state, but utilisation of broadcast signalling to setup some limited set of measurements for all devices accessing to the cell could be envisioned. 
（中略）
　The reporting of the measurement results are transported via normal RRC signalling to the eNB. 」（１〜２葉）
（［当審仮訳］：
2.2　制御プレーン・ソリューション
　このアプローチでは，eNBに対して構成されたネットワーク管理システムの測定定義に基づいて，eNBによって，通常のRRCシグナリングにより，測定がUEに対して構成される。ネットワーク管理システムにおける構成はセル及びeNBレベルであると予想され，所望の結果はセルにアクセスしている全て又は一部の端末から得られる。
　典型的な状況ではUEに対する測定構成は，RRC接続状態における専用のRRCシグナリングを使用することによって行われるが，セルにアクセスする全てのデバイスの測定値のいくつかの限られたセットのセットアップにブロードキャスト・シグナリングを利用することが想像される。
（中略）
　測定結果の報告は，通常のRRCシグナリングを介してeNBに転送される。）
　上記（カ），（ケ）の記載によれば，「MDTのために使用される構成情報が無線ネットワークを介してRRC（無線リソース制御）シグナリングによりUEに送信される。」ことは周知であると認められる（以下，「周知事項２」という。）。
ウ　対比・判断
　補正後の発明と引用発明とを対比すると，
（ア）補正後の発明の「eノードB」，「ユーザ装置」，「トランシーバ」，「測定ユニット」，「端末測定データ」と，引用発明の「eNB」，「UE」，「eNBとの間で送受信するための手段」，「測定手段」，「UE測定」とは，それぞれ表現が異なるのみであって実質的な差異は無い。
（イ）補正後の発明の「構成パラメータ」は，「端末測定データ収集するために使用される」，「ドライブテストの最小化(MDT)コンフィギュレーション」であり，端末測定データインジケータ，報告されたUE測定情報，端末測定データ収集の範囲リスト，端末測定データ収集の優先順位，およびターゲットユーザアイデンティティ(IMSI, IMEI)またはターゲットユーザアイデンティティのリストのパラメータのうちの任意の組合せからなるものである。
　一方，引用発明の「情報」も，もともと事業者が構成したポリシー（Operator configured policy）であり，MDTのために使用されるものであるから，「ドライブテストの最小化(MDT)コンフィギュレーションである」といえる。また，MDTは「端末測定データ収集する」ものであることは技術常識であるから，当該「情報」は「端末測定データ収集するために使用される」といえる。そして，MDT対象領域，ログされる測定／イベントのタイプ，ロギング／報告のトリガ，及びログファイルをアップロードするファイルサーバのURLを備えるものであり，これらを「パラメータ」と称することは任意である。
　したがって，引用発明の「情報」は，下記の相違点は別として，補正後の発明の「構成パラメータ」に相当する。
（ウ）引用発明の「MDT対象領域」は，補正後の発明の「端末測定データ収集の範囲リスト」に対応する。また，引用発明の「ログされる測定／イベントのタイプ」は，報告されるべきUE測定を示しているといえるから，補正後の発明の「報告されるべきUE測定情報」に対応する。したがって，補正後の発明の「端末測定データを収集するために使用される前記構成パラメータ」と引用発明の「情報」とは，「少なくとも報告されるべきUE測定情報，端末測定データ収集の範囲リストを含む」点で共通している。
　以上を総合すると，補正後の発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「eノードBによって送信された端末測定データ収集するために使用される構成パラメータを受信して，端末測定データ報告を前記eノードBに送信するように構成されたトランシーバであって，前記構成パラメータがドライブテストの最小化(MDT)コンフィギュレーションである，トランシーバと，
　端末測定データを収集するために使用される前記構成パラメータによって端末測定データを測定するように構成された測定ユニットとを備え，
　端末測定データを収集するために使用される前記構成パラメータが，
　少なくとも報告されるべきUE測定情報，端末測定データ収集の範囲リストを含む，ユーザ装置。」
（相違点）
　一致点の「端末測定データを収集するために使用される前記構成パラメータ」に関し，補正後の発明は，「端末測定データインジケータ，報告されるべきUE測定情報，端末測定データ収集の範囲リスト，端末測定データ収集の優先順位，およびターゲットユーザアイデンティティ(IMSI, IMEI)またはターゲットユーザアイデンティティのリストのパラメータのうちの任意の組合せのうちのいずれか1つを備える」のに対し，引用発明は，「MDT対象領域，ログされる測定／イベントのタイプ，ロギング／報告のトリガ，及びログファイルをアップロードするファイルサーバのURLを備える」ものである点。
　以下，上記相違点について検討する。
　引用発明は，「端末測定データインジケータ，報告されるべきUE測定情報，端末測定データ収集の範囲リスト，端末測定データ収集の優先順位，およびターゲットユーザアイデンティティ(IMSI, IMEI)またはターゲットユーザアイデンティティのリストのパラメータのうちの任意の組合せ」のうちの「「報告されるべきUE測定情報」と「端末測定データ収集の範囲リスト」の組み合わせ」を備えるといえるから，両者に実質的な相違は無い。
　また，周知事項１のとおり，MDT用の構成パラメータとして様々なものが知られており，どのようなものを採用するかは，適宜選択し得る事項に過ぎない。
　したがって，上記相違点は当業者が適宜なし得ることにすぎない。
　そして，補正後の発明の作用効果も，引用発明及び周知事項に基づいて当業者が予測できる範囲のものである。
（なお，請求人は，平成２８年５月９日提出の上申書にて，補正後の発明（請求項３２）に対して，(i) 「構成パラメータが無線ネットワークを介して無線リソース制御シグナリングによりユーザ装置に送信される」点を限定する補正，(ii)構成パラメータを「トリガ条件であって，前記UEに関連するダウンリンクパイロット信号強度の定期的ロギングイベントと，前記UEに関連するランダムアクセス失敗イベントと，前記UEに関連するページングチャネル復号失敗イベントと，前記UEに関連する無線リンク失敗イベントとのうちのいずれか１つまたは任意の組み合わせの発生を含む，トリガ条件」を備えるものに変更する補正，を含む補正案を提示し，補正の機会を与えるよう求めている。
　しかしながら，上記(i) の補正事項は，周知事項２のとおり周知であるから，当該補正によって進歩性が生じるものではない。また，上記(ii)の補正事項は，構成パラメータの内容を全く異なるものに変更するものであるから，特許法第１７条の２第５項の規定に違反するものであって認めることができない。仮にこれを認めたとしても，引用発明の「MDTのために使用される情報」は，例えばRSRPがしきい値以下の場合等の「ロギング／報告のトリガ」を含むものであり，また周知事項１のとおりトリガとして「成功までになされたUEのアプリケーション層からの試行回数，待ち時間，パケット損失」等も知られており，トリガとしてどのようなものを採用するか設計上の選択事項であるところ，MDTの意義に照らせば上記(ii)の補正事項に挙げられているイベントは格別困難なものではなく，適宜採用し得ることにすぎない。
　したがって，補正案に係る発明も特許性を有するものではないから，補正する機会を与える必要性は見出せない。）
　以上のとおり，補正後の発明は，引用発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
３　結語
　したがって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成２７年１１月９日付けの手続補正は上記のとおり却下されたので，本願発明は，上記「第２　補正却下の決定」の項中の「１　本願発明と補正後の発明」の項の「本願発明」のとおりのものと認める。
２　引用発明
　引用発明及び周知事項は，上記「第２　補正却下の決定」の項中の「２　補正の適否」の項中の「（２）独立特許要件」の項中の「イ　引用発明及び周知事項」の項で認定したとおりである。
３　対比・判断
　そこで，本願発明と引用発明とを対比するに，本願発明は補正後の発明から当該補正に係る限定を省いたものである。
　そうすると，本願発明と引用発明との間には，補正後の発明と引用発明との間の上記相違点は存在しない。そして，本願発明が「端末測定データ収集するために使用される構成パラメータ，またはノードBによって送信された端末測定停止インジケータを受信」するのに対し，引用発明は端末測定停止インジケータの受信について明らかにしていない点で相違することになる。
　しかしながら，「または」は択一的であることを表現する記載であるから，本願発明は「端末測定データ収集するために使用される構成パラメータ」のみを受信することを含むものである。したがって，両者に実質的な相違は無い。また，MDTもトレース技術の一種であるところ，トレース技術において情報取得停止指示を発行することは，例えば原査定の拒絶の理由に引用された特開２００８−２２０６５号公報の【００４１】にも示されているように，普通に行われていることにすぎないから，端末測定停止インジケータの受信の点は格別困難なことではない。
　したがって，本願発明は，引用発明及び周知事項に基づいて容易に発明できたものである。
４　むすび
　以上のとおり，本願発明は，引用発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。