【事件の表示】
　平成１１年特許願第２５７７９０号「エンタテインメント装置、メニュー表示方法および情報記録媒体」拒絶査定不服審判事件〔平成１３年　３月３０日出願公開、特開２００１−　８４１３１、請求項の数（８）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
　１．手続の経緯・本願発明
　本願は、平成１１年９月１０日の出願であって、平成１８年１月１１日付けで拒絶理由通知がなされ、同年３月２０日付けで手続補正がなされ、同年４月２８日付けで再度の拒絶理由通知がなされ、同年７月２６日付けで拒絶査定がなされ、これに対し同年８月３１日付けで審判請求がなされ、平成２０年１２月２４日付けで当審より拒絶理由通知がなされ、これに対し平成２１年２月２７日付けで手続補正がなされたものである。そして、請求項１乃至８に係る発明は、平成２１年２月２７日付けで補正された特許請求の範囲の請求項１乃至８（以下、「補正後の請求項１乃至８」という。）に記載されたとおりのものと認める。
　
　２．当審の拒絶理由について
　当審より平成２０年１２月２４日付けで通知された拒絶の理由の概要は、
　（理由１）
　「本件出願は、特許請求の範囲の記載に不備があるため、特許法第３６条第６項第２号に規定する要件を満たしていない。」、
　
　（理由２）
　「本件出願は、特許請求の範囲の記載に不備があるため、特許法第３６条第６項第１号に規定する要件を満たしていない。」
　
及び
　
　（理由３）
　「本件出願は、発明の詳細な説明の記載に不備があるため、特許法第３６条第４項に規定する要件を満たしていない。」
　
というものであるが、平成２１年２月２７日付けの手続補正により、特許請求の範囲に記載された特許を受けようとする発明は明確となり、また、特許請求の範囲に記載された特許を受けようとする発明は発明の詳細な説明に記載したものとなり、また、発明の詳細な説明の記載はその発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載されたものとなったので、当審より通知された前記理由１乃至理由３は、すべて解消された。また、平成２１年２月２７日付けの手続補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされているので、特許法第１７条の２第３項に規定されている要件も満たしている。
　
　３．原査定の拒絶理由
　原査定の拒絶理由の要旨は、本願発明は
　
文献１：特開平４−２４５５３６号公報
文献２：特開昭６３−２４４２２６号公報
文献３：特開平３−１２６１３０号公報
文献４：特開平２−６７６２５号公報
文献５：特開平６−３４８４６７号公報
　
に基づいて当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができないというものである。
　
　４．原査定の拒絶理由に対する当審の判断
　補正後の請求項１乃至４の「エンタテインメント装置」、補正後の請求項５、６の「電子機器」、補正後の請求項７、８の「コンピュータ」は、上位概念化するといずれも「装置」であると言えるから、補正後の請求項１乃至８は、
　
　（イ）装置が記憶媒体を有すること。
　（ロ）前記記憶媒体には、アプリケーションプログラム毎のアプリケーションモジュールが記憶されていること。
　（ハ）前記アプリケーションモジュールは、アプリケーションプログラムと、当該アプリケーションプログラムが動作するために必要なハードウェアの情報である要求ハードウェア情報とを有していること。
　（ニ）前記装置の起動時において、前記装置に接続されたハードウェアの構成を取得し、前記記憶媒体に記憶されている前記アプリケーションモジュール毎に、前記取得したハードウェアの構成が、要求ハードウェア情報を満たすかどうかを判定し、満たすと判定したアプリケーションモジュールを示す情報をメニューの表示対象とすること。
　
を、発明特定事項として共通に備えている。
　
　一方、原査定において引用されている上記文献１は、第４頁左コラム第１５〜１８行に「そして、アプリケーション・プログラム４０−１〜４０−ｎの先頭に配置してある第３のテーブル４３からメニュー情報を読み出して表示させる（Ｓ１２）」と記載されているように、存在しているすべてのアプリケーション・プログラムのメニュー情報を取捨選択することなくすべて表示するようになっているから、上記（ニ）のように、ハードウェアの構成に基づいてメニューの表示対象を取捨選択することは文献１には記載も示唆もなく、また、文献１から自明な事項でもない。
　また、原査定において引用されている上記文献２は、第２頁右上欄第１３行〜同頁左下欄第２行に、
　「本発明では、第１図に原理的に示すように表示用のディスプレイ１と、複数のコマンドについてこれらをそれぞれ個別に表わす記号をディスプレイ１上に表示するコマンド表示手段２と、このコマンド表示手段２によって表示される各コマンドについてそれらが現在実行することができるか否かの判別を行う判別手段３と、この判別手段３の判別結果に応じてそれぞれのコマンドの表示形態を変化させる表示形態制御手段４とを表示装置に具備させる。」
と記載され、第５頁左上欄第３行〜同頁右上欄第６行には、
　「第８図は、第６図に示した各コマンド６１〜６５の表示制御を示す流れ図である。
　まず第３図に示したＣＰＵ１４は、ＲＡＭ１３にコマンドの数ｎをセットする（第８図ステップ1）。この実施例では、コマンドの数は５である。次にｉを０（零）とおき（ステップ2）、ｉ番目のコマンドが実行可能であるか否かの判別を行う（ステップ3）。ここでｉ＝０は第６図に示す印刷コマンド６１、ｉ＝２は確認コマンド６２、ｉ＝３は再読み取りコマンド６３、ｉ＝４は印刷部数コマンドであるとする。従ってまず印刷コマンド６１が実行可能であるかどうかの判別が行われる。画像出力部２５が画像編集装置に接続されていなかったり、その電源がオフとなっていたり、あるいは用紙がセットされていなかったりした場合には、印刷コマンド６１が実行できない状態になっている。
　印刷コマンド６１が実行不可能な状態では（ステップ3；Ｎ）、ＲＡＭ１３のｉ＝０に対応するフラグ記憶領域に数値“０”がセットされる（ステップ4）。ＣＰＵ１４はこのフラグ”０”についてのコマンドすなわち印刷コマンド６１の枠表示を細線とし（ステップ5）、ビットマツプメモリ２３に出力する。」
と記載されている（なお、文献２においては、○の中に数字の１、２等が書かれた記号が使用されているが、それらの記号はここでは1、2等の表記によって代用する。）が、文献２の上述の第８図の処理は装置の起動時に行われる処理ではなく、また、文献２の上述の第８図の処理は、印刷コマンドを実行するために必要な画像出力部が接続されているか否かを確認し、コマンドが実行可能か否かを判断してコマンドの表示形態を変化させているが、上記（ニ）のように「前記装置に接続されたハードウェアの構成を取得し、前記記憶媒体に記憶されている前記アプリケーションモジュール毎に、前記取得したハードウェアの構成が、要求ハードウェア情報を満たすかどうかを判定し、満たすと判定したアプリケーションモジュールを示す情報をメニューの表示対象とする」ものでもない。
　次に、原査定において引用されている上記文献３は、第２頁右上欄第１８行〜同頁左下欄第８行に「本発明に係るプログラムのロード方式においては、本体ＲＯＭおよびエミュレーションカードに格納されるＢＩＯＳを機能毎（ハードウェア毎）のモジュールに分け、各モジュールにモジュール識別子、バージョン番号を含むヘッダを付加し、このヘッダ情報に基づいて最新のファームウェアモジュールを選択するので、この最新のファームウェアが、本体ＲＯＭまたはエミュレーションカードのいずれに格納されている場合でも、これに左右されることなく、最新のファームウェアモジュールを選択することが可能になる。」と記載されているように、エミュレーションカードに格納されているＢＩＯＳと、本体ＲＯＭに格納されているＢＩＯＳのうち、バージョンの新しい方のＢＩＯＳを自動的に選択して使用する構成が開示されているに過ぎず、文献３には上記（ニ）の発明特定事項について記載も示唆もなく、また、文献３から自明な事項でもない。
　次に、原査定において引用されている上記文献４は、第２頁左上欄第３〜１４行に「本発明の方式は、ワークステーションから、動作させるべきプログラムを選択するプログラム選択方式において、システム生成時にニーズ・動作環境とプログラムを対応づけてニーズ・ソフト対応知識データベースを作成するニーズ動作環境学習手段と、システム利用時に利用者が入力したニーズにより、前記ニーズ・ソフト対応知識データベースを参照して、そのニーズ・動作環境に最適なプログラムを自動選択・自動起動させる最適プログラム自動選択・実行手段とを設けたことを特徴とする。」と記載されているように、利用者が「ニーズ」だけを指定すればニーズに対応する動作環境を判断し、その動作環境に最適なプログラムを自動選択してメニュー表示することもなく自動起動するものであるから、文献４には上記（ニ）の発明特定事項について記載も示唆もなく、また、文献４から自明な事項でもない。
　次に、原査定において引用されている上記文献５は、段落【００１６】〜【００２０】に、
「【００１６】次に、上記実施例の動作を説明する。なお、予め、図２に示すような、処理プログラムＰｒと、データテーブルへの格納順を決定する付加情報が付加された処理プログラムＰｒに対応するプログラム名Ｐｍとからなるメニュー定義ファイルＦを作成し、例えば、補助記憶部４に格納しておくものとする。
【００１７】図３は、メニュー一覧表示時の処理部２の処理手順を示すフローチャートである。まず、ステップＳ１において、補助記憶部４に格納されたメニュー定義ファイルＦを読み出し、次いで、ステップＳ２で、メニュー定義ファイルＦから読み出した各プログラム名Ｐｍに対し、読み出した順にプログラム番号Ｎｐを設定する。そして、ステップＳ３に移行し、プログラム名Ｐｍと、プログラム番号Ｎｐと、プログラム番号Ｎｐに対応するプログラム名Ｐｍの処理プログラムＰｒが格納されているメニュー定義ファイルＦのアドレスＡｄとの対応を表すメニューテーブルＴｍ（図５）を作成し、ステップＳ４に移行する。
【００１８】ステップＳ４では、プログラム名Ｐｍに付加された付加情報をもとに、予め設定した格納順にメニューテーブルＴｍの配列を並び変える。そして、ステップＳ５に移行してｎ＝１とした後ステップＳ６に移行し、メニューテーブルＴｍの１番目に格納されているプログラム番号Ｎｐを読み出し、ステップＳ７で、読み出したプログラム番号Ｎｐに対応するプログラム名を求め、表示装置５に表示する。
【００１９】そして、ステップＳ８に移行して、メニューテーブルＴｍから全てのプログラム名Ｐｍを読み出したか否かを判定し、全てのプログラム名Ｐｍを読み出した場合には処理を終了し、全てのプログラム名Ｐｍを読み出していない場合には、ステップＳ９に移行して、ｎ＝ｎ＋１とした後、ステップＳ６に戻り、上記と同様に、処理を行う。
【００２０】ここで、ステップＳ１〜Ｓ４がテーブル作成手段に対応している。そして、オペレータのキー操作等によって、表示装置５に表示されたプログラム名の中から任意のプログラム名が選択された場合には、図４に示す処理プログラム呼び出し処理を実行し、まず、ステップＳ２１において、メニュー表示処理において作成したメニューテーブルに基づき、選択されたプログラム名Ｐｍに対応する処理プログラムが格納されたアドレスＡｄを求めてステップＳ２２に移行し、求めたアドレスＡｄに該当するメニュー定義ファイルＦのアドレスから処理プログラムを読み出し、処理プログラム呼び出し処理を終了する。」
と記載されているように、メニュー表示を行うためにメニュー定義ファイルに基づいてメニューテーブルを作成することは開示されているが、前記メニューテーブルの作成は、装置に接続されているハードウェアの構成を考慮することなく行われており、当該文献５では装置に接続されているハードウェアの構成を取得することすら行われていないから、文献５には上記（ニ）の発明特定事項について、記載も示唆もなく、また、文献５から自明な事項でもない。
　以上のとおりであるから、原査定において引用されている上記文献１乃至５を組み合わせても、上記（イ）乃至（ニ）の発明特定事項を導き出すことが当業者にとって容易であるとは言えず、また、上記（イ）乃至（ニ）の発明特定事項によって補正後の請求項１乃至８に記載されている本願発明は、本願明細書の段落【０００４】に「この従来のメニュー表示では、出荷時に内蔵ＲＯＭにあらかじめ記憶されたものを表示するのみであり、出荷後の機能の追加・変更やそれに伴う表示の変更などに動的に対応することはできなかった」と記載されている課題を解決し、同明細書段落【００７６】、【００７７】にそれぞれ「アプリケーションごとにメニュー情報を保持し、これを用いてメニューを表示するため、アプリケーションの追加・変更に伴うメニュー項目（表示アイテム）の追加・変更が自動的に行われる」、「アプリケーションテーブルを作成する際、実行可能なアプリケーションのみを抽出するため、ハードウエア構成を変更した場合であっても、当該変更に伴って、表示されるメニューの内容も自動的に変更される」と記載されている効果を奏するものである。
　したがって、原査定の拒絶理由は妥当なものではない。
　
　５．まとめ 
　以上のとおり、原査定の拒絶理由は妥当ではない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。