【事件の表示】
　特願２００９−５０１８２１「ディジタル著作権保護のための方法、システム、加入者装置、及びマルチメディアサーバ」拒絶査定不服審判事件〔平成１９年１０月　４日国際公開、ＷＯ２００７／１０９９９９、平成２１年　９月　３日国内公表、特表２００９−５３１８８０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００７年３月２８日を国際出願日（優先権主張日：２００６年３月２９日、中国）とする出願であって、平成２３年８月１９日付けで拒絶理由通知がなされ、平成２３年１１月１６日付けで意見書の提出とともに手続補正がなされたが、平成２４年３月２２日付けで拒絶査定がなされ、これに対して平成２４年７月２６日付けで拒絶査定不服審判請求がなされ、平成２４年７月２６日付けで手続補正がなされ、平成２５年１月２４日付けの当審の前置報告を引用した審尋に対して平成２５年４月２４日に回答がなされ、当審において平成２５年１１月２１日付けで拒絶理由通知がなされ、平成平成２６年２月２５日付けで意見書が提出され、当審において平成２６年４月４日付けで拒絶理由がなされ、平成２６年６月２４日付けで意見書が提出されたものである。 
　
２．平成２６年４月４日付の拒絶理由通知の概要
　当審において通知した拒絶理由通知の概要は以下のとおりである。
「Ａ　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号及び第２号に規定する要件を満たしていない。
 　 
 　　　　　　　　　　　　　　　　　記
　請求項１における「ＩＰＳｅｃ通信チャネルを確立するための認証情報を含む権利オブジェクト」及び「権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報」との記載について、明細書の例えば第【００４４】段落には「ステップ４４においては、権利オブジェクト（ＲＯ）の生成の際、ストリームメディアサーバ及び権利発行装置は、ＩＰＳｅｃ通信チャネルを確立するための認証情報を協議する。ステップ４７Ａにおける協議を介してセキュリティ・アソシエーション（ＳＡ）を確立する際に、識別及び認証データを互いに配信するのに、上記認証情報が用いられる。ステップ４７Ａにおける認証がパスしたときのみ、ＩＰＳｅｃの第２の段階のＳＡに手順が進むことができる。それによりＩＰデータパケットを暗号化するためのキーを協議する。」と記載されており、また、第【００４５】段落乃至第【００６０】段落にはＩＰＳｅｃ通信チャネルの確立手順について説明されてはいるものの、これらは通常の確立手順と変わりはなく、また、第【００５９】段落の記載によると、上記「認証情報」はあくまでもユーザ装置とストリームメディアサーバの識別検証に使用されるものであり、その結果としてＩＰＳｅｃ通信が許可されるものであるとしても、この「認証情報」は直接“ＩＰＳｅｃ通信チャネルを確立するため”に使用されるものではないことから、上記記載は不正確な記載であると考えられる。
　また、請求項６、９、１２、１４、１６、１９についても同様の記載不備がある。
 　　 
　よって、請求項１−２０に係る発明は明確でなく、また、発明の詳細な説明で裏付けされていないものでもある。
 　 
Ｂ　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
 　 
 　　　　　記　　　（引用文献等については引用文献等一覧参照）
・請求項　１−２０
・引用文献等 １−３
・備考
　・・・（途中省略）・・・
　　
　　　　　　　　　　引　用　文　献　等　一　覧 
１．山本修一郎　外１名、２階層ＰＫＩ技術によるサービス利用権認証、ＣＯＭＰＵＴＥＲ＆ＮＥＴＷＯＲＫ　ＬＡＮ、株式会社オーム社、２００４年９月１日、第２２巻、第９号、ｐ．４３−４７
２．特開２００４−２６６７９０号公報
３．山田英史、ＩＰＳｅｃによる異機種混在環境のＶＰＮ構築法(前編)、ＳｏｆｔｗａｒｅＤｅｓｉｇｎ、株式会社技術評論社、２０００年７月１８日、第１１７号、ｐ．２００−２０３」
　　
３．当審の判断
［１］特許法第３６条第６項第１号及び第２号について
（１）上記拒絶理由通知における理由Ａは、請求項１における「ＩＰＳｅｃ通信チャネルを確立するための認証情報を含む権利オブジェクト」及び「権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報」との記載は不正確な記載であって、発明が明確でなく、また、発明の詳細な説明で裏付けされていないものでもあるというものである。
　この点について、明細書の例えば第【００４４】段落には「ステップ４４においては、権利オブジェクト（ＲＯ）の生成の際、ストリームメディアサーバ及び権利発行装置は、ＩＰＳｅｃ通信チャネルを確立するための認証情報を協議する。ステップ４７Ａにおける協議を介してセキュリティ・アソシエーション（ＳＡ）を確立する際に、識別及び認証データを互いに配信するのに、上記認証情報が用いられる。ステップ４７Ａにおける認証がパスしたときのみ、ＩＰＳｅｃの第２の段階のＳＡに手順が進むことができる。それによりＩＰデータパケットを暗号化するためのキーを協議する。」と記載されている。
　また、ＩＰｓｅｃ通信チャネルの第１段階の手順について、明細書の第【００４５】段落乃至第【００６０】段落には、
「【００４５】
　ＩＰＳｅｃの第１段階のＳＡは通常、以下のステップを含む。
　【００４６】
　第１ステップは、ポリシー協議を含む。
　【００４７】
　この第１ステップでは、４つの必須パラメータが協議される。
　【００４８】
（１）暗号化アルゴリズム：ＤＥＳ又は３ＤＥＳが選択される。
　【００４９】
（２）ハッシュアルゴリズム：ＭＤ５又はＳＨＡが選択される。
　【００５０】
（３）認証方法：証明認証、既定の共有鍵認証又はＫｅｒｂｅｒｏｓ　ｖ５認証が選択される。
　【００５１】
（４）デフィー・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）グループの選択
　第２ステップは、鍵交換を含む。
　【００５２】
　「鍵交換」という用語が使用されているにもかかわらず、ユーザ装置とストリームメディアサーバとの間で実際の鍵交換は全く行われない。その代わり、共有鍵を生成するのに必要な基本情報は交換される。交換は公開にしても、保護の下に行われてもよい。ユーザ装置及びストリームメディアサーバは各々、鍵生成の情報を互いに交換した後、各々、同一の共有主キーを生成することができ、それにより以降の認証手順を保護する。
　【００５３】
　第３のステップは、認証を含む。
　【００５４】
　通信エンティティ及び通信チャネルは、共有主キー及び第１ステップで決定された協議アルゴリズムの両方を利用することにより、認証される。第３ステップでは、エンティティ・タイプ、ポート番号、プロトコルを含む認証されるべき全てのエンティティ・ペイロードの秘密性及びインテグリティは、第２ステップで生成された共有主キーの実行により保証される。
　【００５５】
　本発明の一実施の形態によれば、ステップ４７Ａにおけるユーザ装置及びストリームメディアサーバが第１の段階のセキュリティ・アソシエーション（ＳＡ：Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を確立する具体的な手順は、図５に示すとおりであり、以下のステップを含む。
　【００５６】
　ステップ５１：ユーザ装置は、ローカル・インターネット鍵交換（ＩＫＥ）ポリシーをストリームメディアサーバに送信する。
　【００５７】
　ステップ５２：ストリームメディアサーバは、ユーザ装置が使用するアルゴリズムを承認し、ローカルの一致するポリシーを検索し、ストリームメディアサーバによって承認されたポリシーをユーザ装置に対し、送信する。
　【００５８】
　ステップ５３Ａ及び５３Ｂ：相手側（すなわちストリームメディアサーバ）から承認されたポリシーを受け取ると、ユーザ装置は鍵生成のための情報をストリームメディアサーバへ配信し、ストリームメディアサーバ及びユーザ装置は、鍵生成のための情報を交換し、各々、鍵を生成する。
　【００５９】
　ステップ５４：ユーザ装置は、識別及び検証データをストリームメディアサーバに配信し、識別及び検証データは、権利オブジェクト（ＲＯ）に含まれた認証情報を含んでいる。ユーザ装置の識別を検証した後、そのストリームメディアサーバは自身の識別及び検証データをユーザ装置に対し、送信する。
　【００６０】
　ステップ５５：ユーザ装置及びストリームメディアサーバが識別検証及び交換手順検証を完了した後、第１段階のセキュリティ・アソシエーション（ＳＡ）が達成される。」
と記載されているものの、第【００４５】段落乃至第【００５８】段落の記載は、通常のＩＰＳｅｃ通信チャネルの確立手順となんら変わりはない。
　また、上記第【００５３】段落及び第【００５４】段落の記載によると、通常の第３ステップとして行われる認証では、「エンティティ・タイプ、ポート番号、プロトコルを含む認証」が行われ、本願におけるこの第３ステップの認証では、第【００５９】段落に記載のように、「識別及び検証データ」がストリームメディアサーバ及びユーザ装置の間で送受信され認証が行われており、この「識別及び検証データ」に「権利オブジェクト（ＲＯ）に含まれた認証情報」が含まれていると記載されているが、これは「識別及び検証データ」として上記「エンティティ・タイプ、ポート番号、プロトコル」に加えて、「権利オブジェクト（ＲＯ）に含まれた認証情報」が含まれているというものである。
　しかしながら、そもそもこの「権利オブジェクト（ＲＯ）に含まれた認証情報」は、メディアストリームの配信及び受信の正当な権利者であることを互いに確認するための情報であって、当該「認証情報」による識別検証はあくまでもオプションでしかなく、この処理を行わなくとも上記「エンティティ・タイプ、ポート番号、プロトコル」の認証によってＩＰＳｅｃ通信チャネルが確立されるのであり、この「認証情報」による識別検証の結果としてＩＰＳｅｃ通信が許可されるものであるとしても、この「認証情報」は直接“ＩＰＳｅｃ通信チャネルを確立するため”に使用されるものではないから、上記記載は不正確な記載である。
　また、請求項６、９、１２、１４、１６、１９についても同様の記載不備がある。
　よって、請求項１−２０に係る発明は明確でなく、また、発明の詳細な説明で裏付けされていないものでもある。
（２）審判請求人の主張について
　平成２６年６月２４日付けの意見書において、審判請求人は以下のように主張している。
「本願請求項１の発明では、権利オブジェクトが認証情報を含むことにより、権利オブジェクトが、「ユーザ装置及びストリームメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための認証情報」を伝達（carry）します。すなわち、請求項１の発明では、認証情報は、ユーザ装置（ＵＥ）とストリームメディアサーバとの間のＩＰＳｅｃ通信チャネルを確立するために使用されることができます。
　そのうえ、請求項１に記載されていますように、ＩＰＳｅｃ通信チャネルを確立するプロセスは、ＩＰＳｅｃの第１段階のセキュリティ・アソシエーションと、ＩＰＳｅｃの第２段階のセキュリティ・アソシエーションとを含みます。このＩＰＳｅｃの第１段階のセキュリティ・アソシエーションでは、ユーザ装置およびストリームメディアサーバの識別検証が行われており、この識別検証は、権利オブジェクト内に含まれた、ユーザ装置及びストリームメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための認証情報に基づいて行われています。
　したがいまして、認証情報は、ＩＰＳｅｃの第１段階のセキュリティ・アソシエーションにおいて使用されているといえます。この「ＩＰＳｅｃの第１段階のセキュリティ・アソシエーション」は、ＩＰＳｅｃ通信チャネルを確立するプロセスの１ステップですので、認証情報は、ＩＰＳｅｃ通信チャネルを確立するプロセスにおいて用いられているといえます。またこのことは、明細書のご指摘いただいた段落の記載からも理解されるものと思料いたします。
　したがいまして、請求項１の記載は正確かつ明確であり、かつ発明の詳細な説明に記載されているものと思料いたします。
　請求項６、９、１２、１４、１６、および１９についても、上記ご説明した請求項１と同様です。
　よって、請求項１〜２０に係る発明は、明確であり、かつ発明の詳細な説明で裏付けされているものであります。」
　しかしながら、審判請求人の上記主張は、「認証情報」がＩＰＳｅｃの第１段階のセキュリティ・アソシエーションにおいて使用されていることを根拠とするものであるが、上記（１）で示したように、この「認証情報」はあくまでもオプションとしてユーザ装置とストリームメディアサーバの識別検証に使用されるものであり、直接“ＩＰＳｅｃ通信チャネルを確立するため”に使用されるものではないから、上記主張を採用することはできない。
（３）まとめ
　以上のとおりであるから、請求項１−２０に係る発明は、明確でなく、また、発明の詳細な説明で裏付けされていないものでもあるから、特許法第３６条第６項第１号及び第２号に規定する要件を満たしていないものである。
　　
［２］特許法第２９条第２項について
（１）本願発明
　平成２４年７月２６日付けの手続補正により補正された特許請求の範囲の請求項６に係る発明（以下、「本願発明」という。）は以下のとおりである。
「【請求項６】
　ユーザ装置及びマルチメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための認証情報を含む権利オブジェクトを、前記マルチメディアサーバ及び権利発行装置が協議して生成するステップと、
　前記権利オブジェクトを受信すると、前記ユーザ装置が、前記権利オブジェクトに含まれた前記ユーザ装置及び前記マルチメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための前記認証情報を用いて、前記マルチメディアサーバとの間のＩＰＳｅｃ通信チャネルを確立するステップと、
　前記ＩＰＳｅｃ通信チャネルを介して、前記ユーザ装置に対し、前記マルチメディアサーバが、メディアデータを送信するステップと
を含み、
　前記ＩＰＳｅｃ通信チャネルを確立する前記ステップが、
　ＩＰＳｅｃの第１段階のセキュリティ・アソシエーション及びＩＰＳｅｃの第２段階のセキュリティ・アソシエーションを、前記ユーザ装置と前記マルチメディアサーバとが協議して確立するステップを含み、
　ＩＰＳｅｃの前記第１段階のセキュリティ・アソシエーションを確立する際、前記権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報が、前記ユーザ装置及び前記マルチメディアサーバの識別検証に用いられることを特徴とするディジタル著作権保護方法。」
（２）引用例
（２−１）当審の拒絶の理由に引用された、「山本修一郎　外１名、２階層ＰＫＩ技術によるサービス利用権認証、ＣＯＭＰＵＴＥＲ＆ＮＥＴＷＯＲＫ　ＬＡＮ、株式会社オーム社、２００４年９月１日、第２２巻、第９号、ｐ．４３−４７」（以下、「引用例１」という。）には、図面とともに、次の事項が記載されている。
（ａ）「ｅ−Ｋｅｙチップは耐タンパ性を有し、２階層ＰＫＩ技術を実装しているＩＣチップであり、情報流通機器に組み込むことを想定している。機器管理者はｅ−Ｋｅｙチップに対して各種サービスの設定を行い、利用権管理者はサービスに対応した利用権を配送管理する。そしてサービス提供者は、利用権を用いた各種サービスを提供する。
　２階層ＰＫＩ技術は、１階層目のＰＫＩを利用して、カード発行後でも自由にアプリケーションを発行設定し、各アプリケーションが独自に２階層目のＰＫＩを利用してサービスが提供できるなど、サービス間のセキュリティを保ちながら幅広いサービスの提供が可能な技術である（図２）。」（第４３頁右欄第７行−１７行）
（ｂ）図１には「Ｓｅｃｕｒｅ　ｅ−Ｋｅｙ　Ｎｅｔｗｏｒｋの概念」が図示されており、耐タンパ性をもち、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」、個々のサービスに対応した鍵などの「利用権」を機器に配送する「利用権管理者」、及び、利用権の鍵を利用して通信などのサービスを提供する「サービス提供者」がインターネットで接続されることが示されている。（第４４頁）
（ｃ）図４には「Ｓｅｃｕｒｅ　ｅ−Ｋｅｙ　Ｎｅｔｗｏｒｋのフレームワーク（プレイヤ・モデル）」が図示されており、ここでは「サービス利用者」から「利用権管理者」に利用権設定依頼がされると、「利用権管理者」は「サービス提供者」に利用権設定依頼を行い、「利用権管理者」から利用権の設定が行われ、「サービス利用者」は「サービス提供者」にサービス提供依頼を行い、「サービス提供者」はサービスの提供を行うことが示されている。（第４５頁）
（ｄ）図５には「ｅ−Ｋｅｙチップによる利用権管理イメージ」が図示されており、ｅ−Ｋｅｙチップ内の利用権管理アプリケーションに各種利用権が格納されることが示されている。（第４５頁）
（ｅ）「Ｓｅｃｕｒｅ　ｅ−Ｋｅｙ　Ｎｅｔｗｏｒｋの技術検証として、以下の４つのサービスを構築し、構成可能であることを確認した。
『１』ＩＰｓｅｃによる通信鍵を利用権として配布することによる暗号通信の実現
 ・・・（中略）・・・ 
『３』デジタル・コンテンツ閲覧用の鍵を利用権として配布し、パソコンによるコンテンツ視聴の実現」（第４５頁右欄第３２行−第３９行、なお『１』及び『３』は丸付き数字である。） 
（ｆ）「【３】デジタル・コンテンツ流通 
 ・・・（中略）・・・ 
　そこで、Ｓｅｃｕｒｅ　ｅ−Ｋｅｙ　Ｎｅｔｗｏｒｋによって、コンテンツ保護を利用権認証で実現することにより、共通のデジタル・コンテンツ流通基盤のもとで、複数のコンテンツ提供者がサービス提供を行い、利用者はコンテンツ・プロバイダやメーカーを問わず、共通のコンテンツ流通基盤のもとでコンテンツを利用することが可能となる。」（第４６頁右欄第１７行−第３１行） 
 　　 
　ここで、上記（ｂ）及び（ｃ）における「利用権管理者」及び「サービス提供者」は、インターネットに接続され、また、利用権の設定処理やデジタル・コンテンツの配信処理を行うことから、これらは実質的にコンピュータを使用した装置であると認められる。
　そうすると、上記（ａ）乃至（ｆ）の記載から、引用例１には次の発明（以下、「引用発明」という）が記載されている。 
「ｅ−Ｋｅｙチップが組み込まれた情報流通機器と、個々のサービスに対応した鍵などの利用権を機器に配送する利用権管理者装置、及び、利用権の鍵を利用してサービスを提供するサービス提供者装置がインターネットで接続され、サービス利用者が前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器から、前記利用権管理者装置に利用権設定依頼を行うと、前記利用権管理者装置は前記サービス提供者装置に利用権設定依頼を行い、前記利用権管理者装置はその結果として利用権を前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器に配送し、前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器では配送された利用権をｅ−Ｋｅｙチップ内に格納するものであり、前記サービス提供者装置は、前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器から送付される利用権を認証することによりコンテンツの視聴を許可する方法。」 
（２−２）当審の拒絶の理由に引用された、特開２００４−２６６７９０号公報（以下、「引用例２」という。）には、図面とともに、次の事項が記載されている。
（ｇ）「【請求項６】
請求項１のシステムにて保管されたデジタルビデオ映像コンテンツを、同じく請求項１で示した高速アクセス回線経由にて視聴する際に、よりセキュリティ性を高めるためにＩＰＳｅｃ（ＩＰ　Ｓｅｃｕｒｉｔｙ）機能などによるデータの暗号化、またはＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）などによるネットワーク上での閉域グループ化を行えることを特徴とする請求項１記載のアーカイブコンテンツ視聴システム。」
（２−３）当審の拒絶の理由に周知例として引用された、「山田英史、ＩＰＳｅｃによる異機種混在環境のＶＰＮ構築法(前編)、ＳｏｆｔｗａｒｅＤｅｓｉｇｎ、株式会社技術評論社、２０００年７月１８日、第１１７号、ｐ．２００−２０３」（以下、「引用例３」という。）には、図面とともに、次の事項が記載されている。
（ｈ）「『１』ＩＫＥパラメータの調整
　ＩＰＳｅｃはＳＡ（Security Association）というセキュアな仮想トンネルをＩＰＳｅｃ製品間で構築しますが、ＳＡを確立するためにＩＫＥ（Internet Key Exchange）という手順で各種アルゴリズムのネゴや鍵の交換を行います。図２の通り、すべてのＳＡの土台になるトンネルをＩＰＳｅｃ製品間で確立するためのＩＫＥフェーズ１と、実際に暗号化通信を行うホスト間（またはサブネット間）にトンネルを確立するためのＩＫＥフェーズ２という２段階のプロセスが実行されます。表１の通り各フェーズに設定するパラメータにはさまざまなものがあり、通信を行うＩＰＳｅｃ製品間で相互に使用可能な値を確認し設定します。基本的には使用するアルゴリズムなどはＩＫＥセッションの中で自動的にネゴして決定することになっていますが、ネゴを円滑に進めさせるために通信者双方で事前に申し合わせて決定しておいた方が良いようです。」（第２００頁右欄第４行−第２０１頁左欄第５行、なお『１』は丸付き数字である。）
（ｊ）「図2-1　IKEフェーズ１」では、「Initiator」と「Responder」との間で、以下のような手順が行われることが示されている。
　Initiator　　　　　　　　　　　　　　　　　　　　　　　Responder
　各種アルゴリズムの提案　→
　　　　　　　　　　　　　　　　　　　　←　各種アルゴリズムの選択
　DHによる鍵交換　→　
　　　　　　　　　　　　　　　　　　　　　　　　←　DHによる鍵交換
　認証　→
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　←　認証
  　　　　　　　　　　　　　　↓
　　　　　フェーズ２のための安全なトンネルを確立
（ｋ）「図2-2　IKEフェーズ２」では、「Initiator」と「Responder」との間で、以下のような手順が行われることが示されている。
　Initiator　　　　　　　　　　　　　　　　　　　　　　　Responder
　各種アルゴリズムの提案とDHによる鍵交換　→
　　　　　　　　　　　　←　各種アルゴリズムの選択とDHによる鍵交換
　接続了承　→　
 　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　SA確立
（ｌ）「表１」には各フェーズで設定されるパラメータとして、「IKEフェーズ１」では、「フェーズ１モード」、「暗号アルゴリズム」、「ハッシュアルゴリズム」、「DHグループ」、「認証用IDタイプ」、「Key Life Time」が、また、「IKEフェーズ２」では、「フェーズ２モード」、「トランスフォーム　ペイロード」、「PFS」、「Key Life Time」が記載されている。
   　
（３）対比
　そこで、本願発明と引用発明とを比較する。
（ア）引用発明の「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」は、ユーザが使用し、利用権に基づいてコンテンツの視聴が許可されるものであることから、本願発明の「ユーザ装置」に対応するものである。
　また、引用発明の「利用権管理者装置」は、利用権の設定や配送を行うものであることから、本願発明の「権利発行装置」に対応するものである。
　また、引用発明の「サービス提供者装置」は、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」に対して利用権の認証に基づくコンテンツの提供を行うものであり、コンテンツは一般に音楽、写真、動画などのいわゆるマルチメディアであることから、本願発明の「マルチメディアサーバ」に対応するものである。
（イ）引用発明の「サービス利用者が前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器から、前記利用権管理者装置に利用権設定依頼を行うと、前記利用権管理者装置は前記サービス提供者装置に利用権設定依頼を行い、前記利用権管理者装置はその結果として利用権を前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器に配送し」によれば、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」からの依頼に応じて、「利用権管理者装置」と「サービス提供者装置」とのやり取り、つまり協議によって「利用権」を生成するものである。
　また、この「利用権」は、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」と「サービス提供者装置」との間での認証に使用される情報であって、これもコンテンツの視聴のための権利オブジェクトといえる。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「ユーザ装置及びマルチメディアサーバ間の認証情報を含む権利オブジェクトを、前記マルチメディアサーバ及び権利発行装置が協議して生成するステップ」
を備える点で共通している。
（ウ）引用発明の「前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器では配送された利用権をｅ−Ｋｅｙチップ内に格納するものであり、前記サービス提供者装置は、前記ｅ−Ｋｅｙチップが組み込まれた情報流通機器から送付される利用権を認証することによりコンテンツの視聴を許可する」によると、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」は、配送された「利用権」をｅ−Ｋｅｙチップ内に格納し、「サービス提供者装置」は、「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」から送付される「利用権」を認証することによりコンテンツの視聴を許可する、すなわちコンテンツを送信するものである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「前記権利オブジェクトを受信すると、前記ユーザ装置が、前記認証情報を用いて、前記マルチメディアサーバとの間で認証を行うステップと、
　前記ユーザ装置に対し、前記マルチメディアサーバが、メディアデータを送信するステップ」
を備える点で共通している。
（エ）引用発明の方法は、利用権に基づくコンテンツの保護を行うものであり、これもディジタル著作権を保護するためのものであることは明らかである。
　そうすると、本願発明と引用発明は、後記する点で相違するものの、
「ディジタル著作権保護方法」
である点で共通している。
（オ）以上の（ア）乃至（エ）から、本願発明と引用発明は、
「ユーザ装置及びマルチメディアサーバ間の認証情報を含む権利オブジェクトを、前記マルチメディアサーバ及び権利発行装置が協議して生成するステップと、
　前記権利オブジェクトを受信すると、前記ユーザ装置が、前記認証情報を用いて、前記マルチメディアサーバとの間で認証を行うステップと、
　前記ユーザ装置に対し、前記マルチメディアサーバが、メディアデータを送信するステップ、
　からなるディジタル著作権保護方法。」
である点で一致し、以下の点で相違している。
　
［相違点１］
　本願発明の「認証情報」は、「ユーザ装置及びマルチメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための」ものであるのに対し、引用発明ではそのようになっていない点。
　　
［相違点２］
　本願発明では、「前記権利オブジェクトを受信すると、前記ユーザ装置が、前記権利オブジェクトに含まれた前記ユーザ装置及び前記マルチメディアサーバ間のＩＰＳｅｃ通信チャネルを確立するための前記認証情報を用いて、前記マルチメディアサーバとの間のＩＰＳｅｃ通信チャネルを確立するステップ」により確立した「ＩＰＳｅｃ通信チャネルを介して」、ユーザ装置に対しメディアデータを送信するものであるのに対し、引用発明ではそのようになっていない点。
　　
［相違点３］
　本願発明では、「前記ＩＰＳｅｃ通信チャネルを確立する前記ステップが、ＩＰＳｅｃの第１段階のセキュリティ・アソシエーション及びＩＰＳｅｃの第２段階のセキュリティ・アソシエーションを、前記ユーザ装置と前記マルチメディアサーバとが協議して確立するステップを含み、ＩＰＳｅｃの前記第１段階のセキュリティ・アソシエーションを確立する際、前記権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報が、前記ユーザ装置及び前記マルチメディアサーバの識別検証に用いられる」ものであるのに対し、引用発明ではそのようになっていない点。
　　
（４）当審の判断
　上記［相違点１］、［相違点２］及び［相違点３］は、本願発明が「ユーザ装置」と「マルチメディアサーバ」との間で「ＩＰＳｅｃ通信チャネル」を確立する点に起因するものであるのでまとめて判断する。
　本願発明の課題は、明細書に「【００１６】先行技術では、メディアストリームの復号化は、ユーザ装置のアプリケーション層で行われる。この場合、ユーザ装置の設備に対する要求が高く、その結果、ユーザ装置の付加的なコストが嵩むこととなる。」及び「【００１７】更に、モバイルＴＶ及びファイルダウンロードなどのマルチメディアサービスを行う場合にも、先行技術によるディジタル著作権保護方法及びシステムは、ユーザ装置について高い要求があり、その結果、ユーザ装置の付加的なコストが嵩むことがある。」と記載しているように、メディアストリームなどの復号化処理のためにユーザ装置の付加的なコストが嵩むことである。
　そして、この課題に対し、ユーザ装置とマルチメディアサーバとの間の通信にＩＰＳｅｃを採用し、メディアストリームをＩＰＳｅｃによる暗号化通信により送信することにより解決しようとするものである。
　これに対し、引用発明でも上記（２−１）（ａ）の記載によれば、ＰＫＩを利用してセキュリティを保ちながらサービスの提供が行われるものであり、一般にコンテンツを通信ネットワークで送信する際の暗号化は周知の課題である。
　そして、引用例２の上記（２−２）（ｇ）には、デジタルビデオ映像コンテンツを高速アクセス回線経由にて視聴する際に、よりセキュリティ性を高めるためにＩＰＳｅｃ（ＩＰ　Ｓｅｃｕｒｉｔｙ）機能によるデータの暗号化を採用することが記載されており、また、ＩＰＳｅｃのＩＫＥフェーズ１及びＩＫＥフェーズ２という２段階のセキュリティ・アソシエーションの確立手順は、例えば引用例３の上記（２−３）（ｈ）乃至（ｌ）に記載されているように周知の技術である。
　そうすると、引用発明において、利用権の認証後の「サービス提供者装置」から「ｅ−Ｋｅｙチップが組み込まれた情報流通機器」へのコンテンツの送信時に、セキュリティ性を高めるために引用例２のＩＰＳｅｃによる暗号化を適用することは、当業者であれば容易に想到し得たことである。
　また、上記［相違点３］の「ＩＰＳｅｃの前記第１段階のセキュリティ・アソシエーションを確立する際、前記権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報が、前記ユーザ装置及び前記マルチメディアサーバの識別検証に用いられる」点について、この「権利オブジェクトに含まれたＩＰＳｅｃ通信を確立するための前記認証情報」に基づく識別検証によって認証されなければ、その時点で処理は中止されるのであるから、引用発明の利用権の認証と機能的に変わりはない。また、利用権の認証タイミングについて、一般には利用権の認証後にＩＰＳｅｃ通信チャネルの確立を行うのが普通と考えられるものの、コンテンツの配信実行前であればＩＰＳｅｃ通信チャネルの確立手順の途中であっても、確立後であっても可能（無駄な手順が生じるが）であることは技術常識からして明らかであり、また、本願においても「【００６１】本発明の実施の形態に係る方法の代替の実施は、以下のステップを含むことができる。」及び「【００６２】ステップ４４において、ユーザ装置のための著作権利用承認情報は、ストリームメディアサーバ及び権利発行装置が協議して生成した権利オブジェクト（ＲＯ）に備えられている。ステップ４７において、ユーザ装置は、ストリームメディアサーバにコンテンツのダウンロードのリクエストをするときは、著作権利用承認情報を含んでいる権利オブジェクト（ＲＯ）をストリームメディアサーバに提供し、ストリームメディアサーバは、著作権利用承認情報を認証し、認証がパスしたときは、ストリームメディアサーバ及びユーザ装置は、セキュリティ・アソシエーション（ＳＡ）を協議し、ＩＰＳｅｃ通信チャネルを確立する。ＳＡ協議及びＩＰＳｅｃ通信の確立の手順は、先行技術を利用して実行され得るので、ここではこれ以上説明しない。」と記載しているように、認証を行った後にＩＰＳｅｃ通信チャネルの確立処理を行うことを想定していることからも、利用権の認証をＩＰＳｅｃ通信チャネルの確立の際のどのタイミングで行うこととしても、それは当業者が適宜なし得ることであり、この点に進歩性があるものではない。
　したがって、上記［相違点１］、［相違点２］及び［相違点３］に係る構成はいずれも格別なものとはいえず、本願発明は当業者が引用発明、引用例２及び周知技術から容易に想到し得たものである。
　　
（５）まとめ
　以上のとおりであるから、本願発明は、引用発明、引用例２及び周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものである。
　そして、本願発明の作用効果も、引用発明、引用例２及び周知技術から当業者が予測できる範囲のものである。
　　
４．むすび
　以上のとおり、請求項１−２０に係る発明は、明確でなく、また、発明の詳細な説明で裏付けされていないものでもあるから、特許法第３６条第６項第１号及び第２号に規定する要件を満たしていないものであり、また、請求項６に係る発明は引用発明、引用例２及び周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものでもあるから、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　　　
　よって、結論のとおり審決する。