(57)【要約】  アップデートに用いるアップデートデータのメタデータを受信する受信手段と、前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段とを備える。
2015068460.tif 000002
【特許請求の範囲】
【請求項１】
アップデートに用いるアップデートデータのメタデータを受信する受信手段と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段と
を備えたことを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記判断手段は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理手段は事前ダウンロードを開始または再開する
ことを特徴とする通信装置。
【請求項３】
請求項１または２のいずれか一項に記載の通信装置において、
前記判断手段は、ビデオ会議が開始された場合に、事前ダウンロードを実施するタイミングでないと判断し、前記アップデート処理手段は事前ダウンロードを中断する
ことを特徴とする通信装置。
【請求項４】
請求項３に記載の通信装置において、
前記アップデート処理手段は、前記判断手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量がダウンロード中のデータの半分以上の場合はダウンロード中のデータをすべてダウンロードしてから中断する
ことを特徴とする通信装置。
【請求項５】
請求項３に記載の通信装置において、
前記アップデート処理手段は、前記判断手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量がダウンロード中のデータの半分以下の場合はダウンロード中のデータを破棄してダウンロードを中断する
ことを特徴とする通信装置。
【請求項６】
請求項３に記載の通信装置において、
前記アップデート処理手段は、前記判断手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量にかかわらず即座にダウンロードを中断する
ことを特徴とする通信装置。
【請求項７】
請求項４乃至６のいずれか一項に記載の通信装置において、
前記データは分割データとし、前記データ量は当該分割データ中のダウンロードしたデータ量とする
ことを特徴とする通信装置。
【請求項８】
ネットワークを介して接続可能なアップデートサーバと通信装置とを備えた通信システムであって、
前記アップデートサーバは、
前記通信装置からの要求に応じてアップデートデータおよびメタデータを提供する提供手段
を備え、
前記通信装置は、
アップデートに用いるアップデートデータのメタデータを受信する受信手段と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段と
を備えたことを特徴とする通信システム。
【請求項９】
アップデートに用いるアップデートデータのメタデータを受信する受信工程と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断工程と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御工程と、
前記判断工程により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御工程により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理工程と
を備えたことを特徴とする通信方法。
【請求項１０】
通信装置を構成するコンピュータを、
アップデートに用いるアップデートデータのメタデータを受信する受信手段、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段
として機能させる通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信装置、通信システム、通信方法および通信プログラムに関する。
【背景技術】
【０００２】
インターネット等の通信ネットワークを介して、遠隔地との間で遠隔会議を行う会議システムが普及している。このような会議システムにおいては、遠隔会議を行う出席者等の当事者の一方がいる会議室において、会議システムの端末装置を用いて会議の当事者などの会議室の画像および発言などの音声を撮影および収集し、それをデジタルデータに変換して相手方の端末装置に送信し、相手方の会議室のディスプレイに表示しスピーカにより音声出力して、実際の会議に近い状態で遠隔地間の会議を行う。【０００３】
このような会議システムをはじめとする通信システムでは、通話秘匿性能や操作性能を向上させるために、端末装置のファームウェア（プログラム）のアップデートが定期的に行われることがある。このような通信システムにおけるプログラムについて、アップデートデータとそのメタ情報（メタデータ）を、端末装置からネットワークを介してサーバへアクセスして取得し、アップデートする方法が既に知られている（特許文献１、２等を参照。）。メタ情報を先に取得してアップデートの必要性を判断した後にアップデートデータを取得することにより、必要のないアップデートデータの取得を行わないで済む。なお、アップデートデータのダウンロードは、通常、アップデートが開始できる日付以降に可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−０８４１１８号公報
【特許文献２】特開２０１３−０２０５０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述したように、事前ダウンロードは、ダウンロード要求アクセスの集中を防止し、アップデートを円滑に進める上で有効であるが、事前ダウンロード中にビデオ会議を開始してしまうと、ユーザのネットワークの環境によってはビデオ会議に必要な帯域が十分に確保できなくなることがある。そのため、ユーザが意図しないうちに、映像／音声の品質が落ちてしまい、最悪の場合はビデオ会議が切断に至るという問題があった。【０００６】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ビデオ会議等の意図しない品質の低下を避けることにある。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明にあっては、アップデートに用いるアップデートデータのメタデータを受信する受信手段と、前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段とを備えるようにしている。
【発明の効果】
【０００８】
本発明にあっては、ビデオ会議等の意図しない品質の低下を避けることができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態にかかる通信システムの構成例を示す図である。
【図２】通話端末のハードウェア構成例を示す図である。
【図３】中継装置、通信管理サーバ、アップデートサーバのハードウェア構成例を示す図である。
【図４】通話端末およびアップデートサーバの機能構成例を示す図である。
【図５】アップデートサーバのアップデートデータ提供部の処理例を示すフローチャートである。
【図６】メタデータの例を示す図である。
【図７】通話端末の処理例を示すフローチャート（その１）である。
【図８】起動画面の例を示す図である。
【図９】設定画面の例を示す図である。
【図１０】確認画面の例を示す図である。
【図１１】確認ウインドウの例を示す図である。
【図１２】通話端末の処理例を示すフローチャート（その２）である。
【図１３】設定画面の例を示す図である。
【図１４Ａ】事前ダウンロードの中断の判断の例を示す図である。
【図１４Ｂ】事前ダウンロードの中断の判断と再開時の開始位置の例を示す図である。
【図１５】確認画面の例を示す図である。
【図１６】事前ダウンロード実行中画面の例を示す図である。
【図１７】通話端末の処理例を示すフローチャート（その３）である。
【図１８】アップデート画面の例を示す図である。
【図１９】確認画面の例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の好適な実施形態につき説明する。
【００１１】
＜構成＞
図１は本発明の一実施形態にかかる通信システムの構成例を示す図である。
【００１２】
図１において、通信システム１は、通信ネットワーク２により通信装置としての通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、通信管理サーバ５０、アップデートサーバ６０およびルータ７０ａ〜７０ｄが通信可能に接続されるシステムである。具体的には、通信システム１は、インターネット２ｉにルータ７０ａ〜７０ｄを介して接続するＬＡＮ２ａ、２ｂ、２ｃ、２ｄ、通信管理サーバ５０およびアップデートサーバ６０と、ＬＡＮ２ａに接続する通話端末１１ａａ〜１１ａｃおよび中継装置３０ａと、ＬＡＮ２ｂに接続する通話端末１１ｂａ〜１１ｂｃおよび中継装置３０ｂと、ＬＡＮ２ｃに接続する通話端末１１ｃａ〜１１ｃｃおよび中継装置３０ｃと、ＬＡＮ２ｄに接続する通話端末１１ｄａ〜１１ｄｃおよび中継装置３０ｄとを有する構成である。通信システム１では、通信管理サーバ５０の管理の下、地域Ａの通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、地域Ｂの通話端末１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃの各々が、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄによる通信データの中継を介して、互いに音声および映像（画像）の少なくともいずれかを含むデータを送受信することで通話を行う。
【００１３】
具体的には、通信管理サーバ５０は、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄなどの通信アドレス、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄの各々が中継を行う通話端末、各通話端末の通話状態などの情報を管理する。例えば、通話端末１１ａａが通話端末１１ｃａと通話を行う場合は、中継装置３０ａに通話端末１１ｃａへの通話の中継を依頼する。中継装置３０ａは、通信管理サーバ５０に通話端末１１ａａの通話の開始を通知するとともに、通話端末１１ｃａへ通話を中継するための中継装置３０ｃの通信アドレスを通信管理サーバ５０より取得する。次いで、中継装置３０ａは通話端末１１ｃａへの通話の中継を中継装置３０ｃに依頼し、中継装置３０ｃは、通話端末１１ｃａとの通信セッションを開始する。次いで、中継装置３０ｃは、通話端末１１ｃａとの通信セッションの開始を通信管理サーバ５０へ通知する。
【００１４】
これにより、中継装置３０ａ、３０ｃを介して、通話端末１１ａａおよび通話端末１１ｃａとの間の通話が開始される。また、通信管理サーバ５０は、通話端末１１ａａおよび通話端末１１ｃａが通話中であることを管理する。例えば、通信管理サーバ５０は、通話端末１１ａｂから通話端末１１ａａや通話端末１１ｃａなどの通話状態の問い合わせがあった場合は、オンラインであるが互いに通話中であることを返信する。
【００１５】
なお、以下の説明において、同種の装置の中の任意の装置について説明を行う場合は、数字の後の英数字を略した符号を用いるものとする。例えば、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃは通話端末１１と略すものとする。また、中継装置３０ａ〜３０ｄは中継装置３０と略すものとする。
【００１６】
アップデートサーバ６０は、通話端末（第１通信装置）１１のプログラムや各種設定情報のアップデートにかかる情報を管理し、通話端末１１の要求に応じてその情報を提供するアップデート情報提供装置（第２通信装置）である。アップデートにかかる情報を示す関連情報としては、通話端末１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータ（メタ情報）などである。アップデートにかかる情報として全てのバージョンのデータをアップデートサーバ６０が管理する理由は、通話端末１１がアップデートを行うタイミングが各々異なるためである。
【００１７】
例えば、頻繁にアップデートを行っている通話端末１１は、最新のバージョンへのアップデートを行うだけでよいかもしれないが、アップデートの間隔が長い通話端末１１は、何回かバージョンアップが繰り返された後にアップデートを行うかもしれない。このような場合は、直に最新のバージョンへアップデートせずに、最新のバージョンと依存関係のある古いバージョンへのアップデートを経ることがある。このように、依存関係のある古いバージョンへのアップデートを経る通話端末１１もあることから、アップデートサーバ６０は、アップデートにかかる情報として全てのバージョンのデータを管理している。
【００１８】
ここで、アップデートの種類には、通常アップデートと強制アップデートの２種類がある。通常アップデートは、バグ等の障害対応や機能追加を目的として実施されるアップデートである。
【００１９】
強制アップデートは、通話端末１１そのものの機能とは異なる装置、機能の変更に伴って、強制的に行うことを目的としたアップデートである。例えば、中継装置３０側において、通話の際に送受信する音声や画像のデータフォーマットやビデオコーデックが変更されたり、エンコーダのアップデート等の映像に関する中継装置３０のバージョンアップが実施されたりする場合がある。また、中継装置３０との通信プロトコルが変更される場合もある。このような変更は、音声や画像、映像そのものの構造が変わり、あるいは通信プロトコルの変更に伴う中継装置３０との通信手順そのものが変わり、もしくは中継装置３０側の機能が変わるため、アップデート前の通話端末１１では、通話端末１１の本来の機能である通話を実現することができない。このため、このような場合には、中継装置３０のアップデート後のバージョンに適合させるために強制アップデートを行う。
【００２０】
また、中継装置３０側でセキュリティホールが発見された場合等、セキュリティ面で問題がある場合等に、これを回避するようなセキュリティホール対応のアップデートを中継装置３０側で行う場合がある。このような場合にも、アップデート前の通話端末１１では通話すら実行できないことになるため、中継装置３０側のセキュリティホール対応に適合させるために強制アップデートが実施される。
【００２１】
図２は通話端末のハードウェア構成例を示す図である。
【００２２】
図２において、通話端末１１は、ＣＰＵ１０１（Central Processing Unit）、ＲＯＭ１０２（Read Only Memory）、ＲＡＭ１０３（Random Access Memory）、記憶部１０５、メディアドライブ１０７、操作部１０８、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３およびディスプレイＩ／Ｆ１１４を備え、各部がバス１１０により互いに接続される構成である。
【００２３】
ＣＰＵ１０１は、ＲＯＭ１０２や記憶部１０５に記憶されたプログラム１０４をＲＡＭ１０３に展開して順次実行することで、通話端末１１の動作を中央制御する。記憶部１０５は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などであり、読み出し／書き込み可能にデータを記憶する。具体的には、記憶部１０５は、ＣＰＵ１０１が実行するためのプログラム１０４や各種設定情報を記憶する。アップデートの際には、この記憶部１０５に記憶されるプログラム１０４や各種設定情報が更新される。
【００２４】
メディアドライブ１０７は、光ディスクなどのメディア１０６の読み出し／書き込みを行うドライブ装置である。操作部１０８は、キーボード、各種操作キー、ディスプレイ１３上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークＩ／Ｆ１１１は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。撮像素子Ｉ／Ｆ１１２は、デジタルカメラであるカメラ１２と接続し、カメラ１２が撮像した画像を取得するためのインタフェースである。音声入出力Ｉ／Ｆ１１３は、マイク１４、スピーカ１５と接続し、マイク１４による音声入力や、スピーカ１５を介した音声出力を行うインタフェースである。ディスプレイＩ／Ｆ１１４は、ＬＣＤ（Liquid Crystal Display）などであるディスプレイ１３と接続し、ディスプレイ１３へ表示データを出力するインタフェースである。なお、本実施形態では、ディスプレイ１３を用いているが、ディスプレイ１３に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。
【００２５】
通話端末１１は、プログラム１０４を実行したＣＰＵ１０１の制御の下、例えば他の通話端末との通話時には、カメラ１２から取得した画像やマイク１４から入力された音声をネットワークＩ／Ｆ１１１を介して中継装置３０へ出力する。また、中継装置３０より中継され、ネットワークＩ／Ｆ１１１を介して入力された他の通話端末からの音声をスピーカ１５より出力し、同様に他の通話端末からの画像をディスプレイ１３により表示する。これにより、通話端末１１は、画像および音声による他の通話端末との通話、いわゆるテレビ会議を実現する。なお、通話端末１１は、汎用のＰＣ（Personal Computer）、スマートフォン、携帯電話およびタブレット端末などの通信端末であってもよい。
【００２６】
図３は中継装置、通信管理サーバ、アップデートサーバのハードウェア構成例を示す図である。
【００２７】
図３において、中継装置３０、通信管理サーバ５０、アップデートサーバ６０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶部２０４、ディスプレイ２０５、ネットワークＩ／Ｆ２０６、キーボード２０７、マウス２０８、メディアドライブ２０９およびＣＤ−ＲＯＭドライブ２１１を備え、各部がバス２１４により互いに接続される構成である。中継装置３０、通信管理サーバ５０、アップデートサーバ６０は、いわゆるＰＣ（Personal Computer）やＷＳ（Work Station）などの機器である。
【００２８】
ＣＰＵ２０１は、ＲＯＭ２０２や記憶部２０４に記憶されたプログラムをＲＡＭ２０３に展開して順次実行することで、自装置の動作を中央制御する。記憶部２０４は、ＨＤＤやＳＳＤなどであり、読み出し／書き込み可能にデータを記憶する。例えば、アップデートサーバ６０では、アップデートにかかる情報などが記憶部２０４に記憶されている。
【００２９】
ディスプレイ２０５は、例えばＬＣＤなどである。ネットワークＩ／Ｆ２０６は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。キーボード２０７、マウス２０８は、ユーザの操作入力を受け付ける。メディアドライブ２０９は、光ディスクなどのメディア２１０の読み出し／書き込みを行うドライブ装置である。ＣＤ−ＲＯＭドライブ２１１は、ＣＤ−ＲＯＭ２１３の読み出しを行うドライブ装置である。例えば、アップデートサーバ６０では、メディア２１０やＣＤ−ＲＯＭ２１３によりアップデートにかかる最新の情報が提供され、記憶部２０４に記憶される。
【００３０】
図４は通話端末およびアップデートサーバの機能構成例を示す図である。これらの機能構成は、主として、ＣＰＵ１０１やＣＰＵ２０１がプログラムを実行することにより実現される。
【００３１】
図４において、通話端末１１は、送受信部１１０１、ユーザインタフェース部１１０２、アップデート部１１０３を主に有している。アップデートサーバ６０は、送受信部６０１およびアップデートデータ提供部６０２を主に有している。なお、通話端末１１およびアップデートサーバ６０の各機能は、一部または全部がハードウェアで構成されてもよい。
【００３２】
通話端末１１の送受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う。具体的には、送受信部１１０１は、記憶部１０５の設定情報などに予め設定されているアップデートサーバ６０の通信アドレスや通信管理サーバ５０へ問い合わせて取得したアップデートサーバ６０の通信アドレスをもとに、アップデートサーバ６０との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ６０との間でデータの送受信を行う。このデータの送受信により、送受信部１１０１は、アップデートサーバ６０が管理しているアップデートにかかる情報（例えばメタデータおよびアップデートデータなど）を取得する。
【００３３】
ユーザインタフェース部１１０２は、スピーカ１５による音声出力、ディスプレイ１３の表示画面、操作部１０８によるユーザの操作入力の受け付けなどを制御して、ユーザと通話端末１１との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部１１０２は、スピーカ１５による音声出力やディスプレイ１３の表示画面でユーザへの各種通知を行うユーザ通知部１１０４と、操作部１０８によるユーザの操作入力を受け付ける操作入力受付部１１０５とを有する。
【００３４】
アップデート部１１０３は、判断部およびアップデート処理部として機能し、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報を示す情報に基づいて、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデート（アップデートデータのダウンロードを含む）を制御して実行する。
【００３５】
アップデートサーバ６０の送受信部６０１は、通信ネットワーク２を介して通話端末１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した通話端末１１の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末１１との間でデータの送受信を行う。
【００３６】
アップデートデータ提供部６０２は、送受信部６０１によってデータの送受信を行っている通話端末１１からの要求に応じて、アップデートサーバ６０が管理しているアップデートにかかる情報を通話端末１１に提供する。
【００３７】
＜動作＞
図５はアップデートサーバ６０のアップデートデータ提供部６０２の処理例を示すフローチャートである。
【００３８】
図５において、アップデートデータ提供部６０２は、通話端末１１からメタデータの要求を受信する（ステップＳ６００）。
【００３９】
アップデートデータ提供部６０２は、メタデータの要求を受信すると、現在アップデートを実行可能なデータ（実行可能データ）のメタデータを生成する（ステップＳ６０２）。
【００４０】
さらに、アップデートデータ提供部６０２は、事前ダウンロードの対象となるデータがあるか否かを判定する（ステップＳ６０４）。ここで、事前ダウンロードの対象となるデータとは、現在アップデートを実行できないが、アップデート可能日時に対し、事前（アップデート可能日時以前）にダウンロードが可能なアップデートデータである。つまり、事前ダウンロードの対象となるデータは、例えばビデオ会議を実行するアプリケーションのアップデートを行う以前に予めダウンロード可能なアップデートデータである。事前ダウンロードは、アップデートの実行時にアップデートサーバ６０に対するアクセスが集中してしまうことを防止することを可能にする。
【００４１】
アップデートデータ提供部６０２は、事前にダウンロード可能なアップデートデータがあるか否かを、後述するメタデータに含まれる"valid date"の時刻が、現在時刻よりも未来であるか否かによって判断する。アップデートデータ提供部６０２は、現在時刻を、例えばＮＴＰ（Network  Time  Protocol）サーバから取得してもよいし、機器に内蔵されている時計から取得してもよい。
【００４２】
アップデートデータ提供部６０２は、事前にダウンロード可能なアップデートデータがあると判断した場合（ステップＳ６０４：Ｙｅｓ）、事前ダウンロード対象のアップデートデータのメタデータを生成する（ステップＳ６０６）。そして、アップデートデータ提供部６０２は、現在アップデートを実行可能なデータのメタデータとともに、事前ダウンロード対象のアップデートデータのメタデータを通話端末１１へ送信する（ステップＳ６０８）。
【００４３】
また、アップデートデータ提供部６０２は、事前にダウンロード可能なアップデートデータがないと判断した場合（ステップＳ６０４：Ｎｏ）、現在アップデートを実行可能なデータのメタデータのみを通話端末１１へ送信する（ステップＳ６０８）。
【００４４】
図６はメタデータの例を示す図である。
【００４５】
図６において、各バージョンのメタデータは、"version"、"dependency"、"description"、"files"、"scriptname"、"require_reboot"、"force_update"、"valid date"、"data size"などのデータ項目を含む構成である。
【００４６】
"version"には、"1.0.1"などのバージョン番号が記述される。"dependency"には、"1.0.0"などの、互いに依存関係を有する他のバージョンを示すバージョン番号が記述される。したがって、"dependency"のデータ項目に記述されたバージョン番号を確認することで、依存関係にあるバージョンへと遡ることが可能である。"description"には、"It is sample data."などのバージョンの詳細が記述される。"files"には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）のリストとその格納先や、それらデータファイルのチェックサムなどが記述される。したがって、アップデート部１１０３は、"files"のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。"scriptname"には、アップデートを実行する際に実行するスクリプト名が記述される。"require_reboot"には、アップデートを実行した後に、装置の再起動を行うか否かを示すフラグ（"true"または"false"）が記述される。"force_update"には、強制のアップデートであるか否かを示すフラグ（"true"または"false"）が記述される。"valid date"には、アップデートデータが実行可能となる日時が記述される。つまり、"valid date"は、アップデートデータが事前ダウンロードデータであるか否かを判断可能にする情報である。"data size"には、アップデートデータのサイズが記述される。
【００４７】
プログラム１０４のアップデートには、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３、ディスプレイＩ／Ｆ１１４等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、"require_reboot"に"true"が記述される。また、プログラム１０４のアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、"force_update"に"true"が記述される。
【００４８】
図７は通話端末の処理例を示すフローチャートである。
【００４９】
図７において、ユーザインタフェース部１１０２は、操作部１０８の電源スイッチなどの操作に応じて自装置の電源投入（電源オン）を行い（ステップＳ１）、起動画面をディスプレイ１３に表示させる（ステップＳ２）。この起動画面は、ＣＰＵ１０１の制御の下で通信管理サーバ５０へ問い合わせて得られた各通話端末１１の通話状態を一覧表示した表示画面である（詳細は後述する）。
【００５０】
アップデート部１１０３は、ステップＳ１による電源投入後の起動時において、自装置のアップデートの確認を開始する（ステップＳ３）。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。
【００５１】
アップデートの確認が開始されると、アップデート部１１０３は、送受信部１１０１によって、最新バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ４）、その要求に対応してアップデートサーバ６０のアップデートデータ提供部６０２が提供するメタデータを取得する（ステップＳ５）。
【００５２】
次いで、アップデート部１１０３は、取得したメタデータの"dependency"のデータ項目に記述された内容をもとに、依存するバージョンの有無を確認する（ステップＳ６）。例えば、図６に示したように、"dependency"のデータ項目に"1.0.0"などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、"dependency"のデータ項目に何も記述がない場合には、依存するバージョンがないものとする。
【００５３】
次いで、アップデート部１１０３は、ステップＳ６による確認の結果、依存するバージョンが有るか否かを判定する（ステップＳ７）。依存するバージョンがある場合（ステップＳ７：Ｙｅｓ）、アップデート部１１０３は、送受信部１１０１によって、依存するバージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ８）、その要求に対応してアップデートデータ提供部６０２が提供する、依存するバージョンのメタデータを取得して（ステップＳ９）、ステップＳ６へ処理を戻す。したがって、アップデート部１１０３は、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。
【００５４】
次いで、アップデート部１１０３は、"valid date"が現在時刻よりも前に設定された最新バージョンのメタデータの"version"に記述されたバージョン番号と、自装置の記憶部１０５に記憶されたプログラム１０４のバージョン番号とを比較することで、自装置の実行可能なアップデートが存在するか否かを判定する（ステップＳ１０）。具体的には、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致する場合は、プログラム１０４が最新バージョンであることから、実行可能なアップデートが存在しないと判定する。
【００５５】
また、アップデート部１１０３は、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、実行可能なアップデートが存在すると判定する。
【００５６】
自装置のアップデートが存在する場合（ステップＳ１０：Ｙｅｓ）、アップデート部１１０３は、そのアップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ１１）。具体的には、最新バージョンおよびその最新バージョンに依存するバージョンのメタデータのうち、"files"、"scriptname"などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。
【００５７】
ユーザインタフェース部１１０２のユーザ通知部１１０４では、ステップＳ１１においてアップデート部１１０３より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ１３の起動画面に表示して、ユーザへ通知する（ステップＳ１２）。
【００５８】
ここで、起動画面の詳細について説明する。図８は、起動画面Ｇ１の一例を示す概念図である。図８において、起動画面Ｇ１は、各通話端末の通話状態を一覧表示する主画面Ｇ１１と、自装置のステータスを表示するステータス画面Ｇ１２とを含む構成である。ユーザ通知部１１０４は、アップデートに関する情報がアップデート部１１０３より通知された場合は、ステータス画面Ｇ１２にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面Ｇ１１に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例（図８〜図１１等）において、中抜きまたは黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。
【００５９】
また、ユーザ通知部１１０４は、アップデートに関する情報として含まれるデータ項目の中で"force_update"の記述が"true"である場合は、自装置に存在するアップデートが強制のアップデートであることを起動画面Ｇ１に表示してユーザに通知する。具体的には、アップデートが強制のアップデートである旨をステータス画面Ｇ１２に表示してもよいし、主画面Ｇ１１に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。
【００６０】
図７に戻り、ステップＳ１２によるユーザへの通知によって、ユーザインタフェース部１１０２の操作入力受付部１１０５によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部１１０２は、設定画面をディスプレイ１３に表示させる（ステップＳ１３）。
【００６１】
図９は、設定画面Ｇ２の一例を示す概念図である。図９に示すように、設定画面Ｇ２は、操作入力受付部１１０５によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンＧ２３〜Ｇ２６を表示する主画面Ｇ２１を含む構成である。設定ボタンＧ２３〜Ｇ２６の中で設定ボタンＧ２６がアップデートの実行を指示するためのボタンである。この設定ボタンＧ２６は、アップデートに関する情報がアップデート部１１０３より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。逆に、アップデートに関する情報がアップデート部１１０３より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部１１０５によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンＧ２６には、アップデートに関する情報として含まれるデータ項目の"version"の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が２．０の最新バージョンにアップデートすることが記載されている。なお、設定画面Ｇ２に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
【００６２】
図７に戻り、設定画面（ステップＳ１３）において、設定ボタンＧ２６の選択操作が行われた場合、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面をディスプレイ１３に表示させる（ステップＳ１４）。
【００６３】
図１０は、確認画面Ｇ３の一例を示す概念図である。図１０に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行またはキャンセルの指示をユーザより受け付けるための操作ボタンＧ３５、Ｇ３４とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む構成である。アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の"version"の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、確認画面Ｇ３のアップデート表示Ｇ３３に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６４】
図１１は、確認ウインドウＧ３６の一例を示す概念図である。確認画面Ｇ３において、アップデートの実行を指示する操作ボタンＧ３５が選択された場合は、再度ユーザに確認を促す確認ウインドウＧ３６を表示してもよい。確認ウインドウＧ３６には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面Ｇ３では、アップデートの実行が指示された場合に確認ウインドウＧ３６を表示することで、ユーザへの注意喚起を促すことができる。なお、確認ウインドウ３６に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６５】
図７に戻り、アップデート部１１０３では、確認画面Ｇ３での操作ボタンＧ３４、Ｇ３５の選択操作をもとに、アップデートを実行するか否かを判定する（ステップＳ１５）。アップデートの実行を指示する操作ボタンＧ３５が選択された場合（ステップＳ１５：Ｙｅｓ）、アップデート部１１０３は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ１６）。
【００６６】
アップデートの実行をキャンセルする操作ボタンＧ３４が選択されるなどして、操作ボタンＧ３５の選択が行われなかった場合（ステップＳ１５：Ｎｏ）、アップデート部１１０３は、取得しているメタデータの"force_update"の記述をもとに、実行されなかったアップデートの中に強制のアップデートが含まれるか否かを判定する（ステップＳ１７）。強制のアップデートが含まれる場合（ステップＳ１７：Ｙｅｓ）、アップデート部１１０３は、自装置の処理を終了させる終了処理を行い（ステップＳ１８）、装置の電源を落とす。このように、強制のアップデートが実行されない場合は、通話すら実行できないこととなるため、装置の電源を落として無駄な操作が行われることを未然に防止する。逆に、強制のアップデートが含まれない場合（ステップＳ１７：Ｎｏ）、アップデート部１１０３は、現時点ではアップデートを実行しないことから、通常の動作を継続させる（ステップＳ１９）。これにより、ユーザは、アップデートよりも通話を優先することができる。
【００６７】
すなわち、通話端末１１では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部１１０２のユーザ通知部１１０４よりユーザに通知する。そして、通話端末１１では、操作入力受付部１１０５により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート部１１０３によるアップデート処理が実行される。したがって、通話端末１１は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。
【００６８】
一方、アップデート部１１０３は、実行可能なアップデートが存在しない場合（ステップＳ１０：Ｎｏ）は、事前ダウンロード可能なアップデートデータがあるか否かを判定する（ステップＳ２００）。ここで、アップデート部１１０３は、メタデータの"valid date"が現在時刻よりも未来に設定されたものがあるか否かにより、事前ダウンロード可能なアップデートデータがあるか否かを判定する。
【００６９】
アップデート部１１０３は、事前ダウンロード可能なデータがない場合（ステップＳ２００：Ｎｏ）、アップデートの実行および事前ダウンロードを行う必要がないことから、通常の動作を継続させる（ステップＳ１９）。また、アップデート部１１０３は、事前ダウンロード可能なデータがある場合（ステップＳ２００：Ｙｅｓ）、事前ダウンロード処理（ステップＳ２０２）を行い、その後に通常の動作を継続させる（ステップＳ１９）。
【００７０】
図１２は、アップデート部１１０３がユーザインタフェース部１１０２とともに行う事前ダウンロード処理を示す図である。
【００７１】
図１２において、アップデート部１１０３は、事前ダウンロード可能なデータがある場合、事前ダウンロードに関する情報をユーザインタフェース部１１０２に通知する（ステップＳ１０１）。
【００７２】
ユーザインタフェース部１１０２は、例えば図１３に示すような画面を表示することで、ユーザに事前ダウンロード可能なアップデートデータが存在することを通知する。つまり、ユーザインタフェース部１１０２は、事前ダウンロードに関する情報を設定画面に表示する（ステップＳ１０２）。
【００７３】
図１３に示すように、設定画面Ｇ４は、操作入力受付部１１０５によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンＧ２３〜Ｇ２５、Ｇ４２を表示する主画面Ｇ４１を含む構成である。設定ボタンＧ２３〜Ｇ２５、Ｇ４２の中で設定ボタンＧ４２がアップデートの実行を指示するためのボタンである。設定ボタンＧ４２には、事前アップデートに関する情報として含まれるデータ項目の"version"の記述をもとに、事前アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が２．１の最新バージョンに事前アップデート可能であることが記載されている。なお、設定画面Ｇ４に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
【００７４】
図１２に戻り、ユーザインタフェース部１１０２はビデオ会議アプリを実行（起動）すると（ステップＳ１０３）、図８に示したような、ビデオ会議の自らの開始や相手からの着信を待っている状態である起動画面（拠点一覧画面）になる。
【００７５】
次いで、ユーザインタフェース部１１０２はビデオ会議前であるか否か判定する（ステップＳ１０４）。すなわち、事前ダウンロードを自動的に行う場合、ビデオ会議が行われていない場合をはじめとする「ネットワーク帯域を必要とする状況ではない場合」に実施する必要がある。通話端末上の各アプリケーションが何をし、ネットワーク帯域にどういう影響のある処理をしているかの判断は難しい。そのため、確実にビデオ会議を行っておらず、ネットワーク帯域を使うような機能を使っていない状況を判断するため、ビデオ会議アプリケーションが起動されており、かつビデオ会議を開始していない状態であることを判断する。つまり、ビデオ会議アプリケーションが起動されていることで、他のアプリケーションの機能は排除されており、かつビデオ会議を開始していないことでネットワーク帯域を大きく消費している状態ではないことが明らかである。
【００７６】
ビデオ会議前である場合（ステップＳ１０４：Ｙｅｓ）、すなわち拠点一覧画面のときに事前ダウンロードを実施するものとし、ユーザインタフェース部１１０２はアップデート部１１０３に開始要求を行う。
【００７７】
開始要求を受け、アップデート部１１０３は、事前ダウンロードデータの有無を確認し（ステップＳ１０５）、すでに全部ダウンロードが終了し事前ダウンロードデータが存在しなかったとき（ステップＳ１０５：Ｎｏ）は事前ダウンロードを完了（ステップＳ１０６）し、ユーザインタフェース部１１０２に完了を通知する。
【００７８】
また、事前ダウンロードデータがあった場合（ステップＳ１０５：Ｙｅｓ）、アップデート部１１０３は、事前ダウンロードの開始位置を確認し（ステップＳ１０７）、事前ダウンロードを開始する（ステップＳ１０８）。図１４Ｂは開始位置を保持するダウンロード開始位置管理テーブルの例を示しており、アップデート部１１０３はこのダウンロード開始位置管理テーブルを参照することで開始位置を知ることができる。
【００７９】
図１２に戻り、ビデオ会議前でない場合（ステップＳ１０４：Ｎｏ）、ユーザインタフェース部１１０２で拠点一覧画面のままであれば事前ダウンロードは継続されるが、ビデオ会議が開始（ステップＳ１０９）されると、ユーザインタフェース部１１０２はアップデート部１１０３に事前ダウンロードの中断要求をする。
【００８０】
アップデート部１１０３は中断要求を受けると、中断のための処理を開始する（ステップＳ１１０）。ここで、もし分割データの半分以上をダウンロードした時点での中断要求であった場合（ステップＳ１１１：Ｙｅｓ）は、ダウンロード途中の分割データの終了までダウンロードを継続し（ステップＳ１１２）、終わり次第終了する（ステップＳ１１３）。中断要求がきたとき、ダウンロード量が分割データの半分以下であった場合（ステップＳ１１１：Ｎｏ）は、その時点で即座に中断し、終了する（ステップＳ１１３）。事前ダウンロードの中断に際し、開始位置の記録も行う。
【００８１】
図１４Ａは事前ダウンロードの中断の判断と再開時の開始位置の例を示している。すなわち、アップデート部１１０３は中断要求が来たとき、ダウンロード途中の分割データのどこまでダウンロードしているかを判断する。図１４Ａにおいて中断要求が来たときのダウンロード完了位置Ｐｆが分割データ＃４の半分以下である場合は、その分割データ＃４のダウンロードを中止（分割データ＃４の既にダウンロードした部分は破棄）し、再度、分割データ＃４をダウンロードしなおすために、次回ダウンロードの再開位置として分割データ＃４の先頭位置Ｐ４を図１４Ｂのダウンロード開始位置管理テーブルに保存する。もし、ダウンロード完了位置Ｐｆが分割データ＃４の半分以上の位置だった場合、アップデート部１１０３は分割データ＃４のダウンロードを継続し、分割データ＃４のダウンロードが終了してからダウンロードを中断する。そのときアップデート部１１０３は次回の開始位置（再開位置）として次の分割データ＃５の先頭位置Ｐ５をダウンロード開始位置管理テーブルに保存する。アップデート部１１０３はダウンロードの開始要求を受け取るとダウンロード開始位置管理テーブルに記載されている開始位置からダウンロードを再開する。
【００８２】
また、事前ダウンロードの中断の方法として、中断要求が来た瞬間からダウンロードによるネットワーク帯域への影響をなくすため、アップデート部１１０３は中断要求が来た場合にすぐに事前ダウンロードを中断する方法もある。この場合は図１４Ａにおいてダウンロード完了位置Ｐｆが分割データ＃４の半分以上・以下にかかわらず即座に中断する。そのため、アップデート部１１０３はダウンロード開始位置管理テーブルに分割データ＃４の先頭位置Ｐ４を保存する。なお、分割データが半分を超えるか否かにより判断する場合について説明したが、事前ダウンロードデータの全体について半分を超えるか否かにより判断するようにしてもよい。更に、分割データと事前ダウンロードデータの全体のいずれについても、半分を超えるか否かに代えて、他の所定値（割合）を超えるか否かで判断するようにしてもよい。
【００８３】
図１２に戻り、ビデオ会議が終了し（ステップＳ１１４）、そのままビデオ会議アプリケーションも終了した場合（ステップＳ１１５：Ｙｅｓ）、事前ダウンロードは一旦終了し、次にあらためてビデオ会議アプリが実行（ステップＳ１０３）されたときに事前ダウンロードを再開する。
【００８４】
ビデオ会議を終了してもビデオ会議アプリ自体を終了しない場合（ステップＳ１１５：Ｎｏ）は、拠点一覧画面に戻るため、再びユーザインタフェース部１１０２はアップデート部１１０３に対し開始要求をする（ステップＳ１０４：Ｙｅｓ）。アップデート部１１０３は事前ダウンロードデータの有無を確認（ステップＳ１０５）するところから再度処理を行う。
【００８５】
上記の処理例では条件が満たされた場合に事前ダウンロードを通話端末が自動的に行う場合について説明したが、ユーザが事前ダウンロードの実行ボタンを選択することにより実行することもできる。この場合、図１５のような事前ダウンロードの確認画面からダウンロードボタンＧ５３を選択することで実行することができる。この場合はダウンロード完了までユーザは待つことができるし、事前ダウンロードの実行中は図１６に示すようなキャンセルボタンにより途中でキャンセルすることもできる。ユーザの手動操作で事前ダウンロードを行う場合は、ダウンロードが完了するまでビデオ会議を開始できないようにすることで、ビデオ会議の品質低下を防ぐことができる。
【００８６】
次に、図１７を用いて、アップデート処理（図７に示すステップＳ１６）の詳細について説明する。
【００８７】
図１７において、アップデート部１１０３は、アップデート処理が開始されると、カメラ１２、マイク１４、スピーカ１５などの外部装置と接続するための撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム１０４が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート部１１０３は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。
【００８８】
次いで、アップデート部１１０３は、取得したメタデータの"files"からアップデートに用いるデータファイル（アップデートデータ）のファイルリストと、それらファイルのチェックサムとを取得する（ステップＳ１５０１）。依存関係を有する複数のバージョンのメタデータを取得している場合、アップデート部１１０３は、バージョン番号が古いものから順にステップＳ１５０１〜Ｓ１５０８の処理を行う。
【００８９】
次いで、アップデート部１１０３は、取得したメタデータの"valid  date"に記述されたアップデートが実行可能となる日時に基づいて、取得したメタデータに対応するデータファイル（アップデートデータ）を用いたアップデートが実行可能か否かを判断する（ステップＳ１５０２）。本実施形態では、アップデート部１１０３は、取得したメタデータの"valid  date"に記述された日時が、例えばＮＴＰサーバまたは自装置が備える計時部などから取得した現在日時よりも以前の日時である場合には、取得したメタデータに対応するデータファイル（アップデートデータ）を用いたアップデートが実行可能であると判断する。
【００９０】
取得したメタデータに対応するデータファイルを用いたアップデートが実行可能であると判断した場合（ステップＳ１５０２：Ｙｅｓ）、アップデート部１１０３は、当該取得したメタデータに対応するデータファイルが事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みであるか否か、すなわち、当該取得したメタデータに対応するデータファイルが事前ダウンロードデータであるか否かを判断する（ステップＳ１５０３）。
【００９１】
事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みでないと判断した場合（ステップＳ１５０３：Ｎｏ）、アップデート部１１０３は、ステップＳ１５０１で取得したファイルリストのデータファイル（アップデートデータ）をアップデートサーバ６０から取得するとともに（ステップＳ１５０４）、取得したデータファイルのチェックサムを取得する（ステップＳ１５０５）。一方、事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みであると判断した場合（ステップＳ１５０３：Ｙｅｓ）、アップデート部１１０３は、事前ダウンロード処理によりダウンロード済みのデータファイル（事前ダウンロードデータ）をダウンロード先（例えば、記憶部１０５）から取得し、取得したデータファイルのチェックサムを取得する（ステップＳ１５０５）。次いで、アップデート部１１０３は、取得したデータファイルを用いて、記憶部１０５に記憶されたプログラム１０４のアップデートを実行する。
【００９２】
次いで、アップデート部１１０３は、アップデートの進行状況をユーザインタフェース部１１０２に通知する（ステップＳ１５０６）。この進行状況の通知は、ファイルリストに含まれる複数のデータファイルの中で、どのデータファイルまでステップＳ１５０４、Ｓ１５０５の処理を終えたかを通知する。また、依存関係を有する複数のバージョンのアップデートを行う場合には、どのバージョンのアップデートまでを終えたかを通知してもよい。ユーザインタフェース部１１０２では、通知されたアップデートの進行状況をディスプレイ１３に画面表示してユーザに通知する。
【００９３】
図１８は、通話端末により表示されるアップデート画面の一例を示す図である。図１８に示すように、アップデート画面Ｇ６は、アップデート部１１０３によるアップデート処理中にユーザインタフェース部１１０２がディスプレイ１３に表示させる画面である。アップデート画面Ｇ６には、アップデート部１１０３より通知されたアップデートの進行状況を表示するアップデートステータスウインドウＧ６１と、アップデートの中止を指示するための操作ボタンＧ６２と、が表示される。ユーザは、アップデートステータスウインドウＧ６１の表示内容により、アップデートの進行状況を確認できる。
【００９４】
また、ユーザインタフェース部１１０２は、アップデート画面Ｇ６に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するようにしてもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。
【００９５】
図１７に戻り、アップデート部１１０３は、アップデート処理のエラーの発生の有無を判定し（ステップＳ１５０７）、アップデート処理にエラーの発生がある場合（ステップＳ１５０７：Ｙｅｓ）は、ステップＳ１５０９に示す処理に進む。本実施形態では、アップデート部１１０３は、アップデート処理の実行中に何らかの要因で発生するエラー（例えば、ステップＳ１５０５により取得したチェックサムと、ステップＳ１５０１で取得したチェックサムとの相違）の他、アップデート画面Ｇ６の操作ボタンＧ６２の操作によるアップデートの中止や、ステップＳ１５０４およびステップＳ１５０５で行ったアップデートのバージョンが再起動を要する場合にもエラーとして判定される。したがって、バージョン番号が古いものから順にアップデートが行われる場合には、再起動を要するバージョンのアップデートまでが行われた段階で、ステップＳ１５０１〜Ｓ１５０８の処理を抜けることとなる。
【００９６】
アップデート処理にエラーの発生がない場合（ステップＳ１５０７：Ｎｏ）、アップデート部１１０３は、取得したメタデータにかかる、全てのバージョンのアップデートが完了したか否かを判定する（ステップＳ１５０８）。全てのバージョンのアップデートが完了していない場合（ステップＳ１５０８：Ｎｏ）には、ステップＳ１５０１へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合（ステップＳ１５０８：Ｙｅｓ）には、ステップＳ１５０９に進む。
【００９７】
アップデート部１１０３は、アップデートの結果をユーザインタフェース部１１０２へ通知する（ステップＳ１５０９）。ユーザインタフェース部１１０２では、通知されたアップデートの結果をディスプレイ１３に画面表示してユーザに通知する。
【００９８】
図１９は、通話端末により表示される確認画面の一例を示す図である。アップデートの結果を受けたユーザインタフェース部１１０２は、図１９に示すように、アップデート結果Ｇ７１や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンＧ７２、Ｇ７３を確認画面Ｇ７に表示する。アップデート結果Ｇ７１には、アップデート前のバージョンにかかる情報の他、アップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果Ｇ７１の表示内容により、ユーザは、アップデートの結果を確認できる。
【００９９】
図１７に戻り、アップデート部１１０３は、アップデートに用いたアップデートデータのメタデータに含まれる、"reboot"の記述を基に、情報処理装置１１の再起動が必要であるか否かを判定する（ステップＳ１５１０）。情報処理装置１１の再起動が必要でない場合（ステップＳ１５１０：Ｎｏ）、アップデート部１１０３は、情報処理装置１１を再起動することなくアップデート処理を終了する。情報処理装置１１の再起動が必要である場合（ステップＳ１５１０：Ｙｅｓ）、アップデート部１１０３は、情報処理装置１１を再起動させる（ステップＳ１５１１）。このように、再起動が必要なアップデートが実行された場合は、ユーザが操作することなく、アップデート後に再起動されることとなる。
【０１００】
＜総括＞
以上説明したように、本実施形態によれば、ビデオ会議等の意図しない品質の低下を避けることができる。
【０１０１】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【０１０２】
通信装置を実施例により説明したが、本発明は上記実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内で種々の変形及び改良が可能である。
【０１０３】
本国際出願は、２０１３年１１月５日に出願した日本国特許出願２０１３−２２９１０５号に基づく優先権を主張するものであり、２０１３−２２９１０５号の全内容をここに本国際出願に援用する。
【符号の説明】
【０１０４】
１            通信システム
２            通信ネットワーク
１１          通話端末
１２          カメラ
１３          ディスプレイ
１４          マイク
１５          スピーカ
３０          中継装置
５０          通信管理サーバ
６０          アップデートサーバ
６０１        送受信部
６０２        アップデートデータ提供部
１１０１      送受信部
１１０２      ユーザインタフェース部
１１０３      アップデート部
１１０４      ユーザ通知部
１１０５      操作入力受付部
【図１】
2015068460.tif 000003
【図２】
2015068460.tif 000004
【図３】
2015068460.tif 000005
【図４】
2015068460.tif 000006
【図５】
2015068460.tif 000007
【図６】
2015068460.tif 000008
【図７】
2015068460.tif 000009
【図８】
2015068460.tif 000010
【図９】
2015068460.tif 000011
【図１０】
2015068460.tif 000012
【図１１】
2015068460.tif 000013
【図１２】
2015068460.tif 000014
【図１３】
2015068460.tif 000015
【図１４Ａ】
2015068460.tif 000016
【図１４Ｂ】
2015068460.tif 000017
【図１５】
2015068460.tif 000018
【図１６】
2015068460.tif 000019
【図１７】
2015068460.tif 000020
【図１８】
2015068460.tif 000021
【図１９】
2015068460.tif 000022
【手続補正書】
【提出日】平成28年11月28日(2016.11.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アップデートに用いるアップデートデータのメタデータを受信する受信手段と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段と
を備え、
前記制御手段は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理手段は事前ダウンロードを開始または再開する
たことを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記制御手段は、ビデオ会議が開始された場合に、事前ダウンロードを実施するタイミングでないと判断し、前記アップデート処理手段は事前ダウンロードを中断する
ことを特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記アップデート処理手段は、前記制御手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量がダウンロード中のデータの半分以上の場合はダウンロード中のデータをすべてダウンロードしてから中断する
ことを特徴とする通信装置。
【請求項４】
請求項２に記載の通信装置において、
前記アップデート処理手段は、前記制御手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量がダウンロード中のデータの半分以下の場合はダウンロード中のデータを破棄してダウンロードを中断する
ことを特徴とする通信装置。
【請求項５】
請求項２に記載の通信装置において、
前記アップデート処理手段は、前記制御手段が事前ダウンロードを実施するタイミングでないと判断して事前ダウンロードを中断する場合、ダウンロードしたデータ量にかかわらず即座にダウンロードを中断する
ことを特徴とする通信装置。
【請求項６】
請求項３乃至５のいずれか一項に記載の通信装置において、
前記データは分割データとし、前記データ量は当該分割データ中のダウンロードしたデータ量とする
ことを特徴とする通信装置。
【請求項７】
ネットワークを介して接続可能なアップデートサーバと通信装置とを備えた通信システムであって、
前記アップデートサーバは、
前記通信装置からの要求に応じてアップデートデータおよびメタデータを提供する提供手段
を備え、
前記通信装置は、
アップデートに用いるアップデートデータのメタデータを受信する受信手段と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段と
を備え、
前記制御手段は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理手段は事前ダウンロードを開始または再開する
たことを特徴とする通信システム。
【請求項８】
アップデートに用いるアップデートデータのメタデータを受信する受信工程と、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断工程と、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御工程と、
前記判断工程により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御工程により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理工程と
を備え、
前記制御工程は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理工程は事前ダウンロードを開始または再開する
たことを特徴とする通信方法。
【請求項９】
通信装置を構成するコンピュータを、
アップデートに用いるアップデートデータのメタデータを受信する受信手段、
前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段、
前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段、
前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段
として機能させ、
前記制御手段は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理手段は事前ダウンロードを開始または再開する
通信プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上記の課題を解決するため、本発明にあっては、アップデートに用いるアップデートデータのメタデータを受信する受信手段と、前記メタデータの記述に基づいて、アップデートが開始可能な時点よりも前にアップデートデータのダウンロードを実行する事前ダウンロードの対象となるアップデートデータがあるか否かを判断する判断手段と、前記事前ダウンロードを実施するタイミングであるか否かを判断する制御手段と、前記判断手段により前記事前ダウンロードの対象となるアップデートデータがあると判断され、かつ前記制御手段により事前ダウンロードを実施するタイミングであると判断された場合に、当該アップデートデータのダウンロードを行うアップデート処理手段とを備え、前記制御手段は、ビデオ会議アプリケーションが起動され、かつビデオ会議が開始されていない場合に、事前ダウンロードを実施するタイミングであると判断し、前記アップデート処理手段は事前ダウンロードを開始または再開する。
【国際調査報告】
2015068460.tif 000023
2015068460.tif 000024
2015068460.tif 000025
2015068460.tif 000026