System and method for implementing frictionless micropayments for consumable services
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.
[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.
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.
Type: Application
Filed: Nov 12, 2002
Publication Date: Jul 3, 2003
Inventors: James A. Roberson (The Woodlands, TX), William Sprott Greene (Fairview, TX)
Application Number: 10292118
