• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1261161
審判番号 不服2009-10500  
総通号数 153 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-09-28 
種別 拒絶査定不服の審決 
審判請求日 2009-06-01 
確定日 2012-08-08 
事件の表示 特願2003-586730「データセンタへのプラットフォームの内包検証」拒絶査定不服審判事件〔平成15年10月30日国際公開、WO03/90053、平成17年 9月15日国内公表、特表2005-527900〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 その1.手続の経緯
本願は、2003年3月28日(パリ条約による優先権主張外国庁受理2002年4月15日 アメリカ合衆国)を国際出願日とする出願であって、
平成16年10月13日付けで特許法第184条の4第1項の規定による明細書、請求の範囲、及び、図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に、同日付けで審査請求がなされ、平成20年6月12日付けで審査官により拒絶理由が通知され、これに対して同年9月24日付けで意見書が提出されると共に手続補正がなされたが、平成21年2月27日付けで審査官により拒絶査定がなされ、これに対して同年6月1日付けで審判請求がなされると共に手続補正がなされ、同年8月11日付けで審査官により拒絶理由が通知され、これに対して同年11月18日付けで意見書が提出されると共に手続補正がなされたが、平成22年1月29日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ、同年11月30日付けで当審により特許法第134条第4項の規定に基づく審尋がなされ、平成23年3月3日付けで回答書が提出され、同年7月4日付けで当審により拒絶理由が通知され、これに対して平成24年1月5日付けで意見書が提出されると共に手続補正がなされたものである。

その2.本願発明について
本願に係る発明は、平成24年1月5日付けの手続補正(以下、これを「本件手続補正」という)により補正された特許請求の範囲の請求項1に記載された次のとおりのものである(以下、これを「本願発明」という)

「 データセンタを運営し、ユーザからの前記データセンタに対する処理要求を処理するよう構成される複数のプラットフォームサーバと、
前記複数のプラットフォームサーバが前記データセンタのための処理を実行するのに信頼されていることを認証する管理部と、
を有するコンピュータシステムであって、
前記複数のプラットフォームサーバは、互いに異なる秘密鍵を有し、
前記管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有し、前記複数のプラットフォームサーバの前記データセンタへの内包に関するポリシーを格納し、
プラットフォームサーバが、前記管理部に前記プラットフォームサーバが信頼されていることを認証するよう要求するためのリクエストを、前記要求元のプラットフォームサーバの秘密鍵と共に前記管理部に送信すると、前記管理部は、前記要求元のプラットフォームサーバが前記ポリシーを充足するか判断し、前記署名鍵を用いて前記秘密鍵を認証するコンピュータシステム。」

その3.当審の拒絶理由
一方、平成23年7月4日付けの当審による拒絶理由(以下、これを「当審拒絶理由」という)は、概略、以下のとおりである。

「 理 由
1)本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第36条第6項第2号、第1号及び第4項第1号に規定する要件を満たしていない。
2)<省略>



理由1の1.36条6項2号について
(1)?(2)<省略>

(3)本願の請求項6に、
「秘密鍵を含む暗号鍵ペアを生成する処理ユニット及びサーバのポリシーを表す値を保持するレジスタを含むトークンと、前記暗号鍵を保持するメモリとからなるサーバと、前記サーバに結合され、データセンタコンピュータシステムに対するルート鍵を生成し、前記ルート鍵の認証に基づき前記データセンタコンピュータシステムに対する署名鍵を生成し、前記署名鍵により前記サーバの秘密鍵を署名する管理ユニットからなることを特徴とするデータセンタコンピュータシステム。」
と記載されているが、
a.<省略>
b.ここでいう「署名鍵」とはどのようなものであるか不明である。
(署名アルゴリズムとして、何を採用しているかによって、署名鍵が異なり、その署名鍵を生成する手法も異なるが、本願の請求項に記載の内容では、署名鍵についての情報は、全く示されていない。)
c.「署名鍵により前記サーバの秘密鍵に署名する」とあるが、該「秘密鍵」は、「サーバ」内の「メモリ」に保持されている。
では、「サーバ」内の「メモリ」に保持されている「秘密鍵」に対して、「管理ユニット」は、どのようにして、「署名鍵」を用いて「署名」しているのか、同請求項6、及び、他の請求項に記載の内容を加味しても不明である。
(本願の請求項6では、サーバ側で、秘密鍵を含む暗号鍵ペアを生成している。当該技術分野の技術常識を加味すると、「暗号鍵ペア」と表現されている場合、採用されている暗号アルゴリズムは、通常“公開鍵暗号”と解される。この前提に立った場合、セキュリティ上の観点から、「秘密鍵」は、該「秘密鍵」とペアにある「公開鍵」で暗号化された情報を、サーバが受信した場合に、該暗号化情報を復号するために用いる場合と、サーバ側で、情報に該秘密鍵で署名して送信し、受信側で、該ペアとなる「公開鍵」で“署名検証”を行うための、サーバの署名鍵として用いられるものであって、該「秘密鍵」自体を、外部に送信することはない。該「サーバ」で生成した「秘密鍵」を、“認証局”などに登録するために送信する事例が皆無ではないが、その場合は、該“認証局”の“公開鍵”などで暗号化され、送信される。しかしながら、このような手法は、当業者に知られたものであったとしても、これのみに限定されるものではなく、したがって、本願の請求項に記載の内容から自明の事項ではない。
以上のとおりであるから、本願の請求項6における、「管理ユニット」による「署名」がどのように実現されているかは不明である。)

(4)?(6)<省略>

その1の2.36条6項1号について
(1)?(3)<省略>

その1の3.36条4項1号について
(1)<省略>

(2)本願の請求項6に記載の、
「データセンタコンピュータシステムに対するルート鍵を生成」すること、
「ルート鍵の認証に基づき前記データセンタコンピュータシステムに対する署名鍵を生成」すること、
について、これらは、同請求項6に記載の内容から、同請求項6に記載の発明においては、「管理ユニット」によってなされるものであると解されるが、
上記「管理ユニット」による「データセンタコンピュータシステムに対するルート鍵」、及び、「データセンタコンピュータシステムに対する署名鍵」の生成については、本願明細書等の段落【0014】に、
「管理者ユニット106は、認証機関116により署名されたルート鍵170を生成するようにしてもよく、これにより署名鍵175が生成される。署名鍵175は、プラットフォーム105A?105Iに保持される異なる認証データセンタ識別鍵130A?130Iの認証に利用されてもよい」(以下、「引用記載11」という)、
同段落【0056】に、
「ブロック552において、フロー図550は、データセンタ180に対するルート鍵170と署名鍵175の生成から開始される。図3に示される実施例を参照して、管理論理302は、データセンタ180に対するルート鍵170を生成する。さらに、管理論理302は、このルート鍵170を認証する認証機関116を備え、これにより署名鍵175を生成する。一実施例では、管理論理302は、RSA、Diffie-Hellmanなどの様々なタイプの暗号化処理に基づき、ルート鍵170を生成するようにしてもよい。従って、ルート鍵170はデータセンタ180の署名鍵175のみに対する鍵証明鍵として利用され、以下でより詳細に説明されるように、異なる秘密鍵が異なるプラットフォーム105に保持されるために、データセンタ180内の鍵署名鍵として利用される証明鍵175と比較して攻撃に対してより限定的となる」(以下、「引用記載12」という)、
と記載されているに止まり、これら引用記載11、及び、引用記載12を参照しても、
「ルート鍵170」をどのように生成し、「ルート鍵170」を生成することで、どのようにして、「署名鍵175」を生成しているのか不明である。
ここで、引用記載12に、「ルート鍵170」の生成手法として、
「管理論理302は、RSA、Diffie-Hellmanなどの様々なタイプの暗号化処理に基づき、ルート鍵170を生成するようにしてもよい」、
との記載があるが、RSA公開鍵生成を行った場合、必ず、“公開鍵”と“個別鍵”が生成される。
それでは、該「ルート鍵170」は、RSAを用いた場合、“公開鍵”なのか“個別鍵”なのか不明である。
また、Diffie-Hellman鍵共有を用いた場合には、“誰”、或いは、“何”との間で、共有する鍵の計算を行っているか不明であり、
結果として、どのようにして、「ルート鍵170」を求めているか不明である。
また、引用記載12によれば、「署名鍵175」は、「ルート鍵170を認証する認証機関116を備え、これにより署名鍵175を生成する」との記載から、「認証機関116」が生成しているとも読めるが、該「認証機関116」は、どのようにして、「ルート鍵170」から、「署名鍵175」を生成しているのか、引用記載11、及び、引用記載12に記載の内容からは不明である。
ここで、該「ルート鍵」については、引用記載11、及び、引用記載12の他、
同段落【0029】に、
「一実施例では、この安全な環境は、それに関連するメモリ部分におけるデータの保持及び抽出に利用される対応するルート暗号鍵を有する。一実施例では、ルート暗号鍵は、トークン250(図示せず)に保持される永久公開鍵とPCR255の1つに保持されるダイジェスト値に基づく。一実施例では、ルート暗号鍵は、ダイジェスト値が暗号化の一部として保持されるように、永久公開鍵により暗号化される。従って、このルート暗号鍵は、保持されているダイジェスト値がPCR255に現在保持されているダイジェスト値と一致するとき、永久公開鍵を利用した解読に基づき利用することができる。従って、以下で詳細に説明されるように、データセンタに対する秘密鍵(データセンタ秘密鍵120と認証データセンタ秘密鍵130)は、ルート暗号鍵による暗号化処理に基づく安全な環境と関連付けされたプラットフォーム104/105内のメモリ部分への格納及び抽出が行われる」(以下、「引用記載13」という)、
との記載があるが、引用記載13における「ルート暗号鍵」と、引用記載11、或いは、引用記載12における「ルート鍵170」とが、同一のものか不明であり、また、引用記載13における、
「ルート暗号鍵は、トークン250(図示せず)に保持される永久公開鍵とPCR255の1つに保持されるダイジェスト値に基づく」、
との記載のみからでは、該「ルート暗号鍵」が、どのようなもので、どのように生成されているか不明である。
また、該「認証鍵」については、引用記載11、及び、引用記載12の他、
同段落【0055】に、
「そのような秘密鍵がデータセンタのための署名鍵により署名されるよう動作する」(以下、「引用記載14」という)、
同段落【0073】に、
「検証論理402は、認証データセンタ識別秘密鍵130がデータセンタ180を表す署名鍵175により署名されていることを証明するために認証機関116を利用することにより、プラットフォーム105がデータセンタ180に含まれているか検証してもよい」(以下、「引用記載15」という)、
同段落【0083】に、
「管理論理302は、この認証データセンタ識別秘密鍵130をデータセンタ180の署名鍵175を用いて認証するようにしてもよい」(以下、「引用記載16」という)、
との記載が存在するが、これら、引用記載14乃至引用記載16に記載の内容を加味しても、どのようにして「認証鍵」を生成しているか不明である。また、上記引用記載11乃至引用記載16以外の本願明細書等の記載内容を加味しても、どのようにして、「ルート鍵」、及び、「認証鍵」を生成しているか不明である。

(3)?(6)<省略>

以上その1の3(1)?(6)に指摘したとおりであるから、本願明細書の発明の詳細な説明は、経済産業省令で定めるところにより、その発明の属する技術分野に属する通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものでない。 <以下省略>」

その4.当審の判断
そこで、本件手続補正により、当審拒絶理由が解消したかについて以下に検討する。

(1)当審拒絶理由の理由1の1.36条6項2号について
本件手続補正により補正された本願の請求項1に係る発明は、上記項目その2.本願発明についてで引用した記載のとおりのものであるから、発明特定事項として次の構成を含むものである。

ア.「管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有」する構成、

イ.「管理部は、前記要求元のプラットフォームサーバが前記ポリシーを充足するか判断し、前記署名鍵を用いて前記秘密鍵を認証する」構成、

これに対して、当審拒絶理由の理由1の1.(3)において、平成21年11月18日付けの手続補正により補正された請求項(以下、これを「補正前の請求項」という)6について、
「b.ここでいう「署名鍵」とはどのようなものであるか不明である。
(署名アルゴリズムとして、何を採用しているかによって、署名鍵が異なり、その署名鍵を生成する手法も異なるが、本願の請求項に記載の内容では、署名鍵についての情報は、全く示されていない。) 」
との指摘をしている。
上記引用の指摘した事項が、本件手続補正によって解消しているかについて検討する。
本願の請求項1に記載の「署名鍵」は、補正前の請求項6に記載の「署名鍵」と同一のものである。
補正前の請求項6に記載の「署名鍵」について、当審拒絶理由の理由1の1.(3)において、上記引用の指摘を行っているが、本願の請求項1に記載の「署名鍵」も、本願の請求項1の記載においては、上記引用のア、及び、イに記載されている程度であり、該記載からは、本願の請求項1に記載の「署名鍵」が、「ルート鍵」から、どのようにして生成されたものであるか、及び、本願の請求項1に記載の「署名鍵」が、「秘密鍵」を、どのようにして「認証する」のか不明であり、結果、本願の請求項1に記載の「署名鍵」がどのようなものであるか、本願の請求項1に記載の内容からは不明である。
この点に関して、本件手続補正と同日に提出された意見書において、
「(3)まず、理由1(第36条第4項第1号、第6項第1号及び第2号)について、補正後の請求項1に係る発明は、図1B,5B及び関連する明細書の段落[0012]?[0015],[0055]?[0063]などの記載に基づくものであり、これらの記載に
基づき当業者が実施可能であり、また明確であると考えます。」
と述べるに止まり、上記引用の意見書の主張だけでは、依然として、本願の請求項1に記載の「署名鍵」がどのようなものであるか不明である点は解消しないので、更に、上記意見書の記載中に挙げられていた、本願明細書の段落の記載を含め、本願明細書の発明の詳細な説明を参酌すると、「署名鍵」に関しては、当審拒絶理由のその1の3.(2)において指摘したように、
「本願明細書等の段落【0014】に、
「管理者ユニット106は、認証機関116により署名されたルート鍵170を生成するようにしてもよく、これにより署名鍵175が生成される。署名鍵175は、プラットフォーム105A?105Iに保持される異なる認証データセンタ識別鍵130A?130Iの認証に利用されてもよい」(以下、「引用記載11」という)、
同段落【0056】に、
「ブロック552において、フロー図550は、データセンタ180に対するルート鍵170と署名鍵175の生成から開始される。図3に示される実施例を参照して、管理論理302は、データセンタ180に対するルート鍵170を生成する。さらに、管理論理302は、このルート鍵170を認証する認証機関116を備え、これにより署名鍵175を生成する。一実施例では、管理論理302は、RSA、Diffie-Hellmanなどの様々なタイプの暗号化処理に基づき、ルート鍵170を生成するようにしてもよい。従って、ルート鍵170はデータセンタ180の署名鍵175のみに対する鍵証明鍵として利用され、以下でより詳細に説明されるように、異なる秘密鍵が異なるプラットフォーム105に保持されるために、データセンタ180内の鍵署名鍵として利用される証明鍵175と比較して攻撃に対してより限定的となる」(以下、「引用記載12」という)、
と記載されているに止まり」、及び、
「 また、該「認証鍵」については、引用記載11、及び、引用記載12の他、
同段落【0055】に、
「そのような秘密鍵がデータセンタのための署名鍵により署名されるよう動作する」(以下、「引用記載14」という)、
同段落【0073】に、
「検証論理402は、認証データセンタ識別秘密鍵130がデータセンタ180を表す署名鍵175により署名されていることを証明するために認証機関116を利用することにより、プラットフォーム105がデータセンタ180に含まれているか検証してもよい」(以下、「引用記載15」という)、
同段落【0083】に、
「管理論理302は、この認証データセンタ識別秘密鍵130をデータセンタ180の署名鍵175を用いて認証するようにしてもよい」(以下、「引用記載16」という)、
との記載が存在する」との記載が存在する程度であり、これらの記載内容を参酌しても、本願発明における「署名鍵」がどのようなものである不明である。
よって、本願の請求項1に記載の「署名鍵」は、本件手続補正により補正された請求項1に記載の内容、及び、本願明細書の発明の詳細な説明、並びに、本件手続補正と同日に提出された意見書の内容を加味しても、依然として不明である。
次に、当審拒絶理由の理由1の1.(3)のcで指摘した、
「c.「署名鍵により前記サーバの秘密鍵に署名する」とあるが、該「秘密鍵」は、「サーバ」内の「メモリ」に保持されている。 では、「サーバ」内の「メモリ」に保持されている「秘密鍵」に対して、「管理ユニット」は、どのようにして、「署名鍵」を用いて「署名」しているのか、同請求項6、及び、他の請求項に記載の内容を加味しても不明である。」
と指摘した点について、
本願の請求項1に記載の「プラットフォームサーバ」は、補正前の請求項6に記載の「サーバ」と同一のものであることは明らかである。
そして、本願の請求項1の記載においては、「秘密鍵」は、「プラットフォームサーバ」が、自身が「信頼されていることを認証するよう要求するためのリクエストと共に」、「管理部に送信する」ものであり、該「管理部」が、送信されてきた「秘密鍵」を、「署名鍵」を用いて「認証する」構成となっている。
しかしながら、上記構成については、当審拒絶理由において、
「本願の請求項6では、サーバ側で、秘密鍵を含む暗号鍵ペアを生成している。当該技術分野の技術常識を加味すると、「暗号鍵ペア」と表現されている場合、採用されている暗号アルゴリズムは、通常“公開鍵暗号”と解される。この前提に立った場合、セキュリティ上の観点から、「秘密鍵」は、該「秘密鍵」とペアにある「公開鍵」で暗号化された情報を、サーバが受信した場合に、該暗号化情報を復号するために用いる場合と、サーバ側で、情報に該秘密鍵で署名して送信し、受信側で、該ペアとなる「公開鍵」で“署名検証”を行うための、サーバの署名鍵として用いられるものであって、該「秘密鍵」自体を、外部に送信することはない。該「サーバ」で生成した「秘密鍵」を、“認証局”などに登録するために送信する事例が皆無ではないが、その場合は、該“認証局”の“公開鍵”などで暗号化され、送信される。しかしながら、このような手法は、当業者に知られたものであったとしても、これのみに限定されるものではなく、したがって、本願の請求項に記載の内容から自明の事項ではない。 以上のとおりであるから、本願の請求項6における、「管理ユニット」による「署名」がどのように実現されているかは不明である。」(下線は当審にて説明の都合上附加したものである)と指摘しているように、当該技術分野においては、通常採用されない構成であり、且つ、敢えて採用する場合には、特別の条件を付加することが技術常識であるが、本願の請求項1に記載の内容からは、それをどのように実現しているか不明であり、よって、「秘密鍵」に対する「管理部」の「署名鍵」による「認証」をどのように実現しているか、依然として不明である。
以上のとおりであるから、本願の請求項1に記載の発明は、明確でない。

(2)当審拒絶理由のその1の3.36条4項1号について
本願の請求項1においては、単に、「前記管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有」すると記載されるに止まり、「ルート鍵」の「生成」について、本願の請求項1においては言及されていないが、本願の請求項1における「ルート鍵」と「署名鍵」が、補正前の請求項6における「ルート鍵」と「署名鍵」と同一のものであることは明らかである。
そして、「ルート鍵」、「署名鍵」に関する、上記(1)で引用したア、及び、イの構成について、本願明細書の発明の詳細な説明には、上記(1)で指摘した、当審拒絶理由のその1の3.(2)で引用した程度の記載しか存在しておらず、これらの記載内容を加味しても、どのようにして「ルート鍵」、及び、「署名鍵」を生成しているか不明である。
また、当審拒絶理由に引用した以外の本願明細書等の記載内容を加味しても、どのようにして、「ルート鍵」、及び、「署名鍵」を生成しているか不明であることは、当審拒絶理由で指摘したとおりである。
そして、本件手続補正と同日に提出された意見書には、上記(1)に引用した程度の記載しか存在しないので、当該意見書の内容を加味しても、上記指摘の点が明瞭になるものでもない。
以上のとおりであるから、本願明細書の発明な説明は、本件手続補正後においても、依然として、経済産業省令で定めるところにより、その発明の属する技術分野に属する通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものでない。

その5.むすび
したがって、本願は、特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしていない。

よって、結論のとおり審決する。
 
審理終結日 2012-03-14 
結審通知日 2012-03-21 
審決日 2012-03-28 
出願番号 特願2003-586730(P2003-586730)
審決分類 P 1 8・ 536- WZ (G06F)
P 1 8・ 537- WZ (G06F)
最終処分 不成立  
前審関与審査官 平井 誠  
特許庁審判長 赤川 誠一
特許庁審判官 石井 茂和
田中 秀人
発明の名称 データセンタへのプラットフォームの内包検証  
代理人 伊東 忠彦  
代理人 大貫 進介  
代理人 伊東 忠重  

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