JP5739370B2 - メッセージ配信システム、及びメッセージ配信方法 - Google Patents

Description

本発明は、メッセージ配信システム、及びメッセージ配信方法に関し、例えば、WebSocketプロトコルを利用したプッシュ型配信に関するものである。

サーバからクライアント端末に、メッセージをプッシュ配信する方法として、SMS方式、WebSocket方式などがある。SMS方式については、例えば、特許文献１及び非特許文献１に開示されている。また、WebSocket方式については、例えば、非特許文献２に示されるように、IETFによりRFC6455として開示されている。

一般にSMS方式は、非特許文献１に示されるように、通信事業者が提供するものであり、電話回線契約が必要であるため、一般に料金が高い。一方、WebSocket方式は、電話回線契約が不要で、パケット通信費用のみであるためSMSに比べ低額である。

WebSocket方式は、通信を行う２者間で接続を維持することを特徴とする。ただし、経由するネットワーク装置は、非特許文献３に示されるように、負荷軽減のため、無通信状態が一定時間に達すると切断を行うというアイドルタイマの機能を備えているものがある。

特願2000-297920号公報

メール／基本／メール種別（http://www.jpo.go.jp/shiryou/s_sonota/hyoujun_gijutsu/keitai/3-1-1.pdf） Internet Engineering Task Force (IETF), I. Fette, Google, Inc. and A. Melnikov, Isode Ltd., December 2011 （http://tools.ietf.org/html/rfc6455） Cosminexus アプリケーションサーバ V8 機能解説 基本・開発編(コンテナ共通機能)（http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d3U0740/EU070179.HTM）

上述のアイドルタイマによる切断を防ぐため、WebSocketの利用者は、一般的に、送るべきメッセージが無くても無通信状態が一定時間経過すると接続維持のためのパケットを送付する。また、この接続維持パケットを送付し、それによる接続確認動作が失敗することにより、電波状況の悪化に伴った切断を検知できるという意味において、接続維持パケットの送付は重要である。WebSocketはクライアント端末からサーバに接続を開始する方式であるため、サーバからメッセージを送るには、クライアント端末側で切断検知し、接続を再度行う必要があるからである。

また、顧客の要望として即時性と通信パケット量削減が存在する。これらにはトレードオフの関係がある。この即時性と通信パケット量削減と、接続維持パケットの間隔（以下、WebSocket接続維持間隔）の関係について記述する。つまり、WebSocket接続維持間隔が短いと、切断検知できる間隔が狭まるため、即時性が上がるが、通信パケット量は多くなる。一方、WebSocket接続維持間隔が長いと、切断検知できる間隔が広がるため、即時性が下がるが、通信パケット量は少なくなる。

ところが、即時性のあるサービスを顧客ごとに提供するためのプッシュシステムの開発に掛かる作業量は大きくなってしまう。つまり、顧客の即時性とパケット使用量削減の重視度合いに応じたシステム設計及び開発をその都度行う必要があるが、これを軽減する仕組みは開示されていない。

本発明はこのような状況に鑑みてなされたものであり、通信の即時性と通信パケット量削減とのバランスを取り、かつ各顧客の要望に応じたシステム設計及び開発のための作業量を削減することを可能にする技術を提供するものである。

上記課題を解決するために、本発明によるメッセージ配信システムは、配信装置から少なくとも１つのクライアント端末装置にメッセージを送信する。クライアント端末装置は、通信の即時性とパケット量削減の重視度合いを示すモード情報を保持するモード情報保持部と、モード情報を解釈し、配信装置との間においてWebSocket通信方式を用いること、さらに、WebSocketの接続維持方式、及びWebSocketの接続維持間隔を決定するクライアント管理部と、決定されたWebSocket通信方式で配信装置と通信を行い、決定されたWebSocketの接続維持方式及びWebSocketの接続維持間隔によって配信装置との接続を維持するクライアント通信部と、を有する。配信装置は、決定されたWebSocket通信方式によってクライアント端末装置に対してメッセージを送信し、決定されたWebSocketの接続維持方式及びWebSocketの接続維持間隔に従って、クライアント端末装置からの接続維持要求に対する応答処理を実行する、サーバ通信部を有する。

本発明によれば、通信の即時性と通信パケット量削減とのバランスを取り、かつ各顧客の要望に応じたシステム設計及び開発のための作業量を削減することが可能となる。

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

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

本発明の第１の実施形態によるメッセージ配信システムの概略構成を示す図である。 本発明の実施形態によるWebSocketサーバ側通信部の機能構成を示す図である。 本発明の実施形態によるWebSocketクライアント側通信部の機能構成を示す図である。 管理者応答部またはクライアント管理部が、それぞれサーバ、或いは端末の起動時に、各モードテーブルを読み込み、通信方式、接続維持方式、及び接続維持間隔を決定する処理を説明するためのフローチャートである。 本発明のサーバ側において、システム毎に必要な開発部分を表すための模式図である。 本発明のクライアント側において、システム毎に必要な開発部分を表すための模式図である。 クライアント端末装置の起動時の処理を説明するためのフローチャートである。 配信装置によるメッセージ送信処理を説明するためのフローチャートである。 管理者端末装置に表示される、送信先端末一覧画面例を示す図である。 管理者端末装置に表示される、送信内容一覧画面例を示す図である。 管理者端末装置に表示される、サーバ側モードテーブル表示画面例を示す図である。 管理者端末装置に表示される、送信用画面例を示す図である。 本発明の第２の実施形態によるメッセージ配信システムの概略構成を示す図である。 第２の実施形態によるモード変更処理を説明するためのフローチャートである。 本発明の第３の実施形態によるメッセージ配信システムの概略構成を示す図である。 第３の実施形態によるサーバ側モードテーブルの例を示す図である。 ネットワーク装置のアイドルタイマが短くなった場合に備えた、接続維持間隔の自動調整処理を説明するためのフローチャートである。 ネットワーク装置のアイドルタイマが長くなった場合に備えた、接続維持間隔の自動調整処理を説明するためのフローチャートである。

現在、それぞれの顧客の要望に応えるために、顧客毎に、通信方式の設計、WebSocket接続維持方式の設計、WebSocket接続維持間隔の設計、及びシステム全体の開発といった作業が行われている。本発明は、このような作業を軽減し、通信事業者の方針変更などによるアイドルタイムアウト時間の変更時に、容易に対応する仕組みを有するプッシュ配信技術を提案する。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。また、SMS通信方式も一緒に記述する例を示しているが、必ずしも必要ではなく、WebSocket通信方式のみ備えていれば十分である。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

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

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

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

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

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

ところで、WebSocket接続維持方式には、キープアライブとハートビートの２つの方式がある。ここで、キープアライブとは、送信元から受信先に対し、あるパケットを投げ、受信先から応答パケットを受け取るという通信を行うことで、ネットワーク上でパケットが消滅した場合に応答パケットが来ないことでこれを検知し、リトライを行うことができる接続維持方式である。一方、ハートビートとは、送信元から受信先に対し、あるパケットを投げるだけの方式である。ネットワーク上でパケットが消滅した場合接続の維持がなされない危険性がある半面、パケット量はキープアライブと比べ少なくて済む。

また、ここでは、３つの実施形態を例に挙げて本発明について説明する。第１の実施形態は、WebSocket通信方式、WebSocket接続維持方式、WebSocket接続維持間隔といった、複雑処理を内部に隠ぺいし、即時性とパケット量削減の重視度合い（以下、モード）を入力インターフェースとすることで顧客毎に必要な設計と開発の量を減らすためのものである。ここでは、上述のとおり、トレードオフの関係にある即時性とパケット量削減に関し、即時性最優先、即時性優先、省パケット優先、省パケット最優先という４つに分類する例で説明する。第２の実施形態は、モードを遠隔から変更するための形態である。第３の実施形態は、WebSocket接続維持間隔を、自動で調整するためのものである。

本発明では、顧客毎にシステム（通信システム）全体を設計及び開発するのではなく、ミドルウェアを作成し、その上で動作するアプリケーションのみを顧客毎に作り替えていくような携帯を想定している。アプリケーションは全体のシステムから比べたら開発に占める割合が少なくて済む。アプリケーションからミドルウェアに対しては即時性とパケット量の重要度合に関する情報が与えられ、ミドルウェアがその情報に基づいて接続維持間隔を決定するようになっている。

（１）第１の実施形態
＜通信システムの構成＞
図１Ａは、本発明の第1の実施形態による通信システム（メッセージ配信システム、或いは、配信システムとも言う）の概略構成を示す図である。通信システムは、少なくとも１つの管理端末装置１と、少なくとも１つの配信装置２と、少なくとも１つのクライアント端末装置３と、を有する。当該実施形態では、管理端末装置１と配信装置２はネットワーク（インターネット）４を介して接続される。また、配信装置２とクライアント端末装置はネットワーク４及び電話網５を介して接続される。管理端末装置１は、例えば、宅配サービスにおける管理センタに相当し、配信装置２は配信サービス業者の情報配信サーバに相当し、クライアント端末装置３は宅配車に搭載された車載用端末装置に相当する。

各クライアント端末装置３は、最初に（例えば、毎朝９：００に）配信装置３にアクセスし、まずコネクションを成立させ、その後そのコネクションを維持するような処理が配信装置２及び各クライアント端末装置３との間で行われることになる。

管理者端末装置１は、クライアント端末装置３に配信装置２を介してメッセージを配布する装置である。管理者端末装置１は、ＣＰＵ（単に、プロセッサということもできる）１１Ａ及びメモリ１１Ｂを含む処理装置１１と、通信ポート１２と、外部記憶装置１３と、を有している。外部記憶装置１３は、管理者からのメッセージの送信などの操作を配信送信に対し命令するための管理者操作送信部１３Ａ（管理者操作送信プログラム）と、送信結果などを表示するための処理を行う表示処理部１３Ｂ（表示プログラム）と、を格納している。なお、管理者端末装置１は、図１Ａには図示されてはいないが、ディスプレイ等の表示装置も有している。また、ＣＰＵ１１Ａが各プログラムを読み込んで、各プログラムに対応する機能を実現する。

配信装置２は、管理者端末装置１からの要求に応答してクライアント端末装置３にメッセージを配信する装置であると共に、後述のようにクライアント端末装置３との間でWebSocket接続維持間隔を変更する処理を行う装置である。配信装置２は、ＣＰＵ２１Ａ及びメモリ２１Ｂを含む処理装置２１と、通信ポート２２と、外部記憶装置２３と、を有している。外部記憶装置２３は、管理者操作（メッセージ送信要求）に対する応答を管理者端末装置１に返すための管理者操作応答部２３Ａ（管理者操作応答プログラム）と、同装置内の処理を取りまとめるサーバ管理部２３Ｂ（サーバ管理プログラム）と、WebSocketでメッセージ送付するためのWebSocketサーバ側通信部２３Ｃ（WebSocketサーバ側通信プログラム）と、ＳＭＳ方式でメッセージ送付するためのＳＭＳ送信部２３Ｄ（ＳＭＳ送信プログラム）と、を格納している。ＣＰＵ２１Ａが各プログラムを読み込んで、各プログラムに対応する機能を実現する。

サーバ管理部２３Ｂは、頻繁に送付するメッセージ内容を保持する送信内容リストテーブル２３Ｂ１と、クライアント端末装置３の情報を保持する送信先端末リストテーブル２３Ｂ２と、管理する全てのクライアント端末装置３のモードの情報を保持するサーバ側モードテーブル２３Ｂ３と、を有する。

クライアント端末装置３は、ＣＰＵ３１Ａ及びメモリ３１Ｂを含む処理装置３１と、通信ポート３２と、外部記憶装置３３と、を有している。外部記憶装置３３は、モードを保存するクライアント側モードテーブル３３Ａ１を保有し、クライアント端末装置３内の処理を取りまとめるクライアント管理部３３Ａ（クライアント管理プログラム）と、WebSocketで通信を行うためのWebSocketクライアント側通信部３３Ｂ（WebSocketクライアント側通信プログラム）と、ＳＭＳ方式で通信するためのＳＭＳ受信部３３Ｃ（ＳＭＳ受信プログラム）と、配信装置２から配信されたメッセージを表示するための表示処理部３３Ｄ（表示処理プログラム）と、を格納している。なお、クライアント端末装置３は、図１Ａには図示されてはいないが、ディスプレイ等の表示装置も有している。また、ＣＰＵ３１Ａが各プログラムを読み込んで、各プログラムに対応する機能を実現する。

当該実施形態では、説明を簡単にするため、送信されるメッセージは固定となっており、管理者が表示装置に表示される固定のメッセージを選択するようになっているが、管理者が作成した任意のメッセージを、配信装置２を介して各クライアント端末装置３に配信するようにしても良い。

＜WebSocketサーバ側通信部、及びWebSocketクライアント側通信部の機能構成＞
図１Ｂは、WebSocketサーバ側通信部２３Ｃの機能構成を示す図である。
WebSocketサーバ側通信部２３Ｃは、WebSockeクライアント側通信部３３Ｂからの接続・切断要求に対し、応答するための接続・切断応答部２３Ｃ１と、WebSocketクライアント通信部３３ＢからのWebSocket接続を維持するためのパケットに対する応答をするための処理を提供するWebSocket接続維持応答部２３Ｃ２と、メッセージ送信を行うメッセージ送信部２３Ｃ３と、を有している。WebSocket接続維持応答部２３Ｃ２は、キープアライブのパケットに対して応答するためのキープアライブ応答部２３Ｃ２００と、ハートビートのパケットを受信するためのハートビート受信部２３Ｃ２０１と、を含んでいる。

図１Ｃは、WebSocketクライアント側通信部３３Ｃの機能構成を示す図である。
WebSocketクライアント側通信部３３Ｃは、WebSocketサーバ側通信部２３Ｃに対して、接続・切断要求を出すための接続・切断部３３Ｃ１と、WebSocketサーバ側通信部２３Ｃに対して、WebSocket接続の維持を実現するためのWebSocket接続維持部３３Ｃ２と、メッセージ受信を行うメッセージ受信手段３３Ｃ３と、を有する。WebSocket接続維持部３３Ｃ２は、キープアライブを行うためのキープアライブ部３３Ｃ２００と、ハートビートを行うためのハートビート部３３Ｃ２０１と、WebSocket接続維持間隔の情報を保持する接続維持間隔テーブル３３Ｃ２０２と、を含んでいる。キープアライブ方式及びハートビート方式の何れかを選ぶことも即時性及びパケット通信量の関係を決定し、また、接続維持間隔の長短も即時性及びパケット通信量の関係を決定する。従って、本実施形態による接続維持の方法には、２×２＝４通りのパターンがあることになる。

なお、WebSocketは、サーバからクライアント側のみといった一方向の通信だけでなく、逆方向も含めた双方向を特徴とするプロトコルである。従って、メッセージ送信部２３Ｃ３及びメッセージ受信部３３Ｃ３は、本来は送受信する機能を有する通信手段であるが、実施形態では、説明の簡便化のため、配信装置（サーバ）２からクライアント端末３に一方向であるかのように、記述することとする。

＜通信方式及び接続維持間隔の設定処理＞
図２は、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれが、配信装置（サーバ）２及びクライアント端末装置３の起動時に、各モードテーブルを読み込み、接続維持間隔及び通信方式を決定する処理を説明するためのフローチャートである。当該処理は、配信装置２と各クライアント端末装置３との組み合わせにおいて実行される処理である。

サーバ管理部２３Ｂ及びクライアント管理部３３Ａは、それぞれサーバ側モードテーブル２３Ｂ３或いはクライアント側モードテーブル３３Ａ１を参照し、対象の端末に設定されているモードが「即時性最優先」かどうかを調べる（ステップ２０１）。

モードが「即時性最優先」である場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、送信方式を「ＳＭＳ」、接続維持方式を「無し」、接続維持間隔を「無し」に設定する（ステップ２０２）。その後、処理はステップ２０９に移行する。

モードが「即時性最優先」でない場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、モードが「即時性優先」かどうかを調べる（ステップ２０３）。

モードが「即時性優先」である場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、送信方式を「WebSocket」、接続維持方式を「キープアライブ」、接続維持間隔を「短期間」（予め設定されている時間）に設定する（ステップ２０４）。その後、処理はステップ２０９に移行する。

モードが「即時性優先」でない場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、モードが「省パケット優先又は指定なしか」どうかを調べる（ステップ２０５）。モードが「省パケット優先又は指定なし」である場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、送信方式を「WebSocket」、接続維持方式を「キープアライブ」、接続維持間隔を「長期間」（予め設定されている上記「短期間」よりも長い時間）に設定する（ステップ２０６）。その後、処理はステップ２０９に移行する。

モードが「省パケット優先」でも「指定なし」でもない場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、モードが「省パケット最優先」かどうかを調べる（ステップ２０７）。モードが「省パケット最優先」である場合、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、送信方式を「WebSocket」、接続維持方式を「ハートビート」、接続維持間隔を「長期間」に設定する（ステップ２０８）。その後、処理はステップ２０９に移行する。

ステップ２０９では、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、ステップ２０１から２０８で設定された送信方式が「WebSocket」かどうかをチェックする。

ステップ２０９において送信方式が「WebSocket」であると判断された場合、サーバ管理部２３ＢはWebSocketサーバ側通信部２３Ｃを利用し、クライアント管理部３３ＡはWebSocketクライアント側通信部３３Ｂを利用するように設定する（ステップ２１０）。その後、処理はステップ２１１に移行する。

ステップ２０９において送信方式が「WebSocket」ではないと判断された場合、サーバ管理部２３ＢはＳＭＳ送信部２３Ｄを利用し、クライアント管理部３３ＡはＳＭＳ受信部３３Ｃを利用するように設定する（ステップ２１５）。その後、処理は終了する。

ステップ２１１において、サーバ管理部２３Ｂ及びクライアント管理部３３Ａのそれぞれは、ステップ２０１から２０８で設定された接続維持方式が「キープアライブ」か否か調べる（ステップ２１１）。

ステップ２１１において送信方式が「キープアライブ」であると判断された場合、サーバ管理部２３Ｂはキープアライブ応答部２３Ｃ２００を利用し、クライアント管理部３３Ａはキープアライブ部を利用するように設定する（ステップ２１２）。その後、処理はステップ２１４に移行する。

ステップ２１１において送信方式が「キープアライブ」ではないと判断された場合、サーバ管理部２３Ｂはハートビート受信部２３Ｃ２０１を利用し、クライアント管理部３３Ａはハートビート部３３Ｃ２０１を利用するように設定する（ステップ２１３）。その後、処理はステップ２１４に移行する。

ステップ２１４では、クライアント管理部３３Ａは、ステップ２０１から２０８で設定された接続維持間隔を利用するように設定（接続維持間隔テーブルに設定値を保持）する（ステップ２１４）。そして、通信方式及び接続維持間隔の設定処理は終了する。

＜開発が必要な部分＞
図３Ａ及びＢは、配信装置（サーバ）２側及びクライアント端末装置３側で、システム毎に必要な開発部分を表すための模式図である。本発明によらない場合には、システム全体を設計、開発する必要があることは前述の通りである。

図３Ａにおいて、管理者操作応答部２３Ａ、サーバ管理部２３Ｂ、WebSocketサーバ側通信部２Ｃ、及びＳＭＳ送信部２３Ｄはミドルウェアとして構成される。一方、送信内容リストテーブル２３Ｂ１、送信先リストテーブル２３Ｂ２、及び２３Ｂ３は、顧客毎に適宜変更して用いられる構成である。従って、配信装置２では、顧客毎にシステム全体を開発する必要はなく、顧客毎に、送信内容リストテーブル２３Ｂ１、送信先リストテーブル２３Ｂ２、及びサーバ側モードテーブル２３Ｂ３のみを設定すれば良い。

図３Ｂは、クライアント端末装置３側で、システム毎に必要な開発部分を表すための模式図である。
図３Ｂにおいて、クライアント管理部３３Ａ、WebSocketクライアント側通信部３３Ｂ、ＳＭＳ受信部３３Ｃ、及び表示処理部３３Ｄはミドルウェアとして構成される。一方、クライアント側モードテーブル３３Ａ１は、顧客毎に適宜変更して用いられる構成である。したがって、クライアント端末装置３では、顧客毎にシステム全体を開発する必要はなく、顧客毎に、送信内容リストテーブル２３Ｂ１、送信先リストテーブル２３Ｂ２、及びサーバ側モードテーブル２３Ｂ３のみを設定すれば良い。

＜クライアント端末機能時の処理＞
図４は、クライアント端末装置３を起動する時に実行される処理を説明するためのフローチャートである。

クライアント管理部３３Ａは、クライアント側モードテーブル３３Ａ１を参照して、送信方式が「WebSocket」であるか否か調べる（ステップ４０１）。

送信方式が「WebSocket」であると判断されると、クライアント管理部３３Ａは、接続維持方式及び接続維持間隔をクライアント側モードテーブル３３Ａ１において指定されている通りに設定する（ステップ４０２）。

そして、クライアント管理部３３Ａは、接続・切断部３３Ｃ１を用いて、配信装置２に接続し（ステップ４０３）、処理を終了する。

一方、送信方式が「WebSocket」ではないと判断されると、クライアント管理部３３Ａは、ＳＭＳ通信部３３Ｃを有効にして受信待ち受けが可能なようにする（ステップ４０４）。

＜メッセージ送信処理＞
図５は、配信装置２によるメッセージ送信処理を説明するためのフローチャートである。
サーバ管理部２３Ｂは、クライアント端末装置３からの接続が維持されているか（状態がＯＫ）か否か調べる（ステップ５０１）。

状態がＯＫでないと判断した場合、サーバ管理部２３Ｂは、配信装置２の内部において送信不可の処理（ミドルウェアからメッセージ送信の指示を出すアプリケーションに送信不可を返す処理）を実行する（ステップ５０２）。

状態がＯＫであると判断した場合、さらに、サーバ管理部２３Ｂは、サーバ側モードテーブル２３Ｂ３を参照し、送信方式が「WebSocket」であるか否かを調べる（ステップ５０３）。

送信方式が「WebSocket」である場合、WebSocketサーバ側通信部２３Ｃが管理者端末装置１から指定されたメッセージをクライアント端末装置３に送信する（ステップ５０４）。

一方、送信方式が「WebSocket」ではない場合、ＳＭＳ送信部２３Ｄが、指定されたメッセージをクライアント端末装置３に送信する（ステップ５０５）。

＜各テーブルの内容＞
図６Ａは、送信先端末リストテーブルの例を示す図である。ここでは、管理者端末装置１の表示装置上に一覧画面例として表示されている。

送信先端末リストテーブル２３Ｂ２は、対象のクライアント端末装置３を一意に特定・識別するための情報である端末ＩＤと、そのクライアント端末装置３の利用者を示す情報と、配信装置２と接続が維持されている状態か否か示す情報と、を構成項目として有している。

管理者端末装置１では、管理者によって表示された一覧画面上でメッセージを送信する端末が選択される。

図６Ｂは、送信内容リストテーブルの例を示す図である。ここでは、管理者端末装置１の表示装置上に送信内容一覧画面例として表示されている。

送信内容リストテーブル２３Ｂ１は、送信内容を一意に特定・識別するための情報である送信内容ＩＤと、送信すべきメッセージの内容を示す送信内容と、を構成項目として有している。なお、上述したように、送信コンテンツは、あらかじめ固定ではなく、管理者が任意に作成するようにしても良い。

図６Ｃは、サーバ側モードテーブルの例を示す図である。ここでは、管理者端末装置１の表示装置上にサーバ側モードテーブル表示画面として表示されている。

サーバ側モードテーブル２３Ｂ３は、対象のクライアント端末装置３を一意に特定・識別するための情報である端末ＩＤと、モードと、を構成項目として有している。管理者端末装置１において、管理者は、サーバ側モードテーブル表示画面を参照することにより、各クライアント端末装置３のモードを確認することができる。

なお、クライアント側モードテーブル３３Ａ１は、サーバ側モードテーブル２３Ｂ３のうち当該クライアント端末装置に対応する一行の情報のみを保持している。

＜送信用画面例＞
図６Ｄは、管理者端末装置１における送信用画面例を示す図であり、送信先端末及び送信コンテンツの指定の様子を示している。

送信用画面は、送信先端末を選択する画面と、送信コンテンツを選択する画面と、を含んでいる。なお、送信コンテンツは、上述のように、あらかじめ固定でなく、任意に作成できるようにしても良い。その場合、送信コンテンツの領域が例えばメッセージボックスのように構成され、管理者がそこに自由に所望のメッセージを入力できるようになっている。

（２）第２の実施形態
通信業者の方針変更などにより、通信事業者が有するネットワーク装置のアイドルタイムアウト時間が変わることがある。このような事態に対応するためのフィールドサポート員による作業もしくは端末の回収の作業が発生することがある。第２の実施形態は、これを軽減する仕組みを提案するものである。

＜通信システムの構成＞
図７は、本発明の第２の実施形態による通信システムの概略構成を示す図である。第２の実施形態による通信システムは、第１の実施形態の構成に、サーバ側モードテーブル管理部２３Ｅ、サーバ側モード変更成否送信部２３Ｆ、クライアント側モードテーブル管理部３３Ｅ、及びクライアント側モード変更成否送信部を追加した構成となっている。

＜モード変更処理＞
図８は、モード変更処理を説明するためのフローチャートである。
まず、サーバ側モードテーブル管理部２３Ｅは、管理者端末１からの要求に応答して、指定のクライアント端末装置の状態をメンテナンス中にし、モード変更要求を対象のクライアント端末装置３に送信する（ステップ８０１）。

クライアント端末装置３は、配信装置２から送信されてきたモード変更要求を受信し（ステップ８０２）、クライアント側モードテーブル管理部３３Ｅは、現在設定されているモードが「即時性最優先」か否か調べる（ステップ８０３）。

現在のモードが「即時性最優先」ではないと判断した場合、クライアント側モードテーブル管理部３３Ｅは、次のモード（変更後のモード）が「即時性最優先」か調べる（ステップ８０４）。

次のモード（変更後のモード）が「即時性最優先」である場合、クライアント側モードテーブル管理部３３Ｅは、WebSocketの接続を閉じ、ＳＭＳの接続を有効にする（ステップ８０５）。

ステップ８０３で現在のモードが「即時性最優先」であると判断された場合、或いは、ステップ８０４で次のモード（変更後のモード）が「即時性最優先」ではないと判断された場合、クライアント側モードテーブル管理部３３Ｅは、モード、接続維持方式、及び接続維持間隔を変更する（ステップ８０６）。

次に、クライアント側モード変更成否送信部３３Ｆは、変更成功を配信装置２に送信する（ステップ８０７）。

続いて、サーバ側モード変更成否受信部２３Ｆは、クライアント端末装置３から送信されてきた「変更成功」を受信し、サーバ側モードテーブル管理部３３Ｅは、モードを変更する（ステップ８０８）。

（３）第３の実施形態
第３の実施形態は、フィールドサポート員による作業もしくは端末の回収の作業を軽減することに関し、特に、ネットワーク装置のアイドルタイムアウト時間が変わった場合に、WebSocket接続維持間隔を適切に自動調整する仕組みについて提案する。

図９は、本発明の第３の実施形態による通信システムの概略構成を示す図である。なお、第３の実施形態では、説明の便宜のため、第１及び第２の実施形態で用いられている「モード」を「自動調整」と標記することとする。

＜通信システムの構成＞
第３の実施形態による通信システムは、第１の実施形態による構成に、サーバ側モードテーブル管理部２３Ｅ、切断時間監視部２３Ｇ、及びクライアント側モードテーブル管理部を追加した構成となっている。

切断時間監視部２３Ｇが、配信装置２と各クライアント端末装置３との接続が切断されている時間を監視し、その接続切断時間が所定の時間を超過する場合に、接続維持間隔を短縮するように自動調整するため、サーバ側モードテーブル管理部２３Ｅ及びクライアント側モードテーブル管理部３３Ｅが動作する。

＜サーバ側モードテーブルの構成＞
図１０は、第３の実施形態によるサーバ側モードテーブル２３Ｂ３の構成例を示す図である。
サーバ側モードテーブル２３Ｂ３は、クライアント端末装置を一意に特定・識別するための情報である端末ＩＤと、モード（今回の場合「自動調整」のみが入力される）と、WebSocket接続維持方式と、WebSocket接続維持間隔と、を構成項目として有している。

WebSocket接続維持間隔は、接続が切断されていてもそれが検知されない最大の時間を示す情報である。切断時間監視部２３Ｇによって、切断されている時間が監視されるが、その切断時間が所定時間（例えば、２分）を超える場合、ステップ・バイ・ステップで１分間ずつ接続維持間隔が短縮される処理が実行され、これが繰り返えされる。

＜接続維持間隔自動調整処理（１）＞
図１１は、ネットワーク装置のアイドルタイムが短くなった場合に備えて配信装置２とクライアント端末装置３との接続維持間隔を自動調整する処理（接続維持間隔短縮処理）を説明するためのフローチャートである。

配信装置２の切断時間監視部２３Ｇは、配信装置２とクライアント端末装置３との接続を監視し、切断時間が一定値（設定値）を超えるか否か判断する（ステップ１１０１）。超えていなければ処理は終了する。

切断時間が一定値を超えていると判断された場合、配信装置２のサーバ側モードテーブル管理部２３Ｅは、接続維持間隔を一定量（予め決められた時間量）分短縮するように、対象となるクライアント端末装置３に変更命令を送信する（１１０２）。

クライアント端末装置３のクライアント側モードテーブル管理部３３Ｅは、受信した変更命令に応答して、接続維持間隔を一定量短縮し（ステップ１１０３）、配信装置２に変更成功を返信する（ステップ１１０４）。

＜接続維持間隔自動調整処理（２）＞
図１２は、ネットワーク装置のアイドルタイムが長くなった場合に備えて、配信装置２とクライアント端末装置３との接続維持間隔を自動調整する処理（接続維持間隔延長処理）を説明するためのフローチャートである。図１２の処理は、図１１の処理とは逆の処理に相当し、接続維持間隔が短くなりすぎてしまったときに実行される処理である。図１１の処理によって本来適正であるとされている接続維持間隔（例えば、５分）が短くなりすぎてしまったとき（例えば、３分）に、図１２の処理によって適正な接続維持間隔（５分）に戻されることになる。

定期的に当該自動調整処理が開始される（ステップ１２０１）。図１２において、「一定時間待つ」とは定期的に（例えば、１回／日、１回／月）当該自動調整処理を実行することを意味する。

クライアント端末装置３のクライアント側モードテーブル管理部３３Ｅは、接続維持間隔を一定量（設定値）分長くし（ステップ１２０２）、配信装置２に対して変更結果を送信する（ステップ１２０３）。

（４）更なる変形例
＜変形例１＞
クライアント端末装置３が車両に設置され、配信装置２が当該車両の位置を監視する処理を実行するようにしても良い。

＜変形例２＞
上述のような入力情報をモードではなく、通信事業者（キャリア）及び配信装置（サーバ）２が動作する基盤サービス（サーバ（クラウドサービス）の種類）などといった通信環境としても良い。この場合、配信装置２が、内部のメモリに、通信環境毎に適切な接続維持方式及び接続維持間隔の組み合わせに関する情報を保持するという構成としてもよい。上記２つの要素を含む通信環境が設定されると、配信装置２及びクライアント端末装置３のミドルウェアにおいて、通信環境に対応する接続維持間隔と接続維持方式（通信方式）を設定する。このようにすることにより、アプリケーション開発者の作業量を劇的に削減することができるようになる。

＜変形例３＞
通信事業者ごとの適切な接続維持間隔と、サーバが動作する基盤サービスごとの適切な接続維持時間を、モードテーブルと同じようにあらかじめ保有しておき、上位アプリケーションから指定された通信事業者に対する接続維持間隔と、上位アプリアプリケーションから指定されたサーバ動作基盤サービスに対する接続維持間隔のうち、短い方を選ぶようにする処理を実行しても良い。この場合、さらに接続維持間隔の上限を指定するため、即時性要望値（管理者から指定される）を加えた３者から最小のものを選ぶようにしてもよい。例えば、通信環境から決まる接続維持間隔が長すぎる場合等に、要望値を最終的な接続維持間隔の設定値とするものである。

ここで、通信議事業者に対する接続維持間隔と、サーバ動作基盤サービスに関する接続維持間隔のうち、いずれか一方をあらかじめ保有しておき、保有されているいずれか一方を上位アプリケーションから指定する形態であってもよい。

＜変形例４＞
非常用に通話可能な携帯電話など他の連絡手段を持つか否か、その車両が他の車両に比べサーバからの命令を優先的に受け取るようにすべきか否かという、クライアント端末装置間で比較した際の即時性の優先度合いの情報を接続維持間隔や接続維持方式決定の要素とし、それに応じた接続維持方式および接続維持間隔を設定するようにしてもよい。

（５）まとめ
（i）本発明によるシステムは、クライアント端末装置及び配信装置において、通信の即時性とパケット量削減の重視度合いを示す情報（モード情報）を解釈し、配信装置とクライアント端末装置との間において用いる、通信方式（WebSocketを使う場合には接続維持方式と接続維持間隔も決定する）、WebSocketの接続維持方式、及びWebSocketの接続維持間隔を決定する。また、クライアント端末装置と配信装置は、決定された通信方式で通信を行い、決定されたWebSocketの接続維持方式及びWebSocketの接続維持間隔によって配信装置とクライアント端末装置の接続を維持する。そして、配信装置は、決定された通信方式によってクライアント端末装置に対してメッセージを送信し、決定されたWebSocketの接続維持方式及びWebSocketの接続維持間隔に従って、クライアント端末装置からの接続維持要求に対する応答処理を実行する。このようにすることにより、顧客毎の要望に応えるために、配信システムにおける通信方式の設計、WebSocket接続維持方式の設計、WebSocket接続維持間隔の設計、システム全体の開発といった、顧客毎にカスタマイズするための作業量を軽減することが可能となる。なお、実施形態では、配信装置は、各クライアント端末装置のモード情報を管理しているが、各クライアント端末装置が単独でモード情報を保持し、それに基づいて決定された通信方式（ＳＮＳかWebSocketか）、接続維持方式、及び接続維持間隔を配信装置に通知してその後の通信に用いるようにしても良い。

また、配信装置が、モード情報の変更命令をクライアント端末装置に送信し、クライアント端末装置が、変更命令に基づいてモード情報を変更し、変更の成否を配信装置に通知するようにしても良い。この際、クライアント端末装置は、再度、変更されたモード情報を解釈し、必要に応じてWebSocketの接続維持方式及びWebSocketの接続維持間隔の少なくとも１つを更新する。このようにすることにより、通信事業者の方針変更などによるネットワーク装置のアイドルタイムアウト時間の変更に容易に対応できることが可能となる。

また、配信装置が、クライアント端末装置との接続の切断時間を監視し、切断時間が所定値を超えた場合にWebSocketの接続維持間隔の変更命令をクライアント端末装置に送信し、クライアント端末装置が、変更命令に応答してWebSocketの接続維持間隔を所定値分短くするようにしても良い。このようにすることにより、ネットワーク装置のアイドルタイムアウト時間が変わった場合にも、WebSocket接続維持間隔を適切に自動調整することができるようになる。

さらに、クライアント端末装置は、一定時間毎にWebSocket接続維持間隔を所定時間長く変更し、当該変更結果を配信装置に通知するようにしても良い。このようにすることにより、ネットワーク装置のアイドルタイムアウト時間が長くなった場合に、WebSocket接続維持間隔を適切に自動的に調整することができるようになる。

また、クライアント端末装置は、契約した通信事業者の情報及び配信装置の基板サービスの情報を含む通信環境情報に基づいて、通信事業者に適切な前記接続維持方式を決定し、通信事業者が提供する接続維持間隔と基板サービスによって決まる接続維持間隔のうち短い間隔を、配信装置との間で用いるWebSocketの接続維持間隔とするようにしても良い。このようにすることにより、通信環境が異なっていたとしても適切な接続維持間隔を設定することが可能となる。

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

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

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

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

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

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

１・・・管理者端末装置
１１Ａ、２１Ａ、３１Ａ・・・ＣＰＵ（プロセッサ）
１１Ｂ、２１Ｂ、３１Ｂ・・・メモリ
１３、２３、３３・・・外部記憶装置
２・・・配信装置
３・・・クライアント端末装置
４・・・インターネット（ネットワーク）
５・・・電話網
１３Ａ・・・管理者操作送信部
１３Ｂ、３３Ｄ・・表示部
２３Ａ・・・管理者操作応答部
２３Ｂ・・・サーバ管理部
２３Ｃ・・・WebSocketサーバ側通信部
２３Ｄ・・・ＳＭＳ送信部
２３Ｂ１・・・送信内容リストテーブル
２３Ｂ２・・・送信先端末リストテーブル
２３Ｂ３・・・サーバ側モードテーブル
３３Ａ・・・クライアント管理部
３３Ｂ・・・WebSocketクライアント側通信部
３３Ｃ・・・ＳＭＳ受信部
３３Ａ１・・・クライアント側モードテーブル

Claims (12)

1. 配信装置から少なくとも１つのクライアント端末装置にメッセージを送信するメッセージ配信システムであって、
   前記クライアント端末装置は、
   通信の即時性とパケット量削減の重視度合いを示すモード情報を保持するモード情報保持部と、
   前記モード情報を解釈し、前記配信装置との間においてWebSocket通信方式を用いること、さらに、WebSocket接続維持方式、及びWebSocket接続維持間隔を決定するクライアント管理部と、
   前記決定されたWebSocket通信方式で前記配信装置と通信を行い、前記決定されたWebSocket接続維持方式及びWebSocket接続維持間隔によって前記配信装置との接続を維持するクライアント通信部と、を有し、
   前記配信装置は、
   前記決定されたWebSocket通信方式によって前記クライアント端末装置に対してメッセージを送信し、前記決定されたWebSocket接続維持方式及びWebSocket接続維持間隔に従って、前記クライアント端末装置からの接続維持要求に対する応答処理を実行する、サーバ通信部を有する、
   ことを特徴とするメッセージ配信システム。
2. 請求項１において、
   前記配信装置は、さらに、前記モード情報の変更命令を前記クライアント端末装置に送信するサーバ側モード管理部と、モード情報変更の成否に関する通知を受信するサーバ側モード変更成否受信部と、を有し、
   前記クライアント端末装置は、さらに、前記変更命令を受信し、それに基づいて前記モード情報を変更するクライアント側モード管理部と、変更の成否を前記配信装置に通知するクライアント側モード変更成否送信部と、を有し、
   前記クライアント管理部は、前記変更されたモード情報を解釈し、必要に応じて前記WebSocketの接続維持方式及び前記WebSocket接続維持間隔の少なくとも１つを更新する、
   ことを特徴とするメッセージ配信システム。
3. 請求項１において、
   前記配信装置は、さらに、前記クライアント端末装置との接続の切断時間を監視する切断時間監視部と、前記切断時間が所定値を超えた場合に前記WebSocket接続維持間隔の変更命令を前記クライアント端末装置に送信するサーバ側モード管理部と、を有し、
   前記クライアント端末装置は、前記変更命令を受信し、それに応答して前記WebSocketの接続維持間隔を所定値分短くするクライアント側モード管理部を有する、
   ことを特徴とするメッセージ配信システム。
4. 請求項１において、
   前記クライアント端末装置は、さらに、一定時間毎に前記WebSocket接続維持間隔を所定時間長く変更し、当該変更結果を前記配信装置に通知するクライアント側モード管理部を有する、
   ことを特徴とするメッセージ配信システム。
5. 請求項１において、
   前記モード情報保持部は、前記モード情報として、通信事業者の情報及び前記配信装置の基板サービスの情報を含む通信環境情報を保持し、
   前記クライアント管理部は、前記通信事業者に適切な前記接続維持方式を決定し、前記通信事業者が提供する前記接続維持間隔と前記基板サービスによって決まる前記接続維持間隔のうち短い間隔を、前記配信装置との間で用いるWebSocket接続維持間隔とすることを特徴とするメッセージ配信システム。
6. 請求項１において、
   前記配信装置は、さらに、ショートメッセージ送信部を有し、
   前記クライアント端末装置は、さらに、ショートメッセージ受信部を有し、
   前記クライアント管理部は、前記モード情報を解釈し、前記配信装置との間において、前記WebSocket通信方式及びショートメッセージ通信方式の何れを用いるかを決定することを特徴とするメッセージ配信システム。
7. 配信装置から少なくとも１つのクライアント端末装置にメッセージを送信するメッセージ配信方法であって、
   前記クライアント端末装置が、通信の即時性とパケット量削減の重視度合いを示すモード情報をメモリから読み出して解釈し、前記配信装置との間においてWebSocket通信方式を用いること、さらに、WebSocket接続維持方式、及びWebSocket接続維持間隔を決定するステップと、
   前記クライアント端末装置が、前記決定されたWebSocket通信方式で前記配信装置と通信を行い、前記決定されたWebSocket接続維持方式及びWebSocket接続維持間隔によって前記配信装置との接続を維持するステップと、
   前記配信装置が、前記決定されたWebSocket通信方式によって前記クライアント端末装置に対してメッセージを送信し、前記決定されたWebSocket接続維持方式及びWebSocket接続維持間隔に従って、前記クライアント端末装置からの接続維持要求に対する応答処理を実行するステップと、
   を有することを特徴とするメッセージ配信方法。
8. 請求項７において、さらに、
   前記配信装置が、前記モード情報の変更命令を前記クライアント端末装置に送信するステップと、
   前記クライアント端末装置が、前記変更命令を受信し、それに基づいて前記モード情報を変更するステップと、
   前記クライアント端末装置が、変更の成否を前記配信装置に通知するステップと、
   前記配信装置が、モード情報変更の成否に関する通知を受信するステップと、
   前記クライアント端末装置が、前記変更されたモード情報を解釈し、必要に応じて前記WebSocket接続維持方式及び前記WebSocket接続維持間隔の少なくとも１つを更新するステップと、
   を有することを特徴とするメッセージ配信方法。
9. 請求項７において、さらに、
   前記配信装置が、前記クライアント端末装置との接続の切断時間を監視するステップと、
   前記配信装置が、前記切断時間が所定値を超えた場合に、前記WebSocket接続維持間隔の変更命令を前記クライアント端末装置に送信するステップと、
   前記クライアント端末装置が、前記変更命令を受信し、それに応答して前記WebSocketの接続維持間隔を所定値分短くするステップと、
   を有することを特徴とするメッセージ配信方法。
10. 請求項７において、さらに、
    前記クライアント端末装置が、一定時間毎に前記WebSocket接続維持間隔を所定時間長く変更し、当該変更結果を前記配信装置に通知するステップを有することを特徴とするメッセージ配信方法。
11. 請求項７において、
    前記メモリは、前記モード情報として、通信事業者の情報及び前記配信装置の基板サービスの情報を含む通信環境情報を保持し、
    さらに、前記クライアント端末装置が、前記メモリから前記通信環境情報を読み出し、前記通信事業者に適切な前記接続維持方式を決定し、前記通信事業者が提供する前記接続維持間隔と前記基板サービスによって決まる前記接続維持間隔のうち短い間隔を、前記配信装置との間で用いるWebSocketの接続維持間隔とするステップを有することを特徴とするメッセージ配信方法。
12. 請求項７において、
    前記配信装置は、さらに、ショートメッセージ送信部を有し、前記クライアント端末装置は、さらに、ショートメッセージ受信部を有し、
    前記方法は、さらに、
    前記クライアント端末装置が、前記モード情報を解釈し、前記配信装置との間において、前記WebSocket通信方式及びショートメッセージ通信方式の何れを用いるかを決定するステップを有することを特徴とするメッセージ配信方法。

Images