(57)【要約】  本発明は、顧客の前払い残高が事前に規定された閾値を下回っていることを前払いサービスを使用する通信顧客に通知を行うための向上した方法および装置に関する。通知の数は、規定された間隔内の規定された数に限定される。顧客は、顧客が問題をすでに認識しているとき、複数の通知を受信する迷惑から逃れるので有利である。
2010516219.tif 000002
【特許請求の範囲】
【請求項１】
顧客の前払い通信アカウントの状態を顧客に通知する方法であって、
前記顧客用の通知データベースを格納するステップであって、前記データベースが規定された間隔中に前記顧客に行われるべき低残高通知の数の制限値を備える、格納するステップと、
前記顧客が電話をかける前、電話中、または電話をかけた後に前記顧客に関する前払い残高が事前に規定された閾値を下回っており、Ｎ個未満の通知が前記間隔中に前記顧客に行われている場合、前記顧客に低残高通知を行うステップと
を備える、方法。
【請求項２】
前記前払い残高がゼロまたは負になる場合、前記顧客にゼロまたは負残高通知を行うステップ
をさらに備える、請求項１に記載の方法。
【請求項３】
前記ゼロまたは負残高通知が、Ｎ個の通知が以前に行われている場合でも行われる、請求項２に記載の方法。
【請求項４】
前記顧客が、前記低残高通知に対する確認応答メッセージを返信することができるかどうかを試験するステップと、
前記顧客が確認応答メッセージを返信する場合にさらなる低残高通知を停止するステップと
をさらに備える、請求項１に記載の方法。
【請求項５】
通知メッセージが、規定された時刻および／または曜日中に抑制されることができる、請求項１に記載の方法。
【請求項６】
前記顧客用の通知データベースが、前記顧客の前払いサービスの販売会社の１つまたは複数の通知データの複数のセットのうちの１つを備える、請求項１に記載の方法。
【請求項７】
顧客の前払い通信アカウントの状態を顧客に通知するための装置であって、
規定された間隔中に前記顧客に行われるべき低残高通知の数の制限値を備える前記顧客用の通知データベースと、
前記顧客の前払い残高が事前に規定された閾値にあるまたは下回っていることを検出するための手段と、
前記顧客の前払い残高が前記閾値にあるまたは下回っていることの検出、およびＮ個未満の通知が前記顧客に行われていることの検出に応答して、前記顧客が電話をかける前、電話中または電話をかけた後に前記顧客に低残高通知を行うための手段と
を備える、装置。
【請求項８】
前記前払い残高がゼロまたは負になる場合、前記顧客にゼロまたは負残高通知を行うための手段をさらに備える、請求項７に記載の装置。
【請求項９】
前記顧客が前記低残高通知に対する確認応答メッセージを返信することができるかどうかを試験し、
前記顧客が確認応答メッセージを返信する場合にさらなる低残高通知を停止するための手段
をさらに備える、請求項７に記載の装置。
【請求項１０】
通知メッセージが、規定された時刻および／または曜日中に抑制されることができる、請求項７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、顧客の残高が閾値を下回っているまたは実際にはゼロもしくは負であることを前払い通信顧客に通知するための向上した方法および装置に関する。
【背景技術】
【０００２】
多くの通信顧客は、前払いサービスアカウントを確立することによりそれらのサービスの代金を支払うことを選択する。このアカウントは、顧客が顧客のアカウント内に有し、通信サービスのために使用することができる単位またはドルのいずれかでの通信サービス金額の残高を維持する。概してアカウントは、顧客がクレジットもしくはデビットカード番号および顧客のアカウントに加算されるべき金額を与える呼を用いて補充されることができ、またはアカウントは、販売会社から購入される「スクラッチ」カードの使用により補充され、顧客によって通信サービスプロバイダに連絡されることができる。また一部の小売業者は、顧客が小売業者に代金を支払い、小売業者が顧客のために通信サービスプロバイダを購入するサービスを提供する。スクラッチカードまたは小売業者が購入したサービスは、顧客のアカウントに加算された残高が、顧客がスクラッチカードの販売会社または小売業者に支払う金額を超える販売促進の可能性を提供する。一部の顧客は、顧客がサービスプロバイダにクレジットまたはデビットカード番号を与え、サービスプロバイダが、アカウントが閾値を下回るときにアカウントに自動的に補充するサービスを使用する。
【０００３】
しかし、多くの顧客は、顧客のアカウントを制御することにおいてよりアクティブに関与することを好む。これらの後者の顧客の場合、顧客のアカウントがある閾値を下回っていることを音声またはデータメッセージを介して顧客に通知するための用意がなされ、その結果、顧客は、サービスが拒否される前に顧客のアカウントに加算するように手配することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術の問題は、顧客の残高が閾値を下回った後、通知システムによって通知メッセージが呼ごとに顧客に送信されることである。呼がショートメッセージサービス（ＳＭＳ）呼である場合、これらの煩雑な通知は、顧客を煩わすことになる可能性があり、サービスプロバイダへの苦情になる可能性があり、これらの苦情は、処理する上で非常に高くつく。
【課題を解決するための手段】
【０００５】
通知の数およびこれらの通知のタイミングが、前払いサービスの顧客に対するサービスの通知クラスによって制御される本発明によれば、上記の問題が解決され、従来技術に勝る寄与がなされる。顧客は、わずかＮ個の通知（ここで、一般にＮは１−３の範囲である）が間隔ごとに行われるべきであり、ここで典型的には間隔は１日であることを規定することができる。様々な規則が、サービスが打ち切られようとしているという警告を用いて顧客の残高がゼロまたは負であることを通知するために利用可能である。
【０００６】
出願人の発明の１つの特徴によれば通知メッセージが、顧客がサービスプロバイダに通知確認応答の指示を行わない限り機会ごとに（例えば、呼ごとに）顧客に送信されることができる。確認応答の指示が個人識別番号（ＰＩＮ）を含む場合、主なユーザ以外のユーザ（例えば、主なユーザの子供たち）はさらなる通知を抑制することができないことになる。この仕組みは、顧客が、顧客をさらに悩ませることなく通知メッセージを聞いていることを保証するので有利である。
【０００７】
出願人の発明の他の特徴によれば、サービスプロバイダおよび顧客の両方がサービスの通知クラスを変更することができ、その結果、例えば顧客が、各期間内の通知が２つでは不十分であることを見いだす場合、顧客はこの数を増大することができる。
【０００８】
出願人の発明の他の特徴によれば、前払いサービスの販売会社が、１つまたは複数の事前にパッケージ化されたサービスの通知クラスを提供し、販売会社のサービスを向上するための選択を使用することができる。顧客が、顧客自体のサービスクラスを初期設定することまたは販売会社のサービス代理人にこの機能を実行させることの複雑さから逃れることができるので有利である。
【０００９】
出願人の発明の他の特徴によれば、残高がその顧客に関する閾値を下回ってしまったので金額が顧客のクレジットまたはデビットカードアカウントから自動的に引き出されるとき、顧客は通知を受信する。
【図面の簡単な説明】
【００１０】
【図１】出願人の発明の動作を示す構成図である。
【図２】低またはゼロ残高通知メッセージの適用を示す流れ図である。
【図３】低またはゼロ残高通知処理が要求されるときに実行される動作を示す図である。
【図４】通知データベース内の顧客のサービスクラスの変更を示す流れ図である。
【発明を実施するための形態】
【００１１】
図１は出願人の発明の動作を示す構成図である。顧客ステーション１０１は、ＳＳ７またはインターネットプロトコル（ＩＰ）ネットワーク１０３を介して交換装置１０５にアクセスする。交換機は、陸上回線交換機、モバイル交換局（ＭＳＣ）、またはインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）などの特定の呼の要求に従ってデータパケットもしくはデータメッセージを導くための単に呼セッション制御機能（ＣＳＣＦ）であってよい。呼が、携帯電話ステーション１０１内で生じる信号によって示されるショートメッセージ呼であると認識される場合、呼はショートメッセージサービスセンタ（ＳＭＳＣ）１０７にルーティングされる。交換機またはＳＭＳＣは、顧客が、呼に対する請求金額ごとに顧客のアカウントから引き落とすことによって呼に対して請求を受けるように手配するために前払いサービス複合体１０９にアクセスする。交換機１０５またはＳＭＳＣ１０７は、前払いサービス複合体１０９内の前払い呼制御ユニット１１１にアクセスする。前払い呼制御ユニットは、アカウント管理ユニット１１３と通信し、アカウント管理ユニット１１３は、顧客のアカウントを管理し、顧客用の通知データベースを格納し、呼に対する請求額に従ってアカウントを低減する。前払い呼制御は、いくらのアカウントが、呼自体のためにおよび呼の分または他の期間ごとに引き落とされるべきかを見いだすために評価エンジン１２１にアクセスする。前払い呼制御ユニットはアカウント管理ユニット１１３と通信して、アカウント管理ユニットに呼およびその時間増大に対して顧客のアカウントを低減させる。次いでアカウント管理ユニットは、顧客のアカウントが、通知動作が必要とされうることを示す閾値を下回るときに通知制御規則エンジン１１５に通知する。次いで通知制御規則エンジンは、通知が、交換機１０５およびネットワーク１０３を介して顧客と通信するインテリジェント周辺装置（ＩＰ）またはメディアサーバ１１９から顧客に送信されるように通知制御１１７に通知する。プロトコルは、ネットワーク、呼の種類（音声、データ、テキストメッセージ（ＳＭＳ、インスタントメッセージ、電子メール））、送受話器の種類に依存することになる。
【００１２】
前払いサービス複合体のブロックのそれぞれは、プロセッサプラットフォームの制御下で動作するソフトウェアパッケージを備える。一部の物理プロセッサプラットフォームはブロックのいくつかを制御することができる。ブロックのうちの１つ（好ましい実施形態ではアカウント管理ユニット）は、自由度のある通知機能を有し、前払いサービス複合体によって供給される顧客のサービスの通知クラスを格納するデータベース１１４を含む。
【００１３】
図２は通知プロセスを示す。前払い呼が入電する（動作ブロック２０１）。これは、ステーション１０１からの発呼、または携帯電話ステーション１０１の場合には着呼のいずれかであってよい。試験２０３は、呼前通知処理が、残高をチェックすることによって必要とされうるかどうかを決定するために使用される（試験２０３）。残高がゼロである場合、ゼロ残高通知処理が呼び出され（動作ブロック２０５）、呼が終了する（動作ブロック２０７）。試験２０３の呼前残高チェックが閾値を上回る残高を示す場合、呼はいかなる残高通知をすることなく持続することを許される（動作ブロック２０９）。呼前残高チェック試験２０３が、残高が閾値に等しいまたは下回っていることを示す場合、低残高通知処理（動作ブロック２１１）が呼び出される。低残高通知処理２１１およびゼロ残高通知処理２０５の詳細が図３に示されている。
【００１４】
低残高通知処理の実行後、呼は持続する（動作ブロック２１３）。
【００１５】
呼中には、評価エンジンおよびアカウント管理システムによって規定された間隔で顧客の残高がチェックされる（試験２１５）。ここで残高がゼロである場合、ゼロ残高通知処理（動作ブロック２０５）が呼び出される。ここで残高が閾値にあるまたは閾値を下回っている場合、低残高通知処理が呼び出される（動作ブロック２１７）。残高が閾値を上回っている場合、呼は、１つの当事者が電話を切るまで持続することを許される（動作ブロック２１９）。試験２１５は、評価エンジンおよびアカウント管理システムによって規定されるように呼中に複数回呼び出されることが可能である。
【００１６】
当事者のうちの１つが電話を切る（動作ブロック２１９）とき、試験２２１が、通知処理がこの呼後の状態で必要であるかどうかを決定するためにもう一度使用される。ここで残高がゼロである場合、ゼロ残高通知処理２０５が呼び出される。残高が閾値にあるまたは閾値を下回っている場合、低残高通知処理が呼び出される（動作ブロック２２３）。残高が閾値を上回っている場合、呼は、さらなる通知動作なしに単に終了する（動作ブロック２０７）。
【００１７】
サービスの通知クラスは、個々の顧客に対して調整されることができるまたは販売会社によって提供される複数のクラスのうちの１つでありうる。
【００１８】
図３は、低またはゼロ残高通知の適用を示す流れ図である。通知が適用されるべきかどうかの試験は、様々なカウンタが、低残高通知が送信されるべきかどうかまたはゼロ残高通知が送信されるべきかどうかを決定するために使用されることを除いて低またはゼロ残高通知に関するものと同一である。低またはゼロ残高通知の要求が、図２の流れ図の複数の箇所（２０５、２１１、２１７、２２３）のうちの１つで検出されている（動作ブロック３０１）。試験３０３は、これが通知間隔の期間内の第１の通知要求であるかどうかを決定するために使用される。典型的にはこの期間は１日である。その間隔中に顧客に行われるべきである通知の最大数は間隔に関連している。これが期間中の第１の通知処理要求である場合、好ましいモードで残高通知が顧客に送信される（動作ブロック３０５）。これが第１の通知処理要求でない場合、試験３０６が、時刻または曜日の制限があるかどうかを決定するために使用される。この種の制限がサービスの通知クラスの一部として存在する場合、ならびに現在の曜日および時刻が制限リスト上にある場合、通知は送信されないことになる。代替実施形態では、時刻および曜日の制限が第１の通知にも適用されることができる。時刻および曜日の制限が最繁時中の通知トラフィックを低減するために使用されることができる。その後、試験３０７は、Ｎ個未満の通知がこの期間内に送信されているかどうかを決定するために使用される。その場合、残高通知メッセージが顧客に送信される（動作ブロック３０５）。Ｎ個の通知がすでに送信されている場合、試験３０９は、これが補充後の通知に関する第１の要求であるかどうかを決定するために使用される。これは、顧客が顧客のアカウントを補充したが、この補充後に多くの電話をかけたので残高が再び低くなった場合に生じるであろう。その場合、カウンタはリセットされるべきであり、残高通知が送信されるべきである（動作ブロック３０５）。これが補充後の第１の要求でない場合、Ｎ個の通知がすでに送信されている場合でも残高通知が送信されるべきであることを要求するオペレータオーバライドが受信されているかどうかのチェックがなされる（試験３１１）。その場合、残高通知メッセージが送信される。オペレータオーバライドがない場合、これは、残高通知がこの時点で送信されるべきでない状態である（動作ブロック３１３）。
【００１９】
動作ブロック３０５（残高通知の実施）の後、試験３１５が、確認応答がこの顧客に対する残高通知のために使用されるかどうかを尋ねるために使用される。顧客がこの機能を有しない場合、これが、残高通知の要求に応答するプロセスの最後である。顧客が確認応答機能を有する場合、試験３１９が、顧客が個人識別番号（ＰＩＮ）と共に確認応答を行っているかどうかを決定するために使用される。顧客が確認応答を行っていない場合、これが通知手順の最後である。顧客が確認応答を行っている場合、通知のカウンタは最大数Ｎを超えるように設定され、その結果、さらなる通知が顧客に送信されないことになる（動作ブロック３２１）。
【００２０】
通知の種類はサービスの通知クラスの一部でもある。通常の送受話器の場合、口頭の通知が好まれうる。愛好家の送受話器の場合、メッセージが好まれうる。データ端末装置の場合、メッセージ（場合によっては可聴信号（例えば、ベル）を伴う）が好まれうる。
【００２１】
図４は、顧客またはサービスプロバイダのいずれかによって通知データベースにアクセスするプロセスを示す。顧客がデータベースにアクセスする（動作ブロック４０１）。試験４０３は、顧客が正しい個人識別番号（ＰＩＮ）を与えるかどうかを決定するために使用される。顧客が正しいＰＩＮを与える場合、データベースを変更するために顧客とデータベースとの間の対話が可能とされる。データベースが変更されるかまたは顧客が正しいＰＩＮを与えることを失敗するかのいずれかの後にプロセスが終了する（終了ブロック４０５）。サービスプロバイダがデータベースにアクセスする（動作ブロック４１１）場合、データベースを変更するためにサービスプロバイダとデータベースとの間の対話が行われる（動作ブロック４１３）。動作ブロック４１３の完了後に終了ブロック４０５に入る。
【００２２】
通知データベースは下記に関するフィールドを含む：
１．通知に関する閾値
２．Ｎ個の通知を行うための間隔
３．その間隔中に行われるべき通知の数Ｎ
４．間隔中に行われるべきゼロ残高通知の数Ｍ
５．顧客が確認応答機能を与えられているか？
６．確認応答機能に関するＰＩＮ
７．データベースを変更するためのＰＩＮ
８．時刻および曜日の制限
９．使用されるべき通知の種類（例えば、口頭、データメッセージ、可聴信号を加えたデータメッセージ）
１０．前払いサービスの販売会社の識別番号
【００２３】
通知データベース内のデータは上述の様々な機能をサポートする。
【００２４】
上記の説明は出願人の発明の１つの好ましい実施形態についてである。
【図１】
2010516219.tif 000003
【図２】
2010516219.tif 000004
【図３】
2010516219.tif 000005
【図４】
2010516219.tif 000006
【国際調査報告】
2010516219.tif 000007
2010516219.tif 000008