JP6823740B2 - メッセージ管理サーバ、メッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システム - Google Patents

Description

この発明は、メッセージ管理サーバ、メッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムに関する。

近年、携帯電話端末のユーザ同士でのメッセージ送信や、企業からユーザへの広告配信などに携帯電話サービスを提供する各通信事業者により提供されるショートメッセージサービス（ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ））が活用されている。ショートメッセージサービスは、電子メールに使用されるトラフィックチャネルを使用せず、シグナリングチャネルを用いて、宛先に受信先となる携帯電話端末の電話番号を指定してメッセージを送信するサービスである。宛先として携帯電話端末の電話番号を用いることにより、ユーザはメッセージの送信先となるユーザの電話番号だけでメッセージを送信することができる。また、シグナリングチャネルは、トラフィックチャネルに用いられる通信プロトコルよりも軽量かつ単純な通信プロトコルが用いられるため、ショートメッセージサービスにより送信されるメッセージ（以下、ショートメッセージという。）はリアルタイム性に優れるというメリットもある。一方で、ショートメッセージの場合には、電話回線を用いた軽量な通信プロトコルが使用されるため、１回あたりの通信容量が制限されるというデメリットもある。例えば、１回で送信可能なショートメッセージの文字は６０字〜８０字程度であるため、これを超える文字数である場合には、複数回に分けて送信する必要があり、また、画像は送信できないなどの制約があった。

そこで、ショートメッセージと同様に、携帯電話端末の電話番号を宛先として用いつつも、より大きい通信容量を１回で送受信可能としたリッチコミュニケーションサービス（ＲＣＳ（Ｒｉｃｈ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ））が開発されている（例えば、特許文献１参照。）。リッチコミュニケーションサービスは、ショートメッセージで送信可能な文字数より多い文字数からなるテキストや、高解像度の画像の送受信、ファイル共有、グループチャットやＩＰ電話、ビデオ通話、イメージシェアリングなども含めた総合的なコミュニケーション・サービス仕様になっている。

しかし、リッチコミュニケーションサービスを用いて送信されたメッセージ（以下、リッチコミュニケーションメッセージという。）は、リッチコミュニケーションサービスのアプリケーションがインストールされている携帯電話端末でしかメッセージを受信できないという問題がある。一方で、リッチコミュニケーションメッセージは、ショートメッセージと互換性があるので、受信側の携帯電話端末にリッチコミュニケーションサービスのアプリケーションがインストールされていない場合、メッセージを配信した配信サーバに送信エラーがフォールバックされる。この場合、配信サーバは、リッチコミュニケーションメッセージをショートメッセージで用いられるプロトコルに変換して、リッチコミュニケーションメッセージをショートメッセージにより一度で送信可能な容量に分割して、複数回に分けてショートメッセージを受信側の携帯電話端末に送信する。

特表２０１８−５０６７９３号公報

しかしながら、リッチコミュニケーションメッセージでは、１回に送信可能な文字数が６００文字超であるので、これをショートメッセージに分割して複数回送信すると、多い場合には１０通程度のメッセージを送信することとなってしまい、受信側のユーザがメッセージを開封して読むことが煩雑となる。ショートメッセージの受信には、１回の受信ごとに料金が発生するため、受信側のユーザとしては複数のメッセージの受信を拒否したいという要望がある。とりわけ、Ｂ ｔｏ Ｃ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｃｏｎｓｕｍｅｒ）企業が、顧客にメッセージを配信する際には、顧客側に負担を強いることを避けたいという要望がある。

そこで、本発明は、受信側の携帯電話端末においてデータを受信できない場合であっても、受信側のユーザに煩雑な手間や経済的負担を発生させることなく、送信側が要望する多彩なデータの送受信を提供することができるメッセージ管理サーバ、メッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムを提供することを目的とする。

上記課題を解決するため、本発明に係るメッセージ管理サーバは、携帯電話端末の電話番号を使用したメッセージサービスを提供するメッセージ管理サーバであって、携帯電話端末の電話番号と、携帯電話端末のユーザの電子メールアドレスと前記電話番号に紐づくチャットＩＤの少なくともいずれか一つとを対応付けて記憶する記憶部と、第一のプロトコルが用いられる第一のメッセージを携帯電話端末に配信する配信部と、配信部による第一のメッセージの送信エラーを受信するエラー受信部と、エラー受信部により送信エラーを受信した場合に、所定の条件に基づいて、第一のプロトコルとは異なり、かつ、第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージまたは電子メールまたはチャットシステムの少なくともいずれか一つメッセージツールを用いて第一のメッセージに含まれるデータを携帯電話端末に再送するかを決定する決定部と、決定部により決定されたメッセージツールに第一のメッセージに含まれるデータを当該メッセージツールのデータ形式に変換する変換部と、を備え、配信部は、変換部により変換されたデータを携帯電話端末に配信すること、を特徴とする。

本発明によれば、受信側の携帯電話端末においてリッチコミュニケーションメッセージを受信できない場合には、リッチコミュニケーションメッセージを電子メールに変換して送信するので、受信側の携帯電話端末においてデータを受信できない場合であっても、受信側のユーザに煩雑な手間や経済的負担を発生させることなく、送信側が要望する多彩なデータの送受信を提供することができる。

本発明の実施形態１〜４に係るメッセージ管理システムの構成を示すシステム図である。 本発明の実施態様１におけるメッセージ管理サーバの機能構成例を示すブロック図である。 本実施形態１におけるユーザ情報の一例を示す図である。 実施形態１におけるショートメッセージの一例を示す図である。 実施形態１におけるリッチコミュニケーションメッセージの一例を示す図である。 実施形態１におけるユーザ端末と、メッセージ管理サーバと、ユーザ端末とによるリッチコミュニケーションメッセージの送信処理の流れを示すシーケンス図である。 実施形態２におけるメッセージ管理サーバの機能構成例を示すブロック図である。 図８（ａ）は、実施形態１における機種情報の一例を示す図であり、図８（ｂ）は、実施形態２におけるインストール情報の一例を示す図である。 実施形態２におけるユーザ端末と、メッセージ管理サーバと、ユーザ端末とによるリッチコミュニケーションメッセージの送信処理の流れを示すシーケンス図である。 実施形態２におけるユーザ端末と、メッセージ管理サーバと、ユーザ端末とによるリッチコミュニケーションメッセージの送信処理の他の例を示すシーケンス図である。 実施形態３におけるメッセージ管理サーバの機能構成例を示すブロック図である。 図１２（ａ）は、実施形態３における属性情報の一例を示す図である。図１２（ｂ）および図１２（ｃ）は、実施形態２におけるメッセージツール情報の一例を示す図である。図１２（ｄ）は、実施形態３におけるレスポンス情報の一例を示す図である。 実施形態３におけるメッセージ配信要求サーバと、メッセージ管理サーバと、ユーザ端末とによるメッセージの配信処理の流れを示すシーケンス図である。 実施形態３におけるメッセージ配信要求サーバと、メッセージ管理サーバと、ユーザ端末とによるメッセージの配信処理の流れを示すシーケンス図である。 実施形態４におけるメッセージ管理サーバの機能構成例を示すブロック図である。 実施形態４におけるメッセージ配信要求サーバと、メッセージ管理サーバと、ユーザ端末とによるメッセージの配信処理の流れを示すシーケンス図である。 実施形態４におけるメッセージ配信要求サーバと、メッセージ管理サーバと、ユーザ端末とによるメッセージの配信処理の流れを示すシーケンス図である。 実施形態４におけるチャット画面の一例を示す図である。 実施形態１〜４におけるメッセージ管理サーバを実現可能なコンピュータの一例を示すハードウェア構成図である。

（実施形態１）
図１は、本発明の実施の形態に係るメッセージ管理システムの全体構成を示すシステム図である。図１に示すように、メッセージ管理システム１は、メッセージ配信要求サーバ３００がメッセージ管理サーバ１００とネットワーク１０を介して相互に通信可能に接続されており、メッセージ管理サーバ１００はモバイルネットワーク１１を介してユーザ端末２００と相互に通信可能に接続されている。メッセージ配信要求サーバメッセージ配信要求サーバ例えば、ネットワーク１０、モバイルネットワーク１１は、有線ネットワークや無線ネットワークであってもよい。なお、図１では、ユーザ端末２００ａ〜ユーザ端末２００ｃの３台を図示するが、さらに複数台あってもよい（以下、特に明示する場合を除き、ユーザ端末２００と総称する。）。

メッセージ管理サーバ１００は、メッセージ配信要求サーバ３００からユーザ端末２００に配信されるショートメッセージ、リッチコミュニケーションメッセージ、電子メールなどのメッセージの配信を管理する。例えば、メッセージ管理サーバ１００には、ユーザ端末２００のユーザの個人情報などに関するユーザ情報、メッセージの送受信のエラーや、ユーザ端末２００におけるメッセージに対するレスポンス（例えば、メッセージに含まれるＵＲＬリンクへのアクセス）などに関する通信情報などが管理される。また、ユーザ端末２００は、スマートフォンなどの携帯電話端末であって、本発明における携帯電話端末に相当する。また、メッセージ配信要求サーバは、Ｂ ｔｏ Ｃ企業など、企業と個人（消費者）間の商取引、あるいは、個人向けに行う事業を行う企業などである。なお、リッチコミュニケーションメッセージは、本発明における第一のメッセージに相当し、ショートメッセージは本発明における第二のメッセージに相当する。

図２は、本発明の実施形態１におけるメッセージ管理サーバ１００の機能構成例を示すブロック図である。図２に示すように、メッセージ管理サーバ１００は、制御部１１０と、通信制御部１２０と、記憶部１３０とを備える。

通信制御部１２０は、通信回線や電話回線等に接続されるアンテナやルータ等の通信装置（図示せず）に接続されるインターフェースである。すなわち、通信制御部１２０は、ユーザ端末２００や、メッセージ配信要求サーバ３００等のような外部装置と通信回線を介してデータを通信する機能を有している。

記憶部１３０は、ユーザ情報データベース１３１と、メッセージ情報データベース１３２とを記憶する。ユーザ情報データベース１３１には、ユーザ情報が格納されている。ここで、ユーザ情報とは、ユーザの個人情報や、当該ユーザが利用するユーザ端末２００の端末に関する情報である。ユーザの個人情報としては、少なくともユーザの氏名、生年月日、性別が含まれ、端末に関する情報には、ユーザ端末２００の電話番号、ユーザ端末２００の端末識別情報が少なくとも含まれる。ユーザの個人情報には、ユーザが利用可能な通信サービスに関する識別情報（アカウントＩＤ）が含まれてもよく、同種であっても異なる通信サービスであれば、通信サービスごとの情報が含まれてよい。図３は、実施形態１におけるユーザ情報の一例を示す図である。図３では、ユーザの氏名「山田〇〇」に、ユーザの生年月日である１９７８年１月１日を示す「１９７８０１０１」、ユーザの住所「東京都港区〇〇」、ユーザの電話番号「０９０−００００−００００」、ユーザが利用するユーザ端末２００の識別情報を示す端末ＩＤ「ＸＤＲ１２３４５６」、ユーザ端末２００の機種の識別情報を示す機種ＩＤ「ＸＹＺ００１」、ユーザの電子メールアドレスを示すＥｍａｉｌ「ｙａｍａｄａ＠...」と、ユーザが利用しているチャットＡ＿ＩＤ「ｙａｍ０１０１」と、チャットＢ＿ＩＤ「ｙａｍａ０１６」と、が対応付けられている。なお、端末ＩＤは、各ユーザ端末２００に付与される端末固有の識別情報であり、機種ＩＤは、ユーザ端末２００の機種の識別情報であるため端末固有ではない。また、メッセージ情報データベース１３２には、メッセージ情報が格納されている。ここで、メッセージ情報とは、リッチコミュニケーションメッセージに対応するリッチコミュニケーションメッセージに含まれるデータが要約されたショートメッセージであり、例えば、ショートメッセージがクラウドにアップロードされている場合には、メッセージ情報データベース１３２に当該ショートメッセージにアクセス可能なＵＲＬが記憶されることとしてもよい。なお、メッセージ情報データベース１３２に格納されているメッセージ情報であるショートメッセージは、送信先となるユーザ端末２００がリッチコミュニケーションメッセージを受信できない場合に、リッチコミュニケーションメッセージに代えて送信に用いられるメッセージである。また、チャットＡ＿ＩＤ、チャットＢ＿ＩＤは、ユーザが利用しているチャットシステムにおけるユーザの識別情報であり、チャットシステムは、ユーザが利用可能な通信ツールの一種であり、ユーザ端末２００がリッチコミュニケーションメッセージを受信できない場合などにその代替の通信ツールとして利用することができる。

制御部１１０は、受付部１１１と、決定部１１２と、変換部１１３と、取得部１１４と、送受信部１１５とを備える。なお、送受信部１１５は、本発明におけるエラー受信部と、配信部に相当する。

送受信部１１５は、ユーザ端末２００やメッセージ配信要求サーバ３００などの外部端末または外部装置との間で各種情報を送受信する。例えば、送受信部１１５は、メッセージ配信要求サーバ３００から、ユーザ端末２００へのメッセージ配信依頼を受信し、メッセージの配信先となるユーザ端末２００に送信する。ここで、メッセージ配信依頼とは、ショートメッセージ、リッチコミュニケーションメッセージ、電子メールなどのメッセージと、宛先となる携帯電話番号または電子メールアドレスを含むメッセージを、送信先となるユーザ端末２００に送信する旨の依頼である。また、ショートメッセージおよびリッチコミュニケーションメッセージはともに、宛先としてユーザ端末２００の携帯電話番号が用いられるので相互に互換性を有する。ショートメッセージのデータ容量は、所定文字数以内（例えば、７０文字〜１００文字など。）のテキストに限定されるが、リッチコミュニケーションメッセージはショートメッセージのデータ容量よりも大きくテキストに限定されない。このため、リッチコミュニケーションメッセージによれば、動画や音源などを添付することも可能となる。

図４は、実施形態１におけるショートメッセージの一例を示す図である。図４では、ユーザ端末２００の画面２１０に、航空会社からの搭乗の事前案内を示すメッセージが表示されている。画面２１０に表示されているショートメッセージは、テキストだけで構成されており、テキストの文字数は１００文字以下に留められている。このため、文面は極力短文化され、厳選された必要最低限の情報として、航空会社名、「ご予約された５月５日ＪＡ０７８便についての事前のご案内です」というメッセージ、および予約番号だけが表示されている。一方、図５は、実施形態１におけるリッチコミュニケーションメッセージの一例を示す図である。図５においても、ユーザ端末２００の画面２１０に、航空会社からの搭乗の事前案内を示すメッセージが表示されている。画面２１０に表示されているリッチコミュニケーションメッセージは、できるだけユーザが読みやすい表示形式で、また、図４に示したショートメッセージよりも詳細な情報として、「出発時刻：１２：００」、「ご搭乗ゲート：２５」、「座席番号：Ａ８８」、搭乗に際しての注意事項「チェックインは出発時刻の２０分前までにお済ませください。」という文面、さらに、Ｅチケットが表示されている。なお、Ｅチケットは、バーコードやＱＲコードなどの二次元コードであってもよい。

また、送受信部１１５は、メッセージ配信要求サーバ３００から顧客のユーザ端末２００へのメッセージ配信依頼を受信する。ここで、メッセージ配信依頼とは、同一または個別のメッセージを顧客のユーザ端末２００に一斉配信、または個別配信する依頼のことであり、メッセージ配信依頼には、配信先の宛先とメッセージが含まれる。また、送受信部１１５は、メッセージ配信要求サーバ３００からメッセージ配信依頼を受信した場合に、メッセージ配信依頼に含まれる宛先にメッセージを送信する。例えば、メッセージ配信依頼に含まれる宛先は携帯電話番号であり、リッチコミュニケーションメッセージが含まれる場合には、配信部は、当該携帯電話番号を宛先として、リッチコミュニケーションを配信する。

また、送受信部１１５は、送信先となるユーザ端末２００においてリッチコミュニケーションメッセージが受信できなかった場合に、送信が失敗した旨を示す送信エラーＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）応答を受信する。また、送受信部１１５は、送信エラーＡＣＫ応答を受信した場合に、変換部１１３により変換された電子メール、または取得部１１４によりメッセージ情報データベース１３２から取得されたショートメッセージを送信先となるユーザ端末２００に送信する。

受付部１１１は、送受信部１１５を介してユーザ端末２００やメッセージ配信要求サーバなどの外部端末または外部装置から各種依頼を受け付ける。例えば、受付部１１１は、ユーザ端末２００からメッセージ送信依頼や、メッセージ配信要求サーバ３００から配信依頼を受け付ける。

決定部１１２は、送受信部１１５により送信エラーＡＣＫを受信した場合に、所定の条件に基づいて、ショートメッセージまたは電子メールのいずれのメッセージツールを用いてリッチコミュニケーションメッセージに含まれるデータ、または、リッチコミュニケーションメッセージを送信先となるユーザ端末２００に送信不可能な場合に対応するショートメッセージをユーザ端末２００に再送するかを決定する。例えば、決定部１１２は、メッセージ配信要求サーバ３００やユーザ端末２００によりあらかじめ指定されている場合には、当該指定によりショートメッセージまたは電子メールのいずれをメッセージツールとして用いるかを決定する。また、決定部１１２は、リッチコミュニケーションメッセージを送信先となるユーザ端末２００に送信不可能な場合には、メッセージ情報データベース１３２を参照し、リッチコミュニケーションメッセージに対応するショートメッセージをユーザ端末２００に再送することとなる。なお、ユーザ端末２００またはメッセージ配信要求サーバ３００からのリクエストなどにより、リッチコミュニケーションメッセージが配信できない場合には、ショートメッセージも電子メールも再送しない旨が指定されているような場合には、決定部１１２は、いずれのメッセージも再送しないことと決定する。

変換部１１３は、送受信部１１５が送信エラーＡＣＫ応答を受信した場合に、リッチコミュニケーションメッセージに含まれるメッセージのデータを、決定部１１２により決定されたメッセージツールであるショートメッセージまたは電子メールのデータ形式に変換する。具体的には、変換部１１３は、送受信部１１５が送信エラーＡＣＫ応答を受信した場合に、送信元となるユーザ端末２００から受信したリッチコミュニケーションメッセージの送受信を可能とするプロトコルを用いて生成されたリッチコミュニケーションメッセージを、ショートメッセージまたは電子メールのプロトコルを用いてショートメッセージまたは電子メールのメッセージを生成する。例えば、変換部１１３は、リッチコミュニケーションメッセージの宛先となる携帯電話番号に対応する電子メールアドレスをユーザ情報データベース１３１から取得し、取得した電子メールアドレスを生成した電子メールのメッセージに含める。なお、変換部１１３は、送受信部１１５が送信エラーＡＣＫ応答を受信した場合に、リッチコミュニケーションメッセージに含まれるメッセージのデータをショートメッセージのデータに変換する際、変換部１１３は、リッチコミュニケーションメッセージに含まれるデータを全てショートメッセージにより１回で送信可能なデータ容量に分割するだけでなく、あらかじめ用意されたショートメッセージ用のメッセージを、送受信部１１５を介して送信先となるユーザ端末２００に送信してもよい。例えば、送受信部１１５は、後述する取得部１１４により取得されたメッセージ情報データベース１３２に保存されているリッチコミュニケーションメッセージに対応するショートメッセージを送信することとしてもよい。リッチコミュニケーションメッセージに対応するショートメッセージとは、図５に示したリッチコミュニケーションメッセージを、あらかじめ用意されたショートメッセージ用のメッセージとして、図４に示したショートメッセージのようにショートメッセージにより１回で送信可能な容量のメッセージとして必要最低限の内容が含まれるメッセージを送信することができる。なお、リッチコミュニケーションメッセージを送信先となるユーザ端末２００において受信できない場合において、後述する取得部１１４によりメッセージ情報データベース１３２からリッチコミュニケーションメッセージに対応するショートメッセージが取得される場合には、変換部１１３による処理は行われない。

取得部１１４は、送受信部１１５により送信先となるユーザ端末２００においてリッチコミュニケーションメッセージの受信ができなかった場合に、メッセージ情報データベース１３２から、当該リッチコミュニケーションメッセージに対応するショートメッセージを取得する。ここで、取得部１１４は、メッセージ情報データベース１３２かたショートメッセージを取得してもいいし、または、ショートメッセージの所在を示すＵＲＬからショートメッセージを取得してもよい。

次に、メッセージ配信要求サーバ３００ａからユーザ端末２００にメッセージを送信する例を用いて、メッセージ配信要求サーバ３００と、メッセージ管理サーバ１００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理について説明する。図６は、実施形態１におけるメッセージ配信要求サーバ３００と、メッセージ管理サーバ１００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理の流れを示すシーケンス図である。

メッセージ配信要求サーバ３００は、リッチコミュニケーションメッセージをメッセージ管理サーバ１００に送信する（ステップＳ１）。メッセージ管理サーバ１００は、ユーザ端末２００にステップＳ１において受信したリッチコミュニケーションメッセージを、送信先となるユーザ端末２００に送信する（ステップＳ２）。ここで、ユーザ端末２００がステップＳ２において送信されたリッチコミュニケーションメッセージを受信できなかった場合、ユーザ端末２００ｂは、メッセージ管理サーバ１００に送信エラーＡＣＫを送信する（ステップＳ３）。メッセージ管理サーバ１００は、送信エラーＡＣＫ応答を受信する（ステップＳ４）。メッセージ管理サーバ１００は、ステップＳ１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをＥｍａｉｌ形式のメッセージに変換する（ステップＳ５）。メッセージ管理サーバ１００は、ステップＳ５において変換したＥｍａｉｌをユーザ端末２００に送信する（ステップＳ６）。

このように、実施形態１におけるメッセージ管理サーバ１００によれば、送信先となるユーザ端末２００へのリッチコミュニケーションメッセージの送信がエラーとなった場合に、電子メールに変換して再送信するので、送信先となるユーザ端末２００のユーザに煩雑な手間や経済的負担を発生させることなく、送信側が要望する多彩なデータを送信することができる。例えば、リッチコミュニケーションメッセージの送信がエラーとなった場合に、複数のショートメッセージが複数回にわたって送信先となるユーザ端末２００に送信されるとすると、本来であれば１件のメッセージを確認することで閲読や管理ができるところ、ユーザに複数のメッセージを確認する手間が発生することとなる。また、ショートメッセージの受信には１回の受信ごとに通信費用が発生するので、複数のメッセージを受信する場合、通信費用が増大することとなる。

（実施形態２）
実施形態１において、メッセージ管理サーバ１００は、リッチコミュニケーションメッセージの送信エラーＡＣＫ応答を受信した場合に、リッチコミュニケーションメッセージを電子メールに変換して送信する構成であった。実施形態２においては、通信効率をより向上すべく、リッチコミュニケーションメッセージの送信エラーＡＣＫ応答を不要とする構成を説明する。実施形態２における全体構成は実施形態１において図１を用いて説明した全体構成と同様である。

図７は、実施形態２におけるメッセージ管理サーバ４００の機能構成例を示すブロック図である。図７に示すように、メッセージ管理サーバ４００は、制御部４１０と、通信制御部１２０と、記憶部４３０とを備える。なお、実施形態１と同様の構成および機能については、同一の符号を付して説明を省略する。

記憶部４３０は、ユーザ情報データベース１３１と、機種情報データベース４３１と、インストール情報データベース４３３とを記憶する。機種情報データベース４３２には、機種情報が格納されている。ここで、機種情報とは、ユーザ端末２００の機種が、リッチコミュニケーションメッセージの受信が可能であるか否かを示す情報であり、例えば、機種の識別情報を示す機種ＩＤに、リッチコミュニケーションメッセージの受信の可否が対応付けられている。図８（ａ）は、実施形態１における機種情報の一例を示す図である。図８（ａ）に示すように、ユーザ端末２００の機種を識別する機種ＩＤ「ＸＹＺ００１」には、リッチコミュニケーションサービスを受信可能な機種であるか否かを示すＲＣＳ受信可否「可」が、また、機種ＩＤ「ＸＹＺ００３」には、ＲＣＳ受信可否「不可」がそれぞれ対応付けられている。また、機種ＩＤ「ＸＹＺ００１」には、チャットサービスを受信可能な機種であるか否かを示すチャット受信可否「不可」が、また、機種ＩＤ「ＸＹＺ００２」には、チャット受信可否「可」がそれぞれ対応付けられている。本実施形態では、リッチコミュニケーションメッセージで送信されたメッセージをユーザ端末が受信可能かどうかを、図８に示す機種情報を用いてその送信前に判断し、「可」である場合にそのまま送信し、「不可」の場合に送信しないか、他の通信サービスに変換して送信する例を説明するが、これは、チャットシステムによりメッセージが送信された場合であっても同様である。

また、インストール情報データベース１３３には、インストール情報が格納されている。ここで、インストール情報とは、ユーザ端末２００にリッチコミュニケーションサービスのアプリケーションがインストールされているか否かを示す情報であり、例えば、ユーザ端末２００の携帯電話番号に、リッチコミュニケーションサービスのアプリケーションのインストールの有無が対応付けられている。その他の例としては、チャットシステムに関するアプリケーションのインストールの有無が対応付けられていてもよい。図８（ｂ）は、実施形態２におけるインストール情報の一例を示す図である。図８（ｂ）に示すように、ユーザ端末２００の携帯電話番号「０９０−０００−００００」に、リッチコミュニケーションサービスのアプリケーションのインストールの有無を示すＲＣＳインストール有無「無」が対応付けられており、チャットシステムＡに関するアプリケーションのインストール有無「有」が対応付けられている。チャットシステムに関するアプリケーションのインストールの有無に係る情報は、メッセージ配信要求サーバからチャットによるメッセージが送信された場合に利用することができる。

制御部４１０は、受付部１１１と、決定部４１１と、取得部４１３と、変換部１１３と、判定部４１２と、取得部１１４と、送受信部１１５とを備える。

取得部４１３は、受付部１１１によりメッセージ送信依頼が受け付けられた場合に、機種情報データベース４３２またはインストール情報データベース４３３を参照し、機種情報またはインストール情報を取得する。具体的には、取得部４１３は、ユーザ情報データベース１３１からメッセージ送信依頼に含まれる宛先となる携帯電話番号に対応する機種ＩＤを取得し、機種情報データベース４３２から機種ＩＤに対応するリッチコミュニケーションメッセージの受信可否を示す情報を取得する。または、取得部４１３は、インストール情報データベース４３３から、メッセージ送信依頼に含まれる宛先となる携帯電話番号に対応するリッチコミュニケーションサービスのアプリケーションのインストールの有無を示す情報を取得する。

判定部４１２は、送受信部１１５によりメッセージ送信依頼を受信した場合に、送信先となるユーザ端末２００がリッチコミュニケーションメッセージの受信をできるか否かを判定する。具体的には、判定部４１２は、取得部４１３により取得された機種ＩＤに対応するリッチコミュニケーションメッセージの受信可否を示す情報が受信可を示すか否かを判定する。または、判定部４１２は、送受信部１１５によりメッセージ送信依頼を受信した場合に、送信先となるユーザ端末２００にアプリケーションがインストールされているか否かを判定する。具体的には、判定部４１２は、取得部４１３により取得された送信先となるユーザ端末２００携帯電話番号に対応するインストール情報がインストール無を示すか否かを判定する。

決定部４１１は、判定部４１２により、ユーザ端末２００の機種ＩＤがリッチコミュニケーションメッセージを送受信できない端末であると判定された場合に、所定の条件に基づいて、ショートメッセージまたは電子メールのいずれのメッセージツールを用いてリッチコミュニケーションメッセージに含まれるデータをユーザ端末２００に再送するかを決定する。例えば、決定部４１１は、メッセージ配信要求サーバ３００やユーザ端末２００によりあらかじめ指定されている場合には、当該指定によりショートメッセージまたは電子メールのいずれをメッセージツールとして用いるかを決定する。なお、ユーザ端末２００またはメッセージ配信要求サーバ３００からのリクエストなどにより、リッチコミュニケーションメッセージが配信できない場合には、ショートメッセージも電子メールも再送しない旨が指定されているような場合には、決定部４１１は、いずれのメッセージも再送しないことと決定する。

次に、メッセージ配信要求サーバ３００からユーザ端末２００にメッセージを送信する例を用いて、メッセージ配信要求サーバ３００と、メッセージ管理サーバ１００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理について説明する。図９は、実施形態２におけるメッセージ配信要求サーバ３００と、メッセージ管理サーバ１００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理を示すシーケンス図である。

メッセージ配信要求サーバ３００は、メッセージ管理サーバ４００にリッチコミュニケーションメッセージを送信する（ステップＳ１１）。メッセージ管理サーバ４００は、ステップＳ１１においてリッチコミュニケーションメッセージを受信すると、ユーザ端末２００がリッチコミュニケーションメッセージを受信可能な端末であるか否かを判定する（ステップＳ１２）。具体的には、メッセージ管理サーバ４００の判定部４１２は、メッセージ管理サーバ４００の記憶部１３０に記憶されている機種情報データベース４３２を参照し、ユーザ端末２００がリッチコミュニケーションサービスを送受信可能な機種であるか否かを判定する。メッセージ管理サーバ４００は、ステップＳ１４において、ユーザ端末２００がリッチコミュニケーションサービスを送受信可能な機種であると判定された場合に、ユーザ端末２００にステップＳ１１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをユーザ端末２００に送信する（ステップＳ１３）。なお、ステップＳ１２において、メッセージ管理サーバ４００が、ユーザ端末２００がリッチコミュニケーションサービスを送受信できない機種であると判定した場合には、メッセージ管理サーバ４００はユーザ端末２００にステップＳ１１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをユーザ端末２００に送信しない。または、ステップＳ１２において、メッセージ管理サーバ４００が、ユーザ端末２００がリッチコミュニケーションサービスを送受信できない機種であると判定した場合であっても、ステップＳ１１において受信したリッチコミュニケーションメッセージのデータ容量が、ショートメッセージにおいて１回で送信可能な容量である場合には、メッセージ管理サーバ４００はメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをショートメッセージに変換し、変換したショートメッセージをユーザ端末２００に送信することとしてもよい。

また、メッセージ配信要求サーバ３００からユーザ端末２００にメッセージを送信する他の例を用いて、メッセージ配信要求サーバ３００と、メッセージ管理サーバ４００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理について説明する。図１０は、実施形態２におけるメッセージ配信要求サーバ３００と、メッセージ管理サーバ４００と、ユーザ端末２００とによるリッチコミュニケーションメッセージの送信処理の他の例を示すシーケンス図である。

メッセージ配信要求サーバ３００は、メッセージ管理サーバ４００にリッチコミュニケーションメッセージを送信する（ステップＳ２１）。メッセージ管理サーバ４００は、ステップＳ２１においてリッチコミュニケーションメッセージを受信すると、ユーザ端末２００がリッチコミュニケーションメッセージを受信可能な端末であるか否かを判定する（ステップＳ２２）。具体的には、メッセージ管理サーバ４００の判定部４１２は、メッセージ管理サーバ４００の記憶部１３０に記憶されているインストール情報データベース１３３を参照し、ユーザ端末２００がリッチコミュニケーションサービスのアプリケーションがインストールされているか否かを判定する。メッセージ管理サーバ４００は、ステップＳ１４において、ユーザ端末２００にリッチコミュニケーションサービスのアプリケーションがインストールされていると判定された場合に、ユーザ端末２００にステップＳ１１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをユーザ端末２００に送信する（ステップＳ２３）。なお、ステップＳ１２において、メッセージ管理サーバ４００が、ユーザ端末２００にリッチコミュニケーションサービスのアプリケーションがインストールされていないと判定した場合には、メッセージ管理サーバ４００はユーザ端末２００にステップＳ１１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをユーザ端末２００に送信しない。または、ステップＳ２２において、メッセージ管理サーバ４００が、ユーザ端末２００にリッチコミュニケーションサービスのアプリケーションがインストールされていないと判定した場合であっても、ステップＳ２１において受信したリッチコミュニケーションメッセージのデータ容量が、ショートメッセージにおいて１回で送信可能な容量である場合には、メッセージ管理サーバ４００はメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージをショートメッセージに変換し、変換したショートメッセージをユーザ端末２００に送信することとしてもよい。

このように、実施形態２におけるメッセージ管理サーバ４００によれば、送信先となるユーザ端末２００にメッセージを送信する前に当該ユーザ端末２００がリッチコミュニケーションメッセージの受信が可能か否かを判定し、受信不可である場合にはリッチコミュニケーションメッセージを送信しないので、通信効率を向上することができる。

（実施形態３）
上記実施形態１および実施形態２において、リッチコミュニケーションメッセージの送信処理の基本構成を示した。しかし、特に、Ｂ ｔｏ Ｃ企業から顧客に向けて配信するメッセージを顧客が閲読するか否かは、メッセージツールの種類によるケースもある。そこで、実施形態３においては、主にメッセージ配信要求サーバ３００から顧客にメッセージを配信する際において、企業側の情報を顧客が閲読しやすい方法でメッセージを配信する処理について説明する。実施形態３における全体構成は実施形態１において図１を用いて説明した全体構成と同様である。

図１１は、実施形態３におけるメッセージ管理サーバ５００の機能構成例を示すブロック図である。図１１に示すように、メッセージ管理サーバ５００は、制御部５１０と、通信制御部１２０と、記憶部５３０とを備える。なお、実施形態１または実施形態２と同様の構成および機能については、同一の符号を付して説明を省略する。

記憶部５３０は、ユーザ情報データベース１３１と、属性情報データベース５３２と、レスポンス情報データベース５３３とを記憶する。属性情報データベース５３２には、属性情報とメッセージツール情報とが格納されている。ここで、属性情報とは、ユーザ端末２００のユーザの属性を示す情報であって、ユーザ端末２００の電話番号に、当該ユーザ端末２００のユーザの性別または年齢のうち少なくともいずれかが対応付けられている。また、例えば、ユーザの性別および年齢の他、ユーザの居住エリア、趣味、嗜好、購入履歴などのユーザの好みを示す情報のいずれかがユーザ端末２００の電話番号に対応付けられてもよい。図１２（ａ）は、実施形態３における属性情報の一例を示す図である。図１２（ａ）では、ユーザ端末２００の携帯電話番号を示す電話番号「０９０−００００−００００」に、ユーザの年齢を示す年齢「４０歳」と、ユーザの性別を示す性別「男」と、ユーザが好む食事を示す食事嗜好「和食」とが対応付けられている。また、メッセージツール情報とは、属性情報に応じて定められたメッセージツールの種類を示す情報であって、ユーザの属性にメッセージツールが対応付けられている。なお、ユーザの属性に対応付けられるメッセージツールは、ユーザの属性によって使用される頻度あるいは可能性の高いメッセージツールとなる。図１２（ｂ）および図１２（ｃ）は、実施形態２におけるメッセージツール情報の一例を示す図である。図１２（ｂ）は、ユーザの性別ごとにメッセージツールが対応付けられており、性別「男性」には、電子メールを示すメッセージツール「Ｅｍａｉｌ」が、また、性別「女性」には、リッチコミュニケーションメッセージを示すメッセージツール「ＲＣＳ」がそれぞれ対応付けられている。また、図１２（ｃ）では、食事嗜好ごとにメッセージツールが対応付けられており、食事嗜好「和食」には、電子メールを示すメッセージツール「Ｅｍａｉｌ」が、食事嗜好「洋食」には、リッチコミュニケーションメッセージを示すメッセージツール「ＲＣＳ」が、食事嗜好「中華」には、ショートメッセージを示すメッセージツール「ＳＭＳ」が、食事嗜好「エスニック」には、チャットサービス「チャット」がそれぞれ対応付けられている。

また、レスポンス情報データベース５３３には、レスポンス情報が格納されている。ここで、レスポンス情報とは、複数のメッセージツールごとにユーザ端末２００からレスポンスがあった回数を示す情報であって、ユーザ端末２００の携帯電話番号に、メッセージツールごとのレスポンス回数が少なくとも対応付けられている。また、レスポンスとは、メッセージの開封操作や、メッセージ内容の表示操作などを示す。なお、メッセージツールとは、メッセージを送受信するためのアプリケーションなどのツールであり、ショートメッセージ、リッチコミュニケーションメッセージ、電子メールなどである。図１２（ｄ）は、実施形態３におけるレスポンス情報の一例を示す図である。図１２（ｄ）では、ユーザ端末２００の携帯電話番号を示す電話番号「０９０−００００−００００」に、ユーザ端末２００の電子メールに対するレスポンス回数としてＥｍａｉｌ「２０／３０」、リッチコミュニケーションメッセージに対するレスポンス回数としてＲＣＳ「３０／３０」、ショートメッセージに対するレスポンス回数としてＳＭＳ「０／２０」、チャットメッセージに対するレスポンス回数としてチャット「１０／２０」レスポンス回数がカウントされた期間として受信期間「２０１８０１０１−２０１８１２３１」が対応付けられている。ここで、受信期間２０１８年１月１日から２０１８年１２月３１日におけるＥｍａｉｌのレスポンス回数は、ユーザ端末２００が送受信したＥｍａｉｌ総数３０通のうち、２０回であることを示す。また、当該受信期間におけるリッチコミュニケーションサービスのレスポンス回数は、ユーザ端末２００が送受信したリッチコミュニケーションメッセージ総数３０通のうち、３０回であることを示す。また、当該受信期間におけるショートメッセージのレスポンス回数は、ユーザ端末２００が送受信したショートメッセージ総数３０通のうち、０回であることを示す。また、当該受信機関におけるチャットシステムのレスポンス回数は、ユーザ端末２００が送受信したチャットメッセージ総数２０通のうち、１０回であることを示す。図１２（ｄ）では、レスポンス回数が最も多いのは、リッチコミュニケーションメッセージであり、受信回数に対するレスポンス回数の割合で比較しても、リッチコミュニケーションメッセージによるレスポンスの割合が最も高いことを示す。なお、本実施形態においては、個々のユーザ端末２００の携帯電話番号ごとにレスポンス情報をカウントする例を示したが、これに限定されず、例えば、所定の年齢層や性別ごとにメッセージツールごとのレスポンス回数をカウントし、カウントしたレスポンス回数の統計に応じてメッセージツールが定められることとしてもよい。また、統計は個人ごとの統計としてもよいし、所定のグループ（例えば、メッセージアプリケーションのトークルームにおいて作成されたグループであってもよい。）ごとの統計としてもよい。さらに、グループの場合であれば、機種によってアプリケーションの表示態様が異なることもあり、クリック操作の容易性が異なる事情もあるため、機種ごとの統計とすることも可能である。

制御部５１０は、受付部５１１と、取得部５１２と、変換部５１３と、判定部４１４と、決定部５１４と、送受信部１１５とを備える。

受付部５１１は、メッセージ配信要求サーバ３００から、メッセージのコンテンツ種別を含むメッセージの配信依頼を受け付ける。ここで、メッセージのコンテンツ種別とは、メッセージの配信内容や目的により分類される種別のことであり、例えば、企業広告、アプリケーションや決済の認証、災害通知などがある。

取得部５１２は、受付部１１１によりメッセージの配信依頼が受け付けられた場合に、属性情報データベース５３２から属性情報を取得する。具体的には、取得部５１２は、メッセージの配信依頼に含まれる宛先となる携帯電話番号に対応する属性として、年齢、性別、ユーザの趣味、嗜好、購入履歴の少なくともいずれか１つ以上を取得する。例えば、メッセージの配信依頼にメッセージツールを決定するための属性情報として性別の指定が含まれる場合には、取得部５１２は、性別に対応するメッセージツールを取得する。または、取得部５１２は、受付部１１１によりメッセージの配信依頼が受け付けられた場合に、レスポンス情報データベース５３３からレスポンス情報を取得する。具体的には、取得部５１２は、メッセージの配信依頼に含まれる宛先となる携帯電話番号に対応する複数のメッセージツールそれぞれのレスポンス回数を取得する。

決定部５１４は、取得部５１２により取得された属性のうち、ユーザの年齢、性別、ユーザの居住エリア、趣味、嗜好、購入履歴のうち少なくともいずれか一つに応じて、メッセージの送信に用いられるメッセージツールを決定し、決定したメッセージツールを用いて送受信部１１６を介してメッセージを配信する。または、決定部５１４は、取得部５１２により取得されたレスポンス回数のうち最もレスポンス回数が多かったメッセージツールを使用するメッセージツールとして決定し、決定したメッセージツールを用いて送受信部１１６を介してメッセージを配信することとしてもよい。なお、決定部５１４は、リッチコミュニケーションメッセージを使用するメッセージツールとして決定した場合であっても、判定部４１２により配信先となるユーザ端末２００においてリッチコミュニケーションメッセージがインストールされていないなどと判定された場合には、他のメッセージツールを使用することとしてもよい。さらに、決定部５１４は、受付部５１１により受け付けられたメッセージの配信依頼にメッセージのコンテンツ種別が含まれる場合、コンテンツ種別に応じてメッセージツールを決定することとしてもよい。例えば、あらかじめ、企業広告の場合にはリッチコミュニケーションメッセージ、電子メール、ショートメッセージの順番が、認証の場合にはショートメッセージ限定、災害通知の場合にはショートメッセージ、という順番の条件に従ってメッセージツールを決定する。このように、企業広告の種別を示すメッセージであればより商品またはサービスの広告内容の詳細を示すメッセージがユーザ端末２００に配信されることが要望され、認証の種別を示すメッセージであれば、ワンタイムパスワードなど数字またはローマ字などが羅列された短い文字情報であることが多く、また、災害通知の種別を示すメッセージであればより確実にユーザに災害情報を通知することが求められる。このように、メッセージの種別により配信に用いられるメッセージツールを異ならせることでユーザまたはメッセージの配信要求元にとって実情に即した効率的かつ効果的なメッセージ配信を行うことができる。

変換部５１３は、受付部１１１により受け付けられたメッセージの配信依頼に含まれるメッセージを、配信部５１５により決定されたメッセージツールのプロトコルを用いて変換する。なお、受付部１１１が、メッセージ配信要求サーバ３００からのメッセージの配信依頼に１種類のメッセージツールにより生成されたメッセージが受け付けられた場合に、変換部５１３は、上記変換処理を行う。一方、受付部１１１が、メッセージ配信要求サーバ３００からのメッセージの配信依頼に複数のメッセージツールにより生成された複数のメッセージが含まれる場合、変換部５１３は、上記変換処理を行わず、配信部５１５は、メッセージの配信依頼に含まれる各種メッセージツールにより生成されたメッセージを用いることとなる。

次に、メッセージ配信要求サーバ３００と、メッセージ管理サーバ５００と、ユーザ端末２００とによるメッセージの配信処理について説明する。図１３は、メッセージ配信要求サーバ３００と、メッセージ管理サーバ５００と、ユーザ端末２００とによるメッセージの配信処理の流れを示すシーケンス図である。

メッセージ配信要求サーバ３００は、メッセージの配信依頼をメッセージ管理サーバ５００に送信する（ステップＳ３１）。メッセージ管理サーバ５００は、属性情報データベース５３２から属性情報を取得する（ステップＳ３２）。メッセージ管理サーバ５００は、ステップＳ３２において取得した属性情報に応じてメッセージツールを決定する（ステップＳ３３）。具体的には、メッセージ管理サーバ５００は、属性情報データベース５３２に格納されているメッセージツール情報を参照し、ステップＳ３２において取得した属性情報に対応付けられたメッセージツールを、メッセージの配信に使用するメッセージツールと決定する。メッセージ管理サーバ５００は、ユーザ端末２００にステップＳ３３において決定したメッセージツールを用いてユーザ端末２００にメッセージを送信する（ステップＳ３４）。

次に、メッセージ配信要求サーバ３００と、メッセージ管理サーバ５００と、ユーザ端末２００とによるメッセージの配信処理の他の例について説明する。図１４は、メッセージ配信要求サーバ３００と、メッセージ管理サーバ５００と、ユーザ端末２００とによるメッセージの配信処理の流れを示すシーケンス図である。

メッセージ配信要求サーバ３００は、メッセージの配信依頼をメッセージ管理サーバ５００に送信する（ステップＳ４１）。メッセージ管理サーバ５００は、レスポンス情報データベース５３３からレスポンス情報を取得する（ステップＳ４２）。メッセージ管理サーバ５００は、ステップＳ４２において取得したレスポンス情報に応じてメッセージツールを決定する（ステップＳ４３）。具体的には、メッセージ管理サーバ５００は、レスポンス情報データベース５３３に格納されているメッセージツール情報を参照し、送信先となるユーザ端末２００の携帯電話番号に対応付けられたレスポンス回数が最も多いメッセージツールを、メッセージの配信に使用するメッセージツールと決定する。メッセージ管理サーバ５００は、ユーザ端末２００にステップＳ４３において決定したメッセージツールを用いてユーザ端末２００にメッセージを送信する（ステップＳ４４）。

このように、実施形態３におけるメッセージ管理サーバ５００によれば、ユーザの性別や年齢などの属性によって、また、ユーザ端末２００によるメッセージへのレスポンス回数などによって、メッセージツールを決定する構成としたので、企業からのメッセージをユーザが閲読する可能性を高めることができる。

（実施形態４）
上記実施形態において、リッチコミュニケーションメッセージの送信処理の基本構成を示した。即ち、リッチコミュニケーションメッセージを、ＥｍａｉｌやＳＭＳでの送信に切り換えたり、Ｅｍａｉｌを、リッチコミュニケーションメッセージでの送信に切り換えたりする態様を示したが、メッセージ種別の切替は、これらに限定するものではない。本実施形態４では、更に、メッセージの送信ツールとして、チャットシステムを利用する例を説明する。

チャットとは、一般的には、コンピュータネットワーク上のデータ通信回線を介してリアルタイムコミュニケーションを行うためのツールであるが、メッセージのやり取りはリアルタイムでなくてもよく、後からメッセージの確認を行える態様であってもよい。通常は、チャットにおいては、ユーザ自身と、1人以上の他のユーザとの間でのメッセージのやり取りを行うものであり、チャットのユーザインターフェースとしては、画面の左右の一方に自身の送信したメッセージを寄せて表示し、他のユーザが送信したメッセージを他方に寄せて表示する。

実施形態４における全体構成は実施形態１において図１を用いて説明した全体構成と同様である。図１５は、実施形態４におけるメッセージ管理サーバ６００の機能構成例を示すブロック図である。図１５に示すように、メッセージ管理サーバ６００は、制御部６１０と記憶部６３０と通信制御部１２０とを備える。制御部６１０は、実施形態３に示す制御部５１０と異なり変換部６１３を備える。また、記憶部６３０は、ユーザ情報ＤＢ５３１に異なりユーザ情報ＤＢ６３１を備える。

以下、本実施形態４に係るメッセージ管理サーバ６００の機能として、上記実施形態１〜３において記載していない内容について説明する。
本実施形態４において、メッセージ管理サーバ６００の記憶部６３０のユーザ情報ＤＢ６３１は、基本的には、図３に示すデータ構成と同様であるが、図３に示す情報に加えて、さらに、ユーザ毎に、そのユーザが利用しているチャットシステム（サービス）を示す情報と、そのチャットシステムを利用する上でのユーザの識別情報（ユーザＩＤ）とが対応付けられている。チャットシステムを示す情報とは、チャットシステムの商品名、サービス名であってよく、そのサービスにおいて利用しているチャットシステムのプロトコルを特定できるものであってもよい。チャットシステムを利用する上でのユーザの識別情報は、チャットシステム上で、各ユーザを一意に特定できる情報であればよく、ユーザ自身が自身に付した名前でもよいし、チャットシステムのシステム側で付与する情報であってもよい。チャットシステムにおいては、メッセージの送受信を行うユーザ間でのみやり取りしているメッセージの内容を確認することができ、メッセージのやり取りを行うＵＩをチャットルームと呼称することもある。他のユーザはチャットに関連するユーザからの招待を受けない限りはチャットルームに参加することができない。メッセージ配信要求サーバ３００が例えば企業のサーバ３００であれば、

変換部６１３は、変換部１１３や変換部５１３が備える機能に加えて、チャットシステムに送信されたメッセージを、Ｅｍａｉｌ、リッチコミュニケーションメッセージ、ＳＭＳのいずれかの形式に変換する機能を有し、送受信部１１５に伝達する。また、変換部１１３は、Ｅｍａｉｌ、リッチコミュニケーションメッセージ、ＳＭＳのいずれかの形式で受信したメッセージを、チャットシステムの形式に変換して送信する機能も有する。

即ち、メッセージ管理サーバ６００は、チャットルームに送信されたメッセージを受信する。変換部６１３は、チャットシステム（チャットルーム）に送信された最新のメッセージの内容を特定する。そして、特定したメッセージの内容を含むＥｍａｉｌ、リッチコミュニケーションメッセージ、ＳＭＳのいずれかの形式に変換するとともに、その宛先を、チャットルームに参加している他のユーザとしたメッセージに変換する。

また、メッセージ管理サーバ６００の変換部６１３は、Ｅｍａｉｌやリッチコミュニケーションメッセージ、ＳＭＳで送信されたメッセージを、それらのメッセージの宛先のユーザ並びに送信者を含むチャットルームに、テキストメッセージや画像データ、動画データなどで、送信する。

以下、メッセージ配信要求サーバ３００と、メッセージ管理サーバ６００と、ユーザ端末２００とによるメッセージの配信処理について説明する。図１６は、メッセージ配信要求サーバ３００と、メッセージ管理サーバ６００と、ユーザ端末２００とによるメッセージの配信処理の流れを示すシーケンス図であって、メッセージ管理サーバ６００からのメッセージの送信がチャットシステムにより行われた場合のシーケンス図である。

メッセージ配信要求サーバ３００は、チャットシステムを用いて、メッセージをメッセージ管理サーバ６００に送信する（ステップＳ５１）。メッセージ管理サーバ６００は、ユーザ端末２００にステップＳ５１において受信したメッセージを、同じチャットシステムを利用して送信先となるユーザ端末２００に送信する（ステップＳ５２）。ここで、ユーザ端末２００がステップＳ５２において送信されたチャットシステムでメッセージを受信できなかった場合、ユーザ端末２００は、メッセージ管理サーバ６００に送信エラーＡＣＫを送信する（ステップＳ５３）。メッセージ管理サーバ６００は、送信エラーＡＣＫ応答を受信する（ステップＳ５４）。メッセージ管理サーバ６００は、ステップＳ５１においてメッセージ配信要求サーバ３００から受信したチャットのメッセージ内容をＥｍａｉｌ形式のメッセージに変換する（ステップＳ５５）。メッセージ管理サーバ６００は、ステップＳ５５において変換したＥｍａｉｌをユーザ端末２００に送信する（ステップＳ５６）。なお、ステップＳ５５においては、Ｅｍａｉｌに変換する例を示しているが、これは、チャットシステム以外の手法を用いた通信であればＥｍａｉｌに限定するものではなく、リッチコミュニケーションメッセージやＳＭＳなどであってもよい。

次に、図１７は、メッセージ配信要求サーバ３００と、メッセージ管理サーバ６００と、ユーザ端末２００とによるメッセージの配信処理の流れを示すシーケンス図であって、メッセージ管理サーバ６００からのメッセージの送信がＥｍａｉｌ（またはリッチコミュニケーションメッセージまたはＳＭＳ）により行われた場合のシーケンス図である。

メッセージ配信要求サーバ３００は、チャットシステム以外の形式、例えば、リッチコミュニケーションメッセージを管理サーバ６００に送信する（ステップＳ６１）。メッセージ管理サーバ６００は、ユーザ端末２００にステップＳ６１において受信したリッチコミュニケーションメッセージを、宛先であるユーザ端末２００に送信する（ステップＳ６２）。ここで、ユーザ端末２００がステップＳ６２において送信されたリッチコミュニケーションメッセージを受信できなかった場合、ユーザ端末２００は、メッセージ管理サーバ６００に送信エラーＡＣＫを送信する（ステップＳ６３）。メッセージ管理サーバ６００は、送信エラーＡＣＫ応答を受信する（ステップＳ６４）。メッセージ管理サーバ６００は、ステップＳ６１においてメッセージ配信要求サーバ３００から受信したリッチコミュニケーションメッセージのメッセージ内容をチャットシステムのメッセージに変換する（ステップＳ６５）。メッセージ管理サーバ６００は、ステップＳ６５において変換したメッセージをチャットシステムを用いてユーザ端末２００に送信する（ステップＳ６６）。なお、ステップＳ６５においては、チャットシステムでのメッセージに変換する例を示しているが、これは、ＥｍａｉｌやＳＭＳへの変換などであってもよい。

図１６、図１７に示すように、メッセージ管理サーバ６００は、チャットシステムでやり取りされているメッセージの内容を、チャットシステム以外の通信ツール（例えば、リッチコミュニケーション、Ｅｍａｉｌ、ＳＭＳなど）を用いての通信に切換えることができ、その逆も可能である。したがって、ユーザ側がチャットシステムによるメッセージのやり取りを拒否している場合でも、メッセージ配信要求サーバ３００からのメッセージをユーザ端末２００に送信することができる。

図１８は、チャットシステムを用いて、メッセージ配信要求サーバ３００が送信したメッセージをユーザ端末２００で表示した例を示している。ここでは、図５に示したリッチコミュニケーションメッセージで送信したメッセージの内容を、チャットシステムで送信した場合の例を示しており、その内容は対応している。したがって、図５と図１８とは、互いに変換部６１３による変換前と変換後の関係を示しているともいえる。

図１８に示すように、ユーザ端末２００の画面２１０には、航空会社とユーザとの間のチャットルームの一例を示しており、チャットルーム内では発言者（図１８に示す例では航空会社）のメッセージ内容が、メッセージバブル２１１内に示される。図１８に示す例では、航空会社からのメッセージが、メッセージバブル２１１内に、予約の事前案内であることが理解でき、予約番号が「４１５５−４４７７」であること、搭乗日が「５月５日」であること、搭乗便が「ＪＡ０７８便」であること、出発時刻が「１２：００」であること、搭乗ゲートが「２５」番であること、座席番号が「Ａ８８」であることが理解できる。メッセージ配信要求サーバ３００からチャットメッセージを利用して、図１８に示す内容が送信され、ユーザ端末２００で拒否されなかった場合には、図１８に示す内容が表示される。一方で、メッセージ配信要求サーバ３００が送信したチャットメッセージがユーザ端末２００により受信拒否された場合には、変換部６１３により、一例としてリッチコミュニケーションメッセージに変換され、例えば、図５に示す態様で表示されることとなる。これは逆も同様であり、図５に示すリッチコミュニケーションメッセージが、メッセージ配信要求サーバ３００により送信されユーザ端末２００により受信拒否された場合に、変換部６１３により、チャットメッセージに変換され、図１８に示す態様で、ユーザ端末２００に表示される。

なお、本実施形態４においても、上記実施形態２に示したように、メッセージの送信前に、ユーザがチャットメッセージを受信可能かどうかを確認して、不可能と判定した場合に、チャットメッセージの送信ではなく、最初から、例えば、リッチコミュニケーションメッセージに変換しての送信を行ってもよいし、上記実施形態３に示したように、ユーザの属性に応じたメッセージの配信を行ってもよい。

上記実施形態１〜４において、メッセージ配信要求サーバ３００に最初に指定されている通信プロトコルでのメッセージを受信側が受信できなかった場合に、メッセージ管理サーバ１００（４００、５００、６００）の変換部１１３が、メッセージ配信要求サーバ３００からのメッセージを、他の通信プロトコルの態様に変換することで、他の通信プロトコルでのメッセージの送信を実現していたが、これはその限りではない。予め、メッセージ管理サーバ１００（４００、５００、６００）の記憶部１３０に代替となる他の通信プロトコルでのメッセージのデータを記憶しておき、受信側が受信できなかった場合に、そのデータを読み出して送信するように構成されてもよい。記憶部１３０に予め代替となる他の通信プロトコルでのメッセージのデータは、最初にメッセージ配信要求サーバ３００から受信したものを記憶しておくこととしてよい。即ち、最初のメッセージ配信要求を行う際に、メッセージ配信要求サーバ３００は、送信したい内容は同じ趣旨のメッセージであって、各通信プロトコルに対応したメッセージをメッセージ管理サーバ１００（４００、５００、６００）に送信し、記憶部１３０に記憶しておいてもよい。このような構成により、メッセージ管理サーバ１００（４００、５００、６００）は、変換部１１３がなくても、複数の通信プロトコルに対応して、メッセージの送信を行うことができる。

上記実施形態１〜４において、メッセージの送信後に送信エラーＡＣＫを受信した場合、あるいは、指定されている態様でのメッセージが受信側で予め拒否されている、あるいは、受信できないことがわかっている場合に、メッセージを他の通信プロトコル（ツール）を利用して送信するときに、複数の利用可能な通信プロトコルが存在する場合がある。そのような場合に、メッセージ管理サーバ１００（４００、５００、６００）は、それらの複数の他の利用可能な通信プロトコルの中からランダムに選択した通信プロトコルでメッセージを送信（再送）することとしてもよいし、所定の基準に従って選択した通信プロトコルでメッセージを送信することとしてもよい。ここでいう所定の基準は、予め定められた優先度のことであってもよく、例えば、予め、ＲＳＣ、チャット、Ｅｍａｉｌ、ＳＭＳという順番が設定されていた場合であって、最初のメッセージがチャットで送信された場合に受信側がチャットを拒否していた場合には、メッセージ管理サーバは、最初にＲＳＣでの送信にチャレンジし、次に、Ｅｍａｉｌ、最後にＳＭＳでの送信を行う。また、この所定の基準は、受信側の端末によって異なってよく、ユーザ毎に優先度が設定されていてもよい。また、さらには、順番に異なる通信プロトコルでのメッセージを送信するのではなく、メッセージの送信後に送信エラーＡＣＫを受信した場合、あるいは、指定されている態様でのメッセージが受信側で予め拒否されている、あるいは、受信できないことがわかっている場合に、複数の異なる通信プロトコルでまとめて一度にメッセージを送信するように構成されてもよい。

また、上記実施形態１、４において、メッセージ管理サーバ１００（６００）は、送信エラーＡＣＫを受信した場合、自動的にメッセージを他の通信プロトコルの態様に変換して、変換後のメッセージを対応する他の通信プロトコルで送信することとしている。このときに、メッセージ管理サーバ１００（６００）は、メッセージを再送する前に、受信側、即ち、ユーザ端末２００のユーザに許可を求めてからメッセージを再送するように構成されてもよい。即ち、メッセージ管理サーバ１００（６００）は、送信エラーＡＣＫを受信した場合に、メッセージ配信要求サーバ３００がメッセージの配信を行いたいとの要望があることをユーザ端末２００に通知する。ユーザ端末２００のユーザは、その通知を見て、メッセージの受信を行ってもよいと判断した場合に、受信許可をメッセージ管理サーバ１００（６００）に通知する。メッセージを受信したくないと判断した場合には、受信不許可をメッセージ管理サーバ１００（６００）に通知する。そして、メッセージ管理サーバ１００（６００）は、受信許可をユーザ端末２００から受信した場合に限り、メッセージを他の通信プロトコルでメッセージを送信する。このとき、ユーザ端末２００が許可するのであれば、メッセージ配信要求サーバ３００が最初に指定している通信プロトコルでのメッセージの再送を行ってもよい。

図１９は、実施形態１〜４におけるメッセージ管理サーバ１００、４００、５００、６００を実現可能なコンピュータ２０の一例を示すハードウェア構成図である。図１９に示すように、コンピュータ２０は、ＣＰＵ（Central Processing Unit）２１、ＲＡＭ（Random Access Memory）２２、ＲＯＭ（Read Only Memory）２３、ＨＤＤ（Hard Disk Drive）２４、通信インターフェース（Ｉ／Ｆ）２５、入出力インターフェース（Ｉ／Ｆ）２６、およびメディアインターフェース（Ｉ／Ｆ）２７を備える。

ＣＰＵ２１は、ＲＯＭ２３またはＨＤＤ２４に格納されたプログラムにより動作し、各部の制御を行う。ＲＯＭ２３は、コンピュータ２０の起動時にＣＰＵ２１によって実行されるブートプログラムや、コンピュータ２０のハードウェアに依存するプログラム等を格納する。

ＨＤＤ２４は、ＣＰＵ２１によって実行されるプログラムおよび当該プログラムによって使用されるデータ等を格納する。通信インターフェース２５は、通信回線を介して外部機器から受信したデータをＣＰＵ２１に送り、ＣＰＵ２１が生成したデータを、通信回線を介して外部機器に送信する。

ＣＰＵ２１は、入出力インターフェース２６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ２１は、入出力インターフェース２６を介して、入力装置からデータを取得する。また、ＣＰＵ２１は、生成したデータを、入出力インターフェース２６を介して出力装置へ出力する。

メディアインターフェース２７は、記憶媒体２８に格納されたプログラムまたはデータを読み取り、ＲＡＭ２２を介してＣＰＵ２１に提供する。ＣＰＵ２１は、当該プログラムを、メディアインターフェース２７を介して記憶媒体（不図示）からＲＡＭ２２上にロードし、ロードしたプログラムを実行する。記憶媒体は、例えばＤＶＤ（Digital Versatile Disc）等の光学記憶媒体、磁気記憶媒体、または半導体メモリ等である。

コンピュータ２０が本実施形態におけるメッセージ管理サーバ１００として機能する場合、コンピュータ２０のＣＰＵ２１は、ＲＡＭ２２上にロードされたプログラムを実行することにより、受付部１１１、決定部１１２、決定部４１１、決定部５１４、変換部１１３、判定部４１２、取得部１１４、取得部４１３、取得部５１２、判定部４１２、送受信部１１５の各機能を実現する。また、ＨＤＤ２４には、ユーザ情報データベース１３１、機種情報データベース４３２、インストール情報データベース４３３、属性情報データベース５３２、レスポンス情報データベース５３３内のデータが格納される。

メッセージ管理システムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、メモリカード、ＤＶＤ（Digital Versatile Disk）、フレキシブルディスク（ＦＤ）等のコンピュータで読み取り可能な記憶媒体に記憶されて提供される。コンピュータ２０のＣＰＵ２１は、これらのプログラムを、メディアインターフェース２７を介して上記の記憶媒体から読み取って実行するが、他の例として、外部装置から、通信回線を介してこれらのプログラムを取得してもよい。

なお、メッセージ管理システムは、例えば、ActionScript、JavaScript（登録商標）、Python、Rubyなどのスクリプト言語、C言語、C＋＋、C＃、Objective-C、Swift、Java（登録商標）などのコンパイラ言語などを用いて実装できる。
なお、本発明に係るメッセージ管理サーバは、携帯電話端末の電話番号を使用したメッセージサービスを提供するメッセージ管理サーバであって、外部サーバから、複数の携帯電話端末へのメッセージの配信依頼を受け付ける受付部と、所定の条件に応じて、メッセージの送信に用いるメッセージツールとして、第一のプロトコルが用いられる第一のメッセージ、前記第一のプロトコルとは異なり、かつ、前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージ、または電子メールまたはチャットシステムの少なくともいずれか一つのいずれかを決定する決定部と、前記決定部により決定された配信方法に従って前記携帯電話端末にメッセージを配信する配信部と、備えることを特徴とするものであってもよい。
また、上記メッセージ管理サーバにおいて、前記携帯電話端末の電話番号に、前記携帯電話端末のユーザの性別、年齢、居住エリア、趣味、嗜好、の少なくともいずれか一つを示す属性情報を対応付けて記憶する記憶部と、前記受付部によりメッセージの配信依頼が受け付けられた場合に、前記記憶部から、前記携帯電話の電話番号に対応付けられた前記ユーザの性別、年齢、居住エリア、趣味、嗜好の少なくともいずれか一つを取得する取得部と、をさらに備え、前記決定部は、前記取得部により取得された前記ユーザの性別、年齢、居住エリア、趣味、嗜好のうち少なくともいずれか一つに応じて、メッセージの送信に用いられるメッセージツールを決定すること、を特徴としてもよい。
また、上記メッセージ管理サーバにおいて、前記受付部は、メッセージのコンテンツ種別を含むメッセージの配信依頼を受け付け、前記決定部は、前記コンテンツ種別に応じてメッセージツールを決定すること、を特徴としてもよい。
また、上記メッセージ管理サーバにおいて、前記携帯電話端末の電話番号に、複数のメッセージツールに対する前記携帯電話端末か前記受付部によりメッセージの配信依頼が受け付けられた場合に、前記記憶部から、前記携帯電話の電話番号に対応付けられた前記携帯電話端末からのレスポンス回数を取得する取得部と、をさらに備え、前記決定部は、前記取得部により取得された前記携帯電話端末からのレスポンス回数に応じて、メッセージの送信に用いられるメッセージツールを決定すること、を特徴としてもよい。
また、上記メッセージ管理サーバにおいて、第一のメッセージに対応する前記第二のメッセージを記憶する記憶部と、前記第一のメッセージを含むメッセージの配信依頼を受け付けた場合であって、前記第一のメッセージを前記携帯電話端末に送信できない場合に、前記記憶部から前記第一のメッセージに対応する前記第二のメッセージを取得するメッセージ取得部と、を備え、前記配信部は、前記メッセージ取得部により取得された前記第二のメッセージを前記携帯電話端末に送信すること、を特徴としてもよい。

１ メッセージ管理システム
１００ メッセージ管理サーバ
１１０ 制御部
１１１ 受付部
１１２ 決定部
１１３ 変換部
１１４ 取得部
１１５ 送受信部
１２０ 通信制御部
１３０ 記憶部
１３１ ユーザ情報データベース
１３２ メッセージ情報データベース
２００ ユーザ端末
２１０ 画面
３００ メッセージ配信要求サーバ

Claims (9)

1. 携帯電話端末の電話番号を使用したメッセージサービスを提供するメッセージ管理サーバであって、
   第一のプロトコルが用いられる第一のメッセージの配信依頼を受け付ける受付部と、
   前記携帯電話端末の電話番号と、前記携帯電話端末のユーザの電子メールアドレスと前記電話番号に紐づくチャットＩＤの少なくともいずれか一つとを対応付けた宛先情報と、前記携帯電話端末の電話番号と、第一のプロトコルが用いられる第一のメッセージを受信するためのアプリケーションのインストールの有無を示す情報とを対応付けたインストール情報とを記憶する記憶部と、
   前記記憶部を参照し、送信先となる携帯電話端末の電話番号に対応付けられているアプリケーションのインストールの有無を示す情報がインストールされていることを示すか否かを判定する第１判定部と、
   前記第１判定部により、前記携帯電話端末に前記アプリケーションがインストールされていると判定された場合に、前記携帯電話端末に前記第一のプロトコルが対応するメッセージツールで前記第一のメッセージを配信することを決定し、前記第１判定部により、前記携帯電話端末に前記アプリケーションがインストールされていないと判定された場合に、所定の条件に基づいて、前記携帯電話端末に前記第一のプロトコルとは異なり、かつ、前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージまたは電子メールまたはチャットシステムの少なくともいずれか一つのいずれのメッセージツールを用いて前記第一のメッセージに含まれるデータを前記携帯電話端末に配信することを決定する決定部と、
   前記決定部により決定されたメッセージツールを用いて前記携帯電話端末にメッセージを配信する配信部と、
   を備えることを特徴とするメッセージ管理サーバ。
2. 前記配信部による配信されたメッセージに対する送信エラーを受信するエラー受信部と、
   前記エラー受信部により前記送信エラーを受信した場合に、前記決定部は、前記携帯電話端末に配信するメッセージツールとして決定したメッセージツールとは異なるメッセージツールで、前記第一のメッセージに含まれるデータを前記携帯電話端末に配信することを決定する
   ことを特徴とする請求項１に記載のメッセージ管理サーバ。
3. 前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージ、電子メールまたはチャットシステムのうち、第二のプロトコルが複数利用可能である場合には、前記所定の条件に基づいて、予め定められた当該メッセージツールと当該メッセージツールを利用する優先順位に基づいて順次再送を行う又は同時に再送を行うことを特徴とする請求項１又は請求項２に記載のメッセージ管理サーバ。
4. 前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージ、電子メールまたはチャットシステムのうち、第二のプロトコルが複数利用可能である場合には、前記所定の条件に基づいて、予め定められた当該メッセージツールと当該メッセージツールを利用する優先順位に基づいて再送を行うものであって、受信したことを示す情報を受信したら再送を完了し、受信できなかったことを示す情報を受信した場合には、次の優先順位の異なる該メッセージツールに再送を行う請求項３に記載のメッセージ管理サーバ。
5. 前記記憶部は、前記携帯電話端末の電話番号と、前記携帯電話端末の機種の識別情報と、前記第一のメッセージを送受信できない携帯電話端末の機種の識別情報とを対応付けて記憶し、
   前記記憶部を参照し、送信先となる携帯電話端末の電話番号に対応付けられている機種の識別情報が、前記第一のメッセージを送受信できない携帯電話端末の機種の識別情報であるか否かを判定する第２判定部と、
   前記配信部は、前記第２判定部により、前記第一のメッセージを送受信できない携帯電話端末の機種の識別情報であると判定された場合に、前記第一のメッセージを送信しないこと、
   を特徴とする請求項１〜４のいずれか一項に記載のメッセージ管理サーバ。
6. 前記記憶部は、前記携帯電話端末の電話番号と、前記携帯電話端末の機種の識別情報と、前記第一のメッセージを送受信できない携帯電話端末の機種の識別情報とを対応付けて記憶し、
   前記記憶部を参照し、送信先となる携帯電話端末の電話番号に対応付けられている機種の識別情報が、前記第一のメッセージを送受信できない携帯電話端末の機種の識別情報であるか否かを判定する第２判定部と、
   前記配信部は、前記第２判定部により、前記第一のメッセージを送受信できる携帯電話端末の機種の識別情報であると判定された場合に、前記第一のメッセージを送信すること、
   を特徴とする請求項１〜４のいずれか一項に記載のメッセージ管理サーバ。
7. 前記第一のプロトコルは、ＲＣＳ（Rich Communication Service）であり、
   前記第二のプロトコルは、ＳＭＳ（Short Message Service）である
   ことを特徴とする請求項１〜６のいずれか一項に記載のメッセージ管理サーバ。
8. 携帯電話端末の電話番号を使用したメッセージサービスを提供するメッセージ管理サーバによるメッセージ管理方法であって、
   第一のプロトコルが用いられる第一のメッセージの配信を受け付ける受付ステップと、
   前記携帯電話端末の電話番号と、前記携帯電話端末のユーザの電子メールアドレスと前記電話番号に紐づくチャットＩＤの少なくともいずれか一つとを対応付けた宛先情報と、前記携帯電話端末の電話番号と、第一のプロトコルが用いられる第一のメッセージを受信するためのアプリケーションのインストールの有無を示す情報とを対応付けたインストール情報とを記憶部に記憶する記憶ステップと、
   前記記憶部を参照し、送信先となる携帯電話端末の電話番号に対応付けられているアプリケーションのインストールの有無を示す情報がインストールされていることを示すか否かを判定する判定ステップと、
   前記判定ステップにより、前記携帯電話端末に前記アプリケーションがインストールされていると判定された場合に、前記携帯電話端末に前記第一のプロトコルが対応するメッセージツールで前記第一のメッセージを配信することを決定し、前記判定ステップにより、前記携帯電話端末に前記アプリケーションがインストールされていないと判定された場合に、所定の条件に基づいて、前記携帯電話端末に前記第一のプロトコルとは異なり、かつ、前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージまたは電子メールまたはチャットシステムの少なくともいずれか一つのいずれのメッセージツールを用いて前記第一のメッセージに含まれるデータを前記携帯電話端末に配信することを決定する決定ステップと、
   前記決定ステップにより決定されたメッセージツールを用いて前記携帯電話端末にメッセージを配信する配信ステップと、
   を含むことを特徴とするメッセージ管理方法。
9. コンピュータに、
   第一のプロトコルが用いられる第一のメッセージの配信を受け付ける受付機能と、
   携帯電話端末の電話番号と、前記携帯電話端末のユーザの電子メールアドレスと前記電話番号に紐づくチャットＩＤの少なくともいずれか一つとを対応付けた宛先情報と、前記携帯電話端末の電話番号と、第一のプロトコルが用いられる第一のメッセージを受信するためのアプリケーションのインストールの有無を示す情報とを対応付けたインストール情報とを記憶部に記憶する記憶機能と、
   前記記憶部を参照し、送信先となる携帯電話端末の電話番号に対応付けられているアプリケーションのインストールの有無を示す情報がインストールされていることを示すか否かを判定する判定機能と、
   前記判定機能により、前記携帯電話端末に前記アプリケーションがインストールされていると判定された場合に、前記携帯電話端末に前記第一のプロトコルが対応するメッセージツールで前記第一のメッセージを配信することを決定し、前記判定機能により、前記携帯電話端末に前記アプリケーションがインストールされていないと判定された場合に、所定の条件に基づいて、前記携帯電話端末に前記第一のプロトコルとは異なり、かつ、前記第一のプロトコルと互換性を有する第二のプロトコルが用いられる第二のメッセージまたは電子メールまたはチャットシステムの少なくともいずれか一つのいずれのメッセージツールを用いて前記第一のメッセージに含まれるデータを前記携帯電話端末に配信することを決定する決定機能と、
   前記決定機能により決定されたメッセージツールを用いて前記携帯電話端末にメッセージを配信する配信機能と、
   を実現させることを特徴とするメッセージ管理プログラム。
   

Images