JP5412613B1

JP5412613B1 - 通知システム

Info

Publication number: JP5412613B1
Application number: JP2013053300A
Authority: JP
Inventors: 高司松原
Original assignee: MRS Holdings Co Ltd
Current assignee: MRS Holdings Co Ltd
Priority date: 2013-03-15
Filing date: 2013-03-15
Publication date: 2014-02-12
Anticipated expiration: 2032-12-14
Also published as: JP2014120150A

Abstract

【課題】支サービスや商品などを利用、購入するための継続的な料金支払いに関して支払手段を変更した際には、その変更可否の通知を、例えば料金の請求書や領収書などの通知と同じ方法で行うことができる通知システムを提供する。
【解決手段】顧客ＩＤとその料金の支払手段および領収書などの通知手段とを関連付けたマスタデータなどを保持、管理するとともに、支払手段の変更をインターネットなどの通信を介して受付けた場合に、すぐにその変更可否の返信ができない場合には、当該マスタデータを参照して、そこで示される領収書などの通知手段と同じ方法で通知を行うように構成する。
【選択図】図２

Description

本発明は、顧客に各種の通知を好適に行うための技術に関する。

従来、電気やガス、水道などの公共サービスの利用や電話やインターネットの利用、またトレーニング施設や塾など諸設備や人材サービスの利用、あるいは定期的な雑誌や農作物の購入などのように、継続的に料金が徴収されることで提供されるサービスや商品販売がある。

また、このようなサービスや商品販売に係る料金の徴収に関して、請求書や領収書などを通知することも行われている。このような場合、現在は郵送での通知のほか、各種メールサービスや、ユーザＩＤログインによるユーザ別Ｗｅｂページへの掲載などで通知がなされている。

さらに、これら料金を顧客が支払うための方法に関して、例えば銀行口座からの自動引き落としやクレジット支払い、あるいはコンビニなどの徴収代行業者やサービス・商品提供者の店舗窓口での支払い、インターネットなどを利用したその他の電子決済での支払いなどのさまざまな支払手段が提供されている。

そして、前述の通知においては、例えばこれら支払手段の違いに応じてその通知内容なども異なってくる。例えば銀行口座からの自動引き落としである場合、料金の請求に関する通知は必要なく、領収に係る内容のみが通知されれば良い。一方で、コンビニなどの窓口支払いである場合、窓口端末に読み取らせることでスムーズな料金支払を可能とするための情報（請求ＩＤや顧客ＩＤ、徴収金額など）を示す二次元コードなどを通知する必要がある。

そのため、上記サービスや商品の提供者は、顧客ごとに上記いずれの支払手段で料金徴収を行うかを管理するマスタデータを保持し、その管理情報に合わせて料金徴収に係る通知を行うようにしている。またその通知を行うための方法（郵送かメール送信かなど）も合わせてマスタデータなどで管理していることも多い。

また、特許文献１には、公共サービスの料金支払いにおいて、通信ネットワーク上で各種電子決済を行えるよう構成した公共料金電子決済システムが開示されている。

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

ここで例えば顧客Ａが料金の支払いをコンビニの窓口支払いから銀行口座の自動引き落としに変更する、という具合に支払手段が変更される場合がある。このような場合、その変更が許可された旨の情報に応じて上記マスタデータが書き換えられる。

また、このような支払手段の変更においては、顧客に対して支払変更の申請が受理され正しく変更されたこと、あるいは変更申請は受理したものの何らかの理由で変更が認められないことなどを通知する必要がある。そして、その通知は主に郵送などで行われているが、それは特に前述の料金徴収のための請求や領収にかかる通知とはまったく別に行われている。

つまり、上記のようにマスタデータにて顧客ごとの料金支払手段に加えて、当該料金徴収に係る請求書や領収書などの通知方法も管理されているにも関わらず、支払手段の変更に関する通知に関しては、そのマスタデータが活用されていない、という課題がある。

そのため、例えば料金の請求書や領収書はメールで通知されるにも関わらず、支払手段の変更を申請した際の返答（変更完了や不許可による変更未了など）の通知は郵送でなされる、といったことも起こり得る。そして、そうすると、当該サービスや商品購入に関する通知はメールで来ると思い込んでいる顧客は、郵送で送られてくる支払手段の変更に係る通知に気付かない等の事態も想定される。

以上の課題を解決するために、本発明は、顧客ＩＤとその料金の支払手段および領収書などの通知手段とを関連付けた上記のようなマスタデータを保持、管理するとともに、支払手段の変更をインターネットなどの通信を介して受付けた場合に、すぐにその変更可否の返信ができない場合には、当該マスタデータを参照して、そこで示される領収書などの通知手段と同じ方法で通知を行うように構成されたことを特徴とする通知システムを提供する。

具体的には、電気、ガス、水道、電話、その他の商品や役務など、連続あるいは断続を問わないが同一顧客から継続的に料金徴収が行われるモノ又はサービスの料金の徴収のための通知システムであって、複数の通知手段を実行するためのハードウェアを制御するハードウェア制御部と、顧客ＩＤと料金支払手段ＩＤとを関連付けて保持する第一顧客情報保持部と、顧客ＩＤとその顧客に対する請求又は／及び領収などに関する通知をするための通知手段とを関連付けて保持する第二顧客情報保持部と、銀行引落、クレジット支払、窓口支払、広域的通信網又はその他の閉鎖的通信網に構築される電子決済システムでの支払い、あるいは、その他の支払いなどの顧客選択可能な料金支払手段ＩＤを保持する支払手段保持部と、支払手段保持部に保持されている料金支払手段ＩＤの中から選択することで、顧客ＩＤと関連付けて第一顧客情報保持部に保持されている料金支払手段ＩＤの変更を、通信を介して受付ける支払手段変更受付部と、受付けた料金支払手段が実行可能かを示す実行可否情報を取得する可否取得部と、可否取得部で取得した実行可否情報に基づいた変更可能、変更完了又は変更不可を示す顧客への通知を前記通信中に取得した場合にはその通信を介して顧客に対して行い、顧客への通知を前記通信中に取得しない場合又は／及び前記通信中に取得した場合には第二顧客情報保持部に保持された通知手段を用いて通知するための処理をハードウェア制御部に対して実行させる実行命令部と、を有する通知システムを提供する。

また、その通知手段を携帯電話機能で用いられるメールに類するサービスやＷｅｂサービスとして、通知に際してはハードウェアとしてその携帯電話機能を制御し、メール等やＷｅｂサービスなどで通知を行うよう構成された通知システムも提供する。具体的には、上記構成に加えて、第二顧客情報保持部に保持されている前記通知手段は少なくとも携帯電話機能で用いられる通信サービスとＷｅｂサービスのいずれかを含み、前記ハードウェア制御部は、ハードウェアとして携帯電話機能を制御するＳＩＭ制御手段を有する通知システムも提供する。

また、通知用ハードウェアを実現するため携帯電話機能をＳＩＭ制御手段にて制御する場合、例えば携帯電話キャリアによる一日当たりの送信数の上限規制（発信上限）に応じて一のＳＩＭ制御手段から送信可能な通知の数を予め定められていることがある。つまりその一のＳＩＭ制御手段あたりの送信可能数と通知先顧客のと、から必要なＳＩＭ制御手段の数を算出されることになる。

しかし、携帯電話キャリアなどの個別の事情でこの発信上限が変更されると、一のＳＩＭ制御手段で送信できる通知数も変わり、それに応じて必要となるＳＩＭ制御手段の数も変わってくる。そこで、その送信数の規制上限を正確に把握するために試験的に通知を送信し、その試験通知の上限エラーから把握した発信上限に基づいて請求書や領収書などの通知の送信に必要なＳＩＭ制御手段の数を算出する機能をさらに備える通知システムも提供する。

具体的には、上記構成を備え、さらに前記携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数有する通知システムであって、前記顧客以外の試験用の送信先アドレスである試験用アドレスを保持する試験用アドレス保持部と、前記携帯電話機能を有するハードウェアを制御して一以上の試験用アドレスに対して、携帯電話キャリアにて定められる単一携帯電話からの発信上限を定める時間枠内に送信数を順次増やしながら試験通知を実行する試験実行部と、前記送信数が前記発信上限を超えたために送信できなかった旨を示す上限エラーを受信する上限エラー受信部と、受信した上限エラーに基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する発信上限算出部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムを提供する。

また試験的な通知による発信上限を把握する替わりに、顧客への実際の通知送信に対する上限エラーから発信上限を把握し、請求書や領収書などの通知の送信に必要なＳＩＭ制御手段の数を算出する機能をさらに備える通知システムも提供する。

具体的には、上記構成を備え、さらに前記携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数有する通知システムであって、前記ハードウェア制御部は、携帯電話機能を有するハードウェアを制御して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内で通知を発信上限に応じた数だけ送信する通知送信手段を有するとともに、送信された通知数が前記発信上限を超えたために送信できなかった旨を示す上限エラーを受信する上限エラー受信部と、受信した上限エラーに基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する発信上限算出部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムを提供する。

また例えば携帯電話キャリアなどの公開する発信上限を直接又は間接的に取得するなどして、その取得した発信上限をもとに請求書や領収書などの通知の送信に必要なＳＩＭ制御手段の数を算出する機能をさらに備える通知システムも提供する。具体的には、上記構成を備え、さらに前記携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数有する通知システムであって、前記携帯電話機能に係る携帯電話キャリアにて定められる所定の時間枠内での単一ＳＩＭ制御手段からの発信上限を取得する発信上限取得部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムも提供する。

また、上記のように必要なＳＩＭ制御手段の数が変わった場合に、各ＳＩＭ制御手段が担当する送信先の再割り当てを行う機能を備える通知システムも提供する。具体的には、上記構成を備え、さらに前記顧客に対する通知の送信先アドレスを管理する送信先アドレス管理部と、前記算出された一のＳＩＭ制御手段あたりの発信上限及び必要なＳＩＭ制御手段の数に応じて、送信先アドレス管理部に管理されている送信先アドレスのＳＩＭ制御手段への割り当てを決定するアドレス割当決定部と、を有する通知システムを提供する。

また、通知としては、上記のような請求書や領収書など料金支払に関する通知や、その料金支払いの変更に関する通知のほか、料金支払いとは無関係の例えば新サービスや新商品の広告などの通知も考えられる。そしてそのような場合でも、通知用ハードウェアとして携帯電話機能をＳＩＭ制御手段にて制御する場合、発信上限の変更に伴う必要ＳＩＭ制御手段数の変化という問題は同様に生じ得る。

そこで、顧客ＩＤとその料金の支払手段および領収書などの通知手段とを関連付けたマスタデータを保持、管理し、料金支払や支払手段の変更に係る通知を行う構成とは切り離して発信上限を把握して広告などの通知の送信に必要なＳＩＭ制御手段の数を算出する機能を備える通知システムも提供する。

具体的には、携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数利用して顧客に対して通知を行う通知システムであって、前記顧客以外の試験用の送信先アドレスである試験用アドレスを保持する試験用アドレス保持部と、前記携帯電話機能を有するハードウェアを制御して一以上の試験用アドレスに対して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内に送信数を順次増やしながら試験通知を実行する試験実行部と、前記送信数が前記発信上限を超えたために送信できなかった旨を示す上限エラー情報を受信する上限エラー情報受信部と、受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する発信上限算出部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムを提供する。

また、携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数利用して顧客に対して通知を行う通知システムであって、前記携帯電話機能を有するハードウェアを制御して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内で通知を発信上限に応じた数だけ送信する通知送信部と、送信された通知数が前記発信上限を超えたために送信できなかった旨を示す上限エラー情報を受信する上限エラー情報受信部と、受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する発信上限算出部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムも提供する。

また、携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数利用して顧客に対して通知を行う通知システムであって、前記携帯電話機能に係る携帯電話キャリアにて定められる所定の時間枠内での単一ＳＩＭ制御手段からの発信上限を取得する発信上限取得部と、通知必要数を保持する通知必要数保持部と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、を有する通知システムを提供する。

また上記構成に加えて、前記顧客に対する通知の送信先アドレスを管理する送信先アドレス管理部と、前記算出された一のＳＩＭ制御手段あたりの発信上限及び必要なＳＩＭ制御手段の数に応じて、送信先アドレス管理部に管理されている送信先アドレスのＳＩＭ制御手段への割り当てを決定するアドレス割当決定部と、を有する通知システムも提供する。

以上のような構成をとる本発明によって、サービスや商品などを利用、購入するための継続的な料金支払いに関して支払手段を変更した際には、その変更可否の通知を、例えば料金の請求書や領収書などの通知と同じ方法で行うことができる。したがって、顧客は領収書や請求書などと同じ感覚で支払手段の変更を知ることができ、その通知に気付かない等の事態も起こりにくくなる効果が期待できる。

また、その通知を携帯電話機能のＳＩＭ制御手段での制御によって実現する場合、一のＳＩＭ制御手段における発信上限を把握する構成を備えることで、当該発信上限が変更されても、全体で必要なＳＩＭ制御手段の数を算出し、きちんと請求書や領収書などの通知を顧客全体に送信することができる。

また、同様に一のＳＩＭ制御手段における発信上限を把握する構成を備えることで、当該発信上限が変更されても、全体で必要なＳＩＭ制御手段の数を算出し、請求書や領収書のほか、広告などの通知もきちんと顧客全体に送信することができる。

実施例１の通知システムによる料金の支払手段を変更した場合の通知の一例を説明するための概念図実施例１の通知システムにおける機能ブロックの一例を示す図実施例１の通知システムの第一顧客情報保持部で保持されている支払手段マスタデータの一例を表す図実施例１の通知システムの第二顧客情報保持部で保持されている通知手段マスタデータの一例を表す図実施例１の通知システムの料金支払手段ＩＤの変更を通信を介して受付けるためのＷｅｂページの一例を表す図実施例１の通知システムにおけるハードウェア構成の一例を示す図実施例１の通知システムにおける処理の流れの一例を示すフローチャート実施例２の通知システムにおける機能ブロックの一例を示す図実施例２の通知システムにおけるハードウェア構成の一例を示す図実施例２の通知システムにおける処理の流れの一例を示すフローチャート実施例３の通知システムにおける機能ブロックの一例を示す図実施例３の通知システムにおける処理の流れの一例を示すフローチャート実施例４の通知システムにおける機能ブロックの一例を示す図実施例４の通知システムにおける処理の流れの一例を示すフローチャート

以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。

なお、実施例２は、主に請求項１について説明する。また、実施例３は、主に請求項２について説明する。また、実施例４は、主に請求項３について説明する。

≪実施例１≫
<概要>
図１は、本実施例の通知システムによるサービスや商品を受けるための継続的に支払うことが必要な料金の支払手段を変更した場合の通知の一例を説明するための概念図である。なお、以下の記載では、本実施例の通知システムが電力会社サーバや銀行口座データベース、顧客ごとの通知手段を示すデータベースなど複数の装置の協働によって構成される例を挙げて説明する。

この図にあるように、例えば電力の利用料金をコンビニでの窓口支払いで行っていた顧客Ａが、銀行口座を開設したことを機に、銀行口座からの自動引き落としに変更しようと考えた。そこで、顧客Ａはインターネット接続端末を利用して電力提供サービス会社のホームページにアクセスし、所定の支払手段変更ページにて電力サービスの提供に際して自身に付与されたＩＤや銀行の口座番号などの情報を入力し、当該情報を電力サービス提供者の管理するサーバなどに送信する（１．支払手段の変更申請）。

すると電力会社サーバでは、銀行口座に関する与信情報などを管理するデータベースなどに対して口座番号などをキーとして問合せを行い、当該口座による自動引き落としが可能かを確認する（２．変更可否の問い合わせ）。

そして、この問い合わせに基づいて当該口座による自動引き落としが可能／不可能である、つまり支払手段の変更が可能／不可能であるとの判断結果が得られた場合、電力会社サーバでは、その結果を通知するための以下のような処理を行う。

例えばこのときまだ変更申請のためのアクセスが継続中であれば、そのアクセス中のホームページ上に当該結果を示すテキスト表示を行うなどすることで顧客にその旨を通知する（３．結果通知１）。

また、このとき変更申請のためのアクセスがすでに終了していれば、当該アクセスへのレスポンスとは別の方法で通知を行うためのハードウェア制御処理を実行する。あるいはアクセスが継続中であっても、正式な通知として、当該アクセスへのレスポンスとは別の方法で通知を行うためのハードウェア制御処理を実行しても良い。具体的には、電力管理会社が別途管理している、顧客ごとの請求書や領収書などの通知方法を示すマスタテーブルを含むデータベースを参照する（４．通知手段の特定）。

そして、例えば顧客Ａに対してはコンビニでの窓口支払に利用される請求書を「郵送」で通知している旨が特定されれば、その郵送のためのハードウェアである印刷装置などを制御する制御命令を出力する。あるいは顧客Ａに対しては請求書を「ＳＭＳ（ショート・メッセージ・サービス）」で通知している旨が特定されれば、そのＳＭＳ送信のためのハードウェアである携帯電話機能を有する通信装置を制御する制御命令を出力する（５．ハードウェアの制御）。

そして、そのハードウェアの制御によって、顧客Ａに対して請求書などと同様の通知手段にて、支払手段の変更可／不可に関する通知を行うことができる（６．結果通知２）、という具合である。

<機能的構成>
図２は、本実施例の通知システムにおける機能ブロックの一例を示す図である。なお、本実施例の「通知システム」は、連続あるいは断続を問わないが同一顧客から継続的に料金徴収が行われるモノ又はサービスの料金の徴収のための通知システムであって、そのサービスとしては、例えば電気、ガス、水道などの公共サービスや、電話利用やインターネット利用、塾やスポーツジムなどでのレッスンの受講、またモノとしては（定期購入される）雑誌や農作物、その他販売物などが挙げられる。また、その料金の徴収のための通知とは、例えば請求書や領収書、料金支払いの督促状などの通知が挙げられる。

そして以下に記載する本システムの機能ブロックは、ハードウェア及びソフトウェアの組み合わせとして実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵや主メモリ、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤやＤＶＤなどの記憶メディアとそれらメディアの読取ドライブなど）、情報入力に利用される入力デバイス、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、ユーザ・インターフェース用アプリケーションなどが挙げられる。そして主メモリ上に展開したプログラムに従ったＣＰＵの演算処理によって、入力デバイスやその他インターフェースなどから入力され、メモリやハードディスク上に保持されているデータなどが加工、蓄積されたり、上記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。あるいは本システムの機能ブロックは専用ハードウェアによって実現されてもよい。

また、本システムは、後述する各構成要件のすべてを含む一の物理装置によって実現されても良いし、複数の物理装置間での近距離／遠距離通信等を介した協働によって実現されても良い。また、物理装置が複数ある場合、各物理装置を管理するものは一の法人や自然人であっても良いし、まったく別の者によってそれぞれが管理、運用されていても良い。例えば、上記概要例におけるマスタデータの保持管理を行うサーバはサービス提供者（電力会社）が管理し、その支払や支払手段変更の通知に関するサーバや通知用ハードウェアなどの管理はシステムインテグレータ等が行う、という具合である。

また、本明細書に記載の各実施例はシステムとして実現できるのみでなく、方法としても実現可能である。また、このような装置の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を固定した記録媒体も、当然に本明細書に記載の各実施例の技術的な範囲に含まれる（本明細書の全体を通じて同様である）。

そして、この図２にあるように、本実施例の「通知システム」（０２００）は、「ハードウェア制御部」（０２０１）と、「第一顧客情報保持部」（０２０２）と、「第二顧客情報保持部」（０２０３）と、「支払手段保持部」（０２０４）と、「支払手段変更受付部」（０２０５）と、「可否取得部」（０２０６）と、「実行命令部」（０２０７）と、を有する。

「ハードウェア制御部」（０２０１）は、複数の通知手段を実行するためのハードウェアを制御する機能を有し、例えばＣＰＵや主メモリ、ハードウェア制御プログラムなどで実現することができる。

なお、通知手段での「通知」とは、前述の通り料金徴収が行われるモノ又はサービスの料金の徴収のための通知であって、例えば料金の請求や督促、領収に係る通知が挙げられる。また、そのような通知を行うための「通知手段」としては、例えばＳＭＳ（ショート・メッセージ・サービス）や電子メール、あるいはメールに類するその他の電子通信手段や、ホームページ上にユーザＩＤなどによるログインで表示されるユーザ別通知Ｗｅｂページを構成し、そのユーザ別通知Ｗｅｂページによる通知手段、あるいは、郵送や訪問員の直接訪問による通知などが挙げられる。

また、そのために制御されるハードウェアとしては通知手段に応じて様々であって良く、例えば通信手段がＳＭＳや電子メールなどであれば携帯電話機能またはインターネット接続機能を有する通信装置が挙げられ、通知手段がＷｅｂページであればＷｅｂサーバが挙げられる。また、通知手段が郵送であれば郵送物を印刷するための印刷装置が挙げられ、訪問員による直接訪問であれば、当該訪問員が情報の閲覧や提示に利用する携帯端末機器などが挙げられる。

なお、通知手段が少なくとも携帯電話機能で用いられる通信サービスとＷｅｂサービスとを含む場合、このハードウェア制御手段は、ハードウェアとして携帯電話機能を制御する「ＳＩＭ制御手段」を有していても良い。「ＳＩＭ制御手段」とは、ＳＩＭ（サブスクライバー・アイデンティファイ・モジュール）カードを利用してハードウェアを制御する手段であって、これによってＳＩＭカードで携帯電話キャリアの提供するＳＭＳやメールなどの各種通信サービスや携帯電話用サイトなどのＷｅｂサービスによる通知を行うことができる。
なおＳＩＭ制御手段は、1枚のＳＩＭカードを利用してハードウェアを制御する構成であっても良いし、複数のＳＩＭカードを利用して、それぞれのＳＩＭカードで複数のハードウェアを制御する構成であっても良い。また後者の構成である場合は、そのＳＩＭカードの枚数が把握できるように構成されていると良い。

そしてハードウェア制御部では、上記のような各種ハードウェアを制御することで、顧客に対して請求書や領収書のようなモノ又はサービスの料金の徴収のための通知を行う。

「第一顧客情報保持部」（０２０２）は、顧客ＩＤと料金支払手段ＩＤとを関連付けた情報である第一顧客情報を保持する機能を有し、例えばフラッシュメモリやＨＤＤ、その他の記憶装置で実現することができる。

図３は、この第一顧客情報保持部で保持されている、顧客ＩＤと料金支払手段ＩＤとが関連付けられた支払手段マスタデータ（第一顧客情報）の一例を表す図である。この図にあるように、例えば顧客ＩＤ：Ｕ００１で識別される顧客Ａは、例えば電力料金の支払手段としてコンビニでの窓口支払が関連付けられて管理されており、また顧客ＩＤ：Ｕ００２で識別される顧客Ｂは、例えば電力料金の支払手段として銀行口座からの自動引き落としによる支払が関連付けられて管理されている、という具合である。また第一顧客情報保持部では、図に示すように顧客ＩＤと支払手段とを１対１で関連付けて保持する形態であっても良いし、例えば銀行口座の残高が十分でない場合に利用される第二の支払手段を「窓口支払」とする、という具合に選択条件や優先順位を設定するなどして一の顧客ＩＤに複数の支払手段が関連付けて保持されていても良い。

そして、このような支払手段マスタデータを参照することで、前述のハードウェア制御部では、ハードウェア制御による料金徴収に係る各種通知に関して、例えば顧客Ａには窓口での支払のための請求を通知する必要があることや、その請求通知に窓口での支払いをスムーズにするための請求ＩＤや請求金額を示す二次元コードを添付したほうが良いこと、また顧客Ｂに対しては自動引き落としであるため残高が十分である限り請求通知をする必要はなく、自動引き落としの領収に係る通知のみすれば良いことなどを把握して好適な形で当該通知を実行することができる。

「第二顧客情報保持部」（０２０３）は、顧客ＩＤとその顧客に対する請求又は／及び領収などに関する通知をするための通知手段とを関連付けた情報である第二顧客情報を保持する機能を有し、例えばフラッシュメモリやＨＤＤ、その他の記憶装置で実現することができる。

図４は、この第二顧客情報保持部で保持されている、顧客ＩＤと通知手段とが関連付けられた通知手段マスタデータ（第二顧客情報）の一例を表す図である。なお、本例では図３で示す支払手段マスタデータとこの通知手段マスタデータを別個のテーブルデータとし、例えば顧客ＩＤを主キーとするリレーショナルデータベースとして運用する例を挙げているがもちろんそれに限定されるものではなく、上記２つのマスタデータを統合し、顧客ＩＤに支払手段と通知手段を関連付けたテーブルデータとしても良い。

そして、この図４に示すように、例えば顧客ＩＤ：Ｕ００１で識別される顧客Ａは、例えば請求や領収に係る通知の通知手段として「ＳＭＳ」が関連付けられており、またそのＳＭＳの宛先アドレス「０９０ｘｘｘｘｘｘｘｘ」も関連付けられている。また顧客ＩＤ：Ｕ００２で識別される顧客Ｂは、例えば領収に係る通知の通知手段として「Ｗｅｂサービス（ユーザ別通知Ｗｅｂページ）」が関連付けられており、また、そのＷｅｂページにアクセスするためのユーザＩＤやパスワードなども関連付けて管理されている、という具合である。

そして、このような第二顧客情報を示す通知手段マスタデータと、図３のような第一顧客情報を示す支払手段マスタデータを参照して、例えば、顧客Ａはコンビニ窓口支払いであるので、窓口支払用の二次元コード付きの請求通知をＳＭＳで送信し、一方で顧客Ｂは銀行口座からの自動引き落としによる支払であるので、領収金額など領収した旨を示す情報を掲載するＷｅｂページを生成するといった処理を行うことができる。

なお、この第二顧客情報保持部に保持されている前記通知手段は、上記例のように少なくとも携帯電話機能で用いられる通信サービス（ＳＭＳなど）とＷｅｂサービスのいずれかを含むよう構成しても良い。また、その場合には、後述するハードウェアとして携帯電話機能を制御するＳＩＭ制御手段を有するように構成すると良い。なお、携帯電話機能で用いられる通信サービスとしては、ＳＭＳのほかに、例えば電子メールや各種アプリケーションソフトウェア内機能として提供されるメールに類するサービス、音声メッセージ送信サービスなどが挙げられる。

また、通知手段は、上記のような携帯電話機能で用いられる通信サービスやＷｅｂサービスによる通知以外のものであっても良い。例えば図４に示すように、顧客Ｃに対する通知方法として、「郵送」による通知が関連付けられ、顧客Ｄに対する通知方法として「訪問員による直接訪問」が関連付けられている、という具合である。

「支払手段保持部」（０２０４）は、顧客選択可能な料金支払手段ＩＤを保持する機能を有し、例えばフラッシュメモリやＨＤＤ、その他の記憶装置で実現することができる。ここで保持される料金支払手段ＩＤとしては、例えば、銀行引落、クレジット支払、窓口支払、広域的通信網又はその他の閉鎖的通信網に構築される電子決済システムでの支払い、あるいはその他の支払いなどが挙げられる。なお、広域的通信網とはＷＡＮ（ワイド・エリア・ネットワーク）網／インターネット網などが挙げられ、閉鎖的通信網とは銀行間通信網や携帯電話のキャリア網などが挙げられる。

そして、ここで保持されている上記のような各種料金支払手段ＩＤを顧客に提示し、その中から顧客に所望の料金支払手段ＩＤを選択させる、という具合である。

「支払手段変更受付部」（０２０５）は、支払手段保持部に保持されている料金支払手段ＩＤの中から選択することで、顧客ＩＤと関連付けて第一顧客情報保持部に保持されている料金支払手段ＩＤの変更を、通信を介して受付ける機能を有し、例えばＣＰＵや主メモリ、通信回路や顧客側の入力端末、支払手段変更受付プログラムなどで実現することができる。

図５は、この料金支払手段ＩＤの変更を通信を介して受付けるためのＷｅｂページの一例を表す図である。例えば、顧客Ａが、今まで電気料金をコンビニの窓口支払いで支払っていたのを銀行口座からの自動引き落として変更しようと考え、携帯端末などを利用して当該電気会社のホームページにアクセスする。そして当該ホームページ内のリンクをたどり、料金支払手段ＩＤの変更申請ページにアクセスすると、図５に示す画面が顧客Ａの携帯端末上に表示される。

そして顧客Ａは、この画面表示にそって、例えば前述の支払手段保持部に保持されている各種支払手段をプルダウンメニューなどで選択可能に構成された入力欄から「銀行引落」を選択し、さらに以前通知された請求書などに記載されている自身のＩＤや、変更によって利用されることになる銀行口座の口座番号などの各種必要情報を入力する。また、このとき通知手段の変更入力欄を設け、通知手段の変更申請も合わせて受付ける構成としても良い。

そして画面上の確認ボタンや送信ボタンがユーザ操作にてクリックされることによって、本実施例の支払手段変更受付部はこれら画面内に入力された情報を受け付ける、という具合である。

「可否取得部」（０２０６）は、実行可否情報を取得する機能を有し、例えばＣＰＵや主メモリ、通信回路、可否取得プログラムなどで実現することができる。「実行可否情報」とは、受付けた料金支払手段が実行可能かを示す情報をいい、例えば変更希望対象の支払手段に関して顧客の契約情報などを保持するデータベースなどに問合せを送信し、その返信結果として取得された情報などをいう。また実行可否情報としては、変更希望対象の料金支払手段ＩＤが実行可能か否かを示す情報そのものでも良いし、その可否を判断するための情報であっても良い。

具体的には、変更支払手段が「銀行引落」であれば、銀行口座の与信情報などを管理するデータベースなどに対して入力された口座番号で示される口座が実際にあるか、あるいはその口座の残高はいくらか／十分か等の問い合わせを行い、その返信として十分な残高の口座がある旨を示す情報や、口座が無い／残高が十分ではない等を示す情報、与信に関する情報、あるいはそれら情報を元に判断される銀行引落の実行可否を示す情報などを実行可否情報として取得する。

あるいは変更支払手段が「クレジット支払」であれば、例えば入力されたクレジットカードＩＤなどの情報をキーとしてクレジット契約に関する情報を管理するデータベースなどに問い合わせを行い、そのユーザが確かに当該クレジット事業者と契約しているか否かを示す情報、与信に関する情報、あるいはそれら情報を元に判断されるクレジット支払の実行可否を示す情報などを実行可否情報として取得する。

また変更支払手段が「窓口支払」であれば、基本的にはすべて「変更可である」旨を示す実行可否情報を取得する構成としても良いし、例えば顧客の住所情報を入力させ、当該住所近辺に窓口支払い可能な店舗があるか否かを示す情報やその判断に利用する情報などを実行可否情報として取得しても良い。

また変更支払情報が「その他の各種電子決済」であれば、当該電子決済サービスを提供するサービス会社のデータベースなどに対して、入力されたサービスＩＤや顧客名などをキーとしてサービス利用に係る契約がなされているか等を問い合わせたり、当該電子決済で利用される銀行口座／クレジット契約があるか否かの問い合わせを銀行口座やクレジット契約に関する情報を管理するデータベースなどに行ったりして、その返信を実行可否情報として取得するという具合である。

なお、上記は一例であって、その問い合わせ先や問い合わせ方法、返信として得られる実行可否情報の内容などについては特に限定せず、料金支払手段に応じて各種のやり方で実現されると良い。

そして、このようにして取得した実行可否情報を利用して判断される支払手段の変更可否結果を、本実施例の通知システムでは以下のように料金支払いの請求や領収に係る通知手段と同じ手段で通知することもできることを特徴とする。

「実行命令部」（０２０７）は、可否取得部で取得した実行可否情報に基づいた変更可能、変更完了又は変更不可を示す顧客への通知を前記通信中に取得した場合にはその通信を介して顧客に対して行い、顧客への通知を前記通信中に取得しない場合又は／及び前記通信中に取得した場合には第二顧客情報保持部に保持された通知手段を用いて通知するための処理をハードウェア制御部に対して実行させる機能を有し、例えばＣＰＵや主メモリ、実行命令プログラムなどで実現することができる。

具体的に、顧客の端末が、支払手段の変更のために例えば変更申請用Ｗｅｂページなどにアクセスしたままの状態で、上記変更可能や完了／不可を示す判断結果が得られた場合、その得られた変更可否などの結果を、当該アクセスへのレスポンスとして顧客に通知する。すると顧客端末の画面上では、Ｗｅｂページ遷移やポップアップ表示などが実行され、それによって顧客は変更可否結果を知ることができる、という具合である。

また、上記変更可能や完了／不可を示す判断結果が得られたタイミングで、すでに変更申請用Ｗｅｂページなどへのアクセスが切断されている場合には、上記のようなアクセスへのレスポンスによる通知ができないため別の方法で顧客への通知を行っても良い。あるいは変更申請用Ｗｅｂページなどへのアクセス中であっても、正式な変更可否結果の通知などとして当該アクセスへのレスポンス以外の方法で顧客への通知を行っても良い。

具体的には、図４に示すような通知手段マスタデータ（顧客ＩＤと通知手段とを関連付けた第二顧客情報）を参照し、顧客ＩＤをキーとして関連付けられている通知手段、すなわち当該顧客に対して料金支払いに係る請求や領収の通知を行う際の通知手段を特定する。そして、その特定した請求や領収に関する通知と同じ手段で通知を行わせるようなハードウェア制御が実行されるようにハードウェア制御部に対する実行命令を出力する、という具合である。

例えば、特定された通知手段がＳＭＳや電子メールなどであれば、携帯電話機能やインターネット通信機能を備える各種通信装置をハードウェアとして、請求や領収に係る定型文や顧客の料金徴収に係る情報などを元にメッセージ本文を生成し、さらに通信手段マスタデータで管理されている宛先に対して生成したメッセージを本文とするＳＭＳや電子メールの送信処理が通信装置にて行われるような制御が実行されるよう、ハードウェア制御部に対する実行命令を出力する。

また、通知手段がＷｅｂページへの掲載であれば、Ｗｅｂサーバをハードウェアとして、顧客の料金徴収に係る情報などを元に当該顧客用の通知用Ｗｅｂページ等の生成やログイン管理などがＷｅｂサーバにて行われるような制御が実行されるよう、ハードウェア制御部に対する実行命令を出力する。

また通知手段が郵送であれば、印刷装置をハードウェアとして、請求や領収に係る定型文や顧客の料金徴収に係る情報などを元に生成したメッセージ本文と、当該顧客の住所や氏名を示す宛先ラベルなどを示す情報が印刷装置に送信され、当該印刷装置にてこれら情報に基づくバッチ印刷が可能となるような制御が実行されるよう、ハードウェア制御部に対する実行命令を出力する。あるいは、郵送担当者の端末装置をハードウェアとして、当該端末に送信した情報をもとに郵送を行う旨の指示が端末装置上で出力されるような制御が実行されるよう、ハードウェア制御部に対する実行命令を出力する。

また、通知手段が訪問員による直接訪問での通知であれば、ハードウェアを当該訪問員が情報の閲覧や提示に利用する携帯端末機器として、顧客の料金徴収に係る明細などの情報や当該顧客の住所や氏名が訪問員の携帯端末機器にて取得、表示されるような制御が実行されるよう、ハードウェア制御部に対する実行命令を出力する。

このように顧客から料金支払手段の変更を受付けた場合に、その変更可否の通知を料金の請求書や領収書などの通知と同じ方法となるように実行することができる。

また上記通知とともに、本実施例の通知システムでは、料金支払手段の変更可否の判断結果が変更可である場合には、支払手段マスタデータ（顧客ＩＤと料金支払手段ＩＤとを関連付けた第一顧客情報）にて当該顧客ＩＤと関連付けられている料金支払手段ＩＤを変更する処理を行う。

<ハードウェア構成>
図６は、上記機能的な各構成要件をハードウェアとして実現した際の、通知システムにおける構成の一例を表す概略図である。この図を利用して顧客より受付けた支払手段の変更可否結果の通知処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、通知システムは、演算処理を実行するための「ＣＰＵ」（０６０１）と、「主メモリ」（０６０２）と、を備えている。また各種情報やプログラムを保持する「ＨＤＤ」（０６０３）や、「通信回路」（０６０４）、通知用のハードウェアを制御するための「ＳＩＭカード」（０６０５）、「Ｉ／Ｏ（インプット／アウトプット）回路」（０６０６）などを備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

また、「主メモリ」にはハードウェア制御プログラムや支払手段変更受付プログラム、可否取得プログラム、実行命令プログラムなどの各プログラムが適宜読み出され、「ＣＰＵ」は読み出された当該プログラムを参照し、プログラムで示される手順に従い各種演算処理を実行し、また上記各ハードウェア構成に対する制御命令を出力する。また、この「主メモリ」や「ＨＤＤ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」の演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。

なお、ここで説明する通知システムに関しては、各ハードウェア構成や各プログラムは一のサーバ装置に含まれるものであっても良いし、複数のサーバ装置やその他装置に分散／複数配置され、それらの協働処理によって実現されても良いし、またそれら各装置の管理者も複数であっても良い。

まず、例えば電力会社などサービスや商品の提供者が利用するデータベースとして、顧客ＩＤと当該顧客の料金支払手段ＩＤを関連付けた第一顧客情報と、また当該顧客に対する通知を行うための通知手段などを関連付けた第二顧客情報とを含む顧客別のマスタデータが「ＨＤＤ」に登録される。また、銀行引落やクレジット支払、窓口支払、通信網に構築される電子決済システムでの支払などのうち、当該サービス提供者が料金の料金支払手段として認めている方法（すなわち支払が可能な方法）についても、そのＩＤが同様に「ＨＤＤ」に登録される。なお、これら情報の登録は、例えばオペレータ入力による登録や、外部のサーバ装置から通信などを介して取得することによる登録など様々な形態が挙げられる。

そして、例えばサービスの料金徴収用の請求書などを送付するよう予め定められた日になったことを、現在日時情報をもとにした「ＣＰＵ」の演算処理によって判断すると、「ＣＰＵ」はハードウェア制御プログラムを解釈し、それにしたがって上記マスタデータの第一顧客情報を参照して顧客ごとの料金支払手段ＩＤを特定する。そして、特定した料金支払手段ＩＤに応じて請求書などを生成し、生成した請求書などを顧客に対して通知するためのハードウェア制御処理を実行する。

具体的には、まず請求書の通知であれば請求ＩＤや顧客の支払うべき料金などを含む利用明細情報を取得する。また料金支払手段ＩＤで「窓口支払」が示されていれば、窓口での支払いをスムーズなものとするために、「ＣＰＵ」は請求ＩＤや支払料金などを二次元バーコード化した画像情報を生成しても良い。また料金支払手段ＩＤで「銀行引落」が示されていれば、自動引き落としであるため請求書の通知は必要ないとして請求書通知に係るハードウェア制御処理を実行しない構成としても良い。
つづいて「ＣＰＵ」は「ＨＤＤ」に保持されているマスタデータの第二顧客情報を参照し、当該顧客への通知手段を特定する。そして例えば通知手段がＳＭＳであれば、携帯電話機能を備える「通信装置」に対して請求書などをＳＭＳで送信するよう制御するための制御命令を、「ＳＩＭカード」を利用して「Ｉ／Ｏ回路」などから出力する。なお上記取得した利用明細情報や二次元バーコードの画像情報は制御命令に含まれる形で通信装置に出力される構成としても良いし、制御命令とは別に「Ｉ／Ｏ回路」などから通信装置に出力される構成としても良い。また、特定した通知手段に関連付けられている送信先アドレスなどの情報も、制御命令に含めて、あるいは別途通信装置に対して「ＳＩＭカード」を利用して「Ｉ／Ｏ回路」などから出力する。

そして「通信装置」では、ＳＩＭカードを利用した制御命令に応じて、前記取得した請求ＩＤや利用明細情報、また窓口支払いであれば二次元バーコード画像などを利用して請求書データを生成し、その生成した請求書データを、取得した送信先アドレスを宛先とするＳＭＳによって通知する、という具合である。

また、さらに例えば電力会社などサービスや商品の提供者が用意するＷｅｂページに顧客の携帯端末などからアクセスがあると、「ＣＰＵ」は支払手段変更受付プログラムを解釈し、それにしたがって顧客の端末上に料金の支払手段の変更申請用のＷｅｂページ画面を表示する。なお、この変更申請用Ｗｅｂページ画面において顧客に対して提示される選択候補の支払手段の一覧やプルダウンメニューなどは、図に示す「ＨＤＤ」に登録保持されている料金支払手段ＩＤをもとに生成される。そして、当該申請画面に入力された料金支払いの変更申請に係る情報（顧客ＩＤや変更対象の料金支払手段ＩＤなど）が「通信回路」を介して通知システムに受付けられ、「主メモリ」に格納される。

すると、「ＣＰＵ」は可否取得プログラムを解釈し、その解釈結果にしたがって「通信回路」から所定の外部データベースなどに対して変更申請において受付けた料金支払手段が実行可能か否かの問い合わせを出力する。例えば、変更対象の料金支払手段が「銀行口座の自動引落」であれば、銀行口座に関する与信情報などを管理しているデータベースなどに対して、変更申請に係る情報に含まれる口座番号などをキーとする問い合わせを出力する。そして問い合わせに対するレスポンスとして「通信回路」を介して受信した該当口座の有無情報や該当口座の残高情報、与信情報などを実行可否情報として「主メモリ」に格納する。

そして、その実行可否情報が、例えば「該当口座が有」で「残高が閾値以上」などの所定の条件を満たしているか否かを「ＣＰＵ」の演算処理によって判断し、実行可否情報が当該条件を満たしていれば料金支払手段の変更は可であるとの判断結果を出力し、当該条件を満たしていなければ変更不可であるとの判断結果を出力する。

つづいて「ＣＰＵ」は実行命令プログラムを解釈し、それにしたがって上記変更可／不可などの判断結果を顧客に通知するために、まず顧客の端末がＷｅｂページにまだアクセスしたままであるか否かを、例えばセッション情報などを参照して判断し、アクセスしたままであれば当該アクセスへのレスポンスとして例えばページ遷移やポップアップ表示でその変更可否結果を表示するための情報を顧客端末に返信する。なお、ここで返信される情報は変更可否の判断結果のみならず、変更可との判断結果に応じて実際に変更が完了したことを示す情報であっても良い。

すると顧客端末では当該変更可否や変更完了などの変更申請に対する結果情報が画面上に表示され、顧客は申請した料金支払手段の変更が許可されたか否かを知ることができる。

また、この通知システムでは、上記変更申請のためのＷｅｂアクセスへのレスポンスによる当該変更可否結果の通知が実行されたか否かに関わらず、あるいは上記通知ができなかった旨を示す情報の受領に応じて、変更可否判断結果やそれにともなう変更完了などの通知を、当該顧客に対する料金徴収の請求や領収に係る通知と同じ通知手段で通知するために、以下の処理を行う。

すなわち「ＣＰＵ」はハードウェア制御プログラムを解釈し、その解釈結果にしたがって「ＨＤＤ」に保持されているマスタデータの第二顧客情報を参照し、通知相手となる顧客ＩＤをキーとしてそれに関連付けられている通知手段を特定する。そして特定された通知手段がＳＭＳや電子メールなどであれば、「ＣＰＵ」は請求や領収に係る定型文や顧客の料金徴収に係る情報などを元にメッセージ本文を生成する処理を実行する。
そして特定された通知手段に関連付けられている送信先アドレスを宛先として、生成したメッセージを本文とするＳＭＳや電子メールの送信処理を行うよう制御するための制御命令を「ＳＩＭカード」を利用して「Ｉ／Ｏ回路」から通信装置に出力する。なお前述の請求書などの通知と同様に、メッセージ本文等の情報は制御命令に含まれる形で通信装置に出力される構成としても良いし、制御命令とは別に「Ｉ／Ｏ回路」などから通信装置に出力される構成としても良い。
また、もちろん、通知手段に応じて制御するハードウェアが「ＳＩＭカード」を利用しないものであれば、「Ｉ／Ｏ回路」などから直接制御命令をハードウェアに対して出力しても良い。

そして携帯電話機能などを備える通信装置では、この制御命令に従って携帯電話網などを介してＳＭＳを顧客端末に対して送信し、そのＳＭＳが顧客端末上で表示されることで、顧客はその料金支払手段の変更可否結果を料金支払いの請求や領収と同じ通知手段によって知ることができる、という具合である。

また変更可否結果などが変更可や変更完了である場合には、「ＣＰＵ」は図示しない第二顧客情報変更プログラムの解釈結果にしたがって、前記当該顧客ＩＤと関連付けて「ＨＤＤ」のマスタデータに登録されている料金支払手段ＩＤの項目を更新変更／新規登録する処理を行う。

<処理の流れ>
図７は、本実施例の通知システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、上記のような計算機の各ハードウェア構成によって実行されるステップであっても良いし、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、顧客ＩＤと料金支払手段ＩＤとを関連付けて保持するため第一顧客情報保持部に記録し（第一顧客情報保持ステップＳ０７０１）、また、顧客ＩＤとその顧客に対する請求又は／及び領収などに関する通知をするための通知手段とを関連付けて保持するため第二顧客情報保持部に記録する（第二顧客情報保持ステップＳ０７０２）。もちろん、上記第一顧客情報保持部と第二顧客情報保持部は同一の保持部として、顧客ＩＤと料金支払手段ＩＤ、そして請求や領収などに係る通知手段とが関連付けて記録されても良い。

また、銀行引落、クレジット支払、窓口支払、広域的通信網又はその他の閉鎖的通信網に構築される電子決済システムでの支払い、あるいはその他の支払いなどの顧客選択可能な料金支払手段ＩＤを保持するため支払手段保持部に記録する（支払手段保持ステップＳ０７０３）。

そして、料金支払いに関する請求や領収の通知を行う場合には、上記第二顧客情報保持部に保持されている当該顧客ＩＤと関連付けられた通知手段にて通知を行うよう、例えば携帯電話機能を有する通信装置などのハードウェアを制御する（ハードウェア制御ステップ１Ｓ０７０４）。

また、例えばサービス提供者のホームページ内にある料金支払手段の変更申請用Ｗｅｂページなどを利用して、前記支払手段保持部に保持されている料金支払手段ＩＤの中から選択することで、顧客ＩＤと関連付けて第一顧客情報保持部に保持されている料金支払手段ＩＤの変更を通信を介して受け付ける（支払手段変更受付ステップＳ０７０５）と、例えば外部の銀行サーバやクレジット会社サーバなどに問い合わせることで、受付けた料金支払手段が実行可能かを示す実行可否情報を取得する（可否取得ステップＳ０７０６）。

そして前記ステップＳ０７０６で取得した実行可否情報に基づいた変更可能、変更完了又は変更不可を示す顧客への通知を取得し（通知取得ステップＳ０７０７）、そして前記ステップＳ０７０５の支払手段変更に係る通信がまだ継続されていれば、その取得した通知内容での通知を、当該通信を介して顧客に対して実行する（通信通知実行ステップＳ０７０８）。

また、前記ステップＳ０７０８での通信を介した通知が実行される／されないに関わらず、第二顧客情報保持部に保持された通知手段を用いて前記変更可否などの通知を行うための処理を例えば携帯電話機能を有する通信装置などのハードウェアに対して実行させるため、前記ハードウェア制御ステップＳ０７０４に対して実行命令を出力（実行命令ステップＳ０７０９）しても良い。

<効果の簡単な説明>
以上のような本実施例の通知システムによって、顧客はサービスや商品などを利用、購入するための継続的な料金支払いに関して支払手段を変更した際には、その変更可否などの通知を、例えば料金の請求書や領収書などの通知と同じ方法で受け取ることができる。

したがって、顧客は領収書や請求書などと同じ感覚で支払手段の変更を知ることができ、その通知に気付かない等の事態も起こりにくくなる効果が期待できる。

≪実施例２≫
<概要>
通知システムにおいて携帯電話機能をＳＩＭ制御手段で制御することで通知を行うにあたり、必要なＳＩＭ制御手段の数が変わる可能性がある。何故ならば、前述の通り、例えばスパムメール防止などの観点から携帯電話キャリアによる一日当たりの送信数の上限規制（発信上限）が定められているが、何らかの事情でこの発信上限が変更されると、一のＳＩＭ制御手段で送信できる通知数も変わり、それに応じて必要となるＳＩＭ制御手段の数も変わってくるからである。

そこで、本実施例の通知システムでは、その発信上限を正確に把握するために試験的に通知を順次送信し、その試験通知に対する上限エラーから把握した発信上限に基づいて請求書や領収書などの通知を送信する際に必要なＳＩＭ制御手段の数を算出する機能をさらに備えることを特徴とする。
なおＳＩＭ制御手段は、前述の通り1枚のＳＩＭカードを利用してハードウェアを制御する構成であっても良いし、複数のＳＩＭカードを利用し、かつその枚数を把握可能として、それぞれのＳＩＭカードで複数のハードウェアを制御する構成であっても良い。以下の例ではＳＩＭ制御手段が1枚のＳＩＭカードを利用する例を挙げて説明する。

<機能的構成>
図８は、本実施例の通知システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「通知システム」（０８００）は、「試験用アドレス保持部」（０８０１）と、「試験実行部」（０８０２）と、「上限エラー情報受信部」（０８０３）と、「発信上限算出部」（０８０４）と、「通知必要数保持部」（０８０５）と、「ＳＩＭ制御手段必要数算出部」（０８０６）と、を有する。

なお本実施例の通知システムは、上記実施例１の通知システムの一部として、上記実施例１で説明した構成要件に加えて上記の各構成要件を有し、それら追加された構成要件によって算出された必要数分だけ実施例１の通知システムのハードウェア制御部の有するＳＩＭ制御手段を用意しハードウェア制御を行うことで、料金支払いに関する請求や領収の通知を行うものであっても良い。あるいは実施例１とは別の、複数のＳＩＭ制御手段を利用して各種の通知を行う通知システムとして、上記各構成要件によって算出された必要数分だけＳＩＭ制御手段を用意し、広告や勧誘などをはじめとする通知を行うものであっても良い。

「試験用アドレス保持部」（０８０１）は、試験用アドレスを保持する機能を有し、例えばフラッシュメモリやＨＤＤ、その他の記憶装置によって実現することができる。「試験用アドレス」とは、顧客以外の試験用の送信先アドレスをいい、顧客以外の者に利用される受信側リソースに割り当てられるアドレスである。例えば本通知システムの管理者と携帯キャリアやＩＳＰ（インターネットサービスプロバイダー）との間の契約によって得られるアドレスを試験専用のアドレスとして利用する構成などが挙げられる。

「試験実行部」（０８０２）は、携帯電話機能を有するハードウェアを制御して複数の試験用アドレスに対して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内に送信数を順次増やしながら試験通知を実行する機能を有し、例えばＣＰＵや主メモリ、通信回路、試験実行プログラムなどによって実現することができる。

具体的には、単一ＳＩＭ制御手段（例えば一の契約ＳＩＭカードやそれに類する契約記憶媒体）ごとの所定時間枠あたりに送信できる通知数（発信上限）が、ある携帯電話キャリアＡでは「１日あたり５００通」と規定されている。するとこの試験実行部では、1日の間に、携帯電話機能で提供されるＳＭＳなどの通知手段によって、試験用アドレスに対して1通ずつ通知を行う処理を実行する、という具合である。また、その通知数をカウントする処理も合わせて実行する。

そして、例えば上記発信上限に変更が無く１日あたり５００通のままであれば、５０１通目を送信した際に、後述する上限エラー情報を受信することになる。一方、発信上限に変更があれば、その変更された発信上限（例えば１日あたり７００通）に応じて７０１通目の試験通知に対する上限エラー情報を受信することになり、それによって変更された発信上限を把握することができる。

「上限エラー情報受信部」（０８０３）は、上限エラー情報を受信する機能を有し、例えばＣＰＵや主メモリ、通信回路、上限エラー情報受信プログラムなどで実現することができる。「上限エラー情報」とは、前記試験実行部での試験通知の送信数が前記発信上限を超えたために送信できなかった旨を示す情報をいい、例えば携帯電話キャリアのメールサーバが、発信上限を超えて送信された試験通知に対する応答として送信するエラー通知が挙げられる。また、試験用アドレス宛ての通知を実際に受信する通信端末にてカウントされた試験通知の受信数を上限エラー情報として、当該通信端末から受信する構成としても良い。

「発信上限算出部」（０８０４）は、受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する機能を有し、例えばＣＰＵや主メモリ、発信上限算出プログラムなどによって実現することができる。具体的には、例えば、試験通知数をカウントした結果、７０１通目の試験通知を送信したレスポンスとして上限エラー通知を受信すれば、所定の時間枠での一のＳＩＭ制御手段あたりの発信上限は７００通であると算出することができる。また、試験通知の受信側端末での受信数が７００通であっても、やはり同様に所定の時間枠での１のＳＩＭ制御手段あたりの発信上限は７００通であると算出することができる。

なお、後述する稼働すべきＳＩＭ制御手段の数の算出にあたっては、この算出された発信上限の数値をそのまま用いても良いし、マージンを持たせて算出した発信上限から例えば「２」などのマージン値を減算した値を用いても良い。

「通知必要数保持部」（０８０５）は、通知必要数を保持する機能を有し、例えばフラッシュメモリやＨＤＤ、その他記憶装置によって実現することができる。「通知必要数」とは通知を送信すべき数をいい、例えばサービス提供／商品販売契約などで明らかな顧客の数や、その中で当該携帯電話機能による通知を希望する顧客の数、あるいは顧客でなくとも見込みや売り込みのための通知の対象として特定される顧客候補の数などが挙げられる。

「ＳＩＭ制御手段必要数算出部」（０８０６）は、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出する機能を有し、例えばＣＰＵや主メモリ、ＳＩＭ制御手段必要数算出プログラムなどによって実現することができる。

具体的に、例えば発信上限として「７００通」を算出し、マージンを「２」として、一のＳＩＭ制御手段にて１日に送信する通知数を「６９８通」とする。そして、例えば通知必要数が「２０００００通」であれば、稼働すべきＳＩＭ制御手段の数は２０００００から６９８を除して「２８７枚」であることが算出される、という具合である。

そして、例えば今までの発信上限が「５００通」であり、マージン込みの１つのＳＩＭ制御手段からの１日当たりの送信数を「４９８通」とした場合に稼働しているＳＩＭ制御手段の数が「４０２枚」であれば、余剰の「１１５枚」について非稼動状態としたり、その一部／全部について携帯電話キャリアとの契約を解除したりすると良い。

また逆に発信上限が今までよりも少ない数値に変更されれば、当然稼働すべきＳＩＭ制御手段の数は増えるので、その分非稼動状態としていたＳＩＭ制御手段を稼働状態に復帰させたり、新たに携帯電話キャリアとの契約を結んだりして、利用できるＳＩＭ制御手段の数を増やすようにすると良い。

このようにＳＩＭ制御手段の必要数を適宜算出することによって、携帯電話キャリアによって発信上限が変更されても、少なくとも発信上限によるエラーなく実際の通知を顧客に送信するための手続などをすぐにとることができる。

なお前述の通り、本実施例における通知は、例えば上記実施例１の通知システムで管理されている顧客ごとの料金支払手段などに応じた料金の請求や領収の通知であっても良いし、実施例１とは別の通知システムとして、料金の請求や領収の通知のほか、広告や勧誘などをはじめとするその他の通知であっても良い。

また、上記のように発信上限の変更によって稼働すべきＳＩＭ制御手段の数が変わった場合には、１のＳＩＭ制御手段が担当する実際の顧客への通知の割り当てを再度実行する機能をさらに備えるよう構成しても良い。

具体的には、本実施例の通知システムは、例えば前記顧客に対する通知の送信先アドレスを管理する送信先アドレス管理部と、前記算出された一のＳＩＭ制御手段あたりの発信上限及び必要なＳＩＭ制御手段の数に応じて、送信先アドレス管理部に管理されている送信先アドレスのＳＩＭ制御手段への割り当てを決定するアドレス割当決定部と、を有するよう構成しても良い。

例えば、稼働すべきＳＩＭ制御手段の数が２８７枚であり、今まで稼働していたＳＩＭ制御手段１１５枚を非稼動とする場合、その非稼動となる１１５枚に割り当てられていた実際の顧客の送信先アドレスを、前記２８７枚のＳＩＭ制御手段に対して２０ずつ割り当てる、という具合である。あるいは、１のＳＩＭ制御手段あたりの発信上限が減った場合には、新たに稼働するＳＩＭ制御手段に対して、すでに稼働中のＳＩＭ制御手段に割り当てられていた送信先アドレスの一部を割り当てるようにする、という具合である。

<ハードウェア構成>
図９は、上記機能的な各構成要件をハードウェアとして実現した際の、通信システムにおける構成の一例を表す概略図である。この図を利用して稼働すべきＳＩＭ制御手段の数の算出処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、通信システムは、演算処理を実行するための「ＣＰＵ」（０９０１）と、「主メモリ」（０９０２）と、を備えている。また各種情報やプログラムを保持する「ＨＤＤ」（０９０３）や、「通信回路」（０９０４）、通知用のハードウェアを制御するための「ＳＩＭカード」（０９０５）、「Ｉ／Ｏ回路」（０９０６）などを備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

また、「主メモリ」には試験実行プログラムや上限エラー受信プログラム、発信上限算出プログラム、ＳＩＭ制御手段必要数算出プログラムなどの各プログラムが適宜読み出され、「ＣＰＵ」は読み出された当該プログラムを参照し、プログラムで示される手順に従い各種演算処理を実行し、また上記の各ハードウェア構成を制御するための制御命令を出力する。また、この「主メモリ」や「ＨＤＤ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」の演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。

なお、ここで説明する通知システムに関しても、各ハードウェア構成や各プログラムは一のサーバ装置に含まれるものであっても良いし、複数のサーバ装置やその他装置に分散／複数配置され、それらの協働処理によって実現されても良いし、またそれら各装置の管理者も複数であっても良い。

ここで、本実施例の通知システムは、例えば前回の試験通知の結果などから、携帯電話機能を有し１枚のＳＩＭカードを利用して制御される通信装置あたりの発信上限を「ＨＤＤ」に記録、保持している。またオペレータからの情報入力などによって、例えばサービス利用料金に係る請求や領収、あるいは広告などのさまざまな通知を送信する対象者として特定されている顧客や顧客候補などの数も通知必要数として「ＨＤＤ」に記録、保持している。

また、同様にオペレータ入力などによって、試験通知を送信するための試験用アドレスも「ＨＤＤ」に登録、保持されている。

そして例えばタイムスケジューラなどで定められる日時に「ＣＰＵ」は試験実行プログラムを解釈し、それにしたがって「ＨＤＤ」に記録されている試験用アドレスに対して試験通知を順次行うよう、「ＳＩＭカード」を利用して「Ｉ／Ｏ」回路から１の通信装置に対して制御命令を出力する。そして当該制御命令に従って、１の通信装置は携帯電話機能の例えばＳＭＳなどを利用して試験用アドレス宛ての試験通知を順次送信する。また、「ＣＰＵ」はその試験通知の送信数をカウントする処理を行う。

その後、携帯電話キャリアによる発信上限以上の通知を送信した場合に、その送信エラーとして上限エラー情報が携帯電話キャリアのメールサーバなどから返信される。すると通知システムの「ＣＰＵ」は上限エラー受信プログラムに従って、その返信された上限エラー情報を「通信回路」や、通信装置を経由して「Ｉ／Ｏ回路」を介して取得する。

そして「ＣＰＵ」は、発信上限算出プログラムを解釈し、その解釈結果にしたがって、その上限エラー情報を受信するまでに前記カウントされた試験通知の送信数を「主メモリ」のアドレス１に格納する。そして当該送信数を発信上限とするとともに、当該数値から予め定められたマージンの「２」を減算した値を１の通信装置から送信する通知数として「主メモリ」のアドレス２に格納する。また、「ＨＤＤ」に保持されている発信上限と上記新たに得られた発信上限の数値が変わっていれば、新たに得られた値で発信上限の値を更新する。

つづいて「ＣＰＵ」は、ＳＩＭ制御手段必要数算出プログラムを解釈し、それにしたがって「ＨＤＤ」に保持されている通知必要数を読み出し、「主メモリ」のアドレス３に格納する。そして、アドレス３に格納されている通知必要数を、アドレス２に格納されている１の通知機器からの送信数で除すことで、必要な通信装置の数を算出し、「主メモリ」のアドレス４に格納する。

そして管理者やサービス提供者などは、算出されたＳＩＭ制御手段の必要数と現在の稼働数を参考に、当該必要数に足りない分のＳＩＭ制御手段の入手（例えば通信装置の購入や携帯電話キャリアとの契約によるＳＩＭカードの入手）を行ったり、逆に必要数を超えているＳＩＭ制御手段の休眠手続や契約解除手続などを行ったりする、という具合である。

<処理の流れ>
図１０は、本実施例の通知システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、上記のような計算機の各ハードウェア構成によって実行されるステップであっても良いし、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、顧客以外の試験用の送信先アドレスである試験用アドレスを試験用アドレス保持部に保持するため記録し（試験用アドレス保持ステップＳ１００１）、また、通知必要数を通知必要数保持部に保持するため記録する（通知必要数保持ステップＳ１００２）。

その後、携帯電話機能を有するハードウェアを制御して複数の試験用アドレスに対して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内に送信数を順次増やしながら試験通知を実行する（試験実行ステップＳ１００３）。そしてこのＳ１００３を、その試験通知の送信数が前記発信上限を超えたために送信できなかった旨を示す上限エラー情報を受信する（上限エラー情報受信ステップＳ１００４）まで実行する。

つづいて受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出し（発信上限算出ステップＳ１００５）、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出する（ＳＩＭ制御手段必要数算出ステップＳ１００６）。

<効果の簡単な説明>
以上のように、本実施例の通知システムによって、一のＳＩＭ制御手段における発信上限を把握することができる。したがって当該発信上限が変更されても、全体で必要なＳＩＭ制御手段の数を算出し、その算出数に応じた数のＳＩＭ制御手段を用意することで、料金支払いに係る請求書や領収書などの通知、あるいは料金支払いとは関係なく広告などの通知を遅滞なく顧客全体に送信することができる。

≪実施例３≫
<概要>
本実施例は、上記実施例２と同様に、携帯電話キャリアなどが定める発信上限について発信上限の減少変更があったことを把握し、通知の送信に必要なＳＩＭ制御手段の数を算出する機能を備える。そして本実施例では、上記実施例２とは異なり、試験通知ではなく、実際の顧客などへの通知による上限エラーからその発信上限を算出することを特徴とする。

<機能的構成>
図１１は、本実施例の通知システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「通知システム」（１１００）は、「通知送信部」（１１０１）と、「上限エラー情報受信部」（１１０２）と、「発信上限算出部」（１１０３）と、「通知必要数保持部」（１１０４）と、「ＳＩＭ制御手段必要数算出部」（１１０５）と、を有する。

なお、本実施例の通知システムも、上記実施例１で説明した構成要件に加えて以下の構成要件を有し、以下の構成要件によって算出したＳＩＭ制御手段の必要数分だけ実施例１の通知システムのハードウェア制御部の有するＳＩＭ制御手段を用意しハードウェア制御を行うことで、料金支払いに関する請求や領収の通知を行うものであっても良い。あるいは実施例１とは別の、複数のＳＩＭ制御手段を利用して各種の通知を行う通知システムとして広告や勧誘などをはじめとする通知を行うものであっても良い。

「通知送信部」（１１０１）は、携帯電話機能を有するハードウェアを制御して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内で通知を発信上限に応じた数だけ送信する機能を有し、例えばＣＰＵや主メモリ、通信回路、通知送信プログラムなどによって実現することができる。具体的には、例えば単一ＳＩＭ制御手段、すなわち一の契約ＳＩＭカードやそれに類する契約記憶媒体を利用した携帯電話機能によって、発信上限に応じて通知システムにて予め定められた数（発信上限の−２の数など）の通知を、顧客の送信先アドレスに対して送信する、という具合である。
また、本実施例の通知システムが上記実施例１の通知システムとの組み合わせで構成される場合、この通知送信部の替わりに、前記ハードウェア制御部が、携帯電話機能を有するハードウェアを制御して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内で通知を発信上限に応じた数だけ送信する通知送信手段を有する構成とすると良い。

また、「上限エラー情報受信部」（１１０２）と、「発信上限算出部」（１１０３）と、「通知必要数保持部」（１１０４）と、「ＳＩＭ制御手段必要数算出部」（１１０５）と、については、上限エラー情報が試験通知ではなく、実際の通知に対する者である以外基本的には上記実施例の同名の構成要件と同じであるので、その詳細な説明は省略する。

そして、もし所定時間枠あたりに送信できる通知の発信上限が、今までの「一日あたり５００通」から「一日あたり４００通」に変更されると、当該通知に対する上限エラー情報を受信することになり、それによって変更された発信上限を把握することができる。

なお、上記の通り本実施例では通知数は現時点で把握している発信上限に応じた数であるため、現時点の発信上限を減じる変更を把握することができる一方で発信上限が増加する変更を把握することはできない。しかし前者の変更の場合、通知を送ることができない顧客や顧客候補などが生じてしまうのに対し、後者の変更の場合、過大なＳＩＭ制御手段を利用することになるものの、全ての顧客などにきちんと通知を送信することは可能である。したがって、本実施例の構成でも、通知の送信確実性については十分担保することができる。

<処理の流れ>
図１２は、本実施例の通知システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、上記のような計算機の各ハードウェア構成によって実行されるステップであっても良いし、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、通知必要数を通知必要数保持部に保持するため記録する（通知必要数保持ステップＳ１２０１）。

その後、携帯電話機能を有するハードウェアを制御して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内で、顧客などの送信先アドレスに対して実際の通知を送信する（通知送信ステップＳ１２０２）。

そしてこの通知の送信数が前記発信上限を超えたために送信できなかった旨を示す上限エラー情報を受信する（上限エラー情報受信ステップＳ１２０３）と、受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出し（発信上限算出ステップＳ１２０４）、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出する（ＳＩＭ制御手段必要数算出ステップＳ１２０５）。

<効果の簡単な説明>
以上のように、本実施例の通知システムによっても、一のＳＩＭ制御手段における発信上限が減じられたことを把握することができる。したがって当該発信上限が減少変更されても、全体で必要なＳＩＭ制御手段の数を算出し、その算出数に応じた数のＳＩＭ制御手段を用意することで、料金支払いに係る請求書や領収書などの通知、あるいは料金支払いとは関係なく広告などの通知を遅滞なく顧客全体に送信することができる。

≪実施例４≫
<概要>
本実施例は、上記実施例２や３と同様に、携帯電話キャリアなどが定める発信上限を把握し、発信上限の変更があった場合に、通知の送信に必要なＳＩＭ制御手段の数を算出する機能を備える。そして本実施例では、上記実施例２や３とは異なり、例えばキャリアなどから通知されるその発信上限を取得する構成を備えることを特徴とする。

<機能的構成>
図１３は、本実施例の通知システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例の「通知システム」（１３００）は、「発信上限取得部」（１３０１）と、「通知必要数保持部」（１３０２）と、「ＳＩＭ制御手段必要数算出部」（１３０３）と、を有する。

なお、本実施例の通知システムも、上記実施例１の通知システムの一部として以下の構成要件を有し、実施例１で説明したように管理されている顧客ごとの料金支払手段などに応じた料金の請求や領収の通知を行うものであっても良いし、実施例１とは別の通知システムとして、料金の請求や領収の通知のほか、広告をはじめとするその他の通知を行うものであっても良い。

「発信上限取得部」（１３０１）は、携帯電話機能に係る携帯電話キャリアにて定められる所定の時間枠内での単一ＳＩＭ制御手段からの発信上限を取得する機能を有し、例えばＣＰＵや主メモリ、通信回路や入力デバイス、発信上限取得プログラムなどで実現できる。

具体的には、例えば携帯電話キャリアが公開する発信上限を通信回路を介して取得したり、別途オペレータによる発信上限の入力よって取得したりする、という具合である。

また、「通知必要数保持部」（１３０２）と、「ＳＩＭ制御手段必要数算出部」（１３０３）については、上記実施例の同名の構成要件と基本的に同じであるので、その詳細な説明は省略する。

<処理の流れ>
図１４は、本実施例の通知システムにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、上記のような計算機の各ハードウェア構成によって実行されるステップであっても良いし、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、通知必要数を通知必要数保持部に保持するため記録する（通知必要数保持ステップＳ１４０１）。

その後、例えば携帯電話キャリアが公開するなどした、当該携帯電話キャリアにて定められる所定の時間枠内での単一ＳＩＭ制御手段からの発信上限を取得する（発信上限取得ステップＳ１４０２）と、前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出する（ＳＩＭ制御手段必要数算出ステップＳ１４０３）。

<効果の簡単な説明>
以上のように、本実施例の通知システムによっても、一のＳＩＭ制御手段における発信上限を把握することができる。したがって当該発信上限が変更されても、全体で必要なＳＩＭ制御手段の数を算出し、その算出数に応じた数のＳＩＭ制御手段を用意することで、料金支払いに係る請求書や領収書などの通知、あるいは料金支払いとは関係なく広告などの通知を遅滞なく顧客全体に送信することができる。

０２００通知システム
０２０１ハードウェア制御部
０２０２第一顧客情報保持部
０２０３第二顧客情報保持部
０２０４支払手段保持部
０２０５支払手段変更受付部
０２０６可否取得部
０２０７実行命令部

Claims

携帯電話機能を有するハードウェアを制御するためのＳＩＭ制御手段を複数利用して顧客に対して通知を行う通知システムであって、
前記顧客以外の試験用の送信先アドレスである試験用アドレスを保持する試験用アドレス保持部と、
前記携帯電話機能を有するハードウェアを制御して一以上の試験用アドレスに対して、携帯電話キャリアにて定められる単一ＳＩＭ制御手段からの発信上限を定める時間枠内に送信数を順次増やしながら試験通知を実行する試験実行部と、
前記送信数が前記発信上限を超えたために送信できなかった旨を示す上限エラー情報を受信する上限エラー情報受信部と、
受信した上限エラー情報に基づいて、一のＳＩＭ制御手段あたりの発信上限を算出する発信上限算出部と、
通知必要数を保持する通知必要数保持部と、
前記発信上限と通知必要数から稼働すべきＳＩＭ制御手段の数を算出するＳＩＭ制御手段必要数算出部と、
を有する通知システム。