JP2015103106A - 通信装置、及び通信プログラム - Google Patents

Abstract

【課題】アップデートが必要な複数のアップデートデータが存在する場合においても、アップデートデータ毎にアップデートに関する情報を把握できる通信装置と、通信プログラムを提供する。
【解決手段】メタデータを受信する受信手段であって、前記メタデータは前記メタデータの受信時より後にアップデートの実行が可能なアップデートデータに関する情報を含む、受信手段と、前記メタデータにしたがって前記メタデータに対応するアップデートデータのアップデートが実行可能か否かを通知する通知手段とを有することを特徴とする。
【選択図】図９

Description

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

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

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

出願人はアップデートデータの容量が大きい場合や、ユーザの利用するネットワーク回線の通信速度が遅い場合など、ダウンロードに時間がかかりユーザの待ち時間が長くなるという問題があった。このため、ユーザは、ダウンロードの進捗状況やアップデートの実行可能なタイミングといったアップデートに関わる情報について知りたいと考えるが、アップデートの必要がある複数のアップデートデータが存在する場合、アップデートデータ毎にアップデートに関わる情報を把握することができなかった。

この発明に係る通信装置は、上記に鑑みてなされたものであって、アップデートが必要な複数のアップデートデータが存在する場合においても、アップデートデータ毎にアップデートに関する情報を把握できる通信装置と、通信プログラムを提供することを目的としている。

本発明のある態様によると、メタデータを受信する受信手段であって、前記メタデータは前記メタデータの受信時より後にアップデートの実行が可能なアップデートデータに関する情報を含む、受信手段と、前記メタデータにしたがって前記メタデータに対応するアップデートデータのアップデートが実行可能か否かを通知する通知手段とを備えることを特徴とした通信装置を要旨としている。

本発明によれば、アップデートが必要な複数のアップデートデータが存在する場合においても、アップデートデータ毎にアップデートに関する情報を把握できる通信装置と、通信プログラムを提供できる。

本発明の実施の形態に係る通信システムの構成を例示する模式図 通話端末のハードウエア構成を例示するブロック図 中継装置、通信管理サーバ、アップデートサーバのハードウエア構成を例示するブロック図 実施の形態の通話端末及びアップデートサーバの機能構成を例示するブロック図 実施の形態の通話端末の動作の一例を示す図 メタデータの一例を示す概念図 起動画面の一例を示す概念図 設定画面の一例を示す概念図 本発明の実施の形態に係る確認画面の一例を示す概念図（その１） 確認画面の表示処理の一例を示すフローチャート図 確認ウインドウの一例を示す図 実施の形態のアップデート処理の一例を示す図 アップデート画面の一例を示す概念図 本発明の実施の形態にかかる確認画面の一例を示す概念図（その２） 本発明の変形例に係る確認画面の一例を示す概念図（その１） 本発明の変形例に係る確認画面の一例を示す概念図（その２）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

送受信部６０１は、通信ネットワーク２を介して通話端末１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した通話端末１１の要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、通話端末１１との間でデータの送受信を行う。本実施の形態では通話端末１１からの要求に応じて、アップデートサーバ６０がアップデートに係る情報を送付する例を示しているが、最新のアップデートデータのメタデータが新しく保存された場合や、保存されているメタデータに変更があった場合などにアップデートデータ提供部６０２から通話端末１１へメタデータの送付を行ってもよい。

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

実行可否フラグ変更部６０３は、ダウンロード可能なアップデートデータのアップデートの実行を通話端末１１に許可するか否かを示すフラグを制御する。具体的には、アップデートの実行を許可しない状態から許可する状態もしくは、許可する状態から許可しない状態へと変更する。フラグの変更は、キーボード２０７やマウス２０８からの入力を受け付けて変更してもよい。また、予めフラグ情報を変更する時間を設定しておき、設定した時間になったらフラグ情報を変更するようにしてもよい。

つづいて、通話端末１１が実行する処理の一例を説明する。図５は、実施の形態の通話端末の動作の一例を示す図である。

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

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

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

ここでメタデータについて説明する。メタデータは、アップデートの実行が可能なアップデートデータのメタデータに加え、アップデータの実行日以前にダウンロード可能なアップデートデータのメタデータを含んでいる。図６にメタデータの一例を示す概念図を記載している。図６のメタデータは、"ｖｅｒｓｉｏｎ"、"ｄｅｐｅｎｄｅｎｃｙ"、"ｄｅｓｃｒｉｐｔｉｏｎ"、"ｆｉｌｅｓ"、"ｓｃｒｉｐｔｎａｍｅ"、"ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ"、"ｆｏｒｃｅ＿ｕｐｄａｔｅ"、 "ｉｓＶａｌｉｄ"で構成される。"ｖｅｒｓｉｏｎ"には「１．０．１」のようにバージョン番号が記述される。"ｄｅｐｅｎｄｅｎｃｙ"には、「１．０．０」など、"ｖｅｒｓｉｏｎ"に記載のバージョンが依存する他のバージョン番号が記述される。つまり、"ｄｅｐｅｎｄｅｎｃｙに記載のバージョンを確認することで依存するバージョンを遡って知ることができる。"ｄｅｓｃｒｉｐｔｉｏｎ"には、"Ｉｔ ｉｓ ｓａｍｐｌｅ ｄａｔａ．"などの当該アップデータデータの詳細な情報が記述される。"ｆｉｌｅｓ"には、アップデートサーバ６０が管理しているアップデートの実体となるプログラム（データファイル）のリスト、その格納先を示すＵＲＬ情報が記述される。したがって、アップデート部１１０３は、"ｆｉｌｅｓ"のデータ項目に記述された内容をもとに、送受信部１１０１によってデータファイルを取得することができる。"ｓｃｒｉｐｔｎａｍｅ"には、アップデートを実行する際に実行するスクリプト名が記述される。"ｒｅｑｕｉｒｅ＿ｒｅｂｏｏｔ"には、アップデートの実行後に、装置の再起動を行うか否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｆｏｒｃｅ＿ｕｐｄａｔｅ"には、強制のアップデートであるか否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｉｓＶａｌｉｄ"には、アップデートデータが実行可能か否かを示すフラグ（"ｔｒｕｅ"又は"ｆａｌｓｅ"）が記述される。"ｉｓＶａｌｉｄ"には、"ｔｒｕｅ"や"ｆａｌｓｅ"に限定されず、他の文字列を記述してもよい。例えば、アップデートの実行が可能な場合は"ｔｒｕｅ"を記述し、アップデートの実行が可能でない場合は、"２０１３／１０／２０"のようにアップデートの実行が可能となる日時を記述してもよい。通話端末１１は、"ｉｓＶａｌｉｄ"に記載されるフラグに従ってアップデートを実行するか否かを判断する。

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

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

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

次いで、アップデート部１１０３は、サーバより取得したメタデータ内の"ｖｅｒｓｉｏｎ"に記述されたバージョン番号と、通話端末１１の記憶部１０５に記憶されたプログラム１０４のバージョン番号と比較することで、記憶部１０５に記憶されたプログラムよりも新しいアップデートデータが存在するか否かの確認を行う（ステップＳ１０）。具体的には、プログラム１０４のバージョン番号と、アップデートサーバ６０より取得したメタデータ内の"ｖｅｒｓｉｏｎ"に記述されたバージョン番号とが一致する場合は、プログラム１０４が最新バージョンであることから、取得が必要なアップデートが存在しないと判定する。また、アップデート部１１０３は、取得したメタデータ内に示されるバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４のバージョンよりも新しいバージョンが存在することから、取得が必要なアップデートが存在すると判定する。

アップデート部１１０３は、プログラム１０４よりも新しいアップデートデータが存在しないと判断した場合（ステップＳ１０：ＮＯ）、通常の動作を継続させる（ステップＳ２２）。新しいアップデートデータが存在すると判断した場合（ステップＳ１０：ＹＥＳ）、アップデート部１１０３は、新しいアップデートデータが実行可能か否かを判断する（ステップＳ１１）。具体的には、最新のバージョンのメタデータ内の"ｉｓＶａｌｉｄ"に含まれるフラグ情報に従い、判断する。例えば、"ｉｓＶａｌｉｄ"のフラグ情報が"ｆａｌｓｅ"の場合は、最新のアップデートデータは、まだアップデートの実行ができないと判断し、フラグ情報が"ｔｒｕｅ"の場合は、アップデートの実行が可能な状態であると判断する。

最新のアップデートデータが実行可能でないと判断した場合（ステップＳ１１：ＮＯ）、アップデート部１１０３は事前ダウンロード処理を実行する（ステップＳ１２）。具体的には、現時点でアップデートの実行は行えないが、事前にダウンロードが可能なアップデートデータをダウンロードする。ダウンロード処理の実行後、通常の動作を継続させる（ステップＳ２２）。なお、事前ダウンロードはバックグラウンドダウンロードで行ってもよい。

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

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

ステップＳ１５にて実行可能なアップデートの情報をユーザインタフェース部１１０２に通知した後、ステップＳ１４にて取得可能なアップデートデータのダウンロードを自動的に開始することができる。アップデートデータの自動ダウンロードは、起動画面などのユーザへの表示画面を表示させながら、バックグラウンドで行われる。また、バックグラウンドでのダウンロードは、ダウンロード中であってもユーザによって他の通話端末との通話などの通信が開始された時点でダウンロードを停止する。他の通話端末との通信の終了に伴い、ダウンロードを再開させることができる。なお、バックグラウンドによる自動ダウンロードを行うか否かは、図８に示す設定画面にて変更することができる。

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

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

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

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

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

図９は、本発明の実施の形態に係る確認画面の一例を示す概念図（その１）である。アップデート確認画面Ｇ３は、各バージョン番号のアップデートの進捗状況を示す画面Ｇ３３〜Ｇ３６、アップデートのキャンセルを指示を受け付ける操作ボタンＧ３７、アップロードの実行の指示を受け付ける操作ボタンＧ３８とを含む主画面Ｇ３１と、自装置のステータスを示すＧ３２を含む構成である。

アップデート確認画面Ｇ３は、サーバより取得したメタデータに基づき、アップデートすべきバージョンの個数、アップデートの実行が可能か否かといった情報に基づき画面を構成する。図９の例では、通話端末１１に適用すべきアップデートが４つ存在している。バージョン「３．０１」と「３．０２」と「３．０３」はその時点でアップデートの適用が可能であることを、「適用可」という文字列表示とアップデートの実行が可能であることを表すアイコンにより示している。バージョン「３．０４」は「２０１３／１０／２０に適用可」という文字列表示とアップデートデータのダウンロードのみ可能であることを表すアイコンにより示している。また、現時点でのダウンロード進捗状況をバージョン毎に進捗バーにより表示を行う。なお、進捗状況は、進捗バーに限定されず、進捗状況を数字などの文字情報で表してもよい。各バージョンの確認画面に表示する情報は、画面例に示したものに限定せず、変更してもよい。また、図９で示したようにアップデートが実行可能か否かの情報は、アイコンで判別できるように表示してもよい。例えば、ダウンロードとアップデートが実行可能なことを示すアイコンと、ダウンロードのみ実行可能なことを示すアイコンの２種類を用意して表示させる。なお、上述したアップデート情報およびダウンロードの進捗状況に関する情報を、図９に示した画面表示の形式に限らず、スピーカ１５から音声で通知してもよい。

次に図９のアップデート確認画面を表示するにあたり通話端末１１が実行する処理の例を示す。図１０は確認画面の表示処理の一例を示すフローチャート図である。Ｓ１３にてアップデート部１１０３が、ユーザインタフェース部１１０２へアップデートに関する情報を通知するタイミングで処理が開始される（ステップＳ１００）。

ユーザ通知部１１０４は、メタデータに含まれるアップデートに関する情報をアップデート部１１０３から取得する（ステップＳ１０１）。ユーザ通知部１１０４は、取得したアップデートに関する情報から現時点でアップデートの実行可能もしくは、今後にアップデートの実行が可能になるアップデートデータがアップデートサーバ６０に存在するか否かを判断する（ステップＳ１０２）。

該当するアップデートデータがサーバ上に存在しない場合（ステップＳ１０２：ＮＯ）、プログラム１０４が最新であることを示す確認画面を生成し、処理を終了する（ステップＳ１０３、Ｓ１０７）。該当するアップデートデータがアップデートサーバ６０に存在する場合（ステップＳ１０２：ＹＥＳ）、ユーザ通知部１１０５は、アップデートに関する情報に従ってアップデート確認画面の構成を決定する（ステップＳ１０４）。具体的には、アップデートに関する情報に含まれる該当するアップデートデータの個数と、各アップデートのバージョン情報、各アップデートの実行可否に関する情報に基づいてアップデート確認画面の構成が行われる。ここで示した情報に限らず、アップデート確認画面の構成に用いる情報は、自由に変更してもよい。また、アップデート確認画面の構成は、文字列に限定せず、アイコンなどを組み合わせてもよい。例えば、アップデートデータの個数によりそれぞれのアップデートの情報を表示する枠の数を決定し、その枠の中に表示するアップデートバージョン情報や適用可能かどうかといった文字列情報やアイコンの情報を紐付けて構成する。

次に各アップデートデータのダウンロードの進捗状況をアップデート部１１０３から取得する（ステップＳ１０５）。その後、ステップＳ１０４にて決定した画面構成と、ステップＳ５にて取得したダウンロード状況を紐付け、ユーザに通知し、処理を終了する（ステップＳ１０６、Ｓ１０７）。

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

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

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

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

ここで、アップデート処理（ステップＳ１９）の詳細について説明する。図１２は、実施の形態のアップデート処理の一例を示す図である。ここで通話端末１１は、図６に示すように構成されるメタデータを受信する。

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

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

次いで、アップデート部１１０３は、メタデータの"ｉｓＶａｌｉｄ"に基づいてアップデートが実行可能か否かを判断する（ステップＳ２０２）。

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

アップデート部１１０３は、データをダウンロードで取得済みである場合（ステップＳ２０３：ＹＥＳ）、取得した全てのファイル（ダウンロードしたアップデートデータ）のチェックサムを確認する（ステップＳ２０５）。アップデート部１１０３は、データを事前ダウンロードで取得済みでない場合（ステップＳ２０３：ＮＯ）、ファイルリストのファイルをアップデートサーバ６０から取得し（ステップＳ２０４）、取得したファイルのチェックサムを確認する（ステップＳ２０５）。

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

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

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

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

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

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

図１４は、本発明の実施の形態にかかる確認画面の一例を示す概念図（その２）である。アップデートの結果を受けたユーザインタフェース部１１０２は、図１４に示すように、Ｓ２０１〜Ｓ２０９によるアップデート結果Ｇ５１〜Ｇ５４や、アップデート後のシャットダウンや再起動の操作を受け付けるための操作ボタンＧ５５、Ｇ５６を確認画面Ｇ５に表示する。

図１４に示すように、アップデート結果画面Ｇ５１〜Ｇ５４ではそれぞれのバージョンのアップデート結果を表示する。バージョン「３.０１」、「３．０２」、「３．０３」は適用可能であるため、アップデートが完了した旨の文字列とアイコンの表示を行う。バージョン「３．０４」は適用可能ではないため、アップデート適用可能日時とダウンロードのみ完了した旨を示す文字列とアイコンの表示を行う。

この表示より、ユーザは各バージョンごとのアップデート結果を確認することができる。

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

＜変形例＞
ここでアップデート確認画面の変形例を示す。変形例は、現時点でアップデートの実行はできないが、今後アップデートの実行が可能になるアップデートにおいて、具体的にいつ実行が可能になるかわからない場合に、ユーザ通知部１１０４が表示するアップデートの確認画面について説明する。図１５、１６は、本発明の変形例に係る確認画面の一例を示す概念図（その１）および本発明の変形例に係る確認画面の一例を示す概念図（その２）である。

上述した例では、アップデートが実行になる日時がわかっている場合を示した。しかし、いつの時点でアップデートの実行が可能になるかという情報が常にあるとは限らない。例えば、通話端末１１に提供するアップデートデータの準備はできているが、サーバ側で当該アップデートデータに対応する時期が未確定な場合がありうる。その時、アップデートサーバ６０より"ｉｓＶａｌｉｄ"に"ｆａｌｓｅ"が設定されている場合、ユーザ通知部１１０４は、図１５、１６のように「現時点で適用不可」を表示させる。

このように本実施の形態では、アップデートの必要のあるアップデートデータ毎にアップデートに関する情報をユーザへ通知することができることにより、複数のアップデートデータが存在する場合においても、ユーザは、適用すべきアップデートデータ毎にダウンロードの進捗状況やアップデートの実行可能日時といったアップデートに関する情報を把握することができるという効果を奏する。

なお、上述の実施例の全部又は一部はプログラムによって実装され得る。このプログラムは、可搬記録媒体に格納することができる。可搬記録媒体とは、非一時的（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）な記憶媒体を言う。可搬記録媒体の例としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。

可搬型記録媒体に格納されたプログラムが読み出され、プロセッサーによって実行されることにより、本発明の実施例の全部又は一部が実施され得る。

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

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

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

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

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

Claims (4)

1. メタデータを受信する受信手段であって、前記メタデータは前記メタデータの受信時より後にアップデートの実行が可能なアップデートデータに関する情報を含む、受信手段と、
   前記メタデータにしたがって、前記メタデータに対応するアップデートデータのアップデートが実行可能か否かを通知する通知手段と
   を有することを特徴とした通信装置。
2. 請求項１に記載の通信装置であって、
   前記通知手段は、
   前記アップデートデータのアップデートが実行可能になる日時を通知することを
   特徴とした通信装置。
3. 請求項１又は２に記載の通信装置であって、
   アップデートの実行が可能か否かの情報をアイコンにて表示する表示手段と
   を有することを特徴とした通信装置。
4. メタデータを受信する受信ステップであって、前記メタデータは前記メタデータの受信時より後にアップデートの実行が可能なアップデートデータに関する情報を含む、受信ステップと、
   前記メタデータに対応するアップデートデータが実行可能か否かを通知する通知ステップと
   をコンピュータに実行させる通信プログラム。