【事件の表示】
　特願２０１４−５０５０８８「マシン−対−マシンノード消去手順」拒絶査定不服審判事件〔平成２４年１０月１８日国際公開，ＷＯ２０１２／１４１５５６，平成２６年　５月２９日国内公表，特表２０１４−５１３４７２，請求項の数（１６）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　 本願は，２０１２年４月１６日（パリ条約による優先権主張外国庁受理２０１１年４月１５日（以下，「優先日」という。），２０１１年５月１２日，２０１１年１０月７日，米国）を国際出願日とする出願であって，平成２８年３月２４日付けで拒絶理由通知（以下，「原審拒絶理由」という。）がされ，平成２８年６月２８日付けで意見書が提出されると共に手続補正がされ，平成２８年１１月２１日付けで拒絶査定がされ，これに対し，平成２９年３月２８日付けて拒絶査定不服審判の請求されると同時に手続補正され，平成２９年５月１２日付けで前置報告がされ，平成２９年１２月２２日付けで拒絶理由通知（以下，「当審拒絶理由」という。）がされ，平成３０年３月２６日付けで意見書が提出されると共に手続補正がされたものである。
第２．本願発明
　本願請求項１〜１６に係る発明（以下，それぞれ「本願発明１」〜「本願発明１６」という。）は，平成３０年３月２６日付けの手続補正で補正された特許請求の範囲の請求項１〜１６に記載された事項により特定される発明であり，本願発明１は以下のとおりである。
「【請求項１】
　マシン−対−マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ：Ｍ２Ｍ）サービスにおいてデバイスまたはゲートウェイでブートストラップ（ｂｏｏｔｓｔｒａｐｐｉｎｇ）状態を消去する方法は，
　Ｍ２Ｍ認証サーバ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｓｅｒｖｅｒ）（ＭＡＳ）またはＭ２Ｍサービスブートストラップ機能部（Ｍ２Ｍ　Ｓｅｒｖｉｃｅ　Ｂｏｏｔｓｔｒａｐｐｉｎｇ　Ｆｕｎｃｔｉｏｎ）（ＭＳＢＦ）から第１ペイロードを含む消去要請を受信するステップと，
　前記消去要請の第１ペイロードに含まれるＭ２ＭノードＩＤ及びキーインデックスに基づいて秘密キーを獲得するステップと，
　前記秘密キー，前記Ｍ２ＭノードＩＤ及びキーインデックスに基づいて，第１ハッシュ値を生成するステップと，
　前記第１ハッシュ値を前記消去要請に含まれた第２ハッシュ値とマッチングさせるステップと，
　前記マッチングの結果に基づいて前記消去要請を処理するステップと，
　消去応答を前記ＭＡＳまたは前記ＭＳＢＦに送信するステップとを含み，
　前記第１ハッシュ値は，ハッシュ＝ハッシュ関数（Ｋｍｒ，Ｍ２ＭノードＩＤ｜キーインデックス｜Ｎ臨時｜類型）によって生成され，
　前記「｜」は，連鎖を意味し，前記Ｎ臨時は，前記ＭＡＳまたは前記ＭＳＢＦによって生成された臨時値を含み，前記類型は，前記第１ペイロードの類型を表す類型値を含むことを特徴とするブートストラップ状態消去方法。」
　なお，本願発明２〜１６の概要は以下の通りである。
　本願発明２〜４は，本願発明１を減縮した発明である。
　本願発明５は，本願発明１に対応する消去要請を送信する側の方法の発明である。
　本願発明６〜８は，本願発明５を減縮した発明である。
　本願発明９は，本願発明１に対応するデバイスまたはゲートウェイの発明である。
　本願発明１０〜１２は，本願発明９を減縮する発明である。
　本願発明１３は，本願発明５に対応するデバイスまたはゲートウェイの発明である。
　本願発明１４〜１６は，本願発明１３を減縮した発明である。
第３．引用文献，引用発明等
１．引用文献１について
（１）原審拒絶理由に引用され，本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった特開２００５−２６０３５８号公報には，図面と共に次の事項が記載されている。
Ａ．「【００１１】
　それゆえに，本発明の目的は，
通信端末同士が直接通信する通信システムであって，各通信端末から認証に必要な情報を一括で削除することのできる
認証情報削除方法
Ｂ．「【００４５】
　鍵付きハッシュ関数を用いる場合，メッセージを送信する側の第１の通信端末は，送信先の第２の通信端末が持っているハッシュ関数で，鍵を付加したメッセージを変換する。ハッシュ関数とは，メッセージを一定長の値に変換し，当該一定長の値からは元のメッセージを求めることができないことを保証する一方向性関数のことをいう。
メッセージを送信する側の第１の通信端末は，鍵を付加したメッセージをハッシュ関数で変換し，得られた値を認証コードとしてメッセージに添付して，当該第２の通信端末に送信する
当該第２の通信端末は，送られてきたメッセージ（認証コード部分を除く）に，自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換する
第２の通信端末は，変換後に得られた値とメッセージに添付されている値（認証コード）とが一致すれば，正当な通信端末からのメッセージであると判断する
ハッシュ関数を用いる場合に，各通信端末が保持している鍵付きハッシュ関数に関するテーブルの構成を示す図である。図２Ｂに示すように，各通信端末は，他の通信端末に対応するハッシュ関数およびその鍵を，当該他の通信端末の識別子およびアドレスに対応させて保持している
Ｃ．「【００５３】
　ここで，例えば，
通信端末１１ａを廃棄する場合，通信端末１１ａは，自端末に関する認証情報の削除を指示するためのメッセージ（以下，削除命令メッセージという）を，認証関係にある他の通信端末（図１では，通信端末１１ｂおよび通信端末１１ｃ）に送信する
通信端末１１ａは，自端末に格納されている全ての認証情報を削除する。削除命令メッセージを受信した通信端末１１ｂおよび通信端末１１ｃは，通信端末１１ａに関する認証情報を管理テーブルから削除する
Ｄ．「【００７１】
　
通信端末１１ａは，ユーザから削除指示を受け取ると，削除命令メッセージを作成し，通信端末１１ｂに送信する
通信端末１１ｂは，削除命令メッセージを受信すると，応答メッセージを作成し，通信端末１１ａに返信する。そして，通信端末１１ｂは，自端末に格納されている管理テーブル１０２を参照し，通信端末１１ａの認証情報を削除する
信端末１１ａは，応答メッセージを受信すると，自端末に格納されている管理テーブル１０２を参照し，通信端末１１ｂの認証情報を削除する
Ｅ．「【００８４】
　一方，ステップＳ４０１において，
削除命令メッセージを受け取った場合，応答処理部１０５は，当該削除命令メッセージを認証し，正当なメッセージであるか否かを判断する（ステップＳ４０２）
【００８５】
　一方，
受け取った削除命令メッセージが正当なものである場合，管理テーブル１０２を参照して，削除命令メッセージの送信元アドレスが登録されたエントリから認証情報を削除する（ステップＳ４０３）
応答処理部１０５は，応答メッセージを作成する（ステップＳ４０４）。作成された応答メッセージは，通信部１０６に渡される（ステップＳ４０５）。以上のステップＳ４０１〜Ｓ４０５の処理によって，応答メッセージが作成され，通信端末１１ａに関する認証情報が削除される
Ｆ．「【０１１０】
　図１５Ａは，メッセージを暗号化して送信する場合における削除命令メッセージの構成の一例を示す。図１５Ａに示すように，
削除命令メッセージは，宛先アドレス情報と，送信元アドレス情報と，メッセージタイプと，乱数値と，削除命令フラグと，ハッシュ値とから構成される。
（２）上記Ａ乃至Ｆの記載から，引用文献１には次の発明（以下，「引用発明」という。）が記載されているといえる。
「通信端末同士が直接通信する通信システムにおいて，他の通信端末に対応するハッシュ関数およびその鍵を，他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除することができる認証情報削除方法であって，
　ユーザから削除指示を受け取る第１の通信端末は，送信先の第２の通信端末が持っているハッシュ関数で，鍵を付加したメッセージを変換し，得られた値を認証コードとしてメッセージに添付し，削除命令メッセージを作成するステップと，
　第１の通信端末は削除命令メッセージを認証関係にある第２の通信端末に送信するステップと，
　第２の通信端末は，送られてきた削除命令メッセージを受信するステップと，
　第２の通信端末は，送られてきた削除命令メッセージ（認証コード部分を除く）に，自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換するステップと，
　変換後に得られた値と削除命令メッセージに付加されている値（認証コード）が一致すれば，正当な通信端末からのメッセージであると判断するステップと，
　第２通信端末は，削除命令メッセージを正当なものと判断すると，応答メッセージを作成し第１の通信端末に返信し，自端末に格納されている管理テーブルを参照し，第１の通信端末の認証情報を削除するステップと，
　第１通信端末は，第２通信端末からの応答メッセージを受信すると，自端末に格納されている管理テーブルを参照し，第２の通信端末の認証情報を削除するステップと，
　宛先アドレス情報と，送信元アドレス情報と，メッセージタイプと，乱数値と，削除命令フラグと，ハッシュ値から構成される削除メッセージと，
　を備える認証情報削除方法。」
２．引用文献２
（１）原審拒絶理由に引用され，本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった国際公開第２００９／１４９７５９号（翻訳文は特表２０１１−５２４１３６号公報）には，図面と共に次の事項が記載されている。
Ｇ．「Detailed Description
 As mentioned above,
 with the rapid deployment of SNs and increased usage of M2M communication, the data processing workload of a Broker can be significant
Delegating tasks to Applications in order to reduce the workload on the Brokers requires that the SNs send data directly to those Applications.
 （第７頁１１行目〜２１行目）
【００３２】
　上述のように，
ＳＮの急速な展開とＭ２Ｍ通信の使用の増加とにより，ブローカーのデータ処理負荷はかなりのものになり得る
ブローカーの負荷を軽減するためにタスクをアプリケーションに委譲するには，ＳＮがデータを直接これらのアプリケーションへ送信する必要がある
Ｈ．「The above concept will now be described in more detail with reference to Figure 4, which shows a simplified signalling flow diagram in a situation where an Application 12 makes a request for service requiring data from two different SNs 13. The steps performed are as follows:
 S1. 
The Application 12 sends a request to the Broker 1 1 asking for a service.
 S2. The Broker 1 1 sends a request to the TDP 15, via the Application 12, to present its certificate and checks whether the certificate has expired or has been revoked. If the certificate is valid and the Broker 1 1 successfully authenticates the TDP 15 using the public key contained in the certificate, it continues with step S3. Otherwise the Broker 1 1 rejects the Application's request.
 S3. 
The Data Reasoner 16 within the Broker 11 analyses the request from the Application 12 and decides from which SNs 13 the data is going to be collected. For each source SN 13, it instructs the Key Generator 17 to generate a data key K and sends it to the SN 13.
 S4. 
The Data Reasoner 16 also produces a data processing algorithm F that identifies the source SNs 13 and provides the algorithm F that the TDP 15 will use to process the data from those SNs 13.
 S5. 
The Broker 11 encrypts the data keys K 1 , K 2  (generated by the Key Generator 17 at step S3) and the algorithm F (produced by the Data Reasoner 16 at step S4) with the TDP's public key K TDP  and the result (i.e.( K 1 , K 2 , F) K TDP ) is sent to the Application 12. 
 S6. The Application 12 forwards the encrypted data keys K 1 , K 2  and data processing algorithm F (i.e.( K 1 , K 2 , F) K TDP ) received at step S5 to the TDP 15.
 S7. 
The SNs 13 collect data P. For each SN 13, when the data P is ready, the SN 13 encrypts P with the data key K 1  or K 2  received from the Broker 1 1 to produce encrypted data C (i.e. C = (P)K). The encrypted data C is sent to the  TDP 15 in a communication session.
 S8. 
The Key and Algorithm Decryptor 22 of the TDP 15 decrypts the data keys K 1 , K 2  and the data processing algorithm F by using its private key.
 S9. 
The Data Decryptor 20 within the TDP 15 decrypts each input C by using the corresponding data key K 1  or K 2  and recovers the data P.
 S10. The TDP 15 outputs the result R to the Application 12.
（第９頁第７行目〜第１０頁第１１行目）
【００４０】
　ここで，図４を参照して，上述のコンセプトを更に詳細に説明する。図４は，アプリケーション１２が２つの異なるＳＮ１３からのデータを必要とするサービスを要求する状況における単純化されたシグナリングフロー図を示す。実行されるステップは以下の通りである。
【００４１】
　Ｓ１．  
アプリケーション１２は，ブローカー１１へ要求を送信してサービスを求める
【００４２】
　Ｓ２．  ブローカー１１は，アプリケーション１２経由で要求をＴＤＰ１５へ送信してＴＤＰ１５の証明書を提示するように求め，証明書が有効期限切れになったり無効にされたりしていないかをチェックする。証明書が有効であり，ブローカー１１が証明書に含まれる公開鍵を使用してＴＤＰ１５の認証に成功した場合，ステップＳ３に進む。そうでない場合，ブローカー１１はアプリケーションの要求を拒絶する。
【００４３】
　Ｓ３．  
ブローカー１１内のデータリーズナ１６は，アプリケーション１２からの要求を分析し，どのＳＮ１３からデータを収集すべきかを決定する。各ソースＳＮ１３について，データリーズナ１６は，鍵生成器１７に対してデータ鍵Ｋを生成してＳＮ１３へ送信するように指示する
【００４４】
　Ｓ４．  
データリーズナ１６はまた，ソースＳＮ１３を特定するデータ処理アルゴリズムＦを生成し，ＴＤＰ１５がそれらのＳＮ１３からのデータを処理するために使用するであろうアルゴリズムＦを提供す
【００４５】
　Ｓ５．  
ブローカー１１は，（ステップＳ３で鍵生成器１７によって生成された）データ鍵Ｋ１，Ｋ２と（ステップＳ４でデータリーズナ１６によって生成された）アルゴリズムＦとを，ＴＤＰの公開鍵ＫＴＤＰを用いて暗号化し，その結果（即ち，（Ｋ１，Ｋ２，Ｆ）ＫＴＤＰ）は，アプリケーション１２へ送信される
【００４６】
　Ｓ６．  アプリケーション１２は，ステップＳ５で受信した暗号化されたデータ鍵Ｋ１，Ｋ２及びデータ処理アルゴリズムＦ（即ち，（Ｋ１，Ｋ２，Ｆ）ＫＴＤＰ）を，ＴＤＰ１５へ転送する。
【００４７】
　Ｓ７．  
ＳＮ１３は，データＰを収集する。各ＳＮ１３について，データＰの準備ができると，ＳＮ１３は，ブローカー１１から受信したデータ鍵Ｋ１，Ｋ２を用いてＰを暗号化し，暗号化されたデータＣ（即ち，Ｃ＝（Ｐ）Ｋ）を生成する。暗号化されたデータＣは，通信セッションの中でＴＤＰ１５へ送信される
【００４８】
　Ｓ８．  
ＴＤＰ１５の鍵及びアルゴリズム復号器２２は，自分の秘密鍵を用いて，データ鍵Ｋ１，Ｋ２及びデータ処理アルゴリズムＦを復号する
【００４９】
　Ｓ９．  
ＴＤＰ１５内のデータ復号器２０は，対応するデータ鍵Ｋ１又はＫ２を用いて各入力Ｃを復号し，データＰを復元する
【００５０】
　Ｓ１０．  ＴＤＰ１５は，結果Ｒをアプリケーション１２へ出力する。」
Ｉ．「IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3G) to provide IP Multimedia services over mobile communication networks. IMS provides a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user  terminals (or user terminals and application servers). SIP makes it possible for a calling party to establish a packet switched session to a called party (using so-called SIP User Agents, UAs, installed in the user terminals) even though the calling party does not know the current IP address of the called party prior to initiating the call. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.（第１０頁３１行目〜第１１頁８行目）
【００５３】
  ＩＰマルチメディア・サブシステム（ＩＭＳ）は，第３世代パートナーシップ・プロジェクト（３Ｇ）によって策定された技術であり，移動体通信ネットワークを介してＩＰマルチメディア・サービスを提供する。ＩＭＳは，音声，ビデオ，メッセージング，データ等の動的な組み合わせを，同一のセッション内で提供する。ＩＭＳは，ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）で呼又はセッションをセットアップして制御するために，セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰにより，たとえ呼を開始する前に発呼パーティーが被呼パーティーの現在のＩＰアドレスを知らなかったとしても，発呼パーティーは，被呼パーティーに対するパケット交換セッションを確立することができるようになる（ユーザ端末内にインストールされた所謂ＳＩＰユーザエージェント（ＵＡ）を使用して）。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は，セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作られたが，ＩＭＳにより，オペレータ及びサービスプロバイダは，サービスに対するユーザアクセスを制御し，それに応じてユーザに課金することができる。」
（２）上記Ｇ乃至Ｈの記載から引用文献２には次の技術的事項が記載されているといえる。
「Ｍ２Ｍシステムにおいて，ブローカーのデータ処理負荷を軽減するために，タスクをアプリケーションに委譲し，アプリケーションがブローカーへサービスを要求すると，ブローカーは，ＴＤＰ（信頼済データプロセッサ）の認証が成功した場合，データ鍵を生成しＳＮ（センサネットワーク）に送信し，データ鍵をＴＤＰの公開鍵を用いて暗号化しアプリケーションに送信しする。ＳＮは，データを収集しデータ鍵を用いて暗号化し，暗号されたデータをＴＤＰに送信する。ＴＤＰは秘密鍵を用いてデータ鍵を復号し，データ鍵を用いてデータを復元することを特徴とするＭ２Ｍシステム」
４．引用文献３
（１）原審拒絶理由に引用され，本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった国際公開第２０１０／１０７６３１号（翻訳文は特表２０１２−５２１０４５号公報）には，図面と共に次の事項が記載されている。
Ｊ．「[0040] 
Electronic devices, such as laptop or handheld computers, are frequently lost or stolen.
【００２１】
　
ラップトップコンピュータまたはハンドヘルドコンピュータ等の電子機器は，紛失したり盗まれたりすることが多い。
Ｋ．「[0087] As shown in FIG. 10, flowchart 1300 begins with step 1302. In step 1302, an instruction to enact a remediation policy is received. Referring to FIG. 2, in an embodiment, 
electronic device 102 may receive second communication signal 220 from management service 204, which includes the instruction to initiate remediation of electronic device 102.
 [0088] As shown in FIG. 12, network interface 1206 communicatively couples electronic device 1200 with network 206 through a communication link 1208. Network interface 1206 may be any type of network interface (e.g., network interface card (NIC)), wired or wireless, such as an as IEEE 802.11 wireless LAN (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, etc.
 [0089] In an embodiment, network interface 1206 participates in communication session 420, and outputs remediation message 418. 
Remediation message 418 is received by device remediation module 1202, which instructs device remediation module 1202 to implement remediation policy 1214.
 [0090] In step 1304, the remediation policy is performed. As shown in FIG. 12, 
as a result of receiving remediation message 418 or remediation instruction 1212, device remediation module 1202 implements one or more remediation policies, such as a remediation policy 1214.
 [0091] Various
 remediation policies may be included in remediation policy 1214 that are performed by device remediation module 1202.
 [0092] As shown in FIG. 14, flowchart 1400 begins with step 1402. In step 1402, at least one encryption key is deleted. For example, in an embodiment, 
device remediation module 1202 may be configured to delete local encryption keys to protect local copies of private encrypted data from access.
【００６８】
　図１０に示すように，フローチャート１３００はステップ１３０２にて開始される。ステップ１３０２にて，修正ポリシを成立させる命令が受信される。図２を参照すると，一実施形態において，
電子機器１０２は，管理サービス２０４から第２の通信信号２２０を受信することができ，通信信号２２０には電子機器１０２の修正を開始させる命令が含まれる
【００６９】
　図１２に示すように，ネットワークインターフェース１２０６は，電子機器１２００をネットワーク２０６に通信リンク１２０８を介して通信可能に連結する。ネットワークインターフェース１２０６は，有線または無線の，任意のタイプのネットワークインターフェース（例えば，ネットワークインターフェースカード（ＮＩＣ））とすることができ，例えば，ＩＥＥＥ８０２．１１無線ＬＡＮ（ＷＬＡＮ）無線インターフェース，Ｗｉ−ＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）インターフェース，Ｅｔｈｅｒｎｅｔインターフェース，ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）インターフェースなどがある。
【００７０】
　一実施形態において，ネットワークインターフェース１２０６は，通信セッション４２０に加わり，修正メッセージ４１８を出力する。
修正メッセージ４１８は機器修正モジュール１２０２により受信され，修正メッセージ４１８は，機器修正モジュール１２０２に命令して修正ポリシ１２１４を実装させる。
【００７１】
　ステップ１３０４にて修正ポリシが実行される。図１２に示すように，
修正メッセージ４１８または修正命令１２１２を受信した結果，機器修正モジュール１２０２は修正ポリシ１２１４等の１つまたは複数の修正ポリシを実装する
【００７２】
　種々の
修正ポリシは，機器修正モジュール１２０２により実行される修正ポリシ１２１４内に含まれていても良い
【００７３】
　図１４に示すように，フローチャート１４００はステップ１４０２にて開始される。ステップ１４０２にて，少なくとも１つの暗号鍵が削除される。例えば，一実施形態において，
機器修正モジュール１２０２を，ローカルな暗号鍵を削除してプライベートな暗号化されたデータのローカルコピーをアクセスされないように保護するように構成することができる
（２）上記Ｊ乃至Ｋの記載から，引用文献３には次の技術的事項が記載されているといえる。
「携帯電話等の電子機器を紛失したり盗まれたりした際に，修正命令を送信し，電子機器が修正命令を受信すると修正ポリシが実行され，電子機器内の暗号鍵を削除する方法」
４．引用文献４
（１）原審拒絶理由に引用され，本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった特開２００９−１００２４９号公報には，図面と共に次の事項が記載されている。
Ｌ．「【０００２】
　従来，
通信端末装置間でデータを通信する際に，両装置間に少なくとも１つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている
（２）上記Ｌの記載から，引用文献４には次の技術的事項が記載されているといえる。
「通信端末装置間でデータを通信する際に，両装置間に少なくとも１つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている」
第４．対比・判断
１．本願発明１
（１）対比
あ．引用発明の「通信端末同士が直接通信する通信システムにおいて，他の通信端末に対応するハッシュ関数およびその鍵を，他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除することができる認証情報削除方法」と本願発明１の「マシン−対−マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ：Ｍ２Ｍ）サービスにおいてデバイスまたはゲートウェイでブートストラップ（ｂｏｏｔｓｔｒａｐｐｉｎｇ）状態を消去する方法」とを対比すると，
　引用発明の「通信端末同士が直接通信する通信システム」は，マシン−対−マシンのサービスを含んでいるといえ，本願発明１の「ブートストラップ（ｂｏｏｔｓｔｒａｐｐｉｎｇ）状態を消去する」ことは，サービス加入状態（デバイスに記憶済みの情報）を消去しているといえるので，引用発明の「他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除すること」は，“デバイスに記録済みの情報を消去する”点で共通するといえる。そうすると，両者は後記する点で相違するものの，
“マシン−対−マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ：Ｍ２Ｍ）サービスにおいてデバイスに記録済み状態を消去する方法”という点で一致する。
い．引用発明の「ユーザから削除指示を受け取る第１の通信端末は，送信先の第２の通信端末が持っているハッシュ関数で，鍵を付加したメッセージを変換し，得られた値を認証コードとしてメッセージに添付し，削除命令メッセージを作成するステップと，第１の通信端末は削除命令メッセージを認証関係にある第２の通信端末に送信するステップと，第２の通信端末は，送られてきた削除命令メッセージを受信するステップと，」と本願発明１の「Ｍ２Ｍ認証サーバ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｓｅｒｖｅｒ）（ＭＡＳ）またはＭ２Ｍサービスブートストラップ機能部（Ｍ２Ｍ　Ｓｅｒｖｉｃｅ　Ｂｏｏｔｓｔｒａｐｐｉｎｇ　Ｆｕｎｃｔｉｏｎ）（ＭＳＢＦ）から第１ペイロードを含む消去要請を受信するステップ」とを対比すると，
　引用発明の「送信先の第２の通信端末が持っているハッシュ関数で，鍵を付加したメッセージを変換し，得られた値を認証コードとしてメッセージに添付」された「削除命令メッセージ」は本願発明の「第１ペイロードを含む消去要請」に対応することから，両者は，後記する点で相違するものの，
“消去要請元から第１ペイロードを含む消去要請を受信するステップ”という点で一致する。
う．引用発明の「第２の通信端末は，送られてきた削除命令メッセージ（認証コード部分を除く）に，自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換するステップ」と本願発明１の「前記消去要請の第１ペイロードに含まれるＭ２ＭノードＩＤ及びキーインデックスに基づいて秘密キーを獲得するステップと，前記秘密キー，前記Ｍ２ＭノードＩＤ及びキーインデックスに基づいて，第１ハッシュ値を生成するステップ」とを対比すると，
　引用発明の「送られてきた削除命令メッセージ（認証コード部分を除く）に，自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換する」ことは，前記消去要請の第１のペイロードに含まれるメッセージに基づいて，第１ハッシュ値を生成しているといえるので，両者は，後記する点で相違するものの，
“前記消去要請の第１のペイロードに含まれるメッセージに基づいて，第１ハッシュ値を生成するステップ”の点で一致する。
え．引用発明の「変換後に得られた値と削除命令メッセージに付加されている値（認証コード）が一致すれば，正当な通信端末からのメッセージであると判断するステップ」と本願発明１の「前記第１ハッシュ値を前記消去要請に含まれた第２ハッシュ値とマッチングさせるステップ」とを対比すると，
　引用発明の「変換後に得られた値」と「削除命令メッセージに付加されている値（認証コード）」は本願発明１の「第１ハッシュ値」と「消去要請に含まれた第２ハッシュ値」にそれぞれ相当し，引用発明の「一致すれば，正当な通信端末からのメッセージであると判断する」ことは，マッチングさせているといえるので，両者は後記する点で相違するものの，
“前記第１ハッシュ値を前記消去要請に含まれた第２ハッシュ値とマッチングさせるステップ”という点で一致する。
お．引用発明の「第２通信端末は，削除命令メッセージを正当なものと判断すると，応答メッセージを作成し第１の通信端末に返信し，自端末に格納されている管理テーブルを参照し，第１の通信端末の認証情報を削除するステップ」と本願発明１の「前記マッチングの結果に基づいて前記消去要請を処理するステップと，消去応答を前記ＭＡＳまたは前記ＭＳＢＦに送信するステップ」とを対比すると，
　引用発明の「削除命令メッセージを正当なものと判断する」ことは，削除メッセージを正当なものと判断した結果であり，ハッシュ値をマッチング結果といえ，「自端末に格納されている管理テーブルを参照し，第１の通信端末の認証情報を削除する」ことは，削除命令メッセージの削除要請を処理しているといえ，引用発明の「応答メッセージを作成し第１の通信端末に返信」することは，消去応答を消去要請元へ送信しているといえるので，両者は，後記する点で相違するものの，
“前記マッチング結果に基づいて前記消去要請を処理するステップと，消去応答を消去要請元へ送信するステップ”という点で一致する。
か．上記あ．〜お．の検討より，引用発明と本願発明１は，以下の点で一致し，相違する。
＜一致点＞
　マシン−対−マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ：Ｍ２Ｍ）サービスにおいてデバイスに記録済み状態を消去する方法であって，
　消去要請元から第１ペイロードを含む消去要請を受信するステップと，
　前記消去要請の第１のペイロードに含まれるメッセージに基づいて，第１ハッシュ値を生成するステップと，
　前記第１ハッシュ値を前記消去要請に含まれた第２ハッシュ値とマッチングさせるステップと，
　前記マッチング結果に基づいて前記消去要請を処理するステップと，
　消去応答を消去要請元へ送信するステップと，
　を含むことを特徴とする記録済み状態消去方法。
＜相違点１＞
　本願発明１ではマシン−対−マシン（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ：Ｍ２Ｍ）サービスにおいてデバイスまたはゲートウェイでブートストラップ（ｂｏｏｔｓｔｒａｐｐｉｎｇ）状態を消去する方法であるのに対して，引用発明では，通信端末同士における認証情報を削除方法である点。
＜相違点２＞
　本願発明１では，Ｍ２ＭノードＩＤまたはキーインデックスに基づいて秘密キーを獲得し，秘密キーとＭ２ＭノードＩＤまたはキーインデックスのうちいずれか１つに基づいて，第１ハッシュ値を生成しているのに対して，引用発明では，通信端末に対応するハッシュ関数や鍵は管理テーブルに保持されているものから認証コード（第１ハッシュ値）を生成し，Ｍ２Ｍノードキーやキーインデックスについては明記されていない点。
＜相違点３＞
　本願発明１では，前記第１ハッシュ値は，ハッシュ＝ハッシュ関数（Ｋｍｒ，Ｍ２ＭノードＩＤ｜キーインデックス｜Ｎ臨時｜類型）によって生成され，　前記「｜」は，連鎖を意味し，前記Ｎ臨時は，前記ＭＡＳまたは前記ＭＳＢＦによって生成された臨時値を含み，前記類型は，前記第１ペイロードの類型を表す類型値を含むと特定しているのに対して，引用発明では，宛先アドレス，送信元アドレス情報，メッセージタイプ，乱数値，削除命令フラグ，ハッシュ値から構成される削除命令メッセージを用いているものの，ハッシュ関数についてそのように特定されていない点。
（２）相違点に対する判断
　上記相違点２及び相違点３について検討すると，相違点２に係る構成は，Ｍ２ＭノードＩＤ及びキーインデクスに基づいて秘密キーを獲得する構成（以下，「秘密キーを獲得する構成」という）含んでおり，相違点３に係る構成は，第１のハッシュ値は，ハッシュ＝ハッシュ（ｋｍｒ（秘密キー），Ｍ２ＭノードＩＤ｜キーインデックス｜Ｎ臨時｜類型）（以下，「ハッシュ関数の構成」という）を含むものである。
　しかし，引用文献２（上記Ｇ，Ｈ参照）には「Ｍ２Ｍシステムにおいて，ブローカーのデータ処理負荷を軽減するために，タスクをアプリケーションに委譲し，アプリケーションがブローカーへサービスを要求すると，ブローカーは，ＴＤＰ（信頼済データプロセッサ）の認証が成功した場合，データ鍵を生成しＳＮ（センサネットワーク）に送信し，データ鍵をＴＤＰの公開鍵を用いて暗号化しアプリケーションに送信しする。ＳＮは，データを収集しデータ鍵を用いて暗号化し，暗号されたデータをＴＤＰに送信する。ＴＤＰは秘密鍵を用いてデータ鍵を復号し，データ鍵を用いてデータを復元することを特徴とするＭ２Ｍシステム」が記載され，引用文献３（上記Ｊ，Ｋ参照）には「携帯電話等の電子機器を紛失したり盗まれたりした際に，修正命令を送信し，電子機器が修正命令を受信すると修正ポリシが実行され，電子機器内の暗号鍵を削除する方法」が記載され，引用文献４(上記Ｌ参照）には「通信端末装置間でデータを通信する際に，両装置間に少なくとも１つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている」ことが記載されているものの，上記秘密キーを獲得する構成及びハッシュ関数の構成は記載されておらず，引用発明の「宛先アドレス情報と，送信元アドレス情報と，メッセージタイプと，乱数値と，削除命令フラグと，ハッシュ値から構成される削除メッセージ」から当業者が容易に想到し得ることともいえない。
　したがって，その他の相違点について判断するまでもなく，本願発明１は，当業者あっても，引用発明，引用文献２乃至４に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２．本願発明２〜４について
　本願発明２〜４は，本願発明１を減縮した発明であるから，本願発明１の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
３．本願発明５について
　本願発明５は，本願発明１に対応する消去要請を送信する側の方法の発明である。
　しかし，本願発明５は，本願発明１の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
４．本願発明６〜８について
　本願発明６〜８は，本願発明５を減縮した発明である。
　即ち，本願発明６〜８は，本願発明１の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
５．本願発明９〜１６について
　本願発明９は，本願発明１に対応するデバイスまたはゲートウェイの発明である。
　本願発明１０〜１２は，本願発明９を減縮する発明である。
　本願発明１３は，本願発明５に対応するデバイスまたはゲートウェイの発明である。
　本願発明１４〜１６は，本願発明１３を減縮した発明である。
　即ち，本願発明９〜１６は，本願発明１の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２乃至４に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第５．原査定の概要および原査定の判断
  原査定は，請求項１−２０について上記引用文献１−４に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないというものである。
　しかしながら，平成２９年３月２８日付けの手続補正により補正された請求項１−１６は，「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものとなっており，引用発明及び上用文献２−４に記載された技術的事項に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持するこはできない。
第６．当審拒絶理由について
　当審では，請求項２，６，１０，１４の「第１ペイロード」が情報要素を「少なくとも１つを含み」という点は，「第１ペイロード」に含まれない情報要素を何処から如何に獲得するのか不明りょうであり，発明の詳細な説明には当業者が実施できるように記載されていないという拒絶の理由を通知しているが，平成３０年３月２６日の手続補正において「前記第１ペイロード」は，「少なくとも」各情報要素を含む態様に補正された結果，この拒絶理由は解消した。
　また，当審では，請求項４，８，１２，１６の「Ｍ２Ｍノード」と当該請求項が従属する請求項の「Ｍ２ＭノードＩＤ」における「Ｍ２Ｍノード」との対応が不明りょうであるとの拒絶の理由を通知しているが，平成３０年３月２６日付け手続補正で「Ｍ２Ｍノード」を「ネットワークＭ２Ｍノード」と補正された結果，この拒絶理由は解消した。
第７．むすび
　以上のとおり，本願発明１−１６は，当業者が引用発明及び引用文献２−４に記載された技術的事項に基づいて容易に発明することができたものではない。
　したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。