JP2014178806A - サーバ装置、アップデートシステム、アップデート方法およびプログラム - Google Patents

Abstract

【課題】オンラインアップデートを行う際に、通信装置側でアップデートデータを格納できるだけの容量が不足している場合においてもアップデートを完了させること。
【解決手段】サーバ装置は、ネットワークに接続された通信装置に関する端末情報に基づいて、前記通信装置のアップデートのためのアップデートデータを分割するか否かを判断する判断部と、前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割部と、分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを、前記通信装置に送信する提供部と、を備えた。
【選択図】図４

Description

本発明は、サーバ装置、アップデートシステム、アップデート方法およびプログラムに関する。

インターネット等の通信ネットワークを介して遠隔地との間で、遠隔会議を行う会議システムが普及している。この会議システムにおいては、遠隔会議を行う出席者等の当事者の一方がいる会議室において、遠隔会議システムの端末装置を用いて会議の当事者などの会議室の画像および発言などの音声を撮影および収集し、それをデジタルデータに変換して相手方の端末装置に送信し、相手方の会議室のディスプレイに表示およびスピーカにより音声出力して、実際の会議に近い状態で遠隔地間の会議を行う技術が従来から知られている。

この会議システムでは、通話秘匿性能や操作性能を向上させるため、ファームウェア（プログラム）のアップデートが定期的に行われることがある。この会議システムにおけるプログラムのアップデートは、アップデートデータとメタ情報を、ネットワークを介してサーバへアクセスして取得し、プログラム及び当該プログラムに依存するバージョンのプログラムをアップデートする方法が従来から知られている。

例えば、特許文献１には、アップデート提供装置とアップデートデータを受信する端末装置において、受信端末に実行するアップデートがある場合に、そのアップデートの実行をユーザが選択可能として、ユーザの利便性を図ることができるアップデート方法が開示されている。

しかしながら、これらのオンラインアップデートに関する従来技術では、アップデートデータをサーバから受信する端末に、データを格納するだけの十分な空き容量がない場合、データのダウンロードを完了することができず、プログラムのアップデートを実行することができないという問題がある。

本発明は、上記に鑑みてなされたものであって、オンラインアップデートを行う際に、通信装置側でアップデートデータを格納できるだけの容量が不足している場合においてもアップデートを完了させることができるサーバ装置、アップデートシステム、アップデート方法およびプログラムを提供することを主な目的とする。

上述した課題を解決し、目的を達成するために、本発明にかかるサーバ装置は、ネットワークに接続された通信装置に関する端末情報に基づいて、前記通信装置のアップデートのためのアップデートデータを分割するか否かを判断する判断部と、前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割部と、分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを、前記通信装置に送信する提供部と、を備えた。

本発明によれば、オンラインアップデートを行う際に、通信装置側でアップデートデータを格納できるだけの容量が不足している場合においてもアップデートを完了させることができるという効果を奏する。

図１は、遠隔通信システムの構成を例示する模式図である。 図２は、通信端末のハードウエア構成を例示するブロック図である。 図３は、中継装置、遠隔通信管理サーバ、アップデートサーバのハードウエア構成を例示するブロック図である。 図４は、実施の形態１の通信端末及びアップデートサーバの機能構成を例示するブロック図である。 図５は、端末ＤＢの一例を示す図である。 図６は、実施の形態１の分割処理の流れを示すラダーチャートである。 図７は、メタデータの一例を示す概念図である。 図８は、アップデートデータの分割とメタデータとについて説明するための図である。 図９は、実施の形態１の通信端末の動作の一例を示すラダーチャートである。 図１０は、起動画面の一例を示す概念図である。 図１１は、設定画面の一例を示す概念図である。 図１２は、実施の形態１の確認画面の一例を示す概念図である。 図１３は、実施の形態１の確認ウインドウの一例を示す概念図である。 図１４は、実施の形態１のアップデート処理の一例を示すフローチャートである。 図１５は、アップデート画面の一例を示す概念図である。 図１６は、実施の形態１の確認画面の一例を示す概念図である。 図１７は、実施の形態２の分割処理の流れを示すラダーチャートである。

以下に添付図面を参照して、サーバ装置、アップデートシステム、アップデート方法およびプログラムの一実施形態を詳細に説明する。

（実施の形態１）
図１は、実施の形態１の遠隔通信システム１の構成を例示する模式図である。図１に示すように、遠隔通信システム１は、通信ネットワーク２により通信装置としての通信端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、遠隔通信管理サーバ５０、アップデートサーバ６０及びルータ７０ａ〜７０ｄが通信可能に接続されるシステムである。具体的には、遠隔通信システム１は、インターネット２ｉにルータ７０ａ〜７０ｄを介して接続するＬＡＮ２ａ、２ｂ、２ｃ、２ｄ、遠隔通信管理サーバ５０及びアップデートサーバ６０と、ＬＡＮ２ａに接続する通信端末１１ａａ〜１１ａｃ及び中継装置３０ａと、ＬＡＮ２ｂに接続する通信端末１１ｂａ〜１１ｂｃ及び中継装置３０ｂと、ＬＡＮ２ｃに接続する通信端末１１ｃａ〜１１ｃｃ及び中継装置３０ｃと、ＬＡＮ２ｄに接続する通信端末１１ｄａ〜１１ｄｃ及び中継装置３０ｄとを有する構成である。遠隔通信システム１では、遠隔通信管理サーバ５０の管理の下、地域Ａの通信端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、地域Ｂの通信端末１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃの各々が、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄによる通信データの中継を介して、互いに音声又は映像を送受信することで通話を行う。

具体的には、遠隔通信管理サーバ５０は、通信端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄなどの通信アドレス、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄの各々が中継を行う通信端末、各通信端末の通話状態などの情報を管理する。例えば、通信端末１１ａａが通信端末１１ｃａと通話を行う場合は、中継装置３０ａに通信端末１１ｃａへの通話の中継を依頼する。中継装置３０ａは、遠隔通信管理サーバ５０に通信端末１１ａａの通話の開始を通知するとともに、通信端末１１ｃａへ通話を中継するための中継装置３０ｃの通信アドレスを遠隔通信管理サーバ５０より取得する。次いで、中継装置３０ａは通信端末１１ｃａへ通話の中継を中継装置３０ｃに依頼し、中継装置３０ｃは、通信端末１１ｃａとの通信セッションを開始する。次いで、中継装置３０ｃは、通信端末１１ｃａとの通信セッションの開始を遠隔通信管理サーバ５０へ通知する。

これにより、中継装置３０ａ、３０ｃを介して、通信端末１１ａａ及び通信端末１１ｃａとの間の通話が開始される。また、遠隔通信管理サーバ５０は、通信端末１１ａａ及び通信端末１１ｃａが通話中であることを管理する。例えば、遠隔通信管理サーバ５０は、通信端末１１ａｂから通信端末１１ａａや通信端末１１ｃａなどの通話状態の問い合わせがあった場合は、オンラインであるが互いに通話中であることを返信する。

なお、以下の説明において、同種の装置の中の任意の装置について説明を行う場合は、数字の後の英数字を略した符号を用いるものとする。例えば、通信端末１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃは通信端末１１と略すものとする。また、中継装置３０ａ〜３０ｄは中継装置３０と略すものとする。

アップデートサーバ６０は、通信端末１１のプログラムや各種設定情報のアップデートにかかる情報を管理し、通信端末１１の要求に応じてその情報を提供するアップデート情報提供装置である。アップデートにかかる情報としては、通信端末１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータ（メタ情報）などである。アップデートにかかる情報として全てのバージョンのデータをアップデートサーバ６０が管理する理由は、通信端末１１がアップデートを行うタイミングが各々異なるためである。また、アップデートサーバ６０は、通信端末１１の端末情報に基づいて、アップデートデータの分割の要否の判断、および分割が必要な場合、アップデートデータの分割を行う。

例えば、頻繁にアップデートを行っている通信端末１１は、最新のバージョンへのアップデートを行うだけでよいかもしれないが、アップデートの間隔が長い通信端末１１は、何回かバージョンアップが繰り返された後にアップデートを行うかもしれない。このような場合は、直に最新のバージョンへアップデートせずに、最新のバージョンと依存関係のある古いバージョンへのアップデートを経ることがある。このように、依存関係のある古いバージョンへのアップデートを経る通信端末１１もあることから、アップデートサーバ６０は、アップデートにかかる情報として全てのバージョンのデータを管理している。

ここで、アップデートの種類には、通常アップデートと強制アップデートの２種類がある。通常アップデートは、バグ等の障害対応や機能追加を目的として実施されるアップデートである。

強制アップデートは、通信端末１１そのものの機能とは異なる装置、機能の変更に伴って、強制的に行うことを目的としたアップデートである。例えば、中継装置３０側において、通話の際に送受信する音声や画像のデータフォーマットやビデオコーデックが変更されたり、エンコーダのアップデート等の映像に関する中継装置３０のバージョンアップが実施される場合がある。また、中継装置３０との通信プロトコルが変更される場合もある。このような変更は、音声や画像、映像そのものの構造が変わり、あるいは通信プロトコルの変更に伴う中継装置３０との通信手順そのものが変わり、もしくは中継装置３０側の機能が変わるため、アップデート前の通信端末１１では、通信端末１１の本来の機能である通話を実現することができない。このため、このような場合には、中継装置３０のアップデート後のバージョンに適合させるために強制アップデートを行う。

また、中継装置３０側でセキュリティホールが発見された場合等、セキュリティ面で問題がある等に、これを回避するようなセキュリティホール対応のアップデートを中継装置３０側で行う場合がある。このような場合にも、アップデート前の通信端末１１では通話すら実行できないことになるため、中継装置３０側のセキュリティホール対応に適合させるために強制アップデートが実施される。

次に、通信端末１１のハードウエア構成を説明する。図２は、通信端末１１のハードウエア構成を例示するブロック図である。図２に示すように、通信端末１１は、ＣＰＵ１０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ１０２（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ１０３（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、記憶部１０５、メディアドライブ１０７、操作部１０８、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３及びディスプレイＩ／Ｆ１１４を備え、各部がバス１１０により互いに接続される構成である。

ＣＰＵ１０１は、ＲＯＭ１０２や記憶部１０５に記憶されたプログラム１０４をＲＡＭ１０３に展開して順次実行することで、通信端末１１の動作を中央制御する。記憶部１０５は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などであり、読み出し／書き込み可能にデータを記憶する。具体的には、記憶部１０５は、ＣＰＵ１０１が実行するためのプログラム１０４や各種設定情報を記憶する。アップデートの際には、この記憶部１０５に記憶されるプログラム１０４や各種設定情報が更新される。

メディアドライブ１０７は、光ディスクなどのメディア１０６の読み出し／書き込みを行うドライブ装置である。操作部１０８は、キーボード、各種操作キー、ディスプレイ１３上に積層配置されたタッチパネル等であり、ユーザの操作入力を受け付ける。ネットワークＩ／Ｆ１１１は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。撮像素子Ｉ／Ｆ１１２は、デジタルカメラであるカメラ１２と接続し、カメラ１２が撮像した画像を取得するためのインタフェースである。音声入出力Ｉ／Ｆ１１３は、マイク１４、スピーカ１５と接続し、マイク１４による音声入力や、スピーカ１５を介した音声出力を行うインタフェースである。ディスプレイＩ／Ｆ１１４は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などであるディスプレイ１３と接続し、ディスプレイ１３へ表示データを出力するインタフェースである。

なお、本実施の形態では、ディスプレイ１３を用いているが、ディスプレイ１３に代えて、プロジェクタ等、他の表示機器を接続する構成としてもよい。

通信端末１１は、プログラム１０４を実行したＣＰＵ１０１の制御の下、例えば他の通信端末との通話時には、カメラ１２から取得した画像やマイク１４から入力された音声をネットワークＩ／Ｆ１１１を介して中継装置３０へ出力する。また、中継装置３０より中継され、ネットワークＩ／Ｆ１１１を介して入力された他の通信端末からの音声をスピーカ１５より出力し、同様に他の通信端末からの画像をディスプレイ１３により表示する。これにより、通信端末１１は、画像及び音声による他の通信端末との通話、いわゆるテレビ会議を実現する。

次に、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を説明する。図３は、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウエア構成を例示するブロック図である。図３に示すように、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶部２０４、ディスプレイ２０５、ネットワークＩ／Ｆ２０６、キーボード２０７、マウス２０８、メディアドライブ２０９及びＣＤ−ＲＯＭドライブ２１１を備え、各部がバス２１４により互いに接続される構成である。中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、いわゆるＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やＷＳ（Ｗｏｒｋ Ｓｔａｔｉｏｎ）などの機器である。

ＣＰＵ２０１は、ＲＯＭ２０２や記憶部２０４に記憶されたプログラムをＲＡＭ２０３に展開して順次実行することで、自装置の動作を中央制御する。記憶部２０４は、ＨＤＤやＳＳＤなどであり、読み出し／書き込み可能にデータを記憶する。例えば、アップデートサーバ６０では、アップデートにかかる情報などが記憶部２０４に記憶されている。

ディスプレイ２０５は、例えばＬＣＤなどである。ネットワークＩ／Ｆ２０６は、通信ネットワーク２と接続してデータ通信を行うインタフェースである。キーボード２０７、マウス２０８は、ユーザの操作入力を受け付ける。メディアドライブ２０９は、光ディスクなどのメディア２１０の読み出し／書き込みを行うドライブ装置である。ＣＤ−ＲＯＭドライブ２１１は、ＣＤ−ＲＯＭ２１３の読み出しを行うドライブ装置である。例えば、アップデートサーバ６０では、メディア２１０やＣＤ−ＲＯＭ２１３によりアップデートにかかる最新の情報が提供され、記憶部２０４に記憶される。

次に、ＣＰＵ１０１やＣＰＵ２０１がプログラムを実行することで実現される、通信端末１１及びアップデートサーバ６０の機能構成について説明する。図４は、実施の形態１の通信端末１１及びアップデートサーバ６０の機能構成を例示するブロック図である。

まず、通信端末１１の機能的構成について説明する。通信端末１１は、図４に示すように、送受信部１１０１と、ユーザインタフェース部１１０２と、アップデート部１１０３とを主に有している。

送受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う。具体的には、送受信部１１０１は、記憶部１０５の設定情報などに予め設定されているアップデートサーバ６０の通信アドレスや遠隔通信管理サーバ５０へ問い合わせて取得したアップデートサーバ６０の通信アドレスをもとに、アップデートサーバ６０との間で所定の通信プロトコルを用いた通信セッションを開始することで、アップデートサーバ６０との間でデータの送受信を行う。このデータの送受信により、送受信部１１０１は、アップデートサーバ６０が管理しているアップデートにかかる情報を取得する。具体的には、送受信部１１０１は、メタデータの送信要求をアップデートサーバ６０に送信し、アップデートサーバ６０からアップデートに関するメタデータ、アップデートデータを受信する。

ユーザインタフェース部（ＵＩ部）１１０２は、スピーカ１５による音声出力、ディスプレイ１３の表示画面、操作部１０８によるユーザの操作入力の受け付けなどを制御して、ユーザと通信端末１１との間の情報伝達を制御するインタフェースである。具体的には、ユーザインタフェース部１１０２は、スピーカ１５による音声出力やディスプレイ１３の表示画面でユーザへの各種通知を行うユーザ通知部１１０４と、操作部１０８によるユーザの操作入力を受け付ける操作入力受付部１１０５とを有する。

アップデート部１１０３は、判断部およびアップデート処理部として機能し、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報をもとに、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデートを実行する。アップデート部１１０３が実行するアップデートについては、アップデート処理（ステップＳ３６）にて詳細に説明する。

次に、アップデートサーバ６０の機能的構成について説明する。アップデートサーバ６０は、図４に示すように、送受信部６０１と、アップデートデータ提供部６０２と、アップデートデータ分割部６０３と、分割判断部６０４と、端末データベース６１０（以下、「端末ＤＢ６１０」という。）とを主に有している。

送受信部６０１は、通信ネットワーク２を介して通信端末１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した通信端末１１の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通信端末１１との間でデータの送受信を行う。

端末ＤＢ６１０は、通信端末１１ごとに、通信端末１１に関する端末情報を記憶するＨＤＤ（ハードディスクドライブ）やメモリ等の記憶媒体である。図５は、端末ＤＢ６１０の一例を示す図である。図５に示すように、端末ＤＢ６１０には端末情報が登録されており、端末情報は、通信端末１１の機種名と通信端末１１が受信可能なサイズとが対応付けられている。受信可能なサイズとは、通信端末１１が有する記憶部１０５の記憶容量である。

分割判断部６０４は、端末ＤＢ６１０の端末情報の機種名に基づいて、通信端末１１のアップデートデータを分割するか否かを判断する。具体的には、分割判断部６０４は、端末ＤＢ６１０において、メタデータの送信要求を行った通信端末１１の機種名に対応する受信可能なサイズとアップデートデータのサイズとに基づいて、アップデートデータを分割するか否かを判断する。

例えば、アップデートデータのサイズが３００ＭＢの場合、図５の端末ＤＢ６１０において、機種Ａおよび機種Ｂの通信端末１１の受信可能サイズは３００ＭＢより大きいため、分割判断部６０４はアップデートデータの分割は不要と判断する。一方、図５の端末ＤＢ６１０において、機種Ｃの通信端末１１の受信可能サイズは３００ＭＢより小さいため、分割判断部６０４はアップデートデータの分割が必要と判断する。

アップデートデータ分割部６０３は、分割判断部６０４によって、アップデートデータを分割すると判断された場合に、アップデートデータを分割し、さらに分割されたアップデートデータに基づくメタデータを生成する。

例えば、アップデートデータのサイズが３００ＭＢの場合、図５の端末ＤＢ６１０において、機種Ｃの通信端末１１からメタデータの送信要求があった場合には、アップデートデータ分割部６０３は、アップデートデータを２５０ＭＢ以下のサイズに分割する。

アップデートデータ提供部６０２は、送受信部６０１を介して、通信端末１１からメタデータの送信要求を受信する。また、アップデートデータ提供部６０２は、送受信部６０１を介して通信端末１１からメタデータの送信要求を受信した場合には、通信端末１１からの要求に応じて、アップデートサーバ６０が管理しているアップデートにかかる情報、すなわちメタデータを通信端末１１に提供する。また、アップデートデータ提供部６０２は、アップデートデータ（分割されたアップデートデータも含む）を通信端末１１に送信する。

次に、アップデートサーバ６０で実行される処理について説明する。図６は、実施の形態１のアップデートサーバ６０で実行される分割処理の流れを示すラダーチャートである。

まず、アップデートデータ提供部６０２が、送受信部６０１を介して、通信端末１１からメタデータの送信要求を受信すると（ステップＳ１１）、分割判断部６０４は、端末ＤＢ６１０において、メタデータの送信要求を送信した通信端末１１の機種名に基づいてアップデートデータを分割するか否かを判断する（ステップＳ１２）。具体的には、上述のように、分割判断部６０４は、アップデートデータのサイズと、機種名に対応する受信可能サイズとから分割の要否を判断する。

そして、分割が不要と判断された場合には（ステップＳ１３：Ｎｏ）、アップデートデータ提供部６０２は、アップデートサーバ６０が管理しているメタデータを、送信要求のあった通信端末１１に送信する（ステップＳ１６）。

一方、ステップＳ１３において、分割が必要と判断された場合には（ステップＳ１３：Ｙｅｓ）、アップデートデータ分割部６０３は、機種名に基づいてアップデートデータを分割し、分割されたアップデートデータに基づくメタデータを生成する（ステップＳ１５）。ここで、アップデートデータは、複数の画像ファイルやプログラムのオブジェクトファイル、設定ファイルなどの集合であるため、アップデートデータ分割部６０３は、アップデートデータを、ファイル容量の最小単位まで分割可能である。

そして、アップデートデータ提供部６０２は、ステップＳ１５で生成されたメタデータを、送信要求のあった通信端末１１に送信する（ステップＳ１６）。

ここで、メタデータの詳細について説明する。図７は、メタデータの一例を示す概念図である。図７に示すように、各バージョンのメタデータは、“ｖｅｒｓｉｏｎ”、“ｄｅｐｅｎｄｅｎｃｙ”、“ｄｅｓｃｒｉｐｔｉｏｎ”、“ｆｉｌｅｓ”、“ｓｃｒｉｐｔｎａｍｅ”、“ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ”、“ｆｏｒｃｅ＿ｕｐｄａｔｅ”などのデータ項目を含む構成である。

“ｖｅｒｓｉｏｎ”には、“１．０．１”などのバージョン番号が記述される。“ｄｅｐｅｎｄｅｎｃｙ”には、“１．０．０”などの、互いに依存関係を有する他のバージョンを示すバージョン番号が記述される。したがって、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に記述されたバージョン番号を確認することで、依存関係にあるバージョンへと遡ることが可能である。

“ｄｅｓｃｒｉｐｔｉｏｎ”には、“Ｉｔ ｉｓ ｓａｍｐｌｅ ｄａｔａ．”などのバージョンの詳細が記述される。“ｆｉｌｅｓ”には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）のリストとその格納先や、それらデータファイルのチェックサムなどが記述される。

したがって、アップデート部１１０３は、“ｆｉｌｅｓ”のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。

“ｓｃｒｉｐｔｎａｍｅ”には、アップデートを実行する際に実行するスクリプト名が記述される。“ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ”には、アップデートを実行した後に、装置の再起動を行うか否かを示すフラグ（“ｔｒｕｅ”又は“ｆａｌｓｅ”）が記述される。“ｆｏｒｃｅ＿ｕｐｄａｔｅ”には、強制のアップデートであるか否かを示すフラグ（“ｔｒｕｅ”又は“ｆａｌｓｅ”）が記述される。

プログラム１０４のアップデートには、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３、ディスプレイＩ／Ｆ１１４等のデバイス制御にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ”に“ｔｒｕｅ”が記述される。また、プログラム１０４のアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“ｆｏｒｃｅ＿ｕｐｄａｔｅ”に“ｔｒｕｅ”が記述される。

次に、アップデートデータを分割する場合におけるメタデータの内容について説明する。図８は、アップデートデータの分割とメタデータとについて説明するための図である。アップデートデータ分割部６０３がアップデートデータを分割する場合、分割後のアップデートデータに対して新たなバージョン番号を、分割元のアップデートデータのバージョン番号の桁数を１つ増やした番号で生成して付与し、新たなバージョンをメタデータの“ｖｅｒｓｉｏｎ”に記述する。例えば、図８に示すように、分割元のアップデートデータのバージョン番号が”２．２”の場合で、アップデートデータ分割部６０３がこのアップデートデータを２つに分割する場合には、１番目のアップデートデータのバージョン番号を“２．２．０”とし、２番目のアップデートデータのバージョン番号を“２．２．１”としてそれぞれ付与し、“ｖｅｒｓｉｏｎ”に記述する。

また、アップデートデータ分割部６０３は、メタデータにおいて、依存関係を示す“ｄｅｐｅｎｄｅｎｃｙ”については以下のように記述する。アップデートデータ分割部６０３は、分割した１番目のアップデートデータの“ｄｅｐｅｎｄｅｎｃｙ”には、分割元のアップデートデータの依存先のバージョン番号を記述し、分割したｎ番目のアップデートデータの“ｄｅｐｅｎｄｅｎｃｙ”には、分割した（ｎ−１）番目のアップデートデータのバージョン番号を記述する。

図８の例では、アップデートデータ分割部６０３は、バージョン番号“２．１”に依存するバージョン番号“２．２”であるアップデートデータを、バージョン番号“２．２．０”と“２．２．１”の２つのアップデートデータに分割している。この場合において、アップデートデータ分割部６０３は、バージョン番号“２．２．０”のアップデートデータ（１番目のアップデートデータ）の“ｄｅｐｅｎｄｅｎｃｙ”を“２．１”と記述し、バージョン番号“２．２．１”のアップデートデータ（２番目のアップデートデータ）の“ｄｅｐｅｎｄｅｎｃｙ”を“２．２．０”と記述してメタデータを生成している。

なお、図８の例では、アップデートデータを２つに分割する例を示しているが、１つ当たりのアップデートデータが端末ＤＢ６１０における機種名に対応する受信可能サイズに収まるように分割数を決定して分割すれば、任意の数に分割することができる。

次に、通信端末１１の動作の詳細を説明する。図９は、実施の形態１の通信端末１１の動作の一例を示すラダーチャートである。

図９に示すように、ユーザインタフェース部１１０２は、操作部１０８の電源スイッチなどの操作に応じて自装置の電源投入（電源オン）を行い（ステップＳ２１）、起動画面をディスプレイ１３に表示させる（ステップＳ２２）。この起動画面は、ＣＰＵ１０１の制御の下で遠隔通信管理サーバ５０へ問い合わせて得られた各通信端末１１の通話状態を一覧表示した表示画面である（詳細は後述する）。

アップデート部１１０３は、Ｓ２１による電源投入後の起動時において、自装置のアップデートの確認を開始する（ステップＳ２３）。なお、以下の説明では、プログラムのアップデートを例示するが、各種設定情報のアップデートも同様にして行われることは言うまでもないことである。

アップデートの確認が開始されると、アップデート部１１０３は、送受信部１１０１によって、最新バージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ２４）、その要求に対応してアップデートデータ提供部６０２が提供するメタデータを取得する（ステップＳ２５）。

次いで、アップデート部１１０３は、取得したメタデータの“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に記述された内容をもとに、依存するバージョンの有無を確認する（ステップＳ２６）。例えば、図７に示すように、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に“１．０．０”などの他のバージョンを示すバージョン番号が記述されている場合には、依存するバージョンがあるものとする。また、“ｄｅｐｅｎｄｅｎｃｙ”のデータ項目に何も記述がない場合には、依存するバージョンがないものとする。なお、この依存するバージョンは、図８を用いて上述したとおり、分割されたアップデートデータも含まれる。

次いで、アップデート部１１０３は、Ｓ２６による確認の結果、依存するバージョンが有るか否かを判定する（ステップＳ２７）。依存するバージョンがある場合（ステップＳ７：ＹＥＳ）、アップデート部１１０３は、送受信部１１０１によって、依存するバージョンのプログラムのメタデータをアップデートサーバ６０に対して要求し（ステップＳ２８）、その要求に対応してアップデートデータ提供部６０２が提供する、依存するバージョンのメタデータを取得して（ステップＳ２９）、Ｓ２６へ処理を戻す。したがって、アップデート部１１０３は、最新バージョンに対して依存するバージョンを順次遡って、それらのバージョンにかかるメタデータを取得する。また、アップデートデータが分割されている場合には、ステップＳ２８、Ｓ２９の処理を繰り返すことによって、アップデート部１１０３は、分割後のすべてのアップデートデータに対するメタデータを取得することができる。

次いで、アップデート部１１０３は最新バージョンのメタデータの“ｖｅｒｓｉｏｎ”に記述されたバージョン番号と、自装置の記憶部１０５に記憶されたプログラム１０４のバージョン番号とを比較することで、自装置のアップデートが存在するか否か（すなわち、アップデート済みか否か）を判定する（ステップＳ３０）。具体的には、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致する場合は、プログラム１０４が最新バージョンであることから、自装置に必要なアップデートが存在しない（すなわち、アップデート済み）と判定する。また、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、自装置に必要なアップデートが存在する（すなわち、アップデート済みでない）と判定する。自装置に必要なアップデートが存在しない場合（ステップＳ３０：ＮＯ）は、アップデートを実行する必要がないことから、通常の動作を継続させる（ステップＳ３９）。

自装置のアップデートが存在する場合（ステップＳ３０：ＹＥＳ）、アップデート部１１０３は、そのアップデートに関する情報をユーザインタフェース部１１０２へ通知する（ステップＳ３１）。具体的には、最新バージョン及びその最新バージョンに依存するバージョンのメタデータのうち、“ｆｉｌｅｓ”、“ｓｃｒｉｐｔｎａｍｅ”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデートに関する情報としてユーザインタフェース部１１０２へ通知する。

ユーザインタフェース部１１０２のユーザ通知部１１０４では、Ｓ３１においてアップデート部１１０３より通知されたアップデートに関する情報をもとに、自装置に必要なアップデートが存在することをディスプレイ１３の起動画面に表示して、ユーザへ通知する（ステップＳ３２）。

ここで、起動画面の詳細について説明する。図１０は、起動画面Ｇ１の一例を示す概念図である。図１０に示すように、起動画面Ｇ１は、各通信端末の通話状態を一覧表示する主画面Ｇ１１と、自装置のステータスを表示するステータス画面Ｇ１２とを含む構成である。ユーザ通知部１１０４は、アップデートに関する情報がアップデート部１１０３より通知された場合は、ステータス画面Ｇ１２にアップデートがある旨の表示を行うことで、ユーザへの通知を行う。なお、アップデートがある旨の表示は、予め設定されたアイコン画像を主画面Ｇ１１に表示してもよく、図示したレイアウトに限定しない。なお、図面で例示している画面例（図１０〜１３、１５、１６等）において、中抜き又は黒塗りの四角で表された部分は、メッセージを表示する可能性のある領域を示しており、例えばシステム上で予め予約されたメッセージ表示領域などである。

また、ユーザ通知部１１０４は、アップデートに関する情報として含まれるデータ項目の中で“ｆｏｒｃｅ＿ｕｐｄａｔｅ”の記述が“ｔｒｕｅ”である場合は、自装置に存在するアップデートが強制のアップデートであることを起動画面Ｇ１に表示してユーザに通知する。具体的には、アップデートが強制のアップデートである旨をステータス画面Ｇ１２に表示してもよいし、主画面Ｇ１１に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。

Ｓ３２によるユーザへの通知によって、ユーザインタフェース部１１０２の操作入力受付部１１０５によりアップデートなどの各種設定を行うための操作指示が受け付けられた場合、ユーザインタフェース部１１０２は、設定画面をディスプレイ１３に表示させる（ステップＳ３３）。

図１１は、設定画面Ｇ２の一例を示す概念図である。図１１に示すように、設定画面Ｇ２は、操作入力受付部１１０５によりユーザの選択操作を受け付けて、各種設定を行うための設定ボタンＧ２３〜Ｇ２６を表示する主画面Ｇ２１を含む構成である。設定ボタンＧ２３〜Ｇ２６の中で設定ボタンＧ２６がアップデートの実行を指示するためのボタンである。この設定ボタンＧ２６は、アップデートに関する情報がアップデート部１１０３より通知されず、自装置にアップデートが存在しない場合には、グレーアウトするなどして、選択操作が無効とされている。

逆に、アップデートに関する情報がアップデート部１１０３より通知され、自装置にアップデートが存在する場合には、グレーアウトが解除され、操作入力受付部１１０５によるユーザの選択操作を受け付ける状態となる。この場合、設定ボタンＧ２６には、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとに、アップデートが行われる最新バージョンのバージョン番号などを記載してもよい。図示例では、バージョン番号が２．０の最新バージョンにアップデートすることが記載されている。なお、設定画面Ｇ２に、さらに、自装置のステータスを表示するステータス画面を表示するように構成してもよい。

ステップＳ３３において、設定ボタンＧ２６の選択操作が行われた場合、ユーザインタフェース部１１０２は、アップデートの実行を確認する確認画面をディスプレイ１３に表示させる（ステップＳ３４）。

図１２は、確認画面Ｇ３の一例を示す概念図である。図１２に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンＧ３５、Ｇ３４とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む構成である。

アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の“ｖｅｒｓｉｏｎ”の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、確認画面Ｇ３のアップデート表示Ｇ３３に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。

図１３は、確認ウインドウＧ３６の一例を示す概念図である。確認画面Ｇ３において、アップデートの実行を指示する操作ボタンＧ３５が選択された場合は、再度ユーザに確認を促す確認ウインドウＧ３６を表示してもよい。確認ウインドウＧ３６には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。この確認画面Ｇ３では、アップデートの実行が指示された場合に確認ウインドウＧ３６を表示することで、ユーザへの注意喚起を促すことができる。なお、確認ウィンドウ３６に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。

図９に戻り、アップデート部１１０３では、確認画面Ｇ３での操作ボタンＧ３４、Ｇ３５の選択操作をもとに、アップデートを実行するか否かを判定する（ステップＳ３５）。アップデートの実行を指示する操作ボタンＧ３５が選択された場合（ステップＳ３５：ＹＥＳ）、アップデート部１１０３は、取得しているメタデータをもとにアップデート処理を実行する（ステップＳ３６）。

アップデートの実行をキャンセルする操作ボタンＧ３４が選択されるなどして、操作ボタンＧ３５の選択が行われなかった場合（ステップＳ３５：ＮＯ）、アップデート部１１０３は、取得しているメタデータの“ｆｏｒｃｅ＿ｕｐｄａｔｅ”の記述をもとに、実行されなかったアップデートの中に強制のアップデートが含まれるか否かを判定する（ステップＳ３７）。強制のアップデートが含まれる場合（ステップＳ３７：ＹＥＳ）、アップデート部１１０３は、自装置の処理を終了させる終了処理を行い（ステップＳ３８）、装置の電源を落とす。このように、強制のアップデートが実行されない場合は、通話すら実行できないこととなるため、装置の電源を落として無駄な操作が行われることを未然に防止する。逆に、強制のアップデートが含まれない場合（ステップＳ３７：ＮＯ）、アップデート部１１０３は、現時点ではアップデートを実行しないことから、通常の動作を継続させる。これにより、ユーザは、アップデートよりも通話を優先することができる。

すなわち、通信端末１１では、自装置のアップデートが存在する場合には、そのアップデートの存在をユーザインタフェース部１１０２のユーザ通知部１１０４よりユーザに通知する。そして、通信端末１１では、操作入力受付部１１０５により、そのアップデートを実行するか否かの選択操作をユーザより受け付け、アップデートを実行する選択操作が行われた場合に、アップデート部１１０３によるアップデート処理が実行される。したがって、通信端末１１は、自装置に実行するアップデートがある場合の、そのアップデートの実行をユーザが選択可能となる。

ここで、アップデート処理（ステップＳ３６）の詳細について説明する。図１４は、アップデート処理の一例を示すフローチャートである。

図１４に示すように、アップデート部１１０３は、アップデート処理が開始されると（ステップＳ１００）、カメラ１２、マイク１４、スピーカ１５などの外部装置と接続するための撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３等のインタフェース部の機能を停止する。インタフェース部が稼働していると、そのインタフェース部にかかるプログラム１０４が使用中であるため、アップデートがエラーとなることがある。このエラーを未然に防止するため、アップデート部１１０３は、アップデート処理の開始に伴い、上述したインタフェース部の機能を停止する。

次いで、アップデート部１１０３は、取得したメタデータの“ｆｉｌｅｓ”からアップデートの実体となるプログラムのファイルリストと、それらファイルのチェックサムとを取得する（ステップＳ１０１）。なお、依存関係を有する複数のバージョンのメタデータを取得している場合には、バージョン番号が古いものから順にＳ１０１〜Ｓ１０６の処理が行われるものとする。

次いで、アップデート部１１０３は、Ｓ１０１で取得したファイルリストのファイルをアップデートサーバ６０から取得し（ステップＳ１０２）、取得したファイルのチェックサムを確認する（ステップＳ１０３）。次いで、アップデート部１１０３は、アップデートの進行状況をユーザインタフェース部１１０２に通知する（ステップＳ１０４）。この進行状況の通知は、ファイルリストに含まれる複数のファイルの中で、どのファイルまでＳ１０２、Ｓ１０３の処理を終えたかを通知する。また、依存関係を有する複数のバージョンのアップデートを行う場合には、どのバージョンのアップデートまでを終えたかを通知してもよい。ユーザインタフェース部１１０２では、通知されたアップデートの進行状況をディスプレイ１３に画面表示してユーザに通知する。

図１５は、アップデート画面Ｇ４の一例を示す概念図である。図１５に示すように、アップデート画面Ｇ４は、アップデート部１１０３によるアップデート処理中にユーザインタフェース部１１０２がディスプレイ１３に表示させる画面である。アップデート画面Ｇ４には、アップデート部１１０３より通知されたアップデートの進行状況を表示するアップデートステータスウインドウＧ４１と、アップデートの中止を指示するための操作ボタンＧ４２とが表示される。ユーザは、アップデートステータスウインドウＧ４１の表示内容により、アップデートの進行状況を確認できる。

なお、この他、アップデート画面Ｇ４に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するように構成してもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。

次いで、アップデート部１１０３は、エラーの発生の有無を判定し（ステップＳ１０５）、エラーの発生がある場合（ステップＳ１０５：ＹＥＳ）はＳ１０１〜Ｓ１０６の処理を抜けてＳ１０７へ処理を進める。このＳ１０５では、アップデート実行中に何らかの要因で発生するエラー（例えば、Ｓ１０３におけるチェックサムの相違）の他、アップデート画面Ｇ４の操作ボタンＧ４２の操作によるアップデートの中止や、Ｓ１０２、Ｓ１０３で行ったアップデートのバージョンが再起動を要する場合にもエラーとして判定される。したがって、バージョン番号が古いものから順にアップデートが行われる場合には、再起動を要するバージョンのアップデートまでが行われた段階で、Ｓ１０１〜Ｓ１０６の処理を抜けることとなる。

エラーの発生がない場合（ステップＳ１０５：ＮＯ）、アップデート部１１０３は、取得したメタデータにかかる、全てのバージョンのアップデートが完了したか否かを判定する（ステップＳ１０６）。全てのバージョンのアップデートが完了していない場合（ステップＳ１０６：ＮＯ）には、Ｓ１０１へ戻り、アップデート処理を継続する。全てのバージョンのアップデートが完了した場合（ステップＳ１０６：ＹＥＳ）には、Ｓ１０１〜Ｓ１０６の処理を抜け、Ｓ１０７へ処理を進める。

Ｓ１０７において、アップデート部１１０３は、Ｓ１０６〜Ｓ１０７によるアップデートの結果をユーザインタフェース部１１０２へ通知する。ユーザインタフェース部１１０２では、通知されたアップデートの結果をディスプレイ１３に画面表示してユーザに通知する。

図１６は、確認画面Ｇ５の一例を示す概念図である。アップデートの結果を受けたユーザインタフェース部１１０２は、図１６に示すように、Ｓ１０６〜Ｓ１０７によるアップデート結果Ｇ５１や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンＧ５２、Ｇ５３を確認画面Ｇ５に表示する。アップデート結果Ｇ５１には、アップデート前のバージョンにかかる情報の他、Ｓ１０６〜Ｓ１０７のアップデートによる現在のバージョンにかかる情報などが表示される。このアップデート結果Ｇ５１の表示内容により、ユーザは、アップデートの結果を確認できる。

次いで、アップデート部１１０３は、Ｓ１０１〜Ｓ１０６でアップデートを行った際のメタデータに含まれる、“ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ”の記述をもとに、再起動が必要であるか否かを判定する（ステップＳ１０８）。再起動が必要でない場合（ステップＳ１０８：ＮＯ）、アップデート部１１０３は、再起動することなくアップデート処理を終了する（ステップＳ１０９）。再起動が必要である場合（ステップＳ１０８：ＹＥＳ）、アップデート部１１０３は、自装置を再起動させて処理を終了する（ステップＳ１１０）。このように、再起動が必要なアップデートが実行された場合は、ユーザが操作することなく、アップデート後に再起動されることとなる。

このように本実施の形態では、アップデートサーバ６０は、メタデータの送信要求を行った通信端末１１の機種名、記憶容量を含む端末情報に基づいて、アップデートデータを分割するか否か判断して、分割が必要な場合、端末情報に基づいてアップデートデータを分割しているので、オンラインアップデートを行う際に、通信端末１１側でアップデートデータを格納できるだけの容量が不足している場合においてもアップデートを完了させることができる。

また、本実施の形態では、通信端末１１にに実行するアップデートがある場合において、そのアップデートの実行をユーザが選択することができるので、これによりユーザの利便性を図ることができる。

（実施の形態２）
実施の形態１では、予め端末ＤＢ６１０に通信端末１１の機種名と記憶容量とを対応付けた端末情報を保存しておき、メタデータの送信要求があった場合、当該送信要求を行った通信端末１１の機種名、記憶容量からアップデートデータの分割の要否を判断していた。この場合、実際には通信端末１１ごとにアプリケーションのインストール状況などにより、記憶部１０５の空き容量が異なってくる場合があるため、不必要に分割が行われたり、分割されるべきデータが分割されず、アップデートの効率が低下したり、アップデートの実行が困難になる場合も発生する。

このため、この実施の形態２では、通信端末１１がメタデータの送信要求に、現時点の記憶部１０５の空き容量等からダウンロード可能サイズを含めて送信し、アップデートサーバ６０がこのダウンロード可能サイズとアップデートデータのサイズから、アップデートデータを分割する必要があるか否かを判断している。

本実施の形態の遠隔通信システム１のネットワーク構成、通信端末１１、アップデートサーバ６０、中継装置３０、遠隔通信管理サーバ５０の構成は、実施の形態１と同様である。

本実施の形態の通信端末１１の送受信部１１０１は、メタデータの送信要求に、通信端末１１の記憶部１０５の現時点での空き容量に基づいたダウンロード可能サイズを含めて送信する。

本実施の形態のアップデートサーバ６０のアップデートデータ提供部６０２は、通信端末１１から、このようなダウンロード可能サイズを含むメタデータ送信要求を受信する。また、分割判断部６０４は、アップデートデータ提供部６０２がメタデータの送信要求を受信した場合に、メタデータ送信要求に含まれるダウンロード可能サイズとアップデートデータのサイズに基づいて、アップデートデータを分割するか否かを判断する。

ここで、分割要否の判断は、通信端末１１のダウンロード可能サイズとアップデートデータのサイズとを比較し、ダウンロード可能サイズがアップデートデータのサイズより大きいか否かにより行う他、アップデートデータが圧縮形式で提供される場合には、アップデートデータのサイズに解凍後の展開領域のサイズも含めて、ダウンロード可能サイズと比較して判断するように分割判断部６０４を構成してもよい。

アップデートデータ分割部６０３は、ダウンロード可能サイズの範囲内でアップデートデータを分割する。

次に、アップデートサーバ６０で実行される処理について説明する。図１７は、実施の形態２のアップデートサーバ６０で実行される分割処理の流れを示すラダーチャートである。

まず、アップデートデータ提供部６０２が、送受信部６０１を介して、通信端末１１から、通信端末１１におけるダウンロード可能サイズを含むメタデータ送信要求を受信すると（ステップＳ２０１）、分割判断部６０４は、端末ＤＢ６１０において、メタデータ送信要求に含まれるダウンロード可能サイズに基づいてアップデートデータを分割するか否かを判断する（ステップＳ２０２）。

そして、分割が不要と判断された場合には（ステップＳ１３：Ｎｏ）、アップデートデータ提供部６０２は、アップデートサーバ６０が管理しているメタデータを、送信要求のあった通信端末１１に送信する（ステップＳ１６）。

一方、ステップＳ１３において、分割が必要と判断された場合には（ステップＳ１３：Ｙｅｓ）、アップデートデータ分割部６０３は、ダウンロード可能サイズに基づいてアップデートデータを分割し、分割されたアップデートデータに基づくメタデータを生成する（ステップＳ２０５）。

そして、アップデートデータ提供部６０２は、ステップＳ１５で生成されたメタデータを、送信要求のあった通信端末１１に送信する（ステップＳ１６）。

このように本実施の形態では、通信端末１１がメタデータの送信要求に、現時点の記憶部１０５の空き容量等からダウンロード可能サイズを含めて送信し、アップデートサーバ６０がこのダウンロード可能サイズとアップデートデータのサイズから、アップデートデータを分割する必要があるか否かを判断しているので、アップデートデータの不要な分割を防止することができるとともに、アップデートデータを分割した場合においても、分割後のアップデートデータの数を低減させることができる。このため、本実施の形態によれば、アップデートの効率を向上させることができる。

上述した実施の形態１，２では、アップデートが存在する場合、そのアップデートが強制のアップデートであるか否かにかかわらず、アップデートを実行するか否かの選択操作をユーザより受け付けて、アップデートを実行しない場合に自装置の処理を終了させる構成を例示した。

しかしながら、アップデートが存在する場合で、そのアップデートが強制のアップデートである場合は、アップデートが存在することをユーザに通知することなく、アップデートを実行してもよい。具体的には、図９に例示したＳ３７の処理をＳ３０の直後に行い、強制のアップデートがある場合にはＳ３１の処理を行うことなく、Ｓ３６へ処理を進めてよい。

強制のアップデートを実行していない状況では、通話すら実行できないことから、アップデートの実行が最優先となる。したがって、このような場合には、ユーザに確認するまでもなく、アップデートを実行することが好適である。

なお、上記実施の形態１，２では、遠隔通信管理サーバ５０とアップデートサーバ６０とを別個の構成とした例を示しているが、これに限定されるものではない。例えば、サーバ装置を設け、当該サーバ装置が遠隔通信管理サーバ５０の機能とアップデートサーバ６０の機能とを備えた構成としてもよい。

なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。

１ 遠隔通信システム
２ 通信ネットワーク
１１ 通話端末
１２ カメラ
１３ ディスプレイ
１４ マイク
１５ スピーカ
３０ 中継装置
５０ 遠隔通信管理サーバ
６０ アップデートサーバ
６０１ 送受信部
６０２ アップデートデータ提供部
６０３ アップデートデータ分割部
６０４ 分割判断部
６１０ 端末ＤＢ
１１０１ 送受信部
１１０２ ユーザインタフェース部
１１０３ アップデート部
１１０４ ユーザ通知部
１１０５ 操作入力受付部

特開２０１２−８４１１８号公報

Claims (8)

1. ネットワークに接続された通信装置に関する端末情報に基づいて、前記通信装置のアップデートのためのアップデートデータを分割するか否かを判断する判断部と、
   前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割部と、
   分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを、前記通信装置に送信する提供部と、
   を備えたサーバ装置。
2. 前記通信装置ごとに、前記通信装置の前記端末情報を記憶する記憶部と、
   前記通信装置から、前記メタ情報の送信要求を受信する受信部と、をさらに備え、
   前記判断部は、前記記憶部において前記送信要求を行った通信装置の前記端末情報に基づいて、前記アップデートデータを分割するか否かを判断する、
   請求項１に記載のサーバ装置。
3. 前記端末情報は、前記通信装置の記憶容量を含み、
   前記判断部は、前記記憶部において前記送信要求を行った通信装置の前記端末情報に含まれる前記記憶容量と前記アップデートデータのサイズとに基づいて、前記アップデートデータを分割するか否かを判断し、
   前記分割部は、前記記憶容量の範囲内で前記アップデートデータを分割する、
   請求項２に記載のサーバ装置。
4. 前記通信装置から、ダウンロード可能サイズを含む、前記メタ情報の送信要求を受信する受信部と、をさらに備え、
   前記判断部は、前記メタ情報の送信要求を受信した場合に、前記ダウンロード可能サイズに基づいて、前記アップデートデータを分割するか否かを判断し、
   前記分割部は、前記ダウンロード可能サイズの範囲内で前記アップデートデータを分割する、
   請求項１に記載のサーバ装置。
5. 通信装置と、前記通信装置とネットワークで接続されたサーバ装置とを備えたアップデートシステムであって、
   前記通信装置に関する端末情報に基づいて、アップデートのためのアップデートデータを分割するか否かを判断する判断部と、
   前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割部と、
   分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを送信する提供部と、
   前記メタ情報を受信する受信部と、
   受信した前記メタ情報に基づいて、前記分割されたアップデートデータを受信し、アップデートを実行するアップデート処理部と、
   を備えたアップデートシステム。
6. コンピュータに実行させるためのプログラムと、前記コンピュータとネットワークで接続されたサーバ装置とを備えたアップデートシステムであって、
   前記コンピュータに関する端末情報に基づいて、前記コンピュータのアップデートのためのアップデートデータを分割するか否かを判断する判断部と、
   前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割部と、
   分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを前記コンピュータに送信する提供部と、
   前記プログラムは、
   前記メタ情報を受信する受信ステップと、
   受信した前記メタ情報に基づいて、前記分割されたアップデートデータを受信し、アップデートを実行するアップデート処理ステップと、
   を前記コンピュータに実行させる、アップデートシステム。
7. サーバ装置で実行されるアップデート方法であって、
   前記サーバ装置とネットワークに接続された通信装置に関する情報に基づいて、前記通信装置のアップデートのためのアップデートデータを分割するか否かを判断する判断ステップと、
   前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割ステップと、
   分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを、前記通信装置に送信する提供ステップと、
   を含むアップデート方法。
8. コンピュータに実行させるためのプログラムであって、
   前記コンピュータとネットワークに接続された通信装置に関する情報に基づいて、前記通信装置のアップデートのためのアップデートデータを分割するか否かを判断する判断ステップと、
   前記アップデートデータを分割すると判断された場合に、前記アップデートデータを分割する分割ステップと、
   分割されたアップデートデータに基づいたメタ情報と前記分割されたアップデートデータを、前記通信装置に送信する提供ステップと、
   を前記コンピュータに実行させるためのプログラム。

Images