JP6590356B1 - メッセージ通信装置及びメッセージ通信プログラム - Google Patents

Abstract

【課題】テキストを含み得るメッセージ通信に関する多様な通信形態が存在する環境において、顧客及び顧客のユーザの通信環境に適合し、かつ顧客と顧客のユーザに対して、より利便性の高いメッセージ通信を提供すること。【解決手段】開示の技術によれば、顧客から、少なくともアドレスと、前記アドレスに送信する１以上のメッセージとを受け取る受取部であって、前記アドレスは前記顧客のユーザの電話番号又は電話番号に準ずるアドレスであり、前記メッセージはテキストを含み得るメッセージである、受取部と、複数の通信事業体装置のうちの１つの通信事業体装置を選択する通信事業体装置選択部と、選択された前記通信事業体装置において用いられる１以上の通信プロトコルのうちの１つの通信プロトコルを選択する通信プロトコル選択部と、前記１以上のメッセージから、選択された前記通信プロトコルに適合し前記アドレスに送るメッセージを出力するメッセージ出力部と、出力された前記メッセージが、前記アドレスに宛てて、選択された前記通信プロトコルで選択された前記通信事業体装置によって送信されるように、選択された前記通信事業体装置に前記メッセージの送信を要求する送信要求部であって、送信が成功するか前記通信事業体装置と前記通信プロトコルとの組み合わせが無くなるまで、前記要求を繰り返す送信要求部と、を有するメッセージ通信装置が提供される。【選択図】図１

Description

本発明は、メッセージ通信装置及びメッセージ通信プログラムに関する。

通信端末宛に、メッセージを送信する技術には多様な形態が存在する。メッセージ通信技術には、通常のメールアドレスを宛先に用いるものと、電話番号又は電話番号に準ずるアドレスを宛先に用いるもの等がある。なお、本明細書においてメッセージとは、テキストを含み得るメッセージを指す。

電話番号に準ずるアドレスとは、以下のようなアドレスが挙げられる。例えば、携帯電話番号を管理する通信キャリアから電話番号に対応して付与されたメールアドレスがこの一例である。このメールアドレスは、電話番号に一意に対応して付与されたメールアドレスである。或いは、電話番号に準ずるアドレスとして、携帯電話番号に一意に紐づけられたＳＮＳアカウントに付随するメッセージングシステムで用いられるアドレスが挙げられる。その他、電話番号に準ずるアドレスは、電話番号に準ずるような個人を識別する能力が高い通信アドレスであってもよい。以下、本明細書ではこのようなアドレスを「電話番号又は電話番号に準ずるアドレス」と称す。

これらのメッセージ通信を比較すると、通常のメールアドレスを宛先に用いるメッセージ通信は、通信費用も低額であり、簡便なメッセージ伝達方法である。すなわち、通常のメールアドレスを宛先に用いるメッセージ通信は、宛先にメールアドレスを指定すれば、国内外を問わず送信可能である。また、携帯電話のキャリアの種類などにも依存せずに、メッセージを伝達することができる。

これに対して、電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信は、宛先への到達率、メッセージ開封率、通信相手を特定する能力などが高いという特徴を有する。しかしながら、電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信は、通信方式の違い等により、メッセージが届かない場合もあり得る。このような両者の特質を踏まえて、利用者のニーズ、伝達するべきメッセージ内容等に応じて、通常のメールアドレスを宛先に用いるメッセージ通信と、電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信の使い分けがなされている。

昨今においては、通信キャリアの多様化、通信事業体（通信事業者）の多様化により、電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信は、以下に示すように複数の形態が存在している。また、それぞれの通信形態によって、送信できるコンテンツの種類、フォーマット、通信プロトコルなどが異なっている。
電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信形態の例を以下に示す。

電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信の例として、ＳＭＳ（Short Messaging Service）がある。ＳＭＳは、電話番号を宛先として文字列を転送することはできるが、静止画、動画などを含むマルチメディアコンテンツを送ることはできない。

他の例としてＭＭＳ（Multimedia Messaging Service）がある。ＭＭＳは、画像、音、ビデオ、リッチテキストを含んだマルチメディアコンテンツを送信できる。

他の例としては、ＲＣＳ（Rich Communication Services）がある。ＲＣＳは、電話番号を宛先として、テキスト、動画、位置情報、ファイルなどを含むマルチメディアコンテンツを送ることができる。

その他、電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信の例として、通信端末にインストールされた専用のアプリケーションを用いる通信形態、ＷＥＢブラウザを用いて所定のサイトにログインして専用のユーザインタフェースを用いる通信形態などがある。

通信の利用形態の側面からこれらの通信形態を分類すると、通信端末から通信端末へのメッセージ通信（いわゆるＰ２Ｐ（Person to Person））と、企業から個人の通信端末への一斉配信（いわゆる、企業側のアプリケーションからのメッセージ配信：Ａ２Ｐ（Application to Pearson））とがある。

電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信の場合、メールアドレスを用いる通信形態と異なり、Ｐ２ＰとＡ２Ｐとの利用形態には大きな相違がある。

電話番号又は電話番号に準ずるアドレスを宛先に用いるＰ２Ｐの通信においては、通信端末を利用する個人は、利用するメッセージ通信の種類に応じたユーザインタフェースを用いてメッセージを相手に送ることとなるため、そもそも相手に送ることができない仕様のメッセージを送る事象は発生しないことが通常である。また、相手に送ることができない通信事業体（通信キャリア）などを経由するメッセージを送ろうとしても、相手の宛先を選ぶことがそもそもできないことが通常である。

これに対して、電話番号又は電話番号に準ずるアドレスを宛先に用いるＡ２Ｐにおけるメッセージ通信は、上記のＰ２Ｐにおけるメッセージ通信とは異なる環境に置かれている。例えば、ある企業が、多数の電話番号又は電話番号に対応するアドレスに宛ててメッセージを送信しようとする場合、利用できるメッセージ通信の形態が予め明らかでない場合が多く、送信先に応じて異なる状況に対処することが求められる。企業（顧客）が個人（ユーザ）の通信端末宛にメッセージを配信するＡ２Ｐのメッセージ通信を取り扱う場合、通信形態が多様化する中で、複数のメッセージ通信形態の選択肢のうちからどのメッセージ通信形態を選択するかに関して困難を伴っていた。
電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信に関する従来技術としては、例えば、以下のものがある。

送信先電話番号に基づいて、その受信端末が属する送信先キャリア網ｂを判定するとともに、キャリア情報データベースから当該送信先キャリア網ｂのプロトコルに関する情報を含む他キャリア情報を取得するキャリア情報取得ステップと、上記他キャリア情報に基づき、ＳＭＳメールを、その送信先のキャリア網ｂのプロトコルにあわせてプロトコル変換して送信するプロトコル変換・送信ステップとから構成される技術が存在する（例えば、特許文献１参照）。

また、相手先携帯端末に対してリクエストデータを送信する送信元端末と、送信元端末と公衆回線又は広域ネットワークを介して接続され、リクエストデータを受信する管理装置と、管理装置と接続され、相手先携帯端末に接続しうるショートメッセージサービス（ＳＭＳ）を提供する複数のゲートウェイ装置とを備え、管理装置は、複数のゲートウェイ装置から、一のゲートウェイ装置を選択すると共に、選択されたゲートウェイ装置に対して、送信元端末から受信したリクエストデータに対応する処理を請求するデータ仲介システムであって、ゲートウェイ装置のＡＰＩに従ってデータを送信するプロトコル変換と、レスポンスデータ変換手段とを備えた技術が存在する（例えば、特許文献２参照）。

また、各キャリアに設置されたショートメッセージサービス（ＳＭＳ）サーバｃと、コンシューマ端末に対して各キャリアの携帯電話端末とのショートメッセージの送受を可能とするサービスを提供するプロバイダに設置されたプロバイダサーバと接続されたサーバコンピュータを含むショートメッセージサービス用ゲートウエイシステムを用いる技術が存在する。各キャリアの携帯電話端末から送信される各キャリア独自のキャリアプロトコルによるＳＭＳをプロバイダプロトコルのＳＭＳに変換する第１プロトコル変換処理と、コンシューマ端末から送信されるＳＭＳの送信先となるキャリアを特定し、特定したキャリアにて使用されているキャリアプロトコルにプロバイダプロトコルのＳＭＳを変換する第２プロトコル変換処理を行う技術が存在する（例えば、特許文献３参照）。

しかしながら、上記のような従来の技術は、電話番号又は電話番号に準ずるアドレス宛にメッセージが送れることを前提とした対応策を提供するにとどまっており、昨今の多様な電話番号又は電話番号に準ずるアドレスを宛先に用いるメッセージ通信形態が存在する環境に対して、充分に適応できていない。

特開２００７−２７４５２４号公報 特開２０１２−１７８７９９号公報 特開２０１６−１４９１号公報

本発明はこのような課題に対処するためになされたものであって、テキストを含み得るメッセージ通信に関する多様な通信形態が存在する環境において、顧客及び顧客のユーザの通信環境に適合し、かつ顧客と顧客のユーザに対して、より利便性の高いメッセージ通信を提供することを目的とする。

開示の技術によれば、顧客から、少なくともアドレスと、前記アドレスに送信する１以上のメッセージとを受け取る受取部であって、前記アドレスは前記顧客のユーザの電話番号又は電話番号に準ずるアドレスであり、前記メッセージはテキストを含み得るメッセージである、受取部と、複数の通信事業体装置のうちの１つの通信事業体装置を選択する通信事業体装置選択部と、選択された前記通信事業体装置において用いられる１以上の通信プロトコルのうちの１つの通信プロトコルを選択する通信プロトコル選択部と、前記１以上のメッセージから、選択された前記通信プロトコルに適合し前記アドレスに送るメッセージを出力するメッセージ出力部と、出力された前記メッセージが、前記アドレスに宛てて、選択された前記通信プロトコルで選択された前記通信事業体装置によって送信されるように、選択された前記通信事業体装置に前記メッセージの送信を要求する送信要求部であって、送信が成功するか前記通信事業体装置と前記通信プロトコルとの組み合わせが無くなるまで、前記要求を繰り返す送信要求部と、を有するメッセージ通信装置が提供される。

開示の技術によれば、テキストを含み得るメッセージ通信に関する多様な通信形態が存在する環境において、顧客及び顧客のユーザの通信環境に適合し、かつ顧客と顧客のユーザに対して、より利便性の高いメッセージ通信を提供することができる。

図１は、一実施形態の全体構成を示すブロック図である。 図２は、一実施形態のメッセージ通信装置のハードウエアブロック図である。 図３は、一実施形態の処理の概要を示すフローチャートである。 図４は、一実施形態の処理の詳細を示すフローチャートである。 図５は、一実施形態の処理の詳細を示すフローチャートである。 図６は、一実施形態の処理の詳細を示すフローチャートである。 図７は、一実施形態の処理の詳細を示すフローチャートである。

電話番号又は電話番号に準ずるアドレスを宛先に用いるＡ２Ｐにおけるメッセージ通信において、企業（顧客）から個人（ユーザ）の通信端末の各々へのメッセージ通信で、メッセージ到達率を上げるために、いずれの形態でメッセージ通信を行うのかを個々の通信端末が置かれた環境に応じて適切に選択することが求められている。加えて、一つの通信端末にメッセージを送る形態が複数存在する場合も想定される。このため、メッセージを送る企業（顧客）又は個人（ユーザ）のニーズ、メッセージの内容に応じて異なるメッセージ通信形態を選択できるようにすることが求められる。例えば、ユーザの通信端末にインストールされ、利用されているアプリケーションに依存して、メッセージ通信の形態のうちのいずれを用いるのが適切なのかが異なることもある。
以下、図面を参照しながら、開示の実施形態について説明する。
図１は、一実施形態の構成を示すブロック図である。本実施形態は、メッセージ通信装置１００によって実現される。

＜通信事業体について＞
本明細書においては、「通信事業体」という語を用いている。移動体通信におけるキャリア（移動体通信事業者：ＭＮＯ（Mobile Network Operator））は、通信事業体の一例である。また、このキャリアの通信回線を利用するＭＶＮＯ（Mobile Virtual Network Operator）も通信事業体の一例である。このほか、ＳＮＳ（Social Networking Service）などに付随して提供されるメッセージングサービスを営む企業、通信端末及びＯＳを提供しＯＳの一機能としてメッセージングサービスを営む企業も通信事業体の一例である。

図１に示されるように、本実施形態では、顧客装置１５０と、複数の通信事業体装置１６０と、顧客装置１５０と複数の通信事業体装置１６０との間のメッセージ通信を仲介するメッセージ通信装置１００と、ユーザが管理する通信端末１７０とが関与する。通信端末１７０を管理する主体をユーザと称する。
複数の通信事業体装置１６０の各々は、通信端末１７０との間でメッセージ通信を実現する通信網（不図示）に接続されている。

メッセージ通信装置１００は、顧客装置１５０から、送信すべき１以上のメッセージと、宛先となる電話番号又は電話番号に準ずるアドレスなどを受け取る。顧客装置１５０からのメッセージは、メッセージ通信装置１００及び通信事業体装置１６０を経由してユーザの通信端末１７０に伝達される。

＜メッセージの宛先について＞
メッセージ通信装置１００は、顧客が管理する顧客装置１５０から、ユーザの管理する複数の通信端末１７０の各々に宛てて送信するべきメッセージと送信先の電話番号又は、電話番号に準ずるアドレスとを受け取る。

メッセージ通信装置１００は、選択された通信プロトコルに適合したメッセージと、電話番号又は電話番号に準ずるアドレスとを、通信事業体装置１６０に伝達する。なお、選択された通信プロトコルに適合したメッセージは、受け取られた１以上のメッセージから選択されるか、生成される。

メッセージ通信装置１００は、通信事業体装置１６０に対して、このメッセージを電話番号又は電話番号に準ずるアドレスに対応する通信端末１７０に送信するよう要求する。

なお、上述の１以上のメッセージとは、例えば、ＳＭＳ通信プロトコル用の所定文字数以下のテキストからなる第１のメッセージと、ＲＣＳ通信プロトコル用の画像等を含むリッチテキストからなる第２のメッセージとが挙げられる。

メッセージ通信装置１００は、例えば、この顧客装置１５０から第１のメッセージ及び第２のメッセージと、複数の電話番号又は電話番号に準ずるアドレスとを受け取る。メッセージ通信装置１００は、通信事業体装置１６０に、複数の電話番号のうちの第１の電話番号にＳＭＳ通信プロトコルで第１のメッセージを送信するよう要求する。或いは、メッセージ通信装置１００は、通信事業体装置１６０に、同じ第１の電話番号にＲＣＳ通信プロトコルで第２のメッセージを送信するよう要求する。このように、メッセージ通信装置１００は、通信プロトコルに適合したメッセージを選択する。なお、メッセージ通信装置１００によって受け取られた１以上のメッセージのいずれもが、所定の通信プロトコルに適合しない場合には、メッセージ通信装置１００が、１以上のメッセージから所定の通信プロトコルに適合したメッセージを所定のアルゴリズムを用いて生成してもよい。所定のアルゴリズムは、顧客装置１５０から予め指示されることが望ましい。
また、メッセージ通信装置１００は、通信端末１７０から、返信のメッセージ、到達通知、開封通知などを、通信事業体装置１６０から受信し、顧客装置１５０に転送してもよい。
メッセージ通信装置１００と、通信事業体装置１６０との間の接続は、各々の通信事業体が定めたＡＰＩを用いた直収接続であることが望ましい。

図１に示す構成を用いることによって、顧客の管理下にある顧客装置１５０と複数のユーザの通信端末１７０との間で、メッセージ通信装置１００を介してメッセージ通信を行うことができる。なお、本実施形態では、宛先への到達率が高く、メッセージ開封率が高く、かつ通信相手を特定する能力が高いメッセージを送るように、通信端末１７０の電話番号又は電話番号に準ずるアドレスに宛てて通信事業体装置１６０と通信プロトコルとの組み合わせが用いられることが望ましい。或いは、他の評価基準（通信費用が安いなど）をも勘案して通信事業体装置１６０と通信プロトコルとの組み合わせが選択されてもよい。

＜メッセージについて＞
転送されるメッセージは、キャラクタを含み得るメッセージである。すなわち、メッセージは、キャラクタ以外に、画像、音声、ファイルなどを含むことができるいわゆるリッチテキストであってもよい。メッセージは、テキストが含まれない画像やファイルのみのメッセージであってもよい。

また、メッセージ通信は、顧客装置１５０から通信端末１７０に送られる一方向のメッセージ通信ばかりでなく、顧客装置１５０と通信端末１７０との間の双方向のメッセージ通信であってもよい。後述するように、チャットボット１４２が、通信端末１７０からのメッセージに対して自動的に応答メッセージを返してもよい。
図１を参照して、メッセージ通信装置１００の動作をさらに詳細に説明する。

＜メッセージ送信の手法について＞
受取部１１０は、顧客装置１５０から１以上のメッセージと、この１以上のメッセージを送るべき電話番号又は電話番号に順ずるアドレスを受け取る。

１以上のメッセージとは、既に例示したように、電話番号又は電話番号に準ずるアドレスに送るメッセージの集合を意味する。例えば、メッセージがＳＭＳ通信プロトコルによって通信端末１７０に送信される場合には、メッセージは所定の文字数以下のキャラクタのみで構成されるメッセージが用意される。また、メッセージがＲＣＳ通信プロトコルによって通信端末１７０に送信される場合には、メッセージは、テキストのみに限定されず、テキスト、画像などを含む、いわゆるリッチテキストからなるメッセージが用意される。全ての電話番号又は電話番号に準ずるアドレスに送るメッセージが、１つの所定の通信プロトコルで送られることを顧客が予め知っているのであれば、受取部１１０が顧客装置から受け取るメッセージは、その１つの所定の通信プロトコルに適合した１つのメッセージ（又は１つの所定のフォーマット）であってもよい。しかしながら、ＳＭＳやＲＣＳなど、メッセージを伝達する複数の通信プロトコルが存在する。したがって、現実にはメッセージ通信形態の多様化により、通信端末１７０に送ることができるメッセージの通信プロトコルを事前に１つに特定することができない場合がある。各々の通信プロトコルによって、メッセージのフォーマットが異なる場合が想定される。したがって、受取部１１０が顧客装置１５０から受け取るメッセージは、想定され得る通信プロトコルに適合した複数種類のフォーマットにより作成された１以上のメッセージであることが望ましい。

なお、例えば、受取部１１０が顧客装置１５０から受け取る１以上のメッセージのいずれもが、通信端末１７０に送信される選択された通信プロトコルに適合しない場合には、後述するようにメッセージ出力部１１６によって、当該通信プロトコルに適合するメッセージに変換されるようにしてもよい。例えば、ＲＣＳ用に用意された１種類のリッチテキストのメッセージだけを、受取部１１０が受け取った場合であって、ＳＭＳの通信プロトコルによりメッセージが通信端末１７０に送られる場合が想定される。この場合、当該リッチテキストをＳＭＳ通信プロトコルに適合するように、メッセージ出力部１１６によって当該リッチテキストメッセージが、テキストのみのメッセージに変換されることが望ましい。変換の手法としては、メッセージ出力部１１６によって当該リッチテキストから、テキストのみが抽出されてＳＭＳ用のメッセージが生成されてもよい。或いは、メッセージ出力部１１６によって当該リッチテキストから例えばＨＴＭＬに準拠したファイルが生成されてもよい。この生成されたファイルのＵＲＬがＳＭＳ用のメッセージに挿入されるようにしてキャラクタのみのメッセージが生成されてもよい。なお、どのようなメッセージの生成手法を用いるかは、顧客から予め指定されていることが望ましい。メッセージ出力部１１６は、顧客から予め指定されたメッセージ生成手法に基づいて、利用される通信プロトコルに適合したメッセージがメッセージ出力部１１６から生成されるようにすることができる。

顧客装置１５０から、各々の通信プロトコルに対応した複数のメッセージが受取部１１０によって受け取られている場合には、メッセージ出力部１１６は、複数のメッセージから、使用される通信プロトコルに適合したメッセージを出力してもよい。受取部１１０は、顧客装置１５０から複数のメッセージを受け取った場合には、複数のメッセージの各々が、いずれの通信プロトコルに対応するメッセージであるかの情報も受け取ることが望ましい。なお、受取部が、複数のメッセージを受け取った場合であっても、その複数のメッセージのいずれもが、選択された通信プロトコルに適合しない場合には、メッセージ出力部１１６によって、その複数のメッセージから、選択された通信プロトコルに適合したメッセージが生成されることが望ましい。この場合においても、受取部１１０は、メッセージの生成の手法を、予め顧客装置から受け取ることが望ましい。メッセージ出力部１１６が、特定の通信プロトコルに適合するメッセージを生成できない場合には、送信要求部１１８は、その通信プロトコルを使用して通信端末１７０にメッセージを送る要求を通信事業体装置１６０に送らなくてもよい。

このようにして、受取部１１０は、メッセージ出力部１１６等と連携して、選択された通信プロトコルに適合したメッセージを送信要求部１１８に送る。なお、送信要求部１１８の動作については後述する。

＜ユーザが電話番号を取得するときの本人確認について＞
本実施形態では、宛先への到達率、メッセージ開封率、通信相手を特定する能力などが高いメッセージ通信を用いることを前提としている。したがって、ユーザが任意に設定または取得することができる一般的なメールアドレスを用いないことを前提としている。なお、メールアドレスが、電話番号と同様に、宛先への到達率、メッセージ開封率、通信相手を特定する能力などが高いメッセージ通信を担保できる場合には、そのメールアドレスを用いることとしてもよい。例えば、この例としては、移動体通信キャリアが電話番号に対応させてユーザに付与するメールアドレスが挙げられる。

既に述べたように、宛先への到達率、メッセージ開封率、通信相手を特定する能力などが高いメッセージ通信では、宛先に電話番号を用いるメッセージ通信が挙げられる。ユーザが電話番号を取得するためには、携帯電話の場合、電話番号が割り当てられたＳＩＭを取得することが必要である。そして、ユーザは、通信の使用料を支払うことが必要となる。このため、通常、運転免許証、パスポートなどの身分を証明する書類の提示が求められる。空港などで販売されるプリペイドＳＩＭの取得においても、音声通話機能付きのＳＩＭでは、パスポートなどにより本人確認が必要とされることが通常である。

なお、日本においては、ＳＭＳ機能付きデータ通信専用ＳＩＭカードをユーザが取得する場合、本人確認は不要である。電話番号の取得において、本人確認を要するか否かは、電話番号が音声通話機能を有するか否かで異なっている。電話番号がＳＩＰなどの通信プロトコルを利用するインターネット電話の電話番号であるか否かでも本人確認の要否は異なっている。

また、電話番号を割り当てたそれぞれの国の法制度によっても電話番号を取得するために本人確認を要するか否かは異なっている。なお、各国とも、本人確認を経て取得された電話番号であるか否かは、電話番号を割り当てたその国の行政主体等が公開する情報を取得することで、確認することが可能であることがほとんどである。

すなわち、電話番号毎に本人認証の信ぴょう性の度合いは異なっており、その度合いは、公開された情報から推測することができることがほとんどである。したがって、電話番号毎の本人認証のレベルについての情報を顧客に提供することは、ほとんどの場合可能である。そのような情報を顧客が知りたいと欲する場合には、例えば、この情報を後述するログ１３０に記録しておき、この情報を通信結果と共に顧客に提供してもよい。

＜通信事業体装置１６０の選択について＞
次に、電話番号又は電話番号に準ずるアドレスに対応する通信端末１７０との間でメッセージ通信を実現する場合の通信事業体装置１６０の選択について説明する。

電話番号が割り当てられた当初の通信事業体（通信キャリア）は、電話番号を割り当てた行政主体等の公開情報を取得することによって特定することができる。しかしながら、ＭＮＰ（Mobile Number Portability）のサービスをユーザが利用することによって、電話番号を管理する通信事業体（通信事業者）が変更されることがある。この場合、通信キャリアは同じ場合がある。また、通信事業体が変更されない場合であっても、通信端末の機種変更或いは通信端末への通信ソフトウエアのインストール、又はソフトウエアの削除により、送受信できる通信プロトコルが変更される場合もある。また、ＳＮＳなどのメッセージング通信のサービスが利用できる通信端末も存在する。

ログ１３０は、過去にメッセージ通信が成功した通信事業体装置１６０及び通信プロトコルを保存することが望ましい。なお、ログ１３０には、過去にメッセージ通信が成功した通信事業体装置１６０又は通信プロトコルのいずれか一方が保存されるようにしてもよい。また、過去にメッセージ通信が成功した通信事業体装置１６０及び通信プロトコルが用いられたにもかかわらず今回の通信が失敗した場合には、ログ１３０における該当するエントリーが削除されるか通信が失敗した旨が記録されることが望ましい。宛先の電話番号で、通信事業体装置選択部１１２が、まずこのログ１３０を検索することが望ましい。そして、過去においてメッセージ通信が成功した電話番号又は電話番号に準ずるアドレスがヒットした場合には、通信事業体装置選択部１１２は、ヒットした結果を利用して、通信事業体装置１６０を特定し、その通信事業体装置１６０及び通信プロトコルの情報を送信要求部１１８に与えることが望ましい。このようにすることによって、通信が成功する通信事業体装置１６０と通信プロトコルとの組み合わせの試行錯誤を繰り返す頻度を減らすことができる。

送信要求部１１８は、通信事業体装置選択部１１２から与えられた通信事業体装置１６０の情報及び通信プロトコル選択部１１４から与えられた通信プロトコルの情報を基にして、電話番号又は電話番号に準ずるアドレスに宛てて、適合するメッセージを通信端末１７０に送ることを、該当する通信事業体装置１６０に対して要求する。なお、ＭＮＰの情報などに基づき、利用できる通信事業体装置１６０の情報及び適用される通信プロトコルの情報が予め分かっている場合には、この情報を記録制御部１２２が、予めログ１３０に格納しておくことが望ましい。

電話番号に準ずるアドレスがメールアドレスである場合には、送信要求部１１８は、通信事業体装置１６０に送信要求を発することなく、インターネット網を介して、メールアドレスを用いて、メッセージを送信してもよい。

優先順位ＤＢ１３２は、顧客装置１５０からの指示により、どの通信事業体装置１６０と通信プロトコルとを優先的に選択するかの情報を保存してもよい。優先順位ＤＢ１３２の利用については、例えば以下のパターンが挙げられる。下記のいずれのパターンを採用するかは、顧客のポリシーに基づき、顧客装置１５０から予め通信事業体装置選択部１１２に指示され記憶されていてもよい。
なお、下記のパターンは例示であって、当業者は、下記のパターンを参考にしてその他のバリエーションを有するパターンを適用することができる。

（パターン１）優先順位ＤＢ１３２に格納された通信事業体装置１６０の選択順序を、通信プロトコルの選択順序よりも優先させるパターンであって、ログ１３０の記録は無視されるか、例えば優先順位ＤＢ１３２に基づいて最初に選択された通信事業体装置１６０で採用される通信プロトコルの全ての組合せが失敗した場合には、ログ１３０の記録を検索しヒットすればその情報を採用するパターン。
このパターンによれば、最も望まれる通信事業体装置１６０を優先的に利用できるようにすると共に、ログ１３０も適宜利用されるので、試行錯誤の回数を効果的に減少させることができる。

（パターン２）優先順位ＤＢ１３２に格納された通信プロトコルの選択順序を、通信事業体装置１６０の選択順序よりも優先させるパターンであって、ログ１３０で宛先がヒットすれば、ヒットした宛先に利用された通信プロトコルが、選択された通信プロトコルと一致していれば、優先順位ＤＢ１３２の通信事業体装置１６０の選択順序にかかわらず、ヒットした通信事業体装置１６０をまず優先的に選択するパターン。
このパターンによれば、望まれる通信プロトコルを選択した際に、通信事業体装置１６０の選択の試行錯誤の回数を効果的に減少させることができる。

（パターン３）ログ１３０の記憶内容を、優先順位ＤＢ１３２に格納された情報よりも優先させるパターンであって、ログ１３０で宛先がヒットすれば、ヒットした宛先に利用された通信事業体装置１６０及び通信プロトコルの組合せを優先的に選択し、かつ以下のいずれかのパターンを採用する：

（パターン３−１）ログ１３０でヒットしないか上記の組合せで通信が行えなかった場合には、優先順位ＤＢ１３２に格納された通信事業体装置１６０の選択順序を、通信プロトコルの選択順序よりも優先させるパターン。
このパターによれば、ログ１３０の情報が利用できるので、試行錯誤の回数を効果的に減少させることができ、かつ通信事業体装置１６０の選択の順序を優先させることができる。

（パターン３−２）ログ１３０でヒットしないか上記の組合せで通信が行えなかった場合には、優先順位ＤＢ１３２に格納された通信プロトコルの選択順序を、通信事業体装置１６０の選択順序よりも優先させるパターン。
このパターによれば、ログ１３０の情報が利用できるので、試行錯誤の回数を効果的に減少させることができ、かつ通信プロトコルの選択の順序を優先させることができる。
上記の各パターンの具体的事例を以下に示す。
（パターン１の例）

例えば、図１において、通信端末１７０ａに対しては、通信事業体装置１６０ａの通信プロトコル１９１よる通信と、通信事業体装置１６０ｂの通信プロトコル１９３による通信の複数の通信プロトコルが存在することがあり得る。このような状況は、例えば、通信事業体装置１６０ａが、ＳＮＳに関連するメッセージング通信プロトコルをサポートしており、通信事業体装置１６０ｂが、ＳＭＳ又はＲＣＳでの通信プロトコルをサポートしている場合が想定される。
そして、ログ１３０には、通信事業体装置１６０ａと通信端末１７０ａとの通信でＳＮＳに関連するメッセージング通信プロトコルが過去に成功したことが記録されており、優先順位ＤＢ１３２には、通信事業体装置１６０ｂが通信事業体装置１６０ａよりも優先して選択され、通信プロトコルはＲＣＳをＳＭＳよりも優先して選択されることが記憶されている場合が想定される。
この場合には、通信事業体装置選択部１１２は、ログ１３０に記録された通信事業体装置１６０ａの存在にかかわらず、優先順位ＤＢ１３２に優先すべきとして記憶された通信事業体装置１６０ｂをまず選択する。そして、通信プロトコル選択部１１４は、ＲＣＳ通信プロトコルを選択することとなる。
（パターン２の例）
例えば、顧客装置１５０から、ＲＣＳでのメッセージ通信を望むことが指示されている場合がこの例として挙げられる。

この場合、ＲＣＳメッセージ通信プロトコルをサポートする通信事業体装置１６０が優先される。いずれの通信事業体装置１６０が選択されるかは、ログ１３０がヒットし、そのヒットした情報の通信プロトコルがＲＣＳ通信プロトコルであれば、ログ１３０でヒットした通信事業体装置１６０の情報を優先する。ログ１３０がヒットしなければ、優先順位ＤＢ１３２の選択順序の情報に基づいて通信事業体装置１６０が選択され得る。
（パターン３−１の例）

ログ１３０で宛先がヒットすれば、ヒットした宛先への通信で過去に成功した、通信事業体装置１６０及び通信プロトコルが選択される。ログ１３０を検索した結果、宛先がヒットしなかった場合には、優先順位ＤＢ１３２に格納された通信事業体装置１６０の選択順序を優先して通信事業体装置１６０を選択する。そして、その選択された通信事業体装置１６０について、優先順位ＤＢ１３２に格納された通信プロトコルの選択順序に従って、通信プロトコルが選択される。
なお、パターン３−２の例は、パターン３−１の例から当業者が推測できるため省略する。

＜通信プロトコル選択部１１４に関する補足事項＞
通信プロトコル選択部１１４は、通信事業体装置１６０によって通信され得るメッセージの通信のプロトコルを選択する。通信プロトコル選択部１１４は、選択された通信プロトコルを、送信要求部１１８に伝達する。送信要求部１１８は、メッセージ出力部１１６からのメッセージと、メッセージが送信される通信プロトコルとを含む送信要求を、通信事業体装置選択部１１２が選択した通信事業体装置１６０に送る。送信要求部１１８と通信事業体装置１６０との間は、それぞれの通信事業体が定めたＡＰＩを用いて、直収接続されていることが望ましい。

通信事業体装置１６０と通信端末１７０との間の通信プロトコルには、例えば、ＳＭＳ、ＭＭＳ、ＲＣＳ等を伝送する通信プロトコル、ＳＮＳに付随した独自のメッセージング通信プロトコル等が挙げられる。

既に述べたように、通信プロトコル選択部１１４は、ログ１３０において過去に送信が成功した通信プロトコルを選択することとしてもよい。或いは、通信プロトコル選択部１１４は、優先順位ＤＢ１３２に記憶された優先順位に基づいて、優先される通信プロトコルを選択してもよい。或いは、通信事業体装置１６０が選択されている場合には、その通信事業体装置１６０がサポートする通信プロトコルのうちの一つが選択される。いずれの通信プロトコルが優先されるかは、優先順位ＤＢ１３２又はログ１３０のいずれかの情報を優先して決定されてもよい。
なお、ある通信事業体装置１６０が選択された場合に、その通信事業体装置１６０がサポートしていない通信プロトコルを選択しないようにする。このために、通信事業体装置１６０の各々によってサポートされている通信プロトコルに関する対応表が、優先順位ＤＢ１３２に格納されていることが望ましい。

＜ログ１３０の記録制御について＞
記録制御部１２２は、ログ１３０に記録される情報を制御する。
判断部１２４は、送信要求部１１８からの情報と、受信部１８０からの送信成功又は不成功の情報とから、メッセージの送信が成功したか否かを判断することができる。記録制御部１２２は、判断部１２４においてメッセージ通信が成功したと判断された電話番号又は電話番号に準ずるアドレス、通信事業体装置１６０、及び通信プロトコルの組み合わせを少なくともログ１３０に記録するよう制御する。なお、複数の通信経路において通信が成功している場合、ログ１３０には、同じ電話番号又は電話番号に準ずるアドレスに対して、複数の通信事業体装置１６０及び通信プロトコルの組み合わせが記録される場合もあり得る。

ログ１３０の情報が利用されることによって、送信要求部１１８は、メッセージ通信が成功する確率の高い通信事業体装置１６０に対して、メッセージ通信が成功する確率の高い通信プロトコルを指定して、電話番号又は電話番号に準ずるアドレスに宛てたメッセージの送信を要求することができる。

＜チャットについて＞
チャットボット１４２は、オペレータに代わって、通信端末１７０からのメッセージに自動的に応答して、通信端末１７０のユーザとの間での複数のメッセージのやり取りを実現する機能を有する。例えば、ＳＭＳ、ＭＭＳ、ＲＣＳなどのメッセージ通信では、メッセージをやり取りすることで、チャットをする機能を持っている。チャットボットにＡＩ（不図示）を実装させ、実際にオペレータとユーザとの間でなされたチャットを予め学習させておくことが望ましい。学習済みのデータを用いて、オペレータの代わりに、チャットボット１４２が、通信端末１７０のユーザとチャットを行うことができる。チャットボットは、受取部１１０、受信部１８０、及びログ１３０からの情報等を基にして、チャットのための応答メッセージを生成し、受取部１１０に渡すことで、応答メッセージを送信要求部１１８に提供する。
なお、顧客装置１５０において、チャットボット１５２が実装されてもよい。

＜メッセージ通信装置１００の変形例＞
メッセージ通信装置１００は、顧客装置１５０からの指示に基づいて、例えば以下のような変形例を実現することができる。
（変形例１）（ＲＣＳでのメッセージ通信を優先する変形例）

顧客は、ＲＣＳを用いて、画像などを含むリッチテキストを複数のユーザの通信端末に送信したいと望んでいる場合を想定する。しかしながら、ＲＣＳのメッセージを受信するためには、ＲＣＳをサポートするアプリケーションがユーザの通信端末１７０にインストールされている必要がある。加えて、通信事業体装置１６０も、ＲＣＳ通信プロトコルをサポートしていることが前提となる。そして、受取部１１０は、顧客装置１５０から、複数の送信先の電話番号と、ＲＣＳメッセージに加えて、ＲＣＳメッセージが送信できなかった通信端末に送信するＳＭＳメッセージを受け取る。

この変形例の場合には、まず通信プロトコル選択部１１４が、ＲＣＳを転送する通信プロトコルを優先して選択することとなる。例えば、電話番号でログ１３０を検索して、この電話番号が、過去にＳＭＳメッセージの通信が成功した電話番号であることが分かった場合を想定する。この場合にも、通信プロトコル選択部１１４は、ログ１３０からＳＭＳの通信プロトコルの情報が得られても、優先順位ＤＢ１３２にＲＳＣ通信プロトコルを優先して選択することが記憶されているため、ＲＣＳの通信プロトコルを選択し、これを送信要求部１１８に渡す。通信事業体装置選択部１１２は、ログ１３０から得られた通信事業体装置１６０がＲＣＳをサポートしていれば、その通信事業体装置１６０を選択し送信要求部１１８に渡す。メッセージ出力部は、ＲＣＳメッセージを送信要求部１１８に渡す。

送信要求部１１８は、選択された通信事業体装置１６０に対して、ＲＣＳの通信プロトコルで、ＲＣＳメッセージを送るよう要求する。要求された通信事業体装置１６０がＲＣＳメッセージを送信できた場合には、受信部１８０は送信成功の情報を受信する。要求された通信事業体装置１６０がＲＣＳメッセージを送信できなかった場合には、受信部１８０は送信失敗の情報を受信する。
ＲＣＳメッセージの送信が成功した場合には、記録制御部１２２は、電話番号又は電話番号に準ずるアドレスに対応させて、通信事業体装置１６０とＲＣＳメッセージ通信プロトコルをログ１３０に記録する。

ＲＣＳメッセージの送信が失敗した場合には、電話番号又は電話番号に準ずるアドレスでこの通信事業体装置１６０とＲＣＳ通信プロトコルとの組み合わせに関して、過去に通信が成功したエントリーがある場合は、そのエントリーを削除するか無効化する。記録制御部１２２は、電話番号又は電話番号に準ずるアドレスに対応させて、通信事業体装置１６０とＲＣＳメッセージ通信プロトコルとの組み合わせで失敗した旨を一時的にログに記録することとしてもよい。
通信事業体装置選択部１１２は、このログ１３０の情報を基にして、優先順位ＤＢ１３２を検索して、次に選択されるべき新たな通信事業体装置１６０を選択する。送信要求部１１８は、新たな通信事業体装置１６０に対して、ＲＣＳメッセージをＲＣＳ通信プロトコルによって同じ通信端末１７０に送信するよう要求する。送信要求部１１８からのＲＣＳメッセージの送信要求は、ＲＣＳメッセージの送信が成功するか、通信事業体装置１６０の選択肢が無くなるまで続けられる。

ＲＣＳメッセージによる通信事業体装置１６０の選択肢が無くなった場合には、例えば、優先順位ＤＢ１３２の記憶内容に基づいて、通信プロトコルとしてＳＭＳが選択される。ログ１３０にＳＭＳでのメッセージ通信に成功した記録があれば、その記録に基づいて、通信事業体装置選択部１１２は、ＳＭＳメッセージ通信が成功した通信事業体装置１６０を選択し、送信要求部１１８に送る。送信要求部１１８は、メッセージ出力部１１６からのＳＭＳメッセージを、ＳＭＳ通信プロトコルで、指定された電話番号の通信端末１７０に送信するよう、選択された通信事業体装置１６０に要求する。このＳＭＳメッセージ送信が成功すれば、記録制御部１２２は、その通信事業体装置１６０とＳＭＳメッセージ通信プロトコルとを、電話番号又は電話番号に準ずるアドレスに対応付けてログ１３０に記録する制御を行う。

メッセージ通信が成功するか、通信事業体装置１６０と通信プロトコルとの組み合わせの選択肢が無くなるまで、送信要求部１１８によってメッセージの送信要求が発せられる。
（変形例２）（特定の通信事業体装置１６０を優先する変形例）

例えば、なるべく特定の通信事業体装置１６０を利用してメッセージ通信を利用することで、複数の通信端末１７０へのメッセージ通信コストを低減することが可能である場合を想定する。この例としては、特定の通信事業体装置１６０が、メッセージ通信装置１００をも管理している場合などが挙げられる。この場合には、メッセージ通信装置１００と特定の通信事業体装置１６０とが、同じ企業の管理下に置かれていることになる。このため、通信事業体装置選択部１１２は、コストのかからない同じ企業の管理下におかれている通信事業体装置１６０を優先して選択することを望んでいる。なお、この場合には、同じ企業の管理下に置かれている通信事業体装置１６０によるメッセージ通信が、各宛先について成功するか否かは、予知できることとなる。例えば、ログ１３０に、所定の通信事業体装置１６０によって送信できる電話番号又は電話番号に準ずるアドレスを記憶させておいてもよい。

所定の通信事業体装置１６０によって送信できない電話番号又は電話番号に準ずるアドレスへのメッセージ送信については、通信事業体装置１６０と通信プロトコルとの組み合わせを網羅的に選択することによって、送信要求部１１８がメッセージの送信要求を行う。メッセージの送信が成功するか、通信事業体装置１６０と通信プロトコルとの組み合わせが無くなるまで、メッセージの送信要求が繰り返される。
なお、メッセージ通信装置１００と特定の通信事業体装置１６０とが、同じ企業の管理下に置かれていない場合であっても、通信料金を下げることができる通信事業体装置１６０を、上記と同様の処理を行わせることで優先的に選択することが可能である。

＜ハードウエア構成＞

図２は、メッセージ通信装置１００のハードウエア構成図である。メッセージ通信装置１００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、キー操作部２０５、時計部２０６、通信部２０７、表示部２１１、及び外部記憶制御部２１２を有する。

メッセージ通信装置１００は、外部記憶制御部２１２により、メモリ２１３に記憶されたプログラムを読み込んで動作することが可能である。プログラムは、ＲＯＭ２０１及びＲＡＭ２０３にも保存され得る。メッセージ通信装置１００は、プログラムを実行するＣＰＵ２０１の管理のもとに動作する。

＜動作フロー＞
図３は、一実施形態の処理の概要を示すフローチャートである。本明細書及び図面に開示された動作フローの各ステップは、矛盾の無い限り順番を入れ換えて実行されてもよい。また、複数のステップが同時に実行されてもよい。各ステップは、メモリに記憶されたプログラムを実行することにより実現されてもよい。また各ステップの一部は、オペレーティングシステム或いはハードウエアにより実現されてもよい。
また、各フローは排他的なものではなく、矛盾の無い限り組み合わせることができる。

ステップＳ３０２で、顧客装置１５０から電話番号又は電話番号に準ずるアドレスと、１つ以上のメッセージが受け取られる。１つ以上のメッセージの各々は、各メッセージ通信プロトコルに対応する。
ステップＳ３０４は、ステップ３１４との間で、特定の電話番号又は電話番号に準ずるアドレスについて、網羅的に処理を繰り返すことを示している。
ステップＳ３０６で、通信事業体装置１６０が選択される。
ステップＳ３０８で、通信プロトコルが選択される。通信プロトコルの選択によりメッセージの形態が特定される。

なお、ステップＳ３０６とステップＳ３０８の順番が逆であってもよい。また、通信プロトコルの選択をまず固定し、通信事業体装置１６０の選択を網羅的に行ってもよいし、通信事業体装置１６０の選択をまず固定し、通信プロトコルの選択を網羅的に行ってもよい。また、特定の電話番号又は電話番号に準ずるアドレスでログ１３０を検索してヒットした場合には、ヒットしたエントリーに記録された通信事業体装置１６０及び通信プロトコルのうち少なくともいずれか１つが優先的に選択されてもよい。
ステップＳ３１０で、メッセージの生成・出力がなされる。メッセージの形態は、選択された通信プロトコルに依存する。

ステップＳ３１２で、選択された通信事業体装置１６０に対して、選択されたプロトコルによって、特定の電話番号又は電話番号に準ずるアドレスに宛ててメッセージを送信するよう送信要求がなされる。
以上で処理が終了する。
図４は、一実施形態の処理の詳細を示すフローチャートである。この処理は、図３のステップＳ３１２の後に実行され得る。

ステップＳ４０２で、メッセージの送信が成功したか否かがチェックされる。このチェックがＹＥＳであれば、処理はステップＳ４０４に移る。このチェックがＮＯであれば、処理は終了してもよい。なお、ＮＯである場合において、ログ１３０に該当するエントリーがある場合には、そのエントリーを削除するか、無効である旨のフラグを立てるなどの処理を行ってもよい。

ステップＳ４０４で、ログ１３０に、メッセージの送信が成功した時の通信事業体装置１６０と通信プロトコルとが電話番号又は電話番号に準ずるアドレスに対応付けて少なくとも記録される。なお、メッセージの送信が成功した時の通信事業体装置１６０又は通信プロトコルのいずれかが電話番号又は電話番号に準ずるアドレスに対応付けて記録されるようにしてもよい。
以上で処理が終了する。

図５は、一実施形態の処理の詳細を示すフローチャートである。図５（Ａ）は、図３のステップＳ３０６の中で実行され得る。図５（Ｂ）は、図３のステップＳ３０８の中で実行され得る。
図５（Ａ）の処理について以下に説明する。
ステップＳ５０２で、ログ１３０の検索で電話番号又は電話番号に準ずるアドレスがヒットしたか否かがチェックされる。
このチェックがＹＥＳであれば、処理はステップＳ５０４に移る。このチェックがＮＯであれば、処理は終了する。

ステップＳ５０４で、ヒットした電話番号又は電話番号に準ずるアドレスに対応する通信事業体装置１６０が選択される。なお、既に述べたように、特定の通信事業体装置１６０の選択順序が優先される場合には、このステップＳ５０４の処理が無視されて、所定の選択順序に基づいて、通信事業体装置１６０が選択されてもよい。
以上で処理が終了する。
図５（Ｂ）の処理につて以下に説明する。
ステップＳ５１２で、ログ１３０の検索で電話番号又は電話番号に準ずるアドレスがヒットしたか否かがチェックされる。
このチェックがＹＥＳであれば、処理はステップＳ５１４に移る。このチェックがＮＯであれば、処理は終了する。

ステップＳ５１４で、ヒットした電話番号又は電話番号に準ずるアドレスに対応する通信プロトコルが選択される。なお、既に述べたように、特定の通信プロトコルの選択順序が優先される場合には、このステップＳ５１４の処理が無視されて、所定の選択順序に基づいて、通信プロトコルが選択されてもよい。
以上で処理が終了する。

図６は、一実施形態の処理の詳細を示すフローチャートである。図６（Ａ）は、図３のステップＳ３０６の中で実行され得る。図６（Ｂ）は、図３のステップＳ３０８の中で実行され得る。
図６（Ａ）の処理について以下に説明する。

ステップＳ６０２で、選択された通信事業体装置１６０においてサポートされる通信プロトコルが所定の優先順位で選択される。なお、ログ１３０の検索で電話番号又は電話番号に準ずるアドレスがヒットした場合であって、ヒットしたエントリーの通信事業体装置１６０が選択されている場合には、そのエントリーの通信プロトコルが選択されてもよい。
以上で処理が終了する。
図６（Ｂ）の処理について以下に説明する。

ステップＳ６１２で、選択された通信プロトコルをサポートする通信事業体装置１６０が所定の優先順位で選択される。なお、ログ１３０の検索で電話番号又は電話番号に準ずるアドレスがヒットした場合であって、ヒットしたエントリーの通信プロトコルが選択されている場合には、そのエントリーの通信事業体装置１６０が選択されてもよい。
以上で処理が終了する。
図７は、一実施形態の処理の詳細を示すフローチャートである。この処理は、図３のステップＳ３１０において実行され得る。

ステップＳ７０２で、１以上のメッセージのいずれかが、選択された通信プロトコルに適合するか否かがチェックされる。このチェックがＹＥＳであれば、処理は、ステップＳ７０６に移る。このチェックがＮＯであれば、処理はステップＳ７０４に移る。

ステップＳ７０４で、１以上のメッセージから、選択された通信プロトコルに適合するメッセージが生成される。この生成をどのように行うかは、顧客装置１５０によって、予め指示されていることが望ましい。
ステップＳ７０６で、選択された通信プロトコルに適合するメッセージが１以上のメッセージの中から選択される。
以上で処理が終了する。

＜その他の変形例＞
例えば、ＲＣＳでは、送信したメッセージが開封されたか否かを知ることができる。例えば、この開封されたか否かの情報を平均化した開封率が、記録制御部１２２によってログ１３０に記録されてもよい。そして、電話番号又は電話番号に準ずるアドレスでログ１３０を検索した場合に、複数のエントリーがヒットした場合であって、いずれのエントリーにも開封率が記録されている場合には、開封率の高いエントリーに対応する通信事業体装置１６０及び通信プロトコルの組合せが優先されて選択されるようにしてもよい。このようにすることによって、送信するメッセージの開封率を高めることができる。

以上に説明した各実施形態は、それぞれが排他的なものではなく、ある実施形態の一部を他の実施形態に組み込んだり、ある実施形態の一部を他の実施形態の一部で代替したりすることができる。

加えて、例示したフローチャートの各フローは、矛盾のない限り順番を入れ替えることができる。また、矛盾のない限り、例示された１つのフローを、異なるタイミングで、複数回実行することができる。
また、矛盾のない限り、複数のフローを同時に実行したりすることができる。

また、開示された実施形態の一部のプログラムは、オペレーティングシステムなどの汎用のプログラム、またはハードウエアで実現することができる。加えて、開示されたプログラムは、複数のハードウエアで分散して実行されてもよい。

上述の実施形態を実現するプログラムは、図２に示されるハードウエア構成を備えるコンピュータにより実行され得る。また，実施形態のプログラムは，コンピュータに実行させる方法として，インプリメントされてもよい。本実施形態のプログラムの一部又は全部は、オペレーティングシステムにより実行されてもよい。また、プログラムの一部がハードウエアにより実現されてもよい。プログラムは図２のメモリ２１３、ＲＯＭ２０２、又はＲＡＭ２０３に記憶されてもよい。

実施形態は，ハードウエアの装置としてインプリメントされ得る。
以上の実施形態は，請求項に記載された発明を限定するものではなく，例示として取り扱われることは言うまでもない。

１００ メッセージ通信装置
１１０ 受取部
１１２ 通信事業体装置選択部
１１４ 通信プロトコル選択部
１１６ メッセージ出力部
１１８ 送信要求部
１２２ 記録制御部
１２４ 判断部
１３０ ログ
１４２ チャットボット
１５０ 顧客装置
１５２ チャットボット
１６０ 通信事業体装置
１７０ 通信端末
１８０ 受信部

Claims (7)

1. 顧客から、少なくともアドレスと、前記アドレスに送信する１以上のメッセージとを受け取る受取部であって、前記アドレスは前記顧客のユーザの電話番号又は電話番号に準ずるアドレスであり、前記メッセージはテキストを含み得るメッセージである、受取部と、
   複数の通信事業体装置のうちの１つの通信事業体装置を選択する通信事業体装置選択部と、
   選択された前記通信事業体装置において用いられる複数の通信プロトコルのうちの１つの通信プロトコルを選択する通信プロトコル選択部と、
   前記１以上のメッセージから、選択された前記通信プロトコルに適合し前記アドレスに送るメッセージを出力するメッセージ出力部と、
   出力された前記メッセージが、前記アドレスに宛てて、選択された前記通信プロトコルで選択された前記通信事業体装置によって送信されるように、選択された前記通信事業体装置に前記メッセージの送信を要求する送信要求部であって、送信が成功するか前記通信事業体装置と前記通信プロトコルとの組み合わせが無くなるまで、前記要求を繰り返す送信要求部と、
   を有するメッセージ通信装置。
2. 前記送信が成功したか否かの判断を行う判断部と、
   前記判断部で送信が成功したと判断されたときの、前記通信事業体装置及び前記通信プロトコルと、前記アドレスとを対応付けてログへの記録を制御する記録制御部と、
   を更に有し、
   前記通信事業体装置選択部は、前記アドレスで、前記ログを検索して、前記アドレスがヒットした場合、ヒットした前記アドレスに対応する前記通信事業体装置を優先して選択し、
   かつ／又は
   前記通信プロトコル選択部は、前記アドレスで、前記ログを検索して、前記アドレスがヒットした場合、ヒットした前記アドレスに対応する前記通信プロトコルを優先して選択する、
   請求項１に記載のメッセージ通信装置。
3. 前記通信事業体装置選択部は、予め定められた前記通信事業体装置を優先して選択する、
   請求項１又は２に記載のメッセージ通信装置。
4. 前記通信事業体装置選択部は、予め定められた前記通信プロトコルを優先して選択する、
   請求項１又は２に記載のメッセージ通信装置。
5. 前記メッセージ出力部は、
   前記顧客から受け取った前記１以上のメッセージに基づいて、選択された前記通信プロトコルに適合するメッセージを出力する、
   請求項１ないし４のうちいずれか１項に記載のメッセージ通信装置。
6. 前記メッセージ出力部は、
   前記顧客から受け取った前記１以上のメッセージのいずれもが、選択された前記通信プロトコルに適合しない場合、前記１以上のメッセージを用いて、前記通信プロトコルに適合するメッセージを生成する、
   請求項５に記載のメッセージ通信装置。
7. 顧客から、少なくともアドレスと、前記アドレスに送信する１以上のメッセージとを受け取るステップであって、前記アドレスは前記顧客のユーザの電話番号又は電話番号に準ずるアドレスであり、前記メッセージはテキストを含み得るメッセージである、受け取るステップと、
   複数の通信事業体装置のうちの１つの通信事業体装置を選択するステップと、
   選択された前記通信事業体装置において用いられる複数の通信プロトコルのうちの１つの通信プロトコルを選択するステップと、
   前記１以上のメッセージから、選択された前記通信プロトコルに適合し前記アドレスに送るメッセージを出力するステップと、
   出力された前記メッセージが、前記アドレスに宛てて、選択された前記通信プロトコルで選択された前記通信事業体装置によって送信されるように、選択された前記通信事業体装置に前記メッセージの送信を要求するステップであって、送信が成功するか前記通信事業体装置と前記通信プロトコルとの組み合わせが無くなるまで、前記要求を繰り返す送信を要求するステップと、
   をコンピュータに実行させるメッセージ通信プログラム。
   

Images