JP5070206B2 - ハードウェア資源のシステム内再構成 - Google Patents

Description

発明の実施形態は、コンピュータシステムなどにおいて利用されるハードウェアコンポーネントに関しており、特にこれらコンポーネントのアップグレード可能性に関する。

より具体的にはパソコン（ＰＣｓ）、サーバ、携帯端末（ＰＤＡｓ）、および携帯電話を含む、プロセッサに基づく多くのシステムは、ハードウェアコンポーネントとソフトウェアコンポーネントの混合を含む。典型的にシステムは、例えばメモリその他の記憶媒体、チップセットその他のプロセスデバイス、入力／出力（Ｉ／Ｏ）デバイスを含む関連コンポーネントとともに、プロセス操作の大半を手がける一般に中央処理装置（ＣＰＵ）と称されるマイクロプロセッサを含む。

エンドユーザは典型的にこのようなシステムを様々なプロセス、娯楽、通信その他のアクティビティに利用する。しばしばユーザは、オペレーティングシステム（ＯＳ）、ウィルス対策プログラムなどのアプリケーションプログラムなどを含む、システムのソフトウェアコンポーネントをアップグレードする。さらにユーザは、ハードウェアを制御するために新たなソフトウェア（例えば、ドライバあるいはソフトウェアパッチ）をダウンロードさもなくばインストールして、追加的なメモリなどの新たなコンポーネントを追加して、高度なグラフィックカードなどの新たなデバイスを組み込み、あるいはマイクロプロセッサあるいはハードディスクドライブなどの古いコンポーネントを新たなコンポーネントに置き換えることにより、システムのハードウェアをアップグレードすることもある。しかし、先に構成されたシステム内のハードウェアコンポーネントについて販売後のアップグレード（post-point of sale upgrades）は出来ない。

マイクロプロセッサ、チップセットなどのハードウェアコンポーネントのハードウェア機能の適用は、ユーザの大半によりこれら機能が適用される何年も先を行くことが多い。例えば、ハードウェア機能はこれら機能がソフトウェアにより採用されるずっと前、および／またはこれら機能を実施するソフトウェアの成熟のずっと前から入手可能でありハードウェアコンポーネント内に現存することが多い。言い換えると、新たなハードウェア技術は、ソフトウェアがその技術を採用するより早く導入されることが多い、ということである。そのようなハードウェア機能に対するソフトウェア支援およびユーザの需要なくしては、これら新たなハードウェア機能を含むハードウェアコンポーネントは、しばしば、ボード上の技術が未開発のまま宝の持ち腐れとなる。

従い、システム内のハードウェア機能のアップグレード可能性を改善する必要が存在する。

図１を参照すると、システムの一以上のハードウェア機能をアップグレードするシステムのブロック図が示されている。図１に示すように、システムは、対象システム１００と通信する遠隔サーバ１０を含む。一例として、遠隔サーバ１０は、ＰＣの製造者あるいは転売人、あるいはその他のベンダーなどの相手先商標製品製造会社（ＯＥＭ）のウェブサーバであってよい。あるいは、遠隔サーバ１０は、ハードウェアコンポーネントの独立ベンダーと関連付けられていてもよい。また別の実施形態においては、遠隔サーバ１０は、ある種のハードウェアコンポーネントの公認転売人などの、独立サービスプロバイダと関連付けられていてもよい。ここでは遠隔サーバとして記載されるが、他の実施形態においては、本発明の一実施形態によるアップグレードを実現するのに別の種類のシステムが利用できることは理解されよう。

遠隔サーバ１０は、例えばインターネットあるいはその他のネットワークに基づく相互接続を介すものを含む様々な手段を利用して対象システム１００と通信してよい。幾らかの実施形態においては、遠隔サーバ１０は、対象システム１００と通信すべく安全インタフェース２０を含んでもよい。安全インタフェース２０は、対象システム１００と安全に通信すべく、ウェブに基づく金融その他の安全な取引に利用されるような、暗号技術を利用してもよい。

様々な実施形態においては、対象システム１００は、ＰＣ、サーバコンピュータ、ＰＤＡ、携帯電話などであってよい。対象システム１００は様々なハードウェア・ソフトウェアコンポーネントを含んでよい。様々な実施形態においては、異なるハードウェア機能のステータスを示す複数のマシンステータスレジスタ（ＭＳＲ）を含む支援構成テーブル１１０を含んでよい。一実施形態においては、支援構成テーブル１１０は、対象システム１００のマイクロプロセッサの内部にあって、マイクロプロセッサ自身の異なるハードウェア機能を示すのに利用されてよい。幾らかの実施形態においては、支援構成テーブル１１０内の情報の少なくとも幾つかが該プロセッサの他の箇所に含まれてもよい。例えば、他のステータスレジスタは、プロセッサの特定の性能を識別する情報を含んで、適切なソフトウェア、マイクロコードなどがその性能を利用できるようにしてもよい。しかし、このようなステータスレジスタ内の情報は遠隔サーバには見えない。

他の実施形態において支援構成テーブル１１０は、例えばチップセットコンポーネント、永続性メモリ、あるいはその他の位置である、対象システムの他の箇所に位置してよい。対象システム１００はさらに、本発明の一実施形態による様々なアップグレードアクティビティを取り扱う再構成可能なロジックブロック１２０を含んでよい。

操作中、遠隔サーバ１０はハードウェアコンポーネントのシステム内再構成のリクエストを起動してよい。例えば、遠隔サーバ１０は、システム１００のユーザがマイクロプロセッサのハードウェア機能のアップグレードを望んでいるかを判断するためのリクエストを対象システム１００へ送ってよい。遠隔サーバ１０は様々な方法で対象システム１００と通信してよい。例えば、幾らかの実施形態において遠隔サーバ１０は、任意のモデルおよび／または構成の全ての既知の対象システムへの放送送信といった、幾つものシステムに対する放送通信を送ってよい。例えば、一ＯＥＭの、特定のプロセッサおよび／または特定のソフトウェア画像を含む全てのモデルＸが放送パケットとして送信されてよい。

幾らかの実施形態においては、これらの放送パケットは、システムのユーザがパケット受信に気づかないよう、透過的に対象システム１００へ送られてよい。これら実施形態においては、放送パケットは、支援構成テーブル１１０へのアクセス情報に加えて、該パケットの送信者を識別する情報を含んでよい。特に、放送パケットは、対象システム１００のプロセッサが任意のハードウェア機能のアップグレードステータスの判断目的で支援構成テーブル１１０へアクセスするために実行する命令を含んでよい。例えば、放送パケットは、ハードウェア機能Ｂに関する情報についての遠隔サーバ１０からのリクエストを含んでよい。故に、対象システム１００は、機能Ｂを実現するためのアップグレードが対象システム１００と互換性を持つか判断すべく支援構成テーブル１１０へアクセスしてよい。そうである場合には、対象システム１００はそのような情報を遠隔サーバ１０へ通信してよい。幾らかの実施形態においては、この通信もまた対象システム１００のユーザには透過的であってよい。

遠隔サーバ１０がこのようにして対象システム１００が機能Ｂに対してアップグレード可能であると確かめると、遠隔サーバ１０はその後、機能Ｂに対する該システムのアップグレードを対象システム１００のユーザ（担当の情報技術（ＩＴ）マネージャ）が望むかどうか判断するための通信を、対象システム１００へ送ってよい。幾らかの実施形態においては、メッセージはポップアップあるいは他の動的なメッセージであってよい。これら実施形態においては、このような動的メッセージを受信するにあたり、対象システム１００が動的なアップグレードを実現できるようされてよい。アップグレードの利用可能性をアドバイスするメッセージの形式は多くの形式をとることができるが、幾らかの実施形態においては、従前のソフトウェア／ＯＳアップグレードなどのポップアップ表示を提示してもよい。一例としては、メッセージは以下のように機能Ｂの利用可能性を報告してよい「お持ちのＩｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）システムにおける機能Ｂの実現に興味がおありですか？」「この機能の利点を見たい場合、ここをクリックすると、あなたのシステムで既に利用可能な利用モデル列を見ることができます」。すると、機能の利点を説明するデモンストレーションがコストとともに提示されてよい。そして、「既にお持ちのＰＣのアップグレードはＸ分で＄Ｙかかります」などのメッセージが表示されてよい。ユーザの応答に基づき、遠隔サーバ１０への返信がなされる。このようにして、サービスプロバイダは、この販売時点後の金額に対する請求をして、完売チャンス（sell up opportunity）に乗じることができる。

ハードウェア機能は任意の機能を実現する任意の望ましいハードウェア回路であってよい。あくまで例示であり限定ではないが、幾らかの実施形態においてはアップグレードするハードウェア機能は、プロセッサ速度、安全機能などを含んでよい。アップグレードする他のハードウェア機能には、ハイパスレッドあるいは他のマルチプルスレッド技術、仮想化技術、６４ビット命令計算、高度技術などが含まれてよい。

幾らかの実施形態においては、遠隔サーバ１０は安全インタフェース２０を利用して対象システム１００にリクエストを送ってよい。そのお返しに、対象システム１００は該システムがアップグレード可能であるか、およびどの機能がアップグレードできるのか、を判断すべくチェックをする。上述のように、幾らかの実施形態においては、支援構成テーブル１１０の異なるレジスタを調べてシステムのアップグレードステータスを判断することができる。

図１に示すように、支援構成テーブル１１０は、複数のマシンステータスレジスタ（ＭＳＲ）を含んでよい。幾らかの実施形態においては、ＭＳＲ各々は多数のビットを含んでよく、各ビットが異なる機能と関連付けられていてよいが、もちろん他の制御スキームも利用できる。

第一のＭＳＲ１１２は製品機能ステータスレジスタと言及されてもよい。製品機能ＭＳＲ１１２は、ハードウェアコンポーネントの製造業者（プロセッサ製造業者）により設定され、任意のハードウェアコンポーネントが任意の機能に対応する回路を含むかを示してよい。図１に示す実施形態においては、製品機能ＭＳＲ１１２は複数のビットを含む。ビットＡ、Ｂ、Ｃが設定されているとして示されており、これは製造されたままのプロセッサがハードウェア機能Ａ、Ｂ、Ｃ用の回路を含むことを示す。もちろん他の実施形態においては、異なる構成が可能であり、示された機能数以上の機能が存在してよい。

さらに図１を参照すると、支援構成テーブル１１０は第二のＭＳＲ１１４を含み、これはシステム機能ＭＳＲと言及されてよい。システム機能ＭＳＲ１１４はどのシステムがＯＥＭを支援するかを、あるいは構成されたままのシステムに利用可能な他のベンダを報告することができる。つまり、機能のなかには、追加的なハードウェアあるいはソフトウェア（例としては、ＯＳ機能、ドライバ、信用できるプラットフォームモジュール（ＴＰＭ）あるいは帯域外（ＯＯＢ）管理可能性エンジンなどの追加的ハードウェア）のようなシステムレベル支援が必要となるものもある、ということである。故に、システム機能ＭＳＲ１１４は、構成されたままの対象システム１００が均一のアップグレードできるか否かについての情報を提供してよい。様々な実施形態においては、システム機能ＭＳＲ１１４は、対象システムの異なるハードウェア機能についてのアップグレード可能性を示すように、ＯＥＭその他のシステムベンダにより、例えばシステム製造中に書き込まれてよい。故に、第二のＭＳＲ１１４は任意のハードウェア機能についてシステムの認証／検証を提供するよう利用されてよい。任意の機能が第二のＭＳＲ１１４に設定される場合、対象システム１００は、任意のシステムの様々なハードウェアおよびソフトウェアの観点から、任意の機能のアップグレードに対してそれを支援するよう確実に相互利用可能であってよい。

故に様々な実施形態においてはシステムは、ＯＥＭ、相手先ブランド設計製造業者（ＯＤＭ）、および／またはインテグレータにより、あるクラスの機能についてアップグレード可能であると販売時点で認証されてよい。このようなアップグレード可能性は、販売時点で、システムに対応するコアモデルが多くのフレーバで利用可能であってよい（たとえば、様々なハードウェアコンポーネントおよびソフトウェアコンポーネントを含み、そのようなコンポーネントに様々なレベルがある）という前提に基づき提供できる。ユーザのなかには、全ての機能をイネーブルな形で（つまり、ラインシステムのトップ）購入することを希望する人もいよう。しかしユーザのなかには、生態系および利用モデルが熟し主流のユーザに対して価格をつりあげている間は、ハードウエアで利用可能な全ての機能のサブセットをもつシステムを購入することを望む人もいよう。故に、特定のシステム構成に基づくと、ベンダは販売時点ではシステム機能ＭＳＲ１１４を設定することにしてもよい。

アップグレードＭＳＲ１１６はシステム内でイネーブルできる対象コンポーネントの機能を示してもよい。幾らかの実施形態においては、ＭＳＲ１１６は販売後アップグレードＭＳＲであってよい。つまり、アップグレードＭＳＲ１１６は、ＭＳＲ１１２、１１４間の論理積演算を示してもよい。故に、図１に示すように、機能ＢはアップグレードＭＳＲ１１６に設定され、これは機能Ｂが販売後アップグレードであることを示す。

故に、対象システム１００がアップグレードできユーザがそのアップグレードを望む場合、対象システム１００および遠隔サーバ１０は対象システムをアップグレードさせてよい。幾らかの実施形態においては、任意のハードウェアアップグレードが許可される前にユーザがＯＥＭ提供画像を変更した場合、ハードウェア機能が途切れなく実現できることを確かめるべく現画像を再インストールしてもよい。つまり、遠隔サーバ１０が対象システム１００をアップグレードできる前に、第一に対象システム１００は現画像を再インストールされてもよい。

ハードウェアアップグレードを達成すべく、対象システム１００は、ハードウェア機能Ｂがイネーブルおよび／またはアップグレードを望まれているという示唆とともに、暗号鍵を遠隔サーバ１０へ送ってよい。様々な実施形態においては、アップグレード対象のシステムコンポーネントは（例えばＣＰＵあるいはチップセットコンポーネント）、対象システム１００特有の固有暗号鍵を提供してよい。幾らかの実施形態においては、固有暗号鍵は製品シリアル番号、あるいは各製造コンポーネントを一意に識別するよう提供される別の固有識別子であってよい。固有識別子を提供することで、著作権侵害防止およびその他の安全機構への準拠が施行される。

対象システム１００から入手された情報に基づき、遠隔サーバ１０はマイクロコード命令を暗号化して、機能Ｂ（一例である）を対象システム１００でアップグレードすることができる。図１の実施形態においては、遠隔サーバ１０内のコード暗号ロジックブロック３０を利用することで、アップグレードをするマイクロコードを入手して、該マイクロコードを対象システム１００から受信した暗号鍵により暗号化してよい。そして遠隔サーバ１０は、コードおよび検証通信ロジックブロック４０を介して暗号化された命令を送信してよい。様々な実施形態においては、送られる情報は、対象コンポーネントをテストしてアップグレードの成功を確かめるための追加的な命令とともに、ハードウェア機能（一又は複数）をイネーブルする暗号化されたマイクロコード命令を含んでよい。

さらに図１を参照すると、暗号化された命令を対象システム１００の再構成可能なロジックブロック１２０により利用することができる。再構成可能なロジックブロック１２０は、機能アップグレードを達成するために様々なコンポーネントを含むことができる。特に、図１に示すように、再構成可能なロジックブロック１２０は、遠隔サーバ１０が送るマイクロコードを復号するコード復号ロジック１２２を含んでよい。様々な実施形態において、コード復号ロジック１２２は、対象システム１００が送信する暗号鍵に対応する復号鍵を利用してよい。マイクロコードを復号すると、システム内イネーブルロジック１２４は機能Ｂを実現してよい。様々な実施形態においては、さらに以下に説明するように、ヒューズプログラミング可能性ロジックを利用して機能をイネーブルしてもよい。

機能のイネーブルを完成すると、システム内検証ロジック１２６は、ハードウェア機能のイネーブルが実際に成功したかどうか確かめてよい。成功である場合には、システム内検証ロジック１２６は、支援構成テーブル１１０内の機能イネーブル済みＭＳＲ１１８内に対応する機能ビットを設定して、イネーブルされたステータスを示してもよい。例えば図１は、機能イネーブル済みＭＳＲ１１８が機能Ｂに対応するビット内にロジック「ゼロ」を含むことを示す。機能Ｂを提供するアップグレードが成功すると、機能Ｂに対応するビットがロジック「１」状態に設定されてよい。機能イネーブル済みＭＳＲ１１８を設定すると、対象システム１００は、遠隔サーバ１０の確認および請求ロジックブロック（確認ブロック）５０に確認メッセージを送ってもよい。様々な実施形態においては、確認メッセージはさらに、ハードウェア機能が対象システム１００で機能したことを確認してもよい。故に、サーバ１０に戻る検証メッセージは、対象システム１００へのハードウェア機能の実施が成功したことを確認する署名を含んでよい。これによりユーザは、アップグレードの支払いを避ける試みから、ハードウェア機能のアップグレードが不成功に終わったと後に主張することはできない。

確認メッセージを受け取ると、遠隔サーバ１０は成功したアップグレードについて対象システム１００に関連付けられる勘定を請求することができる。さらに、確認ブロック５０は、対象システム１００へのアップグレードを示すステータスメッセージを中央データベース６０へ送ることができる。幾らかの実施形態においては、中央データベース６０はコンポーネント製造者（例えばマイクロプロセッサ製造者）と関連付けられたデータベースであってよい。このようにして製造者は、保証その他の目的で特定のプロセッサの実際の構成をトラックすることができる。例えば、ユーザが任意のハードウェア機能をイネーブルすると、プロセッサ製造者はそのシステムを、さらなるアップグレード、その任意のハードウェア機能アップグレードとの共用に適しているアクセサリを提供するソフトウェアその他のコンポーネントの対象としてよい。またさらには、プロセッサ製造者は特定のユーザが達成したアップグレードあるいはアップグレード選択全体に関する情報を利用して、将来の製品およびアップグレードの開発に利用するマーケティング情報を抽出してもよい。

図１には遠隔サーバ１０とともに実施されるとして示したが、他の実施形態においては、対象システム１００のアップグレードは他の方法で行われてもよい。例えば、ユーザは本発明の一実施形態によるアップグレードを実施する命令を含むディスクあるいはその他の記憶媒体を購入してもよい。

図２を参照すると、本発明の一実施形態による方法のフロー図が示されている。図２に示すように、方法２００を利用して、対象システムのハードウェア機能をアップグレードすることができる。方法２００は、対象システムと通信することで始められてよい（ブロック２０５）。例えば、ＯＥＭの遠隔サーバ、転売者などが対象システムと通信してよい。様々な実施形態においては、通信はシステムのユーザには透過的であってよい。特に、遠隔サーバは対象システムの構成に関する情報をリクエストして、該システムがアップグレード可能であるかの判断をしてもよい。

故に、対象システムがアップグレードを承認されるかどうか判断してもよい（ダイアモンド２１０）。様々な実施形態においては、支援構成テーブル内の情報は、遠隔サーバからのリクエストに応じて遠隔サーバへ戻されてよい。ここでも、遠隔サーバ・対象システム間のこの通信はエンドユーザに対して透過的であってよい。対象システムから受信される情報に基づき、遠隔サーバは対象システムがアップグレードを承認されるか判断してよい。承認されない場合には、方法２００は終了されてよい。

対象システムがアップグレードを承認されると判断される場合には、次に、ユーザがシステムのアップグレードを望むかどうか判断してよい（ダイアモンド２１５）。システムがアップグレードを望まれているかを判断するのには様々な方法が存在しうるが、多くの実施形態においては、遠隔サーバから対象システムへメッセージが送られてよい。メッセージは例えばポップアップその他のメッセージブロックにより対象システムにおいて表示され、アップグレードの利用可能性を示してよい。ユーザがアップグレードを望まない場合、方法２００は終了されてよい。

あるいは、ユーザがアップグレードを望む場合、対象システムは遠隔サーバに暗号鍵を送ってよい（ブロック２２０）。様々な実施形態においては、暗号鍵は、対象システムおよび／またはシステムの特定のハードウェアコンポーネント（例えばプロセッサあるいはチップセット）を識別する固有コードであってよい。

暗号鍵を利用して、遠隔サーバはアップグレードをイネーブルする暗号化命令を生成してよい。より具体的には、遠隔サーバはマイクロコード命令を生成してよく、さらには、命令への不当アクセスを妨げるために命令を暗号化してよい。マイクロコード命令は対象システムが、適切に一以上のハードウェアコンポーネントをプログラミングして、操作機能（一又は複数）をイネーブルするのに利用されてもよい。遠隔システムはさらに、検証命令を生成して、これを対象システムに送信してアップグレードが成功したこと、および対象システムが所望の機能を実施するコードを実行することができることを確かめてよい。故に、遠隔サーバは対象システムに暗号化アップグレード命令を送信してよい（ブロック２２５）。

暗号化命令に対応する復号鍵を利用して、対象システムはアップグレード命令を復号して、これにより対象システムをプログラミングしてよい（ブロック２３０）。特に、復号化マイクロコード命令を利用すると、安全違反をあまり気にすることなくアップグレードを安全に行うことができる。つまり、マイクロコード命令を復号して直接プロセッサコアに送ってよく、ここでマイクロコード命令を内部的に実行してプログラミングを始めてよい。送信された命令はこれら実施形態でマイクロコード内にあってよいので、ユーザが命令を抽出して、該命令を権限のない者に送ることは顕著に減らされよう。

幾らかの実施形態においては、マイクロコード命令はプロセッサにより実行されて、アップグレードする機能（一又は複数）のプログラミングを始めてよい。例えば、幾らかの実施形態においては、マイクロコード命令は動的ヒューズプログラミングロジックをプロセッサその他のハードウェアコンポーネント内で起動して、一以上のヒューズをバーニング（burn）して前に利用不可能であった回路への経路をイネーブルしてもよい。これら実施形態においては、動的ヒューズプログラミングロジックは、電源電圧をヒューズバンクなどへ起こし、選択されたヒューズをバーニングして（つまりイネーブルして）よい。バーニングが成功すると、経路は機能を実行する回路へ生成される。

コンポーネントをプログラミングして機能をイネーブルした後、次にはアップグレードが成功したかを判断してよい（ダイアモンド２３５）。様々な実施形態においては、遠隔サーバが送信したコードを利用して、イネーブルされた機能の操作を検証してもよい。例えば、幾らかの実施形態においては、検証コードをマイクロコード命令とともに送ってよい。プログラミングが完成すると、対象システムは検証コードを実行してよい。検証コードは新たにイネーブルされた回路を実行して、意図する目的で操作されるか検証してもよく、より具体的には、対象システムの特定の構成で操作されるかを検証してよい。

アップグレードが不成功だったと判断される場合（ダイアモンド２３５）、制御はブロック２４０へ移行し、ここでエラー対処処理が行われてよい。様々な実施形態においては、エラー対処コードが対象システム上で実施されて、エラーに対処してよい。幾らかの実施形態においては、エラー対処処理は遠隔発信元からダウンロードされてよい。エラー処理コードが実行された後、今度はアップグレードプロセスを再試行するかどうか判断してよい（ダイアモンド２４５）。例えば、エラー対処ルーチンがエラーを訂正すると、アップグレードプロセスを再試行することができる。あるいは、今の時点ではアップグレードを行わないと判断されてもよく、そうするとこの時点で方法２００が終了されてよい。アップグレードを再試行する場合には、制御はブロック２３０へ戻る。

一方、ダイアモンド２３５においてアップグレードが成功したと判断された場合には、アップグレードを遠隔サーバへ報告してよい（ブロック２５０）。特に、支援構成テーブルからの情報を遠隔サーバに送り、アップグレードが成功裏に完了したことを示してよい。支援構成テーブルからの情報に加えて、対象システムを識別する情報を含めて、遠隔サーバが適切な方策を講じることができるようにしてよい。

特に、遠隔サーバはアップグレードについて対象システムに関連付けられる勘定を請求することができる（ブロック２６０）。例えば、会社のＩＴ部は遠隔サーバを実施するＯＥＭの勘定を保持することができる。他の実施形態においては、アップグレード支払いについて異なる方策が可能であってよい。例えば、幾らかの実施形態においては、個々のエンドユーザが該エンドユーザが望むアップグレードに対する課金を認可するクレジットカード情報を提供してよい。

アップグレードに対する課金に加えて、遠隔サーバは、例えば対象システムの識別に関する情報、達成されたアップグレード、プラットフォーム、構成、画像などの対象システムに関する追加的情報含む、アップグレードに関する情報を記憶してよい。さらに図２に示すように、遠隔サーバは中央データベースにアップグレード情報を通信してよい（ブロック２７０）。

図３を参照すると、本発明の一実施形態による、動的ヒューズプログラミングロジックの一箇所のブロック図が示されている。図３に示すように、回路３００ａは、様々なレジスタ、ロジックゲート、異なるハードウェア機能をイネーブルすべくヒューズのバーニングを制御するコントローラを含んでよい。図３に示すように、回路３００ａはヒューズをバーニングすべくデータ受信するよう連結されている。データは、遠隔サーバから受信されるマイクロコード命令の制御下で回路３００ａに送信されてよい。図３に示すように、入力されるデータは複数のラッチ３１０ａ、ｂ、ｃで受信されてよい。様々な実施形態においては、１ビットラッチを利用して、アップグレードできる各機能についてのデータ受信をしてもよい。図３には例示をし易くするためにこのようなラッチを三つ含むとして示したが、本発明の範囲はこれに限定されないことは理解されるべきである。ラッチ３１０を連結して、例えばプロセッサクロック信号（ＣＰＵ Ｃｌｏｃｋ）などの、入力されるクロック信号でクロックする。入力されるクロック信号はさらに、制御信号を受信するよう連結される制御ラッチ３１５をクロックするのに利用することもできる。特に、制御信号（つまりＲｅａｄｙＴｏＵｐｇｒａｄｅ）を、実行されるマイクロコード命令から受信してもよい。

選択されたヒューズのバーニングを制御すべく、ヒューズバーニングコントローラ３２５が存在してもよい。様々な実施形態においては、コントローラ３２５はヒューズバーニング列を起動する、プログラム可能なロジックであってよい。図３の実施形態においては、コントローラ３２５はリセット信号（つまりＣＰＵ Ｒｅｓｅｔ）および制御信号（つまりＳｔａｒｔＢｕｒｎＳｅｑｕｅｎｃｅ）を受信するよう連結され、ラッチ３１５からのヒューズバーニング列を起動する。さらには、コントローラ３２５は入力されるクロック信号を受信するよう連結する。最後に、図３に示すように、コントローラ３２５は電圧ステータス信号（つまりＶＣＣＩｓＧｏｏｄ）を受信するために連結される。電圧ステータス信号は比較器３２０により出力されてよく、比較器３２０はプロセッサ供給電圧（ＣＰＵ ＶＣＣ）を、例えば参照電圧と比較する。図３に示す実施形態においては、参照電圧（つまりＳｔａｂｌｅ ＶＲＥＦ）は供給電圧の三分の二に略等しくてよい。

制御信号（つまりＳｔａｒｔＢｕｒｎＳｅｑｕｅｎｃｅ）が起動され、およびリセット信号が受信され、電圧ステータス信号がアクティブであるということを仮定した場合、コントローラ３２５は選択されたヒューズをバーニングしてよい。より具体的には、コントローラ３２５は先ず、起動チャージ制御信号（つまりＳｔａｒｔＣｈａｒｇｅＰｕｍｐ）を設定してよい。そして、これに続くクロックサイクル（例えばＣＰＵ Ｃｌｏｃｋの１マイクロセカンド（μｓ）サイクル）において、コントローラ３２５は選択された機能について複数の重複ヒューズの各々について信号を設定してよい。図３に示すように、送られた信号は複数ライン上に発行してよい（つまりＢｕｒｎＦｕｓｅ「３：０」）。バーニング列がなされると、バーニング列完了制御信号（つまりＢｕｒｎＳｅｑＤｏｎｅ）が生成されてよい。そしてコントローラ３２５は、その全ての出力をゼロに設定する。

今度は図４に着目すると、本発明の一実施形態による動的ヒューズプログラミングロジックの第二の箇所が示されている。図４に示すように、回路３００ｂは回路３００ａと同じロジックの一部であってよい。

図４に示すように、回路３００ｂは起動されるとヒューズバーニング電圧を生成するチャージポンプ３３０を含む。チャージポンプ３３０は供給電圧（ＣＰＵ ＶＣＣ）およびＡＮＤゲート３２８からの出力であるイネーブル信号（ＰｕｍｐＶｏｌｔａｇｅ）を受信するよう連結される。図４に示すように、ＡＮＤゲート３２８は、チャージ制御信号および反転バーニング列完了制御信号を（つまりインバータから３２７）受信するよう連結される。故に、ＡＮＤゲート３２８からの出力がロジック「１」であり、供給電力が存在する場合、チャージポンプ３３０はチャージポンプ電圧信号（ＣｈａｒｇｅＰｕｍｐＯｕｔ）を生成して、ヒューズバーニング電圧を第一のヒューズバンク４０および第二のヒューズバンク３４５へ提供してよい。図４の実施形態にはプロセッサ供給電圧（ＣＰＵ ＶＣＣ）から電源電圧を受け取るように示したが、他の実施形態においては補助的電圧供給を利用してもよい。さらには、ポンプアップされた電圧をチャージポンプ３３０を介して利用する代わりに、専用プラットフォーム電源電圧を利用することもできる。もしくは他の実施形態においては、名目供給電圧（ＣＰＵ ＶＣＣ）を利用することもできる。

図４の実施形態には二つのヒューズバンクだけを含むように示したが、本発明の範囲がそれに限定されないことは理解されるべきであり、任意の実施形態では任意の所望数のヒューズバンクが存在してよい。様々な実施形態においては、各ヒューズバンクは、各ヒューズに別個のバーニング制御がなされる、重複ヒューズのバンクであってよい（例えば、四つの重複ヒューズ）。さらに、様々な実施形態においては、ヒューズバンクは各潜在的機能に存在して、イネーブルあるいはアップグレードされてよい。しかし、他の構成も可能であることは理解されるべきである。

任意のヒューズバンクにおいて選択されたヒューズをバーニングすべく、バンク内の選択されたヒューズに対応するラインに入力される信号は論理高レベルであってよい。特に、図４に示すように、ロジックゲート３３５および３３７（ＡＮＤゲート）はヒューズバンク３４０、３４５のデータ入力にそれぞれ連結される。ＡＮＤゲート３３５、３３７は、ラッチ３１０からの機能バーニング選択信号（ＦｅａｔｕｒｅＢｕｒｎＲｅｇｉｓｔｅｒ［Ｘ］）およびコントローラ３２５からのヒューズバーニング信号を受信するように連結される。論理高レベルがＡＮＤゲート３３５、３３７のいずれかから出力され、チャージポンプ電圧信号が存在する場合、適切なヒューズがバーニングされる。このようにして、任意のハードウェア機能に対応する複数の重複ヒューズが命令（マイクロコード命令）の制御下に設定されてよい。

さらに図３、４を参照すると、回路３００ａ、３００ｂをさらに利用して、ヒューズバーニングが適切に実行されたことを検証してよい。故に、ヒューズ検証コントローラ３６０が存在してもよい（回路３００ａ中に）。図３に示すように、コントローラ３６０は、入力されるクロック信号、電圧ステータス信号、およびリセット信号を含む、様々な入力を受信するよう連結されてよい。さらに、コントローラ３６０はコントローラ３２５からバーニング列完了信号を受信するよう連結されてよい。様々な実施形態においては、コントローラ３６０は、バーニング列の完了を示すよう、アクティブな高いバーニング列完了信号を受信するまでは、全ての自身の出力をゼロに設定したままアイドル状態であってよい。

このようなとき、一実施形態においては、コントローラ３６０は以下の機能を遂行してもよい。つまり、先ず、コントローラ３６０はヒューズ感知信号（Ｆｕｓｅ Ｓｅｎｓｅ）を論理高に設定してよい。そして、ヒューズロード信号（Ｆｕｓｅ Ｌｏａｄ）をアクティブ高値に設定してよい。ヒューズ感知信号がアクティブなとき、ヒューズバンク３４０、３４５は各バンク内の個々のヒューズ各々のバーニングステータスを示す出力を生成する。これら出力信号はその後、今度はＯＲゲート３４８、３４９を介して論理和をとられて、その出力はそれぞれラッチ３５０、３５２と連結される。これらラッチはヒューズロード信号によりイネーブルされ、該ラッチはヒューズ出力信号を出力する（ＦｕｓｅＯｕｔ［ｘ］）。

図４に示すように、インバータ３５４を介して、ヒューズ出力信号は反転されて、「全ヒューズ信号」（ＡｌｌＦｕｓｅ＝Ｚｅｒｏ）、および「いずれのヒューズ信号も非反転信号」（ＡｎｙＦｕｓｅ＝Ｏｎｅ）を形成する。図３を参照すると、ＡＮＤゲート３５６（つまり、ＡＮＤゲート）は、ヒューズコントローラ３６０が生成する検証列完了信号（ＶｅｒｆｙＳｅｑｕｅｎｃｅＤｏｎｅ）とともに、任意のヒューズ信号を受信するよう連結される。これら信号の両方が論理高に設定されると、ＡＮＤゲート３５６はラッチ３７４ａ、ｂ、ｃそれぞれに提供される高出力を生成し、各ラッチ３７４ａ、ｂ、ｃは各ハードウェア機能に対応している。ラッチ３７４のうちの一つが機能有効ビット（ＦｅａｔｕｒｅＶａｌｉｄＢｉｔｓ）を生成する場合、これは対応するハードウェア機能のヒューズのプログラミングが成功していることを示す。

対して、全てのヒューズ信号が論理高レベルであり、コントローラ３６０からの検証列完了信号も論理高である場合、ＡＮＤゲート３６８は出力高信号を生成して値を、それぞれが任意の機能に対応しているラッチ３７０ａ、ｂ、ｃのうちの対応するものに提供してもよい。これらラッチ３７０の一つが論理高信号を出力するとき、これは、任意のハードウェア機能のプログラムを試みた際にヒューズバーニングエラーが生じたことを示す。最後に、ＯＲゲート３６４は電源失敗信号を受信すべく連結されてよい。特に、二つのこのような電源失敗信号が（つまり、ヒューズバーニングコントローラ３２５からのＶＣＣＦａｉｌＢｅｆｏｒｅＢｕｒｎ信号と、ヒューズ検証コントローラ３６０からのＶＣＣＦａｉｌＢｅｆｏｒｅＤｏｎｅ信号）、ＯＲゲート３６４の入力に提供されてよい。これら信号のいずれかが高に設定され、供給電圧失敗を示すと、ＯＲゲート３６４は論理高信号を出力する。これにより、今度はラッチ３７２が電力失敗エラーを示すよう設定される。

様々な実施形態においては、機能有効ビット（例えば、ラッチ３７４ａ、ｂ、ｃの一つを介して）を利用して、支援構成テーブル１１０の機能イネーブルＭＳＲ１１８を設定することができる。例えば、機能Ｂのヒューズバンクのプログラミングが成功したとすると、機能イネーブルＭＳＲ１１８内の機能Ｂに対応するビットを設定することができる。すると今度は、対象システム１００が遠隔サーバ１０に対して、選択された機能のプログラミングが成功したことを示すメッセージを送ってよい。

故に、様々な実施形態においては、ハードウェア機能は製造時点でハードウェアコンポーネント内に実施されてよく、ユーザは販売後に一以上のハードウェア機能の利用を選択することができる。本発明の様々な実施形態によると、機能をイネーブルにしその機能を対象システムで検証する際のセーフ／安全な様式が提供されてよい。このようなアップグレードはＯＥＭ、ＩＴ顧客、およびエンドユーザに付加価値を提供することができる。さらに、ハードウェア製造業者、ＯＥＭなどは、既にハードウェアに実施されているが販売時点ではイネーブルではない、より最近の機能アップグレードにより、追加的な収入を生むことができる。さらに、ハードウェア機能をアップグレードするエンドユーザは、彼等のアップグレードプランをさらに速いエンドプラットフォームにおいて速めることができ、ＰＣ交換サイクルを減らすことができる。

さらに、ユーザは購入時点で高額を払わなくてよくなり、かつ後で提供されるハードウェア機能をアップグレードすることができる柔軟性および可能性を留保することができる。例えば、ある種のアプリケーション／用途モデルがより成熟したそのときに、ユーザは一以上のハードウェアコンポーネントをアップグレードしてさらなるハードウェア機能を提供する選択をすることができる。

様々な実施形態をコンピュータプログラムに実施できる。こういう訳なので、これら実施形態は、実施形態を実行するようシステムをプログラムするのに利用することのできる命令を記憶する記憶媒体に記憶することができる。記憶媒体は、それらに限定されるわけではないが、フロッピー（登録商標）ディスク、光ディスク、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭｓ）、書き換え型コンパクトディスク（ＣＤ−ＲＷｓ）、光磁気ディスクを含む任意の種類のディスク、読み取り専用メモリ（ＲＯＭｓ）などの半導体デバイス、動的ＲＡＭｓ（ＤＲＡＭｓ）などのランダムアクセスメモリ（ＲＡＭｓ）、消去可能ＰＲＯＭ（ＥＰＲＯＭｓ）、電気的消去可能なＰＲＯＭ（ＥＥＰＲＯＭｓ）、フラッシュメモリ、磁気あるいは光カード、電子命令を記憶するのに適した任意の種類の媒体を含む。同様に、実施形態は、プログラム可能な制御デバイスにより実行されるソフトウェアモジュールとして実施されてもよい（コンピュータプロセッサあるいはカスタム設計状態マシンなど）。

実施形態はそれぞれ異なるシステムにおいて実施されてもよい。例えば、幾らかの実施形態はマルチプロセッサシステムで実施されてもよい（例えば共通システムインタフェース（ＣＳＩ）システムなどのポイントツーポイントバスシステム）。図５を参照すると、本発明の一実施形態によるマルチプロセッサシステムのブロック図が示されている。図５に示すように、マルチプロセッサシステム４００はポイントツーポイントバスシステムであり、ポイントツーポイント相互接続４５０を介して連結された第一のプロセッサ４７０と第二のプロセッサ４８０とを含む。図５に示すように、プロセッサ４７０、４８０の各々が複数のマルチコアプロセッサであり、第一および第二のプロセッサコアを含んでよい（プロセッサコア４７４ａ、ｂおよびプロセッサコア４８４ａ、ｂ）。第一のプロセッサ４７０はさらに、メモリコントローラハブ（ＭＣＨ）４７２およびポイントツーポイント（Ｐ−Ｐ）インタフェース４７６、４７８を含む。同様に、第二のプロセッサ４８０は、ＭＣＨ４８２、Ｐ−Ｐインタフェース４８６、４８８を含む。図５に示すように、ＭＣＨ４７２、４８２は前述のプロセッサ同士をメモリそれぞれへ連結し、メモリとはつまりメモリ４３２およびメモリ４３４であり、これらはプロセッサそれぞれにローカルに取り付けられた主メモリの箇所であってよい。

図５に示すように、プロセッサ４７０は、本発明の一実施形態によるとテーブル４７３を含んでよい。より具体的には、テーブル４７３は、様々なハードウェア機能およびそれらのアップグレードステータスを識別する複数のＭＳＲを含む支援構成テーブルであってよい。さらに、プロセッサ４７０は、本発明の一実施形態により再構成可能なロジック４７５を含んでよい。再構築可能なロジック４７５は遠隔サーバから命令を受信して、システム内に命令による一以上のハードウェア機能をイネーブルするのに利用されてよい。図５にさらに示すように、プロセッサ４８０は同様に、本発明の一実施形態によるテーブル４８３および再構成可能なロジック４８５を含んでよい。

第一のプロセッサ４７０および第二のプロセッサ４８０は、それぞれチップセット４９０にＰ−Ｐインタフェース４５２、４５４を介して連結されてよい。図５に示すように、チップセット４９０はＰ−Ｐインタフェース４９４、４９８を含む。さらにチップセット４９０は、チップセット４９０と高性能グラフィックエンジン４３８とを連結するインタフェース４９２を含む。一実施形態においては、高度グラフィックスポート（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ））バス４３９を利用してグラフィックエンジン４３８をチップセット４９０に連結してよい。ＡＧＰバス４３９は１９９８年５月４日にカリフォルニア州Ｓａｎｔａ ＣｌａｒａのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから発行されたＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ， Ｒｅｖｉｓｉｏｎ２．０に準拠していてもよい。もしくは、ポイントツーポイント相互接続４３９がこれらコンポーネントを連結してもよい。

また、チップセット４９０が第一のバス４１６にインタフェース４９６を介して連結されてもよい。一実施形態においては、第一のバス４１６は、１９９５年６月付のＰＣＩ Ｌｏｃａｌ Ｂｕｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ， Ｐｒｏｄｕｃｔｉｏｎ Ｖｅｒｓｉｏｎ， Ｒｅｖｉｓｉｏｎ２．１が定義するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス、あるいはＰＣＩ Ｅｘｐｒｅｓｓバスあるいは別の第三世代Ｉ／Ｏ相互接続バスなどのバスであってよいが、本発明の範囲はそれに限定されない。

図５に示すように、様々な入力／出力（Ｉ／Ｏ）デバイス４１４を、第一のバス４１６を第二のバス４２０に連結するバスブリッジ４１８とともに、第一のバス４１６に連結することができる。一実施形態においては、第二のバス４２０は低ピンカウント（ＬＰＣ）バスであってよい。一実施形態においては、様々なデバイスを、キーボード／マウス４２２、通信デバイス４２６、コード４３０を含むことのできるデータ記憶部４２８を含む、第二のバス４２０に連結することができる。通信デバイス４２６はネットワークインタフェースカード、無線インタフェースなどを含み、システム４００に遠隔システムと通信させてアップグレード命令を受信させてよい。さらに、音声Ｉ／Ｏ４２４は第二のバス４２０に連結されてよい。

ここでは限定数の実施形態の観点から本発明を記載したが、当業者であればそこから幾らもの変形例および変更例を理解するだろう。添付の請求項はそのような変形例および変更例全てを、本発明の真の精神および範囲に含めるよう網羅することを意図している。

本発明の一実施形態によりハードウェアアップグレードを行うシステムのブロック図である。

本発明の一実施形態による方法のフロー図である。

本発明の一実施形態による、動的ヒューズプログラミング回路の第一箇所のブロック図である。

図３の動的ヒューズプログラミング回路の第二箇所のブロック図である。

本発明の一実施形態によるシステムのブロック図である。

Claims (20)

1. システムのハードウェアコンポーネントが有する支援構成テーブルであって、前記システムの複数のハードウェア回路のうちの１つのハードウェア回路についてのシステム支援ステータスに関する情報を記憶する第一のステータスレジスタであって、前記システムのベンダにより、前記ベンダが構成したままの前記システムが前記ハードウェア回路を支援することができるかを承認する目的で設定される第一のステータスレジスタと、前記ハードウェア回路についての機能イネーブルステータスに関する情報を記憶する第二のステータスレジスタであって、前記ハードウェアコンポーネントの製造者により、前記ハードウェア回路に対応する前記ハードウェアコンポーネント内の回路の存在を示す目的で設定される第二のステータスレジスタとを含む前記支援構成テーブルにアクセスすることによって、前記システムが前記ハードウェア回路のアップグレードに互換性を持つか判断する工程と、
   前記システムが互換性を持つ場合に前記ハードウェア回路をアップグレードする遠隔システムからの複数の命令を受信する工程と、
   前記ハードウェア回路を前記複数の命令に基づきプログラミングする工程と、
   を含む方法。
2. 前記システムが互換性を持つと判断された後に、前記システムの暗号鍵を前記遠隔システムへ送る工程と、
   前記遠隔システムから、複数の暗号化命令を受信する工程と、をさらに含み、
   前記複数の命令はマイクロコードを含む、請求項１に記載の方法。
3. 前記ハードウェア回路をプログラミングする工程は、前記ハードウェア回路を、前記マイクロコードの命令により行われる動的ヒューズにより永久的にプログラミングすることを含む、請求項２に記載の方法。
4. 前記動的ヒューズは、経路を前記アップグレードに対応する前記ハードウェア回路にイネーブルすることを含む、請求項３に記載の方法。
5. 前記遠隔システムから検証コードを受信する工程と、
   受信した前記検証コードを実行することができることを確認する工程と、
   確認した結果を前記遠隔システムに送信する工程と、
   をさらに含む請求項１から４のいずれか１項に記載の方法。
6. システムであって、ハードウェアコンポーネントを含み、
   前記ハードウェアコンポーネントは、システムの販売後にイネーブルされる、前記ハードウェアコンポーネントが含む一以上のハードウェア機能のステータスに関する情報を記憶する機能テーブルを持ち、
   前記機能テーブルは、
   前記ハードウェア機能のうちの１つについてのシステム支援ステータスに関する情報を記憶する第一のステータスレジスタであって、前記システムのベンダにより、前記ベンダが構成したままの前記システムが前記ハードウェア機能を支援することができるかを承認する目的で設定される第一のステータスレジスタと、
   前記ハードウェア機能についての機能イネーブルステータスに関する情報を記憶する第二のステータスレジスタであって、前記ハードウェアコンポーネントの製造者により、前記ハードウェア機能に対応する前記ハードウェアコンポーネント内の回路の存在を示す目的で設定される第二のステータスレジスタと、を含み、
   前記システムは、前記機能テーブルにアクセスすることによって、前記システムが前記ハードウェアコンポーネントのアップグレードに互換性を持つと判断した場合に、前記ハードウェアコンポーネントをアップグレードする遠隔システムからの複数の命令を受信して、前記ハードウェアコンポーネントを前記複数の命令に基づきプログラミングする
   システム。
7. 前記機能テーブルは、前記ハードウェア機能についてのアップグレードされたステータスに関する情報を記憶する第三のステータスレジスタを含み、前記第三のステータスレジスタの少なくとも一箇所は、前記ハードウェア機能のうちの一つについてのイネーブルが成功した際に設定される、請求項６に記載のシステム。
8. 遠隔発信元から受信したマイクロコードにより前記ハードウェア機能の少なくとも一つをイネーブルするために前記ハードウェアコンポーネントをプログラムする動的ヒューズプログラミングロジックをさらに含む、請求項６または７に記載のシステム。
9. 前記動的ヒューズプログラミングロジックは、前記マイクロコードに基づき前記ハードウェア機能の前記少なくとも一つをイネーブルするために少なくとも一つのヒューズをバーニングするヒューズバーニングコントローラと、前記バーニングを検証するためにヒューズ検証コントローラとを含む、請求項８に記載のシステム。
10. 前記ハードウェアコンポーネントはプロセッサを含み、前記システムは、前記ハードウェア機能の前記少なくとも一つを実行する目的で、前記プロセッサの一ブロックをさらに含み、前記ブロックが前記少なくとも一つのヒューズを介してプロセッサコアに連結されている、請求項９に記載のシステム。
11. 前記ハードウェアコンポーネントは前記ハードウェア機能を含み、前記ハードウェア機能は前記動的ヒューズプログラミングロジックによりプログラミングされる場合以外にはイネーブルされない、請求項８に記載のシステム。
12. 前記機能テーブルは、前記ハードウェアコンポーネントの複数のレジスタ内で利用可能なステータス情報用の中央記憶装置を含み、前記機能テーブルは外部システムに対して透過的である、請求項６から１１のいずれか１項に記載のシステム。
13. コンピュータに、
    対象システムが前記対象システムのハードウェアコンポーネントをアップグレードする資格があるかを、前記ハードウェアコンポーネントが有する複数のハードウェア機能のうちの１つのハードウェア機能についてのシステム支援ステータスに関する情報を記憶する第一のステータスレジスタであって、前記対象システムのベンダにより、前記ベンダが構成したままの前記対象システムが前記ハードウェア機能を支援することができるかを承認する目的で設定される第一のステータスレジスタと、前記ハードウェア機能についての機能イネーブルステータスに関する情報を記憶する第二のステータスレジスタであって、前記対象システムのハードウェアコンポーネントの製造者により、前記ハードウェア機能に対応する前記ハードウェアコンポーネント内の回路の存在を示す目的で設定される第二のステータスレジスタとを含む機能テーブルの分析により判断する手順と、
    前記対象システムへ複数のアップグレード命令を準備および送信する手順と、を実行させるためのプログラムであって、
    前記複数のアップグレード命令は前記対象システムに対して、前記アップグレードをイネーブルするよう前記ハードウェアコンポーネントをプログラミングさせる、プログラム。
14. 前記コンピュータに、
    前記対象システムに、前記対象システムに対する前記アップグレードが成功したことを確かめる複数の検証命令を提供する手順
    をさらに実行させるための請求項１３に記載のプログラム。
15. 前記コンピュータに、
    前記アップグレードが成功したと確かめた際に、前記アップグレードについて前記対象システムに関連付けられた勘定を請求する手順と、
    前記ハードウェアコンポーネントの製造者によりアクセス可能な中央データベースに、前記対象システムおよび前記アップグレードに関する情報を記録する手順と、をさらに実行させるための請求項１４に記載のプログラム。
16. 前記複数のアップグレード命令を準備および送信する手順は、前記対象システムから受信した暗号鍵により暗号化された様式で準備および送信する請求項１３に記載のプログラム。
17. システムであって、
    前記システムの販売時点でイネーブルでないハードウェア機能を含むプロセッサと、
    前記ハードウェア機能に連結され、前記ハードウェア機能を販売後にイネーブルにするプログラマと、
    前記システムを遠隔システムに接続するインタフェースと、を含み、
    前記インタフェースは、前記遠隔システムから前記システムへの、前記システムの構成に関する情報をリクエストする第１通信、および前記システムが前記ハードウェア機能を実行可能であることを示すべく、前記第１通信に応じて前記システムの機能テーブルから取得された情報を、前記システムから前記遠隔システムへと提供するための第２通信を実現し、
    前記機能テーブルは、前記ハードウェア機能のうちの１つについてのシステム支援ステータスに関する情報を記憶する第一のステータスレジスタであって、前記システムのベンダにより、前記ベンダが構成したままの前記システムが前記ハードウェア機能を支援することができるかを承認する目的で設定される第一のステータスレジスタと、前記ハードウェア機能についての機能イネーブルステータスに関する情報を記憶する第二のステータスレジスタであって、前記プロセッサの製造者により、前記ハードウェア機能に対応する前記プロセッサ内の回路の存在を示す目的で設定される第二のステータスレジスタとを含む、システム。
18. 前記プログラマは、前記遠隔システムから受信した複数の命令によって前記ハードウェア機能をイネーブルにする動的ヒューズプログラミングロジックを含む、請求項１７に記載のシステム。
19. 前記動的ヒューズプログラミングロジックは、前記ハードウェア機能をプロセッサコアに連結すべく少なくとも一つのヒューズをバーニングするコントローラを含む、請求項１８に記載のシステム。
20. 前記ハードウェア機能は、安全機能を含む、請求項１７から１９のいずれか１項に記載のシステム。

Images