"1つの完全な汎用シリアルバスUSBプロトコルスタックコードにより通常オペレーション中に動作可能な汎用シリアルバスUSBインタフェースを有する電子機器であって、該電子機器をブートするブートコードを含む不揮発性メモリを備えた電子機器において、前記電子機器のソフトウェアは、前記汎用シリアルバスUSBインタフェースを介して前記電子機器のブートオペレーション中にアップグレード可能であり、前記ブートコードは、前記汎用シリアルバスUSBインタフェースの軽量プロトコルスタックコードを有しており、該軽量プロトコルスタックコードは、前記完全な汎用シリアルバスUSBプロトコルスタックコードのサブセットから成り、ブートオペレーション中の前記汎用シリアルバスUSBインタフェースを介した送受信と前記ソフトウェアのアップグレードのためのコードであることを特徴とする電子機器。前記不揮発性メモリは、前記完全な汎用シリアルバスUSBプロトコルスタックコードを含むように適合されていないことを特徴とする請求項1に記載の電子機器。汎用シリアルバスUSBインタフェースを備えた電子機器のメモリ部分にファイルをダウンロードする方法であって、前記電子機器は、少なくとも前記汎用シリアルバスUSBを介して1つまたは複数のコンピュータと接続されており、前記電子機器は、該電子機器をブートするブートコードを含む不揮発性メモリを備え、前記ブートコードは、完全な汎用シリアルバスUSBプロトコルスタックコードのうちの軽量プロトコルスタックコードを備え、前記軽量プロトコルスタックコードは、ブートオペレーション中の前記汎用シリアルバスUSBインタフェースを介した送受信と前記電子機器のソフトウェアのアップグレードのためのコードが含まれ、前記方法は、前記軽量プロトコルスタックコードを用いて、前記汎用シリアルバスUSBインタフェースを介して、前記1つまたは複数のコンピュータに少なくとも1つのブートリクエストを送信するステップと、前記1つまたは複数のコンピュータから少なくとも1つのブートリプライを受信するステップと、前記1つまたは複数のコンピュータのうち1つのコンピュータにファイル転送リクエストを送信するステップと、前記1つのコンピュータから前記格納されたファイルを受信するステップとを備えたことを特徴とする方法。本発明の課題は、ブートオペレーション中にいっそう幅広いアップグレードを行わせる装置およびシステムならびに方法を提供することにある。本発明によればこの課題は、電子機器のソフトウェアはそのブートオペレーション中にアップグレード可能であり、ブートコードは汎用シリアルバスUSBインタフェースのための軽量プロトコルスタックコードを有しており、該軽量プロトコルスタックは完全なUSBプロトコルスタックコードのサブセットから成ることを特徴とする電子機器により解決される。さらに上述の別の課題は、少なくとも1つのコンピュータにUSBインタフェースが設けられていて、1つまたは複数のコンピュータにファイルを格納するステップと、少なくとも汎用シリアルバスUSBを介して前記電子機器を1つまたは複数のコンピュータに接続するステップと、完全なUSBプロトコルスタックに比べて低減された軽量プロトコルスタックを利用して、少なくとも1つのブートリクエストを前記電子機器から前記1つまたは複数のコンピュータへ前記USBインタフェースを介して送信するステップと、前記1つまたは複数のコンピュータから前記電子機器へ少なくとも1つのブートリプライを送信するステップと、前記電子機器から前記1つまたは複数のコンピュータのうち1つのコンピュータにファイル転送リクエストを送信するステップと、前記格納されたファイルを前記1つのコンピュータから前記電子機器へ送信するステップを有することを特徴とする、USBインタフェースを備えた電子機器のメモリ部分にファイルをダウンロードする方法により解決される。電子機器の通常オペレーション中、インタフェースのすべてのオペレーションをコントロールするために、およびこのインタフェースに関連するすべてのプロトコルを処理するために、典型的にはオペレーションソフトウェア中に完全なプロトコルスタックコードが設けられている。典型的なインタフェースはたとえばUSB、USB2またはFirewireなどである。いっそう幅広いアップグレードオプションを提供する目的で本発明による電子機器は、この機器のソフトウェアがこの種のインタフェースを介してブートオペレーション中にもアップグレードが可能であるように構成されている。完全なプロトコルスタックコードは通例、大量のメモリを占有するものであり、フラッシュメモリ内のブートコードには適していない。電子機器のコストの点ではフラッシュメモリのサイズを制限するのが望ましい。したがって本発明の別の目的として挙げられるのは、不揮発性メモリ内の対応するブートコードサイズを小さく維持することである。この目的は、ブートオペレーション中にインタフェースを処理するための軽量プロトコルスタックコードだけをもつブートコードを使用することによって達成される。本発明の別の実施形態によれば、ブートコードは前記のインタフェースを検出するためのコントロールコードと、このインタフェースを介して送受信を行うためのプロトコル処理コードとを有している。この種のブートコードによってこのインタフェースを介してデータを送信できるようになり、このデータを電子機器のソフトウェアアップグレードのために機器のメモリに書き込むことができる。本発明の有利な実施形態によればインタフェースはUSBインタフェースである。完全なUSBプロトコルスタックというのはかなり大きいプロトコルスタックであり、これは典型的にはオペレーションソフトウェア中に設けられているのに対し、ブートコードは軽量プロトコルスタックだけを使用することから小さく維持されており、つまりメモリサイズが低減される。さらに本発明の別の目的は、通常オペレーション中に完全なプロトコルスタックコードによって動作可能なUSBインタフェースを備えたモデムなどのような電子機器において、そのブートオペレーション中にUSBインタフェースを介してこのような電子機器のソフトウェアをアップグレード可能にすることである。このため本発明の別の観点によれば前述のブートコードには、前記の完全なプロトコルスタックコードのイーサネットからUSBへのマッピングパートが含まれている。このパートは、ワイドエリアネットワークWANを介した通信に必要とされるAAL5/ATM/USBATMasynchronoustransfermodeAALATMadaptionlayerマッピングをサポートしていない。換言すれば、いくつかのレイヤが取り除かれている。しかしながらこのパートによって、少なくともUSBポートにおいて電子機器と接続されたコンピュータなどの適切な機器へBOOTPリクエストを首尾よく伝送可能にするために必要とされるカプセル化が保証される。さらに詳しくは、BOOTP、ユーザデータグラムプロトコルUDPならびにインターネットプロトコルIPがブートオペレーション中に利用され、これによってBOOTP/UDP/IPをイーサネットにカプセル化することができる。しかもUSBを介したこのイーサネットプロトコルスタックは完全なスタックと比べて軽量なプロトコルスタックであり、その結果としてブートコードがいっそう小さくなる。したがって本発明の別の観点によれば、ワイドエリアネットワークWANを介した通信のための完全なUSBプロトコルスタックコードが第2のメモリに含まれている。このコードは、通常オペレーション中にワイドエリアネットワークWANを介した通信に必要とされるAAL5/ATM/USBマッピングをサポートする。有利な実施形態によればモデムはさらにイーサネットインタフェースを有しており、この場合、ブートコードはブートオペレーション中にイーサネットを介して送受信するためのコードを有している。これによって、USBインタフェースを介したまたはイーサネットインタフェースを介したモデムのソフトウェアアップグレードが考慮される。本発明はさらに、前述の実施形態のいずれかに従って電子機器にファイルをダウンロードするためのシステムに関する。このシステムには、前述の電子機器と前述のインタフェース用のドライバを備えたコンピュータとが設けられていて、このコンピュータは前述のインタフェースを介して電子機器と接続されており、リモートのコンピュータには、電子機器と通信するためのおよびダウンロードすべきファイルを供給するための実行可能なプログラムコードが含まれている。USBインタフェースの場合、USBドライバはコンピュータ内部のUSBハードウェアをコントロールし、コンピュータ上のソフトウェアはプログラムインタフェースセットを介してこのドライバと通信することができる。実行可能なプログラムは一般にそれ自体PCにおいてアップグレードウィザードプログラムを成しており、これは一連のダイアログボックスを用いた手順を通してステップを追ってユーザをガイドするプログラムである。電子機器がUSBインタフェースとイーサネットインタフェースを有しているならば、アップグレードウィザードプログラムはUSBポートあるいはイーサネットポートの双方を介してアップグレード可能である。USBホスト通常はコンピュータとUSBデバイスとの間の基本通信要素はパイプとエンドポイントEPである。エンドポイントは、USBホストとUSBデバイス内部のいくつかの機能との間の論理的な伝送経路である。エンドポイントは通常、単方向のみでデータを送信するために存在しており、それらはパイプなどのようにいっそう先進的な通信経路のために使用される。本発明によるシステムの1つの特有の実施形態によれば、送信すべきフレームをUSBデバイスへおよびそこから送信できるようにするため、USBインタフェースのエンドポイントEP4および5においてそれぞれコネクションが確立される。エンドポイントは所定のプロトコルの使用と結びつけられており、EP4,EP5の選択はブートオペレーション中に使用される軽量プロトコルに関連づけられる。このコネクションを可能にするためブートコードは、コントロールに使用されるEP0と、バルクモードにおけるソフトウェアダウンロードインタフェースとして使用されるEP4と、バルクモードにおける確認応答インタフェースとして用いられるEP5をサポートしている。他のエンドポイントはブートオペレーション中は使用不能状態におかれ、EP4とEP5以外のエンドポイントにおけるすべてのトラフィックは除かれる。本発明はさらに、USBコネクションを備えた電子機器のメモリ部分にファイルをダウンロードするための方法に関し、この方法は以下のステップから成る。すなわち、-1つまたは複数のコンピュータにファイルを格納するステップ、ここで少なくとも1つのコンピュータにはUSBインタフェースが設けられている;-前記電子機器を少なくとも汎用シリアルバスUSBを介して1つまたは複数のコンピュータに接続するステップ;-完全なUSBプロトコルスタックと比べて低減されたUSBプロトコルスタックを使用し、USBインタフェースを介して前記電子機器から1つまたは複数のコンピュータに少なくとも1つのリクエストを送信するステップ;-前記1つまたは複数のコンピュータから前記電子機器へ少なくとも1つのブートリプライを送信するステップ;-前記電子機器から前記1つまたは複数のコンピュータのうちの1つにファイル転送リクエストを送信するステップ;-格納されたファイルを前記1つのコンピュータから前記電子機器へ送信するステップ。この方法の有利な実施形態によれば、上述のブートリクエストとブートリプライはBOOTPプロトコルを使用する。また、上述のファイル転送リクエストおよび格納されたファイルの送信を、簡易ファイル転送プロトコルTFTPを使用して行うと有利である。ファイルが電子機器のメモリパートに格納されたならば、ダウンロードされたファイルの形式に応じてそのファイルからブートするのが有利である。この方法における1つの特有の実施形態によれば、電子機器は少なくとも1つのコンピュータとイーサネットを介しても接続されている。この場合、ブートリクエストはUSBインタフェースとイーサネットインタフェースの双方に送信される。最初の可能性によれば、最初にブートリプライを受け取ったインタフェースを介してファイル転送が確立される。他の可能性によれば、USBインタフェースを介して接続されたコンピュータから受け取ったブートリプライとイーサネットインタフェースを介して接続されたコンピュータから受け取ったブートリプライの双方が、電子機器によって監視されることになる。たとえば転送すべきファイルの重要性あるいはバージョンなどに依存して、電子機器は複数のコンピュータのうちのいずれかに優先権を与えることができる。本発明のさらに別の特徴や利点は、図面を参照しながら以下で説明する本発明の有利な実施形態の説明に示されている。図1には、本発明によるモデム1の主要ハードウェアコンポーネントの概観が描かれている。このハードウェアアーキテクチャによって、電話回線と1つまたは複数のコンピュータとの間のリンクが形成される。電話回線インタフェース3は典型的にはDSLターミネーションインタフェースであって、ここではRJ-11コネクタが使用される。ADSLモデム1はさらに第1のブロック2を有しており、これにはアナログフロントエンドと、アナログ回線インタフェースのターミネーションおよびディジタルデータをメインコントローラ4からアナログバンドパス信号に変換するための特定用途向け集積回路ASICが含まれていて、このASICのことをADSLASICと称する。アナログフロントエンドモジュールは、既存電話サービス網POTS信号をフィルタリング除去しADSL信号の通過を許可するハイパスフィルタと、アップストリーム信号とダウンストリーム信号とを分離するため2線から4線へまたはその逆への変換を実行するハイブリッド回路たとえば受動回路網と、アップストリームラインドライバとダウンストリームレシーバフィルタとによって構成されている。ADSLASICによって、アナログ/ディジタル変換A/Dおよびディジタル/アナログ変換D/Aが行われる。メインコントローラ4は基本的にディジタルADSLモデムASIC、イーサネットATMアダプタおよびマイクロプロセッサを有している。ディジタルADSLモデムASICにはDMTdigitalmultitone変調の手法を用いる信号変復調器が含まれており、これによってイーサネットまたはUSBインタフェースから到来する信号が変調されてそれらがADSL,ASICに供給され、さらにその逆のことが行われる。コントローラには、シンクロナスダイナミックランダムアクセスメモリ5SDRAMとフラッシュメモリすなわち電気的にプログラミング可能なリードオンリメモリEPROM6から成るメモリプールが付属しており、このリードオンリメモリ6はブロック単位で消去および再プログラミング可能な不揮発性メモリである。フラッシュEPROMのサイズは典型的には2MBであって8MBまで拡張可能である。典型的には8MBのサイズであるSDRAMは、たとえば32bit幅のバスを介してメインコントローラ4と通信を行う。イーサネットインタフェース7は専用インタフェースを介してコントローラと接続されている。イーサネットインタフェース7は典型的には、RJ-45コネクタを備えた10/100BaseTインタフェースである。専用のUSB集積回路を含むUSBインタフェース11は、たとえば16bit幅のデータバスと1bit幅のアドレスバスから成るパラレルインタフェースを介して、メインコントローラ4と接続されている。この機器にはさらに、内部電源8と接続された標準電源プラグ9が設けられている。内部電源8の出力側から複数の電圧が供給され、たとえば12Vと3.3Vと1.8Vが供給される。これらの給電電圧によって、ハードウェアコンポーネントのために必要とされる電源が供給される。さらにこの機器には通常、LED発光ダイオードなどのような複数の視覚的インジケータが設けられており、これによって機器の種々のハードウェアの振る舞いが表示される。モデムの通常オペレーション中、機器は以下のように動作する。電話回線からADSL信号が受信され、AAL5でカプセル化された所定のバーチャルチャネルとバーチャルパスの組み合わせをもつ標準ATMセルに変換される。これらの組み合わせによって、到来トラフィックがオペレーションおよびメンテナンストラフィックから成りオンボードプロセッサによりルーティングされ処理されるのか、あるいはそのままUSBまたはイーサネットへ送られるべきブリッジされたイーサネットフレームから成るのか、あるいはUSBまたはイーサネットへ転送されるルーティングされたIPパケットから成るのかが決定される。図2には、モデムシステムをブートするためのプロセスを示すフローチャートが描かれている。ボードがパワーオンされると、コントローラは内部ROMからの実行コードをスタートさせ、それに応じてフラッシュメモリにおけるブートコードの開始アドレスにジャンプし、このアドレスはボードサポートパッケージBSPのエントリポイントである。そこでBSPが実行開始される。まだ実行されていないBSPのパートはブートコードとともにSDRAMにコピーされ、これにはグローバル変数および初期化されたデータが続く。プログラムカウンタはSDRAM内のコードにセットされ、コントローラは実行を開始する。BSPがその初期化を完了すると、プログラムはブートコードのエントリポイントにジャンプする。ついでBOOTPリクエストメッセージが送信され、BOOTPレスポンスタイマが実行を開始する。このメッセージの内容および使用されるプロトコルスタックについては、図3および図4を参照しながら詳しく説明する。その後、この機器はリプライ待ち状態となる。タイムアウトした場合または無効なリプライである場合、矢印16で示されているように新たなリクエストが送信される。この再送信の回数はたとえば、タイムアウトまたは無効なリプライの場合の再試行回数を指定するリクエストパラメータに依存させることができる。有効なリプライメッセージが受信された場合にはIPアドレスがセットされ、チェックブロック17で示されているようにこのリプライメッセージの内容がチェックされる。リプライメッセージにファイル名が含まれている場合にはプロセスにおける以下のステップは、簡易ファイル転送プロトコルTrivialFileTransterProtocolTFTPを利用したファイルのダウンロードである。つまりデータパケットがホストコンピュータからSDRAMに伝送され、これについては以下で詳しく説明する。ダウンロードごとに、転送されたファイルのヘッダがチェックされる。ファイルはたとえば以下のフォーマットをもつ。表1のすべての行は4byteである。ファイルヘッダの最初の4byteはファイルフォーマット識別子を表し、これにはたとえばBLI1つまりBootLoaderImageVersion1が含まれている。ファイルの宛先を後続の4byteにおくことができ、これにはSDRAMまたはフラッシュメモリ内の宛先開始アドレスが含まれている。オプションとしてタグコードが設けられており、これにはあらゆるタイプの情報が含まれていて、これによりたとえばファイルからブートするために用いられるアドレス、ファイルデータのトータルサイズ等が指定される。さらに図2を参照すると参照符号22で示されているようにデータは宛先に従い、SDRAM内に残されるかまたはフラッシュメモリに格納される。後者の場合、フラッシュ照合パターンを含む宛先領域が消去され、データが書き込まれる。ついで書き込まれたデータがチェックされ、これはたとえば送信ファイルのファイルヘッダ中に存在する巡回冗長検査CyclicRedundancyCheckCRCの再計算および比較により行われる表1参照。モデムにより生成されたチェックデータが送信されたチェックデータと同じであれば、フラッシュ照合パターンが書き込まれる。それらが同じでなければ、線24で示されているようにリブートが実行される。問い合わせブロック25で規定されているこのプロセスの次のステップは、BOOTPリプライメッセージ中のフラグに依存する。このオプションは、ブロック26で表されているような所定のファイルエントリポイントでブートするためのものであり、あるいは問い合わせ27においてボードサポートパッケージBoardSupportPackageBSPが存在しているならば、このパッケージから第2のブートを実行するためであり、あるいはそれが存在していないのであればスタートからリブートさせるためのものである。なお、上述の説明はプロセス中の主要なステップを表したにすぎないことは自明であり、さらに明らかなように、たいていのオペレーションは個々のモデム形式に依存して所定の回数反復可能なループを使ったタイムアウト方式を用いている。また、いくつかの付加的なテストを実行させてもよい。図3には、ブートコードで用いられるプロトコルスタックが示されている。これは初期化Init、簡易ファイル転送プロトコルTrivialFileTransferProtocolTFTP、ブートプロトコルBootProtocolBOOTP、ユーザデータプロトコルUserDataProtocolUDP、イーサネットコントロールメッセージプロトコル、IP、アドレス解決プロトコルAddressResolutionProtocolARP、イーサネットEthernet登録商標、ETHUSBイーサネットをUSBにダイレクトにマッピングさせるプロトコルによって構成されている。個別のプロトコルのタスクについてはあとで説明する。図4を参照するとそこには、ブートオペレーション中にファイルがダウンロードされ、いかなるエラーも発生しない場合の、モデムMとコンピュータPCとの間の通信について示す図が示されている。矢印28で表されているように、まずはじめにBOOTPリクエストがモデムからPCへ送信される。このメッセージにはMACMediumAccessControlアドレスのような情報、ベンダ固有の情報などが含まれており、これはイーサネットインタフェースとUSBインタフェースの双方へ送信される。次に図3を参照しながら、このBOOTPリクエストのフォーマットがどのようにして整えられるかについて説明する。INITモジュール30が初期化されると、まずはじめにBOOTPリクエストの最初のフィールドが構築され、それがBOOTPモジュール31に送られ、これによってMACアドレスなどのような情報を含む完全なBOOTPリクエストが合成されることになる。ついでUDP33、IP39、さらにインタフェースによってはイーサネット36またはUSBイーサネット35によって、プロトコルスタックを通過して下がっていくときにそれらのヘッダがBOOTPフレームに加えられる。物理層に到達すると、アクティブなインタフェースに従いUSBおよび/またはイーサネットネットワークを介してブロードキャストされる。MACレイヤ34はイーサネットインタフェースまたはUSBインタフェースへのアクセスをコントロールし、IPアドレスをフレーム伝送に使われる物理アドレスに変換するためにアドレス解決プロトコルaddressresolutionprotocolARP38が用いられる。インターネットコントロールメッセージプロトコルICMPによって、ICMPメッセージ送信時の動作異常たとえば輻輳の問題などを考慮することができる。このようなメッセージを受け取ったとき、IPによってその問題が扱われる。BOOTPリクエストが送信されると、モデムMはBOOTPリプライの待機状態をスタートさせる。有効なBOOTPリプライには要求された情報が含まれていなければ、それはたとえばモデムに割り当てられたIPアドレス、本発明による実施形態によればPCに含まれているTFTPサーバのIPアドレス、ダウンロードすべきファイル名のフルパスなどである。BOOTPリプライは最初はUSBインタフェースから受信され、このUSBインタフェースを介してさらに通信が行われ、これと同じことはイーサネットインタフェースについてもあてはまる。この実施形態によれば、リプライを出すPCがまず最初に優先権を獲得する。冒頭ですでに説明したように、最新のアップグレードファイルが格納されているPCに対して優先権を与えるなど、他のインプリメンテーションが可能である。矢印29および矢印40によって表されているのは、モデムが有効なBOOTPリプライを受け取ると、モデムによりTFTP伝送が初期化され、それによってTFTPリクエストがBOOTPリプライ中で指定されたIPアドレスのところにあるTFTPサーバへ送信されることである。このリクエストには、8192byteのTFTPブロックサイズに対するオプションネゴシエーションも含めることができる。ついでモデムは第1のデータパケットの到来を待つ。データパケットが到来すると、ファイルヘッダが分析されて、ファイルをフラッシュメモリに格納しその際にまず最初にSDRAMにバッファリングすべきか、あるいはSDRAM内の適正なアドレスのところにただちに配置すべきかが決定される。最初のパケットのデータがSDRAM内に首尾よく配置された後、矢印42によって示されているように確認応答パケットacknowledgementpacketACKがコンピュータへ送信される。これらのステップは最後のパケットを受信するまで繰り返される。図5には種々のソフトウェアコンポーネントが概略的に描かれており、これは典型的には2MBのサイズをもつフラッシュメモリに格納されている。ブートコード50は典型的にはフラッシュメモリの最上位の128KBを満たしており、これにはUSBコードのイーサネットプロトコル処理パートETHUSBが含まれている。さらにこの領域は、LEDやタイマのようないくつかのハードウェアコンポーネントをアクセスするためのボードサポートパッケージBoardSupportPackageBSPを使用している。フラッシュメモリにはさらに52のオペレーションソフトウェア、通常のオペレーションを目的としたファイルシステム、およびこのファイルシステムにより使用されるスペースが含まれている。次に図6を参照すると、そこにはモデムMのソフトウェアアップグレード中に使用されるプロトコルを表すブロック図が示されており、ここではUSBインタフェース63またはイーサネットインタフェース62を介してモデムに接続されたPC上でウィザードが実行される。USBインタフェース63がアクティブであり、かつウィザード61が開始されると、USBドライバに対するコネクションが確立される。モデムMがUSBインタフェースを介してウィザードにつながると、ウィザードはモデムMにより送信されたBOOTPリクエストを待ち受けようとする。EP5を介してモデムのUSBインタフェースから到来するBOOTPリクエストは、UDP/IP/ETH/USBフレーム内にカプセル化されている。USBドライバ64はこのフレームを非カプセル化してすなわちカプセルから取り出して、UDP/IP/ETHフレームを形成し、それに応じてこのフレームがさらに非カプセル化されてウィザード61に転送される。その後、ウィザード61はBOOTPリプライをUSBドライバ64に送信し、これはUDP/IP/ETHにカプセル化されることになる。ついでUSBドライバ64は受信パケットをEP4を介してUSBデバイスに転送する。同じようにしてモデムMはTFTPリクエストを送信し、これはウィザード61によって受信され、他方、ウィザード61はTFTPを使用してリクエストされたファイルを送信することによりリプライする。モデムMがイーサネットインタフェースを介してウィザードとつなげられるときも、同様のプロセスが行われる。次に図7を参照すると、ここではモデムMはイーサネットインタフェースを介して第1のPC1に接続されており、USBインタフェース68を介して第2のPC2に接続されている。この場合、ウィザード61は、TFTP転送のために初期化されるインタフェースにソフトウェアをアップロードするだけであり、イーサネットインタフェースとUSBインタフェースの双方にはアップロードしない。ここで説明し図面に示した実施形態は、特にPCベースのオペレーティングシステムに係わるものであるが、本発明はPCベースのオペレーティングシステムに限定されるものではなく、本発明をUNIXシステムやMacintoshシステムによっても利用できるし、あるいはUSBインタフェースを備えた他のいかなるシステムによっても利用できる。これまで1つの特定の実施形態について例示し説明してきたが、本発明は種々の変形実施形態を含むものであり、本発明の範囲は以下の特許請求の範囲に基づき規定されるものである。"