【事件の表示】
　特願２０１２−５１９５６５「効率的鍵管理システムおよび方法」拒絶査定不服審判事件〔平成２３年　１月１３日国際公開，ＷＯ２０１１／００５５６９，平成２４年１２月２０日国内公表，特表２０１２−５３３２１８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２０１０年６月２３日（パリ条約による優先権主張外国庁受理２００９年７月７日（以下，「優先日」という），アメリカ合衆国）を国際出願日とする出願であって，平成２４年１月６日付けで特許法第１８４条の５第１項に規定される書面が提出され，同年３月５日付けで特許法第１８４条の４第１項の規定による翻訳文が提出され，同日付けで審査請求がなされ，平成２５年５月１５日付けで拒絶理由通知（同年５月２８日発送）がなされ，これに対して同年８月１６日付けで意見書が提出されると共に，同日付けで手続補正がなされたが，同年９月４日付けで拒絶査定（同年９月１０日謄本送達）がなされたものである。　
　これに対して，「原査定を取り消す，この出願は特許をすべきものである，との審決を求める。」との請求の趣旨で，平成２５年１２月２７日付けで審判請求がなされると共に，同日付けで手続補正がなされ，平成２６年３月２６日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ，これに対して同年５月２０日付け及び同年６月９日付けで上申書が提出された。　
　
　
２　本願発明
　
　本願の請求項５に係る発明（以下「本願発明」という。）は，平成２５年１２月２７日付けの手続補正書により補正された特許請求の範囲の記載からみて，その請求項５に記載されたとおりの次のものと認める。
　「少なくとも１つのプロキシサーバを介して少なくとも１つの第１のデバイスから少なくとも１つの第２のデバイスにコスト効率のよい，安全な鍵交換を提供するシステムであって，
　少なくとも１つのプロキシサーバを介する少なくとも１つの第１のデバイスから少なくとも１つの第２のデバイスへの第１の鍵交換と，
　インターネットのメディアストリームを介する少なくとも１つの第２のデバイスから少なくとも１つの第１のデバイスへの第２の鍵交換と
　を備える，システム。」
　
　
３　引用文献
　
（１）　引用文献１
　
　本願の優先日前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２５年５月１５日付けの拒絶理由通知において引用された文献である「Prateek Gupta，Vitaly Shmatikov，Security Analysis of Voice-over-IP Protocols，Computer Security Foundations Symposium，2007. CSF'07. 20th IEEE，IEEE，２００７年，pp.49-63(全15頁）」（以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ．「
The transmission of voice communications as datagram　packets over IP networks, commonly known as Voice-over-IP (VoIP) telephony
・・・（中略）・・・
　The VoIP protocol stack is shown in figure 1. For the purposes of our analysis, we will divide it into four layers: signaling, session description, key exchange and secure media (data) transport. This division is quite natural, since each layer is typically implemented by a separate protocol.
　Signaling is an application-layer (from the viewpoint of the underlying communication network) control mechanism used for creating, modifying and terminating VoIP sessions with one or more participants. 
Signaling protocols include Session Initiation Protocol (SIP) [27], H.323 and MGCP. Session description protocols such as SDP [20] are used for initiating multimedia and other sessions, and often include key exchange as a sub-protocol.
　
Key exchange protocols are intended to provide a cryptographically secure way of establishing secret session keys between two or more participants in an untrusted environment.
Key exchange protocols for VoIP sessions include SDP's Security DEscriptions for Media Streams (SDES)
　Secure media transport aims to provide confidentiality, message authentication and integrity, and replay protection to the media (data) stream. In the case of VoIP, this stream typically carries voice datagrams. Confidentiality means that the data under encryption is indistinguishable from random for anyone who does not have the key. Message authentication implies that if Alice receives a datagram apparently sent by Bob, then it was indeed sent by Bob. Data integrity implies that any modification of the data in transit will be detected by the recipient. 
An example of a secure media transport protocol used on VoIP communications is Secure Real-time Transport Protocol (SRTP) [6], which is a profile of Real-time Transport Protocol (RTP) [28].
「当審仮訳：
　
ボイスオーバーＩＰ（ＶｏＩＰ）電話としても一般的に知られているＩＰネットワークを介したデータグラムパケット，音声通信の伝送
・・・（中略）・・・
　ＶｏＩＰプロトコルスタックは，図１に示されている。我々の解析の目的のために，シグナリング，セッション記述，鍵交換および安全なメディア（データ）転送の４つのレイヤーにＶｏＩＰプロトコルスタックを分割する。各レイヤーは，典型的に別個のプロトコルによって実装されるので，これは，非常に自然な分け方である。
　シグナリングは，１人以上の参加者とのＶｏＩＰセッションを生成，修正，終了するための（下層にある通信ネットワークの観点から）アプリケーションレイヤー制御メカニズムである。
シグナリング・プロトコルは，セッション開始プロトコル（ＳＩＰ）[27]，Ｈ．３２３およびＭＧＣＰが含まれる。ＳＤＰ[20]のようなセッション記述プロトコルは，マルチメディアおよび他のセッションを開始するために使用され，多くの場合，サブプロトコルとして鍵交換が含まれている。
　
鍵交換プロトコルは，信頼できない環境で複数の参加者間の秘密セッションキーを確立するための暗号的に安全な方法を提供することを意図している。
ＶｏＩＰセッションのための鍵交換プロトコルは，メディアストリーム用のＳＤＰのセキュリティ記述（ＳＤＥＳ）
を含む
　セキュア・メディア・トランスポートは，メディア（データ）ストリームに機密性，メッセージ認証及び完全性，およびリプレイ・プロテクションを提供することを目的とする。 ＶｏＩＰの場合には，この流れは，典型的には，音声データグラムを運ぶ。機密性とは，暗号化の下で，データが鍵を持っていない人がランダムと区別できないことを意味する。メッセージ認証は，アリスが明らかにボブによって送信されたデータグラムを受信した場合，それが実際にボブによって送信されたということを意味する。データ完全性は転送中のデータのどのような変更も受信者によって検出されることを意味する。 
ＶｏＩＰ通信で使用される安全なメディア・トランスポート・プロトコルの例は，セキュア・リアルタイム・トランスポート・プロトコル（ＳＲＴＰ）[6]であり，それは，リアルタイム転送プロトコル（ＲＴＰ）[28]のプロファイルのひとつである。
　
Ｂ．「
SIP uses a HTTP-like request-response mechanism for initiating a two-way communication session.
Figure 2 shows a SIP connection setup with an intermediate proxy server between the end points. In order to set up a connection between Alice's and Bob's UAs, Alice's SIP URI is first resolved into the IP address of the UA under which Alice is currently registered. SIP address resolution and routing is usually not done by the UA itself, but rather delegated to the proxy server for the UA's domain. In our example, Bob's proxy will make a DNS lookup to determine the address of Alice's proxy server.
「当審仮訳：
ＳＩＰは，双方向の通信セッションを開始するために，ＨＴＴＰライクの要求・応答メカニズムを使用する。
図２は，エンドポイント間の中間プロキシサーバとのＳＩＰ接続設定を示している。アリスとボブのＵＡとの間の接続を設定するために，アリスのＳＩＰ　ＵＲＩは，アリスが現在登録されているＵＡのＩＰアドレスを最初に解決する。ＳＩＰアドレス解決とルーティングは，通常はＵＡ自身によって行われているのではなく，ＵＡのドメイン用のプロキシサーバーに委任されている。この例ではボブのプロキシは，アリスのプロキシサーバーのアドレスを決定するために，ＤＮＳルックアップを行う。
　
Ｃ．「2.3 Key exchange: SDES, ZRTP, and MIKEY
　
Unlike session initiation and description, key exchange is a fundamental security mechanism. Therefore, we describe the key exchange protocols specific to VoIP in more detail.
SDES. 
SDES [1] is the key transport extension of the SDP protocol. It provides a way to signal and negotiate cryptographic key(s) and other session parameters for media streams in general, and for SRTP in particular.
The only method supported for key exchange is inline :, which specifies that the key itself must be included in plaintext. In other words, the key is embedded directly in the SDP attachment of a SIP message.
　SIP security mechanisms are described in detail in appendix A. For our purposes, it is enough to observe that transport-layer protection in SIP can be done using either TLS [15] (if the transport layer is TCP), or S/MIME [25]. The use of TLS is deprecated because TLS does not provide end-to-end protection over a chain of proxies. 
Moreover, it assumes that the next hop in the SIP proxy chain is trusted.
「当審仮訳：
２．３　鍵交換：ＳＤＥＳ，ＺＲＴＰ，およびＭＩＫＥＹ
　
セッション開始と記述とは異なり，鍵交換は，基本的なセキュリティ・メカニズムである。したがって，我々は，より詳細にＶｏＩＰに対する特定の鍵交換プロトコルを記述する。
ＳＤＥＳ. 
ＳＤＥＳ[1]はＳＤＰプロトコルの鍵送信の拡張機能である。これは，一般的にメディアストリームのために（特に，ＳＲＴＰのために），（複数の）暗号鍵と他のセッションパラメータに信号を送り，ネゴシエーションを実行する方法を提供する。
鍵交換のためにサポートされている唯一の方法はinlineである。：その方法は，キー自体が平文に含まれなければならないことを指定している。言い換えれば，キーは，ＳＩＰメッセージのＳＤＰアタッチメントに直接埋め込まれている。
　ＳＩＰのセキュリティメカニズムが付録Ａに詳細に記載されている、我々の目的にとって，ＴＬＳ[15]（トランスポートレイヤーがＴＣＰである場合）、あるいはＳ／ＭＩＭＥ[25]のどちらかを使用して，ＳＩＰ内でそのトランスポートレイヤーの保護を監視することは十分である。ＴＬＳはプロキシの連鎖を越えてエンド・トゥ・エンドの保護を提供していないため、ＴＬＳの使用が推奨されていない。
また、ＳＩＰプロキシチェーン内の次のホップが信頼されていることを前提としている。
　
Ｄ．「2.4 Secure transport layer: SRTP
　VoIP datagrams are usually transported using the Realtime Transport Protocol (RTP). SRTP [6] is a profile of RTP which aims to provide confidentiality, message authentication,and replay protection to RTP data and control traffic. SRTP uses a single master key to derive keying material via a cryptographically secure hash function.
 In SRTP, a cryptographic context refers to the cryptographic state information maintained by the sender and receiver for the media stream. This includes the master key, session keys, identifiers for encryption and message authentication algorithms, lifetime of session keys, and a rollover counter (ROC).
・・・（中略）・・・
SRTP key derivation. 
SRTP uses a cryptographically secure pseudo-random function (PRF) to generate encryption and authentication session keys from the master key, master salt and the packet sequence number. The sequence number of the packet is chosen by the sender. Both master key and master salt are derived deterministically by applying HMAC, keyed with the material received during the key exchange protocol, to a known plaintext (as defined by the key exchange protocol).
　Session key derivation involves an 8-bit label, master salt ms, the key derivation rate, as determined by the cryptographic context, and the index (48-bit ROC||SEQ). Let || denote string concatenation. Let x = (label||r) xor ms, where r is the integer quotient obtained by dividing the index by the key derivation rate. Let mk denote the master key and PRF(k, x) denote a pseudorandom function family such that for the secret random key k, given m-bit x, the output is an n-bit string computationally indistinguishable from a truly random n-bit string. The session keys are generated as PRF(mk, x), using different labels for encryption, authentication and salting keys, respectively.
　An important point to note is that there is no receiver generated randomness in the session key derivation process. This will allow us to break the protocol because security of the stream cipher-like encryption used in SRTP depends critically on the keystream never repeating. This is emphasized several times in the SRTP specification [6], which warns about the dangers of “two-time pad” (a colloquial term for keystream reuse).」（第５３頁右欄第１８行〜第５４頁左欄第３０行）
「当審仮訳：
２．４　セキュア・トランスポート・レイヤー：ＳＲＴＰ
　ＶｏＩＰのデータグラムは，通常，リアルタイム転送プロトコル（ＲＴＰ）を使用して転送される。 ＳＲＴＰ[6]は，ＲＴＰデータと制御トラフィックに対する，機密性，メッセージ認証，および再生保護を提供することを目的とするＲＴＰのプロファイルである。 ＳＲＴＰは暗号的に安全なハッシュ関数によってキー生成の材料を導出する単一のマスターキーを使用している。 
ＳＲＴＰでは、暗号コンテキストは、メディアストリームを用いて，送信者と受信者により維持された暗号状態情報を参照する。これは，マスターキー，セッションキー，暗号化およびメッセージ認証アルゴリズムのための識別子，セッションキーの寿命，およびロールオーバー・カウンター（ＲＯＣ）を含む。
・・・（中略）・・・
ＳＲＴＰ鍵導出。　
ＳＲＴＰは，マスターキー，マスターソルト，パケットシーケンス番号から暗号化および認証セッションキーを生成する暗号学的に安全な擬似ランダム関数（ＰＲＦ）を使用する。パケットのシーケンス番号は，送信者によって選択される。マスターキーとマスターソルトの両方が，既知の平文（鍵交換プロトコルによって定義された）に，鍵交換プロトコル中に受信された材料をキーとして，ＨＭＡＣを適用することにより決定論的に導出される。
　セッションキー導出は８ビットのlabel，マスターソルトms，暗号コンテキストによって決定される鍵導出率，およびインデックス（４８ビットＲＯＣ||ＳＥＱ）が含まれる。||は文字列の連結を意味する。 ｘ =（〈label||r〉）xor msにおいて，rは鍵導出率でインデックスを割って得られた整数の商である。 mkをマスターキーを示すものとし，ＰＲＦ（ｋ，ｘ）は，秘密ランダムキーｋに対して，与えられたｍビットｘは，出力が，真にランダムなｎビット文字列と計算的に区別できないのｎビットの文字列であるような，擬似ランダム関数ファミリーを意味する。セッションキーは，それぞれ，暗号化，認証処理及びソルティングキーのために異なるラベルを使用して，ＰＲＦ（mk，ｘ）のように生成される。
　注目すべき重要な点は，セッションキー導出プロセスにおいて，ランダムネスを発生させる受信機が存在しないことである。これは，ＳＲＴＰで使用されるストリーム暗号のような暗号化のセキュリティーが，キーストリームが決して繰り返さないことに厳密に依存するという理由で，我々がプロトコルを解読することを可能にするであろう。これは，「２タイムパッド」（キーストリーム再利用に対する俗称である）の危険性について警告している，ＳＲＴＰ仕様[6]中に数回を強調されている。」
　
Ｅ．「3.2 Attack on SDES/SRTP
　Figure 4 shows an attack on 
SRTP when used in combination with SDES key exchange
　S/MIME does not provide any anti-replay protection.After the original session has been torn down, the attacker can replay Bob’s original INVITE message to Alice, containing an S/MIME-encrypted SDP attachment with the SDES key transfer message.(Fig. 4 shows the sessions running concurrently, but the attack need not be adaptive; one session can be executed after the other.)」（第５５頁左欄第２７行〜第３２行）
「当審仮訳：
　３.２ ＳＤＥＳ／ＳＲＴＰ に対する攻撃
　
ＳＤＥＳ鍵交換と組み合わせて利用される場合のＳＲＴＰ
　Ｓ／ＭＩＭＥはいかなるアンチ・リプレイ保護も提供しない。
元のセッションが切断された後，ＳＤＥＳキー転送メッセージにＳ／ＭＩＭＥで暗号化されたＳＤＰの添付ファイルを含んだ，ボブのアリスに対するオリジナルＩＮＶＩＴＥメッセージを，攻撃者はリプレイすることができる。
　
Ｆ．「　
To prevent keystream re-use, SRTP responder should use its own fresh randomness as part of the key derivation process, e.g., as input to HMAC used in session key derivation. This randomness need not be secret. It can be publicly communicated to the sender as part of SRTP session establishment to ensure that the sender derives the same set of session keys.
「当審仮訳：
　
キーストリームの再使用を防止するために，ＳＲＴＰの応答者は，鍵導出プロセスの一部として，例えば，セッションキーの導出に使用されるＨＭＡＣへの入力として，独自の新たなランダムネスを使用するべきである。このランダムネスは秘密である必要はない。ＳＲＴＰセッション確立の一部は，送信者に，セッションキーの同じセットを導出することを確実にするように，公然と送信者に伝達することができる。
　
Ｇ．「A 
SIP security mechanisms
　SIP security mechanisms can be broadly divided into those devoted to authentication, data integrity, and confidentiality.
Authentication.　SIP supports HTTP basic authentication and HTTP digest authentication [17]. HTTP basic authentication requires username and matching password to be sent in plaintext as part of the HTTP header request. This has serious security risks, and HTTP basic authentication has been deprecated in SIP version 2 (SIPv2) [27].
　HTTP digest authentication is based on a simple challenge-response paradigm. 
The digest authentication scheme challenges the remote user with a random nonce.
A valid response consists of 
the nonce value
・・・（中略）・・・
　The third option is IPsec. IPsec provides two mechanisms for authentication and, in the case of ESP, confidentiality: Authentication Header (AH) and Encapsulating Security Payload (ESP). Since 
each proxy server on the path
One commonly accepted key establishment protocol for IPsec Internet Key Exchange (IKE) [21]. IKE may be used with pre-shared secrets or PKI infrastructure.
「当審仮訳：
Ａ　
ＳＩＰのセキュリティメカニズム
　ＳＩＰセキュリティメカニズムは，認証，データの整合性，および機密性を扱っているものに大きく分けることができる。
認証。　ＳＩＰは，ＨＴＴＰ基本認証をサポートし，ＨＴＴＰダイジェスト認証[17]。ＨＴＴＰ基本認証は，ＨＴＴＰヘッダー要求の一部として平文テキストで送信されるユーザー名と一致するパスワードが必要となる。これは，重大なセキュリティ上のリスクがあり，ＨＴＴＰ基本認証は，ＳＩＰバージョン２（ＳＩＰｖ２）[27]で廃止された。
　ＨＴＴＰダイジェスト認証は単純なチャレンジ・レスポンス・パラダイムに基づいている。
ダイジェスト認証方式は，ランダム・ナンスでリモートユーザーに問い合わせする。
有効なレスポンスは，
ナンス値と
を含むいくつかの他のパラメータで構成されている。
・・・（中略）・・・
　第三の選択肢は，ＩＰｓｅｃである。ＩＰｓｅｃは認証のための２つのメカニズムと，ＥＳＰの場合には，機密性（認証ヘッダー（ＡＨ）とカプセル化セキュリティ・ペイロード（ＥＳＰ））のメカニズムを提供します。
経路上の各プロキシサーバ
ＩＰｓｅｃのインターネットキー交換（ＩＫＥ）[21]のためのキー確立プロトコルを一般的に受け入れている。ＩＫＥは，事前共有秘密またはＰＫＩインフラストラクチャで使用することができる。
　
（２）引用発明の認定
　
　ここで，上記引用文献１に記載されている事項を検討する。
　
ア　引用文献１には，「システム」の構成としては明記されていないが，上記Ａには，「ボイスオーバーＩＰ（ＶｏＩＰ）電話としても一般的に知られているＩＰネットワークを介したデータグラムパケット、音声通信の伝送」について記載されており，これらの記載から，ＩＰネットワークを使った音声通信手法であるＶｏＩＰ電話を用いた「ＶｏＩＰ電話システム」を読み取ることができる。
イ　上記Ｇの「ＳＩＰのセキュリティメカニズム」における，「経路上の各プロキシサーバ」との記載等から，「経路上」に「プロキシサーバ」がいくつか存在することが読み取れるから，引用文献１には，ＳＩＰにおいて，「経路上に少なくとも１つのプロキシサーバ」が存在することが記載されているといえる。
　また，上記Ｂの「図２は，エンドポイント間の中間プロキシサーバとのＳＩＰ接続設定を示している。アリスとボブのＵＡとの間の接続を設定するために，アリスのＳＩＰ　ＵＲＩは，アリスが現在登録されているＵＡのＩＰアドレスを最初に解決する。ＳＩＰアドレス解決とルーティングは，通常はＵＡ自身によって行われているのではなく，ＵＡのドメイン用のプロキシサーバーに委任されている。この例ではボブのプロキシは，アリスのプロキシサーバーのアドレスを決定するために，ＤＮＳルックアップを行う。」との記載等から，引用文献１には，「ボブのＵＡとアリスのＵＡとの間の中間プロキシサーバを介したＳＩＰ接続を行う」ことが読み取れる。
　したがって，これらの記載から，上記ＶｏＩＰ電話システムは，「経路上に少なくとも１つのプロキシサーバを有し，ボブのＵＡとアリスのＵＡとの間をこれらの中間プロキシサーバを介したＳＩＰ接続を行」うものと認められる。
　
ウ　上記イで確認した記載，上記Ｃの「鍵交換のためにサポートされている唯一の方法はinlineである。：その方法は，キー自体が平文に含まれなければならないことを指定している。言い換えれば，キーは，ＳＩＰメッセージのＳＤＰアタッチメントに直接埋め込まれている。」との記載及び上記Ａの「ＶｏＩＰセッションのための鍵交換プロトコルは，メディアストリーム用のＳＤＰのセキュリティ記述（ＳＤＥＳ）…（中略）…を含む」との記載等から，「プロキシサーバを介するＳＩＰ接続において，ボブのＵＡからアリスのＵＡへの転送情報にキーが含まれている」ことが読み取れる。
　
エ　上記Ｅの「ＳＤＥＳ鍵交換と組み合わせて利用される場合のＳＲＴＰ」，「元のセッションが切断された後，ＳＤＥＳキー転送メッセージにＳ／ＭＩＭＥで暗号化されたＳＤＰの添付ファイルを含んだ，ボブのアリスに対するオリジナルＩＮＶＩＴＥメッセージを，攻撃者はリプレイすることができる。」との記載，上記Ｄの「ＳＲＴＰでは、暗号コンテキストは、メディアストリームを用いて，送信者と受信者により維持された暗号状態情報を参照する。これは，マスターキー，セッションキー，暗号化およびメッセージ認証アルゴリズムのための識別子，セッションキーの寿命，およびロールオーバー・カウンター（ＲＯＣ）を含む。」との記載及び，上記Ｆの「キーストリームの再使用を防止するために，ＳＲＴＰの応答者は，鍵導出プロセスの一部として，例えば，セッションキーの導出に使用されるＨＭＡＣへの入力として，独自の新たなランダムネスを使用するべきである。このランダムネスは秘密である必要はない。ＳＲＴＰセッション確立の一部は，送信者に，セッションキーの同じセットを導出することを確実にするように，公然と送信者に伝達することができる。」との記載等から，「ＳＲＴＰにおいて，メディアストリームを用いて，応答者は，送信者に対して，鍵導出プロセスに用いるランダムネスを伝達する」ことが読み取れる。また，ここで，「応答者」，「送信者」がそれぞれ，上記Ｂの記載の「アリス」，「ボブ」に対応することが読み取れる。
　したがって，引用文献１には，「ＳＲＴＰにおいて，メディアストリームを用いて，ボブは，アリスに対して，鍵導出プロセスに用いるランダムネスを伝達する」ことが記載されていると認められる。
　
オ　以上，ア〜エで検討した事項を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　
　「経路上に少なくとも１つのプロキシサーバを有し，ボブのＵＡとアリスのＵＡとの間をこれらの中間プロキシサーバを介したＳＩＰ接続を行い，　
　前記プロキシサーバを介するＳＩＰ接続において，ボブのＵＡからアリスのＵＡへの転送情報にキーが含まれており，
　ＳＲＴＰにおいて，メディアストリームを用いて，アリスは，ボブに対して，鍵導出プロセスに用いるランダムネスを伝達する
　ようにしたＶｏＩＰ電話システム。」
　
４　対比
　
　本願発明と引用発明とを対比する。
　
（１）引用発明は，「経路上に少なくとも１つのプロキシサーバを有し」ており，「中間プロキシを介したＳＩＰ接続を行う」ことから，本願発明と，「少なくとも１つのプロキシサーバを介して」いる点で共通し，「ＵＡ」は，ＶｏＩＰにおいて，「Ｕｓｅｒ　Ａｇｅｎｔ」の略であり，端末（ＩＰ電話機）を指すことから，引用発明の「ボブのＵＡ」，「アリスのＵＡ」が，それぞれ，本願発明の「第１のデバイス」，「第２のデバイス」に相当する。
　また，引用発明も本願発明も，「安全な鍵交換を提供するシステム」である点で共通する。
　
（２）引用発明には，ＶｏＩＰのセッション記述（ＳＤＰ）において，「前記プロキシサーバを介するＳＩＰ接続において，ボブのＵＡからアリスのＵＡへの転送情報にキーが含まれて」いることから，「プロキシサーバを介する」点は明らかであり，さらに，本願発明における「第１のデバイスから第２のデバイス」への「転送情報にキーが含まれ」ていることが読み取れる。
　したがって，引用発明と本願発明とは，「少なくとも１つのプロキシサーバを介する第１のデバイスから第２のデバイスへの鍵交換」を備える点で共通している。
　
（３）引用発明は，ＳＲＴＰにおいて，「メディアストリームを用いて，アリスは，ボブに対して，鍵導出プロセスに用いるランダムネスを伝達する」ものであり，「アリス」側は，本願発明における「第２のデバイス」に相当し，「ボブ」側は，本願発明における「第１のデバイス」に相当することから，引用発明と本願発明とは，「メディアストリームを介して，第２のデバイスから第１のデバイスに鍵導出プロセスに用いる情報を転送する」点で共通している。
　
（４）以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
「少なくとも１つのプロキシサーバを介して第１のデバイスからの第２のデバイスに安全な鍵交換を提供するシステムであって，
　少なくとも１つのプロキシサーバを介する第１のデバイスから第２のデバイスへの第１の鍵交換と，
　メディアストリームを介する第２のデバイスから第１のデバイスへの鍵導出プロセスに用いる情報を転送すること
　を備える，システム。」
　
（相違点１）
　本願発明は，「コスト効率のよい」「システム」と特定されているのに対して，引用発明は，その点に言及されていない点。
　
（相違点２）
　本願発明は，「インターネットのメディアストリームを介する」と特定されているのに対して，引用発明は，「メディアストリームを介する」ものの，それが，「インターネットのメディアストリームを介する」かどうかが不明な点。
　
（相違点３）
　本願発明は，「第２のデバイスから第１のデバイスへ第２の鍵交換」を行っているのに対して，引用発明は，「鍵導出プロセスに用いる情報」を「送信者に伝達」しているものの，鍵交換であるのかが不明な点。
　
　
５　当審の判断
　
　上記相違点について検討する。
　
（１）　相違点１について
　
　本願発明において，何と比較して「コスト効率のよい」ものであるのかという点が明確ではないものの，本願発明の「コスト効率のよい」については，本願の明細書の段落【００１３】，【００１４】の記載を参酌すると，「
本明細書に記載のシステムは、ＰＫＩの複雑さおよびコストなしに、
ＰＫＩインフラストラクチャを用いる必要をなくす
　したがって，相違点１は，引用発明においても，当然得られる効果であるといえることから，格別なものではない。
　
（２）　相違点２について
　
　本願発明の，「インターネットのメディアストリームを介する」は，本願の明細書の段落【００２０】の「本方法のメディアチャネルは、インターネットメディアチャネルでもよい。」との記載に対応するものと認められる。
　ここで，引用文献１においても，引用文献１の上記Ｇにおいて，「ＩＰｓｅｃのインターネットキー交換（ＩＫＥ）[21]のためのキー確立プロトコルを一般的に受け入れている。ＩＫＥは，事前共有秘密またはＰＫＩインフラストラクチャで使用することができる。」と記載されているように，ＩＫＥという仕組みで，インターネットを用いた鍵交換が普通に行われていることが読み取れる。
　したがって，引用発明においても，上記Ｇの記載等を参酌して，「インターネットのメディアストリームを介する」ようにすることは，当業者が適宜為し得る程度のことに過ぎない。
　
（３）　相違点３について
　
　本願発明の，「第２の鍵交換」との処理は，本願の明細書の段落【００１５】の「複数層を組み込んでその層内の問合せを介してランダムセッション鍵を作り出す鍵管理システムおよび方法は、本明細書に記載の原理にしたがって、単純な、コスト効率のよい、非常に安全な鍵管理システムを提供する。さらに、本システムは、ＳＩＰでの使用に適している。ランダムｒはボブがｋを使用する度に生成されることになるため、フォーキングが同じｋと通信するボブの異なるインスタンス内で生じないという点で、追加の利点がこのインタラクティブ鍵管理システムで実現される。さらに、アリスおよびボブは、将来のセッションでより効率的で安全な鍵交換を確立するために、長期ＰＳＫを確立することができる。」における「ランダムｒ」や，段落【００１３】における「ランダムナンスｒ」を，「アリスに返信する」処理に対応するものと認められる。
　してみると，引用発明における，「鍵導出プロセスに用いる情報」は，「ランダムネス」であり，引用発明においても，当該「ランダムネス」を「送信者（アリス）に伝達する」ことから，本願発明と同様の処理をしているといえる。
　よって，相違点３も格別なものではない。
　
（４）　まとめ
　
　以上のように，相違点１〜３に係る構成は，引用発明に基づいて，当業者であれば容易に想到しうる事項である。
　また，本願発明の奏する作用効果も，引用発明の属する技術分野の周知技術の奏する作用効果から予測される範囲内のものに過ぎず，格別顕著なものでもない。
　したがって，本願発明は，上記引用文献１に記載された発明に基づいて，当業者が容易に発明をすることができたものである。
　
　
６　むすび
　
　以上のとおり，本願発明は，その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，当業者が容易に発明することができたものであるから，特許法第２９条第２項の規定により特許を受けることができないものであり，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　
　よって，結論のとおり審決する。