JP6577907B2 - 通信監視装置および通信監視方法 - Google Patents

Description

本発明は、スマートフォンなどのモバイル端末（以下、「端末」または「ユーザ端末」と呼ぶ場合がある）の情報配信の技術に関する。

スマートフォンなどのモバイル端末の普及に伴い、マスユーザへの効果的なアプローチ手段として、スマートフォンのアプリを用いたＰＵＳＨ通知（プッシュ通知）が使われている。

プッシュ通知に関する技術を開示した文献としては、例えば、非特許文献１がある。

"Androidで使えるO2O技術まとめ解説（1）：スマホ技術者も知らないと損する「O2O」の基礎知識 (5/5)"［online］、［平成28年6月2日検索］、インターネット<ＵＲＬ: http://www.atmarkit.co.jp/ait/articles/1209/07/news127_5.html>

しかし、多くのアプリでプッシュ通知が使われている現状では、多くのアプリを端末にインストールしているユーザにとって、プッシュ通知があるたびに着信情報を確認する、という所作は非常に煩雑である。その結果、現状では、プッシュ通知の訴求力は低下しており、端末未使用時（端末画面を見ていない時：スリープ状態）に受信したプッシュ通知は、（メールと同様に）見落とされる可能性が高い。

このような事情に鑑みて、本発明は、ユーザ端末で使われているプッシュ通知の訴求力を向上させることを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置であって、前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定し、前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知する判定部、を備える、ことを特徴とする。

また、請求項５に記載の発明は、配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置における通信監視方法であって、前記通信監視装置は、前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定するステップと、前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知するステップと、を実行する、ことを特徴とする。

請求項１，５に記載の発明によれば、サービス提供者が、通信監視装置を有する回線事業者等と連携可能となるシステムを構築することで、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末の使用中というタイミングを、通信監視装置から通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。

また、請求項２に記載の発明は、請求項１に記載の通信監視装置であって、前記判定部は、前記指示サーバを保有するサービス提供者が提供するアプリを使用した通信以外も含めて通信を確認したことで前記ユーザ端末が使用中であると判定した場合、前記指示サーバに、前記プッシュ通知の実施タイミングを通知する、ことを特徴とする。

請求項２に記載の発明によれば、サービス提供者だけでは、サービス提供者が提供するアプリを使用した通信以外の通信を直接的に把握することはできないところ、通信監視装置によって、そのような通信を間接的に把握することができるようになる。その結果、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末の使用中というタイミングを、通信監視装置からより頻繁に通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力をさらに向上させることができる。
また、請求項３に記載の発明は、請求項１または請求項２に記載の通信監視装置であって、前記判定部は、前記ユーザ端末からの通信のパケットヘッダに特定ＵＲＩ（Uniform Resource Identifier）が含まれている場合、前記指示サーバへの前記通知をする、ことを特徴とする。
また、請求項４に記載の発明は、請求項１または請求項２に記載の通信監視装置であって、前記判定部は、前記ユーザ端末からの通信のパケットペイロードに特定キーワードが含まれている場合、前記指示サーバへの前記通知をする、ことを特徴とする。

本発明によれば、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。

本実施形態のプッシュ通知を実現するシステムの全体構成図である。 本実施形態の通信監視装置の機能構成図である。 本実施形態の通信監視装置にて実行される全体処理を示すフローチャートである。 R_ID-ID_A紐付部の動作例を示すフローチャートである。 連携対象R_ID管理部の動作例を示すフローチャートである。 タイミング判断・共有部の動作例を示すフローチャートである。

本発明の実施形態について、図面を参照しながら詳細に説明する。

≪構成≫
図１に示すように、本実施形態のプッシュ通知を実現するシステムは、通信監視装置１と、ユーザ端末２と、指示サーバ３と、自社サービスサーバ３Ａと、配信サーバ４とを備えている。また、図１中の他サーバ５は、本実施形態のシステムに通信可能に接続している。

通信監視装置１は、ユーザ端末２で行われる通信を監視する装置である。通信監視装置１は、例えば、パケットカウンタやＤＰＩ（Deep Packet Inspection）装置である。通信監視装置１は、例えば、回線事業者やＩＳＰ（Internet Service Provider）業者（以下、「回線事業者等」と呼ぶ場合がある）が使用する。
なお、通信監視装置１は、制御部、記憶部、入力部、出力部といったハードウェアを有し、制御部が、記憶部に記憶されているプログラムを記憶部の記憶領域に展開し実行することにより、上記の機能部を実現し、さまざまな処理を実行することができる。本実施形態の通信監視装置１は、このようなソフトウェアとハードウェアの協働を実現することができる。

ユーザ端末２は、例えば、スマートフォンやタブレット端末である。ユーザ端末２は、所定のサービスを利用するユーザが使用する装置である。ユーザ端末２には、Ｗｅｂブラウザおよび複数種類のアプリがインストールされており、プッシュ通知を利用する機能を備えている。

指示サーバ３は、配信サーバ４にプッシュ通知を指示するサーバである。指示サーバ３は、ユーザに所定のサービスを提供するサービス事業者（説明の便宜上、「自社のサービス事業者」と呼ぶ場合がある）が使用する装置である。

自社サービスサーバ３Ａは、自社のサービス事業者が自社のサービスをユーザに提供するサーバである。ユーザ端末２には、自社のサービス事業者が開発したアプリがインストールされているとする。このアプリは、プッシュ通知を利用する機能を有する。

配信サーバ４は、指示サーバ３からの指示に従い、ユーザ端末２にプッシュ通知を実施するサーバである。配信サーバ４は、ユーザ端末２のＯＳ（Operating System）提供者が使用するサーバである。配信サーバ４は、プッシュ通知のＡＰＩ（Application Programming Interface）を公開している。

他サーバ５は、例えば、Ｗｅｂサーバや他社サービスサーバである。Ｗｅｂサーバは、ユーザ端末２のＷｅｂブラウジングによってＷｅｂページを公開することができる。他社サービスサーバは、自社サービスサーバ３Ａ以外のサービスサーバであって、自社のサービス事業者以外の他社サービス事業者が使用する。ユーザ端末２には、他社のサービス事業者が開発したアプリがインストールされているとする。このアプリは、プッシュ通知を利用する機能を有していてもよいし、有していなくてもよい。
なお、他社サービス事業者は、指示サーバ３と同等の機能を有する指示サーバ（図示せず）を有し、配信サーバ４にプッシュ通知を指示することができる。

プッシュ通知前の事前動作として、図１中のステップａ１〜ステップａ３の処理が実行される。すなわち、ステップａ１にて、ユーザ端末２の自社アプリ（以降単にアプリ）が、ユーザ端末２のアプリ自身を配信サーバ４に登録し、プッシュ通知用のR_IDの払い出しを配信サーバ４に要求する（R_ID払出要求）。R_IDは、プッシュ通知の実施に関して、指示サーバ３がユーザ端末２のアプリを識別するために配信サーバ４や指示サーバ３側で管理する識別子である。

次に、ステップａ２にて、配信サーバ４が、ユーザ端末２のアプリにR_IDを付与する。次に、ステップａ３にて、ユーザ端末２のアプリが、（通信監視装置１を介して、）指示サーバ３に対して、ユーザ端末２のアプリ自身のR_IDを送信する。このとき、サービス提供者の応用例として、ユーザ端末２のアプリは、指示サーバ３に対して、R_IDとともに、ユーザの年齢や性別などのユーザ属性情報を送信することもできる。

また、プッシュ通知時の動作として、図１中のステップｂ１〜ステップｂ４の処理が実行される。すなわち、ステップｂ１にて、（自社の）サービス事業者側で、ユーザに適した情報とタイミングが発生すると、ステップｂ２にて、指示サーバ３は、配信サーバ４に対してプッシュ通知を指示し、そのユーザのR_IDに向けて情報配信を依頼する。このとき、プッシュ通知の実施のタイミングを知るために、サービス提供者の応用例として、ユーザ端末２のアプリは、指示サーバ３に対して、ＧＰＳ（Global Positioning System）などによる位置情報を送信することができる。

次に、ステップｂ３にて、配信サーバ４は、ユーザ端末２に対してプッシュ通知を実施し、依頼のあった情報を配信する。次に、ステップｂ４にて、ユーザ端末２は、配信された情報を処理する。

回線事業者等は、ユーザにID_Aを付与している。ID_Aは、ユーザが利用する通信回線に関して、回線事業者等（通信監視装置１）がユーザを識別するために回線事業者等（通信監視装置１）側で管理する識別子である。R_IDが送信される際（ステップａ３）、通信監視装置１は、R_IDとID_Aとを紐付けることができる（詳細は後記）。図１中のステップｃ１に示すように、ユーザ端末２は、サービスを利用するために自社サービスサーバ３Ａまたは他サーバ５の他社サービスサーバと通信したり、Ｗｅｂブラウジングによって他サーバ５のＷｅｂサーバと通信したりすることができる。このとき、図１中のステップｃ２に示すように、通信監視装置１は、ユーザ端末２から、自社サービスサーバ３Ａまたは他サーバ５への通信の通信状況に基づいて、指示サーバ３に対して、プッシュ通知の実施の最適なタイミングを通知することができる（詳細は後記）。

すでに説明したとおり、プッシュ通知を利用するアプリがユーザ端末２に多数インストールされている現状では、プッシュ通知の訴求力は低下している。このため、ユーザ端末２の未使用時にプッシュ通知を実施しても、配信した情報が見落とされる可能性が高い。そこで、ユーザ端末２の使用中のタイミングを見計らってプッシュ通知を実施したほうがよいという着想が生まれる。しかし、ユーザ端末２の使用中の判定は、決して容易ではない。なお、「ユーザ端末２の使用中」（ユーザ端末２の使用時：端末使用時）とは、ユーザが端末画面を見ている時、端末画面が表示中である時、または、ロック解除中をいう。また、「ユーザ端末２の未使用時」（端末未使用時）とは、ユーザが端末画面を見ていない時、端末画面が無表示である時（スリープ状態）、または、ロック作動中をいう。プッシュ通知の実施タイミングについて、以下の＜１＞〜＜４＞の事項に留意する。

＜１＞まず、ユーザ端末２が使用中であるか否かを特に考慮せず、ユーザに適した情報が発生したときに即時でプッシュ通知を行う方法がある。この場合、プッシュ通知を最速にすることができる、というメリットはある。しかし、ユーザがユーザ端末２を触っている可能性は最も小さく、プッシュ通知の訴求力は極めて小さいと考えられる。

＜２＞また、プッシュ通知を実施する時間帯を指定する方法がある。例えば、電車内ユーザがユーザ端末２を触っていると見込まれる通勤時間帯にプッシュ通知の実施タイミングとする。しかし、通勤時間帯であってもユーザ端末２を触っていないユーザもある程度の割合で存在しており、プッシュ通知の訴求力はそれほど高いとはいえない。

＜３＞また、プッシュ通知を実施する特定エリアを指定し、ＧＰＳ、ＷｉＦｉ（登録商標）、ＢＬＥ（Bluetooth（登録商標） Low Energy）などのセンサ情報を利用して、特定エリアへの出入りや滞在を監視する方法がある。この方法によれば、特定エリアと連動したタイムリーな情報配信（例：名産品のＰＲ）を行うことができる、というメリットはある。しかし、ユーザが移動中であることからユーザ端末２を触っていない可能性があり、プッシュ通知の高い訴求力を望むことができない。また、各種センサ情報の利用は、ユーザの許可をとる必要があるため、プライバシーの観点などから、自社アプリのインストールの障害になり得る。また、定期的なセンサ情報の収集や自社サービスサーバへの収集情報の送信となると、バッテリの消費が懸念されるが、バックグラウンド動作でバッテリの消費が多いとアプリがアンインストールされる可能性が高くなる。つまり、プッシュ通知とは直接的に関係ない不都合な事情が存在する。

＜４＞また、自社（サービス提供者）のアプリを利用しているときにプッシュ通知を行う方法がある。自社サービスサーバ３Ａは自社アプリの利用時にはユーザが自社アプリを使っていることをユーザ端末２から取得することができ、ユーザがユーザ端末２を確実に触っており、プッシュ通知の実施の最適なタイミングを指示サーバ３に通知することができる。しかし、例えば、自社アプリが、ユーザが頻繁に利用するものではない場合、自社のサービス提供者がプッシュ通知の最適なタイミングを知る機会が少ない。

上記の事情に鑑みて、自社アプリの利用時以外の利用時、例えば、他社のアプリが利用されていたり、標準のＷｅｂブラウザが利用されていたりする時にプッシュ通知をできるようにし、プッシュ通知の最適なタイミングを知る機会を増やしたい、という要望がある。そこで、本実施形態では、自社のサービス提供者が、通信監視装置１を使用する回線事業者やＩＳＰ業者と連携し、ユーザがユーザ端末２を利用している、例えば、端末画面を見ている可能性が高いタイミングを通信監視装置１から通知してもらい、そのタイミングでプッシュ通知を実施する構成を実現する。

通信監視装置１の構成について説明する。
図２に示すように、通信監視装置１は、R_ID-ID_A紐付部１１と、連携対象R_ID管理部１２と、タイミング判断・共有部１３（判定部）と、ユーザ認証部１４と、中継部１５と、ＩＤ対応テーブルＴ１と、通信確認対象ユーザ登録テーブルＴ２と、いった機能部を備える。なお、ユーザ端末２は、自社のサービス提供者が開発したアプリである提供者アプリ２１と、他社のサービス提供者が開発したアプリである他社アプリ２２と、Ｗｅｂブラウザ２３をインストールしており、通信部２４によって、（通信監視装置１を介して、）指示サーバ３、自社サービスサーバ３Ａ、および他サーバ５とやり取りすることができる。

R_ID-ID_A紐付部１１は、同一ユーザについて、プッシュ通知前の事前動作の際（図１のステップａ１〜ステップａ３参照）に配信サーバ４から払い出され、ユーザ端末２から取得したR_IDと、回線事業者等側（通信監視装置１側）で予め管理しているID_Aとを紐付ける。R_ID-ID_A紐付部１１は、紐付けの結果をＩＤ対応テーブルＴ１に登録する。

連携対象R_ID管理部１２は、サービス提供者がプッシュ通知の実施タイミングを知りたいユーザのR_IDを指示サーバ３から受信して管理する。連携対象R_ID管理部１２は、指示サーバ３から受信したR_IDを連携対象R_IDとして管理する。連携対象R_ID管理部１２は、サービス提供者から連携対象R_IDの一覧をオンラインで取得することもできるし、オフラインで取得することもできる。また、連携対象R_ID管理部１２は、取得したR_IDをID_Aに変換して管理してもよい。

タイミング判断・共有部１３は、ユーザ端末２の通信状況からユーザ端末２が使用中であるか否かを判定する。また、タイミング判断・共有部１３は、ユーザ端末２が使用中であると判定した場合、指示サーバ３に、プッシュ通知の実施タイミングを通知し、回線事業者等とサービス提供者との間で、プッシュ通知の実施タイミングを共有する。タイミング判断・共有部１３は、ユーザ端末２が使用中であるか否かを判定する対象となるユーザを通信確認対象ユーザ登録テーブルＴ２から特定する。

ユーザ認証部１４は、通信を行うユーザを認証する。
中継部１５は、通信監視装置１と、指示サーバ３、自社サービスサーバ３Ａ、および他サーバ５との間の情報のやり取りを中継する。

ＩＤ対応テーブルＴ１は、本実施形態のシステムによってサービスを利用するユーザごとに、R_IDとID_Aとを対応付けて管理するテーブルである。
通信確認対象ユーザ登録テーブルＴ２は、本実施形態のシステムによってサービスを利用するユーザのうち、サービス事業者が、プッシュ通知の実施タイミングを知りたいとするユーザとなる通信確認対象ユーザごとに、R_IDとID_Aとサービス事業者とを対応付けて管理するテーブルである。

（タイミング判断・共有部１３のバリエーション）
［１−１］：例えば、タイミング判断・共有部１３は、通信確認対象ユーザに対して、パケットカウンタなどでユーザ端末２の通信量を確認し、通信量が増大したタイミングでユーザ端末２が使用中であると判定し、指示サーバ３に通知する。ここで、通信には、ユーザ端末２でのバックグラウンド通信も含まれるので、例えば、平常時のバックグラウンド通信量を測定し、バックグラウンド通信量を差し引いた通信量で、ユーザ端末２が使用中であるか否かを判定するとよい。

［１−２］：また、例えば、タイミング判断・共有部１３は、ＤＰＩでユーザ端末２からの通信のパケットヘッダやペイロードを解析し、バックグラウンド特有の通信でない通信（例えば、バックグラウンド通信のときに動作する特定サーバ以外のサーバとの通信）が検出された場合、ユーザ端末２が使用中であると判定し、指示サーバ３に通知するとよい。

［１−３］：また、例えば、タイミング判断・共有部１３は、サービス提供者からR_IDと特定ＵＲＩ（Uniform Resource Identifier）とのペアの一覧情報を予め取得しておき、ＤＰＩでユーザ端末２からの通信のパケットヘッダを確認し、取得した特定ＵＲＩがパケットヘッダに含まれている場合、ユーザ端末２が使用中であると判定し、指示サーバ３に通知するとよい。これにより、例えば、自動車に興味があるユーザにプッシュ通知したい場合、ユーザ端末２が自動車の情報を扱うＵＲＩへのアクセスの最中にプッシュ通知することができる。［１−３］の場合、連携対象R_ID管理部１２は、サービス提供者から連携対象R_IDとともに、特定ＵＲＩを取得し、管理してもよい。

［１−４］：また、例えば、タイミング判断・共有部１３は、サービス提供者からR_IDと特定キーワードとのペアの一覧情報を予め取得しておき、ＤＰＩでユーザ端末２からの通信のパケットペイロードを確認し、取得した特定キーワードがパケットペイロードに含まれている場合、ユーザ端末２が使用中であると判定し、指示サーバ３に通知するとよい。これにより、例えば、自動車に興味があるユーザにプッシュ通知したい場合、ユーザ端末２が自動車の情報を扱うＷｅｂページをブラウジングしている最中にプッシュ通知することができる。［１−４］の場合、連携対象R_ID管理部１２は、サービス提供者から連携対象R_IDとともに、キーワードを取得し、管理してもよい。

（R_ID-ID_A紐付部１１のバリエーション）
［２−１−１］：例えば、R_ID-ID_A紐付部１１は、ＤＰＩで提供者アプリ２１とサービス提供者との間の通信からR_IDを検出した場合などに、検出したR_IDと、通信監視装置１側で予め管理しているID_Aとを、オンラインでまたはリアルタイムで紐付けて、管理してもよい。

［２−１−２］：また、例えば、R_ID-ID_A紐付部１１は、ユーザ端末２からの通信のログや会員情報（例：ユーザの氏名）などを、ID_Aに突き合わせたり、ユーザ端末２のアプリ２１，２２からR_IDを直接通知（別送）してもらったりすることで、R_IDとID_Aとを、ＤＰＩ未利用で紐付けて、管理してもよい。

［２−２−１］：例えば、R_ID-ID_A紐付部１１は、ID_Aと紐付けるR_IDを受け付ける受付部として機能する際、この受付部をサービス提供者ごとに設置する形態をとることができる。
［２−２−１］の形態をとる場合、［２−１−１］のバリエーションについては、各受付部のＩＰアドレスで通信パケットの送信先アドレス（サービスサーバのアドレス）をフィルタリング等して、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。また、［２−１−２］のバリエーションについては、各受付部のアクセスログと、回線事業者等でのＤＨＣＰ／ＮＡＴログなどとを突き合わせることで、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。

［２−２−２］：例えば、R_ID-ID_A紐付部１１は、ID_Aと紐付けるR_IDを受け付ける受付部として機能する際、この受付部を回線事業者等が一元的に設置する形態をとり、この受付部が、サービス提供者の識別子を用いて、アプリから別送される通信や、サービス提供者への通信を１次受付して中継することができる。
［２−２−２］の形態をとる場合、［２−１−１］のバリエーションについては、回線事業者等のこの受付部のＩＰアドレスで通信パケットの送信先アドレス（サービスサーバのアドレス）をフィルタリング等して、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。また、［２−１−２］のバリエーションについては、回線事業者等この受付部のアクセスログと、回線事業者等でのＤＨＣＰ／ＮＡＴログなどとを突き合わせることで、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。

≪処理≫
次に、通信監視装置１の処理について説明する。
図３に示すように、通信監視装置１の全体処理は、以下の通りである。

まず、R_ID-ID_A紐付部１１が、ＩＤ対応テーブルＴ１を、所定の時間間隔で常時更新する（ステップＳ１）。例えば、通信監視装置１側で管理され、ＩＤ対応テーブルＴ１に登録されているID_Aに対して、対応するR_IDを通信監視装置１が取得した場合、取得したR_IDを、ＩＤ対応テーブルＴ１の対応のID_Aに紐付ける。

次に、連携対象R_ID管理部１２が、所定のサービス提供者から提示された連携対象R_IDを受信する（ステップＳ２）。

次に、タイミング判断・共有部１３が、連携対象R_IDに該当するユーザを通信確認対象ユーザとして通信確認対象ユーザ登録テーブルＴ２に追加する（ステップＳ３）。例えば、ＩＤ対応テーブルＴ１中に、連携対象R_IDに該当するユーザのID_Aが存在する場合、タイミング判断・共有部１３は、このID_Aを通信確認対象ユーザ登録テーブルＴ２に登録して通信確認対象ユーザを追加する。
もし、ＩＤ対応テーブルＴ１中に、連携対象R_IDに該当するユーザのID_Aが存在しない場合、まず、タイミング判断・共有部１３は、連携対象R_IDとしてのR_IDを通信確認対象ユーザ登録テーブルＴ２に追加する。そして、ステップＳ１による更新タイミングで、連携対象R_IDに対応するID_Aが新たに出現したときに、タイミング判断・共有部１３は、このID_Aを通信確認対象ユーザ登録テーブルＴ２に登録して通信確認対象ユーザを追加する。

次に、タイミング判断・共有部１３が、通信確認対象ユーザ登録テーブルＴ２に登録されている通信確認対象ユーザの通信を確認する（ステップＳ４）。
次に、タイミング判断・共有部１３が、通信確認対象ユーザのユーザ端末２が使用中であるか否かを判定し、使用中と判定した場合、プッシュ通知の実施タイミングを指示サーバ３に通知する（ステップＳ５）。この通知により、通信確認対象ユーザのR_IDは、回線事業者等とサービス提供者との間で共有される。

その後、指示サーバ３は、配信サーバ４（図１）にプッシュ通知を指示し、配信サーバ４によるプッシュ通知が実施される。このプッシュ通知は、ユーザ端末２が使用中、例えばユーザが端末画面を見ているときになされるので、ユーザはプッシュ通知をプッシュ通知が実施された時点で確実に認識し、プッシュ通知で配信された情報に即座にアクセスすることができる。

図３の全体処理を実行するためのR_ID-ID_A紐付部１１の動作例について説明する。
図４に示すように、R_ID-ID_A紐付部１１の動作例は、以下の通りである。

まず、R_ID-ID_A紐付部１１は、ネットワーク上の通信を常時監視する（ステップＡ１）。例えば、R_ID-ID_A紐付部１１は、不特定のユーザ端末２の通信により発生したパケットを定期的に取得して解析することで監視する。

次に、R_ID-ID_A紐付部１１は、取得したパケット内にR_IDが含まれているか否かを判定する（ステップＡ２）。含まれていない場合（ステップＡ２／Ｎｏ）、ステップＡ１に戻って、通信の監視を継続する。

一方、取得したパケット内にR_IDが含まれている場合（ステップＡ２／Ｙｅｓ）、R_ID-ID_A紐付部１１は、そのR_IDと、取得したパケットを通信したユーザ端末２のユーザ（通信者）のID_AをＩＤ対応テーブルＴ１に追加し、登録する（ステップＡ３）。

次に、R_ID-ID_A紐付部１１は、R_IDが、プッシュ通知の実施タイミングを判定するために必要となる監視の監視対象であるか否かを判定する（ステップＡ４）。例えば、ステップＡ３での追加の前では、R_IDがＩＤ対応テーブルＴ１にあったが、そのR_IDに対応のID_Aが空欄であったときには、R_IDが監視対象となる。監視対象でない場合（ステップＡ４／Ｎｏ）、ステップＡ１に戻って、通信の監視を継続する。

一方、R_IDが監視対象となる場合（ステップＡ４／Ｙｅｓ）、R_ID-ID_A紐付部１１は、ＩＤ対応テーブルＴ１に追加した（ステップＡ３参照）ID_Aを通信確認対象ユーザ登録テーブルＴ２に追加し、追加したID_Aに該当するユーザを通信確認対象ユーザとする（ステップＡ５）。
図４の処理によれば、プッシュ通知の実施タイミングを通知するために通信確認するユーザを特定することができる。

図３の全体処理を実行するための連携対象R_ID管理部１２の動作例について説明する。
図５に示すように、連携対象R_ID管理部１２の動作例は、以下の通りである。

まず、連携対象R_ID管理部１２は、特定のサービス提供者（の指示サーバ３など）から、当該サービス提供者が指定した１または複数の連携対象R_IDを取得し、回線事業者等とサービス提供者との間で連携対象R_IDを共有する（ステップＢ１）。

次に、共有された連携対象R_IDに対して、以下のステップＢ３〜Ｂ５のループ処理を実行する（ステップＢ２）。
連携対象R_ID管理部１２は、連携対象R_IDに対応するID_Aが、ＩＤ対応テーブルＴ１内に有るか否かを判定する（ステップＢ３）。

ID_Aが有る場合（ステップＢ３／Ｙｅｓ）、連携対象R_ID管理部１２は、そのID_Aを通信確認対象ユーザ登録テーブルＴ２に追加し、追加したID_Aに該当するユーザを通信確認対象ユーザとする（ステップＢ４）。結果的に、通信確認対象ユーザ登録テーブルＴ２には、共有された連携対象R_IDとしてのR_IDと、ID_Aと、連携対象R_IDを指定したサービス提供者の識別子とが関連付けられて登録される。
その後、他の連携対象R_IDについてループ処理を進めるか、他の連携対象R_IDが存在しなければ、図５の処理を終了する。

ID_Aが無い場合（ステップＢ３／Ｎｏ）、連携対象R_ID管理部１２は、共有された連携対象R_IDとしてのR_IDをＩＤ対応テーブルＴ１に追加する（ステップＢ５）。追加されたR_IDに対応するID_Aは暫定的に空欄となるが、通信を関してそのID_Aが発見されたときに補充される。
その後、他の連携対象R_IDについてループ処理を進めるか、他の連携対象R_IDが存在しなければ、図５の処理を終了する。
図５の処理によれば、サービス提供者が指定した１または複数の連携対象R_IDを、回線業者等側で管理することができる。

図３の全体処理を実行するためのタイミング判断・共有部１３の動作例について説明する。
図６に示すように、タイミング判断・共有部１３の動作例は、以下の通りである。

まず、タイミング判断・共有部１３は、常時、通信確認対象ユーザの各々に対して、以下のステップＣ２〜Ｃ４のループ処理を実行する（ステップＣ１）。

タイミング判断・共有部１３は、通信確認対象ユーザのユーザ端末２の通信を監視する（ステップＣ２）。
次に、タイミング判断・共有部１３は、通信確認対象ユーザのユーザ端末２が使用中であるか否かを判定する（ステップＣ３）。使用中でないと判定した場合（ステップＣ３／Ｎｏ）、ステップＣ１に戻り、他の通信確認対象ユーザについてループ処理を実行する。

一方、使用中であると判定した場合（ステップＣ３／Ｙｅｓ）、サービス提供者の指示サーバ３に、通信確認対象ユーザのR_IDを通知し、通信確認対象ユーザのR_IDを、回線業者等とサービス提供者との間で共有する（ステップＣ４）。
その後、ステップＣ１に戻り、他の通信確認対象ユーザについてループ処理を実行する。すべての通信確認対象ユーザについてループ処理が完了した場合、図６の処理（常時処理の一回）を終了する。

図６の処理によれば、サービス提供者が連携対象R_IDとして指定したユーザを通信確認対象ユーザとして、ユーザ端末２の使用中を判定し、プッシュ通知の実施タイミングを回線業者等から通知してもらうことができる。

≪まとめ≫
本実施形態によれば、サービス提供者が、通信監視装置１を有する回線事業者等と連携可能となるシステムを構築することで、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末２の使用中というタイミングを、通信監視装置１から通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。
その結果、ユーザ端末２側で配信サーバ４からのプッシュ通知の開封率は向上する。サービスを利用するユーザによるプッシュ通知の見落としは減少する。プッシュ通知で配信された情報が活用されれば、サービス提供者や回線事業者等の利益の向上が見込まれ、ユーザへの最終的な利益還元の可能性が高まる。
また、タイミング判断・共有部１３のバリエーション［１−３］，［１−４］による判断ロジックを採用すれば、特定の情報に興味を持つユーザに絞ってプッシュ通知を行うことができるので、一定の原資で通常よりも多くの特典をユーザに提供することもできる。

また、サービス提供者だけでは、サービス提供者が提供するアプリを使用した通信以外の通信を直接的に把握することはできないところ、通信監視装置１によって、そのような通信を間接的に把握することができるようになる。その結果、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末２の使用中というタイミングを、通信監視装置１からより頻繁に通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力をさらに向上させることができる。

本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
例えば、本実施形態では、サービス提供者は、通信監視装置１の回線事業者等から他社のアプリの通信によるユーザ端末２の使用中を通知してもらった。しかし、複数のサービス提供者が所持するサービスサーバ間で、各社のアプリの通信が行われてユーザ端末２が使用中であることを相互に通知し合って、サービス提供者の各々が、プッシュ通知の最適な実施タイミングを数多く獲得することができるようにしてもよい。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、処理手順などについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ 通信監視装置
２ ユーザ端末
３ 指示サーバ
３Ａ 自社サービスサーバ
４ 配信サーバ
５ 他サーバ
１１ R_ID-ID_A紐付部
１２ 連携対象R_ID管理部
１３ タイミング判断・共有部（判定部）

Claims (5)

1. 配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置であって、
   前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定し、前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知する判定部、を備える、
   ことを特徴とする通信監視装置。
2. 前記判定部は、
   前記指示サーバを保有するサービス提供者が提供するアプリを使用した通信以外も含めて通信を確認したことで前記ユーザ端末が使用中であると判定した場合、前記指示サーバに、前記プッシュ通知の実施タイミングを通知する、
   ことを特徴とする請求項１に記載の通信監視装置。
3. 前記判定部は、
   前記ユーザ端末からの通信のパケットヘッダに特定ＵＲＩ（Uniform Resource Identifier）が含まれている場合、前記指示サーバへの前記通知をする、
   ことを特徴とする請求項１または請求項２に記載の通信監視装置。
4. 前記判定部は、
   前記ユーザ端末からの通信のパケットペイロードに特定キーワードが含まれている場合、前記指示サーバへの前記通知をする、
   ことを特徴とする請求項１または請求項２に記載の通信監視装置。
5. 配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置における通信監視方法であって、
   前記通信監視装置は、
   前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定するステップと、
   前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知するステップと、を実行する、
   ことを特徴とする通信監視方法。

Images