(57)【要約】【課題】  前払いサービス提供を組み込んだインテリジェントでネットワークベースのＥコマース・システムを提供すること。【解決手段】  インテリジェント・ネットワークベース・Ｅコマース・システム１００は複数の前払い加入者に関連付けされた口座情報をメンテナンスするための１つまたは複数のサービス制御点（ＳＣＰ）１２２を含む。この口座情報はサービス・プロバイダ１０８〜１２０または加入者によってゲートウェイ・サーバ１０４を介してアクセス可能である。本電子商取引システムは加入者認証、残高要求操作、借り方処理要求操作および貸し方処理要求操作を含むトランザクションをサポートしている。【選択図】図１
2004164598.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数の加入者に前払いサービスを提供する電子商取引システムにおける加入者認証方法であって、
Ｅコマース見込み顧客に関連付けされた情報を含む認証要求をサービス・プロバイダから受け取る工程と、
前記顧客の加入者ステータスを決定する工程と、
前記加入者ステータスに基づいて、認証メッセージと非認証メッセージのうちの一方を前記サービス・プロバイダに送信する工程と
を含む方法。
【請求項２】
前記電子商取引システムが１つまたは複数のサービス制御点（ＳＣＰ）に動作可能に接続したゲートウェイ・サーバを備えると共に、
認証要求を前記ゲートウェイ・サーバによって受け取る工程と、
前記１つまたは複数のＳＣＰの中から１次ＳＣＰを前記ゲートウェイ・サーバによって決定する工程と、
顧客ＩＤと該顧客に関連付けした口座コードの少なくとも一方を含む認証要求メッセージを前記ゲートウェイ・サーバから前記１次ＳＣＰまで送信する工程と、
前記認証要求メッセージで特定される顧客ＩＤおよび口座コードのうちの１つまたは複数に基づいて、前記１次ＳＣＰによって顧客の加入者ステータスを決定する工程と、
前記顧客の加入者ステータスを指示するメッセージを前記１次ＳＣＰからゲートウェイ・サーバまで送信する工程と、
前記加入者ステータスに基づいて、認証メッセージと非認証メッセージのうちの一方をゲートウェイ・サーバから前記サービス・プロバイダまで送信する工程と
を含む請求項１に記載の方法。
【請求項３】
１つまたは複数の加入者に前払いサービスを提供する電子商取引システムにおいて残高要求操作を実行する方法であって、
加入者ＩＤと特定の加入者口座と関連付けした口座コードのうちの少なくとも一方を含む残高要求をエンドユーザから受け取る工程と、
前記残高要求操作の実施可能ステータスを決定する工程と、
前記残高要求操作が実施可能である場合に、前記口座に関連付けされた残高情報を取得し該残高情報の少なくとも一部分をエンドユーザに送信する工程と、
前記残高要求操作が実施不可能である場合に、エラーメッセージをエンドユーザに送信する工程と
を含む方法。
【請求項４】
前記電子商取引システムが１つまたは複数のサービス制御点（ＳＣＰ）に動作可能に接続したゲートウェイ・サーバを備えると共に、
残高要求を前記ゲートウェイ・サーバによって受け取る工程と、
前記１つまたは複数のＳＣＰの中から１次ＳＣＰを前記ゲートウェイ・サーバによって決定する工程と、
加入者ＩＤと該加入者に関連付けした口座コードの少なくとも一方を含む残高要求メッセージを前記ゲートウェイ・サーバから前記１次ＳＣＰまで送信する工程と、
加入者ＩＤおよび口座コードのうちの１つまたは複数に基づいて、前記１次ＳＣＰによって、残高要求操作の実施可能ステータスを決定する工程と
を含む請求項３に記載の方法。
【請求項５】
１つまたは複数の加入者に前払いサービスを提供する電子商取引システムにおいて借り方処理要求操作を実行する方法であって、
借り方処理額、加入者ＩＤおよび業者ＩＤを含む借り方処理要求をサービス・プロバイダから受け取る工程と、
前記借り方処理要求操作の実施可能ステータスを決定する工程と、
前記借り方処理要求操作が実施可能である場合に、加入者口座から前記借り方処理額を差し引き、更新した口座残高を求め、サービス・プロバイダに肯定応答メッセージを送信する工程と、
前記借り方処理要求操作が実施不可能である場合に、サービス・プロバイダにエラーメッセージを送信する工程と
を含む方法。
【請求項６】
前記電子商取引システムが１つまたは複数のサービス制御点（ＳＣＰ）に動作可能に接続したゲートウェイ・サーバを備えると共に、
前記借り方処理要求を前記ゲートウェイ・サーバによって受け取る工程と、
前記１つまたは複数のＳＣＰの中から１次ＳＣＰを前記ゲートウェイ・サーバによって決定する工程と、
借り方処理額、加入者ＩＤおよび業者ＩＤを含む借り方処理要求メッセージを前記ゲートウェイ・サーバから前記１次ＳＣＰまで送信する工程と、
借り方処理額、加入者ＩＤおよび業者ＩＤのうちの１つまたは複数に基づいて、前記借り方処理要求操作の実施可能ステータスを前記１次ＳＣＰによって決定する工程と
を含む請求項５に記載の方法。
【請求項７】
１つまたは複数の加入者に前払いサービスを提供する電子商取引システムにおいて貸し方処理要求操作を実行する方法であって、
貸し方処理額および加入者ＩＤを含む貸し方処理要求をサービス・プロバイダから受け取る工程と、
前記貸し方処理額を加入者口座に加算し、更新口座残高を求める工程と、
肯定応答メッセージをサービス・プロバイダに送信する工程と
を含む方法。
【請求項８】
前記電子商取引システムが１つまたは複数のサービス制御点（ＳＣＰ）に動作可能に接続したゲートウェイ・サーバを備えると共に、
前記貸し方処理要求を前記ゲートウェイ・サーバによって受け取る工程と、
前記１つまたは複数のＳＣＰの中から１次ＳＣＰを前記ゲートウェイ・サーバによって決定する工程と、
貸し方処理額および加入者ＩＤを含む貸し方処理要求メッセージを前記ゲートウェイ・サーバから前記１次ＳＣＰまで送信する工程と、
１次ＳＣＰによって前記貸し方処理額を前記加入者ＩＤに関連付けされた口座残高に加算し、これにより更新口座残高を求めるトランザクションを規定する工程と、
前記トランザクションを前記１次ＳＣＰによって記録する工程と、
前記１次ＳＣＰから前記ゲートウェイ・サーバまで肯定応答メッセージを送信する工程と、
前記肯定応答メッセージを前記ゲートウェイ・サーバからサービス・プロバイダまで転送する工程と
を含む請求項７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には電子商取引（すなわち「Ｅコマース（ｅ−ｃｏｍｍｅｒｃｅ）」）の分野に関し、さらに詳細には、前払いサービス提供を組み込んだインテリジェントでネットワークベースのＥコマース・システムに関する。
【背景技術】
【０００２】
インターネットなどの通信ネットワークは、広い地理的エリアに及ぶ通信デバイスを相互接続できることが知られている。一般に、インターネット（ワールド・ワイド・ウェブ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）と呼ぶこともある）は、同じプロトコルで対話するローカル・エリア・ネットワーク（ＬＡＮ）やワイド・エリア・ネットワーク（ＷＡＮ）が組み合わされたものであり、これによりインターネットに接続したさまざまな通信デバイスは互いに通信することが可能となる。インターネット上で使用する一群のプロトコルは、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）（すなわち、ＴＣＰ／ＩＰ）として知られている。インターネットにアクセスできる通信デバイスとしては、たとえば、コンピュータ、携帯電話、有線式電話、ポケットベル、双方向無線機および携帯情報端末（ＰＤＡ）が含まれる。これらの通信デバイスはイーサネット（登録商標）、電話回線、固定無線、衛星あるいは非同期転送モード（ＡＴＭ）ネットワークなどのアクセス・テクノロジーを用いてインターネットに接続する。
【０００３】
よく知られているように、インターネットに接続した通信デバイスのユーザは事業会社、政府組織、金融機関や教育機関その他がホストとなったさまざまなＷｅｂサイトをサーフィンすることがある。これらのサイトの幾つかは、インターネット・ユーザが電子的に（すなわち、ユーザ・デバイスを介してポイント・アンド・クリック、キー操作その他を実行することによって）購入できる販売向けの商品やサービスを提供することが知られている。この種の販売トランザクションは一般に、電子商取引、すなわちＥコマースとして知られている。現在知られているように、Ｅコマース・トランザクションは、購入のために品目（複数のこともある）やサービス（複数のこともある）を選択した顧客に対して支払い実行のためにクレジットカード番号を入力することを要求する。（別法として、顧客が以前のトランザクションにおいてすでにクレジットカードを入力しており販売者がそのカードの記録をメンテナンスしていることがある）。その後、販売者は、クレジットカード承認を確認し、選択され商品やサービスを引き渡し、さらにクレジットカード会社から支払いを受ける。顧客は、少し後にクレジットカード会社に支払いを行う。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ある種のＥコマース見込み顧客は商品やサービスをインターネット上で購入したいがクレジットカードを所持していないことがあるという問題が生じている。こうした顧客としては、たとえば、未成年者、家計を現金ベースとしている者、クレジット・チェックをパスしそうにない者、あるいはクレジットカードを好まない者が含まれることがある。これが目下のところＥコマース業者によってまだ開拓されていない巨大な潜在的マーケットとなっている。このマーケットの開拓のためには、ネットワークベースの業者はこうした顧客に対して「前払い（ｐｒｅｐａｉｄ）」サービスを提供し、あらゆる階層の顧客がある種のレベルの商品やサービスを（従来のＥコマース・トランザクションにおけるように少し後になって料金を支払うのではなく）前金で支払うことができるようにし、これにより、その前払い口座のクレジット・レベルが尽きる時点まで顧客にＥコマース・トランザクションを行う機会が与えられるようにすることが望ましい。前払いサービスの提供は、音声テレコミュニケーションでは知られているが、現在Ｅコマース・トランザクションでは利用可能となっていない。
【課題を解決するための手段】
【０００５】
本発明によるシステムおよび方法の実施形態は、前払いサービス提供を組み込んだインテリジェントでネットワークベースのＥコマース・システムを提供する。この前払いＥコマース・サービスは、既存の前払い音声テレコミュニケーション・サービス提供に基づくと共に該サービス提供と互換性を有し、これにより前払いした顧客はクレジットカードやクレジット契約を要することなくかつ月次の請求を受けることなく、あらゆる製品やサービスに対するインターネット・ベースの前払い購入および／またはＰＯＳベースの前払い購入を含め電話およびその他のサービス・トランザクションを実行することが可能となる。このサービスは、共通のゲートウェイを介して複数のサービス・プロバイダや加入者によってアクセス可能な単一の前払い口座（個別の複数の口座ではなく）を顧客が設けるように集中化している。
本発明の上述およびその他の利点は、以下の詳細な説明を読みかつ図面を参照することによって明らかとなろう。
【発明を実施するための最良の形態】
【０００６】
ここで図面に移り、先ず図１を参照すると、本発明の一実施形態に従ったインテリジェント・ネットワークベースＥコマース・システム１００を表している。Ｅコマース・システム１００は、ゲートウェイ・サーバ１０４を介してパケット・ネットワーク１０６（図示では、ＴＣＰ／ＩＰネットワーク）に接続されているサービス・システム１０２を備えている。パケット・ネットワーク１０６は、Ｅコマース・トランザクションを実行するためにサービス・システム１０２へのアクセスを要求することができるさまざまなＥコマース業者および／またはサービス（以下において、「サービス・プロバイダ」と云う）とインタフェースしている。図のように、これらのサービス・プロバイダとしては、ショート・メッセージ・サービス・センタ（「ＳＭＳＣ」）１０８、Ｗｅｂアプリケーション・プラットフォーム（ＷＡＰ）サーバ１１０、ゼネラル・パケット・ラジオ・サービス（ＧＰＲＳ）ネットワーク１１２、業者ネットワーク１１４および金融ネットワーク１１６が含まれる。図のように、業者ネットワーク１１４および金融ネットワーク１１６はインターネット１１８または「ＰＯＳ（ｐｏｉｎｔ  ｏｆ  ｓａｌｅｓ）」サーバ１２０を介してサービス・システムにアクセスする。前払いＥコマース・サービスの加入者（すなわち、Ｅコマース顧客）もまた、インターネット１１８またはＰＯＳサーバ１２０を介してサービス・システムにアクセスする。
【０００７】
当然のことながら、Ｅコマース・システム１００に示すサービス・プロバイダはすべてを網羅したものではなく、前払い顧客に利用可能な広範なＥコマース・オプションを一般的に表したものである。これらのサービス・プロバイダで利用可能なサービスの種別としては、たとえば、商品、映画のチケット、電話サービス、ショート・メッセージ・サービス、ＷＡＰサービス、インターネット利用、インターネット・ゲーム、および音楽やファイルのアップロード／ダウンロードの購入が含まれる（ただしこれらに限らない）。顧客は、移動式電話、ワイヤレス・ハンドへルド型デバイス、キオスク（ｋｉｏｓｋ）、サービス箇所設置（ｐｏｉｎｔ−ｏｆ−ｓｅｒｖｉｃｅ）クライアント、インターネット画面など（ただしこれらに限らない）を含む通信デバイス（図示せず）を用いてサービス・プロバイダと対話する。
【０００８】
サービス・システム１０２は、複数のサービス制御点（ＳＣＰ）１２２と、サービス・マネージャ・システム（ＳＭＳ）１２４と、リチャージ・カード管理システム（ＲＣＭＳ）１２６と、を備えている。これらのデバイスの各々はそれぞれに、サービス・システム１０２のサービスおよび機能に関するある種のトランザクションを実現するためのプロセッサとメモリ（図示せず）を含んでいる。本明細書の以下でより詳細に記載することにするが、サービス・システム１０２がサポートしているトランザクションとしては、前払い加入者口座の認証（図２）、加入者口座の残高要求（図３）、加入者口座の借り方処理要求（図４）、および加入者口座の貸し方処理要求（図５）が含まれる。
【０００９】
ＳＣＰ１２２は加入者口座をメンテナンスすると共に加入者残高（複数のこともある）に対する「ポータル（ｐｏｒｔａｌ）」の役割を果たしており、これによってＥコマース・トランザクションの過程でサービス・プロバイダにより加入者口座（複数のこともある）へのアクセスおよび変更が可能となる。一実施形態では、冗長性をもたせるため一組のＳＣＰ対を設け、加入者ごとに「１次の」ＳＣＰと「２次の」ＳＣＰを指定している。
【００１０】
これらのＳＣＰは、リンク１２８（図示では、アプリケーション・プログラム可能インタフェース（ＡＰＩ）リンク（複数のこともある））を介してゲートウェイ・サーバ１０４に接続している。ＡＰＩリンクの一例は、Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓによって開発された軽量ディレクトリ・アクセス・プロトコル（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ：ＬＤＡＰ）である。ＳＣＰ１２２はさらに、リンク１３２（図示では、ＳＳ７電話信号リンク）を介して電話ネットワーク１３０に接続しており、サービス・システム１０２がネットワークベースのサービス・プロバイダ１０８〜１２０によって提供されるサービスに加えて電話ネットワーク１３０のユーザに対する前払い音声サービスをサポートできるようにしている。電話ネットワーク１３０はＳＳ７リンクを用いた配線式すなわち有線式ネットワークを備えることがある。
【００１１】
ＳＭＳ１２４は、サービス・システム１０２に対してプロビジョン機能（ｐｒｏｖｉｓｉｏｎｉｎｇ）、管理機能（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）および監督機能（ｍａｎａｇｅｍｅｎｔ）を実行する。一般にこれには、サービス・システム１０２に関連付けされた加入者およびサービス情報の作成および／またはメンテナンス、ならびに必要に応じたＳＣＰ１２２への当該情報のダウンロードが含まれる。ＳＭＳ１２４は、ＡＰＩリンク１２８またはＴＣＰ／ＩＰインタフェース（図示せず）（たとえば、ＴＣＰ／ＩＰ上のＣＯＲＢＡ）を介してＳＣＰと通信している。より具体的には、ＳＭＳ１２４の役割としては、新規の加入者口座の開設および／または既存口座（加入者ＩＤや貸し方処理額を含む）のメンテナンス、１次／２次ＳＣＰに対する加入者ＩＤのマッピング、加入者のさまざまな属性（たとえば、年齢、性別、言語の種別、通貨の種別、利用データ、サービス特典および／または制約）の特定、ならびに口座／利用情報に関する包括的報告の作成、が含まれる。
【００１２】
ＲＣＭＳ１２６は、加入者口座の定期的なリチャージすなわち補充、ならびに必要に応じたリチャージ情報のＳＭＳ１２４への伝達を容易にしている。ＲＣＭＳ１２４はＡＰＩリンク１２８またはＴＣＰ／ＩＰインタフェース（図示せず）を介してＳＭＳ１２４と通信している。
【００１３】
ゲートウェイ・サーバ１０４は、サービス・システム１０２にアクセス（したがってさらに、前払い加入者口座にアクセス）してＥコマース・トランザクションを容易にするような、サービス・プロバイダおよび／または加入者に対するインタフェースの役割をしている。ゲートウェイ・サーバ１０４は、１つまたは複数の物理デバイス内に常駐できる１つの機能要素である。図のように、すべてのネットワークベース型サービス・プロバイダ１０８〜１２０は、ＴＣＰ／ＩＰネットワーク１０６を介してゲートウェイ・サーバにアクセスしており、一方電話ネットワーク１３０はＳＳ７プロトコルを使用して直接サービス・システム１０２にアクセスすることができる。ＴＣＰ／ＩＰネットワーク１０６は１つまたは複数のルータ（図示せず）を介してＩＰメッセージ（すなわち、「データグラム」）を搬送するように適応させている。当然のことながら、代替的な構成も可能である。たとえば、ある種のサービス・プロバイダ１０８〜１２０はゲートウェイ・サーバ１０４と直接（すなわち、ＴＣＰ／ＩＰネットワーク１０６以外のリンク／ネットワークを介して）インタフェースすることがある。
【００１４】
一実施形態では、メッセージはゲートウェイ・サーバと、サービス・プロバイダ１０８〜１２０および／または加入者との間で拡張可能なマーク付け言語（ＸＭＬ）を用いて通信される。ＸＭＬは、Ｗｅｂ上の構造化された文書やデータに対するユニバーサル形式である。したがってＸＭＬプロトコルは、サービス・プロバイダおよび加入者に対して、加入者口座情報にアクセスする際の非常に大きな柔軟性を提供する。たとえば、サービス・プロバイダまたは加入者は、インターネット画面、ＰＯＳコンピューティング・デバイス、ワイヤレス・デバイス、あるいは一般に、ＸＭＬプロトコルを介してゲートウェイ・サーバ１０４と通信可能な任意のデバイスから口座情報にアクセスすることがある。当然のことながら、ＸＭＬ以外のプロトコルを使用することも可能である。
【００１５】
一実施形態では、ゲートウェイ・サーバ１０４は、Ｅコマース操作に関するプロトコル変換、ＳＣＰ（複数のこともある）に対する加入者マッピング、および操作のログ作成という３つの主たる機能を実行する。プロトコル変換機能は、サービス・プロバイダまたは加入者からのＸＭＬクエリーまたはトランザクション要求をサービス・システム１０２がサポートしているＡＰＩ形式に変換すること、また逆に、サービス・システム１０２のＡＰＩ応答をサービス・プロバイダ１０８〜１２０または加入者に伝達するためにＸＭＬ形式に変換すること、を含む。マッピング機能は、Ｅコマース・トランザクションを実行したことがある各加入者に関する１次および２次ＳＣＰを特定するためのデータベースのメンテナンスを含む。Ｅコマース・システムに関して新規ユーザであるような加入者では、ゲートウェイ・サーバは１次および２次ＳＣＰを特定するようにＳＭＳ１２４にクエリーを出し、その後マッピング・テーブル／データベース内の情報をメンテナンスする。その後、ある特定の加入者に関するクエリーまたはトランザクションを受け取ると、ゲートウェイ・サーバはマッピング・テーブルを参照して１次および２次ＳＣＰを決定する（したがって、サービス・プロバイダおよび加入者は負担から開放される）。随意選択では、ゲートウェイ・サーバは、ある時間期間にわたって働きかけがない加入者のマッピングに対して定期的に削除を実施することがある。さらに、ゲートウェイ・サーバは、最初に特定した１次または２次ＳＣＰに関して障害が発生した場合（発生時点で）１次および２次ＳＣＰを定期的に特定し直すことがある。一実施形態では、ゲートウェイ・サーバ上にＳＭＳを介した加入者の新規エントリに関する自動プロビジョンが存在する場合（すなわち、ＳＭＳがゲートウェイのマッピング・テーブル内の新規加入者を自動的にプロビジョンする場合）、ゲートウェイは、受け取った着信要求内の加入者ＩＤが未承認であるとクライアント・システムにエラーメッセージを返す。ログ作成機能は、すべての要求をログ記録し各要求に対する結果（すなわち、成否）を指示する。
【００１６】
一実施形態では、ゲートウェイ・サーバは、１００万人の顧客からなる加入者ベースをサポートするように動作可能なプロセッサおよびメモリ（図示せず）を含んでいる。この性能レベルはＥコマース・システム１００の適用範囲に応じてスケール調整／チューニングすることができる。
【００１７】
図２〜６は、Ｅコマース・システム１００がサポートしているさまざまなＥコマース・トランザクションを表した流れ図である。これらのトランザクションとしては、前払い加入者口座の認証（図２）、加入者口座の残高要求（図３）、加入者口座の借り方処理要求（図４）、加入者口座の貸し方処理要求（図５）、ならびにエンドユーザによるＥコマース・システムの操作（すなわち、オンライン購入を実行すること）が含まれる。図２〜６の各工程は、適用可能である場合、Ｅコマース・システム１００のゲートウェイ・サーバ１０４、ＳＣＰ１２２またはＳＭＳ１２８内に保存したソフトウェア・ルーチンを用いて実現される。
【００１８】
図２に戻ると、本発明の一実施形態に従った加入者認証操作を表した流れ図を示している。一般にこの操作は、Ｅコマース・システム１００に有効な加入者口座が存在することを確認するために使用する。たとえば、サービス・プロバイダは有料のサービスまたは商品を見込み顧客に引き渡す前に加入者認証の受け取りを希望することがある。
【００１９】
工程２０２において、ゲートウェイ・サーバ１０４は加入者認証要求を受け取る。この要求はたとえば、見込み顧客とのＥコマース・トランザクションを検討しているネットワークベースのサービス・プロバイダ１０８〜１２０から受け取ることがある。一実施形態では、この要求は、当該の見込み顧客に関連付けされた加入者ＩＤおよび口座コードを含む。一実施形態では、この要求はＸＭＬプロトコルのメッセージである。
【００２０】
この要求に応答してゲートウェイ・サーバ１０４は、工程２０４において、該要求で特定された加入者ＩＤおよび／または口座コードに対応する加入者データが見出されるか否かを判定するためにマッピング・テーブルを参照する。一実施形態では、この加入者データはＥコマース・システムの１次または２次ＳＣＰ（複数のこともある）に関する識別名（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を含む。当然のことながら、異なるサービス・プロバイダは、この異なるサービス・プロバイダの名称付与／番号付与スキームに応じて、同じ加入者に対して異なるＩＤ（複数のこともある）または口座コードを有することがある。たとえば、移動式ワイヤレス・サービス・プロバイダでは、その加入者ＩＤは、そのサービス・プロバイダのネットワークに応じてモバイル・ステーション国際加入者登録番号（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｄｉｒｅｃｔｏｒｙ  Ｎｕｍｂｅｒ：ＭＳＩＳＤＮ）またはモバイル登録番号（Ｍｏｂｉｌｅ  Ｄｉｒｅｃｔｏｒｙ  Ｎｕｍｂｅｒ：ＭＤＮ）とすることが可能である。一実施形態では、そのマッピング・テーブルは、異なる加入者ＩＤ（複数のこともある）／口座コードを収容するために、適用可能であれば、個別の加入者（複数のこともある）に対する複数のＩＤのマッピングを含む。
【００２１】
工程２０６における判定で加入者データが見つからない場合、ゲートウェイ・サーバは、随意選択において、工程２０８で決定されるＳＭＳに対して、ＳＭＳ１２４が当該加入者ＩＤに対応した１次および／または２次ＳＣＰを特定可能か否かを判定するようにクエリーを出す。工程２０８における肯定判定に応答して、工程２１０においてゲートウェイ・サーバはＳＭＳにクエリーを出す。一実施形態では、たとえば、ゲートウェイ・サーバのマッピング・テーブルでは初回のユーザに対して１次や２次のＳＣＰが特定されない。こうした場合、ゲートウェイ・サーバは当該の初回ユーザに対する１次および２次ＳＣＰを特定するようにＳＭＳにクエリーを出すことがある。その後ゲートウェイ・サーバはそのマッピング・テーブル内の情報をメンテナンスする。
【００２２】
ＳＭＳに対してクエリーを出した後でもなお加入者データが見出されない場合、または工程２０８においてゲートウェイ・サーバがＳＭＳにクエリーを出さないと決定した場合には、ゲートウェイ・サーバは工程２１２において要求を出したシステムにエラーメッセージを返す。上記以外の場合で加入者データが見出された場合（すなわち、ゲートウェイ・サーバが当該加入者ＩＤに対応した１次および／または２次ＳＣＰを特定した場合）、ゲートウェイ・サーバは工程２１４において指定されたＳＣＰ（複数のこともある）に認証要求メッセージを送信する。一実施形態では、この送信には加入者ＩＤおよび口座コードを適当なＡＰＩ形式で１次ＳＣＰに送信し、また所定の時間内に応答が受け取れない場合に２次ＳＣＰに送信することを含む。別法として、当然のことながら、ゲートウェイ・サーバは１次ＳＣＰおよび２次ＳＣＰに同時に認証要求を送信することがある。便宜上、以下において「ＳＣＰ」という用語により１次ＳＣＰであるか２次ＳＣＰであるかによらず運用ＳＣＰを指し示すことを理解されたい。
【００２３】
工程２１６において、ＳＣＰは見込み顧客の加入者ステータスを決定する。一実施形態では、この決定には、その加入者ＩＤが存在するか否か（すなわち、当該加入者ＩＤが有効な加入者に対応するものであるか否か）、その口座コードが存在するか否か（すなわち、当該口座コードが有効な口座に対応するものであるか否か）、ならびに加入者ＩＤと口座コードがマッチングしているか否か（すなわち、当該口座がその加入者に属するか否か）を判定することを含む。判断ブロック２１８、２２０、２２２において判定されるこれらの条件のいずれかでも否であれば、ＳＣＰは工程２２４においてゲートウェイ・サーバに非認証メッセージを返す。逆に、これらの条件のそれぞれが諾であれば、ＳＣＰは工程２２６においてゲートウェイ・サーバに認証メッセージを返す。ゲートウェイ・サーバは工程２２８において、このメッセージをＡＰＩ形式からＸＭＬ形式に適宜変換した後に要求を出したシステムに転送する。
【００２４】
図３は本発明の一実施形態に従った残高要求操作の流れ図である。一般に、この操作は、加入者がＥコマース・システム１００によってメンテナンスされている自身の加入者口座（複数のこともある）の残高を取得するために使用する。加入者は１つまたは複数の口座をメンテナンスしていることがある。
【００２５】
工程３０２において、ゲートウェイ・サーバ１０４は残高要求を受け取る。一実施形態では、その要求は加入者に関連付けされた加入者ＩＤおよび口座コードを含むＸＭＬ形式のメッセージを含んでいる。例示目的のため要求は加入者から受け取ることを想定している。別法または追加として、残高要求（複数のこともある）はサービス・プロバイダや加入者の代理人など加入者以外のエンドユーザ、ならびに当該加入者ＩＤおよび口座コードにアクセス権限を有する金融機関、法執行機関担当者、その他が受け取る可能性がある。
【００２６】
この要求に応答してゲートウェイ・サーバ１０４は、工程３０４において、該要求で特定された加入者ＩＤおよび／または口座コードに対応する加入者データが見出されるか否かを判定するためにマッピング・テーブルを参照する。一実施形態では、この加入者データは加入者ＩＤおよび／または口座コードに関連付けされた１次または２次ＳＣＰ（複数のこともある）に関する識別名を含む。
【００２７】
工程３０６における判定で加入者データが見つからない場合は、ゲートウェイ・サーバは、随意選択において、工程３０８で決定されるＳＭＳに対して、ＳＭＳ１２４が当該加入者ＩＤに対応した１次および／または２次ＳＣＰを特定可能か否かを判定するようにクエリーを出す。工程３０８における肯定判定に応答して、工程３１０においてゲートウェイ・サーバはＳＭＳにクエリーを出す。ＳＭＳに対してクエリーを出した後でもなお加入者データが見出されない場合、または工程３０８においてゲートウェイ・サーバがＳＭＳにクエリーを出さないと決定した場合には、ゲートウェイ・サーバは工程３１２において要求を出したシステムにエラーメッセージを返す。上記以外の場合で加入者データが見出された場合（すなわち、ゲートウェイ・サーバが当該加入者ＩＤに対応した１次および／または２次ＳＣＰを特定した場合）、ゲートウェイ・サーバは工程３１４において指定されたＳＣＰ（複数のこともある）に残高要求メッセージを送信する。
【００２８】
工程３１６において運用ＳＣＰは、当該加入者口座に対して残高要求操作が実施可能か実施不可能かを判定する。口座の実施可能ステータスまたは実施不可能ステータスはサービス・システム１０２が単独で、または加入者命令に応答して指定することができる。たとえば、残高要求操作はインターネットを介するのではなく電話による残高要求を容易にするためにサービス・システム１０２によって実行不可能にされる可能性があり、あるいは残高要求操作は加入者命令に応答して特定の要求者または要求者リストに対してのみ実施可能とさせる可能性がある。この実施可能ステータスまたは実施不可能ステータスは、同じ加入者でも口座が異なれば様々に異なることがある。
【００２９】
工程３１８における判定において残高要求操作が実施可能であれば、ＳＣＰは工程３２０において加入者口座に関連付けされた残高情報をゲートウェイ・サーバに返す。随意選択では、加入者が複数の口座をメンテナンスしている場合は、その残高情報には残高要求操作が実施可能となっている口座の各々の残高を含むことがある。残高要求操作が実施不可能である場合には、ＳＣＰは工程３２２において、当該残高要求操作が拒絶されたとのエラーメッセージやその他何らかの指示を返す。次いで工程３２４において、ゲートウェイ・サーバはこのメッセージをＡＰＩからＸＭＬ形式に変換しこの残高情報またはエラーメッセージを加入者またはエンドユーザに転送する。
【００３０】
図４は、本発明の一実施形態に従った借り方処理要求操作を表した流れ図である。一般にこの操作は、サービス・プロバイダがＥコマース・トランザクションに応答して加入者口座の残高に借り方処理するために使用される。
【００３１】
工程４０２において、ゲートウェイ・サーバ１０４はサービス・プロバイダから借り方処理要求を受け取る。この要求はたとえば、Ｅコマース・トランザクションに応答して商品やサービスを顧客に引き渡した（または、引き渡す予定にしている）ネットワークベースのサービス・プロバイダ１０８〜１２０のいずれかから受け取ることがある。たとえば、この要求は、ワイヤレス・ネットワーク（たとえば、ＷＡＰ、ＧＰＲＳなどを介する）からの場合や、インターネットやＰＯＳサーバを介する業者からの場合がある。一実施形態では、その要求は、加入者ＩＤ、購入額、およびサービス・プロバイダに関連付けされた業者ＩＤが含まれる。一実施形態では、その要求はＸＭＬプロトコルのメッセージである。
【００３２】
この要求に応答してゲートウェイ・サーバ１０４は、工程４０４において、図２に関連する記載と実質的に同様にして、加入者ＩＤに関連付けされた１次および／または２次ＳＣＰ（複数のこともある）を決定するためにマッピング・テーブルを参照する。例示目的のため、ゲートウェイ・サーバが工程４０４において１次および／または２次ＳＣＰを首尾よく特定できるものと想定している。工程４０６において、ゲートウェイ・サーバは借り方処理要求メッセージを指定されたＳＣＰ（複数のこともある）に送信する。一実施形態では、その借り方処理要求はＡＰＩ形式をしていると共に、加入者ＩＤ、口座コード、トランザクションＩＤ、メッセージ種別（すなわち、借り方処理要求）、口座インジケータ、借り方処理額および通貨インジケータなどのパラメータを含んでいる。
【００３３】
工程４０８において、運用ＳＣＰは加入者口座に関連付けされた残高およびサービス・ステータスを決定する。一実施形態では、この決定には当該残高が要求された購入額をまかなうだけ十分にあるか否か（すなわち、適用可能な場合で、最小残高しきい値を十分超えているか否か）、ならびに当該口座が実施可能か実施不可能か、を判定することを含む。判断ブロック４１０、４１２による判定によって残高が不十分であるか当該口座が実施不可能であった場合には、ＳＣＰは工程４２０において、必要に応じて残高が不十分であることまたは口座が実施不可能であること示すエラーメッセージをゲートウェイ・サーバに返す。逆に、残高が十分にありかつ口座が実施可能であれば、ＳＣＰは、工程４１４において当該加入者口座の借り方処理を行い、工程４１６においてそのトランザクションを呼詳細記録（ＣＤＲ）内に記録し、かつ工程４１８において更新した口座残高を伴う肯定応答メッセージをゲートウェイ・サーバに送信する。一実施形態では、そのＣＤＲは、加入者ＩＤ、口座コード、トランザクションＩＤ、借り方処理額、通貨インジケータ、口座インジケータおよびメッセージ種別（すなわち、借り方処理要求）などのパラメータを含む。ゲートウェイ・サーバは工程４２２において、この肯定応答またはエラーメッセージを必要に応じてＡＰＩ形式からＸＭＬ形式に適宜変換した後、要求を出したシステムに転送する。
【００３４】
図５は、本発明の一実施形態に従った貸し方処理要求操作を表した流れ図である。一般に、この操作はサービス・プロバイダが顧客による商品の返品、購入のキャンセル、課金過剰（ｏｖｅｒｃｈａｒｇｅ）、その他に応答して加入者口座の残高に対して貸し方処理を行うために使用する。
【００３５】
工程５０２において、ゲートウェイ・サーバ１０４はサービス・プロバイダから貸し方処理／払戻し要求を受け取る。この要求はたとえば、借り方処理要求に関して図４に関連して記載したようなサービス・プロバイダのいずれかから受け取ることがある。一実施形態では、その要求には、加入者ＩＤや、その加入者口座に貸し方処理すべき額が含まれる。一実施形態では、その要求はＸＭＬプロトコルのメッセージである。
【００３６】
この要求に応答してゲートウェイ・サーバ１０４は、工程５０４において、図２に関連する記載と実質的に同様にして、当該加入者ＩＤに関連付けされた１次および／または２次ＳＣＰ（複数のこともある）を決定するためにそのマッピング・テーブルを参照する。例示目的のため、ゲートウェイ・サーバが工程５０４において１次および／または２次ＳＣＰを首尾よく特定できるものと想定している。工程５０６において、ゲートウェイ・サーバは貸し方処理要求メッセージを指定されたＳＣＰ（複数のこともある）に送信する。一実施形態では、その貸し方処理要求はＡＰＩ形式をしていると共に、加入者ＩＤ、口座コード、トランザクションＩＤ、メッセージ種別（すなわち、貸し方処理要求）、業者識別子、口座インジケータ、貸し方処理額および通貨インジケータなどのパラメータを含んでいる。
【００３７】
工程５０８において運用ＳＣＰは加入者口座の貸し方処理を行い、さらに工程５１０において該ＳＣＰはそのトランザクションを呼詳細記録（ＣＤＲ）内に記録する。一実施形態では、そのＣＤＲは、加入者ＩＤ、口座コード、トランザクションＩＤ、貸し方処理額、通貨インジケータ、口座インジケータ、メッセージ種別（すなわち、貸し方処理要求）および業者識別子などのパラメータを含む。工程５１２においてＳＣＰは更新した口座残高を伴う肯定応答メッセージをゲートウェイ・サーバに送信する。ゲートウェイ・サーバは工程５１４において、この肯定応答をＡＰＩ形式からＸＭＬ形式に適宜変換した後、要求を出したシステムに転送する。
【００３８】
図６は、エンドユーザによるインテリジェント・ネットワークベース・Ｅコマース・システムの操作を表した流れ図である。本例の目的のため、エンドユーザがインターネット１１８を介してＥコマース・システムにアクセスしていると想定している。別法として、当然のことながら、エンドユーザはワイヤレス・デバイス／ネットワークを介して当該システムにアクセスすることも可能である。
【００３９】
工程６０２において、エンドユーザは、オンライン業者からのオンライン購入を開始させる際に適当であるようなクリック操作（たとえば、Ｗｅｂページのアイコン上）やキー操作を実行する。工程６０４において、クライアント・アプリケーション（すなわち、Ｅコマース・ソフトウェア）はユーザＩＤ、業者ＩＤ、課金額その他など当該の購入に関する情報を収集する。クライアント・アプリケーションは業者または複数の業者にサービス提供している集中型主体により運用されているサーバ内に常駐させることができる。工程６０６において、クライアント・アプリケーションはこの関連情報を含むクエリーをゲートウェイ・サーバ１０４に送信する。一実施形態では、そのクエリーはＸＭＬ形式をしている。
【００４０】
工程６０８において、ゲートウェイ・サーバ１０４は、要求を経由させようとする１次および／または２次ＳＣＰ（複数のこともある）の特定が可能であるか否かを判定する。可能でない場合は、ゲートウェイ・サーバ１０４は工程６１０において、図２、３に関連してすでに記載したのと実質的に同様にしてＳＭＳ１２４にクエリーを出す。ゲートウェイ・サーバが１次および／または２次ＳＣＰを首尾よく特定できる場合は、ゲートウェイ・サーバ工程６１２において、直接の借り方処理要求メッセージを指定されたＳＣＰ（複数のこともある）に送信する。一実施形態では、その借り方処理要求はＡＰＩ形式をしていると共に、加入者ＩＤ、口座コード、トランザクションＩＤ、メッセージ種別（すなわち、借り方処理要求）、口座インジケータ、借り方処理額および通貨インジケータなどのパラメータを含んでいる。
【００４１】
工程６１４において、運用ＳＣＰは加入者口座の有効性判定を試みる。一実施形態では、この判定には、図４に関連して記載したのと実質的に同様に、残高が十分であることおよび当該口座が実施可能ステータスであることのチェックが含まれる。口座が有効でない場合は、ＳＣＰは工程６１８においてゲートウェイ・サーバにエラーメッセージを返す。ゲートウェイ・サーバは、工程６２０においてこのエラーメッセージをクライアントに転送し、またクライアントは工程６２４においてエンドユーザからの購入要求を拒絶する。
【００４２】
口座が有効であれば、ＳＣＰは工程６１６において業者ＩＤの有効性判定を試みる。この業者ＩＤが有効でない場合、ＳＣＰは工程６１８においてゲートウェイ・サーバにエラーメッセージを返す。ゲートウェイ・サーバは工程６２０においてこのエラーメッセージをクライアントに転送し、またクライアントは工程６２４においてエンドユーザからの購入要求を拒絶する。上記以外の場合で業者ＩＤが有効であれば、ＳＣＰは、工程６２６において当該加入者口座の借り方処理を行ってそのトランザクションを呼詳細記録（ＣＤＲ）に記録し、さらに工程６２８においてゲートウェイ・サーバに肯定応答メッセージを送信する。ゲートウェイ・サーバは工程６３０においてこの肯定応答をクライアントに転送し、またクライアントは工程６３２においてエンドユーザによる購入を確認する（すなわち、販売が完了する）。
【００４３】
工程６２６において、業者への支払いを実施するため、ＳＣＰは業者の銀行（すなわち、Ｅコマース・サービス・プロバイダの銀行）に対して、業者の銀行に対して（別法としては、業者自身に対して）課金額を支払うように指令するメッセージを送信する。こうした支払いは一般に、銀行業務のトランザクションでは慣例であるように、トランザクションの完了後しばらくして（たとえば、業務の終了時点で）行われる。
【００４４】
本発明は、本発明の精神や本質的特徴を逸脱することなく、別の具体的な形式で具現化することができる。記載した実施形態はそのすべての点で例示としてのみ見なすべきであり、限定と見なすべきではない。したがって、本発明の適用範囲は、上記の記載によってではなく、添付の特許請求の範囲によって指示されている。本特許請求の範囲の意味内および等価範囲内に属するようなすべての変更はその適用範囲内に包含させるべきものである。
【図面の簡単な説明】
【００４５】
【図１】本発明による前払いサービス提供を組み込んだインテリジェント・ネットワークベース・Ｅコマース・システムのブロック図である。
【図２】インテリジェント・ネットワークベース電子商取引システムの前払い加入者口座を認証するための方法の流れ図である。
【図３】インテリジェント・ネットワークベース電子商取引システムにおいて前払い加入者口座の残高要求のための方法の流れ図である。
【図４】インテリジェント・ネットワークベース電子商取引システムにおいて加入者口座に対する借り方処理要求のための方法の流れ図である。
【図５】インテリジェント・ネットワークベース電子商取引システムにおいて加入者口座に対する直接の貸し方処理要求のための方法の流れ図である。
【図６】エンドユーザによるインテリジェント・ネットワークベース・Ｅコマース・システムの操作を表した流れ図である。
【図１】
2004164598.tif 000003
【図２】
2004164598.tif 000004
【図３】
2004164598.tif 000005
【図４】
2004164598.tif 000006
【図５】
2004164598.tif 000007
【図６】
2004164598.tif 000008