JP2015095071A - 通信装置、通信システム、通信方法及び通信プログラム - Google Patents

Abstract

【課題】アップデートの実行前にサーバ上のアップデートデータの変更の有無を判断し、変更されている場合はアップデートデータの再取得を行うことができる通信装置、通信システム、通信方法及び通信プログラムを提供することを目的としている。
【解決手段】データ伝送路を介して通信が実施可能な通信装置であって、アップデートに関する記述を有するメタ情報を受信する受信手段と、アップデートデータがダウンロード済みの場合、前記受信手段によって受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定する判定手段と、前記判定手段によってアップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行う取得手段と、前記取得手段によってダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するアップデート処理手段とを備える。
【選択図】図６

Description

本発明は、通信装置、通信システム、通信方法及び通信プログラムに関する。

テレビ会議システムなどの通信システムでは、通話秘匿性能や操作性能を向上させるために、ファームウェア（プログラム）のアップデートが定期的に行われることがある。このような通信システムにおけるプログラムは、アップデートデータとメタ情報を、ネットワークを介してサーバへアクセスして取得し、プログラムをアップデートする方法が既に知られている（例えば、特許文献１等を参照）。アップデートデータのダウンロードは、通常アップデートが開始できる日付以降にダウンロードが可能となる。

また、多数のダウンロード要求アクセスの集中による通信回線のトラフィックの飽和を防止するために、予め設定された時刻以前に、そのままでは機能しない状態でコンテンツファイルをクライアント装置に提供し、予め設定された時刻以降に、コンテンツファイルが機能する上で必要な有効化情報をクライアント装置に提供する技術が既に知られている（例えば、特許文献２等を参照）。

しかし、今までのアップデートを行うシステムでは、通話端末がアップデートデータのダウンロード完了後、実際にアップデートを開始できる日付より前に、アップデートデータに不具合が見つかることがあった。通話端末は、事前にダウンロードしたアップデートデータの不具合を修正したアップデートデータに差換えることができない為、アップデートデータを管理するサーバでは、不具合を修正したアップデートデータを別のバージョンとして管理する必要があった。その結果、通話端末は、修正したアップデートデータのアップデート実行をするまでに、アップデートデータのダウンロードとアップデートの実行を何度も実行する必要があった。また、不具合を修正したアップデートデータのダウンロードの実行を完了させる前に会議システムを利用した場合、不具合のあるアップデートデータが原因で通話端末に不具合が発生することがあった。

この発明に係る通信装置は、上記に鑑みてなされたものであって、アップデートデータの再取得を行うことができる通信装置、通信システム、通信方法及び通信プログラムを提供することを目的としている。

上記課題を解決するため、本発明にあっては、請求項１に記載されるように、データ伝送路を介して通信が実施可能な通信装置であって、アップデートに関する記述を有するメタ情報を受信する受信手段と、アップデートデータがダウンロード済みの場合、前記受信手段によって受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定する判定手段と、前記判定手段によってアップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行う取得手段と、前記取得手段によってダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するアップデート処理手段とを備える通信装置を要旨としている。

本発明によれば、通話端末は、アップデートデータの再取得を行うことが可能となる。

実施の形態の通信システムの構成を例示する模式図である。 通話端末のハードウエア構成を例示するブロック図である。 中継装置、通信管理サーバ、アップデートサーバのハードウエア構成を例示するブロック図である。 実施の形態の通話端末及びアップデートサーバの機能構成を例示するブロック図である。 実施の形態の通話端末の動作の一例を示す図である。 実施の形態の事前ダウンロード処理を示す図である。 メタデータの一例を示す概念図である。 起動画面の一例を示す概念図である。 設定画面の一例を示す概念図である。 確認画面の一例を示す概念図である。 確認ウインドウの一例を示す図である。 実施の形態のアップデート処理の一例を示す図である。 アップデート画面の一例を示す概念図である。 確認画面の一例を示す概念図である。

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

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

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

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

アップデートサーバ６０は、通話端末１１のプログラムや各種設定情報のアップデートにかかる情報を管理し、通話端末１１の要求に応じてその情報を提供するアップデート情報提供装置である。アップデートにかかる情報としては、通話端末１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルと、バージョンごとにアップデートの内容を記載したメタデータ（メタ情報）などである。アップデートサーバ６０は、各通話端末がアップデートを行う時期が異なる為、アップデートに係る情報として全てのバージョンのデータファイルを管理している。

具体的には、頻繁にアップデートを実施している通話端末は、最新のバージョンへのアップデートを実行するだけでよいが、長期にわたってアップデートを行っていない通話端末は、最新のバージョンから依存関係のあるバージョンへと遡り、アップデートを実行する必要がある。このように、最新のバージョンだけでなく、依存関係のあるバージョンへのアップデートを必要とする通話端末が存在することから、アップデートサーバ６０はアップデートに係る情報として全てのバージョンを管理している。

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

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

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

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

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

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

通話端末１１は、プログラム１０４を実行したＣＰＵ１０１の制御の下、例えば他の通話端末との通話時には、カメラ１２から取得した画像やマイク１４から入力された音声をネットワークＩ／Ｆ１１１を介して中継装置３０へ出力する。また、中継装置３０より中継され、ネットワークＩ／Ｆ１１１を介して入力された他の通話端末からの音声をスピーカ１５より出力し、同様に他の通話端末からの画像をディスプレイ１３により表示する。これにより、通話端末１１は、画像及び音声による他の通話端末との通話、いわゆるテレビ会議を実現する。なお、通話端末１１は、汎用のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、スマートフォン、携帯電話及びタブレット端末などの通信端末であってもよい。

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

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

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

次に、ＣＰＵ１０１やＣＰＵ２０１がプログラムを実行することにより実現する通話端末１１及びアップデートサーバ６０の機能構成について説明する。図４は、実施の形態の通話端末１１及びアップデートサーバ６０の機能構成を例示するブロック図である。図４に示すように、通話端末１１は、送受信部１１０１、ユーザインタフェース部１１０２、アップデート部１１０３及びデータ検査部１１０６を主に有している。アップデートサーバ６０は、送受信部６０１及びアップデートデータ提供部６０２を主に有している。なお、通話端末１１及びアップデートサーバ６０の各機能は、一部又は全部がハードウエアで構成されてもよい。

受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う機能部である。具体的には、記憶部１０５に予め記憶されているアップデートサーバ６０の通信アドレス、もしくは通信管理サーバ５０への問い合わせによって取得したアップデートサーバ６０の通信アドレスを用いて、アップデートサーバ６０との間で所定の通信セッションを確立することでアップデートサーバ６０との間でデータの送受信を行う。なお、受信部１１０１が送受信を行うデータは、アップデートサーバ６０が管理するアップデートにかかる情報（例えばメタデータ及びアップデートデータなど）である。

ユーザインタフェース部１１０２は、スピーカ１５による音声出力やディスプレイ１３の表示画面でユーザへの各種通知を行うユーザ通知部１１０４と、操作部１０８によるユーザの操作入力を受け付ける操作入力受付部１１０５とを有する。

アップデート部１１０３は、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報を示す関連情報（メタデータ）に基づいて、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデート（アップデートデータのダウンロードを含む）を制御して実行する。アップデート部１１０３が実行するアップデートについては、後述するアップデート処理（図５のステップＳ１６）において詳細に説明する。

データ検査部１１０６は、ファイル識別情報を用いてアップデートサーバ６０上でアップデートデータの変更が行われたか否かを検査する機能部である。ファイル識別情報とは、アップデートデータが変更されているか否かを判定するために用いる識別情報である。ファイル識別情報は、アップデートデータから生成され、アップデートデータごとに単一であることが望ましい。本実施の形態においては、ハッシュ値をファイル識別情報として用いている。具体的には、記憶部１０５に記憶されているアップデートの実行可能日以前のアップデートデータのファイル識別情報と受信部１１０１より事前に取得したアップデートデータに係る情報を示す関連情報に含まれるファイル識別情報を比較する。比較した結果、ファイル識別情報が一致しない場合は、アップデートサーバ６０上でアップデートデータの変更が行われたと判断し、受信部１１０１へ通知を行い、アップデートデータの再取得を行う。

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

アップデートデータ提供部６０２は、送受信部６０１によってデータの送受信を行っている通話端末１１からの要求に応じて、アップデートサーバ６０が管理しているアップデートにかかる情報を通話端末１１に提供する。

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

アップデート部１１０３は、Ｓ１による電源投入後の起動時において、自装置のアップデートの確認を開始する（ステップＳ３）。なお、通話装置のアップデートにはプログラムのアップデートはもちろん、各種設定情報のアップデートも含まれる。

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

ここでメタデータについて説明する。メタデータは、アップデートの実行が可能なアップデートデータのメタデータに加え、アップデータの実行日以前にダウンロード可能なアップデートデータのメタデータを含んでいる。図７にメタデータの例を記載している。図７のメタデータは、"ｖｅｒｓｉｏｎ"、"ｄｅｐｅｎｄｅｎｃｙ"、"ｄｅｓｃｒｉｐｔｉｏｎ"、"ｆｉｌｅｓ"、"ｓｃｒｉｐｔｎａｍｅ"、"ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ"、"ｆｏｒｃｅ＿ｕｐｄａｔｅ"、 "ｉｓＶａｌｉｄ"、"ｖａｌｉｄ ｄａｔｅ"で構成される。

"ｖｅｒｓｉｏｎ"には「１．０．１」のようなバージョン番号が記述される。"ｄｅｐｅｎｄｅｎｃｙ"には、「１．０．０」など、"ｖｅｒｓｉｏｎ"に記載のバージョンと依存関係にある他のバージョン番号が記述される。つまり、"ｄｅｐｅｎｄｅｎｃｙ"に記載のバージョンを確認することで、依存関係にあるバージョンを遡って知ることができる。"ｄｅｓｃｒｉｐｔｉｏｎ"には、"Ｉｔ ｉｓ ｓａｍｐｌｅ ｄａｔａ．"などの当該アップデータデータの詳細な情報が記述される。"ｆｉｌｅｓ"には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）のリスト、その格納先を示すＵＲＬ情報、及びデータファイルの識別情報が記述される。図７に示す一例では、ファイル識別情報にハッシュ値を用いている。"ｄｉｇｅｓｔ"には、ハッシュ値を設定している。したがって、アップデート部１１０３は、"ｆｉｌｅｓ"のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートを実行することができる。また、"ｆｉｌｅｓ"に含まれる"ｄｉｇｅｓｔ"をもとに、データ検査部１１０６によってデータファイルの変更の有無を判断することができる。"ｓｃｒｉｐｔｎａｍｅ"には、アップデートを実行する際に実行するスクリプト名が記述される。"ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ"には、アップデートの実行後に、装置の再起動を行うか否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｆｏｒｃｅ＿ｕｐｄａｔｅ"には、強制のアップデートであるか否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｉｓＶａｌｉｄ"には、アップデートデータが実行可能か否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｖａｌｉｄ ｄａｔｅ"には、アップデートデータが実行可能となる日時が記述される。

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

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

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

次いで、アップデート部１１０３は、"ｉｓＶａｌｉｄ"が"ｔｒｕｅ"に設定された最新バージョンのメタデータの"ｖｅｒｓｉｏｎ"に記述されたバージョン番号と、自装置の記憶部１０５に記憶されたプログラム１０４のバージョン番号とを比較することで、自装置の実行可能なアップデートが存在するか否かを判定する（ステップＳ１０）。具体的には、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致する場合は、プログラム１０４が最新バージョンであることから、実行可能なアップデートが存在しないと判定する。

また、アップデート部１１０３は、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、実行可能なアップデートが存在すると判定する。

アップデート部１１０３は、実行可能なアップデートが存在しない場合（ステップＳ１０：ＮＯ）は、事前ダウンロード可能なアップデートデータがあるか否かを判定する（ステップＳ２００）。ここで、アップデート部１１０３は、メタデータの"ｉｓＶａｌｉｄ"が"ｆａｌｓｅ"に設定されたものがあるか否かにより、事前ダウンロード可能なアップデートデータがあるか否かを判定する。

アップデート部１１０３は、事前ダウンロード可能なデータがない場合（ステップＳ２００：Ｎｏ）、アップデートの実行及び事前ダウンロードを行う必要がないことから、通常の動作を継続させる（ステップＳ１９）。また、アップデート部１１０３は、事前ダウンロード可能なデータがある場合（ステップＳ２００：ＹＥＳ）、事前ダウンロード処理（ステップＳ２０２）を行い、その後に通常の動作を継続させる（ステップＳ１９）。

ここで通話端末１１が実施する事前ダウンロードの処理について説明する。

図６は、事前ダウンロード可能なアップデートデータが存在する場合に通話端末１１が実施する事前ダウンロードの処理を示すフローチャートである。通話端末１１は、図７に示すメタデータを受信し、ファイル識別情報はハッシュ値であるとする。

まず、通話端末１１はアップデートサーバ６０より取得したメタデータから事前ダウンロード可能なアップデートデータが存在することを確認すると図６に示す事前ダウンロードに係る処理を開始する（ステップＳ１００）。通話端末１１は、記憶部１０５に当該アップデートデータが保存されているか否かを判定する（ステップＳ１０１）。判定方法の一例として、該当するアップデートデータのメタデータに記載されているファイル名のファイルが、通話端末１１の記憶部１０５に存在するか否かを判定する方法がある。

通話端末１１が、アップデートデータを保持していない場合（ステップＳ１０１：ＮＯ）、通話端末１１は、サーバ６０に対して該当するアップデートデータのダウンロードを要求する（ステップＳ１０３）。アップデートデータを取得後、処理を終了する（ステップＳ１０４）。

一方、通話端末１１がアップデートデータを保持している場合（ステップＳ１０１：ＹＥＳ）、通話端末１１はダウンロード済みのファイルのハッシュ値と図５のＳ５にて取得した同一バージョンのアップデートデータのメタデータに含まれるハッシュ値が一致しているか否かを確認する（ステップＳ１０２）。ハッシュ値が一致する場合（ステップＳ１０２：ＹＥＳ）、通話端末１１は、事前ダウンロード処理を終了する（ステップＳ１０４）。一方、ハッシュ値が一致しない場合（ステップＳ１０２：ＮＯ）、通話端末１１は、記憶部１０５に保存してあるアップデートデータを破棄し、アップデートデータの再ダウンロードを開始する（ステップＳ１０３）。通話端末１１は、ダウンロード完了後、事前ダウンロード処理を終了する（ステップＳ１０４）。

つまり、通信装置１１は、記憶部１０５に保存しているアップデートデータのハッシュ値と、図５のＳ５にて取得したメタデータに含まれるハッシュ値とを比較することによって、アップデートサーバ６０に保存されている同一バージョンのアップデートデータの変更の有無を判断し、アップデートデータの再取得の要否を判断する。

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

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

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

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

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

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

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

図１０は、確認画面Ｇ３の一例を示す概念図である。図１０に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行又はキャンセルの指示をユーザより受け付けるための操作ボタンＧ３４、Ｇ３５とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む構成である。アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデートに関する情報として含まれるデータ項目の"ｖｅｒｓｉｏｎ"の記述をもとにした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示され、ユーザに通知される。したがって、ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。なお、確認画面Ｇ３のアップデート表示Ｇ３３に、さらに、再起動が行われるか否かの情報を表示するように構成してもよい。

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

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

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

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

ここで、アップデート処理（ステップＳ１６）の詳細について説明する。図１２は、通話端末１１が実行するアップデート処理の一例を示す図である。ここで通話端末１１は、図６と同様に、図７に示すように構成されるメタデータを受信し、ファイル識別情報はハッシュ値であるとする。

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

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

次いで、アップデート部１１０３は、メタデータの"ｉｓＶａｌｉｄ"に基づいてアップデートが実行可能か否かを判断する（ステップＳ３０２）。例えば、アップデート部１１０３は、通話端末がＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）サーバから取得した現在時刻と、"ｖａｌｉｄ ｄａｔｅ"に記載されている時刻を比較して、"ｖａｌｉｄ ｄａｔｅ"が過去の時刻であれば、"ｉｓＶａｌｉｄ"のフラグを"ｔｒｕｅ"に書き換え、アップデートが実行可能と判断する。

アップデート部１１０３は、実行可能でないと判断した場合（ステップＳ３０２：ＮＯ）、Ｓ３１０の処理に進み、アップデートが実行できない旨をユーザインタフェース部１１０２に通知する。また、アップデート部１１０３は、実行可能と判断した場合（ステップＳ３０２：ＹＥＳ）、そのデータを事前ダウンロードで取得済みかどうかを判定する（ステップＳ３０３）。

アップデート部１１０３は、アップデートデータを事前ダウンロードで取得済みである場合（ステップＳ３０３：ＹＥＳ）、事前にダウンロードしたファイルから算出されたハッシュ値と、事前にダウンロードしたアップデートデータに対応するメタデータに含まれるハッシュ値とを比較する（ステップＳ３０５）。ハッシュ値を比較し、ハッシュ値が一致するか否かを判断する（ステップＳ３０６）。ハッシュ値が一致する場合（ステップＳ３０６：ＹＥＳ）、アップデートを実行し、アップデートの進行状況をユーザインタフェース部１１０２に通知する（ステップＳ３０７）。ハッシュ値が一致しない場合（ステップＳ３０６：ＮＯ）、通信端末１１が、記憶部１０５に保存しているアップデートデータが再取得したものか否かを確認する（ステップＳ３０７）。具体的には、Ｓ３００のアップデート処理開始後において、事前ダウンロードしたアップデートデータを破棄し、Ｓ３０４にて取得したものか否かを確認する。再取得により取得したものでない場合（ステップＳ３０７：ＮＯ）、Ｓ３０４の処理に戻り、アップデートデータの再取得を行う。つまり、対応するアップデートデータが変更されているため、通話端末１１はアップデートサーバ６０から対応するアップデートデータの再取得を行う。

一方、再取得したアップデートデータの場合（Ｓ３０７：ＹＥＳ）は、エラーが発生したものとみなし、Ｓ３０８の処理に進む。再取得を行った後もハッシュ値が一致しない例として、アップデートサーバ６０にあるアップデートデータ自体に欠損が生じていること等が考えられる。

アップデート部１１０３は、アップデートデータを事前ダウンロードしていない場合（ステップＳ３０３：ＮＯ）、取得したメタデータに記述されているファイルをアップデートサーバから取得する。ファイルの取得後は、アップデートデータを事前ダウンロードで取得済みの場合（ステップＳ３０３：ＹＥＳ）と同様にＳ３０５からＳ３０７の処理が実行される。なお、この時にハッシュ値が一致しない原因として、ダウンロード中の通信障害などが考えられる為、通話端末１１は、アップデートデータの再取得を一度だけ行う。再取得を行ってもハッシュ値が一致しない場合は、アップデートデータを事前ダウンロードで取得済みの場合と同様に、エラーが発生したものとみなし、Ｓ３０８の処理に進む。

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

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

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

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

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

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

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

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

このように本実施の形態では、通話端末側でアップデートデータの再取得が可能となることにより、アップデートサーバにおいて軽微な不具合を修正した場合等は、アップデートサーバにおいて当該アップデートデータを新しいバージョンとして管理する必要がなく、データの差換えのみで対処が可能になるという効果を奏する。また、アップデートサーバにおいてアップデートデータの差換えが可能になることによって、不具合のあるアップデートデータが原因で生じる不具合の発生を防止することができる。

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

具体的には、通信システム１は、テレビ電話システム、音声会議システム、音声電話システム、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）画面共有システム、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話及びインターネット電話等の電話システムであってもよい。さらに、遠隔操作システム１は、カーナビゲーションシステムであってもよい。例えば、通話端末１１の一方が自動車に搭載されたカーナビゲーション装置に相当し、通話端末１１の他方がカーナビゲーションを管理する管理センターの管理端末若しくは管理サーバ、又は他の自動車に搭載されているカーナビゲーション装置に相当するように構成されてもよい。また、通信システム１１は、映画、ドラマ、テレビ、投稿動画などの映像や、電子書籍などの電子データを配信するコンテンツ配信システムとして構成されてもよい。

また、上記各実施形態における通信管理サーバ５０、及びアップデートサーバ６０は、単一のコンピュータによって構築されてもよいし、各部（機能又は手段）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、アップデートサーバ６０が単一のコンピュータによって構築されている場合には、アップデートサーバ６０によって送信されるプログラムは、複数のモジュールに分けて送信されるようにしてもよいし、分けないで送信されるようにしてもよい。更に、アップデートサーバ６０が複数のコンピュータによって構築されている場合には、複数のモジュールが分けられた状態で、各コンピュータから送信されるようにしてもよい。

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

特開２０１２−８４１１８号公報 特開２０１１−１９３２６４号公報

Claims (6)

1. データ伝送路を介して通信が実施可能な通信装置であって、
   アップデートに関する記述を有するメタ情報を受信する受信手段と、
   アップデートデータがダウンロード済みの場合、前記受信手段によって受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定する判定手段と、
   前記判定手段によってアップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行う取得手段と、
   前記取得手段によってダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するアップデート処理手段と
   を備えることを特徴とした通信装置。
2. 請求項１に記載の通信装置において、
   前記メタ情報は、
   前記アップデートデータが変更されているか否かの判断に用いられるファイル識別情報を有することを特徴とした通信装置。
3. 請求項２に記載の通信装置において、
   前記アップデートデータから前記ファイル識別情報を生成する生成手段を備え、
   前記判定手段は、
   前記生成手段によって生成された前記ファイル識別情報と、前記受信手段によって受信した前記メタ情報に含まれる前記ファイル識別情報とを比較することによって、前記アップデートデータが変更されたか否かを判定することを特徴とした通信装置。
4. データ伝送路を介して通信可能なアップデート情報提供装置と通信装置を備えた通信システムであって、
   前記アップデート情報提供装置は、
   通信装置とのアップデート情報の送受信を行う送信手段と、
   前記通信装置からの要求によりアップデートデータを提供するアップデートデータ提供手段と
   を備え、
   前記通信装置は、
   アップデートに関する記述を有するメタ情報を受信する受信手段と、
   アップデートデータがダウンロード済みの場合、前記受信手段によって受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定する判定手段と、
   前記判定手段によってアップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行う取得手段と、
   前記取得手段によってダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するアップデート処理手段と
   を有することを特徴とした通信システム。
5. データ伝送路を介して通信が実施可能な通信装置において、
   アップデートに関する記述を有するメタ情報を受信する受信工程と、
   アップデートデータがダウンロード済みの場合、受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定する判定工程と、
   アップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行う取得工程と、
   ダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するアップデート処理工程と
   を行う通信方法。
6. データ伝送路を介して通信可能な通信装置が有するコンピュータに、
   アップデートに関する記述を有するメタ情報を受信する受信ステップと、
   アップデートデータがダウンロード済みの場合、受信された前記メタ情報に基づいて、当該アップデートデータが変更されたか否かを判定するステップと、
   アップデートデータが変更されていると判定された場合、変更されたアップデートデータのダウンロードを行うステップと、
   ダウンロードされた前記変更されたアップデートデータに基づいて、アップデートを実行するステップと
   を実行させるための通信プログラム。