【事件の表示】
　特願２００３−５８６７３０「データセンタへのプラットフォームの内包検証」拒絶査定不服審判事件〔平成１５年１０月３０日国際公開、ＷＯ０３／９００５３、平成１７年　９月１５日国内公表、特表２００５−５２７９００〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
その１．手続の経緯
　本願は、２００３年３月２８日（パリ条約による優先権主張外国庁受理２００２年４月１５日　アメリカ合衆国）を国際出願日とする出願であって、
　平成１６年１０月１３日付けで特許法第１８４条の４第１項の規定による明細書、請求の範囲、及び、図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に、同日付けで審査請求がなされ、平成２０年６月１２日付けで審査官により拒絶理由が通知され、これに対して同年９月２４日付けで意見書が提出されると共に手続補正がなされたが、平成２１年２月２７日付けで審査官により拒絶査定がなされ、これに対して同年６月１日付けで審判請求がなされると共に手続補正がなされ、同年８月１１日付けで審査官により拒絶理由が通知され、これに対して同年１１月１８日付けで意見書が提出されると共に手続補正がなされたが、平成２２年１月２９日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ、同年１１月３０日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ、平成２３年３月３日付けで回答書が提出され、同年７月４日付けで当審により拒絶理由が通知され、これに対して平成２４年１月５日付けで意見書が提出されると共に手続補正がなされたものである。
　
その２．本願発明について
　本願に係る発明は、平成２４年１月５日付けの手続補正（以下、これを「本件手続補正」という）により補正された特許請求の範囲の請求項１に記載された次のとおりのものである（以下、これを「本願発明」という）
　
「　データセンタを運営し、ユーザからの前記データセンタに対する処理要求を処理するよう構成される複数のプラットフォームサーバと、
　前記複数のプラットフォームサーバが前記データセンタのための処理を実行するのに信頼されていることを認証する管理部と、
を有するコンピュータシステムであって、
　前記複数のプラットフォームサーバは、互いに異なる秘密鍵を有し、
　前記管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有し、前記複数のプラットフォームサーバの前記データセンタへの内包に関するポリシーを格納し、
　プラットフォームサーバが、前記管理部に前記プラットフォームサーバが信頼されていることを認証するよう要求するためのリクエストを、前記要求元のプラットフォームサーバの秘密鍵と共に前記管理部に送信すると、前記管理部は、前記要求元のプラットフォームサーバが前記ポリシーを充足するか判断し、前記署名鍵を用いて前記秘密鍵を認証するコンピュータシステム。」
　
その３．当審の拒絶理由
　一方、平成２３年７月４日付けの当審による拒絶理由（以下、これを「当審拒絶理由」という）は、概略、以下のとおりである。
　
「　　　　　　　　　　　　　　理　由 
 １）本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第６項第２号、第１号及び第４項第１号に規定する要件を満たしていない。 
 ２）＜省略＞
 　 
 　　　　　　　　　　　　　　　　記 
 　 
 理由１の１．３６条６項２号について 
　（１）〜（２）＜省略＞
　
　（３）本願の請求項６に、 
 「秘密鍵を含む暗号鍵ペアを生成する処理ユニット及びサーバのポリシーを表す値を保持するレジスタを含むトークンと、前記暗号鍵を保持するメモリとからなるサーバと、前記サーバに結合され、データセンタコンピュータシステムに対するルート鍵を生成し、前記ルート鍵の認証に基づき前記データセンタコンピュータシステムに対する署名鍵を生成し、前記署名鍵により前記サーバの秘密鍵を署名する管理ユニットからなることを特徴とするデータセンタコンピュータシステム。」 
 　と記載されているが、 
 ａ．＜省略＞
 ｂ．ここでいう「署名鍵」とはどのようなものであるか不明である。 
 （署名アルゴリズムとして、何を採用しているかによって、署名鍵が異なり、その署名鍵を生成する手法も異なるが、本願の請求項に記載の内容では、署名鍵についての情報は、全く示されていない。） 
 ｃ．「署名鍵により前記サーバの秘密鍵に署名する」とあるが、該「秘密鍵」は、「サーバ」内の「メモリ」に保持されている。 
 　では、「サーバ」内の「メモリ」に保持されている「秘密鍵」に対して、「管理ユニット」は、どのようにして、「署名鍵」を用いて「署名」しているのか、同請求項６、及び、他の請求項に記載の内容を加味しても不明である。 
 （本願の請求項６では、サーバ側で、秘密鍵を含む暗号鍵ペアを生成している。当該技術分野の技術常識を加味すると、「暗号鍵ペア」と表現されている場合、採用されている暗号アルゴリズムは、通常“公開鍵暗号”と解される。この前提に立った場合、セキュリティ上の観点から、「秘密鍵」は、該「秘密鍵」とペアにある「公開鍵」で暗号化された情報を、サーバが受信した場合に、該暗号化情報を復号するために用いる場合と、サーバ側で、情報に該秘密鍵で署名して送信し、受信側で、該ペアとなる「公開鍵」で“署名検証”を行うための、サーバの署名鍵として用いられるものであって、該「秘密鍵」自体を、外部に送信することはない。該「サーバ」で生成した「秘密鍵」を、“認証局”などに登録するために送信する事例が皆無ではないが、その場合は、該“認証局”の“公開鍵”などで暗号化され、送信される。しかしながら、このような手法は、当業者に知られたものであったとしても、これのみに限定されるものではなく、したがって、本願の請求項に記載の内容から自明の事項ではない。 
 　以上のとおりであるから、本願の請求項６における、「管理ユニット」による「署名」がどのように実現されているかは不明である。）
　
（４）〜（６）＜省略＞
　
その１の２．３６条６項１号について 
（１）〜（３）＜省略＞
　
その１の３．３６条４項１号について 
（１）＜省略＞
　
（２）本願の請求項６に記載の、 
 「データセンタコンピュータシステムに対するルート鍵を生成」すること、 
 「ルート鍵の認証に基づき前記データセンタコンピュータシステムに対する署名鍵を生成」すること、 
 　について、これらは、同請求項６に記載の内容から、同請求項６に記載の発明においては、「管理ユニット」によってなされるものであると解されるが、 
 　上記「管理ユニット」による「データセンタコンピュータシステムに対するルート鍵」、及び、「データセンタコンピュータシステムに対する署名鍵」の生成については、本願明細書等の段落【００１４】に、 
 「管理者ユニット１０６は、認証機関１１６により署名されたルート鍵１７０を生成するようにしてもよく、これにより署名鍵１７５が生成される。署名鍵１７５は、プラットフォーム１０５Ａ〜１０５Ｉに保持される異なる認証データセンタ識別鍵１３０Ａ〜１３０Ｉの認証に利用されてもよい」（以下、「引用記載１１」という）、 
 　同段落【００５６】に、 
 「ブロック５５２において、フロー図５５０は、データセンタ１８０に対するルート鍵１７０と署名鍵１７５の生成から開始される。図３に示される実施例を参照して、管理論理３０２は、データセンタ１８０に対するルート鍵１７０を生成する。さらに、管理論理３０２は、このルート鍵１７０を認証する認証機関１１６を備え、これにより署名鍵１７５を生成する。一実施例では、管理論理３０２は、ＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなどの様々なタイプの暗号化処理に基づき、ルート鍵１７０を生成するようにしてもよい。従って、ルート鍵１７０はデータセンタ１８０の署名鍵１７５のみに対する鍵証明鍵として利用され、以下でより詳細に説明されるように、異なる秘密鍵が異なるプラットフォーム１０５に保持されるために、データセンタ１８０内の鍵署名鍵として利用される証明鍵１７５と比較して攻撃に対してより限定的となる」（以下、「引用記載１２」という）、 
 　と記載されているに止まり、これら引用記載１１、及び、引用記載１２を参照しても、 
 「ルート鍵１７０」をどのように生成し、「ルート鍵１７０」を生成することで、どのようにして、「署名鍵１７５」を生成しているのか不明である。 
 　ここで、引用記載１２に、「ルート鍵１７０」の生成手法として、 
 「管理論理３０２は、ＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなどの様々なタイプの暗号化処理に基づき、ルート鍵１７０を生成するようにしてもよい」、 
 　との記載があるが、ＲＳＡ公開鍵生成を行った場合、必ず、“公開鍵”と“個別鍵”が生成される。 
 　それでは、該「ルート鍵１７０」は、ＲＳＡを用いた場合、“公開鍵”なのか“個別鍵”なのか不明である。 
 　また、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵共有を用いた場合には、“誰”、或いは、“何”との間で、共有する鍵の計算を行っているか不明であり、 
 　結果として、どのようにして、「ルート鍵１７０」を求めているか不明である。 
 　また、引用記載１２によれば、「署名鍵１７５」は、「ルート鍵１７０を認証する認証機関１１６を備え、これにより署名鍵１７５を生成する」との記載から、「認証機関１１６」が生成しているとも読めるが、該「認証機関１１６」は、どのようにして、「ルート鍵１７０」から、「署名鍵１７５」を生成しているのか、引用記載１１、及び、引用記載１２に記載の内容からは不明である。 
 　ここで、該「ルート鍵」については、引用記載１１、及び、引用記載１２の他、 
 　同段落【００２９】に、 
 「一実施例では、この安全な環境は、それに関連するメモリ部分におけるデータの保持及び抽出に利用される対応するルート暗号鍵を有する。一実施例では、ルート暗号鍵は、トークン２５０（図示せず）に保持される永久公開鍵とＰＣＲ２５５の１つに保持されるダイジェスト値に基づく。一実施例では、ルート暗号鍵は、ダイジェスト値が暗号化の一部として保持されるように、永久公開鍵により暗号化される。従って、このルート暗号鍵は、保持されているダイジェスト値がＰＣＲ２５５に現在保持されているダイジェスト値と一致するとき、永久公開鍵を利用した解読に基づき利用することができる。従って、以下で詳細に説明されるように、データセンタに対する秘密鍵（データセンタ秘密鍵１２０と認証データセンタ秘密鍵１３０）は、ルート暗号鍵による暗号化処理に基づく安全な環境と関連付けされたプラットフォーム１０４／１０５内のメモリ部分への格納及び抽出が行われる」（以下、「引用記載１３」という）、 
 　との記載があるが、引用記載１３における「ルート暗号鍵」と、引用記載１１、或いは、引用記載１２における「ルート鍵１７０」とが、同一のものか不明であり、また、引用記載１３における、 
 「ルート暗号鍵は、トークン２５０（図示せず）に保持される永久公開鍵とＰＣＲ２５５の１つに保持されるダイジェスト値に基づく」、 
 　との記載のみからでは、該「ルート暗号鍵」が、どのようなもので、どのように生成されているか不明である。 
 　また、該「認証鍵」については、引用記載１１、及び、引用記載１２の他、 
 　同段落【００５５】に、 
 「そのような秘密鍵がデータセンタのための署名鍵により署名されるよう動作する」（以下、「引用記載１４」という）、 
 　同段落【００７３】に、 
 「検証論理４０２は、認証データセンタ識別秘密鍵１３０がデータセンタ１８０を表す署名鍵１７５により署名されていることを証明するために認証機関１１６を利用することにより、プラットフォーム１０５がデータセンタ１８０に含まれているか検証してもよい」（以下、「引用記載１５」という）、 
 　同段落【００８３】に、 
 「管理論理３０２は、この認証データセンタ識別秘密鍵１３０をデータセンタ１８０の署名鍵１７５を用いて認証するようにしてもよい」（以下、「引用記載１６」という）、 
 　との記載が存在するが、これら、引用記載１４乃至引用記載１６に記載の内容を加味しても、どのようにして「認証鍵」を生成しているか不明である。また、上記引用記載１１乃至引用記載１６以外の本願明細書等の記載内容を加味しても、どのようにして、「ルート鍵」、及び、「認証鍵」を生成しているか不明である。 
　
（３）〜（６）＜省略＞
　
　以上その１の３（１）〜（６）に指摘したとおりであるから、本願明細書の発明の詳細な説明は、経済産業省令で定めるところにより、その発明の属する技術分野に属する通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものでない。 ＜以下省略＞」
　
その４．当審の判断
　そこで、本件手続補正により、当審拒絶理由が解消したかについて以下に検討する。
　
（１）当審拒絶理由の理由１の１．３６条６項２号について
　本件手続補正により補正された本願の請求項１に係る発明は、上記項目その２．本願発明についてで引用した記載のとおりのものであるから、発明特定事項として次の構成を含むものである。
　
ア．「管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有」する構成、
　
イ．「管理部は、前記要求元のプラットフォームサーバが前記ポリシーを充足するか判断し、前記署名鍵を用いて前記秘密鍵を認証する」構成、
　
　これに対して、当審拒絶理由の理由１の１．（３）において、平成２１年１１月１８日付けの手続補正により補正された請求項（以下、これを「補正前の請求項」という）６について、
「ｂ．ここでいう「署名鍵」とはどのようなものであるか不明である。 
 （署名アルゴリズムとして、何を採用しているかによって、署名鍵が異なり、その署名鍵を生成する手法も異なるが、本願の請求項に記載の内容では、署名鍵についての情報は、全く示されていない。） 」
　との指摘をしている。
　上記引用の指摘した事項が、本件手続補正によって解消しているかについて検討する。
　本願の請求項１に記載の「署名鍵」は、補正前の請求項６に記載の「署名鍵」と同一のものである。
　補正前の請求項６に記載の「署名鍵」について、当審拒絶理由の理由１の１．（３）において、上記引用の指摘を行っているが、本願の請求項１に記載の「署名鍵」も、本願の請求項１の記載においては、上記引用のア、及び、イに記載されている程度であり、該記載からは、本願の請求項１に記載の「署名鍵」が、「ルート鍵」から、どのようにして生成されたものであるか、及び、本願の請求項１に記載の「署名鍵」が、「秘密鍵」を、どのようにして「認証する」のか不明であり、結果、本願の請求項１に記載の「署名鍵」がどのようなものであるか、本願の請求項１に記載の内容からは不明である。
　この点に関して、本件手続補正と同日に提出された意見書において、
「（３）まず、理由１（第３６条第４項第１号、第６項第１号及び第２号）について、補正後の請求項１に係る発明は、図１Ｂ，５Ｂ及び関連する明細書の段落［００１２］〜［００１５］，［００５５］〜［００６３］などの記載に基づくものであり、これらの記載に
基づき当業者が実施可能であり、また明確であると考えます。」
　と述べるに止まり、上記引用の意見書の主張だけでは、依然として、本願の請求項１に記載の「署名鍵」がどのようなものであるか不明である点は解消しないので、更に、上記意見書の記載中に挙げられていた、本願明細書の段落の記載を含め、本願明細書の発明の詳細な説明を参酌すると、「署名鍵」に関しては、当審拒絶理由のその１の３．（２）において指摘したように、
「本願明細書等の段落【００１４】に、 
 「管理者ユニット１０６は、認証機関１１６により署名されたルート鍵１７０を生成するようにしてもよく、これにより署名鍵１７５が生成される。署名鍵１７５は、プラットフォーム１０５Ａ〜１０５Ｉに保持される異なる認証データセンタ識別鍵１３０Ａ〜１３０Ｉの認証に利用されてもよい」（以下、「引用記載１１」という）、 
 　同段落【００５６】に、 
　「ブロック５５２において、フロー図５５０は、データセンタ１８０に対するルート鍵１７０と署名鍵１７５の生成から開始される。図３に示される実施例を参照して、管理論理３０２は、データセンタ１８０に対するルート鍵１７０を生成する。さらに、管理論理３０２は、このルート鍵１７０を認証する認証機関１１６を備え、これにより署名鍵１７５を生成する。一実施例では、管理論理３０２は、ＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなどの様々なタイプの暗号化処理に基づき、ルート鍵１７０を生成するようにしてもよい。従って、ルート鍵１７０はデータセンタ１８０の署名鍵１７５のみに対する鍵証明鍵として利用され、以下でより詳細に説明されるように、異なる秘密鍵が異なるプラットフォーム１０５に保持されるために、データセンタ１８０内の鍵署名鍵として利用される証明鍵１７５と比較して攻撃に対してより限定的となる」（以下、「引用記載１２」という）、 
 　と記載されているに止まり」、及び、
「　また、該「認証鍵」については、引用記載１１、及び、引用記載１２の他、 
 　同段落【００５５】に、 
 「そのような秘密鍵がデータセンタのための署名鍵により署名されるよう動作する」（以下、「引用記載１４」という）、 
 　同段落【００７３】に、 
 「検証論理４０２は、認証データセンタ識別秘密鍵１３０がデータセンタ１８０を表す署名鍵１７５により署名されていることを証明するために認証機関１１６を利用することにより、プラットフォーム１０５がデータセンタ１８０に含まれているか検証してもよい」（以下、「引用記載１５」という）、 
 　同段落【００８３】に、 
 「管理論理３０２は、この認証データセンタ識別秘密鍵１３０をデータセンタ１８０の署名鍵１７５を用いて認証するようにしてもよい」（以下、「引用記載１６」という）、 
 　との記載が存在する」との記載が存在する程度であり、これらの記載内容を参酌しても、本願発明における「署名鍵」がどのようなものである不明である。
　よって、本願の請求項１に記載の「署名鍵」は、本件手続補正により補正された請求項１に記載の内容、及び、本願明細書の発明の詳細な説明、並びに、本件手続補正と同日に提出された意見書の内容を加味しても、依然として不明である。
　次に、当審拒絶理由の理由１の１．（３）のｃで指摘した、
「ｃ．「署名鍵により前記サーバの秘密鍵に署名する」とあるが、該「秘密鍵」は、「サーバ」内の「メモリ」に保持されている。 では、「サーバ」内の「メモリ」に保持されている「秘密鍵」に対して、「管理ユニット」は、どのようにして、「署名鍵」を用いて「署名」しているのか、同請求項６、及び、他の請求項に記載の内容を加味しても不明である。」
　と指摘した点について、
　本願の請求項１に記載の「プラットフォームサーバ」は、補正前の請求項６に記載の「サーバ」と同一のものであることは明らかである。
　そして、本願の請求項１の記載においては、「秘密鍵」は、「プラットフォームサーバ」が、自身が「信頼されていることを認証するよう要求するためのリクエストと共に」、「管理部に送信する」ものであり、該「管理部」が、送信されてきた「秘密鍵」を、「署名鍵」を用いて「認証する」構成となっている。
　しかしながら、上記構成については、当審拒絶理由において、
「本願の請求項６では、サーバ側で、秘密鍵を含む暗号鍵ペアを生成している。当該技術分野の技術常識を加味すると、「暗号鍵ペア」と表現されている場合、採用されている暗号アルゴリズムは、通常“公開鍵暗号”と解される。この前提に立った場合、セキュリティ上の観点から、「秘密鍵」は、該「秘密鍵」とペアにある「公開鍵」で暗号化された情報を、サーバが受信した場合に、該暗号化情報を復号するために用いる場合と、サーバ側で、情報に該秘密鍵で署名して送信し、受信側で、該ペアとなる「公開鍵」で“署名検証”を行うための、サーバの署名鍵として用いられるものであって、
該「秘密鍵」自体を、外部に送信することはない。該「サーバ」で生成した「秘密鍵」を、“認証局”などに登録するために送信する事例が皆無ではないが、その場合は、該“認証局”の“公開鍵”などで暗号化され、送信される。しかしながら、このような手法は、当業者に知られたものであったとしても、これのみに限定されるものではなく、したがって、本願の請求項に記載の内容から自明の事項ではない。 以上のとおりであるから、本願の請求項６における、「管理ユニット」による「署名」がどのように実現されているかは不明である
　以上のとおりであるから、本願の請求項１に記載の発明は、明確でない。
　
（２）当審拒絶理由のその１の３．３６条４項１号について
　本願の請求項１においては、単に、「前記管理部は、当該コンピュータシステムに対するルート鍵と、前記ルート鍵から生成される署名鍵とを有」すると記載されるに止まり、「ルート鍵」の「生成」について、本願の請求項１においては言及されていないが、本願の請求項１における「ルート鍵」と「署名鍵」が、補正前の請求項６における「ルート鍵」と「署名鍵」と同一のものであることは明らかである。
　そして、「ルート鍵」、「署名鍵」に関する、上記（１）で引用したア、及び、イの構成について、本願明細書の発明の詳細な説明には、上記（１）で指摘した、当審拒絶理由のその１の３．（２）で引用した程度の記載しか存在しておらず、これらの記載内容を加味しても、どのようにして「ルート鍵」、及び、「署名鍵」を生成しているか不明である。
　また、当審拒絶理由に引用した以外の本願明細書等の記載内容を加味しても、どのようにして、「ルート鍵」、及び、「署名鍵」を生成しているか不明であることは、当審拒絶理由で指摘したとおりである。
　そして、本件手続補正と同日に提出された意見書には、上記（１）に引用した程度の記載しか存在しないので、当該意見書の内容を加味しても、上記指摘の点が明瞭になるものでもない。
　以上のとおりであるから、本願明細書の発明な説明は、本件手続補正後においても、依然として、経済産業省令で定めるところにより、その発明の属する技術分野に属する通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものでない。
　
その５．むすび
　したがって、本願は、特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　
　よって、結論のとおり審決する。