【事件の表示】
　特願２０１０−２４３２２７「データセンタへのプラットフォームの内包検証」拒絶査定不服審判事件〔平成２３年　４月　７日出願公開，特開２０１１−　７２００６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００３年３月２８日（パリ条約による優先権主張外国庁受理２００２年４月１５日　アメリカ合衆国）を国際出願日とする特願２００３−５８６７３０号の一部を，平成２１年６月３０日に新たな出願とした特願２００９−１５４９９１号の一部を，平成２２年１０月２９日に新たな出願としたものであって，
　平成２２年１０月２９日付けで審査請求がなされ，平成２５年１月２１日付けで審査官により拒絶理由が通知され，これに対して平成２５年４月３０日付けで意見書が提出されると共に手続補正がなされたが，平成２５年９月２４日付けで審査官により拒絶査定がなされ（発送；平成２５年１０月１日），これに対して平成２６年２月３日付けで審判請求がなされると共に手続補正がなされ，平成２６年４月２日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２６年２月３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。
　
「【請求項１】
　複数のサーバの少なくとも１つを含むデータセンタコンピュータシステムに含まれるサーバであって，
　前記複数のサーバは，当該サーバと他のサーバとを含み，
当該サーバは，
　当該サーバがデータセンタコンピュータシステム内に包含されているかを検証するのに使用される秘密鍵と，
　前記秘密鍵を当該サーバにシール処理する少なくとも１つのトークンと，
を有し，
　前記少なくとも１つのトークンは，プロテクトされたストレージを有し，
　前記秘密鍵を当該サーバにシール処理することは，ｓｅａｌコマンドを利用することによって前記秘密鍵を当該サーバに関連付けることを含むことを特徴とするサーバ。」
　
第３．引用刊行物に記載の発明
　一方，原審が，平成２５年１月２１日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用した，本願の原出願の第１国出願前に既に公知である，国際公開第００／５４１２６号（２０００年９月１４日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「 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”の頭文字をとって“ＴＰ”と略称される場合がある。) 一致すれば，信頼性メトリックの範囲に応じて，少なくともプラットフォームの一部が正しく動作していることを意味する。）
　
Ｃ．「　Techniques relevant to tamper-resistance are well known to those skilled in the art of security. These techniques include methods for resisting tampering (such as appropriate encapsulation of the trusted device), methods for detecting tampering (such as detection of out of specification voltages, X-rays, or loss of physical integrity in the trusted device casing), and methods for eliminating data when tampering is detected. Further discussion of appropriate techniques can be found at http://www.cl.cam.ac.uk/~mgk25/tamper.html. It will be appreciated that, although tamper-proofing is a most desirable feature of the present invention, it does not enter into the normal operation of the invention and, as such, is beyond the scope of the present invention and will not be described in any detail herein. 」（１３頁２０行〜２９行）
（    【００４３】
　不正操作抵抗力に関連した技法は，セキュリティの分野の専門家には周知のものである。そのような技法は，(信頼できる装置の適切なカプセル化のような)不正操作抵抗方法，(仕様電圧，Ｘ線逸脱の検出，または信頼できる装置枠における物理的信頼性の喪失の検出のような)不正操作検出方法，および不正操作検出の時データを削除する方法などを含む。更に，いくつかの適切な技法が，http://www.cl.cam.ac.uk/~mgk25/tamper.hlmlに紹介されている。理解されることであろうが，不正操作抵抗方法は本発明の最も望ましい機能であるとはいえ，それは，本発明の通常の動作に含まれず，従って，本発明の適用範囲外にあり，ここで詳細な記述は行わない。）
　
Ｄ．「　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.」（１６頁１８行〜２９行）
（   【００５４】
　信頼できる装置は，具体的には，信頼できる装置２４の動作全体を制御し，信頼できる装置２４のその他の機能およびマザーボード２０のその他の装置と対話するようにプログラムされたコントローラ３０，プラットフォーム１０から信頼性メトリックを取得する測定機能３１，指定されたデータを署名，暗号化または解読する暗号機能３２，スマートカードを認証する認証機能３３，および，適切なポート(３６，３７，３８)を有し，マザーボード２０のデータ・バス２６，制御線２７，およびアドレス線２８のそれぞれに信頼できる装置２４を接続するインタフェース回路３４を備える。信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ。更に，信頼できる装置２４は，周知の形態で，不正抵抗性を持つように設計される。）
　
Ｆ．「 　One item of data stored in the non-volatile memory 3 of the trusted device 24 is a certificate 350. The certificate 350 contains at least a public key 351 of the trusted device 24 and an authenticated value 352 of the platform integrity metric measured by a trusted party (TP). The certificate 350 is signed by the TP using the TP's private key prior to it being stored in the trusted device 24. In later communications sessions, a user of the platform 10 can verify the integrity of the platform 10 by comparing the acquired integrity metric with the authentic integrity metric 352. If there is a match, the user can be confident that the platform 10 has not been subverted. Knowledge of the TP's generally-available public key enables simple verification of the certificate 350. The non-volatile memory 35 also contains an identity (ID) label 353. The ID label 353 is a conventional ID label, for example a serial number, that is unique within some context. The ID label 353 is generally used for indexing and labelling of data relevant to the trusted device 24, but is insufficient in itself to prove the identity of the platform 10 under trusted conditions.
 ・・・・・（中略）・・・・・
　　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.」（２０頁１２行〜１８行）
（   【００６８】
　先ず，信頼できるプラットフォームを保証するＴＰ(信頼できる機関)が，保証すべきか否かを決定するためそのプラットフォームのタイプを調べる。これは，ポリシの問題である。すべてがよければ，ステップ５００において，ＴＰがプラットフォームの信頼性メトリックの値を測定する。次に，ＴＰは，ステップ５０５において，プラットフォームに関する認証書を生成する。認証書の生成は，信頼できる装置の公開暗号鍵およびオプションとしてそのＩＤラベルを測定された信頼性メトリックに追加し，ＴＰの秘密鍵でストリングスを署名することによって行われる。）
　
Ｈ．「　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 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（これら識別情報および信頼性メトリックが，プラットフォームの信頼性を保証するように準備されている信頼できる機関によって提供される期待値と比較される）」という記載から，引用刊行物１には，「コンピュータ・プラットフォーム」と，前記「コンピュータ・プラットフォーム」に組み込まれることで，前記「コンピュータ・プラットフォーム」を，「信頼できるコンピュータ・プラットフォーム」にする「物理的な信頼できる装置」と，「プラットフォームの信頼性を保証するように準備されている信頼できる機関」とが存在していることが読み取れ，
　そして，前半において上記Ａの記載内容について指摘した事項と併せると，引用刊行物１から，
“サーバになり得る複数のコンピュータ・プラットフォーム，及び，前記プラットフォームの信頼性を保証するように準備されている信頼できる機関から構成されるシステム”を読み取ることができる。
　以上の検討から，「コンピュータ・プラットフォーム」は，前記“システム”に含まれるものであり，“複数のコンピュータ・プラットフォーム”には，
“１のコンピュータ・プラットフォームと，他のコンピュータ・プラットフォームを含”むものであることは明らかである。
　
２．上記Ｅの「 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（信頼できる装置２４におけるブロックの各々は，信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ）」という記載，及び，上記Ｆの「One item of data stored in the non-volatile memory 3 of the trusted device 24 is a certificate 350. The certificate 350 contains at least a public key 351 of the trusted device 24 and an authenticated value 352 of the platform integrity metric measured by a trusted party (TP). The certificate 350 is signed by the TP using the TP's private key prior to it being stored in 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（測定機能３１は，ハッシュ・プログラム３５４および信頼できる装置２４の秘密鍵３５５を保存する不揮発性メモリ３および取得した信頼性メトリックをダイジェスト３６１の形態で保存する揮発性メモリ４にアクセスする）」という記載から，引用刊行物１においては，
“信頼できる装置が有するメモリに，信頼できる装置の秘密鍵と，ＴＰの秘密鍵を用いて署名された認証書が保存されている”ことが読み取れ，
　上記Ｇの「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（ＴＰは，ステップ５０５において，プラットフォームに関する認証書を生成する。認証書の生成は，信頼できる装置の公開暗号鍵およびオプションとしてそのＩＤラベルを測定された信頼性メトリックに追加し，ＴＰの秘密鍵でストリングスを署名することによって行われる）」という記載，及び，上記Ｈの「 the trusted device 24 signs the digest, using its private key, and returns the signed digest, accompanied by the certificate 350, to the user（その秘密鍵を使用して，信頼できる装置２４は，ダイジェストに署名し，認証書３５０と共に，署名されたダイジェストをユーザに送り返す）」という記載と，同じく上記Ｈの「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（ユーザはチャレンジの応答を受け取り，ＴＰの既知の公開暗号鍵を使用して認証書を検証する。次に，ユーザは，ステップ５５０において，認証書から信頼できる装置２４の公開暗号鍵を抽出して，それを使用してチャレンジ応答から署名されたダイジェストを解読する）」，同じく上記Ｈの「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（ユーザは，チャレンジ応答の中の一時的ワードを検証する。次に，ステップ５７０において，ユーザは，(チャレンジ応答から取り出した)計算された信頼性メトリックを(認証書から抽出した)該当するプラットフォーム信頼性メトリックと比較する）」という記載から，引用刊行物１においては，
“ユーザが，信頼できる機関の秘密鍵で署名した認証書を，信頼できる機関の公開鍵で検証し，信頼できる装置の公開鍵を取得し，前記信頼できる装置の公開鍵を用いて，信頼できる装置の秘密鍵によって署名されたダイジェストを検証することで，プラットフォームの信頼性を検証する”ことが読み取れ，
　このことから，「信頼できる装置の秘密鍵」は，「ダイジェストの検証」，即ち，「プラットフォームの信頼性を検証」するために用いられるものであることは明らかである。
　そして，「信頼できる装置」は,上記１．において検討したとおり，「コンピュータ・プラットフォーム」に組み込まれるものであるから，当該２．において検討した事項から，前記「秘密鍵」は，「コンピュータ・プラットフォーム」が有するものであることも，明らかである。
　
３．上記１．において指摘した，“信頼できるプラットフォーム”は，物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される”という点，及び，上記Ｄの「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（代替的に，必要に応じてプラットフォームに接続することができるドングルのような取り外し可能な装置として実施することも可能である。信頼できる装置が統合された装置か取り外し可能な装置かは設計選択の問題である）」という記載，並びに，上記２．において検討した事項から，引用刊行物１には，
“コンピュータ・プラットフォームから取り外し可能な，自身の秘密鍵と，信頼できる機関の秘密鍵を用いて署名された認証書とを保存する，信頼できる装置”が読み取れる。
　
４．上記２．において検討した事項から，引用刊行物１に記載の「信頼できる装置」は，「メモリ」を有しており，上記Ｅの「Additionally, the trusted device 24 is designed, in a known manner, to be tamper resistant（更に，信頼できる装置２４は，周知の形態で，不正抵抗性を持つように設計される）」という記載，及び，上記Ｃに引用した記載内容から，
　引用刊行物１に記載の「信頼できる装置」は，「不正抵抗性」，即ち，“耐タンパ性”を有しており，このことから，前記「信頼できる装置」が有するメモリも，“耐タンパ性”を有することは明らかである。
　
　以上，上記１．〜４．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　サーバになり得る複数のコンピュータ・プラットフォーム，及び，前記プラットフォームの信頼性を保証するように準備されている信頼できる機関から構成されるシステムに含まれるコンピュータ・プラットフォームであって，
　前記複数のコンピュータ・プラットフォームは，１のコンピュータ・プラットフォームと他のコンピュータ・プラットフォームとを含み，
１のコンピュータ・プラットフォームは，
　１のコンピュータ・プラットフォームの信頼性を検証するために用いられる秘密鍵と，
　コンピュータ・プラットフォームから取り外し可能な，自身の秘密鍵と，信頼できる機関の秘密鍵を用いて署名された認証書とを保存する，信頼できる装置と，
を有し，
　前記信頼できる装置は，耐タンパ性を有するメモリを有する，コンピュータ・プラットフォーム。
　
第４．本願発明と引用発明との対比
１．引用発明における「コンピュータ・プラットフォーム」は，「サーバになり得る」ものであるから，本願発明における「サーバ」に相当し，引用発明における「システム」も，本願発明における「データセンタコンピュータシステム」も，“コンピュータシステム”である点で共通するので，
　引用発明における「サーバになり得る複数のコンピュータ・プラットフォーム，及び，前記プラットフォームの信頼性を保証するように準備されている信頼できる機関から構成されるシステムに含まれるコンピュータ・プラットフォームであって，
　前記複数のコンピュータ・プラットフォームは」と，
　本願発明における「複数のサーバの少なくとも１つを含むデータセンタコンピュータシステムに含まれるサーバであって，
　前記複数のサーバは，当該サーバと他のサーバとを含み，
当該サーバは」とは，
“複数のサーバの少なくとも１つを含むコンピュータシステムに含まれるサーバであって，
　前記複数のサーバは，当該サーバと他のサーバとを含み，
当該サーバは”である点で共通する。
　
２．引用発明における「秘密鍵」は，「コンピュータ・プラットフォームの正当性を検証するために用いられる」ものであるから，
　本願発明における「サーバがデータセンタコンピュータシステム内に包含されているかを検証するのに使用される秘密鍵」とは，
“サーバが所定の条件を満たすものであるかを検証するのに使用される秘密鍵”である点で共通する。
　
３．引用発明における「信頼できる装置」は，「コンピュータ・プラットフォーム」に組み込まれ，且つ，前記「コンピュータ・プラットフォーム」から取り外し可能に構成し得るものであって，前記「コンピュータ・プラットフォーム」の信頼性を検証するために用いられるものであるから，一種の“ハードウェア・トークン”と言い得るものである。
　よって，引用発明における「コンピュータ・プラットフォームから取り外し可能な，自身の秘密鍵と，信頼できる機関の秘密鍵を用いて署名された認証書とを保存する，信頼できる装置」と，
　本願発明における「前記秘密鍵を当該サーバにシール処理する少なくとも１つのトークン」とは，
“少なくとも１つのトークン”である点で共通する。
　
４．引用発明における「信頼できる装置」は，「耐タンパ性」を有する「メモリ」を有しており，「メモリ」に対して，「耐タンパ性」を持たせるということは，「メモリ」を，“第３者からアクセス不能とする”，即ち，「プロテクト」することも含み得るものであり，引用発明における「メモリ」も，本願発明における「ストレージ」も「記憶手段」である点で共通するので，
　引用発明における「コンピュータ・プラットフォームから取り外し可能な，自身の秘密鍵と，信頼できる機関の秘密鍵を用いて署名された認証書とを保存する，信頼できる装置」と，
　本願発明における「少なくとも１つのトークンは，プロテクトされたストレージを有」することとは，
“少なくとも１つのトークンは，プロテクトされた記憶手段を有”する点で共通する。
　
　以上，上記１．〜４．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　複数のサーバの少なくとも１つを含むコンピュータシステムに含まれるサーバであって，
　前記複数のサーバは，当該サーバと他のサーバとを含み，
当該サーバは，
　当該サーバが所定の条件を満たすものであるかを検証するのに使用される秘密鍵と，
　少なくとも１つのトークンと，を有し，
　前記少なくとも１つのトークンは，プロテクトされた記憶手段を有する，サーバ。
　
［相違点１］
“コンピュータシステム”に関して，
　本願発明においては，「データセンタコンピュータシステム」であるのに対して，
　引用発明においては，「データセンタ」については言及されていない点。
　
［相違点２］
“所定の条件を満たすもの”に関して，
　本願発明においては，「サーバがデータセンタコンピュータシステム内に包含されているか」という条件であるのに対して，
　引用発明においては，「コンピュータ・プラットフォームの信頼性」であって，該「コンピュータ・プラットフォーム」が，「データセンタコンピュータシステム」に含まれるか否かに関しては，言及されていない点。
　
［相違点３］
“少なくとも１つのトークン”に関して，
　本願発明においては，「少なくとも１つのトークン」は，“秘密鍵をサーバにシール処理する”ものであるのに対して，
　引用発明においては，「シール処理」について言及されていない点。
　
［相違点４］
“記憶手段”に関して，
　本願発明においては，「ストレージ」であるのに対して，引用発明においては「メモリ」である点。
　
［相違点５］
　本願発明においては，「秘密鍵を当該サーバにシール処理することは，ｓｅａｌコマンドを利用することによって前記秘密鍵を当該サーバに関連付けることを含む」ものであるのに対して，
　引用発明においては，「シール処理」に関する言及がない点。
　
第５．相違点についての当審の判断
１．［相違点１］，及び，［相違点２］について
　引用発明における「コンピュータ・プラットフォーム」は，「サーバ」を含み得るものであり，引用発明は，複数の「コンピュータ・プラットフォーム」から構成されるシステムを形成していることは明らかである。
　そして，「サーバ」が「クライアント」に提供する“サービス”として，“データセンタ”は，本願の原出願の第１国出願前に,当業者には周知の技術事項であって（例えば，本願の原出願の第１国出願前に既に公知である，特開２００２-１０８８１８号公報（２００２年４月１２日公開，以下，これを「周知技術文献」という）の【図１】等を参照されたい），
　例えば，“システムのユーザが，該システムに含まれるサーバが正当であるかを検証することに換えて，該サーバが，該システムに含まれるものであるかを検証する”こととすることは，“検証する値の意味付けを変更する”程度のものであるから，引用発明においても，「システム」を，“データセンタ”の“サービス”を提供する「データセンタコンピュータシステム」とし，「コンピュータ・プラットフォーム」の信頼性の検証に換えて，該「データセンタコンピュータシステム」に含まれているかを検証するものとすることは，当業者が適宜なし得る事項に過ぎない。
　よって，相違点１，及び，相違点２は，格別のものではない。
　
２．［相違点３］，及び，［相違点５］について
　「シール処理」については，原審拒絶理由に引用された，本願の原出願の第１国出願前に既に公知である，「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) when the SEAL operation was performed. The SEAL operation uses the tpmProof value to BIND the blob to an individual TPM.
　
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
参考情報の開始：
シール処理は，ソフトウェアに，公開される秘密のため，プラットフォームが採るに違いない，将来の“信頼された”構成を，明言することを許可する。シール処理は，また，シール処理が実行されるとき，関連するプラットフォームの構成（ＰＣＲ値）を暗黙的に含む。シール処理は，個別のＴＰＭに，ブロブをバインドするために，ｔｍｐ証明値を使用する。
　
もしシール解除処理が成功したのであれば，シール処理が実行されたときに実施された，プラットフォーム構成の証明は，秘密データを同様に，呼出し側に返される。この証明は，関心があるか，ないかである。もし，シールされた秘密が，第３者に対して，プラットフォームを認証するために用いられたのであれば，呼出し側は，通常，秘密がシールされたときに，プラットフォームの状態について，関係がなく，そして，証明には関心がない。他方，もし，シールされた秘密が，プラットフォームに対して，第３者を認証するために用いられたのであれば，呼出し側は，秘密がシールされたときに，プラットフォームの状態について関係がある。そのとき，証明には関心がある。
　
例えば，もしシールが，将来の構成のために秘密鍵を格納するために用いられるのであれば（おそらく，プラットフォームが，特別な構成における，特別なプラットフォームであることを証明するために），唯一の条件は，プラットフォームが，その将来の構成内にあるときのみに，その鍵が用いられることである。次に，秘密鍵がシールされた時に，プラットフォームの構成には興味がない。この場合の例は，シールが，ネットワーク認証鍵を格納するために用いられる時である。
　
他方，ＯＳが，プラットフォーム上で，ログを取ることを許可された，暗号化されたユーザのデータベースを含むと仮定する。そのＯＳは，ユーザ−データベースのために，暗号化された鍵を格納するために，シールされたブロブを用いる。しかしながら，シールの本質は，任意のソフトウェア・スタックが，その他のソフトウェア・スタックのためのブロブを，シールすることである。それ故，そのＯＳは，第２のＯＳから，シールされたブロブ暗号鍵と，ユーザ・データベース自身を置換する，そのＯＳのサービスに，信頼できない者のアクセスを許可する，攻撃を受ける。それ故，もし，そのＯＳが，このような攻撃について懸念があれば，過去の構成が信頼されることが知られているものであるかどうか見るためにチェックするかもしれない。
　
ＴＰＭ_シールは，パラメータの暗号化を要求する（“秘密”）。より多くのパラメータの暗号化を要求する他のコマンドとの均一性のために，排他的論理和暗号化のために用いられた文字列は，秘密を共有するセッションにおいて，（ＯＳＡＰセッションの間に生成された）ノンスを結合することによって，生成され，そして，次に結果がハッシュされる。
　
参考情報の終了。当審にて訳出）
　
　と記載されてもいるように，本願の原出願の第１国出願前に，当業者には，既に知られた技術であり，引用発明においも，「信頼できる装置」における処理として，該「シール処理」を採用することは，求められる安全性等に応じて，当業者が適宜採用し得るものである。
　よって，相違点３，及び，相違点５は，格別のものではない。
　
３．［相違点４］について
　上記「第４．本願発明と引用発明との対比」の４．においても指摘したとおり，引用発明における「メモリ」も，本願発明における「ストレージ」も，記憶手段である点では共通しており，引用発明において，「信頼できる装置」の装置規模等を考慮して，「メモリ」に換えて，「ストレージ」を採用することは，当業者が適宜なし得る事項である。
　よって，相違点４は，格別のものではない。
　
　上記で検討したごとく，相違点１〜相違点５はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，引用発明，及び，引用刊行物２に記載された発明，並びに，当業者に周知な技術から当業者であれば容易に予測可能なものに過ぎず格別なものとは認められない。
　
第６．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。