JP2015212893A - 情報処理装置、方法、プログラム、及び情報処理システム - Google Patents

Abstract

【課題】 ステータス情報に基づくメッセージを適切に作成する。【解決手段】 所定の処理を実行する処理装置に関するステータス情報を取得する。所定の数より少ない通知項目に対応するステータス情報が取得された場合、当該通知項目に個別に対応するメッセージを作成し、当該所定の数以上の複数の通知項目に対応するステータス情報が取得された場合、当該複数の通知項目に基づく内容のメッセージを作成する。【選択図】 図１１

Description

本発明は、所定の処理を実行する処理装置に関するステータス情報に基づきメッセージを作成する技術に関するものである。

近年、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）と呼ばれる、誰でも自由に登録できるインターネットサービスが広く普及している。なかでもＴｗｉｔｔｅｒ（登録商標）といったリアルタイムコミュニケーションツールは、登録したユーザがミニブログと呼ばれる、つぶやきのようなメッセージをリアルタイムに送信することを可能としている。また、他のユーザを登録する機能があり、さらに多くのつぶやきメッセージをリアルタイムに受信することも可能である。そのため、こうしたリアルタイムコミュニケーションツールでは、通信負荷の増加を防ぐ等の理由により情報の通知回数に制限を設けている場合がある。また、このような通知回数の制限がなかったとしても、多数の通知を行うことで、ユーザの確認が煩雑になることがあり、通知回数を抑えた方がよい場合がある。

一方、インスタントメッセージのようなシステムを用い、遠隔の家電や周辺装置のステータス情報を、リアルタイムに情報処理装置にアクセスしているユーザへ通知するという技術が存在する。ここでいう家電や周辺装置の例としては、テレビ、冷蔵庫、洗濯機、プリンタ、複写機、ファクシミリ、スキャナ、デジタルカメラ、及びこれらの複合機であり、ネットワークに接続される情報処理装置と通信可能である。

さらに、障害等により周辺装置と情報処理装置が通信できず、周辺装置のステータス情報を情報処理装置へ送信できなかった場合、周辺装置にステータスを一時保存しておく。そして、復旧後に一時保存されたステータス情報を情報処理装置へ送信する技術がある（特許文献１参照）。

特開２００８−７０９６７号公報

しかしながら、特許文献１では、一時保存された通知項目が複数ある場合、複数回通知を行うため、例えば、通信が行えない期間において多数の通知項目が発生した場合、復旧後に多くの回数、通知を行ってしまう場合がある。

本発明は上記の課題に鑑みてなされたものであり、ステータス情報に基づくメッセージを適切に作成することができる技術を提供することを目的とする。

上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、
所定の処理を実行する処理装置に関するステータス情報を取得する取得手段と、
所定の数より少ない通知項目に対応するステータス情報が前記取得手段により取得された場合、当該通知項目に個別に対応するメッセージを作成し、当該所定の数以上の複数の通知項目に対応するステータス情報が前記取得手段により取得された場合、当該複数の通知項目に基づく内容のメッセージを作成する作成手段と
を備える。

本発明によれば、ステータス情報に基づくメッセージを適切に作成することができる。

ＭＦＰのハードウェア構成図である。 情報処理装置及び情報処理サーバの一例であるＰＣの概略構成を示すブロック図である。 ネットワーク構成を示すブロック図である。 ＭＦＰが表示部に表示するメニュー画面である。 ＭＦＰが表示部に表示する登録画面である。 ＭＦＰが表示部に表示する登録完了画面及び登録失敗画面を示す図である。 ＳＮＳアカウントの登録時のＭＦＰの動作を示すフローチャートである。 サーバ及びクライアントのソフトウェア構成図である。 アカウント情報保存部が保持するアカウント情報対応表を示す図である。 ステータス情報保存部が保持する未送信のステータス情報対応表を示す図である。 ＭＦＰ及びサーバの動作を示すフローチャートである。 サーバの動作を示すフローチャートである。 ユーザへの通知表示画面を示す図である。 ユーザへの通知表示画面を示す図である。 ステータス情報管理部が保持するステータス情報対応表を示す図である。 ＭＦＰ及びサーバの動作を示すフローチャートである。 サーバ及びクライアントのソフトウェア構成図である。 通知履歴保存部が保持する通知履歴情報対応表を示す図である。 ＭＦＰ及びサーバの動作を示すフローチャートである。 サーバの動作を示すフローチャートである。 サーバの動作を示すフローチャートである。 サーバ及びクライアントのソフトウェア構成図である。 サーバの動作を示すフローチャートである。

以下、添付図面を参照して本発明の実施形態を詳細に説明する。尚、以下の実施形態は、特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

以下の各実施形態におけるＭｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ（複合機能周辺装置、以下、ＭＦＰ）、ＰＣ（パーソナルコンピュータ）、及びこれらを接続するネットワーク構成と、これらを用いて行われるクラウド印刷について説明する。

図１は周辺装置の一例であるＭＦＰ１００の概略構成を示すブロック図である。ＭＦＰ１００は、プリンタ機能、スキャナ機能及びストレージ機能を備えており、ネットワークを経由してそれぞれの機能のサービスを提供することができる。

ＭＦＰ１００において、プリンタ機能はプリンタ部１０１で、スキャナ機能はスキャナ部１０２で実現する。ストレージ機能はメモリカード装着部１０３及びメモリカード１０４で実現する。

プリンタ部１０１は、外部から受信した印刷データやメモリカード１０４に格納されている画像データ等のデータを、インクジェット方式や電子写真方式等の印刷方式によって印刷用紙に印刷する。スキャナ部１０２は、原稿台にセットされた原稿を光学式に読み取って電子データに変換し、更に指定されたファイル形式に変換してネットワーク経由で外部装置に送信する。もしく、この電子データに変換し指定したファイル形式に変換したデータを保存する保存領域（不図示）をＭＦＰ１００内に備えてもよい。コピーサービスは、原稿台に置かれた原稿をスキャナ部１０２で読み取って生成した画像データをプリンタ部１０１へ転送してプリンタ部１０１が印刷用紙にその原稿データを印刷する。また、メモリカード１０４に格納されているファイルを、ネットワークを経由して接続された外部装置が読み出し、編集し、外部装置からメモリカード１０４内にファイルを格納することが可能である。

更に、ＭＦＰ１００は、各種構成要素を制御するための中央演算装置（ＣＰＵ）１０５、ＣＰＵ１０５が読み出すプログラムコード等のデータを格納するＲＯＭ等のプログラムメモリ１０６を備える。また、ＭＦＰ１００は、各サービス実行時に画像データ等のデータを一時格納したり、バッファリングしたりするためのＲＡＭ等のワークメモリ１０７、ＬＣＤ等の表示部１０８、各スイッチやタッチパネルを含む操作部１０９を備える。ＣＰＵ１０５は、プログラムメモリ１０６に格納されているプログラムをワークメモリ１０７上で実行することにより、後述する各種の処理を実現することができる。

また、ＭＦＰ１００は、ＭＦＰ１００をネットワークに接続して各種通信を行うためのネットワーク通信部１１０と、ネットワーク通信部１１０をネットワーク媒体に接続するためのネットワーク接続部１１１を備える。ネットワーク通信部１１０は、有線ネットワークと無線ネットワークの内、少なくともいずれかに対応する。有線ネットワーク対応の場合、ネットワーク接続部１１１は有線ネットワークのケーブルをＭＦＰ１００に接続するためのコネクタとなる。また、無線ネットワーク対応の場合、ネットワーク接続部１１１はアンテナとなる。

また、更に、ＭＦＰ１００は、ネットワーク通信部１１０が受信したデータを格納するために、不揮発性フラッシュメモリであるフラッシュメモリ１１２を備える。また、さらに、ＭＦＰ１００は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）インタフェースを介して情報処理装置２００（図２）と通信するためのＵＳＢ通信部１１４を備える。ＭＦＰ１００は、情報処理装置２００とはＵＳＢコネクタ等のコネクタによるＵＳＢ接続部１１５より接続する。

ＭＦＰ１００の各種構成要素は、信号線１１３により相互に接続される。このようにＭＦＰ１００は、プリンタ機能、スキャナ機能、及びストレージ機能によって画像を処理する画像処理装置でもあり、また、プリンタ機能により画像を形成する画像形成装置でもある。また、更に、ＭＦＰ１００は、プログラムメモリ１０６にＷｅｂブラウザプログラムを含み、サーバとのＨＴＴＰ通信またはＨＴＴＰＳ通信を行うことが可能である。

図２は情報処理装置の一例であるクライアント及びサーバの概略構成を示すブロック図である。クライアントあるいはサーバを実現する情報処理装置２００は、例えば、汎用的なＰＣに所定のソフトウェアをインストールすることによって、以下に説明する各種の処理を実現可能である。情報処理装置２００は、用途や目的に応じて、サーバとして機能したり、クライアントとして機能することができる。

図２において、２０１は、情報処理装置２００の各種構成要素を制御するためのＣＰＵである。２０２は、ＣＰＵ２０１が読み出すアプリケーションプログラムやＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）等をインストールし、また、各種ファイル等のデータを格納するディスク装置である。

ここで、情報処理装置２００によって実現されるクライアント２５０（図３）においては、アプリケーションプログラムのひとつとして、Ｗｅｂブラウザがインストールされている。また、情報処理装置２００によって実現されるサーバ３０１（図３）においては、Ｗｅｂアプリケーションがインストールされている。尚、クライアント２５０は、ＰＣ（パーソナルコンピュータ）、携帯電話やスマートフォン、ＰＤＡ等の各種の情報処理装置である。

２０３は、ＣＤ−ＲＯＭ等の外部記憶媒体の内容を読み出すための外部ディスク読取装置である。２０４は、ＣＰＵ２０１が必要に応じてデータの一時的格納、バッファリング等の処理を行うためのメモリである。ＣＰＵ２０１は、ディスク装置２０２に格納されている各種のプログラムをメモリ２０４上で実行することにより、後述する各種の処理を実現することができる。

ＣＰＵ２０１は、例えば、情報処理装置２００からＭＦＰ１００を利用するためのソフトウェアのセットアッププログラムを実行することにより、各種プログラムが情報処理装置２００にインストールされる。ディスク装置２０２に格納される各種プログラムには、スキャン機能を利用するためのスキャナドライバ、プリンタ機能を利用するためのプリンタドライバ等の各種デバイスドライバが含まれる。また、さらに、ＭＦＰ１００の状態（イベントの有無等）を問い合わせるためのポーリングアプリケーション、ＭＦＰ１００の状態（ステータス）を管理する管理ソフトウェア（ボタンモニター）等の各種アプリケーションが含まれる。

２０５は、ＬＣＤを含む表示部である。２０６は、キーボードやマウス等による操作部である。２０７は、情報処理装置２００をネットワークに接続して各種通信を行うためのネットワーク通信部である。２０８は、ネットワーク通信部２０７をネットワーク媒体に接続するためのネットワーク接続部である。

ＭＦＰ１００と同様に、ネットワーク通信部２０７とネットワーク接続部２０８は、有線ネットワークと無線ネットワークの内、少なくともいずれかに対応する。具体的な形態は、ＭＦＰ１００に内蔵のネットワーク通信部１１０及びネットワーク接続部１１１と同様に、対応するネットワークに応じて必要な機能及び形態をとる。２０９は、各種構成要素を接続するための信号線である。２１０は、各種周辺装置とＵＳＢインタフェースを介して通信するためのＵＳＢ通信部である。２１１は、ＵＳＢコネクタ等のＵＳＢ接続部である。

このように、ＭＦＰ１００と情報処理装置２００をネットワークを介して接続した情報処理システムとして構成することができる。このネットワークには、例えば、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）がある。また、以降の説明では、有線ネットワークケーブルであるネットワークから構成されるネットワークについて扱うが、これに限定されない。ネットワークの態様は、無線ネットワークであっても、有線ネットワークと無線ネットワークが混在するネットワークであっても同様である。

図３は図１のＭＦＰ１００と図２の情報処理装置２００によるネットワークシステムの概略構成を示すブロック図である。図３では、情報処理装置２００によって実現される、クライアント２５０、サーバ３０１及びＳＮＳサーバ３０２を含んでいる。

図３において、クライアント２５０には、クライアント用ＯＳがインストールされている。サーバ３０１には、サーバ用ＯＳがインストールされている。ＳＮＳサーバ３０２には、サーバ用ＯＳがインストールされているとともに、メッセージの投稿、閲覧等の各種サービスを提供する。例えば、ＳＮＳサーバ３０２は、リアルタイムコミュニケーションツールであるＴｗｉｔｔｅｒ（登録商標）のようなＷｅｂアプリケーションであるところのＳＮＳアプリケーションをサービスとして提供している。

そして、ＭＦＰ１００、サーバ３０１、ＳＮＳサーバ３０２、クライアント２５０がインターネット３５０を介して相互に接続されている。ＭＦＰ１００は、インターネット３５０を介してサーバ３０１と通信する。クライアント２５０はインターネット３５０を介してサーバ３０１と通信する。尚、インターネット３５０への接続方式は有線ネットワークであっても無線ネットワークであってもよい。また、インターネット３５０に接続されているクライアントとサーバとＭＦＰの台数は図３に示す例に限定されるものではなく、用途や目的に応じて、それぞれ複数の台数を接続することができる。

ここで、印刷処理として、一般的なクラウド印刷についての説明を加える。まず、クライアント２５０において、ユーザは、Ｗｅｂブラウザを介してサーバ３０１のＷｅｂアプリケーションを利用する。このＷｅｂアプリケーションは、サーバ３０１上で動作する。そこで、クライアント２５０のＷｅｂブラウザからＷｅｂアプリケーションに対して印刷を指示し、出力先のプリンタとしてＭＦＰ１００を指定する。

サーバ３０１はＷｅｂアプリケーションが作成したアプリケーション文書を、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）に代表される汎用的な電子文書に形式に変換し、別途保存してある印刷設定情報と電子文書から描画命令を発行する。さらに、サーバ３０１に搭載されたプリンタドライバは、この描画命令を出力先であるＭＦＰ１００が解釈可能な印刷命令に変換し、その印刷命令をＭＦＰ１００に送信する。

ＭＦＰ１００は、受信した印刷命令に従い印刷動作を行い、印刷物を生成する。ＭＦＰ１００は、ステータス情報を一定間隔でサーバ３０１に送信する。ステータス情報の種類としては、印刷開始、印刷完了、印刷中止、印刷失敗、プリンタビジー、紙なし、紙ジャム、紙カセット交換、インク少量、インク切れ、カバーオープン等、様々な多くのステータスが存在する。これらのステータス情報はそれぞれの種類に応じた所定のコードとして、ワークメモリ１０７に一旦保存され、ネットワーク接続部１１１を介してサーバ３０１に送信される。

以下、図３のネットワークシステムにおいて実現されるいくつかの実施形態について説明する。

尚、後述の実施形態における通知処理を行うにあたり、次に示す処理が完了していることを必要条件とする。

１．ユーザは、あらかじめＳＮＳアプリケーションを利用するための、ユーザ自身のアカウント（以下、アカウント１）を作成しておく必要がある。

２．ユーザは、ＳＮＳアプリケーションを利用するための、ＭＦＰ１００のステータス情報を投稿するためのアカウント（以下、アカウント２）を作成しておく必要がある。

３．ユーザは、ＭＦＰ１００上において、アカウント２にＭＦＰのステータス情報を投稿させるように設定しておく必要がある。

４．ユーザは、ＳＮＳアプリケーションを利用するためのアカウント１で、アカウント２をフォロー（他のユーザの投稿を自分の画面に表示されるように、ユーザを登録すること）しておく必要がある。

図４はＭＦＰ１００の表示部１０８に表示される、印刷用アプリケーションやＳＮＳ通知サービス等の各種アプリケーションを実行するためのメニュー画面４００の一例を示す図である。メニュー画面４００では、印刷アプリケーションＡを実行するためのボタン４０１０、印刷アプリケーションＢを実行するためのボタン４０２０、及びＳＮＳ通知サービスを実行するためのボタン４０３０を含んでいる。ユーザは、これらのボタンを押下することによって、そのボタンに対応するアプリケーションを実行するための各種処理を実行することができる。

図５はＭＦＰ１００の表示部１０８に表示される、ＭＦＰ１００のステータス情報を投稿するためのアカウント２の登録画面５００の一例を示す図である。登録画面５００において、アカウント入力ボックス５１は、ユーザが操作部１０９により、所定のサービスを利用するためのアカウントを入力するボックスである。ここで、所定のサービスとは、例えば、ＳＮＳサーバ３０２が提供するＳＮＳ通知サービスがある。パスワード入力ボックス５２は、ユーザが操作部１０９によりパスワードを入力するボックスである。登録ボタン５３は、アカウント入力ボックス５１に入力されたアカウントとパスワード入力ボックス５２に入力されたパスワードに基づいて、登録処理を実行するためのボタンである。キャンセルボタン５４は、登録処理をキャンセルして、処理を終了するためのボタンである。登録ボタン５３によって登録処理が実行され、登録が成功すると、図６（ａ）に示す登録完了画面６００が表示される。一方、登録が失敗すると、図６（ｂ）に示す登録失敗画面６１０が表示される。

図７は登録及び認証処理を示すフローチャートである。

この処理は、ユーザがＳＮＳ通知サービスを利用するために、図４のメニュー画面４００のＳＮＳ通知サービスに対するボタン４０３０を押下すると、ＭＦＰ１００とサーバ３０１との間で実行される後述の実施形態の通知処理を行うために開始される。図７に示す処理は、ＭＦＰ１００のＣＰＵ１０５がプログラムメモリ１０６に格納されているプログラムをワークメモリ１０７上で実行し、かつサーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。

まず、Ｓ１で、ＭＦＰ１００は、表示部１０８に図５の登録画面５００を表示する。Ｓ２で、ＭＦＰ１００は、ユーザによって登録画面５００の登録ボタン５３が押下されたか否かを判断する。登録ボタン５３が押下されない場合（Ｓ２でＮＯ）、つまり、キャンセルボタン５４が押下された場合、処理を終了する。あるいは、登録ボタン５３が押下されるまで待機しても良い。

一方、登録ボタン５３が押下された場合（Ｓ２でＹＥＳ）、Ｓ３に進む。Ｓ３で、ＭＦＰ１００は、ＭＦＰ１００のＭＦＰ＿ＩＤ（ＭＦＰ毎に割り当てられた固有のＩＤ）、アカウント入力ボックス５１で入力されたＳＮＳアカウント、及びパスワード入力ボックス５２で入力されたパスワードを含む認証情報をサーバ３０１へ送信する。

Ｓ４で、サーバ３０１は、ＭＦＰ１００より、ＭＦＰ＿ＩＤ、ＳＮＳアカウント及びパスワードを含む認証情報を受信する。Ｓ５で、サーバ３０１は、認証情報に含まれる、ＳＮＳアカウント及びパスワードにより、ＳＮＳ通知サービスを実現するＳＮＳアプリケーションのユーザ認証を行う。Ｓ６で、サーバ３０１は、ＳＮＳアプリケーションのユーザ認証が成功したか否かを判断する。ユーザ認証が成功したと判断した場合（Ｓ６でＹＥＳ）、Ｓ７で、サーバ３０１は、ＭＦＰ１００より受信したアカウントを、ＭＦＰ１００より受信したＭＦＰ＿ＩＤの対応情報として、後述するアカウント情報保存部４０２（図８）に保存する。その後、Ｓ８へ進む。一方、ユーザ認証が失敗したと判断した場合（Ｓ６でＮＯ）、Ｓ８へ進む。Ｓ８で、サーバ３０１は、ユーザ認証の結果を示す認証終了通知をＭＦＰ１００へ送信する。この認証終了通知には、ユーザ認証の成功／失敗を示す認証情報が含まれる。

Ｓ９で、ＭＦＰ１００は、サーバ３０１より認証終了通知を受信する。Ｓ１０で、ＭＦＰ１００は、認証終了通知により、ユーザ認証が成功したか否かを判断する。ユーザ認証が成功したと判断した場合（Ｓ１０でＹＥＳ）、Ｓ１１で、ＭＦＰ１００は、表示部１０８に図６（ａ）に示す登録完了画面６００を表示する。一方、ユーザ認証が失敗したと判断した場合（Ｓ１０でＮＯ）、Ｓ１２で、ＭＦＰ１００は、表示部１０８に図６（ｂ）に示す登録失敗画面を表示する。

以上の処理が終了することで、ＳＮＳアカウントにＭＦＰ１００のステータス情報を投稿させる設定が完了する。

上記の設定により、ＳＮＳサーバ３０２がＭＦＰ１００のステータス情報をＰＣクライアント２５０に通知することができる。但し、ＳＮＳサーバ３０２は、所定時間内においてステータス情報を通知する回数に制限があるものとする。このように制限を設ける理由としては、例えば、通信負荷を抑えるためである。仮に、所定時間内に制限を越える数の通知項目（ステータス情報）がＭＦＰ１００で発生し、ＳＮＳサーバ３０２が通知要求を受けたとしても、ＳＮＳサーバ３０２はクライアント２５０に通知を行わない。

そこで、本実施形態では、上記のように所定時間内においてステータス情報の通知回数が上限を越える場合に、複数のステータス情報の内容を纏めたステータス情報を作成し、通知する。これにより、ステータス情報の通知回数を抑えるとともに、当該複数のステータス情報の内容を適切に通知することができる。上記の処理について詳細に説明する。

＜実施形態１＞
実施形態１では、サーバ３０１が、ＳＮＳサーバ３０２が提供するリアルタイムコミュニケーションツール（サービス）におけるステータス通知の通知回数制限を超えそうか否かを判断する。そして、判断の結果、通知回数制限を超えそうと判断された場合には、サーバ３０１は、ＭＦＰ１００から送信されるステータス情報を纏めて通知（一括通知）する。即ち、実施形態１では、ステータス情報受信時のリアルタイムコミュニケーションツールへの残りの通知可能回数をＳＮＳサーバ３０２から取得し、通知回数制限を超えるか否かを判断する。そして、通知回数制限を超えると判断された場合は、サーバ３０１は、ステータス情報をデータベースに一時保存した後で、別途、纏めて通知することで、通知回数の制限を超えないように制御する。尚、この場合、クライアントに通知すべきであった複数のステータス情報を纏めた情報を作成し、通知を行う。

この結果、サーバ３０１は、リアルタイムコミュニケーションツールにおける通知回数制限を超えることなく、ユーザへ通知しなければならないステータス情報の取りこぼしがないようクライアント２５０へ通知することができる。

尚、本実施形態では、ＭＦＰ１００から、印刷完了時にステータス通知をサーバ３０１に送信する例で説明するが、これに限定されない。ステータス通知は、例えば、印刷開始前、ステータス変更時等の任意のタイミングで行ってもよい。また、サーバ３０１からＭＦＰ１００へステータス情報を問い合わせるポーリング形式で、ＭＦＰ１００からサーバ３０１へのステータス通知を行う構成としても良い。

図８はサーバ３０１のシステムを構成する各装置のソフトウェア構成図である。尚、サーバ３０１は、図２に示したものと同様の構成を備えている。そして、図８に示す各制御部（ソフトウェアモジュール）がプログラムとしてサーバ３０１のＲＯＭに記憶されている。そして、サーバ３０１のＣＰＵが、当該プログラムをＲＯＭから読み出してＲＡＭ上で実行することで、ＣＰＵが図８に示す各制御部として動作する。

サーバ３０１は、ステータス通知サービスを実装する。サーバ３０１は、ステータス通知サービスにより、ＭＦＰ１００からステータス情報を受信し、リアルタイムコミュニケーションツールにおける所定時間内の通知回数制限を超えそうか否かを判断する。判断の結果、超えそうでない場合、サーバ３０１は、ステータス情報よりメッセージを作成してＳＮＳサーバ３０２へ送信する。一方、判断の結果、通知回数制限を超えそうである場合、サーバ３０１は、上記所定時間が経過した後に纏めて通知する処理を行う。

サーバ３０１が提供するステータス通知サービスは、複数種類の機能を提供する。ステータス受信部４０１は、ＭＦＰ１００からＭＦＰ１００のステータス情報を受信する。ステータス情報には、ステータス情報を送信したＭＦＰ１００のＭＦＰ＿ＩＤが付与されている。アカウント情報保存部４０２は、ＭＦＰ毎に登録されたＳＮＳサーバ３０２が提供するＳＮＳサービス（例えば、リアルタイムコミュニケーションツール）を利用するためのＳＮＳアカウント情報を保存管理する。アカウント情報取得部４０３は、アカウント情報保存部４０２より、ＭＦＰ１００上で事前に登録されたＳＮＳアカウント情報を取得する。通知回数取得部４０４は、アカウント情報取得部４０３より取得したＳＮＳアカウントのリアルタイムコミュニケーションツールへの残りの通知可能回数をＳＮＳサーバ３０２より取得する。通知判断部４０５は、通知回数取得部４０４が取得した通知可能回数により、リアルタイムコミュニケーションツールにおける通知回数制限を超えないか否かを判断する。

メッセージ作成部４０６は、ステータス情報により、通知メッセージの作成を行う。メッセージ送信部４０７は、通知メッセージ、ＳＮＳアカウントをネットワーク（例えば、インターネット）経由でＳＮＳサーバ３０２に送信する。ステータス情報保存部４０８は、通知判断部４０５により通知回数制限を超えると判断された場合に、そのステータス情報を未送信ステータス情報として、サーバ内のＲＡＭや外部または内部のハードディスク等に保存管理する。ステータス情報管理部４０９は、ステータス情報保存部４０８の管理を行う。タイマコントローラ４１０は、ステータス情報管理部４０９に対してステータス情報保存部４０８の管理指示を一定時時間間隔で発行する。

メッセージ合成部４１１は、メッセージ作成部４０６が作成した複数の通知メッセージを１つに纏める合成を行う。具体的には、ステータス情報保存部４０８により未送信のステータス情報が複数保存されている場合に、その複数のステータス情報を纏めたステータス情報を作成する。即ち、複数の通知メッセージを纏めた通知メッセージを作成する。詳細については後述する。

ＳＮＳサーバ３０２のＳＮＳアプリケーション７０１は、例えば、Ｔｗｉｔｔｅｒ（登録商標）のようなリアルタイムコミュニケーションツールであり、かつＷｅｂアプリケーションであるところのＳＮＳアプリケーションをサービスとして提供する。

クライアント２５０のＷＥＢブラウザ６０１は、サーバ３０１あるいはＳＮＳサーバ３０２のＷｅｂアプリケーションを利用する。また、Ｗｅｂブラウザ６０１は、サーバ３０１が提供するＷｅｂアプリケーションに対して印刷を指示し、出力先のプリンタとしてＭＦＰ１００を指定することができる。また、クライアント２５０のＷＥＢブラウザ６０１は、ＳＮＳサーバ３０２のＷｅｂアプリケーション（リアルタイムコミュニケーションツール）を利用する。そして、ＭＦＰ１００のステータス情報を、ＳＮＳサーバ３０２を介してサーバ３０１から受信することができる。

図９のテーブル１０００は、アカウント情報保存部４０２が保持する、ＭＦＰ毎のＳＮＳアカウント情報を保存するテーブルである。ＭＦＰ＿ＩＤ１００１は、ＭＦＰ毎に割り当てられるＩＤであり、テーブル１０００内でこの値が重複することがなく、テーブル１０００内でＭＦＰのＳＮＳアカウント情報を検索する際の主キーとなる。ＳＮＳアカウント１００２は、ＭＦＰに登録されているＳＮＳアカウント情報である。上記のアカウント情報取得部４０３は、テーブル１０００を参照することで、ステータス情報を通知してきたＭＦＰＩＤ１００１を特定し、当該ＭＦＰ＿ＩＤ１００１に対応するＳＮＳアカウント１００２を特定する。そして、メッセージ作成部４０６は、当該ＳＮＳアカウント１００２と、当該ステータス情報（通知メッセージ）をＳＮＳサーバ３０２に送信する。これにより、ＭＦＰに対応するステータス情報を、当該ＭＦＰに対応するＳＮＳアカウント（例えば、当該ＭＦＰの所有者のアカウント）に向けて通知することができる。

図１０のテーブル１１００は、ステータス情報保存部４０８が保持する、未送信のステータス情報を保存するテーブルである。ＭＦＰ＿ＩＤ１１０１は、ＭＦＰ毎に割り当てられるＩＤであり、テーブル１１００内でこの値が重複することがなく、テーブル１１００内でＭＦＰのステータス情報を検索する際の主キーとなる。ステータス１１０２は、ＭＦＰのステータス情報である。受信日時１１０３は、ステータス情報を受信した日時である。テーブル１１００には、他にもＭＦＰ毎に管理、保持されるデータを格納することができる。例えば、ＭＦＰの仕向け情報、ＭＦＰのバージョン情報等が考えられるが、それ以外の項目が存在していても構わない。

図１１はＭＦＰ１００のステータスを、サーバ３０１を介してＳＮＳサーバ３０２へ通知する処理を示すフローチャートである。図１１に示す処理は、ＭＦＰ１００のＣＰＵ１０５がプログラムメモリ１０６に格納されているプログラムをワークメモリ１０７上で実行し、かつサーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。

Ｓ５０１で、ＭＦＰ１００は、サーバ３０１のステータス受信部４０１にステータス情報を送信する。尚、このステータス情報は１または複数の通知項目に対応する。具体的には、例えば、複数の印刷ジョブに基づいて複数回の印刷を行った場合、複数の印刷ジョブのそれぞれに対応する「印刷完了」ステータスが複数の通知項目となる。或いは、例えば１回目の印刷では印刷が完了したが、２回目の印刷ではインク切れ等のエラーにより印刷が中断された場合、「印刷完了」と「エラー」が複数の通知項目として、ＭＦＰ１００から送信される。

さらに、ステータス情報として、ＭＦＰ１００のステータスに関するテーブルが送信されてもよい。そのテーブルでは、例えば、「印刷完了」、「インクなし」、「紙ジャム」等の各項目について「０」または「１」が入力されるものとする。そして、「１」が入力されている項目については、現在、ＭＦＰ１００が当該通知項目に該当する状態であるものとする。通知対象の通知項目として指定されているものとして、ＳＮＳサーバ３０２への通知の対象となる。

また、ＭＦＰ１００から送信されるステータス情報は、通知項目のそれぞれに個別に対応する情報でなくてもよい。例えば、「印刷完了とエラー」や、「４件の印刷完了」等、複数のステータスが纏まった情報であってもよい。

Ｓ５０２で、サーバ３０１のステータス受信部４０１は、ＭＦＰ１００からステータス情報を受信する。ステータス情報には、ＭＦＰ１００のステータスだけでなく、ＭＦＰ１００のＭＦＰ＿ＩＤが付与されている。Ｓ５０３で、サーバ３０１のアカウント情報取得部４０３は、ＭＦＰ＿ＩＤと一致する、アカウント情報保存部４０２が保持するテーブル１０００のＭＦＰ＿ＩＤ１００１に定義されたＳＮＳアカウント１００２を取得する。Ｓ５０４で、サーバ３０１の通知回数取得部４０４は、Ｓ５０２においてステータス情報が受信されたときの、ＳＮＳアカウントのリアルタイムコミュニケーションツールに対する残りの通知可能回数をＳＮＳサーバ３０２より取得する。尚、ＳＮＳサーバ３０２では、所定時間内の通知可能回数がＳＮＳアカウント毎に設けられており、Ｓ５０４で取得される通知可能回数は、時間により、また、ＳＮＳアカウントにより異なる。

Ｓ５０５で、サーバ３０１の通知判断部４０５は、通知可能回数より、ＳＮＳアカウントの通知回数がリアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かを判断する。この通知回数制限を超えそうか否かの判断は、Ｓ５０２により受信されたステータス情報に対応する１または複数の通知項目の数が通知回数制限を超えてしまうか判断する。あるいは、当該通知項目の数が通知回数制限から所定範囲内の通知回数を超えてしまうかどうかで判断する。

通知回数制限を超えないと判断した場合（Ｓ５０５でＮＯ）、Ｓ５０６で、サーバ３０１のメッセージ作成部４０６は、ステータス情報によりメッセージの作成を行う。Ｓ５０７で、サーバ３０１のメッセージ送信部４０７は、メッセージとアカウント情報をＳＮＳサーバ３０２へ送信する。

一方、通知回数制限を超えそうであると判断した場合（Ｓ５０５でＹＥＳ）、Ｓ５０８で、サーバ３０１の通知判断部４０５は、ステータス情報保存部４０８にステータス情報を追加保存する。

図１２はステータス情報保存部４０８に登録されている未送信のステータス情報を、ステータス情報管理部４０９が自動で纏めて送信する処理を示すフローチャートである。図１２に示す処理は、サーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。

尚、リアルタイムコミュニケーションツールにおける残りの通知可能回数は所定のタイミングでリセットされ、その通知可能回数に余裕が生まれる。また、ステータス情報保存部４０８に保存される未送信のステータス情報は、何もしなければ延々蓄積されていき膨大な量となってしまう。そこで、タイマコントローラ４１０の指示によりステータス情報管理部４０９は、ステータス情報保存部４０８を一定周期で常時監視し、その一定周期毎に未送信のステータス情報を纏めて送信（一括送信）する処理を実行する。

Ｓ６０１で、サーバ３０１のステータス情報管理部４０９は、アカウント情報取得部４０３により、ＭＦＰ１００と一致する、アカウント情報保存部４０２が保持するテーブル１０００のＭＦＰ＿ＩＤ１００１に定義されたＳＮＳアカウント１００２を取得する。Ｓ６０２で、サーバ３０１のステータス情報管理部４０９は、通知回数取得部４０４により、ＳＮＳアカウントのリアルタイムコミュニケーションツールに対する残りの通知可能回数をＳＮＳサーバ３０２より取得する。

Ｓ６０３で、サーバ３０１のステータス情報管理部４０９は、通知判断部４０５により、通知可能回数により、ＳＮＳアカウントの通知回数がリアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かを判断する。通知回数制限を超えそうと判断した場合（Ｓ６０３でＹＥＳ）、処理を終了する。

一方、通知回数制限を超えないと判断した場合（Ｓ６０３でＮＯ）、Ｓ６０４〜Ｓ６０６の処理を、未送信のステータス情報の数分、ループさせて実行する。

Ｓ６０４で、ステータス情報管理部４０９は、ＭＦＰ＿ＩＤ１と一致する、ステータス情報保存部４０８が保持するテーブル１１００のＭＦＰ＿ＩＤ１１０１に定義されたステータス１１０２と受信日時１１０３のステータス情報を取得する。

Ｓ６０５で、サーバ３０１のステータス情報管理部４０９は、ステータス情報でメッセージ作成部４０６によりメッセージの作成を行う。Ｓ６０６で、サーバ３０１のステータス情報管理部４０９は、メッセージ合成部４１１により、作成したメッセージを通知メッセージに纏める。具体的には、例えば、未送信のステータス情報として１つ目のステータス情報に対応するメッセージがＳ６０５で作成された場合、当該メッセージを含む通知メッセージを作成する。一方、２つ目以降のステータス情報に対応するメッセージがＳ６０５で作成された場合、既に作成されている通知メッセージ（１つ目のメッセージを含む）に当該メッセージの内容を追記する。

Ｓ６０７で、サーバ３０１のステータス情報管理部４０９は、取得したステータス情報をステータス情報保存部４０８より削除する。ステータス情報管理部４０９は、ステータス情報保存部４０８に保存されているＭＦＰ１００のステータス情報すべてに対してＳ６０４〜Ｓ６０７を繰り返し行う。そして、Ｓ６０８で、サーバ３０１のステータス情報管理部４０９は、通知メッセージが存在すれば、メッセージ送信部４０７により通知メッセージをＳＮＳサーバ３０２へ送信する。

Ｓ６０８における処理により、ＳＮＳサーバ３０２は、当該通知メッセージを当該ＳＮＳアカウントに対するメッセージとして表示する。即ち、クライアント２５０は、当該メッセージをＳＮＳサーバ３０２を介して受信する。

図１２の処理によれば、複数のステータス情報（複数の通知項目）が未送信であった場合、Ｓ６０５の処理により、１つの通知メッセージに纏められ、ＳＮＳサーバ３０２に送信される。よって、上記のようにＳＮＳサーバ３０２において通知回数に制限があったとしても、通知回数を削減することができる。

尚、通知回数を削減する方法として、例えば複数の通知項目から１つの通知項目を選択し、その１つの通知項目のみを通知する方法もある。但し、この方法では、当該選択された通知項目以外の項目についてはクライアントに通知されないことになる。

そこで、上記Ｓ６０５では、複数の通知項目を纏めて、当該複数の通知項目が反映された１つの通知メッセージを作成する。そのため、当該通知メッセージが送信されたクライアント装置のユーザは、複数の通知項目が存在することを認識することができる。

尚、Ｓ６０７でステータス情報管理部４０９は、取得したステータス情報をステータス情報保存部４０８より削除しているが、取得したステータス情報を再度通知するようなことを避ける方法であれば削除しなくてもよい。例えば、送信したことを示す送信済フラグをステータス情報に付加して、送信／未送信のステータス情報を区別するようにしても良い。

図１２の処理によって、ＳＮＳサーバ３０２は、サーバ３０１より送信されたメッセージとＳＮＳアカウント情報を受信する。ＳＮＳサーバ３０２は、受信したメッセージを、ＳＮＳアカウントの投稿として、当該ＳＮＳアカウントをフォローしているユーザのクライアント２５０で表示されるタイムラインに図１３のようなメッセージを出力する。タイムラインとは、ユーザがフォローしている他のアカウントが投稿したメッセージが、投稿時間順に並べられ、表示されるものである。尚、ユーザはあらかじめクライアント２５０のＷｅｂブラウザ６０１によって、ＳＮＳアプリケーション７０１にユーザ自身のアカウントでログインをしておく必要がある。

また、サーバ３０１のメッセージ合成部４１１が行う、メッセージ作成部４０６が作成したメッセージと通知メッセージを１つに纏める処理は、図１３のように、作成した複数のメッセージが並べて表示されるように合成していく方法がある。また、図１４のように、同一のステータスが存在する場合は、ユーザへの同一のメッセージを繰り返して通知してしまうことを避けるため、メッセージの繰り返しをなくして時間を並べて通知する方法もある。

例えば、図１３及び図１４の例のように、２つのステータス情報（「印刷完了」）を通知する場合、そのそれぞれに対して２つの通知メッセージが作成され、クライアント２５０に２回の通知が行われる。ところが図１３及び図１４により通知内容が纏められた１つの通知メッセージが通知されることで、通知回数を抑制し、且つ２つのステータス情報の内容をクライアント２５０のユーザに認識させることができる。

尚、ＳＮＳサーバの通知回数制限がなくても、図１３及び図１４のように、１つの通知メッセージとして通知された方がよい場合がある。そこで、例えばサーバ３０１が同一のＭＦＰ１００から複数のステータス情報を受信した場合に、通知回数制限に関わらず、その複数のステータス情報を１つの通知メッセージに纏めてもよい。

ここで、サーバ３０１のステータス情報管理部４０９が行う図１２の処理では、ステータス情報保存部４０８に保存されているＭＦＰ１００のステータス情報をすべてユーザへ通知することとなる。よって、ステータス情報保存部４０８にＭＦＰ１００のエラーに関するステータス情報が保存されていた場合、既にエラーが回復しているにもかかわらずユーザへ通知してしまう可能性がある。これは、ユーザビリティの観点から好ましくない。そこで、本実施形態では、エラーを通知する前に、そのエラーがすでに回復されていないか否かをＭＦＰ１００へ問い合わせ、回復していればユーザへ通知しない（ユーザへの通知を禁止する）判断処理を行うステータス情報管理部４０９に関して説明する。

図１５のテーブル１２００は、ステータス情報管理部４０９が保持する、ステータス情報のステータス種と、そのステータス情報がエラーであるか否かを示す情報を保存するテーブルである。ステータス種１２０１は、各ステータス名であり、テーブル１２００内でこの値が重複することがなく、テーブル１２００内でステータスを検索する際の主キーとなる。エラー判断１２０２は、エラーであるか否かを示す真理値情報（ＦＡＬＳＥ／ＴＲＵＥ）である。ここで、真理値情報が「ＦＡＬＳＥ」の場合は「エラー」でないことを示し、真理値情報が「ＴＲＵＥ」の場合は「エラー」であることを示す。

図１６はステータス情報保存部４０８に登録されている未送信のステータス情報を既に回復しているエラーを除いて、ステータス情報管理部４０９が自動で纏めて送信する処理を示すフローチャートである。図１６に示す処理は、サーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。尚、図１６において、図１２の処理と同一の処理については、同一のステップ番号を付加し、その詳細については省略する。

Ｓ７０５で、サーバ３０１のステータス情報管理部４０９は、ステータス情報保存部４０８より取得したステータス情報と一致する、テーブル１２００のステータス種１２０１に定義されたエラー判断１２０２の真理値がＴＲＵＥであるか否かを判断する。ここで、真理値がＴＲＵＥである場合には、取得したステータス情報はエラーであると判断し、真理値がＦＡＬＳＥである場合には、取得したステータス情報はエラーでないと判断する。判断の結果、取得したステータス情報がエラーでない場合（Ｓ７０５でＮＯ）、Ｓ６０５へ進む。

一方、取得したステータス情報がエラーである場合（Ｓ７０５でＹＥＳ）、Ｓ７０６で、サーバ３０１のステータス情報管理部４０９は、ＭＦＰ１００より最新のステータス情報を問い合わせる。Ｓ７０７で、サーバ３０１のステータス情報管理部４０９は、ＭＦＰ１００への問い合わせによって、ＭＦＰ１００から取得したステータス情報に、ステータス情報保存部４０８より取得したステータス情報が含まれているか否かを判断する。含まれていると判断した場合（Ｓ７０７でＮＯ）、エラーはまだ回復していないと判断して、Ｓ６０５へ進む。一方、含まれていないと判断した場合（Ｓ７０７でＹＥＳ）、エラーは回復していると判断して、Ｓ６０７へ進む。

以上説明したように、実施形態１によれば、リアルタイムコミュニケーションツールにおける通知回数制限を超えるか否かを判断し、超えそうと判断される場合は、複数のステータス情報を纏めて送信する。これにより、ユーザビリティへの制約をなくすことができる。また、ステータス情報を纏めて送信する場合に、既に回復したエラーが存在しているか否かを判断することで、不要なステータス情報の送信を回避することができる。

＜実施形態１の変形例＞
尚、実施形態１では、通知が完了したステータス情報は、ステータス情報保存部４０８が保持するテーブルより削除しているが、これに限定されない。例えば、通知を行っても削除を行わずテーブルに通知の完了の有無を示す情報を追加し、これにより同一のステータス情報が繰り返し通知されることを回避するようにしても良い。また、一度通知したステータス情報を再度通知するような構成に対してテーブルを利用してもよい。また、テーブルに保存されるステータス情報は、サーバ３０１の通知判断部４０５で超えそうと判断された場合に保存するステータス情報に限定されず、受信したステータス情報すべてを保存する構成でもよい。

＜実施形態２＞
実施形態１では、サーバ３０１は、リアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かの判断を、リアルタイムコミュニケーションツールから取得する残りの通知可能回数を利用して行っている。

実施形態２では、サーバ３０１が、通知回数制限を超えそうか否かの判断をサーバ自身で行う構成について説明する。即ち、実施形態２では、リアルタイムコミュニケーションツールへの通知回数をサーバ３０１で記憶、管理しておく。そして、サーバ３０１は、ステータス情報の受信時に、管理している通知回数により通知回数制限を超えるか否かを判断し、超えると判断された場合はデータベースに一時保存し、後で纏めて通知する。これにより、リアルタイムコミュニケーションツールから残りの通知可能回数を取得できない場合においてでも、通知回数制限を超えないように制御することができる。この結果、サーバ３０１は、リアルタイムコミュニケーションツールにおける通知回数制限を超えることなく、ユーザへ通知しなければならないステータス情報の取りこぼしがないようクライアントへ通知することができる。

尚、本実施形態では、ステータス通知のタイミングは、実施形態１と同様に、ＭＦＰ１００からサーバ３０１に印刷完了時にステータス通知を送信する例で説明するが、これに限定されない。実施形態１と同様に、ステータス通知は、例えば、印刷開始前、ステータス変更時等の任意のタイミングで行ってもよい。また、サーバ３０１からＭＦＰ１００へステータス情報を問い合わせるようなポーリング形式で、ステータス通知を行う構成としても良い。

図１７はシステムを構成する各装置のソフトウェア構成図である。

サーバ３０１は、実施形態１と同様に、ステータス通知サービスを実装する。特に、実施形態２では、サーバ３０１は、ステータス通知サービスにより、サーバ３０１自身に記憶している通知回数に基づいて、ステータス情報の通知を制御する。

尚、実施形態２のステータス通知サービスが実現する機能の内、実施形態１の図８のステータス通知サービスが実現する機能と同一の機能については、同一の参照番号を付加して、その詳細については省略する。

通知回数取得部８０４は、通知履歴保存部８１２より、ＭＦＰ１００の通知回数を取得する。通知判断部８０５は、通知回数取得部８０４が取得した通知回数により、リアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かを判断する。ステータス情報管理部８０９は、ステータス情報保存部４０８の管理を行う。通知履歴保存部８１２は、ＳＮＳサーバ３０２への通知履歴を保存する。通知履歴管理部８１３は、通知履歴保存部８１２の管理を行う。タイマコントローラ８１０は、ステータス情報管理部８０９に対してステータス情報保存部４０８の管理指示を一定時間間隔で発行する、もしくは、通知履歴管理部８１３に対して通知履歴保存部８１２の管理指示を一定時間間隔で発行する。

クライアント２５０とＳＮＳサーバ３０２はそれぞれ、実施形態１の図８と同様に、Ｗｅｂブラウザ６０１とＳＮＳアプリケーション７０１を実装する。

図１８のテーブル１３００は、通知履歴保存部８１２が保持する、ＭＦＰ毎の通知履歴情報を保存するテーブルである。ＭＦＰ＿ＩＤ１３０１は、ＭＦＰ毎に割り当てられるＩＤであり、テーブル１３００内でこの値が重複することがなく、テーブル１３００内でＭＦＰの通知履歴情報を検索する際の主キーとなる。通知回数１３０２は、ＳＮＳサーバ３０２への通知回数である。最終通知日時１３０３は、ステータス通知を最後に行った日時である。

図１９はＭＦＰ１００のステータスを、サーバ３０１を介してＳＮＳサーバ３０２へ通知する処理を示すフローチャートである。図１９に示す処理は、ＭＦＰ１００のＣＰＵ１０５がプログラムメモリ１０６に格納されているプログラムをワークメモリ１０７上で実行し、かつサーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。尚、図１９において、図１１の処理と同一の処理については、同一のステップ番号を付加し、その詳細については省略する。

Ｓ８０４で、サーバ３０１の通知回数取得部８０４は、ＭＦＰ１００と一致する、通知履歴保存部８１２が保持するテーブル１３００のＭＦＰ＿ＩＤ１３０１に定義された通知回数１３０２を取得する。Ｓ８０５で、サーバ３０１の通知判断部８０５は、取得した通知回数より、リアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かを判断する。通知回数制限を超えないと判断した場合（Ｓ８０５でＮＯ）、Ｓ８０６で、サーバ３０１のメッセージ作成部４０６は、ＭＦＰ１００から取得したステータス情報によりメッセージの作成を行う。Ｓ５０７の処理を経て、Ｓ８０８で、サーバ３０１の通知履歴管理部８１３は、通知履歴保存部８１２が保持するテーブル１３００のＭＦＰ＿ＩＤ１３０１に定義された通知回数１３０２をインクリメントし、最終通知日時１３０３を更新する。

一方、通知回数制限を超えそうであると判断した場合（Ｓ８０５でＹＥＳ）、Ｓ８０９で、サーバ３０１の通知判断部８０５は、ステータス情報保存部４０８にステータス情報を追加する。

図２０はステータス情報保存部４０８に登録されている未送信のステータス情報を、ステータス情報管理部８０９が自動で纏めて送信する処理を示すフローチャートである。図２０に示す処理は、サーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。尚、図２０において、図１２の処理と同一の処理については、同一のステップ番号を付加し、その詳細については省略する。

尚、リアルタイムコミュニケーションツールにおける残りの通知可能回数は所定のタイミングでリセットされ、その通知可能回数に余裕が生まれる。また、ステータス情報保存部４０８に保存される未送信のステータス情報は、何もしなければ延々蓄積されていき膨大な量となってしまう。そこで、タイマコントローラ８１０の指示によりステータス情報管理部８０９はステータス情報保存部４０８を一定周期で常時監視し、複数の通知を纏めて通知する処理を実行する。

Ｓ９０１で、サーバ３０１のステータス情報管理部８０９は、アカウント情報取得部４０３により、ＭＦＰ１００と一致する、アカウント情報保存部４０２が保持するテーブル１０００のＭＦＰ＿ＩＤ１００１に定義されたＳＮＳアカウント１００２を取得する。Ｓ９０２で、サーバ３０１のステータス情報管理部８０９は、通知回数取得部８０４により、ＳＮＳアカウントのリアルタイムコミュニケーションツールに対する残りの通知可能回数を通知履歴保存部８１２より取得する。

Ｓ９０３で、サーバ３０１のステータス情報管理部８０９は、通知判断部８０５により、通知回数により、ＳＮＳアカウントの通知回数がリアルタイムコミュニケーションツールにおける通知回数制限を超えそうか否かを判断する。通知回数制限を超えそうと判断した場合（Ｓ９０３でＹＥＳ）、処理を終了する。

一方、通知回数制限を超えないと判断した場合（Ｓ９０３でＮＯ）、Ｓ６０４〜Ｓ６０８の処理を実行する。その後、Ｓ９０９で、サーバ３０１のステータス情報管理部８０９は、通知履歴管理部８１３により、通知履歴保存部８１２における通知回数１３０２と最終通知日時１３０３を更新する。

図２１は通知履歴保存部８１２に保存されている通知回数を、通知履歴管理部８１３が自動でリフレッシュする処理を示すフローチャートである。図２１に示す処理は、サーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。

リアルタイムコミュニケーションツールにおける残りの通知可能回数は所定のタイミングでリセットされ、その通知可能回数に余裕が生まれる。そこで、タイマコントローラ８１０の指示により、通知履歴管理部８１３は通知履歴保存部８１２を一定周期で常時監視し、通知回数をリフレッシュする処理を実行する。

Ｓ１００１で、サーバ３０１の通知履歴管理部８１３は、ＭＦＰ１００と一致する、通知履歴保存部８１２が保持するテーブル１３００のＭＦＰ＿ＩＤ１３０１に定義された最終通知日時１３０３を取得する。Ｓ１００２で、サーバ３０１の通知履歴管理部８１３は、最終通知日時から一定時間経過しているか否かを判断する。一定時間経過していないと判断した場合（Ｓ１００２でＮＯ）、処理を終了する。一方、一定時間経過していると判断した場合（Ｓ１００２でＹＥＳ）、Ｓ１００３で、サーバ３０１の通知履歴管理部８１３は、通知履歴保存部８１２が保持するテーブル１３００のＭＦＰ＿ＩＤ１３０１に定義された通知回数１３０２をリフレッシュする。

尚、図２０の処理によってＳＮＳサーバ３０２が実行する処理は、実施形態１と同様であり、また、サーバ３０１のメッセージ合成部４１１によって生成されるメッセージも、図１３や図１４のようになる。

以上説明したように、実施形態２によれば、実施形態１で説明した効果に加えて、リアルタイムコミュニケーションツールへの通知回数をサーバ３０１自身に記憶しておく。これにより、リアルタイムコミュニケーションツールから残りの通知可能回数を取得できない場合でも、ステータス情報の送信を適切に行うことができる。

＜実施形態２の変形例＞
尚、実施形態２においても、実施形態１と同様の変形例を適用できることは言うまでもない。また、実施形態２の構成を、実施形態１の構成と組み合わせてもよい。

＜実施形態３＞
本実施形態のクラウド印刷では、ＭＦＰ１００に入稿される印刷ジョブのキューイングをサーバ３０１が行う。実施形態３では、サーバ３０１がＭＦＰ１００よりステータス通知を受信した際に、入稿されている印刷ジョブの問い合わせを行い、入稿されている印刷ジョブの数が一定数以上であるか否かを判断する。一定数以上である場合、サーバ３０１は、入稿されている印刷ジョブの印刷完了通知の受信を待機し、受信後に纏めて通知することで、通知回数制限を超えないように制御する。

図２２はシステムを構成する各装置のソフトウェア構成図である。

サーバ３０１は、実施形態１と同様に、ステータス通知サービスを実装する。特に、実施形態３では、サーバ３０１は、ステータス通知サービスにより、ＭＦＰ１００からステータス情報を受信し、後述する入稿ジョブ情報取得部９６５が入稿ジョブ管理部９６４に、入稿されている印刷ジョブの問い合わせを行う。そして、印刷ジョブが一定数以上入稿されているか否かを判断する。一定数以上でない場合、サーバ３０１は、ステータス情報よりメッセージを作成してＳＮＳサーバ３０２へ送信する。一方、一定数以上である場合、サーバ３０１は、入稿されている印刷ジョブの完了通知を待機し、纏めて通知する処理を行う。

尚、実施形態３のステータス通知サービスが実現する機能の内、実施形態１の図８のステータス通知サービスが実現する機能と同一の機能については、同一の参照番号を付加して、その詳細については省略する。

入稿ジョブ管理部９６４は、クラウド印刷（インターネット３５０を介して、クライアント２５０から、サーバ３０１を経由して、ＭＦＰ１００への印刷）において入稿される印刷ジョブのキューイングを行う。入稿ジョブ情報取得部９６５は、入稿ジョブ管理部９６４より入稿されている印刷ジョブの情報を取得する。通知判断部９６６は、入稿ジョブ情報取得部９６５が取得した入稿ジョブ管理部９６４に入稿されている印刷ジョブの数が一定数以上であるか否かを判断する。受信待機部９７０は、入稿ジョブ管理部９６４に入稿されている印刷ジョブの完了通知をすべて受信するまでサーバ３０１が行う処理を停止させ、待機させる。

クライアント２５０とＳＮＳサーバ３０２はそれぞれ、実施形態１の図８と同様に、Ｗｅｂブラウザ６０１とＳＮＳアプリケーション７０１を実装する。

図２３はＭＦＰ１００のステータスを、サーバ３０１を介してＳＮＳサーバ３０２へ通知する処理を示すフローチャートである。図２３に示す処理は、ＭＦＰ１００のＣＰＵ１０５がプログラムメモリ１０６に格納されているプログラムをワークメモリ１０７上で実行し、かつサーバ３０１のＣＰＵ２０１がディスク装置２０２に格納されているプログラムをメモリ２０４上で実行することで実現される。尚、図２３において、図１１の処理と同一の処理については、同一のステップ番号を付加し、その詳細については省略する。

Ｓ１１０４で、サーバ３０１の入稿ジョブ情報取得部９６５は、入稿ジョブ管理部９６４より入稿されている印刷ジョブのジョブ数を取得する。Ｓ１１０５で、サーバ３０１の通知判断部９６６は、印刷ジョブの数が一定数以上であるか否かを判断する。Ｓ１１０５で、印刷ジョブの数が一定数以上でない場合（Ｓ１１０５でＮＯ）、Ｓ１１０６で、サーバ３０１のメッセージ作成部４０６は、ステータス情報によりメッセージの作成を行う。

一方、印刷ジョブの数が一定数以上である場合（Ｓ１１０５でＹＥＳ）、Ｓ１１０７で、サーバ３０１の受信待機部９７０は、入稿ジョブ管理部９６４に入稿されている印刷ジョブの完了通知を受信するまで待機する。Ｓ１１０８で、サーバ３０１のメッセージ作成部４０６は、ステータス情報及び完了通知によりメッセージの作成を行う。Ｓ１１０９で、サーバ３０１のメッセージ送信部４０７は、メッセージとアカウント情報をＳＮＳサーバ３０２へ送信する。

尚、図２３の処理によってＳＮＳサーバ３０２が実行する処理は、実施形態１と同様であり、また、サーバ３０１のメッセージ合成部４１１によって生成されるメッセージも、図１３や図１４のようになる。

以上説明したように、実施形態３によれば、リアルタイムコミュニケーションツールへ通知する前に入稿されている印刷ジョブがあるか否かを確認する。そして、印刷ジョブが入稿されている場合、その印刷ジョブの完了通知を待機した上で、ステータス情報を纏めて送信する。即ち複数の通知項目について個別の通知を行うか否かを、通知可能回数により判断しなくても、入稿されている印刷ジョブの数により当該判断を行うことができる。

例えば、多数の印刷ジョブが入稿されている場合、その多数の印刷ジョブに対応する多数の通知項目（例えば「印刷完了」）がその後ＭＦＰから受信されると判断することができる。そこで、その場合に、通知項目「印刷完了」を個別に通知するのではなく、Ｓ１１０８において１つの通知メッセージに纏める。よって、通知可能回数を外部のＳＮＳサーバから取得しなくても、或いはサーバ３０１自身が通知可能回数を管理しなくても、上記判断を適切に行うことができる。また印刷ジョブの管理は、ステータス情報の通知に関わらず行うため、通知可能回数の管理等、通知のための構成を設けなくても、上記判断を適切に行うことができる。

また、同一種類のステータス通知が連続して複数回タイムラインに表示することを軽減するため、ユーザの視認性を向上することができる。さらに、通知するステータスがあることを事前に判断するため、リアルタイムコミュニケーションツールにおける残りの通知可能回数の取得及び判断処理を軽減できる。

＜実施形態３の変形例＞
尚、実施形態３においても、実施形態１と同様の変形例を適用できることは言うまでもない。また、実施形態１及び実施形態２の少なくとも一方の構成を、実施形態１の構成と組み合わせてもよい。

＜実施形態４＞
家電や周辺装置によっては、ステータスの通知が頻繁に行われるものがある。これらの特性によっては、サーバで、通知回数制限を超えると判断された場合のみ、纏めて通知するのではなく、受信したステータスすべてをデータベースに一時保存し後で纏めて通知することで、ユーザビリティへの制約をなくすことができる。

尚、実施形態４の構成を、用途や目的に応じて、実施形態１、実施形態２及び実施形態３の構成と任意の組み合わせることもできる。

＜実施形態５＞
上記実施形態では、ステータス情報の通知条件として、通知サービスの通知可能回数、あるいは、印刷ジョブがＭＦＰ１００に入稿されている数に基づいて、ステータス情報の都度送信あるいは一旦保存後の一括送信を制御しているが、これに限定されない。これらの両方を組み合わせた通知条件や、それ以外の通知条件を利用して、ステータス情報の通知を制御するようにしても良い。

上記実施形態では、サーバ３０１とＭＦＰ１００との間で印刷処理を行う場合のステータス情報の送受信について説明しているが、これに限定されない。例えば、ＭＦＰにおける各種ステータス情報の送受信について、上記各実施形態を適用するにしても良い。例えば、上記実施形態は、ＭＦＰで実現される各種機能（プリンタ機能、スキャナ機能、ストレージ機能、ＦＡＸ機能等）による処理を行う場合のステータス情報の送受信についても適用することができる。

また、上記実施形態では、ＭＦＰ１００に対する制御を行うサーバ３０１と、ＳＮＳサービスを提供するＳＮＳサーバ３０２とが別サーバとして構成されている例を示している。この場合、サーバ３０１のステータス通知サービスによってステータス情報を通知する通知先装置はＳＮＳサーバ３０２となり、その後、ＳＮＳサーバ３０２からステータス情報がクライアント２５０へ送信されることになる。一方で、サーバ３０１とＳＮＳサーバ３０２とが同一のサーバ上で実現することもできる。この場合、サーバ３０１のステータス通知サービスによってステータス情報を通知する通知先装置はクライアント２５０となる。

以上の実施形態によれば、複数のステータス情報（複数の通知項目）が１つの通知メッセージに纏められる。よって、例えば、上記のようにＳＮＳサーバにおいて通知回数に制限があったとしても、その制限内で通知を行うことができる。また、その制限に関わらず、通知回数が少なくなるため、通知を受けたクライアント装置のユーザは、通知内容を容易に認識することができる。特に、通知項目が多数の場合、その多数の通知項目の内容が纏められた内容を含む通知メッセージが作成されるため、ユーザはその内容を容易に認識することができる。

通知メッセージの内容として、上記図１３、図１４を例に説明したが、これに限らない。例えば、印刷完了の通知として、通知対象が１００件ある場合、「印刷が完了しました。（印刷完了時刻）。他に９９件の印刷が完了しました。」等、残りの通知項目の件数を示すメッセージを作成してもよい。或いは、例えば、１０件の印刷ジョブに対して、８件の印刷ジョブについては印刷が完了したが、残り２件の印刷ジョブについてはインクがなくエラーとなった場合がある。この場合に、通知メッセージとして「８件の印刷を完了しました。２件の印刷についてはインクなしによりエラーとなりました。」等、通知項目の種別ごとに件数を表示してもよい。

また、メッセージの合成は１件に合成する場合に限らず、２件以上のメッセージに纏めてもよい。例えば上記の例のように、１０件の印刷ジョブ中、８件の印刷ジョブについては印刷が完了したが、残り２件がエラーとなった場合がある。この場合に、「８件の印刷を完了しました。」とのメッセージと、「２件の印刷についてはインクなしによりエラーとなりました。」とのメッセージを個別に作成してもよい。この場合、通常であれば１０件のメッセージが印刷ジョブごとに作成されるが、上記方法により２件のメッセージで通知が可能なため、通知回数を抑制することができる。

また、以上の実施形態において、サーバ３０１がメッセージ作成処理を実行する例を示したが、これに限定されない。例えば、このサーバ３０１として１台のサーバ装置により処理が実行されてもよいし、複数のサーバ装置を含むサーバシステムが、サーバ３０１として処理を実行してもよい。例えば、図８に示したソフトウェア構成図における各モジュール（４０１〜４１１）のそれぞれを実行するサーバが設けられ、それらのサーバが連携して処理を行ってもよい。

また、以上の実施形態では、ステータス情報として、印刷ジョブに関する情報や、プリンタ等の装置の状態を例に説明したが、これに限定されない。例えば、処理装置の機能として新たな機能が追加された場合に、その機能を示す情報がステータス情報として通知されてもよい。例えば、装置がプリンタの場合、ステープル機能等の印刷の仕上げに関する機能、または印刷ジョブを受信するインタフェース等の通信に関する機能が追加された場合に、当該追加された機能がステータス情報として通知されてもよい。

尚、以上の実施形態の機能は以下の構成によっても実現することができる。つまり、本実施形態の処理を行うためのプログラムコードをシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）がプログラムコードを実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することとなり、またそのプログラムコードを記憶した記憶媒体も本実施形態の機能を実現することになる。

また、本実施形態の機能を実現するためのプログラムコードを、１つのコンピュータ（ＣＰＵ、ＭＰＵ）で実行する場合であってもよいし、複数のコンピュータが協働することによって実行する場合であってもよい。さらに、プログラムコードをコンピュータが実行する場合であってもよいし、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。またはプログラムコードの一部をハードウェアで実現し、残りの部分をコンピュータが実行する場合であってもよい。

２００：情報処理装置、２０１：ＣＰＵ、２０２：ディスク装置、２０３：外部ディスク読取装置、２０４：メモリ、２０５：表示部、２０６：操作部、２０７：ネットワーク通信部、２０８：ネットワーク接続部、

Claims (14)

1. 所定の処理を実行する処理装置に関するステータス情報を取得する取得手段と、
   所定の数より少ない通知項目に対応するステータス情報が前記取得手段により取得された場合、当該通知項目に個別に対応するメッセージを作成し、当該所定の数以上の複数の通知項目に対応するステータス情報が前記取得手段により取得された場合、当該複数の通知項目に基づく内容のメッセージを作成する作成手段と
   を備えることを特徴とする情報処理装置。
2. 前記所定の数は、前記作成手段により作成されたメッセージを通知する通知サービスの通知条件に基づく数である
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記所定の数は、前記通知サービスの通知回数制限に基づく数である
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記通知サービスの通知可能回数を
   前記通知サービスを提供する情報処理装置から取得する第２の取得手段を更に備え、 前記作成手段は、前記第２の取得手段で取得した通知可能回数に基づく前記所定の数に応じてメッセージを作成する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記作成手段により作成されたメッセージを、前記通知サービスを提供する情報処理装置へ送信する送信手段を更に備える
   ことを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
6. 前記通知サービスによる通知履歴を保存する通知履歴保存手段を更に備え、
   前記作成手段は、前記通知履歴保存手段が保存する通知履歴に基づく前記所定の数に応じてメッセージを作成する
   ことを特徴とする請求項２乃至５のいずか１項に記載の情報処理装置。
7. 前記所定の数以上の複数の通知項目に対応するステータス情報が前記取得手段により取得された場合、該ステータス情報を保存する保存手段と、
   前記作成手段は、前記保存手段により保存されたステータス情報に対応する前記複数の通知項目に基づく内容のメッセージを作成する
   ことを特徴とする請求項２乃至６のいずか１項に記載の情報処理装置。
8. 前記取得手段により取得されたステータス情報に対応する通知対象の前記複数の通知項目に、前記処理装置のエラーに関するステータス情報に対応する項目が含まれている場合、当該処理装置に前記エラーが回復しているか問い合わせを行い、前記エラーが回復している場合、当該エラーに対応する項目が含まれていないメッセージを作成する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記作成手段は、前記処理装置により処理されるジョブの数を前記所定の数として前記メッセージを作成する
   ことを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
10. 前記処理装置は、画像を印刷する印刷装置である
    ことを特徴とする請求項１乃至９のいずれか１項に記載の情報処理装置。
11. 前記ステータス情報は、前記処理装置により処理されるジョブまたは該処理装置の状態の少なくとも一方を含む
    ことを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
12. 所定の処理を実行する処理装置に関するステータス情報を取得する取得工程と、
    所定の数より少ない通知項目に対応するステータス情報が前記取得工程において取得された場合、当該通知項目に個別に対応するメッセージを作成し、当該所定の数以上の複数の通知項目に対応するステータス情報が前記取得工程において取得された場合、当該複数の通知項目に基づく内容のメッセージを作成する作成工程と
    を備えることを特徴とする方法。
13. コンピュータを、請求項１乃至１１のいずれか１項に記載の情報処理装置の各手段として機能させるための、または請求項１２に記載の方法をコンピュータに実行させるためのプログラム。
14. 所定の処理を実行する処理装置に関するステータス情報を取得する取得手段と、
    所定の数より少ない通知項目に対応するステータス情報が前記取得手段により取得された場合、当該通知項目に個別に対応するメッセージを作成し、当該所定の数以上の複数の通知項目に対応するステータス情報が前記取得手段により取得された場合、当該複数の通知項目に基づく内容のメッセージを作成する作成手段と、
    前記作成手段により作成されたメッセージを受信する受信手段と、
    を備えることを特徴とする情報処理システム。

Images