拒絶査定不服の審決｜不服2017-4385 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備取り消して特許、登録 H04L 審判査定不服特36条4項詳細な説明の記載不備取り消して特許、登録 H04L 審判査定不服 2項進歩性取り消して特許、登録 H04L
管理番号	1340518
審判番号	不服2017-4385
総通号数	223
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2018-07-27
種別	拒絶査定不服の審決
審判請求日	2017-03-28
確定日	2018-06-11
事件の表示	特願2014-505088「マシン-対-マシンノード消去手順」拒絶査定不服審判事件〔平成24年10月18日国際公開,WO2012/141556,平成26年 5月29日国内公表,特表2014-513472,請求項の数(16)〕について,次のとおり審決する。
結論	原査定を取り消す。本願の発明は,特許すべきものとする。
理由	第1.手続の経緯本願は,2012年4月16日(パリ条約による優先権主張外国庁受理2011年4月15日(以下,「優先日」という。),2011年5月12日,2011年10月7日,米国)を国際出願日とする出願であって,平成28年3月24日付けで拒絶理由通知(以下,「原審拒絶理由」という。)がされ,平成28年6月28日付けで意見書が提出されると共に手続補正がされ,平成28年11月21日付けで拒絶査定がされ,これに対し,平成29年3月28日付けて拒絶査定不服審判の請求されると同時に手続補正され,平成29年5月12日付けで前置報告がされ,平成29年12月22日付けで拒絶理由通知(以下,「当審拒絶理由」という。)がされ,平成30年3月26日付けで意見書が提出されると共に手続補正がされたものである。第2.本願発明本願請求項1?16に係る発明(以下,それぞれ「本願発明1」?「本願発明16」という。)は,平成30年3月26日付けの手続補正で補正された特許請求の範囲の請求項1?16に記載された事項により特定される発明であり,本願発明1は以下のとおりである。「【請求項1】マシン-対-マシン(Machine-ｔｏ-Machine:M2M)サービスにおいてデバイスまたはゲートウェイでブートストラップ(bｏｏｔｓｔｒaｐｐing)状態を消去する方法は, M2M認証サーバ(Aｕｔhenｔicaｔiｏn Seｒｖeｒ)(MAS)またはM2Mサービスブートストラップ機能部(M2M Seｒｖice Bｏｏｔｓｔｒaｐｐing Fｕncｔiｏn)(MSBF)から第1ペイロードを含む消去要請を受信するステップと, 前記消去要請の第1ペイロードに含まれるM2MノードID及びキーインデックスに基づいて秘密キーを獲得するステップと, 前記秘密キー,前記M2MノードID及びキーインデックスに基づいて,第1ハッシュ値を生成するステップと, 前記第1ハッシュ値を前記消去要請に含まれた第2ハッシュ値とマッチングさせるステップと, 前記マッチングの結果に基づいて前記消去要請を処理するステップと, 消去応答を前記MASまたは前記MSBFに送信するステップとを含み, 前記第1ハッシュ値は,ハッシュ=ハッシュ関数(Kmｒ,M2MノードID｜キーインデックス｜N臨時｜類型)によって生成され, 前記「｜」は,連鎖を意味し,前記N臨時は,前記MASまたは前記MSBFによって生成された臨時値を含み,前記類型は,前記第1ペイロードの類型を表す類型値を含むことを特徴とするブートストラップ状態消去方法。」なお,本願発明2?16の概要は以下の通りである。本願発明2?4は,本願発明1を減縮した発明である。本願発明5は,本願発明1に対応する消去要請を送信する側の方法の発明である。本願発明6?8は,本願発明5を減縮した発明である。本願発明9は,本願発明1に対応するデバイスまたはゲートウェイの発明である。本願発明10?12は,本願発明9を減縮する発明である。本願発明13は,本願発明5に対応するデバイスまたはゲートウェイの発明である。本願発明14?16は,本願発明13を減縮した発明である。第3.引用文献,引用発明等 1.引用文献1について (1)原審拒絶理由に引用され,本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった特開2005-260358号公報には,図面と共に次の事項が記載されている。 A.「【0011】それゆえに,本発明の目的は,通信端末同士が直接通信する通信システムであって,各通信端末から認証に必要な情報を一括で削除することのできる通信システムならびにそれに用いられる通信端末,認証情報削除方法,認証情報削除プログラムおよび認証情報削除プログラムを格納する記録媒体を提供することである。」 B.「【0045】鍵付きハッシュ関数を用いる場合,メッセージを送信する側の第1の通信端末は,送信先の第2の通信端末が持っているハッシュ関数で,鍵を付加したメッセージを変換する。ハッシュ関数とは,メッセージを一定長の値に変換し,当該一定長の値からは元のメッセージを求めることができないことを保証する一方向性関数のことをいう。メッセージを送信する側の第1の通信端末は,鍵を付加したメッセージをハッシュ関数で変換し,得られた値を認証コードとしてメッセージに添付して,当該第2の通信端末に送信する。当該第2の通信端末は,送られてきたメッセージ(認証コード部分を除く)に,自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換する。第2の通信端末は,変換後に得られた値とメッセージに添付されている値(認証コード)とが一致すれば,正当な通信端末からのメッセージであると判断する。したがって,鍵付きハッシュ関数を用いる場合,各通信端末は,通信相手先と共通のハッシュ関数およびその鍵を保持していることとなる。図2Bは,ハッシュ関数を用いる場合に,各通信端末が保持している鍵付きハッシュ関数に関するテーブルの構成を示す図である。図2Bに示すように,各通信端末は,他の通信端末に対応するハッシュ関数およびその鍵を,当該他の通信端末の識別子およびアドレスに対応させて保持している。」 C.「【0053】ここで,例えば,通信端末11aを廃棄する場合,通信端末11aは,自端末に関する認証情報の削除を指示するためのメッセージ(以下,削除命令メッセージという)を,認証関係にある他の通信端末(図1では,通信端末11bおよび通信端末11c)に送信する。そして,通信端末11aは,自端末に格納されている全ての認証情報を削除する。削除命令メッセージを受信した通信端末11bおよび通信端末11cは,通信端末11aに関する認証情報を管理テーブルから削除する。なお,以下,特に断らない限り,通信端末は,認証情報を削除する際に,同一のエントリに登録されている通信先識別子およびアドレスも共に削除するものとする。また,認証情報が削除されることを認証関係が解除されたということにする。」 D.「【0071】通信端末11aは,ユーザから削除指示を受け取ると,削除命令メッセージを作成し,通信端末11bに送信する。通信端末11bは,削除命令メッセージを受信すると,応答メッセージを作成し,通信端末11aに返信する。そして,通信端末11bは,自端末に格納されている管理テーブル102を参照し,通信端末11aの認証情報を削除する。一方,通信端末11aは,応答メッセージを受信すると,自端末に格納されている管理テーブル102を参照し,通信端末11bの認証情報を削除する。なお,上記では通信端末11aから通信端末11bへ削除命令メッセージが送信される場合を例に説明したが,削除命令メッセージは,通信端末11b以外の他の通信端末(通信端末11c)にも送信される。」 E.「【0084】一方,ステップS401において,削除命令メッセージを受け取った場合,応答処理部105は,当該削除命令メッセージを認証し,正当なメッセージであるか否かを判断する(ステップS402)。受け取った削除命令メッセージが正当なものでない場合,認証情報は削除されない。そして,応答処理部105は,ステップS401の動作に戻る。【0085】一方,受け取った削除命令メッセージが正当なものである場合,管理テーブル102を参照して,削除命令メッセージの送信元アドレスが登録されたエントリから認証情報を削除する(ステップS403)。そして,応答処理部105は,応答メッセージを作成する(ステップS404)。作成された応答メッセージは,通信部106に渡される(ステップS405)。以上のステップS401?S405の処理によって,応答メッセージが作成され,通信端末11aに関する認証情報が削除される。」 F.「【0110】図15Aは,メッセージを暗号化して送信する場合における削除命令メッセージの構成の一例を示す。図15Aに示すように,削除命令メッセージは,宛先アドレス情報と,送信元アドレス情報と,メッセージタイプと,乱数値と,削除命令フラグと,ハッシュ値とから構成される。図15に示す削除命令メッセージは,メッセージタイプと乱数値とを含む点で図5に示す削除命令メッセージと異なる。メッセージタイプは,メッセージの属性を示し,ここでは削除命令を示す情報である。乱数値は,メッセージを作成する通信端末が決定するランダムな値である。通信端末は,乱数値を記録した削除命令メッセージを送信先に送信すると,送信先の通信端末は,当該乱数値を応答メッセージに記録して返信する。これにより,削除命令メッセージを送信した通信端末は,送信した乱数値と受信した乱数値とを比較することによって,受信したメッセージが正当なものであるかを判断することができる。削除命令処理部104は,削除命令メッセージを作成後,乱数値および削除命令フラグを暗号化して通信部106に渡す。」 (2)上記A乃至Fの記載から,引用文献1には次の発明(以下,「引用発明」という。)が記載されているといえる。「通信端末同士が直接通信する通信システムにおいて,他の通信端末に対応するハッシュ関数およびその鍵を,他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除することができる認証情報削除方法であって, ユーザから削除指示を受け取る第1の通信端末は,送信先の第2の通信端末が持っているハッシュ関数で,鍵を付加したメッセージを変換し,得られた値を認証コードとしてメッセージに添付し,削除命令メッセージを作成するステップと, 第1の通信端末は削除命令メッセージを認証関係にある第2の通信端末に送信するステップと, 第2の通信端末は,送られてきた削除命令メッセージを受信するステップと, 第2の通信端末は,送られてきた削除命令メッセージ(認証コード部分を除く)に,自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換するステップと, 変換後に得られた値と削除命令メッセージに付加されている値(認証コード)が一致すれば,正当な通信端末からのメッセージであると判断するステップと, 第2通信端末は,削除命令メッセージを正当なものと判断すると,応答メッセージを作成し第1の通信端末に返信し,自端末に格納されている管理テーブルを参照し,第1の通信端末の認証情報を削除するステップと, 第1通信端末は,第2通信端末からの応答メッセージを受信すると,自端末に格納されている管理テーブルを参照し,第2の通信端末の認証情報を削除するステップと, 宛先アドレス情報と,送信元アドレス情報と,メッセージタイプと,乱数値と,削除命令フラグと,ハッシュ値から構成される削除メッセージと, を備える認証情報削除方法。」 2.引用文献2 (1)原審拒絶理由に引用され,本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった国際公開第2009/149759号(翻訳文は特表2011-524136号公報)には,図面と共に次の事項が記載されている。 G.「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, especially when streaming data is sent from a SN. It is therefore desirable that the Broker can delegate some of its data processing tasks to Applications in order to maintain scalability of the system. Delegating tasks to Applications in order to reduce the workload on the Brokers requires that the SNs send data directly to those Applications. In addition, when the data being sent from a SN to an Application is in a streamed format and no further processing is required, it would be better if the gateway of the SN could transmit the data directly to the recipient Application. (第7頁11行目?21行目) 【0032】上述のように,SNの急速な展開とM2M通信の使用の増加とにより,ブローカーのデータ処理負荷はかなりのものになり得る。これは特に,SNからストリーミングデータが送信される場合にそうである。それゆえ,システムのスケーラビリティを維持するために,ブローカーが自分のデータ処理タスクの一部をアプリケーションに委譲できることが望ましい。ブローカーの負荷を軽減するためにタスクをアプリケーションに委譲するには,SNがデータを直接これらのアプリケーションへ送信する必要がある。加えて,SNからアプリケーションへ送信されるデータがストリーム形式であってこれ以上の処理が不要な場合,SNのゲートウェイがそのデータを直接受信者のアプリケーションへ送信できれば,その方がよいであろう。」 H.「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. The session can be established according to the procedures described below. 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. It sends the data keys K 1 , K 2 and the algorithm F to the Data Decryptor 20 and the Data Processing Unit 21 respectively. 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. The Data Processing Unit 21 within the TDP 15 processes the plaintext data (P1 and P2 as shown in Figure 3) according to the algorithm F, generating a result (R). S10. The TDP 15 outputs the result R to the Application 12. (第9頁第7行目?第10頁第11行目) 【0040】ここで,図4を参照して,上述のコンセプトを更に詳細に説明する。図4は,アプリケーション12が2つの異なるSN13からのデータを必要とするサービスを要求する状況における単純化されたシグナリングフロー図を示す。実行されるステップは以下の通りである。【0041】 S1. アプリケーション12は,ブローカー11へ要求を送信してサービスを求める。【0042】 S2. ブローカー11は,アプリケーション12経由で要求をTDP15へ送信してTDP15の証明書を提示するように求め,証明書が有効期限切れになったり無効にされたりしていないかをチェックする。証明書が有効であり,ブローカー11が証明書に含まれる公開鍵を使用してTDP15の認証に成功した場合,ステップS3に進む。そうでない場合,ブローカー11はアプリケーションの要求を拒絶する。【0043】 S3. ブローカー11内のデータリーズナ16は,アプリケーション12からの要求を分析し,どのSN13からデータを収集すべきかを決定する。各ソースSN13について,データリーズナ16は,鍵生成器17に対してデータ鍵Kを生成してSN13へ送信するように指示する。【0044】 S4. データリーズナ16はまた,ソースSN13を特定するデータ処理アルゴリズムFを生成し,TDP15がそれらのSN13からのデータを処理するために使用するであろうアルゴリズムFを提供する。【0045】 S5. ブローカー11は,(ステップS3で鍵生成器17によって生成された)データ鍵K1,K2と(ステップS4でデータリーズナ16によって生成された)アルゴリズムFとを,TDPの公開鍵KTDPを用いて暗号化し,その結果(即ち,(K1,K2,F)KTDP)は,アプリケーション12へ送信される。【0046】 S6. アプリケーション12は,ステップS5で受信した暗号化されたデータ鍵K1,K2及びデータ処理アルゴリズムF(即ち,(K1,K2,F)KTDP)を,TDP15へ転送する。【0047】 S7. SN13は,データPを収集する。各SN13について,データPの準備ができると,SN13は,ブローカー11から受信したデータ鍵K1,K2を用いてPを暗号化し,暗号化されたデータC(即ち,C=(P)K)を生成する。暗号化されたデータCは,通信セッションの中でTDP15へ送信される。このセッションは,後述する手順に従って確立可能である。【0048】 S8. TDP15の鍵及びアルゴリズム復号器22は,自分の秘密鍵を用いて,データ鍵K1,K2及びデータ処理アルゴリズムFを復号する。アルゴリズム復号器22は,データ鍵K1,K2及びデータ処理アルゴリズムFを,それぞれデータ復号器20及びデータ処理ユニット21へ送信する。【0049】 S9. TDP15内のデータ復号器20は,対応するデータ鍵K1又はK2を用いて各入力Cを復号し,データPを復元する。TDP15内のデータ処理ユニット21は,アルゴリズムFに従ってプレーンテキストデータ(図3に示すP1及びP2)を処理し,結果(R)を生成する。【0050】 S10. TDP15は,結果Rをアプリケーション12へ出力する。」 I.「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.(第10頁31行目?第11頁8行目) 【0053】 IPマルチメディア・サブシステム(IMS)は,第3世代パートナーシップ・プロジェクト(3G)によって策定された技術であり,移動体通信ネットワークを介してIPマルチメディア・サービスを提供する。IMSは,音声,ビデオ,メッセージング,データ等の動的な組み合わせを,同一のセッション内で提供する。IMSは,ユーザ端末間(又はユーザ端末とアプリケーションサーバとの間)で呼又はセッションをセットアップして制御するために,セッション開始プロトコル(SIP)を使用する。SIPにより,たとえ呼を開始する前に発呼パーティーが被呼パーティーの現在のIPアドレスを知らなかったとしても,発呼パーティーは,被呼パーティーに対するパケット交換セッションを確立することができるようになる(ユーザ端末内にインストールされた所謂SIPユーザエージェント(UA)を使用して)。SIPシグナリングによって搬送されるセッション記述プロトコル(SDP)は,セッションのメディアコンポーネントを記述して交渉するために使用される。SIPはユーザ対ユーザのプロトコルとして作られたが,IMSにより,オペレータ及びサービスプロバイダは,サービスに対するユーザアクセスを制御し,それに応じてユーザに課金することができる。」 (2)上記G乃至Hの記載から引用文献2には次の技術的事項が記載されているといえる。「M2Mシステムにおいて,ブローカーのデータ処理負荷を軽減するために,タスクをアプリケーションに委譲し,アプリケーションがブローカーへサービスを要求すると,ブローカーは,TDP(信頼済データプロセッサ)の認証が成功した場合,データ鍵を生成しSN(センサネットワーク)に送信し,データ鍵をTDPの公開鍵を用いて暗号化しアプリケーションに送信しする。SNは,データを収集しデータ鍵を用いて暗号化し,暗号されたデータをTDPに送信する。TDPは秘密鍵を用いてデータ鍵を復号し,データ鍵を用いてデータを復元することを特徴とするM2Mシステム」 4.引用文献3 (1)原審拒絶理由に引用され,本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった国際公開第2010/107631号(翻訳文は特表2012-521045号公報)には,図面と共に次の事項が記載されている。 J.「[0040] Electronic devices, such as laptop or handheld computers, are frequently lost or stolen. For instance, FIG. 1 shows an example electronic device 102 being misappropriated. As shown in FIG. 1, a thief 104 steals or otherwise misappropriates electronic device 102 from a victim user 106. Although in the example of FIG. 1, electronic device 102 is shown as a laptop computer, electronic device 102 may be any of a variety of electronic devices capable of storing and/or processing data in electronic (e.g., digital) form, including a notebook computer, a mobile device such as a personal digital assistant (PDA), a cell phone, a smart phone (e.g., a RIM Blackberry^((R)) device, a Palm^((R)) Treo^(TM) device, etc.), etc. 【0021】ラップトップコンピュータまたはハンドヘルドコンピュータ等の電子機器は,紛失したり盗まれたりすることが多い。例えば,図1は,例示の電子機器102が不正使用されるところを示す。図1に示すように,盗人104は,被害者ユーザ106から電子機器102を盗む,または別の方法で不正使用する。図1の例では,電子機器102はラップトップコンピュータとして示されるが,電子機器102は,電子(例えば,デジタル)形式でデータを記憶および/または処理することが可能な様々な電子機器のいずれかとすることができ,これには,ノートブックコンピュータ,携帯情報端末(PDA)等の携帯用機器,携帯電話,スマートフォン(例えば,RIM社のBlackbeｒｒｙ(登録商標)の機器,Palm(登録商標)社のTｒeｏ(商標)の機器など)等,が含まれる。」 K.「[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. With reference to FIG. 12, electronic device 1200 may receive a remediation instruction (e.g., remediation message 418) during communication session 420 with management service 400. As described above, the instruction may alternatively be received from phone service provider 202, or in still another embodiment, the instruction may be generated internally to electronic device. [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. In another embodiment, suspicious activity detector module 1204 is configured to detect one or more suspicious activities that indicate electronic device 1200 may have been compromised. In the event that suspicious activity detector module 1204 detects a sufficient amount of suspicious activity, suspicious activity module 1204 may generate a remediation instruction 1212. Remediation instruction 1212 is received by device remediation module 1202, which instructs device remediation module 1202 to implement remediation policy 1214. Alternatively, instead of generating remediation instruction 1212, suspicious activity detector module 1204 may generate a suspicious activity indicator signal 1210, which may be transmitted to management service 204 (e.g., management service 400 of FIG. 4) in a communication signal 1216. As a result of receiving suspicious activity indicator signal 1210, management service 204 may perform various functions. For example, management service 204 may generate and provide remediation message 418 to electronic device 1200 in communication session 420, as described above. Management system 400 may be configured to contact admin user 216 (e.g., via email, text message, phone) at computer 210 or communication device 214 to alert an IT department, or to contact victim user 106 to inform victim user 106 (e.g., at a communication device of victim user 106) about electronic device 1200 being potentially compromised. Victim user 106 may then indicate whether electronic device 1200 is missing. Such policies for contacting a user may be different depending on the user's job and/or location. A company may have multiple policies tailored to different employee roles. [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. Remediation policy 1214 includes one or more remediation processes to be performed in the event that electronic device 102 is compromised. Remediation policy 1214 may be maintained in device remediation module 1202, or may be received from management system 400 with remediation message 418. [0091] Various remediation policies may be included in remediation policy 1214 that are performed by device remediation module 1202. For instance, FIG. 14 shows a flowchart 1400 providing a process for performing one or more remediation policies at a potentially compromised electronic device, according to an example embodiment. In an embodiment, a portion or the entirety of flowchart 1400 may be performed by device remediation module 1202 upon receipt of a remediation instruction. Any one or more of the steps shown in flowchart 1400 may be performed in embodiments. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart 1400. [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. 【0068】図10に示すように,フローチャート1300はステップ1302にて開始される。ステップ1302にて,修正ポリシを成立させる命令が受信される。図2を参照すると,一実施形態において,電子機器102は,管理サービス204から第2の通信信号220を受信することができ,通信信号220には電子機器102の修正を開始させる命令が含まれる。図12を参照すると,電子機器1200は,管理サービス400との通信セッション420の間に,修正命令(例えば,修正メッセージ418)を受信することができる。上述したように,命令は,代わりに電話サービスプロバイダ202から受信しても良く,または,さらに別の実施形態において,命令は,電子機器に対して内部的に生成されても良い。【0069】図12に示すように,ネットワークインターフェース1206は,電子機器1200をネットワーク206に通信リンク1208を介して通信可能に連結する。ネットワークインターフェース1206は,有線または無線の,任意のタイプのネットワークインターフェース(例えば,ネットワークインターフェースカード(NIC))とすることができ,例えば,IEEE802.11無線LAN(WLAN)無線インターフェース,Wi-MAX(Wｏｒldｗide Inｔeｒｏｐeｒabiliｔｙ fｏｒ Micｒｏｗaｖe Acceｓｓ)インターフェース,Eｔheｒneｔインターフェース,USB(Uniｖeｒｓal Seｒial Bｕｓ)インターフェースなどがある。【0070】一実施形態において,ネットワークインターフェース1206は,通信セッション420に加わり,修正メッセージ418を出力する。修正メッセージ418は機器修正モジュール1202により受信され,修正メッセージ418は,機器修正モジュール1202に命令して修正ポリシ1214を実装させる。別の実施形態において,不審動作検出モジュール1204は,電子機器1200が危険にさらされているかもしれないことを示す1つまたは複数の不審な動作を検出するように構成される。不審動作検出モジュール1204が十分な量の不審な動作を検出する事象において,不審動作検出モジュール1204は修正命令1212を生成することができる。修正命令1212は機器修正モジュール1202により受信され,修正命令1212は機器修正モジュール1202に命令して修正ポリシ1214を実装させる。あるいは,修正命令1212を生成する代わりに,不審動作検出モジュール1204は,不審動作指示信号1210を生成しても良く,この信号は,管理サービス204(例えば,図4の管理サービス400)に通信信号1216で送信することができる。不審動作指示信号1210を受信した結果,管理サービス204は種々の機能を実行することができる。例えば,管理サービス204は,修正メッセージ418を生成して,上述したように通信セッション420で電子機器1200に提供することができる。電子機器1200が潜在的に危険にさらされていることについて,運営ユーザ216に(例えば,電子メール,テキストメッセージ,電話,を介して)コンピュータ210または通信機器214にて連絡を取り,ITの部署に警告するように,または,被害者ユーザ106に連絡を取り,被害者ユーザ106に(例えば,被害者ユーザ106の通信機器にて)通知するように,管理システム400を構成することができる。被害者ユーザ106は次に,電子機器1200が紛失しているかどうかを示す。ユーザに連絡するためのこのようなポリシは,ユーザの仕事および/または場所によって異なっても良い。企業は,異なる従業員規則に適合する複数のポリシを持つことができる。【0071】ステップ1304にて修正ポリシが実行される。図12に示すように,修正メッセージ418または修正命令1212を受信した結果,機器修正モジュール1202は修正ポリシ1214等の1つまたは複数の修正ポリシを実装する。修正ポリシ1214には,電子機器102が危険にさらされている事象において実行される1つまたは複数の修正処理が含まれる。修正ポリシ1214は,機器修正モジュール1202において維持されること,または,修正メッセージ418と共に管理システム400から受信されること,とすることができる。【0072】種々の修正ポリシは,機器修正モジュール1202により実行される修正ポリシ1214内に含まれていても良い。例えば,図14は,例示の実施形態に従う,潜在的に危険にさらされている電子機器にて1つまたは複数の修正ポリシを実行するための処理を提供するフローチャート1400を示す。一実施形態において,フローチャート1400の一部または全体を,修正命令の受信時に機器修正モジュール1202により実行することができる。フローチャート1400に示される任意の1つまたは複数のステップは,実施形態において実行することができる。他の構造的および操作的な実施形態は,フローチャート1400に関する検討に基づき,当業者には明らかになるであろう。【0073】図14に示すように,フローチャート1400はステップ1402にて開始される。ステップ1402にて,少なくとも1つの暗号鍵が削除される。例えば,一実施形態において,機器修正モジュール1202を,ローカルな暗号鍵を削除してプライベートな暗号化されたデータのローカルコピーをアクセスされないように保護するように構成することができる。」 (2)上記J乃至Kの記載から,引用文献3には次の技術的事項が記載されているといえる。「携帯電話等の電子機器を紛失したり盗まれたりした際に,修正命令を送信し,電子機器が修正命令を受信すると修正ポリシが実行され,電子機器内の暗号鍵を削除する方法」 4.引用文献4 (1)原審拒絶理由に引用され,本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった特開2009-100249号公報には,図面と共に次の事項が記載されている。 L.「【0002】従来,通信端末装置間でデータを通信する際に,両装置間に少なくとも1つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている(例えば,特許文献1参照)。このマルチホップ通信は,両装置が通信可能な位置に無い場合であっても,間接的に両装置間で通信を行うことができる。例えば,赤外線通信機能や非接触IC通信機能などの近距離無線通信機能を備えた通信端末装置間でデータを通信する場合に,送信側と受信側の両方の装置が近距離(通信可能圏内)に存在していなければ,直接データを通信することはできないが,別の装置を中継装置として利用すれば,送信側の装置と中継装置とが通信可能な場合にデータ通信を行っておき,後で中継装置と受信側の装置とが通信可能となったときにデータを通信するようにすれば,結果的に送信側と受信側の装置間でデータ通信が行われたことになる。」 (2)上記Lの記載から,引用文献4には次の技術的事項が記載されているといえる。「通信端末装置間でデータを通信する際に,両装置間に少なくとも1つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている」第4.対比・判断 1.本願発明1 (1)対比あ.引用発明の「通信端末同士が直接通信する通信システムにおいて,他の通信端末に対応するハッシュ関数およびその鍵を,他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除することができる認証情報削除方法」と本願発明1の「マシン-対-マシン(Machine-ｔｏ-Machine:M2M)サービスにおいてデバイスまたはゲートウェイでブートストラップ(bｏｏｔｓｔｒaｐｐing)状態を消去する方法」とを対比すると, 引用発明の「通信端末同士が直接通信する通信システム」は,マシン-対-マシンのサービスを含んでいるといえ,本願発明1の「ブートストラップ(bｏｏｔｓｔｒaｐｐing)状態を消去する」ことは,サービス加入状態(デバイスに記憶済みの情報)を消去しているといえるので,引用発明の「他の通信端末の識別子およびアドレスに対応させて各通信端末の管理テーブルに保持された認証に必要な情報を一括で削除すること」は,“デバイスに記録済みの情報を消去する”点で共通するといえる。そうすると,両者は後記する点で相違するものの, “マシン-対-マシン(Machine-ｔｏ-Machine:M2M)サービスにおいてデバイスに記録済み状態を消去する方法”という点で一致する。い.引用発明の「ユーザから削除指示を受け取る第1の通信端末は,送信先の第2の通信端末が持っているハッシュ関数で,鍵を付加したメッセージを変換し,得られた値を認証コードとしてメッセージに添付し,削除命令メッセージを作成するステップと,第1の通信端末は削除命令メッセージを認証関係にある第2の通信端末に送信するステップと,第2の通信端末は,送られてきた削除命令メッセージを受信するステップと,」と本願発明1の「M2M認証サーバ(Aｕｔhenｔicaｔiｏn Seｒｖeｒ)(MAS)またはM2Mサービスブートストラップ機能部(M2M Seｒｖice Bｏｏｔｓｔｒaｐｐing Fｕncｔiｏn)(MSBF)から第1ペイロードを含む消去要請を受信するステップ」とを対比すると, 引用発明の「送信先の第2の通信端末が持っているハッシュ関数で,鍵を付加したメッセージを変換し,得られた値を認証コードとしてメッセージに添付」された「削除命令メッセージ」は本願発明の「第1ペイロードを含む消去要請」に対応することから,両者は,後記する点で相違するものの, “消去要請元から第1ペイロードを含む消去要請を受信するステップ”という点で一致する。う.引用発明の「第2の通信端末は,送られてきた削除命令メッセージ(認証コード部分を除く)に,自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換するステップ」と本願発明1の「前記消去要請の第1ペイロードに含まれるM2MノードID及びキーインデックスに基づいて秘密キーを獲得するステップと,前記秘密キー,前記M2MノードID及びキーインデックスに基づいて,第1ハッシュ値を生成するステップ」とを対比すると, 引用発明の「送られてきた削除命令メッセージ(認証コード部分を除く)に,自端末に格納されている鍵を付加して当該ハッシュ関数を用いて変換する」ことは,前記消去要請の第1のペイロードに含まれるメッセージに基づいて,第1ハッシュ値を生成しているといえるので,両者は,後記する点で相違するものの, “前記消去要請の第1のペイロードに含まれるメッセージに基づいて,第1ハッシュ値を生成するステップ”の点で一致する。え.引用発明の「変換後に得られた値と削除命令メッセージに付加されている値(認証コード)が一致すれば,正当な通信端末からのメッセージであると判断するステップ」と本願発明1の「前記第1ハッシュ値を前記消去要請に含まれた第2ハッシュ値とマッチングさせるステップ」とを対比すると, 引用発明の「変換後に得られた値」と「削除命令メッセージに付加されている値(認証コード)」は本願発明1の「第1ハッシュ値」と「消去要請に含まれた第2ハッシュ値」にそれぞれ相当し,引用発明の「一致すれば,正当な通信端末からのメッセージであると判断する」ことは,マッチングさせているといえるので,両者は後記する点で相違するものの, “前記第1ハッシュ値を前記消去要請に含まれた第2ハッシュ値とマッチングさせるステップ”という点で一致する。お.引用発明の「第2通信端末は,削除命令メッセージを正当なものと判断すると,応答メッセージを作成し第1の通信端末に返信し,自端末に格納されている管理テーブルを参照し,第1の通信端末の認証情報を削除するステップ」と本願発明1の「前記マッチングの結果に基づいて前記消去要請を処理するステップと,消去応答を前記MASまたは前記MSBFに送信するステップ」とを対比すると, 引用発明の「削除命令メッセージを正当なものと判断する」ことは,削除メッセージを正当なものと判断した結果であり,ハッシュ値をマッチング結果といえ,「自端末に格納されている管理テーブルを参照し,第1の通信端末の認証情報を削除する」ことは,削除命令メッセージの削除要請を処理しているといえ,引用発明の「応答メッセージを作成し第1の通信端末に返信」することは,消去応答を消去要請元へ送信しているといえるので,両者は,後記する点で相違するものの, “前記マッチング結果に基づいて前記消去要請を処理するステップと,消去応答を消去要請元へ送信するステップ”という点で一致する。か.上記あ.?お.の検討より,引用発明と本願発明1は,以下の点で一致し,相違する。＜一致点＞マシン-対-マシン(Machine-ｔｏ-Machine:M2M)サービスにおいてデバイスに記録済み状態を消去する方法であって, 消去要請元から第1ペイロードを含む消去要請を受信するステップと, 前記消去要請の第1のペイロードに含まれるメッセージに基づいて,第1ハッシュ値を生成するステップと, 前記第1ハッシュ値を前記消去要請に含まれた第2ハッシュ値とマッチングさせるステップと, 前記マッチング結果に基づいて前記消去要請を処理するステップと, 消去応答を消去要請元へ送信するステップと, を含むことを特徴とする記録済み状態消去方法。＜相違点1＞本願発明1ではマシン-対-マシン(Machine-ｔｏ-Machine:M2M)サービスにおいてデバイスまたはゲートウェイでブートストラップ(bｏｏｔｓｔｒaｐｐing)状態を消去する方法であるのに対して,引用発明では,通信端末同士における認証情報を削除方法である点。＜相違点2＞本願発明1では,M2MノードIDまたはキーインデックスに基づいて秘密キーを獲得し,秘密キーとM2MノードIDまたはキーインデックスのうちいずれか1つに基づいて,第1ハッシュ値を生成しているのに対して,引用発明では,通信端末に対応するハッシュ関数や鍵は管理テーブルに保持されているものから認証コード(第1ハッシュ値)を生成し,M2Mノードキーやキーインデックスについては明記されていない点。＜相違点3＞本願発明1では,前記第1ハッシュ値は,ハッシュ=ハッシュ関数(Kmｒ,M2MノードID｜キーインデックス｜N臨時｜類型)によって生成され, 前記「｜」は,連鎖を意味し,前記N臨時は,前記MASまたは前記MSBFによって生成された臨時値を含み,前記類型は,前記第1ペイロードの類型を表す類型値を含むと特定しているのに対して,引用発明では,宛先アドレス,送信元アドレス情報,メッセージタイプ,乱数値,削除命令フラグ,ハッシュ値から構成される削除命令メッセージを用いているものの,ハッシュ関数についてそのように特定されていない点。 (2)相違点に対する判断上記相違点2及び相違点3について検討すると,相違点2に係る構成は,M2MノードID及びキーインデクスに基づいて秘密キーを獲得する構成(以下,「秘密キーを獲得する構成」という)含んでおり,相違点3に係る構成は,第1のハッシュ値は,ハッシュ=ハッシュ(kmｒ(秘密キー),M2MノードID｜キーインデックス｜N臨時｜類型)(以下,「ハッシュ関数の構成」という)を含むものである。しかし,引用文献2(上記G,H参照)には「M2Mシステムにおいて,ブローカーのデータ処理負荷を軽減するために,タスクをアプリケーションに委譲し,アプリケーションがブローカーへサービスを要求すると,ブローカーは,TDP(信頼済データプロセッサ)の認証が成功した場合,データ鍵を生成しSN(センサネットワーク)に送信し,データ鍵をTDPの公開鍵を用いて暗号化しアプリケーションに送信しする。SNは,データを収集しデータ鍵を用いて暗号化し,暗号されたデータをTDPに送信する。TDPは秘密鍵を用いてデータ鍵を復号し,データ鍵を用いてデータを復元することを特徴とするM2Mシステム」が記載され,引用文献3(上記J,K参照)には「携帯電話等の電子機器を紛失したり盗まれたりした際に,修正命令を送信し,電子機器が修正命令を受信すると修正ポリシが実行され,電子機器内の暗号鍵を削除する方法」が記載され,引用文献4(上記L参照)には「通信端末装置間でデータを通信する際に,両装置間に少なくとも1つの通信端末装置を介して中継通信を行うマルチホップ通信システムが知られている」ことが記載されているものの,上記秘密キーを獲得する構成及びハッシュ関数の構成は記載されておらず,引用発明の「宛先アドレス情報と,送信元アドレス情報と,メッセージタイプと,乱数値と,削除命令フラグと,ハッシュ値から構成される削除メッセージ」から当業者が容易に想到し得ることともいえない。したがって,その他の相違点について判断するまでもなく,本願発明1は,当業者あっても,引用発明,引用文献2乃至4に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 2.本願発明2?4について本願発明2?4は,本願発明1を減縮した発明であるから,本願発明1の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 3.本願発明5について本願発明5は,本願発明1に対応する消去要請を送信する側の方法の発明である。しかし,本願発明5は,本願発明1の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 4.本願発明6?8について本願発明6?8は,本願発明5を減縮した発明である。即ち,本願発明6?8は,本願発明1の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。 5.本願発明9?16について本願発明9は,本願発明1に対応するデバイスまたはゲートウェイの発明である。本願発明10?12は,本願発明9を減縮する発明である。本願発明13は,本願発明5に対応するデバイスまたはゲートウェイの発明である。本願発明14?16は,本願発明13を減縮した発明である。即ち,本願発明9?16は,本願発明1の「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2乃至4に記載された技術的事項に基づいて容易に発明できたものとはいえない。第5.原査定の概要および原査定の判断原査定は,請求項1-20について上記引用文献1-4に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができないというものである。しかしながら,平成29年3月28日付けの手続補正により補正された請求項1-16は,「秘密キーを獲得する構成」及び「ハッシュ関数の構成」を備えるものとなっており,引用発明及び上用文献2-4に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。したがって,原査定を維持するこはできない。第6.当審拒絶理由について当審では,請求項2,6,10,14の「第1ペイロード」が情報要素を「少なくとも1つを含み」という点は,「第1ペイロード」に含まれない情報要素を何処から如何に獲得するのか不明りょうであり,発明の詳細な説明には当業者が実施できるように記載されていないという拒絶の理由を通知しているが,平成30年3月26日の手続補正において「前記第1ペイロード」は,「少なくとも」各情報要素を含む態様に補正された結果,この拒絶理由は解消した。また,当審では,請求項4,8,12,16の「M2Mノード」と当該請求項が従属する請求項の「M2MノードID」における「M2Mノード」との対応が不明りょうであるとの拒絶の理由を通知しているが,平成30年3月26日付け手続補正で「M2Mノード」を「ネットワークM2Mノード」と補正された結果,この拒絶理由は解消した。第7.むすび以上のとおり,本願発明1-16は,当業者が引用発明及び引用文献2-4に記載された技術的事項に基づいて容易に発明することができたものではない。したがって,原査定の理由によっては,本願を拒絶することはできない。また,他に本願を拒絶すべき理由を発見しない。よって,結論のとおり審決する。
審決日	2018-05-25
出願番号	特願2014-505088(P2014-505088)
審決分類	P 1 8・ 121- WY (H04L) P 1 8・ 537- WY (H04L) P 1 8・ 536- WY (H04L)
最終処分	成立
前審関与審査官	宮司卓佳、上島拓也
特許庁審判長	石井茂和
特許庁審判官	仲間晃高木進
発明の名称	マシン-対-マシンノード消去手順
代理人	実広信哉
代理人	木内敬二
代理人	崔允辰
代理人	阿部達彦

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ