• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L
管理番号 1315544
審判番号 不服2014-11262  
総通号数 199 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-07-29 
種別 拒絶査定不服の審決 
審判請求日 2014-06-13 
確定日 2016-06-07 
事件の表示 特願2011-526450「ネットワークノード間のデータ伝送方法」拒絶査定不服審判事件〔平成22年 3月18日国際公開,WO2010/028936,平成24年 1月26日国内公表,特表2012-502572〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2009年8月19日(パリ条約による優先権主張外国庁受理2008年9月10日 ドイツ連邦共和国)を国際出願日とする出願であって,
平成23年3月10日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に同日付けで審査請求がなされ,平成24年12月25日付けで審査官により拒絶理由が通知され,これに対して平成25年5月10日付けで意見書が提出されると共に手続補正がなされ,平成25年8月8日付けで審査官により拒絶理由が通知され,これに対して平成26年1月20日付けで意見書が提出されたが,平成26年2月26日付けで審査官により拒絶査定がなされ(発送;平成26年3月3日),これに対して平成26年6月13日付けで審判請求がなされ,平成27年7月6日付けで当審により拒絶理由が通知され,平成27年10月27日付けで意見書が提出されると共に手続補正がなされたものである。

第2.本願発明について
本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成27年10月27日付けの手続補正により補正された,特許請求の範囲の請求項1に記載された,次のとおりのものである。

「中央管理ネットワークノード(2-0)を備えたネットワーク(1)の,送信ネットワークノード(2-1)としても受信ネットワークノード(2-2)としても動作可能な各ネットワークノード(2)間においてデータを暗号化により保護して送信および受信するための方法において,
送信ネットワークノード(2-1)が,
a)メッセージ(F)の送信時に更新されるカウンタ値(CTR)と,前記中央管理ネットワークノード(2-0)によって提供され,且つ,前記ネットワーク(1)の前記中央管理ネットワークノード(2-0)以外のネットワークノード(2-i)が使用する共通の一定値(EANCV)と,からnonce値(N)を形成するステップと,
b)前記データを,暗号化鍵(K)と形成された前記nonce値(N)とを用いて暗号化して,前記暗号化されたデータを有する有効データ(PL)と,前記送信ネットワークノード(2-1)の目下のカウンタ値(CTR)を有するヘッダデータ(HDR)と,を前記メッセージ(F)として送信するステップと,
を実施し,
受信ネットワークノード(2-2)が,
c)前記メッセージ(F)を受信し,該受信したメッセージ(F)から前記カウンタ値(CTR)を抽出し,前記カウンタ値(CTR)と前記一定値(EANCV)とを用いて受信側のnonce値(N’)を形成し,該形成された受信側のnonce値(N’)と鍵(K)とを用いて前記受信したメッセージ(F)のデータを復号するステップを実施し,
前記中央管理ネットワークノード(2-0)が,
新たな共通の一定値(EANCV)を送信するステップを実施し,
前記共通の一定値(EANCV)を,前記新たな共通の一定値(EANCV)によって置換するステップを実施する,
方法。」

第3.引用刊行物に記載の事項
1.当審が,平成27年7月6日付けの拒絶理由通知(以下,これを「当審拒絶理由」という)において,引用刊行物1として引用した,本願の第1国出願前に既に公知である,米国特許出願公開第2008/0044014号明細書(2008年2月21日公開)には,関連する図面と共に,次の事項が記載されている。

A.「[0044] The BAN key will in certain key embodiments be communicated securely from in-vivo devices, particularly, implants such as IMD 115 to other in-vitro “bridge” devices 110 in a BAN 100. The BAN key should also be communicated securely from bridge devices 110 in a BAN 100 to implants 115. According to embodiments of the present invention, there is an underlying communications session 120, which may be unsecured, providing communication between two in-vitro devices 110, or between in-vivo device 115 and in-vitro device 110. Secure communications, such security including encryption as well as integrity and freshness confirmation, is provided by means of authentication material held by the implanted device 115. Implant devices 115 deliver the BAN key to bridge devices 110 who possess the appropriate authentication material 160 and processes such as random number generating facility 165. Implanted devices 115 can also receive the BAN key from bridge devices 110 who possess the appropriate authentication material 160 and processes. According to embodiments of the present invention, the following protocols permit secure and wireless delivery of the BAN key to bridge devices capable of using the security protocol of the present invention.」(下線は,当審にて,説明の都合上,附加したものである。以下,同じ。)
(【0028】
BANキーは,特定のキーの実施形態では,体内デバイス,特にIMD115等の埋め込み物から,BAN100の他の体外「ブリッジ」デバイス110へセキュアに通信される。また,BANキーは,BAN100のブリッジデバイス110から埋め込み物115へもセキュアに通信されるべきである。本発明の実施形態によれば,2つの体外デバイス110間の通信又は体内デバイス115と体外デバイス110との間の通信を提供する基礎となる通信セッション120が存在する。この通信セッション120は,セキュアにされていない場合がある。セキュア通信(このようなセキュリティは,暗号化だけでなく完全性及び新しさの確証も含む)は,埋め込まれたデバイス115によって保持された認証マテリアルによって提供される。埋め込みデバイス115は,BANキーをブリッジデバイス110へ配信する。ブリッジデバイス110は,適切な認証マテリアル160と,乱数生成ファシリティ165等のプロセスとを所有する。埋め込まれたデバイス115は,適切な認証マテリアル160とプロセスとを所有するブリッジデバイス110からBANキーを受信することもできる。本発明の実施形態によれば,以下のプロトコルによって,本発明のセキュリティプロトコルを使用できるブリッジデバイスへのBANキーのセキュアな無線配信が可能になる。<引用刊行物1のファミリーである,特表2010-507928号公報の当該箇所より引用。以下,同じ。>)

B.「[0065] In this embodiment, generation of every (i+1)^(th) PRN proceeds as follows: The block cipher 620 (in this example, 128-bit AES) is used to encrypt a nonce 625 using K_(R) 610 as the key input 615 , as depicted in FIG.6. The nonce 625 , which could, for example, consist of the node's current real-time clock value, may be loaded into the 128-bit data_i input 630 of the block cipher 620 by way of a 128-bit register. (If the real-time clock is longer than 128 bits, then the least-significant 128 bits of the real-time clock may be used.) If the real-time clock is shorter than 128 bits, the most-significant bits of the nonce 625 may be padded with zeros such that the number of zeros plus the number of real-time clock bits equals 128. Whether or not the real-time clock is used to generate the nonce 625 the intermediate value data_o 635 outputted from the block cipher 620 may be called V_(1) 640 herein.」
(【0057】
この実施形態では,あらゆる(i+1)番目のPRNの生成は,次のように進行する。すなわち,図6に示すように,ブロック暗号620(この例では,128ビットAES)が,キー入力615としてK_(R)610を使用してノンス625を暗号化するのに使用される。ノンス625は,たとえば,そのノードの現在のリアルタイムクロック値から構成することができ,128ビットレジスタを経由してブロック暗号620の128ビットdata_i入力630にロードすることができる。(リアルタイムクロックが,128ビットよりも長い場合には,リアルタイムクロックの最下位128ビットを使用することができる。)リアルタイムクロックが128ビットよりも短い場合には,0の個数にリアルタイムクロックのビット数を加えたものが128に等しくなるように,ノンス625の最上位ビットを0でパッディングすることができる。リアルタイムクロックが,ノンス625を生成するのに使用されようとされまいと,ブロック暗号620から出力される中間値data_o635は,本明細書では,V_(1)640と呼ばれる場合がある。)

C.「[0076] As described, the securing of information in certain embodiments may be based on ciphers, including by the use of block ciphers, for example, used in their counter(CTR) mode. In this way, the block cipher may be applied to streams in that the block cipher generates a keyed, pseudo-random keystream which is then XORed against the plaintext in order to generate encrypted text (or, at the recipient node, applied against the ciphertext to generate plaintext to effect decryption). FIG.11 shows the data flow of the CTR-mode encryption and decryption of a message according to embodiments of the present invention. As depicted, the shared session key 1030 is loaded into the key_i input 615 of the block cipher 620 by way of a 128-bit register; the session key 1030 may be loaded into the register from memory or storage (after being calculated at the initiation of a secure session as discussed above). A 128-bit nonce (i.e., a number used only once) 1110 is loaded into the data_i input 630 of the block cipher 620 by way of another 128-bit register.」
(【0071】
説明したように,特定の実施形態で情報をセキュアにすることは,たとえばカウンタ(CTR)モードで使用されるブロック暗号が使用されることを含めて,暗号に基づくことができる。このように,ブロック暗号は,キー付き疑似乱数キーストリームを生成するという点で,ストリームに適用することができる(又は,受信側ノードにおいて,平文を生成して解読を行うために暗号文に対して適用することができる)。このキー付き疑似乱数キーストリームは,その後,暗号化文を生成するために平文に対してXORされる。図11は,本発明の実施形態によるメッセージのCTRモードの暗号及び解読のデータフローを示している。図示するように,共有セッションキー1030は,128ビットレジスタを経由してブロック暗号620のkey_i入力615にロードされ,セッションキー1030は,(上述したように,セキュアセッションの開始時に計算された後)メモリ又はストレージからレジスタにロードすることができる。128ビットノンス(すなわち,1回だけ使用される数)1110は,別の128ビットレジスタを経由して,ブロック暗号620のdata_i入力630にロードされる。)

D.引用刊行物1のFIG.11には,「session-key register1030」からの出力である「key_i」と,「nonce register1110」からの出力である「data_i」とを,「128-bit AES」に入力し,前記「128-bit AES」の出力である「data_o」(上記Cにおける「キー付き疑似乱数ストリーム)と,「enc./dec. data blocks」との排他的論理和を計算することで,「dec./enc. data blocks」を得る点が示されている。

2.当審拒絶理由において,引用刊行物2として引用した,特開2005-346659号公報(2005年12月15日公開)には,関連する図面と共に,次の事項が記載されている。

E.「【0032】
端末2は,詳しくは,ユーザがサービス提供システム5から所定のサービスを受ける際に,機密情報管理システム1から送信されたカウンタ値n及び乱数種初期値r_(0)を用いて,再分割データD’(3)を生成するために使用される乱数R’のシード(乱数生成の種となる情報)r_(n)を生成する乱数種生成部22,再分割データD’(3)を生成するために使用される乱数R’を上述したシードr_(n)及び所定の疑似乱数アルゴリズムGに基づいて生成する乱数生成部22,上述した乱数R’及び機密情報管理システム1から送信された分割データD(3)から,秘密分散法Aを用いて再分割データD’(3)を生成する再分割データ生成部23,並びに,機密情報管理システム1及びサービス提供システム5それぞれとデータの送受信を行う通信部24を具備する構成となっている。」

3.当審拒絶理由において,引用刊行物3として引用した,特開2008-172282号公報(2008年7月24日公開)には,関連する図面と共に,次の事項が記載されている。

F.「【0041】
時計の代わりにカウンタを使う例を説明する。時刻を入力とする乱数発生器の場合は,同じシードで一定時間ごとに乱数値を更新する。あるいは,シードと時刻を入力して乱数値を得る。時刻を用いる場合と同様に,カウント値を入力して,カウント値に対応した乱数を得ることができる。カウント値を入力とする乱数発生器の場合は,位置サーバ(例えばICタグ)では,位置情報を発行するたびに,カウンタの値を更新し,擬似乱数を更新する。センタでは,位置サーバ(タグ)の固定の識別情報と,カウント値を受け取る。センタでは,位置サーバの識別情報に基づいて,擬似乱数生成器やシードを選択する。擬似乱数生成器を初期値から起動して,カウント値の回数だけ更新する。このようにして,位置サーバと同じ乱数値を得る。」

4.当審拒絶理由において,引用刊行物4として引用した,特開2001-7800号公報(2001年1月12日公開)には,関連する図面と共に,次の事項が記載されている。

G.「【0028】図2に示すように,KSはまた,データのシーケンスとして定義されたナンスNを受信することができる。この場合,ある特定のキーに対して,特定の値が2度現れる確率が無視できるほど小さい。例えば,ナンスは,特定のキーの基で単一のメッセージの暗号化中に常時カウントアップするカウンタから導出することができる。したがって,メッセージの暗号化中に用いられるナンスの各値は一意である。ナンスの他の例については後述する。」

H.「【0072】図29において,放送システムでは,放送局BSTNが,番組キーとナンスとを生成する。このナンスは,番組識別子と,その番組が数フレームに分割される際のコンテンツデータのフレーム番号とからなる。このコンテンツデータは,当該キーおよびナンスを用いて暗号化される。・・・(中略)・・・
【0074】図31における,図25により説明したようなディスク暗号化システムの実現例では,ファイルは異なるキーで暗号化される。その際,各ナンスは,時刻スタンプ付きファイル名と所有者の識別子からなる。CPUは,メモリDMEMに格納され,図25により説明された暗号化アルゴリズムを実行する。秘密キーは,暗号化システムの操作者がスマートカード上に保持する。
【0075】図32は,図25により説明した暗号化アルゴリズムの,データベース暗号化システムへの他の応用例を示す。このシステムでは,ナンスは,IDと,カテゴリと,改訂番号(revision number)または時刻スタンプとからなる。
【0076】図33は,図25により説明した暗号化アルゴリズムの,マルチメディア配信システムの用途への他の応用例を示す。CD-ROMやDVD-ROM上の内容は,秘密キーKとナンスN1とを用いて暗号化される。このナンスは,例えば,日付つきの番組名とバージョン番号とを連結したものである。(以下略)」

5.当審拒絶理由において,引用刊行物5として引用した,特開2008-77664号公報(2008年4月3日公開)には,関連する図面と共に,次の事項が記載されている。

I.「【0011】
一実施形態においては,ナンスはサーバによって知られている。サーバは,例えば,通信セッションの開始時に,クライアント・システムからのナンスを受信し得る。代替的には,サーバは,通信セッションの開始前にクライアントのナンスに気付いているかも知れない。ナンスは,例えば,ナンスが導出され得るシード(seed:発生源)によってサーバにより知られるかもしれない。」

6.当審拒絶理由において,引用刊行物9として引用した,国際公開第2007/046376号(2007年4月26日国際公開)には,次の事項が開示されている。

J.「



7.本願の第1国出願前に既に公知である,特開2004-312772号公報(2004年11月4日公開,以下,これを「周知技術文献」という)には,次の事項が記載されている。

K.「【0004】
シードは,ブロードキャストモードでトランスポートデータストリームTDSにおいて配信される(すなわち,全てのデコーダは同時にシードを受け取る)。可能な限りのデータ著作権侵害者からの開発を避けるためにシードは暗号化されなければならない。シードは,マルチセッションキーMSKを用いて暗号器24で暗号化され,暗号化されたシードEMSK(SEED)を提供する。マルチセッションキーMSKはサービス配信器16からくる。暗号化されたシードEMSK(SEED)は,マルチプレクサ20によってブロードキャストモードでトランスポートデータストリームTDSに配置される。好ましくは,シードは,頻繁に,例えば,10回/秒で変更される。従って,暗号化されたシードEMSK(SEED)は,すべてのデコーダ40へ,例えば,10回/秒でブロードキャストされる。シードを復元するために,デコーダ40はマルチセッションキーMSKへのアクセスを得なければならない。」

第4.引用刊行物に記載の発明
1.上記Aの「The BAN key will in certain key embodiments be communicated securely from in-vivo devices, particularly, implants such as IMD 115 to other in-vitro “bridge” devices 110 in a BAN 100(BANキーは,特定のキーの実施形態では,体内デバイス,特にIMD115等の埋め込み物から,BAN100の他の体外「ブリッジ」デバイス110へセキュアに通信される)」という記載と,同じく,上記Aの「Implanted devices 115 can also receive the BAN key from bridge devices 110 who possess the appropriate authentication material 160 and processes(埋め込まれたデバイス115は,適切な認証マテリアル160とプロセスとを所有するブリッジデバイス110からBANキーを受信することもできる)」という記載から,引用刊行物1は,“体内デバイス等から,ブリッジデバイスへの,及び,ブリッジデバイスから,体内デバイスへの,セキュア通信”に関するものであることが読み取れ,上記引用のAの記載内容と,上記Cの「or, at the recipient node, applied against the ciphertext to generate plaintext to effect decryption(又は,受信側ノードにおいて,平文を生成して解読を行うために暗号文に対して適用することができる)」という記載から,「体内デバイス等」,或いは,「ブリッジデバイス」が「受信側ノード」であり,例えば,「ブリッジデバイス」が,「受信側ノード」であるとき,「体内デバイス等」は,「送信側ノード」と言えるので,上記引用のAの記載内容を踏まえると,引用刊行物1における「体内デバイス等」と,「ブリッジデバイス」とは,“送信側ノードにも受信側ノードにもなり得るノード”と言えるものである。
よって,上記に引用の引用刊行物1の記載内容から,引用刊行物1は,“送信側ノードにも受信側ノードにもなり得るノード間の,セキュア通信を行うための方法”に関するものであることが読み取れる。

2.上記Bの「If the real-time clock is shorter than 128 bits, the most-significant bits of the nonce 625 may be padded with zeros such that the number of zeros plus the number of real-time clock bits equals 128(リアルタイムクロックが128ビットよりも短い場合には,0の個数にリアルタイムクロックのビット数を加えたものが128に等しくなるように,ノンス625の最上位ビットを0でパッディングすることができる)」という記載から,引用刊行物1は,“リアルタイムクロックと,パディングデータとからノンスを生成する”態様を含むものであることが読み取れる。

3.上記Cの「the securing of information in certain embodiments may be based on ciphers, including by the use of block ciphers, for example, used in their counter(CTR) mode(特定の実施形態で情報をセキュアにすることは,たとえばカウンタ(CTR)モードで使用されるブロック暗号が使用されることを含めて,暗号に基づくことができる)」という記載,同じく上記Cの「pseudo-random keystream which is then XORed against the plaintext in order to generate encrypted text(このキー付き疑似乱数キーストリームは,その後,暗号化文を生成するために平文に対してXORされる)」という記載,同じく,上記Cの「FIG.11 shows the data flow of the CTR-mode encryption and decryption of a message according to embodiments of the present invention(図11は,本発明の実施形態によるメッセージのCTRモードの暗号及び解読のデータフローを示している)」という記載,同じく,上記Cの「the shared session key 1030 is loaded into the key_i input 615 of the block cipher 620 by way of a 128-bit register(共有セッションキー1030は,128ビットレジスタを経由してブロック暗号620のkey_i入力615にロードされ)」という記載,同じく,上記Cの「A 128-bit nonce (i.e., a number used only once) 1110 is loaded into the data_i input 630 of the block cipher 620 by way of another 128-bit register(128ビットノンス(すなわち,1回だけ使用される数)1110は,別の128ビットレジスタを経由して,ブロック暗号620のdata_i入力630にロードされる)」という記載,及び,上記Dにおいて指摘した,引用刊行物1のFIG.11に開示されている事項と,上記1.において検討した事項から,引用刊行物1においては,“通信をセキュアにするために,CTRモードを用いて,共有セッションキーと,128ビットノンスを,ブロック暗号に入力して,鍵付き暗号ストリームを生成し,前記鍵付きストリームと,通信される情報との,排他的論理和を計算することで,前記情報を暗号化する”ことが,読み取れる。

4.上記Cの「or, at the recipient node, applied against the ciphertext to generate plaintext to effect decryption(又は,受信側ノードにおいて,平文を生成して解読を行うために暗号文に対して適用することができる)」という記載,及び,上記Dにおいて指摘した,引用刊行物1のFIG.11に開示されている事項と,上記3.において検討した事項から,引用刊行物1においては,“受信側ノードにおいて,暗号化されて送信されてきた情報を,共有セッションキーと,128ビットノンスから生成される,鍵付きストリームとの排他的論理和を計算することで,復号する”ことが読み取れる。
そして,上記において検討した事項は,「受信側ノード」における処理に関するものであるから,上記3.において検討した事項が,「送信側ノード」における処理に関するものであることは,明らかである。
また,上記Dにおいて指摘した,引用刊行物1のFIG.11に開示されている事項から明らかなように,復号を成功させるためには,送信側ノードと,受信側ノードにおいて,同一のノンス値が用いられることも,明らかである。

以上1.?4.において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

送信側ノードにも受信側ノードにもなり得るノード間の,セキュア通信を行うための方法であって,
送信側ノードにおいて,
リアルタイムクロックと,パディングデータとから128ビットノンスを生成し,
通信をセキュアにするために,CTRモードを用いて,共有セッションキーと,前記128ビットノンスを,ブロック暗号に入力して,鍵付き暗号ストリームを生成し,前記鍵付きストリームと,送信される情報との,排他的論理和を計算することで,前記情報を暗号化し,
受信側ノードにおいて,
送信側ノードと同一の128ビットノンスを生成し,
暗号化されて送信されてきた情報を,前記共有セッションキーと,前記128ビットノンスから生成される,前記鍵付きストリームとの排他的論理和を計算することで,復号する,方法。

第5.本願発明と引用発明との対比
1.引用発明において,「セキュア通信」は,「送信される情報」を「暗号化」することで実現されるものであって,
引用発明における「送信側ノード」,「受信側ノード」が,本願発明における「送信ネットワークノード(2-1)」,「受信ネットワークノード(2-2)」に相当するので,
引用発明における「送信側ノードにも受信側ノードにもなり得るノード間の,セキュア通信を行うための方法」と,
本願発明における「中央管理ネットワークノード(2-0)を備えたネットワーク(1)の,送信ネットワークノード(2-1)としても受信ネットワークノード(2-2)としても動作可能な各ネットワークノード(2)間においてデータを暗号化により保護して送信および受信するための方法」とは,
“送信ネットワークノードとしても受信ネットワークノードとしても動作可能な各ネットワークノード間においてデータを暗号化により保護して送信および受信するための方法”
である点で共通する。

2.引用発明における「送信される情報」が,本願発明における「メッセージ」に相当し,
引用発明における「リアルタイムクロック」は,「送信される情報」が,送信される時点で更新されることは明らかであるから,本願発明における「カウンタ値」と,
“メッセージが送信される時に更新されるデータ”である点で共通し,
引用発明における「128ビットノンス」と,本願発明における「nonce値(N)」とは,“ノンス値”である点で共通し,
引用発明における「パディングデータ」は,“ノンス値を生成するためのデータ”である点で,本願発明における「ネットワークノード(2-i)が使用する共通の一定値(EANCV)」と共通するので,
引用発明における「送信側ノードにおいて,リアルタイムクロックと,パディングデータとから128ビットノンスを生成」することと,
本願発明における「送信ネットワークノード(2-1)が,a)メッセージ(F)の送信時に更新されるカウンタ値(CTR)と,前記中央管理ネットワークノード(2-0)によって提供され,且つ,前記ネットワーク(1)の前記中央管理ネットワークノード(2-0)以外のネットワークノード(2-i)が使用する共通の一定値(EANCV)と,からnonce値(N)を形成するステップ」とは,
“送信ネットワークノードが,メッセージが送信される時に更新されるデータと,ノンス値を生成するためのデータとからノンス値を生成するステップ”である点で共通する。

3.引用発明における「共有セッションキー」は,「送信側ノード」における「暗号化」にも,「受信側ノード」における「復号」にも,共通して用いられているので,本願発明における「暗号化鍵(K)」に相当し,
引用発明においても,「共有セッションキー」と,「128ビットノンス」から「鍵付き暗号ストリームを生成し」て,「送信される情報」を暗号化しているので,“共有セッションキーと128ビットノンスを用いて,送信される情報を暗号化”していて,該“暗号化された情報”は,「受信側ノード」に送信されるものであるから,
引用発明においては,“共有セッションキーと128ビットノンスを用いて,送信される情報を暗号化し,前記暗号化した情報を,受信側ノードに送信する”ものである。
よって,本願発明における「b)前記データを,暗号化鍵(K)と形成された前記nonce値(N)とを用いて暗号化して,前記暗号化されたデータを有する有効データ(PL)と,前記送信ネットワークノード(2-1)の目下のカウンタ値(CTR)を有するヘッダデータ(HDR)と,を前記メッセージ(F)として送信するステップ」と,
“メッセージとして送信されるデータを,暗号化鍵と,形成されたノンス値とを用いて暗号化して送信するステップ”である点で共通する。

4.引用発明において,「受信側ノード」で,「暗号化されて送信されてきた情報」を復号している以上,該「受信側ノード」が,「暗号化されて送信されてきた情報」を“受信”していることは明らかであるから,
このことが,本願発明における「受信ネットワークノード(2-2)が,c)前記メッセージ(F)を受信し,」に相当し,
そして,引用発明において,「送信側ノードと同一の128ビットノンスを生成」することとは,
引用発明における「ノード」が,「送信側ノードにも受信側ノードにもなり得るノード」であることから,「受信側ノード」においても,「送信側ノード」と同じく,「リアルタイムクロックと,パディングデータとから128ビットノンスを生成」していることは明らかであるから,上記2.に検討した,「送信側ノード」における「ノンス値」の生成に関する点を踏まえると,
引用発明における「受信側ノードにおいて,送信側ノードと同一の128ビットノンスを生成」することと,
本願発明における「該受信したメッセージ(F)から前記カウンタ値(CTR)を抽出し,前記カウンタ値(CTR)と前記一定値(EANCV)とを用いて受信側のnonce値(N’)を形成」することとは,
“メッセージが送信される時に更新されるデータと,ノンス値を生成するためのデータとから受信側のノンス値を形成”する点で共通し,
引用発明における「暗号化されて送信されてきた情報を,前記共有セッションキーと,前記128ビットノンスから生成される,前記鍵付きストリームとの排他的論理和を計算することで,復号する」ことと,
本願発明における「形成された受信側のnonce値(N’)と鍵(K)を用いて前記受信したデータを復号化するステップ」とは,
“形成された受信側のノンス値と,暗号化鍵を用いて,受信した暗号化されたメッセージを復号するステップ”である点で共通する。

以上1.?4.において検討した事項から,本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
送信ネットワークノードとしても受信ネットワークノードとしても動作可能な各ネットワークノード間においてデータを暗号化により保護して送信および受信するための方法において,
送信ネットワークノードが,
メッセージが送信される時に更新されるデータと,ノンス値を生成するためのデータとからノンス値を生成するステップと,
メッセージとして送信されるデータを,暗号化鍵と,形成されたノンス値とを用いて暗号化して送信するステップとを実施し,
受信ネットワークノードが,前記メッセージとして送信されたデータを受信し,メッセージが送信される時に更新されるデータと,ノンス値を生成するためのデータとから受信側のノンス値を形成し,前記形成された受信側のノンス値と,暗号化鍵を用いて,受信した暗号化されたメッセージを復号するステップを実施する,方法。

[相違点1]
“送信ネットワークノードとしても受信ネットワークノードとしても動作可能な各ネットワークノード間においてデータを暗号化により保護して送信および受信するための方法”に関して,
本願発明においては,「中央管理ネットワークノードを備えた」ものであるのに対して,
引用発明においては,「中央管理ネットワークノード」については,言及されていない点。

[相違点2]
“メッセージが送信される時に更新されるデータ”に関して,
本願発明においては,「メッセージ(F)の送信時に更新されるカウンタ値(CTR)」であるのに対して,
引用発明においては,「リアルタイムクロック」である点。

[相違点3]
“ノンス値を生成するためのデータ”に関して,
本願発明においては,「中央管理ネットワークノード(2-0)によって提供され,且つ,前記ネットワーク(1)の前記中央管理ネットワークノード(2-0)以外のネットワークノード(2-i)が共通して使用する一定値(EANCV)」であるのに対して,
引用発明においては,「パディングデータ」である点。

[相違点4]
“形成されたノンス値”に関して,
本願発明においては,“カウンタ値(CTR)と,一定値(EANCV)とから形成されたnonce値(N)”であるのに対して,
引用発明においては,“リアルタイムクロックと,パディングデータから形成されたノンス”である点。

[相違点5]
本願発明においては,「暗号化されたデータを有する有効データ(PL)と,前記送信ネットワークノード(2-1)の目下のカウンタ値(CTR)を有するヘッダデータ(HDR)と,を前記メッセージ(F)として送信する」ものであるのに対して,
引用発明においては,「リアルタイムクロック」を「ヘッダデータ」として送信する点に関する言及がない点。

[相違点6]
“メッセージが送信される時に更新されるデータと,ノンス値を生成するためのデータとから受信側のノンス値を形成”する点に関して,
本願発明においては,「受信したデータと前記一定値(EANCV)とを用いて受信側のnonce値(N’)を形成」するものであるのに対して,
引用発明においては,受信側ノード」において,「リアルタイムクロック」と,「パディングデータ」を用いて「ノンス」を生成している点。

[相違点7]
本願発明においては,「中央管理ネットワークノード(2-0)が,新たな共通の一定値(EANCV)を送信するステップを実施し,前記共通の一定値(EANCV)を,前記新たな共通の一定値(EANCV)によって置換する」ものであるのに対して,
引用発明においては,「新たな共通の一定値を送信」し,当該「新たな共通の一定値によって置換する」ことに関しては,言及されていない点。

第6.相違点についての当審の判断
1.[相違点1],及び,[相違点3]について
上記Eとして引用した,引用刊行物2の記載内容にもあるとおり,ネットワーク内に,“管理ノード”を設けることは,本願の第1国出願前に,当業者には周知の技術事項であり,このとき,前記“管理ノード”から,セキュリティ処理に必要なデータを,“ノード”が受信するよう構成することも,上記Eに記載された内容からみて,当業者には周知の技術事項である。
したがって,引用発明においても,「送信側ノード」,「受信側ノード」の他に,“管理ノード”を設け,該“管理ノード”から,「ノンス」の形成に必要な,「ノード」共通のデータを受信するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点1],及び,[相違点3]は,格別のものではない。

2.[相違点2],及び,[相違点4]について
上記Eの記載内容,或いは,上記Fとして引用した,引用刊行物3の記載内容,更に,上記Gとして引用した,引用刊行物4の記載内容にもあるとおり,疑似乱数生成に「カウンタ値」を用いることは,周知の技術事項であり,上記Fの記載にもあるとおり,「時計」,即ち,「クロック」に換えて,「カウンタ値」を用いることも,当業者には,広く知られた技術事項である。
そして,引用発明における「ノンス」は,“乱数”を含むものであることも,当業者には周知の技術事項であるから,引用発明において,「リアルタイムクロック」に換えて,「カウンタ値」を用いるよう構成することは,当業者が適宜なし得る事項である。
更に,上記Hとして引用した,引用刊行物4の記載内容から,「カウンタ値」,「乱数」以外を用いて,「ノンス」を形成することも,本願の第1国出願前に,当業者には周知の技術事項であるから,上記1.において検討した事項を踏まえると,引用発明において,「ノンス」を生成する際に,前記「カウンタ値」に加えて,「パディングデータ」に換えて,“管理ノード”から送られた“「ノード」共通のデータ”を用いることも,当業者が必要に応じて,適宜なし得る事項である。
よって,[相違点2],及び,[相違点4]は,格別のものではない。

3.[相違点5]について
上記Jとして引用した,引用刊行物9の記載内容にもあるとおり,送信するデータのヘッダに「カウンタ値」,データ部に“暗号化されたデータ”を配置する点については,本願の第1国出願前に,当業者には周知の技術事項である。
したがって,引用発明においても,受信側で「ノンス値」を生成するのに必要な情報を,送信データのヘッダに添付して送信するよう構成することは,当業者が適宜なし得た事項である。
よって,[相違点5]は,格別のものではない。

4.[相違点6]について
上記Iとして引用した,引用刊行物5の記載内容において,「サーバ」は,“受信側”,「クライアント・システム」は,“送信側”と見なせるので,“受信側において,シードを用いて,送信側と同じノンスを生成する”ことは,本願の第1国出願前には,当業者に広く知られた技術事項であった。
加えて,上記Fの記載にもあるとおり,受信側で必要なデータを,送信側から送られてきたデータを用いて生成することも,本願の第1国出願前に,当業者には広く知られた技術事項であった。
そして,引用発明においては,「暗号化されて送信されてきた情報」を,「受信側ノード」において復号するためには,「送信側ノード」と同一の「ノンス」が必要であることは,明らかであるから,
上記1.において検討した事項を踏まえると,引用発明において,“送信側ノードにおいて,暗号化に用いたノンスを,管理ノードから受信したデータと,送信側から送られてきたデータに基づいて形成する”よう構成することは,当業者が適宜なし得る事項である。
よって,[相違点6]は,格別のものではない。

5.[相違点7]について
上記Kにおいて引用した,周知技術文献の記載内容にもあるとおり,複数存在する「デコーダ」(本願発明における「受信ネットワークノード」に相当)が有する「シード」(本願発明における「一定値」に相当)を更新するために,定期的に新しい「シード」が,ブロードキャストされ,古い「シード」と置換されるようなことは,本願の第1国出願前に,当業者には周知の技術事項である。
そして,上記1.において検討した事項を踏まえれば,前記「シード」を“管理ノード”から送信するよう構成することも,当業者には周知の技術事項である。
したがって,引用発明において,「受信側ノード」において,「ノンス」を生成するために必要な「データ」を,“管理ノード”から,定期的に送信して,更新するよう構成すことは,当業者が,引用発明と周知技術とに基づいて,適宜なし得る事項である。
よって,[相違点7]は,格別のものではない。

6.以上1.?5.において検討したとおり,[相違点1]?[相違点7]は,格別なものではなく,また,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

なお,審判請求人は,平成27年10月27日付けの意見書において,
「引例1の乱数Rxが,本願発明の一定値(EANCV)に相当すると認定しています。しかしながら,引例1の乱数Rxは,ネットワークの全てのデバイスに対して共通の値になることはありえません。それゆえ,引例1には,本願発明の「前記ネットワーク(1)の前記中央管理ネットワークノード(2-0)以外のネットワークノード(2-i)が使用する共通の一定値(EANCV)」という特徴事項が記載も示唆もされていません。
引例1において,ノンス値の残りの7バイト(最下位7バイト1240)は,永久的に論理0に設定することができます。しかしながら,ノンス値の残りの7バイト(最下位7バイト1240)が,永久的に論理0に設定されるため,新たな値によって置換されることはありません。それゆえ,引例1には,本願発明の「前記共通の一定値(EANCV)を,前記新たな共通の一定値(EANCV)によって置換するステップを実施する」という特徴事項が記載も示唆もされていません。それゆえ,仮に引例1に他の引例を組み合わせたとしても,本願発明の構成を達成することはできません。」
と主張しているが,上記の「第6.相違点についての当審の判断」の「2.[相違点2],及び,[相違点4]について」において検討したとおり,「引用発明」における「パディングデータ」に換えて,他のデータを採用することは,当業者が適宜なし得る事項であるから,上記請求人の主張は,採用できない。

第7.むすび
したがって,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2015-12-22 
結審通知日 2016-01-05 
審決日 2016-01-25 
出願番号 特願2011-526450(P2011-526450)
審決分類 P 1 8・ 121- WZ (H04L)
最終処分 不成立  
前審関与審査官 青木 重徳  
特許庁審判長 辻本 泰隆
特許庁審判官 戸島 弘詩
石井 茂和
発明の名称 ネットワークノード間のデータ伝送方法  
代理人 久野 琢也  
代理人 星 公弘  
代理人 アインゼル・フェリックス=ラインハルト  

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