• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1299299
審判番号 不服2014-1946  
総通号数 185 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-05-29 
種別 拒絶査定不服の審決 
審判請求日 2014-02-03 
確定日 2015-04-01 
事件の表示 特願2010-243228「データセンタへのプラットフォームの内包検証」拒絶査定不服審判事件〔平成23年 3月31日出願公開,特開2011- 65665〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2003年3月28日(パリ条約による優先権主張外国庁受理2002年4月15日 アメリカ合衆国)を国際出願日とする特願2003-586730号の一部を,平成21年6月30日に新たな出願とした特願2009-154991号の一部を,平成22年10月29日に新たな出願としたものであって,
平成22年10月29日付けで審査請求がなされ,平成25年1月21日付けで審査官により拒絶理由が通知され,これに対して平成25年7月26日付けで意見書が提出されると共に手続補正がなされたが,平成25年9月24日付けで審査官により拒絶査定がなされ(発送;平成25年10月1日),これに対して平成26年2月3日付けで審判請求がなされると共に手続補正がなされ,平成26年4月2日付けで審査官により特許法第164条第3項の規定に基づく報告がなされたものである。

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

「【請求項1】
サーバがデータセンタコンピュータシステム内に包含されているか検証する方法であって,
前記サーバに含まれるプラットフォームキーアプリケーションロジックが,前記包含されているか検証するための引用リクエストを受信するステップであって,前記引用リクエストは,前記サーバのポリシーを表す値であって,前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ(PCR)に保持される前記値に対するリクエストを含む,前記引用リクエストを受信するステップと,
前記プラットフォームキーアプリケーションロジックが,前記値を抽出するステップと,
前記サーバに含まれるプロセッサが,前記サーバに保持される暗号鍵ペアの秘密鍵を用いて前記値を署名するステップと,
前記プラットフォームキーアプリケーションロジックが,前記サーバに含まれるネットワークコントローラを用いて,前記引用リクエストに応答して前記署名された値を出力するステップとを有することを特徴とする方法。」

第3.引用刊行物に記載の発明
一方,原審が,平成25年1月21日付けの拒絶理由(以下,これを「原審拒絶理由」という)において引用した,本願の原出願の第1国出願前に既に公知である,国際公開第00/54126号(2000年9月14日公開,以下,これを「引用刊行物1」という)には,関連する図面と共に,次の事項が記載されている。

A.「 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^(TM) operating system is common, as well as the Unix^(TM) 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.」(1頁20行?29行)
( 【0003】
一方,多くのアプリケーションにおけるビジネス使用に関しては,サーバ・プラットフォームが,集中的データ記憶装置および複数のクライアント・ステーションのためのアプリケーション機能性を提供する。ビジネス用途に関する重要な基準は,信頼性,ネットワーキング機能およびセキュリティ機能である。そのようなプラットフォームとして,Unixオペレーティング・システムと共に,マイクロソフト・ウインドウズNT4.0が広く使用されている。
【0004】
“電子商取引”として知られているインターネット上で取り引きされる商業活動の増加に伴って,家庭用および商取引用タイプ両方のインターネット上でコンピュータ・プラットフォーム間のデータ・トランザクション(取引)を可能にすることに大きな関心が寄せられている。そのようなシステムを受け入れる場合の基本的問題は,そのようなトランザクションを処理するため相互に対話するコンピュータ・プラットフォーム間の信頼性の問題である。<引用刊行物1のファミリである,特表2002-539656号公報の当該箇所より引用。以下,同じ。>)

B.「 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.」(12頁24行?31行)
( 【0039】
本発明の実施形態において使用される“信頼できるプラットフォーム”をここで説明する。これは,物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される。この物理的な信頼できる装置は,プラットフォームの信頼性メトリックを提供する測定されたデータにプラットフォームの識別を結合する機能を有する。これら識別情報および信頼性メトリックが,プラットフォームの信頼性を保証するように準備されている信頼できる機関によって提供される期待値と比較される。(注:以下の記述において,“信頼できる機関”は,その英語表記である“trusted party”の頭文字をとって“TP”と略称される場合がある。) 一致すれば,信頼性メトリックの範囲に応じて,少なくともプラットフォームの一部が正しく動作していることを意味する。)

C.「 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.」(15頁29行?16頁7行)
( 【0052】
以下に記述される好ましい実施形態において,信頼できる装置24が単一の,離散的なコンポーネントであるとはいえ,代替的形態として信頼できる装置24の機能をマザーボード上の複数の装置に分割することも,あるいは,プラットフォームの従来型標準装置の1つまたは複数に組み込むことさえ可能である。例えば,諸機能およびそれら対話が破壊されることができないと仮定すれば,主プロセッサに信頼できる装置の1つまたは複数の機能を主プロセッサに統合することは可能である。しかしながら,この構成は,プロセッサが信頼できる機能によってのみ使用されることを必要とすることになるであろう。更に,本実施形態において,信頼できる装置はマザーボード20への統合に適応されるハードウェア装置であるが,代替的に,必要に応じてプラットフォームに接続することができるドングルのような"取り外し可能な"装置として実施することも可能である。信頼できる装置が統合された装置か取り外し可能な装置かは設計選択の問題である。しかしながら,信頼できる装置が分離できるものである場合,信頼できる装置とプラットフォームの間の論理的結合を提供するメカニズムが存在しなければならない。)

D.「 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.」(16頁18行?29行)
( 【0054】
信頼できる装置は,具体的には,信頼できる装置24の動作全体を制御し,信頼できる装置24のその他の機能およびマザーボード20のその他の装置と対話するようにプログラムされたコントローラ30,プラットフォーム10から信頼性メトリックを取得する測定機能31,指定されたデータを署名,暗号化または解読する暗号機能32,スマートカードを認証する認証機能33,および,適切なポート(36,37,38)を有し,マザーボード20のデータ・バス26,制御線27,およびアドレス線28のそれぞれに信頼できる装置24を接続するインタフェース回路34を備える。信頼できる装置24におけるブロックの各々は,信頼できる装置24の適切な揮発性メモリ領域4および不揮発性メモリ領域3に対する(典型的にはコントローラ30経由の)アクセスを持つ。更に,信頼できる装置24は,周知の形態で,不正抵抗性を持つように設計される。)

E.「 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.」(17頁22行?27行)
( 【0058】
測定機能31は,ハッシュ・プログラム354および信頼できる装置24の秘密鍵355を保存する不揮発性メモリ3および取得した信頼性メトリックをダイジェスト361の形態で保存する揮発性メモリ4にアクセスする。また,適切な実施形態において,揮発性メモリ4は,プラットフォーム10へのアクセスを取得するために使用されることができる1つまたは複数の真正スマートカードの公開暗号鍵および関連IDラベル360a-360nを記憶するためにも使用される。)

F.「 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.」(20頁12行?18行)
( 【0068】
先ず,信頼できるプラットフォームを保証するTP(信頼できる機関)が,保証すべきか否かを決定するためそのプラットフォームのタイプを調べる。これは,ポリシの問題である。すべてがよければ,ステップ500において,TPがプラットフォームの信頼性メトリックの値を測定する。次に,TPは,ステップ505において,プラットフォームに関する認証書を生成する。認証書の生成は,信頼できる装置の公開暗号鍵およびオプションとしてそのIDラベルを測定された信頼性メトリックに追加し,TPの秘密鍵でストリングスを署名することによって行われる。)

G.「 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.」(21頁6行?28行)
( 【0072】
ユーザは,プラットフォームとの通信を望む時,ステップ520において,乱数のような一時的ワードを作成し,ステップ525において,信頼できる装置24にチャレンジ(呼びかけ)を行う(プラットフォームのオペレーティング・システムまたは適切なソフトウェア・アプリケーションは,チャレンジを認識して適切な形態で典型的にはBIOS呼び出しを介して信頼できる装置24へそれを渡すように構成されている)。一時的ワードは,信頼できないプラットフォームによる古いが真正な署名に起因する欺瞞("返信攻撃"と呼ばれる)からユーザを保護するために使用される。一時的ワードを提供して応答を検証するプロセスは,周知の“チャレンジ/応答”プロセスの1例である。
【0073】
ステップ530において,信頼できる装置24は,チャレンジを受け取り,該当する応答を作成する。応答は,測定された信頼性メトリックと一時的ワードのダイジェスト,および,オプションとして,そのIDラベルである。次に,ステップ535において,その秘密鍵を使用して,信頼できる装置24は,ダイジェストに署名し,認証書350と共に,署名されたダイジェストをユーザに送り返す。
【0074】
ステップ540において,ユーザはチャレンジの応答を受け取り,TPの既知の公開暗号鍵を使用して認証書を検証する。次に,ユーザは,ステップ550において,認証書から信頼できる装置24の公開暗号鍵を抽出して,それを使用してチャレンジ応答から署名されたダイジェストを解読する。次に,ステップ560において,ユーザは,チャレンジ応答の中の一時的ワードを検証する。次に,ステップ570において,ユーザは,(チャレンジ応答から取り出した)計算された信頼性メトリックを(認証書から抽出した)該当するプラットフォーム信頼性メトリックと比較する。ステップ545,555,565または575における前記検証のいずれかが失敗すれば,全ステップはステップ580で終了しそれ以上の通信は行われない。)

1.上記Aの「 for business use in many applications, a server platform provides centralized data storage, and application functionality for a plurality of client stations(多くのアプリケーションにおけるビジネス使用に関しては,サーバ・プラットフォームが,集中的データ記憶装置および複数のクライアント・ステーションのためのアプリケーション機能性を提供する)」という記載,同じく上記Aの「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(“電子商取引”として知られているインターネット上で取り引きされる商業活動の増加に伴って,家庭用および商取引用タイプ両方のインターネット上でコンピュータ・プラットフォーム間のデータ・トランザクション(取引)を可能にすることに大きな関心が寄せられている。そのようなシステムを受け入れる場合の基本的問題は,そのようなトランザクションを処理するため相互に対話するコンピュータ・プラットフォーム間の信頼性の問題である)」という記載から,引用刊行物1は,“サーバ,クライアントである,複数のコンピュータ・プラットフォームから構成されるシステムにおける,複数のコンピュータ・プラットフォーム間の信頼性に関するものである”ことが読み取れる。

2.上記Bの「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(本発明の実施形態において使用される“信頼できるプラットフォーム”をここで説明する。これは,物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される)」という記載から,引用刊行物1においては,
“コンピュータ・プラットフォームに,物理的に信頼できる装置が含まれる”ことが読み取れる。

3.上記Dの「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(信頼できる装置は,信頼できる装置24の動作全体を制御し,信頼できる装置24のその他の機能およびマザーボード20のその他の装置と対話するようにプログラムされたコントローラ30,プラットフォーム10から信頼性メトリックを取得する測定機能31,指定されたデータを署名,暗号化または解読する暗号機能32・・・および,適切なポート(36,37,38)を有し,マザーボード20のデータ・バス26,制御線27,およびアドレス線28のそれぞれに信頼できる装置24を接続するインタフェース回路34を備える)」という記載,及び,同じく上記Dの「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(信頼できる装置24におけるブロックの各々は,信頼できる装置24の適切な揮発性メモリ領域4および不揮発性メモリ領域3に対する(典型的にはコントローラ30経由の)アクセスを持つ信頼できる装置24におけるブロックの各々は,信頼できる装置24の適切な揮発性メモリ領域4および不揮発性メモリ領域3に対する(典型的にはコントローラ30経由の)アクセスを持つ)」という記載から,引用刊行物1においては,
“信頼できる装置は,コントローラ,測定機能,暗号機能,及び,マザーボードと接続するためのインタフェース回路,並びに,揮発性メモリ領域,及び,不揮発性メモリ領域を有している”ことが読み取れ,
上記Eの「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(測定機能31は,ハッシュ・プログラム354および信頼できる装置24の秘密鍵355を保存する不揮発性メモリ3および取得した信頼性メトリックをダイジェスト361の形態で保存する揮発性メモリ4にアクセスする)」という記載から,引用刊行物1においては,
“信頼性メトリックが,揮発性メモリに保存されている”ことが読み取れ,上記Dの記載内容において検討した事項と併せると,引用刊行物1においては,
“信頼性メトリックが,信頼できる装置が有するメモリに保存されている”ことが読み取れる。

4.上記Gの「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(ステップ530において,信頼できる装置24は,チャレンジを受け取り,該当する応答を作成する。応答は,測定された信頼性メトリックと一時的ワードのダイジェスト,および,オプションとして,そのIDラベルである。次に,ステップ535において,その秘密鍵を使用して,信頼できる装置24は,ダイジェストに署名し,認証書350と共に,署名されたダイジェストをユーザに送り返す)」という記載から,引用刊行物1においては,
“信頼できる装置は,チャレンジを受取り,測定された信頼性メトリックと一時的ワードとのダイジェストを生成し,前記ダイジェストに,信頼できる装置の秘密鍵を使用して署名し,署名されたダイジェストと,認証書とをユーザに送り返す”ことが読み取れる。

5.上記3.において引用した,上記Dの記載内容から,引用刊行物1においては,
“信頼できる装置が有するコントローラが,信頼できる装置の外側にあるマザーボード,或いは,その他の装置に,インタフェース回路を用いてアクセスする”ことが読み取れ,更に,上記Dの「 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(信頼できる装置24におけるブロックの各々は,信頼できる装置24の適切な揮発性メモリ領域4および不揮発性メモリ領域3に対する(典型的にはコントローラ30経由の)アクセスを持つ)」という記載内容から,引用刊行物1においては,
“コントローラは,信頼できる装置内の各ブロックからの要求に応じて,メモリにアクセスする”ことが読み取れるので,上記3.,及び,4.において検討した事項と併せると,引用刊行物1においては,
“信頼できる装置は,チャレンジを受取り,前記信頼できる装置が有するメモリにアクセスして,測定された信頼性メトリックを読み出し,前記測定された信頼性メトリックと,一時ワードのダイジェストを作成して,前記ダイジェストに,前記信頼できる装置の秘密鍵で署名して,前記信頼できる装置のインタフェース回路を介して,前記信頼できる装置の外部に出力する”ものであることが読み取れる。

6.上記1.において検討した事項と,上記2.?5.において検討した事項から,
引用刊行物1は,“サーバ,クライアントである,複数のコンピュータ・プラットフォームから構成されるシステムにおける,複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法”に関するものであることは明らかである。

以上1.?6.において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

サーバ,クライアントである,複数のコンピュータ・プラットフォームから構成されるシステムにおける,複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法であって,
コンピュータ・プラットフォームに含まれる,物理的に信頼できる装置が,チャレンジを受取り,
前記信頼できる装置が有するメモリにアクセスして,測定された信頼性メトリックを読み出し,
前記測定された信頼性メトリックと,一時ワードのダイジェストを作成して,前記ダイジェストに,前記信頼できる装置の秘密鍵で署名し,
前記信頼できる装置のインタフェース回路を介して,前記信頼できる装置の外部に出力する,方法。

第4.本願発明と引用発明との対比
1.引用発明における「複数のコンピュータ・プラットフォーム」は,「サーバ」となり得るものであるから,本願発明における「サーバ」に相当するので,
引用発明における「サーバ,クライアントである,複数のコンピュータ・プラットフォームから構成されるシステムにおける,複数のコンピュータ・プラットフォーム間の信頼性を検証するための方法」と,
本願発明における「サーバがデータセンタコンピュータシステム内に包含されているか検証する方法」とは,
“サーバが,所定の条件を満たすものであるかを検証する方法”である点で共通する。

2.引用発明における「チャレンジ」は,前記「チャレンジ」を受け取った「信頼できる装置」が,「信頼性メトリック」を外部に出力しているので,前記「信頼性メトリック」の送信を「要求」するための「リクエスト」と言い得るものであり,且つ,前記「チャレンジ」は,引用発明において,「コンピュータ・プラットフォーム」の「信頼性」を検証するためのものである。
そして,引用発明における「信頼性メトリック」は,前記「信頼できる装置」の「メモリ」に保存されているものであり,前記「信頼できる装置」は,前記「コンピュータ・プラットフォーム」に含まれるものであって,結果として,前記「信頼性メトリック」は,「コンピュータ・プラットフォーム」の「メモリ」に保存されているものと言い得るものであるから,
本願発明における「サーバのポリシーを表す値であって,前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ(PCR)に保持されている前記値」と,
“サーバに含まれる記憶手段に保持されている値”である点で共通するので,
引用発明における「コンピュータ・プラットフォームに含まれる,物理的に信頼できる装置が,チャレンジを受取り」と,
本願発明における「前記サーバに含まれるプラットフォームキーアプリケーションロジックが,前記包含されているか検証するための引用リクエストを受信するステップであって,前記引用リクエストは,前記サーバのポリシーを表す値であって,前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ(PCR)に保持される前記値に対するリクエストを含む,前記引用リクエストを受信するステップ」とは,
“サーバに含まれる手段が,所定の条件を満たすものであるかを検証するためリクエストを受信するステップであって,前記リクエストは,前記サーバに含まれる記憶手段に保持されている値に対するリクエストを含む,前記リクエストを受信するステップ”である点で共通する。

3.引用発明においても,「信頼できる装置」が,前記「信頼できる装置が有するメモリにアクセス」して,「測定された信頼性メトリック」を読み出しているので,
引用発明における「信頼できる装置が有するメモリにアクセスして,測定された信頼性メトリックを読み出」すことと,
本願発明における「前記プラットフォームキーアプリケーションロジックが,前記値を抽出するステップ」とは,
“サーバに含まれる手段が,サーバに含まれる記憶手段に保持されている値を抽出するステップ”である点で共通する。

4.引用発明においても「測定された信頼性メトリック」は,「信頼できる装置」の「秘密鍵」で署名され,前記「秘密鍵」は,「コンピュータ・プラットフォーム」に含まれる「信頼できる装置」の「メモリ」に保持されているものであるから,「コンピュータ・プラットフォーム」に保持されているものと言い得るものである。よって,
引用発明における「測定された信頼性メトリックと,一時ワードのダイジェストを作成して,前記ダイジェストに,前記信頼できる装置の秘密鍵で署名」することと,
本願発明における「サーバに含まれるプロセッサが,前記サーバに保持される暗号鍵ペアの秘密鍵を用いて前記値を署名するステップ」とは,
“サーバに含まれる装置が,前記サーバに保持される秘密鍵を用いて,前記サーバに含まれる記憶手段に保持されている値を署名するステップ”である点で共通する。

5.引用発明においても,“署名した値”を,「信頼できる装置」の外部に出力しており,上記「第3.引用刊行物に記載の発明」において引用した上記Gに記載された内容においては,「 the trusted device 24 signs the digest, using its private key, and returns the signed digest, accompanied by the certificate 350, to the user(信頼できる装置24は,ダイジェストに署名し,認証書350と共に,署名されたダイジェストをユーザに送り返す)」とあって,該「ユーザ」が,「コンピュータ・プラットフォーム」の外部にいる場合には,「コンピュータ・プラットフォーム」の外に出力する態様を含むものであることは明らかである。よって,
引用発明における「信頼できる装置のインタフェース回路を介して,前記信頼できる装置の外部に出力する」ことと,
本願発明における「プラットフォームキーアプリケーションロジックが,前記サーバに含まれるネットワークコントローラを用いて,前記引用リクエストに応答して前記署名された値を出力するステップ」とは,
“サーバに含まれる手段が,要求に応答して,署名された値を出力するステップ”である点で共通する。

よって,以上1.?5.において検討した事項から,本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
サーバが,所定の条件を満たすものであるかを検証する方法であって,
前記サーバに含まれる手段が,所定の条件を満たすものであるかを検証するためリクエストを受信するステップであって,前記リクエストは,前記サーバに含まれる記憶手段に保持されている値に対するリクエストを含む,前記リクエストを受信するステップと,
前記サーバに含まれる手段が,前記値を抽出するステップと,
前記サーバに含まれる装置が,前記サーバに保持される秘密鍵を用いて,前記値を署名するステップと,
サーバに含まれる手段が,要求に応答して,前記署名された値を出力するステップとを有する方法。

[相違点1]
“所定の条件”に関して,
本願発明においては,「サーバがデータセンタコンピュータシステム内に包含されている」というものであるのに対して,
引用発明においては,「複数のコンピュータ・プラットフォーム間の信頼性」というものである点。

[相違点2]
“サーバに含まれる手段”に関して,
本願発明においては,「プラットフォームキーアプリケーションロジック」というソフトウェアであるのに対して,
引用発明においては,「信頼できる装置」であって,ソフトウェアではない点。

[相違点3]
“サーバに含まれる記憶手段に保持されている値”に関して,
本願発明においては,「サーバのポリシーを表す値であって,前記サーバに含まれるプラットフォームコンフィギュレーションレジスタ(PCR)に保持される前記値」であるのに対して,
引用発明においては,「信頼できる装置が有するメモリ」に格納されている「信頼性メトリック」であって,“PCRに保持されているサーバのポリシーを表す値”ではない点。

[相違点4]
“サーバに含まれる装置”に関して,
本願発明においては,「サーバに含まれるプロセッサ」が,「署名」を行っているのに対して,
引用発明においては,「署名」を,「信頼できる装置」が行っている点。

[相違点5]
“前記署名された値を出力するステップ”に関して,
本願発明においては,「プラットフォームキーアプリケーションロジックが,前記サーバに含まれるネットワークコントローラを用いて」いるのに対して,
引用発明においては,「信頼できる装置」が,前記「信頼できる装置」を含む「コンピュータ・プラットフォーム」の有する“外部への通信制御機能”を用いているか不明である点。

第5.相違点についての当審の判断
1.[相違点1]について
「サーバ」が「クライアント」に提供する“サービス”として,“データセンタ”は,本願の原出願の第1国出願前に,当業者には周知の技術事項であって(例えば,本願の原出願の第1国出願前に既に公知である,特開2002-108818号公報(2002年4月12日公開,以下,これを「周知技術文献1」という)の【図1】等を参照されたい),
例えば,“システムのユーザが,該システムに含まれるサーバが正当であるかを検証することに換えて,該サーバが,該システムに含まれるものであるかを検証する”こととすることは,“検証する値の意味付けを変更する”程度のものであるから,引用発明においても,「システム」を,“データセンタ”の“サービス”を提供する「データセンタコンピュータシステム」とし,「コンピュータ・プラットフォーム」の信頼性の検証に換えて,該「データセンタコンピュータシステム」に含まれているかを検証するものとすることは,当業者が適宜なし得る事項に過ぎない。
よって,相違点1は,格別のものではない。

2.[相違点2]について
引用発明においても,「信頼できる装置」は,上記Dに引用した記載中にあるように,「 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(信頼できる装置24の動作全体を制御し,信頼できる装置24のその他の機能およびマザーボード20のその他の装置と対話するようにプログラムされたコントローラ30)」を有しており,該「プログラムされたコントローラ30」は,上記Dの記載内容に,「 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(ブロックの各々は,信頼できる装置24の適切な揮発性メモリ領域4および不揮発性メモリ領域3に対する(典型的にはコントローラ30経由の)アクセスを持つ)」とあるように,“プログラムであるコントローラ30を実行することで,メモリへのアクセス制御を行う”ものであるから,該「コントローラ」が,「リクエスト」を“受信する機能”を有する点の明言の記載はないものの,「リクエスト」の“受信処理”を行う機能を有するプログラム,即ち,「ソフトウェア」であるものと解され,また,仮に,他の機能が,該受信処理を行っているとしても,引用発明において,該「コントローラ」を,「リクエスト」の受信機能を有する「ソフトウェア」として構成することは,当業者が適宜なし得る事項である。
よって,相違点2は,格別のものではない。

3.[相違点3]について
“プラットフォームコンフィギュレーションレジスタ(PCR)に保持される値”を用いる点については,例えば,本願の原出願の第1国出願前に既に公知である,「Trusted ComputingPlatform Alliance Main SpecificationVersion 1.1b,2002年 2月22日,p.151」(以下,これを「周知技術文献2」という)に,

H.「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.」(151頁1行?30行)
(7.2.1 TPM_Seal
参考情報の開始:
シール処理は,ソフトウェアに,公開される秘密のため,プラットフォームが採るに違いない,将来の“信頼された”構成を,明言することを許可する。シール処理は,また,シール処理が実行されるとき,関連するプラットフォームの構成(PCR値)を暗黙的に含む。シール処理は,個別のTPMに,ブロブをバインドするために,tmp証明値を使用する。

もしシール解除処理が成功したのであれば,シール処理が実行されたときに実施された,プラットフォーム構成の証明は,秘密データを同様に,呼出し側に返される。この証明は,関心があるか,ないかである。もし,シールされた秘密が,第3者に対して,プラットフォームを認証するために用いられたのであれば,呼出し側は,通常,秘密がシールされたときに,プラットフォームの状態について,関係がなく,そして,証明には関心がない。他方,もし,シールされた秘密が,プラットフォームに対して,第3者を認証するために用いられたのであれば,呼出し側は,秘密がシールされたときに,プラットフォームの状態について関係がある。そのとき,証明には関心がある。

例えば,もしシールが,将来の構成のために秘密鍵を格納するために用いられるのであれば(おそらく,プラットフォームが,特別な構成における,特別なプラットフォームであることを証明するために),唯一の条件は,プラットフォームが,その将来の構成内にあるときのみに,その鍵が用いられることである。次に,秘密鍵がシールされた時に,プラットフォームの構成には興味がない。この場合の例は,シールが,ネットワーク認証鍵を格納するために用いられる時である。

他方,OSが,プラットフォーム上で,ログを取ることを許可された,暗号化されたユーザのデータベースを含むと仮定する。そのOSは,ユーザ-データベースのために,暗号化された鍵を格納するために,シールされたブロブを用いる。しかしながら,シールの本質は,任意のソフトウェア・スタックが,その他のソフトウェア・スタックのためのブロブを,シールすることである。それ故,そのOSは,第2のOSから,シールされたブロブ暗号鍵と,ユーザ・データベース自身を置換する,そのOSのサービスに,信頼できない者のアクセスを許可する,攻撃を受ける。それ故,もし,そのOSが,このような攻撃について懸念があれば,過去の構成が信頼されることが知られているものであるかどうか見るためにチェックするかもしれない。

TPM_シールは,パラメータの暗号化を要求する(“秘密”)。より多くのパラメータの暗号化を要求する他のコマンドとの均一性のために,排他的論理和暗号化のために用いられた文字列は,秘密を共有するセッションにおいて,(OSAPセッションの間に生成された)ノンスを結合することによって,生成され,そして,次に結果がハッシュされる。

参考情報の終了。<当審にて訳出。なお,下線は,当審にて,説明の都合上附加したものである。>)

という記載が存在するように,本願の原出願の第1国出願前に,当業者には,周知の技術事項である。
本願発明においては,「サーバのポリシーを表す値」がどのようなものであるかの限定がなされていないが,この点に関して,本願明細書の発明の詳細な説明(以下,単に「本願明細書」という)を参酌すると,本願明細書には,

「【0049】
ブロック502において,フロー図500は,データセンタの生成のためのポリシーから開始される。図3に示される実施例を参照することにより,管理者ユニット106の管理論理302は,プラットフォームがデータセンタ140内に含まれるべきかに関するポリシーを生成する。一実施例では,このポリシーは,プラットフォーム104のためのハードウェアメトリックを備えるものであってもよい。例えば,ポリシーは,TCPAに基づくTPMモジュールがプラットフォーム104内になければならいという要請を含むことができる。ポリシーのためのハードウェアメトリックの他の例としては,プロセッサのタイプや,プラットフォーム104が安全と考えられるアプリケーションにメモリへのアクセスを限定するように,様々なタイプの私有あるいは安全なメモリを備えるかどうかなどがあげられる。他の例としては,プラットフォーム104内のメモリの一部や他のユニットがそれへのアクセスに関して制限するようバーチャルマシーン監視の必要性があげられる。ポリシーのハードウェアメトリックの他の例としては,プラットフォーム104内に暗号化アクセラレータカード,ネットワークカードなどが含まれるというものであってもよい。
【0050】
一実施例では,このポリシーは,プラットフォーム104のためのソフトウェアメトリックを有する。例えば,ポリシーは,プラットフォームが所与のタイプのオペレーティングシステムあるいはその上で実行される他のタイプのより高いレベルのアプリケーションを実行していることの要求を含むものであってもよい。ポリシーに要求されるより高いレベルのアプリケーションの例としては,あるタイプのデータベース,当該データベースのためのインタフェースアプリケーション及びあるタイプの暗号化処理を実行する暗号化アプリケーションがあげられる。
【0051】
管理論理302は,データセンタの管理者からの入力に基づきこのポリシーを生成するようにしてもよい。そのような実施例では,このポリシーは,データセンタのユーザが要求する必要条件や基準に基づくものであるかもしれない。例えば,第1のプラットフォーム群は秘匿性のある情報を通信することなくプラットフォームからのデータの抽出を可能にするが,第2のプラットフォーム群は秘匿性のある情報/財務情報のアップロードを含む書籍,おもちゃなどの電子商取引を可能にし,第3のプラットフォーム群は安全性を求められる政府文書,個人の医療記録などを含む高い秘匿性を有する情報のアップロードを可能にする。従って,これら様々なタイプのプラットフォーム群のポリシーの必要条件は,プラットフォームとの通信のタイプに基づき変化する。」

という記載が存在し,上記引用の記載中に,本願における「ポリシー」が例示されているが,本願発明の構成から,本願発明の「ポリシー」を,上記引用記載中の例示の何れかに限定解釈しなければならない根拠は存在しない。
そして,該例示中に,「一実施例では,このポリシーは,プラットフォーム104のためのハードウェアメトリックを備えるものであってもよい」,或いは,「一実施例では,このポリシーは,プラットフォーム104のためのソフトウェアメトリックを有する」とあり,本願発明における「ポリシー」が,上記指摘の例示のものであるとすれば,引用発明における「信頼性メトリック」と格別相違しない。
また,仮に,上記引用記載中に例示された,他の「ポリシー」であったとしても,何れの「ポリシー」も,「システム」の利用者が,必要に応じて適宜設定し得る程度のものであって,引用発明において,そのような「ポリシー」を採用することは,当業者が適宜なし得る事項である。
よって,相違点3は,格別のものではい。

4.[相違点4]について
上記Cに「 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(例えば,諸機能およびそれら対話が破壊されることができないと仮定すれば,主プロセッサに信頼できる装置の1つまたは複数の機能を主プロセッサに統合することは可能である)」と記載されていて,引用発明において,「信頼できる装置の1つまたは複数の機能」を,「信頼できる装置」ではない,「主プロセッサ」に割り当てることが可能であるから,引用発明において,「署名」する機能を,「プロセッサ」に割り当てることは,当業者が適宜なし得る事項である。
よって,相違点4は,格別のものではい。

5.[相違点5]について
上記Dの記載内容にもあるとおり,引用発明においては,「信頼できる装置」は,前記「信頼できる装置」を有する「コンピュータ・プラットフォーム」の「マザーボード」と接続されており,前記「コンピュータ・プラットフォーム」は,外部との通信を行い得るものであるから,前記「信頼できる装置」から,「コンピュータ・プラットフォーム」の外部に対して,“データ”等を送信する場合に,「コンピュータ・プラットフォーム」の“通信のためのコントローラ”を使用するよう構成することは,当業者が適宜なし得る事項である。
よって,相違点5は,格別のものではない。

上記で検討したごとく,相違点1?相違点5はいずれも格別のものではなく,そして,本願発明の構成によってもたらされる効果も,引用発明,及び,当該技術分野における周知技術から,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

第6.むすび
したがって,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2014-10-30 
結審通知日 2014-11-04 
審決日 2014-11-19 
出願番号 特願2010-243228(P2010-243228)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 平井 誠  
特許庁審判長 辻本 泰隆
特許庁審判官 田中 秀人
石井 茂和
発明の名称 データセンタへのプラットフォームの内包検証  
代理人 伊東 忠彦  
代理人 大貫 進介  
代理人 伊東 忠重  

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