(57)【要約】【課題】ＷｅｂＳｏｃｋｅｔに準拠してメッセージを配信する際に、メッセージが相手方に到達したことを確認する仕組みを提供する。【解決手段】本発明に係るメッセージ配信システムにおいて、配信装置はメッセージとともにこれを固有識別するメッセージＩＤを送信し、クライアント端末はメッセージＩＤと受信確認応答を併せて返信する。【選択図】図１
2014170288.tif 000002
【特許請求の範囲】
【請求項１】
メッセージを受信するクライアント端末と、
前記クライアント端末に対してネットワークを介しメッセージを配信する配信装置と、
を有し、
前記配信装置は、
前記ネットワークを介して前記クライアント端末との間でＷｅｂＳｏｃｋｅｔプロトコルに準拠して通信するサーバ側通信部と、
前記サーバ側通信部を介して前記クライアント端末に対して前記メッセージを送信するメッセージ配信部と、
を備え、
前記クライアント端末は、
前記ネットワークを介して前記配信装置との間でＷｅｂＳｏｃｋｅｔプロトコルに準拠して通信するクライアント側通信部と、
前記クライアント側通信部を介して前記配信装置から前記メッセージを受信するメッセージ受信部と、
を備え、
前記メッセージ配信部は、前記メッセージを送信する際に、前記メッセージを固有に識別するメッセージＩＤを前記メッセージに付与して送信し、
前記メッセージ受信部は、前記メッセージを受信すると、その旨を示す受信確認応答を当該メッセージに付与されている前記メッセージＩＤとともに前記クライアント側通信部を介して前記配信装置に対して送信し、
前記メッセージ配信部は、前記クライアント端末から前記受信確認応答とともに前記メッセージＩＤを受信したか否かに基づき、前記メッセージが前記クライアント端末に到達したか否かを確認し、到達しなかった場合は所定の通信エラー処理を実施する
ことを特徴とするメッセージ配信システム。
【請求項２】
前記ネットワークは、無線通信回線として構成されており、
前記ネットワーク上には、前記クライアント端末と前記配信装置との間の無線接続を中継する中継装置が配置されており、
前記中継装置は、前記クライアント端末と前記配信装置が所定時間以上通信しなかった場合は前記無線接続を切断するように構成されており、
前記クライアント端末はさらに、前記中継装置が前記無線接続を切断する前に前記クライアント側通信部を介して通信データを送信することにより前記無線接続を継続させるクライアント側接続維持部を備える
ことを特徴とする請求項１記載のメッセージ配信システム。
【請求項３】
前記接続維持部は、前記無線接続が前記クライアント端末以外の要因によって切断された場合は、前記クライアント通信部を介して前記配信装置と再接続する
ことを特徴とする請求項２記載のメッセージ配信システム。
【請求項４】
前記配信装置はさらに、前記中継装置が前記無線接続を切断する前に前記サーバ側通信部を介して通信データを送信することにより前記無線接続を継続させるサーバ側接続維持部を備える
ことを特徴とする請求項２または３記載のメッセージ配信システム。
【請求項５】
前記メッセージ受信部は、前記受信確認応答を即座に送信せずに保留しておき、前記保留している受信確認応答の個数が所定数に達した場合、前記配信装置との間の通信量が所定量に達した場合、または前記保留している受信確認応答のデータ量が所定量に達した場合は、前記保留している受信確認応答をまとめて前記配信装置に対して送信する
ことを特徴とする請求項１から４のいずれか１項記載のメッセージ配信システム。
【請求項６】
前記クライアント端末はさらに、前記メッセージの内容に対する返答をオペレータが入力するための入力部を備え、
前記メッセージ受信部は、前記受信確認応答とともに前記入力部に入力された前記返答を前記配信装置に対して送信し、
前記メッセージ配信部は、前記返答を入力すべき制限時間を指定する制限時間指示とともに前記メッセージを前記クライアント端末に対して送信し、
前記メッセージ受信部は、前記制限時間内に前記入力部に対して前記返答が入力されなかった場合は、前記メッセージの内容に対する肯定的な返答が入力されなかった旨の前記返答を前記配信装置に対して送信する
ことを特徴とする請求項１から５のいずれか１項記載のメッセージ配信システム。
【請求項７】
前記メッセージ配信システムは、複数の前記クライアント端末を有し、
前記配信装置はさらに、前記メッセージ配信システムが有する複数の前記クライアント端末のリストを備え、
前記メッセージ配信部は、前記メッセージの内容に対する前記肯定的な返答を前記クライアント端末から受信しなかった場合は、前記リストが記述している他の前記クライアント端末に対して同じ前記メッセージを再送する
ことを特徴とする請求項６記載のメッセージ配信システム。
【請求項８】
前記配信装置はさらに、前記クライアント端末またはその保有者の特性毎に、前記制限時間を増減する量を定義する制限時間補正テーブルを備え、
前記メッセージ配信部は、前記制限時間補正テーブルの記述にしたがって前記制限時間を増減補正した上で、前記メッセージを前記クライアント端末に対して送信する
ことを特徴とする請求項６または７記載のメッセージ配信システム。
【請求項９】
前記配信装置は、前記メッセージの内容に対する肯定的な返答が入力されなかった回数を記録する記憶部を備え、
前記メッセージ配信部は、前記回数が所定上限に達した場合は、前記肯定的な入力以外の前記返答を許可しない旨の肯定強制指示とともに前記メッセージを前記クライアント端末に対して送信し、
前記入力部は、前記メッセージ受信部が前記肯定強制指示を受信した場合は、前記肯定的な入力以外の前記返答を受け付けない
ことを特徴とする請求項６から８のいずれか１項記載のメッセージ配信システム。
【請求項１０】
前記クライアント端末は、車両に搭載されている
ことを特徴とする請求項１から９のいずれか１項記載のメッセージ配信システム。
【請求項１１】
メッセージを配信する配信装置に対してＷｅｂＳｏｃｋｅｔプロトコルに準拠した通信接続を確立するステップ、
前記配信装置から、前記通信接続を介して、前記メッセージとともに前記メッセージを固有に識別するメッセージＩＤを受信するステップ、
前記メッセージとともに前記ＩＤを受信した場合は、その旨の受信確認応答を前記メッセージＩＤとともに前記配信装置に対して前記通信接続を介して送信するステップ、
を有することを特徴とするメッセージ配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷｅｂＳｏｃｋｅｔプロトコルを用いてメッセージを配信する技術に関するものである。
【背景技術】
【０００２】
ネットワークを介してメッセージを配信する通信プロトコルとして、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）が利用される場合がある。ＨＴＴＰはセッションレス型のプロトコルであるため、クライアントからサーバに対してリクエストを発行してその返信を受け取るのが原則であり、サーバからクライアントに対してメッセージをＰＵＳＨ配信することはできない。
【０００３】
ＨＴＴＰを用いたＰＵＳＨ配信を擬似的に実現する手法として、ＨＴＴＰポーリングと呼ばれる手法がある。これは、実際にリクエストを発行する必要があるか否かによらずクライアントからサーバに対して定期的にリクエストを発行し、その結果をレスポンスとして受け取る方法である。ポーリング間隔をある程度短くすれば、実質的にはサーバからＰＵＳＨ配信しているのと同等の動作を実現することができる。ポーリングに関する技術の例として、下記特許文献１がある。
【０００４】
車両の現在位置などを管理する車両管理システムにおいて、ＨＴＴＰポーリングを利用して管理サーバと車両の間でメッセージを送受信することを考える。車両からサーバに対してメッセージを送信する場合は、ＨＴＴＰリクエスト内にメッセージを記述して送信する。メッセージがサーバに到達したか否かについては、ＨＴＴＰレスポンスにより判定することができる。サーバから車両に対してメッセージを送信する場合は、ＨＴＴＰレスポンス内にメッセージを記述して送信する。メッセージが車両に到達したか否かについては以後のＨＴＴＰリクエストによって判定することができる。
【０００５】
一方で近年、ＨＴＴＰに代わるプロトコルとして、ＷｅｂＳｏｃｋｅｔが注目されている。ＷｅｂＳｏｃｋｅｔは、下記非特許文献１に示すように、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によりＲＦＣ６４５５として開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−２２３２４８号公報
【非特許文献】
【０００７】
【非特許文献１】http://tools.ietf.org/html/rfc6455（２０１３年０２月１５日取得）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＨＴＴＰポーリングは、ＨＴＴＰをベースとしてＰＵＳＨ配信を実現する利点がある一方で、以下のような課題がある。
（課題１）プロトコルの性質上、双方向通信を前提に作られていないため、クライアントとサーバの間で対話的な通信をすることには向いていない。
（課題２）プロトコルの性質上、ポーリング間隔が存在するため、即時性のあるメッセージ配信を実施することはできない。
（課題３）プロトコルの性質上、無駄なヘッダ（ＨＴＴＰヘッダ）があるため、通信量が大きい。
【０００９】
ＷｅｂＳｏｃｋｅｔは、上述のような課題はないものの、到達確認をする必要がない娯楽目的のチャットなどが主な使用用途であり、その他の到達確認が必要な用途において用いるための手順は提供されていない。例えば車両管理システムにおいてＷｅｂＳｏｃｋｅｔを用いる場合、管理センタから車両ドライバに対するメッセージが届いたことを確認する必要が生じる場合があるが、ＷｅｂＳｏｃｋｅｔはそのような手順を提供していない。また、管理センタと車両ドライバが対話する場合においても、娯楽目的のチャットとは異なり業務上のメッセージは相手方に対して確実に届くかまたはこれを確認できることが望ましいと考えられる。
【００１０】
本発明は、上記のような課題に鑑みてなされたものであり、ＷｅｂＳｏｃｋｅｔに準拠してメッセージを配信する際に、メッセージが相手方に到達したことを確認する仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明に係るメッセージ配信システムにおいて、配信装置はメッセージとともにこれを固有識別するメッセージＩＤを送信し、クライアント端末はメッセージＩＤと受信確認応答を併せて返信する。
【発明の効果】
【００１２】
本発明に係るメッセージ配信システムによれば、ＷｅｂＳｏｃｋｅｔを利用して軽量な通信負荷の下で即時性のある双方向通信を実現しつつ、メッセージが相手方に届いたか否かを確認して必要に応じ再送処理などの通信エラー処理を実施することができる。
【図面の簡単な説明】
【００１３】
【図１】実施形態１に係るメッセージ配信システム１００の構成図である。
【図２】管理者端末１の表示部１５が表示する画面例を示す図である。
【図３】クライアント側接続維持部３７の動作を説明するフローチャートである。
【図４】メッセージ配信部２６の動作を説明するフローチャートである。
【図５】メッセージ受信部３６の動作を説明するフローチャートである。
【図６】メッセージ配信部２６が送信するメッセージのデータ形式例である。
【図７】メッセージ受信部３６が送信する受信確認応答のデータ形式例である。
【図８】実施形態２に係るメッセージ配信システム１００の構成図である。
【図９】実施形態２において管理者端末１の表示部１５が表示する画面例を示す図である。
【図１０】表示部３４が画面表示するメッセージの例である。
【図１１】管理者端末１の動作を説明するフローチャートである。
【図１２】配信装置２がメッセージを送信する処理を説明するフローチャートである。
【図１３】クライアント端末３がメッセージを受信する処理を説明するフローチャートである。
【図１４】メッセージ配信部２６が送信するメッセージのデータ形式例である。
【図１５】補正テーブル２３１の構成とデータ例を示す図である。
【発明を実施するための形態】
【００１４】
＜実施の形態１＞
図１は、本発明の実施形態１に係るメッセージ配信システム１００の構成図である。メッセージ配信システム１００は、クライアント端末３に対してメッセージを配信するシステムであり、管理者端末１、配信装置２、クライアント端末３を有する。ここでは、商用車が搭載しているクライアント端末３に対して、管理センタ側に設置されている配信装置２から配車依頼などのメッセージを送信する、車両管理システムを想定する。
【００１５】
管理者端末１は、メッセージ配信システム１００の管理者が管理指示を実施するための端末である。管理者端末１は、通信ポート１１、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１２、メモリ１３、操作送信部１４、表示部１５を備える。
【００１６】
通信ポート１１は、ネットワーク４を介して他装置と通信する通信インターフェースである。ＣＰＵ１２は、管理者端末１が備える記憶装置が格納するプログラムを実行する。メモリ１３はＣＰＵ１２が一時的に使用するデータを格納する。操作送信部１４は、管理者による操作指示を配信装置２に対して通信ポート１１を介して送信する。表示部１５は、管理指示に対する応答などを画面表示する。
【００１７】
配信装置２は、クライアント端末３に対してネットワーク４を介してメッセージを配信する装置である。配信装置２は、通信ポート２１、ＣＰＵ２２、メモリ２３、操作応答部２４、サーバ側通信部２５、メッセージ配信部２６、サーバ側接続維持部２７を備える。
【００１８】
通信ポート２１は、ネットワーク４を介して他装置と通信する通信インターフェースである。ＣＰＵ２２は、配信装置２が備える記憶装置が格納するプログラムを実行する。メモリ２３はＣＰＵ２２が一時的に使用するデータを格納する。
【００１９】
操作応答部２４は、管理者端末１が送信した操作指示に対する応答を通信ポート２１経由で管理者端末１に返信する。サーバ側通信部２５は、ＷｅｂＳｏｃｋｅｔプロトコルに準拠して通信ポート２１経由でクライアント端末３と通信する。メッセージ配信部２６は、サーバ側通信部２５の機能を利用して、ＷｅｂＳｏｃｋｅｔプロトコルに準拠してクライアント端末３に対してメッセージを送信する。送信手順については後述する。サーバ側接続維持部２７は、配信装置２とクライアント端末３の間のＷｅｂＳｏｃｋｅｔ接続が外部的要因によって切断されないようにするための処理を実施する。この処理については後述する。
【００２０】
クライアント端末３は、配信装置２からネットワーク４を介してメッセージを受信する端末である。クライアント端末３は、通信ポート３１、ＣＰＵ３２、メモリ３３、表示部３４、クライアント側通信部３５、メッセージ受信部３６、クライアント側接続維持部３７を備える。
【００２１】
通信ポート３１は、ネットワーク４を介して他装置と通信する通信インターフェースである。ＣＰＵ３２は、クライアント端末３が備える記憶装置が格納するプログラムを実行する。メモリ３３はＣＰＵ３２が一時的に使用するデータを格納する。
【００２２】
表示部３４は、配信装置２から受信したメッセージを画面表示する。クライアント側通信部３５は、ＷｅｂＳｏｃｋｅｔプロトコルに準拠して通信ポート３１経由で配信装置２と通信する。メッセージ受信部３６は、クライアント側通信部３５の機能を利用して、ＷｅｂＳｏｃｋｅｔプロトコルに準拠して配信装置２からメッセージを受信し、または応答を送信する。これらの手順については後述する。クライアント側接続維持部３７は、配信装置２とクライアント端末３の間のＷｅｂＳｏｃｋｅｔ接続が外部的要因によって切断されないようにするための処理を実施する。この処理については後述する。
【００２３】
図２は、管理者端末１の表示部１５が表示する画面例を示す図である。図２（ａ）はメッセージを送信する宛先とすべきクライアント端末３と送信するメッセージを選択する画面である。図２(ｂ)は、送信可能なメッセージを列挙する画面である。
【００２４】
配信装置２は、複数のクライアント端末３およびそのＩＰアドレスを固有識別子によって管理しており、管理者は配信装置２が管理しているクライアント端末３の一覧を図２（ａ）の画面上で確認することができる。管理者は、いずれのクライアント端末３に対してメッセージを送信するかを同画面上で選択する。
【００２５】
配信装置２は、図２（ｂ）に示すようなメッセージ一覧をあらかじめ記憶装置上に保持している。管理者は、配信装置２が保持しているメッセージの一覧を図２（ｂ）の画面上で確認し、送信すべきメッセージをその一覧から選択することができる。
【００２６】
図３は、クライアント側接続維持部３７の動作を説明するフローチャートである。図３（ａ）はクライアント側接続維持部３７が常時実施している動作であり、図３（ｂ）は配信装置２とクライアント端末３との間のＷｅｂＳｏｃｋｅｔ接続が切断されたときに実施する動作である。以下、図３の各ステップについて説明する。
【００２７】
配信装置２とクライアント端末３との間は、サーバ側通信部２５とクライアント側通信部３５によってＷｅｂＳｏｃｋｅｔ接続が確立されている。この接続は通信セッションを維持するため、接続を開始したクライアント側通信部３５から切断しない限りは原則として維持される。ただし、配信装置２とクライアント端末３との間で長時間通信がなされなかった場合、通信経路の途中に配置されているネットワーク装置（例えばルータ、ゲートウェイ、ファイアウォールなどの中継装置がこれに当たる）が両者の間の接続を強制的に切断する場合がある。そこでクライアント側接続維持部３７は、図３（ａ）のフローチャートにより、配信装置２とクライアント端末３との間のＷｅｂＳｏｃｋｅｔ接続を上記のような外部的要因により切断させることなく維持する。
【００２８】
（図３（ａ）：ステップＳ３０１〜Ｓ３０２）
クライアント側接続維持部３７は、配信装置２とクライアント端末３との間で通信がなされない時間（無通信間隔）を計測するためのカウンタを０に初期化する（Ｓ３０１）。クライアント側接続維持部３７は、所定時間待機する（Ｓ３０２）。
【００２９】
（図３（ａ）：ステップＳ３０３）
クライアント側接続維持部３７は、ステップＳ３０２の間に配信装置２とクライアント端末３との間で通信が発生したか否かを判定する。発生した場合はステップＳ３０１に戻り、発生しなかった場合はステップＳ３０４に進む。
【００３０】
（図３（ａ）：ステップＳ３０４）
クライアント側接続維持部３７は、無通信間隔のカウンタを、ステップＳ３０２で待機した時間分インクリメントする。
【００３１】
（図３（ａ）：ステップＳ３０５）
クライアント側接続維持部３７は、無通信間隔のカウンタが所定閾値以上に達したか否かを判定する。閾値以上に達している場合はステップＳ３０６に進み、達していない場合は無通信間隔のカウンタをリセットしてステップＳ３０２に戻る。
【００３２】
（図３（ａ）：ステップＳ３０６）
クライアント側接続維持部３７は、クライアント側通信部３５を介して、配信装置２に対して接続維持信号を送付する。ここでいう接続維持信号は、配信装置２とクライアント端末３との間の通信が全くない期間をこれ以上生じさせないようにするためのものであるため、任意の通信データでよい。例えばＡＣＫ以外の応答を要しない簡易パケットなどを用いればよい。このパケットは、サーバ側接続維持部２７が受信する。本ステップの後はステップＳ３０１に戻る。
【００３３】
図３（ｂ）は、クライアント側接続維持部３７が配信装置２とクライアント端末３との間のＷｅｂＳｏｃｋｅｔ接続を維持しているにも関わらず、両者の間の接続が切断された場合に実施する動作である。具体的には、ネットワーク４が携帯電話事業者の無線通信回線である場合において、電波不良による意図しない通信遮断が発生したときがこれに該当する。
【００３４】
（図３（ｂ）：ステップＳ３１０）
クライアント側接続維持部３７は、配信装置２とクライアント端末３との間のＷｅｂＳｏｃｋｅｔ接続が切断されたとき、例えばイベント割込などによって本フローチャートを開始する。
【００３５】
（図３（ｂ）：ステップＳ３１１）
クライアント側接続維持部３７は、配信装置２とクライアント端末３との間の接続断が意図しないものであるか否かを判定する。具体的には、例えばクライアント側通信部３５が両者の間の接続を明示的に切断したか否かによって判定することができる。意図しない切断である場合はステップＳ３１２へ進み、意図した切断である場合は本フローチャートを終了する。
【００３６】
（図３（ｂ）：ステップＳ３１２）
クライアント側接続維持部３７は、クライアント側通信部３５を介して、配信装置２との間のＷｅｂＳｏｃｋｅｔ接続を改めて開始する。
【００３７】
図４は、メッセージ配信部２６の動作を説明するフローチャートである。以下、図４の各ステップについて説明する。
【００３８】
（図４：ステップＳ４０１）
メッセージ配信部２６は、図２で説明した画面上で管理者が選択したメッセージ番号にしたがって、クライアント端末３に対して送信するメッセージとそのメッセージを識別するメッセージＩＤを生成する。
【００３９】
（図４：ステップＳ４０２〜Ｓ４０３）
メッセージ配信部２６は、サーバ側通信部２５を介して、ステップＳ４０１で生成したメッセージとメッセージＩＤを、図２で説明した画面上で管理者が選択したクライアント端末３に対して送信する（Ｓ４０２）。メッセージ配信部２６は、クライアント端末３が送信する受信確認応答を所定時間待機する（Ｓ４０３）。
【００４０】
（図４：ステップＳ４０４）
メッセージ配信部２６は、ステップＳ４０１で送信したメッセージＩＤに対応する受信確認応答をクライアント端末３から受信したか否かを判定する。受信していない、または受信確認応答は受信したが正常受信できなかった旨を示す受信確認応答である場合は、ステップＳ４０２に戻る。それ以外であれば本フローチャートを終了する。
【００４１】
（図４：ステップＳ４０４：補足）
本ステップの後にステップＳ４０２へ戻る場合、例えばメッセージが到達しなかった旨を管理者端末１上で画面表示し、別のクライアント端末およびメッセージを指定するように促してもよいし、配信装置２が保持しているクライアント端末３のリストから適当な他のクライアント端末３を自動的に選択し同じメッセージとメッセージＩＤを再送してもよい。
【００４２】
図５は、メッセージ受信部３６の動作を説明するフローチャートである。以下、図５の各ステップについて説明する。
【００４３】
（図５：ステップＳ５０１〜Ｓ５０２）
メッセージ受信部３６は、配信装置２が送信するメッセージを待ち受け（Ｓ５０１）、メッセージを受信すると（Ｓ５０２）以下のステップを実施する。
【００４４】
（図５：ステップＳ５０３）
メッセージ受信部３６は、配信装置２からメッセージを受信している途中にエラーが発生したか否かを判定する。エラーが発生した場合はステップＳ５０４に進み、発生しなかった場合はステップＳ５０５に進む。
【００４５】
（図５：ステップＳ５０４）
メッセージ受信部３６は、クライアント側通信部３５を介して、メッセージを正常受信することに失敗した旨の受信確認応答を配信装置２に対して送信する。本ステップの後は本フローチャートを終了する。
【００４６】
（図５：ステップＳ５０５）
メッセージ受信部３６は、受信確認応答を逐次送信してもよいし、通信負荷を軽減するため、受信確認応答を所定件数蓄積してから送信してもよい。蓄積する場合は、その蓄積量が所定量（件数、通信量、または蓄積データ量）に達したか否かを本ステップにおいて判定する。所定量に達した場合はステップＳ５０６へ進み、達していない場合は本フローチャートを終了する。
【００４７】
（図５：ステップＳ５０６）
メッセージ受信部３６は、正常に受信したメッセージについて、その旨を示す各受信確認応答を、ステップＳ５０５において蓄積した分だけまとめた上で、配信装置２に対して送信する。これにより、受信確認応答のための通信回数とこれにともなうオーバヘッドを削減することができる。
【００４８】
図６は、メッセージ配信部２６が送信するメッセージのデータ形式例である。ｆｒｏｍフィールドは配信装置２のアドレスまたはホスト名である。ｔｏフィールドはクライアント端末３のアドレスまたはホスト名である。ｍｅｓｓａｇｅフィールドはメッセージ内容を示す文字列である。ｍｅｓｓａｇｅ＿ｉｄは当該メッセージを一意に識別するメッセージＩＤである。
【００４９】
図７は、メッセージ受信部３６が送信する受信確認応答のデータ形式例である。ｍｅｓｓａｇｅ_ｉｄフィールドは、受信したことを示すメッセージＩＤであり、ステップＳ５０５〜Ｓ５０６で説明したように複数の値を記述することもできる。ｒｅｓｕｌｔフィールドは、ｍｅｓｓａｇｅ＿ｉｄフィールドに記載しているメッセージを正常受信できたか否かを示す値である。例えば正常受信できた場合はＳｕｃｃｅｓｓと記述し、受信失敗した場合はＦａｉｌｕｒｅと記述する。
【００５０】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るメッセージ配信システム１００において、配信装置２は、クライアント端末３に対して送信するメッセージにこれを一意識別するメッセージＩＤを付与して受信確認応答を待機する。クライアント端末３は、正常受信できたか否かを示す受信確認応答を各メッセージＩＤについて返信する。これにより、単にＷｅｂＳｏｃｋｅｔ接続を確立して双方向通信可能な状態になっていることに依拠するのみならず、送受信が確実になされたか否かを送信側で確認することができる。したがって、ＷｅｂＳｏｃｋｅｔプロトコルを利用したメッセージ配信の信頼性を高めることができる。
【００５１】
また、本実施形態１に係るメッセージ配信システム１００において、クライアント端末３は配信装置２との間のＷｅｂＳｏｃｋｅｔが外部的要因によって切断されないように、接続維持信号を発信する。これにより、ＷｅｂＳｏｃｋｅｔプロトコルの対象外の要因によるメッセージ配送不能を抑制することができる。同様の処理は、配信装置２が備えるサーバ側接続維持部２７からクライアント端末３に対して実施してもよい。
【００５２】
＜実施の形態２＞
実施形態１においては、配信装置２が送信したメッセージがクライアント端末３に到達したことを確認する動作例を説明した。このメッセージは配信装置２からクライアント端末３に対する１方向的なものを想定している。
【００５３】
一方で、例えば車両管理システムにおいては、特定の場所に対して配車を指示するメッセージが考えられる。この場合、そのメッセージ内容として、配車可能であるか否かをクライアント端末３の所持者に対して問い合わせるメッセージが記載されていると考えられる。クライアント端末３の所持者はこれに対して返答を入力するので、メッセージは双方向的なものとなる。
【００５４】
本発明の実施形態２においては、配信装置２とクライアント端末３双方からメッセージを送信する構成例について説明する。さらに、クライアント端末３が送信したメッセージの内容に応じて別のクライアント端末３に対して同じメッセージを再送する構成例についても説明する。
【００５５】
図８は、本実施形態２に係るメッセージ配信システム１００の構成図である。配信装置２は、実施形態１で説明した構成に加えて送信順決定部２８と自動送信部２９を備える。クライアント端末３は、実施形態１で説明した構成に加えて入力部３８を備える。その他の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５６】
送信順決定部２８は、メッセージを送信するクライアント端末３の候補が複数ある場合において、その送信順序を決定する。決定手順については後述の図９で説明する。自動送信部２９は、クライアント端末３が送信した応答内容に基づき、必要に応じて他のクライアント端末３に対して同じメッセージを再送する。再送手順については後述の図１２で説明する。入力部３８は、クライアント端末３の所持者がメッセージに対する応答を入力するための手段である。
【００５７】
図９は、本実施形態２において管理者端末１の表示部１５が表示する画面例を示す図である。図９（ａ）は、メッセージを送信する宛先とすべきクライアント端末３、送信するメッセージ、および送信順を選択する画面である。図９（ｂ）は、決定された送信先を表示する画面である。
【００５８】
配信装置２は、複数のクライアント端末３またはその所持者の特性を管理している。ここでは車両管理システムを想定しているので、車両運転者のスキル、車両状態、車両現在位置などを管理しているものとする。これら情報はあらかじめ配信装置２上に入力して記憶装置に格納しておくことができる。車両現在位置や車両状態のように変化する情報については、例えばＧＰＳその他任意の通信手段によって各クライアント端末３から収集して逐次更新しておけばよい。
【００５９】
管理者は配信装置２が管理しているクライアント端末３またはその所持者の特性のなかからいずれを優先してメッセージを送信するかを、図９（ａ）の画面上で選択することができる。例えば車両管理システムにおいては、配車先までの距離が短い順にメッセージを送信するように指定することが考えられる。配車先までの距離は、各クライアント端末３の現在位置と配車先の座標が分かれば、計算することができる。
【００６０】
送信順決定部２８は、図９（ａ）の画面上で管理者が指定した送信順にしたがって、メッセージを送信する宛先であるクライアント端末３を決定する。メッセージ配信部２６は、送信順決定部２８が決定したクライアント端末３に対してメッセージを送信する。またこれと併せて、管理者端末１は、図９（ｂ）に示すような画面を表示し、いずれのクライアント端末３にメッセージが送信されたかを管理者へ通知する。
【００６１】
本実施形態２において、メッセージ配信部２６は、クライアント端末３の所持者に対して返答を促すメッセージを送信する。例えば車両管理システムにおいては、配車指示とともに、その指示に応じることができるか否かを回答するよう促すメッセージを送信することが考えられる。
【００６２】
図１０は、表示部３４が画面表示するメッセージの例である。この例において、メッセージ配信部２６が送信したメッセージは、配車指示とともに、指示に応じることができるか否かを回答するよう促している。クライアント端末３の所持者は、入力部３８を介して返答を入力する。メッセージ受信部３６は、クライアント側通信部３５を介してその旨の回答を返信する。
【００６３】
図１１は、管理者端末１の動作を説明するフローチャートである。ステップＳ１１０１において、管理者は図９で説明した画面上で、メッセージを送信する対象とする範囲を指定する（例えばクライアント端末３が存在する地域名を指定する）。ステップＳ１１０２において、管理者は図９で説明した画面上で、送信するメッセージを選択する。ステップＳ１１０３において、管理者は図９で説明した画面上で、送信順序を指定する。ステップＳ１１０４において、管理者は図９で説明した画面上で、メッセージを送信するよう配信装置２に対して指示する。
【００６４】
図１２は、配信装置２がメッセージを送信する処理を説明するフローチャートである。以下、図１２の各ステップについて説明する。
【００６５】
（図１２：ステップＳ１２０１）
送信順決定部２８は、管理者が図９で説明した画面上で指定した内容にしたがって、メッセージを送信するクライアント端末３の順序を決定する。
【００６６】
（図１２：ステップＳ１２０２）
自動送信部２９は、送信順決定部２８が決定した１番目の値を、メッセージの送信先として設定する。例えば配車先に対する距離が近い順に送信先を決定した場合、配車先に最も近いクライアント端末３が送信先として設定される。
【００６７】
（図１２：ステップＳ１２０３）
自動送信部２９は、返答待ち時間ｔｗを設定する。ｔｗの値はあらかじめ固定的に定めておくこともできるし、例えばメッセージ種別に応じて変えてもよい。メッセージ配信部２６は、送信するメッセージとそのメッセージＩＤを生成する。
【００６８】
（図１２：ステップＳ１２０４〜Ｓ１２０５）
メッセージ配信部２６は、実施形態１の図４で説明したフローチャートに準じてメッセージを送信する（Ｓ１２０４）。ただし本実施形態２においては、メッセージとメッセージＩＤに加えて、ステップＳ１２０３で設定された返答待ち時間ｔｗをこれらと併せて通信データ内に記述しておく。メッセージ配信部２６は、クライアント端末３の所持者が入力した返答を受信する（Ｓ１２０５）。
【００６９】
（図１２：ステップＳ１２０６）
メッセージ配信部２６は、ステップＳ１２０５において受信したクライアント端末３からの返答結果が、メッセージに対する肯定的な回答であるか否かを判定する。例えば図１０に示したメッセージ例においては、クライアント端末３の所持者が「ＯＫ」を回答したか否かを判定する。ＯＫであればステップＳ１２０８へ進み、それ以外であればステップＳ１２０７へ進む。
【００７０】
（図１２：ステップＳ１２０７）
自動送信部２９は、送信順決定部２８が決定した次順位の値を、メッセージの送信先として設定する。ステップＳ１２０３に戻って同様の処理を実施する。
【００７１】
（図１２：ステップＳ１２０８〜Ｓ１２０９）
クライアント端末３の所持者がＯＫを入力した時点で、メッセージの目的は果たされた（配車に応じる車両が決定された）ことになる。管理者端末１は、最終的に決定された車両を、図９（ｂ）のような画面上で表示する（Ｓ１２０８）。管理者端末１またはメッセージ配信部２６は、クライアント端末３に対して追加で送信すべき詳細情報があれば送付する（Ｓ１２０９）。
【００７２】
図１３は、クライアント端末３がメッセージを受信する処理を説明するフローチャートである。以下、図１３の各ステップについて説明する。
【００７３】
（図１３：ステップＳ１３０１〜Ｓ１３０３）
メッセージ受信部３６は、メッセージを待ち受け（Ｓ１３０１）、メッセージが到着するとこれを受信する（Ｓ１３０２）。メッセージを受信する処理は実施形態１で説明した図５と同様である。メッセージ受信部３６は、クライアント端末３の所持者がメッセージに対する返答を入力するのを待機する（Ｓ１３０３）。
【００７４】
（図１３：ステップＳ１３０４）
メッセージ受信部３６は、時間ｔｗ以内にメッセージに対する返答が入力されたか否かを判定する。入力がなかった場合はステップＳ１３０６に進み、あった場合はステップＳ１３０５に進む。
【００７５】
（図１３：ステップＳ１３０５〜Ｓ１３０６）
メッセージ受信部３６は、返答が入力された場合はその内容を配信装置２に対する返答メッセージとして設定する（Ｓ１３０５）。メッセージ受信部３６は、返答が入力されなかった場合はタイムアウトした旨の返答メッセージを設定する（Ｓ１３０６）。
【００７６】
（図１３：ステップＳ１３０７〜Ｓ１３０８）
メッセージ受信部３６は、サーバに返答メッセージを送信する（Ｓ１３０７）。メッセージ受信部３６は、配信装置２から受信すべき詳細情報がある場合はこれを受信する（Ｓ１３０８）。
【００７７】
図１４は、メッセージ配信部２６が送信するメッセージのデータ形式例である。実施形態１で説明したデータ形式に加えて、クライアント端末３が返答を入力待ちすべき時間を指定するｔｗフィールドが追加されている。
【００７８】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係るメッセージ配信システム１００において、配信装置２は返答待ち時間を指定した上で、返答を要するメッセージをクライアント端末３に対して送信し、クライアント端末３は返答内容を返信する。このような双方向通信において、配信装置２とクライアント端末３との間のＷｅｂＳｏｃｋｅｔ接続を確実に維持することにより、メッセージの伝達効率を高めることができる。
【００７９】
また、本実施形態２に係るメッセージ配信システム１００において、クライアント端末３の所持者がメッセージに対して肯定的な返答をしなかった場合は、配信装置２は他のクライアント端末３に対して同じメッセージを自動的に再送する。これにより、管理者の作業負担を軽減することができる。
【００８０】
＜実施の形態３＞
実施形態２においては、返答待ち時間ｔｗは原則として固定であるが、なるべく特定のクライアント端末３から肯定的な返答を得たい場合には、そのクライアント端末３については返答待ち時間を長めに設定して猶予時間を多く与えることが考えられる。そこで本発明の実施形態３においては、クライアント端末３またはその所持者の特性に応じて、返答待ち時間ｔｗを補正する構成例を説明する。その他の構成は実施形態２と同様であるため、以下では返答待ち時間ｔｗの補正に係る事項を中心に説明する。
【００８１】
返答待ち時間ｔｗを補正する場合、例えば問い合わせやクレームの要望内容に応えるのにより適合した人や車両からの返答をより長く待ち、そうでない人や車両からの返答はこれよりも短く待機すれば足りる。そこで本実施形態３において、配信装置２はクライアント端末３またはその所持者の特性と補正時間との間の対応関係を記述した補正テーブルを保持しておく。管理者は管理者端末１を介してこれを参照し、メッセージを送信するクライアント端末３に応じてｔｗを補正することができる。あるいは補正テーブルの記述にしたがってメッセージ配信部２６がｔｗの値を自動補正してもよい。
【００８２】
図１５は、補正テーブル２３１の構成とデータ例を示す図である。補正テーブル２３１は、補正対象項目２３１１、補正条件２３１２、補正値２３１３を有する。補正対象項目２３１１は、クライアント端末３またはその所持者の特性のうちｔｗを補正する対象となるものを列挙するフィールドである。補正条件２３１２は、ｔｗを補正するか否かの条件を記述している。補正値２３１３はｔｗを増減補正する値である。
【００８３】
図１５に示す例においては、例えば訪問先に対する距離が近いクライアント端末３に対して優先的に指示を割り当てるため、訪問先からの距離が近い場合はｔｗの値を加算補正している。メッセージ配信部２６（または自動送信部２９）は、補正後のｔｗを反映したメッセージをクライアント端末３に対して送信する。
【００８４】
＜実施の形態３：まとめ＞
以上のように、本実施形態３に係るメッセージ配信システム１００において、配信装置２は、クライアント端末３またはその所持者の特性に応じて返答待ち時間ｔｗを補正するための補正テーブルを備え、これに基づきｔｗを補正した上でメッセージを送信する。これにより、送信順決定部２８が決定した順序にしたがってメッセージを自動送信しつつ、より望ましい送信先を選択することができる。
【００８５】
＜実施の形態４＞
本発明の実施形態４では、以上の実施形態１〜３における各機能部の変形例について説明する。
【００８６】
実施形態２〜３において、メッセージ配信部２６は、クライアント端末３からメッセージ内容に対する否定的な返答を所定期間内に受信した回数をカウントしておき、これがあらかじめ定めた上限に達した場合は、否定的返答を選択させない、すなわち返答選択肢がＯＫのみであるメッセージを送信するようにしてもよい。具体的には、メッセージ配信部２６が送信するメッセージ自体を、ＯＫ以外の返答を許可しないように構成することもできるし、メッセージ内にはＯＫ以外の返答を許可しない旨のフラグを記載しておき、入力部３８がＯＫ以外の返答を受け付けないようにしてもよい。
【００８７】
実施形態１〜３において、クライアント端末３から配信装置２に対して返答メッセージなどを送信する際に、実施形態１で説明したものと同様の受信確認応答を用いて、返答メッセージが到達したか否かをクライアント端末３側で確認するようにしてもよい。また、クライアント端末３から別のクラアイント端末３にメッセージを送信する際にも、同様の到達確認を実施してもよい。
【００８８】
実施形態２〜３において、入力部３８として、音声入力などの画面操作以外の手段を用いてもよい。
【００８９】
実施形態１〜３において、必ずしも全てのメッセージについて受信確認応答を要求する必要はなく、例えば重要ではないメッセージについてはこれを省略してもよい。
【００９０】
実施形態１〜３において、クライアント端末３は所持者が手で保持してもよいし、車両管理システムのように車両と対応させる場合には車載端末として構成してもよい。
【００９１】
実施形態３において、メッセージ内容に関する優先度が高い宛先、すなわち補正値２３１３が正値である場合には、返答待ち時間ｔｗを超過してからさらに一定時間が経過した後に、同じメッセージを再送してもよい。
【００９２】
実施形態２〜３において、必ずしも１台ずつメッセージを送信する必要はない。例えばまず所定範囲内に存在する複数のクライアント端末３に対して仮メッセージを送信し、返答のあったクライアント端末３に対して、本来のメッセージを順次送信するようにしてもよい。
【００９３】
実施形態１〜３では、管理者が管理者端末１上でメッセージ送信を指示することを説明したが、これを省略するため、例えば一般の携帯電話またはパーソナルコンピュータ利用者が、クライアント端末３に対してメッセージを直接送付してもよい。この場合は送信元端末が配信装置２と同様の構成を備える。
【００９４】
実施形態２〜３において、複数のクライアント端末３が共同して対処すべきメッセージを送信する場合が考えられる。この場合は例えば、ステップＳ１２０６において、そのメッセージに対して対処するのに必要な人数分のＯＫが得られるまで待機するようにすればよい。
【００９５】
実施形態１〜３において、クライアント端末３から配信装置２に対してメッセージを送信する場合においても、配信装置２からクライアント端末３に対してメッセージを送信する際と同様の処理を実施してもよい。クライアント端末３同士でメッセージを送受信する場合においても同様である。
【００９６】
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。
【００９７】
上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【符号の説明】
【００９８】
１：管理者端末、１１：通信ポート、１２：ＣＰＵ、１３：メモリ、１４：操作送信部、１５：表示部、２：配信装置、２１：通信ポート、２２：ＣＰＵ、２３：メモリ、２４：操作応答部、２５：サーバ側通信部、２６：メッセージ配信部、２７：サーバ側接続維持部、２８：送信順決定部、２９：自動送信部、３：クライアント端末、３１：通信ポート、３２：ＣＰＵ、３３：メモリ、３４：表示部、３５：クライアント側通信部、３６：メッセージ受信部、３７：クライアント側接続維持部、３８：入力部、１００：メッセージ配信システム。
【図１】
2014170288.tif 000003
【図２】
2014170288.tif 000004
【図３】
2014170288.tif 000005
【図４】
2014170288.tif 000006
【図５】
2014170288.tif 000007
【図６】
2014170288.tif 000008
【図７】
2014170288.tif 000009
【図８】
2014170288.tif 000010
【図９】
2014170288.tif 000011
【図１０】
2014170288.tif 000012
【図１１】
2014170288.tif 000013
【図１２】
2014170288.tif 000014
【図１３】
2014170288.tif 000015
【図１４】
2014170288.tif 000016
【図１５】
2014170288.tif 000017