JP2019028757A - サーバーシステム、稼働情報収集システム及びサーバーシステムの作動方法 - Google Patents

Abstract

【課題】 所定種別の情報をプッシュ通知する経路を設けることで、当該種別の情報を迅速に端末装置に送信するサーバーシステム、稼働情報収集システム及びサーバーシステムの作動方法等の提供。【解決手段】 サーバーシステム７は、収集対象機器の稼働情報をネットワークを介して収集するサーバーシステムであって、通信接続の確立後、確立状態が維持される第１の通信処理と、情報が受信されると通信接続が切断される第２の通信処理と、を行う通信部７３１と、処理部７１と、記憶部７５を含む。通信部７３１は、稼働情報の第１の情報は第１の通信処理により受信し、第２の情報は第２の通信処理により受信し、第１の情報のうちの所与の種別の情報を受信したときに、端末装置９に対してプッシュ通知を行う。【選択図】 図１

Description

本発明は、サーバーシステム、稼働情報収集システム及びサーバーシステムの作動方法等に関する。

従来、ネットワークに接続された複数の機器の稼働情報を収集するサーバーシステムが知られている。稼働情報の収集対象機器は種々考えられるが、例えばプリンター等の生産機器である。

サーバーシステムが収集した稼働情報の用途は種々考えられる。例えば、サーバーシステムは、収集した稼働情報をユーザーが使用する端末装置に対して送信する。このようにすれば、ユーザーはプリンターの稼働状態を端末装置を用いて確認することが可能になる。例えば、プリンターから離れた場所にいるユーザーが、当該プリンターの稼働状態（例えばジョブの進捗状態）を遠隔監視することも可能になる。

プリンターの実際の稼働状態と、端末装置で閲覧する稼働情報との間に乖離がある場合、端末装置を利用するユーザーはプリンターの状態を誤認してしまい、適切な対応をとれないおそれがある。特許文献１には、管理サーバーが仲介サーバー（ローカルＰＣ）経由でプリンターの稼働情報を収集する構成において、仲介サーバーがプリンター毎にアクセスするタイミングを設定して、稼働情報を収集（ポーリング）する頻度を調整する手法が開示されている。

特開２０１６−１３６３０９号公報

特許文献１の手法では、稼働情報の収集が設定された頻度で行われるため、ジョブ完了やエラー発生等、ユーザーにいち早く通知すべき情報を、端末装置に迅速に送信できないおそれがある。また、単純に収集頻度を高くした場合、通信負荷が増大してしまう。

本発明の一態様は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムであって、通信接続の確立後、前記通信接続の確立状態が維持される第１の通信処理と、通信接続の確立後、情報が受信されると前記通信接続が切断される第２の通信処理と、を行う通信部と、処理部と、記憶部と、を含み、前記通信部は、前記稼働情報のうちの第１の情報については前記第１の通信処理により受信し、前記稼働情報のうちの第２の情報については前記第２の通信処理により受信し、前記処理部は、前記第１の通信処理により受信した前記第１の情報、及び前記第２の通信処理により受信した前記第２の情報を前記記憶部に書き込み、前記通信部は、受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うサーバーシステムに関係する。

また本発明の一態様では、稼働情報の第１の情報と第２の情報を、それぞれ異なる通信処理により受信し、受信した第１の情報が所定種別である場合に、端末装置に対してプッシュ通知を行う。このように、端末装置へのプッシュ通知に関連する可能性がある第１の情報の通信経路と、第２の情報の通信経路を分けることで、通信負荷を抑制しつつ、第１の情報の取得及びプッシュ通知を迅速に行うこと等が可能になる。

また本発明の一態様では、前記処理部は、前記第１の通信処理により受信した前記第１の情報を前記記憶部に上書きし、前記第２の通信処理により受信した前記第２の情報を前記記憶部に追記書き込みしてもよい。

このようにすれば、情報の種別に応じた適切な態様で、記憶部への書き込みを行うことが可能になる。

また本発明の一態様では、前記通信部は、前記端末装置から報知設定情報を受信し、受信した前記報知設定情報に基づき前記プッシュ通知を行ってもよい。

このように、端末装置側で行われた設定に基づいてプッシュ通知を実行することで、ユーザーの望む態様でプッシュ通知を行うことが可能になる。

また本発明の一態様では、前記通信部は、前記第２の通信処理により、前記報知設定情報を前記端末装置から受信してもよい。

このようにすれば、報知設定情報を適切な通信処理により受信することが可能になる。

また本発明の一態様では、前記第１の情報は、前記収集対象機器で発生したイベントをトリガーとして送信される情報であり、前記第２の情報は、所与のスケジュールで送信される情報であってもよい。

このようにすれば、第１の情報をイベント発生後、迅速に受信すること、及び第２の情報の通信による負荷増大を抑制すること等が可能になる。

また本発明の一態様では、前記第１の情報は、前記収集対象機器のステータスの変化情報、ジョブの開始／終了情報、消費材に関する情報、ジョブの時間情報、ジョブの進捗情報の少なくとも１つを含んでもよい。

このようにすれば、重要度の高い所定の情報を迅速に収集することが可能になる。

また本発明の一態様では、前記収集対象機器は印刷装置であり、前記第１の情報は、前記印刷装置のエラー状態、警告状態、通常動作状態、アイドル状態の少なくとも１つの状態を含むステータスの変化情報、インク又はトナーに関する情報、印刷媒体に関する情報、印刷完了時刻情報、印刷完了までの残り時間情報、印刷動作の進捗情報、の少なくとも１つを含んでもよい。

このようにすれば、プリンターの動作において重要度の高い所定の情報を、迅速に収集することが可能になる。

また本発明の一態様では、前記第２の情報は、前記収集対象機器の稼働状態についての履歴情報であってもよい。

このようにすれば、履歴情報を収集することが可能になる。

また本発明の一態様では、前記履歴情報は、前記収集対象機器で発生したイベントにタイムスタンプが対応づけられた情報であってもよい。

このようにすれば、時系列的な稼働情報を履歴情報として収集することが可能になる。

また本発明の一態様では、前記第２の情報は、前記収集対象機器で収集された時系列の複数の情報に対して加工処理が行われた情報を含んでもよい。

このようにすれば、第２の情報の情報量を削減したり、稼働状態の把握に有用な情報を第２の情報とすることが可能になる。

また本発明の一態様では、前記収集対象機器は印刷装置であり、前記第２の情報は、部品交換の履歴情報、ノズルチェックの履歴情報、フラッシングの回数情報、インクの吐出回数情報、の少なくとも１つを含んでもよい。

このようにすれば、プリンターの長期的なメンテナンス等に有用な情報を収集することが可能になる。

また本発明の一態様では、前記第１の通信処理は、ＭＱＴＴ（Message Queue Telemetry Transport）に対応する通信処理であり、前記第２の通信処理は、ＨＴＴＰ（Hypertext Transfer Protocol）に対応する通信処理であってもよい。

このようにすれば、各通信処理を具体的な通信プロトコルを用いて実現することが可能になる。

また本発明の他の態様は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムであって、通信接続の確立後、前記通信接続の確立状態が維持される通信処理により、前記稼働情報を受信する通信部と、処理部と、記憶部と、を含み、前記処理部は、前記稼働情報のうちの第１の情報を前記記憶部に上書きし、前記稼働情報のうちの第２の情報を前記記憶部に追記書き込みし、前記通信部は、受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うサーバーシステムに関係する。

本発明の他の態様では、通信接続の確立状態が維持される通信処理により稼働情報を受信し、稼働情報が第１の情報か第２の情報かに応じて記憶部への書き込みを制御し、さらに受信した第１の情報が所定種別である場合に、端末装置に対してプッシュ通知を行う。このようにすれば、通信接続の確立状態が維持される通信処理により稼働情報を受信しつつ、所定の情報についてのプッシュ通知を迅速に行うこと等が可能になる。

また本発明の他の態様では、前記通信部は、前記第２の情報として、前記収集対象機器でバッファーされた前記稼働情報に基づく情報を受信してもよい。

このようにすれば、第２の情報の受信による通信負荷を軽減することが可能になる。

また本発明のさらに他の態様は、上記のいずれかに記載のサーバーシステムと、前記端末装置と、を含む稼働情報収集システムに関係する。

また本発明のさらに他の態様は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムの作動方法であって、前記稼働情報のうちの第１の情報については、通信接続の確立後、前記通信接続の確立状態が維持される第１の通信処理により受信し、前記稼働情報のうちの第２の情報については、通信接続の確立後、情報が受信されると前記通信接続が切断される第２の通信処理により受信し、前記第１の通信処理により受信した前記第１の情報、及び前記第２の通信処理により受信した前記第２の情報を記憶部に書き込み、受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うサーバーシステムの作動方法に関係する。

また本発明のさらに他の態様は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムの作動方法であって、通信接続の確立後、前記通信接続の確立状態が維持される通信処理により、前記稼働情報を受信し、前記稼働情報のうちの第１の情報を記憶部に上書きし、前記稼働情報のうちの第２の情報を前記記憶部に追記書き込みし、受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うサーバーシステムの作動方法に関係する。

稼働情報収集システムの構成例。 プリンターの構成例。 情報処理装置の構成例。 サーバーシステムの構成例。 端末装置の構成例。 プリンターで記憶される稼働情報のデータ構造例。 情報処理装置等で記憶される稼働情報のデータ構造例。 第１の情報の具体例。 プリンター側、サーバーシステム、端末装置間の通信態様の模式図。 第１の通信処理での通信態様の模式図。 第１の情報に関する通信シーケンスの説明図。 第２の情報に関する通信シーケンスの説明図。 報知設定に用いられる表示画面例。 プリンター側、サーバーシステム、端末装置間の通信態様の模式図。 複数のプリンターの情報を一覧表示する表示画面例。 詳細情報の表示画面例。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

また、以下では稼働情報の収集対象機器がプリンター（印刷装置）である例について説明するが、収集対象機器は他の機器（例えばプリンター以外の生産機器）に拡張可能である。

１．稼働情報収集システム
図１は、本発明にかかる稼働情報収集システムの一例を模式的に示す図である。稼働情報収集システム１は、プリンター３の稼働情報を、情報処理装置５を介して収集するサーバーシステム７と、端末装置９を含む。サーバーシステム７は、収集した稼働情報を端末装置９に対して送信する。なお端末装置９に送信される情報は、サーバーシステム７が収集した全ての稼働情報を対象にする必要はない。例えば、サーバーシステム７は稼働情報の一部を抽出した情報、或いは稼働情報に対して統計処理等の加工処理を行った情報を端末装置９に対して送信してもよい。端末装置９は、サーバーシステム７から受信した情報の表示部での表示、或いは鳴動等による報知を行う。

ただし、稼働情報収集システム１を含むシステムは図１の構成に限定されず、これらの一部の構成要素を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。例えば、図１から情報処理装置５を省略し、各プリンター３が直接ネットワークＮＥ２（インターネット）に接続されてもよい。

図１に示したように、複数のプリンター３及び情報処理装置５は、ネットワークＮＥ１に接続されており、ネットワークＮＥ１を介して双方向に通信可能である。また、情報処理装置５及びサーバーシステム７は、ネットワークＮＥ２に接続されており、ネットワークＮＥ２を介して双方向に通信可能である。また、端末装置９もネットワークＮＥ２に接続されており、サーバーシステム７と端末装置９は、ネットワークＮＥ２を介して双方向に通信可能である。

例えば、ネットワークＮＥ１はＬＡＮ（Local Area Network）であり、ネットワークＮＥ２はインターネットである。ただし、ＬＡＮやインターネットは通信回線の一例として示したものであり、プリンター３と情報処理装置５との間、情報処理装置５とサーバーシステム７との間、サーバーシステム７と端末装置９との間を接続する通信回線の具体的構成はこれらに限られない。

複数のプリンター３、ＬＡＮ、及び情報処理装置５で構成されるシステム１０は、各プリンター３の稼働情報を情報処理装置５により収集して、外部のサーバーシステム７へ送信する。この情報処理装置５は、例えば同一企業の施設内に構築される装置であり、ＰＣ（Personal Computer）であってもよいし、企業内のサーバーであってもよい。なお、図１では、１つのシステム１０が記載されているが、複数のシステム１０がサーバーシステム７に接続されてもよい。

プリンター３は、図２を用いて後述するように表示部３３３を含む。そのため、ユーザーがプリンター３の近くで作業をしていれば、表示部３３３に表示される稼働情報を閲覧することで、プリンターの状態を認識可能である。しかし、ユーザーがプリンター３から離れて作業することも考えられる。

例えば、従業員が少ない中小規模の企業（事業所）では、ユーザーがプリンター３の操作の他に、経理や営業、生産物の納品と行った業務を行う必要があり、プリンター３から離れる場面が発生する。そのためプリンター３の稼働状態を、ユーザーが操作する端末装置９を用いて確認できるシステムの構築が重要となる。具体的には、端末装置９が、サーバーシステム７が収集した稼働情報に基づく情報の受信、表示、報知等を行うことで、ユーザーはプリンター３の稼働状態の遠隔監視を行う。

また、比較的規模の大きい事業所であれば、各プリンター３（各生産ライン）に人員を配置することが可能である。しかし複数の生産ラインを統括する管理者は、全てのプリンター３の表示部３３３を常時確認することはできない。そのため、作業の全体的な進捗を適切に把握するためには、端末装置９での情報の表示等が重要となり、図１に示した稼働情報収集システム１は、この場合にも有用である。

なお、図１では１つの端末装置９を図示したが、端末装置９が複数であってもよい。例えば１つのシステム１０を利用する企業内の複数のユーザーが、それぞれ端末装置９を利用した情報の受信、閲覧を行ってもよい。また、サーバーシステム７に複数のシステム１０が接続される場合に、各システム１０について、それぞれ１又は複数個の端末装置９が用いられてもよい。

２．各装置の詳細な構成例
次に、プリンター３、情報処理装置５、サーバーシステム７、端末装置９の構成例についてそれぞれ説明する。

２．１ プリンター
図２は、プリンター３の構成の一例を示すブロック図である。プリンター３は、処理部３１、インターフェース部３３、印刷部３５及び記憶部３７を備える。処理部３１は、プリンター３で実行される動作を統括的に制御する。この処理部３１の機能は、ＣＰＵ（Central Processing Unit）等の各種プロセッサー、ＡＳＩＣ（Application Specific Integrated Circuit、ゲートアレイ等）などのハードウェアや、プログラムなどにより実現できる。インターフェース部３３、印刷部３５及び記憶部３７は、処理部３１の制御を受けて動作する。

インターフェース部３３は、通信部３３１、操作部３３２、及び表示部３３３を含む。通信部３３１はＬＡＮに接続され、ＬＡＮを介して情報処理装置５との通信を実行する。また、操作部３３２は、ユーザーからの入力操作を受け付けるボタン等で構成され、表示部３３３はプリンター３に関する各種情報をユーザーに表示するディスプレイ等で構成される。なお、操作部３３２及び表示部３３３は、例えばタッチパネルにより一体的に構成してもよい。

印刷部３５は、印刷エンジン３５１、センサー３５２、及びカウンター３５３を含む。印刷エンジン３５１は、印刷媒体への画像の印刷を実行する機械的構成である。この印刷エンジン３５１は、ロール・トゥ・ロールで搬送される巻取式の印刷媒体に対してインクジェット方式の吐出ヘッドからインクを吐出することで、印刷媒体に画像を印刷する。なお、印刷エンジン３５１の具体的構成はここで例示したものに限られず、印刷エンジン３５１は枚葉式の印刷媒体に印刷するものでも構わないし、レーザー方式でトナーにより印刷するものでも構わない。センサー３５２は、印刷エンジン３５１の稼働状態に関わる各種の物理量を検出し、カウンター３５３は、印刷エンジン３５１の稼働に伴って変化する各種の数値を計数する。

印刷エンジン３５１の稼働状態を示す物理量としては、例えば印刷エンジン３５１の電気部品に印加される電圧、印刷エンジン３５１内の温度及び湿度、吐出ヘッドや印刷媒体の位置等がある。これらの物理量を検出するために、電圧センサー、温湿度センサー、位置センサー、加速度センサー等の各種のセンサー３５２が設けられる。また、印刷エンジン３５１の稼働に伴って変化する数値としては、例えば印刷エンジン３５１の電源投入後の経過時間、印刷された印刷媒体の積算長、インクの消費量（あるいは残量）、回転する機械部品（例えば印刷媒体を搬送するローラー）の積算回転量等がある。そして、これらの数値を計数するために各種のカウンター３５３が設けられる。

記憶部３７は、ＨＤＤ（Hard Disk Drive）、ＲＯＭ（Read Only Memory）、或いはＲＡＭ（Random Access Memory）といった記憶媒体で構成される。記憶部３７は、プリンター３のステータス情報（エラーや警告等）、プリンター３で実行されるジョブの識別情報（ジョブ名）、ジョブの進捗を表す情報（印刷時間情報、進捗情報）、或いはセンサー３５２及びカウンター３５３から出力されるデータ等を、プリンター３の稼働状況を表す稼働情報として記憶する。

２．２ 情報処理装置
図３は、情報処理装置５の構成の一例を示すブロック図である。情報処理装置５は、処理部５１、インターフェース部５３及び記憶部５５を備え、複数のプリンター３それぞれの記憶部３７へアクセスして稼働情報を収集し、収集した稼働情報をサーバーシステム７に送信する情報仲介動作を実行する。処理部５１は、ＣＰＵ等のプロセッサーであり、インターフェース部５３及び記憶部５５を用いつつ情報仲介動作を実行する。

インターフェース部５３は、通信部５３１、操作部５３２、及び表示部５３３を含む。通信部５３１は、ＬＡＮ及びインターネットに接続され、ＬＡＮを介して各プリンター３との通信を実行するとともに、インターネットを介してサーバーシステム７との通信を実行する。また、操作部５３２は、ユーザーからの入力操作を受け付けるマウス及びキーボード等で構成され、表示部５３３は、各種情報をユーザーに表示するディスプレイ等で構成される。なお、操作部５３２及び表示部５３３は、例えばタッチパネルにより一体的に構成してもよい。

記憶部５５は、ＨＤＤ、ＲＯＭ或いはＲＡＭといった記憶媒体で構成され、通信部５３１がプリンター３から受信した稼働情報を記憶する。情報処理装置５は、複数のプリンター３からの稼働情報を取得することもあるため、記憶部５５は、プリンター３の識別情報（プリンターＩＤ）と、上記ステータス情報等の各情報を関連付けて記憶する。

２．３ サーバーシステム
図４は、サーバーシステム７の構成の一例を示すブロック図である。サーバーシステム７は、処理部７１（プロセッサー）、通信部７３１（通信インターフェース）、及び記憶部７５（記憶装置、メモリー）を備え、情報処理装置５が収集した稼働情報を受信するとともに、端末装置９に対して稼働情報を送信する。処理部７１の機能は、ＣＰＵ等の各種プロセッサー、ＡＳＩＣなどのハードウェアや、プログラムなどにより実現でき、処理部７１は通信部７３１及び記憶部７５を用いて所定の動作を実行する。

通信部７３１は、インターネットに接続され、インターネットを介して情報処理装置５、或いは端末装置９との通信を実行する。なお、サーバーシステム７は、不図示の操作部や表示部を含んでもよい。操作部は、ユーザーからの入力操作を受け付けるマウス及びキーボード等で構成され、表示部は、各種情報をユーザーに表示するディスプレイ等で構成される。ただし、サーバーシステム７が操作部や表示部を含まず、外部装置（管理用端末装置）を用いてサーバーシステム７の管理が行われてもよい。例えば、サーバーシステム７はＷｅｂサーバーとしての機能を有し、外部装置で動作するソフトウェア（Ｗｅｂブラウザー）を用いて操作が行われ、当該外部装置の表示部に種々の情報が表示される態様であってもよい。

記憶部７５は、ＨＤＤ、ＲＯＭ或いはＲＡＭといった記憶媒体で構成される。記憶部７５は、プリンター３からの稼働情報と、報知設定情報を記憶する。記憶部７５は、データベース（狭義にはリレーショナルデータベース）であってもよく、記憶部７５は、稼働情報テーブルと報知設定情報テーブルを記憶する。稼働情報テーブルは、稼働情報を記憶するテーブルである。報知設定情報テーブルは、端末装置９に対するサーバーシステムからの通知（プッシュ通知）を行う場合に利用されるテーブルである。ここでのプッシュ通知は、受信側からのリクエストが無くても、送信側から情報の送信が行われる通信形態を表す。サーバーシステム７から端末装置９へのプッシュ通知とは、サーバーシステム７が起点となって、端末装置９へ情報を送信することである。

なお、サーバーシステム７は、１台のサーバーで実現されるものに限定されない。例えばサーバーシステム７は、稼働情報テーブル等を記憶するデータベースサーバー（記憶部７５）と、端末装置９との情報の送受信を行うアプリケーションサーバー（処理部７１、通信部７３１の一部）を含んでもよい。或いは、サーバーシステム７は負荷分散用のサーバーや、端末装置９へのプッシュ通知用のサーバーを含んでもよい。さらに、データベースサーバーやアプリケーションサーバー等を複数台のサーバーの分散動作により実現してもよい。また、サーバーシステム７を構成する各サーバーは、仮想化されたサーバー（仮想サーバー）であってもよい。この場合、各仮想サーバーは、同一のサーバー（物理サーバー）上で動作してもよいし、異なる物理サーバー上で動作してもよい。また、サーバーシステム７は、通信負荷等をモニタリングすることで動的なスケーリング（例えば仮想サーバーの数の動的な変更）が行われてもよい。即ち、本実施形態のサーバーシステム７は、物理サーバーの数、サーバーを仮想化する場合の仮想サーバーの数、或いは仮想サーバーと物理サーバーとの対応関係等に関して、種々の変形実施が可能である。

２．４ 端末装置
図５は、端末装置９の構成の一例を示すブロック図である。端末装置９は、処理部９１（プロセッサー）、インターフェース部９３、及び記憶部９５（記憶装置、メモリー）を備え、サーバーシステム７が収集した稼働情報を受信する。処理部９１の機能は、ＣＰＵ等の各種プロセッサー、ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

インターフェース部９３は、通信部９３１（通信インターフェース）、操作部９３２、表示部９３３、及び報知部９３４を含む。通信部９３１は、インターネットに接続され、インターネットを介してサーバーシステム７との通信を実行する。操作部９３２は、ユーザーからの入力操作を受け付けるボタン等で構成され、表示部９３３は、各種情報をユーザーに表示するディスプレイ等で構成される。なお、操作部９３２及び表示部９３３は、例えばタッチパネルにより一体的に構成してもよい。報知部９３４は、ユーザーに対する報知を行う。報知部９３４は、例えば音による報知を行うスピーカーであってもよいし、振動による報知を行う振動部（振動モーター）であってもよいし、これらの組み合わせであってもよい。

記憶部９５は、ＨＤＤ、ＲＯＭ或いはＲＡＭといった記憶媒体で構成される。記憶部９５は、サーバーシステム７からの稼働情報の取得処理や表示処理等を行うソフトウェア（アプリケーション）を記憶してもよい。また記憶部９５は、サーバーシステム７から受信した稼働情報を記憶する。

３．プリンターと情報処理装置との間の通信
図６は、プリンター３の記憶部３７における稼働情報の記憶態様を模式的に示す図である。図６に示すように、記憶部３７では、稼働情報の種類とメモリーのアドレスとが対応付けられており、各稼働情報はその種類に対応するアドレスに格納される。具体例を挙げると、電源投入後経過時間の値を示す稼働情報ｖ１は、その種類に対応するアドレスａ１に格納される。ただし、記憶部３７は、稼働情報と、当該稼働情報の更新時刻（タイムスタンプ）を関連付けて記憶する等の変形実施が可能である。

プリンター３の処理部３１や、印刷部３５（センサー３５２、カウンター３５３）では、定期的に（狭義には常時）稼働状態を監視し、稼働状態が変化した場合に、記憶部３７の稼働情報が更新される。

情報処理装置５の処理部５１（通信部５３１）は、ポーリングを行い、ＬＡＮを介して接続される１又は複数のプリンター３から定期的に稼働情報を取得する。

図６に示したようにプリンター３の記憶部３７で、稼働情報の種類とアドレスとが対応付けられている場合であれば、処理部５１は、収集対象となる稼働情報に対応するアドレスにアクセスし、当該アドレスに格納された稼働情報を収集する。例えば、処理部５１は、前回収集した情報に対して変化があった情報を収集対象とする。或いは、処理部５１は、プリンター３の機種、ファームウェアバージョン等に基づいて、プリンター３ごとに収集対象となる稼働情報を決定する。

図７は、情報処理装置５の記憶部５５に記憶される稼働情報の記憶態様を模式的に示す図である。図７に示すように記憶部５５には、稼働情報が、プリンター３の識別情報（ＩＤ、シリアル番号）、及び取得時間情報と関連付けられて記録される。なお、図７では省略しているが、記憶部５５は、図６の例と同様に、情報の種類（「Ｙインク消費量」等）と、具体的な値（インク消費量であれば、吐出回数、体積、割合等）との組み合わせを、稼働情報として記憶する。

ただし、上述したように情報処理装置５は省略可能であり、プリンター３が直接サーバーシステム７との通信を行ってもよい。

４．サーバーシステムの通信制御
次にサーバーシステム７に関する稼働情報の通信手法を説明する。具体的には、第１の通信処理（ＭＱＴＴ）と第２の通信処理（ＨＴＴＰ）を併用して種々の稼働情報の通信を行う第１の実施形態、第１の通信処理（ＭＱＴＴ）により種々の稼働情報の通信を行う第２の実施形態、及び変形例について説明する。

４．１ 第１の実施形態
以下、第１の実施形態について説明する。まず稼働情報のうちの第１の情報と第２の情報について説明し、その後、具体的な通信経路や通信シーケンスについて説明する。さらに、サーバーシステム７から端末装置９へのプッシュ通知を行う場合の設定手法についても説明する。

４．１．１ 第１の情報
上述したように、収集対象機器（プリンター３）では、種々の稼働情報が収集される。稼働情報には、リアルタイム性が相対的に高い情報と低い情報が含まれる。ここで、リアルタイム性が高いとは、プリンター３での情報の取得から、当該情報がサーバーシステム７を経由して端末装置９においてユーザーに提示されるまでの時間を短くする必要性が高いことを表す。或いは、リアルタイム性が高いとは、プリンター３での情報の取得から、当該情報がサーバーシステム７で収集されるまでの時間を短くする必要性が高いことを表す。逆に、リアルタイム性が低い情報とは、プリンター３で情報が取得された後、サーバーシステム７への情報の送信や、サーバーシステム７を経由した端末装置９への情報の送信にある程度の時間を要しても問題が生じにくい情報を表す。

以下、リアルタイム性が相対的に高い稼働情報を第１の情報と表記し、リアルタイム性が相対的に低い稼働情報を第２の情報と表記する。

図８は、稼働情報のうちの第１の情報の具体例、及び各情報に対応するイベントの具体例である。第１の情報は、プリンター３（印刷装置）のエラー状態、警告状態、通常動作状態、アイドル状態の少なくとも１つの状態を含むステータスの変化情報を含む。

プリンター３が通常動作状態（印刷中）から、警告状態やエラー状態に移行した場合、ジョブ（印刷）の継続や再開のためには、ユーザーがプリンター３の所まで戻って何らかの作業を行う必要性が高い。警告状態とは、印刷を継続できないおそれがある状態（例えばインク残量低下等）であり、エラー状態とは、何らかの異常により印刷動作が停止した状態を表す。或いは、プリンター３でのジョブが終了し、通常動作状態（印刷中）からアイドル状態（待機中）に移行した場合、ユーザーがプリンター３の所まで戻って新規ジョブを投入することで、プリンター３を効率的に動作させることが可能になる。よって印刷中から待機中へのステータス変化も、リアルタイム性の高い情報である。

図８に示したように、ステータス情報は、「印刷中」「待機中」「警告」「エラー」のいずれかの値をとる。「印刷中」は上記通常動作状態に対応し、「待機中」はアイドル状態に対応し、「警告」は警告状態に対応し、「エラー」はエラー状態に対応する。

また第１の情報は、プリンター３のインク又はトナーに関する情報、印刷媒体に関する情報を含む。インク等は、プリンター３の動作に伴って残量が減少していく消費材である。ユーザーが関心を持っているのは、現時点でプリンター３にどれだけのインクが残っているか、即ち、印刷動作の継続に問題がないか、プリンター３に戻ってインクを補充する必要があるか、といった情報であると考えられる。よってインク等に関する情報は、プリンター３の実際のインク量等との乖離が十分小さい必要があり、リアルタイム性の高い情報である。

インク又はトナーに関する情報、印刷媒体に関する情報とは、具体的には図８に示したように、液体インクやトナーの残量、印刷媒体の残量である。インク残量は、例えばインクタンクの容量を１００％とした場合の残量の割合であり、単位は％である。印刷媒体の残量は、例えば枚数であってもよいし、ロール紙等を用いる場合は長さ（単位：ｍ）であってもよい。また図８では残量情報を用いる例を示したが、インク等の消費量情報を用いてもよい。

また第１の情報は、印刷完了までの残り時間情報、印刷完了時刻情報、印刷動作の進捗情報を含む。図８では、第１の情報が、残り時間情報である例を示している。残り時間情報は、印刷完了までの残り時間を表す情報であり、例えば残り時間の時分（「残り１時間４５分」等）を表す情報である。

印刷完了時刻情報は、例えば「１４：２５」等の時刻を表す情報である。また印刷完了時刻情報は、日付の情報を含むことも可能である。印刷動作の進捗情報は、印刷動作全体（例えば印刷対象である画像ファイル全体の印刷を完了するための動作）に対して、現時点でどれだけの印刷動作が完了しているかの進捗を表す情報である。進捗情報は、例えば印刷動作全体を１００％としたときの割合（「６０％」等）である。

残り時間情報（或いは印刷完了時刻情報）を用いることで、後何分で（或いは何時になったら）現在実行している印刷が終了するかをユーザーに容易に把握させることが可能である。また、進捗情報を用いることで、印刷動作の進捗度合いをユーザーに容易に把握させることが可能である。これらの情報は、プリンター３で把握している最新の情報と、ユーザーに提示する情報とに乖離があると、ユーザーの判断を誤らせるおそれがある。例えば、当面印刷が完了しないとユーザーが誤認することで、プリンター３のところに戻るべきタイミングで戻れなかったり、或いは印刷が早く完了すると誤認することで、印刷動作がしばらく完了しないタイミングでプリンター３のところに戻ってしまい時間を無駄にする、といったことが考えられる。よって残り時間情報等は、プリンター３で保持している情報との乖離が十分小さい必要があり、リアルタイム性の高い情報である。

なお、残り時間情報及び印刷完了時刻情報の一方の情報から他方の情報を演算可能である。また、現時点での印刷動作の実行時間と、残り時間との比率から、進捗情報を演算可能である。同様に、印刷完了時刻情報からも進捗情報を演算可能である。即ち、残り時間情報、印刷完了時刻情報及び進捗情報は、相互に変換可能な情報と言える。そのため、プリンター３からは上記３つの情報のうちの一部が送信され、情報処理装置５、サーバーシステム７、或いは端末装置９において変換処理が行われてもよい。例えば、プリンター３では残り時間情報及び進捗情報の取得、送信を行い、端末装置９はサーバーシステム７経由で受信した残り時間情報に基づいて、印刷完了時刻情報を演算、表示する。

また第１の情報は、ジョブ名の情報を含む。ジョブ名の情報は、例えば印刷対象となるファイル名（画像ファイル名等）である。また、ジョブ名については、実行中のジョブ名に限定されず、過去に実行した所定数のジョブのジョブ名（ジョブ履歴情報）に拡張することも可能である。ジョブ履歴情報の詳細については、変形例として後述する。

上述してきたように、第１の情報は、プリンター３での取得後、少なくとも後述する第２の情報よりも短い時間で（理想的には即座に）、サーバーシステム７に対して送信されるべき情報である。しかし、第１の情報の送信頻度を単純に高くすることは好ましくない。例えば、相対的に短い所定期間（例えば１分や数十秒）ごとに、定期的に通信部５３１（通信部３３１）がサーバーシステム７に対して第１の情報を送信する場合、通信回数が非常に多くなってしまい通信負荷が大きい。サーバーシステム７の通信部７３１側から、定期的にプリンター３又は情報処理装置５にアクセスする場合も同様である。

よって第１の情報は、収集対象機器での所与のイベント発生をトリガーとして送信処理が実行される（イベントドリブンで送信される）。上記図８は、第１の情報の各情報に対応するイベントを説明する図でもある。第１の情報の各情報に対して、当該情報を送信すべき状況を「イベント」として定義しておく。そして、当該イベントが発生した場合に、対応する第１の情報を送信することで、サーバーシステム７は適切なタイミングで第１の情報を収集することが可能になる。この場合、イベント発生の判定頻度が第１の情報の送信頻度の上限となる。そのため、イベント発生の判定頻度を第２の情報の送信頻度に比べて高くしておけば、イベントが頻発するような状況では、第１の情報を高頻度で（リアルタイムに）サーバーシステム７に送信することが可能になる。一方、イベントが発生しなければ第１の情報のサーバーシステム７への送信も必要とならない。よって、不要な通信を抑制できるため、通信負荷を軽減することが可能である。

図８に示したように、サーバーシステム７にステータス情報を送信するトリガーになるイベントとは、ステータス情報の値が変化するイベントである。なお、プリンター３、情報処理装置５、及びサーバーシステム７の各機器は、「警告」又は「エラー」への遷移と、「印刷中」又は「待機中」への遷移を別イベントとして分けて管理してもよい。前者はプリンター３の動作が停止した、或いは停止するおそれがあるという異常状態を表すイベントであるのに対して、後者は印刷開始や終了という正常動作における始点、終点を表すイベントである。

また、サーバーシステム７に残り時間情報を送信するトリガーになるイベントとは、残り時間情報が変化するイベントである。例えば、プリンター３や情報処理装置５は、印刷中にフラッシング動作が発生し、残り時間が増加した場合に、イベント発生と判定する。

また、サーバーシステム７に消耗材の残量情報を送信するトリガーになるイベントとは、残量が所定量（所定割合、所定枚数、所定長さ）だけ変化したイベントであってもよいし、残量が所与の閾値を下回ったイベントであってもよい。

また、サーバーシステム７にジョブ名を送信するトリガーになるイベントとは、新たなジョブの実行を表すイベントである。なお、新たなジョブの実行を表すイベントは、「待機中」から「印刷中」への遷移イベント（印刷開始イベント）と同様のイベントとして、プリンター３等で管理されてもよい。

なお、通信部５３１（通信部３３１）は、第１の情報の種別によっては、サーバーシステム７への情報送信の間引きを行ってもよい。具体的には、通信部５３１は、前回の情報送信後、所定期間（例えば数分）は新たなイベントが発生しても情報の送信を行わない。このようにすれば、情報処理装置５（プリンター３）とサーバーシステム７との間の通信負荷を軽減することが可能になる。例えば、サーバーシステム７の通信部７３１は、第１の情報の中でも特にリアルタイム性の高いステータス情報はイベント発生後、即座に受信し、他の情報については受信頻度に上限を設定する。

例えば、エラーや警告、印刷完了は即座にユーザーに提示することが望ましいため、間引きを行わない。また残り時間情報等についても、ユーザーが閲覧する情報と実際の情報（プリンター３で把握している情報）に乖離が生じることは好ましくないため、間引きを行わない。それに対して、インク等の消費材の情報については、数分程度の遅延が問題となりにくい。よって通信部５３１（通信部３３１）は、インク等の消費材の情報を対象に間引きを行って、通信負荷の軽減を図る。

なお、以上では稼働情報の収集対象機器がプリンター３である例を示したが、収集対象機器はプリンター３以外の機器に拡張可能である。この場合、第１の情報は、収集対象機器のステータスの変化情報、ジョブの開始／終了情報、消費材に関する情報、ジョブの時間情報、ジョブの進捗情報の少なくとも１つを含む情報に拡張できる。

４．１．２ 第２の情報
以上の第１の情報に対して、印刷部３５のローラーの回転量や、ヘッダーの往復回数、クリーニングの実行回数などのカウント結果は、プリンター３の長期的なメンテナンスには有用であるが、カウントアップが行われてから数分以内にユーザーに閲覧させる必要性は低い。よって、これらのリアルタイム性が相対的に低い稼働情報である第２の情報を対象とする場合、プリンター３や情報処理装置５は上記第１の情報と異なる処理を行う。

第２の情報は、収集対象機器の稼働状態についての履歴情報である。ここでの履歴情報は、収集対象機器で発生したイベントにタイムスタンプが対応づけられた情報である。即ち、第２の情報とは、プリンター３の稼働に伴って、時間とともに取得される種々の情報を含むものであり、狭義には稼働情報のうち、上記第１の情報を除く全ての情報が第２の情報である。

また、上記第１の情報は、リアルタイムでのユーザーへの報知を想定したものであり、過去の情報（例えば変化前のステータス情報）の重要性は低く、過去の履歴まで保持する必要性が低い。しかし、ステータスが時間とともにどのように変化していったか、という履歴は、プリンター３の長期的な（日、週、月単位、或いはそれ以上の単位での）稼働状態の分析には有用である。よって、第２の情報は、ステータス情報の履歴情報等、第１の情報として例示した情報の履歴情報を含む。

収集対象機器がプリンター３（印刷装置）である場合、第２の情報は、部品交換の履歴情報、ノズルチェックの履歴情報、フラッシングの回数情報、インクの吐出回数情報、の少なくとも１つを含む情報である。

部品交換の履歴情報とは、プリンター３の部品の交換履歴を表す情報である。プリンター３には、印刷動作の実行により消耗し、所定の周期で交換することが望ましい部品がある。例えば、印刷エンジン３５１のうち、印刷媒体の搬送に用いられる部品（ローラー）や、インクジェットプリンターにおけるインクヘッド移動用の部品（ベルト等）、或いはレーザープリンターにおけるインク定着用のユニット等が交換対象の部品である。これらの部品は、数万メートル分の印刷媒体に対する印刷が行われたら交換することが望ましい、といった寿命の目安（交換目安）が部品ごとに設定されている。

よって部品交換の履歴情報は、例えば「部品交換してから８０００メートルまで使用した」等の寿命カウントに関する情報である。また部品交換の履歴情報は、所与の部品を何回交換したかを表す部品の交換回数の情報を含む。なお、上述したように交換対象となる部品は種々考えられるため、部品交換の履歴情報として、寿命カウントや交換回数の情報と、部品の識別情報（部品ＩＤ）とが関連付けられた情報を用いる。また、ここでは定期交換の対象となる部品を例示したが、部品交換の履歴情報は、定期交換とは異なる部品交換、例えば故障による電気回路やセンサー類の交換の履歴情報を含んでもよい。

ノズルチェックの履歴情報とは、ノズルチェックの実行履歴を表す情報であり、ノズルチェックの開始日時及び終了日時の情報である。開始日時及び終了日時は、例えば年月日（YYYY-MM-DD）の情報である。ノズルチェックとは、ノズルが詰まることにより、印字されない部分（ノズル抜け）が発生しているか否かをチェックするプリンター３の動作であり、例えばチェックパターンを印刷する動作である。このようにすれば、ノズルの状態を長期的に監視することが可能になる。なお、ノズルチェックの履歴情報は、開始日時、終了日時に加えて、ノズル抜けのカウント結果（総ノズル抜け数）の情報を含むことも可能である。

フラッシングとは、プリンター３のヘッドを印刷領域外となる位置へ移動させ、当該位置で各ノズルから一定量のインクを吐出させる動作である。例えばヘッドが往復する時に、ノズル詰まり防止のため、端の方でインクを無駄打ちする動作が入ることがある。第２の情報は、フラッシングが行われた時刻情報を含む。ただし、フラッシングはある程度の頻度で実行されるため、何時何分にフラッシングがあったという情報を提示したとしても、情報が細かすぎてユーザーにとって有用でない。

そこで第２の情報は、収集対象機器で収集された時系列の複数の情報に対して、加工処理が行われた情報を含む。フラッシングの例であれば、１回１回のフラッシングのタイミングをそのまま用いるのではなく、所定の期間を対象として、当該期間内での総フラッシング回数を集計し、集計結果であるフラッシングの回数情報を第２の情報とする。

このようにすれば、膨大な情報をそのまま用いるのではなく、わかりやすい形式に加工した上で、ユーザーに提示することが可能になる。また、第２の情報の情報量の削減も可能である。なお、集計対象期間は例えば１つのジョブ（１つのファイルを対象とした印刷動作）の実行期間であるが、１日単位にする等の種々の変形実施が可能である。

また、プリンタードライバーからの印刷データは、ヘッドのインク吐出を制御する情報、或いはそれに近い形式の情報である。よってプリンター３は、稼働情報として、各色のインクごとの吐出（ドット）の情報を取得可能である。ただし、ドットの情報についても、どのタイミングでどの色のインクが吐出された、という情報は細かすぎてユーザーにとって有用でない。

よってプリンター３では、印刷データに基づいて、所定期間での吐出回数（何ドット打ったか）を集計し、集計結果であるインクの吐出回数情報を第２の情報とする。集計対象期間は、上記例と同様に、１つのジョブであってもよいし、１日単位等の他の期間であってもよい。

なお、インクの吐出回数情報は、インクの消費量情報（消費体積）に変換することが可能である。また、インク単価の情報を併用することで、インクコストに関する情報に変換可能である。よって第２の情報は、インクの消費体積やインクコストの情報を含む。

また、以上では加工処理として、所定期間での回数のカウント処理を行う例を示した。これは所定期間を対象として、フラッシング等の出現をカウントする統計処理と考えることができる。ただし加工処理は、平均、最大値、最小値、中央値、分散等を求める他の統計処理に拡張可能である。このようにすれば、時系列的に値が変化する稼働情報を対象とした場合に、長期的な変化の傾向等をわかりやすい形式でユーザーに提示することが可能になる。また、加工処理は統計処理に限定されず、例えば一部のデータを間引く処理や、所定数のデータから一部を抽出する処理等の種々の変形実施が可能である。

以上で説明した第２の情報は、第１の情報に比べてリアルタイム性が低く、イベントドリブンでサーバーシステム７に送信される必要性も低い。よって第２の情報は、所与のスケジュールで送信される。ここで、所与のスケジュールとは、例えば１日に数回〜十数回程度の頻度であらかじめ定められたタイミングで送信処理が行われることを表す。なお、第２の情報の送信間隔は等間隔であってもよいし、間隔が異なってもよい。例えば第２の情報は、プリンター３の稼働率が高い時間帯（例えば昼間）の方が、稼働率が低い時間帯（例えば深夜）に比べて高い頻度で送信されてもよい。

４．１．３ プリンター側とサーバーシステムとの間の通信
図９は、プリンター３側（プリンター３又は情報処理装置５）、サーバーシステム７、及び端末装置９の通信態様を模式的に示す図である。図４で上述したように、本実施形態のサーバーシステム７は、少なくとも１つの収集対象機器（プリンター３）の稼働情報を、ネットワークを介して収集するサーバーシステムであって、通信部７３１と、通信部７３１の通信制御を行う処理部７１と、記憶部７５を含む。

図９に示したように、通信部７３１は、通信接続の確立後、通信接続の確立状態が維持される第１の通信処理と、通信接続の確立後、情報が受信されると通信接続が切断される第２の通信処理と、を行う。図９では、第１の通信処理は、ＭＱＴＴ（Message Queue Telemetry Transport）に対応する通信処理であり、第２の通信処理は、ＨＴＴＰ（Hypertext Transfer Protocol）に対応する通信処理である例を示しているが、ＭＱＴＴは通信接続の確立状態を維持する他の通信処理に拡張可能であるし、ＨＴＴＰは通信接続の確立後、情報が受信されると通信接続が切断される他の通信処理に拡張可能である。また、通信部７３１（及び通信部５３１及び通信部９３１）は、ＳＳＬ（Secure Sockets Layer）等を用いたセキュアな接続により、第１の通信処理及び第２の通信処理を実現してもよい。

そして通信部７３１は、稼働情報のうちの第１の情報については、図９のＡ１に示したように第１の通信処理により受信し、稼働情報のうちの第２の情報については、Ａ２に示したように第２の通信処理により受信する。

第２の通信処理は、上述したようにＨＴＴＰを利用可能である。ＨＴＴＰは多様な機器で利用可能であり、非常に可用性が高い通信処理を実現可能という利点がある。ただし、ＨＴＴＰは通信対象となる機器が多くなると、負荷が非常に大きくなってしまう。例えばＨＴＴＰでは、１つの機器との接続に対して１つのプロセスを割り当てる方式により実装される場合がある。１つのプロセスは所定サイズの記憶領域を専有するため、ＨＴＴＰで多数の機器との接続を行う場合、膨大なサイズの記憶領域を確保しなければならず、実現が困難になる。また、１つのプロセスを複数の機器との通信で共有する手法も考えられるが、この場合、プロセス内の所与の通信でエラーが発生すると、同一プロセス内のエラーが発生していない通信まで停止してしまう。

このように、ＨＴＴＰは多数の機器と同時に接続する可能性がある状況では通信負荷が大きくなってしまう。例えば本実施形態のサーバーシステム７では、多数のプリンター３の稼働情報を収集する可能性があり、且つ、上記第１の情報はイベントドリブンで送信される。そのため、状況によってはサーバーシステム７は、多数のプリンター３と同時に接続される可能性があり、第１の情報の通信に第２の通信処理（ＨＴＴＰ）を用いることは望ましくない。

その点、ＭＱＴＴはＩｏＴ（Internet of Things）への適用も想定される通信処理であり、多数の機器との同時接続に適している。ＭＱＴＴでは、データ形式が軽量且つシンプルであり、数万ノードといった膨大な通信を行うことも可能である。また、ＭＱＴＴでは中継サーバーを用いることで、さらなる通信負荷軽減が可能である。

図１０は、ＭＱＴＴのネットワークを説明する図である。図１０の例では、ＭＱＴＴサーバー８１には、複数の中継サーバー８２が接続され、各中継サーバー８２にノード（本実施形態であればプリンター３）が接続される。中継サーバー８２もＭＱＴＴサーバー（ブローカー）である。

図１０の例では、ＭＱＴＴサーバー８１は、複数の中継サーバー８２との接続を管理し、中継サーバー８２は、自身に接続される複数のノード（プリンター３）との接続を管理する。中継サーバー８２が１０台であり、且つ、各中継サーバー８２に１万個のノードが接続される場合、図１０のＭＱＴＴサーバー８１は１０万個のノードから稼働情報を収集できる。そして図１０のＭＱＴＴサーバー８１は、中継サーバー８２との１０個の通信を管理すればよく、全てのノードが直接接続される場合に比べて通信負荷を軽減できる。

なお、本実施形態のサーバーシステム７は、図１０のＭＱＴＴサーバー８１のみを含み、中継サーバー８２は外部のＭＱＴＴサービス提供者の保有するサーバーである。或いは、本実施形態のサーバーシステム７は、図１０のＭＱＴＴサーバー８１及び中継サーバー８２を含んでもよい。

このように第１の情報の通信に第１の通信処理（ＭＱＴＴ）を用いることで、サーバーシステム７は、通信負荷を軽減しつつ、リアルタイム性の高い情報を、高い頻度で受信することが可能になる。一方、第２の情報は、上述したように所定のスケジュールで行われるものであり、通信頻度が低い。第２の情報の通信では、多数の接続が同時に行われないような通信制御も容易であるため、通信部７３１は、第２の情報の通信には第２の通信処理（ＨＴＴＰ）を用いる。このように、本実施形態のサーバーシステム７は、稼働情報の特性に応じて、複数の通信処理を適切に使い分けることが可能である。

またサーバーシステム７の処理部７１は、第１の通信処理により受信した第１の情報、及び第２の通信処理により受信した第２の情報を記憶部７５に書き込む。記憶部７５は、例えばデータベース（データベースサーバー）である。

この際、処理部７１は、第１の通信処理により受信した第１の情報を記憶部７５に上書きし、第２の通信処理により受信した第２の情報を記憶部７５に追記書き込みする。

上述してきたように、第１の情報はプリンター３の稼働状態をリアルタイムにユーザーに提示することを想定した情報である。よって、より新しい情報が取得された場合、古い情報の有用性は低くなる。例えば、ステータス情報が「印刷中」から「待機中」に変化した場合、現在「待機中」である旨をユーザーに報知することが重要であり、過去に「印刷中」であったことをわざわざ報知しなくてもよい。よって処理部７１は第１の情報を記憶部７５に上書きする。このようにすれば、第１の情報を記憶するための記憶領域を抑制でき、効率的に第１の情報を記憶できる。

なお、サーバーシステム７の記憶部７５は、収集対象機器（プリンター３）ごと、及び情報種別ごとに、第１の情報を記憶する。図８の例であれば、第１のプリンターについてステータス情報、残り時間情報、消耗材の情報、ジョブ名の情報を記憶し、第２のプリンターについてステータス情報、残り時間情報、消耗材の情報、ジョブ名の情報を記憶する。３つ以上のプリンター３を対象とする場合も同様である。ここでの「上書き」とは、所与のプリンターの所与の種別の第１の情報が記憶部７５に記憶されている状態において、同じプリンターの同じ種別の第１の情報が通信部７３１で受信された場合に、記憶部７５に記憶されていた情報を、新たに受信した情報に置き換える（更新する）処理を表す。それまでに記憶されていないプリンター及び種別の第１の情報が受信された場合、上書きされる情報がないため、処理部７１は、受信した情報を単純に記憶部７５に書き込むことになる。なお、インク残量の情報は色ごとに記憶され、色ごとに上書き処理が行われることが想定されるが、複数色のインク残量を１つの情報として記憶し、当該複数色のインク残量の情報を処理単位として上書き処理が行われてもよい。このように、第１の情報をどのように記憶部７５に記憶するか、及び上書き処理をどのように実行するかは種々の変形実施が可能である。

一方、第２の情報は履歴情報であり、長期的な稼働情報をユーザーに提示したり、プリンター３のメンテナンスに利用することを想定した情報である。第２の情報は、新しい情報が取得されたとしても削除するべきではない。よって処理部７１は第２の情報を記憶部７５に追記書き込みする。

なお、処理部７１は、取得した情報が第１の通信処理で取得されたか、第２の通信処理はで取得されたかに応じて、記憶部７５への書き込み処理を切り替える。上記の例であれば、ＭＱＴＴ経由の情報は上書きされ、ＨＴＴＰ経由の情報は追記される。記憶部７５は、上書き用の領域と追記用の領域とが分かれていてもよいし、領域は１つで書き込み処理の内容（フィールドの設定）が異なっていてもよい。

また、サーバーシステム７と端末装置９との間の通信も複数の経路が考えられる。図９のＢ１に示したように、サーバーシステム７の通信部７３１は、端末装置９に対するプッシュ通知を行い、端末装置９は、通信部９３１によるプッシュ通知の受信、及び報知部９３４による報知（鳴動）を行う。言い換えれば、プッシュ通知は、サーバーシステム７側が主体となって稼働情報を送信する通信処理である。

図９のＢ２に示したように、端末装置９の通信部９３１は、サーバーシステム７（Ｗｅｂアプリケーションサーバー）に対してリクエストを送信し、サーバーシステム７は当該リクエストに対するレスポンスとして、稼働情報を返信する。この通信は、例えば第２の通信処理（ＨＴＴＰ）により行われ、端末装置９でのアプリケーションソフトウェア（いわゆるスマホアプリ）の起動時、或いはユーザーによる更新操作時に実行される。言い換えれば、Ｂ２に示したリクエスト／レスポンスによる通信は、端末装置９側（ユーザー側）が主体となって稼働情報を取得する通信処理である。なお、図９ではＡ２とＢ２はともにＨＴＴＰを用いた通信であるため、サーバーシステム７の通信部７３１は、Ａ２とＢ２を明確に区別せずに、共通の通信処理として実行することも可能である。

上述したように、第２の通信処理（ＨＴＴＰ）は可用性の非常に高い通信処理であるため、端末装置９の機種やＯＳ（Operating System）によらず利用できる蓋然性が高い。よって、Ｂ２に示した通信を行うことで、サーバーシステム７で収集された稼働情報を、端末装置９で適切に受信、表示することが可能になる。サーバーシステム７には、図９のＡ１に示したように、リアルタイム性の高い情報が高い頻度で収集されているため、Ｂ２の通信を行った場合、端末装置９は、プリンター３の現在の稼働状態との乖離が十分に小さい情報を取得できる。

ただし、上述したようにＢ２の通信は端末装置９側が起点となることが想定される。そのため、Ｂ２の通信のみでは、サーバーシステム７に第１の情報が収集されてから、当該第１の情報が端末装置９に送信されるまでにタイムラグが生じるおそれがある。例えば、エラーの発生イベント（ステータス情報の「エラー」への変化）が検出された場合、プリンター３の印刷動作を再開させるためには、ユーザーにエラー発生をいち早く報知し、対応を促すことが望ましい。しかし、端末装置９からのリクエストを待っていたのでは、サーバーシステム７が把握しているエラーを迅速にユーザーに報知することが難しい。

そこでサーバーシステム７の通信部７３１は、受信した第１の情報が所与の種別である場合に、端末装置９に対してプッシュ通知（図９のＢ１）を行う。プッシュ通知は、サーバーシステム７側が起点となるため、端末装置９からのリクエストの有無によらず、迅速に端末装置９に情報を送信することが可能になる。

ただし、ユーザーにとって必要性の低い情報までプッシュ通知の対象としてしまうと、ユーザーに煩わしさを感じさせてしまい好ましくない。よってここでは、第１の情報のうちの所与の種別の情報に限定してプッシュ通知を行う。

プッシュ通知が行われる情報は、第１の情報の中でも特にリアルタイム性の高い情報である。具体的には、上述した情報のうち、ステータス情報の変化が、プッシュ通知により端末装置９に対して送信される。プッシュ通知ではステータス情報の変化があったことを表す情報（例えば「エラー発生」等）のみを送信し、具体的なステータス情報は、Ｂ２に示した通信で送信される。或いは、プッシュ通知により、変化後のステータス情報そのものを送信してもよい。即ち、通信部７３１は、記憶部７５に記憶された所与の種別の第１の情報そのもの、又は、所与の種別の第１の情報に関する情報（イベント発生を表す情報）をプッシュ通知する。

図１１、図１２は、本実施形態の通信シーケンスを説明する図である。図１１及び図１２における「プリンター側」とは、プリンター３であってもよいし情報処理装置５であってもよい。また、本実施形態のサーバーシステム７等は、図１１、図１２では不図示の他の処理を行うことが可能である。

図１１は、第１の情報の通信シーケンスを説明する図である。プリンター３の稼働に伴い、プリンター側では稼働情報が取得される。そして、プリンター側で第１の情報に関連するイベントの発生が検出された場合（Ｓ１０１）、当該イベントをトリガーとして、サーバーシステム７に対して、第１の通信処理（ＭＱＴＴ）により第１の情報が送信される（Ｓ１０２）。

サーバーシステム７は、第１の通信処理により情報を受信したため、受信した情報を記憶部７５（データベース）の所定領域に上書きする（Ｓ１０３）。さらにサーバーシステム７は、受信した第１の情報の種別を判定し、所定種別であると判定された場合に、端末装置９に対するプッシュ通知を行う（Ｓ１０４）。第１の情報が所定種別でない場合は、Ｓ１０４の処理は実行されない。なお、Ｓ１０３とＳ１０４は図１１に示した順序で行われるものに限定されず、Ｓ１０４が先に実行されてもよいし、並列に処理が実行されてもよい。端末装置９は、プッシュ通知に対応する報知を行う（Ｓ１０５）。端末装置９での報知は、表示部９３３での表示、スピーカーによる音の発生、或いは振動モーターによる振動の発生等により実現される。

また、端末装置９は、サーバーシステム７に対して第２の通信処理によりリクエストを送信し（Ｓ１０６）、サーバーシステム７は当該リクエストに対して、第２の通信処理によりレスポンスを返す（Ｓ１０７）。例えば、Ｓ１０５の報知（鳴動）に対して、ユーザーが端末装置９のアプリケーションソフトウェアを起動することにより、Ｓ１０６の処理が実行される。ただし、Ｓ１０６及びＳ１０７の処理はプッシュ通知をトリガーとするものに限定されず、アプリケーションソフトウェアの動作に基づいて任意のタイミングで実行可能である。

図１２は、第２の情報の通信シーケンスを説明する図である。プリンター３の稼働に伴い、プリンター側で稼働情報が取得される点は図１１と同様である。プリンター側では、あらかじめ設定されたスケジュールに基づいて情報の送信を行う。具体的には、プリンター側で、現時点が定期送信のタイミングであると判定された場合に（Ｓ２０１）、サーバーシステム７に対して、第２の通信処理（ＨＴＴＰ）により第２の情報が送信される（Ｓ２０２）。

サーバーシステム７は、第２の通信処理により情報を受信したため、受信した情報を記憶部７５（データベース）に追記する（Ｓ２０３）。第２の情報の受信時には、図１１のＳ１０４に示したプッシュ通知は実行されない。

また、第２の情報は、プリンター３の保守、管理に使用されるものであって、端末装置９への送信は想定されない。ただし、図１２に示したように、端末装置９からのリクエスト（Ｓ２０４）に基づいて、サーバーシステム７からのレスポンスとして第２の情報を返信（Ｓ２０５）することは妨げられない。Ｓ２０４及びＳ２０５の処理が任意のタイミングで実行可能である点は、図１１と同様である。

４．１．４ 報知設定
図１１のＳ１０５に示したように、サーバーシステム７からのプッシュ通知を受信した場合、端末装置９では鳴動等の報知制御が行われる。ただし、鳴動による報知はユーザーの注意を引きつけるものであるため、不要な状況で報知を行うことは好ましくない。

例えば、所与の企業が多数のプリンター３を保有している場合、セキュリティー上の観点からは、当該企業の保有するプリンター３に関するプッシュ通知を、当該企業の従業員の端末装置９に送信することには問題がない。しかし所与のユーザーは、企業の保有するプリンター３のうちの数台を担当し、他のプリンター３については担当外であることが考えられる。この場合、当該所与のユーザーの端末装置９に対して、担当外のプリンター３のエラー発生をプッシュ通知することは有用でなく、ユーザーにとっては煩わしく感じられる。

また、交代制の勤務が行われる場合、月曜日から金曜日までは、所与のプリンター３の担当者がユーザーＡであるが、土曜日及び日曜日はユーザーＡが休養日であるため、当該所与のプリンター３の担当者がユーザーＢになる、ということが考えられる。当該プリンター３でのエラーが土曜日又は日曜日に発生した場合、プッシュ通知を優先的に行うべきはユーザーＢの端末装置９であって、ユーザーＡの端末装置９に対するプッシュ通知の優先度は高くない。むしろ、休養日にプッシュ通知が行われることで、ユーザーＡが煩わしさを感じてしまうおそれがある。

よって、サーバーシステム７は、所定種別の第１の情報を受信した場合に、必ず端末装置９に対してプッシュ通知を行うのではなく、所与の報知設定に基づいてプッシュ通知を行う。報知設定とは、報知時間帯の設定、及び、稼働情報の収集対象である少なくとも１つのプリンターのうちの、いずれを報知対象とするかの設定、の少なくとも一方の設定である。ここでの報知時間帯は、１週間の中での時間帯である曜日を決定する情報、及び、１日の中での時間帯（例えば０：００〜２３：５９までの２４時間のうちの一部の時間帯）を決定する情報の少なくとも一方を含む。

或いは報知設定は、プリンター３でのイベント種別の設定を含む。例えば、エラーの発生（「エラー」へのステータス変化）、警告の発生（「警告」へのステータス変化）、印刷終了（「待機中」へのステータス変化）のいずれかのイベントをトリガーとしたプッシュ通知が可能な例において、報知設定として、各イベントについて報知を行うか否かが設定される。

このようにすれば、サーバーシステム７から端末装置９へのプッシュ通知が、所定のプリンター３、所定の報知時間帯、所定のイベント種別に限定して行われる。ただし、以上の例からわかるように、各端末装置９での適切な報知設定は、当該端末装置９を利用するユーザーに応じて異なるものであり、サーバーシステム７側で自動的に設定を行うことは容易でない。

そこで通信部７３１は、端末装置９から報知設定情報（通知設定情報）を受信し、受信した報知設定情報に基づきプッシュ通知を行う。ここでの報知設定情報とは、上記報知設定を行うための情報であり、プッシュ通知を許可する時間帯、プリンター３、イベント種別を特定する情報である。このようにすれば、端末装置９側に、適切な報知設定を行わせることが可能になる。なお、ここではサーバーシステム７からのプッシュ通知を受信した場合、端末装置９では必ず報知部７３４による報知が行われることを想定している。そのため、報知を行うか否かを設定するための情報である報知設定情報とは、サーバーシステム７からプッシュ通知を行うか否かを設定するための情報である通知設定情報と言い換えることが可能である。また、サーバーシステム７からのプッシュ通知を受信した場合に、端末装置９側で報知を行うか否かを判定してもよい。この場合、通知設定情報と報知設定情報は一致しない可能性があり、サーバーシステム７の通信部７３１は通知設定情報を受信する。

図１３は、報知設定情報として、端末装置９で報知対象となるプリンター３を特定する情報の入力を受け付ける表示画面例である。図１３に示したように、端末装置９の処理部９１は、端末装置９での報知対象の候補となるプリンター３の情報（シリアル、名称等）とチェックボックスとを、候補となるプリンター数だけ並べて表示する処理を行う。ユーザーは、報知対象として設定したいプリンター３のチェックボックスにチェックを入れて、ＯＫボタンを押下する。

上記操作に基づいて、サーバーシステム７の通信部７３１は、報知候補プリンターのうち、端末装置９において報知対象として選択されたプリンター３を特定する情報を、報知設定情報として端末装置９（通信部９３１）から受信する。なお、通信部７３１は、第２の通信処理により、報知設定を端末装置９から受信する。例えば、端末装置９の通信部９３１は、図９のＢ２に示した通信経路において、ＨＴＴＰのＰＵＴメソッド等を用いて報知設定情報の送信を行う。

４．２ 第２の実施形態
第１の実施形態では、プリンター３側からの稼働情報の収集に、第１の通信処理と第２の通信処理の２つを用いる例について説明した。ただし、近年のＩｏＴの発達を鑑みるに、プリンター３等の各機器が直接ネットワークに接続され、自身の情報を送信することも多くなると考えられる。この場合、各機器とサーバーシステム７との通信処理は、上述した第１の通信処理（ＭＱＴＴ）により行われる。

本実施形態のサーバーシステム７は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムであって、通信接続の確立後、通信接続の確立状態が維持される通信処理により、稼働情報を受信する通信部７３１と、処理部７１と、記憶部７５を含むサーバーシステムに適用できる。処理部７１は、稼働情報のうちの第１の情報を記憶部７５に上書きし、稼働情報のうちの第２の情報を記憶部７５に追記書き込みし、通信部７３１は、受信した第１の情報が所与の種別である場合に、端末装置９に対してプッシュ通知を行う。

図１４は、第２の実施形態のプリンター３側（プリンター３又は情報処理装置５）、サーバーシステム７、及び端末装置９の通信態様を模式的に示す図である。図９と比較した場合、第１の情報及び第２の情報が、ともに第１の通信処理（ＭＱＴＴ）によりサーバーシステム７に対して送信される点が異なる。また、サーバーシステム７では、第１の情報を記憶部７５に上書きし、第２の情報を記憶部７５に追記するが、本実施形態では、通信処理の内容で情報を識別できないため、処理部７１は受信した情報が第１の情報か第２の情報かを判定し、判定結果に応じて記憶部７５への書き込み処理を変更する。

本実施形態の手法によれば、稼働情報を第１の通信処理（ＭＱＴＴ）により収集でき、膨大な数の収集対象機器（プリンター３）が直接ネットワークに接続されるような環境に好適なサーバーシステム７を実現できる。

ただし、第１の通信処理では、情報を高い頻度で、且つ細かい単位で送信することが想定される。そのため、上述した例であれば、１回のフラッシングや、１回（或いは非常に少ない回数）のインクの吐出が、稼働情報としてサーバーシステム７に送信されてしまう。このような細かい情報は、プリンター３の稼働状態の把握やユーザーへの提示に有用でないため、サーバーシステム７で上述した加工処理（統計処理）を実行する必要が生じる。即ち、第２の情報を単純に第１の通信処理により受信する場合、サーバーシステム７の通信負荷が大きく、且つ、加工処理に関する負荷も増える。

よって通信部７３１は、第２の情報として、収集対象機器でバッファーされた稼働情報に基づく情報を受信する。例えば、図１４に示したように、第１の情報がイベントドリブンで送信され、第２の情報がスケジュールに従って定期送信される。

ここで、収集対象機器でバッファーされた稼働情報に基づく情報とは、例えば単純に複数の稼働情報を蓄積した情報である。このようにすれば、複数の稼働情報（例えば複数回分のフラッシングの情報）をまとめて受信できるため、通信回数が抑制され、通信部７３１の負荷を軽減できる。或いは、収集対象機器でバッファーされた稼働情報に基づく情報とは、複数の稼働情報を圧縮した情報である。このようにすれば、通信回数の削減だけでなくデータ量も削減できるため、通信部７３１の負荷をより軽減できる。或いは、収集対象機器でバッファーされた稼働情報に基づく情報とは、時系列の稼働情報に対して加工処理が施された情報（例えばサマリー情報）であってもよい。このようにすれば、サーバーシステム７は第１の実施形態と同様の形式の第２の情報を受信でき、さらなる負荷の軽減が可能である。

５．変形例
以下、いくつかの変形例について説明する。

以上ではプリンター３、サーバーシステム７、端末装置９等の間の通信手法について説明したが、端末装置９が、受信した情報（特に図９のＢ２に示した経路により受信した第１の情報）をどのように表示するかは任意である。

図１５は、端末装置９の表示部９３３に表示される表示画面の例である。端末装置９の通信部９３１は、複数のプリンター３の印刷時間情報等を、ネットワークを介して受信し、処理部９１は、複数のプリンター３の印刷時間情報等が、一画面内に配置された表示画面を、表示部９３３に表示する処理を行う。

図１５の例では、表示部９３３は、３つのプリンターについての情報を表示する。例えば、Ｃ１に示した領域にはプリンター３の名称である「Printer-0001」（Ｃ１１）とともに、稼働情報としてステータス情報（Ｃ１２）、ジョブの進捗情報（Ｃ１３）、ジョブ名（Ｃ１４）、印刷完了時刻情報（Ｃ１５）が表示されている。具体的には、「Printer-0001」という名称のプリンターは、現在「印刷中」というステータスであり、「Sample_image.pdf」というジョブ名のジョブを実行している。ここでは、ジョブ名は印刷対象としているファイル名である。そして当該ジョブ全体を１００％としたときに、進捗は「１％」であり、印刷完了時刻が「１４：２０」である。

また表示部９３３は、Ｃ２に示した領域において、「Printer-0002」という名称のプリンターが、現在「印刷中」というステータスであり、「Sample_image_Xmas.pdf」というジョブ名（印刷対象ファイル名）のジョブを実行しており、当該ジョブの進捗は「６０％」であり、印刷完了時刻が「１３：２０」であることを表示している。

また表示部９３３は、Ｃ３に示した領域において、「Printer-0003」という名称のプリンターが、現在「待機中」（アイドル状態）というステータスであることを表示している。Printer-0003はアイドル状態であるため、ジョブ名、進捗情報、印刷完了時刻情報については表示されていない。

図１５の表示画面を用いることで、複数のプリンター３の稼働状態を一覧性の高い態様でユーザーに提示することが可能になる。特に、印刷完了時刻情報が表示されるため、複数のプリンター３が表示対象となる場合にも、印刷完了時刻の把握が容易である。例えば、図１５の表示画面では、最も早い印刷完了時刻の把握が容易であるため、その時刻にはプリンター３のところまで戻って次のジョブを投入する準備をしなくてはならない、といった判断をユーザーに実行させることが可能である。

なお、図１５の表示画面は、複数のプリンター３の情報を一覧性の高い態様で表示可能であるが、１つのプリンター３についての情報量が制限される。例えば、図１５では、第１の情報のうち、インク残量の情報が表示対象とならない。よって処理部９１は、印刷時間情報が表示されている複数のプリンター３のうち、いずれかのプリンターが選択されたときに、選択操作が行われたプリンターの表示領域を拡大し、詳細情報を表示する処理を行う。

図１６は、詳細情報を表示する表示画面の例である。図１６は、例えば図１５の表示が行われている状態において、ユーザーが「Printer-0001」を選択する操作を行った場合の表示画面に対応する。処理部９１は、図１５のＣ１１〜Ｃ１５に対応する情報の表示（Ｈ１１〜Ｈ１５）に加えて、インク及びメディア（紙や布等）の残量情報（Ｈ１６）、ジョブ履歴情報（Ｈ１７）を表示している。なお、Ｈ１５では印刷時間情報として印刷完了までの残り時間情報を表示しているが、図１５のＣ１５と同様に、印刷完了時刻情報を用いてもよい。

このようにすれば、一覧性の高い表示（図１５）と詳細表示（図１６）を適宜切り替えることで、ユーザーに対して適切な情報を提示することが可能になる。なお、詳細情報として表示する情報は図１６に限定されず、種々の変形実施が可能である。また、図１６では図１５とは別画面として詳細情報を表示する（「Printer-0002」や「Printer-0003」は非表示になる）例を示したが、異なる変形実施も可能である。例えば、図１５のように複数のプリンター３の情報を並べて表示する画面に詳細情報を追加することも可能である。具体的には、「Printer-0001」が選択された場合に、図１５のＣ１とＣ２の間にＨ１６やＨ１７に相当する表示が挿入されてもよい。この場合、詳細情報の表示中にも、スクロール操作を行うことで、「Printer-0002」等の他のプリンターの情報を閲覧することが可能である。

また、図１６に示したように、端末装置９ではジョブ履歴情報を表示する場合がある。ただし本実施形態では第１の情報は上書きされるため、仮に最新のジョブ名だけを記憶していたのでは、第１の情報に基づいてジョブ履歴情報を表示することはできない。第２の情報には、過去に実行したジョブ名が含まれるため、第２の情報に基づいて、ジョブ履歴情報を表示することは可能である。ただし、第２の情報は所与のスケジュールに従って定期送信されるため、端末装置９からのリクエストがあった時点でサーバーシステム７が保持している第２の情報が古い情報である可能性もある。

例えば、プリンター３が、第２の情報の定期送信後、且つ次の定期送信前の期間において、複数のジョブを完了している場合を考える。この場合、サーバーシステム７は、当該複数のジョブの情報を第２の情報として受信していないため、第２の情報を参照しても当該複数のジョブに関する情報を端末装置９に提供できない。またサーバーシステム７は、当該複数のジョブの情報を第１の情報として受信してはいるが、上記のように最新のジョブ名だけを記憶していたのでは、最新以外のジョブ名の情報は記憶部７５から失われている。

以上の点を鑑み、サーバーシステム７は、複数のジョブ名の情報を、第１の情報として保持する。例えば、記憶部７５は、ジョブ名の情報をリングバッファーにより記憶する。リングバッファーは、例えば５０個のジョブ名を記憶するバッファーであり、新たなジョブ名の情報を受信した場合に、任意の１つ（狭義には最も古い１つ）を当該新たなジョブ名により上書きする。このようにすれば、複数のジョブ名を第１の情報として保持できるため、ジョブ履歴情報を適切に表示することが可能になる。

また、本実施形態の手法は、図１に示したように、上記のサーバーシステム７と、端末装置９と、を含む稼働情報収集システム１に適用できる。

また、本実施形態のサーバーシステム７や端末装置９等は、その処理の一部または大部分をプログラムにより実現してもよい。この場合には、ＣＰＵ等のプロセッサーがプログラムを実行することで、本実施形態のサーバーシステム７や端末装置９等が実現される。具体的には、非一時的な情報記憶媒体に記憶されたプログラムが読み出され、読み出されたプログラムをＣＰＵ等のプロセッサーが実行する。ここで、情報記憶媒体（コンピューターにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＤＶＤ、ＣＤ等）、ＨＤＤ（ハードディスクドライブ）、或いはメモリー（カード型メモリー、ＲＯＭ等）などにより実現できる。そして、ＣＰＵ等のプロセッサーは、情報記憶媒体に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち、情報記憶媒体には、本実施形態の各部としてコンピューター（操作部、処理部、記憶部、出力部を備える装置）を機能させるためのプログラム（各部の処理をコンピューターに実行させるためのプログラム）が記憶される。

また、本実施形態のサーバーシステム７や端末装置９等は、プロセッサーとメモリーを含んでもよい。ここでのプロセッサーは、例えば各部の機能が個別のハードウェアで実現されてもよいし、或いは各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサーはハードウェアを含み、そのハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、プロセッサーは、回路基板に実装された１又は複数の回路装置（例えばＩＣ等）や、１又は複数の回路素子（例えば抵抗、キャパシター等）で構成することができる。プロセッサーは、例えばＣＰＵであってもよい。ただし、プロセッサーはＣＰＵに限定されるものではなく、ＧＰＵ（Graphics Processing Unit）、或いはＤＳＰ（Digital Signal Processor）等、各種のプロセッサーを用いることが可能である。またプロセッサーはＡＳＩＣによるハードウェア回路でもよい。またプロセッサーは、アナログ信号を処理するアンプ回路やフィルター回路等を含んでもよい。メモリーは、ＳＲＡＭ、ＤＲＡＭなどの半導体メモリーであってもよいし、レジスターであってもよいし、ハードディスク装置等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリーはコンピューターにより読み取り可能な命令を格納しており、当該命令がプロセッサーにより実行されることで、サーバーシステム７や端末装置９等の各部（通信部、処理部）の機能が実現されることになる。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、プロセッサーのハードウェア回路に対して動作を指示する命令であってもよい。

また本実施形態の手法は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステム７の作動方法であって、稼働情報のうちの第１の情報については、通信接続の確立後、通信接続の確立状態が維持される第１の通信処理により受信し、稼働情報のうちの第２の情報については、通信接続の確立後、情報が受信されると通信接続が切断される第２の通信処理により受信し、第１の通信処理により受信した第１の情報、及び第２の通信処理により受信した第２の情報を記憶部７５に書き込み、受信した第１の情報が所与の種別である場合に、端末装置９に対してプッシュ通知を行うサーバーシステム７の作動方法に適用できる。

或いは本実施形態の手法は、少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステム７の作動方法であって、通信接続の確立後、通信接続の確立状態が維持される通信処理により、稼働情報を受信し、稼働情報のうちの第１の情報を記憶部７５に上書きし、稼働情報のうちの第２の情報を記憶部７５に追記書き込みし、受信した第１の情報が所与の種別である場合に、端末装置９に対してプッシュ通知を行うサーバーシステム７の作動方法に適用できる。

以上、本発明を適用した実施形態及びその変形例について説明したが、本発明は、各実施形態やその変形例そのままに限定されるものではなく、実施段階では、発明の要旨を逸脱しない範囲内で構成要素を変形して具体化することができる。また、上記した各実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることによって、種々の発明を形成することができる。例えば、各実施形態や変形例に記載した全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態や変形例で説明した構成要素を適宜組み合わせてもよい。また、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。このように、発明の主旨を逸脱しない範囲内において種々の変形や応用が可能である。

ＮＥ１，ＮＥ２…ネットワーク、１…稼働情報収集システム、３…プリンター、
３１…処理部、３３…インターフェース部、３５…印刷部、３７…記憶部、
３３１…通信部、３３２…操作部、３３３…表示部、３５１…印刷エンジン、
３５２…センサー、３５３…カウンター、５…情報処理装置、５１…処理部、
５３…インターフェース部、５５…記憶部、５３１…通信部、５３２…操作部、
５３３…表示部、７…サーバーシステム、７１…処理部、７５…記憶部、
７３１…通信部、８１…ＭＱＴＴサーバー、８２…中継サーバー、９…端末装置、
９１…処理部、９３…インターフェース部、９５…記憶部、９３１…通信部、
９３２…操作部、９３３…表示部、９３４…報知部、１０…システム

Claims (17)

1. 少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムであって、
   通信接続の確立後、前記通信接続の確立状態が維持される第１の通信処理と、通信接続の確立後、情報が受信されると前記通信接続が切断される第２の通信処理と、を行う通信部と、
   処理部と、
   記憶部と、
   を含み、
   前記通信部は、
   前記稼働情報のうちの第１の情報については前記第１の通信処理により受信し、前記稼働情報のうちの第２の情報については前記第２の通信処理により受信し、
   前記処理部は、
   前記第１の通信処理により受信した前記第１の情報、及び前記第２の通信処理により受信した前記第２の情報を前記記憶部に書き込み、
   前記通信部は、
   受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うことを特徴とするサーバーシステム。
2. 請求項１において、
   前記処理部は、
   前記第１の通信処理により受信した前記第１の情報を前記記憶部に上書きし、前記第２の通信処理により受信した前記第２の情報を前記記憶部に追記書き込みすることを特徴とするサーバーシステム。
3. 請求項２において、
   前記通信部は、
   前記端末装置から報知設定情報を受信し、受信した前記報知設定情報に基づき前記プッシュ通知を行うことを特徴とするサーバーシステム。
4. 請求項３において、
   前記通信部は、
   前記第２の通信処理により、前記報知設定情報を前記端末装置から受信することを特徴とするサーバーシステム。
5. 請求項１乃至４のいずれかにおいて、
   前記第１の情報は、前記収集対象機器で発生したイベントをトリガーとして送信される情報であり、
   前記第２の情報は、所与のスケジュールで送信される情報であることを特徴とするサーバーシステム。
6. 請求項１乃至５のいずれかにおいて、
   前記第１の情報は、前記収集対象機器のステータスの変化情報、ジョブの開始／終了情報、消費材に関する情報、ジョブの時間情報、ジョブの進捗情報の少なくとも１つを含むことを特徴とするサーバーシステム。
7. 請求項１乃至５のいずれかにおいて、
   前記収集対象機器は印刷装置であり、
   前記第１の情報は、
   前記印刷装置のエラー状態、警告状態、通常動作状態、アイドル状態の少なくとも１つの状態を含むステータスの変化情報、インク又はトナーに関する情報、印刷媒体に関する情報、印刷完了時刻情報、印刷完了までの残り時間情報、印刷動作の進捗情報、
   の少なくとも１つを含むことを特徴とするサーバーシステム。
8. 請求項１乃至７のいずれかにおいて、
   前記第２の情報は、前記収集対象機器の稼働状態についての履歴情報であることを特徴とするサーバーシステム。
9. 請求項８において、
   前記履歴情報は、前記収集対象機器で発生したイベントにタイムスタンプが対応づけられた情報であることを特徴とするサーバーシステム。
10. 請求項１乃至９のいずれかにおいて、
    前記第２の情報は、前記収集対象機器で収集された時系列の複数の情報に対して加工処理が行われた情報を含むことを特徴とするサーバーシステム。
11. 請求項１乃至１０のいずれかにおいて、
    前記収集対象機器は印刷装置であり、
    前記第２の情報は、
    部品交換の履歴情報、ノズルチェックの履歴情報、フラッシングの回数情報、インクの吐出回数情報、の少なくとも１つを含むことを特徴とするサーバーシステム。
12. 請求項１乃至１１のいずれかにおいて、
    前記第１の通信処理は、ＭＱＴＴ（Message Queue Telemetry Transport）に対応する通信処理であり、
    前記第２の通信処理は、ＨＴＴＰ（Hypertext Transfer Protocol）に対応する通信処理であることを特徴とするサーバーシステム。
13. 少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムであって、
    通信接続の確立後、前記通信接続の確立状態が維持される通信処理により、前記稼働情報を受信する通信部と、
    処理部と、
    記憶部と、
    を含み、
    前記処理部は、
    前記稼働情報のうちの第１の情報を前記記憶部に上書きし、前記稼働情報のうちの第２の情報を前記記憶部に追記書き込みし、
    前記通信部は、
    受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行うことを特徴とするサーバーシステム。
14. 請求項１３において、
    前記通信部は、
    前記第２の情報として、前記収集対象機器でバッファーされた前記稼働情報に基づく情報を受信することを特徴とするサーバーシステム。
15. 請求項１乃至１４のいずれかに記載のサーバーシステムと、
    前記端末装置と、
    を含むことを特徴とする稼働情報収集システム。
16. 少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムの作動方法であって、
    前記稼働情報のうちの第１の情報については、通信接続の確立後、前記通信接続の確立状態が維持される第１の通信処理により受信し、
    前記稼働情報のうちの第２の情報については、通信接続の確立後、情報が受信されると前記通信接続が切断される第２の通信処理により受信し、
    前記第１の通信処理により受信した前記第１の情報、及び前記第２の通信処理により受信した前記第２の情報を記憶部に書き込み、
    受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行う、
    ことを特徴とするサーバーシステムの作動方法。
17. 少なくとも１つの収集対象機器の稼働情報を、ネットワークを介して収集するサーバーシステムの作動方法であって、
    通信接続の確立後、前記通信接続の確立状態が維持される通信処理により、前記稼働情報を受信し、
    前記稼働情報のうちの第１の情報を記憶部に上書きし、前記稼働情報のうちの第２の情報を前記記憶部に追記書き込みし、
    受信した前記第１の情報が所与の種別である場合に、端末装置に対してプッシュ通知を行う、
    ことを特徴とするサーバーシステムの作動方法。