U.S. patent application number 10/292118 was filed with the patent office on 2003-07-03 for system and method for implementing frictionless micropayments for consumable services.
Invention is credited to Greene, William Sprott, Roberson, James A..
Application Number | 20030126079 10/292118 |
Document ID | / |
Family ID | 23352823 |
Filed Date | 2003-07-03 |
United States Patent
Application |
20030126079 |
Kind Code |
A1 |
Roberson, James A. ; et
al. |
July 3, 2003 |
System and method for implementing frictionless micropayments for
consumable services
Abstract
The present invention is directed to a system, method and
software program product for implementing a policy payment agent
which, based on policy thresholds set by the consumer, determines
whether or not to autonomously issue a payment. Initially, the
consumer sets the payment policy through the selection of payment
parameters such as the type of consumable or transaction, maximum
one-time payment amount, and recent spending rate. If the payment
request meets the payment policy criteria, then the payment agent
autonomously issues a payment. Otherwise, the request is passed to
the user for manual intervention.
Inventors: |
Roberson, James A.; (The
Woodlands, TX) ; Greene, William Sprott; (Fairview,
TX) |
Correspondence
Address: |
WORLDCOM, INC.
TECHNOLOGY LAW DEPARTMENT
1133 19TH STREET NW
WASHINGTON
DC
20036
US
|
Family ID: |
23352823 |
Appl. No.: |
10/292118 |
Filed: |
November 12, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60344956 |
Nov 12, 2001 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 20/00 20130101;
G06Q 20/102 20130101; G06Q 10/06 20130101; G06Q 20/04 20130101;
G06Q 20/4016 20130101; G06Q 30/06 20130101; G06Q 20/403 20130101;
G06Q 20/29 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06F 017/60 |
Claims
1. A method for handling payment requests without user intervention
by implementing a payment policy comprising: retaining payment
policy criteria, said payment policy criteria describing the user's
consumption persona for authorizing payments from the user, without
intervention from the user; receiving a payment request from a
payment requester; accessing the payment policy criteria; analyzing
the payment request using the payment policy criteria; and
autonomously authorizing a payment based on the analysis of the
payment request under the payment policy criteria.
2. The method recited in claim 1 above, wherein the payment policy
criteria includes a maximum payment amount threshold and the method
further comprises: extracting a requested payment amount from the
payment request; and analyzing the payment request using the
payment policy criteria further comprises: comparing the requested
payment amount with the maximum payment amount threshold.
3. The method recited in claim I above, wherein the payment policy
criteria includes a maximum pay out rate threshold and the method
further comprises: calculating a pay out rate for the user; and
analyzing the payment request using the payment policy criteria
further comprises: comparing the pay out rate for the user with the
maximum pay out rate threshold.
4. The method recited in claim 1 above, wherein the payment policy
criteria includes a service type identifier criterion and the
method further comprises: extracting a service type identifier from
the payment request; and analyzing the payment request using the
payment policy criteria further comprises: comparing the service
type identifier from the payment request with the service type
identifier criterion.
5. The method recited in claim 1 above, wherein the payment request
is a first payment request and the payment requestor is a first
payment requestor and the method further comprises: receiving a
second payment request from a second payment requester; analyzing
the second payment request using the payment policy criteria; and
soliciting a response from the user based on the analysis of the
second payment request under the payment policy criteria.
6. The method recited in claim 5 above, wherein the payment policy
criteria includes a maximum payment amount threshold and the method
further comprises: extracting an amount requested from the second
payment request; and analyzing the second payment request using the
payment policy criteria further comprises: comparing the amount
requested with the maximum payment amount threshold.
7. The method recited in claim 5 above, wherein the payment policy
criteria includes a maximum pay out rate threshold and the method
further comprises: calculating a pay out rate for the user; and
analyzing the second payment request using the payment policy
criteria further comprises: comparing the pay out rate for the user
with the maximum pay out rate threshold.
8. The method recited in claim 5 above, wherein the payment policy
criteria includes a service type identifier criterion and the
method further comprises: extracting a service type identifier from
the second payment request; and analyzing the second payment
request using the payment policy criteria further comprises:
comparing the service type identifier from the second payment
request with the service type identifier criterion.
9. The method recited in claim 5 further comprises: receiving the
response from the user; and authorizing a payment to the payment
requester based on the response from the user.
10. The method recited in claim I further comprises: receiving a
notification of insufficient available funds to cover a requested
payment amount; and informing the user of the receipt of the
notification of insufficient available funds.
11. The method recited in claim 1, wherein autonomously authorizing
a payment to the payment requestor further comprises: requesting a
payment voucher from a banking service.
12. The method recited in claim 1 further comprises: directing the
payment voucher to the payment requestor.
13. The method recited in claim 1 further comprises: directing the
payment voucher to a third party.
14. The method recited in claim 1, further comprises: storing the
payment policy criteria on a connectable storage.
15. The method recited in claim 1, further comprises: inviting an
application into a local process space, wherein the application is
controlled by the payment requestor.
16. A computer program product stored on a computer readable medium
for implementing a policy based payment agent for handling payment
requests without user intervention comprising: instructions for
retaining payment policy criteria, said payment policy criteria
describing a user's consumption persona for authorizing payments
from the user, without intervention from the user; and instructions
for implementing a payment agent comprising: instructions for
receiving a payment request from a payment requestor; instructions
for accessing the payment policy criteria; instructions for
analyzing the payment request using the payment policy; and
instructions for autonomously authorizing a payment based on the
analysis of the payment request under the payment policy
criteria.
17. The computer program product recited in claim 16 above, wherein
the instructions for implementing a payment agent further comprise:
instructions for extracting a requested payment amount requested
from the payment request; and instructions for comparing the
requested payment amount requested with the maximum payment amount
threshold.
18. The computer program product recited in claim 16 above, wherein
the instructions for retaining payment policy criteria further
comprise instructions for retaining a maximum pay out rate
threshold and the instructions for implementing a payment agent
further comprise: instructions for calculating a pay out rate for
the user; and instructions for comparing the pay out rate for the
user with the maximum pay out rate threshold.
19. The computer program product recited in claim 16 above, wherein
the instructions for retaining payment policy criteria further
comprise instructions for retaining a service type identifier
criterion and the instructions for implementing a payment agent
further comprise: instructions for extracting a service type
identifier from the payment request; and instructions for comparing
the service type identifier from the payment request with the
service type identifier criterion.
20. The computer program product recited in claim 16 above, wherein
the instructions for implementing a payment agent further comprise:
instructions for soliciting a response from the user based on the
analysis of the second payment request under the payment policy
criteria.
21. The computer program product recited in claim 20 further
comprises: instructions for receiving the response from the user;
and instructions for authorizing a payment to the payment requester
based on the response from the user.
22. The computer program product recited in claim 16, wherein the
instructions for implementing a payment agent further comprise:
instructions for receiving a notification of insufficient available
funds to cover a requested payment amount; and instructions for
informing the user of the receipt of the notification of
insufficient available funds.
23. The computer program product recited in claim 16, wherein the
instructions for implementing a payment agent further comprise:
instructions for requesting a payment voucher from a banking
service.
24. The computer program product recited in claim 23 further
comprises: instructions for directing the payment voucher to the
requester.
25. The computer program product recited in claim 15, wherein the
instructions for implementing a payment agent further comprise:
instructions for communicating with an application running in local
process space, wherein the application is controlled by the payment
requestor.
26. The computer program product recited in claim 16, wherein the
instructions for implementing a payment agent are stored remotely
from the user, the computer program product further comprises:
instructions for finding the payment agent.
27. The computer program product recited in claim 16, wherein the
instructions for implementing a payment agent are stored remotely
from the user, the computer program product further comprises:
instructions for calling the payment agent.
28. The computer program product recited in claim 16, wherein the
instructions for implementing a payment agent are stored remotely
from the user, the computer program product further comprises:
instructions for remotely executing the payment agent.
29. The computer program product recited in claim 16, wherein the
instructions for retaining payment policy criteria are stored
remotely from the user, the instructions for implementing a payment
agent further comprise: instructions for retrieving a remotely
located payment policy criterion.
30. An apparatus for handling payment requests without user
intervention by implementing a payment policy comprising: retaining
means for retaining payment policy criteria, said payment policy
criteria describing the user's consumption persona for authorizing
payments from the user, without intervention from the user;
receiving means for receiving a payment request from a payment
requestor; accessing means for accessing the payment policy
criteria; analyzing means for analyzing the payment request using
the payment policy criteria; and authorizing means for autonomously
authorizing a payment based on the analysis of the payment request
under the payment policy criteria.
31. The apparatus recited in claim 30 above, wherein the payment
policy criteria includes a maximum payment amount threshold and the
apparatus further comprises: extracting means for extracting a
requested payment amount from the payment request; and comparison
means for comparing the requested payment amount with the maximum
payment amount threshold.
32. The apparatus recited in claim 30 above, wherein the payment
policy criteria includes a maximum pay out rate threshold and the
apparatus further comprises: calculation means for calculating a
pay out rate for the user; and comparison means for comparing the
pay out rate for the user with the maximum pay out rate
threshold.
33. The apparatus in claim 30 above, wherein the payment policy
criteria includes a service type identifier criterion and the
apparatus further comprises: extracting means for extracting a
service type identifier from the payment request; and comparison
means for comparing the service type identifier from the payment
request with the service type identifier criterion.
34. The apparatus in claim 30 above further comprises: solicitation
means for soliciting a response from the user based on the analysis
of a payment request under the payment policy criteria.
Description
CROSS REFERENCES TO RELATED APPLICATIONS
[0001] The present application is related to and claims priority
from co-pending U.S. Provisional Patent Application No. 60/344,956
filed on Nov. 12, 2001, and entitled "System And Method For
Creating And Managing Survivable, Service Hosting Networks." The
above-identified application is incorporated in its entirety herein
by reference.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates to network and information
technology. More particularly, the present invention relates to
paying for services and consumables over a globally dispersed
network. Still further, the present invention relates to making
secure and efficient payment decisions based on a payment policy
which exemplifies the persona of the payer.
[0004] 2. Description of Related Art
[0005] The Internet is a vast system of computer networks organized
as a network of networks whereby computers, and the users of
computers, can access information from other computers on one of
the networks. This information, commonly referred to as "content,"
is most often provided free to users of the Internet merely by
looking up a site where the content may be found. However, the
popularity of the Internet among users was greatly enhanced by the
availability of services that were perceived as being as-good-as,
or better than those typically used by consumers at that time such
as e-mail exchange, Internet chat, instant news, weather and market
updates, and the availability of information on a global scale that
was previously typically available only at a local level, e.g.
employment listings and opportunities, retail shopping and
auctions. Since that time, the Internet has become even more
indispensable as a means for facilitating other services that were
heretofore unknown such as music and video downloads, online
gaming, Internet telephony and video conferencing, and real-time
access to a wide variety of financial opportunities from stock,
bond and commodity trading to financing options. However, these
online services come at a price. The recent dot-com collapse and an
emerging sense of "Internet fatigue" by businesses has emphasized
that services available on the medium are not "free," but are more
appropriately pay-as-you-go services which cannot be born entirely
by Internet Service Providers (ISPs) and advertisers.
[0006] Non-commercial Internet users have been reluctant to
patronize for-pay sites in any great number, or even to a point
past the break-even point necessary for many of these sites to
continue providing their services. Some prognosticates have
relegated all viable commercial web sites of the future into one of
two categories: online retail sales and advertiser paid content.
However, both of these characterizations are far too simplistic of
descriptions for the services that the Internet currently provides
or is expected to be available to users in the future. Maybe the
greatest under-exploited use for the Internet is that of a network
medium for providing third-party services to anyone who has the
capability of connecting to the Internet. However, as has been
shown, these consumables come at a cost that must be paid to ensure
their continued availability.
[0007] Currently, there are several types of payment models that
are used on the Internet which may be broken down into two general
usage groups: per transaction; and prior commitment. Most online
retail sales are per transaction events that take place between the
user and a provider without prearranging the event, other than
those specified by the debt holder, i.e., the credit card issuer,
bank, etc. Retail sales of videos and electronics, online auctions
and most other consumer goods are per transaction events in which
the customer and the provider engage and may never do so again.
Prior commitment transactions are those in which both the customer
and the provider agree in advance on a course of conduct. These
events, while possibly being one-time occurrences, more often
represent a continued arrangement between the provider and the
customer. Importantly, transaction costs on a per transaction event
basis may be greatly reduced when customers and the providers agree
in advance on an acceptable conduct. Moreover, risk and the
uncertainty associated with risk are also reduced when parties
engage in multiple transactions. However, prior commitment
transactions are simply not suitable for most online retail sales
as they limit the consumers' choices by the mere existence of the
prior commitment. Therefore, transactions in the prior commitment
group are largely limited to online consumables.
[0008] Whether a transaction is in the per transaction group or the
prior commitment group, paying for an Internet transaction usually
follows one or more of the following models:
[0009] Subsidies: Subsidy refers to getting someone else other than
the consumer to pay for a consumable. Subsidized content may be the
most prevalent form of paying for content on the Internet.
Generally, content subsidies are in one of two types:
advertisements; and third-party subscriptions which are described
below in detail.
[0010] Advertisements: Long held to be the savior of the "free"
Internet, banners, pop-ups and sponsor logos advertising were
touted as an effective means for businesses to convey commercial
messages to target audiences consisting largely of upwardly mobile
Internet users, who could be considered at least able to afford the
price of a computer and a monthly ISP fee. Thus, the conventional
thinking was that service providers could provide modest
consumables to any Internet user by passing the cost of the
consumables on to advertisers. Advertising subsidy is the normal
form of revenue for most Web sites offering content and is well
accepted by users. Problems associated with advertiser subsidized
free media content have been long understood from experiences with
the print, radio and television media. Aside from being cyclic,
difficult to verify (thus, hard to justify for advertisers and
difficult to promote for content providers), and expensive,
Internet advertising has additional disadvantages. These include
the Internet being unsuitable for temporally reaching large
segments of the population because a relatively low percentage of
the population has unfettered access to the Internet and, in
addition, the advertiser's message becomes diluted in the enormous
quantity of independent sites that advertise. In order to be seen,
an advertiser must place ads in a significant percentage of the
Internet sites being accessed in order to be seen. In addition,
users often resent advertisers for cluttering their favorite sites
with seemingly unnecessary content, especially users with slower
connection speeds such as those with narrow band dial-up
connections or those who access through heavily used connection
nodes that bottleneck network traffic during high usage peaks.
Internet advertising is often perceived as obscuring the user's
enjoyment of the consumables that lead the user to initially access
the site. However, the main disadvantage of advertising is that it
has not been shown to be an effective means for paying for content,
especially sites that offer consumables of low value, and therefore
attract fewer hits and sites that offer premium content, and
therefore are more expensive to advertise on.
[0011] Subscriptions: Prior to the implementation of any secure
means for conducting paying transactions on the Internet, the
subscription payment model was the most widely implemented means
for securing customer transactions. These types of subscriptions
are referred to as direct subscriptions because the user pays for
the consumables he receives. Generally, customers are required to
pay in advance for consumables, and if the customer does not pay,
then the customer is not entitled to the consumables. ISPs lead the
subscription forefront by providing access to the Internet on a fee
subscription basis, but other providers of consumables followed.
Subscriptions provide the customer with perhaps the lowest
transaction cost per transaction of any prior art payment model but
suffer from terminal rigidity. Subscribers are bound to the
provider for the term of the subscription regardless of the quality
provided by the provider. The subscriber pays regardless of how
much, or even whether or not the service is accessed. A subscriber
is always free to change providers prior to the end of the
subscription period or to subscribe to multiple services that
provide similar consumables, but multiple subscriptions effectively
double the cost, thus increasing the transaction cost. Normally, a
user will ride out the subscription period and then jump to a
different provider that is perceived to be a better value. The
tendency of subscribers to jump ship at the end of the subscription
period is detrimental to both the provider and the users. Providers
were often unable to count on continued support from users,
especially in markets with a finite amount of users and therefore
were often unable to justify upgrading consumables, and users were
hurt by the "grass is greener" syndrome where the advantage of
their current providers went unrecognized. Therefore, in an effort
to reduce the number of the subscribers automatically leaving the
services at a term's end, providers introduced two modified
subscription payment services. The first is third-party
subscriptions where the provider subsidizes the subscriber with
content from third-party providers, usually at no cost to the user.
The second is an automated payment mechanism whereby the user
agrees in advance to automatic billing for an additional
subscription period unless the user takes affirmative steps to the
contrary. In this variation of the subscription payment model, a
customer authorizes payment from a credit card or other source up
to a predetermined amount, over a preset time period. Pre-paid
e-cards and digital wallet services operate on a pre-paid version
of the subscription payment model.
[0012] Credit cards: Credit cards give a user the most optimum
means for expeditiously completing individual transactions, and
considering the newer security measures implemented by merchants on
the Internet and the amount of risk assumed by credit card issuers,
they are safe as well as convenient for users for one-time
transactions. However, transaction costs associated with credit
cards are high, and regressive. A larger percentage of the cost of
using a credit card is devoted to transaction costs for lower
valued transactions. Typically, a 2%-4% fee is charged by the
issuer for each payment made by the issuer, with an additional flat
charge of between $0.45-$0.95 assessed per credit card transaction.
So far as most users are concerned, a lower threshold exists for
Internet transaction viability using the credit card model than
with other payment models. Historically, that threshold has been
recognized to be between $2.00 and $3.00 per transaction but has
been rising steadily in recent years to between $8.00 and $10.00
per transaction. Transaction costs have an inverse relationship
with interest rates, so in periods where credit card interest rates
are relatively low, other fees increase, including credit card
transaction fees. Thus, the credit card payment model is an
exceptional mechanism for higher priced, per transaction
occurrences, and can be especially safe payment model for one-time
on-line transactions.
[0013] Internet currencies: Various schemes have been implemented
that allow users to pay for merchandise and consumables through the
use of an electronic currency medium that is accepted by various
on-line providers. A user merely buys an amount of electronic
currency that is spent with participating on-line providers in a
manner that is similar to using a credit card. The difference
between the Internet currency and credit card payment models is in
the transaction costs. Internet currencies are designed to have
extremely low per transaction costs because the currencies are
essentially pre-paid accounts that are used for consumables. Thus,
they have many similar features to the subscription payment model
with the exception of its rigidity. Internet currencies allow users
to patronize competing providers without doubling their costs.
[0014] Micropayments: The micropayment payment model refers to
payments for low-value electronic financial transactions, but more
generically, the term "micropayment" is taken to mean the entire
transaction. Ideally, the micropayment payment model addresses the
inefficiencies in other payment models that result in extremely
high transaction costs or cumulative transaction costs that
escalate with each sequential micropayment. An example of payment
inefficiencies are the transaction costs associated with each
credit card transaction which make credit card transactions for
online consumables nonviable below $8.00-$10.00 per transaction.
The micropayment payment model was never intended to address the
2%-4% fee charged card issuers for using the credit card, but was
instead directed to the additional flat charge for credit card
transaction. Another aspect of the conventional micropayment model
is in its application. The consumables themselves were segmented
into parts of the whole for which a micropayment was made.
Consumables such as text, music and gaming were divided up into
discrete segments and assigned a micro-value. For example, a single
song from a CD, a page of text from a favorite book, an image, a
discrete time period in a gaming session and so on. Thus, as a user
consumed a digital service, the user would pay for only the
micro-value of the consumption via a micropayment payment
model.
[0015] Micropayments have been analogized to other pay-as-you-use
services, such as water, sewage, electricity, gas, long distance,
cell minutes, etc., that are familiar to and accepted by consumers.
Thus, prior art Internet micropayment models have been based on
those well accepted concepts. However, users have not embraced
prior art micropayment schemes to the same degree for online
consumables as for the other, better known, pay-as-you-use
services. Commentators have offered various explanations for the
lack of consumer enthusiasm. These explanations vary from users
just disliking micropayments for online consumables to not being
able to accept paying for something that was once offered for free.
Another popular belief is that users often feel that payment to
their ISP is enough, i.e., all Internet content is somehow
subsidized by subscribing to an ISP.
[0016] Advocates of micropayments point to the general discontent
expressed by the public for the micropayment approach in the time
period immediately after other types of services being transformed
from set rate billing rates to pay-as-you-go. They stress that the
initial discontent for pay-as-you-go is eventually followed by a
more enthusiastic acceptance, or at least acquiescence, for a
market-based solution for managing a finite service resources,
e.g., water and sewage being examples of the most recently
converted utilities.
[0017] Opponents of micropayments suggest that the sectors where
micropayment-like models have worked are governmental services,
monopolies or cartels where the public has no other choice for
accessing the service resource and recognizes the resource as a
necessity. With regard to the Internet, the case is made that
micropayments have not even proven themselves as a viable
alternative to other payment models for services where users have
demonstrated a willingness to pay for, such as technical
publications, adult material and even for music and video
downloads. The latter two are of particular interest given the
recent file swapping trends that have permeated the Internet.
Recent studies have suggested that the micropayment payment model
would seem to be a particularly fitting solution to the problem of
file swapping because many users are unopposed to paying reasonable
fees for downloading selected music and video content over the
Internet. However, most users perceive "reasonable" as being less
than that for the retail equivalent because the publishing middle
man is eliminated. Additionally, and more to the micropayment
payment model, users would select which portions of content to buy,
a section of a newspaper rather than the paper, or an article
rather than the section of the newspaper, but could always buy the
whole paper at a preset amount which is less than the hard copy of
the newspaper because the print publisher is eliminated. Moreover,
the public seems to indicate that providers should be willing to
realize more modest profits if file swapping is eliminated, i.e.,
something is better than the nothing providers currently receive
when music and videos are file swapped.
[0018] The online world of electronic delivery of media content and
services is presently at an impasse. Credit cards and other
intermediary payment schemes are only practical for discreet
purchases for items valued at more than a few dollars. For content
and services that have a reasonable value below such thresholds,
but greater than zero, providers have been left with few
alternatives besides giving their offerings away to consumers, and
relying upon advertisements for revenue. Prior art subscription
models are an alternative, but are highly restrictive "walled
gardens," not allowing the consumer to go wherever and buy whatever
they want, as they would in an everyday shopping district, and thus
may be unacceptable to many consumers.
[0019] One alternative is to use any one of several prior art
micropayment mechanisms to allow content or services of small value
to be consumed and paid for on a usage basis. Such schemes have
failed to gain a following in the marketplace, apparently due to a
lack of consumer acceptance. Consumer rejection may be due to such
factors as being made nervous by a ticking meter; need for
assurance that they will not overspend their budget; the added
annoyance of having to respond to many confirmation prompts to
approve very small payment. The industry appears to have largely
acquiesced to this impasse, and seems resigned to a situation where
services of value below some threshold will of necessity be
provided for free and supported mainly through advertisements.
[0020] Prior art micropayment systems have suffered from both
usability and security shortcomings. More secure prior micropayment
systems were correspondingly more cumbersome and less user
friendly. Users of such systems were constantly bombarded with
payment authorization request pop-ups, which often required
reauthorization through the security layer before executing a
payment decision. These micropayment systems were bothersome to
users and actually encouraged making payments over traditional
credit and debit card channels because those payment systems were
seen as being more secure, and required very little more effort on
the part of the user. Additionally, as the micropayment
transactions "looked" and operated more like traditional credit
card transactions, their service charges crept up toward those
charged for traditional credit card transactions.
[0021] On the other hand, usability in prior micropayment systems
came at the expense of security. Unlike traditional pay-as-you-use
services, online services fees are not always time-based at a
pre-set rate. A user of a traditional pay-as-you-use service is
connected to one service of a particular type, usually without
immediate access to competitive services. Use-fees are known, and
therefore the user is in a good position to meter micropayment
charges on traditional pay-as-you-use service accounts and budget
their expenditures. However, even though online connections provide
the ultimate environment for a rich variety of both service types
and associative service fees, such environments do not always offer
the security of well-established providers, pre-set fees or even
standardized billing units or unit increments. Users of prior art
micropayment systems are often unaware of how much is paid out from
their account, payment frequency or even who is requesting payment
or the applicable billing rates Thus, users of the more friendly
prior art micropayment systems often experienced large and sometime
unexplained charges to their accounts. Budgeting for online service
was virtually impossible with these systems and the users were
often forced to return to traditional payment mechanisms due to the
uncertainty. Moreover, prior art micropayment systems provided
unscrupulous providers and hackers a direct conduit to the user
funds, whether as credit, debit or bank accounts. Fee changes by
providers were extremely difficult to monitor for users of more
friendly micropayment systems and the system was often vulnerable
even when the user was physically offline. Because users were not
required to authorize every transaction, a provider or hacker could
gain access to the user's account and drain it.
[0022] What is needed, therefore, is a micropayment system that is
both secure and user friendly, and in which the user maintains
absolute control of disbursements, yet is not bothered by continual
payment authorization requests. Also needed is a micropayment
system in which the user's payment preferences are understood and
carried out without exception, but that is flexible enough that the
preference might be altered between virtually every transaction.
Additionally, what is needed is a micropayment system that can be
easily adopted into existing online payment structures. One in
which transaction payments flow smoothly, thereby lessening their
associative transaction fees. Finally, what is needed is a more
secure micropayment system which is does not provide unscrupulous
providers and hackers with an open channel to the user's account
even when the account is not in use, and, a means for minimizing a
worst case scenario loss.
SUMMARY OF THE INVENTION
[0023] The present invention is directed to a system, method and
software implemented policy-based payment agent for disbursing
funds for both low valued and higher valued consumables online and
a policy based protocol utilizing user-defined parameters for
handling either. Initially, a user creates an instance of a payment
agent which embodies the persona of the user that can be authorized
by the user to handle payment transactions. The payment agent may
physically reside on the user's local device, a smart card
controlled by the user, or might instead be remotely hosted and
called only during transacting with a provider. The payment agent
may be an independent application that may be used to draw funds
from a variety of different banking services, or alternatively, the
payment agent may be issued to a user by a central banking service
for drawing payment vouchers to the issuing banking service only. A
secret key known only to the user is needed for activating the
payment agent and enabling it to authorize payment requests. The
user must select and set several threshold parameters for
configuring the payment agent. These parameters define the policy
information that determines if and when the agent can freely
release funds to a requester and when the agent should first ask
the user for confirmation. They include the type of consumable,
maximum payment amount, maximum pay out rate (which may be
specified by a rate amount, or, by an amount and a time period from
which a pay out rate may be to calculated). Other payment policy
parameters may also be specified by the user for making payment
decisions such as the geographic area for tax computations and
legality implications, the minimum balance amount of funds to
maintain in the account for replenishment notices for the user, and
the account information for the user's account containing monetary
units and the identity and location of a central banking service
holding the account. Additionally, the user may specify policy for
each type of consumable, thereby allowing for automated handling of
a certain type of consumables with a set of payment threshold
parameters fixed specifically for that type of consumable. These
policy parameters may be held on a user's smart card, local to the
user, or might be instead managed remotely at a secure
location.
[0024] User funds may be held by a trusted third party, such as a
central banking service, and payments to providers are drawn on
that account. The user deposits an amount with the banking service,
and payments are drawn on that amount until the user's funds are
depleted. Once depleted, the user replenishes the funds prior to
the central banking service honoring any payment demands from
providers. Thus, at any point in time, the risk to the user is
limited to the amount of funds on deposit with the central banking
service. Payments to providers may take the form of payment
vouchers that are requested by the payment agent, issued by the
central banking service, and then passed to the providers by the
payment agent. The providers then present the payment vouchers for
demand with the central banking service for payment (usually in the
form of transferring funds from the user's account to the
providers' accounts). Alternatively, the payment vouchers drawn on
the user's account may be issued by the payment agent directly and
passed to the provider for payment. In either case, the payment
agent may authorize a payment to be drawn on the user's account
based on the payment policy specified by the user. Whenever a
payment is authorized to be drawn on the user's account, the
payment agent compares the balance amount remaining in the user's
account to a pre-specified minimum balance amount. If the actual
balance amount in the user's account drops below the threshold
amount, the user is notified that the funds in the account may need
replenishing.
[0025] With a payment agent in place, payment policy parameters
selected, a payment account activated, funds deposited and payment
mechanism enacted, the user can invite a provider's application on
to the user's device. From time to time, the provider's application
may require payment for consumables to be expended in the user's
workspace and make periodic payment requests to the payment agent.
Using the policy that is the user's persona, the payment agent
analyzes the request based on the preset thresholds of the payment
policy parameters. Initially, the agent determines whether or not
it should consider any payment request for the particular type of
consumable extended by provider. If the payment agent determines
that it cannot process the payment request, that request is passed
to the user for manual intervention. Any payment request passed to
the user and subsequently approved by the user may be satisfied by
the user, e.g., a credit card, debit card, etc., or alternatively
may be redirected to the payment agent which handles the authorized
payment to the provider.
[0026] If the payment request is for a type of consumable that the
payment agent is authorized to consider for making payments to, the
payment agent then attempts to characterize the payment request as
a micropayment request for a low valued consumable that can be
handled automatically without user intervention, or some other type
of transaction (requiring manual intervention by the user). To
determine if the payment request can be properly considered a
micropayment request, the payment agent compares the requested
amount to the threshold amount set by the user for micropayments.
If the requested amount is above the threshold amount, then the
payment request is higher than the user specified for automated
payment by the payment agent. In that case, the request is passed
to the user for approval.
[0027] The provider is not necessarily paid merely because the
payment amount is below the micropayment threshold amount specified
by the user for automated payment by the payment agent. The payment
agent is also obliged to verify that the payment rate to providers
is not greater than the user had intended for a recent time period.
To do so, the payment agent keeps a record of the payments from a
user's account and analyzes the recent payment history for a
predetermined time interval to determine the recent pay out rate.
The amount of the payment request may either be included or
excluded from the determination of the recent pay out rate. If
used, the amount of the payment request from the provider is summed
with the amounts of other payments made from the user's account
over the preset time period and a recent pay out rate calculated
over that time period. Alternatively, the recent pay out rate may
be calculated over a preset time period without considering the
amount of the current payment request from the provider, and
thereby eliminating one calculation step. In either case, the
recent payment rate is compared to a threshold payment rate. If the
recent payment rate is outside the threshold micropayment rate set
up by the user, the payment request can either be denied outright
by the payment agent without further action by the user, or
alternatively, the payment agent may pass the payment request to
the user for further consideration. In the latter case, upon the
user approving the payment request, the payment agent updates its
account balance record to reflect the payment and then authorizes a
draft on the user's account. Then again, if the recent payment rate
is within the threshold payment rate specified by the user, the
payment agent can autonomously authorize a draft on the user's
account to the provider without any type of intervention from the
user.
[0028] In any case, whenever the payment agent authorizes a draft
on the user's account,, the agent determines what the new account
balance will be upon redemption of that voucher, and the resulting
balance amount is compared to the minimum balance amount threshold.
If the resulting balance amount drops below the minimum balance
amount threshold, the payment agent notifies the user that the
account funds should be replenished.
BRIEF DESCRIPTION OF THE DRAWINGS
[0029] The novel features believed characteristic of the present
invention are set forth in the appended claims. The invention
itself, however, as well as a preferred mode of use, further
objectives and advantages thereof, will be best understood by
reference to the following detailed description of an illustrative
embodiment when read in conjunction with the accompanying drawings
wherein:
[0030] FIG. 1 is a diagram depicting money and return value flowing
through supply chains of a service economy consisting of a
plurality of services in accordance with an exemplary embodiment of
the present invention;
[0031] FIG. 2 is a diagram depicting money and return value flowing
through supply chains of a service economy consisting of a
plurality of services being invoked by an independent application
in accordance with an exemplary embodiment of the present
invention;
[0032] FIG. 3 is a diagram depicting money and return value flowing
through supply chains of a service economy consisting of a
plurality of services being invoked by an application invited to
run in a consumer's process space in accordance with an exemplary
embodiment of the present invention;
[0033] FIG. 4 is a diagram depicting money and return value flow
approach for consumers paying for the end-user services that they
consume through applications invited to run in a consumer's process
space in accordance with an exemplary embodiment of the present
invention;
[0034] FIG. 5 is a diagram depicting alternative configurations for
the consumer's device, payment agent and the payment policy in
accordance with an exemplary embodiment of the present
invention;
[0035] FIG. 6 is flowchart depicting a process for instantiating a
policy based payment agent in accordance with an exemplary
embodiment of the present invention;
[0036] FIG. 7 depicts a flowchart of the payment process
implemented by the payment agent in accordance with an exemplary
embodiment of the present invention; and
[0037] FIGS. 8A and 8B depict a flowchart of the process used by
the payment agent for implementing the payment policy in accordance
with an exemplary embodiment of the present invention.
[0038] Other features of the present invention will be apparent
from the accompanying drawings and from the following detailed
description.
DETAILED DESCRIPTION OF THE INVENTION
[0039] Various embodiments for paying for network based services,
resources, content and other consumables have been used in the
prior art with uneven levels of success and acceptance. One
particularly useful mechanism involves implementing a funds
transfer API that allows all participants to securely create a
funds transfer authorization (voucher) made out to a specific
recipient in a specific amount. The actual funds are held on
deposit with a trusted third-party central bank. The voucher can be
passed over the network in the course of utilizing a service or
leasing a resource. The provider of the service or resource can
then cash in the voucher, which causes the central bank to transfer
monetary units from account to account in accordance with an
exemplary embodiment of the present invention. This approach is
analogous to the system of writing personal checks in the everyday
world.
[0040] This simple single mechanism enables money to flow through a
micro-economy as participants pay for services rendered: money and
return value flows through supply chains of a service economy. One
service may call other services in the course of carrying out its
own value-add services. Calling a service may result in activity
that is a composite of services supplied by multiple vendors. FIG.
1 is a diagram depicting money and return value flowing through
supply chains of a service economy consisting of a plurality of
services in accordance with an exemplary embodiment of the present
invention. The depiction is a simplified representation of the
service economy which includes only vendors' service A 120, service
B 130, service C 140 and central banking service 160 that maintains
funds accounts for vendor Alpha, Beta and Charlie, shown as
accounts 122, 132 and 142, respectively. In the depiction of the
exemplary service economy, vendor Alpha's service A 120 invokes a
service that Alpha does not own, in the example vendor Beta's
service B 130, and service B 130, in turn makes a call to a service
not owned by vendor Beta, service C 140. In this example, the three
services are supplied by vendors Alpha, Beta and Charlie, and as
the illustration suggests, value flows from Charlie to Beta to
Alpha and on to the consumer who requests the service that Alpha
offers. However, each vendor's service provides a unique value for
a price, shown as value 146 from service C 140 in return for money
134 from service B 130; value 136 from service B 130 in return for
money 124 from service A 120; and value 126 from service a 120 in
return for money 114 from the ultimate consumer. Money flows in the
opposite direction from value, from the consumer to Alpha to Beta
and finally to Charlie, though in amounts that reflect the value
imparted. Also depicted in the figure, services that receive money
for value transfer the money to their respective accounts in
central banking service 160, shown as money transfer arrows 118,
128 and 138.
[0041] The above-described service economy money flow is
implemented with the two simple funds transfer API calls of the
type described above. The service B program, for example, service B
130 issues a "createVoucher( )" call (not shown) to central bank
160 which is made out to Charlie's identity and authorizes a funds
transfer from Beta's account 132 to Charlie's account 142. In
return, central bank 160 issues a payment voucher (not shown) to
service B 130, which passes such voucher 134 to Service C in the
API calls of Service C 140. The programs implementing service C 140
will make "cashInVoucher( )" call 138 to central bank 160 to cash
in vouchers 134 it receives from Service B 130. The receipt of the
cashInVoucher( ) by central bank 160 completes the transfer of
monetary units from Beta's account 132 to Charlie's account
142.
[0042] FIG. 2 is a diagram depicting money and return value flowing
through supply chains of a service economy consisting of a
plurality of services being invoked by an independent application
in accordance with an exemplary embodiment of the present
invention. In this case, Joe Programmer decides to utilize Service
A 220 from vendor Alpha. Programmer Joe writes program 210 that
makes calls to Service A 220, and programs into his code the calls
to central bank 260 (supplying his password for authentication) to
request vouchers 208. Payment vouchers are returned (not shown)
from central banking service 160. Joe's code passes vouchers 214 to
Alpha in the course of exercising the interface of service A 220.
Service A 220 may find it necessary to invoke another service for
resources of consumables not inherent in Service A 220. The
movement of money and value between services takes place in exactly
the same manner as described above. Thus, with the two simple
central bank API calls, which create vouchers and cash in vouchers,
money can be moved through an entire supply chain, from end
consumer to "retail" services and on to "wholesale" services
further upstream.
[0043] The money and return value flow through a supply chain of a
service economy works exceptionally well in cases where Joe
Programmer has a keen understanding of security and management
issues, such as in the case of the ultimate consumer being a back
end of an enterprise. Problems occur in cases where the ultimate
consumer is not a programmer and is not skilled in writing programs
that make calls directly to supply chain services out there. In
most situations, Chappy Consumer will be running an application
supplied by a software company. It is the application used by the
consumer that makes calls to online supply chain services, and
which should also pass payments to the various online supply chain
services that it accesses. The user's application may be delivered
to the user's site using any number of different delivery
mechanisms: it might be bought at a store and installed onto a PC
from a CD; or the application might itself be a supply chain
service that is downloaded on the fly over the Internet to the
consumer's access device. In either case, the application that
Chappy uses has in effect been invited by Chappy into his process
space.
[0044] FIG. 3 is a diagram depicting money and return value flowing
through supply chains of a service economy consisting of a
plurality of services being invoked by an application invited to
run in a consumer's process space in accordance with an exemplary
embodiment of the present invention. Here, Chappy invites
ZebraSoftware application Z 310 to execute on Chappy's computer
300. In this scenario, application Z 310 from vendor ZebraSoft is
running on Chappy's machine 300 for the benefit of Chappy.
Application Z 310 is accessing a backend service ZServer 318 that
is also supplied by vendor ZebraSoft, and this service is accessing
Service A 320 from vendor Alpha. Application Z 310 is also directly
accessing Service B 330 from vendor Beta and might access other
services and/or content as necessary for performing the application
functions executed by Chappy and/or accessing the online content
selected by Chappy, via computer 300 through locally executing
application 310.
[0045] In the discussion up to now, a service such as Service A 320
is running in an environment essentially "owned" by Alpha, the
supplier of the service. But in the case of Application Z 310, the
situation is different. Application Z 310 is written by vendor
ZebraSoft, but is being run not by ZebraSoft on ZebraSoft
facilities, but by Chappy on Chappy's computer 300. In previous
examples, when dollars flow from Service B 330 to Service C 340, it
was implied that Beta was paying Charlie, via their respective
accounts in banking service 360. But now, in the case of the
application running on Chappy's machine, a more precise mechanism
is needed for about who is paying whom. The dollar flow arrows from
Application Z 310 to Service B 330 or to Service ZServer 318 should
somehow represent payments from Chappy to ZebraSoft and Beta. What
is needed is a mechanism to accommodate a program supplied by
company ZebraSoft to safely pass Chappy's money to ZebraSoft's and
Beta's accounts.
[0046] This capability (or the functional equivalent) should be
supported without compromising the security of Chappy's password or
subjecting Chappy to risk of financial loss. In the previous
example of Joe Programmer, since the application was Joe's own
code, he could safely wire in or type in his password into his own
program, and that program could safely make central banking calls
to accomplish the funds transfers in payment for vendor services.
Now the situation is different. Chappy cannot trust ZebraSoft
enough to reveal his password to ZebraSoft's Z application 310.
[0047] Additionally, the executing payment for low value
consumables is problematic for such an environment. Clearly, larger
consumables may be authorized directly by the consumer. However,
payment for lower valued consumables should address several
persistent concerns unrecognized by prior art micropayment systems,
including:
[0048] Competition between providers free market): In any viable
micropayment model for online consumables, competition between
providers of competing consumables must be encouraged. Thus, the
full effect of the free market forces may be brought to bear on
inefficient and unpopular providers.
[0049] Selectivity between consumables: As a corollary to
competition between providers, users must be allowed to make
decisions as to which provider to patronize without having to
manually authorize payments for lower valued consumables to them.
If a consumer feels the need to authorize automated micropayments
for one type of consumable, the consumer should have the option of
authorizing automated micropayments for all competitors for the
particular type of service without manual intervention.
[0050] Lack of complexity (simplicity of operation): Complexity may
be described on three user levels: invitation; money transfer; and
micropayments for consumables. Invitation refers to calling a
provider to a user's space to provide consumables for a fee; money
transfer refers to the act of safely transferring money from a
specified user money account into the micropayment system, and
thereby being available to be disbursed as micropayments; and
micropayment is the act of authorizing small payments for and
receiving low value consumables. More secure micropayment systems
are correspondingly more cumbersome and less automated because the
user makes all of the invitation, money transfer, and payment
decisions. In these types of micropayment systems, the user is
constantly being bombarded with payment request pop-ups and might
even be required to reauthorize through the security layer before
making a payment decision. Security is enhanced by dispensing the
user's mental effort on manually evaluating many tiny transactions
requests in order to conserve cheap resources. User friendly
micropayment systems are less secure because the provider
invitations, account replenishments and payment decisions are
delegated to the micropayment system by the user in advance and
thus are fully authorized by the software without user
intervention, thus no user control is retained.
[0051] Automation: Automation is one means for simplifying
invitations, money transfers or micropayments for the user, and is
probably the key to user acceptance while being the downfall of
security.
[0052] Security: At a high level, security refers to any mechanism
for stopping unauthorized intrusions into the micropayment system;
at a lower level it refers to a layered approach for deciding which
payment requests to consider, which requests are made for
micropayments, which micropayment requests should be granted
automatically and which requests, either micropayment or not, to
defer to the user.
[0053] Assurance of security: Security is provided to the user by
implementing the layered security decision process; however, the
user is assured that if all security measures break down, the worst
case loss can be known in advance and therefore risk is kept at a
manageable level for the user.
[0054] The solution to all of these demands is the implementation
of a policy based client payment agent in accordance with exemplary
embodiments of the present invention. The computer software-based
agent entity of the present invention seeks to address the problems
in prior art micropayment systems as well as resolve the impasse
faced by the online world of electronic delivery of media content
and services by handling the job of autonomously making small
payments on demand for services as they are consumed. The payment
agent acts much as an "authorized agent" in the business world, one
who is entitled to spend money on behalf of their employer, within
prescribed limits. In much the same way, the policy based payment
agent of the present invention is authorized by the consumer to
make small payments behind the scenes as the consumer consumes
online content. So long as payment amounts and spend rates are
within user-defined policy limits, the payment mechanism happens
non-intrusively, without annoying the consumer with confirmation
alerts. But at the same time, policy limits safeguard the consumer
from spending amounts beyond specified limits. The approach allows
the consumer to make casual purchases, without prior commitments
such as subscriptions, of any online content adopting this approach
to micropayments.
[0055] The payment agent is provided in the runtime environment on
the consumer's access device (PC, handheld, or other type of net
appliance). . This payment agent is essentially a check writer who
makes out checks to providers of consumables on behalf of the
consumer, but runs under a set of constraints that can be relied on
by the providers. It is the consumer's agent, much as a well-heeled
person might have a human or institutional agent that is authorized
to make payments on their behalf. The payment agent is in
possession of the secret password of the consumer, and can thus
carry out the voucher creation calls to the central bank in order
to create funds transfer vouchers with which to pay vendors.
[0056] FIG. 4 is a diagram depicting money and return value flow
approach for consumers paying for the end-user services that they
consume through applications invited to run in a consumer's process
space in accordance with an exemplary embodiment of the present
invention. The diagram depicted in FIG. 4 is identical to that
discussed above with respect to FIG. 3, with the exception of
payment agent 408 which will be emphasized in the following
discussion. It should be understood that device 400 is any type of
device which may access a network such as Personal Computers (PCs),
Personal Digital Assistants (PDAs), cell phones, net devices, other
net appliances, etc. Device 400 may connect to a network in any
manner, through electrical or optical conductors, over the air or
through other types of medium. It should also be recognized that
application 410 may be invited onto consumer's device 400 through
any of the above-mentioned network connection as a separate
application program, subprogram, routine or module embodied on a
memory such as an optical or magnet storage media, or may be
invited as a sub-part to a hardware or firmware appliance connected
to consumer's device 400. Finally, it should also be recognized
that application 410 may be executed directly by the operating
system of device 400, or within another application running on
device 400 such as in a virtual machine or container.
Alternatively, application 410 may be invited on an application
program that is specifically designed to comply with a particular
type of network protocol for interacting with nodes on a network
utilizing that protocol, such as a browser application supporting,
for example, the Hypertext Transfer Protocol (HTTP) application
protocol of the Transmission Control Protocol/Internet Protocol
(TCP/IP) transport protocol on the World Wide Web.
[0057] As discussed above, each of these "dollar flows" depicted in
the diagrams as arrows 404, 414, 416, 434 with $$$API signs are
actually accomplished by passing funds transfer authorization
(voucher) objects from process to process. The actual movement of
monetary units from account to account happens only when the party
receiving one of voucher 404, 414, 416, and 434 cashes it in with
central banking service 460 via the relaying of voucher 418, 428,
438 and 448, to central banking service 460. Thus, it should be
readily understood that the flow of money in the present invention
is quite analogous to the passing of checks from person to person,
or person to retailer and then on to the retailer's bank.
[0058] With the above approach to consumer payment for online
services, application 410 is invited into the consumer's device 400
and from then on periodically makes requests 417 to consumer's
payment agent 408 for money in return for a valuable (fee-based)
consumable 426. Payment agent 408 obliges and passes application
410 vouchers 404 made out to that application's supplier and/or the
suppliers of other online services that application 410 uses. Thus,
voucher 404 may identify the supplier of application 410 as the
recipient of the funds, such as vendor ZebraSoft. Alternatively,
voucher 404 may identify a third-party supplier as the recipient of
the funds, such as one of vendors Alpha, Beta or Charlie, in cases
where application Z 410 will call other consumables at the
direction of the consumer. Of course, vendor ZebraSoft may provide
the value of all consumables to the consumer on a turn-key basis
and, in that case, all vouchers 404 will identify vendor ZebraSoft
as the recipients, and then Service ZService 418 will issue its own
vouchers, such as vouchers 414, to turn-key providers such as
vendor Alpha.
[0059] Two final problems exist with the payment agent approach, as
described thus far: an unscrupulous application could make
excessive demands for payment and drain the consumer's account; and
the provider must trust vouchers as being valid and money being in
the bank to cover the voucher's redemption. This leads to the
approach of having a policy based payment agent that is wired with
rules for deciding when requests for payment are reasonable, and
when they are not reasonable, or at least when they are
questionable.
[0060] In accordance with an exemplary embodiment of the present
invention, a consumer has the option of setting several threshold
policy parameters in the configuration of the payment agent in
order to set the criteria for when the agent can freely release
funds and when the agent should first ask the user for
confirmation. This approach can prevent the issuance of vouchers to
types of services that the consumer has decided not to patronize;
conversely, if the consumer decides to patronize a certain type of
service, then the consumer can patronize service of that type,
thereby shopping around for the best provider without losing the
benefits of the preset policy parameters thresholds invoked by the
payment agent. Additionally, the invocation of the policy decreases
the risk of a single large loss due to a service demanding payments
that are larger than the consumer wishes to make, or at a higher
pay out rate than the consumer wishes to make, i.e., excessive
losses from multiple smaller payment demands over a predefined time
period. Tuning the policy allows the consumer to also set caps on
their average spending rates over the course of a month, a week, a
day, an hour . . . even a minute or second. So, it is not just
guarding against malicious applications, but also safeguarding the
consumer from their own excesses of consumption.
[0061] The present micropayment system involves the use of
electronic vouchers being issued to requestor/providers. Vouchers
provide an electronic equivalent of check writing. These check
objects are referred to herein as "vouchers," and their creation
and redemption are enabled by an API of two calls, "Create Voucher"
and "Cash In Voucher." These calls allow funds to flow through the
network between consumers and suppliers of services. Turning again
to FIG. 4, when consumer payment agent process 406 wishes to pay
for an online service, it makes a "Create Voucher" request to
central bank 460. The request to central banking service 460 may be
secured using trusted third-party techniques or public key
infrastructure. The consumer specifies the recipient identity and
the amount of the transfer. It is quite analogous to requesting a
cashier's check from a bank in the everyday world.
[0062] Banking service 460 returns a voucher object to requesting
consumer payment agent 406. In accordance with one exemplary
embodiment, the voucher may have two halves. Both halves contain
identical information, except that one half is encrypted using the
consumer's secret key, which is a secret shared with the bank, and
the other half is encrypted using the payee's secret key, such as
for Zebrasoft's application Z 410. Both consumer and supplier can
peek at the contents of the voucher. The voucher can be passed
across the network in any API calls of a service, and this is
effectively how money flows through the system. However, only the
party to whom the voucher is made out can cash it in.
[0063] The above described system of voucher creation and
redemption disallows payers from directly depositing funds into a
payee's account without the payee's consent. The need for payee to
deliberately cash in a voucher puts payment receipt on a consensual
basis. This approach, for example, guards against unwanted payments
such as bribes to be made.
[0064] Upon receiving a voucher in payment for a service, Vendor
Zebrasoft may, at their convenience, cash in the voucher by making
a "Cash In Voucher" call to central bank 460. Bank 460 verifies
that the identity of the party cashing in the voucher is identical
to the pay-to-the-order-of field of the voucher, in this example
Zebrasoft. Bank 460 also verifies that the two halves of the
voucher remain identical (unaltered in transit).
[0065] The bank then carries out the debit/credit (under
distributed transactional control) to accomplish the funds transfer
by transferring the draft amount from Chappy's account 402 to
Zebrasoft's account 412. Central banking service 460 enforces
"one-shot" behavior of the vouchers: once a given voucher is cashed
in, an identical copy of it cannot be cashed in again. One-shot
behavior is enforced through a mechanism whereby banking service
460 maintains a list of all outstanding vouchers for each user
account, indexing this list according to voucher IDs. When a payee
attempts to cash in a voucher, bank 460 verifies that the voucher
is still on the list of outstanding vouchers. If it does not appear
on the list, then the operation of redeeming the voucher fails, and
the party cashing in the voucher is informed of the failure. If the
voucher ID is found on the list of outstanding vouchers, then the
cashing-in operation can proceed (unless it fails for some other
reason). Whether or not the redemption of the voucher succeeds or
fails, the entry for that voucher is removed from the list of
outstanding vouchers.
[0066] Another point to note is that the provider of the bank
service may command a service charge (say 1%) for all funds
transfer transactions. This is easily accomplished, for example, by
debiting the payer's account by amount X, and crediting the payee's
account by something less than amount X, for example amount 0.99 X.
Thus, central banking service 460 accrues the service charge by
virtue of holding less total obligations to the account
holders.
[0067] FIG. 5 is a diagram depicting alternative configurations for
the consumer's device, payment agent and the payment policy in
accordance with an exemplary embodiment of the present invention.
As described above, a payment agent may be loaded onto the
consumer's device as part of an application suite, as an
independent third-party service or even as an application provided
by a debit service such as a central banking service. The point
here is that the payment agent is not under the direct control of
either the consumer or the providers, but issues vouchers in a form
acceptable to the provider, but in accordance with the payment
policy specified by the consumer. The two points of the payment
agent most vulnerable to attack are the agent itself and the
payment policy. If the agent is compromised, a hacker could easily
drain the consumer's account at the central banking service;
similarly, by altering the payment policy, a hacker could remove or
sufficiently weaken the policy parameter thresholds sufficiently to
drain the consumer's account. Therefore, the most secure
application of the payment agent and policy are implemented on a
remote, machine connectable device such as a smart card or the
like, which is only vulnerable to attack while it is actually
connected to the user's device while being used. Alternatively, the
agent may be physically located on a smart card or finally, the
payment agent might be remotely located and securely called only
when needed using a secret code. The payment policy may also be
stored securely on a remote site and retrieved when necessary using
the consumer's secret code, whether or not the payment agent is
stored locally or remotely.
[0068] Returning to FIG. 5, in accordance with one exemplary
embodiment, payment agent 506 is local on user machine 502, as is
payment policy 508. In the specific depiction, fee-based service
504 is also running on local machine 502 in a virtual machine (VM)
container as described in U.S. patent application Ser. No.
10/112,373, filed on Mar. 29, 2002, and entitled "Method And System
For Implementing A Global Ecosystem Of Interrelated Services," and
is incorporated by reference herein in its entirety. Payment agent
506 may also run on the same or on a different VM container on
local machine 502 as fee-based service 504, in cases where each is
running on the same machine, whether local machine 502 or on some
other remotely located machine. A connection is made once between
fee-based service 504 and payment agent 506 and is maintained
throughout the session. Alternatively, the payment agent and/or
payment policy may be located anywhere in extended network 526. In
that configuration, fee-based service 504 utilizes global lookup
526 for finding remotely located payment agent 516 which is invoked
by the user only after presenting a mutually agreed upon secret
code. After which, a connection is made between fee-based service
504 and remotely located payment agent 516 for the term of the
session. Additionally, remote payment agent 516 connects to payment
policy database 538 once the user's secret code is authenticated by
remote payment agent 516.
[0069] Whether or not the payment agent, and/or payment policy, is
local, remote or loaded locally from a remote location, user
defined policy must be instantiated prior to the agent's use. FIG.
6 is a flowchart depicting a process for instantiating a policy
based payment agent in accordance with an exemplary embodiment of
the present invention. It is understood that a payment agent might
be one of many that are available to a consumer, each of which may
take on the persona of the user (as a consumer). The separate
payment agents may be given access to separate accounts, thereby
giving the consumer a large pool of funds from which to draw, but
segregated, one from another, thereby lessening the consumer's risk
to the amount of the funds account actually being used by the
agent. Regardless, the process begins with the user creating an
instance of the policy agent (step 602) and setting a secret code
known only to the payment agent and the consumer (step 604). The
payment agent is responsible for authorizing funds to be drawn from
a predetermined consumer account held at a central banking service
using payment vouchers or the like, and therefore the banking
service will also be made aware of the consumer's secret code for
accepting account deposits, account maintenance, etc.
[0070] Once an agent is in place, the payment policy may be defined
for the agent by selecting parametric thresholds that will be used
by the payment agent for deciding whether or not to make an
automated payment or pass the decision on to the user. Persona
criteria may be entered which describes personal traits, such as
identity, age, profession, etc., along with other payment criteria,
such as the identity and location of the central banking service,
which are useful for making or implementing payment policy
decisions, or for routing payment vouchers (step 606). With this
information the agent may recognize from the policy that the
payment decision should be made exclusively by the consumer, such
as mature theme gaming, adult content, etc. Moreover, with the
persona criteria payment agents can be tailored for consumers who
are third-party beneficiaries of a benefactor, such as children and
other family members who rely on another's funds account for paying
for consumables. The persona criteria also helps the payment agent
to decide the legality of the transaction before having to make a
payment decision. If the transaction is not legal, or is
questionable given the policy and criteria, the agent passes the
decision on to the consumer for action. Next, geographic criteria
is entered (step 608). The geographic criteria is actually special
persona criteria and is used to compute and check such payments for
sales tax, franchise fees and other location dependent
assessments.
[0071] After the payment agent is set up and the basic persona
criteria is set, the consumer determines which types of services
may be considered by the payment agent for automated payment and
which types are not to be considered for payment by the agent
without intervention from the consumer (step 610). Once a selection
is made, any provider that identifies itself as being a provider of
the service type can be considered by the payment agent without
regard to the actual identity of the provider. Thus, the consumer
may shop around for the best price, value and response without
resetting the payment policy parameters. Also, the payment policy
may be indexed hierarchically or relationally. Thus, each payment
parameter may be selected in relation to a type of consumable,
globally for all payments for any type of consumable, or a
combination of both.
[0072] Next, the payment threshold is selected, either for the
particular type of service or for all types of services, or a
maximum threshold amount for all services and something less for
the particular type of service (step 612). This threshold amount is
used by the payment agent for bifurcating payments between
micropayment amounts and payment amounts above the micropayment
amount level. Typically, payment requests that are for amounts
below the threshold amount are not immediately passed to the
consumer, but are retained by the payment agent for further
consideration and possibly the ultimate issuance of a voucher. The
payment amount criteria provides that a payment agent with a
maximum payment amount for requests that can be handled
autonomously and thereby lessens the risk of the consumer's account
being drained in one transaction authorized by the payment agent.
However, an unscrupulous provider may make several or hundreds of
requests for lesser amounts below the threshold amount that drain
the consumer's account just as empty. This situation is addressed
by setting a payment rate threshold for the payment agent to check
before autonomously issuing a voucher (step 614). The payment rate
can be set as an amount and a time period, for example, $10.00 for
a 24-hour time period. With the service type, threshold amount and
rate maximums, the payment agent can form a payment decision based
on the payment policy specified by the consumer.
[0073] In order for the automated issuance of payment vouchers to
work efficiently, the consumer's account must have the funds
available from which to draw. This is necessary because providers
may make their consumable and/or services available merely on the
receipt of a payment voucher without having actually transferred
the cash or even having verified that the consumer's account
contains the requested amount. Therefore, payment vouchers should
represent a vested interest to the requested money in the
consumer's account. Without some assurance that funds are in the
consumer's account to cover the amount of the payment voucher, the
provider would find it necessary to draft the consumer's account
prior to providing the service. While this may be acceptable for
some larger payment requests, it may not be acceptable for cases
where the consumer is consuming a sequence of lower valued
consumables which require payment in a series of micropayments.
[0074] Additionally, the bank may go to extra lengths to ensure
that overdraft situations do not occur. If the bank's decision
whether to grant the payment agent's request to create a voucher is
based strictly upon comparing the user's current balance with the
amount of the requested voucher, then there is the chance that an
overdraft situation could arise due to the fact that this approach
does not take into account other outstanding vouchers not yet
redeemed. To remedy this, the bank can keep a tally for each user
account of the total amount of vouchers that are outstanding, in
addition to maintaining a record of the current account balance.
Thus, when a payment agent (or the user directly) requests the
creation of a new voucher, the bank service can look at the sum of
the outstanding voucher amounts and the requested voucher amount
and compare this sum with the current balance to determine whether
funds would be available to cover all outstanding obligations were
the new request to be approved. If not, then the voucher creation
request would fail due to lack of sufficient funds. Of course,
whenever a voucher is cashed in, the tally of outstanding voucher
obligations needs to be debited, as well as the funds account
transfer occurring. Also note that if vouchers incorporate a
feature of supporting an expiration date, then additional
bookkeeping features need to be incorporated into the bank
service's accounting program to ensure that the tallies of
outstanding voucher obligations are adjusted whenever expirations
on outstanding vouchers occur. (Standard programming techniques,
for instance using priority queue data structures, can be used for
making sure that such tallies of outstanding voucher amounts are
properly adjusted to reflect voucher expirations.)
[0075] To avoid the situation where the payment agent is unable to
issue payment vouchers midway through a series of micropayments,
the consumer may also enter a minimum balance threshold that is set
for checking against the payment agent's account balance record
(step 616). Whenever the payment agent's account balance record
indicates that the balance drops below the minimum balance
threshold amount, the consumer is notified that the account balance
is low.
[0076] After the policy parameters are entered, the parameters are
checked for their legal implications (step 620). Payment policies
that indicate the payment agent could authorize an illegal
transaction are identified, such as underage consumers intending to
access adult materials, state taxes are not authorized for
inclusion in the payment amount, etc. If any are identified, the
process returns to the point in policy that needs adjusting;
otherwise, the process dumps the selected policy and reverts to
setting up a new policy agent. Once the consumer policy selections
have been determined to be directed to only legal transactions, the
policy criteria are saved with the consumer's secret code (step
622). And finally, if a new instance of the payment agent is to be
created, the process reverts to the agent creation step; otherwise,
the process ends (step 624). The process then ends.
[0077] As described briefly above with regard to FIG. 5, all
payment requests are handled through the payment agent. The payment
process implemented by the payment agent in accordance with an
exemplary embodiment of the present invention is depicted in the
flowchart illustrated in FIG. 7. Initially, the payment agent is
invoked and continues to run on the consumer's machine.
Alternatively, a process that is invited into the consumer's
machine may cause the machine to invoke the agent. In any case, all
incoming communications are monitored for requests for payments
(step 702). When a request for payment is identified, the
information in the request is first parsed for the amount
requested, the identity of the provider requesting the payment and
the type of service making the request and other pertinent
information (step 704). Next, the payment agent is identified for
handling the payment request (step 706). As mentioned briefly
above, it is possible that multiple payment agents may be available
to the consumer's machine, or might be running in the background.
Various criteria might be used to identify the payment agent to be
invoked such as the account balance amount in each account serviced
by the payment agents, the identity of the consumer logged on to
the device, etc. Alternatively, the consumer's device may have only
one instance of a payment agent associated with it which is
accessed. As also mentioned above, the agent may be physically
located on a smart card device, on the consumer's local machine, or
even on a secure remote site that is accessible by only the
consumer using the consumer's secret code. Once the payment agent
is invoked, the payment policy for the agent is retrieved (step
708). Payment policy is held in a secure location, possibly with
the payment agent, that is accessible by the payment agent without
any intervention from the user.
[0078] With the payment agent and the policy, the payment agent can
invoke the payment policy for handling the payment request (step
712). If the payment policy permits the payment agent to handle the
request autonomously, then according to one exemplary embodiment a
payment voucher is requested from the banking service in the
identity of the requestor/provider and, once received from the
banking service, passed to the requestor/provider without manual
intervention from the user (step 716) and the consumer's device
waits to receive another payment request, possibly with the payment
agent running in the background. Returning to step 712, if the
payment policy restricts the payment agent from making the decision
autonomously, then the payment agent may automatically issue a
denial to the requestor/provider for the payment (step 714) and the
consumer's device returns to the waiting state, possibly with the
payment agent running in the background.
[0079] Here it should be understood that the implementation of
payment policy takes one of several courses: autonomous
authorization for payment by the payment agent followed by the
issuance of a payment voucher to the requestor/provider; refusal to
handle the payment request by the payment agent for policy reasons;
and deference to the consumer who either authorizes or denies the
payment request. If the consumer authorizes the payment request,
the payment agent requests the issuance of a payment voucher,
alternatively, if the consumer denies the request, the payment
agent may issue a payment denial to the requestor/provider. Under
certain conditions the payment policy may circumvent the payment
agent from soliciting the consumer's intervention for making
payment decisions, such as with minor-aged consumers or consumers
who are third party beneficiaries of another's funds account.
However, it is expected that in most situations where the payment
policy prohibits the payment agent from autonomously authorizing a
payment, the payment request will be passed to the user for direct
user interaction.
[0080] FIGS. 8A and 8B depict a flowchart of the process used by
the payment agent for implementing the payment policy in accordance
with an exemplary embodiment of the present invention. The process
depicted in FIGS. 8A and 8B diagrammatically illustrates the
payment policy implementation steps 710 and 712 on the flowchart
depicted in FIG. 7. The process begins with legality check (step
802). If the payment policy suggests that authorizing the payment
would be illegal, then the payment process is immediately
terminated and a denial is sent to the requestor/provider (step
828), and the process ends. Alternatively, if the legality is
merely questionable, the request may be passed to the consumer for
disposal at entry point "C" (not depicted in decision 802). Payment
policy may be specified which allows the consumer to manually
intervene whenever a transaction is illegal or questionable rather
than the process ending automatically. However, in cases where a
third-party beneficiary is transacting with the provider, the
consumer may not be given the option to intervene.
[0081] Next, the payment agent identifies the type of service
transaction from the payment request and determines whether or not
the requested type is authorized (step 804). If not, the process
sends the request to the user, where a pop-up window, or the like,
is presented to the user (step 820) for authorization for the
requested payment (step 822). If the consumer manually authorizes
the payment, the authorization is returned to the payment agent
which authorizes the central banking service to issue a payment
voucher in the name of the requestor/provider (step 824). It is
recognized that the banking service will not issue a payment
voucher if sufficient funds are not in the consumer's account to
cover the request, and all other outstanding payment vouchers that
have been issued, so the account balance amount is checked (step
826). If sufficient funds are not available to cover the
transaction, the consumer may be given the opportunity to replenish
the funds prior to the payment process ending (step 828). If the
consumer refuses to authorize the request, then the payment process
is immediately terminated and a denial is sent to the
requestor/provider (step 830). If the consumer deposits sufficient
funds into the central banking service account to cover the payment
request, the payment process reverts to step 824 where the payment
agent is notified that the funds were deposited and which again
authorizes the central banking service to issue a payment (step
824); funds should then be available (step 826). Then, a balance
amount is returned from the banking service and compared to the
minimum balance threshold (step 832). Alternatively, the payment
agent may keep a balance record, in which case the payment amount
is subtracted from the record and the current balance is
determined. In either case, if the balance is below the minimum
balance threshold, the consumer is warned in a pop-up window that
the balance amount in the account is below the threshold amount and
the funds amount may need replenishing (step 834). Regardless of
whether or not the consumer's account balance is above or below the
minimum balance threshold, as long a sufficient funds are available
in the account, a request for creating a voucher is authorized
(step 836). The process ends.
[0082] Returning to step 804, if the type of service is authorized
under the payment policy, then the requested payment amount is
compared to the maximum amount authorized for the payment agent to
authorize without consumer intervention (step 808). If the
requested amount is above the maximum threshold amount, the request
is passed to the consumer for manual intervention as described
above. A pop-up window is displayed (step 820) for authorizing the
requested payment (step 822), and if the payment request is
manually authorized, the payment agent authorizes the central
banking service to issue a payment voucher (step 824). Once again,
the banking service determines if sufficient funds are available in
the consumer's account to cover the request prior to actually
issuing a voucher (step 824). If not, the consumer is invited to
replenish the account. If sufficient funds are available or are
deposited, the process continues with the account balance amount
being compared to the minimum balance threshold (step 832) and the
consumer is warned if the account balance amount is below the
threshold amount (step 834). If, as step 832 consumer's account
balance is above the minimum balance threshold, the funds
replenishment warning to the consumer is omitted. Finally, a
request for creating a voucher is authorized (step 836) and the
process ends. However, if at step 826 sufficient funds are not
available in the consumer's account, and the consumer chooses not
to replenish the account (step 828), a denial is sent to the
requestor/provider (step 830) and the process ends.
[0083] Returning to step 808, if the requested payment amount is
below the threshold amount, then the payment agent determines if
the recent pay out rate is below the pay out rate threshold for a
predefined time period. Initially, the requested amount is added to
the amount paid out over the pre-set time period (step 810) and the
spending rate is compared to the threshold spending rate (step
812). If the recent pay out rate is above the pay out rate
threshold, then the consumer must intervene as described above in
accordance with process steps 820-836. If, on the other hand, the
recent pay out rate is determined to be an amount below the
threshold spending rate, then the payment agent can autonomously
request the issuance of a payment voucher from the banking service
without intervention from the consumer (step 824). The banking
service verifies that funds are available in the consumer's account
to cover the requested payment amount (and the sum of all
outstanding vouchers) and the new balance amount is compared to the
minimum account balance threshold (step 832). The consumer is
warned if the balance amount in the account is below the threshold
amount (step 834), but in either case, a request for voucher
creation authorized (step 836) and the process ends. If, at step
826 the banking service determines that the consumer's account does
not have sufficient funds available, then the consumer may be
allowed to replenish the account in the manner described above, and
the process may or may not continue based on the consumer's
action.
[0084] This policy based approach allows the consumer to freely and
conveniently use any services they desire that are offered on the
chains of a service economy platform without worry of excessive
losses, and without the need to keep looking at a ticking meter.
The approach allows low valued services to be consumed that extract
very small fractions of a cent payment: the payment agent will just
pay out on demand for these tiny amounts. But whenever a sizable
payment is required, a pop-up panel will require user confirmation
before proceeding with payment. And if average spending rates are
exceeded, the user can be reminded that they are exceeding their
desired high-water mark. The consumer may even configure policy to
be more assertive, and completely bar all payments if average
spending exceeds a second higher water mark.
[0085] With this approach, the market is encouraged to provide a
lot of small services that charge fractional dollar or fractional
cent amounts. The consumer can make use of them without giving a
second thought to their cost or being hassled with prompts. But at
the same time, the vendor can potentially make a sizable profit if
millions of consumers make use of the service. Thus, this approach
gets around an impasse that has been a part of the Internet and
World Wide Web so far, wherein services that might be of value, but
for which consumers would not be willing to spend credit-card sized
fees of a few dollars (or go through the hassle of payment forms);
should out of necessity be given away.
[0086] The corresponding structures, materials, acts, and
equivalents of all means or step plus function elements in the
claims below are intended to include any structure, material, or
act for performing the function in combination with other claimed
elements as specifically claimed. The description of the present
invention has been presented for purposes of illustration and
description, but is not intended to be exhaustive or limited to the
invention in the form disclosed. Many modifications and variations
will be apparent to those of ordinary skill in the art. The
embodiment was chosen and described in order to best explain the
principles of the invention and the practical application, and to
enable others of ordinary skill in the art to understand the
invention for various embodiments with various modifications as are
suited to the particular use contemplated.
* * * * *