(57)【要約】      （修正有）【課題】ネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供。【解決手段】ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、前記サービスが課金対象である場合、前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供。【選択図】図１
2010081614.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークを介して移動商取引サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、
前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供し、
前記サービスを提供するために、前記有効ユーザアカウントから課金する
ことを特徴とする方法。
【請求項２】
複数のネットワークを介して移動商取引サービスを提供する装置であって、
サービスのリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからの前記サービスの料金を含み、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証する検証部と、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を送信する送信部と、
前記サービスを提供するために、前記有効ユーザアカウントから課金する課金部を
を備えることを特徴とする装置。
【請求項３】
複数のネットワークを介してプリペイドローミング通信サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及び宛先装置番号を受信し、
前記識別番号及び前記宛先装置番号に、サービスプロバイダ識別番号及びローミング通信サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が有効ユーザ情報に関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っている場合、前記ローミングネットワークに認可を提供し、
前記サービスを提供するために、前記有効ユーザアカウントから課金し、
前記ユーザアカウント残高が所定レベルに達する場合、信号を送信する
ことを特徴とする方法。
【請求項４】
前記信号は、サービス停止、中断、再入金リクエスト及び少残高警告の少なくとも１つである
ことを特徴とする請求項３に記載の方法。
【請求項５】
複数のネットワークを介してプリペイドローミング通信サービスを提供する装置であって、
サービスのリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号及び宛先装置番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからのサービスの料金を含み、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記ローミングネットワーク上の前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証する検証部と、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を送信し、かつ前記ユーザアカウントが所定レベルに達する場合、信号を送信する送信部と、
前記サービスを提供するために、前記有効ユーザアカウントから課金する課金部を
を備えることを特徴とする装置。
【請求項６】
前記サービスを前記ユーザへ提供する比率を判定する判定部を更に備え、
前記課金部は、前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザアカウントから課金する
ことを特徴とする請求項５に記載の装置。
【請求項７】
前記信号は、サービス停止、中断、再入金リクエスト及び少残高警告の少なくとも１つである
ことを特徴とする請求項５に記載の装置。
【請求項８】
複数の独立ネットワークを介して、ネットワーク独立型消費者ケアサービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及び消費者ケアサービスリクエストを受信し、
前記識別番号及び前記消費者ケアサービスリクエストに、サービスプロバイダ識別番号を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連していることを検証し、
前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に前記消費者ケアサービスを接続する
ことを特徴とする方法。
【請求項９】
前記消費者ケアサービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項８に記載の方法。
【請求項１０】
更に、前記有効ユーザアカウントが再入金メカニズムを承認していることを判定し、
前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する
ことを特徴とする請求項８に記載の方法。
【請求項１１】
更に、前記サービスプロバイダ識別番号を記憶する
ことを特徴とする請求項８に記載の方法。
【請求項１２】
複数のネットワークを介して、消費者ケアサービスを提供する装置であって、
消費者ケアサービスのリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号と、前記ローミングネットワークからのサービスプロバイダに関連するサービスプロバイダ識別番号を含み、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記消費者ケアサービスを受信するために認可されていることを検証する検証部と、
前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に、前記消費者ケアサービスを提供することができる消費者ケアサービスプロバイダを接続する接続部と
を備えることを特徴とする装置。
【請求項１３】
前記消費者ケアサービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項１２に記載の装置。
【請求項１４】
前記有効ユーザアカウントが再入金メカニズムを承認していることを判定する判定部と、
前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する再入金部と
を更に備えることを特徴とする請求項１２に記載の装置。
【請求項１５】
集中通信プラットホームを介して提供されるサービスに対するプリペイドアカウントに再入金する方法であって、
前記集中通信プラットホームに配置されている消費者アカウントを使用するための認可用のユーザ識別番号を含むリクエストを、ユーザ装置から受信し、
前記ユーザ識別番号に関連する消費者アカウントが、提供対象のサービスに対して十分な残高を持っていないことを判定し、
前記消費者アカウントが認可済の再入金メカニズムを持っていることを判定し、
前記認可済の再入金メカニズムを使用して、前記消費者アカウントに再入金し、
前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用を認可する
ことを特徴とする方法。
【請求項１６】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及びデータダウンロードの少なくとも１つである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記集中通信プラットホームがホームネットワークに存在する場合には、前記受信は、ローミングネットワークから行う
ことを特徴とする請求項１５に記載の方法。
【請求項１８】
集中通信プラットホームを介して提供対象のサービスに対するプリペイドアカウントに再入金する装置であって、
前記集中通信プラットホームに配置されている消費者アカウントを使用するための識別番号を含む認可リクエストを、ユーザ装置から受信する受信部と、
前記識別番号に関連する消費者アカウントが、提供対象のサービスに対して十分な残高を持っておらず、かつ前記消費者アカウントが再入金メカニズムを認可していることを判定する判定部と、
前記再入金メカニズムを使用して、前記消費者アカウントに再入金する再入金部と、
前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用の認可を送信する送信部と
を備えることを特徴とする装置。
【請求項１９】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及びデータダウンロードの少なくとも１つである
ことを特徴とする請求項１８に記載の装置。
【請求項２０】
前記集中通信プラットホームがホームネットワークに存在する場合には、前記ユーザ装置は、ローミングネットワークに存在する
ことを特徴とする請求項１８に記載の装置。
【請求項２１】
集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う方法であって、
リアルタイムで、複数のネットワークを介して提供される取引に対する有効ユーザアカウントから料金を課金し、
前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定し、
前記判定された料金に従って、前記複数のネットワークを介して前記プリペイド取引に対する前記プロバイダとの決済を行う
ことを特徴とする方法。
【請求項２２】
前記取引は、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２１に記載の方法。
【請求項２３】
更に、前記有効ユーザアカウントが十分な残高を持っていないことを判定し、
前記有効ユーザアカウントが再入金メカニズムを認可していることを判定し、
前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する
ことを特徴とする請求項２１に記載の方法。
【請求項２４】
更に、前記取引及び前記複数のプロバイダそれぞれに対するプロバイダ識別番号を記憶する
ことを特徴とする請求項２１に記載の方法。
【請求項２５】
集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う装置であって、
リアルタイムで、複数のネットワークを介して提供される取引に対するユーザアカウントから課金する課金部と、
前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定する判定部と、
前記判定された料金に従って、前記複数のネットワークを介して前記プリペイド取引に対する前記プロバイダとの決済を行う送信部と
を備えることを特徴とする装置。
【請求項２６】
前記取引は、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２５に記載の装置。
【請求項２７】
前記取引及び前記複数のプロバイダそれぞれに対するプロバイダ識別番号を記憶する記憶部を更に備える
ことを特徴とする請求項２５に記載の装置。
【請求項２８】
複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、
前記サービスが課金対象である場合、前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供し、
前記サービスが課金対象である場合、前記サービスを提供するために、リアルタイムで前記有効ユーザアカウントから課金する
ことを特徴とする方法。
【請求項２９】
前記ローミングネットワークは、無線ネットワーク、シンプルメッセージングサービスネットワーク、公衆交換電話ネットワーク、パケット交換ネットワーク、回線交換ネットワーク、非同期ネットワーク、インターネット、イントラネット、マイクロ波ネットワーク、ケーブルネットワーク、イーサネットネットワーク、トークンリングネットワーク及びワイドエリアネットワークの少なくとも１つである
ことを特徴とする請求項１、３、８あるいは２８のいずれか１項に記載の方法。
【請求項３０】
前記ローミングネットワークは、異なるシグナリングプロトコルを利用する、ホームネットワーク以外の異なるエンティティの少なくとも１つによって制御され、かつ異なる位置に配置されている
ことを特徴とする請求項８あるいは２８に記載の方法。
【請求項３１】
前記ユーザ装置は、無線電話、有線電話、モデム、コンピュータ、パーソナルデジタルアシスタント、ページャー、セルラー電話及び無線送信機の少なくとも１つである
ことを特徴とする請求項１、３、８、１５あるいは２８のいずれか１項に記載の方法。
【請求項３２】
前記識別番号は、個人識別番号、加入者識別モジュール、国際移動体加入者識別子、国際移動局端末識別子、アルファベット及び数字の組み合わせ、及び１６進数の少なくとも１つである
ことを特徴とする請求項１、３、８、１５あるいは２８のいずれか１項に記載の方法。
【請求項３３】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスの購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３４】
前記サービスプロバイダは、前記サービスの料金の一部をそれぞれが受信する複数のビジネスを含んでいる
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３５】
更に、前記サービスプロバイダに課金額を送信する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３６】
更に、前記有効ユーザアカウントが十分な残高を持っていないことを判定し、
前記有効ユーザアカウントが再入金メカニズムを認可していることを判定し、
前記再入金メカニズムを使用して、前記ユーザアカウントに再入金する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３７】
更に、ユーザ介入後に、前記有効ユーザアカウントが前記再入金メカニズムを認可していることを判定し、
再入金の認可を要求する前記ローミングネットワークで、前記ユーザ装置と接続し、
前記ユーザ装置が、再入金の認可の要求に正しく応答する場合、前記再入金を認可する
ことを特徴とする請求項３６に記載の方法。
【請求項３８】
前記再入金は、アカウント、金額及び資金源の少なくとも１つを特定するユーザ定義ルールに基づいている
ことを特徴とする請求項３６に記載の方法。
【請求項３９】
前記ユーザ定義ルールは、アカウント、過去の再入金、アカウント残高及び時間の少なくとも１つに基づく再入金優先度で、複数のアカウントを特定する
ことを特徴とする請求項３８に記載の方法。
【請求項４０】
前記再入金は、銀行アカウント、投資アカウント、クレジットアカウント及び認可済ローンアカウントの少なくとも１つから再入金を行う
ことを特徴とする請求項３６に記載の方法。
【請求項４１】
更に、前記課金及び前記サービスプロバイダ識別番号を記憶する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項４２】
前記ローミング通信サービスの料金は、ローミング料金、サービス配信料金、通信料金、税金、設備使用追加料金、ディスカウント及び保険料金の少なくとも１つである
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項４３】
更に、前記サービスを前記ユーザへ提供する比率を判定し、
前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザーアカウントから課金する
ことを特徴とする請求項３あるいは２８に記載の方法。
【請求項４４】
前記比率は、ローミングネットワーク比率、ホームネットワーク比率、通信比率、長距離比率、国際比率、税金率、設備使用追加料金比率、ディスカウント比率及び保険料金比率の少なくとも１つである
ことを特徴とする請求項２８に記載の方法。
【請求項４５】
複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する装置であって、
サービスがローミングネットワークからの課金対象である場合、ユーザ装置からの識別番号、サービスリクエスト、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を受信する受信部と、
前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連しているか、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っているかを判定する判定部と、
前記サービスが課金対象である場合、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供する送信部と、
前記サービスが課金対象である場合、前記サービスを提供するために、リアルタイムで前記有効ユーザアカウントから課金する課金部と
を備えることを特徴とする装置。
【請求項４６】
前記ローミングネットワークは、無線ネットワーク、シンプルメッセージングサービスネットワーク、公衆交換電話ネットワーク、パケット交換ネットワーク、回線交換ネットワーク、非同期ネットワーク、インターネット、イントラネット、マイクロ波ネットワーク、ケーブルネットワーク、イーサネットネットワーク、トークンリングネットワーク及びワイドエリアネットワークの少なくとも１つである
ことを特徴とする請求項２、５、１２あるいは４５のいずれか１項に記載の装置。
【請求項４７】
前記ローミングネットワークは、異なるシグナリングプロトコルを利用する、ホームネットワーク以外の異なるエンティティの少なくとも１つによって制御され、かつ異なる位置に配置されている
ことを特徴とする請求項１２あるいは４５に記載の装置。
【請求項４８】
前記ユーザ装置は、無線電話、有線電話、モデム、コンピュータ、パーソナルデジタルアシスタント、ページャー、セルラー電話及び無線送信機の少なくとも１つである
ことを特徴とする請求項２、５、１２、１８あるいは４５のいずれか１項に記載の装置。
【請求項４９】
前記識別番号は、個人識別番号、加入者識別モジュール、国際移動体加入者識別子、国際移動局端末識別子、アルファベット及び数字の組み合わせ、及び１６進数の少なくとも１つである
ことを特徴とする請求項２、５、１２、１８あるいは４５のいずれか１項に記載の装置。
【請求項５０】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスの購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５１】
前記サービスプロバイダは、前記サービスの料金の一部をそれぞれが受信する複数のビジネスを含んでいる
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５２】
前記送信機は、更に、前記サービスプロバイダに課金額を送信する
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５３】
前記有効ユーザアカウントが十分な残高を持っていないこと、かつ前記有効ユーザアカウントが再入金メカニズムを認可していることを判定する判定部と、
前記再入金メカニズムを使用して、前記ユーザアカウントに再入金する再入金部と
を更に備えることを特徴とする請求項２、５、２５あるいは４５のいずれか１項に記載の装置。
【請求項５４】
ユーザ介入後に、前記有効ユーザアカウントが前記再入金メカニズムを認可していることを判定する判定部と、
前記ローミングネットワークの前記ユーザ装置へ、再入金の認可リクエストを送信する送信部と、
前記ユーザ装置が、前記再入金の認可リクエストに正しく応答する場合、前記再入金を認可する認可部と
を更に備えることを特徴とする請求項５３に記載の方法。
【請求項５５】
前記再入金は、アカウント、金額及び資金源の少なくとも１つを特定するユーザ定義ルールに基づいている
ことを特徴とする請求項５３に記載の装置。
【請求項５６】
前記ユーザ定義ルールは、アカウント、過去の再入金、アカウント残高及び時間の少なくとも１つに基づく再入金優先度で、複数のアカウントを特定する
ことを特徴とする請求項５５に記載の装置。
【請求項５７】
前記再入金部は、銀行アカウント、投資アカウント、クレジットアカウント及び認可済ローンアカウントの少なくとも１つから再入金を行う
ことを特徴とする請求項５３に記載の装置。
【請求項５８】
課金額及び前記サービスプロバイダ識別番号を記憶する記憶部
を更に備えることを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５９】
前記ローミング通信サービスの料金は、ローミング料金、通信料金、税金、設備使用追加料金、ディスカウント及び保険料金の少なくとも１つである
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項６０】
前記判定部は、更に、前記サービスを前記ユーザへ提供する比率を判定し、かつ前記課金部は、前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザーアカウントから課金する
ことを特徴とする請求項４５に記載の装置。
【請求項６１】
前記比率は、ローミングネットワーク比率、ホームネットワーク比率、通信比率、長距離比率、国際比率、税率、設備使用追加料金比率、ディスカウント比率及び保険料金比率の少なくとも１つである
ことを特徴とする請求項４５に記載の装置。
【請求項６２】
ルールセットを採用する集中通信方法であって、
認可済ユーザに対して、取引の認可及び前記認可済ユーザのアカウントの課金時に利用可能な少なくとも１つのルールを判定し、
前記取引の認可に対し、前記少なくとも１つのルールを適用し、
前記取引が認可される場合、リアルタイムで、アカウントから課金するために、前記少なくとも１つのルールに従って、前記アカウントから課金し、
少なくとも１つの決済ルールに従って、複数の取引プロバイダに対して、リアルタイム課金を決済する
ことを特徴とする方法。
【請求項６３】
更に、前記認可済ユーザが、前記取引に対する課金を行うための認可済ユーザアカウントに十分な金額を持っていないことを判定し、
再入金ルーチンの完了後、前記認可済ユーザアカウントに再入金し、
前記再入金ルーチンは、
送金するための再入金ユーザアカウントを判定し、
前記認可済ユーザからの事前認可済送金の参照及び認可の要求の少なくとも１つによって前記送金を認可する
ことを特徴とする請求項６２に記載の方法。
【請求項６４】
前記再入金は、複数の再入金ユーザアカウントを利用して実行される
ことを特徴とする請求項６３に記載の方法。
【請求項６５】
前記認可済ユーザからの前記認可の要求は、ユーザＰＩＮの要求、手動エントリの要求、ユーザパスフレーズの要求及び生体測定手段を介するユーザ識別子の確認の少なくとも１つである
ことを特徴とする請求項６３に記載の方法。
【請求項６６】
前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項６２に記載の方法。
【請求項６７】
前記適用は、前記取引を認可するための複数のルールを利用して実行され、前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項６２に記載の方法。
【請求項６８】
前記決済は、即時、３日後、カレンダー月の末、定期的な期間及び一連の分割払日の少なくとも１つで発生する
ことを特徴とする請求項６２に記載の方法。
【請求項６９】
前記取引の認可に対し、前記少なくとも１つのルールを適用することは、ＰＩＮ、手動エントリ、ユーザパスフレーズ及び生体測定手段を介するユーザ識別子の確認の少なくとも１つを使用する前記取引の認可を含む
ことを特徴とする請求項６２に記載の方法。
【請求項７０】
更に、アルゴリズムに従って、取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記アルゴリズムは、当該アルゴリズムの機能である前記取引認可リクエストのタイミングを含んでいる
ことを特徴とする請求項６２に記載の方法。
【請求項７１】
更に、時系列イベントに関連するデータのソースからの入力を使用するアルゴリズムに従う取引認可リクエストの発行時に、リアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮される
ことを特徴とする請求項６２に記載の方法。
【請求項７２】
前記時系列イベントは、認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果である
ことを特徴とする請求項７１に記載の方法。
【請求項７３】
更に、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時に、リアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮され、かつ利用可能な時系列データの内容は定常的に変更される
ことを特徴とする請求項６２に記載の方法。
【請求項７４】
前記時系列イベントは、認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果である
ことを特徴とする請求項７３に記載の方法。
【請求項７５】
前記取引が要求され、かつ前記複数の取引プロバイダへの接続は、異種ネットワークにまたがっている
ことを特徴とする請求項６２に記載の方法。
【請求項７６】
前記課金は、メンバーシップが現状通りであるかのチェック、飛行マイルの減少あるいは増加、クレジット契約の増加あるいは減少、契約の記録の少なくとも１つである
ことを特徴とする請求項６２に記載の方法。
【請求項７７】
集中通信システムのアカウントにアクセスするユーザ入力装置であって、
認可済ユーザアカウントへアクセスし、かつアカウントマネージャーから取引を要求するために、前記集中通信システムへ送信する送信部と、
前記アカウントマネージャーは、
認可済ユーザに対し、取引を認可し、かつアカウントから課金する時点で利用可能な少なくとも１つのルールを判定する判定部と、
前記取引を認可するために、前記少なくとも１つのルールを適用するプロセッサと、
前記取引が認可される場合に、リアルタイムで、アカウントから課金するための前記少なくとも１つのルールに従って、前記アカウントから課金する課金部と、
少なくとも１つの決済ルールに従って、複数の取引プロバイダに対してリアルタイム課金を決済する決済部とを備え、
前記認可済ユーザアカウントへアクセスする前記アカウントマネージャーからの確認、認可済ユーザアカウントからの課金の確認及び決済の通知の少なくとも１つを受信する受信部と
を備えることを特徴とするユーザ入力装置。
【請求項７８】
前記アカウントマネージャーは、更に、
前記認可済ユーザが、前記取引に対して課金する認可済ユーザアカウントに十分な金額を持っていないことを判定する判定部と、
再入金ルーチンの完了後、前記認可済ユーザアカウントに再入金する再入金部とを備え、
前記再入金ルーチンは、
送金するための再入金ユーザアカウントを判定し、
前記認可済ユーザからの事前認可済送金の参照及び認可の要求の少なくとも１つによって前記送金を認可する
ことを特徴とする請求項７７に記載の装置。
【請求項７９】
前記再入金は、複数の再入金ユーザアカウントを利用して実行される
ことを特徴とする請求項７８に記載の装置。
【請求項８０】
前記認可済ユーザからの前記認可の要求は、ユーザＰＩＮの要求、手動エントリの要求、ユーザパスフレーズの要求及び生体測定手段を介するユーザ識別子の確認の少なくとも１つである
ことを特徴とする請求項７８に記載の装置。
【請求項８１】
前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項７７に記載の装置。
【請求項８２】
前記適用は、前記取引を認可するための複数のルールを利用して実行され、前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項７７に記載の装置。
【請求項８３】
前記決済は、即時、３日後、カレンダー月の末、定期的な期間及び一連の分割払日の少なくとも１つで発生する
ことを特徴とする請求項７７に記載の装置。
【請求項８４】
前記取引の認可に対し、前記少なくとも１つのルールを適用することは、ＰＩＮ、手動エントリ、ユーザパスフレーズ及び生体測定手段を介するユーザ識別子の確認の少なくとも１つを使用する前記取引の認可を含む
ことを特徴とする請求項７７に記載の装置。
【請求項８５】
更に、アルゴリズムに従って、取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記アルゴリズムは、当該アルゴリズムの機能である前記取引認可リクエストのタイミングを含んでいる
ことを特徴とする請求項７７に記載の装置。
【請求項８６】
更に、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮される
ことを特徴とする請求項７７に記載の装置。
【請求項８７】
前記時系列イベントは、認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果である
ことを特徴とする請求項８６に記載の装置。
【請求項８８】
更に、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮され、かつ利用可能な時系列データの内容は定常的に変更される
ことを特徴とする請求項７７に記載の装置。
【請求項８９】
前記時系列イベントは、認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果である
ことを特徴とする請求項８８に記載の装置。
【請求項９０】
前記ユーザ入力装置は、コンピュータ、電話、セルラー電話、コンピュータ、ポイントオブセールス装置及びＭＰ３プレーヤーの少なくとも１つである
ことを特徴とする請求項８８に記載の装置。
【請求項９１】
前記取引が要求され、かつ前記複数の取引プロバイダへの接続は、異種ネットワークにまたがっている
ことを特徴とする請求項７７に記載の装置。
【請求項９２】
前記課金額は、メンバーシップが現状通りであるかのチェック、飛行マイルの減少あるいは増加、クレジット契約の増加あるいは減少、契約の記録の少なくとも１つである
ことを特徴とする請求項７７に記載の装置。
【請求項９３】
ルールセットを採用する集中通信システムであって、
認可済ユーザに対し、取引を認可し、かつ前記認可済ユーザのアカウントから課金する時点で利用可能な少なくとも１つのルールを判定する判定部と、
前記取引を認可するために、前記少なくとも１つのルールを適用するプロセッサと、
前記取引が認可される場合に、リアルタイムで、アカウントから課金するための前記少なくとも１つのルールに従って、前記アカウントから課金する課金部と、
少なくとも１つの決済ルールに従って、複数の取引プロバイダに対してリアルタイム課金を決済する決済部と
を備えることを特徴とする集中通信システム。
【請求項９４】
前記認可済ユーザが、前記取引に対して課金する認可済ユーザアカウントに十分な金額を持っていないことを判定する判定部と、
再入金ルーチンの完了後、前記認可済ユーザアカウントに再入金する再入金部とを備え、
前記再入金ルーチンは、
送金するための再入金ユーザアカウントを判定し、
前記認可済ユーザからの事前認可済送金の参照及び認可の要求の少なくとも１つによって前記送金を認可する
ことを特徴とする請求項９３に記載の集中通信システム。
【請求項９５】
前記適用は、前記取引を認可するための複数のルールを利用して実行され、前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項９３に記載の集中通信システム。
【請求項９６】
更に、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮される
ことを特徴とする請求項９３に記載の集中通信システム。
【請求項９７】
更に、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮され、かつ利用可能な時系列データの内容は定常的に変更される
ことを特徴とする請求項９３に記載の集中通信システム。
【請求項９８】
ルールセットを採用する集中通信システムであって、
現時点での取引を認可し、課金し、決済するための複数のルールをリアルタイムで判定する判定部と、
認可済ユーザのアカウントあるいは前記認可済ユーザが、現時点の取引を認可するための前記複数のルールと合っている場合、前記取引を認可する認可部と、
前記認可済ユーザのアカウントをリアルタイムで課金し、少なくとも１つの取引プロバイダアカウントに返金する課金部と、
前記取引を決済するための前記少なくとも１つのルールに従って、前記取引を決済する決済部と
を備えることを特徴とする集中通信システム。
【請求項９９】
前記認可済ユーザが、前記取引に対して課金する認可済ユーザアカウントに十分な金額を持っていないことを判定する第２判定部と、
再入金ルーチンの完了後、前記認可済ユーザアカウントに再入金する再入金部とを更に備え、
前記再入金ルーチンは、
送金するための再入金ユーザアカウントを判定し、
前記認可済ユーザからの事前認可済送金の参照及び認可の要求の少なくとも１つによって前記送金を認可する
ことを特徴とする請求項９８に記載の集中通信システム。
【請求項１００】
前記再入金は、複数の再入金ユーザアカウントを利用して実行される
ことを特徴とする請求項９４あるいは９８に記載の集中通信システム。
【請求項１０１】
前記認可済ユーザからの前記認可の要求は、ユーザＰＩＮの要求、手動エントリの要求、ユーザパスフレーズの要求及び生体測定手段を介するユーザ識別子の確認の少なくとも１つである
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１０２】
前記課金は、アカウントから課金するための複数のルールを利用して実行され、かつ前記決済は、複数の決済ルールを利用して実行される
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１０３】
前記認可部は、前記取引を認可するための複数のルールを利用し、前記課金部は、アカウントから課金するための複数のルールを利用し、かつ前記決済部は、複数の決済ルールを利用する
ことを特徴とする請求項９８に記載の集中通信システム。
【請求項１０４】
前記決済は、即時、３日後、カレンダー月の末、定期的な期間及び一連の分割払日の少なくとも１つで発生する
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１０５】
前記取引の認可に対し、前記少なくとも１つのルールを適用することは、ＰＩＮ、手動エントリ、ユーザパスフレーズ及び生体測定手段を介するユーザ識別子の確認の少なくとも１つを使用する前記取引の認可を含む
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１０６】
更に、アルゴリズムに従って、取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定し、前記アルゴリズムは、当該アルゴリズムの機能である前記取引認可リクエストのタイミングを含んでいる
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１０７】
時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定する判定部と、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮される
ことを特徴とする請求項９８に記載の集中通信システム。
【請求項１０８】
時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールを判定する判定部を更に備え、前記ルールは、前記取引認可リクエストとの関係を持っていることが考慮され、かつ利用可能な時系列データの内容は定常的に変更される
ことを特徴とする請求項９８に記載の集中通信システム。
【請求項１０９】
前記時系列イベントは、認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果である
ことを特徴とする請求項９６、９７、１０７あるいは１０８のいずれか１項に記載の集中通信システム。
【請求項１１０】
前記取引が要求され、かつ前記複数の取引プロバイダへの接続は、異種ネットワークにまたがっている
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【請求項１１１】
前記課金部は、メンバーシップが現状通りであるかのチェック、飛行マイルの減少あるいは増加、クレジット契約の増加あるいは減少、契約の記録の少なくとも１つによって課金する
ことを特徴とする請求項９３あるいは９８に記載の集中通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願のクロスリファレンス
本願は、２００２年３月１４日に出願されている米国特許出願番号１０／０９６９１２の特徴を請求項で示しており、この米国特許出願番号は、２００１年１月２９に出願されている米国特許出願番号０９／８９４８９０の一部継続出願であり、その内容と本明細書の内容は相互に参照される。
【０００２】
本発明は、世界中の個人消費者及び企業消費者にサービスを提供する集中通信システムに関するものである。より詳しくは、本発明は、既存の通信スイッチに構成される特定のハードウェアを用いずに、その既存通信スイッチを介して移動体商取引、電子商取引及び通信サービスを提供する集中通信システムに関するものである。このシステムは、消費者の位置に関係なく、広範囲の改良型通信サービスを提供するために、異種ネットワークにまたがるプリペイド及びポストペイドアカウントの使用をサポートする。
【背景技術】
【０００３】
前もってサービスに対し支払を行うこと（プリペイド）、また、サービスに対しクレジットアカウントを確立すること（ポストペイド）が知られている。ポストペイドアカウントは、消費者のクレジット資産に基づいて確立され、また、ポストペイドアカウントを確立する企業エンティティは、消費者の継続されたクレジット資産を継続的に保証する。ポストペイドアカウントは、よく知られており、かつ広く使用されている。
【０００４】
例えば、ポストペイド電話アクセスアカウントを確立することが知られている。消費者は、ポストペイドアカウントを使用して、長距離電話を行ったり、あるいはホームネットワークとは異なる来訪ネットワークでローミング中に、電話ネットワークへアクセスすることができる。電話会社は、消費者のクレジット資産に基づいて、ローミングサービスを提供する任意の他の会社への支払を保証する。加えて、ここ数年では、モバイルオペレータは、自身の消費者へのローミングサービスを提供している。典型的には、モバイルオペレータは、他国のような異なる地域でのパートーナオペレータとローミング契約を結んで、自身の消費者に、自分の移動電話をこれらのパートナー国あるいは他のネットワークで使用することを可能にしている。ホームネットワークは、来訪ネットワーク内の消費者による通話に対する支払保証人の立場にある。来訪ネットワークは、ホームネットワーク加入者に対する発呼及び着呼の機能を提供し、使用データを取得して、処理し、発呼者の支払用のホームネットワークへ送信する。そして、ホームネットワークは、来訪ネットワークへの支払を行う。
【０００５】
定期的な間隔で、ホームネットワーク電話会社は、自身の消費者へ請求を発行し、消費者から料金を徴収する。典型的には、このような取引には、著しい時間遅延、例えば、数日から数月の間の遅延が含まれる。それゆえ、ホームネットワークは、自身の消費者による通話に対する来訪ネットワークへの支払保証人の立場をとらなければならない。このため、現在、ホームネットワークは、自身のポストペイド消費者（クレジット資産が確立している）にのみ、ローミングを提供することが可能である。プリペイド加入者の基盤が増加するにつれて、広範囲で、電気通信オペレータは、自身のプリペイド消費者にも同様にローミングサービスを提供することを希望している。今日、消費者のローミングに対する通話使用の処理は、非リアルタイム処理であるという固有の性質があるために、オペレータは、自身の消費者に完全なプリペイドローミングを提供する立場にはない。
【０００６】
また、銀行あるいは他の貸出期間で、ポストペイドクレジットアカウントを確立し、商品及びサービスを購入するために、そのポストペイドアカウントを使用することが知られている。時には、ポストペイドクレジットアカウント及びローミング電話サービスは組み合わせることができる、これは、無線電話リンクを介してクレジットカード番号を送受信して、サービスを注文する場合である。このシステムには、制限がある。例えば、消費者は、アカウントは、自身の資産照会に制限することを希望したり、あるいは電話会社とクレジットを確立することを希望しない場合がある。これらの消費者は、プリペイドアカウントを確立することができる。しかしながら、既存のプリペイドアカウント構成には、いくつかの制限がある。
【０００７】
例えば、プリペイド移動あるいは無線電話ユーザは、他の電話会社によって管理されるテリトリーで、自身の無線電話を使用したい場合がある。以下で使用されるように、これは、来訪あるいはローミングテリトリーネットワークと呼ぶ。プリペイド消費者は、クレジットカードのような他のアカウントを使用して通話を完了するための十分なクレジットを持っている可能性がある一方で、消費者は、プリペイド消費者となっていることによって、ローミングテリトリーの電話会社との間で、あるいは自身のオリジナルの電話会社（「ホームネットワーク」あるいは「ホームテリトリー」）との間でさえ、「クレジット」を確立しない。つまり、ローミングテリトリー（「プリペイドローマー」）内のプリペイド消費者は、ローミングネットワーク電話会社がホームネットワーク電話会社の構成を持ち、かつ発呼を監視するために、各スイッチに特定のハードウェアを持ち、更に、消費者のプリペイドアカウントから課金しない限り、ローミング中に、自身のプリペイドホーム電話会社アカウントで課金する方法がない。これらの契約は取り交わすことは、通常は、非現実的であり、有効なプリペイドローミングが存在していない。
【０００８】
プリペイド電話は、電気通信産業に存在し続けている。消費者あるいはユーザは、通信サービスプロバイダに前もってある程度の料金を支払うことが要求され、そして、サービスプロバイダは、消費者に、その予め支払われている料金に対する通信サービスを使用することを可能にしている。一旦、ユーザアカウント残高がゼロになると、サービスプロバイダは、サービスを中断する。そのため、消費者は、通信サービスプロバイダに追加の料金の支払を行うことによって、自身のアカウントに再入金する必要がある。つまり、プリペイドアカウントは、現状を、維持し続ける必要がある。
【０００９】
プリペイド通信サービスを可能にするためには、サービスプロバイダは、リアルタイム（即ち、サービスが配信される時点）で、消費者のプリペイドアカウントの実際に使用する資産を制御する必要があり、かつサービスプロバイダは、消費者の発呼が行われるに従って、アカウントの資金の使用をリアルタイムで算出するシステムを必要とする。このようなリアルタイムの使用制御を可能にするサービスプロバイダに対して、利用可能なシステムがいくつか市場に存在する。今日、商業上利用可能な技術は、いくつかの方法を使用して、サービスプロバイダに、リアルタイムあるいはリアルタイムに近い形で、発呼を制御することを可能にしている。
【００１０】
第１の方法は、電話交換ネットワークへのサービスノードとして動作するプリペイドプラットホームがある。発呼は、プリペイドプラットホームを介して行われる、あるいはサービスプリペイドプラットホームは、セミインテリジェントネットワークの形態（即ち、プラットホームが、システムを介して実際に発呼を転送しないて接続／切断することを、交換ネットワークに指示する）で発呼を制御することができる。それゆえ、プリペイドプラットホームは、電話交換ネットワークが可能となるＩＮ（インテリジェントネットワーク）上のインテリジェントネットワークノードとして動作することができる。
【００１１】
発呼データレコード群（「ＣＤＲ群」）の処理に基づいて、かなり短い間隔で、プリペイドサービスを提供することもできる。交換システムは、例えば、ホットＣＤＲポートを介して、サービスプロバイダの請求書作成（billing）システム上に使用情報を渡すことが可能である、ここでホットＣＤＲポートは、使用情報を請求書作成システムに頻繁な間隔で供給するように構成されている電話会社のスイッチである。発呼の使用を制限する、課金通知（Advice of Charge）（「ＡｏＣ」）パラメータを利用するためのカードのプログラミングに基づいて、プリペイドサービスを提供することも可能である。しかしながら、発呼データレコードの使用は不正の可能性があるので、モバイルオペレータは、これらの使用を広範囲では継続しない。また、ＡｏＣは、使用料金の構成時の柔軟性がない。
【００１２】
伝統的なプリペイドシステムは、スイッチと一緒に配置される、発呼制御装置を必要とする、即ち、ソフトウェアとハードウェアの両方を必要とする。プリペイドシステムは、シグナリングリンク（例えば、ＳＳ７、ＭＦ２ＲＣあるいはＩＳＤＮ−ＰＲＩ等）を介して電気通信スイッチと接続される。発呼者が発呼を行う場合、スイッチは、シグナリングリンクを介して、シグナリング情報をプリペイドシステムへ転送する。次に、プリペイドシステムは、発呼を認可し、発呼を接続するためにスイッチに問い合わせる。また、プリペイドシステムは、その発呼に対するレイティング（rating）処理を初期化する。レイティング処理は、発呼者のプリペイドアカウントの使用の追跡を維持し、残高が尽きた場合、システムは、その発呼を切断することをスイッチに問い合わせる。
【００１３】
プリペイドローミングに対するこのタイプのシステムの配置は、効率的でない。プリペイドローミングに対しては、関連ネットワークのすべてと、かつたいていは異種ネットワークは、同一のプリペイドシステムを持つ必要がある。これは、複数のプリペイド発呼制御装置が、各関連ネットワークに対して配置される必要があることを意味する。これには、いくつかの理由によって、ロジスティックな問題が存在し得る。第１に、関連ネットワークすべてに装置を配置することは、時間を浪費し、かつ高価となり得る。第２に、通常の動作及びメインテナンス（例えば、料金体系の更新、システム情報の管理等）は、日単位ではロジスティック的に難しい。
【００１４】
加えて、ローミングサービスは、データ抹消と、金融取引の決済を必要とする。様々なネットワークシステムを介する複数の決済はかなり複雑となり得る。ネットワークをまたがる消費者アカウントのセットアップ及び管理は、かなり複雑となり得り、かつある程度の遅延は、消費者に対して大きな誤解及び混乱を招き得る。消費者は、来訪ネットワーク内で、自身のプリペイドアカウント残高を使い尽くす場合がある。消費者に、来訪ネットワークから自身のアカウントにお金を追加あるいは「再入金」できるようにすべきである。来訪ネットワークからの消費者の再入金は、いくつかの問題をもたらす：これには、消費者が来訪ネットワークサービスプロバイダの消費者でない場合には、どのようにして消費者アカウントの再入金を可能にするか、支払管理及び再入金額の決済に関連する金融取引をどのように管理するかである（例えば、業者手数料、再入金サービス簡素化処理及びホームネットークと来訪ネットワーク間の送金に関連する問題等）。
【００１５】
消費者が自身のアカウントに対するいくつかの支援、例えば、請求情報あるいは付加サービス等を必要とする場合、消費者サービスについては、だれに問い合わせるかについての問題が発生する。来訪ネットワークは、消費者に関連する情報をすべて持つ必要はなく、ホームネットワークでの情報は、流通している必要はない。来訪ネットワークは、シンプルメッセージングサービス（「ＳＭＳ」）、データサービス及び発呼関連サービス（例えば、電話会議、通話中着信等）のような付加価値サービスをローミング消費者に提供しようとしている。（付加価値サービスは、消費者がローミングしていない状態で、ホームネットワーク内の同一消費者に対して利用可能である）。ホームネットワークと来訪ネットワーク間の情報が、プリペイドローミング消費者に対して同期している必要がある場合、更なる問題が発生する。
【００１６】
今日、多くの電話会社は、経営及びビジネス管理のための社内情報技術（「ＩＴ」）システムを持っている。これらの現在のプリペイドシステムは、このような社内経営及びビジネス管理システムに統合されている。電話会社は、自身のプリペイドローミングシステムと社内ＩＴシステム間での統合を同一レベルで行うので、自身のビジネスを効率良く管理することができる。いくつかのプリペイドローミングシステムの配置は、いくつかの統合を意味する場合がある。これは、それ自身によって、時間を浪費し、高価となり得る。
【００１７】
ホームネットワークは、消費者の信用貸しの価値を予め評価し、かつホームネットワークは支払リスクを保証しているので、ポストペイド消費者に対して、電話会社は、消費者の支払あるいは金融リスクを負おうとする。しかしながら、プリペイド消費者の場合、ホームネットワークは、例えば、消費者は匿名消費者であり得るので、消費者がだれであるかさえ知らない可能性がある。これは、来訪ネットワークとホームネットワークの両方が、取引（例えば、通信サービス及び金融取引）のタイプのすべてに対して一定の契約を持つ必要がある。
【００１８】
また、電話会社は、自身の消費者に対して消費者ケアを提供している。しかしながら、電話会社は、加入者が自身のホームネットワークに存在する場合にのみ、その加入者に対して消費者ケアを提供する。加入者がローミングしている場合、その加入者はホームネットワークの消費者ケアセンターに電話することができ、かつその役務を使用することができる。しかしながら、ホームネットワークサービスエリア以外での消費者ケアの提供は、消費者情報が来訪ネットワークで利用できないという事実のために困難である。いくつかの電話会社のオペレータは、来訪ネットワークで制約のある消費者ケアを提供できるようにしている。しかしながら、これまでのところ、このようなシステムは、ポストペイド消費者にのみサービスしている。
【００１９】
プリペイド加入者基盤の増加に伴い、かつ移動商取引の機会が増えるにつれて、消費者ケアは、プリペイド消費者にとってかなり重要になってきている。概して、消費者は、消費者ケアサービスの見地からの要望をいくつか持っており：これには、来訪ネットワークあるいはテリトリ位置で利用可能なサービスに関する情報（例えば、自身の移動電話を使用して、消費者がファックスを送信できるか）、ローカルテリトリに関する情報（例えば、最寄りの医者はどこか）、来訪ネットワークのサービスをどのようにして使用するかに関する情報（例えば、消費者がＸＹＺの宛先へどのようにして電話するか、来訪ネットワークベンダーによって供給されている自身の移動電話を使用して、消費者がどのようにしてファックスを送信するか）、アカウント照会サービス（例えば、消費者のプリペイドアカウントの現在の残高がどれくらいか、消費者が行った直前の５つの取引はなにか及びどれくらいの取引額であるか）、アカウント／サービスプロファイル情報変更サービス（例えば、消費者が、自身のアドレスの変更を希望しているか、消費者が新規のサービスに加入して、ファックの送信を希望しているか）、意見／苦情（例えば、加入者が１０回試みても、毎回、電話が切断されるので、消費者は、通話に対する支払を行いたくない、消費者は、ＸＹＺの宛先には全く電話しない）、様々なソースからの消費者のプリペイドアカウントの再入金（例えば、消費者は、自身のアカウントの資産を使い果たし、再入金証書、自身の銀行アカウント、現金あるいは他の手段を使用して補填したい）がある。
【００２０】
電話会社の業務は複雑である。任意の電話会社のサービスの配信は、消費者の期待、例えば、サービスを利用可能にすること、また、正確な時間でかつ正確な位置で完全で正確な情報を提供することを管理し、かつ動作させるために様々なシステムを必要とし、そうすることで、消費者に効率的に提供される。電話会社のシステムは、その電話会社の内部処理が最適化されるようにすることを必要とする。これは、電話会社内部のスタッフが、完全で正確な情報を、正確な時間でかつ正確な位置で利用可能となることが必要されることを意味し、この情報を使用することで、仕事を効率的に管理する。電話会社のシステムは、共存するあるいは他のサードパーティ電話会社及びサービスプロバイダとの互換性があることも必要とし、そうすることで、サービスを集約して消費者に提供でき、かつ自身のビジネスを管理することができ、収益等を共有することができる。このような電話会社／サービスプロバイダの大量でかつ複雑な要求を満足するために、全機能を提供できるシステムは単独では存在しない。典型的には、サプライヤー、インテグレーター及び電話会社が協働して、いくつかの異なるシステムをカスタマイズして統合して動作させることで、特定の電話会社の要求を満足している。
【００２１】
プリペイド通信サービスビジネスが、別々のサービスとなることが当初から予想されていたので、電話会社は、通常、リアルタイム（あるいは、「リアルタイム」という語句の様々な定義に近いリアルタイム）で発呼を制御することができる単独の会社専用システムを採用している。プリペイド通信ビジネスが広範囲に急速なペースで成長するにつれて、サービスプロバイダは、自身の消費者に効率的に提供し、かつビジネスを管理するために、自身のプリペイドシステムと他のシステムを統合する要求があると感じている。
【００２２】
しかしながら、プリペイドローミングは、電話会社産業に対しいくつかの取り組みを提案している。すべての関連ネットワークは、発呼フローをどのようにして管理し、どのようにしてサービスを提供し、かつどのようにしてビジネスを管理するかについての共通な理解を持つ必要がある。しかしながら、様々なネットワークを介して、様々な方法で統合されたいくつかのシステムを用いると、プリペイドローミングに対する取り組みはわずかである。１つの基本的な問題には、いくつかの関連ネットワーク、たいていは異種あるいは異なるタイプのネットワークを介する、消費者及び効率的なビジネス管理に対して、「シームレス」サービスをどのようにして達成するかである。例えば、あるサービスプロバイダオペレータは、優良な消費者ケアセンターを持っているが、別のオペレータは、このような高品質な消費者ケアセンターを持っていない、あるいは、あるオペレータは高品質な証書（voucher）生成／管理システムを持っているが、他のオペレータは、これらの処理のほとんどを手動で管理している。いくつかの異なるシステムの単純あるいは複雑な統合は、電話会社間の様々な順列及び組み合わせのために、ビジネスソリューションを提供しない。また、１つの電話会社に、自身の既存システムを断念させて、完全に新しいシステムを採用することは、その新しいシステムが品質上どんなにすぐれているとしても、非現実的である。
【００２３】
周知のプリペイドシステムは、単一のボックスソリューションである、これは、外部システムとで制限のある統合が可能である。統合が実行可能な状況でさえも、他のシステムに対して、様々なレベルでプリペイドシステムに進入することは不可能である。つまり、プリペイドシステムのいくつかの機能を置換するための統合は不可能である。付加機能を追加するための統合は、達成するための何かが必要である。これは、電話会社のビジネスを効率的に管理する際の電話会社に対する主要な制限となる。例えば、電話会社が既にパーソナル識別番号（ＰＩＮ）生成システムを持っている場合で、ローミングに対するプリペイドシステムを配置しようとする場合には、旧来のシステムではなく、新規なプリペイドローミングシステムのＰＩＮ生成機能を使用することを必要とする。これは、電話会社が、ＰＩＮ生成システムを、非ローミング加入者に対するものと、ローミング加入者に対する別のものとに２つに分ける必要がある。これは、市場で様々な混乱を招き、また、サードパーティシステムとの単なる統合では、この問題を解決しない。これ以外の問題に、例えば、配信管理、消費者管理等がある。
【００２４】
上述のことに加えて、モバイルオペレータが、集中化通信及び商取引環境でプリペイドローマに移動消費取引を可能にする場合には、プリペイドローミング消費者によって行われる商取引に含まれる様々なパーティへの金融決済に対する要求が存在する。商取引の決済は、更に、以下の点を含めることができる、商取引に関連する支払は、以下の１つ以上のエンティティを介して分散される必要がある、このエンティティには、販売者（商品／サービスの提供者、あるいは製造業者、転売業者あるいは配給業者、あるいはそのようなエンティティのいくつかの組み合わせ）、ポータル（移動ポータルあるいは音声ポータル（「ボータル（Vortal）」））、電子商取引ポータル等を含む任意の他のタイプのポータル）、インターネットサービスプロバイダ（独立エージェンシーあるいはモバイルオペレータ自身あるいはポータル自身）、移動電話会社（ホームネットワーク、来訪ネットワークあるいはその両方）、仮想サービスプロバイダ（コンテンツサービスプロバイダあるいはインフラストラクチャサービスプロバイダあるいはブランディングエージェンシー（ブランド設定代理店）あるいはそれらの任意の組み合わせ）、銀行／クレジットカードエージェンシーあるいは任意の他の金融機関（取引で１つ以上関与する）、サードパーティ支払代理店（例えば、販売法人（aggregator）、支払処理エージェンシー、電子財布あるいは任意のそのような支払処理エージェンシー）がある。移動サービスプロバイダがいくつかのバンドル化パッケージ（例えば、消費者がローミング中に５０ドルの商品を購入する場合に、テレフォニーによるローミング追加料金が控除される等）を提供することも可能である。これは、商取引に関与する様々なパーティ間での料金計画及びローミング契約に基づいて、任意の決済システムで、様々な決済額を達成することを可能にすべきであることを意味する。
【００２５】
移動処理装置（電話、ＰＤＡ等）は、任意のタイプの支払、特に、小額払（マイクロペイメント）に対して使用されることが予想される。典型的には、消費者は、自身の移動電話を使用して、小額のもの、例えば、自動販売機のソフトドリンク、たばこ、新聞、書籍、駐車代金及び小額払として業界で一般的に知られている他の小額のものに対する支払を行う。
【００２６】
今日の既存の技術は、以下のいくつかの方法の１つを利用して、上記の支払を可能にする、これは、消費者は、自身の移動電話を使用することができ、また、支払時に、消費者は、自身のクレジットカードあるいは銀行の支払用のデビットカードを使用することができる。これは、支払が、消費者の電話アカウントではなく、消費者のバンキング／クレジットアカウントを介して行うことを意味する。この方法は、すべての消費者が銀行のデビットカードあるいはクレジットカードのどちらかを所有していることを想定しているという制約がある。現在のプリペイド移動電話の広範囲な成長は、任意のバンキング／クレジット関係を持たない、あるいは単に、電話用のバンキング／クレジット関係を使用したくないという市場が大きな区分で存在することを示している。これは、特に、貧弱なバンキング契約を行う、発展国での実情である。デビット／クレジットカードの条件は、移動商取引を行うことができる消費者の総数も制限するので、電話会社は、移動商取引ではかなり制限された役割だけを果たしている。電話会社の収入は、通常、電話接続及び自身が提供するサービスに制限されている。しかしながら、消費者は、商取引の支払に対し、自身の移動電話アカウントを使用することができる。つまり、商品／サービスのコストは、消費者の電話アカウントから課金される。月末には、消費者は、商品／サービスのコストが課金されている電話請求書を取得する。この方法は、消費者がポストペイドアカウント消費者であることを想定しているという制約がある。これは、システムは、プリペイド消費者には対応しない、つまり、移動商取引を実行できないことを意味する。その代わり、システムは、支払リスクは、電話会社あるいは販売者が負うことを想定している。請求期限までに、消費者が自身の請求を支払わない場合、電話会社／販売者は、金融リスクを負わなればならない。
【００２７】
消費者は、電子財布アカウントを持つことができ、これは、個人識別番号を有するアカウントである。消費者が商品を購入する時には、消費者は、ＰＩＮをキー入力することができ、電子財布会社（例えば、ＩＰＩＮ）は、支払保証を発行することができる。この方法では、電子財布は、プリペイドアカウントとして機能し、かつアカウント内のお金の残高が利用可能である場合にのみ、購入取引が認可される。この方法には制約があり、それは、購入が発生する毎に、ユーザは自身（例えば、典型的には１２桁以上のＰＩＮを使用して）を識別する必要があるからである。この識別処理自身は抑止力として動作し得り、消費者には、その処理を介して小額の購入を行うことに興味を持ってもらえない可能性がある。電話会社自身の収入あるいは料金が、提供する電話接続に制限されるように、ここでも、電話会社は、移動商取引ではかなり制限された役割のみを果たしている。
【００２８】
移動商取引購入処理を簡単にするために、産業は、ブルートゥースのような革新的な技術を模索している、この技術は、自動販売機と消費者の移動電話間での直接通信を可能にする。しかしながら、これらの技術は、販売者と消費者がともに、これらの技術を処理できる機器を装備する必要があるという制約がある。これは、セットアップコストがより高くなることを意味している。経済的なコストは、少なくとも近年では投資対象を正当化しないので、これらの技術は、支払リスクに関連する問題には関知しない。これらのシステムは、すべての消費者が信用に値し、かつ自身の支払を引き受けることを想定している。実生活では、これは、そのようになっていない。加えて、これらの技術は、プリペイド消費者に関連する問題に関知していない。プリペイド消費者は匿名であり得り、これは、電話会社も販売者もだれが購入者であるかを知らないことを意味する。
【００２９】
今日の電子商取引分野では、リード／ライトメモリ装置が、より普及している。リード／ライトメモリ装置は、アカウント残高及び消費者に関連する他の情報を記憶する機能を持っている。リード／ライトメモリ装置は、バックエンドシステムとの任意のネットワーク接続を必要としない。リード／ライトメモリ装置リーダは、販売者の販売店に設することができ、立ち寄りの消費者は、自身のカードを使用して支払を行うことができる。このメカニズムは、販売者と消費者との両方で使用することが簡単になるという利便性を見出し、かつ支払を可能にする。
【００３０】
サービスを使用する毎に、そのサービスに関連する支払は、消費者のプリペイドアカウントから控除される。ここで、プリペイドアカウント内の金額は、ある時点でゼロ残高に達することは明らかである。この時点で、消費者によって、自身のプリペイドアカウントに再入金する必要がある。プリペイド設備を提供する商取引可能システムが市場に存在し、それらのほとんどは、アカウントの再入金を提供している。現在の利用可能なシステムは、アカウントの再入金を、消費者によって使用することができる、再入金証書（証書は、ＰＩＮとして知られる固有の番号を持ち、例えば、２０ドルというようなある所定金額を持っている）を発行することによって実現している。消費者は、サービスプロバイダのインタラクティブ音声応答（「ＩＶＲ」）システムにダイヤルし、かつガイドメニューによって、消費者は、固有のＰＩＮ番号を入力することによって自身のプリペイドアカウントに再入金することができる。
【００３１】
このような再入金システムは、サービスプロバイダが再入金証書を印刷して、その証書を配達する必要があるという制約がある。これは、大きなロジスティック的かつコスト的な問題となる。また、いくつかのタイプの実行可能な不正による潜在的な不正のリスクが存在し、例えば、未認可ユーザへのＰＩＮの漏出、未認可ユーザが様々な番号をランダムに試行して、正当な番号と照合すること、また、未認可パーティが偽の再入金証書を印刷すること、偽造貨幣の類がある。また、サービスプロバイダは、いくつかのタイプの証書を提供することができるが、各証書は、所定金額になっている。サービスプロバイダは、証書毎に所定量の金額のみを提供することができる。これは、消費者が自身が希望する正確な再入金額を選択できなことを意味する。また、プリペイド消費者に対しクレジット設備を提供する機能は、サービスプロバイダにはない。より高度に発展し、かつクレジット取引のある国でのプリペイドアカウントの使用の増加は、任意のクレジット関連発行物でなく、便利でかつ簡単に使用するためのプリペイドアカウントを益々、消費者が使用することを意味している。このような消費者は、消費者がまだ使用していないサービスに対して前もって支払を行おうとはしない。クレジットの制限（銀行等のようなサードパーティによる保証された支払保証を有する）を持った状態で、このような方法は、プリペイドアカウントを選択する消費者の数を増加させるであろう。
【００３２】
プリペイド料金が、消費者によって使用可能なカード（ＳＩＭカード、スマートカード、磁気カードあるいは任意のタイプのカード）上にプログラムされている状況では、消費者は、カードの再入金に利用できる専用プログラミング装置が存在する最寄りの販売代理店に自身のカードを持って行くことができる。このようなタイプの支払は、昔から使用されている。しかしながら、移動商取引が益々普及するにつれて、消費者が小額払に対してこのような状況を使用したいことが予想される。プリペイド金額のカードへのプログラミングは、かなり小額の取引に対しては、消費者が長いコード（通常は、１２桁以上）を入力する必要がないという、利便性を消費者に提供している。しかしながら、このようなアカウントの再入金の構成は、消費者が再入金を必要とする毎に、消費者は限られた再入金の販売代理店にしか行けないという制約がある。このようなカードは、他の場所では再入金することができない。また、サービスプロバイダは、不正（例えば、カードに高額のお金を書き込むことができる装置へのアクセスを行う未認可パーティ）に関連する問題があるため、これらのカードにかなりの高額のお金を更新あるいは再入金をしようとしないし、サービスプロバイダは、プリペイド消費者に対してクレジット設備を提供する能力はない。
【００３３】
通常の商取引（例えば、実在の商店あるいは小売店でクレジットカード／デビットカードを使用して）、取引確認は、通常、カードの読取（swiping）と物理的な署名確認によって行われる。時には、不正の防止として、クレジット／デビットカードの販売代理店は、購入成立／消費者に対して銀行と照会することを要求する。そして、銀行は、母親の旧姓、誕生日等のような補助的な安全対策を使用して、消費者が未認可者でないことを保証する。今日のインターネット及びモバイルインターネット環境では、これらの補助的な安全対策は存在しないし、上述したような不正が、プリペイドアカウントシステムを変更できない様々なシステムで存在する。保証が制限されていることによって、取引に関連するインターネット／モバイルインターネット上の不正が、かなり多くなることが予想される。
【００３４】
電話料金に保険がかけられる場合には、消費者のプリペイドアカウントから課金することが知られている。課金は、アカウントに依存して、多くのソースから発生し得る。例えば、プリペイド電話アクセスアカウントを確立することが知られている。そして、消費者は、長距離電話を行うあるいは電話ネットワークへアクセスすることができる。
【００３５】
また、銀行あるいは他の貸付機関でポストペイドクレジットアカウントを確立し、そのポストペイドアカウントを使用して、商品及びサービスを購入することが知られている。時として、例えば、クレジットカード番号が無線電話リンクを介してサービスを注文するために取り交わされる場合には、ポストペイドクレジットアカウント及びローミング電話サービスを組み合わすことができる。このシステムには制約がある。例えば、消費者は、自身のアカウントの金額提示を制限しようとしたり、あるいは、電話会社とのクレジットを確立できない他の理由によって、自身のアカウントの金額提示を制限しなかったりする可能性がある。これらの消費者は、プリペイドアカウントを確立することができる。しかしながら、既存のプリペイドアカウント構成は、少なくともいくつかの制約がある。
【００３６】
例えば、プリペイド移動あるいは無線電話のユーザは、他の電話会社のテリトリ内で、自身の無線電話を使用したい場合がある。以下で使用するように、これは、来訪あるいはローミングテリトリあるいはネットワークと称される。プリペイド消費者が他のアカウント、例えば、クレジットカードを使用して通話を完了するために十分なクレジットを持っている場合には、消費者は、プリペイド消費者となっているために、ローミングテリトリの電話会社あるいは自身のオリジナルの電話会社（「ホームネットワーク」あるいは「ホームテリトリ」）でさえ、「クレジット」を確立しない。つまり、ローミングネットワークの電話会社がホームネットワークの電話会社との契約を交わしており、かつ各スイッチで、通話を監視し、かつ消費者のプリペイドアカウントから課金する専用のハードウェアを持っていない限り、ローミングテリトリ内のプリペイド消費者（「プリペイドローマー」）は、ローミング中に課金される、自身の電話会社のプリペイドアカウントを持つ術はない。これらの契約を行うことを通常非現実的なので、有効なプリペイドローミングは存在しない。
【００３７】
プリペイド電話が、電話通信産業で存在し続けている。消費者あるいはユーザは、通信サービスプロバイダに前もってある程度の金額を支払うことが要求され、サービスプロバイダは、消費者に、そのプリペイド金額分の通信サービスを使用することを可能にしている。一旦、ユーザアカウント口座がゼロになると、サービスプロバイダは、サービスを停止する。そして、消費者は、通信サービスプロバイダに追加料金の支払を行うことによって、自身のアカウントに再入金する必要がある。つまり、プリペイドアカウントは、いつでも維持される必要がある。金額が十分でない任意の取引は、制約のある取引として取り扱われる。
【００３８】
制約のある取引が発生している場合、その取引の取扱には２つの選択肢が存在する。その取引を辞退する。後日確認を条件として、その取引を承認する。後日確認を条件とする取引を承認する場合、アカウントプロバイダは、不正取引のリストを受け入れることになる。つまり、クレジットアカウント上に多額のデビットが発生する場合、クレジットアカウントプロバイダは、アカウント保持者に追加の電話確認を条件にその取引を承認していた、その取引に不正が見つかる場合は、通常、クレジットアカウントプロバイダに責任がある。
【００３９】
様々なクレジットアカウントプロバイダが、市場における自身の立場に基づいて、これらの損失を分散しようとしている。例えば、クレジットプロバイダは、不正取引の損失の一部を受け入れるために、自身のクレジットカードを受け入れることをベンダーに強いている。選択的には、その損失は、保険を使用することによって削減することができる。
【００４０】
同様なことに、アカウントへのクレジット取引が知られている。時には、予め認可されたクレジットが、時には、オーバドラフトプロテクションと呼ばれる、使用される。ここでも、アカウントについては、単純化したいくつかの制約が設けられる。例えば、預金アカウントにお金が長い間存在している限り、あるアカウントから他のアカウントへの連続送金によって、ゼロを下まわる課金アカウント残高を削減する課金が承認される。
【００４１】
特定アカウントに関連するサービスに対して様々なディスカウトがあることも知られている。例えば、消費者がセービングクラブ（savings club）の会員である場合、食料品をディスカウントで購入することができる。つまり、金銭がアカウント内に保持されていない場合でさえも、あるメンバーシップを保持することが、ディスカウントを行う条件ととしているとしても、取引の履歴は金銭的な価値がある。追加のディスカウントは、あるアカウント金額あるいはアカウント履歴を条件とすることができる。加えて、広告及びディスカウントは、様々な消費者に特別に提供されても良い。事前に（ahead of time）サービスに対する支払を行うこと（プリペイド）、また、サービスに対してクレジットアカウントを確立すること（ポストペイド）が知られている。ポストペイドアカウントは、消費者の信用能力に基づいて確立され、そして、ポストペイドアカウントを確立する企業エンティティは、消費者の継続的な信用能力を保証する。ポストペイドアカウントは良く知られており、かつ広く使用されている。
【００４２】
プリペイド通信サービスを可能にするために、サービスプロバイダは、リアルタイムで消費者のプリペイドアカウントの実際の金銭の使用を制御する（即ち、サービスが配信されるようにする）必要があり、サービスプロバイダは、消費者の通話が継続するにつれて、アカウント額の使用をリアルタイムで計算することができるシステムを必要とする。このようなリアルタイムの使用制御をシミュレートする、市場で利用可能なサービスプロバイダ用のシステムがいくつか存在する。
【００４３】
加えて、ローミングサービスは、データクリーニング（データ抹消）と金融取引の決済を必要とする。様々なネットワークシステムを介する複数のパーティのデータクリーニング及び決済は、かなり複雑となり得る。ネットワークを介する消費者アカウントのセットアップ及び管理はかなり複雑となり得り、かつある遅延は、消費者に対して大きな誤解と混乱をもたらし得る。消費者は、来訪ネットワークに存在している状態で、自身のプリペイドアカウント残高を使い尽くす可能性がある。消費者は、来訪ネットワークから自身のアカウントにお金を追加あるいは「再入金」できるようにすべきである。来訪ネットワークからの消費者の再入金は、以下のいくつかの問題を生じる：消費者が来訪ネットワークサービスプロバイダの消費者でない場合、消費者のアカウントの再入金をどのようにして可能にするか、再入金額の支払管理及び決済に関連する金融取引をどのようにして管理するか（例えば、ディーラーコミッションに関連する問題、ホームネットワークと来訪ネットワーク間の再入金サービス簡易化処理及び送金等）がある。
【００４４】
本発明の様々な実施形態は、移動処理装置（電話、ＰＤＡ等）を、様々なタイプの支払のすべて、特に、小額払に対して使用することを可能にする。典型的には、消費者は、自身の移動電話を使用して、小額のもの、例えば、自動販売機のソフトドリンク、たばこ、新聞、書籍、駐車代金及び小額払として業界で一般的に知られている他の小額のものに対する支払を行う。
【００４５】
プリペイド消費者にクレジット設備を提供する能力のないサービスプロバイダは、プリペイドアカウントの使用に制限をもたらし得る。より高度に発展し、かつクレジット取引のある国でのプリペイドアカウントの使用の増加は、消費者が、任意のクレジット関連発行物でなく、便利でかつ簡単に使用するためのプリペイドアカウントを益々使用することを意味している。これらのアカウントは、信用能力のある消費者に対する、リアルタイム認可アカウントとして知られている。このような消費者は、自身がまだ使用していないサービスに対する事前支払の支払を行おうとはしない。クレジット上限（銀行等の類のサーバパーティによる保証された支払保証）を用いて、このような方法は、プリペイドアカウントとリアルタイム認可アカウントを選択する消費者の数を増やすことになるであろう。
【００４６】
消費者が使用することができるカード（例えば、ＳＩＭカード、スマートカード、磁気カードあるいはその他の任意のタイプのカード）にプリペイド額がプログラムされる状況では、消費者は、カードの再入金に利用できる専用プログラミング装置が存在する最寄りの販売代理店に自身のカードを持って行くことができる。このようなタイプの支払は、昔から使用されている。しかしながら、移動商取引が益々普及するにつれて、消費者が小額払に対してこのような状況を使用したいことが予想される。プリペイド金額のカードへのプログラミングは、かなり小額の取引に対しては、消費者が長いコード（通常は、１２桁以上）を入力する必要がないという、利便性を消費者に提供している。
【発明の概要】
【発明が解決しようとする課題】
【００４７】
しかしながら、そのようなアカウント再入金構成は、再入金が必要である毎に、消費者は、限られた再入金の代理店にしか行けないという制約がある。このようなカードは、他の場所では再入金することができない。サービスプロバイダは、不正に関連する問題（例えば、装置へのアクセスを有する未承認パーティは、カードに多額の金額を書き込むことができる）と、かつプリペイド消費者へクレジット設備を提供する能力がサービスプロバイダにないことがあるために、これらのカードにかなり多額の金額を更新あるいは再入金したくないと考えている。また、このような再入金システムは、ユーザが自身の「ホームベース」からロジスティック的に使用することがますますできなくなっている。ロンドンのサービスプロバイダは、パリのあるセンターはもちろん、香港でさえも提供するつもりはないと言っている、これは、自身の消費者がこれらの地域に頻繁に旅行している可能性があるとしてでもである。なぜなら、サービスプロバイダが、例えば、店舗あるいは販売網基盤のような別のパーティの資産に依存している場合には、そのサービスプロバイダは、このような資産を使用する手数料が潜在的な収益からかなりの割合で損失するからである。
【課題を解決するための手段】
【００４８】
米国特許出願番号０９／３９５８６８で開示される本発明の実施形態は、シンプル電話スイッチを使用するプリペイードコール及び他の通信サービスに関するものである。このシンプル電話スイッチは、コンピュータ電話インタフェース（「ＣＴＩ」）カードが挿入され、第２の固定チャネルに拡張機能を転送する。第２の固定チャネルは、電話ネットワーク、インターネットあるいは他のインターネットプロトコルネットワークを介して、通信プラットホームに接続されている。通信プラットホームは、発呼、接続命令及び他のコマンドに対する認可を、シンプル電話スイッチに送信することができ、これにより、消費者は、拡張機能にアクセスする。
【００４９】
支払を認可し、かつ発呼制御を処理するための第２固定チャネルの使用は、通信システムを変更した、本明細書で説明されるいくつかの実施形態で可能であり、プリペイドローミングサービスに対していくつかの改良点を持たせている。例えば、上述のプリペイドローミングに加えて、本発明では、移動商取引、電子商取引、アカウント再入金、複数のパーティの決済取引、統合消費者ケアあるいは任意の他の商取引用の改良型集中通信装置を提供する。
【００５０】
つまり、本発明の第１実施形態は、集中位置に配置されている集中通信システムであり、この集中位置には、インターネット、公衆交換電話ネットワーク、ＳＳ７シグナリングライン、電話番号、あるいは任意の他の周知の手段あるいは将来開発される手段を介して、任意の位置からアクセス可能である。プリペイドローミングコールは、ローカル電話スイッチから集中化集中通信プラットホームに信号するを送信することによって、ローカル電話スイッチで処理することができ、この集中化集中通信プラットホームでは、消費者が自身のアカウントへのアクセスを試行する。
【００５１】
集中通信プラットホームは、いくつかのステップの完了後に、電話発呼を認可することができる。第１ステップは、消費者が実際の認可済消費者であることをチェックすることである。第２ステップは、消費者が、特定のサービスの使用を認可していることをチェックすることである。第３ステップは、集中化集中通信プラットホームの消費者のアカウントの残高をチェックすることである。サービスを認可し、かつ十分なアカウント残高を持っている消費者からリクエストがある場合、集中化集中通信プラットホームは、ローカル電話番号スイッチへの認可番号を発行することができる。
【００５２】
消費者が通話を完了すると、ローカル電話スイッチは、集中化集中通信プラットホームへの通話時間に従って、サービスの完了の通知を集中化集中通信プラットホームに送信することができる。消費者が、電話中に、自身のアカウント内のお金を使い尽くす場合、集中化集中通信プラットホームは、第２ラインを介して、メッセージをスイッチへ送信して、通話を終了することができる。どちらの場合でも、プリペイドローミング消費者は、自身のアカウントにアクセスし、かつプリペイドサービスを利用することができる。
【００５３】
電気通信分野では、異なるネットワーク技術が、様々な地域で存在している。消費者がある地点から別の地点、例えば、ヨーロッパからアメリカへ旅行する際には、ローミングテリトリ内でも同一の電話番号で電話を接続したい要望がいまだなおある。今日では、ローミングは同一のタイプの２つのネットワーク間で可能である（例えば、あるＧＳＭネットワークから別のＧＳＭネットワークへのローミング、あるいはあるＡＭＰＳネットワークから別のＡＭＰＳネットワークへのローミング等）。しかしながら、技術の違いによって、消費者は、あるネットワークタイプから別のネットワークタイプ間のローミングは実行できない（例えば、ＧＳＭ電話を所有する消費者は、ＣＤＭＡネットワークにローミングすることができない、ＡＭＰＳ電話を所有する消費者は、ＧＳＭネットワークにローミングすることができない）。このローミング機能が実現できないのは、各技術が異なる周波数で動作するからである。それゆえ、移動体ハンドセットは互換性がなく、電話会社のネットワーク技術のそれぞれの発呼フロー管理は異なっており、かつ各ネットワークタイプの加入者識別処理は異なっている。例えば、ＧＳＭネットワーク内で、加入者あるいは消費者は、ＩＭＳＩ、ＳＩＭシリアル番号及びＭＳＩＩＳＤＮに基づいて識別される、ＣＤＭＡネットワークでは、加入者あるいは消費者は、ＭＩＮ及びＥＳＮに基づいて識別される、ＡＭＰＳネットワークでは、加入者は、ＥＳＮに基づいて識別される。
【００５４】
異種ネットワークをまたがるローミングの問題は、次の２つの解決策のどちらかで解決することができる：消費者が複数帯域移動体ハンドセットを購入する、この移動体ハンドセットは、ハンドセットからのページング信号を、複数のネットワークで認識可能にする（例えば、トライバンドハンドセットは、加入者に、ヨーロッパとアメリカの両方で同一の電話を使用することを可能にする）、あるいはローミング消費者は、ローミングサービスプロバイダに行き、一時的に、異なるローミングネットワーク規格のハンドセットを借りることである。電話会社は、消費者に、着信転送方法によって同一の電話番号を持つことができることを保証する。
【００５５】
しかしながら、これらのローミング解決策は、ポストペイド加入者に対してのみ実現可能である。これらは、プリペイドローミングが可能なプリペイド加入者に対しては動作しない、これは、関連ネットワークのすべてが、認可、比率、及び消費者ホームネットワークプリペイドアカウントからの課金に関し、協力して動作する必要があるからである。異種ネットワークにまたがってプリペイドローミングをサポートすることができる、市場で利用可能な商取引技術は現在存在しない。
【００５６】
プリペイド加入者基盤の成長に伴い、電話会社は、広範囲で、異種ネットワークにまたがるプリペイドローミングを提供しようとしている。それゆえ、次のことができる解決策が必要とされている：異種ネットワークタイプの様々な要求を満足する、発呼あるいはローミングネットワークから関連発呼制御情報及び加入者情報を取得する、加入者のホームネットワークへ関連発呼制御情報及び加入者情報を生成し送信する、加入者の確認による加入者認証を取得するばかりでなく加入者に許容するサービスのプロファイルに基づいて、加入者を認証する、発呼あるいはローミングネットワークによって必要とされるフォーマットで、発呼あるいはローミングネットワークに承認／拒否を返信する、発呼ネットワークあるいは加入者が現在存在するネットワークで発呼がセットアップされる場合に、リアルタイムで通話料を算出する、使用情報を提供する、異種ネットワークにまたがって提供されるサービスに対する複数のパーティの決済を実行することである。
【００５７】
ローミング加入者、特に、プリペイドローマーに対する消費者ケア解決策は、少なくとも次の機能を持つべきである：加入者が消費者ケアセンタ（「ＣＣＣ」）に発呼する場合にローミング加入者を識別する機能、ホームネットワークと通信し、消費者アカウントに関連する情報（残高、過去の取引履歴等）と消費者サービスプロファイル（どんなサービスが、特定の消費者に対して可能であるか）を取得する機能、情報配信／クエリー応答に対する消費者のリクエストを処理する機能、消費者アカウントあるいはサービスプロファイル（例えば、漏話に対するお金のクレジット／返金、消費者に対して新規のサービスの有効化、等）のどちらかにおいて動作を行う機能、加入者が来訪ネットワークで消費者ケアシステムへ接続して消費者ケアの提供を受けることができる機能（例えば、ローカルインタラクティブ音声システムとの統合、消費者アプリケーション等）、消費者アカウントの情報の完全性を維持するために、消費者のホームデータベースを更新する機能、ローミング中に、消費者が自身のプリペイドアカウントに再入金する機能である。
【００５８】
プリペイドローミングは、集中通信サービスに対する複数のパーティの決済に対し、いくつかの挑戦をもたらしている。ポストペイドローミングでは、消費者から集金するホームネットワークがある。それゆえ、すべての来訪ネットワークは、ローミング消費者使用データを（直接あるいはデータクリアリング／決済機関を介して）、決済のためにホームネットワークへ送信する。プリペイドローミングでは、消費者ＡはネットワークＸからの初期加入を購入するばかりか、ネットワークＹのプリペイド金額を使用し、そして、ネットワークＺの自身のアカウントに再入金することが可能である。このような状況では、たとえネットワークＺが消費者Ａによって再入金金額を保持している場合でさえも、ネットワークＹへの支払を行う、ビジネス義務はネットワークＺにはない。また、ネットワークＸは、消費者Ａによって支払われるお金を実際に保持しないで、消費者支払を保証している。また、支払集金あるいは再入金サービスを提供するために、ネットワークＺは、ネットワークＸにサービス料金を徴収しようとする。
【００５９】
現在利用可能なローミング決済解決策は、ポストペイドサービスである電話サービスに対する決済のみに行うものである。これらは、プリペイド電話サービス（単一あるいは集中化サービス）の必要性には取り組んでおらず、来訪ネットワークのプリペイドローマー加入者によって実行される商取引の決済の必要性も取り組んでいない。ここで、方法及びシステムの解決策で必要とされることは、次のことである：集中化サービス及び商取引の複数パーティによる決済を可能にする；各サービス及び商取引の決済ルールの構成を可能にすることである。これらのルールは、次の間での決済を可能にするべきである：販売者（商品／サービスのプロバイダ、例えば、製造者、再販者、流通業者あるいはこのようなエンティティのいくつかの組み合わせ）、ポータル（移動ポータル、あるいは電子商取引ポータルを含む任意のタイプ、等）、インターネットサービスプロバイダ（独立エージェンシーあるいはモバイルオペレータあるいはポータル）、移動電話会社（ホームネットワーク、来訪ネットワーク、あるいはその両方）、仮想サービスプロバイダ（コンテンツサービスプロバイダあるいはインフラストラクチャサービスプロバイダあるいはブランディングエージェンシーあるいは任意の組み合わせ）、銀行／クレジットカードエージェンシーあるいは任意の他の金融機関（商取引に１つ以上含まれている）、サードパーティエージェンシー（例えば、商業法人（merchants aggregator）、支払処理エージェンシーあるいは電子財布あるいは任意のこのような支払エージェンシー）、商品／サービス配送エージェンシー（例えば、国際宅配業者（クーリエ（courier）業者）、バンド幅（bandwidth：回線）供給者）及び保険エージェンシーである。
【００６０】
決済ルールは、次のような様々な状況に対する構成を可能にするべきである：（１）リアルタイム決済、（２）時間遅延型（time delay）決済（例えば、２日後あるいは３０日後等）、（３）ある条件の確認に基づく決済（例えば、保険エージェンシーが商品の出荷前に支払を行っているけれども、商品が配達される場合にのみクーリエが支払われる）、（４）パーティ間のビジネス関係に基づく決済（例えば、クーリエーエージェンシーは、ボリュームに基づくディスカウントを提供し、これは、決済処理が、１つだけの配達ではなくいくつかの配達を考慮に入れること意味する）、及び（５）出来高に基づく決済（例えば、広告がローミング加入者に配信される毎にポータルに小額が支払われ、かつポータルは、ローミング加入者が実際に商品／サービスを購入する場合には、それより大きな額の支払を受け取る）。決済は、関連ネットワーク間のローミング契約（例えば、ローミング追加料金）も考慮すべきである。決済は、任意の規制条件も考慮すべきである（例えば、政府機関への税金及び決済の充当）。
【００６１】
プリペイドサービス及び商取引を成立させるために、特に、移動商取引では、方法及びシステムに対して、次の任意のものからの再入金を可能にすることが必要とされている：再入金証書、保証人アカウント（クレジット／デビット／任意の他のタイプのアカウント）との直接連携、移動電話あるいは固定電話による消費者からの再入金、保証人アカウント（クレジット／デビット／任意の他のタイプのアカウント）からの直接課金、銀行ＡＴＭからの消費者による再入金、あるいは現金窓口での現金支払による再入金である。各プリペイド消費者には、次の方法で再入金に対する自身の条件を構成することを可能にするべきである：電話（移動電話あるいは固定電話）からのみからの再入金、ネットからの再入金（インターネット、モバイルインターネットあるいは任意の他のタイプの公衆あるいは専用ネットワーク）、消費者が再入金に対して明確に問い合わせている場合にのみ再入金（ＩＶＲ、ネットあるいは立ち寄り、あるいは任意の別の方法によって）、残高がある額を下回っている場合に自動的に別の特定アカウント（銀行デビット／クレジットあるいは任意のタイプのアカウント）から再入金、プリペイドアカウントに対して支払保証とする別のアカウントを使用している場合は、そのアカウントに再入金はしない、メインアカウントからの予め構成されているいくつかのサブアカウントへの再入金、定期的な再入金（例えば、日毎、月毎、週毎等）、ユーザによって定義される使用基準に基づいて判定される金額での再入金（例えば、過去７日間の使用及び平均再入金金額の参照、あるいは再入金金額が、過去「ｘ」日間で指示された最も高額取引の金額と等しくなっている等）がある。
【００６２】
プリペイド集中通信環境では、取引確認／認証（通信サービスあるいは商取引、あるいはその両方の組み合わせであるか）は、ユーザを確認するためにいくつかのステップあるいはチェックを行い、かつアカウントに関連付けられているクレジット上限あるいはプリペイド金額を利用できるようにすべきである。通信アクセス、インターネットあるいはモバイルインターネットアクセス、商取引（物理的な店舗あるいはネット／モバイルネット上で実行される）に対する解決策には、次のことを可能にするべきである：ＰＩＮに基づく消費者確認、パスワード、電話関連セキュリティ機能、あるいはそれらのいくつかあるいはすべての組み合わせ、要求されたサービス／取引が認可されているか、あるいは特定消費者プリペイドアカウントに対するものでないかの確認（サービスプロファイル確認）、サービス／取引用の消費者プリペイドアカウントに有用な十分な残高があることの確認（残高は、プリペイドアカウント残高、クレジットアカウント残高、あるいは任意の他のタイプの、消費者プリペイドアカウントに関連付けされている実際のあるいは仮想アカウント）である。
【００６３】
サービスプロバイダ（銀行、電気通信会社あるいは販売者あるいは任意の他のタイプのサービスプロバイダ）によって構成されるルールに基づいて、追加の確認を実行することができる。例えば、サービスプロバイダは、次のことができる：ユーザからの追加の情報を（例えば、母方の旧姓、誕生日、あるいは前回の取引時の金額、あるいは前回の課金額、前回の再入金額、あるいは消費者によって予め定義されている個人的な質問と回答とのの一致度）を問い合わせることができる、高額の取引（例えば、２０ドル以上）あるいは大量の取引（例えば、１日に１５取引以上、あるいは月に５０取引以上等）に対しては専用パスワードを問い合わせることができる。エンドユーザあるいは消費者によって構成されるルールに基づいて、サービスプロバイダは、追加の確認を実行することができる。
【００６４】
例えば、消費者／ユーザは、次のことを要求することができる：あるタイプの取引に対する追加のパスワード（例えば、航空券の購入）、前回の取引の数以上の取引の場合（例えば、過去５日間の取引の総数が現在の取引数の５０％以上であるかを尋ねる）にシステムによって要求される追加の情報（例えば、誕生日、友人名、専用パスワード）。消費者／ユーザによって構成されるルールに基づいて、システムは、あるタイプの取引（例えば、通貨制限のある国間でのポルノ写真あるいはお金以外の可能なすべての電子商取引及び移動商取引）を防ぐことができる。
【００６５】
上述のようにして構成されるルールに基づいて、消費者ケアエージェントに対しては、電話（即ち、本システムは、認可される取引が処理中には、取引認可用の音声通信を可能にするべきである）による消費者との連絡を行えるようにするべきである。サービスプロバイダによって構成されるルールに依存して、このような音声通信／追加のセキュリティ情報の使用に対しては、消費者から課金するべきでない（例えば、無料アクセス）。
【００６６】
つまり、本発明の構成の１つは、複数のネットワークを介する移動商取引、電子商取引、消費者ケア及び通信サービスを提供する方法を提供することであり、この方法は、ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金あるいは比率を追加して、前記ローミングネットワークからホームネットワークへ送信し、前記サービスが課金対象である場合、前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供し、前記サービスが課金対象である場合、リアルタイムで前記有効ユーザアカウントから課金し、必要に応じて、前記サービスが課金対象である場合、前記サービスを提供する。
【００６７】
本発明の別の構成は、複数のネットワークを介して移動商取引を提供する装置を提供することであり、この装置は、サービスのリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからの前記サービスの料金を含み、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証する検証部と、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を送信する送信部と、前記サービスを提供するために、前記有効ユーザアカウントから課金する課金部を備える。
【００６８】
本発明の更なる別の構成は、複数のネットワークを介してプリペイドローミング通信サービスを提供する方法を提供することであり、この方法は、ローミングネットワークで、ユーザ装置から、識別番号及び宛先装置番号を受信し、前記識別番号及び前記宛先装置番号に、サービスプロバイダ識別番号及びローミング通信サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っていることを検証し、前記識別番号が有効ユーザ情報に関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っている場合、前記ローミングネットワークに認可を提供し、前記サービスを提供するために、前記有効ユーザアカウントから課金し、前記ユーザアカウント残高が所定レベルに達する場合、信号を送信する。
【００６９】
本発明の別の構成は、複数のネットワークを介してプリペイドローミング通信サービスを提供する装置を提供することであり、この装置は、サービスリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号及び宛先装置番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからのサービスの料金を含み、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記ローミングネットワーク上の前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証する検証部と、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を送信し、かつ前記ユーザアカウントが所定レベルに達する場合、信号を送信する送信部と、前記サービスを提供するために、前記有効ユーザアカウントから課金する課金部を備える。
【００７０】
本発明の別の構成は、複数のネットワークを介して消費者ケアサービスを提供する方法を提供することであり、この方法は、ローミングネットワークで、ユーザ装置から、識別番号及び消費者ケアサービスのリクエストを受信し、前記識別番号及び前記消費者ケアサービスリクエストに、サービスプロバイダ識別番号を追加して、前記ローミングネットワークからホームネットワークへ送信し、前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連していることを検証し、前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に前記消費者ケアサービスを接続する。
【００７１】
本発明の別の構成は、複数のネットワークを介して消費者ケアサービスを提供する装置を提供することであり、この装置は、消費者ケアサービスのリクエストを受信する受信部と、前記リクエストは、ローミングネットワークに配置されているユーザ装置からの識別番号と、前記ローミングネットワークからのサービスプロバイダに関連するサービスプロバイダ識別番号を含み、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記消費者ケアサービスを受信するために認可されていることを検証する検証部と、前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に、前記消費者ケアサービスを提供することができる消費者ケアサービスプロバイダを接続する接続部とを備える。
【００７２】
本発明の更なる別の構成は、集中通信プラットホームを介して提供されるサービスに対するプリペイドアカウントに再入金する方法を提供することであり、この方法は、前記集中通信プラットホームに配置されている消費者アカウントを使用するための認可用のリクエストを受信し、前記消費者アカウントが、提供対象のサービスに対して十分な残高を持っていないことを判定し、前記消費者アカウントが再入金メカニズムを認可していることを判定し、前記再入金メカニズムを使用して、前記消費者アカウントに再入金し、前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用を認可する。
【００７３】
本発明の更なる構成は、集中通信プラットホームを介して提供対象のサービスに対するプリペイドアカウントに再入金する装置を提供することであり、この装置は、前記集中通信プラットホームに配置されている消費者アカウントを使用するための認可リクエストを受信する受信部と、前記消費者アカウントが、提供対象のサービスに対して十分な残高を持っておらず、かつ前記消費者アカウントが再入金メカニズムを認可していることを判定する判定部と、前記再入金メカニズムを使用して、前記消費者アカウントに再入金する再入金部と、前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用の認可を送信する送信部とを備える。
【００７４】
本発明の別の構成は、集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う方法を提供することであり、リアルタイムで、複数のネットワークを介して提供される取引に対するユーザアカウントから料金を課金し、前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定し、前記判定された料金に従って、前記複数のネットワークを介して前記プロバイダとの決済を行う。
【００７５】
本発明の更なる別の構成は、集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う装置を提供することであり、この装置は、リアルタイムで、複数のネットワークを介して提供される取引に対するユーザアカウントから課金する課金部と、前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定する判定部と、前記判定された料金に従って、前記複数のネットワークを介して前記プロバイダとの決済を行う送信部とを備える。
【００７６】
本発明の別の構成は、複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する方法を提供することであり、この方法は、ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、前記サービスが課金対象である場合、前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、前記識別番号が前記有効ユーザアカウントに関連し、かつ前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供し、前記サービスが課金対象である場合、リアルタイムで前記有効ユーザアカウントから課金し、必要であれば、前記サービスが課金対象である場合に、前記サービスを提供する。
【００７７】
加えて、本発明の構成は、複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する装置を提供することであり、この装置は、サービスがローミングネットワークからの課金対象である場合、ユーザ装置からの識別番号、サービスリクエスト、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金あるいは比率を受信する受信部と、前記ホームネットワークに配置される集中通信プラットホームによって、前記識別番号が有効ユーザアカウントに関連しているか、前記ユーザ装置が前記サービスを受信するために認可されているか、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っているかを判定する判定部と、前記サービスが課金対象である場合、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供する送信部と、前記サービスが課金対象である場合、前記サービスを提供するために、リアルタイムで前記有効ユーザアカウントから課金し、必要であれば、前記サービスが課金対象である場合、前記サービスを提供する。
【００７８】
つまり、本発明の構成は、多くのソースから発信する通信サービス及び取引を処理する、柔軟かつ高度なシングルユーザアカウントを実現する集中通信システム及び方法を提供することである。複数のサービスプロバイダ及び取引プロバイダからの取引を処理することができるシングルアカウントは、以前は利用不可能であった取引に対し、他の取引のコストを削減することを可能にするので、取引をより頻繁に行えるようになる。本発明の様々な実施形態は、複数のベンダー、複数のシステム環境内で小額取引を可能にする。様々な実施形態は、かなりの小額取引を簡単に認可し、課金し、決済する方法を生成する。本発明の様々な実施形態は、現在、ユーザに使用されている移動体の仕様を満足する、集中通信システム及び方法を提供する。
【００７９】
本発明の別の構成は、益々特殊化している分野に適合する集中通信システム及び方法を提供することである、この分野では、多くのパーティに、ある取引を可能にすることが要求されている。追加のパーティは、取引に付加価値を追加することができ、その付加価値に基づく代償を受けることを期待している。本明細書で説明されるリアルタイムルールは、多くのパーティに、取引に対し、そのパーティが同意する課金及び支払スケジュールに従う支払を受け取ることを可能にする。複雑な取引では、各サービスプロバイダは、支払が保証されていることを要求する。これらの複雑な混合サービスの配信に対しては、配信連鎖内のパーティは、その複雑な取引がリアルタイムで認可された場合にのみ保証を受け取ることができ、これは、その時間（即ち、リアルタイム）で適用可能対象として保証されている認可に対するルールが定義されているアカウントに対してである。本発明の様々な実施形態は、リアルタイムのルールセットを使用して、複数のサービスプロバイダ間での複雑な取引を実現する方法によって、複数のパーティでの課金及び決済を可能にする。
【００８０】
本明細書で説明される本発明の更なる構成は、アカウントによって提供される適合性及び機能性を拡張する通信システム及び方法を提供することであり、このアカウントは、アカウント再入金に関連する複雑なルールに対し、取引の認可、リアルタイム課金及び複雑な決済を可能にし、かつその構成はそのルールを判定する方法を提供することである。
【００８１】
消費者に対する柔軟性及び安全性を提供するシングルアカウントは、従来利用不可能であった複雑な取引を可能にする。本発明の様々な実施形態は、実行対象の高度なルールセットを提供し、これは、消費者に柔軟性及び利便性を提供できるとともに、関係するサービスプロバイダ（群）に対する安全性を提供できる。例えば、アカウントからのクレジット、取引の認可、アカウントの課金及び複数の受取人が関与する取引の決済に対する高度なルールは、今日及び将来の移動商取引で必要とされる柔軟性及び利便性を提供する。つまり、要求された取引が、その時点での位置で許容できるか否かを判定し、どんな追加のアクションがその取引を許容できるかについてを判定することができる。時には、これには、消費者に選択の機会を与えるが、通常は、そうでない。
【００８２】
パーティから取得する支払の取得金額の判定は複雑であり、かつ、すべてのパーティを公平に扱われることを補償するために、取引時に判定される必要がある。本発明の実施形態は、アカウントのリアルタイム認可及び課金を用いて、リアルタイムで制御される取引を提供する。リアルタイムルールセットは、様々な動機に基づいて決定することができる。例えば、過去のイベントに基づいて、適合的あるいは適宜判定することができる取引の日時、消費者及びベンダーの履歴及び他のファクタを、取引の認可を行うかについてをサポートするために使用することができる。
【００８３】
集中通信システム及び方法で使用される第１カテゴリのルールは、アカウント再入金であり、これは、異種ネットワーク環境内の集中通信システム及び方法を介する、様々なサービスプロバイダからの移動商取引、通信あるいは他の電子商取引に対して、前もって、ユーザが要求しかつ要求されるものである。アカウント再入金は、アカウントに入金するクレジットの種類を含ませることができる。いくつかの例には、現金、ストック、飛行マイル、メンバーシップ、メンバーシップに対する延長期間、クレジット許可、所有権移転、あるいは、アカウントに送金する現在知られているあるいは将来開発される他の方法が含まれる。アカウント再入金は、自動、半自動、手動あるいはあるパラメータ内では自動でそれ以外は手動とすることができる。本発明の様々な実施形態は、次の任意のものからの再入金を提供する：再入金証書、保証人アカウント（クレジット／デビット／任意の他のタイプのアカウント）との直接連携、移動電話あるいは固定電話による消費者からの再入金、保証人アカウント（クレジット／デビット／任意の他のタイプのアカウント）からの直接課金、銀行ＡＴＭからの消費者による再入金、あるいは現金窓口での現金支払による再入金である。これによって、ユーザは、自身の消費者アカウントに対して、複雑ではあるが機能的な環境をセットアップすることができる。
【００８４】
集中通信システム及び方法で使用される第２カテゴリのルールは、認可及び承認ルールであり、これは、異種ネットワーク環境内の集中通信システム及び方法を介する、様々なサービスプロバイダからの移動商取引、通信あるいは他の電子商取引に対して、前もって、ユーザが要求しかつ要求されるものである。本発明の実施形態は、クレジットサービス、電話及びインターネットへのリンクを提供しているので、ルールは、どんな状況で、お金がアカウントから取得できるかについての概要が含まれている。様々な例では、課金制限、第２システムへの通知、アカウント入金制限、メンバーシップ制限、あるいは単一の取引に制限する他の現在知られているあるいは将来開発される方法、月別取引、アカウント残高、取引発信者及び取引受信者毎に含まれる。これによって、ユーザは、だれが、どのようにしてアカウントを使用することが認可されるかを制御する、複雑ではあるが機能的な環境をセットアップすることができる。
【００８５】
集中通信システム及び方法で使用される第３カテゴリのルールは、課金ルールであり、これは、異種ネットワーク環境内の集中通信システム及び方法を介する、様々なサービスプロバイダからの移動商取引、通信あるいは他の電子商取引に対して、前もって、ユーザが要求しかつ要求されるものである。本発明の様々な実施形態は、様々なサービスプロバイダを提供して、サービスプロバイダあるいは消費者のアカウントのどちらかから課金する様々な方法をセットアップする。例えば、電話サービスプロバイダは、自身のアカウントへの支払、ローミングネットワークプロバイダのアカウントへの支払、及び長距離プロバイダのアカウントへの支払を提供することができる。
【００８６】
上述の本発明の構成は、ルールセットを採用し、いくつかの機能を有する集中通信方法によって対応することができ、この機能は、認可済ユーザに対し、取引を認可し、かつその認可済ユーザのアカウントから課金する時に適用可能な少なくとも１つのルールの判定、取引を認可するための少なくとも１つのルールの適用、取引が認可される場合にリアルタイムでアカウントから課金するための少なくとも１つのルールに従うアカウントからの課金、少なくとも１つの決済ルールに従う複数の取引プロバイダからの課金を含んでいる。
【００８７】
上述のシステム及び方法に対する様々な構成には、取引に対して課金される認可済ユーザアカウントに、認可済ユーザが十分な金額を持っているかの判定、いくつかの機能を有する再入金ルーチンの完了後に認可済ユーザアカウントへの再入金を含むことができ、この機能は、送金ための再入金ユーザアカウントの判定及び事前認可済送金を少なくとも１つ照会することによる送金の認可及び認可済ユーザからの認可の要求を含んでいる。他の構成は、複数の再入金ユーザアカウントを利用して、再入金が実行されることを含んでいる。他の構成は、認可済ユーザからの認可の要求が、ＰＩＮの要求、手動エントリの要求、ユーザパスフレーズの要求及び生体測定手段を介するユーザ識別子の確認の少なくとも１つであることである。
【００８８】
上述のシステム及び方法に対する様々な構成は、取引を認可するための複数のルールを利用して適用が実行されること、アカウントを課金するための複数のルールを利用して課金が実行されること、及び複数の決済ルールを利用して決済が実行されることを含み、あるいはアカウントから課金するための複数のルールを利用して課金が実行されること、かつ複数の決済ルールを利用して決済が実行されることを含んでいる。他の構成は、決済が、即時、３日後、カレンダー月の末、定期的な期間及び一連の分割払日の少なくとも１つで発生すること、かつ取引の認可に対し、少なくとも１つのルールを適用することが、ユーザＰＩＮ、手動エントリ、ユーザパスフレーズ及び生体測定手段を介するユーザ識別子の確認の少なくとも１つを使用する取引の認可を含むことである。
【００８９】
上述のシステム及び方法に対する様々な構成は、時系列イベントに関連するデータを使用するアルゴリズムに従う取引認可リクエストの発行時にリアルタイムで適用される少なくとも１つのルールの判定であり、このルールは、取引認可リクエストとの関係を持っていることが考慮される。他の構成は、時系列イベントが認可済ユーザの過去の購入、あるいは時系列リスクアセスメントの実際の成果であること、あるいはこのような時系列イベントが定常的に変更可能であることである。他の構成は、取引が要求され、かつ複数の取引プロバイダへの接続が異種ネットワークにまたがっていることである。
【００９０】
上述の本発明の構成は、集中通信システム内のアカウントにアクセスするためのユーザ入力装置によって対応可能であり、これは、認可済ユーザアカウントへアクセスし、かつアカウントマネージャーから取引を要求するために、前記集中通信システムへ送信する送信部を備え、前記アカウントマネージャーは、認可済ユーザに対し、取引を認可し、かつアカウントから課金する時点で利用可能な少なくとも１つのルールを判定する判定部と、前記取引を認可するために、前記少なくとも１つのルールを適用するプロセッサと、前記取引が認可される場合に、リアルタイムで、アカウントから課金するための前記少なくとも１つのルールに従って、前記アカウントから課金する課金部と、少なくとも１つの決済ルールに従って、複数の取引プロバイダに対してリアルタイム課金を決済する決済部とを備え、また、ユーザ入力装置は、前記認可済ユーザアカウントへのアクセスの確認、認可済ユーザアカウントからの課金の確認及び決済の通知の少なくとも１つを受信する受信部を備える。
【００９１】
上述の本発明の構成は、更に、ルールセットを採用する集中通信システムによって対応することができる、これは、認可済ユーザに対し、取引を認可し、かつ前記認可済ユーザのアカウントから課金する時点で利用可能な少なくとも１つのルールを判定する判定部と、前記取引を認可するために、前記少なくとも１つのルールを適用するプロセッサと、前記取引が認可される場合に、リアルタイムで、アカウントから課金するための前記少なくとも１つのルールに従って、前記アカウントから課金する課金部と、少なくとも１つの決済ルールに従って、複数の取引プロバイダに対してリアルタイム課金を決済する決済部とを備える。
【００９２】
上述の本発明の構成は、更に、ルールセットを採用する集中通信システムによって対応することができ、これは、現時点での取引を認可し、課金し、決済するための複数のルールをリアルタイムで判定する判定部と、認可済ユーザのアカウントあるいは前記認可済ユーザが、現時点の取引を認可するための前記複数のルールと合っている場合、前記取引を認可する認可部と、前記認可済ユーザのアカウントをリアルタイムで課金し、少なくとも１つの取引プロバイダアカウントに返金する課金部と、前記取引を決済するための前記少なくとも１つのルールに従って、前記取引を決済する決済部とを備える。
【図面の簡単な説明】
【００９３】
【図１】集中通信プラットホームを利用するシステムの実施形態である。
【図２】移動商取引用の集中通信プラットホームを利用するシステムの実施形態を示す図である。
【図３】プリペイドローミング用の集中通信プラットホームを利用するシステムの実施形態を示す図である。
【図４】消費者ケア用の集中通信プラットホームを利用するシステムの実施形態を示す図である。
【図５】集中通信プラットホームを利用する国際システムの実施形態を示す図である。
【図６】集中通信プラットホームを利用するシステムの実施形態を示す図である。
【図７】集中通信プラットホームで拡張データサービスを可能にするアーキテクチャの一例を示す図である。
【図８】集中通信プラットホームに対する課金の残高の実施形態を示す図である。
【図９】プリペイド通信アカウントに再入金する方法の一例を示す図である。
【図１０】集中通信プラットホームに対するいくつかのパーティ間での情報転送の一例を示す図である。
【図１１】ローミング中の移動商取引を構成するブロック図である。
【図１２】集中通信プラットホームでローミングサービスを要求するユーザの一例を示す図である。
【図１３】集中通信プラットホームで使用されるユーザ及び取引レコードの一例を示す図である。
【図１４】集中通信プラットホームのユーザアカウントの一例を示す図である。
【図１５】集中通信プラットホームで使用されるインタラクティブ音声応答システムの実施形態を示す図である。
【図１６】複数の決済に対する集中通信プラットホームのプリペイドアカウントの使用を示すフローチャートである。
【図１７】集中通信プラットホームにおける、複数のパーティの決済に対して、プリペイドアカウントに再入金し、ルールをセットアップする半自動化方法の一例を示す図である。
【図１８】集中通信プラットホームで調整レポートを生成する方法の一例を示す図である。
【図１９】集中通信プラットホームでのデータ転送の一例を示す図である。
【図２０Ａ】集中通信プラットホームでのリアルタイム決済の方法の一例を示す図である。
【図２０Ｂ】集中通信プラットホームでのリアルタイム決済の方法の一例を示す図である。
【図２１】集中通信プラットホーム用のアカウント管理装置の一例を示すブロック図である。
【図２２】集中通信プラットホームのスイッチマネージャー装置の一例を示すブロック図である。
【図２３】集中通信プラットホームを使用するビジネス間の取引の一例を示す図である。
【図２４】ビジネス間の商取引を行う集中通信システムのブロック図である。
【図２５】集中通信システムに対するアカウント再入金用システムの一例を示すブロック図である。
【図２６】集中通信プラットホームのインタラクティブ音声応答システムを使用する、プリペイドアカウント再入金用システムの一例を示すブロック図である。
【図２７】集中通信プラットホームによって使用されるセキュリティシステムの一例を示すブロック図である。
【図２８】決済機関として集中通信プラットホームを使用する複数パーティの決済の一例を示す図である。
【図２９】集中通信プラットホームの決済に対するベンダー情報のスクリーンショットの一例を示す図である。
【図３０】集中通信プラットホームにベンダー情報を追加するスクリーンショットの一例を示す図である。
【図３１】集中通信プラットホームに販売についての詳細を追加するスクリーンショットの一例を示す図である。
【図３２】集中通信システム用のルールリポジトリのテーブルの一例を示す図である。
【図３３】集中通信システムに対して決済を実現することができる装置の一例を示す図である。
【図３４】集中通信システムを利用する、高度なアカウント再入金の方法の一例を示す図である。
【図３５】集中通信システムを利用する、高度な取引認可の方法の一例を示す図である。
【図３６】集中通信システムを利用する、高度なリアルタイムアカウント課金の方法の一例を示す図である。
【図３７】集中通信システムを利用する、高度な決済処理の方法の一例を示す図である。
【発明を実施するための形態】
【００９４】
本明細書で説明するように、本発明の実施形態は、異種ネットワークを使用するための、及び集中化（あるいは集中）通信、集中化商取引及び集中化サービスのためのシステム、方法及びプラットホームに適用可能である。様々な産業用語及び頭字語が使用される一方で、いくつかの用語は、上述のように、以下の付加的な意味を持っている。
【００９５】
異種ネットワークの例には、異なるあるいは多様な技術要素あるいは部品の組み合わせからなるネットワークである。例えば、異種ネットワークには、次のようなものがある：ＧＳＭ及びＣＤＭＡのような様々な電気通信規格、ＧＳＭ９００及び１９００のような様々なバージョンの同一の電気通信規格、ノキア及びエリクソンのような様々なスイッチング環境、インテリジェントネットワーク（ＩＮ）あるいは非ＩＮ、ＩＳＤＮあるいはＳＳ７のような異なる異なるシグナリング（信号方法（signaling））、ＵＮＩＸ及びマイクロソフトウインドウズのような様々なオペレーティングシステム、ソラリス（ＳＵＮ）及びＡＩＸ（ＩＢＭ）のような異なる形態の同一のオペレーティングシステム、２．０及び２．１のような異なるバージョンの同一のオペレーティングシステム、ＩＢＭ及びコンパックのような異なるサーバハードウェア、ＣＤＭＡ及びＰＤＣのような異なるネットワークタイプであるが、日本のＫＤＤＩのような同一のオペレータ、異なる地域での異なるネットワークであるが、ボーダフォンのような同一のオペレータがあり得る。
【００９６】
集中の例は、より多くのサービスのレベルを提供するために、様々な技術とメディアを一緒に組み合わせることである。例えば、集中化通信は、次のものを組み合わせることができる：音声、データ、メッセージングのような様々なメディア、サービスプロバイダによって提供される、移動、固定あるいは衛星の音声、データ、メッセージング、同一のサービスプロバイダによって提供される音声、データ、メッセージングのような様々なメディア、異なるサービスプロバイダによって提供される、移動、固定あるいは衛星の音声、データ、メッセージング、異なるサービスプロバイダによって提供される移動、固定、衛星の音声、データ、メッセージングがある。集中化商取引は、電話、インターネット、電子商取引あるいは移動商取引（m-commerce）の組み合わせを含んでいる。集中化サービスは、通信及び商取引サービスの組み合わせを含んでいる。集中化会計は、すべての通信サービスに対し、１つに統合された請求書を提供する機能と、配信される内容あるいは商品に対する課金を含んでいる。集中化商取引は、取引に対するすべての課金を１つの取引と、追加料金、税金、電気通信料等の要素を含むコストに統合したものとみなすこともできる。集中化サービスは、消費者アカウントがローカルネットワーク上に存在しない場合でさえも、消費者アカウントにアクセスし、確認し、変更することができる単独のヘルプオペレータを提供するものとみなすこともできる。
【００９７】
集中インタフェースは、いくつかの必要かつ付加的なパラメータを構成することができ、これは、サードパーティ要素（群）が必要とする入力／出力パラメータを解析し、サードパーティ要素を本例の集中通信プラットホーム要素パラメータにマッピングし、ある衝突を解決するためにその要素を構成することによって、サードパーティシステムに組み込むように構成することができる。サードパーティシステムが、いくつかの付加的なパラメータを提供できない場合は、本例の集中通信プラットホームは、正常なマッピングを保証するためのダミーパラメータを生成することができる。
【００９８】
プラットホームの例には、付加的な試みを行うための基盤を提供するシステムを含んでいる。例えば、電話システムのような通信プラットホームは、様々な方法による通信に対してデータを流すことを可能にする。同様に、集中通信プラットホームは、様々な技術を併合して、拡張された移動商取引、電子商取引及び消費者ケアを可能にすることができる。
【００９９】
拡張されたサービスの例には、再フォーマッティングの機能が含まれている。拡張されたサービスは、例えば、あるシステムからのデータリクエストを再フォーマットすることができ、そうすることで、そのデータは第２のシステムで受信することができる、また、記憶された情報を参照する情報を再フォーマットすることができ、そのため、その再フォーマットされた情報には、発信装置で利用できない情報を含んでいる。
【０１００】
図１は、集中通信プラットホームを利用するシステムの例のブロック図である。図１に示されるように、消費者は、自身の入力１０から、ＩＰ装置２１、無線装置２３あるいは電話システムアクセス装置２５を介して、インターネット２２、無線ネットワーク２４あるいは公衆交換電話ネットワーク２６と接続し、更に、ベンダー（即ち、サービスプロバイダ）サービス装置５０と接続している。ベンダーサービス装置５０は、更に、支払リクエスト５２を介して、集中通信プラットホーム１００と接続している。集中通信プラットホーム１００は、支払認可１０２をベンダーサービス装置５０へ返信する。次に、ベンダーサービス装置５０は、消費者入力１０に返信されるサービス／商品１１を配信することができる、あるいはその配信を確認することができる。
【０１０１】
このシステムの例では、移動商取引を取り交わそうとする消費者は、迅速かつ効率的に自身が希望するサービス／商品を受信することができる。例えば、消費者が電子音楽ベンダーからＭＰ３ファイルを購入したい場合、取引は、以下のように、動作し得る。
【０１０２】
消費者入力１０を操作する消費者は、ベンダーのサービス装置５０を介して音楽ベンダーに接続することを試行する。消費者入力１０は、ＩＰ装置２１、無線装置２３あるいは電話システムアクセス装置２５の内の任意の１つに接続することができる。ＩＰ装置２１は、ネットワークカード、ＷＡＰ接続装置、ＳＭＳメッセージング装置、あるいはインターネットプロトコルネットワークに接続するための、現在知られているあるいは将来開発される任意の他の装置であり得る。
【０１０３】
無線装置２３は、移動電話、セルラーフォン、あるいは無線波あるいは電磁波エネルギーを使用し、無線ネットワーク２４と通信する任意の他の装置であり得る。電話システムアクセス装置２５は、モデム、ルータ、ケーブルモデムあるいは、公衆交換電話ネットワーク２６と接続することができる任意の他の装置であり得る。
【０１０４】
インターネット２２は、スイッチ、ルーター、ハブ、マイクロ波装置あるいはある地点から他の地点へインターネットプロトコルメッセージを転送することができる他の通信装置の任意の組み合わせであり得る。無線ネットワーク２４は、無線局及びスイッチ、無線装置２３がベンダーサービス装置５０に接続することができるような他の装置からなる任意のシステムであり得る。
【０１０５】
公衆交換電話ネットワーク２６は、回線交換、パケット交換、あるいはベンダーサービス装置５０と電話システムとを接続するように適合されている他の装置の任意の組み合わせであり得る。
【０１０６】
消費者入力１０が無線装置２３であり、かつ無線ネットワーク２４を介して、ベンダーサービス装置５０と接続している場合、ベンダーサービス装置５０は、消費者１０がベンダーサービスプロバイダ５０からＭＰ３を購入するためのリクエストを適切に特定することができるような、モールスあるいは数字列認識システムであり得る。
【０１０７】
ベンダーサービス装置５０は、ウェブサーバ、ボイスサーバ、ＳＭＳメッセージングサーバあるいは、移動商取引を行い、消費者入力１０にサービスあるいは商品の配信あるいはその配信の確認を行うことができる無線アクセスプロトコル（ＷＡＰ）サーバの任意の組み合わせであり得る。ベンダーサービスプロバイダ５０は、ＭＰ３ファイルに対する消費者リクエストを受信し、支払リクエスト５２を生成する。支払リクエスト５２は、集中通信プラットホーム１００に返信される。
【０１０８】
次に、集中通信プラットホーム１００は、ユーザあるいは消費者が、認可ユーザであり、この種の移動商取引を行うために、ユーザのアカウントが認可されており、その消費者アカウントが、そのサービスを可能にするための十分なお金あるいは資産を含んでいるかをチェックする。ユーザのアカウントが、正常な認可かつ資産を持っている場合、集中通信プラットホーム１００は、支払認可１２０を生成し、それをベンダーサービス装置５０に返信する。
【０１０９】
次に、ベンダーサービス装置５０はサービスあるいは商品を生成し、ＭＰ３ファイルの場合、インターネット２２、無線ネットワーク２４、公衆交換電話ネットワーク２６あるいは他の転送（shipping）ネットワークの任意の１つによって、そのＭＰ３ファイルを、消費者ネットワークあるいは消費者入力１０へ送信する。
【０１１０】
様々な実施形態において、上述の手順は、広い範囲あるいは狭い範囲で、システムによって自動化することができる。完全な自動化環境では、消費者入力１０は、無線ネットワーク２４に対する無線装置２３と接続されているＭＰ３プレーヤーであり得り、これは、認可及び転送データのどちらかをベンダーサービス装置５０へ自動的に送信する。つまり、すべてのユーザがするべきことは、装置を起動し、新規のＭＰ３ファイルを購入しようとする装置を選択することである。次に、装置は、自動的にＭＰ３ベンダーに接続し、購入を行うユーザに対して音楽のリストを表示する。そして、ユーザは、自身が購入したい音楽を選択し、バックグラウンドで発生する他の個々のタスクのすべてとして、その音楽のダウンロードを開始する。
【０１１１】
別の実施形態では、ＰＩＮ、スマートカード、磁気読出／書込装置、バーコード、磁気テープ、浮き彫り（raised）の英数字、あるいは、現在知られているあるいは将来開発される、あるいは図２７で説明される任意の他の不正防止方法を使用して、サービス／商品及び支払リクエストの認可の付加的なセキュリティが利用されても良い。
【０１１２】
図２は、移動（ｍ）−商取引あるいは電子（ｅ）−商取引における集中サービス装置を利用するためのシステムの例を示すブロック図である。図２に示されるように、消費者入力１００は、サービスリクエスト１０５をベンダーサービス装置１１０へ送信する。次に、ベンダーサービス装置１１０は、認可リクエスト１１５を集中サービス装置２００に送信する。次に、集中サービス装置２００は、認可許可１２４をベンダーサービス装置１１０へ送信し、支払通知１３５を消費者入力装置１００へ送信する。そして、集中サービス装置２００は、ベンダー１４０に対する銀行あるいは金融機関に支払１５０を送信し、支払１５５を荷主１６０に送信する。
【０１１３】
本実施形態では、自身の入力装置１００を介して、消費者は、映画のチケットを購入することを要求している。消費者は、自身の消費者装置１００を開始する、あるいはそれを起動することで、サービスリクエスト１０５がベンダーサービス装置１１０へ送信される。ベンダーサービス装置１１０は、音声認識あるいはデジタル解析用の、現在知られているあるいは将来開発される装置であり得り、そうすることで、ユーザは、自身が来訪したい特定の映画館の特定の映画のチケットを選択することができる。加えて、ベンダーサービス装置１１０は、映画だけではなく、任意の周知のビジネスに対して操作を行うことができる。例えば、コンサートのチケットあるいは他のアイテムを購入することができる。
【０１１４】
ユーザは、サービスリクエスト１０５をベンダーサービス装置１１０に入力した後、ベンダーサービス装置１１０は、認可リクエスト１１５を生成することができる。認可リクエスト１１５は、消費者ＩＤ、サービスに対するコスト、ベンダー識別子（ＩＤ）のような情報を含み得る。
【０１１５】
集中サービス装置２００が一旦、認可リクエスト１１５を受信すると、ユーザＩＤに関係付けられているユーザのプリペイドアカウントをチェックし、アカウントが映画のチケットの購入に対して認可されているかをチェックし、消費者のアカウントに十分な残高があるかをチェックすることができる。アカウントに十分な残高がある場合、その取引に対してアカウントが認可され、そのアカウントは有効アカウントとなり、集中サービス装置は、認可許可１２５をベンダーサービス装置１１０へ送信し、かつ支払通知１３５を消費者入力装置１００へ送信することができる。
【０１１６】
次に、消費者は、現在知られているあるいは将来開発される任意の方法によって、映画館から映画のチケットを受け取ることができる。例えば、ユーザは、自動発券（dispensing）装置識別番号を入力して、映画チケットを単に発券する自動発券装置を利用することができる。他の手段が従来より知られており、例えば、認可コードを既存装置に入力し、その装置自身をベンダー会社に明らかにするフェデラルエクスプレス配送を、従来より良く知られているものとして使用することができる。
【０１１７】
様々な実施形態では、集中サービス装置２００は、支払をベンダーサービス装置１１０へ送信でき場合がある。集中サービス装置２００は、その支払を、ベンダー１４０に関連する銀行あるいは金融機関に送信することができる。選択的には、集中サービス装置２００は、消費者あるいはユーザに関連する銀行あるいは金融機関から、ベンダー１４０の銀行あるいは金融機関への送金を簡単に認可することができる。加えて、集中サービス装置２００は、配達を行うことができる荷主１６０への支払を認可することができる。
【０１１８】
図３は、集中通信プラットホームでプリペイドローミングを可能にするシステムの例を示す図である。図３では、エリア３１０は、内部に、消費者１、消費者２、電話スイッチＡ、サービスマネージャーＡ及びアカウントマネージャーＡを持っている。アカウントマネージャーＡは、消費者１、消費者２及び消費者３に対する消費者アカウントを含んでいる。エリア３２０は、内部に、消費者３、消費者４、電話スイッチＢ、サービスマネージャーＢ及びアカウントマネージャーＢを持っている。アカウントマネージャーＢは、消費者４、消費者５及び消費者６に対する消費者アカウントを含んでいる。エリア３３０は、内部に、消費者５、消費者６、電話スイッチＣ、サービスマネージャーＣ及びアカウントマネージャーＣを持っている。エリア３１０、エリア３２０及びエリア３３０は、公衆交換電話ネットワーク３００及びワイドエリアネットワーク（ＷＡＮ）３５０によって接続されている。
【０１１９】
ワイドエリアネットワーク３５０を使用することは、プリペイドローミングを可能にするためののアカウント情報の送信に安全性を持たせることである。つまり、すべての消費者１−６のすべてが、エリア３１０あるいはエリア３２０でアカウントを持つプリペイド消費者である場合、本実施形態は、かれらが存在するエリアに関係なく、自身のプリペイドアカウントを使用することを可能にする。様々な例を、以下に説明する。
【０１２０】
プリペイドローミングは、以下のステップで示されるように動作することができる。エリア３１０内の消費者２に発呼を行う探索を行うエリア３１０の消費者１は、自身の装置を起動する。消費者１の装置が起動される場合、電話スイッチＡは信号を取得して、サービスリクエストをサービスマネージャーＡへ送信する。次に、サービスマネージャーＡは、アカウントマネージャーＡを用いて、消費者１が有効な消費者であり、かつそのアカウントに残っているアカウント残高あるいは金額を持っているかをチェックする。また、サービスマネージャＡは、消費者２が、電話発呼を受信するために、そのアカウントから引き出せるアカウント残高あるいは金額を持っている有効な消費者であるかをチェックする。サービスマネージャーＡは、すべてのアカウント情報が正しいことが明らかになった後、発呼を終了する。
【０１２１】
しかしながら、エリア３１０内の消費者１がエリア３２０内の消費者３に発呼したい場合、既存のシステムの下では、問題が発生する。消費者１は自身の装置を起動し、消費者３の識別番号を入力する。次に、電話スイッチＡは、サービスリクエストを受信し、それをサービスマネージャーＡへ送信する。次に、サービスマネージャーＡは、消費者１及び消費者３が有効な消費者であるかをチェックし、通信を完了することを試行する。次に、サービスマネージャーＡは、電話スイッチＡ及び公衆交換ネットワーク３００を介して、消費者３に到達するための試行を行うように動作する。しかしながら、電話スイッチＢでは、消費者３がアカウントマネージャーＢを有するアカウントを持っていないので、電話スイッチＢは、電話発呼を完了するための認可を行えない。
【０１２２】
しかしながら、本発明の様々な実施形態では、電話スイッチＢは、サービスリクエストをサービスマネージャーＢに送信する、これは、消費者３がアカウントマネージャＢ内のアカウントを持たないようにし、そのリクエストをワイドエリアネットワーク３５０を介してサービスマネージャーＡへ送信することである。次に、サービスマネージャーＡは、消費者３が、自身のアカウントに残りの金額を持つ有効な消費者であるかを検証する。次に、サービスマネージャーＡは、ワイドエリアネットワーク３５０を介するサービスマネージャーＢへの発呼を認可し、電話スイッチＢへ発呼を完了することを通知する。消費者１あるいは消費者３が電話の会話中にお金あるいはアカウント残高を使い尽くしてしまった場合、サービスマネージャーＡは、信号を電話スイッチＡへ送信して、あるいはワイドエリアネットワーク３５０を介してサービスマネージャーＢへ送信して、電話の会話を停止する。
【０１２３】
プリペイド電話サービスに対する既存システムにおいて、消費者１が消費者４に電話をかけたい場合、消費者１は自身のユーザ装置を起動して、消費者４に電話をかける。サービスリクエストは、電話スイッチＡによって受信され、次に、それは、アカウントマネージャーＡの消費者１のプリペイドアカウントが現存している場合、信号をサービスを認可するサービスマネージャーＡへ送信する。次に、サービスマネージャーＡは、受信する消費者４が自身のアカウントの一部でもなく、自身のネットワーク上にも存在していなくても、サービスを認可する。次に、電話スイッチＡは、交換電話ネットワーク３００を介してサービスリクエストを電話スイッチＢへ送信する。次に、電話スイッチＢは、消費者４が自身のエリア内に存在するかをチェックし、サービスマネージャーＢを用いて消費者４がアカウントを持っているかをチェックする。アカウントマネージャーＢを用いてチェックを行うサービスマネージャーＢは、消費者４が残高を持っているカレントアカウントホルダーであるかを検証する。次に、サービスマネージャーＢは、電話スイッチＢを認可して、電話発呼を完了し、そして、消費者４に電話がかかる。
【０１２４】
しかしながら、エリア３１０内の消費者１がエリア３３０内の消費者５に到達したい場合、周知のシステムは、上述で詳細した理由のために動作しない。しかしながら、本発明の様々な実施形態の下では、消費者１は自身のアクセス装置を起動して、消費者５への発行を試行する。電話スイッチＡは、サービスリクエストを受信して、クリアランスリクエストをサービスマネージャーＡへ送信する。次に、サービスマネージャーＡは、アカウントマネージャーＡを用いて、消費者１が残高を持つ有効な消費者であり、かつ消費者５が自身のネットワーク上の消費者でないことをチェックする。次に、電話スイッチＡは、公衆交換電話ネットワークを介してサービスリクエストを電話スイッチＣへ送信し、ここで、電話スイッチＣには、消費者５が自身のエリアに存在していることが登録されている。次に、電話スイッチＣは、消費者５がアカウントマネージャーＣ内のアカウントを持っていないことを検証するサービスマネージャＣへ処理が進む。次に、サービスマネージャーＣは、ワイドエリアネットワーク３５０を介して、通信を認可することを、アカウントマネージャーＢに問い合わせる。アカウントマネージャーＢでの、消費者５が残高を持っている有効な消費者であることのチェックの後、サービスマネージャーＢによって通信が一旦認可されると、電話スイッチＣは、消費者間の電話発呼を認可し、完了する。
【０１２５】
いくつかのケースを、以下にまとめることができる。
【０１２６】
ケース１：消費者１及び消費者４の両方が、ホームネットワークに存在し、消費者１が消費者４へ電話する。
【０１２７】
１．消費者１が消費者４へ電話する。
【０１２８】
２．消費者１がプリペイド加入者であるので、電話スイッチＡは信号をサービスマネージャＡに転送する。
【０１２９】
３．サービスマネージャーＡは、信号をアカウントマネージャーＡへ転送する。
【０１３０】
４．アカウントマネージャーＡは、消費者１の個人識別がホームネットワークに属しており、ＤＮＩＳ（消費者４のＭＳＩＳＤＮ）がネットワーク３１０に属しておらず、かつ発呼がネットワーク３１０から発信されていることを識別する。
【０１３１】
５．サービスマネージャーＡは、消費者１を認証し、かつ電話スイッチＡにリプライする。
【０１３２】
６．電話スイッチＡは、公衆交換電話ネットワーク（ＰＳＴＮ）を介して、発呼を電話スイッチＢへ送信する。
【０１３３】
７．電話スイッチＢは、ＰＳＴＮをネットワークを介して、発呼を受信し、かつ消費者がプリペイドであることを示す信号をサービスマネージャーＢへ転送する。
【０１３４】
８．サービスマネージャーＢは、信号を受信し、かつアカウントマネージャーＢを介して消費者４を認証する。
【０１３５】
９．サービスマネージャＢは、ＭＡＰクエリーを送信し、かつ消費者Ｂに対して在圏電話スイッチＢを配置する。
【０１３６】
１０．サービスマネージャーＢは、ページ信号を電話スイッチＢへ送信する。
【０１３７】
１１．電話スイッチＢは、消費者４のページングを開始する。
【０１３８】
１２．消費者４が発呼サービスに応答すると、サービスマネージャーＢは、消費者４に対するレイティングを開始し、かつサービスマネージャーＡは消費者１に対するレイティングを開始する。
【０１３９】
ケース２：消費者４が自身のホームネットワークに存在し、かつ消費者３が消費者４のホームネットワークにローミング中であり、消費者３が消費者４へ電話する。
【０１４０】
１．消費者３が消費者４へ電話する。
【０１４１】
２．消費者３はプリペイド加入者であるので、電話スイッチＢは信号をサービスマネージャＢに転送する。
【０１４２】
３．サービスマネージャーＢは、信号をサービスマネージャーＡへ転送する。
【０１４３】
４．サービスマネージャーＡは、消費者３がホームネットワーク３１０に属しており、かつ消費者４がネットワーク３１０に属していないことを識別する。
【０１４４】
５．サービスマネージャーＡは、消費者３を証明し、かつ電話スイッチＢに信号を転送する。
【０１４５】
６．電話スイッチＢは、消費者がプリペイド加入者であることを示す信号をサービスマネージャーＢへ転送する。
【０１４６】
７．サービスマネージャーＢは、アカウントマネージャーＢを介して、ネットワーク３２０に属する消費者４を認証し、かつＭＡＰクエリーを送信して、消費者４に対し在圏ＭＳＣを配置する。
【０１４７】
８．電話スイッチＢはリプライバックを行い、発呼が指示される。
【０１４８】
９．電話スイッチＢは、消費者４に対するページングを開始する。
【０１４９】
１０．消費者４が発呼に応答すると、サービスマネージャーＢは消費者４のレイティングを開始し、かつサービスマネージャーＡは消費者３に対するレイティングを開始する。
【０１５０】
ケース３：消費者５及び消費者３の両方がローミング中であり、消費者５が消費者３へ電話する。
【０１５１】
１．消費者５は消費者３へ電話する。
【０１５２】
２．消費者５のＩＭＳＩ（あるいは任意の固有識別子）の検証後、電話スイッチＣは消費者５をプリペイド加入者として判定し、信号をサービスマネージャーＣへ転送し、それはサービスマネージャーＢへ転送する。
【０１５３】
３．サービスマネージャーＢは消費者５をローミング加入者として識別し、かつアカウントマネージャーＢへクエリーを発行することによって、それを認証する。
【０１５４】
４．サービスマネージャーＢは、消費者５が更なるルーティングに対して有効であることを、サービスマネージャーＣへリプライバックする。
【０１５５】
５．サービスマネージャーＣは、認可を電話スイッチＣへ転送する。
【０１５６】
６．電話スイッチＣは、ＰＳＴＮを介して、消費者３がプリペイド加入者であることを示す信号を電話スイッチＡへ転送する。
【０１５７】
７．サービスマネージャーＡは消費者３を認証し、かつＭＡＰクエリーを送信して、消費者３の在圏ＭＳＣを配置する。
【０１５８】
８．サービスマネージャーＢは、サービスマネージャーＡへリプライバックを行い、これは、ルーティング情報を電話スイッチＣへ送信する。
【０１５９】
９．電話スイッチＣは、発呼を在圏ＭＳＣ、即ち、電話スイッチＢへ転送する。
【０１６０】
１０．電話スイッチＢは、消費者３に対するページングを開始する。
【０１６１】
１１．消費者３が発呼に応答すると、サービスマネージャーＡは消費者３に対するレイティングを開始し、かつサービスマネージャーＣは消費者６に対するレイティングを開始する。
【０１６２】
１２．どちらかのパーティが発呼を中止すると、サービスマネージャーＣは、ＷＡＮを介してアカウントマネージャーＢを更新する。
【０１６３】
図４は、ユニバーサルあるいはネットワーク独立型消費者サービスシステムの実施形態を示す図である。図４では、消費者４００は、経路４１４を介して公衆交換電話ネットワークあるいはＳＳ７ネットワーク４１０に接続して、サービスマネージャー（「ＳＭ」）４２０と通信する。サービスマネージャー４２０は、ワイドエリアネットワーク（「ＷＡＮ」）４３０を介して、アカウントマネージャー（「ＡＭ」）４４２、アカウントマネージャー４４４あるいはアカウントマネージャー４４６と接続することができる。次に、サービスマネージャー４２０は、消費者４００と任意のオペレータ／ベンダー１  ４６２、オペレータ／ベンダー２  ４６４あるいはオペレータ／ベンダー３  ４６３と接続するために、経路４１２を使用して消費者４００に再転送することができ、これらは、その消費者に自身の消費者ケアサービスを提供する適切なアカウントマネージャー４４２、４４４あるいは４４６とアクセスすることができる。アカウントマネージャー４４２は、データベース４５２の消費者情報、あるいはワイドエリアネットワーク４３０を介してデータベース４５４の消費者情報、あるいはワイドエリアネットワーク４３０を介してデータベース４５６の消費者情報に接続することができる。つまり、消費者は、その消費者の実際の位置に関係なく、消費者ケアサービスに対し発呼を行うための単一の電話番号を持つことができる。
【０１６４】
図５は、各オペレータが、自身のホームカントリー（ホーム地域）で複数のスイッチを動作させることを示す図である。それぞれは、集中化ローミングデータセンターモデルに基づいて、国際ローミングサービスに参加している。このデータセンターは、１つ以上の電話会社あるいはサードパーティのどちからによって管理され得る。図５に示されるように、オペレータ１  ５３２、オペレータ２  ５３４及びオペレータ３  ５３６は、Ａ国５３０に存在し、ＷＡＮあるいはＴＣＰ／ＩＰネットワーク５２０及びＰＳＴＮ＆ＳＳ７ネットワーク５１０の両方に接続されている。また、オペレータ４  ５４６、オペレータ５  ５４４及びオペレータ６  ５４２はＢ国５４０に存在し、かつＷＡＮあるいはＴＣＰ／ＩＰネットワーク５２０とＰＳＴＮ及びＳＳ７ネットワーク５１０の両方に接続されている。ＷＡＮあるいはＴＣＰ／ＩＰネットワーク５２０とＰＳＴＮ及びＳＳ７ネットワーク５１０の両方は、国際ローミングデータデータセンター５００に接続されている。国際ローミングデータセンター５００は、サーバ５０２、サーバ５０４及びサーバ５０６を含むことができる。
【０１６５】
サーバ５０２、５０４及び５０６のそれぞれは、上述のように動作することができ、消費者を認証し、かつサービスリクエストを転送する。つまり、図５は、上述のサービスマネージャー及びアカウントマネージャーが任意の位置に配置され得ることを示しているが、ホームネットワークの発呼エリア内に配置される必要はない。ネットワークは、ＧＳＭ、ＣＤＭＡ、ＴＤＭＡ、ＡＭＰＳ、ＤＡＭＰＳ、あるいは２．５Ｇ及び３Ｇを含む任意の他のネットワーク規格であり得る。スイッチを持ついくつかのＳＭ／ＡＭを介して動作する必要はなく、このスイッチは、メッセージを専用の集中通信プラットホームへ転送する。本例の集中通信プラットホームシステム内のスイッチは、それが国際ローミングデータセンターにインストールされる場合の選択要素であり、アドレスはローカルであり得る。そうでなければ、アドレスは、国際アドレスでなければならない。
【０１６６】
ローミング消費者に対する消費者ケアは、上述のように厳密に処理される場合がある。しかしながら、多くの国にまたがる多くのオペレータによる大規模な設備を用いて、各関係電話会社が自身のスイッチングサイトのすべてに呼制御装置（スイッチマネージャーサーバ）をセットアップしなければならいことは非現実的である。消費者アカウント管理及びビジネスサポートシステム（アカウントマネージャー）は、すべての関係電話会社によって使用され、自身のそれぞれの加入者を管理し、それらの料金体系の生成／管理及びスイッチマネージャー（群）にＩＭＳＩ／ＭＳＩＳＤＮ（固有の加入者識別子）情報を与える、これは、各消費者の発呼を識別し、レイティングを行う。アカウントマネージャーは、ビジネスの状況に応じて分散できたり、できなかったりする。
【０１６７】
図６は、集中化アカウントマネージャー６７２を示す図である。一例では、あるアカウントマネージャーを、集中化形態でいくつかの電話会社に提供することができる。別の例では、より高度な分散形態で配置される複数のアカウントマネージャーを持つこともでき、各アカウントマネージャーは、特定の電話会社あるいはそれらの任意の組み合わせに提供される。図６に示されるように、ユーザ６１５は、無線あるいはセルラー局６９０を介して、セルラー電話スイッチ６７８に接続することができる。セルラー電話スイッチ６７８は、ＰＳＴＮ６５０及びスイッチマネージャー６７４に接続されている。スイッチマネージャー６７４は、ネットワークを介して、インタラクティブ音声応答（ＩＶＲ）サーバ６８６、シンプルメッセージサーバ（ＳＭＳ）６８４、ボイスメールサーバ（ＶＭＳ）６８２、ネットワークアカウントサービス（ＮＡＳ）ユニット６８０、ファイヤーウォール６７６、アカウントマネージャー（ＡＭ）６７２及びキャタリスト（catakyst）ハブ６４０と接続されている。ＩＶＲサーバ６８６は、ヘルプデスク６８８に接続されている。ＡＭ６７２は、データベース６７０に接続されている。キャタリストハブ６４０は、アクセスサーバ６２８、ＩＶＲサーバ６３２、電子モバイルポータルコマースサーバ６３０、プロキシサーバ６２６及びセキュリティサーバ６２４に接続されている。ホーム／オフィスユーザ６１０は、インターネット６００に接続されており、これは、ＰＳＴＮ６５０及びサイトルータ６２０に接続されている。サイトルータ６２０は、ファイヤーウォール６２２を介して、プロキシサーバ６２６に接続されている。
【０１６８】
つまり、図６に示される集中通信システムは、国際ローミングデータセンターを使用可能にすることができ、かつサービスを提供するための様々な専用サーバを収容することができる。例えば、ＮＡＳユニット６８０は、レイティング算出サーバとして設計することができる。様々なビジネス慣習を収容するための他の変形及び構成を、本発明の精神及び範囲から逸脱しないで組み込むことができる。
【０１６９】
つまり、スイッチマネージャーは、国際ローミングデータセンター（ＩＲＤＣ）内に集中化することできる。各関連ネットワークは、シグナリングリンク（ＳＳ７等）を介して、セントラルスイッチマネージャーに接続することができる。これが可能になると、各関連ネットワークオペレータは、オペレータのローミングサービスを管理するために、ＩＲＤＣで動作するサービスマネージャーのあるインスタンスのみが必要となる。単独のサーバ上にいくつかのサービスマネージャーインスタンスを配置することが可能である、あるいは各インスタンスは、自身が所有する専用サーバ上で、あるいはあるサービスマネージャーサーバが他のサーバに対するバックアップ／スタンバイとして動作する構成上で動作しても良い。
【０１７０】
各オペレータに割り当てられるＳＭは、上述のローミングセクションで説明されている各ＳＭの機能を組み合わせる。各オペレータの領域内の各ＭＳＣは、発呼者を識別し、自身のホームネットワークが関連ローミングパートーナーであるかを検証し、それらを自身のＭＳＲＮＮに割り当てたりする。ＭＳＣがＳＭへの信号をハンドオフする場合、制御トラフィックは、スイッチルームからＩＲＤＣへ遷移するのではなく、国際ＳＳ７ネットワークからＩＲＤＣへ遷移する。ＳＭは、発呼発信地点を識別し、発呼者のホームロケーションを判定することができる。次に、ＳＭは、認可を行い、発信スイッチネットワークコード（及び発信発呼ＩＤ等）、発呼に対するＭＯＣ及びＭＴＣ部分に対する適切なレイティングテーブルに基づいてレイティングを行いう。
【０１７１】
上述したように、内部オペレータ決済は、ＩＲＤＣで処理される。規則に基づく収入の分割が管理され、リアルタイム、日毎、週毎あるいは月毎で、ネット収入の決済が実行される。本理恵のの集中通信プラットホームは、以下のように、異種ネットワークを介して発呼を処理する。
【０１７２】
１．ＳＭ＆ＡＭは、複数のネットワークタイプに対し、ＧＳＭ、ＣＤＭＡ、ＴＤＭＡ、ＡＭＰＳ等に対するネットワーク特定情報、シグナリングパラメータ制御情報、加入者認証特定情報及び通信プロトコル情報を構成することができる。
【０１７３】
２．ローミング契約及びルールは、サービスと商取引に対するオペレータ間の関係に対し、料金、追加料金、税金、決済形態、期間、アカウント情報等毎にセットアップされる。
【０１７４】
３．加入者設定：サービスプロファイル情報、ローミングに対する利用可能なネットワークタイプと、各ネットワークタイプに対する加入者識別情報を含んでいる。
【０１７５】
４．発呼は、以下の方法で処理することができる。
【０１７６】
ａ．ＳＭは、着信発呼信号を受信する。
【０１７７】
ｂ．ネットワークタイプを識別する。
【０１７８】
ｃ．ネットワークタイプ（即ち、固有の識別子）に対して必要とされる情報をチェックする。
【０１７９】
ｄ．これが、ホームあるいは来訪ネットワークの発呼であるかをチェックする。
【０１８０】
ｅ．そのネットワークタイプに対して必要とされる適切なパラメータを使用して、ホームネットワークへの信号を生成する。
【０１８１】
ｆ．来訪ネットワークに戻るユーザ／加入者を認証し、加入者サービスプロファイルからサービス有効性を確認する。
【０１８２】
ｇ．ユーザのアカウントに対する来訪ネットワークタイプからの発呼をレイティングする（残高をチェックし、利用可能性を確認する）。
【０１８３】
ｈ．残高が使い尽くされるあるいは発呼が終了する場合、ＳＭは、終了を確認し、後取引情報をホームネットワークデータベースに送信し、決済を指示する。
【０１８４】
ビジネスが益々競争的になるにつれて、モバイルオペレータは、データ、ファックス、シンプルメッセージサーバ及び移動商取引のような、いくつかの付加価値サービスを自身のホームネットワークの消費者に提供することを広範囲で模索している。また、これらの付加価値サービスは、益々、ポストペイドローマーに提供されている。モバイルオペレータは、このようなサービスをプリペイドローミング加入者にも提供しようとしているが、それは、自身のオペレータ専用装置及びシステムに制限されている。
【０１８５】
図７は、電話管理システム７２０、ＳＭＳサービス管理システム７２２、ＦＡＸサービス管理システム７２４、データサービス管理システム７２６及び他の「ＸＹＺ」管理システム７２８を有する移動ネットワーク７１０を示す図である。
【０１８６】
消費者に課金されるこれらのサービスのいくつかは、時間単位あるいは他のイベント単位で実現され得る。実生活での構成は、シグナリングリンクを介して、付加価値サービスのすべての認可／使用を制御できるようにしても良いし、あるいはしなくても良い。電話サービスは、シグナリングリンクを介して制御することができるが、ファックスや移動商取引のようなサービスに対しては、シグナリングリンクを介する認可／使用の制御は実現できくなくても良い。
【０１８７】
プリペイドローミング加入者へこのような付加価値サービスを提供する電話会社あるいは他の通信オペレータに対しては、頻繁な間隔（例えば、１分毎あるいは５分毎）で使用記録が収集され、かつ処理される、いくつかのインタフェースが構築される必要がある。しかしながら、高額の取引の可能性を考慮すると、商取引サービスは、取引が発生すると同時に処理される必要がある。
【０１８８】
図７は、集中通信プラットホームシステムの実施例が、プリペイドローマーに対し、そのような付加価値サービスの使用を、どのようにして管理するかを説明している。移動ネットワーク７１０は、電話管理システム７２０、ＳＭＳサービス管理システム７２２及びＦＡＸサービス管理システム７２４と、データサービス管理システム７２６あるいは他の「ＸＹＺ」管理システム７２８にアクセスすることができる。電話管理システム７２０は、電話レイティング７４０にアクセスすることができる、これは、集中通信プラットホームプリペイドアカウント及び残高７５０に接続することができる。ＳＭＳサービス管理システム７２２、ＦＡＸサービス管理システム７２４、データサービス管理システム７２６及び他の「ＸＹＺ」管理システム７２８は、ゲートウェイ７３０に接続することができ、これによって、ＳＭＳ用拡張データサービスレイティング７４２、ファックス用拡張データサービスレイティング７４４、データ用拡張データサービスレイティング７４６及び拡張データサービスレイティング７４８と接続する。ＳＭＳ用拡張データサービスレイティング７４２、ファックス用拡張データサービスレイティング７４４、データ用拡張データサービスレイティング７４６及び拡張データサービスレイティング７４８は、集中通信プラットホームプリペイドアカウント及び残高７５０に接続することができる。
【０１８９】
付加価値サービスが認可される前に、外部システム（即ち、付加価値サービスを提供しているシステム）は、一例の集中通信プラットホームシステムにゲートウェイ７３０を介してリクエストを行う。集中通信プラットホームシステムの一例の詳細は図７に示されていないが、その詳細は、本明細書で説明される及び／あるいは明示される。レイティングテーブル、プリペイドアカウントが利用可能なアカウント残高及び許可済サービスプロファイル解析に基づいて、本例の集中通信プラットホームは、ゲートウェイ７３０を介して外部システムに対する取引を認可するあるいは拒絶する。認可された取引のそれぞれに対しては、外部システムは、付加価値サービスをプリペイドローマー消費者に提供する。使用の終了時（あるいは所定量の時間の終了時）には、外部システムは、拡張データレイティング（ＥＤＲ）を生成し、これは、ゲートウェイ７３０を介して本例の集中通信プラットホームシステムに送信される。外部集中通信プラットホームは、このようなレコードそれぞれに対してＥＤＲレイティング処理を初期化し、ＥＤＲを処理し、かつ本例の集中通信プラットホームデータベースに消費者アカウント残高情報を更新する。
【０１９０】
プリペイドローマーは、１つ以上の付加価値サービスを使用しながら、電話の使用を継続することができる。このような状況では、以下で更に説明されるように、本例の集中通信プラットホームシステムは、電話の使用に対して電話レイティング処理を初期化する。また、本例の集中通信プラットホームは、ＥＤＲレイティングテーブル、ＥＤＲルール及び処理を使用して、ＥＤＲ群を同時に処理する。デッドロック状態あるいは著しい残高不足を回避するために、本例の集中通信プラットホームは、電話サービスに対する金額をプリペイド消費者アカウントに優先的な割当を行う（例えば、ある所定期間の使用に対する料金を確保する）。また、このアーキテクチャにおいては、ＥＤＲのレコードが遅延されて登録されることによって、プリペイドローマーのユーザアカウント残高がゼロを下回ることが発生し得る。このような状況は、サービス認可リクエストが到達する場合に、付加価値サービスに対する事前割当金によって避けられる。
【０１９１】
例えば、来訪ネットワークエリアから、消費者が発呼を行う。本例の集中通信プラットホームは、以下のようにして、発呼レイティングを処理する。
【０１９２】
１．ＩＶＲ、立ち寄り（walk-in）、インターネット／モバイルインターネット、及び任意の他の手段を介して、加入者が発呼を行う。
【０１９３】
２．本例の集中通信プラットホームは、電話番号、ユーザから与えられるＰＩＮあるいは他の情報のどれかによって、あるいは自動あるいは手動の確認によって、加入者を確認する。
【０１９４】
３．ＩＶＲは、消費者ホームアカウントを配置する。
【０１９５】
４．ＩＶＲは、アカウント情報及びサービスプロファイルを取得するために、消費者ホームアカウントにクエリーを送信する。
【０１９６】
５．ＩＶＲは、クエリーを解析する／処理する：情報サービスがＣＣＣによって処理され、アカウント関連サービスクエリーは、本例の集中通信プラットホームを介してホームネットワークへの更なるクエリーを生成し、再入金サービスが、以下のようにして処理される。
【０１９７】
６．次に、消費者は、来訪ネットワークによって提供されるＷＡＰサービスを介してインターネットに接続し、かつ販売サイトを介して購入を行う。
【０１９８】
７．支払認可に対して、ＩＰネットワーク（公衆あるいは専用ネットワーク）を介して、ホームネットワークで本例の集中通信プラットホームに対し、販売サイト（あるいは任意の他のサービスプロバイダ）が認可を問い合わせる。
【０１９９】
８．次に、集中通信プラットホームは、ホームネットワーク認可データベースを用いて、消費者が商取引に対して認可され（サービスプロファイル確認）及び消費者の位置を取得しているかを検証する。
【０２００】
９．次に、集中通信プラットホームは、集中通信プラットホームコンポーネントへのリクエストを行い、これは、来訪ネットワークで発呼を処理する（分散アーキテクチャで、これらのコンポーネントは、来訪位置に存在し得る）。
【０２０１】
１０．集中通信プラットホームは、ＷＡＮリンクを介して、専用あるいは公衆ネットワークへのリクエストを行う。集中化アーキテクチャにおいては、これらのコンポーネントは、局所的に利用可能になっている。
【０２０２】
１１．集中通信プラットホームは、ネットワークを介して認可リクエストを行う。
【０２０３】
１２．認可が一旦成立すると、本例の集中通信プラットホームコンポーネント（このタイプに依存する、ホームネットワークあるいは来訪ネットワークのどちらか）は、情報の一貫性を保証するために、ホームネットワークデータベースに全部の取引を引き渡す。
【０２０４】
１３．決済ルールに基づいて、本例の集中通信プラットホームは決済を指示する。
【０２０５】
認可リクエストは、２つのタイプがあり得る。タイプ１：消費者の現在残高がどれくらいがを通知し、ブロック「Ｘ」の金額を商取引にあてる（「Ｘ」は、ローミング契約に基づいて、ホーム／来訪ネットワークによって課せられる認可と任意のサービス料金に対して、販売者によって要求される金額である）。このような状況では、最終認可が、ホームネットワーク自身によって処理される。タイプ２：商取引を処理し、かつ認可されている場合にはＸ金額分を控除する（「Ｘ」は、ローミング契約に基づいて、ホーム／来訪ネットワークによって課せられる認可と任意のサービス料金に対して、販売者によって要求される金額である）。このような状況では、これは、来訪ネットワークでの商取引レイティング処理となり、これは、取引を完全に処理し、かつ更なる処理のために決済レコードを生成する。
【０２０６】
別の例では、ローカルのネットワークＸに存在する消費者Ａが、ネットワークＺにローミングする。彼は、自身のプリペイドアカウントを満額にする、あるいは再入金する必要がある。本例の集中通信プラットホームは、これを、以下の方法で可能にすることができる。
【０２０７】
１．彼は、市場で、オペレータＺから証書（商品引換券）を購入する。
【０２０８】
２．彼は、ネットワークＺのＩＶＲ番号をダイヤルする。
【０２０９】
３．ＩＶＲシステムは、彼のＭＳＩＳＤＮ番号を読み出し、ネットワークコードから彼がローカルの加入者でないことを判定する。
【０２１０】
４．ネットワークＩＤを持つことで、ＩＶＲは、ＴＣＰ／ＩＰネットワークを介して、ネットワークＸのＬＡＵＴデータベースにクエリーを発行する、これは、購入された商品引換券の額に対し、消費者Ａのホームネットワークでの通話時間を判定する。
【０２１１】
５．次に、ＬＡＵＴデータベースは、ホームネットワーク上で更新される。
【０２１２】
この処理は、再入金に関連する任意の金額が、任意の来訪ネットワークで再入金されるとしても、その金額が常にホームネットワークに送金されることを保証する。ローミング発呼の成立に続いて、本例の集中通信プラットホームスイッチマネージャーによって課金される収益は、自身のローミング料金表（tariff）契約に従うパートナーネットワーク間で分配されなければならない。
【０２１３】
ローミング課金率契約は、いくつかの任意の場所に記憶することができる。この契約は、集中通信プラットホーム、別の課金サーバ、あるいはアカウントの決済をサポートする任意の他の場所に記憶することができる。加えて、決済に対するルールは、集中通信プラットホーム、別の課金サーバ、あるいはその契約に対するパーティによって決定される他の場所に記憶することができる。加えて、決済に対するルールは、集中通信プラットホーム、別の課金サーバ、契約に対するパーティによって決定される他の場所に記憶することができる。加えて、この契約は、集中通信プラットホームのオペレータと、そのオペレータとビジネスを行う会社群、消費者及び組織間で取り交わされ得る。
【０２１４】
任意の時間期間が経過した時点で、通常は日毎に、ローミング発呼に対するすべての発呼詳細レコード群（ＣＤＲ群）は、決済処理に渡される。選択的には、決済目的用の情報を送信するＴＡＰ／Ｃｙｂｅｒのような産業標準フォーマットで使用記録を生成することができる。これは、それぞれのオペレータのバックオフィスの一部とすることができる、あるいはアプリケーションサービスプロバイダ（ＡＳＰ）モデルを実行する情報センター（clearinghouse）を介して処理することができる。本例の集中通信プラットホームは、各オペレータの収入と、そのパートナーに関する収入とを比較して、最終的なネット送金（transfers）をまとめることができる。
【０２１５】
これらの取引は、集中通信プラットホームに記憶することができるが、本実施形態は、集中通信プラットホーム上で提供される多次元データベースの使用に対するものとなる。本実施形態が使用される場合、多次元データベースは、パートナーネットワークあるいはベンダー間の契約に従って様々な時間の様々な次元で取引のすべての構成を、ある次元として記憶することができる。また、アクセスが利用可能である場合、消費者は、自身の長距離キャリヤを選択しても良い。このような状況では、本例の集中通信プラットホームは、ホーム方式（plan）の長距離移動ネットワークの代りに、長距離キャリヤを用いて、来訪ネットワークでＰＳＴＮ移動体で終了された発呼を決済する。また、ホーム方式の長距離移動ネットワークと来訪方式の長距離移動ネットワークは、ホーム方式の移動ネットワーク及び来訪方式の移動ネットワークとすること（即ち、グローバル方式ローミングあるいは３Ｇネットワークをカバーすること）も可能である。また、ホームネットワークと来訪ネットワークは、ＧＳＭ技術に基づいていなくても良く、別の移動体技術に基づいていても良い。
【０２１６】
本例の集中通信プラットホームシステムは、プリペイドローミングサービス管理システムとして動作するために、電話会社と接続することができる。加えて、本例の集中通信プラットホームは、販売取引を管理するための販売システムと相互接続することもできる。各販売とネットワークパートナーそれぞれに対する決済ルールは、本例の集中通信プラットホーム決済システム上に構成することができる。本例の集中通信プラットホームは、提供されるサービスあるいは商取引に関連する支払取引を制御する。本例の集中通信プラットホームは、決済ルールに基づいて、サービス及び取引の少なくとも一方に関与するすべてのパーティに対する支払を決済する。
【０２１７】
ボリュームディスカウント、バンドル化サービスのような要素に対して、本例の集中通信プラットホームは、データテーブルに適切な情報を配置することができる。定期的に（例えば、毎分、毎日等）、本例の集中通信プラットホームは、そのような情報を解析し、かつそのようなサービスに対する決済を実行する。
【０２１８】
本例の集中通信プラットホームは、セントラルサイト（中央）に配置して、電話会社ネットワーク、販売ネットワーク及び保証人の消費者アカウントシステムに接続することができる。本例の集中通信プラットホームは、レイティングエンジンあるいは音声用テーブルと、データ及びイベントの少なくとも一方と、消費者のプリペイドアカウント間の動的対話を可能にする。ユーザの選択時に（いつも、あるいはユーザ定義基準に基づいて自動的に自身を選択するシステム）、お金を、保証人の消費者アカウント（任意のタイプのアカウント）から本例の集中通信プラットホームの消費者プリペイドアカウントに送金することができる。
【０２１９】
本例の集中通信プラットホームの消費者プリペイドアカウントは、商取引及び通信取引支払処理に対して使用される。消費者の残高が本例の集中通信プラットホームアカウントを使い尽くす場合、本例の集中通信プラットホームアカウントには、消費者の要求に応じて、例えば、銀行の投資信託会社の補償人の消費者アカウントやその類を介して、再入金することができる。また、本例の集中通信プラットホームは、そのプラットホームの単独の消費者のプリペイドアカウント上での商取引、通信及びデータ取引の並列処理を可能にする。各取引に対して、本例の集中通信プラットホームは、消費者へサービス及び取引の少なくとも一方の提供時に関与するすべてのパーティン間の支払を決済することもできる。
【０２２０】
例えば、ジョン  スミス（John Smith）が銀行アカウント（ＢＡ００１）と集中通信プラットホームアカウント（ＵＰ９８７）を持っている場合、ジョン  スミスは、自身の銀行アカウントＢＡ００１を自身のプリペイドプラットホームアカウントＵＰ９８７と関連付けることができる。もちろん、ＢＡ００１は、預金、当座、デビット（借入）、クレジットあるいは任意のタイプのアカウントとすることができる。また、銀行は、消費者の資産を保証する、いくつかの任意のタイプの事業体であり得る。銀行定義基準に基づいて、銀行は、ジョン  スミスによる集中通信プラットホームアカウントのある金額の保証人の立場となることに同意している。例えば、ＢＡ００１が消費者アカウントに１５００ドルを持っていても、銀行は集中通信プラットホーム消費者アカウント上限を１００ドルにすることを許容しても良い。本例の集中通信プラットホームアカウントの実際の金額は、ジョン  スミスの銀行取引履歴や銀行取引金額のようないくつかのファクターに依存してかなり変化し得るので、ジョン  スミスは、本例の集中通信プラットホームアカウントで、電話会社、販売コミュニティー、地方監督官庁等によって課される任意の期間及び状態を保とうとする。ジョン  スミスは、関連付けられている消費者の銀行あるいは保証人のアカウントを使用する再入金で、本例の集中通信プラットホームアカウントを使用する任意の移動商取引あるいは通信サービスに対して支払を行うために、本例の集中通信プラットホームプリペイドアカウントを使用することができる。
【０２２１】
例えば、ユーザが、自身の集中通信プラットホームアカウントの金額を使い尽くしている場合、そのユーザは、ＢＡ００１から自身のプラットホームアカウントに再入金することができる。消費者は、また、集中通信アカウント（いわゆる、ＵＰ００１、ＵＰ６５７等）に対するサブをアカウントを作成して、それを特定用途用（例えば、消費者にどのようなタイプのサービスが可能であるかの制約を持たせてあるいは持たせずに、自身の家族に贈り物をする、あるいはオンライン取引に対して１つのアカウントを使用し、かつオフライン取引に対して別のアカウントを使用する等）に使用することができる。消費者は、自身のサブアカウントのそれぞれに対して制限を設定することができる（予算管理）、あるいはすべてのサブアカウントに対しても併せて設定するフリーフロー制限としてメインアカウント制限（集中通信アカウント）を使用することができる。どのような場合でも、消費者の支払に対する銀行の保証は、本例の集中通信プラットホームアカウントに対して特定される金額に制限されている。
【０２２２】
また、ＢＡ００１は、単独のアカウントである必要はなく、かつＵＰ９８７の制約はＢＡ００１の一部である必要はない。例えば、ＢＡ００１は、仮想アカウントであり得る、これは、ジョン  スミスの金融有価証券（ジョン  スミスによって保有される、例えば、預金アカウントの残高、クレジットアカウント、当座アカウント、現在の市場価格の在庫資金／投資信託等）のすべてを組み合わせ、かつＢＡ００１の通貨単位で入金することを想定することができる。また、集中通信アカウントの上限は、ＢＡ００１アカウントの金額より高く、あるいは低く、あるいは同じにすることができる。
【０２２３】
本例の集中通信プラットホームは、以下の状況が可能である。：集中通信プラットホームアカウントの残高のみに基づく認可、集中通信プラットホームアカウントの残高に基づく認可、これは、プラットホームアカウントがリアルタイムあるいはほぼリアルタイムの取引（残高及びデビットのチェック）に対して認可されている保証人の消費者アカウントに統合する、かつ集中通信プラットホームアカウントの残高に基づく認可、これは、別の機関が、リアルタイム認可及びリアルタイム残高に基づいている現在の金額を保証する。
【０２２４】
いくつかの状況／市場では、銀行を介在させないことが可能である。このような状況では、デジタルデビットアカウントを、販売者あるいは販売コミュニティーのどちらかによって、あるいは電話会社によって、あるいはサードパーティによって、あるいはこれらのエンティティのすべてあるいはいくつかの組み合わせによって発行することができる。このデジタルデビットアカウントは、銀行以外のパーティがアカウントを発行する以外は、かなり類似する形態で動作する。この状況では、デジタルデビットアカウントの発行エージェンシーは、銀行あるいは金融機関をパートナーとしても良いし、あるいはしなくても良い。
【０２２５】
このデジタルデビットアカウントは、市場で現在利用可能な電子財布とは異なるものである。電子財布は、支払に関連する発行物のみに関係する。財布は、主に、認可される金額に着目している。これに対し、デジタルデビットアカウントは、消費者に関連する様々な構成に注目している（例えば、サービスを受信するあるいは購入するために、消費者が認可されているか否か）。また、電子財布は、継続する、時間単位の課金（例えば、電話発呼、分単位でのダウンロードで課金される音楽のダウンロード等）に関連する発行物にも関係しない。デジタルデビットアカウントは、これらの発行物に注目しており、適切な課金計算を可能にする。つまり、電子財布は、電子財布アカウント（これらは、使用するためのサードパーティに依存する）から、お金をいくら引き落とすかについての決定は行わない。集中通信プラットホームで使用されるデジタルデビットアカウントは、お金をいくら引き落とすかについての決定を行うことができる。
【０２２６】
本例の集中通信プラットホームは、セントラルサイト（中央）に配置することができ、サービスノードあるいは統合ネットワークノードのどちらかとして電話会社ネットワークと接続することができる。本例の集中通信プラットホームは、銀行の消費者アカウントシステム、あるいは消費者のクレジットカードシステム、あるいはオンライン／オフライン集中通信プラットホーム消費者アカウント再入金を可能にする任意のサードパーティシステムにも接続することができる。
【０２２７】
消費者に対し、本例の集中通信プラットホームアカウントは、２つのサブアカウントを生成することができる。例えば、１つのサブアカウントは、オンライン／リアルタイム取引用に使用され、これは、通信サービスあるいは商取引サービスあるいはそれらの両方に対するものとすることができる。もう１つのサブアカウントは、オフライン取引用に使用される。例えば、ジョン  スミスが、５０ドルの本例の集中通信プラットホームアカウントを持っている場合、彼は、アカウントＡに４０ドルを持たせて、これをオンライン／リアルタイム取引に対して使用する。ジョン  スミスは、もう１つのサブアカウントＢに１０ドルを持っている。この１０ドルは、ユーザの読出／書込メモリ装置（別々の読出／書込メモリ装置あるいは読出／書込メモリ装置として動作する電話機器あるいは任意の組み合わせ）に転送することができる。
【０２２８】
ジョン  スミスが、電話による発呼、あるいはインターネット上での音楽のダウンロード、あるいはリアルタイムレイティングを必要とする任意の取引を行う場合、本例の集中通信プラットホームは、自動的にあるいはユーザの選択（予め選択されている、あるいはユーザリクエストの時点で）によって、支払用にアカウントＡを使用する。ジョン  スミスがお店に行って、コーヒー、あるいはコーラ、あるいは新聞、あるいはオンライン／リアルタイム取引を許可していない任意の商品（群）を購入しようとする場合、本例の集中通信プラットホームは、自動的にあるいはユーザの選択によって（予め選択されている、あるいはユーザリクエストの時点で）、アカウントＢを使用することになる。売買の成立時に、装置が本例の集中通信プラットホームとのオンライン接続が可能である場合、本例の集中通信プラットホームは、取引／消費者プロファイルに関連する情報を（双方向で）更新することができる。
【０２２９】
サブアカウントＢの残高が使い尽くされると、本例の集中通信プラットホームは、消費者に（ユーザの選択によって、あるいはプリセットパラメータによって）、アカウントＡからアカウントＢへ送金させることを可能にする。ジョン  スミスがアカウントＢのお金を使い尽くしている場合、彼は、売買成立（読出／書込メモリ装置上で残高情報を更新するための装置を持つ）を行うことができ、かつ自身のアカウントに再入金することができる。例えば、ジョン  スミスは、お店に行って、１００ドルを支払い、自身の読出／書込メモリ装置が更新されている追加の１００ドルを取得し、次に、彼が、本例の集中通信プラットホームシステムとオンライン接続を行う売買装置を使用している場合、本例の集中通信プラットホームは、自動的に情報を更新し、かつ、ジョン  スミスの要求に応じて新規の１００ドルを彼のプリペイド  サブアカウントＡ及びＢに分割して入金する。
【０２３０】
本例の集中通信プラットホームは、電話会社、販売ネットワーク及び銀行の消費者アカウントシステムに接続することができる。本例の集中通信プラットホームは、消費者に、再入金用の可変構成ルールエンジンに基づいて様々な再入金基準を定義させることを可能にする。このような、ルールエンジンは、消費者に対して、以下のようなことを定義させることを可能にする：消費者が可能な様々な再入金手段（ＩＶＲ、ＡＴＭ、直接送金等）、アカウントに再入金する時間であるかどうかを特定する様々な基準、消費者アカウントにお金がいくら再入金されるかを判定する様々な基準がある。つまり、集中通信プラットホームシステムは、自身の消費者プリペイドアカウントに対して、ゲートウェイあるいは他の手段を介して多くのサービスを可能にすることができる。
【０２３１】
図８は、集中通信プラットホーム、システム及び方法を用いて通信サービスに対する課金の発生例を示している。図８は、課金のタイプ、課金決定先、引落先、ホームネットワーク及びローミングネットワークの負担額、及び課金決定単位に対する列を含んでいる。例えば、商取引は、サービス税、レンタル及び再入金料金を介して、ホームネットワーク内の移動発信発呼（ＭＯＣ）に対する支払を必要とするかもしれない。
【０２３２】
図９は、集中通信プラットホーム、システム及び方法に対して、プリペイド消費者アカウントへの再入金方法の例である。図９に示される方法は、自動再入金である。しかしながら、他のタイプの再入金も本
発明の範囲内であり、これには、消費者で再入金を確認する追加のステップ、銀行あるいはサードパーティで再入金を確認する追加のステップ、及び時間あるいは他の変数のチェックに関連する追加のステップを含んでいる。本方法は、ステップ９００で開始し、消費者プリペイドアカウントに十分なお金が存在するかを判定するために、９１０に進む。
【０２３３】
９１０でのアカウントに十分なお金があるかの判定において、判定は、プリペイドのユーザアカウントに値が存在するか否かの判定が行われる。そのアカウントに十分なお金がない場合、本方法は、再入金ルールがセットアップされているかを判定するために、９２０に進む。そのアカウントに十分なお金がある場合、本方法は、サービスを認可するために、ステップ９１２に進む。本方法がサービス認可ステップ９１２に進む場合、次に、本方法は、エンド９５０に進む。
【０２３４】
本方法が「再入金ルールセットアップ」ステップ９２０に進む場合、消費者が、自身のアカウントのプリペイド再入金を認可しているかどうかの判定を行う。消費者がアカウントの自動再入金を認可している場合、本方法は、「どこからの再入金？」ステップ９３０に進む。消費者が、自身のアカウントの自動再入金を認可していない場合、本方法は、サービス終了ステップ９２２に進む。本方法がサービス終了ステップ９２２に進む場合、本方法はエンド９５０に進む。
【０２３５】
本方法が「どこからの再入金？」９３０に進む場合、任意の銀行、クレジット、投資アカウントあるいは事前認可済ローンによってアカウントに再入金するための判定が行われる。「どこからの再入金」処理が銀行からの場合、本方法は、９３２の、銀行との電子商取引に進む。再入金がクレジットによる場合、本方法は、９３４の、クレジット会社との電子商取引に進む。再入金が投資アカウントからである場合、本方法は、９３６の、投資アカウントとの電子商取引に進む。再入金の形態が事前認可済ローンである場合、本方法は、９３８の、ローン会社との電子商取引に進む。再入金の形態に関係なく、本方法は、ステップ９４０に進む。ステップ９４０で、集中通信プラットホームは、プリペイド消費者のアカウントに再入金を行い、９１０の、十分なお金が消費者のプリペイドアカウントがあるかの判定に戻る。
【０２３６】
上述したように、ユーザは、いくつかのソースの任意のものから自身のアカウントに再入金することができる。この再入金は、ユーザ選択あるいはルールによって制御することができる。例えば、ユーザは、投資アカウントから、５０００ドルの再入金を行い、その後、クレジットアカウントから課金することを予め定義することができる。加えて、ユーザは、様々な変数、例えば、時間、アカウント残高、再入金金額及び他の要素に基づいて、再入金を認可することができる。各再入金アカウントに対して、集中通信プラットホームと再入金エンティティのオペレータとの両方の再入金エンティティと消費者間で、契約がセットアップされる、その契約は、再入金速度、決済時間、再入金エンティティからの不足額の通知、アカウント残高通知及び従来より知られている他の要素のような事柄を詳細に説明する。再入金アカウント、契約、ルール及び処理に関するデータは、集中通信プラットホームのアカウント及びサービスマネージャーの少なくとも一方に記憶されることが好ましい。
【０２３７】
図１０は、ディーラー１０１０、セールスエージェント１０２０、ユーザ１０３０、外部キャリヤ１０５０、企業及びホームアカウント１０４０、ＶＭＳ加入者１０６０及び集中サービスマネージャー１０００間の関係の例を示している。ユーザ１０３０は、注文あるいは注文取消を行い、ＰＩＮを集中サービスマネージャー１０００に入力することができる。これに対し、ユーザ１０３０は、サービスを受信することができる。ユーザ１０３０が受信するサービスの取引において、集中サービスマネージャー１０００は、企業及びホームアカウント１０４０からの支払を初期化することができる。ユーザ１０３０が自身のアカウントに再入金したい場合、そのユーザは、セールスエージェント１０２０に赴くことができる。次に、セールスエージェント１０２０は、集中サービスマネージャー１０００のアカウントに再入金する一方で、手数料を受け取ることができる。次に、集中サービスマネージャは、アカウントの再入金を、企業及びホームアカウント１０４０に送信することができる。アカウントに再入金されると、次に、ユーザは、ユーザが受信できるサービスに対するディーラー１０１０への支払を認可することができる。加えて、外部キャリヤ１０５０は、転送サービスのようなサービスに対する支払あるいは認可を受信することができる、また、仮想電話番号の再調停及びレイティング情報を、集中サービスマネージャ１０００に更新する。選択的には、ＶＭＳ加入者１０６０は、音声メールボックス情報、請求書及び証書、クエリー応答、歓待メッセージや支払催促状を維持するためのクエリーあるいは支払を受信することができる。
【０２３８】
図１１は、ローミングネットワークで移動商取引を可能にする集中システムの実施形態である。ユーザ装置１１３０は、ローミングネットワーク１１２０に接続する。ローミングネットワーク１１２０は、集中サービスプロバイダ１１５０に接続する。集中サービスプロバイダ１１５０は、インターネット１１００及び集中サービスプロバイダ１１４０に接続することができる。販売者１１６０及び１１７０は、インターネット１１００に接続することができる。次に、ホームネットワーク１１１０は、集中サービスプロバイダ１１４０にも接続することができる。集中サービスプロバイダ１０５０及び１１４０は、ともに、サービスのエリアの変化に伴って、集中通信システムを維持する機構である。
【０２３９】
動作としては、ユーザ装置１１３０は、ローミングネットワーク１１２０に存在している状態で、集中サービスプロバイダ１１５０に接続して、移動商取引を初期化することができる。集中サービスプロバイダ１１５０は、移動商取引に対するリクエストをホームネットワーク１１１０の集中サービスプロバイダ１１４０に送信する。集中サービスプロバイダ１１５０は、インターネット１１００にも接続して、販売者１１６０及び１１７０と連絡して、ユーザ装置１１３０へのサービスの配送、あるいはユーザ装置１１３０への商品の配送の確認を提供する。
【０２４０】
図１２は、本発明の実施形態に従うプリペイドローミングサービスアクティビティの例を示している。ホームネットワーク１２１２がイタリア１２１０である地点１２００にいる移動電話のプリペイドユーザであるティム（Tim）は、スペイン１２２０に旅行する、このスペインは、ローミングネットワーク１２２２を持っている。スペイン１２０１で、ティムは、自身のプリペイド消費者アカウントに再入金しようとする。次に、地点１２０１のティムは、ローミングネットワーク１２２２と接続し、ＳＳ７  １２４０とのリンク１２２４を確立し、集中サービスマネージャー１２５０とのリンク１２４２を確立する。次に、集中サービスマネージャー１２５０は、リンク１２４４、ＳＳ７  １２４０及びリンク１２２６を介して、ティムの現在のアカウント情報をローミングネットワーク１２２２に送信する。そして、ローミングネットワーク１２２２は、フランス１２３０の銀行１２３２に連絡して、集中サービスマネージャ１２５０のティムのプリペイド消費者アカウントに再入金することができる。
【０２４１】
図１３は、集中通信プラットホームに対するユーザのアカウントの情報データ及び構造の実施形態を示している。消費者アカウントは、ホームテーブル１３００、リクエスト情報テーブル１３１０及び認可情報テーブル１３２０を含むことができるが、これに限定されるものではない。ホーム情報テーブ１３００は、ホームメイン番号、タイトル、ファースネーム、ミドルネーム、ラストネーム、アドレス、電話番号、ファックス、電子メール、備考、職業、最終課金日、デポジット金額、クレジット上限、クレジット上限解消、現在残高、最終支払日、有効カード、状態及び状態変更日を含むことができるが、これに限定されるものではない。認可情報テーブル１３２０は、値、隔離時間（quarantine）、有効明細、使用済カウンタ、承認状態、最終承認シーケンス、トポロジーコード及び転送済ＲＯＣを含むことができる。リクエスト情報テーブル１３１０は、拡張コード、開始ストリング、受信範囲、ＰＩＮ番号、初期起動コード及び状態を含むことができるが、これに限定されるものではない。
【０２４２】
図１４は、集中通信プラットホームに対する音声メールシステムにリンクしている消費者アカウントの実施形態を示している。消費者アカウントは、消費者テーブル１４００、音声メールボックス１４１０を含むことができるが、これに限定されるものではない。消費者テーブル１４００は、パスワード、タイトル、ファーストネーム、ミドルネーム、ラストネーム、アドレス、電話番号、ファックス、電子メール、状態、状態変更日、プロファイルＩＤ、職業、言語ＩＤ、有効日、最終課金日、現在残高、最終支払日、備考及び歓待メッセージを含むことができるが、これに限定されるものではない。音声メールボックス１４１０は、オペレータ名、状態、受信用のインポートボックス番号を含むことができるが、これに限定されるものではない。音声メールシステムプロファイルは、詳細、総メッセージ長、各メッセージ長、メッセージ期限（age）、課金、延滞金、利子（interest）タイプ、案分、有効期限、有効日、デポジット及び総メッセージを追加することができ、また含んでいる。
【０２４３】
図１５は、集中通信プラットホームで使用することができる、インタラクティブ音声応答システムの実施形態を示している。図１５の方法は、スタート１５００で開始する。次に、本方法は、プロンプト（支払催促）番号１をユーザ１５１０に発信し続ける。１５１０で、プロンプト番号１がユーザに発信された後、本方法は、番号１５１２の待機に移動する。デジタル値が入力されると、本方法は、番号チェックを行うために、１５２０に進む。１５２０の番号チェックにおいて、番号が有効である場合、本方法は１５３０に進む。番号が無効番号である場合、本方法は、１５１４に戻る。
【０２４４】
１５１４において、最大試行回数に到達しているかどうかの判定が行われる。最大試行回数に到達していない場合、本方法は、１５１０で、プロンプト１をユーザに発信し続ける。最大試行回数に到達している場合、本方法は、１５６０で、プロンプト４を発信し続ける。
【０２４５】
１５３０のユーザへのプロンプト２の発信において、ユーザが番号を受信しているか、発信の終了となっているかの判定を行う。１５３０で、ユーザへのプロンプトが発信の終了となっている場合、本方法は、１５３２の待機に進む。１５３０で、ユーザへのプロンプトの発信が番号を取得している場合、本方法は、１５４０で、プロンプト３の発信を実行する。１５３２の待機においては、番号を取得するまで待機する。番号が一旦受信されると、本方法は、１５４０のユーザへのプロンプト３の発信に進む。
【０２４６】
次に、１５４０のユーザへのプロンプト３の発信は、それが発信の終了となっているかあるいは番号を受信しているか判定する。１５４０のユーザへのプロンプト３の発信が発信の終了となっている場合、本方法は、１５４２の番号の待機に進む。１５４０のユーザへのプロンプト３への発信が番号を受信している場合、１５５０の番号チェックに進む。１５５０の番号のチェックにおいて、番号が有効な番号である場合、本方法は、１５７０のショートコードと実際の番号のデータベースへの登録に進む。そうでなければ、本方法は、１５６０のプロンプト４の発信に進む。
【０２４７】
図１６は、複数の決済に対する集中通信プラットホームのプリペイドアカウントの使用を示すフローチャートである。プロンプト１は、集中通信プラットホームに、予め確立されているルールに基づいてパーティタイプを選択することをプロンプトすることができる。次に、パーティタイプは、選択しているパーティタイプ１６１０に入れることができる。選択しているパーティタイプ１６１０は、企業、ホーム、ディーラーあるいはセールスエージェントタイプの任意の１つとすることができる。パーティタイプが企業である場合、本方法は、部門１６１２の選択に移動する。パーティタイプがホームである場合、本方法は、ホーム１６１４の選択に移動する。パーティタイプがディーラーである場合、本方法は、ディーラー１６１６の選択に移動する。パーティタイプがセールスエージェントである場合、本方法は、セールスエージェント１６１８の選択に進む。
【０２４８】
選択されているパーティタイプに依存して、１６００の手数料のパーティコード及び支払に対する現在の金額を調べるために、適切なタイプのＩＤが送信される。これによって、ユーザは、プリペイドアカウントに再入金することができる、あるいはプリペイドアカウントを確立することができる。集中通信プラットホームにおける、１６００の手数料のパーティコード及び支払に対する現在の金額の調査中に、関連情報が記憶される。
【０２４９】
プロンプト２の支払方法は、集中通信プラットホームに、予め定義されているルールに基づく支払方法を選択することをプロンプトする。１６２０で選択する支払方法において、支払方法のタイプが、クレジットカード、銀行及び現金から選択される。クレジットカードが選択されている場合、本方法は、クレジット情報１６４０の入力に移動する。銀行が選択されている場合、銀行情報１６２２の入力に移動する。次に、本方法は、１６００の手数料のパーティコード及び支払に対する現在の金額の調査に移動する。
【０２５０】
次に、１６００のパーティコード及び支払に対する現在の金額の調査は、ａｍ＿ｄｉ＿ｉｎｆｏ１６３０、ａｍ＿ｈｏｍｅ＿ｉｎｆｏ１６３２、ｄｍｓ＿ｄｅａｌｅｒ１６３４、ｄｍｓ＿ｓａｌｅｓ＿ａｇｅｎｔ１６３６、ｐｐ＿ｉｎｓｔｒ１６３８、ｐｐ＿ｃｒｅｄｉｔ＿ｃａｒｄ１６４０、ｐｐ＿ｐａｉｄ＿ｔｒａｎｓ＿ｍａｉｎ１６４２、ｐｐ＿ｏｕｔｓｔａｎｄ＿ｐａｙｍｅｎｔ１６４４のいずれかに進むことができる。つまり、決済は、複数のパーティの取引となる。
【０２５１】
図１７は、集中通信装置内で発生し得る複数パーティの決済に対するプリペイドアカウントの再入金、ルールのセットアップの半自動化方法の実施形態である。本方法は、スタート１７００で開始し、１７０１のパーティタイプ及びコードの選択１７０１、あるいは１７１０のＯ／Ｓ支払リストの調査のどちらかに進む。
【０２５２】
本方法が、１７１０の現在及び決済（Ｏ／Ｓ）支払のリストの閲覧に進む場合、本方法は、最初のあるいは現在の支払手数料を判定する。次に、本方法は、１７２０の支払方法の選択に進む。１７２０の支払の選択において、本方法は、予め定義されているルールに基づいて、支払のタイプを判定する。ルールが現金を示している場合、本方法は、１７２２の現金に進む。ルールがチェックを示している場合、本方法は、１７２４のチェックに進む。ルールがクレジットカードを示している場合、本方法は、１７２６のクレジットカードに進む。
【０２５３】
ルールがチェック１７２４を示している場合、次に、本方法は、１７２５の銀行の介在に進む。ルールがクレジットカード１７２６を示している場合、本方法は、１７２７のクレジットカード情報の入力に移動する。次に、本方法は、集中通信プラットホーム上に予め記憶される適切な情報の入力後、取引レコード１７３０の入力に進む。そして、本方法は、エンド１７４０に進む。
【０２５４】
ルールがパーティタイプ及びコードを示している場合、次に、本方法は、ステップ１７１２に進む。パーティタイプ及びコードの選択時に、次に、本方法は、アカウント更新を必要とするパーティタイプを判定する。ルールが企業を示している場合、本方法は、１７０２の企業の更新に移動する。ルールがホームを示している場合、本方法は、１７０４のホームの更新に移動する。ルールがディーラーを示している場合、本方法は、１７０６のディーラー更新に移動する。ルールがセールスエージェントを示している場合、本方法は、１７０８のセールスエージェントの更新に移動する。そして、本方法は、エンド１７４０に進む。
【０２５５】
図１８は、集中通信プラットホーム及びシステムで使用するレポートを生成する方法の例を示している。本方法は、バッチ情報１８２０、プリント注文情報１８１０、ロット情報１８３０、プリントベンダー情報１８６０のあるいはすべてのカードタイプ１８５０のいずれかで開始することができる。次に、方法は、１８００のレポートの生成に進み、１８４０のレポートのプレビューに進む。本方法がバッチ情報１８２０で開始する場合、バッチ番号ユニットレート及びバッチ番号は、集中通信プラットホーム上のメモリ装置から入力される必要がある。本方法がプリント注文情報１８１０で開始する場合、ＰＯ番号、ＰＳ状態及びＰＯ日時を入力する必要がある。本方法がロット情報１８３０で開始する場合、ロット番号とロットサイズが入力される必要がある。本方法がすべてのカードタイプ１８５０で開始する場合、クレジットカードタイプの詳細が入力される必要がある。本方法がプリントベンダー情報１８６０で開始する場合、ベンダーの名前が入力される必要がある。
【０２５６】
図１９は、集中通信プラットホームでのデータ転送の例である。図１９に示されるように、ユーザ装置１９００は、エンドユーザ情報、エンドユーザが利用可能なアカウント情報、電話通信情報、課金データ取得情報及びユーザデータ取得情報を含むようなデータ記憶構造１９０５を含むことができる。また、ユーザデータ構造１９０５は、通信装置発呼制御及び課金制御及びデータ取得機能を含むことができ、これは、支払、及び決済処理及び消費者ケア用の通信装置１９４０と通信することができる。インターネットＩＳＰ１９１０はデータ構造１９１５を含むことができ、これは、エンドユーザ、、エンドユーザが利用可能なアカウント、ＩＳＰ、課金データ取得、広告及び手数料に関連するユーザデータ取得に関する情報を含んでいる。また、データ構造１９１５は、通信装置範囲制御、使用制御及びデータ取得用のモジュールを含むことができ、これは、通信装置あるいは支払あるいは決済処理及び消費者ケア１９４０と通信する。ポータル１９２０は、データ構造１９２５を含むことができる。データ構造１９２５は、エンドユーザ情報、アカウントアクセス情報、ポータル情報及びアカウント管理情報を含むことができる。また、データ構造１９２５は、通信、装置支払、保険及びデータ取得用のモジュールを含むことができ、これは、支払及び決済処理及び消費者ケア用の通信装置１９４０と通信することができる。販売者１９３０は、データ構造１９３５を含むことができる。データ構造１９３５は、エンドユーザ、利用可能アカウントにカートへの充填（filling the cart in an enabled account）、販売者、課金データ取得及びユーザデータ取得に関する情報を含むことができる。また、データ構造１９３５は、通信、装置支払、保険及びデータ取得用のモジュールを含むことでき、これは、支払及び決済処理及び消費者ケア用の通信装置１９４０と通信することができる。支払及び決済処理及び消費者ケア用の通信装置１９４０は、データマイニング／消費者関係管理（ＣＲＭ）１９５０と通信することができる。
【０２５７】
図２０Ａは、集中通信プラットホームを使用して、プリペイド、再入金タイプアカウントを持つ消費者によって行われるサービス及び取引の少なくとも一方に対する、複数のパーティのリアルタイム決済用の方法及びシステムの例である。本例の方法は、この方法を初期化するエンドユーザ２０００で開始する。次に、本方法は、２０１０のプリペイド再入金に進む。
【０２５８】
２０１０のプリペイド再入金では、前もって、ユーザは、自動的にあるいはサービス及び取引の少なくとも一方をリクエストする時点で、自分以外のだれがプラットホームアカウントをやめ、かつこれらのアカウントのそれぞれに関連する金額がどれくらい、自身のプリペイドプラットホームアカウントに再入金されるべきであるかを判定する。次に、本方法は、２０５０のリアルタイム金融決済に進む。
【０２５９】
リアルタイム金融決済２０５０は、電話会社２０６０、ＩＳＰ２０６２、ポータル２０６４、販売者２０６６及び銀行２０６８からの支払リクエストを受信する。２０７０の販売者管理は、２０５０のリアルタイムダイレクト金融決済を達成する手段である。２０７０の販売者管理は、関係する複数のパーティに対する決済が、即時性、遅延性、付加的な認可を含む、あるいは従来より良く知られている任意の他の特徴となっているかを特定する。つまり、集中通信プラットホームの実施形態は、複数の時間枠に渡って、複数のパーティを含む取引を決済することができる。
【０２６０】
図２０Ｂは、集中プラットホームを使用して、プリペイド、再入金タイプアカウントを持つ消費者によって行われるサービス及び取引の少なくとも一方に対する複数のパーティのリアルタイム決済用の方法及びシステムの別の例である。本方法は、当該方法を初期化するエンドユーザ２０００で開始する。次に、本方法は、２０１０のプリペイド再入金に進む。
【０２６１】
２０１０のプリペイド再入金では、前もって、ユーザは、自動的にあるいはサービス及び取引の少なくとも一方をリクエストする時点で、自分以外のだれがプラットホームアカウントをやめ、かつこれらのアカウントのそれぞれに関連する金額がどれくらい、自身のプリペイドプラットホームアカウントに再入金されるべきであるかを判定する。次に、本方法は、２０２０の銀行に進む。２０２０の銀行では、資産が、銀行からリアルタイム金融決済２０５０に転送される。
【０２６２】
リアルタイム金融決済２０５０は、電話会社２０６０、ＩＳＰ２０６２、ポータル２０６４及び販売者２０６６からの支払リクエストを受信する。販売者管理２０７０は、２０５０のリアルタイムダイレクト金融決済を達成する手段である。２０７０の販売者管理は、関係する複数のパーティに対する決済が、即時性、遅延性、付加的な認可を含む、あるいは従来より良く知られている任意の他の特徴となっているかを特定する。つまり、集中通信プラットホームの実施形態は、複数の時間枠に渡って、複数のパーティを含む取引を決済することができる。
【０２６３】
図２１は、集中通信プラットホームで使用するアカウント管理装置２１００の実施形態である。アカウント管理装置２１００は、加入者アカウントマネージャー２１６０、ＳＩＭ供給（provisioning）２１７０、ＳＩＭ配信２１８０、ＳＩＭ注文２１９０、決済２１５０、領収書供給２１４０、領収証配信２１３０、領収書注文２１２０及びＰＩＮ生成２１１０を持つことができる。
【０２６４】
図２２は、集中通信プラットホームで使用するスイッチマネージャー２２００の一例を示すブロック図である。スイッチマネージャー２２００は、レイティング２２３０、発呼制御２２２０及び残高２２１０を含むことができる。レイティング２２３０はリアルタイムであり得り、あるいは、様々な利益によって、リクエストされたサービスのコストのレイティングであり得る。また、レイティングは、商取引に含まれる不足金あるいはリスクを判定することができる。発呼制御２２２０は、ユーザのアカウントへの課金のすべてを同時に監視し続けることができ、ユーザアカウントへ再入金する追加金を認可する、あるいは再入金を指示するための認可を行う、あるいは発呼を終了する、ユーザあるいは様々なサードパーティのどちらかに信号を送信する。残高制御２２１０は、ユーザのアカウントの現在の残高を監視し続けることができる、あるいはユーザのアカウントが所定レベルに達している場合に警告を提供することができる。
【０２６５】
図２３は、ビジネス対ビジネス（Ｂ２Ｂ）の集中通信システムの一例を示すブロック図である。図２３に示されるように、会社１  ２３３０、会社２  ２３３２から会社ｘ  ２３３９は、インターネット２３１０を介して、集中通信システム２３００に接続している。加えて、会社Ａ  ２３４０、組織２３４２、ユーティリティＡ  ２３４４、ユーティリティＢ２３４６、販売者２３４８及びサプライヤー２３４９は、インターネット２３２０を介して、集中通信システム２３００に接続している。集中通信システム２３００は、仮想アカウント２３０２、レギュラーアカウント２３０４及び銀行システム２３０６に接続することができる、あるいは統合することができる。つまり、会社１  ２３３０のような会社は、会社Ａ  ２３４０からサプライヤー２３４９のいずれかとのビジネス対ビジネス取引を指示するために、インターネット２３１０との唯一の接続を持たなければならない。
【０２６６】
図２４は、ビジネス集中通信システムの別の例を示すブロック図である。図２４において、ユーザ２４００は、電話２４１０、ＡＴＭ２４１２、ＷＥＢ２４１４、ＷＡＰ２４１６及びエージェント２４１８を介して、銀行２４２０と接続している。銀行２４２０は、Ｂ２Ｂゲートウェイ２４３４と接続している。Ｂ２Ｂゲートウェイ２４３４は、集中通信システム２４３０の一部であり、これは、集中通信装置２４３２も含んでいる。集中通信装置２４３２は、電話会社あるいは他の会社の課金（請求書作成）システム２４３２と接続している。つまり、ユーザ２４００は、電話２４１０を使用して、資産を預金あるいは送金することができる。ＡＴＭ２４１２、ウェブ２４１４あるいはＷＡＰ２４１６あるいはエージェント２４１８は、資産をアカウント間で転送し、かつ／あるいは銀行２４２０を利用して、ビジネス対ビジネス取引を電話会社あるいは企業の課金（請求書作成）システム２４４０に指示する。加えて、図２４に示されるように、銀行２４２０は、多くの異なるエンティティとのビジネス対ビジネス商取引を指示するために、集中通信システム２４３０との唯一の接続のみを持つ必要がある。
【０２６７】
図２５は、集中通信プラットホームで消費者プリペイドアカウントに再入金するためのシステムの一例を示すブロック図である。図２５において、ＡＴＭ２５０６、ＡＴＭ２５０４、ＡＴＭ２５０２、ＡＴＭ２５０８、投資信託会社２５３０、銀行２  ２５２０及び銀行１  ２５１０のような様々な装置は、Ｘ．２５ネットワーク２５００に接続されている。Ｘ．２５ネットワーク２５００は、集中通信プラットホーム２５４０の一部としてルーター２５４９に接続されている。集中通信プラットホー２５４０は、ファイヤーウォール２５４４、アカウントマネージャー２５４６、消費者ケア２５４８及び銀行３  ２５４２を含むことができる。アカウントマネージャー２５４６は、データベース２５４７に接続することができる。つまり、消費者は、任意のリモート手段、例えば、ＡＴＭ２５０６から集中通信プラットホーム２５４０の自身のアカウントにアクセスすることができる。
【０２６８】
図２６は、集中通信プラットホームのインタラクティブ音声応答システムを使用して、消費者プリペイドアカウントに再入金するためのシステムの一例を示すブロック図である。図２６に示されるように、銀行１のメインフレーム２６１０は、Ｘ．２５ネットワーク２６００を介して、ＡＴＭ２６０２から２６０８、電話会社２  ２６４０、電話会社１  ２６３０及び銀行２のメインフレーム２６２０のいずれにも接続することができる。集中通信プラットホーム２６５０は、Ｘ．２５ネットワーク２６００にも接続することができる。集中通信プラットホーム２６５０は、ルーター２６６０、ファイヤーウォール２６５８、アカウントマネージャー２６５６、データベース２６５７、インタラクティブ音声応答システム２６５４及びオペレータ２６５２を含むことができる。
【０２６９】
つまり、電話会社１  ２６３０を介して集中通信プラットホーム２６５０と接続する消費者ユーザは、Ｘ．２５ネットワーク２６００からルーター２６６０に転送される自身のリクエストを持つことができる。ルータ２６６０は、ファイヤーウォール２６５８を使用してユーザを認証し、かつリクエストがインタラクティブ音声応答システム２６５４を使用すべきであるかを判定する。インタラクティブ音声応答システム２６５４はアカウント再入金を処理することができる、あるいは消費者が困難である場合には、インタラクティブ音声応答システム２６５４は、発呼をオペレータ２６５２へ送信することができる。インタラクティブ音声応答システム２６５４がアカウント再入金を処理することができる場合、コマンドを発信あるいはデジタル値の入力によって、ユーザは、ユーザの銀行２のメインフレーム２６２０から、Ｘ．２５ネットワーク２６００を使用して、プラットホームアカウントマネージャー２６５６に資産を転送することができる、ここで、資産は、プラットホームデータベース２６５７に記録される。
【０２７０】
図２７は、集中通信プラットホームによって使用されるセキュリティシステムの一例を示すブロック図である。図２７に示されるように、個人識別番号（ＰＩＮ）２７０１は、ユーザ装置２７００に入力することができる。ユーザ装置２７００は、加入者識別モジュール（ＳＩＭ）２７０２、国際移動体加入者識別（ＩＭＳＩ）２７０４及び国際移動局装置識別子（ＩＭＳＥＩ）２７０６を含むことができる。次に、ユーザ装置２７００は、セキュリティに対して必要とされるこららの番号のいずれかを電話スイッチ２７３０に送信することができる。電話スイッチ２７３０は、移動体スイッチセンター番号（ＭＳＣＮ）２７３４及び移動局番号（ＭＳＮ）２７３２を含むことができる。電話スイッチは、上記の番号のいずれか、あるいは識別コードをスイッチマネージャー２７５０に送信することができる。スイッチマネージャー２７５０は、ユーザアカウント２７５２及び認可モジュール２７５４を含むことができる。
【０２７１】
本例の集中通信プラットホームは、金融取引（ＩＳＯ８５８３、あるいは金融取引保証プロトコルにような類に基づく）の安全を可能にし、これは、消費者のプリペイドアカウントの実際の再入金に有益である。本例の集中通信プラットホームは、様々なインタフェースに対し、サードパーティシステム（例えば、消費者の銀行アカウントシステムからお金を引き出すための取引を初期化する本例の集中通信プラットホーム）からのお金の引き落とし、あるいはサードパーティシステム（例えば、本例の集中通信プラットホームの消費者のプリペイドアカウントに入金する消費者の銀行アカウントシステム）によって本例の集中通信プラットホームシステムへの入金を可能にすることを提供する。
【０２７２】
つまり、通常の金融取引を行うにあたって、集中通信プラットホームは、クレジットカード及びデビットカードの未認可ユーザからの不正、及び販売者の不正取引を防止することができる。つまり、本例の集中通信システム方法及びプラットホームは、プリペイド集中通信プラットホームユーザを認可するために、現在知られている任意のもの、あるいは将来の装置セキュリティシステムを使用することができる。
【０２７３】
図２８は、決済機関として集中通信プラットホームを使用する複数の決済の実施形態を示している。図２８に示されるように、決済機関２８００は、銀行２８４０、販売者２８２０、インターネットサービスプロバイダ２８３０及び消費者２８１０と関連付けることができる。つまり、集中通信プラットホームは、複数のパーティの金融決済に対する単一の導管（conduit）として動作することができ、加えて、異種ネットワークを介する複数のサービス及び取引に対する単一の導管として動作することができる。
【０２７４】
図２９は、集中通信プラットホームでの決済に対するベンダー、販売者及びサービスプロバイダ情報のスクリーンショットの一例である。図２９に示されるように、様々なベンダー、サービスプロバイダ及び販売者との契約及び決済構成に対する様々なルールが記憶されている。例えば、本例の集中通信プラットホームは、販売者、決済状態、決済額、決済単位、タイムスタンプ、通貨、契約様式、契約有効日及び契約に関する任意の追加ルールを記憶し、表示することができる。例えば、サティアムオンライン（Satyam online）は、５より大きい金額で、領収後に電子商取引の決済を行おうとしており、ここでは、総領収額の割合で集金している。加えて、契約は、２０００年１１月２３日から２０００年１１月２３日まで有効である。
【０２７５】
図３０は、ベンダー／サービスプロバイダ／販売者情報を集中通信プラットホームに追加しているスクリーンショットの一例である。図３０に示されるように、販売者は、例えば、Sify@Info.comは、契約、効力開始日、効力終了日、状態、支払モード、値、タイムスタンプ、販売者、状態、支払モード、値、タイムスタンプ及び販売者に関連する貯金のような情報をもつことができる。
【０２７６】
図３１は、ベンダー／サービスプロバイダ／販売者についての詳細を本例の通信プラットホームに追加しているスクリーンショットの一例である。図３１に示されるように、フルネーム、住所１、住所２、市、州、郵便番号、国、アカウント番号、基本通貨、基本単位、銀行名、銀行支店、銀行シティ（city）及び販売者に関する備考のような詳細情報、集中通信プラットホームに記憶することができる。
【０２７７】
図３２は、集中通信システムに設定される高度なルールを実現するためのルールリポジトリの一例を示している。一例のルールリポジトリは、いくつかのテーブルを含んでいる。このテーブルは、ルールマスター３２００、加入者３２１０、サービスプロバイダ３２２０及びサービス３２３０と名前が付けられている。各テーブルは、様々なルールセットを実現するために関連するデータを保持するいくつかのフィールドを含んでいる。
【０２７８】
ルールマスタ３２００のテーブルは、例えば、ルール識別子、時間単位、日単位、日時単位、ボリューム単位、パーセンテージ、位置単位、加入者属性単位、サービスプロバイダ属性単位、サービス単位、最終取引単位及び失効契約単位フィールドを持つことができる。ルール識別子フィールドは、加入者３２１０のテーブル及びサービスプロバイダ３２２０のテーブルにリンクされていても良い。
【０２７９】
加入者３２１０のテーブルは、加入者識別子、サービス識別子、サービスプロバイダ識別子、残高クレジット、使用金額及びルールリストフィールドを含むことができる。サービス識別子フィールドは、サービス３２３０のテーブルにリンクされていても良い。サービスプロバイダ識別子フィールドは、サービスプロバイダ３２３０のテーブルにリンクされていても良い。ルールリストフィールドは、ルールマスタ３２００のテーブルにリンクされていても良い。
【０２８０】
サービスプロバイダ３２２０のテーブルは、サービスプロバイダ識別子、サービス識別子、来訪サービスプロバイダ、支払可能、受取可能及びルールリストフィールドを持つことができる。サービスプロバイダフィールドは、来訪サービスプロバイダフィールド及び加入者３２１０のテーブルにリンクされていても良い。サービス識別子フィールドは、サービス３２３０のテーブルにリンクされていても良い。ルールリストフィールドは、ルールマスタ３２００のテーブルにリンクされていても良い。
【０２８１】
サービス３２３０は、サービス識別子、サービスタイプ及び料金表フィールドを持つことができる。サービス識別子フィールドは、加入者３２１０及びサービスプロバイダ３２２０のテーブルにリンクされていても良い。
【０２８２】
追加のテーブルを、集中通信システム及び方法の全体の一部としても良い。加えて、表記名は、本例のルールリポジトリで使用される様々なテーブル及びルールに対して使用される一方で、任意の名前を、フィールドあるいはテーブルの機能に関連するかどうかに関わらず使用されても良い。各テーブルで追加のフィールドが使用されても良く、例えば、変更日を保持する記録フィールドが使用されても良い。
【０２８３】
図３３は、本発明の実施形態に従う集中通信システム及び方法を使用する決済プロセスを実現する装置の一例である。システム全体は、集中通信システム３３００、サービスプロバイダ３３４０及び金融機関３３８０を含んでいる。取引が認可され、かつ課金された後、本例の装置は、サービスプロバイダ３３４０が、金融機関３３８０のアカウントを維持し、かつ提供されるサービスに対する資金を直接受け取らない場合に、決済できる方法を明示する。この状況は良く知られている一方で、ある金融機関のアカウントから別の金融機関に送金する資産を用いて、決済に影響を与え得る別の状況が存在する。
【０２８４】
決済は、サービスを提供するサービスプロバイダ３３４０と同時に課金される集中通信システムのアカウントで開始する。集中通信システム３３００は、決済サービスプロバイダ３３０１を含むことができる。決済サービスプロバイダ３３０１は、データインポート／エクスポート３３０２を含むことができ、これは、集中通信システム３３００、サービスプロバイダ３３４０、金融機関３２８０及びデータフォーマットリポジトリ３３１０間で情報を転送する。
【０２８５】
つまり、例えば、サービスプロバイダ３３４０は、データインポート／エクスポート３３０２を介して、決済ルールを決済処理プロバイダ３３０１に提供することができる。次に、決済ルールは、データフォーマットリポジトリに対するデータを生成するために、あるいは命令を金融機関３３８０に転送するために使用することができる。次に、金融機関３３８０は、機関あるいはアカウント間で資産を送金することができる。例えば、集中通信システム３３００が、クレジット連合３３８４によって管理されるユーザアカウントを持ち、かつサービスプロバイダ３３４０が銀行３３８２の自身のアカウントにクレジットされるサービスを提供する場合、決済プロセスプロバイダ３３０１は、命令を金融機関３３８０に簡単に送信することができる。
【０２８６】
サービスプロバイダは、電気通信会社３３４２、インターネットサービス会社３３４４、販売者３３４６、コンテンツプロバイダ３３４８、あるいは商品あるいはサービスを提供する、現在知られているあるいは将来生成される装置組織のいずれか１つであり得る。金融機関３３８０は、銀行３３８２、クレジット連合３３８４、クレジット会社３３８６、仲買業３３８８あるいは、お金を管理しかつ送金する、現在知られているあるいは将来生成される組織のいずれか１つであり得る。
【０２８７】
図３４は、本発明の実施形態に従う集中通信システム用のプリペイド消費者アカウントの再入金方法の一例を示している。図３４に示される方法は、一連で遷移する質疑応答である。しかしながら、他の様々な実施形態では、同時の質疑応答、偶発的な質疑応答及び未定義の回答を伴う質疑を含んでいても良い。本方法は、スタート３４００で開始し、３４１０の預金アカウントから送金されるべきであるかの判定に進む。
【０２８８】
３４１０の預金アカウントから送金されるべきであるかの判定で、預金アカウントから送金されるべきでないとの判定がなされる場合、本方法は、３４３０のクレジットカードから送金されるべきであるかの判定に進む。３４１０の預金アカウントから送金されるべきであるかの判定で、預金アカウントから送金されるべきであるとの判定がなされる場合、本方法は、３４２０のアカウントに十分な資産があるかの判定に進む。アカウントに十分な資産があるとの判定がなされる場合、本方法は、３４９０の資産の送金に進む。アカウントに十分な資産がないとの判定がなされる場合、本方法は、３４３０のクレジットカードから送金されるべきであるかの判定に進む。
【０２８９】
３４３０のクレジットカードから送金されるべきであるかの判定で、クレジットカードから送金されるべきでないとの判定がなされる場合、本方法は、３４５０のストックアカウントから送金されるべきであるかの判定に進む。３４３０のクレジットカードから送金されるべきであるかの判定で、クレジットカードから送金されるべきであるとの判定がなされる場合、本方法は、３４４０のアカウントに十分なクレジットが存在するかの判定に進む。アカウントに十分なクレジットがあるとの判定がなされる場合、本方法は、３４９０の送金に進む。アカウントに十分なクレジットがないとの判定がなされる場合、本方法は、３４５０のストックアカウントから送金されるべきであるかの判定に進む。
【０２９０】
３４５０のストックアカウントから送金されるべきであるかの判定で、ストックアカウントが送金されるべきでないとの判定がなされる場合、本方法は、３４７０の消費者にオーバドラフト（当座貸越（overdraft））を許容すべきかの判定に進む。３４５０のストックアカウントから送金されるべきであるかの判定で、ストックアカウントから送金されるべきであるとの判定がなされる場合、本方法は、３４６０のどのストックで売るかについての消費者への問い合わせに進む。消費者が、売るストックの数を一旦決定すると、本方法は、３４９０の資産の送金に進む。
【０２９１】
３４７０の消費者にオーバドラフトを許容すべきかの判定で、消費者にオーバドラフトを許容すべきでないとの判定がなされる場合、本方法は、３４８０の消費者が再入金を了承しているかの判定に進む。３４７０の消費者にオーバドラフトを許容すべきかの判定で、消費者に当座貸越を許容すべきであるとの判定がなされる場合、本方法は、３４９０の資産の送金に進む。
【０２９２】
３４８０の消費者が再入金を認可しているかの判定で、消費者が再入金を認可しているとの判定がなされる場合、本方法は、３４８５の送金が可能であるかの判定に進む。消費者が再入金を認可していない、あるいは送金が不可能であるとの判定がなされる場合、本方法は、３４９５の取引の中止に進む。３４８５の送金が可能であるかの判定で、送金が可能であるとの判定がなされる場合、本方法は、３４９０の資産の送金に進む。
【０２９３】
各プリペイド消費者は、以下の方法の少なくとも１つで、再入金に対する自身の条件を構成することができる、（１）電話（移動電話あるいは固定電話）からのみの再入金、（２）ネット（インターネット、モバイルインターネットあるいは公衆あるいは専用ネットワークの任意のタイプ）からの再入金（ＩＶＲ、あるいは立ち寄りを介して、あるいは他の方法を介して）、（３）消費者が再入金に対して明確に問い合わせている場合のみの再入金、（４）残高がある金額を下回る場合、別の特定アカウント（銀行デビットあるいはクレジットあるいは任意のタイプのアカウント）から自動的に行う自動再入金、（５）アカウントに再入金しないが、プリペイドアカウントに対する支払保証として別のアカウントを使用して、メインアカウントから予め構成されている制限を持ついくつかのサブアカウントに再入金する、（３４）定期的（例えば、日毎、月毎、週毎等）な再入金、（７）ユーザによって定義される使用条件に基づいて判定される再入金金額（例えば、過去７日間の使用及び平均再入金金額の参照、あるいは再入金金額が、過去「ｘ」日間で指示された最も高額取引の金額と等しくなっている等）、（８）サービスプロバイダに従う再入金ルール、（９）消費者の「オーナー」に従う再入金ルール（様々なサービスプロバイダの１つであり得る、あるいは消費者を「所有」し、かつその消費者にルールを指示することができるものの２つ以上の組み合わせであり得る）、（１０）サブアカウントホルダー（例えば、親／子、あるいは階層状況での）以外のメイン「アカウントホルダー」に基づく再入金ルール、（１１）再入金を提供する装置（即ち、電話、エージェント、ＡＴＭ、ＰＯＳ等）のオーナーによって指示される再入金ルールがある。
【０２９４】
これらの再入金方法は、様々なタイプの装置に渡って、異なるネットワークに渡って、異なる再入金モード（ＩＶＲ、エージェント等）に渡って及び国あるいは管轄区域内のルールに従って、変化する。加えて、これらのモード、装置、ネットワーク等を組み合わせて、様々なルールを作成したり、様々な組み合わせあるいは置換を行うことが可能である。例えば、ビジネスアカウントを持つ人が、自身のセルラーフォンからのＶＩＲを使用して、ビジネス動作アカウントからお金を、移動取引用に自身の電話に追加する。これをどのようにして、かついくらであるかを示すルールも、電話のアカウントに追加することができ、かつその国のビジネスに対する法規制によって調整することができる。同一のルール及びモード、装置等を使用して、様々な場所で、同一の人が再入金する場合でも、ルールを異なるせることができる。
【０２９５】
図３５は、本発明のいくつかの実施形態に従う集中通信システム及び方法に対するプリペイド消費者アカウントを認可する方法の一例を示している。図３５に示される方法は、一連で遷移する質疑応答である。しかしながら、本発明の範囲内で、別のタイプの遷移があり、これには、同時の質疑応答、偶発的な質疑応答及び未定義の回答を伴う質疑を含んでいる。本方法は、スタート３５００で開始し、３５１０の取引が１ドル以下であるかの判定に進む。
【０２９６】
３５１０の取引が１ドル以下であるかの判定において、取引が最小金額を下回る、即ち、１ドルを下回るか否かの判定がなされる。取引が１ドル以上である場合、本方法は、３５２０の取引が１０ドル以下であるかの判定に進む。取引が１ドル以下である場合、本方法は、３５８０の取引の認可に進む。３５２０の取引が１０ドル以下であるかの判定で、取引が１０ドル以上との判定がなされる場合、本方法は、３５４０の取引が１００ドル以下であるかの判定に進む。３５２０の取引が１０ドル以下であるかの判定で、取引が１０ドル以下であるとの判定がなされる場合、本方法は、３５３０の取引がケイレス（ＫＬＥＳＳ）からであるかの判定に進む。取引がＫＬＥＳＳからであるとの判定がなされる場合、本方法は、３５８０の取引の認可に進む。取引がＫＬＥＳＳからでないとの判定がなされる場合、本方法は、３５４０の取引が１００ドル以下であるかの判定に進む。
【０２９７】
３５４０の取引が１００ドル以下であるかの判定において、取引が所定金額を下回る、即ち、１００ドルを下回るか否かの判定がなされる。取引が１００ドル以上である場合、本方法は、３５６０の取引がローカル（ホームテリトリ内）であるかの判定に進む。取引が１００ドル以下である場合、本方法は、３５５０の取引が衣服に対するものであるかの判定に進む。３５５０の取引が衣服に対するものであるかの判定で、取引が衣服に対するものであるとの判定がなされる場合、本方法は、３５８０の取引の認可に進む。３５５０の取引が衣服に対するものであるかの判定で、取引が衣服に対するものでないとの判定がなされる場合、本方法は、３５６０の取引がローカルであるかの判定に戻る。３５６０の取引がローカルであるかの判定で、取引がローカルでないとの判定がなされる場合、本方法は、３５７０の１時間前までに任意のＰＩＮ認可が存在しているかの判定に進む。取引がローカルであるとの判定がなされる場合、本方法は、３５８０の取引の認可に進む。そして、１時間前までにＰＩＮ認可が存在していないとの判定がなされる場合、本方法は、３５８５のＰＩＮの確認に進む。１時間前までにＰＩＮ認可が存在しているとの判定がなされる場合、本方法は、３５８０の取引の認可に進む。
【０２９８】
つまり、例えば、企業の管理者が、仕事場から近所のオフィスデポ（ＯＦＦＩＣＥ  ＤＥＰＯ）百貨店に行き、仕事用の備品を購入する。管理者は、備品を選択して、勘定場に行く。管理者は、オフィスデポ百貨店の本発明のポイントオブサービスシステムを使用して、ブラッド（Brad）社のビジネス用アカウントからオフィスデポのアカウントに送金して、選択した備品を確保する（ルール：百貨店は、本発明のポイントオブサービスシステムを提供しているか、販売員がそのシステムを使用するために利用可能な情報を持っているか、本発明のポイントオブサービスシステムのビジネス部分であるか、アカウント番号／ＰＩＮ番号以外に必要なものがあるか）。販売員は購入を記録し、管理者に、ポイントオブサービス装置にビジネスアカウントコードを入力することを許可する（ルール：アカウントコードがシステムで必要な文字ストリング、番号、文字列と一致しているか）。本発明のポイントオブサービスシステムは、その会社のビジネスアカウントが有効なアカウントであることを、本発明のポイントオブサービスシステムと本例のゲートウェイを介して、国際銀行アカウントレジスタにアクセスすることによってチェックする（ルール：どの銀行とアカウントが、本発明のポイントオブサービスシステムであるか、どれがシステムを介して可能であるか）。
【０２９９】
レジスタが、会社のビジネスアカウントが、その会社で有効なカウントであることを示し、かつ管理者にＰＩＮ番号を入力することを要求する（ルール：本人が有効なユーザであるか、本人が、このシステムを介して使用ための認証を持っているか、ＰＩＮ番号がファイル上のＰＩＮ番号と一致しているか、かつどのような制限がなされているか）。本発明のポイントオブサービスシステムは、会社のビジネスアカウントの確認を販売員に通知し、そして、会社のビジネスアカウントをチェックして、アカウントが有効で、かつそのアカウントが請求を受けることができるかを確認する（ルール：アカウントがこのような請求を受けられるか、どのような制限があるか）。販売員は、会社のビジネスアカウントが有効で、かつ請求を受け入れることの認証を受信する（ルール：販売員は、管理者に提供するいくつかのオプションを受信する、これらには、請求書を含めるか否か、リボ払いアカウントであるか否か、現金／催促状を介していくらかをアカウントに振り込むか否かがある）。販売員は、管理者のＰＩＮが有効で、かつ管理者がある購入権限を持っていることを通知する。販売員は、会社のビジネスアカウントからオフィスデポアカウントへ送金／支払をする金額を、管理者に提示する。管理者は、支払に同意する。本例のポイントオブサービスシステム（本例のゲートウェイを介する）は、現在の取引の会社のビジネスアカウント及びオフィスデポアカウントを通知する（ルール：いつ実際のお金が送金されるか、パーティ間での分割があるか、いつ分割されるか、どんな情報がパーティに提供されるか）。取引が、本発明のポイントオブサービスシステムと本例のゲートウェイを介して処理される（ルール：処理に関連付けられているタイミング）。確認付きの請求書が、管理者に提供される（ルール：どんな情報が請求書上にあるか、どのような別のオプションが利用可能であるか）。確認は、オフィスデポの販売員に提供される（ルール：どんな内部処理が販売員に対して必要とされるか、確認のプリントアウトが存在するか、現金、チャージ、クレジットチャージ、他のカテゴリ等に付加される金額を取得しているか）。
【０３００】
つまり、本例の集中通信システム及び方法では、取引確認／認証（通信サービスあるいは商取引、あるいはそれらの両方の組み合わせ）は、ユーザ及びアカウントに関連付けられているクレジット制限あるいはプリペイド金額の有効性を確認するための、いくつかの処理あるいはチェックを行う。通信アクセス、インターネットあるいはモバイル／インターネットアクセス、商取引（実際の店舗あるいはネット／モバイルネット上の店舗のどちらか）を使用する様々な実施形態は、次のような確認を行うことができる：ＰＩＮ入力に基づく消費者確認、パスワード入力に基づく確認、電話関連セキュリティ特性に基づく確認、これらのいくつかの組み合わせあるいはそのすべて、要求されたサービス／取引が、特定の消費者プリペイドアカウントに対するものであるか否かの確認（サービスプロファイル確認）、サービス／取引に対する消費者プリペイドアカウントでの利用可能な十分な残高の確認（残高は、プリペイドアカウント残高、あるいはクレジットアカウント残高、あるいは消費者プリペイドアカウントに関連付けられている他のタイプの実際あるいは仮想アカウントであり得る）、様々なサービスプロバイダを介する様々な金額を介する基盤（matrix）に基づく確認がある。例えば、様々な金額に対し、銀行は、認可には４桁のＰＩＮのみ要求する、電話会社は、２０ドル未満の取引に対しては住所のみを要求するが、５０ドルを越える任意の取引に対しては、郵便番号と社会保障番号を要求する、クレジットカード発行者は、住所、郵便番号、社会保障番号、母方の旧姓及びアカウントに入れる最新金額を要求する。
【０３０１】
また、特定の認可プロセスに基づいて、ルールは変更することができる。例えば、ある人が「あなたの現住所はなんですか」のような基本的な質問に回答できない場合、認可に対するルールは、直ちに、２つ以上の質問を追加するために変更することができ、これは、サービスプロバイダがその認可条件に対して、何が重要であるかを判定する。認可を要求する人が、これらの２つ以上の質問に回答できる場合、認可が許可される。そうでない場合、別の質問がだされる、あるいはその人は、サービスプロバイダ（銀行、電話会社、販売者あるいは任意の他のタイプのサービスプロバイダ）によって構成されるルールに基づく実際の認可リクエストに対する列（queue）に入ることができる。例えば、サービスプロバイダは、ユーザから追加の情報を問い合わせることができ（例えば、母方の旧姓、誕生日、あるいは前回の取引時の金額、あるいは前回の課金額、前回の再入金額、あるいは消費者によって予め定義されている個人的な質問と回答との一致度）、高額の取引（例えば、２０ドル以上）あるいは大量の取引（例えば、１日に１５取引以上、あるいは月に５０取引以上等）に対しては専用パスワードを問い合わせることができる。つまり、消費者あるいはサービスプロバイダによって構成されるルールに基づいて、追加の確認を、取引をすぐに拒否する代わりに使用することができる。上述の説明から明らかなように、ルールは、消費者あるいはサービスプロバイダのどちらかによって確立されるルール群に基づくインタラクティブプロセスの一部であり得る、また、ある取引に対する消費者とサービスプロバイダ間のインタラクティブ通信を介して、不正防止を可能とすることができる。
【０３０２】
例えば、消費者／ユーザは、あるタイプの取引に対する追加のパスワードと、前回の取引の数以上の取引の場合（例えば、過去５日間の取引の総数が現在の取引数の５０％以上であるかを問い合わせる）にシステムによって要求される追加の情報（例えば、誕生日、友人名、専用パスワード）をセットアップすることができる。消費者／ユーザによって構成されるルールに基づいて、システムは、あるタイプの取引（例えば、通貨制限のある国間でのポルノ写真あるいはお金以外の可能なすべての電子商取引及び移動商取引）を防ぐことができる。
【０３０３】
つまり、ルールは、乗車券を購入するための２０ドルの取引は、プリペイド残高がゼロを下回っていない限り（換言すれば、２０ドルのオーバードラフトを可能とする）認可されるというものであり、これは、リクエスタが６０歳以上で、かつその要求が銀行の営業時間外で行われる。つまり、いくつかの実施形態は、経済特性、取引タイプ特性、リクエスタ特性及び日時によって定義される基準を使用することができる。つまり、本例のシステムは、３次元ルール、人工知能によって決定されるルール、取引単位あるいはアカウント単位で適用されるルールマトリクスを使用することができる。このルールマトリクスは、同一の取引に対してでさえも、異なるサービスプロバイダの提携が含まれている場合には、様相が異なる。
【０３０４】
また、本明細書で実施されるように、ルールは、適応性あるいは経済性に基づかせることができる。例えば、ルールは、アカウント残高、補填能力、使用通貨、マージンルール及び利子率に基づかせることができる（これらのルールは、アルゴリズム的ルールの変更と呼ぶことができる）。他のルールは、消費者プロファイル、例えば、年齢、職業、国籍、性別、住所、金融歴、犯罪歴、メンバーシップ、取引履歴、取引プロファイルに基づかせることができ、取引プロファイルは、例えば、サービスタイプ、コンテンツタイプ、注文量、あるカテゴリの製品の購入名がある。ルールは、幾人かの繋がりによる履歴、ロジック、不正及びセキュリティ要因に基づかせることができ、この繋がりには、サービスプロバイダ、販売者及び消費者、あるいは販売者プロファイル、例えば、所在地、タイプ、ビジネスウェブ提携等を含んでいる。
【０３０５】
また、本明細書で実施されるルールは、「ファジー」、あるいは人工知能のような改良ロジックに基づかせることができる。例えば、消費者の音声の解析は、音声の振動、抑揚、アクセントを評価して、消費者のストレスレベルを判定することができ、これによって、取引を認可するための判定に効果を与えることができる。人工知能システムは学習機能を持つこともでき、これは、特定の個人消費者の過去の様々なイベントに基づく判定を行うことを可能にする（判定を行う際に特別な影響を与えるイベントが１つもない場合でさえも）。例えば、システムは、所定月数の期間に渡るデビット取引を解析して、個々の消費行動を得ることができる。新規の取引のリクエストが初期化される場合に、購入パターンによる大まかな照合がなされると、システムは取引を可能にすることができる。そうでない場合、システムは、その取引が、潜在的な不正があることを示す印をつけ、更なる確認を行うことができる。確認が適切に完了する場合、システムは、その取引を認可し、かつ個人の新規の消費行動を得るために、その取引をナレッジベースに入力する。
【０３０６】
本明細書で実施されるように、システムは、消費者群（例えば、すべての教師、すべてのティーネージャー、ダラスに住んでいる５５歳以上の女性等）の過去の様々なイベントに基づく判定を可能にする学習機能を持つこともできる。取引リクエストが初期化される場合、システムは購入パターンを解析することができ、グループ行動パターンが大まかに照合する場合、システムは、その取引を認可する。例えば、テキサスのかなりの小さな町が生まれである６２歳の女性が、現在、インドネシアにいる状態で、ブラジルのサイトからポルノ写真のダウンロードの承認を問い合わせる機会がある。システムは追加の認可を提供する、これは、取引には潜在的な不正状態である可能性があるからである。
【０３０７】
本明細書で実施されるように、システムは、特定の個人消費者の過去の様々なイベントに基づく判定を可能にする学習機能を持つこともできる（判定を行う際に特別な影響を与えるイベントが１つもない場合でさえも）。例えば、システムは、所定月数の期間に渡る取引を解析して、個々の消費行動を得ることができる。新規の取引のリクエストが初期化される場合に、購入パターンによる大まかな照合がなされると、システムは取引を認可することができる。そうでない場合、システムは、その取引が潜在的な不正であると識別し、更なる確認を行う。確認が適切に完了する場合、システムは、その取引を認可し、かつ個人の新規の消費行動を得るために、その取引をナレッジベースに入力する。
【０３０８】
様々な実施形態の特定の特徴は、デビットがリアルタイムで発生することである。つまり、サービスプロバイダは、近い金額の２つのチャージが同時に発生する場合に、消費者のアカウントから重複課金されることが防止される。加えて、リアルタイム課金は、単純なワンタイムアクセスフィーではなく、すべての課金に対して動的アカウンティングを可能にする。例えば、ローミング電話発呼は、ワンタイムローミング課金だけではなく、通話時間に基づいて、ローミングネットワークにクレジットすることができる。これは、いくつかの異なる方法で不正防止を可能にする。
【０３０９】
すべてのタイプのサービスプロバイダには、不正の管理及び制御についての共通の問題を持っている。サービスプロバイダが単純な通信サービス、商取引サービスあるいは金融サービスあるいはその他の任意のサービスのどれを提供するかで、不正は、彼らのビジネスに対する最大の脅威の１つになる。一般的に、不正は、ある理由によって生じる「収入の損失」として定義される。伝統的には、ベンダー及びサービスプロバイダーはこの問題を認識し、不正を最小化するにいくつかの解決策を見出している。今までのところ、提供される解決策は、ある基本的な問題を理解することによって潜在的な不正を解析する。これらの基本的な問題には、次のものがある、動機−不正に対する基本的な事象は何であるか（例：お金をつくる、犯罪への性向、ハッキング等）、手段−不正の性質は何であるか（例：電話加入権販売（call selling）／プレミアムレートサービス等）、モード−基本的な不正方法が何であるか（例：不正加入、不正サーフィン（surfing）、不正ゴースティング（ghosting）等）及び方法−特定の不正方法が何であるか（例：加入、ローミング等）がある。
【０３１０】
上述の様々な場合に適合する方法は、通常分類することができる。第１のタイプは不正加入があり、−加入者が頻繁に使用するための接続を行っているが、支払の意志がない場合である。第２のタイプは不正電話加入権であり、−加入が、助成金で電話加入権を他人へ販売するために使用されるが、加入者が支払の意志がない場合である。第３のタイプは不正プレミアムレートサービス（ＰＲＳ）があり、−これによって、ＰＲＳコンテンツプロバイダ自身は、自身のＰＲＳ番号への発呼を行って、手数料を集金することによって、ネットワークを乱用するが、生成した発呼に対するオペレータへの支払を免れる。第４のタイプは不正ローミングであり、−これは、ローミング加入者がネットワーク／サービスを頻繁に使用しているが、支払の意志がない場合である。不正の最後のタイプは内部不正であり、−これは、サービスプロバイダの従業員が自身の知識を使用して、他者が不正を行うことを手助けすることによってシステムを改竄することである。
【０３１１】
サービスプロバイダは広い範囲で、定常的に様々なタイプの不正、かつ不正を検出し、解析し、対応してかつ防ぐために、どのようにして十分な監視を効率的に行うかについての取り巻く問題を学習し理解することに務めている。ある特有の利点あるいは本システムは、本実施形態の有効性が継続的に測定され、かつ確認事項（findings）を、改良点としてシステムにフィードバックすることができることである。
【０３１２】
いくつかの不正管理システムを、様々な知的レベルで、今日の市場で利用することが可能である。サービスプロバイダは、通常、このようなシステムとビジネスプロセスのセットを実装することによって、不正を管理する。例えば、クレジットレイティングエージェンシーからクレジットレイティングの取得、消費者及びその住所の物理的な確認、人／エンティティが過去の支払に対する責任を持っている他のサービスプロバイダからの確認の取得、かなり高度な集金プロセスのセットアップ、パスワードの保護、向上したＩＴセキュリティ及びより強力な暗号化アルゴリズムの確立がある。
【０３１３】
通信の分野では、様々なタイプの不正に関連するリスクがあるために、今日のサービスプロバイダは、ポストペイド消費者よりもプリペイド消費者を好んでいる。しかしながら、ポストペイド消費者からプリペイド消費者への切換では、不正を解消できないばかりか、不正の不利益をあるパーティから別のパーティへ移すことにある。潜在的な不正者は、その不利益を被る人への配慮を行わない。そのため、不正の問題に対する顕著な有効な手だてがない。
【０３１４】
金融サービスの分野では、これらの理由のいくつかのために、クレジットカードよりも、デビットカード及びスマートカードベースのプリペイドカードを好んでいる。本発明の実施形態は、セルラー電話の使用、電子メールシステムへのアクセス及び上述の接続を通して、集中通信システム及び方法を認証プロセスに組み込むことによって、すべてのシステムを改良している。
【０３１５】
例えば、消費者は、自身の電話、インターネット装置、任意のポイントオブセール装置、クレジットカード、デビットカードあるいはＡＴＭを使用して、任意の２つ以上のサービス（２つ以上の通信サービス、１つ以上の商取引サービス、あるいは通信及び商取引サービスの組み合わせ）に対する認可リクエストを発行することができる。このようなリクエストは、各サービスプロバイダの通常の不正確認処理が施され、その結果が肯定的である場合、サービスの組み合わせに対して、本例の集中通信システム及び方法による更なる確認がなされる。確認中に、そのリクエストに不正の可能性がある場合、サービスプロバイダは、消費者との対話（音声あるいはデータ対話）を開始して、追加の確認を指示することができる。このような確認は、消費者構成パラメータに基づかせることができる。例えば、消費者は、いつでも、２５ドル以上のものを購入することを試みて、追加の確認を行える。付加的なサービスプロバイダ構成パラメータも使用することができる。例えば、２５ドルを越えるあるリクエストに追加の確認を施し、かつ消費者がローミング中での商品／サービスの購入に対する任意のリクエストは、ホームサービスプロバイダと来訪ネットワークサービスプロバイダの両方に基づく追加の確認を施すべきである。他のプロファイル／カテゴリ／使用に基づく構成パラメータを使用することができる。例えば、緊急かつ予定外の量の認可リクエスト、緊急かつ予定外のリモート位置からの認可リクエスト及びサービスタイプは、通常、消費者のカテゴリでは使用されない。
【０３１６】
つまり、高度な技術及びより高度なビジネスプロセスの使用が増えるにつれて、全世界のサービスプロバイダは、潜在的な不正を削減することが可能である。サービスプロバイダが今日直面している最大の難関は、ルールの数やビジネスプロセスに関りなく生じる不正がいまだなお発生しているという事実である。
【０３１７】
例えば、大規模な産業では、不正を解消する／最小化する最良の方法は、その不正が発生する地点での不正の試行を制御することであるという事実を認識している。ビジネスに影響を与えるリクエストは、潜在的な不正となり得る。その結果、現在利用可能な不正管理解決策は、ルールのセットに基づくリクエストを承認するあるいは拒否することに着目している。これらの解決策は、ルールのセットを満足するリクエストが良好なリクエストであり、かつ任意のリクエストが不正でないという仮定に基づいている。しかしながら、実生活では、すべての条件を満足する消費者でも、不正者となり得る一方で、不正者を装う消費者は、実生活で、不正を意図しない良好な消費者となり得る。
【０３１８】
集中通信及び商取引を用いると、いくつかのパーティは、消費者の要望の１つを満足するために協働する必要がある。これらのサービスプロバイダのそれぞれは、自身のサービス提供時に、それに関連する不正を扱うリスクを持つことになる。任意の集中サービスは、関連サービスプロバイダのすべてのリスクを統合する。その結果、混合サービスに対して、得られる不正管理機能は、サービスプロバイダのそれぞれの不正管理機能の少なくとも共通部分となる（即ち、最低限のリンク状況）。その結果、サービス提供時に関与するサービスプロバイダのパーティ数に従って、潜在的な不正が急激に増加することになる。
【０３１９】
現在利用可能な不正管理システムは、複数のパーティに関連する問題に関知していない。これらは、様々な知的レベルにおける、単独のサービスの不正管理解決策である。これらは、様々なサービスプロバイダによってもたらされる集中サービスに関連するリスクの組み合わせに基づく解決策を提供しない。本明細書の様々な実施形態は、不正を削減しかつ解消するために使用することができる。
【０３２０】
例えば、図３６は、本発明のいくつかの実施形態に従う、集中通信システム及び方法に対するプリペイド消費者アカウントの課金方法の一例を示している。図３６に示される方法は、一連で遷移する質疑応答である。しかしながら、他の様々な実施形態では、同時の質疑応答、偶発的な質疑応答及び未定義の回答を伴う質疑を含んでいても良い。本方法は、スタート３６００で開始し、３６１０の取引が課税対象（非課税）であるかの判定に進む。
【０３２１】
３６１０の取引が課税対象であるかの判定で、取引が非課税であるべきとの判定がなされる場合、本方法は、３６３０の課金をクレジットアカウントへ送金するかの判定に進む。３６１０の取引が課税対象であるかの判定で、取引が課税対象であるべきとの判定がなされる場合、本方法は、３６２０の政府アカウントへの課金へ進む。３６２０の政府アカウントへの課金が一旦完了すると、本方法は、３６９０の決済の調整に進む。
【０３２２】
３６３０の課金をクレジットアカウントへ送金するかの判定で、クレジットアカウントへ送信するべきでないとの判定がなされる場合、本方法は、３６５０の取引が配送を含んでいるべきであるかの判定に進む。３６３０の課金をクレジットアカウントへ送金するかの判定で、クレジットアカウントへ送金されるべきとの判定がなされる場合、本方法は、３６４０の課金は即時になされるべきかの判定に進む。課金は即時になされるべきとの判定が３６４０でなされる場合、本方法は、３６９０の決済の調整に進む。課金は即時になされるべきでないとの判定がなされる場合、本方法は、３６５０の取引が配送を含んでいるかの判定に進む。
【０３２３】
３６５０の取引が配送を含んでいるかの判定で、取引は配送を含んでいないとの判定がなされる場合、本方法は、３６７０の課金が分割払い（split over time）であるかの判定に進む。３６５０の取引が配送を含んでいるかの判定で、取引は配送を含むできとの判定がなされる場合、本方法は、３３６０の配送が即時に支払われるべきであるかの判定に進む。配送が即時に支払われるべきであるとの判定がなされる場合、本方法は、３６９０の決済の調整に進む。配送が即時に支払われるべきでないとの判定がなされる場合、本方法は、３６７０の課金を分割払いとすべきであるかの判定に進む。
【０３２４】
３６７０の課金を分割払いとすべきであるかの判定で、取引を分割払いとすべきでないとの判定がなされる場合、本方法は、３６８０の課金を電子的とするべきかの判定に進む。３６７０の課金を分割払いとすべきであるかの判定で、課金を分割払いとすべきとの判定がなされる場合、本方法は、３６９０の決済の調整に進む。課金を分割払いとすべきでないとの判定がなされる場合、本方法は、３６８０の決済を電子的にすべきであるかの判定に進む。３６８０の決済を電子的にすべきであるかの判定で、取引を電子的にすべきでないとの判定がなされる場合、本方法は、３６９５の決済情報のプリントに進む。３６８０の決済を電子的にすべきでないとの判定で、課金を電子的にすべきとの判定がなされる場合、本方法は、３６９７の送金の調整に進む。
【０３２５】
例えば、消費者がＡＴＭに行き、百貨店を選択して、レンナー（Renner）百貨店のアカウント番号を入力する。本実施形態のシステムは、その百貨店がシステムのメンバーであるか、かつその百貨店がシステムを介しての支払を提供し、そのアカウント番号（文字列／数字／図形）が、その百貨店のものと照合しているかをチェックする。本例のシステムは、ゲートウェイを使用して、レンナー百貨店のデータベースと接続し、アカウント番号を確認することができる。本例のシステムは、アカウント番号が照合するかのチェックもできる。消費者は、自身の身元とアカウントを確認するために、ＰＩＮ番号を使用することもできる。本例のシステムは、ゲートウェイを使用して、レンナー百貨店のデータベースと接続して、レンナーとのアカウント番号を確認することができる。このシステムは、システムの特性に対するＰＩＮ番号と、消費者に関連付けられている実際のアカウント番号をチェックする追加の確認処理を実行することができる。このシステムは、データベースにアクセスして、消費者にアカウント残高を引き戻すことができる。このシステムは、次のことをチェックすることができる、ＰＩＮ番号と、百貨店のレコードにあるＰＩＮ番号と照合しているか、引き落とすアカウント残高が存在するか、追加のチャージあるいはペイオフを行うために、本例のシステムを使用することが可能なアカウントであるかである。
【０３２６】
次に、消費者は、レンナーに対する支払タイプとして自身のクレジットカードで負うものの部分をペイオフとする決定を行うことができる。本例のシステムは、次のことをチェックする：消費者が何をしたくて、かつ消費者が何をできるかである。本例のシステムは、可能であれば、ゲートウェイを使用しないで、銀行システムのクレジットカード残高をチェックすることができる。次に、システムは、次のことをチェックする：クレジットカードの残高がどれくらいか、トータルクレジット上限がどれくらいか、クレジット上限と残高間の差がどれくらいか、残高が正である場合、システムは消費者にオプションを提供できるかである。本例のシステムは、次に、消費者のクレジットカードで利用可能なクレジットが存在するかを更に検証する。消費者は、クレジットカードからの送金を介して、自分の自分の残高比率に応じて、レンナーへの支払に同一する。次に、本例のシステムは、次のことをチェックする：消費者が何をしたいか、どれくらいの量を処理すべきか、どれくらい送金されるべきか、かついつ送金が発生すべきかである。次に、送金を行うことを指示し、物理的な送金を行い、お金が受け取られたかのチェックを行うために、銀行システムを使用することができる。次に、本例のシステムは、次のことをチェックする：レンナー及びクレジットカード会社によってどのようなチェック及び確認が要求されているか、どのような受領オプションを消費者が要求しているかである。次に、消費者は、支払を照会するＡＴＭを介して、取引／支払受領証を受け取ることができる。本例のシステムは、次のことをチェックする：受領証でどんな情報が要求されているか、消費者が更にどのような情報をみたいか、消費者に対してどのような選択が利用可能であるかである。受領証は、取引の確認を含んでいる。そして、取引が完了する。次に、本例のシステムは、次のことをチェックすることができる：消費者がどのようなものを望んでいてい、何が選択されるかである。
【０３２７】
つまり、これらのルールは、お金がアカウントからいつ引き落とされるかについてを具体的にしたものである（課金された後にどこでクレジットされるかに対して）。つまり、このルールは、次のルールに基づいていても良い、サービスプロバイダに従うルール、消費者の要望に従うルール（おそらくは、めったに使用されない）、サービスプロバイダの混合に従うルール、消費者の「オーナー」に従うルール、「主要な」プロバイダのサービスに従うルール（即ち、販売者が消費者にＣＤを２０ドルで販売し、オーバナイト出荷が２２ドルである場合、オーバナイト出荷者は、いつ／どのようにして課金が発生するかを指示することができる）、金融機関の状態、プロセス、手順に従って変更するルール、様々な立法機関の規制に従うルール、消費者履歴、利用制限、月別平均アカウント残高に従うルール、任意のサービスプロバイダ間の所定の契約に従うルールである。
【０３２８】
また、ルールは、即時払あるいは後支払／後送金にすることができ、かつルールは、上述の分割払いの組み合わせとすることができる。例えば、金額の５０％を即時払とし、残りを１週間で２回の均等払にすることができる。つまり、課金は、一括払にする必要はなく、あるいは即時払いにする必要はない、購入額に付加する複数のデビットとすることができる、月別のデビット（「あなたのすべてのプランを消費することができる」ことをカバーする）とすることができる、かつ、その他の周知の方法で、支払を構築することができる。
【０３２９】
また、金額に対してすべての取引が、送金を含む必要はない。お金が交換される場合、様々な取引は、次のようになり得る、フリー、（頻繁な飛行マイルのような）前回の購入アイテムの特典、月別の加入サービスあるいはお金の交換の部分、通貨を含まない商品あるいはサービス（商品（merchandizing）クレジットのような）がある。例えば、フリーアイテムは、特定の期間内で追加のアイテムを購入するための契約に対して提供されても良い。他の交換は、アクセス用のＭＰ３ファイルを別のＭＰ３ファイルで提供することを含んでいる。あるいは、消費者は、自身がある銀行に預金している限り、マッピングプログラムへのアクセスを取得できるようにしても良い。本例のシステムは、図３２に示される構造内で、これらのタイプの交換を可能にする。
【０３３０】
図３７は、本発明のいくつかの実施形態に従う、集中通信システム及び方法に対する取引決済方法の一例を示している。図３７に示される方法は、一連で遷移する質疑応答である。しかしながら、他の様々な実施形態では、同時の質疑応答、偶発的な質疑応答及び未定義の回答を伴う質疑を含んでいても良い。本方法は、スタート３７００で開始し、３７１０の任意のリアルタイム決済が存在するかの判定に進む。
【０３３１】
３７１０の任意のリアルタイム決済が存在するかの判定で、リアルタイム決済が存在するとの判定がなされる場合、本方法は、３７１５の送金に進む。３７１５の送金において、アカウント間の即時送金が指示される。次に、本方法は、３７２０の任意の日時トリガー型決済が存在するかの判定に戻る。選択的には、３７１０の任意のリアルタイム決済が存在するかの判定で、リアルタイム決済が存在しないとの判定がなされる場合、３７２０の任意の日時トリガー型決済が存在するかの判定に進む。
【０３３２】
３７２０の任意の日時トリガー型決済が存在するかの判定で、日時トリガー型決済が存在するとの判定がなされる場合、本方法は、３７２５の日時トリガーの設定にすすむ。３７２５の日時トリガーの設定において、決定日時に送金を行うトリガーが設定される。次に、本方法は、３７３０の任意のイベントトリガー型決済が存在するかの判定に戻る。選択的には、３７２０の任意の日時トリガー型決済が存在するかの判定で、日時トリガー型決済が存在しないとの判定がなされる場合、本方法は、３７３０の任意のイベントトリガー型決済が存在するかの判定に進む。
【０３３３】
３７３０の任意のイベントトリガー型決済が存在するかの判定で、イベントトリガー型決済が存在するとの判定がなされる場合、本方法は、３７３５のイベントトリガーの設定に進む。３７３５のイベントトリガーの設定において、トリガーは、決定されたイベントに送金するトリガーが設定される。本方法は、３７４０の任意のバッチ決済が存在するかの判定に戻る。選択的には、３７３０の任意の日時トリガー型決済が存在するかの判定で、日時トリガー型決済が存在しないとの判定がなされる場合、本方法は、３７４０の任意のバッチ決済が存在するかの判定に進む。
【０３３４】
３７４０の任意のバッチ決済が存在するかの判定で、バッチ決済が存在するとの判定がなされる場合、本方法は、３７４５の取引のバッチへの追加に進む。３７４５の取引のバッチへの追加において、取引結果が、次回のバッチで呼び出されて動作するように、取引のリストに追加される。次に、本方法は、３７５０の終了に戻る。選択的には、３７４０の任意のバッチ決済が存在するかの判定で、バッチ決済が存在しないとの判定がなされる場合、本方法は、３７５０の終了に進む。
【０３３５】
例えば、取引が、１つ以上の通信サービスプロバイダが含まれる場合（例えば、ローミング）の単純な通信取引である場合、できる限り取引（例えば、電話発呼）が行われ、本例の決済モジュールが取引を参照して、関係するパーティ（例えば、サービスプロバイダ）を識別し、かつ決済（例えば、リアルタイムあるいは時間遅延決済、パートナー決済料金表、注文量に対するディスカウント、任意の部分が規定のエージェンシーへの支払対象となっているか等）に対するルールを適用する。ルールに基づいて、集中通信システム及び方法は、本例のシステム内で決済がなされなければならないかどうか、あるいは外部エージェンシーを使用して、決済が指示されなければならないかを識別することもできる。次に、集中通信システム及び方法は、ルールを適用して、決済ネッティング情報＆レポートを出力する。外部エージェンシーに対して、このような情報が、予め定義されているフォーマット上で処理される（例えば、ＴＡＰレコード、予め定義されているＡＳＣＩＩテキストファイル、ＭＸＰレコード、ＣＩＢＥＲレコードあるいはＩＰＤＲレコード等）。
【０３３６】
別の例においては、取引は、商取引であり得る。本例の集中通信システム及び方法は、上述のプロセスと同一のプロセスを行うが、適用されるルールは、そのルールがすべてあるいはいくつかの外部サービスプロバイダを管理する必要があるので、少し複雑になり得る（例えば、販売者は、商品の配達にクーリエ便を使用する可能性があり、かつ物理的な配送に関連するいくつかのルールは、リアルタイムでなく、かつ時には、いくつかのプロセスは自動化されていない）。決済ルールも、より複雑となり得る（例えば、決済額は、量、重さ等に依存し得る）。
【０３３７】
取引が集中取引（商取引及び通信）である場合、本例の集中通信システム及び方法は、上述のタイプの両方の組み合わせとなる。本例の集中通信システム及び方法は、商取引決済ルールに基づく状況で、更なる複雑さをルールに追加し得り、通信決済用のいくつかのルールに影響を与える可能性がある。例えば、消費者が来訪ネットワークで５０ドルの商品を購入する場合、来訪ネットワークは、ホームネットワークへの任意のローミングの通話時間の料金を課金しない可能性がある。ホームネットワークは、最終消費者へ利益を享受する、あるいは享受しない可能性がある。
【０３３８】
上述の方法は、以下の実例に続く。消費者ジムは、休暇中にワシントンＤＣで自身のＣＤＭＡプリペイド移動電話でローミングしている。自身のホームネットワークは、ノースカロナイナモバイルであり、これは、彼が、５０ドルの月別のサービス料金を支払を行い、ホームネットワーク上のどの場所でもウィークエンド記録プランを使用することができる。ローミングは、自身のホームネットワークによって通話毎に１ドルの追加料金で徴収される。
【０３３９】
ワシントンＤＣでは、ジムは、ＧＳＭネットワークを介して受信する、オレンジミュージックストリーマーミュージックサービスを介してサンタナのグレイテストヒットを聴取している。彼は、ソニー（Sonny）の新しいミニデジタルＣＤプレーヤーの広告をプロンプトしている、シンプルメッセージングシステム（ＳＭＳ）を受信する。彼は広告を読みながら、カルロス  サンタナを聴取している。ＣＤプレーヤーの特性のショートリストの後には、次の１５分以内に購入する場合には、ＣＤプレーヤーを３３％オフで購入するプライスリストが提供されている。彼は、その提供をクリックすることを衝動的に決定し、オレンジミュージックストリーマーモバイルサービスのショッピングウェブサイトに進む。
【０３４０】
オレンジミュージックストリーマーのウェブサイトは、アーサーシステム（Aether Systems）によって開発された。オレンジとの対話を介して、アーサーは、そのサイトを管理している。この管理、開発及び設計関係に対して、アーサーは、いくつかの方法で報酬を受け取っている。これには、次のものを含んでいる：（１）ウェブサイトの開発に対する通常の固定費、（２）サイトへの掲載を維持するサービスを提供する等の月別の管理費、（３）サイト上の任意の広告に対するクリック毎に２セントの均一料金、（４）サイトの広告によって購入される各アイテムに対する商品あるいはサービスの料金の手数料、（５）オレンジ  ミュージックストリーマーによって提供される消費者サービスの発呼毎に１ドルの均一料金がある。
【０３４１】
ジムは、カルロス  サンタナを聞きながら、モバイルウェブサイトのソニーＣＤプレーヤーについての２つ以上のスクリーンを介してクリックする。彼はクリックして、価格と予約状況（availability）を確認する。このサイトは、２つのオレンジミュージックストリーマーパートナーを用いて、彼が商品をどこで購入できるかを彼に提供する。彼は、電子Ｒ−Ｕを介するアマズーム（Amazoom）を選択すると、直ちに、アマズームのモバイルショッピングサイトを提示する。
【０３４２】
アマズームでは、ジムは、ＣＤプレーヤーを１００ドル（提示額は１５０ドルである）で提供する簡易支払プランを選択し、彼は、２回払での支払を選択する（最初に５０ドル、ＣＤプレーヤーが配達される時点で５０ドル）。彼はプリペイドボタンをクリックして、自身の集中通信システムプリペイドアカウントを使用することを選択する。
【０３４３】
アマズームは、ジムの新規のＣＤプレーヤーをフェドエクストラ（FedExtra）ボックスに包み、そのパッケージの保険を提供するためのインシュラス（InsurUS）を手配する。フェドエクストラの配送は、アマズームで５ドルかかり、インシュラスは、総額０．５ドルの保険をＣＤプレーヤーにかける。
【０３４４】
ジムは、自身のプリペイド電話でカルロス  サンタナを聞きながら、ノースカロライナの帰路の列車を待っている。彼が自宅に到着すると、フェドエクストラが彼のＣＤプレーヤーを配達し、配達票のサインによって、いくつかのサービスプロバイダに渡る価値連鎖の取引が始動する。
【０３４５】
以下の決済取引は、本発明のシステム及び方法の実施形態を使用して発生する。
【０３４６】
【表１】
2010081614.tif 000003
【０３４７】
本例の集中通信システム及び方法の決済部分は、どのようにして支払が取り決められ、かつどのアカウントが支払によるクレジット対象となるかを制御する。これらの取引決済ルールは、アカウント間、異なるアカウントから多数のアカウントへ等での決済を構成する。つまり、本例のシステムは、集中サービス及び通信取引に対し、複数のパーティによる決済を可能にし、各サービス及び商取引に対する決済ルールを構成することを可能にし、販売者（商品／サービスのプロバイダー、例えば、製造業、再販業者、流通業者あるいはこのようなエンティティのいくつかの組み合わせ）間、ポータル（移動ポータルあるいは電子商取引ポータルを含む任意のタイプのポータル等）間、インターネットサービスプロバイダ（独立エージェンシーあるいはモバイルオペレータあるいはポータル）間、移動電話会社（ホームネットワーク、来訪ネットワーク、あるいはその両方）間、仮想サービスプロバイダ（コンテンツサービスプロバイダ、あるいはインフラストラクチャサービスプロバイダ、あるいはブランディングエージェンシー、あるいは任意の組み合わせ）間、銀行／クレジットエージェンシーあるいは任意の他の金融機関（１つ以上の商取引に関与する）間、サードパーティ支払エージェンシー（例えば、販売法人（aggregators）、支払処理エージェンシー、あるいは電子財布、あるいはこのような任意の処理エージェンシー）間、商品／サービス配送エージェンシー（例えば、クーリエー会社、バンド幅サプライヤー）間及び保険エージェンシー間での決済を可能にする。
【０３４８】
本明細書で実施されるように、集中通信システム及び方法は、様々な状況に対する決済ルールの構成を提供することができる、例えば：リアルタイム決済、時間遅延型決済（例えば、２日後あるいは３０日後等）、ある条件の確認に基づく決済（例えば、保険エージェンシーが商品の出荷前に支払を行っているけれども、商品が配達される場合にのみクーリエが支払われる）、パーティ間のビジネス関係に基づく決済（例えば、クーリエーエージェンシーは、ボリュームに基づくディスカウントを提供し、これは、決済処理が、１つだけの配達ではなくいくつかの配達を考慮に入れること意味する）、及び出来高に基づく決済（例えば、ポータルに、広告がローミング加入者に配信される毎に小額が支払われ、かつポータルは、ローミング加入者が実際に商品／サービスを購入する場合には、それより大きな額を支払う）。本明細書で実施されるように、集中通信システム及び方法は、関連ネットワーク間のローミング契約を考慮する決済を提供することができる（例えば、ローミング追加料金）。また、集中通信システム及び方法は、任意の規制条件を考慮する決済を提供することができる（例えば、政府機関への税金及び決済の充当）。つまり、取引は、１つの取引の支払あるいは即時クレジットのみしかできないわけではなく、取引は、購入額に追加する、複数のデビットに分けることができる。また、取引は、１年に渡って分けられる月毎の取引の類とすることができる（「すべてのプランを使用できる」ことも含む）。
【０３４９】
本明細書で実施されるように、集中通信システム及び方法は、以下のカテゴリに分けることができる決済を提供することができる：クレジット日、クレジット上限、資産額閾値、注文量に対するディスカウント、規制条件、決済手数料、要望に応じたサービスタイプ（繰り返し締め切れられる関係に基づく）、オンライン、オンラインリアルタイム及び様々な時限に基づくバッチがある。
【０３５０】
このシステムへアクセスする方法にはいくつかの例がある。例えば、本発明の実施形態の１つは、具体的には、ＡＴＭ、銀行、エージェント、ＰＯＳ、インタラクティブ音声応答システム、セルラー電話、固定線電話、インターネット、ＷＡＰ（セルを介する）、シンプルメッセージングシステム（固定線電話及びセルを介する）、ペルト（Perto）装置（即ち、請求書の支払を現金で受け付ける装置）及び郵便局を介して、本システムへアクセスする。
【０３５１】
本システムを使用する人のタイプにはいくつかの例がある。例えば、本システムは、消費者、家族会員、子供、ビジネスユーザー、ビジネスマネージャー、従業員（business subrdinate）、支払会社ユーザ及び銀行ユーザによって使用される。
【０３５２】
システムが資産を送金することができるアカウントのタイプにはいくつかの例がある。例えば、本システムは、銀行アカウント（様々なタイプ、当座用、預金用、成長用、教育用、休日用等）、キャッシュアカウント、クレジットカードアカウント、デビットカードアカウント、仮想アカウント、投資アカウント、仲介アカウント及びビジネスアカウントに関与することができる。本例のシステムは、上述、かつ従来より通常知られている送金についての通信に対し、複数のフォーマットを使用することができる。
【０３５３】
資産の受取人にはいくつかの例がある。例えば、支払のタイプは、通常、ピアーツーピア、ビジネス対消費者、ビジネス対ビジネスの３つのカテゴリに分けられる。より詳しくは、支払のタイプは、使用料、公共料、税金、地方用途（ライセンス等）、小売（レンガ＆モルタル）、小売（電子商取引／インターネット）、移動商取引、セルラー、ＩＳＰ、銀行、保険会社、慈善団体、仲介業者、ファミリー会員へのギフト及び固定線電話の請求書を含むことができる。
【０３５４】
送金のために他のアカウントと本例のシステムが通信する方法、あるいはどのようにして通信するかを判定する方法にはいくつかの例がある。例えば、支払アカウントは、国際無線電気通信データベース（セルラー）、国際固定線電気通信データベース（電話）、国際銀行アカウントデータベース、各支払受取会社の個々のアカウント−即ち、小売店レンナーは、レンナークレジットカードのすべての消費者のデータベースを持っている、税金用の支払タイプ及び地方自治体のデータベース、ライセンス等を介して確認することができる。
【０３５５】
本発明の様々な特徴及び効果は、詳細な明細書から明らかであり、つまり、本発明の本来の精神及び目的の範囲内で、本発明のこのような特徴のすべて及び効果は、添付の請求項によって含まれることが意図されている。また、様々な変形及び変更が当業者に対して容易に発生するので、本発明が図示の実際の構成及び動作に制限されるものではなく、従って、適切な変形及び等価構成が、本発明の目的の範囲内で行われても良い。
【図１】
2010081614.tif 000004
【図２】
2010081614.tif 000005
【図３】
2010081614.tif 000006
【図４】
2010081614.tif 000007
【図５】
2010081614.tif 000008
【図６】
2010081614.tif 000009
【図７】
2010081614.tif 000010
【図８】
2010081614.tif 000011
【図９】
2010081614.tif 000012
【図１０】
2010081614.tif 000013
【図１１】
2010081614.tif 000014
【図１２】
2010081614.tif 000015
【図１３】
2010081614.tif 000016
【図１４】
2010081614.tif 000017
【図１５】
2010081614.tif 000018
【図１６】
2010081614.tif 000019
【図１７】
2010081614.tif 000020
【図１８】
2010081614.tif 000021
【図１９】
2010081614.tif 000022
【図２０Ａ】
2010081614.tif 000023
【図２０Ｂ】
2010081614.tif 000024
【図２１】
2010081614.tif 000025
【図２２】
2010081614.tif 000026
【図２３】
2010081614.tif 000027
【図２４】
2010081614.tif 000028
【図２５】
2010081614.tif 000029
【図２６】
2010081614.tif 000030
【図２７】
2010081614.tif 000031
【図２８】
2010081614.tif 000032
【図２９】
2010081614.tif 000033
【図３０】
2010081614.tif 000034
【図３１】
2010081614.tif 000035
【図３２】
2010081614.tif 000036
【図３３】
2010081614.tif 000037
【図３４】
2010081614.tif 000038
【図３５】
2010081614.tif 000039
【図３６】
2010081614.tif 000040
【図３７】
2010081614.tif 000041
【手続補正書】
【提出日】平成21年11月4日(2009.11.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のネットワークを介して移動商取引サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、
前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに前記サービスを提供する権限を付与し、
前記サービスを提供するために、前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記有効ユーザアカウントから課金する
ことを特徴とする方法。
【請求項２】
複数のネットワークを介して移動商取引サービスを提供する装置であって、
サービスのリクエストとして、ローミングネットワークに配置されているユーザ装置からの識別番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからの前記サービスの料金を含む、前記リクエストを少なくとも１つの前記ネットワークを介して受信する受信部と、
少なくとも１つのプロセッサとして、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスを提供するために、前記有効ユーザアカウントから課金する
ように構成されているプロセッサと、
前記サービスプロバイダに認可を送信する送信部と
を備えることを特徴とする装置。
【請求項３】
複数のネットワークを介してプリペイドローミング通信サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及び宛先装置番号を受信し、
前記識別番号及び前記宛先装置番号に、サービスプロバイダ識別番号及びローミング通信サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が有効ユーザ情報に関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っている場合、前記ローミングネットワークに前記サービスを提供する権限を付与し、
前記サービスを提供するために、前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記有効ユーザアカウントから課金し、
前記ユーザアカウント残高が所定レベルに達する場合、信号を送信する
ことを特徴とする方法。
【手続補正書】
【提出日】平成21年11月18日(2009.11.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のネットワークを介して移動商取引サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、
前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに前記サービスを提供する権限を付与し、
前記サービスを提供するために、前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記有効ユーザアカウントから課金する
ことを特徴とする方法。
【請求項２】
複数のネットワークを介して移動商取引サービスを提供する装置であって、
サービスのリクエストとして、ローミングネットワークに配置されているユーザ装置からの識別番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからの前記サービスの料金を含む、前記リクエストを少なくとも１つの前記ネットワークを介して受信する受信部と、
少なくとも１つのプロセッサとして、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスを提供するために、前記有効ユーザアカウントから課金する
ように構成されているプロセッサと、
前記サービスプロバイダに認可を送信する送信部と
を備えることを特徴とする装置。
【請求項３】
複数のネットワークを介してプリペイドローミング通信サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及び宛先装置番号を受信し、
前記識別番号及び前記宛先装置番号に、サービスプロバイダ識別番号及びローミング通信サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っていることを検証し、
前記識別番号が有効ユーザ情報に関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスの初期費用に対する支払を行うための十分な金額を持っている場合、前記ローミングネットワークに前記サービスを提供する権限を付与し、
前記サービスを提供するために、前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記有効ユーザアカウントから課金し、
前記ユーザアカウント残高が所定レベルに達する場合、信号を送信する
ことを特徴とする方法。
【請求項４】
前記信号は、サービス停止、中断、再入金リクエスト及び少残高警告の少なくとも１つである
ことを特徴とする請求項３に記載の方法。
【請求項５】
複数のネットワークを介してプリペイドローミング通信サービスを提供する装置であって、
サービスのリクエストであって、ローミングネットワークに配置されているユーザ装置からの識別番号及び宛先装置番号と、サービスプロバイダに関するサービスプロバイダ識別番号及び前記ローミングネットワークからのサービスの料金を含むリクエストを、少なくとも１つの前記ネットワークを介して受信する受信部と、
少なくとも１つのプロセッサとして、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記ローミングネットワーク上の前記サービスを受信するために認可され、前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記サービスを提供するために、前記有効ユーザアカウントから課金する
ように構成されているプロセッサと、
前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を送信し、かつ前記ユーザアカウントが所定レベルに達する場合、信号を送信する送信部と
を備えることを特徴とする装置。
【請求項６】
前記少なくとも１つのプロセッサは、更に、
前記サービスを前記ユーザへ提供する比率を判定し、
前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザアカウントから課金する
ように構成されている
ことを特徴とする請求項５に記載の装置。
【請求項７】
前記信号は、サービス停止、中断、再入金リクエスト及び少残高警告の少なくとも１つである
ことを特徴とする請求項５に記載の装置。
【請求項８】
複数の独立ネットワークを介して、ネットワーク独立型消費者ケアサービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及び消費者ケアサービスリクエストを受信し、
前記識別番号及び前記消費者ケアサービスリクエストに、サービスプロバイダ識別番号を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連していることを検証し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に前記消費者ケアサービスを接続する
ことを特徴とする方法。
【請求項９】
前記消費者ケアサービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項８に記載の方法。
【請求項１０】
更に、前記有効ユーザアカウントが再入金メカニズムを承認していることを判定し、
前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する
ことを特徴とする請求項８に記載の方法。
【請求項１１】
更に、前記サービスプロバイダ識別番号を記憶する
ことを特徴とする請求項８に記載の方法。
【請求項１２】
複数のネットワークを介して、消費者ケアサービスを提供する装置であって、
消費者ケアサービスのリクエストであって、ローミングネットワークに配置されているユーザ装置からの識別番号と、前記ローミングネットワークからのサービスプロバイダに関連するサービスプロバイダ識別番号を含むリクエストを、少なくとも１つの前記ネットワークを介して受信する受信部と、
少なくとも１つのプロセッサとして、
前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記消費者ケアサービスを受信するために認可されていることを検証する、
ように構成されているプロセッサと、
前記識別番号が前記有効ユーザアカウントに関連している場合、前記ユーザ装置に、前記消費者ケアサービスを提供することができる消費者ケアサービスプロバイダを接続する接続部と
を備えることを特徴とする装置。
【請求項１３】
前記消費者ケアサービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項１２に記載の装置。
【請求項１４】
前記少なくとも１つのプロセッサは、更に、
前記有効ユーザアカウントが再入金メカニズムを承認していることを判定し、
前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する
ように構成されている
ことを特徴とする請求項１２に記載の装置。
【請求項１５】
集中通信プラットホームを介して提供されるサービスに対するプリペイドアカウントに再入金する方法であって、
前記集中通信プラットホームに配置されている消費者アカウントを使用するための認可用のユーザ識別番号を含むリクエストを、ユーザ装置から受信し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記ユーザ識別番号に関連する消費者アカウントが、提供対象のサービスに対して十分な残高を持っていないことを判定し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記消費者アカウントが認可済の再入金メカニズムを持っていることを判定し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記認可済の再入金メカニズムを使用して、前記消費者アカウントに再入金し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用を認可する
ことを特徴とする方法。
【請求項１６】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及びデータダウンロードの少なくとも１つである
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記集中通信プラットホームがホームネットワークに存在する場合には、前記受信は、ローミングネットワークから行う
ことを特徴とする請求項１５に記載の方法。
【請求項１８】
集中通信プラットホームを介して提供対象のサービスに対するプリペイドアカウントに再入金する装置であって、
前記集中通信プラットホームに配置されている消費者アカウントを使用するための識別番号を含む認可リクエストを、ユーザ装置から受信する受信部と、
少なくとも１つのプロセッサとして、
前記識別番号に関連する消費者アカウントが、提供対象のサービスに対して十分な残高を持っておらず、かつ前記消費者アカウントが再入金メカニズムを認可していることを判定し、
前記再入金メカニズムを使用して、前記消費者アカウントに再入金する、
ように構成されているプロセッサと、
前記集中通信プラットホームを介して、前記サービスに対して前記消費者アカウントの使用の認可を送信する送信部と
を備えることを特徴とする装置。
【請求項１９】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト及びデータダウンロードの少なくとも１つである
ことを特徴とする請求項１８に記載の装置。
【請求項２０】
前記集中通信プラットホームがホームネットワークに存在する場合には、前記ユーザ装置は、ローミングネットワークに存在する
ことを特徴とする請求項１８に記載の装置。
【請求項２１】
集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う方法であって、
少なくとも１つのプロセッサによって、リアルタイムで、複数のネットワークを介して提供される取引に対する有効ユーザアカウントから料金を課金し、
少なくとも１つのプロセッサによって、前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定し、
少なくとも１つのプロセッサによって、前記判定された料金に従って、前記複数のネットワークを介して前記プリペイド取引に対する前記プロバイダとの決済を行う
ことを特徴とする方法。
【請求項２２】
前記取引は、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２１に記載の方法。
【請求項２３】
更に、少なくとも１つのプロセッサによって、前記有効ユーザアカウントが十分な残高を持っていないことを判定し、
少なくとも１つのプロセッサによって、前記有効ユーザアカウントが再入金メカニズムを認可していることを判定し、
少なくとも１つのプロセッサによって、前記再入金メカニズムを使用して、前記有効ユーザアカウントに再入金する
ことを特徴とする請求項２１に記載の方法。
【請求項２４】
更に、少なくとも１つのプロセッサによって、前記取引及び前記複数のプロバイダそれぞれに対するプロバイダ識別番号を記憶する
ことを特徴とする請求項２１に記載の方法。
【請求項２５】
集中通信環境内の複数のプロバイダに対するプリペイド取引の決済を行う装置であって、
少なくとも１つのプロセッサとして、
リアルタイムで、複数のネットワークを介して提供される取引に対するユーザアカウントから課金し、
前記複数のネットワークを介する前記プリペイド取引の提供に関与する複数のプロバイダに分配すべき料金を判定する、
ように構成されているプロセッサと、
前記判定された料金に従って、前記複数のネットワークを介して前記プリペイド取引に対する前記プロバイダとの決済を行う送信部と
を備えることを特徴とする装置。
【請求項２６】
前記取引は、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスに対する購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２５に記載の装置。
【請求項２７】
前記取引及び前記複数のプロバイダそれぞれに対するプロバイダ識別番号を記憶する記憶部を更に備える
ことを特徴とする請求項２５に記載の装置。
【請求項２８】
複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する方法であって、
ローミングネットワークで、ユーザ装置から、識別番号及びサービスリクエストを受信し、
前記サービスが課金対象である場合、前記識別番号及び前記サービスリクエストに、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を追加して、前記ローミングネットワークからホームネットワークへ送信し、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っていることを検証し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供し、
前記集中通信プラットホームにおける少なくとも１つのプロセッサによって、前記サービスが課金対象である場合、前記サービスを提供するために、リアルタイムで前記有効ユーザアカウントから課金する
ことを特徴とする方法。
【請求項２９】
前記ローミングネットワークは、無線ネットワーク、シンプルメッセージングサービスネットワーク、公衆交換電話ネットワーク、パケット交換ネットワーク、回線交換ネットワーク、非同期ネットワーク、インターネット、イントラネット、マイクロ波ネットワーク、ケーブルネットワーク、イーサネットネットワーク、トークンリングネットワーク及びワイドエリアネットワークの少なくとも１つである
ことを特徴とする請求項１、３、８あるいは２８のいずれか１項に記載の方法。
【請求項３０】
前記ローミングネットワークは、異なるシグナリングプロトコルを利用する、ホームネットワーク以外の異なるエンティティの少なくとも１つによって制御され、かつ異なる位置に配置されている
ことを特徴とする請求項８あるいは２８に記載の方法。
【請求項３１】
前記ユーザ装置は、無線電話、有線電話、モデム、コンピュータ、パーソナルデジタルアシスタント、ページャー、セルラー電話及び無線送信機の少なくとも１つである
ことを特徴とする請求項１、３、８、１５あるいは２８のいずれか１項に記載の方法。
【請求項３２】
前記識別番号は、個人識別番号、加入者識別モジュール、国際移動体加入者識別子、国際移動局端末識別子、アルファベット及び数字の組み合わせ、及び１６進数の少なくとも１つである
ことを特徴とする請求項１、３、８、１５あるいは２８のいずれか１項に記載の方法。
【請求項３３】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスの購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３４】
前記サービスプロバイダは、前記サービスの料金の一部をそれぞれが受信する複数のビジネスを含んでいる
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３５】
更に、前記サービスプロバイダに課金額を送信する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３６】
更に、前記少なくとも１つのプロセッサによって、前記有効ユーザアカウントが十分な残高を持っていないことを判定し、
前記少なくとも１つのプロセッサによって、前記有効ユーザアカウントが再入金メカニズムを認可していることを判定し、
前記少なくとも１つのプロセッサによって、前記再入金メカニズムを使用して、前記ユーザアカウントに再入金する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項３７】
更に、前記少なくとも１つのプロセッサによって、ユーザ介入後に、前記有効ユーザアカウントが前記再入金メカニズムを認可していることを判定し、
前記少なくとも１つのプロセッサによって、再入金の認可を要求する前記ローミングネットワークで、前記ユーザ装置と接続し、
前記少なくとも１つのプロセッサによって、前記ユーザ装置が、再入金の認可の要求に正しく応答する場合、前記再入金を認可する
ことを特徴とする請求項３６に記載の方法。
【請求項３８】
前記再入金は、アカウント、金額及び資金源の少なくとも１つを特定するユーザ定義ルールに基づいている
ことを特徴とする請求項３６に記載の方法。
【請求項３９】
前記ユーザ定義ルールは、アカウント、過去の再入金、アカウント残高及び時間の少なくとも１つに基づく再入金優先度で、複数のアカウントを特定する
ことを特徴とする請求項３８に記載の方法。
【請求項４０】
前記再入金は、銀行アカウント、投資アカウント、クレジットアカウント及び認可済ローンアカウントの少なくとも１つから再入金を行う
ことを特徴とする請求項３６に記載の方法。
【請求項４１】
更に、前記課金及び前記サービスプロバイダ識別番号を記憶する
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項４２】
前記ローミング通信サービスの料金は、ローミング料金、サービス配信料金、通信料金、税金、設備使用追加料金、ディスカウント及び保険料金の少なくとも１つである
ことを特徴とする請求項１、３あるいは２８のいずれか１項に記載の方法。
【請求項４３】
更に、前記少なくとも１つのプロセッサによって、前記サービスを前記ユーザへ提供する比率を判定し、
前記少なくとも１つのプロセッサによって、前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザーアカウントから課金する
ことを特徴とする請求項３あるいは２８に記載の方法。
【請求項４４】
前記比率は、ローミングネットワーク比率、ホームネットワーク比率、通信比率、長距離比率、国際比率、税金率、設備使用追加料金比率、ディスカウント比率及び保険料金比率の少なくとも１つである
ことを特徴とする請求項２８に記載の方法。
【請求項４５】
複数のネットワークを介して、移動商取引、電子商取引、消費者ケア及び通信サービスを提供する装置であって、
サービスがローミングネットワークからの課金対象である場合、ユーザ装置からの識別番号、サービスリクエスト、サービスプロバイダに関するサービスプロバイダ識別番号及び前記サービスの料金を受信する受信部と、
前記ホームネットワークに配置される集中通信プラットホームにおける少なくとも１つのプロセッサとして、
前記識別番号が有効ユーザアカウントに関連しているか、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが前記サービスに対する支払を行うための十分な金額を持っているかを判定し、
前記サービスが課金対象である場合、前記サービスを提供するために、リアルタイムで前記有効ユーザアカウントから課金する
ように構成されているプロセッサと、
前記サービスが課金対象である場合、前記識別番号が前記有効ユーザアカウントに関連し、前記ユーザ装置が前記サービスを受信するために認可され、かつ前記有効ユーザアカウントが十分な金額を持っている場合、前記サービスプロバイダに認可を提供する送信部と、
を備えることを特徴とする装置。
【請求項４６】
前記ローミングネットワークは、無線ネットワーク、シンプルメッセージングサービスネットワーク、公衆交換電話ネットワーク、パケット交換ネットワーク、回線交換ネットワーク、非同期ネットワーク、インターネット、イントラネット、マイクロ波ネットワーク、ケーブルネットワーク、イーサネットネットワーク、トークンリングネットワーク及びワイドエリアネットワークの少なくとも１つである
ことを特徴とする請求項２、５、１２あるいは４５のいずれか１項に記載の装置。
【請求項４７】
前記ローミングネットワークは、異なるシグナリングプロトコルを利用する、ホームネットワーク以外の異なるエンティティの少なくとも１つによって制御され、かつ異なる位置に配置されている
ことを特徴とする請求項１２あるいは４５に記載の装置。
【請求項４８】
前記ユーザ装置は、無線電話、有線電話、モデム、コンピュータ、パーソナルデジタルアシスタント、ページャー、セルラー電話及び無線送信機の少なくとも１つである
ことを特徴とする請求項２、５、１２、１８あるいは４５のいずれか１項に記載の装置。
【請求項４９】
前記識別番号は、個人識別番号、加入者識別モジュール、国際移動体加入者識別子、国際移動局端末識別子、アルファベット及び数字の組み合わせ、及び１６進数の少なくとも１つである
ことを特徴とする請求項２、５、１２、１８あるいは４５のいずれか１項に記載の装置。
【請求項５０】
前記サービスは、電話接続、シンプルメッセージングサービスメッセージ、ファクシミリ送信、データ送信、商品／サービスの購入リクエスト、データダウンロード及び再入金リクエストの少なくとも１つである
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５１】
前記サービスプロバイダは、前記サービスの料金の一部をそれぞれが受信する複数のビジネスを含んでいる
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５２】
前記送信部は、更に、前記サービスプロバイダに課金額を送信する
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５３】
前記少なくとも１つのプロセッサは、更に、
前記有効ユーザアカウントが十分な残高を持っていないこと、かつ前記有効ユーザアカウントが再入金メカニズムを認可していることを判定し、
前記再入金メカニズムを使用して、前記ユーザアカウントに再入金する
ように構成されている
ことを特徴とする請求項２、５、２５あるいは４５のいずれか１項に記載の装置。
【請求項５４】
前記少なくとも１つのプロセッサは、更に、
ユーザ介入後に、前記有効ユーザアカウントが前記再入金メカニズムを認可していることを判定し、
前記ローミングネットワークの前記ユーザ装置へ、再入金の認可リクエストを送信し、
前記ユーザ装置が、前記再入金の認可リクエストに正しく応答する場合、前記再入金を認可する
ように構成されている
ことを特徴とする請求項５３に記載の装置。
【請求項５５】
前記再入金は、アカウント、金額及び資金源の少なくとも１つを特定するユーザ定義ルールに基づいている
ことを特徴とする請求項５３に記載の装置。
【請求項５６】
前記ユーザ定義ルールは、アカウント、過去の再入金、アカウント残高及び時間の少なくとも１つに基づく再入金優先度で、複数のアカウントを特定する
ことを特徴とする請求項５５に記載の装置。
【請求項５７】
前記少なくとも１つのプロセッサは、銀行アカウント、投資アカウント、クレジットアカウント及び認可済ローンアカウントの少なくとも１つから再入金を行う
ことを特徴とする請求項５３に記載の装置。
【請求項５８】
課金額及び前記サービスプロバイダ識別番号を記憶する記憶部
を更に備えることを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項５９】
前記ローミング通信サービスの料金は、ローミング料金、通信料金、税金、設備使用追加料金、ディスカウント及び保険料金の少なくとも１つである
ことを特徴とする請求項２、５あるいは４５のいずれか１項に記載の装置。
【請求項６０】
前記少なくとも１つのプロセッサは、更に、前記サービスを前記ユーザへ提供する比率を判定し、かつ前記課金部は、前記判定された比率で提供される前記サービスに対して、リアルタイムで前記有効ユーザーアカウントから課金する
ことを特徴とする請求項４５に記載の装置。
【請求項６１】
前記比率は、ローミングネットワーク比率、ホームネットワーク比率、通信比率、長距離比率、国際比率、税率、設備使用追加料金比率、ディスカウント比率及び保険料金比率の少なくとも１つである
ことを特徴とする請求項４５に記載の装置。
【外国語明細書】
2010081614.tif 000042
2010081614.tif 000043
2010081614.tif 000044
2010081614.tif 000045
2010081614.tif 000046
2010081614.tif 000047
2010081614.tif 000048
2010081614.tif 000049
2010081614.tif 000050
2010081614.tif 000051
2010081614.tif 000052
2010081614.tif 000053
2010081614.tif 000054
2010081614.tif 000055
2010081614.tif 000056
2010081614.tif 000057
2010081614.tif 000058
2010081614.tif 000059
2010081614.tif 000060
2010081614.tif 000061
2010081614.tif 000062
2010081614.tif 000063
2010081614.tif 000064
2010081614.tif 000065
2010081614.tif 000066
2010081614.tif 000067
2010081614.tif 000068
2010081614.tif 000069
2010081614.tif 000070
2010081614.tif 000071
2010081614.tif 000072
2010081614.tif 000073
2010081614.tif 000074
2010081614.tif 000075
2010081614.tif 000076
2010081614.tif 000077
2010081614.tif 000078
2010081614.tif 000079
2010081614.tif 000080
2010081614.tif 000081
2010081614.tif 000082
2010081614.tif 000083
2010081614.tif 000084
2010081614.tif 000085
2010081614.tif 000086
2010081614.tif 000087
2010081614.tif 000088
2010081614.tif 000089
2010081614.tif 000090
2010081614.tif 000091
2010081614.tif 000092
2010081614.tif 000093
2010081614.tif 000094
2010081614.tif 000095
2010081614.tif 000096
2010081614.tif 000097
2010081614.tif 000098
2010081614.tif 000099
2010081614.tif 000100
2010081614.tif 000101
2010081614.tif 000102
2010081614.tif 000103
2010081614.tif 000104
2010081614.tif 000105
2010081614.tif 000106
2010081614.tif 000107
2010081614.tif 000108
2010081614.tif 000109
2010081614.tif 000110
2010081614.tif 000111
2010081614.tif 000112
2010081614.tif 000113
2010081614.tif 000114
2010081614.tif 000115
2010081614.tif 000116
2010081614.tif 000117
2010081614.tif 000118
2010081614.tif 000119
2010081614.tif 000120
2010081614.tif 000121
2010081614.tif 000122
2010081614.tif 000123
2010081614.tif 000124
2010081614.tif 000125
2010081614.tif 000126
2010081614.tif 000127
2010081614.tif 000128
2010081614.tif 000129
2010081614.tif 000130
2010081614.tif 000131
2010081614.tif 000132
2010081614.tif 000133
2010081614.tif 000134
2010081614.tif 000135
2010081614.tif 000136
2010081614.tif 000137
2010081614.tif 000138
2010081614.tif 000139
2010081614.tif 000140
2010081614.tif 000141
2010081614.tif 000142
2010081614.tif 000143
2010081614.tif 000144
2010081614.tif 000145
2010081614.tif 000146
2010081614.tif 000147
2010081614.tif 000148
2010081614.tif 000149
2010081614.tif 000150
2010081614.tif 000151
2010081614.tif 000152
2010081614.tif 000153
2010081614.tif 000154
2010081614.tif 000155
2010081614.tif 000156
2010081614.tif 000157
2010081614.tif 000158
2010081614.tif 000159
2010081614.tif 000160
2010081614.tif 000161
2010081614.tif 000162
2010081614.tif 000163
2010081614.tif 000164
2010081614.tif 000165
2010081614.tif 000166
2010081614.tif 000167
2010081614.tif 000168
2010081614.tif 000169
2010081614.tif 000170
2010081614.tif 000171
2010081614.tif 000172
2010081614.tif 000173
2010081614.tif 000174
2010081614.tif 000175
2010081614.tif 000176
2010081614.tif 000177