拒絶査定不服の審決｜不服2006-11370 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない(前置又は当審拒絶理由) H04L 審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) H04L 審判査定不服特36条4項詳細な説明の記載不備特許、登録しない(前置又は当審拒絶理由) H04L
管理番号	1218769
審判番号	不服2006-11370
総通号数	128
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2010-08-27
種別	拒絶査定不服の審決
審判請求日	2006-06-05
確定日	2010-06-15
事件の表示	特願2000-135069「エンドユーザに対してアクセス制限することができるプログラムを送信する方法、暗号化されたプログラムをデコードする方法」拒絶査定不服審判事件〔平成13年 2月 9日出願公開、特開2001- 36517〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続の経緯本願は、平成12年5月8日(パリ条約による優先権主張1999年5月7日、米国)を出願日とする出願であって、出願後の手続きの経緯は次のとおりである。拒絶理由通知平成17年6月1日意見書、手続補正書平成17年8月26日拒絶査定(起案) 平成18年3月3日拒絶査定(送達日) 平成18年3月8日審判請求平成18年6月5日補正書平成18年6月23日拒絶理由通知平成21年5月26日意見書、手続補正書平成21年11月27日上申書平成21年12月25日 2.本願特許請求の範囲の記載本願特許請求の範囲の記載は、平成21年11月27日付け手続補正書により補正されたとおりの次の事項により特定されるものである。「【請求項1】エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、 (B)少なくとも1つのマスターキーを定めるステップと、 (C)前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つのハッシュ関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、 (D)暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。【請求項2】前記プログラム識別子はnビットからなり、前記プログラム識別子の対応するビット値に従って、前記プログラム識別子のnビットの位置それぞれに前記ハッシュ関数の1つが適用されることを特徴とする請求項1記載の方法。【請求項3】 (E)前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有することを特徴とする請求項1記載の方法。【請求項4】前記エンタイトルメント情報には、前記エンドユーザにより得たプログラムのセットに基づくキーツリーの一部を含むことを特徴とする請求項3記載の方法。【請求項5】前記エンドユーザは、前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いることを特徴とする請求項3記載の方法。【請求項6】前記プログラム識別子は前記暗号化プログラムの送信とともにインターリーブされることを特徴とする請求項1記載の方法。【請求項7】前記プログラム識別子は、制御チャネル上で送信されることを特徴とする請求項1記載の方法。【請求項8】複数のエンドユーザにプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)2ビットもしくはそれより多くのビットから成るプログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップと、 (B)暗号化したプログラムおよび前記プログラム識別子を前記エンドユーザに送信するステップと、を実行することを特徴とする方法。【請求項9】少なくとも1つのプログラムパッケージに対応するプログラムを複数のエンドユーザに送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)前記エンドユーザにより得たプログラムパッケージに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップと、 (B)2ビットもしくはそれより多くのビットから成るプログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップと、 (C)暗号化されたプログラムとともに前記プログラム識別子を前記エンドユーザに送信するステップであって、前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっているステップと、を実行することを特徴とする方法。【請求項10】暗号化されたプログラムをデコードするための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)前記プログラムのプロバイダーから顧客が得たプログラムのセットに基づいてキーツリーから少なくとも1つの中間キーを含むエンタイトルメント情報を受信するステップと、 (B)プログラムキーで暗号化された暗号化プログラムと、2ビットもしくはそれより多くのビットから成るプログラム識別子とを受信するステップと、 (C)前記プログラム識別子及び前記キーツリーの部分から前記プログラムキーを得るステップと、 (D)前記プログラムキーおよびプロセッサを用いて前記暗号化プログラムを解読するステップと、を実行することを特徴とする方法。【請求項11】前記プログラム識別子はnビットからなり、マスターキーは前記キーツリーのルートに配置され、前記キーツリーは、nのツリーレベルが作られるまで前記キーツリーの各ノードにハッシュ関数を適用することにより前記キーツリーが生成されることを特徴とする請求項10記載の方法。【請求項12】暗号化されたプログラムをデコードするための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)前記プログラムのプロバイダーから、顧客が得るプログラムのセットに基づくキーツリーから少なくとも1つの中間キーを含むエンタイトルメント情報を受信するステップと、 (B)プログラムキーで暗号化された暗号化プログラムと、2ビットもしくはそれより多くのビットから成るプログラム識別子とを受信するステップと、 (C)前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記中間キーにハッシュ関数を回帰的に適用することにより前記プログラム識別子及び前記中間キーから前記プログラムキーを得るステップと、 (D)前記プログラムキーを用いて前記暗号化プログラムを解読するステップと、を実行することを特徴とする方法。【請求項13】前記プログラム識別子はnビットからなり、前記中間キーは前記キーツリーのレベルｒにおける中間ノードに対応し、前記ハッシュ関数は前記中間キーにn-ｒ回適用されることを特徴とする請求項12記載の方法。【請求項14】エンドユーザに対して、アクセスを制限したプログラムを送信するシステムであって、 (A)2ビットもしくはそれより多くのビットから成るマスターキーとコンピュータ読みとり可能コードを記憶するメモリーと、 (B)前記メモリーに動作的につながったプロセッサとを有し、このプロセッサが、 (a)バイナリ値を有するプログラム識別子を前記プログラムに割り当て、 (b)少なくとも1つのマスターキーを定め、 (c)前記プログラム識別子のバイナリ値に基づいて前記マスターキーに少なくとも1つのハッシュ関数を適用することによりプログラムキーを用いて前記プログラムを暗号化し、 (d)前記プログラム識別子とともに暗号化プログラムを前記エンドユーザに送信するように構成することを特徴とするシステム。【請求項15】エンドユーザーに対して、アクセスを制限したプログラムを送信するシステムであって、 (A)コンピュータ読み取り可能コードを記憶するメモリーと、 (B)前記メモリーに動作上つながったプロセッサーとを有し、前記プロセッサーは、 (a)2ビットもしくはそれより多くのビットから成るプログラム識別子の各ビット位置のバイナリー値に基づいてマスターキーにハッシュ関数を回帰的に適用することによって得られるプログラムキーを用いて、該プログラム識別子を有する該プログラムを暗号化し、 (b)前記エンドユーザーに暗号化された該プログラムおよび前記プログラム識別子を送信するように構成することを特徴とするシステム。【請求項16】暗号化されたプログラムをデコードするシステムであって、 (A)マスターキーおよびコンピュータ読み取り可能コードを記憶するメモリーと、 (B)前記メモリーに動作上つながったプロセッサーとを有し、前記プロセッサーは、 (a)前記顧客によって得られるプログラムのセットに基づくキーツリーの部分を含むエンタイトルメント情報を該プログラムのプロバイダーから受信し、 (b)プログラムキーによって暗号化された暗号化プログラム、および2ビットもしくはそれより多くのビットから成るプログラム識別子を受信し、 (c)前記プログラム識別子および前記キーツリーの記憶された前記部分から前記プログラムキーを得て、 (d)前記プログラムキーを用いて前記暗号化プログラムを解読するように構成することを特徴とするシステム。【請求項17】プログラムを記録するコンピュータ読み取り可能記録媒体であって、前記コンピュータに (a)2ビットもしくはそれより多くのビットから成るバイナリー値を有するプログラム識別子をプログラムに割り当てるステップと、 (b)少なくても一つのマスターキーを定めるステップと、 (c)前記プログラム識別子の各ビット位置のバイナリー値に基づいて前記マスターキーに少なくとも一つのハッシュ関数を適用することによって得られるプログラムキーを用いて、該プログラムを暗号化するステップと、 P.4 (d)前記プログラム識別子とともに暗号化された該プログラムをエンドユーザーに送信するステップと、を実行させることを特徴とするコンピュータ読み取り可能記録媒体。【請求項18】プログラムを記録するコンピュータ読み取り可能記録媒体であって、前記コンピュータに (a)前記顧客によって得られるプログラムのセットに基づくキーツリーの部分を含むエンタイトルメント情報を該プログラムのプロバイダーから受信するステップと、 (b)プログラムキーによって暗号化される暗号化プログラム、および2ビットもしくはそれより多くのビットから成るプログラム識別子を受信するステップと、 (c)前記プログラム識別子および前記キーツリーの前記部分から前記プログラムキーを得るステップと、 (d)前記プログラムキーを用いて前記暗号化プログラムを解読するステップと、を実行させることを特徴とするコンピュータ読み取り可能記録媒体。」 3.当審の拒絶の理由の概要は次のとおりである。「一.この出願の請求項1乃至請求項18に係る発明は、その出願前(優先権主張日;1999年5月7日)に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。記刊行物1;欧州特許出願公開第899956号明細書(本件と同一出願人に係る出願の明細書;公開日,1999年3月3日)(パテントファミリーである特開平11-155138号公報を参照した。) 刊行物2;特開平5-347616号公報刊行物3;特開平11-88322号公報刊行物1には、FIG.2に示された、HEAD END(ヘッドエンド)において遂行される方法が、FIG.8a,FIG.9から読み取れる。ア.FIG.9のステップ920の番組識別子ｐは、通常、1、0のデータで表されるので、「バイナリ値を有するプログラム識別子」といえるとともに、番組識別子は番組に対応して割り当てられることは自明。イ.FIG.2のマスタ鍵マトリックスM240は、「少なくとも1つのマスターキー」に対応する。ウ.FIG.9のステップ930のKｐ=M・ｐについては、番組識別子ｐのビット位置の1,0に基づいてかけ算され、このかけ算をすることは、ハッシュ関数とまではいえないまでも、上位概念では、少なくとも1つの関数を適用することであるから、Kｐ=M・ｐは、番組識別子ｐの各ビット位置のバイナリ値に基づいてマスタ鍵マトリックスMに少なくとも1つの関数を適用することにより番組鍵Kｐが得られることを示している。また、ステップ940には、該番組鍵Kｐで番組を暗号化するステップが示されている。前記番組鍵Kｐは「プログラムキー」に対応する。エ.FIG.9のステップ950には、暗号化された番組を番組識別子ｐとともに(エンドユーザに)送信することが示されている。ア.?エ.をふまえると、刊行物1には、次の発明が示されている。エンドユーザに対してアクセス制限することができるプログラム(番組)を送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサがバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、少なくとも1つのマスターキーを定めるステップと、前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。刊行物2には、次の事項が記載されている。「【0044】図3は、メモリ104に格納されているグループ鍵生成プログラム1の動作を説明するためのフローチャートを示す。…(中略)…ステップ303で該通信宛先情報に事業所識別番号118と個人識別番号119が同時に含まれるかどうかを検査する。…(中略)…そして、ステップ305で該宛先通信情報と該マスタ鍵を使ってハッシュトータルを計算する。すなわち、ハッシュトータル←H(マスタ鍵,宛先通信情報) とする。ここに、H(K,M)はハッシュ関数であり、…(中略)…このハッシュトータルがグループ鍵として用いられる。」刊行物3には、次の事項が記載されている。「【0079】図2(1)に示すように、個人情報管理配列20aは、ユーザの「ID」と、「登録動的署名データ」と、「鍵ハッシュ値」とを格納している配列である。この「鍵ハッシュ値」とは秘密鍵を、所定のハッシュ関数でハッシュ値に変換したものであり、このハッシュ値は、後述する暗号鍵管理配列20bにおいて利用される。」本願請求項1の発明(以下、「請求項1の発明」という。)について刊行物1の発明と請求項1の発明とを対比すると、次の相違点が認められるが、その余の事項を有する発明である点で差異はない。〈相違点〉プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも1つの関数が、請求項1の発明は、ハッシュ関数であるのに対し、刊行物1の発明は、かけ算の関数である点。当審判断マスターキーに適用する、少なくとも1つの関数が、ハッシュ関数であることは、本願優先権主張日前に周知の技術的事項にすぎない。例えば、刊行物2には、マスタ鍵にハッシュ関数を適用すること、この適用で得られた鍵をグループ鍵として用いることが記載されており、刊行物3にも、秘密鍵を、所定のハッシュ関数でハッシュ値に変換することが記載されている。刊行物1の発明において、プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも1つの関数を、ハッシュ関数とすることは、前記周知の技術的事項を参酌することにより当業者が容易になし得ることである。二.この出願は、特許請求の範囲及び発明の詳細な説明の記載が下記の点で、特許法第36条第4項及び第6項第1号、第2号に規定する要件を満たしていない。記 (1)請求項1についてア.請求項1には、送信側とエンドユーザ側とで何をするのかという前提事項が記載されておらず、また、エンドユーザ側に、単に、暗号化したプログラムとプログラム識別子を送るだけで、送られたデータをどのように用いるか記載されていないので、これらが発明特定事項として何ができるためにあるのか明確でない。特にエンドユーザ側は、暗号化したプログラムとプログラム識別子を送られただけではマスターキーmに関連した情報は得られていない(発明特定事項にない。)ので、プログラムキーは生成できず、暗号化したプログラムの復号もできないことは明らかである。請求項1に記載された一部の事項で何をしようとしているのか、請求項1の発明の技術的思想も不明である。少なくとも、事前にエンドユーザにキー値KIを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図9のステップ960から明らかである。イ.請求項1は、「少なくとも1つのハッシュ関数」、即ち、1つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。 (2)請求項2には、「プログラム識別子のnビットの位置それぞれに前記ハッシュ関数の1つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。文字通り解して、ビットの位置それぞれに前記ハッシュ関数の1つが適用されることは、発明の詳細な説明の具体的にどこに記載されているのか不明である。例えば、図8のステップ830の計算は、位置それぞれにハッシュ関数を適用するものではない。 (3)請求項3の「(E)前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を指すのか明確でなく、また、(E)のステップの順序が(A)?(D)のあとに「さらに有する」ことは、何のための事項なのか意味不明である。エンタイトルメント情報は、(1)で言及したように、最初の方の順序でエンドユーザが有していることが前提であり、この情報がなければプログラムキーが生成できないことは図9のステップ960から明らかである。 (4)請求項4、請求項3の「エンドユーザにより得た」は、発明の詳細な説明との対応が不明である(図7のどのステップが対応するのか?)。 (5)請求項4の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でない。キーツリーとして、マスターキーをキーツリーのルートの位置に配置され、中間キーのノード、プログラムキーのリーフノードを有するキーツリーが図2に示されてはいるが、キーツリーに図6のノードが関連するとしても、ノードのみではキーツリーではない。 (6)請求項3を引用する請求項5に関し、請求項1?3は送信するための、つまり送信する側におけるステップにおけるものであるのに対し、請求項5は請求項3記載の方法であるにも関わらず、エンドユーザの側の、デコードのプロセスに係るところの「前記エンドユーザは、前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」を特徴としており、送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。 (7)請求項8は、(1)で言及したことと同様のことがいえる。請求項8の「(A)プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、が記載されていると認められるが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明である。 (8)請求項9は、(1)で言及したことと同様のことがいえる。請求項9の(B)の事項については、請求項8で言及したことと同様のことがいえる。請求項9の(C)の事項における「暗号化されたプログラムとともに前記プログラム識別子を前記エンドユーザに送信するステップであって、前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は、これらステップのうち「エンドユーザが前記プログラムの正当ユーザであれば、前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は実質的にエンドユーザ側におけるデコードに係るステップであって送信する側の送信するステップに含まれないから、(C)の事項は不明確な記載である。 (9)請求項10における「前記顧客」における「前記」が請求項10の何を指すのか不明である。請求項10は、「キーツリー」の構成、「キーツリーの部分」(プログラムのセット、ノード、キー値(中間キー)、部分プログラム識別子、マスター鍵との関係)が不明であるので、プログラムキーを得るステップが不明確である。また、「中間キーを含むエンタイトルメント情報を受信する」と記載されているが、前記エンタイトルメント情報を何のためにどのように用いるのか記載されていないので、発明特定事項としての意義が不明であり、前記情報や中間キーと「キーツリーの部分」との関係も不明である。 (10)請求項11には、「各ノードにハッシュ関数を適用する」と記載されているが、ノードの何にハッシュ関数を適用するのか不明確である(ルートに位置するマスターキーのノードとキーツリーの他の中間キーのノードとの関係が不明である。)。また、「各ノードにハッシュ関数を適用することにより前記キーツリーが生成されること」は、プログラム識別子のバイナリ値に基づくことが記載されておらず、これではH0とH1のハッシュ関数を適用するものしか開示のない発明の詳細な説明とは対応せず不明確である。 (11)請求項14、15はカテゴリーがシステムの発明に係るが、請求項1で言及したことと同様のことがいえる。送信したものを何に用いるのか記載されていないので、何のための特定事項であるのか技術的意義が不明である。 (12)請求項16は、(c)の「プログラムキーを得」るステップが、キーツリーの部分、エンタイトルメント情報、プログラム識別子をどの様に用いて得るのか不明確である。 (13)請求項17及び18は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている(記録媒体自体が、コンピュータに対して命令するようなもの)が、対応する記録媒体は、発明の詳細な説明には記載がない。 (14)請求項17は、カテゴリーが記録媒体の発明に係るが、実質的には送信に係り、請求項1で言及したことと同様のことがいえる。また、請求項18は、カテゴリーが記録媒体の発明に係るが、実質的には解読(デコード)に係り、請求項10で言及したことと同様のことがいえる。 (15)請求項16は、「暗号化されたプログラムをデコードするシステム」であるにも関わらず、プロバイダー側しか有しない「(A)マスターキー・・・を有し、」ている。これでは、受信したエンタイトルメント情報、プログラム識別子を用いてプログラムキーを自在に生成でき(図9のステップ960参照)、正規の顧客でなくてもプログラムを視聴できることになり、本願発明の解決課題が達成されない。発明の詳細な説明には、請求項16の特定事項を有する発明の具体的な態様は示されておらず、解決課題がどのように解決されるのか不明であり、当業者がその実施をすることができる程度に明確かつ十分に記載したものであるとは認められず、その技術上の意義を理解するために必要な事項も十分に記載されているとは認められない。」 4.当審拒絶理由に対する意見、上申の概要 4.1 意見の概要「(1)本件出願は、本願発明が、欧州特許出願公開第899956号明細書(引用例1)、特開平5-347616号公報(引用例2)および特開平11-88322号公報(引用例3)に記載された発明に基づいて、当業者が容易になし得たとして、特許法第29条第2項の規定により、ならびに明細書の記載が不備と認められるから、特許法第36条第4項および第6項の規定により、それぞれ特許を受けることができないとする旨の平成21年5月26日付け拒絶理由通知に接しました。 (2)これに対して、本願発明の構成をより明確に特定するために、本日別途提出する手続補正書により特許請求の範囲の記載を補正しております。 (3)A.本願発明の進歩性について今回の拒絶理由通知において、 …(中略)… しかしながら、出願人としては、拒絶理由通知における上記技術認定および所見には同意致しかねるものであります。プログラムの暗号化は、成熟した技術であるから、プログラム識別子の各ビット位置のバイナリ値に基づいてハッシュ関数を繰り返し適用する暗号化技術の手法が従来技術に存在しないということは、この技術手法が当業者にとって自明ではないという十分な証拠になり得るものと考えます。したがって、拒絶理由通知における(本願発明に対する)拒絶の判断にもかかわらず、バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理は全く新規なものであり、当業者により容易になし得るものではないと考えます。したがって、本願発明は、引用例1-3に記載の発明に対して進歩性を有するものである、と確信致します。 B.記載不備について (a) (i)拒絶理由通知における理由2の記(1)において、「請求項1には、送信側とエンドユーザ側とで何をするのかという前提事項が記載されていない。」との指摘がなされております。しかしながら、請求項1は、エンドユーザに対して、アクセス制限したプログラムを送信するための方法を指向するものであることに注意すべきであります。よって、請求項1に記載される処理ステップは、明らかに送信側によって遂行されるものであり、このことは請求項1の記載において自明であると思料致します。また、拒絶理由通知において、「エンドユーザに送られた暗号化したプログラムとプログラム識別子がどのように用いられるかが請求項1に記載されていないため、何をしようとしているのか不明である」との指摘がなされております。この点について、上述したように、請求項1に記載の処理ステップは送信側により行われるものであり、請求項1はエンドユーザ側により行われる処理を指向するものではありません。さらに、「エンドユーザ側は、暗号化したプログラムとプログラム識別子を送られただけではマスターキーmに関連した情報は得られていないので、請求項1に記載された一部の事項で何をしようとしているのか、請求項1の発明の技術的思想も不明である。」との指摘がなされております。しかしながら、上述したように請求項1は、エンドユーザに対して、アクセス制限したプログラムを遂行するための方法を指向するものであることに注意すべきであります。マスターキーnなどの他の情報の送信は、本願発明の技術的範囲外のものであります。また、「少なくとも、事前にエンドユーザにキー値KIを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図9のステップ960から明らかである。」との指摘がなされておりますが、請求項1は請求項1に記載の発明の技術的範囲外にある他の処理ステップが行われることを制限するものではない、という点に注意すべきであります。 (ii)「請求項1は、1つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。」との指摘に対応して、「2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いることを要件とするよう、(請求項1を含む)独立請求項の各々を補正致しました。 [拒絶理由における理由2.の記(2)ないし(15)に対しては、指摘の記載不備に対する釈明を追って近日中に「上申書」を介してご提示申し上げる所存であります。」 4.2 上申の概要「(b)同、理由2の記(2)において、『請求項2には、「プログラム識別子のnビットの位置それぞれに前記ハッシュ関数の1つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。』との指摘がなされております。この点に関し、本願明細書の段落【0013】には、次のような事柄が記載されております。『例として、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数H0またはH1を回帰的に適用することによってプログラムキーkpを得ることができる。従って、もしプログラム識別子ｐがmビットからなるのであれば、ハッシュ関数H0またはH1の一方がプログラム識別子ｐの対応するビット値に従ってプログラム識別子ｐのnのビット位置それぞれに対して適用される。最初には、ハッシュ関数H0またはH1の一方がプログラム識別子ｐの最左桁ビットのバイナリー値に従ってマスターキーに適用される。その後で、残りの(n-1)ビット位置それぞれに対し、対応するビットのバイナリ値に従って、前のハッシュ演算の結果にハッシュ関数H0またはH1の一方が適用される。プログラムキーkpの計算は以下のように表すことができる。【数1】』上記記載事項を考慮すれば、「ハッシュ関数の1つが、プログラム識別子のnビットの位置のそれぞれに適用される」ということの技術的意味は、当業者にはよく理解できることであります。 (c)同、理由2の記(3)において、『請求項3の「(E)前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を意味するのか明確でなく、また、(E)のステップの順序が(A)?(D)のあとに「さらに有する」ことは、何のための事項なのか意味不明である。』との指摘がなされております。エンドユーザーは、複数のプログラムを、パッケージもしくはセットの形で一体として受信し得るものである、という点に注意すべきであります(本願明細書の「従来技術」の欄を参照のこと)。また、さらに注意すべき点は、請求項3は請求項1の従属するものではあるが、特定の順番の処理ステップについての要件は存在せず、請求項3に記載の処理ステップは、請求項1に記載の処理ステップの1つもしくは2つ以上のものの前又は後にて行われるものである、ということです。このことは、当業者にとって、自明なことであります。例えば、エンタイトルメント情報は、プログラムの送信前、送信中および送信後にエンドユーザに対して送出されるものであります。 (d)同、理由2の記(4)において、『請求項4、請求項3の「エンドユーザにより得た」は、発明の詳細な説明との対応が不明である』との指摘がなされております。「エンドユーザにより得た」という記載は、(本願明細書の「従来技術」の欄に記載されているように)“「複数プログラムのセット」がエンドユーザにより得られた”ということを指しています。上述のように、エンドユーザは、複数のプログラムを、パッケージもしくはセットの形で一体として受信し得るものであります。ただし、本願発明書の開示は、主として、送信されたプログラム内容へのアクセスを制限するための暗号化方法および装置を指向し、プログラムのセットを得るエンドユーザの処理ステップは、図7に示される技術的範囲外のものであります。 (e)同、理由2の記(5)において、『請求項4の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でない発明の詳細な説明との対応が不明である』との指摘がなされております。この点に関し、本願明細書の段落【0014】には、次のような事柄が記載されております。『このようなハッシュ演算は、ツリーのルート2マスターキーmが配置されているようなnレベルバイナリーツリーT(キーツリーとも呼ばれる)に関連して表すことができる。所望の数のツリーレベル(n)が作られるまで、各ノードに対しハッシュ関数H0およびH1を適用することによりツリーを生成することができる。プログラムキーkpはツリーのボトム(底)レベルにおけるリーフ(葉)ノードに対応する。各プログラムキーkpに対応するバイナリーインデックス(そして同様にプログラム識別子ｐ)は、ルートから所望のリーフノードへのキーツリーを通るパス(路)に対応する。従って、ノードｕのインデックスないしラベルは、ルートからノードｕへのパス上のH上のラベルの連結である。T(ｕ)はノードｕをルートとするサブツリー、即ち、ノードｕのサブツリーにおけるリーフに対応するプログラム識別子ｐのセットを表す部分的プログラム識別子ｐを有するキーツリーにおける深さｒにおける内部ノードｕ(ｕ1,...,ur)に対して、サブツリーT(ｕ)における何れのプログラムのキーをもハッシュ関数を(n-ｒ)回作動させることにより計算することができる。』上記記載事項を考慮すれば、当業者であれば、キーツリーがどのように用いられるかを理解できるはずであります(明細書の「キーツリー」の欄、段落【0025】ないし【0028】を参照のこと)。 (f)同、理由2の記(6)において、『請求項3を引用する請求項5に関し、請求項1?3は送信するための、つまり送信する側におけるステップにおけるものであるのに対し、請求項5は請求項3記載の方法であるにも関わらず、エンドユーザの側の、デコードのプロセスに係るところの「前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」を特徴としており、送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。』との指摘がなされております。請求項5は、送信する側における処理ステップを意図したものではなく、プログラム識別子の使用を説明するものであるため、請求項5の記載は、送信する側の処理ステップに限定されるものではありません。 (g)同、理由2の記(7)において、『請求項8の「(A)プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、が記載されていると認められるが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明である。』との指摘がなされております。この点について、明細書の段落【0013】における前述の記載を考慮すれば、バイナリ値に基づくマスターキーに対して「ハッシュ関数を回帰的に適用する」ことの技術的意味を当業者はよく理解できるはずであります。 (h)同、理由2の記(8)において、『請求項9に記載の「エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報から前記プログラムキーを得るようになっているステップ」は実質的にエンドユーザ側におけるデコードに係るステップであって送信する側の送信するステップに含まれないから、(C)の事項は不明確な記載である。』との指摘がなされております。今回なされた手続補正により、請求項9におけるステップ(C)中の記載が、「前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっている」と訂正されました。請求項9に記載の上記技術限定事項は、エンタイトルメント情報がどのようにして利用されるかということを特定するものであって、エンドユーザ側の処理ステップを指すものではありません。 (i)同、理由2の記(9)において、『請求項10における「前記顧客」における「前記」が何を指すのか不明であり、また「キーツリー」の構成、「キーツリーの部分」(プログラムのセット、ノード、キー値(中間キー)、部分プログラム識別子、マスター鍵との関係)が不明であるので、プログラムキーを得るステップが不明確である。』との指摘がなされております。指摘の不備を解消するために、請求項10における該当箇所の記載を訂正致しました。なお、(上記項目(e)において)前記した明細書の段落【0014】の記載事項を考慮すれば、プログラムのセットとの関係における「キーツリー」および「キーツリーの部分」の配置の特徴的意味を、当業者は理解できるはずであります(なお、「中間キー」については請求項10には記載されていないことに注意されたい)。 (j)同、理由2の記(11)において、『請求項14、15はカテゴリーがシステムの発明に係るが、請求項1で言及したことと同様のことがいえる。送信したものを何に用いるのか記載されていないので、何のための特定事項であるのか技術的意義が不明である。』との指摘がなされております。今回なされた請求項14および15に対する補正により、指摘の記載不備の問題は解消されたものと思料致します。 (k)同、理由2の記(12)において、『請求項16は、(c)の「プログラムキーを得」るステップが、キーツリーの部分、エンタイトルメント情報、プログラム識別子をどのように用いて得るのか不明確である。』との指摘がなされております。この点に関し、本願明細書の段落【0050】ないし【0051】には、次のような事柄が記載されております。『しかし、もし受信されたプログラム識別子ｐの最左桁ビットに合致する部分プログラム識別子ｐを有するエンタイトルメントデータベース600にエントリーが存在すれば、顧客には選択されたプログラムへのエンタイトルメントがある。従って、エンタイトルメントデータベース600のエントリーから取り出した中間キーkiを用いてプログラムキーkpが計算される(960)。具体的には、プログラムキーkpは以下のようにプログラム識別子ｐの(n-ｒ)低いオーダーのビットのそれぞれの値が指示するように適切なハッシュ関数H0またはH1を作動させることによって計算される。【数5】最後に、そのプログラムは得られたプログラムキーkpを用いて解読され(970)、プログラム制御を終了する(980)。ここで、もし受信されたプログラムが顧客のエンタイトルメントの一部ではないような場合、送信プログラムとともに受信したプログラム識別子ｐの低位ビットに合致する部分的識別子ｐを有するエンタイトルメント情報がエンタイトルメントデータベース600にはないことが重要である。』上記記載事項を考慮すれば、「キーツリーの部分、エンタイトルメント情報およびプログラム識別子をどのように用いてプログラムキーを得るのか」を、当業者はよく理解できるはずであります。 (l)同、理由2の記(13)において、『請求項17及び18は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている(記録媒体自体が、コンピュータに対して命令するようなもの)が、対応する記録媒体は、発明の詳細な説明には記載がない。』との指摘がなされております。コンピュータに種々の処理ステップを実行させるプログラムを記録するコンピュータ読み取り可能な記録媒体は、当業者には全く周知なものであります。 (m)同、理由2の記(14)において指摘された、請求項17および18の記載を補正致しました。 (n)同、理由2の記(15)において、『請求項16の記載に関し、“マスタキー”はプロバイダーの側で用いられるものであるところ、これでは、正規の顧客でなくてもプログラムを視聴できることとなってしまい本願発明の解決課題が達成されない』との指摘がなされております。指摘の記載不備を解消するために、“マスターキー”についての要件を削除するよう請求項15を訂正致しました。」 5 特許法第29条第2項の点について 5.1 本願発明本願特許請求の範囲の請求項1に係る発明は、平成21年11月27日付け手続補正書により補正されたとおりの次の事項により特定されるもの(以下、「本願発明」という。)である。(請求項1の記載を再度掲示した。) 「エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、 (B)少なくとも1つのマスターキーを定めるステップと、 (C)前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つのハッシュ関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、 (D)暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。」 5.2 刊行物1の発明当審の拒絶理由で引用した刊行物1には、その理由で言及したと同様のことが言えるとともに、刊行物1の発明の「バイナリ値を有するプログラム識別子」として、刊行物1の[0019]段落に「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.」(訳;一実施例では、番組識別子ｐは、例えば、MPEG2標準で定義されるECMフィールドで送信される32ビット値からなる。)と記載されていることを加味すると、32ビット値からなるバイナリ値を有する番組識別子ｐ(プログラム識別子)が例示されている。この点をふまえると、刊行物1には次の発明(以下「刊行物1の発明」という。)が示されている。エンドユーザに対してアクセス制限することができるプログラム(番組)を送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが 32ビット値からなるバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、少なくとも1つのマスターキーを定めるステップと、前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。 5.3 対比本願発明と刊行物1の発明とを対比する。刊行物1の発明の「32ビット値からなるバイナリ値を有するプログラム識別子」は、換言すれば、2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム(番組)識別子に含まれる(下位概念にあたる)から、刊行物1の発明の前記識別子は本願発明の「2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」と実質的な差異はない。また、その余の事項の対比については、前記当審拒絶理由で言及したことと同様のことが言える。以上の点をふまえると、刊行物1の発明と本願発明とは、次の事項を有する発明である点で一致し、そして、次の点で相違が認められる。〈一致点〉エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって、前記プロセッサが (A)2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子を前記プログラムに割り当てるステップと、 (B)少なくとも1つのマスターキーを定めるステップと、 (C)前記プログラム識別子の各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つの関数を適用することにより得たプログラムキーおよびプロセッサを用いることにより前記プログラムを暗号化するステップと、 (D)暗号化したプログラムを前記プログラム識別子とともに前記エンドユーザへと送るステップと、を実行することを特徴とする方法。〈相違点〉プログラム識別子における各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも1つの関数が、請求項1の発明は、ハッシュ関数であるのに対し、刊行物1の発明は、かけ算の関数である点。 5.4 〈相違点〉についての判断マスターキーに適用する、少なくとも1つの関数が、ハッシュ関数であることは、本願優先権主張日前に周知の技術的事項にすぎない。例えば、刊行物2には、マスタ鍵にハッシュ関数を適用することと、この適用で得られた鍵をグループ鍵として用いることが記載されており、また、刊行物2には、宛先通信情報に事業所識別番号と個人識別番号が同時に含まれるかどうかを検査し、含まれていれば、ステップ305で該宛先通信情報と該マスタ鍵を使ってグループ鍵であるハッシュトータル[H(マスタ鍵,宛先通信情報)]を計算し、含まれていなければ、前記ハッシュの適用がされない(図3のフロー参照)旨示されており、これは含まれているかいないかのバイナリ状態(値)に基づいて、前記マスタ鍵に少なくとも1つのハッシュ関数を適用する技術に相当する。刊行物3にも、秘密鍵を、所定のハッシュ関数でハッシュ値に変換することが記載されている。刊行物1の発明において、プログラム識別子の各ビット位置のバイナリ値に基づいてマスターキーに適用する、少なくとも1つの関数を、ハッシュ関数とすることは、前記周知の技術的事項を参酌することにより当業者が容易になし得ることである。なお、出願人は、意見書において、プログラムの暗号化は、成熟した技術であるから、プログラム識別子の各ビット位置のバイナリ値に基づいてハッシュ関数を繰り返し適用する暗号化技術の手法が従来技術に存在しないということは、この技術手法が当業者にとって自明ではないという十分な証拠になり得るものと考えられるので、バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理は全く新規なものである旨主張しているので、この点に言及すると、前記意見書で主張している「ハッシュ関数を繰り返し適用する」ことは本願請求項1の発明の特定事項ではなく、前記主張は本願発明に基づく主張ではないばかりか、仮に、本願請求項1の発明の特定事項であるとしても、ハッシュ関数を繰り返し適用する暗号化技術の手法は周知である。例えば、特開平10-307882号公報の従来技術を説明する【0004】?【0006】段落には「2.金額情報作成次に利用者は、Wn からはじまり、Wn-1 ,Wn-2 ,,,WO からなるn個の数列をつくる(これによりn円の金額情報を表す)。【0005】この際、 Wi =h(Wi-1) (iは0からn-1まで) (h()は一方向性ハッシュ関数を表す)を計算することにより求める。最後に求まるWO を数列の根とする。 3.支払い …(中略)… 【0006】次に、k円を支払う際には、先の金額情報からWk ,kを送る。商店では、Wk をk回ハッシュすることにより、WO (数列の根)を求めることができ、先の利用者の署名の中のWO と一致することを認識することにより、ハッシュした回数kを金額情報k円として受けとる。」と記載されており、ハッシュ関数を繰り返し適用する暗号化技術の手法が示されており、この手法は周知である。また、出願人が主張する、前記「バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理」は本願発明の特定事項ではなく、前記バイナリ値の各ビット位置に基づいてハッシュ関数を適用する処理と本願発明の「各ビット位置のバイナリ値に基づいて前記マスターキーに少なくとも1つのハッシュ関数を適用すること」とは、その特定事項の意味する内容が異なり、前記主張は本願請求項1の発明の事項に基づく主張ではないから採用できない。したがって、意見書の内容を検討してみても、前記特許法第29条第2項の拒絶の理由を覆すに足る理由は認められない。 6. 特許法第36条第4項、第6項第1号、第2号の点について (1)請求項1について出願人は、請求項1は、エンドユーザに対して、アクセス制限したプログラムを送信するための方法を指向するものであり、送信側で遂行されるものであり、他の情報の送信は請求項1の発明の技術的範囲外のものであり、請求項1記載の発明の技術的範囲外にある他の処理ステップが行われることを制限する必要はない旨の主張をしているが、依然として、特許請求の範囲の記載(請求項1)は、特許を受けようとする発明が明確でない。発明の詳細な説明には、エンドユーザに対して、アクセス制限する構成として、送信側からエンタイトルメント情報が配信され(本願図6、図7参照)、この配信と、プログラム識別子と暗号化されたプログラムが送信されること(本願図8参照)により、「エンドユーザに対して、アクセス制限」する発明が記載され、「少なくとも、事前にエンドユーザにキー値KIを含むエンタイトルメントデータが送られていなければ、前記プログラムキーが生成できないことは図9のステップ960から明らかである。」が、「アクセス制限」という用語は、エンドユーザにプログラムを一切利用させないことまで通常含まれる。しかし、本願発明の課題との関係で、発明の詳細な説明又は図面に開示されていないものまで含むものであり、換言すれば、「暗号化したプログラムとプログラム識別子を送られ」ただけで「エンドユーザに対して、アクセスを制限」したプログラムに係る発明は、発明の詳細な説明との対応がとれておらず、依然として、不備なままである。当審の「請求項1は、1つのハッシュ関数のみを適用してキーツリーに対応したプログラム鍵が得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか、対応が不明である。」との指摘に応対して、出願人は「2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いることを要件とするよう、(請求項1を含む)独立請求項の各々を補正したとする。しかし、この補正によっても、請求項1は「1つのハッシュ関数のみを適用」するものを含み、また、繰り返しハッシュ関数を適用することを特定したものでなく、しかも、請求項1は、「2ビットもしくはそれより多くのビットから成るバイナリ値を有するプログラム識別子」を用いて、マスタ鍵に1つのハッシュ関数のみを適用して(キーツリーに対応した)プログラムキーが得られることを含むが、そのような例は発明の詳細な説明のどこに具体的に記載されているのか対応が不明であって、その発明と対応する解決する課題も示されていないため、請求項1の発明は、発明の詳細な説明に記載した範囲を超えて特許を請求するものであると認められ、依然として、発明の詳細な説明に記載されたものでないことは明らかである。 (2)当審の『請求項2には、「プログラム識別子のnビットの位置それぞれに前記ハッシュ関数の1つが適用される」と記載されているが、ビット位置にハッシュ関数が適用されるの意味するところが不明である。』との指摘に対して、出願人は、本願明細書の段落【0013】には、『例として、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数H0またはH1を回帰的に適用することによってプログラムキーkpを得ることができる。…(中略)… 【数1】』の記載事項を考慮すれば、「ハッシュ関数の1つが、プログラム識別子のnビットの位置のそれぞれに適用される」ことは理解できる旨主張する。しかし、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、「マスターキー」に対しハッシュ関数H0またはH1を適用することと、「プログラム識別子のnビットの位置」それぞれに前記ハッシュ関数の1つが適用されることとは意味する技術的内容が全く異なり、「前記ビット位置」に「ハッシュ関数が適用される」の意味するところは依然として不明のままであるとともに、「前記ビット位置にハッシュ関数が適用される」は【0013】にも開示されたものではないので、請求項2は特許を受けようとする発明が明確でなく、しかも、発明の詳細な説明に記載されたものではない。 (3)請求項3の「(E)前記エンドユーザにより得たプログラムのセットに基づいて前記エンドユーザにエンタイトルメント情報を提供するステップをさらに有すること」は、「前記エンドユーザにより得たプログラムのセット」が何を意味するのか明確でなく(少なくとも請求項3が引用する請求項1には「エンドユーザにより得たプログラムのセット」なる文言はない。)、依然として、特許を受けようとする発明が明確でない。また、ステップを実行する方法において、請求項3の発明のように記載した場合、ステップの順序に意味があると認められ、一方、出願人の主張するような特定の順番の処理ステップについての要件は存在せず、といえるのであれば、(E)のステップの順序が(A)?(D)のあとに「さらに有する」こと、例えば、エンタイトルメント情報が、プログラムの送信前、送信中でなく、送信後に送信されて(発明の詳細な説明にはエンタイトルメント情報が暗号化プログラムの送信のあとにユーザに送信される説明はない。)、そのエンタイトルメント情報が何のために用いられる事項であるのか意味不明となるので、依然として、請求項3は特許を受けようとする発明が明確でなく、しかも、発明の詳細な説明に記載されたものではない。 (4)請求項4の「キーツリーの一部を含む」は、そもそもキーツリーの内容が明確にされておらず、キーツリーがどのように用いられ何のために構成として加わっているのか明確でないとの指摘に対し、出願人は段落【0014】(明細書の「キーツリー」の欄、段落【0025】ないし【0028】)の記載事項を考慮すれば、当業者であれば、キーツリーがどのように用いられるかを理解できるはずである旨主張しているが、前記段落に記載されているとしても、請求項4の記載にはキーツリーの一部がどのように用いられ何のために発明特定事項(構成)として加わっているのか明確でなく、依然として、請求項4は特許を受けようとする発明が明確でない。 (5)請求項3を引用する請求項5に関し、「送信する側のステップとエンドユーザ側のステップが混在しており、構成が不明確になっている。」との指摘に対し、出願人は、請求項5は、送信する側における処理ステップを意図したものではなく、プログラム識別子の使用を説明するものであるため、請求項5の記載は、送信する側の処理ステップに限定されるものではない旨主張しているが、請求項1は「エンドユーザに対して、アクセスを制限したプログラムを送信するための、プロセッサを含むハードウェア・システムにより遂行される方法であって」、請求項1を引用する請求項3は「エンタイトルメント情報を提供するステップをさらに有する」ものであり、あくまで送信するための、「前記方法であって」におけるものであるから、「その方法であって、」且つ、請求項5の、エンドユーザの側のプロセスに係ると解される、「前記エンドユーザは前記エンタイトルメント情報から前記プログラムキーを得るために前記プログラム識別子を用いること」は、前記方法において、どのように用いられ発明特定事項として有しているのか不明であり、依然として、請求項5は特許を受けようとする発明が明確でない。 (6)請求項8の「(A)・・・プログラム識別子を有するプログラムを、前記プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用することによって得たプログラムキーおよびプロセッサを用いて暗号化するステップ」は、プログラム識別子を有するプログラムをプログラムキーおよびプロセッサを用いて暗号化すること、ビット位置それぞれのバイナリ値に基づくマスターキーにハッシュ関数を回帰的に適用すること、を内容とするが、この記載内容が発明の詳細な説明のどの記載と対応しているのか不明であるとの指摘に対して、出願人は、明細書の段落【0013】における前述の記載を考慮すれば、バイナリ値に基づくマスターキーに対して「ハッシュ関数を回帰的に適用する」ことの技術的意味を当業者はよく理解できる旨主張している。しかし、依然として、請求項8の前記の事項との対応が不明である。明細書の段落【0013】には、プログラム識別子ｐの各ビット位置の対応するバイナリー値に従って、マスターキーに対しハッシュ関数H0またはH1を回帰的に適用することは記載されているが、請求項8の、特に「プログラム識別子を有するプログラムを、・・・暗号化する」点、及び、「プログラム識別子のビット位置それぞれのバイナリ値に基づくマスターキー」にハッシュ関数を回帰的に適用することは記載されておらず、請求項8のこれらの事項の意味する内容と明細書の段落【0013】の内容とは意味する内容が異なる。したがって、請求項8は発明の詳細な説明に記載されたものではない。 (7)請求項9の(B)の事項について言及した点は、この(B)の事項が請求項8の(A)の事項と同様の事項であり、前記請求項8で言及したことと同様のことが言える。また、出願人は、補正により、請求項9におけるステップ(C)中の記載が、「前記エンドユーザが前記プログラムの正当ユーザであれば、前記エンタイトルメント情報が、前記エンドユーザにより利用されて、前記プログラムキーを取り出すようになっている」ステップと、を実行すると補正し、請求項9に記載の上記技術限定事項は、エンタイトルメント情報がどのようにして利用されるかということを特定するものであって、エンドユーザ側の処理ステップを指すものではないと主張しているが、前記請求項9の記載によれば、(C)のステップ実行は送信するためのプロセッサが実行するステップであり、出願人の主張する、エンドユーザ側の処理ステップを指すものではなく、また、送信側の処理ステップである旨のとおりであるとすると、前記(C)の「エンドユーザにより利用されて、前記プログラムキーを取り出すようになっているステップ」を送信側でどの様に実行するか発明の詳細な説明に記載されている根拠も示していないので、この点からも発明の詳細な説明に記載されたものとは認められない。 (8)請求項10について、(A)の、受信する「キーツリーから少なくとも1つの中間キーを含むエンタイトルメント情報」と(C)の、「前記キーツリー」の部分との関係が明確でなく、受信する「中間キーを含むエンタイトルメント情報」がどのように用いられているのか明確でないので、依然として、特許を受けようとする発明が明確でない。出願人は、「(なお、「中間キー」については請求項10には記載されていないことに注意されたい)」としているが、「中間キー」は請求項10の特定事項として記載されている。 (9)請求項14、15は、カテゴリーがシステムの発明に係るが、ハッシュ関数を「回帰的」に適用する事項が特定されている点を除いて、請求項1で言及したことと同様のことがいえる。また、請求項14の発明特定事項(A)における「マスターキー」は、補正により「2ビットもしくはそれより多くのビットから成るマスターキー」とされたが、このように限定されたビットのマスターキーを発明特定事項として具備する技術的意義が発明の詳細な説明に説明されておらず、自明な事項でもない。したがって、この点からも請求項14は、発明の詳細な説明に記載されたものであるとは認められない。 (10)「請求項17及び18は、コンピュータに所定のステップを実行させる「記録媒体」の発明になっている(記録媒体自体が、コンピュータに対して命令するようなもの)が、これに対応する記録媒体は、発明の詳細な説明には記載がない。」旨の指摘に対し、出願人は、コンピュータに種々の処理ステップを実行させる「プログラム」を記録するコンピュータ読み取り可能な記録媒体は、当業者には全く周知なものであると反論しているが、この反論は、実行させる主体がプログラムであって、実行させる主体が「記録媒体」であること、つまり、実行させる「記録媒体」については言及しておらず、出願人のこの主張は請求項17の構成に基づくものではなく採用できない。また、請求項17、18は、カテゴリーが記録媒体の発明に係るが、請求項1、請求項10と同様の事項を有し、依然として、請求項1、請求項10で言及したことと同様のことが言える。 (11)請求項16の記載に関し、暗号化されたプログラムをデコードするシステムであるにも関わらず「マスターキー」を有している点に対し、出願人は指摘の記載不備を解消するために、“マスターキー”についての要件を削除するよう請求項15を訂正した旨主張しているが、当審で指摘した請求項16について訂正しておらず、当審で(15)の項で指摘した「マスターキー」の点は依然として不備のままである。 6.むすび以上のとおり、本願発明は、刊行物1に記載された発明、刊行物2に記載された技術及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。また、本願は、依然として、特許法第36条第4項及び第6項第1号、2号に規定する要件を満たしていない。よって、結論のとおり審決する。
審理終結日	2010-01-15
結審通知日	2010-01-18
審決日	2010-02-01
出願番号	特願2000-135069(P2000-135069)
審決分類	P 1 8・ 537- WZ (H04L) P 1 8・ 121- WZ (H04L) P 1 8・ 536- WZ (H04L)
最終処分	不成立
前審関与審査官	青木重徳、石川正二
特許庁審判長	山崎達也
特許庁審判官	宮司卓佳石井茂和
発明の名称	エンドユーザに対してアクセス制限することができるプログラムを送信する方法、暗号化されたプログラムをデコードする方法
代理人	朝日伸光
代理人	岡部正夫
代理人	臼井伸一
代理人	本宮照久
代理人	加藤伸晃
代理人	越智隆夫

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