(57)【要約】  例えば、プッシュサーバに負荷がかかっている場合にも、プッシュサーバがメッセージ送信要求を受信してから、端末にプッシュメッセージを送信するまでの遅延の増大を抑止することを可能にする。端末へのメッセージ送信に関する処理を行うメッセージ送信装置が、未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する。前記メッセージを前記端末に送信するための準備処理を実行する。前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する。
2014122981.tif 000002
【特許請求の範囲】
【請求項１】
端末へのメッセージ送信に関する処理を行うメッセージ送信装置であって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、
前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、
を備えることを特徴とするメッセージ送信装置。
【請求項２】
請求項１に記載のメッセージ送信装置であって、
前記端末が通信可能状態であるか又は休止状態であるのかに基づいて、通信可能状態にある端末についての前記準備処理が休止状態にある端末についての前記準備処理よりも優先して行われるように実行順序を決定することを特徴とするメッセージ送信装置。
【請求項３】
請求項１又は２に記載のメッセージ送信装置であって、
前記通知処理が少なくとも一部の準備処理よりも優先して行われるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【請求項４】
請求項１乃至３の何れか１項に記載のメッセージ送信装置であって、
前記端末が通信可能状態であるか又は休止状態であるのかに基づいて、通信可能状態にある端末についての前記準備処理には第１の長さの処理期限を設定し、休止状態にある端末についての前記準備処理には前記第１の長さよりも長い第２の長さの処理期限を設定し、前記処理期限の終了時刻までの時間が短い準備処理ほど優先して実行されるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【請求項５】
請求項４に記載のメッセージ送信装置であって、
前記処理期限の終了時刻に近づくに伴い高くなっていく優先度を前記準備処理に設定し、前記通知処理には変化しない一定の高さの優先度を設定し、前記準備処理及び通知処理の中から優先度の高いものほど優先して実行されるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【請求項６】
請求項４又は５に記載のメッセージ送信装置であって、
或るメッセージに関しての前記準備処理の処理期限の終了時刻が経過したにも関わらず、該準備処理が未だ実行されておらず、更に、前記端末から該或るメッセージに関して前記メッセージ取得要求を受信していない場合には該準備処理の処理期限をより長い処理期限へと変更することを特徴とするメッセージ送信装置。
【請求項７】
請求項１乃至６の何れか１項に記載のメッセージ送信装置であって、
前記端末から或るメッセージに関して前記メッセージ取得要求を受信したにも関わらず、該或るメッセージに関しての準備処理が未だ実行されていない場合には、前記決定した実行順序にとらわれることなく該或るメッセージに関しての準備処理を優先して実行することを特徴とするメッセージ送信装置。
【請求項８】
端末へのメッセージ送信に関する処理を行うメッセージ送信方法であって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知ステップと、
前記メッセージを前記端末に送信するための準備処理を実行する準備ステップと、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定ステップと、
を備えることを特徴とするメッセージ送信方法。
【請求項９】
端末へのメッセージ送信に関する処理を行うメッセージ送信装置としてコンピュータを機能させるメッセージ送信プログラムであって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、
前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、
を備えるメッセージ送信装置として前記コンピュータを機能させることを特徴とするメッセージ送信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ送信を行う為の、メッセージ送信装置、メッセージ送信方法及びメッセージ送信プログラムに関する。
【背景技術】
【０００２】
現在、プッシュ通知（Push Notification）やメッセージ（プッシュメッセージとも言う）と呼ばれる、プッシュ型のイベント通知サービスが広く利用されている。【０００３】
この点、インターネットで利用されているＷＷＷ（World Wide Web）では、情報処理端末からのトリガにより、インターネット上のＷＷＷサーバに対して、情報処理端末への通信（主にダウンロード）を開始させるプル型通信がもっぱら利用されている。一方で、プッシュ通知では、インターネット上のサービスプロバイダのサービスサーバから情報処理端末に対する通信（主にダウンロード）を、サービスサーバ側のトリガにより、開始する点で相違する。【０００４】
このプッシュ通知は、一般的にサーバ装置から情報処理端末への何らかの通知に利用されるものである。具体的な用途としては、例えばＶｏＩＰ（Voice over Internet Protocol）に準拠した音声通話サービスにおける着信通知や、ＳＮＳ（Social Networking Service）の更新通知等が挙げられる。そしてプッシュ通知では、サーバ装置から情報処理端末に対してＩＰ（Internet Protocol）に準拠したネットワークを通して能動的にイベントが通知される。【０００５】
メッセージを送信するサーバ装置（以下、「プッシュサーバ」という。）は、ＶｏＩＰに準拠した音声通話サービスにおける着信通知、ＳＮＳの更新通知、チャットメッセージ配信、クラウドストレージの更新通知などの通知要求をサービス事業者サーバ（以下、単に「アプリサーバ」という。）から受け取る。ここで、アプリサーバは、ＳＮＳ管理者等のサービスを提供するサービス事業者が使用するサーバ装置である。【０００６】
サービス事業者は、予め、サービスを利用するためのアプリケーション（以下、単に「アプリ」という。）をユーザに提供する。そして、ユーザは自身が利用する携帯電話機やパーソナルコンピュータといった情報処理端末にアプリをインストールしておく。そして、ユーザは、サービス事業者から提供されたアプリを情報処理端末上で動作させる。【０００７】
一方で、サービス事業者は、アプリサーバを使用して、自身が提供するアプリ宛てのメッセージ送信をプッシュサーバに要求する。プッシュサーバは、メッセージ送信要求に従って情報処理端末上で動作するソフトウェア（以下、「プッシュクライアント」という。）に対してメッセージを送信する。プッシュクライアントは、受信したメッセージを宛先のアプリに渡す。アプリは、プッシュクライアントから受け取ったメッセージの内容に応じた処理を行う。【０００８】
上述したようなイベント通知サービスにおける処理の流れを説明する為のシーケンス図である図１を参照して更に説明を続ける。【０００９】
図１を参照すると、本説明例は情報処理端末１０００、プッシュサーバ１１００、メッセージデータベース１２００及びアプリサーバ１３００を含む。また、情報処理端末１０００はアプリ１００１及びプッシュクライアント１００２を含む。【００１０】
そして、まずアプリサーバ１３００からプッシュサーバ１１００に対し、アプリ１００１に対してのメッセージ送信要求を行う（ステップＳ１４０１）。【００１１】
プッシュサーバ１１００は、メッセージをメッセージデータベース１２００に記録させる（ステップＳ１４０２）。その後プッシュサーバ１１００は、メッセージの宛先となる情報処理端末１０００上のプッシュクライアント１００２に対し、未送信のメッセージが存在することを示すトリガパケットを送信する（ステップＳ１４０３）。【００１２】
トリガパケットを受信したプッシュクライアント１００２は、メッセージ取得要求をプッシュサーバ１１００に対し送信する（ステップＳ１４０４）。【００１３】
メッセージ取得要求を受信したプッシュサーバ１１００は、メッセージデータベース１２００から情報処理端末１０００宛てのメッセージを取得する（ステップＳ１４０５）。また、プッシュサーバ１１００は、プッシュクライアント１００２にメッセージ取得要求の応答としてメッセージを送信する（ステップＳ１４０６）。【００１４】
プッシュクライアント１００２は受信したメッセージをアプリ１００１に引き渡す（ステップＳ１４０７）。このような処理によりアプリ１００１へのメッセージの送信は終了する。【００１５】
このような、プッシュサーバにおいて端末に対するデータの送信準備が完了後、プッシュサーバがトリガを端末に送信し、トリガを受信した端末がデータをプッシュサーバから取得する方式が、例えば、特許文献１に記載されている。【００１６】
また、このようなプッシュサーバの他の一例として特許文献２に記載の技術が挙げられる。特許文献２に記載の技術は、プッシュ通知サービスを利用した情報配信システムにおいて、携帯端末機に付与された識別子を安全に管理することを目的としている。そして特許文献２に記載の技術は、情報配信システムに含まれるプッシュサーバ及びＷｅｂサーバ間での通信において暗号化通信を行うことにより携帯端末機に付与された識別子の漏洩等を防止する。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００２−３６６３６５号公報
【特許文献２】特開２０１２−２３０５５５号公報
【非特許文献】
【００１８】
【非特許文献１】3GPP TS 25.331 ： Radio Resource Control(RRC) ; Protocol specification、[online]、[平成２５年１月３０日検索]、インターネット<http://www.3gpp.org/ftp/Specs/archive/25_series/25.331/>
【非特許文献２】3GPP TS  36.331 ： Evolved Universal Terrestrial Radio Access (E-UTRA); Radio ResourceControl (RRC) ; Protocol specification、[online]、[平成２５年１月３０日検索]、インターネット<http://www.3gpp.org/ftp/Specs/archive/36_series/36.331/>
【発明の概要】
【発明が解決しようとする課題】
【００１９】
上述したような各技術を利用することにより、プッシュサーバ側からの能動的なメッセージ送信が可能となる。しかしながら、プッシュサーバにおいて情報処理端末に送信するメッセージの送信準備が完了してからトリガを送信するという方式では、プッシュサーバに多数の情報処理宛てのメッセージ送信要求が要求された場合、端末に対してプッシュメッセージが端末に到達するまでの遅延が大きくなるという問題が発生する。【００２０】
ここで、遅延は様々な要素が複合的に原因となって発生する。具体的には、情報処理端末に対してメッセージを送信する際の遅延の要素として、プッシュサーバと端末間の通信に関する遅延と、プッシュサーバ内での処理に関する遅延との２つが挙げられる。【００２１】
まず、前者の通信に関する遅延について説明する。プッシュサーバと情報処理端末間の通信は、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）、ＬＴＥ（Long
Term Evolution）及びＨＳＰＡ（High Speed Packet Access）等の規格に準拠した無線通信網を利用して行われる。【００２２】
これらの規格では、通信状況に応じてＲＲＣ（Radio Resource Control）状態を設定する、という制御を行うことにより電力の消費を抑える技術が存在する。具体的には、一定期間通信が行われなかった情報処理端末については、ＲＲＣ状態を通信可能状態（例えばＤＣＨ状態）から休止状態（例えばＩＤＬＥ状態）へと切り替えるという制御が行われる。【００２３】
そして、プッシュサーバと情報処理端末との通信時に生じる通信に関する遅延は、情報処理端末のＲＲＣ状態に応じて大きく異なる。【００２４】
例えば、ＷＣＤＭＡにおけるＤＣＨ状態やＬＴＥにおけるＣＯＮＮ状態の端末にパケットが到着するまでの通信遅延は典型的に数百ミリ秒程度であるのに対し、ＷＣＤＭＡ及びＬＴＥにおけるＩＤＬＥ状態の端末にパケットが到着するまでの通信遅延は数秒程度となる。【００２５】
なお、これらＬＴＥやＷ−ＣＤＭＡ、ＨＳＰＡにおけるＲＣＣ状態の種別及びＲＲＣ状態の遷移に関する仕組みについては、通信規格の標準化団体により設立された３ＧＰＰ（Third Generation Partnership Project）によって規定されている。そして、これらＲＲＣ状態の遷移等については非特許文献１および非特許文献２に詳細に記載されており、また、当業者にも知られている事項であるので、ここではこれ以上の詳細な説明を省略する。
次に、後者のプッシュサーバ内での処理に関する遅延について説明する。【００２６】
プッシュサーバでは、メッセージの送信の処理が逐次行われている。そして、処理を円滑に行えるように複数のサーバ装置を協働させるようなことも行われている。【００２７】
しかしながら、プッシュサーバの処理能力を超えるような多数の情報処理端末宛てのメッセージ送信要求が要求された場合、ある情報処理端末宛てのメッセージ送信のための処理は、他の情報処理端末宛てのメッセージ送信のための処理によって待たされることになる。これによりプッシュサーバ内での処理に関する遅延が生じてしまう。なお、場合によっては、プッシュサーバ内での処理に関する遅延は、上記の通信に関する遅延と同程度、もしくはそれ以上になりうる。【００２８】
ここで、メッセージ送信の為の処理の中でも特にトリガパケットの送信処理を速やかに行う必要がある。何故ならば、情報処理端末はトリガパケットを受信しない限り、メッセージの取得要求をプッシュサーバに送信しないため、トリガパケットの送信処理が遅れれば、その分、メッセージの到着も遅れることになるからである。【００２９】
そこで、メッセージ送信のための処理の内、トリガパケットの送信処理を先に実行し、かつ、トリガパケットの送信処理を他の処理に比べ高優先度で実施することが考えられる。このようにすることにより、トリガパケットの送信時刻が早くなるため、プッシュサーバ１１００がメッセージ送信要求を受信してから情報処理端末にメッセージが到達するまでの遅延が小さくなることが期待される。【００３０】
しかしながら、プッシュサーバは、情報処理端末からのメッセージ取得要求を受信するまでの間に、メッセージ送信のために必要な他の処理、例えば、メッセージのメッセージデータベースへの記録処理、を完了していなければ、情報処理端末からのメッセージ取得要求を受信した直後にメッセージを情報処理端末に送信することができず、メッセージ送信のために必要な他の処理の完了を待ってから、メッセージを送信することとなるため、メッセージが端末に到達するまでの遅延が大きくなる。例えば、多数のメッセージ送信要求を受け付けている場合のように、メッセージサーバに一定以上の負荷がかかっている場合に、情報処理端末からのメッセージ取得要求を受信するまでの間に、メッセージ送信のために必要な他の処理を完了することができない。
そこで、本発明は、例えば、プッシュサーバに負荷がかかっている場合にも、プッシュサーバがメッセージ送信要求を受信してから、端末にプッシュメッセージを送信するまでの遅延の増大を抑止することを可能にする、メッセージ送信装置、メッセージ送信方法及びメッセージ送信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００３１】
本発明の第１の観点によれば、端末へのメッセージ送信に関する処理を行うメッセージ送信装置であって、未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、を備えることを特徴とするメッセージ送信装置が提供される。【００３２】
本発明の第２の観点によれば、端末へのメッセージ送信に関する処理を行うメッセージ送信方法であって、未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知ステップと、前記メッセージを前記端末に送信するための準備処理を実行する準備ステップと、前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定ステップと、を備えることを特徴とするメッセージ送信方法が提供される。【００３３】
本発明の第３の観点によれば、端末へのメッセージ送信に関する処理を行うメッセージ送信装置としてコンピュータを機能させるメッセージ送信プログラムであって、未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、を備えるメッセージ送信装置として前記コンピュータを機能させることを特徴とするメッセージ送信プログラムが提供される。
【発明の効果】
【００３４】
本発明によれば、例えば、プッシュサーバに負荷がかかっている場合にも、プッシュサーバがメッセージ送信要求を受信してから、端末にプッシュメッセージを送信するまでの遅延の増大を抑止することが可能となる。
【図面の簡単な説明】
【００３５】
【図１】一般的な技術におけるプッシュサーバのメッセージ送信処理の流れを表すシーケンス図である。
【図２】本発明の実施形態１におけるシステムの構成例を表すブロック図である。
【図３】本発明の実施形態１におけるプッシュサーバの構成例を表すブロック図である。
【図４−１】本発明の各実施形態における処理期限の算出について説明する概念図である。
【図４−２】本発明の各実施形態における処理期限とメッセージ記録処理の優先度の関係の例を表すグラフである。
【図５】本発明の実施形態１における情報処理端末の構成例を表すブロック図である。
【図６】本発明の実施形態１における動作例を表すシーケンス図である。
【図７】本発明の実施形態１における処理スケジュールの方法の例を表すフローチャートである。
【図８】本発明の実施形態２におけるシステムの構成例を表すブロック図である。
【図９】本発明の実施形態２におけるプッシュサーバの構成例を表すブロック図である。
【図１０】本発明の実施形態２における動作例を表すシーケンス図である。
【図１１】本発明の実施形態３におけるプッシュサーバの構成例を表すブロック図である。
【図１２】本発明の実施形態３における動作例を表すフローチャートである。
【発明を実施するための形態】
【００３６】
[実施形態１]
次に、本発明の実施形態１について図面を参照して詳細に説明する。
【００３７】
図２は、実施形態１のシステム構成を表すブロック図である。図２を参照すると、実施形態１によるシステムは、プッシュサーバ１００−１〜１００−ｎ、メッセージデータベース２００、情報処理端末３００−１〜３００−ｍ及びアプリサーバ４００−１〜４００−ｊを含む。ここで、符号の末尾の「ｍ」、「ｎ」及び「ｊ」はそれぞれが１以上の整数である。すなわち、プッシュサーバ１００、情報処理端末３００及びアプリサーバ４００の台数に特に制限は無い。
【００３８】
また、プッシュサーバ１００−１〜１００−ｎと個々の情報処理端末３００−１〜３００−ｍは無線通信網（図示を省略する）により接続されている。そして、この無線通信網はＲＲＣ状態の切り替えが可能な無線通信方式に準拠して実現されている。ここで、ＲＲＣ状態の切り替えが可能な無線通信方式とは例えば、［発明が解決しようとする課題］の欄にて説明したＬＴＥやＷ−ＣＤＭＡ及びＨＳＰＡといった無線方式である。
【００３９】
なお、以下の説明において、例えばＷＣＤＭＡにおけるＤＣＨ状態やＬＴＥにおけるＣＯＮＮ状態のような、プッシュサーバ１００から情報処理端末３００にパケットが到着するまでの通信遅延が典型的に数百ミリ秒程度である状態を「通信可能状態」と呼ぶ。一方で、ＷＣＤＭＡ及びＬＴＥにおけるＩＤＬＥ状態のような、プッシュサーバ１００から情報処理端末３００に端末にパケットが到着するまでの通信遅延が典型的に数秒程度の状態を「休止状態」と呼ぶ。
【００４０】
一方で、プッシュサーバ１００−１〜１００−ｎとアプリサーバ４００−１〜４００−ｊ、並びに、プッシュサーバ１００−１〜１００−ｎとメッセージデータベース２００は、それぞれが有線又は無線を問わないネットワーク（図示を省略する。）を介して通信可能な状態で接続されている。このネットワークは任意の方式に準拠して実現することが可能であり、専用線により実現されても良いがインターネット等の公衆網を用いるものであっても良い。
【００４１】
プッシュサーバ１００−１〜１００−ｎは、アプリサーバ４００から、情報処理端末３００へのメッセージ送信要求を受信し、宛先となっている情報処理端末３００へのメッセージ送信処理を行う。プッシュサーバ１００としての機能は１台のプッシュサーバ１００により実現することも可能ではある。しかしながら実施形態１では、メッセージ送信処理の負荷分散のため、複数台のプッシュサーバ１００−１〜１００−ｎが協働することにより実現されるものとする。情報処理端末３００及びアプリサーバ４００から、プッシュサーバ１００への通信は、例えばロードバランサ（負荷分散装置）等によって、プッシュサーバ１００−１から１００−ｎのいずれか一つに割り振られ、各プッシュサーバ１００の負荷は可能な限り平準化されるものとする。
【００４２】
メッセージデータベース２００は、プッシュサーバ１００−１〜１００−ｎが情報処理端末３００−１〜３００−ｍに対して送信するメッセージを記録する。メッセージデータベース２００は、プッシュサーバ１００−１〜１００−ｎと通信可能に接続され、任意のプッシュサーバ１００−１〜１００−ｎからメッセージデータベース２００に対して、メッセージの記録（書込み）および参照（読出し）を行うことが可能である。メッセージデータベース２００は、例えば、ＲＤＢ（Relational Data Base）で実現することを想定するが、ＫＶＳ（Key
Value Store）等の他のデータ格納方式により実現するようにしても良い。
【００４３】
情報処理端末３００−１〜３００−ｍは、プッシュサーバ１００−１〜１００−ｎを介して、アプリサーバ４００−１〜４００−ｊからのメッセージを受信する。情報処理端末３００−１〜３００−ｍは、例えば、携帯電話機、タブレット端末、パーソナルコンピュータ、デジタルサイネージ端末などである。
【００４４】
また、情報処理端末３００−１〜３００−ｍは、プッシュクライアント３１０とアプリ３２０−１〜３２０−ｋ（ｋは１以上の整数）を含む。
【００４５】
プッシュクライアント３１０は、プッシュサーバ１００−１〜１００−ｎからメッセージを受信し、宛先に指定されたアプリ３２０−１〜３２０−ｋにメッセージを送信する。アプリ３２０−１〜３２０−ｋは、例えば、サービス事業者が提供するアプリである。
【００４６】
アプリサーバ４００−１〜４００−ｊは、例えば、サービス事業者がサービスを提供する為に利用するサーバである。アプリサーバ４００−１〜４００−ｊは、情報処理端末３００−１〜３００−ｍ上で動作するアプリ３２０−１〜３２０−ｋに対するメッセージの送信要求をプッシュサーバ１００−１〜１００−ｎに対して行う。
【００４７】
プッシュサーバ１００及びアプリサーバ４００といった、各サーバはそれぞれ別個のサーバ装置により実現されても良いが、１つのサーバ装置により複数のサーバの機能を実現するようにしても良い。また、複数のサーバ装置が協働することにより１つのサーバの機能を実現しても良い。また、メッセージデータベース２００が物理的にプッシュサーバ１００に内蔵されていても良い。
【００４８】
続いて、実施形態１におけるプッシュサーバ１００の機能ブロックを表すブロック図である図３を参照して説明を行う。
【００４９】
図３に表されるように、プッシュサーバ１００−１〜１００−ｎは、メッセージ送信要求受信部１０１、ＲＲＣ状態取得部１０２、メッセージ記録処理部１０３、トリガパケット送信部１０４、処理期限決定部１０５、処理優先度決定部１０６、処理スケジューリング部１０７、メッセージ参照部１０８及びメッセージ送信部１０９を含む。
【００５０】
メッセージ送信要求受信部１０１は、アプリサーバ４００から情報処理端末３００に対するメッセージ送信要求を受信する。メッセージ送信要求には、例えば、送信したいメッセージそのもの、メッセージの送信先となる情報処理端末３００を識別する識別子、及び、メッセージを通知するアプリ３２０を特定する識別子が含まれる。
【００５１】
ＲＲＣ状態取得部１０２は、メッセージ送信要求受信部１０１が受信したメッセージ送信要求に応じて送信するメッセージの宛先となる情報処理端末３００の現在のＲＲＣ状態を取得する。現在のＲＲＣ状態は、例えば、無線通信網に含まれている基地局（図示を省略する。）から取得することが可能である。この場合は、メッセージの送信先となる情報処理端末３００を識別する識別子及びＲＲＣ状態の問い合わせ要求を基地局に送信し、その返信として、メッセージの送信先となる情報処理端末３００の現在のＲＲＣ状態を受信する。
【００５２】
また、プッシュサーバと情報処理端末３００の通信履歴を基に、メッセージの送信先となる情報処理端末３００の現在のＲＲＣ状態を推定することも可能である。例えば、直近の数秒間にプッシュサーバと通信を行った情報処理端末３００のＲＲＣ状態は通信可能状態（例えば、ＤＣＨ）であり、直近の数秒以上の間に通信を行っていない情報処理端末３００のＲＲＣ状態は休止状態（例えば、ＩＤＬＥ）であると推定できる。また、他の方法によりＲＲＣ状態を取得してもよい。
【００５３】
メッセージ記録処理部１０３は、メッセージ送信要求受信部１０１が受信したメッセージ送信要求に含まれる情報処理端末３００に送信するメッセージをメッセージデータベース２００に記録する処理を行う。
【００５４】
トリガパケット送信部１０４は、メッセージ送信要求により指定されたメッセージの送信先である情報処理端末３００に対して、そのメッセージがまだ未送信のままプッシュサーバ内に存在すること（送信を待機していること）を通知するパケットであるトリガパケットを送信する。
【００５５】
処理期限決定部１０５は、メッセージ記録処理部１０３が行う処理の処理期限終了時刻を、ＲＲＣ状態取得部１０２によって取得した情報処理端末３００のＲＲＣ状態に基づいて決定する。ここで、「処理期限終了時刻」は、「トリガパケット送信時刻」に「情報処理端末３００のＲＲＣ状態に応じた処理期限」を加えたものとする。すなわち、「処理期限終了時刻＝トリガパケット送信時刻＋情報処理端末３００のＲＲＣ状態に応じた処理期限」とする。
【００５６】
ここで、トリガパケット送信時刻とは、メッセージの送信先となる情報処理端末３００にトリガパケットを送信する時刻である。
【００５７】
また、情報処理端末３００のＲＲＣ状態に応じた処理期限とは、例えば、メッセージの送信先となる情報処理端末３００の状態が休止状態であれば３秒、通信可能状態であれば０．１秒といった値である。
【００５８】
なお、図４−１は、処理期限及び処理期限終了時刻について表した概念図である。図４−１に表されるように処理期限は、メッセージの送信先となる情報処理端末３００の状態が通信可能状態の場合には短く、休止状態時の場合には長く設定される。
【００５９】
なお、上記で例示した３秒や０．１秒といった値は一例に過ぎず、準拠する通信方式や実装環境に応じて任意の値とすることが可能である。また、実施形態１では通信可能状態と休止状態の２つの状態に情報処理端末３００の状態を区別しているが、これを更に細かく区別するようにしても良い。例えば、高速通信可能状態、低速通信可能状態、休止状態、といったように三段階に状態が変化すると仮定するのであれば、これら３つの状態それぞれについての、ＲＲＣ状態に応じた処理期限を異なるものに設定するようにしても良い。
【００６０】
処理優先度決定部１０６は、メッセージ記録処理部１０３が行う処理とトリガパケット送信部１０４が行う処理の優先度を決定する。ここで、メッセージ記録処理部１０３が行う処理とはメッセージ記録処理のことである。また、トリガパケット送信部１０４が行う処理とはトリガパケット送信処理である。なお、メッセージ記録処理は本発明の「準備処理」に相当する。また、トリガパケット送信処理は本発明の「通知処理」に相当する。
【００６１】
処理優先度は、例えば、次のようにして決定する。まず、処理優先度は０〜１０の整数で表すとする。また、数値が大きいほど優先度の高いことを示す。更に、トリガパケット送信処理の優先度は、予め決められた所定値とする。例えば、中央値５とする。なお、本実施形態の実装環境に応じてトリガパケット送信処理の優先度を５以外の値としても良い。一方で、メッセージ記録処理の処理優先度は、処理期限終了時刻までの残り時間に応じて変化させる。
【００６２】
図４−２に、メッセージ記録処理の「処理期限終了時刻」までの残り時間と処理優先度の関係を表したグラフを示す。図４−２のように処理期限終了時刻までの残り時間が少ないほど処理優先度を高くする。処理期限終了時刻までの残り時間が所定値よりも短いメッセージの記録処理はトリガパケット送信処理に比べて高い優先度となり、処理期限終了時刻までの残り時間が所定値（図４−２の例では１．５秒）よりも長いメッセージ記録処理の優先度はトリガパケット送信処理に比べ低い優先度となる。なお、処理期限終了時刻の過ぎたメッセージ記録処理の優先度は最大値とする。ここでは１０とする。また、ＲＲＣ状態に応じた処理期限は今回最長でも３秒であると想定する。従って処理期限終了時刻までの残り時間も最長でも３秒である。よって、処理期限終了時刻までの残り時間が３秒以上であるメッセージ記録処理の優先度を全て０とする。そして、処理期限終了時刻までの残り時間が３秒を切ってから、０．３秒が経過する毎に優先度を１つずつ上げていくこととする。
【００６３】
処理スケジューリング部１０７は、処理優先度決定部１０６の決定した優先度に応じて、メッセージ記録処理部１０３の行うメッセージ記録処理とトリガパケット送信部１０４の行うトリガパケット送信処理の処理スケジューリングを行う。具体的には処理スケジューリング部１０７は、処理優先度の高い処理ほど先に処理されるようにスケジューリングする。
【００６４】
メッセージ参照部１０８は、メッセージデータベース２００を参照して、情報処理端末３００に送信するメッセージを取得する。
【００６５】
メッセージ送信部１０９は、メッセージ参照部１０８の取得したメッセージを情報処理端末３００に送信する。
【００６６】
続いて、実施形態１における情報処理端末３００の機能ブロックを表すブロック図である図５を参照して説明を行う。
【００６７】
情報処理端末３００は、プッシュクライアント３１０とアプリ３２０−１〜３２０−ｋを含む。また、プッシュクライアント３１０は、トリガパケット受信部３１１、メッセージ受信部３１２及びメッセージ通知部３１３を含む。
【００６８】
トリガパケット受信部３１１は、プッシュサーバ１００のトリガパケット送信部１０４が送信したトリガパケットを受信する。
【００６９】
メッセージ受信部３１２は、トリガパケット受信部３１１がトリガパケットを受信後、プッシュサーバ１００のメッセージ送信部１０９に対して、メッセージ取得要求を送信する。メッセージ取得要求を受信したプッシュサーバ１００のメッセージ送信部１０９は、メッセージ取得要求の応答としてメッセージを送信し、情報処理端末３００のメッセージ受信部３１２がメッセージを受信する。
【００７０】
メッセージ通知部３１３は、メッセージ受信部３１２が受信したメッセージを、メッセージの宛先に指定されたアプリ３２０に対して通知する。
【００７１】
アプリ３２０−１〜３２０−ｋは、メッセージを利用するアプリであり、具体的なアプリの用途及び種別はどのようなものであっても良く、特に限定はされない。
【００７２】
以上、実施形態１の各機能ブロックについて詳細に説明した。なお、図２，３及び５には実施形態１に特に関係する機能ブロックのみを図示しているが、これは説明の便宜の為である。
【００７３】
すなわち、実施形態１は、図示されている機能ブロック以外の機能ブロックが存在することを禁止することを意図したものではない。例えば、プッシュサーバ１００、メッセージデータベース２００、情報処理端末３００及びアプリサーバ４００−１〜４００−ｊのそれぞれは図示しない通信部や、制御部及び記録部といった機能ブロックを内部又は外部に含んでいる。また、図示されている又は図示を省略されている各機能ブロックは、実施形態１特有の動作にのみ利用されても良いが、他の用途に汎用的に利用されても良い。例えばアプリの実行や、プッシュメッセージの送受信以外のパケット通信に利用されても良い。
【００７４】
次に実施形態１の基本的動作について図６のシーケンス図及び図７のフローチャートを参照して説明する。
【００７５】
図６は、実施形態１全体の動作例を示すシーケンス図である。本動作例では、アプリサーバ４００−１が情報処理端末３００−１上で動作するアプリ３２０−１に対してメッセージを送信する場合を想定して説明する。
【００７６】
最初に、アプリサーバ４００−１が、プッシュサーバ１００のメッセージ送信要求受信部１０１に対してメッセージ送信要求を送信する（ステップＳ１１）。
【００７７】
本動作例では、ステップＳ１１におけるメッセージ送信要求は、ロードバランサ（負荷分散装置）によりプッシュサーバ１００−１に割り振られたとする。すなわち、メッセージ送信要求を受信したプッシュサーバ１００は、プッシュサーバ１００−１であったとする。ここで、メッセージ送信要求には、メッセージの宛先となる情報処理端末３００とアプリ３２０それぞれの識別子と、メッセージそのものとが含まれる。本動作例ではメッセージの宛先が情報処理端末３００−１のアプリ３２０−１なので、メッセージ送信要求には、情報処理端末３００−１を示す識別子とアプリ３２０−１を示す識別子を含んでいる。メッセージ送信要求は、例えば、ＨＴＴＰ(Hypertext Transfer Protocol)により規定されるＰＯＳＴメソッドによって送信される。
【００７８】
次に、プッシュサーバ１００−１のトリガパケット送信部１０４がメッセージの送信先となる情報処理端末３００−１に対してトリガパケットを送信する（ステップＳ１２）。なお、ステップＳ１２の処理は、プッシュサーバ１００−１の処理スケジューリング部１０７によって、処理を開始するべきと判断された時点で実行される。
【００７９】
この処理スケジューリング部１０７の判断に関して図７を参照して詳細に説明する。図７は、処理スケジューリング部１０７が実行する処理のスケジューリングを行う際の動作の一例を示したフローチャートである。
【００８０】
まず、処理スケジューリング部１０７は、現在プッシュサーバ１００において未処理となっているトリガパケット送信処理とメッセージ記録処理の処理優先度を確認する（ステップＳ２１）。各処理の処理優先度は処理優先度決定部１０６によって評価される。なお、処理優先度を評価するにあたっては、メッセージ記録処理の現時点での処理期限終了時刻までの残り時間をまず算出する。そして、残り時間に応じて処理優先度を評価する。上述したようにメッセージ記録処理の優先度は、処理期限終了時刻が近づくにつれて高くなっているからである。一方で、トリガパケット送信処理については優先度が一定であるので改めて算出を行う必要は無い。
【００８１】
ここで、トリガパケット送信処理の処理優先度が最大の場合は（ステップＳ２２においてＹｅｓ）、トリガパケット送信処理の内、一つをトリガパケット送信処理部１０４が実行する（ステップＳ２３）。ここで、本動作例では、トリガパケット送信処理の優先度を５としているので、ステップＳ２２においてＹｅｓになる場合とは、未処理となっているメッセージ記録処理が存在しない場合か、未処理となっているメッセージ記録処理が存在するとしても処理期限終了時刻までに余裕が有り、未だ優先度が４以下であるような場合である。
【００８２】
なお、ステップＳ２３においてトリガパケット送信処理が複数存在する場合に、何れのトリガパケット送信処理を実行するかの基準は任意に定めることが可能である。例えば最も過去に受信したメッセージ送信要求に対応するトリガパケット送信処理を実行することが考えられる。この他にも、例えばメッセージ送信要求の送信元のアプリサーバ４００に応じてトリガパケット送信処理を実行するようにしても良い。例えば、アプリサーバ４００−１のメッセージ送信要求に対応するトリガパケット送信処理は、アプリサーバ４００−１以外の他のアプリサーバ４００のメッセージ送信要求に対応するトリガパケット送信処理よりも優先して実行するようにしても良い。また、同様に送信先の情報処理端末３００に応じてトリガパケット送信処理を実行するようにしても良い。
【００８３】
一方、メッセージ記録処理の優先度が最大の場合は（ステップＳ２２においてＮｏ）、メッセージ記録処理の内、優先度が最大の処理をメッセージ記録処理部１０３が実行する（ステップＳ２４）。ここで、本動作例では、トリガパケット送信処理の優先度を５としているので、ステップＳ２２においてＮｏになる場合とは、未処理となっているトリガパケット送信処理が存在しない場合か、未処理となっているトリガパケット送信処理が存在するとしても、これとは別に、メッセージ記録処理であって、処理期限終了時刻までに余裕が無く、優先度が６以上となっているようなメッセージ記録処理が存在しているような場合である。なお、ステップＳ２４において優先度が最大のメッセージ記録処理が複数存在する場合もあり得る。例えば優先度が８のメッセージ記録処理が複数存在するような場合である。この場合には、上述したステップＳ２３と同じような基準で実行するメッセージ記録処理を選択する。また、優先度が同じ場合には、処理期限終了時刻までの残り時間を更に厳密に比較して、少しでも処理期限終了時刻までの残り時間が少ないメッセージ記録処理を選択して実行するようにしても良い。
【００８４】
なお、トリガパケット送信処理は優先度５であるが、このトリガパケット送信処理と優先度５のメッセージ記録処理とが両方存在しており、更に、優先度６以上のメッセージ記録処理は存在していない場合もあり得る。この場合は、トリガパケット送信処理の優先度は最大とは判断しない（ステップＳ２２においてＮｏ）。従って、ステップＳ２４に進み、メッセージ記録処理の内、優先度が最大の処理をメッセージ記録処理部１０３が実行する（ステップＳ２４）。
【００８５】
もっとも、このようなトリガパケット送信処理と優先度５のメッセージ記録処理とが両方存在しており、更に、優先度６以上のメッセージ記録処理は存在していない場合に、トリガパケット送信処理の優先度が最大であると判断するようにしても良い（ステップＳ２２においてＹｅｓ）。この場合には、トリガパケット送信処理の内の１つを実行する（ステップＳ２３）。また、このような事態が発生しないようにトリガパケット送信処理の優先度を例えば５．５と設定するようにしても良い。メッセージ記録処理の優先度は整数に限られるので、５．５という優先度になることは無い。従って、メッセージ記録処理とトリガパケット送信処理の優先度が同一という事態は発生しないこととなり、必ず高低の差が発生することになる。
【００８６】
ステップＳ２３又はステップＳ２４が完了後、ステップＳ２５に進む。そして、ステップＳ２３又はステップＳ２４において実行したメッセージ記録処理又はトリガパケット送信処理を次回の優先度の比較対象から除外する処理を行う（ステップＳ２５）。その後、再度ステップＳ２１の処理に戻り、同様の処理を繰り返す。
【００８７】
図６を参照した説明に戻る。プッシュサーバ１００−１のトリガパケット送信部１０４がトリガパケットを情報処理端末３００−１へ送信後（ステップＳ１２）、処理期限決定部１０５がメッセージ記録処理の処理期限終了時刻を決定する（ステップＳ１３）。処理期限終了時刻の設定は上述したように、「トリガパケット送信時刻」に「情報処理端末３００のＲＲＣ状態に応じた処理期限」を加算することにより行われる。
【００８８】
その後、プッシュサーバ１００−１のメッセージ記録処理部１０３がメッセージデータベース２００にメッセージを記録する（ステップＳ１４）。このメッセージはステップＳ１１において受信したメッセージ送信要求に含まれていたものである。そして、具体的にメッセージデータベース２００に記録される情報は、メッセージの宛先となる情報処理端末３００−１とアプリ３２０−１の識別子とメッセージ本文である。なお、ステップＳ１４の処理は、プッシュサーバ１００−１の処理スケジューリング部１０７によって、処理を開始するべきと判断された時点で実行される。
【００８９】
メッセージ記録処理部１０３が動作している他方で、情報処理端末３００−１のトリガパケット受信部３１１が、トリガパケットを受信すると、メッセージ受信部３１２がメッセージ取得要求をプッシュサーバ１００に対して送信する（ステップＳ１５）。
【００９０】
本動作例では、メッセージ取得要求についての対応を割り振られたのはプッシュサーバ１００−ｎであったとする。なお、トリガパケットを送信したプッシュサーバ１００とメッセージ取得要求を受信するプッシュサーバ１００は、ロードバランサによって振り分けられ、一般的に同一のプッシュサーバ１００とはならない。
【００９１】
メッセージ取得要求には、メッセージ取得要求を送信した情報処理端末３００−１の識別子が含まれる。メッセージ取得要求は、例えば、ＨＴＴＰのＧＥＴメソッドにより送信される。プッシュサーバ１００―ｎのメッセージ送信部１０９がメッセージ取得要求を受信すると、メッセージ参照部１０８がメッセージデータベース２００を参照する。そして、プッシュサーバ１００―ｎのメッセージ送信部１０９は、メッセージ送信要求に含まれる情報処理端末３００−１の識別子に基づいて情報処理端末３００−１に送信するメッセージを取得する（ステップＳ１６）。
【００９２】
次に、プッシュサーバ１００―ｎのメッセージ送信部１０９は、メッセージ参照部１０８が取得したメッセージを、メッセージ送信要求への応答として、情報処理端末３００−１に送信する（ステップＳ１７）。ステップＳ１７で、情報処理端末３００−１に送信される情報には、宛先となるアプリ３２０−１の識別子とメッセージ本文が含まれる。メッセージ送信要求の応答は、例えば、ＨＴＴＰのステータスコードである２００  ＯＫ（HTTP status code 200）で送信される。情報処理端末３００−１のメッセージ受信部３１２がメッセージを受信後、メッセージ通知部３１３がメッセージの宛先として指定されているアプリ３２０−１に対してメッセージを通知する（ステップＳ１８）。
【００９３】
以上に説明したように、実施形態１では、トリガパケットの送信がメッセージ記録処理に先んじて行われる。そのため、アプリサーバがメッセージ送信要求を受信してから、トリガパケットが情報処理端末に到達するまでの時間が短くなり、その結果、情報処理端末にメッセージが到達するまでの遅延が小さくなる。
【００９４】
また、実施形態１ではＲＲＣ状態を考慮した上で、複数のメッセージ記録処理それぞれに優先度を付している。そのため、通信可能状態にあり、即座にパケットが受信できる情報処理端末に対して優先的にメッセージ送信しようとする際に、未だメッセージ記録処理が終了していないという問題を回避することが可能となる。一方で、休止状態時の情報処理端末に対してメッセージを送信しようとするまでの間には、休止状態時の情報処理端末に関してのメッセージ記録処理を終了させておくことも可能となる。すなわち、実施形態１では、トリガパケットを受信した情報処理端末からのメッセージ取得要求がプッシュサーバに到達するまでの間に、メッセージの送信に必要なメッセージ記録処理が完了しているため、プッシュサーバはメッセージ取得要求に対して即座にメッセージを含む応答を返信することができる。
【００９５】
以上より、実施形態１によれば、プッシュサーバが多数のメッセージ送信要求を受け付けて、それにより大きな負荷がかかっている場合にも、プッシュサーバがメッセージ送信要求を受け付けてからプッシュサーバから端末にプッシュメッセージが到着するまでの遅延の増大を抑止することができる。
【００９６】
［実施形態２］
続いて、実施形態１を一部変形した実施形態である実施形態２について説明する。
【００９７】
実施形態１では、メッセージの送信先となっている情報処理端末のＲＲＣ状態が信頼できる場合について述べた。一方で、本実施の形態では、取得したＲＲＣ状態にある程度の不確定性が含まれる場合について述べる。
【００９８】
ここで、取得したＲＲＣ状態に不確定性が含まれる事象は、例えば、無線通信網の基地局から情報処理端末のＲＲＣ状態の情報が一定周期でしか得られない場合がある。この場合、基地局から情報を取得した時点とメッセージを送信する時点は異なり、タイムラグが生じる。そのため、基地局から情報を取得してからメッセージを送信するまでの間に情報処理端末のＲＲＣ状態が変化している場合がある。そして、このような場合には下述するように２つの問題が生じる。
【００９９】
例えば、基地局から情報を取得した時点においてはＲＣＣ状態が休止状態時であったにも関わらず、その後通信が行われたためにメッセージを送信する時点ではＲＲＣ状態が通信可能状態になっている場合が考えられる。この場合には、メッセージの送信を待機する必要はないため、メッセージ記録処理を速やかに行うことが好ましいが、取得したＲＲＣ状態が休止状態であった為、処理期限が長く設定されメッセージ記録処理は優先度が低くなってしまっている。その場合、トリガパケットを受信した情報処理端末からのメッセージ取得要求がプッシュサーバに到達した際に、メッセージ記録処理が完了していないため、プッシュサーバは即座にメッセージを送信することができず、メッセージ送信処理は、メッセージ記録処理が完了するまで待つ必要があり、メッセージが情報処理端末に到達するまでの遅延が増大する、という第１の問題が生じる。
【０１００】
一方で、基地局から情報を取得した時点においてはＲＣＣ状態が通信可能状態であったにも関わらず、その後通信が行われなかったためにメッセージを送信する時点ではＲＲＣ状態が休止状態になってしまっている場合が考えられる、この場合には、ＲＲＣ状態が通信可能状態になるまでメッセージの送信を待機する必要が生じる。従って、メッセージ記録処理を優先的に行う必要はないが、取得したＲＲＣ状態が通信可能状態であった為、優先的にメッセージ記録処理が実行されてしまっている。そのため、他の優先すべきメッセージ記録処理が後回しにされてしまう、という第２の問題が生じる。
【０１０１】
このように、取得したＲＲＣ状態に不確定性が含まれていると、メッセージ記録処理の処理期限が正しく設定できないことから不具合が生じる。そこで、実施形態２は、この第１の問題を解消することを目的とする。
【０１０２】
図８は、実施形態２のシステム構成を表すブロック図である。図８を参照すると、実施形態２は、プッシュサーバ５００−１〜５００−ｎ、メッセージデータベース２００、情報処理端末３００−１〜３００−ｍ、アプリサーバ４００−１〜４００−ｊを含む。
【０１０３】
実施形態１との相違点は、プッシュサーバ１００−１〜１００−ｎがプッシュサーバ５００−１〜５００−ｎに置きかわっている点である。従って、以下では、もっぱらプッシュサーバ５００−１〜５００−ｎについて説明する。一方で、メッセージデータベース２００、情報処理端末３００−１〜３００−ｍ及びアプリサーバ４００−１〜４００−ｊ並びにこれらとプッシュサーバ５００−１〜５００−ｎの接続等に関しては、実施形態１と同様であるため、詳細な説明を省略する。
【０１０４】
図９は実施形態２におけるプッシュサーバ５００の構成を示すブロック図である。実施形態２におけるプッシュサーバ５００は、処理期限変更部５０１を有する点で、実施形態１におけるプッシュサーバ１００と異なる。なお、実施形態１におけるプッシュサーバ１００と同一の構成要素に関しては、同一の符号を付し、詳細な説明を省略する。
【０１０５】
処理期限変更部５０１は、処理期限決定部１０５が決定したメッセージ記録処理の処理期限の変更を行う。
【０１０６】
次に、実施形態２の基本的動作について図１０のシーケンス図を参照して説明する。本動作例では、アプリサーバ４００−１が情報処理端末３００−１上で動作するアプリ３２０−１に対してメッセージを送信する場合を想定して説明する。また、プッシュサーバ５００−１がアプリサーバ４００−１から送信されたメッセージ送信要求を受信し、プッシュサーバ５００−ｎが情報処理端末３００−１から送信されたメッセージ取得要求を受信する場合を想定して説明する。なお、メッセージ送信要求を受信するプッシュサーバ５００とメッセージ取得要求を受信するプッシュサーバ５００が異なるのは実施形態１の説明時に説明したようにロードバランサによる割り振りが行われるからである。
【０１０７】
実施形態２におけるシーケンスはプッシュサーバ５００−１がメッセージの記録処理期限を決定するステップＳ１３までは、実施形態１と同一の処理である。もっとも、実施形態２における動作例においては実施形態１における動作例と異なり、メッセージの記録処理が完了する前に、情報処理端末３００からのメッセージ取得要求をプッシュサーバ５００−ｎが受信する（ステップＳ１５）。これは、上述したように情報処理端末３００−１のＲＲＣ状態が休止状態時であると判断していたにも関わらず、実際には通信可能状態であったため、トリガパケット送信後、想定していたよりも速やかに情報処理端末３００−１からのメッセージ取得要求が返信されるからである。
【０１０８】
情報処理端末３００−１からメッセージ取得要求を受信したプッシュサーバ５００−ｎのメッセージ参照部１０８は、メッセージデータベース２００を参照し、情報処理端末３００−１宛てのメッセージを取得しようとする。しかし、情報処理端末３００−１宛てのメッセージ記録処理が完了していないため、メッセージ参照部１０８はメッセージの取得に失敗する（ステップＳ１６）。この場合、速やかに情報処理端末３００−１宛てのメッセージについてメッセージ記録処理を行うことが望ましい。しかしながら、情報処理端末３００−１のＲＲＣ状態は休止状態時であると判断されてしまっているために、情報処理端末３００−１宛てのメッセージについて、メッセージ記録処理の優先度は未だ低いままである。
【０１０９】
そこでプッシュサーバ５００−ｎの処理期限変更部５０１は、情報処理端末３００−１宛てのメッセージについてメッセージ記録処理の処理期限の変更を行う。
【０１１０】
プッシュサーバ５００−ｎの処理期限変更部５０１は、情報処理端末３００−１宛てのメッセージ記録処理を行う予定でいるプッシュサーバ５００−１に対し、処理期限変更要求を送信し、メッセージ記録処理の処理期限の変更を依頼する（ステップＳ３１）。この点、上述したように本実施形態ではプッシュサーバ５００が行う各処理がロードバランサによって振り分けられ、同一のプッシュサーバ５００が一貫して全ての処理を行っている訳ではない。そのため、プッシュサーバ５００−ｎは、どのプッシュサーバ５００が情報処理端末３００−１宛てのメッセージ記録処理を担当しているかの情報を保持していない。よって、各プッシュサーバ５００にそれぞれ含まれる各処理期限変更部５０１は協働してメッセージ記録処理を担当しているプッシュサーバ５００を探す。以下の説明ではそれぞれの処理期限変更部５０１を明確に区別するため、処理期限変更部５０１の末尾にもプッシュサーバ５００と同様に符号を付加する。例えば、プッシュサーバ５００−１に含まれる処理期限変更部５０１は、処理期限変更部５０１−１と表記し、プッシュサーバ５００−ｎに含まれる処理期限変更部５０１は、処理期限変更部５０１−ｎと表記する。
【０１１１】
まず、プッシュサーバ５００−ｎの処理期限変更部５０１−ｎは、プッシュサーバ５００−ｎ以外の他のプッシュサーバ５００に含まれている処理期限変更部５０１（処理期限変更部５０１−１〜処理期限変更部５０１−ｎ―１）全てに対して処理期限変更要求を送信する。
【０１１２】
この処理期限変更要求には、依頼を送信した処理期限変更部５０１−ｎが含まれているプッシュサーバ５００であるプッシュサーバ５００−ｎを示す識別子と、メッセージの宛先となる情報処理端末３００−１を識別する識別子が保持されている。
【０１１３】
処理期限変更要求を受信した処理期限変更部５０１−ｎ以外の処理期限変更部５０１（処理期限変更部５０１−１〜処理期限変更部５０１−ｎ―１）の各々は、処理期限変更要求に含まれるメッセージの宛先となる情報処理端末３００−１の識別子に基づいて、処理期限変更部５０１（処理期限変更部５０１−１〜処理期限変更部５０１−ｎ―１）自身が含まれているプッシュサーバ５００が情報処理端末３００−１のメッセージ記録処理を行う予定のプッシュサーバ５００であるのか否かを判断する。つまり、処理期限変更部５０１−１はプッシュサーバ５００−１が情報処理端末３００−１のメッセージ記録処理を行う予定のプッシュサーバ５００であるのか否かを判断する。同様に他の処理期限変更部５０１（例えば処理期限変更部５０１−２）はプッシュサーバ５００−２が情報処理端末３００−１のメッセージ記録処理を行う予定のプッシュサーバ５００であるのか否かを判断する。
【０１１４】
また、情報処理端末３００−１宛てのメッセージ記録処理を行うプッシュサーバ５００がステップＳ１５にてメッセージ取得要求を受信したプッシュサーバ５００−ｎ自身である場合もあり得る。そのため、プッシュサーバ５００−ｎの処理期限変更部５０１−ｎは、プッシュサーバ５００−ｎが情報処理端末３００−１のメッセージ記録処理を行う予定であるか否かを確認する。
【０１１５】
この例では、今回情報処理端末３００−１のメッセージ記録処理を行う予定であるのはプッシュサーバ５００−１である。そのため、処理期限変更要求を受信したプッシュサーバ５００−１の処理期限変更部５０１−１は、処理期限変更要求に含まれるメッセージの宛先となる情報処理端末３００−１の識別子に基づいて、プッシュサーバ５００−１が情報処理端末３００−１のメッセージ記録処理を行う予定であると判断し、メッセージ記録処理の処理期限を変更する（ステップＳ３２）。一方で、他の処理期限変更部５０１（処理期限変更部５０１−２〜処理期限変更部５０１−ｎ―１）は自身が含まれるプッシュサーバ５００がメッセージ記録処理を行う予定ではないと判断し、特にそれ以上の処理を行わない。同様に、処理期限変更要求の送信元である処理期限変更部５０１−１もプッシュサーバ５００−１がメッセージ記録処理を行う予定ではないと判断し、特にそれ以上の処理を行わない。
【０１１６】
ここで、処理期限変更部５０１−１によりメッセージ記録処理の処理期限が変更され、処理期限終了時刻が現在時刻とされる。この変更により、メッセージ記録処理の処理期限終了時刻までの残り時間がゼロになる。そのため、情報処理端末３００−１宛てのメッセージ記録処理の優先度が最大値である１０に設定される。これにより、処理優先度決定部１０６とメッセージ記録処理部１０３は、最優先で情報処理端末３００−１宛てのメッセージ記録処理を実施する（ステップＳ３３）。
【０１１７】
メッセージの記録処理が完了したプッシュサーバ５００−１の処理期限変更部５０１−１は、メッセージの記録処理が完了したことをプッシュサーバ５００−ｎの処理期限変更部５０１−ｎに対して通知する（ステップＳ３４）。
【０１１８】
この時、通知先となる処理期限変更部５０１−ｎは、処理期限変更要求に含まれる変更要求を送信したプッシュサーバ５００−ｎの識別子を基に決定される。処理期限変更部５０１−ｎはメッセージ記録処理が完了した旨を表す情報を、プッシュサーバ５００−ｎに含まれるメッセージ参照部１０８に通知する。通知を受けたメッセージ参照部１０８は、再度、メッセージデータベース２００を参照し、情報処理端末３００−１宛てのメッセージを取得する（ステップＳ３５）。
【０１１９】
メッセージ送信部１０９が、ステップＳ３５で取得したメッセージを、情報処理端末３００に送信する（ステップＳ１７）。以降の処理は実施形態１と同一であるため、詳細な説明を省略する。
【０１２０】
以上のように、実施形態２では、実施形態１と同様に、トリガパケットの送信処理がメッセージ記録処理に先んじて実施されるため、情報処理端末３００にメッセージが到達するまでの遅延が小さくなる。
【０１２１】
また仮に、ＲＲＣ状態の推定結果が間違っており、メッセージ記録処理が実施される前に、プッシュサーバ５００が情報処理端末３００からメッセージ取得要求を受信した場合であっても、メッセージ記録処理の処理期限終了時刻を変更し、そのメッセージ取得要求を送信した情報処理端末宛てのメッセージの記録処理を最優先で実施する。そのため、メッセージの送信先となる情報処理端末３００のＲＲＣ状態が変化した場合であったとしてもプッシュサーバ５００が情報処理端末３００に対してメッセージを送信可能になるまでの時間が最小限に抑えられる、という効果を奏する。実施形態２は取得したＲＲＣ状態にある程度の不確定性が含まれる場合（例えば、休止状態にあった情報処理端末が通信可能状態に変わる場合）に特に好適である。
【０１２２】
［実施形態３］
続いて、実施形態１を一部変形した実施形態である実施形態３について説明する。
【０１２３】
実施形態２では、ＲＲＣ状態の推定に不確定性があり、設定したメッセージの記録処理期限終了時刻前に、プッシュサーバが情報処理端末からメッセージ取得要求を受信した場合について述べた。すなわち、実施形態２の説明の冒頭で述べた第１の問題点を解決する場合について述べた。一方で、実施形態３では、実施形態２の説明の冒頭で述べた第２の問題点を解決することを課題とする。つまり実施形態３では、設定したメッセージの記録処理期限終了時刻を経過したにも関わらず、プッシュサーバが情報処理端末からのメッセージ取得要求を受信しなかった場合について述べる。
【０１２４】
このような事象は、情報処理端末のＲＲＣ状態を通信可能状態であるとしてメッセージ記録処理期限を設定したが、実際は情報処理端末のＲＲＣ状態が休止状態時であった場合に発生する。この場合、実際は情報処理端末からのメッセージ取得要求をプッシュサーバが受信するまでに時間的余裕があるにも関わらず、メッセージ記録処理の処理期限終了時刻が過ぎているため、不必要に高い優先度がメッセージ記録処理に割り当てられることになる。これにより、時間的余裕があるにも関わらず不必要に優先してメッセージ記録処理が実行され、他のメッセージ記録処理の実行が後回しとなってしまう。実施形態３ではこのような問題を解決する。
【０１２５】
図１１に示す実施形態３における構成は、実施形態２における構成と同様であるが、処理期限変更部５０１が、処理期限変更部５０１Ｂに変更されている。
【０１２６】
実施形態３は、プッシュサーバ５００の処理期限変更部５０１Ｂの行う処理期限変更法が、実施形態２のプッシュサーバ５００の処理期限変更部５０１の行う処理期限変更法とは異なる。そのため、以下の説明においてはもっぱら処理期限変更部５０１Ｂの行う処理期限変更法について説明する。
【０１２７】
図１２は、実施形態３におけるプッシュサーバ５００の処理期限変更部５０１Ｂの処理の流れを示すフローチャートである。
【０１２８】
プッシュサーバ５００の処理期限変更部５０１Ｂは、処理の完了していないメッセージ記録処理の処理期限を確認する。併せて、処理の完了していないメッセージ記録処理に対応するメッセージについてメッセージ取得要求を受信しているか否かを確認する（ステップＳ４１）。
【０１２９】
そして、現在時刻が処理期限終了時刻を経過しているメッセージ記録処理であって、且つ、このメッセージ記録処理に対応するメッセージについてメッセージ取得要求を受信していない、という２つの条件を満たしたメッセージ記録処理が存在するのかを確認する（ステップＳ４２）。
【０１３０】
この２つの条件について説明する。上述したように、メッセージの処理期限終了時刻を経過した場合には優先度は最高値である１０に設定される。そのため、このメッセージは最優先に処理の対象となる。しかしながら、例えばプッシュサーバ５００にメッセージが非常に多く集中しており、負荷がかかっているような場合には、複数の優先度１０のメッセージの処理が滞留するような場合もあり得る。そして、このように優先度１０のメッセージが滞留することにより、優先度９以下のメッセージについても処理が行われないことになる。そこで、このような負荷がかかっている場合には、優先度１０のメッセージの内、早期に処理する必要がないメッセージについてはメッセージ記録処理の処理期限を後に処理するように変更することが望ましい。こうすることにより、他の優先度１０のメッセージ及び優先度９以下のメッセージについて早期に処理が行われるからである。
【０１３１】
このためには、情報処理端末のＲＲＣ状態を通信可能状態であるとしてメッセージ記録処理期限を設定したが、実際は情報処理端末のＲＲＣ状態が休止状態時であったメッセージの、メッセージ記録処理を後回しにすることが好ましい。
【０１３２】
そこで、メッセージ取得要求を受信していないことも条件とする。メッセージ取得要求が受信されていないということは、情報処理端末のＲＲＣ状態が休止状態であると推認される。一方で、メッセージ取得要求が受信されている場合は情報処理端末のＲＲＣ状態が通信可能状態であると推認される。そのため、ステップＳ４２では、メッセージ取得要求が受信されていないことと、現在時刻が処理期限終了時刻を経過していることの２つを条件とする。
【０１３３】
ステップＳ４２の２つの条件を満たしているメッセージ記録処理が１つでも存在する場合は（ステップＳ４２においてＹｅｓ）、処理期限変更部５０１は、この２つの条件を満たしているメッセージ記録処理全てについて処理期限を変更する（ステップＳ４３）。
【０１３４】
ここで、処理期限終了時刻は、上述したように「トリガパケット送信時刻」に「情報処理端末３００がＲＲＣ状態に応じた処理期限」を加算することにより設定されているものであるが、このＲＲＣ状態に応じた処理期限を休止状態の処理期限に設定し直す。
【０１３５】
すなわち、本動作例では、処理期限決定部１０５Ｂは、情報処理端末のＲＲＣ状態が通信可能状態であるとした場合には、「処理期限終了時刻＝トリガパケットの送信時刻＋１００ミリ秒」に設定するが、処理期限変更部５０１Ｂは、ステップＳ４３で、これを新たに「処理期限終了時刻＝トリガパケットの送信時刻＋３秒」に変更する。その後、ステップＳ４４へ進む。なお、本動作例ではＲＲＣ状態に応じた処理期限を休止状態の値に設定し直す場合について説明しているが、これを他の値としても良い。例えば、通信可能状態の値を超え、且つ、休止状態の値未満の他の値に設定し直すようにしても良い。例えば「処理期限終了時刻＝トリガパケットの送信時刻＋２秒」というように変更しても良い。
【０１３６】
一方で、ステップＳ４２で、現在時刻が処理期限終了時刻を過ぎているメッセージ記録処理が存在しない場合は（ステップＳ４２においてＮｏ）、ステップＳ４３の処理は実行されず、直接ステップＳ４４に遷移する。
【０１３７】
そして、ステップＳ４４では一定時間処理を止める。処理を止める時間は予め設定されているものとし、例えば、１０ミリ秒とする。その後、ステップＳ４１に戻り、再度同様の処理を繰り返す。
【０１３８】
なお、処理を止める理由であるが、一定時間が経過しない状態で高速に連続してステップＳ４１及びステップＳ４２の判定を行ったとしても、「処理期限終了時刻が現在時刻を過ぎているにも関わらず、処理の完了していないメッセージ記録処理」が新たに存在する可能性は低く、処理が煩雑となるだけだからである。そのため、ステップＳ４４にて一定時間待機し、これにより「処理期限終了時刻が現在時刻を過ぎているにも関わらず、処理の完了していないメッセージ記録処理」が新たに存在する可能性がある程度高くなってから再度ステップＳ４１及びステップＳ４２の判定を行う。これは、言い換えれば一定時間の周期で定期的にステップＳ４１〜ステップＳ４４を繰り返すということである。
【０１３９】
実施形態３におけるメッセージ送信処理は実施形態２と同様であるため、説明を省略する。
【０１４０】
以上のように、実施形態３では、情報処理端末３００のＲＲＣ状態に不確定性がある場合に、メッセージの記録処理に不必要に高い優先度が設定されることを抑止する。これにより、他に処理すべきトリガパケットの送信処理やメッセージの記録処理の実行時刻を早めることができるため、情報処理端末３００にメッセージが到達するまでの遅延が低減する、という効果を奏する。実施形態３は取得したＲＲＣ状態にある程度の不確定性が含まれる場合であって、休止状態時にある情報処理端末を誤って通信可能状態にあると判断してしまった場合に特に好適である。
【０１４１】
また、上述した各実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【０１４２】
例えば、上述した実施形態３のステップＳ４２では、メッセージ取得要求が既に到着しており、速やかに実行すべきであるメッセージ記録処理の処理期限を延長してしまうことの無いように、ステップＳ４２において判断対象としているメッセージの処理期限終了時刻が終了していることに加えて、判断対象としているメッセージのメッセージ取得要求が到着していることも条件として考慮していた。
【０１４３】
もっとも、実施形態２と実施形態３を組み合わせることにより、ステップＳ４２におけるメッセージ取得要求が到着有無の確認を省略することもできる。
【０１４４】
具体的には、実施形態２と実施形態３を組み合わせ、実施形態２の処理を行いながら、図１２に表される実施形態３特有の処理も行うことによって、メッセージ取得要求が既に到着しており、速やかに実行すべきであるメッセージ記録処理の処理期限を延長してしまうような事態を以下に示す理由により防止することができる。
【０１４５】
実施形態２と実施形態３を組み合わせた場合には、休止状態だと判断していたにも関わらず実際には通信可能状態であったメッセージは、実施形態２の処理の対象となり、これにより迅速にメッセージ記録処理を終了することができる。
【０１４６】
一方で、実施形態２の処理対象とならなかったメッセージ及びメッセージ取得要求がなされる前にメッセージ記録処理が終了しているメッセージの２種類のメッセージ以外のメッセージについては、通信可能状態だと判断していたのにも関わらず実際には休止状態であると考えられる。そして、このようなメッセージについては実施形態３の処理により、処理期限が休止状態の処理期限に再設定される。つまり、実施形態２及び実施形態３を組み合わせることにより、休止状態だと判断していたのにも関わらず実際には通信可能状態であった場合と、通信可能状態だと判断していたのにも関わらず実際には休止状態である場合の双方に対応することが可能となる。
【０１４７】
なお、上記のプッシュサーバ、メッセージデータベース、情報処理端末及びアプリサーバのそれぞれは、ハードウェア、ソフトウェア又はこれらの組合わせによりそれぞれ実現することができる。また、上記のプッシュサーバ、メッセージデータベース、情報処理端末及びアプリサーバの協働により行なわれるメッセージ送信方法も、ハードウェア、ソフトウェア又はこれらの組合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
【０１４８】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory）)を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１４９】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１５０】
（付記１）  端末へのメッセージ送信に関する処理を行うメッセージ送信装置であって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、
前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、
を備えることを特徴とするメッセージ送信装置。
【０１５１】
（付記２）  付記１に記載のメッセージ送信装置であって、
前記端末が通信可能状態であるか又は休止状態であるのかに基づいて、通信可能状態にある端末についての前記準備処理が休止状態にある端末についての前記準備処理よりも優先して行われるように実行順序を決定することを特徴とするメッセージ送信装置。
【０１５２】
（付記３）  付記１又は２に記載のメッセージ送信装置であって、
前記通知処理が少なくとも一部の準備処理よりも優先して行われるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【０１５３】
（付記４）  付記１乃至３の何れか１に記載のメッセージ送信装置であって、
前記端末が通信可能状態であるか又は休止状態であるのかに基づいて、通信可能状態にある端末についての前記準備処理には第１の長さの処理期限を設定し、休止状態にある端末についての前記準備処理には前記第１の長さよりも長い第２の長さの処理期限を設定し、前記処理期限の終了時刻までの時間が短い準備処理ほど優先して実行されるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【０１５４】
（付記５）  付記４に記載のメッセージ送信装置であって、
前記処理期限の終了時刻に近づくに伴い高くなっていく優先度を前記準備処理に設定し、前記通知処理には変化しない一定の高さの優先度を設定し、前記準備処理及び通知処理の中から優先度の高いものほど優先して実行されるように前記実行順序を決定することを特徴とするメッセージ送信装置。
【０１５５】
（付記６）  付記４又は５に記載のメッセージ送信装置であって、
或るメッセージに関しての前記準備処理の処理期限の終了時刻が経過したにも関わらず、該準備処理が未だ実行されておらず、更に、前記端末から該或るメッセージに関して前記メッセージ取得要求を受信していない場合には該準備処理の処理期限をより長い処理期限へと変更することを特徴とするメッセージ送信装置。
【０１５６】
（付記７）  付記１乃至６の何れか１に記載のメッセージ送信装置であって、
前記端末から或るメッセージに関して前記メッセージ取得要求を受信したにも関わらず、該或るメッセージに関しての準備処理が未だ実行されていない場合には、前記決定した実行順序にとらわれることなく該或るメッセージに関しての準備処理を優先して実行することを特徴とするメッセージ送信装置。
【０１５７】
（付記８）  端末へのメッセージ送信に関する処理を行うメッセージ送信方法であって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知ステップと、
前記メッセージを前記端末に送信するための準備処理を実行する準備ステップと、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定ステップと、
を備えることを特徴とするメッセージ送信方法。
【０１５８】
（付記９）  端末へのメッセージ送信に関する処理を行うメッセージ送信装置としてコンピュータを機能させるメッセージ送信プログラムであって、
未送信の前記メッセージが存在する旨を示すトリガパケットを前記端末に送信するための通知処理を実行する通知手段と、
前記メッセージを前記端末に送信するための準備処理を実行する準備手段と、
前記トリガパケットに対しての応答であるメッセージ取得要求を前記端末から受信する前に、前記準備処理が終了しているように前記通知処理及び前記準備処理の実行順序を決定する順序決定手段と、
を備えるメッセージ送信装置として前記コンピュータを機能させることを特徴とするメッセージ送信プログラム。
【０１５９】
（付記１０）  情報処理端末に対してメッセージの送信をプッシュ型で行うサーバであって、
メッセージ送信対象の情報処理端末のＲＲＣ（Radio Resource Control）状態を取得するＲＲＣ状態取得部と、
前記情報処理端末に対して送信するメッセージを記録装置に記録させる処理を行うメッセージ記録処理部と、
前記情報処理端末に対する未送信のメッセージがサーバに存在することを前記情報処理端末に伝えるトリガパケットを送信するトリガ送信部と、
前記ＲＲＣ状態取得部により取得した前記情報処理端末のＲＲＣ状態に基づき、前記メッセージ記録処理部が行う前記情報処理端末宛てのメッセージを記録する処理の処理期限を決定する処理期限決定部と、
前記処理期限に基づき、前記メッセージ記録処理部が行うメッセージの記録処理と前記トリガ送信部が行うトリガ送信処理の優先度を決定する処理優先度決定部と、
前記処理優先度決定部の決定した処理優先度に基づき前記メッセージ記録部が行うメッセージの記録処理と前記トリガ送信部が行うトリガ送信処理の処理順序を決定する処理スケジューリング部と、
トリガパケットを受信した前記情報処理端末が送信するメッセージ取得要求を受信して、メッセージ取得要求の応答として前記情報処理端末宛てのメッセージを送信するメッセージ送信部とを
備えたことを特徴とするサーバ。
【０１６０】
（付記１１）  処理優先度決定部は、前記処理期限決定部の決定する処理期限までの残り時刻が大きいほど前記メッセージ記録処理部の行うメッセージの記録処理の優先度を小さく設定する付記１０に記載のサーバ。
【０１６１】
（付記１２）  付記１０又は１１に記載のサーバであって、
前記メッセージ送信部が、前記情報処理端末からメッセージ取得要求を受信した時点で、前記メッセージ記録処理部が行う前記情報処理端末宛てのメッセージの記録処理が完了していない場合に、前記情報処理端末宛てのメッセージの記録処理の処理期限を変更する処理期限変更部を、
さらに備えることを特徴とした付記１０又は１１に記載のサーバ。
【０１６２】
（付記１３）  付記１０又は１１に記載のサーバであって、
前記処理期限決定部が決定したメッセージ記録処理の処理期限が過ぎ、前記メッセージ送信部が、前記情報処理端末からメッセージ取得要求を受信していない場合に、メッセージ記録処理の処理期限を変更する処理期限変更部を、
さらに備えることを特徴とした付記１０又は１１に記載のサーバ。
【０１６３】
（付記１４）  情報処理端末に対してメッセージの送信をプッシュ型で行うメッセージ送信方法であって、
メッセージ送信対象の情報処理端末のＲＲＣ状態を取得するＲＲＣ状態取得ステップと、
前記情報処理端末に対して送信するメッセージを記録装置に記録させる処理を行うメッセージ記録処理ステップと、
前記情報処理端末に対する未送信のメッセージがサーバに存在することを前記情報処理端末に伝えるトリガパケットを送信するトリガ送信ステップと、
前記ＲＲＣ状態取得ステップで取得した前記情報処理端末のＲＲＣ状態に基づき、前記メッセージ記録処理ステップで行う前記情報処理端末宛てのメッセージを記録する処理の処理期限を決定する処理期限決定ステップと、
前記処理期限に基づき、前記メッセージ記録処理ステップで行うメッセージの記録処理と前記トリガ送信ステップが行うトリガ送信処理の優先度を決定する処理優先度決定ステップと、
前記処理優先度決定ステップで決定した処理優先度に基づき前記メッセージ記録ステップで行うメッセージ記録処理と前記トリガ送信ステップで行うトリガ送信処理の処理順序を決定する処理スケジューリングステップと、
トリガパケットを受信した前記情報処理端末が送信するメッセージ取得要求を受信して、メッセージ取得要求の応答として前記情報処理端末宛てのメッセージを送信するメッセージ送信ステップとを
備えたことを特徴とするメッセージ送信方法。
【０１６４】
（付記１５）  処理優先度決定ステップは、前記処理期限決定ステップで決定した処理期限までの残り時刻が大きいほど前記メッセージ記録処理ステップで行うメッセージの記録処理の優先度を小さく設定する付記１４に記載のメッセージ送信方法。
【０１６５】
（付記１６）  付記１４又は１５に記載のメッセージ送信方法であって、
前記メッセージ送信ステップで、前記情報処理端末からメッセージ取得要求を受信した時点で、前記メッセージ記録処理ステップで行う前記情報処理端末宛てのメッセージの記録処理が完了していない場合に、前記情報処理端末宛てのメッセージの記録処理の処理期限を変更する処理期限変更ステップを、
さらに備えることを特徴とした付記１４又は１５に記載のメッセージ送信方法。
【０１６６】
（付記１７）  付記１４又は１５に記載のメッセージ送信方法であって、
前記処理期限決定ステップで決定したメッセージ記録処理の処理期限が過ぎ、前記情報処理端末からメッセージ取得要求を受信していない場合に、メッセージ記録処理の処理期限を変更する処理期限変更ステップを、
さらに備えることを特徴とした付記１４又は１５に記載のメッセージ送信方法。
【０１６７】
（付記１８）  情報処理端末に対してメッセージの送信をプッシュ型で行うコンピュータに、
メッセージ送信対象の情報処理端末のＲＲＣ状態を取得するＲＲＣ状態取得処理と、
前記情報処理端末に対して送信するメッセージを記録装置に記録させる処理を行うメッセージ記録処理と、
前記情報処理端末に対する未送信のメッセージがサーバに存在することを前記情報処理端末に伝えるトリガパケットを送信するトリガ送信処理と、
前記ＲＲＣ状態取得処理で取得した前記情報処理端末のＲＲＣ状態に基づき、前記メッセージ記録処理で行う前記情報処理端末宛てのメッセージを記録する処理の処理期限を決定する処理期限決定処理と、
前記処理期限に基づき、前記メッセージ記録処理で行うメッセージの記録処理と前記トリガ送信処理で行うトリガ送信処理の優先度を決定する処理優先度決定処理と、
前記処理優先度決定処理で決定した処理優先度に基づき前記メッセージ記録処理と前記トリガ送信処理の処理順序を決定する処理スケジューリング処理と、
トリガパケットを受信した前記情報処理端末が送信するメッセージ取得要求を受信して、メッセージ取得要求の応答として前記情報処理端末宛てのメッセージを送信するメッセージ送信処理とを
実行させるプログラム。
【０１６８】
（付記１９）  処理優先度決定処理は、前記処理期限決定処理で決定した処理期限までの残り時刻が大きいほど前記メッセージ記録処理の優先度を小さく設定する付記１８に記載のプログラム。
【０１６９】
（付記２０）  付記１８又は１９に記載のプログラムであって、
前記メッセージ送信処理において、前記情報処理端末からメッセージ取得要求を受信した時点で、前記情報処理端末宛ての前記メッセージ記録処理が完了していない場合に、前記情報処理端末宛てのメッセージの記録処理の処理期限を変更する処理期限変更処理を、
さらに実行させる付記１８又は１９に記載のプログラム。
【０１７０】
（付記２１）  付記１８又は１９に記載のプログラムであって、
前記処理期限決定処理で決定した前記メッセージ記録処理の処理期限が過ぎ、前記メッセージ送信処理において前記情報処理端末からメッセージ取得要求を受信していない場合に、メッセージ記録処理の処理期限を変更する処理期限変更処理を、
さらに実行させる付記１８又は１９に記載のプログラム。
【０１７１】
この出願は、２０１３年２月７日に出願された日本出願特願２０１３−０２２３８９を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１７２】
本願発明は、プッシュメッセージの配信における遅延防止に好適である。
【符号の説明】
【０１７３】
１００、１００−１〜１００−ｎ、５００、５００−１〜５００−ｎ、１１００  プッシュサーバ
１０１  メッセージ送信要求受信部
１０２  ＲＲＣ状態取得部
１０３  メッセージ記録処理部
１０４  トリガパケット送信部
１０５  処理期限決定部
１０６  処理優先度決定部
１０７  処理スケジューリング部
１０８  メッセージ参照部
１０９  メッセージ送信部
２００、１２００  メッセージデータベース
３００、３００−１〜３００−ｍ  情報処理端末
３１０、１００２  プッシュクライアント
３１１  トリガパケット受信部
３１２  メッセージ受信部
３１３  メッセージ通知部
３２０−１〜３２０−ｋ、１００１  アプリ
４００、４００−１〜４００−ｊ、１３００  アプリサーバ
５０１、５０１Ｂ  処理期限変更部
【図１】
2014122981.tif 000003
【図２】
2014122981.tif 000004
【図３】
2014122981.tif 000005
【図４−１】
2014122981.tif 000006
【図４−２】
2014122981.tif 000007
【図５】
2014122981.tif 000008
【図６】
2014122981.tif 000009
【図７】
2014122981.tif 000010
【図８】
2014122981.tif 000011
【図９】
2014122981.tif 000012
【図１０】
2014122981.tif 000013
【図１１】
2014122981.tif 000014
【図１２】
2014122981.tif 000015
【国際調査報告】
2014122981.tif 000016
2014122981.tif 000017