JP4635558B2

JP4635558B2 - バックアップサ−バ装置ならびにプログラム

Info

Publication number: JP4635558B2
Application number: JP2004312013A
Authority: JP
Inventors: 伸吾小俣
Original assignee: Casio Computer Co Ltd
Current assignee: Casio Computer Co Ltd
Priority date: 2004-10-27
Filing date: 2004-10-27
Publication date: 2011-02-23
Anticipated expiration: 2024-10-27
Also published as: JP2006127003A

Description

この発明は、画像処理装置にネットワークを介して接続されているバックアップサーバ装置ならびにプログラムに関する。

従来、画像データをバックアップする技術としては、ハードディスクに記録された画像データをサーバに定期的に送信してバックアップした後、ハードディスク内の画像ファイルが破損した際には、サーバから画像データを取得して復元するようにしたハードディスクレコーダが知られている（特許文献１参照）。
特開２００４−２１６３４号公報

しかしながら、上述した特許文献の技術にあっては、画像データをネットワーク経由でバックアップすることができるが、画像データのように大容量のデータをサーバに送信する場合、ネットワークが混雑していると、その込み具合によってはアップロード時間が相当長くなったり、バックアップ中に通信異常が発生したり、タイムアウトによるバックアップの失敗を招くという問題があった。

ところで、一般に、各種のサービスを提供している企業側のサーバ装置に対して、インターネット経由で顧客端末からデータをアップロードする場合、インターネットサービスプロバイダ間でのトラフィックがボトルネックとなったり、サービス提供企業が契約しているバックボーンの容量不足がボトルネックとなって、通信障害が発生することがある。このような場合、サービス提供企業は多数の顧客からのアクセス集中によるボトルネックを解消するためにバックボーン容量を頻繁に増強するようにしているが、顧客数およびアクセスの集中度合いは刻々と変化し、将来予測の下、膨大な費用をかけて通信設備を増強したとしても無駄な出費となるケースも多く、どの程度の通信設備で足りるかの判断は、極めて困難を伴うものであった。

本発明の課題は、画像処理装置からアップロードされたバックアップ対象の画像データを保管するバックアップサーバ装置において、アップロード要求を受けた時点のトラフィック状況に基づいてアップロードを即座に許可するか、トラフィック履歴を考慮した日時に制限するかを制御できるようにすることである。

本発明は、バックアップ対象の画像データを記録処理する画像処理装置にネットワークを介して接続されているバックアップサーバ装置であって、過去のトラフィック状況をトラフィック履歴として記憶管理するトラフィック履歴記憶手段と、前記画像処理装置からバックアップ要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別する判別手段と、この判別手段によって実行可能であると判別された場合には、現時点でのアップロードを許可し、実行不可能であると判別された場合には、前記トラフィック履歴を参照してトラフィック状況の少ない日時をアップロードの実行開始日時とするためのスケジュール情報を特定して要求元の画像処理装置に送信することによって現時点でのアップロードを制限するアップロード制御手段とを具備し、前記アップロード実行開始日時に前記画像処理装置からアップロードされた画像データをバックアップデータとして保管するようにしたことを特徴とする。
さらに、コンピュータに対して、上述した請求項１記載の発明に示した主要機能を実現させるためのプログラムを提供する（請求項２記載の発明）。

本発明によれば、アップロード要求を受けた時点のトラフィック状況に基づいてアップロードを即座に許可するか、トラフィック履歴を考慮した日時に制限するかを制御することができ、通信設備を増強しなくても、トラフィック発生時、通信障害時などのようにアップロードが困難な状態下でのアップロードを回避することができ、画像データを円滑かつ正確にバックアップすることが可能となり、通信設備費の過剰投資を抑えることができる。

（実施例１）
以下、図１〜図９を参照して本発明の第１実施例を説明する。
図１は、この実施例における画像データバックアップシステムの全体構成の概要を示したブロック図である。
このデータバックアップシステムは、電子アルバムを恒久的に保管可能なサービスを実施するもので、家庭内ＬＡＮに接続された電子アルバム端末(画像処理装置)１と、電子アルバムをバックアップ保管するサービスを提供する企業側のデータセンタ２とがインターネット３を介して接続された広域通信システムであり、電子アルバム端末１とデータセンタ２側のアプリケーションサーバ２１との間では、ＴＣＰ／ＩＰ通信プロトコルを利用したＨＴＴＰプロトコル等によって、デジタル化（パケット化）された画像データを送受信するようにしている。

電子アルバム端末１は、カメラ撮影された画像データがメモリカードあるいはカメラ装置などから外部供給された際に、この画像データを内部記憶部(ハードディスク)に記録保存するもので、この内部記憶部に保存された画像データは、データセンタ２側にアップロード送信されることによってバックアップ保管される。すなわち、電子アルバム端末１は、アプリケーションサーバ２１に対してバックアップ要求を通知することによって当該サーバ２１から受信取得したバックアップ実行開始日時を設定した後、この設定日時に到達した際に、アプリケーションサーバ２１をアクセスして画像データをアップロードするようにしている。データセンタ２側には、アプリケーションサーバ２１およびストレージサーバ２２が備えられており、アプリケーションサーバ２１は、電子アルバム端末１との間で画像データなどの送受信を行い、電子アルバム端末１からアップロードされた画像データをストレージサーバ２２に転送してそのバードディスク群(図示せず)内に記録保存させる。

なお、ＩＳＰ４は、電子アルバム端末１側の顧客が契約したインターネットサービスプロバイダであり、家庭内ＬＡＮとＩＳＰ４とはＡＤＳＬ回線(上り：01.Ｍ〜１Ｍ〜１０Ｍｂｐｓ)５を介して接続されている。ＩＳＰ６は、データセンタ２側の企業が契約したインターネットサービスプロバイダであり、データセンタ２とＩＳＰ６とは、バックボーン(１０Ｍ〜１００Ｍ〜１Ｇｂｐｓ)７を介して接続されている。

図２は、電子アルバム端末１の基本的な構成要素を示したブロック図である。
ＣＰＵ１１は、内部記憶部１２内の各種プログラムに応じてこの電子アルバム端末の全体動作を制御する中央演算処理装置である。内部記憶部１２は、プログラム領域およびデータ領域を有するハードディスク(ＨＤＤ)である。この内部記憶部(内蔵ハードディスク)１２内のプログラム領域には、後述する図５〜図７に示す動作手順に応じて本実施例を実現するためのプログラムが格納され、また、そのデータ領域には、撮影画像データを保管する画像フォルダなどが設けられている。この内蔵ハードディスク１２内のプログラム、データは、必要に応じてＲＡＭ（たとえば、スタティックＲＡＭ）１３にロードされたり、このＲＡＭ１３内のデータが内蔵ハードディスク１２にセーブされる。なお、ＲＡＭ１３は、プログラム実行領域と作業領域とを有している。

さらに、ＣＰＵ１１は、その入出力周辺デバイスであるキー入力部１４、表示部１５、ＬＡＮ通信部１６、インターネット通信部１７が接続されているほか、ＵＳＢ端子１８を介してカメラ装置３１、カードドライブ１９を介してメモリカード３２が接続可能となっている。ＬＡＮ通信部１６は、家庭内ＬＡＮを介して他の電子機器との間でデータの送受信を行い、インターネット通信部１７は、インターネット３を介してそのＩＳＰ４との間でデータの送受信を行う通信インターフェイスである。

メモリカード３２は、ＳＤカード、メモリステイクなどであり、デジタルカメラ装置３１からの撮影画像データを電子アルバム端末１に外部供給する画像記録メディアであり、このメモリカード３２がカードドライブ１９のスロットに挿入セットされた際に、カードドライブ１９は、カードセット有り信号を出力してＣＰＵ1に与えるほか、ＣＰＵ１１の制御下でメモリカード３２をアクセスして画像データの読み込み動作を行う。

データセンタ２側のアプリケーションサーバ２１およびストレージサーバ２２の構成は、図示省略したが、ＣＰＵ、内部記憶部(ハードディスク)、通信部、キー入力部、表示部などを有する構成となっている。なお、データセンタ２側は、電子アルバムをバックアップ保管するサービス以外のサービスも提供するが、この実施例においては、電子アルバムをバックアップ保管する場合について説明する。なお、ストレージサーバ２２側には、大容量のハードディスク群などが備えられており、アプリケーションサーバ２１の制御下で画像データの書き込み／読み出し動作が制御される。

次ぎに、この第１実施例における画像データバックアップシステムの動作を説明する。
図３および図４は、電子アルバム端末１、アプリケーションサーバ２１、ストレージサーバ２２との間で行われる画像データのバックアップ手順を示したタイムチャートである。図５〜図７は、電子アルバム端末１側の動作を示したフローチャートであり、図８は、アプリケーションサーバ２１が実行するスケジュール処理を示したフローチャートである。
なお、このタイムチャートで示したバックアップ手順、フローチャートに記述されている各機能は、読み取り可能なプログラムコードの形態で格納されており、このプログラムコードにしたがった動作が逐次実行される。また、伝送媒体を介して伝送されてきた上述のプログラムコードに従った動作を逐次実行することもできる。このことは後述する他の実施例においても同様であり、記録媒体の他に、伝送媒体を介して外部供給されたプログラム／データを利用してこの実施例特有の動作を実行することもできる。

図５〜図７を参照して電子アルバム端末１の動作を説明する。
先ず、電子アルバム端末１においてＣＰＵ１１は、電源オンに伴ってエラーフラグのオン／オフをチェックする(図５のステップＡ１)。このエラーフラグは、アプリケーションサーバ２１にバックアップ要求を何回も試みても応答無しを検出した通信エラーなど、各種のエラー状態の有無を示すもので、エラーフラグがオフ(フラグ＝“０”)であれば、バックアップ・フラグをオフする処理に移るが(ステップＡ２)、エラーフラグがオン(フラグ≠“０”)であれば、そのエラー内容を案内表示してエラーフラグをオフ(フラグ＝“０”)した後に(ステップＡ３)、バックアップ・フラグをオフする処理に移る(ステップＡ２)。このバックアップ・フラグは、内蔵ハードディスク１２に記録保存されている画像データをアプリケーションサーバ２１に対してアップロードしてバックアップすべきことを示すフラグである。

この状態において、上述したメモリカードドライブ１９のスロットにメモリカード(ＳＤカード)１９が挿入されたか否かを示す検出信号に基づいてカードの挿入有無を判別し(ステップＡ４)、メモリカード３２が挿入されている場合には、当該カードに記録されている画像データを内蔵ハードディスク１２に保存済みか未保存かをチェックする(ステップＡ５)。ここで、カードが挿入されていない場合(ステップＡ４でＮＯ)あるいはカードが挿入されていてもその画像が保存済みであれば(ステップＡ５でＮＯ)、カメラ装置３１がＵＳＢ端子１８を介して接続されているかをチェックするステップＡ８に移るが、カード内の画像データが内蔵ハードディスク１２に保存されていない未保存の画像データであれば(ステップＡ５でＹＥＳ)、当該カード１９から画像データを読み出し、内蔵ハードディスク１２にコピーして記録保存させる(ステップＡ６)。この場合、新規画像の保存によって当該画像のバックアップを指示するためにバックアップ・フラグをオンしておく(ステップＡ７)。

そして、カメラ装置３１がＵＳＢ端子１８を介して接続されているかをチェックし(ステップＡ８)、カメラ装置３１が接続されている場合には、当該カメラ内部に記録されている画像データを内蔵ハードディスク１２に保存済みか、未保存かをチェックし(ステップＡ９)、未保存であれば(ステップＡ９でＹＥＳ)、カメラ内部の画像データを読み出し、内蔵ハードディスク１２にコピーして記録保存させた後(ステップＡ１０)、バックアップ・フラグをオンする(ステップＡ１１)。その後、図６のステップＡ１２に移り、内蔵ハードディスク１２に記録保存されている画像データに対する編集処理が指示されたかを調べ、編集指示があれば、画像編集処理が実行されて内部記憶部(ハードディスク)の内容が書き換えられる(ステップＡ１３)。この場合、編集後の当該画像データのバックアップを指示するためにバックアップ・フラグをオンしておく(ステップＡ１４)。

このようにバックアップ・フラグは、メモリカード(ＳＤカード)１９あるいはカメラ装置３１から外部供給された画像データが新規保存されたり、保存画像が編集された際にオンされる。この状態において、電源のオフ操作が行われると(ステップＡ１５)、バックアップ・フラグのオン／オフ状態を調べ(ステップＡ１６)、フラグがオフされていれば、電源オフ操作に応答して電源を遮断してオフ状態となるが、フラグがオンされていれば、内蔵ハードディスク１２に記録保存されている全画像のデータ量を算出すると共に(ステップＡ１７)、指定ＵＲＬ(アプリケーションサーバ２１のインターネットアドレス)を読み出し、アプリケーションサーバ２１に対してバックアップ要求を行う(ステップＡ１８)。この場合、電子アルバム端末１は、全画像のデータ量(バックアップ容量)を付加情報として、バックアップ要求と共に送信するようにしている。その後、アプリケーションサーバ２１からの応答待ち状態となり、バックアップ要求を何回も試みても応答が無いタイムアップ時には(ステップＡ１９)、エラーフラグに当該通信エラーを示す番号をセットした後に(ステップＡ２０)、電源を遮断してオフ状態となる。

ここで、アプリケーションサーバ２１においては、図３に示すように、電子アルバム端末１から画像保存に伴うバックアップ要求を受け取ると、図８のフローチャートに示すスケジュール処理を実行することによってアップロード(バックアップ)の実行開始日時を特定し、この実行開始日時をスケジュール情報として要求元の電子アルバム端末１に対して送信するようにしている。すなわち、アプリケーションサーバ２１は、電子アルバム端末１からのバックアップ要求有無をチェックし(ステップＢ１)、バックアップ要求を受けた際には、図９に示す時間帯別・曜日別トラフィック履歴テーブルＴＦＴと電子アルバム端末１から送信されて来た全画像のデータ量(バックアップ容量)を参照することによって(ステップＢ２)、最適なバックアップ実行開始日時を示すスケジュール情報を決定し(ステップＢ３)、このバックアップ実行開始日時を要求元の電子アルバム端末１に対して応答送信する(ステップＢ４)。

ここで、時間帯別・曜日別トラフィック履歴テーブルＴＦＴは、過去の各時間帯毎および曜日毎のトラフィック状況を考慮して予め設定された時間帯別・曜日別トラフィック履歴を記憶管理するテーブルである。すなわち、このトラフィック履歴テーブルＴＦＴは、図９に示すように、その横軸に１時間単位に区分された時間帯を配置し、その縦軸に七曜日を配置した構成で、この時間帯と曜日とが交差するマトリックス状の各セル位置には、時間帯別・曜日別のトラフィック状況がセットされている。たとえば、カメラ撮影された画像データのバックアップ要求は、休日の翌日(月曜日)に集中し、かつ、月曜日の午前１０時頃がピークであるという実情などを考慮して、月曜日の午前１０時頃をピークとしたトラフィック状況が１時間単位および曜日単位毎にセットされている。

なお、時間帯別・曜日別トラフィック履歴テーブルＴＦＴにおいて、上述した図示の例は、１時間単位および曜日単位毎にトラフィック状況をセットするようにしたが、１０分単位、２０分単位でトラフィック状況をセットしたり、クリスマス、正月などの翌日、運動会シーズン、入学・卒業シーズンなどに対応してトラフィック状況をセットするようにしてもよい。また、トラフィック履歴テーブルＴＦＴに設定されているトラフィック状況をレベルによって示すようにしてもよい。たとえば、月曜日の午前１０時頃をＡレベル、月曜日の午前１０時前後の時間帯をＢレベル、その他の曜日、時間帯をＣレベルとしてもよい。また、図示の例では、時間帯別・曜日別のトラフィック状況をマトリックステーブルで構成したが、時間帯別トラフィック履歴テーブルと曜日別トラフィック履歴テーブルに分けた構成であってもよい。また、トラフィック履歴テーブルＴＦＴの内容は、定期的に更新するようにしているが、たとえば、トラフィック状況を自動的に検出分析しながら、この分析結果をトラフィック履歴テーブルに蓄積反映させるなど、その更新の仕方は任意である。さらに、トラフィック履歴テーブルＴＦＴに設定されているトラフィック状況は、バックアップサービスを提供する施設を他のサービスと共有しているような場合には、他のサービスでのトラフィック状況をも考慮したものとなっている。

アプリケーションサーバ２１は、バックアップ要求を受ける毎に、アクセスが集中する曜日・時間帯でのバックアップ要求を他の時間帯、他の曜日に分散させるために、時間帯別・曜日別トラフィック履歴テーブルＴＦＴなどを参照してトラフィック状況の少ない最適なバックアップ実行開始日時を決定するようにしている。この場合、バックアップ要求を受けた時点のトラフィック状況が少なく、高速通信が可能な状態であれば、その時点をバックアップ実行開始日時として決定する。つまり、バックアップ要求時点をバックアップ実行開始日時として決定するが、その際、応答に要する若干の所要時間を考慮したり、先着順を考慮してバックアップ実行開始日時を決定するようにしている。また、アプリケーションサーバ２１は、時間帯別・曜日別トラフィック履歴のほかに、バックアップ対象の全画像のデータ量(バックアップ容量)をも考慮してバックアップ実行開始日時を決定するようにしている。

電子アルバム端末１は、アプリケーションサーバ２１から送信されて来たバックアップ実行開始日時を設定した後に(図６のステップＡ２１)、省電力モードに切り替える(ステップＡ２２)。その後、設定したバックアップ実行開始日時に到達するまでの間あるいは電源がオンされるまでの間、必要最低限の電力である省電力モードのままの状態を保持する(ステップＡ２２〜Ａ２４)。ここで、バックアップ実行開始日時に到達する前に、電源がオンされた場合には(ステップＡ２４でＹＥＳ)、最初のステップＡ１に戻り、以下、同様の動作が行われる。この場合においても、上述と同様、バックアップ実行開始日時に到達する前に内蔵ハードディスク１２に記録保存されている画像データに新規画像が追加されたり、画像の削除、切り出しなどの編集が行われた際には、つまり、内蔵ハードディスク１２の内容が再更新された際には、バックアップ・フラグがオンされるため、その後の電源オフ操作に応じて再度のバックアップ要求が行われる。

この場合、アプリケーションサーバ２１は、図３に示すように、保存データの再更新に伴うバックアップ要求を受け取ると、上述したスケジュール処理を実行するが、その際、更新前における全画像のデータ量(バックアップ容量)と更新後のバックアップ容量とを比較し、その容量変化によって更新前のバックアップ実行開始日時を変更した新たなバックアップ実行開始日時を決定して、要求元の電子アルバム端末１に送信する。ここで、電子アルバム端末１は、前回設定したバックアップ実行開始日時を今回新たに受信したバックアップ実行開始日時に書き換えることによってその設定内容を変更する(図６のステップＡ２１)。なお、図３の例では、前回設定したバックアップ実行開始日時よりも先の日時が新たな開始日時として再設定された場合を示している。

ここで、電子アルバム端末１は、バックアップ実行開始日時に達したことを検出すると(図６のステップＡ２３)、図７のステップＡ２５に移って電源をオンさせる。そして、上述の指定ＵＲＬを読み出して、アプリケーションサーバ２１に対してバックアップの実行を通知した後に(ステップＡ２６)、応答待ち状態となる。ここで、バックアップ実行通知を何回も試みても応答が無いタイムアップ時には(ステップＡ２７)、エラーフラグに当該通信エラーを示す番号をセットした後(ステップＡ２８)、電源を遮断してオフ状態となるが、アプリケーションサーバ２１からの応答を受信すると(ステップＡ２７)、その応答内容は、肯定(ＯＫ)応答か、否定(ＮＧ)応答かを調べる(ステップＡ２９)。

ここで、アプリケーションサーバ２１は、図３に示すように、電子アルバム端末１からバックアップ実行通知を受信すると、現時点のアクセス数、通信速度を自動検出して経路上のボトルネックによる通信障害の発生有無を判別し、現時点のトラフィック状況はアップロードに適した状態か否かを調べ、現在のトラフィック状況に応じて肯定(ＯＫ)応答あるいは否定(ＮＧ)応答を行う。ここで、ＮＧ応答を行う場合には、たとえば、現在の日時から所定時間後(５分後、１０分後など)の日時を新たなバックアップ実行開始日時として決定し、再度、要求元の電子アルバム端末１に対して新たなバックアップ実行開始日時を送信する。なお、この場合、上述した時間帯別・曜日別トラフィック履歴テーブルＴＦＴの内容を加味して新たなバックアップ実行開始日時を決定するようにしてもよい。

電子アルバム端末１は、アプリケーションサーバ２１から否定(ＮＧ)応答を受信した場合には(ステップＡ２９)、その応答に付加されている新たなバックアップ実行開始日時を設定した後(ステップＡ３４)、省電力モードに切り替える(ステップＡ３５)。その後、設定したバックアップ実行開始日時に到達するまでの間(ステップＡ３６)、必要最低限の電力である省電力モードのままの状態を保持する。ここで、実行開始日時に到達すると、ステップＡ２５に戻り、電源をオンさせた後に、再度、バックアップ実行開始通知を行う(ステップＡ２６)。

一方、電子アルバム端末１は、肯定(ＯＫ)応答を受信した場合には(ステップＡ２９)、内蔵ハードディスク１２に記録保存されている画像データのうち、アップロード済み(バックアップ済み)の画像データを重複してアップロードすることを避けるために、当該アップロード済みのデータを削除対象(バックアップ対象外)として指定するための削除データリストを作成し、アプリケーションサーバ２１をアクセスして当該削除データリストの送信を行う(ステップＡ３０)。

ここで、図３および図４に示すように、アプリケーションサーバ２１は、削除データリストを受信すると、ストレージサーバ２２に対して当該指定データの削除を要求する。ストレージサーバ２２は、この削除要求に応じて指定データを削除する処理を実行し、その処理が終了に伴って削除完了通知をアプリケーションサーバ２１に対して行う。アプリケーションサーバ２１は、この削除完了通知に応答して電子アルバム端末１をアクセスし、今回のバックアップ対象データ(更新データ)を送信すべきことを指示する更新データ送信要求を行う。

電子アルバム端末１は、更新データ送信要求の待ち状態において(ステップＡ３１)、応答無しのタイムアップ時には、エラーフラグに当該通信エラーを示す番号をセットした後(ステップＡ２８)、電源を遮断してオフ状態となるが、アプリケーションサーバ２１からの更新データ送信要求を受信すると、内蔵ハードディスク１２に記録保存されている画像データのうち、未アップロードの画像データ(更新データ)を読み出してアプリケーションサーバ２１にアップロード送信する(ステップＡ３２)。その後、応答待ち状態となり、バックアップの正常終了を示す応答を受けた場合には(ステップＡ３３でＹＥＳ)、電源を遮断してオフ状態となるが、応答無しのタイムアップ時には(ステップＡ３３)、エラーフラグに当該通信エラーを示す番号をセットした後(ステップＡ２８)、電源を遮断してオフ状態となる。

ここで、アプリケーションサーバ２１は、電子アルバム端末１からアップロードされた更新データ(画像データ)を受信すると、この受信データを一時記憶した後に、バックアップの正常終了を示す正常応答を電子アルバム端末１に返信すると共に、ストレージサーバ２２をアクセスし、この受信データをそのハードディスク群に記録保存すべきことを指示する記録保存の要求を行う。

以上のように、この第１実施例における電子アルバム端末１は、アプリケーションサーバ２１に対してバックアップ要求を通知することによって当該サーバ２１から受信取得したスケジュール情報に基づいてバックアップ実行開始日時を設定した後、この設定日時に到達した際に、アプリケーションサーバ２１をアクセスして画像データをアップロードするようにしたから、画像データをアプリケーションサーバ２１にバックアップするタイミングをサーバ２１から取得したスケジュール情報(バックアップ実行開始日時)に基づいて制御することができ、通信設備を増強しなくても、トラフィック発生時、通信障害時などのようにアップロードが困難な状態下でのアップロードを回避することができ、画像データを円滑かつ正確にバックアップすることが可能となり、通信設備費の過剰投資を抑えることができる。

この場合、電子アルバム端末１は、バックアップ対象となる全画像分のデータ量をバックアップ要求と共に送信するようにしたから、アプリケーションサーバ２１側では、この全画像分のデータ量に基づいてアップロードに必要な所要時間などを加味することができ、バックアップ実行開始日時を決定する際に、その決定をより適切に行うことができる。
また、画像データが編集されて再保存された際に、アプリケーションサーバ２１に対してバックアップ要求を再度行う共に、編集後の全画像分のデータ量を送信し、これに応答してサーバ２１から改めて送信されて来たバックアップ実行開始日時を再取得して設定内容を変更するようにしたから、画像編集によってデータ量が大きく増えたり、減った場合でも、サーバ２１側では、その編集前後の変動データ量を加味することによってバックアップ実行開始日時を決定することができる。

電子アルバム端末１は、カメラ装置３１あるいはメモリカード３２からの画像データが内蔵ハードディスク１２に記録保存された際に、そのことを示すバックアップ・フラグをセットし、電源オフ時にバックアップ・フラグのセット有無を判別し、フラグがセットされていれば、アプリケーションサーバ２１に対してバックアップ要求を行い、これに応答して送信されて来たバックアップ実行開始日時を受信取得するようにしたから、画像データのバックアップを意識することなく、カメラ装置３１あるいはメモリカード３２からの画像データをバックアップさせることができる。この場合、電源オフ時にバックアップ実行開始日時を設定した後に省電力の待機状態に移行し、この待機状態においてバックアップ実行開始日時に到達したことを検出した際に、電源をオンして画像データをアップロードするようにしたから、無駄な電力消費を抑えることができる。

電子アルバム端末１は、内蔵ハードディスク１２の画像データが編集されて再保存された際に、画像編集が行われたことを示すバックアップ・フラグをセットし、電源オフ時にバックアップ・フラグのセット有無を判別し、フラグがセットされていれば、サーバ２１に対してバックアップ要求を行い、これに応答して送信されて来たバックアップ実行開始日時を受信取得するようにしたから、画像編集を行った場合でもそのアップロードを意識することなく、編集後の画像データをアップロードさせることができる。

また、バックアップ実行開始日時にサーバ２１をアクセスした際に、アクセス数の増大などによってバックアップに適した状態でない場合にサーバ２１から改めて送信されて来たバックアップ実行開始日時を再取得することによってその設定内容を延長変更するようにしたから、アップロードが困難な現状を回避することができる。

一方、アプリケーションサーバ２１は、電子アルバム端末１からバックアップ要求を受けた際に、時間帯別・曜日別トラフィック履歴テーブルＴＦＴを参照してトラフィック状況の少ない日時をバックアップ実行開始日時として特定して要求元に送信した後に、このバックアップ実行開始日時にアップロードされた画像データをバックアップデータとしてストレージサーバ２２に保管させるようにしたから、過去のトラフィック履歴に基づいてアップロード実行開始日時を制限することができ、通信設備を増強しなくても、トラフィック発生時、通信障害時などのようにアップロードが困難な状態下でのアップロードを回避することができ、画像データを円滑かつ正確にバックアップすることが可能となり、通信設備費の過剰投資を抑えることができる。
（実施例２）

以下、この発明の第２実施例について図１０および図１１を参照して説明する。
なお、上述した第１実施例において、アプリケーションサーバ２１は、電子アルバム端末１からバックアップ要求を受けた際に、時間帯別・曜日別トラフィック履歴テーブルＴＦＴを参照してトラフィック状況の少ない日時をバックアップ実行開始日時として特定して要求元に送信するようにしたが、この第２実施例においては、バックアップ要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別し、実行可能であれば、現時点でのアップロードを許可し、実行不可能であれば、時間帯別・曜日別トラフィック履歴テーブルＴＦＴなどを参照してトラフィック状況の少ない日時をバックアップ実行開始日時として特定して送信するようにしたものである。
ここで、両実施例において基本的あるいは名称的に同一のものは、同一符号を付して示し、その説明を省略すると共に、以下、第２実施例の特徴部分を中心に説明するものとする。

図１０、図１１は、第２実施例の特徴部分を示したフローチャートであり、図１０は、電子アルバム端末１側の動作、図１１は、アプリケーションサーバ２１側の動作を示したフローチャートである。
先ず、電子アルバム端末１は、内蔵ハードディスク１２に記録保持されている画像データをデータセンタ２側にバックアップさせるために、アップロードが可能か否かを問い合わせるアップロード要求をアプリケーションサーバ２１に対して行い(ステップＣ１)、応答待ち状態となる(ステップＣ２)。

アプリケーションサーバ２１は、電子アルバム端末１からのアップロード要求を受信すると(ステップＤ１)、現時点のアクセス数、通信速度を自動検出して経路上のボトルネックによる通信障害の発生有無を判別し、現時点のトラフィック状況はアップロードに適した状態か否かを調べ(ステップＤ２)、現在のトラフィック状況に応じて肯定(ＯＫ)応答あるいは否定(ＮＧ)応答を行う。すなわち、アップロードに適した状態でなければ、アップロードＮＧと判別して(ステップＤ３)、図９に示す時間帯別・曜日別トラフィック履歴テーブルＴＦＴと電子アルバム端末１から送信されて来た全画像のデータ量(バックアップ容量)を参照することによって(ステップＤ４)、最適なバックアップ実行開始日時を示すスケジュール情報を決定し(ステップＤ５)、このバックアップ実行開始日時を要求元の電子アルバム端末１に対して応答送信する(ステップＤ６)。また、アップロードに支障がない状態であれば、アップロードＯＫと判別して(ステップＤ３)、アップロードの実行許可通知を要求元の電子アルバム端末１に対して応答送信する(ステップＤ７)。

電子アルバム端末１は、アップロード要求に伴ってアプリケーションサーバ２１からの応答を受信すると、ＯＫ応答かＮＧ応答かの判別を行い(ステップＣ３)、ＮＧ応答であれば、バックアップ実行開始日時を受信して設定する(ステップＣ４)。その後、設定したバックアップ実行開始日時に到達したかを監視し(ステップＣ５)、実行開始日時に到達した際には、ステップＣ１に戻って、再度、アップロード要求を行う。一方、ＯＫ応答を受信した場合には(ステップＣ３)、内蔵ハードディスク１２に記録保持されている画像データを読み出してアプリケーションサーバ２１にアップロード送信する(ステップＣ６)。
ここで、アプリケーションサーバ２１は、電子アルバム端末１からアップロードされた画像データを受信すると(ステップＤ８)、この受信データをストレージサーバ２２に転送して記録保管させる(ステップＤ９)。

以上のように、この第２実施例におけるアプリケーションサーバ２１は、電子アルバム端末１からアップロード要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別し、実行可能であれば、現時点でのアップロードを許可し、実行不可能であれば、時間帯別・曜日別トラフィック履歴テーブルＴＦＴなどを参照してトラフィック状況の少ない日時をアップロード実行開始日時を決定して要求元の電子アルバム端末１に送信することによって現時点でのアップロードを制限した後に、このアップロード実行開始日時に電子アルバム端末１からアップロードされた画像データをバックアップデータとして保管するようにしたから、アップロード要求を受けた時点のトラフィック状況に基づいてアップロードを即座に許可するか、過去のトラフィック履歴を考慮した日時に制限するかを制御することができ、通信設備を増強しなくても、トラフィック発生時、通信障害時などのようにアップロードが困難な状態下でのアップロードを回避することができ、画像データを円滑かつ正確にバックアップすることが可能となり、通信設備費の過剰投資を抑えることができる。

なお、上述した第１および第２実施例においては、電子アルバム端末１の内蔵ハードディスク内の画像データを一括してアップロードするようにしたが、たとえば、画像データ量が多いような場合には、画像データを複数に分割して各分割データ毎にアップロードするようにしてもよい。この場合、電子アルバム端末１は、分割データ毎に、対応するバックアップ実行開始日時をアプリケーションサーバ２１から受信取得して設定しておけばよい。

さらに、画像データの重要度、緊急度に応じて優先的にアップロードする画像データが指定されている場合に、電子アルバム端末１は、重要度、緊急度毎に、対応するバックアップ実行開始日時を受信取得して設定するようにしてもよい。
また、上述した実施例においては、言及しなかったが、外部供給する画像データは、静止画に限らず、動画であってもよく、また、音声データ付きの画像データであってもよい。

その他、上述した第１および第２実施例においては、電子アルバム端末１を例示したが、カメラ撮影された画像データを電子アルバムとして収集保存するパーソナルコンピュータ(ＰＣ)あるいは携帯端末装置であってもよく、さらに、バードディスクレコーダ、通信機能付きのデジタルカメラ装置、カメラ付き携帯端末装置などにも同様に適用可能である。

一方、コンピュータに対して、上述した各手段を実行させるためのプログラムコードをそれぞれ記録した記録媒体（たとえば、ＣＤ−ＲＯＭ、フレキシブルディスク、ＲＡＭカード等）を提供するようにしてもよい。すなわち、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、内部記憶部に記録された画像データをネットワーク経由でサーバ装置にアップロードするタイミングを示すスケジュール情報を当該サーバ装置から受信取得する機能と、受信取得したスケジュール情報に基づいてアップロードの実行開始日時を設定する機能と、設定されたアップロード実行開始日時に到達したことが検出された際に、前記サーバ装置をアクセスして前記内部記憶部に記録された画像データをアップロードする機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。

また、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、過去のトラフィック状況をトラフィック履歴として記憶管理する機能と、画像処理装置からバックアップ要求を受けた際に、前記トラフィック履歴を参照してトラフィック状況の少ない日時をアップロードの実行開始日時とするためのスケジュール情報を特定して要求元の画像処理装置に対して送信する機能と、前記アップロード実行開始日時に前記画像処理装置からアップロードされた画像データをバックアップデータとして保管する機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。

また、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、過去のトラフィック状況をトラフィック履歴として記憶管理する機能と、画像処理装置からバックアップ要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別する機能と、実行可能であると判別された場合には、現時点でのアップロードを許可し、実行不可能であると判別された場合には、前記トラフィック履歴記を参照してトラフィック状況の少ない日時をアップロードの実行開始日時とするためのスケジュール情報を特定して要求元の画像処理装置に送信することによって現時点でのアップロードを制限する機能と、前記アップロード実行開始日時に前記画像処理装置からアップロードされた画像データをバックアップデータとして保管する機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。

画像データバックアップシステムの全体構成の概要を示したブロック図。電子アルバム端末１の基本的な構成要素を示したブロック図。電子アルバム端末１、アプリケーションサーバ２１、ストレージサーバ２２との間で行われる画像データのバックアップ手順を示したタイムチャート。図３に続く、バックアップ手順を示したタイムチャート。電子アルバム端末１側の動作を示したフローチャート。図５に続く、電子アルバム端末１側の動作を示したフローチャート。図５、図６に続く、電子アルバム端末１側の動作を示したフローチャート。アプリケーションサーバ２１が実行するスケジュール処理を示したフローチャート。時間帯別・曜日別トラフィック履歴テーブルＴＦＴを説明するための図。第２実施例の特徴部分である電子アルバム端末１側の動作を示したフローチャート。第２実施例の特徴部分であるアプリケーションサーバ２１側の動作を示したフローチャート。

符号の説明

１電子アルバム端末
２データセンタ
３インターネット
１１ＣＰＵ
１２内蔵ハードディスク
１４キー入力部
１７インターネット通信部
１８ＵＳＢ端子
１９カードドライバ
２１アプリケーションサーバ
２２ストレージサーバ
３１カメラ装置
３２メモリカード
ＴＦＴ時間帯別・曜日別トラフィック履歴テーブル

Claims

バックアップ対象の画像データを記録処理する画像処理装置にネットワークを介して接続されているバックアップサーバ装置であって、
過去のトラフィック状況をトラフィック履歴として記憶管理するトラフィック履歴記憶手段と、
前記画像処理装置からバックアップ要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別する判別手段と、
この判別手段によって実行可能であると判別された場合には、現時点でのアップロードを許可し、実行不可能であると判別された場合には、前記トラフィック履歴を参照してトラフィック状況の少ない日時をアップロードの実行開始日時とするためのスケジュール情報を特定して要求元の画像処理装置に送信することによって現時点でのアップロードを制限するアップロード制御手段と、
を具備し、前記アップロード実行開始日時に前記画像処理装置からアップロードされた画像データをバックアップデータとして保管する、ようにしたことを特徴とするバックアップサーバ装置。
コンピュータに対して、
過去のトラフィック状況をトラフィック履歴として記憶管理する機能と、
画像処理装置からバックアップ要求を受けた際に、その時点のトラフィック状況に基づいてアップロードを適切に実行可能か否かを判別する機能と、
実行可能であると判別された場合には、現時点でのアップロードを許可し、実行不可能であると判別された場合には、前記トラフィック履歴を参照してトラフィック状況の少ない日時をアップロードの実行開始日時とするためのスケジュール情報を特定して要求元の画像処理装置に送信することによって現時点でのアップロードを制限する機能と、
前記アップロード実行開始日時に前記画像処理装置からアップロードされた画像データをバックアップデータとして保管する機能と、
を実現させるためのプログラム。