以下に添付図面を参照して、実施形態にかかる通信システムを詳細に説明する。
(実施の形態)
図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は、通話端末(第1通信装置)11のプログラムや各種設定情報のアップデートにかかる情報を管理し、通話端末11の要求に応じてその情報を提供するアップデート情報提供装置(第2通信装置)である。アップデートにかかる情報を示す関連情報としては、通話端末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は、CPU101(Central Processing Unit)、ROM102(Read Only Memory)、RAM103(Random Access Memory)、記憶部105、メディアドライブ107、操作部108、ネットワークI/F111、撮像素子I/F112、音声入出力I/F113及びディスプレイI/F114を備え、各部がバス110により互いに接続される構成である。
CPU101は、ROM102や記憶部105に記憶されたプログラム104をRAM103に展開して順次実行することで、通話端末11の動作を中央制御する。記憶部105は、HDD(Hard Disk Drive)やSSD(Solid State Drive)などであり、読み出し/書き込み可能にデータを記憶する。具体的には、記憶部105は、CPU101が実行するためのプログラム104や各種設定情報を記憶する。アップデートの際には、この記憶部105に記憶されるプログラム104や各種設定情報が更新される。
メディアドライブ107は、光ディスクなどのメディア106の読み出し/書き込みを行うドライブ装置である。操作部108は、キーボード、各種操作キー、ディスプレイ13上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークI/F111は、通信ネットワーク2と接続してデータ通信を行うインタフェースである。撮像素子I/F112は、デジタルカメラであるカメラ12と接続し、カメラ12が撮像した画像を取得するためのインタフェースである。音声入出力I/F113は、マイク14、スピーカ15と接続し、マイク14による音声入力や、スピーカ15を介した音声出力を行うインタフェースである。ディスプレイI/F114は、LCD(Liquid Crystal Display)などであるディスプレイ13と接続し、ディスプレイ13へ表示データを出力するインタフェースである。
なお、本実施の形態では、ディスプレイ13を用いているが、ディスプレイ13に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。
通話端末11は、プログラム104を実行したCPU101の制御の下、例えば他の通話端末との通話時には、カメラ12から取得した画像やマイク14から入力された音声をネットワークI/F111を介して中継装置30へ出力する。また、中継装置30より中継され、ネットワークI/F111を介して入力された他の通話端末からの音声をスピーカ15より出力し、同様に他の通話端末からの画像をディスプレイ13により表示する。これにより、通話端末11は、画像及び音声による他の通話端末との通話、いわゆるテレビ会議を実現する。なお、通話端末11は、汎用のPC(Personal Computer)、スマートフォン、携帯電話及びタブレット端末などの通信端末であってもよい。
次に、中継装置30、通信管理サーバ50、アップデートサーバ60のハードウエア構成を説明する。図3は、中継装置30、通信管理サーバ50、アップデートサーバ60のハードウエア構成を例示するブロック図である。図3に示すように、中継装置30、通信管理サーバ50、アップデートサーバ60は、CPU201、ROM202、RAM203、記憶部204、ディスプレイ205、ネットワークI/F206、キーボード207、マウス208、メディアドライブ209及びCD−ROMドライブ211を備え、各部がバス214により互いに接続される構成である。中継装置30、通信管理サーバ50、アップデートサーバ60は、いわゆるPC(Personal Computer)やWS(Work Station)などの機器である。
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の機能構成について説明する。図4は、実施の形態の通話端末11及びアップデートサーバ60の機能構成を例示するブロック図である。図4に示すように、通話端末11は、送受信部1101、ユーザインタフェース部1102、アップデート部1103及びアプリケーション状態判断部(判断部)1110を主に有している。アップデートサーバ60は、送受信部601及びアップデートデータ提供部602を主に有している。なお、通話端末11及びアップデートサーバ60の各機能は、一部又は全部がハードウェアで構成されてもよい。
送受信部1101は、通信ネットワーク2を介してアップデートサーバ60との間でデータの送受信を行う。具体的には、送受信部1101は、記憶部105の設定情報などに予め設定されているアップデートサーバ60の通信アドレスや通信管理サーバ50へ問い合わせて取得したアップデートサーバ60の通信アドレスをもとに、アップデートサーバ60との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ60との間でデータの送受信を行う。このデータの送受信により、送受信部1101は、アップデートサーバ60が管理しているアップデートにかかる情報(例えばメタデータ及びアップデートデータなど)を取得する。
ユーザインタフェース部1102は、スピーカ15による音声出力、ディスプレイ13の表示画面、操作部108によるユーザの操作入力の受け付けなどを制御して、ユーザと通話端末11との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部1102は、スピーカ15による音声出力やディスプレイ13の表示画面でユーザへの各種通知を行うユーザ通知部1104と、操作部108によるユーザの操作入力を受け付ける操作入力受付部1105とを有する。
アップデート部1103は、送受信部1101によりアップデートサーバ60から取得したアップデートにかかる情報を示す関連情報(メタデータ)に基づいて、後述するアプリケーション状態判断部1110の判断結果に応じて、記憶部105が記憶するプログラム104や各種設定情報のアップデート(アップデートデータのダウンロードを含む)を制御して実行する。アップデート部1103が実行するアップデートについては、後述するアップデート処理(図6のステップS16)において詳細に説明する。
アプリケーション状態判断部1110は、例えばビデオ会議を実行するアプリケーションの起動状態や実行状態を判断し、管理する。例えば、アプリケーション状態判断部1110は、通話端末11におけるアプリケーションの実行状態を判断する。アプリケーションの実行状態には、例えば、ネットワークを介して他の通話端末11と画像及び音声の通信を開始したことを示す状態(例えば、ビデオ会議を開始したことを示す状態)、画像及び音声を通信中であることを示す状態(例えば、ビデオ会議を実行中であることを示す状態)、並びに画像及び音声の通信を終了したことを示す状態(例えばビデオ会議を終了したことを示す状態)などが含まれる。さらに、アプリケーション状態判断部1110は、通信ネットワーク2で使用可能な通信帯域、及びネットワークを介して他の通話端末11と画像及び音声の通信を行うために必要な帯域がそれぞれどのような状態であるかを判断する。なお、本実施形態においては、「ビデオ会議」は、「テレビ会議」と置き換え可能な用語として用いられている。また、通信は、画像と音声のどちらか一方のみであってもよい。
送受信部601は、通信ネットワーク2を介して通話端末11との間でデータの送受信を行う。具体的には、送受信部601は、通信ネットワーク2を介した通話端末11の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末11との間でデータの送受信を行う。
アップデートデータ提供部602は、送受信部601によってデータの送受信を行っている通話端末11からの要求に応じて、アップデートサーバ60が管理しているアップデートにかかる情報を通話端末11に提供する。
図5は、アップデートデータ提供部602の動作を示す図である。図5に示すように、アップデートデータ提供部602は、通話端末11からメタデータの要求を受信する(ステップS600)。
アップデートデータ提供部602は、メタデータの要求を受信すると、現在アップデートを実行可能なデータ(実行可能データ)のメタデータを生成する(ステップS602)。
さらに、アップデートデータ提供部602は、事前ダウンロードの対象となるデータがあるか否かを判定する(ステップS604)。ここで、事前ダウンロードの対象となるデータとは、現在アップデートを実行できないが、アップデート可能日時に対し、事前(アップデート可能日時以前)にダウンロードが可能なアップデートデータである。つまり、事前ダウンロードの対象となるデータは、例えばビデオ会議を実行するアプリケーションのアップデートを行う以前に予めダウンロード可能なアップデートデータである。事前ダウンロードは、アップデートの実行時にアップデートサーバ60に対するアクセスが集中してしまうことを防止することを可能にする。
アップデートデータ提供部602は、事前にダウンロード可能なアップデートデータがあるか否かを、後述する図10に示すメタデータに含まれる”valid date”の時刻が、現在時刻よりも未来であるか否かによって判断する。アップデートデータ提供部602は、現在時刻を、例えばNTP(Network Time Protocol)サーバから取得してもよいし、機器に内蔵されている時計から取得してもよい。
アップデートデータ提供部602は、事前にダウンロード可能なアップデートデータがあると判断した場合(ステップS604:YES)、事前ダウンロード対象のアップデートデータのメタデータを生成する(ステップS606)。そして、アップデートデータ提供部602は、現在アップデートを実行可能なデータのメタデータとともに、事前ダウンロード対象のアップデートデータのメタデータを通話端末11へ送信する(ステップS608)。
また、アップデートデータ提供部602は、事前にダウンロード可能なアップデートデータがないと判断した場合(ステップS604:NO)、現在アップデートを実行可能なデータのメタデータのみを通話端末11へ送信する(ステップS608)。
次に、通話端末11の動作について詳細に説明する。図6は、実施の形態の通話端末11の動作の一例を示す図である。
図6に示すように、ユーザインタフェース部1102は、操作部108の電源スイッチなどの操作に応じて自装置の電源投入(電源オン)を行い(ステップS1)、起動画面をディスプレイ13に表示させる(ステップS2)。この起動画面は、CPU101の制御の下で通信管理サーバ50へ問い合わせて得られた各通話端末11の通話状態を一覧表示した表示画面である(詳細は後述する)。
アップデート部1103は、S1による電源投入後の起動時において、自装置のアップデートの確認を開始する(ステップS3)。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。
アップデートの確認が開始されると、アップデート部1103は、送受信部1101によって、最新バージョンのプログラムのメタデータをアップデートサーバ60に対して要求し(ステップS4)、その要求に対応してアップデートデータ提供部602が提供するメタデータを取得する(ステップS5)。
ここで、メタデータの詳細について説明する。図10は、メタデータの一例を示す概念図である。メタデータは、アップデートデータが、アプリケーションのアップデートを行う以前に予めダウンロード可能な事前ダウンロードデータであることを示す情報を含む場合がある。例えば、図10に示すように、各バージョンのメタデータは、“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”には、アップデートサーバ60が管理しているアップデートの実体となるプログラム(データファイル)のリストとその格納先や、それらデータファイルのチェックサムなどが記述される。したがって、アップデート部1103は、“files”のデータ項目に記述された内容をもとに、送受信部1101によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。“scriptname”には、アップデートを実行する際に実行するスクリプト名が記述される。“require_reboot”には、アップデートを実行した後に、装置の再起動を行うか否かを示すフラグ(“true”又は“false”)が記述される。“force_update”には、強制のアップデートであるか否かを示すフラグ(“true”又は“false”)が記述される。“valid date”には、アップデートデータが実行可能となる日時が記述される。つまり、“valid date”は、アップデートデータが事前ダウンロードデータであるか否かを判断可能にする情報である。“data size”には、アップデートデータのサイズが記述される。
プログラム104のアップデートには、ネットワークI/F111、撮像素子I/F112、音声入出力I/F113、ディスプレイI/F114等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“require_reboot”に“true”が記述される。また、プログラム104のアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“force_update”に“true”が記述される。
次いで、アップデート部1103は、取得したメタデータの“dependency”のデータ項目に記述された内容をもとに、依存するバージョンの有無を確認する(ステップS6)。例えば、図10に示すように、“dependency”のデータ項目に“1.0.0”などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、“dependency”のデータ項目に何も記述がない場合には、依存するバージョンがないものとする。
次いで、アップデート部1103は、S6による確認の結果、依存するバージョンが有るか否かを判定する(ステップS7)。依存するバージョンがある場合(ステップS7:YES)、アップデート部1103は、送受信部1101によって、依存するバージョンのプログラムのメタデータをアップデートサーバ60に対して要求し(ステップS8)、その要求に対応してアップデートデータ提供部602が提供する、依存するバージョンのメタデータを取得して(ステップS9)、S6へ処理を戻す。したがって、アップデート部1103は、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。
次いで、アップデート部1103は、”valid date”が現在時刻よりも前に設定された最新バージョンのメタデータの“version”に記述されたバージョン番号と、自装置の記憶部105に記憶されたプログラム104のバージョン番号とを比較することで、自装置の実行可能なアップデートが存在するか否かを判定する(ステップS10)。具体的には、最新バージョンのバージョン番号と、プログラム104のバージョン番号とが一致する場合は、プログラム104が最新バージョンであることから、実行可能なアップデートが存在しないと判定する。
また、アップデート部1103は、最新バージョンのバージョン番号と、プログラム104のバージョン番号とが一致しない場合は、プログラム104が古いバージョンであることから、実行可能なアップデートが存在すると判定する。
アップデート部1103は、実行可能なアップデートが存在しない場合(ステップS10:NO)は、事前ダウンロード可能なアップデートデータがあるか否かを判定する(ステップS200)。ここで、アップデート部1103は、メタデータの”valid date”が現在時刻よりも未来に設定されたものがあるか否かにより、事前ダウンロード可能なアップデートデータがあるか否かを判定する。
アップデート部1103は、事前ダウンロード可能なデータがない場合(ステップS200:No)、アップデートの実行及び事前ダウンロードを行う必要がないことから、通常の動作を継続させる(ステップS19)。また、アップデート部1103は、事前ダウンロード可能なデータがある場合(ステップS200:YES)、事前ダウンロード処理(ステップS202)を行い、その後に通常の動作を継続させる(ステップS19)。
図7は、アップデート部1103がユーザインタフェース部1102とともに行う事前ダウンロード処理を示す図である。アップデート部1103は、事前ダウンロード可能なデータがある場合、事前ダウンロードに関する情報をユーザインタフェース部1102に通知する(ステップS250)。
ユーザインタフェース部1102は、例えば図8に示すような画面を表示することで、ユーザに事前ダウンロード可能なアップデートデータが存在することを通知する。つまり、ユーザインタフェース部1102は、事前ダウンロードに関する情報を設定画面に表示する(ステップS252)。
図8に示すように、設定画面G2は、操作入力受付部1105によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンG22〜G25を表示する主画面G21を含む構成である。設定ボタンG22〜G25の中で設定ボタンG22がアップデートの実行を指示するためのボタンである。設定ボタンG22には、事前アップデートに関する情報として含まれるデータ項目の“version”の記述をもとに、事前アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が2.1の最新バージョンに事前アップデート可能であることが記載されている。なお、設定画面G2に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
ユーザインタフェース部1102は、設定ボタンG22〜G25のいずれかを選択する入力を受け付けると(ステップS253)、例えば図9に示すような事前ダウンロードの設定画面を表示する(ステップS254)。図9に示した事前ダウンロードの設定画面G200は、事前ダウンロード可能なアップデートデータの内容を表示する事前アップデート表示G201と、その内容での事前アップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンG202、G203とを含む。
ユーザインタフェース部1102は、図9に示した事前ダウンロード設定画面から、事前ダウンロードの実行ボタンをユーザが選択することにより、事前ダウンロードの実行を指示する入力を受入れる(ステップS255)。そして、ユーザインタフェース部1102は、ユーザから受入れた実行を指示する入力の有無に応じて、事前ダウンロードを実行するか否かを判定する(ステップS256)。
ユーザインタフェース部1102がS255の処理において実行を指示する入力を受入れた場合(ステップS256:YES)、アップデート部1103は、現在ビデオ会議が行われているかどうかを判定する(ステップS258)。ここで、アップデート部1103は、ビデオ会議が行われているかどうかを、アプリケーション状態判断部1110からのビデオ会議状態通知により判断する。また、ユーザインタフェース部1102は、S255の処理において実行を指示する入力以外の入力を受入れた場合(ステップS256:NO)、事前ダウンロードを実行させない。
アップデート部1103は、ビデオ会議中であると判断した場合(ステップS258:YES)、処理を継続する。つまり、アップデート部1103は、ビデオ会議中である場合には、ビデオ会議が終了するまでダウンロードを実行しない。
また、アップデート部1103は、ビデオ会議中でないと判断した場合(ステップS258:NO)、アップデートデータのダウンロードを開始し、アップデートデータを通話端末11内の記憶部105に記憶させる(ステップS260)。
なお、ここでは、ユーザ操作により事前ダウンロードの実行を判断する例を記載したが、事前ダウンロードがある場合、ユーザの判断を介さずにアップデート部1103が事前ダウンロードの実行を判断してもよい。また、S258の処理においては、ビデオ会議が行われているかどうかを判定する場合を例に説明したが、アップデート部1103は、画像及び音声の少なくとも1つのデータ通信が開始、終了及び通信中のいずれの状態であるかを判定し、アップデートの再開及び停止を制御するように構成されてもよい。
図11は、ビデオ会議中にビデオ会議の状態が変化する場合のアプリケーション状態判断部1110及びアップデート部1103の動作を示す図である。アップデート部1103は、事前ダウンロードを開始する(ステップS300)。アプリケーション状態判断部1110は、ビデオ会議が開始されると判断すると、ビデオ会議の開始をアップデート部1103に対して通知する(ステップS302)。
アップデート部1103は、事前ダウンロード中にアプリケーション状態判断部1110からビデオ会議などのアプリケーション開始の通知を受けた場合、事前ダウンロードを停止する(ステップS304)。
アプリケーション状態判断部1110は、ビデオ会議が終了されると判断すると、ビデオ会議の終了をアップデート部1103に対して通知する(ステップS306)。
アップデート部1103は、アプリケーション状態判断部1110からビデオ会議の終了を通知された場合、事前ダウンロードを再開する(ステップS308)。なお、アプリケーション状態判断部1110は、画像及び音声の少なくとも1つのデータ通信が開始、終了及び通信中のいずれの状態であるかを判定し、アップデート部1103に対してアップデートの再開及び停止を制御するように構成されてもよい。
図6に戻り、自装置のアップデートが存在する場合(ステップS10:YES)、アップデート部1103は、そのアップデートに関する情報をユーザインタフェース部1102へ通知する(ステップS11)。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“files”、“scriptname”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部1102へ通知する。
ユーザインタフェース部1102のユーザ通知部1104では、S11においてアップデート部1103より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ13の起動画面に表示して、ユーザへ通知する(ステップS12)。
ここで、起動画面の詳細について説明する。図12は、起動画面G1の一例を示す概念図である。図12に示すように、起動画面G1は、各通話端末の通話状態を一覧表示する主画面G11と、自装置のステータスを表示するステータス画面G12とを含む構成である。ユーザ通知部1104は、アップデートに関する情報がアップデート部1103より通知された場合は、ステータス画面G12にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面G11に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例(図8、12〜15等)において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。
また、ユーザ通知部1104は、アップデートに関する情報として含まれるデータ項目の中で“force_update”の記述が“true”である場合は、自装置に存在するアップデートが強制のアップデートであることを起動画面G1に表示してユーザに通知する。具体的には、アップデートが強制のアップデートである旨をステータス画面G12に表示してもよいし、主画面G11に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。
S12によるユーザへの通知によって、ユーザインタフェース部1102の操作入力受付部1105によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部1102は、設定画面をディスプレイ13に表示させる(ステップS13)。
図13は、設定画面G2の一例を示す概念図である。図13に示すように、設定画面G2は、操作入力受付部1105によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンG23〜G26を表示する主画面G21を含む構成である。設定ボタンG23〜G26の中で設定ボタンG26がアップデートの実行を指示するためのボタンである。この設定ボタンG26は、アップデートに関する情報がアップデート部1103より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。逆に、アップデートに関する情報がアップデート部1103より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部1105によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンG26には、アップデートに関する情報として含まれるデータ項目の“version”の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が2.0の最新バージョンにアップデートすることが記載されている。なお、設定画面G2に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
S13において、設定ボタンG26の選択操作が行われた場合、ユーザインタフェース部1102は、アップデートの実行を確認する確認画面をディスプレイ13に表示させる(ステップS14)。
図14は、確認画面G3の一例を示す概念図である。図14に示すように、確認画面G3は、実行するアップデートの内容を表示するアップデート表示G33と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンG34、G35とを含む主画面G31と、自装置のステータスを表示するステータス画面G32とを含む構成である。アップデート表示G33には、自装置のプログラム104のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の“version”の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示G33の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、確認画面G3のアップデート表示G33に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
図15は、確認ウインドウG36の一例を示す概念図である。確認画面G3において、アップデートの実行を指示する操作ボタンG35が選択された場合は、再度ユーザに確認を促す確認ウインドウG36を表示してもよい。確認ウインドウG36には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面G3では、アップデートの実行が指示された場合に確認ウインドウG36を表示することで、ユーザへの注意喚起を促すことができる。なお、確認ウインドウ36に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
図6に戻り、アップデート部1103では、確認画面G3での操作ボタンG34、G35の選択操作をもとに、アップデートを実行するか否かを判定する(ステップS15)。アップデートの実行を指示する操作ボタンG35が選択された場合(ステップS15:YES)、アップデート部1103は、取得しているメタデータをもとにアップデート処理を実行する(ステップS16)。
アップデートの実行をキャンセルする操作ボタンG34が選択されるなどして、操作ボタンG35の選択が行われなかった場合(ステップS15:NO)、アップデート部1103は、取得しているメタデータの“force_update”の記述をもとに、実行されなかったアップデートの中に強制のアップデートが含まれるか否かを判定する(ステップS17)。強制のアップデートが含まれる場合(ステップS17:YES)、アップデート部1103は、自装置の処理を終了させる終了処理を行い(ステップS18)、装置の電源を落とす。このように、強制のアップデートが実行されない場合は、通話すら実行できないこととなるため、装置の電源を落として無駄な操作が行われることを未然に防止する。逆に、強制のアップデートが含まれない場合(ステップS17:NO)、アップデート部1103は、現時点ではアップデートを実行しないことから、通常の動作を継続させる。これにより、ユーザは、アップデートよりも通話を優先することができる。
すなわち、通話端末11では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部1102のユーザ通知部1104よりユーザに通知する。そして、通話端末11では、操作入力受付部1105により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート部1103によるアップデート処理が実行される。したがって、通話端末11は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。
ここで、アップデート処理(ステップS16)の詳細について説明する。図16は、通話端末11が実行するアップデート処理の一例を示す図である。
図16に示すように、アップデート部1103は、アップデート処理を開始すると(ステップS100)、カメラ12、マイク14、スピーカ15などの外部装置と接続するための撮像素子I/F112、音声入出力I/F113等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム104が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート部1103は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。
次いで、アップデート部1103は、取得した全てのメタデータの“files”からアップデートの実体となるプログラムのファイルリストと、それらファイルのチェックサムとを取得する(ステップS101)。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にS101〜S106の処理が行われるものとする。
次いで、アップデート部1103は、メタデータの”valid date”に基づいてアップデートが実行可能か否かを判断する(ステップS350)。例えば、アップデート部1103は、端末がNTP(Network Time Protocol)サーバから取得した現在時刻と、”valid date”に記載されている時刻を比較して、”valid date”が過去の時刻であれば実行可能と判断する。
アップデート部1103は、実行可能でないと判断した場合(ステップS350:NO)、S101の処理に戻る。また、アップデート部1103は、実行可能と判断した場合(ステップS350:YES)、そのデータを事前ダウンロードで取得済みかどうかを判定する(ステップS352)。
アップデート部1103は、データを事前ダウンロードで取得済みである場合(ステップS352:YES)、取得した全てのファイル(ダウンロードしたアップデートデータ)のチェックサムを確認する(ステップS103)。アップデート部1103は、データを事前ダウンロードで取得済みでない場合(ステップS352:NO)、ファイルリストのファイルをアップデートサーバ60から取得し(ステップS102)、取得したファイルのチェックサムを確認する(ステップS103)。
次いで、アップデート部1103は、アップデートの進行状況をユーザインタフェース部1102に通知する(ステップS104)。この進行状況の通知は、ファイルリストに含まれる複数のファイルの中で、どのファイルまでS102、S103の処理を終えたかを通知する。また、依存関係を有する複数のバージョンのアップデートを行う場合には、どのバージョンのアップデートまでを終えたかを通知してもよい。ユーザインタフェース部1102では、通知されたアップデートの進行状況をディスプレイ13に画面表示してユーザに通知する。
図17は、アップデート画面G4の一例を示す概念図である。図17に示すように、アップデート画面G4は、アップデート部1103によるアップデート処理中にユーザインタフェース部1102がディスプレイ13に表示させる画面である。アップデート画面G4には、アップデート部1103より通知されたアップデートの進行状況を表示するアップデートステータスウインドウG41と、アップデートの中止を指示するための操作ボタンG42とが表示される。ユーザは、アップデートステータスウインドウG41の表示内容により、アップデートの進行状況を確認できる。
なお、この他、アップデート画面G4に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するように構成してもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。
次いで、アップデート部1103は、エラーの発生の有無を判定し(ステップS105)、エラーの発生がある場合(ステップS105:YES)はS101〜S106の処理を抜けてS107へ処理を進める。このS105では、アップデート実行中に何らかの要因で発生するエラー(例えば、S103におけるチェックサムの相違)の他、アップデート画面G4の操作ボタンG42の操作によるアップデートの中止や、S102、S103で行ったアップデートのバージョンが再起動を要する場合にもエラーとして判定される。したがって、バージョン番号が古いものから順にアップデートが行われる場合には、再起動を要するバージョンのアップデートまでが行われた段階で、S101〜S106の処理を抜けることとなる。
エラーの発生がない場合(ステップS105:NO)、アップデート部1103は、取得したメタデータにかかる、全てのバージョンのアップデートが完了したか否かを判定する(ステップS106)。全てのバージョンのアップデートが完了していない場合(ステップS106:NO)には、S101へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合(ステップS106:YES)には、S101〜S106の処理を抜け、S107へ処理を進める。
S107において、アップデート部1103は、S101〜S106によるアップデートの結果をユーザインタフェース部1102へ通知する。ユーザインタフェース部1102では、通知されたアップデートの結果をディスプレイ13に画面表示してユーザに通知する。
図18は、確認画面G5の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部1102は、図18に示すように、S101〜S107によるアップデート結果G51や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンG52、G53を確認画面G5に表示する。アップデート結果G51には、アップデート前のバージョンにかかる情報の他、S101〜S106のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果G51の表示内容により、ユーザは、アップデートの結果を確認できる。
次いで、アップデート部1103は、S101〜S106でアップデートを行った際のメタデータに含まれる、“require_reboot”の記述をもとに、再起動が必要であるか否かを判定する(ステップS108)。再起動が必要でない場合(ステップS108:NO)、アップデート部1103は、再起動することなくアップデート処理を終了する(ステップS109)。再起動が必要である場合(ステップS108:YES)、アップデート部1103は、自装置を再起動させて処理を終了する(ステップS110)。このように、再起動が必要なアップデートが実行された場合は、ユーザが操作することなく、アップデート後に再起動されることとなる。
このように本実施の形態では、アップデートデータのダウンロードの停止及び再開を制御するので、アップデートデータのダウンロード中にデータの通信を開始しても、データの通信品質がユーザの意図に反して低下してしまうことを防止することができる。
(第1変形例)
次に、ビデオ会議中にビデオ会議の状態が変化する場合のアプリケーション状態判断部1110及びアップデート部1103の動作の第1変形例について説明する。図19は、ビデオ会議中にビデオ会議の状態が変化する場合のアプリケーション状態判断部1110及びアップデート部1103の動作の第1変形例を示す図である。アップデート部1103は、事前ダウンロードを開始し(ステップS400)、その旨をアプリケーション状態判断部1110に通知する。
アプリケーション状態判断部1110は、ビデオ会議の開始を検知すると(ステップS402)、通信ネットワーク2における利用可能な通信帯域を取得する(ステップS404)。アプリケーション状態判断部1110は、利用可能な通信帯域をPingを用いて取得してもよい。また、アプリケーション状態判断部1110は、通信ネットワーク2を介してビデオ会議等のコミュニケーションが行われる場合に、コミュニケーション中の通信速度を取得して、利用可能な通信帯域を算出してもよい。また、アプリケーション状態判断部1110は、常時ポーリングで利用可能な通信帯域を取得してもよい。さらに、アプリケーション状態判断部1110は、画像及び音声の少なくとも1つのデータ通信が開始、終了及び通信中のいずれの状態であるかを判定し、アップデート部1103に対してアップデートの再開及び停止を制御するように構成されてもよい。
アプリケーション状態判断部1110は、取得した利用可能な通信帯域と、ビデオ会議を行うために予め定められた閾値と比較することにより、ビデオ会議を行うために十分な帯域が通信ネットワーク2の通信帯域に確保可能であるか否かを判断する(ステップS406)。なお、閾値は、ユーザが意図する通信品質に応じて設定した値とする。例えば、アプリケーション状態判断部1110は、「1Mbps」などのように、閾値を設定ファイルとしてメモリに定義しておく。
アプリケーション状態判断部1110は、閾値よりも通信帯域が低ければ事前ダウンロードを停止させる指示をアップデート部1103に対して行う(ステップS406:NO)。また、アプリケーション状態判断部1110は、通信帯域が閾値以上であれば(通信帯域が十分であれば)、アップデート部1103に対する指示を行わない(ステップS406:YES)。つまり、通信帯域が閾値以上であれば、アップデート部1103は、事前ダウンロードを継続する。
アップデート部1103は、事前ダウンロードを停止させる指示を受入れると、事前ダウンロードを停止する(ステップS408)。
(第2変形例)
次に、ビデオ会議中にビデオ会議の状態が変化する場合のアプリケーション状態判断部1110及びアップデート部1103の動作の第2変形例について説明する。第2変形例において、アプリケーション状態判断部1110は、取得した利用可能な通信帯域と、ビデオ会議に必要な帯域を示す帯域表とを用いて、ビデオ会議に利用する最大帯域を指定する。図20は、ビデオ会議中にビデオ会議の状態が変化する場合のアプリケーション状態判断部1110及びアップデート部1103の動作の第2変形例を示す図である。図21は、ビデオ会議に必要な帯域をビデオ会議モードごとに示す図表(帯域表)である。図21に示した帯域表は、例えばROM102又はRAM103などに記憶されている。なお、図20に示した第2変形例において、図19に示した第1変形例における処理と実質的に同一の処理には、同一の符号が付してある。
アプリケーション状態判断部1110は、ユーザによる設定に従い、図21に示した帯域表に応じてビデオ会議モードごとに必要な帯域(ビデオ会議の使用帯域)を設定するか否かを判定する(ステップS407)。ここで、アプリケーション状態判断部1110は、ユーザによる設定に従い、ビデオ会議に使用する帯域を制限すれば事前ダウンロードが継続可能な場合に、ビデオ会議の使用帯域を設定すると判定する。
アプリケーション状態判断部1110は、会議の使用帯域を設定しないと判定した場合(ステップS407:NO)、事前ダウンロードを停止させる指示をアップデート部1103に対して行う。また、アプリケーション状態判断部1110は、会議の使用帯域を設定すると判定した場合(ステップS407:YES)、ユーザによる設定に合わせて、ビデオ会議に使用する帯域を制限する設定を行う(ステップS410)。
このように、アプリケーション状態判断部1110は、ビデオ会議に利用する帯域を制限することにより、事前ダウンロードを停止することなくビデオ会議を継続可能であるか否かを判断する。アプリケーション状態判断部1110は、事前ダウンロードを停止することなくビデオ会議を継続可能な場合は、ビデオ会議に使用する帯域を制限する設定を行う。アプリケーション状態判断部1110が帯域を制限する設定を行うと、アップデート部1103は、ビデオ会議に使用する帯域を制限し、アップデートデータの事前ダウンロードを停止しない。
例えば、通信ネットワーク2において、事前ダウンロードを継続しつつ、ビデオ会議に利用可能な通信帯域が400kbpsの場合、狭帯域モードであればビデオ会議を行うことが可能である。そこで、アプリケーション状態判断部1110は、ユーザによる設定に従い、ビデオ会議に使用する帯域を制限すれば事前ダウンロードが継続可能であるため、ビデオ会議の使用帯域を設定すると判定し、使用帯域を制限する設定を行う。つまり、アプリケーション状態判断部1110は、ビデオ会議を狭帯域モードで使用する場合の解像度、パラメータに設定して利用帯域を制限する設定を行う。また、アプリケーション状態判断部1110は、ビデオ会議に利用する帯域を制限しても全体(事前ダウンロードとビデオ会議)で必要な帯域が得られない場合には、事前ダウンロードを停止させる指示をアップデート部1103に対して行う。
なお、本発明は上述した実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。
具体的には、通信システム1は、テレビ電話システム、音声会議システム、音声電話システム、PC(Personal Computer)画面共有システム、IP(Internet Protocol)電話及びインターネット電話等の電話システムであってもよい。さらに、遠隔操作システム1は、カーナビゲーションシステムであってもよい。例えば、通話端末11の一方が自動車に搭載されたカーナビゲーション装置に相当し、通話端末11の他方がカーナビゲーションを管理する管理センターの管理端末若しくは管理サーバ、又は他の自動車に搭載されているカーナビゲーション装置に相当するように構成されてもよい。また、通信システム11は、映画、ドラマ、テレビ、投稿動画などの映像や、電子書籍などの電子データを配信するコンテンツ配信システムとして構成されてもよい。
また、上記各実施形態における通信管理サーバ50、及びアップデートサーバ60は、単一のコンピュータによって構築されてもよいし、各部(機能又は手段)を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、アップデートサーバ60が単一のコンピュータによって構築されている場合には、アップデートサーバ60によって送信されるプログラムは、複数のモジュールに分けて送信されるようにしてもよいし、分けないで送信されるようにしてもよい。更に、アップデートサーバ60が複数のコンピュータによって構築されている場合には、複数のモジュールが分けられた状態で、各コンピュータから送信されるようにしてもよい。