(57)【特許請求の範囲】
【請求項１】
外部通信ネットワークを介して通信するための通信機能と、ストレージに記憶されたコンテンツ情報をレンダリングするレンダリング機能と、モバイル電子装置のユーザ制御のためのユーザインターフェースと、を有するモバイル電子装置であって、
前記通信機能と前記ユーザインターフェースとの制御のためのホストプロセッサと、
前記レンダリング機能の制御のためのコプロセッサと、を備え、
前記ホストプロセッサは、前記ストレージへアクセスし、
前記ホストプロセッサは、アクティブモードとスリープモードとを有し、
前記ホストプロセッサは、前記アクティブモードにおいて高電力消費、前記スリープモードにおいて低電力消費であり、
前記コプロセッサは、条件に応じて前記ホストプロセッサへ起動信号を供給するように構成され、
前記ホストプロセッサは、前記起動信号のうちの特定の1つを受信すると、前記スリープモードから前記アクティブモードへ切り換わるように構成され、
前記ホストプロセッサは、前記アクティブモードにおいて、前記スリープモードに切り替わる前に、前記コンテンツ情報の複数のセグメントのうちの特定の1つを前記コプロセッサに転送するように構成され、
前記コプロセッサは、前記特定のセグメントをレンダリングする前に、前記特定のセグメントをバッファにバッファリングするように構成され、
前記コプロセッサは、前記特定のセグメントのレンダリングの進行に関する所定レベルを検出すると、前記ホストプロセッサの制御の下、前記ストレージから前記コプロセッサへ前記複数のセグメントのうちの次の1つの転送を開始するために前記ホストプロセッサへ前記起動信号のうちの次の1つを供給するように構成され、
前記コプロセッサが非アクティブの場合に、通信のレンダリングの制御のために、前記ホストプロセッサは、外部からバイパス経路を介して、前記レンダリング機能を有効又は無効にするように構成されている、
モバイル電子装置。
【請求項２】
前記コプロセッサは、レンダリングコンポーネントで前記コンテンツ情報のレンダリングを、前記外部通信ネットワークを介して受信された通信のレンダリングと結合するための、結合器を備えた、請求項1に記載のモバイル電子装置。
【請求項３】
外部通信ネットワークを介して通信するための通信機能と、ストレージに記憶されたコンテンツ情報をレンダリングするレンダリング機能と、モバイル電子装置のユーザ制御のためのユーザインターフェースとを備え、さらに前記通信機能と前記ユーザインターフェースとの制御のためのホストプロセッサと、前記レンダリング機能の制御のためのコプロセッサと、を備えた前記モバイル電子装置の前記ストレージに格納されたコンテンツ情報をレンダリングする方法であって、
前記起動信号を受けると、前記ホストプロセッサを、スリープモードからアクティブモードへ切り換えるステップと、
前記ホストプロセッサによって前記コンテンツ情報の複数のセグメントのうちの特定の1つを前記ストレージから前記コプロセッサに転送するステップと、
前記ホストプロセッサを前記スリープモードに切り換えるステップと、
前記コンテンツ情報の前記特定のセグメントを前記コプロセッサのバッファにバッファリングし、その後、前記特定のセグメントをレンダリングするステップと、
前記特定のセグメントのレンダリングの進行に関する所定レベルを検出すると、前記ホストプロセッサの制御の下、前記ストレージから前記コプロセッサへ前記複数のセグメントのうちの次の1つの転送を開始するために、前記コプロセッサから前記ホストプロセッサへ前記起動信号のうちの次の1つを供給するステップと、
を備え、
前記コプロセッサが非アクティブの場合に、前記ホストプロセッサは、バイパス経路を介して、前記レンダリング機能を外部から有効及び／又は無効にする命令を供給する、
ことを特徴とする方法。
【請求項４】
前記起動信号は、前記コプロセッサによって送信される、請求項３に記載の方法。
【請求項５】
第1起動信号は、前記ユーザインターフェースまたは前記通信機能を介して受信される、請求項３に記載の方法。
【請求項６】
前記第1起動信号の後、前記ホストプロセッサが前記コプロセッサを起動してレンダリングを開始させる、請求項４に記載の方法。
【請求項７】
前記起動は、前記コプロセッサへ動作命令を転送するステップを備える、請求項６に記載の方法。
【請求項８】
前記コプロセッサは、前記ホストプロセッサが前記コプロセッサをアクティブモードへ起動できる別個の起動機能を有する、請求項４または５に記載の方法。
【請求項９】
前記ホストプロセッサは、前記別個の起動機能によりバイパス経路を介して外部から前記レンダリング機能を有効及び／又は無効にする命令を供給する、請求項８に記載の方法。
【請求項１０】
請求項1に記載されたモバイル電子装置におけるレンダリング機能の制御のためのコプロセッサであって、
条件に応じて前記モバイル電子装置におけるホストプロセッサへ起動信号を供給するための手段と、
前記ホストプロセッサからコンテンツ情報のうちの少なくとも1つのセグメントを受信するための手段と、
前記セグメントをバッファリングするためのバッファと、
前記セグメントをレンダリングするための処理手段と、
前記セグメントのレンダリングの進行に関する所定レベルを検出して、前記ホストプロセッサへ次の起動信号の供給を可能にするための検出手段と
を備えたコプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル電子装置に関し、たとえばモバイル電話または通信ネットワークインターフェースを備えたモバイルコンピュータ装置に関する。当該装置は、外部ネットワークを介して通信するための通信機能と、ストレージに記憶されたコンテンツ情報をレンダリングするためのメディアレンダリング機能とを有する。
【背景技術】
【０００２】
モバイル電話は、電話機能を実施する専用のベースバンドエンジンを有する。今日のモバイル電話では、ベースバンドエンジン（「アプリケーションエンジン」とも称される）は、従来の電話アプリケーションに加えて多くの機能を提供する。追加の機能は、たとえばユーザインターフェース制御、ユーザインターフェースにおけるオーディオおよび映像のようなメディアのレンダリング、ロケーションベースサービス、ネットワーク接続性およびブラウジングに係わる。小さなフォームファクタおよび自律性は、モバイル電話ユーザへのキー発行である。結果として、ベースバンドエンジンは、最小限の周辺部と非常に低電力消費のスタンバイモードを実施する手段とを備えた高集積システムオンチップ（SoC）である。現在、ベースバンドエンジンは、セルラーフロントエンドが任意の電話呼び出しのためにネットワークと処理（update）している時間の間、非常に小さい電力を消費する。エンジンの回路の多くは、スイッチオフされ、少しの回路のみが、RFフロントエンドでのトリガーを検出するためにスイッチオンされる。
【０００３】
しかしながら、スタンバイモードを実施する手段は、モバイル電話が電話呼び出しを待機しかつ多くのデータトラフィックが要求されていない、シナリオへ合わせられている。ユーザが電話とやりとり（たとえばユーザが双方向性を要求し、またはサービスを必要とする）を行うと、データトラフィックバックボーンが高速度かつ並列メディア処理機能用に設計されているため、エンジンがアイドルであっても、ベースバンドエンジンはかなりの高いレベルで電力を消費する。結果として、多くの機能を備えたあるモバイル電話は、電話の電源パックまたはバッテリが、不便にも短い時間期間（たとえば1日または2，3時間程度）で空になるため、十分に使用できない。これは特に、MP3データ、とりわけオーディオといったメディアの再生に係わる。ユーザは、再生時間の上昇を期待している。現在、バッテリが再充電される前に、およそ20時間の再生時間が得られ、この時間量はあまりに低いと考えられる。
【０００４】
それを別の観点から見ると、モバイル電話の分野で、ますます機能が拡張するより新たなモバイル電話の傾向が現れてきた。様々なデジタル技術がモバイル電話に集中している。たとえばモバイル電話は、GPSナビゲーション、モバイルTV、モバイルEメールなどのアプリケーション用の回路が備え付けられている。別の例として、現代のモバイル端末が、広域セルラーアクセスネットワークを介した通信と、インターネットへのローカル無線接続を介した通信（たとえばボイスオーバーIP（VoIP）用）との両方をサポートしているという意味で、フィックスドおよびモバイル電話が集中（融合）している。後者の傾向は、「フィックスド−モバイルコンバージェンス」と呼ばれる。これらのコンバージェンス技術から生じるモバイル電話プラットフォームは、「コンバージェンスアーキテクチャ」と呼ばれることもある。以前は、単一の通信機能を実施する回路は、とりわけ低電力消費に関して最適化されていた。様々な機能を同じプラットフォームでマージし、異なる機能間でハードウェアコンポーネントを共有することは、低電力消費に関して、以前の最適化を現実的に意味のないものにする。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、本願発明の実施形態の目的の1つは、モバイル電話、または、機載無線電話または別の機載データ通信機能をもった同様のモバイル電子装置において、メディアの長い再生時間を可能にすることにある。長い再生時間により、モバイル電話または他のモバイル電子装置の必須機能が阻害されてはならない。そのような必須機能は、電話としての装置の使用、および適切かつ高速なユーザインターフェース機能を含む。
【０００６】
本発明者は、外部通信ネットワークを介して通信するための通信機能と、ストレージに記憶されたコンテンツ情報をレンダリングするレンダリング機能と、モバイル電子装置のユーザ制御のためのユーザインターフェースと、を有するモバイル電子装置を提案する。当該装置は、前記通信機能と前記ユーザインターフェースとの制御のためのホストプロセッサと、前記レンダリング機能の制御のためのコプロセッサと、を備える。前記ホストプロセッサは、前記ストレージへアクセスする。前記ホストプロセッサは、アクティブモードとスリープモードとを有する。前記ホストプロセッサは、前記アクティブモードにおいて高電力消費、前記スリープモードにおいて低電力消費である。前記コプロセッサは、条件に応じて前記ホストプロセッサへ起動信号を供給するように構成される。前記ホストプロセッサは、前記起動信号のうちの特定の1つを受信すると、前記スリープモードから前記アクティブモードへ切り換わるように構成される。前記ホストプロセッサは、前記アクティブモードにおいて、前記スリープモードに切り替わる前に、前記コンテンツ情報の複数のセグメントのうちの特定の1つを前記コプロセッサに転送するように構成される。前記コプロセッサは、前記特定のセグメントをレンダリングする前に、前記特定のセグメントをバッファにバッファリングするように構成される。前記コプロセッサは、前記特定のセグメントのレンダリングの進行に関する所定レベルを検出すると、前記ホストプロセッサの制御の下、前記ストレージから前記コプロセッサへ前記複数のセグメントのうちの次の1つの転送を開始するために前記ホストプロセッサへ前記起動信号のうちの次の1つを供給するように構成される。
【０００７】
ホストプロセッサは、依然として当該装置のオンボードのシステムのマスターである。ホストプロセッサは装置のユーザインターフェースを制御する。レンダリング処理は、時間内で線形であるため、コンテンツ情報は、時間的に連続したセグメントに分割されることができ、セグメントの連続した各々のレンダリングは連結されることができる。コンテンツ情報のセグメンテーションおよびコプロセッサでの再生は、ホストプロセッサがバーストで動作し、バースト間でスリープモードに滞在することを可能にする。ホストプロセッサは、通信機能に関して最適化されたままであることが可能であり、コプロセッサは、レンダリング機能を実施する回路内の他のコンポーネントと共に、メディアレンダリングに関して最適化されることができる。結果として、電力消費を、メディア固有のレンダリングタスクに関して、最小化または最適化できる。
【０００８】
本発明における装置の実施形態において、前記コプロセッサは、レンダリングコンポーネントにおいて、前記コンテンツ情報のレンダリングを、前記外部通信ネットワークを介して受信された通信のレンダリングと結合するための、結合器を備える。したがって、通信のレンダリングは、着信通信の間に再生されているコンテンツ情報のレンダリングと合成されることができる。
【０００９】
本発明における装置のさらなる実施形態において、当該装置は、前記コプロセッサがスリープモードのときに前記通信のレンダリングの制御のため前記ホストコンピュータの制御の下、前記レンダリングコンポーネントを有効または無効にするように構成される。もしコプロセッサが非アクティブであれば、ホストプロセッサは、コプロセッサにおける最小限の資源を用いて、通信をレンダリングするためにレンダリングコンポーネントを直接制御する。
【００１０】
さらなる実施において、コプロセッサ集積回路は、揮発性メモリ部を備える。これは、コプロセッサがホストプロセッサによって起動するごとに、ホストプロセッサからの動作命令の再ロードを必要とする。しかしながら、それは電力消費を全体として低減可能である。動作命令のこの再ロードは、少なくとも現在では、処理されるメディアがオーディオデータであるならばもっとも適切であることが分かっている。オーディオデータでは、動作命令およびメディアデータの量が、必要とされるデータ転送の観点において適切である。
【００１１】
さらなる電力消費に関してもっとも適切には、コプロセッサは、別個の電源管理部を備える。そのような電源管理部は、コプロセッサ集積回路に組み込まれてもよいし、別個のチップとして設けられても良い。
【００１２】
別の態様において、本願発明は、当該装置の動作の方法に関する。基本的に、当該方法は、
前記起動信号を受けると、前記ホストプロセッサを、スリープモードからアクティブモードへ切り換えるステップと、
前記ホストプロセッサによって前記コンテンツ情報の複数のセグメントのうちの特定の1つを前記ストレージから前記コプロセッサに転送するステップと、
前記ホストプロセッサを前記スリープモードに切り換えるステップと、
前記コンテンツ情報の前記特定のセグメントを前記コプロセッサのバッファにバッファリングし、その後、前記特定のセグメントをレンダリングするステップと、
前記特定のセグメントのレンダリングの進行に関する所定レベルを検出すると、前記ホストプロセッサの制御の下、前記ストレージから前記コプロセッサへ前記複数のセグメントのうちの次の1つの転送を開始するために、前記コプロセッサから前記ホストプロセッサへ前記起動信号のうちの次の1つを供給するステップと、
を備える。
【００１３】
第1実施形態において、第1起動信号は、コプロセッサからの信号である。しかしながら、第1起動信号が、ユーザインターフェースまたは通信機能を介して生成されることは排除しない。
【００１４】
このアプリケーションのコンテキストにおいて、ホストプロセッサはアクティブモードへ切り換わるとき、完全にスリープモードにいる必要はないことが理解されるべきである。たとえば、レンダリング機能の専用の部分は、スリープモードにあり、通信機能の制御に関する部分といった他の部分はアクティブであることも可能である。さらに、アクティブモードへの切り替えのための起動信号は、ホストコンピュータをアクティブモードへ切り換えてコンテンツ情報のレンダリングを可能にする信号のオプションを含む。
【００１５】
さらなる実施形態において、コンテンツ情報のレンダリングを開始するための命令を受信すると、ホストプロセッサはコプロセッサを起動する。これは、ホストプロセッサからコプロセッサへの特定の起動信号の供給を含んでも良い。さらに好適には、その起動は、ホストプロセッサによってコプロセッサへ動作命令を転送するステップを含む。これは、特に、コプロセッサが、内部の揮発性メモリに基づいて動作する場合に望ましい。
【００１６】
さらなる態様において、本発明は、本発明のモバイル電子装置において使用するコプロセッサに関する。そのコプロセッサは  条件に応じて前記モバイル電子装置におけるホストプロセッサへ起動信号を供給するための手段と、
前記ホストプロセッサからコンテンツ情報のうちの少なくとも1つのセグメントを受信するための手段と、
前記セグメントをバッファリングするためのバッファと、
前記セグメントをレンダリングするための処理手段と、
前記セグメントのレンダリングの進行に関する所定レベルを検出して、前記ホストプロセッサへ次の起動信号の供給を可能にするための検出手段と
を備える。
【００１７】
コプロセッサは、1つ以上の集積回路を含んでも良い。
【図面の簡単な説明】
【００１８】
【図１】本発明における電子無線通信装置のブロック図である。
【図２】図1の装置におけるメモリ管理で用いられるオンデマンドページング（On-Demand-Paging:ODP）アプローチにおける遷移を示す状態マシン線図である。
【図３】図2の線図への代替案を示す状態マシン線図である。
【図４】図2の線図への代替案を示す状態マシン線図である。
【発明を実施するための形態】
【００１９】
添付図面を参照しながら、例を用いて、本願発明を詳細に説明する。すべての図に渡って、同様または対応する特徴は、同じ参照符号によって示される。
【００２０】
図1は、本願発明における電子無線通信装置100のブロック図である。装置100はホストプロセッサ102およびメディアコプロセッサ104を収容する。ホスト102は、特に、装置100のモジュール106のベースバンド機能を制御する。コプロセッサ104は、適当なレンダリングコンポーネント108（たとえば表示モニタ、ラウドスピーカ）において、メディア（ここではコンテンツ情報と称されることもある）のレンダリングを制御し、そのメディアは、記憶されたまたはダウンロードされたオーディオまたはビデオである。
【００２１】
装置100のユーザは、ユーザインターフェース（UI）110を介して、装置100とやり取りする。装置100の実施形態において、UI110は、たとえばハードボタンおよび／または、レンダリングコンポーネント108の一部として表示モニタのタッチスクリーンにおけるソフトキーまたは他の仕掛け（たとえばグラフィカルユーザインターフェース（GUI）におけるスクローリングおよびハイライティング機能）の集合によって実装される。ユーザは、マルチメディア機能（たとえば映像を再生する、オーディオを再生する）を選択し、UI110を介して、レンダリングコンポーネント108でレンダリングするコンテンツ情報の関連ファイルを選択する。
【００２２】
UI110は、ホストプロセッサ102を介して制御される。メディア機能、たとえばオーディオのレンダリング、のユーザ選択がUI110を介して行われると、ホストプロセッサ102は、コプロセッサ104の起動を開始する。その起動は、たとえばコプロセッサ104の電源システム（図示せず）、たとえばlow-dropout regulators(LDOs)およびDC−DCコンバータの起動、コプロセッサ104および場合によってはレンダリングコンポーネント108および他の周辺機器（図示せず）へのパワーオンリセットの生成を含む。コプロセッサ104によるメディアのレンダリングの起動の前および起動の間、ホストプロセッサ102は完全に起きている。コプロセッサ104でレンダリングを開始した後、ホストプロセッサ102はスリープモードに入る。すなわち、ホストプロセッサ102は、UI110を介したユーザリクエストによって引き起こされるようにコプロセッサ104のサービスを必要とするため、ホストプロセッサ102は、コプロセッサ104を起こす。コプロセッサ104が適切に構成されて、要求されたサービスのために必要とするデータが供給された後、ホストプロセッサ102は、スリープモードに入る。
【００２３】
スリープモードにおいて、ホストプロセッサ102は、セルラーフロントエンドが任意の電話呼び出しのために通信ネットワークと更新している時間期間の間に、ベースバンドエンジンとして動作し、そのとき少量の電力のみを消費する。ホストプロセッサ102の回路のほとんどは電源を切られ、ほんの少しの回路のみがトリガーを検出するために電源を入れられている。
【００２４】
コプロセッサ104は起動された後、コプロセッサ104はホストインターフェースコントローラ116を介して、ホストプロセッサ102へブートリクエストの信号を発する。
【００２５】
コプロセッサ用のファームウェアおよび設定は、コプロセッサ104をブートするために必要であり、ホストプロセッサ102に結合された固定不揮発性メモリに格納されている。ファームウェアおよび設定は、基本的に、たとえばモバイル電話として実施されるモバイル通信装置100の標準ファームウェアの一部である。ホストプロセッサ102はブートリクエストから、何のプログラム画像が、新たに付加されたコプロセッサに対応するのかを決定する。ホストプロセッサ102は、次にこの画像を固定ストレージからフェッチし、それをホストインターフェースコントローラ116およびコプロセッサインターフェースコントローラ114を介して、コプロセッサ104におけるメモリ118の専用メモリ空間へ運ぶ。この後、コプロセッサ104は、このメモリ空間から実行を開始し、要求されたサービスを顕在化させる。
【００２６】
好適には、そのファームウェアは、メディアコプロセッサ104がデータにおけるエラーを検出可能にするようにヘッダおよびチェックサムを備えて、バイナリ形式で転送され、これによりファームウェアを内部メモリ118、たとえばSDRAMへロードするときにデータの完全性を保つ。ヘッダにおけるチェックサムおよびペイロードを介してファームウェアの完全性を検証したとき、メディコプロセッサ104は実行を開始する。
【００２７】
したがって、ファームウェアは、装置100（たとえばモバイル電話）がスイッチオンされたとき、またはコプロセッサ104の追加機能または修正機能が必要とされるときに、ロードされる。それ故、装置100は、動的にメモリ118へソフトウェアコンポーネントをロードすることが可能である。結果として、組み込まれるメモリ118のサイズは、比較的小さく保たれることができる。さらに、柔軟性が、コプロセッサ104によって与えられるサービスに導入される。
【００２８】
上述したように、ユーザはUI110を介して、再生されるべきコンテンツ情報を選択する。ホストプロセッサ102は、まず装置100のオンボードのメディアコンテナ120、またはデータネットワークを介してアクセス可能でありバッファ120にローカルにバッファリングされる外部ストレージから、コンテンツ情報を取り出す。コンテンツ情報はデータファイルとして取り出され、タイプ（たとえばオーディオ、映像）を表すメタデータおよびコンテンツ情報のフォーマット（たとえばMP3、MPEG2など）を含む。このメタデータは、ホストプロセッサ102が、適切なコーデックを選択することを可能にする。ホストプロセッサ102は、ホストプロセッサ102およびコプロセッサ104間のやりとりを可能にするコプロセッサアプリケーションインターフェースを介して、コプロセッサ104のマルチメディアストリーミングフレームワークを設定する。これが実行された後、コプロセッサ104は、選択されたコンテンツ情報の第1セグメントを要求し、そのセグメントをローカル揮発性ストレージ132にバッファリングする。転送されるセグメントのサイズは、バッファ132のサイズに合致する。十分なデータが受信された後、コプロセッサ104は、メディア復元部128およびレンダリングコンポーネント108を介して、再生を開始する。ホストプロセッサ102は、他のタスクが他のサービスまたはアプリケーションから要求されなければ、スリープモードに入る。以下に、転送メカニズムをさらに詳細に説明する。
【００２９】
装置100の実施形態において、ホストプロセッサ102とコプロセッサ104間のデータ通信は、特定のマルチメディアフレームワーク（またはソフトウェアインターフェース）、たとえばKhronosグループによって開発されたOpenMax APIを用いて、可能にされる。OpenMaxは、メディアコンポーネントのための明確なメディアインターフェース記述を定義するための業界計画である。OpenMaxは、業界全体で同意されたメディアサービスへ、コプロセッサ104の機能を抽出することをサポートする。
【００３０】
再生の間、コプロセッサ104は、ホストプロセッサ102へ、起動信号を割り込みハンドラ112へ発行することによって、コンテンツ情報の次のセグメントを受信する用意ができているとの信号を送る。コプロセッサ104から起動信号の受信を受けて、割り込みハンドラ112は、ホストプロセッサ102が、スリープモードからアクティブモードへ切り替えことを引き起こす。アクティブモードにおいて、ホストプロセッサ102は、選択されたコンテンツ情報の次のセグメントを取り出し、ホストインターフェースコントローラ112およびコプロセッサインターフェースコントローラ114を介してコプロセッサ104へ転送し、再度、スリープモードへ入る。
【００３１】
上述したように、本発明の実施形態において、選択されたコンテンツ情報のセグメントは、記憶インターフェースコントローラ122およびロードストア部124の制御の下、装置100のオンボードの、または装置100に電気的に接続されたメディアコンテナ120から取り出される。知られているように、ロードストア部は、メモリ、この場合ではメディアコンテナ120と簡単なやりとりを扱うための専用モジュールである。メディアコンテナ120は、たとえばフラッシュカードを備える。好適には、ホストプロセッサ102によって供給されるようなセグメントは、圧縮形式であり、圧縮データのビットレートに対するレンダリングビットレートの比率を最大化する。さらに、圧縮形式は、転送の時間期間を短縮可能にし、したがってホストプロセッサ102がアクティブモードに滞在する時間期間を短縮可能にする。コプロセッサ104は次に、復元（解凍）動作を実行するための復元モジュール128を備える。注意すべきことは、コプロセッサ104でメディアを復元することにより、レンダリングされる出力に比較して、コプロセッサ104へのホストプロセッサ102からの平均データレートが減少することである。コプロセッサ104で実行される当該復元を有するこの特徴は、可能な限りホストプロセッサ102を眠らせることに大いに寄与する。寄与する他の要因は、ストレージ132のバッファサイズと、ホストプロセッサ102とコプロセッサ104間の最大転送レートである。それ故、高速度データバス126を介して送られ、可能な限り短く、ホストプロセッサ102の動作時間を保つ。たとえば高速度データバス126は、シリアルペリフェラルインターフェース（SPI）、モバイルインダストリープロセッサインターフェース（MIPI）、高速度シリアルインターフェース（HSI）、モバイルインダストリープロセッサインターフェース（MIPI）スリムバス（シリアル低電力チップ内メディアバス）、MIPI Unipro（Unified Protocol、モバイル電話、ハンドヘルドコンピュータまたはPDA、デジタルカメラなど内の装置およびコンポーネントを相互接続するための高速度シリアルインターフェースにおける階層化されたプロトコル、高データレート、高効率および低ピン数のために設計された）などである。上述した種類のシリアル
バスの1つで、典型的なデータ速度は、1Mbit/secから100Mbits/secの範囲にある。または、ホストプロセッサ102は、たとえば外部ソースから無線接続、たとえばインターネットまたは別のデータネットワーク上のサーバからアクセスポイントを介して、ベースバンドモジュール106の制御の下、コンテンツ情報を取り出す、たとえばダウンロードする。選択されたコンテンツ情報の取り出されたデータは、ネットワークバッファ130にバッファリングされる。ネットワークバッファ130は次に上述したストレージ120と同様の役目を提供する。注意すべきことは、情報コンテンツをネットワークバッファ130に完全にダウンロードすることはオプションであるということである。別のオプションは、ネットワークバッファ130に一度に1つずつ単一のセグメントをバッファリングするように、セグメントにおけるコンテンツ情報をダウンロードすることである。好適には、サーバーサイドは、セグメントにおけるコンテンツ情報を順々に提供する。セグメントのダウンロードが行われると、ホスト102は、次のセグメントがメディアコプロセッサ104への配送のための期限になるまで、スリープモードに入ることができる。このコンテキスト内では、ヨーロッパ特許第1131930号「ストリーミングをエミュレーションするためのファイルのパーティショニング」を参照する。この特許は、電子ファイル、たとえばMP3ファイルを、サーバーサイドでセグメントのシーケンスへ、パーティショニングすることに関する。第1セグメントはダウンロードされて再生される。第1セグメントが再生されている間、第1セグメントの実行が完了したときに利用可能であるように第2セグメントがダウンロードされバッファリングされる。現在のセグメントを再生している間、次のセグメントがダウンロードされバッファリングされる。このパーティショニングおよびシーケンシャル再生は、ファイルのストリーミングをエミュレーションし、電子ファイルをダウンロードする間、レイテンシを最小化することを可能にする。
【００３２】
ホストプロセッサ102から情報コンテンツのセグメントを受け取った後、コプロセッサ104は、ローカル揮発性ストレージ132にセグメントをバッファリングする。ストレージ132にバッファリングされたセグメントのデータは、次にメディア復元部128において読み出され、続いてそのデータをコンポーネント108でのレンダリングに適したフォーマットに変換するメディアレンダリングコントローラ134へ転送される。たとえば、コンテンツ情報はオーディオファイルであるならば、コントローラ134は映像ファイルのデータを、たとえばレンダリングコンポーネント108におけるLCD表示モニタにおけるレンダリングのために、適切なデジタルフォーマットへ変換する。ストレージ132は、好適には、循環バッファ（またはリングバッファ）として構成される、DRAMまたはSDRAMを備える。
【００３３】
シームレス態様でレンダリングを継続するために、新たなセグメントが、現在レンダリングされているセグメントが完了する前に、コプロセッサ104に転送されるべきである。したがって、ホストプロセッサ102は、間に合うように起こされ、スリープモードからアクティブモードへ切り換えられることにより、次のセグメントを取り出してバス126を介して当該次のセグメントをコプロセッサ104へ転送する。その転送が行われると、ホストプロセッサ102は再度スリープモードに入る。コプロセッサ104は、ホストプロセッサ102が起動信号の受信からアクティブモードへ入るのに要する時間と、次のセグメントを取り出して転送する時間とを考慮して、現在のセグメントのレンダリングが完了する前に、起動信号を発行するべきである。
【００３４】
このタイムリーな起動のためのメカニズムを実行する1つの方法は、コプロセッサ104が現在のセグメントをレンダリングするのに必要な時間と、起動して次のセグメントを取り出しコプロセッサ104へ転送するのにホストプロセッサ102によって要される時間と、レンダリングの準備ができる前にセグメントをコプロセッサ104が処理するのに要する時間とを前もって決定しておくことである。クロックは、新たなセグメント毎の再生で、再スタートされる。再スタートの後、現在のセグメントがレンダリングされている間、クロックは、任意の時点で、現在のセグメントのレンダリングが完了する前に残されている時間量を表す。残された時間が、ホストプロセッサ102が起動して次のセグメントを取り出しコプロセッサ104へ転送するのに必要な時間に、コプロセッサ104によって、レンダリングの準備ができる前に次のセグメントを処理するのに必要な時間期間を加算した長さに等しい、またはやや大きいならば、コプロセッサ104は次の起動信号をホストプロセッサ102に発行するべきである。
【００３５】
これを実行する別の方法は、レンダリングのためにバッファ132に残されているデータ量の追跡を、コプロセッサ104にさせ続けることである。閾値すなわちウォーターマークは、バッファ132における残されたデータ量で設定されることができ、そのレンダリングは、一方においてホストプロセッサ102が起動して次のセグメントを取り出してコプロセッサ104に転送し、コプロセッサ104がレンダリングの準備ができる前に次のセグメントを処理するために、十分な時間を必要とする。閾値すなわちウォーターマークは、たとえばバッファ132のサイズ、コンテンツ情報のセグメントのサイズ、バス126の転送スピード、コプロセッサ104にホストプロセッサ102から次のセグメントを受信させてレンダリングのために準備させるための上記の時間に依存する。
【００３６】
要するに、レンダリング処理は、時間内で線形であるため、コンテンツ情報は、時間的に連続したセグメントに分割されることができ、セグメントの連続した各々のレンダリングは連結されることができる。コンテンツ情報のセグメンテーションは、ホストプロセッサ102がセグメントを転送するためにバーストで動作し、バースト間でスリープモードに滞在することを可能にし、したがって電力を節約することができる。本発明の実施形態において、ホストプロセッサ102が圧縮されたデータをオンザフライで、バッファ132の実施サイズに応じて、セグメント化する。
【００３７】
ここで、着信する電話呼び出し、着信するSMSメッセージ、着信する映像メッセージ等のシナリオが、以下の異なる条件の下、モジュール106によって扱われることを考える。1）メディアコプロセッサ104がコンテンツ情報をレンダリングするのに忙しい、2）メディアコプロセッサ104がオフまたは、ホストプロセッサ102からのトリガーを待機するアイドル／スリープモードにある。
【００３８】
条件1）では、メディアプロセッサ104が、メッセージ（たとえば電話呼び出し、Eメール、SMSなど）がモジュール106を介して着信している間、コンテンツ情報をレンダリングしている。モジュール106は1つ以上のコーデック136、たとえば音声コーデック、テキストコーデック、映像コーデックなどを備えている。ホストプロセッサ102は、着信メッセージを表すデータを、アナログ形式またはデジタル形式で（たとえばパルスコード変調（PCM）でI2Sバスを介して）メディアコプロセッサ104へ送る。メディアコプロセッサ104は、レンダリングモジュール134へのメッセージデータの直接転送のためのバイパス経路を有する。モジュール134は、そのデータを、そのときにレンダリングされているコンテンツ情報と機能上結合するための結合器38を有する。たとえば着信するメッセージが電話呼び出しであり、レンダリングされているコンテンツ情報がオーディオファイルであるとする。このとき、着信音が、レンダリングされているオーディオと混合され、混合されたデータが、レンダリングコンポーネント108、ここではラウドスピーカへ送られる。もしユーザがその電話を受けることを決定する場合、音声データが、レンダリングされているオーディオと混合され、混合されたデータがラウドスピーカ108に送られる。設定モードにおいて、装置100は、ユーザによってコンテンツ情報と音声データを音量に関して異なる設定にしたがって、設定されることができる。すなわち、ユーザは装置100を、着信音が混合され、レンダリングされるとすぐに、UI110を介して、オーディオコンテンツ情報の音量を所望のレベルへ低下させるように設定することができる。メディアプレーヤで音声レベルを設定することは、従来において知られており、ここではさらに詳細には述べない。別の例では、着信メッセージがSMSメッセージであり、レンダリングされているコンテンツ情報が映像クリップであるとする。このときモジュール106はメディアコプロセッサ104へテキストデータ（または視覚的にレンダリングされるための他のデータ）を提示して、ユーザに新たに受信されたメッセージをアラートする。このテキストデータは次に、クリップの映像データと混合される。たとえばアラートデータが映像クリップの映像に重ねられ、好ましくは、あまり煩わしくない態様、たとえば半透明なアイコンを介して行う。アイコンを再現するデータは、たとえばストレージ120に記憶されている。もしユーザがSMSメッセージを見ることを決定したならば、そのテキストがデータとしてモジュール106からモジュール134へ送られ、結合器138を介して同様にオーバーレイで、レンダリングされる。メッセージへのアラートおよびメッセージ自体はいずれとも、たとえばオンスクリーンディスプレイ（OSD）技術を用いて、レンダリングされる。
【００３９】
条件2）では、メディアコプロセッサ104はオフにされ、またはモジュール106が着信するメッセージを受信したときアイドルまたはスリープモードである。プロセッサ102，104の汎用目的入力／出力（GPIO）およびバイパス経路を介して、ホストプロセッサ102は外部からレンダリングコンポーネント108を有効化または無効化する。バイパス経路はコプロセッサ104がスリープモードに滞在することを可能にし、結合器138からレンダリングコンポーネント108への回路のみが、低電力ではあるが依然として動作中である。高速バス126は、これらの状況の下では必要でない。注意すべきことは、これは電力消費を低減するのに有益であり、その理由は高速バス126はホストプロセッサ102とコプロセッサ104との両方からのサポートを必要とするからである。
【００４０】
注意すべきことは、典型的なモバイル電話ソフトウェアでは、音声はモデムスタックで扱われることである。モデムソフトウェアスタックはホストプロセッサ102で実行される。モデムスタックは、典型的には、音声通信と、通信ネットワークを介して着信する他のイベントを扱うことに関する。たとえばSMSは、モデルを介して着信する。イベントは、（たとえば着信音を生成するために）モデムスタックを介して信号発信され、処理、編集等は、アプリケーションスタックを介して進み、さらにホストプロセッサ102で実行される。したがって、SMSおよび他の通信サービス（たとえばEメール、ビデオ会議など）は、ホストプロセッサ102を介して処理される。しかしながら、ホストプロセッサ102は、コプロセッサ104を介してレンダリングコンポーネント108へアクセスする必要がある。コプロセッサ104はこの機能のために最適化されてきており、上述したようにバイパス経路を備える。したがって、レンダリングコンポーネント108への接続のみが必要とされる。
【００４１】
スリープモードにおける動作のため、コプロセッサ104は低電力モードで設定されている。これは、休止モードまたはアイドルモードで動作するプロセッサ104を含む。さらに、SDRAM118は、自己リフレッシュモードへ置かれて、さらなる電力消費を低減してもよい。専用GPIOを介して、ホストプロセッサ102はレンダリングコンポーネント108に対するパスを有効化および無効化することができる。そのようなGPIOをアサートすることで、コプロセッサ104が（たとえば割り込みを介して）起動する。コプロセッサ104は次にレンダリングコンポーネント104を電源オンし、スリープモードに戻り、結果として、SDRAM118を、同様に自己リフレッシュモードへ置く。パスはいま有効であるため、ホストプロセッサ102はレンダリングコンポーネント108へアクセスすることができる。ホストプロセッサ102がそのタスクを終了した後、ホストプロセッサ102はレンダリングコンポーネント108へのパスを無効化することができる。電力消費は、さらにSDRAM118への記憶を必要としない、特別に用意されたプログラムをロードすることによって減じられることができる。したがって、SDRAM118は完全に電力を落とすことができる。そのような小さなプログラムは、コプロセッサ104でのオンチップSDRAM（図示せず）へ取り付けることができ、スリープモードでは非常に少ない電力を消費する（保持のみが必要とされる）。
【００４２】
ここでメディアコプロセッサ104がコンテンツ情報の第1片をレンダリングし、当該第1片のレンダリングの進行中にユーザがUI110を介してレンダリングのためのコンテンツ情報の第2片を選択するシナリオを考える。
【００４３】
ユーザ入力を受信すると、ホストプロセッサ102はOpenMaxソフトウェアレイヤを介して動作し、第1片の再生を停止する。ホストプロセッサ102はメディアコンテナ120から（またはネットワークバッファ130を介して外部ソースから）、第2片の第1セグメントを取り出し、当該第1セグメントを上述した処理を用いてメディアコプロセッサ104に転送する。バッファ132は、次にリロードされ、再生が再スタートされる。もし新たなコーデックまたはエフェクトが選択されたならば、新たなグラフが立てられ、異なるコンポーネントが作動およびロードされる。装置100のアーキテクチャはコンポーネントの動的なロードをサポートする。したがって、ブートおよびセットアップの後でも、新たなコンポーネントがロードされることができ、現存のコンポーネント（コーデック、エフェクト）がバッファ132およびSDRAM118から取り除かれることができる。
【００４４】
たとえば、第1歌曲の再生の次に第2歌曲の再生が行われるシナリオを考え、ここで当該第2歌曲は、プレイリストによって事前に決定され、または第1歌曲の再生の完了によりユーザによって選択される。第2歌曲は、異なるオーディオコーデックをもっていてもよい。それ故、オーディオパスは実行時に再設定される必要がある。この再設定は、上述したOpenMaxの制御の下で行われる。OpenMaxはメディア関連サービスを引き起こす、業界全体の共通のアプローチである。OpenMaxはコンポーネントの動的なロードをサポートする。この特徴は、任意のプラットフォームでコプロセッサ104を用いるという柔軟性をサポートする。同様に、OpenMaxは、メディアコンテナ形式のアップグレードを扱うこともできる。
【００４５】
本発明の実施形態において、第1歌曲の最後のセグメントが、再生のために事前に選択された歌曲のストリーム終端を知らせるために追加された特定のマーカーを有している。ホストプロセッサ102は、たとえば現在の歌曲から次の歌曲へのシームレスな再生を可能にするために、第2デコーダのインスタンス化を介して、現在の歌曲が終わる前に第2ストリームを開始するオプションを有する。このことは、ユーザ経験を高め、新たなグラフが設定され新たなセグメントがバッファ132にロードされた後にのみ次の歌が開始するのを阻止できる。
【００４６】
同様に、音量および／または画像明るさなどが、UI110および、メディアコプロセッサにその設定を変えるように指示するOpenMaxソフトウェアを介して、変えることができる。
【００４７】
コプロセッサ104は、ソフトウェア制御の下、データを処理するマイクロコントローラ140を備える。装置10の実施形態において、マイクロコントローラはたとえばホストインターフェースコントローラ116、メディア復元部128および／またはメディアレンダリングモジュール134とは異なった回路を有する。別の実施形態では、ホストコントローラ116、メディア復元部128およびメディアレンダリングモジュール134は、ソフトウェア制御の下、マイクロコントローラ140によって実行される機能である。明確のため、機能116、128、134は、マイクロコントローラ140とは別個の構成要素として、図1に示される。
【００４８】
大容量のポータブルマルチメディア製品、たとえばモバイル電話、音楽プレーヤのために、システム設計の焦点は、電力消費およびシリコン領域に当てられる。組み込みマイクロコントローラ140の電力性能に関して、マイクロコントローラ140に極めて近くのスタティックメモリ（ISRAM）142は、SDRAMまたはDDRAM(DDR SDRAM,すなわちDouble Data Rate-Synchronous DRAM)として実施されるとき、低電力であり、ローカル揮発性ストレージ132よりも速い。しかしながら、ISRAMサイズはダイ面積に大きな影響を与え、したがって製品の販売価格に大きな影響を与える。ISRAMは、組み込みプロセッサで実行されるコーデックを格納するために、およびデータを格納するために、ソフトウェアによって用いられる。知られているプロセッサでは、たとえばNexperia PNX0103モバイルマルチメディアプロセッサでは、ソフトウェアソリューションは、命令コードと読み出し専用データのために用いられる論理メモリ空間を、均等サイズの塊（ページ）で分割する。ページは、そのページに含まれる任意のデータへの第1アクセスに応じて外部ストレージ（たとえばNADNフラッシュメモリ）から内部メモリへロードされる。ISRAMの容量は制限されるため、そのソリューションは、どのページをISRAMから取り除くかを決定するためのメカニズムを含む。このソリューションおよびその拡張を、ここでは、「オンデマンドページング」（ODP）と称する。本発明において、ODPメカニズムは、電力消費を低減するために、SDRAMからSDRAMへ命令コードをロードするために用いられる。そのようなものとしてローカルRAMは、小さなキャッシュと見ることができる。ローカルRAMは、すべてのコードが外部チップ（off-chip）DRAMからフェッチされる必要がある状況に比べて、電力を低減する。
【００４９】
知られているように、その表現「デマンドページング」は、コンピュータオペレーティングシステムの分野で用いられ、仮想メモリのアプリケーションを参照する。
【００５０】
これを可能にする組み込みプロセッサによって用いられる基盤は、メモリ管理ユニット（MMU）、およびデータおよび命令アボートハンドラである。MMUは、組み込みプロセッサのメモリ空間の論理−物理マッピングを与える。ARMシステムにおいては、MMUは、1MBアドレス範囲をマッピングするためのセクションテーブルと、きめ細かな論理−物理アドレスマッピングを可能にするページテーブルとを用いる。もっともきめ細かなマッピングは、4kBまたは1kBページである。これらはODPページの細かさでもある。MMUにおけるテーブルエントリは、論理メモリ空間の部分へアクセスを許可または拒否するための制御を含んでも良い。このように、IDPアルゴリズムは、「アクティブ」（すなわちアクセスが許可される）または「非推奨（Deprecated）」（すなわちアクセスが拒絶されまたはページが不活性である）として、ページをマークする。非推奨ページからのコードまたはデータが組み込みプロセッサによってフェッチ（参照）されたとき、組み込みプロセッサは例外割り込み、たとえば「プリフェッチ」またはARMシステムにおける「データアボート」を立てる。
【００５１】
ページロードの数は、システム性能に影響を与え、その理由は、ロードで費やされるサイクルは、他の何にも用いられることができないからである。ページロードの数は、電力消費に影響することもあり、その理由は、ストレージ装置およびDRAMへのアクセスは電力を消費するからである。
【００５２】
ほとんどのオンデマンドページングアルゴリズムは、ページロードの数が制限されないという欠点を有する。
【００５３】
本発明の実施形態において、ページロードの数を制限、ひいては電力消費も制限するメカニズムを用いる。そのメカニズムは、コード実行のためにメモリアクセスに消費される電力消費を最適化する。
【００５４】
そのメカニズムの関連特徴は、ISRAMまたはSDRAMからどのコードを実行するかを実行時に決定する状態マシン、ISRAMまたはSDRAMからの実行へ外部ストレージからページをどのようにロードするかを実行時に決定する状態マシン、および実行時にODPによって管理されるメモリ空間を管理するメカニズムを含む。
【００５５】
図2の線図を参照して、論理ODPメモリ空間の各ページ（1kBまたは4kB）は、4つの状態のうちの1つにあることができる。状態「非推奨SDRAM」：ページが物理的にSDRAM内に存在するが、その論理アドレスを介したそのアクセスはMMUページテーブルエントリで拒絶される。状態「非推奨ISRAM」：ページは物理的にISRAM内に存在するが、その論理アドレスを介したそのアクセスはMMUページテーブルエントリで拒絶される。状態「アクティブISRAM」：ページは物理的にISRAM内に存在し、その論理アドレスを介したそのアクセスは、MMUページテーブルエントリで許可される。状態「アクティブSDRAM」：ページは物理的にSDRAM内に存在し、その論理アドレスを介したそのアクセスは、MMUページテーブルエントリで許可される。
【００５６】
「非推奨」状態の概念を導入した理由は、システムにおける履歴のフォームを導入するためである。このように、頻繁に必要とされるページは、ISRAM内に留まり、散発的なイベントに属するページは、SDRAM内に残る。周期的に、ハウスキーピング（HK）タスクが、多数の「アクティブ」ページを、「非推奨」状態へ動かす。その方法は、各状態に対して、その状態をもつすべてのページの順序付きリストを保持し、HKが、状態遷移のために最も古いページを選ぶことができる。
【００５７】
線図200は、以下の起こりうる遷移を説明する。
【００５８】
遷移202：非推奨SDRAM−アクティブISRAM：ページが参照され、非推奨ISRAM状態のページが存在する。そのページはISRAMへコピーされ、ページテーブルがそのマッピングを反映するように設定される。最も古い非推奨ISRAMページは非推奨SDRAM状態へ遷移し、その理由は、そのコンテンツはアクティブSDRAMへの遷移をなすページによって上書きされるためである。以下の遷移208を参照されたい。
【００５９】
遷移204：非推奨SDRAM−アクティブSDRAM：ページが参照され、非推奨ISRAM状態のページは存在しない。ページテーブルは、そのマッピングを活性化するように設定される。
【００６０】
遷移206：非推奨ISRAM−非推奨SDRAM：この遷移は、上記遷移202に対するものである。ページはSDRAMへコピーされる必要はなく、その理由は、そのオリジナルのメモリが決して開放されなかったためである。MMUページテーブルは、変化後の物理的マッピングを反映する必要がある。
【００６１】
遷移210：アクティブISRAM−非推奨ISRAM：周期的に「ハウスキーピングタスク」が、多数のX個のアクティブページを非推奨ISRAM状態へ動かす。これらのページに対し、起こる必要のある唯一の事は、ページを非活性に設定することである。
【００６２】
遷移212：アクティブSDRAM−非推奨SDRAM：周期的に、「ハウスキーピングタスク」が、多数のY個のアクティブページを、非推奨SDRAM状態へ動かす。これらのページに対し、起こる必要のある唯一の事は、ページを非活性に設定することである。
【００６３】
非推奨状態は、システムにおけるアクセスの履歴を形成するため、値X、Yをどのように決定するかを知ることが関係される。以下のシナリオが考えられる。
【００６４】
1）XとYを、アクティブSDRAMページの数と等しい値に設定する。したがって、ハウスキーピングの後、アクティブSDRAMページの数はゼロである。
【００６５】
2）Yを、アクティブSDRAMページの数と等しい値に設定する。したがって、ハウスキーピングの後、アクティブSDRAMページの数は依然としてゼロである。しかしながら、Xを、ZおよびYのうちの最小の値に制限し、ここでZは、アクティブISRAM(またはアクティブSDRAM)から非推奨ISRAM(または非推奨SDRAM)へ移動するページの数を制限する定数である。Zを決定することは、電力（Zは可能な限り低くあるべきである）と、ある低電力システム状態から、異なるODPページを用いる別の状態へ行くための速度（Zはできるだけ高くあるべきである）との間のトレードオフを決定することに関するすべてである。Zの適切な値は、Zの値の範囲にわたって最も低い電力を要するシナリオの電力消費を観測することによって得られることができる。
【００６６】
3）XとYの値を、Zと、ハウスキーピング（HK）の開始時におけるアクティブSDRAMページの数とのうちの最小値に設定する。Zは、上述のシナリオ2）のようにして決定できる。
【００６７】
4）上述したシナリオのいずれも拡張されることができ、その拡張により、2HKタスク間において非推奨ISRAMおよびSDRAM状態に変化がなかったならば、ODPにおいて保存されるページの数が減少される。ハウスキーピング時に、ISRAM非推奨ページおよびSDRAMアクティブページは存在しない。これは、保存されているよりも少ないODPページを必要とするシステム状態に対して起こる。このメモリは、次にシステムの別の部分、たとえばコーデック作業領域によって用いられることができる。再びSDRAMアクティブページがシステムに存在すると、これらの借りられたページが再要求されることができる。
【００６８】
図3は、図2の線図200における振る舞いの代替案を説明する状態線図300である。図2の線図200における非推奨ISRAMから非推奨SDRAMへの遷移208の代わりに、線図300は、非推奨ISRAMからアクティブSDRAMへの遷移302を説明している。線図300のアプローチは、履歴に関するさらなる情報（さらなる履歴保持）を有しており、散発的なイベントとその結果として起こるページロードに対して図2のアプローチよりもロバストであることが分かる。
【００６９】
図4は、線図200における振る舞いの別の代替案を説明する状態線図400である。特別な状態「非ロード」が考慮されている。状態「非ロード」は、ページが非揮発性非線形アドレス可能なメモリ、たとえばNANDフラッシュ内に存在する状態である。矢印402に示されるように、「非ロード」ページが参照されるとき、それらのページは、非ロードから、アクティブSDRAMへ進む。SDRAMにおけるメモリが一杯である場合、非推奨SDRAMリストから最も古いページが「非ロード」状態遷移404へ動く必要がある。
【図１】
0005555224.tif 000002
【図２】
0005555224.tif 000003
【図３】
0005555224.tif 000004
【図４】
0005555224.tif 000005