JP2022164222A - ネットワークデバイス、ネットワークデバイスの制御方法およびプログラム - Google Patents

Abstract

【課題】ネットワークデバイスからのデータの送信によるネットワーク負荷の増大を抑制する。【解決手段】ネットワークデバイス１２０内で収集したデータをネットワーク１００を介してシステム１１１に送信するネットワークデバイス１２０は、ネットワークデバイス１２０の起動時にリカバリ送信が行われる対象のデータについては、ネットワークデバイス１２０の起動時に送信するイベントの送信の設定においてオフセット時間が設定されている場合、該オフセット時間に従うイベントの送信よりもさらに遅延させて、リカバリ送信の対象のデータの送信を行う制御手段５１１を有する。【選択図】図９

Description

本発明は、ネットワークデバイス、ネットワークデバイスの制御方法およびプログラムに関する。

迅速な保守やデバイス内で発生するの事象の予兆予測、デバイス搭載機能の改善等を行うために、デバイスの状態の監視が行われている。デバイスの状態の監視のために、稼働しているデバイスからネットワークを通じてイベントログ管理サーバに大量の各種イベントログを送信しサーバに保存するシステムが知られている。クラウドのサーバでは、蓄積されたイベントログとサーバ上のアプリケーションを利用し、デバイスの各種状態変化を分析したり、発生した事象に応じて迅速に消耗品の交換やメンテナンス作業の手配の通知をしたりなどの対応を行う必要がある。そのため、デバイス上で起きた事象をサーバ側のアプリケーションが取り扱いやすい形のイベントログの形にして送付する必要がある。

ネットワーク回線への負荷が致命的な環境では、負荷を分散させるために、イベントログの定期送信時刻をずらし、稼働時間外に送信するような対応が行われる。しかし指定した時間帯に起動していない場合には収集することができなくなるため、そのときはデバイスが起動した後に当該イベントログの送信をおこなうことが必要である。一方で、デバイスの設定によってはデバイスが起動した時に情報を収集して起動時にイベントログを送信することも行われる。このようにデバイスが起動した際にイベントログの送信が行われる可能性が高く、複数のデバイスの同時起動での一斉送信を防ぐために、ランダムなオフセット時間を設定して送信が行われる。特許文献１は、デバイス管理装置がスリープ状態のため指定した時刻にデータが送信できなかったとき、スリープから復帰後にランダムなオフセット時間を設定して当該データをサーバに送信するデバイス監視システムを開示している。

特開２０１７－６２５４７号公報

しかしながら、特許文献１の方法では、指定時刻にデータ送信できなかった場合、スリープから復帰後にランダムなオフセット時間を設定したリカバリ送信と、ランダムなオフセットを設定した起動時データ送信との送信タイミングが重複する可能性がある。データの送信タイミングが重複してしまうと、ネットワーク負荷が増大する可能性がある。

本発明は、ネットワークデバイスからのデータの送信によるネットワーク負荷の増大を抑制することを目的とする。

上記課題を解決するために、本発明のネットワークデバイスは、ネットワークデバイス内で収集したデータをネットワークを介してシステムに送信するネットワークデバイスであって、前記ネットワークデバイスの起動時にリカバリ送信が行われる対象のデータについては、前記ネットワークデバイスの起動時に送信するイベントの送信の設定においてオフセット時間が設定されている場合、該オフセット時間に従う前記イベントの送信よりもさらに遅延させて、前記リカバリ送信の対象のデータの送信を行う制御手段を有する。

本発明によれば、ネットワークデバイスからのデータの送信によるネットワーク負荷の増大を抑制することができる。

システム全体の構成を示す図である。 管理サーバの構成を示す図である。 クライアント機の構成を示す図である。 クライアント機の情報処理コントローラユニットの構成を示す図である。 クライアント機のソフトウェア構成を示す図である。 イベントの発行・送付処理を示すフローチャートである。 イベントの通知設定を取得・更新する処理を示すフローチャートである。 第１実施形態におけるコレクションファイルの一例を示す図である。 第１実施形態におけるイベントの送付処理を示すフローチャートである。 第１実施形態におけるイベントの送付処理を示すフローチャートである。 第２実施形態におけるコレクションファイルの一例を示す図である。 第２実施形態におけるイベントの送付処理を示すフローチャートである。 第２実施形態におけるイベントの送付処理を示すフローチャートである。 第３実施形態におけるイベントの送付処理を示すフローチャートである。 第３実施形態におけるイベントの送付処理を示すフローチャートである。

（第１実施形態）
図１は、本発明におけるネットワークを介して接続されるネットワークデバイスからネットワークデバイス内のデータを収集するシステム全体の構成を示す図である。ネットワーク１００には、複数の管理サーバ１１０およびネットワークデバイス（以下、デバイスと記す）１２０（デバイス１２０ａおよびデバイス１２０ｂ）が接続されている。管理サーバ１１０は、デバイス１２０からデバイス内で収集されるデータを取得し、取得したデータを利用するシステム１１１に属している。

デバイス１２０は、ネットワーク１００に接続され通信が可能なネットワークデバイスであり、例えばＰＣ、タブレット、複合機、カメラなどの情報処理装置である。本実施形態では、デバイス１２０としてコピーやＦＡＸ等の複数種類の機能を実現する複合機を例に説明する。また、本実施形態のデバイス１２０は、デバイス内で収集したデータを、ネットワーク１００を介して管理サーバ１１０に対して送信する機能を有している。デバイス１２０は、デバイス内での事象やデバイス内のデータをイベントの形式で管理サーバ１１０に対して送信する。管理サーバ１１０に対して送信するイベントには、例えば、機能の実行をした履歴、省電力状態への遷移や復帰等のデバイスの稼働状況、デバイスで利用される消耗品のカウンタ情報、エラー発生など異常状態への遷移・復帰などの履歴などがある。

管理サーバ１１０は、ネットワーク１００を介してデバイス１２０などネットワーク上のデバイスからイベントを収集する情報処理装置である。収集したイベントは、管理サーバ１１０内のストレージに保存される。そして、ストレージに蓄積されたイベントの情報は、デバイスの稼働状況の分析、分析結果に応じたサービスの提供などに利用される。なお、管理サーバ１１０はサーバ装置の他、サーバ装置を含むデータセンターにより提供されたリソースを利用した仮想マシン（クラウドサービス）により実現されてもよい。

図２は、管理サーバ１１０の構成を示す図である。管理サーバ１１０は、コントローラユニット２００、操作部２１０、表示部２２０を備える。コントローラユニット２００は、ＣＰＵ２１０、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、操作部Ｉ／Ｆ２０５、表示部Ｉ／Ｆ２０６、通信Ｉ／Ｆ２０７を備える。コントローラユニット２００内の各要素はシステムバス２０８を介して接続され、互いにデータのやり取りを行う。

ＣＰＵ２０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）は、管理サーバ１１０全体を制御する。ＣＰＵ２０１は、ＲＯＭ２０２に格納されているブートプログラムによりＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を起動する。また、ＣＰＵ２０１は、このＯＳ上で、ＨＤＤ２０４に格納されているアプリケーションプログラムを実行し、これによって各種処理を実行する。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２は、不揮発性の記憶領域であって、管理サーバ１１０の基本制御プログラム、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、アプリケーション等の各種データを記憶する。基本制御プログラムにはブートプログラムが含まれる。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０２は、揮発性の記憶領域であって、ＣＰＵ２０１が各種処理を行う際の一時記憶領域、ワークエリアとして使用される。ＣＰＵ２０１はＲＡＭ２０３に、ＲＯＭ２０２及びＨＤＤ２０４に格納された各種制御プログラムを展開する。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４は、不揮発性の大容量記憶部である。ＨＤＤ２０４には、アプリケーションプログラム、設定値、ネットワーク１００上のデバイスから収集したイベント等のデータなどが格納される。なお、本実施形態では記憶部の一例としてＨＤＤ２０４を説明したが、これに限られるものではなく、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）でもよいし、メモリカードといった外部メディアを装填してデータの読出／書込が可能な装置であってもよい。

操作部２１０は、例えば、ポインティングデバイス（例えば、マウス、タッチパネルなど）、操作ボタン、キーボード等であり、ユーザによる操作、入力、指示を受け付ける。操作部Ｉ／Ｆ２０５は、操作部２１０とのインタフェースであり、操作部２１０によってユーザにより入力された情報をＣＰＵ２０１に送出する。表示部２２０は、例えば、液晶ディスプレイやタッチパネルなどであり、画像や各種データを表示する。表示部Ｉ／Ｆ２０６は、表示部２２０に表示すべきデータを表示部２２０に対して出力する。操作部２１０および表示部２２０は、タッチパネル等として一体的に構成されていてもよい。

通信Ｉ／Ｆ２０７は、ネットワーク１００に接続され、ネットワーク１００を介してネットワーク１００上の各デバイスとの間で情報の入出力を行う。なお、図２を用いて説明した管理サーバ１１０の構成は管理サーバ１１０が一般的なコンピュータなどの情報処理装置で実現された場合の一例であり、これに限られるものではない。例えば、管理サーバ１１０は操作部２１０や表示部２２０、これらに対応するインタフェースを含まなくてもよい。

図３は、デバイス１２０（デバイス１２０ａ，デバイス１２０ｂ）の構成の概要を説明する図である。デバイス１２０は、情報処理コントローラユニット３０１、プリンタコントローラユニット３０２、スキャナコントローラユニット３０３、プリンタ３０４、スキャナ３０５、操作部３０６を含む複合機である。情報処理コントローラユニット３０１は、デバイス１２０の動作に係る情報処理制御を統括するコントローラである。情報処理コントローラユニット３０１の詳細な説明は、図４を用いて後述する。

情報処理コントローラユニット３０１には、操作部３０６、プリンタコントローラユニット３０２およびスキャナコントローラユニット３０３が接続される。操作部３０６は、表示装置および入力装置を備えており、ユーザに対して各種情報を表示し、また、ユーザによる操作、入力、指示を受け付ける。表示装置は、例えば液晶ディスプレイやタッチパネルである。入力装置は、例えば、ポインティングデバイス（例えば、タッチパッド、タッチパネルなど）、操作ボタン、キーボード等である。本実施形態では、デバイス１２０が操作部３０６としてタッチパネルを備えている場合を例に説明する。タッチパネルにおける入力座標と表示座標を対応付けることで、あたかもユーザがタッチパネルに表示された画面を直接的に操作可能であるかのようなＧＵＩを構成することができる。

プリンタ３０４は、外部から受信した印刷データに応じた画像を形成して用紙に出力したり、スキャナ３０５にセットされた原稿画像を光学的に読み取り用紙に出力したりする画像出力デバイスである。プリンタコントローラユニット３０２は、プリンタ３０４を制御する。スキャナ３０５は、原稿を光学的に読み取り、スキャンに基づく電子ファイル（スキャンデータ）を生成する画像入力デバイスである。スキャナコントローラユニット３０３は、スキャナ３０５を制御する。

図４は、デバイス１２０の情報処理コントローラユニット３０１の構成を示す図である。情報処理コントローラユニット３０１は、ＣＰＵ４０１、ＲＯＭ４０２、ＲＡＭ４０３、ＨＤＤ４０４、通信Ｉ／Ｆ４０５、操作部Ｉ／Ｆ４０６、画像処理部４０７、デバイスコントローラＩ／Ｆ４０８、電源管理部４０９を有する。情報処理コントローラユニット３０１内の各要素はシステムバス４１０を介して接続され、互いにデータのやり取りを行う。

ＣＰＵ４０１は、デバイス１２０全体を制御する。ＣＰＵ４０１は、ＲＯＭ４０２に格納されているブートプログラムによりＯＳを起動し、ＯＳ上でＨＤＤ４０４に格納されているアプリケーションプログラムを実行することにより、後述する各種処理を実行する。ＲＯＭ４０２は、不揮発性の記憶領域であって、デバイス１２０の基本制御プログラム、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、アプリケーション等の各種データを記憶する。基本制御プログラムにはブートプログラムが含まれる。ＲＡＭ４０２は、揮発性の記憶領域であって、ＣＰＵ４０１が各種処理を行う際の一時記憶領域、ワークエリアとして使用される。また、ＲＡＭ４０３は、画像データを一時記憶するための画像メモリ領域を提供する。ＣＰＵ４０１はＲＡＭ４０３に、ＲＯＭ４０２及びＨＤＤ４０４に格納された各種制御プログラムを展開する。すなわち、ＣＰＵ２０１が、読み取り可能な記憶媒体に格納されたプログラムを実行することにより、後述する処理を実行する各処理部として機能する。

ＨＤＤ４０４は、不揮発性の大容量記憶部である。ＨＤＤ２０４には、アプリケーションプログラムや画像データ、各種設定値や履歴、次回の管理サーバ１１０へのデータの送信予定時刻などが格納される。なお、本実施形態では記憶部の一例としてＨＤＤ４０４を説明したが、これに限られるものではなく、ＳＳＤでもよいし、メモリカードといった外部メディアを装填してデータの読出／書込が可能な装置であってもよい。

通信Ｉ／Ｆ４０５はネットワーク１００に接続され、ネットワーク１００を介してネットワーク１００上の各装置、例えば管理サーバ１１０との間で情報の入出力を行う。操作部Ｉ／Ｆ４０６は、操作部３０６とのインタフェースである。操作部Ｉ／Ｆ４０６は、操作部３０６によってユーザにより入力された情報をＣＰＵ４０１に送出し、また、操作部３０６に表示すべきデータを操作部３０６に対して出力する。

画像処理部４０７は、プリンタ３０４へ出力する画像やスキャナ３０５で取得した画像に対して各種画像処理を行う。各種画像処理の例としては、画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理が挙げられる。デバイスコントローラＩ／Ｆ４０８は、プリンタコントローラユニット３０２およびスキャナコントローラユニット３０３と接続し、プリンタコントローラユニット３０２およびスキャナコントローラユニット３０３とＣＰＵ４０１とのデータの入出力を制御する。また、デバイスコントローラＩ／Ｆ４０８は、画像データの同期系／非同期系の変換を行う。電源管理部４０９は、デバイス１２０の電源制御を行う。具体例には、電源管理部４０９は、オンオフの制御の他、通常通電状態以外の省電力状態への移行や、通常状態への復帰などを制御する。

図５は、デバイス１２０のソフトウェア構成を示す図である。ＣＰＵ２０１が、ＲＯＭ４０２及びＨＤＤ４０４に格納されたプログラムをＲＡＭ４０３に展開して実行することにより、各処理部として機能する。デバイス１２０では、ネットワークやメモリストレージを利用した一般的な情報処理装置の機能を実現するソフトウェアの他、スキャンやプリントなど複合機の機能を実現するソフトウェアが動作する。

デバイス１２０は、ユーザインターフェース５０１、機能アプリケーション５０２、ジョブ制御部５０３、電源制御部５０４、エラー制御部５０５、履歴・設定保持部５０６、カウンタ管理部５０７、構成情報管理部５０８、デバイスログ管理部５０９を有する。さらに、デバイス１２０は、タイマー通知部５４０、イベント回収部５１０、メッセージバッファ５２０、イベント送付部５３０、ネットワーク通信部５３１、通知設定取得部５３２、通知設定保持部５２１を有する。なお、イベント送付部５３０、ネットワーク通信部５３１および通知設定取得部５３２は、デバイス１２０の稼働情報等を収集するシステムに対してデータを送信するアプリケーションが有する機能として実現されてもよい。

ユーザインターフェース５０１は、操作部３０６に対してユーザが操作する画面を表示したり、操作部３０６を介したユーザの操作をソフトウェアに伝えたりする。機能アプリケーション５０２は、複合機のアプリケーション機能を動作させる。複合機のアプリケーション機能は、コピー、プリント、メール送信など複数あり、機能アプリケーション５０２はアプリケーション機能ごとに設けられる。すなわち、デバイス１２０は複数の機能アプリケーション５０２を有する。機能アプリケーション５０２は、操作部３０６を経由したユーザの指示や通信Ｉ／Ｆ４０５経由のデータ受信などをトリガにして、複合機のアプリケーション機能を動作させる。

ジョブ制御部５０３は、機能アプリケーション５０２からの指示を受けてプリンタコントローラユニット３０２やスキャナコントローラユニット３０３を制御してプリントやスキャンを実行する。電源制御部５０４は、デバイス１２０内のソフトウェアの状態と連動して電源管理部４０９を制御する。具体例には、電源制御部５０４は、ソフトウェアの状態に応じて通常通電状態と省電力状態の遷移を制御する。

エラー制御部５０５は、ジョブ制御部５０３、プリンタコントローラユニット３０２、スキャナコントローラユニット３０３などデバイス１２０内で発生した異常状態を検知する。また、エラー制御部５０５は検知した異常状態に応じて、システム全体の停止や縮退動作などを指示して、デバイス１２０の稼働状況を制御する。履歴・設定保持部５０６は、デバイス１２０内における不揮発情報を管理する。具体例には、履歴・設定保持部５０６は、複合機やジョブの制御に必要な設定を保持したり、ユーザの操作履歴やジョブ実行結果およびエラーの発生などをサマライズして保存したりする。また、履歴・設定保持部５０６は、システムの不具合発生時に解析デバッグ用途で残すログ情報も保持する。履歴・設定保持部５０６が管理する不揮発データの実体は、ＨＤＤ４０４に保持される。

カウンタ管理部５０７は、機器内で発生したスキャンやプリントの枚数などのカウントや、消耗部品ごとの消耗度を測るカウント、またカウント結果から算出される部品の寿命情報などを管理する。カウンタ管理部５０７が管理するカウントや寿命情報などの不揮発データの実体は、ＨＤＤ４０４に保持される。構成情報管理部５０８は、デバイス１２０を構成するハード・ソフトの構成を管理する。デバイス１２０を構成するハード・ソフトとして、例えば、給紙カセット、排紙トレイ、フィニッシャ等の外付けのアクセサリ、ファームウェアのバージョン、インストールされているアプリケーションの一覧などが構成情報管理部５０８により管理される。デバイスログ管理部５０９は、プリンタコントローラユニット３０２やスキャナコントローラユニット３０３などデバイス１２０内の稼働状況を詳細に記録し、デバイスログとして保存する。

制御部５１１は、イベント回収部５１０、イベント送付部５３０、タイマー通知部５４０を制御することにより、デバイス１２０内のデータを収集してイベントの形式に正規化し、管理サーバ１１０に送信する一連の処理を制御する。データ（イベント）の管理サーバ１１０への送信のタイミングも、制御部５１１により制御される。後述するイベント回収部５１０、イベント送付部５３０、タイマー通知部５４０が実行する各処理は制御部５１１により制御される。

イベント回収部５１０は、制御部５１１の指示に応じて、管理サーバ１１０に送信するためのデバイス１２０の稼働状況などのデータを収集し、イベントの形式で保存する。イベント回収部５１０は、まず、デバイス１２０内の事象を監視し、指定された条件に従い対象のデータを収集する。そして、イベント回収部５１０は、収集したデバイス１２０内のデータを管理サーバ１１０に送付するためイベントの形で正規化してメッセージバッファ５２０に保存する。

ここで、イベント回収部５１０によるデバイス１２０内のデータの収集について説明する。イベント回収部５１０は、後述する通知設定保持部５２１に保存されたイベントの通知設定に従ってデバイス１２０内でデータを収集する。例えば、イベント回収部５１０は、自発的にイベントを発行するモジュール（例えば、ユーザインターフェース５０１～履歴・設定保持部５０６）で発生した状態遷移を監視し、リアルタイムで状態遷移のデータを収集する。また、イベント回収部５１０は、デバイス１２０の稼働状況を定期的に収集するために、タイマー通知部５４０に対して指定時間経過後のタイマーの発火もしくは指定時刻でのタイマーの発火を要求する。タイマー通知部５４０から通知を受けたイベント回収部５１０は、タイマーの発火をトリガにして定期的に収集するデータを回収する。ここで、定期的に収集するデータとはデバイス１２０から管理サーバ１１０に定期送信するデータであり、カウンタ管理部５０７が管理するカウンタや構成情報管理部５０８が管理する構成情報などである。タイマー通知部５４０は、イベント回収部５１０の指示に応じてタイマーを設定し、設定された時刻の経過をイベント回収部５１０に通知する。

次に、イベント回収部５１０によるイベントの保存について説明する。イベント回収部５１０は、収集したデバイス１２０内のデータをイベントの形式に正規化し、正規化したイベントをメッセージバッファ５２０に保存する。正規化は、収集したデータを管理サーバ１１０に送信する形式にするために、例えばＪＳＯＮなどの汎用のフォーマットを使って行われる。イベントには、イベント名称、発生時刻、情報処理装置のシリアル番号などの基本情報に加えてイベントの種別によって、追加でさまざまな情報が付与される。付与情報は、イベント回収部５１０がデバイス１２０内の各モジュールの状態や不揮発領域に保持される内容などから収集する。イベントの形式に正規化されたデータは、メッセージバッファ５２０に保存される。

メッセージバッファ５２０は、イベント回収部５１０により正規化されたイベントを保持する。メッセージバッファ５２０は、不揮発性のＨＤＤ４０４上にある。イベント送付部５３０は、制御部５１１の指示に応じて、デバイス１２０内から収集されてメッセージバッファ５２０に保存されたイベントを取得し、管理サーバ１１０に送信する。具体例には、イベント送付部５３０は、メッセージバッファ５２０への書き込みを検知するなどしてイベントが発行されたことを把握する。イベントの発行を検知したイベント送付部５３０は、メッセージバッファ５２０からイベントを取得し、ネットワーク通信部５３１を介して管理サーバ１１０にイベントを送付する。ネットワーク通信部５３１は、通信Ｉ／Ｆ４０５を利用し、ネットワーク１００を介して管理サーバ１１０と通信する。

通知設定取得部５３２は、ネットワーク通信部５３１を介して、管理サーバ１１０からイベントの通知設定を受信する。そして、通知設定取得部５３２は、ネットワーク通信部５３１を介して管理サーバ１１０から取得したイベントの通知設定を通知設定保持部５２１に保存する。ここで、イベントの通知設定とは、管理サーバ１１０の管理対象であるデバイス内のデータの内、どのデータをどのタイミングでイベントとして管理サーバ１１０に送付するかの定義情報を示した内容である。イベントの通知設定は、コレクションファイルとして取得される。コレクションファイルの詳細な説明は、図８を用いて後述する。イベントの通知設定の取得、管理についての詳細な説明は、図７および図８を用いて後述する。

通知設定保持部５２１は、イベントの通知設定を保持する。すなわち、通知設定保持部５２１には、イベントの通知設定として、デバイス１２０内から収集されるべきデータの種類と収集される条件が記録される。通知設定保持部５２１は、不揮発性のＨＤＤ４０４上にあり、イベントの通知設定はファイルの形式で保存される。イベント回収部５１０は、通知設定保持部５２１に保存されたイベントの通知設定に従って、通知すべきと指示されたイベントを収集しメッセージバッファ５２０に保存する。そのため、デバイス１２０から管理サーバ１１０に契約の対象となっているデータのみを送付することができる。

次に、イベントの通知設定の詳細について説明する。表１は、イベントの通知設定とイベントの関係を示す表である。

「Ｅｖｅｎｔ」の列に記載がある名称が、デバイス１２０内で発生した状態遷移に対して名称を付けて正規化した単位（以下、イベントと記載する）である。つまりこのイベントが、イベント回収部５１０がデバイス内から収集してメッセージバッファ５２０に対して保存する単位であり、管理サーバ１１０に送られる単位である。例えばＪｏｂＳｔａｒｔｅｄは、コピーやプリントなどのジョブが実行開始したことを意味するイベントである。ＥｒｒｏｒＯｃｃｕｒｒｅｄは、デバイス内で何らかの異常状態が発生したことを意味するイベントである。「説明」の列は、各イベントの内容である。

「Ｃｏｌｌｅｃｔｉｏｎ」の列に記載がある名称は、複数のイベントを動作の意味のまとまりでグルーピングした単位である（以下、コレクションと記載する）。本実施形態では、コレクションの単位で管理サーバ１１０への送信の有効化の設定がなされる。そのため、通知設定保持部５２１が保持するイベントの通知設定では、デバイス１２０内で収集されるべきデータの種類がコレクションの単位で設定される。例えばイベントの通知設定でＡｌａｒｍのコレクションが指定されると、ＥｒｒｏｒＯｃｃｕｒｒｅｄおよびＡｌａｒｍＯｃｃｕｒｒｅｄのイベントが管理サーバ１１０に送付されることになる。すなわち、Ａｌａｒｍのコレクションが指定されると、ＥｒｒｏｒＯｃｃｕｒｒｅｄおよびＡｌａｒｍＯｃｃｕｒｒｅｄのイベントがイベント回収部５１０の収集対象となる。

「定期送信」の列は、イベントが定期的に送付されるスナップショットのイベントであるか否かをコレクション単位で定義している。すなわち、定期送信の欄に〇が付いているイベントは、起動やタイマー等で定期的に送付されるスナップショットのイベントである。定期送信を有効化する場合は、通知設定保持部５２１においてコレクションの指定に加えて送信間隔と送信開始時刻の設定を行い、イベントの通知設定の一部として保存する。

「起動時」の列は、イベントが起動時に送信されるイベントであるか否かをコレクション単位で定義している。すなわち、起動時の欄に〇が付いているイベントは、起動時に送信されるイベントである。「発生時」の列は、イベントが対応する事象が発生したときに即時送信されるイベントであるか否かをコレクション単位で定義している。すなわち、発生時の欄に○がついているイベントは、対応する事象が発生したときに即時送信されるイベントである。

例えば、Ｂａｓｉｃのコレクションが指定されると、機種名や設置場所、ファームバージョン等基本情報を属性に持つＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄイベントが、起動時および指定された送信間隔で定期的に管理サーバ１１０に送信される。同様に、Ｃｏｕｎｔｅｒのコレクションが指定されると、ＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄが、指定された送信開始時刻と送信間隔で管理サーバ１１０に定期送信される。なお、ＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄは課金用のカウンタ情報の一覧、ＰａｒｔｓＣｏｕｎｔｅｒＳｎａｐｓｈｏｔｔｅｄは部品の摩耗度のカウンタ情報の一覧を示す情報である。また、ＤｅｖｉｃｅＬｏｇのコレクションが指定されると、ＤｅｉｃｅＬｏｇＤａｔａが、指定された送信開始時刻と送信間隔で管理サーバ１１０に定期送信される。なお、ＤｅｉｃｅＬｏｇＤａｔａはデバイスの稼働状況ログである。

図６は、イベントの発行・送付処理を示すフローチャートである。自発的にイベントを発行するモジュールで発生した状態遷移を監視してリアルタイムで状態遷移のデータを収集し、即時にイベントとして管理サーバ１１０へ送信するまでの流れを示してる。図６に示される各処理は、ＣＰＵ４０１が、読み取り可能な記憶媒体（ＲＯＭ４０２またはＨＤＤ４０４）に格納されたプログラムをＲＡＭ４０３に展開して実行することにより実現される。

図６では、具体例として、デバイス１２０内でエラーが発生した場合について説明する。エラーの発生を受けて制御部５１１の指示により、イベント回収部５１０がエラーに関連するデータを収集し、イベントを発行してメッセージバッファ５２０に保存し、イベント送付部５３０が管理サーバへ送付するまでの流れを示してる。図６（Ａ）は、エラー発生イベントを収集して保存・送信する処理を示すフローチャートである。

ステップＳ６０１において、イベント回収部５１０は、デバイス１２０内のエラーの発生を検知する。具体例には、デバイス１２０内でエラーが発生するとまずエラー制御部５０５がエラーを検知する。エラーを検知したエラー制御部５０５は、イベント回収部５１０にエラーの発生を通知する。イベント回収部５１０はエラー制御部５０５からの通知を受けて、デバイス１２０内のエラーの発生を検知する。

ステップＳ６０２において、イベント回収部５１０は、ステップＳ６０１で検知したエラーの発生というイベント（以下、エラーイベントと記載する）が管理サーバ１１０に通知する対象であるか否かを判定する。イベント回収部５１０は、エラーイベントが通知対象であるか否かを、通知設定保持部５２１に保存されたイベントの通知設定に従って判定する。イベントの通知設定においてエラーイベントを含むコレクションが管理サーバ１１０への通知対象に設定されていた場合は、ステップＳ６０３に進む。一方、イベントの通知設定においてエラーイベントを含むコレクションが管理サーバ１１０への通知対象に設定されていなかった場合は、本処理を終了する。ステップＳ６０１およびステップＳ６０２により、イベント回収部５１０は、イベントの通知設定において通知対象に設定されているイベントのみを収集することができる。

ステップＳ６０３において、イベント回収部５１０は、現在時刻を取得する。そして、ステップＳ６０４において、イベント回収部５１０は、イベントを発行して管理サーバ１１０に送信する。ステップＳ６０４の詳細な処理について図６（Ｂ）を用いて説明する。

図６（Ｂ）は、ステップＳ６０４の処理、すなわちイベントを発行して管理サーバ１１０に送付する処理を示すフローチャートである。ステップＳ６１１において、イベント回収部５１０は、ステップＳ６０１で検知したイベントに応じた情報をデバイス１２０内の各モジュールから収集する。ここで収集される情報は、イベントごとにあらかじめ紐づけられた情報であり、検知されたイベントと共に管理サーバ１１０に送信される。ステップＳ６０１で検知したイベントがエラーイベントである場合は、エラーイベントに付与する情報を収集する。例えばエラーイベントでは、エラーコードやエラーが起きた部品の名称、その時までの通紙したカウント値などが収集対象の付与情報になる。また、例えばコピージョブの完了イベントでは、実行ユーザ名、カラーモノクロの区別、スキャン枚数、プリント枚数などが収集対象の付与情報になる。

ステップＳ６１２において、イベント回収部５１０は、エラーイベントを付与情報と時刻情報と共に正規化する。イベント回収部５１０は、例えば、ＪＳＯＮなどのフォーマットで正規化する。ステップＳ６１３において、イベント回収部５１０は、ステップＳ６１２で正規化されたエラーイベントをメッセージバッファ５２０に保存する。イベントがメッセージバッファ５２０に保存された時点でサーバへの送付内容が確定される。

ステップＳ６１４において、イベント送付部５３０は、メッセージバッファ５２０からイベントを読み出す。イベント送付部５３０は、ステップＳ６１３におけるメッセージバッファ５２０へのイベントの書き込みを非同期に検知し、メッセージバッファ５２０からのイベントの読み出しを行う。ステップＳ６１５において、イベント送付部５３０は、読み出したイベントを管理サーバ１１０へ送信する。イベント送付部５３０は、管理サーバ１１０への認証動作や通信エラー時のリトライ処理などを含めて送信完了までを実行する。デバイス１２０からイベントを受信ｓ似た管理サーバ１１０は、受信したイベントをストレージに保存する。以上の処理により、デバイス１２０内で発生した各種事象は管理サーバ１１０に収集され、システム１１１が提供する各種サービスで利用可能となる。

図６の処理で収集、保存されたデバイス１２０のデータは、管理サーバ１１０に送信され、管理サーバ１１０を含むシステム１１１上に構築される各種サービスやアプリケーションに利用される。そのため、契約したサービスに応じて必要なデータすなわち収集すべきデータが異なるので、サービスごとにイベントの通知設定が異なる。本実施形態では、イベントの通知設定はコレクションファイルの形式で管理される。したがって、契約したサービスごとにコレクションファイルに記載する内容が異なる。例えば、ダッシュボードなどで運用中状況などのマクロな稼働状況の監視を行うサービスを提供するシステムの場合は、表１のＣｏｕｎｔｅｒおよびＡｌａｒｍのコレクションをコレクションファイルに記載する。消耗品の自動配送サービスを提供するシステムでは、表１のＩｍｆｏｒｍａｔｉｏｎのコレクションをコレクションファイルに記載する。デバイス１２０の稼働状況を監視してメンテナンスサービスを提供するシステムでは、表１のＤｉａｇｎｏｓｉｓのコレクションをコレクションファイルに記載する。

イベントの通知設定であるコレクションファイルを設定、管理する処理について説明する。図７は、イベントの通知設定を取得・更新する処理を示すフローチャートである。図７において、デバイス１２０にサービスを提供する管理サーバ１１０を含むシステム１１１が実行する各処理は、管理サーバ１１０が実行するものとして説明する。図７に示される管理サーバ１１０側の各処理は、ＣＰＵ２０１が、読み取り可能な記憶媒体（ＲＯＭ２０２またはＨＤＤ２０４）に格納されたプログラムをＲＡＭ２０３に展開して実行することにより実現される。また、デバイス１２０側の各処理は、ＣＰＵ４０１が、読み取り可能な記憶媒体（ＲＯＭ４０２またはＨＤＤ４０４）に格納されたプログラムをＲＡＭ４０３に展開して実行することにより実現される。

まず、管理サーバ１１０側がデバイス１２０と接続する前に実施する事前処理について説明する。ステップＳ７０１において、管理サーバ１１０は、これから接続されるデバイス装置の情報を登録する。デバイス装置の情報には、デバイスシリアル番号や顧客情報などが含まれる。本実施形態では、管理サーバ１１０がデバイス１２０と接続する例を説明する。次に、ステップＳ７０２において、管理サーバ１１０は、デバイス１２０を有する顧客の契約内容に基づいて、デバイス１２０に提供するサービスを決定する。ステップＳ７０３において、管理サーバ１１０は、デバイス１２０に提供するサービスに応じてデバイス１２０に配置するコレクションファイルの内容を決定する。

一方、デバイス１２０側では、ステップＳ７５１において、ネットワーク通信部５３１が管理サーバ１１０への接続動作を実施する。具体的には、ネットワーク設定で管理サーバ１１０のアドレスを入力するなどの手順でネットワーク１００を介して管理サーバ１１０と接続する。そして、デバイス１２０は管理サーバ１１０上のアプリケーションとの通信を実施する。デバイス１２０からの接続処理（ステップＳ７５１）を受けて、ステップＳ７０４で管理サーバ１１０は、デバイス１２０の接続を確認する。以上によりデバイス１２０と管理サーバ１１０間での通信が確立し、データのやり取りが可能となる。

ステップＳ７０５において、管理サーバ１１０は、ステップＳ７０３で決定したコレクションファイルをデバイス１２０に送信する。ステップＳ７５２において、デバイス１２０の通知設定取得部５３２は、管理サーバ１１０から送信されたコレクションファイルを受信する。ステップＳ７５３において、通知設定取得部５３２は、ステップＳ７５２で取得したコレクションファイルと通知設定保持部５２１に保存している取得元が同じコレクションファイルとを比較し、変更があるか否か判定する。変更があった場合は、ステップＳ７５４に進む。一方、変更がなかった場合はステップＳ７５５に進む。なお、通知設定保持部５２１に取得元が同じコレクションファイルが存在しない場合、すなわち初めて管理サーバ１１０から受信したコレクションファイルであった場合は、変更があったものとしてステップＳ７５４に進むものとする。

ステップＳ７５４において、通知設定取得部５３２は、通知設定保持部５２１に保存されているコレクションファイルを、ステップＳ７５２で受信したコレクションファイルに書き換える。更新された最新のコレクションファイルに従ってイベントの収集保存が行われることにより、管理サーバ１１０から指示されたイベントの送付を実行することができる。以降はステップＳ７５５で一定時間待機した後ステップＳ７５２に戻り、管理サーバ１１０から最新のコレクションファイルを入手し、内容に変更があれば通知設定保持部５２１のコレクションファイルに反映させるという動作を繰り返す。

管理サーバ１１０側ではステップＳ７０５の後、デバイス１２０に提供するサービスに変更があった場合にはコレクションファイルを変更して、変更後のコレクションファイルをデバイス１２０に送付できるようにする。具体例には、まずステップＳ７０６において、管理サーバ１１０は、顧客の契約内容が変更になるなどしてデバイス１２０に提供するサービスの内容が変更になったか否か判定する。サービスの内容が変更になった場合はステップＳ７０７に進む。一方、サービスの内容に変更がない場合はステップＳ７０６を繰り返す。ステップＳ７０７において、管理サーバ１１０は、サービスの変更に応じてコレクションファイルを変更する。コレクションファイルの変更が完了すると、ステップＳ７０５に戻り、変更後のコレクションファイルをデバイス１２０に送信する。

以上説明したように、管理サーバ１１０でコレクションファイルを変更してデバイス１２０が保持するコレクションファイルに反映することで、顧客の契約するサービス内容に応じてデバイス１２０の通知設定を変更することが可能となる。

図８は、第１実施形態におけるコレクションファイルの一例を示す図である。コレクションファイル８００は、イベントの通知設定が記載された定義情報であり、デバイス１２０内で収集されるべきデータの種類と収集される条件が定義されている。コレクションファイル８００は、管理サーバ１１０で生成され、図７のステップＳ７０５で管理サーバ１１０からデバイス１２０に送信される。管理サーバ１１０から送信されたコレクションファイル８００をデバイス１２０はステップＳ７５２で受信し、通知設定保持部５２１で保持する。デバイス１２０内のデータを収集する際には、ステップＳ６０２においてコレクションファイル８００の記載内容が参照される。本実施形態では、JＳＯＮ形式のコレクションファイル８００の例を説明するが、コレクションファイル８００の形式はＸＭＬ・ＣＳＶなどテキストで正規化できるフォーマットであればよい。

コレクションファイル８００には、３種類の通知設定（通知設定８０１～通知設定８０３）が記載されている。各通知設定には、管理サーバ１１０に送付するために収集されるべきデータの種類と、収集される条件が記載されている。具体例には、データの種類としてイベントが属するコレクションが記載され、データの収集条件としてデータを収集するタイミングが記載されている。

通知設定８０１には、収集されるべきデータの種類として“Ｐｏｗｅｒ”と“Ａｌａｒｍ”が、収集される条件として“ｒｅａｌｔｉｍｅ”が記載されている。“ｒｅａｌｔｉｍｅ”はイベント発生時に即座に送付するという定義である。すなわち、通知設定８０１では、ＰｏｗｅｒとＡｌａｒｍのコレクションに属すイベントが発生した場合、即座に送信するよう設定されている。“ｒｅａｌｔｉｍｅ”が設定されている場合は、デバイス１２０内でエラー等、ＰｏｗｅｒもしくはＡｌａｒｍのコレクションに属するイベントが発生した際に、ステップＳ６０２でエラーイベントの送付が必要と判断される。そして、エラーに対応するイベントが発行され、管理サーバ１１０に送付されることになる。

通知設定８０２には、収集されるべきデータの種類として“Ｂａｓｉｃ”が、収集される条件として“ｕｐ”が記載されている。本実施形態において、Ｂａｓｉｃのコレクションに属するイベントは、ＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄである。ｕｐはデバイス１２０の起動時に送信するという定義である。さらに、追加の指定で“ｓｔａｒｔＯｆｆｓｅｔ”が記載され、オフセット上限時間が設定されている。通知設定８０２の記載では、オフセット上限時間が３０分に設定されている。オフセット上限時間の設定のより、Ｂａｓｉｃのコレクションに属するイベントの送信タイミングとして、起動直後から３０分を上限としたランダムなオフセットが指定される。したがって、デバイス１２０の起動のタイミングから３０分以内のオフセット時間をデバイス１２０がランダムに生成し、オフセット時間だけ待った後に、Ｂａｓｉｃのコレクションに属するイベントが管理サーバ１１０に送信されることになる。なお、本実施形態ではオフセットの上限時間が指定されている例について説明するが、固定のオフセット時間が指定されていてもよい。

通知設定８０３には、収集されるべきデータの種類として“ＤｅｖｉｃｅＬｏｇ”が、収集される条件として“ｃｒｏｎ”が記載されている。本実施形態において、ＤｅｖｉｃｅＬｏｇのコレクションに属するイベントは、ＤｅｖｉｃｅＬｏｇＤａｔａである。通知設定８０３のｃｒｏｎの例では、定期送信の周期が２４時間、送信開始時刻が２０２０年１２月１日００：００に定義されている。すなわち、通知設定８０３では、ＤｅｖｉｃｅＬｏｇのコレクションに属するイベントを、送信開始時刻の２０２０年１２月１日００：００に最初に送付し、以降２４時間周期で管理サーバ１１０に送付するよう設定されている。送信開始時刻で指定された日付が現在時刻よりも前の日付だった場合、直近の日付の指定された時刻（００：００）にイベントが送信される。例えば、現在が２０２０年１２月０３日１８：００であった場合、通知設定８０３の指定により、ＤｅｖｉｃｅＬｏｇのコレクションに属するイベントが次に送信がされるのは２０２０年１２月０４日の００：００である。

以上説明したように、通知設定８０１はイベントの即時送信を設定し、通知設定８０２はイベントの起動時送信を設定し、通知設定８０３はイベントの指定時刻送信を設定している。イベントの即時送信については、既に図６を参照して説明した。コレクションファイル８００において起動時送信イベントに設定されたＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄイベントと、指定時刻送信イベントに設定されたＤｅｖｉｃｅＬｏｇＤａｔａイベントの送付について図９および図１０を参照して説明する。

図９および図１０は、第１実施形態におけるイベントの送付処理を示すフローチャートである。図９および図１０に示される各処理は、ＣＰＵ４０１が、読み取り可能な記憶媒体（ＲＯＭ４０２またはＨＤＤ４０４）に格納されたプログラムをＲＡＭ４０３に展開して実行することにより実現される。図９および図１０では、具体例として、起動時送信イベントとしてＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄイベントを、指定時刻送信イベントとしてＤｅｖｉｃｅＬｏｇＤａｔａイベントを送信する場合について説明する。

図９および図１０に示される処理は、デバイス１２０が起動することによって開始される。ステップＳ９０１で、制御部５１１は、通知設定保持部５２１からコレクションファイル８００に設定されている通知設定の情報を取得する。ステップＳ９０２で、制御部５１１は、指定時刻送信イベントの送信予定時刻を計算する。制御部５１１は、コレクションファイル８００に記述された設定値と現在の時刻に基づいて、指定時刻送信イベントの送信予定時刻を算出する。コレクションファイル８００の例では、設定通知８０３でＤｅｖｉｃｅＬｏｇＤａｔａイベントが、送信開始時刻が２０２０年１２月１日００：００、定期送信の周期が２４時間の設定で指定時刻送信イベントとして設定されている。例えば、現在の時刻が２０２０年１２月２日０８：００である場合は、指定時刻送信イベントの送信予定時刻は、２０２０年１２月３日００：００と算出される。

ステップＳ９０３で、制御部５１１は、後述するＨＤＤ４０４に保持しておいた指定時刻送信イベントの送信予定時刻を参照し、ステップＳ９０２で算出した指定時刻送信イベントの送信予定時刻との比較を行う。ステップＳ９０４で、制御部５１１は、ステップＳ９０２で算出した指定時刻送信イベントの送信予定時刻が、ＨＤＤ４０４に保持しておいた指定時刻送信イベントの送信予定時刻を過ぎているか否か判定する。ＨＤＤ４０４に保持しておいた送信予定時刻は、指定時刻送信イベントが本来送信されるべき時刻であり、前回の指定時刻送信イベントの送信の後に次回の送信予定時刻として算出されＨＤＤ４０４に保存されている。デバイス１２０の電源ＯＦＦ等によりシステム１１１から指定された送信予定時刻に送信できなかった場合は、デバイス１２０の起動後にリカバリ送信が行われる。

ステップＳ９０２で計算した送信予定時刻がＨＤＤ４０４に保持しておいた送信予定時刻を過ぎている場合、すなわちデバイス１２０の起動後のリカバリ送信が必要な場合は、ステップＳ９０５へ進む。一方、Ｓ９０２で計算した送信予定時刻がＨＤＤ４０４に保持しておいた送信予定時刻を過ぎていない場合は、送信予定時刻に送信すればよいためリカバリ送信の必要はなく、ステップＳ９０７へ進む。なお、ステップＳ９０２で計算した送信予定時刻とＨＤＤ４０４に保持しておいた送信予定時刻とが一致する場合も、送信予定時刻に送信すればよいためリカバリ送信の必要はなく、ステップＳ９０７へ進む。例えば、ＨＤＤ４０４に保持していた送信予定時刻が２０２０年１２月０２日００：００であり、起動後にステップＳ９０２で計算した次の送信予定時刻が２０２０年１２月０２日００：００で一致する場合は、ステップＳ９０７に進む。一方、ＨＤＤ４０４に保持していた送信予定時刻が２０２０年１２月０２日００：００であり、ステップＳ９０２で計算した送信予定時刻が２０２０年１２月０３日００：００の場合は、２０２０年１２月０２日００：００の指定時刻送信を逃していることになる。この場合は、ステップＳ９０５へ進む。なお、本実施形態ではステップＳ９０２で計算した送信予定時刻とＨＤＤ４０４に保持された送信予定時刻が一致する場合にステップＳ９０７に進む例を説明したが、イベントの送信が重複する恐れを抑制するためにステップＳ９０５に進むように制御してもよい。

管理サーバ１１０から指定された送信時刻を過ぎていた場合はリカバリ送信を行う必要があるが、指定時刻送信イベントのリカバリ送信と起動時送信イベントの送付が重なってしまう恐れがある。リカバリ送信と起動時送信イベントの送信が重なってしまうと、デバイス１２０の処理の負荷や管理サーバ１１０との通信を行うためのネットワークの負荷が増大してしまう。また、管理サーバ１１０等にデータを送信する同一ネットワーク１００内の複数のデバイスの起動時刻が同時刻に設定されていた場合は、管理サーバ１１０との通信を行うためのネットワークの負荷が同じ時刻に集中してしまう恐れがある。そこで、デバイス１２０の起動時に指定時刻送信イベントのリカバリ送信を行う必要がある場合には、リカバリ送信と起動時送信イベントとの送信時刻の重複を抑制して、負荷を分散させる必要がある。

ステップＳ９０５で、制御部５１１は、通知設定保持部５２１のコレクションファイル８００に記述された設定値に基づいて、起動時送信イベントにオフセット上限時間が設定されているか判定する。コレクションファイル８００の例では、設定通知８０２で、起動時送信イベントであるＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄに３０分のオフセット上限時間が設定されている。オフセット上限時間が設定されている場合はステップＳ９０６に進む。一方、オフセット上限時間が設定されていない場合は、ステップＳ９１３に進む。

ステップ９１３およびステップＳ９１３に続くステップＳ９１４では、現在の時刻で指定時刻送信イベントのリカバリ送信を行う。すなわち、ステップＳ９０５で起動時送信イベントのオフセット上限時間が設定されていない場合には、指定時刻送信イベントを即時送信することになる。これは、管理サーバ１１０から指示されたコレクションファイル８００にオフセット上限時間の設定がないということは、ネットワーク負荷の懸念が少ない環境であると判断できるためである。ネットワーク負荷の懸念が少ない環境である場合には、指定時刻に送信できなかったデータをできるだけ早く送信するようにする。そのため、制御部５１１は、オフセット上限時間が設定されていない場合（ステップＳ９０５がＮｏ）には、指定時刻送信イベントの送信を起動時送信イベントの送信より遅らせる遅延処理を行わずに指定時刻送信イベントを即時送信するようにする。

ステップＳ９０６で、制御部５１１は、指定時刻送信イベントのリカバリ送信時刻と起動時送信イベントとの送信時刻が重ならないように、指定時刻送信イベントのリカバリ送信時刻を算出する。具体的には、制御部５１１は、指定時刻送信イベントのリカバリ送信時刻が、設定されているオフセット時間に従う起動時送信イベントの送信時刻よりさらに遅延するように設定する。指定時刻送信イベントのリカバリ送信時刻を起動時送信イベントに設定されているオフセット上限時間よりさらに遅延させることで、指定時刻送信イベントのリカバリ送信時刻と起動時送信イベントとの送信時刻の重複を回避することが可能となる。

例えば、制御部５１１は、起動時送信イベントの送信時刻に所定の時間を加算し、リカバリ送信時刻とする。加算する所定の時間は、０より大きい値で、かつ、リカバリ送信として遅くなりすぎない時間であればよい。例えば、加算する所定の時間は、予め決定された固定の時間でもよいし、コレクションファイル８００の設定通知８０２のオフセット上限時間と同じ固定値でもよいし、オフセット上限時間からオフセット上限時間の２倍の時間の間のランダムな時間としてもよい。例えば、コレクションファイル８００で起動時送信イベントのオフセット上限時間が３０分に設定されている場合、起動時送信イベントの送信時刻は３０分を上限として制御部５１１が乱数をかけるなどして生成した時刻となる。ここでは、制御部５１１が起動時送信イベントの送信予定時刻を９分後と算出したとする。加算する所定の時間がオフセット上限時間と同じである場合は、リカバリ送信時刻は、起動時送信イベントの送信予定時刻（９分）にオフセットの上限時間（３０分）を加算した３９分と設定される。すなわち、起動時送信イベントが９分後に送信され、指定時刻送信イベントのリカバリ送信は３９分後に送信されるため、送信時刻が重なることがない。このように、制御部５１１はネットワーク負荷が懸念される場合において、電源ＯＦＦ等から復帰後のリカバリ送信を起動時送信よりも遅延させる処理（ステップＳ９０３～ステップＳ９０６）を行うことで、データの送信の重複を抑制することができる。

ステップＳ９０７で、制御部５１１は、起動時送信イベントの送信時刻のタイマーを設定する。具体的には、制御部５１１は、コレクションファイル８００で設定されている起動時送信イベントのオフセット上限時間を読み出し、起動時送信イベントの送信時刻としてオフセット上限時間を超えないランダムな時間を決定する。そして、制御部５１１は、タイマー通知部５４０に指示して起動時送信イベントの送信時刻のタイマーを設定させる。

ステップＳ９０８で、制御部５１１は、指定時刻送信イベントの送信時刻のタイマーを設定する。具体的には、制御部５１１は、タイマー通知部５４０に指示して、ステップＳ９０６もしくはステップＳ９１５で算出した指定時刻送信イベントの送信時刻のタイマーを設定させる。

ステップＳ９０９で、制御部５１１は、タイマー通知部５４０からステップＳ９０８で設定した指定時刻送信イベントの送信時刻経過の通知を受けたか判定する。タイマー通知部５４０から指定時刻送信イベントの送信時刻経過の通知を受けた場合は、ステップＳ９１３に進む。一方、タイマー通知部５４０から指定時刻送信イベントの送信時刻経過の通知が来ていない場合は、ステップＳ９１０に進む。

ステップＳ９１０で、制御部５１１は、タイマー通知部５４０からステップＳ９０７で設定した起動時送信イベントの送信時刻経過の通知を受けたか判定する。起動時送信イベントの送信時刻経過の通知を受けた場合は、ステップＳ９１１に進む。一方、起動時送信イベントの送信時刻経過の通知が来ていない場合は、ステップＳ９０９に戻り送信時刻の確認処理を繰り返す。

起動時送信イベントの送信時刻になったら、ステップＳ９１１で、制御部５１１は、現在の時刻を取得する。ステップＳ９１２で、制御部５１１は、起動時送信イベントを発行し、送付する処理を実施する。ステップＳ９１２の具体的な処理内容は、図６（Ｂ）で示した処理と同様である。一方、指定時刻送信イベントの送信時刻になったら、ステップＳ９１３で、制御部５１１は、現在の時刻を取得する。ステップＳ９１４で、制御部５１１は、起動時送信イベントを発行し、送付する処理を実施する。ステップＳ９１４の具体的な処理内容は、図６（Ｂ）で示した処理と同様である。

ステップＳ９１５で、制御部５１１は、次に指定時刻送信イベントを送信すべき送信予定時刻を計算する。例えば、コレクションファイル８００の通知設定８０３の設定で送信間隔が２４時間で送信開始時刻が２０２０年１２月０１日００：００に指定され、現在時刻が２０２０年１２月０４日１４：００であるとする。この場合、次の指定時刻送信イベントの送信時刻は２０２０年１２月０１日００：００から２４時間ずつずらした直近の日時の１２月０５日００：００と計算される。

ステップＳ９１６で、制御部５１１は、ステップＳ９０３で参照したＨＤＤ４０４に保持しておいた送信予定時刻を、ステップＳ９１５で計算した次の送信予定時刻に更新する。このように、指定時刻送信イベントを送信した後に次回の送信予定時刻をＨＤＤ４０４の不揮発な領域に書き込んでおくことで、電源ＯＦＦから復帰した際に送信予定時刻を過ぎているか否かをステップＳ９０４で判定することができる。ステップＳ９１６で、制御部５１１は、ＨＤＤ４０４の送信予定時刻を更新する。送信予定時刻を更新後、ステップＳ９０８へ戻る。

以上説明したように本実施形態によると、起動時送信イベントにオフセットが設定されており、かつ、指定時刻送信イベントの送信予定時刻を超過していた場合、指定時刻送信イベントのリカバリ送信を起動時送信イベントの送信より遅延させることができる。これにより、デバイス１２０の起動後の複数のイベントの同時送信によるネットワーク１００の負荷の増大を抑制することができる。一方で、起動時送信イベントにオフセットが設定されていない場合、すなわちネットワーク負荷が致命的にならないと判断できる場合には、指定時刻送信イベントを起動後即時送信するもできるので、環境に合わせて柔軟に対応ができる。

なお、ステップＳ９０８ではステップＳ９０６で算出したオフセット時間後を送信予定時刻としていた。しかし、指定時刻送信イベントが、例えばデータのサイズが非常に大きい場合や指定時刻にデータを収集しなければならない場合も考えられる。このように、イベントのデータ量が所定の量より大きい場合や通知設定において送信時刻以外の送信が認められていない場合は、指定時刻以外に送信をさせないように、ステップＳ９０２で算出した次の指定時刻にタイマーをセットするようにすればよい。また、本実施形態では、イベントの発行を行うタイミングを制御することでイベントの送信タイミングを制御していたが、これに限られるものではない。例えば、制御部５１１がメッセージバッファ５２０からイベントを読み出すタイミングを制御する等により、イベントの送信のタイミングが重複しないように制御するようにしてもよい。

（第２実施形態）
第１実施形態では起動時送信イベントが起動時に送信される場合を前提に説明してきたが、起動時送信イベントがない場合もある。第２実施形態では、起動時送信イベントがない場合について説明する。起動時送信イベントがない場合は、電源復帰後即時に指定時刻送信イベントのリカバリ送信を行っても起動時送信イベントとの重複は起こらないため、ネットワーク負荷の影響が明確に判断できない。しかし、例えば同一ネットワーク１００に複数のデバイス１２０が接続され、各デバイスの起動タイミングが同時である場合には、ネットワーク１００に負荷がかかってしまう恐れがある。そのため、本実施形態では、起動時送信イベントがない場合でも同時に起動した各デバイス１２０のリカバリ送信の重複により生じてしまう恐れのあるネットワーク負荷の増大を抑制するために、リカバリ送信の送信時刻を起動後即時よりも遅らせるよう制御する。

図１１は、第２実施形態におけるコレクションファイルの一例を示す図である。コレクションファイル１１００は、イベントの通知設定が記載された定義情報であり、デバイス１２０内で収集されるべきデータの種類と収集される条件が定義されている。コレクションファイル１１００は、コレクションファイル８００と同様に、管理サーバ１１０からデバイス１２０に送付され、通知設定保持部５２１に保持されている。デバイス１２０内のデータを収集する際には、コレクションファイル８００の記載内容が参照される。本実施形態では、ＪＳＯＮ形式のコレクションファイル１１００の例を説明するが、コレクションファイル１１００の形式はＸＭＬ・ＣＳＶなどテキストで正規化できるフォーマットであればよい。

コレクションファイル１１００には、２種類の通知設定（通知設定１１０１，通知設定１１０２）が記載されている。各通知設定には、管理サーバ１１０に送付するために収集されるべきデータの種類と、収集される条件が記載されている。具体例には、データの種類としてイベントが属するコレクションが記載され、データの収集条件としてデータを収集するタイミングが記載されている。

通知設定１１０１は、通知設定８０１と同様の通知設定である。通知設定１１０２は、通知設定８０３と同様の通知設定である。通知設定１１０１はリアルタイム送信イベントを、通知設定１１０１は指定時刻送信イベントを定義している。第１実施形態のコレクションファイル８００との違いは、通知設定８０２で定義されていた起動時送信イベントがない点である。したがって、コレクションファイル１１００に従ったイベントの送信では、起動時送信イベントは送信されない。

図１２および図１３は、第２実施形態におけるイベントの送付処理を示すフローチャートである。図１２および図１３に示される各処理は、ＣＰＵ４０１が、読み取り可能な記憶媒体（ＲＯＭ４０２またはＨＤＤ４０４）に格納されたプログラムをＲＡＭ４０３に展開して実行することにより実現される。以下では、第１実施形態におけるイベントの送付処理（図９および図１０）と異なる部分についてのみ説明する。

ステップＳ９０４において、Ｓ９０２で算出した指定時刻送信イベントの送信予定時刻がＨＤＤ２０８に保存されていた送信予定時刻を超過していると判定された場合、ステップＳ１２０１に進む。ステップＳ１２０１で、制御部５１１は、通知設定保持部５２１が保持するコレクションファイル１１００に起動時送信イベントが記述されているか判定する。制御部５１１は、例えば、コレクションファイル１１００にイベントが収集される条件として起動時の送付を示す“ｕｐ”が記載されているか否かにより起動時送信イベントが記述されているか判定する。起動時送信イベントが記述されている場合は、ステップＳ９０５に進む。一方、起動時送信イベントが記述されていない場合は、起動時送信イベントはないためステップＳ１２０２に進む。

ステップＳ１２０２で、制御部５１１は、指定時刻送信イベントのリカバリ送信の送信予定時刻を算出する。ここで、制御部５１１は、デバイス１２０の起動後の即時の送信時刻よりも遅延させた時刻をリカバリ送信の送信予定時刻に設定する。例えば、制御部５１１は、現在時刻にランダムな時間を加算し、指定時刻送信イベントのリカバリ送信の送信予定時刻とする。ここで、加算するランダムな時間は０より大きく、かつ、所定の上限時間以下であればよい。所定の上限時間は、例えば送信データのサイズなどのパラメータに応じて決定してもよいし、固定値としてもよい。

以上説明したように、本実施形態によるとステップＳ１２０２に処理により、電源ＯＦＦ等により指定時刻送信イベントの送信ができずに電源復帰後にリカバリ送信する場合、リカバリ送信の送信時刻を遅延させることができる。これにより、起動時送信イベントのオフセットの設定がない場合でも、リカバリ送信によるネットワーク負荷を分散させることができる。

（第３実施形態）
第１実施形態では起動時送信イベントと指定時刻送信イベントの間に関連がなく、どちらを先に送信しても影響がない場合について説明してきた。しかし、送信する複数のイベントの間に送信順の優先順位が規定されていることもある。イベントの送信の順序に優先順位が規定されている場合、優先順位の通りにデータを送信しなければサーバ側でうまく処理ができないなどの制約があるため、優先順位通りに送信しなければならない。

表２は、イベントの通知設定とイベントの関係を示す表である。表２では、表１の内容に加えて各コレクションに送信の優先順位を定義している。送信のタイミングが重なってしまう場合、優先順位の値が小さいほうから先に送信が行われる。優先順位は、例えば、コレクションファイルに定義され、制御部５１１が指定時刻送信イベントを発行する際に参照する。

Ｂａｓｉｃのコレクションに対応するＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄイベントは起動時に送信する対象であり、優先順位は２になっている。一方、ＤｅｖｉｃｅＬｏｇのコレクションに対応するＤｅｉｃｅＬｏｇＤａｔａイベントは定期送信の対象であり、優先順位は１となっている。その他のイベントの優先順位は３になっている。この優先順位に従うと、送信のタイミングが重なってしまう場合、優先順位の値が小さいＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄイベントが先に送信され、次にＤｅｉｃｅＬｏｇＤａｔａイベント、その次にその他のイベントが送信される。したがって、制御部５１１は、メッセージバッファ５２０にＤｅｖｉｃｅＬｏｇＤａｔａを１番目に、ＢａｓｉｃＩｎｆｏＳｎａｐｓｈｏｔｔｅｄを２番目に書き込むように制御部５１１を制御する。

図１４および図１５は、第３実施形態におけるイベントの送付処理を示すフローチャートである。図１４および図１５に示される各処理は、ＣＰＵ４０１が、読み取り可能な記憶媒体（ＲＯＭ４０２またはＨＤＤ４０４）に格納されたプログラムをＲＡＭ４０３に展開して実行することにより実現される。以下では、第１実施形態におけるイベントの送付処理（図９および図１０）と異なる部分についてのみ説明する。

ステップＳ９０５において、起動時送信イベントにオフセット上限時間が設定されていると判定された場合、ステップＳ１４０１に進む。ステップＳ１４０１で、制御部５１１は、各イベントの優先順位の情報を取得し、送信すべき対象となっている起動時送信イベントとリカバリ送信の対象となっている指定時刻送信イベントの優先順位を比較する。起動時送信イベントよりも指定時刻送信イベントの優先順位が高い場合は、ステップＳ１４０２へ進む。一方、起動時送信イベントよりも指定時刻送信イベントの優先順位が低い場合は、第１実施形態と同様にリカバリ送信を起動時送信イベントの送信よりも遅延させればよいため、ステップＳ９０６へ進む。

起動時送信イベントよりも指定時刻送信イベントの優先順位が高い場合は優先順位に従って送信するために、ステップＳ１４０２およびステップＳ１４０３で指定時刻送信イベントのリカバリ送信時刻が起動時送信イベントの送信時刻より先になるよう設定する。ステップＳ１４０２で、制御部５１１は、指定時刻送信イベントのリカバリ送信時刻を設定する。制御部５１１は、例えば、指定時刻送信イベントを起動時送信イベントより先に送信するため、現在の時刻に内部で保持する固定のオフセット上限時間を上限とするランダムな時間を加算し、リカバリ送信の送信時刻として計算する。ステップＳ１４０３で、制御部５１１は、起動時送信イベントの送信時刻を設定する。制御部５１１は、例えば、現在の時刻に内部で保持する固定のオフセット上限時間とコレクションファイル８００の通知設定８０２で設定されたオフセット上限時間を上限とするランダムな時間を加算し、起動時送信イベントの送信時刻として計算する。

指定時刻送信イベントの優先順位が起動時送信イベントよりも高く設定されている場合において、例えば、固定のオフセット上限時間が２０分で、通知設定８０２で指定された起動時送信イベントのオフセット上限時間の設定値が３０分であったとする。固定のオフセット上限時間に乱数をかけて算出したオフセット時間は１８分であったとすると、指定時刻送信イベントのリカバリ送信の送信予定時刻は１８分後となる。一方で、起動時送信イベントのオフセット時間は、オフセット上限時間３０分に乱数をかけて２６分であったとする。この場合、起動時送信イベントの送信予定時刻は固定オフセット上限時間２０分とランダムなオフセット時間２６分を足して４６分後となる。

ステップＳ１４０４で、制御部５１１は、ステップＳ１４０３で算出した起動時送信イベントの送信時刻でタイマーを設定するようタイマー通知部５４０に指示する。なお、ステップＳ１４０２およびステップＳ１４０３では、指定時刻送信イベントのリカバリ送信の送信時刻が起動時送信イベントの送信時刻より先になるよう設定すればよく、送信時刻の設定方法は問わない。例えば、ステップＳ１４０３は、制御部５１１は、ステップＳ１４０２で算出した指定時刻送信イベントの送信時刻に所定の時間を加算して起動時送信イベントの送信時刻とするようにしてもよい。

以上のように本実施形態によると、イベントの送信順に優先順位が規定されている場合に、デバイス１２０の起動時に指定時刻送信イベントと起動時送信イベントとを送信する際には優先順位通りに送信をおこなうことができる。

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

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

Claims (8)

1. ネットワークデバイス内で収集したデータをネットワークを介してシステムに送信するネットワークデバイスであって、
   前記ネットワークデバイスの起動時にリカバリ送信が行われる対象のデータについては、前記ネットワークデバイスの起動時に送信するイベントの送信の設定においてオフセット時間が設定されている場合、該オフセット時間に従う前記イベントの送信よりもさらに遅延させて、前記リカバリ送信の対象のデータの送信を行う制御手段を有する、ことを特徴とするネットワークデバイス。
2. 前記オフセット時間として、オフセットの上限時間が設定されている場合、
   前記制御手段は、前記リカバリ送信の対象のデータの送信を起動時に送信するイベントに設定されているオフセットの上限時間よりも遅らせることで、前記イベントの送信よりもさらに遅延させて、前記リカバリ送信の対象のデータの送信を行うことを特徴とする請求項１に記載のネットワークデバイス。
3. 前記ネットワークデバイスの起動時に送信する前記イベントの送信の設定において、オフセット時間が設定されていない場合、前記制御手段は、前記リカバリ送信の対象のデータの送信を遅延させる処理を行わずに、前記リカバリ送信の対象のデータの送信を行うことを特徴とする請求項１または２に記載のネットワークデバイス。
4. 前記ネットワークデバイスの起動時に送信するイベントがない場合、前記制御手段は、前記ネットワークデバイスの起動後即時よりも遅延させて、前記リカバリ送信の対象のデータの送信を行うことを特徴とする請求項１乃至３のいずれか１項に記載のネットワークデバイス。
5. 前記ネットワークデバイスの起動時に送信するイベントの送信の設定においてオフセット時間が設定されている場合、かつ、前記リカバリ送信の対象のデータの送信の優先順位が前記ネットワークデバイスの起動時に送信する前記イベントの送信の優先順位よりも高い場合には、前記制御手段は、前記リカバリ送信の対象のデータの送信よりもさらに遅延させて、前記イベントの送信を行うことを特徴とする請求項１乃至４のいずれか１項に記載のネットワークデバイス。
6. 起動時にリカバリ送信が行われる対象のデータは、前記システムから指定された送信時刻に送信ができなかったデータであり、前記制御部は、前記ネットワークデバイスを起動した際に現在の時刻と前記システムに指定された送信時刻から算出した次回の送信予定時刻が、前回、前記システムに送信時刻が指定されたデータを送信した際に保存した次回のデータの送信予定時刻を超過していた場合に、システムから指定された送信時刻に送信ができなかったと判定することを特徴とする請求項１乃至５のいずれか１項に記載のネットワークデバイス。
7. ネットワークデバイス内で収集したデータをネットワークを介してシステムに送信するネットワークデバイスの制御方法であって、
   前記ネットワークデバイスの起動時にリカバリ送信が行われる対象のデータについては、前記ネットワークデバイスの起動時に送信するイベントの送信の設定においてオフセット時間が設定されている場合、該オフセット時間に従う前記イベントの送信よりもさらに遅延させて、前記リカバリ送信の対象のデータの送信を行う制御工程を有する、ことを特徴とするネットワークデバイスの制御方法。
8. 請求項１乃至６のいずれか１項に記載のネットワークデバイスの制御手段としてコンピュータを機能させるためのプログラム。

Images