JP2019212250A - 処理装置、および、コンピュータプログラム - Google Patents

Abstract

【課題】特定の情報処理の過程で発生するイベントに応じて、適切な報知を行う。【解決手段】処理装置は、サーバから、第１の報知情報を受信し、第１の報知情報を第１の格納部に格納し、特定の情報処理の過程で発生する第１のイベントであってユーザへの情報を報知すべき第１のイベントが発生した場合に、第１のイベントに対応する第１の報知情報が第１の格納部に格納されているか否かを判断し、該第１の報知情報が第１の格納部に格納されている場合に、該第１の報知情報を用いて、ユーザへ情報を報知し、該第１の報知情報が第１の格納部に格納されていない場合に、第２の格納部に格納されている第２の報知情報を用いて、ユーザへ情報を報知する。【選択図】 図８

Description

本明細書は、特定の情報処理の過程で発生するイベントに応じてユーザへ情報を報知する技術に関する。

特許文献１に開示された技術では、サーバは、複数個の端末からアプリケーションのエラー情報と端末情報とを受信し、アプリケーションがエラーを起こす条件を判定する。サーバは、アプリケーションがエラーを起こす条件を満たす端末に、その旨を通知する。通知を受信した端末は、当該アプリケーションのアイコンとして、所定のエフェクトを加えたアイコンを表示し、通知を受信しない端末は、当該アプリケーションのアイコンとして、通常のアイコンを表示する。

特開２０１４−５２８６７号公報 特開２００６−２４３９１１号公報

しかしながら、上記技術では、アプリケーションの実行の過程における報知については何ら工夫がなされていなかった。また、単に、サーバからの通知に応じて、アイコンを切り替えているに過ぎなかった。このために、特定の情報処理（例えば、アプリケーションの実行処理）の過程で発生するイベントに応じて、適切な報知を行うことができない可能性があった。

本明細書は、特定の情報処理の過程で発生するイベントに応じて、適切な報知を行うことができる技術を開示する。

本明細書に開示された技術は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の適用例として実現することが可能である。

［適用例１］特定の情報処理を実行する処理装置のためのコンピュータプログラムであって、サーバから、第１の報知情報を受信する受信機能と、前記サーバから受信した前記第１の報知情報を第１の格納部に格納する格納処理機能と、前記特定の情報処理の過程で発生する第１のイベントであって、ユーザへ情報の報知を行うべき前記第１のイベントが発生した場合に、前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されているか否かを判断する判断機能と、前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されている場合に、前記第１のイベントに対応する前記第１の報知情報を用いて、ユーザへ情報を報知する第１の報知機能と、前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されていない場合に、第２の格納部に格納されている第２の報知情報であって前記第１のイベントに対応する前記第２の報知情報を用いて、ユーザへ情報を報知する第２の報知機能と、を前記処理装置に搭載されたコンピュータに実現させ、前記第２の報知情報は、前記第１の報知情報が前記第１の格納部に格納されるよりも前に前記第２の格納部に格納される、コンピュータプログラム。

なお、本明細書に開示される技術は、種々の形態で実現することが可能であり、例えば、端末装置、特定の情報処理における報知方法、特定の情報処理における報知システム、処理装置と通信可能なサーバ、これら装置の機能または上記方法を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、等の形態で実現することができる。

システム１０００の構成を示すブロック図である。 プッシュ通知データＰＤの一例を示す図である。 ＯＳによる通知受信処理のフローチャートである。 端末装置１００の表示部１７０に表示される画面の一例を示す図である。 アプリケーションＡＰＰによる通知受信処理のフローチャートである。 データベースＤＢとメッセージテーブルＭＴの一例を示す図である。 メッセージ表示処理のフローチャートである。 コールスタックＣＳに記録された情報の一例を示す。 システム１０００の動作例を示すシーケンス図である。

Ａ．第１実施例：
Ａ−１：システム１０００の構成
図１は、システム１０００の構成を示すブロック図である。システム１０００は、端末装置１００と、プリンタ２１０、２２０と、制御サーバ３００と、プッシュ通知サーバ４００と、を備える。プリンタ２１０、２２０は、有線のローカルエリアネットワークＬＮに接続されている。ローカルエリアネットワークＬＮには、無線のアクセスポイントＡＰが接続されている。ローカルエリアネットワークＬＮは、例えば、イーサネット（登録商標）規格に準拠して構築された有線ネットワークである。アクセスポイントＡＰは、例えば、Ｗｉ−Ｆｉ規格に準拠した通信方式を利用したアクセスポイントである。ローカルエリアネットワークＬＮは、インターネットＩＴに接続されている。制御サーバ３００とプッシュ通知サーバ４００とは、インターネットＩＴに接続されている。

端末装置１００は、アクセスポイントＡＰとローカルエリアネットワークＬＮを介して、プリンタ２１０、２２０と、通信可能に接続されている。端末装置１００は、アクセスポイントＡＰとローカルエリアネットワークＬＮとインターネットＩＴとを介して、制御サーバ３００およびプッシュ通知サーバ４００と通信可能に接続されている。なお、端末装置１００は、Ｗ−ＣＤＭＡなどの携帯電話通信の方式に従う無線通信を行う基地局（図示省略）と、インターネットＩＴと、を介して、制御サーバ３００およびプッシュ通知サーバ４００と接続されていても良い。

端末装置１００（図１）は、プリンタ２１０、２２０のユーザが利用する端末装置であり、例えば、スマートフォンである。端末装置１００は、端末装置１００のコントローラーとしてのＣＰＵ１１０と、ＲＡＭなどの揮発性記憶装置１２０と、ハードディスクドライブなどの不揮発性記憶装置１３０と、タッチパネルなどの操作部１６０と、液晶ディスプレイなどの表示部１７０と、外部機器との通信のための通信ＩＦ１８０と、を備えている。

通信ＩＦ１８０は、本実施例では、Ｗｉ−Ｆｉ規格に準拠した無線のインタフェースである。通信ＩＦ１８０は、上述したプリンタ２１０、２２０、制御サーバ３００、および、プッシュ通知サーバ４００との通信に用いられる。

揮発性記憶装置１２０は、ＣＰＵ１１０が処理を行う際に生成される種々の中間データを一時的に格納するバッファ領域を提供する。不揮発性記憶装置１３０には、コンピュータプログラムＰＧ１とデータベースＤＢとが格納されている。

コンピュータプログラムＰＧ１は、プリンタ２１０、２２０のベンダによって提供されるコンピュータプログラムであり、インターネットＩＴを介して端末装置１００に接続されたサーバからダウンロードされる形態で提供される。これに代えて、コンピュータプログラムＰＧ１は、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどに格納された形態で提供されても良い。

ＣＰＵ１１０は、図示しないＯＳプログラムを実行することによって、所定のＯＳ（オペレーティングシステム）としての機能を実現する。ＯＳは、例えば、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）などのプッシュ通知サービスに対応したＯＳである。ＣＰＵ１１０は、例えば、ＯＳプログラムを実行することによって、後述するＯＳによる通知受信処理を実行する。

ＣＰＵ１１０は、例えば、上述した所定のＯＳ上で、コンピュータプログラムＰＧ１を実行することにより、プリンタ２１０、２２０を制御するアプリケーションＡＰＰとしての機能を実現する。この機能は、例えば、プリンタ２１０、２２０のうちの制御対象のプリンタに、印刷指示や印刷データを含む印刷ジョブを送信して、制御対象のプリンタに印刷を実行させるプリンタ制御処理を実行する。なお、この機能は、ローカルエリアネットワークＬＮに接続されたスキャナ（図示省略）に原稿を読み取らせて、スキャンデータを生成させ、該スキャンデータをスキャナから取得するスキャナ制御処理を実行しても良い。また、ＣＰＵ１１０は、後述するアプリケーションＡＰＰによる通知受信処理を実行する。

コンピュータプログラムＰＧ１には、リソースファイルが組み込まれている。リソースファイルＲＦは、コンピュータプログラムＰＧ１がインストールされる際に、アプリケーション（コンピュータプログラムＰＧ１）による書き込みが禁止され、読み出しが許容されるメモリ領域に格納される。このために、リソースファイルＲＦは、アプリケーションＡＰＰによる書き込みが禁止され、読み出しが許容されるファイル、すなわち、読み出し専用ファイルである。

リソースファイルＲＦは、アプリケーションＡＰＰが使用する各種の情報、例えば、テキスト、画像を含む。本実施例では、例えば、リソースファイルＲＦは、アプリケーションがユーザへ情報の報知やユーザからの指示の取得のためのＵＩ画面に、表示するためのメッセージを含む。リソースファイルＲＦに格納されるデータについては後述する。

データベースＤＢは、コンピュータプログラムＰＧ１が最初に起動されたときに、アプリケーション（コンピュータプログラムＰＧ１）による書き込みと読み出しと両方が許容されるメモリ領域に構築される。データベースＤＢには、受信されたプッシュ通知データＰＤに基づいて、アプリケーションＡＰＰによってデータが格納される（詳細は後述）。リソースファイルＲＦに記録されるデータは、データベースＤＢに記録されるデータがデータベースＤＢに記録されるよりも前に、リソースファイルＲＦに記録される、ということができる。

プリンタ２１０、２２０は、例えば、ＣＰＵとメモリを含む制御部（図示省略）と、該制御部の制御に従って印刷を行う印刷機構（図示省略）と、を備えている。印刷機構は、例えば、インクジェット方式や電子写真方式などの所定の方式で、用紙などの印刷媒体上に画像を印刷する。

制御サーバ３００は、例えば、プリンタ２１０、２２０のベンダによって提供されるサーバである。制御サーバ３００は、制御サーバ３００のコントローラーとしてのＣＰＵ３１０と、ＲＡＭなどの揮発性記憶装置３２０と、ハードディスクドライブなどの不揮発性記憶装置３３０と、インターネットＩＴと接続するための通信ＩＦ３８０と、を備えている。

揮発性記憶装置３２０は、ＣＰＵ３１０が処理を行う際に生成される種々の中間データを一時的に格納するバッファ領域を提供する。不揮発性記憶装置３３０は、コンピュータプログラムＰＧ２を格納している。

ＣＰＵ３１０は、コンピュータプログラムＰＧ２を実行することによって、例えば、操作者の指示に従って、プッシュ通知サーバ４００に、プッシュ通知データＰＤの送信指示を送信する。制御サーバ３００が実行する処理については後述する。

プッシュ通知サーバ４００は、プッシュ通知サービスを提供するサーバである。プッシュ通知サービスは、制御サーバ３００の指示に応じて、プッシュ通知データＰＤを端末装置１００に送信するサービスである。プッシュ通知データＰＤは、端末装置１００にインストールされているコンピュータプログラムＰＧ１によって実現されるアプリケーションＡＰＰに関するデータを含む。プッシュ通知データＰＤは、アプリケーションＡＰＰ（コンピュータプログラムＰＧ１）が端末装置１００において起動しているか否かに拘わらず、制御サーバ３００からの指示を契機として、送信される。プッシュ通知データＰＤは、アプリケーションＡＰＰのユーザ宛に報知されるべき情報（例えば、テキストや画像）に限らず、アプリケーションＡＰＰが用いるべきデータを含み得る。プッシュ通知データＰＤについては、さらに後述する。

プッシュ通知サーバ４００は、自身で、あるいは、他のサーバ（図示省略）を介して、端末装置１００にプッシュ通知データＰＤを送信する。プッシュ通知サーバ４００は、例えば、Ａｎｄｒｏｉｄ（登録商標）やｉＯＳ（登録商標）などの複数種類のプラットフォームでそれぞれ動作する各アプリケーションに対するプッシュ通知データＰＤを送信可能なＦＣＭ（Firebase Cloud Messagingの略）サーバである。以下では、「プッシュ通知サーバ４００が端末装置１００にプッシュ通知データＰＤを送信する」とは、プッシュ通知サーバ４００が、直接、端末装置１００にプッシュ通知データＰＤを送信すること、および、他のサーバが提供するサービスを利用してプッシュ通知データＰＤを端末装置１００に送信すること、との両方を含む。

Ａ−２．プッシュ通知データＰＤ
図２は、プッシュ通知データＰＤの一例を示す図である。図２（Ａ）のプッシュ通知データＰＤ１は、ユーザ通知用のプッシュ通知データＰＤ１である。プッシュ通知データＰＤ１は、通知先識別子と、通知用データと、を含む。

通知先識別子は、プッシュ通知データＰＤの送信先を示す識別子である。通知先識別子には、例えば、端末装置１００とアプリケーションＡＰＰ（コンピュータプログラムＰＧ１）との組み合わせに対して付与される識別子であるアプリインスタンスＩＤが用いられる。すなわち、アプリインスタンスＩＤは、送信先の端末装置１００を識別するとともに、送信先の端末装置１００にインストールされた１以上のアプリケーションプログラムのうち、プッシュ通知データＰＤの送信先のアプリケーションＡＰＰを識別する。

例えば、端末装置１００においてアプリケーションＡＰＰが最初に起動されたときに、アプリケーションＡＰＰは、ユーザに対してプッシュ通知データＰＤを受信する許可を求めるＵＩ画面を表示する。ユーザから許可を取得した場合に、アプリケーションＡＰＰは、プッシュ通知サーバ４００に対して、アプリインスタンスＩＤの生成要求を送信する。プッシュ通知サーバ４００は、該生成要求を受信すると、アプリインスタンスＩＤを生成して、端末装置１００に送信する。端末装置１００のアプリケーションＡＰＰは、アプリインスタンスＩＤを制御サーバ３００に送信する。制御サーバ３００は、アプリインスタンスＩＤを用いて、プッシュ通知データＰＤの送信先を指定することができる。

プッシュ通知データＰＤ１の通知用データ（図２（Ａ））は、タイトルと、メッセージと、を含む。通知用データは、端末装置１００のユーザ（アプリケーションＡＰＰのユーザ）に対して報知すべき内容を示す。

図２（Ｂ）のプッシュ通知データＰＤ２は、表示制御用のプッシュ通知データである。プッシュ通知データＰＤ２は、上述した通知先識別子と、アプリ宛データと、を含む。アプリ宛データは、表示ＩＤと、条件情報と、メッセージと、コマンドと、を含む。

表示ＩＤは、メッセージに対応付けられた識別子である。条件情報は、メッセージを使用するか否かを判断するための使用条件を示す情報である。メッセージは、表示すべき内容を示すテキストである。コマンドは、登録コマンドと、削除コマンドと、のいずれかである。登録コマンドは、プッシュ通知データＰＤ２に含まれるアプリ宛データをデータベースＤＢに登録（格納）することを指示するコマンドである。削除コマンドは、プッシュ通知データＰＤ２にて指定されるアプリ宛データであって、データベースＤＢに登録済みのアプリ宛データを、データベースＤＢから削除することを指示するコマンドである。図２（Ｂ）のプッシュ通知データＰＤ２は、登録コマンドを含む。

図２（Ｃ）のプッシュ通知データＰＤ３は、プッシュ通知データＰＤ２と同様に、表示制御用のプッシュ通知データである。プッシュ通知データＰＤ３は、削除コマンドを含む点がプッシュ通知データＰＤ２と異なる。プッシュ通知データＰＤ３は、上述した表示ＩＤと、条件情報と、を含み、メッセージを含んでいない。プッシュ通知データＰＤ１〜ＰＤ３を用いた処理については、後述する。

なお、図示は省略するが、プッシュ通知データＰＤは、通知用、かつ、表示制御用のプッシュ通知データである場合には、図２（Ａ）の通知用データと、図２（Ｂ）、（Ｃ）のアプリ宛データと、の両方を含んでも良い。

Ａ−３．端末装置１００の動作
Ａ−３−１．ＯＳによる通知受信処理
端末装置１００のＯＳ（ＣＰＵ１１０）は、通信ＩＦ１８０を介してプッシュ通知サーバ４００からプッシュ通知データＰＤを受信すると、ＯＳによる通知受信処理を実行する。図３は、ＯＳによる通知受信処理のフローチャートである。

Ｓ１１０では、ＣＰＵ１１０は、受信されたプッシュ通知データＰＤは、上述した通知用データを含むか否かを判断する。例えば、受信されたプッシュ通知データＰＤが、図２（Ａ）のプッシュ通知データＰＤ１である場合には、プッシュ通知データＰＤは、通知用データを含むと判断される。

プッシュ通知データＰＤが通知用データを含む場合には（Ｓ１１０：ＹＥＳ）、Ｓ１２０にて、ＣＰＵ１１０は、該通知用データを用いて、表示部１７０に通知ウインドウＮＷを表示する。プッシュ通知データＰＤが通知用データを含まない場合には（Ｓ１１０：ＮＯ）、ＣＰＵ１１０は、Ｓ１２０をスキップする。

図４は、端末装置１００の表示部１７０に表示される画面の一例を示す図である。図４（Ａ）の例では、表示部１７０には、通知ウインドウＮＷが表示されている。この通知ウインドウＮＷは、図２（Ａ）のプッシュ通知データＰＤ１が受信された場合に表示される。通知ウインドウＮＷは、アイコンＡＩと、タイトルＴＴと、ボタンＢＴａ、ＢＴｂと、を含む。アイコンＡＩは、プッシュ通知データＰＤ１に含まれる通知先識別子によって示されるアプリケーションＡＰＰを示すアイコンである。タイトルＴＴは、プッシュ通知データＰＤ１の通知用データに含まれるタイトルである。通知ウインドウＮＷにおいて「表示」のボタンＢＴａがユーザによって押下されると、ＣＰＵ１１０は、プッシュ通知データＰＤ１の通知用データに含まれるメッセージを表示する（図示省略）。通知ウインドウＮＷにおいて「閉じる」のボタンＢＴｂがユーザによって押下されると、ＣＰＵ１１０は、通知ウインドウＮＷを消去する。

Ｓ１３０では、ＣＰＵ１１０は、受信されたプッシュ通知データＰＤは、上述したアプリ宛データを含むか否かを判断する。例えば、受信されたプッシュ通知データＰＤが、図２（Ｂ）のプッシュ通知データＰＤ２である場合には、プッシュ通知データＰＤは、アプリ宛データを含むと判断される。

プッシュ通知データＰＤがアプリ宛データを含む場合には（Ｓ１３０：ＹＥＳ）、Ｓ１４０にて、ＣＰＵ１１０は、アプリ宛データを、揮発性記憶装置１２０あるいは不揮発性記憶装置１３０上の指定領域に格納して、ＯＳによる通知受信処理を終了する。プッシュ通知データＰＤが宛先用データを含まない場合には（Ｓ１３０：ＮＯ）、ＣＰＵ１１０は、Ｓ１４０をスキップして、ＯＳによる通知受信処理を終了する。

Ａ−３−２．アプリケーションＡＰＰによる通知受信処理
端末装置１００のアプリケーションＡＰＰ（ＣＰＵ１１０）は、上述した指定領域を監視しており、ＯＳによって該指定領域にアプリ宛データが格納されると、アプリケーションＡＰＰによる通知受信処理を実行する。図５は、アプリケーションＡＰＰによる通知受信処理のフローチャートである。

Ｓ２００では、ＣＰＵ１１０は、指定領域に格納されたアプリ宛データを取得して、揮発性記憶装置１２０のバッファ領域に格納する。本ステップで取得されたアプリ宛データを処理対象のアプリ宛データと呼ぶ。

Ｓ２１０では、ＣＰＵ１１０は、処理対象のアプリ宛データに登録コマンドが含まれるか否かを判断する。例えば、処理対象のアプリ宛データが、図２（Ｂ）のプッシュ通知データＰＤ２に含まれるアプリ宛データである場合には、アプリ宛データに登録コマンドが含まれると判断される。

処理対象のアプリ宛データに登録コマンドが含まれる場合には（Ｓ２１０：ＹＥＳ）、Ｓ２２０にて、ＣＰＵ１１０は、処理対象のアプリ宛データをデータベースＤＢ（図１）に格納する。これによって、処理対象のアプリ宛データが登録される。

図６は、データベースＤＢとメッセージテーブルＭＴの一例を示す図である。図６（Ａ）のデータベースＤＢには、１個のエントリＥＮａが記録されている。このエントリＥＮａは、図２（Ｂ）のプッシュ通知データＰＤ２のアプリ宛データが処理対象のアプリ宛データである場合に、記録されるエントリである。エントリＥＮａは、アプリ宛データに含まれる表示ＩＤと、条件情報と、データ（例えば、メッセージ）と、を含む。エントリＥＮａは、さらに、アプリ宛データに含まれるデータの属性を示す情報を含む。アプリ宛データに含まれるデータがメッセージである場合には、属性は、テキストである。アプリ宛データに含まれるデータの属性は、例えば、画像データや音声データである場合がある。

処理対象のアプリ宛データに登録コマンドが含まれない場合には（Ｓ２１０：ＮＯ）、Ｓ２２０はスキップされる。

Ｓ２３０では、ＣＰＵ１１０は、処理対象のアプリ宛データに削除コマンドが含まれるか否かを判断する。例えば、処理対象のアプリ宛データが、図２（Ｃ）のプッシュ通知データＰＤ３に含まれるアプリ宛データである場合には、アプリ宛データに削除コマンドが含まれると判断される。

処理対象のアプリ宛データに削除コマンドが含まれる場合には（Ｓ２３０：ＹＥＳ）、Ｓ２４０にて、ＣＰＵ１１０は、データベースＤＢ（図１）に格納済みのデータのうち、処理対象のアプリ宛データ対応するデータを削除して、アプリケーションＡＰＰによる通知受信処理を終了する。

例えば、図２（Ｂ）のプッシュ通知データＰＤ２のアプリ宛データが処理対象のアプリ宛データである場合には、データベースＤＢにおいて、該アプリ宛データに含まれる表示ＩＤと条件情報とを含むエントリＥＮａが特定される。そして、データベースＤＢからエントリＥＮａの全体が削除される。

アプリ宛データに削除コマンドが含まれない場合には（Ｓ２３０：ＮＯ）、ＣＰＵ１１０は、Ｓ２４０をスキップして、アプリケーションＡＰＰによる通知受信処理を終了する。

Ａ−３−３．メッセージ表示処理
次に、端末装置１００のアプリケーションＡＰＰ（ＣＰＵ１１０）によって実行されるメッセージ表示処理について説明する。アプリケーションＡＰＰは、上述したように、プリンタ２１０、２２０を制御するプリンタ制御処理を実行するアプリケーションである。プリンタ制御処理の実行の過程では、表示部１７０に様々なメッセージを表示すべきイベントが発生する。例えば、エラーが発生した場合には、当該エラーの発生をユーザに報知するメッセージが表示部１７０に表示される。また、例えば、ユーザから印刷すべきファイルの選択指示や用いるべきプリンタの選択指示を取得する必要がある場合には、表示部１７０には、当該選択指示を取得するためのＵＩ要素（プルダウンメニューなど）とともに、選択指示の入力を促すメッセージが表示される。プリンタ制御処理の実行の過程で発生するイベントであって、表示部１７０にメッセージを表示する契機となるイベントを、メッセージ表示イベントと呼ぶ。メッセージ表示イベントは、例えば、エラーの発生、ユーザから所定の指示が入力されたこと、制御対象のプリンタ２１０、２２０から所定のデータを受信したこと、などを含み得る。

メッセージ表示イベントが発生した場合には、ＣＰＵ１１０は、メッセージ表示処理を実行する。図７は、メッセージ表示処理のフローチャートである。Ｓ３００では、ＣＰＵ１１０は、発生したメーセージ表示イベントに対応する表示ＩＤを特定する。例えば、リソースファイルＲＦは、発生し得るメッセージ表示イベントのそれぞれに対応する表示ＩＤを記録したテーブルを含んでいる（図示省略）。ＣＰＵ１１０は、該テーブルを参照して対応する表示ＩＤを特定する。メッセージ表示処理が開始される契機となったメッセージ表示イベントに対応する表示ＩＤを注目表示ＩＤとも呼ぶ。

Ｓ３１０では、ＣＰＵ１１０は、注目表示ＩＤが、データベースＤＢに記録されているか否かを判断する。例えば、図６（Ａ）の例では、データベースＤＢには、１個の表示ＩＤ「ＩＤ＿１」だけが記録されているので、注目表示ＩＤが「ＩＤ＿１」である場合には、注目表示ＩＤがデータベースＤＢに記録されていると判断される。

注目表示ＩＤが、データベースＤＢに記録されている場合には（Ｓ３１０：ＹＥＳ）、Ｓ３２０にて、ＣＰＵ１１０は、データベースＤＢに、注目表示ＩＤに対応する条件情報が含まれるか否かを判断する。図６（Ａ）の例において、注目表示ＩＤが「ＩＤ＿１」である場合には、該注目表示ＩＤ「ＩＤ＿１」を含むエントリＥＮａに、条件情報「［3］SaveHistory(11, *)」が含まれる。このために、この場合には、データベースＤＢに、表示ＩＤに対応する条件情報が含まれると判断される。なお、プッシュ通知データＰＤ２（図２（Ｂ））において、条件情報は省略され得るので、データベースＤＢのエントリＥＮａには、条件情報が含まれない場合がある。その場合には、データベースＤＢに、表示ＩＤに対応する条件情報が含まれないと判断される。

注目表示ＩＤに対応する条件情報が含まれる場合には（Ｓ３２０：ＹＥＳ）、Ｓ３３０にて、ＣＰＵ１１０は、コールスタックＣＳに条件情報が含まれるか否かを判断する。コールスタックＣＳは、例えば、コンピュータプログラムＰＧ１の実行中に、揮発性記憶装置１２０に確保されるＬＩＦＯ（後入れ先出し）の記憶領域である。コールスタックＣＳには、プログラムの実行中において関数（サブルーチン）がコールされた履歴を特定できる情報が記録されている。具体的には、ＣＰＵ１１０は、メッセージ表示イベントが発生した時点（例えば、エラーの発生時）においてコールスタックＣＳに記録されている情報を取得し、取得された情報に条件情報と一致する情報が含まれているか否かを判断する。

図８は、コールスタックＣＳに記録された情報の一例を示す。図８の例では、コールスタックＣＳは、［１］〜［４］の４個のスタックフレームを含んでいる。例えば、［１］のスタックフレームは、メッセージ表示イベントが発生した時点で実行されていた関数に関する情報を示す。［２］のスタックフレームは、［１］のスタックフレームに対応する関数をコールした関数に関する情報を示す。同様に、［３］、［４］のスタックフレームは、それぞれ、［２］、［３］のスタックフレームに対応する関数をコールした関数に関する情報を示す。例えば、図８の例では、［２］のスタックフレーム「write(11, 0xff00,0x5)」は、関数「write」がコールされて、２個の引数(11, 0xff00,0x5)が渡されたことを示している。［３］のスタックフレーム「SaveHistory(11, 0xff339b9)」は、関数「SaveHistory」がコールされて、２個の引数(11, 0xff339b9)が渡されたことを示している。ここで、「SaveHistory」は、印刷履歴情報を保存する関数であるとする。また、この関数に渡される１個目の引数が「１１」である場合には、１１個目の記憶領域に印刷履歴情報が保存されるものとする。

コールスタックＣＳに記録された情報によって、どのような処理の実行過程を経てメッセージ表示イベントが発生したかが特定できる。このために、本実施例では、条件情報として、コールスタックＣＳに含まれ得る特定のスタックフレームを示す情報が用いられている。例えば、図６（Ａ）のエントリＥＮａの条件情報は、「［3］SaveHistory(11, *)」である。このために、図８の例のように、コールスタックＣＳに、［3］SaveHistory(11, *)が含まれる場合には、条件情報と一致する情報が含まれると判断される。ここで、条件情報において、２個目の引数「*」は、任意の数値を示すワイルドカードである。コールスタックＣＳに、［3］SaveHistory(11, *)が含まれることは、１１個目の記憶領域に印刷履歴情報が保存される処理が実行された上で、メッセージ表示イベント（例えば、エラー）が発生したことを意味する。

コールスタックＣＳに条件情報が含まれる場合には（Ｓ３３０：ＹＥＳ）、データベースＤＢに記録されたデータ（メッセージ）の使用条件が満たされたと判断できる。このために、この場合には、Ｓ３４０にて、ＣＰＵ１１０は、データベースＤＢに記録されたメッセージを表示する。例えば、図６（Ａ）のデータベースＤＢの例において、注目表示ＩＤが「ＩＤ＿１」であり、コールスタックＣＳに「［3］SaveHistory(11, *)」が含まれる場合には、Ｓ３４０にて、例えば、表示部１７０に、図４（Ｂ）に示す画面が表示される。図４（Ｂ）の例では、表示部１７０に、図６（Ａ）のデータベースＤＢのエントリＥＮａに含まれるメッセージＭＳ１が表示されている。

コールスタックＣＳに条件情報が含まれない場合には（Ｓ３３０：ＮＯ）、データベースＤＢに記録されたメッセージの使用条件が満たされないと判断できる。このために、この場合には、Ｓ３５０にて、ＣＰＵ１１０は、リソースファイルＲＦに記録されたメッセージを表示する。

具体的には、リソースファイルＲＦは、図６（Ｂ）に示すメッセージテーブルＭＴを含んでいる。メッセージテーブルＭＴは、全ての表示ＩＤに対応するエントリを１個ずつ含んでおり、各エントリは、表示ＩＤと、データ（例えば、メッセージ）と、該データの属性を示す情報と、を含む。データがメッセージである場合には、属性は、テキストである。すなわち、メッセージテーブルＭＴには、全ての表示ＩＤに対応するメッセージが記録されている。図６（Ｂ）では、４個のエントリＥＮ１〜ＥＮ４だけが代表して図示されている。

Ｓ３５０では、メッセージテーブルＭＴから注目表示ＩＤに対応するメッセージが取得されて、表示部１７０に表示される。例えば、注目表示ＩＤが「ＩＤ＿１」であり、コールスタックＣＳに「［3］SaveHistory(11, *)」が含まれない場合には、Ｓ３５０にて、例えば、表示部１７０に、図４（Ｃ）に示す画面が表示される。図４（Ｃ）の例では、表示部１７０に、図６（Ｂ）のメッセージテーブルＭＴのエントリＥＮ１に含まれるメッセージＭＳ２が表示されている。

注目表示ＩＤが、データベースＤＢに記録されていない場合には（Ｓ３１０：ＮＯ）、Ｓ３５０にて、ＣＰＵ１１０は、リソースファイルＲＦに記録されたメッセージを表示する。例えば、例えば、注目表示ＩＤが「ＩＤ＿１」であっても、データベースＤＢに「ＩＤ＿１」に対応するエントリＥＮａがない場合には、Ｓ３５０にて、表示部１７０に、図４（Ｃ）に示す画面が表示される。

注目表示ＩＤに対応する条件情報が含まれない場合には（Ｓ３２０：ＮＯ）、無条件でデータベースＤＢに記録されたデータ（メッセージ）が使用される。このために、この場合には、Ｓ３４０にて、ＣＰＵ１１０は、データベースＤＢに記録されたメッセージを表示する。

Ａ−３−４．システム１０００の具体的な動作例
図９は、システム１０００の動作例を示すシーケンス図である。コンピュータプログラムＰＧ１が市場にリリースされ、端末装置１００にインストールされた時点では、データベースＤＢには、図６（Ａ）のエントリＥＮａに示すようなデータは格納されていない。一方で、図６（Ｂ）のメッセージテーブルＭＴは、リソースファイルＲＦに含まれる情報であるので、コンピュータプログラムＰＧ１がインストールされて時点から不揮発性記憶装置１３０に格納されている。

この状態で、アプリケーションＡＰＰ（ＣＰＵ１１０）によるプリンタ制御処理の実行過程において、メッセージ表示イベントである印刷履歴情報の保存エラーが発生したとする（図９のＳ１）。この場合には、Ｓ２にて、ＣＰＵ１１０は、メッセージ表示イベントの発生に応じて、上述したメッセージ表示処理（図７）を実行する。

この時点では、データベースＤＢには、図６（Ａ）のエントリＥＮａが記録されていないので、図７のＳ３１０にて、注目表示ＩＤ（例えば、ＩＤ＿１）はデータベースＤＢに記録されていないと判断され（図７のＳ３１０：ＮＯ）、リソースファイルＲＦのメッセージテーブルＭＴ（図６（Ｂ））に記録されたメッセージが表示部１７０に表示される（図４（Ｃ））。すなわち、この時点では、印刷履歴情報の保存エラーが発生した場合には、どのような状況で該保存エラーが発生した場合であっても、例えば、「保存に失敗しました」という汎用的なメッセージが表示部１７０に表示される。

その後に、例えば、アプリケーションＡＰＰのユーザからの報告などに基づいて、アプリケーションＡＰＰでは、１０個の印刷履歴情報が保存された状態で、１１個目の印刷履歴情報を保存しようとすると、保存エラーが発生することが判明したとする。この場合には、アプリケーションＡＰＰを提供するベンダは、制御サーバ３００から、プッシュ通知送信指示をプッシュ通知サーバ４００に対して送信する（図９のＳ３）。このプッシュ通知送信指示は、図２（Ｂ）のプッシュ通知データＰＤ２を、コンピュータプログラムＰＧ１がインストールされた全ての端末装置（例えば、端末装置１００）に送信するように、指示する送信指示である。

プッシュ通知サーバ４００がプッシュ通知送信指示を受信すると、Ｓ４では、プッシュ通知サーバ４００は、プッシュ通知送信指示に従って、図２（Ｂ）のプッシュ通知データＰＤ２を、端末装置１００を含む送信対象の端末装置に対して送信する。Ｓ５では、プッシュ通知データＰＤ２を受信したことに応じて、端末装置１００（ＣＰＵ１１０）は、ＯＳによる通知受信処理（図３）を実行する。Ｓ６では、端末装置１００は、アプリケーションＡＰＰによる通知受信処理（図５）を実行する。この結果、図６（Ａ）に示すように、データベースＤＢにエントリＥＮａが記録される（図５のＳ２１０にてＹＥＳ、Ｓ２２０）。

データベースＤＢにエントリＥＮａが記録された後に、アプリケーションＡＰＰ（ＣＰＵ１１０）によるプリンタ制御処理の実行過程において、再度、印刷履歴情報の保存エラーが発生したとする（図９のＳ７）。この場合には、Ｓ８にて、ＣＰＵ１１０は、再度、上述したメッセージ表示処理（図７）を実行する。

この時点では、データベースＤＢには、図６（Ａ）のエントリＥＮａが記録されているので、図７のＳ３１０にて、注目表示ＩＤ（例えば、ＩＤ＿１）はデータベースＤＢに記録されていると判断される（図７のＳ３１０にてＹＥＳ）。さらに、Ｓ７にて発生した保存エラーが、１１個目の印刷履歴情報を保存しようとしとことに起因して発生した場合には、コールスタックにエントリＥＮａに記録された条件情報が含まれるので（図７のＳ３３０にてＹＥＳ）、エントリＥＮａに記録されたメッセージの使用条件は満たされる。したがって、データベースＤＢのエントリＥＮａに記録されたメッセージが表示される（図４（Ｂ））。すなわち、この時点では、１１個目の印刷履歴情報を保存しようとしたことに起因して保存エラーが発生した場合には、より具体的にエラーについて説明するメッセージを表示し得る。例えば、図４（Ｂ）に示すように、「履歴保存は１０件までです。古いデータを削除してから保存してください。」というようなエラーへの対処法まで言及した適切なメッセージが表示部１７０に表示される。

以上説明した本実施例によれば、第１のメッセージ表示イベント（例えば、１１個目の印刷履歴情報の保存エラー）が発生した場合に、該メッセージ表示イベントに対応する報知情報（例えば、エントリＥＮａに記録された情報）がデータベースＤＢに格納されているか否かが判断される（図７のＳ３１０〜Ｓ３３０等）。該メッセージ表示イベントに対応する報知情報がデータベースＤＢに格納されている場合に（例えば、図７のＳ３１０にてＹＥＳ、かつ、Ｓ３３０にてＹＥＳ）、データベースＤＢに格納されている報知情報を用いて、ユーザへ情報が報知される（図７のＳ３４０、図４（Ｂ））。該メッセージ表示イベントに対応する報知情報がデータベースＤＢに格納されていない場合に（例えば、図７のＳ３１０にてＮＯ、あるいは、Ｓ３３０にてＮＯ）、リソースファイルＲＦに格納されている報知情報（例えば、メッセージテーブルＭＴに記録されたメッセージ）を用いて、ユーザへ情報が報知される（図７のＳ３４０、図４（Ｃ））。

この結果、プッシュ通知サーバ４００からのプッシュ通知によって報知情報を端末装置１００に送信しておくことで、第１のメッセージ表示イベントが発生した場合に、端末装置１００は、プッシュ通知によって送信される報知情報を用いてユーザへ情報を報知できる。また、プッシュ通知サーバ４００からプッシュ通知を送信しなくても、第１のメッセージ表示イベントが発生した場合に、端末装置１００は、リソースファイルＲＦに格納された報知情報を用いてユーザへ情報を報知できる。したがって、端末装置１００は、プリンタ制御処理の過程で発生するイベントに応じて、適切な報知を行うことができる。例えば、上述したように、リソースファイルＲＦに格納された報知情報を用いた報知よりも、他の報知情報を用いた報知が適切であることが判明した場合には、プッシュ通知によって当該他の報知情報を端末装置１００に送信することで、端末装置１００は、当該他の報知情報を用いた報知を行うことができる。

さらに、上記実施例によれば、第１のメッセージ表示イベントとは異なるイベントであっても、メッセージを表示すべきイベントが発生すれば、図７のメッセージ表示処理が行われる。すなわち、第２のメッセージ表示イベント（例えば、保存エラーとは異なるエラー）が発生した場合に、第２のメッセージ表示イベントに対応する報知情報がデータベースＤＢに格納されているか否かが判断される（図７のＳ３１０〜Ｓ３３０等）。第２のメッセージ表示イベントに対応する報知情報がデータベースＤＢに格納されている場合に（例えば、図７のＳ３１０にてＹＥＳ、かつ、Ｓ３３０にてＹＥＳ）、データベースＤＢに格納されている報知情報を用いて、ユーザへ情報が報知される（図７のＳ３４０、図４（Ｂ））。第２のメッセージ表示イベントに対応する報知情報がデータベースＤＢに格納されていない場合に（例えば、図７のＳ３１０にてＮＯ、あるいは、Ｓ３３０にてＮＯ）、リソースファイルＲＦに格納されている報知情報（例えば、メッセージテーブルＭＴに記録されたメッセージ）を用いて、ユーザへ情報が報知される（図７のＳ３４０、図４（Ｃ））。したがって、プリンタ制御処理の過程で発生する複数個のイベントに応じて、適切な報知を行うことができる。

さらに、上記実施例によれば、端末装置１００は、プッシュ通知によって報知情報（メッセージ）の使用条件を示す条件情報（例えば、図６（Ａ）の「［3］SaveHistory(11, *)」）を受信する。該条件情報は、報知情報と対応付けてデータベースＤＢに格納される（図６（Ａ））。端末装置１００は、メッセージ表示イベントが発生した場合に、条件情報によって示される使用条件が満たされるか否かを判断する（図７のＳ３３０）。使用条件が満たされる場合に（図７のＳ３４０にてＹＥＳ）、データベースＤＢに対応する報知情報が格納されていると判断されて、該報知情報を用いた報知が行われる（図７のＳ３４０）。そして、使用条件が満たされない場合に（図７のＳ３４０にてＮＯ）、データベースＤＢに対応する報知情報が格納されていないと判断されて、リソースファイルＲＦに格納された報知情報を用いた報知が行われる（図７のＳ３５０）。この結果、プッシュ通知サーバ４００から受信される条件情報を用いて、データベースＤＢに格納された報知情報を用いた報知と、リソースファイルＲＦに格納された報知情報を用いた報知と、が適切に切り替えられる。

さらに、条件情報は、プリンタ制御処理の実行の過程でコールスタックに記録され得る特定の情報（例えば、図６（Ａ）の「［3］SaveHistory(11, *)」）を含む。端末装置１００は、コールスタックに当該特定の情報が記録されている場合に、使用条件が満たされると判断する。この結果、データベースＤＢに格納された報知情報が用いられるべきか否かを適切に判断できる。

さらに、上記実施例では、データベースＤＢに格納される報知情報は、第１のメッセージ表示イベントに対応する第１のメッセージ（例えば、図６（Ａ）のエントリＥＮａに含まれるメッセージ）を含む。そして、リソースファイルＲＦに格納される報知情報は、特定のメッセージ表示イベントに対応する第２のメッセージ（例えば、図６（Ｂ）のエントリＥＮ１に含まれるメッセージ）を含む。第１のメッセージと第２のメッセージとは互いに異なっている。この結果、プッシュ通知サーバ４００からプッシュ通知データＰＤ２が端末装置１００に送信されることで、端末装置１００は、処理装置は、第１のメッセージ表示イベントが発生した場合に報知されるメッセージを、第２のメッセージから第１のメッセージに変更できる。

さらに、上記実施例では、第１のメッセージ表示イベントは、プリンタ制御処理の過程で発生する特定のエラー（具体的には、１１個目の印刷履歴情報の保存エラー）である。したがって、プッシュ通知サーバ４００から報知情報が端末装置１００に送信されることで、端末装置１００は、特定のエラーが発生した場合行われるユーザへの報知を変更できる。どのようなエラーが発生するかをコンピュータプログラムＰＧ１がリリースされた時点で完全に把握することは困難である。このために、事後的に、プッシュ通知サーバ４００から報知情報を送信することで、エラーが発生した場合行われるユーザへの報知を変更できれば便利である。

さらに、上記実施例では、データベースＤＢに格納されるべき報知情報は、プッシュ通知サービスを用いて送信されるので、端末装置１００は、容易に、適切なタイミングで、報知情報を受信することができる。

さらに、上記実施例では、端末装置１００は、プッシュ通知サーバ４００から、受信済みの報知情報を削除することを指示する削除コマンドを含むプッシュ通知データＰＤ３（図２（Ｃ））を受信し得る。端末装置１００は、削除コマンドに従って、データベースＤＢに格納済みの報知情報を削除する（図５のＳ２３０、Ｓ２４０）。この結果、例えば、プッシュ通知サーバ４００から削除コマンドが端末装置１００に送信されることで、端末装置１００は、第１のメッセージ表示イベントが発生した場合に行われる報知を、データベースＤＢに格納された報知情報を用いた報知から、リソースファイルＲＦに格納された報知情報を用いた報知に戻すことができる。例えば、端末装置１００のＯＳがアップデートされることによって、上述した１１個目の印刷履歴情報の保存エラーが発生しなくなる場合がある。このような場合であっても、プッシュ通知サーバ４００から削除コマンドを含むプッシュ通知データＰＤ３が端末装置１００に送信されることで、容易に、データベースＤＢからエントリＥＮａが削除される。このような場合には、１１個目の印刷履歴情報を保存した際に、偶然に、他の原因によって保存エラーが発生した場合に、データベースＤＢのエントリＥＮａに含まれるメッセージが表示されることを防止できる。

また、上記実施例では、リソースファイルＲＦに記録された報知情報は、コンピュータプログラムＰＧ１に組み込まれた状態で端末装置１００に取得される。このようなリソースファイルＲＦは、書き込みが許容されないメモリ領域に格納されるので、容易には、変更できない。例えば、リソースファイルＲＦの内容を変更する方法として、コンピュータプログラムＰＧ１のバージョンアップを行う方法がある。このような方法は、例えば、新たなバージョンのコンピュータプログラムＰＧ１の審査手続きが必要な場合がある等から、容易に行える方法であるとは言い難い。本実施例によれば、リソースファイルＲＦに格納された報知情報を用いて実行されていた報知の内容を、事後的に、容易に変更することができる。

Ｃ．変形例：
（１）上記実施例では、データベースＤＢのエントリＥＮａにおいて、表示ＩＤと条件情報との組み合わせに、報知情報としてのメッセージを対応付けている。そして、表示ＩＤと条件情報との組み合わせによって、メッセージを用いるべきメッセージ表示イベント（例えば、１１個目の印刷履歴情報の保存エラー）が発生したか否かを判断している。これに代えて、表示ＩＤのみで、メッセージを用いるべきメッセージ表示イベントが発生したか否かを判断しても良い。この場合には、条件情報は不要であり、図７の３２０、３３０は省略されても良い。

（２）上記実施例では、条件情報として、コールスタックに記録され得る情報が用いられる。これに代えて、他の種類の条件情報が用いられても良い。例えば、対応するメッセージを用いるべき期間、例えば、「４月１日から８月３１日まで」などの期間を示す情報が条件情報として用いられても良い。こうすれば、プッシュ通知データを用いて、特定の期間だけ、特定のメッセージ表示イベント発生時に表示されるメッセージを容易に変更することができる。

（３）上記実施例では、データベースＤＢに記録されるアプリ宛データは、プッシュ通知データとして送信される。これに代えて、他の送信手段を用いて、アプリ宛データが端末装置１００に送信されても良い。例えば、アプリケーションＡＰＰ（コンピュータプログラムＰＧ１）の起動時に、端末装置１００は、プッシュ通知サーバ４００または制御サーバ３００に、新たなアプリ宛データの有無を問い合わせてもよい。この場合には、プッシュ通知サーバ４００または制御サーバ３００は、新たなアプリ宛データがある場合には、該問い合わせに対する応答として、新たなアプリ宛データを、端末装置１００に送信しても良い。ただし、実施例のように、プッシュ通知データＰＤ２を用いる場合には、プッシュ通知サーバ４００は、コンピュータプログラムＰＧ１が起動されているか否かに拘わらずに、あるいは、端末装置１００からの問い合わせの有無に拘わらずに、任意のタイミングで、アプリ宛データを送信できる。

（４）上記実施例では、削除コマンドを含むプッシュ通知データＰＤ３が端末装置１００に送信されることによって、データベースＤＢから不要となってエントリＥＮａを削除することができる。このようなエントリＥＮａを削除する仕組みは省略されても良い。例えば、データベースＤＢに、同一のメッセージ表示イベントに対応する複数個のエントリが存在する場合には、複数個のエントリのうち、最後に記録されたエントリ、すなわち、最後にプッシュ通知サーバ４００から送信されたアプリ宛データに基づくエントリの報知情報が用いられる。

（５）上記実施例では、メッセージテーブルＭＴ（図６（Ｂ））は、コンピュータプログラムＰＧ１に組み込まれたリソースファイルＲＦに含まれている。これに代えて、メッセージテーブルＭＴは、最初にコンピュータプログラムＰＧ１が起動されたときに、制御サーバ３００から取得されても良い。このとき、メッセージテーブルＭＴは、コンピュータプログラムＰＧ１による書き込みと読み出しとの両方が許容されるメモリ領域に格納されても良い。

（６）上記実施例では、データベースＤＢやメッセージテーブルＭＴに記録された報知情報は、表示部１７０に表示されるメッセージである。これに代えて、または、これとともに、報知情報は、端末装置１００のスピーカーから出力される音声情報であっても良いし、表示部１７０に表示される画像情報（ＪＰＥＧデータなど）であっても良い。

（７）上記実施例では、データベースＤＢやリソースファイルＲＦを保持し、図３、図５、図７の処理を実行する装置は、端末装置１００である。これに代えて、データベースＤＢやリソースファイルＲＦを保持し、図３、図５、図７の処理を実行する装置は、プリンタ２１０のＣＰＵであっても良い。この場合には、プッシュ通知サーバ４００は、プリンタ２１０に対して、プッシュ通知データＰＤ２、ＰＤ３を送信する。こうすれば、プッシュ通知サーバ４００からプリンタ２１０に対してプッシュ通知データＰＤ２、ＰＤ３が送信されることで、プリンタ２１０は、自身の表示部に表示するメッセージを変更できる。

（８）上記実施例では、制御サーバ３００とプッシュ通知サーバ４００とは別体のサーバであるが、制御サーバ３００とプッシュ通知サーバ４００の機能は、１個のサーバによって実現されても良い。また、制御サーバ３００とプッシュ通知サーバ４００とは、それぞれ、１個の計算機ではなく、通信可能に接続された複数個の計算機から構成されるいわゆるクラウドサーバであっても良い。

（９）上記実施例では、アプリケーションＡＰＰが実行する処理は、プリンタ制御処理であるが、これに限られない。例えば、アプリケーションＡＰＰが実行する処理は、上述したようにスキャナ制御処理であっても良い。また、例えば、アプリケーションＡＰＰが実行する処理は、他のデバイスを制御する処理に限らず、ゲーム、ＳＮＳ（SOCIAL NETWORK SERVICEの略）などの他のサービスや機能を実現する処理であっても良い。

（１０）上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。

以上、実施例、変形例に基づき本発明について説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれる。

１００…端末装置、１１０…ＣＰＵ、１２０…揮発性記憶装置、１３０…不揮発性記憶装置、１６０…操作部、１７０…表示部、１８０…通信ＩＦ、２１０、２２０…プリンタ、３００…制御サーバ、３１０…ＣＰＵ、３２０…揮発性記憶装置、３３０…不揮発性記憶装置、３８０…通信ＩＦ、４００…プッシュ通知サーバ、１０００…システム、ＤＢ…データベース、ＰＤ…プッシュ通知データ、ＲＦ…リソースファイル、ＬＮ…ローカルエリアネットワーク、ＡＰ…アクセスポイント、ＣＳ…コールスタック、ＩＴ…インターネット、ＭＴ…メッセージテーブル、ＰＧ１、ＰＧ２…コンピュータプログラム

Claims (11)

1. 特定の情報処理を実行する処理装置のためのコンピュータプログラムであって、
   サーバから、第１の報知情報を受信する受信機能と、
   前記サーバから受信した前記第１の報知情報を第１の格納部に格納する格納処理機能と、
   前記特定の情報処理の過程で発生する第１のイベントであって、ユーザへ情報の報知を行うべき前記第１のイベントが発生した場合に、前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されているか否かを判断する判断機能と、
   前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されている場合に、前記第１のイベントに対応する前記第１の報知情報を用いて、ユーザへ情報を報知する第１の報知機能と、
   前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されていない場合に、第２の格納部に格納されている第２の報知情報であって前記第１のイベントに対応する前記第２の報知情報を用いて、ユーザへ情報を報知する第２の報知機能と、
   を前記処理装置に搭載されたコンピュータに実現させ、
   前記第２の報知情報は、前記第１の報知情報が前記第１の格納部に格納されるよりも前に前記第２の格納部に格納される、コンピュータプログラム。
2. 請求項１に記載のコンピュータプログラムであって、
   前記判断機能は、前記特定の情報処理の過程で発生する第２のイベントであって、ユーザへ情報の報知を行うべき前記第２のイベントが発生した場合に、前記第２のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されているか否かを判断し、
   前記第１の報知機能は、前記第２のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されている場合に、前記第２のイベントに対応する前記第１の報知情報を用いて、ユーザへ情報を報知し、
   前記第２の報知機能は、前記第２のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されていない場合に、前記第２の格納部に格納されている前記第２の報知情報であって、前記第２のイベントに対応する前記第２の報知情報を用いて、ユーザへ情報を報知する、コンピュータプログラム。
3. 請求項１または２に記載のコンピュータプログラムであって、
   前記受信機能は、さらに、前記第１の報知情報の使用条件を示す条件情報を受信し、
   前記条件情報は、前記第１の報知情報と対応付けて前記第１の格納部に格納され、
   前記判断機能は、
   前記第１のイベントが発生した場合に、前記条件情報によって示される前記使用条件が満たされるか否かを判断し、
   前記使用条件が満たされる場合に、前記第１のイベントに対応する前記第１の報知情報が格納されていると判断し、
   前記使用条件が満たされない場合に、前記第１のイベントに対応する前記第１の報知情報が格納されていないと判断する、コンピュータプログラム。
4. 請求項３に記載のコンピュータプログラムであって、
   前記条件情報は、前記特定の情報処理の実行の過程でコールスタックに記録され得る特定の情報を示し、
   前記判断機能は、
   前記第１のイベントの発生時に、前記コールスタックに前記特定の情報が記録されているか否かを判断し、
   前記コールスタックに前記特定の情報が記録されている場合に、前記条件情報が満たされると判断する、コンピュータプログラム。
5. 請求項１〜４のいずれかに記載のコンピュータプログラムであって、
   前記第１のイベントに対応する前記第１の報知情報は、ユーザに対して報知されるべき第１のメッセージを含み、
   前記第１のイベントに対応する前記第２の報知情報は、ユーザに対して報知されるべき第２のメッセージであって前記第１のメッセージとは異なる前記第２のメッセージを含む、コンピュータプログラム。
6. 請求項１〜５のいずれかに記載のコンピュータプログラムであって、
   前記第１のイベントは、前記特定の情報処理の過程で発生する特定のエラーである、コンピュータプログラム。
7. 請求項１〜６のいずれかに記載のコンピュータプログラムであって、
   前記サーバは、プッシュ通知サービスを実行するサーバであり、
   前記第１の報知情報は、プッシュ通知サービスを用いて送信される、コンピュータプログラム。
8. 請求項１〜７のいずれかに記載のコンピュータプログラムであって、
   前記受信機能は、前記第１の報知情報の受信後に、受信済みの前記第１の報知情報を削除することを指示する削除指示を受信し、
   前記コンピュータプログラムは、さらに、
   前記削除指示に従って、前記第１の格納部に格納済みの前記第１の報知情報を削除する削除機能を備える、コンピュータプログラム。
9. 請求項１〜８のいずれかに記載のコンピュータプログラムであって、
   前記第２の報知情報は、前記コンピュータプログラムに組み込まれた状態で前記処理装置に取得される、コンピュータプログラム。
10. 請求項１〜９のいずれかに記載のコンピュータプログラムであって、
    前記第１の格納部は、前記コンピュータプログラムによる書き込みと読み出しとの両方が許容されるメモリ領域であり、
    前記第２の格納部は、前記第２の報知情報が格納された後は、前記コンピュータプログラムによる書き込みが禁止され、読み出しが許容されるメモリ領域である、コンピュータプログラム。
11. 特定の情報処理を実行する処理装置であって、
    第１の格納部と、
    サーバから、第１の報知情報を受信する受信部と、
    前記サーバから受信した前記第１の報知情報を前記第１の格納部に格納する格納処理部と、
    前記第１の報知情報が前記第１の格納部に格納されるよりも前に第２の報知情報が格納される第２の格納部と、
    前記特定の情報処理の過程で発生する第１のイベントであって、ユーザへ情報の報知を行うべき前記第１のイベントが発生した場合に、前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されているか否かを判断する判断部と、
    前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されている場合に、前記第１のイベントに対応する前記第１の報知情報を用いて、ユーザへ情報を報知する第１の報知部と、
    前記第１のイベントに対応する前記第１の報知情報が前記第１の格納部に格納されていない場合に、前記第２の格納部に格納されている前記第２の報知情報であって前記第１のイベントに対応する前記第２の報知情報を用いて、ユーザへ情報を報知する第２の報知部と、
    を備える処理装置。
    

Images