JP6102378B2 - サーバ、情報処理システムおよびプログラム - Google Patents

Description

本発明は、サーバ、情報処理システムおよびプログラムに関する。

インターネット等の通信ネットワークを利用して、異なる場所（遠隔地）に設置された通信装置間において画像や音声を送受信することにより、異なる場所間において会議を行う会議システムが普及している。具体的には、会議システムは、会議に出席する出席者が居る一方の場所に設置された通信装置（情報処理装置の一例）を利用して、出席者などを含む会議室の撮像および出席者の発言等の音声の収集を行い、会議室の撮像により得られた画像および収集した音声をデジタルデータに変換して他方の場所に設置された通信装置に送信する。そして、当該他方の場所に設置された通信装置が、受信した画像を表示装置に表示させかつ受信した音声をスピーカから出力させる。これにより、会議システムは、一つの場所において行われる会議に近い状態で、異なる場所間での会議を行うことを可能にしている。

この会議システムにおいては、異なる場所に設置された通信装置間で送受信する情報（例えば、画像や音声など）の秘匿性能や当該会議システムの操作性能を向上させるために、各場所に設置された通信装置に記憶されたファームウェア（プログラム）のアップデートが定期的に行われる。そして、通信装置に記憶されたファームウェアをアップデートするアップデート方法としては、ファームウェアのアップデートに用いるアップデートデータと当該アップデートデータのメタデータとを、ネットワークを介して接続されたサーバからダウンロードし、当該ダウンロードしたメタデータに基づいてファームウェアのアップデートが必要か否かを判断し、アップデートが必要と判断された場合に、当該ダウンロードしたアップデートデータを用いてファームウェアのアップデートを実行する方法がある。

ところで、アップデートデータのダウンロードは、通常、アップデートが実行可能となる所定日時以降に可能となるが、アップデートデータのダウンロードによるサーバへのアクセスの集中を防止することを目的として、所定日時前にアップデートデータをダウンロードしておき、所定日時以降にダウンロード済みのアップデートデータを用いたファームウェアのアップデートを行わせることにより、アップデートデータがダウンロードされる時期を分散する技術が開示されている。

しかしながら、所定日時前にアップデートデータのダウンロードを行う技術によれば、アップデートデータをダウンロードするためのサーバへのアクセスが所定日時前に一斉に行われた場合、ダウンロードによってネットワークやサーバに負荷がかかる時期が前倒しされるだけで、ネットワークやサーバに負荷がかかる時期を分散することができず、サーバがダウンしたり、アップデートデータのダウンロードに要する時間が長くなったりするなど、ユーザの利便性が損なわれる可能性がある。

本発明は、上記に鑑みてなされたものであって、サーバやネットワークへのアクセスの集中を回避して効率的なデータのアップデートを実現するサーバ、情報処理システムおよびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、アップデートを実行する情報処理装置から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部と、アップデートデータの中に、アップデートが実行可能となる日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部と、判定部により事前ダウンロードデータが有ると判定された場合、事前ダウンロードデータに対応するメタデータを、情報処理装置に通信ネットワークを介して送信する送信部と、事前ダウンロードデータをダウンロード中の情報処理装置の数に基づいて、事前ダウンロードデータのメタデータの送信を禁止する禁止部と、を備えるサーバである。

本発明によれば、事前ダウンロードデータのダウンロードによりネットワークやサーバに負荷がかかる時期を分散させることができ、かつ当該事前ダウンロードデータを含むアップロードデータのダウンロードに要する時間が長くなる等によりユーザの利便性が損なわれることを防止できる、という効果を奏する。

図１は、第１の実施の形態にかかる遠隔通信システムの構成を例示する模式図である。 図２は、第１の実施の形態にかかる情報処理装置のハードウェア構成を示すブロック図である。 図３は、第１の実施の形態にかかる中継装置、遠隔通信管理サーバ、アップデートサーバのハードウェア構成を示すブロック図である。 図４は、第１の実施の形態にかかる情報処理装置およびアップデートサーバの機能構成を示すブロック図である。 図５は、第１の実施の形態にかかるアップデートサーバにおいてメタデータを送信する処理の流れを示すフローチャートである。 図６は、第１の実施の形態にかかる情報処理装置におけるアップデートの動作の流れを示すフローチャートである。 図７は、第１の実施の形態にかかるアップデートサーバから送信されるメタデータの一例を示す図である。 図８は、第１の実施の形態にかかる情報処理装置に表示される起動画面の一例を示す図である。 図９は、第１の実施の形態にかかる情報処理装置に表示される設定画面の一例を示す図である。 図１０は、第１の実施の形態にかかる情報処理装置に表示される確認画面の一例を示す図である。 図１１は、第１の実施の形態にかかる情報処理装置に表示される確認ウインドウの一例を示す図である。 図１２は、第１の実施の形態にかかる情報処理装置における事前ダウンロード処理の流れを示すフローチャートである。 図１３は、第１の実施の形態にかかる情報処理装置で表示される設定画面の一例を示す図である。 図１４は、第１の実施の形態にかかる情報処理装置に表示される確認画面の一例を示す図である。 図１５は、第１の実施の形態にかかる情報処理装置によるアップデート処理の流れを示すフローチャートである。 図１６は、第１の実施の形態にかかる情報処理装置に表示されるアップデート画面の一例を示す図である。 図１７は、第１の実施の形態にかかる情報処理装置により表示される確認画面の一例を示す図である。 図１８は、第２の実施の形態にかかる情報処理装置およびアップデートサーバの機能構成を示すブロック図である。 図１９は、第２の実施の形態にかかる情報処理装置の事前ダウンロード処理を停止する処理の流れを示すフローチャートである。

以下に添付図面を参照して、サーバ、情報処理システムおよびプログラムの実施の形態を詳細に説明する。

（第１の実施の形態）
図１は、第１の実施の形態にかかる遠隔通信システムの構成を例示する模式図である。図１に示すように、遠隔通信システム１（情報処理システムの一例）は、通信ネットワーク２により、情報処理装置１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、遠隔通信管理サーバ５０、アップデートサーバ６０およびルータ７０ａ〜７０ｄが通信可能に接続されている。具体的には、遠隔通信システム１は、ルータ７０ａ〜７０ｄを介してインターネット２ｉに接続されるＬＡＮ（Local Area Network）２ａ、２ｂ、２ｃ、２ｄ、遠隔通信管理サーバ５０およびアップデートサーバ６０と、ＬＡＮ２ａに接続する情報処理装置１１ａａ〜１１ａｃおよび中継装置３０ａと、ＬＡＮ２ｂに接続する情報処理装置１１ｂａ〜１１ｂｃおよび中継装置３０ｂと、ＬＡＮ２ｃに接続する情報処理装置１１ｃａ〜１１ｃｃおよび中継装置３０ｃと、ＬＡＮ２ｄに接続する情報処理装置１１ｄａ〜１１ｄｃおよび中継装置３０ｄと、を有する。

遠隔通信システム１では、遠隔通信管理サーバ５０の管理の下、地域Ａの情報処理装置１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、地域Ｂの情報処理装置１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃの各々が、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄを介して、互いに音声および画像を含む通信データを送受信することで通話を行う。

具体的には、遠隔通信管理サーバ５０は、情報処理装置１１ａａ〜１１ａｃ、１１ｂａ〜１１ｂｃ、１１ｃａ〜１１ｃｃ、１１ｄａ〜１１ｄｃ、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄなどの通信アドレス、中継装置３０ａ、３０ｂ、３０ｃ、３０ｄの各々が中継を行う情報処理装置、各情報処理装置の通話状態などの情報を記憶する。

例えば、情報処理装置１１ａａが情報処理装置１１ｃａと通話を行う場合は、情報処理装置１１ａａは、中継装置３０ａに情報処理装置１１ｃａへの通信データの中継を指示する。中継装置３０ａは、遠隔通信管理サーバ５０に情報処理装置１１ａａの通話の開始を通知するとともに、情報処理装置１１ｃａへの通信データを中継する中継装置３０ｃの通信アドレスを遠隔通信管理サーバ５０より取得する。次いで、中継装置３０ａは情報処理装置１１ｃａへの通信データの中継を中継装置３０ｃに指示し、中継装置３０ｃは、情報処理装置１１ｃａとの通信を開始する。次いで、中継装置３０ｃは、情報処理装置１１ｃａとの通信の開始を遠隔通信管理サーバ５０へ通知する。

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

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

アップデートサーバ６０は、情報処理装置１１のプログラムや各種設定情報のアップデートにかかる情報を記憶し、情報処理装置１１からの送信指示に応じてアップデートにかかる情報を送信する。アップデートにかかる情報としては、情報処理装置１１のプログラムや各種設定情報の過去のバージョンから最新のバージョンまでの全てのバージョンのデータファイルなどアップデートに用いるアップデートデータと、プログラムや各種設定情報の各バージョンのアップデートの内容などを含むアップデートデータのメタデータなどである。アップデートにかかる情報として全てのバージョンのデータファイルをアップデートサーバ６０が記憶しているのは、情報処理装置１１毎にアップデートを任意のタイミングで行えるようにするためである。

例えば、頻繁にアップデートを行っている情報処理装置１１は、最新のバージョンへのアップデートを行うだけでよいが、アップデートの間隔が長い情報処理装置１１は、何回かバージョンアップが繰り返された後にアップデートを行う可能性がある。このような場合は、直ちに最新のバージョンへアップデートせずに、最新のバージョンへアップデートするために必要な古いバージョン（最新のバージョンと依存関係にある古いバージョン）へのアップデートを経ることがある。そのため、アップデートサーバ６０は、アップデートにかかる情報として全ての（若しくは、最低限必要とされる）バージョンのデータファイルを記憶している。

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

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

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

次に、本実施の形態にかかる情報処理装置１１のハードウェア構成を説明する。図２は、第１の実施の形態にかかる情報処理装置のハードウェア構成を示すブロック図である。図２に示すように、情報処理装置１１は、ＣＰＵ（Central Processing Unit）１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、記憶部１０５、メディアドライブ１０７、操作部１０８、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３およびディスプレイＩ／Ｆ１１４を備え、各部がバス１１０により互いに接続されている。

ＣＰＵ１０１は、ＲＯＭ１０２に記憶されたプログラム（図示しない）や記憶部１０５に記憶されたプログラム１０４をＲＡＭ１０３に展開して順次実行することで、情報処理装置１１の動作を制御する。記憶部１０５は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などであり、ＣＰＵ１０１が実行するプログラム１０４や各種設定情報を記憶する。ＣＰＵ１０１は、アップデートの際、記憶部１０５に記憶されるプログラム１０４や各種設定情報をアップデート（更新）する。

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

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

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

次に、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０のハードウェア構成を説明する。図３は、第１の実施の形態にかかる中継装置、遠隔通信管理サーバ、アップデートサーバのハードウェア構成を示すブロック図である。図３に示すように、中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶部２０４、ディスプレイ２０５、ネットワークＩ／Ｆ２０６、キーボード２０７、マウス２０８、メディアドライブ２０９およびＣＤ−ＲＯＭドライブ２１１を備え、各部がバス２１４により互いに接続されている。中継装置３０、遠隔通信管理サーバ５０、アップデートサーバ６０は、いわゆるＰＣ（Personal Computer）やＷＳ（Work Station）などの機器である。

ＣＰＵ２０１は、ＲＯＭ２０２や記憶部２０４に記憶されたプログラムをＲＡＭ２０３に展開して順次実行することで、自装置の動作を制御する。記憶部２０４は、ＨＤＤやＳＳＤなどであり、アップデートにかかる情報などを記憶する。

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

次に、情報処理装置１１が備えるＣＰＵ１０１やアップデートサーバ６０が備えるＣＰＵ２０１がプログラムを実行することで実現される、情報処理装置１１およびアップデートサーバ６０の機能構成について説明する。図４は、第１の実施の形態にかかる情報処理装置およびアップデートサーバの機能構成を示すブロック図である。図４に示すように、情報処理装置１１は、送受信部１１０１、ユーザインタフェース部１１０２およびアップデート部１１０３を有している。アップデートサーバ６０は、送受信部６０１および禁止部６０２を有する。

まず、情報処理装置１１の機能構成について説明する。送受信部１１０１は、通信ネットワーク２を介してアップデートサーバ６０との間でデータの送受信を行う。具体的には、送受信部１１０１は、記憶部１０５の設定情報などに予め設定されているアップデートサーバ６０の通信アドレスや遠隔通信管理サーバ５０から取得したアップデートサーバ６０の通信アドレスをもとに、アップデートサーバ６０との間で所定の通信プロトコルを用いた通信を開始することで、アップデートサーバ６０との間でデータの送受信を行う。このデータの送受信により、送受信部１１０１は、アップデートサーバ６０が記憶しているアップデートにかかる情報を取得する。

ユーザインタフェース部１１０２は、スピーカ１５による音声の出力、ディスプレイ１３への各種情報の表示、操作部１０８によるユーザの操作入力の受け付けなどを制御して、ユーザと情報処理装置１１との間での情報のやりとりを制御するインタフェースである。具体的には、ユーザインタフェース部１１０２は、スピーカ１５による音声の出力やディスプレイ１３への各種情報の表示でユーザへの各種通知を行うとともに、操作部１０８によるユーザの操作入力を受け付ける。

アップデート部１１０３は、送受信部１１０１によりアップデートサーバ６０から取得したアップデートにかかる情報をもとに、記憶部１０５が記憶するプログラム１０４や各種設定情報のアップデートを実行する。

次に、アップデートサーバ６０の機能構成について説明する。送受信部６０１は、通信ネットワーク２を介して情報処理装置１１との間でデータの送受信を行う。具体的には、送受信部６０１は、通信ネットワーク２を介した情報処理装置１１からの要求に応じて所定の通信プロトコルを用いた通信セッションを開始することで、情報処理装置１１との間でデータの送受信を行う。

また、送受信部６０１は、アップデートサーバ６０が記憶しているアップデートにかかる情報が含むアップデートデータを情報処理装置１１に送信する。さらに、送受信部６０１は、アップデートサーバ６０が記憶しているアップデートにかかる情報が含むアップデートデータの中に、アップデートが実行可能となる所定日時（日時）が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部として機能する。そして、送受信部６０１は、事前ダウンロードデータが有ると判定された場合、事前ダウンロードデータに対応するメタデータを情報処理装置１１に通信ネットワーク２を介して送信する送信部として機能する。ここで、事前ダウンロードデータに対応するメタデータとは、事前ダウンロードデータを用いたアップデートが必要か否かを判断可能なデータであり、本実施の形態では、図７に示すメタデータに記述された“version”を含むメタデータである。

禁止部６０２は、送受信部６０１により事前ダウンロードデータをダウンロード（送信）中の情報処理装置１１の数（以下、装置数と言う）に基づいて、事前ダウンロードデータのメタデータの送信を禁止する。本実施の形態では、禁止部６０２は、送受信部６０１により事前ダウンロードデータをダウンロード中の情報処理装置１１の装置数が閾値以上である場合に、事前ダウンロードデータのメタデータの送信を禁止する。

次に、本実施の形態にかかるアップデートサーバ６０からメタデータを送信する際の当該アップデートサーバ６０の制御方法について説明する。図５は、第１の実施の形態にかかるアップデートサーバにおいてメタデータを送信する処理の流れを示すフローチャートである。

送受信部６０１は、情報処理装置１１からアップデートデータのメタデータの送信を指示する送信指示を受信する（ステップＳ５０１）。本実施の形態では、送受信部６０１が、アップデートを実行する情報処理装置１１から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部として機能する。アップデートデータのメタデータの送信指示を受信すると、送受信部６０１は、記憶部２０４に記憶されたアップデートデータのメタデータのうち、アップデートを実行可能なアップデートデータのメタデータを取得する（ステップＳ５０２）。本実施の形態では、送受信部６０１は、記憶部２０４に記憶されたアップデートデータのメタデータのうち、当該メタデータが含むアップデートが実行可能となる所定日時である“valid date”（図７参照）が現在日時より前のメタデータを、アップデートを実行可能なアップデートデータのメタデータとして取得する。また、本実施の形態では、送受信部６０１は、例えばＮＴＰ（Network Time Protocol）サーバ、アップデートサーバ６０が備える時計などから、現在日時を取得するものとする。

次に、送受信部６０１は、記憶部２０４に記憶されたアップデートデータのメタデータの中に、事前ダウンロードデータのメタデータがあるか否かを判断する（ステップＳ５０３）。本実施の形態では、送受信部６０１は、記憶部２０４に記憶されたアップデートデータのメタデータのうち、当該メタデータが含むアップデートが実行可能となる所定日時である“valid date”（図７参照）が現在日時（例えば、ＮＴＰサーバやアップデートサーバ６０が備える時計から取得した現在日時）より後のメタデータを、事前ダウンロードデータのメタデータとして取得する。これにより、送受信部６０１は、アップデートサーバ６０が記憶しているアップデートにかかる情報が含むアップデートデータの中に、アップデートが実行可能となる所定日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する。

そして、事前ダウンロードデータのメタデータがある場合（ステップＳ５０３：Ｙｅｓ）、すなわち、事前ダウンロードデータが有ると判定された場合、禁止部６０２は、送受信部６０１により送信された事前ダウンロードデータをダウンロード中の情報処理装置１１の数である装置数が閾値より少ないか否かを判断する（ステップＳ５０４）。本実施の形態では、禁止部６０２は、単位時間当り（例えば、１０分間当りなど）の装置数が閾値（例えば、１００台）より少ないか否かを判断する。より具体的には、禁止部６０２は、単位時間毎に、事前ダウンロードデータへのアクセス数を装置数として計数する。ここで計数される装置数には、事前ダウンロードデータをダウンロード中の情報処理装置１１の数に加え、事前ダウンロードデータのダウンロードは開始していないが事前ダウンロードデータへのアクセスを行った情報処理装置１１（すなわち、事前ダウンロードデータをダウンロード前の情報処理装置１１）の数が含まれる。そして、禁止部６０２は、計数した装置数が閾値より少ないか否かを判断する。

事前ダウンロードデータをダウンロード中の情報処理装置１１の装置数が閾値より少ない場合（ステップＳ５０４：Ｙｅｓ）、送受信部６０１は、記憶部２０４に記憶された事前ダウンロードデータのメタデータを取得する（ステップＳ５０５）。そして、送受信部６０１は、ステップＳ５０２で取得したメタデータ（アップデートを実行可能なアップデートデータのメタデータ）とともに、ステップＳ５０５で取得した事前ダウンロードデータのメタデータを、メタデータの送信指示の送信元の情報処理装置１１に送信する（ステップＳ５０６）。本実施の形態では、送受信部６０１は、アップデートを実行可能なアップデートデータのメタデータとともに、事前ダウンロードデータを送信しているが、少なくとも事前ダウンロードデータを送信するものであれば良い。ここで、送信するメタデータは、少なくとも、事前ダウンロードデータを用いたアップデートが必要か否かを判断可能なデータ（本実施の形態では、図７に示すメタデータに記述された“version”）を含む。

一方、事前ダウンロードデータをダウンロード中の情報処理装置１１の装置数が閾値以上である場合（ステップＳ５０３：Ｎｏ）、禁止部６０２は、事前ダウンロードデータのメタデータの送信を禁止する（ステップＳ５０７）。本実施の形態では、禁止部６０２は、事前ダウンロードデータをダウンロード中の情報処理装置１１の装置数（例えば、１１０台）が閾値（例えば、１００台）以上である場合、記憶部２０４に記憶された事前ダウンロードデータのメタデータの取得を禁止することにより、事前ダウンロードデータのメタデータの送信を禁止する。そして、送受信部６０１は、ステップＳ５０２で取得したメタデータ（アップデートを実行可能なアップデートデータのメタデータ）のみを、メタデータの送信指示の送信元の情報処理装置１１に送信する（ステップＳ５０６）。

これにより、計数した装置数が閾値に達した場合（すなわち、事前ダウンロードデータを含むアップデートデータのダウンロードにより通信ネットワーク２やアップデートサーバ６０に負荷がかかっている場合）には、事前ダウンロードデータのメタデータが情報処理装置１１に送信されず、当該情報処理装置１１のユーザから事前ダウンロードデータの送信（ダウンロード）が指示されなくなるので（言い換えると、事前ダウンロードへのアクセスが所定日時前に一斉に行われることを防止できるので）、事前ダウンロードデータのダウンロードにより通信ネットワーク２やアップデートサーバ６０に負荷がかかる時期を分散させることができ、かつ当該事前ダウンロードデータを含むアップロードデータのダウンロードに要する時間が長くなるなどによりユーザの利便性が損なわれることを防止できる。

次に、本実施の形態にかかる情報処理装置１１におけるアップデートの動作を説明する。図６は、第１の実施の形態にかかる情報処理装置におけるアップデートの動作の流れを示すフローチャートである。

ユーザインタフェース部１１０２は、操作部１０８の電源スイッチなどの操作に応じて自装置の電源オンを行うとともに（ステップＳ６１０）、起動画面をディスプレイ１３に表示させる（ステップＳ６１１）。この起動画面は、ＣＰＵ１０１の制御の下で遠隔通信管理サーバ５０から取得した各情報処理装置１１の通話状態を一覧表示した表示画面である。

アップデート部１１０３は、自装置の電源オンが行われると、アップデートの確認を開始する（ステップＳ６１２）。ここで、アップデートの確認とは、自装置のプログラム１０４や各種設定情報が最新のバージョンにアップデートされているか否かを判定する処理である。以下の説明では、自装置のプログラム１０４のアップデートを確認する例について説明するが、各種設定情報のアップデートの確認も同様にして行われる。

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

ここで、メタデータの詳細について説明する。図７は、第１の実施の形態にかかるアップデートサーバから送信されるメタデータの一例を示す図である。図７に示すように、各バージョンのメタデータは、“version”、“dependency”、“description”、“files”、“scriptname”、“require＿reboot”、“force＿update”、“valid date”、“data size”などのデータ項目を含む。

“version”は、アップロードデータ（事前アップロードデータ）を用いたアップデートが必要か否かを判断可能なデータであり、本実施の形態では、“1.0.1”などのアップロードデータのバージョン番号が記述される。“dependency”には、“1.0.0”などの、互いに依存関係を有する他のバージョンを示すバージョン番号が記述される。したがって、“dependency”のデータ項目に記述されたバージョン番号を確認することで、依存関係にあるバージョンを検出することができる。“description”には、“It is sample data.”などのバージョンの詳細が記述される。“files”には、アップデートサーバ６０に記憶されているアップデートに用いるアップデートデータ（データファイル）のリストとその格納先や、それらデータファイルのチェックサムなどが記述される。したがって、アップデート部１１０３は、“files”のデータ項目に記述された内容を基に、送受信部１１０１によってデータファイルを取得することで、メタデータに記述されたバージョンにかかるアップデートの実行が可能となる。“scriptname”には、アップデートを実行する際に実行するスクリプト名が記述される。“require＿reboot”には、アップデートを実行した後に、装置の再起動を行うか否かを示すフラグ（“true”または“false”）が記述される。“force＿update”には、強制のアップデートであるか否かを示すフラグ（“true”または“false”）が記述される。“valid date”には、“201209151200”など、メタデータに記述されたバージョンのデータファイルを用いたアップデートが実行可能となる日時（所定日時）が記述される。“data size”には、メタデータに記述されたバージョンのデータファイルのデータ量が記述される。

プログラム１０４のアップデートには、ネットワークＩ／Ｆ１１１、撮像素子Ｉ／Ｆ１１２、音声入出力Ｉ／Ｆ１１３、ディスプレイＩ／Ｆ１１４等の制御（以下、デバイス制御という）にかかるものがある。このようなデバイス制御のアップデートでは、アップデート後に再起動が必要となることから、“require＿reboot”に“true”が記述される。また、プログラム１０４のアップデートには、上述したように、通常アップデートと強制アップデートがあり、強制アップデートを行う場合には、“force＿update”に“true”が記述される。

次いで、アップデート部１１０３は、取得したメタデータの“dependency”のデータ項目に記述された内容を基に、依存関係を有する他のバージョンの有無を検出する（ステップＳ６１５）。例えば、図７に示すように、“dependency”のデータ項目に“1.0.0”などの他のバージョンを示すバージョン番号が記述されている場合には、依存関係を有する他のバージョンがあることを検出する。また、“dependency”のデータ項目に何も記述がない場合には、依存関係を有する他のバージョンがないと判断する。

次いで、アップデート部１１０３は、依存関係を有する他のバージョンが有ることを検出した場合（ステップＳ６１６：Ｙｅｓ）、送受信部１１０１によって、依存関係を有する他のバージョンのデータファイルのメタデータの送信指示をアップデートサーバ６０に対して送信する（ステップＳ６１７）。送受信部１１０１は、その送信指示に応じてアップデートサーバ６０から送信された、依存関係を有する他のバージョンのメタデータを取得する（ステップＳ６１８）。したがって、アップデート部１１０３は、最新バージョンと依存関係を有する他のバージョンへ順次遡って、当該他のバージョンのメタデータを取得する。

次いで、アップデート部１１０３は、最新バージョンのデータファイルのメタデータののうち“valid date”に記述された日時が現在日時より前のメタデータの“version”に記述されたバージョン番号と、記憶部１０５に記憶されたプログラム１０４のバージョン番号とを比較することで、プログラム１０４がアップデート済みか否か（アップロードデータを用いたプログラム１０４のアップデートが必要か否か）を判定する（ステップＳ６１９）。本実施の形態では、アップデート部１１０３は、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致する場合は、プログラム１０４が最新バージョンであることから、プログラム１０４をアップデート済みと判定する。一方、アップデート部１１０３は、最新バージョンのバージョン番号と、プログラム１０４のバージョン番号とが一致しない場合は、プログラム１０４が古いバージョンであることから、アップデート済みでないと判定する。

アップデート済みでないと判定した場合（ステップＳ６１９：Ｎｏ）、すなわち、アップデートが必要と判断した場合、アップデート部１１０３は、そのアップデートに関する情報（以下、アップデート情報という）をユーザインタフェース部１１０２へ通知する（ステップＳ６２０）。本実施の形態では、アップデート部１１０３は、最新バージョンおよびその最新バージョンと依存関係を有する他のバージョンのデータファイルのメタデータのうち、“files”、“scriptname”などのユーザへの通知に不要なデータ項目以外のデータ項目を、アップデート情報としてユーザインタフェース部１１０２へ通知する。

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

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

また、ユーザインタフェース部１１０２は、アップデート情報として含まれるデータ項目の中で“force＿update”の記述が“true”である場合は、自装置に存在するアップデートが強制アップデートであることを起動画面Ｇ１に表示してユーザに通知する。例えば、ユーザインタフェース部１１０２は、アップデートが強制アップデートである旨をステータス画面Ｇ１２に表示してもよいし、主画面Ｇ１１に表示されている一覧表示をグレーアウトするなどして、アップデート以外の操作が無効であることを通知してもよい。

次いで、操作部１０８からアップデートの実行指示や各種設定を行うための操作指示が入力された場合、ユーザインタフェース部１１０２は、設定画面をディスプレイ１３に表示させる（ステップＳ６２２）。

図９は、第１の実施の形態にかかる情報処理装置に表示される設定画面の一例を示す図である。図９に示すように、設定画面Ｇ２は、ユーザインタフェース部１１０２によりユーザの操作を受け付けて、アップデートの実行指示および各種設定を行うための設定ボタンＧ２３〜Ｇ２６を表示する主画面Ｇ２１を含む。設定ボタンＧ２３〜Ｇ２６の中で設定ボタンＧ２６がアップデートの実行を指示するためのボタンである。

ユーザインタフェース部１１０２は、アップデート情報がアップデート部１１０３より通知されず、アップデートが必要なプログラム（ファームウェア）が存在しない場合には、グレーアウトするなどして、設定ボタンＧ２６を操作できないようにする。一方、ユーザインタフェース部１１０２は、アップデート情報がアップデート部１１０３より通知され、アップデートが必要なプログラムが存在する場合には、グレーアウトが解除され、設定ボタンＧ２６の操作を可能とする。設定ボタンＧ２６には、アップデート情報として含まれるデータ項目の“version”の記述を基に、アップデートが行われる最新バージョンのバージョン番号などを含めても良い。図９に示す設定ボタンＧ２６には、バージョン番号が2.0の最新バージョンにアップデート可能であることが記載されている。ユーザインタフェース部１１０２は、設定画面Ｇ２に、自装置のステータスを表示するステータス画面を表示しても良い。

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

図１０は、第１の実施の形態にかかる情報処理装置に表示される確認画面の一例を示す図である。図１０に示すように、確認画面Ｇ３は、実行するアップデートの内容を表示するアップデート表示Ｇ３３と、その内容でのアップデートの実行またはキャンセルの指示をユーザより受け付けるための操作ボタンＧ３４，Ｇ３５とを含む主画面Ｇ３１と、自装置のステータスを表示するステータス画面Ｇ３２とを含む。アップデート表示Ｇ３３には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、アップデート情報に含まれるデータ項目の“version”の記述を基にした、アップデートが行われる最新バージョンのバージョン番号などの情報が表示される。ユーザは、アップデート表示Ｇ３３の表示内容により、どのバージョン番号へのアップデートが行われるかを確認できる。確認画面Ｇ３のアップデート表示Ｇ３３には、再起動が行われるか否かの情報を表示しても良い。

図１１は、第１の実施の形態にかかる情報処理装置に表示される確認ウインドウの一例を示す図である。本実施の形態では、ユーザインタフェース部１１０２は、確認画面Ｇ３においてアップデートの実行を指示する操作ボタンＧ３５が操作された場合、アップデートの実行の確認を促す確認ウインドウＧ３６を表示する。確認ウインドウＧ３６には、アップデートが行われる最新バージョンのバージョン番号などの情報の他、予め設定されたアップデート時の注意事項などを表示する。確認画面Ｇ３においてアップデートの実行が指示された場合に確認ウインドウＧ３６を表示することで、ユーザへの注意喚起を促すことができる。ユーザインタフェース部１１０２は、再起動が行われるか否かの情報を確認ウィンドウＧ３６に表示しても良い。

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

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

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

また、ステップＳ６１９において、最新バージョンのデータファイルのメタデータのうち“valid date”に記述された日時が現在日時より前のメタデータの“version”に記述されたバージョン番号と、プログラム１０４のバージョン番号とが一致して、プログラム１０４が最新バージョンにアップデート済みであると判断された場合（ステップＳ６１９：Ｙｅｓ）、すなわち、アップデートが不要と判断した場合、アップデート部１１０３は、最新バージョンのデータファイルのメタデータの“valid date”に基づいて、事前ダウンロードデータが有るか否かを判断する（ステップＳ６２９）。そして、アップデート部１１０３は、最新バージョンのデータファイルのメタデータの“valid date”に記述された日時が現在日時以降の日時である場合には、事前ダウンロードデータが有ると判断して（ステップＳ６２９：Ｙｅｓ）、事前ダウンロードデータをダウンロードする事前ダウンロード処理を実行する（ステップＳ６３０）。

一方、最新バージョンのデータファイルのメタデータの“valid date”に記述された日時が現在日時より前の日時である場合には、アップデート部１１０３は、事前ダウンロードデータが無いと判断して（ステップＳ６２９：Ｎｏ）、通常の動作を継続させる（ステップＳ６２８）。

次に、図１２を用いて、事前ダウンロード処理の詳細について説明する。図１２は、第１の実施の形態にかかる情報処理装置における事前ダウンロード処理の流れを示すフローチャートである。

アップデート部１１０３は、事前ダウンロードデータがあると判断した場合（ステップＳ６２９：Ｙｅｓ）、事前ダウンロードデータに関する情報（例えば、“valid date”に記述された日時が現在日時以降の日時のメタデータのうち、“files”、“scriptname”などのユーザへの通知に不要なデータ項目以外のデータ項目を、事前ダウンロードデータに関する情報としてユーザインタフェース部１１０２へ通知する（ステップＳ１２０１）。

事前ダウンロードデータに関する情報が通知されると、ユーザインタフェース部１１０２は、事前ダウンロードデータに関する情報を用いて、設定画面をディスプレイ１３に表示させる（ステップＳ１２０２）。図１３は、第１の実施の形態にかかる情報処理装置で表示される設定画面の一例を示す図である。図１３に示すように、設定画面Ｇ４には、ユーザインタフェース部１１０２によりユーザの操作を受け付けて、事前ダウンロード処理の実行指示および各種設定を行うための設定ボタンＧ２３〜Ｇ２５，Ｇ４２を表示する主画面Ｇ４１を含む。設定ボタンＧ２３〜Ｇ２５，Ｇ４２の中で設定ボタンＧ４２が事前ダウンロード処理の実行を指示するためのボタンである。設定ボタンＧ４２には、事前ダウンロードデータに関する情報に含まれるデータ項目の“version”の記述を基に、事前ダウンロード処理を実行する最新バージョンのバージョン番号などを含めても良い。図１３に示す設定ボタンＧ４２には、バージョン番号が2.1の最新バージョンの事前ダウンロード処理が実行可能であることが記載されている。

設定ボタンＧ４２の操作が行われた場合、ユーザインタフェース部１１０２は、事前ダウンロード処理の実行を確認する確認画面をディスプレイ１３に表示させる（ステップＳ１２０３）。図１４は、第１の実施の形態にかかる情報処理装置に表示される確認画面の一例を示す図である。図１４に示すように、確認画面Ｇ５は、実行する事前ダウンロード処理の内容を表示する事前ダウンロード表示Ｇ５１と、その内容での事前ダウンロード処理の実行またはキャンセルの指示をユーザより受け付けるための操作ボタンＧ５２，Ｇ５３と、を含む。事前ダウンロード表示Ｇ５１には、自装置のプログラム１０４のバージョン番号である現在のバージョンの他、事前ダウンロードデータに関する情報に含まれるデータ項目の“version”の記述を基にした、事前ダウンロード処理が実行される最新バージョンのバージョン番号などの情報が表示される。ユーザは、事前ダウンロード表示Ｇ５１の表示内容により、どのバージョン番号の事前ダウンロードデータのダウンロードが行われるかを確認できる。

アップデート部１１０３は、確認画面Ｇ５での操作ボタンＧ５２，Ｇ５３の操作を基に、事前ダウンロード処理を実行するか否かを判定する（ステップＳ１２０４）。事前ダウンロード処理の実行を指示する操作ボタンＧ５３が選択された場合（ステップＳ１２０４：Ｙｅｓ）、アップデート部１１０３は、取得しているメタデータのうち“valid date”に記述された日時が現在日時以降のメタデータ（すなわち、事前ダウンロードデータのメタデータ）を基に、事前ダウンロードデータ（アップデートデータ）のダウンロードを実行する（ステップＳ１２０５）。

次に、図１５を用いて、アップデート処理（図６に示すステップＳ６２５）の詳細について説明する。図１５は、第１の実施の形態にかかる情報処理装置によるアップデート処理の流れを示すフローチャートである。

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

次いで、アップデート部１１０３は、取得したメタデータの“files”からアップデートに用いるデータファイル（アップデートデータ）のファイルリストと、それらファイルのチェックサムとを取得する（ステップＳ１５０１）。依存関係を有する複数のバージョンのメタデータを取得している場合、アップデート部１１０３は、バージョン番号が古いものから順にステップＳ１５０１〜Ｓ１５０８の処理を行う。

次いで、アップデート部１１０３は、取得したメタデータの“valid date”に記述されたアップデートが実行可能となる日時に基づいて、取得したメタデータに対応するデータファイル（アップデートデータ）を用いたアップデートが実行可能か否かを判断する（ステップＳ１５０２）。本実施の形態では、アップデート部１１０３は、取得したメタデータの“valid date”に記述された日時が、例えばＮＴＰサーバまたは自装置が備える計時部などから取得した現在日時よりも以前の日時である場合には、取得したメタデータに対応するデータファイル（アップデートデータ）を用いたアップデートが実行可能であると判断する。

取得したメタデータに対応するデータファイルを用いたアップデートが実行可能であると判断した場合（ステップＳ１５０２：Ｙｅｓ）、アップデート部１１０３は、当該取得したメタデータに対応するデータファイルが事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みであるか否か、すなわち、当該取得したメタデータに対応するデータファイルが事前ダウンロードデータであるか否かを判断する（ステップＳ１５０３）。

事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みでないと判断した場合（ステップＳ１５０３：Ｎｏ）、アップデート部１１０３は、ステップＳ１５０１で取得したファイルリストのデータファイル（アップデートデータ）をアップデートサーバ６０から取得するとともに（ステップＳ１５０４）、取得したデータファイルのチェックサムを取得する（ステップＳ１５０５）。一方、事前ダウンロード処理によりアップデートサーバ６０からダウンロード済みであると判断した場合（ステップＳ１５０３：Ｙｅｓ）、アップデート部１１０３は、事前ダウンロード処理によりダウンロード済みのデータファイル（事前ダウンロードデータ）をダウンロード先（例えば、記憶部１０５）から取得し、取得したデータファイルのチェックサムを取得する。次いで、アップデート部１１０３は、取得したデータファイルを用いて、記憶部１０５に記憶されたプログラム１０４のアップデートを実行する。

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

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

また、ユーザインタフェース部１１０２は、アップデート画面Ｇ６に、アップデートの残り時間や現在の回線速度をリアルタイムで表示するようにしてもよい。この場合には、ユーザにアップデートの状況をより詳細に把握させることができるという利点がある。

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

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

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

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

次いで、アップデート部１１０３は、アップデートに用いたアップデートデータのメタデータに含まれる、“require＿reboot”の記述を基に、情報処理装置１１の再起動が必要であるか否かを判定する（ステップＳ１５１０）。情報処理装置１１の再起動が必要でない場合（ステップＳ１５１０：Ｎｏ）、アップデート部１１０３は、情報処理装置１１を再起動することなくアップデート処理を終了する。情報処理装置１１の再起動が必要である場合（ステップＳ１５１０：Ｙｅｓ）、アップデート部１１０３は、情報処理装置１１を再起動させる（ステップＳ１５１１）。このように、再起動が必要なアップデートが実行された場合は、ユーザが操作することなく、アップデート後に再起動されることとなる。

このように本実施の形態にかかるアップデートサーバ６０によれば、アップデートに用いるアップデータのうちアップデートが実行可能となる所定日時よりも前にダウンロードが実行可能な事前ダウンロードデータへのアクセスが当該所定日時前に一斉に行われることを防止できるので、事前ダウンロードデータのダウンロードにより通信ネットワーク２やアップデートサーバ６０に負荷がかかる時期を分散させることができ、かつ当該事前ダウンロードデータを含むアップロードデータのダウンロードに要する時間が長くなる等によりユーザの利便性が損なわれることを防止できる。

（第２の実施の形態）
本実施の形態は、事前ダウンロード処理の実行中に他の情報処理装置との通話（例えば、テレビ会議など）が開始された場合に、事前ダウンロード処理を停止させる例である。以下の説明では、第１の実施の形態と異なる箇所について説明を行う。

図１８は、第２の実施の形態にかかる情報処理装置およびアップデートサーバの機能構成を示すブロック図である。本実施の形態にかかる情報処理装置１８００は、送受信部１１０１、ユーザインタフェース部１１０２、アップデート部１１０３およびアプリケーション状態監視部１８０１を有している。また、アップデートサーバ６０は、送受信部６０１および禁止部６０２を有している。

アプリケーション状態監視部１８０１は、情報処理装置１８００で実行されるアプリケーションの実行状態を監視する。そして、アプリケーション状態監視部１８０１は、アップデート部１１０３による事前ダウンロード処理（図６に示すステップＳ６３０）の実行中に、情報処理装置１８００で実行されるアプリケーションのうち他の情報処理装置との通信（通話）が開始された場合、アップデート部１１０３による事前ダウンロード処理を停止させる。

次に、本実施の形態にかかる情報処理装置１８００における事前ダウンロード処理を停止する動作の詳細を説明する。図１９は、第２の実施の形態にかかる情報処理装置の事前ダウンロード処理を停止する処理の流れを示すフローチャートである。

アプリケーション状態監視部１８０１は、アップデート部１１０３による事前ダウンロード処理が開始されると（ステップＳ１９０１）。他の情報処理装置の通信状態（例えば、テレビ会議などによる通話）を監視する。そして、アプリケーション状態監視部１８０１は、他の情報処理装置との通信が開始された場合、当該他の情報処理装置との通信が開始されたことをアップデート部１１０３に通知して（ステップＳ１９０２）、当該アップデート部１１０３による事前ダウンロード処理の実行を停止させる（ステップＳ１９０３）。

その後、アプリケーション状態監視部１８０１は、他の情報処理装置との通信が終了した場合、当該他の情報処理装置との通信が終了したことをアップデート部１１０３に通知して（ステップＳ１９０４）、当該アップデート部１１０３による事前ダウンロード処理の実行を再開させる（ステップＳ１９０５）。

このように本実施の形態にかかる情報処理装置１８００によれば、通信ネットワーク２を介して接続された外部機器（異なる地域に設置された情報処理装置）と通信可能な情報処理装置１８００であって、通信ネットワーク２を介して接続されたアップデートサーバ６０から、アップデートに用いるアップデートデータのうち、アップデートが実行可能となる所定日時が現在日時より後のアップデートデータである事前ダウンロードデータを取得し、事前ダウンロードデータの取得中に外部機器との通信が開始された場合、事前ダウンロードデータの取得を停止させることにより、ビデオ会議などにより異なる地域に設置された情報処理装置１８００間において音声や画像の通信データを送受信する場合に、事前ダウンロードデータのダウンロードにより通信ネットワーク２のネットワーク帯域が消費されてしまい、事前ダウンロードデータのダウンロードが情報処理装置１８００間における通信品質に影響を及ぼすことを防止できる。

本実施形態のアップデートサーバ６０および情報処理装置１１（１８００）で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、本実施形態のアップデートサーバ６０および情報処理装置１１（１８００）で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態のアップデートサーバ６０および情報処理装置１１（１８００）で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

なお、本実施の形態は、本発明の範囲を限定するものではなく、アップデートサーバ６０が、アップデートを実行する情報処理装置１１から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信機能と、アップデートデータの中に事前ダウンロードデータが有るか否かを判定する判定機能と、事前ダウンロードデータのメタデータを送信する送信機能と、事前ダウンロードデータのメタデータの送信を禁止する禁止機能とを備えていても良いし、アップデートサーバ６０以外のサーバ若しくは遠隔通信システム１が備える情報処理装置１１のいずれかが、受信機能と判定機能と送信機能と禁止機能とを備えていても良い。また、アップデートサーバ６０を構成するサーバは複数台でも良く、当該複数台のサーバのうちどのサーバに受信機能と判定機能と送信機能と禁止機能とを備えさせても良い。さらに、本実施の形態で説明する情報処理装置１１と、遠隔通信管理サーバ５０と、アップデートサーバ６０と、が接続されたシステム構成は一例であり、用途や目的に応じて様々なシステム構成例があることは言うまでもない。

１１，１８００ 情報処理装置
６０ アップデートサーバ
１０１，２０１ ＣＰＵ
１０２，２０２ ＲＯＭ
１０３，２０３ ＲＡＭ
１０５，２０４ 記憶部
１１１，２０６ ネットワークＩ／Ｆ
６０１，１１０１ 送受信部
６０２ 禁止部
１１０２ ユーザインタフェース部
１１０３ アップデート部
１８０１ アプリケーション状態監視部

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

Claims (7)

1. アップデートを実行する情報処理装置から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部と、
   アップデートデータの中に、アップデートが実行可能となる日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部と、
   前記判定部により事前ダウンロードデータが有ると判定された場合、前記事前ダウンロードデータに対応するメタデータを、前記情報処理装置に通信ネットワークを介して送信する送信部と、
   前記事前ダウンロードデータをダウンロード中の情報処理装置の数に基づいて、前記事前ダウンロードデータのメタデータの送信を禁止する禁止部と、
   を備えたサーバ。
2. 前記禁止部は、単位時間当りの前記情報処理装置の数が閾値以上である場合、前記事前ダウンロードデータのメタデータの送信を禁止する請求項１に記載のサーバ。
3. 前記送信部は、アップデートデータのうち、所定日時を経過したアップデートデータのメタデータとともに、前記事前ダウンロードデータのメタデータを前記情報処理装置に送信する請求項１または２に記載のサーバ。
4. アップデートを実行する情報処理装置から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部と、
   アップデートデータの中に、アップデートが実行可能となる日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部と、
   前記判定部により事前ダウンロードデータが有ると判定された場合、前記事前ダウンロードデータに対応するメタデータを、前記情報処理装置に通信ネットワークを介して送信する送信部と、
   前記事前ダウンロードデータをダウンロード中の情報処理装置の数に基づいて、前記事前ダウンロードデータのメタデータの送信を禁止する禁止部と、
   を備えた情報処理システム。
5. アップデートを実行する情報処理装置から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部と、アップデートデータの中に、アップデートが実行可能となる日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部と、前記判定部により事前ダウンロードデータが有ると判定された場合、前記事前ダウンロードデータに対応するメタデータを、前記情報処理装置に通信ネットワークを介して送信する送信部と、前記事前ダウンロードデータをダウンロード中の情報処理装置の数に基づいて、前記事前ダウンロードデータのメタデータの送信を禁止する禁止部と、としてコンピュータを機能させるためのプログラムと、
   前記送信部により送信された前記メタデータに基づいて、前記事前ダウンロードデータのダウンロードを行う前記情報処理装置と、
   を備えた情報処理システム。
6. 前記情報処理装置は、前記通信ネットワークを介して接続された外部機器と通信可能であり、前記事前ダウンロードデータのダウンロード中に前記外部機器との通信が開始された場合、前記事前ダウンロードデータのダウンロードを停止させる請求項５に記載の情報処理システム。
7. コンピュータを、
   アップデートを実行する情報処理装置から、アップデートに用いるアップデートデータのメタデータの送信指示を受信する受信部と、
   アップデートデータの中に、アップデートが実行可能となる日時が現在日時より後のアップデートデータである事前ダウンロードデータが有るか否かを判定する判定部と、
   前記判定部により事前ダウンロードデータが有ると判定された場合、前記事前ダウンロードデータに対応するメタデータを、前記情報処理装置に通信ネットワークを介して送信する送信部と、
   前記事前ダウンロードデータをダウンロード中の情報処理装置の数に基づいて、前記事前ダウンロードデータのメタデータの送信を禁止する禁止部と、
   として機能させるためのプログラム。

Images