JP2014053732A - 通信端末装置、メッセージ配信システム、及び通信方法 - Google Patents

Abstract

【課題】即時性のあるサービスを提供するプッシュ通信システムの開発に掛かる作業を軽減するための技術を提供する。
【解決手段】サーバ装置と通信端末装置との間で、ＷｅｂＳｏｃｋｅｔプロトコルを用いた、メッセージプッシュ配信が行われる。この通信においては、通信端末装置からサーバ装置に対しては、ＷｅｂＳｏｃｋｅｔ接続維持のための信号が定期的に送信される。通信端末装置は、利用ネットワーク構成情報に基づいて、利用者が現在利用している携帯電話通信キャリアの接続維持間隔及びクラウド基盤の接続維持間隔を特定し、少なくとも当該特定した携帯電話通信キャリアの接続維持間隔とクラウド基盤の接続維持間隔の何れが最小かを判定し、最小の接続維持間隔を用いてサーバ装置との通信接続を確立する。本発明では、携帯電話通信キャリア別の接続維持間隔情報及びクラウド基盤別の接続維持間隔情報は、書き換え不要の固定の情報である。
【選択図】図２

Description

本発明は、通信端末装置、メッセージ配信システム、及び通信方法に関し、例えば、ＷｅｂＳｏｃｋｅｔプロトコルを利用したプッシュ配信に関するものである。

サーバからクライアント端末に、メッセージをプッシュ配信する方法として、ＳＭＳ方式、ＷｅｂＳｏｃｋｅｔ方式などがある。ＳＭＳ方式については、例えば、特許文献１や非特許文献１に開示されている。

一方、ＷｅｂＳｏｃｋｅｔ方式は、非特許文献２に、ＩＥＴＦによりＲＦＣ６４５５として開示されている。ＷｅｂＳｏｃｋｅｔ方式の規格策定時期は、２０１１年１２月と比較的新しい。

一般にＳＭＳは非特許文献１にあるように、通信事業者が提供するものであり、電話回線契約が必要であるため一般に料金が高い。一方、ＷｅｂＳｏｃｋｅｔ方式は、電話回線契約が不要で、パケット通信費用のみであるためＳＭＳに比べ低額である。この点で、ＷｅｂＳｏｃｋｅｔ方式が注目されている。ＷｅｂＳｏｃｋｅｔは、接続を、通信を行う２者間で維持することを特徴とする方式である。例えば、ＷｅｂＳｏｃｋｅｔ方式では、クライアント端末側からの接続要求に応じてサーバとの間で接続が確立され、その後サーバからのプッシュ配信が可能となる。

プッシュ型配信方式においては、必ずしも即時性が保証されているわけではない。このため、サーバ側から移動体に設置したクライアント端末に対して、即時性のあるメッセージ送信が望まれる。即時性のあるメッセージを送るには、第１に接続を維持すること、第２に予期せぬ切断が発生しても即座に切断検知し、接続を再度行うこと、が必要である。

第１の要件に関し、メッセージ送信の際に経由するネットワーク装置の中には、非特許文献３に示すように、負荷軽減のため、無通信状態が一定時間に達すると切断を行うというアイドル切断の機能を備えているものがある。このような無通信状態継続による切断を防ぐため、送るべきメッセージが無くても無通信状態が一定時間経過すると接続維持のための接続維持信号を送付する。

第２の要件に関し、携帯電話回線上で利用する場合、電波不良のため、上記ネットワーク装置のアイドル切断の通知などを受け取れず、クライアントが切断に気付かないことが考えられる。また、携帯回線やＷｉｆｉといったネットワーク種別変更に伴う切断にクラアイントが気付かないことが考えられる。当該課題に対する解決策として、接続維持信号に対する応答が一定期間無い場合に接続を切断する再送タイマを設ける方法がある。

特開２００２−１１１７９０号公報

http://www.jpo.go.jp/shiryou/s_sonota/hyoujun_gijutsu/keitai/3-1-1.pdf http://tools.ietf.org/html/rfc6455 http://www.hitachi.co.jp/Prod/comp/soft1/manual/cosmi/v0870/APKC/EU070179.HTM

しかしながら、上述のような即時性のあるメッセージサービスを提供するプッシュ通信システムを開発するには、非常に多くの作業量が必要となってしまう。特に、次の３つ事項に関する作業量が課題である。

（i）接続維持間隔の調査
顧客間で、又は同一顧客によって利用されているシステムにおいて、携帯回線またはＷｉｆｉ回線といったクライアント端末直結ネットワーク及びクラウド基盤網といったネットワーク構成要素のうち何れか１つでも変更されると、システム開発者は、その都度システム全体の接続維持間隔を調べ直す必要がある。ここで、基幹回線網（バックボーン）に関しては、上記要素より短いアイドルタイムアウトを設定している情報は公開されていないため、無いものとみなとして省略する。また、クラウド基盤を公開するためのインターネットサービスプロバイダ網もネットワーク構成要素の１つであるが、以降の実施形態の説明では、簡単のため省略するものとする。

また、顧客の即時性（最大不通時間）要望値が変更された場合も、開発者は、その都度システム全体の接続維持間隔を調べ直す必要がある。

（ii）動的変更への対応
複数ネットワーク種別混在環境では、ネットワーク種別動的変更に対応できない。

（iii）接続維持間隔の調査
特に、顧客の求める最大不通時間（即時性）に適合する接続維持間隔を調べるのに手間が掛かってしまう。

本発明はこのような状況に鑑みてなされたのであり、即時性のあるサービスを提供するプッシュ通信システムの開発に掛かる作業を軽減するための技術を提供するものである。

上記課題を解決するために、本発明では、サーバ装置（配信装置）と通信端末装置（クライアント端末装置）との間で、ＷｅｂＳｏｃｋｅｔプロトコルを用いた、メッセージプッシュ配信が行われる。この通信においては、通信端末装置からサーバ装置に対しては、ＷｅｂＳｏｃｋｅｔ接続維持のための信号が定期的に送信される。ここで、通信端末装置は、メモリに、少なくとも、携帯電話通信キャリア別の接続維持間隔情報と、クラウド基盤別の接続維持間隔情報と、利用者が利用するネットワークの構成要素を示す利用ネットワーク構成情報と、を保持している。そして、通信端末装置は、利用ネットワーク構成情報に基づいて、利用者が現在利用している携帯電話通信キャリアの接続維持間隔及びクラウド基盤の接続維持間隔を特定する接続維持間隔特定処理と、当該特定した携帯電話通信キャリアの接続維持間隔とクラウド基盤の接続維持間隔の何れが最小かを判定する最小接続維持間隔判定処理と、最小の接続維持間隔を用いてサーバ装置との通信接続を確立する接続確立処理と、を実行する。ここで、携帯電話通信キャリア別の接続維持間隔情報及びクラウド基盤別の接続維持間隔情報は書き換え不要の固定の情報であり、利用ネットワーク構成情報は利用者毎に設定される情報である。

本発明によれば、即時性のあるサービスを提供するプッシュ通信システムの開発に掛かる作業を軽減することが可能となる。

本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本発明の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。

本明細書の記述は典型的な例示に過ぎず、本発明の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。

本発明の第１の実施形態を適用する場面を示す図である。 本発明の第１の実施形態による配信システム概略構成を示す図である。 ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃの機能構成を示す図である。 ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの機能構成を示す図である。 携帯回線接続先テーブル３３Ｂ１００の構成例を示す図である。 Ｗｉｆｉ接続先テーブル３３Ｂ１０１の構成例を示す図である。 携帯キャリア別接続維持間隔テーブル３３Ｂ２０２の構成例を示す図である。 Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３の構成例を示す図である。 クラウド基盤別接続維持間隔テーブル３３Ｂ２０４の構成例を示す図である。 最大接続維持間隔テーブル３３Ｂ２０５の構成例を示す図である。 接続維持再送間隔テーブル３３Ｂ２０６の構成例を示す図である。 接続維持再送回数テーブル３３Ｂ２０７の構成例を示す図である。 利用ネットワーク構成要素指定テーブル３３Ｂ２０８の構成例を示すである。 第１の実施形態によるクライアント端末装置３の接続処理を説明するためのフローチャートである。 第１の実施形態による、接続中の接続信号送付処理を説明するためのフローチャートである。 第１の実施形態による、接続中に切断が起こった場合の再接続処理を説明するためのフローチャートである。 本発明の実施形態におけるシステムにおいて開発が必要な要素を示す図である。 サーバ（配信装置２）側で実行されるメッセージ送信処理を説明するためのフローチャートである。 管理者端末装置１の表示部に表示される設定画面（ＧＵＩ）の例を示す図である。 第２の実施形態の適用場面を示すための模式図である。 本発明の第２の実施形態による配信システムの概略構成を示す図である。 第２の実施形態による、クライアント端末装置３が実行する接続処理を説明するためのフローチャートである。 第３の実施形態による、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの内部構成を示す図である。 第３の実施形態による、クライアント端末装置が実行する接続処理を説明するためのフローチャートである。

本発明は、例えば、ＷｅｂＳｏｃｋｅｔプロトコルを利用したプッシュ配信システムの開発に掛かる作業量を軽減するための技術を提供する。

本発明の各実施形態は、顧客間または同一顧客が利用しているネットワーク環境において、システム構成要素が変わった場合でもシステム全体の接続維持間隔を、全てのシステム構成要素について調べ直すことを不要とするものである。また、各実施形態は、電波が良好でない環境を含め、顧客の要望する時間内に即時性を確保するための作業量も軽減することである。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。

以後の説明では「テーブル」によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

以下では「・・・部」を主語（動作主体）として本発明の実施形態における各処理について説明を行うが、各「・・・部」はプログラムによって構成するようにしても良い。この場合、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを動作主体として説明してもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

（１）第１の実施形態
第１の実施形態は、ネットワーク構成要素の静的な変更への対応を軽減するためのものである。

＜適用場面＞
図１は、第１の実施形態を適用する場面を示す図である。図１Ａ乃至Ｃは、それぞれ、携帯キャリアＡのみを利用する場合、携帯キャリアＢのみを利用する場合、顧客構内でＷｉｆｉ網のみを利用する場合の模式図である。上述のとおり、顧客間で、又は同一顧客によって利用されているシステムでは、このようなネットワーク構成要素は、変更されることがあり得る。

図１Ａによる場面では、管理者端末装置１は、インターネット４を介して配信装置２と接続されている。また、配信装置２は、インターネット４及び携帯キャリアＡ網１０２を介して移動体１０１の中のクライアント端末装置３と接続されている。この移動体１０１の中のクライアント端末装置３は、顧客α構内１０３または顧客α構外１０４にあり、配信装置２と携帯キャリアＡ網１０２を使って通信する。

図１Ｂによる場面では、管理者端末装置１は、インターネット４を介して配信装置２と接続されている。また、配信装置２は、インターネット４及び携帯キャリアＢ網１０５を介して移動体１０１の中のクライアント端末装置３と接続されている。この移動体１０１の中のクライアント端末装置３は、顧客β構内１０６または顧客β構外１０７にあり、配信装置２と携帯キャリアＢ網１０５を使って通信する。

図１Ｃによる場面では、管理者端末装置１は、インターネット４を介して配信装置２と接続されている。また、配信装置２は、インターネット４及び顧客宅内のＬＡＮも含むＷｉｆｉ網６が接続されている。そして、顧客γ構内１０８内の移動体１０１の中のクライアント端末装置３は、Ｗｉｆｉ網６を通じて配信装置２と通信を行う。顧客γ構外１０９では通信手段はない。

上述したように、図１Ａで動作しているシステムを図１Ｂの場面で動作できるようにするためには、システムを変更する必要がある（ネットワーク構成要素の静的な変更）。このシステム変更を実現する場合、システム全体の接続維持間隔をあらゆる手段を尽くして調べなければならない。

しかし、この接続維持間隔の調査については作業量が多くなってしまう場合があり、この作業量を軽減できるような工夫が必要である。

そこで、第１の実施形態では、このようなネットワーク構成要素を静的に変更する際の作業量を軽減するための構成を提供する。

＜配信システムの構成＞
図２は、本発明の第１の実施形態による配信システム概略構成を示す図である。
第１の実施形態による配信システムは、少なくとも１つの管理者端末装置１と、少なくとも１つの配信装置２と、少なくとも１つのクライアント端末装置３と、を有し、管理者端末装置１と配信装置２はインターネット４を介して接続され、配信装置２とクライアント端末装置３は携帯電話網５及びＷｉｆｉ網６を介して接続されている。

管理者端末装置１は、ＣＰＵ１１Ａ及びメモリ１１Ｂを含む端末装置１１と、通信ポート１２と、外部記憶装置１３と、を有している。外部記憶装置１３は、管理者からのメッセージの送信などの操作を配信装置２に対して命令するための管理者操作送信部１３Ａと、送信結果などを表示するための表示処理部１３Ｂと、を有している。なお、管理者操作送信部１３Ａ及び表示処理部１３Ｂはプログラムとして格納されており、ＣＰＵ１１Ａがこれらのプログラムを実行して、それぞれの機能を実現している。

配信装置２は、ＣＰＵ２１Ａ及びメモリ２１Ｂを含む端末装置２１と、通信ポート２２と、外部記憶装置２３と、を有している。外部記憶装置２３は、管理者操作の応答を管理者端末装置に返すための管理者操作応答部２３Ａと、同装置内の処理を取りまとめるサーバ管理部２３Ｂと、ＷｅｂＳｏｃｋｅｔでメッセージ送付するためのＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃと、を有している。サーバ管理部２３Ｂは、よく送付する内容を保存する送信内容リストテーブル２３Ｂ１と、クライアント端末装置３の情報を保存する送信先端末リストテーブル２３Ｂ２とを有している。なお、管理者操作応答部２３Ａ、サーバ管理部２３Ｂ、及びＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃはプログラムとして格納されており、ＣＰＵ２１Ａがこれらのプログラムを実行して、それぞれの機能を実現している。

クライアント端末装置３は、ＣＰＵ３１Ａ及びメモリ３１Ｂを含む端末装置３１と、通信ポート３２と、外部記憶装置３３と、を有している。外部記憶装置３３は、クライアント端末装置内の処理を取りまとめるクライアント管理部３３Ａと、ＷｅｂＳｏｃｋｅｔで通信を行うためのＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂと、配信装置から配信されたメッセージを表示するための表示処理部３３Ｃと、クライアント端末装置３が利用するネットワークが携帯電話網の場合に接続を行う携帯回線接続部３３Ｄと、クライアント端末装置３が利用するネットワークがＷｉｆｉである場合にＷｉｆｉ網を検索しさらに接続を行うＷｉｆｉ検索・接続部３３Ｅと、を有している。なお、クライアント管理部３３Ａ、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂ、表示処理部３３Ｃ、携帯回線接続部３３Ｄ、及びＷｉｆｉ検索・接続部３３Ｅはプログラムとして格納されており、ＣＰＵ３１Ａがこれらのプログラムを実行して、それぞれの機能を実現している。

＜ＷｅｂＳｏｃｋｅｔサーバ側通信部の機能＞
図３は、ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃの機能構成を示す図である。
ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃは、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂからの接続・切断要求に対して応答するための接続・切断応答部２３Ｃ１と、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３ＢからのＷｅｂＳｏｃｋｅｔ接続維持のためのパケットに対する応答を送信するための接続維持信号応答部２３Ｃ２と、メッセージ送信を行うメッセージ送信部２３Ｃ３と、を有している。

＜ＷｅｂＳｏｃｋｅｔクライアント側通信部の機能＞
図４は、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの機能構成を示す図である。
ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃに対して接続・切断を要求する接続・切断部３３Ｂ１と、ＷｅｂＳｏｃｋｅｔ接続維持部３３Ｂ２と、メッセージ受信部３３Ｂ３と、を有している。

接続・切断部３３Ｂ１は、クライアント端末装置３が利用するネットワークが携帯電話網の場合の接続先の情報を格納するための携帯回線接続先テーブル３３Ｂ１００と、クライアント端末装置３が利用するネットワークがＷｉｆｉ網の場合の接続先の情報を格納するためのＷｉｆｉ接続先テーブル３３Ｂ１０１と、を保持している。ここで、携帯回線接続先テーブル３３Ｂ１００は、接続先アドレスだけでなく、認証情報などその他の接続に必要な情報も記述しても良い。

ＷｅｂＳｏｃｋｅｔ接続維持部３３Ｂ２は、ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃに対して接続維持信号を送信するための接続維持信号送信部３３Ｂ２００と、接続維持信号の応答が一定期間無い場合に接続を切断するための切断検知部３３Ｂ２０１と、携帯キャリア網、Ｗｉｆｉ網、クラウド基盤ネットワークといったネットワーク種別毎に必要な接続維持間隔を事前に格納しておくための、携帯キャリア別接続維持間隔テーブル３３Ｂ２０２と、Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３と、クラウド基盤別接続維持間隔テーブル３３Ｂ２０４と、顧客が要望する最大不通時間を満たす、最大接続維持間隔を記すための最大接続維持間隔テーブル３３Ｂ２０５と、切断検知部３３Ｂ２０１が接続維持信号の応答が無い場合に行う再送間隔、再送上限回数をそれぞれ記している接続維持再送間隔テーブル３３Ｂ２０６と、接続維持再送回数テーブル３３Ｂ２０７と、利用するネットワーク構成要素を指定するための利用ネットワーク構成要素指定テーブル３３Ｂ２０８と、を含んでいる。

なお、メッセージ送信部２３Ｃ３及びメッセージ受信部３３Ｂ３に関し、ＷｅｂＳｏｃｋｅｔは、サーバからクライアント側のみといった一方向の通信だけでなく、逆方向も含めた双方向を特徴とするプロトコルであり、これらは本来は送受信することのできる通信手段であるが、ここでは説明の簡便化のため、サーバからクライアント側のみの一方向であるかのように、記述する。

＜携帯回線接続先テーブル＞
図５は、携帯回線接続先テーブル３３Ｂ１００の構成例を示す図である。
携帯回線接続先テーブル３３Ｂ１００は、接続先ＵＲＬ５０１と、認証用ユーザ名５０２と、認証用パスワード５０３と、を構成項目として有している。図５の例では、それぞれの項目に、ａｄｄｒｅｓｓ_ａ、ｕｓｒ_ａ、及びｐｗ_ａが設定されている。

＜Ｗｉｆｉ接続先テーブル＞
図６は、Ｗｉｆｉ接続先テーブル３３Ｂ１０１の構成例を示す図である。
Ｗｉｆｉ接続先テーブル３３Ｂ１０１は、接続先ＵＲＬ６０１と、認証用ユーザ名６０２と、認証用パスワード６０３と、を構成項目として有している。図６の例では、それぞれの項目に、ａｄｄｒｅｓｓ_ｗｉｆｉ_ａ、ｕｓｒ_ｗｉｆｉ_ａ、ｐｗ_ｗｉｆｉ_ａが設定されている。

＜携帯キャリア別接続維持間隔テーブル＞
図７は、携帯キャリア別接続維持間隔テーブル３３Ｂ２０２の構成例を示す図である。
携帯キャリア別接続維持間隔テーブル３３Ｂ２０２は、携帯キャリア７０１と、必要な接続維持間隔７０２と、を構成項目として有している。ここで、接続維持間隔とは、無通信時間の計測タイマ動作開始を回避するために必要な時間間隔を示す情報である。

図７では、例えば、必要な接続維持間隔７０２として、Ａ社、Ｂ社、及びＣ社に対してそれぞれ、１８００秒、２４００秒、及び３０００秒と設定されている。

＜Ｗｉｆｉ接続維持間隔テーブル＞
図８は、Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３の構成例を示す図である。
Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３は、Ｗｉｆｉ接続維持間隔８０１の情報を保持しており、その値は、例えば３０秒と設定される。

＜クラウド基盤別接続維持間隔テーブル＞
図９は、クラウド基盤別接続維持間隔テーブル３３Ｂ２０４の構成例を示す図である。
クラウド基盤別接続維持間隔テーブル３３Ｂ２０４は、クラウド基盤９０１と、必要な接続維持間隔９０２と、を構成項目として有している。図９の例では、例えば、ａ社、ｂ社、及びｃ社に対してそれぞれ、６００秒、１２００秒、及び１８００秒が設定されている。

＜最大接続維持間隔テーブル＞
図１０は、最大接続維持間隔テーブル３３Ｂ２０５の構成例を示す図である。
最大接続維持間隔テーブル３３Ｂ２０５は、最大接続維持間隔１００１の情報を保持しており、その値は、例えば９００秒と設定される。この最大接続維持間隔１００１は、クライアント端末装置３のユーザが設定した要望値である。

＜接続維持再送間隔テーブル＞
図１１は、接続維持再送間隔テーブル３３Ｂ２０６の構成例を示す図である。
接続維持再送間隔テーブル３３Ｂ２０６は、接続維持再送間隔１１０１の情報を保持しており、その値は、例えば４秒と設定される。

＜接続維持再送回数テーブル＞
図１２は、接続維持再送回数テーブル３３Ｂ２０７の構成例を示す図である。
接続維持再送回数テーブル３３Ｂ２０７は、接続維持再送回数１２０１の情報を保持しており、その値は、例えば２回と設定される。なお、本明細書では、本テーブルで指定の再送回数の再送を行い、図１１の再送間隔待っても、接続維持信号の応答が返ってこない場合に切断とみなすものとする。

＜利用ネットワーク構成要素指定テーブル＞
図１３は、利用ネットワーク構成要素指定テーブル３３Ｂ２０８の構成例を示すである。
利用ネットワーク構成要素指定テーブル３３Ｂ２０８は、利用構成要素の項目名１３０１と、利用構成要素の内容１３０２と、を構成項目として有している。利用構成要素の項目名１３０１は、ネットワーク種別、携帯キャリア、クラウド基盤の情報で構成され、図１３の例では、それぞれ携帯回線、Ａ社、及びａ社と設定されている。

＜クライアント端末装置の接続処理＞
図１４は、第１の実施形態によるクライアント端末装置３の接続処理を説明するためのフローチャートである。当該処理は、クライアント端末装置３が起動した時、又は以降で説明する意図せぬ切断を検知した後に実行される処理である。

まず、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、携帯回線接続先テーブル３３Ｂ１００、及びＷｉｆｉ接続先テーブル３３Ｂ１０１を読み込む（ステップ２００）。

次に、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、携帯キャリア別接続維持間隔テーブル３３Ｂ２０２と、Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３と、クラウド基盤別接続維持間隔テーブル３３Ｂ２０４と、最大接続維持間隔テーブル３３Ｂ２０５と、を読み込む（ステップ２０１）。

また、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、利用ネットワーク構成要素指定テーブル３３Ｂ２０８で指定されている、ネットワーク種別と、携帯回線の場合さらに携帯キャリアと、クラウド基盤の情報を読み込む（ステップ２０２）。つまり、現在使用している環境についての情報が取得される。

ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、各テーブルから、指定の携帯キャリアの接続維持間隔７０２またはＷｉｆｉ接続維持間隔８０１と、クラウド基盤の接続維持間隔９０２を取得する（ステップ２０３）。

そして、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持再送間隔テーブル３３Ｂ２０６と、接続維持再送回数テーブル３３Ｂ２０７を読み込む（ステップ２０４）。

続いて、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、利用ネットワーク構成要素指定テーブル３３Ｂ２０８を参照して、ネットワーク種別が携帯回線であるか調べる（ステップ２０５）。使用しているネットワークが携帯回線の場合には、処理はステップ２０６に移行する。使用しているネットワークが携帯回線ではない場合には、処理はステップ２１２に移行する。

ステップ２０６において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続先として携帯回線接続先を採用する。（ステップ２０６）。

そして、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、携帯キャリアの接続維持間隔７０２、クラウド基盤の接続維持間隔９０２、最大接続維持間隔１００１を比較し、携帯キャリアの接続維持間隔７０２が最小であるか調べる（ステップ２０７）。携帯キャリアの接続維持間隔７０２が最小である場合、処理はステップ２１１に移行し、最小ではない場合には、処理はステップ２０８に移行する。

ステップ２１１において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、携帯キャリアの接続維持間隔７０２を採用する（ステップ２１１）。

一方、ステップ２０８においては、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、クラウド基盤の接続維持間隔９０２が最小であるか調べる（ステップ２０８）。クラウド基盤の接続維持間隔９０２が最小の場合には、処理はステップ２０９に移行し、最小でない場合には、ステップ２１０に移行する。

ステップ２０９において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、クラウド基盤の接続維持間隔９０２を採用する（ステップ２０９）。

ステップ２１０では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、最大接続維持間隔１００１を採用する。

一方、ステップ２１２において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続先としてＷｉｆｉ接続先を採用する。（ステップ２１２）。

そして、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、Ｗｉｆｉの接続維持間隔８０１、クラウド基盤の接続維持間隔９０２、最大接続維持間隔１００１を比較し、Ｗｉｆｉの接続維持間隔８０１が最小であるか調べる（ステップ２１３）。Ｗｉｆｉの接続維持間隔８０１が最小である場合、処理はステップ２１７に移行し、最小ではない場合には、処理はステップ２１４に移行する。

ステップ２１７において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、Ｗｉｆｉの接続維持間隔８０１を採用する（ステップ２１７）。

ステップ２１４においては、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、クラウド基盤の接続維持間隔９０２が最小であるか調べる（ステップ２１４）。クラウド基盤の接続維持間隔９０２が最小の場合には、処理はステップ２１５に移行し、最小でない場合には、ステップ２１６に移行する。

ステップ２１５において、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、クラウド基盤の接続維持間隔９０２を採用する（ステップ２１５）。

ステップ２１６では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持間隔として、最大接続維持間隔１００１を採用する。

ステップ２１８では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの接続・切断部３３Ｂ１が、これまでの処理で採用した接続先、接続維持間隔を利用して、配信装置２に接続する（ステップ２１８）。

＜接続中の接続信号送付処理＞
図１５は、第１の実施形態による、接続中の接続信号送付処理を説明するためのフローチャートである。

まず、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、一定時間無通信状態か否か判断する（ステップ３０１）。一定時間無通信状態に該当する場合、処理はステップ３０３に移行し、該当しない場合には、処理はステップ３０２に移行する。

ステップ３０２では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、無通信時間計測用変数をリセットし、再度、ステップ３０１において一定時間無通信状態となっているか判断する。

ステップ３０３では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、無通信時間計測用変数をインクリメントする（ステップ３０３）。

また、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、無通信時間計測用変数が接続維持間隔（７０２又は８０１）に到達したか否か判断する（ステップ３０４）。接続維持間隔に到達していない場合には、処理はステップ３０１に移行し、到達している場合には、処理はステップ３０５に移行する。

ステップ３０５では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂ（接続維持信号送信部３３Ｂ２００）は、配信装置２に対して接続維持信号を送付する（ステップ３０５）。

さらに、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、配信装置２からの応答信号を受信する前に、接続維持再送間隔テーブル３３Ｂ２０６に記述された接続維持再送間隔（再送時間間隔）１１０１が経過したか判断する（ステップ３０６）。接続維持再送間隔（再送時間間隔）１１０１が経過していない場合には、処理はステップ３０７に移行し、接続維持再送間隔（再送時間間隔）１１０１が経過している場合には、処理はステップ３０８に移行する。

ステップ３０７では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、再送回数をリセットし（ステップ３０７）、さらに、無通信時間計測用変数をリセットし（ステップ３０２）、処理をステップ３０１に移行させる。

ステップ３０８では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持信号を再送し（ステップ３０８）、再送回数に１加算し（ステップ３０９）する。

そして、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、接続維持再送回数テーブル３３Ｂ２０７に記述された再送回数の上限１２０１に達したか判断する（ステップ３１０）。上限に達した場合は、処理はステップ３１１に移行し、上限に達していない場合には、処理はステップ３０６に移行する。

ステップ３１１では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、当該接続の切断が意図しない切断である判断し、そのことを表すフラグを設定して、接続を切断する（ステップ３１１）。

＜再接続処理＞
図１６は、第１の実施形態による、接続中に切断が起こった場合の再接続処理を説明するためのフローチャートである。

ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの接続・切断部３３Ｂ１は、配信装置２との間に張られた接続を常に監視しており、切断が発生した場合に本処理を行う。

まず、接続・切断部３３Ｂ１は、発生した切断が意図しない切断か否か判断する（ステップ３５１）。ここで、ステップ３１１により発生した切断であれば、意図しない切断であることを表すフラグが設定されており、そうでない正常な切断であれば本フラグは設定されていない。

意図しない切断である場合、接続・切断部３３Ｂ１は、再度図１４の接続処理を実行する（ステップ３５２）。ここで、図１４の接続処理を再度行う際、既に読み込んでいるテーブルの読み込みは省略してもよい。

意図する切断ではなく、正常な切断である場合（フラグが設定されていない場合）、処理は終了する。

＜開発が必要な要素＞
図１７は、本発明の実施形態によるシステムにおいて開発が必要な要素を示す図である。
（i）図１７Ａは、サーバ側で、顧客毎または同一顧客のネットワーク構成要件の変更に対応するために必要な開発部分を表す模式図である。本発明が無ければ、ネットワーク構成に変更があれば、サーバ（配信装置２）側のシステム全体を設計、開発する必要があるが、本発明によると、斜線部分、つまり、送信内容リストテーブル２３Ｂ１及び送信先リストテーブル２３Ｂ２のみ変更すれば、サーバ（配信装置２）側は、ネットワーク構成要件の変更に対処することができるようになる。

（ii）図１７Ｂは、クライアント側で、顧客毎または同一顧客のネットワーク構成要件の変更に対応するために必要な開発部分を表す模式図である。上述同様、本発明が無ければ、ネットワーク構成に変更があれば、クライアント側のシステム全体を設計、開発する必要があるが、本発明によると、斜線部分、つまり、接続回線接続先テーブル３３Ｂ１００、Ｗｉｆｉ接続先テーブル３３Ｂ１０１、Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３、最大接続維持間隔テーブル３３Ｂ２０５、利用ネットワーク構成要素指定テーブル３３Ｂ２０８を変更すれば、クライアント側は、ネットワーク構成要件の変更に対処することができるようになる。なお、図１７Ｂでは、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂにおいて、その都度開発が不要な３３Ｂ２００などの要素は省略されている。

＜サーバ側のメッセージ送信処理＞
図１８は、サーバ（配信装置２）側で実行されるメッセージ送信処理を説明するためのフローチャートである。

ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃは、クライアントの状態がメッセージ送信してもＯＫか否か判断する（ステップ４０１）。ここでクライアントの状態とは、配信装置２とクライアント端末装置３との接続が確立・維持されていれば「ＯＫ」となり、切断状態であれば「ＮＧ」となる変数である。状態がＮＧであれば、処理はステップ４０２に移行し、状態がＯＫであれば、処理はステップ４０３に移行する。

ステップ４０２において、ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃは、送信不可を管理者端末装置１に返却する（ステップ４０２）。

ステップ４０３において、ＷｅｂＳｏｃｋｅｔサーバ側通信部２３Ｃは、メッセージをクライアント端末装置３に送信する。

＜送信設定画面例＞
図１９は、管理者端末装置１の表示部に表示される設定画面（ＧＵＩ）の例を示す図である。図１９Ａは送信先端末一覧画面例を示し、図１９Ｂは送信内容一覧画面例を示している。図１９Ｃは、送信設定画面例を示している。

（i）図１９Ａに示されるように、送信先端末一覧画面は、クライアント端末装置３を一意に特定・識別するための端末ＩＤ１９０１と、対応するクライアント端末装置３の利用者を示す利用者１９０２と、対応するクライアント端末装置３の状態を示す状態１９０３と、を構成要素として有している。

管理者は、この画面を表示部に表示させ、状態１９０３がＯＫとなっているクライアント端末装置３の中から、メッセージを送信したいものを選択して、配信装置２にメッセージ送信を指示することができるようになっている。

（ii）図１９Ｂに示されるように、送信内容一覧画面は、送信メッセージを一意に特定・識別するための送信内容ＩＤ１９０４と、メッセージの内容を示す送信内容１９０５と、を構成要素として有している。

管理者は、予め用意されている送信内容１９０５の中から所望のものと選択して、配信装置２が選択したクライアント端末装置３に選択したメッセージを送信するように指示することができる。送信内容１９０５は、説明の簡単化のため、ここでは固定としているが、その限りではない。従って、所望のメッセージが送信内容一覧画面にない場合には、図示しないメッセージ作成画面を表示し、管理者は所望のメッセージを作成することができるようにしても良い。

（iii）図１９Ｃに示される送信設定画面では、送信端末設定と送信コンテンツ設定が１つの画面内の選択操作で行うことができるようになっている。なお、図１９Ｂと同様に、送信コンテンツ（送信内容）は、予め固定でなくても良い。

（２）第２の実施形態
第２の実施形態は、複数種類のネットワークが混在する環境において、ネットワークの種類が動的に変更した場合に容易に対応できるようにするための技術を提供する。

＜適用場面＞
図２０は、第２の実施形態の適用場面を示すための模式図である。
図２０は、顧客構内でＷｉｆｉ網を利用し、顧客構外で携帯回線網を利用する場面を示している。この適用場面では、顧客構内から、顧客構外に移動時に、動的にネットワーク構成要素の変更が生じる。第２の実施形態は、この動的なネットワーク構成の変更に対応できるようにするシステムを提供するものである。

図２０では、管理者端末装置１が、インターネット４を介して配信装置２と接続されている。配信装置２は、インターネット４を介して、携帯キャリアＣ網１１３、顧客宅内のＬＡＮも含むＷｉｆｉ網６と接続されている。移動体１０１が顧客δ構内１１１内にある場合、その中のクライアント端末装置３は、Ｗｉｆｉ網６を介して配信装置２と通信を行う。一方、移動体１０１が顧客δ構外にある場合には、クライアント端末装置３は、携帯キャリアＣ網１１３を介して配信装置２と通信を行う。

＜配信システムの構成＞
図２１は、本発明の第２の実施形態による配信システムの概略構成を示す図である。
第２の実施形態による配信システムは、第１の実施形態による構成に加えて、さらに、ネットワーク種別自動判定部３３Ｆと、携帯キャリア自動判定部３３Ｇとを、有している。

ネットワーク種別自動判定部３３Ｆは、クライアント端末装置３のＯＳが有している情報を参照して、どのネットワークを利用しているか判定する処理を行う。また、携帯キャリア自動判定部３３Ｇは、ネットワーク種別自動判定部３３Ｆによって、携帯キャリア網を利用していると判定された場合に、同ＯＳの情報から、どのキャリアを利用しているかを判定する処理を実行する。その他の構成については、図２と同じであるため、説明は省略する。

＜接続処理＞
図２２は、第２の実施形態による、クライアント端末装置３が実行する接続処理を説明するためのフローチャートである。第２の実施形態による当該接続処理は、クライアント端末装置３を起動したとき、或いは、意図せぬ切断が発生したとき、配信装置２との接続を確立する処理を実行する際に、ネットワーク種別自動判別、及びネットワーク種別が携帯回線の場合は携帯キャリア自動判別を行うというものである。

図１４との違いは、ステップ２０２及び２０３が変更されてステップ９０１及び９０２となり、新たにステップ９０３乃至９０６が追加されている。従って、以下では、これらのステップのみについて説明する。

ステップ９０１及びステップ９０２では、それぞれ、読み込み対象及び取得対象をクラウド基盤のみに変更されている。第２の実施形態では、利用ネットワークを自動的に判別しているため、必要な情報はクラウド基盤についての情報のみだからである。

ステップ９０３では、ネットワーク種別自動判別部３３Ｆが、クライアント端末装置３のＯＳが保持している情報を参照し、ネットワーク種別の自動判別を行う。

ステップ９０４では、携帯キャリア自動判定部３３Ｇが、同様に、クライアント端末装置３のＯＳが保持している情報を参照し、携帯キャリア自動判別を行う。

ステップ９０５では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂが、該当する携帯キャリア接続維持間隔７０２（図７参照）を取得する。

ステップ９０６では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂが、該当するＷｉｆｉ接続維持間隔８０１（図８参照）を取得する。

以上のような処理を実行することにより、動的なネットワーク構成の変更に対応して接続処理を実行することができるようになる。

（３）第３の実施形態
第３の実施形態は、顧客の即時性（最大不通時間）要望値から、接続維持間隔を直接決める手段を提供する。

第１及び第２の実施形態では、クライアント端末装置３の利用者は、所望の接続維持間隔として、最大接続維持間隔１００１（図１０）を設定入力する必要がある。この最大接続維持間隔は、利用者からは分かりづらい概念であり、不慣れな利用者は間違って設定しまう場合もある。

そこで、本発明の第３の実施形態では、顧客から見て分かりやすい「最大不通時間」という観点から、接続維持間隔を決定する処理を行っていることに特徴がある。なお、配信システムの構成は、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの内部構成以外は、図２と同じであるため、説明は省略する。

＜ＷｅｂＳｏｃｋｅｔクライアント側通信部の内部構成＞
図２３は、第３の実施形態による、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂの内部構成を示す図である。

第１の実施形態との違いは、顧客から見てより分かりやすい概念である最大不通時間を入力値とするため、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂが、最大接続維持間隔テーブル３３Ｂ２０５の代わりに、最大不通時間テーブル３３Ｂ２０９を有している点である。

最大不通時間は、「最大接続維持間隔」に「最終送信時刻からの再送タイムアウト時間」を加算した値である。再送タイムアウト時間は、接続維持間隔後に実行される再送処理の間隔（再送間隔）×（接続維持再送上限回数＋１）で表される値である。

＜接続処理＞
図２４は、第３の実施形態による、クライアント端末装置が実行する接続処理を説明するためのフローチャートである。第１の実施形態による接続処理（図１４）との違いは、ステップ２０１を変更してステップ１１０１とし、ステップ１１０２を追加したことである。

ステップ１１０１では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、携帯キャリア別接続維持間隔テーブル３３Ｂ２０２と、Ｗｉｆｉ接続維持間隔テーブル３３Ｂ２０３と、クラウド基盤別接続維持間隔テーブル３３Ｂ２０４と、最大不通時間テーブル３３Ｂ２０９を読み込む。最大不通時間テーブルには、利用者が設定した最大不通時間要望値が記述されている。

ステップ１１０２では、ＷｅｂＳｏｃｋｅｔクライアント側通信部３３Ｂは、最大不通時間要望値から、最大接続維持間隔要望値を導出する。ここで、不通時間が最大となるのは、定期的な接続維持信号の送信成功の直後に切断が発生した場合である。この場合、上述のように、最大不通時間は、接続維持信号送信間隔と、「最終送信時刻からの再送タイムアウト値」の和で表される。よって、ステップ１１０２では、接続維持再送間隔と接続維持再送上限回数に１を加算した値を乗じることで得られる「最終送信時刻からの再送タイムアウト値」を、「最大不通時間要望値」から差し引くことで、最大接続維持間隔が算出される。

以上のようにして、クライアント端末装置３が自動的にその「最大不通時間」を「最大接続維持間隔」に変換するので、利用者は、より分かりやすい「最大不通時間」の要望値を入力するだけでよく、適切に接続処理を実行することが可能となる。

（４）変形例
（i）ＷｅｂＳｏｃｋｅｔプロトコルの代わりに、ＣＯＭＥＴと呼ばれるプロトコルでもよい。

（ii）上述の各実施形態では、電波不良のため、各ネットワーク装置のアイドル切断の通知などを受け取れず、クライアントが切断に気付かない問題に対する解決策としては、接続維持信号に対する応答が一定期間無い場合に接続を切断する再送タイマを設ける方法で解決を図っている。しかし、この代わりに、電波状況を監視することにより切断を判定したり、ネットワーク種別の変更を監視することにより切断を判定する手法を採ってもよい。

（iii）第２の実施形態を、ネットワーク構成要素の静的な変更の用途に使ってもよい。

（iv）第２の実施形態において、さらに変更されないことが分かっている場合には、自動判別の処理を省くため、自動判別対象の「ネットワーク種別」及び「携帯キャリア」の内、いずれかを固定値としてもよい。

（v）第３の実施形態において、動的に変更されるネットワーク種別のいずれか一方で、ＷｅｂＳｏｃｋｅｔではなくポーリング方式を採用してもよい。

（５）まとめ
（i）本発明は、サーバ装置（配信装置）から通信端末装置（クライアント端末装置）にメッセージをＷｅｂＳｏｃｋｅｔプロトコルでプッシュ送信するメッセージプッシュ配信システムに関する。当該システムにおいて、クライアント端末装置は、ネットワーク構成要素毎にネットワークの無通信タイマを回避するのに必要な接続維持間隔（携帯通信のキャリア別の接続維持間隔、クラウド基盤別の接続維持間隔、Ｗｉｆｉ通信の接続維持間隔）の情報（システム改変時でも変更不要な固定の情報）を事前に保持しておき、利用する構成要素を指定するだけで全要素の無通信タイマを回避できるように接続維持間隔の最小値を、接続維持間隔として採用する。このようにすることにより、顧客間で又は同一顧客によって利用されているネットワーク構成において、システム構成要素が静的に変わった場合でもシステム全体の接続維持間隔を、システム構成要素すべてに関し調べ直すことが不要となる。また、接続に必要な情報をネットワーク種別毎に分けて管理する構成とすることで、ネットワーク種別の静的変更に伴う接続先変更の作業量が軽減される。なお、当該システムでは、クライアント端末装置は、自動車等の乗り物に設置して利用することを想定している。

また、クライアント端末装置は、無通信となった後に一定期間、接続維持のための信号を配信装置に再送するが、それに対する応答が配信装置から無い場合に切断を行う再送タイマ手段と再接続を行う再接続手段を有している。これにより、電波が良好でない環境を含め一定の即時性を確保することができるようになる。

接続維持間隔の最小値を取得する際、クライアント端末装置は、携帯通信のキャリア別の接続維持間隔、クラウド基盤別の接続維持間隔、及びＷｉｆｉ通信の接続維持間隔の他に、利用者が指定する最大接続維持時間間隔（最低でもこの程度の接続維持間隔は満足すべきとする利用者の要望値）を含めて、最小値を判断するようにしている。これにより、電波が良好でない環境を含め、顧客の要望する即時性を確保することができるようになる。

本発明（第２の実施形態）では、クライアント端末装置は、携帯通信回線かＷｉｆｉかといったネットワーク種別を、クライアント端末装置が有するＯＳの保持情報を参照することにより自動判定し、さらに、ネットワーク種別が携帯通信回線の場合には自動で通信キャリアを判別する。このようにすることにより、動的にネットワーク種別、携帯キャリアが変更された際に、その変更を検知して再接続し、自動でネットワーク構成を切り替えることができるようになる。この場合、接続先アドレス、認証情報といった接続に必要な情報、そのネットワーク環境にあった接続維持間隔といった接続維持に必要な情報を自動で設定する。

また、本発明（第３の実施形態）では、利用者は、最大接続維持間隔の代わりに、顧客から見てより分かり易い概念である最大不通時間を入力値として設定する。そして、最大不通時間と接続維持信号再送間隔、接続維持信号再送回数から、最大接続維持間隔を算出する。このようにすることにより、利用者にとってより分かり易いシステムを提供することができる。

（ii）本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。

１・・・管理者端末装置
１１Ａ、２１Ａ、３１Ａ・・・ＣＰＵ
１１Ｂ、２１Ｂ、３１Ｂ・・・メモリ
１３、２３、３３・・・外部記憶装置
２・・・配信装置
３・・・クライアント端末装置
４・・・インターネット
５・・・携帯電話網
６・・・Ｗｉｆｉ網
１３Ａ・・・管理者操作送信部
１３Ｂ、３３Ｃ・・表示処理部
２３Ａ・・・管理者操作応答部
２３Ｂ・・・サーバ管理部
２３Ｃ・・・ＷｅｂＳｏｃｋｅｔサーバ側通信部
２３Ｂ１・・・送信内容リストテーブル
２３Ｂ２・・・送信先端末リストテーブル
３３Ａ・・・クライアント管理部
３３Ｂ・・・ＷｅｂＳｏｃｋｅｔクライアント側通信部
３３Ｄ・・・携帯回線接続部
３３Ｅ・・・Ｗｉｆｉ検索・接続部

Claims (15)

1. サーバ装置がプッシュ送信するメッセージを受け取る通信端末装置であって、
   プログラムに従って、ＷｅｂＳｏｃｋｅｔプロトコルを用いて前記サーバ装置からメッセージを受信し、前記サーバ装置に対してＷｅｂＳｏｃｋｅｔ接続維持のための信号を送信するプロセッサと、
   少なくとも、携帯電話通信キャリア別の接続維持間隔情報と、クラウド基盤別の接続維持間隔情報と、利用者が利用するネットワークの構成要素を示す利用ネットワーク構成情報と、を格納するメモリと、
   前記プロセッサは、前記利用ネットワーク構成情報に基づいて、前記利用者が現在利用している携帯電話通信キャリアの接続維持間隔及びクラウド基盤の接続維持間隔を特定する接続維持間隔特定処理と、当該特定した携帯電話通信キャリアの接続維持間隔とクラウド基盤の接続維持間隔の何れが最小かを判定する最小接続維持間隔判定処理と、最小の接続維持間隔を用いて前記サーバ装置との通信接続を確立する接続確立処理と、を実行し、
   前記携帯電話通信キャリア別の接続維持間隔情報及び前記クラウド基盤別の接続維持間隔情報は書き換え不要の固定の情報であり、前記利用ネットワーク構成情報は利用者毎に設定される情報であることを特徴とする通信端末装置。
2. 請求項１において、
   前記メモリは、さらに、前記利用者が最低でも満足すべきであると要求する接続維持間隔を示す最大接続維持間隔の情報を格納し、
   前記プロセッサは、前記接続維持間隔特定処理において、前記特定した携帯電話通信キャリアの接続維持間隔、前記特定したクラウド基盤の接続維持間隔、及び前記最大接続維持間隔のうち、何れが最小かを判定することを特徴とする通信端末装置。
3. 請求項２において、
   前記メモリは、さらに、変更可能なＷｉｆｉ通信の接続維持間隔情報を格納し、
   前記プロセッサは、さらに、前記利用ネットワーク構成情報を参照して、前記利用者が現在利用しているネットワークが携帯電話通信網かＷｉｆｉ通信網か判定する処理と、利用ネットワークがＷｉｆｉ通信網の場合に、前記Ｗｉｆｉ通信の接続維持間隔、及び前記クラウド基盤の接続維持間隔を特定する処理と、当該特定したＷｉｆｉ通信の接続維持間隔、前記クラウド基盤の接続維持間隔、及び前記最大接続維持間隔の何れが最小かを判定する処理と、を実行することを特徴とする通信端末装置。
4. 請求項２において、
   前記メモリは、さらに、前記ＷｅｂＳｏｃｋｅｔ接続維持のための信号の再送間隔及び再送回数を規定する再送処理関連情報を格納し、
   前記再送処理関連情報は書き換え不要の固定の情報であり、
   前記プロセッサは、さらに、一定時間の無通信状態を検知した場合に、前記再送間隔及び前記再送回数に従って、前記ＷｅｂＳｏｃｋｅｔ接続維持のための信号を再送する処理と、前記再送回数の上限に達した場合には、前記利用者が意図しないＷｅｂＳｏｃｋｅｔ通信の切断であることを示すフラグ情報を前記通信端末装置内に設定することを特徴とする通信端末装置。
5. 請求項４において、
   前記プロセッサは、前記フラグ情報を参照して直近の通信切断が前記利用者の意図しない切断であると判断する処理を実行し、
   前記プロセッサは、前記通信切断が前記利用者の意図しない切断である場合に、前記接続維持間隔特定処理、前記最小接続維持間隔判定処理、及び前記接続確立処理を実行することを特徴とする通信端末装置。
6. 請求項２において、
   前記メモリは、さらに、変更可能なＷｉｆｉ通信の接続維持間隔情報を格納し、
   前記プロセッサは、さらに、前記通信端末装置のＯＳを参照して、前記利用者が現在利用しているネットワークが携帯電話通信網かＷｉｆｉ通信網か判定する処理と、利用ネットワークがＷｉｆｉ通信網の場合に、前記Ｗｉｆｉ通信の接続維持間隔、及び前記クラウド基盤の接続維持間隔を特定する処理と、当該特定したＷｉｆｉ通信の接続維持間隔、前記クラウド基盤の接続維持間隔、及び前記最大接続維持間隔の何れが最小かを判定する処理と、を実行することを特徴とする通信端末装置。
7. 請求項１において、
   前記メモリは、さらに、前記利用者が設定した通信の最大不通時間の情報を格納し、
   前記プロセッサは、さらに、前記最大不通時間から前記利用者が要求する最大接続維持間隔を算出する処理を実行し、
   前記プロセッサは、前記接続維持間隔特定処理において、前記特定した携帯電話通信キャリアの接続維持間隔、前記特定したクラウド基盤の接続維持間隔、及び前記算出した最大接続維持間隔のうち、何れが最小かを判定することを特徴とする通信端末装置。
8. 請求項１の通信端末装置と、
   前記通信端末装置に対してＷｅｂＳｏｃｋｅｔ通信を用いてメッセージをプッシュ送信するサーバ装置と、
   前記サーバ装置に対して、送信すべきメッセージの内容と当該メッセージを送信すべき対象である通信端末装置を指示する管理者端末装置と、
   を有することを特徴とするメッセージ配信システム。
9. メッセージをプッシュ送信するサーバ装置と、当該メッセージを受け取る通信端末装置との間で実行される通信方法であって、
   前記通信端末装置は、プログラムに従って、ＷｅｂＳｏｃｋｅｔプロトコルを用いて前記サーバ装置からメッセージを受信し、前記サーバ装置に対してＷｅｂＳｏｃｋｅｔ接続維持のための信号を送信するプロセッサと、少なくとも、携帯電話通信キャリア別の接続維持間隔情報と、クラウド基盤別の接続維持間隔情報と、利用者が利用するネットワークの構成要素を示す利用ネットワーク構成情報と、を格納するメモリと、を有し、
   前記通信方法は、
   前記プロセッサが、前記利用ネットワーク構成情報に基づいて、前記利用者が現在利用している携帯電話通信キャリアの接続維持間隔及びクラウド基盤の接続維持間隔を特定する接続維持間隔特定ステップと、
   前記プロセッサが、前記特定した携帯電話通信キャリアの接続維持間隔とクラウド基盤の接続維持間隔の何れが最小かを判定する最小接続維持間隔判定ステップと、
   前記プロセッサが、最小の接続維持間隔を用いて前記サーバ装置との通信接続を確立する接続確立ステップと、を有し、
   前記携帯電話通信キャリア別の接続維持間隔情報及び前記クラウド基盤別の接続維持間隔情報は書き換え不要の固定の情報であり、前記利用ネットワーク構成情報は利用者毎に設定される情報であることを特徴とする通信方法。
10. 請求項９において、
    前記メモリは、さらに、前記利用者が最低でも満足すべきであると要求する接続維持間隔を示す最大接続維持間隔の情報を格納し、
    前記接続維持間隔特定ステップにおいて、前記プロセッサは、前記特定した携帯電話通信キャリアの接続維持間隔、前記特定したクラウド基盤の接続維持間隔、及び前記最大接続維持間隔のうち、何れが最小かを判定することを特徴とする通信方法。
11. 請求項１０において、
    前記メモリは、さらに、変更可能なＷｉｆｉ通信の接続維持間隔情報を格納し、
    前記通信方法は、さらに、
    前記プロセッサが、前記利用ネットワーク構成情報を参照して、前記利用者が現在利用しているネットワークが携帯電話通信網かＷｉｆｉ通信網か判定するステップと、
    前記プロセッサが、利用ネットワークがＷｉｆｉ通信網の場合に、前記Ｗｉｆｉ通信の接続維持間隔、及び前記クラウド基盤の接続維持間隔を特定するステップと、
    前記プロセッサが、前記該特定したＷｉｆｉ通信の接続維持間隔、前記クラウド基盤の接続維持間隔、及び前記最大接続維持間隔の何れが最小かを判定するステップと、
    を有することを特徴とする通信方法。
12. 請求項１０において、
    前記メモリは、さらに、前記ＷｅｂＳｏｃｋｅｔ接続維持のための信号の再送間隔及び再送回数を規定する再送処理関連情報を格納し、
    前記再送処理関連情報は書き換え不要の固定の情報であり、
    前記通信方法は、さらに、
    前記プロセッサが、一定時間の無通信状態を検知した場合に、前記再送間隔及び前記再送回数に従って、前記ＷｅｂＳｏｃｋｅｔ接続維持のための信号を再送するステップと、
    前記プロセッサが、前記再送回数の上限に達した場合には、前記利用者が意図しないＷｅｂＳｏｃｋｅｔ通信の切断であることを示すフラグ情報を前記通信端末装置内に設定するステップと、
    を有することを特徴とする通信方法。
13. 請求項１２において、さらに、
    前記プロセッサが、前記フラグ情報を参照して直近の通信切断が前記利用者の意図しない切断であると判断するステップと、
    前記プロセッサが、前記通信切断が前記利用者の意図しない切断である場合に、前記接続維持間隔特定ステップ、前記最小接続維持間隔判定ステップ、及び前記接続確立ステップを実行することを特徴とする通信方法。
14. 請求項１０において、
    前記メモリは、さらに、変更可能なＷｉｆｉ通信の接続維持間隔情報を格納し、
    前記通信方法は、さらに、
    前記プロセッサが、前記通信端末装置のＯＳを参照して、前記利用者が現在利用しているネットワークが携帯電話通信網かＷｉｆｉ通信網か判定するステップと、
    前記プロセッサが、利用ネットワークがＷｉｆｉ通信網の場合に、前記Ｗｉｆｉ通信の接続維持間隔、及び前記クラウド基盤の接続維持間隔を特定するステップと、
    前記プロセッサが、前記特定したＷｉｆｉ通信の接続維持間隔、前記クラウド基盤の接続維持間隔、及び前記最大接続維持間隔の何れが最小かを判定するステップと、
    を有することを特徴とする通信方法。
15. 請求項９において、
    前記メモリは、さらに、前記利用者が設定した通信の最大不通時間の情報を格納し、
    前記通信方法は、さらに、
    前記プロセッサが、前記最大不通時間から前記利用者が要求する最大接続維持間隔を算出するステップと、を有し、
    前記プロセッサは、前記接続維持間隔特定ステップにおいて、前記特定した携帯電話通信キャリアの接続維持間隔、前記特定したクラウド基盤の接続維持間隔、及び前記算出した最大接続維持間隔のうち、何れが最小かを判定することを特徴とする通信方法。

Images