通信装置、アップデート方法およびアップデートプログラム
【課題】ネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うこと。
【解決手段】通信装置は、アップデート情報提供装置から、メタ情報を受信する第１受信部と、依存バージョンが通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、依存バージョンが装置バージョンより新しい場合に、依存バージョンのアップデートを示すメタ情報をアップデート情報提供装置から受信する第２受信部と、依存バージョンのメタ情報に基づいて依存バージョンのアップデートを実行し、依存バージョンのアップデートの実行後、対象のアップデートのメタ情報に基づいて対象のアップデートを実行するアップデート処理部と、を備えた。
【解決手段】通信装置は、アップデート情報提供装置から、メタ情報を受信する第１受信部と、依存バージョンが通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、依存バージョンが装置バージョンより新しい場合に、依存バージョンのアップデートを示すメタ情報をアップデート情報提供装置から受信する第２受信部と、依存バージョンのメタ情報に基づいて依存バージョンのアップデートを実行し、依存バージョンのアップデートの実行後、対象のアップデートのメタ情報に基づいて対象のアップデートを実行するアップデート処理部と、を備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、アップデート方法およびアップデートプログラムに関する。
【背景技術】
【０００２】
近年、出張経費及び出張時間を削減する要請に伴い、インターネット等の通信ネットワークを介してテレビ会議などを行うための通話端末が普及している。各通話端末では、宛先の通話端末を指定して通話を開始することで、画像データ及び音声データの送受信が行われ、テレビ会議を実現することができる。
【０００３】
この通話端末では、通話秘匿性能や操作性能を向上させるため、ファームウエア（プログラム）のアップデートが定期的に行われることがある。この通話端末におけるプログラムのアップデートについては、特許文献１が知られている。特許文献１には、アップデートデータとメタ情報を、ネットワークを介してサーバへアクセスして取得し、プログラムおよび当該プログラムに依存するバージョンのプログラムをアップデートすることが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した従来技術では、プログラムに依存するバージョンのプログラムのアップデートを行う必要がある場合には、当該依存するバージョンのメタ情報も、ネットワークを介してサーバへアクセスして取得するため、依存するバージョンが複数存在する場合には、複数のバージョンの数だけ何回もメタ情報をネットワークを介して取得しなければならず、ネットワーク帯域の利用が増加してネットワーク負荷が増大するとともに、アップデートの処理が煩雑で時間を要するという問題がある。
【０００５】
本発明は、上記に鑑みてなされたものであって、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができる通信装置、アップデート方法及びアップデートプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明にかかる通信装置は、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第１受信部と、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第２受信部と、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、を備えたことを特徴とする。
【０００７】
また、本発明にかかるアップデート方法は、通信装置で実行されるアップデート方法であって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を含むことを特徴とする。
【０００８】
また、本発明にかかるアップデートプログラムは、コンピュータに実行させるためのアップデートプログラムであって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を前記コンピュータに実行させる。
【発明の効果】
【０００９】
本発明によれば、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、本実施の形態の遠隔通信システムの構成を例示する模式図である。
【図２】図２は、本実施の形態の通話端末のハードウエア構成を例示するブロック図である。
【図３】図３は、本実施の形態の通話端末の外観図である。
【図４】図４は、本実施の形態の中継装置、遠隔通信管理サーバ、アップデートサーバのハードウエア構成を例示するブロック図である。
【図５】図５は、本実施の形態の通話端末及びアップデートサーバの機能構成を例示するブロック図である。
【図６】図６は、本実施の形態のメタデータの一例を示す概念図である。
【図７】図７は、本実施の形態の通話端末の動作の一例を示すラダーチャートである。
【図８】図８は、本実施の形態の通話端末の動作の一例を示すラダーチャートである。
【図９】図９は、本実施の形態の起動画面の一例を示す概念図である。
【図１０】図１０は、本実施の形態の設定画面の一例を示す概念図である。
【図１１】図１１は、本実施の形態の確認画面の一例を示す概念図である。
【図１２】図１２は、本実施の形態の確認ウインドウの一例を示す概念図である。
【図１３】図１３は、本実施の形態の強制アップデート時の確認画面の一例を示す概念図である。
【図１４】図１４は、本実施の形態のアップデート処理の一例を示すフローチャートである。
【図１５】図１５は、本実施の形態のスクリプトの一例を示す説明図である。
【図１６】図１６は、本実施の形態のアップデート画面の一例を示す概念図である。
【図１７】図１７は、本実施の形態の通常アップデートの場合の確認画面の一例を示す概念図である。
【図１８】図１８は、本実施の形態の強制アップデート結果画面の一例を示す概念図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、この発明にかかる通信装置、アップデート方法およびアップデートプログラムの実施の形態を詳細に説明する。
【００１２】
図１は、本実施の形態の遠隔通信システム１の構成を例示する模式図である。図１に示すように、遠隔通信システム１は、通信ネットワーク２により通信装置としての通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、遠隔通信管理サーバ５０、アップデートサーバ６０及びルータ７０ａ〜７０ｄが通信可能に接続されるシステムである。具体的には、遠隔通信システム１は、インターネット２ｉにルータ７０ａ〜７０ｄを介して接続するＬＡＮ２ａ、２ｂ、２ｃ、２ｄ、遠隔通信管理サーバ５０及びアップデートサーバ６０と、ＬＡＮ２ａに接続する通話端末１１ａａ〜１１ａｃ及び中継装置３０ａと、ＬＡＮ２ｂに接続する通話端末１１ｂａ〜１１ｂｃ及び中継装置３０ｂと、ＬＡＮ２ｃに接続する通話端末１１ｃａ〜１１ｃｃ及び中継装置３０ｃと、ＬＡＮ２ｄに接続する通話端末１１ｄａ〜１１ｄｃ及び中継装置３０ｄとを有する構成である。遠隔通信システム１では、遠隔通信管理サーバ５０の管理の下、地域Ａの通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、地域Ｂの通話端末１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃの各々が、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄによる通信データの中継を介して、互いに音声又は映像を送受信することで通話を行う。
【００１３】
具体的には、遠隔通信管理サーバ５０は、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄなどの通信アドレス、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄの各々が中継を行う通話端末、各通話端末の通話状態などの情報を管理する。例えば、通話端末１１ａａが通話端末１１ｃａと通話を行う場合は、中継装置３０ａに通話端末１１ｃａへの通話の中継を依頼する。中継装置３０ａは、遠隔通信管理サーバ５０に通話端末１１ａａの通話の開始を通知するとともに、通話端末１１ｃａへ通話を中継するための中継装置３０ｃの通信アドレスを遠隔通信管理サーバ５０より取得する。次いで、中継装置３０ａは通話端末１１ｃａへ通話の中継を中継装置３０ｃに依頼し、中継装置３０ｃは、通話端末１１ｃａとの通信セッションを開始する。次いで、中継装置３０ｃは、通話端末１１ｃａとの通信セッションの開始を遠隔通信管理サーバ５０へ通知する。
【００１４】
これにより、中継装置３０ａ、３０ｃを介して、通話端末１１ａａ及び通話端末１１ｃａとの間の通話が開始される。また、遠隔通信管理サーバ５０は、通話端末１１ａａ及び通話端末１１ｃａが通話中であることを管理する。例えば、遠隔通信管理サーバ５０は、通話端末１１ａｂから通話端末１１ａａや通話端末１１ｃａなどの通話状態の問い合わせがあった場合は、オンラインであるが互いに通話中であることを返信する。
【００１５】
なお、以下の説明において、同種の装置の中の任意の装置について説明を行う場合は、数字の後の英数字を略した符号を用いるものとする。例えば、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃは通話端末１１と略すものとする。また、中継装置３０ａ〜３０ｄは中継装置３０と略すものとする。
【００１６】
アップデートサーバ６０は、通話端末１１のプログラムや各種設定情報のアップデートプログラムによるアップデートにかかる情報を管理し、通話端末１１の要求に応じてその情報を提供するアップデート情報提供装置である。アップデートにかかる情報としては、通話端末１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータ（メタ情報）などである。アップデートにかかる情報として全てのバージョンのデータをアップデートサーバ６０が管理する理由は、通話端末１１がアップデートを行うタイミングが各々異なるためである。
【００１７】
例えば、頻繁にアップデートを行っている通話端末１１は、最新のバージョンへのアップデートを行うだけでよいかもしれないが、アップデートの間隔が長い通話端末１１は、何回かバージョンアップが繰り返された後にアップデートを行うかもしれない。このような場合は、直に最新のバージョンへアップデートせずに、最新のバージョンと依存関係のある古いバージョンへのアップデートを経ることがある。このように、依存関係のある古いバージョンへのアップデートを経る通話端末１１もあることから、アップデートサーバ６０は、アップデートにかかる情報として全てのバージョンのデータを管理している。
【００１８】
ここで、アップデートの種類には、通常アップデートと強制アップデートの２種類がある。通常アップデートは、バグ等の障害対応や機能追加を目的として実施されるアップデートである。
【００１９】
強制アップデートは、通話端末１１そのものの機能とは異なる装置、機能の変更に伴って、強制的に行うことを目的としたアップデートである。例えば、中継装置３０側において、通話の際に送受信する音声や画像のデータフォーマットやビデオコーデックが変更されたり、エンコーダのアップデート等の映像に関する中継装置３０のバージョンアップが実施される場合がある。また、中継装置３０との通信プロトコルが変更される場合もある。このような変更は、音声や画像、映像そのものの構造が変わり、あるいは通信プロトコルの変更に伴う中継装置３０との通信手順そのものが変わり、もしくは中継装置３０側の機能が変わるため、アップデート前の通話端末１１では、通話端末１１の本来の機能である通話を実現することができない。このため、このような場合には、中継装置３０のアップデート後のバージョンに適合させるために強制アップデートを行う。
【００２０】
また、中継装置３０側でセキュリティホールが発見された場合等、セキュリティ面で問題がある等に、これを回避するようなセキュリティホール対応のアップデートを中継装置３０側で行う場合がある。このような場合にも、アップデート前の通話端末１１では通話すら実行できないことになるため、中継装置３０側のセキュリティホール対応に適合させるために強制アップデートが実施される。
【００２１】
次に、通話端末１１のハードウエア構成を説明する。図２は、通話端末１１のハードウエア構成を例示するブロック図である。図２に示すように、通話端末１１は、ＣＰＵ１０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ１０２（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ１０３（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、記憶部１０５、メディアドライブ１０７、操作部１０８、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３及びディスプレイＩ／Ｆ１１４を備え、各部がバス１１０により互いに接続される構成である。
【００２２】
ＣＰＵ１０１は、ＲＯＭ１０２や記憶部１０５に記憶されたプログラム１０４をＲＡＭ１０３に展開して順次実行することで、通話端末１１の動作を中央制御する。記憶部１０５は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などであり、読み出し／書き込み可能にデータを記憶する。具体的には、記憶部１０５は、ＣＰＵ１０１が実行するためのプログラム１０４や各種設定情報を記憶する。アップデートの際には、この記憶部１０５に記憶されるプログラム１０４や各種設定情報が更新される。なお、本実施の形態では、プログラム１０４がアップデート対象であるとして説明する。
【００２３】
メディアドライブ１０７は、光ディスクなどのメディア１０６の読み出し／書き込みを行うドライブ装置である。操作部１０８は、キーボード、各種操作キー、ディスプレイ１３上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークＩ／Ｆ１１１は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。撮像素子Ｉ／Ｆ１１２は、デジタルカメラであるカメラ１２と接続し、カメラ１２が撮像した画像を取得するためのインタフェースである。音声入出力Ｉ／Ｆ１１３は、マイク１４、スピーカ１５と接続し、マイク１４による音声入力や、スピーカ１５を介した音声出力を行うインタフェースである。ディスプレイＩ／Ｆ１１４は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などであるディスプレイ１３と接続し、ディスプレイ１３へ表示データを出力するインタフェースである。
【００２４】
なお、本実施の形態では、ディスプレイ１３を用いているが、ディスプレイ１３に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。
【００２５】
通話端末１１は、プログラム１０４を実行したＣＰＵ１０１の制御の下、例えば他の通話端末との通話時には、カメラ１２から取得した画像やマイク１４から入力された音声をネットワークＩ／Ｆ１１１を介して中継装置３０へ出力する。また、中継装置３０より中継され、ネットワークＩ／Ｆ１１１を介して入力された他の通話端末からの音声をスピーカ１５より出力し、同様に他の通話端末からの画像をディスプレイ１３により表示する。これにより、通話端末１１は、画像及び音声による他の通話端末との通話、いわゆるテレビ会議を実現する。
【００２６】
次に、通話端末１１の外観構成について説明する。図３は、本実施の形態の通話端末１１の外観図である。通話端末１１は、図３に示すように、筐体１１００、アーム１２００、カメラハウジング１３００を備えている。
【００２７】
筐体１１００の右側壁面１１３０には、操作パネル１１５０が形成されている。操作パネル１１５０には、操作部１０８としての複数の操作ボタン１０８ａ〜１０８ｅ、電源スイッチ１０９、アラームランプ１１９、内蔵スピーカからの音声を出力するための音出力面１１５１等が形成されている。
【００２８】
また、筐体１１００の左側壁面１１４０には、アーム１２００およびカメラハウジング１３００を収容するための凹部としての収容部１１６０が形成されている。この通話端末１１の筐体１１００にはケーブルでディスプレイ１３が接続されている。
【００２９】
アーム１２００は、トルクヒンジ１２１０を介して筐体１１００に取り付けられており、アーム１２００が筐体１１００に対して、１３５度のチルト角θ１の範囲で、上下方向に回転可能に構成されている。図３では、チルト角θ１が９０度の状態を示している。
【００３０】
カメラハウジング１３００には、上述のカメラ１２が内蔵されており、ユーザ、書類、および部屋等を撮像することができる。また、カメラハウジング１３００は、トルクヒンジ１３１０が形成されている。カメラハウジング１３００は、トルクヒンジ１３１０を介して、アーム１２００に取り付けられている。そして、カメラハウジング１３００は、トルクヒンジ１３１０がアーム１２００に対して、図３で示される状態を０度として±１８０度のパン角θ２の範囲で、かつ、±４５度のチルト角θ３の範囲で、上下左右方向に回転可能に構成されている。
【００３１】
次に、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を説明する。図４は、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を例示するブロック図である。図４に示すように、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶部２０４、ディスプレイ２０５、ネットワークＩ／Ｆ２０６、キーボード２０７、マウス２０８、メディアドライブ２０９及びＣＤ−ＲＯＭドライブ２１１を備え、各部がバス２１４により互いに接続される構成である。中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、いわゆるＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やＷＳ（Ｗｏｒｋ Ｓｔａｔｉｏｎ）などの機器である。
【００３２】
ＣＰＵ２０１は、ＲＯＭ２０２や記憶部２０４に記憶されたプログラムをＲＡＭ２０３に展開して順次実行することで、自装置の動作を中央制御する。記憶部２０４は、ＨＤＤやＳＳＤなどであり、読み出し／書き込み可能にデータを記憶する。例えば、アップデートサーバ６０では、アップデートにかかる情報などが記憶部２０４に記憶されている。
【００３３】
ディスプレイ２０５は、例えばＬＣＤなどである。ネットワークＩ／Ｆ２０６は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。キーボード２０７、マウス２０８は、ユーザの操作入力を受け付ける。メディアドライブ２０９は、光ディスクなどのメディア２１０の読み出し／書き込みを行うドライブ装置である。ＣＤ−ＲＯＭドライブ２１１は、ＣＤ−ＲＯＭ２１３の読み出しを行うドライブ装置である。例えば、アップデートサーバ６０では、メディア２１０やＣＤ−ＲＯＭ２１３によりアップデートにかかる最新の情報が提供され、記憶部２０４に記憶される。
【００３４】
次に、ＣＰＵ１０１やＣＰＵ２０１がプログラムを実行することで実現される、通話端末１１及びアップデートサーバ６０の機能構成について説明する。図５は、本実施の形態の通話端末１１及びアップデートサーバ６０の機能構成を例示するブロック図である。
【００３５】
まず、通話端末１１の機能的構成について説明する。図５に示すように、通話端末１１は、送受信部１１０１、ユーザインタフェース部１１０２及びアップデート部１１０３を主に有している。
【００３６】
送受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う。具体的には、送受信部１１０１は、記憶部１０５の設定情報などに予め設定されているアップデートサーバ６０の通信アドレスや遠隔通信管理サーバ５０へ問い合わせて取得したアップデートサーバ６０の通信アドレスをもとに、アップデートサーバ６０との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ６０との間でデータの送受信を行う。このデータの送受信により、送受信部１１０１は、アップデートサーバ６０が管理しているアップデートにかかる情報を取得する。すなわち、送受信部１１０１は、アップデートサーバ６０から、通話端末１１のプログラム１０４に必要なアップデートを示すメタデータを受信する。
【００３７】
ユーザインタフェース部１１０２は、スピーカ１５による音声出力、ディスプレイ１３の表示画面、操作部１０８によるユーザの操作入力の受け付けなどを制御して、ユーザと通話端末１１との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部１１０２は、スピーカ１５による音声出力やディスプレイ１３の表示画面でユーザへの各種通知を行うユーザ通知部１１０４と、操作部１０８によるユーザの操作入力を受け付ける操作入力受付部１１０５とを有する。
【００３８】
アップデート部１１０３は、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報をもとに、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデートを実行する。アップデート部１１０３は、判断部１１０６とアップデート処理部１１０７とを備えている。
【００３９】
判断部１１０６は、対象のアップデートの最新バージョンが端末バージョン（装置バージョン）より新しいか否かを判断する。ここで、端末バージョンは、通話端末１１のアップデート対象のプログラム１０４の現在のバージョンである。この端末バージョンは、記憶部１０５の設定情報に設定されている。例えば、ＯＳ（オペレーティングシステム）がマイクロソフト（Ｒ）社のＷｉｎｄｏｗｓ（登録商標）である場合には、設定情報としてのレジストリに端末バージョンが設定されている。
【００４０】
また、判断部１１０６は、最新バージョンが端末バージョンより新しい場合において、メタデータに、対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、この依存バージョンと端末バージョンとを比較し、依存バージョンが端末バージョンより新しいか否かを判断する。
【００４１】
本実施の形態の送受信部１１０１は、この判断結果により、以下の処理を行う。送受信部１１０１は、依存バージョンが端末バージョンより新しい場合に、依存バージョンのアップデートを示すメタデータをアップデートサーバ６０に対して要求し、アップデートサーバ６０から依存バージョンのメタデータを受信する。送受信部１１０１は、依存バージョンが端末バージョンより新しくない場合には、アップデートサーバ６０に対する依存バージョンのメタデータの要求は行わず、従ってメタデータの受信は行われない。
【００４２】
アップデート処理部１１０７は、依存バージョンのアップデートプログラムのメタデータに基づいて依存バージョンのアップデートを実行し、依存バージョンのアップデートの実行後、アップデート対象のアップデートプログラムのメタデータに基づいて、アップデート対象のアップデートプログラムのアップデートを実行する。また、アップデート処理部１１０７は、アップデート対象のアップデートプログラムの実行後に、端末バージョンを最新バージョンに更新して設定する。また、アップデート処理部１１０７は、メタデータで指定された格納先からデータファイルを受信し、アップデートを実行する。ここで、アップデート処理部１１０７は、データファイルが複数のデータをまとめたキャビネットファイルやＺＩＰ形式等のパッケージ形式のファイル（パッケージファイル）である場合には、当該パッケージファイルに含まれているスクリプトを実行することにより、アップデート処理を行う。ここで、スクリプトは、アップデートの実行手順が記述された実行可能な形式のデータである。
【００４３】
次に、アップデートサーバ６０の機能的構成について説明する。アップデートサーバ６０は、図５に示すように、送受信部６０１及びアップデートデータ提供部６０２を主に有している。
【００４４】
送受信部６０１は、通信ネットワーク２を介して通話端末１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した通話端末１１の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末１１との間でデータの送受信を行う。
【００４５】
アップデートデータ提供部６０２は、送受信部６０１によってデータの送受信を行っている通話端末１１からの要求に応じて、アップデートサーバ６０が管理しているアップデートにかかる情報を通話端末１１に提供する。
【００４６】
ここで、メタデータの詳細について説明する。図６は、メタデータの一例を示す概念図である。図６に示すように、各バージョンのメタデータは、“ｖｅｒｓｉｏｎ”、“ｄｅｓｃｒｉｐｔｉｏｎ”、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”、“ｅｘｅｃｕｔｅ”、“ｒｅｂｏｏｔ”、“ｃｒｉｔｉｃａｌ”、“ｄｅｐｅｎｄｅｎｃｙ”、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”、“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”などのデータ項目を含む構成である。
【００４７】
“ｖｅｒｓｉｏｎ”には、“１．０．１”などのアップデートプログラムのバージョン番号が設定される。“ｄｅｐｅｎｄｅｎｃｙ”は、依存関係を有する他のバージョンである依存バージョンが存在するか否かを示すフラグであり、依存バージョンが存在する場合には“ｔｒｕｅ”、依存バージョンが存在しない場合には“ｆａｌｓｅ”がそれぞれ設定される。依存バージョンが存在する場合、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”には、互いに依存関係を有する他のバージョンを示すバージョン番号、すなわち、依存バージョンのバージョン番号が設定される。従って、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に記述されたバージョン番号を確認することで、依存バージョンへと遡ることが可能である。“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”には、依存バージョンのメタデータの格納先のＵＲＬが設定される。
【００４８】
“ｄｅｓｃｒｉｐｔｉｏｎ”には、“Ｉｔ ｉｓ ｓａｍｐｌｅ ｄａｔａ．”などのバージョンの詳細が設定される。“ｐａｃｋａｇｅ＿ｕｒｌ”には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）の格納先のＵＲＬが設定される。“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”には、アップデートの実体となるデータファイルのチェックサムが設定される。従って、アップデート処理部１１０７は、“ｐａｃｋａｇｅ＿ｕｒｌ”のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。
【００４９】
“ｅｘｅｃｕｔｅ”には、アップデートを実行する際に実行するスクリプトのスクリプト名が設定される。このスクリプトは、取得したデータファイルがパッケージ形式のパッケージファイルである場合に、このパッケージファイルの内部に含まれている。“ｒｅｂｏｏｔ”は、アップデートを実行した後に、通話端末１１の再起動を行うか否かを示すフラグであり、再起動を行う場合には“ｔｒｕｅ”、再起動を行わない場合には“ｆａｌｓｅ”がそれぞれ設定される。“ｃｒｉｔｉｃａｌ”は、アップデートが強制アップデートであるか否かを示すフラグであり、強制アップデートの場合には“ｔｒｕｅ”、通常アップデートの場合には“ｆａｌｓｅ”が設定される。
【００５０】
記憶部１０５のプログラム１０４のアップデートには、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３、ディスプレイＩ／Ｆ１１４等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定される。また、プログラムのアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定される。
【００５１】
次に、以上のように構成された通話端末１１の動作の詳細を説明する。図７，図８は、本実施の形態の通話端末１１の動作の一例を示すラダーチャートである。
【００５２】
図７に示すように、ユーザインタフェース部１１０２は、操作部１０８の電源スイッチなどの操作に応じて自装置の電源投入（電源オン）を行い（ステップＳ１）、起動画面をディスプレイ１３に表示させる（ステップＳ２）。この起動画面は、ＣＰＵ１０１の制御の下で遠隔通信管理サーバ５０へ問い合わせて得られた各通話端末１１の通話状態を一覧表示した表示画面である（詳細は後述する）。
【００５３】
アップデート処理部１１０７は、ステップＳ１による電源投入後の起動時において、自装置のアップデートの確認を開始する（ステップＳ３）。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。
【００５４】
アップデートの確認が開始されると、アップデート処理部１１０７は、送受信部１１０１によって、最新バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ４）、その要求に対応して、アップデートサーバ６０のアップデートデータ提供部６０２が提供するメタデータを取得する（ステップＳ５）。
【００５５】
次に、判断部１１０６は、端末バージョンを記憶部１０４の設定情報から取得し、最新バージョンが通話端末１１の端末バージョンより新しいか否かを判断する（ステップＳ６）。
【００５６】
そして、最新バージョンが端末バージョンより新しくない場合（ステップＳ６：Ｎｏ）、すなわち、最新バージョンが端末バージョンと等しいか、最新バージョンが端末バージョンより古い場合には、アップデート処理を行わずに動作を継続する（ステップＳ２１）。
【００５７】
一方、ステップＳ６で、最新バージョンが端末バージョンより新しい場合（ステップＳ６：Ｙｅｓ）、アップデート処理部１１０７は、取得したメタデータの“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に記述された内容をもとに、依存バージョンの有無を確認する（ステップＳ７）。例えば、図６に示すように、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目が“ｔｒｕｅ”であり、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に“１．０．０”などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目が“ｆａｌｓｅ”の場合には、依存するバージョンがないものとする。
【００５８】
次いで、判断部１１０６は、ステップＳ７による確認の結果、依存バージョンが有るか否かを判定する（ステップＳ８）。依存バージョンがある場合（ステップＳ８：Ｙｅｓ）、判断部１１０６は、メタデータの“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に設定されたバージョン番号が端末バージョンにより大きいか否かを判断することにより、依存バージョンが端末バージョンより新しいか否かを判断する（ステップＳ９）。そして、依存バージョンが端末バージョンより新しい場合には（ステップＳ９：Ｙｅｓ）、アップデート処理部１１０７は、送受信部１１０１によって、既に取得済みのメタデータの“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”のデータ項目に設定された格納先をもとに、依存バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ１０）、その要求に対応してアップデートデータ提供部６０２が提供する、依存バージョンのメタデータを取得して（ステップＳ１１）、Ｓ７へ処理を戻す。したがって、アップデート処理部１１０７は、依存バージョンが端末バージョンより新しい場合に限り、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。
【００５９】
ステップＳ８で依存バージョンが存在しない場合（ステップＳ８：Ｎｏ）、またはステップＳ８で依存バージョンが存在するが（ステップＳ８：Ｙｅｓ）、ステップＳ９で依存バージョンが端末バージョンより新しくない場合（ステップＳ９：Ｎｏ）には、アップデート処理部１１０７は、取得したメタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されているか否かを判断することにより、今回のアップデートが強制アップデートか否かを判断する（ステップＳ１２）。
【００６０】
そして、メタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されておらず、通常アップデートである場合には（ステップＳ１２：Ｎｏ）、アップデート処理部１１０７は、最新バージョンのメタデータの“ｖｅｒｓｉｏｎ”に記述されたバージョン番号と、自装置の端末バージョン（記憶部１０５に記憶されたプログラム１０４のバージョン番号）とを比較することで、自装置のアップデートが存在するか否か（すなわち、アップデート済みか否か）を判定する（ステップＳ１３）。具体的には、最新バージョンのバージョン番号と、端末バージョンとが一致する場合は、プログラム１０４が最新バージョンであることから、自装置に必要なアップデートが存在しない（すなわち、アップデート済み）と判定する。また、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、自装置に必要なアップデートが存在する（すなわち、アップデート済みでない）と判定する。自装置に必要なアップデートが存在しない場合（ステップＳ１３：Ｎｏ）は、アップデートを実行する必要がないことから、通常の動作を継続させる（ステップＳ２１）。
【００６１】
自装置のアップデートが存在する場合（ステップＳ１３：ＹＥＳ）、アップデート処理部１１０７は、そのアップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ１４）。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｅｘｅｃｕｔｅ”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。
【００６２】
ユーザインタフェース部１１０２のユーザ通知部１１０４では、Ｓ１４においてアップデート処理部１１０７より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ１３の起動画面に表示して、ユーザへ通知する（ステップＳ１５）。
【００６３】
ここで、起動画面の詳細について説明する。図９は、起動画面Ｇ１の一例を示す概念図である。図９に示すように、起動画面Ｇ１は、各通話端末の通話状態を一覧表示する主画面Ｇ１１と、自装置のステータスを表示するステータス画面Ｇ１２とを含む構成である。ユーザ通知部１１０４は、アップデートに関する情報がアップデート処理部１１０７より通知された場合は、ステータス画面Ｇ１２にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面Ｇ１１に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例（図９〜１３等）において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。
【００６４】
ステップＳ１５によるユーザへの通知によって、ユーザインタフェース部１１０２の操作入力受付部１１０５によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部１１０２は、設定画面をディスプレイ１３に表示させる（ステップＳ１６）。
【００６５】
図１０は、設定画面Ｇ２の一例を示す概念図である。図１０に示すように、設定画面Ｇ２は、操作入力受付部１１０５によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンＧ２３〜Ｇ２６を表示する主画面Ｇ２１を含む構成である。設定ボタンＧ２３〜Ｇ２６の中で設定ボタンＧ２６がアップデートの実行を指示するためボタンである。この設定ボタンＧ２６は、アップデートに関する情報がアップデート処理部１１０７より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。逆に、アップデートに関する情報がアップデート処理部１１０７より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部１１０５によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンＧ２６には、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が２．０の最新バージョンにアップデートすることが記載されている。なお、設定画面Ｇ２に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
【００６６】
ステップＳ１６において、設定ボタンＧ２６の選択操作が行われた場合、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面をディスプレイ１３に表示させる（ステップＳ１７）。
【００６７】
図１１は、確認画面Ｇ３の一例を示す概念図である。図１１に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンＧ３４、Ｇ３５とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む構成である。アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、メータデータの“ｒｅｂｏｏｔ”のデータ項目を参照して、確認画面Ｇ３のアップデート表示Ｇ３３に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６８】
図１２は、確認ウインドウＧ３６の一例を示す概念図である。確認画面Ｇ３において、アップデートの実行を指示する操作ボタンＧ３５が選択された場合は、再度ユーザに確認を促す確認ウインドウＧ３６を表示してもよい。確認ウインドウＧ３６には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面Ｇ３では、アップデートの実行が指示された場合に確認ウインドウＧ３６を表示することで、ユーザへの注意喚起を促すことができる。なお、メータデータの“ｒｅｂｏｏｔ”のデータ項目を参照して、確認ウィンドウＧ３６に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６９】
図７に戻り、アップデート処理部１１０７では、確認画面Ｇ３での操作ボタンＧ３４、Ｇ３５の選択操作をもとに、アップデートを実行するか否かを判定する（ステップＳ１８）。アップデートの実行を指示する操作ボタンＧ３５が選択された場合（ステップＳ１８：Ｙｅｓ）、アップデート処理部１１０７は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ１９）。ここで、アップデート処理の詳細については後述する。
【００７０】
アップデートの実行をキャンセルする操作ボタンＧ３４が選択されるなどして、操作ボタンＧ３５の選択が行われなかった場合（ステップＳ１８：Ｎｏ）、アップデート処理部１１０７は、自装置の処理を終了させる終了処理を行い（ステップＳ２０）、装置の電源を落とす。
【００７１】
すなわち、通話端末１１では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部１１０２のユーザ通知部１１０４よりユーザに通知する。そして、通話端末１１では、操作入力受付部１１０５により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート処理部１１０７によるアップデート処理が実行される。したがって、通話端末１１は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。
【００７２】
ステップＳ１２で、メタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されている場合、すなわち、強制アップデートである場合には（ステップＳ１２：Ｙｅｓ）、アップデート処理部１１０７は、その強制アップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ７０１）。具体的には、通常アップデートの場合と同様に、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｅｘｅｃｕｔｅ”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。
【００７３】
ユーザインタフェース部１１０２のユーザ通知部１１０４では、Ｓ６０２においてアップデート処理部１１０７より通知された強制アップデートに関する情報をもとに、自装置に必要な強制アップデートが存在することをディスプレイ１３の起動画面Ｇ１（図９参照）に表示して、ユーザへ通知する（ステップＳ６０２）。
【００７４】
具体的には、ユーザ通知部１１０４は、アップデートが強制アップデートである旨を、起動画面Ｇ１のステータス画面Ｇ１２に表示してもよいし、主画面Ｇ１１に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。
【００７５】
Ｓ７０１でユーザへの通知が行われると、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面Ｇ７０（図１３参照）をディスプレイ１３に表示させる（ステップＳ６０３）。なお、通常アップデート時のようなアップデートの設定画面Ｇ２（図１０参照）は表示されない。
【００７６】
図１３は、強制アップデート時に表示される確認画面Ｇ７０の一例を示す概念図である。図１３に示すように、確認画面Ｇ７０は、実行するアップデートの内容を表示するアップデート表示Ｇ７３と、アップデートの実行をユーザより受け付けるための操作ボタンＧ７５とを含む主画面Ｇ７２を含む構成である。アップデート表示Ｇ７３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、強制アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとにした、強制アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ７３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。
【００７７】
ここで、強制アップデートの確認画面Ｇ７０に表示されるボタンとして、アップデートボタンＧ７５しか表示されず、通常アップデートの確認画面Ｇ３（図１１）に表示されるキャンセルボタンＧ３４は表示されない。これは、強制アップデートの場合には、必ずアップデートを実施する必要があるからである。ただし、操作部１０８のメニューキーに対応した操作ボタンにより設定画面へ遷移したり、または、電源スイッチ１０９の押下による電源遮断を行うことができる。
【００７８】
図８に戻り、アップデート処理部１１０７は、確認画面Ｇ７０での操作ボタンＧ７５の選択操作をもとに、強制アップデートを実行するか否かを判定する（ステップＳ７０２）。強制アップデートの実行を指示する操作ボタンＧ７５が選択された場合（ステップＳ７０２：ＹＥＳ）、アップデート処理部１１０７は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ７０３）。
【００７９】
一方、ステップＳ７０２において、操作ボタンＧ７５が押下されず、操作部１０８の操作ボタンが押下された場合には（ステップＳ７０２：Ｎｏ）、押下された操作ボタンに従い、設定画面の表示や電源遮断を行う（ステップＳ７０５）。
【００８０】
次に、アップデート処理（ステップＳ１９，Ｓ７０３）の詳細について説明する。図１４は、アップデート処理の一例を示すフローチャートである。なお、ステップＳ１９とステップＳ７０３では、同一の図１４に示すアップデート処理が実行される。
【００８１】
図１４に示すように、アップデート処理部１１０７は、アップデート処理が開始されると、カメラ１２、マイク１４、スピーカ１５などの外部装置と接続するための撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム１０４が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート処理部１１０７は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。
【００８２】
次に、アップデート処理部１１０７は、取得したメタデータの“ｐａｃｋａｇｅ＿ｕｒｌ”からアップデートの実体となるデータファイルの格納先と、“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”からチェックサムとを取得する（ステップＳ１４０１）。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にＳ１４０１〜Ｓ１４１０の処理が行われるものとする。
【００８３】
次いで、アップデート処理部１１０７は、ステップＳ１４０１で取得したデータファイルをアップデートサーバ６０から取得する（ステップＳ１４０２）。このとき取得するファイルが、例えばキャビネットファイルやＺＩＰファイルといった複数のファイルをまとめたパッケージ形式であるパッケージファイルの場合には、データファイル（プログラム）が複数存在する場合にも取得する回数が１回のみで済み、ネットワーク帯域の利用を低減することができる。
【００８４】
次に、アップデート処理部１１０７は、ステップＳ１４０２で取得したデータファイルのチェックサムを確認する（ステップＳ１４０３）。そして、アップデート処理部１１０７は、取得したデータファイルが複数のファイルをまとめたパッケージファイルである場合、取得したパッケージファイルを展開して、アップデート用のファイルとスクリプトを取得する（ステップＳ１４０４）。このスクリプトには、ファイルの移動や削除といったアップデートに関するオペレーションの手順が記述される。
【００８５】
図１５は、スクリプトの一例を示す説明図である。図１５は、ディレクトリ作成・ファイル移動・処理中断・再起動等の各コマンドを、マイクロソフト（Ｒ）社の“Ｄｅｖｉｃｅ Ｕｐｄａｔｅ Ｓｃｒｉｐｔ”に基づいて記述したものである。アップデート用スクリプトは、図１５に示すように、人間が可読なテキスト形式で配布してもよいし、あるいは処理時間の低減を目的として、機械語形式、中間言語形式等にコンパイル処理を施して配布してもよい。
【００８６】
次に、アップデート処理部１１０７は、ステップＳ１４０４で取得したスクリプトを実行して、アップデートを実施する（ステップＳ１４０５）。次いで、アップデート処理部１１０７は、アップデートの進行状況をユーザインタフェース部１１０２に通知する（ステップＳ１４０６）。この進行状況の通知は、Ｓ１４０２、Ｓ１４０３、Ｓ１４０４、Ｓ１４０５の処理を終えたか否かを通知する。また、依存関係を有する複数のバージョン（依存バージョン）のアップデートを行う場合には、どのバージョンのアップデートまでを終了したかを通知してもよい。ユーザインタフェース部１１０２では、通知されたアップデートの進行状況をディスプレイ１３に画面表示してユーザに通知する。
【００８７】
図１６は、アップデート画面Ｇ４の一例を示す概念図である。図１６に示すように、アップデート画面Ｇ４は、アップデート処理部１１０７によるアップデート処理中にユーザインタフェース部１１０２がディスプレイ１３に表示させる画面である。アップデート画面Ｇ４には、アップデート処理部１１０７より通知されたアップデートの進行状況を表示するアップデートステータスウインドウＧ４１と、アップデートの中止を指示するための操作ボタンＧ４２とが表示される。ユーザは、アップデートステータスウインドウＧ４１の表示内容により、アップデートの進行状況を確認できる。
【００８８】
なお、この他、アップデート画面Ｇ４に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するように構成してもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。
【００８９】
次いで、アップデート処理部１１０７は、エラーの発生の有無を判定し（ステップＳ１４０７）、エラーの発生がある場合（ステップＳ１４０７：Ｙｅｓ）はステップＳ１４０１〜Ｓ１４１０の処理を抜けてステップＳ１４１２へ処理を進める。このＳ１４０７では、アップデート実行中に何らかの要因で発生するエラー（例えば、Ｓ１４０３におけるチェックサムの相違）の場合にもエラーとして判定される。
【００９０】
ステップＳ１４０７でエラーの発生がない場合には（ステップＳ１４０７：Ｎｏ）、アップデート処理部１１０７は、メタデータに含まれる、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されているか否かを判断することにより、再起動が必要であるか否かを判定する（ステップＳ１４０８）。
【００９１】
ここで、本実施の形態では、メタデータの“ｒｅｂｏｏｔ”は、実施したアップデートに次のアップデートを行う前に、再起動が必要か否かを示すものとなっている。図１４に示すアップデート処理では、ステップＳ１４０１からＳ１４１０までの処理で１回のアップデートを行い、複数のバージョンのアップデートを行う場合には、ステップＳ１４０１からＳ１４１０までの処理をアップデートのバージョン数だけ繰り返すことになっている。このため、本実施の形態では、ステップＳ１４０１からＳ１４１０までの処理の１回のループの最後に、メタデータに含まれる“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されているか否かを判断して、再起動の要否判断（ステップＳ１４０８）を行い、１回のアップデートごとに再起動を行っている。
【００９２】
そして、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されており再起動が必要である場合には（ステップＳ１４０８：Ｙｅｓ）、通話端末１１の再起動を行う（ステップＳ１４０９）。
【００９３】
そして、アップデート処理部１１０７は、全てのバージョンのアップデートが完了したか否かを判定する（ステップＳ１４１０）。全てのバージョンのアップデートが完了していない場合（ステップＳ１４１０：Ｎｏ）には、Ｓ１４０１へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合（ステップＳ１４１０：Ｙｅｅｓ）には、アップデート処理部１１０７は、通話端末１１の記憶部１０５の設定情報に設定されているプログラム１０４の端末バージョンをアップデートを行った最新バージョンに更新する（ステップＳ１４１１）。なお、ＯＳがマイクロソフト（Ｒ）社のＷｉｎｄｏｗｓ（登録商標）である場合には、アップデート処理部１１０７は、レジストリに設定されいるプログラム１０４の端末バージョンを最新バージョンに更新する。
【００９４】
次に、アップデート処理部１１０７は、Ｓ１４０１〜Ｓ１４１０によるアップデートの結果をユーザインタフェース部１１０２へ通知する（ステップＳ１４１２）。ユーザインタフェース部１１０２では、通知されたアップデートの結果をディスプレイ１３に画面表示してユーザに通知する。
【００９５】
通常アップデートの結果は図１７の画面が表示される。一方、強制アップデートの結果は、図１８に示す強制アップデート結果画面Ｇ８０が表示される。
【００９６】
図１７は、通常アップデートの場合の確認画面Ｇ５の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部１１０２は、図１７に示すように、Ｓ１４０１〜Ｓ１４１０によるアップデート結果Ｇ５１や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンＧ５２、Ｇ５３を確認画面Ｇ５に表示する。アップデート結果Ｇ５１には、アップデート前のバージョンにかかる情報の他、Ｓ１４０１〜Ｓ１４１０のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果Ｇ５１の表示内容により、ユーザは、アップデートの結果を確認できる。
【００９７】
図１８は、強制アップデート結果画面Ｇ８０の一例を示す概念図である。強制アップデート結果画面Ｇ８０では、通常アップデート時の確認画面Ｇ５と同様に、シャットダウンボタンＧ８４と再起動ボタンＧ８５とが表示され、ユーザはいずれかのボタンを押下可能である。
【００９８】
アップデート処理部１１０７は、アップデートの結果をユーザインタフェース部１１０２へ通知したらアップデート処理を終了する（ステップＳ１４１３）。
【００９９】
このように本実施の形態では、アップデートに依存するバージョンのアップデートが存在する場合には、この依存バージョンが通信端末１１のプログラム１０４の現在のバージョンである端末バージョンより新しいか否かを判断し、新しい場合には、依存バージョンのアップデートのメタデータをネットワークを介してアップデートサーバ６０に要求して取得し、かつ依存バージョンのアップデートのデータファイルをアップデートサーバ６０からネットワークを介して取得する。一方、依存バージョンが端末バージョンと等しいか、端末バージョンより古い場合には、依存バージョンのアップデートのメタデータの要求を行わず、従って依存バージョンのアップデートの取得も行わない。
【０１００】
従って、本実施の形態によれば、プログラム１０４のアップデートに１または複数の依存バージョンのアップデートがある場合でも、端末バージョンに応じて、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。
【０１０１】
また、本実施の形態では、通話端末１１に実行するアップデートがある場合において、そのアップデートの実行をユーザが選択することができるので、これによりユーザの利便性を図ることができる。
【０１０２】
また、本実施の形態では、通話端末１１が強制アップデートを実施しなければならない場合には、ユーザにキャンセルさせる選択を与えずに、強制アップデートを実行するので、中継装置３０等、通話端末１１側以外のアップデートにより通話端末１１本来の機能の実行が不可能になることを回避することができる。
【０１０３】
なお、本実施の形態では、遠隔通信管理サーバ５０とアップデートサーバ６０とを別個の構成とした例を示しているが、これに限定されるものではない。例えば、サーバ装置を設け、当該サーバ装置が遠隔通信管理サーバ５０の機能とアップデートサーバ６０の機能とを備えた構成としてもよい。
【０１０４】
なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１０５】
１ 遠隔通信システム
２ 通信ネットワーク
１１，１４１１ 通話端末
１２ カメラ
１３ ディスプレイ
１４ マイク
１５ スピーカ
３０ 中継装置
５０ 遠隔通信管理サーバ
６０ アップデートサーバ
６０１ 送受信部
６０２ アップデートデータ提供部
１１０１ 送受信部
１１０２ ユーザインタフェース部
１１０３ アップデート部
１１０４ ユーザ通知部
１１０５ 操作入力受付部
１１０６ 判断部
１１０７ アップデート処理部
Ｇ１ 起動画面
Ｇ２ 設定画面
Ｇ３ 確認画面
Ｇ４ アップデート画面
Ｇ５，Ｇ７０ 確認画面
Ｇ８０ 強制アップデート結果画面
【先行技術文献】
【特許文献】
【０１０６】
【特許文献１】米国特許７，８９０，９８９号公報
【技術分野】
【０００１】
本発明は、通信装置、アップデート方法およびアップデートプログラムに関する。
【背景技術】
【０００２】
近年、出張経費及び出張時間を削減する要請に伴い、インターネット等の通信ネットワークを介してテレビ会議などを行うための通話端末が普及している。各通話端末では、宛先の通話端末を指定して通話を開始することで、画像データ及び音声データの送受信が行われ、テレビ会議を実現することができる。
【０００３】
この通話端末では、通話秘匿性能や操作性能を向上させるため、ファームウエア（プログラム）のアップデートが定期的に行われることがある。この通話端末におけるプログラムのアップデートについては、特許文献１が知られている。特許文献１には、アップデートデータとメタ情報を、ネットワークを介してサーバへアクセスして取得し、プログラムおよび当該プログラムに依存するバージョンのプログラムをアップデートすることが開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した従来技術では、プログラムに依存するバージョンのプログラムのアップデートを行う必要がある場合には、当該依存するバージョンのメタ情報も、ネットワークを介してサーバへアクセスして取得するため、依存するバージョンが複数存在する場合には、複数のバージョンの数だけ何回もメタ情報をネットワークを介して取得しなければならず、ネットワーク帯域の利用が増加してネットワーク負荷が増大するとともに、アップデートの処理が煩雑で時間を要するという問題がある。
【０００５】
本発明は、上記に鑑みてなされたものであって、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができる通信装置、アップデート方法及びアップデートプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明にかかる通信装置は、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第１受信部と、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第２受信部と、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、を備えたことを特徴とする。
【０００７】
また、本発明にかかるアップデート方法は、通信装置で実行されるアップデート方法であって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を含むことを特徴とする。
【０００８】
また、本発明にかかるアップデートプログラムは、コンピュータに実行させるためのアップデートプログラムであって、アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、を前記コンピュータに実行させる。
【発明の効果】
【０００９】
本発明によれば、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、本実施の形態の遠隔通信システムの構成を例示する模式図である。
【図２】図２は、本実施の形態の通話端末のハードウエア構成を例示するブロック図である。
【図３】図３は、本実施の形態の通話端末の外観図である。
【図４】図４は、本実施の形態の中継装置、遠隔通信管理サーバ、アップデートサーバのハードウエア構成を例示するブロック図である。
【図５】図５は、本実施の形態の通話端末及びアップデートサーバの機能構成を例示するブロック図である。
【図６】図６は、本実施の形態のメタデータの一例を示す概念図である。
【図７】図７は、本実施の形態の通話端末の動作の一例を示すラダーチャートである。
【図８】図８は、本実施の形態の通話端末の動作の一例を示すラダーチャートである。
【図９】図９は、本実施の形態の起動画面の一例を示す概念図である。
【図１０】図１０は、本実施の形態の設定画面の一例を示す概念図である。
【図１１】図１１は、本実施の形態の確認画面の一例を示す概念図である。
【図１２】図１２は、本実施の形態の確認ウインドウの一例を示す概念図である。
【図１３】図１３は、本実施の形態の強制アップデート時の確認画面の一例を示す概念図である。
【図１４】図１４は、本実施の形態のアップデート処理の一例を示すフローチャートである。
【図１５】図１５は、本実施の形態のスクリプトの一例を示す説明図である。
【図１６】図１６は、本実施の形態のアップデート画面の一例を示す概念図である。
【図１７】図１７は、本実施の形態の通常アップデートの場合の確認画面の一例を示す概念図である。
【図１８】図１８は、本実施の形態の強制アップデート結果画面の一例を示す概念図である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、この発明にかかる通信装置、アップデート方法およびアップデートプログラムの実施の形態を詳細に説明する。
【００１２】
図１は、本実施の形態の遠隔通信システム１の構成を例示する模式図である。図１に示すように、遠隔通信システム１は、通信ネットワーク２により通信装置としての通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、遠隔通信管理サーバ５０、アップデートサーバ６０及びルータ７０ａ〜７０ｄが通信可能に接続されるシステムである。具体的には、遠隔通信システム１は、インターネット２ｉにルータ７０ａ〜７０ｄを介して接続するＬＡＮ２ａ、２ｂ、２ｃ、２ｄ、遠隔通信管理サーバ５０及びアップデートサーバ６０と、ＬＡＮ２ａに接続する通話端末１１ａａ〜１１ａｃ及び中継装置３０ａと、ＬＡＮ２ｂに接続する通話端末１１ｂａ〜１１ｂｃ及び中継装置３０ｂと、ＬＡＮ２ｃに接続する通話端末１１ｃａ〜１１ｃｃ及び中継装置３０ｃと、ＬＡＮ２ｄに接続する通話端末１１ｄａ〜１１ｄｃ及び中継装置３０ｄとを有する構成である。遠隔通信システム１では、遠隔通信管理サーバ５０の管理の下、地域Ａの通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、地域Ｂの通話端末１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃの各々が、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄによる通信データの中継を介して、互いに音声又は映像を送受信することで通話を行う。
【００１３】
具体的には、遠隔通信管理サーバ５０は、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄなどの通信アドレス、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄの各々が中継を行う通話端末、各通話端末の通話状態などの情報を管理する。例えば、通話端末１１ａａが通話端末１１ｃａと通話を行う場合は、中継装置３０ａに通話端末１１ｃａへの通話の中継を依頼する。中継装置３０ａは、遠隔通信管理サーバ５０に通話端末１１ａａの通話の開始を通知するとともに、通話端末１１ｃａへ通話を中継するための中継装置３０ｃの通信アドレスを遠隔通信管理サーバ５０より取得する。次いで、中継装置３０ａは通話端末１１ｃａへ通話の中継を中継装置３０ｃに依頼し、中継装置３０ｃは、通話端末１１ｃａとの通信セッションを開始する。次いで、中継装置３０ｃは、通話端末１１ｃａとの通信セッションの開始を遠隔通信管理サーバ５０へ通知する。
【００１４】
これにより、中継装置３０ａ、３０ｃを介して、通話端末１１ａａ及び通話端末１１ｃａとの間の通話が開始される。また、遠隔通信管理サーバ５０は、通話端末１１ａａ及び通話端末１１ｃａが通話中であることを管理する。例えば、遠隔通信管理サーバ５０は、通話端末１１ａｂから通話端末１１ａａや通話端末１１ｃａなどの通話状態の問い合わせがあった場合は、オンラインであるが互いに通話中であることを返信する。
【００１５】
なお、以下の説明において、同種の装置の中の任意の装置について説明を行う場合は、数字の後の英数字を略した符号を用いるものとする。例えば、通話端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃは通話端末１１と略すものとする。また、中継装置３０ａ〜３０ｄは中継装置３０と略すものとする。
【００１６】
アップデートサーバ６０は、通話端末１１のプログラムや各種設定情報のアップデートプログラムによるアップデートにかかる情報を管理し、通話端末１１の要求に応じてその情報を提供するアップデート情報提供装置である。アップデートにかかる情報としては、通話端末１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータ（メタ情報）などである。アップデートにかかる情報として全てのバージョンのデータをアップデートサーバ６０が管理する理由は、通話端末１１がアップデートを行うタイミングが各々異なるためである。
【００１７】
例えば、頻繁にアップデートを行っている通話端末１１は、最新のバージョンへのアップデートを行うだけでよいかもしれないが、アップデートの間隔が長い通話端末１１は、何回かバージョンアップが繰り返された後にアップデートを行うかもしれない。このような場合は、直に最新のバージョンへアップデートせずに、最新のバージョンと依存関係のある古いバージョンへのアップデートを経ることがある。このように、依存関係のある古いバージョンへのアップデートを経る通話端末１１もあることから、アップデートサーバ６０は、アップデートにかかる情報として全てのバージョンのデータを管理している。
【００１８】
ここで、アップデートの種類には、通常アップデートと強制アップデートの２種類がある。通常アップデートは、バグ等の障害対応や機能追加を目的として実施されるアップデートである。
【００１９】
強制アップデートは、通話端末１１そのものの機能とは異なる装置、機能の変更に伴って、強制的に行うことを目的としたアップデートである。例えば、中継装置３０側において、通話の際に送受信する音声や画像のデータフォーマットやビデオコーデックが変更されたり、エンコーダのアップデート等の映像に関する中継装置３０のバージョンアップが実施される場合がある。また、中継装置３０との通信プロトコルが変更される場合もある。このような変更は、音声や画像、映像そのものの構造が変わり、あるいは通信プロトコルの変更に伴う中継装置３０との通信手順そのものが変わり、もしくは中継装置３０側の機能が変わるため、アップデート前の通話端末１１では、通話端末１１の本来の機能である通話を実現することができない。このため、このような場合には、中継装置３０のアップデート後のバージョンに適合させるために強制アップデートを行う。
【００２０】
また、中継装置３０側でセキュリティホールが発見された場合等、セキュリティ面で問題がある等に、これを回避するようなセキュリティホール対応のアップデートを中継装置３０側で行う場合がある。このような場合にも、アップデート前の通話端末１１では通話すら実行できないことになるため、中継装置３０側のセキュリティホール対応に適合させるために強制アップデートが実施される。
【００２１】
次に、通話端末１１のハードウエア構成を説明する。図２は、通話端末１１のハードウエア構成を例示するブロック図である。図２に示すように、通話端末１１は、ＣＰＵ１０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ１０２（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ１０３（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、記憶部１０５、メディアドライブ１０７、操作部１０８、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３及びディスプレイＩ／Ｆ１１４を備え、各部がバス１１０により互いに接続される構成である。
【００２２】
ＣＰＵ１０１は、ＲＯＭ１０２や記憶部１０５に記憶されたプログラム１０４をＲＡＭ１０３に展開して順次実行することで、通話端末１１の動作を中央制御する。記憶部１０５は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などであり、読み出し／書き込み可能にデータを記憶する。具体的には、記憶部１０５は、ＣＰＵ１０１が実行するためのプログラム１０４や各種設定情報を記憶する。アップデートの際には、この記憶部１０５に記憶されるプログラム１０４や各種設定情報が更新される。なお、本実施の形態では、プログラム１０４がアップデート対象であるとして説明する。
【００２３】
メディアドライブ１０７は、光ディスクなどのメディア１０６の読み出し／書き込みを行うドライブ装置である。操作部１０８は、キーボード、各種操作キー、ディスプレイ１３上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークＩ／Ｆ１１１は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。撮像素子Ｉ／Ｆ１１２は、デジタルカメラであるカメラ１２と接続し、カメラ１２が撮像した画像を取得するためのインタフェースである。音声入出力Ｉ／Ｆ１１３は、マイク１４、スピーカ１５と接続し、マイク１４による音声入力や、スピーカ１５を介した音声出力を行うインタフェースである。ディスプレイＩ／Ｆ１１４は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などであるディスプレイ１３と接続し、ディスプレイ１３へ表示データを出力するインタフェースである。
【００２４】
なお、本実施の形態では、ディスプレイ１３を用いているが、ディスプレイ１３に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。
【００２５】
通話端末１１は、プログラム１０４を実行したＣＰＵ１０１の制御の下、例えば他の通話端末との通話時には、カメラ１２から取得した画像やマイク１４から入力された音声をネットワークＩ／Ｆ１１１を介して中継装置３０へ出力する。また、中継装置３０より中継され、ネットワークＩ／Ｆ１１１を介して入力された他の通話端末からの音声をスピーカ１５より出力し、同様に他の通話端末からの画像をディスプレイ１３により表示する。これにより、通話端末１１は、画像及び音声による他の通話端末との通話、いわゆるテレビ会議を実現する。
【００２６】
次に、通話端末１１の外観構成について説明する。図３は、本実施の形態の通話端末１１の外観図である。通話端末１１は、図３に示すように、筐体１１００、アーム１２００、カメラハウジング１３００を備えている。
【００２７】
筐体１１００の右側壁面１１３０には、操作パネル１１５０が形成されている。操作パネル１１５０には、操作部１０８としての複数の操作ボタン１０８ａ〜１０８ｅ、電源スイッチ１０９、アラームランプ１１９、内蔵スピーカからの音声を出力するための音出力面１１５１等が形成されている。
【００２８】
また、筐体１１００の左側壁面１１４０には、アーム１２００およびカメラハウジング１３００を収容するための凹部としての収容部１１６０が形成されている。この通話端末１１の筐体１１００にはケーブルでディスプレイ１３が接続されている。
【００２９】
アーム１２００は、トルクヒンジ１２１０を介して筐体１１００に取り付けられており、アーム１２００が筐体１１００に対して、１３５度のチルト角θ１の範囲で、上下方向に回転可能に構成されている。図３では、チルト角θ１が９０度の状態を示している。
【００３０】
カメラハウジング１３００には、上述のカメラ１２が内蔵されており、ユーザ、書類、および部屋等を撮像することができる。また、カメラハウジング１３００は、トルクヒンジ１３１０が形成されている。カメラハウジング１３００は、トルクヒンジ１３１０を介して、アーム１２００に取り付けられている。そして、カメラハウジング１３００は、トルクヒンジ１３１０がアーム１２００に対して、図３で示される状態を０度として±１８０度のパン角θ２の範囲で、かつ、±４５度のチルト角θ３の範囲で、上下左右方向に回転可能に構成されている。
【００３１】
次に、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を説明する。図４は、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を例示するブロック図である。図４に示すように、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶部２０４、ディスプレイ２０５、ネットワークＩ／Ｆ２０６、キーボード２０７、マウス２０８、メディアドライブ２０９及びＣＤ−ＲＯＭドライブ２１１を備え、各部がバス２１４により互いに接続される構成である。中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、いわゆるＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やＷＳ（Ｗｏｒｋ Ｓｔａｔｉｏｎ）などの機器である。
【００３２】
ＣＰＵ２０１は、ＲＯＭ２０２や記憶部２０４に記憶されたプログラムをＲＡＭ２０３に展開して順次実行することで、自装置の動作を中央制御する。記憶部２０４は、ＨＤＤやＳＳＤなどであり、読み出し／書き込み可能にデータを記憶する。例えば、アップデートサーバ６０では、アップデートにかかる情報などが記憶部２０４に記憶されている。
【００３３】
ディスプレイ２０５は、例えばＬＣＤなどである。ネットワークＩ／Ｆ２０６は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。キーボード２０７、マウス２０８は、ユーザの操作入力を受け付ける。メディアドライブ２０９は、光ディスクなどのメディア２１０の読み出し／書き込みを行うドライブ装置である。ＣＤ−ＲＯＭドライブ２１１は、ＣＤ−ＲＯＭ２１３の読み出しを行うドライブ装置である。例えば、アップデートサーバ６０では、メディア２１０やＣＤ−ＲＯＭ２１３によりアップデートにかかる最新の情報が提供され、記憶部２０４に記憶される。
【００３４】
次に、ＣＰＵ１０１やＣＰＵ２０１がプログラムを実行することで実現される、通話端末１１及びアップデートサーバ６０の機能構成について説明する。図５は、本実施の形態の通話端末１１及びアップデートサーバ６０の機能構成を例示するブロック図である。
【００３５】
まず、通話端末１１の機能的構成について説明する。図５に示すように、通話端末１１は、送受信部１１０１、ユーザインタフェース部１１０２及びアップデート部１１０３を主に有している。
【００３６】
送受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う。具体的には、送受信部１１０１は、記憶部１０５の設定情報などに予め設定されているアップデートサーバ６０の通信アドレスや遠隔通信管理サーバ５０へ問い合わせて取得したアップデートサーバ６０の通信アドレスをもとに、アップデートサーバ６０との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ６０との間でデータの送受信を行う。このデータの送受信により、送受信部１１０１は、アップデートサーバ６０が管理しているアップデートにかかる情報を取得する。すなわち、送受信部１１０１は、アップデートサーバ６０から、通話端末１１のプログラム１０４に必要なアップデートを示すメタデータを受信する。
【００３７】
ユーザインタフェース部１１０２は、スピーカ１５による音声出力、ディスプレイ１３の表示画面、操作部１０８によるユーザの操作入力の受け付けなどを制御して、ユーザと通話端末１１との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部１１０２は、スピーカ１５による音声出力やディスプレイ１３の表示画面でユーザへの各種通知を行うユーザ通知部１１０４と、操作部１０８によるユーザの操作入力を受け付ける操作入力受付部１１０５とを有する。
【００３８】
アップデート部１１０３は、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報をもとに、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデートを実行する。アップデート部１１０３は、判断部１１０６とアップデート処理部１１０７とを備えている。
【００３９】
判断部１１０６は、対象のアップデートの最新バージョンが端末バージョン（装置バージョン）より新しいか否かを判断する。ここで、端末バージョンは、通話端末１１のアップデート対象のプログラム１０４の現在のバージョンである。この端末バージョンは、記憶部１０５の設定情報に設定されている。例えば、ＯＳ（オペレーティングシステム）がマイクロソフト（Ｒ）社のＷｉｎｄｏｗｓ（登録商標）である場合には、設定情報としてのレジストリに端末バージョンが設定されている。
【００４０】
また、判断部１１０６は、最新バージョンが端末バージョンより新しい場合において、メタデータに、対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、この依存バージョンと端末バージョンとを比較し、依存バージョンが端末バージョンより新しいか否かを判断する。
【００４１】
本実施の形態の送受信部１１０１は、この判断結果により、以下の処理を行う。送受信部１１０１は、依存バージョンが端末バージョンより新しい場合に、依存バージョンのアップデートを示すメタデータをアップデートサーバ６０に対して要求し、アップデートサーバ６０から依存バージョンのメタデータを受信する。送受信部１１０１は、依存バージョンが端末バージョンより新しくない場合には、アップデートサーバ６０に対する依存バージョンのメタデータの要求は行わず、従ってメタデータの受信は行われない。
【００４２】
アップデート処理部１１０７は、依存バージョンのアップデートプログラムのメタデータに基づいて依存バージョンのアップデートを実行し、依存バージョンのアップデートの実行後、アップデート対象のアップデートプログラムのメタデータに基づいて、アップデート対象のアップデートプログラムのアップデートを実行する。また、アップデート処理部１１０７は、アップデート対象のアップデートプログラムの実行後に、端末バージョンを最新バージョンに更新して設定する。また、アップデート処理部１１０７は、メタデータで指定された格納先からデータファイルを受信し、アップデートを実行する。ここで、アップデート処理部１１０７は、データファイルが複数のデータをまとめたキャビネットファイルやＺＩＰ形式等のパッケージ形式のファイル（パッケージファイル）である場合には、当該パッケージファイルに含まれているスクリプトを実行することにより、アップデート処理を行う。ここで、スクリプトは、アップデートの実行手順が記述された実行可能な形式のデータである。
【００４３】
次に、アップデートサーバ６０の機能的構成について説明する。アップデートサーバ６０は、図５に示すように、送受信部６０１及びアップデートデータ提供部６０２を主に有している。
【００４４】
送受信部６０１は、通信ネットワーク２を介して通話端末１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した通話端末１１の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末１１との間でデータの送受信を行う。
【００４５】
アップデートデータ提供部６０２は、送受信部６０１によってデータの送受信を行っている通話端末１１からの要求に応じて、アップデートサーバ６０が管理しているアップデートにかかる情報を通話端末１１に提供する。
【００４６】
ここで、メタデータの詳細について説明する。図６は、メタデータの一例を示す概念図である。図６に示すように、各バージョンのメタデータは、“ｖｅｒｓｉｏｎ”、“ｄｅｓｃｒｉｐｔｉｏｎ”、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”、“ｅｘｅｃｕｔｅ”、“ｒｅｂｏｏｔ”、“ｃｒｉｔｉｃａｌ”、“ｄｅｐｅｎｄｅｎｃｙ”、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”、“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”などのデータ項目を含む構成である。
【００４７】
“ｖｅｒｓｉｏｎ”には、“１．０．１”などのアップデートプログラムのバージョン番号が設定される。“ｄｅｐｅｎｄｅｎｃｙ”は、依存関係を有する他のバージョンである依存バージョンが存在するか否かを示すフラグであり、依存バージョンが存在する場合には“ｔｒｕｅ”、依存バージョンが存在しない場合には“ｆａｌｓｅ”がそれぞれ設定される。依存バージョンが存在する場合、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”には、互いに依存関係を有する他のバージョンを示すバージョン番号、すなわち、依存バージョンのバージョン番号が設定される。従って、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に記述されたバージョン番号を確認することで、依存バージョンへと遡ることが可能である。“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”には、依存バージョンのメタデータの格納先のＵＲＬが設定される。
【００４８】
“ｄｅｓｃｒｉｐｔｉｏｎ”には、“Ｉｔ ｉｓ ｓａｍｐｌｅ ｄａｔａ．”などのバージョンの詳細が設定される。“ｐａｃｋａｇｅ＿ｕｒｌ”には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）の格納先のＵＲＬが設定される。“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”には、アップデートの実体となるデータファイルのチェックサムが設定される。従って、アップデート処理部１１０７は、“ｐａｃｋａｇｅ＿ｕｒｌ”のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。
【００４９】
“ｅｘｅｃｕｔｅ”には、アップデートを実行する際に実行するスクリプトのスクリプト名が設定される。このスクリプトは、取得したデータファイルがパッケージ形式のパッケージファイルである場合に、このパッケージファイルの内部に含まれている。“ｒｅｂｏｏｔ”は、アップデートを実行した後に、通話端末１１の再起動を行うか否かを示すフラグであり、再起動を行う場合には“ｔｒｕｅ”、再起動を行わない場合には“ｆａｌｓｅ”がそれぞれ設定される。“ｃｒｉｔｉｃａｌ”は、アップデートが強制アップデートであるか否かを示すフラグであり、強制アップデートの場合には“ｔｒｕｅ”、通常アップデートの場合には“ｆａｌｓｅ”が設定される。
【００５０】
記憶部１０５のプログラム１０４のアップデートには、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３、ディスプレイＩ／Ｆ１１４等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定される。また、プログラムのアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定される。
【００５１】
次に、以上のように構成された通話端末１１の動作の詳細を説明する。図７，図８は、本実施の形態の通話端末１１の動作の一例を示すラダーチャートである。
【００５２】
図７に示すように、ユーザインタフェース部１１０２は、操作部１０８の電源スイッチなどの操作に応じて自装置の電源投入（電源オン）を行い（ステップＳ１）、起動画面をディスプレイ１３に表示させる（ステップＳ２）。この起動画面は、ＣＰＵ１０１の制御の下で遠隔通信管理サーバ５０へ問い合わせて得られた各通話端末１１の通話状態を一覧表示した表示画面である（詳細は後述する）。
【００５３】
アップデート処理部１１０７は、ステップＳ１による電源投入後の起動時において、自装置のアップデートの確認を開始する（ステップＳ３）。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。
【００５４】
アップデートの確認が開始されると、アップデート処理部１１０７は、送受信部１１０１によって、最新バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ４）、その要求に対応して、アップデートサーバ６０のアップデートデータ提供部６０２が提供するメタデータを取得する（ステップＳ５）。
【００５５】
次に、判断部１１０６は、端末バージョンを記憶部１０４の設定情報から取得し、最新バージョンが通話端末１１の端末バージョンより新しいか否かを判断する（ステップＳ６）。
【００５６】
そして、最新バージョンが端末バージョンより新しくない場合（ステップＳ６：Ｎｏ）、すなわち、最新バージョンが端末バージョンと等しいか、最新バージョンが端末バージョンより古い場合には、アップデート処理を行わずに動作を継続する（ステップＳ２１）。
【００５７】
一方、ステップＳ６で、最新バージョンが端末バージョンより新しい場合（ステップＳ６：Ｙｅｓ）、アップデート処理部１１０７は、取得したメタデータの“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に記述された内容をもとに、依存バージョンの有無を確認する（ステップＳ７）。例えば、図６に示すように、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目が“ｔｒｕｅ”であり、“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に“１．０．０”などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目が“ｆａｌｓｅ”の場合には、依存するバージョンがないものとする。
【００５８】
次いで、判断部１１０６は、ステップＳ７による確認の結果、依存バージョンが有るか否かを判定する（ステップＳ８）。依存バージョンがある場合（ステップＳ８：Ｙｅｓ）、判断部１１０６は、メタデータの“ｄｅｐｅｎｄｅｎｃｙ＿ｖｅｒｓｉｏｎ”のデータ項目に設定されたバージョン番号が端末バージョンにより大きいか否かを判断することにより、依存バージョンが端末バージョンより新しいか否かを判断する（ステップＳ９）。そして、依存バージョンが端末バージョンより新しい場合には（ステップＳ９：Ｙｅｓ）、アップデート処理部１１０７は、送受信部１１０１によって、既に取得済みのメタデータの“ｄｅｐｅｎｄｅｎｃｙ＿ｍｅｔａｄａｔａ＿ｕｒｌ”のデータ項目に設定された格納先をもとに、依存バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ１０）、その要求に対応してアップデートデータ提供部６０２が提供する、依存バージョンのメタデータを取得して（ステップＳ１１）、Ｓ７へ処理を戻す。したがって、アップデート処理部１１０７は、依存バージョンが端末バージョンより新しい場合に限り、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。
【００５９】
ステップＳ８で依存バージョンが存在しない場合（ステップＳ８：Ｎｏ）、またはステップＳ８で依存バージョンが存在するが（ステップＳ８：Ｙｅｓ）、ステップＳ９で依存バージョンが端末バージョンより新しくない場合（ステップＳ９：Ｎｏ）には、アップデート処理部１１０７は、取得したメタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されているか否かを判断することにより、今回のアップデートが強制アップデートか否かを判断する（ステップＳ１２）。
【００６０】
そして、メタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されておらず、通常アップデートである場合には（ステップＳ１２：Ｎｏ）、アップデート処理部１１０７は、最新バージョンのメタデータの“ｖｅｒｓｉｏｎ”に記述されたバージョン番号と、自装置の端末バージョン（記憶部１０５に記憶されたプログラム１０４のバージョン番号）とを比較することで、自装置のアップデートが存在するか否か（すなわち、アップデート済みか否か）を判定する（ステップＳ１３）。具体的には、最新バージョンのバージョン番号と、端末バージョンとが一致する場合は、プログラム１０４が最新バージョンであることから、自装置に必要なアップデートが存在しない（すなわち、アップデート済み）と判定する。また、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、自装置に必要なアップデートが存在する（すなわち、アップデート済みでない）と判定する。自装置に必要なアップデートが存在しない場合（ステップＳ１３：Ｎｏ）は、アップデートを実行する必要がないことから、通常の動作を継続させる（ステップＳ２１）。
【００６１】
自装置のアップデートが存在する場合（ステップＳ１３：ＹＥＳ）、アップデート処理部１１０７は、そのアップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ１４）。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｅｘｅｃｕｔｅ”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。
【００６２】
ユーザインタフェース部１１０２のユーザ通知部１１０４では、Ｓ１４においてアップデート処理部１１０７より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ１３の起動画面に表示して、ユーザへ通知する（ステップＳ１５）。
【００６３】
ここで、起動画面の詳細について説明する。図９は、起動画面Ｇ１の一例を示す概念図である。図９に示すように、起動画面Ｇ１は、各通話端末の通話状態を一覧表示する主画面Ｇ１１と、自装置のステータスを表示するステータス画面Ｇ１２とを含む構成である。ユーザ通知部１１０４は、アップデートに関する情報がアップデート処理部１１０７より通知された場合は、ステータス画面Ｇ１２にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面Ｇ１１に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例（図９〜１３等）において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。
【００６４】
ステップＳ１５によるユーザへの通知によって、ユーザインタフェース部１１０２の操作入力受付部１１０５によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部１１０２は、設定画面をディスプレイ１３に表示させる（ステップＳ１６）。
【００６５】
図１０は、設定画面Ｇ２の一例を示す概念図である。図１０に示すように、設定画面Ｇ２は、操作入力受付部１１０５によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンＧ２３〜Ｇ２６を表示する主画面Ｇ２１を含む構成である。設定ボタンＧ２３〜Ｇ２６の中で設定ボタンＧ２６がアップデートの実行を指示するためボタンである。この設定ボタンＧ２６は、アップデートに関する情報がアップデート処理部１１０７より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。逆に、アップデートに関する情報がアップデート処理部１１０７より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部１１０５によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンＧ２６には、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が２．０の最新バージョンにアップデートすることが記載されている。なお、設定画面Ｇ２に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。
【００６６】
ステップＳ１６において、設定ボタンＧ２６の選択操作が行われた場合、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面をディスプレイ１３に表示させる（ステップＳ１７）。
【００６７】
図１１は、確認画面Ｇ３の一例を示す概念図である。図１１に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンＧ３４、Ｇ３５とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む構成である。アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、メータデータの“ｒｅｂｏｏｔ”のデータ項目を参照して、確認画面Ｇ３のアップデート表示Ｇ３３に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６８】
図１２は、確認ウインドウＧ３６の一例を示す概念図である。確認画面Ｇ３において、アップデートの実行を指示する操作ボタンＧ３５が選択された場合は、再度ユーザに確認を促す確認ウインドウＧ３６を表示してもよい。確認ウインドウＧ３６には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面Ｇ３では、アップデートの実行が指示された場合に確認ウインドウＧ３６を表示することで、ユーザへの注意喚起を促すことができる。なお、メータデータの“ｒｅｂｏｏｔ”のデータ項目を参照して、確認ウィンドウＧ３６に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。
【００６９】
図７に戻り、アップデート処理部１１０７では、確認画面Ｇ３での操作ボタンＧ３４、Ｇ３５の選択操作をもとに、アップデートを実行するか否かを判定する（ステップＳ１８）。アップデートの実行を指示する操作ボタンＧ３５が選択された場合（ステップＳ１８：Ｙｅｓ）、アップデート処理部１１０７は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ１９）。ここで、アップデート処理の詳細については後述する。
【００７０】
アップデートの実行をキャンセルする操作ボタンＧ３４が選択されるなどして、操作ボタンＧ３５の選択が行われなかった場合（ステップＳ１８：Ｎｏ）、アップデート処理部１１０７は、自装置の処理を終了させる終了処理を行い（ステップＳ２０）、装置の電源を落とす。
【００７１】
すなわち、通話端末１１では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部１１０２のユーザ通知部１１０４よりユーザに通知する。そして、通話端末１１では、操作入力受付部１１０５により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート処理部１１０７によるアップデート処理が実行される。したがって、通話端末１１は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。
【００７２】
ステップＳ１２で、メタデータの“ｃｒｉｔｉｃａｌ”が“ｔｒｕｅ”に設定されている場合、すなわち、強制アップデートである場合には（ステップＳ１２：Ｙｅｓ）、アップデート処理部１１０７は、その強制アップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ７０１）。具体的には、通常アップデートの場合と同様に、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“ｐａｃｋａｇｅ＿ｕｒｌ”、“ｅｘｅｃｕｔｅ”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。
【００７３】
ユーザインタフェース部１１０２のユーザ通知部１１０４では、Ｓ６０２においてアップデート処理部１１０７より通知された強制アップデートに関する情報をもとに、自装置に必要な強制アップデートが存在することをディスプレイ１３の起動画面Ｇ１（図９参照）に表示して、ユーザへ通知する（ステップＳ６０２）。
【００７４】
具体的には、ユーザ通知部１１０４は、アップデートが強制アップデートである旨を、起動画面Ｇ１のステータス画面Ｇ１２に表示してもよいし、主画面Ｇ１１に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。
【００７５】
Ｓ７０１でユーザへの通知が行われると、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面Ｇ７０（図１３参照）をディスプレイ１３に表示させる（ステップＳ６０３）。なお、通常アップデート時のようなアップデートの設定画面Ｇ２（図１０参照）は表示されない。
【００７６】
図１３は、強制アップデート時に表示される確認画面Ｇ７０の一例を示す概念図である。図１３に示すように、確認画面Ｇ７０は、実行するアップデートの内容を表示するアップデート表示Ｇ７３と、アップデートの実行をユーザより受け付けるための操作ボタンＧ７５とを含む主画面Ｇ７２を含む構成である。アップデート表示Ｇ７３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、強制アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとにした、強制アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ７３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。
【００７７】
ここで、強制アップデートの確認画面Ｇ７０に表示されるボタンとして、アップデートボタンＧ７５しか表示されず、通常アップデートの確認画面Ｇ３（図１１）に表示されるキャンセルボタンＧ３４は表示されない。これは、強制アップデートの場合には、必ずアップデートを実施する必要があるからである。ただし、操作部１０８のメニューキーに対応した操作ボタンにより設定画面へ遷移したり、または、電源スイッチ１０９の押下による電源遮断を行うことができる。
【００７８】
図８に戻り、アップデート処理部１１０７は、確認画面Ｇ７０での操作ボタンＧ７５の選択操作をもとに、強制アップデートを実行するか否かを判定する（ステップＳ７０２）。強制アップデートの実行を指示する操作ボタンＧ７５が選択された場合（ステップＳ７０２：ＹＥＳ）、アップデート処理部１１０７は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ７０３）。
【００７９】
一方、ステップＳ７０２において、操作ボタンＧ７５が押下されず、操作部１０８の操作ボタンが押下された場合には（ステップＳ７０２：Ｎｏ）、押下された操作ボタンに従い、設定画面の表示や電源遮断を行う（ステップＳ７０５）。
【００８０】
次に、アップデート処理（ステップＳ１９，Ｓ７０３）の詳細について説明する。図１４は、アップデート処理の一例を示すフローチャートである。なお、ステップＳ１９とステップＳ７０３では、同一の図１４に示すアップデート処理が実行される。
【００８１】
図１４に示すように、アップデート処理部１１０７は、アップデート処理が開始されると、カメラ１２、マイク１４、スピーカ１５などの外部装置と接続するための撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム１０４が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート処理部１１０７は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。
【００８２】
次に、アップデート処理部１１０７は、取得したメタデータの“ｐａｃｋａｇｅ＿ｕｒｌ”からアップデートの実体となるデータファイルの格納先と、“ｐａｃｋａｇｅ＿ｄｉｇｅｓｔ”からチェックサムとを取得する（ステップＳ１４０１）。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にＳ１４０１〜Ｓ１４１０の処理が行われるものとする。
【００８３】
次いで、アップデート処理部１１０７は、ステップＳ１４０１で取得したデータファイルをアップデートサーバ６０から取得する（ステップＳ１４０２）。このとき取得するファイルが、例えばキャビネットファイルやＺＩＰファイルといった複数のファイルをまとめたパッケージ形式であるパッケージファイルの場合には、データファイル（プログラム）が複数存在する場合にも取得する回数が１回のみで済み、ネットワーク帯域の利用を低減することができる。
【００８４】
次に、アップデート処理部１１０７は、ステップＳ１４０２で取得したデータファイルのチェックサムを確認する（ステップＳ１４０３）。そして、アップデート処理部１１０７は、取得したデータファイルが複数のファイルをまとめたパッケージファイルである場合、取得したパッケージファイルを展開して、アップデート用のファイルとスクリプトを取得する（ステップＳ１４０４）。このスクリプトには、ファイルの移動や削除といったアップデートに関するオペレーションの手順が記述される。
【００８５】
図１５は、スクリプトの一例を示す説明図である。図１５は、ディレクトリ作成・ファイル移動・処理中断・再起動等の各コマンドを、マイクロソフト（Ｒ）社の“Ｄｅｖｉｃｅ Ｕｐｄａｔｅ Ｓｃｒｉｐｔ”に基づいて記述したものである。アップデート用スクリプトは、図１５に示すように、人間が可読なテキスト形式で配布してもよいし、あるいは処理時間の低減を目的として、機械語形式、中間言語形式等にコンパイル処理を施して配布してもよい。
【００８６】
次に、アップデート処理部１１０７は、ステップＳ１４０４で取得したスクリプトを実行して、アップデートを実施する（ステップＳ１４０５）。次いで、アップデート処理部１１０７は、アップデートの進行状況をユーザインタフェース部１１０２に通知する（ステップＳ１４０６）。この進行状況の通知は、Ｓ１４０２、Ｓ１４０３、Ｓ１４０４、Ｓ１４０５の処理を終えたか否かを通知する。また、依存関係を有する複数のバージョン（依存バージョン）のアップデートを行う場合には、どのバージョンのアップデートまでを終了したかを通知してもよい。ユーザインタフェース部１１０２では、通知されたアップデートの進行状況をディスプレイ１３に画面表示してユーザに通知する。
【００８７】
図１６は、アップデート画面Ｇ４の一例を示す概念図である。図１６に示すように、アップデート画面Ｇ４は、アップデート処理部１１０７によるアップデート処理中にユーザインタフェース部１１０２がディスプレイ１３に表示させる画面である。アップデート画面Ｇ４には、アップデート処理部１１０７より通知されたアップデートの進行状況を表示するアップデートステータスウインドウＧ４１と、アップデートの中止を指示するための操作ボタンＧ４２とが表示される。ユーザは、アップデートステータスウインドウＧ４１の表示内容により、アップデートの進行状況を確認できる。
【００８８】
なお、この他、アップデート画面Ｇ４に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するように構成してもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。
【００８９】
次いで、アップデート処理部１１０７は、エラーの発生の有無を判定し（ステップＳ１４０７）、エラーの発生がある場合（ステップＳ１４０７：Ｙｅｓ）はステップＳ１４０１〜Ｓ１４１０の処理を抜けてステップＳ１４１２へ処理を進める。このＳ１４０７では、アップデート実行中に何らかの要因で発生するエラー（例えば、Ｓ１４０３におけるチェックサムの相違）の場合にもエラーとして判定される。
【００９０】
ステップＳ１４０７でエラーの発生がない場合には（ステップＳ１４０７：Ｎｏ）、アップデート処理部１１０７は、メタデータに含まれる、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されているか否かを判断することにより、再起動が必要であるか否かを判定する（ステップＳ１４０８）。
【００９１】
ここで、本実施の形態では、メタデータの“ｒｅｂｏｏｔ”は、実施したアップデートに次のアップデートを行う前に、再起動が必要か否かを示すものとなっている。図１４に示すアップデート処理では、ステップＳ１４０１からＳ１４１０までの処理で１回のアップデートを行い、複数のバージョンのアップデートを行う場合には、ステップＳ１４０１からＳ１４１０までの処理をアップデートのバージョン数だけ繰り返すことになっている。このため、本実施の形態では、ステップＳ１４０１からＳ１４１０までの処理の１回のループの最後に、メタデータに含まれる“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されているか否かを判断して、再起動の要否判断（ステップＳ１４０８）を行い、１回のアップデートごとに再起動を行っている。
【００９２】
そして、“ｒｅｂｏｏｔ”に“ｔｒｕｅ”が設定されており再起動が必要である場合には（ステップＳ１４０８：Ｙｅｓ）、通話端末１１の再起動を行う（ステップＳ１４０９）。
【００９３】
そして、アップデート処理部１１０７は、全てのバージョンのアップデートが完了したか否かを判定する（ステップＳ１４１０）。全てのバージョンのアップデートが完了していない場合（ステップＳ１４１０：Ｎｏ）には、Ｓ１４０１へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合（ステップＳ１４１０：Ｙｅｅｓ）には、アップデート処理部１１０７は、通話端末１１の記憶部１０５の設定情報に設定されているプログラム１０４の端末バージョンをアップデートを行った最新バージョンに更新する（ステップＳ１４１１）。なお、ＯＳがマイクロソフト（Ｒ）社のＷｉｎｄｏｗｓ（登録商標）である場合には、アップデート処理部１１０７は、レジストリに設定されいるプログラム１０４の端末バージョンを最新バージョンに更新する。
【００９４】
次に、アップデート処理部１１０７は、Ｓ１４０１〜Ｓ１４１０によるアップデートの結果をユーザインタフェース部１１０２へ通知する（ステップＳ１４１２）。ユーザインタフェース部１１０２では、通知されたアップデートの結果をディスプレイ１３に画面表示してユーザに通知する。
【００９５】
通常アップデートの結果は図１７の画面が表示される。一方、強制アップデートの結果は、図１８に示す強制アップデート結果画面Ｇ８０が表示される。
【００９６】
図１７は、通常アップデートの場合の確認画面Ｇ５の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部１１０２は、図１７に示すように、Ｓ１４０１〜Ｓ１４１０によるアップデート結果Ｇ５１や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンＧ５２、Ｇ５３を確認画面Ｇ５に表示する。アップデート結果Ｇ５１には、アップデート前のバージョンにかかる情報の他、Ｓ１４０１〜Ｓ１４１０のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果Ｇ５１の表示内容により、ユーザは、アップデートの結果を確認できる。
【００９７】
図１８は、強制アップデート結果画面Ｇ８０の一例を示す概念図である。強制アップデート結果画面Ｇ８０では、通常アップデート時の確認画面Ｇ５と同様に、シャットダウンボタンＧ８４と再起動ボタンＧ８５とが表示され、ユーザはいずれかのボタンを押下可能である。
【００９８】
アップデート処理部１１０７は、アップデートの結果をユーザインタフェース部１１０２へ通知したらアップデート処理を終了する（ステップＳ１４１３）。
【００９９】
このように本実施の形態では、アップデートに依存するバージョンのアップデートが存在する場合には、この依存バージョンが通信端末１１のプログラム１０４の現在のバージョンである端末バージョンより新しいか否かを判断し、新しい場合には、依存バージョンのアップデートのメタデータをネットワークを介してアップデートサーバ６０に要求して取得し、かつ依存バージョンのアップデートのデータファイルをアップデートサーバ６０からネットワークを介して取得する。一方、依存バージョンが端末バージョンと等しいか、端末バージョンより古い場合には、依存バージョンのアップデートのメタデータの要求を行わず、従って依存バージョンのアップデートの取得も行わない。
【０１００】
従って、本実施の形態によれば、プログラム１０４のアップデートに１または複数の依存バージョンのアップデートがある場合でも、端末バージョンに応じて、ネットワーク帯域の利用を低減してネットワーク負荷を軽減することができるとともに、アップデートの処理を短時間で簡易に行うことができるという効果を奏する。
【０１０１】
また、本実施の形態では、通話端末１１に実行するアップデートがある場合において、そのアップデートの実行をユーザが選択することができるので、これによりユーザの利便性を図ることができる。
【０１０２】
また、本実施の形態では、通話端末１１が強制アップデートを実施しなければならない場合には、ユーザにキャンセルさせる選択を与えずに、強制アップデートを実行するので、中継装置３０等、通話端末１１側以外のアップデートにより通話端末１１本来の機能の実行が不可能になることを回避することができる。
【０１０３】
なお、本実施の形態では、遠隔通信管理サーバ５０とアップデートサーバ６０とを別個の構成とした例を示しているが、これに限定されるものではない。例えば、サーバ装置を設け、当該サーバ装置が遠隔通信管理サーバ５０の機能とアップデートサーバ６０の機能とを備えた構成としてもよい。
【０１０４】
なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１０５】
１ 遠隔通信システム
２ 通信ネットワーク
１１，１４１１ 通話端末
１２ カメラ
１３ ディスプレイ
１４ マイク
１５ スピーカ
３０ 中継装置
５０ 遠隔通信管理サーバ
６０ アップデートサーバ
６０１ 送受信部
６０２ アップデートデータ提供部
１１０１ 送受信部
１１０２ ユーザインタフェース部
１１０３ アップデート部
１１０４ ユーザ通知部
１１０５ 操作入力受付部
１１０６ 判断部
１１０７ アップデート処理部
Ｇ１ 起動画面
Ｇ２ 設定画面
Ｇ３ 確認画面
Ｇ４ アップデート画面
Ｇ５，Ｇ７０ 確認画面
Ｇ８０ 強制アップデート結果画面
【先行技術文献】
【特許文献】
【０１０６】
【特許文献１】米国特許７，８９０，９８９号公報
【特許請求の範囲】
【請求項１】
通信装置であって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第１受信部と、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第２受信部と、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、
を備えたことを特徴とする通信装置。
【請求項２】
前記第２受信部は、前記依存バージョンが前記装置バージョンより新しくない場合に、前記依存バージョンのメタ情報を受信しないこと、
を特徴とする請求項１に記載の通信装置。
【請求項３】
前記判断部は、さらに、前記対象のアップデートの最新バージョンが前記装置バージョンより新しいか否かを判断し、前記最新バージョンが前記装置バージョンより新しい場合に、前記依存バージョンが前記装置バージョンより新しいか否かを判断すること、
を特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記アップデート処理部は、さらに、前記対象のアップデートの実行後に、前記装置バージョンを前記最新バージョンに更新して設定すること、
を特徴とする請求項３に記載の通信装置。
【請求項５】
前記メタ情報は、前記アップデートと前記アップデートの実行手順を示すスクリプトとを含むパッケージファイルの格納先が指定されており、
前記アップデート処理部は、前記メタ情報で指定された格納先から前記パッケージファイルを受信し、前記パッケージファイルの前記スクリプトを実行することにより、前記アップデートを実行すること、
を特徴とする請求項１〜４のいずれか一つに記載の通信装置。
【請求項６】
通信装置で実行されるアップデート方法であって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、
を含むアップデート方法。
【請求項７】
コンピュータに実行させるためのアップデートプログラムであって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、
を前記コンピュータに実行させるためのアップデートプログラム。
【請求項１】
通信装置であって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信する第１受信部と、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断する判断部と、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信する第２受信部と、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するアップデート処理部と、
を備えたことを特徴とする通信装置。
【請求項２】
前記第２受信部は、前記依存バージョンが前記装置バージョンより新しくない場合に、前記依存バージョンのメタ情報を受信しないこと、
を特徴とする請求項１に記載の通信装置。
【請求項３】
前記判断部は、さらに、前記対象のアップデートの最新バージョンが前記装置バージョンより新しいか否かを判断し、前記最新バージョンが前記装置バージョンより新しい場合に、前記依存バージョンが前記装置バージョンより新しいか否かを判断すること、
を特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記アップデート処理部は、さらに、前記対象のアップデートの実行後に、前記装置バージョンを前記最新バージョンに更新して設定すること、
を特徴とする請求項３に記載の通信装置。
【請求項５】
前記メタ情報は、前記アップデートと前記アップデートの実行手順を示すスクリプトとを含むパッケージファイルの格納先が指定されており、
前記アップデート処理部は、前記メタ情報で指定された格納先から前記パッケージファイルを受信し、前記パッケージファイルの前記スクリプトを実行することにより、前記アップデートを実行すること、
を特徴とする請求項１〜４のいずれか一つに記載の通信装置。
【請求項６】
通信装置で実行されるアップデート方法であって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記通信装置のプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記通信装置のアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、
を含むアップデート方法。
【請求項７】
コンピュータに実行させるためのアップデートプログラムであって、
アップデートにかかる情報を提供するアップデート情報提供装置から、前記コンピュータのプログラムに必要な対象のアップデートを示すメタ情報を受信するステップと、
前記メタ情報に、前記対象のアップデートに依存するアップデートのバージョンである依存バージョンの指定が含まれる場合に、前記依存バージョンが前記コンピュータのアップデートの現在のバージョンである装置バージョンより新しいか否かを判断するステップと、
前記依存バージョンが前記装置バージョンより新しい場合に、前記依存バージョンのアップデートを示すメタ情報を前記アップデート情報提供装置から受信するステップと、
前記依存バージョンのメタ情報に基づいて前記依存バージョンのアップデートを実行し、前記依存バージョンのアップデートの実行後、前記対象のアップデートのメタ情報に基づいて前記対象のアップデートを実行するステップと、
を前記コンピュータに実行させるためのアップデートプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１３−２０５０６（Ｐ２０１３−２０５０６Ａ）
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願番号】特願２０１１−１５４３１１（Ｐ２０１１−１５４３１１）
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]