JP2020048050A - 管理システム及び管理方法 - Google Patents

Abstract

【課題】イベント駆動型のサーバーレスシステムにおいて、クライアントのデバイスから定期的に送信されるべき定期送信データが所定期間送信されていないことを検出して、登録された通知先に通知するデバイスの管理システムを提供する。【解決手段】有効期限テーブルに書き込むエンティティ毎に通知を実行する時刻を有効期限として設定し、有効期限が経過したことをイベントとして、当該エンティティを削除するとともに、登録先への通知を実行する。【選択図】図４

Description

本発明は、ネットワークデバイスの管理システム及び管理方法に関するものであり、特に、クラウドサービスにおけるイベント駆動型コンピューティングサービスにおいて、デバイスについての定期的な処理が行われない場合の管理システムに関する。

従来、ＭＦＰ（Multifunction Peripheral）のような画像処理装置を管理するシステムにおいて、毎日所定の時刻（例えば、午前２時）になった時点で、各ＭＦＰのバックアップ処理の状況を確認するものが知られている。このようなシステム（バックアップリストアシステム）では、バックアップ処理に失敗したデバイスがあった場合、そのデバイスを割り出して、管理者などにバックアップ処理に失敗した旨のメールを送信する。
こうしたバックアップリストアシステムを提供するサービス提供者としては、ＭＦＰを保有する自社の契約顧客に対してはできるだけ低価格でサービスを提供したいため、バックアップリストアシステムの運用は低コストで実現したい。

ところで、近年、サーバー等のインフラストラクチャを複数人で共有して利用することで、ハードウェアのコストを下げる仮想化技術が発展している。その中でも特に、ハードウェアを関数単位で共有することで、サーバーの利用効率を更に高める、サーバーレスと呼ばれる技術が普及している。例えば、AWS Lambdaのようなサーバーレスのシステムを用いれば、常駐のサービスを構築して実現するよりも、コストを安く抑えることができる。

そこで、バックアップリストアシステムでもサーバーレス技術を用いてサービスを提供することが考えられる。
ただし、一般に、サーバーレス技術においては、関数を共有する設計であるため、単一の関数がハードウェア資源を専有し続けることがないように所定時間でタイムアウトする設計となっている。

特許文献１には、クライアント・サーバーシステムにおいて、クライアントが定期的にサーバーに対して状態通知を行うシステムが開示されている。特許文献１おいては、サーバーは、クライアントから定期的な状態通知が送信されてこないことを検出すると、ユーザーに通知を行う。この検出は、すべてのクライアントに対して最終ステータスの受信時刻を定期的に取得して、取得した時刻が現在時刻よりも一定期間以上前の時刻であるか否かにより行われる。

特開２００８−７７３２４号公報

しかし、特許文献１のようなシステムにおいては、処理のフロー上、クライアントの台数が増加することに伴い、状態通知のために行う処理の実行時間も増大してしまう。
また、先に述べたとおり、サーバーレスシステムにおいては関数のタイムアウトが存在するため、上記のようなシステムをサーバーレスシステムにそのまま適用するとタイムアウトが発生する可能性が高い。そのため、上記のようなシステムをサーバーレスシステムにそのまま適用することはできない。
また、バックアップファイルの送信に失敗した場合、デバイス（ＭＦＰ）側でその失敗が検出できないケースがある。そのようなケースでは、ユーザーは送信の失敗をクラウドサービス上で確認する必要がある。

そこで、本発明では、クライアント・サーバー型のサーバーレスシステムにおいて、ネットワークデバイスから定期的に送信されるデータが処理されていないことを検出して通知するシステムを提供することを目的とする。

本発明は、複数のネットワークデバイスからのデータを受信して、前記複数のネットワークデバイスを管理する管理システムであって、データベースに、各ネットワークデバイスについて、前記各ネットワークデバイスからデータを受信する時刻に対応する第１の時間情報を、有効期限として書き込む第１の書き込み手段と、前記データベースにおける前記有効期限が過ぎたことに従うイベントに応じて実行される第１の関数に従い、前記有効期限に対応するネットワークデバイスに係る通知を実行する通知手段と、前記第１の関数に従い、前記データベースに、前記通知の対象となったネットワークデバイスについて、該ネットワークデバイスからデータを受信する次回の時刻に対応する第２の時間情報を、前記有効期限として書き込む第２の書き込み手段と、を有し、前記第１の関数は、前記第２の時間情報を前記有効期限として書き込みをした後に終了することを特徴とする。

本発明により、タイムアウトが存在するクライアント・サーバー型のサーバーレスシステムにおいて、管理するネットワークデバイスの台数が増加しても、エラーが発生した場合の通知を確実に実行することが可能となる。

管理システム全体の構成例を示す図である。 各サーバーのハードウェアの構成例を示す図である。 ＭＦＰのハードウェアの構成例を示す図である。 各機器のソフトウェアモジュールの構成例を示す図である。 有効期限切れデータを削除する処理を示すフローチャートである（実施例１）。 有効期限切れデータを削除する処理を示すフローチャートである（実施例２）。る。 各機器のソフトウェアモジュールの構成例を示す図である（実施例３）。 有効期限切れデータを削除する処理を示すフローチャートである（実施例３）。 データを集約して通知する処理を示すフローチャートである。

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

図１は、本管理システム全体の構成例を示す図である。

本システムは、ＭＦＰ１０１、アプリケーションシステム１１０及びネットワーク１０２から構成される。
ＭＦＰ１０１は、本システムにおいて管理されるネットワークデバイスの一例であり、ネットワーク１０２を介して、アプリケーションシステム１１０に接続される。ＭＦＰ１０１は、例えばバックアップデータやプリント枚数カウンタデータなどに代表される、ＭＦＰ１０１上で生成されるデータを、ネットワーク１０２を通じて、アプリケーションシステム１１０に定期的に送信する。なお、図１ではＭＦＰ１０１は１つのみを図示しているが、本発明においては、多数のＭＦＰ１０１がネットワーク１０２に接続されることが想定されている。また、ネットワークデバイスとしては、ＭＦＰに限られず、各種のＩＣＴ機器を対象とすることもできる。

ネットワーク１０２は、いわゆる通信ネットワークである。ネットワーク１０２は、インターネットなどのＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線などのいずれか、または、これらの組み合わせにより実現される。

アプリケーションシステム１１０は、ＡＰＩサーバー１１１、関数サーバー１１２、データベースサーバー１１３、スケジュールサーバー１１４の各サーバーからなるサーバー群、及び内部ネットワーク１１５から構成される。また、アプリケーションシステム１１０は、例えば、クラウドサービスにより実現されるシステムである、

ＡＰＩ（Application Programming Interface）サーバー１１１は、ＭＦＰ１０１からの要求を解析し、要求を実現する関数を関数サーバー１１２から選択して実行する。一般的には、ＨＴＴＰに代表されるプロトコルを受信し、ＵＲＩからアクセスしたいリソースを特定して、そのリソースを操作可能な関数を実行する。
ＡＰＩサーバーが受信可能なプロトコルは、ＨＴＴＰに限定されず、例えばＷｅｂＳｏｃｋｅｔのような双方向通信可能なプロトコルや、ＵＤＰなどの単方向プロトコルを利用した通信であってもよい。本実施例におけるＡＰＩサーバー１１１は、ＨＴＴＰプロトコルを利用するサーバーであるものとして、具体的に説明する。

関数サーバー１１２は、任意のイベントと、そのイベントが発生した時に実行する関数とを紐づけて管理する。更に、関数サーバー１１２は、内部ネットワーク１１５で接続された各サーバーにおいて発生したイベントをトリガーとして、イベントに紐づけられて登録されている関数を実行する。
更に、関数サーバー１１２は、登録されている関数の実行が完了した後に、関数が利用したリソースを開放する。これにより多種多数の関数を同じサーバー上で実行することが可能となるため、要求されるハードウェア資源量を削減することが可能となる。更に、関数サーバー１１２は、登録された関数の実行時間が一定時間（タイムアウト時間）以上となった時に、関数を終了させるタイムアウト機能を持つ。

データベースサーバー１１３は、ＭＦＰ１０１から定期的に送信されるデータ（定期送信データ）を、検索性を高めるためにインデックスを付与した上で保存する。また、後述する有効期限テーブルを保存する目的でも利用される。更に、データベースサーバー１１３は、データベースへの書き込みや削除などの処理が行われるたびに、その処理をイベントとして、関数サーバー１１２に通知を行う。
また、データベースサーバー１１３は、データベースに保存する項目（エンティティ）毎にそのエンティティを自動的に削除するための有効期限（生存期間（Time to Live）と言うこともある）を設定することが可能である。データベースサーバー１１３は、エンティティの有効期限が切れたことを検出すると、そのエンティティをデータベースから削除する。

スケジュールサーバー１１４は、タイマーを備え、指定された時刻になったことを検出すると関数サーバー１１２に対してイベントを通知する。

内部ネットワーク１１５は、アプリケーションシステム１１０内の各サーバーを接続する、いわゆる通信ネットワークである。内部ネットワーク１１５は、インターネットなどのＬＡＮ上に構成されたＶＰＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、または、これらの組み合わせにより実現される。

図２は、本システムにおいて用いられる各サーバーやＭＦＰなどの各機器のハードウェアの構成例を示す図である。
図２Ａは、ＡＰＩサーバー１１１、関数サーバー１１２、データベースサーバー１１３、スケジュールサーバー１１４の各サーバーを構成する情報処理装置内部のハードウェア構成を示す図である。これらは、一般的な情報処理装置（いわゆるＰＣ）のハードウェアで構成することができる。

ＣＰＵ２０１は、ＲＯＭ２０３内に記憶されたプログラムや、外部メモリ２１０からＲＡＭ２０２にロードされたＯＳ（オペレーションシステム）やアプリケーション等のプログラムを実行する。すなわち、ＣＰＵ２０１は、読み取り可能な記憶媒体に格納されたプログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。
ＲＡＭ２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリアなどとして機能する。

入力コントローラ２０４は、キーボード２０８や図示しないポインティングデバイス（例えば、マウス、タッチパッド、タッチパネル、トラックボール）からの操作入力を制御する。
ビデオコントローラ２０５は、ディスプレイ２０９の表示を制御する。
ディスクコントローラ２０６は、各種のデータを記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）などの外部メモリ２１０へのデータアクセスを制御する。
ネットワークＩ／Ｆ２０７は、ネットワーク１０２に接続されて、ネットワーク１０２に接続された他の機器との通信制御処理を実行する。
ＣＰＵ２０１や各コントローラなどは、内部バス２１１によって相互に接続される。

図２Ｂは、ＭＦＰ１０１の内部のハードウェア構成を示す図である。
ＭＦＰ（Multifunction Peripheral：複合機）１０１は、画像形成装置の一例である。
ＣＰＵ２２１は、ＲＯＭ２２３に格納されているプログラム（後述する各処理を実現するプログラムも含む）を備え、内部バス２３１を介して各デバイスを総括的に制御する。また、ＣＰＵ２２１は、ＲＡＭ２２２やＲＯＭ２２３と共にプログラムの実行処理を行うとともに、記憶装置２２４などの記録媒体に画像データを記録する処理を行う。
ＲＡＭ２２２は、ＣＰＵ２２１のメモリやワークエリアとして機能する。

ネットワークＩ／Ｆ２２５は、外部のネットワーク機器と片方向または双方向にデータを送受信する。
近接通信Ｉ／Ｆ２２６は、ＮＦＣやＢｌｕｅＴｏｏｔｈ（登録商標）などの近接通信用のネットワークＩ／Ｆであり、携帯端末などと通信し、データの送受信を行う。
デバイスコントローラ２２７は、印刷部２２８を制御する。
記憶装置２２４は外部記憶装置として機能する。

入出力装置２３０は、ＭＦＰ１０１におけるデータの入出力を担う。入出力装置２３０は、複数の要素を含むものでもよい。具体的には、ユーザーからの入力（ボタン入力など）を受け付ける操作部や、入力に対応する信号を入出力Ｉ／Ｆ２２９を介して前述した各デバイスへ送信する送信部が含まれる。その他、ユーザーに対して必要な情報を提供したり、ユーザー操作を受付けたりするための表示装置（例えば、タッチパネル）も入出力装置２３０に含まれる。さらに、原稿を読み取り、入力として電子データを受付けるためのスキャン装置が入出力装置２３０に含まれてもよい。

タイマー２３２は、所定時間に到達したことを検出して割り込みを発生させ、ＣＰＵ２２１に通知する処理を行う。ＣＰＵ２２１は、プログラムに基づき決定されるスケジュールをタイマー２３２に登録することにより、割り込みを発生させて、定期的な処理を実行することが可能となる。

図３は、本システムにおいて用いられる各機器のソフトウェアモジュールの構成例を示す図である。
本実施例において、各々のソフトウェアモジュール（図３に示された各ブロック）は、各機器のＣＰＵによって実行されるプログラムで実現される処理の主体として例示するものである。また、以下においては、ＭＦＰ１０１から定期的に送信するデータとして、バックアップ処理を行う際のデータを例にして説明を行う。

まず、ＭＦＰ１０１が有するソフトウェアモジュールについて説明する。
定期送信設定部３０１は、ＭＦＰ１０１が定期的に送信する各種のデータを、リクエスト毎にどのようなタイミングでアプリケーションシステム１１０に送信するかという設定を行う。設定した値は、アプリケーションシステム１１０のデータベースサーバー１１３に保存される。
ここで、表１に、定期送信設定部３０１で設定される定期送信データの例を示す。

表１において、「データ種別」は、定期送信データの種別を示す。
「定期送信」は、定期的に送信する処理（定期送信処理）を実施するか否かを示す。
「実行日時」は、各定期送信処理を実行する時刻を示す。例えば、表１の例においては、バックアップ処理は、１週間毎に、毎週火曜日の０時から実行する設定となっている。また、カウンタの定期送信は、１時間毎に、毎時３０分から実行する設定となっている。なお、実行日時は、現在時刻から次の実行時刻が分かるように、前回の実行時刻からＸ時間後といった相対値ではなく、絶対値として設定する。

「実行時間」は、各定期送信処理の実行に要する時間を示す。表１の例においては、バックアップ処理は、バックアップ開始から各種のデータを収集して単一のファイルとしてアーカイブするため、最大３時間を要する。一方、カウンタの送信は、ＲＡＭ２２２上に格納されているカウンタデータを取り出して送信するだけであるため、実行時間は実質的に０である。

「通知先」は、各定期送信処理が失敗した場合に、通知を実行する通知先を示す。通知先としては、ＭＦＰ１０１の管理者のメールアドレスの他に、例えばＳＭＳによるメッセージ通知や各種のメッセージングサービスにメッセージを登録するためのＨＴＴＰエンドポイントであってもよい。更に、それらの複数の組み合わせであってもよい。

タスク実行部３０２は、定期送信設定部３０１が設定した定期送信処理の設定に基づいて、ＭＦＰ１０１のタイマー２３２を設定して、設定された時間に各定期送信処理が実行されるように制御する。
定期送信データ取得部３０３は、定期送信設定部３０１が設定した定期送信処理のデータ種別に応じて、ＭＦＰ１０１の各種のメモリや記憶部からデータを収集して、定期送信データを作成する。例えば、定期送信処理のデータ種別がバックアップデータである場合は、ＭＦＰ１０１のＲＡＭ２２２や記憶装置２２４から必要な情報を収集して、Ｚｉｐ等の圧縮形式でアーカイブする。
定期送信データ送信部３０４は、定期送信データ取得部３０３で取得したデータを、アプリケーションシステム１１０へ送信する。

次に、ＡＰＩサーバー１１１が有するソフトウェアモジュールについて説明する。
リクエスト受信部３１１は、ＭＦＰ１０１からアプリケーションシステム１１０へ送信される各種のリクエストを受け付ける。本実施例においては、ＲＥＳＴ ＡＰＩを利用するＨＴＴＰエンドポイントとして実装する。
更に、リクエスト受信部３１１は、リクエストの内容をＵＲＩから解析し、関数サーバー１１２に存在する関数の中から呼び出すべき関数を決定して、その関数を呼び出す。更に、リクエスト受信部３１１は、実行した関数の戻り値を受け取り、ＭＦＰ１０１に対してリクエストが成功したか失敗したかについての情報、及び、戻り値に関する内容を送信する。

認証部３１２は、リクエスト受信部３１１が受信したデータが、正規のＭＦＰから送信されたものであるか否かを検証する。検証方法としては、ＡＰＩキーによる検証、公開鍵暗号による検証、パスフレーズによる検証などがあるが、本実施例においてはその形態は問わない。

次に、関数サーバー１１２が有するソフトウェアモジュールについて説明する。
関数登録部３２１は、アプリケーションのデプロイ時に関数を登録し、かつ、各イベントが発生した場合に呼び出す関数を登録する。
ここで、表２に、本実施例における具体的な関数の設定を示す。

表２において、「イベント発生元」は、本システムにおいて発生しうるイベントのリストを示す。
「呼び出し関数」は、各イベントが発生した場合に、関数サーバー１１２が実行させるソフトウェアモジュールを示す。
表２に基づいて、関数サーバー１１２は、アプリケーションシステム１１０内で発生するイベントからどの関数を呼び出すかを決定し、イベントをトリガーとして決定した関数を実行する。

定期送信設定受信部３２２は、ＭＦＰ１０１の定期送信設定部３０１が送信した定期送信設定を受信して、その内容をデータベースサーバー１１３へ保存する。更に、定期送信設定受信部３２２は、有効期限更新部３２４を動作させ、有効期限テーブルを更新する。有効期限テーブルの具体的な内容は後述する。
定期送信データ受信部３２３は、ＭＦＰ１０１の定期送信データ送信部３０４が送信した定期送信データを受信して、その内容をデータベースサーバー１１３へ保存する。更に、定期送信データ受信部３２３は、有効期限更新部３２４を動作させ、有効期限テーブルを更新する。

有効期限更新部３２４は、現在時刻と表１に示す定期送信データの実行日時とから、次回の定期送信データを受信する時刻を算出して、有効期限テーブルに書き込む。
ここで、表３に、有効期限テーブルの例を示す。

表３において、「デバイスＩＤ」は、個々のＭＦＰ１０１毎に一意のＩＤを示す。
「データ種別」、「実行日時」、「実行時間」、「通知先」は、それぞれ、表１に示した同名の項目と同一のものであるため、説明を省略する。

「有効期限」は、デバイスから定期送信データを受信する時刻に対応する時間情報であり、各種の定期送信データの送信が完了する予定時刻を示す。具体的には、以下の式から算出される。
有効期限 ＝ 現在時刻以降の最初の実行日時 ＋ 実行時間

この式において、「現在時刻以降の最初の実行日時」とは、次回の定期送信処理を実行する時刻であり、現在時刻と実行日時とに基づいて算出される。
具体例として、表３における、デバイスＩＤがZZZ99999、データ種別がバックアップのエンティティについて説明する。ここで、現在時刻が２０１８／６／１０（日）の１５時であると仮定した場合、実行日時（毎週火曜日０時）の条件を満たす最も近い将来の日時は２０１８／６／１２（火）の０時である。そこで、この日時に更に実行時間の３時間を足し合わせた、２０１８／６／１２（火）の３時が、有効期限として設定される。

有効期限切れデータ処理部３２５は、データベースサーバー１１３からエンティティを削除するイベントによって駆動され、設定された通知先への通知処理を行う。更に、有効期限切れデータ処理部３２５は、有効期限更新部３２４と同様に、有効期限を更新したエンティティを、有効期限テーブルに対して再度書きこむ。この処理については、後述の各フローチャートを用いて詳細に説明する。

次に、スケジュールサーバー１１４が有するソフトウェアモジュールについて説明する。
スケジュール登録部３４１は、アプリケーションシステム１１０の設定値を受け付け、スケジュール起動するタスクを生成する。
スケジュール実行部３４２は、スケジュール登録部３４１が受け付けた設定値に基づいて、関数サーバー１１２に対してイベントを生成する。

最後に、データベースサーバー１１３が有するソフトウェアモジュールについて説明する。
データ保存部３３１は、検索性を高めるために、関数サーバー１１２の各種の関数から保存するように要求されたデータを、インデックスを付与した後に、不揮発性メモリやハードディスクに保存する。
データ取得部３３２は、関数サーバー１１２の各種の関数から要求されたデータを不揮発性メモリやハードディスクから取り出して提供する。

有効期限切れデータ削除部３３３は、有効期限テーブルの「有効期限」に設定された日時を経過したエンティティを削除する。更に、有効期限切れデータ削除部３３３は、有効期限が経過したことをイベントとして関数サーバー１１２に送信する。
ここで、表４に、有効期限が経過し、データを削除する時に発生するイベントの例を示す。

「削除時間」は、有効期限切れデータ削除部３３３が有効期限を経過したエンティティを削除した時の時刻を示す。
「テーブル名」は、有効期限切れデータ削除部３３３がどのテーブルのエンティティを削除したかを示す。
「削除データ」は、実際に削除されたデータを示す。
なお、本システムでは、有効期限切れデータ削除部３３３において実行されるデータの自動削除機能は、アプリケーションの設定に応じて無効化することも可能である。

次に、図４を用いて、有効期限が経過したことによりデータが削除され、通知が実行される際の処理の流れを説明する。図４は、実施例１における有効期限切れデータの処理手順を示すフローチャートである。

データベースサーバー１１３の有効期限切れデータ削除部３３３は、まず、有効期限切れデータの有無を確認する（Ｓ４０１）。なお、有効期限切れデータとは、設定されている有効期限が、現在時刻よりも前の時刻であるエンティティのことである。
有効期限切れデータがある場合（Ｓ４０１：Ｙ）、有効期限切れデータ削除部３３３は、該当するエンティティを削除する（Ｓ４０２）。

そして、有効期限切れデータ削除部３３３は、有効期限切れデータを削除したことを、イベントとして関数サーバー１１２に向けて通知を行う（Ｓ４０３）。
その後、有効期限切れデータ削除部３３３は、Ｓ４０１に戻り、処理を繰り返す。また、Ｓ４０１において有効期限切れデータがなかった場合（Ｓ４０１：Ｎ）も、Ｓ４０１に戻り、処理を繰り返す。

関数サーバー１１２の有効期限切れデータ処理部３２５は、Ｓ４０３においてデータベースサーバー１１３からイベントを受信すると、受信したイベントの有効期限切れデータから、登録されている通知先を取り出して、各種の通知を実行する（Ｓ４０４）。先に説明したように、通知先としては、ＭＦＰ１０１の管理者のメールアドレスの他に、例えばＳＭＳによるメッセージ通知や各種のメッセージングサービスにメッセージを登録するためのＨＴＴＰエンドポイントであってもよい。更に、それら複数の組み合わせであってもよい。
次に、有効期限切れデータ処理部３２５は、有効期限を算出し直し、有効期限を更新する（Ｓ４０５）。そして、有効期限を更新したエンティティを作成して、データベースサーバー１１３の有効期限テーブルを更新する（Ｓ４０６）。
Ｓ４０６の処理が終了すると、関数サーバー１１２は、有効期限切れデータ処理部３２５の処理が終了したと判断し、実行した関数が所有するリソースを削除して、実行した関数を終了する。

以上説明したように、実施例１においては、有効期限が経過したデータの削除をトリガーとして関数を実行することで、単一の関数により単一のＭＦＰに対して逐次、通知を実行する。そのため、アプリケーションシステム１１０に接続されるＭＦＰ１０１の台数が増加したとしても、関数の実行時間がＭＦＰの台数に依存しないため、タイムアウトを発生させることなく、システムを動作させることが可能となる。

また、特許文献１に開示されているような、定期的にすべてのクライアントの状態を確認する手法においては、確認するタイミングにおいて、クライアントの台数に応じてデータベースサーバーへ対して多量の検索処理を実行する必要がある。このため、クライアントの状態を確認するタイミングにおいて、データベースサーバーへのアクセスに偏りを発生させてしまう。

これに対して、本実施例においては、イベント単位で関数を実行することで逐次、通知処理を行うため、ＭＦＰの台数が増加したとしても、通知時間に偏りが存在しない限り、データベースへのアクセスの偏りを発生させることがない。これにより、データベースサーバーへのアクセスが均一になるため、データベースサーバーへのピーク負荷を削減することが可能となる。

実施例１においては、有効期限切れデータをデータベースから自動削除する機能を利用して通知する手法について説明した。これに対して、実施例２では、スケジュールサーバー１１４が備えるタイマー２３２を用いて定期的に有効期限切れデータを検出して通知する手法について説明する。なお、実施例１と同様の処理を実施する箇所に関しては、同じ符号を用い、説明を省略する。

図５は、実施例２における有効期限切れデータの処理手順を示すフローチャートである。なお、実施例２においては、データベースサーバー１１３が有する有効期限切れによる自動削除機能を利用しないため、有効期限切れデータ削除部３３３を事前に無効化しておく。

まず、スケジュールサーバー１１４は、タイマー２３２の機能を用いて、有効期限テーブルにおいて設定されている有効期限になったことを検出して、関数サーバー１１２に対してイベントを通知する（Ｓ５０１）。
ここで、表５に、スケジュールサーバー１１４が生成するイベントの例を示す。

「実行開始時刻」は、タイマーが起動した正確な時刻を示す。
「タイマーＩＤ」は、どのタイマーによるイベントであるかを区別するための一意のＩＤを示す。

イベントの通知を受けると、関数サーバー１１２の有効期限切れデータ処理部３２５は、後のタイムアウト判定のために、実行開始時間として現在の時刻を記録する（Ｓ５０２）。

次に、有効期限切れデータ処理部３２５は、データベースサーバー１１３のデータ取得部３３２に対して、有効期限切れデータ、すなわち、有効期限が現在時刻より前であるエンティティの一覧を要求する（Ｓ５０３）。
データ取得部３３２は、Ｓ５０３において要求を受信すると、自身の持つハードディスク及び不揮発メモリからデータを検索し、検索結果である有効期限切れデータの一覧を、戻り値として有効期限切れデータ処理部３２５へ送信する（Ｓ５０４）。

有効期限切れデータ処理部３２５は、Ｓ５０４においてデータ取得部３３２から受信した戻り値から、未処理の有効期限切れデータがあるか否かを検出する（Ｓ５０５）。
未処理の有効期限切れデータがない場合は、有効期限切れデータ処理部３２５は、すべての有効期限切れデータに対して通知を完了したと判断して、本フローチャートを終了する（Ｓ５０６）。

一方、未処理の有効期限切れデータがある場合（Ｓ５０５：Ｙ）、有効期限切れデータ処理部３２５は、未処理の有効期限切れデータから１つを取り出して、通知処理を行う（Ｓ５０７）。なお、Ｓ５０７における通知処理は、実施例１で説明したＳ４０４における処理と同様である。
そして、有効期限切れデータ処理部３２５は、取り出した未処理の有効期限切れデータについて有効期限を更新して（Ｓ５０８）、更新後のエンティティをデータベースサーバー１１３に書き込む（Ｓ５０９）。
なお、Ｓ５０８及びＳ５０９の処理も、それぞれ、実施例１で説明したＳ４０５及びＳ４０６の処理と同様である。

その後、有効期限切れデータ処理部３２５は、自身のタイムアウトまでの残時間の有無を判定する（Ｓ５１０）。この処理は、Ｓ５０２で取得した実行開始時間と、Ｓ５１０において取得した現在時刻との差を、関数サーバー１１２にあらかじめ記録されたタイムアウト時間と比較することにより算出される。

まだタイムアウトに到達していない場合（Ｓ５１０：Ｎ）、Ｓ５０５に戻り、有効期限切れデータ処理部３２５は、残っている未処理の有効期限切れデータに対しての通知処理を継続する。
タイムアウト時間に到達した場合（Ｓ５１０：Ｙ）、有効期限切れデータ処理部３２５は、自分自身の関数を起動するように再度イベントを発行する（Ｓ５１１）。

最後に、関数サーバー１１２は、有効期限切れデータ処理部３２５の処理が終了すると、実行した関数が所有するリソースを削除する。
ここで、表６に、Ｓ５１１で発行されるイベントのフォーマットの例を示す。

表６において、「実行開始時刻」は、タイマー２３２が起動した正確な時刻を示す。
「イベントＩＤ」は、各種のイベントを区別するための一意のＩＤを示す。
Ｓ５１１においてイベントの発行を完了した後、有効期限切れデータ処理部３２５は、本フローチャートを終了する。

なお、タイムアウトによりすべての有効期限切れデータを処理できなかった場合であっても、Ｓ５１１において発行されたイベントをトリガーとして、有効期限切れデータ処理部３２５が再び動作することにより、本フローチャートは再帰的に実行される。その結果、処理は継続して行われるため、関数サーバー１１２の自動削除機能にかかわらず、すべての有効期限切れデータに対して通知処理を行うことが可能となる。
ここで、表７に、実施例２において関数登録部３２１に登録する関数の一覧を示す。

実施例２においても、実施例１と同じく、ＡＰＩサーバー１１１で発生したイベントは該当するソフトウェアモジュールで処理されるように設定される。なお、ＩＤが「ＴＭ１」のタイマー及びＩＤが「ＥＶ１」のイベントは、共に、有効期限切れデータ処理部３２５で処理されるように設定される。すなわち、複数の異なるイベントから同一の関数が実行される。

以上説明したように、実施例２においては、タイマー機能を用いた定期処理であっても、自分自身を実行するイベントをタイムアウト前に生成して発行することにより、すべてのデバイスに関する通知処理を行うことが可能となる。

実施例３では、実施例１の手法を多段に構築することにより、通知先毎に複数台分のデバイスに関する通知を集約して実行する例について説明する。
実施例１及び実施例２の手法においては、複数のデバイスに関する同じ通知がほぼ同時刻に発生した場合であっても、発生した回数に応じた回数の送信を行う。しかし、デバイス（ＭＦＰ）を多数所有する顧客の場合、デバイス台数分のメールがほぼ同時刻に送信されてしまうと、顧客のネットワーク環境に過大の負荷を与えてしまう可能性がある。そのため、本実施例では、ほぼ同時刻に発生した通知を、デバイス毎ではなく、通知先毎などに集約して送信する。

図６は、実施例３において用いられる各機器のソフトウェアモジュールの構成例を示す図である。なお、図３と同様の動作を行うソフトウェアモジュールについては、同じ符号を用い、説明を省略する。

関数サーバー１１２は、図３で説明したソフトウェアモジュールに加えて、有効期限切れ通知集約データ処理部６２６を備える。有効期限切れ通知集約データ処理部６２６は、後述の通知集約テーブルについて有効期限切れによる自動削除時に実行されるソフトウェアモジュールであり、実際に通知処理を行う関数である。その詳細については後述する。

図７は、実施例３における有効期限切れデータの処理手順を示すフローチャートである。本フローチャートは、前述の有効期限テーブルからエンティティを削除するイベントをトリガーとして起動する。

本フローチャートが起動すると、関数サーバー１１２の有効期限切れデータ処理部３２５は、データベースサーバー１１３の通知集約テーブルから通知集約エンティティを取得する（Ｓ７０１）。なお、「通知集約エンティティ」とは、通知先とデータ種別が共に同一であるエンティティをいう。
ここで、表８に、通知集約テーブルの例を示す。

表８において、「通知先」は、表１における通知先と同様であるため、説明を省略する。
「データ種別」は、定期送信データの種別を示す。
「デバイスＩＤ」は、定期送信データがまだ受信されていないと判別されたデバイスを示す。
「有効期限」は、有効期限切れデータ削除部３３３によりデータが削除される時刻を示す。
表８の例では、以下のとおり、同一の管理者（通知先がa＠b.c）が管理する複数のデバイス（デバイスＩＤがZZZ99999, ZZZ99997）に関して、その通知先に対して同時に通知を行うことになる。

通知集約エンティティが存在しない場合（Ｓ７０２：Ｎ）は、新規にエンティティを作成するために、有効期限を設定する（Ｓ７０３）。有効期限に代入する値は、現在時刻に集約期間に加えた値である。なお、集約期間とは、通知先とデータ種別が共に同一であるエンティティを、集約して送信するために、あらかじめ定められた一定期間である。
通知集約エンティティが存在する場合（Ｓ７０２：Ｙ）は、該当するエンティティのデバイスＩＤのフィールドに、通知対象のデバイスＩＤを追加する（Ｓ７０４）。

その後、有効期限切れデータ処理部３２５は、変更ないし新規作成した通知集約エンティティを保存して、通知集約テーブルを更新する（Ｓ７０５）。
このように、通知集約テーブルを更新することにより、最初に通知対象となるイベントが発生してから集約期間内に発生した同一種類のイベントを、同一の通知先にまとめて通知することが可能となる。

ここで、有効期限テーブルに記載される通知先は、配列として、複数設定することができる。そのため、すべての通知先に対して処理を実行するまで、Ｓ７０１からＳ７０５までの処理を繰り返す（Ｓ７０６）。
すべての通知先に対する処理が完了すると（Ｓ７０６：Ｙ）、有効期限切れデータ処理部３２５は、有効期限を更新する（Ｓ７０７）。
そして、有効期限切れデータ処理部３２５は、更新された有効期限テーブルをデータベースサーバー１１３に送信する（Ｓ７０８）。
Ｓ７０７及びＳ７０８の処理は、それぞれ、実施例１におけるＳ４０５及びＳ４０６の処理と同様である。

最後に、関数サーバー１１２は、有効期限切れデータ処理部３２５の処理が終了すると、実行した関数が所有するリソースを削除する。

図８は、有効期限切れ通知集約データ処理部６２６における動作フローを示すフローチャートである。本フローチャートは、有効期限切れデータ削除部３３３が通知集約テーブルから有効期限切れデータを削除するイベントをトリガーとして起動する。
ここで、表９に、通知集約テーブルから有効期限切れデータを削除する際のイベントの例を示す。

表９における、「削除時間」、「テーブル名」、「削除データ」は、それぞれ、表４のものと同様であるため、説明を省略する。
なお、削除データには、本フローチャートの起動のトリガーとなる、通知集約テーブルから削除されたエンティティが代入される。

有効期限切れ通知集約データ処理部６２６は、削除されたエンティティの削除データに含まれる通知先を抽出して、通知先に通知を実行する（Ｓ８０１）。通知先及び通知方法については、実施例１及び実施例２と同様であるため省略する。但し、複数のデバイスに関する通知を同一の通知先に対して同時刻に行うため、通知方法としては、例えば、次のように、その旨が分かるよう文面が望ましい。

「お客様の管理する以下のデバイスにおいて、バックアップ処理が実行されていません。設定を確認してください。
・ZZZ99999
・ZZZ99997」

なお、実施例３においては、実施例１や実施例２の有効期限切れデータ処理部３２５における処理とは異なり、通知集約テーブルで管理する内容は定期的な処理ではないため、再度エンティティの内容を更新する処理は必要としない。そのため、通知が終わり次第、関数は終了する。
最後に、関数サーバー１１２は、有効期限切れ通知集約データ処理部６２６の処理が終了したと判断すると、実行した関数が所有するリソースを削除する。

以上説明したように、実施例３においては、集約期間内に発生したデータベースの有効期限切れによる削除を集約して通知する。これにより、同一の管理者が管理する複数のデバイスに関する通知をまとめて実行することができる

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上述の実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形が可能であり、それらを本発明の範囲から除外するものではない。すなわち、上述の各実施例及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。

１０１ ＭＦＰ
１１０ アプリケーションシステム
１１１ ＡＰＩサーバー
１１２ 関数サーバー
１１３ データベースサーバー
１１４ スケジュールサーバー

Claims (7)

1. 複数のネットワークデバイスからのデータを受信して、前記受信したデータを管理する管理システムであって、
   データベースに、各ネットワークデバイスについて、前記各ネットワークデバイスからデータを受信する時刻に対応する時間情報を、有効期限として書き込む第１の書き込み手段と、
   前記データベースにおける前記有効期限が過ぎたことに従うイベントに応じて実行される第１の関数に従い、前記有効期限に対応するネットワークデバイスに係る通知を実行する通知手段と、
   前記第１の関数に従い、前記データベースに、前記通知の対象となったネットワークデバイスについての前記有効期限として、該ネットワークデバイスからデータを受信する次回の時刻に対応する時間情報を、書き込む第２の書き込み手段と、を有し、
   前記第１の関数は、前記有効期限の書き込みをした後に終了する
   ことを特徴とする管理システム。
2. 前記複数のネットワークデバイスのうちのいずれかのネットワークデバイスからデータを受信したことに応じて実行される第２の関数に従い、前記データベースにおいて、該ネットワークデバイスについての前記有効期限を、該ネットワークデバイスからデータを受信する次回の時刻に対応する時間情報で更新する更新手段、をさらに有する
   ことを特徴とする請求項１に記載の管理システム。
3. 前記データベースでは、前記有効期限が過ぎたことに応じて、前記有効期限に対応するネットワークデバイスについての該有効期限を含むデータが削除され、当該データの削除に応じて前記イベントが発行される
   ことを特徴とする請求項１に記載の管理システム。
4. 一定の期間内に過ぎた前記有効期限に対応する複数のネットワークデバイスに係る前記通知を集約して実行する
   ことを特徴とする請求項１に記載の管理システム。
5. 前記ネットワークデバイスは画像処理装置である
   ことを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
6. 前記管理システムは、前記ネットワークデバイスからのデータとして、当該ネットワークデバイスのバックアップのためのデータを管理する
   ことを特徴とする請求項１乃至５のいずれか１項に記載の管理システム。
7. 複数のネットワークデバイスからのデータを受信して、前記受信したデータを管理する管理システムにおける管理方法であって、
   データベースに、各ネットワークデバイスについて、前記各ネットワークデバイスからデータを受信する時刻に対応する時間情報を、有効期限として書き込む第１の書き込みステップと、
   前記データベースにおける前記有効期限が過ぎたことに従うイベントに応じて実行される第１の関数に従い、前記有効期限に対応するネットワークデバイスに係る通知を実行する通知ステップと、
   前記第１の関数に従い、前記データベースに、前記通知の対象となったネットワークデバイスについての前記有効期限として、該ネットワークデバイスからデータを受信する次回の時刻に対応する時間情報を、書き込む第２の書き込みステップと、を有し、
   前記第１の関数は、前記有効期限の書き込みをした後に終了する
   ことを特徴とする管理方法。