特許 6054908 変数セットを修復する方法、コンピュータ・プログラムおよびコンピュータ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6054908

(24)【登録日】2016年12月9日

(45)【発行日】2016年12月27日

(54)【発明の名称】変数セットを修復する方法、コンピュータ・プログラムおよびコンピュータ

(51)【国際特許分類】

   G06F 9/445 20060101AFI20161219BHJP

【ＦＩ】

   G06F9/06 610K

【請求項の数】17

【全頁数】18

(21)【出願番号】特願2014-106076(P2014-106076)

(22)【出願日】2014年5月22日

(65)【公開番号】特開2015-222474(P2015-222474A)

(43)【公開日】2015年12月10日

【審査請求日】2015年1月19日

(73)【特許権者】

【識別番号】505205731

【氏名又は名称】レノボ・シンガポール・プライベート・リミテッド

(74)【代理人】

【識別番号】100106699

【弁理士】

【氏名又は名称】渡部 弘道

(74)【代理人】

【識別番号】100132595

【弁理士】

【氏名又は名称】袴田 眞志

(72)【発明者】

【氏名】萩原 幹雄

(72)【発明者】

【氏名】笠松 栄太郎

【審査官】 石川 亮

(56)【参考文献】

【文献】 米国特許出願公開第２００５／００３９０８１（ＵＳ，Ａ１）

【文献】 特開２０１３−１４０５３６（ＪＰ，Ａ）

【文献】 特開２００２−０１４８１８（ＪＰ，Ａ）

【文献】 特開２００９−０１５８１８（ＪＰ，Ａ）

【文献】 特開２０００−２３５４８３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

電源起動後に最初に実行されるシステム・ファームウェアが参照する変数セットをコンピュータが修復する方法であって、
前記システム・ファームウェアの参照領域に変数セットを書き込むステップと、
前記コンピュータが正常にブートしたときに前記変数セットを所定の領域に退避するステップと、
前回のブートの開始後に設定した検出フラグをオペレーティング・システムのロードを開始する直前に解除し、今回のブートで前記検出フラグを確認して前記参照領域の変数セットが改変されたことを前記コンピュータが検出するステップと、
前記検出に応答して前記コンピュータが前記退避した変数セットで前記参照領域の変数セットを置換するステップと
を有する方法。

【請求項2】

前記検出するステップが、前記オペレーティング・システムのロードを開始する前に前記ブートが停止したことを検出するステップを含む請求項１に記載の方法。

【請求項3】

前記検出するステップを、前記システム・ファームウェアが提供するセット・アップ画面を表示できる状態まで前記今回のブートが進行する前に実行する請求項１に記載の方法。

【請求項4】

前記検出フラグの確認を、前記システム・ファームウェアが前記検出フラグを確認するために必要なデバイスの初期化が終了した直後に実行する請求項１に記載の方法。

【請求項5】

前記検出フラグの確認を、前記システム・ファームウェアが前記参照領域に書き込んだ変数セットを参照する前に実行する請求項１に記載の方法。

【請求項6】

前記今回のブートを開始してから前記検出フラグを確認するまで所定の値でデバイスを初期化し、前記検出フラグを確認してから前記変数セットを参照して再度前記デバイスを初期化するステップを有する請求項１に記載の方法。

【請求項7】

前記今回のブートが、
前記検出フラグの確認の直後に前記検出フラグを設定するステップを有する請求項１に記載の方法。

【請求項8】

前記退避するステップを、前記システム・ファームウェアのセット・アップ画面を通じて実行する請求項１に記載の方法。

【請求項9】

前記退避するステップを、各ブートにおいて前記オペレーティング・システムのロードを開始する直前に実行する請求項１に記載の方法。

【請求項10】

前記退避するステップが、前記参照領域に書き込まれたすべての変数セットを退避する請求項１に記載の方法。

【請求項11】

電源起動後に最初に実行されるシステム・ファームウェアが参照する変数セットをコンピュータが修復する方法であって、
前記システム・ファームウェアを格納するファームウェアＲＯＭに設定された参照領域に変数セットを書き込むステップと、
前記コンピュータが正常にブートしたときに前記変数セットを前記ファームウェアＲＯＭとは異なる不揮発性メモリに退避するステップと、
前記コンピュータのブート中に前記参照領域の変数セットが改変されたことを前記コンピュータが検出するステップと、
前記検出に応答して前記ファームウェアＲＯＭとは異なる不揮発性メモリに格納された修復コードが前記コンピュータを前記退避した変数セットで前記参照領域の変数セットを置換するように機能させるステップと
を有する方法。

【請求項12】

前記修復コードのダイジェストを計算するステップと、
前記ダイジェストを前記コンピュータが保有する暗号鍵で暗号化するステップとを有し、
前記置換するように機能させるステップが前記ダイジェストを使って前記修復コードの同一性を検証するステップを含む請求項１１に記載の方法。

【請求項13】

前記退避するステップが、
前記退避する変数セットのダイジェストを計算するステップと、
前記ダイジェストを前記コンピュータが保有する暗号鍵で暗号化するステップとを含み、
前記置換するように機能させるステップが前記ダイジェストを使って前記変数セットが前記コンピュータから抽出されたことを検証するステップを含む請求項１１に記載の方法。

【請求項14】

前記システム・ファームウェアがＵＥＦＩファームウェアである請求項１から請求項１３のいずれかに記載の方法。

【請求項15】

コンピュータがブートの失敗から復旧する方法であって、
電源起動後に最初に実行されるシステム・ファームウェアのブートが成功したときに参照領域に書き込まれた変数セットを所定の領域に退避するステップと、
前記コンピュータのブートを開始するステップと、
前回のブートの開始後に設定した検出フラグをオペレーティング・システムのロードを開始する直前に解除し、今回のブートで前記検出フラグを確認して前記前回のブートが停止したことを検出するステップと、
前記検出に応答して前記コンピュータが前記退避した変数セットで前記参照領域の変数セットを置換するステップと
を有する方法。

【請求項16】

ＵＥＦＩファームウェアがファームウェアＲＯＭに書き込まれた変数セットを修復するためにコンピュータに、
前記変数セットを所定の領域に退避するステップと、
前記コンピュータがブートを開始するステップと、
前回のブートの開始後に設定した検出フラグをオペレーティング・システムのロードを開始する直前に解除し、今回のブートで前記検出フラグを確認して前記前回のブートが前記オペレーティング・システムのロードまで到達しなかったことを検出するステップと、
前記検出に応答して前記退避した変数セットで前記ファームウェアＲＯＭの変数セットを置換するステップと
を有する処理を実行させるためのコンピュータ・プログラム。

【請求項17】

電源起動後に最初に実行されるシステム・ファームウェアを実装するコンピュータであって、
プロセッサと、
システム・メモリと、
システム・ファームウェアと該システム・ファームウェアが参照する変数セットを格納する不揮発性メモリとを有し、
前記システム・ファームウェアが、前回のブートの開始後に設定した検出フラグをオペレーティング・システムのロードを開始する直前に解除し、今回のブートで前記検出フラグを確認して前記前回のブートが停止したことを検出したときにあらかじめ退避しておいた変数セットで前記不揮発性メモリの変数セットを置換する機能を前記コンピュータに実現させるコンピュータ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、起動できなくなったコンピュータを回復する技術に関し、さらには、システム・ファームウェアが参照する変数セットを回復する技術に関する。

【背景技術】

【0002】

コンピュータは、ハードウェアとオペレーティング・システム（ＯＳ）、デバイス・ドライバまたはアプリケーションなどの上位のプログラムとの間のインターフェースを提供するファームウェアを実装する。ファームウェアは、周辺デバイスを専用に制御するデバイス・ファームウェアとシステム全体の動作にかかわるシステム・ファームウェア（プラットフォーム・ファームウェアともいう。）に分けることができる。

【0003】

システム・ファームウェアは通常マザーボードに取り付けられたファームウェアＲＯＭに格納されている。ＢＩＯＳはこれまで多くのコンピュータ・システムに実装されてきたシステム・ファームウェアで、コンピュータの電源が起動してからＯＳがロードを開始するまでの間にＰＯＳＴ（Power On Self Test）およびパスワード処理をしたり、上位のプログラムがハードウェアにアクセスする為のサービスを提供したりする。

【0004】

しかしＢＩＯＳは、近年の進化したハードウェアへの対応が困難になってきたため、非特許文献１に示すように、ＵＥＦＩ（Unified Extensible Firmware Interface）フォーラムが、従来のＢＩＯＳであるレガシーＢＩＯＳに代わる新しいシステム・ファームウェアとしてＵＥＦＩ規格を策定した。ＵＥＦＩファームウェアは、レガシーＢＩＯＳをエミュレートして互換性を保つための仕組みを取り入れており、ハードウェアとソフトウェアは過去数年かけてレガシーＢＩＯＳからＵＥＦＩファームウェアに対応できるように段階的に発展してきた。２０１１年４月には非特許文献１に示すＵＥＦＩ規格が策定され、ハードウェアもほぼ対応できるようになってきたこともあって現在のシステムはＵＥＦＩファームウェアへの完全移行段階に入ってきている。

【0005】

ＵＥＦＩファームウェアを実装するシステムではＵＥＦＩネイティブ・モードで動作するＵＥＦＩ対応のＯＳと、レガシーＢＩＯＳ互換モードで動作するＵＥＦＩ非対応のＯＳのいずれも動作することができる。Ｗｉｎｄｏｗｓ（登録商標）７はＵＥＦＩネイティブ・モードに対応しているが、ＵＥＦＩファームウェアの高速ブート、セキュア・ブートなどの機能を利用することはできない。Ｗｉｎｄｏｗｓ（登録商標）８ではＵＥＦＩファームウェアに完全移行してその機能を完全に利用できるようになっている。

【0006】

非特許文献１のＵＥＦＩ仕様には、７．２項にバリアブル・サービス（Variable Services）を規定している。バリアブル・サービスでは、不揮発性のメモリにＵＥＦＩ規格で定義した変数であるグローバル・バリアブルズ（ＧＶ：Global Variables）を格納することにしている。現在ほとんどのパーソナル・コンピュータ（ＰＣ）では、ＵＥＦＩファームウェアを格納する不揮発性メモリにＧＶを記録している。ＵＥＦＩ規格では、ベンダーがＵＥＦＩ規格で定義されたＧＶ用の識別子（VendorGuid）を使って、当該不揮発性メモリにＧＶを書き込んでもよいとしている。また、ＯＳやアプリケーションがＵＥＦＩ規格で定義したＧＶを書き換えることを許容している。特許文献１はＵＥＦＩファームウェアが使用する変数をプロテクトして不揮発性メモリに記憶する発明を記載している。

【0007】

特許文献２は、システムを正常に起動させることができなくなったＢＩＯＳを正常なＢＩＯＳに復旧させる発明を開示する。情報処理装置は、電源が立ち上がるとＢＩＯＳを読み出すための命令を出力する。その後、ＢＩＯＳＲＯＭが起動を開始する前に、ＰＣＩスロットに装着されたＢＩＯＳＲＯＭカードに予め記憶されているシステムを初期化する初期化プログラムを読み出し、初期化プログラムによりシステムを初期化する。

【0008】

次に、ＢＩＯＳＲＯＭカードに記憶されているＢＩＯＳＲＯＭ書き換えプログラムを読み出し、読み出した書き込みプログラムに従って、ＢＩＯＳＲＯＭカードに記憶されているＢＩＯＳ制御コードをＢＩＯＳＲＯＭに格納する。特許文献３は、ＢＩＯＳ＿ＲＯＭに格納されたシステム・ファームウェアを更新する際に、ＢＩＯＳ＿ＲＯＭに旧ＣＲＴＭの変数の定義と新ＢＩＯＳの変数の定義が異なる場合に更新できなくなる事態を防ぐ発明を開示する。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０１０−７３１９３号公報

【特許文献2】特開２００３−３４５６１７号公報

【特許文献3】特開２０１３−１５６７９９号公報

【非特許文献】

【0010】

【非特許文献1】Unified Extensible Firmware Interface Specification Version 2.3.1 April 6,2011

【発明の概要】

【発明が解決しようとする課題】

【0011】

ところで、レガシーＢＩＯＳやＵＥＦＩファームウェアなどのシステム・ファームウェアは、ブートの際にデバイスの認識や初期化などの処理をするために、電源の起動直後にアクセスが可能なファームウェアＲＯＭに書き込んだデータを参照する必要がある。以後このようなブートに不可欠なデータ（変数）を、本明細書においてコンフィグレーション・バリアブルズ（ＣＶ：Configuration Variables）ということにする。

【0012】

ＣＶはプリブート段階でＵＥＦＩがデバイスに設定するデバイスの属性情報およびデバイスに設定するパラメータ、セット・アップ画面を呼び出してユーザが設定したデバイスの種類、デバイスの動作モード、デバイスの有効／無効などの設定情報、ブート・イメージが格納されているパーティションのパス、およびロードするＯＳの種類などの情報を含む。

【0013】

ここでプリブートとは、システムがＡＣＰＩに規定するパワー・オフ状態（Ｓ５ステート）またはハイバネーション状態（Ｓ４ステート）のときに、電源が起動してからＯＳがロードを開始するまでの間に、システム・ファームウェアが行う処理をいう。また本明細書でブートとは、電源が起動してからプリブートを経由してＯＳおよびＯＳアプリケーションのロードが完了した状態になるまでの一連の処理をいうことにする。なお、Ｓ５ステートまたはＳ４ステートからブートすることをコールド・ブートという。

【0014】

ＣＶの多くは、従来、ボタン電池で電源をサポートしているＣＭＯＳに記録されていたが、近年はＵＥＦＩを格納するファームウェアＲＯＭにも書き込むようになってきた。また、ＯＳ、ＵＥＦＩアプリケーション、およびＯＳアプリケーションはその実行に際して、自らをカスタマイズするための環境変数、デバッグ・ログ、またはエラー・ログのようなダンプ・ファイルをＵＥＦＩファームウェアの仕様上の制約を受けないで自由にファームウェアＲＯＭに書き込むことができる。このようなＯＳ、ＵＥＦＩアプリケーション、およびＯＳアプリケーションが作成したデータを本明細書においてユーザ・バリアブルズ（ＵＶ：User Variables）ということにする。

【0015】

ファームウェアＲＯＭは、システム・ファームウェアを格納するコード領域と変数を記録する変数領域を含む。いずれのプログラムであっても、バリアブル・サービスを利用して変数領域にデータを書き込むためには、ＵＥＦＩ規格が定義する関数であるSetVariable()を呼び出してパラメータを設定する必要がある。ＵＥＦＩ規格では後述の認証サービスなどを除き変数領域の利用に制限を設けていないため、ＵＥＦＩネイティブ・モードで動作するＯＳおよびＯＳアプリケーションは、バリアブル・サービスを利用して変数領域に自由にＵＶを書き込むことができる。その結果、変数領域にはＵＥＦＩファームウェアが書き込んだＣＶ、ＧＶと、ＵＥＦＩアプリケーション、ＯＳ、ＯＳアプリケーションが書き込んだＵＶ、ＧＶが記録される。

【0016】

システム・ファームウェアの動作環境がレガシーＢＩＯＳからＵＥＦＩファームウェアに完全に移行して変数領域がＯＳおよびＯＳアプリケーションに解放されたことに伴って、最近、ブートに支障がでる場合があることがわかってきた。ＵＶを書き込むＯＳやＯＳアプリケーションが、SetVariable()に誤ってＣＶやＧＶの変数の名称（VariableName）や識別子（VendorGuid）を設定すると、ＣＶやＧＶが書き換えられてしまうことがある。

【0017】

また、ＵＥＦＩファームウェアが誤ってＣＶやＧＶを書き込んだり更新したりすることもある。さらに、マルウェアによっても意図的にＣＶやＧＶが書き換えられたり消去されたりしてしまう危険性がある。ＣＶはプリブートでハードウェアを構成するために不可欠なデータであり、さらにＧＶもプリブートに関連するデータを含むためそれらが誤って書き換えられるとシステムをブートできなくなりユーザによる復旧作業が困難になる。

【0018】

ＵＥＦＩ規格では、SetVariable()に設定するパラメータをハッシュして書き込み保護をする認証サービス（Variable Authentication）を提供する。認証サービスを利用すればＯＳまたはＯＳアプリケーションによるＣＶの上書きを防ぐことはできる。しかし、ＯＳまたはＵＥＦＩアプリケーションが変数領域にアクセスしているときに電源の瞬断などによって電気的なノイズが発生すると、ＣＶやＧＶが毀損する可能性がある。

【0019】

またＵＥＦＩ規格では、ＯＳやＯＳアプリケーションがＧＶを書き換えることを許容するため、認証サービスではＧＶを保護することはできない。ＧＶは、Boot####、BootOrder、Driver####、DriverOrder、Key####などの名称の起動ディスクの種類や優先順位などに関するブート関連データや、Conin、Conoutといった入出力コンソールまでのパスに関するデータを含みＵＥＦＩ規格で定義している。ＧＶのブート関連データがＯＳやＯＳアプリケーションで誤って書き換えられたり、電源ノイズで改変されたりするとブートできなくなることも予想される。

【0020】

ＵＥＦＩファームウェアを格納するファームウェアＲＯＭは、システムの基板に装着されて容易に取り外しできないようになっている。またファームウェアＲＯＭは、ＯＳやＯＳアプリケ−ションにより書き換えができないように、ハードウェアでライト・ロックが施されている。そして、システムは電源が起動した直後だけライト・ロックを解除して、ファームウェアＲＯＭを最初に実行するようにして外付けのデバイスからの起動を防止し不正なプログラムによる起動を防止している。したがって、特許文献１のように電源の起動直後にファームウェアＲＯＭ以外のデバイスが格納するコードを実行して改変されたＣＶ、ＧＶを修復することはできない。

【0021】

また、ファームウェアＲＯＭは、ＣＶやＧＶのデフォルト値を保有しているため、起動直後にＦ１キー、Ｆ３キーなどのファンクション・キーを押下して、セット・アップ画面を表示させることができれば、それらを初期化することができる。しかし、セット・アップ画面を表示できる段階までプリブートが進むためには、ＵＥＦＩファームウェアが多くの変数を参照する必要があるため、変数が改変されている場合にはセット・アップ画面を表示できないことが多い。さらに、変数を初期化してしまうと、システムの状態が変化するため、できるだけシステムへの影響を少なくして修復できれば都合がよい。

【0022】

本発明は、システム・ファームウェアに関する上述の諸問題を解決することを目的とする。そこで本発明の目的は、電源の起動時に最初に実行するシステム・ファームウェアが参照する変数セットを修復する方法を提供することにある。さらに本発明の目的は、コンピュータをブートの失敗から復旧する方法を提供することにある。さらに、本発明の目的は、ブートが失敗したときに直近の動作環境に復旧する方法を提供することにある。さらに本発明の目的は、そのような方法を実現するコンピュータ・プログラムおよびコンピュータを提供することにある。

【課題を解決するための手段】

【0023】

本発明の一の態様は、電源起動後に最初に実行されるシステム・ファームウェアが参照する変数セットをコンピュータが修復する方法を提供する。システム・ファームウェアの参照領域に変数セットを書き込む。コンピュータが正常にブートしたときの変数セットを所定の領域に退避する。つぎに、コンピュータのブート中に、参照領域の変数セットが改変されたことを検出する。つぎに、検出に応答して退避した変数セットで参照領域の変数セットを置換する。したがって、変数セットをシステム・ファームウェアが誤って改変した場合、システム・ファームウェア以外のプログラムが改変した場合、または電源ノイズにより改変された場合のいずれでも正常にブートしたときの状態に戻すことができる。ＯＳやＯＳアプリケーションが書き込んだ変数セットも含めて参照領域のすべての変数セットを正常な変数セットで置換すれば、改変前の動作環境からの変化が少なくなるように修復することができる。

【0024】

システム・ファームウェアはＵＥＦＩファームウェアとすることができる。改変の検出は、オペレーティング・システムのロードを開始する前にブートが停止したことで検出することができる。セット・アップ画面を表示できる状態までブートが進行するためには、システム・ファームウェアが多くの変数セットを参照するため、変数セットが改変されているときはその段階までブート処理を進めることができない可能性が高いが、本発明では改変の検出を、システム・ファームウェアが提供するセット・アップ画面を表示できる状態までブートが進行する前に実行することができる。

【0025】

変数セットが改変されたことの検出は、前回のブートの開始後に検出フラグを設定し、オペレーティング・システムのロードを開始する直前に検出フラグを解除し、今回のブートで検出フラグを確認することで行うことができる。このとき検出フラグの確認を、システム・ファームウェアの検出フラグを確認するために必要なデバイスの初期化が終了した直後に実行することができる。また検出フラグの確認を、ブートを開始したシステム・ファームウェアが参照領域に書き込まれた変数セットを参照する前に実行することができる。さらに今回のブートを開始してから検出フラグを確認するまで所定の値でデバイスを初期化し、検出フラグを確認してから変数セットを参照して再度初期化することができる。その結果、変数セットが改変された状態でブートを開始したときに、検出フラグの確認ができないような事態を防ぐことができる。

【0026】

今回のブートで、検出フラグを確認するステップの直後に検出フラグを設定することができる。その結果、今回のブートで変数セットが改変されても次回のブートで検出フラグを確認して修復することができる。検出フラグの解除は、オペレーティング・システムのロードを開始する直前に実行することで、システム・ファームウェアによるブート処理が終了したときだけ検出フラグを解除できるため、次回のブートでシステムは検出フラグが解除されているときに、変数セットが改変されていないと判断することができる。

【0027】

正常にブートしたときの変数セットの退避は、システム・ファームウェアのセット・アップ画面を通じて行うことができる。また変数セットの退避は、各ブートにおいてオペレーティング・システムのロードを開始する直前に実行することもできる。この場合は、ブートが成功してから変数セットを退避するまでの間に、システム・ファームウェア以外のプログラムが変数セットを改変する機会を完全になくすことができる。

【0028】

参照領域を、システム・ファームウェアを格納するファームウェアＲＯＭに設定し、置換する処理をする修復コードと退避した変数セットをファームウェアＲＯＭとは異なる不揮発性メモリに格納することができる。修復コードのダイジェストを計算し、ダイジェストをコンピュータが保有する暗号鍵で暗号化し、置換する際にダイジェストを使って修復コードが改変されていないことを検証することができる。退避する際に、退避する変数セットのダイジェストを計算し、ダイジェストをコンピュータが保有する暗号鍵で暗号化し、置換する際にダイジェストを使って変数セットがコンピュータから抽出されたことを検証することができる。

【発明の効果】

【0029】

本発明により、電源の起動時に最初に実行するシステム・ファームウェアが参照する変数セットを修復する方法を提供することができた。さらに本発明により、コンピュータをブートの失敗から復旧する方法を提供することができた。さらに、本発明により、ブートが失敗したときに直近の動作環境に復旧する方法を提供することができた。さらに本発明により、そのような方法を実現するコンピュータ・プログラムおよびコンピュータを提供することができた。

【図面の簡単な説明】

【0030】

【図1】ＰＣ１０の主要なハードウェアの構成を説明するための概略の機能ブロック図である。

【図2】ファームウェアＲＯＭ１００のデータ構造の一例を説明するための図である。

【図3】ＰＣ１０が実装するソフトウェアの実行状態における階層構造を説明するための図である。

【図4】ＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７のデータ構造を説明するための図である。

【図5】ＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７に変数セットを格納する手順を説明するためのフローチャートである。

【図6】ＵＳＢメモリ・キー５０を利用して変数セットを修復する手順を説明するためのフローチャートである。

【図7】ＮＶＲＡＭ２７を利用して変数セットを修復する手順を説明するためのフローチャートである。

【発明を実施するための形態】

【0031】

［ハードウェアの概略構成］
図１は、ノートブック型またはデスクトップ型のパーソナル・コンピュータ（ＰＣ）１０の主要なハードウェアの構成を示す機能ブロック図である。多くのハードウェアの構成は周知であるため、ここでは本発明の理解に必要な範囲で説明する。チップセット１３はさまざまな規格のインターフェース機能を備えており、ＣＰＵ１１、システム・メモリ１５、ＧＰＵ１７、ＨＤＤ２１、ＵＳＢコネクタ２３、有線または無線のＬＡＮに接続するためのネットワーク・モジュール２５、不揮発性メモリ（ＮＶＲＡＭ）２７およびキーボード２９などが接続されている。ＧＰＵ１７にはＬＣＤ１９が接続されている。チップセット１３にはさらに、ＳＰＩ（Serial Peripheral Interface）コントローラにファームウェアＲＯＭ１００が接続されている。

【0032】

チップセット１３は後に説明する変数修復コード１５０ｆのダイジェストや変数セット２０５のダイジェストを暗号化する暗号鍵１５５を格納する。暗号鍵１５５は、たとえば、インテル（登録商標）ＭＥ・プラット・フォーム・キーや、ＵＥＦＩファームウェア１５０（図２）とＰＣ１０を関連付ける識別情報のような、ＰＣ１０を他のコンピュータから区別することができる固有のデータとすることが望ましい。

【0033】

ＨＤＤ２１は起動ディスクで、ＰＣ１０の、ＵＥＦＩ規格に対応するＯＳのブート・イメージを格納する。ＨＤＤ２１は、複数のパーティションにそれぞれＵＥＦＩ非対応のＯＳも含めて異なるブート・イメージを格納するようにしてもよい。ＨＤＤ２１のブート・セクタは、ＯＳのブート・イメージをロードするためのＯＳローダーを格納する。ＵＳＢコネクタ２３には、変数セットの修復に利用するＵＳＢメモリ・キー５０を装着することができる。ＰＣ１０は、ＵＳＢコネクタ２３にＯＳのブート・イメージを格納したＵＳＢメモリ・キーを装着して、当該ブート・イメージをロードすることはできるが、システム・ファームウェアを格納して電源の起動直後から実行することはできないようにしている。

【0034】

［ファームウェアＲＯＭのデータ構造］
図２は、ファームウェアＲＯＭ１００のデータ構造を説明するための図で、図３はシステム・メモリ１５にロードされて実行状態にあるソフトウェアの階層構造を説明するための図である。ファームウェアＲＯＭ１００は、不揮発性で記憶内容の電気的な書き替えが可能なフラッシュ・メモリで、一例としてコード領域１０１、デフォルト領域１０３、および変数領域１０５の３ブロックに区分している。

【0035】

本実施の形態では、コード領域１０１およびデフォルト領域１０３には、チップセット１３のＳＰＩコントローラでライト・ロックが可能な記録領域を割り当てている。ライト・ロックが実行された記録領域に対しては、チップセット１３がリセットされるまで書き込みができない。ただし、変数領域１０５はＵＥＦＩ規格でＯＳ１６７またはＯＳアプリケーション１６９（図３）による書き換えを保証しているＧＶを記録するためにライト・ロックはできない。ＵＥＦＩファームウェア１５０は、チップセット１３がリセットされたときに実行が可能な状態になり、ＯＳ１６７にＣＰＵ１１の制御権を渡す前にライト・ロックをする。

【0036】

本発明は、変数領域１０５を、ＣＶだけを記憶する領域と、ＧＶ、ＵＶを記憶する領域に分割して、前者だけをライト・ロックするようにしてもよい。ライト・ロックをすれば、ＯＳ１６７およびＯＳアプリケーション１６９による改変を防止することはできるが、ＵＥＦＩファームウェア１５０自体による誤った改変および電源ノイズによる改変の可能性は依然として残る。

【0037】

コード領域１０１はＵＥＦＩファームウェア１５０、検出フラグ１５３およびＵＥＦＩアプリケーション１６５を格納し、デフォルト領域１０３はＧＶとＣＶの初期値１８１を格納する。なお、検出フラグ１５３は、チップセット１３のＣＭＯＳ領域のような事前に変数セット１８３を参照しないでアクセスが可能な保管場所に格納することもできる。変数領域１０５にはＵＥＦＩファームウェア１５０、ＵＥＦＩアプリケーション１６５、ＯＳ１６７またはＯＳアプリケーション１６９が実行中にＣＶ、ＧＶ、ＵＶのいずれかの変数セット１８３を記録する。デフォルト領域１０３が格納する変数セットの初期値１８１は、ＰＣ１０の出荷前またはＵＥＦＩファームウェア１５０の更新時に書き込まれる。

【0038】

ＵＥＦＩファームウェア１５０は、システムの動作環境の変化に応じてＣＶとＧＶを更新する。ＵＥＦＩ規格では、ＧＶをＵＥＦＩアプリケーション１６５、ＯＳ１６７、ＯＳアプリケーション１６９に参照または更新できるように公開することを規定している。したがって、変数領域１０５が記録するＧＶおよびＣＶは当初は初期値であるが、ＰＣ１０がブートを繰り返す間に書き換えられたり追加されたりする。ＣＶがＵＥＦＩファームウェア１５０によって誤って書き換えられたり、電源のノイズで書き換えられたりすると、システムは次回のプリブートを正常に行うことができなくなる可能性がある。また、ＧＶのブート関連データがＯＳ１６７やＯＳアプリケーション１６９で誤って書き換えられたときも同様にプリブートを行うことができなくなる可能性がある。

【0039】

ＵＥＦＩファームウェア１５０は、初期化コード１５０ａ、ランタイム・サービス１５０ｂ、ブート・マネージャ１５０ｃ、セット・アップ・コード１５０ｄ、変数修復コード１５０ｅ、１５０ｆ、およびレガシーＢＩＯＳ互換サービス１５０ｇを含む。ＵＥＦＩファームウェア１５０は署名データ・ベースに、ＵＥＦＩファームウェアの製造者が発行した公開鍵を保持しており、完全性を検証した後でないと更新できないようになっている。

【0040】

また、システムは電源の起動（コールド・ブート）でリセットされたときにＣＰＵ１１に、ファームウェアＲＯＭ１００の初期化コード１５０ａを実行するリセット・ベクタを設定する。初期化コード１５０ａは、ＰＣ１０がコールド・ブートをする際に、システム・メモリ１５にＵＥＦＩファームウェア１５０をロードして実行を開始するために必要なＣＰＵ１１、システム・メモリ１５およびチップセット１３の主要なコントローラなどの基本的なデバイスの検出、検査および初期化を必要な範囲で行う。

【0041】

初期化コード１５０ａはまた、ＣＰＵ１１がリセットしてから、ＵＥＦＩ＿ＯＳローダー１６３に制御が移行するまでの期間にチップセット１３の残りのコントローラや周辺デバイスなどの所定のデバイスを初期化して使用できる状態にする。初期化コード１５０ａは、コード領域１０１が格納する他のコードの一貫性または完全性を検査して改竄を発見した場合はブートを停止する。

【0042】

ランタイム・サービス１５０ｂは、変数セットに関連するバリアブル・サービス、時刻情報のサービス、および仮想メモリ・サービスなどを提供する。ブート・マネージャ１５０ｃは、ブート処理およびパスワード認証処理などを行う。ブート・マネージャ１５０ｃは、ＧＶを参照してＵＥＦＩアプリケーション１６５、ＵＥＦＩドライバ１５０ｈおよびＵＥＦＩ＿ＯＳローダー１６３（レガシーＯＳ１７３をブートするときはレガシーＢＩＯＳ＿ＯＳローダー１７１）をシステム・メモリ１５にロードする。ブート・マネージャ１５０ｃは、プリブートが終了してＵＥＦＩファームウェア１５０からＯＳ１６７にＣＰＵ１１の制御権が移る直前に、ＵＥＦＩ＿ＯＳローダー１６３をシステム・メモリ１５に読み出して完全性の検証をする。

【0043】

ブート・マネージャ１５０ｃは、ＵＥＦＩ＿ＯＳローダー１６３のコードから計算したハッシュ値と、署名データ・ベースから取得した公開鍵で復号して得た電子署名のハッシュ値を比較して、一致していれば完全性が維持されていると判断してＵＥＦＩ＿ＯＳローダー１６３の実行を許可する。セット・アップ・コード１５０ｄは、プリブートの段階でキーボード２９の所定のファンクション・キーが押下されたたときに、ＬＣＤ１９にセット・アップ画面を表示する。

【0044】

ユーザはセット・アップ画面を通じて、起動ディスクの優先順位の決定、起動方法の設定、使用デバイスの設定、パスワードの設定およびパワー・マネジメントの設定などをすることができる。さらに、ユーザは、前回のブートが成功したときに、今回のブートにおいてセット・アップ画面を表示してＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７に変数領域１０５が記録する変数セット１８３を復旧用の変数として退避することができる。

【0045】

セット・アップ・コード１５０ｄはセット・アップ画面を通じて入力された設定情報を変数領域１０５およびその他の記憶領域に書き込む。ユーザはセット・アップ・コード１５０ｄを通じて、変数領域１０５を初期値１８１に戻すことができる。ただし、プリブートの処理がセット・アップ画面を表示できる状態に到達するまでには、ほとんどのデバイスを初期化するために初期化コード１５０ａが多くの変数セット１８３を参照する必要がある。したがって、変数セット１８３が改変されている場合は、セット・アップ画面を表示できないことが多い。変数修復コード１５０ｅ、１５０ｆは、図４、図５の手順で説明するように、ＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７に退避した変数セットで、変数領域１０５を置換するための処理をする。

【0046】

一例において変数修復コード１５０ｆは実行に際し、後に説明するようにＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７に書き込まれる。変数修復コード１５０ｅ、１５０ｆは、デバイスの初期化に必要なパラメータを規定の初期値として保有することで、変数セットを参照しないで修復処理ができるようにコーディングしている。したがって、変数修復コード１５０ｅ、１５０ｆは、変数セット１８３の改変の影響を受けることはないようにしている。

【0047】

レガシーＢＩＯＳ互換サービス１５０ｇは、ＵＥＦＩ非対応のレガシーＯＳ１７３に対するレガシーＢＩＯＳ互換のインターフェースを提供する。レガシーＯＳ１７３が、レガシーＢＩＯＳ互換のインターフェースを利用するときは、ＩＮＴ＊＊の割り込みルーチンを呼び出すが、そこにはバリアブル・サービスに関する割り込みルーチンを含まないため、レガシーＯＳ１７３はバリアブル・サービスを利用することはできない。したがって、レガシーＯＳ１７３は、変数領域１０５にＵＶを書き込むことはできない。

【0048】

［ＵＳＢメモリ・キー］
図４は、ＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７のデータ構造を説明するための図である。両者を代表してＵＳＢメモリ・キー５０には、変数修復コード１５０ｆが転送された状態の変数修復コード２０１、変数修復コード１５０ｆのダイジェストを暗号鍵１５５で暗号化した暗号化ダイジェスト２０３、変数領域１０５に記録されていた変数セット１８３が転送された状態の変数セット２０５、変数セット２０５のダイジェストを暗号鍵１５５で暗号化した暗号化ダイジェスト２０７が格納される。

【0049】

以下においてはファームウェアＲＯＭ１００に格納された状態とＵＳＢメモリ・キー５０またはＮＶＲＡＭ２７に格納された状態を区別する必要がある場合に、後者の変数修復コードおよび変数セットをそれぞれ参照番号２０１、２０５で示すことにする。さらにＵＳＢメモリ・キー５０は、変数セット１８３の修復の際のユーザ認証に使用する修復用パスワード２０９を格納する。

【0050】

［変数修復の第１の手順］
図５、図６は、ＵＳＢメモリ・キー５０を使用してＵＥＦＩファームウェア１５０が改変された変数セット１８３を修復する手順を説明するためのフローチャートである。図５は、ＵＳＢメモリ・キー５０に図４に示したデータを格納する手順を示している。図６は、ＵＳＢメモリ・キー５０が装着されたＰＣ１０が変数領域１０５に記憶する変数セット１８３を修復する手順を示している。図５の手順は、ＮＶＲＡＭ２７にデータを格納する場合にも適用できる。

【0051】

図５のブロック３０１でＰＣ１０にＵＳＢメモリ・キー５０を装着し、ブロック３０３で電源を起動してコールド・ブートを開始する。ユーザは前回のブートが成功してＯＳ１６７およびＯＳアプリケーション１６９が安定して動作していることから、ブートに関連する変数セットは正常であることを確認している。ブロック３０５でユーザは、電源の投入直後に所定のファンクション・キーを押下してセット・アップ・コード１５０ｄを呼び出し、ＬＣＤ１９にセット・アップ画面を表示する。セット・アップ画面には、ＵＳＢメモリ・キー５０にデータを格納するためのメニューが表示される。セット・アップ画面が表示される状態では、ほとんどのデバイスの初期化が終了してＵＥＦＩファームウェア１５０がそれらの利用が可能な状態になっている。

【0052】

ブロック３０７で、ユーザが変数セット１８３の退避メニューを選択すると、変数修復コード１５０ｅは、変数領域１０５が記憶する変数セット１８３のハッシュ値を計算してダイジェストを作成する。さらに変数修復コード１５０ｅは、暗号鍵１５５を使ってダイジェストを暗号化する。ブロック３０９で変数修復コード１５０ｅは、変数セット１８３とそのダイジェストをそれぞれ変数セット２０５、暗号化ダイジェスト２０７としてＵＳＢメモリ５０に格納する。

【0053】

ファームウェアＲＯＭ１００に十分なスペースがないときは、ＯＳ１６７の動作環境下でＷｅｂサイトから変数修復コード１５０ｆをダウンロードして、ＵＳＢメモリ・キー５０に格納することもできる。このときダウンロードした変数修復コード１５０ｆには、製造者の秘密鍵で暗号化されたダイジェストが電子署名として付属している。電子署名を復号する公開鍵はＵＥＦＩファームウェア１５０に埋め込まれている。

【0054】

ブロック３１１でユーザが変数修復コード１５０ｆの格納メニューを選択すると、変数修復コード１５０ｅは、変数修復コード１５０ｆのハッシュ値を計算して作成したダイジェストを、暗号鍵１５５を使って暗号化する。ブロック３１３で変数修復コード１５０ｅは、変数修復コード１５０ｆと暗号化されたダイジェストを変数修復コード２０１、暗号化ダイジェスト２０３としてＵＳＢメモリ・キー５０に格納する。以後、ユーザはブートが失敗するまでＵＳＢメモリ・キー５０を保管するが、変数セット１８３はＰＣ１０がブートを繰り返すたびに変更される可能性があるため、ブロック３０７、３０９は適宜実施することが望ましい。ブロック３１５でユーザがパスワードの登録メニューを選択して、キーボード２９からＵＳＢメモリ・キー５０に修復用パスワード３１５を登録する。

【0055】

変数修復コード１５０ｅはコールド・ブートの際に、変数セット１８３のＵＳＢメモリ・キー５０への退避を促すプロンプトを経過時間やブート回数などで計算した適当なタイミングで表示することができる。変数領域１０５を、ＣＶとプリブートに関連するＧＶだけを記憶する領域と、ＵＶとその他のＧＶを記録する領域に分けておく場合は、ＵＳＢメモリ・キー５０にはＣＶとプリブートに関連するＧＶだけを保存しておくこともできる。このときプリブートに関連するＧＶは、Boot####、BootOrder、Driver####、DriverOrder、およびKey####とし、それらに対するパラメータは、ロード・オプション（Load options）とすることができる。

【0056】

つぎに図６を参照して、ＵＳＢメモリ・キー５０を利用してＰＣ１０が、改変された変数セットを修復する手順を説明する。ブロック４０３で電源を起動してコールド・ブートを開始する。ブロック４０３への移行には、前回のブートが成功して安定した動作をしていたブロック４２１からのパス、改変された変数セット１８３が修復されたブロック４６１からのパス、およびプリブートが失敗したブロック４１３からのパスを含む。以下の手順で明らかになるように、前回のプリブートが失敗したときは、今回のブートでユーザがＵＳＢメモリ・キー５０を装着して電源を起動することを想定している。

【0057】

リセット信号を受け取ったＣＰＵ１１は、電圧が安定すると内部のキャッシュおよびレジスタを初期化する。チップセット１３はＣＰＵ１１のあらかじめ定められたリセット・ベクタを初期化コード１５０ａのアドレスに切り換える。ＣＰＵ１１はリセット・ベクタ）にアクセスして初期化コード１５０ａのインストラクションをフェッチする。

【0058】

ブロック４０５でＣＰＵ１１はコード領域１０１に格納されたＵＥＦＩファームウェア１５０をキャッシュに読み出して、システム・メモリ１５およびチップセット１３などの修復に関連するＵＥＦＩファームウェア１５０を実行するのに必要な基本的なデバイスの初期化をする。つづいて、初期化コード１５０ａは、システム・メモリ１５が利用できるようになると、ＵＥＦＩファームウェア１５０をシステム・メモリ１５にロードする。

【0059】

ブロック４０７で変数修復コード１５０ｅが検出フラグ１５３を確認する。検出フラグ１５３の設定と解除の論理は正論理と負論理のいずれでもよい。ここまでの動作において実行する初期化コード１５０ａは、変数セット１８３に依存しないようなコーディングすることができる。たとえば、変数セットを参照しないで一旦既定の値でデバイスを初期化しておき、検出フラグを確認した後で変数セットを参照して再度、初期化を行うようにコーディングすることができる。したがって、前回のブートで変数セット１８３が改変されていても、今回のブートでは確実にブロック４０７まで進行することができる。

【0060】

検出フラグ１５３が設定されているときはブロック４５０に移行して変数セット１８３の修復処理をする。検出フラグ１５３が設定されていないときはブロック４０９に移行する。ブロック４０９では、ブロック４０７の手順の直後に変数修復コード１５０ｅが検出フラグ１５３を設定する。この手順も今回のプリブートの失敗を次回のプリブートで変数修復コード１５０ｅが検出できるようにするために、変数修復コード１５０ｅが変数セット１８３に依存しないようにコーディングしておくことが望ましい。ブロック４１１で初期化コード１５０ａが残りのデバイスを初期化したり、ブート・マネージャ１５０ｃがプリブートに必要な処理をしたりする。ブロック４１１が終了するとセット・アップ・コード１５０ｄが実行できる状態になる。ブロック４１１においては、ＵＥＦＩファームウェア１５０が多くの変数セット１８３を参照する。

【0061】

したがって、変数セット１８３が正常な状態から改変されていれば、ブロック４１１の手順を終了することができないためプリブートは停止する。他方でブロック４０７、４０９の手順は、ブロック４１１の前に行うことで前回のブートで変数セット１８３の改変があってもその影響を受けないで実行することができる。ブロック４１３では、変数セット１８３が改変されているとブロック４１１の手順の途中でプリブートが停止することを示している。ユーザはＬＣＤ１９の画面を注視することで、ＯＳ１６７のロードが始まらないときにプリブートが停止したと判断することができる。

【0062】

プリブートが停止したと判断したユーザは、ブロック４３１でＵＳＢメモリ・キー５０を装着してブロック４０３でＰＣ１０を再起動する。ブロック４１３からブロック４３１を経由してブロック４０３に移行するパスは、ユーザの操作に依存するため、点線で示している。ブロック４２１からブロック４０３までのパスもユーザの操作に依存するため点線で示している。

【0063】

ブロック４１３でプリブートが正常に終了したときは、ブロック４１５に移行して変数修復コード１５０ｅが検出フラグ１５３を解除する。検出フラグ１５３が解除できたことは、プリブートが成功したことを意味しており、変数セット１８３が改変されてないことに相当する。ブロック４１７でブート・マネージャ１５０ｃが、ＵＥＦＩ＿ＯＳローダー１６３の完全性を検証すると、ＣＰＵ１１の制御権がＯＳ１６７に移り、ＯＳ１６７およびＯＳアプリケーション１６９のロードが開始される。

【0064】

ブロック４１５の手順は、プリブートが成功してＯＳ１６７にＣＰＵ１１の制御権が移る直前の段階で行われるため、プリブートが成功する限り必ず実行される。ブロック４１９でブートが完了してＯＳ１６７およびＯＳアプリケーション１６９が実行される。ＯＳ１６７またはＯＳアプリケーション１６９は、その後の動作でＵＥＦＩファームウェア１５０が書き込んだプリブートに関連する変数セットを誤って書き換える場合がある。また、マルウェアが意図的に書き換える場合もある。本発明ではこれらの問題を、次回のブートで治癒することができる。ブロック４２１で今回のブートが完了して電源が停止する。

【0065】

ブロック４３１を経由したブロック４０３以降の手順では、検出フラグ１５３が解除されていないため、ブロック４０７からブロック４５１に移行する。ブロック４５０で変数修復コード１５０ｅは、ＵＳＢメモリ・キー５０が装着されていないときにビープ音でユーザにＵＳＢメモリ・キー５０を装着するように促すことができる。

【0066】

ブロック４５１で変数修復コード１５０ｅは、暗号鍵１５５で復号した暗号化ダイジェスト２０３と、変数修復コード２０１から計算したダイジェストを比較して同一性を検証する。同一性があるときは、変数修復コード１５０ｆは、ファームウェアＲＯＭ１００に格納されていた状態から改変されていないことに相当する。変数修復コード２０１をＷｅｂサイトからダウンロードしたときは、暗号化ダイジェスト２０３をＵＥＦＩファームウェア１５０が保持する公開鍵で復号して同一性を検証する。変数修復コード１５０ｆと変数修復コード２０１の同一性を検証することで、不正な変数修復コードを使って第３者がＰＣ１０にアクセスすることを防ぐことができる。ブロック４５０、４５１の手順も変数修復コード１５０ｅが変数セット１８３に依存しないで実行できるようにコーディングしておくことが望ましい。

【0067】

変数修復コード２０１の検証が成功するとブロック４５３で、ＣＰＵ１１はＵＳＢメモリ・キー５０が格納する変数修復コード２０１を実行する。変数修復コード２０１は、暗号鍵１５５を使って変数セットの暗号化ダイジェスト２０７を復号し、変数セット２０５から計算したダイジェストと比較する。両者が一致した場合は、変数セット２０５が暗号鍵１５５に関連付けられたＰＣ１０から抽出したもので、かつ改変されていないことになる。

【0068】

したがって、不正な変数セットを変数領域１０５に書き込むことはできず、かつ、異なるＰＣ１０の変数セットで置換することもできない。変数セット２０５とＰＣ１０のバインディングの検証が成功すると、ブロック４５５で変数修復コード２０１は修復用パスワード２０９でユーザ認証をする。したがって、ＰＣ１０から抽出した正規の変数セット２０５であってもＵＳＢメモリ・キー５０を使って他人が変数領域１０５に書き込むことはできない。

【0069】

変数修復コード２０１は、図７のブロック５０３で説明するように各プリブートの終了直前にＮＶＲＡＭ２７に格納することもできる。ブロック４５７では、変数修復コード２０１がユーザに、任意のタイミングでセット・アップ画面を通じてＵＳＢメモリ・キー５０に格納した変数セット２０５と、前回のプリブートの終了直前に退避して置いた変数セット２０５のいずれを使用して修復するかを選択させるためのプロンプトを表示することができる。ブロック４５９で変数修復コード２０１は、変数領域１０５に変数セット１８３をクリアしてから変数セット２０５を書き込む。

【0070】

ブロック４６１で変数修復コード２０１は、検出フラグ１５３を解除してブロック４０３でＵＳＢメモリ・キー５０を取り外すようにユーザに促したあとに電源を再起動する。これまでＵＳＢメモリ・キー５０を利用して変数セット１８３を修復する例を説明したが、ＮＶＲＡＭ２７を利用した修復もほぼ同じ手順で行うことができる。この場合は、ブロック４１３からブロック４０３にはブロック４３１を経由しないで自動的に戻る。また、ブロック４５０の手順は不要になる。

【0071】

［変数修復の第２の手順］
つぎに、図７のフローチャートを参照して、ＮＶＲＡＭ２７を使ってＵＥＦＩファームウェア１５０が改変された変数セット１８３を修復する手順を説明する。図７において図６の手順と同一の手順には、同一の参照番号を付して説明を省略し、特徴的なブロック５０１、５０３、５５１の手順だけを説明する。図６のブロック４５０、４５７の手順は図７から削除している。ブロック５０１では、修復に必要な変数セット２０５と修復コード２０１をＮＶＲＡＭ２７に格納している。

【0072】

ブロック５０３では、毎回、プリブートが成功して検出フラグ１５３を解除する直前に変数修復コード１５０ｅが変数セット１８３をＮＶＲＡＭ２７に退避する。その結果、ＮＶＲＡＭ２７には、ＵＳＢメモリ・キー５０に格納する場合とは異なり、ＯＳ１６７およびＯＳアプリケーション１６９による改変の可能性がない最新の変数セットを格納することができる。

【0073】

ブロック５５１では、ＮＶＲＡＭ２７が格納する変数修復コード２０１がブロック４５１と同様の手順で検証される。それ以降は、ＮＶＲＡＭ２７が格納する変数修復コード２０１が図６の手順と同様に修復処理をする。図５〜図７に示したフローチャートの手順はすべてが必須の手順ではなく、また、手順の前後を限定するものでもない。本発明に必須の手順および手順の前後関係は特許請求の範囲の記載として特定する。

【0074】

これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることはいうまでもないことである。

【符号の説明】

【0075】

１０ ＰＣ
２７ 不揮発性メモリ（ＮＶＲＡＭ）
１００ ファームウェアＲＯＭ
１０１ コード領域
１０３ デフォルト領域
１０５ 変数領域
１８３、２０５ 変数セット
１５０ ＵＥＦＩファームウェア

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】