(57)【要約】【課題】ネットワーク上の通信に関わらないサービスについて、サービス利用の可否とサービス提供場所を、ネットワークを利用して検索する。【解決手段】上記目的を達成するために、サービス名称とマルチキャストアドレスを一意に対応させ、サービス提供手段ごとの名前に位置情報を含ませた。また、各サービス提供手段は問い合わせのあった時点で提供可能なサービスに対応するマルチキャストアドレス宛のパケットのみに応答するようにした。さらに、名前解決手段にマルチキャストアドレスとサービスの種類を表す名前との対応を保持させ、利用者からの問い合わせに回答するようにした。【選択図】  図１
2004200821.tif 000002
【特許請求の範囲】
【請求項１】
サービス提供場所検索方法であって、
ネットワークと該ネットワークに接続された複数の機器を有し、
前記複数の機器は、提供するサービスの種類毎に一意に対応するマルチキャストアドレスとサービス提供手段毎に固有なユニキャストアドレスに一意に対応する名前に位置情報を有し、特定のサービスを提供中のサービス提供手段をマルチキャスト通信を用いて検索し、発見したサービス提供手段の名前を提示することで、ネットワークを利用してサービス提供場所を検索することを特徴とするサービス提供場所検索方法。
【請求項２】
ネットワークにより通信が可能で、サービスの種類に応じてあらかじめ一意に決められたマルチキャストアドレス宛のパケットを受信でき、該マルチキャストアドレスにより一意に決まる種類のサービスをその時点で提供可能である場合にのみ、該パケットに対する返信を該パケットの送信元アドレスに対して行うことを特徴とするサービス提供手段。
【請求項３】
前記マルチキャストアドレスとサービスの種類との対応を保持し、ネットワークを介した対応の問合せに対して、該マルチキャストアドレスとサービスの種類との対応を回答することを特徴とする名前解決手段。
【請求項４】
一または複数の請求項２記載のサービス提供手段と、一以上の請求項３記載の名前解決手段と、利用者端末とから構成されることを特徴とするネットワークシステム。
【請求項５】
端末機器と、ＤＮＳサーバと、ネットワークインタフェースを有する複数のサービス提供手段と、前記端末機器と前記ＤＮＳサーバと前記サービス提供手段とを接続するネットワークとを有するシステムにおけるサービス提供手段検索方法であって、
前記複数のサービス提供手段は、サービスの種類ごとに対応するマルチキャストアドレスと該ネットワークインタフェースに対応するユニキャストアドレスを有し、
ＤＮＳサーバは、前記マルチキャストアドレスとサービスの種類を特定する前記サービス提供手段の第1の名称および前記ユニキャストアドレスと前記前記サービス提供手段に固有の第2の名称との対応を記憶したテーブルを有し、
前記端末機器は、前記ネットワークを介して、前記ＤＮＳサーバへ前記第1の名称を送信し、
前記ＤＮＳサーバは、前記端末機器から送信された第1の名称に対応するマルチキャストアドレスを前記テーブルから検索して、前記端末機器に返信し、
前記端末機器は、前記マルチキャストアドレスを宛先アドレスとして前記ネットワークに接続された前記サービス提供手段にマルチキャストし、
前記サービス提供手段のネットワークインターフェースは、前記マルチキャストアドレスが自機器のマルチキャストアドレスと一致する場合は、送信元アドレスを前記ユニキャストアドレスとして前記端末機器に返信し、
前記端末機器は、前記受信したユニキャストアドレスに対応する第2の名称を前記ＤＮＳサーバに問い合わせて、
前記ＤＮＳサーバは、問合せのあったユニキャストアドレスに対応する第2の名称を前記テーブルから検索し前記端末機器に返信し、
前記端末機器は、前記第2の名称を受信することでサービス提供手段を特定することを特徴とするサービス提供手段検索方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
ネットワークによりサービス提供の有無を検索するサービス提供場所検索方式に関連し、特に名前解決と、マルチキャスト通信に関する。
【０００２】
【従来の技術】
従来の技術では、ネットワークを利用して、あるサービスが利用可能であるかどうかを調べる方法として、ネットワーク上の通信により提供されるサービス、例えばネットワークにより送信したデータの印刷など、を受けるために通信すべきサービス提供手段のネットワークアドレスを、利用者が検索できるようになっている（例えば、非特許文献１等参照）。
【０００３】
【非特許文献１】
E.Guttman, C.Perkins, J.Veizades, and M.Day、 "Service Location Protocol, Version 2"、 RFC2608、 June 1999、 p.5-7, p.9
【０００４】
【発明が解決しようとする課題】
上記従来技術では、扱えるサービスがネットワーク上の通信により提供されるサービスに限定され、ネットワークを使用しない一般的なサービス(たとえば、清涼飲料水の販売)に関しては考慮されていない。また、サービス提供場所をネットワークアドレスで識別するため、利用者にはサービスが提供されている物理的な場所がわからないという問題があるため、利用者がサービス提供場所へ行く必要がある場合(たとえば会議室の利用)に応用できなかった。さらに従来技術では、個々のサービス提供手段がそれぞれ提供するサービスについての情報を有し、専用プロトコルによりネットワークを介して情報を提供できる必要があった。
【０００５】
【課題を解決するための手段】
上記目的を達成するために、サービス名称とマルチキャストアドレスを一意に対応させ、さらにサービス提供手段の名前に位置情報を含ませたものである。
上記他の目的を達成するために、各サービス提供手段は問い合わせのあった時点で提供可能なサービスに対応するマルチキャストアドレス宛のパケットのみに応答するようにしたものである。
【０００６】
上記他の目的を達成するために、名前解決手段にマルチキャストアドレスとサービスの種類を表す名前との対応を保持させ、利用者からの問い合わせに回答するようにしたものである。
【０００７】
【発明の実施の形態】
以下、本発明の実施例を図１により説明する。本実施例は、複数の会議室11がある建物への本発明の適用例である。会議室11の名前は、１階にある会議室は順番に１０１会議室、１０２会議室、２階にある会議室には２０１会議室、２０２会議室、というやり方で、会議室11の名前から会議室11の位置が推定できる名前がつけられている。
【０００８】
各会議室11の入り口には、その会議室が使用中か否かを示す表示手段12が備えられている。各表示手段12はIPv6ネットワーク13に接続されている。
IPv6ネットワーク13は、各会議室11の表示手段12、DNS(Domain Name System)サーバ14、および無線AP(Access Point)15が相互に接続されて構成されている。さらに無線AP15と無線通信できるIPv6ネットワーク機器も、IPv6ネットワーク13の一部となり、相互に通信が可能である。図１の携帯端末16がその例である。
【０００９】
表示手段12のブロック図を図２に示す。本実施例の表示手段12は、スイッチ21を押すと使用中表示部22に「使用中」と表示され、再びスイッチ21を押すと表示が消えるものとする。会議室利用者は会議室11の利用開始時にその会議室11の表示手段12のスイッチ21を押して「使用中」を表示させる。会議室の利用が終了したら、再び表示手段12のスイッチ21を押して「使用中」表示を消すものとする。
【００１０】
表示手段12はネットワークインターフェース23を備え、ネットワークインターフェース23によりIPv6ネットワーク13に接続されている。表示手段12のスイッチ21はネットワークインターフェース23の電源スイッチを兼ねている。使用中表示部22に「使用中」が表示されている場合はネットワークインターフェース23に電力が供給されない。「使用中」の表示が消えている場合にネットワークインターフェース23に電力が供給される。ネットワークインターフェース23は電力が供給されている間だけ動作するので、「使用中」の表示が消えている時、すなわち会議室11が空いている時だけ、ネットワークインターフェース23が動作するようになっている。
【００１１】
本実施例のネットワークインターフェース23は、IETFの仕様であるIPv6(Internet Protocol version 6)により通信が可能である。各ネットワークインターフェース23はそれぞれ固有のIPv6ユニキャストアドレスを少なくとも一つ持つ。本実施例では、各ネットワークインターフェース23に固有のリンクローカルアドレスを持つものとする。各ネットワークインターフェース23は、マルチキャストアドレス格納部24に登録されているマルチキャストアドレス宛のパケットのみを受信する。
【００１２】
DNSサーバ14は、DNSプロトコルにより名前とIPv6アドレスの対応を回答する。DNSサーバ14は名前とIPv6アドレスの対応関係が登録された名前テーブル31を持つ。
【００１３】
図３に、名前テーブル31に登録されている内容を示す。名前テーブル31には、互いに対応するIPv6アドレスと名前の組が複数登録されている。各会議室11の表示手段12のネットワークインターフェース23に固有のIPv6ユニキャストアドレス(本実施例ではリンクローカルアドレス)は、対応する会議室11の名前とともに全て登録されている。さらに、あらかじめ決められた３種類のIPv6マルチキャストアドレス（１、２、３）が名前テーブル31に登録されている。それぞれのマルチキャストアドレスは、規模（大，中，小）によってグループ化された会議室11のグループにそれぞれ対応する。マルチキャストアドレスに対応する名前はそれぞれ「大会議室」、「中会議室」、「小会議室」である。
【００１４】
次に、利用者が現在空いている会議室11を探す場合の通信シーケンスを、図４および図５に沿って説明する。
【００１５】
利用者は、IPv6プロトコルによる通信機能を持ち無線により無線AP15と通信できる携帯端末16を所持しているものとする。利用者は探している会議室11の規模に応じた名前、例えば「大会議室」、を携帯端末16に入力する(501)。携帯端末16は、DNSプロトコルによりDNSサーバ14に対して利用者が入力した名前（「大会議室」）に対応するIPv6アドレスを問い合わせる(401)。なお、DNSサーバ14のIPv6アドレスは、携帯端末16には既知であるものとする。具体的には、例えばDHCPv6(Dynamic Host Configuration Protocol)により携帯端末16にDNSサーバ14のアドレスをあらかじめ設定することが可能である。
【００１６】
携帯端末16からの問合せを受けたDNSサーバ14は、名前（この場合「大会議室」）を名前テーブル31から検索し、対応するアドレス（この場合マルチキャストアドレス１）を携帯端末16に対して回答する(402)。
DNSサーバ14からの回答を受けた携帯端末16は、得られたアドレス（マルチキャストアドレス１）を宛先アドレスとしたICMPv6(Internet Control Message Protocol for IPv6)のEcho Requestメッセージを送信する(403)。Echo Requestメッセージはマルチキャストされ、IPv6ネットワーク13に接続された全ての表示手段12に到達する。
【００１７】
各表示手段12のネットワークインターフェース23では、メッセージの宛先アドレスがマルチキャストアドレス格納手段24にあらかじめ登録されたマルチキャストアドレスと一致する場合にのみ、Echo Requestメッセージを受信する。各会議室11の表示手段12のマルチキャストアドレス格納手段24には、あらかじめ会議室11の大きさに応じたマルチキャストアドレスを設定しておく。例えば大きい会議室11の場合は、名前「大会議室」に対応するマルチキャストアドレス１を登録しておく。
【００１８】
Echo Requestメッセージの宛先アドレスがマルチキャストアドレス１（「大会議室」に対応するアドレス）である場合、マルチキャストアドレス格納手段24にマルチキャストアドレス１が登録されている表示手段21、つまり規模の大きい会議室11の表示手段21のネットワークインターフェース23だけが、そのEcho Requestメッセージを受信することになる。また、会議室11が使用中である場合、使用中表示部21に「使用中」が表示され、ネットワークインターフェース23は作動していない。よってマルチキャストアドレス１宛のEcho Requestメッセージを受信するネットワークインターフェース23は、規模が大きく、現在利用可能な会議室11のものに限られる。
【００１９】
Echo Requestメッセージを受信したネットワークインターフェース23は、EchoRequestメッセージの送信元アドレス（この場合携帯端末16のアドレス）を宛先としてEcho Replyメッセージを送信する。Echo Replyメッセージの送信元アドレスは各ネットワークインターフェース23固有のユニキャストアドレス(本実施例ではリンクローカルアドレス)を使う。
【００２０】
携帯端末16には、該当する規模（「大会議室」）で、かつ現在空いている会議室11の表示手段12からEcho Replyメッセージが届く(404)。該当する会議室11が複数ある場合は、携帯端末16に対して複数のEcho Replyメッセージが返り、該当する会議室11がない場合（全て使用中）、Echo Replyメッセージは一つも返って来ない。
【００２１】
携帯端末16はEcho Replyメッセージの受信を待ち(510)、受信したEcho Replyメッセージの送信元アドレスに対応する名前をDNSサーバ14に問い合わせる(405)。DNSサーバ14は問合せのあったアドレス（例えばリンクローカルアドレス１）を名前テーブル31から検索し、対応する名前（この場合「１０１会議室」）を携帯端末16に回答する。DNSサーバ14からの回答を受けた携帯端末16は、会議室11の名前を、画面に表示するなどの手段で利用者に提供する(505)。複数の会議室11の表示手段12からのEcho Replyメッセージを受けた場合、それぞれについてDNSサーバ14に名前を問い合わせ、名前の一覧を画面に表示するなどの手段で、利用者が希望する規模の利用可能な全ての会議室11の名前を利用者に提供する。EchoReplyメッセージを待つ処理(510)は利用者が明示的に中断するまで続く。利用者は画面に名前が一または複数表示され、利用可能な会議室11の名前を確認できた時点、あるいは一定時間待っても名前が表示されない場合に利用可能な会議室11が無いものと判断し、処理を中断する。
【００２２】
利用者は、希望する規模(大、中、小)の、その時点で空いている会議室11の一覧を、会議室11まで行かずに携帯端末16で確認することができる。表示された会議室11の名前から会議室のおおよその場所がわかるので、そこへ移動することができる。
【００２３】
以上のように本発明によるサービス提供場所確認方式を用いることにより、ネットワーク上の通信を使用しない一般的なサービス(本実施例では会議室)の検索がネットワークにより可能になり、サービスの提供場所を、ネットワークアドレス以外の情報(本実施例では会議室名)で確認できるという効果がある。また、各サービス提供手段(会議室)ではサービスに関する情報(例えば会議室名、会議室の位置や会議室の規模)を持たずに問い合わせに答えられるという効果がある。
【００２４】
次に、本発明によるサービス提供場所確認方式の第二の実施例を、図６にしたがい説明する。本実施例でのサービス提供手段は、清涼飲料水を販売する自動販売機61である。特定の建物や施設(地下街やスタジアムなど)において、複数の自動販売機61が設置されている場合に、目的の清涼飲料水がどの自動販売機61で入手可能かネットワークを利用して検索可能にする。
【００２５】
本実施例のIPv6ネットワーク13は、清涼飲料水の自動販売機Ａ，Ｂ，Ｃ(61)および、DNSサーバ14、無線AP15を相互に接続して構成している。無線AP15と無線で通信できるIPv6端末も、このIPv6ネットワーク13に参加できる。携帯端末16がこのIPv6端末の例である。
【００２６】
本実施例のDNSサーバ14は第一実施例と同様に、名前とアドレスの対応を記録した名前テーブル31を持つ。図８に名前テーブル31の内容を示す。各自動販売機61はそれぞれ固有のIPv6ユニキャストアドレス(本実施例ではリンクローカルアドレス)を持ち、それらは全て対応する名前とともに名前テーブル31に登録されている。名前は、各自動販売機61の設置場所を表す名前が選ばれている(例えば「西口自動販売機」)。さらに名前テーブル31には、自動販売機61で販売されている清涼飲料水の種類ごとに、清涼飲料水の名前(例えばオレンジジュース)と対応するマルチキャストアドレスとが登録されている。マルチキャストアドレスは、清涼飲料水の種類ごとに固有で重複がないように管理者が決定する。
【００２７】
自動販売機61のブロック図を図７に示す。自動販売機61はIPv6ネットワーク13に接続するためのネットワークインターフェース23、マルチキャストアドレスを登録するマルチキャストアドレステーブル72、販売している清涼飲料水の種類ごとに残数を示す複数のカウンタ73を持つ。
【００２８】
カウンタ73は値として０または正の整数をとり、その値は対応する清涼飲料水の、自動販売機61に格納されている数と常に一致する。カウンタ73の値が０の場合対応する清涼飲料水は売り切れていることになる。
【００２９】
マルチキャストアドレステーブル72には、その自動販売機61で販売している清涼飲料水の種類に対応するマルチキャストアドレスが全て登録されている。清涼飲料水の種類とマルチキャストアドレスの対応関係は、DNSサーバ14の名前テーブル31に登録されている対応関係と一致させる。図１０にマルチキャストアドレステーブル72の例を示す。この例では、オレンジジュース、スポーツドリンク、緑茶に対応するマルチキャストアドレスが登録されている。
【００３０】
利用者は携帯端末16を利用して、希望する清涼飲料水の種類（たとえばスポーツドリンク）が購入可能な自動販売機61の場所を検索することが可能である。このときの携帯端末16における処理フローは第一実施例と同様である(図５)。利用者は携帯端末16に検索したい清涼飲料水の種類(例えばスポーツドリンク)を入力し、携帯端末16はDNSサーバ14に対して清涼飲料水の種類に対応するマルチキャストアドレスを問い合わせる。DNSサーバ14から回答されたアドレス(この場合マルチキャストアドレスＤ)に対してEcho Requestメッセージを送信する。
【００３１】
自動販売機61がEcho Requestメッセージを受信する場合の処理フローを図９に示す。自動販売機61は受信したEcho Requestメッセージの宛先アドレスを、マルチキャストアドレステーブル72から検索する(901)。マルチキャストアドレステーブル72にはその自動販売機61で販売している清涼飲料水に対応するマルチキャストアドレスが全て登録されている。Echo Requestメッセージの宛先アドレスがマルチキャストアドレステーブル72に登録されていない場合、利用者の希望する清涼飲料水をこの自動販売機61では販売していないことになるので、処理は終了する(902)。
【００３２】
該当するマルチキャストアドレスがある場合、そのマルチキャストアドレスに対応する清涼飲料水の残数を表すカウンタ73の番号をマルチキャストアドレステーブル72から取得し、その番号のカウンタ73の値を検査する(903)。カウンタ73の値が０であるならば、利用者の希望する清涼飲料水は売り切れているので処理を終了する(904)。カウンタ73の値が０より大きい場合、利用者の希望する清涼飲料水を少なくとも一つ販売可能であることになる。この場合、Echo Requestメッセージの送信元アドレス(この場合携帯端末16のアドレス)宛にEcho Replyメッセージを返信する(905)。
【００３３】
携帯端末16には、利用者の希望する清涼飲料水の種類を販売していて、かつその清涼飲料水が売り切れていない自動販売機61からのEcho Replyメッセージが届く。希望する清涼飲料水を販売している自動販売機61がない、あるいは全て売り切れている場合、Echo Replyメッセージは一つも返信されてこない。複数の自動販売機61が該当する清涼飲料水を販売し、かつ売り切れていない場合、複数のEcho Replyメッセージが携帯端末16に届く。
【００３４】
Echo Replyメッセージを受けた携帯端末16は、第一実施例と同様に、Echo Replyメッセージの送信元アドレス(例えばリンクローカルアドレス１)に対応する名前をDNSサーバ14に問い合わせ、回答された名前（この場合「西口自動販売機」）を画面に表示する。
【００３５】
以上のように本発明によるネットワークを用いたサービス提供場所検索方式を用いることで、利用者はネットワーク上の通信を使用しないサービス(本実施例では清涼飲料水の販売)をネットワークにより検索することが可能で、サービス提供場所がネットワークアドレス以外の情報(本実施例では自動販売機の名前)で確認できるという効果がある。また、各サービス提供手段（本実施例では自動販売機）は、マルチキャストアドレスと取り扱うサービスの種類(本実施例では清涼飲料水の種類)の対応をマルチキャストアドレステーブル72に登録するだけで、サービスの名称やサービス提供場所などを設定する必要がなく、一般的なプロトコルを用いてサービス提供場所を通知できるという効果がある。また、本実施例では第一実施例とは異なり、一つのサービス提供手段が複数の種類のサービスを扱うことが可能になっている。
【００３６】
次に本発明による第三の実施例を説明する。本実施例では、書類の収集作業に本発明を適用したものである。建物の各部署に書類回収ボックス112が設置され、定期的に書類回収ボックス112内の書類を回収する場合に、ネットワークを利用して回収すべき書類がある部署を事前に確認し、必要な部署にだけ回収に行くことを実現する。
【００３７】
図１１は本実施例におけるネットワークシステムを示している。各部署の書類回収ボックス112はIPv6ネットワーク13に接続されている。DNSサーバ14の名前テーブル31には各書類回収ボックス112に固有のアドレスと、その書類回収ボックス112が設置されている部署名との対応が登録されている(図１２)。
IPv6ネットワーク13にはさらにネットワーク端末111が接続されている。書類の回収担当者は、書類の回収に向かう前にネットワーク端末111から回収すべき書類のある部署を検索する。この場合の通信シーケンスは第一、第二実施例と同様であるが、検索対象が常に同じで、それに対応するマルチキャストアドレスも一定であるため、ネットワーク端末111にEcho Requestメッセージを送信するマルチキャストアドレスをあらかじめ設定しておけば、サービス名称に対応するマルチキャストアドレスをDNSサーバ14に問い合わせるシーケンス（図4の401、402）は省略可能である。したがって、DNSサーバ14の名前テーブル31にサービス名称とマルチキャストアドレスの対応を登録しなくてよい。
【００３８】
各部署の書類回収ボックス112は、書類のある回収ボックスを問い合わせるためのマルチキャストアドレス宛のEcho Requestメッセージのみを受信する。各部署の書類回収ボックス112は、回収すべき書類が書類回収ボックス112に入っている場合にのみ、Echo Requestメッセージに対してEcho Replyメッセージで応答する。書類回収ボックス112の具体的な実現方法としては、第一実施例の表示手段12(図２)において、ネットワークインターフェース23への電源投入を行なうスイッチ21が書類の有無と連動し、書類があるときだけネットワークインターフェース23へ電源が供給されるようにすればよい。そのためには、例えば書類の重量によりスイッチ21が押される仕組みや、光センサにより書類の有無を検出してスイッチ21を制御する方法、あるいは書類自体に微弱な電波を発信するICを埋め込み、電波の検出とスイッチ21が連動する方法などが考えられる。
【００３９】
書類回収ボックス112からのEcho Replyメッセージを受けたネットワーク端末112は、第一実施例の携帯端末16と同様に、Echo Replyメッセージの送信元アドレスに対応する部署名をDNSサーバ14に問い合わせる(図５、504)。DNSサーバ14から回答された部署名を画面に一覧表示するなどの手段で利用者に提示することで、利用者(書類の回収担当者)はどの部署に行く必要があるか事前に把握することが可能である。また、どの部署の書類回収ボックス112からもEcho Replyメッセージが返って来ない場合、回収に行く必要がないことがわかる。
【００４０】
以上のように、本発明によるネットワークを用いたサービス提供場所検索方式を用いることで、特定の条件を満たしている場所がネットワークアドレス以外の情報(本実施例では部署名)で確認できるという効果がある。さらに、本実施例のように回収に向かう必要がある場所全てを把握することが必要な場合でも、本発明によるサービス提供場所検索方式では問い合わせにマルチキャストを使うので、該当する場所が全て利用者に提示できるという効果がある。また、本実施例のように検索する対象が特定の一種類に限定される場合、DNSサーバ14にサービス名称を登録しなくても、検索を実行するネットワーク端末111にあらかじめ決めたマルチキャストアドレスを登録しておけばよい。
【００４１】
【発明の効果】
本発明は、ネットワークを使用しないで提供されるサービスの、サービス提供の有無とサービス提供場所をネットワークを利用して確認できるという効果がある。また、サービス提供手段にサービスの名称や位置情報を登録することなしに、サービス提供の有無と提供場所を通知可能にするという効果がある。
【図面の簡単な説明】
【図１】第一実施例のネットワーク構成図である。
【図２】第一実施例における表示手段のブロック図である。
【図３】第一実施例の名前テーブルである。
【図４】第一実施例の通信シーケンス図である。
【図５】第一実施例の携帯端末における検索処理フローである。
【図６】第二実施例のネットワーク構成図である。
【図７】第二実施例における自動販売機のブロック図である。
【図８】第二実施例の名前テーブルである。
【図９】第二実施例の自動販売機における応答処理フローである。
【図１０】第二実施例のマルチキャストアドレステーブルである。
【図１１】第三実施例のネットワーク構成図である。
【図１２】第三実施例の名前テーブルである。
【符号の説明】
12…表示手段
13…IPv6ネットワーク
14…DNSサーバ
16…携帯端末
21…スイッチ
23…ネットワークインターフェース
24…マルチキャストアドレス格納手段
31…名前テーブル
72…マルチキャストアドレステーブル
73…カウンタ
111…ネットワーク端末
112…書類回収ボックス
【図１】
2004200821.tif 000003
【図２】
2004200821.tif 000004
【図３】
2004200821.tif 000005
【図４】
2004200821.tif 000006
【図５】
2004200821.tif 000007
【図６】
2004200821.tif 000008
【図７】
2004200821.tif 000009
【図８】
2004200821.tif 000010
【図９】
2004200821.tif 000011
【図１０】
2004200821.tif 000012
【図１１】
2004200821.tif 000013
【図１２】
2004200821.tif 000014