(57)【特許請求の範囲】
【請求項１】
種々の復号化プラットフォーム上で実行するためにマルチメディア情報を符号化する方法であって、
ユーザーに並列に提示する複数の情報ストリームを発生し、
段階的に増加する復号化品質レベルを表す複数の復号化品質が選択可能であることを示す単一の制御信号を発生し、前記復号化品質の可能性の各々が、前記情報ストリームの各々に対する復号化品質レベルを指定し、
前記複数の情報ストリームと前記単一の制御信号とを組み合わせて前記マルチメディア情報を形成することを特徴とする方法。
【請求項２】
前記単一の制御信号が、
第１の情報ストリームに対する第１の復号化品質レベル及び第２の情報ストリームに対する第１の復号化品質レベルに対応する第１の復号化品質を選択可能であること、
前記第１の情報ストリームに対する第２の復号化品質レベル及び前記第２の情報ストリームに対する第１の復号化品質レベルに対応する第２の復号化品質を選択可能であること、及び、
前記第１の情報ストリームに対する前記第２の復号化品質レベル及び前記第２の情報ストリームに対する前記第２の復号化品質レベルに対応する第３の復号化品質を選択可能であることを示すことを特徴とする請求項１記載の方法。
【請求項３】
請求項１又は２に記載された方法によって符号化されたマルチメディア情報が記憶される単一の物理的記憶媒体。
【請求項４】
マルチメディア情報を復号化する復号化プラットフォームシステムであって、
前記マルチメディア情報が、
ユーザーに並列に提示する複数の情報ストリームと、
段階的に増加する復号化品質レベルを表す複数の復号化品質が選択可能であることを示し、前記復号化品質の可能性の各々が、前記情報ストリームの各々に対する復号化品質レベルを指定する、単一の制御信号とを具え、
前記復号化プラットフォームシステムが、
前記複数の情報ストリームを復号化する復号化手段と、
前記単一の制御信号に応答して、利用できる復号化リソースに依存して前記情報ストリームが復号化される復号化品質レベルを決定するよう前記復号化手段を制御する制御手段とを具えることを特徴とする復号化プラットフォームシステム。
【発明の詳細な説明】
定義
十分な理解を得るために、次のような用語の定義を与える：
資源(Resource)
中央処理ユニット(CPU)のMIPSや、メガバイト級のメモリサイズや、メガビット／秒級のバスの帯域幅とかのような、プラットフォームの量的又は質的属性；
資源への要求条件(Resource requirement)
そのような資源の必要量；
性能(Performance)
コンピュータ又はCPUの速度；
品質レベル(Quality level)
プラットフォームとは独立に定義されている復号器の機能レベル。
本発明の背景
本発明は、種々の復号化プラットフォーム上で実行するためにマルチメディア情報を符号化する方法に関する。マルチメディア・アプリケーション・プログラム（複数）又はアプリケーション（複数）は種々のプラットフォーム上で実行することができなければならない。そのようなプラットフォームは、関係するアプリケーションがその上を正しく実行するのを保証することができるようにするために、資源についての最小の要求条件を満足させなければならない。種々の場合にプラットフォームは最小より多くの資源を持っている。実際に利用可能なプラットフォームの資源が与えられた場合に、最適の品質レベルが達成されるために、アプリケーションはスケーラブル(scalable)にしてあることが有益である。
本発明の概要
その結果、本発明の目的はとりわけ、簡明なやり方でそのようなスケーラビリティを実現するマルチメディア・アプリケーション情報を記憶する方法を提供することである。本発明の１つの態様によれば、本発明は、上記アプリケーションの実行のスケーラビリティを可能なものとするために、上記方法が、ユーザーに並列に提示する複数の情報ストリームを発生し、段階的に増加する復号化品質レベルを表す複数の復号化品質が選択可能であることを示す単一の制御信号を発生し、前記復号化品質の可能性の各々が、前記情報ストリームの各々に対する復号化品質レベルを指定し、前記複数の情報ストリームと前記単一の制御信号とを組み合わせて前記マルチメディア情報を形成することを特徴とする。ストリング中のそれらの相対的な位置が種々のストリームの間に優先順位を与え、また各単一ストリームに対する種々の品質レベル間にも優先順序を与える。先ず初めに、すべてのストリームを一緒にしたものに対して、プラットフォームがアプリケーションを実行するため、又はしないために、指定された最小プラットフォーム資源が必要である。更に、もし余分の資源が存在するならば、それを相対的な優先順序に基づいて種々のストリームに割り当てることは簡明である。この組織は利用可能な資源に関してプラットフォームが最適の品質レベルをたやすく選択することを許容する。
種々のプラットフォーム上でのマルチメディアの実行可能性だけについて云えば、ヨーロッパ特許出願EP A 731 971号及びこれに対応する米国特許出願08/533,030号で本件出願人により既に考察されており、それを茲に参照文献として引用する。該文献では、マルチメディア・アプリケーション自体がマルチプラットフォーム翻訳器を持ち、各実際のプラットフォームは抽象的なマシーンの一例である。本発明はそのような更に複雑な環境で使えるであろうが、もしプラットフォーム資源が量的性能においてのみ異なるならば既に有用である。
本発明による構成では、プラットフォーム又はプレーヤーは各復号器の各品質レベルに対する資源への要求条件を知っている。それらはプラットフォームの資源への要求条件テーブル内に記憶されている（図５参照）。データストリームとアプリケーション自体とのどちらもがそれを知る必要はないのであって、その理由はデータストリームを形成しアプリケーションを書くに当たってターゲットプラットフォームは一般的に未だ分かっていないからである。データストリームはすべての関連する復号器の入力データを含んでいる。一般的には、本発明の組織を実現するのには、これ以上の情報は必要としないのである。アプリケーションは、現実的又は記号的な項目のストリングとして実現されているモデルを含み、それは関連の復号器レベルの観点でアプリケーションの段階的に上がるモデル又は優先経路を記述する。
或る特定のプラットフォームの資源への要求条件は、プラットフォームを形成するとき各復号器及び関連の品質レベルに対して固定されている。これらはプラットフォーム内に記憶されている。アプリケーションを生成することは、いわゆるディスクビルダー(discbuilder)を使って実時間内ファイル内でデータストリームを結合することを意味する。更にまた、アプリケーションの段階的に上がるモデルが、それについての１つ又はそれ以上の数の呼(calls)を伴ってアプリケーション内に建てられる。一般的にはこのモデルは、データストリームから隔離されている。
少なくとも１つのそのようなストリームが、上記ストリングの少なくとも２つの非隣接項目に関連していることが有利である。このことは、ストリームＡが或る特定の品質レベルを得たとき、ストリームＡの更に改善されることが許されることのできる以前に、先ずストリームＢの品質が改善されるであろうことを意味するのである。
品質レベル項目は記憶されるとき上記アプリケーションに沿ってダイナミックなやり方で上記ストリームに割り当てられるのが有利である。それによりアプリケーションの書き手は、アプリケーションの実行中に種々の復号器間の優先順序が変動するかも知れない、ということを判断できる。或る特定のプラットフォーム上で実行そのものの最中に、このことが実際に使われる品質レベルに影響するかも知れないし、しないかも知れない。
本発明はまた、そのようなアプリケーションの入っている単一の物理的記録担体にも関し、更にまた、そのようなマルチメディア・アプリケーション情報を再生するためのプラットフォームシステムにも関し、該プラットフォームは種々のストリームに対して適切な品質レベルを自動的に選択するであろう。本発明のその他の有益な態様は従属請求項に記載されている。
これらの態様並びにその他の態様及び本発明の利点が、以下に開示される好適実施例及び添付された図面を参照して、更に詳細に説明される。
一般的な考察
マルチメディア、及び特にIMDFアプリケーションは、その最も完全な形態において、次の２つの処理形式を有するであろう：
●ストリーム処理(SP)−これは、ビデオ(MPEG)，２次元又は３次元のグラフィック，オーディオ(MPEG，MIDI，PCM，ADPCM)のようなオーディオ・ビジュアル情報ストリームのストリーム処理であって、これらのストリームはユーザーである人間の期待する正規の再生速度における時間的に一致したやり方で処理されなければならない。
●非ストリーム処理(NSP)−これは、上述のような時間的に一致したオーディオ・ビジュアル情報ストリームには直接関連を持たない。しかし用語の簡単のために、物理的な記録担体上に在る上述のような時間的に一致したオーディオ・ビジュアル情報ストリームに関連する情報も同様にストリームと呼ばれる。この処理形式は更に次のように再分割することができる：
●(a)実時間の強制されたNSP−これは例えば航空機運行シミュレータのようなシミュレーション計算の類である。
●(b)非実時間の強制されたNSP−これは定常情報(stationary information)を提供するためのデータベース又はエンサイクロペディアの探索の類である。
その低端でも各アプリケーションは最小の資源を持つプラットフォームを必要とし、それらの資源は適用すべき標準中に定義されていよう。そのような最小のプラットフォーム上では、或る限定された数の情報ストリーム及び計算のみが並列に処理されることができる。更に強力なプラットフォームでは原理的に、最小のものに比べれば高品質レベルが許容されよう。そのような資源の例としては、CPU処理サイクルの循環周波数、メモリサイズ、バス転送容量、I/O機能、等がある。或る種の環境では原始命令(raw instruction)処理速度を示すMIPS数は、MOPSへの再計算の必要、すなわち演算速度を当該ストリームに相応しいものとする必要があろう。同様に、全アプリケーション又は一部アプリケーションの搭載用のような演算オーバヘッドも考慮する必要があろう。サーバー又はその他のマルチ処理環境の場合には、利用可能な資源は同時に走る種々のアプリケーション間で共同使用しなければならないこともあろう。
ストリーム処理(SP)に対しては、資源管理は次の３ステップでなされる：
−すべての利用可能な復号器に対して目標品質レベルを定義する；
−或る特定の復号器に対して実際の品質レベルを選定する；
−選定された品質レベルで復号器を制御する。
但し、茲で復号器とは事実上は、種々の復号器間で共同使用されることもされないこともあるハードウェア上を並列に走る復号器プログラムのことである。
最初のアプローチでは、非ストリーム処理(NSP)はアプリケーションによって完全に定められ、スケーラブルではないと考えられる、それはプラットフォームにとってNSPが何をしようとしているかを予見できないからである。このことはNSPに対しては資源への要求条件がプラットフォーム内で前以て分かっていなければならないことを意味する。割り当てられた資源の量は、もし実時間が強制されるならば、常に最終期限に間に合っているために十分なものでなければならない。もし実時間が強制されていないならば、すべての長期に亙る未完成業務の積み上げを避けるために十分なものでなければならない。このことは一般的にNSPに対する資源が一括して割り当てられなければならないことを意味する。次いで任意の残りの資源がSPに対して割り当てられることができる。
好適な実施例の詳細な説明
図１は、本発明によるアプリケーションを記憶するためのフローチャートを示す。このフローチャートに従う演算はアプリケーションの一般的書き込みの直ぐ後に実行できる。ステップ20ではアプリケーションの未処理の情報が特定の時間間隔又は情景(scene)に相応しいように受信される。一般的に情景のサイズはアプリケーションの開発者により定められている。そうするときには、情景は通常は音楽又は動画の間隔、静画、グラフィックエレメント、等々のようなものから積み上げられたものである。情報の中ではデータストリームは通常はつなぎ合わせてインターリーブされ多重化されたデータファイルとなっている。十分な処理能力が、該アプリケーションをその最高品質レベルで実行するために利用可能である。該アプリケーションの実行の過程では、処理はしばしば時間的に線形(linear)であり、種々のストリームが動画のやり方におけるように相互同期をとってユーザーに提供される。しかしこの行動は時間的に同一(uniform)である必要はないので、ある時点で画像は凍結し、付随する音楽は進行することもある。相互に影響し合う状況では、相対的な行動は更に不均一(non-umfom)なこともあろう。ステップ22ではアプリケーションの最初の未処理の項目が、その品質レベル項目のストリングをそれに対して定める、という見地でアクセスされる。
ステップ28では該アプリケーション（の一部）を実行するための最小品質レベルが査定(assess)される。この判定はアプリケーションの書き手によってなされる。次に、茲で情景の見出し(heading)が与えられて、品質レベル項目のストリングの最初の項目としてすべての復号器の最小限必要な品質レベルが示される。この最初の項目は１個より多くの復号器に関連するから複合項目となるであろう。自動的なスケーラビリティが達成できるようにするために、ストリングの以後の項目は、進むに従って１段ずつ段階的に品質が向上するように配列されていなければならない。ステップ28の演算は、孤立した１つの情景で実行することもでき、或いは前後の情景との関連で実行することもできる。次にステップ30では、ストリームのうちの異なる複数の品質を許容するところの正確に唯１つの情景がその次に高い品質レベルで取り上げられて、情景が再度実行される。向上可能な品質レベルを持つストリームの各々に対してこれが繰り返され、そのことがループ線31で示されている。単一品質向上のすべての可能性について情景が実行され終わると、その中での最良の再生(performance)がステップ32で選定される。一般的にこれは設計者個人による主観的行動である。品質を更に向上させることが可能である限り（ステップ34）、システムは次にはステップ30に戻る。もしすべてのストリームがそれぞれの最高品質レベルで実行され終わったら、該アプリケーション情景が搭載される（ステップ36）。本発明の最終的な結果は、この種類の媒体(media)の標準的製造方法で造られた単一の担体(carrier)である。ステップ38で処理システムは終了する。簡単のために単一の情景の搭載のみが考察された。しかしその次の情景に対して図１のフローチャートを実行すると決定してもよいのである。
図２は、そのように形成された単一の記録担体を表している。この担体は縦の別々の列で示された８個のストリームを含んでいる。Compact-Disc Interactiveのような物理的な記憶のために、一般的には直列化した演算が実行される；これは実時間多重化ファイルを生成することができる。各ストリームにはブロック32があり、それは識別子(identifier)，長さ，及びその他各種参考事項を含む。このストリームの並列特性は、それらストリームがインターリーブされたやり方で再生のためにアクセスできる、という事実に在る。簡単のために物理的記憶の実際の組織はアドレスされていない。模範的解答が本件と同一出願人によるヨーロッパ特許出願EP Patent Application 95202623.5(PCT/IB96/00962に相当)に開示されており、茲にそれを参照文献とする。そのようなインターリービングでは、プレーヤーは、実際にアクセスされているところのストリームのトラックを維持する。上述のように、段階的に品質が向上することを示す品質レベル項目のストリングはこの図中のＸとして情景の見出しの中に記憶されている。
図３は記録担体を再生するためのプラットフォームシステムを示す。ディスクの形をした記録体40は、ライン44上に在る位置決め信号の制御の下に読み取り装置42によりアクセスされる。プレーヤー本体60は、ユーザーの命令を入力するユーザーインターフェース50と、上述の品質レベル項目のストリングを検出する検出器ブロック46とを持つ。この検出器ブロックはまた、当該プラットフォームに適応する種々の復号器の種々の品質レベルに対して必要な資源についても知っている。従ってそれは実際に達成可能な品質のレベルを、或る要求条件には適合するが他の条件はプラットフォームに過重な負担となるように、選択できる。これについては以後更に詳しく論ずる。中央処理デバイス48が上記選定に従って当該ストリームを処理する。そのような処理は更にインターフェース50上のユーザーの命令の制御下にもあるであろう。原理的にはユーザーはプラットフォームにより選定された品質レベルを覆すこともあろう。例えばユーザーがビデオよりオーディオ上演を優先して選ぶことがあり、そのためにオーディオ処理に対しアプリケーションの設計者が割り当てた相対的優先度よりも多くの資源を優先して割り当てることがあろう。中央処理デバイス48は種々のユーザー情報信号を種々のユーザー出力装置52，54，56，58に出力する。それらのユーザー出力装置にはオーディオチャネル、ビデオチャネル、及びデータチャネルが含まれる。これらのうちの様々のものが並べて配列されることもある、例えば同じスクリーンにビデオとアニメーションの表示が並列に置かれる、等。またこの処理は線44上で読み取り装置42のために位置決めもさせる。
以後、資源管理について更に詳細に論ずる。中央処理デバイス４８は種々の装置、例えばメモリ，バス，及びI/O機能等を含む。それらの情報は検出器ブロック46に知らされ、該検出器ブロック46は更に種々の品質レベルに対して必要な資源の量につても知っている。このことが、実際のアプリケーションに適合するように、現実に存在する資源を用いて実現できる最適の品質レベルを、選択することを検出器ブロック46に許容する。もし適切な再生レベルが選択されたならば、必要な資源が割り当てられて、アプリケーションが実行されるようになる。しかしもし、例えば帯域幅，遅延，誤り率，等について規定に対し資源が不十分であるならば、プレーヤーはユーザーに通知し、またアプリケーションの実行を一時停止する。続いて起こる情景に遭遇すると資源割り当ては再始動しなければならない。もし資源への要求条件がアプリケーションと共にダイナミックに変動するならば、アプリケーションが必要な最小の全体的品質レベルをシグナルして、アプリケーションの全体的実行可能性がプラットフォームによって決定できる。その結果として瞬間的なサービスの品質は時間的に不均一であろう。
この関連において、図４はサービス品質の管理図表を示す図である。アプリケーション70が或る特定のサービス品質を管理装置72に要請し、該管理装置72は契約提案を返送する。もしそれが受け入れられれば、管理装置72はパラメタを処理装置に送る。処理装置は、走行時間資源割り当て(74)，計数処理及び規制(76)を行い、ハードウェア・エレメント78−84を制御する。そのように割り当てられた資源はそのサービスをアプリケーションに提供する。
図５は、プラットフォーム内に存在する典型的な資源への要求条件のテーブルを示し、様々なストリームがある故に、その結果として関連の資源への要求条件は大幅に標準化されている。その上にアプリケーション自身はプラットフォーム内に存在する種々の資源について知ろうとはしない。
MPEGビデオについては、次の客観的品質レベルが復号器に対し適用されるであろう：
●１．黒白／半フレームレート；
●２．黒白／全フレームレート；
●３．全カラー／半フレームレート；
●４．全カラー／全フレームレート．
MPEGオーディオについては、次の客観的品質レベルが復号器に対し適用されるであろう：
●１．モノ；
●２．ステレオ；
●３．ドルビーサラウンド；
●４．５＋１サラウンド（５個の標準チャネル及び１個の特殊効果用）．
３次元グラフィックについては、次の客観的品質レベルが復号器に対し適用されるであろう：
●１．フレーム当たり5000個の三角形又は多角形；
●２−４．それぞれフレーム当たり10k個,15k個,20k個の三角形．
図５では縦の列が、プラットフォーム内の既知の装置からのこれら種々の品質レベルにより要求される資源を記載する。記載された要求条件は、平均値、平均値プラス20％程度の安全マージン、又は最悪の場合に相当しているであろう。茲で資源１ないし４は、それぞれ第１プロセッサ、第２プロセッサ、メモリ、及びI/O装置であろう。各資源は最高再生値により特徴付けられるところの抽象的実在である。
利用可能な資源が或る特定のアプリケーションを実行するためにかろうじて最小限の必要を超えている場合には、プラットフォームはどの復号器がどんな品質レベルで再生しなければならないかについて決定しなければならない。この決定のために、特定のストリームのアプリケーションに対する相対的重要性、及びその実行に対して必要な資源を知る必要があり；第１の知識は、アプリケーション間で大幅に変動するが故にアプリケーションによってもたらされ;第２の知識は、プラットフォーム自身の内に存在する。簡明なやり方は段階的に挙げて行くやり方で実行可能性レベルを記述することである。用語「復号器」は実際の復号用ソフトウェアパッケージの意味で使われる。例えば：
0003918951.tif 000002
このテーブルに示すように、アプリケーションの完全機能性のために、３個の復号器はすべて品質レベル３で動作しなければならない。２つの典型的な利用可能プラットフォームの各々に対して、実際の再生は比較的低いものであり当該復号器の各々に対し破線上で達成された最大レベルによって与えられる。例えば、相対的に簡単なプレーヤーは、MIDI，レベル２におけるビデオ，及びレベル３におけるオーディオを持たない。相対的に高い再生をするプレーヤーは、レベル１におけるMIDI，及びレベル３におけるオーディオとビデオの双方を持つ。明らかに、MIDIのアプリケーションへの貢献は相対的に僅かな重要性しか持たないと判定される。もう１つのアプリケーションでは、ストリームの相対的重要性は異なることがあろう。例えば、MIDIは品質への妥当性は近似的にオーディオと同じレベルにあると評価することができよう。別のプレーヤーはいわゆる「サウンドブラスター(sound blasters)」カードをボード上に持つことがあり、これが中央プロセッサ機能の外でMIDI復号を行わせる。
この文脈で、図６は或る特定のアプリケーションに係わる２次元優先経路図表(two-dimensional preference path diagram)を示し、この図表は当該アプリケーションの各別個の情報ストリームに対し１つの次元を持つ。簡単のためにこの実例では２ストリームのアプリケーションが取り上げられている。優先経路は実線で表され、それに沿った各×印は感知可能な資源のセットを表す。次々の×印は該アプリケーションを再生する次々の品質レベルを示す。優先経路は０資源を表す左上端の隅から開始する。実線に沿ったその次の×印は、以前に考察した３次元アプリケーションに対し与えられたのと同じやり方でその次の列に対応する。茲で或る特定の（図中◯で囲った）×印は、当該プラットフォーム上のアプリケーションを実行するための最小の資源への要求条件を示す。プラットフォームは×印の線に沿って最も遠い×印によって表されるような最良の品質レベルを達成しようと試みる。
更に、点線はプラットフォームの全資源を示す。この線を超えない最後の×印がこの特定のプラットフォームの利用可能な最高品質を示す。もしこのアプリケーションが並列に多数のストリームを持つならば、該マトリクスは同じく多数の次元を持ち、更に静的(static)であるに及ばない。或る状況ではプラットフォームはこの図表の線に厳密に沿い続けるには及ばない。例えば、もしMPEG-3オーディオがプラットフォームに過重の負担を掛けようとするならば、該プラットフォームによりMPEG-3ビデオが（後に着実に改善される品質レベルのシーケンス中で）巧く実行できるか否かを、該プラットフォームはなお試みることができよう。
もし巧く実行できるのであれば、該プラットフォームは実行に含まれよう。アプリケーションにとっては相対的に重要なシーケンスを明記することは、もしストリームの数が多く相対的な重要性の割当てがダイナミックであるならば、労の多い仕事である。言語の数が増加し、オーディオは標準又はカラオケであろうし、ビデオも多くの変形が並列に提示されようから、ストリームの数は現実に大きいものであることに留意しなければならない。これを簡単にするために、相対的な重要性が各復号器に割り当てられ、これらは初等的モデル上にマップされる。それは次のようになされる：
●復号器の重要性はその最小限許容される品質レベルであり；これは段階的に上げる(incremental)記述中の最初の出現に対応するであろう。
●各復号器の品質はそれがオープンになる順序で上がって行く。
●各復号器の品質はそれが最高の品質に達するまで上がって行く。
例えば、各復号器に対し最高の品質が３であり、
復号器１＝オープン復号器（MPEG2,ビデオ,2）
復号器２＝オープン復号器（MPEG2,ビデオ,2）
復号器３＝オープン復号器（MIDI-16,1）
として与えられている重要性の図式(importance scheme)は、次のような段階的に上げる記述を与える：
品質レベル２でMPEG2ビデオ復号器１を創造する；
品質レベル２でMPEG2オーディオ復号器１を創造する；
品質レベル１でMIDI-16復号器１を創造する；
MPEG2ビデオ復号器１を品質レベル３に上げる；
MPEG2オーディオ復号器１を品質レベル３に上げる；
MIDI-16復号器１を品質レベル２に上げる；
MIDI-16復号器１を品質レベル３に上げる．
各復号器の品質レベルを選定するのに、我々は段階的に上げるモデルの始まりで開始する。復号器は或る１つの品質レベルで創造され、各復号器品質レベルは段階的に上げるモデル中に記述された優先経路に従って１つ上げられる。創造される各復号器に対し、及び１つ上げられる各品質レベルに対して、資源への要求条件は、資源への要求条件テーブル中でルックアップされ、足し算されて、アプリケーションの全資源への要求条件に到達する。もし資源のうちのどれか１つに対する要求条件がその最大値（すなわち100％）を超えるならば、それ以上の復号器品質はもはや果たされない。これが実際のアプリケーション又は情景に対するこのプラットフォームの優先経路の終端である。
【図面の簡単な説明】
図１が、本発明によるアプリケーションを記憶するためのフローチャートを示す図であり；
図２が、そのように形成された単一の記録担体を示す図であり；
図３が、記録を再生するためのプラットフォームシステムを示す図であり；
図４が、サービスの品質管理図表を示す図であり；
図５が、プラットフォームの資源への要求条件テーブルを示す図であり；
図６が、優先経路の図式を示す図である。
【図１】
0003918951.tif 000003
【図２】
0003918951.tif 000004
【図３】
0003918951.tif 000005
【図４】
0003918951.tif 000006
【図６】
0003918951.tif 000007
【図５】
0003918951.tif 000008