【事件の表示】
　特願２０１２−５０３６５２「既存の無線接続鍵を使用する仮想ペアリングのための装置および方法」拒絶査定不服審判事件〔平成２２年１０月１４日国際公開，ＷＯ２０１０／１１７８５４，平成２４年　９月２７日国内公表，特表２０１２−５２３１６７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２０１０年３月３１日（パリ条約による優先権主張外国庁受理２００９年３月３１日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２３年１１月３０日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に同日付けで審査請求がなされ，平成２４年１月３１日付けで手続補正がなされ，平成２５年３月７日付けで審査官により拒絶理由が通知され（発送；平成２５年３月１２日），これに対して平成２５年６月１２日付けで意見書が提出されると共に手続補正がなされたが，平成２５年６月２８日付けで審査官により拒絶査定がなされ（発送；平成２５年７月２日），これに対して平成２５年１１月５日付けで審判請求がなされると共に手続補正がなされ，平成２５年１１月２８日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２５年１１月５日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。
　
「第１のピア・デバイスと第２のピア・デバイスとの仮想ペアリングのための方法であって，
　第１タイプの無線接続を確立するために，前記第１および第２のピア・デバイスを仮想的にペアリングする際に使用するためのナンスを，前記第１のピア・デバイスにおいて生成することと，
　前記第１および第２のピア・デバイス間のすでに確立されている第２タイプの無線接続によって，前記第１のピア・デバイスから前記第２のピア・デバイスに前記ナンスを送ることと，
　前記ナンスと，前記すでに確立されている第２タイプの無線接続のための共有鍵とから，少なくとも１つの新たな鍵を生成することと，
　前記第１および第２のピア・デバイス間の前記第１タイプの無線接続を確立するために，前記少なくとも１つの新たな鍵を使用して，前記第１のピア・デバイスを前記第２のピア・デバイスと仮想的にペアリングすることと
　
　
第３．引用刊行物に記載の発明
　原審における平成２５年３月７日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用された，本願の第１国出願前に既に公知である，特開２００７−５３６１２号公報（２００７年３月１日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【００１２】
　図１は，
本発明の通信機器の実施例に係る携帯電話及びＨＤＤレコーダが使用されるシステム
本システムは，携帯電話１１からリモコン信号を送信することによりＨＤＤレコーダ１０を操作し，また，ＨＤＤレコーダ１０から携帯電話１１に対して動画配信を行う
【００１３】
　図１（ａ）は，Ｂｌｕｅｔｏｏｔｈ（登録商標）通信による近距離通信を行う際のシステムの構成を示す図である。
本システムでは，ＨＤＤレコーダ１０と携帯電話１１とは，Ｂｌｕｅｔｏｏｔｈ通信により認証を行い，共通鍵（後述するリンクキー）の作成を行う
Ｂｌｕｅｔｏｏｔｈ通信のデータ転送レートは比較的小さいため，本実施例ではＨＤＤレコーダ１０と携帯電話１１とがＢｌｕｅｔｏｏｔｈ通信可能な距離にある場合であっても，後述する図１（ｂ）のように，Ｂｌｕｅｔｏｏｔｈ通信よりもデータ転送レートの大きいインターネット１２及び携帯電話網を介して動画配信を行うものとする
【００１４】
　尚，Ｂｌｕｅｔｏｏｔｈ通信は比較的強固な暗号化アルゴリズムが採用されている。また通信範囲も通常１０ｍ程度と限られており，第三者に覗き見られる可能性が低い。よって，Ｂｌｕｅｔｏｏｔｈ通信は，インターネット等の公衆通信網を利用する場合と比して安全性が高い。よって，
ＨＤＤレコーダ１０及び携帯電話１１は，Ｂｌｕｅｔｏｏｔｈ通信により認証及び共通鍵生成を行う
・・・・・（中略）・・・・・
【００１６】
　図１（ｂ）は，
ＨＤＤレコーダ１０及び携帯電話１１が，インターネット１２を介して通信を行う際のシステムの構成を示す図である
一方，携帯電話１１は基地局１３との間で携帯電話通信を行い，当該基地局１３を介してインターネット１２に接続されている
ＨＤＤレコーダ１０及び携帯電話１１は，インターネット１２を介して通信することができる
　
Ｂ．「【００４８】
　次に，携帯電話１１とＨＤＤレコーダ１０とがデータ通信を行う際の処理の流れについて図５を参照しながら説明する。図５は，携帯電話１１とＨＤＤレコーダ１０とが通信する際の処理の流れを示すフローチャートである。
図５の処理は，通常のＢｌｕｅｔｏｏｔｈ通信を行う機器の通信処理の流れと同様であるが，本実施例では，携帯電話１１及びＨＤＤレコーダ１０は，Ｂｌｕｅｔｏｏｔｈ通信のみならず，インターネット１２を介した通信でも同様の通信処理が行われる
図５の例では携帯電話１１からＨＤＤレコーダ１０に向けて接続要求を行っているがこれに限られるものではなく，ＨＤＤレコーダ１０から携帯電話１１に向けて接続要求を行っても良い
【００４９】
　
携帯電話１１は，まず乱数を生成する（Ｓ５０１）。以下，Ｓ５０１で携帯電話１１が生成した乱数を乱数Ｆとする。乱数Ｆを生成した後，携帯電話１１はＨＤＤレコーダ１０に対して接続要求を行い，乱数Ｆを送信する
【００５０】
　ＨＤＤレコーダ１０は，乱数Ｆを受信すれば（Ｓ５０３），確認応答を携帯電話１１に対して送信する（Ｓ５０４）。
　
携帯電話１１は
暗号鍵の生成処理に入る。まず，Ｓ５０１で生成した乱数Ｆと，図３の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する
Ｓ５０６の演算結果と，携帯電話１１のＢｌｕｅｔｏｏｔｈアドレスであるａｄｄＸとの排他的論理和を取り（Ｓ５０７），この演算結果と携帯電話１０のクロック値との排他的論理和を演算する（Ｓ５０８）。この演算結果を暗号鍵とする
【００５１】
　
他方ＨＤＤレコーダ１０も同様に暗号鍵の生成処理を行う
Ｓ５０３で携帯電話１１から受信した乱数Ｆと，図３の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する
Ｓ５０９の演算結果と，携帯電話１１のＢｌｕｅｔｏｏｔｈアドレスであるａｄｄＸとの排他的論理和を取り（Ｓ５１０），この演算結果と携帯電話１０のクロック値との排他的論理和を演算し（Ｓ５１１），これを暗号鍵とする
Ｓ５１１で得られる暗号鍵は，Ｓ５０８で携帯電話１１に作成される暗号鍵と一致する
ここで使用する携帯電話１１のＢｌｕｅｔｏｏｔｈアドレス
は，図３及び図４で示した認証処理の際に携帯電話１０から予め取得
　
Ｃ．「【００５８】
　
ＨＤＤレコーダ１０は，再生指示をＢｌｕｅｔｏｏｔｈ通信部１１３で受信すると
Ｂｌｕｅｔｏｏｔｈ通信よりもデータ転送レートの大きなインターネット１２を介した通信の接続要求をインターネット通信部１０４から携帯電話１１に向けて送信する
図５の処理では携帯電話１１から要求を行っているが，Ｓ６０４ではＨＤＤレコーダ１０から携帯電話１１に向けて接続要求を送信している
携帯電話１１及びＨＤＤレコーダ１０は其々暗号鍵を作成する
【００５９】
　
インターネット１１２を介した接続が確立した後
　
Ｄ．「【００７２】
　
本実施例では，Ｂｌｕｅｔｏｏｔｈ通信とインターネット１２による通信とを例にとって説明を行ったが，これに限られるものではなく，例えば無線ＬＡＮによる通信等であっても良い
　
１．上記Ａの「
本発明の通信機器の実施例に係る携帯電話及びＨＤＤレコーダが使用されるシステム
本システムは，携帯電話１１からリモコン信号を送信することによりＨＤＤレコーダ１０を操作し，また，ＨＤＤレコーダ１０から携帯電話１１に対して動画配信を行う
インターネット１１２を介した接続が確立した後
　
２．上記Ｂの「
携帯電話１１は，まず乱数を生成する（Ｓ５０１）。以下，Ｓ５０１で携帯電話１１が生成した乱数を乱数Ｆとする。乱数Ｆを生成した後，携帯電話１１はＨＤＤレコーダ１０に対して接続要求を行い，乱数Ｆを送信する
図５の処理は，通常のＢｌｕｅｔｏｏｔｈ通信を行う機器の通信処理の流れと同様であるが，本実施例では，携帯電話１１及びＨＤＤレコーダ１０は，Ｂｌｕｅｔｏｏｔｈ通信のみならず，インターネット１２を介した通信でも同様の通信処理が行われる
図５の処理では携帯電話１１から要求を行っているが，Ｓ６０４ではＨＤＤレコーダ１０から携帯電話１１に向けて接続要求を送信している
図５の処理では携帯電話１１から要求を行っているが，Ｓ６０４ではＨＤＤレコーダ１０から携帯電話１１に向けて接続要求を送信している
　
３．上記Ａの「
本システムでは，ＨＤＤレコーダ１０と携帯電話１１とは，Ｂｌｕｅｔｏｏｔｈ通信により認証を行い，共通鍵（後述するリンクキー）の作成を行う
本システムでは，ＨＤＤレコーダ１０と携帯電話１１とは，Ｂｌｕｅｔｏｏｔｈ通信により認証を行い，共通鍵（後述するリンクキー）の作成を行う
ＨＤＤレコーダ１０及び携帯電話１１は，Ｂｌｕｅｔｏｏｔｈ通信により認証及び共通鍵生成を行う
　
４．上記Ｂの「
携帯電話１１は
暗号鍵の生成処理に入る。まず，Ｓ５０１で生成した乱数Ｆと，図３の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する
Ｓ５０６の演算結果と，携帯電話１１のＢｌｕｅｔｏｏｔｈアドレスであるａｄｄＸとの排他的論理和を取り（Ｓ５０７），この演算結果と携帯電話１０のクロック値との排他的論理和を演算する（Ｓ５０８）。この演算結果を暗号鍵とする
他方ＨＤＤレコーダ１０も同様に暗号鍵の生成処理を行う
Ｓ５０３で携帯電話１１から受信した乱数Ｆと，図３の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する
Ｓ５０９の演算結果と，携帯電話１１のＢｌｕｅｔｏｏｔｈアドレスであるａｄｄＸとの排他的論理和を取り（Ｓ５１０），この演算結果と携帯電話１０のクロック値との排他的論理和を演算し（Ｓ５１１），これを暗号鍵とする
ここで使用する携帯電話１１のＢｌｕｅｔｏｏｔｈアドレス
は，図３及び図４で示した認証処理の際に携帯電話１０から予め取得
Ｓ５１１で得られる暗号鍵は，Ｓ５０８で携帯電話１１に作成される暗号鍵と一致する
　
５．引用刊行物１においては，上記４．において，検討した，「携帯電話」と，「ＨＤＤレコーダ」において同一の「暗号鍵」を用いて，上記１．において言及した「インターネットによる通信」が確立されるものであることは明らかであって，上記Ｄの「
本実施例では，Ｂｌｕｅｔｏｏｔｈ通信とインターネット１２による通信とを例にとって説明を行ったが，これに限られるものではなく，例えば無線ＬＡＮによる通信等であっても良い
　上記１．〜５．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　通信機器である携帯電話と，同じく通信機器であるＨＤＤレコーダとの接続を確立するための方法であって，
　無線ＬＡＮによる通信を確立するために，乱数Ｆを前記携帯電話において生成し，
　前記携帯電話から，前記ＨＤＤレコーダに送信し，
　前記携帯電話において生成した前記乱数Ｆと，Ｂｌｕｅｔｏｏｔｈの認証の際に計算した共通鍵とから，前記携帯電話と，前記ＨＤＤレコーダの双方において，暗号鍵を生成し，
　前記暗号鍵を用いて，前記携帯電話と，前記ＨＤＤレコーダとの間の無線ＬＡＮによる通信を確立する，方法。
　
第４．本願発明と引用発明との対比
１．引用発明における「通信機器である携帯電話」と，「通信機器であるＨＤＤレコーダ」とが，本願発明における「第１のピア・デバイス」と，「第２のピア・デバイス」に相当し，引用発明において，「携帯電話」と，「ＨＤＤレコーダ」との間で「接続を確立する」ということは，「携帯電話」と，「ＨＤＤレコーダ」との間に，“通信のための関係を構築する”ことに他ならない。そして，本願発明における「仮想ペアリング」も，一種の“通信のための関係”と言い得るものであるから，
　引用発明における「通信機器である携帯電話と，同じく通信機器であるＨＤＤレコーダとの接続を確立するための方法」と，
　本願発明における「第１のピア・デバイスと第２のピア・デバイスとの仮想ペアリングのための方法」とは，
“第１のピア・デバイスと第２のピア・デバイスとの通信のための関係を構築するための方法”である点で共通する。
　
２．引用発明における「無線ＬＡＮによる通信」が，本願発明における「第１タイプの無線接続」に相当し，引用発明における「乱数Ｆ」は，前記「無線ＬＡＮによる通信」を確立するために用いられるものであって，「携帯電話」と，「ＨＤＤレコーダ」との間に，“通信のための関係を構築するため”に用いられるものとも言い得るものであるから，本願発明における「ナンス」と，“通信のための関係を構築するために用いられる値”である点で共通するので，
　引用発明における「無線ＬＡＮによる通信を確立するために，乱数Ｆを前記携帯電話において生成」することと，
　本願発明における「第１タイプの無線接続を確立するために，前記第１および第２のピア・デバイスを仮想的にペアリングする際に使用するためのナンスを，前記第１のピア・デバイスにおいて生成すること」とは，
“第１タイプの無線接続を確立するために，第１および第２のピア・デバイスに通信のための関係を構築するために用いられる値を，第１のピア・デバイスにおいて生成すること”である点で共通する。
　
３．引用発明における「前記携帯電話から，前記ＨＤＤレコーダに送信」することと，
　本願発明における「前記第１および第２のピア・デバイス間のすでに確立されている第２タイプの無線接続によって，前記第１のピア・デバイスから前記第２のピア・デバイスに前記ナンスを送ること」とは，
“第１のピア・デバイスから第２のピア・デバイスに通信のための関係を構築するために用いられる値を送ること”である点で共通する。
　
４．引用発明における「Ｂｌｕｅｔｏｏｔｈ」が，本願発明における「第２タイプの無線通信」に相当し，引用発明における「Ｂｌｕｅｔｏｏｔｈの認証の際に計算した共通鍵」が，本願発明における「第２タイプの無線接続のための共有鍵」に相当するので，
　引用発明における「前記携帯電話において生成した前記乱数Ｆと，Ｂｌｕｅｔｏｏｔｈの認証の際に計算した共通鍵とから，前記携帯電話と，前記ＨＤＤレコーダの双方において，暗号鍵を生成」することと，
　本願発明における「前記ナンスと，前記すでに確立されている第２タイプの無線接続のための共有鍵とから，少なくとも１つの新たな鍵を生成すること」とは，
“通信のための関係を構築するために用いられる値と，第２タイプの無線接続のための共有鍵とから，少なくとも１つの新たな鍵を生成すること”である点で共通する。
　
５．そして，引用発明における「暗号鍵を用いて，前記携帯電話と，前記ＨＤＤレコーダとの間の無線ＬＡＮによる通信を確立する」ことと，
　本願発明における「前記第１および第２のピア・デバイス間の前記第１タイプの無線接続を確立するために，前記少なくとも１つの新たな鍵を使用して，前記第１のピア・デバイスを前記第２のピア・デバイスと仮想的にペアリングすること」とは，
“前記第１および第２のピア・デバイス間の前記第１タイプの無線接続を確立するために，前記少なくとも１つの新たな鍵を使用する”点で共通する。
　
　以上，１．〜５．において検討した事項から，本願発明と，引用発明との一致点，及び，相違点は，次のとおりである。
　
［一致点］
　第１のピア・デバイスと第２のピア・デバイスとの通信のための関係を構築するための方法であって，
　第１タイプの無線接続を確立するために，前記第１および前記第２のピア・デバイスに通信のための関係を構築するために用いられる値を，前記第１のピア・デバイスにおいて生成することと，
　前記第１のピア・デバイスから前記第２のピア・デバイスに，前記通信のための関係を構築するために用いられる値を送ることと，
　前記通信のための関係を構築するために用いられる値と，第２タイプの無線接続のための共有鍵とから，少なくとも１つの新たな鍵を生成すること，
　前記第１および前記第２のピア・デバイス間の前記第１タイプの無線接続を確立するために，前記少なくとも１つの新たな鍵を使用することと，から成る方法。
　
［相違点１］
“通信のための関係を構築するため”に関して，
　本願発明においては，「仮想ペアリング」であるのに対して，
　引用発明においては，「仮想ペアリング」についての明確な言及がない点。
　
［相違点２］
“通信のための関係を構築するために用いられる値”に関して，
　本願発明においては，「ナンス」であるのに対して，
　引用発明においては，「乱数Ｆ」である点。
　
［相違点３］
“通信のための関係を構築するために用いられる値を送ること”に関して，
　本願発明においては，「第１および第２のピア・デバイス間にすでに確立されている第２タイプの無線接続によって，前記第１のデバイスから前記第２のデバイスにナンスを送る」ものであるのに対して，
　引用発明においては「すでに確立されている第２タイプの無線接続」を介する点についての明確な言及がない点。
　
［相違点４］
“第２タイプの無線接続のための共有鍵”に関して，
　本願発明においては，「すでに確立されている第２タイプの無線接続のための共有鍵」であるのに対して，
　引用発明においては，「Ｂｌｕｅｔｏｏｔｈ」による「接続」が，「暗号鍵」生成時点で，「確立」されていることが，明言されていない点。
　
［相違点５］
　本願発明においては，「少なくとも１つの鍵を使用して，前記第１のピア・デバイスを前記第２のピア・デバイスと仮想的にペアリングすること」であるのに対して，
　引用発明においては，「仮想的にペアリングすること」に対する，明確な言及がない点。
　
第５．相違点についての当審の判断
１．［相違点１］，及び，［相違点５］について
　本願発明における「仮想ペアリング」，及び，「仮想的にペアリングする」とは，原審の平成２５年６月２８日付けの拒絶査定（以下，これを「原審拒絶査定」という」）の備考において指摘されてもいるように，本願明細書には，
　
「【００１５】
　
本発明の新たな鍵の確立は，既存のデバイス認証に依存する
デバイス認証のためのセキュリティ委託は，１つの接続技術で認証された時点で，デバイスが信頼可能と見なされるということを意味する。結果として，別の接続技術によって指定された認証を実行する必要はない
【００１６】
　
例えばBluetooth接続のような，新たな無線接続１１８’と，例えばWi-Fi接続のような，既存の無線接続１１６’との簡略化デバイス認証の実例が図３を参照して図示される。例えばラップトップ・コンピュータのような，第１のピア・デバイス１０２’と，例えばスマート・フォンのような，第２のピア・デバイス１１４’とが，ＷＥＰあるいはＷＰＡが使用可能なWi-Fiアドホック・モードで相互接続されうる。これら２つのピア・デバイスは，例えば，既存の無線接続１１６’のための共有鍵ＫＳ認証によって認証されている
それらのデバイスがBluetoothによってペアリングされていることを望みうる。この場合，Bluetoothペアリング処理全体が取り除かれうる。代わりに，仮想Bluetoothペアリング処理が，ユーザの関与なしに，自動的に開始されうる。例えば，ナンスＮのようなBluetooth鍵マテリアルがランダムに生成され，その後，安全なWi-Fiリンクでトランスポートされうる
【００１７】
　・・・・・（中略）・・・・・
【００１８】
　
別の接続技術によって確立された共有鍵ＫＳから，新たな共有秘密鍵ＫＮを導出するために，セキュリティ委託が使用されうる。結果として，更なるユーザの関与も，時間のかかる動作も必要なくなる。Wi-FiおよびBluetoothを使用する別の実例として，２つのピア・デバイスがBluetoothによってペアリングされうる。これら２つのデバイスが，高速ファイル転送のためにピア・ツー・ピアWi-Fiリンクをセット・アップすることを望む場合，ＷＥＰあるいはＷＰＡのために使用される鍵を導出するために，Bluetoothリンク鍵が使用されうる
　
　という記載が存在し，上記引用の，特に段落【００１６】の「既存の無線接続１１６’のための共有鍵ＫＳ認証によって認証されている・・・Bluetoothペアリング処理全体が取り除かれうる。代わりに，仮想Bluetoothペアリング処理が，ユーザの関与なしに，自動的に開始されうる。例えば，ナンスＮのようなBluetooth鍵マテリアルがランダムに生成され」という記載から，本願発明における「仮想ペアリング」とは，“第１のピア・デバイスと，第２のピア・デバイスとの間が，複数の異なる無線接続を用いて接続可能である時，１つの無線接続において認証がなされている場合は，他の無線接続における認証処理が省略される”というものである。
　一方，引用発明においても，引用刊行物１に，
　
Ｅ．「【００７０】
　またユーザは，
インターネット通信に対する認証を行わないので，通信環境による通信経路の選択をユーザに意識させずに処理することができる
　また，
安全性の高い通信経路であるＢｌｕｅｔｏｏｔｈ通信で作成したリンクキーに基づいて，安全性の低いインターネット１２を介した通信でも暗号化を行う
　
　と記載されているように，引用発明においても，「Ｂｌｕｅｔｏｏｔｈ通信」における認証が成立している場合に，「インターネット通信に対する認証を行わ」ずに，「Ｂｌｕｅｔｏｏｔｈ通信で作成したリンクキーに基づいて」処理を行っており，上記Ｂにおいて引用した記載内容から，「リンクキーに基づ」く処理とは，「乱数Ｆ」と，「リンクキー」から，「暗号鍵」を生成することに他ならないから，結果として，引用発明においても，本願発明における「仮想ペアリング」に相当する処理が行われていることは明らかである。
　よって，相違点１，及び，相違点５は，格別のものではない。
　
２．［相違点２］について
　「ナンス」とは，例えば，本願の第１国出願前に既に公知である，特表２００９-５０６４３８号公報（２００９年２月１２日公表，以下，これを「周知技術文献１」という）に，
　
Ｆ．「【０００６】
　
暗号の応用では，通常，初期化ベクトル，鍵，ナンス（nonce），ソルト（salt），等に“ランダムな（random）”数を使用する
　
　と，また，同じく，本願の第１国出願前に既に公知である，特開２００６−１２７１３３号公報（２００６年５月１８日公開，以下，これを「周知技術文献２」という）に，
　
Ｇ．「【００４３】
　その後，コンテンツ譲渡受付処理機能において，
乱数値（ナンス）を生成
　
　と記載されているように，暗号の応用分野においては，“ナンス＝乱数”であることは周知の技術事項である。
　そして，本願明細書に，
　
「【００１３】
　第１タイプの無線接続１１６は高速接続でありうる，また，第２タイプの無線接続１１８は低電力接続でありうる。
第１タイプの無線接続はWi-Fi接続でありうる，また，第２タイプの無線接続はBluetooth接続でありうる
　
Wi-Fi鍵＝kdf（BTリンク鍵 || ナンス）
　ここで，BTリンク鍵はすでに確立されているBluetooth接続のための共有鍵であり，kdf（  ）は鍵導出関数である。典型的なkdf（  ）は，ＡＮＳＩ−Ｘ９．６３，“Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography”に示されている。付加的なナンスが，新たな鍵の形成に含まれうる。例えば，第２のピア・デバイスは，第１のピア・デバイスによって生成された第１のナンスに加えて，第２のナンスを生成しうる。このように，新たな鍵は，以下の式に従って形成されることができる。  
　Wi-Fi鍵＝kdf（BTリンク鍵 || ナンス１ || ナンス２）    （式２）  
　更に，状況を逆転させると，第１タイプの接続はBluetooth接続でありうる，また，第２タイプの無線接続はWi-Fi接続でありうる。」
　
　と記載されていて，段落【００１３】に記載された内容から，本願発明においては，“第２タイプの無線接続における，リンク鍵である，ＢＴリンク鍵（共有鍵）と，ナンスから，Wi-Fi鍵，即ち，本願発明における，少なくとも１つの新たな鍵を生成するするもの”であり，引用発明も，同様に，“乱数Ｆと，Ｂｌｕｅｔｏｏｔｈの認証の際に計算した共通鍵とから，暗号鍵を生成している”ことから，上記において指摘したとおり，“ナンス＝乱数”と言い得る以上，「少なくとも１つの新たな鍵」を生成する処理に関して，表現の差こそあれ，本願発明と，引用発明との処理内容自体に格別の相違は存在しない。
　よって，相違点２は，格別のものではない。
　
３．［相違点３］，及び，［相違点４］について
　原審拒絶理由において引用された，本願の第１国出願前に既に公知である，特開２００５−２４４９８８号公報（２００５年９月８日公開，以下，これを「引用刊行物２」という）に，
　
Ｈ．「【請求項２９】
　前記
帯域外機構は
Ｂｌｕｅｔｏｏｔｈ互換装置
を含む
　
Ｉ．「【０００６】
　図１に示すネットワーク環境の一例で，
クライアント装置とも呼ばれる複数のクライアントコンピューティング装置１０５，１１０，１１５，および１２０は，ネットワーク１００を介して互いに結合されており，並びに少なくとも１つのサーバ装置１２５に結合されている
ネットワーク１００は，有線および／または無線のネットワークを含め
。ネットワーク１００は，例えばインターネット，および場合によっては１つまたは複数のローカルエリアネットワーク（ＬＡＮ）の少なくとも一部分を含む
【０００７】
　
クライアント装置１０５は，デスクトップパーソナルコンピュータ（ＰＣ），ワークステーション，メインフレームコンピュータ，インターネット機器，およびゲームコンソールを含む従来の様々なコンピューティング装置のうちの任意のものを含むことができる
ネットワーク１００に関連付けられているクライアント装置は，有線および／または無線リンクによってネットワーク１００と通信することができる携帯情報端末（ＰＤＡ）１１０，ラップトップコンピュータ１１５，並びにセル方式電話１２０などを含むことができる
　
Ｊ．「【００１２】
　図２の実施形態の例によれば，
装置２０５と２３０との間の信頼関係は
装置２０５および２０３が結合して通信を行なうネットワーク１００を介して確立されるのではなく
サードパーティの帯域外すなわち非同期の機構（ｅｎｔｉｔｙ）が使用される。こうした機構は，以下「帯域外機構」（ｏｕｔ−ｏｆ−ｂａｎｄ  ｍｅｃｈａｎｉｓｍ）２４５と呼び
代わりに帯域外機構２４５の・・・・および赤外線互換の例がプログラム主導，またはユーザにより実行されるものでもよい
【００１３】
　
第１の実施形態によれば，Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ暗号プロトコルを使用して少なくとも装置２０５および２３０上で対称鍵が確立される
装置２０５および２３０で生成された公開鍵の値は，帯域外機構２４５を介して交換される
【００１４】
　つまり，
装置２０５上の共有秘密値生成器２２５は，生成器２１５によって生成された秘密鍵の値，および帯域外機構２４５を介して装置２３０からインポートされた公開鍵の値の関数としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ共有の秘密の値を生成する
装置２３０上の共有秘密値生成器２４０は，生成器２３５によって生成された秘密鍵の値，および帯域外機構２４５を介して装置２０５からインポートされた公開鍵の値の関数としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ共有の秘密の値を生成する
【００１５】
　各装置で生成されたＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ秘密の値は，暗号化／解読，または他の既知の認証の目的に使用される。」
　
　と記載されているように，引用刊行物２には，“クライアントと，サーバとの間で，ネットワーク接続における，ＤＨ鍵共有を行う場合の，クライアントの公開鍵の値を，クライアントとサーバが接続されているネットワークではなく，帯域外機構を経由して，サーバに送り，サーバの公開鍵の値を，サーバとクライアントが接続されているネットワークではなく，帯域外機構を経由して，クライアントに送って，双方で共有する秘密の値を計算する”ことが記載されていて，引用刊行物２に係る発明においては，当該「帯域外機構」として，上記Ｈに記載されているように，「Ｂｌｕｅｔｏｏｔｈ互換装置」を含んでおり，当該「Ｂｌｕｅｔｏｏｔｈ互換装置」を経由して，「クライアント」，「サーバ」間で，「公開鍵の値」を送受するためには，「クライアント」と，「Ｂｌｕｅｔｏｏｔｈ互換装置」間，及び，「サーバ」と，「Ｂｌｕｅｔｏｏｔｈ互換装置」間に，それぞれ，Ｂｌｕｅｔｏｏｔｈ接続が確立していることは明らかである。
　そして，引用刊行物２に係る発明においては，「クライアント」と，「サーバ」とは，接続された「ネットワーク」とは異なる「帯域外機構」として，「Ｂｌｕｅｔｏｏｔｈ互換装置」を経由する通信を用いているが，「クライアント」と，「サーバ」とが，接続された「ネットワーク」とは別の“通信路”として，直接「Ｂｌｕｅｔｏｏｔｈ」で接続し得ることは明らかである。
　ここで，ＤＨ鍵共有の際に，交換される「公開鍵の値」とは，原審拒絶理由においても指摘されているとおり，“ランダムな値”であるから，引用刊行物２に係る発明における「クライアント」，「サーバ」，「公開鍵の値」は，それぞれ，引用発明における「携帯電話」，「ＨＤＤレコーダ」，「乱数Ｆ」に相当するので，引用発明においても，“接続が確立しているＢｌｕｅｔｏｏｔｈ接続を介して，他の通信において共有される鍵を計算するための「乱数Ｆ」を，「携帯電話」から，「ＨＤＤレコーダ」へ送る”よう構成することは，当業者が適宜なし得る事項である。
　そして，上記指摘の構成を採用すれば，引用発明における「Ｂｌｕｅｔｏｏｔｈの認証の際に計算した共通鍵」が，「すでに確立されているＢｌｕｅｔｏｏｔｈ接続のための共有鍵」と言い得るものであることは，明らかである。
　よって，相違点３，及び，相違点４は，格別のものではない。
　
　上記で検討したごとく，相違点１〜相違点５はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，引用発明，引用刊行物２に係る発明，及び，周知技術文献に記載された技術からもたらされる効果を参酌すれば，当業者であれば当然に予測可能なものに過ぎず，格別なものとは認められない。
　
第６．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。