(57)【要約】【課題】利用者がＰｕｓｈ配信とは直接関係のないサーバを用意せずに確実性の高いＰｕｓｈ配信を行うことができ、クライアント端末のＯＳに応じて配信データを登録せずにＰｕｓｈ配信を行うことができるＰｕｓｈ配信ゲートウェイサービスシステムを提供する。【解決手段】Ｐｕｓｈ配信アプリを開発する利用者からの配信データの情報の登録および配信先の前記クライアント端末の情報の登録を受け付ける受付サーバ２３０と、受付サーバ２３０で受け付けられた配信データの情報およびクライアント端末の情報を格納するデータベースと、データベースに格納された配信データの情報およびクライアント端末の情報に基づいて、Ｐｕｓｈ配信サービスへ配信データを配信する配信サーバ２１０とを備える。【選択図】図１
2014186696.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末上でＰｕｓｈ配信の配信データが配信されるＰｕｓｈ配信アプリを開発する利用者に対して、前記配信データの配信を行うＰｕｓｈ配信サービスシステムへのゲートウェイサービスを提供するＰｕｓｈ配信ゲートウェイサービスシステムであって、
前記利用者からの配信リクエストおよび配信メッセージを含む前記配信データの情報の登録および配信先の前記クライアント端末の情報の登録を受け付けるＰｕｓｈ配信ゲートウェイサーバと、
前記Ｐｕｓｈ配信ゲートウェイサーバで受け付けられた前記配信データの情報および前記クライアント端末の情報を格納するデータベースと、を備え、
前記Ｐｕｓｈ配信ゲートウェイサーバは、前記データベースに格納された前記配信データの情報および前記クライアント端末の情報に基づいて、前記Ｐｕｓｈ配信サービスシステムに対して前記配信データを配信する、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【請求項２】
請求項１に記載のＰｕｓｈ配信ゲートウェイサービスシステムにおいて、
前記Ｐｕｓｈ配信ゲートウェイサーバは、前記利用者からの前記Ｐｕｓｈ配信に関するアカウント情報、証明書情報、前記Ｐｕｓｈ配信サービスから取得したトークン情報、前記クライアント端末を指定する識別子、および前記クライアント端末のグルーピングタグの登録を受け付け前記データベースに格納する、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【請求項３】
請求項２に記載のＰｕｓｈ配信ゲートウェイサービスシステムにおいて、
前記Ｐｕｓｈ配信ゲートウェイサーバは、前記クライアント端末のグルーピングタグに基づいて、配信対象の前記クライアント端末をグルーピングして指定する、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【請求項４】
請求項２に記載のＰｕｓｈ配信ゲートウェイサービスシステムにおいて、
前記Ｐｕｓｈ配信ゲートウェイサーバは、前記利用者からの前記配信データの配信失敗時に再配信を行うかの情報、無効な前記トークン情報を無視するかの情報、前記配信データの分割配信の情報、および前記配信データのスケジューリングの情報の登録を受け付け、受け付けた情報に基づいて、前記Ｐｕｓｈ配信サービスシステムに対して前記配信データを配信する、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【請求項５】
請求項１に記載のＰｕｓｈ配信ゲートウェイサービスシステムにおいて、
前記配信データの前記配信リクエストは、前記クライアント端末の種類に関係無く、共通のデータである、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【請求項６】
請求項５に記載のＰｕｓｈ配信ゲートウェイサービスシステムにおいて、
前記配信データの前記配信リクエストは、配信対象の前記クライアント端末を複数指定するデータである、Ｐｕｓｈ配信ゲートウェイサービスシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ側からクライアント側に向けてデータを配信するＰｕｓｈ配信の管理を行うＰｕｓｈ配信ゲートウェイサービスシステムに関し、特に、スマートフォン向けの通知をＰｕｓｈ配信するシステムに関する。
【０００２】
なお、Ｐｕｓｈ配信とは、クライアント側がサーバ側へデータをリクエストするのではなく、サーバ側からクライアント側に向けてデータを配信することを指すものとする。
【背景技術】
【０００３】
従来、Ａｎｄｒｏｉｄ（登録商標）搭載スマートフォン端末向けのＰｕｓｈ配信サービスにＣ２ＤＭ（Ａｎｄｒｏｉｄ  Ｃｌｏｕｄ  ｔｏ  Ｄｅｖｉｃｅ  Ｍｅｓｓａｇｅ）、ｉＯＳ（登録商標）搭載スマートフォン端末向けのＰｕｓｈ配信サービスにＡＰＮｓ（Ａｐｐｌｅ  Ｐｕｓｈ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）というサービスが存在する。
【０００４】
また、特開２００５−１６５６９７号公報（特許文献１）には、クライアント端末が受信可能な場合にＰｕｓｈ配信を行うことで配信の確実性を向上させる方法が記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−１６５６９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
以降の説明において、Ｐｕｓｈ配信を使ったスマートフォン向けアプリを「Ｐｕｓｈ配信アプリ」、Ｐｕｓｈ配信アプリにおけるサーバを「アプリサーバ」、Ｐｕｓｈ配信アプリにおけるスマートフォンクライアントを「クライアント端末」と記す。
【０００７】
Ｐｕｓｈ配信アプリを開発しようとするとき、Ｃ２ＤＭやＡＰＮｓというＰｕｓｈ配信サービスを利用すると、アプリサーバにＰｕｓｈ配信の機能を実装しなくとも、配信の事前に取得するトークン情報を使って配信対象のクライアント端末を指定し、Ｐｕｓｈ配信を実現することができる。
【０００８】
ただし、Ｃ２ＤＭを利用するためにはＧｏｏｇｌｅ（登録商標）アカウントが、ＡＰＮｓを利用するにはＳＳＬ証明書が必要となる。
【０００９】
Ｃ２ＤＭはＡｎｄｒｏｉｄ搭載スマートフォンを、ＡＰＮｓはｉＯＳ搭載スマートフォンを配信対象とするＰｕｓｈ配信サービスである。
【００１０】
クライアント端末のＯＳに依存しないスマートフォン向けＰｕｓｈ配信アプリを開発する場合、アプリサーバは、Ｃ２ＤＭやＡＰＮｓそれぞれのインタフェイス仕様に応じて配信データを登録する必要がある。
【００１１】
また、Ｃ２ＤＭやＡＰＮｓを利用してＰｕｓｈ配信を行なった場合、配信エラーが起きても再配信は行われないため、配信の確実性を向上する機能はアプリサーバ側で実装する必要がある。
【００１２】
前記特許文献１では、クライアント端末を使う人のスケジュール、配信対象となるクライアント端末の電池残量、利用可能な通信手段、位置情報に基づく電波状況などの状態によってＰｕｓｈ配信の確実性を向上する方法が記載されているが、この方法は、Ｐｕｓｈ配信とは直接関係のないサーバとしてクライアント端末を使う人のスケジュールを管理するサーバを用意する必要がある。
【００１３】
そこで、本発明の目的は、利用者がＰｕｓｈ配信とは直接関係のないサーバを用意せずに確実性の高いＰｕｓｈ配信を行うことができ、クライアント端末のＯＳに応じて配信データを登録せずにＰｕｓｈ配信を行うことができるＰｕｓｈ配信ゲートウェイサービスシステムを提供することにある。
【００１４】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１５】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。
【００１６】
すなわち、代表的なものの概要は、クライアント端末上でＰｕｓｈ配信の配信データが配信されるＰｕｓｈ配信アプリを開発する利用者に対して、配信データの配信を行うＰｕｓｈ配信サービスへのゲートウェイサービスを提供するＰｕｓｈ配信ゲートウェイサービスシステムであって、利用者からの配信リクエストおよび配信メッセージを含む配信データの情報の登録および配信先のクライアント端末の情報の登録を受け付けるＰｕｓｈ配信ゲートウェイサーバと、Ｐｕｓｈ配信ゲートウェイサーバで受け付けられた配信データの情報およびクライアント端末の情報を格納するデータベースと、を備え、Ｐｕｓｈ配信ゲートウェイサーバは、データベースに格納された配信データの情報およびクライアント端末の情報に基づいて、Ｐｕｓｈ配信サービスに対して配信データを配信する。
【発明の効果】
【００１７】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。
【００１８】
すなわち、Ｐｕｓｈ配信ゲートウェイサービスシステムにより、下記の効果を期待できる。
【００１９】
（１）利用者がＰｕｓｈ配信とは直接関係のないサーバを用意せずに確実性の高いＰｕｓｈ配信を行うことができる。
【００２０】
（２）利用者がクライアント端末のＯＳに応じて配信データを登録せずにＰｕｓｈ配信を行うことができる。
【００２１】
（３）Ｐｕｓｈ配信対象のクライアント端末を、トークン情報だけでなく、識別子や任意のグルーピングタグで指定できる。
【００２２】
（４）分割配信、スケジューリング配信、無効なトークン情報の無視などの付加的機能を利用者に提供できる。
【図面の簡単な説明】
【００２３】
【図１】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの構成を示す構成図である。
【図２】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの端末情報のデータベースに格納する配信対象となるクライアント端末を指定するデータの一例を示す図である。
【図３】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの配信データの中核となるペイロードのデータの一例を示す図である。
【図４】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの配信データの配信オプションのデータの一例を示す図である。
【図５】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの事前準備段階の動作を示すフローチャートである。
【図６】本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムのＰｕｓｈ配信段階の動作を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２５】
＜Ｐｕｓｈ配信ゲートウェイサービスシステムの構成＞
図１により、本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの構成について説明する。図１は本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの構成を示す構成図である。
【００２６】
図１において、Ｐｕｓｈ配信ゲートウェイサービスシステム２００は、配信サーバ２１０、管理サーバ２２０、受付サーバ２３０、配信データ２４０および端末情報２５０が格納されたデータベースから構成されている。
【００２７】
また、Ｐｕｓｈ配信ゲートウェイサービスシステム２００と、Ｐｕｓｈ配信ゲートウェイサービスシステム２００の利用者１１０、１２０、１３０側との間は、インターネット通信経路４２０で接続されている。
【００２８】
また、利用者１１０、１２０、１３０は、利用者１１０、１２０、１３０が実現しようとしているＰｕｓｈ配信アプリにおいて、配信データを受け取るクライアント端末１１１、１２１、１３１と、Ｐｕｓｈ配信の配信データを送信するアプリサーバ１１２、１２２、１３２を備えている。
【００２９】
また、Ｐｕｓｈ配信ゲートウェイサービスシステム２００と、Ｐｕｓｈ配信ゲートウェイサービスシステム２００がクライアント端末に配信データを配信するために利用する既存のＰｕｓｈ配信サービスシステム３００との間は、インターネット通信経路４３０で接続されている。
【００３０】
既存のＰｕｓｈ配信サービスとしては、例えば、Ａｎｄｒｏｉｄ搭載スマートフォン端末向けのＰｕｓｈ配信サービスＣ２ＤＭ（Ａｎｄｒｏｉｄ  Ｃｌｏｕｄ  ｔｏ  Ｄｅｖｉｃｅ  Ｍｅｓｓａｇｅ）３１０や、ｉＯＳ搭載スマートフォン端末向けのＰｕｓｈ配信サービスＡＰＮｓ（Ａｐｐｌｅ  Ｐｕｓｈ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）３２０を対象としている。
【００３１】
なお、Ｐｕｓｈ配信サービスについては、Ｃ２ＤＭ３１０やＡＰＮｓ３２０に限らず、他のＰｕｓｈ配信サービスを対象としてもよい。
【００３２】
また、Ｐｕｓｈ配信ゲートウェイサービスシステム２００の利用者１１０、１２０、１３０側と、既存のＰｕｓｈ配信サービスシステム３００との間もインターネット通信経路４１０で接続されている。
【００３３】
配信サーバ２１０、管理サーバ２２０、および受付サーバ２３０はＡｐａｃｈｅとＴｏｍｃａｔによるＷｅｂサービスで、配信データ２４０および端末情報２５０が格納されたデータベースはＭｙＳＱＬで実現する。
【００３４】
また、Ｐｕｓｈ配信ゲートウェイサービスシステム２００がＰｕｓｈ配信を行う際は、例えば、既存のＰｕｓｈ配信サービスシステム３００のＣ２ＤＭ３１０とＡＰＮｓ３２０を利用する。
【００３５】
なお、Ｐｕｓｈ配信ゲートウェイサービスシステム２００は、アプリサーバ１１２、１２２、１３２がＰｕｓｈ配信による通知をクライアント端末１１１、１２１、１３１に行うＰｕｓｈ配信アプリの開発者を利用者として想定しており、以下、「利用者」と記した場合、Ｐｕｓｈ配信ゲートウェイサービスシステム２００の利用者である「Ｐｕｓｈ配信アプリの開発者」を指すものとする。
【００３６】
また、「運用者」と記した場合、「Ｐｕｓｈ配信ゲートウェイサービスシステム２００の運用者」を指すものとする。
【００３７】
配信サーバ２１０は、Ｐｕｓｈ配信ゲートウェイサービスシステム２００が利用者から受け付けた配信データを、既存のＰｕｓｈ配信サービスシステム３００を利用して、クライアント端末１１１、１２１、１３１やその他の複数のクライアント端末に配信する。
【００３８】
管理サーバ２２０は、運用者がＰｕｓｈ配信ゲートウェイサービスを運用管理するための管理サーバである。
【００３９】
管理サーバ２２０は、運用管理のためのバックグラウンド処理の他、Ｐｕｓｈ配信アプリへの配信サーバの割り当てや、Ｐｕｓｈ配信の利用状況確認といった機能を運用者に提供する。
【００４０】
受付サーバ２３０は、Ｐｕｓｈ配信ゲートウェイサービスシステム２００の利用者１１０、１２０、１３０からの配信データを受け付ける。利用者１１０、１２０、１３０から受け付けた配信データは、配信リクエストや配信メッセージとして配信データ２４０のデータベースに格納される。
【００４１】
また、受付サーバ２３０は、利用者１１０、１２０、１３０によるＰｕｓｈ配信の事前設定を受け付け、端末情報２５０のデータベースに保存する。
【００４２】
なお、図１に示す例では、配信サーバ２１０、管理サーバ２２０および受付サーバ２３０を個別のサーバとしているが、これらの機能を有するＰｕｓｈ配信ゲートウェイサーバなどのサーバとして構成することもできる。
【００４３】
配信データ２４０のデータベースは、Ｐｕｓｈ配信ゲートウェイサービスシステム２００が利用者１１０、１２０、１３０から受け付けた配信リクエストと配信メッセージからなる配信データ、配信結果のログ、および履歴として退避された配信データを格納する。
【００４４】
端末情報２５０のデータベースは、Ｐｕｓｈ配信ゲートウェイサービスシステム２００の利用者１１０、１２０、１３０がＰｕｓｈ配信の対象とするクライアント端末のクライアント端末識別子などの情報、クライアント端末に配信データを配信するために必要なＧｏｏｇｌｅアカウント、ＳＳＬ証明書、トークン情報、およびグルーピングタグの対応付けなどの情報、および配信失敗時に再配信を行なうか、無効なトークン情報を無視するかなどの事前設定情報を格納する。
【００４５】
なお、図１においては、配信データ２４０のデータベースと端末情報２５０のデータベースとを分けているが、１つのデータベース内の情報として管理してもよい。
【００４６】
＜データベースのデータ例＞
次に、図２〜図４により、本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムのデータベースのデータ例について説明する。
【００４７】
図２〜図４は本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムのデータベースのデータの一例を示す図であり、図２は端末情報２５０のデータベースに格納する配信対象となるクライアント端末を指定するデータの一例、図３は配信データ２４０の中核となるペイロードのデータの一例、図４は配信データ２４０の配信オプションのデータの一例である。
【００４８】
図２において、配信対象は、Ｃ２ＤＭ３１０やＡＰＮｓ３２０から取得したトークン情報のほか、利用者１１０、１２０、１３０が事前に対応付けたクライアント端末識別子やグルーピングタグで指定することができる。
【００４９】
クライアント端末識別子とグルーピングタグとの違いは、クライアント端末識別子が端末から取得する固有のＵＵＩＤなどの値であるのに対し、グルーピングタグは利用者１１０、１２０、１３０が値を任意に決められることである。
【００５０】
図２に示した例では、項目ｔｏｋｅｎｓとして、「ｔｏｋｅｎ１」、「ｔｏｋｅｎ２」、「ｔｏｋｅｎ３」、「ｔｏｋｅｎ４」、「ｔｏｋｅｎ５」のトークン情報を持つクライアント端末、または項目ｄｅｖｉｃｅｉｄｓとして、「ｄｅｖ１」、「ｄｅｖ２」、「ｄｅｖ３」のクライアント端末識別子を持つクライアント端末、または項目ｕｓｅｒｋｅｙｓとして、「ｋｅｙ１」、「ｋｅｙ２」のグルーピングタグを持つクライアント端末はＰｕｓｈ配信の対象となり、項目ｉｇｎｏｒｅｔｏｋｅｎｓとして、「ｔｏｋｅｎ５」、「ｔｏｋｅｎ６」のトークン情報を持つクライアント端末はＰｕｓｈ配信の対象外となる。
【００５１】
なお、「トークン情報」と「クライアント端末識別子」、「グルーピングタグ」との対応付けは、事前準備段階にて利用者１１０、１２０、１３０がＰｕｓｈ配信ゲートウェイサービスシステム２００に登録しておく。
【００５２】
また，図３において、ペイロードには、配信データがクライアント端末１１１、１２１、１３１に到着した際の通知方法を設定する「ａｌｅｒｔ」、「ｂａｄｇｅ」、「ｓｏｕｎｄ」のほか、「任意キー１、任意キー２、任意キー３、…」を使用してＰｕｓｈ配信アプリに任意の値を渡す情報が格納されている。
【００５３】
「ａｌｅｒｔ」はクライアント端末へデータが到着したときに表示させるダイアログのメッセージ、「ｂａｄｇｅ」はクライアント端末へデータが到着したときに表示させるアイコンバッチの数値、「ｓｏｕｎｄ」はクライアント端末へデータが到着したときに鳴らす音声ファイルのパスを設定している。
【００５４】
また、図４において、配信オプションには、３つのデータ項目として「ｃｏｌｌａｐｓｅｋｅｙ」、「ｄｅｌａｙｗｈｉｌｅｉｄｌｅ」、「ｅｘｐｉｒｙ」を有し、Ｃ２ＤＭ３１０やＡＰＮｓ３２０のオプションである。
【００５５】
「ｃｏｌｌａｐｓｅｋｅｙ」は、Ｃ２ＤＭ３１０のｃｏｌｌａｐｓｅｋｅｙオプションに渡されるデータ、「ｄｅｌａｙｗｈｉｌｅｉｄｌｅ」はＣ２ＤＭ３１０のｄｅｌａｙｗｈｉｌｅｉｄｌｅオプションに渡されるオプションデータ、「ｅｘｐｉｒｙ」はＡＰＮｓ３２０のｅｘｐｉｒｙオプションに渡されるデータである。
【００５６】
＜Ｐｕｓｈ配信ゲートウェイサービスシステムの動作＞
次に、図５および図６により、本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの動作について説明する。図５は本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムの事前準備段階の動作を示すフローチャート、図６は本発明の一実施の形態に係るＰｕｓｈ配信ゲートウェイサービスシステムのＰｕｓｈ配信段階の動作を示すフローチャートである。
【００５７】
Ｐｕｓｈ配信ゲートウェイサービスシステム２００を利用してＰｕｓｈ配信を行なうためには、事前準備の実施が必須となる。
【００５８】
まず、事前準備段階の動作は、図５に示すように、Ｐｕｓｈ配信アプリ登録：利用者１１０、１２０、１３０は、Ｐｕｓｈ配信ゲートウェイサービスシステム２００を利用するＰｕｓｈ配信アプリを事前に登録しておく（ステップＳ１００）。このＰｕｓｈ配信アプリの登録情報は、管理サーバ２２０内に格納されるか、端末情報２５０のデータベースなどに格納される。
【００５９】
Ｐｕｓｈ配信ゲートウェイサービスシステム２００は、ステップＳ１００で正規に登録されたＰｕｓｈ配信アプリに対してのみサービスを提供する。
【００６０】
Ｐｕｓｈ配信設定：利用者１１０、１２０、１３０は、Ｐｕｓｈ配信ゲートウェイサービスシステム２００を利用するための情報、例えば、「再配信有無」、「再配信回数」、「無効トークン情報削除有無」、「配信データ保存期間」などを配信サーバ２１０に登録する（ステップＳ１０１）。
【００６１】
また、ステップＳ１０１では、Ｃ２ＤＭ３１０を利用する場合は、「Ｇｏｏｇｌｅアカウント」、「Ｇｏｏｇｌｅアカウントのパスワード」、ＡＰＮｓ３２０を利用する場合は、「ＳＳＬ証明書」、「証明書パスワード」を併せて登録する。
【００６２】
これらの情報は、端末情報２５０のデータベースに格納される。
【００６３】
配信サーバ割り当て：運用者は、利用者１１０、１２０、１３０が登録したＰｕｓｈ配信アプリのＰｕｓｈ配信を担当する配信サーバ２１０を割り当てる（ステップＳ１０２）。
【００６４】
クライアント端末登録：Ｐｕｓｈ配信を行うにあたり、利用者１１０、１２０、１３０は、Ｃ２ＤＭ３１０やＡＰＮｓ３２０から取得したトークン情報を、受付サーバ２３０に登録し、「クライアント端末識別子」、「グルーピングタグ」と対応付けてＰｕｓｈ配信ゲートウェイサービスシステム２００の端末情報２５０のデータベースに登録する。
【００６５】
配信データ２４０の配信対象とする配信先のクライアント端末は、ここでの登録内容によって対応付けられる。
【００６６】
次に、Ｐｕｓｈ配信段階の動作は、図６に示すように、配信リクエスト登録：利用者１１０、１２０、１３０は、配信対象のクライアント端末を指定し、配信データの中核となるペイロードと共に、必要に応じて配信オプションをＰｕｓｈ配信ゲートウェイサービスシステム２００の受付サーバ２３０に登録する。
【００６７】
受付サーバ２３０は、利用者１１０、１２０、１３０から登録されたデータを配信リクエストとして配信データ２４０のデータベースに保存する（ステップＳ２００）。
【００６８】
配信リクエストには、トークン情報を直接指定するほか、事前に対応付けたクライアント端末識別子やグルーピングタグを指定情報とし、配信対象のクライアント端末を複数指定することが可能である。
【００６９】
配信メッセージ展開：受付サーバ２３０は、配信リクエストを配信対象のクライアント端末の１台ごとにトークン情報と対応付いた配信メッセージとして展開し、配信データ２４０のデータベースに保存する（ステップＳ２０１）。
【００７０】
さらに、受付サーバ２３０は、管理サーバ２２０がＰｕｓｈ配信アプリに割り当てた配信サーバ２１０にウェイクアップ信号を送り、配信処理の実行を促がす。
【００７１】
配信メッセージ配信：配信サーバ２１０は、自分が管理サーバ２２０に割り当てられたＰｕｓｈ配信アプリの配信メッセージがないか、配信データ２４０のデータベースを定期的に確認している。
【００７２】
メッセージがない場合、確認間隔は徐々に長くなっていくが、受付サーバ２３０からウェイクアップ信号が送られると確認間隔が最小値にリセットされる。
【００７３】
配信メッセージがある場合、その配信メッセージを取得し、多重配信を防ぐために排他ロックし、Ｃ２ＤＭ３１０やＡＰＮｓ３２０へ配信する（ステップＳ２０２）。
【００７４】
配信要求に対してＣ２ＤＭ３１０やＡＰＮｓ３２０からトークン情報が無効とのレスポンスが返ってきた場合、配信サーバ２１０は、そのトークン情報を無視するようになり、以降はＰｕｓｈ配信に使わない。
【００７５】
なお、このトークン情報の無視については、利用者１１０、１２０、１３０の事前設定次第で変更することが可能である。
【００７６】
配信処理が一通り終わると、配信サーバ２１０は、取得した配信メッセージの排他ロックを解除し、配信結果のログを配信データ２４０のデータベースに保存する。
【００７７】
配信メッセージ到着：ネットワークに接続できない、または利用者１１０、１２０、１３０が無効なトークン情報を登録したなどのエラーがなかった場合、配信が成功しており、配信データ２４０が配信対象のクライアント端末に到着する（ステップＳ２０３）。
【００７８】
配信に成功した場合、配信サーバ２１０は、配信メッセージを履歴として退避し、配信完了とする。エラーがあった場合、配信サーバ２１０は、再配信を試みて配信の確実性向上を図る。
【００７９】
なお、この再配信などについては、利用者１１０、１２０、１３０の事前設定次第で変更することが可能である。
【００８０】
また、利用者１１０、１２０、１３０の事前設定で、配信データの分割配信や、スケジューリング配信などを行うことも可能である。
【００８１】
その他、管理サーバ２２０は、下記の処理をバックグラウンドで定期的に実行する。
【００８２】
＊配信を試みたがいつまでも成否結果が返ってこない配信メッセージのリセット
＊配信サーバ稼働状況の監視
＊配信データ保存期間を過ぎた配信リクエストと配信メッセージを履歴として退避
以上のような事前準備段階の動作およびＰｕｓｈ配信段階の動作を行うＰｕｓｈ配信ゲートウェイサービスシステムを提供することにより、利用者がＰｕｓｈ配信とは直接関係のないサーバを用意せずに確実性の高いＰｕｓｈ配信を行うことができ、クライアント端末のＯＳに応じて配信データを登録せずにＰｕｓｈ配信を行うことができる。
【００８３】
そのため、Ｐｕｓｈ配信を利用するスマートフォン向けアプリの開発者を顧客とする市場の獲得が期待できる。
【００８４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【符号の説明】
【００８５】
１１０、１２０、１３０…利用者、１１１、１２１、１３１…クライアント端末、１１２、１２２、１３２…アプリサーバ、２００…Ｐｕｓｈ配信ゲートウェイサービスシステム、２１０…配信サーバ、２２０…管理サーバ、２３０…受付サーバ、２４０…配信データ、２５０…端末情報、３００…Ｐｕｓｈ配信サービスシステム、３１０…Ｃ２ＤＭ、３２０…ＡＰＮｓ、４１０、４２０、４３０…インターネット通信経路。
【図１】
2014186696.tif 000003
【図２】
2014186696.tif 000004
【図３】
2014186696.tif 000005
【図４】
2014186696.tif 000006
【図５】
2014186696.tif 000007
【図６】
2014186696.tif 000008