特許 6241418 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6241418

(24)【登録日】2017年11月17日

(45)【発行日】2017年12月6日

(54)【発明の名称】端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20171127BHJP

   H04W 4/12 20090101ALI20171127BHJP

   H04W 48/18 20090101ALI20171127BHJP

   H04M 1/00 20060101ALI20171127BHJP

   H04M 11/00 20060101ALI20171127BHJP

【ＦＩ】

   H04L12/70 A

   H04W4/12

   H04W48/18 113

   H04M1/00 R

   H04M11/00 302

【請求項の数】8

【全頁数】21

(21)【出願番号】特願2014-541923(P2014-541923)

(86)(22)【出願日】2013年10月2日

(86)【国際出願番号】JP2013005876

(87)【国際公開番号】WO2014061220

(87)【国際公開日】20140424

【審査請求日】2016年9月15日

(31)【優先権主張番号】特願2012-230001(P2012-230001)

(32)【優先日】2012年10月17日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】大西 健夫

(72)【発明者】

【氏名】城島 貴弘

(72)【発明者】

【氏名】川戸 正裕

(72)【発明者】

【氏名】多 忠行

【審査官】 上田 翔太

(56)【参考文献】

【文献】 特開２００８−０８５４７０（ＪＰ，Ａ）

【文献】 特開２０１２−１０９６４１（ＪＰ，Ａ）

【文献】 特開２００３−０３２７５０（ＪＰ，Ａ）

【文献】 Hiroyuki，富士通BSC社さんのMDMソリューションFENCE-Mobile RemoteManagerを評価してみました。，Curl Global Community，２０１２年 ６月１９日，ＵＲＬ，http://communities.curl.com/showthread.php?tid=537

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

Ｈ０４Ｍ １／００

Ｈ０４Ｍ １１／００

Ｈ０４Ｗ ４／１２

Ｈ０４Ｗ ４８／１８

(57)【特許請求の範囲】

【請求項1】

自端末と、メッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、
前記検知結果をもとに、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置によって自端末との間に新規に確立されたＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて前記配信装置からメッセージを受信する受信部とを備え、
前記受信部は、前記自端末と前記配信装置とを接続するネットワークが無線ＬＡＮである場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する、
端末。

【請求項2】

前記受信部は、第一の通信方式を選択した場合は、前記配信装置に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、前記配信装置とのＴＣＰ接続を検知したときに当該配信装置にメッセージ取得要求を送信する
請求項１に記載の端末。

【請求項3】

前記受信部は、第二の通信方式を選択したときに前記自端末のＩＰアドレスを含む端末状態情報を配信装置に通知する
請求項１または請求項２のいずれかに記載の端末。

【請求項4】

前記受信部は、配信すべきメッセージがあることを示すＳＭＳによる通知を検知したときに前記配信装置にメッセージ取得要求を送信する
請求項１から請求項３のうちのいずれか１項に記載の端末。

【請求項5】

前記受信部は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を前記配信装置に通知しない
請求項３または請求項４に記載の端末。

【請求項6】

端末と、前記端末にメッセージの配信をプッシュ型で行う配信装置とを備え、
前記端末は、
自端末と前記配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、
前記検知結果をもとに、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置によって前記自端末との間に新規に確立されるＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて前記配信装置からメッセージを受信する受信部とを備え、
前記配信装置は、前記端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部を備え、
前記受信部は、前記自端末と前記配信装置とを接続するネットワークが無線ＬＡＮである場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する
メッセージ配信システム。

【請求項7】

端末が、自端末とメッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知し、前記検知結果をもとに、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置によって前記自端末との間に新規に確立されるＴＣＰセッションを利用する第二の通信方式を選択し、
前記配信装置が、前記端末から通知された通信方式の選択結果に応じたメッセージ配信を行うことを備え、
前記端末が、前記自端末と前記配信装置とを接続するネットワークが無線ＬＡＮである場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、前記自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する
メッセージ配信方法。

【請求項8】

メッセージの配信をプッシュ型で行う配信装置と通信可能な端末に搭載されるコンピュータに、
前記端末と前記配信装置とを接続するネットワークの状態を検知する処理と、
前記検知結果をもとに、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置によって前記自端末との間に新規に確立されるＴＣＰセッションを利用する第二の通信方式を選択する処理と、
選択した通信方式に応じて前記配信装置からメッセージを受信する処理と実行させ、更に、前記コンピュータに、
前記端末と前記配信装置とを接続するネットワークが無線ＬＡＮである場合は、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する処理を実行させる
メッセージ受信プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、イベント通知サービスをユーザに提供するための端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラムに関する。

【背景技術】

【0002】

ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の着信通知やＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）の更新通知など、サーバ装置から端末に対してＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを通して能動的にイベントを通知するイベント通知サービスがある。イベント通知サービスにおいてサーバ装置が端末に対してプッシュ型で行う通知は、プッシュ通知（Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ）またはプッシュメッセージと呼ばれる。プッシュメッセージを送信するサーバ装置（以下、プッシュサーバという。）は、ＶｏＩＰの着信通知、ＳＮＳの更新通知、チャットメッセージ配信、クラウドストレージの更新通知などの通知要求をサービス事業者サーバ（以下、アプリケーションサーバという。）から受け取る。アプリケーションサーバは、ＳＮＳ管理者等のサービス事業者が使用するサーバ装置である。

【0003】

サービス事業者は、アプリケーションサーバを使用して、自身が提供するアプリケーション宛てのメッセージ配信をプッシュサーバに要求する。サービス事業者は、予め、サービスを利用するためのアプリケーションをユーザに提供する。そして、ユーザは、サービス事業者から提供されたアプリケーションを端末上で動作させる。

【0004】

プッシュサーバは、メッセージ配信要求に従って端末上で動作するソフトウェア（以下、プッシュクライアントという。）に対してプッシュメッセージを送信する。プッシュクライアントは、受信したメッセージを宛先のアプリケーションに渡す。アプリケーションは、プッシュクライアントから受け取ったメッセージの内容に応じた処理を行う。

【0005】

イベント通知サービスでは、プッシュサーバが、端末とアプリケーションとの組み合わせごとに、ＩＤを発行する。例えば、プッシュサーバは、端末ＸのアプリケーションＡに対してはＩＤ「ｘｘｘＡ」、端末ＸのアプリケーションＢに対してはＩＤ「ｘｘｘＢ」、端末ＹのアプリケーションＣに対してはＩＤ「ｙｙｙＣ」を発行する。プッシュサーバ、プッシュクライアント、アプリケーションサーバは、各ＩＤを共有する。

【0006】

図１１は、イベント通知サービスの概要を示す説明図である。アプリケーションサーバはメッセージ配信要求をするとき、メッセージ配信要求とともに、メッセージの配信先の端末とアプリケーションとの組み合わせを示すＩＤをプッシュサーバに渡す。図１１は、サービス事業者Ａのアプリケーションサーバ７００−１が、端末ＸのアプリケーションＡ宛てのメッセージ配信要求とともにＩＤ「ｘｘｘＡ」をプッシュサーバ６００に渡した場合の例である。ここで、端末５００−１、端末５００−２がそれぞれ端末Ｘ、端末Ｙに相当するとする。また、端末Ｘに、サービス事業者Ａが提供するアプリケーション（以下、アプリケーションＡという。）とサービス事業者Ｂが提供するアプリケーション（以下、アプリケーションＢという。）とが格納されているとする。また、端末Ｙに、サービス事業者Ｃが提供するアプリケーション（以下、アプリケーションＣという。）が格納されているとする。

【0007】

プッシュサーバ６００は、ＩＤ「ｘｘｘＡ」にもとづいて、メッセージ配信先の端末Ｘにメッセージを送信する。端末Ｘのプッシュクライアント５１０−１は、ＩＤ「ｘｘｘＡ」にもとづいて、受信したメッセージをメッセージ配信先のアプリケーション、つまりアプリケーションＡに送信する。

【0008】

アプリケーションＡは、受信したメッセージに応じた処理を行う。例えば、アプリケーションＡは、ユーザに情報を通知したり、コンテンツサーバと通信してコンテンツサーバから更新されたコンテンツを取得したりする。

【0009】

特許文献１には、ネットワーク環境やプッシュサーバのリソースの状況に応じて、端末からプッシュサーバへのコネクションを維持し続けるコネクション型の配信方法、または、定期的に端末からプッシュサーバに対してポーリングを行うポーリング型の配信方法を選択する方法が記載されている（例えば、特許文献１参照。）。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】特開２０１１−１２３８０１号公報

【発明の概要】

【発明が解決しようとする課題】

【0011】

端末は、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）回線やＷｉＦｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）（登録商標）など様々なネットワークを利用する。端末が利用するネットワークによっては、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）やＦＷ（ファイヤフォール）などにより、プッシュサーバ・端末間の接続方法が制限されることがある。そのような状況では、プッシュメッセージを端末に確実に到達させることができない場合がある。

【0012】

例えば、端末がプッシュサーバのＮＡＴ配下となる場合、つまり、プッシュサーバ・端末間にＮＡＴ機能を備えたルータ等が設置される場合がある。その場合、プッシュサーバと端末とのＩＰアドレス空間が異なるため、プッシュサーバから端末に直接ＩＰパケットを送信することができない。従って、予め端末側からプッシュサーバに対しＴＣＰセッションの確立を実施しておき、プッシュサーバは確立済みのＴＣＰセッションを利用してプッシュメッセージを端末に送信する。

【0013】

ＮＡＴ機能を備えたルータは、ＩＰ変換テーブルを用いて端末のグローバルアドレスとプライベートアドレスとを変換する。ＩＰ変換テーブルは、グローバルアドレスとプライベートアドレスとの対応を示す情報を、ＴＣＰセッションごとに記憶する。ＮＡＴでは、一定時間通信のないＴＣＰセッションはタイムアウトしたと判断され、ＩＰ変換テーブルから削除される。ＩＰ変換テーブルから削除されたＴＣＰセッションは、通信不能になる。すると、プッシュサーバは、端末にプッシュメッセージを到達させることができなくなる。

【0014】

従って、端末がプッシュサーバのＮＡＴ配下となる環境では、プッシュサーバと端末は、配信すべきプッシュメッセージがない場合であっても、ＴＣＰセッションを維持するために、定期的に通信を行う。例えば、ＫｅｅｐＡｌｉｖｅ信号の送受信を定期的に行う。

【0015】

端末は、３Ｇ回線やＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などのモバイル網を利用するとき、電力を節約するために通信状態に応じて無線状態を切り替える。例えば、端末は、通信状態に応じて、無線状態をスタンバイ状態にしたりアクティブ状態にしたりする。無線状態の切り替えの際、端末は、モバイル網との間で無線状態を切り替えるための制御信号の送受信を行う。端末上で動作するアプリケーションなどが定期的に通信を発生させる場合、端末の無線状態は、スタンバイ状態とアクティブ状態とを交互に繰り返すことになり、モバイル網に多数の制御信号が流れ、モバイル網で輻輳が発生する。また、多数の制御信号が発生することにより、プッシュサーバにおける制御信号に応答するための処理負荷が増大する。従って、ＴＣＰセッションを維持するための定期的な通信は、モバイル網で輻輳を発生させ、プッシュサーバの処理負荷を増大させる。

【0016】

プッシュサーバと端末とが同一ＮＡＴ内に配置されている場合、つまり、プッシュサーバと端末とが同じＩＰアドレス空間上に存在する場合には、プッシュサーバから端末に直接ＩＰパケットを送信することができる。従って、プッシュサーバと端末とを同一ＮＡＴ内に配置すれば、常時ＴＣＰセッションを維持する必要がないので、モバイル網における輻輳を抑制することができる。しかし、スマートフォンなどの端末は、自端末が利用するネットワークを容易に切り替えることができる。従って、プッシュサーバと端末とを常に同一ＮＡＴ内に配置させておくことは難しい。例えば、端末がプッシュサーバと同一ＮＡＴ内に配置されていたとしても、ネットワークをＷｉＦｉに切り替えたときに、端末がＮＡＴ配下になってしまう場合がある。

【0017】

特許文献１に記載された方法は、利用中のネットワークの状況、例えば、通信速度やコネクションの継続可能時間に応じて配信方法を選択する。つまり、特許文献１に記載された方法は、ネットワークの種別に応じた配信方法の選択を行っていない。そのため、特許文献１に記載された方法を用いた場合、モバイル網においてコネクション型の配信方法が選択される可能性があり、モバイル網で輻輳を発生させる可能性がある。

【0018】

そこで、本発明は、プッシュサーバの処理負荷を削減しつつ、ネットワークの種別によらずにプッシュサーバから端末にプッシュメッセージを確実に到達させることができる端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラムを提供することを目的とする。

【課題を解決するための手段】

【0019】

本発明による端末は、自端末と、メッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部とを備えたことを特徴とする。

【0020】

本発明によるメッセージ配信システムは、端末と、端末にメッセージの配信をプッシュ型で行う配信装置とを備え、端末は、自端末と配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部とを備え、配信装置は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部を備えたことを特徴とする。

【0021】

本発明によるメッセージ配信方法は、端末が、自端末とメッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知し、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、配信装置が、端末から通知された通信方式の選択結果に応じたメッセージ配信を行うことを特徴とする。

【0022】

本発明によるメッセージ受信プログラムは、メッセージの配信をプッシュ型で行う配信装置と通信可能な端末に搭載されるコンピュータに、端末と配信装置とを接続するネットワークの状態を検知する処理と、検知結果をもとに、端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択する処理と、選択した通信方式に応じて配信装置からメッセージを受信する処理とを実行させることを特徴とする。

【発明の効果】

【0023】

本発明によれば、プッシュサーバの処理負荷を削減しつつ、ネットワークの種別によらずにプッシュサーバから端末にプッシュメッセージを確実に到達させることができる。

【図面の簡単な説明】

【0024】

【図1】本発明によるメッセージ配信システムの第１の実施形態の構成を示すブロック図である。

【図2】端末の第１の実施形態の構成を示すブロック図である。

【図3】端末がプッシュ方法としてロングポーリングを選択した場合の動作を示すシーケンス図である。

【図4】端末がプッシュ方法としてダイレクトＩＰを選択した場合の動作を示すシーケンス図である。

【図5】ロングポーリングによるプッシュメッセージの配信処理を示すシーケンス図である。

【図6】ダイレクトＩＰによるプッシュメッセージの配信処理を示すシーケンス図である。

【図7】ＳＭＳによるプッシュメッセージの配信処理を示すシーケンス図である。

【図8】端末がプッシュ方法としてダイレクトＩＰを選択した場合の第３の実施形態の動作を示すシーケンス図である。

【図9】本発明による端末の最小構成を示すブロック図である。

【図10】本発明によるメッセージ配信システムの最小構成を示すブロック図である。

【図11】イベント通知サービスの概要を示す説明図である。

【発明を実施するための形態】

【0025】

実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。

【0026】

図１は、本発明によるメッセージ配信システムの第１の実施形態の構成を示すブロック図である。

【0027】

通信システムは、図１に示すように、端末１００−１〜１００−ｎと、プッシュサーバ２００と、アプリケーションサーバ３００−１〜３００−ｎとを含む。なお、図１には、１つのプッシュサーバ２００が例示されているが、プッシュサーバはいくつあってもよい。

【0028】

端末１００−１〜１００−ｎは、例えば、携帯電話機等の通信端末である。プッシュサーバ２００とアプリケーションサーバ３００−１〜３００−ｎとは、通信可能に接続される。プッシュサーバ２００と端末１００−１〜１００−ｎとは、モバイル網または無線ＬＡＮ、およびインターネットを介して通信可能に接続される。モバイル網は、例えば、３Ｇ回線やＬＴＥである。無線ＬＡＮは、例えばＷｉＦｉである。

【0029】

各端末は、プッシュクライアント１１０と、アプリケーション１２０−１〜１２０−ｎとを含む。

【0030】

図２は、本発明による端末の第１の実施形態の構成を示すブロック図である。

【0031】

図２に示すように端末１００（端末１００−１〜１００−ｎ）のプッシュクライアント１１０は、端末状態通知送信部１１１と、ネットワーク（ＮＷ）状態検知部１１２と、メッセージ更新通知受信部１１３と、メッセージ受信部１１４と、メッセージ通知部１１５とを含む。

【0032】

端末状態通知送信部１１１は、端末状態通知を行う。具体的には、端末状態通知送信部１１１は、端末状態を示す情報（以下、端末状態情報という。）をプッシュサーバ２００に通知する。端末状態情報は、例えば、端末１００のＩＰアドレスを含む情報である。

【0033】

ＮＷ状態検知部１１２は、ネットワーク状態を検知する。具体的には、ＮＷ状態検知部１１２は、ネットワーク状態として、端末１００とプッシュサーバ２００とが接続されているネットワークの種別を検知する。ネットワークの種別は、例えば、無線ＬＡＮや、モバイル網である。

【0034】

メッセージ更新通知受信部１１３は、プッシュサーバ２００から送信されるメッセージ更新通知を受信する。

【0035】

メッセージ受信部１１４は、メッセージ更新通知に対応するメッセージをプッシュサーバ２００から受信する。

【0036】

メッセージ通知部１１５は、プッシュサーバ２００から受信したメッセージをアプリケーション１２０−１〜１２０−ｎに渡す。

【0037】

アプリケーション１２０−１〜１２０−ｎは、端末１００上で動作するアプリケーションプログラムである。アプリケーション１２０−１〜１２０−ｎは、例えばサービス事業者等から提供され、端末が備える記憶部（図示せず）に格納される。

【0038】

なお、プッシュクライアント１１０は、端末１００が備えるＣＰＵ等によって実現される。

【0039】

プッシュサーバ２００は、プッシュメッセージを端末に配信するサーバ装置である。プッシュサーバ２００は、制御部（図示せず）を備える。なお、制御部は、プッシュサーバ２００が備えるＣＰＵ等によって実現される。以降、プッシュサーバ２００の制御部が処理することを、単にプッシュサーバ２００が処理すると表現する。

【0040】

アプリケーションサーバ３００−１〜３００−ｎは、各サービス事業者が使用するサーバ装置である。アプリケーションサーバ３００−１〜３００−ｎは、例えばサービス事業者が入力した操作に応じて、メッセージ配信要求をプッシュサーバ２００に送信する。

【0041】

次に、本実施形態の動作を説明する。

【0042】

まず、端末１００が、プッシュメッセージを取得する方法（以下、プッシュ方法という。）を決定する動作を説明する。

【0043】

本実施形態では、端末はプッシュ方法として第一の通信方式と第二の通信方式とを用いる。第一の通信方式はロングポーリング方式（以下、単にロングポーリングという。）である。第二の通信方式はダイレクトＩＰ方式（以下、単にダイレクトＩＰという。）である。

【0044】

ロングポーリングは、プッシュサーバが、端末からのＨＴＴＰ要求（ＨＴＴＰ ＧＥＴ）に対して、配信すべきプッシュメッセージが発生するまで、応答をブロックする方法である。つまり、プッシュサーバは、配信すべきプッシュメッセージがない場合には、メッセージ配信要求をアプリケーションサーバから受け付けるまで、ＨＴＴＰ要求に対する応答をしない。

【0045】

ロングポーリングは、ＨＴＴＰを利用するため、端末がＮＡＴ配下となるＷｉＦｉなどの無線ＬＡＮに接続している場合においても、プッシュメッセージを端末に到達させることができる。また、ロングポーリングは、企業内イントラネットのようにプロキシサーバを経由してインターネットに接続する環境においても、端末にプッシュメッセージを到達させることができる。

【0046】

しかし、ロングポーリングは、ＴＣＰセッションを常時維持しておく必要がある。従って、プッシュサーバおよび端末は、ＴＣＰセッションを維持するために定期的に通信を行う必要がある。そのため、モバイル網においてロングポーリングを行った場合には、輻輳が発生する可能性がある。また、サーバ負荷が増大する可能性がある。

【0047】

ダイレクトＩＰは、プッシュサーバが、メッセージ配信時に端末とのＴＣＰセッションを確立させ、確立したＴＣＰセッションを利用してプッシュメッセージを送信する方法である。

【0048】

端末がＮＡＴ配下にある場合には、端末とプッシュサーバとが異なるＩＰアドレス空間に存在するため、プッシュサーバは当該端末とのＴＣＰ接続を行うことができない。従って、ダイレクトＩＰを利用する場合には、プッシュサーバを端末と同一ＮＡＴ内に配置する必要がある。

【0049】

携帯電話サービスを提供する通信事業者（キャリア）は、モバイル網内にプッシュサーバを設置することができる。つまり、プッシュサーバを端末と同一ＮＡＴ内に設置することができる。よって、モバイル網がＮＡＴ経由でインターネットに繋がっている環境でも、キャリアがプッシュサーバをモバイル網内に設置することにより、当該モバイル網でダイレクトＩＰを利用することが可能となる。

【0050】

プッシュサーバと端末とが同一ＮＡＴ内に設置されていない場合であっても、端末にグローバルＩＰアドレスが割り振られている場合には、プッシュサーバから端末に対してＴＣＰセッションの確立を行うことができるので、ダイレクトＩＰを利用することができる。

【0051】

ダイレクトＩＰは、ＴＣＰセッションを常時維持させておく必要がないため、モバイル網で利用しても輻輳を発生させない。

【0052】

そこで、本実施形態では、端末１００は、ネットワークの状態に応じて、プッシュ方法を使い分ける。具体的には、ネットワークが、一般的に端末がＮＡＴ配下となるＷｉＦｉなどの無線ＬＡＮの場合には、端末１００はロングポーリングを選択する。ネットワークが、端末とプッシュサーバとが同一ＮＡＴ内に含まれるモバイル網の場合には、端末１００はダイレクトＩＰを選択する。

【0053】

図３は、端末１００がプッシュ方法としてロングポーリングを選択した場合の動作を示すシーケンス図である。なお、図３では、アプリケーション１２０（アプリケーション１２０−１〜１２０−ｎ）が１つ例示されているが、アプリケーションは端末１００上でいくつ動作していてもよい。また、図３では、端末１００が１つ例示されているが、プッシュサーバ２００に複数台の端末が接続される場合には各端末が端末１００と同様の動作をする。

【0054】

端末１００とプッシュサーバ２００とを接続するネットワークの状態に変化があった場合、端末１００のプッシュクライアント１１０は、ネットワークの状態が変化したことを検知する（ステップＳ３０１）。具体的には、プッシュクライアント１１０のＮＷ状態検知部１１２が、端末１００上で動作するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）からネットワークの状態が変化したことを示す通知（以下、ＮＷ状態変更通知という。）を受信する。

【0055】

ＮＷ状態検知部１１２は、ＮＷ状態変更通知をもとに、ネットワーク状態を確認する（ステップＳ３０２）。具体的には、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とを接続するネットワークの種別を確認する。ここでは、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とが無線ＬＡＮを介して接続されていることを認識する。

【0056】

メッセージ受信部１１４は、ネットワークが無線ＬＡＮであるので、プッシュ方法としてロングポーリングを選択する。そして、メッセージ受信部１１４は、プッシュサーバ２００に対して、配信すべきプッシュメッセージの有無の問い合わせ（以下、プッシュ問い合わせという。）を行うために、問い合わせ要求を送信する。具体的には、メッセージ受信部１１４は、ＨＴＴＰ要求を送信する（ステップＳ３０３）。

【0057】

プッシュサーバ２００は、ＨＴＴＰ要求に対して即座に応答しない。プッシュサーバ２００は、端末１００のプッシュクライアント１１０に対して配信すべきプッシュメッセージが発生するまで、ＨＴＴＰ要求に対する応答をブロックする。なお、配信すべきプッシュメッセージがある場合には、ブロックせずに即座に応答を返す。

【0058】

図４は、端末１００がプッシュ方法としてダイレクトＩＰを選択した場合の動作を示すシーケンス図である。

【0059】

ステップＳ４０１、ステップＳ４０２の処理は、ステップＳ３０１、ステップＳ３０２の処理と同様であるため説明を省略する。

【0060】

なお、ステップＳ４０２では、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とがモバイル網を介して接続されていることを認識する。

【0061】

メッセージ受信部１１４は、ネットワークがモバイル網であるので、プッシュ方法としてダイレクトＩＰを選択する。

【0062】

メッセージ更新通知受信部１１３は、ＴＣＰ待ち受けを開始する（ステップＳ４０３）。具体的には、メッセージ更新通知受信部１１３は、ＴＣＰのポートを開放し、メッセージ更新通知を受信可能な状態にする。

【0063】

端末状態通知送信部１１１は、端末の状態を通知する（ステップＳ４０４）。具体的には、端末状態通知送信部１１１は、端末のＩＰアドレスと、メッセージ更新通知受信部１１３が開放したＴＣＰポートのポート番号とを含む端末状態情報をプッシュサーバ２００に送信する。

【0064】

ステップＳ４０４の後、端末１００のプッシュクライアント１１０は、プッシュサーバ２００からのＴＣＰ接続を待つ。つまり、プッシュクライアント１１０は、プッシュサーバ２００が端末１００とのＴＣＰセッションを確立するのを待つ。このとき、プッシュクライアント１１０とプッシュサーバ２００間のＴＣＰセッションは確立されていない。従って、プッシュクライアント１１０とプッシュサーバ２００とは、ＴＣＰセッションを維持するための定期的な通信を行う必要がない。

【0065】

ここで、プッシュサーバ２００におけるプッシュ方法の判定処理を説明する。

【0066】

プッシュサーバ２００は、ステップＳ３０３において、プッシュ問い合わせのＨＴＴＰ要求を受信すると、端末１００がロングポーリングを選択したと判断する。また、ステップＳ４０４において端末状態通知送信部１１１から端末状態情報を受信すると、端末１００がダイレクトＩＰを選択したと判断する。

【0067】

このように、端末状態通知またはプッシュ問い合わせによって、プッシュ方法の選択結果がプッシュサーバ２００に通知される。このような形態を実現するには、例えば、端末状態通知のＵＲＬのパスと、プッシュ問い合わせのＵＲＬのパスとを別に設定し、プッシュサーバ２００は、どちらのＵＲＬにアクセスがあったかを判断すればよい。

【0068】

次に、端末１００がロングポーリングによりプッシュメッセージを取得する動作を説明する。

【0069】

図５は、ロングポーリングによるプッシュメッセージの配信処理を示すシーケンス図である。

【0070】

図５に示すシーケンス図においては、端末１００によるプッシュ問い合わせ実施以降のメッセージ配信システムの動作を示す。

【0071】

プッシュサーバ２００は、プッシュクライアント１１０のメッセージ受信部１１４からＨＴＴＰ要求としてプッシュ問い合わせを受け付けると（ステップＳ５０１）、端末１００がロングポーリングを選択したと判断する。このとき、プッシュサーバ２００は、即座に応答せずに、配信すべきプッシュメッセージの発生を待つ。つまり、プッシュサーバ２００はプッシュ待ちの状態となる。

【0072】

プッシュサーバ２００は、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けると（ステップＳ５０２）、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答（ＨＴＴＰ ２００ＯＫ）とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ５０３）。

【0073】

プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ５０３で受信したメッセージを対応するアプリケーションに渡す（ステップＳ５０４）。

【0074】

次に、端末１００がダイレクトＩＰによりプッシュメッセージを取得する動作を説明する。

【0075】

図６は、ダイレクトＩＰによるプッシュメッセージの配信処理を示すシーケンス図である。

【0076】

図６に示すシーケンス図においては、端末１００が端末状態通知をした後のメッセージ配信システムの動作を示す。

【0077】

プッシュサーバ２００は、端末１００から端末状態通知を受けると、すなわち端末１００から端末状態情報を受信すると、端末１００がダイレクトＩＰを選択したと判断する。その後、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けると（ステップＳ６０１）、プッシュサーバ２００は、プッシュクライアント１１０に対してＴＣＰ接続を行う（ステップＳ６０２）。ダイレクトＩＰでは、このＴＣＰ接続がメッセージ更新通知となる。すなわち、メッセージ更新通知受信部１１３は、ＴＣＰ接続を検知することにより、メッセージ更新通知があったと判断する。

【0078】

プッシュクライアント１１０のメッセージ更新通知受信部１１３がプッシュサーバ２００とのＴＣＰ接続を検知すると、メッセージ受信部１１４は、これをトリガとしてメッセージ取得処理を開始する。つまり、プッシュサーバ２００に対してＨＴＴＰ要求としてメッセージ取得要求を送信する（ステップＳ６０３）。

【0079】

プッシュサーバ２００は、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ６０４）。

【0080】

プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ６０４で受信したメッセージを対応するアプリケーションに渡す（ステップＳ６０５）。

【0081】

以上に説明したように、本実施形態では、端末がネットワーク状態に応じてプッシュ方法を決定する。従って、ロングポーリング方式のみを利用した場合に比べプッシュサーバの処理負荷を軽減させるとともに、端末が利用するネットワークの種別によらずに、プッシュメッセージを確実に端末内のプッシュクライアントに到達させることができる。

【0082】

また、端末がモバイル網を利用しているときには、ＴＣＰセッションを常時維持させておく必要がないダイレクトＩＰをプッシュ方法として選択するので、モバイル網における制御信号の輻輳の発生を抑止することができる。

【0083】

なお、本実施形態では、端末とプッシュサーバとが異なるＩＰアドレス空間に存在する場合には、ＮＡＴやＦＷを介した通信およびプロキシサーバを介した通信が可能なロングポーリングをプッシュ方法として選択しているが、その他の方法を利用してもよい。例えば、プロキシサーバを介した通信ができなくてもよい場合には、ＷｅｂＳｏｃｋｅｔやＴＣＰ独自通信を利用することができる。つまり、第一の通信方式はＷｅｂＳｏｃｋｅｔやＴＣＰ独自通信であってもよい。

【0084】

ＷｅｂＳｏｃｋｅｔは、ウェブサーバとブラウザ間のＴＣＰ上における双方向通信用の通信方式である。ＷｅｂＳｏｃｋｅｔでは、ＴＣＰセッションを１回確立させると、その後端末とプッシュサーバ間で双方向通信が可能となる。ただし、ＷｅｂＳｏｃｋｅｔでは、ＷｅｂＳｏｃｋｅｔに対応していないプロキシサーバを介した通信を行うことができない。ＴＣＰ独自通信は、ユーザ等が独自に開発したＴＣＰ上における通信方式である。

【0085】

実施形態２．
以下、本発明の第２の実施形態を図面を参照して説明する。

【0086】

端末１００の第２の実施形態における構成は、第１の実施形態における構成と同様であるため、説明を省略する。

【0087】

第１の実施形態では、ロングポーリングおよびダイレクトＩＰによってプッシュメッセージを端末に配信するメッセージ配信システムを例にした。

【0088】

しかし、ロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合がある。例えば、端末が長時間無通信（スリープ）状態になっていて、端末のＩＰアドレスが開放されている場合である。

【0089】

本実施形態では、ロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合、プッシュサーバ２００は、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）を利用してプッシュメッセージを配信する。

【0090】

図７は、ＳＭＳによるプッシュメッセージの配信処理を示すシーケンス図である。

【0091】

プッシュサーバ２００は、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けたときに（ステップＳ７０１）、配信先の端末が選択したプッシュ方法でプッシュメッセージの配信が可能か否かを判定する。本実施形態では、プッシュサーバ２００は、プッシュメッセージの配信試行を実行し、配信試行の結果をもとに配信可能か否かを判定する（ステップＳ７０２）。

【0092】

プッシュサーバ２００は、配信先の端末がプッシュ方法としてダイレクトＩＰを選択している場合は、ダイレクトＩＰによるプッシュメッセージの配信を試行する。また、プッシュサーバ２００は、配信先の端末がプッシュ方法としてロングポーリングを選択している場合は、ロングポーリングによるプッシュメッセージの配信を試行する。

【0093】

このとき、端末１００が、長時間スリープ状態になっていて、端末１００のＩＰアドレスが開放されてしまっている場合がある。その場合、プッシュメッセージが端末１００に配信されない。

【0094】

プッシュメッセージの配信試行に失敗した場合には、プッシュサーバ２００は、配信先の端末が選択したプッシュ方法ではプッシュメッセージの配信ができないと判断する。そして、プッシュサーバ２００は、プッシュクライアント１１０に対して、配信すべきプッシュメッセージがあることを示す通知をＳＭＳで送信する（ステップＳ７０３）。このとき、端末１００のＩＰアドレスが開放されていたとしても、ＳＭＳによる通知は端末１００に到達する。本実施形態では、ＳＭＳによる通知がメッセージ更新通知となる。すなわち、メッセージ更新通知受信部１１３は、ＳＭＳによる通知を受けると、メッセージ更新通知があったと判断する。

【0095】

プッシュクライアント１１０のメッセージ更新通知受信部１１３がＳＭＳによる通知を受けると、メッセージ受信部１１４は、これをトリガとしてメッセージ取得処理を開始する。このとき、端末１００のＩＰアドレスは開放されているが、端末１００がプッシュサーバ２００と通信しようとしたタイミングで、端末１００にＩＰアドレスが割り当てられる。例えば、モバイル網上に設置されたＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバが、端末１００にＩＰアドレスを割り当てる。これにより、端末１００に対するプッシュメッセージの配信が可能となる。

【0096】

端末１００にＩＰアドレスが割り当てられた後、メッセージ受信部１１４は、プッシュサーバ２００に対してＨＴＴＰ要求としてメッセージ取得要求を送信する（ステップＳ７０４）。

【0097】

プッシュサーバ２００は、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ７０５）。

【0098】

プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ７０５で受信したメッセージを配信先のアプリケーションに渡す（ステップＳ７０６）。

【0099】

以上に説明したように、本実施形態では、端末が、プッシュサーバから配信すべきプッシュメッセージがあることを示すＳＭＳによる通知を受けると、メッセージ取得要求をプッシュサーバに送信する。従って、プッシュサーバがロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合であっても、プッシュサーバがＳＭＳによる通知を端末に送信すれば、端末は当該通知をもとにプッシュメッセージを取得することができる。よって、例えば、端末のＩＰアドレスが開放されている場合であっても、確実に端末にプッシュメッセージを配信することができる。

【0100】

なお、本実施形態では、ＳＭＳによる通知をトリガとする場合を例にしたが、配信すべきプッシュメッセージがあることをＩＰアドレスが開放されている端末に通知可能であれば、ＳＭＳ以外の方法を利用してもよい。

【0101】

実施形態３．
以下、本発明の第３の実施形態を図面を参照して説明する。

【0102】

端末１００の第３の実施形態における構成は、第１の実施形態および第２の実施形態における構成と同様であるため、説明を省略する。

【0103】

ただし、本実施形態では、端末状態通知送信部１１１は、端末のＩＰアドレスが前回端末状態通知をしたときのＩＰアドレスと同一の場合には、端末状態通知を行わない。

【0104】

図８は、端末１００がプッシュ方法としてダイレクトＩＰを選択した場合の第３の実施形態の動作を示すシーケンス図である。

【0105】

ステップＳ８０１〜Ｓ８０３の処理は、第１の実施形態のステップＳ４０１〜Ｓ４０３の処理と同様であるため、説明を省略する。

【0106】

ステップＳ８０３の後、端末状態通知送信部１１１は、端末に現在割り当てられているＩＰアドレスが、前回端末状態通知をしたときのＩＰアドレスと同一であるか否かを確認する（ステップＳ８０４）。

【0107】

ＩＰアドレスが同一である場合は、端末状態通知送信部１１１は、端末状態通知を行わない（ステップＳ８０５）。なお、ＩＰアドレスが同一でない場合には、端末状態通知送信部１１１は、ステップＳ４０４の処理と同様に端末状態通知を行う。

【0108】

以上に説明したように、本実施形態では、端末がプッシュ方法としてダイレクトＩＰを選択した場合に、端末のＩＰアドレスが前回端末状態通知をしたときと同一であるときには、端末は端末状態通知を行わない。これにより、端末およびプッシュサーバの処理負荷をさらに軽減することができる。特に、端末のネットワーク状態が頻繁に切り替わるような環境において、端末およびプッシュサーバの処理負荷を軽減することができる。

【0109】

例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境では、ネットワークがＷｉＦｉからモバイル網に切り替わる度に、端末から端末状態情報がプッシュサーバに送信される。従って、端末およびプッシュサーバの処理負荷が増大する可能性がある。しかし、本実施形態によれば、そのような環境でも端末およびプッシュサーバの処理負荷を軽減することができる。

【0110】

図９は、本発明による端末の最小構成を示すブロック図である。図１０は、本発明によるメッセージ配信システムの最小構成を示すブロック図である。

【0111】

図９に示すように、端末（図１に示す端末１００−１〜１００−ｎおよび図２に示す端末１００に相当。）は、自端末と、メッセージの配信をプッシュ型で行う配信装置（図１に示すプッシュサーバ２００に相当。）とを接続するネットワークの状態を検知するネットワーク状態検知部１１（図２に示す端末１００のプッシュクライアント１１０におけるＮＷ状態検知部１１２に相当。）と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部１２（図２に示す端末１００のプッシュクライアント１１０における端末状態通知送信部１１１、メッセージ更新通知受信部１１３およびメッセージ受信部１１４に相当。）とを備える。

【0112】

そのような構成によれば、配信装置の処理負荷を削減しつつ、端末が利用するネットワークの種別によらずに、プッシュメッセージを確実に端末に到達させることができる。

【0113】

上記の実施形態には、以下のような端末も開示されている。

【0114】

（１）受信部１２は、自端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置とが同一ＩＰアドレス空間に配置されていると判断する端末。

【0115】

そのような構成によれば、ネットワークの種別をもとに、端末と配信装置とが同一ＩＰアドレス空間内にいるか否かを判定することができる。

【0116】

（２）受信部１２は、第一の通信方式を選択した場合は、配信装置に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、配信装置とのＴＣＰ接続を検知したときに当該配信装置にメッセージ取得要求を送信する端末。

【0117】

そのような構成によれば、選択したプッシュ方法に応じて、配信装置からプッシュメッセージを取得することができる。

【0118】

（３）受信部１２は、第二の通信方式を選択したときに自端末のＩＰアドレスを含む端末状態情報を配信装置に通知する端末。

【0119】

そのような構成によれば、配信装置が端末状態通知をもとに端末のＩＰアドレスなどを認識することができ、配信装置から端末に対してＴＣＰ接続を行うことが可能となる。また、端末状態情報を通知することにより、端末がプッシュ方法としてダイレクトＩＰを選択したことを配信装置が認識することができる。

【0120】

（４）受信部１２は、配信すべきメッセージがあることを示すＳＭＳによる通知を検知したときに配信装置にメッセージ取得要求を送信する端末。

【0121】

そのような構成によれば、例えば、端末のＩＰアドレスが開放されている場合であっても、端末は、ＳＭＳによる通知により配信すべきプッシュメッセージがあることを認識することができる。従って、そのような場合でも、端末は確実にプッシュメッセージを取得することができる。

【0122】

（５）受信部１２は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を配信装置に通知しない端末。

【0123】

そのような構成によれば、例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境において、ネットワークがモバイル網に切り替わる際の端末状態情報の送信を抑止することができる。従って、端末およびプッシュサーバの処理負荷をさらに軽減することができる。

【0124】

上記の実施形態には、図１０に示すようなメッセージ配信システムも開示されている。

【0125】

（６）端末１０−１〜１０−ｎ（図１に示す端末１００−１〜１００−ｎに相当。）と、端末１０−１〜１０−ｎにメッセージの配信をプッシュ型で行う配信装置２０（図１に示すプッシュサーバ２００に相当。）とを備え、端末１０−１〜１０−ｎは、自端末と配信装置２０とを接続するネットワークの状態を検知するネットワーク状態検知部１１と、検知結果をもとに、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置２０が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置２０からメッセージを受信する受信部１２とを備え、配信装置２０は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部２１（図１に示すプッシュサーバ２００における制御部（図示せず）に相当。）を備えるメッセージ配信システム。

【0126】

そのような構成によれば、端末が利用するネットワークの種別によらずに、配信装置の処理負荷を増大させることなく、プッシュメッセージを確実に端末に到達させることができる。

【0127】

（７）受信部１２は、自端末と配信装置２０とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていると判断するメッセージ配信システム。

【0128】

そのような構成によれば、ネットワークの種別をもとに、端末と配信装置とが同一ＩＰアドレス空間内にいるか否かを判定することができる。

【0129】

また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下
に限られない。

【0130】

（付記１）端末１０−１〜１０−ｎと、端末１０−１〜１０−ｎにメッセージの配信をプッシュ型で行う配信装置２０とを備え、端末１０−１〜１０−ｎは、自端末と配信装置２０とを接続するネットワークの状態を検知するネットワーク状態検知部１１と、検知結果をもとに、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置２０が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置２０からメッセージを受信する受信部１２とを備え、配信装置２０は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部２１を備えるメッセージ配信システム。

【0131】

（付記２）受信部１２は、自端末と配信装置２０とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていると判断する付記１に記載のメッセージ配信システム。

【0132】

（付記３）受信部１２は、第一の通信方式を選択した場合は、配信装置２０に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、配信装置２０とのＴＣＰ接続を検知したときに当該配信装置２０にメッセージ取得要求を送信する付記１または付記２に記載のメッセージ配信システム。

【0133】

そのような構成によれば、端末が選択したプッシュ方法に応じて、配信装置から端末へプッシュメッセージの配信を行うことができる。

【0134】

（付記４）受信部１２は、第二の通信方式を選択したときに自端末のＩＰアドレスを含む端末状態情報を配信装置２０に通知し、制御部２１は、メッセージ配信時に端末状態情報をもとに端末１０−１〜１０−ｎとのＴＣＰセッションを確立する付記１から付記３のうちのいずれか１つに記載のメッセージ配信システム。

【0135】

そのような構成によれば、配信装置が端末状態通知をもとに端末のＩＰアドレスなどを認識することができ、配信装置から端末に対してＴＣＰ接続を行うことが可能となる。また、端末状態情報を通知することにより、端末がプッシュ方法としてダイレクトＩＰを選択したことを配信装置が認識することができる。

【0136】

（付記５）制御部２１は、第一の通信方式または第二の通信方式によるメッセージ配信ができないと判断した場合には、配信すべきメッセージがあることを示すＳＭＳによる通知を端末１０−１〜１０−ｎに送信し、受信部１２は、ＳＭＳによる通知を検知したときに配信装置２０にメッセージ取得要求を送信する付記１から付記４のうちのいずれか１つに記載のメッセージ配信システム。

【0137】

そのような構成によれば、例えば、端末のＩＰアドレスが開放されている場合であっても、ＳＭＳによる通知により、配信装置は端末に配信すべきプッシュメッセージがあることを認識させることができ、確実に端末に対してプッシュメッセージを配信することができる。

【0138】

（付記６）受信部１２は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を配信装置２０に通知しない付記４または付記５に記載のメッセージ配信システム。

【0139】

そのような構成によれば、例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境において、ネットワークがモバイル網に切り替わる際の端末状態情報の送信を抑止することができる。従って、端末およびプッシュサーバの処理負荷をさらに軽減することができる。

【0140】

この出願は、２０１２年１０月１７日に出願された日本特許出願２０１２−２３０００１を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【0141】

以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

【符号の説明】

【0142】

１０−１〜１０−ｎ、１００、１００−１〜１００−ｎ、５００−１、５００−２ 端末
１１、１１２ ネットワーク（ＮＷ）状態検知部
１２ 受信部
２０ 配信装置
２１ 制御部
１１０、５１０−１、５１０−２ プッシュクライアント
１１１ 端末状態通知送信部
１１３ メッセージ更新通知受信部
１１４ メッセージ受信部
１１５ メッセージ通知部
１２０−１〜１２０−ｎ アプリケーション
２００、６００ プッシュサーバ
３００、３００−１〜３００−ｎ、７００−１〜７００−３ アプリケーションサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】