(57)【要約】【課題】プリペイド無線サービスの設定を容易にする方法である。【解決手段】プリペイド無線通信デバイスを含む残高リフレッシュ操作では、ＳＭＳメッセージを電波を通じてデバイスに送信する。デバイスは、料金表を用いて、利用可能残高に対する呼び出しの影響を追跡する。サービスプロバイダは、ＳＭＳメッセージを用いて料金表を任意に更新することができる。本発明の実施形態によれば、無線デバイスは、残高ならびに料金表もしくは料金率表を格納するメモリを含む。残高の設定は、デバイスをアクティブ化する際に行うことができる。【選択図】図１
2006340385.tif 000002
【特許請求の範囲】
【請求項１】
プリペイド無線通信サービスを管理する方法であって、
無線デバイス識別番号と通信料金データと利用可能クレジット残高とソフトウェアアプリケーションとをメモリデバイスを含む無線デバイスに格納するステップと、
ネットワークされた複数のサーバにおいて、該無線デバイス識別番号を含む加入者データベースを提供するステップと、
該利用可能クレジット残高の増加を要求するために通話するステップと、
該無線デバイスから該無線デバイス識別番号を示すデータを受信するステップと、
該無線デバイス識別番号の有効性のマッチングを行なうステップと、
クレジット／デビットカードおよび／またはスクラッチカードを用いて該利用可能クレジット残高を増加させるステップと、
該利用可能クレジット残高を改変するために、第１のメッセージングサービスメッセージ、好ましくはＳＭＳメッセージを生成し、該第１のメッセージを暗号化するステップと、
該第１のメッセージングサービスメッセージを該無線デバイスに送信するステップと、
該無線デバイスにおいて該第１のメッセージングサービスメッセージを復号化するステップと、
該復号化された第１のメッセージングサービスメッセージを用いて該無線デバイスにおいて該利用可能クレジット残高を増加させるステップと、
確認応答として、第２のメッセージングサービスメッセージ、好ましくはＳＭＳ−ＭＯを該無線デバイスによって返信するステップと、
該無線デバイスにおいて、該無線デバイスによって受信または開始された各通話のコストを該通信料金データを用いて計算するステップと、
該無線デバイスによって受信または開始された各通話のコストを該利用可能クレジット残高から差し引くステップと
を包含する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は、プリペイド無線サービスを管理するシステムおよび方法に関する。
【背景技術】
【０００２】
（発明の背景）
従来の無線システムにおいて、加入者は、無線電話機（すなわる、ハンドセット）および無線サービスをサービスプロバイダから購入する。加入者は、サービスプロバイダと連絡して無線サービスへのアクセスに対する加入料金を月ごとに支払い、また、呼び出し時間（ａｉｒ  ｔｉｍｅ）に対しても支払いをする。加入者が期日までの支払いを怠ると、サービスプロバイダはサービスを中断し得る。次いで、サービスプロバイダは、未払い料金を集金しなければならなくなる。
【０００３】
米国特許第５，４７０，２４７号に、セルラー電話通信補充（ｒｅｆｉｌｌ）システムについての記載がある。このシステムは、所定のパラメータ（例えば、呼び出し回数、払い込み金額（ａｍｏｕｎｔ  ｏｆ  ｆｕｎｄｓ）等）に従って支払いを計測する装置を含む。所定のパラメータは、この装置のセキュアな計測装置内に格納される。
【０００４】
米国特許第５，５７７，１００号に、リアルタイムで通話料金の請求額を内部で計算する能力を内蔵する移動電話についての記載がある。この移動電話は、アップグレード可能な料金表と実行中のアカウントステータスを演算する複雑な課金アルゴリズムとを格納する内部メモリを内蔵する。さらに、この移動電話は、顧客にリアルタイムのアカウントステータスを通知することが可能である。また、この米国特許は、移動電話をアクティブにし、通信路（ａｉｒｗａｙｓ）を通じて料金表内のアカウントステータスを更新する通信システムも提供する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従って、サービスプロバイダが未払い料金の集金に関して心配をする必要が無く、加入者が無線支払いを管理できる無線プリペイドシステムが必要とされている。
【課題を解決するための手段】
【０００６】
（発明の要旨）
本発明は、プリペイド無線通信サービスの設定を容易にする技術を提供する。本発明の実施形態によれば、無線デバイスは、残高ならびに料金表もしくは料金率表を格納するメモリを含む。残高の設定は、デバイスをアクティブ化する際に行うことができる。このデバイスは、利用可能残高をモニタリングし、デバイスが使用されると残高を再計算する。再計算の際、料金表または料金率表に格納されている情報が使用される。加入者は、利用可能残高をリフレッシュする必要がある場合、サービスプロバイダに連絡して、クレジットカードもしくはデビットカードのアカウント情報および／またはプリペイド通話カード情報をＩＶＲシステムまたは呼び出しセンタ環境内のエージェントに提供する。次いで、そのサービスプロバイダは、ＳＭＳメッセージを生成して、デバイスのメモリの残高内容を電波を介して（ｏｖｅｒ  ｔｈｅ  ａｉｒ）変更する。さらに、サービスプロバイダは、複数の別の料金率表もしくは料金表の提供および／またはこのような表の経時的な修正を行うことができる。サービスプロバイダは、ＳＭＳメッセージを用いて、デバイスのメモリを更新して別の料金率表または料金表をメモリに入れることができる。
【０００７】
（本発明の詳細な説明）
システム１の一般的な概要
本発明による無線プリペイドサービスを管理するシステムにおいて、ネットワークプロバイダは、無線通信ネットワーク（例えば、移動通信用グローバルシステム（ＧＳＭ）ネットワークを配信する。本発明は、ＧＳＭだけでなく、他の無線通信ネットワークにも適用可能である。一方、サービスプロバイダは、そのようなサービスの加入者への顧客サービス機能の配信を含むプリペイドサービスを提供する。
【０００８】
図１は、本発明によるシステム１の例示的な実施形態を示す。システム１は、以下に述べるワークステーションとサーバとを組み合せたネットワークを含む。システム１内の接続は、特に明記なき限り、イーサネット（登録商標）伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）１４１を介して構築される。別のデータネットワーク構成を用いてシステム内でのデータ伝送を提供してもよい。
【０００９】
システム１は、無線デバイス１０（例えば、移動電話）、固定電話１５０、または通信ネットワーク（例えば、インターネット）（図示せず）を通じてアクセス可能である。デバイス１０を用いて、加入者は、無線ネットワークを介して固定型公衆電話ネットワーク（ＦＰＰＮ）１４０へ接続される。電話１５０はＦＰＰＮ１４０に直接接続される。次いで、ＦＰＰＮ１４０は、適切な電話通信インターフェース（例えば、デジタルアクセス信号システム（ＤＡＳＳ）１４３を介して、加入者を自動呼び出し配信（ＡＣＤ）システム１３０に接続する。
【００１０】
ＡＣＤ１３０は、加入者を、適切な電話通信インターフェース（例えば、デジタルプライベートネットワーク信号システム（ＤＰＮＳＳ）１４２を介して自動双方向音声応答（ＩＶＲ）システム３０に接続するか、または、顧客サービスエージェントを有する呼び出しセンタ１６５に接続することができる。加入者は、呼び出しの最中、ＩＶＲ３０と呼び出しセンタ１６５とをいつでも切り替えることができる。
【００１１】
デバイス１０
図２は、システム１の無線デバイス１０のより詳細な図である。デバイス１０は、例えば、無線電話、無線ポケットベル、または無線モデムを有する装置であり得る。デバイス１０は、メモリデバイス１１、プロセッサ１２、受信器／送信器１３、入力デバイス１４および出力デバイス１５をを含む。入力デバイス１４は、例えば、キーボード、音声認識デバイスなどであり得る。出力デバイス１５は、例えば、ＬＣＤ画面、ディスプレイ、モニタ、音声デバイスなどであり得る。メモリデバイス１１は、例えば、ソフトウェアアプリケーション、加入者のプロフィール、通話料金表、一意に定まる認証番号（本発明のこの実施形態では無線電話加入者のＭＳＩＳＤＮ）、および利用可能な残高を格納し得る。メモリデバイス１１は、予めプログラムされた番号も格納し、この番号は、加入者がシステム１に接続してアクティブ化を行い、および／または残高を補充することを可能にする。
【００１２】
デバイス１０による被呼および発呼が発生すると、メモリデバイス１１内に格納されている通話料金表に基づいて通話支払い請求が呼び出される。デバイス１０は、受信および起動された呼び出しの各々について、メモリデバイス１１内に格納されている料金率表または料金表を用いて各通話のコストを計算し、コストを利用可能な残高から差し引く。
【００１３】
デバイス１０の製造工程の間、製造業者により、メモリデバイス１１の特定のデータ（例えば、予めプログラムされた番号およびＭＳＩＳＤＮ）が格納される。製造業者は、このデータを、例えばデータファイルとしてサービスプロバイダに提供する。サービスプロバイダは、このデータファイルを、無線ネットワーク上でデバイス１０を初期設定（ｉｎｉｔｉａｌ  ｐｒｏｖｉｓｉｏｎｉｎｇ）するために必要とする。このデータファイルは最初に、以下に述べる顧客サポートシステム（Ｃｕｓｔｏｍｅｒ  Ｓｕｐｐｏｒｔ  Ｃｅｎｔｅｒ、ＣＳＳ）５０に格納される。所定の時期になると、このデータファイルは、ネットワーク課金および管理システム（ＮＢＡＳ）１９０および暗号化および認証サーバ（ＥＡＳ）４０（例えば、Ｔｅｌｅｍａｃ  Ｃｅｌｌｕｌａｒ  Ｃｏｒｐｏｒａｔｉｏｎの課金認証サーバ（ＤＡＳ）など）に転送される。これらのデータファイルの転送および処理は全て、デバイス１０が使用される前に実行される。
【００１４】
デバイス１０は、ショートメッセージサービス（ＳＭＳ）メッセージを用いて情報を受信および送信することができる。ＳＭＳメッセージのセキュリティは、暗号化サーバ（例えば、ＥＡＳ４０）によって提供される。ＥＡＳ４０は、ＳＭＳメッセージが再使用、コピー、閲覧、または改変できないようにする。ＥＡＳ４０は、ＳＭＳメッセージ内の情報（例えば、ＭＳＩＳＤＮ、残高リフレッシュ、ＳＩＭ通し番号（ＳＩＭ  Ｓｅｒｉａｌ  Ｎｕｍｂｅｒ、ＳＳＮ）、およびＳＭＳメッセージの暗号化用のメッセージ通し番号）を暗号化する。ＥＡＳ４０は、ＳＭＳメッセージをＩＶＲ３０へと送り、ＩＶＲ３０は、そのＳＭＳメッセージをデバイス１０に送信する（図１を参照）。
【００１５】
図３は、ショートメッセージサービスプロセスの図を示す。システム１は、図１内のＳＭＳセンタ（ＳＭＳＣ）１８０をインプリメントする。ＳＭＳセンタ１８０は、例えばＴＣＰ／ＩＰ伝送接続上の双方向ショートメッセージピアートゥピアー（ＳＭＰＰ）プロトコルをサポートする。所定の情報を含むショートメッセージサービス−モバイル終端（ＳＭＳ−ＭＴ）メッセージが、電波を介してデバイス１０へと送信される。デバイス１０は、受信器／送信器１３（図２）を用いてそのＳＭＳメッセージを受信し、ＳＭＳ−ＭＴメッセージを復号し、必要な動作（例えば、残高リフレッシュ）を実行する。次いで、デバイス１０は、受信器／送信器１３を用いて、ポジティブな応答（ｐｏｓｉｔｉｖｅ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をショートメッセージサービス−モバイル発信（ＳＭＳ−ＭＯ）メッセージの形式で送信し返す。デバイス１０からシステム１へのＳＭＳ−ＭＯメッセージは、加入者に支払い請求されない。
【００１６】
ＩＶＲ３０は、アプリケーションレベルフロー制御、再試行カウント、モニタリングおよび検査（ａｕｄｉｔｉｎｇ）を含むＳＭＳワークキュー３００を管理する。ＩＶＲ  ＳＭＳ送信タスク（ＳＭＳ−ＴＸ）３１０は、ＳＭＳワークキュー３００をモニターし、モニター結果に従って新エントリを処理し、ＳＭＳＣ１８０（ＳＭＳＣ１８０は、ＳＭＳＣ  Ａ  ３３０およびＳＭＳＣ  Ｂ  ３４０であり得る）から戻ってきたＭＴ−ＡＣＫメッセージをモニターし、ＳＭＳワークキュー３００内のステータスを更新する。
【００１７】
ＩＶＲ  ＳＭＳ受信タスク（ＳＭＳ−ＲＸ）３２０は、デバイス１０からのＭＯ−ＡＣＫを、到着ルート（すなわち、ＳＭＳＣ  Ａ３３０またはＳＭＳＣ  Ｂ３４０）に関係なくモニターし、ＭＯ−ＡＣＫを適切なＳＭＳ−ＭＴメッセージとリンクさせ、次いで、ＳＭＳワークキュー３００の更新とＳＭＳ−ＭＯメッセージと共に戻ってきた全データの格納とを行う。
【００１８】
ＣＳＳ５０
図１に示すＣＳＳ５０は、加入者データベース２３０とスクラッチカード（すなわち、プリペイド通話カード）データベース２４０とを含む。加入者データベース２３０は、加入者、ＩＶＲ３０および／または呼び出しセンタ１６５が行うアクティビティ（例えば、アクティブ化、残高リフレッシュ、およびデバイス１０のアクティビティ）の全てを継続的に追跡する。加入者データベース２３０はまた、デバイス１０のメモリデバイス１１に格納されている情報の自動ミラーリングも行う。加入者データベース２３０は、加入者との見解の不一致を解決し、潜在的な詐欺的行為を検出するために用いられる。
【００１９】
一方、スクラッチカードデータベース２４０は、スクラッチカードの全アクティビティ（例えば、生成、印刷、分配、アクティブ化、およびスクラッチカードの使用）を追跡する。１つの実施形態において、加入者データベース２３０およびスクラッチカードデータベース２４０は、Ｍｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎのＭｉｃｒｏｓｏｆｔ  ＳＱＬ  Ｓｅｒｖｅｒ（登録商標）を用いて動作および維持される。さらに、１つの実施形態において、Ｍｉｃｒｏｓｏｆｔ
ＣｏｒｐｏｒａｔｉｏｎのＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  ＮＴ（登録商標）  Ｖｅｒｓｉｏｎ  ４のもとで、ＣＳＳ５０上でＣＳＳアプリケーションソフトウェアを動作させる。
【００２０】
ソフトウェアモデル
本発明の１つの実施形態によるシステム１は、「ワークキュー」のソフトウェアモデルを利用する。図４は、このソフトウェアモデルの例示的実施形態を示す。１つのプロセスは、複数の独立かつ別個のサブプロセスを含み、各サブプロセスは、単一のタスクにより管理され得る。例えば、入力キュー４００は、サブプロセス４１０を実行するのに必要なタスク１についての情報を提供する。サブプロセス４１０は、プロセスの定義に従って情報を処理し、処理結果を出力キュー４２０に配置する。次いで、サブプロセス４１０の出力キュー４２０は、サブプロセス４３０の入力キュー４２０となる。入力キュー４２０は、タスク２についての情報をサブプロセス４３０に提供し、その結果が出力キュー４４０に配置される。キュー４４０は、サブプロセス４３０の出力キューとして働き、サブプロセス４５０の入力キューとしても働く。何らかの理由でいくつかのタスクが中断した場合、入力キュープロセスは増大し、出力キューは次第に減少して空のキューとなり、生成ラインの先にある他のサブプロセスは継続して動作する。入力キューがタスクの処理能力よりも速い速度で増加する場合、同じタスクを追加して開始することができる。
【００２１】
１つの実施形態において、図４に示すソフトウェアモデルが以下に述べる残高リフレッシュプロセスに適用される。この残高リフレッシュプロセスでは、残高／請求カード確認、ＥＡＳ処理、およびＳＭＳメッセージ送信について別個のプロセスがある。このソフトウェアモデルは、複数の特殊なプロセスを必要とするアプリケーションに適切である。さらに、このソフトウェアモデルは、インターフェースが異なる他の環境への適応を容易にする。アプリケーション全体を変更する必要はなく、該当プロセスを実行するサブアプリケーションのみを変更すればよい。また、このアプローチは、各サブアプリケーションを他のサブアプリケーションと別個に完全にテストすることが可能なので、統合テストをスピードアップする。さらに、ワークをキューに入れるプロセスはＩＶＲ３０プロセスだけではなく、呼び出しセンタ１６５に配備されるパーソナルコンピュータを用いたアプリケーションでもよい。
【００２２】
アクティブ化
図５は、無線デバイス１０をアクティブ化するプロセスを示すフローチャートである。加入者が予めプログラムされた番号をダイヤルすると、その呼び出しはルーティングされ、ＩＶＲ３０により応答される（工程５００）。あるいは、加入者は、以下に詳述する呼び出しセンタ１６５を呼び出すことによりデバイス１０をアクティブ化することもできる。ＩＶＲ３０は、デバイス１０をアクティブ化する際、デバイス１０のＭＳＩＳＤＮを用いる。
【００２３】
ＩＶＲ３０は、受信の種類（デバイス１０からの初回の受信呼び出し、登録済みのデバイス１０からの受信呼び出し、未登録のデバイス１０からの受信呼び出し、固定電話１５０からの受信呼び出し、または通信ネットワークからの受信呼び出し）に応じて異なる応答をする。
【００２４】
ＩＶＲ３０は、呼び出しを受信すると、自身のデジタル信号処理（ＤＳＰ）入力認識能力を用いて、当事者（ｐａｒｔｙ）Ａの数（すなわち、呼び出しの当事者または呼び出しの発信者の数）を解析して、自動的にＭＳＩＳＤＮをＤＳＰ入力として判定する（工程５１０）。加入者がシステム１へ接続するのにデバイス１０以外の任意の手段を用いている場合、ＩＶＲ３０は、加入者に適切なＭＳＩＳＤＮをＤＴＭＦ入力として手入力するよう促す（工程５２０）。
【００２５】
その後、システム１は、加入者データベース２３０を用いてＭＳＩＳＤＮが有効かどうかを判定する（工程５３０）。ＭＳＩＳＤＮが有効でない場合、システム１は、呼び出しを拒絶するかまたは加入者にＭＳＩＳＤＮを再入力するようリクエストする（工程５５０）。ＭＳＩＳＤＮが有効な場合（すなわち、システム１内で使用されるよう設定済みの場合）（工程５４０）、システム１は、ＭＳＩＳＤＮを照会して移動デバイスがアクティブ化されているかどうかをチェックする（工程５６０）。上述のように、デバイス１０は、事前設定無しにアクティブ化することはできない。ＭＳＩＳＤＮが以前にアクティブ化されていない場合（すなわち、未登録のデバイス１０である場合）、システム１は、呼び出し禁止設定を解除（ｂｙ  ｕｎｂａｒｒｉｎｇ）することによりＭＳＩＳＤＮをアクティブ化し（工程５７０）、加入者を残高リフレッシュプロセスに進ませる（工程５８０）。ＩＶＲ３０がＭＳＩＳＤＮを以前にアクティブ化されていると判定したときも、加入者を残高リフレッシュプロセスに進ませる。その後、ＩＶＲ３０は加入者データベース２３０を更新する。
【００２６】
この「アクティブ化」工程は、デバイス１０に禁止設定（ｂａｒ）が施されているかどうかをチェックするサブ工程も含み得る（図示せず）。デバイス１０に禁止設定が施されている場合、その禁止設定が（関連するデバイス１０が盗品であるなどの理由で）エージェントのリクエストにより施されたものかどうかを確認するようさらなるチェックが行われる。上記の事情が当てはまらない場合、ＩＶＲ３０は、内部フラグを設定することにより、デバイス１０がアクティブ化されていない旨を記録する。しかし、上述したように、デバイスのアクティブ化および禁止設定解除は可能である。とはいえ、禁止設定がエージェントのリクエストによるものである場合、それ以降の処理は禁止され得る。
【００２７】
デバイス１０のアクティブ化および後述する残高リフレッシュが正常に処理されると、ＩＶＲ３０はＣＳＳ５０に、関連するＭＳＩＳＤＮの呼び出し禁止設定を解除するよう命令する。次いで、ＣＳＳ５０は、ゲートウェイ１９１とインターフェースし、入来する呼び出し禁止設定を除去し、その結果、デバイス１０への入来ＳＭＳメッセージおよび電話呼び出しがイネーブルされる。ＮＢＡＳ１９０は継続的に持続することが不可能なため、デバイス１０をアクティブ化できるのは一日のうちほんの数時間に限られ得る。これは、システム１が禁止設定の解除を終えることが必要との旨のＮＢＡＳ１９０からの応答が、禁止設定解除リクエストが提出されてから数時間経過してからでないと配信できないためである。ＩＶＲ３０は、このアクティブ化の利用可能性を加入者に通知し、適切なメッセージを用いてアクティブ化を抑制する。このような場合、ＣＳＳ５０は、リクエストをキューに入れ、オンラインになったときにのみにリクエストをＮＢＡＳ１９０に送信する。ＮＢＡＳ１９０に設定リクエストが送信されると、ＣＳＳ５０は、そのリクエストが作用しているかどうかについての応答をポーリングする。ＣＳＳ５０は、加入者の現在のステータスを示す加入者データベース２３０内のフラグを（ＭＳＩＳＤＮを介して）維持する。
【００２８】
アクティブ化要素内で、ＣＳＳ５０は、図１に示すシステム１内のホームロケーションレジスタ（ＨＬＲ）２６０とインターフェースをとるＮＢＡＳ１９０を介して、デバイス１０の禁止設定を解除する。
【００２９】
アクティブ化の際、サービスプロバイダは、後述するＳＭＳサービスを用いて、電波を通じて料金表情報をデバイスに提供する。この料金表の更新は、後述するように、加入者が無線デバイスの残高をリフレッシュしようとするときにいつでも送信することができる。あるいは、サービスプロバイダも、料金表の更新情報を起動する必要があるときにいつでも更新を転送するＳＭＳメッセージを起動することができる。これにより、特にネットワークプロバイダが利用パターンの異なる様々な層のユーザをできるだけ多く獲得するために異なる料金パッケージを提示して価格競争が激化するにつれて、サービスプロバイダが料金設定において最大限の柔軟性を有することが可能となる。
【００３０】
残高リフレッシュ
図６は、残高リフレッシュプロセス（すなわち、利用可能な残高を増加させるプロセス）を示すフローチャートである。加入者は、無線デバイス１０、電話１５０、またはインターネットなどのネットワークを介して予めプログラムされた番号を発呼することにより、ＩＶＲ３０にアクセスする。本システムは、デバイス１０の利用可能残高が発呼に必要な要求された残高に足りなくなり得るときでも、加入者が予めプログラムされた番号を発呼することを可能にする。
【００３１】
予めプログラムされた番号が発呼されると、ＩＶＲ３０は、その発呼に応答し（工程６００）、デバイス１０のアクティブ化に用いられるアプリケーションに類似するアプリケーションを開始する。ＩＶＲ３０は、デバイス１０に関する情報（すなわち、ＭＳＩＳＤＮ）を収集および有効化する（工程６１０）。加入者は、利用可能残高を増加させるために、クレジット／デビットカードおよび／または以下に詳述するスクラッチカードを用い得る（工程６２０）。加入者は、１回の通話（ｐｈｏｎｅ  ｃａｌｌ）で、２つ以上のデバイス１０の利用可能残高を増加させ得（工程６６０）、２つ以上のクレジット／デビットカード、スクラッチカード、またはこれらのカードの任意の組み合せを用い得る。
【００３２】
スクラッチカードが認証されるか（工程６５０）、またはクレジット／デビットカード情報が収集されて（工程６４０）、加入者が実行する操作がそれ以上無い場合、通話が終了する（工程６７０）。
【００３３】
図７は、残高リフレッシュに関連するプロセスフローを示す。ＩＶＲ３０は、リクエストをキューに入れてバックグラウンド処理し得る。上記呼び出し中にスクラッチカードがオンラインで認証されているので、リクエストは、ＥＡＳ４０によりキューに入れられ、処理され得る（ブロック７００、７２０を参照）。クレジット／デビットカード情報は、まず最初に支払いクリアサービス（ＰＣＳ）２００を通じて認証されなければならない（ブロック７００〜ブロック７１０〜ブロック７３０〜ブロック７２０）。
【００３４】
暗号化プロセスは、例えばＴＣＰ／ＩＰソケット−ソケットプロトコルを用いて、ＥＡＳ４０とインターフェースすることができる。このプロセスでは、ＭＳＩＳＤＮおよび残高更新値をペアでＥＡＳ４０に送信する（ブロック７２０）。ＥＡＳ４０は、暗号化されたＳＭＳメッセージを返送し（工程７４０）、このメッセージはデバイス１０へと送信される。ＥＡＳ４０は、格納している他のＳＭＳメッセージ（例えば、通話料金表の変更リクエスト、利用可能残高の確認リクエスト）も返送し得る。ＥＡＳ４０は通常は、残高リフレッシュの際にＩＶＲ３０への情報返送を行うが、情報の返送は必要に応じて行うことができる。処理されたＥＡＳリクエストは全て、ＳＭＳメッセージによって、デバイス１０へと送信されるのを待機しているキューに入れられる（工程７５０）。将来の検査（ａｕｄｉｔｉｎｇ）に備えるため、各プロセスについて詳細な記録が記録される。
【００３５】
ＳＭＳ送信プロセスでは、ＳＭＳメッセージを意図する送信先への配信を操作する（ブロック７６０）。図３について上述したように、デバイス１０は、ＳＭＳ−ＭＴメッセージに応答して、返送ＳＭＳ−ＭＯメッセージを生成する。このＳＭＳプロセスでは、双方向のＳＭＳメッセージをモニタし、ＳＭＳ−ＭＯ返送メッセージが正常に受信されると、そのメッセージを処理済みとして印を付ける。このＳＭＳプロセスでは、より詳細には、ＳＭＳメッセージをＳＭＳＣ１８０を介して意図する送信先への配信を操作する。ＳＭＳＣ１８０は、低レベル応答を返送し、次いでデバイス１０が応答を返送する。次いで、デバイス１０は、デバイス１０内で残高リフレッシュが発生すると、残高リフレッシュ用のより高いレベルの応答を返送する。このＳＭＳ−ＭＯは、変化を受け得ない。所定の時間内に受信されたＳＭＳ−ＭＯメッセージが無い場合、ＳＭＳＣ１８０は、ＳＭＳメッセージをＩＶＲ３０へと返送する。、ＩＶＲ３０は、メッセージ内の不具合コードに応じて、再送信する残高リフレッシュＳＭＳメッセージを選択することができる。
【００３６】
クレジット／デビットカード認証
クレジット／デビットカードのインプリメンテーションにの具体例について以下に述べる。クレジット／デビットカードトランザクションの認証が遅れる可能性があるため、このプロセスは、ＩＶＲ３０と加入者との間の対話が終了した（工程６７０）後に実行することができる。加入者は、通話を終了する前に、利用可能残高がもうすぐ更新されるのでデバイス１０の電源を切らないようにとの旨を通知される。デバイス１０の電源がオフにされた場合、利用可能残高は、加入者がデバイス１０が電源をオンにするとすぐに更新される。
【００３７】
クレジット／デビットカードを用いて支払いをする場合、加入者は、クレジット／デビットカードに関する特定の情報を入力する必要がある。この情報は、カード番号、有効期限、発行番号（特定の種類のデビットカードのみ）、および所望の金額（ａｍｏｕｎｔ）を含む。この情報は、トランザクション認証されるクレジット／デビットカードキューに格納される（ブロック７１０）。クレジット／デビットカード認証用に行われるプロセスは、ＰＣＳ２００上の入力ドライブに必要な情報に基づいて加入者から収集した関連カード情報を収集する工程と、収集したデータを取得者（例えば、クレジット／デビットカードを提供した機関）に送信する工程とからなる（工程７３０）。
【００３８】
支払いクリア処理では、ＰＣＳ２００を用い、例えば加入者、カード発行者、売買業者、および売買業者のトランザクション取得者（取得者）を必要とする。１つの例示的な実施形態において、支払い認証についてのオンラインリクエストは、英国支払いクリアサービス協会（Ｕ．Ｋ．  Ａｓｓｏｃｉａｔｉｏｎ  ｆｏｒ  Ｐａｙｍｅｎｔ  Ｃｌｅａｒｉｎｇ  Ｓｅｒｖｉｃｅｓ、ＡＰＡＣＳ）規格により規定されたプロトコルを用いて、売買業者から取得者へと提出される。取得者は、そのリクエストを発行者へと転送し、発行者からの回答を売買業者へと返送する。認証されたトランザクションの日常的なバッチ処理は、例えばＡＰＡＣ−２９規格により規定された形式で取得者へと提出される。加入者は、売買業者の代理として動作するＩＶＲ３０を介して、クレジット／デビットカード情報を提示する。クレジット／デビットカードの詳細は、売買業者の代理として動作するＰＣＳ２００に転送される。
【００３９】
ＰＣＳ２００は、取得者とＡＰＡＣＳ−３０との間の対話を処理し、認証回答メッセージを返送する。この認証回答メッセージは、クレジット／デビットカード処理システムにより生成され、例えば、認証されるか、拒絶されるか、または照会されるかのいずれかの結果となり得る。加入者にとって、拒絶メッセージおよび照会メッセージは、利用可能残高が増えないため、実質的に同じ意味を有する。トランザクションが拒絶または照会されると、加入者はカード発行元に連絡するようにとの通知が行く。トランザクションが認証されると、ＭＳＩＳＤＮの詳細および利用可能残高がＥＡＳ４０キューへと送られ、これによりさらなる処理が行われる（ブロック７４０）。クレジット／デビットカード認証がオンラインで行われ、ＰＣＳ２００により認証されると、ＩＶＲ３０は、この情報をＣＳＳ５０へと送り、これにより、ＣＳＳ５０内で完全な検査追跡が行われる。加入者データベース２３０は特に、上述したように、このようなトランザクションの加入者履歴を全て保持する。
【００４０】
スクラッチカードのアクティブ化
サービスプロバイダは、スクラッチカードの生成、印刷、および小売業者への流通を行う。スクラッチカードは、パッケージ化される。小売業者は、スクラッチカードを加入者に販売する。スクラッチカードは、流通網にある間は、アクティブ化されないとシステム１上で使用することはできない。スクラッチカードをアクティブ化するには、小売業者はサービスプロバイダと連絡をとらなければならない。サービスプロバイダは、必要な情報（例えば、小売業者の識別番号、小売業者のセキュリティコード、およびパッケージの識別番号）を提供した後、スクラッチカードをアクティブ化する。
【００４１】
ＣＳＳ５０は、各スクラッチカードに関する詳細な記録を、上述したスクラッチカードデータベース２４０内に保持する。また、ＣＳＳ５０は、スクラッチカードが再利用されることがないよう、全てのスクラッチカードの利用を追跡する。加入者が利用可能残高を増加させるために発呼すると、ＣＳＳ５０は、スクラッチカードの有効性を確認し、それ以上の認証は必要ない。加えて、ＩＶＲ３０は、スクラッチカードの記録をデバイス１０から直接収集し、収集した記録をＣＳＳ５０へと送り、これにより有効性のマッチングが行われる。
【００４２】
スクラッチカードが有効化されると、ＩＶＲ３０は加入者との通話を終了し、ＭＳＩＳＤＮおよび残高更新値をＤＡＳキューに送り、これにより、さらなる処理が行われる（ブロック７２０）。ＣＳＳ５０は、スクラッチカードデータベース２４０においてスクラッチカードに「使用済み」の印を付け、加入者データベース２３０を更新して全ての加入者履歴を維持する。
【００４３】
デバイス禁止設定／中断
デバイス１０に、呼び出し禁止設定をかけるか、または完全に呼び出しを中断することが可能である。これらの操作は、ＩＶＲ３０により自動的に行うか、またはエージェントにより手動で行うことができる。エージェントは、ＩＶＲ３０サポート機能にアクセスして、ＩＶＲ３０内のバックグラウンドタスクを起動してＣＳＳ５０に特定のＭＳＩＳＤＮに入来する呼び出しを禁止設定するようリクエストすることができる。ＣＳＳ５０は、ＮＢＡＳ１９０とインターフェースし、呼び出し禁止設定コマンドを発行し、これにより、入来するＳＭＳメッセージならびにデバイス１０による電話通信被呼および電話通信発呼を中断することができる。
【００４４】
呼び出しセンタ１６５のエージェント
本発明によるシステム１は、上述したＩＶＲ３０を用いて自動的に機能するか、またはサービスプロバイダのエージェントの助けを得て手動で機能することができる。エージェントは、呼び出しセンタ１６５内に配置され、電話通信インターフェース１６０および／またはワークステーションインターフェース１７０を有する。エージェントは、類似のプロセスを行うことにより、ＩＶＲ３０を補充する。例えば、エージェントはデバイス１０をアクティブ化し、クレジット／デビットカードおよび／またはスクラッチカードを用いて利用可能残高を増やし、加入者からの一般的な問合せに応答する。
【００４５】
エージェントは、ＩＶＲ３０と同様に、スクラッチカードおよび／またはクレジット／デビットカードを用いて預け入れ額を転送することができる。エージェントは、必要な機能を行うためにプロセスへアクセスする信任を得ているため、呼び出しセンタ１６５内のエージェントにより不正が行われる可能性がある。プロセス内の検査履歴は、この可能性を認識し、これらのプロセスへのインターフェースがセキュアかつ検査済みであることを保証する。エージェントを保護するために、異なるレベルのアクセスと個人識別番号（ＰＩＮ）とが必要である。
【００４６】
エージェントの場合、以下に述べるワークキューモデルを用いることもできる。ワークキューモデルのプロセスは、ＩＶＲ３０内のプロセスと同じである。ワークキューモデルは、エージェント自身の入力ワークキューおよびエージェント自身の出力ワークキューに対するサブプロセスを行うタスクの閲覧を制限する。サブプロセスを行うタスクは、それ自身の前に発生するサブプロセスについての情報をなにも有さない。これは、従って、異なるプラットフォームで動作する異なるサブプロセスがタスクの入力ワークキューにデータを配置するために共通の構造へのアクセスを有しかつ共有するとシンすると、これらのサブプロセスは全て、タスクに先行することを意味する。
【００４７】
図８は、プロセスを制御するのにＩＶＲ３０の代わりに呼び出しセンタ１６５を用いる点以外は図７で述べたリフレッシュ操作に類似するリフレッシュ操作に関連するプロセスフローを示す。エージェントは、ワークデータを１つ以上のキューに配置する（ブロック７１０、７２０、および７５０）。これは、プロセスを一個所のみで定義するため、プロセスの完全性を保証する。加えて、複数のエージェントタスクが入力キューに書き込まれ、入力ワークキューの読み取りおよび出力ワークキューへの書込みを行うサブプロセスタスクが複数発生する可能性があるため、複数のユーザを処理する能力を有するキュー管理システムを用いる必要がある。
【００４８】
フルファイル機構および記録ロック機構を備え、データベース表を用いてキューをインプリメントするのに最適なシステムは、（例えば、Ｏｒａｃｌｅ  ＣｏｒｐｏｒａｔｉｏｎまたはＳｙｂａｓｅの）リレーショナルデータベースである。ＩＶＲ３０は、これらのデータベースの読み出しおよび書込みを行うことができ、エージェントのアプリケーションは、例えば上記のデータベースの読み出しおよび書込み能力も有する従来のプログラミング言語を用いて書込まれる。エージェントにより実行されるアクティビティは全て、厳正な検査を受ける。ワークキューを通過して処理されるトランザクションの各々に、日付／時間およびエントリをＩＶＲ３０ポートを含むワークキュー内のエントリに配置するエージェントのログイン識別１０が刻印される。
【００４９】
エージェントのアプリケーションは、図９に示すシン（ｔｈｉｎ）クライアント９００として開発することができる。シンクライアント９００とは、一般的に最速の開発方法として考えられているアプリケーション開発方法である。シンクライアント９００は典型的には、ウェブサーバ９１０を用いて情報サーバ９２０へと接続する。アプリケーションサーバ９２０は、他の情報サーバにアクセスすることによりシンクライアント９００の代理としてリクエストを処理し、応答をシンクライアント９００に返送する。シンクライアント９００のインターフェースは、ハイパーテキストマークアップ言語（ＨＴＭＬ）または他の任意の従来からのプログラミング言語を用いて開発することができる。エージェントのアプリケーションについては、情報サーバ９２０が既にＩＶＲ３０内の存在する。
【００５０】
ＩＶＲ３０を開発することのできるブライト音声書込み−１（Ｂｒｉｔｅ  Ｖｏｉｃｅ’ｓ  Ｗｒｉｔｅ−１）ソフトウェア環境は、ウェブサーバ９１０をサポートする拡張部を有し、図１０は、これを示す。ソフトウェアバス９３５の書込み−１ソフトウェアアーキテクチャモデルは、ウェブサーバ９１０がソフトウェアバス９３５を用いてソフトウェアバス９３５上の他の構成要素と通信することを可能にする。これは、ウェブサーバ９１０が同じＩＶＲ３０サブプロセスを実行し、同じ情報にアクセスし、「ワークキュー」の集中管理を行うことを可能にする。
【００５１】
エージェントのワークステーションは、従来のウェブブラウザ（例えば、Ｎｅｔｓｃａｐｅ  ＣｏｒｐｏｒａｔｉｏｎのＮｅｔｓｃａｐｅ（登録商標）  Ｖｅｒｓｉｏｎ  ４）を用いることができる。開発言語としては、例えば、データベースサーバ９８０にアクセスするＨＴＭＬおよび書込み−１シナリオ生成言語（ＳＧＬ）があり得る。ウェブブラウザからのリクエストは、ウェブサーバ９１０からソフトウェアバス９３５上のウェブ構成要素９３０へと方向付けられ、ＳＧＬサブプロセス９４０を動作させ、これにより、データベース９６０の読み取りおよび書込みが行われる。
【００５２】
上述したシステムは、プリペイド無線デバイスの操作を容易にする構成を提供する。この構成は、加入者の機器の残高をリフレッシュし、料金予定を更新するプロセスを簡単化する。
【００５３】
本明細書中、本発明のいくつかの例示的な実施形態を具体的に図示および／または説明したが、本発明の変形および改変が、上記の教示内容に含まれ、本発明の精神および意図された範囲から逸脱することなく添付の特許請求の範囲内に含まれることが理解される。
【図面の簡単な説明】
【００５４】
【図１】図１は、本発明によるシステムの例示的な実施形態を示す。
【図２】図２は、本発明による無線プリペイドデバイスの例示的な実施形態を示す。
【図３】図３は、ショートメッセージサービスプロセスを示す図である。
【図４】図４は、キューを処理するソフトウェアモデルの例示的な実施形態を示す。
【図５】図５は、アクティブ化プロセスの実行を示すフローチャートである。
【図６】図６は、利用可能残高をリフレッシュするプロセスを示すフローチャートである。
【図７】図７は、双方向音声応答システムを用いた残高リフレッシュ操作に関するプロセスフローを示す。
【図８】図８は、顧客サービスエージェントを用いた残高リフレッシュ操作のプロセスフローを示す。
【図９】図９は、シンクライアントとして開発されたエージェントのアプリケーションを示す。
【図１０】図１０は、図９の改変例を示す。
【図１】
2006340385.tif 000003
【図２】
2006340385.tif 000004
【図３】
2006340385.tif 000005
【図４】
2006340385.tif 000006
【図５】
2006340385.tif 000007
【図６】
2006340385.tif 000008
【図７】
2006340385.tif 000009
【図８】
2006340385.tif 000010
【図９】
2006340385.tif 000011
【図１０】
2006340385.tif 000012