【事件の表示】
　特願２０１０−２４３２２８「データセンタへのプラットフォームの内包検証」拒絶査定不服審判事件〔平成２３年　３月３１日出願公開，特開２０１１−　６５６６５〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００３年３月２８日（パリ条約による優先権主張外国庁受理２００２年４月１５日　アメリカ合衆国）を国際出願日とする特願２００３−５８６７３０号の一部を，平成２１年６月３０日に新たな出願とした特願２００９−１５４９９１号の一部を，平成２２年１０月２９日に新たな出願としたものであって，
　平成２２年１０月２９日付けで審査請求がなされ，平成２５年１月２１日付けで審査官により拒絶理由が通知され，これに対して平成２５年７月２６日付けで意見書が提出されると共に手続補正がなされたが，平成２５年９月２４日付けで審査官により拒絶査定がなされ（発送；平成２５年１０月１日），これに対して平成２６年２月３日付けで審判請求がなされると共に手続補正がなされ，平成２６年４月２日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２６年２月３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。
　
「【請求項１】
　サーバがデータセンタコンピュータシステム内に包含されているか検証する方法であって，
　前記サーバに含まれるプラットフォームキーアプリケーションロジックが，前記包含されているか検証するための引用リクエストを受信するステップであって，前記引用リクエストは，前記サーバのポリシーを表す値であって，前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ（ＰＣＲ）に保持される前記値に対するリクエストを含む，前記引用リクエストを受信するステップと，
　前記プラットフォームキーアプリケーションロジックが，前記値を抽出するステップと，
　前記サーバに含まれるプロセッサが，前記サーバに保持される暗号鍵ペアの秘密鍵を用いて前記値を署名するステップと，
　前記プラットフォームキーアプリケーションロジックが，前記サーバに含まれるネットワークコントローラを用いて，前記引用リクエストに応答して前記署名された値を出力するステップとを有することを特徴とする方法。」
　
第３．引用刊行物に記載の発明
　一方，原審が，平成２５年１月２１日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用した，本願の原出願の第１国出願前に既に公知である，国際公開第００／５４１２６号（２０００年９月１４日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「 On the other hand, for business use in many applications, a server platform provides centralized data storage, and application functionality for a plurality of client stations. For business use, key criteria are reliability, networking features, and security features. For such platforms, the Microsoft Windows NT 4.0ＴＭ operating system is common, as well as the UnixＴＭ operating system. 
　With the increase in commercial activity transacted over the Internet, known as “e-commerce”, there has been much interest in the prior art in enabling data transactions between computing platforms over the Internet of both domestic and commercial types. A fundamental issue in acceptance of such systems is the one of trust between interacting computer platforms for the making of such transactions.」（１頁２０行〜２９行）
（   【０００３】
　一方，多くのアプリケーションにおけるビジネス使用に関しては，サーバ・プラットフォームが，集中的データ記憶装置および複数のクライアント・ステーションのためのアプリケーション機能性を提供する。ビジネス用途に関する重要な基準は，信頼性，ネットワーキング機能およびセキュリティ機能である。そのようなプラットフォームとして，Ｕｎｉｘオペレーティング・システムと共に，マイクロソフト・ウインドウズＮＴ４.０が広く使用されている。
      【０００４】
　“電子商取引”として知られているインターネット上で取り引きされる商業活動の増加に伴って，家庭用および商取引用タイプ両方のインターネット上でコンピュータ・プラットフォーム間のデータ・トランザクション(取引)を可能にすることに大きな関心が寄せられている。そのようなシステムを受け入れる場合の基本的問題は，そのようなトランザクションを処理するため相互に対話するコンピュータ・プラットフォーム間の信頼性の問題である。引用刊行物１のファミリである，特表２００２-５３９６５６号公報の当該箇所より引用。以下，同じ。）
　
Ｂ．「　A “trusted platform” used in preferred embodiments of the invention will now be described. This is achieved by the incorporation into a computing platform of a physical trusted device whose function is to bind the identity of the platform to reliably measured data that provides an integrity metric of the platform. The identity and the integrity metric are compared with expected values provided by a trusted party (TP) that is prepared to vouch for the trustworthiness of the platform. If there is a match, the implication is that at least part of the platform is operating correctly, depending on the scope of the integrity metric.」（１２頁２４行〜３１行）
（     【００３９】
　本発明の実施形態において使用される“信頼できるプラットフォーム”をここで説明する。これは，物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される。この物理的な信頼できる装置は，プラットフォームの信頼性メトリックを提供する測定されたデータにプラットフォームの識別を結合する機能を有する。これら識別情報および信頼性メトリックが，プラットフォームの信頼性を保証するように準備されている信頼できる機関によって提供される期待値と比較される。(注：以下の記述において，“信頼できる機関”は，その英語表記である“trusted party”の頭文字をとって“ＴＰ”と略称される場合がある。) 一致すれば，信頼性メトリックの範囲に応じて，少なくともプラットフォームの一部が正しく動作していることを意味する。）
　
Ｃ．「　Although, in the preferred embodiment to be described, the trusted device 24 is a single, discrete component, it is envisaged that the functions of the trusted device 24 may alternatively be split into multiple devices on the motherboard, or even integrated into one or more of the existing standard devices of the platform. For example, it is feasible to integrate one or more of the functions of the trusted device into the main processor itself, provided that the functions and their communications cannot be subverted. This, however, would probably require separate leads on the processor for sole use by the trusted functions. Additionally or alternatively, although in the present embodiment the trusted device is a hardware device that is adapted for integration into the motherboard 20, it is anticipated that a trusted device may be implemented as a ‘removable' device, such as a dongle, which could be attached to a platform when required. Whether the trusted device is integrated or removable is a matter of design choice. However, where the trusted device is separable, a mechanism for providing a logical binding between the trusted device and the platform should be present.」（１５頁２９行〜１６頁７行）
（   【００５２】
　以下に記述される好ましい実施形態において，信頼できる装置２４が単一の，離散的なコンポーネントであるとはいえ，代替的形態として信頼できる装置２４の機能をマザーボード上の複数の装置に分割することも，あるいは，プラットフォームの従来型標準装置の１つまたは複数に組み込むことさえ可能である。例えば，諸機能およびそれら対話が破壊されることができないと仮定すれば，主プロセッサに信頼できる装置の１つまたは複数の機能を主プロセッサに統合することは可能である。しかしながら，この構成は，プロセッサが信頼できる機能によってのみ使用されることを必要とすることになるであろう。更に，本実施形態において，信頼できる装置はマザーボード２０への統合に適応されるハードウェア装置であるが，代替的に，必要に応じてプラットフォームに接続することができるドングルのような取り外し可能な装置として実施することも可能である。信頼できる装置が統合された装置か取り外し可能な装置かは設計選択の問題である。しかしながら，信頼できる装置が分離できるものである場合，信頼できる装置とプラットフォームの間の論理的結合を提供するメカニズムが存在しなければならない。）
　
Ｄ．「　Specifically, the trusted device comprises: a controller 30 programmed to control the overall operation of the trusted device 24, and interact with the other functions on the trusted device 24 and with the other devices on the motherboard 20; a measurement function 31 for acquiring the integrity metric from the platform 10; a cryptographic function 32 for signing, encrypting or decrypting specified data; an authentication function 33 for authenticating a smart card; and interface circuitry 34 having appropriate ports (36, 37  38) for connecting the trusted device 24 respectively to the data bus 26, control lines 27 and address lines 28 of the motherboard 20. Each of the blocks in the trusted device 24 has access (typically via the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the trusted device 24. Additionally, the trusted device 24 is designed, in a known manner, to be tamper resistant.」（１６頁１８行〜２９行）
（   【００５４】
　信頼できる装置は，具体的には，信頼できる装置２４の動作全体を制御し，信頼できる装置２４のその他の機能およびマザーボード２０のその他の装置と対話するようにプログラムされたコントローラ３０，プラットフォーム１０から信頼性メトリックを取得する測定機能３１，指定されたデータを署名，暗号化または解読する暗号機能３２，スマートカードを認証する認証機能３３，および，適切なポート(３６，３７，３８)を有し，マザーボード２０のデータ・バス２６，制御線２７，およびアドレス線２８のそれぞれに信頼できる装置２４を接続するインタフェース回路３４を備える。信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ。更に，信頼できる装置２４は，周知の形態で，不正抵抗性を持つように設計される。）
　
Ｅ．「　The measurement function 31 has access to: non-volatile memory 3 for storing a hash program 354 and a private key 355 of the trusted device 24, and volatile memory 4 for storing acquired integrity metric in the form of a digest 361. In appropriate embodiments, the volatile memory 4 may also be used to store the public keys and associated ID labels 360a-360n of one or more authentic smart cards 19s that can be used to gain access to the platform 10.」（１７頁２２行〜２７行）
（　【００５８】
　測定機能３１は，ハッシュ・プログラム３５４および信頼できる装置２４の秘密鍵３５５を保存する不揮発性メモリ３および取得した信頼性メトリックをダイジェスト３６１の形態で保存する揮発性メモリ４にアクセスする。また，適切な実施形態において，揮発性メモリ４は，プラットフォーム１０へのアクセスを取得するために使用されることができる１つまたは複数の真正スマートカードの公開暗号鍵および関連ＩＤラベル３６０ａ−３６０ｎを記憶するためにも使用される。）
　
Ｆ．「　At the first instance, a TP, which vouches for trusted platforms, will inspect the type of the platform to decide whether to vouch for it or not. This will be a matter of policy. If all is well, in step 500, the TP measures the value of integrity metric of the platform. Then, the TP generates a certificate, in step 505, for the platform. The certificate is generated by the TP by appending the trusted device's public key, and optionally its ID label, to the measured integrity metric, and signing the string with the TP's private key.」（２０頁１２行〜１８行）
（   【００６８】
　先ず，信頼できるプラットフォームを保証するＴＰ(信頼できる機関)が，保証すべきか否かを決定するためそのプラットフォームのタイプを調べる。これは，ポリシの問題である。すべてがよければ，ステップ５００において，ＴＰがプラットフォームの信頼性メトリックの値を測定する。次に，ＴＰは，ステップ５０５において，プラットフォームに関する認証書を生成する。認証書の生成は，信頼できる装置の公開暗号鍵およびオプションとしてそのＩＤラベルを測定された信頼性メトリックに追加し，ＴＰの秘密鍵でストリングスを署名することによって行われる。）
　
Ｇ．「　When a user wishes to communicate with the platform, in step 520, he creates a nonce, such as a random number, and, in step 525, challenges the trusted device 24 (the operating system of the platform, or an appropriate software application, is arranged to recognise the challenge and pass it to the trusted device 24, typically via a BIOS-type call, in an appropriate fashion). The nonce is used to protect the user from deception caused by replay of old but genuine signatures (called a 'replay attack') by untrustworthy platforms. The process of providing a nonce and verifying the response is an example of the well-known “challenge/response” process. 
　In step 530, the trusted device 24 receives the challenge and creates an appropriate response. This may be a digest of the measured integrity metric and the nonce, and optionally its ID label. Then, in step 535, the trusted device 24 signs the digest, using its private key, and returns the signed digest, accompanied by the certificate 350, to the user.
　In step 540, the user receives the challenge response and verifies the certificate using the well known public key of the TP. The user then, in step 550, extracts the trusted device's 24 public key from the certificate and uses it to decrypt the signed digest from the challenge response. Then, in step 560, the user verifies the nonce inside the challenge response. Next, in step 570, the user compares the computed integrity metric, which it extracts from the challenge response, with the proper platform integrity metric, which it extracts from the certificate. If any of the foregoing verification steps fails, in steps 545, 555, 565 or 575, the whole process ends in step 580 with no further communications taking place.」（２１頁６行〜２８行）
（   【００７２】
　ユーザは，プラットフォームとの通信を望む時，ステップ５２０において，乱数のような一時的ワードを作成し，ステップ５２５において，信頼できる装置２４にチャレンジ(呼びかけ)を行う(プラットフォームのオペレーティング・システムまたは適切なソフトウェア・アプリケーションは，チャレンジを認識して適切な形態で典型的にはＢＩＯＳ呼び出しを介して信頼できる装置２４へそれを渡すように構成されている)。一時的ワードは，信頼できないプラットフォームによる古いが真正な署名に起因する欺瞞(返信攻撃と呼ばれる)からユーザを保護するために使用される。一時的ワードを提供して応答を検証するプロセスは，周知の“チャレンジ／応答”プロセスの１例である。
　   【００７３】
　ステップ５３０において，信頼できる装置２４は，チャレンジを受け取り，該当する応答を作成する。応答は，測定された信頼性メトリックと一時的ワードのダイジェスト，および，オプションとして，そのＩＤラベルである。次に，ステップ５３５において，その秘密鍵を使用して，信頼できる装置２４は，ダイジェストに署名し，認証書３５０と共に，署名されたダイジェストをユーザに送り返す。
     【００７４】
　ステップ５４０において，ユーザはチャレンジの応答を受け取り，ＴＰの既知の公開暗号鍵を使用して認証書を検証する。次に，ユーザは，ステップ５５０において，認証書から信頼できる装置２４の公開暗号鍵を抽出して，それを使用してチャレンジ応答から署名されたダイジェストを解読する。次に，ステップ５６０において，ユーザは，チャレンジ応答の中の一時的ワードを検証する。次に，ステップ５７０において，ユーザは，(チャレンジ応答から取り出した)計算された信頼性メトリックを(認証書から抽出した)該当するプラットフォーム信頼性メトリックと比較する。ステップ５４５，５５５，５６５または５７５における前記検証のいずれかが失敗すれば，全ステップはステップ５８０で終了しそれ以上の通信は行われない。）
　
１．上記Ａの「 for business use in many applications, a server platform provides centralized data storage, and application functionality for a plurality of client stations（多くのアプリケーションにおけるビジネス使用に関しては，サーバ・プラットフォームが，集中的データ記憶装置および複数のクライアント・ステーションのためのアプリケーション機能性を提供する）」という記載，同じく上記Ａの「With the increase in commercial activity transacted over the Internet, known as “e-commerce”, there has been much interest in the prior art in enabling data transactions between computing platforms over the Internet of both domestic and commercial types.  A fundamental issue in acceptance of such systems is the one of trust between interacting computer platforms for the making of such transactions（“電子商取引”として知られているインターネット上で取り引きされる商業活動の増加に伴って，家庭用および商取引用タイプ両方のインターネット上でコンピュータ・プラットフォーム間のデータ・トランザクション(取引)を可能にすることに大きな関心が寄せられている。そのようなシステムを受け入れる場合の基本的問題は，そのようなトランザクションを処理するため相互に対話するコンピュータ・プラットフォーム間の信頼性の問題である）」という記載から，引用刊行物１は，“サーバ，クライアントである，複数のコンピュータ・プラットフォームから構成されるシステムにおける，複数のコンピュータ・プラットフォーム間の信頼性に関するものである”ことが読み取れる。
　
２．上記Ｂの「A “trusted platform” used in preferred embodiments of the invention will now be described. This is achieved by the incorporation into a computing platform of a physical trusted device（本発明の実施形態において使用される“信頼できるプラットフォーム”をここで説明する。これは，物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される）」という記載から，引用刊行物１においては，
“コンピュータ・プラットフォームに，物理的に信頼できる装置が含まれる”ことが読み取れる。
　
３．上記Ｄの「the trusted device comprises: a controller 30 programmed to control the overall operation of the trusted device 24, and interact with the other functions on the trusted device 24 and with the other devices on the motherboard 20; a measurement function 31 for acquiring the integrity metric from the platform 10; a cryptographic function 32 for signing, encrypting or decrypting specified data; ・・・ and interface circuitry 34 having appropriate ports (36, 37  38) for connecting the trusted device 24 respectively to the data bus 26, control lines 27 and address lines 28 of the motherboard 20（信頼できる装置は，信頼できる装置２４の動作全体を制御し，信頼できる装置２４のその他の機能およびマザーボード２０のその他の装置と対話するようにプログラムされたコントローラ３０，プラットフォーム１０から信頼性メトリックを取得する測定機能３１，指定されたデータを署名，暗号化または解読する暗号機能３２・・・および，適切なポート(３６，３７，３８)を有し，マザーボード２０のデータ・バス２６，制御線２７，およびアドレス線２８のそれぞれに信頼できる装置２４を接続するインタフェース回路３４を備える）」という記載，及び，同じく上記Ｄの「Each of the blocks in the trusted device 24 has access (typically via the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the trusted device 24（信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ）」という記載から，引用刊行物１においては，
“信頼できる装置は，コントローラ，測定機能，暗号機能，及び，マザーボードと接続するためのインタフェース回路，並びに，揮発性メモリ領域，及び，不揮発性メモリ領域を有している”ことが読み取れ，
　上記Ｅの「The measurement function 31 has access to: non-volatile memory 3 for storing a hash program 354 and a private key 355 of the trusted device 24, and volatile memory 4 for storing acquired integrity metric in the form of a digest 361（測定機能３１は，ハッシュ・プログラム３５４および信頼できる装置２４の秘密鍵３５５を保存する不揮発性メモリ３および取得した信頼性メトリックをダイジェスト３６１の形態で保存する揮発性メモリ４にアクセスする）」という記載から，引用刊行物１においては，
“信頼性メトリックが，揮発性メモリに保存されている”ことが読み取れ，上記Ｄの記載内容において検討した事項と併せると，引用刊行物１においては，
“信頼性メトリックが，信頼できる装置が有するメモリに保存されている”ことが読み取れる。
　
４．上記Ｇの「In step 530, the trusted device 24 receives the challenge and creates an appropriate response. This may be a digest of the measured integrity metric and the nonce, and optionally its ID label. Then, in step 535, the trusted device 24 signs the digest, using its private key, and returns the signed digest, accompanied by the certificate 350, to the user（ステップ５３０において，信頼できる装置２４は，チャレンジを受け取り，該当する応答を作成する。応答は，測定された信頼性メトリックと一時的ワードのダイジェスト，および，オプションとして，そのＩＤラベルである。次に，ステップ５３５において，その秘密鍵を使用して，信頼できる装置２４は，ダイジェストに署名し，認証書３５０と共に，署名されたダイジェストをユーザに送り返す）」という記載から，引用刊行物１においては，
“信頼できる装置は，チャレンジを受取り，測定された信頼性メトリックと一時的ワードとのダイジェストを生成し，前記ダイジェストに，信頼できる装置の秘密鍵を使用して署名し，署名されたダイジェストと，認証書とをユーザに送り返す”ことが読み取れる。
　
５．上記３．において引用した，上記Ｄの記載内容から，引用刊行物１においては，
“信頼できる装置が有するコントローラが，信頼できる装置の外側にあるマザーボード，或いは，その他の装置に，インタフェース回路を用いてアクセスする”ことが読み取れ，更に，上記Ｄの「 Each of the blocks in the trusted device 24 has access (typically via the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the trusted device 24（信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ）」という記載内容から，引用刊行物１においては，
“コントローラは，信頼できる装置内の各ブロックからの要求に応じて，メモリにアクセスする”ことが読み取れるので，上記３．，及び，４．において検討した事項と併せると，引用刊行物１においては，
“信頼できる装置は，チャレンジを受取り，前記信頼できる装置が有するメモリにアクセスして，測定された信頼性メトリックを読み出し，前記測定された信頼性メトリックと，一時ワードのダイジェストを作成して，前記ダイジェストに，前記信頼できる装置の秘密鍵で署名して，前記信頼できる装置のインタフェース回路を介して，前記信頼できる装置の外部に出力する”ものであることが読み取れる。
　
６．上記１．において検討した事項と，上記２．〜５．において検討した事項から，
　引用刊行物１は，“サーバ，クライアントである，複数のコンピュータ・プラットフォームから構成されるシステムにおける，複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法”に関するものであることは明らかである。
　
　以上１．〜６．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　サーバ，クライアントである，複数のコンピュータ・プラットフォームから構成されるシステムにおける，複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法であって，
　コンピュータ・プラットフォームに含まれる，物理的に信頼できる装置が，チャレンジを受取り，
　前記信頼できる装置が有するメモリにアクセスして，測定された信頼性メトリックを読み出し，
　前記測定された信頼性メトリックと，一時ワードのダイジェストを作成して，前記ダイジェストに，前記信頼できる装置の秘密鍵で署名し，
　前記信頼できる装置のインタフェース回路を介して，前記信頼できる装置の外部に出力する，方法。
　
第４．本願発明と引用発明との対比
１．引用発明における「複数のコンピュータ・プラットフォーム」は，「サーバ」となり得るものであるから，本願発明における「サーバ」に相当するので，
　引用発明における「サーバ，クライアントである，複数のコンピュータ・プラットフォームから構成されるシステムにおける，複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法」と，
　本願発明における「サーバがデータセンタコンピュータシステム内に包含されているか検証する方法」とは，
“サーバが，所定の条件を満たすものであるかを検証する方法”である点で共通する。
　
２．引用発明における「チャレンジ」は，前記「チャレンジ」を受け取った「信頼できる装置」が，「信頼性メトリック」を外部に出力しているので，前記「信頼性メトリック」の送信を「要求」するための「リクエスト」と言い得るものであり，且つ，前記「チャレンジ」は，引用発明において，「コンピュータ・プラットフォーム」の「信頼性」を検証するためのものである。
　そして，引用発明における「信頼性メトリック」は，前記「信頼できる装置」の「メモリ」に保存されているものであり，前記「信頼できる装置」は，前記「コンピュータ・プラットフォーム」に含まれるものであって，結果として，前記「信頼性メトリック」は，「コンピュータ・プラットフォーム」の「メモリ」に保存されているものと言い得るものであるから，
　本願発明における「サーバのポリシーを表す値であって，前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ（ＰＣＲ）に保持されている前記値」と，
“サーバに含まれる記憶手段に保持されている値”である点で共通するので，
　引用発明における「コンピュータ・プラットフォームに含まれる，物理的に信頼できる装置が，チャレンジを受取り」と，
　本願発明における「前記サーバに含まれるプラットフォームキーアプリケーションロジックが，前記包含されているか検証するための引用リクエストを受信するステップであって，前記引用リクエストは，前記サーバのポリシーを表す値であって，前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ（ＰＣＲ）に保持される前記値に対するリクエストを含む，前記引用リクエストを受信するステップ」とは，
“サーバに含まれる手段が，所定の条件を満たすものであるかを検証するためリクエストを受信するステップであって，前記リクエストは，前記サーバに含まれる記憶手段に保持されている値に対するリクエストを含む，前記リクエストを受信するステップ”である点で共通する。
　
３．引用発明においても，「信頼できる装置」が，前記「信頼できる装置が有するメモリにアクセス」して，「測定された信頼性メトリック」を読み出しているので，
　引用発明における「信頼できる装置が有するメモリにアクセスして，測定された信頼性メトリックを読み出」すことと，
　本願発明における「前記プラットフォームキーアプリケーションロジックが，前記値を抽出するステップ」とは，
“サーバに含まれる手段が，サーバに含まれる記憶手段に保持されている値を抽出するステップ”である点で共通する。
　
４．引用発明においても「測定された信頼性メトリック」は，「信頼できる装置」の「秘密鍵」で署名され，前記「秘密鍵」は，「コンピュータ・プラットフォーム」に含まれる「信頼できる装置」の「メモリ」に保持されているものであるから，「コンピュータ・プラットフォーム」に保持されているものと言い得るものである。よって，
　引用発明における「測定された信頼性メトリックと，一時ワードのダイジェストを作成して，前記ダイジェストに，前記信頼できる装置の秘密鍵で署名」することと，
　本願発明における「サーバに含まれるプロセッサが，前記サーバに保持される暗号鍵ペアの秘密鍵を用いて前記値を署名するステップ」とは，
“サーバに含まれる装置が，前記サーバに保持される秘密鍵を用いて，前記サーバに含まれる記憶手段に保持されている値を署名するステップ”である点で共通する。
　
５．引用発明においても，“署名した値”を，「信頼できる装置」の外部に出力しており，上記「第３．引用刊行物に記載の発明」において引用した上記Ｇに記載された内容においては，「 the trusted device 24 signs the digest, using its private key, and returns the signed digest, accompanied by the certificate 350, to the user（信頼できる装置２４は，ダイジェストに署名し，認証書３５０と共に，署名されたダイジェストをユーザに送り返す）」とあって，該「ユーザ」が，「コンピュータ・プラットフォーム」の外部にいる場合には，「コンピュータ・プラットフォーム」の外に出力する態様を含むものであることは明らかである。よって，
　引用発明における「信頼できる装置のインタフェース回路を介して，前記信頼できる装置の外部に出力する」ことと，
　本願発明における「プラットフォームキーアプリケーションロジックが，前記サーバに含まれるネットワークコントローラを用いて，前記引用リクエストに応答して前記署名された値を出力するステップ」とは，
“サーバに含まれる手段が，要求に応答して，署名された値を出力するステップ”である点で共通する。
　
　よって，以上１．〜５．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　サーバが，所定の条件を満たすものであるかを検証する方法であって，
　前記サーバに含まれる手段が，所定の条件を満たすものであるかを検証するためリクエストを受信するステップであって，前記リクエストは，前記サーバに含まれる記憶手段に保持されている値に対するリクエストを含む，前記リクエストを受信するステップと，
　前記サーバに含まれる手段が，前記値を抽出するステップと，
　前記サーバに含まれる装置が，前記サーバに保持される秘密鍵を用いて，前記値を署名するステップと，
　サーバに含まれる手段が，要求に応答して，前記署名された値を出力するステップとを有する方法。
　
［相違点１］
“所定の条件”に関して，
　本願発明においては，「サーバがデータセンタコンピュータシステム内に包含されている」というものであるのに対して，
　引用発明においては，「複数のコンピュータ・プラットフォーム間の信頼性」というものである点。
　
［相違点２］
“サーバに含まれる手段”に関して，
　本願発明においては，「プラットフォームキーアプリケーションロジック」というソフトウェアであるのに対して，
　引用発明においては，「信頼できる装置」であって，ソフトウェアではない点。
　
［相違点３］
“サーバに含まれる記憶手段に保持されている値”に関して，
　本願発明においては，「サーバのポリシーを表す値であって，前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ（ＰＣＲ）に保持される前記値」であるのに対して，
　引用発明においては，「信頼できる装置が有するメモリ」に格納されている「信頼性メトリック」であって，“ＰＣＲに保持されているサーバのポリシーを表す値”ではない点。
　
［相違点４］
“サーバに含まれる装置”に関して，
　本願発明においては，「サーバに含まれるプロセッサ」が，「署名」を行っているのに対して，
　引用発明においては，「署名」を，「信頼できる装置」が行っている点。
　
［相違点５］
“前記署名された値を出力するステップ”に関して，
　本願発明においては，「プラットフォームキーアプリケーションロジックが，前記サーバに含まれるネットワークコントローラを用いて」いるのに対して，
　引用発明においては，「信頼できる装置」が，前記「信頼できる装置」を含む「コンピュータ・プラットフォーム」の有する“外部への通信制御機能”を用いているか不明である点。
　
第５．相違点についての当審の判断
１．［相違点１］について
　「サーバ」が「クライアント」に提供する“サービス”として，“データセンタ”は，本願の原出願の第１国出願前に,当業者には周知の技術事項であって（例えば，本願の原出願の第１国出願前に既に公知である，特開２００２-１０８８１８号公報（２００２年４月１２日公開，以下，これを「周知技術文献１」という）の【図１】等を参照されたい），
　例えば，“システムのユーザが，該システムに含まれるサーバが正当であるかを検証することに換えて，該サーバが，該システムに含まれるものであるかを検証する”こととすることは，“検証する値の意味付けを変更する”程度のものであるから，引用発明においても，「システム」を，“データセンタ”の“サービス”を提供する「データセンタコンピュータシステム」とし，「コンピュータ・プラットフォーム」の信頼性の検証に換えて，該「データセンタコンピュータシステム」に含まれているかを検証するものとすることは，当業者が適宜なし得る事項に過ぎない。
　よって，相違点１は，格別のものではない。
　
２．[相違点２]について
　引用発明においても，「信頼できる装置」は，上記Ｄに引用した記載中にあるように，「 a controller 30 programmed to control the overall operation of the trusted device 24, and interact with the other functions on the trusted device 24 and with the other devices on the motherboard 20（信頼できる装置２４の動作全体を制御し，信頼できる装置２４のその他の機能およびマザーボード２０のその他の装置と対話するようにプログラムされたコントローラ３０）」を有しており，該「プログラムされたコントローラ３０」は，上記Ｄの記載内容に，「 Each of the blocks in the trusted device 24 has access (typically via the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the trusted device 24（ブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ）」とあるように，“プログラムであるコントローラ３０を実行することで，メモリへのアクセス制御を行う”ものであるから，該「コントローラ」が，「リクエスト」を“受信する機能”を有する点の明言の記載はないものの，「リクエスト」の“受信処理”を行う機能を有するプログラム，即ち，「ソフトウェア」であるものと解され，また，仮に，他の機能が，該受信処理を行っているとしても，引用発明において，該「コントローラ」を，「リクエスト」の受信機能を有する「ソフトウェア」として構成することは，当業者が適宜なし得る事項である。
　よって，相違点２は，格別のものではない。
　
３．［相違点３］について
　“プラットフォームコンフィギュレーションレジスタ（ＰＣＲ）に保持される値”を用いる点については，例えば，本願の原出願の第１国出願前に既に公知である，「Trusted ComputingPlatform Alliance　Main SpecificationVersion 1.1b，２００２年　２月２２日，p.151」（以下，これを「周知技術文献２」という）に，
　
Ｈ．「7.2.1 TPM_Seal
Start of informative comment:
　
The SEAL operation allows software to explicitly state the future “trusted” configuration that the platform must be in for the secret to be revealed. 
The SEAL operation also implicitly includes the relevant platform configuration (PCR-values
　
If the UNSEAL operation succeeds, proof of the platform configuration that was in effect when the SEAL operation was performed is returned to the caller, as well as the secret data. This proof may, or may not, be of interest. If the SEALed secret is used to authenticate the platform to a third party, a caller is normally unconcerned about the state of the platform when the secret was SEALed, and the proof may be of no interest. On the other hand, if the SEALed secret is used to authenticate a third party to the platform, a caller is normally concerned about the state of the platform when the secret was SEALed. Then the proof is of interest.
　
For example, if SEAL is used to store a secret key for a future configuration (probably to prove that the platform is a particular platform that is in a particular configuration), the only requirement is that that key can be used only when the platform is in that future configuration. Then there is no interest in the platform configuration when the secret key was SEALed. An example of this case is when SEAL is used to store a network authentication key.
　
On the other hand, suppose an OS contains an encrypted database of users allowed to log on to the platform. The OS uses a SEALED blob to store the encryption key for the user-database. However, the nature of SEAL is that any SW stack can SEAL a blob for any other software stack. Hence the OS can be attacked by a second OS replacing both the SEALED-blob encryption key, and the user database itself, allowing untrusted parties access to the services of the OS. To thwart such attacks, SEALED blobs include the past SW configuration. Hence, if the OS is concerned about such attacks, it may check to see whether the past configuration is one that is known to be trusted.
　
TPM_Seal requires the encryption of one parameter (“Secret”). For the sake of uniformity with other commands that require the encryption of more than one parameter, the string used for XOR encryption is generated by concatenating a nonce (created during the OSAP session) with the session shared secret and then hashing the result.
　
End of informative comment.」（１５１頁１行〜３０行）
（7.2.1 TPM_Seal
参考情報の開始：
シール処理は，ソフトウェアに，公開される秘密のため，プラットフォームが採るに違いない，将来の“信頼された”構成を，明言することを許可する。
シール処理は，また
関連するプラットフォームの構成（ＰＣＲ値）を暗黙的に含む
　
もしシール解除処理が成功したのであれば，シール処理が実行されたときに実施された，プラットフォーム構成の証明は，秘密データを同様に，呼出し側に返される。この証明は，関心があるか，ないかである。もし，シールされた秘密が，第３者に対して，プラットフォームを認証するために用いられたのであれば，呼出し側は，通常，秘密がシールされたときに，プラットフォームの状態について，関係がなく，そして，証明には関心がない。他方，もし，シールされた秘密が，プラットフォームに対して，第３者を認証するために用いられたのであれば，呼出し側は，秘密がシールされたときに，プラットフォームの状態について関係がある。そのとき，証明には関心がある。
　
例えば，もしシールが，将来の構成のために秘密鍵を格納するために用いられるのであれば（おそらく，プラットフォームが，特別な構成における，特別なプラットフォームであることを証明するために），唯一の条件は，プラットフォームが，その将来の構成内にあるときのみに，その鍵が用いられることである。次に，秘密鍵がシールされた時に，プラットフォームの構成には興味がない。この場合の例は，シールが，ネットワーク認証鍵を格納するために用いられる時である。
　
他方，ＯＳが，プラットフォーム上で，ログを取ることを許可された，暗号化されたユーザのデータベースを含むと仮定する。そのＯＳは，ユーザ−データベースのために，暗号化された鍵を格納するために，シールされたブロブを用いる。しかしながら，シールの本質は，任意のソフトウェア・スタックが，その他のソフトウェア・スタックのためのブロブを，シールすることである。それ故，そのＯＳは，第２のＯＳから，シールされたブロブ暗号鍵と，ユーザ・データベース自身を置換する，そのＯＳのサービスに，信頼できない者のアクセスを許可する，攻撃を受ける。それ故，もし，そのＯＳが，このような攻撃について懸念があれば，過去の構成が信頼されることが知られているものであるかどうか見るためにチェックするかもしれない。
　
ＴＰＭ_シールは，パラメータの暗号化を要求する（“秘密”）。より多くのパラメータの暗号化を要求する他のコマンドとの均一性のために，排他的論理和暗号化のために用いられた文字列は，秘密を共有するセッションにおいて，（ＯＳＡＰセッションの間に生成された）ノンスを結合することによって，生成され，そして，次に結果がハッシュされる。
　
参考情報の終了。当審にて訳出。なお，下線は，当審にて，説明の都合上附加したものである。）
　
　という記載が存在するように，本願の原出願の第１国出願前に，当業者には，周知の技術事項である。
　本願発明においては，「サーバのポリシーを表す値」がどのようなものであるかの限定がなされていないが，この点に関して，本願明細書の発明の詳細な説明（以下，単に「本願明細書」という）を参酌すると，本願明細書には，
　
「【００４９】
　ブロック５０２において，フロー図５００は，データセンタの生成のためのポリシーから開始される。図３に示される実施例を参照することにより，管理者ユニット１０６の管理論理３０２は，プラットフォームがデータセンタ１４０内に含まれるべきかに関するポリシーを生成する。一実施例では，このポリシーは，プラットフォーム１０４のためのハードウェアメトリックを備えるものであってもよい。例えば，ポリシーは，ＴＣＰＡに基づくＴＰＭモジュールがプラットフォーム１０４内になければならいという要請を含むことができる。ポリシーのためのハードウェアメトリックの他の例としては，プロセッサのタイプや，プラットフォーム１０４が安全と考えられるアプリケーションにメモリへのアクセスを限定するように，様々なタイプの私有あるいは安全なメモリを備えるかどうかなどがあげられる。他の例としては，プラットフォーム１０４内のメモリの一部や他のユニットがそれへのアクセスに関して制限するようバーチャルマシーン監視の必要性があげられる。ポリシーのハードウェアメトリックの他の例としては，プラットフォーム１０４内に暗号化アクセラレータカード，ネットワークカードなどが含まれるというものであってもよい。
　【００５０】
　一実施例では，このポリシーは，プラットフォーム１０４のためのソフトウェアメトリックを有する。例えば，ポリシーは，プラットフォームが所与のタイプのオペレーティングシステムあるいはその上で実行される他のタイプのより高いレベルのアプリケーションを実行していることの要求を含むものであってもよい。ポリシーに要求されるより高いレベルのアプリケーションの例としては，あるタイプのデータベース，当該データベースのためのインタフェースアプリケーション及びあるタイプの暗号化処理を実行する暗号化アプリケーションがあげられる。
　【００５１】
　管理論理３０２は，データセンタの管理者からの入力に基づきこのポリシーを生成するようにしてもよい。そのような実施例では，このポリシーは，データセンタのユーザが要求する必要条件や基準に基づくものであるかもしれない。例えば，第１のプラットフォーム群は秘匿性のある情報を通信することなくプラットフォームからのデータの抽出を可能にするが，第２のプラットフォーム群は秘匿性のある情報／財務情報のアップロードを含む書籍，おもちゃなどの電子商取引を可能にし，第３のプラットフォーム群は安全性を求められる政府文書，個人の医療記録などを含む高い秘匿性を有する情報のアップロードを可能にする。従って，これら様々なタイプのプラットフォーム群のポリシーの必要条件は，プラットフォームとの通信のタイプに基づき変化する。」
　
　という記載が存在し，上記引用の記載中に，本願における「ポリシー」が例示されているが，本願発明の構成から，本願発明の「ポリシー」を，上記引用記載中の例示の何れかに限定解釈しなければならない根拠は存在しない。
　そして，該例示中に，「一実施例では，このポリシーは，プラットフォーム１０４のためのハードウェアメトリックを備えるものであってもよい」，或いは，「一実施例では，このポリシーは，プラットフォーム１０４のためのソフトウェアメトリックを有する」とあり，本願発明における「ポリシー」が，上記指摘の例示のものであるとすれば，引用発明における「信頼性メトリック」と格別相違しない。
　また，仮に，上記引用記載中に例示された，他の「ポリシー」であったとしても，何れの「ポリシー」も，「システム」の利用者が，必要に応じて適宜設定し得る程度のものであって，引用発明において，そのような「ポリシー」を採用することは，当業者が適宜なし得る事項である。
　よって，相違点３は，格別のものではい。
　
４．［相違点４］について
　上記Ｃに「 For example, it is feasible to integrate one or more of the functions of the trusted device into the main processor itself, provided that the functions and their communications cannot be subverted（例えば，諸機能およびそれら対話が破壊されることができないと仮定すれば，主プロセッサに信頼できる装置の１つまたは複数の機能を主プロセッサに統合することは可能である）」と記載されていて，引用発明において，「信頼できる装置の１つまたは複数の機能」を，「信頼できる装置」ではない，「主プロセッサ」に割り当てることが可能であるから，引用発明において，「署名」する機能を，「プロセッサ」に割り当てることは，当業者が適宜なし得る事項である。
　よって，相違点４は，格別のものではい。
　
５．［相違点５］について
　上記Ｄの記載内容にもあるとおり，引用発明においては，「信頼できる装置」は，前記「信頼できる装置」を有する「コンピュータ・プラットフォーム」の「マザーボード」と接続されており，前記「コンピュータ・プラットフォーム」は，外部との通信を行い得るものであるから，前記「信頼できる装置」から，「コンピュータ・プラットフォーム」の外部に対して，“データ”等を送信する場合に，「コンピュータ・プラットフォーム」の“通信のためのコントローラ”を使用するよう構成することは，当業者が適宜なし得る事項である。
　よって，相違点５は，格別のものではない。
　
　上記で検討したごとく，相違点１〜相違点５はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，引用発明，及び，当該技術分野における周知技術から，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
第６．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。