(57)【要約】【課題】バージョンアップ用の情報を提供する側と提供を受ける側との双方の負荷を軽減し、確実かつ迅速にバージョンアップ用の情報をダウンロードできるようにする。【解決手段】アップデートサーバ１は、新たなアップデートファイルが存在する場合に、提供元通知部１０６が機能し、アップデートファイルの提供元を通知するための通知情報を形成し、所定の公衆電話機に回線Ｉ／Ｆ１０５を通じて提供する。アップデートサーバ１は、回線Ｉ／Ｆ１０５を通じてダウンロードの完了通知を受信すると、ダウンロード管理部が機能し、完了通知の送信元の公衆電話機をアップデートファイルの提供元として管理する。【選択図】図２
2014120045.tif 000002
【特許請求の範囲】
【請求項１】
配信管理サーバ装置と複数の通信端末装置とがネットワークを通じて接続されて構成される更新情報配信システムであって、
前記配信管理サーバ装置は、
通信手段と、
新たな更新情報が存在する場合に、少なくとも当該更新情報の提供元を通知する通知情報を形成し、前記通信手段を通じて所定の前記通信端末装置に提供する提供元通知手段と、
前記通信手段を通じて前記通信端末装置からのダウンロード処理が完了したことを示す完了通知を受信した場合に、必要に応じて当該完了通知の送信元の前記通信端末装置を前記更新情報の提供元に加える管理手段と
を備え、
前記通信端末装置は、
通信手段と、
前記通信手段を通じて前記通知情報を受信した場合に、指示された前記提供元に対して、前記更新情報の提供を要求する要求手段と、
前記更新情報の提供の要求に応じて前記提供元から提供される新たな前記更新情報を、前記通信手段を通じて受信して格納する更新処理手段と、
新たに提供された前記更新情報の全ての格納が完了した場合に、ダウンロード処理が完了したことを示す前記完了通知を形成し、前記通信手段を通じて前記配信管理サーバ装置に送信する完了通知手段と
を備えることを特徴とする更新情報配信システム。
【請求項２】
請求項１に記載の更新情報配信システムであって、
前記通知情報の提供先となる所定の前記通信端末装置は、更新情報の提供元となるべき通信端末装置として予め選択された１以上の通信端末装置であり、
前記配信管理サーバ装置の前記管理手段は、予め選択された１以上の前記通信端末装置を管理することを特徴とする更新情報配信システム。
【請求項３】
請求項１または請求項２のいずれかに記載の更新情報配信システムであって、
前記通知情報の提供先となる所定の前記通信端末装置は、更新の有無の確認要求を送信してきた通信端末装置であり、
前記配信管理サーバ装置の前記管理手段は、前記確認要求を送信してきた前記通信端末装置の更新情報のダウンロードの状況を管理できることを特徴とする更新情報配信システム。
【請求項４】
請求項１、請求項２または請求項３のいずれかに記載の更新情報配信システムであって、
前記配信管理サーバ装置は、
前記通信手段を通じて前記更新情報を取得できなかったことを示す失敗通知を受けた場合に、当該失敗通知の送信元の通信端末装置に対して他の提供元を通知する前記通知情報を形成し、前記通信手段を通じて提供する変更通知手段と、
前記通信手段を通じて前記更新情報を取得できなかったことを示す失敗通知を受けた場合に、当該失敗通知の送信元の通信端末装置に更新情報を提供できなかった更新情報の提供元を提供元から外し、他の通信端末装置を新たな提供元とする提供元入れ替え手段と、
を備え、
前記通信端末装置は、
前記更新情報の提供を要求した提供元から前記更新情報の提供を受けられなかった場合に、前記失敗通知を形成し、前記通信手段を通じて前記配信管理サーバ装置に送信する失敗通知手段を備えることを特徴とする更新情報配信システム。
【請求項５】
請求項１、請求項２、請求項３または請求項４のいずれかに記載の更新情報配信システムであって、
前記配信管理サーバ装置は、
少なくとも前記通信手段と、前記通知手段と、前記管理手段とを備える更新確認サーバと、
前記更新情報を蓄積し、当該更新情報の提供元の１つとなる１以上の更新情報提供サーバと
からなることを特徴とする更新情報配信システム。
【請求項６】
配信管理サーバ装置と複数の通信端末装置とがネットワークを通じて接続されて構成される更新情報配信システムの前記配信管理サーバ装置であって、
通信手段と、
新たな更新情報が存在する場合に、少なくとも当該更新情報の提供元を通知する通知情報を形成し、前記通信手段を通じて所定の前記通信端末装置に提供する提供元通知手段と、
前記通信手段を通じて前記通信端末装置からのダウンロード処理が完了したことを示す完了通知を受信した場合に、必要に応じて当該完了通知の送信元の前記通信端末装置を前記更新情報の提供元に加える管理手段と
を備えることを特徴とする配信管理サーバ装置。
【請求項７】
請求項６に記載の配信管理サーバ装置であって、
前記通知情報の提供先となる所定の前記通信端末装置は、更新情報の提供元となるべき通信端末装置として予め選択された１以上の通信端末装置であり、
前記管理手段は、予め選択された１以上の前記通信端末装置を管理することを特徴とする配信管理サーバ装置。
【請求項８】
請求項６または請求項７のいずれかに記載の配信管理サーバ装置であって、
前記通知情報の提供先となる所定の前記通信端末装置は、更新の有無の確認要求を送信してきた通信端末装置であり、
前記管理手段は、前記確認要求を送信してきた前記通信端末装置の更新情報のダウンロードの状況を管理できることを特徴とする配信管理サーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば、公衆電話機や電話システムの主装置などのネットワークに接続されて、プログラムのバージョンアップなどのためにアップデート（更新）が必要な通信端末装置に対してアップデート（更新）を行うためのシステム及びサーバ装置に関する。
【背景技術】
【０００２】
通信ネットワークには種々の通信端末装置が接続されており、これらの通信端末装置については機能強化等のためにプログラム等のバージョンアップが行われる場合がある。このため、通常、通信ネットワーク上にいわゆるバージョンアップサーバを設置しておく。そして、各通信端末装置は定期的にバージョンアップサーバに対してアップデートファイル（更新情報）の有無を確認し、アップデートファイルが存在する場合は、当該バージョンアップサーバからアップデートファイルのダウンロードを行う。
【０００３】
しかしながら、当該バージョンアップサーバにダウンロード要求が集中した場合には、当該バージョンアップサーバの帯域を圧迫してしまい、スムーズにアップデートファイルをダウンロードできなくなる場合がある。ダウンロード要求は、通信端末装置の増加に比例するため、バージョンアップサーバにアクセス可能な通信端末装置が多くなるほど、アップデートファイルのダウンロードに支障を来たす可能性も高くなる。また、アップデートファイルのスムーズなダウンロードが可能か否かは、用いられる通信回線の帯域（容量）も重要なファクターである。
【０００４】
このため、アップデートファイルの有無の確認を受け付けるサーバと、アップデートファイルを提供するサーバとを分離することによって、サーバの負荷の分散を図ることが行われている。また、アップデートファイルを提供するサーバを複数設置することで、アップデートファイルのダウンロードを分散して行うことが行われている。しかし、これでは、サーバの設置コストと保守費用とが増加する。このため、アップデートファイルを提供するサーバとして、無料で、あるいは、安価に第三者が提供している汎用的なものを使用することでクラウド化し、サーバの設置コストと保守費用の低減を図ることも考えられるが、セキュリティの面で不安が残る。
【０００５】
このような問題を解決するための１つの方策として、後に記す特許文献１には、送信装置から配信されたコンテンツを受信装置同士が相互に授受することにより、送信装置の処理負荷や必要とする出力帯域を軽減するシステム等に関する発明が開示されている。具体的には、当該特許文献１の図７や段落［００３５］等に記載されているように、受信装置は、蓄積すべきコンテンツのリストを送信装置または他の受信装置から受け取り、自身が保持していないコンテンツの実体は送信装置や他の受信装置から受け取る。すなわち、コンテンツのダウンロードに関しては、送信装置だけでなく、各受信装置もコンテンツの配信元となることができるようにしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−１１２１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述した特許文献１に記載の発明は、例えば、映画などの種々のコンテンツを配信するシステムである。そして、送信装置では各受信装置からの登録要求を受け付けて、登録要求を送信してきた受信装置の１台１台を管理する必要があるので、送信装置における受信装置を管理する負荷が大きい。また、コンテンツをダウンロードするか否か、また、どこからダウンロードするかは、提供されるリストに基づいてコンテンツの提供を受ける受信装置のそれぞれにおいて判別する。このため、各受信装置におけるコンテンツのダウンロードに関する負荷も大きいといえる。
【０００８】
また、上述したように、受信装置のそれぞれにおいては、目的とするコンテンツをどこからダウンロードするかを自機において特定する。したがって、目的とするコンテンツの提供元が少ない場合、特定の提供元（当該コンテンツを保持する送信装置や受信装置）に提供要求が集中してしまう可能性がある。このため、特許文献１に記載の発明は、映画などのコンテンツをダウンロードする場合のシステム等には好適であっても、受信装置のプログラム等のバージョンアップのためのアップデートには不向きである。すなわち、受信装置のプログラム等のバージョンアップのためのアップデートについては、より高い確実性、迅速性が求められる。
【０００９】
以上の点に鑑み、この発明は、バージョンアップ用の情報を提供する側と提供を受ける側との双方の負荷を軽減し、確実かつ迅速にバージョンアップ用の情報をダウンロードしてアップデートできるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、請求項１に記載の発明の更新情報配信システムは、
配信管理サーバ装置と複数の通信端末装置とがネットワークを通じて接続されて構成される更新情報配信システムであって、
前記配信管理サーバ装置は、
通信手段と、
新たな更新情報が存在する場合に、少なくとも当該更新情報の提供元を通知する通知情報を形成し、前記通信手段を通じて所定の前記通信端末装置に提供する提供元通知手段と、
前記通信手段を通じて前記通信端末装置からのダウンロード処理が完了したことを示す完了通知を受信した場合に、必要に応じて当該完了通知の送信元の前記通信端末装置を前記更新情報の提供元に加える管理手段と
を備え、
前記通信端末装置は、
通信手段と、
前記通信手段を通じて前記通知情報を受信した場合に、指示された前記提供元に対して、前記更新情報の提供を要求する要求手段と、
前記更新情報の提供の要求に応じて前記提供元から提供される新たな前記更新情報を、前記通信手段を通じて受信して格納する更新処理手段と、
新たに提供された前記更新情報の全ての格納が完了した場合に、ダウンロード処理が完了したことを示す前記完了通知を形成し、前記通信手段を通じて前記配信管理サーバ装置に送信する完了通知手段と
を備えることを特徴とする。
【００１１】
この請求項１に記載の発明の更新情報配信システムによれば、配信管理サーバ装置と複数の通信端末装置とからなる。配信管理サーバ装置は、通信手段を備え、新たな更新情報が存在する場合に、提供元通知手段が機能し、当該更新情報の提供元を通知するための通知情報を形成し、所定の通信端末装置に通信手段を通じて提供する。そして、配信管理サーバ装置は、通信手段を通じてダウンロード処理が完了したことを通知する完了通知を受信すると、管理手段が機能し、必要に応じて完了通知の送信元の通信端末装置を更新情報の提供元として管理する。
【００１２】
一方、通信端末装置のそれぞれは、通信手段を備え、当該通信手段を通じて配信管理サーバ装置から更新情報の提供元を通知する通知情報を受信すると、要求手段が、指示（通知）された提供元に対して更新情報の提供を要求する。そして、更新手段が、通信手段を通じて受信される当該提供元からの更新情報を格納して保持するように処理する。この後、更新情報の全部を正常に格納すると、完了通知手段が完了通知を形成し、通信手段を通じて配信管理サーバ装置に送信する。
【００１３】
このように、配信管理サーバ装置は、更新情報の提供を受けた通信端末装置を必要に応じて当該更新情報の配信元として管理できる。これにより、更新情報の提供元を分散させ、１つの提供元だけに大きな負荷がかかることを回避できる。
【発明の効果】
【００１４】
この発明によれば、バージョンアップ用の情報を提供する側と提供を受ける側との双方の負荷を軽減し、通信端末装置が確実かつ迅速にバージョンアップ用の情報をダウンロードできる。
【図面の簡単な説明】
【００１５】
【図１】この発明の更新情報配信システムの概要を説明するための図である。
【図２】アップデートサーバ１の構成例を説明するためのブロック図である。
【図３】ダウンロードサーバ２の構成例を説明するためのブロック図である。
【図４】提供元管理データファイル１０３の格納データの例を説明するための図である。
【図５】ダウンロード管理データファイル１０４の格納データの例を説明するための図である。
【図６】公衆電話機４の構成例を説明するためのブロック図である。
【図７】通知や要求のフォーマット例について説明するための図である。
【図８】更新情報配信システムの動作を説明するためのシーケンス図である。
【図９】更新情報配信システムの動作を説明するためのシーケンス図である。
【図１０】更新情報配信システムの動作を説明するためのシーケンス図である。
【図１１】提供元となる公衆電話機４が新たなアップデートファイルのダウンロードを行うようにするための処理を説明するためのフローチャートである。
【図１２】一般の公衆電話機４が新たなアップデートファイルのダウンロードを行うようにするための処理を説明するためのフローチャートである。
【発明を実施するための形態】
【００１６】
以下、図を参照しながら、この発明のシステム、装置の一実施の形態について説明する。この発明は、ネットワークに接続された種々の通信端末装置において、機能強化等のためにプログラム等のバージョンアップのためのアップデートを行う場合に利用可能なものである。つまり、ネットワークに接続された通信端末装置は種々のものが想定でき、その利用範囲は広い。しかし、以下に説明する実施の形態においては、説明を簡単にするため、ネットワークに接続された通信端末装置が、公共性が高く、迅速かつ確実にプログラム等のアップデート（更新）を行わなければならない公衆電話機である場合を例にして説明する。
【００１７】
［更新情報配信システムの概要］
図１は、この実施の形態の更新情報配信システムの概要を説明するための図である。図１に示すように、この実施の形態の更新情報配信システムは、アップデートサーバ１と、ダウンロードサーバ２と、街中の種々の場所に設置されている多数の公衆電話機４（１）、４（２）、…とがネットワーク３を通じて接続されて構成される。
【００１８】
アップデートサーバ１は、公衆電話機４（１）、４（２）、…に対してアップデートファイル（更新情報）を提供する提供元を管理し、公衆電話機４（１）、４（２）、…に対してアップデートファイルの提供元を通知する機能を有する。アップデートファイルは、例えば機能強化などのために、公衆電話機４（１）、４（２）、…に対して新たに提供する必要が生じたプログラムやデータなどからなる。また、アップデートサーバ１は、詳しくは後述するが、アップデートファイルの提供元とアップデートファイルの提供を要求してきた公衆電話機４（１）、４（２）、…とのアップデートファイルの提供の状況などを管理する機能をも有する。
【００１９】
ダウンロードサーバ２は、アップデートファイルの提供元の１つであり、アップデートファイルを提供する専用のサーバ装置として設けられる。なお、アップデートサーバ１とダウンロードサーバ２とを１つのサーバ装置として構成することももちろん可能である。しかし、この実施の形態においては、アップデートファイルの提供の管理と、アップデートファイルの提供とを異なるサーバ装置に分散させることにより、１つのサーバ装置に負荷が集中することを防止している。
【００２０】
ネットワーク３は、主にインターネットであるが、アップデートサーバ１やダウンロードサーバ２や公衆電話機４（１）、４（２）、…などからインターネットまでを接続する、例えば、公衆電話網（PSTN：Public Switched Telephone Networks）などを含む。そして、公衆電話機４（１）、４（２）、…のそれぞれは、街中の種々の場所に設置され、硬貨やテレホンカードの投入を受け付けて、相手先に電話を掛けて通話を行うものである。なお、公衆電話機４（１）、４（２）、…のそれぞれは、基本的に同様の構成を有し、同様に機能するものである。このため、以下においては、特に区別して示す場合を除き、公衆電話機４（１）、４（２）、…を総称して、公衆電話機４と記載する。
【００２１】
この実施の形態の更新情報配信システムにおいて、アップデートサーバ１は、新たなアップデートファイルが発生した場合に、アップデートファイルの提供元となるように予め決められた１以上の公衆電話機４に対して、アップデートファイルの提供元を通知する。この場合のアップデートファイルの提供元は、基本的にはネットワーク３上にアップデートファイルの専用の提供元として設けられているダウンロードサーバ２である。そして、当該提供元の通知を受けた公衆電話機４が、当該提供元からアップデートファイルをダウンロードすることにより、その公衆電話機４自身が当該アップデートファイルの提供元としてアップデートサーバ１で管理される。
【００２２】
また、アップデートサーバ１は、新たなアップデートファイルが存在するか否かを確認する更新チェックをしてきた公衆電話機４のそれぞれ毎に、新たに提供すべきアップデートファイルが存在する場合は、その提供元を通知する。この場合のアップデートファイルの提供元は、ダウンロードサーバ２やアップデートファイルの提供を受けてアップデートファイルの提供元としてアップデートサーバ１において管理されている公衆電話機４である。
【００２３】
ダウンロードサーバ２やアップデートファイルの提供を受けた公衆電話機４の内、どの機器をアップデートファイルの提供元として通知するかは、アップデートサーバ１によって決められる。すなわち、アップデートサーバ１は、自機で管理している現在のアップデートファイルのダウンロードの状況に応じて、帯域や処理能力に余裕のある提供元をアップデートファイルの提供元として選択し、更新チェック元の公衆電話機４に通知する。
【００２４】
このように、この実施の形態の更新情報配信システムにおいては、ダウンロードサーバ２だけでなく、予め決められた１以上の公衆電話機４もまた、アップデートファイルの提供元となる。これにより、アップデートファイルの提供元を分散し、公衆電話機４のそれぞれがアップデートファイルのダウンロードを確実かつ迅速に行うことができるようにしている。
【００２５】
また、アップデートファイルの提供元となった公衆電話機４が例えば故障するなどしてアップデートファイルの提供ができなくなる場合もあると考えられる。このため、アップデートファイルの提供元の通知を受けた公衆電話機４は、当該提供元からアップデートファイルの提供を受けられなかった場合には、失敗通知を形成し、これをアップデートサーバ１に送信する。
【００２６】
アップデートサーバ１は、アップデートファイルの提供元を通知した公衆電話機４から失敗通知を受信すると、当該公衆電話機４に対してアップデートファイルの他の提供元を通知し直す。また、アップデートサーバ１は、失敗通知を送信してきた公衆電話機４に対してアップデートファイルを提供できなかった提供元に替えて、アップデートファイルの提供を受けた他の公衆電話機４を提供元にする。すなわち、アップデートファイルの提供元を入れ替える。これにより、ダウンロードサーバ２以外に、アップデートファイルの提供元を常時一定台数確保し、アップデートファイルを効率よく提供できる環境を維持する。
【００２７】
そして、この実施の形態のアップデートサーバ１は、全ての公衆電話機４の状態を管理している必要はない。アップデートサーバ１は、アップデートファイルの提供元となるダウンロードサーバ２と予め決められた所定の公衆電話機４とを管理すると共に、更新チェックをしてきた公衆電話機４が現在どこからアップデートファイルの提供を受けているのかを管理する。これらの管理を通じて、アップデートサーバ１は、更新チェックをしてきた公衆電話機４に対して、アップデートファイルの提供元を適切に選択して通知する。これにより、アップデートファイルの提供元の通知を受けた公衆電話機４は、確実かつ迅速にアップデートファイルの提供を受け（ダウンロードし）、プログラム等のバージョンアップのためのアップデート（更新）を行うことができる。
【００２８】
［更新情報配信システムを構成する各機器の詳細］
次に、この実施の形態の更新情報配信システムを構成するアップデートサーバ１、ダウンロードサーバ２、公衆電話機４の構成例と動作について具体的に説明する。
【００２９】
［アップデートサーバ１の構成例］
図２は、この実施の形態のアップデートサーバ１の構成例を説明するためのブロック図である。制御部１０１は、アップデートサーバ１の各部を制御するものであり、図示しないが、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）がＣＰＵバスを通じて接続されて構成されたコンピュータ装置である。記憶装置１０２は、大容量記憶媒体であるハードディスクを備え、種々のプログラムや様々な処理により得られた種々のデータを当該ハードディスクに対して書き込んだり、当該ハードディスクに書き込んだデータを読み出したり、また、削除したりする処理を行う。
【００３０】
提供元管理データファイル１０３は、ハードディスクや不揮発性メモリに形成され、アップデートファイルの提供元となるダウンロードサーバ２や予め決められた１台以上の公衆電話機４に関する情報を記憶保持する。図４は、提供元管理データファイル１０３の格納データの例を説明するための図である。図４に示すように、提供元管理データファイル１０３には、アップデートファイルの提供元となる機器（ダウンロードサーバ２や公衆電話機４）のＭＡＣアドレス（Media Access Control address）、ＩＰアドレス（Internet Protocol address）、現在のアップデートファイルのバージョン、更新日、種別からなる。
【００３１】
図４において、ＭＡＣアドレス及びＩＰアドレスは、アップデートファイルの提供元の機器を一意に特定するための情報である。現在のアップデートファイルのバージョンは、各機器が提供可能なアップデートファイルのバージョンを示す情報である。また、更新日は、現在のアップデートファイルを更新した日付であり、種別は、当該機器がダウンロードサーバ２なのか公衆電話機４なのかを示す情報である。図４に示した例においては、１番目は、ダウンロードサーバ２についてのデータであり、２番目以降は、アップデートファイルの提供元になるように予め決められた公衆電話機４についての情報である。
【００３２】
そして、この実施の形態の更新情報配信システムのダウンロードサーバ２に新たなアップデートファイルが提供されて保持されたとする。この場合、アップデートサーバ１の制御部１０１は、例えば、ダウンロードサーバ２からの情報に基づいて、提供元管理データファイル１０３のダウンロードサーバ２についてアップデートファイルのバージョンと更新日を更新する。これにより、新たなアップデートファイルがダウンロードサーバ２に用意されたことがアップデートサーバ１において把握される。
【００３３】
そして、アップデートサーバ１は、詳しくは後述もするように、アップデートファイルの提供元となる所定の公衆電話機４に対してアップデートファイルの提供元を通知し、アップデートファイルのダウンロードを促す。そして、アップデートファイルの提供元が通知された公衆電話機４が、当該提供元から適切にアップデートファイルをダウンロードできたときには、当該公衆電話機４からダウンロードが完了したことを通知する完了通知がアップデートサーバ１に送信される。このため、アップデートサーバ１は、当該完了通知を受信すると、提供元管理データファイル１０３の完了通知を送信してきた公衆電話機４に対応するデータのアップデートファイルのバージョン情報と更新日とを更新する。これにより、どの公衆電話機４のアップデートファイルがアップデートされたかが管理できる。
【００３４】
ダウンロード管理データファイル１０４は、ハードディスクや不揮発性メモリに形成される。当該ダウンロード管理データファイル１０４は、更新チェックをしてきた公衆電話機４と当該公衆電話機４に対して通知したアップデートファイルの提供元とを管理すると共に、当該公衆電話機４おけるアップデートファイルのダウンロードの成否を管理する。図５は、ダウンロード管理データファイル１０４の格納データの例を説明するための図である。
【００３５】
図５に示すように、ダウンロード管理データファイル１０４は、更新チェックの要求元の機器のＭＡＣアドレス及びＩＰアドレスと、アップデートファイルの提供元の機器のＭＡＣアドレス及びＩＰアドレスとを管理する。さらに、ダウンロード管理データファイル１０４は、ダウンロード対象のアップデートファイルのバージョンを示す情報と、アップデートファイルのダウンロードの成否を示す情報とを管理する。
【００３６】
そして、図５に示した例の場合、ＭＡＣアドレスが「ｃｃｃｃｃ…」である公衆電話機４に対しては、ＭＡＣアドレスが「ＸＸＸＸＸ…」である機器がアップデートファイルの提供元として通知されたことが示されている。ここで、ＭＡＣアドレスが「ＸＸＸＸＸ…」である機器は、図４に示したようにダウンロードサーバ２である。また、ＭＡＣアドレスが「ｄｄｄｄｄ…」である公衆電話機４に対しては、同様に、ＭＡＣアドレスが「ＸＸＸＸＸ…」であるダウンロードサーバ２がアップデートファイルの提供元として通知されたことが示されている。また、これらについては、いずれも、ダウンロードサーバ２からバージョン２．０のアップデートファイルが適切にダウンロードできたこと（ダウンロードが成功したこと）が示しされている。
【００３７】
また、図５に示した例の場合、ＭＡＣアドレスが「ｍｍｍｍｍ…」である公衆電話機４に対しては、初めにＭＡＣアドレスが「ａａａａａ…」である公衆電話機４がアップデートファイルの提供元として通知されたことが示されている。ＭＡＣアドレスが「ａａａａａ…」である公衆電話機４は、図４に示したように、アップデートファイルの提供元となるように予め決められた公衆電話機４の１つである。そして、ＭＡＣアドレスが「ｍｍｍｍｍ…」である公衆電話機４は、ＭＡＣアドレスが「ａａａａａ…」である公衆電話機４から適切にバージョン２．０のアップデートファイルがダウンロードできなかったことが示されている。
【００３８】
そして、ＭＡＣアドレスが「ｍｍｍｍｍ…」である公衆電話機４に対しては、ＭＡＣアドレスが「ｂｂｂｂｂ…」である他の公衆電話機４がアップデートファイルの新たな提供元として通知されたことが示されている。ＭＡＣアドレスが「ｂｂｂｂｂ…」である公衆電話機４は、図４に示したように、アップデートファイルの提供元となるように予め決められた公衆電話機４の１つである。そして、ＭＡＣアドレスが「ｍｍｍｍｍ…」である公衆電話機４は、ＭＡＣアドレスが「ｂｂｂｂｂ…」である公衆電話機４から適切にバージョン２．０のアップデートファイルがダウンロードできたことが示されている。
【００３９】
このように、ダウンロード管理データファイル１０４のデータにより、どの公衆電話機４から更新チェックを受け付け、どの装置をアップデートファイルの提供元として通知したかを管理できる。さらに、ダウンロード管理データファイル１０４のデータにより、更新チェック元の公衆電話機４は、通知した提供元からアップデートファイルをダウンロードできたか否かをも適切に管理できる。
【００４０】
アップデートサーバ１の回線Ｉ／Ｆ１０５は、ネットワーク３を通じて受信した信号を自機（アップデートサーバ１）が処理可能なデータに変換して取り込んだり、送信用の種々のデータをプロトコルに準拠した信号に変換してネットワーク３に送出したりする。提供元通知部１０６は、制御部１０１の制御の下、回線Ｉ／Ｆ１０５を通じて、公衆電話機４に対してアップデートファイルの提供元を通知して、アップデートファイルのダウンロードを促す機能を実現する。
【００４１】
提供元通知部１０６は、新たなアップデートファイルがダウンロードサーバ２に用意された場合に、提供元管理データファイル１０３の情報に基づいて、所定の公衆電話機４にアップデートファイルの提供元を通知する。また、提供元通知部１０６は、更新チェックに応じてアップデートファイルの提供元を通知する場合には、提供元管理データファイル１０３とダウンロード管理データファイル１０４とのデータに応じて、適切に提供元を選択する。また、提供元通知部１０６は、公衆電話機４に提供元を通知した時には、ダウンロード管理データファイル１０４に新たなデータを登録し、ダウンロードの状況を管理できるようにする。
【００４２】
ダウンロード管理部１０７は、アップデートファイルの提供元を通知した公衆電話機４からのアップデートファイルのダウンロードの完了通知や失敗通知に応じて、提供元管理データファイル１０３やダウンロード管理データファイル１０４のデータを更新する。これにより、アップデートファイルの提供元を通知した公衆電話機４におけるアップデートファイルのダウンロードの状況を管理できるようにしている。
【００４３】
提供元変更通知部１０８は、アップデートファイルのダウンロードの失敗通知を送信してきた公衆電話機４に対して、アップデートファイルが適切に提供できなった提供元とは異なる他の提供元を通知する。これにより、失敗通知を送信してきた公衆電話機４ができるだけ迅速にアップデートファイルのダウンロードをできるようにしている。提供元入れ替え部１０９は、失敗通知を送信してきた公衆電話機４にアップデートファイルの提供元として通知した公衆電話機４を提供元から外し、他の公衆電話機４を新たに提供元にする処理を行なう。
【００４４】
具体的に、提供元入れ替え部１０９は、失敗通知を送信してきた公衆電話機４にアップデートファイルの提供元として通知した公衆電話機４についての提供元管理データファイル１０３で管理されているデータを削除する。そして、提供元入れ替え部１０９は、最新のアップデートファイルをダウンロードし終えた他の公衆電話機４に関するデータを提供元管理データファイル１０３に追加記録する。この場合、例えば、予め予備として位置付けられている１以上の公衆電話機４の中から特定した公衆電話機４や、失敗通知を送信してきたが、その後、他の公衆電話機４等からアップデートファイルの提供を受けた公衆電話機４などを新たな提供元することができる。
【００４５】
このように、アップデートサーバ１は、アップデートファイルの提供元を管理し、公衆電話機４に対して、アップデートファイルの提供元を通知すると共に、アップデートファイルの提供の状況などを管理する機能を有するものである。
【００４６】
［ダウンロードサーバ２の構成例］
図３は、この実施の形態のダウンロードサーバ２の構成例を説明するためのブロック図である。制御部２０１は、ダウンロードサーバ２の各部を制御するものであり、図示しないが、ＣＰＵ、ＲＯＭ、ＲＡＭがＣＰＵバスを通じて接続されて構成されたコンピュータ装置である。記憶装置２０２は、大容量記憶媒体であるハードディスクを備え、種々のプログラムや様々な処理により得られた種々のデータを当該ハードディスクに対して書き込んだり、当該ハードディスクに書き込んだデータを読み出したり、また、削除したりする処理を行う。記憶装置２０２には、公衆電話機４に提供するアップデートファイルも格納される。
【００４７】
外部Ｉ／Ｆ２０３は、種々の外部機器からのデータを、自機（ダウンロードサーバ２）で処理可能な形式のデータに変換して取り込んだり、自機からのデータを外部機器に提供する形式のデータに変換して出力したりする機能を実現する。この外部Ｉ／Ｆ２０３を通じて、外部機器からアップデートファイルの提供を受け、制御部２０１が当該アップデートファイルを記憶装置２０２に記憶する処理が行われる。
【００４８】
回線Ｉ／Ｆ２０４は、ネットワーク３を通じて受信した信号を自機（ダウンロードサーバ２）が処理可能なデータに変換して取り込んだり、送信用の種々のデータをプロトコルに準拠した信号に変換してネットワーク３に送出したりする。なお、アップデートファイルは、外部Ｉ／Ｆ２０３を通じて提供されるものとして説明したが、これに限るものではない。アップデートファイルは、ネットワーク３を通じてダウンロードサーバ２に送信され、回線Ｉ／Ｆ２０４を通じて受信されて、制御部２０１により記憶装置２０２に記録される場合もある。
【００４９】
アップデートファイル提供部２０５は、回線Ｉ／Ｆ２０４を通じて、公衆電話機４からのアップデートファイルの提供要求を受信した場合に、アップデートファイルを提供する処理を行う。具体的にアップデートファイル提供部２０５は、制御部２０１の制御の下、記憶装置２０２からアップデートファイルを読み出して、回線Ｉ／Ｆ２０４を通じて、要求元の公衆電話機４に対してアップデートファイルを提供する処理を実行する。
【００５０】
このように、ダウンロードサーバ２は、ネットワーク３上に設けられ、アップデートファイルを公衆電話機４に提供する機能を実現する専用のサーバ装置である。
【００５１】
［公衆電話機４の構成例］
図６は、この実施の形態の公衆電話機４の構成例を説明するためのブロック図である。制御部４０１は、公衆電話機４の各部を制御するものであり、図示しないが、ＣＰＵ、ＲＯＭ、ＲＡＭがＣＰＵバスを通じて接続されて構成されたコンピュータ装置である。記憶装置４０２は、大容量記憶媒体であるハードディスクあるいは不揮発性メモリを備え、種々のプログラムや様々な処理により得られた種々のデータを当該記録媒体に対して書き込んだり、書き込んだデータを読み出したり、また、削除したりする処理を行う。
【００５２】
操作部４０３は、公衆電話機４に設けられたいわゆるテンキーや音量の調整キーなどの幾つかのファンクションキーなどからなり、ユーザーからの操作入力を受け付けて、受け付けた情報を制御部４０１に供給する。表示部４０４は、例えばＬＣＤ（Liquid Crystal Display）などの表示素子を備え、種々のガイダンス情報や警告メッセージなどを表示する。課金処理部４０５は、利用者が投入したプリペイドカードや硬貨を取り込む機能と、ネットワーク３からの課金信号に応じて課金処理を行う機能と、オンフック操作に応じて、プリペイドカードや投入過剰分の硬貨を返却する機能を有する。
【００５３】
ダイヤル回路４０６は、制御部４０１が操作部４０３を通じて受け付けた制御部４０１からのダイヤル番号に基づいてダイヤル信号を生成し、後述する回線Ｉ／Ｆ４０７を介してネットワーク３にダイヤル信号を送出する。このダイヤル信号は、ネットワーク３に接続された電話会社の交換器に送信される。回線Ｉ／Ｆ４０７は、ネットワーク３を通じて受信した信号を自機（公衆電話機４）が処理可能なデータに変換して取り込んだり、送信用の種々のデータをプロトコルに準拠した信号に変換してネットワーク３に送出したりする。
【００５４】
通話回路４０８は、回線Ｉ／Ｆ４０７を通じて受信した音声データ（デジタル信号）から音声信号（アナログ信号）を形成し、これをハンドセット４０９に供給する。また、通話回路４０８は、ハンドセット４０９からの音声信号（アナログ信号）を音声データ（デジタル信号）に変換し、これを回線Ｉ／Ｆ４０７を通じてネットワーク３に送信する。ハンドセット４０９は、スピーカ（受話器）とマイクロホン（送話器）とを備え、通話回路４０８からの音声信号をスピーカに供給して放音し、また、マイクロホンで集音した音声信号を通話回路４０８に供給する。そして、公衆電話機４において、回線Ｉ／Ｆ４０７は、音声データについては通話回路４０８との間で送受し、ダイヤル信号以外の制御データやアップデートファイルは制御部４０１との間で送受する。
【００５５】
また、要求処理部４１０は、制御部４０１の制御の下、ダウンロードサーバ２に対するアップデートファイルのダウンロード要求やアップデートサーバ１に対する更新チェックの要求を形成し、これを回線Ｉ／Ｆ４０７を通じてネットワーク３に送信する。更新処理部４１１は、制御部４０１の制御の下、回線Ｉ／Ｆ４０７を通じてアップデートファイルを受信した場合に、これを記憶装置４０２に格納する処理を実行する。
【００５６】
完了通知部４１２は、制御部４０１の制御の下、アップデートファイルの全部を正常に記憶装置４０２に格納し終えた場合に、適切にダウンロードが完了したことを通知する完了通知を形成し、これを回線Ｉ／Ｆ４０７を通じてアップデートサーバ１に送信する。失敗通知部４１３は、制御部４０１の制御の下、アップデートファイルのダウンロードが失敗した場合に、アップデートファイルのダウンロードが失敗したことを通知する失敗通知を形成し、これを回線Ｉ／Ｆ４０７を通じてアップデートサーバ１に送信する。
【００５７】
このように、公衆電話機４は、不特定多数のユーザーに使用され、目的とする相手先との間に電話回線を接続して通話を行えるようにするものである。さらに、この実施の形態の公衆電話機４は、機能強化などのために、プログラムのアップデートを、ユーザーの手を介すことなく、自動的に行うことができるものである。
【００５８】
［機器間で送受される通知や要求などの例］
図７は、この実施の形態の更新情報配信システムにおいて、アップデートサーバ１と公衆電話機４との間で送受される通知や要求のフォーマット例について説明するための図である。この実施の形態の更新情報提供システムにおいては、基本的には、データ区分、情報１、情報２という３つの項目からなるごく簡単なフォーマットの情報を送受する。なお、図７においては、説明を簡単にするため、送信先を特定するための情報等については省略している。
【００５９】
そして、例えば、アップデートサーバ１から所定の公衆電話機４へのアップデートファイルの提供元の通知情報は、図７（Ａ）に示すものとなる。すなわち、当該通知情報は、データ区分が「提供元通知」であることを示し、情報１が「アップデートファイルのバージョン情報」を示し、情報２が提供元を特定するための「提供元識別情報」を示すものとなる。なお、「提供元識別情報」は、提供元の機器のＭＡＣアドレス及びＩＰアドレスが用いられる。当該通知情報により、何処の機器からバージョンがいくつのアップデートファイルをダウンロードすればよいかが特定できる。
【００６０】
また、公衆電話機４からアップデートファイルの提供元へのダウンロード要求は、図７（Ｂ）に示すものとなる。すなわち、当該ダウンロード要求は、データ区分が「ダウンロード要求」であることを示し、情報１が当該ダウンロード要求の送信元を特定するための「送信元識別情報」を示し、情報２が「空き」となるものである。なお、図７（Ｂ）、（Ｃ）、（Ｄ）、（Ｅ）において、「送信元識別情報」は、送信元の機器のＭＡＣアドレス及びＩＰアドレスが用いられる。当該ダウンロード要求により、アップデートファイルの提供元の機器において、何処の機器がアップデートファイルの提供を要求しているのかを特定でき、当該要求元（ダウンロード要求の送信元）の機器に対してアップデートファイルの提供を行うことができる。
【００６１】
また、公衆電話機４からアップデートサーバ１への完了通知は、図７（Ｃ）に示すものとなる。すなわち、当該完了通知は、データ区分が「完了通知」であることを示し、情報１が完了通知の送信元を特定するための「送信元識別情報」を示し、情報２が「空き」となるものである。当該完了通知により、アップデートサーバ１において、何処の機器がアップデートファイルのダウンロードを正常に完了したのかを把握できる。
【００６２】
また、公衆電話機４からアップデートサーバ１への更新チェックの要求は、図７（Ｄ）に示すものとなる。すなわち、当該更新チェックの要求は、データ区分が「更新チェック」であることを示し、情報１が更新チェックの要求の送信元を特定するための「送信元識別情報」を示し、情報２が送信元において現在適用されている「アップデートファイルのバージョン情報」となる。
【００６３】
当該更新チェックの要求により、アップデートサーバ１において、何処の公衆電話機４から更新チェックの要求が来て、その公衆電話機４のダウンロード済みのアップデートファイルのバージョン情報はいくつかを把握できる。したがって、アップデートサーバ１においては、更新チェックの要求を送信してきた機器において、アップデートファイルのダウンロードが必要か否かを判別し、必要な場合にはアップデートファイルの提供元を通知できる。
【００６４】
また、公衆電話機４からアップデートサーバ１への失敗通知は、図７（Ｅ）に示すものとなる。すなわち、当該失敗通知は、データ区分が「失敗通知」であることを示し、情報１が送信元を特定するための「送信元識別情報」を示し、情報２が「空き」となるものである。当該失敗通知により、アップデートサーバ１において、何処の機器がアップデートファイルのダウンロードに失敗したのかを把握できる。
【００６５】
［更新情報配信システムの動作］
図８〜図１０は、この実施の形態の更新情報配信システムの動作を説明するためのシーケンス図である。この実施の形態では説明を簡単にするため、図８の上端側に示すように、★印が付されている公衆電話機４（１）、４（２１）、…が、アップデートファイルの提供元になる公衆電話機４としてアップデートサーバ１で管理されているものとする。
【００６６】
そして、ダウンロードサーバ２には、バージョン２．０のアップデートファイルが用意され、アップデートサーバ１においては、新たなアップデートファイルがダウンロードサーバ２に存在することが把握されているものとする。そして、公衆電話機４（１）、４（２）、…のそれぞれは、バージョン１．０（Ｖｅｒ１．０）のアップデートファイルが適用されているが、バージョン２．０（Ｖｅｒ２．０）の適用はまだである状態にあることが示されている。
【００６７】
したがって、この場合、アップデートサーバ１の提供元管理データファイル１０３では、図４に示したように、ダウンロードサーバ２だけが最新のバージョン２．０のアップデートファイルを保持している。しかし、他の提供元となる公衆電話機４は古いバージョン１．０のアップデートファイルしか保持していない状態となっている。
【００６８】
このため、アップデートサーバ１は、図７（Ａ）に示した提供元通知を形成し、新しいアップデートファイルが存在し、その提供元がダウンロードサーバ２であることを、提供元になるべき公衆電話機４（１）、４（２１）、…に通知する（ステップＳ１）。当該提供元通知を受けた公衆電話機４（１）は、図７（Ｂ）に示したダウンロード要求を形成し、これを、通知された提供元であるダウンロードサーバ２に送信する（ステップＳ２）。
【００６９】
ダウンロードサーバ２では、公衆電話機４（１）からのダウンロード要求に応じて、バージョン２．０のアップデートファイルを当該公衆電話機４（１）に送信する（ステップＳ３）。これにより、要求元の公衆電話機４（１）では、バージョン２．０のアップデートファイルを受信して記憶装置４０２に格納する（ステップＳ４）。そして、要求元の公衆電話機４（１）は、バージョン２．０のアップデートファイルの全てを適切に受信し、記憶装置４０２に格納できたときには、図７（Ｃ）に示した完了通知を形成し、これをアップデートサーバ１に送信する（ステップＳ５）
この場合、アップデートサーバ１は、公衆電話機４（２１）からの完了通知により、バージョン２．０のアップデートファイルのダウンロードが完了したことが把握できる。このため、アップデートサーバ１では、提供元管理データファイル１０３の公衆電話機４（１）のデータのアップデートファイルのバージョンと更新日とを更新する。これにより、公衆電話機４（１）が、バージョン２．０のアップデートファイルの提供元となるようにされる。
【００７０】
同様に、提供元通知を受けた公衆電話機４（２１）は、図７（Ｂ）に示したダウンロード要求を形成し、これを、通知された提供元であるダウンロードサーバ２に送信する（ステップＳ６）。ダウンロードサーバ２では、公衆電話機４（２１）からのダウンロード要求に応じて、バージョン２．０のアップデートファイルを当該公衆電話機４（２１）に送信する（ステップＳ７）。これにより、要求元の公衆電話機４（２１）では、バージョン２．０のアップデートファイルを受信して記憶装置４０２に格納する（ステップＳ８）。そして、要求元の公衆電話機４（２１）は、バージョン２．０のアップデートファイルの全てを適切に受信し、記憶装置４０２に格納できたときには、図７（Ｃ）に示した完了通知を形成し、これをアップデートサーバ１に送信する（ステップＳ９）
この場合、アップデートサーバ１は、公衆電話機４（１）からの完了通知により、バージョン２．０のアップデートファイルのダウンロードが完了したことが把握できる。このため、アップデートサーバ１では、提供元管理データファイル１０３の公衆電話機４（２１）のデータのアップデートファイルのバージョンと更新日とを更新する。これにより、公衆電話機４（２１）が、バージョン２．０のアップデートファイルの提供元となるようにされる。
【００７１】
このようにして、アップデートサーバ１は、アップデートファイルの提供元となるべき予め決められた公衆電話機４（１）、４（２１）、…に対して、新たなアップデートファイルの所在を通知する。そして、予め決められた公衆電話機４（１）、４（２１）、…のそれぞれが、通知された提供元からアップデートファイルを取得し、新たなアップデートファイルの提供元として機能するように環境が整えられる。
【００７２】
そして、アップデートファイルの提供元として予め決められた公衆電話機４（１）、４（２１）、…以外の公衆電話機４は自機からアップデートサーバ１に対して更新チェックを行う。例えば、公衆電話機４（２）は、図９に示すように、所定のタイミングで、図７（Ｄ）に示した更新チェックの要求を形成し、これをアップデートサーバ１に送信する（ステップＳ１１）。ここで、更新チェックを行う所定のタイミングは、１日に１回、３日に１回、５日に１回、１週間に１回などといった適宜のタイミングである。
【００７３】
更新チェックの要求を受け付けたアップデートサーバ１は、この例では要求元の公衆電話機４（２）からの更新チェックに含まれる送信元のバージョン情報が示すアップデートファイルよりも新しいアップデートファイルが存在するか否かを確認する。そして、新しいアップデートファイルが存在する場合には、提供元管理データファイル１０３のデータとダウンロード管理データファイル１０４とのデータに基づいて、アップデートファイルの提供元を特定する。
【００７４】
この場合、アップデートサーバ１は、現在、複数の公衆電話機４に対してアップデートファイルの提供元になっており、負荷が高くなっている提供元は外し、帯域及び処理能力に余裕のある提供元を通知すべき提供元として特定する。そして、アップデートサーバ１は、図７（Ａ）に示した提供元通知を、受信した更新チェックに対するレスポンスとして形成し、これを要求元の公衆電話機４（２）に送信する。
【００７５】
図９に示す例の場合、アップデートサーバ１は、公衆電話機４（２）からの更新チェック（ステップＳ１１の処理）に対して、バージョン２．０のアップデートファイルが存在し、ダウンロードサーバ２が提供元になることを公衆電話機４（２）に通知している（ステップＳ１２）。この時、アップデートサーバ１では、図５を用いて説明したダウンロード管理データファイル１０４で、更新チェックの要求元とアップデートファイルの提供元とを管理すると共に、当該要求元おけるアップデートファイルのダウンロードの成否をも管理する。
【００７６】
この例では、更新チェックの要求元が公衆電話機４（２）であり、アップデートファイルの提供元がダウンロードサーバ２であり、提供すべきアップデートファイルのバージョンがＶｅｒ２．０であることがダウンロード管理データファイル１０４で管理される。
【００７７】
そして、当該レスポンス（提供元通知）を受けた公衆電話機４（２）は、図７（Ｂ）に示したダウンロード要求を形成し、これを通知された提供元であるダウンロードサーバ２に送信する（ステップＳ１３）。ダウンロードサーバ２では、公衆電話機４（２）からのダウンロード要求に応じて、バージョン２．０のアップデートファイルを当該公衆電話機４（２）に送信する（ステップＳ１４）。
【００７８】
要求元の公衆電話機４（２）では、バージョン２．０のアップデートファイルを受信して記憶装置４０２に格納する（ステップＳ１５）。要求元の公衆電話機４（２）は、バージョン２．０のアップデートファイルの全てを適切に受信し、記憶装置４０２に格納できたときには、図７（Ｃ）に示した完了通知を形成し、これをアップデートサーバ１に送信する（ステップＳ１６）。
【００７９】
この場合、アップデートサーバ１は、公衆電話機４（２）からの完了通知により、バージョン２．０のアップデートファイルのダウンロードが完了したことが把握できる。このため、アップデートサーバ１では、ダウンロード管理データファイル１０４の公衆電話機４（２）のデータのダウンロードの成否の欄にダウンロードが成功したことを示す情報を更新する。
【００８０】
また、アップデートファイルの提供元ではない一般の公衆電話機４（１１）が、図９に示すように、所定のタイミングで、図７（Ｄ）に示した更新チェックの要求を形成し、これをアップデートサーバ１に送信する（ステップＳ１７）。更新チェックの要求を受け付けたアップデートサーバ１は、公衆電話機４（１１）に提供すべき新しいアップデートファイルが存在するかを確認する。そして、存在する場合、アップデートサーバ１は、提供元管理データファイル１０３のデータとダウンロード管理データファイル１０４とのデータに基づいて、アップデートファイルの提供元を特定する。
【００８１】
そして、アップデートサーバ１は、図７（Ａ）に示した提供元通知を、更新チェックに対するレスポンスとして形成し、これを要求元の公衆電話機４（１１）に送信する。図９に示す例の場合、アップデートサーバ１は、公衆電話機４（１１）からの更新チェックに対して、バージョン２．０のアップデートファイルが存在し、公衆電話機４（１）が提供元になることを公衆電話機４（１１）に通知している（ステップＳ１８）。
【００８２】
すなわち、通常、ダウンロードサーバ２がアップデートファイルの提供元になる場合であっても、ダウンロードサーバ２が多数の公衆電話機４にアップデートファイルを提供しているなどして負荷が大きくなっているとする。このような状態は、アップデートサーバ１において、提供元通知の送信状態やダウンロード管理データファイル１０４の格納データに基づいて判別可能である。
【００８３】
このような場合、アップデートサーバ１は、アップデートファイルの提供元として管理している公衆電話機４であって、帯域や処理能力に余裕のある公衆電話機４をアップデートファイルの提供元として特定する。そして、アップデートサーバ１では、図５を用いて説明したダウンロード管理データファイル１０４で、更新チェックの要求元とアップデートファイルの提供元とを管理すると共に、当該要求元おけるアップデートファイルのダウンロードの成否をも管理する。
【００８４】
この例では、更新チェックの要求元が公衆電話機４（１１）であり、アップデートファイルの提供元が公衆電話機４（１）であり、提供すべきアップデートファイルのバージョンがＶｅｒ２．０であることがダウンロード管理データファイル１０４で管理される。
【００８５】
そして、当該レスポンス（提供元通知）を受けた公衆電話機４（１１）は、図７（Ｂ）に示したダウンロード要求を形成し、これを通知された提供元である公衆電話機４（１）に送信する（ステップＳ１９）。公衆電話機４（１）では、公衆電話機４（１１）からのダウンロード要求に応じて、バージョン２．０のアップデートファイルを当該公衆電話機４（１１）に送信する（ステップＳ２０）。
【００８６】
要求元の公衆電話機４（１１）では、公衆電話機４（１）からのバージョン２．０のアップデートファイルを受信して記憶装置４０２に格納する（ステップＳ２１）。要求元の公衆電話機４（１１）は、バージョン２．０のアップデートファイルの全てを適切に受信し、記憶装置４０２に格納できたときには、図７（Ｃ）に示した完了通知を形成し、これをアップデートサーバ１に送信する（ステップＳ２２）。
【００８７】
この場合、アップデートサーバ１は、公衆電話機４（１１）からの完了通知により、バージョン２．０のアップデートファイルのダウンロードが完了したことが把握できる。このため、アップデートサーバ１では、ダウンロード管理データファイル１０４の公衆電話機４（１１）のデータのダウンロードの成否の欄にダウンロードが成功したことを示す情報を更新する。
【００８８】
また、アップデートファイルの提供元ではない一般の公衆電話機４（１２）が、図１０に示すように、所定のタイミングで、図７（Ｄ）に示した更新チェックの要求を形成し、これをアップデートサーバ１に送信する（ステップＳ２３）。更新チェックの要求を受け付けたアップデートサーバ１は、公衆電話機４（１２）に提供すべき新しいアップデートファイルが存在するかを確認する。そして、存在する場合、アップデートサーバ１は、上述もしたように、提供元管理データファイル１０３のデータとダウンロード管理データファイル１０４とのデータに基づいて、アップデートファイルの提供元を特定する。
【００８９】
そして、アップデートサーバ１は、図７（Ａ）に示した提供元通知を、更新チェックに対するレスポンスとして形成し、これを要求元の公衆電話機４（１２）に送信する。図９に示す例の場合、アップデートサーバ１は、公衆電話機４（１２）からの更新チェックに対して、バージョン２．０のアップデートファイルが存在し、公衆電話機４（１）が提供元になることを公衆電話機４（１２）に通知している（ステップＳ２４）。
【００９０】
そして、アップデートサーバ１では、図５を用いて説明したダウンロード管理データファイル１０４で、更新チェックの要求元とアップデートファイルの提供元とを管理すると共に、当該要求元おけるアップデートファイルのダウンロードの成否をも管理する。この例では、更新チェックの要求元が公衆電話機４（１２）であり、アップデートファイルの提供元が公衆電話機４（１）であり、提供すべきアップデートファイルのバージョンがＶｅｒ２．０であることがダウンロード管理データファイル１０４で管理される。
【００９１】
そして、当該レスポンス（提供元通知）を受けた公衆電話機４（１２）は、図７（Ｂ）に示したダウンロード要求を形成し、これを通知された提供元である公衆電話機４（１）に送信する（ステップＳ２５）。しかし、公衆電話機４（１）からアップデートファイルが提供されないために、所定回（例えば、５回）、ダウンロード要求を公衆電話機４（１）に送信しても、アップデートファイルの提供を受けられなかったとする。この場合、公衆電話機４（１２）は、図７（Ｅ）に示した失敗通知を形成し、これをアップデートサーバ１に送信する（ステップＳ２６）。
【００９２】
この場合、アップデートサーバ１は、公衆電話機４（１２）からの失敗通知により、公衆電話機４（１２）はバージョン２．０のアップデートファイルのダウンロードに失敗したことが把握できる。このため、アップデートサーバ１では、ダウンロード管理データファイル１０４の公衆電話機４（１２）のデータのダウンロードの成否の欄にダウンロードが失敗したことを示す情報を更新する。
【００９３】
さらに、公衆電話機４（１２）からの失敗通知を受信したアップデートサーバ１は、提供元管理データファイル１０３とダウンロード管理データファイル１０４のデータに基づき、公衆電話機４（１）に替えてアップデートファイルの他の提供元を特定する。そして、アップデートサーバ１は、図７（Ａ）に示した提供元通知を、失敗通知に対するレスポンスとして形成し、これを要求元の公衆電話機４（１２）に送信する。図９に示す例の場合、アップデートサーバ１は、公衆電話機４（１２）からの失敗通知に対して、バージョン２．０のアップデートファイルを有する公衆電話機４（２１）をアップデートファイルの新たな提供元として公衆電話機４（１２）に通知している（ステップＳ２７）。
【００９４】
そして、アップデートサーバ１では、図５を用いて説明したダウンロード管理データファイル１０４で、新たに失敗通知の送信元（要求元）とアップデートファイルの提供元とを管理する。そして、当該失敗通知の送信元におけるアップデートファイルのダウンロードの成否をも管理する。この例では、失敗通知の送信元（要求元）が公衆電話機４（１２）であり、アップデートファイルの提供元が公衆電話機４（２１）であり、提供すべきアップデートファイルのバージョンがＶｅｒ２．０であることがダウンロード管理データファイル１０４で管理される。
【００９５】
この後、失敗通知の送信元である公衆電話機４（１２）では、新たに通知されたアップデートファイルの提供元である公衆電話機４（２１）に対して、ダウンロード要求を送信する（ステップＳ２８）。新たな提供元とされた公衆電話機４（２１）では、公衆電話機４（１２）からのダウンロード要求に応じて、バージョン２．０のアップデートファイルを当該公衆電話機４（１２）に送信する（ステップＳ２９）。
【００９６】
要求元の公衆電話機４（１２）では、バージョン２．０のアップデートファイルを受信して記憶装置４０２に格納する（ステップＳ３０）。要求元の公衆電話機４（１２）は、バージョン２．０のアップデートファイルの全てを適切に受信し、記憶装置４０２に格納できたときには、図７（Ｃ）に示した完了通知を形成し、これをアップデートサーバ１に送信する（ステップＳ３１）。
【００９７】
この場合、アップデートサーバ１は、公衆電話機４（１２）からの完了通知により、バージョン２．０のアップデートファイルのダウンロードが完了したことが把握できる。このため、アップデートサーバ１では、ダウンロード管理データファイル１０４の公衆電話機４（１２）のデータのダウンロードの成否の欄にダウンロードが成功したことを示す情報を更新する。
【００９８】
このようにして、更新チェックを送信してきた公衆電話機４が、通知されたアップデートファイルの提供元からアップデートファイルの提供を受けられなかった場合には、アップデートサーバ１はアップデートファイルの他の提供元を当該公衆電話機４に通知する。これにより、公衆電話機４が、通知された提供元からアップデートファイルのダウンロードができなかった場合であっても、他の提供元の通知をさらに受けて、アップデートファイルを確実にダウンロード（取得）することができる。
【００９９】
［アップデートサーバ１の処理］
次に、この実施の形態の更新情報配信システムにおいて、アップデートファイルの配信を制御するアップデートサーバ１の動作の詳細について、図１１、図１２のフローチャートを参照しながら説明する。
【０１００】
［アップデートファイルの提供元となる予め決められた公衆電話機４に対する処理］
図１１は、アップデートファイルの提供元となる予め決められた公衆電話機４が新たなアップデートファイルのダウンロードを行うようにするための処理を説明するためのフローチャートである。この実施の形態において、アップデートサーバ１の制御部１０１は、ダウンロードサーバ２から新たなアップデートファイルが用意されたことの通知を受け付けると、図１１に示す処理を実行する。
【０１０１】
そして、制御部１０１は、アップデートファイルの提供元となるように、予め決められた公衆電話機４に対して、アップデートファイルの提供元を通知し（ステップＳ１０１）、新たなアップデートファイルのダウンロードを促す。具体的に、アップデートサーバ１の制御部１０１は、提供元通知部１０６を制御してアップデートファイルの提供元がダウンロードサーバ２となる図７（Ａ）に示した構成の提供元通知を形成する。そして、制御部１０１は、当該提供元通知を回線Ｉ／Ｆ１０５を通じて、提供元管理データファイル１０３の格納データに基づいて、アップデートファイルの提供元となる予め決められた全ての公衆電話機４に対して送信する。
【０１０２】
そして、アップデートサーバ１の制御部１０１は、回線Ｉ／Ｆ１０５を通じて、ステップＳ１０１で提供元通知を送信した公衆電話機４からの応答を受信する（ステップＳ１０２）。制御部１０１は、ステップＳ１０２において、アップデートファイルの提供元となるように予め決められた公衆電話機４からの応答を受信したか否かを判別する（ステップＳ１０３）。ステップＳ１０３の判別処理において、応答を受信していないと判別した時には、ステップＳ１０２からの処理を繰り返す。
【０１０３】
また、ステップＳ１０３の判別処理において、提供元となるように予め決められた公衆電話機４からの応答を受信したと判別した時には、受信した応答はアップデートファイルのダウンロードが終了したことを示す完了通知か否かを判別する（ステップＳ１０４）。ステップＳ１０４の判別処理において、完了通知を受信したと判別したとする。この場合、制御部１０１は、提供元管理データファイル１０３で管理されている、当該完了通知を送信してきた公衆電話機４の管理データのアップデートファイルのバージョン情報と更新日とを更新する（ステップＳ１０５）。
【０１０４】
この後、アップデートサーバ１の制御部１０１は、アップデートファイルの提供元となるように予め決められた全ての公衆電話機４において、新たなアップデートファイルのダウンロードが終了したか否かを判別する（ステップＳ１０６）。この場合、制御部１０１は、提供元管理データファイル１０３で管理されているデータに基づいて、予め決められた公衆電話機４において、新たなアップデートファイルのダウンロードが完了したか否かを判別できる。
【０１０５】
そして、ステップＳ１０６の判別処理において終了したと判別したときには、図１１に示す処理を終了して、次の実行タイミングを待つようにする。また、ステップ１０６の判別処理において、終了していないと判別したときには、ステップＳ１０２からの処理を繰り返す。また、ステップＳ１０４の判別処理において、受信した応答は完了通知ではないと判別したとする。この場合、受信した応答は、失敗通知であるので、制御部１０１は、提供元通知部１０６を制御して、アップデートファイルの提供元を通知する提供元通知を形成し、再度通知する（ステップＳ１０７）。
【０１０６】
この場合、基本的にアップデートファイルの提供元となるのはダウンロードサーバ２であるが、新たなアップデートファイルをダウンロードした公衆電話機４が既に存在している場合には、当該公衆電話機４を提供元として通知するようにしてもよい。そして、ステップＳ１０７の処理の後においては、ステップＳ１０２からの処理を繰り返す。
【０１０７】
このように、この実施の形態のアップデートサーバ１は、ダウンロードサーバ２に新たなアップデートファイルが用意されると、アップデートファイルの提供元となるように予め決められた公衆電話機４に新たなアップデートファイルのダウンロードを促す。そして、アップデートファイルの提供元となるように予め決められた公衆電話機４に新たなアップデートファイルを用意できる。
【０１０８】
［一般の公衆電話機４に対する処理］
図１２は、アップデートファイルの予め決められた提供元以外の一般の公衆電話機４が新たなアップデートファイルのダウンロードを行うようにするための処理を説明するためのフローチャートである。この実施の形態において、アップデートサーバ１の制御部１０１は、一般の公衆電話機４のアップデートファイルのダウンロードを可能にするため、常時、図１２に示す処理を実行している。
【０１０９】
そして、制御部１０１は、回線Ｉ／Ｆ１０５を通じて一般の公衆電話機４からの要求等を受信する（ステップＳ２０１）。制御部１０１は、一般の公衆電話機４からの要求等を受信したか否かを判別し（ステップＳ２０２）、受信していないと判別したときには、ステップＳ２０１からの処理を繰り返す。なお、提供元管理データファイル１０３で管理されていない公衆電話機４が、一般の公衆電話機４となる。
【０１１０】
そして、ステップＳ２０２の判別処理において、一般の公衆電話機４からの要求等を受信したと判別したときには、受信した要求等は、更新チェックの要求か否かを判別する（ステップＳ２０３）。ステップＳ２０３の判別処理において、更新チェックの要求であると判別した時には、制御部１０１は、受信した更新チェックに含まれるアップデートファイルのバージョン情報に基づいて、アップデートファイルの更新の有無を確認する（ステップＳ２０４）。
【０１１１】
この後、制御部１０１は、ステップＳ２０４の確認の結果に基づいて、アップデートファイルの更新が必要か否か（新たなアップデートファイルがあるか否か）を判別する（ステップＳ２０５）。ステップＳ２０５で、アップデートファイルの更新の必要があると判別したとする。この場合、制御部１０１は、提供元通知部１０６を制御し、図７（Ａ）に示した提供元通知を形成し、これを更新チェックの要求元に送信すると共に、ダウンロード管理データファイル１０４（図５）を用いて更新の状況を管理する（ステップＳ２０６）。
【０１１２】
また、ステップＳ２０５で、アップデートファイルの更新は必要ないと判別したとする。この場合、制御部１０１は、新たなアップデートファイルは存在しない旨のメッセージを、更新チェックの要求元の公衆電話機４に通知する（ステップＳ２０７）。そして、ステップＳ２０６またはステップＳ２０７の処理の後において、制御部１０１は、ステップＳ２０１からの処理を繰り返す。
【０１１３】
そして、ステップＳ２０３の判別処理において、受信した要求等は、更新チェックの要求ではないと判別した時には、制御部１０１は、受信した要求等は、完了通知か否かを判別する（ステップＳ２０８）。ステップＳ２０８の判別処理において、受信した要求等が完了通知であると判別したとする。この場合、制御部１０１は、ダウンロード管理部１０７を制御し、ダウンロード管理データファイル１０４の該当データのダウンロードの成否の欄にダウンロードが成功したことを示す情報を更新して、更新の状況の管理を解除する（ステップＳ２０９）。この後、制御部１０１は、ステップＳ１０１からの処理を繰り返す。
【０１１４】
また、ステップＳ２０８の判別処理において、受信した要求等は完了通知ではないと判別したとする。この場合、制御部１０１は、受信した要求等は、失敗通知か否かを判別する（ステップＳ２１０）。ステップＳ２１０の判別処理において、受信した要求等が失敗通知であると判別したとする。この場合、制御部１０１は、他の提供元の通知と、アップデートファイルを提供できなかった提供元の入れ替えとを行う（ステップＳ２１１）。具体的に、制御部１０１は、まず、提供元変更通知部１０８を制御し、失敗通知の送信元に、アップデートファイルの他の提供元を通知する。さらに、制御部１０１は、提供元入れ替え部１０９を制御して、提供元管理データファイル１０３で管理されている今回アップデートファイルを提供できなかった提供元を他の提供元と入れ替える処理を行う。
【０１１５】
ステップＳ２１０の判別処理において、受信した要求等が失敗通知ではないと判別した場合と、ステップＳ２１１の処理の後においては、ステップＳ２０１からの処理を繰り返す。このようにして、一般の公衆電話機４についても、アップデートファイルの提供元を１つに限ることなく、アップデートファイルを効率よく提供可能な提供元からダウンロードできるようにしている。
【０１１６】
［公衆電話機４の処理］
なお、公衆電話機４で行われる処理は、アップデートファイルの提供元となる公衆電話機４も、ならない公衆電話機４も基本的に同じ処理を行うことができるようになっている。すなわち、（１）所定のタイミング毎に更新チェックをアップデートサーバ１に対して行いう。（２）提供元通知を受信したときには、通知された提供元にアップデートファイルの提供を要求してアップデートファイルのダウンロードを行う。そして、（３）ダウンロードが成功すれば完了通知を形成してアップデートサーバ１に送信し、（４）ダウンロードが失敗したときには失敗通知を形成してアップデートサーバ１に送信する。（５）また、アップデートファイルの提供要求を受信した時には、自機が保持するアップデートファイルを提供元に送信する。このような処理を行えるようにしておくことにより、公衆電話機４は、この実施の形態の更新情報配信システムの公衆電話機４として機能できる。
【０１１７】
［実施の形態の効果］
上述した実施の形態の説明から分かるように、新たなアップデートファイルを提供する機器は、ダウンロードサーバ２に限るものではない。アップデートファイルの提供元となるように予め決められた公衆電話機４もまた、一般の公衆電話機４に対して新たなアップデートファイルを提供する提供元となれる。そして、アップデートサーバ１は、アップデートファイルのダウンロードの状況に応じて、適切な提供元を公衆電話機４に通知し、公衆電話機４のそれぞれにおいて、確実かつ迅速にアップデートファイルをダウンロードできる。
【０１１８】
また、公衆電話機４のそれぞれにおいて、アップデートファイルのダウンロードが成功しなかった場合には、アップデートファイルの提供元を他の提供元に変更できる。これにより、アップデートファイルのダウンロードが行えない状況が続いてしまうことを効果的に防止できる。また、基本的にアップデートサーバ１において常時管理しなければならないのは、提供元管理データファイル１０３で管理されるアップデートファイルの提供元に関する情報と、ダウンロード管理データファイル１０４で管理される現時点でのアップデートファイルのダウンロードの状況だけであるので、アップデートサーバ１の負荷が大きくなることもない。すなわち、アップデートサーバ１で、全ての公衆電話機４のアップデートファイルの状態を管理する必要がない。
【０１１９】
すなわち、この実施の形態の更新情報配信システムにおいては、アップデートファイルの更新元として、本来、アップデートファイルの提供先である公衆電話機４をも利用する。これにより、アップデートファイルの配信元を複数に分散し、ダウンロードサーバ２だけに負荷がかからないようにすることができる。しかも、アップデートファイルの提供元として、複数のダウンロードサーバ２を設ける必要もなく、既存のシステムの中で、アップデートファイルのダウンロード処理を分散させることができる。
【０１２０】
また、不特定多数の機器における不特定ファイルの共有とは異なり、同一システム内でのファイル共有となっているため、セキュリティ上の問題も発生しない。すなわち、セキュアな更新情報配信システムを構築できる。
【０１２１】
［変形例］
なお、上述した実施の形態では、アップデートサーバ１が予め定められた公衆電話機４に対してバージョンアップ通知を行っている例を説明しているが、これに限定されるものではない。アップデートサーバ１で管理されている全ての公衆電話機４に対してバージョンアップ通知を行うことも当然にして可能である。
【０１２２】
また、上述した実施の形態では、アップデートサーバ１は、アップデートファイルの提供は行わないものとして説明したが、これに限るものではない。アップデートサーバ１もまた、アップデートファイルの提供元となってもよい。このため、アップデートサーバ１とダウンロードサーバ２とを設け、アップデートサーバ１もアップデートファイルの提供機能を有する構成としたり、アップデートサーバ１とダウンロードサーバ２との機能を合わせ持つ１つの管理サーバを設ける構成としたりするなどのことができる。
【０１２３】
また、アップデートファイルの提供元となる公衆電話機４の決め方も様々な態様とすることができる。例えば、公衆電話機４の複数の設置エリアを設定し、設置エリア毎に決められた数の提供元となる公衆電話機４を特定するなどのことが可能である。
【０１２４】
また、上述した実施の形態においては、アップデートファイルをダウンロードする機器は、公衆電話機４である場合を例にして説明したが、これに限るものではない。アップデートファイルをダウンロードする機器は、プログラムや処理に必要となるデータなどをバージョンアップする必要のある通信機能を備えた種々の電子機器を用いるシステムに、この発明を適用できる。
【０１２５】
［アップデートファイルをダウンロードする機器が少ない場合の対応］
アップデートファイルのダウンロードが必要な機器が、例えば、事業所などに構築される電話システムの主装置などである場合について考える。この場合、例えば、同一メーカー製であるなどの系列化してアップデートファイルの送受を可能にする主装置の数は、上述した実施の形態の公衆電話機４に比べれば遥かに少ない場合が多い。このような場合には、アップデートファイルの提供元となる主装置を予め決めて管理するのではなく、対象となる全ての主装置をアップデートファイルの提供元となる可能性のある機器として扱うようにする。
【０１２６】
この場合、全ての主装置のアップデートファイルのバージョンをアップデートサーバ１で管理する。そして、アップデートサーバ１で、現時点において、アップデートファイルの提供先となっている機器と、アップデートファイルの提供元となっている機器との対応関係を管理する。この対応関係の管理は、上述した実施の形態のアップデートサーバ１のダウンロード管理データファイル１０４を用いて管理する場合と同様にして行うことができる。
【０１２７】
各主装置は、所定のタイミング毎にアップデートサーバ１に対して更新チェックを行なうようにし、アップデートファイルのダウンロードが必要であるとアップデートサーバ１が判断したとする。この場合、アップデートサーバ１は、ダウンロードサーバ２や既に最新のアップデートファイルがダウンロード済みの主装置の中から、帯域及び処理能力に余裕のある機器を選択する。この選択した機器をアップデートファイルの提供元として更新チェックの要求元に通知し、当該更新チェックの要求元の機器（主装置）が、提供元として通知された機器からアップデートファイルのダウンロードを行う。
【０１２８】
すなわち、上述した実施の形態では、予め決められた公衆電話機４をアップデートファイルの提供元として管理するのに対して、この例の場合には、全ての主装置をアップデートファイルの提供元とする点だけが異なるだけである。
【０１２９】
また、アップデートファイルの提供元を固定しない場合であって、アップデートサーバ１自身がアップデートファイルの提供元となり得るシステムの場合には、以下のように動作させることができる。
【０１３０】
（１）アップデートサーバ１は上述した実施の形態の場合と同様にネットワーク３上に設ける。（２）アップデートサーバ１では配下の機器からの更新チェックの受け付けを行う。（３）アップデートファイルをアップデートサーバ１からのダウンロードを可能にする。（４）アップデートサーバ１では、更新チェックを行った装置（端末）のアップデートファイルのバージョン、ＭＡＣアドレス、ＩＰアドレスの管理を行う。（５）アップデートサーバ１は、配下の複数の装置から更新チェックを受け付けた場合には、自機の帯域や処理能力を超える部分について、既に最新のアップデートファイルをダウンロードしている配下の装置をアップデートファイルの提供元として通知する。
【０１３１】
（６）当該提供元の通知を受けた装置は、当該提供元にダウンロード要求を送信して、最新のアップデートファイルをダウンロードする。（７）そして、ダウンロードが正常に終了した場合には、完了通知をアップデートサーバ１に送信する。また、（８）ダウンロードが正常に終了しなかった場合には、失敗通知をアップデートサーバ１に送信する。（９）失敗通知を受信したアップデートサーバ１は、アップデートファイルの他の提供元を選択し、失敗通知を送信してきた装置に通知し、他の提供元からのアップデートファイルのダウンロードを可能にする。なお、アップデートファイルのダウンロードが正常に完了するまで、（８）、（９）の処理を繰り返す。このようにすれば、比較的に小規模な更新情報配信システムを、より簡略化した状態で構成することができる。
【０１３２】
［その他］
なお、上述した実施の形態の説明からも分かるように、各請求項の配信管理サーバ装置の機能は、実施の形態の主にアップデートサーバ１が実現している。そして、配信管理サーバ装置の通信手段、提供元通知手段、管理手段の各機能は、アップデートサーバ１の回線Ｉ／Ｆ１０５、提供元通知部１０６、ダウンロード管理部１０７が実現している。また、配信管理サーバ装置の変通知供手段、入れ替え手段の各機能は、アップデートサーバ１の提供元変更通知部１０８、提供元入れ替え部１０９が実現している。
【０１３３】
また、各請求項の通信端末装置は、実施の形態の公衆電話機４が実現している。そして、通信端末装置の通信手段、要求手段、更新処理手段、完了通知手段は、公衆電話機４の回線Ｉ／Ｆ４０７、要求処理部４１０、更新処理部４１１、完了通知部４１２が実現している。また、通信端末装置の失敗通知手段の機能は、公衆電話機４の失敗通知部４１３が実現している。
【符号の説明】
【０１３４】
１…アップデートサーバ、１０１…制御部、１０２…記憶装置、１０３…提供元管理データファイル、１０４…ダウンロード管理データファイル、１０５…回線Ｉ／Ｆ、１０６…提供元通知部、１０７…ダウンロード管理部、１０８…提供元変更通知部、１０９…提供元入れ替え部、２…ダウンロードサーバ、２０１…制御部、２０２…記憶装置、２０３…外部Ｉ／Ｆ、２０４…回線Ｉ／Ｆ、２０５…アップデートファイル提供部、３…ネットワーク、４…公衆電話機、４０１…制御部、４０２…記憶装置、４０３…操作部、４０４…表示部、４０５…課金処理部、４０６…ダイヤル回路、４０７…回線Ｉ／Ｆ、４０８…通話回路、４０９…ハンドセット、４１０…要求処理部、４１１…更新処理部、４１２…完了通知部、４１３…失敗通知部
【図１】
2014120045.tif 000003
【図２】
2014120045.tif 000004
【図３】
2014120045.tif 000005
【図４】
2014120045.tif 000006
【図５】
2014120045.tif 000007
【図６】
2014120045.tif 000008
【図７】
2014120045.tif 000009
【図８】
2014120045.tif 000010
【図９】
2014120045.tif 000011
【図１０】
2014120045.tif 000012
【図１１】
2014120045.tif 000013
【図１２】
2014120045.tif 000014