(57)【要約】【課題】画像処理装置やクラウドサービスが発した通知のすべてをその都度ユーザに送る方式よりも、ユーザに送られる通知の数を減らす。【解決手段】通知設定記憶部１０６には、連携処理制御部１０２の制御の下で実行される連携処理において複合機１０やサービス３０群で生じたイベントについての通知の種類ごとに、その通知が一括通知の対象か否かを示す通知設定情報が記憶されている。通知制御部１０４は、発生したイベントについての通知が一括通知の対象でなければ、その通知をその連携処理を指示したユーザの登録した通知先に即座に通知する。これに対し、その通知が一括通知の対象であればそれをいったん蓄積する。そして、一括通知の実行タイミングが来ると、蓄積した通知群を１つの通知にまとめて通知先に通知する。【選択図】図１
2020014105.tif 000002
【特許請求の範囲】
【請求項１】
画像処理装置又はネットワーク上の１以上のサービスで生じるイベントに関する通知のうち、一括通知の対象となる通知の種類を記憶する記憶手段と、
ユーザからの指示に応じて、前記画像処理装置及び前記１以上のサービスのうちの１以上が行う処理から構成される連携処理の実行を制御する制御手段と、
前記連携処理の実行において前記画像処理装置又は前記サービスで生じたイベントに関する通知のうち前記一括通知の対象となる種類に該当する通知は蓄積し、蓄積した通知群を前記ユーザに一括して通知する一括通知手段と、
を含む情報処理装置。
【請求項２】
前記一括通知手段は、前記ユーザから実行を指示された連携処理の実行において生じたイベントに関する前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置。
【請求項３】
前記一括通知手段は、予め設定された長さの期間内に前記ユーザから実行を指示された１以上の連携処理の実行において生じた前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置。
【請求項４】
前記一括通知手段は、予め設定された期間内で発せられた前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置。
【請求項５】
前記予め設定された期間として長さが異なる複数の期間があり、
前記記憶手段には、一括通知の対象となる通知の種類のそれぞれが前記複数の期間のいずれに該当するかを示す情報が更に記憶され、
前記一括通知手段は、前記複数の期間のそれぞれについて、当該期間に対応する種類の通知を蓄積し、当該期間に蓄積した通知群を一括して通知する、請求項４に記載の情報処理装置。
【請求項６】
コンピュータを、
画像処理装置又はネットワーク上の１以上のサービスで生じるイベントに関する通知のうち、一括通知の対象となる通知の種類を記憶する記憶手段、
ユーザからの指示に応じて、前記画像処理装置及び前記１以上のサービスのうちの１以上が行う処理から構成される連携処理の実行を制御する制御手段、
前記連携処理の実行において前記画像処理装置又は前記サービスで生じたイベントに関する通知のうち前記一括通知の対象となる種類に該当する通知は蓄積し、蓄積した通知群を前記ユーザに一括して通知する一括通知手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
プリンタ、スキャナ、ファクシミリ装置、複合機（プリンタ、スキャナ、ファクシミリ装置等の機能を併せ持つ装置）等の画像処理装置が、インターネット等のネットワークに接続されることが多くなっている。また、画像処理装置の持つ機能とネットワーク上のサービスとを連携させることで、画像処理装置のユーザに、画像処理装置単体では提供できない高度な処理機能を提供することも行われている。
【０００３】
例えば特許文献１には、指示書と呼ばれるデータに従って、複合機の各種機能とネットワーク上の各種サービス（サーバ）を連携させるシステムが開示されている。指示書には、複合機の各種機能やネットワーク上の各種サービスが実行する処理のフローが記述されている。指示書には、例えば複合機でスキャンした文書の画像をネットワーク上のＯＣＲ（光学文字認識）サービスでテキストデータに変換し、得られたテキストデータを翻訳サービスで特定の言語に翻訳し、翻訳結果のデータをファイル共有サービスの特定フォルダに格納する、といった一連の処理のフローが記述される。システムには例えば連携を管理するサーバが設けられており、そのサーバの指示書に従って複合機やネットワーク上のサービスに処理を実行させ、その処理の結果を受け取って、その指示書に示される次の処理にその処理結果を受け渡す。
【０００４】
このように画像処理装置やネットワーク上の複数のサービスが連携する処理では、画像処理装置や各サービスがそれぞれ、実行した処理の正常終了を示す通知や各種のエラー通知等、依頼された処理に対して様々な通知を発する。指示書に示される一連の処理を担当する画像処理装置や各サービスに関する通知の数は膨大なものとなる可能性がある。また、複数の指示書の実行をまとめて指示した場合には、指示書の数に応じて通知の数も増えてくる。
【０００５】
また、処理中に発生したエラーその他のイベントを電子メール等の通知手段によりその処理を指示したユーザに通知するシステムも知られている。ユーザは、その通知に応じて、例えばエラー原因を解決するための作業を行う等のことが可能になる。
【０００６】
例えば特許文献２に開示される中継装置（情報処理装置）の記憶手段は、クラウドサービスを利用する利用者の認証情報と、利用者毎にクラウドサービスへのデータの格納が失敗した場合の対応情報とを記憶する。受信手段は、画像処理装置から前記利用者の認証情報、クラウドサービスへの格納対象となるデータ及びクラウドサービスへの格納要求を受信する。送信手段は、クラウドサービスへの格納要求に応じて、前記利用者の認証情報と、クラウドサービスへの格納対象となるデータとをクラウドサービスに送信する。第２の送信手段は、クラウドサービスへのデータの格納に失敗した場合には、前記対応情報を参照して、対応方法を前記利用者に送信する。
【０００７】
この他に、複数のサービスからの通知をユーザに分かりやすく提示することを狙った情報システムとして、特許文献３に示されるものがある。この情報システムは、ユーザが複数のクラウドサーバーのそれぞれについて保有するアカウントを示すアカウント情報を管理する情報管理部と、ユーザがログインしたときに、複数のクラウドサーバーのそれぞれからユーザによる利用の状況を示す利用情報を取得する取得部と、利用情報によって示されるユーザによる複数のクラウドサーバーのそれぞれの利用の状況を、当該ユーザがログインに際して操作した機器に備わるディスプレイに一覧表示させるユーザインタフェース部と、を備える。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１５−２７０９９号公報
【特許文献２】特開２０１７−０４５０９９号公報
【特許文献３】特許第５８５３９９６号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００９】
画像処理装置やネットワーク上のサービスが発した通知をその都度ユーザに送る方式は、通知がすぐにユーザに伝達されるという利点はあるが、通知の数が多くなると、通信トラフィックを増大させたり、個々の通知が見落とされやすくなったりする場合がある。
【００１０】
本発明は、画像処理装置やクラウドサービスが発した通知のすべてをその都度ユーザに送る方式よりも、ユーザに送られる通知の数を減らすことができる方式を提供する。
【課題を解決するための手段】
【００１１】
請求項１に係る発明は、画像処理装置又はネットワーク上の１以上のサービスで生じるイベントに関する通知のうち、一括通知の対象となる通知の種類を記憶する記憶手段と、ユーザからの指示に応じて、前記画像処理装置及び前記１以上のサービスのうちの１以上が行う処理から構成される連携処理の実行を制御する制御手段と、前記連携処理の実行において前記画像処理装置又は前記サービスで生じたイベントに関する通知のうち前記一括通知の対象となる種類に該当する通知は蓄積し、蓄積した通知群を前記ユーザに一括して通知する一括通知手段と、を含む情報処理装置である。
【００１２】
請求項２に係る発明は、前記一括通知手段は、前記ユーザから実行を指示された連携処理の実行において生じたイベントに関する前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置である。
【００１３】
請求項３に係る発明は、前記一括通知手段は、予め設定された長さの期間内に前記ユーザから実行を指示された１以上の連携処理の実行において生じた前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置である。
【００１４】
請求項４に係る発明は、前記一括通知手段は、予め設定された期間内で発せられた前記一括通知の対象に該当する通知群を一括して通知する、請求項１に記載の情報処理装置である。
【００１５】
請求項５に係る発明は、前記予め設定された期間として長さが異なる複数の期間があり、前記記憶手段には、一括通知の対象となる通知の種類のそれぞれが前記複数の期間のいずれに該当するかを示す情報が更に記憶され、前記一括通知手段は、前記複数の期間のそれぞれについて、当該期間に対応する種類の通知を蓄積し、当該期間に蓄積した通知群を一括して通知する、請求項４に記載の情報処理装置である。
【００１６】
請求項６に係る発明は、コンピュータを、画像処理装置又はネットワーク上の１以上のサービスで生じるイベントに関する通知のうち、一括通知の対象となる通知の種類を記憶する記憶手段、ユーザからの指示に応じて、前記画像処理装置及び前記１以上のサービスのうちの１以上が行う処理から構成される連携処理の実行を制御する制御手段、前記連携処理の実行において前記画像処理装置又は前記サービスで生じたイベントに関する通知のうち前記一括通知の対象となる種類に該当する通知は蓄積し、蓄積した通知群を前記ユーザに一括して通知する一括通知手段、として機能させるためのプログラムである。
【発明の効果】
【００１７】
請求項１又は６に係る発明によれば、画像処理装置やクラウドサービスが発した通知のすべてをその都度ユーザに送る方式よりも、ユーザに送られる通知の数を減らすことができる。
【００１８】
請求項２に係る発明によれば、１つの連携処理の中で生じた通知のうち一括通知対象のものをまとめて通知することができる。
【００１９】
請求項３に係る発明によれば、ある長さの期間内に実行が指示された複数の連携処理の中で生じた通知のうち一括通知対象のものをまとめて通知することができる。
【００２０】
請求項４に係る発明によれば、ある期間に生じた通知のうち一括通知対象のものをまとめて通知することができる。
【００２１】
請求項５に係る発明によれば、通知の種類ごとに一括通知の期間を変えることができる。
【図面の簡単な説明】
【００２２】
【図１】実施形態のシステム構成を例示する図である。
【図２】通知設定情報を例示する図である。
【図３】通知モード等の設定のためのＵＩ画面を例示する図である。
【図４】新たな連携処理が開始されたときの通知制御部の処理手順を例示する図である。
【図５】ユーザに送るべき通知が生じたときの通知制御部の処理手順を例示する図である。
【図６】通知制御部が蓄積した通知群を一括通知する処理の手順を例示する図である。
【図７】変形例における通知設定情報を例示する図である。
【図８】変形例においてユーザに送るべき通知が生じたときの通知制御部の処理手順を例示する図である。
【発明を実施するための形態】
【００２３】
図１に、本発明の実施形態である情報処理装置を含んだシステムの構成を例示する。このシステムは、画像処理装置の一例としての複合機１０と、この複合機１０に対してインターネット等のネットワーク２０を介して接続された複数のサービス３０とを含んでいる。便宜上、それらネットワーク２０上の各サービス３０を、サービスＡ、サービスＢ、・・・と名付けて識別する。サービスＡ、Ｂ、・・・は、複合機１０の制御部１００内に構築されている連携処理制御部１０２からの指示に応じて情報処理サービスを実行する。例えばサービスＡはＯＣＲ（光学文字認識）サービス、サービスＢは翻訳サービス、サービスＣはファイル共有サービス、等のように、様々なサービス３０が存在する。それらサービス３０は、いわゆるクラウドコンピューティングシステムとして構成されたものであってもよい。
【００２４】
例えば特許文献１に開示される指示書に基づく連携処理スキーム等の連携処理技術を用いて、複合機１０の持つ機能とそれらネットワーク２０上のサービス３０群とを連携させることで、多様な連携サービスが実現される。
【００２５】
複合機１０は、制御部１００、スキャナ１１０、プリンタ１１２等の機能要素を含んでいる。スキャナ１１０は、紙等の媒体上の原稿画像を光学的に読み取り、画像データへと変換する装置である。プリンタ１１２は、印刷データが表す画像を媒体上に印刷する装置である。スキャナ１１０で読み取られた画像をプリンタ１１２で印刷することで、複合機１０のコピー機能が実現される。複合機１０は、この他にファクシミリ機能等の他の機能を担う装置を内蔵していてもよい。
【００２６】
制御部１００は、複合機１０の動作を制御する装置である。この制御の多くの部分はソフトウエアとして実装されており、制御部１００は、そのソフトウエアを実行する計算資源（ＣＰＵ、メモリ、二次記憶等）を有している。この計算資源を用いて、複合機１０のネイティブ機能（スキャン、印刷、コピー等）の制御以外の各種の情報処理が実現される。そのような情報処理の例として、制御部１００は、連携処理制御部１０２、通知制御部１０４、各種のアプリ１０８を備える。
【００２７】
連携処理制御部１０２は、複合機１０のネイティブ機能、複合機１０の制御部１００の計算資源を用いて実行される各種のアプリ１０８、及びネットワーク２０上のサービス３０群、のうちの一以上を連携させることで構成される連携処理の実行を制御する。この連携処理の制御は、例えば、特許文献１等に示される本願出願人の「指示書」ベースの連携処理スキームに準拠したものでよい。
【００２８】
アプリ１０８は、制御部１００の計算資源により実行されるアプリケーションソフトウエアであり、その処理内容には特に限定はない。制御部１００には複数のアプリ１０８がインストール可能である。アプリ１０８の中には、例えばネットワーク２０上のサーバからのダウンロードにより制御部１００にインストールされたものが含まれていてもよい。
【００２９】
通知制御部１０４は、連携処理の実行の際に生じたイベントに関する通知についての制御を行う。連携処理の実行中に、その連携処理を構成する個々の単位処理において各種のイベントが生じる。単位処理は、例えばスキャナ１１０によるスキャン処理、ネットワーク２０上のＯＣＲサービスによるＯＣＲ処理、等のように、複合機１０や各サービス３０が単体で提供する機能による処理である。また、このようなイベントとしては、例えば、当該単位処理の正常終了やその他の正常な処理ステータスの遷移、当該単位処理における各種のエラーの発生等がある。エラーには、単位処理の遂行が不可能になる深刻なエラーから、単位処理の遂行には支障が無い軽微なエラー（警告レベルのもの）まで、何段階かのものがあってもよい。
【００３０】
通知制御部１０４が送信する通知は、発生したイベントに関する情報を示す。イベントに関する情報は、例えばそのイベントが発生したこと自体を示す情報、そのイベントについてのある程度詳しい説明、そのイベントに対してユーザが行うべき対処に関する情報、等のうちの一以上である。大まかな分類でいえば、通知制御部１０４が行う通知には、例えば、連携処理の正常終了又は異常終了を知らせる通知、ユーザが事前に複合機１０に積立（デポジット）済みの金額の連携処理の終了後の残額（デポジット残額）を知らせる通知、連携処理を構成する個々の単位処理の正常終了等の正常ステータスやエラー発生を知らせる通知、エラー発生により遂行不能となった単位処理に対するリカバリ方法を案内する通知（リカバリ案内）等がある。リカバリ案内の通知は、例えば、遂行不能となった単位処理の再実行（リトライ）やその単位処理に対する代替処理を知らせる内容を含む。代替処理の情報には、例えば代替処理を提供するサービス３０のＵＲＬ（Uniform Resource Locator）等が含まれる。特許文献２のシステムがユーザに通知する「対応情報」はリカバリ案内通知の一例である。
【００３１】
通知制御部１０４が通知を送信する宛先は、典型的には、その通知の対象である連携処理の実行を指示したユーザである。ユーザごとに、そのユーザが実行を指示した連携処理に関する通知の宛先が登録され、その宛先は例えばそのユーザにより設定、あるいは変更が可能である。
【００３２】
例えば、ユーザが複数の指示書の実行を短時間の間に続けて指示した場合には、通知制御部１０４からユーザに送られる通知の数も多くなる。また、この場合、ネットワーク２０上のサービス３０ごとに処理の所要時間やその時々の負荷状況が異なるため、それら複数の指示書の連携処理に関する通知がユーザに届くタイミングにかなり大きなばらつきが生じることが少なくない。通知の多さや、通知の到来時刻のばらつきは、ユーザが通知を見落とす大きな要因となる。また、通知の数が多いことは、通信トラフィックの増大を招く。
【００３３】
そこで、通知制御部１０４は、複数の通知をまとめてユーザに通知する一括通知（以下では「まとめて通知」とも呼ぶ）機能を提供する。一括通知により、ユーザに届く通知の数が減る。
【００３４】
ここで、一括通知機能により一括して通知される通知内容の中には、その通知の対象となるイベントの発生からかなり時間の経った、いわば鮮度が低い内容が含まれることになる。ユーザにとって鮮度があまり重要でない通知内容については、このような一括通知を適用しても問題は少ない。しかし、ユーザの緊急対応を求める通知のように鮮度が重要な通知内容も存在し、このような通知内容を一括通知に含めることは不適切である。
【００３５】
そこで、本実施形態では、各通知が一括通知の対象となるか否かを示す情報を含んだ通知設定情報を、通知設定記憶部１０６に持たせる。通知設定情報は、ユーザによらず共通のものとしてもよいが、ユーザごとにそれぞれ個別に設定可能としてもよい。後者の場合、通知設定情報は、複合機１０に登録されたユーザのユーザＩＤ（識別情報）に対応付けて、通知設定記憶部１０６に記憶される。
【００３６】
図２に、通知設定情報の具体例を示す。この例では、通知設定情報は、個々の通知ごとに、その通知の種別、通知内容、及び通知モードの項目を含む。
【００３７】
種別は、その通知が正常系又は異常系のどちらに該当するかを示す情報である。正常系の通知とは、その通知の原因となったイベントが、複合機１０又はサービス３０が正常に処理を行っている又は行った場合に生じるものである場合の通知である。連携処理や個々の単位処理の正常終了の通知、デポジット残額の通知等が正常系の通知の一例である。逆に異常系の通知とは、その通知の原因となったイベントが、複合機１０又はサービス３０の異常により生じるものである場合の通知である。連携処理や個々の単位処理のエラーの通知、リカバリ案内の通知等が異常系の通知の一例である。なお、正常系または異常系の種別を更に細分化してもよい。
【００３８】
通知内容は、当該通知の内容を示す情報である。通知内容には、その通知のメッセージ内容等のテンプレートや、その通知の識別情報等が含まれていてもよい。
【００３９】
通知モードは、当該通知が一括通知（「まとめて通知」）の対象であるか否か等、当該通知の方式を示す情報である。通知モードの値が「まとめて通知」である通知は、一括通知の対象である。またこの例では、一括通知の対象でない通知の通知モードは、即時通知又は非通知のいずれかである。即時通知は、当該通知が発生したときに、他の通知とまとめることなく、当該通知を可及的速やかに通知するモードである。非通知は、当該通知をユーザに送信しないことを示すモードである。
【００４０】
一般的には、正常系の通知はユーザによる緊急の対処を必要としないのに対し、異常系の通知はユーザの緊急の対処を要するものが少なくない。したがって、通知モード設定の単純な例として、正常系の通知は「まとめて通知」、異常系の通知は即時通知と設定してもよい。例えば、異常系の一例である「リカバリ案内」の通知は、エラーが生じているサービス３０について例えば代替サービスの利用を案内するものであり、この通知に応じてユーザが代替サービスの利用を指示すると、そのエラーにより中断している連携処理が再開される。このような通知は即時に行うことで、連携処理の再開が早まる。また、連携処理に含まれる単位処理を担うサービス３０が課金を行うものである場合において、ユーザが複合機１０等にデポジットした金額がそのサービス３０の課金額に満たない場合、そのサービス３０がその単位処理を実行しなかったり、その課金額が支払われるまでその単位処理の結果を連携処理制御部１０２側に渡さなかったりすることがある。このような場合、連携処理はそこでいったん中断される。この種のエラーが生じた場合、料金不足を知らせる通知をユーザに送り、この通知に応じてユーザがデポジットを増額する操作を行うことで、中断された連携処理が再開可能となる。このような料金不足の通知は、即座にユーザに送った方が、連携処理の再開を早める助けとなる。
【００４１】
また、異常系の通知の中には、ユーザに緊急の対応を求めるもの（あるいは早く対応するほどユーザの利益が大きくなるもの）だけでなく、緊急の対応が不要なものも存在する。例えば、連携処理内の単位処理を担うサービス３０がメンテナンス中であったり深刻な障害が発生していたりすると共に、そのサービス３０に対して代替処理となる別のサービス３０が登録されていない場合、ユーザ側がすぐに対応を行ってもその時点ではその連携処理を再開することはできない。このような状況を知らせる通知は、異常系の通知ではあるが、緊急性は低いので、一括通知の対象としてよい。
【００４２】
また逆に、正常系の通知の中にも、ユーザにとってなるべく早く取得したいものもあり得る。例えば、ユーザが、ある指示書が規定する連携処理の結果がでたことをなるべく早く知りたい場合には、その連携処理の正常終了を示す通知は一括通知ではなく即時通知とした方がよい。そこで、図２の例では、通知ごとに通知モードを設定可能としている。
【００４３】
また、この通知ごとの通知モードは、ユーザが設定及び変更できるようにしている。制御部１００は、通知モード等の設定のためのＵＩ（ユーザインタフェース）画面を提供する。図３にこのＵＩ画面２００の例を示す。このＵＩ画面２００には、通知先入力欄２０２と、通知モード入力欄２０４とが含まれる。通知先入力欄２０２は、通知制御部１０４からの通知の宛先の情報を入力する欄であり、図示例では宛先として電子メールアドレスの入力を受け付ける。通知モード入力欄２０４には、通知項目ごとに、その通知項目を当該ユーザに通知するか否か（「通知する？」）を入力するボックスと、その通知を「まとめて通知」（一括通知）の対象とするか否かを入力するボックスが示される。図示例では、「リカバリ案内」は、通知の対象に選択されているが、一括通知の対象には指定されていない。したがって、「リカバリ案内」の通知は、即時通知の対象となる。この画面で設定された通知先や通知モードの情報を含む通知設定情報は、当該ユーザのユーザＩＤに対応付けて通知設定記憶部１０６に保持される。
【００４４】
次に、図４〜図６を参照して、通知制御部１０４の処理手順を例示する。
【００４５】
図４に示すように、通知制御部１０４は、連携処理制御部１０２が新たな連携処理を開始すると、その連携処理の識別情報（連携処理ＩＤと呼ぶ）を連携処理制御部１０２から取得する。そして、その連携処理ＩＤを、その連携処理の実行を指示したユーザのユーザＩＤに対応付けて記憶する（Ｓ１０）。連携処理の指示を行うにあたりユーザは複合機１０（あるいは連携処理制御部１０２）にログインしており、ユーザＩＤは特定されているものとする。なお、連携処理ＩＤとユーザＩＤの対応付けを連携処理制御部１０２で行っている場合は、通知制御部１０４はＳ１０の処理を行わなくてよい。
【００４６】
次に通知制御部１０４は、そのユーザＩＤに対応付けて一括通知ＩＤが設定済みであるかどうかを判定する（Ｓ１２）。一括通知ＩＤは、そのユーザに対して一括して通知する通知群をグループ化するために用いる識別情報である。同じ一括通知ＩＤに対応付けて蓄積された通知は、一括してユーザに通知される。
【００４７】
すなわち、この例では、ユーザからほぼ同じ時期に実行が指示された一群の連携処理の実行の過程で発生した、一括通知の対象に該当する通知を一括して通知する。ここで「ほぼ同じ時期」とは、例えば（１）ユーザが複合機１０（又は連携処理制御部１０２）にログインしてからログアウトするまでの期間、（２）ユーザが最初の連携処理を指示した時点から所定の（すなわち予め定められた）長さの期間、（３）ユーザが最初の連携処理を指示してから互いの時間間隔が所定長さ以内で連続して連携処理が指示されている間、等である。ここで「最初の連携処理」とは、前回の一括通知に係る一群の連携処理のあとに最初に指示された連携処理である。このように「ほぼ同じ時期」に指示された連携処理に関連するものであることを示す情報として、一括通知ＩＤを用いる。ユーザＩＤに対応付けて設定された一括通知ＩＤは、その「ほぼ同じ時期」が終了したと判定されたときに、その対応付けを解除される（この点については後で図６を参照して説明する）。
【００４８】
Ｓ１２の判定結果がＮｏの場合、通知制御部１０４は、一意な一括通知ＩＤを新たに生成し、その一括通知ＩＤをそのユーザＩＤに対応付けて設定する（Ｓ１４）。そして、通知制御部１０４は、Ｓ１０で取得した連携処理ＩＤをその一括通知ＩＤに対応付けて記憶する（Ｓ１６）。Ｓ１２の判定結果がＹｅｓの場合、通知制御部１０４は、ユーザＩＤに対応付けて既に設定されている一括通知ＩＤに対応付けて、その連携処理ＩＤを記憶する（Ｓ１６）。
【００４９】
また通知制御部１０４は、実行中の１以上の連携処理のいずれかに関して、ユーザに送るべき通知が発生した場合、図５に例示する処理を実行する。ここで、連携処理を構成する単位処理を実行している複合機１０の制御プログラムやアプリ１０８又はサービス３０は、正常系のイベント（例えば単位処理の正常終了やその単位処理についての課金処理の完了）又は異常系のイベント（各種のエラー等）が発生すると、そのイベントを知らせる通知を連携処理制御部１０２に送る。通知制御部１０４は、それら複合機１０の制御プログラム又はアプリ１０８又はサービス３０からの通知に応じて、ユーザに送るべき通知を生成する。サービス３０等からどのような通知を受けた場合に、通知制御部１０４がユーザに対してどのような通知を行うかは、予め規定されている。例えば、課金完了の通知（この通知には例えば引き落とした課金額の情報が含まれる）をサービス３０から受け取った場合、通知制御部１０４は、デポジット残額を知らせる通知を生成する。
【００５０】
このようにユーザへの通知を生成した場合、通知制御部１０４は、その通知の対象である連携処理のＩＤを取得し（Ｓ２０）、その連携処理ＩＤに対応づけられているユーザＩＤ及び一括通知ＩＤを特定する（Ｓ２２）。次に通知制御部１０４は、そのユーザＩＤに対応する通知設定情報を通知設定記憶部１０６から取得する（Ｓ２４）。そして通知制御部１０４は、今回生成した通知が一括通知の対象か、即時通知の対象か（それとも非通知か）を、Ｓ２４で取得した設定通知情報（図２参照）に基づき判定する（Ｓ２６）。この判定の結果が一括通知の場合は、通知制御部１０４は、その通知の情報をＳ２２で特定した一括通知ＩＤに対応付けて蓄積する（Ｓ２８）。Ｓ２６の判定結果が即時通知の場合は、通知制御部１０４は、その通知を、Ｓ２２で特定したユーザＩＤに対応して設定された通知先のアドレスに対して送信する（Ｓ２９）。
【００５１】
図６に、一括通知を送信するための制御の手順を例示する。この手順では、通知制御部１０４は、ユーザＩＤに対応付けられている一括通知ＩＤに対応する蓄積終了トリガの発生を監視する（Ｓ３０）。蓄積終了トリガは、その一括通知ＩＤに対応付けて、対象の通知を蓄積する期間の終了を示すトリガイベントである。ユーザがログインしてからログアウトするまでに実行を指示した１以上の連携処理に関する通知を一括して行う方式（上述の（１））では、蓄積終了トリガは、ユーザが複合機１０（又は連携処理制御部１０２）からログアウトしたことである。また、上述の方式（２）を用いる場合は、ユーザが最初の連携処理を指示した時点から所定の長さの期間が経過したことが蓄積終了イベントである。この場合、通知制御部１０４は、ユーザが最初の連携処理を指示した時刻を例えば一括通知ＩＤに対応付けて記憶し、この時刻と現在時刻との比較により、その期間が経過したかどうかを判定する。また、上述の方式（３）を用いる場合は、そのユーザが最後に連携処理の実行指示を行った時点から所定の長さの期間が経過したことが、蓄積終了トリガである。なお、以上に例示した方式やそれに対応する蓄積終了トリガはあくまで例示的なものにすぎない。
【００５２】
ある一括通知ＩＤに対応する蓄積終了トリガが発生したことが検知されると（Ｓ３０の判定結果がＹｅｓ）、通知制御部１０４は、その一括通知ＩＤとユーザＩＤの対応付けを解除する（Ｓ３２）。この時点以降に同じユーザが連携処理の実行を指示した場合、その連携処理に関する通知は、その一括通知ＩＤには対応付けられず、別の新たな一括通知ＩＤに対応付けて管理されることとなる。
【００５３】
次に通知制御部１０４は、その一括通知ＩＤに対応付けられたすべての連携処理ＩＤに対応する連携処理が終了しているかどうかを判定する（Ｓ３４）。通知制御部１０４は、Ｓ３４の判定結果がＹｅｓになるまで待つ。
【００５４】
Ｓ３４の判定結果がＹｅｓになると、通知制御部１０４は、その一括通知ＩＤに対応付けて蓄積しているすべての通知の通知内容を合わせて１つの通知情報を生成し（Ｓ３６）、その通知情報を、Ｓ３２の対応付け解除の前にその一括通知ＩＤに対応付けられていたユーザＩＤに対応して設定されている通知先に対して送信する（Ｓ３８）。
【００５５】
図４〜図６の手順の説明では、ユーザがほぼ同時に実行を指示した複数の連携処理に関する通知を一括通知する場合を例にとって説明したが、図４〜図６の手順は、１つの連携処理の中で発生した通知群を一括通知する場合にも適用可能である。すなわち、図６の手順のＳ３０において、図４の手順で開始が検知された連携処理の実行が完了したことを蓄積終了トリガとすれば、１つの連携処理の中で生じた通知群を一括通知する手順となる。
【００５６】
次に、上記実施形態の変形例を説明する。この変形例では、一括通知を定期的に実行する。例えば、一括通知対象の通知は１日単位で蓄積し、毎日１回、ユーザが設定した時刻に１つにまとめて通知する等である。
【００５７】
また、定期的な一括通知を複数種類用意してもよい。例えば１日１回の一括通知１と、９時、１２時、１５時の１日３回の一括通知２とを用意する等である。図７にこの例における通知設定情報の例を示す。この例では、連携処理の正常終了やデポジット残額の通知は毎日９時に１日分をまとめて通知（「まとめて通知１」）する。また、連携処理の異常終了（代替サービス等によるリカバリが困難なケース）やサービスＡの正常終了等の通知は、９時、１３時、１７時に、前回一括通知からその時刻までに蓄積された通知をまとめて通知（「まとめて通知２」）する。
【００５８】
この変形例において、通知制御部１０４は、実行中の１以上の連携処理のいずれかに関して、ユーザに送るべき通知が発生した場合、図８に例示する処理を実行する。
【００５９】
図８の手順では、通知制御部１０４は、複合機１０やサービス３０からの通知に応じてユーザへの通知を生成した場合、その通知の対象である連携処理のＩＤを取得し（Ｓ４０）、その連携処理ＩＤに対応づけられているユーザＩＤを特定する（Ｓ４２）。次に通知制御部１０４は、そのユーザＩＤに対応する通知設定情報（図７）を通知設定記憶部１０６から取得する（Ｓ４４）。そして通知制御部１０４は、今回生成した通知の通知モードが「まとめて通知１」、「まとめて通知２」、即時通知のいずれに該当するかをその設定通知情報に基づき判定する（Ｓ４６）。この変形例では、通知制御部１０４は、ユーザごとに「まとめて通知１」用の蓄積領域と「まとめて通知２」用の蓄積領域を用意している。そして、Ｓ４６の判定の結果が「まとめて通知１」の場合は、通知制御部１０４は、その通知の情報をそのユーザのＩＤに対応する「まとめて通知１」の蓄積領域に蓄積し（Ｓ４８）、「まとめて通知２」の場合は、その通知の情報をそのユーザのＩＤに対応する「まとめて通知２」の蓄積領域に蓄積する（Ｓ５０）。また判定結果が即時通知の場合は、その通知をそのユーザＩＤに対応する通知先に通知する（Ｓ５２）。
【００６０】
また、この変形例での、蓄積した通知情報の一括通知のための通知制御部１０４の処理は、例えば以下のようなものでよい。すなわち、通知制御部１０４は、あるユーザＩＤに対応する「まとめて通知１」又は「まとめて通知２」の各モードについてそれぞれ定められた定期的な通知のタイミング（例えば前者における午前９時。図７参照）が到来するのを待つ。あるユーザについてのあるモードについての定期的な通知のタイミングが到来すると、通知制御部１０４は、その時点で当該モードの蓄積領域に蓄積されている通知群を１つにまとめた通知情報を生成し、その通知情報をそのユーザが登録している通知先に送信する。また、通知制御部１０４は、その蓄積領域からそれら通知を削除し、その蓄積領域を空にする。
【００６１】
以上、本発明の実施形態及び変形例を説明したが、これらはあくまで例示的なものにすぎない。上記実施形態及び変形例では、連携処理制御部１０２、通知制御部１０４及び通知設定記憶部１０６が複合機１０内に設けられたが、これらの機能モジュールは、複合機１０とは別に、ネットワーク上のサーバ上に設けてもよい。この場合、連携処理制御部１０２と、通知制御部１０４及び通知設定記憶部１０６とは、同一のサーバ上に設けてもよいし、別々のサーバ上に設けてもよい。
【００６２】
以上に例示した制御部１００は、例えば、複合機１０に内蔵されるコンピュータ、又は単体のコンピュータに、それら各機能モジュールの機能を表すプログラムを実行させることにより実現してもよい。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【００６３】
１０  複合機、２０  ネットワーク、３０  サービス、１００  制御部、１０２  連携処理制御部、１０４  通知制御部、１０６  通知設定記憶部、１０８  アプリ、１１０  スキャナ、１１２  プリンタ。
【図１】
2020014105.tif 000003
【図２】
2020014105.tif 000004
【図３】
2020014105.tif 000005
【図４】
2020014105.tif 000006
【図５】
2020014105.tif 000007
【図６】
2020014105.tif 000008
【図７】
2020014105.tif 000009
【図８】
2020014105.tif 000010