拒絶査定不服の審決｜不服2019-14920 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない。 G06F 審判査定不服特17 条の２、４項補正目的特許、登録しない。 G06F 審判査定不服 5項独立特許用件特許、登録しない。 G06F
管理番号	1362020
審判番号	不服2019-14920
総通号数	246
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2020-06-26
種別	拒絶査定不服の審決
審判請求日	2019-11-06
確定日	2020-04-30
事件の表示	特願2015-218286「擬似故障の発生プログラム、発生方法、及び発生装置」拒絶査定不服審判事件〔平成29年 5月25日出願公開、特開2017- 91077〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は,平成27年11月6日を出願日とする出願であって,平成31年4月19日付けの拒絶理由通知に対して令和1年7月16日付けで意見書が提出されるとともに手続補正がなされたが,令和1年7月30日付けで拒絶査定がなされ,これに対して令和1年11月6日に拒絶査定不服審判の請求がなされるとともに手続補正がされ,令和1年11月28日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされたものである。第2 令和1年11月6日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 令和1年11月6日にされた手続補正(以下「本件補正」という。)を却下する。 [理由] 1 本件補正について(補正の内容) (1)本件補正後の特許請求の範囲の記載本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された。(下線部は,補正箇所である。) 「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに、前記故障の発生が割り込みハンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置での擬似故障を発生させるためのプログラムであり、前記情報処理装置を管理する管理コンピュータに、前記管理コンピュータに接続される外部装置から前記擬似故障を発生させる対象のコンポーネントおよび搭載位置情報を指定した指令を受け付け、前記プロセッサをシステム管理モードに移行させ、前記システム空間に擬似故障を示す情報を設定し、前記設定後に前記プロセッサをシステム管理モードから非システム管理モードに移行させ、前記プロセッサに前記擬似故障に対応する割り込みを発生させること、を実行させるためのプログラム。」 (2)本件補正前の特許請求の範囲本件補正前の,令和1年7月16日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。「プロセッサおよび前記プロセッサに接続される部品のいずれかでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに、前記故障の発生が割り込みンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置での擬似故障を発生させるためのプログラムであり、前記情報処理装置を管理する管理コンピュータに、前記管理コンピュータに接続される外部装置から前記擬似故障を発生させる擬似故障発生箇所を指定した指令を受け付け、前記プロセッサをシステム管理モードに移行させ、前記システム空間に擬似故障を示す情報を設定し、前記設定後に前記プロセッサをシステム管理モードから非システム管理モードに移行させ、前記プロセッサに前記擬似故障に対応する割り込みを発生させること、を実行させるためのプログラム。」 2 本件補正の目的について本件補正は,(ア)本件補正前の請求項1に記載された発明を特定するために必要な事項である「プロセッサおよび前記プロセッサに接続される部品のいずれかでの故障が」との記載を,「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障が」との記載に補正し,(イ)本件補正前の請求項1に記載された発明を特定するために必要な事項である「前記擬似故障を発生させる擬似故障発生箇所を指定した指令」との記載を,「前記擬似故障を発生させる対象のコンポーネントおよび搭載位置情報を指定した指令」との記載に補正する,ことを含む。このうち,上記(イ)に係る補正は,本件補正前の請求項1に記載された発明を特定するために必要な事項である「擬似故障」の「発生」を「指定」する対象について,上記のとおり限定を付加するものといい得るものであり,補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。次に,上記(ア)に係る補正は,本件補正前の「プロセッサおよび前記プロセッサに接続される部品のいずれか」との記載が,「プロセッサ」と「部品」のいずれかを意味するにとどまるのに対し,本件補正後の「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネント」との記載は,「プロセッサ」と「部品」を含む「コンポーネント」を意味するものとなっていて,「故障」の対象が「プロセッサ」と「部品」以外の要素を含みうる「コンポーネント」という構成を特定するものとなっているから,特定する事項の範囲が広がっており,限定的減縮を目的としたものであるとは認めらない。また,上記本件補正前の記載に不明りょうな記載や誤記も認めらないから,本件補正は,特許法第17条の2第5項第1号(請求項の削除),第3号(誤記の訂正),第4号(明瞭でない記載の釈明)に掲げる事項を目的とするものでもない。以上より,本件補正は特許法第17条の2第5項の規定に違反するものである。 3 独立特許要件について以上のとおり,本件補正は,特許法第17条の2第5項に規定する要件に違反するものであり,却下されるべきものであるが,仮に,本件補正が,限定的減縮を目的とするものであるとみなしうる余地があるとして,本件補正後の請求項1に記載される発明(以下「本件補正発明」という。)が同条6項において準用する同法126条7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。 (1)本件補正発明本件補正発明は,上記1(1)に記載したとおりのものである。 (2)引用文献の記載事項ア引用文献1 (ア)原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった特表2015-505396号公報(以下,「引用文献1」という。)には,図面とともに,次の記載がある。(下線は当審で付した。以下,同様。) A 「【0001】本発明は概してセキュアなエラーハンドリングに関する。【背景技術】【0002】サーバシステム(特に、拡張可能な、スケーラブルな、ミッションクリティカルなシステム)は、より良好な信頼性(Reliability)、可用性(Availability)及び保守性(Serviceability)(RAS)のエクスペリエンスのためのエラー検出、エラー訂正、エラーリカバリ及びエラーロギングの能力を備えている。【0003】マシンチェックアーキテクチャ(MCA)が、インテルXeｏn(登録商標)プロセッサにおいて用いられて、プロセッサ関連のエラーを上位レイヤソフトウェアにレポートする。マシンチェックアーキテクチャは、典型的には、コア、キャッシュなどのプロセッサコンポーネント関連のエラーに限定される。しかしながら、メモリコントローラ、PCIeルートコンプレックスの、Xeｏn(登録商標)プロセッサソケットへの統合とともに、マシンチェックアーキテクチャのスコープは、すべてのこれらのコンポーネントからのエラーハンドリング及びRASイベントを包含するようにレポートされている。マシンチェックアーキテクチャにおける別の進化が、エラーリカバリであり、これにおいて、プロセッサ/プラットフォームの観点から訂正できないエラーが、リカバリのため、オペレーティングシステム(OS)又は仮想マシンモニタ(VMM)に提供される。【0004】上記のイノベーションを考慮すると、プラットフォーム上のエラーハンドリング、エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを、オペレーティングシステムベンダ(OSV)及び/又は仮想マシンベンダ(VMV)において包括的に検証することが重要である。これは、RAS/エラーハンドリングコードカバレッジと呼ばれる。上記コードカバレッジにより、OS及び/又はVMMは、エラーハンドリング、リカバリ及びRAS機構がエンドツーエンドで実際に動作していることを保証することが可能となる。これには、種々のプロセッサコア、プロセッサキャッシュ、メモリ、入出力装置、システム相互接続などにおけるエラーなどの、種々のタイプのエラーを生成することを含む。エラーハンドリング能力を検証するために、エラー注入能力を、製造プラットフォーム上での実行時にOS及び/又はVMMが利用可能であることが必要となる。ハードウェアにおいて、種々のエラーサブシステム上にすべてのエラーケースについての実際のエラー注入メカニズムを実装することは、非常に複雑となり、非常に高価となる。さらに、エラー注入メカニズム自体は、システムのセキュリティに対するリスクをもたらすべきではない。【0005】エラーハンドリングコードは、現状、限定されたセットの実際のエラー注入を用いて検証されている。実施のエラー注入メカニズムは、1回に1つだけのエラーを注入することを可能にする。したがって、エラーハンドリングコードは、限定されたエラーコード実行カバレッジしか得られない。ひいては、多くの手作業のコードレビューを行ってさらなるコードカバレッジパスを決定することが必要となる。【発明の概要】【発明が解決しようとする課題】【0006】いくつかの従前の実装は、リング0コードからMCAバンクに書き込むことを、別のリング0コードアクセス可能レジスタに書き込むことによって、可能にしている。これは、セキュリティホールである。MCAバンク書き込み有効化レジスタがリング0ドメイン内にあるため、任意のリング0コードが、MCAバンク書き込み能力を有効にしに行き、MCAバンクに書き込み、無用のエラーケースを引き起こす可能性がある。さらに、従前の実装は、マシンチェックアーキテクチャ(MCA)及び訂正マシンチェックエラー割り込み(Corrected Machine Check Error Interrupt)(CMCI)などのエラーのシグナル送信を提供せず、上記実装の機構の有用性を限定している。【0007】本願発明者らはさらに、現在の解決法がMCAバンク書き込み有効化/無効化能力の保護又はエラーシグナル送信(MCA/CMCI)生成有効化/無効化の保護を提供しないことを、識別している。【課題を解決するための手段】【0008】いくつかの実施形態が、オペレーティングシステムと、プロセッサを含むプラットフォームとを含む。プロセッサは、エラーレジスタを含む。オペレーティングシステムは、プラットフォームを介してセキュアな方式でのみエラーレジスタに書き込むことができる。」 B 「【0010】本発明のいくつかの実施形態は、セキュアなエラーハンドリングに関する。【0011】いくつかの実施形態において、マシンチェックエラーコードカバレッジのためのエラー注入が、実施するのにセキュアかつ効率的である(例えば、インテルサーバプロセッサ及び/又はインテルXeｏn(登録商標)プロセッサのためのいくつかの実施形態において)。【0012】いくつかの実施形態は、オペレーティングシステムと、システム管理モード(SystemManagement Mode)(SMM)制御(例えば、及び/又はSMM機能及び/又はSMMファームウェア)を含む基本入出力システムと、エラーレジスタを含むプロセッサとを含む。オペレーティングシステムは、システム管理モード制御、機能、ファームウェアなどを介してのみエラーレジスタに書き込むことができる。【0013】いくつかの実施形態は、オペレーティングシステムと、プロセッサを含むプラットフォームとを含む。プロセッサは、エラーレジスタを含む。オペレーティングシステムは、プラットフォームを介してセキュアな方式でのみエラーレジスタに書き込むことができる。いくつかの実施形態において、オペレーティングシステムは、プラットフォームファームウェアを介してセキュアな方式でのみエラーレジスタに書き込むことができる。【0014】図1は、いくつかの実施形態に従うシステム100を示す。いくつかの実施形態において、システム100は、プラットフォーム102と、オペレーティングシステム/仮想マシンモニタ(又はリング0コード)104と、エラーハンドラ106と、アプリケーション/ゲストオペレーティングシステム108と、アプリケーション/ゲストオペレーティングシステム110とを含む。いくつかの実施形態において、プラットフォーム102は、プロセッサ(及び/又はプロセッサハードウェア)122と、システム基本入出力システム(BIOS)124と、エラー注入ソフトウェア抽象化126とを含む。いくつかの実施形態において、システムBIOS124は、システム管理モード(SMM)コード/データ128(及び/又はSMM制御、SMM機能、SMMコントローラなど)を含む。いくつかの実施形態において、SMMコード/データは、ファームウェアで実装される。いくつかの実施形態において、プロセッサ122は、マシンチェックアーキテクチャ(MCA)バンク書き込み能力有効/無効レジスタ132と、エラーシグナル送信(error signaling)マシンチェックアーキテクチャ(MCA)/訂正マシンチェックエラー割り込み(CMCI)有効/無効レジスタ134とを含む。【0015】いくつかの実施形態において、プロセッサ122は、MCAメモリバンクへの書き込みを有効にする又は無効にすることができる。いくつかの実施形態において、プロセッサ122は、モデル固有レジスタ(Model Specific Register)(MSR)又はコンフィギュレーション空間レジスタ(Configuration Space Register)(CSR)としてエラーをシグナル送信することができる。いくつかの実施形態に従い、プロセッサ122内の有効/無効レジスタ132及び134は、システム管理モード(SMM)からのみアクセス可能である。このことは、オペレーティングシステム(OS)コードが、信頼されたSMMコードを直接経由することなしに、上記機構を有効にすることは決してできないことを、確かにする。【0016】いくつかの実施形態において、MCAバンクへの書き込みは、リング0コード104から実施される。いくつかの実施形態において、リング0コード104は、MCA/CMCIをシグナル送信することができる。いくつかの実施形態において、MCAバンク書き込み能力は、システム管理モード(SMM)からのみ有効にされ及び/又は無効にされ、上記機構の利用についてのセキュリティを提供する。いくつかの実施形態において、エラーシグナル送信(MCA/CMCI)は、SMMからのみ有効にされ及び/又は無効にされ、上記機構の利用についてのセキュリティを提供する。いくつかの実施形態において、オペレーティングシステム(OS)は、コードカバレッジのためのセキュアなエラー注入の可用性を検出する。いくつかの実施形態において、BIOS/OSインタフェースとして、OSに対するエラー注入機能のソフトウェア抽象化が実装される。」 C 「【0018】図3は、いくつかの実施形態に従うフロー300を示す。いくつかの実施形態において、フロー300は、エラーログ/エラーシグナル送信ハードウェアの書き込みを有効化/無効化するシステム管理モード(SMM)コードフローを示す。いくつかの実施形態において、フロー300は、OSがBIOS/OSインタフェースを呼び出してMCAバンク書き込み能力及びエラーシグナル送信能力を有効/無効にするときに、SMMコードにより行われる動作を示す。【0019】いくつかの実施形態において、フロー300は、302においてシステム管理割り込み(System Management Interrupt)(SMI)モジュールにおいて始まる。304において、上記SMIがエラーハンドリングコードカバレッジをもたらすSMIであるかどうかに関して、決定が行われる。上記SMIがエラーハンドリングコードカバレッジをもたらすSMIではないことが304において決定された場合、306において、通常のSMIフローが継続される。上記SMIがエラーハンドリングコードカバレッジをもたらすSMIであることが304において決定された場合、308において、エラーログハードウェア有効化及び/又は無効化が所望されるかどうかに関して、決定が行われる。エラーログハードウェア有効化及び/又は無効化が308において所望されない場合、フローは310に移動し、ここでは、エラーシグナル送信有効化/無効化を決定するように、決定がなされる。エラーログハードウェア有効化/無効化が308において所望される場合、312において、エラーログハードウェア(MCAバンク)書き込み能力の有効化/無効化が行われ、フローが、要求された動作を310に移動する前に設定することができない場合、エラーで応答する。エラーシグナル送信有効化/無効化が310においてまったく決定されない場合、306において通常のSMIフローが継続される。エラーシグナル送信有効化/無効化が310において決定された場合、314において、エラーシグナル送信能力の有効化/無効化が行われ、306において通常のSMIフローが継続される。【0020】図4は、いくつかの実施形態に従うフロー400を示す。いくつかの実施形態において、フロー400は、エラーを注入するためのOSフローを示す。いくつかの実施形態において、フロー400は、OSがどのようにBIOS/OSインタフェースを実行し(consumes)、いくつかの実施形態に従うシステムにエラーを注入するのかを示す。【0021】フロー400は、402において始まり、ここでは、BIOS/OSインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能であるのかどうかに関して、決定が行われる。402においてBIOS/OSインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能でない場合、404において、プラットフォームがエラー注入能力をサポートしない(例えば、MCAバンクエラー注入能力をサポートしない)という決定が行われる。402においてBIOS/OSインタフェースがエラーハンドリングコードカバレッジエラー注入に利用可能である場合、406において、注入すべきエラーが決定される(例えば、エラーログリストを構築することによる)。次いで408において、MCAバンク書き込み能力が、BIOSインタフェース(及び/又はACPIインタフェース)を呼び出すことによって有効にされる。410において、MCAバンク書き込み能力が成功したかどうかに関して、決定が行われる。成功しなかった場合、412においてエラー注入は失敗する。成功した場合、414において、エラーがリストから選択される。416において、エラーを設定すべきスレッドが選択され、エラーを設定すべきMCAバンクが選択される。418において、エラーログデータが書き込まれる。420において、現在のMCAバンクが読み出され、読み出されたものが書き込まれた値に一致するかどうかに関して、決定が行われる。一致しなかった場合、フローが418に戻される前に、422において、現在のMCAバンクがクリアされ、別のMCAバンクが選択され、すべてのバンクが使い尽くされている場合はエラーが生じる。420において読み出されたものが書き込まれた値に一致する場合、424において、エラーリスト内のすべてのエラーが設定されたかどうかに関して、決定が行われる。設定されていない場合、フローは414に戻される。設定されている場合、426において、MCAバンクの非ゼロの書き込み能力が、BIOSインタフェース(及び/又はACPIインタフェース)を呼び出すことによって無効にされる。これは、成功したエラー登録セットアップを示し、428において、エラーがシグナル送信される。次いで430において、MCA/CMCIシグナル送信能力が、BIOSインタフェース(及び/又はACPIインタフェース)を呼び出すことによって有効にされる。次いで432において、CMCIがシグナル送信されるべきである場合、要求されたスレッドが選択される。次いで434において、MCA又はCMCIがシグナル送信される(例えば、BIOSインタフェース動作シーケンスを呼び出すことによる)。次いで436において、MCA/CMCIシグナル送信能力が無効にされる。」 D 「【0024】いくつかの実施形態において、OS/ドライバが、コードカバレッジのためのエラー注入を行う準備ができていることを決定する。次いで、OS/ドライバは、BIOSインタフェースを呼び出してMCAバンク書き込み能力を有効にする。この時点で、OS/ドライバ(リング0コード)は、MCAバンクに書き込む。エラーハンドリングコードカバレッジ検証ドライバが、検証において関心のあるエラーを決定し、種々のMCAバンク及びスレッドのためのエラーログ値を構築する。検証ドライバは、選択されたMCAバンク及びスレッドにエラーログを書き込む。次いで、エラータイプに基づいて、検証ドライバは、例えば、CMCI又はMCAをシグナル送信する。いったんエラーがシグナル送信されると、割り込みがエラーハンドラを起動させ、エラーハンドラは、実際のエラーを受信したのかを考え、標準的にエラーを処理する。エラーハンドリングコードパスを検証するためにエラーハンドラコードを変更する必要はない。いくつかの実施形態に従うエラー注入が、1のエラーをシグナル送信する前に複数のMCAバンク及びスレッド上のエラーが作成される方式で、実施される。この方式において、同時的なエラーシナリオを作成することができる。【0025】いくつかの実施形態に従い、MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあり、エラー注入中にデータがまったく公開されないため、セキュリティホールはまったく公開されない。【0026】いくつかの実施形態において、種々のタイプのエラーが、エラーをシグナル送信する前に、種々のMCAバンク、種々の中央処理ユニット(CPU)若しくはプロセッサスレッド、及び/又は種々のCPU若しくはプロセッサソケット上に設定される。このことは、種々のエラーハンドラコードフローの実行を可能にし、従前には可能ではなかった種々のエラーシナリオを作成する。これらのタイプのシナリオの作成は、エラーハンドリングフローにおける様々なコーナーケースの検証を可能にする。【0027】いくつかの実施形態において、MCAバンク書き込み及びエラーシグナル送信の機構は、システム管理モード(SMM)からのみ許容される。SMMアーキテクチャは、SMMコード又はデータにSMMの外部からアクセスすることができなくなるため、プラットフォームに対してセキュリティを提供する。このことは、マルウェア又は信頼されていないコードがSMMに入り込み、上記の機構を有効にすることが、決してないことを確かにする。【0028】いくつかの従前の実装は、リング0コードからMCAバンクを書き込むことを、別のリング0コードアクセス可能レジスタに書き込むことによって、許容する。これは、セキュリティホールである。MCAバンク書き込み有効化レジスタがリング0ドメイン内にあるため、任意のリング0コードが、MCAバンク書き込み能力を有効にしに行き、MCAバンクに書き込み、無用のエラーケースを引き起こす可能性がある。さらに、従前の実装は、MCA及びCMCIなどのエラーのシグナル送信を提供せず、上記実装の機構の有用性を限定している。【0029】現在の解決法は、MCAバンク書き込み有効化/無効化能力の保護又はエラーシグナル送信(MCA/CMCI)生成有効化/無効化の保護を提供していない。いくつかの実施形態に従い、保護が、MCAバンク書き込み能力及びエラーシグナル送信能力の有効化について提供される。いくつかの実施形態において、MCAバンク書き込み能力及びエラーシグナル送信能力の有効化/無効化についてのソフトウェア抽象化が実装される。いくつかの実施形態において、ハードウェアが変化した場合、エラーハンドリングコードカバレッジエラー注入は変更する必要がない。【0030】いくつかの実施形態において、MCAバンク書き込みの有効化及び/又は無効化が実装される(エラーロギングハードウェア書き込み)。いくつかの実施形態において、エラーシグナル送信ハードウェアの利用が保護される。いくつかの実施形態において、ソフトウェアに対するハードウェア実装の抽象化が実装され、したがってハードウェア実装レジスタ又は配置が変化した場合にソフトウェアの変更は必要なくなる。【0031】いくつかの実施形態において、オペレーティングシステムベンダ(OSV)がエラーハンドリングフローを検証することができ、プロセッサ上のRASのOS実装(例えば、サーバプロセッサ及び/又はインテルXeｏn(登録商標)プロセッサ)がより良好な品質を有することになる。このことは、RAS/エラーハンドリングを有効化するコストを削減する。いくつかの実施形態に従い、任意のエラーの組み合わせを、MCAバンクに投入する(populated)ことができ、OSは、シリコンが利用可能となる前でさえ、セキュアな方式で将来の機構のエラーハンドリングを検証することが可能となる。」 (イ)上記(ア)Aの【0004】には【背景技術】として「上記のイノベーションを考慮すると、プラットフォーム上のエラーハンドリング、エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを、オペレーティングシステムベンダ(OSV)及び/又は仮想マシンベンダ(VMV)において包括的に検証することが重要である。・・・エラーハンドリング能力を検証するために、エラー注入能力を、製造プラットフォーム上での実行時にOS及び/又はVMMが利用可能であることが必要となる。・・・さらに、エラー注入メカニズム自体は、システムのセキュリティに対するリスクをもたらすべきではない。」と記載されており,当該記載から,引用文献1における背景として,プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを,オペレーティングシステムベンダ(OSV)及び/又は仮想マシンベンダ(VMV)において包括的に検証するために,セキュアなエラー注入メカニズムを利用可能とすることが必要されていること,が読み取れる。 (ウ)上記(イ)の【背景技術】に対する【課題を解決するための手段】として,上記(ア)Aの【0008】に「いくつかの実施形態が、オペレーティングシステムと、プロセッサを含むプラットフォームとを含む。プロセッサは、エラーレジスタを含む。オペレーティングシステムは、プラットフォームを介してセキュアな方式でのみエラーレジスタに書き込むことができる。」と記載されていることから,引用文献1から,オペレーティングシステムと,プロセッサを含むプラットフォームからなり,オペレーティングシステムがプラットフォームを介してセキュアな方式でのみ,プロセッサが有するエラーレジスタに書き込むことができる構成が読み取れ,また,上記(ア)Bの【0014】の「いくつかの実施形態に従うシステム100を示す。いくつかの実施形態において、システム100は、プラットフォーム102と、オペレーティングシステム/仮想マシンモニタ(又はリング0コード)104と、・・・を含む。いくつかの実施形態において、プラットフォーム102は、プロセッサ(及び/又はプロセッサハードウェア)122と、・・・を含む。」との記載から,上記オペレーティングシステム及びプロセッサを含むプラットフォームによる構成がシステムを形成することが読み取れ,さらに,上記(ア)Aの【0002】に【背景技術】として「サーバシステム(特に,拡張可能な,スケーラブルな、ミッションクリティカルなシステム)は、より良好な信頼性(Reliability)、可用性(Availability)及び保守性(Serviceability)(RAS)のエクスペリエンスのためのエラー検出、エラー訂正、エラーリカバリ及びエラーロギングの能力を備えている。」と記載されていることから,上記オペレーティングシステム及びプロセッサを含むプラットフォームを含むシステムが,サーバシステムにおけるエラー処理の能力を備えているものであると読み取れることができる。以上から,引用文献1には,オペレーティングシステムとプロセッサを含むプラットフォームを含み,サーバシステムにおけるエラー処理の能力を備えた,オペレーティングシステムがプラットフォームを介してセキュアな方式でのみプロセッサが有するエラーレジスタに書き込むことができるシステム,が記載されているといえる。 (エ)上記(イ)における「オペレーティングシステム」が「プロセッサが有するエラーレジスタに書き込む」点に関し,上記(ア)Cの【0019】の「エラーログハードウェア有効化/無効化が308において所望される場合、312において、エラーログハードウェア(MCAバンク)書き込み能力の有効化/無効化が行われ、フローが、要求された動作を310に移動する前に設定することができない場合、エラーで応答する。」との記載によれば,「オペレーティングシステム」がエラー情報を書き込む「MCAバンク」が「エラーレジスタ」に当たるといえる。以上(イ)ないし(エ)を総合すると,引用文献1には, “プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを,オペレーティングシステムベンダ(OSV)及び/又は仮想マシンベンダ(VMV)において包括的に検証するために必要とされるエラー注入メカニズムを利用可能とする, オペレーティングシステムとプロセッサを含むプラットフォームを含み,サーバシステムにおけるエラー処理の能力を備えた,オペレーティングシステムがプラットフォームを介してセキュアな方式でのみプロセッサが有するMCAバンクであるエラーレジスタに書き込むことができるシステム” が記載されているといえる。 (オ)上記(ア)Bの【0014】に「プラットフォーム102は、プロセッサ(及び/又はプロセッサハードウェア)122と、システム基本入出力システム(BIOS)124と、エラー注入ソフトウェア抽象化126とを含む。・・・いくつかの実施形態において、プロセッサ122は、マシンチェックアーキテクチャ(MCA)バンク書き込み能力有効/無効レジスタ132と、エラーシグナル送信(error signaling)マシンチェックアーキテクチャ(MCA)/訂正マシンチェックエラー割り込み(CMCI)有効/無効レジスタ134とを含む」との記載から, “プラットフォームは,プロセッサ(及び/又はプロセッサハードウェア)と,システム基本入出力システム(BIOS)と,エラー注入ソフトウェア抽象化とを含み,上記プロセッサは,マシンチェックアーキテクチャ(MCA)バンク書き込み能力有効/無効レジスタと,エラーシグナル送信マシンチェックアーキテクチャ(MCA)/訂正マシンチェックエラー割り込み(CMCI)有効/無効レジスタとを含む” ことが読み取れる。 (カ)上記(エ)におけるシステムに関し,さらに,上記(ア)Dの【0024】に「いくつかの実施形態において、OS/ドライバが、コードカバレッジのためのエラー注入を行う準備ができていることを決定する。次いで、OS/ドライバは、BIOSインタフェースを呼び出してMCAバンク書き込み能力を有効にする。この時点で、OS/ドライバ(リング0コード)は、MCAバンクに書き込む。エラーハンドリングコードカバレッジ検証ドライバが、検証において関心のあるエラーを決定し、種々のMCAバンク及びスレッドのためのエラーログ値を構築する。検証ドライバは、選択されたMCAバンク及びスレッドにエラーログを書き込む。次いで、エラータイプに基づいて、検証ドライバは、例えば、CMCI又はMCAをシグナル送信する。いったんエラーがシグナル送信されると、割り込みがエラーハンドラを起動させ、エラーハンドラは、実際のエラーを受信したのかを考え、標準的にエラーを処理する。」と記載されており,当該記載の実施形態では,上記(エ)のシステムのうちプラットフォームを介してセキュアな方式でMCAバンクに書き込むのは,オペレーティングシステムが有するドライバであり,そして,上記(ア)Cの【0020】?【0021】の「いくつかの実施形態において、フロー400は、エラーを注入するためのOSフローを示す。・・・406において、注入すべきエラーが決定される(例えば、エラーログリストを構築することによる)。次いで408において、MCAバンク書き込み能力が、BIOSインタフェース(及び/又はACPIインタフェース)を呼び出すことによって有効にされる。・・・414において、エラーがリストから選択される。416において、エラーを設定すべきスレッドが選択され、エラーを設定すべきMCAバンクが選択される。418において、エラーログデータが書き込まれる。・・・428において、エラーがシグナル送信される。・・・次いで434において、MCA又はCMCIがシグナル送信される」との記載によれば,上記【0024】の記載における,エラー注入を行う準備についての決定,MCAバンク書き込み能力の有効化,MCAバンクへの書き込み,検証において関心のあるエラーの決定,エラーログ値の構築,エラーログの書き込み,次いで,CMCI又はMCAのシグナル送信,エラーハンドラの起動についても,オペレーティングシステムが有するドライバによって行われており,よって,引用文献1の記載から,上記(エ)におけるシステムにおいて, “エラー注入を行う準備ができていることを決定し,次いで,MCAバンク書き込み能力を有効にし,MCAバンクに書き込み,検証において関心のあるエラーを決定し,種々のMCAバンク及びスレッドのためのエラーログ値を構築し,選択されたMCAバンク及びスレッドにエラーログを書き込み,次いで,エラータイプに基づいてCMCI又はMCAをシグナル送信し,いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ,標準的にエラーを処理させる,オペレーティングシステムが有するドライバ” を読み取ることができる。 (キ)上記(ア)Dの【0025】の「いくつかの実施形態に従い、MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあり、エラー注入中にデータがまったく公開されないため、セキュリティホールはまったく公開されない。」との記載から,上記(オ)におけるオペレーティングシステムの有するドライバによるエラー注入において, “MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあり,エラー注入中にデータがまったく公開されない” ことが読み取れる。 (ク)上記(ア)Dの【0026】の「いくつかの実施形態において、種々のタイプのエラーが、エラーをシグナル送信する前に、種々のMCAバンク、種々の中央処理ユニット(CPU)若しくはプロセッサスレッド、及び/又は種々のCPU若しくはプロセッサソケット上に設定される。このことは、種々のエラーハンドラコードフローの実行を可能にし、従前には可能ではなかった種々のエラーシナリオを作成する。」と記載されていることから,上記(オ)におけるオペレーティングシステムの有するドライバによるエラー注入について, “種々のタイプのエラーが,エラーをシグナル送信する前に,種々のMCAバンク,種々の中央処理ユニット(CPU)若しくはプロセッサスレッド,及び/又は種々のCPU若しくはプロセッサソケット上に設定され,種々のエラーハンドラコードフローの実行を可能とする” ことが読み取れ,この場合の「種々のタイプのエラー」とは,上記(ア)Aの【背景技術】における【0004】に記載されている「上記コードカバレッジにより、OS及び/又はVMMは、エラーハンドリング、リカバリ及びRAS機構がエンドツーエンドで実際に動作していることを保証することが可能となる。これには、種々のプロセッサコア、プロセッサキャッシュ、メモリ、入出力装置、システム相互接続などにおけるエラーなどの、種々のタイプのエラーを生成することを含む」ことを前提とするものと解されることから, “種々のタイプのエラーが,種々のプロセッサコア,プロセッサキャッシュ,メモリ,入出力装置,システム相互接続などにおけるエラーなどを含む” ことが読み取れる。 (ケ)上記(ア)ないし(ク)から,引用文献1には,次の発明(以下「引用発明」という。)が記載されていると認められる。「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを,オペレーティングシステムベンダ(OSV)及び/又は仮想マシンベンダ(VMV)において包括的に検証するために必要とされるエラー注入メカニズムを利用可能とする, オペレーティングシステムとプロセッサを含むプラットフォームを含み,サーバシステムにおけるエラー処理の能力を備えた,オペレーティングシステムがプラットフォームを介してセキュアな方式でのみプロセッサが有するMCAバンクであるエラーレジスタに書き込むことができるシステムであり,上記プラットフォームは,プロセッサ(及び/又はプロセッサハードウェア)と,システム基本入出力システム(BIOS)と,エラー注入ソフトウェア抽象化とを含み,上記プロセッサは,マシンチェックアーキテクチャ(MCA)バンク書き込み能力有効/無効レジスタと,エラーシグナル送信マシンチェックアーキテクチャ(MCA)/訂正マシンチェックエラー割り込み(CMCI)有効/無効レジスタとを含む,システムにおいて, エラー注入を行う準備ができていることを決定し,次いで,MCAバンク書き込み能力を有効にし,MCAバンクに書き込み,検証において関心のあるエラーを決定し,種々のMCAバンク及びスレッドのためのエラーログ値を構築し,選択されたMCAバンク及びスレッドにエラーログを書き込み,次いで,エラータイプに基づいてCMCI又はMCAをシグナル送信し,いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ,標準的にエラーを処理させる,オペレーティングシステムが有するドライバであって, 上記エラー注入において, MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあり,エラー注入中にデータがまったく公開されず, 種々のタイプのエラーが,エラーをシグナル送信する前に,種々のMCAバンク,種々の中央処理ユニット(CPU)若しくはプロセッサスレッド,及び/又は種々のCPU若しくはプロセッサソケット上に設定され,種々のエラーハンドラコードフローの実行を可能とするものであり, 上記種々のタイプのエラーが,種々のプロセッサコア,プロセッサキャッシュ,メモリ,入出力装置,システム相互接続などにおけるエラーなどを含む, オペレーティングシステムが有するドライバ。」イ引用文献2 同じく原査定の拒絶の理由で引用された本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった特開平7-334385号公報(以下「引用文献2」という。)には,次の記載がある。 E 「【0019】図4は、本発明の検証方法の手順を示すフローチャートであり、テスト作業者は検証対象装置1を通常の運用状態と同様に立ち上げる。この時、検証プログラム10は起動されない。【0020】しかし、保守診断機能を検証する場合、コンソール装置16からの指示に従って起動される。【0021】検証プログラム10が起動されると、テスト制御部100がコンソール装置16の画面上に疑似障害テスト項目の一覧を表示させる。この状態でテスト制御部100はテスト作業者からのテスト実行番号入力待ちとなる。【0022】そこで、テスト作業者がコンソール装置16に表示された疑似障害テスト項目の一覧の中から所望のテスト項目番号を選択すると、テスト制御部100は選択されたテスト項目番号を解析し、当該テスト項目番号に対応したテストタスクTSnを選択する(ステップ400)。【0023】例えば、テストタスクTS1を選択する。すると、テストタスクTS1は、図3の保守コード期待値テーブル19からテストタスクTS1に対応した障害要因データD1を読出し、この障害要因データD1をハードウェア部15の疑似障害発生レジスタ11に対してセットする(ステップ401)。」ウ引用文献3 同じく原査定の拒絶の理由で周知文献として引用された本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった特開2011-170822号公報(以下「引用文献3」という。)には,次の記載がある。 F 「【0045】そして、擬似故障発生/診断制御部51は、試験モードの時、擬似故障の発生および動作結果情報の収集処理全体を制御する。制御データ経路を介して受信する監視端末2からの擬似故障発生の指示コマンド、あるいは論理ボリュームのデータ伝送経路から受け取る特殊論理ボリューム(後述)により指定される擬似故障発生コードに応じて、データ処理ユニット内で擬似故障を発生させる部位を指定し、擬似故障発生動作処理部52に指示して当該箇所に故障を発生させる動作を制御する。」エ引用文献4 同じく原査定の拒絶の理由で周知文献として引用された本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった特開2008-140198号公報(以下「引用文献4」という。)には,次の記載がある。 G 「【0042】図15は、実施例2におけるサーバ管理機能の動作フローを示している。実施例1との違いは、ステップ1501で擬似障害発生指示の受信を契機にフローが開始されるのと、擬似障害を発生させることである。ステップ1502では、擬似障害を発生させる。擬似障害を発生させる部位等の情報は、ステップ1501の受信した擬似障害発生指示から取得する。」 (3)引用発明との対比ア本件補正発明と引用発明とを対比する。 (ア)引用発明の「プロセッサ」は,本件補正発明の「プロセッサ」に対応する。また,引用発明は,エラー注入の対象として「種々のプロセッサコア、プロセッサキャッシュ、メモリ、入出力装置、システム相互接続などにおけるエラーなどを含む」ものであり,エラー処理の検証のためのエラー注入の対象は「プロセッサ」のみならず「プロセッサ」に接続される「メモリ」も含まれることから,引用発明における当該「メモリ」は,本件補正発明の「プロセッサに接続される部品」に相当する。また,引用発明における上記エラー注入の対象のうち「プロセッサコア」及び「メモリ」は,「プロセッサ」及び「メモリ」を含むコンポーネントといいうるから,本件補正発明の「コンポーネント」に相当する。また,引用発明の「MCAバンク」は,「エラー注入において,MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあ」るものであって,システム管理モードでアクセス可能なメモリ領域といい得るものであり,一方,本件補正発明の「システム空間」とは,発明の詳細な説明の段落【0040】に「SMRAM領域は、システム空間の一例である。」と記載されていることを踏まえるとSMRAM領域等のメモリ領域を含むことから,引用発明の上記「MCAバンク」は,本件補正発明の「システム管理モードでアクセス可能なシステム空間」に相当するといえる。また,引用発明は「いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ」るものであり,引用発明の当該「割り込み」に基づき起動される「エラーハンドラ」は,本件補正発明の「割り込みハンドラ」に相当する。また,引用発明の「プラットフォーム」に含まれる「プロセッサ」及び当該「プロセッサ」に接続される「メモリ」からなる構成は,情報処理を一体として行う装置と呼びうるものであり,また,「エラー注入メカニズム」によって「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリ」が「予期されるとおりに動作する」ことを検証する対象となるものであるから,本件補正発明の「情報処理装置」に対応する。 (イ)引用発明は,「オペレーティングシステムが有するドライバ」によって「エラー注入を行う準備ができていることを決定し,次いで,MCAバンク書き込み能力を有効にし,MCAバンクに書き込み,検証において関心のあるエラーを決定し,種々のMCAバンク及びスレッドのためのエラーログ値を構築し,選択されたMCAバンク及びスレッドにエラーログを書き込み,次いで,エラータイプに基づいてCMCI又はMCAをシグナル送信し,いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ,標準的にエラーを処理させる」ものであって,当該「エラー注入」は「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあ」るとともに,その対象は「種々のプロセッサコア,プロセッサキャッシュ,メモリ,入出力装置,システム相互接続などにおけるエラーなどを含む」エラーであることから,引用発明における上記「エラー注入」は,プロセッサと当該プロセッサに接続されるメモリを含むコンポーネント(本件補正発明の「コンポーネント」に相当)でのエラーについてMCAバンク(本件補正発明の「システム管理モードでアクセス可能なシステム空間」に相当)に記録することを含むといえる。また,引用発明は「いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ,標準的にエラーを処理させる」ものであり,引用発明における上記「エラー注入」は,エラーの発生がエラーハンドラ(本件補正発明の「割り込みハンドラ」)を起動させるために割り込みによって通知されるものであるといえ,そして,「標準的にエラーを処理させる」とは,「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリ」によるエラー処理であって,当該エラー処理がプロセッサにより実行されることは明らかであるから,上記「エラー注入」における割り込みによる通知はプロセッサによりなされるものであるといえる。以上を総合すると,引用発明の「プロセッサ」について,「オペレーティングシステムが有するドライバ」によってなされる「エラー注入」がプロセッサと当該プロセッサに接続されるメモリを含むコンポーネントでのエラーについてMCAバンクに記録することを含み,「エラーハンドラ」を起動させるためにエラーの発生を「割り込み」によって通知させるものであることは,本件補正発明の「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに、前記故障の発生が割り込みハンドラに割り込みで通知されるプロセッサ」に相当するといえ,そして,上記(ア)の検討も踏まえると,引用発明の「プラットフォーム」に含まれる上記「プロセッサ」及び当該「プロセッサ」に接続される「メモリ」からなる構成は,本件補正発明の「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに、前記故障の発生が割り込みハンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置」に相当するといえる。 (ウ)引用発明である「オペレーティングシステムが有するドライバ」における「ドライバ」とはプログラムであるから,引用発明である上記「オペレーティングシステムが有するドライバ」は,本件補正発明である「プログラム」に対応する。そして,引用発明である上記「オペレーティングシステムが有するドライバ」は,「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを」検証する上で「エラー注入」を行うためのものであり,この場合の「注入」するエラーとは「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリ」の動作を検証するためのものであり,システム上の異常を擬似的に示すものであって疑似故障と言いうるものであるから,引用発明の「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリ」の動作を検証する上で「エラー注入」を行うための上記「オペレーティングシステムが有するドライバ」は,本件補正発明の「情報処理装置での擬似故障を発生させるためのプログラム」に相当するといえる。そして,上記(イ)の検討も踏まえると,引用発明である「オペレーティングシステムが有するドライバ」と本件補正発明である「プログラム」とは,「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに、前記故障の発生が割り込みハンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置での擬似故障を発生させるためのプログラム」である点で共通するといえる。 (エ)引用発明は,「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあ」るところ,この場合の「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御」の対象である「マシンチェックアーキテクチャ(MCA)バンク書き込み能力有効/無効レジスタと、エラーシグナル送信マシンチェックアーキテクチャ(MCA)/訂正マシンチェックエラー割り込み(CMCI)有効/無効レジスタ」とはいずれも「プロセッサ」に含まれ,「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御」を行うために「システム管理モード(SMM)の範囲内」に当然に移行する必要があるから,引用発明は,プロセッサをエラー注入のためにシステム管理モードに移行させているといえ,よって本件補正発明と引用発明とは,「前記プロセッサをシステム管理モードに移行させ」ている点で一致しているといえる。 (オ)引用発明は,「エラー注入」のために「選択されたMCAバンク及びスレッドにエラーログを書き込み」を行っているから,上記(ウ)の検討も踏まえると,本件補正発明と引用発明とは,「前記システム空間に擬似故障を示す情報を設定し」ている点で一致しているといえる。 (カ)引用発明は,上記(ウ)のとおり,「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御とはシステム管理モード(SMM)の範囲内にあ」り,これは「プロセッサ」が有する「MCAバンク」に対し「セキュアな方式でのみ」「書き込むことができるシステム」を前提とするものであるところ,「エラー注入」のために「選択されたMCAバンク及びスレッドにエラーログを書き込み,次いで,エラータイプに基づいてCMCI又はMCAをシグナル送信し,いったんエラーがシグナル送信される」と,上記「セキュアな方式」での書き込みを担保するため,引用発明では上記「MCAバンク有効化及び/又は無効化とエラーシグナル送信制御」を実行できないように「システム管理モード(SMM)の範囲」から範囲外へ移行する必要があり,これはシステム管理モードの範囲外であって非システム管理モードといいうることから,本件補正発明と引用発明とは,「前記設定後に前記プロセッサをシステム管理モードから非システム管理モードに移行させ」ている点で一致しているといえる。 (キ)上記(イ)の検討のとおり,引用発明は「エラー注入」において「いったんエラーがシグナル送信されると,割り込みがエラーハンドラを起動させ,標準的にエラーを処理させる」ものであり,上記「エラー注入」における割り込みによる通知はプロセッサによりなされるものであるといえ,この場合の「プロセッサ」によりなされる「割り込み」の通知のための出力が,本件補正発明における「プロセッサ」による「割り込み」の「発生」に相当するといえる。よって,本件補正発明と引用発明とは,「前記プロセッサに前記擬似故障に対応する割り込みを発生させる」点で一致しているといえる。イ以上のことから,本件補正発明と引用発明との一致点及び相違点は,次のとおりである。 (一致点) プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに,前記故障の発生が割り込みハンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置での擬似故障を発生させるためのプログラムであり, 前記プロセッサをシステム管理モードに移行させ, 前記システム空間に擬似故障を示す情報を設定し, 前記設定後に前記プロセッサをシステム管理モードから非システム管理モードに移行させ, 前記プロセッサに前記擬似故障に対応する割り込みを発生させること, を実行させるためのプログラム。 (相違点1) 本件補正発明は,プログラムが,「情報処理装置を管理する管理コンピュータ」に,システム管理モードへの移行,擬似故障を示す情報の設定,非システム管理モードへの移行,割り込みの発生等の処理を実行させるものであるのに対し, 引用発明は,オペレーティングシステムが有するドライバが,システム中のオペレーティングシステムのいずれにおいて,エラー注入メカニズムを実行させるかについては特定されていない点。 (相違点2) プログラムが実行させる処理について本件補正発明は,「管理コンピュータに接続される外部装置から前記擬似故障を発生させる対象のコンポーネントおよび搭載位置情報を指定した指令を受け付け」ることを含むのに対し, 引用発明は,上記処理を行わせることについては特定されていない点。 (4)判断ア相違点1について本件補正発明の「情報処理装置を管理する管理コンピュータ」はその記載から,管理対象の情報処理装置と異なるコンピュータという構成を指すものと解され,発明の詳細な説明に一例として挙げられた「MMB 11」(【0033】)に限定されるものではない。これは,本件補正発明の【発明が解決しようとする課題】欄に記載の「汎用コンポーネント等の部品を搭載した情報処理装置において、物理的な専用機器や使用環境に依存せず、簡易かつ汎用的に擬似故障、あるいは故障の予兆を発生させることができる技術を提供することを目的とする」(【0006】)ことに対し,汎用コンポーネント等の部品を搭載した情報処理装置の物理的な専用機器や使用環境に依存せず,擬似故障または故障予兆を発生しうる構成上の位置づけにあるものであれば課題解決手段となりうること,とも整合することから,上記のとおり,本件補正発明の「情報処理装置を管理する管理コンピュータ」とは,管理対象の情報処理装置と異なるコンピュータという構成を意味するものと解される。それに対し引用発明は,サーバシステムのエラー処理対象であるプラットフォーム内のプロセッサやメモリ等を管理するオペレーティングシステムにおいて,エラー注入メカニズムを行うドライバが,システム上のいずれの構成上にあるのか特定されていないものの,オペレーティングシステムがプラットフォームの環境外であることからドライバについても同様にプラットフォームの環境外であると解され,また,ドライバによるエラー注入メカニズムは,プロセッサやメモリ等に実際の物理的障害があるか否かとは無関係に,プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリ等の機能が予期されるとおりに動作するか否かを検証可能であることが求められているから,オペレーティングシステムが有する当該ドライバの機能を,引用発明のシステムにおいて,少なくともプラットフォームが有するプロセッサやメモリ等とは異なる構成として実装する動機づけがあるといえ,また,一般に,プロセッサやメモリ等にエラー動作検証時以外にはアクセスしないドライバを同じ構成内に実装すべき事情は見いだせず,どのように実装するかは当業者が適宜決定して行うべき事項と認められる。そして,引用発明は,「プラットフォーム上のエラーハンドリング,エラーレポーティング及びエラーリカバリがオペレーティングシステム(OS)及び/又は仮想マシンモニタ(VMM)によって予期されるとおりに動作することを」,「検証するために必要とされるエラー注入メカニズムを利用」するもので,エラー注入メカニズムを実現するドライバを含むオペレーティングシステムを,コンピュータを仮想化した仮想マシンモニタ(VMM)として構成することも想定するものであるから,以上を総合すると,引用発明におけるオペレーティングシステムが有する上記ドライバを,プラットフォームが有するプロセッサやメモリ等とは異なるコンピュータという構成として実装することは,当業者であれば適宜なしうる程度の事項であると認められる。そうすると,引用発明において,相違点1に係る構成とすることは,当業者であれば容易に想到し得たものといえる。イ相違点2について引用文献2には,情報処理装置の保守診断機能の検証方法において,情報処理装置の外部にある装置(コンソール)から疑似故障を発生させる指令を送信する技術が記載されており(上記(2)のウEの記載を参照。),また引用発明は,ドライバが「検証において関心のあるエラーを決定し」,その上で「選択されたMCAバンク及びスレッドにエラーログを書き込」むものであって,検証のためのエラーを決定するために検証を求める側の構成から検証したい「関心」内容を受け入れることを前提とするから,他からのエラー指令を送信させるよう構成する,すなわち上記引用文献2記載の技術を適用する動機付けがあるといえる。そして一般に,情報処理装置を対象とした疑似障害による動作検証は,検証対象の構成や障害内容を決定し,疑似障害を発生した際の装置の動作を確認することで行うものであり,また,その際に検証対象として同種の構成が複数あればそれを識別して検証できるように疑似障害を決定することは,動作検証として当然に担保すべき事項であるから,疑似障害を発生させる検証対象を識別できるよう,情報処理装置における構成の搭載位置を指定するよう疑似障害の指令を受信する構成することは,情報処理装置を対象とした疑似障害による動作検証として普通に行うべき技術常識であるといえる(例えば,引用文献3の上記(2)のウFの記載,引用文献4の上記(2)のエGの記載を参照。)。そうすると,引用発明のドライバが行うエラー注入として,同様の技術分野に属する疑似故障を発生させる指令に係る上記引用文献2記載の技術を適用するとともに,当該疑似故障を発生させる指令として,情報処理装置における検証対象の構成を識別して決定できるよう,検証対象である構成に対しコンポーネントや搭載位置を指定する内容を含む指令を受信する構成とすることは,エラー注入を行うドライバの実装態様に関係なく当業者であれば容易になしうる程度の事項であり,そしてその際に,上記アで検討のとおり,エラー注入を行うドライバの実装態様がプロセッサやメモリ等とは異なるコンピュータという構成になされていれば,外部装置からの疑似故障を発生させる対象のコンポーネントや搭載位置を指定する内容を含む指令は,当然に,管理対象とは異なる構成上に実装されたドライバに対し送信させることとなり,すなわち,「管理コンピュータに接続される外部装置から前記擬似故障を発生させる対象のコンポーネントおよび搭載位置情報を指定した指令を受け付け」る構成となることとなる。そうすると,引用発明において,相違点2に係る構成とすることは,引用発明,引用文献2の記載の技術,技術常識から当業者であれば容易に想到し得たものといえる。ウそして,本件補正発明の奏する作用効果は,引用発明,引用文献2の記載の技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。エしたがって,本件補正発明は,引用発明,引用文献2の記載の技術,技術常識に基づいて,当業者が容易に発明をすることができたものであり,特許法29条2項の規定により,特許出願の際独立して特許を受けることができないものである。 4 本件補正についてのむすびよって,本件補正は,特許法第17条の2第5項の規定に違反するものであり,仮に違反しないものとみなしうるとしても,本件補正は,特許法17条の2第6項において準用する同法126条7項の規定に違反するので,同法159条1項の規定において読み替えて準用する同法53条1項の規定により却下すべきものである。よって,上記補正の却下の決定の結論のとおり決定する。第3 本願発明について 1 本願発明令和1年11月6日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,令和1年7月16日にされた手続補正により補正された特許請求の範囲の請求項1ないし5に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下「本願発明」という。)は,その請求項1に記載された事項により特定される,前記第2の1(2)に記載のとおりのものである。 2 原査定の拒絶の理由原査定の拒絶の理由2は,この出願の請求項1ないし5に係る発明は,本願の出願日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用例1に記載された発明及び引用例2ないし5に記載された技術に基づいて,その出願日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない,というものである。引用例1:特表2015-505396号公報(上記第2の3(2)における引用文献1) 引用例2:特開2014-146110号公報引用例3:特開平7-334385号公報(上記第2の3(2)における引用文献2) 引用例4:特開2011-100300号公報引用例5:特開2011-170822号公報(上記第2の3(2)における引用文献3) 引用例6:特開2008-140198号公報(上記第2の3(2)における引用文献4) 3 引用文献原査定の拒絶の理由で引用された引用例のうち,引用例1,3,5,6とその記載事項は,前記第2の3(2)アないしエに記載したとおりである。 4 対比・判断本願発明は,本件補正発明における「プロセッサおよび前記プロセッサに接続される部品を含むコンポーネントでの故障が」を,「プロセッサおよび前記プロセッサに接続される部品のいずれかでの故障が」とするともに, 同じく本件補正発明における「前記擬似故障を発生させる対象のコンポーネントおよび搭載位置情報を指定した指令」を,「前記擬似故障を発生させる擬似故障発生箇所を指定した指令」とするものであることから,前記第2の2(3)における対比の検討内容を踏まえると,本願発明と引用発明との一致点及び相違点は,次のとおりである。 (一致点) プロセッサおよび前記プロセッサに接続される部品のいずれかでの故障がシステム管理モードでアクセス可能なシステム空間に記録されるとともに,前記故障の発生が割り込みンドラに割り込みで通知されるプロセッサおよび前記部品を有する情報処理装置での擬似故障を発生させるためのプログラムであり, 前記プロセッサをシステム管理モードに移行させ, 前記システム空間に擬似故障を示す情報を設定し, 前記設定後に前記プロセッサをシステム管理モードから非システム管理モードに移行させ, 前記プロセッサに前記擬似故障に対応する割り込みを発生させること, を実行させるためのプログラム。 (相違点1’) 本願発明は,プログラムが,「情報処理装置を管理する管理コンピュータ」に,システム管理モードへの移行,擬似故障を示す情報の設定,非システム管理モードへの移行,割り込みの発生等の処理を実行させるものであるのに対し, 引用発明は,オペレーティングシステムが有するドライバが,システム中のオペレーティングシステムのいずれにおいて,エラー注入メカニズムを実行させるかについては特定されていない点。 (相違点2’) プログラムが実行させる処理について本願発明は,「管理コンピュータに接続される外部装置から前記擬似故障を発生させる擬似故障発生箇所を指定した指令を受け付け」ることを含むのに対し, 引用発明は,上記処理を行わせることについては特定されていない点。上記相違点について検討する。ア相違点1’について上記相違点1’は前記第2の2(3)の相違点1と同じであるから,前記第2の2(4)アと同様の理由により,引用発明において,相違点1’に係る構成とすることは,当業者であれば容易に想到し得たものといえる。イ相違点2’について前記第2の2(4)イでの言及と同様の理由により,疑似障害を発生させる検証対象を識別できるよう,情報処理装置における構成の箇所を指定するよう疑似障害の指令を受信する構成することは,情報処理装置を対象とした疑似障害による動作検証として普通に行うべき技術常識であるといえる(例えば,引用例5(上記第2の3(2)における引用文献3)の上記(2)のウFの記載,引用例6(上記第2の3(2)における引用文献4)の上記(2)のエGの記載を参照。)。そうすると,前記第2の2(4)イでの言及と同様の理由により,引用発明のドライバが行うエラー注入として,同様の技術分野に属する疑似故障を発生させる指令に係る上記引用文献2記載の技術を適用するとともに,当該疑似故障を発生させる指令として,情報処理装置における検証対象の構成を識別して決定できるよう,検証対象に対し発生箇所を指定する内容を含む指令を受信する構成とすることは,エラー注入を行うドライバの実装態様に関係なく当業者であれば容易になしうる程度の事項であり,そしてその際に,上記アで引用する前記第2の2(4)アで検討のとおり,エラー注入を行うドライバの実装態様がプロセッサやメモリ等とは異なるコンピュータという構成になされていれば,外部装置から疑似故障を発生させる対象の発生箇所を指定する内容を含む指令は,当然に,管理対象とは異なる構成上に実装されたドライバに対し送信させることとなり,すなわち,「管理コンピュータに接続される外部装置から前記擬似故障を発生させる擬似故障発生箇所を指定した指令を受け付け」る構成となることとなる。そうすると,引用発明において,相違点2’に係る構成とすることは,引用発明,引用文献2の記載の技術,技術常識から当業者であれば容易に想到し得たものといえる。したがって,本願発明は,引用発明,引用文献2の記載の技術,技術常識に基づいて,当業者が容易に発明をすることができたものである。第4 むすび以上のとおり,本願発明は,特許法29条2項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。よって,結論のとおり審決する。
審理終結日	2020-02-25
結審通知日	2020-03-03
審決日	2020-03-17
出願番号	特願2015-218286(P2015-218286)
審決分類	P 1 8・ 57- Z (G06F) P 1 8・ 121- Z (G06F) P 1 8・ 575- Z (G06F)
最終処分	不成立
前審関与審査官	井上宏一
特許庁審判長	田中秀人
特許庁審判官	山崎慎一仲間晃
発明の名称	擬似故障の発生プログラム、発生方法、及び発生装置
代理人	高田大輔
代理人	平川明
代理人	大竹裕明

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