【事件の表示】
　平成１０年特許願第　５０９８８号「ロード可能ハードウェア・サポート方法」拒絶査定不服審判事件〔平成１０年　９月２９日出願公開、特開平１０−２６０８１９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明
　本願は平成１０年３月３日（パリ優先権　米国、１９９７年３月１７日）の出願であって、その請求項１に係る発明は、平成１１年１２月６日付、及び、平成１６年３月５日付の各手続補正書によって補正された明細書及び出願当初の図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
　
【請求項１】
　プログラム命令を実行するプロセッサ、前記プロセッサに接続されたメモリ装置、及び該プロセッサに接続されたハードウェア・コンポーネントを有するコンピュータのオペレーティング・システムをロードする方法であって、
　前記ハードウェア・コンポーネントを検出する命令を有する、オペレーティング・システムのベース部を前記メモリ装置にロードするステップと、
　前記命令を使用して前記ハードウェア・コンポーネントを検出するステップと、
　前記ハードウェア・コンポーネントに対応したソフトウェア・コンポーネントをロードするステップと、
　を含む、方法。
　
２．引用例
　これに対し、平成１５年８月２７日付の拒絶の理由に引用された各引用例には以下の事項が図面と共に記載されている。
　
２．１　引用例１：「うぶ声をあげたＰｏｗｅｒＰＣパソコン」，
　　　　　　　　　日経バイト，日経ＢＰ社，No.133，1994年12月，
　　　　　　　　　P.112-132
（１）「ブート時とランタイムに抽象化ソフトを分けた
　このため、ＰＲｅＰはハードウェア抽象化をブート時とそれ以降（ランタイム）で明確に分けている（図２）。ＰＲｅＰではＯＳが立ち上がり始めるとブート・ソフトは姿を消してしまい、ＯＳ実行時に必要なソフトだけが動くようになる。図中のOpen Firmwareは将来のＰＲｅＰにおけるハードウェア抽象化のカギを担う重要なものであるが、これについては後で詳しく触れる。
　ブート時に使う抽象化のためのソフトウェアはＢＴＡＳ（
b
t
a
s
r
t
a
s
　
（２）「マシン情報を２種類のメモリ領域に格納
　ハードウェアを抽象化するためには、それに必要なハードウェアの情報を入れたテーブルを作り、ファームウェアやＯＳが利用できるようにしておく必要がある。そのためにＰＲｅＰは、ＮＶＲＡＭ（
n
v
R
　図５にＮＶＲＡＭの構成を示す。ヘッダ、ＧＥエリア、ＯＳエリア、Configエリアの四つに分かれている。ＧＥエリア（global environment area）はブート時にロードするファイルの名前やブート・デバイス、マシンのＩＰ（
i
p
　レジデュアル・データ構造はＣＰＵの数やキャッシュのサイズや種類、拡張スロットの数、メモリ・マップといったマシンの基本仕様を入れる。」（１２４頁中欄１行〜右欄１９行）
　
（３）「Open Firmware を使った場合のブートは既存のブートと比べてかなりインテリジェントなものになる。図６にOpen Firmwareによるブートの手順を示す。特徴的なのはデバイス構成ツリーを作ってＯＳに渡すこと、ＯＳのエンディアンに従ってエンディアンを変更して起動すること（既存のファームウェアでは必ずビック・エンディアンで起動する）などである。
　また、既存のファームウェアはロード・イメージ（ＯＳローダ）に制御を渡したら、もう何も仕事をしないが、Open FirmwareはＯＳローダから呼ぶためのインターフェースを規定している。既存のファームウェアの場合、ＯＳローダはシステムの情報を得るために前述のレジデュアル・データ構造を使うが、Open FirmwareがあればOpen Firmwareが用意するインターフェースを使ってこれらの情報を得る。レジデュアル・データ構造は過去の互換性維持のために残すが、将来のことを考えるとそこへの直接のアクセスはしない方がよい。」（１２５頁中欄１２行〜右欄１８行）
　
　以上の記載より、引用例１には、以下の発明が記載されている。
　
　ＰＲｅＰに準拠したコンピュータでＯＳをロードする方法であって、
  マシンの基本仕様が入ったレジデュアル・データからＯＳローダがシステムの情報を得ること
　を含む、方法。
　
２．２　引用例２：Managing AIX V4 on PCI-Based RISC System/6000
　　　　Workstations (40P/43P)，September 1995，
　　　　ＩＢＭ　International Technical Surpport Organization Austin
　　　　 Center，1995年9月，P.1-25
（４）「・Device Drivers
　Rewrite device drivers to use RTAS services and to be Endian aware.」（１１頁４１，４２行）
　
　以上の記載より、引用例２には以下の事項が記載されている。
　
　RTAS servicesを使うために、device driversを書き換える。
　
３．対比
　請求項１に係る発明と引用例１に記載された発明とを比較すると、
　
　引用例１に記載された発明の「ＰＲｅＰに準拠したコンピュータ」「マシンの基本仕様」は、それぞれ請求項１に係る発明の「プログラム命令を実行するプロセッサ、前記プロセッサに接続されたメモリ装置、及び該プロセッサに接続されたハードウェア・コンポーネントを有するコンピュータ」「ハードウェア・コンポーネント」に相当する。
　
　また、引用例１に記載された発明は「マシンの基本仕様が入ったレジデュアル・データからＯＳローダがシステムの情報を得ること」から、ＯＳローダはレジデュアル・データから「ハードウェア・コンポーネント」を得る（検出する）ためのステップを有している。
　
　また、ＯＳローダが上記「情報を得る」ことを実行するためには、「ＰＲｅＰに準拠したコンピュータ」のメモリ装置に、上記「情報を得る」ための命令をロードする必要があると認められ、引用例１に記載された発明も、請求項１に係る発明の「前記ハードウェア・コンポーネントを検出する命令を有する、オペレーティング・システムのベース部を前記メモリ装置にロードするステップ」と同様のステップを有している。
　
してみると、両者は次の点で一致している。
　
　プログラム命令を実行するプロセッサ、前記プロセッサに接続されたメモリ装置、及び該プロセッサに接続されたハードウェア・コンポーネントを有するコンピュータのオペレーティング・システムをロードする方法であって、
　前記ハードウェア・コンポーネントを検出する命令を有する、オペレーティング・システムのベース部を前記メモリ装置にロードするステップと、
　前記命令を使用して前記ハードウェア・コンポーネントを検出するステップ
　を含む、方法。
　
　一方、両者は以下の点で相違している。
　
　請求項１に係る発明が「前記ハードウェア・コンポーネントに対応したソフトウェア・コンポーネントをロードするステップ」を有しているのに対して、引用例１に記載された発明は、上記ステップに対応するステップについての記載がない点。
　
４．相違点について
　引用例２に記載されたRTAS servicesは、引用例１の１．１（１）に記載されている「ランタイムに使うのはＲＴＡＳ（
r
t
a
s
　してみれば、引用例１記載の発明でも、ランタイム中（即ち、ＯＳの制御の下）に「ハードウェア・コンポーネントに対応したソフトウェア・コンポーネント」を書き換える（即ち、ロードする）ことは当業者が適宜為し得ることにすぎない。
　また、ＯＳの下で、auto-configuration を行うことは、例えば、An Open System UNIX Design, IEEE INT. CONF. ON COMPUTER DESIGN: VLSI IN COMPUTERS, 1986, page 460-463 に記載されているように周知の技術であるから、上記相違点は、当業者が適宜為し得る程度のことにすぎない。
　
５．むすび
　従って、本願の請求項１に係る発明は、引用例１，２に記載された発明及び周知の技術に基いて当業者が容易に発明をすることができたものである。
　
よって、結論のとおり審決する。