(57)【要約】  コンテンツ配信の集中化したスケジューリングを実行するための方法が開示されている。これには、受け入れ承認制御の実行、コンテンツの供給源であるサーバの設置、コンテンツ配信スケジュールの決定、コンテンツ配信ネットワーク（ＣＤＮ:  content  delivery  network）の上のコンテンツ配信スケジュールの順番の入れ替えが含まれる。また、受け入れ承認制御を実行するための方法が開示されている。これには、部分的に供給され約束されたリクエストと新しく到着したコンテンツのリクエストに基づいて、リクエスト待ち行列の順番を入れ替える方法、新しく到着したコンテンツのリクエストがリクエスト待ち行列に入るのを許可されるかどうか決定する方法が含まれる。
2009531956.tif 000002
【特許請求の範囲】
【請求項１】
リクエスト待ち行列へ受け入れ承認することを制御するための方法であって、
部分的に供給され約束されたコンテンツ・リクエスト、および新しく到着したコンテンツ・リクエストに基づいて、前記リクエスト待ち行列の順番を入れ替えるステップ；および
前記新しく到着したコンテンツ・リクエストが前記リクエスト待ち行列に受け入れ承認されるかどうかを決定するステップ；
を有する方法。
【請求項２】
請求項１に記載の方法であって、  前記決定するステップが、前記部分的に供給され約束されたコンテンツ・リクエスト、および前記新しく到着したコンテンツ・リクエストのサービスをエミュレートするステップを更に有する方法。
【請求項３】
前記新しく到着したコンテンツ・リクエストは、順番を入れ替えた前記リクエスト待ち行列から取り出される次の順番のリクエストである請求項２に記載の方法。
【請求項４】
コンテンツ配信ネットワークの上でのコンテンツ配信について集中してスケジューリングを実行するための方法であって：
受け入れ承認制御を実行するステップ；
コンテンツの配信源であるサーバを探すステップ；
コンテンツ配信スケジュールを決定するステップ；および
前記コンテンツ配信スケジュールの順番を入れ替えるステップ；
を有する方法。
【請求項５】
順番を入れ替えた前記コンテンツ配信スケジュールを実行するステップを更に有する請求項４に記載の方法。
【請求項６】
前記順番を入れ替えるステップが前記コンテンツ配信スケジュールを最適化するステップを更に有する請求項４に記載の方法。
【請求項７】
請求項６に記載の方法であって：
配信がスケジュールされた各々のコンテンツのユニットのための標準化速度を算出するステップ；および
算出された前記標準化速度に基づいて、前記コンテンツ配信スケジュールの順番を入れ替えるステップ；
を更に有する方法。
【請求項８】
前記標準化速度の各々は、前記コンテンツのユニットの大きさを、コンテンツ配信予定時刻から現在の時刻を差し引いたもので割った値である請求項７に記載の方法。
【請求項９】
前記決定するステップが、前記コンテンツ配信ネットワークのための逐次的な経路選択を更に有する請求項４に記載の方法。
【請求項１０】
逐次的な経路選択は、コンテンツ・サーバから前記コンテンツをリクエストしているクライアントへの経路の選択であり、標準化された順序でもって逐次的に、コンテンツに対しての各々のリクエストのためのスケジュール時刻を最小化するようになされる、請求項９に記載の方法。
【請求項１１】
リクエスト待行列の中の各々のコンテンツ・リクエストに対して、前記コンテンツ配信スケジュールは、コンテンツ・サーバから前記コンテンツをリクエストしているクライアントまでの経路の最小限のホップの数を逐次的に判定することにより決定される、請求項４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遅延したダウンロードのサービスを提供するためのコンテンツ配信ネットワーク（ＣＤＮ:  content  delivery  network）に関する。より詳細には、本発明は、コンテンツ配信ネットワークのための集中化したスケジューラに関する。
【背景技術】
【０００２】
従来技術としては、単一のコンテンツ・サーバのためのスケジューリング・アルゴリズムおよび遅延したダウンロードのサービスのための単一のキャッシュ・サーバがある。コンテンツ配信ネットワーク（ＣＤＮ）技術は、通常、リクエストされたコンテンツをあとで（すなわち、リクエスト時刻よりも遅れて）提供することができるサービスのために用いられる。デジタル映画レンタル・サービスは、この典型的なサービスである。
【０００３】
ＣＤＮ技術は、２つの主要な構成要素を含む：（１）コンテンツをエッジ・サーバに配信するために資源を割り当て、そして（２）エッジ・サーバからクライアントまでコンテンツを配信するために、リクエスト（リクエストの経路決定）をリダイレクトする。従来のＣＤＮネットワークにおいては、コンテンツがエッジ・サーバで利用できる場合だけ、リクエストの経路決定がエッジ・サーバに対してなされる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は、遅延したダウンロードのサービスのＣＤＮシステムのスケジューリング問題を明確にし、リクエストの経路決定課題を  （１）標準化した速度を基にした順序づけ、および（２）逐次的な経路選択を使用して解決する動的な方法を提案する。
【課題を解決するための手段】
【０００５】
本発明は、キャッシュ／エッジ・サーバを有するコンテンツ配信ネットワークのための集中化したスケジューラであって、集中化したコントローラで（１）配信経路を選択することによって、通信の負荷をバランスさせること、および（２）配信スケジュールを選ぶことによって通信の負荷を平坦化させることを実現するものである。
【０００６】
本発明のＣＤＮにおいて、エッジ・サーバからコンテンツがまだ入手できない場合でも、エッジ・サーバまでのリクエストの経路決定が行われる。リクエストされたコンテンツをクライアントに配信するサーバの経路を選ぶ能力は、本発明におけるＣＤＮのためのリクエスト経路決定機能が持っている。すなわち、本発明のＣＤＮの集中化したスケジューラが、ＣＤＮ内の経路を特定し、（本発明の集中化したスケジューラを使用し、リクエスト・スケジュールによって）リクエストされたコンテンツが配信される。
【０００７】
コンテンツ配信の集中化したスケジューリングを実行する方法が記載されている。この方法には、受け入れ承認を制御すること、コンテンツの供給源であるサーバを特定すること、コンテンツ配信スケジュールを決定すること、コンテンツ配信スケジュールの順番を入れ替えることが含まれる。同様に受け入れ承認を制御するための方法が記載されている。この方法は、部分的に供給され約束されたコンテンツ・リクエストと新しく到着したコンテンツ・リクエストに基づいてリクエスト待ち行列の順番を入れ替えること、新しく到着したコンテンツ・リクエストがリクエスト待ち行列に入るのを承認するかどうか決定することが含まれる。
【発明を実施するための最良の形態】
【０００８】
［好ましい実施例の詳細な説明］
本発明の方法における、リクエストを最適化し、配信スケジュールを決めることは、集中化した手法に基づいている。図１は、本発明によって解決される課題を一般化して例示しているコンテンツ配信ネットワークのブロック線図である。本発明のＣＤＮは、遅延してダウンロードするサービスを具現化する。
【０００９】
図１は、インターネット上のＣＤＮを示している。ＣＤＮは、コンテンツ・サーバ、複数のクライアント／ユーザｕｉ、そして、ユーザ／クライアントがコンテンツを受け取る複数のエッジ・サーバを有している。コンテンツ・サーバは、将来時刻にエッジ・サーバを経てクライアントにコンテンツを配信する経路指示（リクエスト経路決定Ｒ（ｔ０））のためのリクエストを受信する。エッジ・サーバは、利用できるリクエストされたコンテンツをまだ有しなくてもよい。（コンテンツ・サーバ内に存在する）集中化したスケジューラは、リクエストされたコンテンツが、リクエストされた配信時刻以前に、クライアントに利用できるように、スケジューリング集合Ｓ（ｔ０）を見つけ／決定しなければならない。集中化したスケジューラは、コンテンツをリクエストする他の待機中のリクエスト、リンクの状況Ｂ（（ｎｉ，ｎｊ），ｔ）、そして、リンクの伝送容量ｂ（（ｎｉ，ｎｊ）），ｔ）およびキャッシング状況Ｃｉ（ｔ）およびキャッシング容量ｃｉ（ｔ）を考慮しなければならない。
【００１０】
本発明の集中化したスケジューリングを実行する際に使用するパラメータは、以下の通りである：
Ｎ＝｛ｎｊ，  Ｊ＝０，…，Ｊ｝はネットワーク・ノード集合を表し、コンテンツ・サーバ（Ｊ＝０）、Ｉ個のエッジ・サーバ（Ｊ＝１，...，Ｉ）、Ｕ個のクライアント（ｊ＝Ｉ＋１，...，Ｉ＋Ｕ＝Ｊ）を含む。
【００１１】
それぞれのノードには、以下のキャッシュが存在する。
【００１２】
ｃｉ（ｔ）  キャッシュの容量を示す（なお、キャッシュのサイズが固定であればｃｉとなる）
Ｃｉ（ｔ）  時刻ｔにおけるキャッシュの状況（キャッシュの内容のリスト）を表す。
【００１３】
【数１】
2009531956.tif 000003
数１は、ネットワーク・リンク集合を表す。（ｎｉ，ｎｊ）は、ノードｎｉからｎｊへのリンクを表す。リンクでの伝送容量は時刻によって変化する。
【００１４】
ｂ（（ｎｊ，ｎｋ）），ｔ）  は、リンクの伝送容量を表す（なお、リンク伝送容量が一定であればｂ（ｎｉ，ｎｊ）となる）  。
【００１５】
Ｂ（（ｎｊ，ｎｋ），ｔ）  は時刻ｔにおける（ｎｉ，ｎｊ）のリンクの状況（コンテンツの転送リスト）を表す。
【００１６】
ＣＤＮのネットワークは、［Ｎ，｛ｃｊ（ｔ）｝，｛ｂ（（ｎｊ，ｎk），ｔ）｝］で表され、キャッシュとリンクを含むノードより成る集合である。
【００１７】
【数２】
2009531956.tif 000004
数２は、リクエスト集合を表す。すなわち、時刻ｔ＝ｔ０における、クライアントがコンテンツ・サーバになす全てのリクエストを表す。
【００１８】
ｒｑ＝（ｍｑ，ｄｑ，ｕｑ）  はリクエストを表し、コンテンツＩＤ、予定時刻およびリクエストしたクライアントＩＤを基に表される。
【００１９】
ｍｑ  はコンテンツＩＤであり、|ｍｑ|は、コンテンツの大きさを示し、||ｍｑ||は、リアルタイムストリーミング速度を表す。
【００２０】
ｄｑ  は、リクエストｒｑに対する予定時刻を表す。
【００２１】
ｕｑ  は、リクエストを行ったクライアントのＩＤを表し、このＩＤから地理的位置を特定することができる。
【００２２】
【数３】
2009531956.tif 000005
数３は、リクエスト集合Ｒ（ｔ０）に対するスケジューリング集合を表す。
【００２３】
ｓｑ（ｎｉ，ｎｊ）  は、リクエストｒｑに対するスケジュール（開始）時刻であり、リンク（ｎｉ，ｎｊ）を経由して、ストリーミング速度||ｍｑ||で伝送されることを表す。
【００２４】
本発明によって解決される最適化の問題は、リクエスト集合を与えて、スケジューリングの集合を決定することである。新規なリクエストが到着すると、そのリクエストされたコンテンツを最も早く配信できるように、スケジューリング集合を決定しなければならない。解決すべき問題は、以下のように定義できる：
ネットワークが、時刻ｔ＝ｔ０において、［Ｎ，｛ｃｊ（ｔ）｝，｛ｂ（（ｎｊ，ｎk），ｔ）｝］であり、ｔ＝ｔ０の時刻での、リクエスト集合がＲ（ｔ０）、キャッシュの初期状態が｛Cｉ（ｔ０），ｉ＝１...Ｉ｝およびリングが、
【数４】
2009531956.tif 000006
のとき、
【数５】
2009531956.tif 000007
全てのリンク上での全てのリクエストのうち一番遅いスケジュール時刻が、最小になるように、数５の集合を求めること、すなわち数６を求める：
【数６】
2009531956.tif 000008
ただし、以下の制約を満足することを条件とする：
（１）予定時刻の制約（数７）
【数７】
2009531956.tif 000009
（２）ｔ＝ｔ０またはｔ＞ｔ０のどの時刻おいてもキャッシュに対する制約（数８）
【数８】
2009531956.tif 000010
数８において、|ｍｑ|は、リクエストｒｑのためのコンテンツの大きさを表す。そして、
（３）ｔ＝ｔ０またはｔ＞ｔ０におけるリンク伝送容量の制約（数９）
【数９】
2009531956.tif 000011
数９において、ｇ［ｘ］は、下記のようなステップ関数である。
【００２５】
ｘ＝０またはｘ＞０のときｇ［ｘ］＝１、それ以外のときはｇ［ｘ］＝０
そして、eｑ（ｎｊ，ｎk）＝ｓｑ（ｎｊ，ｎk）＋|ｍｑ|／||ｍｑ||は、リクエストｒｑのコンテンツのダウンロード終了時刻である。コンテンツは、あるストリーミング速度で連続的な時間に配信されると仮定する。
【００２６】
解決すべき課題は、全てのリクエストに対してなるべく早く配信することである、すなわち、与えられたリクエスト集合に対して、スケジュール時刻をなるべく早くすることである。しかしながら、与えられた制約を満たすスケジュールは、多く存在する。すなわち、異なる経路を利用することおよび異なる順序で配信することが含まれる。経路の選択の複雑度は、数１０で示される。
【００２７】
【数１０】
2009531956.tif 000012
数１０で、ｐは、コンテンツ・サーバとクライアントの間の経路の数の平均値である。配信／順序選択の複雑度は、最大で、極端なケースの場合、数１１で示される。
【００２８】
【数１１】
2009531956.tif 000013
本発明の集中化したスケジューラは、以下の定義／規則を使用する動的な方法を含む：
１）リクエストの順序付け：
リクエストは、予め定められた順序で待ち行列に入れられる。例えば、リクエストは、到来順で順序づけされる。すなわち、早い者勝ち（ＦＩＦＯ）の順序、あるいは予定時刻（ＤＴ:  Due-time）順序がある。好ましい実施例では標準化速度（ＮＲ）に基づく順序である。これを以下に説明する：
時刻ｔにおけるリクエストｒｑのための標準化速度は、予定時刻ｄｑの前に、リクエストｒｑのためのコンテンツを配信することを必要とする速度を表し、|ｍｑ|／（ｄｑ-ｔ）として定義される。例えば、リクエストがコンテンツ４ＧＢのサイズを有し、予定時刻が午後８時であり、現在の時刻は午後４時であるとすると、標準化速度は、４ＧＢ／４時間＝２.２Ｍｂｐｓである。これは、午後４時から始めて、コンテンツを午後８時前に配信し終えるための速度である。もし、ＣＤＮが、リクエスト集合Ｒ（ｔ０）をｔ＝ｔ０における標準化速度の順序で配信したとした場合、予定時刻より遅延する確率は最小化できる。順序を選択する複雑度は、数１２となり、
【数１２】
2009531956.tif 000014
劇的に減少する。
【００２９】
２）逐次的な経路選択：
リクエストが順序の待ち行列に入れられたにもかかわらず、リクエストのための経路選択が総合的に決定されなければならないとしたら、複雑度はまだ非常に高く、数１３となる。
【００３０】
【数１３】
2009531956.tif 000015
解決すべき課題は、非常に単純化することができる。すなわち、他の目標を設定して、与えられた待ち行列順に従って、一つ一つのリクエスト（すなわち、Ｒ（ｔ０）中のｒｑ）の最小限のスケジュール時間を探すことである。
【００３１】
すなわち、本発明の集中化したスケジューラは、数１４を求めることである。
【００３２】
【数１４】
2009531956.tif 000016
最適化されたスケジュールの集合は、数１５であり、
【数１５】
2009531956.tif 000017
この数１５は、既に求めたスケジュールベクトル｛sｘ（ｎｊ，ｎk）；ｘ＝０，...，ｑ-１｝を基にして、それぞれのリクエストｒｑに対して決定される。各々のリクエストが前の状況に基づいてそれ自身のスケジュールの最適値を求めるので、リクエストのためのスケジュールの決定は、各々のリクエストに対して行われ、これは、将来のリクエストから独立してなされる。複雑度は、下記数１６となる。
【００３３】
【数１６】
2009531956.tif 000018
順次リクエストを処理して、各々のリクエストのスケジュールは、なるべく早く作られる。標準化された順序で順次リクエストを処理して、スケジュールは、なるべく早く作られる。この方法は、本願明細書において、標準化速度で最も早く配信する方法（ＮＲＥＤ:  Normalized  rate  earliest  delivery）と呼ぶ。この方法は、以下の通りのステップで表現できる：
１.  リクエスト集合Ｒ（ｔ０）を標準化速度の順序で待ち行列としてリストアップする。これを新たなＲ（ｔ０）とする。キャッシュおよびリンクの初期条件をそれぞれ、下記数１７とする。
【００３４】
【数１７】
2009531956.tif 000019
２．数１８を実行する。
【００３５】
【数１８】
2009531956.tif 000020
ここで下記数１９は、時刻ｔにおいて受け付けたリクエスト（request）の合計である。
【００３６】
【数１９】
2009531956.tif 000021
３．For  request  ｒｑ＝（ｍｑ，ｄｑ，ｕｑ），コンテンツｍｑをｕｑに配信する、最小のスケジュール時刻（数１４）が得られる最も短い経路を以下の方法で求める：
４．サーバＨｑの集合から開始する（各サーバｎｉはコンテンツｍｑを持ち、数２０および数２１を満たす）。
【００３７】
【数２０】
2009531956.tif 000022
【００３８】
【数２１】
2009531956.tif 000023
なお、数２１において、ｔｉ，ｑは、ｒｑの処理前に、サーバｎｉのキャッシュがアップデートされた最新の時刻を意味する。
【００３９】
５．マルチ供給源最短経路アルゴリズム（例えばダイクストラ（Dijkstra）のアルゴリズム）を使用することにより、サーバｎｉからｕｑへの最も短い経路を見つける。なお、ｎｉは数２２を満たす。
【００４０】
【数２２】
2009531956.tif 000024
６.  数２３のスケジュールを見つける
【数２３】
2009531956.tif 000025
そして、最短の経路上のサーバにおける、数２４で表すキャッシュを更新する。
【００４１】
【数２４】
2009531956.tif 000026
その際、数２５で表すリンクも更新する。
【００４２】
【数２５】
2009531956.tif 000027
この場合、リンク伝送容量およびキャッシュ容量の条件を考慮する。
【００４３】
７．もし、数２６となった場合、
【数２６】
2009531956.tif 000028
この方法では、Ｒ（ｔ０）に対して、スケジューリングの集合を求めることができないということになる。リクエスト集合Ｒ（ｔ０）に対する最新のコンテンツリクエストの到来を拒否する結果となり、この方法は、失敗に終わる。
【００４４】
８．次のリクエストに対して継続するため、ステップ２に戻る。
【００４５】
最短経路の算法のための基準は、例えば、以下の通りに定めることができる：
１）  最短のスケジュール時刻：
これは、リクエストのために最も早いスケジュール時刻を与える経路である。この基準は、数１４（式（２））に対応する。
２）最小限のホップ（接続）の数：
これは、ネットワークに最も少ない負荷を与える経路である。この基準は個々のリクエストに対し、最適のスケジュール時刻を与えない。しかし、全体の結果は、良好にならなければならない。この基準は、数６（式（１））に、より良く適合する。
【００４６】
図２は、本発明の標準化速度で最も早く配信する（ＮＲＥＤ）方法を表している。ステップ２０５において、順番でリクエスト待ち行列が与えられる。この標準化された順序は、初期条件を構成する。ステップ２１０において、一つのリクエストが、リクエスト待ち行列から取り出される。ステップ２１５で、要請されたコンテンツを有するサーバ集合Ｈが探し出される。このサーバ集合は、あるサーバｎｉを含む。このサーバｎｉは、リクエストされたコンテンツを以前提供したことがあり、かつ、そのコンテンツはまだ他のコンテンツと置き換えられていないサーバである。ステップ２２０で、サーバ集合Ｈのいずれかのサーバｎｉから、（エッジ・サーバを経て）ユーザ／クライアントｕｉまで、最も短い経路が決定される。最も短い経路選択のためのコストは、ホップ（接続）の数または最も早いスケジュール時刻である。ステップ２２５で、スケジュール、最も短い経路上の全てのリンクおよびサーバに関する、キャッシュの状況およびキャッシュ容量が算出される。スケジュールは、同様にリンク速度容量およびリンク状況を満たさなければならない。
【００４７】
与えられたＣＤＮのトポロジ、部分的に供給されたリクエストの集合、および新規なコンテンツのリクエストのため、部分的に供給され約束されたリクエストおよび新たに到来したリクエストに基づいて、リクエスト待ち行列は、再び順番が組み替えられる。この手順を、受け入れ承認制御（admission  control）と呼ぶ。コンテンツのための新規なリクエストは、可能ならば（資源が許す限り）認められる。具体的には、集中型サーバが、コンテンツのための新規なリクエストが認められるかどうかを決定する。本発明の集中化したスケジューラは、すでに認められたリクエストをキャンセルすることなしに、コンテンツのための新規なリクエストを満たすスケジュールを作成することができるかどうかを判定する。この判定は、部分的に供給され約束されたリクエストのサービスと、標準化された待ち行列から取り出される最新リクエストとを、エミュレートすることによってなされる。このスケジュールが作成できない場合、コンテンツのための新規なリクエストは拒否されて、リクエスト待ち行列から取り除かれる。
【００４８】
本発明の集中型サーバは命令をエッジ・サーバおよびクライアント／ユーザに対して、コンテンツのための最新リクエストの受け入れ承認がなされるべく作成されたスケジュール通りにダウンロードを行うよう、命令を送信する。
【００４９】
他の実施形態においては、コンテンツの各々のストライピング装置がコンテンツの単一ユニットとして定義される限り、本発明の方法はストライピング（データの分散蓄積）を使用することもできる。ストライピングされたコンテンツのためのリクエストは、各々のストライプの装置に対して付加的に割り当てられた予定時刻を有する複数のリクエストを利用することにより実現される。この方法は、全体の複雑度を増加させるが、より早くしかもパラレルにコンテンツを配信し得る。
【００５０】
このように、本発明の標準化速度で最も早く配信する（ＮＲＥＤ）方法は、時間的および空間的にコンテンツ配信の負荷を平坦化し、そして、このことにより、時間通りに、より多くのリクエストされたコンテンツを配信する。コンテンツのリクエストは、しばしば集中化する（ピークの時間に、そして、特定の場所から来る）ため、もしスケジューリングしない場合には、コンテンツ配信ネットワークは、特定の時間に、オーバーロードとなり、またある時間には、配信されないことがあり得ることになる。
【００５１】
本発明は、ハードウェア、ソフトウェア、ファームウェア、専用プロセッサまたはこれらの組合せにより、さまざまな形で実現できると理解できる。好ましくは、本発明は、ハードウェアおよびソフトウェアの組合せとして実現される。さらに、ソフトウェアは、好ましくは、アプリケーション・プログラムとして記述され、プログラム記憶装置に実際に記憶される。そして、アプリケーション・プログラムは、適切なアーキテクチャを有している装置にアップロードされ、実行され得る。望ましくは、この装置は、ハードウェア（例えば一つ以上の中央演算処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）および入出力（Ｉ／Ｏ）インターフェース）を有するコンピュータ・プラットフォームに実装される。コンピュータ・プラットフォームは、同様にオペレーティングシステムおよびマイクロ命令コードを含む。本願明細書において記載されているさまざまな方法および機能は、マイクロ命令コードの部分、アプリケーションの部分のいずれかの部分（またはこれらの組合せ）であり、それらは、オペレーティングシステム上で実行される。加えて、さまざまな他の周辺装置が、コンピュータ・プラットフォーム（例えば付加的なデータ記憶デバイスおよび印刷装置）に接続されている。
【００５２】
添付の図において表されるいくつかのシステム構成要素および方法ステップは、好ましくはソフトウェアで実装されるため、システム構成要素（またはプロセスステップ）間の実際の接続は、本発明がプログラムされる方式によって、異なることがあることが理解される。本願明細書における記述によって、当業者は、本発明の構成に係る上記構成および類似した構成を理解することが可能となるであろう。
【図面の簡単な説明】
【００５３】
【図１】本発明によって解決される課題を例示しているコンテンツ配信ネットワークのブロック線図である。
【図２】本発明の標準化速度で最も早く配信する（ＮＲＥＤ:  normalized  rate  earliest  delivery）方法を表しているフローチャートである。
【図１】
2009531956.tif 000029
【図２】
2009531956.tif 000030
【国際調査報告】
2009531956.tif 000031
2009531956.tif 000032
2009531956.tif 000033