2018-006067

ｖ　特願２０１６－５４１８０１「移動情報報告方法、システム及び機器」拒絶査定不服審判事件〔平成２７年　３月２６日国際公開、ＷＯ２０１５／０３９６２５、平成２８年１０月１３日国内公表、特表２０１６－５３２４０２〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本願は，２０１４年（平成２６年）９月２２日（パリ条約による優先権主張外国庁受理　２０１３年９月２３日　中国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。 平成２８年３月９日　　　　　：手続補正書の提出 平成２９年２月２７日付け　　：拒絶理由通知書 平成２９年６月１３日　　　　：意見書，手続補正書の提出 平成２９年１２月２６日付け　：拒絶査定 平成３０年５月２日　　　　　：拒絶査定不服審判の請求，手続補正書の提出 平成３１年４月２５日付け　　：拒絶理由通知書（当審） 令和　１年８月２日　　　　　：意見書，手続補正書の提出 第２　本願発明 本願発明は，令和１年８月２日に提出された手続補正書により補正された特許請求の範囲の請求項１に記載された，以下のとおりのものと認める。 「ユーザ機器がアイドル状態からコネクション状態への移行を確定することと、 前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することとを含み、 前記移動情報は、 前記ユーザ機器の移動状態を示す情報である第１移動情報、及び、ユーザ機器によるセル再選択の履歴情報である第２移動情報を含み、 前記第１移動情報は、ユーザ機器による移動状態推定で確定される情報であり、 前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することは、 前記ユーザ機器が第１移動情報をネットワーク側機器に報告することと、 前記ユーザ機器が前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定してから、前記第２移動情報を前記ネットワーク側機器に報告することとを含み、 前記ユーザ機器は、 前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定する前に、さらに、前記ユーザ機器が前記第２移動情報を有するか否かを示す情報をネットワーク側機器に報告することを含むことを特徴とする移動情報報告方法。」 第３　当審の拒絶理由通知の概要 当審拒絶理由の概要は，「（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。」というものであり，請求項１に対して，判断１として，以下の引用例２，１が引用されている。 引用例１：国際公開２００７／０８８３８１号 引用例２：Ｅｒｉｃｓｓｏｎ，　ＳＴ－Ｅｒｉｃｓｓｏｎ，Ｍｏｂｉｌｉｔｙ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔ　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｅｓｔａｂｌｉｓｈｍｅｎｔ，３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　＃８３　Ｒ２－１３２６８２，２０１３年　８月　９日 第４　引用発明等 １　引用発明 当審拒絶理由に引用されたＥｒｉｃｓｓｏｎ，　ＳＴ－Ｅｒｉｃｓｓｏｎ，Ｍｏｂｉｌｉｔｙ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔ　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｅｓｔａｂｌｉｓｈｍｅｎｔ（当審訳：ＲＲＣ接続確立時のモビリティ情報），３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　＃８３　Ｒ２－１３２６８２，２０１３年　８月　９日（アップロード）（引用例２）には，以下の事項が記載されている。 「 1 Introduction （中略） It was also observed that Mobility State Estimation (MSE) mechanism is not as accurate in heterogeneous network deployments as in macro only deployments. （中略） In this paper we propose that a mobility information indicator is sent in the RRCConnectionSetupComplete message. The mobility information is retrieved using UEInformationRequest and UEInformationResponse message. Furthermore, we propose that the mobility information consists of a list of cell IDs and sojourn times. （中略） 2.1.4 Conclusion （中略） For reporting of mobility information we think it is only necessary to indicate existence of such information in the RRCConnectionSetupComplete message since that message is used when the UE transitions from IDLE to CONNECTED mode. For retrieval of the actual mobility information we think the UE Information procedure can be used. Proposal 1 The UE indicates availability of mobility information using the RRCConnectionSetupComplete message. Proposal 2 The eNB requests the mobility information using the UEInformationRequest message. Proposal 3 The UE sends the mobility information using the UEInformationResponse message. 2.2 Message content The second open issue is what the mobility information actually consists of. The purpose of the mobility information is to enable the network to get an understanding of the mobility state of the UE, as early as possible from the transition to CONNECTED. Once in CONNECTED, the network can track the UE and count the number of handovers in the same way as the UE can, but while the UE is in IDLE mode, the network does not know when the UE performs cell reselections among the cells. The following solutions can be envisioned: 1 The UE signals its mobility state 2 The UE signals a list of cell IDs and time spent in each cell 2.2.1 Mobility state This alternative means that the only mobility information the UE signals is its mobility state. The benefit of this solution is that the information transmitted is very small. The drawback is that in case the cells are of different size, as is the case in heterogeneous network deployments, the mobility state estimation process is positively biased when the density of the pico cells goes up[2]. With this solution the UE needs to run the MSE process during IDLE. 2.2.2 A list of cell IDs and time spent in each cell This alternative means that the mobility information consists of a list of cells and the time spent in each cell. The benefit of this solution is that the network, knowing the approximate size of each cell, can make a better estimation of the mobility state. The drawback is that the mobility information can be big, depending on the number of cells in the message.」(１ページ～３ページ) （当審訳： １　序論 （中略） また、モビリティ状態推定（ＭＳＥ）メカニズムは、マクロのみの配置におけるように異種ネットワーク配置においては正確ではないことも観察された。 （中略） 本稿では，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージでモビリティ情報インジケータを送信することを提案する。モビリティ情報は，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ及びＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを取得される。さらに，モビリティ情報はセルＩＤと滞在時間のリストから成ることを提案する。 （中略） ２．１．４　結論 （中略） ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージはＵＥがＩＤＬＥからＣＯＮＮＥＣＴＥＤモードに移行するときに使用されるので，モビリティ情報の報告のために，メッセージ内にそのような情報の存在を示すことだけが必要であると考える。実際のモビリティ情報を取得するために，ＵＥ情報手順を使用できると考える。 提案１　ＵＥは，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを使用してモビリティ情報の利用可能性を示す。 提案２　ｅＮＢは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔメッセージを使用してモビリティ情報を要求する。 提案３　ＵＥは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを使用してモビリティ情報を送信する。 ２．２　メッセージ内容 ２番目の未解決の問題は，モビリティ情報が実際に何から構成されるかである。モビリティ情報の目的は，ネットワークがＵＥのモビリティ状態をＣＯＮＮＥＣＴＥＤへの遷移からできるだけ早く理解できるようにすることである。一度ＣＯＮＮＥＣＴＥＤになると，ネットワークはＵＥと同じ方法でＵＥを追跡，ハンドオーバーの数をカウントできるが，ＵＥがアイドルモードにある間，ネットワークはＵＥがセル間でいつセルの再選択を実行するかを知らない。次の解決策が考えられる。 １．ＵＥはモビリティ状態をシグナルする ２．ＵＥはセルＩＤのリストと各セルで費やした時間をシグナルする ２．２．１　モビリティ状態 この代替策は，ＵＥがシグナリングする唯一のモビリティ情報がそのモビリティ状態であることを意味する。この解決策の利点は，送信される情報が非常に少ないことである。欠点は，異機種ネットワーク展開の場合のようにセルのサイズが異なる場合，ピコセルの密度が上がるとモビリティ状態推定プロセスが正にバイアスされることである［２］。この解決策では，ＵＥはＩＤＬＥ中にＭＳＥプロセスを実行する必要がある。 ２．２．２　セルＩＤと各セルで費やされた時間のリスト この代替策は、モビリティ情報がセルのリストと各セルで費やされた時間で構成されることを意味する。この解決策の利点は、各セルのおおよそのサイズを知っているネットワークがモビリティ状態のより良い推定を行えることである。欠点は、メッセージ内のセルの数に応じて、モビリティ情報が大きくなる可能性があることである。） 引用例の上記記載及びこの分野における技術常識を考慮すると，次のことがいえる。 「２．１．４　結論」の記載によれば，モビリティ情報の報告のために，ＵＥは，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを使用してモビリティ情報の利用可能性を示し，ｅＮＢは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔメッセージを使用してモビリティ情報を要求し，ＵＥは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを使用してモビリティ情報を送信するものである。そして，「１　序論」の記載によれば，モビリティ情報はセルＩＤと滞在時間のリストから成るものである。 以上を総合すると，引用例２には，以下の発明（以下，「引用発明」という。）が記載されていると認められる。 「ＵＥは，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを使用してモビリティ情報の利用可能性を示し， ｅＮＢは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔメッセージを使用してモビリティ情報を要求し， ＵＥは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを使用してモビリティ情報を送信する， ここで，モビリティ情報はセルＩＤと滞在時間のリストから成る， 方法。」 ２　周知技術 当審拒絶理由に引用された，国際公開２００７／０８８３８１号（引用例１）には以下の事項が記載されている。 （１）「In the second embodiment of the invention it is proposed that when the mobile terminal enters an active data transfer state (i.e. CELL_DCH in UTRAN), then it provides information to the network to indicate explicitly whether it considers itself to be ”fast moving” or ”slow moving”. This information is that obtained during the preceding inactive state, and is based on the mobile terminal entering high mobility state or low mobility rate where Hierarchical Cell Structures (HCS) are used, or by deducing that it is moving quickly based on the non-HCS methods described in 3GPP specifications. This allows the network to set optimal handover settings in the mobile terminal as soon as it enters the active CELL-DCH state based on information gathered during the preceding inactive state and reduces the risk of the connection being dropped. Figure 4 shows the steps taken by the network n and the mobile terminal 1 according to the second embodiment of the invention. At step P the mobile terminal 1 enters the idle/inactive state. For example, this may occur after a predetermined period of inactivity. In the inactive state the mobile terminal 1 calculates at step Q its mobility state in the manner described above. The mobile terminal then sets the cell reselection parameters at step R in accordance with the mobility state calculated at step Q. Steps Q and R are periodically repeated in a loop so that the cell reselection parameters are frequently adjusted in accordance with the periodically calculated mobility state, in the manner described above. At step S the mobile terminal 1 enters the active state. In accordance with the second embodiment of the invention, the idle/inactive mode mobility state data determines at step Q is transmitted from the mobile terminal 1 to the network n at step T. The network n includes means to receive and process the idle/inactive mode mobility state data and to use this to set appropriate handover parameters at step U. The network n then calculates the mobility state at step V in the manner described above. The calculations made at step V are used to adjust the handover parameters at step U. Steps U and V are repeated in a loop periodically so that the handover parameters are adjusted in accordance with the prevailing mobility state in the active state. When the active state is initially entered, the historical mobility state data from the idle state transmitted in step T can be used to set appropriate handover parameters from the beginning of the active state, when sufficient historical mobility state data has not yet been calculated in the active state. 」（２６ページ３０行～２８ページ７行） （当審訳： 本発明の第２の実施形態では，移動端末がアクティブデータ転送状態（すなわち，ＵＴＲＡＮにおけるＣＥＬＬ＿ＤＣＨ）に入ると，移動端末は自身が「高速移動」又は「低速移動」のいずれであると考えるかを明示的に示す情報をネットワークに提供する。この情報は，先行する非アクティブ状態の間に取得されたものであり，階層セル構造（ＨＣＳ）が使用される場合，移動端末が「高モビリティ状態」又は「低モビリティレート」に入ることに基づいている，又は３ＧＰＰ仕様に記載されている非ＨＣＳ方式に基づいて迅速に動いていると推測する。これにより，ネットワークは，先行する非アクティブ状態中に収集された情報に基づいてアクティブＣＥＬＬ＿ＤＣＨ状態に入るとすぐに移動端末に最適なハンドオーバ設定を設定することを可能にし，接続が切断されるリスクを減らす。 図４は，本発明の第２の実施形態に係るネットワークｎと移動端末１によりなされるステップを示す。ステップＰにおいて，移動端末１が非アクティブ／アイドル状態に入る。例えば，これは，非アクティブの所定の期間の後に発生する。非アクティブ状態で移動端末１は，ステップＱで上述の方法でそのモビリティ状態を算出する。移動端末は，ステップＱにおいて計算された移動状態に従って，ステップＲにおいてセル再選択パラメータを設定する。ステップＱ及びＲはループ内で周期的に繰り返されるので，セル再選択パラメータは周期的に上述の方法で計算されるモビリティ状態に従って頻繁に調整される。 ステップＳにおいて，携帯端末１はアクティブ状態に入る。本発明の第２の実施形態によれば，ステップＱで決定するアイドル／非アクティブモードのモビリティ状態データが，ステップＴで移動端末１からネットワークｎに送信される。ネットワークｎは，アイドル／非アクティブモードのモビリティ状態データを受信し処理するための手段を含み，そしてこれを使用してステップＵで適切なハンドオーバーパラメータを設定する。ネットワークｎは，次に，ステップＶにおいて，上述の方法で移動状態を計算する。ステップＶで行われた計算は，ステップＵでハンドオーバーパラメータを調整するために使用される。ステップＵとＶがループで周期的に繰り返される，アクティブ状態での優勢なモビリティ状態に従ってハンドオーバーパラメータが調整される。 アクティブ状態に最初に入ったときに，アクティブ状態で十分な履歴モビリティ状態データがまだ計算されていない場合，ステップＴで送信されたアイドル状態からの履歴モビリティ状態データを使用して，アクティブ状態の最初から適切なハンドオーバーパラメータを設定することができる。） 本件の優先日前に公開されたＳａｍｓｕｎｇ，Ｏｎ　Ｍｏｂｉｌｉｔｙ　ｉｎｆｏｒｍａｔｉｏｎ　ｄｕｒｉｎｇ　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　ｓｅｔｕｐ，３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　＃８３　Ｒ２－１３２７４１，[ｏｎｌｉｎｅ]，２０１３年　８月　９日（アップロード）ＵＲＬ：ｈｔｔｐｓ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｒａｎ／ＷＧ２＿ＲＬ２／ＴＳＧＲ２＿８３／Ｄｏｃｓ／Ｒ２－１３２７４１．ｚｉｐには以下の事項が記載されている。 （２）「3 Discussion When UE is in idle mode, it performs mobility state estimate (MSE) based on the number of cell re-selections during an observation window. The MSE is classified as normal, medium and high. One possible option is to provide the existing MSE in idle mode during RRC connection setup. This would incur just two bits signalling overhead. However, we have already seen in HetNet studies the MSE is not accurate in HetNet environment, so then it requires the MSE to be enhanced in HetNet so that reasonable accurate estimate is provided to the network for decision making. Even though the signalling overhead is same whether Rel-8 MSE or enhanced MSE is provided in RRC connection setup complete message, some changes would be required to enhance the Rel-8 MSE. This could be achieved either broadcasting weights for different source-target handovers/re-selections or providing weight in handover command to be considered for enhancing MSE. Providing weight in handover command would enhance the MSE only for connected mode. Third option would be to classify the MSE into only two mobility states: low and high and terminate the medium state into high state. With this option, UE performs the Rel-8 MSE in idle mode and while reporting the mobility state in RRC connection setup complete it either reports low or high with one bit information. If the UE has estimated medium state based on Rel-8 mechanism then this is re-classified as high state and reported to the network. In this option there is no need to enhance the MSE and it would still be sufficiently useful for network decision making. Fourth option is to provide the UE idle mode cell re-selection history information to the network. However, this option would incur high signalling overhead and network would use this information in the same way as it does currently in connected mode. Based on the above discussion we summarize the options for mobility information to be provided during RRC connection establishment: 1 Existing Rel-8 MSE (2 bits information) 2 Enhanced MSE (2 bits information) 3 Simplified low/high mobility state based on existing Rel-8 MSE (1 bit information) 4 Idle mode cell re-selection history information (more number of bits) In our opinion all the above options for mobility information can be provided for the network decision making (for whatever scenario) whether the network environment is homogeneous deployment or heterogeneous deployment. Providing existing Rel-8 MSE or idle mode cell re-selection history information seems logical, but we have a slight preference for existing Rel-8 MSE.」（１ページ～２ページ） （当審訳： ３　討論 ＵＥがアイドルモードの場合，ＵＥは，観測ウィンドウ中のセル再選択の数に基づいてモビリティ状態推定（ＭＳＥ）を実行する。ＭＳＥは，通常，中，高に分類される。可能なオプションの１つは，ＲＲＣ接続のセットアップ中に既存のＭＳＥをアイドルモードで提供することである。これにより，２ビットのシグナリングオーバーヘッドが発生する。ただし，ＨｅｔＮｅｔの研究ではＭＳＥがＨｅｔＮｅｔ環境で正確でないことを既に理解しているため，ＭＳＥをＨｅｔＮｅｔで拡張して，意思決定のために適切な正確な推定値をネットワークに提供する必要がある。Ｒｅｌ－８　ＭＳＥまたは拡張ＭＳＥがＲＲＣ接続セットアップ完了メッセージで提供されるかどうかにかかわらず，シグナリングオーバーヘッドは同じであるが，Ｒｅｌ－８　ＭＳＥを拡張するにはいくつかの変更が必要である。これは，異なるソース－ターゲットハンドオーバ／再選択の重みをブロードキャストするか，ＭＳＥを強化するために考慮されるハンドオーバコマンドで重みを提供することで実現できる。ハンドオーバーコマンドに重みを指定すると，接続モードでのみＭＳＥが向上します。３番目のオプションは，ＭＳＥを低と高の２つのモビリティ状態のみに分類し，中状態を終了して高状態にする。このオプションを使用すると，ＵＥはアイドルモードでＲｅｌ－８　ＭＳＥを実行し，ＲＲＣ接続セットアップ完了でモビリティ状態を報告すると同時に，１ビット情報で低または高を報告する。ＵＥがＲｅｌ－８メカニズムに基づいて中状態を推定した場合，これは高状態として再分類され，ネットワークに報告される。このオプションでは，ＭＳＥを強化する必要はなく，ネットワークの意思決定に十分に役立つ。４番目のオプションは，ＵＥアイドルモードセル再選択履歴情報をネットワークに提供することである。ただし，このオプションでは高いシグナリングオーバーヘッドが発生し，ネットワークはこの情報を現在接続モードで使用しているのと同じ方法で使用する。上記の議論に基づいて，ＲＲＣ接続の確立中に提供されるモビリティ情報のオプションを要約する。 １．既存のＲｅｌ－８　ＭＳＥ（２ビット情報） ２．拡張ＭＳＥ（２ビット情報） ３．既存のＲｅｌ－８　ＭＳＥ（１ビット情報）に基づく簡素化された低／高モビリティ状態 ４．アイドルモードセル再選択履歴情報（より多くのビット数） 私たちの見解では，ネットワーク環境が同種の展開であるか異種の展開であるかに関係なく，ネットワークの意思決定のために，モビリティ情報に関する上記のすべてのオプションを提供できます。　既存のＲｅｌ－８　ＭＳＥまたはアイドルモードセルの再選択履歴情報を提供することは理にかなっていますが，既存のＲｅｌ－８　ＭＳＥを若干優先しています。） 上記（１）（２）の記載並びに当業者の技術常識を考慮すると，「ＵＥはアイドル中にモビリティ状態推定（ＭＳＥ）を実行し，ＵＥがアイドル状態から接続状態（コネクテッド）へ遷移すると，モビリティ状態をネットワークへ報告する。」ことは，周知技術であるといえる。 ５　対比 本願発明と引用発明とを対比すると，以下のことがいえる。 （１）本願発明の「ユーザ機器」と引用発明の「ＵＥ」は，表記が異なるのみであって差違はない。また，引用発明の「ＵＥは，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを使用してモビリティ情報の利用可能性を示し」との事項は，ＵＥがｅＮＢにＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを送信していることが明らかであるところ，当該メッセージはＵＥがＩＤＬＥからＣＯＮＮＥＣＴＥＤモードに移行するときに使用されるから，当該事項の前提として，ＵＥがＩＤＬＥからＣＯＮＮＥＣＴＥＤモードへの移行を確定していることは明らかである。したがって，両者は，「ユーザ機器がアイドル状態からコネクション状態への移行を確定すること」を含む点で一致している。 （２）引用発明の「ＵＥは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを使用してモビリティ情報を送信する」は，本願発明の「前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告すること」に対応する。ここで，引用発明の「モビリティ情報」は，「セルＩＤと滞在時間のリストから成る」から，本願発明の「ユーザ機器によるセル再選択の履歴情報である第２移動情報」に相当する。 したがって，両者は，「前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することとを含み，前記移動情報は，ユーザ機器によるセル再選択の履歴情報である第２移動情報を含」む点で共通する。 （３）引用発明は，ＵＥは，ネットワーク側機器といえるｅＮＢにモビリティ情報の利用可能性を示し，ｅＮＢからモビリティ情報の要求を受けてから，ｅＮＢにモビリティ情報を送信することが明らかであるところ，要求を受けてから送信することは，ｅＮＢによる受信が必要であると確定してから送信しているといえる。したがって，引用発明の「ｅＮＢは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔメッセージを使用してモビリティ情報を要求し，ＵＥは，ＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージを使用してモビリティ情報を送信する」は，本願発明の「前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することは，」「前記ユーザ機器が前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定してから，前記第２移動情報を前記ネットワーク側機器に報告することとを含み」に対応する。 また，モビリティ情報の利用可能性を示すことは，モビリティ情報を有しているか否かを示すことを含んでいるから，引用発明の「ＵＥは，ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを使用してモビリティ情報の利用可能性を示し」は，本願発明の「前記ユーザ機器は，前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定する前に，さらに，前記ユーザ機器が前記第２移動情報を有するか否かを示す情報をネットワーク側機器に報告すること」に対応する。 （４）上記（１）～（３）のとおりであるから，引用発明は「移動情報報告方法」といえる点で本願発明と差違はない。 以上を総合すると，本願発明と引用発明とは，以下の点で一致し，また，相違している。 （一致点） 「ユーザ機器がアイドル状態からコネクション状態への移行を確定することと， 前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することとを含み， 前記移動情報は， 前記ユーザ機器によるセル再選択の履歴情報である第２移動情報を含み， 前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告することは， 前記ユーザ機器が前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定してから，前記第２移動情報を前記ネットワーク側機器に報告することを含み， 前記ユーザ機器は， 前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定する前に，さらに，前記ユーザ機器が前記第２移動情報を有するか否かを示す情報を前記ネットワーク側機器に報告することを含む移動情報報告方法。」 （相違点） 本願発明の「移動情報」は「ユーザ機器による移動状態推定で確定される移動情報を示す情報である第１移動情報及び，ユーザ機器によるセル再選択の履歴情報である第２移動情報を含」むのに対し，引用発明の「モビリティ情報」は，本願発明の「ユーザ機器によるセル再選択の履歴情報である第２移動情報」に相当する「セルＩＤと滞在時間のリストから成る」点。これに伴い，「前記ユーザ機器が前記ユーザ機器の移動情報をネットワーク側機器に報告すること」が，本願発明は「ユーザ機器が第１移動情報をネットワーク側機器に報告すること」との事項も含んでいるのに対し，引用発明は当該事項を含んでいない点。 ６　判断 上記「第４　２」のとおり，「ＵＥはアイドル中にモビリティ状態推定（ＭＳＥ）を実行し，ＵＥがアイドル状態から接続状態（コネクテッド）へ遷移すると，モビリティ状態をネットワークへ報告する。」ことは周知技術である。 ここで，モビリティ状態推定（ＭＳＥ）で得られるモビリティ情報は，情報量としては少ないがＨｅｔｎｅｔ環境では正確でないこと，一方，セル再選択の履歴情報は，情報量は大きくなるが，より良い推定が行えること，は当業者に自明である。 そして，引用例２の「２．２　メッセージ内容」（上記「第４　１」参照）には解決策として「１．ＵＥはモビリティ状態をシグナルする」，「２．ＵＥはセルＩＤのリストと各セルで費やした時間をシグナルする」と記載されているように，どちらの情報も有用であるところ，有用な情報を両方とも利用するようにすることは当業者が適宜なし得ることである。また，システムの処理方法として情報量の少ない情報を先に取得し，その後必要であれば，詳細情報を取得するという処理方法も適宜用いられる処理方法である。 したがって，上記相違点は，当業者が適宜なし得ることである。 そして，本願発明の作用効果も，引用発明及び上記周知技術に基づいて当業者が予測できる範囲のものにすぎず，格別顕著なものとはいえない。 したがって，本願発明は，引用発明及び上記周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。 なお，上記「第３」の当審の拒絶理由通知について，請求人は，令和１年８月２日に提出された意見書において，「ユーザ機器が第１移動情報および第２移動情報をネットワーク側機器に報告することが必要である場合、当業者は、第１移動情報および第２移動情報を組み合わせてから一緒に報告するという技術案を容易に想到できますが、第１移動情報と第２移動情報を２回で報告することについての技術示唆を得ることができず、特に、「前記ユーザ機器が第１移動情報をネットワーク側機器に報告し、前記ユーザ機器が前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定してから、前記第２移動情報を前記ネットワーク側機器に報告する」という技術案を想到できません。」と主張している。 しかしながら，請求人が主張する「前記ユーザ機器が第１移動情報をネットワーク側機器に報告し、前記ユーザ機器が前記ネットワーク側機器による前記第２移動情報の受信が必要であると確定してから、前記第２移動情報を前記ネットワーク側機器に報告する」こと，すなわち，第１移動情報と第２移動情報の報告に時間的差異が存在することは本願発明の発明特定事項ではないから，請求人の主張は本願発明の構成に基づいたものではない。 このため，請求人の主張は採用できない。 第５　むすび 以上のとおり，本願発明は，引用発明及び周知技術に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない。 したがって，他の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 よって，結論のとおり審決する。