(57)【要約】【課題】確実にSMS配信できるSMS配信装置及びSMS配信方法を提供する。【解決手段】  送信データ１３、１５をSMSにより携帯電話端末７に送信する送信装置２３と、前記送信データ１３を送信するキャリアを判定するキャリア判定部２５、３０とを備え、前記キャリア判定部は、NTT交換局３２に前記携帯電話端末７の電話番号に対応するキャリアを問い合わせる手段を有する。更に、前記キャリアの問い合わせは、ISDNのDチャネルを利用した、ATコマンド３４の通信である。キャリアDB26により判定されたキャリアが誤っていた場合に、前記NTT交換局に問い合わせてキャリアを判定する。【選択図】図２
2018046530.tif 000002
【特許請求の範囲】
【請求項１】
送信データをSMSにより携帯電話端末に送信する送信装置と、
前記送信データを送信するキャリアを判定するキャリア判定部とを備え、
前記キャリア判定部は、NTT交換局に前記携帯電話端末の電話番号に対応するキャリアを問い合わせる手段を有することを特徴とするSMS配信装置。
【請求項２】
前記キャリアの問い合わせは、ISDNのDチャネルを利用した、ATコマンドの通信であることを特徴とする請求項１に記載のSMS配信装置。
【請求項３】
前記キャリア判定部は、予め登録された携帯電話端末とキャリアとを関係付けたキャリアDBに基づいて前記携帯電話端末のキャリアを判定する手段を更に有することを特徴とする請求項１または２に記載のSMS配信装置。
【請求項４】
前記キャリアDBにより判定されたキャリアが誤っていた場合に、前記NTT交換局に問い合わせてキャリアを判定することを特徴とする請求項３に記載のSMS配信装置。
【請求項５】
顧客システムはSMS送信リクエストをSMS配信装置に要求するステップと、
前記SMS配信装置は、前記SMS送信リクエストに基づいて、送信先の携帯電話端末のキャリアを判定するステップと、
前記SMS配信装置は、前記SMS送信リクエスト及び前記判定されたキャリアに基づいて、送信データを作成し、SMSにより前記携帯電話端末に前記送信データを送信するステップと、
前記SMS配信装置は前記送信データに対する返信データを前記携帯電話端末から受信するステップと、
前記SMS配信装置は前記返信データに基づき前記顧客システムにSMS受信レスポンスを応答するステップとを含み、
前記キャリアを判定するステップは、NTT交換局に前記携帯電話端末の電話番号に対応するキャリアを問い合わせて、前記携帯電話端末のキャリアを判定することを特徴とするSMS配信方法。
【請求項６】
前記キャリアを判定するステップは、予め登録された携帯電話端末とキャリアとを関係付けたキャリアDBに基づいて前記携帯電話端末のキャリアを判定するステップを更に含み、
前記キャリアDBにより判定されたキャリアが誤っていた場合に、前記NTT交換局に問い合わせてキャリアを判定することを特徴とする請求項５に記載のSMS配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、SMS（ショートメッセージサービス）を利用して、携帯電話端末との間で情報のやりとりを行うSMS配信装置及びSMS配信方法、特にキャリア判定の精度の高いSMS配信装置及びSMS配信方法に関する。
【０００２】
携帯電話サービスを提供する通信事業者（キャリア）が提供する携帯電話端末はSMS機能を備えている。SMSは電話番号を宛先として指定してメッセージをやりとりできるサービスであり、SMSのメッセージは、携帯電話端末の通話回線の制御チャンネルを使用してデータが送信されるので、電子メール（Ｅメール）に比べてリアルタイム性に優れるとともに、相手がメッセージを受け取ったことを確認することが可能である等の理由で、SMSは多くの国で既に利用されている（例えば、特許文献１参照）。
【０００３】
これらリアルタイム性等を有するというSMSの特徴を利用して、企業等のサーバからSMSによりユーザの携帯電話端末にメッセージを提供するサービスが行われている。例えば、ユーザの携帯電話端末に、株式情報等の時々刻々と変化する情報をメッセージとして提供するサービスや、携帯電話端末を所持する利用者の安否を確認するサービスが提案されている（例えば、特許文献２、特許文献３参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−３４９２８号公報
【特許文献２】特開２００９−１０５９０８号公報
【特許文献３】特開２０１４−９９７３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、従来にあっては、総務省払出番号表を参照しその番号帯域により携帯電話端末のキャリアを判定していた。また、SMS配信事業者は独自で携帯電話端末の電話番号とキャリアを関係付けたキャリアDBを作成しておき、このキャリアDBに基づいて携帯電話端末のキャリアを判定することも行われている。
【０００６】
しかしながら、MNP（モバイルナンバーポータビリティ）が行われるようになって、携帯電話端末の電話番号を維持したまま、当該電話番号に対応づけられるキャリアが変更されることがある。上述した総務省払出番号表はその更新頻度が数十日程度でありMNPの情報が反映されるまでに長いタイムラグが生じていた。また、独自に作成するキャリアDBにもタイムラグが生じ、このタイムラグを短くするためには更新間隔を非常に短くする必要があり、更新負荷が高くなり実現が困難であった。このようなことから、MNPによりキャリアが最近変更された携帯電話端末には企業等のサーバからSMS配信をすることができないことがあった。
【０００７】
本発明は、このような問題点に着目してなされたもので、確実にSMS配信できるSMS配信装置及びSMS配信方法を提供することを目的とする。
なお、本明細書において、「キャリア」は携帯電話サービスを提供するNTTドコモやKDDI等の通信事業者を意味する。
【課題を解決するための手段】
【０００８】
本発明のSMS配信装置は、
送信データをSMSにより携帯電話端末に送信する送信装置と、
前記送信データを送信するキャリアを判定するキャリア判定部とを備え、
前記キャリア判定部は、NTT交換局に前記携帯電話端末の電話番号に対応するキャリアを問い合わせる手段を有することを特徴としている。
この特徴によれば、MNPの情報が随時更新されるNTT交換局に問い合わせているためキャリアをリアルタイムで判定できる。そのため、MNPにより最近キャリアが変更された携帯電話端末にも確実にSMS配信をすることができる。
【０００９】
前記キャリアの問い合わせは、ISDNのDチャネルを利用した、ATコマンドの通信であることを特徴としている。
この特徴によれば、キャリアの識別をISDNのDチャネルを利用して行っており、この送信層はSMSの送信層とは異なるため、SMS送信層に負担をかけることがない。
【００１０】
前記キャリア判定部は、予め登録された携帯電話端末とキャリアとを関係付けたキャリアDBに基づいて前記携帯電話端末のキャリアを判定する手段を更に有することを特徴としている。
この特徴によれば、キャリア判定部は、NTT交換局への問い合わせとキャリアDBへのアクセスの２種類の判定手段を有しているため、一方の判定手段が使えないときにもキャリア判定をすることができる。
【００１１】
前記キャリアDBにより判定されたキャリアが誤っていた場合に、前記NTT交換局に問い合わせてキャリアを判定することを特徴としている。
この特徴によれば、NTT交換局への問い合わせよりもキャリアDBへのアクセスによる判定の方が速いのみならずコマンド送信等の負荷も少なく、かつ、最近MNPによりキャリアが変更になった携帯電話端末の割合は小さいため、先ずキャリアDBによるキャリア判定を行うことによりトータルのSMS配信の効率に優れる。
【００１２】
本発明のSMS配信方法は、
顧客システムはSMS送信リクエストをSMS配信装置に要求するステップと、
前記SMS配信装置は、前記SMS送信リクエストに基づいて、送信先の携帯電話端末のキャリアを判定するステップと、
前記SMS配信装置は、前記SMS送信リクエスト及び前記判定されたキャリアに基づいて、送信データを作成し、SMSにより前記携帯電話端末に前記送信データを送信するステップと、
前記SMS配信装置は前記送信データに対する返信データを前記携帯電話端末から受信するステップと、
前記SMS配信装置は前記返信データに基づき前記顧客システムにSMS受信レスポンスを応答するステップとを含み、
前記キャリアを判定するステップは、NTT交換局に前記携帯電話端末の電話番号に対応するキャリアを問い合わせて、前記携帯電話端末のキャリアを判定することを特徴としている。
この特徴によれば、MNPの情報が随時更新されるNTT交換局に問い合わせているためキャリアをリアルタイムで判定できる。そのため、MNPにより最近キャリアが変更された携帯電話端末にも確実にSMS配信をすることができる。
【００１３】
前記キャリアを判定するステップは、予め登録された携帯電話端末とキャリアとを関係付けたキャリアDBに基づいて前記携帯電話端末のキャリアを判定するステップを更に含み、
前記キャリアDBにより判定されたキャリアが誤っていた場合に、前記NTT交換局に問い合わせてキャリアを判定することを特徴としている。
この特徴によれば、NTT交換局への問い合わせよりもキャリアDBへのアクセスによる判定の方が速いのみならずコマンド送信等の負荷も少なく、かつ、最近MNPによりキャリアが変更になった携帯電話端末の割合は小さいため、先ずキャリアDBによるキャリア判定を行うことによりトータルのSMS配信の効率に優れる。
【図面の簡単な説明】
【００１４】
【図１】実施例１のSMS配信システムの構成を示すブロック図である。
【図２】実施例２のSMS配信システムの構成を示すブロック図である。
【図３】実施例２のキャリア判定を説明するフローチャートである。
【発明を実施するための形態】
【００１５】
本発明に係るSMS配信装置及びSMS配信方法を実施するための形態を実施例に基づいて以下に説明する。
【実施例１】
【００１６】
図１を参照して実施例１を説明する。SMS配信システムは、顧客システム１、双方向SMS配信装置２、ユーザの携帯電話端末７から主に構成され、双方向SMS配信装置２と携帯電話端末７との間で双方向にデータをやりとりするものである。
【００１７】
顧客システム１は、コンピュータであって、双方向SMS配信装置２に、SMS送信リクエスト１０を送り、その結果であるSMS受信レスポンス１１を受け取るものである。SMS送信リクエスト１０には「問い合わせ内容」と「問い合わせを行うユーザ」が含まれる。ここで、「問い合わせ内容」は、例えば安否確認であり、「問い合わせを行うユーザ」は予め登録されている３０００人のユーザから選ばれたユーザ名のリストである。なお、ユーザ名に代えてユーザの携帯電話端末７の電話番号としてもよい。また、SMS受信レスポンス１１は、例えば問い合わせを行ったユーザ毎の安否情報である。
【００１８】
双方向SMS配信装置２は、ユーザの携帯電話端末７にSMSにより問い合わせた結果を顧客にレスポンスするサーバであり、送信キュー登録部２０、送信DB２８、送信装置２９、ISDNルータ３１、受信装置５０、受信DB５２から主に構成されている。なお、ISDNルータ３１は双方向SMS配信装置２の外部にあってもよい。
【００１９】
送信キュー登録部２０は、リクエスト受付部２１、受付キュー登録部２２、受付DB２３、受付キュー取得部２４、キュー登録部２７、第２キャリア判定部３０から主に構成され、受け付けたSMS送信リクエスト１０から携帯電話端末７にSMS送信する送信キューを作成し、送信DB２８に登録する。
【００２０】
詳細には、リクエスト受付部２１はSMS送信リクエスト１０を受け付けると、受付キュー登録部２２は問い合わせに含まれる「ユーザ名」を基に図示しない「ユーザ−電話番号リスト」を参照し、ユーザに対応する問い合わせをする携帯電話端末７の電話番号を取得し、電話番号毎に「問い合わせ内容」を基に「コンテンツ」を作成し、受付キューとして受付DB２３に登録させる。
【００２１】
受付キュー取得部２４は受付DB２３から電話番号毎に受付キューを取得する。第２キャリア判定部３０は受付キューに含まれる電話番号を用いて携帯電話端末７のキャリアを後述するようにして判定する。キュー登録部２７は判定されたキャリアの情報を含む送信キューを送信DB２８に登録する。送信装置２９は送信キューを基に携帯電話端末７の電話番号毎に、キャリア（キャリア直収I/F）にあったプロトコルで送信データ１３を作成しSMS送信する。なお、送信データ１３を作成する際には、送信データ１３のセンダIDとして双方向SMS配信装置２に割り当てられたキャリアの予め登録されている電話番号を設定する。
【００２２】
次にキャリア判定（リアルタイム）について説明する。
第２キャリア判定部３０は、受付キューから問い合わせをする携帯電話端末７の電話番号を抽出し、電話番号を含むATコマンド３４「ATDXXXXXXXXXX」（なお、「XXXXXXXXXX」は電話番号である。）を送り、ISDNルータ３１、ISDN回線３３のＤチャネルを利用してNTT交換局３２に問い合わせる。その後、第２キャリア判定部３０はAT＃CコマンドをNTT交換局３２に送り、回線を切断する。なお、通信の前段で回線断を発生させることにより、ISDN回線３３のトラフィックが増大することを抑制できる。
【００２３】
第２キャリア判定部３０は、ATコマンド３４に対する応答として、NTT交換局３２からキャリアレスポンス３５を得る。キャリアレスポンス３５は、CAUSE（＝＃の後に切断理由コードを表示）、SOURCE（＝の後に生成源を表示）、CHARGGE（￥の後に通信料金を表示）から構成されており、CAUSEの＃の後の切断理由コードを解析することでキャリアを判断することができる。例えば、切断理由コードが088であればキャリアはNTT東日本（固定電話）である。同様に003はAU、065はソフトバンク、069はNTTドコモ、127はY!mobileである。
【００２４】
上述のようにして、第２キャリア判定部３０は携帯電話端末７のキャリアを判定し、キュー登録部２７にキャリア情報を送り、キュー登録部２７は上述したように送信キューを送信DB28に登録させる。一方、第２キャリア判定部３０は上述した切断理由コードがキャリアを判定できない旨のコードである場合には、送信キュー登録部２０は番号不備レスポンス１２を顧客システム１に送る。
【００２５】
送信データ１３を受け取った携帯電話端末７の表示部には、送信元の電話番号とともに、問い合わせ内容が表示される。ここで、表示される送信元の電話番号は双方向SMS配信装置２に割り当てられた電話番号である。携帯電話端末７のユーザは、表示部に表示された問い合わせ内容に応じた回答（例えば、安否確認の問い合わせに応じて、安全である旨の回答）操作をした後、表示部に表示された電話番号宛に返信操作を行う。この返信操作により、携帯電話端末７は、回答内容を含むデータを返信データ１４としてSMS返信する。
【００２６】
返信データ１４を受け取った受信装置５０は、返信データ１４に含まれる「回答内容（例えば安否情報）」と「ユーザ名」を含む、SMS受信キューを生成し、受信キュー登録部５１に送信する。受信キュー登録部５１はSMS受信キューを受信DB５２に登録する。SMS送信リクエスト１０により問い合わせを行った全てのユーザからの回答（無応答等の回答も含む）が受信DB５２に受信キューとして登録された後、これらの回答をテーブル形式にまとめ、双方向SMS配信装置２は顧客システム１にSMS受信レスポンス１１として応答する。
【００２７】
このように、第２キャリア判定部３０は、MNPの情報が随時更新されるNTT交換局３２に問い合わせているため、キャリアをリアルタイムで判定できる。したがって、MNPにより最近キャリアが変更された携帯電話端末７のキャリアを認識することが可能であり、当該携帯電話端末７にも確実にSMS配信をすることができる。
【００２８】
また、キャリアの判定をISDN回線３３のDチャネルを利用して行っており、この送信層はSMSの送信層とは異なるため、SMS送信層に負担をかけることがない。
【実施例２】
【００２９】
図２〜図３を参照して実施例２を説明する。なお、実施例１と同様の事項についてはその説明を省略する。実施例２は、第１キャリア判定部を有し、第２キャリア判定は必要であるときのみ第２キャリア判定を行う点が、主に実施例１と相違している。
【００３０】
受付キュー取得部２４は受付DB２３から電話番号毎に受付キューを取得する。
第１キャリア判定部２５は受付キューに含まれる電話番号を用いて携帯電話端末７のキャリアを判定する（Ｓ１）。具体的には、受付キュー取得部２４は、「電話番号−キャリア対応テーブル」を有するキャリアDB２６にアクセスし、当該電話番号に対応するキャリア情報を取得する。なお、顧客システム１からSMS送信リクエストを行う携帯電話端末７が予め決められている固定の場合には、「電話番号−キャリア対応テーブル」を予め用意しておくことができる。また、顧客システム１からSMS送信リクエストを行う携帯電話端末７が予め決まっておらず可変の場合には、総務省払出番号表を保持する総務省サーバにアクセスして全ての携帯電話端末７について「電話番号−キャリア対応テーブル」を予め用意しておくことができる。
【００３１】
送信装置２９は実施例１と同様に送信データ１３を作成し、Ｓ１により判定されたキャリアに、送信データ１３をSMS送信する（Ｓ２）。
次に、送信データ１３が携帯電話端末７に正常に送信できたか否かを判定し（Ｓ３）、受信装置５０が返信データ１４をSMS受信すれば、上記送信データ１３は携帯電話端末７に正常に送信できたとして次の送信キューのキャリア判定を行う。
なお、Ｓ３において、送信キュー毎に送信データ１３の正常送信を判断する例について説明しているが、これに限らず複数の送信キューを単位として送信データ１３の正常送信を判断するものであってもよく、例えば全ての送信キューに対応する送信データ１３を送信した後に、送信データ１３の正常送信の判断を行うようにしてもよい（この場合にはＳ３における「Ｙ」の経路は不要となる。）。
【００３２】
一方、送信データ１３を携帯電話端末７にSMS送信できない旨のエラー信号４０をキャリアから受信する等、受信装置５０が返信データ１４をSMS受信しない場合には、第２キャリア判定部３０によりキャリア判定を行う。なお、第２キャリア判定部３０の構成は実施例１と同様である。
【００３３】
送信装置２９は実施例１と同様に送信データ１５を作成し、Ｓ４により判定されたキャリアに、送信データ１５をSMS送信する（Ｓ５）。
次に、送信データ１５が携帯電話端末７に正常に送信できたか否かを判定し（Ｓ６）、受信装置５０が返信データ１６をSMS受信すれば、上記送信データ１５は携帯電話端末７に正常に送信できたとして次の送信キューのキャリア判定を行う。
なお、Ｓ６においても、上述したＳ３と同様に、複数の送信キュー毎に送信データ１５を正常送信できたか否かを判断するものであってもよい。
【００３４】
一方、送信データ１５を携帯電話端末７にSMS送信できない旨のエラー信号４１をキャリアから受信する等、受信装置５０が返信データ１６をSMS受信しない場合には、番号不備等のエラー（Ｓ７）であるとし、この場合にも送信キュー登録部２０は番号不備レスポンス１２を顧客システム１に送る。
【００３５】
このような構成としたため、実施例１と同様の作用効果を奏する。
また、キャリアDB２６へのアクセスを行う第１キャリア判定部２５と、NTT交換局３２への問い合わせを行う第２キャリア判定部３０との、２種類の判定部を有しているため、一方の判定部が使えないときにもキャリア判定をすることができる。
【００３６】
また、キャリアDB２６へのアクセスはデータベースへのアクセスであるため、NTT交換局３２へのATコマンドを用いた通信よりも、判定を高速で実現できる。さらに、キャリアDB２６のデータは一般に定期的に更新して使用されているため、キャリアが誤っている割合（すなわち最近MNP変更された割合）は小さい。このことから、先ずキャリアDB２６へのアクセスを行う第１キャリア判定部２５による判定を行い、キャリアが正しくない場合に限り、NTT交換局３２への問い合わせを行う第２キャリア判定部３０による判定を行うため、トータルのキャリア判定に要する時間を短縮することができ、トータルのSMS配信の効率に優れるとともに、過度なATコマンド送信等の負荷も少なくできる。
【００３７】
以上、本発明の実施例を図面とともに説明したが、具体的な構成はこれら実施例に限定されるものではなく、本発明の用紙を逸脱しない範囲における変更や追加があっても本発明に含まれる。
【００３８】
実施例１、２では、メッセージの問い合わせ内容として安否確認を説明したが、アンケートの照会、株価の提供等その内容は問わない。
【００３９】
また、携帯電話端末７は、電話番号を用いてSMSによりショーとメッセージを送れるものであれば、その端末の種類は問わない。
【００４０】
また、顧客システム１における顧客は広義の意味であり双方向SMS配信装置２を利用する者のシステムであればよい。また顧客システム１はコンピュータを例に説明したが携帯情報端末や携帯電話端末であってもよい。
【００４１】
また、双方向SMS配信装置２は、送信装置２９と受信装置５０とが一つのサーバ内に組み込まれた構成でもよいし、別々に分散して設けられた構成でもよい。
【００４２】
また、携帯電話端末７はキャリア直収のSMS送信及びSMS受信に対応したものについて説明したが、送信及び受信の少なくともキャリア直収の通信に代えて端末間通信（ＨＴＴＰ、ＳＭＴＰ、無線通信LAN機能を用いる通信）としてもよい。
【００４３】
また、双方向SMS配信装置２と携帯端末装置７との間で双方向にSMS送受信する例について説明したが、SMS配信装置から携帯端末装置７に向けてのみSMS送信（配信）するものであってもよい。
【符号の説明】
【００４４】
１                              顧客システム
２                              双方向SMS配信装置（SMS配信装置）
７                              携帯電話端末
１０                            SMS送信リクエスト
１１                            SMS受信レスポンス
１３、１５                      送信データ
２５                            第１キャリア判定部（キャリア判定部）
２６                            キャリアDB
２９                            送信装置
３０                            第２キャリア判定部（キャリア判定部）
３２                            NTT交換局
３３                            ISDN回線
３４                            ATコマンド
３５                            キャリアレスポンス
５０                            受信装置
【図１】
2018046530.tif 000003
【図２】
2018046530.tif 000004
【図３】
2018046530.tif 000005