"通信装置であって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第1受信部と、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第2受信部と、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、を備えたことを特徴とする通信装置。前記第2受信部は、前記依存バージョンが前記装置バージョンより新しくない場合に、前記依存バージョンのメタ情報を受信しないこと、を特徴とする請求項1に記載の通信装置。前記判断部は、さらに、前記対象のアップデートの最新バージョンが前記装置バージョンより新しいか否かを判断し、前記最新バージョンが前記装置バージョンより新しい場合に、前記依存バージョンが前記装置バージョンより新しいか否かを判断すること、を特徴とする請求項1または2に記載の通信装置。前記アップデート処理部は、さらに、前記対象のアップデートの実行後に、前記装置バージョンを前記最新バージョンに更新して設定すること、を特徴とする請求項3に記載の通信装置。前記メタ情報は、前記アップデートと前記アップデートの実行手順を示すスクリプトとを含むパッケージファイルの格納先が指定されており、前記アップデート処理部は、前記メタ情報で指定された格納先から前記パッケージファイルを受信し、前記パッケージファイルの前記スクリプトを実行することにより、前記アップデートを実行すること、を特徴とする請求項1~4のいずれか一つに記載の通信装置。通信装置で実行されるアップデート方法であって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を含むアップデート方法。コンピュータに実行させるためのアップデートプログラムであって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を前記コンピュータに実行させるためのアップデートプログラム。しかしながら、上述した従来技術では、プログラムに依存するバージョンのプログラムのアップデートを行う必要がある場合には、当該依存するバージョンのメタ情報も、ネットワークを介してサーバへアクセスして取得するため、依存するバージョンが複数存在する場合には、複数のバージョンの数だけ何回もメタ情報をネットワークを介して取得しなければならず、ネットワーク帯域の利用が増加してネットワーク負荷が増大するとともに、アップデートの処理が煩雑で時間を要するという問題がある。本発明は、上記に鑑みてなされたものであって、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができる通信装置、アップデート方法及びアップデートプログラムを提供することを目的とする。上述した課題を解決し、目的を達成するために、本発明にかかる通信装置は、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第1受信部と、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第2受信部と、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、を備えたことを特徴とする。また、本発明にかかるアップデート方法は、通信装置で実行されるアップデート方法であって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を含むことを特徴とする。また、本発明にかかるアップデートプログラムは、コンピュータに実行させるためのアップデートプログラムであって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を前記コンピュータに実行させる。本発明によれば、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。以下に添付図面を参照して、この発明にかかる通信装置、アップデート方法およびアップデートプログラムの実施の形態を詳細に説明する。図1は、本実施の形態の遠隔通信システム1の構成を例示する模式図である。図1に示すように、遠隔通信システム1は、通信ネットワーク2により通信装置としての通話端末11aa~11ac、11ba~11bc、11ca~11cc、11da~11dc、遠隔通信管理サーバ50、アップデートサーバ60及びルータ70a~70dが通信可能に接続されるシステムである。具体的には、遠隔通信システム1は、インターネット2iにルータ70a~70dを介して接続するLAN2a、2b、2c、2d、遠隔通信管理サーバ50及びアップデートサーバ60と、LAN2aに接続する通話端末11aa~11ac及び中継装置30aと、LAN2bに接続する通話端末11ba~11bc及び中継装置30bと、LAN2cに接続する通話端末11ca~11cc及び中継装置30cと、LAN2dに接続する通話端末11da~11dc及び中継装置30dとを有する構成である。遠隔通信システム1では、遠隔通信管理サーバ50の管理の下、地域Aの通話端末11aa~11ac、11ba~11bc、地域Bの通話端末11ca~11cc、11da~11dcの各々が、中継装置30a、30b、30c、30dによる通信データの中継を介して、互いに音声又は映像を送受信することで通話を行う。具体的には、遠隔通信管理サーバ50は、通話端末11aa~11ac、11ba~11bc、11ca~11cc、11da~11dc、中継装置30a、30b、30c、30dなどの通信アドレス、中継装置30a、30b、30c、30dの各々が中継を行う通話端末、各通話端末の通話状態などの情報を管理する。例えば、通話端末11aaが通話端末11caと通話を行う場合は、中継装置30aに通話端末11caへの通話の中継を依頼する。中継装置30aは、遠隔通信管理サーバ50に通話端末11aaの通話の開始を通知するとともに、通話端末11caへ通話を中継するための中継装置30cの通信アドレスを遠隔通信管理サーバ50より取得する。次いで、中継装置30aは通話端末11caへ通話の中継を中継装置30cに依頼し、中継装置30cは、通話端末11caとの通信セッションを開始する。次いで、中継装置30cは、通話端末11caとの通信セッションの開始を遠隔通信管理サーバ50へ通知する。これにより、中継装置30a、30cを介して、通話端末11aa及び通話端末11caとの間の通話が開始される。また、遠隔通信管理サーバ50は、通話端末11aa及び通話端末11caが通話中であることを管理する。例えば、遠隔通信管理サーバ50は、通話端末11abから通話端末11aaや通話端末11caなどの通話状態の問い合わせがあった場合は、オンラインであるが互いに通話中であることを返信する。なお、以下の説明において、同種の装置の中の任意の装置について説明を行う場合は、数字の後の英数字を略した符号を用いるものとする。例えば、通話端末11aa~11ac、11ba~11bc、11ca~11cc、11da~11dcは通話端末11と略すものとする。また、中継装置30a~30dは中継装置30と略すものとする。アップデートサーバ60は、通話端末11のプログラムや各種設定情報のアップデートプログラムによるアップデートにかかる情報を管理し、通話端末11の要求に応じてその情報を提供するアップデート情報提供装置である。アップデートにかかる情報としては、通話端末11のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータメタ情報などである。アップデートにかかる情報として全てのバージョンのデータをアップデートサーバ60が管理する理由は、通話端末11がアップデートを行うタイミングが各々異なるためである。例えば、頻繁にアップデートを行っている通話端末11は、最新のバージョンへのアップデートを行うだけでよいかもしれないが、アップデートの間隔が長い通話端末11は、何回かバージョンアップが繰り返された後にアップデートを行うかもしれない。このような場合は、直に最新のバージョンへアップデートせずに、最新のバージョンと依存関係のある古いバージョンへのアップデートを経ることがある。このように、依存関係のある古いバージョンへのアップデートを経る通話端末11もあることから、アップデートサーバ60は、アップデートにかかる情報として全てのバージョンのデータを管理している。ここで、アップデートの種類には、通常アップデートと強制アップデートの2種類がある。通常アップデートは、バグ等の障害対応や機能追加を目的として実施されるアップデートである。強制アップデートは、通話端末11そのものの機能とは異なる装置、機能の変更に伴って、強制的に行うことを目的としたアップデートである。例えば、中継装置30側において、通話の際に送受信する音声や画像のデータフォーマットやビデオコーデックが変更されたり、エンコーダのアップデート等の映像に関する中継装置30のバージョンアップが実施される場合がある。また、中継装置30との通信プロトコルが変更される場合もある。このような変更は、音声や画像、映像そのものの構造が変わり、あるいは通信プロトコルの変更に伴う中継装置30との通信手順そのものが変わり、もしくは中継装置30側の機能が変わるため、アップデート前の通話端末11では、通話端末11の本来の機能である通話を実現することができない。このため、このような場合には、中継装置30のアップデート後のバージョンに適合させるために強制アップデートを行う。また、中継装置30側でセキュリティホールが発見された場合等、セキュリティ面で問題がある等に、これを回避するようなセキュリティホール対応のアップデートを中継装置30側で行う場合がある。このような場合にも、アップデート前の通話端末11では通話すら実行できないことになるため、中継装置30側のセキュリティホール対応に適合させるために強制アップデートが実施される。次に、通話端末11のハードウエア構成を説明する。図2は、通話端末11のハードウエア構成を例示するブロック図である。図2に示すように、通話端末11は、CPU101CentralProcessingUnit、ROM102ReadOnlyMemory、RAM103RandomAccessMemory、記憶部105、メディアドライブ107、操作部108、ネットワークI/F111、撮像素子I/F112、音声入出力I/F113及びディスプレイI/F114を備え、各部がバス110により互いに接続される構成である。CPU101は、ROM102や記憶部105に記憶されたプログラム104をRAM103に展開して順次実行することで、通話端末11の動作を中央制御する。記憶部105は、HDDHardDiskDriveやSSDSolidStateDriveなどであり、読み出し/書き込み可能にデータを記憶する。具体的には、記憶部105は、CPU101が実行するためのプログラム104や各種設定情報を記憶する。アップデートの際には、この記憶部105に記憶されるプログラム104や各種設定情報が更新される。なお、本実施の形態では、プログラム104がアップデート対象であるとして説明する。メディアドライブ107は、光ディスクなどのメディア106の読み出し/書き込みを行うドライブ装置である。操作部108は、キーボード、各種操作キー、ディスプレイ13上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークI/F111は、通信ネットワーク2と接続してデータ通信を行うインタフェースである。撮像素子I/F112は、デジタルカメラであるカメラ12と接続し、カメラ12が撮像した画像を取得するためのインタフェースである。音声入出力I/F113は、マイク14、スピーカ15と接続し、マイク14による音声入力や、スピーカ15を介した音声出力を行うインタフェースである。ディスプレイI/F114は、LCDLiquidCrystalDisplayなどであるディスプレイ13と接続し、ディスプレイ13へ表示データを出力するインタフェースである。なお、本実施の形態では、ディスプレイ13を用いているが、ディスプレイ13に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。通話端末11は、プログラム104を実行したCPU101の制御の下、例えば他の通話端末との通話時には、カメラ12から取得した画像やマイク14から入力された音声をネットワークI/F111を介して中継装置30へ出力する。また、中継装置30より中継され、ネットワークI/F111を介して入力された他の通話端末からの音声をスピーカ15より出力し、同様に他の通話端末からの画像をディスプレイ13により表示する。これにより、通話端末11は、画像及び音声による他の通話端末との通話、いわゆるテレビ会議を実現する。次に、通話端末11の外観構成について説明する。図3は、本実施の形態の通話端末11の外観図である。通話端末11は、図3に示すように、筐体1100、アーム1200、カメラハウジング1300を備えている。筐体1100の右側壁面1130には、操作パネル1150が形成されている。操作パネル1150には、操作部108としての複数の操作ボタン108a~108e、電源スイッチ109、アラームランプ119、内蔵スピーカからの音声を出力するための音出力面1151等が形成されている。また、筐体1100の左側壁面1140には、アーム1200およびカメラハウジング1300を収容するための凹部としての収容部1160が形成されている。この通話端末11の筐体1100にはケーブルでディスプレイ13が接続されている。アーム1200は、トルクヒンジ1210を介して筐体1100に取り付けられており、アーム1200が筐体1100に対して、135度のチルト角θ1の範囲で、上下方向に回転可能に構成されている。図3では、チルト角θ1が90度の状態を示している。カメラハウジング1300には、上述のカメラ12が内蔵されており、ユーザ、書類、および部屋等を撮像することができる。また、カメラハウジング1300は、トルクヒンジ1310が形成されている。カメラハウジング1300は、トルクヒンジ1310を介して、アーム1200に取り付けられている。そして、カメラハウジング1300は、トルクヒンジ1310がアーム1200に対して、図3で示される状態を0度として±180度のパン角θ2の範囲で、かつ、±45度のチルト角θ3の範囲で、上下左右方向に回転可能に構成されている。次に、中継装置30、遠隔通信管理サーバ50、アップデートサーバ60のハードウエア構成を説明する。図4は、中継装置30、遠隔通信管理サーバ50、アップデートサーバ60のハードウエア構成を例示するブロック図である。図4に示すように、中継装置30、遠隔通信管理サーバ50、アップデートサーバ60は、CPU201、ROM202、RAM203、記憶部204、ディスプレイ205、ネットワークI/F206、キーボード207、マウス208、メディアドライブ209及びCD-ROMドライブ211を備え、各部がバス214により互いに接続される構成である。中継装置30、遠隔通信管理サーバ50、アップデートサーバ60は、いわゆるPCPersonalComputerやWSWorkStationなどの機器である。CPU201は、ROM202や記憶部204に記憶されたプログラムをRAM203に展開して順次実行することで、自装置の動作を中央制御する。記憶部204は、HDDやSSDなどであり、読み出し/書き込み可能にデータを記憶する。例えば、アップデートサーバ60では、アップデートにかかる情報などが記憶部204に記憶されている。ディスプレイ205は、例えばLCDなどである。ネットワークI/F206は、通信ネットワーク2と接続してデータ通信を行うインタフェースである。キーボード207、マウス208は、ユーザの操作入力を受け付ける。メディアドライブ209は、光ディスクなどのメディア210の読み出し/書き込みを行うドライブ装置である。CD-ROMドライブ211は、CD-ROM213の読み出しを行うドライブ装置である。例えば、アップデートサーバ60では、メディア210やCD-ROM213によりアップデートにかかる最新の情報が提供され、記憶部204に記憶される。次に、CPU101やCPU201がプログラムを実行することで実現される、通話端末11及びアップデートサーバ60の機能構成について説明する。図5は、本実施の形態の通話端末11及びアップデートサーバ60の機能構成を例示するブロック図である。まず、通話端末11の機能的構成について説明する。図5に示すように、通話端末11は、送受信部1101、ユーザインタフェース部1102及びアップデート部1103を主に有している。送受信部1101は、通信ネットワーク2を介してアップデートサーバ60との間でデータの送受信を行う。具体的には、送受信部1101は、記憶部105の設定情報などに予め設定されているアップデートサーバ60の通信アドレスや遠隔通信管理サーバ50へ問い合わせて取得したアップデートサーバ60の通信アドレスをもとに、アップデートサーバ60との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ60との間でデータの送受信を行う。このデータの送受信により、送受信部1101は、アップデートサーバ60が管理しているアップデートにかかる情報を取得する。すなわち、送受信部1101は、アップデートサーバ60から、通話端末11のプログラム104に必要なアップデートを示すメタデータを受信する。ユーザインタフェース部1102は、スピーカ15による音声出力、ディスプレイ13の表示画面、操作部108によるユーザの操作入力の受け付けなどを制御して、ユーザと通話端末11との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部1102は、スピーカ15による音声出力やディスプレイ13の表示画面でユーザへの各種通知を行うユーザ通知部1104と、操作部108によるユーザの操作入力を受け付ける操作入力受付部1105とを有する。アップデート部1103は、送受信部1101によりアップデートサーバ60から取得したアップデートにかかる情報をもとに、記憶部105が記憶するプログラム104や各種設定情報のアップデートを実行する。アップデート部1103は、判断部1106とアップデート処理部1107とを備えている。判断部1106は、対象のアップデートの最新バージョンが端末バージョン装置バージョンより新しいか否かを判断する。ここで、端末バージョンは、通話端末11のアップデート対象のプログラム104の現在のバージョンである。この端末バージョンは、記憶部105の設定情報に設定されている。例えば、OSオペレーティングシステムがマイクロソフトR社のWindows登録商標である場合には、設定情報としてのレジストリに端末バージョンが設定されている。また、判断部1106は、最新バージョンが端末バージョンより新しい場合において、メタデータに、対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、この依存バージョンと端末バージョンとを比較し、依存バージョンが端末バージョンより新しいか否かを判断する。本実施の形態の送受信部1101は、この判断結果により、以下の処理を行う。送受信部1101は、依存バージョンが端末バージョンより新しい場合に、依存バージョンのアップデートを示すメタデータをアップデートサーバ60に対して要求し、アップデートサーバ60から依存バージョンのメタデータを受信する。送受信部1101は、依存バージョンが端末バージョンより新しくない場合には、アップデートサーバ60に対する依存バージョンのメタデータの要求は行わず、従ってメタデータの受信は行われない。アップデート処理部1107は、依存バージョンのアップデートプログラムのメタデータに基づいて依存バージョンのアップデートを実行し、依存バージョンのアップデートの実行後、アップデート対象のアップデートプログラムのメタデータに基づいて、アップデート対象のアップデートプログラムのアップデートを実行する。また、アップデート処理部1107は、アップデート対象のアップデートプログラムの実行後に、端末バージョンを最新バージョンに更新して設定する。また、アップデート処理部1107は、メタデータで指定された格納先からデータファイルを受信し、アップデートを実行する。ここで、アップデート処理部1107は、データファイルが複数のデータをまとめたキャビネットファイルやZIP形式等のパッケージ形式のファイルパッケージファイルである場合には、当該パッケージファイルに含まれているスクリプトを実行することにより、アップデート処理を行う。ここで、スクリプトは、アップデートの実行手順が記述された実行可能な形式のデータである。次に、アップデートサーバ60の機能的構成について説明する。アップデートサーバ60は、図5に示すように、送受信部601及びアップデートデータ提供部602を主に有している。送受信部601は、通信ネットワーク2を介して通話端末11との間でデータの送受信を行う。具体的には、送受信部601は、通信ネットワーク2を介した通話端末11の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末11との間でデータの送受信を行う。アップデートデータ提供部602は、送受信部601によってデータの送受信を行っている通話端末11からの要求に応じて、アップデートサーバ60が管理しているアップデートにかかる情報を通話端末11に提供する。ここで、メタデータの詳細について説明する。図6は、メタデータの一例を示す概念図である。図6に示すように、各バージョンのメタデータは、version、description、package_url、package_digest、execute、reboot、critical、dependency、dependency_version、dependency_metadata_urlなどのデータ項目を含む構成である。versionには、1.0.1などのアップデートプログラムのバージョン番号が設定される。dependencyは、依存関係を有する他のバージョンである依存バージョンが存在するか否かを示すフラグであり、依存バージョンが存在する場合にはtrue、依存バージョンが存在しない場合にはfalseがそれぞれ設定される。依存バージョンが存在する場合、dependency_versionには、互いに依存関係を有する他のバージョンを示すバージョン番号、すなわち、依存バージョンのバージョン番号が設定される。従って、dependency_versionのデータ項目に記述されたバージョン番号を確認することで、依存バージョンへと遡ることが可能である。dependency_metadata_urlには、依存バージョンのメタデータの格納先のURLが設定される。descriptionには、Itissampledata.などのバージョンの詳細が設定される。package_urlには、アップデートサーバ60が管理しているアップデートの実体となるプログラムデータファイルの格納先のURLが設定される。package_digestには、アップデートの実体となるデータファイルのチェックサムが設定される。従って、アップデート処理部1107は、package_urlのデータ項目に記述された内容をもとに、送受信部1101によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。executeには、アップデートを実行する際に実行するスクリプトのスクリプト名が設定される。このスクリプトは、取得したデータファイルがパッケージ形式のパッケージファイルである場合に、このパッケージファイルの内部に含まれている。rebootは、アップデートを実行した後に、通話端末11の再起動を行うか否かを示すフラグであり、再起動を行う場合にはtrue、再起動を行わない場合にはfalseがそれぞれ設定される。criticalは、アップデートが強制アップデートであるか否かを示すフラグであり、強制アップデートの場合にはtrue、通常アップデートの場合にはfalseが設定される。記憶部105のプログラム104のアップデートには、ネットワークI/F111、撮像素子I/F112、音声入出力I/F113、ディスプレイI/F114等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、rebootにtrueが設定される。また、プログラムのアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、rebootにtrueが設定される。次に、以上のように構成された通話端末11の動作の詳細を説明する。図7,図8は、本実施の形態の通話端末11の動作の一例を示すラダーチャートである。図7に示すように、ユーザインタフェース部1102は、操作部108の電源スイッチなどの操作に応じて自装置の電源投入電源オンを行いステップS1、起動画面をディスプレイ13に表示させるステップS2。この起動画面は、CPU101の制御の下で遠隔通信管理サーバ50へ問い合わせて得られた各通話端末11の通話状態を一覧表示した表示画面である詳細は後述する。アップデート処理部1107は、ステップS1による電源投入後の起動時において、自装置のアップデートの確認を開始するステップS3。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。アップデートの確認が開始されると、アップデート処理部1107は、送受信部1101によって、最新バージョンのプログラムのメタデータをアップデートサーバ60に対して要求しステップS4、その要求に対応して、アップデートサーバ60のアップデートデータ提供部602が提供するメタデータを取得するステップS5。次に、判断部1106は、端末バージョンを記憶部104の設定情報から取得し、最新バージョンが通話端末11の端末バージョンより新しいか否かを判断するステップS6。そして、最新バージョンが端末バージョンより新しくない場合ステップS6:No、すなわち、最新バージョンが端末バージョンと等しいか、最新バージョンが端末バージョンより古い場合には、アップデート処理を行わずに動作を継続するステップS21。一方、ステップS6で、最新バージョンが端末バージョンより新しい場合ステップS6:Yes、アップデート処理部1107は、取得したメタデータのdependencyのデータ項目に記述された内容をもとに、依存バージョンの有無を確認するステップS7。例えば、図6に示すように、dependencyのデータ項目がtrueであり、dependency_versionのデータ項目に1.0.0などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、dependencyのデータ項目がfalseの場合には、依存するバージョンがないものとする。次いで、判断部1106は、ステップS7による確認の結果、依存バージョンが有るか否かを判定するステップS8。依存バージョンがある場合ステップS8:Yes、判断部1106は、メタデータのdependency_versionのデータ項目に設定されたバージョン番号が端末バージョンにより大きいか否かを判断することにより、依存バージョンが端末バージョンより新しいか否かを判断するステップS9。そして、依存バージョンが端末バージョンより新しい場合にはステップS9:Yes、アップデート処理部1107は、送受信部1101によって、既に取得済みのメタデータのdependency_metadata_urlのデータ項目に設定された格納先をもとに、依存バージョンのプログラムのメタデータをアップデートサーバ60に対して要求しステップS10、その要求に対応してアップデートデータ提供部602が提供する、依存バージョンのメタデータを取得してステップS11、S7へ処理を戻す。したがって、アップデート処理部1107は、依存バージョンが端末バージョンより新しい場合に限り、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。ステップS8で依存バージョンが存在しない場合ステップS8:No、またはステップS8で依存バージョンが存在するがステップS8:Yes、ステップS9で依存バージョンが端末バージョンより新しくない場合ステップS9:Noには、アップデート処理部1107は、取得したメタデータのcriticalがtrueに設定されているか否かを判断することにより、今回のアップデートが強制アップデートか否かを判断するステップS12。そして、メタデータのcriticalがtrueに設定されておらず、通常アップデートである場合にはステップS12:No、アップデート処理部1107は、最新バージョンのメタデータのversionに記述されたバージョン番号と、自装置の端末バージョン記憶部105に記憶されたプログラム104のバージョン番号とを比較することで、自装置のアップデートが存在するか否かすなわち、アップデート済みか否かを判定するステップS13。具体的には、最新バージョンのバージョン番号と、端末バージョンとが一致する場合は、プログラム104が最新バージョンであることから、自装置に必要なアップデートが存在しないすなわち、アップデート済みと判定する。また、最新バージョンのバージョン番号と、プログラム104のバージョン番号とが一致しない場合は、プログラム104が古いバージョンであることから、自装置に必要なアップデートが存在するすなわち、アップデート済みでないと判定する。自装置に必要なアップデートが存在しない場合ステップS13:Noは、アップデートを実行する必要がないことから、通常の動作を継続させるステップS21。自装置のアップデートが存在する場合ステップS13:YES、アップデート処理部1107は、そのアップデートに関する情報をユーザインタフェース部1102へ通知するステップS14。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、package_url、executeなどのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部1102へ通知する。ユーザインタフェース部1102のユーザ通知部1104では、S14においてアップデート処理部1107より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ13の起動画面に表示して、ユーザへ通知するステップS15。ここで、起動画面の詳細について説明する。図9は、起動画面G1の一例を示す概念図である。図9に示すように、起動画面G1は、各通話端末の通話状態を一覧表示する主画面G11と、自装置のステータスを表示するステータス画面G12とを含む構成である。ユーザ通知部1104は、アップデートに関する情報がアップデート処理部1107より通知された場合は、ステータス画面G12にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面G11に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例図9~13等において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。ステップS15によるユーザへの通知によって、ユーザインタフェース部1102の操作入力受付部1105によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部1102は、設定画面をディスプレイ13に表示させるステップS16。図10は、設定画面G2の一例を示す概念図である。図10に示すように、設定画面G2は、操作入力受付部1105によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンG23~G26を表示する主画面G21を含む構成である。設定ボタンG23~G26の中で設定ボタンG26がアップデートの実行を指示するためボタンである。この設定ボタンG26は、アップデートに関する情報がアップデート処理部1107より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。逆に、アップデートに関する情報がアップデート処理部1107より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部1105によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンG26には、アップデートに関する情報として含まれるデータ項目のversionの記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が2.0の最新バージョンにアップデートすることが記載されている。なお、設定画面G2に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。ステップS16において、設定ボタンG26の選択操作が行われた場合、ユーザインタフェース部1102は、アップデートの実行を確認する確認画面をディスプレイ13に表示させるステップS17。図11は、確認画面G3の一例を示す概念図である。図11に示すように、確認画面G3は、実行するアップデートの内容を表示するアップデート表示G33と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンG34、G35とを含む主画面G31と、自装置のステータスを表示するステータス画面G32とを含む構成である。アップデート表示G33には、自装置のプログラム104のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目のversionの記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示G33の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、メータデータのrebootのデータ項目を参照して、確認画面G3のアップデート表示G33に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。図12は、確認ウインドウG36の一例を示す概念図である。確認画面G3において、アップデートの実行を指示する操作ボタンG35が選択された場合は、再度ユーザに確認を促す確認ウインドウG36を表示してもよい。確認ウインドウG36には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面G3では、アップデートの実行が指示された場合に確認ウインドウG36を表示することで、ユーザへの注意喚起を促すことができる。なお、メータデータのrebootのデータ項目を参照して、確認ウィンドウG36に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。図7に戻り、アップデート処理部1107では、確認画面G3での操作ボタンG34、G35の選択操作をもとに、アップデートを実行するか否かを判定するステップS18。アップデートの実行を指示する操作ボタンG35が選択された場合ステップS18:Yes、アップデート処理部1107は、取得しているメタデータをもとにアップデート処理を実行するステップS19。ここで、アップデート処理の詳細については後述する。アップデートの実行をキャンセルする操作ボタンG34が選択されるなどして、操作ボタンG35の選択が行われなかった場合ステップS18:No、アップデート処理部1107は、自装置の処理を終了させる終了処理を行いステップS20、装置の電源を落とす。すなわち、通話端末11では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部1102のユーザ通知部1104よりユーザに通知する。そして、通話端末11では、操作入力受付部1105により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート処理部1107によるアップデート処理が実行される。したがって、通話端末11は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。ステップS12で、メタデータのcriticalがtrueに設定されている場合、すなわち、強制アップデートである場合にはステップS12:Yes、アップデート処理部1107は、その強制アップデートに関する情報をユーザインタフェース部1102へ通知するステップS701。具体的には、通常アップデートの場合と同様に、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、package_url、executeなどのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部1102へ通知する。ユーザインタフェース部1102のユーザ通知部1104では、S602においてアップデート処理部1107より通知された強制アップデートに関する情報をもとに、自装置に必要な強制アップデートが存在することをディスプレイ13の起動画面G1図9参照に表示して、ユーザへ通知するステップS602。具体的には、ユーザ通知部1104は、アップデートが強制アップデートである旨を、起動画面G1のステータス画面G12に表示してもよいし、主画面G11に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。S701でユーザへの通知が行われると、ユーザインタフェース部1102は、アップデートの実行を確認する確認画面G70図13参照をディスプレイ13に表示させるステップS603。なお、通常アップデート時のようなアップデートの設定画面G2図10参照は表示されない。図13は、強制アップデート時に表示される確認画面G70の一例を示す概念図である。図13に示すように、確認画面G70は、実行するアップデートの内容を表示するアップデート表示G73と、アップデートの実行をユーザより受け付けるための操作ボタンG75とを含む主画面G72を含む構成である。アップデート表示G73には、自装置のプログラム104のバージョン番号である現在のバージョンの他、強制アップデートに関する情報として含まれるデータ項目のversionの記述をもとにした、強制アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示G73の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。ここで、強制アップデートの確認画面G70に表示されるボタンとして、アップデートボタンG75しか表示されず、通常アップデートの確認画面G3図11に表示されるキャンセルボタンG34は表示されない。これは、強制アップデートの場合には、必ずアップデートを実施する必要があるからである。ただし、操作部108のメニューキーに対応した操作ボタンにより設定画面へ遷移したり、または、電源スイッチ109の押下による電源遮断を行うことができる。図8に戻り、アップデート処理部1107は、確認画面G70での操作ボタンG75の選択操作をもとに、強制アップデートを実行するか否かを判定するステップS702。強制アップデートの実行を指示する操作ボタンG75が選択された場合ステップS702:YES、アップデート処理部1107は、取得しているメタデータをもとにアップデート処理を実行するステップS703。一方、ステップS702において、操作ボタンG75が押下されず、操作部108の操作ボタンが押下された場合にはステップS702:No、押下された操作ボタンに従い、設定画面の表示や電源遮断を行うステップS705。次に、アップデート処理ステップS19,S703の詳細について説明する。図14は、アップデート処理の一例を示すフローチャートである。なお、ステップS19とステップS703では、同一の図14に示すアップデート処理が実行される。図14に示すように、アップデート処理部1107は、アップデート処理が開始されると、カメラ12、マイク14、スピーカ15などの外部装置と接続するための撮像素子I/F112、音声入出力I/F113等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム104が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート処理部1107は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。次に、アップデート処理部1107は、取得したメタデータのpackage_urlからアップデートの実体となるデータファイルの格納先と、package_digestからチェックサムとを取得するステップS1401。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にS1401~S1410の処理が行われるものとする。次いで、アップデート処理部1107は、ステップS1401で取得したデータファイルをアップデートサーバ60から取得するステップS1402。このとき取得するファイルが、例えばキャビネットファイルやZIPファイルといった複数のファイルをまとめたパッケージ形式であるパッケージファイルの場合には、データファイルプログラムが複数存在する場合にも取得する回数が1回のみで済み、ネットワーク帯域の利用を低減することができる。次に、アップデート処理部1107は、ステップS1402で取得したデータファイルのチェックサムを確認するステップS1403。そして、アップデート処理部1107は、取得したデータファイルが複数のファイルをまとめたパッケージファイルである場合、取得したパッケージファイルを展開して、アップデート用のファイルとスクリプトを取得するステップS1404。このスクリプトには、ファイルの移動や削除といったアップデートに関するオペレーションの手順が記述される。図15は、スクリプトの一例を示す説明図である。図15は、ディレクトリ作成ファイル移動処理中断再起動等の各コマンドを、マイクロソフトR社のDeviceUpdateScriptに基づいて記述したものである。アップデート用スクリプトは、図15に示すように、人間が可読なテキスト形式で配布してもよいし、あるいは処理時間の低減を目的として、機械語形式、中間言語形式等にコンパイル処理を施して配布してもよい。次に、アップデート処理部1107は、ステップS1404で取得したスクリプトを実行して、アップデートを実施するステップS1405。次いで、アップデート処理部1107は、アップデートの進行状況をユーザインタフェース部1102に通知するステップS1406。この進行状況の通知は、S1402、S1403、S1404、S1405の処理を終えたか否かを通知する。また、依存関係を有する複数のバージョン依存バージョンのアップデートを行う場合には、どのバージョンのアップデートまでを終了したかを通知してもよい。ユーザインタフェース部1102では、通知されたアップデートの進行状況をディスプレイ13に画面表示してユーザに通知する。図16は、アップデート画面G4の一例を示す概念図である。図16に示すように、アップデート画面G4は、アップデート処理部1107によるアップデート処理中にユーザインタフェース部1102がディスプレイ13に表示させる画面である。アップデート画面G4には、アップデート処理部1107より通知されたアップデートの進行状況を表示するアップデートステータスウインドウG41と、アップデートの中止を指示するための操作ボタンG42とが表示される。ユーザは、アップデートステータスウインドウG41の表示内容により、アップデートの進行状況を確認できる。なお、この他、アップデート画面G4に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するように構成してもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。次いで、アップデート処理部1107は、エラーの発生の有無を判定しステップS1407、エラーの発生がある場合ステップS1407:YesはステップS1401~S1410の処理を抜けてステップS1412へ処理を進める。このS1407では、アップデート実行中に何らかの要因で発生するエラー例えば、S1403におけるチェックサムの相違の場合にもエラーとして判定される。ステップS1407でエラーの発生がない場合にはステップS1407:No、アップデート処理部1107は、メタデータに含まれる、rebootにtrueが設定されているか否かを判断することにより、再起動が必要であるか否かを判定するステップS1408。ここで、本実施の形態では、メタデータのrebootは、実施したアップデートに次のアップデートを行う前に、再起動が必要か否かを示すものとなっている。図14に示すアップデート処理では、ステップS1401からS1410までの処理で1回のアップデートを行い、複数のバージョンのアップデートを行う場合には、ステップS1401からS1410までの処理をアップデートのバージョン数だけ繰り返すことになっている。このため、本実施の形態では、ステップS1401からS1410までの処理の1回のループの最後に、メタデータに含まれるrebootにtrueが設定されているか否かを判断して、再起動の要否判断ステップS1408を行い、1回のアップデートごとに再起動を行っている。そして、rebootにtrueが設定されており再起動が必要である場合にはステップS1408:Yes、通話端末11の再起動を行うステップS1409。そして、アップデート処理部1107は、全てのバージョンのアップデートが完了したか否かを判定するステップS1410。全てのバージョンのアップデートが完了していない場合ステップS1410:Noには、S1401へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合ステップS1410:Yeesには、アップデート処理部1107は、通話端末11の記憶部105の設定情報に設定されているプログラム104の端末バージョンをアップデートを行った最新バージョンに更新するステップS1411。なお、OSがマイクロソフトR社のWindows登録商標である場合には、アップデート処理部1107は、レジストリに設定されいるプログラム104の端末バージョンを最新バージョンに更新する。次に、アップデート処理部1107は、S1401~S1410によるアップデートの結果をユーザインタフェース部1102へ通知するステップS1412。ユーザインタフェース部1102では、通知されたアップデートの結果をディスプレイ13に画面表示してユーザに通知する。通常アップデートの結果は図17の画面が表示される。一方、強制アップデートの結果は、図18に示す強制アップデート結果画面G80が表示される。図17は、通常アップデートの場合の確認画面G5の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部1102は、図17に示すように、S1401~S1410によるアップデート結果G51や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンG52、G53を確認画面G5に表示する。アップデート結果G51には、アップデート前のバージョンにかかる情報の他、S1401~S1410のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果G51の表示内容により、ユーザは、アップデートの結果を確認できる。図18は、強制アップデート結果画面G80の一例を示す概念図である。強制アップデート結果画面G80では、通常アップデート時の確認画面G5と同様に、シャットダウンボタンG84と再起動ボタンG85とが表示され、ユーザはいずれかのボタンを押下可能である。アップデート処理部1107は、アップデートの結果をユーザインタフェース部1102へ通知したらアップデート処理を終了するステップS1413。このように本実施の形態では、アップデートに依存するバージョンのアップデートが存在する場合には、この依存バージョンが通信端末11のプログラム104の現在のバージョンである端末バージョンより新しいか否かを判断し、新しい場合には、依存バージョンのアップデートのメタデータをネットワークを介してアップデートサーバ60に要求して取得し、かつ依存バージョンのアップデートのデータファイルをアップデートサーバ60からネットワークを介して取得する。一方、依存バージョンが端末バージョンと等しいか、端末バージョンより古い場合には、依存バージョンのアップデートのメタデータの要求を行わず、従って依存バージョンのアップデートの取得も行わない。従って、本実施の形態によれば、プログラム104のアップデートに1または複数の依存バージョンのアップデートがある場合でも、端末バージョンに応じて、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。また、本実施の形態では、通話端末11に実行するアップデートがある場合において、そのアップデートの実行をユーザが選択することができるので、これによりユーザの利便性を図ることができる。また、本実施の形態では、通話端末11が強制アップデートを実施しなければならない場合には、ユーザにキャンセルさせる選択を与えずに、強制アップデートを実行するので、中継装置30等、通話端末11側以外のアップデートにより通話端末11本来の機能の実行が不可能になることを回避することができる。なお、本実施の形態では、遠隔通信管理サーバ50とアップデートサーバ60とを別個の構成とした例を示しているが、これに限定されるものではない。例えば、サーバ装置を設け、当該サーバ装置が遠隔通信管理サーバ50の機能とアップデートサーバ60の機能とを備えた構成としてもよい。なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。"