• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L
管理番号 1301973
審判番号 不服2012-21136  
総通号数 188 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-08-28 
種別 拒絶査定不服の審決 
審判請求日 2012-10-26 
確定日 2015-06-12 
事件の表示 特願2007-555104「ディジタル映画のための鍵管理システム」拒絶査定不服審判事件〔平成18年 8月24日国際公開,WO2006/088596,平成20年 8月 7日国内公表、特表2008-530902〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 審決:

第1.手続の経緯
本願は,2006年1月18日(パリ条約による優先権主張外国庁受理2005年2月15日 アメリカ合衆国)を国際出願日とする出願であって,
平成19年10月10日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文,並びに,条約第34条(2)(b)の規定に基づく補正書の日本語による翻訳文が提出され,平成21年1月9日付けで審査請求がなされ,平成23年8月9日付けで審査官により拒絶理由が通知され,これに対して平成24年2月17日付けで意見書が提出されると共に手続補正がなされたが,平成24年6月25日付けで審査官により拒絶査定がなされ(発送;平成24年6月27日),これに対して平成24年10月26日付けで審判請求がなされ,平成26年6月3日付けで当審により拒絶理由が通知され,これに対して平成26年10月28日付けで意見書が提出されると共に手続補正がなされたものである。

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

「 【請求項1】
暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップと,
前記複数の保護されたフィーチャ鍵のうちの別々の1つを前記複数の暗号化解除モジュールのうちの対応する1つに供給して,前記暗号化済みコンテンツの暗号化解除を可能にするステップと,
を含む鍵管理方法。
【請求項2】
前記供給するステップは,前記保護されたフィーチャ鍵を安全な送信チャネルを介して供給するステップをさらに含む,請求項1に記載の方法。
【請求項3】
前記供給するステップは,前記保護されたフィーチャ鍵を安全な無線送信チャネルを介して供給するステップをさらに含む,請求項1に記載の方法。
【請求項4】
フィーチャ作成システムからフィーチャ鍵を受け取り,保護されたフィーチャ鍵を暗号化解除モジュールに配布するための鍵マネージャ・システムであって,
(1)前記フィーチャ作成システムからのフィーチャ鍵を,対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで暗号化して,複数の保護されたフィーチャ鍵を生成し,
(2)前記複数の保護されたフィーチャ鍵の別々の1つを前記複数の暗号化解除モジュールのうちの対応する1つに供給して,暗号化済みコンテンツの暗号化解除を可能にする鍵マネージャを備える,前記システム。
【請求項5】
前記コンテンツは,非対称スクランブル化アルゴリズム,対称スクランブル化アルゴリズム,非対称暗号化アルゴリズム,および対称暗号化アルゴリズムのうちのいずれか1つを使用して暗号化される,請求項4に記載のシステム。
【請求項6】
当該鍵マネージャ・システムは,少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る,請求項4に記載のシステム。
【請求項7】
前記フィーチャ鍵は,前記鍵マネージャと前記暗号化解除モジュールとの間で共有される鍵を利用する対称暗号化アルゴリズムまたはスクランブル化アルゴリズムを使用して保護される,請求項4に記載のシステム。
【請求項8】
前記フィーチャ鍵は,前記鍵マネージャの秘密/公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される,請求項4に記載のシステム。
【請求項9】
前記フィーチャ鍵は,前記暗号化解除モジュールの秘密/公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される,請求項4に記載のシステム。
【請求項10】
前記フィーチャ鍵は,前記送信鍵と他の情報とに基づいて生成される非対称暗号ベースの秘密/公開鍵の対を使用して保護される,請求項4に記載のシステム。
【請求項11】
前記保護されたフィーチャ鍵の配布は安全なチャネルを介して行われる,請求項4に記載のシステム。」

第3.当審の拒絶理由
平成26年6月3日付けの当審による拒絶理由(以下,これを「当審拒絶理由」という)は,次のとおりである。

「第3.拒絶理由
(1)本件出願は,明細書,特許請求の範囲及び図面の記載が下記の点で不備のため,特許法第36条第4項第1号及び第6項第1号,第2号に規定する要件を満たしていない。
(2)本件出願の下記の請求項に係る発明は,その特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

記

1.36条6項1号,及び,2号について
(1)本願の請求項1に,
「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」(以下,これを「引用記載1」という),
と記載されている。
引用記載1中の,「単一のメッセージ・グループ」とは,どのような態様を表現したものであるか,本願の請求項各項の記載内容からは不明である。
仮に,引用記載1が,
“複数の暗号化解除モジュールの一つ一つが,全く異なる物理的位置,或いは,地理的位置に点在している状況で,それぞれの暗号解除モジュールが有する送信鍵を,一つのメッセージとして,鍵マネージャが受信する”,
という態様を含むものであるとすると,
本願明細書の発明の詳細な説明には,「単一のメッセージ・グループ」に関して,
「【0024】
各暗号化解除モジュールは,その公開鍵を鍵マネージャに送信する。このような送信は個別に行うことができる(すなわち,暗号化解除モジュールは鍵マネージャへの直接接続を有する)。あるいは,1組の暗号化解除モジュール,例えば単一の公開施設にあるすべての暗号化解除モジュールが,それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。通信リンクは,無線または有線チャネルを含むことができる。送信鍵に関する非対称アプローチの代替方法には,事前に合意した対称鍵の使用や,MACベースの方法などを含めることができる。本原理の鍵管理技術は,フィーチャ暗号化鍵に暗号化解除モジュール・レベルでのみアクセス可能であり他のどんな中間モジュールからもアクセス不可能な方式で,フィーチャ暗号化鍵を保護する利点をもたらす。」(以下,これを「引用記載2」という。なお,下線は,当審にて説明の都合上,附加したものである。以下,同じ。)
という記載が存在するのみであり,
“物理的・地理的に,別々に点在する暗号化解除モジュールの送信鍵を単一のメッセージ内で送信する”,
という態様は,本願明細書の発明の詳細な説明に記載も示唆もされておらず,どのように実現するのかも不明である。
よって,引用記載1が,仮に,上記指摘の態様を含むものであるとすると,本願の請求項1に係る発明は,発明の詳細な説明に記載されたものではなく,本願の請求項1に係る発明は,明確でない。
引用記載1が,仮に,上記指摘の態様を含まないにしても,「単一のメッセージ・グループ」に関する点から,本願の請求項1に係る発明は,明確ではない。

(2)本願の請求項2,及び,請求項3は,本願の請求項1を引用するものであるから,上記(1)において指摘した明確でない構成を内包し,且つ,本願の請求項2,及び,請求項3に記載された内容からは,記載されていないという点,及び,明確でないという点が,解消するものではない。
よって,本願の請求項2,及び,請求項3に係る発明は,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確でない。

(3)本願の請求項4においても,上記(1)で指摘した記載が存在しているので,上記(1)で検討したとおり,本願の請求項4に係る発明は,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確ではない。

(4)本願の請求項5?請求項11は,本願の請求項4を引用するものであるから,上記(3)において指摘した,本願明細書の発明の詳細な説明に記載されていない態様,或いは,明確でない態様を含むものであり,かつ,本願の請求項5?請求項11に記載された内容を加味しても,記載されていないという点,及び,明確でないという点が,解消するものではない。
よって,本願の請求項5?請求項11に記載係る発明は,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確なものでもない。
加えて,本願の請求項6に,
「鍵マネージャ・システムは,少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」(以下,これを「引用記載3」という),
と記載されているが,「暗号化解除受信側」と,「暗号化解除モジュール」との関係が,本願の請求項各項に記載された内容からは不明であり,「鍵マネージャ・システム」は,何を目的として,「少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」のか不明である。
(本願の請求項6に記載された内容からは,「識別子」を“1つ”ではなく,“1つ以上”と,“複数”送る態様を含み得るが,「暗号化解除受信側」と,「暗号化解除モジュール」とが,同一である場合に,何のために,「識別子」を“複数”送るのか不明であり,また,「暗号化解除受信側」と,「暗号化解除モジュール」とが,異なる場合に,「暗号化解除モジュール」は,送られた「識別子」をどのように用いるのか不明である。)
この点に関して,本願明細書の発明の詳細な説明には,
「【0015】
鍵マネージャ3000が,フィーチャ鍵2000をコンテンツ製作者から受け取る。図3の鍵マネージャ3000は,暗号化解除モジュール6001?6004と,送信鍵4001?4004をそれぞれ交換する。図3の例示的な実施例では,暗号化解除モジュール6001および6002は第1の公開施設(映画館A)にあり,暗号化解除モジュール6003および6004は第2の公開施設(映画館B)にある。あるいは,暗号化解除モジュール6001?6004それぞれが別々の公開施設にあってもよい。公開施設の数,およびこのような施設にある暗号化解除モジュールの数は,本原理の鍵管理技術に悪影響を及ぼすことなく変更することができる。鍵マネージャと暗号化解除モジュールの何れかが,交換を開始することになる。鍵マネージャが交換を開始する場合は,鍵マネージャ・システムは通常,少なくとも1つの予想される暗号化解除受信側の固有識別子を,各暗号化解除モジュールに送ることになる。」(以下,これを「引用記載4」という)
という記載があるのみであり,引用記載4を参酌しても,何のために「少なくとも1つの予想される暗号化解除受信側の固有識別子」を送信するのか不明である。

2.36条4項1号について
(1)本願の請求項1,及び,請求項4に記載された,引用記載1,
「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」,
に関して,本願明細書の発明の詳細な説明には,引用記載2の他,
「【0028】
【図1】本発明の原理の鍵管理技術を実施する,単一の公開施設に単一の暗号化解除 モジュールがある場合のシステムの単純化されたブロック図である。
【図2】本発明の原理の鍵管理技術を実施する,単一の公開施設に複数の暗号化解除 モジュールがある場合のシステムの単純化されたブロック図である。
【図3】本発明の原理の鍵管理技術を実施する,複数の公開施設に複数の暗号化解除 モジュールがある場合のシステムの単純化されたブロック図である。」(以下,これを「引用記載5」という),
が存在するのみであり,引用記載2,及び,引用記載5を参酌しても,「単一のメッセージ・グループ」とは,どのようなもので,「暗号化解除モジュール」が点在する場合に,どのように“一つのメッセージ内に送信鍵を入れて,鍵マネージャ・システムに送信する”ことが可能であるか不明である。

(2)本願の請求項6に記載された,引用記載3,
「鍵マネージャ・システムは,少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」,
に関して,本願明細書の発明の詳細な説明には,引用記載4程度の記載しか存在しておらず,「鍵マネージャ・システム」は,何を目的として,或いは,何を実現するために,
「少なくとも1つの予想される暗号化解除受信側の固有識別子」を,「暗号化解除モジュール」に送信しているのか不明である。
以上(1),及び,(2)において検討したとおりであるから,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

3.29条2項について
本願の請求項1?請求項11に係る発明は,上記1.において検討したとおり,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確ではないが,一応,その字句どおりのものであるとして,以下の検討を行う。
(1)請求項1について
ア.引用刊行物に記載の発明
一方,原審の平成23年8月9日付けの拒絶理由(以下,これを「原審拒絶理由」という)において引用された,本願の第1国出願前に既に公知である,国際公開第2004/084035号(2004年9月30日公開,以下,これを「引用刊行物1」という)には,関連する図面と共に,次の事項が記載されている。

A.「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.」(4頁21行?5頁22行)
(プロセッサ104は,図5と共に以下により詳細に説明されるように,コンテンツ保有部102からコンテンツを受け取り,そのコンテンツの少なくとも一部を選択的に保護し,分配部106のために,保護されたコンテンツを供給する。簡潔に言うと,しかしながら,プロセッサ104は,復号のためのコンテンツ鍵,コンテンツ識別子,アクセス制限,権利,資格などといった,選択された情報を,生成し,受け取ったコンテンツのストリーム内に埋め込む。一つの実施例においては,選択された情報は,それぞれが,少なくとも一つのスクリーナ鍵を使用して暗号化された,少なくとも一つの鍵パッケージ(図示せず)の中に梱包される。他の実施例においては,それぞれのコンテンツ鍵は,少なくとも一つのスクリーナ鍵を用いて暗号化される。一つの実施例においては,コンテンツ識別子は,暗号化されずに残されるかもしれない。
スクリーナ鍵は,RSAアルゴリズム,DES,IDEA,Skiｐjack,RC4,AES等を含むが,それらに限定されない,様々な暗号化/復号対称鍵メカニズムを用いて生成され得る。一つの実施例においては,スクリーナ鍵は,鍵パッケージ暗号化/復号に256ビットAESアルゴリズムを採用する。しかしながら,スクリーナ鍵は,対称鍵メカニズムに限定されない。そして,非対称鍵メカニズムもまた,本発明の範囲,或いは,要旨を逸脱することなく採用され得る。
プロセッサ104は,コンテンツ所有部102,信頼できる第三者等を含むが,それに限定されない,種々のソースから,スクリーナ鍵と,コンテンツ鍵を取得し得る。プロセッサ104は,また,自身で,スクリーナ鍵,及び/または,コンテンツ鍵を生成する。加えて,スクリーナ鍵は,鍵ストレージ(図示せず)内に存在し得る。スクリーナ鍵のそれぞれは,特定のコンテンツに関連するコンテンツ識別子によって,鍵ストレージ内で,索引付けされ得る。鍵ストレージは,さらに,ユーザ,コンテンツ,標的のセキュア・プレーヤ,任意のユーザの組合せ,コンテンツ,標的のセキュア・プレーヤ等に関連した,アクセス制限,権利などを含み得る。
分配部106は,コンテンツ所有部102から,セキュア・コンテンツを複製し,配布するための権利を得るための,取引,システムなどを含む。分配部106は,1以上のコンテンツ所有者から,複製と配布のための権利を所得し得る。分配部106は,コンテンツ112を使用することの,次の販売,分配,及び,他の分配者,ユーザ114等のライセンスのために,セキュア・コンテンツを,再梱包し,格納し,スケジュールし得る。<当審にて訳出。以下,同じ。>)

B.「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.」(6頁13行?7頁5行)
(分配部106は,また,スクリーナ鍵,及び,スクリーナ鍵モジュールに含まれる,附加情報を,標的のセキュア・プレーヤに関連する公開鍵で暗号化し得る。標的のセキュア・プレーヤの公開鍵は,ディフィ・ヘルマン,RSA,マークル・ヘルマン,PGP,X.509等を含むが,それに限定されない,種々の非対称暗号化手法を採用して,生成され得る。
一つの実施例においては,分配部106は,スクリーナ鍵を暗号化するために,標的のセキュア・プレーヤに関連する2048ビットのRSA非対称(公開/個別)鍵を採用する。他の実施例においては,標的のセキュア・プレーヤに対応する,公開/個別鍵の組は,連邦情報処理基準(FIPS)のレベル4のデバイスにおいて生成される。しかしながら,本発明においては,それに限定されず,標的のセキュア・プレーヤの公開/個別鍵の組のを生成することに,その他のセキュリティ・レベルが採用され得る。
任意のイベントにおいて,標的のセキュア・プレーヤの公開鍵は,信頼できる第三者,ネットワーク,電子メールなどの,様々なやり方を通じて,分配部106に開示され得る。加えて,標的のセキュア・プレーヤの個別/公開鍵は,その標的のセキュア・プレーヤにひも付けされている,即ち,それは,特定の標的のセキュア・プレーヤに固有のものである。加えて,標的のセキュア・プレーヤは,標的のセキュア・プレーヤの個別鍵の削除を妨げるよう構成されている・このような動作が,更にまた,標的のセキュア・プレーヤの個別鍵を,標的のセキュア・プレーヤにひも付けする。
分配部106は,スクリーナ鍵モジュール108を,スマート・カード,PCMCIAカード,メモリ・スティック,ネットワーク上,DVD,CD,テープ,フロッピィ・ディスク,及び,同様のリム-バル・メカニズムを含むが,それに限定されない,種々のメカニズムを採用することで,ユーザ114に配布し得る。スクリーナ鍵モジュール108は,また,ユーザ114に郵送し得る。)

C.Fig.1(図1)には,「Diｓｔｒibｕｔｏｒ106(分配部106)」から,複数の「Uｓeｒ114(ユーザ114)」に,「Scｒeeneｒ Keｙ Mｏdｕle108(スクリーナ鍵モジュール108)」と,「Cｏnｔenｔ Media112(コンテンツ・メディア112」とが送信されていることが示されている。

1.上記Bの「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. (分配部106は,また,スクリーナ鍵,及び,スクリーナ鍵モジュールに含まれる,附加情報を,標的のセキュア・プレーヤに関連する公開鍵で暗号化し得る)」という記載,及び,同じく,上記Bの「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.(任意のイベントにおいて,標的のセキュア・プレーヤの公開鍵は,信頼できる第三者,ネットワーク,電子メールなどの,様々なやり方を通じて,分配部106に開示され得る)」という記載から,引用刊行物1においては,
“分配部106は,ネットワークを介して受信した,標的のセキュア・プレーヤの公開鍵を用いて,スクリーナ鍵を暗号化する”ものであることが読み取れる。

2.上記Aの「 Each screener key may be indexed in the key storage by a content identifier that is associated with particular content. (スクリーナ鍵のそれぞれは,特定のコンテンツに関連するコンテンツ識別子によって,鍵ストレージ内で,索引付けされ得る)」という記載から,引用刊行物1においては,
“スクリーナ鍵は,特定のコンテンツに関連付けられている”ことは明らかであり,同じく,上記Aの「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(プロセッサ104は,復号のためのコンテンツ鍵,コンテンツ識別子,アクセス制限,権利,資格などといった,選択された情報を,生成し,受け取ったコンテンツのストリーム内に埋め込む。一つの実施例においては,選択された情報は,それぞれが,少なくとも一つのスクリーナ鍵を使用して暗号化された,少なくとも一つの鍵パッケージ(図示せず)の中に梱包される)」という記載から,引用刊行物1において,
“コンテンツは暗号化されている”ものであり,“スクリーナ鍵は,暗号化されたコンテンツを復号するコンテンツ鍵を暗号化する”ものであるから,結果として,
“暗号化されたコンテンツに関連するスクリーナ鍵”であるといえる。

3.上記1.において引用した上記Bに記載の内容から,引用刊行物1においては,
“分配部106は,標的のセキュア・プレーヤの公開鍵を,ネットワークを介して受信する”ものであり,
そして,上記Bの「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.(標的のセキュア・プレーヤの個別/公開鍵は,その標的のセキュア・プレーヤにひも付けされている,即ち,それは,特定の標的のセキュア・プレーヤに固有のものである)」という記載,並びに,上記Bの「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(分配部106は,スクリーナ鍵モジュール108を,スマート・カード,PCMCIAカード,メモリ・スティック,ネットワーク上,DVD,CD,テープ,フロッピィ・ディスク,及び,同様のリム-バル・メカニズムを含むが,それに限定されない,種々のメカニズムを採用することで,ユーザ114に配布し得る)」という記載から,引用刊行物1に記載された発明は,
“分配部106は,標的のセキュア・プレーヤに固有の公開鍵を用いて,スクリーナ鍵を暗号化し,該暗号化されたスクリーナ鍵を,ネットワークを介して,ユーザ114に配信する”態様を含むことは明らかである。
ここで,「ユーザ114」とは,「標的のセキュア・プレーヤ」を有する“者”であることは明らかであって,上記Cにおいて指摘した事項から,該「ユーザ」は複数存在しているので,該複数の「ユーザ」が,それぞれ有する,「標的のセキュア・プレーヤ」も複数存在することは明らかであるから,引用刊行物1においては,
“分配部106は,複数の標的のセキュア・プレーヤから,該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し,それぞれの公開鍵を用いて,スクリーナ鍵を暗号化し,前記それぞれの公開鍵で暗号化したスクリーナ鍵を,ネットワークを介して,それぞれの公開鍵に対応する,前記複数の標的のセキュア・プレーヤのそれぞれに送信する”ものであることが読み取れる。

以上1.?3.において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

分配部において,複数の標的のセキュア・プレーヤから,該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し,それぞれの公開鍵を用いて,暗号化されたコンテンツに関連するスクリーナ鍵を暗号化し,
前記それぞれの公開鍵で暗号化したスクリーナ鍵を,ネットワークを介して,それぞれの公開鍵に対応する,前記複数の標的のセキュア・プレーヤのそれぞれに送信する,方法。

イ.本願の請求項1に係る発明と引用発明との対比
1.引用発明における「スクリーナ鍵」は,「暗号化されたコンテンツに関連する」ものであるから,本願の請求項1に係る発明における「暗号化済みコンテンツに関連付けられたフィーチャ鍵」に相当し,引用発明における「公開鍵」は,「スクリーナ鍵」を暗化するために用いられているのであるから,本願の請求項1に係る発明における「送信鍵」に相当する。

2.引用発明における「分配部」は,「スクリーナ鍵」を暗号化し,「標的のセキュア・プレーヤ」に送信しているのであるから,本願の請求項1に係る発明における「暗号化を実施する鍵マネージャ」に相当し,引用発明における「標的のセキュア・プレーヤ」は,「分配部」に,「公開鍵」を送信するものであるから,本願の請求項1に係る発明における「暗号化解除モジュール」に相当するので,上記1.において検討した事項と併せると,
引用発明における「分配部において,複数の標的のセキュア・プレーヤから,該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し,それぞれの公開鍵を用いて,暗号化されたコンテンツに関連するスクリーナ鍵を暗号化」することと,
本願の請求項1に係る発明における「暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップ」とは,
“暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップ”である点で共通する。

3.引用発明においても,個々の「標的のセキュア・プレーヤ」に,「公開鍵で暗号化されたスクリーナ鍵」を送信するものであり,該「スクリーナ鍵」を受信することで,「標的のセキュア・プレーヤ」において「暗号化されたコンテンツ」が,“復号可能となる”ことは明らかであるから,
引用発明における「前記それぞれの公開鍵で暗号化したスクリーナ鍵を,ネットワークを介して,それぞれの公開鍵に対応する,前記複数の標的のセキュア・プレーヤのそれぞれに送信する」が,
本願の請求項1に係る発明における「前記複数の保護されたフィーチャ鍵のうちの別々の1つを前記複数の暗号化解除モジュールのうちの対応する1つに供給して,前記暗号化済みコンテンツの暗号化解除を可能にするステップ」に相当し,
引用発明における「方法」も,「スクリーナ鍵」の管理を行う方法であることは,明らかである。
よって,以上,1.?3.において検討した事項から,本願の請求項1に係る発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップと,
前記複数の保護されたフィーチャ鍵のうちの別々の1つを前記複数の暗号化解除モジュールのうちの対応する1つに供給して,前記暗号化済みコンテンツの暗号化解除を可能にするステップと,を含む鍵管理方法。

[相違点]
“対応する複数の暗号化解除モジュールから受け取った複数の送信鍵”に関して,
本願発明においては,「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」であるのに対して,
引用発明においては,“複数の公開鍵”を,“単一のメッセージ・グループとして受け取る”点については,言及されていない点。

ウ.相違点についての当審の判断
「送信鍵」を,「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取」る点について,本願明細書の発明の詳細な説明には,引用記載2,及び,引用記載5という記載が存在するのみである。
そして,上記1.及び,2.においても指摘したとおり,
“全く,ばらばらに点在している,複数の「暗号解除モジュール」の「送信鍵」を,何らかの手法で,一つにまとめて,「単一のメッセージ・グループ」として,「鍵マネージャ」に送信する”
といった構成は,本願明細書の発明の詳細な説明には一切記載されていない。
そうであるとすると,本願の請求項1に係る発明において,「送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取」るとは,
“複数の暗号解除モジュールを有する単一の施設からの単一のメッセージに,該複数の暗号解除モジュールの送信鍵を乗せて,鍵マネージャ”が受信するというものであると解される。
しかしながら,単一の送信元が,複数の情報を単一のメッセージに含ませて,受信側に向けて,送信するようなことは,例えば,一つの電子メールに複数の添付ファイルを添付して送信するといった手法が存在しているように,当業者には周知の技術事項であり,複数の公開鍵を一括して送信するようなことも,例えば,本願の第1国出願前に既に公知である,特開2003-318873号公報(2003年11月7日公開,以下,これを「周知文献」という)に,

D.「【0181】また,本発明によれば,電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に,これらの複数の公開鍵を一括して通信相手に送信するので,公開鍵送信のための処理と通信負荷を軽減することが可能となる。」

などと記載されてもいるように,本願の第1国出願前に,当業者には周知の技術事項であり,引用発明においても,複数の公開鍵を,必要に応じて一括して送るよう構成することは,当業者が適宜なし得る事項である。
よって,相違点は,格別のものではない。
そして,本願の請求項1に係る発明の構成によってもたらされる効果も,引用発明から当業者ならば容易に予測することができる程度のものであって,格別のものとはいえない。

(2)請求項4について
本願の請求項4に係る発明は,本願の請求項1に係る発明とほぼ同等の構成を有するものであるから,上記(1)で検討したとおり,引用発明,及び,周知技術とから,当業者が容易になし得たものである。

(3)請求項2,及び,請求項3について
「安全な送信チャネル」,或いは,「安全な無線送信チャネル」自体は,本願の第1国出願前に,当業者には周知の技術事項に過ぎず,これらを適用することは,当業者が適宜なし得る事項である。

(4)請求項5?請求項11について
コンテンツ等の暗号化に用いる鍵を配送するために,公開鍵暗号を用いること,或いは,送信側,受信側で予め共有していた供給鍵を用いて暗号化して送受信するようなことは,当業者には周知の技術事項に過ぎず,また,目的を問わず,識別子を送信する程度のことであれば,当業者が適宜なし得る事項である。」

第4.当審の判断
1.36条6項1号,および,2号,並びに,同4項1号について
(1)本件手続補正によって,本願の請求項1?請求項4,及び,請求項6?請求項11に記載された内容は,何ら補正されていない。
したがって,本件手続補正によっては,当審拒絶理由は解消していない。

そこで,審判請求人による,平成26年10月28日付けの意見書(以下,単に「意見書」という)によって,当審拒絶理由が解消するかについて検討する。

(2)当審拒絶理由の理由1の「1.36条6項1号,及び,2号について」の(1),及び(3)における,本願の請求項1,及び,請求項4についての指摘に対して,意見書において,
「3.36条6項1号,2号について
(1)本願請求項1の「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」の「単一のメッセージ・グループ」について
本願明細書の段落0024には,「1組の暗号化解除モジュール,例えば単一の公開施設にあるすべての暗号化解除モジュールが,それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。」と記載されております。本願請求項1はその特徴事項を以下のように記載したものです。
「暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップ」
本願明細書の上記記載では「単一のメッセージ・グループ」は,まさに,単一の場所にある複数の暗号化解除モジュールから1組の送信鍵を含む単一のメッセージを意味します。以下に詳細に説明しますように,本願請求項1に記載された鍵管理技術は,「2つのステップ」による暗号化を利用します。すなわち,暗号化解除モジュールが送信鍵をフィーチャ鍵の暗号化のために鍵マネージャに送信します。それから,鍵マネージャはこれらの暗号化されたフィーチャ鍵を暗号化されたコンテンツの暗号化解除を行うそのような鍵を使用する暗号化解除モジュールに送信します。同一の場所にある1組の暗号解除モジュールから鍵マネージャへの送信鍵の送信を容易にするために,本願明細書に記載されていますように,送信鍵を1つのグループで,単一のメッセージとして送信します。
これらのことから,本願請求項1に記載された「単一のメッセージ・グループ」は明確であり,本願請求項1に記載された特許を受けようとする発明は明確であると思料いたします。さらに,本願請求項1に記載された「単一のメッセージ・グループ」は,発明の詳細な説明に記載されたものであると思料いたします。本願請求項4も本願請求項1と同様に明確かつ発明の詳細な説明に記載されたものであると思料いたします。」(以下,これを「引用記載1」という)
と主張すると共に,36条4項1号については,
「4.36条4項1号について
上記2の(1)および(2)において説明しました事項により,本理由は解消したものと思料いたします。」(以下,これを「引用記載2」という)
と主張しているので,前記引用の主張を以下に検討する。

引用記載1において引用され,当審拒絶理由においても引用した,本願明細書の発明の詳細な説明の段落【0024】の,
「1組の暗号化解除モジュール,例えば単一の公開施設にあるすべての暗号化解除モジュールが,それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる」
という記載からは,
“複数の暗号化解除モジュールが,各暗号化解除モジュールのそれぞれの公開鍵を1つのメッセージの中に入れて,鍵管理システム送ることもできる”
ということは,読み取れる。即ち,段落【0024】に記載された内容から読み取れることは,
“メッセージは1つであって,グループではない”
ということである。
通常の語彙の解釈からすれば,「メッセージ・グループ」と表現した場合,“複数のメッセージが集まったもの”と解するのが普通であり,「単一のメッセージ・グループ」と表現した場合は,“複数のメッセージが集まったものが1つ存在する”ことを表現していると解するのが妥当である。
即ち,「単一のメッセージ」と,「単一のメッセージ・グループ」とは,同一のものを意味しないことは明らかである。
この点に関して審判請求人は引用記載1において,
「本願明細書の上記記載では「単一のメッセージ・グループ」は,まさに,単一の場所にある複数の暗号化解除モジュールから1組の送信鍵を含む単一のメッセージを意味します。」
と主張しているが,上記検討のとおり,本願明細書の発明の詳細な説明に記載された内容は,単に,“一つのメッセージ中に複数の鍵を入れる”というものであって,「グループ」に関しては,本願明細書の発明の詳細な説明に何ら記載されていない。
以上のとおりであるから,審判請求人の引用記載1における主張は採用できない。
また,上記で検討したとおり,本願明細書の発明の詳細な説明には,「単一のメッセージ・グループ」に関しての説明が存在していないので,審判請求人の引用記載2における主張も採用できない。

(3)当審拒絶理由の理由1の「1.36条6項1号,及び,2号について」の(4)において,本願の請求項6に関して指摘した事項に対して,意見書において,
「(2)請求項6の「「鍵マネージャ・システムは,少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」について
本願請求項に記載された鍵管理技術では、鍵マネージャと暗号化解除モジュールとが鍵の交換を行います。例えば、暗号化解除モジュールは、この交換を、鍵マネージャに送信鍵を送信することによって開始することができます(すなわち、「プッシュ」アプローチ)。代替的には、鍵マネージャは、暗号化解除モジュールからの送信鍵をリクエストすることができます(「プル」アプローチ)。鍵マネージャが送信鍵の受信を開始すると、鍵マネージャは、特定の暗号化解除モジュールに知られている固有識別子を送信して、鍵マネージャがこの対応する暗号化解除モジュールと受信した送信鍵とを関連付けできるようにします。このように、本願明細書の段落0015の「鍵マネージャが交換を開始する場合は、鍵マネージャ・システムは通常、少なくとも1つの予想される暗号化解除受信側の固有識別子を、各暗号化解除モジュールに送ることになる。」の記載では、このような固有識別子を送信する目的が明確に記載されているものと思料いたします。」(以下,これを「引用記載3」という)
と主張しているので,引用記載3における主張を以下に検討する。

当審拒絶理由において指摘したとおり,本願の請求項6に記載された,
「鍵マネージャ・システムは,少なくとも1つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る」,
における「暗号化解除受信側」と,「暗号化解除モジュール」との関係は,上記(1)において指摘したとおり,本件手続補正において,本願の請求項6が何ら補正されていないため,本願の請求項6に記載された内容,及び,若干の補正を含む本願の請求項5を加えた,本願の請求項1?請求項5,及び,請求項7?請求項11に記載された内容を加味しても,依然として不明である。
本願明細書の発明の詳細な説明においても,当審拒絶理由において引用した段落【0015】に,
「鍵マネージャが交換を開始する場合は,鍵マネージャ・システムは通常,少なくとも1つの予想される暗号化解除受信側の固有識別子を,各暗号化解除モジュールに送ることになる」,
という記載があるのみであって,「暗号解除受信側」については,本願明細書の発明の詳細な説明の段落【0015】以外に記載が存在しない。
したがって,本願明細書の発明の詳細な説明に記載された内容を考慮しても,「暗号解除受信側」と,「暗号化解除モジュール」との関係は,依然として不明である。
この点に関して,引用記載3における審判請求人の主張は,
「本願請求項に記載された鍵管理技術では、鍵マネージャと暗号化解除モジュールとが鍵の交換を行います。例えば、暗号化解除モジュールは、この交換を、鍵マネージャに送信鍵を送信することによって開始することができます(すなわち、「プッシュ」アプローチ)。代替的には、鍵マネージャは、暗号化解除モジュールからの送信鍵をリクエストすることができます(「プル」アプローチ)。鍵マネージャが送信鍵の受信を開始すると、鍵マネージャは、特定の暗号化解除モジュールに知られている固有識別子を送信して、鍵マネージャがこの対応する暗号化解除モジュールと受信した送信鍵とを関連付けできるようにします。」
であるが,該主張内容は,本願明細書の発明の詳細な説明に記載された内容に基づくものではなく,また,当該技術分野において周知の技術事項といえるものでもない。
加えて,上記引用の審判請求人の主張点においては,「暗号解除受信側」については,一切言及していない。即ち,上記主張点における「特定の暗号化解除モジュールに知られている固有識別子」において,唐突に「固有識別子」が説明中に出現し,該「固有識別子」が,何の「固有識別子」であるのかについては,何ら説明されていない。
したがって,引用記載3における,本願明細書の発明の詳細な説明に記載された内容に基づかない説明を考慮しても,「暗号解除受信側」と,「暗号化解除モジュール」との関係が,依然として不明であり,当審拒絶理由の1の「1.36条6項1号,及び,2号について」の(4)において,
「何のために「少なくとも1つの予想される暗号化解除受信側の固有識別子」を送信するのか不明である」,
と指摘した事項は,依然として解消していない。

以上(1)?(3)において検討したとおりであるから,本件手続補正,及び,意見書の内容を考慮しても,本願の請求項1,請求項4に係る発明は,依然として,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確でなく。
したがって,本願の請求項1を引用する本願の請求項2,及び,請求項3に係る発明,並びに,本願の請求項4を引用する本願の請求項5?請求項11に係る発明は,依然として,本願明細書の発明の詳細な説明に記載されたものではなく,かつ,明確でない。
そして,本願明細書の発明の詳細な説明は,依然として,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

2.29条2項について
(1)本願発明
上記「1.36条6項1号,および,2号,並びに,同4項1号について」において検討したとおり,本願発明は,本願明細書の発明の詳細な説明に記載されたものでなく,本願発明は,明確ではないが,一応,上記において,本願の請求項1として引用した記載のとおりものであるとして,以下の検討を行う。

(2)引用刊行物に記載の発明
当審拒絶理由において,引用刊行物1として引用した国際公開第2004/084035号(2004年9月30日公開)には,上記引用の当審拒絶理由において検討したとおりの次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「分配部において,複数の標的のセキュア・プレーヤから,該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し,それぞれの公開鍵を用いて,暗号化されたコンテンツに関連するスクリーナ鍵を暗号化し,
前記それぞれの公開鍵で暗号化したスクリーナ鍵を,ネットワークを介して,それぞれの公開鍵に対応する,前記複数の標的のセキュア・プレーヤのそれぞれに送信する,方法。」

(3)本願発明と引用発明との対比
本願発明は,本件手続補正によって補正が行われていないので,本願発明と,引用発明との一致点,及び,相違点は,上記引用の当審拒絶理由において検討した,次のとおりものである。

[一致点]
暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから受け取った複数の送信鍵のそれぞれで,暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して,複数の保護されたフィーチャ鍵を生成するステップと,
前記複数の保護されたフィーチャ鍵のうちの別々の1つを前記複数の暗号化解除モジュールのうちの対応する1つに供給して,前記暗号化済みコンテンツの暗号化解除を可能にするステップと,を含む鍵管理方法。

[相違点]
“対応する複数の暗号化解除モジュールから受け取った複数の送信鍵”に関して,
本願発明においては,「対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」であるのに対して,
引用発明においては,“複数の公開鍵”を,“単一のメッセージ・グループとして受け取る”点については,言及されていない点。

(4)相違点に対する当審の判断
当審拒絶理由において指摘したとおり,本願明細書の発明の詳細な説明には,上記相違点に相当する構成は記載されておらず,また,該構成を示唆する記載も存在しない。
そこで,上記相違点を,当審拒絶理由,及び,上記「1.36条6項1号,および,2号,並びに,同4項1号について」において指摘した,本願明細書の発明の詳細な説明の段落【0024】に記載された事項を踏まえて,
“対応する複数の暗号化解除モジュールから単一のメッセージとして受け取った複数の送信鍵”
と読み替えて,以下に検討する。

“対応する複数の暗号化解除モジュールから単一のメッセージとして受け取った複数の送信鍵”
という構成において,「送信鍵」とは,「公開鍵」であって,上記読み替えた相違点は,
“複数の公開鍵を1つのメッセージとして受け取る”
という構成を意味するものであることは明らかである。
そして,上記相違点については,当審拒絶理由において,周知文献として引用した,特開2003-318873号公報(2003年11月7日公開)に,当審拒絶理由おいてD.として引用した,

「【0181】また,本発明によれば,電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に,これらの複数の公開鍵を一括して通信相手に送信するので,公開鍵送信のための処理と通信負荷を軽減することが可能となる。」

という記載が存在しているように,必要に応じて,
「複数の公開鍵を一括して送信相手に送信する」
ことは,本願の第1国出願前に,当業者には周知の技術事項であり,“一括して送信する”形態として,“1つのメッセージに含ませて送る”ことも,当審拒絶理由に,“電子メール(メッセージの相当)に複数の添付ファイルを附加することが周知である”としたとおりであるから,引用発明において,複数の公開鍵を,本願の第1国出願前に周知である技術事項を用いて,1つのメッセージにまとめて送信するよう構成することは,当業者が適宜なし得る事項である。

よって,相違点は,格別のものではない。

(5)ここで,審判請求人は,意見書において,本願発明と,引用発明との一致点,及び,相違点に関して,

「引用文献1には,本願発明の「暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから・・・送信鍵を受け取る」点は記載も示唆もされておりません(以下,「第1の相違点」と称します。)。さらに,「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」点も記載も示唆もされておりません(以下,「第2の相違点」と称します。)。
さらに,引用文献1では「単一のステップ」による暗号化システムについて記載しているのに対して,本願発明では「2つのステップ」による方法を特定しております。
(ii)第1の相違点について
拒絶理由では上記第1の相違点である「暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから・・・送信鍵を受け取る」点に関係する事項として,10頁12?15行に「引用刊行物1に記載された発明は,“分配部106は,標的のセキュア・プレーヤに固有の公開鍵を用いて,スクリーナ鍵を暗号化し,該暗号化されたスクリーナ鍵を,ネットワークを介して,ユーザ114に配信する”態様を含むことは明らかである。」と認定されております。そして,その認定された部分を「“分配部106は,複数の標的のセキュア・プレーヤから,該複数の標的のセキュア・プレーヤのそれぞれに固有の公開鍵を受信し,・・・」と読み取られております(10頁21行?22行)。上記ご認定からこの読み取られた事項から導かれる根拠は,10頁16行?19行に記載の下記の事項では明らかにされていないものと思料いたします。
「ここで,「ユーザ114」とは,「標的のセキュア・プレーヤ」を有する“者”
であることは明らかであって,上記Cにおいて指摘した事項から,該「ユーザ」
は複数存在しているので,該複数の「ユーザ」が,それぞれ有する,「標的のセ
キュア・プレーヤ」も複数存在することは明らかである」
このことから,上記第1の相違点は引用文献1に記載も示唆もされていないものと思料いたします。
(iii)第2の相違点について
拒絶理由では上記第2の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点に関係する事項として,「ウ.相違点についての当審の判断」として,「単一の送信元が,複数の情報を単一のメッセージに含ませて,受信側に向けて,送信するようなことは,例えば,一つの電子メールに複数の添付ファイルを添付して送信するといった手法が存在しているように,当業者には周知の技術事項」と判断され,さらに,「複数の公開鍵を一括して送信するようなことも,・・・(周知文献に)[0181」また,本発明によれば,電子署名と暗号用で別々の公開鍵を使うなど送信元が複数の公開鍵を有する場合に,これらの複数の公開鍵を一括して通信相手に送信するので,公開鍵送信のための処理と通信負荷を軽減することが可能となる。」などと記載されてもいるように,本願の第1国出願前に,当業者には周知の技術事項であ」ると判断されております。
しかしながら,このご判断は,第2の相違点の「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係が考慮されておらず,単なる2者の間の関係ととらえられているようです。さらに,このご判断は,第2の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点を過度に分断して判断されており,第2の相違点全体の意義を考慮して判断されてはいないものと思料いたします。」

と主張しているので,上記主張点について,以下に検討しておく。

ア.審判請求人の主張する相違点1について
当審拒絶理由において,A.として引用した記載にあるとおり,「ユーザ」は,原文では「user(s)」と記載されていて,引用刊行物1が,“ユーザが複数存在する”態様を含むことが明記されている。そして,同じくC.として引用したFig.1には,「ユーザ」が,「1?N」のN人,或いは,N台存在する態様が明記され,「分配部106」から,「スクリーナ鍵モジュール」の1?Nまでが,それぞれ「ユーザ」の1?Nに送られている態様が明記されている。そして,同じくB.として引用した記載に,「スクリーナ鍵」が,「セキュア・プレーヤ」に対応する「公開鍵」によって暗号化されることが明記されている。そして,「セキュア・プレーヤ」は,当審拒絶理由において指摘したとおり「ユーザ」側に存在するものである。
以上のことから,以上のことから,「スクリーナ鍵モジュール」を,「ユーザ」,或いは,「セキュア・プレーヤ」に配布する「分配部106」は,1?Nの「ユーザ」,或いは,「セキュア・プレーヤ」の公開鍵を有していることは明らかである。
このことから,引用刊行物1に明文の記載はないものの,「配布部106」が,「スクリーナ鍵」を,各「セキュア・プレーヤ」に,各「セキュア・プレーヤ」の「公開鍵」を用いて送信する前段のステップとして,「配布部106」が,各「セキュア・プレーヤ」の「公開鍵」を取得するステップが存在することは明らかである。
したがって,審判請求人の主張する相違点1のうちの“複数の送信鍵を受け取る”点,及び,2つのステップを有する点は,引用刊行物1に記載された内容からも読み取れる事項である。
そして,“複数の送信鍵を受け取る”態様として,“複数の送信鍵を一纏めにして受信する”点については,当審拒絶理由においてD.として引用した周知文献の記載にもあるとおり,本願の第1国出願前に,当業者は周知の技術事項であるから,引用発明においても,“各セキュア・プレーヤの公開鍵を受け取る態様として,各セキュア・プレーヤの公開鍵を1つのメッセージとして受信する”よう構成することは,上記「(4)相違点に対する当審の判断」において検討したとおり,当業者が適宜なし得る事項である。

イ.審判請求人の主張する相違点2について
審判請求人の主張する相違点2に関して,審判請求人は,上記引用の意見書において,
当審拒絶理由において“一括して受信することは周知技術である”として点に対して,
「このご判断は,第2の相違点の「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係が考慮されておらず,単なる2者の間の関係ととらえられているようです。さらに,このご判断は,第2の相違点である「「複数の送信鍵」を「対応する複数の暗号化解除モジュールから単一のメッセージ・グループ」として「鍵マネージャ」が「受け取る」」点を過度に分断して判断されており,第2の相違点全体の意義を考慮して判断されてはいないもの」である旨主張しているが,
該主張における「「対応する複数の暗号化解除モジュール」と「鍵マネージャ」との関係」について,具体的に説明されておらず,本願の請求項1には,単に,
「暗号化を実施する鍵マネージャにおいて,対応する複数の暗号化解除モジュールから単一のメッセージ・グループとして受け取った複数の送信鍵」,
と記載されているのみであるから,上記引用の請求項1からは,高々,“送信鍵を送信する暗号化解除モジュール”と,“暗号化解除モジュールの送信する送信鍵を受信する鍵マネージャ”が存在することが,読み取れる程度であり,「暗号化解除モジュール」と,「鍵マネージャ」との間の,本願の請求項1に係る発明に特有の関係などは,一切読み取れない。

以上ア.,及び,イ.において検討したとおりであるから,29条2項に関する意見書における主張は,拒絶理由の解消するに足る内容を有していないので,採用することは出来ない。

よって,本願の請求項1に係る発明は,本件手続補正,及び,意見書の内容を考慮しても,依然として,引用発明,及び,周知技術から,当業者が容易に構築し得るものであり,本願発明の構成によってもたらされる効果も,引用例記載の発明から当業者ならば容易に予測することができる程度のものであって,格別のものとはいえない。

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

よって,結論のとおり審決する。
 
審理終結日 2014-12-25 
結審通知日 2015-01-07 
審決日 2015-01-26 
出願番号 特願2007-555104(P2007-555104)
審決分類 P 1 8・ 537- WZ (H04L)
P 1 8・ 121- WZ (H04L)
P 1 8・ 536- WZ (H04L)
最終処分 不成立  
前審関与審査官 青木 重徳  
特許庁審判長 山崎 達也
特許庁審判官 石井 茂和
小林 大介
発明の名称 ディジタル映画のための鍵管理システム  
代理人 木越 力  
代理人 吹田 礼子  
代理人 石井 たかし  
代理人 倉持 誠  

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