JP7158864B2 - システムおよびそれを用いる方法 - Google Patents

Description

本発明は、ネットワーク機器のクラウドバックアップおよびリストア処理に用いるシステムおよびそれを用いる方法に関する。

近年、画像形成装置のバックアップの需要が高まっている。一般的に画像形成装置などの複写機は、モーターなどの駆動部品を多く内包しており、故障時は、当該部品を交換もしくは代替機への交換によって運用が継続される。しかし、運用に必要なデータを保持するストレージ部品が故障した場合は、データが故障する以前の状態にデータを戻す必要がある。そこで、定期的に画像形成装置のデータをバックアップしておき、部品故障時にバックアップしたデータに復元する手段が必要となる。

しかし、画像形成装置のように、扱うデータが多種多様かつ大容量となる場合は、顧客環境にストレージサーバを用意することは現実的ではない。クラウド上にサーバを用意する手段も考えられるが、大量の画像形成装置からバックアップデータが送信されるため、クライアント・サーバ間の通信負荷やストレージ容量の監視を行いながら都度メンテナンスする必要があり、運用コストが上がってしまう。

そこで、近年では、サーバレスアーキテクチャーによるシステム構築と、データ保管に特化したクラウドのストレージサービスの活用が着目されている。サーバレスアーキテクチャーによるシステムでは、クラウドベンダーが提供するプログラム実行環境にアプリケーションを構成する関数が登録および管理される。画像形成装置は、クラウド上の関数を呼び出す形でシステムが構成される。これにより、従来必要だったサーバ管理が不要となり、運用コストを抑えることが可能となった。

また、クラウドベンダーが提供するサーバ管理不要なストレージサービスを利用することで、システムで扱う大容量のデータ管理および通信による負荷を分散することが可能となる。特に、画像形成装置のように、扱うデータが多種多様かつ大容量となる場合は、容量拡張や監視が不要なクラウドストレージサービスの活用することでシステムの運用管理コストを下げることが可能になる。

特許文献１では、バックアップ処理の負荷を下げつつ、サーバとの通信負荷を下げる方法が提案されている。特許文献１に開示されるシステムによれば、情報処理装置のバックアップ処理において、バックアップ対象のデバイスは、データ保管サーバに対して前回バックアップからの差分データのみの送信を行う。

特開平６－２４３０１３号公報

特許文献１に開示されるシステムでは、デバイスがバックアップからリストアを行う際、デバイスを何時の時点の状態にリストアするか次第で、差分バックアップデータを取得する量が変化する。例えば、デバイスが故障する直前の最新の状態にリストアする場合、デバイスは、全ての差分バックアップデータを取得およびトレースし、かつリストア用の設定・コンテンツデータを生成する必要がある。つまり、バックアップ機能の利用期間が長くなるほどリストア時の負荷がかかり、デバイスを利用できない時間が増加してしまう。

そこで、本発明は、サーバレスアーキテクチャーおよびクラウドストレージサービスによって構成される画像形成装置のクラウドバックアップシステムにおいて、デバイスのリストア処理にかかる時間を最小化する最適な手法を提案する。

本発明の例に係るシステムは、ネットワークデバイスと、ストレージシステムと、データ管理システムと、を含む。前記ネットワークデバイスは、前記ネットワークデバイスの記憶装置に格納されるデータをバックアップデータとして保存するための保存先を示す情報を要求する第１要求を行う第１要求手段と、前記第１要求に従い受信した前記保存先を示す情報を用いて、前記記憶装置に格納されるデータを送信する送信手段と、を有し、前記データ管理システムは、前記第１要求に応じて前記ネットワークデバイスのバックアップデータを保存するための保存先を示す情報を生成し、前記保存先を示す情報を前記ネットワークデバイスに応答する第１応答手段を有し、前記ネットワークデバイスから前記生成された保存先を示す情報を用いて送信されたデータが差分バックアップデータであり、当該差分バックアップデータが前記ストレージシステムに保存されたことを示すイベントに応じて呼び出された関数に基づき、前記ストレージシステムですでに管理されているフルバックアップデータと当該差分バックアップデータとのマージ処理を実行するためのメッセージが管理され、当該管理されたメッセージに基づき前記マージ処理が実行され、前記イベントに応じた前記関数の呼び出しに失敗した場合、さらに呼び出される別の関数の実行に基づき、前記マージ処理を実行するためのメッセージが管理される。

本発明の例によれば、サーバレスアーキテクチャーおよびクラウドストレージサービスによって構成される画像形成装置のクラウドバックアップシステムにおいて、デバイスのリストア処理にかかる時間を最小化することが可能になる。

システムの例を示す全体図である。 システムのハードウェア構成の例を示す図である。 システムのミドルウェア構成の例を示す図である。 システムのソフトウェア構成の例を示す図である。 バックアップ処理の例を示すフローチャートである。 リストア処理の例を示すフローチャートである。 署名付きＵＲＬ生成処理の例を示すフローチャートである。 バックアップデータ保存処理の例を示すフローチャートである。 バックアップ完了処理の例を示すフローチャートである。 マージ処理予約関数の例を示すフローチャートである。 マージ処理関数の例を示すフローチャートである。 関数呼び出しリトライ関数の例を示すフローチャートである。 リストアアプリケーションＵＩの例を示す図である。 イベント検知および関数呼び出し処理の例を示すフローチャートである。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施例１）
本発明の例に係るネットワーク機器を管理するネットワークシステムを説明する。ネットワーク機器の一例として、本実施例では、ＭＦＰ（Ｍｕｌｔｉ－ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、すなわち複合機能を有する複写機を取り上げて説明する。ネットワーク機器としては、プリンタ、ファクシミリなどのＭＦＰ以外のものも含む。以降、これらを総じて「画像形成装置」と表現する。

＜システム構成＞
図１は、本発明の例に係るシステムの全体図である。本実施例のシステムは、画像形成装置のバックアップシステムであり、複数の画像形成装置と、画像形成装置のデータを管理するクラウド上のバックアップアプリケーションシステムと、を備える。

図１において、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１は、顧客環境１００のＬＡＮである。画像形成装置１０２は、ＬＡＮ１０１に接続し、同ネットワークに接続するクライアントコンピュータ１０４のような他のネットワーク機器からの要求に応じてプリント処理およびスキャン処理並びに他の複数の機能を提供できる。画像形成装置１０２は、さらにＬＡＮ１０１を介してインターネット１０７に接続する。画像形成装置１０２は、インターネット１０７を介して、クラウド基盤１１０に構築されたデータ管理システムとしてのアプリケーションシステム１０８に画像形成装置１０２のバックアップデータを送信する。また、画像形成装置１０２は、当該バックアップデータをストレージシステムとしてのストレージサービス１０９にも送信する。

アプリケーションシステム１０８は、データ管理システムとして機能し、画像形成装置１０２を一元的に管理する機能を持つ。また、管理画面も保持する。ストレージシステムとしてのストレージサービス１０９は、画像形成装置１０２から送信されるデータを管理する。ストレージサービス１０９は、アプリケーションシステム１０８が発行する署名付きＵＲＬへのＨＴＴＰＳリクエストによって接続される。ストレージサービス１０９は、署名付きＵＲＬによって画像形成装置１０２からのバックアップデータ送信および受信要求を受け付ける。

本図では、複数の画像形成装置１０２がＬＡＮ１０１を介して接続されている状態、さらには画像形成装置１０２とアプリケーションシステム１０８およびストレージサービス１０９とがインターネット１０７を介して接続されている状態を示している。

＜システムのハードウェア構成＞
図２は、ネットワークシステムのハードウェア構成を説明するブロック図である。図２（Ａ）は、アプリケーションシステム１０８、ストレージサービス１０９が動作するクラウド基盤１１０が稼働するデータセンターを構成するサーバの内部構成およびクライアントコンピュータ１０４の内部構成の例を示す。

図２（Ａ）において、２０１は、ＣＰＵであり、ＲＯＭ２０３あるいは外部メモリ２０９に記憶されたアプリケーションプログラム等に基づいて処理を実行する。さらに、ＣＰＵ２０１は、システムバス２１６に接続される各デバイスを総括的に制御する。また、ＣＰＵ２０１は、ディスプレイ２０８上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のアプリケーションウィンドウを開き、種々のデータ処理を実行する。

２０２は、ＲＡＭであり、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０３は、ＲＯＭであり、基本Ｉ／Ｏプログラム等の記憶領域として機能する読み出し専用のメモリである。このＲＯＭ２０３あるいは記憶装置２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステムプログラム（以下ＯＳ）等が記憶される。さらに、ＲＯＭ２０３あるいは記憶装置２１１には、上記アプリケーションプログラム等に基づく処理の際に使用するファイルやその他各種データを記憶する。２０４は、ネットワークＩ／Ｆ（インターフェース）であり、不図示のファイアウォールを介してインターネット１０７に接続される。なお、ネットワークＩ／Ｆ ２０４に接続可能ネットワークは、有線または無線を問わない。

２０６は、入出力Ｉ／Ｆであり、キーボード２０７やマウス等のポインティングデバイス２０９からの入力やディスプレイ２０８への出力を制御する。２１０は、外部メモリＩ／Ｆであり、ハードディスク（ＨＤ）等の記憶装置２１１とのアクセスを制御する。２１１は、記憶装置であり、ブートプログラム、各種のアプリケーション、ユーザファイル、編集ファイル等を記憶する。クラウド基盤１１０を構成するサーバおよびストレージサービス１０９は、ＣＰＵ２０１がＲＯＭ２０２や記憶装置２１１に書き込まれた基本Ｉ／ＯプログラムおよびＯＳを実行している状態で動作する。基本Ｉ／Ｏプログラムは、ＲＯＭ２０３に書き込まれており、ＯＳは、ＲＯＭ２０３もしくは記憶装置２１１に書き込まれている。そしてコンピュータの電源がＯＮされたときに、基本Ｉ／Ｏプログラム中のイニシャルプログラムロード機能により、ＲＯＭ２０３もしくは記憶装置２１１からＯＳがＲＡＭ２０２に書き込まれ、ＯＳの動作が開始される。

以上、クラウド基盤１１０を構成するサーバの内部構成およびクライアントコンピュータ１０４の内部構成について、説明の便宜上、図２（Ａ）を共通に用いて説明した。なお、アプリケーションシステム１０８およびストレージサービス１０９は、クラウド上の仮想マシンとして図２（Ａ）の内部構成を仮想的に実現されるものである。

図２（Ｂ）は、画像形成装置１０２の内部構成の例を示す。画像形成装置１０２、１０３において、２５１は、ＣＰＵであり、制御プログラム等に基づいてシステムバス２７０に接続されるプリンタＩ／Ｆ２５８を介してプリンタ２５９に出力情報としての画像信号を出力する。なお、制御プログラムは、ＲＯＭ２５３や記憶装置２６３等に記憶される。

ＣＰＵ２５１は、ネットワークＩ／Ｆ ２５５を介して外部のコンピュータ装置との通信処理が可能となっており、画像形成装置１０２内の情報等を外部サーバに通知可能なように構成されている。さらに、ＣＰＵ２５１は、ＲＯＭ２５３あるいは記憶装置２６３に記憶されたアプリケーションプログラム等に基づいて処理を実行する。２５２は、ＲＡＭであり、ＣＰＵ２５１の主メモリ、ワークエリア等として機能し、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張できる。なお、ＲＡＭ２５２は、出力情報展開領域、環境データ格納領域、およびＮＶ（Ｎｏｎ Ｖｏｌａｔｉｌｅ）ＲＡＭ等に用いられる。

２５３は、ＲＯＭであり、２６３は、ハードディスク（ＨＤ）等の記憶装置である。このＲＯＭ２５３あるいは記憶装置２６３には、ＣＰＵ２５１の制御プログラムやアプリケーションプログラムおよび上記出力情報を生成する際に使用するフォントデータ、画像形成装置１０２上で利用される情報等が記憶される。また、ＲＯＭ２５３あるいは記憶装置２６３には、画像形成装置１０２のアプリケーションインストール時にアプリケーションが一時的に格納される。２５４は、ＵＳＢ Ｉ／Ｆであり、外部装置とＵＳＢ接続によるデータ通信を制御する。例えば、後述のクライアントコンピュータ１０４とＵＳＢで接続される。クライアントコンピュータ１０４は、ＵＳＢ Ｉ／Ｆ２５４を介して、各種プリント操作やスキャン操作を実行できる。

２５６は、操作部Ｉ／Ｆであり、操作部２５７との間のインターフェースをつかさどり、表示すべき画像データを操作部２５７に対して出力する。また、ユーザが操作部２５７を介して入力した情報の受信も行う。２５７は、操作部であり、操作のためのスイッチおよびＬＥＤ表示器等が配されている操作パネル等に相当する。２５８は、プリンタＩ／Ｆであり、プリンタ２５９（プリンタエンジン）に出力情報としての画像信号を出力する。

２６０は、スキャナーＩ／Ｆであり、スキャナー２６１（スキャナーエンジン）からの入力情報として画像信号を受信する。２６２は、外部メモリＩ／Ｆ（メモリコントローラ）であり、ハードディスク（ＨＤ）等の外部メモリへのアクセスを制御する。２６４は、オプション機器Ｉ／Ｆであり、フィニッシャー、カセットユニット等のオプション機器２６５へのアクセスを制御する。オプション機器は、フィニッシャーやカセットユニットの他に、カメラやＩＣカードリーダー等のＭＦＰの機能および機構を拡張する周辺機器でもよい。２７０は、システムバスであり、各デバイスを接続する。

＜クラウド基盤のミドルウェア構成＞
図３は、クラウド基盤１１０のミドルウェア構成例を示す。アプリケーションシステム１０８およびストレージサービス１０９は、クラウド基盤１１０上に構築および管理される仮想マシン、および関連するリソース郡から構成される。アプリケーションシステム１０８およびストレージサービス１０９は、クラウド基盤１１０上に構築および管理されたリソースによって、顧客環境１００内のネットワークデバイスおよび中継装置から送られるリクエストを処理してサービスを提供する。

広域ネットワーク３０１は、クラウドサービス内の各サービスを接続する広域ネットワークである。広域ネットワーク３０１によって、クラウドサービス内の各リソースは、データセンターのリージョンを跨いで相互に接続する。リソースマネージャー３０２は、サービスを構成するリソースを生成または削除したり、リソースの負荷に応じてリソース量の調整処理を実行したりする。リソース量の調整には、仮想マシンの台数を増やすスケールアウトと、仮想マシンに対するハードウェア資源の割り当てを増やすスケールアップなどが含まれる。さらに、リソース量の調整には、仮想マシンの台数を減らすスケールインと、仮想マシンに対するハードウェア資源の割り当てを減らすスケールダウンも含まれる。

ハードウェア資源は、ＣＰＵ（コア数）やメモリ（サイズ）、ストレージ（サイズ）などである。リソースマネージャー３０２は、リソースに対するリクエストの量を監視して、処理負荷に応じて自動でリソース量を調整することもできる。処理負荷とは、仮想マシンでの処理にかかる負荷であり、仮想マシンのＣＰＵ使用率やメモリ使用率、レスポンスの応答時間などを指す。監視されるリクエスト量や処理負荷が予め設定された条件に合致した場合にリソースマネージャー３０２により実行されるリソース量の調整のことを、オートスケールという。また、リソースマネージャー３０２は、後述のＤＮＳ３０４に登録されているＤＮＳレコードを書き換えるなどして、顧客環境１００からのリクエストを受け付けるリソースの宛先を切り替える。顧客環境１００からのリクエストを受け付けるリソースとして、後述のロードバランサ３１１や、仮想マシン３１４などがある。

ＤＮＳ３０４には、それぞれの仮想マシンやロードバランサのＩＰアドレスなどのアドレス情報とホスト名が登録されている。顧客環境１００内のコンピュータやネットワークデバイスは、インターネットなどのネットワークを経由して、ＤＮＳ３０４と通信を行う。前述のコンピュータやネットワークデバイスは、ＤＮＳ３０４に、リクエストの接続先となる処理システム内のロードバランサのホスト名に該当するアドレス情報を問合せて、ＤＮＳ３０４から返ってきたアドレス情報にリクエストを送る。受け付けたリクエストに対して、ＤＮＳ３０４は、ＤＮＳ名に紐づくＤＮＳレコードを使って、リクエストの接続先となる処理システム内のロードバランサを示すホスト名またはアドレス情報を返す。

リージョン３１０は、クラウド基盤１１０内のリージョンの一つである。システム管理者は、任意のリージョンを指定し、リソースマネージャー３０２に仮想マシン３１４やロードバランサ３１１などのリソースを生成するためのリクエストを行う。リソースマネージャー３０２は、前記指定されたリージョン内に指定されたリソースを生成する。後述のロードバランサ３１１や仮想マシン３１４は、システム管理者のリクエストによりリージョン３１０内に生成される。ロードバランサ３１１は、システムに対するリクエストを分散させる負荷分散装置として機能する。ロードバランサ３１１は、システムの規模やオートスケール設定に応じて複数生成されてもいい。

コンピュータ３１２は、ハイパーバイザー３１３および仮想マシン３１４が稼働するための情報処理装置である。ここで、ハイパーバイザー３１３とは、コンピュータを仮想化し、複数の異なるＯＳを並列に実行できるようにするソフトウェアのことである。また、仮想マシン３１４は、前述のハイパーバイザー３１３によってコンピュータ３１２上に起動される仮想コンピュータのことである。コンピュータ３１２は、リージョン３１０内に物理的に構築されるサーバマシンである。リージョン３１０内に物理的に構築されるコンピュータ３１２のマシンスペックや台数に応じて、リージョン３１０内で起動可能な特定のマシンスペックの仮想マシン３１４の数が変化する。仮想マシン３１４は、システム管理者が選択可能なＯＳ、アプリケーションサーバ、およびシステムやアプリケーション構成などを含むことができる。コンピュータ３１２の構成は、図２（Ａ）と同様であるため、ここでの説明は省略する。

＜システムの機能構成＞
図４は、画像形成装置を含むネットワークシステムの機能構成を説明するブロック図である。図４（Ａ）は、画像形成装置１０２の機能構成を示した図である。なお、本図に係る画像形成装置１０２のアプリケーションプログラムは、図２（Ｂ）の記憶装置２６３に記憶されており、ＲＡＭ２５２およびＲＯＭ２５３に読み出されＣＰＵ２５１によって実行される。

バックアップ処理部４０１は、画像形成装置上で動作するバックアップ処理を行うアプリケーションプログラムである。バックアップ処理部４０１は、後述の図５のバックアップ処理フローによって、バックアップデータを作成する処理、およびストレージサービス１０９にバックアップデータを送信する処理をもつ。

ここで、バックアップデータは、フルバックアップと差分バックアップの種別がある。フルバックアップは、画像形成装置１０２を構成するための設定値およびデータを含む。差分バックアップは、前回バックアップから変化のあった設定値およびデータのみを含む。初回バックアップ時およびリストア処理を行った直後は、フルバックアップを生成し、以降の運用中は、差分バックアップを生成、クラウドに送信する。これにより、画像形成装置１０２のバックアップデータ生成負荷とストレージサービス１０９への通信負荷が抑えられる。

リストア処理部４０２は、ストレージサービス１０９で管理するバックアップデータから画像形成装置の状態を復元（リストア）するアプリケーションプログラムである。リストア処理部４０２は、後述の図６のリストア処理フローによって、ストレージサービス１０９からバックアップデータを取得し、かつリストア処理を行う。

バックアップ処理部４０１およびリストア処理部４０２は、ともに画像形成装置１０２の操作部２５７を介してＵＩ画面およびＵＩ画面を介したユーザ操作を受け付ける機能を有する。また、バックアップ処理部４０１およびリストア処理部４０２は、バンドルアプリケーションとして画像形成装置１０２にプリインストールされたものであってもよい。画像形成装置１０２の初期セットアップ後に外部メディアもしくはインターネット経由でインストールされる形態で提供されてもよい。

図４（Ｂ）は、データ管理システムとしてのアプリケーションシステム１０８の機能構成を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。

イベント検知部４１０は、後述の図１４のフローによってアプリケーションシステムおよびストレージサービスの各種イベントに応じて、関数管理部４２０に登録された関数を呼び出す。イベントと関数の呼び出し条件情報は、保存部４１２の関数管理テーブルで管理される。キュー管理部４１１は、後述の図１０、図１１、図１２、および図１４のフローで用いる「マージ処理予約キュー」および「関数呼び出し失敗キュー」のリソースを管理する。もちろん、アプリケーションシステムの稼働に必要なキューリソースが管理されてもよい。保存部４１２は、イベント検知部４１０および関数管理部４２０で管理される各種関数が使用する各種データを格納する。保存部４１２は、他の機能の要求に応じて、各種データテーブルのレコードを追加・読出・更新・削除する。

ここで、表１～４は、保存部４１２内の各種データテーブルを示している。

表１は、バックアップサービス契約管理テーブルである。ここで、デバイスＩＤとは、画像形成装置１０２を一意に識別する識別子である。テナントＩＤは、画像形成装置１０２を保有するテナントを一意に識別するための識別子である。テナントＩＤは、アプリケーションシステム１０８が提供するＷｅｂサービスが、様々な組織・個人などに利用される場合、セキュアにリソースを分離するための単位である。このようなシステムは、一般にマルチテナントシステムと呼ばれる。バックアップサービス契約状態は、画像契約装置ごとのバックアップサービスの利用同意契約状態である。例えば、顧客が同意の上で、クラウドと連携したバックアップが有効な状態である場合は、「契約中」、そうでない場合は、「未契約」などの状態情報を格納する。

表２は、バックアップ設定管理テーブルである。ここで、デバイスＩＤは、デバイスを一意に識別する識別子である。バックアップ保持世代数は、ストレージサービス１０９が保持するバックアップデータの世代数である。バックアップ保存期間は、バックアップ処理部４０１が送信するバックアップデータを、ストレージサービス１０９が保持する期間である。バックアップ送信間隔は、バックアップ処理部４０１がバックアップデータを生成、送信するタイミングの日時情報である。日時情報は、「毎週木曜日 ２２：００」といった曜日での設定でもよいし、「毎日２２：００」などの日々の設定をできてもよい。表２のバックアップ設定管理テーブルで管理する設定情報は、画像形成装置１０２のバックアップ処理部が設定のためのＵＩを持ち、顧客がＵＩから設定可能である。また、アプリケーションシステムサーバのＷｅｂＵＩから設定出来てもよい。

表３は、画像形成装置ごとのバックアップデータ送信の履歴情報を管理するためのバックアップ履歴管理テーブルである。ここで、履歴ＩＤは、バックアップ履歴を一意に識別する識別子である。デバイスＩＤは、画像形成装置を一意に識別する識別子である。保存先パス情報は、署名付きＵＲＬ生成関数４２１が生成した署名付きＵＲＬ情報である。バックアップ種別は、画像形成装置１０２のバックアップ処理部４０１が送信するバックアップデータの種別情報である。例えば、「フルバックアップ」や「差分バックアップ」、後述の関数管理部４２０に登録されるマージ処理関数４２６のマージ処理によって生成されたバックアップ履歴の場合は、「フルバックアップ（マージ処理）」となる。

状態カラムは、バックアップ処理部４０１が送信するバックアップデータの保存状態である。例えば、バックアップデータがストレージサービス１０９に送信され、保存も完了している状態であれば、「保存済み」となる。署名付きＵＲＬは、発行されたが、バックアップデータがストレージサービス１０９に送信されていない場合は、「送信予約」となる。バックアップデータの世代数もしくは保存期間が閾値を超えた場合や、マージ処理によって不要となったバックアップデータが削除された場合は、「削除済み」となる。もちろん、その他の状態が管理されてもよい。更新日時は、バックアップ履歴情報が作成もしくは更新された時点の時刻情報である。

表４は、後述の関数管理部４２０で管理される関数の起動条件を管理するための関数管理テーブルである。ここで、関数起動ＩＤは、関数の起動条件を一意に識別する識別子である。関数起動条件は、任意の関数の起動条件が定義されるカラムである。例えば、署名付きＵＲＬ生成関数４２１は、任意のＵＲＬへのＰＯＳＴアクセス時に起動（呼び出し）するなどの条件を定義できる。また、ストレージサービスサーバ１０９の任意の保存領域にデータが保存された場合に起動する、といった条件も定義できる。

例えば、「ストレージサービスサーバ１０９のフルバックアップデータ保存領域にデータが保存された場合に、バックアップ完了関数４２４を呼び出す」などの定義が可能である。また、「ストレージサービスサーバ１０９の差分バックアップデータ保存領域にデータが保存された場合に、マージ処理予約関数４２５を呼び出す」などの定義が可能である。起動関数名は、関数起動条件が満たされた場合に起動される関数情報が定義される。最大同時実行数は、関数の同時実行するが定義される。
以上で保存部４１２が管理する各種データテーブルに関する説明を終わる。

図４（Ｂ）の説明に戻る。関数管理部４２０は、アプリケーションシステムの機能に必要な処理を記述した関数を管理する。関数管理部４２０は、関数を保存部４１２の関数管理テーブルに記載の任意のイベントに紐付けて関数同士を連動（呼び出す）することで、一連の処理が実行可能なように構成される。関数の起動は、図３の仮想マシン３１４がオンデマンドで起動され、仮想マシン３１４上で関数が実行される様態をとるものである。なお、仮想マシン３１４は、軽量なコンテナ型のアプリケーション実行環境であってもよい。システム管理者は、関数管理部４２０を介して任意の関数を登録し、関数内部もしくは他のサービスと相互に連動して動作するよう設定することができる。

署名付きＵＲＬ生成関数４２１は、後述の図７のフローによって画像形成装置１０２の要求に応じて署名付きＵＲＬを生成する関数である。バックアップ設定管理関数４２２は、画像形成装置１０２または関数管理部４２０で管理される他の関数の要求に応じて保存部４１２のバックアップ設定管理テーブルを参照・変更・削除・追加する関数である。バックアップ履歴管理関数４２３は、画像形成装置１０２または関数管理部４２０で管理される他の関数の要求に応じて保存部４１２のバックアップ履歴管理テーブルを参照・変更・削除・追加する関数である。

バックアップ完了関数４２４は、後述の図９のフローによってアプリケーションシステムがバックアップデータのアップロード処理の完了処理を記録する関数である。マージ処理予約関数４２５は、後述の図１０のフローによってアップロードされた差分バックアップのマージ処理を予約する関数である。マージ処理関数４２６は、後述の図１１のフローによってアップロードされた差分バックアップのマージ処理を行う関数である。マージ処理予約関数４２７は、後述の図１２のフローによって呼び出し（マージ処理）に失敗した関数を呼び出し、マージ処理を再度実行する関数である。

図４（Ｃ）は、ストレージシステムとしてのストレージサービス１０９の機能構成を示す。なお、本図に係るストレージサービス１０９のアプリケーションプログラムは、図２（Ａ）の記憶装置２１１に記憶され、ＲＡＭ２０２およびＲＯＭ２０３に読み出され、ＣＰＵ２０１により実行される。

バックアップデータ受信部４３０は、後述の図８のフローによって、バックアップ処理部４０１が生成したバックアップデータを受信する。バックアップデータ受信部４３０は、署名付きＵＲＬ検証部４３１、フルバックアップデータ保存部４３２および差分バックアップデータ保存部４３３を介して、バックアップデータの保存処理、マージ処理実行の判断、およびマージ処理関数の呼び出し等を行う。

署名付きＵＲＬ検証部４３１は、バックアップデータ受信部４３０を介してバックアップ処理部４０１から接続される署名付きＵＲＬの付帯情報が正しいことを検証する。ここで、署名付きＵＲＬの付帯情報とは、暗号化されたトークン情報、有効期限、アップロードまたはダウンロードするデータ名（ファイル名）、アップロードするファイルのサイズ情報などである。また署名付きＵＲＬ検証部４３１は、前述の付帯情報が改ざんされていないことも検証する。

フルバックアップデータ保存部４３２は、後述の図８のフローによって、フルバックアップデータの保存処理を行う。差分バックアップデータ保存部４３３は、後述の図８のフローによって、差分バックアップデータの保存処理およびマージ処理関数の呼び出しを行う。
以上で、図３の説明を終わる。

＜画像形成装置１０２のバックアップ処理のフロー＞
図５は、画像形成装置１０２のバックアップ処理の動作処理の例を示す。なお、本図に係る画像形成装置１０２のアプリケーションプログラムは、図２（Ｂ）の記憶装置２６３に記憶され、ＲＡＭ２５２およびＲＯＭ２５３に読み出され、ＣＰＵ２５１によって実行される。以下、図５を用いて、画像形成装置１０２のバックアップ処理部４０１が、アプリケーションシステム１０８から署名付きＵＲＬを取得し、該署名付きＵＲＬを用いてストレージサービス１０９にバックアップデータをアップロードする処理のフローを説明する。

ステップＳ５００において、バックアップ処理部４０１が、バックアップ要求を受け付ける。バックアップ要求受付は、ユーザの任意のＵＩ操作によるものであってもよい。また、バックアップ要求受付は、アプリケーションシステムの保存部４１２で管理されるバックアップ設定管理テーブルのバックアップ送信間隔カラムの設定に応じて予めスケジュールされたタイミングで受け付けてもよい。

ステップＳ５０１において、バックアップ処理部４０１が、ステップＳ５００で受け付けたバックアップ要求が、リストア後の初のバックアップであるか否かを判断する。リストア後初のバックアップ要求である場合は、ステップＳ５０２に処理を進め、そうでない場合はステップＳ５０４に処理を進める。

ステップＳ５０２において、バックアップ処理部４０１が、画像形成装置１０２のフルバックアップを生成する。フルバックアップに含まれるデータとしては、例えば、画像形成装置１０２のネットワーク設定値情報やライセンス情報、インストール済みのアプリケーション情報、アプリケーションに付随する設定値情報などが含まれる。その他画像形成装置１０２が保持する顧客特有情報を顧客が同意の上で含めてもよい。

ステップＳ５０３において、バックアップ処理部４０１が、アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１に接続し、フルバックアップのデータ送信に必要な署名付きＵＲＬを取得する。このとき、アプリケーションシステム１０８へのリクエストヘッダに、フルバックアップデータの送信である旨のフラグ情報を付加する。

ステップＳ５０４において、バックアップ処理部４０１が、ステップＳ５００で受け付けたバックアップ要求が画像形成装置１０２において初めてのバックアップ処理であるか否か、またはユーザ操作による即時バックアップ要求であるか否かを判断する。初めてのバックアップ処理である、もしくはユーザ操作による即時バックアップ要求であると判断した場合は、ステップＳ５０５に処理を進める。そうでない場合は、ステップＳ５０５に処理を進める。

ステップＳ５０５において、バックアップ処理部４０１が、前回生成したフルバックアップないし差分バックアップからの差分情報で構成される差分バックアップデータを生成する。差分バックアップの形態として、例えば、操作ログのような形で前回バックアップからの差分データを生成してもよい。もちろん、前回バックアップからの差分を判別できる形態であれば、その他の形態であってもよい。

ステップＳ５０６において、バックアップ処理部４０１が、アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１に接続し、差分バックアップのデータ送信に必要な署名付きＵＲＬを取得する。このとき、アプリケーションシステム１０８へのリクエストヘッダに、差分バックアップデータの送信である旨のフラグ情報を付加する。

ステップＳ５０７において、バックアップ処理部４０１が、ステップＳ５０３もしくはステップＳ５０６で取得した署名付きＵＲＬを用いて、ストレージサービス１０９のバックアップデータ受信部４３０に接続する。そして、バックアップ処理部４０１は、ステップＳ５０２もしくはステップＳ５０５で生成したバックアップデータを送信する。

ステップＳ５０８において、バックアップ処理部４０１が、ステップＳ５０２もしくはステップＳ５０５で生成した画像形成装置１０２内のバックアップデータを削除する。
以上で、図５の説明を終わる。

＜画像形成装置１０２のリストア処理のフロー＞
図６は、画像形成装置１０２のリストア処理の動作処理の例を示す。なお、本図に係る画像形成装置１０２のアプリケーションプログラムは、図２（Ｂ）の記憶装置２６３に記憶され、ＲＡＭ２５２およびＲＯＭ２５３に読み出され、ＣＰＵ２５１により実行される。以下、図６を用いて、画像形成装置１０２のリストア処理部４０２が、アプリケーションシステム１０８から署名付きＵＲＬを取得し、該署名付きＵＲＬを用いてストレージサービス１０９にバックアップデータをアップロードする処理のフローを説明する。

ステップＳ６００において、画像形成装置１０２のリストア処理部４０２が、アプリケーションシステム１０８のバックアップ履歴管理関数４２３から自身のバックアップ履歴情報を取得する。ステップＳ６００は、ユーザによってリストアアプリケーションが起動されたタイミングで実行される。

ステップＳ６０１において、リストア処理部４０２が、ステップＳ６００で取得したバックアップ履歴情報をユーザにＵＩで提示する。ユーザは、画像形成装置１０２をどのバックアップでリストアしたいかをＵＩを介して選択する。

ここで、ステップＳ６０１のＵＩの例を、図１３を用いて説明する。

図１３は、画像形成装置１０２の操作部２５７におけるパネルに表示されるステップＳ６０１のＵＩの例である。１３０２は、リストア処理部４０２がステップＳ６００で取得したバックアップ履歴をリスト表示している。１３０２のリストの各アイテムは、パネルのタッチもしくはポインティングデバイスによって選択状態にすることができる。１３０３は、選択状態のアイテムであってバックアップの一時点を示している。１３０４は、各アイテムの詳細情報画面への遷移リンクである。詳細情報画面では、任意のバックアップ時点の差分内容を確認できてもよい。１３０５は、決定ボタンである。決定ボタンが押下されると、選択状態のアイテム（バックアップ時点）を用いて、ステップＳ６０２～Ｓ６０５のリストア処理が実行される。１３０６は、キャンセルボタンである。キャンセルボタンが押下されると、リストア処理部４０２はＵＩ表示およびリストア処理を終了する。

図１３のＵＩに表示するバックアップ履歴は、バックアップ履歴管理テーブルのバックアップ種別カラムが「フルバックアップ」または「フルバックアップ（マージ処理）」となっているバックアップ履歴である。差分バックアップは、選択肢に含めない。ＵＩは、バックアップ履歴をリスト表示してもよい。また、ＵＩは、一日に何度もバックアップが行われるような設定であれば、はじめに日毎の選択肢を表示し、ドリルダウンしてリストアに用いるバックアップを選択してもよい。また、バックアップがスケジュール実行されたものかユーザが任意でバックアップしたか否かによって、表示の仕方を変えてもよい。例えば、ユーザが任意でバックアップした履歴に関しては、リスト表示の先頭に提示するなどしてもよい。
以上で、図１３の説明を終わる。

図６の説明に戻る。ステップＳ６０２において、リストア処理部４０２が、ステップＳ６０１で提示したＵＩによってユーザが任意のバックアップを選択したことを検知する。ステップＳ６０３において、リストア処理部４０２が、アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１に接続する。また、ステップＳ６０１において、選択されたバックアップデータのダウンロード用の署名付きＵＲＬを取得する。このとき、アプリケーションシステム１０８へのリクエストヘッダに、バックアップデータの取得要求である旨のフラグ情報と、どのバックアップデータに関する署名付きＵＲＬであるかの情報を付加する。例えば、ステップＳ６００において取得した履歴ＩＤが付加される。

ステップＳ６０４において、リストア処理部４０２が、ステップＳ６０３で取得した署名付きＵＲＬを用いてストレージサービス１０９のフルバックアップデータ保存４３２からダウンロードする。ステップＳ６０５において、リストア処理部４０２が、ステップＳ６０４で取得したバックアップデータを用いて画像形成装置１０２のストレージ領域をリストアする処理を行う。なお、ステップＳ６０５は、リストアにおける設定情報の復元、アプリケーションの復元、アプリケーション設定の復元、再起動などのリストア処理に必要な処理を含む。
以上で、図６の説明を終わる。

＜アプリケーションシステム１０８の関数呼び出しのフロー＞
図１４は、アプリケーションシステム１０８のイベント検知部４１０が、関数管理部４２０で管理される各関数を呼び出す処理の例を示す。なお、本図に係るアプリケーションシステム１０８のアプリケーションプログラムは、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図１４を用いて、アプリケーションシステム１０８のイベント検知部４１０が、関数管理部４２０で管理される各関数を呼び出す処理を説明する。

ステップＳ１４０１において、イベント検知部４１０が、保存部４１２の関数管理テーブルの関数起動条件を満たすイベントが発生したか否かを検知する。検知するイベントの種類として、例えば、任意のＵＲＬへのＧＥＴもしくはＰＯＳＴによるアクセスイベント、ストレージサービスサーバ１０９の任意の保存領域にデータが保存される保存完了イベントなどが挙げられる。ステップＳ１４０１は、その他アプリケーションシステム１０８に関わる様々なイベント処理を監視する。アプリケーションシステム１０８においてイベントが発生した場合、イベント検知部４１０が、当該イベントが保存部４１２の関数管理テーブルの関数起動条件を満たすイベントであるか否かを判断する。関数起動条件を満たすイベントであると判断した場合は、処理をステップＳ１４０２に進め、そうでない場合は、イベントの監視を継続する。

ステップＳ１４０２において、ステップＳ１４０１で検知した関数起動条件に紐づく関数を呼び出す。ステップＳ１４０３において、ステップＳ１４０２の関数呼び出し処理に失敗したか否かを判断する。関数呼び出し処理に失敗したと判断した場合は、ステップＳ１４０４に進み、そうでない場合は、処理を終了する。ここで、関数呼び出しに失敗する要因として、例えば、図３におけるクラウド基盤１１０の仮想マシン（コンテナ）３１４がリソース不足により呼び出せない例が挙げられる。もちろん、その他の理由で関数の呼び出しの失敗を検知してもよい。

ステップＳ１４０４において、関数呼び出し失敗キューにメッセージを追加する。メッセージには、呼び出しに失敗した関数の情報および、前記関数に渡す予定のパラメータ情報を含める。
以上で、図１４の説明を終わる。

＜アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１の処理フロー＞
図７は、アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１の動作処理の例を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図７を用いて、アプリケーションシステム１０８が画像形成装置１０２のバックアップ処理部４０１およびリストア処理部４０２の要求に応じて署名付きＵＲＬを生成する処理のフローを説明する。なお、署名付きＵＲＬ生成関数４２１は、関数管理テーブルの関数起動条件に従い、画像形成装置１０２のバックアップ処理部４０１およびリストア処理部４０２のＨＴＴＰ要求に応じて呼び出される関数である。

ステップＳ７００において、アプリケーションシステム１０８の署名付きＵＲＬ生成関数４２１が、図５のＳ５０３もしくはＳ５０６、および図６のＳ６０３における署名付きＵＲＬの取得要求を受信する。ステップＳ７０１において、署名付きＵＲＬ生成関数４２１が、保存部４１２のバックアップ設定管理テーブルを参照し、署名付きＵＲＬ取得要求元の画像形成装置のバックアップサービス契約状態を取得する。画像形成装置のバックアップサービス契約状態が契約中の場合は、処理をステップＳ７０１に進み、そうでない場合は、処理を終了する。処理を終了する場合、画像形成装置１０２には、認可エラーの旨の情報を返す。

ステップＳ７０２において、署名付きＵＲＬ生成関数４２１が、ステップＳ７００にて受信した署名付きＵＲＬ取得要求がリストアのための署名付きＵＲＬ取得要求であるか否かを判断する。ステップＳ７００にて受信した署名付きＵＲＬ取得要求がリストアのための署名付きＵＲＬ取得要求であると判断した場合は、処理をステップＳ７０３に進める。そうでない場合は、処理をステップＳ７０４に進める。ステップＳ７００にて受信した署名付きＵＲＬ取得要求がリストアのための署名付きＵＲＬ取得要求であるか否かを判断する手段としては、次のようなものがある。例えば、その手段は、図６のステップＳ６０３の処理において、リクエストヘッダにリストア処理フラグを含めることで実現してもよいし、その他のリストアと判断可能な付随情報によって実現してもよい。

ステップＳ７０３において、署名付きＵＲＬ生成関数４２１が、リストア処理部４０２に返却するためのバックアップデータ取得用の署名付きＵＲＬを生成する。このとき、ステップＳ７００の取得要求のリクエストヘッダに含まれる履歴ＩＤ情報を元にバックアップ履歴管理テーブルを参照して、任意のバックアップデータに紐づく取得用の署名付きＵＲＬを発行する。

ステップＳ７０４において、署名付きＵＲＬ生成関数４２１が、ステップＳ７００にて受信した署名付きＵＲＬ取得要求がフルバックアップデータの送信のための署名付きＵＲＬ取得要求であるか否かを判断する。フルバックアップデータの送信のための署名付きＵＲＬ取得要求であると判断した場合は、ステップＳ７０６に進み、そうでない場合は、ステップＳ７０５に進む。このとき、フルバックアップデータの送信のための署名付きＵＲＬ取得要求であるか否かを判断する手段として、図５のステップＳ５０３でリクエストヘッダに付加されたフラグ情報を用いてもよい。

ステップＳ７０５において、署名付きＵＲＬ生成関数４２１が、差分バックアップデータ送信用の署名付きＵＲＬを生成する。ステップＳ７０６において、署名付きＵＲＬ生成関数４２１が、フルバックアップデータ送信用の署名付きＵＲＬを生成する。ステップＳ７０７において、署名付きＵＲＬ生成関数４２１が、保存部４１２のバックアップ履歴管理テーブルを更新する。新規履歴ＩＤを発番し、デバイスＩＤ、保存先パス情報、バックアップ種別、状態、および更新日時を含めた情報を追加する。このとき、状態カラムには「送信予約」が記録される。

ステップＳ７０８において、署名付きＵＲＬ生成関数４２１が、各ステップＳ７０６、Ｓ７０５、Ｓ７０３で生成した署名付きＵＲＬを画像形成装置１０２に返却する。
以上で、図７の説明を終わる。

＜ストレージサービス１０９のバックアップデータ保存処理のフロー＞
図８は、ストレージサービス１０９のバックアップデータ保存処理の例を示す。なお、本図に係るストレージサービス１０９のアプリケーションプログラムは、図２（Ａ）の記憶装置２１１に記憶され、ＲＡＭ２０２およびＲＯＭ２０３に読み出され、ＣＰＵ２０１により実行される。以下、図８を用いて、ストレージサービス１０９のバックアップデータ受信部４３０が、画像形成装置１０２のバックアップ処理部４０１およびリストア処理部４０２の要求に応じてバックアップデータを保存する処理のフローを説明する。

ステップＳ８００において、バックアップデータ受信部４３０が、画像形成装置１０２のバックアップ処理部４０１からバックアップデータの送信要求を受け付ける。ステップＳ８０１において、署名付きＵＲＬ検証部４３１が、ステップＳ８０１で受け付けたバックアップデータ送信要求の署名付きＵＲＬの付帯情報を検証する。検証する内容として、例えば、署名付きＵＲＬの付帯情報が正しく復号可能で改ざんされていないこと、有効期限が期限内で有るか否かであること、などが挙げられる。前記検証結果で署名付きＵＲＬが正しいと判断された場合は、処理をステップＳ８０２に進める。そうでない場合は、処理を終了する。処理を終了する場合、画像形成装置１０２には、認可エラーの旨の情報を返す。

ステップＳ８０２において、バックアップデータ受信部４０２が、ステップＳ８００にて受信したバックアップデータ送信要求がフルバックアップデータの送信要求であるか否かを判断する。フルバックアップデータの送信要求であると判断した場合は、ステップＳ８０５に進み、そうでない場合は、ステップＳ８０３に進む。このとき、フルバックアップデータの送信のための署名付きＵＲＬ取得要求であるか否かを判断する手段として、図５のＳ５０７でリクエストヘッダに付加されたフラグ情報を用いてもよい。

ステップＳ８０３において、差分バックアップデータ保存部４３３が、画像形成装置１０２のバックアップ処理部４０１からバックアップデータの送信要求を許可する。また、差分バックアップデータ保存部４３３は、差分バックアップデータを受信し、署名付きＵＲＬに付帯する保存先パス情報に従ってデータを保存する。

ステップＳ８０５において、フルバックアップデータ保存部４３２が、画像形成装置１０２のバックアップ処理部４０１からバックアップデータの送信要求を許可する。また、フルバックアップデータ保存部４３２は、フルバックアップデータを受信し、署名付きＵＲＬに付帯する保存先パス情報に従ってデータを保存する。
以上で、図８の説明を終わる。

＜アプリケーションシステム１０８のバックアップ完了関数４２４の処理フロー＞
図９は、アプリケーションシステム１０８のバックアップ完了関数４２４の処理の例を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図９を用いて、アプリケーションシステム１０８の関数管理部４２０に登録された関数であるバックアップ完了処理関数のフローを説明する。なお、バックアップ完了処理関数４２４は、関数管理テーブルの関数起動条件に従い、図８のバックアップデータ保存処理におけるステップＳ８０５の処理の終了後に呼び出される関数である。

ステップＳ９００において、バックアップ完了関数４２４が、保存部４１２のバックアップ履歴管理テーブルを更新する。この時、バックアップ完了関数４２４は、図８のバックアップデータ保存処理におけるステップＳ８０６の処理でバックアップデータの保存先パス情報をパラメータとして受け取る。また、バックアップ完了関数４２４は、前記保存先パス情報と合致するレコードの「状態」カラムを「保存済み」に更新する。更新日時カラムも更新する。
以上で、図９の説明を終わる。

＜アプリケーションシステム１０８のマージ処理予約関数４２５の処理フロー＞
図１０は、アプリケーションシステム１０８のマージ処理予約関数４２５の処理の例を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図１０を用いて、アプリケーションシステム１０８の関数管理部４２０に登録された関数であるマージ処理予約関数のフローを説明する。なお、マージ処理予約関数４２５は、関数管理テーブルの関数起動条件に従い、図８のバックアップデータ保存処理におけるステップＳ８０３の処理の終了後に呼び出される関数である。Ｓ８０５の処理の終了時にはマージ処理が不要なため同関数の呼び出しはない。

ステップＳ１０００において、マージ処理予約関数４２５が、保存部４１２のバックアップ履歴管理テーブルを更新する。この時、マージ処理予約関数４２５は、図８のバックアップデータ保存処理におけるステップＳ８０４の処理でバックアップデータの保存先パス情報をパラメータとして受け取る。また、マージ処理予約関数４２５は、前記保存先パス情報と合致するレコードの「状態」カラムを「保存済み」に更新する。更新日時カラムも更新する。

ステップＳ１００１において、マージ処理予約関数４２５が、予め用意されたマージ処理予約キューにメッセージを追加する。メッセージには、ステップＳ１０００で更新したレコードの履歴ＩＤ情報を含める。
以上で、図１０の説明を終わる。

＜アプリケーションシステム１０８のマージ処理関数４２６の処理フロー＞
図１１は、アプリケーションシステム１０８のマージ処理関数４２６の例を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図１１を用いて、アプリケーションシステム１０８の関数管理部４２０に登録された関数であるマージ処理予約関数のフローを説明する。なお、マージ処理関数は、関数管理テーブルの関数起動条件に従い、定期的に呼び出される関数である。

ステップＳ１１００において、マージ処理関数４２６が、マージ処理予約キューからメッセージを取得する。ステップＳ１１０１において、マージ処理関数４２６が、ステップＳ１１００で取得したメッセージに含まれる履歴ＩＤ情報をもとに、バックアップ履歴管理テーブルから関連する画像形成装置のバックアップ履歴情報リストを取得する。

ステップＳ１１０２において、マージ処理関数４２６が、ステップＳ１１０１で取得したバックアップ履歴情報リストの中に、未マージ、かつステップＳ１１００で取得した履歴ＩＤよりも古い差分バックアップの情報が存在するか否かを判断する。ここで、未マージであるか否かの判断は、バックアップ履歴管理テーブルの状態カラムが「削除済み」であるか否かによって判断してもよい。未マージ、かつステップＳ１１００で取得した履歴ＩＤよりも古い差分バックアップの情報が存在すると判断した場合は、ステップＳ１１０３に処理を進め、そうでない場合は、ステップＳ１１０５に処理を進める。

ステップＳ１１０３において、マージ処理関数４２６が、マージ処理予約キューからステップＳ１１００で取得したメッセージを削除する。なお、マージ処理予約キューのメッセージは、プログラムで意図的に削除処理を行わなければ消えないものとする。

ステップＳ１１０４において、マージ処理関数４２６が、マージ処理予約キューにステップＳ１１００で取得したメッセージを再度追加する。なお、ステップＳ１１０２～ステップＳ１１０４の一連の処理は、図８のステップＳ８０３の処理後でマージ処理関数の呼び出しに失敗した場合を考慮した処理である。呼び出しに失敗した場合には、ステップＳ８０３の処理に対応する差分バックアップデータに対する図１０の処理がスキップされていることになる。すなわち、このＳ１１０３～Ｓ１１０４処理では、差分バックアップ順番にマージ処理することで、マージ処理によって生成されるフルバックアップデータの整合性を合わせることができる。

ステップＳ１１０５において、マージ処理関数４２６が、ステップＳ１１００で取得した履歴ＩＤに紐づく差分バックアップと、ステップＳ１１０１で取得した直近保存されたフルバックアップデータとをマージし、新たなフルバックアップデータを生成する。フルバックアップデータの生成に成功した場合は、マージ処理関数４２６が、ストレージサービス１０９のフルバックアップデータ保存部４３２に生成したフルバックアップデータを保存する。

ここで、前記マージ処理は、例えば、差分バックアップデータに含まれる画像形成装置の操作ログをトレースし、画像形成装置に関する最終時点の設定値情報を抽出し、前記直近のフルバックアップデータに前記設定値情報を反映させることで成されてもよい。

ステップＳ１１０６において、マージ処理関数４２６が、保存部４１２のバックアップ履歴管理テーブルを更新する。ステップＳ１１０５のフルバックアップデータに紐づく新規履歴ＩＤを発番し、デバイスＩＤ、保存先パス情報、バックアップ種別、状態、更新日時を含めた情報を追加する。このとき、バックアップ種別カラムには「フルバックアップ（マージ処理）」が記録され、状態カラムには「保存済み」が記録される。

ステップＳ１１０７において、マージ処理関数４２６が、マージ処理予約キューからステップＳ１１００で取得したメッセージを削除する。ステップＳ１１０８において、マージ処理関数４２６が、ステップＳ１１０５でマージ処理を行う際に使用した差分バックアップデータをストレージサービス１０９の差分バックアップデータ保存部４３３から削除する。ステップＳ１１０９において、マージ処理関数４２６が、保存部４１２のバックアップ履歴管理テーブルを更新する。ステップＳ１１０８で削除した差分バックアップデータに紐づく履歴ＩＤのレコードの状態カラムを「削除済み」に更新する。
以上で、図１１の説明を終わる。

＜アプリケーションシステム１０８の関数呼び出しリトライ関数４２７の処理フロー＞
図１２は、アプリケーションシステム１０８の関数呼び出しリトライ関数４２７の例を示す。なお、本図に係るアプリケーションシステム１０８の関数群は、図３の仮想マシン（コンテナ）３１４で仮想的に構成されるメモリ領域に読み出され、仮想マシン（コンテナ）３１４の仮想ＣＰＵによって実行される。以下、図１２を用いて、アプリケーションシステム１０８の関数管理部４２０に登録された関数である関数呼び出しリトライ関数４２７のフローを説明する。なお、関数呼び出しリトライ関数４２７は、関数管理テーブルの関数起動条件に従い、定期的に呼び出される関数である。

ステップＳ１２００において、関数呼び出しリトライ関数４２７が、関数呼び出し失敗キューからメッセージを取得する。ステップＳ１２０１において、関数呼び出しリトライ関数４２７が、ステップＳ１２００で取得したメッセージから呼び出しに失敗した関数情報を取得する。ここで、関数情報は、例えば、関数を一意に識別可能な関数名などの情報である。ステップＳ１２０２において、関数呼び出しリトライ関数４２７が、ステップＳ１２００で取得したメッセージに含まれるパラメータ情報を用いてステップＳ１２０１で取得した呼び出しに失敗した関数を呼び出し、リトライを再度実行する。

ステップＳ１２０３において、関数呼び出しリトライ関数４２７が、ステップＳ１２０２の処理で関数呼び出しに失敗したか否かを判断する。関数呼び出し処理に失敗したと判断した場合はステップＳ１２０４に進み、そうでない場合は、処理を終了する。ステップＳ１２０４において、関数呼び出しリトライ関数４２７が、関数呼び出し失敗キューからステップＳ１２００で取得したメッセージを削除する。なお、ステップＳ１２００で取得されたメッセージは、ステップＳ１２０４で明示的に削除されない限り、一定時間後に、再度関数呼び出し失敗キューから取得可能となる。
以上で、図１２の説明を終わる。

（その他の実施例）
本発明は、上述の例の１以上の機能を実現するプログラムを、ネットワークまたは記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータでの１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

（むすび）
以上、本実施例によれば、画像形成装置１０２が署名付きＵＲＬを用いてストレージサービス１０９にバックアップデータをアップロードしたタイミングで、アプリケーションシステム１０８が差分バックアップデータのマージ処理を実行する。また、画像形成装置１０２がリストアを要する際は、マージ済みのフルバックアップデータによってリストア処理を行う。これにより、画像形成装置１０２は、ストレージサービス１０９から必要な全ての差分バックアップデータを取得する必要がなくなる。また、画像形成装置側でのマージ処理が不要となるため、結果として、リストア完了までに要する時間が短縮される。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (7)

1. ネットワークデバイスと、ストレージシステムと、データ管理システムと、を含むシステムであって、
   前記ネットワークデバイスは、
   前記ネットワークデバイスの記憶装置に格納されるデータをバックアップデータとして保存するための保存先を示す情報を要求する第１要求を行う第１要求手段と、
   前記第１要求に従い受信した前記保存先を示す情報を用いて、前記記憶装置に格納されるデータを送信する送信手段と、を有し、
   前記データ管理システムは、
   前記第１要求に応じて前記ネットワークデバイスのバックアップデータを保存するための保存先を示す情報を生成し、前記保存先を示す情報を前記ネットワークデバイスに応答する第１応答手段を有し、
   前記ネットワークデバイスから前記生成された保存先を示す情報を用いて送信されたデータが差分バックアップデータであり、当該差分バックアップデータが前記ストレージシステムに保存されたことを示すイベントに応じて呼び出された関数に基づき、前記ストレージシステムですでに管理されているフルバックアップデータと当該差分バックアップデータとのマージ処理を実行するためのメッセージが管理され、当該管理されたメッセージに基づき前記マージ処理が実行され、
   前記イベントに応じた前記関数の呼び出しに失敗した場合、さらに呼び出される別の関数の実行に基づき、前記マージ処理を実行するためのメッセージが管理される、
   ことを特徴とするシステム。
2. 前記第１応答手段は、前記ネットワークデバイスからの前記第１要求が前記差分バックアップデータを保存するための保存先を示す情報のための要求であった場合、前記差分バックアップデータの保存のために予め用意される前記ストレージシステムの保存先を示す情報を前記ネットワークデバイスに応答することを特徴とする、
   請求項１に記載のシステム。
3. 前記ネットワークデバイスから送信されたデータがフルバックアップデータであった場合には、前記関数の呼び出しが行われないことを特徴とする、
   請求項１に記載のシステム。
4. 前記ネットワークデバイスは、さらに、
   前記データ管理システムにリストアのために第２要求を行う第２要求手段と、
   前記第２要求に従い受信した保存先を示す情報を用いて、前記ストレージシステムに保存されるフルバックアップデータを取得する取得手段と、を有することを特徴とする、
   請求項１から３のいずれか１項に記載のシステム。
5. 前記データ管理システムは、さらに、前記第２要求に応じて、前記ストレージシステムにおける前記フルバックアップデータの保存先を示す情報を前記ネットワークデバイスに応答する第２応答手段を有することを特徴とする、
   請求項４に記載のシステム。
6. 前記バックアップデータは、前記ネットワークデバイスの設定情報、アドレス情報、およびインストールされたアプリケーションに関する情報の少なくとも１つを含むことを特徴とする、
   請求項１から５のいずれか１項に記載のシステム。
7. ネットワークデバイスと、ストレージシステムと、データ管理システムと、を含むシステムを用いる方法であって、
   前記ネットワークデバイスにおける、前記ネットワークデバイスの記憶装置に格納されるデータをバックアップデータとして保存するための保存先を示す情報を要求する第１要求を行う工程と、
   前記データ管理システムにおける、前記第１要求に応じて前記ネットワークデバイスのバックアップデータを保存するための保存先を示す情報を生成し、前記保存先を示す情報を前記ネットワークデバイスに応答する工程と、
   前記ネットワークデバイスにおける、前記第１要求に従い受信した前記保存先を示す情報を用いて、前記記憶装置に格納されるデータを送信する工程と、を有し、
   前記ネットワークデバイスから前記生成された保存先を示す情報を用いて送信されたデータが差分バックアップデータであり、当該差分バックアップデータが前記ストレージシステムに保存されたことを示すイベントに応じて呼び出された関数に基づき、前記ストレージシステムですでに管理されているフルバックアップデータと当該差分バックアップデータとのマージ処理を実行するためのメッセージを管理し、当該管理されたメッセージに基づき前記マージ処理が実行され、
   前記イベントに応じた前記関数の呼び出しに失敗した場合、さらに呼び出される別の関数の実行に基づき、前記マージ処理を実行するためのメッセージが管理される、
   ことを特徴とする方法。

Images