【事件の表示】
　特願２００７−５５５１０４「ディジタル映画のための鍵管理システム」拒絶査定不服審判事件〔平成１８年　８月２４日国際公開，ＷＯ２００６／０８８５９６，平成２０年　８月　７日国内公表、特表２００８−５３０９０２〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
審決：
　
第１．手続の経緯
　本願は，２００６年１月１８日（パリ条約による優先権主張外国庁受理２００５年２月１５日　アメリカ合衆国）を国際出願日とする出願であって，
　平成１９年１０月１０日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文，並びに，条約第３４条（２）（ｂ）の規定に基づく補正書の日本語による翻訳文が提出され，平成２１年１月９日付けで審査請求がなされ，平成２３年８月９日付けで審査官により拒絶理由が通知され，これに対して平成２４年２月１７日付けで意見書が提出されると共に手続補正がなされたが，平成２４年６月２５日付けで審査官により拒絶査定がなされ（発送；平成２４年６月２７日），これに対して平成２４年１０月２６日付けで審判請求がなされ，平成２６年６月３日付けで当審により拒絶理由が通知され，これに対して平成２６年１０月２８日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という），及び，請求項２〜請求項１１に係る発明は，平成２６年１０月２８日付けの手続補正（以下，これを「本件手続補正」という）により補正された特許請求項の請求項１〜請求項１１に記載された，次のとおりものである。
　
「　【請求項１】
　暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップと，
　前記複数の保護されたフィーチャ鍵のうちの別々の１つを前記複数の暗号化解除モジュールのうちの対応する１つに供給して，前記暗号化済みコンテンツの暗号化解除を可能にするステップと，
を含む鍵管理方法。
　　【請求項２】
　前記供給するステップは，前記保護されたフィーチャ鍵を安全な送信チャネルを介して供給するステップをさらに含む，請求項１に記載の方法。
　　【請求項３】
　前記供給するステップは，前記保護されたフィーチャ鍵を安全な無線送信チャネルを介して供給するステップをさらに含む，請求項１に記載の方法。
　　【請求項４】
　フィーチャ作成システムからフィーチャ鍵を受け取り，保護されたフィーチャ鍵を暗号化解除モジュールに配布するための鍵マネージャ・システムであって，
　（１）前記フィーチャ作成システムからのフィーチャ鍵を，対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで暗号化して，複数の保護されたフィーチャ鍵を生成し，
　（２）前記複数の保護されたフィーチャ鍵の別々の１つを前記複数の暗号化解除モジュールのうちの対応する１つに供給して，暗号化済みコンテンツの暗号化解除を可能にする鍵マネージャを備える，前記システム。
　　【請求項５】
　前記コンテンツは，非対称スクランブル化アルゴリズム，対称スクランブル化アルゴリズム，非対称暗号化アルゴリズム，および対称暗号化アルゴリズムのうちのいずれか１つを使用して暗号化される，請求項４に記載のシステム。
　　【請求項６】
　当該鍵マネージャ・システムは，少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る，請求項４に記載のシステム。
　　【請求項７】
　前記フィーチャ鍵は，前記鍵マネージャと前記暗号化解除モジュールとの間で共有される鍵を利用する対称暗号化アルゴリズムまたはスクランブル化アルゴリズムを使用して保護される，請求項４に記載のシステム。
　　【請求項８】
　前記フィーチャ鍵は，前記鍵マネージャの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される，請求項４に記載のシステム。
　　【請求項９】
　前記フィーチャ鍵は，前記暗号化解除モジュールの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される，請求項４に記載のシステム。
　　【請求項１０】
　前記フィーチャ鍵は，前記送信鍵と他の情報とに基づいて生成される非対称暗号ベースの秘密／公開鍵の対を使用して保護される，請求項４に記載のシステム。
　　【請求項１１】
　前記保護されたフィーチャ鍵の配布は安全なチャネルを介して行われる，請求項４に記載のシステム。」
　
第３．当審の拒絶理由
　平成２６年６月３日付けの当審による拒絶理由（以下，これを「当審拒絶理由」という）は，次のとおりである。
　
「第３．拒絶理由
（１）本件出願は，明細書，特許請求の範囲及び図面の記載が下記の点で不備のため，特許法第３６条第４項第１号及び第６項第１号，第２号に規定する要件を満たしていない。
（２）本件出願の下記の請求項に係る発明は，その特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　記
　
１．３６条６項１号，及び，２号について
（１）本願の請求項１に，
「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」（以下，これを「引用記載１」という），
　と記載されている。
　引用記載１中の，「単一のメッセージ・グループ」とは，どのような態様を表現したものであるか，本願の請求項各項の記載内容からは不明である。
　仮に，引用記載１が，
“複数の暗号化解除モジュールの一つ一つが，全く異なる物理的位置，或いは，地理的位置に点在している状況で，それぞれの暗号解除モジュールが有する送信鍵を，一つのメッセージとして，鍵マネージャが受信する”，
　という態様を含むものであるとすると，
　本願明細書の発明の詳細な説明には，「単一のメッセージ・グループ」に関して，
「【００２４】
　各暗号化解除モジュールは，その公開鍵を鍵マネージャに送信する。このような送信は個別に行うことができる（すなわち，暗号化解除モジュールは鍵マネージャへの直接接続を有する）。あるいは，１組の暗号化解除モジュール，例えば単一の公開施設にあるすべての暗号化解除モジュールが，それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。通信リンクは，無線または有線チャネルを含むことができる。送信鍵に関する非対称アプローチの代替方法には，事前に合意した対称鍵の使用や，ＭＡＣベースの方法などを含めることができる。本原理の鍵管理技術は，フィーチャ暗号化鍵に暗号化解除モジュール・レベルでのみアクセス可能であり他のどんな中間モジュールからもアクセス不可能な方式で，フィーチャ暗号化鍵を保護する利点をもたらす。」（以下，これを「引用記載２」という。なお，下線は，当審にて説明の都合上，附加したものである。以下，同じ。）
　という記載が存在するのみであり，
“物理的・地理的に，別々に点在する暗号化解除モジュールの送信鍵を単一のメッセージ内で送信する”，
　という態様は，本願明細書の発明の詳細な説明に記載も示唆もされておらず，どのように実現するのかも不明である。
　よって，引用記載１が，仮に，上記指摘の態様を含むものであるとすると，本願の請求項１に係る発明は，発明の詳細な説明に記載されたものではなく，本願の請求項１に係る発明は，明確でない。
　引用記載１が，仮に，上記指摘の態様を含まないにしても，「単一のメッセージ・グループ」に関する点から，本願の請求項１に係る発明は，明確ではない。
　
（２）本願の請求項２，及び，請求項３は，本願の請求項１を引用するものであるから，上記（１）において指摘した明確でない構成を内包し，且つ，本願の請求項２，及び，請求項３に記載された内容からは，記載されていないという点，及び，明確でないという点が，解消するものではない。
　よって，本願の請求項２，及び，請求項３に係る発明は，本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確でない。
　
（３）本願の請求項４においても，上記（１）で指摘した記載が存在しているので，上記（１）で検討したとおり，本願の請求項４に係る発明は，本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確ではない。
　
（４）本願の請求項５〜請求項１１は，本願の請求項４を引用するものであるから，上記（３）において指摘した，本願明細書の発明の詳細な説明に記載されていない態様，或いは，明確でない態様を含むものであり，かつ，本願の請求項５〜請求項１１に記載された内容を加味しても，記載されていないという点，及び，明確でないという点が，解消するものではない。
　よって，本願の請求項５〜請求項１１に記載係る発明は，本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確なものでもない。
　加えて，本願の請求項６に，
「鍵マネージャ・システムは，少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」（以下，これを「引用記載３」という），
　と記載されているが，「暗号化解除受信側」と，「暗号化解除モジュール」との関係が，本願の請求項各項に記載された内容からは不明であり，「鍵マネージャ・システム」は，何を目的として，「少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」のか不明である。
（本願の請求項６に記載された内容からは，「識別子」を“１つ”ではなく，“１つ以上”と，“複数”送る態様を含み得るが，「暗号化解除受信側」と，「暗号化解除モジュール」とが，同一である場合に，何のために，「識別子」を“複数”送るのか不明であり，また，「暗号化解除受信側」と，「暗号化解除モジュール」とが，異なる場合に，「暗号化解除モジュール」は，送られた「識別子」をどのように用いるのか不明である。）
　この点に関して，本願明細書の発明の詳細な説明には，
「【００１５】
　鍵マネージャ３０００が，フィーチャ鍵２０００をコンテンツ製作者から受け取る。図３の鍵マネージャ３０００は，暗号化解除モジュール６００１〜６００４と，送信鍵４００１〜４００４をそれぞれ交換する。図３の例示的な実施例では，暗号化解除モジュール６００１および６００２は第１の公開施設（映画館Ａ）にあり，暗号化解除モジュール６００３および６００４は第２の公開施設（映画館Ｂ）にある。あるいは，暗号化解除モジュール６００１〜６００４それぞれが別々の公開施設にあってもよい。公開施設の数，およびこのような施設にある暗号化解除モジュールの数は，本原理の鍵管理技術に悪影響を及ぼすことなく変更することができる。鍵マネージャと暗号化解除モジュールの何れかが，交換を開始することになる。鍵マネージャが交換を開始する場合は，鍵マネージャ・システムは通常，少なくとも１つの予想される暗号化解除受信側の固有識別子を，各暗号化解除モジュールに送ることになる。」（以下，これを「引用記載４」という）
　という記載があるのみであり，引用記載４を参酌しても，何のために「少なくとも１つの予想される暗号化解除受信側の固有識別子」を送信するのか不明である。
　
２．３６条４項１号について
（１）本願の請求項１，及び，請求項４に記載された，引用記載１，
「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」，
　に関して，本願明細書の発明の詳細な説明には，引用記載２の他，
「【００２８】
　　【図１】本発明の原理の鍵管理技術を実施する，単一の公開施設に単一の暗号化解除　　モジュールがある場合のシステムの単純化されたブロック図である。
　　【図２】本発明の原理の鍵管理技術を実施する，単一の公開施設に複数の暗号化解除　　モジュールがある場合のシステムの単純化されたブロック図である。
　　【図３】本発明の原理の鍵管理技術を実施する，複数の公開施設に複数の暗号化解除　　モジュールがある場合のシステムの単純化されたブロック図である。」（以下，これを「引用記載５」という），
　が存在するのみであり，引用記載２，及び，引用記載５を参酌しても，「単一のメッセージ・グループ」とは，どのようなもので，「暗号化解除モジュール」が点在する場合に，どのように“一つのメッセージ内に送信鍵を入れて，鍵マネージャ・システムに送信する”ことが可能であるか不明である。
　
（２）本願の請求項６に記載された，引用記載３，
「鍵マネージャ・システムは，少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」，
　に関して，本願明細書の発明の詳細な説明には，引用記載４程度の記載しか存在しておらず，「鍵マネージャ・システム」は，何を目的として，或いは，何を実現するために，
「少なくとも１つの予想される暗号化解除受信側の固有識別子」を，「暗号化解除モジュール」に送信しているのか不明である。
　以上（１），及び，（２）において検討したとおりであるから，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
３．２９条２項について
　本願の請求項１〜請求項１１に係る発明は，上記１．において検討したとおり，本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確ではないが，一応，その字句どおりのものであるとして，以下の検討を行う。
（１）請求項１について
ア．引用刊行物に記載の発明
　一方，原審の平成２３年８月９日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用された，本願の第１国出願前に既に公知である，国際公開第２００４／０８４０３５号（２００４年９月３０日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「Processor 104 receives content from content owner 102, selectively secures at least a portion of that content, and provides the secured content to distributor 106, as described in more detail below in conjunction with FIGURE 5. Briefly, however, processor 104 creates and embeds in a stream of the received content, selected information, such as a content key for decryption, a content identifier, access constraints, rights, entitlements, and the like. In one embodiment, the selected information is packaged into at least one key package (not shown), each of which is encrypted employing at least one screener key. In another embodiment, each content key is encrypted employing at least one screener key. In one embodiment, the content identifier may be left in the clear. 
　The screener key(s) may be generated using any of a variety of encryption/decryption symmetric key mechanisms, including, but not limited to RSA algorithms, Data Encryption Standard (DES), International Data Encryption Algorithm (IDEA), Skipjack, RC4, Advanced Encryption Standard (AES), and the like. In one embodiment, the screener key(s) employ a 256-bit AES algorithm for the encryption/decryption of the key package. However, screener key(s) are not limited to symmetric key mechanisms, and asymmetric key mechanisms may also be employed without departing from the scope or spirit of the present invention.
　Processor 104 may obtain the screener key(s) and content key(s) from a variety of sources, including, but not limited to, content owner 102, a trusted third party, and the like. Processor 104 may also generate the screener key(s) and/or content key(s) itself. Moreover, the screener keys may reside within a key storage (not shown). Each screener key may be indexed in the key storage by a content identifier that is associated with particular content. The key storage may further include access constraints, rights, and the like, associated with a user, content, a targeted secure player, any combination of user, content, and targeted secure player, and the like.
　Distributor 106 includes businesses, systems, and the like that obtain rights from content owner 102 to copy and distribute the secure content. Distributor 106 may obtain the rights to copy and distribute from one or more content owners.
　Distributor 106 may repackage, store, and schedule secure content for subsequent sale, distribution, and license to other distributors, user(s) 114, and the like, using content media 112.」（４頁２１行〜５頁２２行）
（プロセッサ１０４は，図５と共に以下により詳細に説明されるように，コンテンツ保有部１０２からコンテンツを受け取り，そのコンテンツの少なくとも一部を選択的に保護し，分配部１０６のために，保護されたコンテンツを供給する。簡潔に言うと，しかしながら，プロセッサ１０４は，復号のためのコンテンツ鍵，コンテンツ識別子，アクセス制限，権利，資格などといった，選択された情報を，生成し，受け取ったコンテンツのストリーム内に埋め込む。一つの実施例においては，選択された情報は，それぞれが，少なくとも一つのスクリーナ鍵を使用して暗号化された，少なくとも一つの鍵パッケージ（図示せず）の中に梱包される。他の実施例においては，それぞれのコンテンツ鍵は，少なくとも一つのスクリーナ鍵を用いて暗号化される。一つの実施例においては，コンテンツ識別子は，暗号化されずに残されるかもしれない。
　スクリーナ鍵は，ＲＳＡアルゴリズム，ＤＥＳ，ＩＤＥＡ，Ｓｋｉｐｊａｃｋ，ＲＣ４，ＡＥＳ等を含むが，それらに限定されない，様々な暗号化／復号対称鍵メカニズムを用いて生成され得る。一つの実施例においては，スクリーナ鍵は，鍵パッケージ暗号化／復号に２５６ビットＡＥＳアルゴリズムを採用する。しかしながら，スクリーナ鍵は，対称鍵メカニズムに限定されない。そして，非対称鍵メカニズムもまた，本発明の範囲，或いは，要旨を逸脱することなく採用され得る。
　プロセッサ１０４は，コンテンツ所有部１０２，信頼できる第三者等を含むが，それに限定されない，種々のソースから，スクリーナ鍵と，コンテンツ鍵を取得し得る。プロセッサ１０４は，また，自身で，スクリーナ鍵，及び／または，コンテンツ鍵を生成する。加えて，スクリーナ鍵は，鍵ストレージ（図示せず）内に存在し得る。スクリーナ鍵のそれぞれは，特定のコンテンツに関連するコンテンツ識別子によって，鍵ストレージ内で，索引付けされ得る。鍵ストレージは，さらに，ユーザ，コンテンツ，標的のセキュア・プレーヤ，任意のユーザの組合せ，コンテンツ，標的のセキュア・プレーヤ等に関連した，アクセス制限，権利などを含み得る。
　分配部１０６は，コンテンツ所有部１０２から，セキュア・コンテンツを複製し，配布するための権利を得るための，取引，システムなどを含む。分配部１０６は，１以上のコンテンツ所有者から，複製と配布のための権利を所得し得る。分配部１０６は，コンテンツ１１２を使用することの，次の販売，分配，及び，他の分配者，ユーザ１１４等のライセンスのために，セキュア・コンテンツを，再梱包し，格納し，スケジュールし得る。当審にて訳出。以下，同じ。）
　
Ｂ．「Distributor 106 may further encrypt the screener key(s), and additional information included on screener key module 108, with a public key associated with the targeted secure player. The targeted secure player's public key may be generated employing a variety of asymmetric encryption mechanisms, including, but not limited to, Diffie-Hellman, RSA, Merkle-Hellman, PGP, X.509, and the like.
　In one embodiment, distributor 106 employs a 2048-bit RSA asymmetric (public/private) key associated with the targeted secure player to encrypt the screener key(s). In another embodiment, the public/private key pair associated with the targeted secure player is generated in a Federal Information Processing Standard (FIPS) level 4 device. However, the present invention is not so limited, and another security level may be employed to generate the targeted secure player's public/private key pair.
　In any event, the targeted secure player's public key. may be made available to distributor 106 through a variety of approaches, including a trusted third party, a network, email, and the like. Moreover, the targeted secure player's private/public keys are bound to the targeted secure player such that they are unique to that particular targeted secure player. Moreover, the targeted secure player is configured to prevent removal of the targeted secure player's private key. Such action further binds the targeted secure player's private key to the targeted secure player. 
　Distributor 106 may distribute screener key module 108 to user(s) 114 employing a variety of mechanisms, including, but not limited to, a smart card, PCMCIA card, a memory stick, over a network, DVD, CD, tape, floppy disc, and similar removable mechanisms. Screener key module 108 may also be mailed to user(s) 114.」（６頁１３行〜７頁５行）
（分配部１０６は，また，スクリーナ鍵，及び，スクリーナ鍵モジュールに含まれる，附加情報を，標的のセキュア・プレーヤに関連する公開鍵で暗号化し得る。標的のセキュア・プレーヤの公開鍵は，ディフィ・ヘルマン，ＲＳＡ，マークル・ヘルマン，ＰＧＰ，Ｘ．５０９等を含むが，それに限定されない，種々の非対称暗号化手法を採用して，生成され得る。
　一つの実施例においては，分配部１０６は，スクリーナ鍵を暗号化するために，標的のセキュア・プレーヤに関連する２０４８ビットのＲＳＡ非対称（公開／個別）鍵を採用する。他の実施例においては，標的のセキュア・プレーヤに対応する，公開／個別鍵の組は，連邦情報処理基準（ＦＩＰＳ）のレベル４のデバイスにおいて生成される。しかしながら，本発明においては，それに限定されず，標的のセキュア・プレーヤの公開／個別鍵の組のを生成することに，その他のセキュリティ・レベルが採用され得る。
　任意のイベントにおいて，標的のセキュア・プレーヤの公開鍵は，信頼できる第三者，ネットワーク，電子メールなどの，様々なやり方を通じて，分配部１０６に開示され得る。加えて，標的のセキュア・プレーヤの個別／公開鍵は，その標的のセキュア・プレーヤにひも付けされている，即ち，それは，特定の標的のセキュア・プレーヤに固有のものである。加えて，標的のセキュア・プレーヤは，標的のセキュア・プレーヤの個別鍵の削除を妨げるよう構成されている・このような動作が，更にまた，標的のセキュア・プレーヤの個別鍵を，標的のセキュア・プレーヤにひも付けする。
　分配部１０６は，スクリーナ鍵モジュール１０８を，スマート・カード，ＰＣＭＣＩＡカード，メモリ・スティック，ネットワーク上，ＤＶＤ，ＣＤ，テープ，フロッピィ・ディスク，及び，同様のリム−バル・メカニズムを含むが，それに限定されない，種々のメカニズムを採用することで，ユーザ１１４に配布し得る。スクリーナ鍵モジュール１０８は，また，ユーザ１１４に郵送し得る。）
　
Ｃ．Ｆｉｇ．１（図１）には，「Ｄｉｓｔｒｉｂｕｔｏｒ１０６（分配部１０６）」から，複数の「Ｕｓｅｒ１１４（ユーザ１１４）」に，「Ｓｃｒｅｅｎｅｒ　Ｋｅｙ　Ｍｏｄｕｌｅ１０８（スクリーナ鍵モジュール１０８）」と，「Ｃｏｎｔｅｎｔ　Ｍｅｄｉａ１１２（コンテンツ・メディア１１２」とが送信されていることが示されている。
　
１．上記Ｂの「Distributor 106 may further encrypt the screener key(s), and additional information included on screener key module 108, with a public key associated with the targeted secure player. （分配部１０６は，また，スクリーナ鍵，及び，スクリーナ鍵モジュールに含まれる，附加情報を，標的のセキュア・プレーヤに関連する公開鍵で暗号化し得る）」という記載，及び，同じく，上記Ｂの「In any event, the targeted secure player's public key. may be made available to distributor 106 through a variety of approaches, including a trusted third party, a network, email, and the like.（任意のイベントにおいて，標的のセキュア・プレーヤの公開鍵は，信頼できる第三者，ネットワーク，電子メールなどの，様々なやり方を通じて，分配部１０６に開示され得る）」という記載から，引用刊行物１においては，
“分配部１０６は，ネットワークを介して受信した，標的のセキュア・プレーヤの公開鍵を用いて，スクリーナ鍵を暗号化する”ものであることが読み取れる。
　
２．上記Ａの「 Each screener key may be indexed in the key storage by a content identifier that is associated with particular content. （スクリーナ鍵のそれぞれは，特定のコンテンツに関連するコンテンツ識別子によって，鍵ストレージ内で，索引付けされ得る）」という記載から，引用刊行物１においては，
“スクリーナ鍵は，特定のコンテンツに関連付けられている”ことは明らかであり，同じく，上記Ａの「processor 104 creates and embeds in a stream of the received content, selected information, such as a content key for decryption, a content identifier, access constraints, rights, entitlements, and the like. In one embodiment, the selected information is packaged into at least one key package (not shown), each of which is encrypted employing at least one screener key（プロセッサ１０４は，復号のためのコンテンツ鍵，コンテンツ識別子，アクセス制限，権利，資格などといった，選択された情報を，生成し，受け取ったコンテンツのストリーム内に埋め込む。一つの実施例においては，選択された情報は，それぞれが，少なくとも一つのスクリーナ鍵を使用して暗号化された，少なくとも一つの鍵パッケージ（図示せず）の中に梱包される）」という記載から，引用刊行物１において，
“コンテンツは暗号化されている”ものであり，“スクリーナ鍵は，暗号化されたコンテンツを復号するコンテンツ鍵を暗号化する”ものであるから，結果として，
“暗号化されたコンテンツに関連するスクリーナ鍵”であるといえる。
　
３．上記１．において引用した上記Ｂに記載の内容から，引用刊行物１においては，
“分配部１０６は，標的のセキュア・プレーヤの公開鍵を，ネットワークを介して受信する”ものであり，
　そして，上記Ｂの「the targeted secure player's private/public keys are bound to the targeted secure player such that they are unique to that particular targeted secure player.（標的のセキュア・プレーヤの個別／公開鍵は，その標的のセキュア・プレーヤにひも付けされている，即ち，それは，特定の標的のセキュア・プレーヤに固有のものである）」という記載，並びに，上記Ｂの「Distributor 106 may distribute screener key module 108 to user(s) 114 employing a variety of mechanisms, including, but not limited to, a smart card, PCMCIA card, a memory stick, over a network, DVD, CD, tape, floppy disc, and similar removable mechanisms（分配部１０６は，スクリーナ鍵モジュール１０８を，スマート・カード，ＰＣＭＣＩＡカード，メモリ・スティック，ネットワーク上，ＤＶＤ，ＣＤ，テープ，フロッピィ・ディスク，及び，同様のリム−バル・メカニズムを含むが，それに限定されない，種々のメカニズムを採用することで，ユーザ１１４に配布し得る）」という記載から，引用刊行物１に記載された発明は，
“分配部１０６は，標的のセキュア・プレーヤに固有の公開鍵を用いて，スクリーナ鍵を暗号化し，該暗号化されたスクリーナ鍵を，ネットワークを介して，ユーザ１１４に配信する”態様を含むことは明らかである。
　ここで，「ユーザ１１４」とは，「標的のセキュア・プレーヤ」を有する“者”であることは明らかであって，上記Ｃにおいて指摘した事項から，該「ユーザ」は複数存在しているので，該複数の「ユーザ」が，それぞれ有する，「標的のセキュア・プレーヤ」も複数存在することは明らかであるから，引用刊行物１においては，
“分配部１０６は，複数の標的のセキュア・プレーヤから，該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し，それぞれの公開鍵を用いて，スクリーナ鍵を暗号化し，前記それぞれの公開鍵で暗号化したスクリーナ鍵を，ネットワークを介して，それぞれの公開鍵に対応する，前記複数の標的のセキュア・プレーヤのそれぞれに送信する”ものであることが読み取れる。
　
　以上１．〜３．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　分配部において，複数の標的のセキュア・プレーヤから，該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し，それぞれの公開鍵を用いて，暗号化されたコンテンツに関連するスクリーナ鍵を暗号化し，
　前記それぞれの公開鍵で暗号化したスクリーナ鍵を，ネットワークを介して，それぞれの公開鍵に対応する，前記複数の標的のセキュア・プレーヤのそれぞれに送信する，方法。
　
イ．本願の請求項１に係る発明と引用発明との対比
１．引用発明における「スクリーナ鍵」は，「暗号化されたコンテンツに関連する」ものであるから，本願の請求項１に係る発明における「暗号化済みコンテンツに関連付けられたフィーチャ鍵」に相当し，引用発明における「公開鍵」は，「スクリーナ鍵」を暗化するために用いられているのであるから，本願の請求項１に係る発明における「送信鍵」に相当する。
　
２．引用発明における「分配部」は，「スクリーナ鍵」を暗号化し，「標的のセキュア・プレーヤ」に送信しているのであるから，本願の請求項１に係る発明における「暗号化を実施する鍵マネージャ」に相当し，引用発明における「標的のセキュア・プレーヤ」は，「分配部」に，「公開鍵」を送信するものであるから，本願の請求項１に係る発明における「暗号化解除モジュール」に相当するので，上記１．において検討した事項と併せると，
　引用発明における「分配部において，複数の標的のセキュア・プレーヤから，該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し，それぞれの公開鍵を用いて，暗号化されたコンテンツに関連するスクリーナ鍵を暗号化」することと，
　本願の請求項１に係る発明における「暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップ」とは，
“暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップ”である点で共通する。
　
３．引用発明においても，個々の「標的のセキュア・プレーヤ」に，「公開鍵で暗号化されたスクリーナ鍵」を送信するものであり，該「スクリーナ鍵」を受信することで，「標的のセキュア・プレーヤ」において「暗号化されたコンテンツ」が，“復号可能となる”ことは明らかであるから，
　引用発明における「前記それぞれの公開鍵で暗号化したスクリーナ鍵を，ネットワークを介して，それぞれの公開鍵に対応する，前記複数の標的のセキュア・プレーヤのそれぞれに送信する」が，
　本願の請求項１に係る発明における「前記複数の保護されたフィーチャ鍵のうちの別々の１つを前記複数の暗号化解除モジュールのうちの対応する１つに供給して，前記暗号化済みコンテンツの暗号化解除を可能にするステップ」に相当し，
　引用発明における「方法」も，「スクリーナ鍵」の管理を行う方法であることは，明らかである。
　よって，以上，１．〜３．において検討した事項から，本願の請求項１に係る発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップと，
　前記複数の保護されたフィーチャ鍵のうちの別々の１つを前記複数の暗号化解除モジュールのうちの対応する１つに供給して，前記暗号化済みコンテンツの暗号化解除を可能にするステップと，を含む鍵管理方法。
　
［相違点］
“対応する複数の暗号化解除モジュールから受け取った複数の送信鍵”に関して，
　本願発明においては，「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」であるのに対して，
　引用発明においては，“複数の公開鍵”を，“単一のメッセージ・グループとして受け取る”点については，言及されていない点。
　
ウ．相違点についての当審の判断
　「送信鍵」を，「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取」る点について，本願明細書の発明の詳細な説明には，引用記載２，及び，引用記載５という記載が存在するのみである。
　そして，上記１．及び，２．においても指摘したとおり，
“全く，ばらばらに点在している，複数の「暗号解除モジュール」の「送信鍵」を，何らかの手法で，一つにまとめて，「単一のメッセージ・グループ」として，「鍵マネージャ」に送信する”
　といった構成は，本願明細書の発明の詳細な説明には一切記載されていない。
　そうであるとすると，本願の請求項１に係る発明において，「送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取」るとは，
“複数の暗号解除モジュールを有する単一の施設からの単一のメッセージに，該複数の暗号解除モジュールの送信鍵を乗せて，鍵マネージャ”が受信するというものであると解される。
　しかしながら，単一の送信元が，複数の情報を単一のメッセージに含ませて，受信側に向けて，送信するようなことは，例えば，一つの電子メールに複数の添付ファイルを添付して送信するといった手法が存在しているように，当業者には周知の技術事項であり，複数の公開鍵を一括して送信するようなことも，例えば，本願の第１国出願前に既に公知である，特開２００３-３１８８７３号公報（２００３年１１月７日公開，以下，これを「周知文献」という）に，
　
Ｄ．「【０１８１】また，本発明によれば，電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に，これらの複数の公開鍵を一括して通信相手に送信するので，公開鍵送信のための処理と通信負荷を軽減することが可能となる。」
　
　などと記載されてもいるように，本願の第１国出願前に，当業者には周知の技術事項であり，引用発明においても，複数の公開鍵を，必要に応じて一括して送るよう構成することは，当業者が適宜なし得る事項である。
　よって，相違点は，格別のものではない。
　そして，本願の請求項１に係る発明の構成によってもたらされる効果も，引用発明から当業者ならば容易に予測することができる程度のものであって，格別のものとはいえない。
　
（２）請求項４について
　本願の請求項４に係る発明は，本願の請求項１に係る発明とほぼ同等の構成を有するものであるから，上記（１）で検討したとおり，引用発明，及び，周知技術とから，当業者が容易になし得たものである。
　
（３）請求項２，及び，請求項３について
　「安全な送信チャネル」，或いは，「安全な無線送信チャネル」自体は，本願の第１国出願前に，当業者には周知の技術事項に過ぎず，これらを適用することは，当業者が適宜なし得る事項である。
　
（４）請求項５〜請求項１１について
　コンテンツ等の暗号化に用いる鍵を配送するために，公開鍵暗号を用いること，或いは，送信側，受信側で予め共有していた供給鍵を用いて暗号化して送受信するようなことは，当業者には周知の技術事項に過ぎず，また，目的を問わず，識別子を送信する程度のことであれば，当業者が適宜なし得る事項である。」
　
第４．当審の判断
１．３６条６項１号，および，２号，並びに，同４項１号について
（１）本件手続補正によって，本願の請求項１〜請求項４，及び，請求項６〜請求項１１に記載された内容は，何ら補正されていない。
　したがって，本件手続補正によっては，当審拒絶理由は解消していない。
　
　そこで，審判請求人による，平成２６年１０月２８日付けの意見書（以下，単に「意見書」という）によって，当審拒絶理由が解消するかについて検討する。
　
（２）当審拒絶理由の理由１の「１．３６条６項１号，及び，２号について」の（１），及び（３）における，本願の請求項１，及び,請求項４についての指摘に対して，意見書において，
「３．３６条６項１号，２号について
（１）本願請求項１の「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」の「単一のメッセージ・グループ」について
　本願明細書の段落００２４には，「１組の暗号化解除モジュール，例えば単一の公開施設にあるすべての暗号化解除モジュールが，それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。」と記載されております。本願請求項１はその特徴事項を以下のように記載したものです。
　「暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップ」
　本願明細書の上記記載では「単一のメッセージ・グループ」は，まさに，単一の場所にある複数の暗号化解除モジュールから１組の送信鍵を含む単一のメッセージを意味します。以下に詳細に説明しますように，本願請求項１に記載された鍵管理技術は，「２つのステップ」による暗号化を利用します。すなわち，暗号化解除モジュールが送信鍵をフィーチャ鍵の暗号化のために鍵マネージャに送信します。それから，鍵マネージャはこれらの暗号化されたフィーチャ鍵を暗号化されたコンテンツの暗号化解除を行うそのような鍵を使用する暗号化解除モジュールに送信します。同一の場所にある１組の暗号解除モジュールから鍵マネージャへの送信鍵の送信を容易にするために，本願明細書に記載されていますように，送信鍵を１つのグループで，単一のメッセージとして送信します。
　これらのことから，本願請求項１に記載された「単一のメッセージ・グループ」は明確であり，本願請求項１に記載された特許を受けようとする発明は明確であると思料いたします。さらに，本願請求項１に記載された「単一のメッセージ・グループ」は，発明の詳細な説明に記載されたものであると思料いたします。本願請求項４も本願請求項１と同様に明確かつ発明の詳細な説明に記載されたものであると思料いたします。」（以下，これを「引用記載１」という）
　と主張すると共に，３６条４項１号については，
「４．３６条４項１号について
　上記２の（１）および（２）において説明しました事項により，本理由は解消したものと思料いたします。」（以下，これを「引用記載２」という）
　と主張しているので，前記引用の主張を以下に検討する。
　
　引用記載１において引用され，当審拒絶理由においても引用した，本願明細書の発明の詳細な説明の段落【００２４】の，
「１組の暗号化解除モジュール，例えば単一の公開施設にあるすべての暗号化解除モジュールが，それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる」
　という記載からは，
“複数の暗号化解除モジュールが，各暗号化解除モジュールのそれぞれの公開鍵を１つのメッセージの中に入れて，鍵管理システム送ることもできる”
　ということは，読み取れる。即ち，段落【００２４】に記載された内容から読み取れることは，
　“メッセージは１つであって，グループではない”
　ということである。
　通常の語彙の解釈からすれば，「メッセージ・グループ」と表現した場合，“複数のメッセージが集まったもの”と解するのが普通であり，「単一のメッセージ・グループ」と表現した場合は，“複数のメッセージが集まったものが１つ存在する”ことを表現していると解するのが妥当である。
　即ち，「単一のメッセージ」と，「単一のメッセージ・グループ」とは，同一のものを意味しないことは明らかである。
　この点に関して審判請求人は引用記載１において，
「本願明細書の上記記載では「単一のメッセージ・グループ」は，まさに，単一の場所にある複数の暗号化解除モジュールから１組の送信鍵を含む単一のメッセージを意味します。」
　と主張しているが，上記検討のとおり，本願明細書の発明の詳細な説明に記載された内容は，単に，“一つのメッセージ中に複数の鍵を入れる”というものであって，「グループ」に関しては，本願明細書の発明の詳細な説明に何ら記載されていない。
　以上のとおりであるから，審判請求人の引用記載１における主張は採用できない。
　また，上記で検討したとおり，本願明細書の発明の詳細な説明には，「単一のメッセージ・グループ」に関しての説明が存在していないので，審判請求人の引用記載２における主張も採用できない。
　
（３）当審拒絶理由の理由１の「１．３６条６項１号，及び，２号について」の（４）において，本願の請求項６に関して指摘した事項に対して，意見書において，
「（２）請求項６の「「鍵マネージャ・システムは，少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」について
　本願請求項に記載された鍵管理技術では、鍵マネージャと暗号化解除モジュールとが鍵の交換を行います。例えば、暗号化解除モジュールは、この交換を、鍵マネージャに送信鍵を送信することによって開始することができます（すなわち、「プッシュ」アプローチ）。代替的には、鍵マネージャは、暗号化解除モジュールからの送信鍵をリクエストすることができます（「プル」アプローチ）。鍵マネージャが送信鍵の受信を開始すると、鍵マネージャは、特定の暗号化解除モジュールに知られている固有識別子を送信して、鍵マネージャがこの対応する暗号化解除モジュールと受信した送信鍵とを関連付けできるようにします。このように、本願明細書の段落００１５の「鍵マネージャが交換を開始する場合は、鍵マネージャ・システムは通常、少なくとも１つの予想される暗号化解除受信側の固有識別子を、各暗号化解除モジュールに送ることになる。」の記載では、このような固有識別子を送信する目的が明確に記載されているものと思料いたします。」（以下，これを「引用記載３」という）
　と主張しているので，引用記載３における主張を以下に検討する。
　
　当審拒絶理由において指摘したとおり，本願の請求項６に記載された，
「鍵マネージャ・システムは，少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」，
　における「暗号化解除受信側」と，「暗号化解除モジュール」との関係は，上記（１）において指摘したとおり，本件手続補正において，本願の請求項６が何ら補正されていないため，本願の請求項６に記載された内容，及び，若干の補正を含む本願の請求項５を加えた，本願の請求項１〜請求項５，及び，請求項７〜請求項１１に記載された内容を加味しても，依然として不明である。
　本願明細書の発明の詳細な説明においても，当審拒絶理由において引用した段落【００１５】に，
「鍵マネージャが交換を開始する場合は，鍵マネージャ・システムは通常，少なくとも１つの予想される暗号化解除受信側の固有識別子を，各暗号化解除モジュールに送ることになる」，
　という記載があるのみであって，「暗号解除受信側」については，本願明細書の発明の詳細な説明の段落【００１５】以外に記載が存在しない。
　したがって，本願明細書の発明の詳細な説明に記載された内容を考慮しても，「暗号解除受信側」と，「暗号化解除モジュール」との関係は，依然として不明である。
　この点に関して，引用記載３における審判請求人の主張は，
「本願請求項に記載された鍵管理技術では、鍵マネージャと暗号化解除モジュールとが鍵の交換を行います。例えば、暗号化解除モジュールは、この交換を、鍵マネージャに送信鍵を送信することによって開始することができます（すなわち、「プッシュ」アプローチ）。代替的には、鍵マネージャは、暗号化解除モジュールからの送信鍵をリクエストすることができます（「プル」アプローチ）。鍵マネージャが送信鍵の受信を開始すると、鍵マネージャは、特定の暗号化解除モジュールに知られている固有識別子を送信して、鍵マネージャがこの対応する暗号化解除モジュールと受信した送信鍵とを関連付けできるようにします。」
　であるが，該主張内容は，本願明細書の発明の詳細な説明に記載された内容に基づくものではなく，また，当該技術分野において周知の技術事項といえるものでもない。
　加えて，上記引用の審判請求人の主張点においては，「暗号解除受信側」については，一切言及していない。即ち，上記主張点における「特定の暗号化解除モジュールに知られている固有識別子」において，唐突に「固有識別子」が説明中に出現し，該「固有識別子」が，何の「固有識別子」であるのかについては，何ら説明されていない。
　したがって，引用記載３における，本願明細書の発明の詳細な説明に記載された内容に基づかない説明を考慮しても，「暗号解除受信側」と，「暗号化解除モジュール」との関係が，依然として不明であり，当審拒絶理由の１の「１．３６条６項１号，及び，２号について」の（４）において，
「何のために「少なくとも１つの予想される暗号化解除受信側の固有識別子」を送信するのか不明である」，
　と指摘した事項は，依然として解消していない。
　
　以上（１）〜（３）において検討したとおりであるから，本件手続補正，及び，意見書の内容を考慮しても，本願の請求項１，請求項４に係る発明は，依然として,本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確でなく。
　したがって，本願の請求項１を引用する本願の請求項２，及び，請求項３に係る発明，並びに，本願の請求項４を引用する本願の請求項５〜請求項１１に係る発明は，依然として，本願明細書の発明の詳細な説明に記載されたものではなく，かつ，明確でない。
　そして，本願明細書の発明の詳細な説明は，依然として，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
２．２９条２項について
（１）本願発明
　上記「１．３６条６項１号，および，２号，並びに，同４項１号について」において検討したとおり，本願発明は，本願明細書の発明の詳細な説明に記載されたものでなく，本願発明は，明確ではないが，一応，上記において，本願の請求項１として引用した記載のとおりものであるとして，以下の検討を行う。
　
（２）引用刊行物に記載の発明
　当審拒絶理由において，引用刊行物１として引用した国際公開第２００４／０８４０３５号（２００４年９月３０日公開）には，上記引用の当審拒絶理由において検討したとおりの次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「分配部において，複数の標的のセキュア・プレーヤから，該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し，それぞれの公開鍵を用いて，暗号化されたコンテンツに関連するスクリーナ鍵を暗号化し， 
　前記それぞれの公開鍵で暗号化したスクリーナ鍵を，ネットワークを介して，それぞれの公開鍵に対応する，前記複数の標的のセキュア・プレーヤのそれぞれに送信する，方法。」
　
（３）本願発明と引用発明との対比
　本願発明は，本件手続補正によって補正が行われていないので，本願発明と，引用発明との一致点，及び，相違点は，上記引用の当審拒絶理由において検討した，次のとおりものである。
　
［一致点］ 
　暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで，暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して，複数の保護されたフィーチャ鍵を生成するステップと， 
　前記複数の保護されたフィーチャ鍵のうちの別々の１つを前記複数の暗号化解除モジュールのうちの対応する１つに供給して，前記暗号化済みコンテンツの暗号化解除を可能にするステップと，を含む鍵管理方法。 
　
 ［相違点］ 
“対応する複数の暗号化解除モジュールから受け取った複数の送信鍵”に関して， 
　本願発明においては，「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」であるのに対して，　
　引用発明においては，“複数の公開鍵”を，“単一のメッセージ・グループとして受け取る”点については，言及されていない点。 
　
（４）相違点に対する当審の判断
　当審拒絶理由において指摘したとおり，本願明細書の発明の詳細な説明には，上記相違点に相当する構成は記載されておらず，また，該構成を示唆する記載も存在しない。
　そこで，上記相違点を，当審拒絶理由，及び，上記「１．３６条６項１号，および，２号，並びに，同４項１号について」において指摘した，本願明細書の発明の詳細な説明の段落【００２４】に記載された事項を踏まえて，
“対応する複数の暗号化解除モジュールから単一のメッセージとして受け取った複数の送信鍵”
　と読み替えて，以下に検討する。
　
　“対応する複数の暗号化解除モジュールから単一のメッセージとして受け取った複数の送信鍵”
　という構成において，「送信鍵」とは，「公開鍵」であって，上記読み替えた相違点は，
“複数の公開鍵を１つのメッセージとして受け取る”
　という構成を意味するものであることは明らかである。
　そして，上記相違点については，当審拒絶理由において，周知文献として引用した，特開２００３−３１８８７３号公報（２００３年１１月７日公開）に，当審拒絶理由おいてＤ．として引用した，
　
「【０１８１】また，本発明によれば，電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に，これらの複数の公開鍵を一括して通信相手に送信するので，公開鍵送信のための処理と通信負荷を軽減することが可能となる。」
　
　という記載が存在しているように，必要に応じて，
「複数の公開鍵を一括して送信相手に送信する」
　ことは，本願の第１国出願前に，当業者には周知の技術事項であり，“一括して送信する”形態として，“１つのメッセージに含ませて送る”ことも，当審拒絶理由に，“電子メール（メッセージの相当）に複数の添付ファイルを附加することが周知である”としたとおりであるから，引用発明において，複数の公開鍵を，本願の第１国出願前に周知である技術事項を用いて，１つのメッセージにまとめて送信するよう構成することは，当業者が適宜なし得る事項である。
　
　よって，相違点は，格別のものではない。
　
（５）ここで，審判請求人は，意見書において，本願発明と，引用発明との一致点，及び，相違点に関して，
　
「引用文献１には，本願発明の「暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから・・・送信鍵を受け取る」点は記載も示唆もされておりません（以下，「第１の相違点」と称します。）。さらに，「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」点も記載も示唆もされておりません（以下，「第２の相違点」と称します。）。
　さらに，引用文献１では「単一のステップ」による暗号化システムについて記載しているのに対して，本願発明では「２つのステップ」による方法を特定しております。
　（ｉｉ）第１の相違点について
　拒絶理由では上記第１の相違点である「暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから・・・送信鍵を受け取る」点に関係する事項として，１０頁１２〜１５行に「引用刊行物１に記載された発明は，“分配部１０６は，標的のセキュア・プレーヤに固有の公開鍵を用いて，スクリーナ鍵を暗号化し，該暗号化されたスクリーナ鍵を，ネットワークを介して，ユーザ１１４に配信する”態様を含むことは明らかである。」と認定されております。そして，その認定された部分を「“分配部１０６は，複数の標的のセキュア・プレーヤから，該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し，・・・」と読み取られております（１０頁２１行〜２２行）。上記ご認定からこの読み取られた事項から導かれる根拠は，１０頁１６行〜１９行に記載の下記の事項では明らかにされていないものと思料いたします。
　　「ここで，「ユーザ１１４」とは，「標的のセキュア・プレーヤ」を有する“者”
　　であることは明らかであって，上記Ｃにおいて指摘した事項から，該「ユーザ」
　　は複数存在しているので，該複数の「ユーザ」が，それぞれ有する，「標的のセ
　　キュア・プレーヤ」も複数存在することは明らかである」
　このことから，上記第１の相違点は引用文献１に記載も示唆もされていないものと思料いたします。
　（ｉｉｉ）第２の相違点について
　拒絶理由では上記第２の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点に関係する事項として，「ウ．相違点についての当審の判断」として，「単一の送信元が，複数の情報を単一のメッセージに含ませて，受信側に向けて，送信するようなことは，例えば，一つの電子メールに複数の添付ファイルを添付して送信するといった手法が存在しているように，当業者には周知の技術事項」と判断され，さらに，「複数の公開鍵を一括して送信するようなことも，・・・（周知文献に）［０１８１」また，本発明によれば，電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に，これらの複数の公開鍵を一括して通信相手に送信するので，公開鍵送信のための処理と通信負荷を軽減することが可能となる。」などと記載されてもいるように，本願の第１国出願前に，当業者には周知の技術事項であ」ると判断されております。
　しかしながら，このご判断は，第２の相違点の「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係が考慮されておらず，単なる２者の間の関係ととらえられているようです。さらに，このご判断は，第２の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点を過度に分断して判断されており，第２の相違点全体の意義を考慮して判断されてはいないものと思料いたします。」
　
　と主張しているので，上記主張点について，以下に検討しておく。
　
ア．審判請求人の主張する相違点１について
　当審拒絶理由において，Ａ．として引用した記載にあるとおり，「ユーザ」は，原文では「user(s)」と記載されていて，引用刊行物１が，“ユーザが複数存在する”態様を含むことが明記されている。そして，同じくＣ．として引用したＦｉｇ．１には，「ユーザ」が，「１〜Ｎ」のＮ人，或いは，Ｎ台存在する態様が明記され，「分配部１０６」から，「スクリーナ鍵モジュール」の１〜Ｎまでが，それぞれ「ユーザ」の１〜Ｎに送られている態様が明記されている。そして，同じくＢ．として引用した記載に，「スクリーナ鍵」が，「セキュア・プレーヤ」に対応する「公開鍵」によって暗号化されることが明記されている。そして，「セキュア・プレーヤ」は，当審拒絶理由において指摘したとおり「ユーザ」側に存在するものである。
　以上のことから，以上のことから，「スクリーナ鍵モジュール」を，「ユーザ」，或いは，「セキュア・プレーヤ」に配布する「分配部１０６」は，１〜Ｎの「ユーザ」，或いは，「セキュア・プレーヤ」の公開鍵を有していることは明らかである。
　このことから，引用刊行物１に明文の記載はないものの，「配布部１０６」が，「スクリーナ鍵」を，各「セキュア・プレーヤ」に，各「セキュア・プレーヤ」の「公開鍵」を用いて送信する前段のステップとして，「配布部１０６」が，各「セキュア・プレーヤ」の「公開鍵」を取得するステップが存在することは明らかである。
　したがって，審判請求人の主張する相違点１のうちの“複数の送信鍵を受け取る”点,及び，２つのステップを有する点は，引用刊行物１に記載された内容からも読み取れる事項である。
　そして，“複数の送信鍵を受け取る”態様として，“複数の送信鍵を一纏めにして受信する”点については，当審拒絶理由においてＤ．として引用した周知文献の記載にもあるとおり，本願の第１国出願前に，当業者は周知の技術事項であるから，引用発明においても，“各セキュア・プレーヤの公開鍵を受け取る態様として，各セキュア・プレーヤの公開鍵を１つのメッセージとして受信する”よう構成することは，上記「（４）相違点に対する当審の判断」において検討したとおり，当業者が適宜なし得る事項である。
　
イ．審判請求人の主張する相違点２について
　審判請求人の主張する相違点２に関して，審判請求人は，上記引用の意見書において，
当審拒絶理由において“一括して受信することは周知技術である”として点に対して，
「このご判断は，第２の相違点の「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係が考慮されておらず，単なる２者の間の関係ととらえられているようです。さらに，このご判断は，第２の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点を過度に分断して判断されており，第２の相違点全体の意義を考慮して判断されてはいないもの」である旨主張しているが，
　該主張における「「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係」について，具体的に説明されておらず，本願の請求項１には，単に，
「暗号化を実施する鍵マネージャにおいて，対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」，
　と記載されているのみであるから，上記引用の請求項１からは，高々，“送信鍵を送信する暗号化解除モジュール”と，“暗号化解除モジュールの送信する送信鍵を受信する鍵マネージャ”が存在することが，読み取れる程度であり，「暗号化解除モジュール」と，「鍵マネージャ」との間の，本願の請求項１に係る発明に特有の関係などは，一切読み取れない。
　
　以上ア．，及び，イ．において検討したとおりであるから，２９条２項に関する意見書における主張は，拒絶理由の解消するに足る内容を有していないので，採用することは出来ない。
　
　よって，本願の請求項１に係る発明は，本件手続補正，及び，意見書の内容を考慮しても，依然として，引用発明，及び，周知技術から，当業者が容易に構築し得るものであり，本願発明の構成によってもたらされる効果も，引用例記載の発明から当業者ならば容易に予測することができる程度のものであって，格別のものとはいえない。
　
第５．むすび
　したがって，本願は，特許法第３６条第４項第１号及び第６項第１号，第２号に規定する要件を満たしていない。
　加えて，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。