(57)【要約】      （修正有）【課題】携帯情報端末にインストールされたのアプリの休眠ユーザの数の変化を計測する。【解決手段】配信サーバーが、第一のサイレントプッシュ通知を携帯情報端末に行い１００、当該通知を携帯情報端末が受信したかどうかを示すフィードバックを携帯情報端末から受信して特定のアプリが起動され且つプッシュ通知が許可されている携帯情報端末の数を計測し１４０、リモートプッシュ通知を携帯情報端末に行い１５０、当該通知を携帯情報端末が受信したかどうかを示すフィードバックを携帯情報端末から受信して１８０、アプリが休眠状態にある携帯情報端末の数を計測し１９０、第二のサイレントプッシュ通知を携帯情報端末に行い２００、当該通知を携帯情報端末が受信したかどうかを示す第ィードバックを携帯情報端末から受信して２３０、リモートプッシュ通知の後で特定のアプリが起動され且つプッシュ通知が許可状態になった携帯情報端末の数を集計する２４０。【選択図】図３
2017045403.tif 000002
【特許請求の範囲】
【請求項１】
携帯情報端末にインストールされた特定のアプリの休眠ユーザの数の変化を計測するための方法であって、以下のステップを含む方法
（Ａ）  配信サーバーが、第一リクエストを仲介サーバーに送信するステップであって、前記第一リクエストは、第一のサイレントプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｂ）  前記配信サーバーが、第一フィードバックを前記携帯情報端末から受信するステップであって、前記第一フィードバックは前記第一のサイレントプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｃ）  前記配信サーバーが、前記第一フィードバックにもとづいて、前記特定のアプリが起動され且つプッシュ通知が許可されている携帯情報端末の数を計測するステップと、
（Ｄ）  前記配信サーバーが、第二リクエストを前記仲介サーバーに送信するステップであって、前記第二リクエストはリモートプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｅ）  前記配信サーバーが、第二フィードバックを前記携帯情報端末から受信するステップであって、前記第二フィードバックは前記リモートプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｆ）  前記配信サーバーが、前記第一フィードバックと前記第二フィードバックとにもとづいて、アプリが休眠状態にある携帯情報端末の数を計測するステップと、
（Ｇ）  前記配信サーバーが、第三リクエストを前記仲介サーバーに送信するステップであって、前記第三リクエストは第二のサイレントプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｈ）  前記配信サーバーが、第三フィードバックを前記携帯情報端末から受信するステップであって、前記第三フィードバックは前記第二のサイレントプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｉ）  前記配信サーバーが、前記リモートプッシュ通知の後で前記特定のアプリが起動され且つプッシュ通知が許可状態になった携帯情報端末の数を集計するステップであって、前記集計は、前記第一フィードバックと前記第二フィードバックと前記第三フィードバックとにもとづいて行われる、該ステップ。
【請求項２】
請求項１に記載の方法であって、前記（Ｇ）のステップが、前記（Ｄ）のステップから１秒以上〜２４時間未満後に、実行される、該方法。
【請求項３】
請求項１又は２に記載の方法であって、前記（Ｇ）〜前記（Ｉ）のステップが、複数回実行される、該方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯情報端末にインストールされるアプリの統計データを作成する方法に関する。
【背景技術】
【０００２】
近年、携帯情報端末（スマートフォン、タブレット端末など）が急速に普及した。これに伴い、これらの端末にインストールされるアプリの数も増加している。携帯情報端末に搭載されるＯＳとしては、Ｇｏｏｇｌｅ（登録商標）社が開発したＡｎｄｒｏｉｄ（登録商標）や、Ａｐｐｌｅ（登録商標）社が開発したｉＯＳなどがある。
【０００３】
アプリは、アプリ配信サイトを通じて、ダウンロードされ、そして、携帯情報端末にインストールされる。Ａｎｄｒｏｉｄ用のアプリを配信する主要なサイトとしてはＧｏｏｇｌｅ  Ｐｌａｙがあり、ｉＯＳ用のアプリを配信する主要なサイトとしてはＡｐｐｌｅ  Ｓｔｏｒｅがある。
【０００４】
携帯情報端末は、通信回線を通して、そして、アプリを通して、サーバーと様々な情報を受信又は送信することができる。携帯情報端末のユーザにサーバー側から情報を配信する手段の１つとして、プッシュ通知という仕組みがある。
【０００５】
携帯情報端末に搭載される幾つかのＯＳは、プッシュ通知をサポートしている。例えば、ｉＯＳでは、ＡＰＮｓ（Ａｐｐｌｅ  Ｐｕｓｈ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）と呼ばれるフレームワークがあり、Ａｎｄｒｏｉｄでは、ＧＣＭ（Ｇｏｏｇｌｅ  Ｃｌｏｕｄ  Ｍｅｓｓａｇｉｎｇ）と呼ばれるフレームワークがある。
【０００６】
アプリの開発者にとって、自分が開発したアプリが、どれだけ多くの端末にインストールされたかについての情報は非常に重要である。インストールされた件数が多いアプリは、それだけ人気の高いアプリである可能性が高く、今後のアプリの開発の参考にすることができる。アプリ配信サイト側で、そのアプリがダウンロードされた件数をカウントすることで、そのアプリがインストールされた件数をカウントすることができる。
【０００７】
しかし、こうした方法で得られた件数は、ユーザの使用状況を反映しているとは言い難い。例えば、アプリをインストールして使用してみた後、そのアプリが気に入らない場合、そのアプリをユーザはアンインストールするかもしれない。あるいは、ユーザは、そのアプリをアンインストールも起動もしないで、携帯情報端末内に放置するかもしれない。
【０００８】
あるいは、プッシュ通知を行うことで、ユーザはそのアプリの存在をわずらわしく感じるようになり、その結果、そのアプリをアンインストールする可能性もある。従って、プッシュ通知のコンテンツを検討するにあたって、どういった内容のプッシュ通知が、アプリのアンインストールにつながりやすいかを知ることは非常に重要である。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述のように、アプリをインストールしたユーザが、その後アプリをどの程度活用しているかの情報は非常に重要である。しかし、単純にアプリのダウンロード（インストール）件数や、アンインストール件数を把握するだけでは、不十分である。なぜなら、現実には、アプリをインストールした後、そのアプリを全く活用せず放置しておくユーザ（例：休眠ユーザ）もいるからである。
【００１０】
また、Ａｎｄｒｏｉｄ  ＯＳ用のアプリでは、アンインストール件数を計測する方法はあるが、１日単位での計測しかできず、それ以上細かい時間単位での計測はできない。
【００１１】
以上の事情に鑑みて、本発明では、特定の時間で休眠ユーザがアプリを起動した件数を把握することを目的とする。
【課題を解決するための手段】
【００１２】
プッシュ通知は、リモートプッシュ通知とサイレントプッシュ通知がある。携帯情報端末のアプリは、状態や設定に応じて、これらの通知に対して違った応答を示す。本発明は、この違いを利用する。
【００１３】
一側面において、本発明は以下の発明を包含する。
（発明１）
携帯情報端末にインストールされた特定のアプリの休眠ユーザの数の変化を計測するための方法であって、以下のステップを含む方法
（Ａ）  配信サーバーが、第一リクエストを仲介サーバーに送信するステップであって、前記第一リクエストは、第一のサイレントプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｂ）  前記配信サーバーが、第一フィードバックを前記携帯情報端末から受信するステップであって、前記第一フィードバックは前記第一のサイレントプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｃ）  前記配信サーバーが、前記第一フィードバックにもとづいて、前記特定のアプリが起動され且つプッシュ通知が許可されている携帯情報端末の数を計測するステップと、
（Ｄ）  前記配信サーバーが、第二リクエストを前記仲介サーバーに送信するステップであって、前記第二リクエストはリモートプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｅ）  前記配信サーバーが、第二フィードバックを前記携帯情報端末から受信するステップであって、前記第二フィードバックは前記リモートプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｆ）  前記配信サーバーが、前記第一フィードバックと前記第二フィードバックとにもとづいて、アプリが休眠状態にある携帯情報端末の数を計測するステップと、
（Ｇ）  前記配信サーバーが、第三リクエストを前記仲介サーバーに送信するステップであって、前記第三リクエストは第二のサイレントプッシュ通知を前記携帯情報端末に行うためのリクエストである、該ステップと、
（Ｈ）  前記配信サーバーが、第三フィードバックを前記携帯情報端末から受信するステップであって、前記第三フィードバックは前記第二のサイレントプッシュ通知を前記携帯情報端末が受信したかどうかを示す、該ステップと、
（Ｉ）  前記配信サーバーが、前記リモートプッシュ通知の後で前記特定のアプリが起動され且つプッシュ通知が許可状態になった携帯情報端末の数を集計するステップであって、前記集計は、前記第一フィードバックと前記第二フィードバックと前記第三フィードバックとにもとづいて行われる、該ステップ。
（発明２）
発明１に記載の方法であって、前記（Ｇ）のステップが、前記（Ｄ）のステップから１秒以上〜２４時間未満後に、実行される、該方法。
（発明３）
発明１又は２に記載の方法であって、前記（Ｇ）〜前記（Ｉ）のステップが、複数回実行される、該方法。
【発明の効果】
【００１４】
上述したように、本発明では、一側面において、リモートプッシュ通知の前後で、サイレントプッシュ通知を行う。これにより、アプリを起動したユーザの件数を把握することができる。また、本発明では、一側面において、リモートプッシュ通知後のサイレントプッシュ通知を、少なくとも２４時間未満に行う。これにより、１日単位よりも細かい時間単位で、アプリの休眠ユーザの数の変化を計測することができる。さらに、本発明では、一側面において、リモートプッシュ通知後のサイレントプッシュ通知を、複数回行う。これにより、特定の時間内で計測できない、アプリの休眠ユーザの数の変化を計測することができる。例えば、リモートプッシュ通知後、しばらくたってからアプリを起動したユーザの件数を知ることができる。
【図面の簡単な説明】
【００１５】
【図１】リモートプッシュ通知を表す図である。
【図２】本発明の一実施形態における、システムの構成を表す図である。
【図３】本発明の一実施形態において、休眠ユーザがアプリを起動した数を計測する処理を表すフローチャート図である。
【図４】アプリの起動状態を表す図である。
【発明を実施するための形態】
【００１６】
以下、本発明の詳細な説明を行う。以下で述べる具体的事例は、本発明の理解を促すための例示であり、本発明の範囲を限定するものではない。
【００１７】
定義
休眠ユーザとは、広義では、アプリを全く使用していないユーザということができるが、本明細書で述べる休眠ユーザとは、アプリをインストール後、少なくとも１度アプリを起動し、最後にそのアプリのプロセスを落とした状態（終了した状態）にあるユーザのことを指す。
【００１８】
一側面において、本発明が対象とする休眠ユーザは、アプリをインストール後、少なくとも１度アプリを起動し、最後にそのアプリのプロセスを落とした状態にあるユーザであり、且つ最終的にプッシュ通知が許可された状態のユーザである。言い換えれば、一側面における本発明は、異なる種類のプッシュ通知がなされた件数の差分を利用するため、そもそもプッシュ通知が許可されない状態にアプリを設定しているユーザについては、対象としない。
【００１９】
「アプリが起動状態にある」とは、端末の画面にそのアプリが表示されている状態のみならず、裏側でアプリが起動して実行されている状態も含む。例えば、図４にあるように、複数のアプリが起動している場合であっても、通常は画面に１つのアプリのみがフルスクリーン状態で表示されている（フォアグラウンド状態）。しかし、ｉＯＳ端末では、ホームボタンをダブルクリックすると、複数のアプリが並列表示され、いわゆる裏側で起動しているアプリの一覧が表示される（バックグラウンド状態）。従って、逆に言えば、「アプリが終了状態にある」とは、上記フォアグラウンド状態でも、バックグラウンド状態でもない状態をさす。
【００２０】
プッシュ通知は、プッシュ通知を配信する配信サーバーが、仲介サーバー（例えば、ＡＰＮｓ及びＧＣＭなどのサービスを司る仲介サーバー）を通して、各携帯情報端末に配信する。本明細書で述べるプッシュ通知には、二種類ある。一つはリモートプッシュ通知であり、もう１つはサイレントプッシュ通知である。リモートプッシュ通知は、携帯情報端末画面のバナーやダイアログに、コンテンツが表示されるタイプの通知である（図１）。言い換えれば、ユーザが目にする表示画面上に通知内容が明示される。サイレントプッシュ通知は、表示画面に特定のコンテンツを表示することなく、バックグラウンドでアップデート処理等を実行することができる通知である。例えば、ｉＯＳでは、ＯＳのバージョン７以降で、実装可能になった機能である。サイレントプッシュ通知の場合には、携帯情報端末側のアプリが終了状態の場合には、例えばプッシュ通知を許可する設定になっていたとしても、届かない。一方で、リモートプッシュ通知の場合には、プッシュ通知を許可する設定になっていさえすれば、携帯情報端末側のアプリが終了状態であっても届けることができる。
【００２１】
携帯情報端末
本発明で用いられる携帯情報端末は、プロセッサ、記憶装置、通信機能、及び表示機能を少なくとも備えた装置である。例えば、タブレット端末（例えば、ｉＰａｄ（登録商標））、スマートフォン、ノートＰＣなどが挙げられる。端末にインストールされるＯＳについては、特に限定されない。しかし、後述するプッシュ通知の機能をサポートするＯＳが望ましい。例えば、Ａｐｐｌｅ社が提供するｉＯＳや、Ｇｏｏｇｌｅ社が提供するＡｎｄｒｏｉｄ等が挙げられる。
【００２２】
プッシュ通知の概要
図２にプッシュ通知の概要を示す。プッシュ通知を配信するサーバーは、まず、仲介サーバーに、プッシュ通知を行うためのリクエストを送信する。ここで、配信サーバーは、アプリや携帯情報端末を特定するための情報（例：トークン）と共に、プッシュ通知する内容を仲介サーバーに送る。例えば、配信サーバーは、記憶部に、携帯情報端末を特定するための情報のリストと、プッシュ通知する内容とを記憶している。配信サーバー内のプロセッサは、携帯情報端末を特定するための情報とプッシュ通知する内容とを取り出す。そして、これらの情報を、配信サーバー内の通信モジュールを経由して、仲介サーバーに送信する。これを受けて、仲介サーバーは、各携帯情報端末にプッシュ通知を行う。各携帯情報端末は、プッシュ通知を受け取ったことを示すフィードバックを配信サーバーに送信する。フィードバックの内容は、通知に成功した場合には、配信サーバーに、プッシュ通知が成功した旨のレスポンスを送信する。一方で、アプリが起動していない等の理由で、通知に失敗した場合には、配信サーバーに、プッシュ通知が失敗した旨のレスポンスを送信する。いずれにせよ、フィードバックの内容は、少なくとも、以下の情報を含んでさえいれば任意の形式であってよい：通知対象の携帯情報端末を特定するための情報；通知内容を特定するための情報；及び、通知の結果（成功又は失敗）。なお、通知の失敗の場合には、必ずしもフィードバックが送信されなくてもよい。例えば、フィードバックが来なかったことをもって、通知が失敗したと判定してもよい。配信サーバー側は、通信モジュールを利用して、前記フィードバックを受け取る。そして、配信サーバーのプロセッサは、上記フィードバックを処理し（例えば集計処理し）、記憶部へ記憶する。後述するプッシュ通知のリクエスト送信やフィードバックの受信はこうした機構で実現できる。
【００２３】
休眠ユーザ数の変化の計測方法
図３において、休眠ユーザ数の変化を計測する方法を示す。まず、配信サーバーは、サイレントプッシュ通知を行う旨のリクエストを、仲介サーバーに送信する（ステップ１００）。仲介サーバーは、そのリクエストに基づいて、指定された携帯情報端末に、サイレントプッシュ通知を送信する（ステップ１１０）。携帯情報端末へのサイレントプッシュ通知は、携帯情報端末にインストールされたアプリの状態によって、挙動が変わる（ステップ１２０）。
【００２４】
携帯情報端末へアプリがインストールされた後、アンインストールされた場合又はプッシュ通知をオフにする設定がされた場合、サイレントプッシュ通知は携帯情報端末へは送信されない。従って、携帯情報端末は、サイレントプッシュ通知が送信できなかった旨のフィードバックを、配信サーバーに送信する（ステップ１３０）。あるいは、フィードバックが配信サーバーに来ないことを以て通知できなかったとみなすこともできる。
【００２５】
携帯情報端末へアプリがインストールされた後、アプリが起動された状態（バックグラウンド、又はフォアグラウンド）にある場合且つプッシュ通知をオンにする設定がされた場合、サイレントプッシュ通知は携帯情報端末へ送信される。従って、携帯情報端末は、サイレントプッシュ通知が送信された旨のフィードバックを、配信サーバーに送信する（ステップ１３０）。
【００２６】
配信サーバーは、前記フィードバックを受信し、サイレントプッシュ通知を携帯情報端末へ送信できた件数及び送信できなかった件数を計測する（ステップ１４０）。例えば、配信サーバーは、プッシュ通知対象の端末数と同一の件数だけ、フィードバックを受け取ることができる。その場合には、配信サーバー側で集計を行い、通知に成功した件数と失敗した件数を集計する。あるいは、配信サーバーは、プッシュ通知の成功件数だけ、フィードバックを受け取ることができる。この場合には、フィードバックの件数を通知成功の件数とみなし、通知対象とした携帯情報端末の件数から前記成功件数を引いた数を失敗した件数とみなすことができる。こうした一連の処理は、配信サーバーのプロセッサで行い、集計結果を記憶部に記憶することができる。
【００２７】
次に、配信サーバーは、リモートプッシュ通知を行う旨のリクエストを、仲介サーバーに送信する（ステップ１５０）。仲介サーバーは、そのリクエストに基づいて、指定された携帯情報端末に、リモートプッシュ通知を送信する（ステップ１６０）。携帯情報端末へのリモートプッシュ通知は、携帯情報端末にインストールされたアプリの状態によって、挙動が変わる（ステップ１７０）。
【００２８】
携帯情報端末でアプリがプッシュ通知を許可していない場合、リモートプッシュ通知は携帯情報端末へは送信されない。従って、携帯情報端末は、リモートプッシュ通知が送信できなかった旨のフィードバックを、配信サーバーに送信する（ステップ１８０）（あるいは、上記と同様フィードバックが全く返ってこない）。
【００２９】
携帯情報端末でアプリがプッシュ通知を許可されている場合、リモートプッシュ通知は携帯情報端末へ送信される。この場合、アプリが起動状態であっても終了状態であっても携帯情報端末へ送信される。従って、携帯情報端末は、リモートプッシュ通知が送信できた旨のフィードバックを、配信サーバーに送信する（ステップ１８０）。フィードバックの内容については、上述したサイレントプッシュ通知の場合と同様である。
【００３０】
配信サーバーは、上記これらのフィードバックに基づいて、送信できなかった携帯情報端末の数と、送信できた携帯情報端末の数を集計する（ステップ１９０）。ここで、配信サーバーは、１回目のフィードバックと２回目のフィードバックを用いて、アプリが休眠状態にある（より具体的には、プッシュ通知が許可状態にあるがアプリが休眠状態にある）端末の件数を計測する。例えば、１回目のフィードバックが１００個の端末にプッシュ通知を送信し６０個で通知成功した旨の内容であり、２回目のフィードバックが１００個の端末にプッシュ通知を送信し８０個で通知成功した旨の内容である場合を想定する。この場合、８０−６０＝２０として、２０個の端末ではアプリが休眠状態であることが分かる。即ち、２０個の端末ではプッシュ通知は許可されているが、アプリが終了された状態にあることが分かる。上記のような集計処理は、配信サーバー内のプロセッサによって実行でき、集計結果は記憶部に記憶することができる。また、集計結果とともに、アプリが休眠状態となっている携帯情報端末を特定するための情報を記憶部に記憶してもよい。
【００３１】
なお、上記のような計測を行うためには、１回目のサイレントプッシュ通知と、１回目のリモートプッシュ通知との間で、アプリの状態が変化しないことが前提となる。従って、１回目のサイレントプッシュ通知のリクエストと、１回目のリモートプッシュ通知のリクエストとの間は、ごく短い時間になるようにすることが好ましい。例えば、１秒以下、２秒以下、１０秒以下、又は１分以下となるようにすることが好ましい。
【００３２】
さらに、配信サーバーは、再度、サイレントプッシュ通知を行う旨のリクエストを、仲介サーバーに送信する（ステップ２００）。ここで、二回目のサイレントプッシュ通知のリクエストは、リモートプッシュ通知のリクエストから所定の時間経過した後で送信することができる。前記時間は特に限定されないが、例えば、少なくとも１秒〜２４時間経過した後に送信することができる（例えば、少なくとも１秒後、少なくとも１０秒後、少なくとも１分後、少なくとも１０分後、少なくとも６０分後、少なくとも１時間後、少なくとも６時間後、少なくとも１２時間後、最大で１０分後、最大で６０分後、最大で６時間後、最大で１２時間後、又は最大で２４時間）。
【００３３】
上述した一回目のサイレントプッシュ通知の場合と同様、仲介サーバーは、そのリクエストに基づいて、指定された携帯情報端末に、サイレントプッシュ通知を送信する（ステップ２１０）。そして、携帯情報端末は、サイレントプッシュ通知が送信された場合については、送信成功の旨のフィードバックを、配信サーバーに送信する（ステップ２３０）。一方で、サイレントプッシュ通知が送信されなかった場合については、フィードバックが返ってこない（ステップ２３０）。
【００３４】
例えば、リモートプッシュ通知を受けた休眠ユーザは、以降アプリを起動して使用するようになる可能性がある。そのような場合、第１回目のサイレントプッシュ通知では送信失敗であっても、第２回目のサイレントプッシュ通知では送信成功となる。従って、第１回目のサイレントプッシュ通知と第２回目のサイレントプッシュ通知の成功失敗を比較して、リモートプッシュ通知以降アプリを起動した休眠ユーザの件数を知ることができる。
【００３５】
例えば、第１回目のサイレントプッシュ通知失敗→第１回目のリモートプッシュ通知成功→第２回目のサイレントプッシュ通知成功となれば、そのユーザは、リモートプッシュ通知を受けた後、アプリを使用するようになったと言える。こうした仕組みは、どのような内容をリモートプッシュ通知で送れば、ユーザにアプリの利用を促すのに効果的かを調べるのに有用であろう。
【００３６】
例えば、１回目のフィードバックが１００個の端末にプッシュ通知を送信し６０個で通知成功した旨の内容であり、２回目のフィードバックが１００個の端末にプッシュ通知を送信し８０個で通知成功した旨の内容である場合、リモートプッシュ通知時においてアプリが休眠状態になっている端末は２０個である。ここで、これら２０個の端末に着目して、個々の端末に関する３回目のフィードバック内容をチェックする。もし、３回目のフィードバックにおいて、２回目のサイレントプッシュ通知が成功しているのであれば、カウントを＋１とする。もし、２回目のサイレントプッシュ通知が失敗しているのであれば、カウントを＋０とする。こうして、２０個の端末について＋１又は＋０をカウントして、２０個の端末のうちどの端末においてアプリが起動されたか、その合計数が算出できる。こうした集計作業は、配信サーバーのプロセッサによって実行でき、また集計結果を記憶部に記憶することができる。
【００３７】
以降、所定の時間をおいて、２回目のサイレントプッシュ通知の工程を何度か繰り返してもよい。これにより、リモートプッシュ通知後の、アプリの状態の変化を追跡することができる。例えば、ユーザがしばらく携帯情報端末から離れた場所におり、リモートプッシュ通知の存在に気が付かない場合がある。この場合、リモートプッシュ通知から１分後のサイレントプッシュ通知では、変化が検出できないかもしれない。しかし、例えば、１時間後に携帯情報端末をチェックして、リモートプッシュ通知の存在に気が付き、アプリを起動するかもしれない。こうした場合、１時間後のサイレントプッシュ通知では、そのアプリが起動されたことを検出できる。
【００３８】
以上具体例を挙げて、本発明の原理を説明してきたが、本発明の範囲は上記具体例に限定されるものではない。例えば、ｉＯＳではなく、Ａｎｄｒｏｉｄ等の他のＯＳでサイレントプッシュ通知がサポートされることになれば、上述したステップを実行することは可能であり、こうした変更も本発明の範囲内である。
【００３９】
例えば、図３では、各々のプッシュ通知の送信結果の集計は、携帯情報端末からプッシュ通知送信結果を受け取った直後のタイミングで行っている。しかし、集計作業の全体または一部は、２回目のサイレントプッシュ通知の送信結果を受け取った後で、まとめて行うことも可能であろう。
【図１】
2017045403.tif 000003
【図２】
2017045403.tif 000004
【図３】
2017045403.tif 000005
【図４】
2017045403.tif 000006