JP2005190481A - 閾値方式の課金（ｂｉｌｌ） - Google Patents

Abstract

【課題】 購入体験を促進するシステムおよび方法を提供すること。
【解決手段】 本発明は、部分的には、購入量または課金額が閾値レベルに達するまで、任意数の購入とその個々の課金額をまとめる。閾値レベルは、部分的には、使用される（消費または購入される）リソース、またはそれに対応する金銭価値に基づくことができる。閾値レベルは、少なくとも部分的には、購入されるリソースのタイプ、一回に、またはある期間に購入されるリソースの量、顧客の支払い履歴、顧客の使用量の履歴、顧客の支払い業者から受け取られるフィードバック、支払い手段のタイプ、（クレジットカード、記憶された値のカードなど）、購入の時間などのいくつかの要素に基づいて決定することができる。閾値に達すると、非同期に支払いが要求される。要求される時間内に支払いを確保することができない場合は、顧客のアカウントを一時停止するか、解約することができる。
【選択図】 図１

Description

本発明は、オンライン購入を容易にするシステムおよび方法に関し、詳細には、動的に決定される閾値に部分的に基づいて顧客に課金することに関する。

インターネットのような世界規模の通信ネットワークの出現により、莫大な数の潜在顧客に接触する商業的機会が得られるようになった。具体的には、オンラインの小売の売り上げが増していることから明らかなように、オンラインでの買い物と購入が増加している。音楽からグリーティングカード、食料品に至るまで、利便性、品揃え、オンラインのみで提供される価格設定の誘引などの様々な理由で、インターネット上の小売業者から買い物をする消費者が増えている。

しかし、オンラインショッピング体験には、障害と問題がない訳ではない。例えば、購入のプロセスは、特に少数の商品を比較的小額で買いたいだけの場合には、長く、困難である場合がある。これは一般に品目単位の購入（ｐｅｒ−ｉｔｅｍ ｐｕｒｃｈａｓｉｎｇ）と呼ばれ、現在用いられる一般的な方式である。この一例は、通例は比較的安価な（２ドルなど）のオンラインのグリーティングカードの購入である。購入プロセスに時間がかかる割に商品が小額であることが、現在の顧客および／またはリピート顧客にとって購買意欲の妨げとなる可能性がある。

品目単位の課金方式に代わる方法として、一部のオンライン小売業者は時間単位の課金を実施しており、この場合、顧客は、例えば月に一度または日に一度課金される。しかし、このタイプの課金には別の問題が伴う。例えば、日に一度あるいは月に一度しか顧客に課金しないと、顧客が「購入」した商品の代金を支払えないことが判明する前に、顧客が歌などのいくつかの製品を購入あるいはダウンロードできる可能性がある。そのため、小売業者にとっては不払いおよび／または負債の危険性が著しく増す。さらに、消費者と小売業者双方の観点からオンライン購入を改良するという、満たされていない必要性がある。

以下に、本発明のいくつかの態様の基本的な理解を提供するために本発明の簡略化した要約を提供する。この要約は、本発明の広範囲にわたる概要ではない。この要約は、本発明の主要／不可欠な要素を明らかにするものでも、本発明の範囲を詳細に述べるものでもない。その唯一の目的は、その後に提供するより詳細な説明の前置きとして、簡略化した形態で本発明の態様のいくつかを提示することである。

本発明は、顧客が、独立した売買ごとの課金プロセスによって妨げられることなく、ある期間にわたって複数の商品および／またはサービスを購入する（商品をダウンロードする、オンライン料金のサービスを利用するなど）ことを可能にするシステムおよび方法を提供する。より詳細には、本発明は、個々のユーザまたは顧客に対応する任意数のパラメータに少なくとも部分的に基づく閾値リソースレベルを用いる。ユーザ単位の料金は基本的にまとめられ、課金額の閾値に達するまで待ち行列（ローカルまたは非ローカルの）または無制限バッファ（ｕｎｒｅｓｔｒｉｃｔｅｄ ｂｕｆｆｅｒ）に記憶され、閾値に達した時点で顧客の課金手段（ｐａｙｍｅｎｔ ｉｎｓｔｒｕｍｅｎｔ）から代金が引き落とされるか、課金手段に代金が課金される。さらに、本発明は、特定の閾値またはレベルに達した時に、無制限バッファから、指定された支払い手段に非同期に課金することに対応する。

閾値は、部分的には、ユーザの嗜好および／または小売業者システムの嗜好、商品またはサービスのタイプ、単位の数量、履歴データ、支払い手段、および／または「購入」あるいはダウンロードの時間、その他多数の要素の組合せによって決定することができる。一例では、小売ユーザは、１１月や１２月など買い物が盛んなシーズン中はリスクの量を増し、その他の時期にはより無難な制限を設定することを望む場合がある。別の例では、時期と、特定の顧客の購入と支払いの履歴とを組み合わせた結果、支払いの履歴があまり好ましくない別の顧客に比べて閾値がより高くなる場合がある。

本発明の一態様によれば、閾値は、特定の小売ユーザに応じて動的に変動することが可能である。顧客の支払い履歴と信用度を利用することに加えて、支払いのタイプ、商品／サービスのタイプ、商品の数量などの他の要素が、ユーザ単位で決定される閾値と、その特定の閾値の存続時間に影響することができる。例えば、閾値は有効な日の範囲を有することができ、必要とされるか、要求される場合には、その有効範囲の最後に、関連パラメータの再評価に基づいて閾値を評価し直し、調整する。

別の態様では、顧客は、さらに、例えば商品のタイプに基づいて閾値の内訳（ｓｕｂ−ｔｈｒｅｓｈｏｌｄ）を定義することが可能であってよい。例として、ある商店が、食料品、衣料品、電子機器、書籍、音楽などの様々な商品を販売するとする。また、その商店により特定の顧客に対して１００ドルの閾値が設定され、１００ドル分の購入が行われると直ちに顧客に代金が請求され、１００ドルの支払いが行われるまではそれ以上購入をすることができない。閾値が１００ドルに設定されるとすると、顧客はさらに、商店により販売のために提供される商品のタイプ間で閾値の割り当てを定義することができる。例えば、食料品でない商品に３０ドルの閾値を設定することができ、すなわち１００ドルの閾値のうち３０ドルを食料品以外の商品に使うことができる。あるいは、閾値の内訳は比率に基づいてもよく、これは、閾値は変動する可能性があるので有用である。例えば、顧客は、閾値の３０％を食料品でない商品、より具体的には音楽に使用できると定めることができる。

閾値は、金銭価値またはリソース価値を指すことができ、リソース価値は、価値を評定してもしなくともよい、商品の消費可能な単位、ダウンロード可能なオブジェクト、または使用量に対応することを理解されたい。また、購入可能商品（リソースの使用）は、売り物またはイベントとして作成されることができ、その代価は、使用される各リソースの価値に基づくことができる。リソース使用量は、コンポーネントによって記録し、後の時間にそのリソース使用量を金銭価値に変換することができる。したがって、一態様では、顧客による「購入」時に金銭価値に関連付けられるように、イベントは、価値を評定する（ｒａｔｅ）、またはあらかじめ価値評定することができる。あるいは、各「購入」イベントに関連付けられた金銭価値は、課金時（クレジットカードへの課金、または支払い業者から要求される支払い）にリソース使用量または購入に割り当てる、または付加することもできる。

閾値に達すると、顧客によって指定された支払い手段から代金を引き落とすか、支払い手段に代金を課金することができる。しかし、顧客または顧客の支払い業者によって支払いを行うことができない場合は、様々な処置をとることができる。例えば、要求される支払いが行われるまでその後の購入の試みを拒絶することができる。さらに、支払いを獲得するために複数回の試行が必要とされた場合は、購入能力が再開する際に閾値を下げることができる。特定の顧客に周期的に警告メッセージを送信して、顧客のアカウントのステータスと、支払いをしなかった場合または支払いが遅れた場合に起こりうる結果を通告することもできる。

本発明のさらに別の態様によれば、サービスの一時停止を回避するために、閾値に近づいていることをユーザに知らせ、閾値に達する前に支払いを要求することが必要とされる場合がある。これは、ユーザのアカウントを決済するために用いられる特定の支払い手段に応じて適用することができる（一部の国で利用される口座引き落としや日本のプッシュ支払いなど）。この結果、通知の閾値や一時停止の閾値などの他の閾値を（課金額の閾値に加えて）利用することができる。通知の閾値は、課金額の閾値より小さい量（通貨、ポイント、および／または単位に換算して）に対応することができ、それにより、ユーザは、課金の閾値に達するか、閾値を超える前に自身のアカウントを決済するよう指示する通知を受け取ることができる。同様に、一時停止の閾値は、通知の閾値および／または課金の閾値より大きい量（通貨、ポイント、および／または単位に換算して）に対応することができ、それにより、一時停止の量に達すると直ちにユーザアカウントを一時停止することができる。

上述の目的およびそれに関連する目的を達成するために、本発明の特定の例示的態様を以下の説明と添付図面との関連で記載した。しかし、これらの態様は、本発明の原理を用いることが可能な各種方式の数例を示すに過ぎず、本発明は、そのような態様とその均等物をすべて包含するものとする。本発明の他の利点と新規の特徴は、添付図面と併せて以下の本発明の詳細な説明を検討することから明らかになろう。

次いで、図面を参照して本発明を説明するが、すべての図面を通じて同様の要素は同様の参照符号を使用して参照する。以下の説明では、説明のために、本発明の完全な理解を提供するために多数の具体的な詳細事項を述べる。しかし、本発明はそれらの具体的な詳細を用いずに実施することが可能であることは明らかであろう。他の例では、本発明の説明を助けるために、周知の構造およびデバイスはブロック図の形態で示す。

本願で使用される用語「コンポーネント」および「システム」は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、あるいは実行中のソフトウェアを問わず、コンピュータに関連するエンティティを指すものとする。例えば、コンポーネントは、これらに限定しないが、プロセッサで実行されるプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータ等である。具体例として、サーバで実行されるアプリケーションとサーバの両方がコンポーネントとなることができる。プロセスおよび／または実行のスレッド中に１つまたは複数のコンポーネントが存在することができ、またコンポーネントは１台のコンピュータに局所化されても、かつ／または２台以上のコンピュータに分散されてもよい。

本発明は、顧客（例えばユーザ）単位などで閾値を自動的に決定することに関連して、様々な推論（ｉｎｆｅｒｅｎｃｅ）の方式および／または技術を取り入れることができる。本発明で使用する用語「推論」とは、一般に、イベントおよび／またはデータを介して捉えられた観測結果のセットから、システム、環境、および／またはユーザの状態を推測あるいは推論するプロセスを言う。推論を用いて、例えば、特定のコンテクストあるいは動作を識別する、あるいは複数の状態にわたる確率分布を生成することができる。推論は確率的、すなわち、データおよびイベントの考慮に基づく、対象の複数の状態にわたる確率分布の計算とすることができる。推論は、イベントおよび／またはデータのセットからより高レベルのイベントを構成するために用いられる技術も指すことができる。そのような推論の結果、観測されたイベントおよび／または記憶されたイベントデータのセットから新しいイベントまたはアクションが構築され、それらのイベントは時間的に近接して相関関係があってもなくとも、また、イベントおよびデータは、１つのイベントおよびデータの供給源から得ても、いくつかの供給源から得てもよい。

本発明は、どのような種類のオンラインサービス提供者、業者、小売業者、ベンダエンティティによっても利用し、実施できることを理解されたい。また、本発明で用いられる用語「顧客」は、購入あるいはダウンロードのための代金または料金を支払うことを条件として、任意の商品を購入および／またはダウンロードすることを望む任意の個人またはエンティティを指すことができる。

本発明は、オンラインの商店またはサービス提供業者が、顧客が、ある設定された価値の商品を購入した時に、顧客の支払い手段（例えば銀行口座、クレジットカード、デビットカード、クレジット残高、または商店用のユーザアカウント）に課金する（引き落としまたは請求）ことを可能にするシステムおよび方法を提供する。設定された価値の商品は、閾値リソース価値に相当する。例えば、設定された価値の商品、すなわち閾値は、１０ドル分の商品またはサービスとすることができる。したがって、顧客が、１回のイベント（売買）または何回かのイベント（イベントを蓄積する場合）で少なくとも１０ドル分の商品またはサービスを購入すると、指定される支払い手段に課金してその商店との勘定を決済する。あるいは、リソース価値は、分、ポイント、単位などの消費可能な単位に相当することもできる。さらに、イベントは、対応する閾値リソース価値に達するまで任意の期間にわたって記憶または追跡することができ、閾値リソース価値に達した時に、それらのイベントに対する支払いが必要とされ、要求される。

このシナリオを図１に概略的に示す。図１は、本発明の一態様による閾値課金システム１００の高レベルブロック図である。詳細には、購入エンティティ１１０（顧客、買い手など）は、オンライン販売者またはサービス提供者１２０とインターフェースをとる、かつ／または通信する。オンライン販売者１２０により購入エンティティ１１０から受信される通信をイベント識別および追跡コンポーネント１３０によって分析して、購入エンティティ１１０からの通信がイベントを構成するかどうかを判定する。イベントとは、何らかのリソース（例えば商品やサービス）の購入あるいはダウンロードを指す。

１回目のイベントが閾値リソース価値に達しないと想定すると、１回目のイベントに加えてその後のイベント（２回目のイベント、３回目のイベント等）をイベント識別および追跡コンポーネント１３０によって追跡し、合計することができる。イベントが閾値リソース価値に達する（あるいは超える）と、直ちに、購入エンティティの支払い手段に課金するようにデビットコンポーネント１４０に指示することができる。適切な支払い手段の例には、クレジットカード、銀行口座（引き落とし）、およびデビットカードが含まれる。あるいは、特定のオンライン販売者１２０との間にクレジット残高（ｃｒｅｄｉｔ ａｃｃｏｕｎｔ）（商店との間で記憶された値のクレジット）を維持し、課金される金額がそのクレジット残高から引かれるようにすることもできる。

支払いは、閾値リソース価値が金銭価値に相当しても、消費可能な単位に相当しても、少なくとも閾値リソース価値について要求されることを理解されたい。例えば、閾値リソース価値が金銭価値（２０ドルなど）に相当する場合には、少なくともその金額が直ちに支払われるように顧客に課金される。しかし、閾値リソース価値に達し、閾値を上回ると（例えば一番最近のイベントで閾値リソース価値が１５ドルから３５ドルになり、閾値が２０ドルの場合）、総計の残高（３５ドル）を顧客に課金して支払うべき残高を０ドルにすることができる。あるいは、販売者の裁量で、閾値に相当する額だけを直ちに支払うことを要求してもよい。要求される支払いが販売者１２０に受領されると、購入エンティティ１１０と販売者１２０の間で（購入の）イベントを再開することができる。

次いで図２を参照すると、本発明の一態様によるオンラインデビットシステム２００を示す。このシステムは、１人または複数の顧客２１０との対話を伴い、それにより、１人または複数の顧客から例えばイベントの形で入力を受け取ることができる。イベントとは、閾値方式の課金（少なくとも閾値などのいくらかの額を直ちに支払う）を条件としてもしなくともよい顧客またはエンティティによる、購入の取引または購入を行う試み（ダウンロードなど）を指すことができる。

イベント検出コンポーネント２２０は、顧客２１０からの入力を受け取り、その入力が閾値課金方式の対象となるイベントを構成するかどうかを検出する。イベントは、例えば購入されるオブジェクト（例えばリソース使用）を備えることができる。入力がイベントと識別あるいは認識される場合は、リソース使用量レコーダ２３０が、そのような個々のリソースの使用量を記録することができる。例えば、リソースに金銭価値が割り当てられている場合は、対応するリソースの値は、閾値リソース価値を基準として「使用された」と記録することができる。すなわち、２度のイベントで使用されたリソースの値が５ドルと記録され、閾値リソース価値が２５ドルである場合、顧客は、少なくとも２５ドルの支払いがオンライン商店から要求される前に２０ドル分のリソースを購入できることになる。これは、閾値に達する前にさらにイベントが顧客によって開始される可能性があることを意味する。イベントが蓄積されていくと、それらのイベントを非ローカルの待ち行列２４０（例えば無制限バッファ）に記憶して、システムの拡張性と信頼性をさらに向上することができる。

あるいは、リソースが時間やポイントなどの消費可能な単位に関連する場合は、閾値リソース価値に達するまで、現時点まで使用されたリソースを記録し、蓄積することができる。例えば、使用されたリソースが時間数を指し、閾値リソース価値が５０時間であり、この閾値に達すると顧客に２５ドルが課金されるものとする。したがって、最初のイベントと２回目のイベントで合わせて１２時間（それぞれ４時間と８時間）が追加される場合、顧客は、２５ドルを課金される前にまだ３８時間（すなわちリソース）を「購入」あるいは利用することができる。

リソースプロセッサ／アナライザ２５０は、無制限バッファ２４０の内容を分析（合計）することにより、閾値リソース価値に達したか、かつ／または値を超えたかどうかを判定することができる。閾値が満たされていない場合、イベント検出コンポーネント２２０は、顧客２１０によって行われるその後のイベントを引き続き検出および／または識別することができる。しかし、閾値が満たされている場合、デビット要求コンポーネント２６０に指示して、無制限バッファ２４０の合計購入額の少なくとも一部を顧客に非同期に課金させることができる。

この時、あるいはこの時の前後に、顧客のアカウント（リソースアカウントあるいはユーザアカウント）を何らかの値に再初期化あるいはリセットして、使用されたリソース（ダウンロードあるいは購入されたオブジェクト等）の少なくとも一部分について支払いが要求されていることを示すことができる。一部の例では、この値をゼロにすることができ、これは全リソース使用量についての即時の支払いが要求される場合に行われる。しかし、他の例では、この値は、最初のリソース使用が無料である場合（例えば最初の１０分間が無料、あるいは最初の５ドル分の購入が無料となる場合）などに、負の値にすることができる。任意で、この値を正の非ゼロの数にして、合計請求額の一部についてのみ支払いが要求され、したがって残りの分は現在の閾値未満であることを表すことができる。この場合、残高はなおオンライン商店に支払わなければならず、次に閾値に達した時に回収することができる。

例えば、閾値リソース価値が５０ドルであるとする。顧客が１回または複数回の購入で合計５０ドルを使用すると、顧客の支払い業者に５０ドルが課金される。したがって、５０ドルの支払いが支払い手段に課金されると、顧客のアカウントは０ドルにすることができる。あるいは、顧客のアカウントを−５ドルにして、そのリソースの最初の５ドル分が無料であることを表すことができる。最後に、顧客のアカウントを２５ドルなど５０ドル以下の額に減らして、２５ドルの支払いが課金された結果、顧客が５０ドルの閾値額以下になったことを表すことができる。したがって、顧客には、５０ドルの閾値に再び達するまで買い物を続けることを許可することができる。任意で、顧客の購入額が合計６５ドルになり（例えば購入合計額が４５ドルから６５ドルに増えた）、閾値が５０ドルである場合には、少なくとも５０ドルの支払いを要求することができ（支払いが要求される額が閾値に相当する）、したがって再び閾値に達するまでアカウント（データベース）に１５ドルを残しておいてもよい。

デビット要求コンポーネントに通知する際に、非同期の料金要求をメッセージ処理施設（ＭＰＦ（ｍｅｓｓａｇｅ ｐｒｏｃｅｓｓｉｎｇ ｆａｃｉｌｉｔｙ））システム２７０の待ち行列に入れることができ、システム２７０は、例えば料金要求など比較的恣意的な動作の実行を処理することができる。ＭＰＦシステム２７０は、メッセージ待ち行列に似たものとすることができる。

別のスレッドおよび／または異なるマシンなどにあるＭＰＦシステム２７０内で、ＭＰＦシステムの一コンポーネントが、未決の課金動作を取り出し、実行すべき適切な課金コードを（例えば動的なバインディングを介して）見つけ、そしてそのコードを呼び出す。この非同期の課金コードが次いで、無制限バッファ２４０から課金記録（現時点で課金すべき合計料金または金額）を呼び出し、商店の嗜好に応じて、指定された額、または合計額の一部について、支払い業者（クレジットカード、銀行口座、記憶された値のｃｒｅｄｉｔなど）に対して決済を試みることができる。

この課金が成功した場合は、バッファ２４０（またはデータベース）に成功と記録することができる。次いで、顧客にメッセージを送信して、支払い手段に課金された、および／または支払いが行われたことを通知することができる。

ただし、課金が失敗した、あるいは拒否された場合は、バッファ２４０に拒否と記録することができ、支払いを得る再度の試みを将来の時間にスケジュールし、それをバッファ２４０に記すこともできる。支払いが失敗した場合の別の結果として、少なくとも一時的に顧客のアカウントを停止して、顧客によってそれ以上の購入またはダウンロードが行われないようにすることができる。詳細には、商店または契約サービス提供者は、別の非同期のＭＰＦ動作による支払いの失敗の通知を受け取ることができ、この通知は基本的に、顧客に対するサービスを使用不可にするようにサービス提供者に指示する。

その後の課金の試みは、日単位のバッチ方式の支払いプロセスによって行うことができる。最終的に課金が成功すると、顧客の契約サービス利用または購入の能力が再開することができる（回復されることができる）。課金が成功しない場合は、拒否が繰り返されている旨の通知を顧客に送付することができる。ある期間支払いが行われないと、顧客の契約サービスまたはアカウントを最終的に解約することができる。

さらに、本発明は、閾値に達した時に即時の支払いあるいはユーザアカウントの決済を必要とすることにより、オンライン商店および／またはサービス提供者にとっての回収不能金のリスクおよび損失を軽減する。さらに、購入をまとめることができるので、銀行やクレジットカードの決済手数料および／または間接費を最小に抑えることができる（購入をまとめることによりクレジットカードの決済回数が減り、したがってクレジットカードの手数料が減る）。同様に、決済をまとめることにより、クレジットカード明細の細目購入を減らすことができる。最後に、購入を報告するオンライン商店およびサービス提供者の呼び出しの待ち時間を増大することなく、直ちに課金を行うことができ、これは、商店の損失と回収不能金のリスクの軽減に役立つ。

上記のように、システム２００は、非同期の課金コードを利用して、課金記録の即時の決済を試みる。本発明の一態様によれば、このシステムは、バッチキューイング（ｑｕｅｕｉｎｇ ｔｏ ｂａｔｃｈ）の機構を採用するなどにより、課金をリチャンネル（ｒｅ−ｃｈａｎｎｅｌ）することもできる。例えば、システムに特定のフラグが設定されている場合、非同期の課金コードは、そのアカウントの即時の決済を要求しない。代わりに、記録された課金は、商店またはサービス提供者の嗜好（例えば呼び出し元の嗜好）に従って、一日以内などに通常のバッチ方式の支払い処理を介して決済することができる。したがって、即時の決済のために支払い業者に連絡がとれない場合など、起こりうる問題が生じた場合には、閾値課金の即時の決済を解除することができる。

商店が顧客の課金を決済できる他の選択肢には、同期した処理、または即時の処理、および／またはバッチ方式の処理（他の課金と併せて）が挙げられる。商店は例えば、顧客のプロファイル、販売製品、販売元のテナントなどに応じて、可能性としては上記の選択肢のどれを選択してもよい。

蓄積された課金が特定の期間（３０日など）内に閾値に達しない場合は、サービス提供者または商店は、例えば月単位で顧客に課金することに戻ることができる。

次いで図３に、閾値リソース価値３００の決定に影響を与えうるいくつかの例示的な要素の模式図を示す。例えば、顧客によって使用または購入されるリソースのタイプ（リソースタイプ３１０）と、そのリソースの使用量（リソース量３２０）が、閾値３００の設定に影響することができる。例えば歌は、顧客によって「使用」できる（例えばダウンロードされる）タイプのリソースである。ダウンロード可能な歌は、一曲当たり比較的低価格である可能性がある。加えて、そうした歌は、１人の顧客により比較的大量にダウンロードされる可能性がある。したがって、閾値は、支払いが要求されるまでに（１回のイベントにつき）何回でもダウンロードできる複数回のイベントを許可できるような高さに設定してよい。

逆に、リソースタイプが自動車など高価格商品に対応する場合は、閾値は、支払いが要求される前に顧客が少なくとも１台の自動車を購入できるが、２台の車は購入できないように設定することができる（商店は、顧客が一度に一台のみの車を購入し、その代金を支払えるようにしたい場合がある）。この特定の事例では、量は、支払い手段３３０（クレジットカードと、記憶された値のアカウント）、支払い業者からのフィードバック３４０（例えば顧客が銀行やクレジットカードについて良好な信用格付けあるいは履歴を有するなど）、および／または顧客の過去の使用量、および／または商店あるいはサービス提供者との履歴３５０（顧客と商店との関係など）といった他のパラメータが考慮されない場合に、商店によって考慮される要素とする場合もしない場合もある。例えば、支払い手段が記憶された値のアカウントであり、すなわち顧客が商店との間にｃｒｅｄｉｔを有する場合は、閾値を高く設定してよい。しかし、支払い手段がクレジットカードであり、銀行から（商店へのフィードバックを通じて）例えば顧客が最近４回の支払い請求サイクルにおいて２度の支払いの遅れがあったことが通知された場合は、閾値を低く設定することができる。

さらに、低価格商品の閾値は、閾値に達する前に顧客が数個の商品をダウンロードあるいは購入できるように高く設定し、これに対し、高価格商品の閾値は、支払いが要求されるまでに１つまたは２つの商品を購入できるように高く設定することができる。したがって、閾値は、商店３６０間、ならびに１つの商店によって提供されるリソースのタイプ３１０間で変えることができる。一部の商店あるいはサービス提供者は、複数の商品およびサービスを提供することができるので、閾値は、顧客の現在の契約サービスの利用または現在のリソースの使用量に部分的に基づいても変動することができる。例えば、商品Ｗに１００ドルの閾値を有する顧客が、商店ＲからサービスＫを購入することも希望するとする。商店Ｒは、顧客がすでに製品Ｗについて有する比較的高い閾値に基づいて、顧客のサービスＫについての閾値を高く設定することができる。逆に、製品Ｗに１０ドルの閾値リソース価値しか持たない顧客は、サービスＫに上述の顧客のような高い閾値（１００ドル等）を受け取ることはできない。したがって、顧客の背景状況を分析して、適切な閾値リソース価値の決定を助ける。

最後に、時間３７０を、商店およびサービス提供者によって用いられる追加的パラメータとすることができる。例えば、一部の商店およびサービス提供者は、一般的な休暇のある月（１１月や１２月）のような買い物が盛んなシーズン中には、他の時期と比較してリスクを恐れない場合がある。その結果、それらの月には閾値を他の月より高く設定してよい。これに対し、商店は、１月や２月など買い物が盛んなシーズンの後の月にはよりリスクを回避しようとする場合がある。したがって、その時期には閾値を低めに設定することができる。

これに代えて、あるいはこれに加えて、月の初め（給料をもらう）には高めに、月末（請求の支払いをした後で残金が少ない）には低めにするなど、顧客の給与期間と一致するように閾値を設定することもできる。

閾値リソース価値を決定する際には上記に加えて他のパラメータを用いてよいことは理解されたい。また、パラメータのうち任意の１つあるいは組合せを利用して現在の閾値を決定することができることも理解されたい。

次いで本発明による各種の方法論について一連の動作を通じて説明する。本発明は、動作の順序によって制限されず、一部の動作は、本発明により、図に示し、ここで説明する順序とは異なる順序で、かつ／または他の動作と同時の行うことができることを理解および認識されたい。例えば、当業者は、ある方法論は、代わりに、状態図などとして相互に関連する状態あるいは事象の連続として表すことができることを理解および認識されよう。さらに、ここで説明する動作のすべてが本発明による方法論を実施するのに必須とは限らない。

次いで図４に、リソース使用量の統合を容易にしてオンライン課金方式を改良する例示的方法４００の流れ図を示す。本発明によれば、商品あるいはサービスの購入および／またはダウンロードなどのイベントに関連する入力（イベントデータ）が、例えば顧客から提出される。符号４１０で、イベントデータを処理および／または分析することにより、リソース使用量が検出および／または判定（識別および／または定量化）される。符号４２０で、リソース使用量をリソースタイプに関連付ける。符号４３０で、そのリソースタイプが閾値リソース価値の対象となるかどうかを判定することができる。すなわち、すべてのリソースタイプが閾値課金方式（閾値に達すると直ちに支払いが要求される）の対象となる訳ではなく、これは商店の嗜好によって決定される。

例えば、一部のオンライン小売業者は、特定の商品あるいはサービスについては商品単位で即時の支払いを要求することができ、一方、他の商品については、顧客が実際に購入の代金を課金されるまである期間にわたって購入をまとめられるように閾値課金の制限が設定される。同様に、一部の小売業者は、一部の商品あるいはサービスについては月単位の課金を維持することを望む。例えば、オンライン新聞は、新聞へのアクセスおよび／または新聞にログオンした状態で費やす時間が一月当たり無制限なので、月単位で顧客に課金する方がよい場合がある。したがって、任意の一カ月における複数回のログオンをリソース使用量の換算（例えばログオン回数、ログオンした状態で消費された分数）に変換することができるが、このシナリオでは、関連付けられたリソースタイプのケースは、閾値リソース価値の対象とならない。

図５〜７に、リソースの使用量を識別および追跡し、現在の使用量を過去の使用量と関係付け、閾値に達した時に合計の使用リソース量を顧客に課金することを容易にする例示的プロセスを示す一連の流れ図を示す。ある料金で顧客によって使用されるオブジェクト、商品、あるいはサービスをいずれもリソースとみなすことができる。したがって、リソースの使用量とは、特定リソースの使用量を指し、そのような使用量は、課金の目的で金銭価値に変換することができる。一部のリソースは、顧客が入手できる状態にする際に価値を評定する（金銭価値あるいは消費可能な単位の値を割り当てる）ことができる。逆に、他のリソースは、顧客が使用または消費できる状態にする際に価値が評定されなくてよい。この場合、評定されないリソースの価値は、閾値リソース価値に達した時に決定または公表することができる。

次いで図５に、本発明の一態様により顧客によるリソース使用量を識別および追跡することを容易にする方法５００の流れ図を示す。方法５００は、符号５１０で、リソース使用量が、リソース使用量の統合と閾値課金の対象となることを判定することを伴う。符号５２０で、リソースの使用量を、個々の顧客のリソース残高に記録することができる。符号５３０で、リソース残高を読み出し、次いで価値を評定または変換してリソース残高の合計値を計算することができる。例えば、リソース残高の金銭価値を確定することができる。符号５４０で、方法５００は、リソース残高の合計値（金銭価値あるいは消費可能な単位の値）が少なくとも閾値リソース価値に達しているかどうかを判定して、（リソース残高の合計値についての）顧客への課金を認可することができる。

これに代えて、またはこれに加えて、ユーザのリソース残高が設定範囲内の閾値リソース価値に近づいていることを通知コンポーネントによってユーザに通知することもできる。例えば、方法５００は、ユーザが、そのユーザの特定の閾値リソース価値または残高のＱ単位内に入った時にユーザに通知を送るようにプログラムすることができる。この場合は、実際に閾値リソース価値に達する前に支払いまたはユーザのアカウントの決済を要求することができる。これは、口座引き落としあるいはプッシュ支払い（例えば日本）で支払いをするユーザに適用することができる。

図５で合計値が閾値リソース価値に到達すると想定すると、方法６００がそこから続いて、「購入」されたがまだ代金が支払われていないリソースの決済あるいは支払いを実施することができる。方法６００は、「購入」されたリソースの記憶と統合のための領域としても機能する非ローカルキューまたは無制限バッファなどのデータベースに、引き落としまたは代金の合計額を書き込むことを含む（符号６１０）。このデータベースは、購入の合計が少なくとも閾値リソース価値に達したと判定されるまで、そのような購入の貯蔵場所（ｔａｎｋ）として機能することができる。

符号６２０で、（リソース残高が閾値リソース価値を下回る程度まで）顧客のアカウントの少なくとも部分的な決済を実施するために、非同期の引き落としまたは課金要求をＭＰＦシステムの待ち行列に入れることができる。ＭＰＦシステムによって行うことのできるさらなる動作については図７および以下で述べる。符号６３０で、顧客のリソースアカウントを例えばゼロなどの何らかの値にリセットして、それ以前のリソースの使用または購入の代金が支払われており、現在は顧客によって「購入」されたリソースがなく、または閾値リソース価値に向かって蓄積されているリソースがないことを示すことができる。

符号６４０で、例えば顧客のリソース使用がデータベースに記録された旨のメッセージを商店あるいはサービス提供者（呼び出し元）に送信することができる。商店あるいはサービス提供者の嗜好に応じて、顧客のリソースアカウントは、支払いが確認されるまで一時停止しておくことができる。あるいは、一部の商店は、一部の良好な顧客が、支払いが検証され確認されるまではより少ない量のリソースを利用できるようにする。良好な顧客とは、例えば、それまで支払いが遅れたことがなく、あったとしても課金の不履行がほとんどない顧客等である。

次いで図７に、本発明の一態様による課金要求を処理する例示的方法７００の流れ図を示す。課金要求は、閾値リソース価値に達すると直ちに行うことができることを思い出されたい（図６、上記参照）。この方法は符号７１０で開始することができ、ここで個々のデータベースまたはバッファから未決の課金要求または動作を取り出し、実行すべき適切な課金コードを発見または特定し、そのコードを呼び出す。符号７２０で、課金記録（リソース残高）をデータベースから読み出して、指定された支払い業者に対して合計料金の少なくとも一部の決済を試みることができる。符号７３０で課金が成功した（支払いが支払い業者から確保された）場合は、それを符号７４０で個々のデータベースに成功した課金として記録することができる。支払いが行われたことを（通知コンポーネントを通じて）顧客に通知することもできる。

しかし、７３０で課金が失敗し、要求される支払いが拒否された場合は、符号７５０で個々のデータベースに拒否が記録される。符号７６０で課金を処理する再度の試行をスケジュールすることができ、課金が成功するまで顧客のアカウント（購入能力、契約サービスの利用）を一時停止することができる。アカウントの一時停止の結果、符号７７０で、購入能力あるいはサービスを少なくとも一時的に使用不可にすべきことを指示する通知を商店あるいはサービス提供者に送信することもできる。

支払いまたはユーザアカウントの決済が成功しないシナリオでは、一時停止の閾値を呼び出せることを理解されたい。例えば、一時停止の閾値は、支払いが受領されていない使用の量または値に相当することができる。これに代えて、またはこれに加えて、一時停止の閾値は、支払いが要求されたが支払い業者（クレジットカード、銀行など）によって拒否された回数に対応することもできる。

さらに、複数回の課金処理に代えて、基本的に購入および／または課金は、より少ない回数の課金処理にまとめられ、その結果、処理の間接費（クレジットカードの手数料など）と顧客の時間が軽減される。実際には、音楽のダウンロードサービスを提供する音楽ダウンロードの小売業者を想像されたい。顧客の体験を向上させるために、顧客は、毎回の購入の最後に課金プロセスによって妨げられることなく歌を購入し、ダウンロードすることができる。例えば、従来のシナリオでは、支払い処理には、１つまたは２つの追加的なウェブページが必要とされ、顧客のクレジットカードに課金するために数秒間を要する場合がある。現時点で数曲の歌を購入し、一時間後にもう数曲を購入し、２０分後にさらに多くの歌を購入し、次の日にさらに歌を購入するために繰返し利用する顧客にとって、購入のたびに単調で面倒な支払いプロセスを行うことは、冗長で時間を要する。単に蓄積された購入について日単位あるいは月単位で課金することは、顧客がダウンロードした歌の代金を支払えないことを小売業者が知る前に顧客が大量の歌をダウンロードできる可能性があるため、余りにも危険性が高い。この点で、さらなるサービスの使用を不可にすることは、必ずしも回収不能金の危険性と経済的損失を軽減しない。さらに、ダウンロードされた商品の場合には、顧客はすでにその購入の恩恵を受け取っており、そのような商品を回収することは不可能に近いと言ってよい。

しかし、本発明によれば、少なくとも閾値のレベルまで回収不能金の危険性と潜在的な経済的損失を軽減することができる。本発明は、非同期の課金機構を採用するので、購入を報告し、記録する商店／小売業者（呼び出し元エンティティ）の呼び出しの待ち時間を増大させることなく、個々の閾値に達するといつでも例えば顧客のクレジットカードに課金することができる。

再度上記の音楽サービスの例に戻ると、この例では一人の顧客により多量の歌が購入され、ダウンロードされる可能性があるが、本発明は、無制限バッファを利用して、閾値に達するまで、多量である可能性のある購入に、購入の統合を介して対処し、それらの購入を以前にまとめられた購入と関係付ける。閾値に達すると、その特定の閾値の値に関係なく、直ちに顧客に非同期に課金することができる。

閾値は、リソースの使用量（顧客によって使用、購入、あるいは消費されたリソースの量など）に相当することができ、それにより顧客のリソース使用量が記録される。リソース使用量の閾値に達すると、式を使用してリソース使用量を金銭価値に変換し、その額を顧客の支払い業者に課金する。このシナリオでは、（売り物あるいはイベントの形で提示される）リソースは、直接金銭価値には関連付けられない（あらかじめ価値が評定されない）。あるいは、閾値は、直接金銭相当値に関連してもよい。例えば、閾値を２５ドルに設定し、顧客がリソースに２５ドルまで使用すると、２５ドルの即時の支払いが要求されるようにすることができる。この場合、リソースは事前に価値が評定されるか、顧客に提示される時に代価に関連付けられる。

本発明は、部分的には、図８の例示的流れ図８００に概略的に示すように、ＲｅｐｏｒｔＵｓａｇｅＥｖｅｎｔの呼び出しを用いることによって実施することができる。ＲｅｐｏｒｔＵｓａｇｅＥｖｅｎｔの呼び出しは、閾値に達するまでリソース使用量を報告し、かつ／または顧客の（現在の合計の）リソース残高に記録することを助ける。従来の課金方式では、例えば顧客が月単位で請求される場合は、現在の合計リソース残高が月単位で維持される。図８の流れ図８００から分かるように、ＲｅｐｏｒｔＵｓａｇｅＥｖｅｎｔの呼び出しは、メッセージキューと同様のＭＰＦ（メッセージ処理機構）システムと関連して動作して、閾値に達すると直ちに顧客のアカウントの決済を得る。

本発明の各種態様についての追加的なコンテクストを提供するために、図９と以下の説明では、本発明の各種態様を実施することが可能な適切な動作環境９１０の簡潔で概略的な説明を提供する。本発明について、１つまたはコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との関連で説明するが、当業者は、本発明は、他のプログラムモジュールと組み合わせて、かつ／またはハードウェアとソフトウェアの組合せとして実施することもできることを認識されよう。

ただし、一般には、プログラムモジュールには、特定のタスクを行うか、特定のデータ型を実装することができるルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。動作環境９１０は、適切な動作環境の一例に過ぎず、本発明の使用または機能性の範囲について制限を示唆するものではない。本発明に使用するのに適する可能性がある他のよく知られるコンピュータシステム、環境、および／または構成には、これらに限定しないが、パーソナルコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサを利用したシステム、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスを含む分散コンピューティング環境などがある。

図９を参照すると、本発明の各種態様を実施する例示的環境９１０は、コンピュータ９１２を含む。コンピュータ９１２は、処理装置９１４、システムメモリ９１６、およびシステムバス９１８を含む。システムバス９１８は、これに限定しないがシステムメモリ９１６を含むシステムコンポーネントを処理装置９１４に結合する。処理装置９１４は、各種の利用可能なプロセッサのいずれでもよい。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも処理装置９１４として用いることができる。

システムバス９１８は、これらに限定しないが１１ビットバス、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＳＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ Ｌｏｃａｌ Ｂｕｓ）、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎバス）、およびＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）を含む各種の利用可能なバスアーキテクチャを使用した、メモリバスまたはメモリコントローラ、ペリフェラルバスまたは外部バス、および／またはローカルバスを含む数種のバス構造のいずれでもよい。

システムメモリ９１６は、揮発性メモリ９２０と不揮発性メモリ９２２を含む。起動時などにコンピュータ９１２内の要素間で情報を転送する基本ルーチンを含んだ基本入出力システム（ＢＩＯＳ）が、不揮発性メモリ９２２に記憶される。限定ではなく例示として、不揮発性メモリ９２２には、読み取り専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的にプログラム可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＲＯＭ（ＥＥＰＲＯＭ）、あるいはフラッシュメモリが含まれる。揮発性メモリ９２０には、外部キャッシュメモリとして機能するランダムアクセスメモリ（ＲＡＭ）が含まれる。限定ではなく例示として、ＲＡＭは、ＳＲＡＭ（シンクロナスＲＡＭ）、ＤＲＡＭ（ダイナミックＲＡＭ）、ＳＤＲＡＭ（シンクロナスＤＲＡＭ）、ＤＤＲ ＳＤＲＡＭ（ダブルデータレートＳＤＲＡＭ）、ＥＳＤＲＡＭ（エンハンストＳＤＲＡＭ）、ＳＬＤＲＡＭ（ＳｙｎｃｈｌｉｎｋＤＲＡＭ）、およびＤＲＲＡＭ（ダイレクトＲａｍｂｕｓＲＡＭ）など多くの形態のものを利用することができる。

コンピュータ９１２は、取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体も含む。図９には例えばディスク記憶装置９２４を図示する。ディスク記憶装置９２４には、これらに限定しないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、あるいはメモリスティックのようなデバイスが含まれる。また、ディスク記憶装置９２４は、記憶媒体を単独で、またはこれらに限定しないがＣＤ−ＲＯＭ（コンパクトディスクＲＯＭ）デバイス、ＣＤ−Ｒドライブ（ＣＤ−Ｒｅｃｏｒｄａｂｌｅドライブ）、ＣＤ−ＲＷドライブ（ＣＤ−Ｒｅｗｒｉｔａｂｌｅドライブ）、またはＤＶＤ−ＲＯＭ（デジタル揮発性ディスクＲＯＭドライブ）などの光学ディスクドライブを含む他の記憶媒体と組み合わせて含むことができる。ディスク記憶装置９２４をシステムバス９１８に容易に接続できるように、通例は取り外し可能インターフェースまたは取り外し不能インターフェースがインターフェース９２６として使用される。

図９には、ユーザと、適切な動作環境９１０に図示する基本的なコンピュータリソースとの間の仲介の役割を果たすソフトウェアを示していることが理解されよう。そのようなソフトウェアにはオペレーティングシステム９２８が含まれる。オペレーティングシステム９２８は、ディスク記憶装置９２４に記憶することができ、コンピュータシステム９１２のリソースを制御し、割り振る働きをする。システムアプリケーション９３０は、システムメモリ９１６またはディスク記憶装置９２４に記憶されたプログラムモジュール９３２およびプログラムデータ９３４を通じて、オペレーティングシステム９２８によるリソースの管理を利用する。本発明は、各種のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実施できることが理解されよう。

ユーザは、入力装置９３６を通じてコンピュータ９１２にコマンドまたは情報を入力する。入力装置９３６には、これらに限定しないが、マウス、トラックボール、スタイラス、タッチパッドなどのポインティングデバイス、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどが含まれる。これらおよび他の入力装置は、インターフェースポート９３８を介して、システムバス９１８を通じて処理装置９１４に接続する。インターフェースポート９３８には、例えばシリアルポート、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力装置９４０は、入力装置９３６と同じタイプのポートの一部を使用する。したがって、例えばＵＳＢポートを使用してコンピュータ９１２に入力を提供し、コンピュータ９１２から出力装置９４０に情報を出力することができる。モニタ、スピーカ、およびプリンタなど、出力装置９４０の中には特殊なアダプタを必要とするものがあることを示すために出力アダプタ９４２が提供される。出力アダプタ９４２には、限定ではなく例示として、出力装置９４０とシステムバス９１８間の接続手段を提供するビデオカードとサウンドカードが含まれる。リモートコンピュータ９４４など、他のデバイスおよび／またはデバイスのシステムが入力と出力両方の機能を提供することに留意されたい。

コンピュータ９１２は、リモートコンピュータ９４４などの１つまたは複数のリモートコンピュータとの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ９４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサを利用した機器、ピアデバイス、または他の一般的なネットワークノードなどであり、通例は、コンピュータ９１２に関連して記載した要素の多くまたはすべてを含む。図を簡潔にするために、リモートコンピュータ９４４にはメモリ記憶装置９４６のみを図示している。リモートコンピュータ９４４は、ネットワークインターフェース９４８を通じて論理的にコンピュータ９１２に接続され、通信接続９５０を介して物理的に接続される。ネットワークインターフェース９４８は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）などの通信ネットワークを包含する。ＬＡＮ技術には、ＦＤＤＩ（ファイバ分散データインターフェース）、ＣＤＤＩ（銅線分散データインターフェース）、Ｅｔｈｅｒｎｅｔ（登録商標）／ＩＥＥＥ１１０２．３、ＴｏｋｅｎＲｉｎｇ／ＩＥＥＥ１１０２．５などがある。ＷＡＮ技術には、これらに限らないが、２地点間リンク、ＩＳＤＮ（総合デジタル通信網）やその変種などの回路交換ネットワーク、パケット交換ネットワーク、およびＤＳＬ（デジタル加入者回線）が挙げられる。

通信接続９５０は、ネットワークインターフェース９４８をバス９１８に接続するために用いられるハードウェア／ソフトウェアを指す。図を分かりやすくするためにコンピュータ９１２の内部に通信接続９５０を示しているが、これはコンピュータ９１２の外部としてもよい。ネットワークインターフェース９４８に接続するために必要なハードウェア／ソフトウェアには、単なる例として、標準的な電話グレードのモデム、ケーブルモデムおよびＤＳＬモデムなどのモデム、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カードなどの内部技術および外部技術が含まれる。

上記の説明には本発明の例が含まれる。無論、本発明を説明する目的で構成要素または方法論の着想しうるすべての組合せを記載することは不可能であり、当業者は、本発明のさらに多くの組合せおよび入れ替えが可能であることを認識されよう。したがって、本発明は、添付の特許請求の範囲の主旨および範囲に該当するすべてのそのような変更、修正、および変形を包含するものとする。さらに、詳細な説明または特許請求の範囲で用語「〜を含む（ｉｎｃｌｕｄｅ）」が使用される範囲内で、この語は、請求項で接続語として「〜を備える（ｃｏｍｐｒｉｓｉｎｇ）」が用いられる場合の解釈と同様に包含的な意味とする。

本発明の一態様による購入の統合と閾値方式の課金を容易にするシステムの高レベルブロック図である。 本発明の一態様による、顧客のリソース使用量を記録し、閾値量に達した時にリソース使用量についての支払いを要求するシステムの模式ブロック図である。 本発明の一態様による閾値に影響する例示的要素の模式図である。 本発明の一態様による購入の統合と閾値方式の課金を容易にする例示的プロセスの流れ図である。 本発明の一態様による購入の統合と閾値方式の課金を容易にする例示的プロセスの流れ図である。 本発明の一態様による図５のプロセスから続く例示的プロセスの流れ図である。 本発明の一態様による図６のプロセスから続く例示的プロセスの流れ図である。 本発明の一態様による閾値方式の課金を容易にする例示的フローチャートである。 本発明の各種態様を実施する例示的環境の図である。

符号の説明

１１０ 購入エンティティ
１２０ オンライン販売者
１３０ イベント識別および追跡コンポーネント
１４０ デビットコンポーネント
２２０ イベント検出コンポーネント
２３０ リソース使用量レコーダ
２４０ （非）ローカルキュー（バッファ）
２５０ リソースプロセッサ／アナライザ
２６０ 引き落とし要求コンポーネント
２７０ ＭＰＦシステム
３１０ リソースのタイプ
３２０ リソースの量
３３０ 支払い手段
３４０ 支払い業者からのフィードバック
３５０ 顧客の過去の使用量
３６０ 商店／契約サービス提供者
３７０ 時間
３００ 閾値リソース価値
９１４ 処理装置
９１６ システムメモリ
９２０ 揮発性
９２２ 不揮発性
９２６ インターフェース
９２４ ディスク記憶装置
９２８ オペレーティングシステム
９３０ アプリケーション
９３２ モジュール
９３４ データ
９３６ 入力装置
９３８ インターフェースポート
９４０ 出力装置
９４２ 出力アダプタ
９４４ リモートコンピュータ
９４６ メモリ記憶装置
９４８ ネットワークインターフェース
９５０ 通信接続

Claims (40)

1. エンティティによって開始されたイベントを検出して、そのイベントが閾値リソース価値の対象となるかどうかを判定する検出コンポーネントと、
   少なくとも前記イベントのサブセットが前記閾値リソース価値に達すると、前記エンティティに課金するデビットコンポーネントと
   を備えることを特徴とするデビットシステム。
2. 前記イベントは、事前に価値が評定されるか、事前に価値が評定されないかのいずれかであることを特徴とする請求項１に記載のシステム。
3. 前記閾値リソース価値は金銭価値に相当することを特徴とする請求項１に記載のシステム。
4. 前記閾値リソース価値は消費可能な単位に相当することを特徴とする請求項１に記載のシステム。
5. 前記イベントは少なくとも１回の購入を表すことを特徴とする請求項１に記載のシステム。
6. 前記イベントは、エンティティが使用するための１つまたは複数のリソースを備え、前記検出コンポーネントは、そのようなリソースが前記閾値リソース価値の対象となるかどうかを検出することを特徴とする請求項１に記載のシステム。
7. 前記イベントは少なくとも１回目のイベントを備え、前記１回目のイベントは少なくとも第１のリソースを備え、前記第１のリソースは、金銭価値および消費可能な単位の価値の少なくとも１つを有することを特徴とする請求項１に記載のシステム。
8. 前記イベントは少なくとも２回目のイベントを備え、前記２回目のイベントは前記１回目のイベントと異なり、前記２回目のイベントは少なくとも第２のリソースを備え、前記第２のリソースは、前記第１のリソースと異なる金銭価値および消費可能な単位の価値の少なくとも１つを有することを特徴とする請求項７に記載のシステム。
9. 任意の１回のイベントは、複数の異なる金銭価値または消費可能な単位の価値を有する複数の異なるリソースを備えることを特徴とする請求項１に記載のシステム。
10. 前記エンティティは顧客であり、前記顧客は、個人、複数の人、会社、およびマシンのいずれかであることを特徴とする請求項１に記載のシステム。
11. 前記閾値リソース価値に達するまで、現在のイベントを以前のイベントと関係付けてリソース使用量を追跡する追跡コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
12. 前記デビットコンポーネントは、前記閾値リソース価値に少なくとも達すると、前記エンティティの支払い業者に支払いを要求することを特徴とする請求項１に記載のシステム。
13. 少なくとも支払いが行われた旨の通知が受け取られるまで、前記検出コンポーネントに入ってくるイベントを一時停止して経済的損失を軽減することを特徴とする請求項１に記載のシステム。
14. 支払いが行われたこと；支払いが行われていないこと；前記エンティティによるそれ以上の使用が一時停止されること；および、前記閾値リソース価値までＱ単位以内であり、Ｑは１以上の整数であること、の少なくとも１つを前記エンティティに通知する通知コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
15. 外部コンポーネントが前記閾値リソース価値を基準とした前記エンティティのアカウントの状態を判定することを可能にする照会コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
16. オンラインの購入および請求の管理を容易にするシステムであって、
    リソース使用量が料金の閾値に関連付けられているかどうかを判定するコンポーネントと、
    前記リソース使用量を記録するリソース使用量レコーダコンポーネントと、
    蓄積されたリソース使用量を閾値リソース価値と比較して、前記閾値リソース価値に達したかどうかを判定する分析コンポーネントと、
    前記閾値リソース価値に達すると、前記リソース使用量についての支払いを要求する支払いコンポーネントと
    を備えることを特徴とするシステム。
17. 現在の合計リソース使用量を表すリソース残高をさらに備え、追加的なリソース使用量が前記リソース残高に追加され、前記リソース残高が前記閾値リソース価値と比較されて、現時点まで使用されたリソースについて支払いを要求するかどうかを判定することを特徴とする請求項１６に記載のシステム。
18. 少なくとも１回の以前のリソース使用イベントを、現在のリソース使用イベントと統合するコンポーネントをさらに備えることを特徴とする請求項１６に記載のシステム。
19. 購入の記録、支払いの記録、合計購入額の記録、およびリソース使用量の記録の少なくとも１つを記憶する、前記リソース使用量レコーダに動作的に結合されたデータベースをさらに備えることを特徴とする請求項１６に記載のシステム。
20. 前記データベースは非ローカルの待ち行列であることを特徴とする請求項１９に記載のシステム。
21. 前記データベースは、使用または購入されたリソースの量をいくらでも記憶することができる無制限バッファであることを特徴とする請求項１９に記載のシステム。
22. 前記支払いコンポーネントから受け取った支払い要求を処理し、前記支払い要求が拒否されたアカウントを一時停止するコンポーネントをさらに備えることを特徴とする請求項１６に記載のシステム。
23. 前記コンポーネントは、メッセージ処理機構であることを特徴とする請求項２２に記載のシステム。
24. 前記閾値リソース価値は、少なくとも部分的に、
    リソースのタイプ；
    リソースの量；
    支払い手段；
    支払い業者からのフィードバック；
    エンティティの過去のリソース使用量；
    支払い履歴；
    商品またはサービス提供者の嗜好；
    エンティティの嗜好；および
    リソース使用の時間
    の要素の１つまたは複数に基づくことを特徴とする請求項１６に記載のシステム。
25. 前記閾値リソース価値は、周期的または不規則に、手動でまたは自動的に調整されることを特徴とする請求項１６に記載のシステム。
26. 閾値方式の課金を容易にする方法であって、
    少なくとも１回目のイベントがエンティティによって開始されたことを検出するステップと、
    前記１回目のイベントが閾値リソース価値の対象となることを判定するステップと、
    前記１回目のイベントに対応するリソース使用量を、データベースに維持される個々のリソース残高に記録するステップと、
    前記リソース残高が前記閾値リソース価値に達するかどうかを判定するステップと
    を備えることを特徴とする方法。
27. 前記閾値リソース価値に達すると支払い業者に支払い要求を送信するステップと、前記支払い要求を前記データベースに記録するステップとをさらに備えることを特徴とする請求項２６に記載の方法。
28. 前記支払い要求が送信される時に前記個々のリソース残高をリセットするステップをさらに備えることを特徴とする請求項２７に記載の方法。
29. 前記支払い要求は、未払い額の少なくとも一部をなすことを特徴とする請求項２７に記載の方法。
30. 前記未払い額は、前記リソース使用量または前記リソース残高の少なくとも一部に相当することを特徴とする請求項２９に記載の方法。
31. 未決の支払い要求に対応する課金コードを見つけ、前記支払い要求は課金コードに関連付けられているステップと、
    前記課金コードを呼び出すステップと、
    前記課金記録を読み出すステップと、
    前記支払い業者に対して前記支払い要求の決済を試みるステップと
    を備える、前記支払い要求を開始するステップをさらに備えることを特徴とする請求項２７に記載の方法。
32. 前記支払い業者に対する前記支払い要求が拒否される場合は、リソースの利用を一時停止するステップをさらに備えることを特徴とする請求項２７に記載の方法。
33. 前記データベースは、前記閾値リソース価値に達するまで多数のイベントを保持することが可能な非ローカルキューおよび無制限バッファのいずれか１つであることを特徴とする請求項２７に記載の方法。
34. 前記支払い要求を満たすための少なくとも１回の後の試行をスケジュールするステップをさらに備えることを特徴とする請求項３２に記載の方法。
35. 前記支払い要求を記録するステップをさらに備えることを特徴とする請求項２７に記載の方法。
36. 閾値方式の課金を容易にするシステムであって、
    少なくとも１回目のイベントがエンティティによって開始されたことを検出する手段と、
    前記１回目のイベントが閾値リソース価値の対象となることを判定する手段と、
    前記１回目のイベントに対応するリソース使用量を個々のリソース残高に記録する手段と、
    前記リソース残高が前記閾値リソース価値に達するかどうかを判定する手段と
    を備えることを特徴とするシステム。
37. 前記閾値リソース価値に達すると、支払い業者に支払い要求を送信する手段をさらに備えることを特徴とする請求項３６に記載のシステム。
38. コンピュータ実行可能コンポーネントが記憶されたコンピュータ可読媒体であって、前記コンポーネントは、
    エンティティによって提出されたイベントを検出して、そのイベントが閾値リソース価値の対象となるかどうかを判定する検出コンポーネントと、
    少なくとも前記イベントのサブセットが前記閾値リソース価値に達すると、前記エンティティに課金するデビットコンポーネントと
    からなることを特徴とする媒体。
39. コンピュータ実行可能コンポーネントが記憶されたコンピュータ可読媒体であって、前記コンポーネントは、
    エンティティによるリソース使用が料金の閾値の対象となるかどうかを判定するコンポーネントと、
    前記リソース使用量を記録するリソース使用量レコーダコンポーネントと、
    蓄積されたリソース使用量を閾値リソース価値と比較して、前記閾値リソース価値に達したかどうかを判定する分析コンポーネントと、
    前記閾値リソース価値に達すると、前記リソース使用量についての支払いを要求する支払いコンポーネントと
    からなることを特徴とする媒体。
40. ２つ以上のコンピュータプロセス間で送信されて潜在的なスパム発信者を識別することを助けるように適合されたデータパケットであって、
    リソース使用量が料金の閾値に関連付けられているかどうかを判定することに関連付けられた情報であって、前記リソース使用量は記録および分析されて、蓄積されたリソース使用量が閾値リソース価値に達するかどうかを確かめる情報と、
    前記閾値リソース価値に達した時に前記リソース使用量についての支払いを求める要求に対応する情報と
    を備えることを特徴とするデータパケット。
    

Images