2016-011732

特願２０１４－５１８５５３「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）を利用するための装置、方法、コンピュータプログラム及び記憶媒体」拒絶査定不服審判事件〔平成２５年　１月１０日国際公開、ＷＯ２０１３／００６２１９、平成２６年　９月　８日国内公表、特表２０１４－５２３１８１〕について、次のとおり審決する。

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

【理　由】 第１　手続の経緯 本願は、２０１２年（平成２４年）３月２７日（パリ条約による優先権主張外国庁受理　２０１１年７月１日　米国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。 平成２６年２月２６日　　　手続補正書の提出 平成２７年１月１３日付け　拒絶理由の通知 平成２７年４月１５日　　　意見書及び手続補正書の提出 平成２７年９月１１日付け　拒絶理由（最後の拒絶理由）の通知 平成２７年１２月２１日　　意見書及び手続補正書の提出 平成２８年４月２１日付け　拒絶査定 平成２８年８月４日　　　　審判請求書、手続補正書の提出 平成２９年６月２３日付け　当審における拒絶理由の通知 平成２９年９月２５日　　　意見書及び手続補正書の提出 第２ 本願発明 本願の請求項１－１３に係る発明は、平成２９年９月２５日提出の手続補正書により補正された特許請求の範囲の請求項１－１３に記載された事項により特定されるものと認められるところ、その請求項６に係る発明（以下、「本願発明」という。）は、以下のとおりのものである。 「【請求項６】 マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置が、無線通信ネットワークを介してユーザ設備（ＵＥ）へ送信されるべきトリガペイロードを含むデバイストリガ要求メッセージをＳＣＳから第１のリファレンスポイントを介して受信するステップと、 前記トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求をＭＭＥ又はＳＧＳＮへ第２のリファレンスポイントを介して送信するステップと を有し、前記装置は、 前記無線通信ネットワークにより通信が確立される前に前記ＳＣＳを認証すること、 該ＳＣＳからの制御プレーン要求を許可すること、 ネットワークポリシーに基づいて、複数のデバイストリガ送出メカニズムのうちのデバイストリガ送出メカニズムを選択することであって、前記複数のデバイストリガ送出メカニズムの各々は前記トリガペイロードの送信が可能なルートを示す、こと、 前記第１のリファレンスポイント及び前記第２のリファレンスポイントを終端すること、 内部ＰＬＭＮトポロジを隠すこと、及び 該ＰＬＭＮにおいて特定の機能を呼び出すために前記第１のリファレンスポイント上で使用されるシグナリングプロトコルを中継又は変換すること を行うように構成されている、方法。」 第３　拒絶の理由 平成２９年６月２３日付けで当審が通知した拒絶理由のうちの理由２は、次のとおりのものである。 本件出願の請求項１－１２に係る発明は、その出願前日本国内または外国において頒布された又は電気通信回線を通じて公衆に利用可能となった以下の引用例１に記載された発明及び引用例２に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 引用例１：３ＧＰＰ　ＴＲ　２３．８８８　ｖ１．３．０（２０１１－０６）、２０１１年６月８日掲載、ｐ１－１４、ｐ２２－２３、ｐ３９－４１、ｐ１０７－１０９ 引用例２：Ｎｏｋｉａ　Ｓｉｅｍｅｎｓ　Ｎｅｔｗｏｒｋ、Ｎｏｋｉａ、“Ｄｅｖｉｃｅ　Ｔｒｉｇｇｅｒｉｎｇ”、３ＧＰＰ　ＴＳＧ　ＳＡ　ＷＧ２　Ｍｅｅｔｉｎｇ　＃８５、ＴＤ　Ｓ２－１１２５７２、２０１１年５月１１日掲載 第４　引用例及び引用発明 １．引用例１及び引用発明１ 当審の平成２９年６月２３日付け拒絶理由（以下、「当審拒絶理由」という。）で引用した３ＧＰＰ　ＴＲ　２３．８８８　ｖ１．３．０（２０１１－０６）、“３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ；　Ｔｅｃｈｎｉｃａｌ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｇｒｏｕｐ　Ｓｅｒｖｉｃｅｓ　ａｎｄ　Ｓｙｓｔｅｍ　Ａｓｐｅｃｔｓ；　Ｓｙｓｔｅｍ　Ｉｍｐｒｏｖｅｍｅｎｔｓ　ｆｏｒ　Ｍａｃｈｉｎｅ－Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ；（Ｒｅｌｅａｓｅ　１１）”、２０１１年６月８日掲載（以下、「引用例１」という。）には、次の事項が記載されている（下線は、当審で付した。以下、同じ。）。 （１）「4　Architectural Considerations 4.1　Architectural requirements （省略） 5)　The reference points between the MTC Server and the PLMN shall enable message exchange to support the following services: a. Device Triggering （省略） 4.3　Architectural Reference Model for MTC The end-to-end application, between the UE used for Machine Type Communication (MTC) and the MTC Application, uses services provided by the 3GPP system, and optionally services provided by an MTC Server. The 3GPP system provides transport and communication services (including 3GPP bearer services, IMS and SMS) including various optimizations that can facilitate MTC. Figure 4.3-1 shows a UE used for MTC connecting to the 3GPP network (UTRAN, E-UTRAN, GERAN, I-WLAN, etc) via the Um/Uu/LTE-Uu interface.（省略） 4.4.2　MTC-IWF To support the Indirect and Hybrid models of MTC, one or more instances of an MTC InterWorking Function (MTC-IWF) reside in the HPLMN. An MTC-IWF could be a standalone entity or a functional entity of another network element. The MTC-IWF hides the internal PLMN topology and relays or translates signaling protocols used over MTCsp to invoke specific functionality in the PLMN. The functionality of the MTC-IWF includes the following: -　terminates the MTCsp reference point; -　may authenticate the MTC Server before communication establishment with the 3GPP network; -　may authorize control plane requests from an MTC Server; （省略） 4.5.2　List of Reference Points The description of the MTC related reference points: （省略） MTCsp:　It is the reference point an entity outside the 3GPP system uses to communicate with the MTC-IWF related control plane signalling. （省略） 4.8.2　Control plane 4.8.2.1　MTC Server-MTC-IWF MTCsp reference point Figure 4.8.2.1-1: MTCsp protocol stack for Machine Type Communication architecture NOTE 1: The MTCsp reference point can map to a protocol or number of protocols.」（第７ページ第１７行～第１３ページ下から７行目） （当審訳：「４　アーキテクチャの検討 ４．１　アーキテクチャの要件 （省略） ５）　ＭＴＣサーバとＰＬＭＮとの間のリファレンスポイントは、下記のサービスをサポートするためのメッセージ交換を可能にする。 ａ．デバイストリガリング （省略） ４．３　ＭＴＣのためのアーキテクチャの参照モデル マシンタイプコミュニケーション（ＭＴＣ）用ＵＥとＭＴＣアプリケーションとの間のエンドツーエンドアプリケーションは、３ＧＰＰシステムによって提供されるサービス、及びＭＴＣサーバによって提供される任意のサービスを使用する。３ＧＰＰシステムは、ＭＴＣを容易にすることができる様々な最適化を含むトランスポート及びコミュニケーションサービス（３ＧＰＰベアラサービス、ＩＭＳ及びＳＭＳを含む。）を提供する。 図４．３－１は、Ｕｍ／Ｕｕ／ＬＴＥ－Ｕｕインターフェイスを介して３ＧＰＰネットワーク（ＵＴＲＡＮ、Ｅ－ＵＴＲＡＮ、ＧＥＲＡＮ、Ｉ－ＷＬＡＮ等）に接続されているＭＴＣ用ＵＥを示す。（省略） ４．４．２　ＭＴＣ－ＩＷＦ ＭＴＣの間接的及びハイブリッドモデルをサポートするために、ＭＴＣ網間接続機能（ＭＴＣ－ＩＷＦ）の１つ以上のインスタンスがＨＰＬＭＮ内に存在する。ＭＴＣ－ＩＷＦは、スタンドアロンのエンティティ又は他のネットワーク要素の機能的なエンティティであることができる。ＭＴＣ－ＩＷＦは、内部ＰＬＭＮトポロジを隠し、ＰＬＭＮにおいて特定の機能を呼び出すために、ＭＴＣｓｐ上で使用されるシグナリングプロトコルを中継又は変換する。 ＭＴＣ－ＩＷＦの機能は、以下を含む。 －　ＭＴＣｓｐリファレンスポイントを終端する。 －　３ＧＰＰネットワークとの通信確立前にＭＴＣサーバを認証してもよい。 －　ＭＴＣサーバから制御プレーンの要求を許可してもよい。 （省略） ４．５．２　リファレンスポイントのリスト ＭＴＣに関連するリファレンスポイントの説明 （省略） ＭＴＣｓｐ：３ＧＰＰシステムの外部エンティティが、制御プレーンシグナリングに関連してＭＴＣ－ＩＷＦと通信するために使用するリファレンスポイント （省略） ４．８．２　制御プレーン ４．８．２．１　ＭＴＣサーバ－ＭＴＣ―ＩＷＦ　ＭＴＣｓｐリファレンスポイント ノート１：ＭＴＣｓｐリファレンスポイントは、プロトコル又は複数のプロトコルにマッピングできる。」） （２）「5　Description of envisioned System Improvements for Machine Type Communication, use cases （省略） 5.8　Key Issue - MTC Device Trigger （省略） 5.8.2　Required Functionality The following functionality is required to trigger MTC Devices: （省略） -　A MTC Device shall be able to receive trigger indications from the network and establish communication with the MTC server when receiving the trigger indication. Possible options are: -　Receiving trigger indication in detached state and establish communication. -　Receiving trigger indication in attached state and the MTC device has no PDP/PDN connection. -　Receiving trigger indication in attached state and the MTC device has a PDP/PDN connection.」（第１４ページ第４行～第２２ページ下から５行） （当審訳：「５　マシンタイプコミュニケーションのための想定されるシステム改善の説明、使用事例 （省略） ５．８　主要問題　－　ＭＴＣデバイストリガ （省略） ５．８．２　要求される機能 （省略） ＭＴＣデバイスをトリガするために、以下の機能が要求される。 （省略） －　ＭＴＣデバイスは、ネットワークからトリガインジケーションを受信でき、トリガインジケーションを受信した時は、ＭＴＣデバイスとの通信を確立できなければならない。可能な選択肢は； －　デタッチ状態でトリガインジケーションを受信、通信を確立。 －　アタッチ状態でトリガインジケーションを受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有していない。 －　アタッチ状態でトリガインジケーションを受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有する。」 （３）「6　Solutions （省略） 6.45　Solution - Device trigger gateway solution （省略） 6.45.2　General This solution shows how the key issue MTC Device Trigger can be achieved using a new simple Device Trigger Gateway (DT-GW) in the HPLMN in combination with several services provided in the existing standards. （省略） A DT-GW could be a standalone physical entity or a functional entity. （省略） At any given point of time, there is at least one globally routable DT-GW assigned for each subscribed MS/UE that supports the MTC device trigger feature. A DT-GW terminates an MTCsp interface for reception of trigger indications from a submitting node (e.g. an authorized MTC server or IWK function on behalf of the MTC server). The MTC server is configured with a DT-GW IP address and optionally the SRC and DST ports to be used to transmit a trigger indication for a particular UE used for MTC. Alternatively, the DT-GW information for a particular subscribed device could be made available and determined through DNS mechanisms. The MTC server sends a trigger indication request to the appropriate DT-GW encapsulated in an IP packet. The trigger indication request could contain pertinent information needed to route the trigger (e.g. device subscriber identity, trigger command/arguments, relevant device location information, security parameters, etc.). When a trigger indication is received from a submitting node, the DT-GW should first authorize the received request; making sure it originated from a trusted MTC server and is targeted for a device for which the MTC server is authorized to trigger. The next step is for the DT-GW to determine the reachability of the UE used for MTC. Per the requirements specified in clause 5.8, a trigger-able UE used for MTC can be received in the detached state, in the attached state without a publically routable PDP context/PDN connection and in the attached state with a publically routable PDP context / PDN connection. To determine “how” reachable the device is, the DT-GW interrogates the HLR/HSS using the C and/or Sh interface. The DT-GW uses the reachability information obtained from the HLR/HSS, the GGSN/P-GW Radius/Diameter interface (as described in clause 16 of TS 29.061 [4]) and MNO configured policy information to determine the most efficient and effective service and route to use for forwarding of the trigger indication to be delivered to the UE used for MTC. Some trigger delivery services that could be considered are shown in Figure 6.45.2-1, for which the DT-GW reformats, as needed, and forwards the trigger indication to the appropriate: a)　GGSN/P-GW for delivery over an already established PDP context / PDN connection; b)　GGSN for delivery over a newly established PDP context (via a Network-Requested PDP Context Activation Procedure initiated by the DT-GW); c)　S-CSCF for delivery over SIP/IMS service; d)　SMS-SC for delivery over SMS; or e)　CBC for broadcast delivery over CBS (assumes location information available in trigger indication request or from other source in order to limit the broadcast area). When a globally routable PDP context / PDN connection is pre-established in the UE used for MTC (as described in bullet a) or is newly established (as described in bullet b), the DT-GW utilizes this connection to forward trigger indications using IP-based communications.（省略） The DT-GW functionality includes the following: -　ingress of trigger indication messages into the PLMN; -　authorization that the trigger indication is from a trusted MTC server; -　authorization that the UE used for MTC addressed in a trigger indication is from a MTC server that is authorized to trigger the addressed UE used for MTC; -　selection of the delivery service and route to forward the trigger indication to for delivery to the UE used for MTC (e.g. based on collected reachability information and network operator policy); -　reformatting, as needed, of the trigger indication payload to match the format required for the selected delivery service; - 　egress of trigger indication from the DT-GW to the to the selected delivery service entity for delivery to the UE used for MTC; （省略）」（第３６ページ下から１０行目、第１０７ページ下から６行目～第１０９ページ第２４行） （当審訳：「６　解決策 （省略） ６．４５　解決策　－　デバイストリガ　ゲートウェイ　ソリューション （省略） ６．４５．２　一般 この解決策は、主要課題であるＭＴＣデバイスのトリガが、既存の標準において提供されるいくつかのサービスと組み合わせて、ＨＰＬＭＮにおいて新しいシンプルなデバイストリガ　ゲートウェイ（ＤＴ－ＧＷ）を用いて達成されることを示している。（省略） ＤＴ－ＧＷは、スタンドアロンの物理的エンティティまたは機能的エンティティであってもよい。（省略） 任意の所与の時点において、各加入ＭＳ／ＵＥのために割り当てられた少なくとも１つのグローバルにルーティング可能なＤＴ－ＧＷがあり、ＭＴＣデバイストリガ機能をサポートする。ＤＴ－ＧＷは、送信側ノード（例えば、許可されたＭＴＣサーバ又はそのＭＴＣサーバに代わるＩＷＫ機能）からのトリガ指示を受信するためのＭＴＣｓｐインタフェースを終端する。ＭＴＣサーバは、ＤＴ－ＧＷ　ＩＰアドレス及び、場合により特定のＭＴＣ用ＵＥのためのトリガー指示を送信するために使用されるＳＲＣ及びＤＳＴポートで構成される。代替として、特定の加入済みデバイスのＤＴ－ＧＷ情報が利用可能にされ、ＤＮＳメカニズムを介して決定することができる。ＭＴＣサーバは、ＩＰパケット内にカプセル化された、適切なＤＴ－ＧＷ宛てのトリガー指示要求を送信する。トリガー指示要求は、トリガをルーティングするために必要な適切な情報を含むことができる（例えば、デバイス加入者識別情報、トリガ命令／引数、関連デバイス位置情報、セキュリティパラメータ、等）。 送信側ノードからトリガ指示を受信すると、ＤＴ－ＧＷは、まず受信した要求を認証する；それが信用できるＭＴＣサーバからのものであり、ＭＴＣサーバがトリガすることを許可されたデバイスに宛てたものかを確認する。ＤＴ－ＧＷの次の工程は、ＭＴＣ用ＵＥの到達可能性を決定することである。第５．８節に特定される要件によって、トリガ可能なＭＴＣ用ＵＥは、デタッチ状態の場合、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがない場合、及び、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがある場合に、受信されることができる。デバイスが「どのように」到達可能であるかを決定するために、ＤＴ－ＧＷがＣ及び／又はＳｈインタフェースを使用してＨＬＲ／ＨＳＳに問い合わせを行う。 ＤＴ－ＧＷは、ＭＴＣ用ＵＥに届けられるトリガ指示を転送するのに使用する最も効率的かつ効果的なサービス及びルートを決定するために、ＨＬＲ／ＨＳＳ、（ＴＳ２９．０６１［４］の第１６節に記載された）ＧＧＳＮ／Ｐ－ＧＷ　Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒインタフェース及びＭＮＯが構成したポリシー情報から得られた到達可能性情報を使用する。考えられ得るいくつかのトリガ配信サービスは、図６．４５．２－１に示され、必要に応じて、ＤＴ－ＧＷは再フォーマットを行い、以下ａ）～ｅ）のうちの適切なものにトリガー指示を転送する。 ａ）　ＧＧＳＮ／Ｐ－ＧＷ、既に確立されたＰＤＰコンテキスト／ＰＤＮコネクションを介した配信のため ｂ）　ＧＧＳＮ、（ＤＴ－ＧＷによって開始されたネットワーク要求ＰＤＰコンテキスト起動手順を介して）新たに確立されるＰＤＰコンテキストを介した配信のため ｃ）　Ｓ－ＣＳＣＦ、ＳＩＰ／ＩＭＳサービスを介した配信のため ｄ）　ＳＭＳ－ＳＣ、ＳＭＳを介した配信のため ｅ）　ＣＢＣ、（放送エリアを制限するために、トリガー指示要求においてまたは他の供給源から位置情報が利用可能であると仮定し）ＣＢＳを介したブロードキャスト配信のため グローバルにルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションが、（上記ａに記載のように）ＭＴＣ用ＵＥにおいて事前に確立されている、または、（上記ｂに記載したように）新たに確立される場合、ＤＴ－ＧＷは、ＩＰベースの通信を使用してトリガー指示を転送するためにこのコネクションを利用する。（省略） ＤＴ－ＧＷ機能は、以下を含む。 －　ＰＬＭＮへのトリガー指示メッセージの入り口 －　トリガー指示が信頼されるＭＴＣサーバーからのものであることの認証 －　トリガー指示にアドレス指定されたＭＴＣ用ＵＥが、当該アドレス指定されたＭＴＣ用ＵＥをトリガすることを許可されているＭＴＣサーバーからのものであることの認証 －　ＭＴＣ用ＵＥへの配信のために、（例えば、収集された到達可能性情報及びネットワークオペレータポリシーに基づいて）トリガー指示を転送するための配信サービス及びルートの選択 －　必要に応じ、選択された配信サービスのために必要なフォーマットに一致させるための、トリガー指示ペイロードの再フォーマット －　ＭＴＣ用ＵＥへの配信のために、ＤＴ－ＧＷから選択された配信サービスエンティティへのトリガー指示の出口、及び（省略）」） （４）Ｆｉｇｕｒｅ ４．３．１、Ｆｉｇｕｒｅ ４．８．２．１－１及びＦｉｇｕｒｅ　６．４５．２－１は以下のとおりである。 Figure 4.3-1: 3GPP Architecture for Machine-Type Communication（当審訳：「図４．３．１：マシンタイプコミュニケーションのための３ＧＰＰアーキテクチャ」） Figure 4.8.2.1-1: MTCsp protocol stack for Machine Type Communication architecture（当審訳：「図４．８．２．１－１：マシンタイプコミュニケーション・アーキテクチャのためのＭＴＣｓｐプロトコルスタック」） Figure 6.45.2-1: MTC device trigger gateway architecture（当審訳：「図６．４５．２－１：ＭＴＣデバイストリガ　ゲートウェイ　アーキテクチャー」） 引用例１は、３ＧＰＰの「Ｓｙｓｔｅｍ　Ｉｍｐｒｏｖｅｍｅｎｔｓ　ｆｏｒ　Ｍａｃｈｉｎｅ－Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（リリース１１）」（ＳＩＭＴＣ／Ｒｅｌ－１１）に関する標準規格文書（バージョン１．３．０）であり、その第４章（アーキテクチャの検討）の４．４．２で、ＭＴＣのためのアーキテクチャの参照モデルとして「ＭＴＣ－ＩＷＦ」を示し、第５章（マシンタイプコミュニケーションのための想定されるシステム改善の説明、使用事例）で主要問題（「５．８　主要問題　－　ＭＴＣデバイストリガ」等を含む。）を列挙した上で、第６章で解決策（「６．４５　解決策　－　デバイストリガ　ゲートウェイ　ソリューション」を含む。）を列挙したものである。 そして、上記（１）～（４）の記載及び当業者の技術常識を考慮すると、 ア　上記（１）の記載によれば、ＭＴＣ用ＵＥは、３ＧＰＰネットワーク（ＵＴＲＡＮ、Ｅ－ＵＴＲＡＮ、ＧＥＲＡＮ、Ｉ－ＷＬＡＮ等）に接続されてており、ＭＴＣサーバとＭＴＣ－ＩＷＦとの間のＭＴＣｓｐリファレンスポイントは、デバイストリガリングをサポートするためのメッセージ交換を可能にする。 また、図４．３．１は、ＭＴＣのための３ＧＰＰアーキテクチャであり、上記（１）の４．４．２の記載によれば、図４．３．１に記載された「ＭＴＣ－ＩＷＦ」は、スタンドアロンのエンティティ又は他のネットワーク要素の機能的なエンティティであって、 ＭＴＣ－ＩＷＦは、内部ＰＬＭＮトポロジを隠し、 ＰＬＭＮにおいて特定の機能を呼び出すために、ＭＴＣｓｐ上で使用されるシグナリングプロトコルを中継又は変換するものであり、 ＭＴＣｓｐリファレンスポイントを終端し、 ３ＧＰＰネットワークとの通信確立前にＭＴＣサーバを認証し、ＭＴＣサーバから制御プレーンの要求を許可する機能を有する。 イ　上記（３）及び（４）の図６．４５．２－１の記載によれば、「６．４５　解決策　－　デバイストリガ　ゲートウェイ　ソリューション」として示された「デバイストリガ　ゲートウェイ（ＤＴ－ＧＷ）」は、上記第４節に記載されたＭＴＣ－ＩＷＦを実現するための解決策として示されたものであって、ＭＴＣ－ＩＷＦと同様に（上記ア参照）、内部ＰＬＭＮトポロジを隠し、ＰＬＭＮにおいて特定の機能を呼び出すために、ＭＴＣｓｐ上で使用されるシグナリングプロトコルを中継又は変換するものといえる。 そして、上記（３）の記載によれば、「ＤＴ－ＧＷ」は、ＨＰＬＭＮにおいて、既存の標準において提供されるいくつかのサービスと組み合わせて、ＭＴＣデバイストリガを達成するものであり、 スタンドアロンの物理的エンティティ又は機能的エンティティであってよく、 ＭＴＣｓｐインタフェースを終端し、 ＭＴＣサーバから送信されるＩＰパケット内にカプセル化された、適切なＤＴ－ＧＷ宛てのトリガー指示要求であって、トリガをルーティングするために必要な適切な情報（例えば、デバイス加入者識別情報、トリガ命令／引数、関連デバイス位置情報、セキュリティパラメータ、等）を含むトリガ指示要求をＭＴＣｓｐインタフェースを介して受信する。 そうすると、ＭＴＣｓｐインタフェースは、上記（１）の「４．４．２　ＭＴＣ－ＩＷＦ」に記載されたＭＴＣｓｐリファレンスポイントと同義であるから、前記ＤＴ－ＧＷは、ＭＴＣｓｐリファレンスポイントを終端するといえ、ＤＴ－ＧＷがＭＴＣサーバからＭＴＣｓｐリファレンスポイントを介して受信するトリガ指示要求は、ＭＴＣサーバとＤＴ－ＧＷとの間で交換されるデバイストリガリングをサポートするためのメッセージであって、トリガをルーティングするために必要な適切な情報（例えば、デバイス加入者識別情報、トリガ命令／引数、関連デバイス位置情報、セキュリティパラメータ、等）を含み、３ＧＰＰネットワークに接続されたＭＴＣ用ＵＥへのデバイストリガリングを行うための要求といえる。 また、ＤＴ－ＧＷは、トリガー指示ペイロードの再フォーマットを行う機能を有するとしていることから、上記ＭＴＣサーバからのトリガ指示要求には、トリガー指示に係るペイロードが含まれるといえる。 ウ　上記（３）及び（４）の図６．４５．２－１の記載によれば、ＤＴ－ＧＷは、ＭＴＣサーバからトリガ指示を受信すると、まず受信した要求を認証し、それが信用できるＭＴＣサーバからのものであり、ＭＴＣサーバがトリガすることを許可されたデバイスに宛てたものかを確認し、 次に、ＭＴＣ用ＵＥの到達可能性を決定し、ここにおいて、第５．８節に特定される要件によれば、トリガ可能なＭＴＣ用ＵＥは、デタッチ状態の場合、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがない場合、及び、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがある場合に、受信されることができ、 ＨＬＲ／ＨＳＳ、（ＴＳ２９．０６１［４］の第１６節に記載された）ＧＧＳＮ／Ｐ－ＧＷ　Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒインタフェース及びＭＮＯが構成したポリシー情報から得られた到達可能性情報を使用して、ＭＴＣ用ＵＥに届けられるトリガ指示を転送するのに使用する最も効率的かつ効果的なサービスおよびルートを決定し、必要に応じて、ＤＴ－ＧＷは再フォーマットを行い、以下ａ）～ｅ）のいずれかにトリガー指示を転送する。 ａ）　ＧＧＳＮ／Ｐ－ＧＷ、既に確立されたＰＤＰコンテキスト／ＰＤＮコネクションを介した配信のため ｂ）　ＧＧＳＮ、（ＤＴ－ＧＷによって開始されたネットワーク要求ＰＤＰコンテキスト起動手順を介して）新たに確立されるＰＤＰコンテキストを介した配信のため ｃ）　Ｓ－ＣＳＣＦ、ＳＩＰ／ＩＭＳサービスを介した配信のため ｄ）　ＳＭＳ－ＳＣ、ＳＭＳを介した配信のため ｅ）　ＣＢＣ、（放送エリアを制限するために、トリガー指示要求においてまたは他の供給源から位置情報が利用可能であると仮定し）ＣＢＳを介したブロードキャスト配信のため。 そして、ＤＴ－ＧＷは、以下の機能を有するものである。 －　ＰＬＭＮへのトリガー指示メッセージの入り口 －　トリガー指示が信頼されるＭＴＣサーバーからのものであることの認証 －　トリガー指示にアドレス指定されたＭＴＣ用ＵＥが、当該アドレス指定されたＭＴＣ用ＵＥをトリガすることを許可されているＭＴＣサーバーからのものであることの認証 －　ＭＴＣ用ＵＥへの配信のために、（例えば、収集された到達可能性情報及びネットワークオペレータポリシーに基づいて）トリガー指示を転送するための配信サービス及びルートの選択 －　必要に応じ、選択された配信サービスのために必要なフォーマットに一致させるための、トリガー指示ペイロードの再フォーマット －　ＭＴＣ用ＵＥへの配信のために、ＤＴ－ＧＷから選択された配信サービスエンティティへのトリガー指示の出口 エ　図６．４５．２－１の記載によれば、ＤＴ－ＧＷは、デバイストリガをＭＴＣサーバからＭＴＣｓｐインタフェースを介して受信し、上記ａ）～ｅ）から選択される配信サービス及びルートを介してＳＧＳＮ／ＭＭＥへ送信することが認められる。 上記ア～エを総合すると、引用例１には、３ＧＰＰの「Ｓｙｓｔｅｍ　Ｉｍｐｒｏｖｅｍｅｎｔｓ　ｆｏｒ　Ｍａｃｈｉｎｅ－Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（リリース１１）」（ＳＩＭＴＣ／Ｒｅｌ－１１）において検討中の「ＭＴＣ－ＩＷＦ」を実現するための解決策として示された、次の発明（以下、「引用発明１」という。）が記載されていると認める。 「ＭＴＣ－ＩＷＦを実現するための解決策として示されたＤＴ－ＧＷが、３ＧＰＰネットワークに接続されたＭＴＣ用ＵＥへのデバイストリガリングを行うためのメッセージである、トリガ指示に係るペイロードを含むトリガ指示要求をＭＴＣサーバからＭＴＣｓｐリファレンスポイントを介して受信し、 ＭＴＣサーバからトリガ指示を受信すると、まず受信した要求を認証し、それが信用できるＭＴＣサーバからのものであり、ＭＴＣサーバがトリガすることを許可されたデバイスに宛てたものかを確認し、 次に、ＭＴＣ用ＵＥの到達可能性を決定し、ここにおいて、第５．８節に特定される要件によれば、トリガ可能なＭＴＣ用ＵＥは、デタッチ状態の場合、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがない場合、及び、アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがある場合に、受信されることができ、 ＨＬＲ／ＨＳＳ、（ＴＳ２９．０６１［４］の第１６節に記載された）ＧＧＳＮ／Ｐ－ＧＷ　Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒインタフェース及びＭＮＯが構成したポリシー情報から得られた到達可能性情報を使用して、ＭＴＣ用ＵＥに届けられるトリガ指示を転送するのに使用する最も効率的かつ効果的なサービスおよびルートを決定し、 再フォーマットを行い、 トリガー指示を、以下の ａ）　ＧＧＳＮ／Ｐ－ＧＷ、既に確立されたＰＤＰコンテキスト／ＰＤＮコネクションを介した配信のため ｂ）　ＧＧＳＮ、（ＤＴ－ＧＷによって開始されたネットワーク要求ＰＤＰコンテキスト起動手順を介して）新たに確立されるＰＤＰコンテキストを介した配信のため ｃ）　Ｓ－ＣＳＣＦ、ＳＩＰ／ＩＭＳサービスを介した配信のため ｄ）　ＳＭＳ－ＳＣ、ＳＭＳを介した配信のため ｅ）　ＣＢＣ、（放送エリアを制限するために、トリガー指示要求においてまたは他の供給源から位置情報が利用可能であると仮定し）ＣＢＳを介したブロードキャスト配信のため から選択される配信サービス及びルートを介してＳＧＳＮ／ＭＭＥへ送信する、方法であって、 前記ＤＴ－ＧＷは、ＭＴＣｓｐリファレンスポイントを終端し、 内部ＰＬＭＮトポロジを隠し、 ＰＬＭＮにおいて特定の機能を呼び出すために、ＭＴＣｓｐ上で使用されるシグナリングプロトコルを中継又は変換し、 前記ＤＴ－ＧＷは、以下の機能を有する、 －　ＰＬＭＮへのトリガー指示メッセージの進入 －　トリガー指示が信頼されるＭＴＣサーバーからのものであることの認証、 －　トリガー指示にアドレス指定されたＭＴＣ用ＵＥが、アドレス指定されたＭＴＣ用ＵＥをトリガすることを許可されているＭＴＣサーバーからのものであることの認証、 －　ＭＴＣ用ＵＥへの配信のために、（例えば、収集された到達可能性情報及びネットワークオペレータポリシーに基づいて）トリガー指示を転送するための配信サービス及びルートの選択、 －　必要に応じ、選択された配信サービスのために必要なフォーマットに一致させるための、トリガー指示ペイロードの再フォーマット、 －　ＭＴＣ用ＵＥへの配信のために、ＤＴ－ＧＷから選択された配信サービスエンティティへのトリガー指示の出口、 方法」 ２．引用例２及び引用発明２ 当審拒絶理由で引用したＮｏｋｉａ　Ｓｉｅｍｅｎｓ　Ｎｅｔｗｏｒｋ、Ｎｏｋｉａ、“Ｄｅｖｉｃｅ　Ｔｒｉｇｇｅｒｉｎｇ”、３ＧＰＰ　ＴＳＧ　ＳＡ　ＷＧ２　Ｍｅｅｔｉｎｇ　＃８５、ＴＤ　Ｓ２－１１２５７２、２０１１年５月１１日掲載（以下、「引用例２」という。）には、図面とともに次の事項が記載されている。 （１）「Work Item / Release:　SIMTC / Rel-11 Abstract of the contribution: This contribution provides a solution for device triggering when the device is attached but has no PDP context / PDN connection and no MSISDN is available.」（第１ページ第８行～第９行） （当審訳：「作業アイテム／リリース：ＳＩＭＴＣ／Ｒｅｌ－１１ 寄書の要約：この寄書は、デバイスがアタッチされているが、ＰＤＰコンテキスト／ＰＤＮコネクションを有しておらず、ＭＳＩＳＤＮが利用可能でない場合のデバイストリガのための解決策を提供する。」） （２）「5.8　Key Issue - MTC Device Trigger （省略） 5.8.2　Required Functionality The following functionality is required to trigger MTC Devices: -　The PLMN shall be able to trigger MTC Devices to initiate communication with the MTC Server based on a trigger indication from the MTC server. （省略） -　A MTC Device shall be able to receive trigger indications from the network and establish communication with the MTC server when receiving the trigger indication. Possible options are: -　Receiving trigger indication in detached state and establish communication. -　Receiving trigger indication in attached state and the MTC device has no PDP/PDN connection. -　Receiving trigger indication in attached state and the MTC device has a PDP/PDN connection.」（第２ページ第１行～第２４行） （当審訳：「５．８　主要課題－　ＭＴＣデバイス　トリガ （省略） ５．８．２　要求される機能 ＭＴＣデバイスをトリガするために、以下の機能が要求される。 －　ＰＬＭＮは、ＭＴＣサーバからのトリガ指示に基づいて、ＭＴＣサーバとの通信を開始するようＭＴＣデバイスをトリガできなければならない。 （省略） －　ＭＴＣデバイスは、ネットワークからトリガ指示を受信でき、トリガ指示を受信した時は、ＭＴＣデバイスとの通信を確立できなければならない。可能な選択肢は； －　デタッチ状態でトリガ指示を受信、通信を確立。 －　アタッチ状態でトリガ指示を受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有していない。 －　アタッチ状態でトリガ指示を受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有する。」） （３）「6.xx　Solution - Device Triggering （省略） 6.xx.3　Device Triggering Alternative 1: This alternative assumes the external device identifier used by the MTC server is stored in the subscription information, the MTC-IWF can determine the correct HSS based on configuration and the HSS returns the IMSI based on the external device identifier. It is also assumed that the MTC IWF has a direct interface with the SGSN serving the MTC device. Step 1: MTC server initiates a Device Trigger request for the UE and provides the external device identifier. Step 2: MTC-IWF receives the request, determines the HSS based on the external device identifier and configuration data and requests the HSS to reply with the IMSI and SGSN address. Step 3: HSS replies with IMSI and serving SGSN address to MTC-IWF. Step 4: MTC-IWF forwards the Device Trigger request with IMSI to the SGSN. Step 5: SGSN pages the MTC device either using its temporary identifier or using its IMSI. Step 6, 7: The MTC device responds to the network with the Service Request procedure and establishes a PDN connection with the GGSN/PGW to connect to the MTC server. （省略） Alternative 3: This alternative can also be considered as an optimized call flow for Alternative 1. It assumes that the MTC-IWF stores the serving SGSN information, external device identifier mapping to IMSI that it retrieved from the HSS. It is also assumes that the MTC IWF has a direct interface with the SGSN serving the device. The call flow steps are similar to Alternative 1 except for the missing steps 2, 3 that are optimized as the MTC-IWF stores the previously retrieved mapping information.」（第３ページ第１行～第４ページ第１３行） （当審訳：「６．ｘｘ　解決策　－　デバイストリガリング （省略） ６．ｘｘ．３　デバイストリガリング 選択肢１： この選択肢は、ＭＴＣサーバにより使用される外部デバイス識別子が加入者情報に格納され、ＭＴＣ－ＩＷＦは、構成に基づいて正しいＨＳＳを決定することができ、ＨＳＳは、外部デバイス識別子に基づいてＩＭＳＩを返すものと仮定する。また、ＭＴＣ－ＩＷＦは、ＭＴＣデバイスにサービスを提供するＳＧＳＮとの直接のインターフェイスを有するものとする。 ステップ１：ＭＴＣサーバは、ＵＥのためのデバイストリガ要求を開始し、外部デバイス識別子を提供する。 ステップ２：ＭＴＣ－ＩＷＦは、上記要求を受信し、外部デバイス識別子及び構成データに基づいてＨＳＳを決定し、ＨＳＳにＩＭＳＩ及びＳＧＳＮアドレスを返信するよう要求する。 ステップ３：ＨＳＳは、ＭＴＣ－ＩＷＦへ、ＩＭＳＩ及びサービングＳＧＳＮアドレスを返信する。 ステップ４：ＭＴＣ－ＩＷＦは、ＳＧＳＮへ、ＩＭＳＩと共にデバイストリガ要求を送信する。 ステップ５：ＳＧＳＮは、一時的な識別子またはＩＭＳＩのいずれかを用いて、ＭＴＣデバイスをページングする。 ステップ６、７：ＭＴＣデバイスは、サービス要求手順を用いてネットワークに応答し、ＭＴＣサーバに接続するために、ＧＧＳＮ／ＰＧＷとのＰＤＮコネクションを確立する。 （省略） 選択肢３： この選択肢は、選択肢１について最適化されたコールフローとみなすこともできる。ＭＴＣ－ＩＷＦは、サービングＳＧＳＮ情報、ＨＳＳから取り出されたＩＭＳＩにマッピングされた外部デバイス識別子を記憶すると仮定する。また、ＭＴＣ－ＩＷＦは、デバイスにサービスを提供するＳＧＳＮとの直接的なインターフェイスを有すると仮定している。コールフローのステップは、ＭＴＣ－ＩＷＦが予め検索されたマッピング情報を格納するように最適化されていてステップ２、３がないことを除いて、選択肢１と同様である。」） （４）第３ページの選択肢１として示された図は、以下のとおりである。 引用例１は、上記のとおり、３ＧＰＰの「ＳＩＭＴＣ／Ｒｅｌ－１１」に関する標準規格文書（バージョン１．３．０）である。 そして、引用例２は、上記（１）～（３）の記載によれば、当該ＳＩＭＴＣ／Ｒｅｌ－１１に向けた寄書であって、ＳＩＭＴＣ／Ｒｅｌ－１１の第５．８節（主要課題　ＭＴＣデバイストリガ）の「５．８．２　要求される機能」に特定される要件のうち、「アタッチ状態でトリガインジケーションを受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有していない」場合におけるデバイストリガリングに関する解決策（「６．ｘｘ　解決策－デバイストリガリング」）を開示したものであることは当業者に自明である。 また、上記（３）及び（４）の記載によれば、選択肢１及び３において、ＭＴＣ－ＩＷＦは、ＭＴＣデバイスにサービスを提供するＳＧＳＮとの直接のインターフェイスを有しており、ＭＴＣ－ＩＷＦは、ＭＴＣサーバからＵＥのためのデバイストリガ要求を受信し、前記ＵＥのためのデバイストリガ要求をＭＴＣデバイス（ＵＥ）に対応したＩＭＳＩとともに、当該インターフェイスを介してＳＧＳＮに直接送信する。 ここで、ＭＴＣ－ＩＷＦとＭＴＣデバイスにサービスを提供するＳＧＳＮとの間の直接のインターフェイスは、ＭＴＣ－ＩＷＦが、ＭＴＣデバイスにサービスを提供するＳＧＳＮとの通信に用いるリファレンスポイントということができ、ＭＴＣ－ＩＷＦは、当該リファレンスポイントを終端しているといえる。 そうすると、引用例２には、ＳＩＭＴＣ／Ｒｅｌ－１１の第５．８節（主要課題　ＭＴＣデバイストリガ）の「５．８．２　要求される機能」に特定される要件のうち、「アタッチ状態でトリガ指示を受信、ＭＴＣデバイスはＰＤＰ／ＰＤＮコネクションを有していない」場合におけるデバイストリガリングに関する解決策として、次の発明（以下、「引用発明２」という。）が記載されていると認める。 「ＭＴＣサーバからのデバイストリガ要求に基づくＭＴＣデバイス（ＵＥ）のトリガリングに関する方法であって、 ＭＴＣ－ＩＷＦは、ＭＴＣデバイスにサービスを提供するＳＧＳＮとの通信に用いるリファレンスポイントを終端しており、 ＭＴＣ－ＩＷＦが、ＭＴＣサーバからＵＥのためのデバイストリガ要求を受信し、前記ＵＥのためのデバイストリガ要求をＭＴＣデバイス（ＵＥ）に対応したＩＭＳＩとともに、当該リファレンスポイントを介してＳＧＳＮに直接送信する、方法」 第５　対比 （１）引用発明１の「ＭＴＣサーバ」は、本願明細書の「幾つかの実施形態において、ＭＴＣサーバ５２はＳＣＳ（Services　Capability　Server）と呼ばれることがある。」（【００２１】）の記載からみて、本願発明の「ＳＣＳ」に相当するといえ、引用発明１の「ＭＴＣｓｐリファレンスポイント」、「３ＧＰＰネットワーク」及び「ＭＴＣ用ＵＥ」は、それぞれ本願発明の「第１のリファレンスポイント」、「無線通信ネットワーク」及び「ユーザ設備（ＵＥ）」に相当し、引用発明１の「３ＧＰＰネットワークに接続されたＭＴＣ用ＵＥへのデバイストリガリングを行うためのメッセージである、トリガ指示に係るペイロードを含むトリガ指示要求」は、本願発明にいう「無線通信ネットワークを介してユーザ設備（ＵＥ）へ送信されるべきトリガペイロードを含むデバイストリガ要求メッセージ」に相当するといえる。 また、引用発明１の「ＭＴＣ－ＩＷＦを実現するための解決策として示されたＤＴ－ＧＷ」は、「第２のリファレンスポイントを終端する」かどうかは別として、本願発明にいう「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置」に対応するものといえる。 そうすると、引用発明１の「ＭＴＣ－ＩＷＦを実現するための解決策として示されたＤＴ－ＧＷが、３ＧＰＰネットワークに接続されたＭＴＣ用ＵＥへのデバイストリガリングを行うためのメッセージである、トリガ指示に係るペイロードを含むトリガ指示要求をＭＴＣサーバからＭＴＣｓｐリファレンスポイントを介して受信」するステップは、本願発明の「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置が、無線通信ネットワークを介してユーザ設備（ＵＥ）へ送信されるべきトリガペイロードを含むデバイストリガ要求メッセージをＳＣＳから第１のリファレンスポイントを介して受信するステップ」に対応する。 （２）引用発明１の「ＤＴ－ＧＷ」は、ＭＴＣサーバからトリガ指示要求を受信し、ＭＴＣ用ＵＥに届けられるトリガ指示を転送するのに使用する最も効率的かつ効果的なサービスおよびルートを決定し、選択された配信サービスのために必要なフォーマットに一致させるための、トリガー指示ペイロードの再フォーマットを行い、再フォーマットを行ったトリガ指示を選択され配信サービス及びルートを介してＳＧＳＮ／ＭＭＥへ送信する。 そうすると、再フォーマットを行ったトリガ指示は、トリガ指示に係るペイロードを含むトリガ指示要求を再フォーマットしたものであるから、本願発明にいう「前記トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求」に相当するといえ、引用発明１が「第２のリファレンスポイントを介して」ＳＧＳＮ／ＭＭＥへ送信するかどうかは別として、本願発明と引用発明１とは、「前記トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求をＭＭＥ又はＳＧＳＮへ送信するステップ」を有する点で共通する。 （３）引用発明１の「ＤＴ－ＧＷ」は、トリガー指示が信頼されるＭＴＣサーバーからのものであることの認証、及び、トリガー指示にアドレス指定されたＭＴＣ用ＵＥが、アドレス指定されたＭＴＣ用ＵＥをトリガすることを許可されているＭＴＣサーバーからのものであることの認証、を行う機能を有し、ＭＴＣサーバからトリガ指示を受信すると、まず受信した要求を認証し、それが信用できるＭＴＣサーバからのものであり、ＭＴＣサーバがトリガすることを許可されたデバイスに宛てたものかを確認する。 そうすると、引用発明１の「ＤＴ－ＧＷ」は、本願発明の「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置」と同様、「前記無線通信ネットワークにより通信が確立される前に前記ＳＣＳを認証すること」、「該ＳＣＳからの制御プレーン要求を許可すること」を「行うように構成されている」といえる。 （４）引用発明１の「ＤＴ－ＧＷ」は、ＭＴＣ用ＵＥへの配信のために、ネットワークオペレータポリシーに基づいて、トリガー指示を転送するための最も効率的かつ効果的な配信サービス及びルートの選択を行う。 そうすると、引用発明１の「ネットワークオペレータポリシー」及びａ）～ｅ）に係る５つの「配信サービス及びルート」は、本願発明にいう「ネットワークポリシー」及び「複数のデバイストリガ送出メカニズム」に相当し、引用発明１の「ＤＴ－ＧＷ」は、本願発明の「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置」と同様、「ネットワークポリシーに基づいて、複数のデバイストリガ送出メカニズムのうちのデバイストリガ送出メカニズムを選択することであって、前記複数のデバイストリガ送出メカニズムの各々は前記トリガペイロードの送信が可能なルートを示す、こと、」を「行うよう構成されている」といえる。 （５）引用発明１の「ＤＴ－ＧＷ」は、ＭＴＣｓｐインタフェースを終端するから、上記のとおり「第２のリファレンスポイントを終端する」かどうかは別として、本願発明の「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置」と引用発明１の「ＤＴ－ＧＷ」とは、「前記第１のリファレンスポイントを終端すること、」を「行うよう構成されている」点で共通する。 （６）引用発明１の「ＤＴ－ＧＷ」は、内部ＰＬＭＮトポロジを隠し、ＰＬＭＮにおいて特定の機能を呼び出すために、ＭＴＣｓｐ上で使用されるシグナリングプロトコルを中継又は変換するから、本願発明の「マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置」と同様、「内部ＰＬＭＮトポロジを隠すこと」及び「該ＰＬＭＮにおいて特定の機能を呼び出すために前記第１のリファレンスポイント上で使用されるシグナリングプロトコルを中継又は変換すること」を「行うように構成されている」といえる。 よって、本願発明と引用発明１とは、以下の点で一致し、相違する。 （一致点） 「　マシンタイプコミュニケーション網間接続機能（ＭＴＣ－ＩＷＦ）において実装される装置が、無線通信ネットワークを介してユーザ設備（ＵＥ）へ送信されるべきトリガペイロードを含むデバイストリガ要求メッセージをＳＣＳから第１のリファレンスポイントを介して受信するステップと、 前記トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求をＭＭＥ又はＳＧＳＮへ送信するステップと を有し、前記装置は、 前記無線通信ネットワークにより通信が確立される前に前記ＳＣＳを認証すること、 該ＳＣＳからの制御プレーン要求を許可すること、 ネットワークポリシーに基づいて、複数のデバイストリガ送出メカニズムのうちのデバイストリガ送出メカニズムを選択することであって、前記複数のデバイストリガ送出メカニズムの各々は前記トリガペイロードの送信が可能なルートを示す、こと、 前記第１のリファレンスポイントを終端すること、 内部ＰＬＭＮトポロジを隠すこと、及び 該ＰＬＭＮにおいて特定の機能を呼び出すために前記第１のリファレンスポイント上で使用されるシグナリングプロトコルを中継又は変換すること を行うように構成されている、方法。」 （相違点） ＭＴＣ－ＩＷＦにおいて実装される装置が、本願発明では、「第２のリファレンスポイントを終端すること、」を「行うよう構成」されており、トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求をＭＭＥ又はＳＧＳＮへ「第２のリファレンスポイントを介して」送信するのに対し、引用発明１では、「第２のリファレンスポイントを終端」するかは明らかでなく、トリガペイロード及び該トリガペイロードを前記ＵＥへ転送する要求をＭＭＥ又はＳＧＳＮへ「第２のリファレンスポイントを介して」送信するものではない点。 第６　判断 引用発明１は、上記のとおり、ＳＩＭＴＣ／Ｒｅｌ－１１において検討された「ＭＴＣ－ＩＷＦ」を実現するための解決策として示された発明であり、その第５．８節に特定される（ｉ）デタッチ状態の場合、（ｉｉ）アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがない場合、及び、（ｉｉｉ）アタッチ状態であって公然にルーティング可能なＰＤＰコンテキスト／ＰＤＮコネクションがある場合、におけるデバイストリガリングに関し、ＭＴＣ－ＩＷＦにおいて実装される装置が、ＳＧＳＮ／ＭＭＥへの最も効率的かつ効果的な配信サービス及びルートをａ）～ｅ）の選択肢から選択するものである。そして、引用発明２は、ＳＩＭＴＣ／Ｒｅｌ－１１の第５．８節に特定される上記（ｉｉ）の場合におけるデバイストリガリングに関する解決策に係る発明であって、ＭＴＣ－ＩＷＦがＭＴＣサーバから受信したＵＥのためのデバイストリガ要求をＳＧＳＮに直接送信するルートの選択肢を示したものであるから、引用発明２に接した当業者が、引用発明２を引用発明１の上記選択肢の一つとして採用しようと試みる動機があるといえる。 そして、引用発明２の「ＭＴＣ－ＩＷＦ」は、ＭＴＣデバイスにサービスを提供するＳＧＳＮとの通信に用いるリファレンスポイントを終端しており、引用発明２は、ＵＥのためのデバイストリガ要求を当該リファレンスポイントを介してＳＧＳＮに直接送信するものであるから、引用発明２の「ＭＴＣデバイスにサービスを提供するＳＧＳＮとの通信に用いるリファレンスポイント」は、本願発明にいう「第２のリファレンスポイント」に相当するものといえる。 そうすると、引用発明１に引用発明２を適用して相違点に係る構成とすることに格別の困難はない。 よって、本願発明は、引用発明１及び引用発明２に基づいて、当業者が容易に発明をすることができたものである。 第７　むすび 以上のとおり、本願の請求項６に係る発明は、引用例１に記載された発明及び引用例２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、本願の他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。