(57)【要約】【課題】通信中の２つの端末において、端末の一方または双方で同時に２つ以上のイベントが発生したような場合でも、正しいデータで通信を行うことが可能なフローとパスの組み合わせを選択する送受信方法を提供する。【解決手段】イベントが生じた場合は、子プロセスもしくは子スレッドを生成し、親プロセスは常に対応可能とする。また、通信管理部が保持するデータにロック機能を設け、アクセスがシーケンシャルに行われるようにする。さらに、ネットワークを介して通知されるメッセージには管理番号を設けてどの情報が最新のものかを判断できるようにする。また、通信メディアを送信すると下りのパス情報が送られてくるようにする。【選択図】図１
2008011072.tif 000002
【特許請求の範囲】
【請求項１】
２つの通信端末間で、１以上のパスで、１以上のフローを送受信する際に、フローとパスの組み合わせを選択する送受信方法であって、
フロー情報を受信、自分側通信メディアの変化を受信、パス状態取得終了を受信、パス情報を受信、相手側通信メディアの変化を受信、パス優先順位を受信、選択されたパス情報を受信の何れか１つ又は複数のイベントを検出した際に、子スレッドを生成してフローとパスの組み合わせを選択することを特徴とする送受信方法。
【請求項２】
前記フロー情報を受信した際に、フロー情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして前記フロー情報を書き込み、次いでデータベースから前記フロー情報と通信相手の通信相手情報を読み込み、
下りフローがない場合はデータベースをアンロックして前記子スレッドを終了することを特徴とする請求項１に記載の送受信方法。
【請求項３】
前記フロー情報を受信した際に、フロー情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして前記フロー情報を書き込み、次いでデータベースから前記フロー情報と通信相手の通信相手情報を読み込み、
下りフローがある場合はパス情報を読み込み、さらに下りパス情報がある場合はデータベースをアンロックし、パス状態取得を依頼することを特徴とする請求項１に記載の送受信方法。
【請求項４】
前記フロー情報を受信した際に、フロー情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして前記フロー情報を書き込み、次いでデータベースから前記フロー情報と通信相手の通信相手情報を読み込み、
下りフローがある場合はパス情報を読み込み、次いで下りパス情報がない場合は自分側通信メディア情報を読み込み、自分側通信メディア管理番号を増加させて通信相手情報を書き込み、データベースをアンロックした後、通信メディア情報と自分側通信メディア管理番号と一緒に送信することを特徴とする請求項１に記載の送受信方法。
【請求項５】
前記自分側通信メディアの変化を受信した際に、通信メディア情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして前記通信メディア情報を書き込み、次いでデータベースから前記フロー情報を読み込んだ後、データベースをアンロックして通信相手毎にフローをチェックし、
通信相手に下りフローがある場合は通信メディア情報送信用の子スレッドを生成し、さらに通信相手に上りフローがある場合はパス情報送信用の子スレッドを生成することを特徴とする請求項１に記載の送受信方法。
【請求項６】
前記通信メディア情報送信用の子スレッドを生成した後、前記子スレッドは、データベースをロックして通信相手情報及び通信メディア情報を読み込み、次いで自分側通信メディア管理番号を増加させて通信相手情報を書き込み、データベースをアンロックした後、前記通信メディア情報を通信相手に送信し、前記通信メディア情報送信用の子スレッドを終了することを特徴とする請求項５に記載の送受信方法。
【請求項７】
前記パス情報送信用の子スレッドを生成した後、前記子スレッドは、データベースをロックして通信相手情報及び通信メディア情報並びに相手側通信メディア情報を読み込んでパス情報を生成し、次いで自分側パス管理番号を増加させて通信相手情報及び前記パス情報を書き込み、データベースをアンロックした後、前記パス情報を通信相手に送信し、前記パス情報送信用の子スレッドを終了することを特徴とする請求項５に記載の送受信方法。
【請求項８】
前記パス状態取得終了を受信した際に、パス状態取得終了用の子スレッドを生成し、前記子スレッドは、データベースをロックしてパス情報を書き込み、次いで通信相手のパス情報及びフロー情報を読み込んだ後、自分側パス優先順位管理番号を増加させて通信相手情報を書き込んで、データベースをアンロックし、次いでパス優先順位を生成させて通信相手に送信することを特徴とする請求項１に記載の送受信方法。
【請求項９】
前記パス情報を受信した際に、パス情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして通信相手情報を読み込み、次いで、「データベース内の相手側パス管理番号」＜「受信した相手側パス管理番号」であった場合はチェックＯＫとして受信したパス情報を書き込み、この後、前記受信した相手側パス管理番号で通信相手情報を書き込んでデータベースをアンロックし、次いでパス状態取得を依頼することを特徴とする請求項１に記載の送受信方法。
【請求項１０】
前記「データベース内の相手側パス管理番号」＜「受信した相手側パス管理番号」でなかった場合は、チェックＮＧとしてデータベースをアンロックし、前記子スレッドを終了することを特徴とする請求項９に記載の送受信方法。
【請求項１１】
前記相手側通信メディアの変化を受信した際に、相手側通信メディア情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして通信相手情報を読み込み、次いで、「データベース内の相手側通信メディア管理番号」＜「受信した相手側通信メディア管理番号」であった場合はチェックＯＫとして受信した相手側通信メディア情報を書き込み、この後、通信メディア情報及び相手側通信メディア情報を読み込んでパス情報を生成して書き込み、次いで自分側パス管理番号を増加させて通信相手情報を書き込んでデータベースをアンロックし、この後、前記パス情報を送信することを特徴とする請求項１に記載の送受信方法。
【請求項１２】
前記「データベース内の相手側通信メディア管理番号」＜「受信した相手側通信メディア管理番号」でなかった場合は、チェックＮＧとしてデータベースをアンロックし、前記子スレッドを終了することを特徴とする前記請求項１１に記載の送受信方法。
【請求項１３】
前記パス優先順位を受信した際に、パス優先順位用の子スレッドを生成し、前記子スレッドは、データベースをロックして通信相手情報を読み込み、次いで、「データベース内の相手側パス優先順位管理番号」＜「受信した相手側パス優先順位管理番号」であった場合はチェックＯＫとして、上りに関する嗜好を加味した選択されたパス情報を生成して書き込み、次いで受信した相手側パス優先順位管理番号で通信相手情を書き込んでデータベースをアンロックし、この後、前記選択されたパス情報を送信することを特徴とする請求項１に記載の送受信方法。
【請求項１４】
前記「データベース内の相手側パス優先順位管理番号」＜「受信した相手側パス優先順位管理番号」でなかった場合は、チェックＮＧとしてデータベースをアンロックし、前記子スレッドを終了することを特徴とする請求項１３に記載の送受信方法。
【請求項１５】
前記選択されたパス情報を受信した際に、選択されたパス情報用の子スレッドを生成し、前記子スレッドは、データベースをロックして通信相手情報を読み込み、次いで、「データベース内の自分側パス優先順位管理番号」≦「受信した自分側パス優先順位管理番号」であった場合はチェックＯＫとして選択されたパス情報を書き込み、次いで受信した自分側パス優先順位管理番号を書き込んでデータベースをアンロックし、この後、ＭｕｌｔｉｐｌｅＣｏＡのインタフェースでネットワーク状態を通知することを特徴とする請求項１に記載の送受信方法。
【請求項１６】
前記「データベース内の自分側パス優先順位管理番号」≦「受信した自分側パス優先順位管理番号」でなかった場合は、チェックＮＧとしてデータベースをアンロックし、前記子スレッドを終了することを特徴とする請求項１５に記載の送受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭｏｂｉｌｅＩＰなどの第三層移動管理プロトコルにおける通信路選択機能を有し、アプリケーションに帯域を割り当てる送受信方法に関する。
【背景技術】
【０００２】
近年、ＭｏｂｉｌｅＩＰｖ６（Mobility Support in  ＩＰｖ６、ＲＦＣ３７７５）等のＩＰ層でのモビリティサポートの研究・開発が盛んである。ＭｏｂｉｌｅＩＰは、（ＯＳＩ；Open Systems Interconnection）７階層モデルにおける第三層のプロトコルで、上位アプリケーションからクライアントの移動（ネットワーク／通信メディアの切り替えや、通信の瞬断など）を隠蔽し、通信を継続させる技術である。このＭｏｂｉｌｅＩＰは、モバイルノード（ＭＮ：Mobile Node）、ホームエージェント（ＨＡ：Ｈome Ａgent）、コレスポンデントノード（ＣＮ：Correspondent Node）と呼ばれるノードから構成される。
【０００３】
モバイルノード（ＭＮ）は、ホームアドレスと呼ばれる常に不変なアドレスを有しており、そのアドレスを管理するノードがホームエージェント（ＨＡ）である。ＭＮはＨＡのリンクであるホームリンク以外のネットワークに接続した際、ケアオブアドレス（ＣｏＡ：Care-of Address）と呼ばれるアドレスを何らかの手段（ＲＡ、ＤＨＣＰｖ６など）で得る。ここで得たＣｏＡは、ＨＡにＢｉｎｄｉｎｇ  Ｕｐｄａｔｅというメッセージで通知される。
【０００４】
この結果、ＭＮと通信したいノード（＝ＣＮ）がホームアドレス宛にパケットを送信すると、ホームアドレスはＨＡの管理するリンクのアドレスであるので、一旦、ＨＡに届く。その際に、ＨＡは、ホームアドレスを関連付けされたＣｏＡ宛に転送する。この結果、常にＭＮは、ホームアドレスで通信可能となる。ＭＮにおいては、ＭＮ上で動作するアプリケーションが、前記ホームアドレスと呼ばれるＩＰアドレスを常に使用し通信する。
【０００５】
実際のＩＰｖ６（Internet Protocol Version ６ ）パケットのソースアドレスもしくはディスティネーションアドレスにはＣｏＡを用いる。また、上位アプリケーションに移動を隠蔽するために、ＩＰｖ６  ｏｖｅｒ  ＩＰｖ６カプセル化、ｍｏｂｉｌｉｔｙ  ｈｅａｄｅｒなどの技術を用いる。この結果、アプリケーションにはホームアドレスを通知し、実際に用いるＩＰｖ６アドレス（ＣｏＡ）を隠蔽している。その結果、前記アプリケーションは、以下のような特性を持つ。
【０００６】
（１）ネットワークとの接続性がある際には、ホームアドレスで常に通信が可能である。（２）通信中に、複数の異なるネットワークへのハンドオーバーが出来るようになる。すなわち、ＭｏｂｉｌｅＩＰ対応端末は、複数の通信メディア（例えば、ＮＩＣ：Network Interface Card）を有することが可能で、前記複数の通信メディアに跨ったハンドオーバーが可能である。
【０００７】
また、ＭｏｂｉｌｅＩＰは、複数のＣｏＡを有する場合、複数の通信メディアを同時に使用するマルチホームを実現できるといわれることが多い。しかしながら、実際のＭｏｂｉｌｅＩＰの仕様では、マルチホームを実現することはできない。そこで、それを実現する一手段として、全てのＣｏＡを通信相手及びＨＡに対して通知するべきであるとの趣旨から、複数のＣｏＡを有する際のＭｏｂｉｌｅＩＰの仕様である「draft-ietf-monami6-multiplecoa」が提案されている。また、複数の通信メディアを同時に使用する技術として、特許文献１が知られている。
【０００８】
また、「draft-ietf-monami6-multiplecoa」に代表される、マルチホーム機能を有するＬ３モビリティプロトコルにおいては、その機能の使用価値を高めるために、ＥＮＤ端末の通信において、ポリシールーティングの設定とアプリケーション動作の連携が必要となる。
これらの問題を解決するために、アプリケーションの嗜好に従って、アプリケーション毎にポリシールーティングを設定し、さらに、各アプリケーションはそのポリシールーティングの設定に適した帯域で通信することが可能となる技術も提案されている。
【特許文献１】特表２００４−５２８７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記の提案にはシーケンス上、両ＥＮＤ端末においていずれかの通信メディアが使用不可能になったり、または、何らかの通信メディアが使用可能になったなどのイベントが同時に発生した際の対応が、未解決のままとなっている。
【００１０】
例えば、図２０（Ａ）に示すように通信開始の初期シーケンスにおいて、端末１０の通信管理部はアプリケーションからのフロー情報（イニシエータとなるべきかどうかを含んだ）を受取り、イニシエータとなるべき場合には通信メディアのＮＩＣ情報を通信相手の端末１１に送信する。その結果、相手からパス情報を得る。このパス情報は、上りと下りの両方が存在している。
【００１１】
これを、通信中の両通信端末で、イベントが同時発生した場合に当てはめて見ると、以下のような状態に陥ってしまう。例えば、図２０（Ｂ）に示すようにイベントが発生した通信端末側では、イニシエータとなるべく通信メディア情報を通信相手に送信する。その際、イニシエータとなるので、通信相手端末からパス情報が帰ってくることを期待する。これが双方の通信端末で同時に起きてしまうと、双方がイニシエータとなってしまい、通信メディアを受取っても、パス情報を返せない状態、いわゆるシーケンスがデッドロック状態に陥ってしまうという問題がある。
【課題を解決するための手段】
【００１２】
本発明においては、上述の問題を解決するために、イベントが生じた場合は子プロセスもしくは子スレッドを生成してそのイベントに対応し、親プロセスは常にイベントに対応可能とする。また、通信管理部が保持するデータにロック機能を設け、アクセスがシーケンシャルに行われるようにする。さらに、ネットワークを介して通知されるメッセージには管理番号を設けてどの情報が最新のものかを判断できるようにする。また、通信メディア情報を送信すると必ず下り又は上りのパス情報が送られてくるようにする。
【００１３】
本発明における送受信方法は、２つの通信端末間で、１以上のパスで、１以上のフローを送受信する際に、フロー情報を受信、自分側通信メディアの変化の受信、パス状態取得終了を受信、パス情報を受信、相手側通信メディアの変化を受信、パス優先順位を受信、選択されたパス情報を受信のイベントの１つ又は複数を検出した際に、各イベント用の子スレッドを生成してフローとパスの組み合わせを選択することを特徴とする。
【００１４】
前記の各イベント用の子スレッドは、データベースをロックして各イベントに関わる情報のを書き込み又は読み出し等の所定の処理を行った後、データベースをアンロックし、次いで子スレッドは相手通信端末に情報を送信するなどして終了する。
また、通信端末は、上記の送受信を行うに際して、通信相手の通信相手情報として、少なくとも通信相手アドレスを有する他に、自分側通信メディア管理番号、相手側通信メディア管理番号、自分側パス管理番号、相手側パス管理番号、自分側優先順位管理番号、相手側優先順位管理番号の何れかを用いている。
【発明の効果】
【００１５】
本発明によれば、通信中の２つの通信端末において同時にイベントが発生しても、デッドロックを起さずに通信を続けることが可能となる。また、微小時間内に複数のイベントが発生した場合にも、最終的に正しい情報をもつことが可能となり、正しい通信を続けることができる。さらに、動画ストリーミングのような一方向のアプリケーションの場合にも、特別な処理をすることなく片方向のパスのみを保持すればよくなり、無駄なデータを保持／送受信しなくてすむようになる。
【発明を実施するための最良の形態】
【００１６】
図により本発明の概略を説明する。図１（Ａ）は動画ストリーミングの例を用いたシステム構成の模式図で、一方の端末１０は、ホームアドレスとしてＩＰ１０を有し、通信メディアとしてＮＩＣ１００及びＮＩＣ１０１を有していて、その双方でインターネットに接続しているとする。他方の端末１１（端末１０の通信相手端末）は、ホームアドレスとしてＩＰ１１を有し、通信メディアとしてＮＩＣ１１０及びＮＩＣ１１１を有していて、そのうちのＮＩＣ１１０でインターネットに接続しているとする。
【００１７】
端末１０及び端末１１の構成は、概略として動画の送信／受信のアプリケーション（１３ａ，１３ｂ）、通信管理部（１４ａ，１４ｂ）、ＭｕｌｔｉｐｌｅＣｏＡ部（１５ａ，１５ｂ）から成る。ここで、通信管理部（１４ａ，１４ｂ）は、図１（Ｂ）に示すように、通信メディア監視モジュール１６、パス管理モジュール１７、パス状態取得モジュール１８から成る。通信メディア監視モジュール１６は、主に通信メディアのＮＩＣを監視し、そのＮＩＣが使用可能かどうかを判断したり、ＭｕｌｔｉｐｌｅＣｏＡから上がるイベントを受信する機能を有していて、それらの通信メディア情報をパス管理モジュール１７に通知する機能を有している。
【００１８】
パス管理モジュール１７は、アプリケーション（１３ａ，１３ｂ）からのフロー情報受信機能、通信メディア監視モジュール１６から通知される通信メディア情報受信機能、通信相手に通信メディア情報を送信する機能、通信相手から通信メディア情報を受信する機能、パス（通信メディアの組み合わせ）作成機能、優先順位決定機能、ポリシールーティング設定機能、帯域割当通知機能、データベース機能等を有する。
パス状態取得モジュール１８は、ＥＮＤ−ＥＮＤのパスを測定したり、パス状態サーバの保有する情報から取得したりすることにより、帯域情報や遅延時間などパスの状態を取得する機能を有している。
【００１９】
ここで、例えば、通信端末に以下のようなイベント発生があるとする。
（１）通信端末を起動する。
（２）２つの通信端末間で通信開始する。
（３）通信端末１０側において、通信メディアＮＩＣ１０１が使用不可能となる。
（４）その後、通信端末１１側の通信メディアＮＩＣ１１１が使用可能となる。
【００２０】
まず、（１）の通信端末の起動時の処理について、図２のシーケンス図により説明をする。例えば、端末１０の通信管理部１４ａが起動されると、通信メディア監視モジュール１６が現在使用可能な通信メディアＮＩＣを判断し、使用可能な通信メディアのリストを通信メディア情報としてパス管理モジュール１７に送信する。パス管理モジュール１７では、通信メディア情報を受取ったことをトリガに子スレッドを生成する。その子スレッドは、パス管理モジュール１７が有しているデータベース機能にアクセスし、まず、データベースにロックをかける。この結果、データベースがアンロックをされるまでは、この子スレッド以外でのデータベースの読み込みや書き込みが出来なくなる。
【００２１】
ところで、以下に本発明を説明するに際して、上記の「データベースをロックする」という記載が頻繁に出てくるが、これは、Ａというスレッドでデータベースをロックしている間は、Ｂというスレッドがデータベースにアクセスしようとするのを拒否することを言う。すなわち、Ｂスレッドは、Ａスレッドがデータベースをアンロックするまで待機することとなり、この結果、データベースへのアクセスは、必ずシーケンシャルに行われることとなる。
【００２２】
図１に示すようなシステム構成において、端末１０では通信メディアのＮＩＣ１００とＮＩＣ１０１の情報が、端末１１では通信メディアのＮＩＣ１１０の情報が書き込まれる。通信メディア情報は、最低限そのＮＩＣの持つＣｏＡ（ケアオブアドレス）を有している。この通信メディア情報を図３（Ａ）、図３（Ｂ）に示す。図３（Ａ）は、端末１０側が有する通信メディア情報で、ＮＩＣ１００はＣｏＡ１００というＩＰアドレスを持ち、上り下り共に１１ＭｂｐｓのＮＩＣであり、ＮＩＣ１０１はＣｏＡ１０１というＩＰアドレスを持ち上り下り共に５４ＭｂｐｓのＮＩＣであることを示している。図３（Ｂ）は、端末１１側が有する通信メディア情報で、ＮＩＣ１１０はＣｏＡ１１０というＩＰアドレスを持ち、上り下り共に１１ＭｂｐｓのＮＩＣであることを示している。これらの通信メディア情報がデータベースに書き込まれたらデータベースをアンロックし、子スレッドは消滅する。
【００２３】
次に、（２）の２つの通信端末間での通信開始の処理について、図１及び図４−１〜図４−６のシーケンス図により説明する。まず、図４−１に示すように、動画送信アプリケーション１３ｂと動画受信アプリケーション１３ａとの間で呼制御に関する通信が行われ、フロー情報が確定する。端末１０側の動画受信アプリケーション１３ａは、確定したフロー情報を通信管理部１４ａのパス管理モジュール１７に通知する。このフロー情報は図５のようなデータで、フローのソースアドレスがＩＰ１１で、ディスティネーションアドレスがＩＰ１０、すなわち、このフロー情報は下り（端末１１から端末１０への方向）となっている。
【００２４】
また、ディスティネーションのポートは９０８０でソースポートは特に指定されておらず、帯域幅ＢＷ１（５０ｋｂｐｓ）に関する嗜好レベルは必須（Ｍｕｓｔ）、帯域幅ＢＷ２（４００ｋｂｐｓ）に対する嗜好レベルは＊１、帯域幅ＢＷ３に対する嗜好レベルは＊５、遅延に対する嗜好レベルが＊１、価格に対する嗜好レベルが＊３のフロー情報となっている。通信管理部１４ａのパス管理モジュール１７では、下りのフロー情報をアプリケーションから通知されたことをトリガに動作を開始する。下りフロー情報を受取ったパス管理モジュール１７は、子スレッドを生成する。
【００２５】
生成された子スレッドは、まず、パス管理モジュール１７のデータベースをロックし、取得したフロー情報を書き込む。次に、該当する通信相手に関する通信相手情報を読み込む。図４−１に示す本例の場合、この情報は存在しないが、既に他のアプリケーションによる通信がある場合はこの情報が存在することもある。次いで、通信相手（端末１１）に関する下りパスが存在するかどうかをチェックする。これは、他のアプリケーションによって端末１０−端末１１間の通信が行われていた場合には、既に下りパスが存在するケースがある。ただ、本例では他のアプリケーションはなく、下りパスがデータベースに存在しないので、自分側（端末１０側）通信メディア情報を読み込み、通信相手情報を書き込む。
【００２６】
このとき、通信相手情報の自分側通信メディア管理番号を、先に読み込んだ通信相手情報の通信メディア管理番号に「＋１」して書き込む。本例では、読み込んだ際に通信相手情報が無かったため、図６（Ａ）のように、自分側通信メディア情報管理番号を「１」としたので、相手側通信メディア管理番号は「０」で、相手アドレスにはＩＰ１１として情報を書き込む。その後、データベースをアンロックし、通信相手（端末１１）の通信管理部のパス管理モジュール１７に、図３（Ａ）に示すような通信メディア情報と自分側（端末１０側）通信メディア情報管理番号を通知する。
【００２７】
続いて、図４−２により、端末１０から通信メディア情報を受取った端末１１側の処理について説明する。端末１１では、端末１０から通信メディア情報を受取ったことをトリガに、子スレッドを生成する。生成された子スレッドは、まず、データベースをロックする。次に、通信相手情報（端末１０）を読み込んで、データベース中の相手側通信メディア情報管理番号と、いま端末１０から受取った通信メディア情報に添付された端末１０側の通信メディア情報管理番号とを比べ、受取った管理番号の方が大きかった場合はチェックＯＫとする。図４−２の本例では、通信相手情報が存在しないので相手側通信メディア情報管理番号＝０と見なし、１＞０なので、チェックＯＫとなる。チェックＯＫとなったことにより、通知された端末１０の通信メディア情報をデータベースに書き込む。
【００２８】
また、自分側（端末１１）の通信メディア情報を読み込み、相手の通信メディア情報と自分の通信メディア情報とから図７（Ａ）に示すようなパス情報を作成する。パス情報は送信元端末識別子ＳｒｃＡｄｄｒ、送信先端末識別子となるＤｓｔＡｄｄｒ、そのパスでの使用可能帯域幅（ここではブランク）、遅延時間、価格、送信元の通信メディアであるＳｒｃＮＩＣ、送信先の通信メディアであるＤｓｔＮＩＣなどの情報を含む。本例では、パス１，パス２共に送信元の端末はＩＰ１１を持つ端末すなわち端末１１で、送信先の端末はＩＰ１０を持つ端末１０で、パス１，パス２共に送信元のＮＩＣはＮＩＣ１１０だが、送信先のＮＩＣだけ異なって、パス１ではＮＩＣ１００に、パス２ではＮＩＣ１０１を利用することを示している。
【００２９】
このパス情報をデータベースに書き込み、通信相手情報の自分側パス管理番号に先ほど得た値に「＋１」としてデータベースに書き込む。本例では「０＋１」で「１」、また、図６（Ｂ）に示すように相手側通信メディア情報管理番号も受取った数字（＝１）として書き込む。これらの書込みが終了したら、データベースをアンロックする。そして、自分側（端末１１側）パス管理番号（＝１）と共にパス情報を、端末１０の通信管理部のパス管理モジュール１７に送信する。この子スレッドは、パス情報を送信したら消滅する。
【００３０】
次に、図４−３により、端末１１からパス情報を受取った後の端末１０側における処理について説明する。端末１０のパス管理モジュール１７は、端末１１からパス情報を受取り、子スレッドを生成し、データベースをロックする。次に、通信相手情報を読み込み、相手側パス管理番号と、受取った端末１１側パス管理番号とを比べ、受取った管理番号の方が大きかった場合には、チェックＯＫとし、受取ったパス情報をデータベースに書き込む。また、通信相手情報の相手側パス管理番号に「＋１」してデータベースに書き込み、データベースをアンロックする。ここで得たパス情報をパス状態取得モジュールに送信してパス状態の取得を依頼し、この子スレッドは消滅する。
【００３１】
パス状態取得モジュール１８では、受取ったパス情報をもとにパスの状態を取得する。パスの状態の取得は、ネットワーク上のサーバから取得しても良いし、実際にＥＮＤ−ＥＮＤで測定しても良い。パス状態取得モジュールでのネットワーク状態の取得が終わると、取得が終了した旨がパス管理モジュールに通知される（図４−４）。このデータ（取得終了）は、パス情報の使用可能帯域／遅延時間／価格などの値となっている。
【００３２】
図４−４は、図４−３に引続く処理シーケンスを示し、端末１０のパス管理モジュール１７は、取得終了のメッセージを受けて、使用可能帯域幅／遅延時間／価格などの値を入れることが可能となる。パスにこの値が入った後のパス情報を図７（Ｂ）に示す。まず、パス管理モジュール１７は、受信したパス状態取得終了メッセージから子スレッドの生成と図７（Ｂ）のようなパス情報を作成し、データベースをロックした上でパス情報に上書きする。次に、パス情報を読み込み、さらにフロー情報を読み込んで、パス優先順位を決定する。
【００３３】
パス優先順位は、各フローとパスの組み合せで、本例ではフローが１つしかないので、パスの数と同数の組み合せが存在する。このパス優先順位は、一例として示す図８（Ａ）のようになり、例えば、組み合せ１の場合にはフロー１０−１はパス１を利用し、４００ｋｂｐｓで、スコアは９５であり、組み合せ２の場合にはパス２を利用し、２Ｍｂｐｓで、スコアは１０３とする。これは、端末１０側としては、組み合せ２の方をより好むことを示している。このパス優先順位が決定したら、通信相手情報の自分側優先順位管理番号を読み、そこに「＋１」したものを新たな自分側優先順位管理番号として、通信相手情報をデータベースに書き込み、データベースをアンロックする。次にこのパス優先順位を送信するため、孫スレッドを生成する。孫スレッドは、パス優先順位と新たな自分側優先順位管理番号を通信相手（端末１１）に送信する。
【００３４】
次に、図４−４に続く図４−５により、パス優先順位を受取った端末１１側における処理について説明する。パス優先順位を受取った端末１１のパス管理モジュール１７は、子スレッド生成する。その子スレッドは、まず、データベースにロックをかける。次に、通信相手情報を読み込み、その中の相手側優先順位管理番号を取得する。「データベース内の相手側優先順位管理番号＜受信した相手側優先順位管理番号」であればチェックＯＫとして、以下の処理を行う。まず、相手の送信してきたパス優先順位のうちの１つの組み合せを選択する。それを選択されたパス情報としてデータベースに書き込む。また、受信した相手側優先順位管理番号を通信相手情報として書き込む。その後、データベースをアンロックして、選択されたパス情報を端末１０に送信する。このとき、パス優先順位は、受信した相手側優先順位管理番号で送信し、子スレッドは消滅する。
【００３５】
次に、図４−５に引続く図４−６により、選択されたパス情報を受信した端末１０側における処理について説明する。端末１０側は選択されたパス情報を端末１１から受取ったら、まず、終了されていない孫スレッドによりデータベースをロックする。次に、端末１１に関する通信相手情報を読み込み、その自分側優先順位管理番号を取得する。この、「データベース内の自分側優先順位管理番号」≦「受信した自分側優先順位管理番号」の場合は、チェックＯＫとして選択されたパスをデータベースに書込み、データベースをアンロックする。そして、選択されたパス情報に基づき、そのアプリケーション（動画受信アプリケーション）１３ａにネットワーク状態を通知する。このネットワーク状態は図８（Ｂ）に示すような情報で、そのフローが最大限利用可能な帯域幅、遅延時間、価格などの情報を含んでいる。
【００３６】
また、これと前後して、ルーティングポリシーを設定する。これはＭｕｌｔｉｐｌｅＣｏＡなどのマルチホーム対応プロトコルのＩＦ（InterFace）を利用して行う。このとき必要な情報は、図８（Ｃ）に示すような情報で、送信元端末識別子であるＳｒｃＨｏＡ、送信元のポート番号、送信先の端末識別子であるＤｓｔＨｏＡ、送信先ポート番号、この４つの情報でフローを一意に識別することが可能で、この４つ情報はフロー識別子である。これに対して、フローをルーティングするための情報がその後に続く、送信元通信メディアであるＳｒｃＮＩＣと送信先通信メディアであるＤｓｔＮＩＣである。
【００３７】
この結果、フロー１０−１のルーティングポリシーは、送信元のＮＩＣ１１０から送信先のＮＩＣ１０１にルーティングする設定がなされる。また、先に説明したネットワーク状態を通知されたアプリケーション１３ａでは、ネットワーク情報の最大限利用可能な帯域幅に対応したコンテンツを選択したり、価格をもとにユーザに価格情報を提示したり、遅延時間をもとにバッファ量を調整したりすることが可能となる。本例では、この結果、２Ｍｂｐｓのコンテンツを取得可能と判断し、その情報を端末１０の動画受信アプリケーション１３ａが動画送信アプリケーション１３ｂと呼制御プロトコルを通じて通知して、２Ｍｂｐｓのコンテンツを取得するようになる。
【００３８】
次に、（３）の通信端末１０側において、通信メディアＮＩＣ１０１が使用不可能となる場合について説明する。このイベントは、図９に示すシステム構成のように、図１のシステム構成から新たに通信メディアＮＩＣ１０１が使用不可となる例で、これについての処理を、図１０−１〜図１０−６のシーケンス図により説明する。
【００３９】
まず、図１０−１に示すように、端末１０の通信メディア監視モジュール１６は、通信メディアＮＩＣ１０１が使用できなくなった
ことを検知する。この使用できないという判断は、ＲＳＳＩ（ Received Signal Strength Indicator ）が一定の閾値を下回った場合や、輻輳やＳ／Ｎ（ Signal to Noise ）比が一定値を下回ったとか、これらの複合要因を考慮して判断するなど、種々の方法が考えられる。しかし、ここではこれら方法は、発明のポイントではないので考慮に入れず、通信メディア監視モジュール１６は、通信メディアＮＩＣの使用可否の判断が可能で、通信メディアの状態に変化があった場合には、パス管理モジュール１７に通信メディア情報を通知する機能を有していることが重要となる。
【００４０】
通信メディア監視モジュール１６は、通信メディアＮＩＣ１０１が使用不可能になったことを受けて、通信メディア情報をパス管理モジュール１７に通知する。この通信メディア情報は、図１１に示すように、現在使用可能な通信メディアであるＮＩＣ１００の情報となっている。通信メディア情報を受取ったパス管理モジュール１７は、子スレッドを生成する。生成された子スレッドでデータベースをロックして、自分側通信メディア情報を上書きする。次に、通信相手情報のフロー情報を読み込んで、データベースをアンロックする。
【００４１】
ここでは、上りフローがなく、下りフローが有るとする。下りフロー情報があるので、それを処理するため孫スレッドを生成し、上りはフロー情報がないので、その孫スレッドは生成しない。下りフロー情報の孫スレッドは、まず、データベースをロックし、通信相手情報を読み込み、次いで、自分側の通信メディア情報を読み込み、自分側通信メディア管理番号に「＋１」して通信相手情報を書き込んでデータベースをアンロックする。そして、通信メディア情報ＮＩＣ１００と自分側通信メディア情報管理番号（＝２）を通信相手のパス管理モジュール１７に送信する。
【００４２】
次に、図１０−２により、通信メディア情報ＮＩＣ１００を受取った端末１１側における処理について説明する。この処理シーケンスは、先に説明した図４−２と同じであるが、受取った通信メディア管理番号が「２」であることと受信した通信メディア情報が異なっている。現在のデータベース内の通信メディア管理番号は「１」なので、チェックはＯＫとなり、端末１０の通信メディアとしてＮＩＣ１００がデータベースに上書きされ、相手側通信メディア管理番号の「２」が通信相手情報としてデータベースに書き込まれ、最終的にはパス情報を端末１１側パス管理番号（＝２）として端末１０に送信する。
【００４３】
次に、図１０−３により、パス情報を受取った端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−３と同じであるが、現在の端末１１側パス管理番号が「２」であることと受信したパス情報の中身が異なっている。現在のデータベース内の端末１１側パス管理番号は「１」であるので、受取ったパス情報は、チェックＯＫとして、受信したパス情報はデータベースに上書きされる。このとき、使用可能帯域幅／遅延時間／価格などの値は、以前に取得したものをそのまま入れておく。また、端末１１に関する通信相手情報を新たに受取った相手側パス管理番号（＝２）として書き込む。そして、パス状態取得モジュール１８にパス状態取得を依頼する。
【００４４】
次に、図１０−４により、パス状態取得モジュール１８が取得依頼を受取った後の端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−４と同じになる。本例では、パスは削除されるだけなので、新たにパス状態を取得する必要はなく、取得終了をパス管理モジュール１７に通知する。パス管理モジュール１７は、取得終了を受取ったら子スレッドを生成し、まず、データベースをロックし、パス情報を書き込み（本シーケンスでは書き込むパス情報は無し）、全てのパス情報をデータベースから読み込む。また、フロー情報も読み込んで、パス優先順位を決定して、通信相手情報のパス優先順位管理番号を「＋１」して上書きし、データベースをアンロックする。次いで、孫スレッドを生成して、端末１１にパス優先順位をパス優先順位管理番号（＝２）と共に送信する。
【００４５】
次に、図１０−５により、パス優先順位を受取った端末１１側における処理について説明する。この処理シーケンスは、先に説明した図４−５と同じになる。すなわち、パス優先順位を受取った端末１１では子スレッドを生成し、まず、データベースをロックして、相手（端末１０）側優先順位管理番号をチェックする。本例ではデータベース内の相手側優先順位管理番号は「１」で、受信した相手側優先順位管理番号は「２」であるのでチェックＯＫとなり、選択されたパス情報を生成する。その選択されたパス情報をデータベースに書込み、通信相手情報の相手側優先順位管理番号を「２」として書込み、データベースをアンロックして選択されたパス情報を送信する。この場合、端末１０側の優先順位管理番号（＝２）も同時に送信する。
【００４６】
次に、図１０−６により、選択されたパス情報を受取った端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−６と同じである。すなわち、選択されたパス情報を受信したら、データベースをロックし、通信相手情報を読み込み、自分側優先順位管理番号をチェックする。本例ではデータベース内の自分側優先順位管理番号が「２」で、受信した自分側優先順位管理番号も「２」なので、チェックＯＫとなる。そこで、選択されたパス情報をデータベースに書き込み、動画受信アプリケーション１３ａにネットワーク状態を送信し、ＭｕｌｔｉｐｌｅＣｏＡ−ＩＦを利用してルーティングポリシーを通知し、アプリケーションは呼制御を経て最適な帯域幅で通信するようになる。
【００４７】
次に、（４）の通信端末１１側の通信メディアＮＩＣ１１１が使用可能となる場合について説明する。このイベントは、図１２のシステム構成に示すように、図９のシステム構成から、通信メディアＮＩＣ１１１が使用可能となる例で、これについての処理を、図１３−１〜図１３−５のシーケンス図により説明する。
【００４８】
まず、図１３−１に示すように、端末１１の通信メディア監視モジュール１６では、使用不可能であった通信メディアのＮＩＣ１１１が使用可能となったことを検知する。その結果、通信メディア情報として、図１４に示すようなＮＩＣ１１０とＮＩＣ１１１の情報をパス管理モジュール１７に通知する。通信メディア情報を受信したパス管理モジュール１７では、子スレッドを生成する。次に、データベースをロックして、通信相手情報を読み込み、自分側通信メディア情報を上書きする。また、フロー情報を読み込み、自分側通信メディア管理番号に「＋１」して「２」とし、通信相手情報に上書きして、データベースをアンロックする。
【００４９】
フロー情報には、下りフローが無く、上りフローしかないので、上りフロー有りの際の処理を行うための孫スレッドを生成する。次に、この孫スレッドによりデータベースをロックして、相手通信メディア情報と自分側通信メディア情報を読み込んで、パス情報を作成し、このパス情報を上書きし、通信相手情報の中の自分側パス管理番号に「＋１」して「３」としてデータベースに通信相手情報を書き込む。そして、データベースをアンロックした上で、図１５に示すようなパス情報と、自分側パス管理番号（＝３）を端末１０に送信する。
【００５０】
次に、図１３−２により、パス情報を受取った端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−３、図１０−３と同じである。すなわち、端末１０側がパス情報を受取ったらパス管理モジュール１７は、子スレッドを生成する。その子スレッドは、データベースをロックし、通信相手情報を読み込み、相手側パス管理番号チェックを行う。
【００５１】
ここで、データベース内の端末１１側パス管理番号は「２」で、受信したパス管理番号は「３」であるので、チェックＯＫとなる。チェックＯＫなのでパス情報を上書きし、通信相手情報の相手側パス管理番号を「３」として上書きする。データベースをアンロックした上でパス状態取得モジュール１８にパス状態の取得を依頼する。パス状態取得モジュール１８は、図１５のパス１に関しては、先に説明した（２）のイベントの際、既にパス状態を取得しているので（図７参照）、パス２に関するパス状態を取得し、取得終了後にパス管理モジュール１７に取得終了を通知する。
【００５２】
次に、図１３−３により、パス情報の取得終了を受取った後の端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−４、図１０−４と同じである。すなわち、パス常態の取得終了を受信したら、子スレッドを生成し、データベースをロックし、パス情報を書き込み、パス情報を読み込み、フロー情報を読み込む。そして、パス優先順位を決定し、通信相手情報を読み込み、通信相手情報の自分側パス優先順位管理番号に「＋１」して上書きし、データベースをアンロックする。次いで，孫スレッドを生成して、端末１１にパス優先順位をパス優先順位管理番号（＝３）と共に送信する。
【００５３】
次に、図１３−４により、パス優先順位を受取った端末１１側における処理について説明する。この処理シーケンスは、先に説明した図４−５、図１０−５と同じである。すなわち、パス優先順位を受取った端末１１では、子スレッドを生成する。まず、データベースをロックして、相手情報の端末１０側の優先順位管理番号をチェックする。本例ではデータベース内の相手側優先順位管理番号は「２」で、新たに受信した相手側優先順位管理番号は「３」であるのでチェックＯＫとなり、選択されたパス情報を生成する。その選択されたパス情報をデータベースに書き込み、通信相手情報の相手側優先順位管理番号を「３」として書込み、データベースをアンロックして選択されたパス情報を送信する。この場合、端末１０側優先順位管理番号（＝３）も同時に送信する。
【００５４】
次に、図１３−５により、選択されたパス情報を受取った端末１０側における処理について説明する。この処理シーケンスは、先に説明した図４−６、図１０−６と同じである。すなわち、選択されたパス情報を受信したら、データベースをロックし、通信相手情報を読み込み、自分側優先順位管理番号をチェックする。本例ではデータベース内の自分側優先順位管理番号が「３」で、新たに受信した自分側優先順位管理番号も「３」なのでチェックＯＫとなる。そこで、選択されたパス情報をデータベースに書込み、アプリケーションにネットワーク状態を送信し、ＭｕｌｔｉｐｌｅＣｏＡ−ＩＦを利用してルーティングポリシーを通知し、アプリケーションは呼制御を経て最適な帯域幅で通信するようになる。
【００５５】
次に、図１６−１〜図１６−７のフロー図により、本発明の送受信方法における具合的なイベント発生に対する実施形態を説明する。なお。本発明における主な特徴は、以下の３点に集約される。
１．イベントの切り分け
２．イベント毎の子スレッドの生成とデータベースのロック／アンロック
３．管理番号チェック
【００５６】
具体的なイベントとしては、以下のようになる。
［１］アプリケーションからフロー情報を受信（アプリケーションから）
［２］自分側通信メディアの変化を受信（通信メディア監視モジュールから）
［３］パス状態取得終了を受信（パス状態取得モジュールから）
［４］パス情報を受信（通信相手パス管理モジュールから）
［５］相手側通信メディアの変化を受信（通信相手パス管理モジュールから）
［６］パス優先順位を受信（通信相手パス管理モジュールから）
［７］選択されたパス情報を受信（通信相手パス管理モジュールから）
なお、このうち、[７］に関しては、パス管理モジュールから親スレッドにメッセージが送信されるとは限らず、その前のシーケンスで既に子スレッドが生成されていて、その子スレッドで処理されることもある。
【００５７】
まず、「［１］アプリケーションからフロー情報を受信」について、図１６−１により説明する。これはアプリケーションが、ルーティングの設定と帯域の割当を、通信管理部に対して依頼するために通知する。このフロー情報は、これらを依頼する場合と、通信が終了して依頼を取り下げる場合とがある。これは、通信管理部のパス管理モジュールからは、フローの追加要求とフローの削除要求と見ることができる。フロー情報を受取ったら（Ｓ１００）、フロー情報の変化に基づいた子スレッドを生成する（Ｓ１０１）。この子スレッドにより以下の処理を行う。
【００５８】
まず、データベースをロックし（Ｓ１０２）、取得したフロー情報をデータベースに追加（もしくは削除）する（Ｓ１０３）。このデータベースのロックは、フロー情報の書込み前である必要がある。フロー情報から得られる通信相手のＩＰアドレスをキーに通信相手情報とフロー情報を取得する（Ｓ１０４）。このフロー情報に下りフローがない場合は（Ｓ１０５ＮＯ）、データベースをアンロックし（Ｓ１０６）、処理を終了する（Ｓ１０７）。下りフローがある場合は（Ｓ１０５ＹＥＳ）、以下の処理を行う。
【００５９】
上述したのと同様に通信相手のＩＰアドレスをキーにパス情報を取得する（Ｓ１０８）。下りパス情報がある場合は（Ｓ１０９ＹＥＳ）、データベースをアンロックし（Ｓ１１０）、パス状態取得を依頼して（Ｓ１１１）、子スレッドを終了する（Ｓ１１２）。下りパス情報がない場合は（Ｓ１０９ＮＯ）、自身の通信メディア情報を読み込み（Ｓ１１３）、通信相手情報の自分側通信メディア管理番号を増加（例えば＋１）させた後、その通信相手情報を書き込み（Ｓ１１４）、データベースをアンロックする（Ｓ１１５）。その後、取得した自分側通信メディア情報を送信し（Ｓ１１６）、子スレッドを終了する（Ｓ１１７）。
【００６０】
つまり、データベースのデータの読み込みや書込みがある間は、データベースをロックすることとなる。また、その他のモジュールへのパス状態取得依頼や、通信メディア情報送信及び、スレッドの終了前にはアンロックする必要がある。
【００６１】
次に「［２］自分側通信メディア状態の変化を受信」について、図１６−２により説明する。図１６−２（Ａ）に示すように、自分側の通信メディア状態に変化が生じたことを検出（受信）したら（Ｓ２００）、まず、子スレッドを作成する（Ｓ２０１）。次に、データベースをロックし（Ｓ２０２）、通信メディア情報を書き込む（Ｓ２０３）。次にフロー情報を読み込み（Ｓ２０４）、データベースをアンロックする（Ｓ２０５）。
【００６２】
ここで、フロー情報は普通、複数あり通信相手も一つとは限らない。そこで、通信相手毎にフロー情報をチェックして、その相手との通信に下りフローがある場合は（Ｓ２０７ＹＥＳ）、通信メディア情報送信用の子スレッドを生成する（Ｓ２０８）。つまり、通信相手が二つあり、その双方に下りフローある場合は、ここで二つの子スレッドが生成されることとなる。同様に上りフローに関してもチェックを行い、上りフローがある場合は（Ｓ２０９ＹＥＳ）、パス情報送信用の子スレッドを生成する（Ｓ２１０）。これも通信メディア情報送信用子スレッドと同様、複数の子スレッドが生成される可能性がある。
【００６３】
次に、通信メディア情報送信用子のスレッド（Ｓ２０９）の処理を、図１６−２（Ｂ）により説明する。通信メディア送信用の子スレッドは、少なくとも通信相手のＩＰアドレスを知った状態で生成される（Ｓ２２１）。まず、データベースをロックして（Ｓ２２２）、通信メディア情報を読み込み、通信相手情報をそのＩＰアドレスをキーに読み込み（２２３）、自分側通信メディア管理番号を増加させて通信相手情報に書き込み（Ｓ２２４）、データベースをアンロックする（Ｓ２２５）。そして、通信メディア情報と、増加後の自分側通信メディア管理番号とをセットで通信相手に送信し（Ｓ２２６）、子スレッドを終了する（Ｓ２２７）。
【００６４】
次に、パス情報送信用の子スレッドの処理を、図１６−２（Ｃ）により説明する。パス情報送信用の子スレッドは、通信メディア送信用の子スレッドと同様に少なくとも通信相手のＩＰアドレスを知った状態で生成される（Ｓ２３１）。まず、データベースをロックする（Ｓ２３２）。このロックはデータベースデータの読み込み前に行われなければ成らない。次に、通信メディア情報を読み込み、通信相手のＩＰアドレスをキーに相手側通信メディア情報を読み込み、通信相手情報を読み込む（Ｓ２３３）。
【００６５】
そして、取得した通信メディア情報と相手側通信メディア情報をもとにパス情報を生成する（Ｓ２３４）。次いで、パス情報及び通信相手情報の自分側パス管理番号を増加させて書き込み（Ｓ２３５）、データベースをアンロックする（Ｓ２３６）。なお、データベースのアンロックは、通信メディア情報取得、相手側通信メディア情報取得、通信相手情報書込みの処理後に行われなければならない。そしてパス情報を増加した自分側パス管理番号と共に送信し（Ｓ２３７）、子スレッドを終了する（Ｓ２３８）。
【００６６】
次に、「［３］パス状態取得終了を受信」について、図１６−３により説明する。パス状態取得モジュールは、パスの状態を取得したら、その取得終了をパス管理モジュールに通知する（Ｓ３００）。パス管理モジュールでは、パス状態取得終了の処理を行う子スレッドを生成し（Ｓ３０１）、受取った取得終了のメッセージに含まれるパス状態をデータベースに書き込むのだが、その前に、データベースをロックする（Ｓ３０２）。データベースをロックした後、該当するパス情報に帯域／遅延／価格などのネットワークの状態を書き込む（Ｓ３０３）。
【００６７】
次に、通信相手のＩＰアドレスをキーに全てのパス情報を取得し、また、その通信相手との全てのフロー情報も取得する（Ｓ３０４）。その後、通信相手情報の自分側パス優先順位管理番号を増加させてデータベースに書き込み（Ｓ３０５）、パス優先順位をパス情報とフロー情報から作成（Ｓ３０６）する。次いで、データベースをアンロックし（Ｓ３０７）、作成したパス優先順位を通信相手に送信し（Ｓ３０８）、子スレッドを終了する（Ｓ３０９）。ちなみに、このパス優先順位作成はパス情報・フロー情報読み込み後で、通信相手に送信前ならどのタイミングで行っても良い。
【００６８】
次に「［４］パス情報を受信」について、図１６−４により説明する。パス情報を受信したら（Ｓ４００）、まず、子スレッドを生成する（Ｓ４０１）。次に、データベースをロックし（Ｓ４０２）、パス情報中の相手のＩＰアドレスをキーに通信相手情報を取得する（Ｓ４０３）。データベース内の相手側パス管理番号と受信したパス情報に添付された相手側パス管理番号とを比べ、「データベース内のパス管理番号」＜「受信したパス管理番号」であった場合は、チェックＯＫとする（Ｓ４０４ＹＥＳ）。チェックＮＧだった場合には（Ｓ４０４ＮＯ）、データベースをアンロックし（Ｓ４０５）、子スレッドを終了する（Ｓ４０６）。
【００６９】
チェックＯＫだった場合には、受取ったパス情報をデータベースに書き込み（Ｓ４０７）、通信相手情報の相手側パス管理番号として、新たに受信したパス管理番号を代入して通信相手情報を書き込む（Ｓ４０８）。その後、データベースをアンロックして（Ｓ４０９）、パス状態の取得依頼をパス状態取得モジュールに依頼し（Ｓ４１０）、子スレッドを終了する（Ｓ４１１）。なお、ここで子スレッドは必ずしも終了させる必要はなく、選択されたパス情報受信用に残しても良い。
【００７０】
次に、「［５］相手側通信メディアの変化を受信」について、図１６−５により説明する。相手側から通信メディア情報の変化を受信したら（Ｓ５００）、まず、子スレッドを生成する（Ｓ５０１）。次に、データベースをロックして（Ｓ５０２）、該当する通信相手の通信相手情報を読み込む（Ｓ５０３）。データベース内の相手側通信メディア管理番号と、受信した通信メディア情報に添付された相手側通信メディア管理番号とを比べて、「データベース内の通信メディア管理番号」＜「受信した通信メディア管理番号」であったら、チェックＯＫとする（Ｓ５０４ＹＥＳ）。チェックＮＧだったらデータベースをアンロックし（Ｓ５０５）、子スレッドを終了する（Ｓ５０６）。
【００７１】
チェックＯＫの場合は（Ｓ５０４ＹＥＳ）、受取った相手側通信メディア情報を書き込み（Ｓ５０７）、通信メディア情報及び相手側通信メディア情報を読み込み（Ｓ５０８）、パス情報を生成して（Ｓ５０９）、パス情報を書き込む（Ｓ５１０）。次に、通信相手情報の自分側パス管理番号を増加させて書き込み（Ｓ５１１）、データベースをアンロックして（Ｓ５１２）、パス情報を送信して（Ｓ５１３）、子スレッドを終了する（Ｓ５１４）。
【００７２】
次に、「［６］パス優先順位を受信」について、図１６−６により説明する。パス優先順位を受信したら（Ｓ６００）、パス優先順位受信として子スレッドを生成する（Ｓ６０１）。次に、データベースをロックして（Ｓ６０２）、該当する通信相手の通信相手情報を取得する（Ｓ６０３）。データベース内の通信相手情報の相手側優先順位管理番号と、受信したパス優先順位に添付された相手側優先順位管理番号を比べ、「データベース内の優先順位管理番号」＜「受信した優先順位管理番号」であった場合に、チェックＯＫとする（Ｓ６０４ＹＥＳ）。ＮＧだった場合は（Ｓ６０４ＮＯ）、データベースをアンロックし（Ｓ６０５）、子スレッドを終了する（Ｓ６０６）。
【００７３】
チェックＯＫの場合は（Ｓ６０４ＹＥＳ）、受取ったパス優先順位から自分の上りに関する嗜好を加味して選択されたパス情報を生成する（Ｓ６０７）。その選択されたパス情報をデータベースに書込み（Ｓ６０８）、通信相手情報の相手側パス優先順位管理番号を受信したパス優先順位管理番号として書き込む（Ｓ６０９）。その後、データベースをアンロックし（Ｓ６１０）、選択されたパス情報をそのパス優先順位管理番号と共に送信し（Ｓ６１１）、子スレッドを終了する（Ｓ６１２）。
【００７４】
次に「［７］選択されたパス情報を受信」について、図１６−７により説明する。まず、選択されたパス情報を受取ったら、選択されたパス情報受信用として子スレッドを生成する（Ｓ７０１）。なお、選択されたパス情報を受信する場合に関しては、上記の「［４］パス情報を受信」の際に、最後に子スレッドを終了していない場合には、次の子スレッドの生成はなくても良い。次いで、デーベースをロックし（Ｓ７０２）、該当する通信相手情報を読み込む（Ｓ７０３）。データベース内の通信相手情報の自分側優先順位管理番号と、受信した選択されたパス情報に添付されている自分側優先順位管理番号を比べて、「データベース内の自分側優先順位管理番号」≦「受信した自分側優先順位管理番号」である場合には、チェックＯＫとする（Ｓ７０４ＹＥＳ）。この場合のみ、イコールが入っている。チェックＮＧの場合は（Ｓ７０４ＮＯ）、データベースをアンロックして（Ｓ７０５）、子スレッドを終了する（Ｓ７０６）。
【００７５】
チェックＯＫの場合には（Ｓ７０４ＹＥＳ）、選択されたパス情報をデータベースに書き込み（Ｓ７０７）、通信相手情報の自分側優先順位管理番号を書き込み（Ｓ７０８）、データベースをアンロックする（Ｓ７０９）。その後、ＭｕｌｔｉｐｌｅＣｏＡのインタフェース（ＩＦ）を用いてルーティングポリシーを設定し、アプリケーションに対して、割り当てられた帯域幅等の情報であるネットワーク状態を通知し（Ｓ７１０）、子スレッドを終了する（Ｓ７１１）。
【００７６】
次に、図１７−１〜図１９−４により、本発明における作用・効果について説明する。なお、以下の説明は、図１７−１〜図１７−３のシステム構成の模式図で示すように、２つの端末間で通信するアプリケーションとして、ＴＶ電話を用い、映像と音声の２つのフローを双方向で送受信することを例としている。また、ここでは、通信開始時の一連の処理シーケンスは終了し、最適なコンテンツでの通信が既に行われているものとする。
【００７７】
いま、２つの端末間における送受信は、図１７−１に示すように端末１０が、通信メディアＮＩＣ１００とＮＩＣ１０１で通信し、端末１１が通信メディアＮＩＣ１１０とＮＩＣ１１１で通信中でＮＩＣ１１２が使用不可の状態にあるとする。
ここで、２つの端末間における送受信のイベントとして、
｛１｝端末１１の通信メディアのＮＩＣ１１２が使用可能となるとほぼ同時に、ＮＩＣ１１１が使用できなくなる。（図１７−１→ 図１７−２への状態に変化）
｛２｝端末１１側の通信メディアのＮＩＣ１１１が使用可能となるのとほぼ同時に、端末１０側のＮＩＣ１０１が使用できなくなる。（図１７−２→ 図１７−３への状態に変化）
を想定して、以下に説明する。
【００７８】
上記｛１｝は、端末１１の通信メディアＮＩＣ１１２が使用可能になるというイベントと、通信メディアＮＩＣ１１１が使用できなくなるというイベントの２つのイベントが、端末１１でほぼ同時に起こる例である。これを、図１８−１のシーケンス図により説明する。通信メディア監視モジュールは、これらのイベントを検知して、通信メディア情報をパス管理モジュールに通知する。これは１回の監視で両方のイベントを検知するかも知れないし、２回分けて検知されるかも知れない。１回の監視で両方を検知できた場合は、通常と同じシーケンスとなる。ここでは、２回に分けて検知された例で説明する。
【００７９】
図１８−１により、通信メディアＮＩＣ１１２が使用可能となるのが、通信メディアＮＩＣ１１１が使用できなくなるより、僅かに早かった場合を説明する。通信メディアＮＩＣ１１２が使用可能となったことにより、生成された子スレッド（子スレッドＡ）の方が先にデータベースをロックし、通信メディアＮＩＣ１１１が使用不可能になったことにより生成された子スレッド（子スレッドＢ）は、データベースにアクセスできない。
【００８０】
このため、僅かに後のイベントとなる子スレッドＢのデータは、後からデータベースに反映され、データベース内のデータが正しいものとなる。ここで、子スレッドＡも子スレッドＢも上りフロー・下りフロー共に存在するため、図１６−２で説明したように、通信メディア情報送信用の子スレッドとパス情報送信用の子スレッドが生成される。つまり、都合４つの子スレッドが生成されることとなる。図１８−２では、説明を分かりやすくにするため、通信メディア情報送信用の子スレッド（Ａ−１，Ｂ−１）のみ示している。
【００８１】
図１８−２に示すように、子スレッドＡは、通信メディア情報送信のため子スレッドＡ−１を生成する。しかし、子スレッドＡ−１の送信しようとしている通信メディア情報は、間違っている可能性がある。これは、子スレッドＢの情報が反映された後にデータベースにアクセスしていれば正しい情報だが、それ以前にアクセスしていれば、正しい情報ではないからである。また、子スレッドＢは、通信メディア情報送信のため子スレッッドＢ−１を生成する。先の子スレッドＡ−１の送信しようとした通信メディア情報に対して、子スレッドＢ−１の送信しようとしている通信メディア情報は、必ず正しいものとなっている。これは、子スレッドＢ−１は、子スレッドＢ−１を生成する子スレッドＢの情報がデータベースに反映された後に生成されるためである。つまり、データベースへのアクセスタイミングを見ると、子スレッドＡ＞子スレッドＡ−１、子スレッドＢ＞子スレッドＢ−１が成立している。
【００８２】
ここで、子スレッドＡ−１による通信メディア情報の送信が子スレッドＢ−１よりも早かったとする。管理番号に注目すると、子スレッドＡ−１が送信する通信メディア情報に添付された自分側（端末１１側）通信メディア管理番号をＮとすると、子スレッドＢ−１の送信する通信メディア情報は、データベースへのアクセスがシーケンシャルとなっているため、必ずＮ＋１以上の数値となる。
【００８３】
次に、図１８−３に示すように、子スレッドＡ−１と子スレッドＢ−１が送信した通信メディア情報が、端末１０に到着する途中で順番が、ネットワークのジッタなどにより入れ変わってしまったとする。この場合、先に到着した子スレッドＢ−１からの通信メディア情報を端末１０で処理することとなる。ここで、子スレッドＢ−１からの通信メディア情報は、端末１１側通信メディア情報管理番号Ｎ＋１として処理される。そうすると、端末１０内での端末１１に関する相手端末情報中の相手側通信メディア管理番号は、Ｎ＋１となっている。その後、子スレッドＡ−１からの通信メディア情報が到着して処理するが、管理番号がＮのため、チェックＮＧとなり処理されない。
【００８４】
この結果、子スレッドＢから生まれた子スレッドＢ−１のシーケンスだけ進むこととなる。ちなみに、子スレッドＡ−１の通信メディア情報の方が先に到着した場合には、子スレッドＡ−１の処理は、通常通り処理されるが、直後に子スレッドＢ−１の通信メディア情報が到着し、その処理も通常通り処理されるため、最終的には子スレッドＢ−１起点の処理がなされることとなる。
【００８５】
上述の例は、「子スレッドＡ−１による送信が、子スレッドＢ−１よりも早い」とする場合であるが、反対に「子スレッドＢ−１による送信が、子スレッドＡ−１よりも早い」とする場合がある。この場合は、図１８−４に示すように、子スレッドＡ−１が送信する通信メディア情報も、子スレッドＢ−１が送信する通信メディア情報も子スレッドＢの後となるため、どちらも正確な情報を送信することとなる。なお、この後のシーケンスに関しては説明は省略する。
【００８６】
次いで、パス情報の送信に関して説明すると、これも通信メディア情報の送信と同じで、子スレッドＡがパス情報送信用の子スレッドＡ−２を生成し、子スレッドＢがパス情報送信用の子スレッドＢ−２を生成する。ここで、子スレッドＢは、子スレッドＡよりも必ず後に処理されるとする。また、子スレッドＡ−２は、子スレッドＡよりも後だが、子スレッドＢとの時間関係はどうなるかは分からない。また、子スレッドＢ−２は子スレッドＢよりも必ず後に処理される。つまり、データベースへのアクセスタイミングを見ると、子スレッドＡ＞子スレッドＡ−２、子スレッドＢ＞子スレッドＢ−２が成立する。
【００８７】
ここで、子スレッドＡ−２によるパス情報の送信が子スレッドＢ−２よりも早かったとする。パス情報の管理番号に注目すると、子スレッドＡ−２が送信するパス情報に添付された自分側（端末１１側）パス管理番号をＭとすると、子スレッドＢ−２の送信する通信メディア情報はデータベースへのアクセスがシーケンシャルとなっているため、必ずＭ＋１以上の数値となっている。
【００８８】
次に、図１８−５に示すように、子スレッドＡ−２と子スレッドＢ−２が送信したパス情報が端末１０に到着する途中で順番が、ネットワークのジッタなどにより変わってしまったとする。この場合、子スレッドＢ−２からのパス情報受信を、先に端末１０で処理することとなる。ここで、子スレッドＢ−２からのパス情報は、端末１１側通信メディア情報管理番号Ｍ＋１として到着し、処理される。そうすると、端末１０内での端末１１に関する相手端末情報中の相手側パス管理番号はＭ＋１となっている。その後、子スレッドＡ−２からのパス情報が到着して処理するが、管理番号がＭのため、チェックＮＧとなり、処理されない。
【００８９】
この結果、子スレッドＢから生まれた子スレッドＢ−２のシーケンスだけ進むこととなる。ちなみに、Ａ−２の子スレッドのパス情報の方が先に到着した場合には、子スレッドＡ−２の処理は通常通り処理されるが、直後に子スレッドＢ−２のパス情報が到着し、その処理も通常通り処理されるため、最終的には子スレッドＢ−２起点の処理がなされることとなる。
【００９０】
上述の例は、「子スレッドＡ−２による送信が、子スレッドＢ−２よりも早い」とする場合であるが、反対に「子スレッドＢ−２による送信が、子スレッドＡ−２よりも早い」とする場合がある。この場合は、子スレッドＡ−２が送信するパス情報も、子スレッドＢ−２が送信するパス情報も子スレッドＢの後となるため、どちらも正確な情報を送信することとなる。なお、この後のシーケンスに関しては説明は省略する。
【００９１】
次に、上記｛２｝は、端末１１側の通信メディアＮＩＣ１１１が使用可能というイベントと、端末１０側の通信メディアＮＩＣ１０１が使用できなくなるというイベントの２つイベントがほぼ同時に起こる例である。これを、図１９−１〜図１９−４のシーケンス図により説明する。
【００９２】
ここで、図１９−２に示す端末１１側の処理に注目すると、端末１０←端末１１方向のパス情報は端末１１で作成される。ここで、パス情報を作成するタイミングを見ると、自分の通信メディア監視モジュールから通信メディア情報を受取った際と、通信相手から相手側の通信メディア情報を受け取った際となっている。ここで、自分側（端末１１側）の通信メディア情報のデータベースへの書込みは、子スレッドＢが、相手側（端末１０側）の通信メディア情報のデータベースへの書込みは子スレッドＣが行う。また、子スレッドＢ自体はパス情報は作成しない。ここで必要なことは、正しいデータで生成されたパス情報に、自分側（端末１１側）パス管理番号が付加されていることにある。
【００９３】
そこで、データベースへのアクセスのタイミングを全て列挙して、各々についてパス情報が正しいかを検証する。パス情報送信用の子スレッドＢ−２のデータベースへのアクセスは必ず子スレッドＢよりも後になるので、以下の３通りが考えられる。
〈１〉子スレッドＢ→子スレッドＣ→子スレッドＢ−２
〈２〉子スレッドＢ→子スレッドＢ−２→子スレッドＣ
〈３〉子スレッドＣ→子スレッドＢ→子スレッドＢ−２
【００９４】
〈１〉の場合のシーケンスを図１９−２に、〈２〉の場合のシーケンスを図１９−３に、〈３〉の場合のシーケンスを図１９−４に示す。ここで、最終的に正しいパス情報は、端末１０側はＮＩＣ１００のみで、端末１１側はＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２が有るので、（ＮＩＣ１００）×（ＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２）の組み合せによるパスが作成されていれば良いことになる。
【００９５】
まず、〈１〉のケースについて、図１９−２により説明する。このケースでは、子スレッドＢによる通信メディア情報が反映された後に、子スレッドＣが通信メディア情報を読み込んでパス情報を作成している。そのため、子スレッドＣが作成し送信するパス情報も、子スレッドＢ−２が作成するパス情報も、（ＮＩＣ１００）×（ＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２）のものとなっている。また、端末１１側の管理番号最大値のものは子スレッドＢ−１（図１９−１参照）が作成するもので、これは正しいパス情報を反映したものとなっている。
【００９６】
次に、〈２〉のケースについて、図１９−３により説明する。このケースでは、子スレッドＣによる相手側の通信メディア情報が反映される前に、子スレッドＢ−１（図１９−１参照）がパス情報を作成し送信している。そのため、このパス情報は、（ＮＩＣ１００、ＮＩＣ１０１）×（ＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２）による間違ったパス情報を作成してしまっている。しかし、この後、子スレッドＣがパス情報を作成する際には、相手側（端末１０側）の通信メディア情報が反映されるので、（ＮＩＣ１００）×（ＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２）による正しいパスが作成され送信される。また、これは、子スレッドＢ−２によるアクセスよりも後なので、このパス情報に添付される端末１１側パス管理番号は、子スレッドＢ−２が送信するパス情報に添付される端末１１側パス管理番号よりも大きくなる。そのため、最終的には正しいパス情報が反映されることとなる。
【００９７】
最後に、〈３〉のケースについて、図１９−４により説明する。このケースでは、子スレッドＢによる通信メディア情報（自分側）が反映される前に、子スレッドＣがパス情報を作成し、送信する。そのため、子スレッドＣが作成するパス情報は、（ＮＩＣ１００）×（ＮＩＣ１１０、ＮＩＣ１１２）によるパスとなってしまう。しかし、この後子スレッドＢの情報が反映された後に、子スレッドＢ−２がパスを作成するため、このパス情報は正しいパス情報（ＮＩＣ１００）×（ＮＩＣ１１０、ＮＩＣ１１１、ＮＩＣ１１２）によるものとなる。また、このパス情報に添付される自分側パス管理番号は、子スレッドＣが送信するものよりも必ず大きいものとなるので、最終的に正しいデータが反映されることとなる。
【００９８】
以上のシーケンスは、端末１０側でも全く同じことが言えるので、詳細な説明は省略する。なお、本発明におけるポイントをまとめると、以下のようになる。
１．各種イベントにおけるシーケンスを明確化にする。
２．送信するデータ毎に管理番号を自分側と相手側に分けて使用する。
３．データベースのロックとアンロックをアクセス時に行う。
４．下りフローがある場合、通信メディア情報を送信する（又は、上りフローがある場合、通信メディア情報を送信する）。
５．上りフローがある場合、上りのパス情報を送信する（又は、下りフローがある場合、下りのパス情報を送信する）。
以上により、通信中の２つの端末において、端末の一方または双方で同時に２つ以上のイベントが発生したような場合でも、正しいデータで通信を行うことが可能となる。
【図面の簡単な説明】
【００９９】
【図１】本発明の概略を説明するシステム構成の模式図である。
【図２】通信端末の起動時の処理について説明するシーケンス図である。
【図３】図１における通信メディア情報の一例を示す図である。
【図４−１】本発明における処理を説明するシーケンス図である。
【図４−２】図４−１に引続くシーケンス図である。
【図４−３】図４−２に引続くシーケンス図である。
【図４−４】図４−３に引続くシーケンス図である。
【図４−５】図４−４に引続くシーケンス図である。
【図４−６】図４−５に引続くシーケンス図である。
【図５】図１におけるフロー情報の一例を示す図である。
【図６】図１における通信相手情報の一例を示す図である。
【図７】図１におけるパス情報の一例を示す図である。
【図８】図１におけるネットワーク状態の一例を示す図である。
【図９】図１のシステム構成で、イベントが発生したときの模式図である。
【図１０−１】イベント発生後の処理を説明するシーケンス図である。
【図１０−２】図１０−１に引続くシーケンス図である。
【図１０−３】図１０−２に引続くシーケンス図である。
【図１０−４】図１０−３に引続くシーケンス図である。
【図１０−５】図１０−４に引続くシーケンス図である。
【図１０−６】図１０−５に引続くシーケンス図である。
【図１１】イベント発生後に通知される通信メディア情報の一例を示す図である。
【図１２】図９のシステム構成で、イベントが発生したときの模式図である。
【図１３−１】他のイベント発生後の処理を説明するシーケンス図である。
【図１３−２】他のイベント発生後の処理を説明するシーケンス図である。
【図１３−３】他のイベント発生後の処理を説明するシーケンス図である。
【図１３−４】他のイベント発生後の処理を説明するシーケンス図である。
【図１３−５】他のイベント発生後の処理を説明するシーケンス図である。
【図１４】他のイベント発生時の通信メディア情報の一例を示す図である。
【図１５】他のイベント発生時のパス情報の一例を示す図である。
【図１６−１】「フロー情報を受信」のイベント発生によるフロー図である。
【図１６−２】「通信メディア変化を受信」のイベント発生によるフロー図である。
【図１６−３】「パス状態取得終了を受信」のイベント発生によるフロー図である。
【図１６−４】「パス情報を受信」のイベント発生によるフロー図である。
【図１６−５】「フ相手側通信メディア変化を受信」のイベント発生によるフロー図である。
【図１６−６】「パス優先順位を受信」のイベント発生によるフロー図である。
【図１６−７】「選択されたパス情報を受信」のイベント発生によるフロー図である。
【図１７−１】本発明を説明する他のシステム構成の模式図である。
【図１７−２】図１７−１のシステム構成で、イベントが発生したときの模式図である。
【図１７−３】図１７−２のシステム構成で、イベントが発生したときの模式図である。
【図１８−１】図１７−２における処理の一例を説明するシーケンス図である。
【図１８−２】図１８−１と異なる処理を説明するシーケンス図である。
【図１８−３】図１８−１と異なる他の処理を説明するシーケンス図である。
【図１８−４】図１８−１と異なる他の処理を説明するシーケンス図である。
【図１８−５】図１８−１と異なる他の処理を説明するシーケンス図である。
【図１９−１】図１７−３に変化したときの処理を説明するシーケンス図である。
【図１９−２】図１９−１と異なる他の処理を説明するシーケンス図である。
【図１９−３】図１９−１と異なる他の処理を説明するシーケンス図である。
【図１９−４】図１９−１と異なる他の処理を説明するシーケンス図である。
【図２０】従来の課題を説明する図である。
【符号の説明】
【０１００】
１０，１１…通信端末（端末）、１３ａ，１３ｂ…アプリケーション、１４ａ，１４ｂ…通信管理部、１５ａ，１５ｂ…ＭｕｌｔｉｐｌｅＣｏＡ部、１６…通信メディア監視モジュール、１７…パス管理モジュール、１８…パス状態取得モジュール。
【図１】
2008011072.tif 000003
【図２】
2008011072.tif 000004
【図３】
2008011072.tif 000005
【図４−１】
2008011072.tif 000006
【図４−２】
2008011072.tif 000007
【図４−３】
2008011072.tif 000008
【図４−４】
2008011072.tif 000009
【図４−５】
2008011072.tif 000010
【図４−６】
2008011072.tif 000011
【図５】
2008011072.tif 000012
【図６】
2008011072.tif 000013
【図７】
2008011072.tif 000014
【図８】
2008011072.tif 000015
【図９】
2008011072.tif 000016
【図１０−１】
2008011072.tif 000017
【図１０−２】
2008011072.tif 000018
【図１０−３】
2008011072.tif 000019
【図１０−４】
2008011072.tif 000020
【図１０−５】
2008011072.tif 000021
【図１０−６】
2008011072.tif 000022
【図１１】
2008011072.tif 000023
【図１２】
2008011072.tif 000024
【図１３−１】
2008011072.tif 000025
【図１３−２】
2008011072.tif 000026
【図１３−３】
2008011072.tif 000027
【図１３−４】
2008011072.tif 000028
【図１３−５】
2008011072.tif 000029
【図１４】
2008011072.tif 000030
【図１５】
2008011072.tif 000031
【図１６−１】
2008011072.tif 000032
【図１６−２】
2008011072.tif 000033
【図１６−３】
2008011072.tif 000034
【図１６−４】
2008011072.tif 000035
【図１６−５】
2008011072.tif 000036
【図１６−６】
2008011072.tif 000037
【図１６−７】
2008011072.tif 000038
【図１７−１】
2008011072.tif 000039
【図１７−２】
2008011072.tif 000040
【図１７−３】
2008011072.tif 000041
【図１８−１】
2008011072.tif 000042
【図１８−２】
2008011072.tif 000043
【図１８−３】
2008011072.tif 000044
【図１８−４】
2008011072.tif 000045
【図１８−５】
2008011072.tif 000046
【図１９−１】
2008011072.tif 000047
【図１９−２】
2008011072.tif 000048
【図１９−３】
2008011072.tif 000049
【図１９−４】
2008011072.tif 000050
【図２０】
2008011072.tif 000051