【事件の表示】
　特願２００７−５３２４７７「デジタルコンテンツへの認可されたアクセスを提供するためのシステム及び方法」拒絶査定不服審判事件〔平成１８年　３月３０日国際公開，ＷＯ２００６／０３３９９７，平成２０年　５月　１日国内公表，特表２００８−５１４１２３〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００５年９月１６日（パリ条約による優先権主張外国庁受理２００４年９月１６日　アメリカ合衆国）を国際出願日とする出願であって，
　平成１９年３月２７日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，平成２２年２月１６日付けで審査官により拒絶理由が通知され，これに対して平成２２年８月２３日付けで意見書が提出されると共に手続補正がなされ，平成２２年１２月１６日付けで審査官により拒絶理由が通知され，これに対して平成２３年６月２１日付けで意見書が提出されると共に手続補正がなされたが，平成２３年７月２０日付けで審査官により拒絶査定がなされ（謄本送達　平成２３年７月２６日），これに対して平成２３年１１月２８日付けで審判請求がなされると共に手続補正がなされたので，特許法第１６２条の規定により前置審査に付され，平成２４年３月９日付けで審査官により最後の拒絶理由が通知され，これに対して平成２４年９月１３日付けで意見書が提出され，平成２４年１１月２６日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２５年１月２４日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２５年７月２９日付けで回答書の提出があったものである。
　
第２．本願発明について
　本願に係る発明は，平成２３年１１月２８日付けの手続補正により補正された特許請求の範囲の請求項１〜請求項１４に記載された次の事項により特定されるものである。
　
「　【請求項１】
　サーバおよび該サーバと通信を行うデバイスを含むシステムにおいて，デバイスの受信するコンテンツへのアクセスを認可するように該システムを動作させるための方法において，
　サーバがデバイスに公開鍵，秘密鍵及び関連するデジタル証明書を提供する工程と，
　サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対しユニークであるデバイスユニット鍵を提供する工程であって，デバイスユニット鍵は公開鍵によって暗号化され，秘密鍵によって解読される，前記工程と，
　サーバが対称鍵アルゴリズムを用いてデバイスに１つ以上のサービス鍵を提供する工程であって，該１つ以上のサービス鍵はデバイスユニット鍵によって暗号化および認証される，前記工程と，
　サーバが対称鍵アルゴリズムを用いてデバイスに１つ以上の番組鍵を提供する工程であって，該１つ以上の番組鍵は第１のタイプのコンテンツアクセス及び別の第２のタイプのコンテンツアクセスを解読するために用いられる，前記工程と，を備え，
　第１のタイプのコンテンツアクセスはコンテンツペイパービューイベント用であり，第２のタイプのコンテンツアクセスはコンテンツ加入サービス用であり，
　デバイスユニット鍵によって，第１のタイプのコンテンツアクセスを解読するために用いる前記１つ以上の番組鍵の暗号化及び認証が行われ，前記１つ以上のサービス鍵によって，第２のタイプのコンテンツアクセスを解読するために用いる前記１つ以上の番組鍵の暗号化及び認証が行われる，方法。
　　【請求項２】
　デバイスユニット鍵は，
　サーバが前記１つ以上のサービス鍵若しくは前記１つ以上の番組鍵の暗号化を行うために用いる第１の対称鍵，又は，
　サーバが前記１つ以上のサービス鍵若しくは前記１つ以上の番組鍵の認証を行うために用いる第２の対称鍵，を含む請求項１に記載の方法。
　　【請求項３】
　デバイスユニット鍵は所定の周期で更新される請求項１に記載の方法。
　　【請求項４】
　前記１つ以上のサービス鍵は複数のサービス鍵を含むことと，前記１つ以上の番組鍵は複数の番組鍵を含むことと，前記複数のサービス鍵の各々は前記複数の番組鍵の各々に対しユニークであり，サーバが前記複数の番組鍵の各々の解読を行うために用いられることと，を含む請求項１に記載の方法。
　　【請求項５】
　前記１つ以上のサービス鍵は，
　サーバが前記１つ以上の番組鍵の暗号化を行うために用いる第１の対称鍵と，
　サーバが前記１つ以上の番組鍵の認証を行うために用いる第２の対称鍵と，を含む請求項１に記載の方法。
　　【請求項６】
　前記１つ以上のサービス鍵は所定の周期で更新される請求項５に記載の方法。
　　【請求項７】
　サーバがデバイスに，前記１つ以上の番組鍵と第２のタイプのコンテンツアクセスによる情報との組合せから導出され，デバイスがコンテンツを解読するために用いられるコンテンツ解読鍵を提供する工程，を含む請求項１に記載の方法。
　　【請求項８】
　公開鍵，秘密鍵及び関連するデジタル証明書，デバイスユニット鍵，サービス鍵，番組鍵，並びにコンテンツ解読鍵は，コンテンツを受信するためにデバイスによってアクセス可能なスマートカード及びコンピュータ可読媒体のうちの一方において符号化されている請求項１に記載の方法。
　　【請求項９】
　サーバおよび該サーバと通信を行うデバイスを含むシステムにおいて，デバイスの受信するコンテンツへの認可されたアクセスを提供するように該システムを動作させるための方法において，
　サーバがデバイスからコンテンツアクセスの要求を受信する要求受信工程と，
　要求に応答して，サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程と，
　サーバがデバイスに資格管理メッセージ（ＥＭＭ）を提供する管理メッセージ提供工程であって，
　　ａ）サーバがデバイスに対しユニークであるデバイスユニット鍵を公開暗号鍵によって暗号化するデバイスユニット鍵暗号化工程と，
　　ｂ）サーバが，デバイスが番組鍵の解読を行うために用いられるサービス鍵を少なくともデバイスユニット鍵によって暗号化するサービス鍵暗号化工程と，を含む，前記工程と，
　サーバがデバイスに第１のタイプのコンテンツアクセス又は別の第２のタイプのコンテンツアクセスの資格制御メッセージ（ＥＣＭ）を提供する制御メッセージ提供工程であって，
　　ａ）サーバが，デバイスによる第１のタイプのコンテンツアクセス又は第２のタイプのコンテンツアクセスの解読のためにＥＣＭに番組鍵を提供する番組鍵提供工程と，
　　ｂ）サーバが第１のタイプのコンテンツアクセス用のサービス鍵によってＥＣＭを暗号化する第１ＥＣＭ暗号化工程と，
　　ｃ）サーバが第２のタイプのコンテンツアクセス用のデバイスユニット鍵によってＥＣＭを暗号化する第２ＥＣＭ暗号化工程と，を含む，前記工程と，からなり，
　第１のタイプのコンテンツアクセスはコンテンツ加入サービスタイプであり，第２のタイプのコンテンツアクセスはコンテンツペイパービューイベントタイプである，方法。
　　【請求項１０】
　第１ＥＣＭ暗号化工程はサーバがサービス鍵によって番組鍵を暗号化する工程を含み，
　第２ＥＣＭ暗号化工程はサーバがデバイスユニット鍵によって番組鍵を暗号化する工程を含む，請求項９に記載の方法。
　　【請求項１１】
　管理メッセージ提供工程は，サーバが，デバイスがサービス鍵の失効時に第１のタイプのコンテンツアクセスの解読を行うために用いる別のサービス鍵を少なくともデバイスユニット鍵によって暗号化する工程を含み，ＥＭＭはサービス鍵及び別のサービス鍵を含む，請求項９に記載の方法。
　　【請求項１２】
　サーバが定期的に管理メッセージ提供工程を反復し，さらなるＥＭＭを生成する工程を含み，各ＥＭＭは各ＥＭＭの生成の順序に基づき最初から最後へ順次値の増大する鍵識別子を含む，請求項９に記載の方法。
　　【請求項１３】
　制御メッセージ提供工程は，
　デバイスが番組鍵を用いて第２のタイプのコンテンツアクセスのコンテンツを解読したとき，サーバがデバイスに，同コンテンツがデバイスに記憶される期間の長さを指定する第１のアクセス規則を提供する工程を含む請求項９に記載の方法。
　　【請求項１４】
　デバイスは，非対称鍵ペアへのアクセスを有し，かつ，コンテンツへのアクセスを提供する受信機を含む請求項９に記載の方法。」
　
第３．原審の拒絶理由
　平成２４年３月９日付けの拒絶理由（以下，これを「前置拒絶理由」という）は，概略，次のとおりである。
　
「　　　　　　　　　　　　　　理　由
　
　この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　
平成23年11月28日付手続補正により補正された請求項記載の発明について，以下の点で当業者が実施可能に発明を開示していない，ないしは技術的意義が把握できない。
　
（１）「デバイス秘密鍵をサーバから提供する」ことについて：
本願明細書段落０００９−００１１の記載ぶりでは，「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか不明である。
仮に，サーバから送られるデバイス秘密鍵を安全に取得するために，端末に固定的な鍵を用いる，このような固定的な鍵は受信機にユニークなデバイスユニット鍵と同じように用いてよいため，本願のようにわざわざデバイスユニット鍵をサーバから送るようにした（可変な鍵にした）ことの技術的意義も，本願のようなデバイス秘密鍵→デバイスユニット鍵→サービス鍵→番組鍵→コンテンツ鍵のような鍵階層（左から右に行くに従い，上位階層の鍵となる）を用いることの技術的意義も不明である。
この点について，平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点1に対する回答では，実質的に回答がなされていない。
当該事項は，本願発明と，本願出願人によって出願され本願優先権主張日前に公開された引用例１記載の発明との差別化を図る事項であるものと思慮され，上記事項を削除してしまったのでは引用例１記載のものとの差異がないとの心証がある。
　
（２）「デバイス秘密鍵を送るための対称鍵，非対称鍵」について：
（１）とも関連するが，デバイス秘密鍵を送るための構成が不明であり，当業者が実施可能な程度に発明を開示していないといえる。また，「対称鍵」「非対称鍵」いずれも公開鍵暗号系を用いているものと思われるが，「対称鍵」「非対称鍵」の技術的定義が不明であることとも関連し，デバイス秘密鍵を送るための構成について技術的意義が理解しがたい。
（平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点3に対する回答を踏まえ，請求項記載のものに対し適切な定義を与え，明細書中の記載についても技術的に一貫する釈明をされたい。）
　
（３）「デバイスユニット鍵をサーバから提供する」ことについて：
これも（１）とも関連するが，本来「デバイス固有の鍵」であり固定的であった「デバイスユニット鍵」を（書き換え可能とするために）サーバから送信するための構成について，「サーバからデバイスに秘密鍵を提供し」，「この秘密鍵を用いてサーバから送られるデバイスユニット鍵を復号する」ものと思われるが，この説明が技術的に正しくなされていない。
（平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点１及び平成24年3月1日付け回答においては，実質的に何の回答もして
いない。さらに，平成24年3月1日付け回答はデバイスユニット鍵に関して，請求項と関係ない回答をしているため，当該回答の意図すらも不明である。）
また，「対称鍵アルゴリズム」というのは，公開鍵暗号系のことを定義したいのか，共有鍵暗号系のことを定義したいのか，技術的に意味不明である。
　
（４）省略」
　
第４．当審の判断
１．（１）について
　上記「第２．本願発明について」において引用した，平成２３年１１月２８日付けの手続補正により補正された請求項（以下，「本願の請求項」という）１に記載された，
「サーバがデバイスに公開鍵，秘密鍵及び関連するデジタル証明書を提供する工程」，
　及び，本願の請求項９に記載された，
「要求に応答して，サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程」，
　に関して，本願明細書の発明の詳細な説明には，その段落【０００９】に，
　
「図２を参照すると，
各受信機はユニークな公開鍵／秘密鍵ペアを所有し
　
　と記載されて，同じく，本願明細書の段落【００２５】に，
　
「４２０にて，一実施形態では，登録の一環として，
ユーザはサービスプロバイダから受信機を獲得する。この受信機は，ユーザとサービスプロバイダとの間で登録が行われる前に，例えば，製造設備において予めインストールされたユニークな公開鍵／秘密鍵ペア，及びデジタル証明書を備える
公開鍵／秘密鍵ペア，及び対応するデジタル証明書１１５は，受信機内に実装され
別の実施形態では，サービスプロバイダは，記憶されている情報へのアクセスがユーザの受信機に与えられるように，公開鍵／秘密鍵ペア，及びデジタル証明書が記憶されているスマートカード又はＣＲＭのユーザへ，物理的な配布を行う
別の実施形態では，サービスプロバイダは，陸線データネットワーク（インターネットなど），無線データネットワーク（セルラーネットワークなど），又は陸線データネットワークと無線データネットワークとの組合せを介して，ユーザの受信機の中に（例えば，メモリ３６０の中に）遠隔的にインストールすることによって，公開鍵／秘密鍵ペア及びデジタル証明書を提供する
　
　と記載されていて，上記引用の段落【０００９】に記載された，特に下線を附した部分の内容に従えば，本願明細書の発明の詳細な説明においては，「各受信機」，即ち，本願の請求項１，及び，請求項９における「デバイス」は，予め，「ユニークな公開鍵／秘密鍵ペア」を有していることになり，また，上記引用の段落【００２５】には，「ユーザの受信機」に「公開鍵／秘密鍵ペア」を配布する態様として，
　１．サービスプロバイダによって，製造装置において予め受信機にインストールする。
　２．サービスプロバイダが，ユーザに対して，公開鍵／秘密鍵ペアが記憶されているＣＲＭのユーザに，物理的な配布を行う。
　３．サービスプロバイダが，陸線データネットワーク（インターネットなど），無線データネットワーク（セルラーネットワークなど），又は陸線データネットワークとの組合せを介して，ユーザの受信機の中に（例えばメモリ３６０の中に）遠隔的にインストールする。
　点が挙げられている。しかしながら，段落【０００９】に記載の内容は，本願の請求項１に係る発明における，
「サーバがデバイスに公開鍵，秘密鍵及び関連するデジタル証明書を提供する工程」，
　及び，請求項９に係る発明における，
「要求に応答して，サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程」，
　ではないことは，明らかであり，段落【００２５】に記載された，各態様も，「サービスプロバイダ」によって行われるものであって，特に，段落【００２５】に記載の，態様の１と，態様の２は，
“サービスプロバイダを運営する人による，作業工程，或いは，サービス提供のための手順”
　であって，“人の作業工程”とも解せるものであるから，サーバによって行われるものでないことは，明らかである。
　ここで，段落【００２５】に記載された，態様の３は，概略，
“サービスプロバイダが，「公開鍵／秘密鍵ペア」を，通信路を介して受信機に送信する”
　というものであるから，これを，
“サービスプロバイダが，サーバを用いて，「公開鍵／秘密鍵ペア」を，通信路を介して受信機に送信する”
　と解した場合は，一応，装置による作業工程と解せるものであるが，前置拒絶理由で指摘したように，態様の３において，どのようにして，安全に，「サービスプロバイダ」が，「受信機」に対して，“通信路”を介した「公開鍵／秘密鍵ペア」の「遠隔的にインストールする」ことを実現しているか，段落【００２５】，及び，本願明細書，及び，図面の他の記載を全て参酌しても不明である。
　以上のとおりであるから，本願明細書の発明の詳細な説明に記載された内容からは，
“「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか”
　は不明である。
　
　この点について，審判請求人は，平成２４年９月１３日付けの意見書（以下，これを「意見書」という）において，
「「デバイス秘密鍵」がどのようにして各デバイスにインストールされるかについては，本発明の範囲ではありません。「サーバ」が各デバイスに送るのは他の種類の鍵であり，「デバイス秘密鍵」ではありません。
・・・・（中略）・・・・
本願発明は，“「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか”について何ら定義を行うものではないので，その態様を明らかにすることはできません。」
　と述べるに止まるが，
　本願の請求項１，及び，請求項９に係る発明においては，上記でも引用したとおり，
「
サーバ
　及び，
「
サーバ
　と明記されているので，審判請求人の，前記引用の意見書における主張は採用できない。
　また，当審の平成２５年１月２４日付けの審尋に対する，平成２５年７月２９日付けの回答書（以下，これを「回答書」という）においては，上記の不明点に対して，何らの説明もしていないので，審判請求人による意見書，及び，回答書の内容を加味しても，上記指摘の不明点は解消しない。
　
　さらに，上記引用の意見書の主張について，
　本願発明の目的は，本願明細書の段落【０００５】に記載されているように，
「デジタル権利管理（ＤＲＭ）アーキテクチャ用のセキュリティを最大化しながら，帯域幅使用を最小限に抑えるための複数のレベルの鍵管理を含む，ＤＲＭアーキテクチャ用の暗号鍵管理のアプローチを提供する」，
　ということである。そして，「公開鍵／秘密鍵ペア」の「秘密鍵」は，本願の請求項１，及び，請求項９に係る発明における「デバイスユニット鍵」を暗号化して，「デバイス」に提供するために用いられるものであるから，該「秘密鍵」が安全に「デバイス」に提供できないのであれば，第３者によって，該「秘密鍵」が取得され，該「秘密鍵」によって，暗号化された「デバイスユニット鍵」を，第３者が取得することが可能となるので，「サービス鍵」，「番組鍵」も同様に，第３者が取得可能となり，結果，本願における目的は，全く達成されないことになる。
　即ち，本願の“鍵配信のプロトコル”は，最初の，「サーバ」が，「公開鍵／秘密鍵ペア」を，安全に提供する点から始まるものである。
　その点が，発明の詳細な説明に明確に記載されていない以上，本願明細書の発明の発明の詳細な説明は，本願の目的を実現するための構成が開示されているとは認められず，
　結果として，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものとは言えない。
　
２．（２），及び，（３）について
　本願の請求項１に記載された，
「サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対するユニークであるデバイスユニット鍵を提供する工程であって，デバイスユニット鍵は公開鍵によって暗号化され，秘密鍵によって解読される，前記工程と」，
　に関して，上記引用の本願の請求項１の記載から，本願の請求項１に係る発明においては，「サーバ」から，「デバイス」に，「デバイスユニット鍵」を提供する工程には，「対称鍵アルゴリズム」が用いられていることになる。
　ここで，「対称鍵アルゴリズム」とは，
“送信側と，受信側が，同一の鍵を，暗号鍵，復号鍵として用い，送信側が，該暗号鍵で，情報を暗号化して，受信側に送り，受信側は，該復号鍵を用いて，暗号化された情報を復号する”
　というアルゴリズムを意味することは，当業者にとって周知の技術事項である。
　この点に関して，本願明細書の発明の詳細な説明には，その段落【００１２】に，
　
「このサービスプロバイダは，デバイスユニット鍵２２０や，デバイス資格及び他の構成データを，ユーザの受信機へ配信する。
デバイスユニット鍵２２０は，配信に先立って，公開鍵／秘密鍵ペアからの公開鍵で暗号化されており，受信機によって受信されると，公開鍵／秘密鍵ペアからのデバイス秘密鍵２１０によって解読される
　
　と記載され，更に，段落【００２６】に，
　
「４３０にて，やはり登録の一環として，サービスプロバイダはユーザの受信機に関するユニークなデバイスユニット鍵２２０（図２），また随意では，デバイス構成データや，特定のコンテンツアクセスサービスを指定しない一般的な資格をユーザに提供する（例えば，メモリ３２０又はメモリ３６０に記憶）。上述のように，
デバイスユニット鍵２２０は公開鍵で暗号化されて配信され，受信機のユニークな公開鍵／秘密鍵ペアの対応する秘密鍵によって受信機内部で解読される
　
　と記載されていて，上記引用の段落【００１２】，及び，段落【００２６】に記載された内容から，「デバイスユニット鍵」は，「ユーザ」に提供される際，「受信機のユニークな公開鍵」で暗号化され，「受信機」において，「受信機のユニークな秘密鍵」で復号される点は記載されているが，これは，“公開鍵暗号系”の処理であるから，この処理が，「対称鍵アルゴリズム」，或いは，「対称鍵アルゴリズム」の一部であるとは言えないことは，明らかである。
　そして，本願明細書中には，上記引用の記載内容の他，「受信機」に，「デバイスユニット鍵」を，「対称鍵アルゴリズム」を用いて，提供する構成については，特に，言及されていないので，本願明細書の発明の詳細な説明，及び，図面の記載内容からでは，
“サーバが，対称鍵アルゴリズムを用いて，どのようにして，デバイスに，デバイスユニット鍵を提供しているか”
　不明である。
　
　審判請求人は，前置拒絶理由における上記不明点（２），及び，（３）について，意見書，および，回答書において，「対称鍵アルゴリズム」については，何らの主張もなされていない。
　よって，意見書，回答書の内容を踏まえても，前置拒絶理由の（２），及び，（３）で指摘した不明点は，依然として解消していない。
　
　なお，「対称鍵アルゴリズム」に関して，平成２４年２月１６日付けで，審判請求人代理人より提示された書面には，その１頁下から２行〜２頁３行に，
「請求項１の「サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対しユニークであるデバイスユニット鍵を提供する工程であって，デバイスユニット鍵は公開鍵によって暗号化され，秘密鍵によって解読される，前記工程」における対称鍵アルゴリズムは，公開鍵アルゴリズムの誤りでしたので訂正させて頂きたく存じます」
　と記載されているが，上記書面を受けて審査官により通知された，前置拒絶理由に応答して，手続補正はなされておらず，また，該前置拒絶理由に対する意見書についても，上記で引用した程度の主張がなされるに止まり，該前置拒絶理由の（２），（３）において指摘した不明点は，上述のとおり，依然として，解消していない。
　
　以上１．及び，２．において検討したとおりであるから，前置拒絶理由の（１）〜（３）において指摘した不明点は，依然として解消していない。
　よって，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
第５．むすび
　したがって，本願は，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　よって，結論のとおり審決する。