以下に添付図面を参照して、サーバ装置、アップデートシステム、アップデート方法およびプログラムの一実施形態を詳細に説明する。
(実施の形態1)
図1は、実施の形態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がアップデートを行うタイミングが各々異なるためである。また、アップデートサーバ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は、画像及び音声による他の通信端末との通話、いわゆるテレビ会議を実現する。
次に、中継装置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は、実施の形態1の通信端末11及びアップデートサーバ60の機能構成を例示するブロック図である。
まず、通信端末11の機能的構成について説明する。通信端末11は、図4に示すように、送受信部1101と、ユーザインタフェース部1102と、アップデート部1103とを主に有している。
送受信部1101は、通信ネットワーク2を介してアップデートサーバ60との間でデータの送受信を行う。具体的には、送受信部1101は、記憶部105の設定情報などに予め設定されているアップデートサーバ60の通信アドレスや遠隔通信管理サーバ50へ問い合わせて取得したアップデートサーバ60の通信アドレスをもとに、アップデートサーバ60との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ60との間でデータの送受信を行う。このデータの送受信により、送受信部1101は、アップデートサーバ60が管理しているアップデートにかかる情報を取得する。具体的には、送受信部1101は、メタデータの送信要求をアップデートサーバ60に送信し、アップデートサーバ60からアップデートに関するメタデータ、アップデートデータを受信する。
ユーザインタフェース部(UI部)1102は、スピーカ15による音声出力、ディスプレイ13の表示画面、操作部108によるユーザの操作入力の受け付けなどを制御して、ユーザと通信端末11との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部1102は、スピーカ15による音声出力やディスプレイ13の表示画面でユーザへの各種通知を行うユーザ通知部1104と、操作部108によるユーザの操作入力を受け付ける操作入力受付部1105とを有する。
アップデート部1103は、判断部およびアップデート処理部として機能し、送受信部1101によりアップデートサーバ60から取得したアップデートにかかる情報をもとに、記憶部105が記憶するプログラム104や各種設定情報のアップデートを実行する。アップデート部1103が実行するアップデートについては、アップデート処理(ステップS36)にて詳細に説明する。
次に、アップデートサーバ60の機能的構成について説明する。アップデートサーバ60は、図4に示すように、送受信部601と、アップデートデータ提供部602と、アップデートデータ分割部603と、分割判断部604と、端末データベース610(以下、「端末DB610」という。)とを主に有している。
送受信部601は、通信ネットワーク2を介して通信端末11との間でデータの送受信を行う。具体的には、送受信部601は、通信ネットワーク2を介した通信端末11の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通信端末11との間でデータの送受信を行う。
端末DB610は、通信端末11ごとに、通信端末11に関する端末情報を記憶するHDD(ハードディスクドライブ)やメモリ等の記憶媒体である。図5は、端末DB610の一例を示す図である。図5に示すように、端末DB610には端末情報が登録されており、端末情報は、通信端末11の機種名と通信端末11が受信可能なサイズとが対応付けられている。受信可能なサイズとは、通信端末11が有する記憶部105の記憶容量である。
分割判断部604は、端末DB610の端末情報の機種名に基づいて、通信端末11のアップデートデータを分割するか否かを判断する。具体的には、分割判断部604は、端末DB610において、メタデータの送信要求を行った通信端末11の機種名に対応する受信可能なサイズとアップデートデータのサイズとに基づいて、アップデートデータを分割するか否かを判断する。
例えば、アップデートデータのサイズが300MBの場合、図5の端末DB610において、機種Aおよび機種Bの通信端末11の受信可能サイズは300MBより大きいため、分割判断部604はアップデートデータの分割は不要と判断する。一方、図5の端末DB610において、機種Cの通信端末11の受信可能サイズは300MBより小さいため、分割判断部604はアップデートデータの分割が必要と判断する。
アップデートデータ分割部603は、分割判断部604によって、アップデートデータを分割すると判断された場合に、アップデートデータを分割し、さらに分割されたアップデートデータに基づくメタデータを生成する。
例えば、アップデートデータのサイズが300MBの場合、図5の端末DB610において、機種Cの通信端末11からメタデータの送信要求があった場合には、アップデートデータ分割部603は、アップデートデータを250MB以下のサイズに分割する。
アップデートデータ提供部602は、送受信部601を介して、通信端末11からメタデータの送信要求を受信する。また、アップデートデータ提供部602は、送受信部601を介して通信端末11からメタデータの送信要求を受信した場合には、通信端末11からの要求に応じて、アップデートサーバ60が管理しているアップデートにかかる情報、すなわちメタデータを通信端末11に提供する。また、アップデートデータ提供部602は、アップデートデータ(分割されたアップデートデータも含む)を通信端末11に送信する。
次に、アップデートサーバ60で実行される処理について説明する。図6は、実施の形態1のアップデートサーバ60で実行される分割処理の流れを示すラダーチャートである。
まず、アップデートデータ提供部602が、送受信部601を介して、通信端末11からメタデータの送信要求を受信すると(ステップS11)、分割判断部604は、端末DB610において、メタデータの送信要求を送信した通信端末11の機種名に基づいてアップデートデータを分割するか否かを判断する(ステップS12)。具体的には、上述のように、分割判断部604は、アップデートデータのサイズと、機種名に対応する受信可能サイズとから分割の要否を判断する。
そして、分割が不要と判断された場合には(ステップS13:No)、アップデートデータ提供部602は、アップデートサーバ60が管理しているメタデータを、送信要求のあった通信端末11に送信する(ステップS16)。
一方、ステップS13において、分割が必要と判断された場合には(ステップS13:Yes)、アップデートデータ分割部603は、機種名に基づいてアップデートデータを分割し、分割されたアップデートデータに基づくメタデータを生成する(ステップS15)。ここで、アップデートデータは、複数の画像ファイルやプログラムのオブジェクトファイル、設定ファイルなどの集合であるため、アップデートデータ分割部603は、アップデートデータを、ファイル容量の最小単位まで分割可能である。
そして、アップデートデータ提供部602は、ステップS15で生成されたメタデータを、送信要求のあった通信端末11に送信する(ステップS16)。
ここで、メタデータの詳細について説明する。図7は、メタデータの一例を示す概念図である。図7に示すように、各バージョンのメタデータは、“version”、“dependency”、“description”、“files”、“scriptname”、“require_reboot”、“force_update”などのデータ項目を含む構成である。
“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”)が記述される。
プログラム104のアップデートには、ネットワークI/F111、撮像素子I/F112、音声入出力I/F113、ディスプレイI/F114等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“require_reboot”に“true”が記述される。また、プログラム104のアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“force_update”に“true”が記述される。
次に、アップデートデータを分割する場合におけるメタデータの内容について説明する。図8は、アップデートデータの分割とメタデータとについて説明するための図である。アップデートデータ分割部603がアップデートデータを分割する場合、分割後のアップデートデータに対して新たなバージョン番号を、分割元のアップデートデータのバージョン番号の桁数を1つ増やした番号で生成して付与し、新たなバージョンをメタデータの“version”に記述する。例えば、図8に示すように、分割元のアップデートデータのバージョン番号が”2.2”の場合で、アップデートデータ分割部603がこのアップデートデータを2つに分割する場合には、1番目のアップデートデータのバージョン番号を“2.2.0”とし、2番目のアップデートデータのバージョン番号を“2.2.1”としてそれぞれ付与し、“version”に記述する。
また、アップデートデータ分割部603は、メタデータにおいて、依存関係を示す“dependency”については以下のように記述する。アップデートデータ分割部603は、分割した1番目のアップデートデータの“dependency”には、分割元のアップデートデータの依存先のバージョン番号を記述し、分割したn番目のアップデートデータの“dependency”には、分割した(n−1)番目のアップデートデータのバージョン番号を記述する。
図8の例では、アップデートデータ分割部603は、バージョン番号“2.1”に依存するバージョン番号“2.2”であるアップデートデータを、バージョン番号“2.2.0”と“2.2.1”の2つのアップデートデータに分割している。この場合において、アップデートデータ分割部603は、バージョン番号“2.2.0”のアップデートデータ(1番目のアップデートデータ)の“dependency”を“2.1”と記述し、バージョン番号“2.2.1”のアップデートデータ(2番目のアップデートデータ)の“dependency”を“2.2.0”と記述してメタデータを生成している。
なお、図8の例では、アップデートデータを2つに分割する例を示しているが、1つ当たりのアップデートデータが端末DB610における機種名に対応する受信可能サイズに収まるように分割数を決定して分割すれば、任意の数に分割することができる。
次に、通信端末11の動作の詳細を説明する。図9は、実施の形態1の通信端末11の動作の一例を示すラダーチャートである。
図9に示すように、ユーザインタフェース部1102は、操作部108の電源スイッチなどの操作に応じて自装置の電源投入(電源オン)を行い(ステップS21)、起動画面をディスプレイ13に表示させる(ステップS22)。この起動画面は、CPU101の制御の下で遠隔通信管理サーバ50へ問い合わせて得られた各通信端末11の通話状態を一覧表示した表示画面である(詳細は後述する)。
アップデート部1103は、S21による電源投入後の起動時において、自装置のアップデートの確認を開始する(ステップS23)。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。
アップデートの確認が開始されると、アップデート部1103は、送受信部1101によって、最新バージョンのプログラムのメタデータをアップデートサーバ60に対して要求し(ステップS24)、その要求に対応してアップデートデータ提供部602が提供するメタデータを取得する(ステップS25)。
次いで、アップデート部1103は、取得したメタデータの“dependency”のデータ項目に記述された内容をもとに、依存するバージョンの有無を確認する(ステップS26)。例えば、図7に示すように、“dependency”のデータ項目に“1.0.0”などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、“dependency”のデータ項目に何も記述がない場合には、依存するバージョンがないものとする。なお、この依存するバージョンは、図8を用いて上述したとおり、分割されたアップデートデータも含まれる。
次いで、アップデート部1103は、S26による確認の結果、依存するバージョンが有るか否かを判定する(ステップS27)。依存するバージョンがある場合(ステップS7:YES)、アップデート部1103は、送受信部1101によって、依存するバージョンのプログラムのメタデータをアップデートサーバ60に対して要求し(ステップS28)、その要求に対応してアップデートデータ提供部602が提供する、依存するバージョンのメタデータを取得して(ステップS29)、S26へ処理を戻す。したがって、アップデート部1103は、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。また、アップデートデータが分割されている場合には、ステップS28、S29の処理を繰り返すことによって、アップデート部1103は、分割後のすべてのアップデートデータに対するメタデータを取得することができる。
次いで、アップデート部1103は最新バージョンのメタデータの“version”に記述されたバージョン番号と、自装置の記憶部105に記憶されたプログラム104のバージョン番号とを比較することで、自装置のアップデートが存在するか否か(すなわち、アップデート済みか否か)を判定する(ステップS30)。具体的には、最新バージョンのバージョン番号と、プログラム104のバージョン番号とが一致する場合は、プログラム104が最新バージョンであることから、自装置に必要なアップデートが存在しない(すなわち、アップデート済み)と判定する。また、最新バージョンのバージョン番号と、プログラム104のバージョン番号とが一致しない場合は、プログラム104が古いバージョンであることから、自装置に必要なアップデートが存在する(すなわち、アップデート済みでない)と判定する。自装置に必要なアップデートが存在しない場合(ステップS30:NO)は、アップデートを実行する必要がないことから、通常の動作を継続させる(ステップS39)。
自装置のアップデートが存在する場合(ステップS30:YES)、アップデート部1103は、そのアップデートに関する情報をユーザインタフェース部1102へ通知する(ステップS31)。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“files”、“scriptname”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部1102へ通知する。
ユーザインタフェース部1102のユーザ通知部1104では、S31においてアップデート部1103より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ13の起動画面に表示して、ユーザへ通知する(ステップS32)。
ここで、起動画面の詳細について説明する。図10は、起動画面G1の一例を示す概念図である。図10に示すように、起動画面G1は、各通信端末の通話状態を一覧表示する主画面G11と、自装置のステータスを表示するステータス画面G12とを含む構成である。ユーザ通知部1104は、アップデートに関する情報がアップデート部1103より通知された場合は、ステータス画面G12にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面G11に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例(図10〜13、15、16等)において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。
また、ユーザ通知部1104は、アップデートに関する情報として含まれるデータ項目の中で“force_update”の記述が“true”である場合は、自装置に存在するアップデートが強制のアップデートであることを起動画面G1に表示してユーザに通知する。具体的には、アップデートが強制のアップデートである旨をステータス画面G12に表示してもよいし、主画面G11に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。
S32によるユーザへの通知によって、ユーザインタフェース部1102の操作入力受付部1105によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部1102は、設定画面をディスプレイ13に表示させる(ステップS33)。
図11は、設定画面G2の一例を示す概念図である。図11に示すように、設定画面G2は、操作入力受付部1105によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンG23〜G26を表示する主画面G21を含む構成である。設定ボタンG23〜G26の中で設定ボタンG26がアップデートの実行を指示するためのボタンである。この設定ボタンG26は、アップデートに関する情報がアップデート部1103より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。
逆に、アップデートに関する情報がアップデート部1103より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部1105によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンG26には、アップデートに関する情報として含まれるデータ項目の“version”の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が2.0の最新バージョンにアップデートすることが記載されている。なお、設定画面G2に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
ステップS33において、設定ボタンG26の選択操作が行われた場合、ユーザインタフェース部1102は、アップデートの実行を確認する確認画面をディスプレイ13に表示させる(ステップS34)。
図12は、確認画面G3の一例を示す概念図である。図12に示すように、確認画面G3は、実行するアップデートの内容を表示するアップデート表示G33と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンG35、G34とを含む主画面G31と、自装置のステータスを表示するステータス画面G32とを含む構成である。
アップデート表示G33には、自装置のプログラム104のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の“version”の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示G33の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、確認画面G3のアップデート表示G33に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
図13は、確認ウインドウG36の一例を示す概念図である。確認画面G3において、アップデートの実行を指示する操作ボタンG35が選択された場合は、再度ユーザに確認を促す確認ウインドウG36を表示してもよい。確認ウインドウG36には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面G3では、アップデートの実行が指示された場合に確認ウインドウG36を表示することで、ユーザへの注意喚起を促すことができる。なお、確認ウィンドウ36に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
図9に戻り、アップデート部1103では、確認画面G3での操作ボタンG34、G35の選択操作をもとに、アップデートを実行するか否かを判定する(ステップS35)。アップデートの実行を指示する操作ボタンG35が選択された場合(ステップS35:YES)、アップデート部1103は、取得しているメタデータをもとにアップデート処理を実行する(ステップS36)。
アップデートの実行をキャンセルする操作ボタンG34が選択されるなどして、操作ボタンG35の選択が行われなかった場合(ステップS35:NO)、アップデート部1103は、取得しているメタデータの“force_update”の記述をもとに、実行されなかったアップデートの中に強制のアップデートが含まれるか否かを判定する(ステップS37)。強制のアップデートが含まれる場合(ステップS37:YES)、アップデート部1103は、自装置の処理を終了させる終了処理を行い(ステップS38)、装置の電源を落とす。このように、強制のアップデートが実行されない場合は、通話すら実行できないこととなるため、装置の電源を落として無駄な操作が行われることを未然に防止する。逆に、強制のアップデートが含まれない場合(ステップS37:NO)、アップデート部1103は、現時点ではアップデートを実行しないことから、通常の動作を継続させる。これにより、ユーザは、アップデートよりも通話を優先することができる。
すなわち、通信端末11では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部1102のユーザ通知部1104よりユーザに通知する。そして、通信端末11では、操作入力受付部1105により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート部1103によるアップデート処理が実行される。したがって、通信端末11は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。
ここで、アップデート処理(ステップS36)の詳細について説明する。図14は、アップデート処理の一例を示すフローチャートである。
図14に示すように、アップデート部1103は、アップデート処理が開始されると(ステップS100)、カメラ12、マイク14、スピーカ15などの外部装置と接続するための撮像素子I/F112、音声入出力I/F113等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム104が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート部1103は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。
次いで、アップデート部1103は、取得したメタデータの“files”からアップデートの実体となるプログラムのファイルリストと、それらファイルのチェックサムとを取得する(ステップS101)。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にS101〜S106の処理が行われるものとする。
次いで、アップデート部1103は、S101で取得したファイルリストのファイルをアップデートサーバ60から取得し(ステップS102)、取得したファイルのチェックサムを確認する(ステップS103)。次いで、アップデート部1103は、アップデートの進行状況をユーザインタフェース部1102に通知する(ステップS104)。この進行状況の通知は、ファイルリストに含まれる複数のファイルの中で、どのファイルまでS102、S103の処理を終えたかを通知する。また、依存関係を有する複数のバージョンのアップデートを行う場合には、どのバージョンのアップデートまでを終えたかを通知してもよい。ユーザインタフェース部1102では、通知されたアップデートの進行状況をディスプレイ13に画面表示してユーザに通知する。
図15は、アップデート画面G4の一例を示す概念図である。図15に示すように、アップデート画面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は、S106〜S107によるアップデートの結果をユーザインタフェース部1102へ通知する。ユーザインタフェース部1102では、通知されたアップデートの結果をディスプレイ13に画面表示してユーザに通知する。
図16は、確認画面G5の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部1102は、図16に示すように、S106〜S107によるアップデート結果G51や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンG52、G53を確認画面G5に表示する。アップデート結果G51には、アップデート前のバージョンにかかる情報の他、S106〜S107のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果G51の表示内容により、ユーザは、アップデートの結果を確認できる。
次いで、アップデート部1103は、S101〜S106でアップデートを行った際のメタデータに含まれる、“require_reboot”の記述をもとに、再起動が必要であるか否かを判定する(ステップS108)。再起動が必要でない場合(ステップS108:NO)、アップデート部1103は、再起動することなくアップデート処理を終了する(ステップS109)。再起動が必要である場合(ステップS108:YES)、アップデート部1103は、自装置を再起動させて処理を終了する(ステップS110)。このように、再起動が必要なアップデートが実行された場合は、ユーザが操作することなく、アップデート後に再起動されることとなる。
このように本実施の形態では、アップデートサーバ60は、メタデータの送信要求を行った通信端末11の機種名、記憶容量を含む端末情報に基づいて、アップデートデータを分割するか否か判断して、分割が必要な場合、端末情報に基づいてアップデートデータを分割しているので、オンラインアップデートを行う際に、通信端末11側でアップデートデータを格納できるだけの容量が不足している場合においてもアップデートを完了させることができる。
また、本実施の形態では、通信端末11にに実行するアップデートがある場合において、そのアップデートの実行をユーザが選択することができるので、これによりユーザの利便性を図ることができる。
(実施の形態2)
実施の形態1では、予め端末DB610に通信端末11の機種名と記憶容量とを対応付けた端末情報を保存しておき、メタデータの送信要求があった場合、当該送信要求を行った通信端末11の機種名、記憶容量からアップデートデータの分割の要否を判断していた。この場合、実際には通信端末11ごとにアプリケーションのインストール状況などにより、記憶部105の空き容量が異なってくる場合があるため、不必要に分割が行われたり、分割されるべきデータが分割されず、アップデートの効率が低下したり、アップデートの実行が困難になる場合も発生する。
このため、この実施の形態2では、通信端末11がメタデータの送信要求に、現時点の記憶部105の空き容量等からダウンロード可能サイズを含めて送信し、アップデートサーバ60がこのダウンロード可能サイズとアップデートデータのサイズから、アップデートデータを分割する必要があるか否かを判断している。
本実施の形態の遠隔通信システム1のネットワーク構成、通信端末11、アップデートサーバ60、中継装置30、遠隔通信管理サーバ50の構成は、実施の形態1と同様である。
本実施の形態の通信端末11の送受信部1101は、メタデータの送信要求に、通信端末11の記憶部105の現時点での空き容量に基づいたダウンロード可能サイズを含めて送信する。
本実施の形態のアップデートサーバ60のアップデートデータ提供部602は、通信端末11から、このようなダウンロード可能サイズを含むメタデータ送信要求を受信する。また、分割判断部604は、アップデートデータ提供部602がメタデータの送信要求を受信した場合に、メタデータ送信要求に含まれるダウンロード可能サイズとアップデートデータのサイズに基づいて、アップデートデータを分割するか否かを判断する。
ここで、分割要否の判断は、通信端末11のダウンロード可能サイズとアップデートデータのサイズとを比較し、ダウンロード可能サイズがアップデートデータのサイズより大きいか否かにより行う他、アップデートデータが圧縮形式で提供される場合には、アップデートデータのサイズに解凍後の展開領域のサイズも含めて、ダウンロード可能サイズと比較して判断するように分割判断部604を構成してもよい。
アップデートデータ分割部603は、ダウンロード可能サイズの範囲内でアップデートデータを分割する。
次に、アップデートサーバ60で実行される処理について説明する。図17は、実施の形態2のアップデートサーバ60で実行される分割処理の流れを示すラダーチャートである。
まず、アップデートデータ提供部602が、送受信部601を介して、通信端末11から、通信端末11におけるダウンロード可能サイズを含むメタデータ送信要求を受信すると(ステップS201)、分割判断部604は、端末DB610において、メタデータ送信要求に含まれるダウンロード可能サイズに基づいてアップデートデータを分割するか否かを判断する(ステップS202)。
そして、分割が不要と判断された場合には(ステップS13:No)、アップデートデータ提供部602は、アップデートサーバ60が管理しているメタデータを、送信要求のあった通信端末11に送信する(ステップS16)。
一方、ステップS13において、分割が必要と判断された場合には(ステップS13:Yes)、アップデートデータ分割部603は、ダウンロード可能サイズに基づいてアップデートデータを分割し、分割されたアップデートデータに基づくメタデータを生成する(ステップS205)。
そして、アップデートデータ提供部602は、ステップS15で生成されたメタデータを、送信要求のあった通信端末11に送信する(ステップS16)。
このように本実施の形態では、通信端末11がメタデータの送信要求に、現時点の記憶部105の空き容量等からダウンロード可能サイズを含めて送信し、アップデートサーバ60がこのダウンロード可能サイズとアップデートデータのサイズから、アップデートデータを分割する必要があるか否かを判断しているので、アップデートデータの不要な分割を防止することができるとともに、アップデートデータを分割した場合においても、分割後のアップデートデータの数を低減させることができる。このため、本実施の形態によれば、アップデートの効率を向上させることができる。
上述した実施の形態1,2では、アップデートが存在する場合、そのアップデートが強制のアップデートであるか否かにかかわらず、アップデートを実行するか否かの選択操作をユーザより受け付けて、アップデートを実行しない場合に自装置の処理を終了させる構成を例示した。
しかしながら、アップデートが存在する場合で、そのアップデートが強制のアップデートである場合は、アップデートが存在することをユーザに通知することなく、アップデートを実行してもよい。具体的には、図9に例示したS37の処理をS30の直後に行い、強制のアップデートがある場合にはS31の処理を行うことなく、S36へ処理を進めてよい。
強制のアップデートを実行していない状況では、通話すら実行できないことから、アップデートの実行が最優先となる。したがって、このような場合には、ユーザに確認するまでもなく、アップデートを実行することが好適である。
なお、上記実施の形態1,2では、遠隔通信管理サーバ50とアップデートサーバ60とを別個の構成とした例を示しているが、これに限定されるものではない。例えば、サーバ装置を設け、当該サーバ装置が遠隔通信管理サーバ50の機能とアップデートサーバ60の機能とを備えた構成としてもよい。
なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。