【事件の表示】
　特願２００６−１２６９９１「論理分割されたマルチプロセッシング・システム内で発生するエラー・イベントを報告する標準化されたフォーマット」拒絶査定不服審判事件〔平成１８年　９月１４日出願公開、特開２００６−２４４５２２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　平成１４年２月２６日（パリ条約による優先権主張２００１年３月１日、アメリカ合衆国）に出願された特願２００２−４９０８０号の一部を平成１８年４月２８日に新たな特許出願としたものであって、
　平成１８年９月１９日付けで最初の拒絶理由通知（同年同月２６日発送）がなされ、
　平成１９年３月２３日付けで意見書が提出されるとともに、手続補正がなされ、
　平成２０年５月２１日付けで最後の拒絶理由通知（同年同月２７日発送）がなされ、
　同年８月２７日付けで意見書が提出されるとともに、手続補正がなされ、
　同年９月１８日付けで同年８月２７日付けの手続補正を却下する旨の補正の却下の決定（同年９月２４日発送）がなされるとともに、同年同月１８日付けで拒絶査定（同年同月２４日発送）がなされ、
　同年１２月１１日付けで審判請求がなされるとともに、手続補正がなされ、
　平成２１年３月４日付けで審査官より特許法第１６４条第３項の規定による前置報告がなされ、
　平成２２年８月２３日付けで当審より審尋（同年同月２４日発送）がなされ、
　この審尋に対して、同年１０月２０日付けで回答書が提出され、
　同年１２月７日付けで当審より最初の拒絶理由通知（同年同月１４日発送）がなされ、
　同年１２月２０日付けで意見書が提出されるとともに、手続補正がなされたものである。
　
第２．本願発明の認定
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年１２月２０日付けの手続補正により補正された、本願の特許請求の範囲の請求項１に記載された次のものと認められる。
　
「複数のプロセッサと複数のメモリ・ユニットとを含むリソースを有するコンピュータ・システムであって、当該コンピュータ・システムが複数の論理区画に分割され、各々の論理区画には少なくとも１つのプロセッサと少なくとも１つのメモリ・ユニットとを含むリソースがそれぞれ割り当てられ、当該論理区画には、複数のオペレーティング・システムのうちの互いに異なる１つのオペレーティング・システムがそれぞれ割り当てられて稼動するコンピュータ・システムにおいて、当該コンピュータ・システム内で発生するエラー・イベントを報告するための方法であって、
　前記複数の論理区画のうちの１つの論理区画において、当該論理区画に割り当てられた１つのオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、当該論理区画の中で発生するエラー・イベントを検出させるステップと、
　前記１つのオペレーティング・システムが、前記プロセッサに、前記エラー・イベントについての情報を含むイベント・ログ・エントリを所定のフォーマットに基づいて生成させるステップとを有し、
　前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムを識別するためのオペレーティング・システム識別フィールドが、前記所定のフォーマット中に含まれ、
　前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールドが、前記所定のフォーマット中に含まれ、
　前記１つのオペレーティング・システムが、前記プロセッサに、エラー・イベントを報告するための所定のフォーマット（書式）に基づいて前記イベント・ログ・エントリ内の前記情報をフォーマット化（書式化）させるステップであって、前記所定のフォーマットに基づいて、各々の論理区画に割り当てられて稼動するそれぞれのオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、エラー・イベントを報告するためにイベント・ログ・エントリ内にエラー情報を配置させ、さらに、各々の論理区画に前記複数のオペレーティング・システムのうちのどの１つが割り当てられているかにかかわらず、当該論理区画に割り当てられたプロセッサが、前記所定のフォーマットに基づいてフォーマット化を行なうことを特徴とする、
　方法。」
　
第３．先行技術文献に記載されている技術的事項と先行技術文献に記載されている発明の認定
３の１．引用例１に記載されている技術的事項
　当審が拒絶理由通知において引用した特開２０００−２５９４３５号公報（平成１２年９月２２日出願公開。以下、「引用例１」という。）には、図面とともに以下の技術的事項が記載されている。
　
（１−１）
「【０００２】
【従来の技術】図３に、従来のマルチオペレーティングシステムの構成ブロック例図を示す。図中、３１はマルチオペレーティングシステムであり、マルチオペレーティングシステム３１はシステムＡ３２と、システムＢ３３とで構成されている。
【０００３】なお、システムＡ３２とシステムＢ３３は、それぞれ独立したシステムであり、それぞれのシステムにはシステム全体を制御するＯＳ３２３、３３３と、システムに接続された入出力装置３２６、３３６と、入出力装置３２６、３３６などのアクセスを制御するドライバ３２４、３３４と、オペレータからシステムへの指示やシステムからオペレータへの通知、例えばエラー発生時にエラー情報をオペレータに通知するコンソール３２２、３３２と、エラー情報のログを記録するためのロギング装置３２７、３３７と、ジョブを実行するためＯＳ３２３、３３３により生成されるプロセス３２１、３３１とで構成されている。
【０００４】次に、システムＡ３２におけるエラー発生時のエラー情報の通知処理とログ処理の動作を説明する。ＯＳ３２３により生成されたプロセス３２１は、与えられた処理を実行するため、ドライバ３２４を介して入出力装置３２６などをアクセスする。このとき、装置エラーが発生すると、ドライバ３２４内のエラー処理部３２５が実行される。そして、エラー処理部３２５は、入出力装置３２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をＯＳ３２３内の通知／ログ処理部３２８に通知する。
【０００５】そして、通知／ログ処理部３２８は、通知されたエラー詳細情報をわかりやすい形式に編集し、装置エラーが発生したことをオペレータに通知するためコンソール３２２にエラー発生の通知およびエラー詳細情報を表示し、また装置エラーが発生したことを記録するためロギング装置３２７にエラー詳細情報などを記録する。
【０００６】なお、システムＢ３３においてもエラー発生時のエラー情報の通知処理とログ処理の動作は、システムＡ３２と同じである。
【０００７】図４に、エラー情報およびエラー情報ログの一実施例図を示す。図４（ａ）はシステムＡ３２におけるエラー情報とエラー情報ログであり、図４（ｂ）はシステムB３３におけるエラー情報とエラー情報ログである。図４（ａ）および図４（ｂ）ともフロッピー媒体の読込みでエラーが発生したものであり、図４（ａ）では（  ）内にセンス情報をわかりやすい形式に編集して表示し、図４（ｂ）はセンス情報をそのまま１６進数で表示している。」
　
（１−２）
「【０００８】
【発明が解決しようとする課題】このように、図３に示す従来技術では、装置エラーのエラー情報をオペレータに通知するために使用するコンソールなど、エラー情報通知先がシステム毎に異なるため、システム毎のコンソールを監視しなければならないという問題点があった。また、エラー情報の詳細が格納されるエラー情報ログの格納先もシステム毎に異なるため、システム毎のエラー情報ログを参照しなければならないという問題点があった。また、エラー情報およびエラー情報ログの編集形式がシステム毎に異なるため、システム毎のエラー情報およびエラー情報ログにおける編集形式の知識が必要になるという問題点があった。」
　
（１−３）
「【００１１】また、同一ハードウェア上で複数の異なるオペレーティングシステムを同時稼動させるマルチオペレーティングシステムにおいて、エラー情報およびエラー情報ログを集約する特定のオペレーティングシステムに、前記の特定のオペレーティングシステムと異なるオペレーティングシステムから装置エラーの通知を受け、特定のオペレーティングシステムのエラー情報の形式に変換し、特定のオペレーティングシステムの通常装置と同じインタフェースで装置エラーの通知を行う疑似装置制御部を設け、かつ、前記の特定のオペレーティングシステムと異なるオペレーティングシステムに、装置エラーの発生時、装置エラーの発生とエラー情報を疑似装置制御部に通知するエラー処理部を設け、マルチオペレーティングシステムで発生する全ての装置エラーのエラー情報およびエラー情報ログを特定のオペレーティングシステムに集約することにより、マルチオペレーティングシステムに接続された全ての装置の装置管理を簡素化することが可能となる。」
　
（１−４）
「【００１４】
【実施例】図１に、本発明のマルチオペレーティングシステムの一実施例の構成ブロック図を示す。図中、１１はマルチオペレーティングシステムであり、マルチオペレーティングシステム１１はシステムＡ１２と、システムＢ１３とで構成されている。
【００１５】なお、システムＢ１３は、マルチオペレーティングシステムに接続された全ての装置で発生するエラー情報およびエラー情報ログを集約するシステムであり、システム全体を制御するＯＳ１３３と、システムに接続された入出力装置１３６と、入出力装置１３６などのアクセスを制御するドライバ１３４と、オペレータからシステムへの指示やシステムからオペレータへの通知、例えばエラー発生時にエラー情報をオペレータに通知するコンソール１３２と、エラー情報のログを記録するためのロギング装置１３７と、ジョブを実行するためＯＳ１３３により生成されるプロセス１３１と、他のオペレーティングシステムから装置エラーの通知を受け、システムＢ１３のエラー情報の形式に変換し、システムＢ１３に接続されている通常装置と同じインタフェースで装置エラーの通知およびエラー詳細情報をＯＳ１３３内の通知／ログ処理部１３８に通知する疑似装置制御部１３９とで構成されている。
【００１６】また、システムＡ１２は、システムに接続された入出力装置で発生するエラー情報およびエラー情報ログをシステムＢ１３に通知するシステムであり、システム全体を制御するＯＳ１２３と、システムに接続された入出力装置１２６と、入出力装置１２６などのアクセスを制御するドライバ１２４と、ジョブを実行するためＯＳ１２３により生成されるプロセス１２１などとで構成されている。」
　
（１−５）
「【００１８】ＯＳ１２３により生成されたプロセス１２１は、与えられた処理を実行するため、ドライバ１２４を介して入出力装置１２６などをアクセスする。このとき、装置エラーが発生すると、ドライバ１２４内のエラー処理部１２５が実行される。そして、エラー処理部１２５は、入出力装置１２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をシステムＢ１３の疑似装置制御部１３９に通知する。
【００１９】そして、疑似装置制御部１３９は、通知されたエラー詳細情報をシステムＢ１３におけるエラー情報の形式に変換し、かつシステムＢ１３の通常装置と同じインタフェースで装置エラーの通知およびエラー詳細情報をＯＳ１３３内の通知／ログ処理部１３８に通知する。
【００２０】そして、通知／ログ処理部１３８は、通知されたエラー詳細情報をわかりやすい形式に編集し、装置エラーが発生したことをオペレータに通知するためコンソール１３２に装置エラー発生の通知およびエラー詳細情報を表示し、また装置エラーが発生したことを記録するためロギング装置１３７にエラー詳細情報などを記録する。
【００２１】このような処理により、システムＡ１２で発生した装置エラーはシステムＢ１３のコンソール１３２へ通知され、またそのエラー情報およびエラー情報ログはシステムB１３のロギング装置１３７に記録されることになる。」
　
（１−６）
「【００２９】次に、疑似装置制御部の動作を説明する。
【００３０】ステップＳ２１１：他システムからの装置エラーの発生を待ち合わせる。
【００３１】ステップＳ２１２：通知された装置エラーの詳細情報を取得する。つまり、ステップＳ２０４で保存された詳細情報が読み出される。
【００３２】ステップＳ２１３：装置エラーの詳細情報をＯＳ１３３の形式に変換する。
【００３３】ステップＳ２１４：装置エラーの発生を通知／ログ処理部に通知する。
【００３４】ステップＳ２１５：装置エラーの詳細情報を通知／ログ処理部に通知する。そして、処理を終了する。」
　
（１−７）
「【００３６】同一ハードウェア上で複数の異なるオペレーティングシステムを同時稼動するマルチオペレーティングシステムにおいて、装置エラーのエラー情報やエラー情報ログが特定のオペレーティングシステムで統一的に確認することが可能となる。また、エラー情報ログの内容が統一化され、装置保守情報の取得が容易となり、装置管理を大幅に簡素化することが可能となる。」
　
３の２．引用発明の認定
　上記（１−１）に「マルチオペレーティングシステム３１はシステムＡ３２と、システムＢ３３とで構成されている。」と記載され、上記（１−４）に「マルチオペレーティングシステム１１はシステムＡ１２と、システムＢ１３とで構成されている。」と記載されていることから、マルチオペレーティングシステムが複数のシステムに分割されていると認められる。
　
　上記（１−１）に「システムＡ３２とシステムＢ３３は、それぞれ独立したシステムであり、それぞれのシステムにはシステム全体を制御するＯＳ３２３、３３３と、…（中略）…とで構成されている。」と記載され、上記（１−４）に「システムＢ１３は、…（中略）…システム全体を制御するＯＳ１３３と、…（中略）…とで構成されている。」と記載され、上記（１−４）に「システムＡ１２は、…（中略）…システム全体を制御するＯＳ１２３と、…（中略）…とで構成されている。」と記載されていることから、各システムには、１つのオペレーティングシステム（ＯＳ）が割り当てられて稼働するものと認められる。
　また、上記（１−１）に「エラー処理部３２５は、入出力装置３２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をＯＳ３２３内の通知／ログ処理部３２８に通知する。…（中略）…通知／ログ処理部３２８は、通知されたエラー詳細情報をわかりやすい形式に編集し」と記載され、上記（１−２）に「エラー情報およびエラー情報ログの編集形式がシステム毎に異なる」と記載され、上記（１−３）に「同一ハードウェア上で複数の異なるオペレーティングシステムを同時稼動させるマルチオペレーティングシステムにおいて、エラー情報およびエラー情報ログを集約する特定のオペレーティングシステムに、前記の特定のオペレーティングシステムと異なるオペレーティングシステムから装置エラーの通知を受け、特定のオペレーティングシステムのエラー情報の形式に変換し、」と記載され、上記（１−６）に「装置エラーの詳細情報をＯＳ１３３の形式に変換する。」と記載されていることから、各システムに割り当てられて稼働しているオペレーティングシステム（ＯＳ）は互いに異なるものであると認められるので、システムには、複数のオペレーティングシステム（ＯＳ）のうちの互いに異なる１つのオペレーティングシステム（ＯＳ）がそれぞれ割り当てられて稼働するものと認められる。
　
　上記（１−１）に「ＯＳ３２３により生成されたプロセス３２１は、与えられた処理を実行するため、ドライバ３２４を介して入出力装置３２６などをアクセスする。このとき、装置エラーが発生すると、ドライバ３２４内のエラー処理部３２５が実行される。そして、エラー処理部３２５は、入出力装置３２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をＯＳ３２３内の通知／ログ処理部３２８に通知する。」と記載され、上記（１−４）に「システムＡ１２は、システムに接続された入出力装置で発生するエラー情報およびエラー情報ログをシステムＢ１３に通知するシステムであり、」と記載され、上記（１−５）に「ＯＳ１２３により生成されたプロセス１２１は、与えられた処理を実行するため、ドライバ１２４を介して入出力装置１２６などをアクセスする。このとき、装置エラーが発生すると、ドライバ１２４内のエラー処理部１２５が実行される。そして、エラー処理部１２５は、入出力装置１２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をシステムＢ１３の疑似装置制御部１３９に通知する。」と記載されていることから、マルチオペレーティングシステム内で発生する入出力装置のエラーを報告するための方法に関するものであると認められ、複数のシステムのうちの１つのシステムにおいて、システムの中で発生する入出力装置のエラーを検出させるものであると認められる。
　
　上記（１−３）に「同一ハードウェア上で複数の異なるオペレーティングシステムを同時稼動させるマルチオペレーティングシステムにおいて、エラー情報およびエラー情報ログを集約する特定のオペレーティングシステムに、前記の特定のオペレーティングシステムと異なるオペレーティングシステムから装置エラーの通知を受け、特定のオペレーティングシステムのエラー情報の形式に変換し、特定のオペレーティングシステムの通常装置と同じインタフェースで装置エラーの通知を行う疑似装置制御部を設け、かつ、前記の特定のオペレーティングシステムと異なるオペレーティングシステムに、装置エラーの発生時、装置エラーの発生とエラー情報を疑似装置制御部に通知するエラー処理部を設け、マルチオペレーティングシステムで発生する全ての装置エラーのエラー情報およびエラー情報ログを特定のオペレーティングシステムに集約する」と記載され、上記（１−４）に「システムＢ１３は、マルチオペレーティングシステムに接続された全ての装置で発生するエラー情報およびエラー情報ログを集約するシステムであり、…（中略）…他のオペレーティングシステムから装置エラーの通知を受け、システムＢ１３のエラー情報の形式に変換し、システムＢ１３に接続されている通常装置と同じインタフェースで装置エラーの通知およびエラー詳細情報をＯＳ１３３内の通知／ログ処理部１３８に通知する疑似装置制御部１３９とで構成されている。」と記載され、上記（１−５）に「エラー処理部１２５は、入出力装置１２６からエラー詳細情報を読み出し、かつ読み出したエラー詳細情報をシステムＢ１３の疑似装置制御部１３９に通知する。…（中略）…疑似装置制御部１３９は、通知されたエラー詳細情報をシステムＢ１３におけるエラー情報の形式に変換し、かつシステムＢ１３の通常装置と同じインタフェースで装置エラーの通知およびエラー詳細情報をＯＳ１３３内の通知／ログ処理部１３８に通知する。」と記載され、上記（１−６）に「ステップＳ２１２：通知された装置エラーの詳細情報を取得する。…（中略）…ステップＳ２１３：装置エラーの詳細情報をＯＳ１３３の形式に変換する。」と記載されていることから、入出力装置のエラーについての情報を含むエラー詳細情報を、１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、エラー情報およびエラー情報ログを集約する他のシステムの形式に変換させるものと認められる。
　
　また、上記で指摘したように、引用例１には、マルチオペレーティングシステム内で発生する入出力装置のエラーを報告するための方法が記載されていると認められ、また、入出力装置のエラーについての情報を含むエラー詳細情報を、１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、エラー情報およびエラー情報ログを集約する他のシステムの形式に変換させるステップが記載されているものと認められるのであるから、当該変換させるステップは、入出力装置のエラーを報告するための、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーについての情報を含むエラー詳細情報を、フォーマット化させるステップであると認められる。
　さらに、入出力装置のエラーを報告するための、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーについての情報を含むエラー詳細情報を、フォーマット化させる際において、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーを報告するために、入出力装置のエラーについての情報を含むエラー詳細情報の中にエラーに関する情報を配置させることは自明である。
　
　また、上記で指摘したように、引用例１には、入出力装置のエラーについての情報を含むエラー詳細情報を、１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、エラー情報およびエラー情報ログを集約する他のシステムの形式に変換させるステップが記載されていると認められ、かつ、前記変換させるステップが、入出力装置のエラーを報告するための、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーについての情報を含むエラー詳細情報をフォーマット化させるステップであると認められる一方で、エラー情報およびエラー情報ログを集約する他のシステムの形式は、入出力装置のエラーが検出されたシステムにかかわらず定まるものであるから、引用例１においては、入出力装置のエラーについての情報を含むエラー詳細情報について、各々のシステムに複数のオペレーティングシステム（ＯＳ）のうちのどの１つが割り当てられているかにかかわらず、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいてフォーマット化を行うものであると認められる。
　
　上記引用例１の記載事項及び図面を総合勘案すると、引用例１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
「マルチオペレーティングシステムであって、当該マルチオペレーティングシステムが複数のシステムに分割され、当該システムには、複数のオペレーティングシステム（ＯＳ）のうちの互いに異なる１つのオペレーティングシステム（ＯＳ）がそれぞれ割り当てられて稼働するマルチオペレーティングシステムにおいて、当該マルチオペレーティングシステム内で発生する入出力装置のエラーを報告するための方法であって、
　複数のシステムのうちの１つのシステムにおいて、システムの中で発生する入出力装置のエラーを検出させるステップと、
　入出力装置のエラーについての情報を含むエラー詳細情報を、１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、エラー情報およびエラー情報ログを集約する他のシステムの形式に変換させるステップとを有し、
　前記変換させるステップが、入出力装置のエラーを報告するための、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーについての情報を含むエラー詳細情報をフォーマット化させるステップであって、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーを報告するために、入出力装置のエラーについての情報を含むエラー詳細情報の中にエラーに関する情報を配置させ、さらに、各々のシステムに複数のオペレーティングシステム（ＯＳ）のうちのどの１つが割り当てられているかにかかわらず、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいてフォーマット化を行う方法。」
　
３の３．引用例２に記載されている技術的事項
　当審が拒絶理由通知において引用した国際公開第００／７０４４９号（２０００年１１月２３日国際公開。以下、「引用例２」という。）には、図面とともに以下の技術的事項が記載されている。（なお、仮訳は、引用例２のパテントファミリである特表２００２−５４４６２０号を参考としたものである。）
　
（２の１）
「One significant advance in computer technology is the development of multi-processor computers, where multiple computer processors are interfaced with one another to permit multiple operations to be performed concurrently, thus improving the overall performance of such computers. Also, a number of multi-processor computer designs rely on logical partitioning to allocate computer resources to further enhance the performance of multiple concurrent tasks.
 With logical partitioning, a single physical computer is permitted to operate essentially like multiple and independent virtual computers (referred to as logical partitions), with the various resources in the physical computer (e.g., processors, memory, input/output devices) allocated among the various logical partitions. Each logical partition executes a separate operating system, and from the perspective of users and of the software applications executing on the logical partition, operates as a fully independent computer.」
（明細書第１頁下から３行目〜第２頁第１４行目。
　仮訳：コンピュータ技術における重要な進歩の１つは、マルチプロセッサ・コンピュータの開発であり、これは複数のコンピュータ・プロセッサが互いにインタフェースして複数の操作が同時に実行されることを可能にし、それによりこうしたコンピュータの全体性能を改善する。また、多数のマルチプロセッサ・コンピュータ設計が、論理区分化に頼ることにより、コンピュータ資源を割当てており、それにより複数同時タスクの性能を更に向上させる。
　論理区分化により、単一の物理コンピュータが本質的に、複数の独立した仮想コンピュータ（論理区画と称される）のように動作することを可能にされ、物理コンピュータ内の様々な資源（例えばプロセッサ、メモリ、入出力装置）が、様々な論理区画の間で割当てられる。各論理区画は別々のオペレーティング・システムを実行し、ユーザから見て及び論理区画上で実行されるソフトウェア・アプリケーションから見て、完全に独立したコンピュータとして動作する。）
　
３の４．周知例１に記載されている技術的事項
　本願の優先日前に頒布された刊行物である特開２０００−１３２５３０号公報（平成１２年５月１２日出願公開。以下、「周知例１」という。）には、図面ともに以下の技術的事項が記載されている。
　
（周知１の１）
「【００１６】システムビルディングブロック
本発明のソフトウェアアーキテクチャは、多数のＣＰＵ、メモリ及びＩ／Ｏハードウェアを組み込んだハードウェアプラットホームにおいて動作する。…（中略）…図１は、４つの基本的なシステムビルディングブロック（ＳＢＢ）１００―１０６で構成されたコンピュータシステムを示す。ここに示す実施形態では、ブロック１００のような各ビルディングブロックは…（中略）…、多数のＣＰＵ１０８―１１４と、多数のメモリスロット（メモリ１２０として集合的に示されている）と、…（中略）…とを備えている。…（後略）…」
　
（周知１の２）
「【００１９】区画は、システムビルディングブロックと同意語ではないことに注意するのが重要である。例えば、区画２０２は、図１のビルディングブロック１００及び１０６のハードウェアを構成するが、区画２０４及び２０６は、各々、ビルディングブロック１０２及び１０４のハードウェアを構成してもよい。又、区画は、ビルディングブロックのハードウェアの一部分を含んでもよい。」
　
（周知１の３）
「【０１３８】図１２は、「何も共用しない」計算モデルをサポートするために本発明のシステムをいかに構成できるかを示す。この例では、３つの区画１２０６、１２１０及び１２１４が単一のマシン１２００内に形成されており、その各々はオペレーティングシステムのインスタンスを実行する。使用可能な１２個のＣＰＵは、この例では１２０６、１２１０及び１２１４と示された区画間で任意に等しく分割されている。使用可能なメモリは、プライベートメモリに分割され、そしてインスタンスに指定されている。図１２においては、プライベートメモリ部分１２１６、１２１８及び１２２０が示されている。各インスタンスのコード及びデータの両方は、そのインスタンスに指定されたプライベートメモリに記憶される。メモリ１２１６、１２１８及び１２２０は、図１２では等しく分割されて示されているが、本発明のアーキテクチャーは、インスタンス間でのメモリの任意の分割をサポートする。従って、ある区画が大きなメモリを必要としそして別の区画が限定されたメモリしか必要としない場合には、システムは、使用可能なメモリを最大限に使用するようにその両方を受け入れることができる。」
　
３の５．周知例２に記載されている技術的事項
　本願の優先日前に頒布された刊行物である特開平７−３３４４２７号公報（平成７年１２月２２日出願公開。以下、「周知例２」という。）には、図面とともに以下の技術的事項が記載されている。
　
（周知２の１）
「【０００１】
【産業上の利用分野】本発明は、情報処理装置に係り、特に情報処理装置の記憶装置を複数の記憶領域に論理的に分割して使用する機能を備える記憶装置の容量拡張方式及び容量を拡張した記憶装置のアクセス方式に関する。
【０００２】
【従来の技術】一般に、単一の情報処理装置上で複数のオペレーティングシステム（以下ＯＳという）を動作させる方法として仮想計算機（以下、ＶＭ又はＬＰＡＲという）と呼ばれる手段が用いられている。
【０００３】ＬＰＡＲを単一の情報処理装置上で実現する為に、仮想計算機制御プログラム（以下、ハイパバイザという）と呼ばれるプログラムを実情報処理装置上で動作させ、このハイパバイザの制御の下で複数のＬＰＡＲを生成し、更に、この各々のＬＰＡＲの上で独立したＯＳを動作させていた。」
　
（周知２の２）
「【０００８】…（中略）…実中央処理装置（以下、ＰＩＰという）…（中略）…実記憶装置（以下、ＲＭＳという）…（中略）…論理中央処理装置（以下、ＬＩＰという）…（中略）…論理記憶装置（以下、ＬＭＳという）…（後略）…」
　
（周知２の３）
「【００５６】図６は、本発明の一実施例である、仮想計算機が記憶装置のアクセスを伴う命令を発行し、該発行された命令の命令語を構成している複数のフィールドから読み出されたデータを基に仮想アドレスを生成し、前記仮想アドレスからアドレス変換過程を経て記憶装置アドレスを作成し、該記憶装置アドレスから浮動アドレスレジスタを用いて、記憶装置を構成している複数の記憶モジュールから１つの記憶モジュールを選択し、記憶データをアクセスする記憶モジュールを選択するハードウェアの詳細を示すブロック図である。」
　
（周知２の４）
「【００９４】以下にその複数の記憶モジュールから１つの記憶モジュールを選択する手順の詳細を図６，図７，図８及び図９を用いて詳細に説明する。
【００９５】図８及び図９に於いて、命令語のベースフィールドで指定された番号から領域ＩＤレジスタを用いて、記憶装置アクセスに伴う領域ＩＤを選択する手順は、ステップ７０１からステップ７１１迄で構成され、前記の記憶装置アドレスから浮動アドレスレジスタを用いて、記憶装置を構成している複数の記憶モジュールから１つの記憶モジュールを選択し、記憶データをアクセスする手順は、ステップ８０１からステップ８１１迄で構成される。以下、各ステップ毎に変換処理手順を説明する。
【００９６】ステップ７０１  ：  仮想計算機（ＬＰＡＲ）から記憶装置アクセスを伴う命令が発行される。尚、本例では、命令形式がＲＸ形式の例を示す。
【００９７】この時、該ＬＰＡＲが必要とする記憶領域は、ＲＭＳの記憶領域に既に分割され割り当てられている。即ち、それぞれのＬＰＡＲに対応する領域ＩＤは、該ＬＰＡＲが必要とする記憶領域をＲＭＳの記憶領域に対応付けて、対応する領域ＩＤレジスタアレイ５５０を構成するそれぞれの領域ＩＤレジスタに設定されている。
【００９８】更に、該ＬＰＡＲに対応する領域ＩＤに対応する浮動アドレスレジスタアレイ６３０を構成するそれぞれの浮動アドレスレジスタブロック７６０のそれぞれの浮動アドレスレジスタエントリは、該ＬＰＡＲが必要とする記憶領域をＲＭＳの記憶領域に対応付けて、既に記憶モジュール番号フィールドに設定されている。
…（中略）…
【０１１２】ステップ８０１  ：  仮想計算機から発行された命令に付随した記憶装置アクセスが、ＬＩＰからＬＰＡＲに割り当てられたＬＭＳの記憶領域に対する記憶装置アクセスとして、ステップ７１０又はステップ７１１で選択された領域ＩＤの値が、その時動作しているＬＰＡＲに割り当てられている所定の領域ＩＤとして信号線６Ａ１を介してラッチＡ６１０に入力され、同時に該記憶装置アクセスとして、ステップ７０６で作成された前記ＬＰＡＲに割り当てられている連続したＬＭＳの記憶領域に対応した記憶装置アドレス（以下、ＬＭＳＡＤＲという）が、信号線６Ａ２を介してラッチＡ６１０に入力される。
【０１１３】この時、該ＬＰＡＲが必要とする記憶領域は、ＲＭＳの記憶領域に、既に分割され割り当てられている。即ち、浮動アドレスレジスタアレイ６３０内の該ＬＰＡＲの領域ＩＤに対応する浮動アドレスレジスタブロック７６０のそれぞれの浮動アドレスレジスタエントリは、該ＬＰＡＲが必要とする記憶領域をＲＭＳの記憶領域に対応付けて、既に記憶モジュール番号フィールドに設定されている。
…（中略）…
【０１１７】ステップ８０４  ：  セレクタ６２０は、信号線６Ａ４を介して送られて来た所定の領域ＩＤの値を用いて、浮動アドレスレジスタアレイ６３０を構成する複数の浮動アドレスレジスタブロック７６０のうちの１つの浮動アドレスレジスタブロックを選択する指示を、ブロック選択指示信号として、信号線６Ａ６を介して浮動アドレスレジスタアレイ６３０に出す。浮動アドレスレジスタアレイ６３０は、信号線６Ａ６を介して送られて来た値を用いて、対応する１つの浮動アドレスレジスタブロックを選択する。
【０１１８】ステップ８０５  ：  セレクタ６２０は、信号線６Ａ４を介して送られて来たＬＭＳＡＤＲの値の上位部分を用いて、ステップ８０４で選択された１つの浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリから１つの浮動アドレスレジスタエントリを選択する旨の指示を、エントリ選択指示信号として信号線６Ａ６を介して浮動アドレスレジスタアレイ６３０に出す。
【０１１９】浮動アドレスレジスタアレイ６３０は、該浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリから１つの浮動アドレスレジスタエントリを選択し、該浮動アドレスレジスタエントリの内容を信号線６Ａ７を介して、ラッチＢ６４０に送出する。
…（中略）…
【０１２２】ステップ８０８  ：  このステップは、選択された浮動アドレスレジスタエントリのＶフィールドが有効の場合に実行され、ラッチＢ６４０は、信号線６Ａ７を介して送られて来た、浮動アドレスレジスタアレイ６３０の複数の浮動アドレスレジスタブロックのうちの選択された浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリの内容、即ち、記憶モジュール番号をラッチＢ６４０にラッチする。
【０１２３】ステップ８０９  ：  ステップ８０８でＢ６４０にラッチされた記憶モジュール番号を、信号線６Ａ８を介して記憶モジュール０  ６５０，記憶モジュール１６５１，記憶モジュール２  ６５２及び記憶モジュールＮ  ６５３等の複数の記憶モジュールに対し送出する。
【０１２４】ステップ８１０  ：  信号線６Ａ８を介して送られて来た記憶モジュール番号は、複数の記憶モジュール群である記憶モジュール０  ６５０，記憶モジュール１  ６５１，記憶モジュール２  ６５２及び記憶モジュールＮ  ６５３等で受け取られ、該記憶モジュール番号と同じ番号を与えられている１つの記憶モジュールのみが記憶装置アクセスを許され、記憶モジュールのみがアクセス可能状態となる。
【０１２５】ステップ８１１  ：  ステップ８１０で記憶装置アクセスを許された記憶モジュールは、ステップ８０３で信号線６Ａ５を介して送出されているラッチＡ６１０の部分ｅの出力であるＬＭＳＡＤＲの値の下位部分を、該記憶モジュールをアクセスする記憶装置アドレスとして取り込み、該記憶モジュールのアクセス動作を実行する。即ち、記憶装置からの読み出し動作要求であれば、信号線６ＡＡに該記憶モジュールから読み出されたデータを送出し、記憶装置への書き込み動作要求であれば、信号線６Ａ９に送出されているデータを該記憶モジュールに書き込む。」
　
３の６．複数の論理区画に分割される対象に関する周知技術の認定
　引用例２の上記（２の１）に「マルチプロセッサ・コンピュータ設計が、論理区分化に頼ることにより、コンピュータ資源を割当てており」と記載され、上記（２の１）に「物理コンピュータ内の様々な資源（例えばプロセッサ、メモリ、入出力装置）が、様々な論理区画の間で割当てられる。」と記載されている。
　また、周知例１の上記（周知１の１）に「図１は、４つの基本的なシステムビルディングブロック（ＳＢＢ）１００―１０６で構成されたコンピュータシステムを示す。ここに示す実施形態では、ブロック１００のような各ビルディングブロックは…（中略）…、多数のＣＰＵ１０８―１１４と、多数のメモリスロット（メモリ１２０として集合的に示されている）と、…（中略）…とを備えている。」と記載され、上記（周知１の２）に「区画は、システムビルディングブロックと同意語ではない…（中略）…。…（中略）…区画は、ビルディングブロックのハードウェアの一部分を含んでもよい。」と記載され、上記（周知１の３）に「この例では、３つの区画１２０６、１２１０及び１２１４が単一のマシン１２００内に形成されており、その各々はオペレーティングシステムのインスタンスを実行する。使用可能な１２個のＣＰＵは、この例では１２０６、１２１０及び１２１４と示された区画間で任意に等しく分割されている。使用可能なメモリは、プライベートメモリに分割され、そしてインスタンスに指定されている。図１２においては、プライベートメモリ部分１２１６、１２１８及び１２２０が示されている。…（中略）…メモリ１２１６、１２１８及び１２２０は、図１２では等しく分割されて示されているが、本発明のアーキテクチャーは、インスタンス間でのメモリの任意の分割をサポートする。従って、ある区画が大きなメモリを必要としそして別の区画が限定されたメモリしか必要としない場合には、システムは、使用可能なメモリを最大限に使用するようにその両方を受け入れることができる。」と記載されている。
　上記した引用例２及び周知例１に例示されるような、複数のプロセッサとメモリとを含むリソースを有するコンピュータ・システムを複数の論理区画に分割するに際して、各論理区画にプロセッサやメモリのリソースを適宜割り当てること（以下、「周知技術１」という。）は、当業者には周知である。
　
　周知例１の上記（周知１の１）に「図１は、４つの基本的なシステムビルディングブロック（ＳＢＢ）１００―１０６で構成されたコンピュータシステムを示す。ここに示す実施形態では、ブロック１００のような各ビルディングブロックは…（中略）…、多数のＣＰＵ１０８―１１４と、多数のメモリスロット（メモリ１２０として集合的に示されている）と、…（中略）…とを備えている。」と記載されている。上記（周知１の１）に示されるように、周知例１の「コンピュータシステム」には複数（周知例１の図１では４つ）のメモリ１２０が含まれ、各メモリ１２０には多数のメモリスロットが含まれるので、当該「コンピュータシステム」には複数のメモリ・ユニットが含まれるものといえる。
　また、周知例２の上記（周知２の３）に「仮想計算機が記憶装置のアクセスを伴う命令を発行し、…（中略）…記憶装置アドレスを作成し、該記憶装置アドレスから浮動アドレスレジスタを用いて、記憶装置を構成している複数の記憶モジュールから１つの記憶モジュールを選択し、記憶データをアクセスする記憶モジュールを選択する」と記載され、上記（周知２の４）に「該ＬＰＡＲが必要とする記憶領域は、ＲＭＳの記憶領域に既に分割され割り当てられている。即ち、それぞれのＬＰＡＲに対応する領域ＩＤは、該ＬＰＡＲが必要とする記憶領域をＲＭＳの記憶領域に対応付けて、対応する領域ＩＤレジスタアレイ５５０を構成するそれぞれの領域ＩＤレジスタに設定されている。…（中略）…更に、該ＬＰＡＲに対応する領域ＩＤに対応する浮動アドレスレジスタアレイ６３０を構成するそれぞれの浮動アドレスレジスタブロック７６０のそれぞれの浮動アドレスレジスタエントリは、該ＬＰＡＲが必要とする記憶領域をＲＭＳの記憶領域に対応付けて、既に記憶モジュール番号フィールドに設定されている。」と記載され、上記（周知２の４）に「仮想計算機から発行された命令に付随した記憶装置アクセスが、ＬＩＰからＬＰＡＲに割り当てられたＬＭＳの記憶領域に対する記憶装置アクセスとして、ステップ７１０又はステップ７１１で選択された領域ＩＤの値が、その時動作しているＬＰＡＲに割り当てられている所定の領域ＩＤとして信号線６Ａ１を介してラッチＡ６１０に入力され、同時に該記憶装置アクセスとして、ステップ７０６で作成された前記ＬＰＡＲに割り当てられている連続したＬＭＳの記憶領域に対応した記憶装置アドレス（以下、ＬＭＳＡＤＲという）が、信号線６Ａ２を介してラッチＡ６１０に入力される。」と記載され、上記（周知２の４）に「セレクタ６２０は、信号線６Ａ４を介して送られて来た所定の領域ＩＤの値を用いて、浮動アドレスレジスタアレイ６３０を構成する複数の浮動アドレスレジスタブロック７６０のうちの１つの浮動アドレスレジスタブロックを選択する指示を、ブロック選択指示信号として、信号線６Ａ６を介して浮動アドレスレジスタアレイ６３０に出す。浮動アドレスレジスタアレイ６３０は、信号線６Ａ６を介して送られて来た値を用いて、対応する１つの浮動アドレスレジスタブロックを選択する。…（中略）…セレクタ６２０は、信号線６Ａ４を介して送られて来たＬＭＳＡＤＲの値の上位部分を用いて、ステップ８０４で選択された１つの浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリから１つの浮動アドレスレジスタエントリを選択する旨の指示を、エントリ選択指示信号として信号線６Ａ６を介して浮動アドレスレジスタアレイ６３０に出す。…（中略）…浮動アドレスレジスタアレイ６３０は、該浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリから１つの浮動アドレスレジスタエントリを選択し、該浮動アドレスレジスタエントリの内容を信号線６Ａ７を介して、ラッチＢ６４０に送出する。」と記載され、上記（周知２の４）に「信号線６Ａ７を介して送られて来た、浮動アドレスレジスタアレイ６３０の複数の浮動アドレスレジスタブロックのうちの選択された浮動アドレスレジスタブロック内の複数の浮動アドレスレジスタエントリの内容、即ち、記憶モジュール番号をラッチＢ６４０にラッチする。…（中略）…ステップ８０８でＢ６４０にラッチされた記憶モジュール番号を、信号線６Ａ８を介して記憶モジュール０  ６５０，記憶モジュール１６５１，記憶モジュール２  ６５２及び記憶モジュールＮ  ６５３等の複数の記憶モジュールに対し送出する。…（中略）…信号線６Ａ８を介して送られて来た記憶モジュール番号は、複数の記憶モジュール群である記憶モジュール０  ６５０，記憶モジュール１  ６５１，記憶モジュール２  ６５２及び記憶モジュールＮ  ６５３等で受け取られ、該記憶モジュール番号と同じ番号を与えられている１つの記憶モジュールのみが記憶装置アクセスを許され、記憶モジュールのみがアクセス可能状態となる。…（中略）…ステップ８１０で記憶装置アクセスを許された記憶モジュールは、ステップ８０３で信号線６Ａ５を介して送出されているラッチＡ６１０の部分ｅの出力であるＬＭＳＡＤＲの値の下位部分を、該記憶モジュールをアクセスする記憶装置アドレスとして取り込み、該記憶モジュールのアクセス動作を実行する。即ち、記憶装置からの読み出し動作要求であれば、信号線６ＡＡに該記憶モジュールから読み出されたデータを送出し、記憶装置への書き込み動動作要求であれば、信号線６Ａ９に送出されているデータを該記憶モジュールに書き込む。」と記載されている。周知例２の上記で指摘した箇所で示されるように、周知例２においては複数の記憶モジュールが備えられているから、複数のメモリ・ユニットが備えられているといえる。なお、周知例２の上記で指摘した箇所で示されるように、周知例２の仮想計算機（ＬＰＡＲ）（上記（周知２の１）に「情報処理装置の記憶装置を複数の記憶領域に論理的に分割して使用する…（中略）…。…（中略）…一般に、単一の情報処理装置上で複数のオペレーティングシステム（以下ＯＳという）を動作させる方法として仮想計算機（以下、ＶＭ又はＬＰＡＲという）と呼ばれる手段が用いられている。…（中略）…ＬＰＡＲを単一の情報処理装置上で実現する為に、…（中略）…複数のＬＰＡＲを生成し、更に、この各々のＬＰＡＲの上で独立したＯＳを動作させていた。」と記載されていることから明らかなように、周知例２の仮想計算機（ＬＰＡＲ）と本願発明の「論理区画」は、ハードウエアリソースを論理的に分割して、分割した個々のリソースにて１つのオペレーティングシステムを稼働させるものである点で同様のものである。）にいずれの記憶モジュール（メモリ・ユニット）を割り当てるかを指定している。
　上記した周知例１及び周知例２に例示されるような、コンピュータ・システムのメモリを複数のメモリ・ユニットから構成すること（以下、「周知技術２」という。）は、当業者には周知である。
　
３の７．引用例３に記載されている技術的事項
　当審が拒絶理由通知において引用した特開平４−２５７０３５号公報（平成４年９月１１日出願公開。以下、「引用例３」という。）には、図面とともに以下の技術的事項が記載されている。なお、引用例３には丸印のなかに数字が記されている記号が多々記載されているが、以下では、これらの記号を”○ｘ”（ｘは自然数）で表記することにする。
　
（３の１）
「【０００２】該仮想計算機システムにおいては、ホストシステムのオペレーティングシステム（ＯＳ）の配下で、複数個のゲスト仮想計算機（以下、ゲストＶＭという）が、それぞれのオペレーティングシステム（ＯＳ）の配下で、恰も、独立した計算機のように動作しており、該ゲストＶＭの配下で動作する周辺装置に障害が発生すると、該周辺装置に割り当てられている仮想機番で、障害情報が、それぞれ、独立したロギングファイルに記録される。」
　
（３の２）
「【００２１】次に、本発明の他の障害情報処理方式の作用動作について説明する。この方式は、該仮想計算機システムを構成している複数個のゲストＶＭ配下のオペレーティングシステムが検出したロギング情報”○２”，及び、ホストシステムが検出しているロギング情報”○１”を、該複数個のゲストＶＭの内の特定のゲストＶＭが、サーバＶＭとなって、一括収集，管理して、各仮想機番対応の障害情報を実装置機番対応の障害情報に編集して出力装置に出力するものである。
【００２２】具体的には、該サーバＶＭからの要求により、各ゲストＶＭの一括収集プログラムが自己のシステムエラーロギングファイル”○２”から障害情報を読み出し、システム共通のデータ形式に変換して、一時ファイルに格納した後、交信データ形式に変換して、上記サーバＶＭ（サーバシステム）に転送する。
【００２３】該サーバＶＭに転送されてきた各障害情報は、前もって、ホストシステムから転送されている上記ＶＭ固有情報に基づいて生成されている、上記装置管理テーブル”○８”が参照され、該障害情報中の仮想機番を実機番に置換して、例えば、累積ファイルに格納する。
【００２４】該累積ファイルに格納された障害情報は、該サーバシステムが実行するログ編集プログラムによって、例えば、装置機番，エラー事象，エラー発生日付け情報の形式に編集された後、分析編集リストとして、保守センタ等に転送され出力される。」
　
（３の３）
「【００２８】…（中略）…仮想計算機システムが稼働中に、磁気ディスク装置などの周辺装置が一時的，又は、永久的な障害が発生した時点で、各ゲストＶＭ　２配下のオペレーティングシステム（ＯＳ）が検出したロギング情報”○２”，…（後略）…」
　
（３の４）
「【００３５】（５）周辺装置の新たな障害情報，又は、統計情報（消耗品情報や、ＤＡＳＤなどでは、シークカウント情報，　リードデータバイト数情報）などをＯＳが検出すると、上記システムエラーロギングファイル”○２”に書き込む…（後略）…」
　
（３の５）
「【００４２】次に、図６〜図８によって、本発明の他の実施例について説明する。本実施例では、例えば、仮想計算機システムの配下で、３つのゲストＶＭ（システム）２が稼働しているものとする。
【００４３】先ず、ホストシステム（仮想計算機システムを意味する）１は、稼働中のシステム数（ゲストＶＭ数），システム名の情報，およびシステムに組み込まれている装置（周辺装置）の実機番と，各システムで固有に定義されている論理機番（仮想機番）の対応情報を稼働システム管理情報”○５”として作成し管理している。
【００４４】該ホストシステムでは、常に、該稼働システム管理情報”○５”を監視しており、情報の追加，変更等がある毎に、装置管理テーブル｛図７（ｂ）参照｝”○８”を作成する。
【００４５】該作成された装置管理テーブル”○８”は、ホストシステム１のエラー情報格納ファイル　（ホストログ）”○１”に管理情報として記録され、上記稼働システム管理情報と一緒に、ログ情報累積時の参照情報として使用される。
【００４６】各ゲストＶＭ２が稼働中に、配下の各装置でハードウェアエラーが発生すると、該装置が接続されているゲストＶＭでエラー情報が作成され、システムエラーロギングファイル（ＬＯＧＲＥＣ）”○２”に格納される。
【００４７】本発明の場合、各ゲストＶＭ２内に、ログ一括収集プログラム２２が用意されており、あるゲストＶＭ２がサーバＶＭとして立候補して、ホストシステム１に認識されると、該ゲストＶＭ２がサーバＶＭ（サーバシステム）２ａとなり、上記ログ一括収集プログラム２２が起動される。｛図８（ｃ）の処理ステップ２００参照｝該サーバＶＭ２ａのログ一括収集プログラム２２　が起動されると、図６（ａ）に示したように、該サーバＶＭ２ａと各ゲストＶＭ２間のデータ通信路を確立し、現在稼働中の各ゲストＶＭ２内のログ一括収集プログラム２２を起動する。｛図８　（ｃ）の処理ステップ２０１〜２０３参照｝該サーバＶＭ２ａにより起動された各ゲストＶＭ２のログ一括収集プログラム２２は、自己のシステムエラーロギングファイル（ＬＯＧＲＥＣ）”○２”内のデータを、各システムに共通なデータ形式に変換して、一時ファイルに格納する。
【００４８】その後、該各一時ファイルに格納されているデータを交信データの形式に変換して、上記サーバＶＭ２ａに、上記データ通信路を介してデータ転送を行う。｛図８（ｃ）の処理ステップ２０８〜２１０，２０６参照｝一方、サーバＶＭ２ａのログ一括収集プログラム２２は、自己のシステムエラーロギングファイル（ＬＯＧＲＥＣ）”○２”内のデータ，及び、ホストシステム１のエラー情報格納ファイル（ホストログ）”○１”内のデータを転送する。｛図８（ｃ）の処理ステップ２０４，２０５参照｝該サーバＶＭ２ａの上記ログ一括収集プログラム２２に転送されたデータは、ホストシステム１から受信している稼働システム管理情報”○５”，及び、装置管理テーブル”○８”を参照して、各ゲストＶＭ２のエラー情報中の装置機番情報（論理機番）を実機番に置換し、累積ファイルに格納する。｛図８（ｃ）の処理ステップ　２０７参照）該累積ファイルに格納されたデータは、該サーバＶＭ２ａに用意されているログ編集プログラム２３によって分析編集される。
【００４９】このとき、図３（ｂ２）に示されている如くに、例えば、実装置機番，エラー種別，発生日付の形式の分析編集リストとして出力され、保守センタ３等に転送される。
【００５０】該保守センタ３の保守技術員（ＣＥ）は、該出力された分析編集リストにより、ハードウェアの稼働状況，及び、障害状況を実機番で的確に把握し、保守作業を行うことができる。」
　
３の８．エラー検出を実現する手段に関する周知技術の認定
　引用例３の上記（３の１）に「該ゲストＶＭの配下で動作する周辺装置に障害が発生すると、該周辺装置に割り当てられている仮想機番で、障害情報が、それぞれ、独立したロギングファイルに記録される。」と記載され、上記（３の２）に「ゲストＶＭ配下のオペレーティングシステムが検出したロギング情報”○２”」と記載され、上記（３の３）に「仮想計算機システムが稼働中に、磁気ディスク装置などの周辺装置が一時的，又は、永久的な障害が発生した時点で、各ゲストＶＭ　２配下のオペレーティングシステム（ＯＳ）が検出したロギング情報”○２”」と記載され、上記（３の４）に「周辺装置の新たな障害情報…（中略）…をＯＳが検出すると、上記システムエラーロギングファイル”○２”に書き込む」と記載されている。これらの記載に例示されるような、周辺装置（周辺装置には当然入出力装置もその範疇として含まれるものである。）等のエラー検出を実現するためにオペレーティングシステムを関与させることは当業者には周知である。
　また、１つの論理区画（または仮想計算機）にて稼働するオペレーティングシステムたるプログラムを、プロセッサが読み込んで実行することも当業者には当然のことである。
　これらのことを考慮すれば、オペレーティングシステムがプロセッサに、周辺装置（周辺装置には当然入出力装置もその範疇として含まれるものである。）等のエラーを検出させること（以下、「周知技術３」という。）は、当業者にとって周知なことである。
　　
３の９．引用例４に記載されている技術的事項
　当審が拒絶理由通知において引用した特開平６−２３６３３７号公報（平成６年８月２３日出願公開。以下、「引用例４」という。）には、図面とともに以下の技術的事項が記載されている。
　
（４−１）
「【０００６】一方、各サブシステムの使用する業務資源は、サブシステム内に設置されたホストコンピュータによって管理され、その管理情報はこのホストコンピュータ内に存在し、且つホストコンピュータのコンソール装置に表示される。この表示情報を、特開平１−１１６８４２で開示の「障害自動通報方式」などを使用して、各サブシステムにとって遠隔地にある管理・保守センタへ通知し、管理・保守センタに設置した表示装置に表示することも可能である。この方法を採用した場合には、管理・保守センタにおいて表示された各サブシステムの管理情報は、送信元であるサブシステム固有の形式を有しており、管理・保守要員は各サブシステムごとに異なった情報解析法によって管理情報を処理する。
【０００７】
【発明が解決しようとする課題】従来、コンピュータ・ネットワーク・システムの管理・保守は、以上のような方法で実施され、システム管理・保守要員の駐在しているシステム管理・保守センタのシステム状態表示部には夫々のサブシステムから送られてきたサブシステム固有の形式に構成された管理情報を、選別せずに或いはサブシステム固有の形式で表示していたので、保守要員による障害の発見は、表示された管理情報を送信したサブシステムを同定後表示されたメッセージに対してサブシステム固有の解読をして、障害等の種類、障害等の発生部位などを、障害を目視で読み取り障害を識別するという方法であるので、障害の監視には熟練した管理・保守要員が不可欠であり、また経験の少ない管理・保守要員では要素が複雑に組合わさった障害には対処できないこともあるので、常に経験の豊富な管理・保守要員を待機させなければならない問題があった。」
　
（４−２）
「【００１７】
【作用】本発明の方法によれば、夫々の業務サブシステムのホストコンピュータが管理している資源に関する業務の実行にあたって検出した管理情報は、システム管理サブシステムへネットワーク経由で通知される。この夫々の管理情報は、システム管理サブシステムのホストコンピュータによって、総合的な処理が施され各業務サブシステム間で整合のとれた、管理・保守要員にとって解読・解析が容易化された形式で表示される。この方法において、各業務コンピュータ・サブシステムが検出した管理情報をシステム全体として取り決めた管理情報形式（統合管理情報形式）に変換してシステム管理サブシステムへ通知する方式を採用すれば、システム管理サブシステムのホストコンピュータに実装する処理は統合化可能であり、業務サブシステムの増設にあたっても対処が容易化される。」
　
（４−３）
「【００２５】図３は、システム管理サブシステム１００とその管理対象の１系列である業務コピュータ・サブシステム２００の系列との論理的な接続の詳細構成図である。システム管理サブシステム１００と業務コンピュータ・サブシステム３００との論理的な接続も同様にして実現される。
【００２６】システム管理コンピュータ・サブシステム１００のハードウエア、応用プログラム群は、このサブシステムの基本ソフトウエアであるオペレーティングシステム（ＯＳ）１５０によって管理される。このＯＳ１５０の管理下にある応用プログラムの１つであるシステム管理プログラム１６０が、システム全体の管理をするための情報を、全業務サブシステムに共通の形式でシステムの管理・保守要員に提供する。
【００２７】このシステム管理プログラム１６０は、受動システム管理プログラム１７０と能動システム管理プログラム１８０とから構成される。受動システム管理プログラム１７０は、業務サブシステム２００から送られてくる管理情報データを受信する受信プログラム１７１と、受信プログラム１７１が受信した管理情報データを解読・解析し、他の業務サブシステムから管理情報と合わせた処理をして表示用データを生成する状態表示データ生成プログラム１７２と、生成された状態表示データを表示装置に表示する状態表示プログラム１７３と、から構成される。能動システム管理プログラム１８０は、検査要求を検出する検査要求検出プログラム１８１と、検査要求から業務サブシステム２００へ通知する検査指示データを生成する検査指示データ生成プログラムと１８２、検査指示データを業務サブシステム２００へ送信する検査指示送信プログラムと、から構成される。
【００２８】業務コンピュータ・サブシステム２００のハードウエア、応用プログラム群および業務実行にあたって使用するネットワーク接続された端末装置群は、このサブシステムの基本ソフトウエアであるオペレーティングシステム（ＯＳ）２５０によって管理される。このＯＳ２５０による資源管理の結果として発生する管理情報を、応用プログラムの１つである管理情報通知プログラム２６０がハードウエアおよび基本ソフトウエアの機能を利用して、業務コンピュータ・サブシステム２００の系列の資源管理を司るシステム管理コンピュータ・サブシステム１００へ提供する。
【００２９】この管理情報通知プログラム２６０は、受動的な管理情報通知プログラム２７０と能動的な管理情報通知プログラム２８０とから構成される。受動的な管理情報通知プログラム２７０は、通常の業務実行に発生する管理情報を検出する検出プログラム２７１と、検出した管理情報を取捨選択してシステム管理サブシステムへ通知する管理情報を決定後、この管理情報のデータ形式をシステム全体として取り決めた統一管理情報形式に変換する形式変換プログラム２７２と、統一管理情報形式を有する管理情報をシステム管理サブシステム１００へ送信する管理情報送信プログラム２７３と、から構成される。能動的な管理情報通知プログラム２８０は、システム管理サブシステム１００から送られてくる検査指示データを受信する受信プログラム２８１と、受信プログラム２８１が受信した検査指示データを解読・解析し、模擬的な業務実行を指示して、この模擬的な業務実行の結果として発生する管理情報を収集後、検出した管理情報を取捨選択してシステム管理サブシステムへ通知する管理情報を決定し、この管理情報のデータ形式をシステム全体として取り決めた統一管理情報形式に変換する検査プログラム２８２と、検査プログラムによって生成された統一管理情報形式を有する管理情報をシステム管理サブシステム１００へ送信する管理情報送信プログラム２８３と、から構成される。
【００３０】まず、受動的に検出した管理情報の処理に関して説明する。業務サブシステム２００が通常のため業務プログラム２９０を実行すると、ＯＳ２５０には業務の開始／終了、障害の発生および障害の種類、障害からの復旧などの管理情報が報告される。これらの管理情報が発生すると、検出プログラム２７１は管理情報の発生を検出し、その管理情報を並行して取り込む。この取り込まれた管理情報は、形式変換プログラム２７２によって取捨選択後、統一管理情報形式に変換される。形式変換された管理情報は、管理情報送信プログラム２７３は業務サブシステム２００のネットワーク通信機能を利用して、形式変換された管理情報をシステム管理サブシステム１００へ送信する。この送信された管理情報データは、受信プログラム１７１を介してシステム管理サブシステム１００に取り込まれる。状態表示データ生成プログラム１７２は、取り込まれた管理情報データに基づいて、その時点のシステム状態を変更して新しいシステム状態に更新し、新たにシステム状態表示データを生成する。この新たなシステム状態表示データを、状態表示プログラムが表示装置（キャラクタ・ディスプレイまたはグラフィック・ディスプレイなど）に表示して、管理・保守要員に総合的なシステム管理情報を提供する。
【００３１】次に、能動的に検出する管理情報の処理に関して説明する。検査要求検出プログラム１８１が、検査要求の発生を検出し、検査内容データを取り込む。する。この検査要求の発生は、システム管理サブシステム１００内の計時機能を利用した定期的な検査要求の場合もあるし、管理・保守要員の人手による検査要求の場合もある。検査指示データ生成プログラム１８２は、取り込まれた検査内容データを処理し、業務サブシステム２００へ通知する検査指示データを生成する。この検査指示データは、検査指示送信プログラム１８３によって業務サブシステム２００へ送信される。この送信された検査指示データは、受信プログラム２８１を介して業務サブシステム２００に取り込まれる。検査プログラム２８２は、検査指示データを解読・解析して、指示された検査内容に従って模擬的な業務を業務用プログラムの使用する資源を用いて実行し、その結果として発生する管理情報を収集する。この収集された管理情報は、検査プログラム２８２によって取捨選択後、統一管理情報形式に変換される。形式変換された管理情報は、管理情報送信プログラム２８３は業務サブシステム２００のネットワーク通信機能を利用して、形式変換された管理情報をシステム管理サブシステム１００へ送信する。この送信された管理情報データは、受信プログラム１７１を介してシステム管理サブシステム１００に取り込まれる。状態表示データ生成プログラム１７２は、取り込まれた管理情報データに基づいて、その時点のシステム状態を変更して新しいシステム状態に更新し、新たにシステム状態表示データを生成する。この新たなシステム状態表示データを、状態表示プログラムが表示装置（キャラクタ・ディスプレイまたはグラフィック・ディスプレイなど）に表示して、管理・保守要員に総合的なシステム管理情報を提供する。例えば、この能動的方法を使用すれば、先の受動的方法に加えて、業務サブシステムにおける停電やハングアップなどの動作不能状態を検出・表示が可能となる。」
　
（４−４）
「【００３２】上述の形式変換プログラム２７２あるいは検査プログラム２８２で行われる業務サブシステム２００に固有な管理情報形式からシステム全体として取り決めた統一管理情報形式へのデータ形式変換は以下のようにして実行される。図４は、このデータ形式変換の説明図である。図４（ａ）は変換前の業務サブシステム２００固有の管理情報形式データの一例であり、図４（ｂ）は変換後の統一管理情報形式データの一例である。
【００３３】図４（ａ）の管理情報形式は、動作状況を示す状況コード枠と、管理情報の発生に関連するシステム資源名が記載されたシステム資源名枠と、コメント枠と、から構成される。
【００３４】図４（ｂ）の統一管理情報形式は、監視領域の種類を含むヘッダー枠と、業務サブシステムの種類枠と、管理情報に関連するシステム資源名枠と、資源状態枠と、管理情報発生日時枠と、資源状態に関するコメント枠からなる。ここで、監視領域の種類とは、通信ネットワーク監視やシステム監視やアプリケーション監視のような実質的な用途の種類を示し、例えば、アプリケーション監視の場合は、「アプリケーション」で示す。
【００３５】図４（ａ）に示すような業務システム２００固有の形式を有する管理情報を形式変換プログラム２７２あるいは検査プログラム２８２が受けとると、これらのプログラムはその形式からどのような監視領域であるのかを判断して、監視領域の種類を示す情報を統一管理情報形式の監視領域の種類枠に書き込む。次に、業務サブシステム２００を示す識別子を業務サブシステム名枠に書き込む。この識別子は業務サブシステムごとに、あらかじめシステム内でユニークに定義されている。次いで、システム資源名をシステム資源名枠に書き込む。ここで、システム資源名とは、システムを構成するうえでの構成要素を示しており、例えば受注業務プログラムであれば「ＪＵＴＹＵ」で表現する。引き続き、管理情報の状況コード枠及びコメント枠を解析することにより、その管理情報が示す状況が分析できるので、その結果を監視状況枠に書き込む。更に、業務サブシステム２００の計時機能の検出した管理情報の発生日時を日時枠に書き込む。最後に、変換前の管理情報のコメント枠に特別なものがあれば統一管理情報形式のコメント枠に書き込む。」
　
（４−５）
「【００３６】本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、実施例では業務サブシステムに管理情報の形式の変換手段を実装したが、システム管理サブシステムに実装してもよい。但し、増設にあったてのシステム管理サブシステムの改造量は、実施例の方式に比べて大きくなる。また、統一管理情報形式は、システム全体が合意として取り決めた形式であれば任意に設定できる。」
　
３の１０．エラーについての情報をシステム全体の共通の形式とすることに関する公知技術の認定
　引用例３の上記（３−２）に「各ゲストＶＭの一括収集プログラムが自己のシステムエラーロギングファイル”○２”から障害情報を読み出し、システム共通のデータ形式に変換して、一時ファイルに格納した後、交信データ形式に変換して、上記サーバＶＭ（サーバシステム）に転送する。」と記載され、上記（３−５）に「該サーバＶＭ２ａにより起動された各ゲストＶＭ２のログ一括収集プログラム２２は、自己のシステムエラーロギングファイル（ＬＯＧＲＥＣ）”○２”内のデータを、各システムに共通なデータ形式に変換して、一時ファイルに格納する。…（中略）…その後、該各一時ファイルに格納されているデータを交信データの形式に変換して、上記サーバＶＭ２ａに、上記データ通信路を介してデータ転送を行う。」と記載されていることから、引用例３には、エラーが発生したゲストＶＭにて、エラーについての情報を含む障害情報を、システム共通のデータ形式に基づいて生成し、システム共通のデータ形式の障害情報を生成した後で、当該障害情報をエラーが発生したゲストＶＭの外に通知する発明（以下、「公知技術１」という。）が記載されていると認められる。
　
　引用例４の上記（４−３）に「業務サブシステム２００が通常のため業務プログラム２９０を実行すると、ＯＳ２５０には業務の開始／終了、障害の発生および障害の種類、障害からの復旧などの管理情報が報告される。」と記載され、上記（４−３）に「業務サブシステムにおける停電やハングアップなどの動作不能状態を検出・表示が可能となる。」と記載されていることから、引用例４における業務コンピュータ・サブシステム２００で取り扱う管理情報には、少なくともエラーについての情報が含まれると認められる。
　
　引用例４の上記（４−１）に「システム管理・保守要員の駐在しているシステム管理・保守センタのシステム状態表示部には夫々のサブシステムから送られてきたサブシステム固有の形式に構成された管理情報を、選別せずに或いはサブシステム固有の形式で表示していたので、…（中略）…障害の監視には熟練した管理・保守要員が不可欠であり、…（中略）…常に経験の豊富な管理・保守要員を待機させなければならない問題があった。」と記載されていることから、業務コンピュータ・サブシステム２００の管理情報は元来は業務コンピュータ・サブシステム２００固有の形式に構成されたものであるので、業務コンピュータ・サブシステム２００固有の形式のままの管理情報を業務コンピュータ・サブシステム２００からシステム管理コンピュータ・サブシステム１００（システム管理・保守センタ）に送ると、システム管理コンピュータ・サブシステム１００（システム管理・保守センタ）において、システム全体で共通の形式ではない様々な形式の管理情報を取り扱わなければならないという問題が生じるということが示されており、この問題を解決することが課題であることが示されている。
　
　引用例４の上記（４−２）に「各業務コンピュータ・サブシステムが検出した管理情報をシステム全体として取り決めた管理情報形式（統合管理情報形式）に変換してシステム管理サブシステムへ通知する方式を採用すれば、システム管理サブシステムのホストコンピュータに実装する処理は統合化可能であり、業務サブシステムの増設にあたっても対処が容易化される。」と記載されていることから、上記の課題を解決するために、業務コンピュータ・サブシステム２００の管理情報を、システム全体として取り決めた形式（統合管理情報形式）に変換してから、システム管理コンピュータ・サブシステム１００へ通知することを意図したものと認められる。
　
　引用例４の上記（４−３）に「この取り込まれた管理情報は、形式変換プログラム２７２によって取捨選択後、統一管理情報形式に変換される。形式変換された管理情報は、管理情報送信プログラム２７３は業務サブシステム２００のネットワーク通信機能を利用して、形式変換された管理情報をシステム管理サブシステム１００へ送信する。」と記載され、上記（４−３）に「この収集された管理情報は、検査プログラム２８２によって取捨選択後、統一管理情報形式に変換される。形式変換された管理情報は、管理情報送信プログラム２８３は業務サブシステム２００のネットワーク通信機能を利用して、形式変換された管理情報をシステム管理サブシステム１００へ送信する。」と記載され、上記（４−４）に「上述の形式変換プログラム２７２あるいは検査プログラム２８２で行われる業務サブシステム２００に固有な管理情報形式からシステム全体として取り決めた統一管理情報形式へのデータ形式変換は以下のようにして実行される。」と記載されていることから、上記した意図を実現するために、業務コンピュータ・サブシステム２００内で形式変換プログラム２７２または検査プログラム２８２を実行することにより、業務コンピュータ・サブシステム２００の管理情報を業務コンピュータ・サブシステム２００固有の形式からシステム全体として取り決めた形式（統合管理情報形式）に変換して、形式の変換後の管理情報をシステム管理コンピュータ・サブシステム１００へ通知するものと認められる。　
　
　つまり、引用例４には、エラーが発生したサブシステムにて、エラーについての情報を含む管理情報を、システム全体として取り決めた形式（統合管理情報形式）に基づいて生成し、システム全体として取り決めた形式（統合管理情報形式）の管理情報を生成した後で、当該管理情報をエラーが発生したサブシステムの外に通知する発明（以下、「公知技術２」という。）が記載されていると認められる。　
　
３の１１．引用例５に記載されている技術的事項
　当審が拒絶理由通知において引用した特開平７−２３９７９３号公報（平成７年９月１２日出願公開。以下、「引用例５」という。）には、図面とともに以下の技術的事項が記載されている。
　　
（５−１）
「【００２４】
【実施例】図１は、測定機構を含むシスプレックス10の概要図である。シスプレックス10は、複数のオペレーティング・システム・イメージ20a、20b、20c、20dを持つ。見やすくするために、図１においては４つのオペレーティング・システム・イメージのみが示される。より多くのイメージを加えることができ、好ましい実施例においては32のイメージが存在する。図１における参照符号は、イメージ20aに対してのみ示される。これも簡略化のためであり、他のイメージ20b、20cおよび20dにおける対応する要素は、イメージ20aにおける要素と同じ機能を実行する。
【００２５】オペレーティング・システム・イメージ20の各々は、アプリケーション・プログラム（図示されない）あるいはアプリケーション・プログラムの一部が置かれたアドレス空間、RMFアドレス空間と呼ばれる第１の測定機構アドレス空間30および、RMFGATアドレス空間と呼ばれる第２の測定機構アドレス空間50を持つ。本発明の好ましい実施例は、２つの測定機構アドレス空間30、50を持つ。第１の測定機構アドレス空間30および第２の測定機構アドレス空間50における機能を、１つの測定機構アドレス空間に取り入れることも可能である。
【００２６】第１の測定機構アドレス空間30において、SMFデータと呼ばれる第１の複数の記憶装置内バッファ40が提供される。この記憶装置内バッファ40の機能は、以下により詳細に記述される。
【００２７】第２の測定機構アドレス空間50において、モニタIIIデータと呼ばれる第２の複数の記憶装置内バッファ60が提供される。第２の複数の記憶装置内バッファ60は、システム・データの連続した監視を可能にし一時的な性能問題を解決する、いわゆるモニタIIIレコードを記憶する。第２の複数の記憶装置内バッファ60の役割は、以下により詳細に記述される。
【００２８】第１の複数の記憶装置内バッファ40および第２の複数の記憶装置内バッファ60をメモリに記憶し、以下に説明するように、そこから他のイメージにおける測定機構アドレス空間に渡すことができる。第１のデータ・セット70は第１の測定機構アドレス空間30に接続し、第２のデータ・セット80は第２の測定機構アドレス空間50に接続する。SMFデータは、第１の記憶装置内バッファ40および第１のデータ・セット70が共に存在する場合、双方に同時に渡される。同様に、モニタIIIデータは、第２の記憶装置内バッファ60および第２のデータ・セット80が共に存在する場合、双方に同時に渡される。データ・セット70、80および記憶装置内バッファ40、60は、データ・グループとして集合的に呼ばれる。
【００２９】シスプレックス10は、第１の記憶装置内バッファ40あるいは第２の記憶装置内バッファ60のいずれかに記憶されているデータを評価するための、２つの分析プログラムを持つ。測定機構プロセッサ（RMFポスト・プロセッサ）110は、直接アクセス記憶装置70からデータを収集し、１つの記憶装置90上へマージし、必要に応じてソートする。ソートされたデータはまた、記憶装置100上に記憶される。図１において、記憶装置90および100が２つの単一記憶装置として示されているが、実際は同じ記憶装置の２つの異なる領域である。測定機構プロセッサ110は、マージされソートされたデータを使用して、シスプレックス10の性能についての情報を表示する。
【００３０】測定機構レポータ（RMFモニタIIIレポータ）120は、直接アクセス記憶装置80からデータを収集し、シスプレックス10の性能のリアルタイムの分析を可能にする。」
　
（５−２）
「【００３１】図２は、第１の複数の記憶装置内バッファ40を持つ、第１の測定機構アドレス空間30の概要図である。
【００３２】第１の複数の記憶装置内バッファ40は、長期のシステム・ワークロードおよび資源利用率の分析を可能にする、いわゆるシステム管理機構（SMF）レコードを記憶する。SMFデータ収集ルーチン32は、システムについての情報を獲得し、この情報を第１の記憶装置内バッファ40および第１のデータ・セット70に渡す。」
　
（５−３）
「【００３４】図４は、第１の複数のデータ・バッファ40に記憶されたSMFデータ・レコード310の形式の例を示す。SMFデータ・レコード310は、この場合18あるいは24バイト長であるSMFレコード・ヘッダ320および、最大32,756バイト長の情報330からなる。SMFデータ・レコード310の正確な長さは、以下に詳述されるように、SMFレコード・ヘッダ320内に示される。情報330の構成は可変であり、SMFデータ・レコード310のユーザによって指定される。
【００３５】SMFレコード・ヘッダ320の固定的な構成は、図５に示される。SMFレコード・ヘッダ320の第１のフィールドはSMFxLENと呼ばれ、2バイト長である。これは、SMFレコード・ヘッダ320および情報330を含む、SMFデータ・レコード310全体の長さを示す。次のフィールドはSMFxSEGと呼ばれ、SMFデータが２つ以上のSMFデータ・レコード310にわたる場合、つまり記録されるデータが32,756バイト以上の長さである時使用される。SMFデータが２つ以上のSMFデータ・レコード310にわたらない場合、SMFxSEGフィールドの2バイトは共に16進のゼロにセットされる。SMFxLENおよびSMFxSEGフィールドは共に、レコード記述語（RDW）と呼ばれる4バイトのレコード記述子を形成する。
【００３６】SMFデータ・レコード310の次のフィールドは、SMFレコードが生成されたオペレーティング・システムを示すSMFxFLGである。これは、1バイト長である。例えばこのバイトが3にセットされている場合、MVS/SPバージョン4のオペレーティング・システムを示す。これが4にセットされている場合オペレーティング・システムがMVS/ESAであることを示し、5にセットされている場合オペレーティング・システムがMVS/XAであることを示す。0、1および2の値は、他の目的のために予約される。
【００３７】SMFxRTYフィールドは、1バイト長であり、0からFF（16進）の値をとることができる。これは、生成されたSMFデータ・レコード310の形式を示す。本発明の好ましい実施例において、レコード形式0から127（10進）は、IBMオペレーティング・システム・イメージが使用するように予約される。特にレコード形式70〜79はここに記述されるように、資源測定機構によって使用される。レコード形式128〜255は、アプリケーション・プログラムが自由に使用することができる。
【００３８】SMFxTMEフィールドは4バイト長であり、真夜中から経過した、SMFデータ・レコード310が生成されてからの時間を100秒単位で示す。SMFxDTEフィールドも4バイト長であり、SMFデータ・レコード310が生成された日付けを示す。
【００３９】最後にSMFxSIDフィールドは、SMFデータ・レコード310が生成された、システムあるいはオペレーティング・システム・イメージ20の識別番号を示す。
【００４０】SMFデータ・レコード310の他のバージョンにおいて、SMFレコードが生成されたサブシステムのサブシステム識別名（SMFxSSI−4バイト長）および、レコードのサブ形式（SMFxSTY）を記録するフィールドがさらに提供される。これは、24バイト長のSMFレコード・ヘッダ320において与えられる。
【００４１】すべてのフィールドが４番目の位置に小さいxを持つことが観察される。xの値は、SMFレコードの形式を示す。xは、0から255の値をとることができる。本発明の好ましい実施例において、xは70から79の値を持つ。」
　
３の１２．レコード内にオペレーティング・システムを識別するためのフィールドを備えることに関する公知技術の認定
　引用例５の上記（５−１）に「オペレーティング・システム・イメージ20の各々は、…（中略）…RMFアドレス空間と呼ばれる第１の測定機構アドレス空間30…（中略）…を持つ。」と記載され、上記（５−１）に「第１の測定機構アドレス空間30において、SMFデータと呼ばれる第１の複数の記憶装置内バッファ40が提供される。」と記載され、上記（５−２）に「第１の複数の記憶装置内バッファ40は、長期のシステム・ワークロードおよび資源利用率の分析を可能にする、いわゆるシステム管理機構（SMF）レコードを記憶する。SMFデータ収集ルーチン32は、システムについての情報を獲得し、この情報を第１の記憶装置内バッファ40および第１のデータ・セット70に渡す。」と記載され、上記（５−１）に「測定機構プロセッサ（RMFポスト・プロセッサ）110は、直接アクセス記憶装置70からデータを収集し、１つの記憶装置90上へマージし、必要に応じてソートする。ソートされたデータはまた、記憶装置100上に記憶される。」と記載されていることから、システム管理機構（SMF）レコードは、オペレーティング・システム・イメージ20から当該オペレーティング・システム・イメージ20の外にある測定機構プロセッサ（RMFポスト・プロセッサ）110、記憶装置90、記憶装置100に通知されるものであると認められる。
　
　引用例５の上記（５−３）に「SMFデータ・レコード310の次のフィールドは、SMFレコードが生成されたオペレーティング・システムを示すSMFxFLGである。これは、1バイト長である。例えばこのバイトが3にセットされている場合、MVS/SPバージョン4のオペレーティング・システムを示す。これが4にセットされている場合オペレーティング・システムがMVS/ESAであることを示し、5にセットされている場合オペレーティング・システムがMVS/XAであることを示す。」と記載されていることから、システム管理機構（SMF）レコード内の１つのフィールドとして、オペレーティング・システムを識別するためのSMFxFLGなるフィールドを備えるものであると認められる。
　
　よって、引用例５には、１つのオペレーティング・システム・イメージから当該１つのオペレーティング・システム・イメージの外に対して通知するレコード内の１つのフィールドとして、オペレーティング・システムを識別するためのフィールドを備える発明（以下、「公知技術３」という。）が記載されていると認められる。　
　
３の１３．引用例６に記載されている技術的事項
　当審が拒絶理由通知において引用した特開平９−８１４１０号公報（平成９年３月２８日出願公開。以下、「引用例６」という。）には、図面とともに以下の技術的事項が記載されている。
　
（６−１）
「【０００８】装置の電源投入、あるいは保守員による診断コマンドの投入により診断モジュール部１０が起動され、各診断プログラム１〜４による一連の装置診断が実行されるが、その実行に先立ち、ログモジュール３０内の登録テーブル３２の登録内容がクリアされる（図２のステップＳ１）。各診断モジュール１〜４は図示していないがそれぞれ、装置に対して各種機能テスト，特性テスト等を行う装置診断プログラム部と、装置診断プログラム部でエラーを検出すると自モジュールの識別情報を含むエラー発生通知及びエラー状況，内容等を示す詳細なエラー情報を収集し出力するエラー情報処理部とから構成されている。各診断モジュール１〜４は順次診断を実行し（ステップＳ２）、エラーが検出されなければ（ステップＳ３のＮＯ）、ログモジュール３０に対して特に何もしない。いずれかの診断モジュール、例えば診断モジュール２でエラーを検出すると、自己の診断モジュール番号を含むエラー発生通知をログモジュール３０に送出し、引き続いてそのエラー情報を送出する（ステップＳ４）。」　　
　
３の１４．診断モジュールの識別情報を含むエラー発生通知を行うことに関する公知技術の認定
　引用例６の上記（６−１）に「各診断モジュール１〜４は…（中略）…装置診断プログラム部でエラーを検出すると自モジュールの識別情報を含むエラー発生通知…（中略）…するエラー情報処理部とから構成されている。」と記載され、上記（６−１）に「診断モジュール２でエラーを検出すると、自己の診断モジュール番号を含むエラー発生通知をログモジュール３０に送出し」と記載されていることから、引用例６には、診断モジュールに基づいてエラーを検出したときに、当該診断モジュールの識別情報を含むエラー発生通知を行う発明（以下、「公知技術４」という。）が記載されていると認められる。
　
第４．対比
　本願発明と引用発明を比較する。
　
　引用発明における「マルチオペレーティングシステム」と本願発明における「コンピュータ・システム」は、分割される対象であるコンピュータ・システムである点で一致する。
　引用発明における「システム」と本願発明における「論理区画」は、コンピュータ・システム（マルチオペレーティングシステム）を分割して設けられるものであって、複数のオペレーティングシステム（ＯＳ）のうちの互いに異なる１つのオペレーティングシステム（ＯＳ）がそれぞれ割り当てられて稼働する論理区画である点で一致する。
　引用発明における「入出力装置のエラー」は本願発明における「エラー・イベント」に相当する。
　引用発明における「エラー詳細情報」と本願発明における「イベント・ログ・エントリ」は、エラー・イベント（入出力装置のエラー）についての情報を含むイベント・ログ・エントリである点で一致する。
　引用発明においては「各々のシステムに複数のオペレーティングシステム（ＯＳ）のうちのどの１つが割り当てられているかにかかわらず、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいてフォーマット化を行う」ものであるから、ここでいう「エラー情報およびエラー情報ログを集約する他のシステムの形式」は、入出力装置のエラーを検出した１つのシステム（オペレーティングシステム）には依らない、マルチオペレーティングシステム（コンピュータ・システム）全体で共通の形式である。そのため、引用発明における「エラー情報およびエラー情報ログを集約する他のシステムの形式」は、本願発明における「所定のフォーマット」に相当する。
　
　すると、本願発明と引用発明とは、次の点で一致する。
　
＜一致点＞
　コンピュータ・システムであって、当該コンピュータ・システムが複数の論理区画に分割され、当該論理区画には、複数のオペレーティング・システムのうちの互いに異なる１つのオペレーティング・システムがそれぞれ割り当てられて稼動するコンピュータ・システムにおいて、当該コンピュータ・システム内で発生するエラー・イベントを報告するための方法であって、
　前記複数の論理区画のうちの１つの論理区画において、当該論理区画の中で発生するエラー・イベントを検出させるステップと、
　前記エラー・イベントについての情報を含むイベント・ログ・エントリを所定のフォーマットに基づいたものとするステップとを有し、
　エラー・イベントを報告するための所定のフォーマット（書式）に基づいて前記イベント・ログ・エントリ内の前記情報をフォーマット化（書式化）させるステップであって、前記所定のフォーマットに基づいて、エラー・イベントを報告するためにイベント・ログ・エントリ内にエラー情報を配置させ、さらに、各々の論理区画に前記複数のオペレーティング・システムのうちのどの１つが割り当てられているかにかかわらず、前記所定のフォーマットに基づいてフォーマット化を行なうことを特徴とする、
　方法。
　
　一方で、両者は、次の点で相違する。
　
＜相違点１＞
　複数の論理区画に分割されるコンピュータ・システムに関して、本願発明における「コンピュータ・システム」は「複数のプロセッサと複数のメモリ・ユニットとを含むリソースを有する」ものであるのに対し、引用発明における「マルチオペレーティングシステム」にハードウェアリソース（資源）として何が含まれるのかが引用例１の記載からは不明であり、複数のオペレーティング・システムのうちの互いに異なる１つのオペレーティング・システムがそれぞれ割り当てられて稼動する論理区画に関して、本願発明における「論理区画」は「少なくとも１つのプロセッサと少なくとも１つのメモリ・ユニットとを含むリソースがそれぞれ割り当てられ」るものであるのに対し、引用発明における「システム」にハードウェアリソース（資源）として何が含まれるのかが引用例１の記載からは不明である点。
　
＜相違点２＞
　複数の論理区画のうちの１つの論理区画において、当該論理区画の中で発生するエラー・イベントを検出させるステップに関して、本願発明では、「当該論理区画に割り当てられた１つのオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、」検出させるものであるのに対し、引用発明における入出力装置のエラーを検出させるためのソフトウェアとハードウェアについては引用例１の記載からは不明である点。
　
＜相違点３＞
　エラー・イベントについての情報を含むイベント・ログ・エントリを所定のフォーマットに基づいたものとするステップに関して、本願発明では「前記１つのオペレーティング・システムが、前記プロセッサに、」「生成させる」ものであるのに対し、引用発明では「１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、」「変換させる」ものである点。
　この点に関連して、エラー・イベントを報告するための所定のフォーマット（書式）に基づいてイベント・ログ・エントリ内の情報をフォーマット化（書式化）させるステップに関して、本願発明では「前記１つのオペレーティング・システムが、前記プロセッサに、」させるものであるのに対し、引用発明はそのようなフォーマット化を入出力装置のエラーを検出したシステム（オペレーティングシステム）内で行わせるわけではない点。
　同様に、所定のフォーマットに基づいて、エラー・イベントを報告するためにイベント・ログ・エントリ内にエラー情報を配置させることに関して、本願発明では「各々の論理区画に割り当てられて稼動するそれぞれのオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、」させるものであるのに対し、引用発明はそのようなフォーマット化に伴うエラーに関する情報の配置を、入出力装置のエラーを検出したシステム（オペレーティングシステム）内で行わせるわけではない点。
　同様に、各々の論理区画に複数のオペレーティング・システムのうちのどの１つが割り当てられているかにかかわらず、所定のフォーマットに基づいてフォーマット化を行なうことに関して、本願発明では「当該論理区画に割り当てられたプロセッサが、」行うものであるのに対し、引用発明はそのようなフォーマット化を入出力装置のエラーを検出したシステム（オペレーティングシステム）内で行うわけではない点。
　
＜相違点４＞
　本願発明では「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムを識別するためのオペレーティング・システム識別フィールドが、前記所定のフォーマット中に含まれ」るのに対し、引用発明における「エラー詳細情報」（イベント・ログ・エントリ）の「エラー情報およびエラー情報ログを集約する他のシステムの形式」（所定のフォーマット）にオペレーティングシステムを識別するフィールドが含まれるとは引用例１には記載されていない点。
　
＜相違点５＞
　本願発明では「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールドが、前記所定のフォーマット中に含まれ」るのに対し、引用発明における「エラー詳細情報」（イベント・ログ・エントリ）の「エラー情報およびエラー情報ログを集約する他のシステムの形式」（所定のフォーマット）に診断フォーマット・フィールドなるものが含まれるか否かが引用例１の記載からは明確でない点。
　
第５．判断
　上記相違点１乃至５について検討する。
　
５の１．相違点１について
　引用例２及び周知例１を例示するまでもなく、周知技術１として示した、複数のプロセッサとメモリとを含むリソースを有するコンピュータ・システムを複数の論理区画に分割するに際して、各論理区画にプロセッサやメモリのリソースを適宜割り当てることは、当業者にとって周知である。また、周知例１及び周知例２を例示するまでもなく、周知技術２として示した、コンピュータ・システムのメモリを複数のメモリ・ユニットから構成することも当業者にとって周知である。
　そして、引用発明に周知技術１、周知技術２を適用することに何ら阻害要因はないから、引用発明に周知技術１、周知技術２を適用して、引用発明における「マルチオペレーティングシステム」を複数のプロセッサと複数のメモリ・ユニットとを含むリソースを有するものとし、引用発明におけるそれぞれの「システム」を少なくとも１つのプロセッサと少なくとも１つのメモリ・ユニットとを含むリソースがそれぞれ割り当てられるものとすることに、特段の困難性はない。
　よって、上記相違点１は格別のものではない。
　
５の２．相違点２について
　引用例３を例示するまでもなく、周知技術３として示した、オペレーティングシステムがプロセッサに、周辺装置（周辺装置には当然入出力装置もその範疇として含まれるものである。）等のエラーを検出させることは、当業者にとって周知なことである。また、引用発明も検出したエラーを報告するための方法なのであるから、エラー検出に関する周知技術３を適用することに何ら困難性はない。
　そのため、引用発明に周知技術３を適用して、入出力装置のエラーを検出するに際して、システムに割り当てられた１つのオペレーティングシステムが、当該システムに割り当てられたプロセッサに検出させるようにすることに特段の困難性はない。
　よって、上記相違点２は格別のものではない。
　
５の３．相違点３について
　引用例３に記載された公知技術１として示したように、エラーが発生したゲストＶＭにて、エラーについての情報を含む障害情報を、システム共通のデータ形式に基づいて生成し、システム共通のデータ形式の障害情報を生成した後で、当該障害情報をエラーが発生したゲストＶＭの外に通知することは知られている。また、引用例４に記載された公知技術２として示したように、エラーが発生したサブシステムにて、エラーについての情報を含む管理情報を、システム全体として取り決めた形式（統合管理情報形式）に基づいて生成し、システム全体として取り決めた形式（統合管理情報形式）の管理情報を生成した後で、当該管理情報をエラーが発生したサブシステムの外に通知することは知られている。
　引用発明、公知技術１及び公知技術２のいずれも、エラーの報告を行う際において、エラー報告（引用発明では「エラー詳細情報」、公知技術１では「エラーについての情報を含む障害情報」、公知技術２では「エラーについての情報を含む管理情報」。本願発明における「イベント・ログ・エントリ」に対応する。）の形式をシステム全体に共通のもの（本願発明における「所定のフォーマット」に対応する。）とすることを課題としたものである。それゆえ、引用発明に、公知技術１または公知技術２を適用して、引用発明における「入出力装置のエラーについての情報を含むエラー詳細情報」を「エラー情報およびエラー情報ログを集約する他のシステムの形式」に基づいたものとするに際して、「１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知させた後で、」「変換させる」ことに代えて、入出力装置のエラーが検出された１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知する前に、入出力装置のエラーが検出された１つのシステムに割り当てられた１つのオペレーティングシステムが、当該システムに割り当てられたプロセッサに、当該形式に基づいた「エラー詳細情報」を生成させるようにすることに、特段の困難性はない。
　同様に、引用発明に、公知技術１または公知技術２を適用して、引用発明における「入出力装置のエラーを報告するための、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーについての情報を含むエラー詳細情報をフォーマット化させる」ことに関して、入出力装置のエラーが検出された１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知する前に、入出力装置のエラーが検出された１つのシステムに割り当てられた１つのオペレーティングシステムが、当該システムに割り当てられたプロセッサに行わせるようにすることに、特段の困難性はない。
　同様に、引用発明に、公知技術１または公知技術２を適用して、引用発明における「エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいて、入出力装置のエラーを報告するために、入出力装置のエラーについての情報を含むエラー詳細情報の中にエラーに関する情報を配置させ」ることに関して、入出力装置のエラーが検出された１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知する前に、各々のシステムに割り当てられて稼働するそれぞれのオペレーティングシステムである、入出力装置のエラーが検出された１つのシステムに割り当てられた１つのオペレーティングシステムが、当該システムに割り当てられたプロセッサに行わせるようにすることに、特段の困難性はない。
　同様に、引用発明に、公知技術１または公知技術２を適用して、引用発明における「各々のシステムに複数のオペレーティングシステム（ＯＳ）のうちのどの１つが割り当てられているかにかかわらず、エラー情報およびエラー情報ログを集約する他のシステムの形式に基づいてフォーマット化を行う」ことに関して、入出力装置のエラーが検出された１つのシステムからエラー情報およびエラー情報ログを集約する他のシステムに通知する前に、入出力装置のエラーが検出された１つのシステムに割り当てられた１つのオペレーティングシステムが、当該システムに割り当てられたプロセッサに行わせるようにすることに、特段の困難性はない。
　よって、上記相違点３は格別のものではない。
　
５の４．相違点４について
　引用例４の上記（４−５）の「統一管理情報形式は、システム全体が合意として取り決めた形式であれば任意に設定できる。」という指摘を引用するまでもなく、引用発明における入出力装置のエラーを報告するための「エラー詳細情報」にいかなるフィールドを設けるかは当業者が任意に設定できるものであり、また、引用例５に記載されている公知技術３のような、１つのオペレーティング・システム・イメージから当該１つのオペレーティング・システム・イメージの外に対して通知するレコード内の１つのフィールドとして、オペレーティング・システムを識別するためのフィールドを備えることも知られているのであるから、引用発明の「エラー詳細情報」の設定の一例として、オペレーティングシステムを識別するためのフィールドを備えるようにすることも当業者であれば適宜なし得たことに過ぎない。
　つまり、引用発明における「エラー詳細情報」の「エラー情報およびエラー情報ログを集約する他のシステムの形式」に含まれるフィールドとして、複数のシステムのうちの、その中で入出力装置のエラーが発生したシステムについて、当該システムに割り当てられたオペレーティングシステムを識別するためのオペレーティングシステム識別フィールドを備えるようにすることは、当業者にとって特段の困難性はない。　
　よって、上記相違点４は格別のものではない。
　
５の５．相違点５について
　後に「第６．各請求項における「診断フォーマット・フィールド」の明確性について」で指摘するように、本願の請求項１における「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載の意味するところが不明である。
　まず、本願の請求項１における「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載、特に当該記載のうち「診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させる」という部分の記載を（本来明確とはいえないが一応）文言上解釈して、「診断フォーマット・フィールド」がエラー・イベントを分析することに用いることができる何らかの診断結果等の情報を有するフィールドであると仮に解釈したとしても、元来、エラー検出・エラー報告とエラー診断は密接に関連したものであるから、引用発明における「エラー詳細情報」の内容として入出力装置のエラーを分析することに用いることができる何らかの診断結果等の情報を含めるようにすることは当業者が適宜なし得たことである。
　次に、「診断フォーマット・フィールド」に関して、明細書の【００４１】に「フィールド５０４は、オペレーティング・システムによって実行される診断ルーチンの種類を識別する診断フォーマット・フィールドである。」と記載されていることを考慮して、本願の請求項１における「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載における「診断フォーマット・フィールド」が実行される診断ルーチンの種類を識別するものであると解釈したとしても、引用例４の上記（４−５）の「統一管理情報形式は、システム全体が合意として取り決めた形式であれば任意に設定できる。」という指摘を引用するまでもなく、引用発明における入出力装置のエラーを報告するための「エラー詳細情報」にいかなるフィールドを設けるかは当業者が任意に設定できるものであり、また、引用例６に記載されている公知技術４のような、診断モジュールに基づいてエラーを検出したときに、当該診断モジュールの識別情報を含むエラー発生通知を行うことも知られているのであるから、引用発明の「エラー詳細情報」の設定の一例として、診断に用いたプログラム（引用例６では「モジュール」という語が用いられ、本願明細書では「ルーチン」という語が用いられている。）の種類を識別するためのフィールドを備えるようにすることも当業者であれば適宜なし得たことに過ぎない。
　つまり、本願の請求項１における「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載を、（本来明確とはいえないが一応）文言上解釈したとしても、明細書の記載を考慮して解釈したとしても、引用発明における「エラー詳細情報」の「エラー情報およびエラー情報ログを集約する他のシステムの形式」に含まれるフィールドとして、複数のシステムのうちの、その中で入出力装置のエラーが発生したシステムについて、当該システムに割り当てられたオペレーティングシステムが、当該システムに割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて入出力装置のエラーを分析させるための、診断フォーマット・フィールドを備えるようにすることは、当業者にとって特段の困難性はない。
　よって、上記相違点５は格別のものではない。
　
　また、本願発明が有する作用効果は引用発明、（引用例２及び周知例１により例示される）周知技術１、（周知例１及び周知例２により例示される）周知技術２、（引用例３により例示される）周知技術３、（引用例３に記載されている）公知技術１、（引用例４に記載されている）公知技術２、（引用例５に記載されている）公知技術３及び（引用例６に記載されている）公知技術４から当業者が予測できた範囲内のものである。
　
　よって、本願発明は、引用発明、（引用例２及び周知例１により例示される）周知技術１、（周知例１及び周知例２により例示される）周知技術２、（引用例３により例示される）周知技術３、（引用例３に記載されている）公知技術１、（引用例４に記載されている）公知技術２、（引用例５に記載されている）公知技術３及び（引用例６に記載されている）公知技術４に基いて、当業者が容易に発明をすることができたものである。
　
第６．各請求項における「診断フォーマット・フィールド」の明確性について
　平成２２年１２月７日付けの拒絶理由通知において、当審から下記の拒絶理由を通知した。
　
「理由４ 
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
１．請求項１、請求項１０及び請求項１１のいずれにも「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断用のフォーマットを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」と記載されている。しかしながら、この記載によっては、「診断用のフォーマット」とは何を意味するのかが不明であるため、「診断フォーマット・フィールド」が結局のところ何を意味するのかが不明である。 
 （なお、この「診断フォーマット・フィールド」に関しては、明細書の【００４１】に「フィールド５０４は、オペレーティング・システムによって実行される診断ルーチンの種類を識別する診断フォーマット・フィールドである。」と記載されている。この【００４１】で示されていることを請求項１、請求項１０及び請求項１１のそれぞれに適切に反映させれば、とりあえず、上記１．の拒絶理由に関しては解消するものと考えられる。） 」
　
　これに対し、審判請求人は、平成２０年１２月１１日付け手続補正書における請求項１、請求項１０及び請求項１１の「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断用のフォーマットを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載を、平成２２年１２月２０日付け手続補正により「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」と補正して、平成２２年１２月２０日付け手続補正後の請求項１、請求項６及び請求項７のなかに含めるようにした。
　しかしながら、同手続補正後の「前記複数の論理区画のうちの、その中で前記エラー・イベントが発生した１つの論理区画について、当該論理区画に割り当てられたオペレーティング・システムが、当該論理区画に割り当てられたプロセッサに、診断フォーマット・フィールドを識別させて前記エラー・イベントを分析させるための、診断フォーマット・フィールド」という記載をもってしても、「診断フォーマット・フィールドを識別させて」という部分の意味するところが不明であり、「診断フォーマット・フィールド」が結局のところ何を意味するのかが依然として不明であることは変わりがない。
　なお、平成２２年１２月２０日付け意見書において、審判請求人は上記の件に関しては「(2) 補正前の請求項１、１０、１１（補正後の請求項１、６、７）において、「診断用のフォーマット」が「診断フォーマット・フィールド」と補正された。この要件は、出願当初の明細書の段落００４１に記載されている。」と言及する程度にとどまり、「診断フォーマット・フィールド」の意味するところについて何ら釈明もしていない。
　よって、平成２０年１２月２０日付けの手続補正後の請求項１、請求項６及び請求項７（及び、これらの請求項を引用する従属請求項）の記載は明確でなく、本願は特許法第３６条第６項第２号に規定する要件を満たしていない。
　
第７．請求項６における「コンピュータ・プログラム」について
　平成２２年１２月７日付けの拒絶理由通知において、当審から下記の拒絶理由を通知した。
　
「理由２ 
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。 
 　　 
 　　　　　　　　　　　　　　　　　記 
…（中略）…
２．明細書等の記載によれば、本願が要旨とするところの動作、特に、エラー・イベントの検出と所定のフォーマットによるイベント・ログ・エントリの生成は、オペレーティング・システムに基づいて行われるものである。明細書等の記載全体を考慮しても、オペレーティング・システム以外のコンピュータ・プログラムにより、どのようにして本願が要旨とするところの動作を行うのかが、明細書等に開示されているとはいえない。 
　これに対し、請求項１０の記載ぶりによれば、本願が要旨とするところの動作、特に、エラー・イベントの検出と所定のフォーマットによるイベント・ログ・エントリの生成を、オペレーティング・システムに限定されない「コンピュータ・プログラム」に基づいて行われるかのように解釈が可能である。このような、動作の根拠となるプログラムの種類の拡張ないし一般化は本願においてはできるとはいえないため、請求項１０は本願明細書の発明の詳細な説明に記載した範囲を超えて特許を請求するものとなっている。よって、請求項１０に関して、本願は特許法第３６条第６項第１号でいうサポート要件を満たしていない。 
 　 
理由３ 
 　この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
　明細書等の記載によれば、本願が要旨とするところの動作、特に、エラー・イベントの検出と所定のフォーマットによるイベント・ログ・エントリの生成は、オペレーティング・システムに基づいて行われるものである。明細書等の記載全体を考慮しても、オペレーティング・システム以外のコンピュータ・プログラムにより、どのようにして本願が要旨とするところの動作を行うのかが、明細書等に開示されているとはいえない。 
　これに対し、請求項１０の記載ぶりによれば、本願が要旨とするところの動作、特に、エラー・イベントの検出と所定のフォーマットによるイベント・ログ・エントリの生成を、オペレーティング・システムに限定されない「コンピュータ・プログラム」に基づいて行われるかのように解釈が可能である。つまり、請求項１０の「コンピュータ・プログラム」をオペレーティング・システム以外のコンピュータ・プログラムと解釈した場合には、請求項１０に関して、本願は特許法第３６条第４項第１号（または、原出願（特願２００２−０４９０８０号）の出願日である特許法においては第３６条第４項）でいう実施可能要件を満たしていない。 
　　 
理由４ 
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
　 
 　　　　　　　　　　　　　　　　　記 
…（中略）…
３．請求項１０は「コンピュータ・プログラム」を特許請求するものであって、請求項１０においては「コンピュータ・プログラム」という語が４箇所に記載されている。しかしながら、請求項１０の記載全体を考慮すれば、実質的に同じものを指し示すために「オペレーティング・システム」という語と「コンピュータ・プログラム」という語が用いられており、用語が統一されているとはいえない。 
（なお、明細書等においては、オペレーティング・システム以外のいかなるコンピュータ・プログラムにより本願が要旨とするところの動作を行えるのかが開示されていないため、仮に請求項１０の上記で指摘した用語を「コンピュータ・プログラム」に統一した場合には、特許法第３６条第６項第１号でいうサポート要件や特許法第３６条第４項第１号（または、原出願の出願日における特許法においては第３６条第４項）でいう実施可能要件を満たさないものとなるので注意されたい。） 」
　
　これに対し、審判請求人は、平成２０年１２月１１日付け手続補正書における請求項１０の記載を、平成２２年１２月２０日付け手続補正により補正し、同手続補正後の請求項６とした。
　しかしながら、同手続補正後の請求項６の記載において、上記した拒絶理由は何ら解消されていない。また、平成２２年１２月２０日付け意見書において、審判請求人は上記の件に関しては何ら釈明もしていない。
　よって、平成２０年１２月２０日付けの手続補正後の請求項６に関して、本願は、特許法第３６条第６項第１号に規定する要件、同法同条第４項に規定する要件、同法同条第６項第２号に規定する要件のいずれも満たしていない。
　
第８．むすび
　したがって、上記「第２．本願発明の認定」、「第３．先行技術文献に記載されている技術的事項と先行技術文献に記載されている発明の認定」、「第４．対比」及び「第５．判断」にて示したように、本願の請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第２９条第２項の規定により特許を受けることができない。
　また、上記「第６．各請求項における「診断フォーマット・フィールド」の明確性について」にて示したように、本願の請求項１乃至７の記載は「診断フォーマット・フィールド」に関して明確でないから、本願は特許法第３６条第６項第２号に規定する要件を満たしておらず、特許を受けることができない。
　さらに、上記「第７．請求項６における「コンピュータ・プログラム」について」にて示したように、本願の請求項６に関して、本願は、特許法第３６条第６項第１号に規定する要件、同法同条第４項に規定する要件、同法同条第６項第２号に規定する要件のいずれも満たしておらず、特許を受けることができない。
　
　よって、結論のとおり審決する。