一又は複数のブレークイベントを発行する方法であって、第1のイベントソースからの第1のブレークイベントを検出するステップと、第2のイベントソースからの第2のブレークイベントを検出するステップと、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントのプラットフォームへの発行を協調するステップとを有する方法。前記第1と第2のブレークイベントの発行を協調するステップは、前記ランタイム情報に少なくとも部分的に基づいて保持時間を決定するステップと、前記保持時間に少なくとも部分的に基づいて前記第1と第2のブレークイベントのうち少なくとも一方を延期するステップとを含む、請求項1に記載の方法。前記第1と第2のイベントソースのうち少なくとも一方から前記ランタイム情報を取得するステップをさらに含む、請求項1に記載の方法。前記ランタイム情報は前記プラットフォームに結合した装置から取得され、前記第1と第2のブレークイベントのうちの少なくとも一方は入出力イベントを含み、前記ランタイム情報は前記入出力イベントの遅延時間を示す、請求項3に記載の方法。前記ランタイム情報は前記プラットフォーム上のアクティブアプリケーションから取得され、前記第1と第2のブレークイベントのうちの少なくとも一方はタイマーイベントを含み、前記ランタイム情報は前記タイマーイベントの遅延可能特性を示す、請求項3に記載の方法。前記プラットフォームから前記ランタイム情報を取得するステップをさらに含む、請求項1に記載の方法。前記ランタイム情報は低電力状態ブレークイーブン時間を特定する、請求項6に記載の方法。前記ランタイム情報はプログラム可能性能要件を特定する、請求項6に記載の方法。一又は複数のブレークイベントを発行する装置であって、入出力モジュールを有し、前記入出力モジュールは、第1のイベントソースからの第1のブレークイベントを検出する手段と、第2のイベントソースからの第2のブレークイベントを検出する手段と、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントのプラットフォームへの発行を協調する手段とを有する装置。前記第1と第2のブレークイベントの発行の協調は、前記ランタイム情報に少なくとも部分的に基づく保持時間の決定と、前記保持時間に少なくとも部分的に基づく前記第1と第2のブレークイベントのうち少なくとも一方の延期とを含む、請求項9に記載の装置。前記入出力モジュールは、前記第1と第2のイベントソースのうち少なくとも一方から前記ランタイム情報を取得する手段をさらに含む、請求項9に記載の装置。前記ランタイム情報は前記プラットフォームに結合した装置から取得されるものであり、前記第1と第2のブレークイベントのうちの少なくとも一方は入出力イベントを含むものであり、前記ランタイム情報は前記入出力イベントの遅延時間を示すものである、請求項11に記載の装置。前記ランタイム情報は前記プラットフォーム上のアクティブアプリケーションから取得されるものであり、前記第1と第2のブレークイベントのうちの少なくとも一方はタイマーイベントを含むものであり、前記ランタイム情報は前記タイマーイベントの遅延可能特性を示すものである、請求項11に記載の装置。前記入出力モジュールは、前記プラットフォームから前記ランタイム情報を取得するロジックをさらに含み、前記ランタイム情報は、低電力状態ブレークイーブン時間とプログラム可能性能要件のうち少なくとも一方を特定するものである、請求項9に記載の装置。一又は複数のブレークイベントを発行するシステムであって、第1のイベントソースと、第2のイベントソースと、プロセッサと、前記プロセッサに結合した入出力モジュールとを有し、前記入出力モジュールは、前記第1のイベントソースからの第1のブレークイベントを検出する手段と、前記第2のイベントソースからの第2のブレークイベントを検出する手段と、前記システムに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントの前記システムへの発行を協調する手段とを有する、システム。前記第1と第2のブレークイベントの発行の協調は、前記ランタイム情報に少なくとも部分的に基づく保持時間の決定と、前記保持時間に少なくとも部分的に基づく前記第1と第2のブレークイベントのうち少なくとも一方の延期とを含む、請求項15に記載のシステム。前記入出力モジュールは、前記第1と第2のイベントソースのうち少なくとも一方から前記ランタイム情報を取得する手段をさらに含む、請求項15に記載のシステム。前記第1と第2のイベントソースのうち少なくとも一方は前記システムに結合した装置を含み、前記第1と第2のブレークイベントのうち少なくとも一方は入出力イベントを含むものであり、前記ランタイム情報は前記入出力イベントの遅延時間を特定するものである、請求項17に記載のシステム。前記第1と第2のイベントソースのうち少なくとも一方はアクティブアプリケーションを実行する前記システムのコンポーネントを含み、前記第1と第2のブレークイベントのうち少なくとも一方はタイマーイベントを含むものであり、前記ランタイム情報は前記タイマーイベントの遅延可能特性を特定するものである、請求項17に記載のシステム。前記入出力モジュールは、前記システムから前記ランタイム情報を取得する手段をさらに含み、前記ランタイム情報は、低電力状態ブレークイーブン時間とプログラム可能性能要件のうち少なくとも一方を特定するものである、請求項15に記載のシステム。一実施形態による、一又は複数のブレークイベントを発行する方法は、第1のイベントソースからの第1のブレークイベントを検出するステップと、第2のイベントソースからの第2のブレークイベントを検出するステップと、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントのプラットフォームへの発行を協調するステップとを有する。他の一実施形態による一又は複数のブレークイベントを発行する装置は、入出力モジュールを有し、前記入出力モジュールは、第1のイベントソースからの第1のブレークイベントを検出する手段と、第2のイベントソースからの第2のブレークイベントを検出する手段と、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントのプラットフォームへの発行を協調する手段とを有する。さらに他の一実施形態による一又は複数のブレークイベントを発行するシステムは、第1のイベントソースと、第2のイベントソースと、プロセッサと、前記プロセッサに結合した入出力モジュールとを有し、前記入出力モジュールは、前記第1のイベントソースからの第1のブレークイベントを検出する手段と、前記第2のイベントソースからの第2のブレークイベントを検出する手段と、前記システムに関連するランタイム情報に少なくとも部分的に基づき、前記第1と第2のブレークイベントの前記システムへの発行を協調する手段とを有する。実施形態は、第1のイベントソースからの第1のブレークイベントを検知し、第2のイベントソースからの第2のブレークイベントを検知する方法を提供する。また、本方法は、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第1と第2のブレークイベントのプラットフォームへの発行を協調するステップを提供する。他の実施形態は、プロセッサにより実行されると、コンピュータに、第1のイベントソースからの第1のブレークイベントを検知させ、第2のイベントソースからの第2のブレークイベントを検知させる一組の命令を有するコンピュータ読み取り可能記憶媒体を含む。また、本命令は、コンピュータに、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第1と第2のブレークイベントのプラットフォームへの発行を協調させるステップを提供する。また、実施形態は、第1のイベントソースからの第1のブレークイベントを検知し、第2のイベントソースからの第2のブレークイベントを検知する論理を有する入出力IOモジュールを有する装置を含む。また、この論理は、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第1と第2のブレークイベントのプラットフォームへの発行を協調する。また、実施形態は、第1のイベントソースと、第2のイベントソースと、プロセッサと、そのプロセッサに結合した入出力IOモジュールとを有するシステムを含む。このIOモジュールは、第1のイベントソースからの第1のブレークイベントを検知し、第2のイベントソースからの第2のブレークイベントを検知する論理を有する。また、この論理は、システムに関連するランタイム情報に少なくとも部分的に基づいて、第1と第2のブレークイベントのシステムへの発行を協調する。ここで図1を参照し、異なるソース例えば、複数の電力管理エンティティからの複数のブレークイベント1010a-10fを、そのブレークイベント10のプラットフォームへの発行の協調の前後で示す。図示した一例では、マウスなどの装置からの入出力IOイベント10a例えば、割り込みが時刻t1に要求され、プラットフォーム上で実行されているアクティブなアプリケーションからのタイマーイベント10bが時刻t2に要求される。また、ネットワークインタフェースカードNICなどのその他の装置からの一連のIOイベント10cが時刻t3で要求される。後でより詳しく説明するが、IOイベント10cは、それ自体が、NIC上に又は集中して配置された合体部coalescingunitによりグループ化される。また、オーディオ装置からのIOイベント10dが時刻t4に要求される。また、図示した例には、時刻t5とt6それぞれにおけるアクティブアプリケーションからのタイマーイベント10eと10fを示した。ネイティブ状態では、ブレークイベント10は、プラットフォームが、長時間省電力状態に入ることを妨げる時間プロファイルを有する。したがって、ブレークイベント10のプラットフォームへの発行を協調して、プラットフォームに電力消費を低減させることができる。例えば、図示したマウスからのIOイベント10aは、アプリケーションタイマーイベント10b後の時刻t2dで発行されるの発行と合うように、時刻t1dまで遅れさせられる。他の一例として、タイマーイベント10bは遅延できないイベントであるとする。かかる場合、IOイベント10aは遅延され、一方タイマーイベント10bはスケジュール通りに発行される。いずれの場合でも、アイドル時間12は長くなり、プラットフォームはより早く、より長い時間、より深い省電力状態例えば、ACPIAdvancedConfigurationandPowerInterfaceSpecificationACPISpecificationRev40June162009省電力状態に入ることができる。また、NICからのIOイベント10cは、オーディオ装置からのIOイベント10dと、それぞれ後の時刻t3dとt4dにおいて合わせalign、時間14を長くすることができる。同様に、アプリケーションタイマーイベント10eと10fは、それぞれ時刻t5dとt6dまで遅延させ、時間16を長くすることができる。簡単に言うと、時間12、14、16が長くなったので、プラットフォームの省電力が向上し、バッテリーの寿命が延びる。図2は、複数のブレークイベント20を検知して、プラットフォーム/オペレーティングシステムOS26に関連するランタイム情報24に少なくとも部分的に基づき、それらを時間的に合わせてalign協調ブレークイベント22とするブレークイベント管理部BMU18を示す。BMU18は、プラットフォーム26のモジュールに実装されてもよく、例えばモバイルインターネットデバイスMIDプラットフォームのシステム制御部SCU又はラップトッププラットフォームのプラットフォームコントローラハブPCHに実装されてもよい。実際、BMU18は、インターフェースと実装手法が若干異なるオペレーティングシステムOSのカーネル空間中にあっても、ユーザ空間にあってもよい。図示した例では、ランタイム情報24は、ブレークイベント20のソース28から、及びプラットフォーム26自体から取得できる。例えば、プラットフォームに結合した装置から取得したランタイム情報24は、一又は複数のIOイベントの最大遅延時間を指定するQoSサービス品質仕様を含む。また、アプリケーションから取得したランタイム情報24は、一又は複数のタイマーイベントの遅延可能特性deferabilitycharacteristicを示すものであってもよい。例えば、タイマーイベントが遅延可能でなければ、BMU18は、他のブレークイベントを、その遅延可能でないタイマーイベントと時間合わせalignするように試みる。タイマーイベントが遅延可能であれば、BMU18はタイマーイベントを管理して、プラットフォームの省電力と性能を最適化できる。例として、アプリケーションが、タイマーイベントを50msごとに、100msの最大頻度まで遅延可能である場合、BMU18は、プラットフォーム26が比較的にアクティブでない間、100msごとにタイマーイベントをトリガーする。しかし、他のソースにより発生されるブレークイベントによりプラットフォーム26がもっとアクティブになると、BMU18は、電力消費に悪い影響を与えずに、タイマーイベントの発行を50msに合わせて、アプリケーション性能を良くすることができる。また、プラットフォーム26は、ランタイム情報24を低電力状態ブレークイーブン時間やプログラマブル性能要件等の形式で提供できる。低電力状態ブレークイーブン時間は、低電力状態に入ったり出たりするのに伴う電力コストオーバーヘッドをオフセット/償却するために、プラットフォーム26が、ある低電力状態にいるべき時間を示す。後でより詳しく説明するが、BMU18は、低電力状態ブレークイーブン時間を用いて、遅延された各ブレークイベントの保持時間を決定できる。これに関して、保持時間がブレークイーブン時間よりずっと長くなると、省電力の利益が急速に低下し、性能が大幅に悪くなる。よって、BMU18は、ブレークイーブン時間と所望の性能とに基づき、合理的な保持時間を決定できる。プログラマブル性能要件はプラットフォーム26のユーザにより決定できる。よって、ユーザは性能を高くしたければ、応答を速くして性能を改善するために、省電力の機会を失う可能性はあるが保持時間を短くする。他方、ユーザがバッテリー寿命を長くすることを要求するとき、プラットフォーム26に低電力状態に留まる機会をより多く与えるために、保持時間を比較的長い値に設定できる。ここで図3を参照して、ブレークイベントの発行の協調方法30の一例を示す。方法30は、例えば、特定目的集積回路ASIC、相補的金属酸化物半導体CMOS、又はトランジスタトランジスタロジックTTLなどの回路技術を用いた固定機能ハードウェアで、又はランダムアクセスメモリRAM、リードオンリメモリROM、プログラマブルROMPROM、フラッシュメモリなどメモリの機械又はコンピュータ読み取り可能媒体に記憶された一組のファームウェア及び/又はロジック命令として実行可能ソフトウェアで、又はこれらの任意の組み合わせで実装可能である。処理ブロック32において、装置、アプリケーション、及びプラットフォームからランタイム情報を収集し、ランタイム情報に基づいて保持時間を決定する。既述の通り、保持時間の決定では、低電力状態ブレークイーブン時間とプログラマブル性能要件、及びIOイベントの最大遅延時間とタイマーイベントの遅延可能特性を考慮し得る。ブロック34においてブレークイベントを検知すると、ブロック36において、保持時間が経過したか判断する。経過していなければ、ブロック38においてブレークイベントを延期する。ブレークイベントの延期は、状況に応じていろいろな方法で実現できる。例えば、ブレークイベントはキューに入れられる。このキューは装置に関連する合体部coalescingunit中のBMU18図2と、すなわちブレークイベントを発行する装置と一緒に用いられる。実際、ブレークイベントがバスマスタリングトランザクション例えば、ダイレクトメモリアクセスDMAと関連する場合、そのブレークイベントは、PCIePeripheralComponentsInterconnectExpressOBFFopportunisticbufferflushfill信号をデアサートして、ソース装置に対して、PCIeバスが利用不可であることを通知することにより延期される。ブロック40において延期できないブレークイベントが検出されるか、ブロック36において保持時間が経過したと判断されると、ブロック42において、延期されたすべてのブレークイベントがプラットフォームにリリースすなわち発行される。図示したブロック44において、収集したランタイム情報に基づき、次の保持時間をスケジューリングする。既述の通り、保持時間は動的に調整できる。ブロック46において、プラットフォーム電力管理部に次の保持時間が通知される。図4は、システム48を示す。このシステム48では、BMU50が、アプリケーションタイマー54と装置5656a-56cから様々なブレークイベントを受信するプロセッサ/プラットフォーム52に結合している。プロセッサ/プラットフォーム52は、ブレークイベントにより、一又は複数の低電力状態を出る又は、入るのを妨げられる。図示した例では、合体部coalescingunits58は、例えば、そうしなければ複数のブレークイベントになってしまう複数のパケットを結合して、1つのブレークイベントにすることにより、ブレークイベントの数を減らす。それゆえ、他の装置やアプリケーションも合体プロセスcoalescingprocessによる利益はあるが、合体部58はネットワークコントローラなどの通信装置にとって特に有用である。合体部58は、ブート時における初期化フェーズから、オーバーライドポリシー、装置バッファサイズ、装置レイテンシ許容要件などのシステムパラメータを取得でき、あるいはすでに知っている。これらのパラメータは、合体部58により用いられ、初期装置アプリケーションベースの保持時間を決定できる。この保持時間は、必要に応じて、ランタイムビヘイビアruntimebehaviorに基づき後で調節できる。ランタイムにおいて、合体部58は、ブレークイベント機能を有する各装置をトラッキングして、その装置が所定時間の間、静穏であったか例えば、αmsの間、割り込みを発生していないか判断する。静穏であった場合、問題の合体部58は、例えば、βmsの保持期間に入る。保持期間では、このソースからの割り込みは、BMU50及び/又はプロセッサ/プラットフォーム52には中継されない。このアプローチは、装置/アプリケーションごとに、及び各装置/アプリケーションごとに異なるパラメータで、実施される。また、高性能/ベンチマーキングモードなどのストラテジを用いて、合体部58をバイパスすることもできる。合体部58は、装置56及びアプリケーションタイマー54に実装できるが、BMU50に配置すると、装置メーカはブレークイベントのアライメントalignmentをサポートする必要が無くなり、よりスケーラブルになる。合体部58をBMU50に実装するには、バッファがあふれることを防止するため、保持タイマーβの上限を、装置の内部バッファサイズに適合したものにする必要がある。また、余裕があるのに時間切れになったり、最高システム性能が下がることを防止するため、静穏タイマーαは十分大きな値に設定できる。合体タイマーを適合するため、異なる多くのストラテジを用いることができる。例えば、静的ポリシーでは、合体ビヘイビアをユーザ設定又はOSプロファイルベースのシステム性能にリンクさせる。よって、ユーザが高い性能プロファイルを好めば、β=0にして、合体をバイパスする。性能/パワープロファイルをバランスさせるため、ティピカル値としてβ=5msを選択できる。低電力モードの場合、省電力を最大化して、ティピカル値としてβ=10msを選択できる。あるいは、あるカウント期間にわたり観測した平均ブレークイベントカウントに基づき、βを閉ループで制御する動的ポリシーを用いても良い。それゆえ、このアプローチは、合体をできるだけ押しつけがましくなくし、ブレークイベントのビヘイビアが平均すれば大きく変わらないようにする。一般的には小さいβ値から初めて、個々の装置からのブレークイベントの数を、比較的長い数秒のオーダー期間にわたり観測し、イベントの平均数が大きく変わるまでβを大きくする。変化に応じて、βをリセットして一から適合させるか、又は繰り返し減らす。ここで図5を参照して、システム60を示す。システム60は、例えば、パーソナルデジタルアシスタントPDAやラップトップなどの計算機能を有する、例えば、無線スマートフォンなどの通信機能を有する、画像取得機能を有する、メディア再生機能を有する、又は例えば、モバイルインターネットデバイスMIDなどの上記機能の任意の組合せを有するモバイルプラットフォームの一部である。図示した例では、システム60は、プロセッサ62、統合メモリコントローラIMC74、IOモジュール64、システムメモリ66、ネットワークコントローラ例えば、ネットワークインタフェースカード68、オーディオIOデバイス72、ソリッドステートディスクSSD70、その他の一又は複数のコントローラ80を含む。プロセッサ62は、一又は複数のプロセッサコア76を有するコア領域を含み、電力管理ユニットPMU78を用いて、既述の通り、コア76その他のシステムコンポーネントを、性能及び/又は電力管理の観点に基づき、一又は複数のアクティブ及び/又はアイドル状態にする。図示したIOモジュール64は、チップセットのうちサウスブリッジやサウスコンプレックスと呼ばれることもあるが、ホストデバイスとして機能し、ネットワークコントローラ68と通信する。ネットワークコントローラ68は、幅広い目的のため、オフプラットフォームの通信機能を提供する。この目的には、携帯電話例えば、W-CDMAUMTS、CDMA2000IS-856/IS-2000など、WiFi例えば、IEEE802.11、1999版、LAN/MAN無線LAN、ブルートゥース例えば、IEEE802.15.1-2005、無線パーソナルエリアネットワーク、WiMax例えば、IEEE802.16-2004、LAN/MANブロードバンド無線LAN、グローバルポジショニングシステムGPS、スプレッドスペクトラム例えば、900MHz、及びその他のラジオ周波数RFテレフォニー目的を含む。また、IOモジュール64は、かかる機能をサポートする一又は複数の無線ハードウェア回路ブロックも含む。SSD70は、一又は複数のNANDチップを含み、大容量データ記憶及び/又は大量の並列処理を提供する。シリアルATAバスSATA、例えば、SATARev30SpecificationMay272009SATAInternationalOrganizationSATAIO又はPCIエクスプレスグラフィックスバスPEG、例えば、PeripheralComponentsInterconnectPCIExpress×16Graphics150WATXSpecification10PCISpecialInterestGroupなどの標準的バスでIOモジュール64に接続された、別の特定目的集積回路ASICコントローラとして実装されたNANDコントローラを含むソリューションもある。また、USBユニバーサルシリアルバス、例えば、USBSpecification20USBImplementersForumフラッシュ記憶デバイスとしてSSD70を用いることもできる。図示したIOモジュール64はBMU82を含む。BMU82は、ネットワークコントローラ68、オーディオIOデバイス72、SSD70、プロセッサ62で実行中のアクティブアプリケーションなどの複数の異なるソースからのブレークイベントを検出し、システム60に関連するランタイム情報に基づいてプロセッサ62へのブレークイベントの発行を調整するように構成されている。一例では、ブレークイベントの発行の調整は、ランタイム情報に基づく保持時間の決定と、その保持時間に基づくブレークイベントの少なくとも一の延期とを含む。例えば、システム60は、VoIPvoiceoverInternetProtocolアプリケーションを実行でき、そのアプリケーションでは、ネットワークコントローラ68とオーディオIOデバイス72が、他のデバイスにより発生されたIOイベントにかかわらず、アクティブにIOイベントを発生する。BMU82を用いてネットワークコントローラ68とオーディオIOデバイス72からのブレークイベントを調整することにより、図示したIOモジュール64は、システム60のコンポーネントを、より長い時間、より深い低電力状態に入らせ、システム60により実現される省電力を大幅に改善する。よって、上記の手法により、複数のIO装置とアプリケーションのアクティビティを調整してアライメントするように計算システムアーキテクチャとインターフェースを画定する全体的アプローチが提供される。結果として、プラットフォームの省電力を最適化するためプラットフォームを最大限アイドル状態にできる。また、かかる調整とアライメントにより、プラットフォームが、理想的な負荷に比例した消費電力により近づくことができ、性能がロバストとなる。本発明の実施形態は、すべてのタイプの半導体集積回路ICチップで利用できる。これらのICチップの例としては、プロセッサ、コントローラ、チップセットコンポーネント、プログラマブルロジックアレイPLA、メモリチップ、ネットワークチップ、システムオンチップSoC、SSD/NANDコントローラASICなどがあるが、これらに限定されない。また、いくつかの図面では、線で信号導線を表した。いくつかの線は太く、より多くの構成信号経路を示し、複数のラベルを有し、複数の構成信号経路を示し、及び/又は1つ以上の端に矢印を有し、主な情報フロー方向を示す。しかし、これは、限定と解釈してはならない。むしろ、かかる付加的詳細は、1つ以上の実施形態と共に、回路の理解を促進するために用いられている。表示したどの信号線も、追加的情報を有していようがいまいが、複数の方向に進む1つ以上の信号を有していてもよく、例えば、差動ペアと実装されたデジタル又はアナログライン、光ファイバライン、及び/又は単一終端ラインなどの所望のタイプの信号方式で実装してもよい。例示したサイズ/モデル/値/範囲は所与のものであってもよいが、本発明の実施形態はこれに限定されない。フォトリソグラフィなどの生産技術が時間とともに成熟してくるので、小さいサイズのデバイスを生産できると期待される。また、ICチップその他のコンポーネントへの周知のパワー/グラウンド接続は、図示と説明とを簡単にするため、及び本発明の実施形態の態様を分かりにくくしないように、図示したものもあれば図示していないものもある。さらに、構成をブロック図の形式で示したが、それは本発明の実施形態を分かりにくくしないようにするため、またかかるブロック図構成の実装に関する具体的事項は実施形態を実装するプラットフォームに大きく依存すること、すなわちかかる具体的事項は当業者の管轄事項であることを考慮したものである。本発明の実施形態を説明するために、例えば、回路などの具体的な詳細事項を記載した場合、当業者には言うまでもなく、こうした具体的な詳細事項が無くても、又はそれを変更しても、本発明の実施形態を実施できる。よって、上記の説明は、限定ではなく例示と考えるべきである。結合したとの用語は、ここでは問題となるコンポーネント間の、直接的又は間接的な任意のタイプの関係を言い、電気的結合、機械的結合、流体的結合、光学的結合、光磁気的結合、電気機械的結合その他の結合に当てはまる。また、第1の、第2の等の用語は、ここでは、説明を容易にするためにだけに使われており、特に断らなければ時間的な意味は無い。当業者には言うまでもなく、本発明の実施形態の幅広い手法は、いろいろな形式で実施できる。それゆえ、本発明の実施形態をその具体的な例に関連して説明したが、当業者には図面、明細書、及び特許請求の範囲を研究すればその他の修正が明らかであるから、本発明の実施形態の範囲は具体例に限定されない。