(57)【要約】【課題】  ブランド化のリソースを効率的に配置し、かつそれらをソフトウェア製品全体にわたって適用することに使用するためのブランド化フレームワークを提供する。【解決手段】  集中的に記憶されたリソースファイルがブランド化のリソースを含み、かつそれらに割り当てられたネーム空間を有する。フレームワークのブランド化エンジンが選択されたネーム空間の関数としてリソースファイルのグループを呼び出し、かつ呼び出されたグループを、ソフトウェア製品にインストールされるべきブランド化のリソースについて検索する。一実施形態では、ブランド化エンジンは呼び出されたリソースファイルを、リソースファイルに組み込まれたメタデータに基づいて検索する。【選択図】  図１
2005078649.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア製品をブランド化するコンピュータ化の方法であって、
複数のリソースファイルの各々にネーム空間を割り当てるステップであって、そこでは、前記リソースファイルが各々１つまたは複数のブランド化のリソースを含むステップと、
前記割り当てられたネーム空間に従って前記リソースファイルをグループ化するステップ、
選択されたネーム空間の関数としてリソースファイルのグループを呼び出すためにインターフェースを実行するステップと、
前記呼び出されたグループを、前記ソフトウェア製品にインストールされるべき１つまたは複数の前記ブランド化のリソースについて検索するステップと
を含むことを特徴とする方法。
【請求項２】
前記ネーム空間を割り当てるステップが、特定のブランドに対応する前記リソースファイル内に含まれる前記ブランド化のリソースを識別するステップを含むことを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項３】
前記ブランド化のリソースのうちの少なくとも１つが前記ソフトウェア製品に付随するイメージを含むことを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項４】
中に含まれる前記ブランド化のリソースを識別するメタデータを前記リソースファイルの各々に組み込むステップをさらに含み、リソースファイルの前記呼び出されたグループが、前記ソフトウェア製品にインストールされるべき前記ブランド化のリソースについて前記組み込まれたメタデータに基づいて検索されることを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項５】
前記リソースファイルの各々がそこに付随するブランド化のマニフェストを有し、前記付随するマニフェストを備えた前記リソースファイルの各々に含まれる前記ブランド化のリソースを識別するステップをさらに含むことを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項６】
前記ブランド化のリソースを識別するステップが、前記リソースファイルに含まれる前記ブランド化のリソースの各々について、前記付随するブランド化のマニフェストでリソースタイプを示すステップを含むことを特徴とする請求項５に記載のコンピュータ化の方法。
【請求項７】
前記リソースファイルのうちの少なくとも１つに１つまたは複数のブランド化のリソースを追加するステップ、およびそこに付随する前記ブランド化のマニフェストを更新するステップをさらに含むことを特徴とする請求項５に記載のコンピュータ化の方法。
【請求項８】
前記インターフェースがアプリケーションプログラミングインターフェースであることを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項９】
前記ソフトウェア製品がコンポーネント内に編成された複数のバイナリファイルを含み、前記コンポーネントの各々が、前記コンポーネントを識別し、かつ前記コンポーネントの１つまたは複数の従属性を特定するためのそこに付随するコンポーネントマニフェストを有し、少なくとも１つの選択されたコンポーネントから前記インターフェースへの従属性を特定することで前記選択されたコンポーネントに関連してインストールされるべき前記ブランド化のリソースにアクセスするステップをさらに含むことを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項１０】
前記選択されたコンポーネントから前記インターフェースへの前記従属性を特定するステップが前記選択されたネーム空間を特定するステップを含み、前記選択されたネーム空間が特定のブランドに対応することを特徴とする請求項９に記載のコンピュータ化の方法。
【請求項１１】
前記選択されたネーム空間を特定するステップが、前記ソフトウェア製品の前記ブランド化を変更するための異なる特定のブランドに対応する別のネーム空間を特定するステップを含むことを特徴とする請求項１０に記載のコンピュータ化の方法。
【請求項１２】
１つまたは複数のコンピュータ読み取り可能な媒体が、請求項１に記載のコンピュータ化の方法を実行するためのコンピュータで実行可能な命令を有することを特徴とする請求項１に記載のコンピュータ化の方法。
【請求項１３】
１つまたは複数のコンピュータ読み取り可能な媒体であって、
複数の集中的に記憶されたリソースファイルを含み、前記リソースファイルが各々１つまたは複数のブランド化のリソースを含み、かつそれに割り当てられたネーム空間を有し、前記リソースファイルがさらに前記割り当てられたネーム空間に従ってグループ化され、
選択されたネーム空間の関数としてリソースファイルのグループを呼び出し、かつリソースファイルの前記呼び出されたグループを、前記ソフトウェア製品にインストールされるべき１つまたは複数の前記ブランド化のリソースについて検索するためのブランド化エンジンを含む媒体。
【請求項１４】
前記ブランド化のリソースのうちの少なくとも１つが前記ソフトウェア製品に付随するイメージを含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。
【請求項１５】
前記ブランド化のリソースのうちの少なくとも１つが前記ソフトウェア製品を識別する文字列を含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。
【請求項１６】
前記リソースファイルの各々が、中に含まれる前記ブランド化のリソースを識別する組み込みメタデータを含み、かつ前記ブランド化エンジンが、前記ソフトウェア製品にインストールされるべきブランド化のリソースについて前記組み込みメタデータに基づいてリソースファイルの前記呼び出されたグループを検索することを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。
【請求項１７】
前記リソースファイルの各々が、中に含まれる前記ブランド化のリソースを識別する付随のブランド化のマニフェストを有することを特徴とする請求項１６に記載のコンピュータ読み取り可能な媒体。
【請求項１８】
前記ブランド化のマニフェストが、前記リソースファイルに含まれる前記ブランド化のリソースの各々についてリソースタイプを示すためのデータフィールドを含むことを特徴とする請求項１６に記載のコンピュータ読み取り可能な媒体。
【請求項１９】
前記ブランド化エンジンがアプリケーションプログラミングインターフェースを含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。
【請求項２０】
前記リソースファイルの各々がダイナミックリンクライブラリを含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェアアーキテクチャの分野に関する。特に、本発明の実施形態はオペレーティングシステムを含むソフトウェア製品のためのブランド化のフレームワークに関する。
【背景技術】
【０００２】
ソフトウェア製品が大きくかつ複雑になるにつれて、既にあるソフトウェア製品を基にして新製品を作り出すことおよび市場と競合ニーズによって要求される通りにこれらの製品を補修することが次第に困難になる。オペレーティングシステム（ＯＳ）は比較的大きく、複雑なソフトウェア製品の範例である。
【０００３】
オペレーティングシステムはコンピュータまたはそれが属している装置のリソースを管理し、スケジュールし、かつ様々なタスクを達成するためにアプリケーションによって使用されることが可能な様々な機能モジュールとインターフェースを供給する。従来式のコンピュータは、概して、コンピュータが実行している時のその様々なアスペクトを管理するためにそのオペレーティングシステムを実行する。例えば、オペレーティングシステムは通常では記憶装置ならびに入力および／または出力装置へのアクセスの管理、および１つまたは複数の追加的なアプリケーションの実行の制御の責任を負う。普通では、導入はコンピュータがオペレーティングシステムを実行する前に（例えば、ＣＤＲＯＭのような配布媒体からコンピュータのハードディスク上に複数のファイルをコピーすることによって）生じる。
【０００４】
従来式のオペレーティングシステムは命令および／またはデータ用の多数の（例えば数千の）ファイルを有する。コンピュータによって実行されるとき、そのような命令はオペレーティングシステムの機能を供給する。通常、多くのオペレーティングシステムのファイル全体にわたってブランド化情報が現れてユーザに一貫した専門的な経験知識を供給する。例えば、オペレーティングシステムは極めて頻繁にユーザインターフェースを提示し、そこにはロゴ、ビットマップ画像などが現れる。普通、ブランド化の変更は製品開発の主要段階で為され、オペレーティングシステムのような製品がリリースされた後でさえ存続する。これらの段階は内部生産サイクル、ベータ版（外部）リリース、および最終小売製品を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
オペレーティングシステムのような大きくて複雑なソフトウェア全体にわたって一貫したブランド認識を手作業で適用する処理は複雑で時間を消費し、かつ間違いを起こし易い。これは、少なくとも部分的には、製品内のブランド化されたすべての単一領域を見つけ出して置き換える困難なタスクのせいである。手作業のブランド化処理は特に問題が多く、なぜならば異なるバージョンの製品がリリースされるとき、既にある製品を土台にして新製品が作り出されるときなどの製品サイクルの中でブランド化の変更が為される度に毎回それが繰り返されなければならないからである。ブランド化は至る所に存在することが望まれ、したがって、変更を行ない、変更を試験し、かつブランド化のバグを修正するための従来式の処理は大きなソフトウェア製品に関すると何千時間も必要とする可能性がある。
【０００６】
製品が開発されて更新されるとき、ブランド化情報が現れると考え得る領域のすべてが適切に表示されているかを知ることは極めて困難である。目に見えるブランド化の不一致を伴う製品は極めて望ましくない。
【０００７】
したがって、ブランド化のフレームワークはこれらおよびその他の欠点の１つまたは複数に対処すること、および中でも改善されたオペレーティングシステムとその他のソフトウェア製品の構築を可能にすることを望まれる。
【課題を解決するための手段】
【０００８】
本発明の実施形態は、オペレーティングシステムのようなソフトウェア製品にブランド化要素が加えられる処理を単純化することによって先行技術の１つまたは複数の欠陥を克服する。本発明は、とりわけ、製品のブランド化のすべてのアスペクトを扱うための完全に新しい方式を提供する。例えば、本発明はすべてのブランド化情報を集中させ、その結果、どのような所定のソフトウェア製品についても全体にわたって無数の変更を行なうことをせずに、１つの場所で１つの変更を行なうことによってブランド化の変更が加えられることを可能にする。さらに、本発明の態様は独自のブランド化で製品をカストマイズするライセンス権を購入したサードパーティに役立つ。
【０００９】
本発明の少なくとも１つの実施形態はブランド化情報を単一のブランド化コンポーネントにカプセル化し、それがコアのオペレーティングシステムの符号からブランド化を分離する。本発明のさらなる態様は、ソフトウェア製品にブランド化要素を加えるためのコンポーネント化されたアーキテクチャを活用する。さらに、ここに述べられる本発明の特徴は現在利用可能な技術よりも手間がかからず、実施することが容易であること、ならびに経済的に実現可能であり、商業的に実用的であることである。
【００１０】
簡単に述べると、本発明の態様を具現化するコンピュータを使用した方法はソフトウェア製品をブランド化する用途のためにある。本方法は複数のリソースファイルの各々にネーム空間を割り当てるステップを含む。リソースファイルは各々１つまたは複数のブランド化のリソースを含む。本方法はまた、割り当てられたネーム空間に従ってリソースファイルをグループ分けするステップ、およびリソースファイルのグループを選択されたネーム空間の関数として呼び出すためのインターフェースを実行するステップも含む。呼び出されたリソースファイルのグループはソフトウェア製品にインストールされるべき１つまたは複数のブランド化のリソースを検索される。
【００１１】
本発明のまた別の実施形態は、集中的に記憶された複数のリソースファイルとブランド化エンジンを有するコンピュータ読み出し可能な媒体に関する。リソースファイルは各々１つまたは複数のブランド化のリソースを含み、それに割り当てられたネーム空間を有する。リソースファイルは割り当てられたネーム空間に従ってグループ分けされる。ブランド化エンジンはリソースファイルのグループを選択されたネーム空間の関数として呼び出し、呼び出されたリソースファイルを、ソフトウェア製品にインストールされるべき１つまたは複数のブランド化のリソースについて検索する。
【００１２】
ソフトウェア製品をブランド化するさらに別の方法は、複数のリソースファイルの各々にネーム空間を割り当てるステップおよびリソースファイルに含まれるブランド化のリソースを識別するメタデータをリソースファイルの各々の中に組み込むステップを含む。本方法はまた、リソースファイルのうちの少なくとも１つを選択されたネーム空間の関数として呼び出すためにインターフェースを実行するステップ、および呼び出されたリソースファイルを、組み込まれたメタデータに基づいて、ソフトウェア製品にインストールされるべき１つまたは複数のブランド化のリソースについて検索するステップを含む。
【００１３】
ブランド化の方法を実行するためのコンピュータで実行可能な命令を有するコンピュータ読み出し可能な媒体は本発明のさらなる態様を具現化する。
【００１４】
場合によっては、本発明は様々な他の方法と装置を含む可能性がある。
【００１５】
他の特徴はこれ以降で部分的に明らかになり、部分的に指摘されるであろう。
【発明を実施するための最良の形態】
【００１６】
図面全体を通して、対応する参照文字は対応する部品を示す。
【００１７】
ここで図面を参照すると、図１は本発明の或る実施形態による範例の計算機装置１５０を例示している。計算機装置１５０はオペレーティングシステム１５２のようなソフトウェア製品および１つまたは複数のアプリケーションプログラム１５４を有するように例示されている。オペレーティングシステム１５２は計算機装置１５０にとって基本的なソフトウェア制御プログラムであり、ユーザインターフェースの供給、１つまたは複数のアプリケーション１５４の実行の管理、および様々な入出力（Ｉ／Ｏ）装置へのデータ入力およびそれらからのデータ出力を含む様々な機能を実行する。
【００１８】
この例では、製品名、ロゴ、ビットマップ画像などの形式のブランド化情報はオペレーティングシステム１５２の多くのファイル全体にわたって現れる。普通、ブランド化の変更は製品開発の主要な段階で為され、オペレーティングシステムのような製品がリリースされる後でさえ存続する。これらの段階は内部生産サイクル、ベータ版（外部）リリース、および最終小売製品を含む。本発明の実施形態はブランド化要素がオペレーティングシステム１５２のようなソフトウェア製品に加えられる処理を単純化する。本発明は、とりわけ、製品のブランド化のすべてのアスペクトを扱うための完全に新しい方式を提供する。例えば、本発明はすべてのブランド化情報を集中させ、その結果、どのような所定のソフトウェア製品についても全体にわたって無数の変更を行なうことをせずに、１つの場所で１つの変更を行なうことによってブランド化の変更が加えられることを可能にする。さらに、本発明の態様は独自のブランド化で製品をカストマイズするライセンス権を購入したサードパーティに役立つ。以下でさらに詳細に述べられるであろうが、本発明の実施形態はブランド化情報を単一のブランド化コンポーネントにカプセル化し、それがコアのオペレーティングシステムの符号からブランド化を分離する。本発明のさらなる態様は、ソフトウェア製品にブランド化要素を加えるためのコンポーネント化されたアーキテクチャを活用する。
【００１９】
多数のファイルに加えて、オペレーティングシステム（例えばオペレーティングシステム１５２）は普通ではファイル間の多数の従属性を有する。例えば、多くのファイルは意図される機能が実行されるために１つまたは複数の他のファイルのインストールを必要とする可能性がある。オペレーティングシステムの製造業者はインストール時にそのような従属性を知ることが可能であるけれども、ユーザ、管理者、または他のソフトウェア開発者にとってこれらの従属性について知ることは困難である。ソフトウェア開発者は彼らが関わる特定の（複数）ファイルに他のファイルのどのようなデータもしくは命令が影響を与えるかを知ることが不可能であるので、これは手数のかかることを立証することが可能である。同様に、誤動作するコンピュータを修理している管理者もしくはユーザは従属性の知識を持たずにどのようなファイルがその問題に適用可能であるかを知ることが不可能である。
【００２０】
当業者は従来式のオペレーティングシステムに慣れており、そこではサーバとクライアントのＯＳ製品の両方がバイナリファイルのすべてを含む巨大なセントラルファイルから構築される。概してモノリシックである従来式のオペレーティングシステムのこの範例では、異なる製品にどのようなファイルが含まれているかをセットアップ実行が特定しなければならない。したがって、各々の製品の様々な部分間の関係は理解することが困難である。この情報欠如はオペレーティングシステムの一部をそのライフサイクルの間に補修する能力を妨げる。言い換えると、オペレーティングシステムが一層大きくかつ複雑になるにつれて開発者その他にとってオペレーティングシステムの様々なモジュールおよびファイルのすべてを把握してそれらが一体化して、および個々に適切にはたらくことを確実化することが一層困難になる。
【００２１】
例を挙げると、特定のＯＳ製品は「家庭用」バージョンとして販売される可能性があり、その一方で追加的な特徴を備えた高級製品が「専門的」バージョンとして販売される可能性がある。この例では、家庭用および専門的製品はしばしば、それぞれの製品を構成する多くのバイナリファイル全体にわたって散在した異なるブランド化情報とその他の参照を有するであろう。残念なことに、製品の作成と補修は極めて手間がかかり、かつバイナリファイル間の関係およびこれらブランド化の参照（それらの各々は新製品に関して変更されなければならない）の存在のせいで広範囲にわたる試験を必要とする。
【００２２】
１つまたは複数のバイナリファイルを追加もしくは入れ換えることによる、または多様な人々（例えばユーザ、管理者、オペレーティングシステム開発者以外のソフトウェア開発者など）によるといった多様な方式のいずれによってもオペレーティングシステムは変更される（例えば更新されるか、もしくは補修される）可能性がある。そのような変更が生じると、それはコンピュータ上に存在するファイル間の従属性を識別する難度を上げる。例えば、単一ファイルへの変更は他の従属ファイルに対する変更を必要にする可能性がある。さらに、それは誤動作するコンピュータを修理すること、またはオペレーティングシステムを更新することすら一層困難にする可能性があり、なぜならばユーザもしくは管理者はどのような機能がコンピュータ上にインストールされているか、またはされるべきかを正確に、容易に知ることが不可能であるからである。
【００２３】
例示された図１の実施形態では、アプリケーションプログラム１５４は計算機装置（コンピュータ）１５０上で実行されることが可能な多様なソフトウェアアプリケーションプログラムのうちの１つまたは複数を表わしている。そのようなアプリケーションプログラム１５４の範例は教育プログラム、参照プログラム、生産性プログラム（例えばワードプロセッサ、表計算、データベース）、レクリエーションプログラム、ユーティリティプログラム（例えば通信プログラム）などを含む。アプリケーションプログラム１５４はユーザによって計算機装置１５０上にインストールされる可能性があり、場合によっては計算機装置１５０の製造業者および／またはディストリビュータによってプリインストールされる可能性がある。
【００２４】
図１のオペレーティングシステム１５２は例示された実施形態（図２と図３参照）のコンポーネント＃１からコンポーネント＃Ｎといった複数のコンポーネント１５６にその機能を分ける。各々のコンポーネント１５６はマニフェスト＃１からマニフェスト＃Ｎといった対応するマニフェスト１５８をそれぞれ有する。コンポーネント１５６は１つまたは複数のファイル（またはファイルの識別子）の収集体を含む。ファイルは実行可能ファイル、ダイナミックリンクライブラリ（ＤＬＬ）、またはコンポーネントオブジェクトモジュール（ｃｏｍｐｏｎｅｎｔ  ｏｂｊｅｃｔ  ｍｏｄｕｌｅ）（ＣＯＭ）といったソフトウェア命令を含む可能性がある。ファイルはまた、コンポーネント１５６のうちの１つまたは複数によって使用されるデータを含む可能性がある。或る実施では、オペレーティングシステム１５２の特定の機能に対応するファイル（例えばデータおよび／または命令）が同じコンポーネント１５６内に一体にグループ化される。例えば、ゲームコンポーネント、通信コンポーネント、およびファイルシステムコンポーネントが存在する可能性がある。コンポーネント化に結びつくファイルのグループ化は定常性であることが可能であり、あるいは場合によっては経時的に変わることも可能である。或る範例では、オペレーティングシステム１５２に対する更新は特定のコンポーネント１５６から選択されたファイルが取り外されて他のコンポーネント１５６に追加されることに結びつく可能性がある。
【００２５】
さらに図１を参照すると、各々のマニフェスト１５８はそれに対応するコンポーネント１５６を説明する情報を含む。対応するコンポーネント１５６に関する多様なメタデータのいずれもが各々のマニフェスト１５８内に含まれることが可能である。或る実施では、マニフェスト１５８はそれに対応するコンポーネント１５６、ならびにもしもあれば対応するコンポーネント１５６が従属する他のコンポーネント１５６のバージョンを識別する。範例を挙げると、コンポーネント１５６中の１つまたは複数のファイルを適切に実行するために、別のコンポーネントから由来する１つまたは複数の他のファイル（例えばＤＬＬファイル）が計算機装置１５０上にインストールされる必要がある可能性がある。この範例では、コンポーネント１５６が他のコンポーネントに従属していることをマニフェスト１５８が表示するであろう。
【００２６】
既にあるオペレーティングシステムの複雑さとサイズのせいで、市場または競合ニーズに合致する新製品を作り出すことが次第に困難になりつつある。現在のＯＳは性質的にさらにモノリシックであり、したがって様々な構成部分の間の関係を理解することは困難である可能性がある。この情報欠如は製品のライフサイクルの間にオペレーティングシステムを補修することを極めて困難にする。これらおよびその他の問題を克服するために、本発明の実施形態はオペレーティングシステムをコンポーネント化する。言い換えると、本発明はソフトウェア製品がコンポーネントの収集体として表わされることを可能にする。本発明の態様は、新製品の作成および既にある製品を補修することを容易にするようにコンポーネント化の方式でオペレーティングシステムを構築することに使用されるいくつかの抽象化を含む。抽象化はアプリケーションプログラムを含むいかなるソフトウェア製品、およびいかなるオペレーティングシステムにも応用されることが可能である。
【００２７】
範例となるコンポーネント定義スキーマはいくつかの抽象化、すなわちコンポーネント（アセンブリとも称される）、カテゴリ、機能、パッケージ、製品、およびＳＫＵ（在庫商品識別番号）を導入する。この例では、コンポーネント１５６は配布、補修、および／またはバインディング（ｂｉｎｄｉｎｇ）の再使用可能で共用可能の自己記述原子単位を表わす。コンポーネント自体、およびインストール、補修、および／またはバインディングに使用するためのすべての関連情報（すなわちメタデータ）を必要なリソースに宣言方式で記述することは最も基本的な抽象化である。
【００２８】
本発明の実施形態に関連して下記でさらに詳細に説明されるが、カテゴリオブジェクト１６２（図４参照）はコンポーネント１５６の共通セットをグループ化するためのメカニズムを表わし、機能オブジェクト１６４（図５参照）はコンポーネント１５６および／または機能１６４の合成を表わし、製品オブジェクト１６６（図７参照）を作り出すためのビルディングブロックとして使用され、パッケージオブジェクト１６８（図６参照）はコンポーネント１５６、機能１６４、カテゴリ１６２、および／または他のパッケージ１６８の合成を表わす。例を挙げると、パッケージオブジェクト１６８は管理目的でコンポーネント１５６のセットをグループ化するために使用される。さらに、この実施形態の製品オブジェクト１６６は機能１６４および／またはコンポーネント１５６の最上位の合成を表わし、ＳＫＵオブジェクト１７０（図７参照）は製品１６６に関する出荷のメカニズムを表わす（例えばＳＫＵ１７０は複数の製品１６６を含む可能性がある）。
【００２９】
ここで図８を参照すると、本発明の実施形態によるクライアントバイナリコンポーネント１７４はソフトウェア製品に加えられるブランド化のリソースをインストール、更新、変更、および／または補修するためにブランド化のフレームワークを利用する。ブランド化のフレームワークは単一の場所にブランド化を集約し、それゆえにブランド化情報を含むすべての製品は恩恵を受けるであろう。この例では、ブランド化のバイナリは２つの部分、すなわちブランド化エンジン１７６と複数のブランド化のリソースファイル１７８に分割される。ブランド化エンジン１７６はリソースファイル１７８に含まれるブランド化のリソースにアクセスする。言い換えると、本発明のブランド化フレームワークはソフトウェア製品全体にわたってブランド化の変更を加えるためにブランド化エンジン１７６を利用する。ブランド化フレームワークはまた、例えばＯＳブランドのような一般的なブランドに加えて独自のブランド要素を含む製品を必要とされるときに使用される特注のブランド化コンポーネント（すなわちリソース）の作成もサポートする。例えば、各々のブランド化のリソースファイルはＷｉｎ３２（登録商標）リソースであり、ＤＬＬまたはアプリケーションプログラミングインターフェース（ＡＰＩ）だけに１つまたは複数のブランド化のリソースが備わっている。上述したように、ブランド化のリソースは製品名、ロゴ、ビットマップ画像などを表わすストリングと画像を含む。
【００３０】
ブランド化のリソースファイル１７８はネーム空間に分けられ、それが今度は他方でコンポーネントにグループ化される。本発明の一実施形態では、ブランド化エンジン１７６のバイナリは選択されたネーム空間の関数としてリソースファイルのグループ１７８（すなわちコンポーネント）を呼び出すためのＡＰＩを含む。特定されたネーム空間に基づいてブランド化エンジン１７６が、要求されたブランド化のリソースについてＤＬＬを検索する。都合のよいことに、ブランド化のリソースファイル１７８のすべてがインストールされる必要はない。そうではなく、本発明のこの実施形態はインストールされたコンポーネント１５６によって要求されるブランド化コンポーネントだけをインストールする。
【００３１】
リリースの後に、リリースされる各々の異なるＳＫＵ１７０（例えば高級バージョン、家庭用バージョンなど）についてブランド化の変更が要求されることもやはりあり得る。長期間にわたって、本発明のブランド化フレームワークはブランドが変更されることを必要としないときの同じバイナリファイルですべてのＳＫＵ１７０が補修されることを可能にする。サービスパック、ＱＦＥリリースなどは同様にブランドにこだわらないと理解される。
【００３２】
ＡＰＩインターフェースを含むバイナリにさらに関連すると、ブランド化エンジン１７６は特定されたネーム空間を使用してどのようなＤＬＬ内で必要なリソースを探すべきかを知っている。以下はブランド化エンジン１７６の管理されていないＡＰＩの範例である。
【００３３】
ＩＮＴ  ＢｒａｎｄＬｏａｄＳｔｒｉｎｇ（ＬＰＣＴＳＴＲ  ＮａｍｅＳｐａｃｅ，／／必要なリソースを含むブランド化（サブ）コンポーネントのネーム空間
ＩＮＴ  Ｉｄ，
ＬＰＴＳＴＲ  ｂｕｆｆｅｒ
ＩＮＴ  ｓｉｚｅ）；
Ｗｉｎ３２  ＳＤＫ  ＡＰＩ  ＬｏａｄＳｔｒｉｎｇと同じ挙動。
【００３４】
ＨＡＮＤＬＥ  ＢｒａｎｄＬｏａｄＩｍａｇｅ（ＬＰＣＴＳＴＲ  ＮａｍｅＳｐａｃｅ，／／  必要なリソースを含むブランド化（サブ）コンポーネントのネーム空間
ＬＰＣＴＳＴＲ  ｌｐｓｚＮａｍｅ，／／ロードすべき画像
ＵＩＮＴ  ｕＴｙｐｅ，／／画像タイプ、ここではＩＭＡＧＥ＿ＢＩＴＭＡＰだけがサポートされる
ｉｎｔ  ｃｘＤｅｓｉｒｅｄ，／／所望の幅
ｉｎｔ  ｉｎｔ  ｃｙＤｅｓｉｒｅｄ，／／所望の高さ
ｉｎｔ  ＵＮＩＴ  ｆｕＬｏａｄ／／ロードのオプション
）；
Ｗｉｎ３２  ＳＤＫ  ＡＰＩ  ＬｏａｄＩｍａｇｅと同じ挙動。呼び出し操作者は戻ったオブジェクトを破壊すべきである（ＬｏａｄＩｍａｇｅと同様）。
【００３５】
ＨＢＩＴＭＡＰ  ＢｒａｎｄｉｎｇＬｏａｄＢｉｔｍａｐ（ＬＰＣＴＳＴＲ  ＮａｍｅＳｐａｃｅ，
ＬＰＣＴＳＴＲ  ｌｐｓｚＮａｍｅ）
Ｗｉｎ３２  ＳＤＫ  ＡＰＩ  ＬｏａｄＢｉｔｍａｐと同じ挙動。呼び出し操作者は戻ったオブジェクトを破壊すべきである（ＬｏａｄＢｉｔｍａｐと同様）。
【００３６】
ＨＣＵＲＳＯＲ  ＷＩＮＡＰＩ  ＢｒａｎｄｉｎｇＬｏａｄＣｕｒｓｏｒ（ＬＰＣＴＳＴＲ  ＮａｍｅＳｐａｃｅ，
ＬＰＣＴＳＴＲ  ｌｐｓｚＮａｍｅ）
Ｗｉｎ３２  ＳＤＫ  ＡＰＩ  ＬｏａｄＣｕｒｓｏｒと同じ挙動。呼び出し操作者は戻ったオブジェクトを破壊すべきである（ＬｏａｄＣｕｒｓｏｒと同様）。
【００３７】
ＨＩＣＯＮ  ＷＩＮＡＰＩ  ＢｒａｎｄｉｎｇＬｏａｄＩｃｏｎ（ＬＰＣＴＳＴＲ  ＮａｍｅＳｐａｃｅ，
ＬＰＣＴＳＴＲ  ｌｐｓｚＮａｍｅ）
Ｗｉｎ３２  ＳＤＫ  ＡＰＩ  ＬｏａｄＩｃｏｎと同じ挙動。呼び出し操作者は戻ったオブジェクトを破壊すべきである（ＬｏａｄＩｃｏｎと同様）。
【００３８】
この実施形態では、ブランド化エンジン１７６はブランド化コンポーネント（すなわちリソースＤＬＬ１７８）を見つけ出すためにＮａｍｅＳｐａｃｅパラメータを使用する。例えば、以下のブランド化のリソースファイルを参照されたい。
【００３９】
Ａ“ｈｅｌｐｅｒ  ＡＰＩ，”
ＬＰＴＳＴＲ  ＢｒａｎｄｉｎｇＦｏｒｍａｔＳｔｒｉｎｇ（ＬＰＣＴＳＴＲ  ｉｎＳｔｒｉｎｇ）
は範例のブランド化のリソースファイル１７８を表わしている。ヘルパーＡＰＩは製品名を含むメッセージ用に使用される。呼び出し操作者が送るストリングは製品名に関する置き換え可能なパラメータを含むことが可能である。以下は範例となる製品名パラメータである。
【００４０】
一般的製品名に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＧＥＮＥＲＩＣ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＧＥＮＥＲＩＣ）；
短い製品名に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＳＨＯＲＴ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＳＨＯＲＴ、例えばＷｉｎｄｏｗｓ（登録商標）  ＸＰ（登録商標）のオペレーティングシステム）；
長い製品名に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＬＯＮＧ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＬＯＮＧ、例えばＷｉｎｄｏｗｓ（登録商標）  ＸＰ（登録商標）の家庭版オペレーティングシステム）；
ＳＫＵ名に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＰＲＯＤＵＣＴ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＰＲＯＤＵＣＴ，例えば専門的）；
著作権ストリングに関する％ＷＩＮＤＯＷＳ（登録商標）＿ＣＯＰＹＲＩＧＨＴ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＣＯＰＹＲＩＧＨＴ，例えばＣｏｐｙｒｉｇｈｔ  １９８３〜２００３  Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ）；
Ｍｉｃｒｏｓｏｆｔ社の名称に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＣＯＭＰＡＮＹＮＡＭＥ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＣＯＭＰＡＮＹ，例えばＭｉｃｒｏｓｏｆｔ）；
バージョンの年に関する％ＷＩＮＤＯＷＳ（登録商標）＿ＶＥＲＳＩＯＮ％
（ＩＤＳ＿ＷＩＮＤＯＷＳ（登録商標）＿ＶＥＲＳＩＯＮ，例えばＶｅｒｓｉｏｎ  ２００３）
この範例内の機能はパラメータをこれに対応する製品名で置き換え、新たなストリングを戻す。例えば、ＧｌｏｂａｌＡｌｌｏｃ機能はストリング上で実行される。呼び出し操作者はＧｌｏｂａｌＦｒｅｅを使用してストリングを解除する。入力ストリングは触れられない。いかなる他の置き換え可能パラメータ（例えば％Ｉｄ（ｓｐｒｉｎｔｆに関する）または％１！Ｉｄ！（ＦｏｒｍａｔＭｅｓｓａｇｅに関する））も「現状通り」に留まる。呼び出し操作者は好ましい機能を呼び出して呼び出しの前または後のそれらをＢｒａｎｄｉｎｇＦｏｒｍａｔＳｔｒｉｎｇへと置き換えることが可能である。場合によっては、呼び出し操作者は製品ストリングを得るためにＢｒａｎｄｉｎｇＬｏａｄＳｔｒｉｎｇを呼び出し、その後、それらを好ましい機能へと送ることも可能である。ＢｒａｎｄｉｎｇＦｏｒｍａｔＳｔｒｉｎｇはブランド化エンジン１７６のユーザの便宜のために設けられるヘルパーＡＰＩのみである。
【００４１】
以下は入力ストリングの範例であって、「％ＷＩＮＤＯＷＳ（登録商標）＿ＬＯＮＧ％はこれまでの最良の製品である」である。もしもコンピュータがＷｉｎｄｏｗｓ（登録商標）  ＸＰ（登録商標）家庭版オペレーションシステムで実行している場合、出力は、「Ｗｉｎｄｏｗｓ（登録商標）  ＸＰ（登録商標）家庭版がこれまでの最良の製品である」であろう。
【００４２】
ここで図９を参照すると、本発明の一態様は相手先商標製品製造会社（ＯＥＭ）のようなサードパーティによってカストマイズされたブランド化を含む。ブランド化エンジン１７６はＯＥＭ特注ブランド化をサポートし、それはブランド化のリソースＤＬＬ１７８内に含まれる拡張可能マーク付け言語（ＸＭＬ）ファイルによって達成される。ブランド化のマニフェストとも称されるＸＭＬファイルは付随するブランド化のリソースＤＬＬ１７８内に含まれるリソースを記述する。ブランド化のリソースＤＬＬ（すなわちリソースファイル１７８）にリソースが追加されると、ＤＬＬに関するＸＭＬデータは新しい（複数）リソースについて更新される。
【００４３】
一実施形態では、ソフトウェア製品にインストールされる特定のブランド化のリソースがＯＥＭもしくは他のサードパーティによって供給／上書きされることが可能であるかどうかをＸＭＬファイル内のデータフィールドの１つが示す。例を挙げると、そのデータは以下の情報、すなわちＲｅｓｏｕｒｃｅＴｙｐｅ、ＲｅｓｏｕｒｃｅＩＤ、およびＯｖｅｒｗｒｉｔｅを含む。ＲｅｓｏｕｒｃｅＴｙｐｅの記述はブランド化のリソースをタイプ（例えばＳｔｒｉｎｇ＝６、Ｂｉｔｍａｐ＝２）によって識別し、それに対してＲｅｓｏｕｒｃｅＩＤは識別子を供給する。ＮＯのデフォルト値を有するＯｖｅｒｗｒｉｔｅは、識別されたブランド化情報にサードパーティがリソースを供給することを許容されるかどうかを示す。付け加えると、マニフェストもやはり、リソースの特徴、他の特徴（例えばサイズ、長さ、色彩、書式など）を記述する組み込みメタデータを含むことが可能である。
【００４４】
開始ステップ１８２で、図９はサードパーティのリソースを得る処理ステップを記述している。バイナリもしくは他の（複数）ファイル（例えばコンポーネント１５６）は最初にブランド化のリソースを要求する。都合のよいことに、リソース自体の中でブランド化規則を維持することはリソースの破損を防止する。１８４で、コンポーネントはブランド化エンジン１７６のブランド化ＡＰＩに呼び出しを行なう。この範例では、様々なタイプで異なる可能性のあるブランド化ＡＰＩはＷｉｎ３２（登録商標）の管理されていないＡＰＩの後にモデル化される。インターフェースが（例えばＮＥＴフレームワークで）管理されることもやはり可能であることは理解されるべきである。
【００４５】
１８６で、例えばネーム空間とリソースＩＤに基づいてブランド化エンジン１７６がブランド化のマニフェストをチェックする。この範例では特定されたネーム空間が特定のＤＬＬに対してマップ化を行なう。この時点で、ブランド化エンジン１７６はＤＬＬをその中央の場所に配置すること、および要求されるリソースに関するＩＤがＤＬＬに知られているかどうかを判定することを試みる。１８８でブランド化エンジン１７６はさらに、オーバーライド命令に関するマニフェストを調べる。オーバーライドがＮＯ値に設定されると、１９０で正規のリソースが戻される。他方で、もしもオーバーライドがＹＥＳ値に設定されると、サードパーティはソフトウェア製品の外観の態様を変える許可を与えられるであろう。
【００４６】
１９２に進むと、ブランド化エンジン１７６はサードパーティのオーバーライドＤＬＬの存在をチェックする。前のように、ブランド化エンジン１７６は特定されたネーム空間に基づき、知られている場所をオーバーライドＤＬＬに関して検索する。もしもオーバーライドＤＬＬが存在しないか、または正規のリソースをオーバーライドする意思を特定しなければ、操作は１９０に戻る。もしもオーバーライドＤＬＬが利用可能であれば、サードパーティのリソースが１９４に戻される。
【００４７】
以下はデータファイル（すなわちブランド化のマニフェスト）の範例である。
<Branding>
<ResourceResourceType="2"ResourceID="100"OverWrite="No"/>
<ResourceResourceType="2"ResourceID="101"OverWrite="No"/>
<ResourceResourceType="2"ResourceID="110"OverWrite="No"/>
<ResourceResourceType="2"ResourceID="111"OverWrite="No"/>
<ResourceResourceType="6"ResourceID="10"OverWrite="Yes"/>
<ResourceResourceType="6"ResourceID="11"OverWrite="Yes"/>
<ResourceResourceType="6"ResourceID="12"OverWrite="Yes"/>
<ResourceResourceType="6"ResourceID="13"OverWrite="Yes"/>
</Branding>
もしも最初の例でブランド化のリソースＤＬＬ内にリソースが供給されない場合、上記のデータファイル内の記入が要求される。しかしながらリソースは、ブランド化のリソースＤＬＬ内ではなく、サードパーティによって供給される可能性がある。例えば、ＯＥＭ／サードパーティがＷｉｎｄｏｗｓ（登録商標）  ＸＰ（登録商標）のオペレーティングシステムのシステムプロパティのページにＯＥＭロゴのような特定のリソースを上書きすることが可能であることを示すためにデータファイル内の記入が使用される。この範例では、ブランド化のリソースを供給しないとＯＥＭが選択すれば、ブランド化のリソースＤＬＬはデフォルトを有する必要がない。
【００４８】
ここで述べられるコンポーネント定義はまた、特にオペレーティングシステムのコンポーネントではなく、概してアプリケーションコンポーネントを記述するために使用されることも可能である。言い換えると、いかなるアプリケーションもこのコンポーネント定義を使用して記述されることが可能である。したがって、ブランド化フレームワークはいかなるオペレーティングシステム、アプリケーションプログラム、またはその他のソフトウェア製品にも適用されることが可能である。
【００４９】
ここで述べるコンポーネント化アーキテクチャは、設計時と稼動時の両方でコンポーネントを管理するための概念、コンポーネントリポジトリ、およびプログラミングモデルを定義する。敏捷性、速度、サポート能力、および向上した収益機会を含めてコンポーネント化のいくつかの戦略的利益が存在する。製品オブジェクトまたはＳＫＵオブジェクトで表わされる新しいソフトウェア製品を作り出すことは、クライアントとサーバのラインを横切って同等に、はるかに容易にされる。正しいコンポーネントを選択し、新製品を構築するためにいくつかの追加的構造を供給することは比較的単純な仕事である。比較的短時間で新製品を作り出す素早さは効率的な競争能力を提供し、市場機会を見逃すことを回避する。例えば、後になって現在の製品に追加すべき追加的なコンポーネントを提供することが可能であり、それは顧客が高級製品にアップグレードさせることを可能にし、それがライセンスの全数を増加させる。これらの追加的な使用率すべてが製品に関する追加的な収益に結びつく。
【００５０】
コンポーネント化はまた、相手先商標製品製造会社（ＯＥＭ）もしくは法人が保持しなければならない製品イメージの数の削減を容易にし、それが大幅なコスト節約につながる可能性がある。本発明の少なくとも１つの実施形態によると、オフライン方式でコンポーネントがインストールされることが可能となるようにコンポーネント情報の大部分は宣言文である。これは目標の装置に製品全体をインストールするためにかかる時間を削減し、かつＯＥＭ、法人、エンドユーザなどにとって大幅なコスト削減ならびに向上した顧客満足度に結びつく。
【００５１】
製品サイクルの一部としての補修の重要性を当業者は認識している。本発明の実施形態に従ってコンポーネント化された製品を補修することは比較的単純であるが、その理由は、各々のコンポーネントによって供給される宣言情報に基づいて変更の影響を評価することが容易であるからである。検査効率を向上させるために一層隔離された環境でコンポーネントを検査することもやはりはるかに容易である。今度は他方で、これがソフトウェア製品の全体的脆弱性を削減する。
【００５２】
ここで述べられるコンポーネント定義スキーマはコンポーネント１５６が記述する情報を網羅しており、それにより適切なリソースにインストール、アップグレード補修、およびバインドする。この関連で、図２は本発明の特定の実施形態による範例のコンポーネント１５６とそれに対応するマニフェスト１５８を例示している。本発明の実施形態によると、各々のコンポーネント１５６は対応するマニフェスト１５８によって説明される。コンポーネント１５６は少なくとも１つのファイル１７４を含み、場合によっては複数（ｎ）のファイルを含む可能性もある。図２でファイルとして例示しているが、コンポーネント１５６は実ファイルではなく１つまたは複数のファイル１７４のポインタまたは他の識別子を含むことも可能である。
【００５３】
コンポーネント１５６はマニフェスト１５８に対応する。例示された範例では、マニフェスト１５８は（例えば名称または何らかの他の独自の識別子によって）コンポーネント１５６を識別するコンポーネント識別子を含む。この対応は、場合によっては、マニフェスト１５８の識別子（図示せず）をコンポーネント１５６内に含めること、データ構造内にコンポーネント１５６とマニフェスト１５８（またはその識別子）の両方を記憶させてそれがコンポーネント１５６とマニフェスト１５８の間の固有の対応を保持することなどといった異なる方式で維持される可能性がある。マニフェスト１５８は拡張可能マーク付け言語（ＸＭＬ）の文書であることが可能である。
【００５４】
図２の範例のリストに示されるように、マニフェスト１５８はまた、コンポーネント１５６が従属するゼロまたはそれよりも多いコンポーネントを識別する従属コンポーネント一覧表も含む。識別される従属コンポーネントは、コンポーネント１５６が適切に機能するようにオペレーティングシステムのイメージの一部としてインストールされることがやはり必要なコンポーネントである。例示された範例では、識別子はコンポーネント１５６が適切に機能するために必要とされるコンポーネントを識別するが、しかし場合によっては、含まれるであろうコンポーネント（すなわち、必要ではないがオペレーティングシステムの一部として有するようにコンポーネント１５６によって推奨されるコンポーネント）を含むことも可能である。識別と従属性に加えて、この範例のマニフェスト１５６はまた、コンポーネント１５６のいくつかの他の詳細、すなわち包括的（一般）情報（所有者、検査者、開発者、説明など）、ファイル、レジストリ情報、設定（構成）、構成員、およびその他の情報も記述している。
【００５５】
別の選択肢の実施形態では、マニフェスト１５８はインストールおよび／またはアップグレードを補助するために優先順位およびバージョン表示もやはり含む可能性がある。
【００５６】
場合によっては、マニフェスト１５８内に保持される情報のいくらかまたは全部が異なる場所に保持される可能性がある。範例を挙げると、情報のうちのいくらかまたは全部が図１のコンポーネント１５６内に組み入れられる可能性がある。
【００５７】
別表Ａの範例はマニフェスト１５８に関する本発明の態様をさらに具体的にしめしている。
【００５８】
以下の説明は、本発明の態様を具現化するコンポーネント化アーキテクチャに使用される主要な抽象化に関してさらなる詳細を提供する。
【００５９】
上述したように、コンポーネント１５６（またはアセンブリ）と称されるオブジェクトは再使用可能または共用可能な配布、補修、およびバインディングの自己記述原子単位を表わしている。図３の実施形態では、コンポーネント１５６は他のコンポーネント１５６および／または機能１６４に従属（依存）して走ることが可能である、すなわちそれらはこれら他のオブジェクトに関して従属性（依存性）を示す。コンポーネント１５６はまた、異なる開放グループ、すなわちカテゴリ１６２の一員であることも可能である。この例では、開発者に馴染んだ拡張可能な「アイデンティティ」と称される複数パートのプロパティ「バッグ」が各々のコンポーネント１５６を識別する。コンポーネントのアイデンティティは次の属性、例えば名称、バージョン、プロセッサアーキテクチャ、言語（例えば「ｕｓ−ｅｎｇ」または「ｊｐｎ」）、ビルドタイプ（例えばフリーまたはデバッグ）、および発信者識別を有する。名称の属性はロケールに無関係のストリングの形式をとり、或る実施形態では特定のコンポーネント１５６を記述する。概して、例えば「ｍａｊｏｒ．ｍｉｎｏｒ．ｂｕｉｌｄ．ｒｅｖｉｓｉｏｎ」書式に従う４部分のバージョン番号はアイデンティティのバージョン属性によって供給される。コンポーネントのアイデンティティが機密保護されることを可能にする暗号で機密保護された情報は発信者のアイデンティティのＩＤ属性の中に見出される。
【００６０】
上述したように、各々のコンポーネント１５６は１つまたは複数のファイルならびにそれに付随するマニフェスト１５８で構成される。図３に示されるようにマニフェスト１５８はコンポーネント１５６の詳細を記述している。図３の実施形態では、コンポーネントもしくはアセンブリと称されるオブジェクトは他のコンポーネント１５６、カテゴリ１６２、および／または機能１６４に関して従属性を有する可能性がある。特に、図３はコンポーネント１５６がゼロまたはそれよりも多いカテゴリ１６２、ゼロまたはそれよりも多い機能１６４、および／またはゼロまたはそれよりも多い他のコンポーネント１５６の中に見出される１つまたは複数のバイナリファイルに従属する可能性があることを示している。さらに、コンポーネント１５６は、カテゴリ１６２で構成員を宣言する。
【００６１】
図４に示されるカテゴリオブジェクト１６２は、構成員がカテゴリマニフェスト内にあるのではなくカテゴリの一員で存在する開放グループを定義する。例えば、ＮｏｔｅｐａｄおよびＷｏｒｄｐａｄのようなテキスト編集プログラムに関連する１つまたは複数のコンポーネントをグループ化するために１つのカテゴリ１６２が確立されることが可能である。カテゴリ１６２もまた、コンポーネント１５６のそれと同様のアイデンティティのメカニズムを使用して識別される。一実施形態では、カテゴリ１６２はアイデンティティ、包括的情報、およびその他の情報といった詳細を有する。
【００６２】
図４の範例の関係図では、カテゴリ１６２はゼロまたはそれよりも多い機能（特徴）１６４、ゼロまたはそれよりも多いコンポーネント１５６、および／またはゼロまたはそれよりも多いパッケージ１６８をグループ化するために使用されることが可能である。上述したように、カテゴリオブジェクト１６２は或る開放グループを表わし、その中に他の複数オブジェクトがそれらの構成員を宣言する。
【００６３】
ここで図５を参照すると、機能オブジェクト１６４はコンポーネント１５６および／または他の機能１６４の合成を表わす。機能１６４はソフトウェア製品のビルディングブロックとして使用され、インストレーションに追加またはそこから削除されることが可能である。他のオブジェクトに従属するのではなく、機能１６４はコンポーネント１５６、他の機能１６４、およびカテゴリ１６２に関して包含的関係を有する。言い換えると、機能１６４は本実施形態による従属性を有さない。例を挙げると、或る機能オブジェクト１６４は集約されたＷｅｂブラウザ機能を表わし、他の機能オブジェクト１６４はメディアプレーヤアプリケーションを表わし、それらの両方がオペレーティングシステムと共に出荷される。機能１６４はアイデンティティ、包括的（一般）情報（例えば所有者、検査者、開発者、説明など）、構成員、構成、およびその他の情報から成る。本発明の一実施形態では、機能のアイデンティティは構造的にコンポーネントのアイデンティティと同様であり、各々の機能を識別するために使用される。機能１６４は複数の異なるカテゴリ１６２の構成員であることが可能である（図４参照）。
【００６４】
図５はさらに、機能１６４がゼロまたはそれよりも多い他の機能１６４および／またはコンポーネント１５６を含むこと、および機能１６４がゼロまたはそれよりも多いカテゴリ１６２の中の構成員を宣言することが可能であることを例示している。
【００６５】
図６はパッケージオブジェクト１６８を図式的に例示している。図示したように、パッケージ１６８はコンポーネント１５６、機能１６４、カテゴリ１６２、および他のパッケージ１６８の合成である。カテゴリ１６２とは対照的に、パッケージ１６８は閉鎖グループである。パッケージ１６８は主に管理目的で使用される。例えば、ＯＳの家庭用バージョンは「ｃａｂ１」、「ｃａｂ２」、「ｃａｂ３」および「ｃａｂ４」で示される４つの異なるパッケージ１６８で出荷される可能性がある。この範例のパッケージオブジェクト１６８はセットアップ目的で形成されたグループである。図６の実施形態では、パッケージ１６８は他のパッケージ１６８だけに従属性を特定する。ここで述べられるコンポーネント化定義に従った各々のパッケージ１６８はアイデンティティ、包括的情報、構成員、構成、従属性、および他の情報といった詳細から成る。
【００６６】
図６をさらに参照すると、パッケージ１６８はゼロまたはそれよりも多い他のパッケージ１６８、カテゴリ１６２、機能１６４、および／またはコンポーネント１５６のグループ化を表わす。この例では、パッケージ１６８はカテゴリ１６２のような開放グループに属すること、または他のパッケージ１６８のような閉鎖グループから従属することが可能である。
【００６７】
図７の製品オブジェクト１６６は機能１６４および／またはコンポーネント１５６の最上位の合成を表わす。それはまた、作り上げられた機能１６４とコンポーネント１５６を構成するために使用されるプロパティも有する。本発明の実施形態によると、製品設計者は製品１６６用に１つまたは複数の機能１６４を選択する（図１３参照）。製品オブジェクト１６６はアイデンティティ、包括的情報、構成、およびその他の情報に関する詳細を含む。ＳＫＵオブジェクト１７０は製品１６６のための出荷媒体を表わす（すなわち出荷用のディスクにどのような製品が含まれるかを表わす）。適切な出荷用媒体にはフロッピー（登録商標）もしくはコンパクトディスク、およびウェブダウンロードのキャビネットファイルが含まれる。また、ＳＫＵ１７０は複数の製品１６４で構成されることも可能である（図１３参照）。本発明の少なくとも１つの実施形態はＳＫＵ設計ツールを使用してＳＫＵマニフェストを作り出す。上述した他の抽象化と同様に、ＳＫＵ１７０はアイデンティティ、包括的情報、製品、およびその他の情報を含む。
【００６８】
図１０は、機能１６４を定義するためにＯＳバイナリファイルの様々なコンポーネント１５６をグループ化する処理の範例を供給する。そのとき、機能１６４は製品１６６を定義するためにグループ化され、それが今度は他方で出荷のためにＳＫＵ１７０に含められる。様々なコンピュータは同じオペレーティングシステムを土台にした様々なオペレーティングシステムイメージを有する可能性がある。例えば、様々なＯＥＭが様々な方式で同じオペレーティングシステムをカストマイズする可能性がある（例えばそれにより、オペレーティングシステムはＯＥＭを識別する初期スクリーンで起動し、様々なデフォルト設定が使用されることが可能である）。様々な機能が含まれる可能性もやはりある（例えばスクリーンセーバ、バックグラウンドもしくは主題、通信プログラムのようなソフトウェアアプリケーション、ゲームなど）。この追加的な機能はＯＥＭ、場合によっては他の製造業者もしくはディストリビュータによって供給される可能性がある。したがって、多くの異なるコンポーネントが、特定のコンピュータにオペレーティングシステムイメージとしてサブセットだけが実際にインストールされるオペレーティングシステムの一部である可能性がある。他方で、ＯＥＭ特異性のコンポーネントとマニフェストのセットは、オペレーティングシステムイメージの一部としてＯＥＭによってインストールされることが可能な追加的なコンポーネントを含む。
【００６９】
オペレーティングシステムは多様な理由のうちのいずれのために更新される可能性もある。範例を挙げると、特定のコンポーネントの特定のファイルに対するバグ修正が利用可能である可能性があり、コンポーネント内に新たな機能（例えば交換もしくは追加ファイル）が利用可能である可能性があり、新たなコンポーネントが利用可能である可能性があるなどである。
【００７０】
付け加えると、新たなコンポーネントは、それを入れ換えるのではなく前のコンポーネントに沿ってオペレーティングシステムの一部としてインストールされることが可能である。これは、様々なアプリケーションがコンポーネントのどのようなバージョンも意のままに使用すること（または使用するようにプログラムされる）を可能にする。
【００７１】
例を挙げると、ＯＥＭは家庭用用途、業務用用途、サーバ用途などに対応して様々な基本的コンピュータ構成を提供することが可能である。この範例ではそれらの構成の各々は同じオペレーティングシステムに基づいているが、しかし異なる機能を含む。追加的なネットワーク化および通信機能はサーバ構成の中に含まれることが可能であってそれは家庭用または業務用構成のいずれにも含まれず、追加的なゲームまたは音声再生機能は家庭用構成の中に含まれることが可能であってそれは業務用またはサーバ構成に含まれない。図１０は基本的な家庭用製品を含む範例の高級製品を示している。
【００７２】
図１１は本発明の実施形態によるプログラミングモデルの第１段階の抽象化を示している。特に、範例の図は、例えば統一モデリング言語（ＵＭＬ）を使用する様々な第１段階のオブジェクト（もしくはクラス）を例示している。この範例では、オブジェクトはＵＭＬを使用するプログラマに対して明らかにされる。インターフェースの各々がコンポーネント化の第１段階の概念へと直接マップ化する。
【００７３】
オペレーティングシステムのインストレーション処理はオペレーティングシステムのコンポーネント化によって大幅に単純化される。ＯＥＭ特異性の機能は、適切なコンポーネントとそれに対応するマニフェストを含ませることによって容易にコンピュータに追加されることが可能である。さらに、機能を向上させるためのオペレーティングシステムに対する更新、バグ修正などは対応するコンポーネントを単純に置き換えることによって容易にインストレーション処理に組み込まれることが可能である。場合によっては、追加的な更新コンポーネントとマニフェストのセットが、そのような更新を含むオペレーティングシステムインストレーションステーションに対して利用可能である可能性もある。
【００７４】
ここで本発明のブランド化フレームワークのさらなる態様を参照すると、内的ブランド化のシナリオは概して、少なくとも或る実施形態では手作業の処理に基づいている。範例を挙げると、コンポーネント１５６は製品のブランド化を含むように発案される可能性がある。これは、そのＵＩ内で製品のブランド化を表示するコンポーネント１５６、ならびに既にある一般的な製品ブランド化要素に追加される独自のブランド化ＵＩを持たないコンポーネント１５６を含む。この例では、コンポーネントの作者は計画と実施といったコンポーネント化の処理中の複数の時点でコンポーネント１５６がブランド化を表示することを可能にする。
【００７５】
計画段階では、例えば、コンポーネント１５６の作者はブランド化要素に関するそのＵＩをチェックし、一般的な製品ブランド化要素のいくつかの例を見つけ出すことが可能である。もしも作者が特定の製品に対して独特であるいかなるブランド化も見つけ出さない場合、ブランド化カテゴリ１６２内の既にある一般的な製品ブランド化要素をコンポーネント１５６が使用することが可能であると結論付けることが可能である。この例では、コンポーネント１５６がブランド化エンジン１７８のＡＰＩ上に従属性を表明する必要があるであろうことに作者は気付く。
【００７６】
実施の段階で、例えば、作者はブランド化カテゴリ１６２の内部のブランド化のリソースを見つけ出し、それはブランド化のリソースコンポーネント（ＤＬＬ）によって分割されたリソースファイル１７８の全部をリストアップしている。別の代替選択肢では、ブランド化バイナリ全部のルートが作者にとって利用可能である可能性がある。実施時に、作者はブランド化カテゴリ１６２からブランド化のリソースコンポーネントを選び出し、コンポーネント１５６についてＵＩを符号化する。この時点で、作者はコンポーネント１５６から由来する従属性をブランド化ＡＰＩに追加する。ビルド時に、特定されたブランド化要素がＵＩ内に表示される。
【００７７】
さらに別の実施形態では、コンポーネントの作者は（例えば高級製品のために）一般的なブランド化の代わりに独特または特注のブランド化要素を要求する可能性がある。ここで図１２を参照すると、本発明の態様を具現化するブランド化フレームワークは、特注のブランド化要素を有するソフトウェア製品を作り出すためにコンポーネント作者がブランド化エンジン１７６に対して従属性を特定することを可能にする。
【００７８】
図１３は本発明で使用するための範例のコンポーネント化アーキテクチャを例示している。図１３に示された拡張可能なアーキテクチャは、インストールとアンインストールのコンポーネントを含むＯＳインストレーションのビルドを可能にし、製品／ＳＫＵの素早さを可能にする。さらに、このアーキテクチャは走っているＯＳおよびＯＳイメージを補修するためのインフラストラクチャを供給し、ＯＳコンポーネントの在庫管理を供給し、かつインストールされたシステム上で活動する。コンポーネント化アーキテクチャはコンポーネントの作成と管理のための汎用化されたフレームワークを供給する。それはまた、ランタイムのイメージを一般的な方式で機器構成からビルドすることを可能にする。コンポーネント管理インターフェース（ＣＭＩ）は、コンポーネント化アーキテクチャによって明らかにされる機能にアクセスする様々な顧客によって使用される可能性のあるプログラミングモデルのインターフェースである。ツール類は概して以下のクラス、すなわち設計時ツール、ランタイムツール、およびビルド時のツールに分けられることが可能である。設計時ツールは設計時（例えばコンポーネント設計者がコンポーネントを設計または作成し、ターゲット設計者が機器構成を設計または作成する）に使用されるツールである。ランタイムツールはランタイムイメージ上に既にあるコンポーネント（インストレーション）を管理するために使用される。これは、システム上にインストールされたコンポーネントを管理するオプションコンポーネントマネージャ（ＯＣＭ）のような機能を含む可能性がある。ランタイムツールのまた別の範例は、コンポーネントの更新を得るために遠隔サーバと会話し、インストレーションでインストールされたコンポーネントを更新する補修用クライアントであることが可能である。ビルド時のツールはビルドの研究室で使用される。それらは主に機器構成からランタイムイメージを作成するために使用される。
【００７９】
図１３に示されるように、ＣＭＩはコア層とユーティリティ層を有する。ＣＭＩのコア層は、よく知られているインターフェースとして概して公表され、かつ消費される様々な機能ブロックから構成される。この層はコアＣＭＩオブジェクトモデル、リポジトリとファイルリポジトリ、および並直列変換器／直並列変換器から構成される。コアＣＭＩオブジェクトモデルブロックはプログラミングを容易にするために、多数の異なる第１のクラスの抽象化をＣＭＩクライアントへのインターフェースとして明らかにする。それらは概して、比較的使用し易い書式でコンポーネント化の抽象化を反映する。例えば、ＩＡｓｓｅｍｂｌｙは「コンポーネント」の概念を抽象化する。この実施形態の中の抽象化はそれらに付随するいかなる機能も持たない。それらは抽象化で明らかにされる方法を通じて回収および設定されることが可能な属性の収集体である。以下のリストはコアＣＭＩオブジェクトモデル内のインターフェースを通じて明らかにされる抽象化のうちのいくつかを含み、ＩＡｓｓｅｍｂｌｙ、ＩＦｅａｔｕｒｅ、ＩＣａｔｅｇｏｒｙ、ＩＰａｃｋａｇｅ、ＩＰｒｏｄｕｃｔ、ＩＳｋｕ、ＩＣｏｎｆｉｇｕｒａｔｉｏｎ、ＩＲｅｐｏｓｉｔｏｒｙである。
【００８０】
図１３の範例の中のコンポーネントリポジトリはリポジトリのうちの１つに存在するコンポーネントを管理するために使用される。上述したように、各々のコンポーネントはメタデータ（すなわちデータに関する情報）および実データ（すなわちコンポーネントのファイル）を有する。メタデータはメタデータリポジトリインターフェース（ＩＲｅｐｏｓｉｔｏｒｙ）を通じてアクセス可能であり、それに対してデータはファイルリポジトリインターフェース（ＩＦｉｌｅＲｅｐｏｓｉｔｏｒｙ）を通じてアクセス可能である。一実施形態では、メタデータリポジトリインターフェースは、コンポーネントのメタデータを記憶して指標化するために関係型データベースを使用して実装される。ファイルリポジトリインターフェースは矛盾のない方式でクライアントがコンポーネントのデータ（ファイル）を得ることを可能にする。
【００８１】
コンポーネントのメタデータとデータのインターフェースは、様々なシナリオに基づいた様々な差し込み可能なメタデータリポジトリの実装を可能にするために図１３のコンポーネントリポジトリインターフェースの下で分離される。例えば、利用可能な記憶装置とメモリが束縛されることはあり得ないので設計マシン上ではＳＱＬメタデータリポジトリを使用することが可能であるが、しかしランタイムのシステム上で、緊密なメモリの必要条件を保護するためにメタデータリポジトリが小規模のフットプリントデータベース（例えばレジストリ）によって戻される可能性がある。
【００８２】
並直列変換器と直並列変換器のインターフェースはＣＭＩ内の第１のクラスのオブジェクトがテキストファイルへと並直列変換されること、およびそこから直並列変換されることを可能にする。例えば、ＸＭＬの並直列変換器と直並列変換器はＸＭＬファイルを読み取り、書き込む。下記で説明されるように、並直列変換器と直並列変換器は概してキャリアと構成を読み取って書き出す。
【００８３】
並直列変換された書式でどのような第１のクラスの抽象化を持つファイルもキャリアまたはマニフェストのいずれかと称される。キャリアはコンポーネントリポジトリデータを母集団化する手段を供給する、すなわちツールがキャリアファイル内でコンポーネントの並直列変換されたインスタンスを作成または編集し、コンポーネントリポジトリインターフェースがコンポーネントリポジトリ内へのキャリアのインポートを可能にする。
【００８４】
情報交換のためにキャリアを使用する主な利点は、コンポーネントリポジトリからツールが切り離されることをそれが可能にすることである。また別の利点は、キャリアの情報をインポートしている間にデータがコンポーネントリポジトリ内にさらに矛盾のない（または完全な）書式でインポートされ得ることである。並直列変換器と直並列変換器のインターフェース分離はまた、他の種類のキャリア（例えばＩＮＦ）が実装されることも可能にする。
【００８５】
機器構成はＣＭＩのＩＣｏｎｆｉｇｕｒａｔｉｏｎオブジェクトの並直列変換された表現であり、それはランタイムイメージのビルドに使用されるコンポーネントと設定の収集体を表わす。キャリアファイルではなく独立したファイル内で機器構成が並直列変換される理由は、機器構成がデータベース内へとインポートされることが不可能であるからである。
【００８６】
ＣＭＩユーティリティ層は頻繁に変わる機能のブロックから成る。図１３の実施形態では、機能ブロックはよく知られているインターフェースとして明らかにされ、消費される。ユーティリティ層はインストーラ、アップグレーダ、従属性リゾルバ、ＣＭＩオブジェクトモデル、およびクライアントに関するブロックを含む。インストーラブロックはコア層によって明らかにされた特定のコンポーネント化の抽象化をインストール（またはビルド）および除去するための論理を有する。例えば、ＩＡｓｓｅｍｂｌｙはオンラインまたはオフラインの方式でＯＳインストレーションからインストールおよび除去される。インストールと除去のアセンブリの論理はこのブロック内に存在する。コア抽象化のすべては「ＩＩｎｓｔａｌｌａｂｌｅ」インターフェースを使用してインストールおよび除去される。これらの方法の実施は各々のコア抽象化で変わる。例えば、アセンブリに関すると「ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒ」と呼ばれるインストーラ抽象化が存在するであろう。ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒは「ＩＡｓｓｅｍｂｌｙ」インターフェースを集合させ、アセンブリインスタンスをインストールおよびアンインストールするために「ＩＩｎｓｔａｌｌａｂｌｅ」を実施する。
【００８７】
コア抽象化と結び付くこのタイプの特定機能は、コアＩＡｓｓｅｍｂｌｙインターフェースに影響することなく、必要なときにアセンブリインストール論理の実施が変わることを可能にする。他のコア抽象化についてもやはり同じことが真実であり続ける。
【００８８】
アップグレーダブロックはウインドウズ（登録商標）のインストレーションで特定のコア抽象化をアップグレードおよびダウングレードするための論理を有する。例えば、ＩＡｓｓｅｍｂｌｙはオンラインまたはオフラインの方式でＯＳインストレーションからアップグレードまたはダウンロードされる。アップグレードおよびダウングレード用アセンブリの論理はこのブロック内に存在する。コア抽象化すべてが「ＩＵｐｇｒａｄａｂｌｅ」インターフェースを使用してアップグレードおよびダウングレードされる。
【００８９】
各々のコア抽象化に関してこれらの方法の別々の実施法が存在する。インストールおよびアンインストール機能がアップグレード処理時に必要とされるので、既にあるインストールとアンインストールの機能を再使用するために「ＩＩｎｓｔａｌｌａｂｌｅ」から「ＩＵｐｇｒａｄａｂｌｅ」が引き継ぐ。例えば、そのアセンブリは「ＩＡｓｓｅｍｂｌｙＵｐｇｒａｄｅｒ」と呼ばれるアップグレーダ抽象化を有する。ＩＡｓｓｅｍｂｌｙＵｐｇｒａｄｅｒは「ＩＡｓｓｅｍｂｌｙ」、「ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒ」を集合させ、ウインドウズ（登録商標）インストレーションでアセンブリインスタンスをアップグレードおよびダウングレードするために「ＩＵｐｇｒａｄａｂｌｅ」を実施する。やはりこの種のバインディングも、コアＩＡｓｓｅｍｂｌｙインターフェースおよびインストールもしくはアンインストール論理に影響することなく、必要なときにアセンブリアップグレード論理の実施が変わることを可能にする。他のコア抽象化についてもやはり同じことが真実であり続ける。
【００９０】
従属性リゾルバブロックは特定のコア抽象化について従属性解決論理を実行する。この例では、各々のコア抽象化についてこのブロックは自動または手動の様式のいずれかで従属性の解に関する論理を有する。従属性リゾルバは、特定のクライアント背景で必要なときにデフォルト従属性解決機能を拡張するためにクライアントプログラムについて拡張可能である。このブロックの機能は「ＩＤｅｐｅｎｄｅｎｃｙＲｅｓｏｌｖｅｒ」インターフェースを通じて明らかにされる。従属性に解を出す方法はそれが使用されているシナリオに基づいてＣＭＩオブジェクトまたはインスタンスオブジェクトのトリーに戻る。従属性解決は、概して、本発明の少なくとも１つの実施形態に従って機器構成またはリポジトリに関して為される。このリポジトリは、インストール可能な、またはインストールされたリポジトリであり得る。
【００９１】
概して、ランタイムのシステムで、従属性解決はインストールされたリポジトリまたは既にある機器構成に対して生じ、それに対して設計時のシナリオでは、従属性解決はインストール可能なリポジトリおよび編集されつつある現在の機器構成に対して生じる。
【００９２】
ＣＭＩオブジェクトモデルはＣＭＩコアオブジェクトモデルと、ユーティリティ層で明らかにされた機能の様々な断片の集合体の形である。コアＣＭＩオブジェクトモデルもまた、キャリア（またはマニフェスト）を並直列変換および直並列変換中に著作ツールが直接抽象化を操作するように明らかにされる。
【００９３】
上記のアーキテクチャの中で気付く主要な事柄の１つは、都合のよいことに同じプログラミングモデルが設計時、ランタイムおよびビルド時のシナリオに関して明らかにされることである。これはオブジェクトモデルを様々な必要条件に関して矛盾なく保つことに役立ち、プログラマの生産力に役立つ。これはまた、ＣＭＩの単一の実施が設計およびランタイムのような異なるシナリオで使用される再使用に役立ち、したがって設計時とランタイムのための異なる実施と比較するとさらに保守可能である。
【００９４】
図１４はコンピュータ７０の形式の汎用計算機装置の１つの範例を示している。本発明の一実施形態では、コンピュータ７０のようなコンピュータはコンピュータ１５０として使用することに適している。
【００９５】
例示された実施形態では、コンピュータ７０は１つまたは複数のプロセッサもしくは処理ユニット７２およびシステムメモリ７４を有する。例示された実施形態では、システムバス７６はシステムメモリ７４を含む様々なシステムコンポーネントをプロセッサ７２へと結合させる。バス７６は、メモリバスもしくはメモリ制御器、周辺バス、ＡＧＰ、および様々なバスアーキテクチャいずれを使用するプロセッサもしくはローカルバスも含めて、いくつかのタイプのバス構造のいずれの１つまたは複数も表わす。限定されることはないが範例を挙げると、そのようなアーキテクチャにはＩｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとしても知られているＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。
【００９６】
コンピュータ７０は通常、少なくともいくつかの形式のコンピュータ読み取り可能な媒体を有する。揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体の両方を含むコンピュータ読み取り可能な媒体はコンピュータ７０によってアクセスされることが可能などのような入手可能な媒体であってもよい。限定されないが範例を挙げると、コンピュータ読み取り可能な媒体はコンピュータの記憶媒体と通信媒体を含む。コンピュータの記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたはその他のデータといった情報の記憶のためのいかなる方法もしくは技術で実装される揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体も含む。例えば、コンピュータの記憶媒体はＲＡＭ、ＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル汎用ディスク（ＤＶＤ）または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶装置、あるいは所望の情報を記憶するために使用されることが可能であり、かつコンピュータ７０によってアクセスされることが可能であるいかなる他の媒体も含む。通信媒体は通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または搬送波もしくは他の搬送メカニズムのような変調されたデータ信号内の他のデータを具現化し、かついかなる情報引渡し媒体も含む。当業者は、１つまたは複数の特性のセットを有するか、または信号内の情報を符号化するような方式で変えられた変調データ信号に慣れている。配線式ネットワークまたは直接配線接続といった配線式媒体、および音響、ＲＦ、赤外、およびその他の無線式媒体といった無線式媒体は通信媒体の範例である。上記のいずれの組み合わせもやはりコンピュータ読み取り可能な媒体の範囲内に含まれる。
【００９７】
システムメモリ７４は取り外し可能および／または取り外し不可能、揮発性および／または不揮発性メモリの形式のコンピュータ記憶媒体を含む。例示された実施形態では、システムメモリ７４は読み出し専用メモリ（ＲＯＭ）７８とランダムアクセスメモリ（ＲＡＭ）８０を含む。例えばスタートアップ時にコンピュータ７０内の素子間の情報伝達を補助する基本ルーチンを含む基本入出力システム８２（ＢＩＯＳ）は、通常ではＲＯＭ７８内に記憶される。ＲＡＭ８０は、通常、即座にアクセス可能であるか、かつ／または現在処理ユニット７２によって操作されているデータおよび／またはプログラムモジュールを含む。限定されないが範例を挙げると、図１６はオペレーティングシステム８４、アプリケーションプログラム８６、その他のプログラムモジュール８８、およびプログラムデータ９０を例示している。
【００９８】
コンピュータ７０はまた、他の取り外し可能／取り外し不可能、揮発性／不揮発性のコンピュータ記憶媒体を含む可能性もある。例えば、図１４は取り外し不可能の不揮発性磁気媒体から読み出し、またはそれに書き込むハードディスクドライブ９４を例示している。図１４はまた、取り外し可能の不揮発性磁気ディスク９８から読み出し、またはそれに書き込む磁気ディスクドライブ９６、およびＣＤ−ＲＯＭもしくはその他の光学的媒体といった取り外し可能の不揮発性光ディスク１０２から読み出し、またはそれに書き込む光ディスクドライブ１００も示している。範例の動作環境で使用される可能正のあるその他の取り外し可能／取り外し不可能、揮発性／不揮発性のコンピュータ記憶媒体には、限定はされないが、磁気テープカセット、フラッシュメモリカード、デジタル汎用ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ８４、および磁気ディスクドライブ９６と光ディスクドライブ１００は通常ではインターフェース１０６のような不揮発性メモリのインターフェースによってシステムバス７６へと接続される。
【００９９】
ドライブまたはその他の大容量記憶装置およびそれらに付随する、上記で検討し、かつ図１４に例示されたコンピュータ記憶媒体はコンピュータ読み取り可能な命令、データ構造、プログラムモジュールおよびコンピュータ７０のためのその他のデータの記憶を提供する。例えば図１４で、ハードディスクドライブ９４はストリングオペレーティングシステム１１０、アプリケーションプログラム１１２、その他のプログラムモジュール１１４、およびプログラムデータ１１６として例示されている。これらのコンポーネントがオペレーティングシステム８４、アプリケーションプログラム８６、その他のプログラムモジュール８８、およびプログラムデータ９０と同じであるか、または異なるかのいずれであることも可能であることに留意すべきである。オペレーティングシステム１１０、アプリケーションプログラム１１２、その他のプログラムモジュール１１４、およびプログラムデータ１１６は、少なくともそれらが異なるコピーであることをここで例示するために異なる番号を与えられている。
【０１００】
ユーザはキーボード１２０と位置指示装置１２２（例えばマウス、トラックボール、ペン、またはタッチパッド）といった入力装置またはユーザインターフェース選択装置を通じてコマンドと情報をコンピュータ７０に入力する。他の入力装置（図示せず）にはマイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどが含まれる。これらおよびその他の入力装置は、システムバス７６に結合されるユーザ入力インターフェース１２４を通じて処理ユニット７２へと接続されるが、しかしパラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）といった他のインターフェースとバス構造によって接続されることも可能である。モニタ１２８または他のタイプの表示用装置もやはりビデオインターフェース１３０のようなインターフェースを介してシステムバス７６へと接続される。モニタ１２８に加えて、コンピュータはしばしばプリンタおよびスピーカといった他の周辺出力装置（図示せず）を有し、それらは出力周辺インターフェース（図示せず）を介して接続されることが可能である。
【０１０１】
コンピュータ７０は、遠隔コンピュータ１３４のような１つまたは複数の遠隔コンピュータへの論理接続を使用してネットワーク化された環境で動作することが可能である。遠隔コンピュータ１３４はパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置または他の共通ネットワークノードであることが可能であり、通常ではコンピュータ７０に関して上述した要素の多くまたはすべてを含む。図１６に描かれた論理接続はローカルエリアネットワーク（ＬＡＮ）１３６と広域ネットワーク（ＷＡＮ）１３８を有するが、しかし他のネットワークを含む可能性もやはりある。ＬＡＮ１３６および／またはＷＡＮ１３８は配線式ネットワーク、無線式ネットワーク、それらの組み合わせなどであることが可能である。そのようなネットワーク化環境は職場、幅広い企業コンピュータネットワーク、および世界的コンピュータネットワーク（例えばインターネット）では普通のことである。
【０１０２】
ローカルエリアネットワーク環境で使用されるとき、コンピュータ７０はネットワークインターフェースまたはアダプタ１４０を通じてＬＡＮ１３６へと接続される。広域ネットワーク環境で使用されるとき、通常ではコンピュータ７０はインターネットのようなＷＡＮ１３８にわたる通信を確立するためのモデム１４２または他の手段を含む。内部または外部にあってもよいモデム１４２はユーザ入力インターフェース１３４または他の適切なメカニズムを介してシステムバス７６へと接続される。ネットワーク化された環境では、コンピュータ７０またはその一部に関して描かれたプログラムモジュールは遠隔のメモリ記憶装置（図示せず）内に記憶される可能性がある。限定はされないが範例を挙げると、図１４はメモリ装置にある遠隔のアプリケーションプログラム１４４を例示している。図示されたネットワーク接続が範例であり、コンピュータ間の通信リンクを確立する他の手段が使用される可能性があることは理解されるであろう。
【０１０３】
概して、コンピュータ７０のデータプロセッサは異なる時間にコンピュータの様々なコンピュータ読み取り可能な記憶装置に記憶された命令によってプログラムされる。通常ではプログラムとオペレーティングシステムは、例えばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭ上に配分される。そこからそれらはコンピュータの二次メモリにインストールもしくはロードされる。実行時に、それらは少なくとも部分的にコンピュータの一次電子メモリへとロードされる。コンピュータ読み取り可能な記憶媒体がマイクロプロセッサもしくは他のデータプロセッサとの関連で、ここで説明されるステップを実行するための命令もしくはプログラムを含むとき、ここで述べられる本発明はこれらおよびその他の様々なタイプのそのような媒体を含む。本発明はまた、ここで述べられる方法および技術に従ってプログラムされるコンピュータ自体も含む。
【０１０４】
具体例を示す目的で、オペレーティングシステムのようなプログラムおよび他の実行可能なプログラムコンポーネントがここで個別のブロックとして例示される。しかしながら、そのようなプログラムおよびコンポーネントが様々な時間にコンピュータの様々な記憶コンポーネント内に存在し、かつコンピュータの（複数の）データプロセッサによって実行されることは認識される。
【０１０５】
コンピュータ７０を含めて範例の計算機システム環境と関連させて説明が為されたが、本発明は数多くの他の汎用目的および特定目的の計算機システム環境もしくは機器構成で操作される。本発明の使用法または機能の範囲について言えば、本計算機システム環境はどのような限定も示唆するように意図されていない。さらに、本計算機システム環境は範例の動作環境に例示されたコンポーネントのいずれの１つまたは組み合わせに関するどのような依存性または必要条件も有すると解釈されるべきではない。限定はされないが、本発明で使用されるために適切である可能性のあるよく知られている計算機システム、環境、および／または機器構成にはパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドもしくはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサを基本としたシステム、セットトップボックス、携帯電話を含むプログラム可能な民生用電子装置、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムもしくは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【０１０６】
本発明の実施形態は、１つまたは複数のコンピュータもしくは他の装置によって実行されるプログラムモジュールのようなコンピュータで実行可能な命令の一般的背景で述べられることが可能である。概して、限定はされないがプログラムモジュールは特定のタスクを実行するかまたは特定の抽象データタイプを導入するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含む。本発明は分散コンピューティング環境で実践されることもやはり可能であり、そこではタスクは通信ネットワークを通じてリンクされる遠隔の処理装置によって実行される。分散コンピューティング環境では、プログラムモジュールはローカルおよび遠隔コンピュータ両方のメモリ記憶装置を含む記憶媒体に配置される可能性がある。
【０１０７】
動作時では、リソースファイル１７８の各々にネーム空間を割り当ててそれらを割り当てたネーム空間に従ってグループ化するために、コンピュータ７０はここで述べたそれらのようなコンピュータで実行可能な命令を実行する。コンピュータ７０はさらに、選択されたネーム空間の関数としてリソースファイルのグループを呼び出し、かつ呼び出されたグループをソフトウェア製品にインストールされるべき１つまたは複数のブランド化のリソースについて検索するためにインターフェースを実行する。また別の実施形態では、リソースファイルに含まれるブランド化のリソースを識別するメタデータをリソースファイル１７８の各々に組み込むために、コンピュータ７０はここで述べられたそれらのようなコンピュータで実行可能な命令を実行する。この例では、コンピュータ７０は呼び出されたリソースファイルを、ソフトウェア製品にインストールされるべき１つまたは複数のブランド化のリソースについて、組み込まれたメタデータに基づいて検索する。
【０１０８】
特に特定しない限りここで例示され、かつ説明された方法の実行または遂行の順序が本質的でないことを当業者は気付くであろう。すなわち、特に特定しない限り本方法の複数の要素がどのような順序でも遂行される可能性があること、および本方法がここで開示されたそれらよりも多い、または少ない要素を含む可能性のあることが発明人らによって意図されている。
【０１０９】
ＵＲＬおよび他のインターネットウェブサイト参照を含むこの文書の中の情報は予告なく変更される対象である。特に言及しない限り、ここで述べられた範例の会社、組織、製品、ドメイン名、ｅメールアドレス、ロゴ、人々、場所および事象は架空であり、いかなる現実の会社、組織、製品、ドメイン名、ｅメールアドレス、ロゴ、個人、場所および事象と無関係であることが意図されるか、または推察される。
【０１１０】
本発明またはその実施形態の要素を導入するとき、「或る」、「その」および「前記」という冠詞は１つまたは複数の要素が存在することを意味すると意図されている。「含む」および「有する」という用語は包含的であることを意図され、リストアップされた要素以外に追加的な要素が存在し得ることを意味する。
【０１１１】
上記の観点から、本発明のいくつかの目的が達成され、他の都合のよい結果が獲得される。
【０１１２】
本発明の範囲から逸脱することなく上記の構成と方法に様々な変形が為され得るので、上記の説明に含まれ、かつ添付の図面に示されたすべての事項は具体的例示として解釈されるべきであり、限定の意味ではない。
【０１１３】
（別表Ａ）
データ記憶と書式：オーサリングツールがコンポーネント、機能、カテゴリ、パッケージ、製品およびＳＫＵを作成する。この範例では、それらはＸＭＬファイルで表わされる（キャリアまたはマニフェストと呼ばれる）。各々のキャリアは機能またはカテゴリまたはパッケージまたは製品またはＳＫＵの唯一のインスタンスを含む。ノートパッドマニフェストの範例は次の通りである。
【０１１４】
【表１−１】
2005078649.tif 000003
【０１１５】
【表１−２】
2005078649.tif 000004
【図面の簡単な説明】
【０１１６】
【図１】本発明の実施形態による範例のコンピュータを例示するブロック図である。
【図２】図１のコンポーネントおよびそれに対応するマニフェストを例示する範例のブロック図である。
【図３】本発明の実施形態による、範例のコンポーネント定義スキーマを例示する図である。
【図４】本発明の実施形態による、範例のコンポーネント定義スキーマを例示する図である。
【図５】本発明の実施形態による、範例のコンポーネント定義スキーマを例示する図である。
【図６】本発明の実施形態による、範例のコンポーネント定義スキーマを例示する図である。
【図７】本発明の実施形態による、範例のコンポーネント定義スキーマを例示する図である。
【図８】本発明の態様を具現化するブランド化のフレームワークのブロック図である。
【図９】本発明の一実施形態による処理フローを例示する範例のフロー図である。
【図１０】ソフトウェア製品に含まれるコンポーネントを選択するための、本発明の実施形態による範例の設計過程を例示する図である。
【図１１】本発明の一実施形態による範例のプログラミング対象モデルを例示する図である。
【図１２】ソフトウェア製品のブランド化に関する範例のコンポーネント従属性を例示するブロック図である。
【図１３】図３〜８のコンポーネント定義スキーマで使用するための範例のコンポーネント化アーキテクチャを例示するブロック図である。
【図１４】図１を使用するためのコンピュータの範例のコンポーネントを例示するブロック図である。
【符号の説明】
【０１１７】
１５０    コンピュータ
１５２    オペレーティングシステム
１５４    アプリケーションシステム
１５６    コンポーネント
１５８    マニフェスト
【図１】
2005078649.tif 000005
【図２】
2005078649.tif 000006
【図３】
2005078649.tif 000007
【図４】
2005078649.tif 000008
【図５】
2005078649.tif 000009
【図６】
2005078649.tif 000010
【図７】
2005078649.tif 000011
【図８】
2005078649.tif 000012
【図９】
2005078649.tif 000013
【図１０】
2005078649.tif 000014
【図１１】
2005078649.tif 000015
【図１２】
2005078649.tif 000016
【図１３】
2005078649.tif 000017
【図１４】
2005078649.tif 000018