図面 (/)

この項目の情報は公開日時点(2020年3月26日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

イベント駆動型サーバーレスステムにおいて、クライアントデバイスから定期的に送信されるべき定期送信データが所定期間送信されていないことを検出して、登録された通知先通知するデバイスの管理システムを提供する。

解決手段

有効期限テーブルに書き込むエンティティ毎に通知を実行する時刻を有効期限として設定し、有効期限が経過したことをイベントとして、当該エンティティを削除するとともに、登録先への通知を実行する。

概要

背景

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

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

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

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

概要

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

目的

そこで、バックアップリストアシステムでもサーバーレス技術を用いてサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記複数のネットワークデバイスのうちのいずれかのネットワークデバイスからデータを受信したことに応じて実行される第2の関数に従い、前記データベースにおいて、該ネットワークデバイスについての前記有効期限を、該ネットワークデバイスからデータを受信する次回の時刻に対応する時間情報で更新する更新手段、をさらに有することを特徴とする請求項1に記載の管理システム。

請求項3

前記データベースでは、前記有効期限が過ぎたことに応じて、前記有効期限に対応するネットワークデバイスについての該有効期限を含むデータが削除され、当該データの削除に応じて前記イベントが発行されることを特徴とする請求項1に記載の管理システム。

請求項4

一定の期間内に過ぎた前記有効期限に対応する複数のネットワークデバイスに係る前記通知を集約して実行することを特徴とする請求項1に記載の管理システム。

請求項5

前記ネットワークデバイスは画像処理装置であることを特徴とする請求項1乃至4のいずれか1項に記載の管理システム。

請求項6

前記管理システムは、前記ネットワークデバイスからのデータとして、当該ネットワークデバイスのバックアップのためのデータを管理することを特徴とする請求項1乃至5のいずれか1項に記載の管理システム。

請求項7

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

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

先行技術

0006

特開2008−77324号公報

発明が解決しようとする課題

0007

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

0008

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

課題を解決するための手段

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

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

0012

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

0013

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

0014

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

0015

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

0016

アプリケーションシステム110は、APIサーバー111、関数サーバー112、データベースサーバー113、スケジュールサーバー114の各サーバーからなるサーバー群、及び内部ネットワーク115から構成される。また、アプリケーションシステム110は、例えば、クラウドサービスにより実現されるシステムである、

0017

API(Application Programming Interface)サーバー111は、MFP101からの要求を解析し、要求を実現する関数を関数サーバー112から選択して実行する。一般的には、HTTPに代表されるプロトコルを受信し、URIからアクセスしたいリソースを特定して、そのリソースを操作可能な関数を実行する。
APIサーバーが受信可能なプロトコルは、HTTPに限定されず、例えばWebSocketのような双方向通信可能なプロトコルや、UDPなどの単方向プロトコルを利用した通信であってもよい。本実施例におけるAPIサーバー111は、HTTPプロトコルを利用するサーバーであるものとして、具体的に説明する。

0018

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

0019

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

0020

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

0021

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

0022

図2は、本システムにおいて用いられる各サーバーやMFPなどの各機器のハードウェアの構成例を示す図である。
図2Aは、APIサーバー111、関数サーバー112、データベースサーバー113、スケジュールサーバー114の各サーバーを構成する情報処理装置内部のハードウェア構成を示す図である。これらは、一般的な情報処理装置(いわゆるPC)のハードウェアで構成することができる。

0023

CPU201は、ROM203内に記憶されたプログラムや、外部メモリ210からRAM202にロードされたOS(オペレーションシステム)やアプリケーション等のプログラムを実行する。すなわち、CPU201は、読み取り可能な記憶媒体に格納されたプログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。
RAM202は、CPU201のメインメモリであり、ワークエリアなどとして機能する。

0024

入力コントローラ204は、キーボード208や図示しないポインティングデバイス(例えば、マウスタッチパッドタッチパネルトラックボール)からの操作入力を制御する。
ビデオコントローラ205は、ディスプレイ209の表示を制御する。
ディスクコントローラ206は、各種のデータを記憶するハードディスク(HD)やフレキシブルディスクFD)などの外部メモリ210へのデータアクセスを制御する。
ネットワークI/F207は、ネットワーク102に接続されて、ネットワーク102に接続された他の機器との通信制御処理を実行する。
CPU201や各コントローラなどは、内部バス211によって相互に接続される。

0025

図2Bは、MFP101の内部のハードウェア構成を示す図である。
MFP(Multifunction Peripheral:複合機)101は、画像形成装置の一例である。
CPU221は、ROM223に格納されているプログラム(後述する各処理を実現するプログラムも含む)を備え、内部バス231を介して各デバイスを総括的に制御する。また、CPU221は、RAM222やROM223と共にプログラムの実行処理を行うとともに、記憶装置224などの記録媒体に画像データを記録する処理を行う。
RAM222は、CPU221のメモリやワークエリアとして機能する。

0026

ネットワークI/F225は、外部のネットワーク機器片方向または双方向にデータを送受信する。
近接通信I/F226は、NFCやBlueTooth(登録商標)などの近接通信用のネットワークI/Fであり、携帯端末などと通信し、データの送受信を行う。
デバイスコントローラ227は、印刷部228を制御する。
記憶装置224は外部記憶装置として機能する。

0027

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

0028

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

0029

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

0030

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

0031

0032

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

0033

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

0034

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

0035

タスク実行部302は、定期送信設定部301が設定した定期送信処理の設定に基づいて、MFP101のタイマー232を設定して、設定された時間に各定期送信処理が実行されるように制御する。
定期送信データ取得部303は、定期送信設定部301が設定した定期送信処理のデータ種別に応じて、MFP101の各種のメモリや記憶部からデータを収集して、定期送信データを作成する。例えば、定期送信処理のデータ種別がバックアップデータである場合は、MFP101のRAM222や記憶装置224から必要な情報を収集して、Zip等の圧縮形式でアーカイブする。
定期送信データ送信部304は、定期送信データ取得部303で取得したデータを、アプリケーションシステム110へ送信する。

0036

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

0037

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

0038

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

0039

0040

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

0041

定期送信設定受信部322は、MFP101の定期送信設定部301が送信した定期送信設定を受信して、その内容をデータベースサーバー113へ保存する。更に、定期送信設定受信部322は、有効期限更新部324を動作させ、有効期限テーブルを更新する。有効期限テーブルの具体的な内容は後述する。
定期送信データ受信部323は、MFP101の定期送信データ送信部304が送信した定期送信データを受信して、その内容をデータベースサーバー113へ保存する。更に、定期送信データ受信部323は、有効期限更新部324を動作させ、有効期限テーブルを更新する。

0042

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

0043

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

0052

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

0053

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

0054

データベースサーバー113の有効期限切れデータ削除部333は、まず、有効期限切れデータの有無を確認する(S401)。なお、有効期限切れデータとは、設定されている有効期限が、現在時刻よりも前の時刻であるエンティティのことである。
有効期限切れデータがある場合(S401:Y)、有効期限切れデータ削除部333は、該当するエンティティを削除する(S402)。

0055

そして、有効期限切れデータ削除部333は、有効期限切れデータを削除したことを、イベントとして関数サーバー112に向けて通知を行う(S403)。
その後、有効期限切れデータ削除部333は、S401に戻り、処理を繰り返す。また、S401において有効期限切れデータがなかった場合(S401:N)も、S401に戻り、処理を繰り返す。

0056

関数サーバー112の有効期限切れデータ処理部325は、S403においてデータベースサーバー113からイベントを受信すると、受信したイベントの有効期限切れデータから、登録されている通知先を取り出して、各種の通知を実行する(S404)。先に説明したように、通知先としては、MFP101の管理者のメールアドレスの他に、例えばSMSによるメッセージ通知や各種のメッセージングサービスにメッセージを登録するためのHTTPエンドポイントであってもよい。更に、それら複数の組み合わせであってもよい。
次に、有効期限切れデータ処理部325は、有効期限を算出し直し、有効期限を更新する(S405)。そして、有効期限を更新したエンティティを作成して、データベースサーバー113の有効期限テーブルを更新する(S406)。
S406の処理が終了すると、関数サーバー112は、有効期限切れデータ処理部325の処理が終了したと判断し、実行した関数が所有するリソースを削除して、実行した関数を終了する。

0057

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

0058

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

0059

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

0060

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

0061

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

0062

まず、スケジュールサーバー114は、タイマー232の機能を用いて、有効期限テーブルにおいて設定されている有効期限になったことを検出して、関数サーバー112に対してイベントを通知する(S501)。
ここで、表5に、スケジュールサーバー114が生成するイベントの例を示す。

0063

0064

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

0065

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

0066

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

0067

有効期限切れデータ処理部325は、S504においてデータ取得部332から受信した戻り値から、未処理の有効期限切れデータがあるか否かを検出する(S505)。
未処理の有効期限切れデータがない場合は、有効期限切れデータ処理部325は、すべての有効期限切れデータに対して通知を完了したと判断して、本フローチャートを終了する(S506)。

0068

一方、未処理の有効期限切れデータがある場合(S505:Y)、有効期限切れデータ処理部325は、未処理の有効期限切れデータから1つを取り出して、通知処理を行う(S507)。なお、S507における通知処理は、実施例1で説明したS404における処理と同様である。
そして、有効期限切れデータ処理部325は、取り出した未処理の有効期限切れデータについて有効期限を更新して(S508)、更新後のエンティティをデータベースサーバー113に書き込む(S509)。
なお、S508及びS509の処理も、それぞれ、実施例1で説明したS405及びS406の処理と同様である。

0069

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

0070

まだタイムアウトに到達していない場合(S510:N)、S505に戻り、有効期限切れデータ処理部325は、残っている未処理の有効期限切れデータに対しての通知処理を継続する。
タイムアウト時間に到達した場合(S510:Y)、有効期限切れデータ処理部325は、自分自身の関数を起動するように再度イベントを発行する(S511)。

0071

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

0072

0073

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

0074

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

0075

0076

実施例2においても、実施例1と同じく、APIサーバー111で発生したイベントは該当するソフトウェアモジュールで処理されるように設定される。なお、IDが「TM1」のタイマー及びIDが「EV1」のイベントは、共に、有効期限切れデータ処理部325で処理されるように設定される。すなわち、複数の異なるイベントから同一の関数が実行される。

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

0084

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

0085

通知集約エンティティが存在しない場合(S702:N)は、新規にエンティティを作成するために、有効期限を設定する(S703)。有効期限に代入する値は、現在時刻に集約期間に加えた値である。なお、集約期間とは、通知先とデータ種別が共に同一であるエンティティを、集約して送信するために、あらかじめ定められた一定期間である。
通知集約エンティティが存在する場合(S702:Y)は、該当するエンティティのデバイスIDのフィールドに、通知対象のデバイスIDを追加する(S704)。

0086

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

0087

ここで、有効期限テーブルに記載される通知先は、配列として、複数設定することができる。そのため、すべての通知先に対して処理を実行するまで、S701からS705までの処理を繰り返す(S706)。
すべての通知先に対する処理が完了すると(S706:Y)、有効期限切れデータ処理部325は、有効期限を更新する(S707)。
そして、有効期限切れデータ処理部325は、更新された有効期限テーブルをデータベースサーバー113に送信する(S708)。
S707及びS708の処理は、それぞれ、実施例1におけるS405及びS406の処理と同様である。

0088

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

0089

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

0090

0091

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

0092

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

0093

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

0094

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

0095

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

実施例

0096

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

0097

101MFP
110アプリケーションシステム
111APIサーバー
112関数サーバー
113データベースサーバー
114 スケジュールサーバー

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士ゼロックス株式会社の「 データ管理システム」が 公開されました。( 2020/09/24)

    【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管... 詳細

  • シチズン時計株式会社の「 プリンタ」が 公開されました。( 2020/09/24)

    【課題】 ファンで発生した風を無駄なくサーマルヘッドの狙いの位置に当てることができるプリンタを提供する。【解決手段】 ケース2の縦壁に配置されるファン41と、ケース2の開口部2aを開閉するカバー(... 詳細

  • 株式会社ウフルの「 デバイス管理システム、デバイス管理方法、情報処理装置、及びプログラム」が 公開されました。( 2020/09/24)

    【課題】デバイスの信頼性を向上可能なデバイス管理システム、デバイス管理方法、情報処理装置、デバイス及びプログラムを提供する。【解決手段】デバイス管理システム1は、複数の情報処理装置2をネットワーク3で... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ