1または複数のプロセッサと、カラー管理システムにコンポーネントからのカラー管理要求をサポートさせるように前記1または複数のプロセッサを介して実行可能なモジュールを格納したメモリとを備えたカラー管理システムであって、前記モジュールは、コンポーネントから前記要求を受け取るアプリケーションプログラムインターフェースAPIレイヤモジュールであって、前記要求がプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別する、APIレイヤモジュールと、前記APIレイヤモジュールから前記要求を得て、前記要求を分析して前記オブジェクトに対応する前記プロファイルがレガシーフォーマットと関連付けられているか、先進フォーマットと関連付けられているかを判定するAPIアダプテーションレイヤモジュールと、前記オブジェクトに対応する前記プロファイルが前記レガシーフォーマットと関連付けられている場合、前記要求を処理するレガシー処理モジュールと、前記オブジェクトに対応する前記プロファイルが前記先進フォーマットと関連付けられている場合、前記要求を処理する先進処理モジュールとを備え、前記APIレイヤモジュールは、前記要求に対する応答を返し、前記応答は、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションの結果を返し、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでなく、異なる要素が利用可能であるとき、前記要求された要素に合致すると判定された前記プロファイルの異なる要素に関する前記オペレーションの結果を返すように構成されていることを特徴とするカラー管理システム。請求項1に記載のカラー管理システムであって、前記オブジェクトを表すように構成された前記レガシーフォーマットおよび前記先進フォーマットとコンパチブルな共通構造をさらに備えたことを特徴とするカラー管理システム。請求項2に記載のカラー管理システムであって、別のオブジェクトを表すように構成された前記レガシーフォーマットおよび前記先進フォーマットとコンパチブルな別の共通構造をさらに備えたことを特徴とするカラー管理システム。請求項2に記載のカラー管理システムであって、前記共通構造は、前記オブジェクトの要素を識別するハンドルを利用することを特徴とするカラー管理システム。請求項2に記載のカラー管理システムであって、前記APIアダプテーションレイヤモジュールは、前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す前記共通構造を変更することを特徴とするカラー管理システム。請求項1に記載のカラー管理システムであって、前記APIアダプテーションレイヤモジュールは、別のオブジェクトが前記先進フォーマットと関連付けられている場合、前記オブジェクトを前記レガシーフォーマットから前記先進フォーマットに変換することを特徴とするカラー管理システム。請求項1に記載のカラー管理システムであって、前記応答は、前記要求された要素が前記判定されたフォーマットとコンパチブルでなく、前記異なる要素が利用可能でないとき、エラーを返すようにさらに構成されていることを特徴とするカラー管理システム。請求項1に記載のカラー管理システムであって、前記アプリケーションプログラムインターフェースAPIレイヤモジュールは、前記オブジェクトおよび前記要求された要素に関して行う前記カラー管理オペレーションを識別する1または複数のパラメータが入ったAPIコールとして前記要求を受け取ることを特徴とするカラー管理システム。請求項8に記載のカラー管理システムであって、前記1または複数のパラメータは、前記オブジェクトを識別するポインタを備えたことを特徴とするカラー管理システム。カラー管理システムの1または複数のコンピューティングデバイスによって行われるアプリケーションプログラムインターフェースAPIに対するカラー管理コールをサポートする方法であって、コンポーネントから要求を受け取ることであって、前記要求がプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別することと、前記要求を分析して、前記オブジェクトに対応する前記プロファイルがレガシーフォーマットと関連付けられているか、先進フォーマットと関連付けられているかを判定することと、前記オブジェクトに対応する前記プロファイルが前記レガシーフォーマットと関連付けられている場合、前記要求を処理するレガシー処理モジュールを呼び出し、前記オブジェクトに対応する前記プロファイルが前記先進フォーマットと関連付けられている場合、前記要求を処理する先進処理モジュールを呼び出す、ことによって前記要求を処理することと、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションの結果を返すことと、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでないとき、前記要求された要素に合致する前記プロファイルからの異なる要素の利用可能性を判定し、前記異なる要素が利用可能であるとき、前記プロファイルの前記異なる要素に関する前記オペレーションの結果を返すこととを備えることを特徴とする方法。請求項10に記載の方法であって、前記要求された要素が前記判定されたフォーマットとコンパチブルでなく、前記異なる要素が利用可能でないとき、エラーを返すことをさらに備えることを特徴とする方法。請求項11に記載の方法であって、前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す共通構造を変更することであって、前記共通構造が前記レガシーフォーマットおよび前記先進フォーマットを収容することをさらに備えることを特徴とする方法。請求項12に記載の方法であって、受け取ることは、前記オブジェクトおよび前記要求された要素に関して行う前記カラー管理オペレーションを識別する1または複数のパラメータが入ったアプリケーションプログラムインターフェースAPIコールとして前記要求を受け取ることを備えることを特徴とする方法。コンピューティングデバイスによって実行されるとき、コンポーネントからアプリケーションプログラムインターフェースAPIコールとしてカラー管理要求を受け取ることであって、前記APIコールがプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別するパラメータを含むことと、前記オブジェクトを分析して、前記オブジェクトに対応する前記プロファイルがレガシーフォーマットに対応するか、先進フォーマットに対応することを判定することと、前記オブジェクトに対応するプロファイルが前記レガシーフォーマットと関連付けられている場合、前記APIコールを処理するレガシー処理モジュールを呼び出すことと、前記オブジェクトに対応するプロファイルが前記先進フォーマットと関連付けられている場合、前記APIコールを処理する先進処理モジュールを呼び出すことと、前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す共通構造を変更することであって、前記共通構造が前記レガシーフォーマットおよび前記先進フォーマットを収容することと、API応答を返すことであって、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションを行い、前記要求された要素に関する前記オペレーションの結果を返すことと、前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでないとき、前記要求された要素に合致する前記プロファイルの異なる要素が利用可能であるときを判定し、前記異なる要素が利用可能であるとき、前記異なる要素に関する前記オペレーションを行い、前記異なる要素に関する前記オペレーションの結果を返すか、前記異なる要素が利用可能でないとき、エラーを返すこととを含むアクトを前記コンピューティングデバイスに行わせるコンピュータ実行可能命令を格納した1または複数のコンピュータ可読記憶媒体。請求項14に記載の1または複数のコンピュータ可読記憶媒体であって、分析することは、前記オブジェクトが前記レガシーフォーマットと関連付けられ、別のオブジェクトが前記先進フォーマットに関連付けられる場合、前記別のオブジェクトが前記APIコールに含まれた別のパラメータによって識別され、前記オブジェクトを前記先進フォーマットとコンパチブルであるように変換することを備えることを特徴とする1または複数のコンピュータ可読記憶媒体。従来の技術では、カラー管理のソリューションは、対応する新しいAPIセットを有するカラー管理システムの新バージョンが導入されるとき、レガシアプリケーションまたはソリューションを通常サポートしない。カラー管理システムの新バージョンは、レガシを変更および/または尾ひれをつけることによって、あるいはレガシAPIセットを先進のAPIセットで置き換えることによって、新しい機能、改良、および解決修繕をレガシバージョンの問題に提供することが可能である。そのような場合、レガシアプリケーションは、先進のAPIセットとコンパチブルではない可能性があり、それゆえ、カラー管理システムの新バージョンとコンパチブルではない可能性がある。一方、カラー管理システムがレガシAPIセットおよび先進のAPIセットの両方をサポートすることは、開発およびメインテナンスの問題を考慮すると、困難でコストがかかる可能性がある。レガシAPIと新しいカラー管理ソリューションとの互換性を提供することが当技術分野における進展である。本発明は、コンポーネント例えば、アプリケーションとシステム例えば、カラー管理システムとの間においてレガシアプリケーションプログラミングインターフェースAPIセットをサポートする方法および装置を提供する。システムによって提供される新しい機能および改良により、レガシAPIセットは、新しい機能および改良の両方、ならびにレガシ機能をサポートする。その結果、システムソフトウェアの更新および維持は容易になるが、その理由は、複数のAPIセットではなく、レガシAPIセットのみをサポートすればよいからである。さらに、レガシアプリケーションは、レガシAPIセットを使用してシステムと対話することができる。本発明の一態様では、カラー管理システムは、レガシAPIセットでレガシアプリケーションおよび先進のアプリケーションの両方をサポートすることができる。カラー管理システムは、APIコールによって参照されるオブジェクトについてフォーマットのタイプを決定する。オブジェクトがレガシフォーマットに関連付けられる場合、APIコールは、レガシ処理モジュールによって処理される。オブジェクトが先進のフォーマットに関連付けられる場合、APIコールは、先進の処理モジュールによって処理される。本発明の他の態様では、複数のオブジェクトがAPIコールに関連付けられ、複数のオブジェクトが混合したフォーマットを有する場合、カラー管理システムは、オブジェクトのフォーマットが一貫するように、オブジェクトのいくつかを変換する。次いで、カラー管理システムは、一貫フォーマットを有するオブジェクトについて要求されたオペレーションを実行する。本発明の他の態様では、共通構造が、レガシフォーマットまたは先進のフォーマットをサポートするために別々の構造を要求するのではなく、レガシフォーマットまたは先進のフォーマットのいずれかを有することが可能であるオブジェクトをサポートする。様々な実施形態の以下の記述において、その一部を形成し、本発明を実行することができる様々な実施形態が例として示される添付の図面を参照する。本発明の範囲から逸脱せずに、他の実施形態を使用することができ、構造上および機能上の修正を実施することができることを理解されたい。以下の用語の定義は、詳細な記述の理解を容易にするために含められている。チャネル-画像は、情報の1つまたは複数のチャネルを含む。一般に、カラーは、加法混合の原色赤、緑、および青によって表される。これらの3色のそれぞれのカラー情報は、それ自体のチャネルに符号化される。チャネルは、RGBに限定されず、チャネルは、ルミナンス輝度チャネルおよびクロミナンス彩度チャネル、または他のさらにより新奇な方式に分類することができる。チャネルを使用して、透明度など、カラー以外のものを符号化することもできる。画像のカラー品質の尺度は、チャネルあたりの符号化するために使用されるビット数bpchである。クリッピング-ソースデータの2つの異なる値が、宛先データの同じ値にマッピングされるたびに、値はクリッピングされると言われる。これは重要であるが、その理由は、クリッピングされたデータが元の状態に復元することができないからである情報は失われる。輝度またはコントラストの変更などのオペレーションは、データをクリッピングする可能性がある。カラー管理-カラー管理は、1つのデバイスによって記録されたカラーが、異なるデバイスにおいてユーザの好みに可能な限り忠実に表されることを保証するプロセスであり、しばしば、これはあるデバイス上の知覚を他へ整合させる。イメージングデバイスのセンサは、人の目と比較するとき、人の目が捉えることができるすべてのカラーおよびダイナミックレンジを捉える能力が限定されている。同じ問題が、表示デバイスおよび出力デバイスの両方に関して起きる。問題は、デバイスのすべての3つのクラスがこれらのカラーおよびダイナミックレンジの限定を有するが、そのいずれもまったく同じ形では限定されないことである。したがって、情報がワークフローを進む際に、変換規則をセットアップして、すでに限定されたカラーおよびダイナミックレンジの情報を可能な限り保存し、ならびに情報が人の目に可能な限り現実的であることを保証しなければならない。カラースペース-センサは、カラーを検出および記録することが可能であるが、未加工の電圧値は、基準がない場合、まったく意味をなさない。基準スケールは、センサ自体の測定された能力とすることができ、センサが特定の周波数応答スペクトルを有すると測定される場合、生成される数字は意味を有することになる。しかし、人の目によって可視であるすべてのカラーを表す共通の基準の方がより有用である。そのような基準CIELABとして知られるカラースペースにより、カラーを明瞭に表すことができ、他のデバイスがこの情報を利用して、カラーを再生するために最適を尽くすことができる。それぞれイメージングの分野内の特定の目的について開発されたsRGB、scRGB、アドビRGBを含め、様々な周知のカラースペースが存在する。カラーコンテキスト-記述されるカラースペースの色域の一般化された形態。あるファイルフォーマットが、特定のカラー管理規格によって記述される色域情報を使用する限り、カラーコンテキストは事実上同じ概念であるが、ICC色域をサポートしないファイル符号化フォーマットを含む。ダイナミックレンジ-数学的に、システムが符号化することができる最大値の信号を同じシステムが符号化することができる最小値の信号によって除算したもの。この値は、システムが符号化する情報のスケールの表示を与える。色域-プリンタまたはモニタなどの出力デバイスにおいて再生可能なカラーおよび密度値の範囲。色相-人が主波長を知覚するカラーの属性。色相、彩度、明度HSV-色相を角度として表し、彩度を中心からの距離として表す色相ダイアグラム。ICC-国際カラーコンソーシアム。強度-観測者がどのように知覚するかに関係なく、表面または光源からの光の純然たる量。精度-カラーを表す精度。ソースデータが適切なカラー分解能を有するとすれば、精度は、通常、各チャネルで符号化されるビット数を増加させることによって向上する。プロファイル-カラー管理システムがカラーを特定のカラースペースの内外に変換するのに十分な情報を含むファイル。これは、サブカテゴリ入力プロファイル、出力プロファイル、および表示プロファイルそれぞれ、入力デバイス、出力デバイス、および表示デバイス用を有するデバイスプロファイルと呼ばれるデバイスのカラースペース、または抽象カラースペースとすることが可能である。レンダリングインテント-より大きい色域からより小さい色域へ移行するとき、カラースペース間でカラーを変換する問題を取り扱う方法をカラー管理システムに通知するセッティング。彩度-カラーの純度。sRGB-インターネット、IEC61966-2-1の画像のための標準RGBカラースペース。scRGB-標準コンピューティングRGBカラースペース、IEC61966-2-2。ワークフロー-ドキュメントの数字がどのカラーを表すかを定義し、ワークがキャプチャから編集を通して出力に進む際に、それらのカラーを保持または制御するプロセス。図1は、本発明を実施することができる適切なコンピューティングシステム環境100の例を示す。特に、図1は、コンピューティングシステム環境100のコンテキストにおける、光学無線マウスなどの無線ポインタデバイス161のオペレーションを示す。コンピューティングシステム環境100は、適切なコンピューティング環境の単なる一例であり、本発明の使用範囲または機能に関する限定を示唆することを意図するものではない。コンピューティング環境100は、例示的なオペレーティング環境100において示されるコンポーネントのいずれか1つまたは組合せに関する依存性または必要性を有すると解釈されるべきではない。本発明は、多くの他の汎用または専用のコンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用されるのに適切である可能性がある周知のコンピューティングシステム、環境、および/または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能家電、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散型コンピューティング環境などがあるが、これに限定されるものではない。本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストにおいて記述することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象的なデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、タスクが通信ネットワークを経てリンクされるリモート処理デバイスによって実行される、分散型コンピューティング環境において実行することもできる。分散型コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含め、ローカルおよびリモートのコンピュータ記憶メディアの両方に配置することができる。図1を参照すると、本発明を実施する例示的なシステムは、コンピュータ110の形態の汎用コンピューティングデバイスを含む。コンピュータ110のコンポーネントは、処理ユニット120、システムメモリ130、およびシステムメモリを含めて様々なシステムコンポーネントを処理ユニット120に結合するシステムバス121を含むことが可能であるが、これに限定されるものではない。システムバス121は、メモリバスまたはメモリ制御デバイス、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含め、いくつかのタイプのバス構造のいずれかとすることが可能である。例として、そのようなアーキテクチャには、ISAIndustryStandardArchitectureバス、MCAMicroChannelArchitectureバス、拡張ISAEnhancedISAバス、VESAVideoElectronicsStandardsAssociationローカルバス、およびメザニンバスとしても知られるPCIPeripheralComponentInterconnectバスがあるが、これに限定されるものではない。コンピュータ110は、通常、様々なコンピュータ可読メディアを含む。コンピュータ可読メディアは、コンピュータ110によってアクセスすることができる任意の利用可能なメディアとすることができ、揮発性および不揮発性のメディア、リムーバブルおよび非リムーバブルなメディアの両方を含む。例として、コンピュータ可読メディアは、コンピュータ記憶メディアおよび通信メディアを備えることが可能であるが、これに限定されるものではない。コンピュータ記憶メディアには、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納する任意の方法または技術において実施される揮発性および不揮発性、リムーバブルおよび非リムーバブルのメディアの両方がある。コンピュータ記憶メディアには、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD-ROM、デジタル多用途ディスクDVDまたは他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ、あるいは所望の情報を格納するために使用することができ、コンピュータ110によってアクセスすることができる任意の他の媒体があるが、これに限定されるものではない。通信メディアは、通常、搬送波などの変調データ信号または他のトランスポート機構において、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実現し、任意の情報送達メディアを含む。変調データ信号という用語は、信号の情報を符号化するような形でその特徴の1つまたは複数を設定または変更した信号を意味する。例として、限定ではなく、通信メディアには、有線ネットワークまたは直接配線接続などの有線メディア、および音声、RF、赤外線などの無線メディア、および他の無線メディアがある。上記のいずれかの組合せも、コンピュータ可読メディアの範囲内に含まれる。システムメモリ130は、読取専用メモリROM131およびランダムアクセスメモリRAM132など、揮発性メモリおよび/または不揮発性メモリの形態のコンピュータ記憶メディアを含む。起動中などにコンピュータ110内の要素間において情報を転送するように作用する基本ルーチンを含む基本的な入力/出力システム133BIOSは、通常、ROM131に格納される。RAM132は、通常、処理ユニット120に即座にアクセス可能であり、および/または処理ユニット120によって現在動作されているデータおよび/またはプログラムモジュールを含む。例として、限定ではなく、図1は、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137を示す。コンピュータ110は、他のリムーバブル/非リムーバブル、揮発性/不揮発性コンピュータ記憶メディアをも含むことが可能である。例としてのみ、図1は、非リムーバブル不揮発性磁気メディアから読み取り、またはそれに書き込むハードディスクドライブ140、リムーバブル不揮発性磁気ディスク152から読み取り、またはそれに書き込む磁気ディスクドライブ151、およびCDROMまたは他の光学メディアなどのリムーバブル不揮発性光学ディスク156から読み取り、またはそれに書き込む光ディスクドライブ155を示す。例示的なオペレーティング環境において使用することができる他のリムーバブル/非リムーバブル、揮発性/不揮発性コンピュータ記憶メディアには、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体RAM、半導体ROMなどがあるが、これに限定されるものではない。ハードディスクドライブ141は、通常、インターフェース140などの非リムーバブルメモリインターフェースを経てシステムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は、通常、インターフェース150などのリムーバブルメモリインターフェースによってシステムバス121に接続される。上記で議論され、図1に示されるデバイスおよびそれに関連するコンピュータ記憶メディアは、コンピュータ110のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。図1では、例えば、ハードディスクドライブ141が、オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137と同じか、または異なるものとすることができることに留意されたい。オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147は、ここでは、少なくとも、それらが異なるコピーであることを示すために、異なる数字が与えられている。ユーザは、マウス、トラックボール、またはタッチパッドと一般に呼ばれるキーボード162および無線ポインティングデバイス161などの入力デバイスにより、コマンドおよび情報をコンピュータ110に入力することが可能である。本発明の一実施形態では、無線ポインティングデバイス161は、マウスの動きを検出する光センサを有するマウスとして実施することができる。他の入力デバイス図示せずは、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含むことが可能である。これらおよび他の入力デバイスは、システムバスに結合されるユーザ入力インターフェース160を経て処理ユニット120にしばしば接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアスバスUSBなど、他のインターフェースおよびバス構造によって接続することができる。図1では、無線ポインタ161は、無線チャネル199によりユーザ入力インターフェース160と通信する。無線チャネル199は、無線周波数RF信号、赤外線信号、または可視光信号など、電磁信号を使用する。モニタ191または他のタイプの表示デバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。モニタの他に、コンピュータは、スピーカ197およびプリンタ196などの他の周辺出力デバイスをも含むことが可能であり、出力周辺インターフェース190を経て接続することが可能である。コンピュータ110は、リモートコンピュータ180など、1つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境において動作することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、または他の共通ネットワークノードとすることが可能であり、通常、コンピュータ110に関して上述された要素の多くまたはすべてを含むが、図1には、メモリストレージ181のみが示されている。図1に示される論理接続は、ローカルエリアネットワークLAN171およびワイドエリアネットワークWAN173を含むが、他のネットワークを含むことも可能である。そのようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。LANネットワーキング環境において使用されるとき、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を経てLAN171に接続される。WANネットワーキング環境において使用されるとき、コンピュータ110は、インターネットなどのWAN173による通信を確立するためのモデム172または他の手段を通常含む。モデム172は、内蔵または外付けとすることが可能であり、ユーザ入力インターフェース160または他の適切な機構を介してシステムバス121に接続することができる。ネットワーク環境では、コンピュータ110に対して示されるプログラムモジュール、またはその一部は、リモートメモリストレージに格納することができる。例として、限定ではなく、図1は、リモートアプリケーションプログラム185がメモリデバイス181の上にあるように示している。示されるネットワーク接続は、例示であり、コンピュータ間において通信リンクを確立する他の手段を使用することができることが理解されるであろう。周辺インターフェース195は、スキャナ図示せずまたはデジタルカメラ194などのビデオ入力デバイスへインターフェースすることが可能であり、この場合、出力周辺インターフェースは、ユニバーサルシリアルバスUSBインターフェースを含め、標準インターフェースをサポートすることが可能である。オペレーティングシステム134によって、またはアプリケーション135によってサポートすることが可能であるカラー管理は、コンピュータデバイス間において望ましいカラー変換を得ることについてユーザを補助する。コンピュータデバイスは、デジタルカメラ194などの入力デバイス、通常、モニタ191などの表示デバイス、およびプリンタ196などの出力デバイスとして分類される。カラー管理のオペレーションは、以下の議論においてより詳細に説明される。図2は、本発明の一実施形態によってサポートされる国際カラーコンソーシアムICCプロファイル200を示す。ICCプロファイル200は、測定-デバイスモデルセグメント201、カラー外観モデルセグメント203、および色域マッピングアルゴリズムセグメント205を含む。この実施形態では、プロファイル200は、ICCのウェブサイトhttpwwwcolororgから利用可能であるICC仕様バージョン3.0から4.0に準拠する。測定-デバイスモデルセグメント201は、複数の比色値ならびに照度に関する情報でデバイスを特徴付ける。カラー外観モデルセグメント203は、入力照度およびビュー環境に基づいて、比色値をプロファイル接続空間PCSに変換するために使用される。対応するカラー外観モデルは、多くの場合、独自のものである。色域マッピングアルゴリズムセグメント205は、基準媒体と特定の出力デバイスとの間のカラー色域の違いを考慮する。ICCプロファイル200では、色域マッピングアルゴリズムセグメント205は、ソースプロファイル接続空間が宛先プロファイル接続空間に等価であると想定する。ICCプロファイル200は、以下の議論において参照されるプロファイルのレガシフォーマットを例示する。ICCプロファイル200は、ブラックボックスアプローチを想定する2進フォーマットで通常表される。結果として、ユーザは、ICCプロファイル200が、他のプロファイルフォーマットによって対処することができる重大な欠点を有すると結論することがある。図3は、本発明の一実施形態によってサポートされる仮想デバイスモデルプロファイル300を示す。仮想デバイスモデルプロファイル300は、ICCプロファイル200に関連する欠点のいくつかを解決する。仮想デバイスモデルプロファイル300は、測定デバイスモデルセグメント301、カラー外観モデルセグメント303、色域マッピングアルゴリズムセグメント305、反転カラー外観モデルセグメント307、および宛先測定モデルセグメント309を含む。仮想デバイスモデルプロファイル300は、ユーザにとって有利である可能性があるいくつかの特徴を有する。例えば、プロファイル300は、ソースプロファイル空間が宛先プロファイル空間と等価であると想定しない。カラー外観モデルカラー外観モデルセグメント303および反転カラー外観モデルセグメント307に対応するは、独自のものであることを必要とせず、CIEベースのカラー外観モデルを使用することが可能である。また、プロファイル300は、ICCプロファイル200によって使用される2進フォーマットではなく、テキストフォーマット例えば、拡張可能マークアップ言語XMLを使用することによって、よりアクセス可能とすることが可能である。仮想デバイスモデルプロファイル300は、以下の議論において参照されるように、先進のプロファイルフォーマットを例示する。図4は、本発明の一実施形態によるカラー管理システムのアーキテクチャ400を示す。カラー管理システムは、API層モジュール401、APIアダプテーション層モジュール407、レガシ処理モジュール417、および先進の処理モジュール419を備える。この実施形態では、API層モジュール401およびAPIアダプテーション層モジュール407は、ICM2ImageColorManagement2など、レガシAPIセットをサポートする。ICM2は、ウィンドウズ登録商標98およびそれ以降に組み込まれている。ICM2は、OPEN/CLOSEプロファイルGET/SETプロファイル要素CREATETRANSFORMTRANSFORMCOLORSを含む、様々なAPIカテゴリを有するレガシアプリケーションプログラムインターフェースAPIセットをサポートする。APIコールは、通常、少なくとも1つのパラメータを含む。パラメータは、プロファイルオブジェクトまたはトランスフォームオブジェクトなどのオブジェクトを特定するポインタとすることが可能である。APIセットのOPENカテゴリにより、アプリケーションによって指定プロファイルにアクセスすることが可能になる。指定カテゴリがオープンにされると、プロファイル要素は、APIセットのGET/SETカテゴリを使用して、アプリケーションによって読み取るか、または書き込むことができる。カラー管理システムがソース画像を宛先画像に変換するために、変換ルックアップテーブル通常多次元であるが、ソースプロファイルおよび宛先プロファイルなど、プロファイルの指定セットから構築される。アプリケーションは、CREATETRANSFORMカテゴリを使用することによって、ルックアップテーブルの構築を呼び出すことができる。ルックアップテーブルが構築されると、APIセットのTRANSFORMCOLORSカテゴリを使用することによって、ソース画像を宛先画像に画素ごとに変換するように、カラー管理システムに命令することができる。図4を参照すると、レガシアプリケーション403および先進のアプリケーション405は、API層モジュール401と対話して、どの処理モジュールがAPI要求を処理するべきであるかを決定する。アプリケーション403および405の両方とも、API要求をAPI層モジュール401に送る。APIコール409、APIリターン結果411、APIコール413、およびAPIリターン結果415の構造およびフォーマットが、レガシフォーマットに準拠する限り、先進のアプリケーション405は、先進の処理モジュール419によって提供される機能および改良を使用することができる。しかし、レガシアプリケーション403は、修正せずに、レガシAPIセットを使用し続けることができる。例えば、先進のアプリケーション405は、仮想デバイスモデルプロファイル300を使用して、APIコールにおいて1つまたは複数の指定プロファイルを表すことが可能である。APIアダプテーション層モジュール407は、APIコールにおいて特定されるオブジェクトを分析して、オブジェクトがレガシフォーマットを有するか例えば、ICCプロファイル200、またはオブジェクトが先進のフォーマット例えば、仮想デバイスモデルプロファイル300を有するかを判定する。先進のフォーマットは、非レガシフォーマットであると定義することができる。オブジェクトがレガシフォーマットを有する場合、レガシ処理モジュール417がAPIコールを処理する。オブジェクトが先進のフォーマットを有する場合、先進の処理モジュール419がAPIコールを処理する。APIコールによって特定される1セットのオブジェクトのオブジェクトが、混合フォーマットを有する場合、すなわち、オブジェクトの1つがレガシフォーマットを有し、他のオブジェクトが先進のフォーマットを有する場合、オブジェクトのいくつかのフォーマットは、オブジェクトのすべてのフォーマットが一貫するように変換される。例として、宛先プロファイルおよびソースプロファイルが異なるフォーマットを有する場合1つのプロファイルがレガシフォーマットを有し、他のプロファイルが先進のフォーマットを有する場合、レガシフォーマットを有するオブジェクトのフォーマットは、先進のフォーマットに変換される。この実施形態では、APIアダプテーション層モジュール407は、表1に示される論理を使用して、フォーマット変換を決定する本発明の他の実施形態では、フォーマット変換は、カラー管理システムの他のモジュールによって実行することができる。表1に示される実施形態では、1セットのオブジェクトの任意のオブジェクトが先進のフォーマットに関連付けられる場合、レガシフォーマットを有するセットの任意の残りのオブジェクトは、セットのすべてのオブジェクトが、フォーマット変換後、先進のフォーマットを有するように、先進のフォーマットに変換される。先進のモジュール419がその後呼び出されて、APIコールを処理する。この実施形態では、表1に示されるように、オブジェクトのセットのすべてのオブジェクトがレガシフォーマットに関連付けられる場合、オブジェクトのいずれも、先進のフォーマットに変換されない。レガシモジュール417がその後呼び出されて、APIコールを処理する。しかし、他の実施形態では、ポリシにより、フォーマットオーバーライドインジケータを構成することができ先進のフォーマットのみに対応する、それにより、オブジェクトのセットの任意のオブジェクトが先進のフォーマットに関連付けられるかに関係なく、レガシフォーマットを有するすべてのオブジェクトが、先進のフォーマットに変換される。さらに、ポリシは、フォーマットオーバーライドインジケータ先進のフォーマットを好むに対応するを構成するための複数のモード選択をサポートすることが可能であり、それにより、すべてのレガシオブジェクトは、無条件では先進のフォーマットに変換されない。すなわち、上述されたように、レガシオブジェクトは、少なくとも1つのオブジェクトが先進のフォーマットを有する場合のみ、先進のフォーマットに変換される。この実施形態は、レガシフォーマットのみおよびレガシフォーマットを好むなど、他のモード選択をサポートすることが可能である。表2は、これらのモード選択によるオペレーションを示す。この実施形態は、オブジェクトをレガシフォーマットから先進のフォーマットに変換するが、他の実施形態は、オブジェクトを先進のフォーマットからレガシフォーマットに変換することが可能である。しかし、レガシソフトウェアは、更新が非レガシソフトウェアに組み込まれる間、通常フリーズされる。その場合、レガシソフトウェアの修正を回避するために、表1に示されるようにレガシフォーマットを先進のフォーマットに変換することが有利である可能性がある。図5は、本発明の一実施形態に従って要求コンポーネント505が中間コンポーネント503を通してカラー管理システム510へのAPIコール507を呼び出すことを示す。図5に示される構成では、中間コンポーネント503は、APIコール507をカラー管理システム501に中継し、カラー管理システム501からのAPIリターン結果509を要求コンポーネント505に中継する。この実施形態では、中間コンポーネント503は、アプリケーションまたはユーティリティとすることが可能である。図6は、本発明の一実施形態に従ってソース画像ドキュメント601または605から宛先画像ドキュメントにカラー情報を変換するカラー管理システム600のアーキテクチャを示す。カラー管理システム600は、レガシモジュール417と、先進の処理モジュール419と、カラー管理システムに関連付けられる様々なオブジェクトをサポートする複数の構造とを備える。この実施形態では、構造609、611、613、および615は、レガシフォーマットレガシソースプロファイル609、レガシ宛先プロファイル611、およびレガシ変換表617と、先進のフォーマット先進のソースプロファイル613、先進の宛先プロファイル615、および先進の変換表619とに別々に関連付けられる。必要であれば、上記で議論されたように、レガシソースプロファイル609は、フォーマット変換651により先進のソースプロファイル613に変換され、レガシ宛先プロファイル611は、フォーマット変換653により先進の宛先プロファイル615に変換される。図7は、本発明の一実施形態に従って画像ドキュメントを処理する共通構造を使用するカラー管理システム701のアーキテクチャ700を示す。レガシ処理モジュール707、先進の処理モジュール709、API層モジュール703、およびAPIアダプテーションモジュール705は、それぞれ、図4に示されるレガシ処理モジュール417、先進の処理モジュール419、API層モジュール401、およびAPIアダプテーション層モジュール407に対応する。コンポーネント717は、APIコールでカラーオペレーションを要求する。アーキテクチャ700は、レガシフォーマットまたは先進のフォーマットで、オブジェクトの共通構造をサポートする。例えば、ソースプロファイル構造711、宛先プロファイル構造713、および変換構造715は、それぞれ、ソースプロファイル、宛先プロファイル、および変換ルックアップテーブルについてレガシフォーマットまたは先進のフォーマットをサポートする。この実施形態では、構造711、713、および715は、ハンドルを使用して、オブジェクトの要素を特定し、この場合、ヌルポインタが、オブジェクトのフォーマットとは異なるフォーマットに対応する要素を表すハンドルはポインタごとである。しかし、本発明の他の実施形態は、ポインタなど、他の特定機構を使用することが可能である。図8は、本発明の一実施形態に従ってGET/SETAPIカテゴリを処理する流れ図800を示す。以前に議論されたように、GET/SETカテゴリにより、アプリケーションが、プロファイル要素を取り出すか、または設定することが可能になる。流れ図800では、指定プロファイルが、レガシフォーマットまたは先進のフォーマットを有することが可能である。ステップ801において、カラー管理システムは、APIコールを受け取って、プロファイルの要素を取り出すか、または設定する。ステップ803において、カラー管理システムは、要求された要素がプロファイルフォーマットと一貫するかを判定する。要素は、レガシフォーマットでサポートすることができるが、先進のフォーマットでサポートすることはできない可能性があり、逆もまた同じである。例えば、好ましいCMM要素は、ICCフォーマット200でサポートすることができるが、仮想デバイスモデルプロファイル300でサポートすることはできない。ステップ803により、プロファイル要素がプロファイルフォーマットと一貫すると判定される場合、要素は、ステップ809において返される。ステップ803により、プロファイル要素がプロファイルフォーマットと一貫しないと判定される場合、エラー表示が返される。他の実施形態では、カラー管理システムはエラー表示を返すのではなく、カラー管理システムは、要求されたプロファイル要素に最適に整合するプロファイル要素プロファイルフォーマットに対応するを決定して、ステップ807において、整合プロファイル要素に関する情報を返す。図4~図7に示される実施形態は、コンポーネントとカラー管理システムとの間においてアプリケーションプログラムインターフェースをサポートするが、本発明は、他のタイプのシステムのレガシAPIによるシステム改良をサポートすることが可能である。その結果、レガシAPIは、システムの改良および新しい機能をサポートすることができ、一方、レガシアプリケーションは、レガシアプリケーションを修正せずに、システムとの対話を続行することが可能になる。プログラミングインターフェースまたは、より簡単にはインターフェースは、コードの1つまたは複数のセグメントが、コードの1つまたは複数の他のセグメントによって提供される機能と通信するか、またはそれにアクセスすることを可能にする任意の機構、プロセス、プロトコルと見なすことができる。代替として、プログラミングインターフェースは、他のコンポーネントの1つまたは複数の機構、メソッド、関数コール、モジュールなどに通信結合することができるシステムのコンポーネントの1つまたは複数の機構、メソッド、関数コール、モジュール、オブジェクトなどと見なすことができる。前文のコードのセグメントという用語は、1つまたは複数の命令またはコードのラインを含むことが意図され、適用される用語、またはコードセグメントが別々にコンパイルされるか、またはコードセグメントがソースコード、中間コード、もしくはオブジェクトコードとして提供されるか、コードセグメントがランタイムシステムまたはプロセスにおいて使用されるか、または、コードセグメントが同じマシン、もしくは異なるマシンにあるか、もしくは複数のマシンにわたって分散するか、または、コードのセグメントによって現される機能が、完全にソフトウェアにおいて、完全にハードウェアにおいて、もしくはハードウェアおよびソフトウェアの組合せにおいて実施されるかに関係なく、同じコードモジュール、オブジェクト、サブルーチン、機能などを含む。概念的には、プログラミングインターフェースは、図9または図10に示されるように一般的に見ることができる。図9は、第1コードセグメントおよび第2コードセグメントが通信するコンジットとしてのインターフェース、インターフェース1を示す。図10は、インターフェースオブジェクトI1およびI2第1コードセグメントおよび第2コードセグメントの一部であるか、または一部ではないことが可能であるを備えるものとしてのインターフェースを示し、これにより、システムの第1コードセグメントおよび第2コードセグメントは、媒体Mを介して通信することが可能になる。図10を考慮すると、インターフェースオブジェクトI1およびI2を同じシステムの別々のインターフェースと見なすことが可能であり、また、オブジェクトI1およびI2ならびに媒体Mがインターフェースを備えるものと見なすことが可能である。図9および図10は、フローの各側における双方向のフローおよびインターフェースを示すが、ある実施態様は、一方向の情報フローのみもしくは、以下で記述されるように情報フローなしを有することが可能であり、または、インターフェースオブジェクトを一方の側においてのみ有することが可能である。例として、限定ではなく、アプリケーションプログラミングインターフェースAPI、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデルCOMインターフェースなどの用語は、プログラミングインターフェースの定義内に内包される。そのようなプログラミングインターフェースの態様は、第1コードセグメントが情報を第2コードセグメントに送信する方法情報は、最も広範な意味で使用され、データ、コマンド、要求などを含む、第2コードセグメントが情報を受信するメソッド、ならびに情報の構造、シーケンス、シンタックス、編成、スキーマ、タイミング、および内容を含むことが可能である。これに関して、情報がインターフェースによって定義される形でトランスポートされる限り、媒体が有線または無線であるか、もしくは両方の組合せであるかに関係なく、基礎となるトランスポート自体は、インターフェースのオペレーションに重要ではない場合がある。ある状況では、情報は、従来の意味で一方向または両方向で渡されないことがあるが、その理由は、1つのコードセグメントが第2コードセグメントによって実行される機能に単にアクセスするときのように、情報の転送が、他の機構例えば、コードセグメント間の情報フローとは別に、バッファ、ファイルなどに配置される情報を介するか、または存在しないことがあるからである。これらの態様のいずれかまたはすべては、コードセグメントが、疎結合された構成、または密結合された構成においてシステムの一部であるかに応じてなど、所与の状況において重要である可能性があり、したがって、このリストは、例示であり、限定ではないと見なされるべきである。プログラミングインターフェースのこの概念は、当業者には既知であり、本発明の以上の詳細な記述から明らかである。しかし、プログラミングインターフェースを実施する他の方式があり、明らかに排除されない限り、これらも、本明細書の終わりに述べられる請求項によって包含されることを意図する。そのような他の方式は、図9および図10の簡略的な図より洗練され、または複雑であるように見える可能性があるが、それにもかかわらず、同じ機能を実行して、同じ全体的な結果を達成する。ここで、プログラミングインターフェースのいくつかの例示的な代替実施態様を簡潔に記述する。1つのコードセグメントから他への通信は、通信を複数の離散通信に分割することによって間接的に達成することができる。これは、図11および図12に概略的に示される。図示されるように、機能の分割可能なセットの観点で、いくつかのインターフェースを記述することができる。それゆえ、数学では、24すなわち2かける2かける3かける2を提供することが可能であるように、図9および図10のインターフェース機能をファクタ化して、同じ結果を達成することが可能である。したがって、図11に示されるように、インターフェース、インターフェース1によって提供される機能は、インターフェースの通信を複数のインターフェース、インターフェース1A、インターフェース1B、インターフェース1Cなどに変換するように、さらに分割し、一方、同じ結果を達成することが可能である。図12に示されるように、インターフェースI1によって提供される機能は、複数のインターフェースI1a、I1b、I1cなどにさらに分割し、一方、同じ結果を達成することが可能である。同様に、第1コードセグメントから情報を受信する第2コードセグメントのインターフェースI2は、複数のインターフェースI2a、I2b、I2cなどにファクタ化することができる。ファクタ化するとき、第1コードセグメントに含まれるインターフェースの数は、第2コードセグメントに含まれるインターフェースの数と整合する必要はない。図11および図12の場合のどちらにおいても、インターフェース、インターフェース1およびI1の機能的趣旨は、それぞれ、図9および図10と依然として同じである。インターフェースのファクタ化は、ファクタ化を認識することが困難であることがるように、結合、可換、および他の数学的プロパティに準拠することも可能である。例えば、オペレーションの順序は、重要ではないこともあり、その結果、インターフェースによって実行される機能は、他のコードまたはインターフェースの部分によって、インターフェースに到達するかなり前に実行する、またはシステムの別のコンポーネントによって実行することが可能である。さらに、プログラミング分野の技術者なら、同じ結果を達成する様々な関数コールを作成する様々な方式があることを理解することができる。いくつかの場合、プログラミングインターフェースのある態様例えば、パラメータを無視、追加、または再定義する一方、意図した結果を依然として達成することが可能であることがある。これは、図13および図14に示される。例えば、図9のインターフェース、インターフェース1が、関数コールSquare入力、精度、出力を含むと想定し、入力、精度、出力の3つのパラメータを含むコールは、第1コードセグメントから第2コードセグメントに発行される。図13に示されるように、中間パラメータの精度が所与のシナリオにおいて重要ではない場合、単に無視することができ、またはさらには無意味なこの状況ではパラメータで置き換えることができる。また、重要ではない追加パラメータを追加することも可能である。どちらの場合でも、入力が第2コードセグメントによってスクエアされた後、出力が返される限り、スクエアの機能を達成することができる。精度は、コンピューティングシステムにおける何らかのダウンストリームまたは他の部分にとって、意味のあるパラメータである可能性が非常に高いが、精度が、スクエアを計算する狭義の目的では必要ではないと認識されると、置き換えるか、または無視することができる。例えば、有効な精度値を渡す代わりに、結果に悪影響を与えずに、誕生日などの無意味な値を渡すことができる。同様に、図14に示されるように、インターフェースI1は、インターフェースI1’によって置き換えられ、パラメータを無視するか、またはパラメータをインターフェースに追加するように再定義される。インターフェースI2は、同様に、インターフェースI2’として再定義し、不必要なパラメータ、または他で処理することができるパラメータを無視するように再定義することができる。ここで重要なことは、いくつかの場合、プログラミングインターフェースは、ある目的には必要とされないパラメータなどの態様を含むことが可能であり、したがって、無視するか、または再定義するか、あるいは他の目的について他で処理することができる。また、2つの別々のコードモジュール間のインターフェースが形態を変更するように、それらのモジュールの機能のいくつかまたはすべてをマージすることも実行可能であることがある。例えば、図9および図10の機能は、それぞれ、図15および図16の機能に変換することができる。図15では、図9の以前の第1コードセグメントおよび第2コードセグメントは、それらの両方を含むモジュールにマージされる。この場合、コードセグメントは、互いに依然として通信することが可能であるが、インターフェースは、単一モジュールにより適切である形態に適合することができる。それゆえ、例えば、フォーマルコールおよびリターンステートメントは、もはや必要ではない可能性があるが、インターフェース、インターフェース1による同様の処理または応答は、依然として有効である可能性がある。同様に、図16に示されるように、図10からのインターフェースI2の一部またはすべては、インターフェースI1を形成するように、インターフェースI1にインライン式に書き込むことができる。図示されるように、インターフェースI2は、I2aおよびI2bに分割され、インターフェース部分I2aは、インターフェースI1とインライン式にコード化されて、インターフェースI1を形成する。具体的な例として、図10のインターフェースI1が関数コールSqure入力、出力を実行し、これは、インターフェースI2によって受信され、その値を処理した後、第2コードセグメントによって入力と共に渡されそれをスクエアするために、出力と共にスクエアされた結果を再び渡すことを考慮する。そのような場合、第2コードセグメントによって実行される処理入力をスクエアするは、インターフェースへのコールなしで、第1コードセグメントによって実行することができる。1つのコードセグメントから他への通信は、通信を複数の離散通信に分割することによって、間接的に達成することができる。これは、図17および図18に概略的に示される。図17に示されるように、ミドルウェア元のインターフェースから機能および/またはインターフェース機能を分離するので分離インターフェースの1つまたは複数の部分は、第1インターフェースであるインターフェース1での通信を変換して、それらを異なるインターフェース、この場合はインターフェース、インターフェース2A、インターフェース2B、およびインターフェース2Cに準拠させるために提供される。これは、実行することができるが、例えば、インターフェース1プロトコルに従ってオペレーティングシステムなどと通信するように設計されるアプリケーションのインストールベースが存在するが、次いで、オペレーティングシステムが、この場合はインターフェース、インターフェース2A、インターフェース2B、およびインターフェース2Cである異なるインターフェースを使用するように要求される場合である。重要なことは、第2コードセグメントによって使用される元のインターフェースが、第1コードセグメントによって使用されるインターフェースともはやコンパチブルではないように変更され、それにより、媒介物を使用して、旧インターフェースおよび新インターフェースをコンパチブルにすることである。同様に、図18に示されるように、第3コードセグメントを分離インターフェースDI1と共に導入して、インターフェースI1から通信を受信することができ、また分離インターフェースDI2と共に導入して、DI2と共に作用するが、同じ機能的結果を提供するように再設計されたインターフェースI2aおよびI2bなどにインターフェース機能を送信することができる。同様に、DI1およびDI2は、共に作用して、図10のインターフェースI1およびI2の機能を新しいオペレーティングシステムに転送し、一方、同じまたは同様の機能的結果を提供することが可能である。他の可能な変形形態は、コードを動的に書き直して、インターフェース機能をその他と置き換えるが、同じ全体的な結果を達成するようにすることである。例えば、中間言語例えば、マイクロソフトIL、Java登録商標ByteCodeなどにおいて提示されるコードセグメントが実行環境.NETフレームワーク、Java登録商標ランタイム環境、または他の同様のランタイムタイプ環境によって提供されるものなどにおいてジャストインタイムJITコンパイラまたはインタープリタに提供されるシステムが存在することが可能である。JITコンパイラは、第1コードセグメントから第2コードセグメントに通信を動的に変換する、すなわち通信を第2コードセグメント元のまたは異なる第2コードセグメントによって要求することができる異なるインターフェースに準拠させるように書くことができる。これは、図19および図20に示される。図19からわかるように、このアプローチは、上述された分離シナリオと同様である。これは、実行することができるが、例えば、アプリケーションのインストールベースが、インターフェース1プロトコルに従ってオペレーティングシステムと通信するように設計されるが、次いで、オペレーティングシステムが、変更されて、異なるインターフェースを使用する場合である。JITコンパイラを使用して、通信をインストールベースアプリケーションからオペレーティングシステムの新しいインターフェースに実行中に準拠させることができる。図20に示されるように、インターフェースを動的に書き直すこのアプローチを適用して、動的にインターフェースを分解するか、そうでなければインターフェースを同様に変更することができる。また、代替実施形態によるインターフェースと同じまたは同様の結果を達成する上述されたシナリオは、様々な方法でシリアルおよび/またはパラレルに、あるいは他の介在コードと共に、組み合わせることもできることにも留意されたい。それゆえ、上記で提示された代替実施形態は、相互に排他的ではなく、混合、整合、および組み合わせて、図9および図10において提示された一般的なシナリオと同じまたは等価のシナリオを生成することができる。また、ほとんどのプログラミング構築の場合と同様に、本明細書において記述されていない可能性があるが、それにもかかわらず、本発明の精神および範囲によって表されるインターフェースの同じまたは同様の機能を達成する他の類似の方法が存在することにも留意されたい。すなわち、これは、少なくとも部分的には、インターフェースの価値の基盤となる、インターフェースによって表される機能、およびインターフェースよって可能になる有利な結果であることに留意されたい。本発明は、本発明を実行する現在好ましいモードを含めて、特定の例に関して記述されたが、当業者なら、添付の請求項において述べられる本発明の精神および範囲内にある上述されたシステムおよび技術の多くの変更および置換が存在することを理解するであろう。