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

通信監視装置および通信監視方法 Download PDF

Info

Publication number
JP6577907B2
JP6577907B2 JP2016112010A JP2016112010A JP6577907B2 JP 6577907 B2 JP6577907 B2 JP 6577907B2 JP 2016112010 A JP2016112010 A JP 2016112010A JP 2016112010 A JP2016112010 A JP 2016112010A JP 6577907 B2 JP6577907 B2 JP 6577907B2
Authority
JP
Japan
Prior art keywords
communication
user terminal
server
push notification
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016112010A
Other languages
English (en)
Other versions
JP2017220720A (ja
Inventor
直人 日高
直人 日高
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2016112010A priority Critical patent/JP6577907B2/ja
Publication of JP2017220720A publication Critical patent/JP2017220720A/ja
Application granted granted Critical
Publication of JP6577907B2 publication Critical patent/JP6577907B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Telephonic Communication Services (AREA)

Description

本発明は、スマートフォンなどのモバイル端末(以下、「端末」または「ユーザ端末」と呼ぶ場合がある)の情報配信の技術に関する。
スマートフォンなどのモバイル端末の普及に伴い、マスユーザへの効果的なアプローチ手段として、スマートフォンのアプリを用いたPUSH通知(プッシュ通知)が使われている。
プッシュ通知に関する技術を開示した文献としては、例えば、非特許文献1がある。
"Androidで使えるO2O技術まとめ解説(1):スマホ技術者も知らないと損する「O2O」の基礎知識 (5/5)"[online]、[平成28年6月2日検索]、インターネット<URL: http://www.atmarkit.co.jp/ait/articles/1209/07/news127_5.html>
しかし、多くのアプリでプッシュ通知が使われている現状では、多くのアプリを端末にインストールしているユーザにとって、プッシュ通知があるたびに着信情報を確認する、という所作は非常に煩雑である。その結果、現状では、プッシュ通知の訴求力は低下しており、端末未使用時(端末画面を見ていない時:スリープ状態)に受信したプッシュ通知は、(メールと同様に)見落とされる可能性が高い。
このような事情に鑑みて、本発明は、ユーザ端末で使われているプッシュ通知の訴求力を向上させることを課題とする。
前記した課題を解決するため、請求項1に記載の発明は、配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置であって、前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定し、前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知する判定部、を備える、ことを特徴とする。
また、請求項に記載の発明は、配信サーバからのプッシュ通知を受けるユーザ端末の通信を監視する通信監視装置における通信監視方法であって、前記通信監視装置は、前記ユーザ端末の通信状況から前記ユーザ端末が使用中であるか否かを判定するステップと、前記ユーザ端末の通信量からバックグラウンド通信量を差し引いた通信量が増大したことで使用中と判定した場合、前記配信サーバに前記プッシュ通知を指示する指示サーバに、前記プッシュ通知の実施タイミングを通知するステップと、を実行する、ことを特徴とする。
請求項1,に記載の発明によれば、サービス提供者が、通信監視装置を有する回線事業者等と連携可能となるシステムを構築することで、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末の使用中というタイミングを、通信監視装置から通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。
また、請求項2に記載の発明は、請求項1に記載の通信監視装置であって、前記判定部は、前記指示サーバを保有するサービス提供者が提供するアプリを使用した通信以外も含めて通信を確認したことで前記ユーザ端末が使用中であると判定した場合、前記指示サーバに、前記プッシュ通知の実施タイミングを通知する、ことを特徴とする。
請求項2に記載の発明によれば、サービス提供者だけでは、サービス提供者が提供するアプリを使用した通信以外の通信を直接的に把握することはできないところ、通信監視装置によって、そのような通信を間接的に把握することができるようになる。その結果、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末の使用中というタイミングを、通信監視装置からより頻繁に通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力をさらに向上させることができる。
また、請求項3に記載の発明は、請求項1または請求項2に記載の通信監視装置であって、前記判定部は、前記ユーザ端末からの通信のパケットヘッダに特定URI(Uniform Resource Identifier)が含まれている場合、前記指示サーバへの前記通知をする、ことを特徴とする。
また、請求項4に記載の発明は、請求項1または請求項2に記載の通信監視装置であって、前記判定部は、前記ユーザ端末からの通信のパケットペイロードに特定キーワードが含まれている場合、前記指示サーバへの前記通知をする、ことを特徴とする。
本発明によれば、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。
本実施形態のプッシュ通知を実現するシステムの全体構成図である。 本実施形態の通信監視装置の機能構成図である。 本実施形態の通信監視装置にて実行される全体処理を示すフローチャートである。 R_ID-ID_A紐付部の動作例を示すフローチャートである。 連携対象R_ID管理部の動作例を示すフローチャートである。 タイミング判断・共有部の動作例を示すフローチャートである。
本発明の実施形態について、図面を参照しながら詳細に説明する。
≪構成≫
図1に示すように、本実施形態のプッシュ通知を実現するシステムは、通信監視装置1と、ユーザ端末2と、指示サーバ3と、自社サービスサーバ3Aと、配信サーバ4とを備えている。また、図1中の他サーバ5は、本実施形態のシステムに通信可能に接続している。
通信監視装置1は、ユーザ端末2で行われる通信を監視する装置である。通信監視装置1は、例えば、パケットカウンタやDPI(Deep Packet Inspection)装置である。通信監視装置1は、例えば、回線事業者やISP(Internet Service Provider)業者(以下、「回線事業者等」と呼ぶ場合がある)が使用する。
なお、通信監視装置1は、制御部、記憶部、入力部、出力部といったハードウェアを有し、制御部が、記憶部に記憶されているプログラムを記憶部の記憶領域に展開し実行することにより、上記の機能部を実現し、さまざまな処理を実行することができる。本実施形態の通信監視装置1は、このようなソフトウェアとハードウェアの協働を実現することができる。
ユーザ端末2は、例えば、スマートフォンやタブレット端末である。ユーザ端末2は、所定のサービスを利用するユーザが使用する装置である。ユーザ端末2には、Webブラウザおよび複数種類のアプリがインストールされており、プッシュ通知を利用する機能を備えている。
指示サーバ3は、配信サーバ4にプッシュ通知を指示するサーバである。指示サーバ3は、ユーザに所定のサービスを提供するサービス事業者(説明の便宜上、「自社のサービス事業者」と呼ぶ場合がある)が使用する装置である。
自社サービスサーバ3Aは、自社のサービス事業者が自社のサービスをユーザに提供するサーバである。ユーザ端末2には、自社のサービス事業者が開発したアプリがインストールされているとする。このアプリは、プッシュ通知を利用する機能を有する。
配信サーバ4は、指示サーバ3からの指示に従い、ユーザ端末2にプッシュ通知を実施するサーバである。配信サーバ4は、ユーザ端末2のOS(Operating System)提供者が使用するサーバである。配信サーバ4は、プッシュ通知のAPI(Application Programming Interface)を公開している。
他サーバ5は、例えば、Webサーバや他社サービスサーバである。Webサーバは、ユーザ端末2のWebブラウジングによってWebページを公開することができる。他社サービスサーバは、自社サービスサーバ3A以外のサービスサーバであって、自社のサービス事業者以外の他社サービス事業者が使用する。ユーザ端末2には、他社のサービス事業者が開発したアプリがインストールされているとする。このアプリは、プッシュ通知を利用する機能を有していてもよいし、有していなくてもよい。
なお、他社サービス事業者は、指示サーバ3と同等の機能を有する指示サーバ(図示せず)を有し、配信サーバ4にプッシュ通知を指示することができる。
プッシュ通知前の事前動作として、図1中のステップa1〜ステップa3の処理が実行される。すなわち、ステップa1にて、ユーザ端末2の自社アプリ(以降単にアプリ)が、ユーザ端末2のアプリ自身を配信サーバ4に登録し、プッシュ通知用のR_IDの払い出しを配信サーバ4に要求する(R_ID払出要求)。R_IDは、プッシュ通知の実施に関して、指示サーバ3がユーザ端末2のアプリを識別するために配信サーバ4や指示サーバ3側で管理する識別子である。
次に、ステップa2にて、配信サーバ4が、ユーザ端末2のアプリにR_IDを付与する。次に、ステップa3にて、ユーザ端末2のアプリが、(通信監視装置1を介して、)指示サーバ3に対して、ユーザ端末2のアプリ自身のR_IDを送信する。このとき、サービス提供者の応用例として、ユーザ端末2のアプリは、指示サーバ3に対して、R_IDとともに、ユーザの年齢や性別などのユーザ属性情報を送信することもできる。
また、プッシュ通知時の動作として、図1中のステップb1〜ステップb4の処理が実行される。すなわち、ステップb1にて、(自社の)サービス事業者側で、ユーザに適した情報とタイミングが発生すると、ステップb2にて、指示サーバ3は、配信サーバ4に対してプッシュ通知を指示し、そのユーザのR_IDに向けて情報配信を依頼する。このとき、プッシュ通知の実施のタイミングを知るために、サービス提供者の応用例として、ユーザ端末2のアプリは、指示サーバ3に対して、GPS(Global Positioning System)などによる位置情報を送信することができる。
次に、ステップb3にて、配信サーバ4は、ユーザ端末2に対してプッシュ通知を実施し、依頼のあった情報を配信する。次に、ステップb4にて、ユーザ端末2は、配信された情報を処理する。
回線事業者等は、ユーザにID_Aを付与している。ID_Aは、ユーザが利用する通信回線に関して、回線事業者等(通信監視装置1)がユーザを識別するために回線事業者等(通信監視装置1)側で管理する識別子である。R_IDが送信される際(ステップa3)、通信監視装置1は、R_IDとID_Aとを紐付けることができる(詳細は後記)。図1中のステップc1に示すように、ユーザ端末2は、サービスを利用するために自社サービスサーバ3Aまたは他サーバ5の他社サービスサーバと通信したり、Webブラウジングによって他サーバ5のWebサーバと通信したりすることができる。このとき、図1中のステップc2に示すように、通信監視装置1は、ユーザ端末2から、自社サービスサーバ3Aまたは他サーバ5への通信の通信状況に基づいて、指示サーバ3に対して、プッシュ通知の実施の最適なタイミングを通知することができる(詳細は後記)。
すでに説明したとおり、プッシュ通知を利用するアプリがユーザ端末2に多数インストールされている現状では、プッシュ通知の訴求力は低下している。このため、ユーザ端末2の未使用時にプッシュ通知を実施しても、配信した情報が見落とされる可能性が高い。そこで、ユーザ端末2の使用中のタイミングを見計らってプッシュ通知を実施したほうがよいという着想が生まれる。しかし、ユーザ端末2の使用中の判定は、決して容易ではない。なお、「ユーザ端末2の使用中」(ユーザ端末2の使用時:端末使用時)とは、ユーザが端末画面を見ている時、端末画面が表示中である時、または、ロック解除中をいう。また、「ユーザ端末2の未使用時」(端末未使用時)とは、ユーザが端末画面を見ていない時、端末画面が無表示である時(スリープ状態)、または、ロック作動中をいう。プッシュ通知の実施タイミングについて、以下の<1>〜<4>の事項に留意する。
<1>まず、ユーザ端末2が使用中であるか否かを特に考慮せず、ユーザに適した情報が発生したときに即時でプッシュ通知を行う方法がある。この場合、プッシュ通知を最速にすることができる、というメリットはある。しかし、ユーザがユーザ端末2を触っている可能性は最も小さく、プッシュ通知の訴求力は極めて小さいと考えられる。
<2>また、プッシュ通知を実施する時間帯を指定する方法がある。例えば、電車内ユーザがユーザ端末2を触っていると見込まれる通勤時間帯にプッシュ通知の実施タイミングとする。しかし、通勤時間帯であってもユーザ端末2を触っていないユーザもある程度の割合で存在しており、プッシュ通知の訴求力はそれほど高いとはいえない。
<3>また、プッシュ通知を実施する特定エリアを指定し、GPS、WiFi(登録商標)、BLE(Bluetooth(登録商標) Low Energy)などのセンサ情報を利用して、特定エリアへの出入りや滞在を監視する方法がある。この方法によれば、特定エリアと連動したタイムリーな情報配信(例:名産品のPR)を行うことができる、というメリットはある。しかし、ユーザが移動中であることからユーザ端末2を触っていない可能性があり、プッシュ通知の高い訴求力を望むことができない。また、各種センサ情報の利用は、ユーザの許可をとる必要があるため、プライバシーの観点などから、自社アプリのインストールの障害になり得る。また、定期的なセンサ情報の収集や自社サービスサーバへの収集情報の送信となると、バッテリの消費が懸念されるが、バックグラウンド動作でバッテリの消費が多いとアプリがアンインストールされる可能性が高くなる。つまり、プッシュ通知とは直接的に関係ない不都合な事情が存在する。
<4>また、自社(サービス提供者)のアプリを利用しているときにプッシュ通知を行う方法がある。自社サービスサーバ3Aは自社アプリの利用時にはユーザが自社アプリを使っていることをユーザ端末2から取得することができ、ユーザがユーザ端末2を確実に触っており、プッシュ通知の実施の最適なタイミングを指示サーバ3に通知することができる。しかし、例えば、自社アプリが、ユーザが頻繁に利用するものではない場合、自社のサービス提供者がプッシュ通知の最適なタイミングを知る機会が少ない。
上記の事情に鑑みて、自社アプリの利用時以外の利用時、例えば、他社のアプリが利用されていたり、標準のWebブラウザが利用されていたりする時にプッシュ通知をできるようにし、プッシュ通知の最適なタイミングを知る機会を増やしたい、という要望がある。そこで、本実施形態では、自社のサービス提供者が、通信監視装置1を使用する回線事業者やISP業者と連携し、ユーザがユーザ端末2を利用している、例えば、端末画面を見ている可能性が高いタイミングを通信監視装置1から通知してもらい、そのタイミングでプッシュ通知を実施する構成を実現する。
通信監視装置1の構成について説明する。
図2に示すように、通信監視装置1は、R_ID-ID_A紐付部11と、連携対象R_ID管理部12と、タイミング判断・共有部13(判定部)と、ユーザ認証部14と、中継部15と、ID対応テーブルT1と、通信確認対象ユーザ登録テーブルT2と、いった機能部を備える。なお、ユーザ端末2は、自社のサービス提供者が開発したアプリである提供者アプリ21と、他社のサービス提供者が開発したアプリである他社アプリ22と、Webブラウザ23をインストールしており、通信部24によって、(通信監視装置1を介して、)指示サーバ3、自社サービスサーバ3A、および他サーバ5とやり取りすることができる。
R_ID-ID_A紐付部11は、同一ユーザについて、プッシュ通知前の事前動作の際(図1のステップa1〜ステップa3参照)に配信サーバ4から払い出され、ユーザ端末2から取得したR_IDと、回線事業者等側(通信監視装置1側)で予め管理しているID_Aとを紐付ける。R_ID-ID_A紐付部11は、紐付けの結果をID対応テーブルT1に登録する。
連携対象R_ID管理部12は、サービス提供者がプッシュ通知の実施タイミングを知りたいユーザのR_IDを指示サーバ3から受信して管理する。連携対象R_ID管理部12は、指示サーバ3から受信したR_IDを連携対象R_IDとして管理する。連携対象R_ID管理部12は、サービス提供者から連携対象R_IDの一覧をオンラインで取得することもできるし、オフラインで取得することもできる。また、連携対象R_ID管理部12は、取得したR_IDをID_Aに変換して管理してもよい。
タイミング判断・共有部13は、ユーザ端末2の通信状況からユーザ端末2が使用中であるか否かを判定する。また、タイミング判断・共有部13は、ユーザ端末2が使用中であると判定した場合、指示サーバ3に、プッシュ通知の実施タイミングを通知し、回線事業者等とサービス提供者との間で、プッシュ通知の実施タイミングを共有する。タイミング判断・共有部13は、ユーザ端末2が使用中であるか否かを判定する対象となるユーザを通信確認対象ユーザ登録テーブルT2から特定する。
ユーザ認証部14は、通信を行うユーザを認証する。
中継部15は、通信監視装置1と、指示サーバ3、自社サービスサーバ3A、および他サーバ5との間の情報のやり取りを中継する。
ID対応テーブルT1は、本実施形態のシステムによってサービスを利用するユーザごとに、R_IDとID_Aとを対応付けて管理するテーブルである。
通信確認対象ユーザ登録テーブルT2は、本実施形態のシステムによってサービスを利用するユーザのうち、サービス事業者が、プッシュ通知の実施タイミングを知りたいとするユーザとなる通信確認対象ユーザごとに、R_IDとID_Aとサービス事業者とを対応付けて管理するテーブルである。
(タイミング判断・共有部13のバリエーション)
[1−1]:例えば、タイミング判断・共有部13は、通信確認対象ユーザに対して、パケットカウンタなどでユーザ端末2の通信量を確認し、通信量が増大したタイミングでユーザ端末2が使用中であると判定し、指示サーバ3に通知する。ここで、通信には、ユーザ端末2でのバックグラウンド通信も含まれるので、例えば、平常時のバックグラウンド通信量を測定し、バックグラウンド通信量を差し引いた通信量で、ユーザ端末2が使用中であるか否かを判定するとよい。
[1−2]:また、例えば、タイミング判断・共有部13は、DPIでユーザ端末2からの通信のパケットヘッダやペイロードを解析し、バックグラウンド特有の通信でない通信(例えば、バックグラウンド通信のときに動作する特定サーバ以外のサーバとの通信)が検出された場合、ユーザ端末2が使用中であると判定し、指示サーバ3に通知するとよい。
[1−3]:また、例えば、タイミング判断・共有部13は、サービス提供者からR_IDと特定URI(Uniform Resource Identifier)とのペアの一覧情報を予め取得しておき、DPIでユーザ端末2からの通信のパケットヘッダを確認し、取得した特定URIがパケットヘッダに含まれている場合、ユーザ端末2が使用中であると判定し、指示サーバ3に通知するとよい。これにより、例えば、自動車に興味があるユーザにプッシュ通知したい場合、ユーザ端末2が自動車の情報を扱うURIへのアクセスの最中にプッシュ通知することができる。[1−3]の場合、連携対象R_ID管理部12は、サービス提供者から連携対象R_IDとともに、特定URIを取得し、管理してもよい。
[1−4]:また、例えば、タイミング判断・共有部13は、サービス提供者からR_IDと特定キーワードとのペアの一覧情報を予め取得しておき、DPIでユーザ端末2からの通信のパケットペイロードを確認し、取得した特定キーワードがパケットペイロードに含まれている場合、ユーザ端末2が使用中であると判定し、指示サーバ3に通知するとよい。これにより、例えば、自動車に興味があるユーザにプッシュ通知したい場合、ユーザ端末2が自動車の情報を扱うWebページをブラウジングしている最中にプッシュ通知することができる。[1−4]の場合、連携対象R_ID管理部12は、サービス提供者から連携対象R_IDとともに、キーワードを取得し、管理してもよい。
(R_ID-ID_A紐付部11のバリエーション)
[2−1−1]:例えば、R_ID-ID_A紐付部11は、DPIで提供者アプリ21とサービス提供者との間の通信からR_IDを検出した場合などに、検出したR_IDと、通信監視装置1側で予め管理しているID_Aとを、オンラインでまたはリアルタイムで紐付けて、管理してもよい。
[2−1−2]:また、例えば、R_ID-ID_A紐付部11は、ユーザ端末2からの通信のログや会員情報(例:ユーザの氏名)などを、ID_Aに突き合わせたり、ユーザ端末2のアプリ21,22からR_IDを直接通知(別送)してもらったりすることで、R_IDとID_Aとを、DPI未利用で紐付けて、管理してもよい。
[2−2−1]:例えば、R_ID-ID_A紐付部11は、ID_Aと紐付けるR_IDを受け付ける受付部として機能する際、この受付部をサービス提供者ごとに設置する形態をとることができる。
[2−2−1]の形態をとる場合、[2−1−1]のバリエーションについては、各受付部のIPアドレスで通信パケットの送信先アドレス(サービスサーバのアドレス)をフィルタリング等して、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。また、[2−1−2]のバリエーションについては、各受付部のアクセスログと、回線事業者等でのDHCP/NATログなどとを突き合わせることで、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。
[2−2−2]:例えば、R_ID-ID_A紐付部11は、ID_Aと紐付けるR_IDを受け付ける受付部として機能する際、この受付部を回線事業者等が一元的に設置する形態をとり、この受付部が、サービス提供者の識別子を用いて、アプリから別送される通信や、サービス提供者への通信を1次受付して中継することができる。
[2−2−2]の形態をとる場合、[2−1−1]のバリエーションについては、回線事業者等のこの受付部のIPアドレスで通信パケットの送信先アドレス(サービスサーバのアドレス)をフィルタリング等して、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。また、[2−1−2]のバリエーションについては、回線事業者等この受付部のアクセスログと、回線事業者等でのDHCP/NATログなどとを突き合わせることで、R_IDを抽出し、抽出したR_IDとID_Aとの紐付けを実現することができる。
≪処理≫
次に、通信監視装置1の処理について説明する。
図3に示すように、通信監視装置1の全体処理は、以下の通りである。
まず、R_ID-ID_A紐付部11が、ID対応テーブルT1を、所定の時間間隔で常時更新する(ステップS1)。例えば、通信監視装置1側で管理され、ID対応テーブルT1に登録されているID_Aに対して、対応するR_IDを通信監視装置1が取得した場合、取得したR_IDを、ID対応テーブルT1の対応のID_Aに紐付ける。
次に、連携対象R_ID管理部12が、所定のサービス提供者から提示された連携対象R_IDを受信する(ステップS2)。
次に、タイミング判断・共有部13が、連携対象R_IDに該当するユーザを通信確認対象ユーザとして通信確認対象ユーザ登録テーブルT2に追加する(ステップS3)。例えば、ID対応テーブルT1中に、連携対象R_IDに該当するユーザのID_Aが存在する場合、タイミング判断・共有部13は、このID_Aを通信確認対象ユーザ登録テーブルT2に登録して通信確認対象ユーザを追加する。
もし、ID対応テーブルT1中に、連携対象R_IDに該当するユーザのID_Aが存在しない場合、まず、タイミング判断・共有部13は、連携対象R_IDとしてのR_IDを通信確認対象ユーザ登録テーブルT2に追加する。そして、ステップS1による更新タイミングで、連携対象R_IDに対応するID_Aが新たに出現したときに、タイミング判断・共有部13は、このID_Aを通信確認対象ユーザ登録テーブルT2に登録して通信確認対象ユーザを追加する。
次に、タイミング判断・共有部13が、通信確認対象ユーザ登録テーブルT2に登録されている通信確認対象ユーザの通信を確認する(ステップS4)。
次に、タイミング判断・共有部13が、通信確認対象ユーザのユーザ端末2が使用中であるか否かを判定し、使用中と判定した場合、プッシュ通知の実施タイミングを指示サーバ3に通知する(ステップS5)。この通知により、通信確認対象ユーザのR_IDは、回線事業者等とサービス提供者との間で共有される。
その後、指示サーバ3は、配信サーバ4(図1)にプッシュ通知を指示し、配信サーバ4によるプッシュ通知が実施される。このプッシュ通知は、ユーザ端末2が使用中、例えばユーザが端末画面を見ているときになされるので、ユーザはプッシュ通知をプッシュ通知が実施された時点で確実に認識し、プッシュ通知で配信された情報に即座にアクセスすることができる。
図3の全体処理を実行するためのR_ID-ID_A紐付部11の動作例について説明する。
図4に示すように、R_ID-ID_A紐付部11の動作例は、以下の通りである。
まず、R_ID-ID_A紐付部11は、ネットワーク上の通信を常時監視する(ステップA1)。例えば、R_ID-ID_A紐付部11は、不特定のユーザ端末2の通信により発生したパケットを定期的に取得して解析することで監視する。
次に、R_ID-ID_A紐付部11は、取得したパケット内にR_IDが含まれているか否かを判定する(ステップA2)。含まれていない場合(ステップA2/No)、ステップA1に戻って、通信の監視を継続する。
一方、取得したパケット内にR_IDが含まれている場合(ステップA2/Yes)、R_ID-ID_A紐付部11は、そのR_IDと、取得したパケットを通信したユーザ端末2のユーザ(通信者)のID_AをID対応テーブルT1に追加し、登録する(ステップA3)。
次に、R_ID-ID_A紐付部11は、R_IDが、プッシュ通知の実施タイミングを判定するために必要となる監視の監視対象であるか否かを判定する(ステップA4)。例えば、ステップA3での追加の前では、R_IDがID対応テーブルT1にあったが、そのR_IDに対応のID_Aが空欄であったときには、R_IDが監視対象となる。監視対象でない場合(ステップA4/No)、ステップA1に戻って、通信の監視を継続する。
一方、R_IDが監視対象となる場合(ステップA4/Yes)、R_ID-ID_A紐付部11は、ID対応テーブルT1に追加した(ステップA3参照)ID_Aを通信確認対象ユーザ登録テーブルT2に追加し、追加したID_Aに該当するユーザを通信確認対象ユーザとする(ステップA5)。
図4の処理によれば、プッシュ通知の実施タイミングを通知するために通信確認するユーザを特定することができる。
図3の全体処理を実行するための連携対象R_ID管理部12の動作例について説明する。
図5に示すように、連携対象R_ID管理部12の動作例は、以下の通りである。
まず、連携対象R_ID管理部12は、特定のサービス提供者(の指示サーバ3など)から、当該サービス提供者が指定した1または複数の連携対象R_IDを取得し、回線事業者等とサービス提供者との間で連携対象R_IDを共有する(ステップB1)。
次に、共有された連携対象R_IDに対して、以下のステップB3〜B5のループ処理を実行する(ステップB2)。
連携対象R_ID管理部12は、連携対象R_IDに対応するID_Aが、ID対応テーブルT1内に有るか否かを判定する(ステップB3)。
ID_Aが有る場合(ステップB3/Yes)、連携対象R_ID管理部12は、そのID_Aを通信確認対象ユーザ登録テーブルT2に追加し、追加したID_Aに該当するユーザを通信確認対象ユーザとする(ステップB4)。結果的に、通信確認対象ユーザ登録テーブルT2には、共有された連携対象R_IDとしてのR_IDと、ID_Aと、連携対象R_IDを指定したサービス提供者の識別子とが関連付けられて登録される。
その後、他の連携対象R_IDについてループ処理を進めるか、他の連携対象R_IDが存在しなければ、図5の処理を終了する。
ID_Aが無い場合(ステップB3/No)、連携対象R_ID管理部12は、共有された連携対象R_IDとしてのR_IDをID対応テーブルT1に追加する(ステップB5)。追加されたR_IDに対応するID_Aは暫定的に空欄となるが、通信を関してそのID_Aが発見されたときに補充される。
その後、他の連携対象R_IDについてループ処理を進めるか、他の連携対象R_IDが存在しなければ、図5の処理を終了する。
図5の処理によれば、サービス提供者が指定した1または複数の連携対象R_IDを、回線業者等側で管理することができる。
図3の全体処理を実行するためのタイミング判断・共有部13の動作例について説明する。
図6に示すように、タイミング判断・共有部13の動作例は、以下の通りである。
まず、タイミング判断・共有部13は、常時、通信確認対象ユーザの各々に対して、以下のステップC2〜C4のループ処理を実行する(ステップC1)。
タイミング判断・共有部13は、通信確認対象ユーザのユーザ端末2の通信を監視する(ステップC2)。
次に、タイミング判断・共有部13は、通信確認対象ユーザのユーザ端末2が使用中であるか否かを判定する(ステップC3)。使用中でないと判定した場合(ステップC3/No)、ステップC1に戻り、他の通信確認対象ユーザについてループ処理を実行する。
一方、使用中であると判定した場合(ステップC3/Yes)、サービス提供者の指示サーバ3に、通信確認対象ユーザのR_IDを通知し、通信確認対象ユーザのR_IDを、回線業者等とサービス提供者との間で共有する(ステップC4)。
その後、ステップC1に戻り、他の通信確認対象ユーザについてループ処理を実行する。すべての通信確認対象ユーザについてループ処理が完了した場合、図6の処理(常時処理の一回)を終了する。
図6の処理によれば、サービス提供者が連携対象R_IDとして指定したユーザを通信確認対象ユーザとして、ユーザ端末2の使用中を判定し、プッシュ通知の実施タイミングを回線業者等から通知してもらうことができる。
≪まとめ≫
本実施形態によれば、サービス提供者が、通信監視装置1を有する回線事業者等と連携可能となるシステムを構築することで、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末2の使用中というタイミングを、通信監視装置1から通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力を向上させることができる。
その結果、ユーザ端末2側で配信サーバ4からのプッシュ通知の開封率は向上する。サービスを利用するユーザによるプッシュ通知の見落としは減少する。プッシュ通知で配信された情報が活用されれば、サービス提供者や回線事業者等の利益の向上が見込まれ、ユーザへの最終的な利益還元の可能性が高まる。
また、タイミング判断・共有部13のバリエーション[1−3],[1−4]による判断ロジックを採用すれば、特定の情報に興味を持つユーザに絞ってプッシュ通知を行うことができるので、一定の原資で通常よりも多くの特典をユーザに提供することもできる。
また、サービス提供者だけでは、サービス提供者が提供するアプリを使用した通信以外の通信を直接的に把握することはできないところ、通信監視装置1によって、そのような通信を間接的に把握することができるようになる。その結果、サービス提供者は、プッシュ通知の最適な実施タイミングとなる、ユーザ端末2の使用中というタイミングを、通信監視装置1からより頻繁に通知してもらうことができる。
したがって、ユーザ端末で使われているプッシュ通知の訴求力をさらに向上させることができる。
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
例えば、本実施形態では、サービス提供者は、通信監視装置1の回線事業者等から他社のアプリの通信によるユーザ端末2の使用中を通知してもらった。しかし、複数のサービス提供者が所持するサービスサーバ間で、各社のアプリの通信が行われてユーザ端末2が使用中であることを相互に通知し合って、サービス提供者の各々が、プッシュ通知の最適な実施タイミングを数多く獲得することができるようにしてもよい。
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、処理手順などについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
1 通信監視装置
2 ユーザ端末
3 指示サーバ
3A 自社サービスサーバ
4 配信サーバ
5 他サーバ
11 R_ID-ID_A紐付部
12 連携対象R_ID管理部
13 タイミング判断・共有部(判定部)

Claims (5)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016112010A JP6577907B2 (ja) 2016-06-03 2016-06-03 通信監視装置および通信監視方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016112010A JP6577907B2 (ja) 2016-06-03 2016-06-03 通信監視装置および通信監視方法

Publications (2)

Publication Number Publication Date
JP2017220720A JP2017220720A (ja) 2017-12-14
JP6577907B2 true JP6577907B2 (ja) 2019-09-18

Family

ID=60658166

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016112010A Active JP6577907B2 (ja) 2016-06-03 2016-06-03 通信監視装置および通信監視方法

Country Status (1)

Country Link
JP (1) JP6577907B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6805610B2 (ja) * 2016-07-28 2020-12-23 日本電気株式会社 サーバ装置、シンクライアントシステム、通知転送方法、および、プログラム
WO2020240641A1 (ja) 2019-05-27 2020-12-03 日本電信電話株式会社 指示出力装置、指示出力方法及びプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003032750A (ja) * 2001-07-17 2003-01-31 Nec Corp 移動体端末への情報配信システムおよび情報配信方法
US8041780B2 (en) * 2007-03-29 2011-10-18 Alcatel Lucent Method and apparatus for dynamically pushing content over wireless networks
JP2009157650A (ja) * 2007-12-26 2009-07-16 Softbank Mobile Corp コンテンツ提供システム、コンテンツ提供方法およびコンテンツ提供プログラム
JP6043631B2 (ja) * 2013-01-15 2016-12-14 Kddi株式会社 プッシュ型情報配信システム、情報受信端末およびコンピュータプログラム
JP2015103031A (ja) * 2013-11-25 2015-06-04 株式会社セガ プッシュ通知管理装置、プッシュ通知管理方法およびプッシュ通知管理プログラム
EP2882163A1 (en) * 2013-12-09 2015-06-10 Alcatel Lucent Method and system for scheduling a push data transmission

Also Published As

Publication number Publication date
JP2017220720A (ja) 2017-12-14

Similar Documents

Publication Publication Date Title
US11418602B2 (en) Systems and methods for service layer session migration and sharing
TWI584619B (zh) 網路聚合器
CN105530175B (zh) 一种消息处理方法、装置及系统
JP5755813B2 (ja) ネットワークリソースダウンロード情報の共有制御システムと方法
US11310348B2 (en) Highly scalable, fault tolerant remote access architecture and method of connecting thereto
CN101039309B (zh) 链路共享服务装置以及通信方法
CN107431726A (zh) 消息总线服务目录
EP3378217A1 (en) Cross-resource subscription for m2m service layer
JP5976210B2 (ja) 監視システム、設備管理装置、監視方法及びプログラム
CN112399130B (zh) 云视频会议信息的处理方法、装置、存储介质和通信设备
JP2017513151A (ja) プライベートクラウド接続装置クラスタアーキテクチャ
Hou et al. Design and implementation of application programming interface for Internet of things cloud
CN104601638A (zh) 进行浏览器网页信息传送的方法及系统
JP6577907B2 (ja) 通信監視装置および通信監視方法
Chang et al. A service-oriented mobile cloud middleware framework for provisioning mobile sensing as a service
JP5961471B2 (ja) 複数の情報システムおける出力比較方法
JP7458377B2 (ja) フォグベースのデータ処理を有効にするためのデータサンプルテンプレート(Data Sample Template:DST)管理
JP5517255B2 (ja) 複数のサービスノードサーバにおけるサービス連結制御方法、制御ノードサーバ及びプログラム
KR101236500B1 (ko) 소형 임베디드 장치를 위한 sns 중계 서비스 장치 및 그 방법
CN103634348A (zh) 终端设备以及发布信息的方法
JP6212944B2 (ja) 通信システム、プロキシサーバ、通信方法およびプログラム
JP2016189127A (ja) 仮想マシン及びリモートデスクトップシステム
CN104462223B (zh) 一种基于对等网络模式的网页浏览方法和装置
Sicari et al. Increasing the pervasiveness of the IoT: fog computing coupled with pub&sub and security
JP5410487B2 (ja) キャッシュサーバ、ウェブサーバ及び方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180619

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190404

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190416

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190820

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190823

R150 Certificate of patent or registration of utility model

Ref document number: 6577907

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150