• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1306831
審判番号 不服2013-21664  
総通号数 192 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-12-25 
種別 拒絶査定不服の審決 
審判請求日 2013-11-05 
確定日 2015-10-14 
事件の表示 特願2012-503652「既存の無線接続鍵を使用する仮想ペアリングのための装置および方法」拒絶査定不服審判事件〔平成22年10月14日国際公開,WO2010/117854,平成24年 9月27日国内公表,特表2012-523167〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2010年3月31日(パリ条約による優先権主張外国庁受理2009年3月31日 アメリカ合衆国)を国際出願日とする出願であって,
平成23年11月30日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に同日付けで審査請求がなされ,平成24年1月31日付けで手続補正がなされ,平成25年3月7日付けで審査官により拒絶理由が通知され(発送;平成25年3月12日),これに対して平成25年6月12日付けで意見書が提出されると共に手続補正がなされたが,平成25年6月28日付けで審査官により拒絶査定がなされ(発送;平成25年7月2日),これに対して平成25年11月5日付けで審判請求がなされると共に手続補正がなされ,平成25年11月28日付けで審査官により特許法第164条第3項の規定に基づく報告がなされたものである。

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

「第1のピア・デバイスと第2のピア・デバイスとの仮想ペアリングのための方法であって,
第1タイプの無線接続を確立するために,前記第1および第2のピア・デバイスを仮想的にペアリングする際に使用するためのナンスを,前記第1のピア・デバイスにおいて生成することと,
前記第1および第2のピア・デバイス間のすでに確立されている第2タイプの無線接続によって,前記第1のピア・デバイスから前記第2のピア・デバイスに前記ナンスを送ることと,
前記ナンスと,前記すでに確立されている第2タイプの無線接続のための共有鍵とから,少なくとも1つの新たな鍵を生成することと,
前記第1および第2のピア・デバイス間の前記第1タイプの無線接続を確立するために,前記少なくとも1つの新たな鍵を使用して,前記第1のピア・デバイスを前記第2のピア・デバイスと仮想的にペアリングすることと
を備える方法。」(下線は,審判請求人が付加したものである。)

第3.引用刊行物に記載の発明
原審における平成25年3月7日付けの拒絶理由(以下,これを「原審拒絶理由」という)において引用された,本願の第1国出願前に既に公知である,特開2007-53612号公報(2007年3月1日公開,以下,これを「引用刊行物1」という)には,関連する図面と共に,次の事項が記載されている。

A.「【0012】
図1は,本発明の通信機器の実施例に係る携帯電話及びHDDレコーダが使用されるシステムの構成を示す図である。本システムは,携帯電話11からリモコン信号を送信することによりHDDレコーダ10を操作し,また,HDDレコーダ10から携帯電話11に対して動画配信を行う。
【0013】
図1(a)は,Bluetooth(登録商標)通信による近距離通信を行う際のシステムの構成を示す図である。本システムでは,HDDレコーダ10と携帯電話11とは,Bluetooth通信により認証を行い,共通鍵(後述するリンクキー)の作成を行う。また,携帯電話11を使用するユーザがHDDレコーダ10の比較的近くにいる場合には,Bluetooth通信により,リモコン信号のやり取りを行う。尚,Bluetooth通信のデータ転送レートは比較的小さいため,本実施例ではHDDレコーダ10と携帯電話11とがBluetooth通信可能な距離にある場合であっても,後述する図1(b)のように,Bluetooth通信よりもデータ転送レートの大きいインターネット12及び携帯電話網を介して動画配信を行うものとする。
【0014】
尚,Bluetooth通信は比較的強固な暗号化アルゴリズムが採用されている。また通信範囲も通常10m程度と限られており,第三者に覗き見られる可能性が低い。よって,Bluetooth通信は,インターネット等の公衆通信網を利用する場合と比して安全性が高い。よって,HDDレコーダ10及び携帯電話11は,Bluetooth通信により認証及び共通鍵生成を行う。
・・・・・(中略)・・・・・
【0016】
図1(b)は,HDDレコーダ10及び携帯電話11が,インターネット12を介して通信を行う際のシステムの構成を示す図である。HDDレコーダ10は,例えばLAN(Local Area Network)等を経由してインターネット12に接続されている。一方,携帯電話11は基地局13との間で携帯電話通信を行い,当該基地局13を介してインターネット12に接続されている。即ち,HDDレコーダ10及び携帯電話11は,インターネット12を介して通信することができる。図1(b)のシステムを使用する際には,携帯電話11が屋外にあっても通信可能なエリア内にさえあればHDDレコーダ10及び携帯電話11間での通信を行うことができるので,10m程度の通信距離しか持たないBluetooth通信と比して長距離での通信が可能である。即ち,図1(b)に示す通信経路は,通信範囲が広い。尚,インターネット12を介した図1(b)の通信経路は,Bluetooth通信による図1(a)の通信経路よりもデータ伝送レートが高いものとする。」(下線は,説明の都合上,当審にて付加したものである。以下,別途断りが無い限り同じ。)

B.「【0048】
次に,携帯電話11とHDDレコーダ10とがデータ通信を行う際の処理の流れについて図5を参照しながら説明する。図5は,携帯電話11とHDDレコーダ10とが通信する際の処理の流れを示すフローチャートである。図5の処理は,通常のBluetooth通信を行う機器の通信処理の流れと同様であるが,本実施例では,携帯電話11及びHDDレコーダ10は,Bluetooth通信のみならず,インターネット12を介した通信でも同様の通信処理が行われる。尚,図5の例では携帯電話11からHDDレコーダ10に向けて接続要求を行っているがこれに限られるものではなく,HDDレコーダ10から携帯電話11に向けて接続要求を行っても良い。
【0049】
携帯電話11は,まず乱数を生成する(S501)。以下,S501で携帯電話11が生成した乱数を乱数Fとする。乱数Fを生成した後,携帯電話11はHDDレコーダ10に対して接続要求を行い,乱数Fを送信する(S502)。
【0050】
HDDレコーダ10は,乱数Fを受信すれば(S503),確認応答を携帯電話11に対して送信する(S504)。
携帯電話11は,S504でHDDレコーダ10が送信した確認応答を受信すれば(S505),暗号鍵の生成処理に入る。まず,S501で生成した乱数Fと,図3の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する(S506)。さらに,S506の演算結果と,携帯電話11のBluetoothアドレスであるaddXとの排他的論理和を取り(S507),この演算結果と携帯電話10のクロック値との排他的論理和を演算する(S508)。この演算結果を暗号鍵とする。
【0051】
他方HDDレコーダ10も同様に暗号鍵の生成処理を行う。まず,S503で携帯電話11から受信した乱数Fと,図3の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する(S509)。さらに,S509の演算結果と,携帯電話11のBluetoothアドレスであるaddXとの排他的論理和を取り(S510),この演算結果と携帯電話10のクロック値との排他的論理和を演算し(S511),これを暗号鍵とする。即ち,S511で得られる暗号鍵は,S508で携帯電話11に作成される暗号鍵と一致する。尚,ここで使用する携帯電話11のBluetoothアドレス,及び携帯電話10のクロック値は,図3及び図4で示した認証処理の際に携帯電話10から予め取得し,記憶部112に記憶しておくことにより得られる。」

C.「【0058】
HDDレコーダ10は,再生指示をBluetooth通信部113で受信すると,Bluetooth通信よりもデータ転送レートの大きなインターネット12を介した通信の接続要求をインターネット通信部104から携帯電話11に向けて送信する(S604)。S604の接続要求は,図5のS502の処理に対応する(但し,図5の処理では携帯電話11から要求を行っているが,S604ではHDDレコーダ10から携帯電話11に向けて接続要求を送信している。図6のインターネットによる通信に関しては,以下同様)。携帯電話11は,携帯電話通信部114で接続開始要求を受信すると,確認応答を携帯電話通信部114からHDDレコーダ10に向けて送信する(S605)。この処理は,図5のS504に相当する。図6では記載を省略しているが,この後,図5のS506乃至S511で示したように,携帯電話11及びHDDレコーダ10は其々暗号鍵を作成する。以後,HDDレコーダ10のインターネット通信部104から携帯電話11に向けて送信されるデータ,及び携帯電話11の携帯電話通信部114からHDDレコーダ10に向けて送信されるデータは,図5のS512乃至S519に示したように,この暗号鍵で暗号化されて送信され,受信側で復号される。
【0059】
インターネット112を介した接続が確立した後,HDDレコーダ10は,インターネット通信部104から携帯電話11に向けた動画データ102dの送信を開始する。携帯電話11は携帯電話通信部114で受信した動画データ102dを暗号鍵で復号して再生し,表示部115に表示する。」

D.「【0072】
本実施例では,Bluetooth通信とインターネット12による通信とを例にとって説明を行ったが,これに限られるものではなく,例えば無線LANによる通信等であっても良い。この場合でも,安全性の高い通信路で認証を行って鍵を生成し,当該鍵に基づいて通信を暗号化すればよい。」

1.上記Aの「本発明の通信機器の実施例に係る携帯電話及びHDDレコーダが使用されるシステム」という記載,同じく,上記Aの「本システムは,携帯電話11からリモコン信号を送信することによりHDDレコーダ10を操作し,また,HDDレコーダ10から携帯電話11に対して動画配信を行う」という記載,及び,上記Cの「インターネット112を介した接続が確立した後」という記載から,引用刊行物1は,“通信機器である携帯電話と,同じく通信機器であるHDDレコーダとの接続を確立するための方法”であることが読み取れる。

2.上記Bの「携帯電話11は,まず乱数を生成する(S501)。以下,S501で携帯電話11が生成した乱数を乱数Fとする。乱数Fを生成した後,携帯電話11はHDDレコーダ10に対して接続要求を行い,乱数Fを送信する」という記載から,引用刊行物1において,“携帯電話において,乱数Fを生成し,前記乱数Fを,HDDレコーダに送信する”ことが読み取れ,同じく,上記Bの「図5の処理は,通常のBluetooth通信を行う機器の通信処理の流れと同様であるが,本実施例では,携帯電話11及びHDDレコーダ10は,Bluetooth通信のみならず,インターネット12を介した通信でも同様の通信処理が行われる」という記載,及び,上記Cの「図5の処理では携帯電話11から要求を行っているが,S604ではHDDレコーダ10から携帯電話11に向けて接続要求を送信している」,同じく,上記Cの「図5の処理では携帯電話11から要求を行っているが,S604ではHDDレコーダ10から携帯電話11に向けて接続要求を送信している」という記載から,引用刊行物1において,「携帯電話」と,「HDDレコーダ」との「通信」には,「Bluetooth通信」と,「インターネットによる通信」とが存在すること,及び,「接続」の「要求」は,「Bluetooth通信」と,「インターネットによる通信」の双方において,「携帯電話」側から,及び,「HDDレコーダ」側から,当該「要求」を出す態様が含まれることが読み取れ,更に,上記「乱数F」の生成は,「インターネットによる通信」の「確立」の際にも行われることが読み取れるので,引用刊行物1においては,“インターネットによる通信を確立するために,乱数Fを携帯電話において生成し,前記携帯電話から,HDDレコーダに送信する”ことが読み取れる。

3.上記Aの「本システムでは,HDDレコーダ10と携帯電話11とは,Bluetooth通信により認証を行い,共通鍵(後述するリンクキー)の作成を行う」という記載,及び,上記Aの「本システムでは,HDDレコーダ10と携帯電話11とは,Bluetooth通信により認証を行い,共通鍵(後述するリンクキー)の作成を行う」という記載,同じく,上記Aの「HDDレコーダ10及び携帯電話11は,Bluetooth通信により認証及び共通鍵生成を行う」という記載から,引用刊行物1においては,“すでに生成されているBluetooth通信のための共有鍵”が存在していることが読み取れる。

4.上記Bの「携帯電話11は・・・暗号鍵の生成処理に入る。まず,S501で生成した乱数Fと,図3の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する」という記載,及び,同じく,上記Bの「S506の演算結果と,携帯電話11のBluetoothアドレスであるaddXとの排他的論理和を取り(S507),この演算結果と携帯電話10のクロック値との排他的論理和を演算する(S508)。この演算結果を暗号鍵とする」という記載,並びに,同じく,上記Bの「他方HDDレコーダ10も同様に暗号鍵の生成処理を行う・・・S503で携帯電話11から受信した乱数Fと,図3の認証処理により予め作成しておいたリンクキーとの排他的論理和を演算する」という記載,及び,同じく,上記Bの「S509の演算結果と,携帯電話11のBluetoothアドレスであるaddXとの排他的論理和を取り(S510),この演算結果と携帯電話10のクロック値との排他的論理和を演算し(S511),これを暗号鍵とする」という記載,同じく,上記Bの「ここで使用する携帯電話11のBluetoothアドレス・・・は,図3及び図4で示した認証処理の際に携帯電話10から予め取得」という記載と,同じく,上記Bの「S511で得られる暗号鍵は,S508で携帯電話11に作成される暗号鍵と一致する」という記載から,引用刊行物1においては,“通信の確立を行うために,携帯電話と,HDDレコーダの双方において,乱数Fと共通鍵との排他的論理和を計算し,前記計算結果と,携帯電話のBluetoothアドレスとの排他的論理和を計算し,前記第2の計算結果と,携帯電話のクロック値との排他的論理和を計算して,前記第3の計算結果を暗号鍵とする”ものであることが読み取れるので,結局のところ,引用刊行物1においては,“携帯電話において生成した乱数Fと,Bluetoothの認証の際に計算した共通鍵とから,携帯電話と,HDDレコーダの双方において,暗号鍵を生成する”ことが読み取れる。

5.引用刊行物1においては,上記4.において,検討した,「携帯電話」と,「HDDレコーダ」において同一の「暗号鍵」を用いて,上記1.において言及した「インターネットによる通信」が確立されるものであることは明らかであって,上記Dの「本実施例では,Bluetooth通信とインターネット12による通信とを例にとって説明を行ったが,これに限られるものではなく,例えば無線LANによる通信等であっても良い」という記載から,引用刊行物1においては,「インターネットによる通信」を,「無線LAN」に置き換えた態様を含むことが読み取れることから,
上記1.?5.において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

通信機器である携帯電話と,同じく通信機器であるHDDレコーダとの接続を確立するための方法であって,
無線LANによる通信を確立するために,乱数Fを前記携帯電話において生成し,
前記携帯電話から,前記HDDレコーダに送信し,
前記携帯電話において生成した前記乱数Fと,Bluetoothの認証の際に計算した共通鍵とから,前記携帯電話と,前記HDDレコーダの双方において,暗号鍵を生成し,
前記暗号鍵を用いて,前記携帯電話と,前記HDDレコーダとの間の無線LANによる通信を確立する,方法。

第4.本願発明と引用発明との対比
1.引用発明における「通信機器である携帯電話」と,「通信機器であるHDDレコーダ」とが,本願発明における「第1のピア・デバイス」と,「第2のピア・デバイス」に相当し,引用発明において,「携帯電話」と,「HDDレコーダ」との間で「接続を確立する」ということは,「携帯電話」と,「HDDレコーダ」との間に,“通信のための関係を構築する”ことに他ならない。そして,本願発明における「仮想ペアリング」も,一種の“通信のための関係”と言い得るものであるから,
引用発明における「通信機器である携帯電話と,同じく通信機器であるHDDレコーダとの接続を確立するための方法」と,
本願発明における「第1のピア・デバイスと第2のピア・デバイスとの仮想ペアリングのための方法」とは,
“第1のピア・デバイスと第2のピア・デバイスとの通信のための関係を構築するための方法”である点で共通する。

2.引用発明における「無線LANによる通信」が,本願発明における「第1タイプの無線接続」に相当し,引用発明における「乱数F」は,前記「無線LANによる通信」を確立するために用いられるものであって,「携帯電話」と,「HDDレコーダ」との間に,“通信のための関係を構築するため”に用いられるものとも言い得るものであるから,本願発明における「ナンス」と,“通信のための関係を構築するために用いられる値”である点で共通するので,
引用発明における「無線LANによる通信を確立するために,乱数Fを前記携帯電話において生成」することと,
本願発明における「第1タイプの無線接続を確立するために,前記第1および第2のピア・デバイスを仮想的にペアリングする際に使用するためのナンスを,前記第1のピア・デバイスにおいて生成すること」とは,
“第1タイプの無線接続を確立するために,第1および第2のピア・デバイスに通信のための関係を構築するために用いられる値を,第1のピア・デバイスにおいて生成すること”である点で共通する。

3.引用発明における「前記携帯電話から,前記HDDレコーダに送信」することと,
本願発明における「前記第1および第2のピア・デバイス間のすでに確立されている第2タイプの無線接続によって,前記第1のピア・デバイスから前記第2のピア・デバイスに前記ナンスを送ること」とは,
“第1のピア・デバイスから第2のピア・デバイスに通信のための関係を構築するために用いられる値を送ること”である点で共通する。

4.引用発明における「Bluetooth」が,本願発明における「第2タイプの無線通信」に相当し,引用発明における「Bluetoothの認証の際に計算した共通鍵」が,本願発明における「第2タイプの無線接続のための共有鍵」に相当するので,
引用発明における「前記携帯電話において生成した前記乱数Fと,Bluetoothの認証の際に計算した共通鍵とから,前記携帯電話と,前記HDDレコーダの双方において,暗号鍵を生成」することと,
本願発明における「前記ナンスと,前記すでに確立されている第2タイプの無線接続のための共有鍵とから,少なくとも1つの新たな鍵を生成すること」とは,
“通信のための関係を構築するために用いられる値と,第2タイプの無線接続のための共有鍵とから,少なくとも1つの新たな鍵を生成すること”である点で共通する。

5.そして,引用発明における「暗号鍵を用いて,前記携帯電話と,前記HDDレコーダとの間の無線LANによる通信を確立する」ことと,
本願発明における「前記第1および第2のピア・デバイス間の前記第1タイプの無線接続を確立するために,前記少なくとも1つの新たな鍵を使用して,前記第1のピア・デバイスを前記第2のピア・デバイスと仮想的にペアリングすること」とは,
“前記第1および第2のピア・デバイス間の前記第1タイプの無線接続を確立するために,前記少なくとも1つの新たな鍵を使用する”点で共通する。

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

[一致点]
第1のピア・デバイスと第2のピア・デバイスとの通信のための関係を構築するための方法であって,
第1タイプの無線接続を確立するために,前記第1および前記第2のピア・デバイスに通信のための関係を構築するために用いられる値を,前記第1のピア・デバイスにおいて生成することと,
前記第1のピア・デバイスから前記第2のピア・デバイスに,前記通信のための関係を構築するために用いられる値を送ることと,
前記通信のための関係を構築するために用いられる値と,第2タイプの無線接続のための共有鍵とから,少なくとも1つの新たな鍵を生成すること,
前記第1および前記第2のピア・デバイス間の前記第1タイプの無線接続を確立するために,前記少なくとも1つの新たな鍵を使用することと,から成る方法。

[相違点1]
“通信のための関係を構築するため”に関して,
本願発明においては,「仮想ペアリング」であるのに対して,
引用発明においては,「仮想ペアリング」についての明確な言及がない点。

[相違点2]
“通信のための関係を構築するために用いられる値”に関して,
本願発明においては,「ナンス」であるのに対して,
引用発明においては,「乱数F」である点。

[相違点3]
“通信のための関係を構築するために用いられる値を送ること”に関して,
本願発明においては,「第1および第2のピア・デバイス間にすでに確立されている第2タイプの無線接続によって,前記第1のデバイスから前記第2のデバイスにナンスを送る」ものであるのに対して,
引用発明においては「すでに確立されている第2タイプの無線接続」を介する点についての明確な言及がない点。

[相違点4]
“第2タイプの無線接続のための共有鍵”に関して,
本願発明においては,「すでに確立されている第2タイプの無線接続のための共有鍵」であるのに対して,
引用発明においては,「Bluetooth」による「接続」が,「暗号鍵」生成時点で,「確立」されていることが,明言されていない点。

[相違点5]
本願発明においては,「少なくとも1つの鍵を使用して,前記第1のピア・デバイスを前記第2のピア・デバイスと仮想的にペアリングすること」であるのに対して,
引用発明においては,「仮想的にペアリングすること」に対する,明確な言及がない点。

第5.相違点についての当審の判断
1.[相違点1],及び,[相違点5]について
本願発明における「仮想ペアリング」,及び,「仮想的にペアリングする」とは,原審の平成25年6月28日付けの拒絶査定(以下,これを「原審拒絶査定」という」)の備考において指摘されてもいるように,本願明細書には,

「【0015】
本発明の新たな鍵の確立は,既存のデバイス認証に依存する。デバイス認証は,1つのデバイスが,存在し得る偽者と自己を区別できるようにするための処理である。デバイス認証は,盗聴やなりすまし(masquerading)の対象となりやすい無線のピア・ツー・ピア接続にとって,とても重要である。パス・コード確認,距離の制限,イベント同期などのように,デバイス認証のための様々なアプローチが存在する。これらのアプローチの大部分は人間の関与を必要とする。デバイス認証のためのセキュリティ委託は,1つの接続技術で認証された時点で,デバイスが信頼可能と見なされるということを意味する。結果として,別の接続技術によって指定された認証を実行する必要はない。
【0016】
例えばBluetooth接続のような,新たな無線接続118’と,例えばWi-Fi接続のような,既存の無線接続116’との簡略化デバイス認証の実例が図3を参照して図示される。例えばラップトップ・コンピュータのような,第1のピア・デバイス102’と,例えばスマート・フォンのような,第2のピア・デバイス114’とが,WEPあるいはWPAが使用可能なWi-Fiアドホック・モードで相互接続されうる。これら2つのピア・デバイスは,例えば,既存の無線接続116’のための共有鍵KS認証によって認証されている。これら2つのデバイスの(複数の)持ち主は更に,電話帳とリング・トーンを同期するために,それらのデバイスがBluetoothによってペアリングされていることを望みうる。この場合,Bluetoothペアリング処理全体が取り除かれうる。代わりに,仮想Bluetoothペアリング処理が,ユーザの関与なしに,自動的に開始されうる。例えば,ナンスNのようなBluetooth鍵マテリアルがランダムに生成され,その後,安全なWi-Fiリンクでトランスポートされうる。
【0017】
・・・・・(中略)・・・・・
【0018】
別の接続技術によって確立された共有鍵KSから,新たな共有秘密鍵KNを導出するために,セキュリティ委託が使用されうる。結果として,更なるユーザの関与も,時間のかかる動作も必要なくなる。Wi-FiおよびBluetoothを使用する別の実例として,2つのピア・デバイスがBluetoothによってペアリングされうる。これら2つのデバイスが,高速ファイル転送のためにピア・ツー・ピアWi-Fiリンクをセット・アップすることを望む場合,WEPあるいはWPAのために使用される鍵を導出するために,Bluetoothリンク鍵が使用されうる。」

という記載が存在し,上記引用の,特に段落【0016】の「既存の無線接続116’のための共有鍵KS認証によって認証されている・・・Bluetoothペアリング処理全体が取り除かれうる。代わりに,仮想Bluetoothペアリング処理が,ユーザの関与なしに,自動的に開始されうる。例えば,ナンスNのようなBluetooth鍵マテリアルがランダムに生成され」という記載から,本願発明における「仮想ペアリング」とは,“第1のピア・デバイスと,第2のピア・デバイスとの間が,複数の異なる無線接続を用いて接続可能である時,1つの無線接続において認証がなされている場合は,他の無線接続における認証処理が省略される”というものである。
一方,引用発明においても,引用刊行物1に,

E.「【0070】
またユーザは,インターネット通信に対する認証を行わないので,通信環境による通信経路の選択をユーザに意識させずに処理することができる。
また,安全性の高い通信経路であるBluetooth通信で作成したリンクキーに基づいて,安全性の低いインターネット12を介した通信でも暗号化を行うことにより,第三者に覗き見られる可能性を軽減することができる。これにより,高いセキュリティを必要とする情報であっても,比較的安全にインターネット12を介してやり取りすることができる。」

と記載されているように,引用発明においても,「Bluetooth通信」における認証が成立している場合に,「インターネット通信に対する認証を行わ」ずに,「Bluetooth通信で作成したリンクキーに基づいて」処理を行っており,上記Bにおいて引用した記載内容から,「リンクキーに基づ」く処理とは,「乱数F」と,「リンクキー」から,「暗号鍵」を生成することに他ならないから,結果として,引用発明においても,本願発明における「仮想ペアリング」に相当する処理が行われていることは明らかである。
よって,相違点1,及び,相違点5は,格別のものではない。

2.[相違点2]について
「ナンス」とは,例えば,本願の第1国出願前に既に公知である,特表2009-506438号公報(2009年2月12日公表,以下,これを「周知技術文献1」という)に,

F.「【0006】
暗号の応用では,通常,初期化ベクトル,鍵,ナンス(nonce),ソルト(salt),等に“ランダムな(random)”数を使用する。一般に,暗号的に安全なPRNG(cryptographically secure PRNG, CSPRNG)は,ランダムビット列からその出力を区別することが実行不可能であるような安全なやり方で,予測不可能な入力を用いてシードを与えられる(seed)。本明細書で定義されているように,CSPRNGは,普通のPRNGの全ての特性をもち,さらに,少なくとも2つの他の特性をもつ。これらの特性の1つは,“次のビットの試験(next bit test)”と呼ばれ,生成器から生成されたmビットの列を与えられたとき,実行可能な方法では,(m+1)番目のビットを,2分の1よりも相当に高い確率で予測できないことを示す。第2の特性は,“悪質なシーディングに対する耐性(malicious seeding resistance)”と呼ばれ,攻撃が,一定期間の間CSPRNGへの入力を全てまたは部分的に制御することができても,CSPRNGからの任意のランダムな出力を予測または再生することが依然として実行不可能であることを示す。」

と,また,同じく,本願の第1国出願前に既に公知である,特開2006-127133号公報(2006年5月18日公開,以下,これを「周知技術文献2」という)に,

G.「【0043】
その後,コンテンツ譲渡受付処理機能において,乱数値(ナンス)を生成し,コンテンツの譲渡処理可能な有効期限設定して,携帯電話機2のフラッシュメモリに格納してある公開鍵証明書,乱数値,有効期限,譲渡受付許可メッセージを携帯電話機1に送信する(ステップS404,405)。公開鍵証明書は公開鍵,コンテンツ管理機能を識別するコンテンツ管理機能ID,CA(Certificate Authority:認証局)によるデジタル署名を含み,携帯電話機2のフラッシュメモリに格納されている。」

と記載されているように,暗号の応用分野においては,“ナンス=乱数”であることは周知の技術事項である。
そして,本願明細書に,

「【0013】
第1タイプの無線接続116は高速接続でありうる,また,第2タイプの無線接続118は低電力接続でありうる。第1タイプの無線接続はWi-Fi接続でありうる,また,第2タイプの無線接続はBluetooth接続でありうる。Wi-Fi接続を確立するための新たな鍵は,以下の式に従って形成されることができる。
Wi-Fi鍵=kdf(BTリンク鍵 || ナンス) (式1)
ここで,BTリンク鍵はすでに確立されているBluetooth接続のための共有鍵であり,kdf( )は鍵導出関数である。典型的なkdf( )は,ANSI-X9.63,“Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography”に示されている。付加的なナンスが,新たな鍵の形成に含まれうる。例えば,第2のピア・デバイスは,第1のピア・デバイスによって生成された第1のナンスに加えて,第2のナンスを生成しうる。このように,新たな鍵は,以下の式に従って形成されることができる。
Wi-Fi鍵=kdf(BTリンク鍵 || ナンス1 || ナンス2) (式2)
更に,状況を逆転させると,第1タイプの接続はBluetooth接続でありうる,また,第2タイプの無線接続はWi-Fi接続でありうる。」

と記載されていて,段落【0013】に記載された内容から,本願発明においては,“第2タイプの無線接続における,リンク鍵である,BTリンク鍵(共有鍵)と,ナンスから,Wi-Fi鍵,即ち,本願発明における,少なくとも1つの新たな鍵を生成するするもの”であり,引用発明も,同様に,“乱数Fと,Bluetoothの認証の際に計算した共通鍵とから,暗号鍵を生成している”ことから,上記において指摘したとおり,“ナンス=乱数”と言い得る以上,「少なくとも1つの新たな鍵」を生成する処理に関して,表現の差こそあれ,本願発明と,引用発明との処理内容自体に格別の相違は存在しない。
よって,相違点2は,格別のものではない。

3.[相違点3],及び,[相違点4]について
原審拒絶理由において引用された,本願の第1国出願前に既に公知である,特開2005-244988号公報(2005年9月8日公開,以下,これを「引用刊行物2」という)に,

H.「【請求項29】
前記帯域外機構は,携帯情報端末(PDA),フラッシュメモリ,メモリスティック,バーコード,スマートカード,USB互換装置,Bluetooth互換装置,および赤外線互換装置のうちのいずれかを含むことを特徴とする請求項23に記載のプロトコル。」

I.「【0006】
図1に示すネットワーク環境の一例で,クライアント装置とも呼ばれる複数のクライアントコンピューティング装置105,110,115,および120は,ネットワーク100を介して互いに結合されており,並びに少なくとも1つのサーバ装置125に結合されている。ネットワーク100は,有線および/または無線のネットワークを含め従来の様々なネットワークのトポロジおよび種類のうちの任意のものを表すものとする。ネットワーク100は,さらに公開および/または専用プロトコルを含め,従来の様々なネットワークプロトコルのうちの任意のものを使用することができる。ネットワーク100は,例えばインターネット,および場合によっては1つまたは複数のローカルエリアネットワーク(LAN)の少なくとも一部分を含むことができる。
【0007】
クライアント装置105は,デスクトップパーソナルコンピュータ(PC),ワークステーション,メインフレームコンピュータ,インターネット機器,およびゲームコンソールを含む従来の様々なコンピューティング装置のうちの任意のものを含むことができる。さらに,ネットワーク100に関連付けられているクライアント装置は,有線および/または無線リンクによってネットワーク100と通信することができる携帯情報端末(PDA)110,ラップトップコンピュータ115,並びにセル方式電話120などを含むことができる。さらに,クライアント装置105,110,115,および120のうちの1つまたは複数は,同じ種類の装置,あるいは異なる種類の装置を含むことができる。」

J.「【0012】
図2の実施形態の例によれば,装置205と230との間の信頼関係は,装置205および203が結合して通信を行なうネットワーク100を介して確立されるのではなく,サードパーティの帯域外すなわち非同期の機構(entity)が使用される。こうした機構は,以下「帯域外機構」(out-of-band mechanism)245と呼び,それだけには限定されないが,シリアルケーブル,USBケーブル,赤外線接続,携帯情報端末(PDA),フラッシュメモリ,メモリスティック,バーコード,およびスマートカードなどを含むことができる。・・・・代わりに帯域外機構245の・・・・および赤外線互換の例がプログラム主導,またはユーザにより実行されるものでもよい。・・・・
【0013】
第1の実施形態によれば,Diffie-Hellman暗号プロトコルを使用して少なくとも装置205および230上で対称鍵が確立される。特に,装置205の生成器215および装置230の生成器235は各々,それぞれの装置のローカルの公開/秘密鍵対を生成する。装置205および230で生成された公開鍵の値は,帯域外機構245を介して交換される。したがって,帯域外機構245を介して他方の装置で生成された公開鍵の値をインポートした後,装置205および230は,Diffie-Hellman計算を実行することによって,インポートされた公開鍵の値およびローカルの秘密鍵の値の関数として共有の秘密の値を生成することができる。Diffie-Hellman計算は,本技術分野では知られており,したがってここでは詳しく説明しない。
【0014】
つまり,装置205上の共有秘密値生成器225は,生成器215によって生成された秘密鍵の値,および帯域外機構245を介して装置230からインポートされた公開鍵の値の関数としてDiffie-Hellman共有の秘密の値を生成する。さらに,装置230上の共有秘密値生成器240は,生成器235によって生成された秘密鍵の値,および帯域外機構245を介して装置205からインポートされた公開鍵の値の関数としてDiffie-Hellman共有の秘密の値を生成する。・・・・・
【0015】
各装置で生成されたDiffie-Hellman秘密の値は,暗号化/解読,または他の既知の認証の目的に使用される。」

と記載されているように,引用刊行物2には,“クライアントと,サーバとの間で,ネットワーク接続における,DH鍵共有を行う場合の,クライアントの公開鍵の値を,クライアントとサーバが接続されているネットワークではなく,帯域外機構を経由して,サーバに送り,サーバの公開鍵の値を,サーバとクライアントが接続されているネットワークではなく,帯域外機構を経由して,クライアントに送って,双方で共有する秘密の値を計算する”ことが記載されていて,引用刊行物2に係る発明においては,当該「帯域外機構」として,上記Hに記載されているように,「Bluetooth互換装置」を含んでおり,当該「Bluetooth互換装置」を経由して,「クライアント」,「サーバ」間で,「公開鍵の値」を送受するためには,「クライアント」と,「Bluetooth互換装置」間,及び,「サーバ」と,「Bluetooth互換装置」間に,それぞれ,Bluetooth接続が確立していることは明らかである。
そして,引用刊行物2に係る発明においては,「クライアント」と,「サーバ」とは,接続された「ネットワーク」とは異なる「帯域外機構」として,「Bluetooth互換装置」を経由する通信を用いているが,「クライアント」と,「サーバ」とが,接続された「ネットワーク」とは別の“通信路”として,直接「Bluetooth」で接続し得ることは明らかである。
ここで,DH鍵共有の際に,交換される「公開鍵の値」とは,原審拒絶理由においても指摘されているとおり,“ランダムな値”であるから,引用刊行物2に係る発明における「クライアント」,「サーバ」,「公開鍵の値」は,それぞれ,引用発明における「携帯電話」,「HDDレコーダ」,「乱数F」に相当するので,引用発明においても,“接続が確立しているBluetooth接続を介して,他の通信において共有される鍵を計算するための「乱数F」を,「携帯電話」から,「HDDレコーダ」へ送る”よう構成することは,当業者が適宜なし得る事項である。
そして,上記指摘の構成を採用すれば,引用発明における「Bluetoothの認証の際に計算した共通鍵」が,「すでに確立されているBluetooth接続のための共有鍵」と言い得るものであることは,明らかである。
よって,相違点3,及び,相違点4は,格別のものではない。

上記で検討したごとく,相違点1?相違点5はいずれも格別のものではなく,そして,本願発明の構成によってもたらされる効果も,引用発明,引用刊行物2に係る発明,及び,周知技術文献に記載された技術からもたらされる効果を参酌すれば,当業者であれば当然に予測可能なものに過ぎず,格別なものとは認められない。

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

よって,結論のとおり審決する。
 
審理終結日 2015-04-20 
結審通知日 2015-04-21 
審決日 2015-06-04 
出願番号 特願2012-503652(P2012-503652)
審決分類 P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 辻本 泰隆
特許庁審判官 石井 茂和
木村 貴俊
発明の名称 既存の無線接続鍵を使用する仮想ペアリングのための装置および方法  
代理人 野河 信久  
代理人 井上 正  
代理人 岡田 貴志  
代理人 蔵田 昌俊  
代理人 佐藤 立志  
代理人 砂川 克  
代理人 赤穂 隆雄  
代理人 井関 守三  
代理人 堀内 美保子  
代理人 河野 直樹  
代理人 峰 隆司  
代理人 福原 淑弘  
  • この表をプリントする

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