【事件の表示】
　特願２０００−１３５０６９「エンドユーザに対してアクセス制限することができるプログラムを送信する方法、暗号化されたプログラムをデコードする方法」拒絶査定不服審判事件〔平成１３年　２月　９日出願公開、特開２００１−　３６５１７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年５月８日（パリ条約による優先権主張１９９９年５月７日、米国）を出願日とする出願であって、出願後の手続きの経緯は次のとおりである。
拒絶理由通知　　　　　　平成１７年６月１日
意見書、手続補正書　　　平成１７年８月２６日
拒絶査定（起案）　　　　平成１８年３月３日
拒絶査定（送達日）　　　平成１８年３月８日
審判請求　　　　　　　　平成１８年６月５日
補正書　　　　　　　　　平成１８年６月２３日
拒絶理由通知　　　　　　平成２１年５月２６日
意見書、手続補正書　　　平成２１年１１月２７日
上申書　　　　　　　　　平成２１年１２月２５日
　
２．本願特許請求の範囲の記載
　本願特許請求の範囲の記載は、平成２１年１１月２７日付け手続補正書により補正されたとおりの次の事項により特定されるものである。
　
「【請求項１】　エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、
　（Ｂ）少なくとも１つのマスターキーを定めるステップと、
　（Ｃ）前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つのハッシュ関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、
　（Ｄ）暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。
　
　　【請求項２】　前記プログラム識別子はｎビットからなり、
　前記プログラム識別子の対応するビット値に従って、前記プログラム識別子のｎビットの位置それぞれに前記ハッシュ関数の１つが適用されることを特徴とする請求項１記載の方法。
　
　　【請求項３】　（Ｅ）前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有することを特徴とする請求項１記載の方法。
　
　　【請求項４】　前記エンタイトルメント情報には、前記エンドユーザにより得たプログラムのセットに基づくキーツリーの一部を含むことを特徴とする請求項３記載の方法。
　
　　【請求項５】　前記エンドユーザは、前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いることを特徴とする請求項３記載の方法。
　
　　【請求項６】　前記プログラム識別子は前記暗号化プログラムの送信とともにインターリーブされることを特徴とする請求項１記載の方法。
　　【請求項７】　前記プログラム識別子は、制御チャネル上で送信されることを特徴とする請求項１記載の方法。
　
　　【請求項８】　複数のエンドユーザにプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）２ビットもしくはそれより多くのビットから成るプログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップと、
　（Ｂ）暗号化したプログラムおよび前記プログラム識別子を前記エンドユーザに送信するステップと、を実行することを特徴とする方法。
　
　　【請求項９】　少なくとも１つのプログラムパッケージに対応するプログラムを複数のエンドユーザに送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）前記エンドユーザにより得たプログラムパッケージに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップと、
　（Ｂ）２ビットもしくはそれより多くのビットから成るプログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップと、
　（Ｃ）暗号化されたプログラムとともに前記プログラム識別子を前記エンドユーザに送信するステップであって、前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっているステップと、を実行することを特徴とする方法。
　
　　【請求項１０】　暗号化されたプログラムをデコードするための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）前記プログラムのプロバイダーから顧客が得たプログラムのセットに基づいてキーツリーから少なくとも１つの中間キーを含むエンタイトルメント情報を受信するステップと、
　（Ｂ）プログラムキーで暗号化された暗号化プログラムと、２ビットもしくはそれより多くのビットから成るプログラム識別子とを受信するステップと、
　（Ｃ）前記プログラム識別子及び前記キーツリーの部分から前記プログラムキーを得るステップと、
　（Ｄ）前記プログラムキーおよびプロセッサを用いて前記暗号化プログラムを解読するステップと、を実行することを特徴とする方法。
　
　　【請求項１１】　前記プログラム識別子はｎビットからなり、
　マスターキーは前記キーツリーのルートに配置され、前記キーツリーは、ｎのツリーレベルが作られるまで前記キーツリーの各ノードにハッシュ関数を適用することにより前記キーツリーが生成されることを特徴とする請求項１０記載の方法。
　
　　【請求項１２】　暗号化されたプログラムをデコードするための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）前記プログラムのプロバイダーから、顧客が得るプログラムのセットに基づくキーツリーから少なくとも１つの中間キーを含むエンタイトルメント情報を受信するステップと、
　（Ｂ）プログラムキーで暗号化された暗号化プログラムと、２ビットもしくはそれより多くのビットから成るプログラム識別子とを受信するステップと、
　（Ｃ）前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記中間キーにハッシュ関数を回帰的に適用することにより前記プログラム識別子及び前記中間キーから前記プログラムキーを得るステップと、
　（Ｄ）前記プログラムキーを用いて前記暗号化プログラムを解読するステップと、を実行することを特徴とする方法。
　
　　【請求項１３】　前記プログラム識別子はｎビットからなり、
　前記中間キーは前記キーツリーのレベルｒにおける中間ノードに対応し、前記ハッシュ関数は前記中間キーにｎ−ｒ回適用されることを特徴とする請求項１２記載の方法。
　
　　【請求項１４】　エンドユーザに対して、アクセスを制限したプログラムを送信するシステムであって、
　（Ａ）２ビットもしくはそれより多くのビットから成るマスターキーとコンピュータ読みとり可能コードを記憶するメモリーと、
　（Ｂ）前記メモリーに動作的につながったプロセッサとを有し、このプロセッサが、
　　（ａ）バイナリ値を有するプログラム識別子を前記プログラムに割り当て、
　　（ｂ）少なくとも１つのマスターキーを定め、
　　（ｃ）前記プログラム識別子のバイナリ値に基づいて前記マスターキーに少なくとも１つのハッシュ関数を適用することによりプログラムキーを用いて前記プログラムを暗号化し、
　　（ｄ）前記プログラム識別子とともに暗号化プログラムを前記エンドユーザに送信するように構成することを特徴とするシステム。
　
　　【請求項１５】　エンドユーザーに対して、アクセスを制限したプログラムを送信するシステムであって、
　（Ａ）コンピュータ読み取り可能コードを記憶するメモリーと、
　（Ｂ）前記メモリーに動作上つながったプロセッサーとを有し、
　前記プロセッサーは、
　　（ａ）２ビットもしくはそれより多くのビットから成るプログラム識別子の各ビット位置のバイナリー値に基づいてマスターキーにハッシュ関数を回帰的に適用することによって得られるプログラムキーを用いて、該プログラム識別子を有する該プログラムを暗号化し、
　　（ｂ）前記エンドユーザーに暗号化された該プログラムおよび前記プログラム識別子を送信するように構成することを特徴とするシステム。
　
　　【請求項１６】　暗号化されたプログラムをデコードするシステムであって、
　（Ａ）マスターキーおよびコンピュータ読み取り可能コードを記憶するメモリーと、
　（Ｂ）前記メモリーに動作上つながったプロセッサーとを有し、
　前記プロセッサーは、
　　（ａ）前記顧客によって得られるプログラムのセットに基づくキーツリーの部分を含むエンタイトルメント情報を該プログラムのプロバイダーから受信し、
　　（ｂ）プログラムキーによって暗号化された暗号化プログラム、および２ビットもしくはそれより多くのビットから成るプログラム識別子を受信し、
　　（ｃ）前記プログラム識別子および前記キーツリーの記憶された前記部分から前記プログラムキーを得て、
　　（ｄ）前記プログラムキーを用いて前記暗号化プログラムを解読するように構成することを特徴とするシステム。
　
　　【請求項１７】　プログラムを記録するコンピュータ読み取り可能記録媒体であって、前記コンピュータに
　　（ａ）２ビットもしくはそれより多くのビットから成るバイナリー値を有するプログラム識別子をプログラムに割り当てるステップと、
　　（ｂ）少なくても一つのマスターキーを定めるステップと、
　　（ｃ）前記プログラム識別子の各ビット位置のバイナリー値に基づいて前記マスターキーに少なくとも一つのハッシュ関数を適用することによって得られるプログラムキーを用いて、該プログラムを暗号化するステップと、
P.4
　　（ｄ）前記プログラム識別子とともに暗号化された該プログラムをエンドユーザーに送信するステップと、を実行させることを特徴とするコンピュータ読み取り可能記録媒体。
　
　　【請求項１８】　プログラムを記録するコンピュータ読み取り可能記録媒体であって、前記コンピュータに
　　（ａ）前記顧客によって得られるプログラムのセットに基づくキーツリーの部分を含むエンタイトルメント情報を該プログラムのプロバイダーから受信するステップと、
　　（ｂ）プログラムキーによって暗号化される暗号化プログラム、および２ビットもしくはそれより多くのビットから成るプログラム識別子を受信するステップと、
　　（ｃ）前記プログラム識別子および前記キーツリーの前記部分から前記プログラムキーを得るステップと、
　　（ｄ）前記プログラムキーを用いて前記暗号化プログラムを解読するステップと、を実行させることを特徴とするコンピュータ読み取り可能記録媒体。」
　
３．当審の拒絶の理由の概要は次のとおりである。
　
「一．この出願の請求項１乃至請求項１８に係る発明は、その出願前（優先権主張日；１９９９年５月７日）に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　記　　
刊行物１；欧州特許出願公開第８９９９５６号明細書（本件と同一出願人に係る出願の明細書；公開日，１９９９年３月３日）（パテントファミリーである特開平１１−１５５１３８号公報を参照した。）
刊行物２；特開平５−３４７６１６号公報
刊行物３；特開平１１−８８３２２号公報
　
　刊行物１には、ＦＩＧ．２に示された、ＨＥＡＤ　ＥＮＤ（ヘッドエンド）において遂行される方法が、ＦＩＧ．８ａ，ＦＩＧ．９から読み取れる。
ア．ＦＩＧ．９のステップ９２０の番組識別子ｐは、通常、１、０のデータで表されるので、「バイナリ値を有するプログラム識別子」といえるとともに、番組識別子は番組に対応して割り当てられることは自明。
イ．ＦＩＧ．２のマスタ鍵マトリックスＭ２４０は、「少なくとも１つのマスターキー」に対応する。
ウ．ＦＩＧ．９のステップ９３０のＫｐ＝Ｍ・ｐについては、番組識別子ｐのビット位置の１，０に基づいてかけ算され、このかけ算をすることは、ハッシュ関数とまではいえないまでも、上位概念では、少なくとも１つの関数を適用することであるから、Ｋｐ＝Ｍ・ｐは、番組識別子ｐの各ビット位置のバイナリ値に基づいてマスタ鍵マトリックスＭに少なくとも１つの関数を適用することにより番組鍵Ｋｐが得られることを示している。
　また、ステップ９４０には、該番組鍵Ｋｐで番組を暗号化するステップが示されている。前記番組鍵Ｋｐは「プログラムキー」に対応する。
エ．ＦＩＧ．９のステップ９５０には、暗号化された番組を番組識別子ｐとともに（エンドユーザに）送信することが示されている。
　
　ア．〜エ．をふまえると、刊行物１には、次の発明が示されている。
　
　エンドユーザに対してアクセス制限することができるプログラム（番組）を送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　バイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、
　少なくとも１つのマスターキーを定めるステップと、
　前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、
　暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。
　
　刊行物２には、次の事項が記載されている。
「【００４４】図３は、メモリ１０４に格納されているグループ鍵生成プログラム１の動作を説明するためのフローチャートを示す。…（中略）…ステップ３０３で該通信宛先情報に事業所識別番号118と個人識別番号１１９が同時に含まれるかどうかを検査する。…（中略）…そして、ステップ３０５で該宛先通信情報と該マスタ鍵を使ってハッシュトータルを計算する。すなわち、ハッシュトータル←Ｈ（マスタ鍵，宛先通信情報）
とする。ここに、Ｈ(Ｋ，Ｍ)はハッシュ関数であり、…（中略）…このハッシュトータルがグループ鍵として用いられる。」
　
　刊行物３には、次の事項が記載されている。
「【００７９】図２（１）に示すように、個人情報管理配列２０ａは、ユーザの「ＩＤ」と、「登録動的署名データ」と、「鍵ハッシュ値」とを格納している配列である。この「鍵ハッシュ値」とは秘密鍵を、所定のハッシュ関数でハッシュ値に変換したものであり、このハッシュ値は、後述する暗号鍵管理配列２０ｂにおいて利用される。」
　
本願請求項１の発明（以下、「請求項１の発明」という。）について
　刊行物１の発明と請求項１の発明とを対比すると、次の相違点が認められるが、その余の事項を有する発明である点で差異はない。
〈相違点〉プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも１つの関数が、請求項１の発明は、ハッシュ関数であるのに対し、刊行物１の発明は、かけ算の関数である点。
　
当審判断
　マスターキーに適用する、少なくとも１つの関数が、ハッシュ関数であることは、本願優先権主張日前に周知の技術的事項にすぎない。例えば、刊行物２には、マスタ鍵にハッシュ関数を適用すること、この適用で得られた鍵をグループ鍵として用いることが記載されており、刊行物３にも、秘密鍵を、所定のハッシュ関数でハッシュ値に変換することが記載されている。
　刊行物１の発明において、プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも１つの関数を、ハッシュ関数とすることは、前記周知の技術的事項を参酌することにより当業者が容易になし得ることである。
　
　二．この出願は、特許請求の範囲及び発明の詳細な説明の記載が下記の点で、特許法第３６条第４項及び第６項第１号、第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
（１）請求項１について
ア．請求項１には、送信側とエンドユーザ側とで何をするのかという前提事項が記載されておらず、また、エンドユーザ側に、単に、暗号化したプログラムとプログラム識別子を送るだけで、送られたデータをどのように用いるか記載されていないので、これらが発明特定事項として何ができるためにあるのか明確でない。
　特にエンドユーザ側は、暗号化したプログラムとプログラム識別子を送られただけではマスターキーｍに関連した情報は得られていない（発明特定事項にない。）ので、プログラムキーは生成できず、暗号化したプログラムの復号もできないことは明らかである。請求項１に記載された一部の事項で何をしようとしているのか、請求項１の発明の技術的思想も不明である。
　少なくとも、事前にエンドユーザにキー値ＫＩを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図９のステップ９６０から明らかである。
イ．請求項１は、「少なくとも１つのハッシュ関数」、即ち、１つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。
　
（２）請求項２には、「プログラム識別子のｎビットの位置それぞれに前記ハッシュ関数の１つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。文字通り解して、ビットの位置それぞれに前記ハッシュ関数の１つが適用されることは、発明の詳細な説明の具体的にどこに記載されているのか不明である。例えば、図８のステップ８３０の計算は、位置それぞれにハッシュ関数を適用するものではない。
　
（３）請求項３の「（Ｅ）前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を指すのか明確でなく、また、（Ｅ）のステップの順序が（Ａ）〜（Ｄ）のあとに「さらに有する」ことは、何のための事項なのか意味不明である。
　エンタイトルメント情報は、（１）で言及したように、最初の方の順序でエンドユーザが有していることが前提であり、この情報がなければプログラムキーが生成できないことは図９のステップ９６０から明らかである。
　
（４）請求項４、請求項３の「エンドユーザにより得た」は、発明の詳細な説明との対応が不明である（図７のどのステップが対応するのか？）。
　
（５）請求項４の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でない。キーツリーとして、マスターキーをキーツリーのルートの位置に配置され、中間キーのノード、プログラムキーのリーフノードを有するキーツリーが図２に示されてはいるが、キーツリーに図６のノードが関連するとしても、ノードのみではキーツリーではない。
　
（６）請求項３を引用する請求項５に関し、請求項１〜３は送信するための、つまり送信する側におけるステップにおけるものであるのに対し、請求項５は請求項３記載の方法であるにも関わらず、エンドユーザの側の、デコードのプロセスに係るところの「前記エンドユーザは、前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」を特徴としており、送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。
　
（７）請求項８は、（１）で言及したことと同様のことがいえる。
　請求項８の「（Ａ）プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、が記載されていると認められるが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明である。
　
（８）請求項９は、（１）で言及したことと同様のことがいえる。
　請求項９の（Ｂ）の事項については、請求項８で言及したことと同様のことがいえる。
　請求項９の（Ｃ）の事項における「暗号化されたプログラムとともに前記プログラム識別子を前記エンドユーザに送信するステップであって、前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は、これらステップのうち「エンドユーザが前記プログラムの正当ユーザであれば、前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は実質的にエンドユーザ側におけるデコードに係るステップであって送信する側の送信するステップに含まれないから、（Ｃ）の事項は不明確な記載である。
　
（９）請求項１０における「前記顧客」における「前記」が請求項１０の何を指すのか不明である。
請求項１０は、「キーツリー」の構成、「キーツリーの部分」（プログラムのセット、ノード、キー値（中間キー）、部分プログラム識別子、マスター鍵との関係）が不明であるので、プログラムキーを得るステップが不明確である。また、「中間キーを含むエンタイトルメント情報を受信する」と記載されているが、前記エンタイトルメント情報を何のためにどのように用いるのか記載されていないので、発明特定事項としての意義が不明であり、前記情報や中間キーと「キーツリーの部分」との関係も不明である。
　
（１０）請求項１１には、「各ノードにハッシュ関数を適用する」と記載されているが、ノードの何にハッシュ関数を適用するのか不明確である（ルートに位置するマスターキーのノードとキーツリーの他の中間キーのノードとの関係が不明である。）。また、「各ノードにハッシュ関数を適用することにより前記キーツリーが生成されること」は、プログラム識別子のバイナリ値に基づくことが記載されておらず、これではＨ0とＨ1のハッシュ関数を適用するものしか開示のない発明の詳細な説明とは対応せず不明確である。
　（１１）請求項１４、１５はカテゴリーがシステムの発明に係るが、請求項１で言及したことと同様のことがいえる。送信したものを何に用いるのか記載されていないので、何のための特定事項であるのか技術的意義が不明である。
　
（１２）請求項１６は、（ｃ）の「プログラムキーを得」るステップが、キーツリーの部分、エンタイトルメント情報、プログラム識別子をどの様に用いて得るのか不明確である。
　
（１３）請求項１７及び１８は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている（記録媒体自体が、コンピュータに対して命令するようなもの）が、対応する記録媒体は、発明の詳細な説明には記載がない。
　
（１４）請求項１７は、カテゴリーが記録媒体の発明に係るが、実質的には送信に係り、請求項１で言及したことと同様のことがいえる。
　また、請求項１８は、カテゴリーが記録媒体の発明に係るが、実質的には解読（デコード）に係り、請求項１０で言及したことと同様のことがいえる。
　
（１５）請求項１６は、「暗号化されたプログラムをデコードするシステム」であるにも関わらず、プロバイダー側しか有しない「（Ａ）マスターキー・・・を有し、」ている。
　これでは、受信したエンタイトルメント情報、プログラム識別子を用いてプログラムキーを自在に生成でき（図９のステップ９６０参照）、正規の顧客でなくてもプログラムを視聴できることになり、本願発明の解決課題が達成されない。
　発明の詳細な説明には、請求項１６の特定事項を有する発明の具体的な態様は示されておらず、解決課題がどのように解決されるのか不明であり、当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとは認められず、その技術上の意義を理解するために必要な事項も十分に記載されているとは認められない。」
　
４．当審拒絶理由に対する意見、上申の概要
４．１　意見の概要
「（１）本件出願は、本願発明が、欧州特許出願公開第８９９９５６号明細書（引用例１）、特開平５−３４７６１６号公報（引用例２）および特開平１１−８８３２２号公報（引用例３）に記載された発明に基づいて、当業者が容易になし得たとして、特許法第２９条第２項の規定により、ならびに明細書の記載が不備と認められるから、特許法第３６条第４項および第６項の規定により、それぞれ特許を受けることができないとする旨の平成２１年５月２６日付け拒絶理由通知に接しました。
（２）これに対して、本願発明の構成をより明確に特定するために、本日別途提出する手続補正書により特許請求の範囲の記載を補正しております。
（３）Ａ．本願発明の進歩性について
　今回の拒絶理由通知において、
…（中略）…
　しかしながら、出願人としては、拒絶理由通知における上記技術認定および所見には同意致しかねるものであります。
　プログラムの暗号化は、成熟した技術であるから、プログラム識別子の各ビット位置のバイナリ値に基づいてハッシュ関数を繰り返し適用する暗号化技術の手法が従来技術に存在しないということは、この技術手法が当業者にとって自明ではないという十分な証拠になり得るものと考えます。したがって、拒絶理由通知における（本願発明に対する）拒絶の判断にもかかわらず、バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理は全く新規なものであり、当業者により容易になし得るものではないと考えます。
　したがって、本願発明は、引用例１−３に記載の発明に対して進歩性を有するものである、と確信致します。
　
Ｂ．記載不備について
（ａ）
（ｉ）拒絶理由通知における理由２の記（１）において、「請求項１には、送信側とエンドユーザ側とで何をするのかという前提事項が記載されていない。」との指摘がなされております。
　しかしながら、請求項１は、エンドユーザに対して、アクセス制限したプログラムを送信するための方法を指向するものであることに注意すべきであります。よって、請求項１に記載される処理ステップは、明らかに送信側によって遂行されるものであり、このことは請求項１の記載において自明であると思料致します。
　また、拒絶理由通知において、「エンドユーザに送られた暗号化したプログラムとプログラム識別子がどのように用いられるかが請求項１に記載されていないため、何をしようとしているのか不明である」との指摘がなされております。
　この点について、上述したように、請求項１に記載の処理ステップは送信側により行われるものであり、請求項１はエンドユーザ側により行われる処理を指向するものではありません。さらに、「エンドユーザ側は、暗号化したプログラムとプログラム識別子を送られただけではマスターキーｍに関連した情報は得られていないので、請求項１に記載された一部の事項で何をしようとしているのか、請求項１の発明の技術的思想も不明である。」との指摘がなされております。
　しかしながら、上述したように請求項１は、エンドユーザに対して、アクセス制限したプログラムを遂行するための方法を指向するものであることに注意すべきであります。マスターキーｎなどの他の情報の送信は、本願発明の技術的範囲外のものであります。また、「少なくとも、事前にエンドユーザにキー値ＫＩを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図９のステップ９６０から明らかである。」との指摘がなされておりますが、請求項１は請求項１に記載の発明の技術的範囲外にある他の処理ステップが行われることを制限するものではない、という点に注意すべきであります。
（ｉｉ）「請求項１は、１つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。」との指摘に対応して、「２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いることを要件とするよう、（請求項１を含む）独立請求項の各々を補正致しました。
　
［拒絶理由における理由２．の記（２）ないし（１５）に対しては、指摘の記載不備に対する釈明を追って近日中に「上申書」を介してご提示申し上げる所存であります。」
　
４．２　上申の概要
「（ｂ）同、理由２の記（２）において、『請求項２には、「プログラム識別子のｎビットの位置それぞれに前記ハッシュ関数の１つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。』との指摘がなされております。
　この点に関し、本願明細書の段落【００１３】には、次のような事柄が記載されております。
『例として、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数Ｈ0またはＨ1を回帰的に適用することによってプログラムキーｋpを得ることができる。従って、もしプログラム識別子ｐがｍビットからなるのであれば、ハッシュ関数Ｈ0またはＨ1の一方がプログラム識別子ｐの対応するビット値に従ってプログラム識別子ｐのｎのビット位置それぞれに対して適用される。最初には、ハッシュ関数Ｈ0またはＨ1の一方がプログラム識別子ｐの最左桁ビットのバイナリー値に従ってマスターキーに適用される。その後で、残りの（ｎ−１）ビット位置それぞれに対し、対応するビットのバイナリ値に従って、前のハッシュ演算の結果にハッシュ関数Ｈ0またはＨ1の一方が適用される。プログラムキーｋpの計算は以下のように表すことができる。
　【数１】
』上記記載事項を考慮すれば、「ハッシュ関数の１つが、プログラム識別子のｎビットの位置のそれぞれに適用される」ということの技術的意味は、当業者にはよく理解できることであります。
（ｃ）同、理由２の記（３）において、『請求項３の「（Ｅ）前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を意味するのか明確でなく、また、（Ｅ）のステップの順序が（Ａ）〜（Ｄ）のあとに「さらに有する」ことは、何のための事項なのか意味不明である。』との指摘がなされております。
　エンドユーザーは、複数のプログラムを、パッケージもしくはセットの形で一体として受信し得るものである、という点に注意すべきであります（本願明細書の「従来技術」の欄を参照のこと）。また、さらに注意すべき点は、請求項３は請求項１の従属するものではあるが、特定の順番の処理ステップについての要件は存在せず、請求項３に記載の処理ステップは、請求項１に記載の処理ステップの１つもしくは２つ以上のものの前又は後にて行われるものである、ということです。このことは、当業者にとって、自明なことであります。例えば、エンタイトルメント情報は、プログラムの送信前、送信中および送信後にエンドユーザに対して送出されるものであります。
（ｄ）同、理由２の記（４）において、『請求項４、請求項３の「エンドユーザにより得た」は、発明の詳細な説明との対応が不明である』との指摘がなされております。
　「エンドユーザにより得た」という記載は、（本願明細書の「従来技術」の欄に記載されているように）“「複数プログラムのセット」がエンドユーザにより得られた”ということを指しています。上述のように、エンドユーザは、複数のプログラムを、パッケージもしくはセットの形で一体として受信し得るものであります。ただし、本願発明書の開示は、主として、送信されたプログラム内容へのアクセスを制限するための暗号化方法および装置を指向し、プログラムのセットを得るエンドユーザの処理ステップは、図７に示される技術的範囲外のものであります。
（ｅ）同、理由２の記（５）において、『請求項４の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でない発明の詳細な説明との対応が不明である』との指摘がなされております。
　この点に関し、本願明細書の段落【００１４】には、次のような事柄が記載されております。
『このようなハッシュ演算は、ツリーのルート２マスターキーｍが配置されているようなｎレベルバイナリーツリーＴ（キーツリーとも呼ばれる）に関連して表すことができる。所望の数のツリーレベル（ｎ）が作られるまで、各ノードに対しハッシュ関数Ｈ0およびＨ1を適用することによりツリーを生成することができる。プログラムキーｋpはツリーのボトム（底）レベルにおけるリーフ（葉）ノードに対応する。各プログラムキーｋpに対応するバイナリーインデックス（そして同様にプログラム識別子ｐ）は、ルートから所望のリーフノードへのキーツリーを通るパス（路）に対応する。従って、ノードｕのインデックスないしラベルは、ルートからノードｕへのパス上のＨ上のラベルの連結である。Ｔ（ｕ）はノードｕをルートとするサブツリー、即ち、ノードｕのサブツリーにおけるリーフに対応するプログラム識別子ｐのセットを表す部分的プログラム識別子ｐを有するキーツリーにおける深さｒにおける内部ノードｕ（ｕ１,...,ur）に対して、サブツリーＴ（ｕ）における何れのプログラムのキーをもハッシュ関数を（ｎ−ｒ）回作動させることにより計算することができる。』
　上記記載事項を考慮すれば、当業者であれば、キーツリーがどのように用いられるかを理解できるはずであります（明細書の「キーツリー」の欄、段落【００２５】ないし【００２８】を参照のこと）。
（ｆ）同、理由２の記（６）において、『請求項３を引用する請求項５に関し、請求項１〜３は送信するための、つまり送信する側におけるステップにおけるものであるのに対し、請求項５は請求項３記載の方法であるにも関わらず、エンドユーザの側の、デコードのプロセスに係るところの「前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」を特徴としており、送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。』との指摘がなされております。
　請求項５は、送信する側における処理ステップを意図したものではなく、プログラム識別子の使用を説明するものであるため、請求項５の記載は、送信する側の処理ステップに限定されるものではありません。
（ｇ）同、理由２の記（７）において、『請求項８の「（Ａ）プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、が記載されていると認められるが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明である。』との指摘がなされております。
　この点について、明細書の段落【００１３】における前述の記載を考慮すれば、バイナリ値に基づくマスターキーに対して「ハッシュ関数を回帰的に適用する」ことの技術的意味を当業者はよく理解できるはずであります。
（ｈ）同、理由２の記（８）において、『請求項９に記載の「エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は実質的にエンドユーザ側におけるデコードに係るステップであって送信する側の送信するステップに含まれないから、（Ｃ）の事項は不明確な記載である。』との指摘がなされております。
　今回なされた手続補正により、請求項９におけるステップ（Ｃ）中の記載が、「前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっている」と訂正されました。
　請求項９に記載の上記技術限定事項は、エンタイトルメント情報がどのようにして利用されるかということを特定するものであって、エンドユーザ側の処理ステップを指すものではありません。
（ｉ）同、理由２の記（９）において、『請求項１０における「前記顧客」における「前記」が何を指すのか不明であり、また「キーツリー」の構成、「キーツリーの部分」（プログラムのセット、ノード、キー値（中間キー）、部分プログラム識別子、マスター鍵との関係）が不明であるので、プログラムキーを得るステップが不明確である。』との指摘がなされております。
　指摘の不備を解消するために、請求項１０における該当箇所の記載を訂正致しました。
　なお、（上記項目（ｅ）において）前記した明細書の段落【００１４】の記載事項を考慮すれば、プログラムのセットとの関係における「キーツリー」および「キーツリーの部分」の配置の特徴的意味を、当業者は理解できるはずであります（なお、「中間キー」については請求項１０には記載されていないことに注意されたい）。
（ｊ）同、理由２の記（１１）において、『請求項１４、１５はカテゴリーがシステムの発明に係るが、請求項１で言及したことと同様のことがいえる。送信したものを何に用いるのか記載されていないので、何のための特定事項であるのか技術的意義が不明である。
』との指摘がなされております。
　今回なされた請求項１４および１５に対する補正により、指摘の記載不備の問題は解消されたものと思料致します。
（ｋ）同、理由２の記（１２）において、『請求項１６は、（ｃ）の「プログラムキーを得」るステップが、キーツリーの部分、エンタイトルメント情報、プログラム識別子をどのように用いて得るのか不明確である。』との指摘がなされております。
　この点に関し、本願明細書の段落【００５０】ないし【００５１】には、次のような事柄が記載されております。  
『しかし、もし受信されたプログラム識別子ｐの最左桁ビットに合致する部分プログラム識別子ｐを有するエンタイトルメントデータベース６００にエントリーが存在すれば、顧客には選択されたプログラムへのエンタイトルメントがある。従って、エンタイトルメントデータベース６００のエントリーから取り出した中間キーｋiを用いてプログラムキーｋpが計算される（９６０）。具体的には、プログラムキーｋpは以下のようにプログラム識別子ｐの（ｎ−ｒ）低いオーダーのビットのそれぞれの値が指示するように適切なハッシュ関数Ｈ0またはＨ1を作動させることによって計算される。
【数５】
最後に、そのプログラムは得られたプログラムキーｋpを用いて解読され（９７０）、プログラム制御を終了する（９８０）。ここで、もし受信されたプログラムが顧客のエンタイトルメントの一部ではないような場合、送信プログラムとともに受信したプログラム識別子ｐの低位ビットに合致する部分的識別子ｐを有するエンタイトルメント情報がエンタイトルメントデータベース６００にはないことが重要である。』
　上記記載事項を考慮すれば、「キーツリーの部分、エンタイトルメント情報およびプログラム識別子をどのように用いてプログラムキーを得るのか」を、当業者はよく理解できるはずであります。
（ｌ）同、理由２の記（１３）において、『請求項１７及び１８は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている（記録媒体自体が、コンピュータに対して命令するようなもの）が、対応する記録媒体は、発明の詳細な説明には記載がない。』との指摘がなされております。
　コンピュータに種々の処理ステップを実行させるプログラムを記録するコンピュータ読み取り可能な記録媒体は、当業者には全く周知なものであります。
（ｍ）同、理由２の記（１４）において指摘された、請求項１７および１８の記載を補正致しました。
（ｎ）同、理由２の記（１５）において、『請求項１６の記載に関し、“マスタキー”はプロバイダーの側で用いられるものであるところ、これでは、正規の顧客でなくてもプログラムを視聴できることとなってしまい本願発明の解決課題が達成されない』との指摘がなされております。
　指摘の記載不備を解消するために、“マスターキー”についての要件を削除するよう請求項１５を訂正致しました。」
　
５　特許法第２９条第２項の点について
５．１　本願発明
　本願特許請求の範囲の請求項１に係る発明は、平成２１年１１月２７日付け手続補正書により補正されたとおりの次の事項により特定されるもの（以下、「本願発明」という。）である。（請求項１の記載を再度掲示した。）
　
「エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、
　（Ｂ）少なくとも１つのマスターキーを定めるステップと、
　（Ｃ）前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つのハッシュ関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、
　（Ｄ）暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。」
　
５．２　刊行物１の発明
　当審の拒絶理由で引用した刊行物１には、その理由で言及したと同様のことが言えるとともに、刊行物１の発明の「バイナリ値を有するプログラム識別子」として、刊行物１の［００１９］段落に「In one preferred embodiment, the program identifier, p, consists of a thirty-two (32) bitvalue that may be transmitted, for example, in the ECM field defined in the MPEG-2 standard.」（訳；一実施例では、番組識別子ｐは、例えば、ＭＰＥＧ２標準で定義されるＥＣＭフィールドで送信される３２ビット値からなる。）と記載されていることを加味すると、３２ビット値からなるバイナリ値を有する番組識別子ｐ（プログラム識別子）が例示されている。この点をふまえると、刊行物１には次の発明（以下「刊行物１の発明」という。）が示されている。
　
　エンドユーザに対してアクセス制限することができるプログラム（番組）を送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　３２ビット値からなるバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、
　少なくとも１つのマスターキーを定めるステップと、
　前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、
　暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。
　
５．３　対比
　本願発明と刊行物１の発明とを対比する。
　刊行物１の発明の「３２ビット値からなるバイナリ値を有するプログラム識別子」は、換言すれば、２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム（番組）識別子に含まれる（下位概念にあたる）から、刊行物１の発明の前記識別子は本願発明の「２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」と実質的な差異はない。また、その余の事項の対比については、前記当審拒絶理由で言及したことと同様のことが言える。
　以上の点をふまえると、刊行物１の発明と本願発明とは、次の事項を有する発明である点で一致し、そして、次の点で相違が認められる。
　
〈一致点〉
　エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが
　（Ａ）２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、
　（Ｂ）少なくとも１つのマスターキーを定めるステップと、
　（Ｃ）前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、
　（Ｄ）暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。
　
〈相違点〉プログラム識別子における各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも１つの関数が、請求項１の発明は、ハッシュ関数であるのに対し、刊行物１の発明は、かけ算の関数である点。
　
５．４　〈相違点〉についての判断
　マスターキーに適用する、少なくとも１つの関数が、ハッシュ関数であることは、本願優先権主張日前に周知の技術的事項にすぎない。例えば、刊行物２には、マスタ鍵にハッシュ関数を適用することと、この適用で得られた鍵をグループ鍵として用いることが記載されており、また、刊行物２には、宛先通信情報に事業所識別番号と個人識別番号が同時に含まれるかどうかを検査し、含まれていれば、ステップ３０５で該宛先通信情報と該マスタ鍵を使ってグループ鍵であるハッシュトータル［Ｈ（マスタ鍵，宛先通信情報）］を計算し、含まれていなければ、前記ハッシュの適用がされない（図３のフロー参照）旨示されており、これは含まれているかいないかのバイナリ状態（値）に基づいて、前記マスタ鍵に少なくとも１つのハッシュ関数を適用する技術に相当する。
　刊行物３にも、秘密鍵を、所定のハッシュ関数でハッシュ値に変換することが記載されている。
　刊行物１の発明において、プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも１つの関数を、ハッシュ関数とすることは、前記周知の技術的事項を参酌することにより当業者が容易になし得ることである。
　
　なお、出願人は、意見書において、プログラムの暗号化は、成熟した技術であるから、プログラム識別子の各ビット位置のバイナリ値に基づいてハッシュ関数を繰り返し適用する暗号化技術の手法が従来技術に存在しないということは、この技術手法が当業者にとって自明ではないという十分な証拠になり得るものと考えられるので、バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理は全く新規なものである旨主張しているので、この点に言及すると、
　前記意見書で主張している「ハッシュ関数を繰り返し適用する」ことは本願請求項１の発明の特定事項ではなく、前記主張は本願発明に基づく主張ではないばかりか、仮に、本願請求項１の発明の特定事項であるとしても、ハッシュ関数を繰り返し適用する暗号化技術の手法は周知である。例えば、特開平１０−３０７８８２号公報の従来技術を説明する【０００４】〜【０００６】段落には
「２．金額情報作成
次に利用者は、Ｗn からはじまり、Ｗn-1 ，Ｗn-2 ，，，ＷO からなるｎ個の数列をつくる（これによりｎ円の金額情報を表す）。
【０００５】この際、
Ｗi ＝ｈ（Ｗi-1)      （ｉは０からｎ−１まで）
（ｈ（）は一方向性ハッシュ関数を表す）を計算することにより求める。最後に求まるＷO を数列の根とする。
３．支払い
…（中略）…
【０００６】次に、ｋ円を支払う際には、先の金額情報からＷk ，ｋを送る。商店では、Ｗk をｋ回ハッシュすることにより、ＷO （数列の根）を求めることができ、先の利用者の署名の中のＷO と一致することを認識することにより、ハッシュした回数ｋを金額情報ｋ円として受けとる。」と記載されており、ハッシュ関数を繰り返し適用する暗号化技術の手法が示されており、この手法は周知である。
　また、出願人が主張する、前記「バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理」は本願発明の特定事項ではなく、前記バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理と本願発明の「各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも１つのハッシュ関数を適用すること」とは、その特定事項の意味する内容が異なり、前記主張は本願請求項１の発明の事項に基づく主張ではないから採用できない。
　したがって、意見書の内容を検討してみても、前記特許法第２９条第２項の拒絶の理由を覆すに足る理由は認められない。
　
６．　特許法第３６条第４項、第６項第１号、第２号の点について
（１）請求項１について
　出願人は、請求項１は、エンドユーザに対して、アクセス制限したプログラムを送信するための方法を指向するものであり、送信側で遂行されるものであり、他の情報の送信は請求項１の発明の技術的範囲外のものであり、請求項１記載の発明の技術的範囲外にある他の処理ステップが行われることを制限する必要はない旨の主張をしているが、依然として、特許請求の範囲の記載（請求項１）は、特許を受けようとする発明が明確でない。
　発明の詳細な説明には、エンドユーザに対して、アクセス制限する構成として、送信側からエンタイトルメント情報が配信され（本願図６、図７参照）、この配信と、プログラム識別子と暗号化されたプログラムが送信されること（本願図８参照）により、「エンドユーザに対して、アクセス制限」する発明が記載され、「少なくとも、事前にエンドユーザにキー値ＫＩを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図９のステップ９６０から明らかである。」が、「アクセス制限」という用語は、エンドユーザにプログラムを一切利用させないことまで通常含まれる。しかし、本願発明の課題との関係で、発明の詳細な説明又は図面に開示されていないものまで含むものであり、換言すれば、「暗号化したプログラムとプログラム識別子を送られ」ただけで「エンドユーザに対して、アクセスを制限」したプログラムに係る発明は、発明の詳細な説明との対応がとれておらず、依然として、不備なままである。
　
　当審の「請求項１は、１つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。」との指摘に応対して、出願人は「２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いることを要件とするよう、（請求項１を含む）独立請求項の各々を補正したとする。しかし、この補正によっても、請求項１は「１つのハッシュ関数のみを適用」するものを含み、また、繰り返しハッシュ関数を適用することを特定したものでなく、しかも、請求項１は、「２ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いて、マスタ鍵に１つのハッシュ関数のみを適用して（キーツリーに対応した）プログラムキーが得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか対応が不明であって、その発明と対応する解決する課題も示されていないため、請求項１の発明は、発明の詳細な説明に記載した範囲を超えて特許を請求するものであると認められ、依然として、発明の詳細な説明に記載されたものでないことは明らかである。
　
（２）当審の『請求項２には、「プログラム識別子のｎビットの位置それぞれに前記ハッシュ関数の１つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。』との指摘に対して、出願人は、本願明細書の段落【００１３】には、
『例として、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数Ｈ0またはＨ1を回帰的に適用することによってプログラムキーｋpを得ることができる。…（中略）…
　【数１】
　　　　』
の記載事項を考慮すれば、「ハッシュ関数の１つが、プログラム識別子のｎビットの位置のそれぞれに適用される」ことは理解できる旨主張する。しかし、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、「マスターキー」に対しハッシュ関数Ｈ0またはＨ1を適用することと、「プログラム識別子のｎビットの位置」それぞれに前記ハッシュ関数の１つが適用されることとは意味する技術的内容が全く異なり、「前記ビット位置」に「ハッシュ関数が適用される」の意味するところは依然として不明のままであるとともに、「前記ビット位置にハッシュ関数が適用される」は【００１３】にも開示されたものではないので、請求項２は特許を受けようとする発明が明確でなく、しかも、発明の詳細な説明に記載されたものではない。
　
（３）請求項３の「（Ｅ）前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を意味するのか明確でなく（少なくとも請求項３が引用する請求項１には「エンドユーザにより得たプログラムのセット」なる文言はない。）、依然として、特許を受けようとする発明が明確でない。
　また、ステップを実行する方法において、請求項３の発明のように記載した場合、ステップの順序に意味があると認められ、一方、出願人の主張するような特定の順番の処理ステップについての要件は存在せず、といえるのであれば、（Ｅ）のステップの順序が（Ａ）〜（Ｄ）のあとに「さらに有する」こと、例えば、エンタイトルメント情報が、プログラムの送信前、送信中でなく、送信後に送信されて（発明の詳細な説明にはエンタイトルメント情報が暗号化プログラムの送信のあとにユーザに送信される説明はない。）、そのエンタイトルメント情報が何のために用いられる事項であるのか意味不明となるので、依然として、請求項３は特許を受けようとする発明が明確でなく、しかも、発明の詳細な説明に記載されたものではない。
　
（４）請求項４の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でないとの指摘に対し、出願人は段落【００１４】（明細書の「キーツリー」の欄、段落【００２５】ないし【００２８】）の記載事項を考慮すれば、当業者であれば、キーツリーがどのように用いられるかを理解できるはずである旨主張しているが、前記段落に記載されているとしても、請求項４の記載にはキーツリーの一部がどのように用いられ何のために発明特定事項（構成）として加わっているのか明確でなく、依然として、請求項４は特許を受けようとする発明が明確でない。
　
（５）請求項３を引用する請求項５に関し、「送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。」との指摘に対し、出願人は、請求項５は、送信する側における処理ステップを意図したものではなく、プログラム識別子の使用を説明するものであるため、請求項５の記載は、送信する側の処理ステップに限定されるものではない旨主張しているが、請求項１は「エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって」、請求項１を引用する請求項３は「エンタイトルメント情報を提供するステップをさらに有する」ものであり、あくまで送信するための、「前記方法であって」におけるものであるから、「その方法であって、」且つ、請求項５の、エンドユーザの側のプロセスに係ると解される、「前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」は、前記方法において、どのように用いられ発明特定事項として有しているのか不明であり、依然として、請求項５は特許を受けようとする発明が明確でない。
　
（６）請求項８の「（Ａ）・・・プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、を内容とするが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明であるとの指摘に対して、出願人は、明細書の段落【００１３】における前述の記載を考慮すれば、バイナリ値に基づくマスターキーに対して「ハッシュ関数を回帰的に適用する」ことの技術的意味を当業者はよく理解できる旨主張している。しかし、依然として、請求項８の前記の事項との対応が不明である。明細書の段落【００１３】には、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数Ｈ0またはＨ1を回帰的に適用することは記載されているが、請求項８の、特に「プログラム識別子を有するプログラムを、・・・暗号化する」点、及び、「プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキー」にハッシュ関数を回帰的に適用することは記載されておらず、請求項８のこれらの事項の意味する内容と明細書の段落【００１３】の内容とは意味する内容が異なる。
　したがって、請求項８は発明の詳細な説明に記載されたものではない。
　
（７）請求項９の（Ｂ）の事項について言及した点は、この（Ｂ）の事項が請求項８の（Ａ）の事項と同様の事項であり、前記請求項８で言及したことと同様のことが言える。
　また、出願人は、補正により、請求項９におけるステップ（Ｃ）中の記載が、「前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっている」ステップと、を実行すると補正し、請求項９に記載の上記技術限定事項は、エンタイトルメント情報がどのようにして利用されるかということを特定するものであって、エンドユーザ側の処理ステップを指すものではないと主張しているが、前記請求項９の記載によれば、（Ｃ）のステップ実行は送信するためのプロセッサが実行するステップであり、出願人の主張する、エンドユーザ側の処理ステップを指すものではなく、また、送信側の処理ステップである旨のとおりであるとすると、前記（Ｃ）の「エンドユーザにより利用されて、前記プログラムキーを取り出すようになっているステップ」を送信側でどの様に実行するか発明の詳細な説明に記載されている根拠も示していないので、この点からも発明の詳細な説明に記載されたものとは認められない。
　
（８）請求項１０について、（Ａ）の、受信する「キーツリーから少なくとも１つの中間キーを含むエンタイトルメント情報」と（Ｃ）の、「前記キーツリー」の部分との関係が明確でなく、受信する「中間キーを含むエンタイトルメント情報」がどのように用いられているのか明確でないので、依然として、特許を受けようとする発明が明確でない。出願人は、「（なお、「中間キー」については請求項１０には記載されていないことに注意されたい）」としているが、「中間キー」は請求項１０の特定事項として記載されている。
　
（９）請求項１４、１５は、カテゴリーがシステムの発明に係るが、ハッシュ関数を「回帰的」に適用する事項が特定されている点を除いて、請求項１で言及したことと同様のことがいえる。
　また、請求項１４の発明特定事項（Ａ）における「マスターキー」は、補正により「２ビットもしくはそれより多くのビットから成るマスターキー」とされたが、このように限定されたビットのマスターキーを発明特定事項として具備する技術的意義が発明の詳細な説明に説明されておらず、自明な事項でもない。したがって、この点からも請求項１４は、発明の詳細な説明に記載されたものであるとは認められない。
　
（１０）「請求項１７及び１８は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている（記録媒体自体が、コンピュータに対して命令するようなもの）が、これに対応する記録媒体は、発明の詳細な説明には記載がない。」旨の指摘に対し、出願人は、コンピュータに種々の処理ステップを実行させる「プログラム」を記録するコンピュータ読み取り可能な記録媒体は、当業者には全く周知なものであると反論しているが、この反論は、実行させる主体がプログラムであって、実行させる主体が「記録媒体」であること、つまり、実行させる「記録媒体」については言及しておらず、出願人のこの主張は請求項１７の構成に基づくものではなく採用できない。
　また、請求項１７、１８は、カテゴリーが記録媒体の発明に係るが、請求項１、請求項１０と同様の事項を有し、依然として、請求項１、請求項１０で言及したことと同様のことが言える。
　
（１１）請求項１６の記載に関し、暗号化されたプログラムをデコードするシステムであるにも関わらず「マスターキー」を有している点に対し、出願人は指摘の記載不備を解消するために、“マスターキー”についての要件を削除するよう請求項１５を訂正した旨主張しているが、当審で指摘した請求項１６について訂正しておらず、当審で（１５）の項で指摘した「マスターキー」の点は依然として不備のままである。
　
６．むすび
　以上のとおり、本願発明は、刊行物１に記載された発明、刊行物２に記載された技術及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　また、本願は、依然として、特許法第３６条第４項及び第６項第１号、２号に規定する要件を満たしていない。
　
　よって、結論のとおり審決する。