US20030126079A1 - System and method for implementing frictionless micropayments for consumable services - Google Patents

System and method for implementing frictionless micropayments for consumable services Download PDF

Info

Publication number
US20030126079A1
US20030126079A1 US10/292,118 US29211802A US2003126079A1 US 20030126079 A1 US20030126079 A1 US 20030126079A1 US 29211802 A US29211802 A US 29211802A US 2003126079 A1 US2003126079 A1 US 2003126079A1
Authority
US
United States
Prior art keywords
payment
user
instructions
policy criteria
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/292,118
Inventor
James Roberson
William Greene
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verizon Patent and Licensing Inc
Original Assignee
Worldcom Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US10/292,118 priority Critical patent/US20030126079A1/en
Application filed by Worldcom Inc filed Critical Worldcom Inc
Assigned to WORLDCOM, INC. reassignment WORLDCOM, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GREENE, WILLIAM SPROTT
Assigned to WORLDCOM, INC. reassignment WORLDCOM, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROBERTSON, JAMES A.
Publication of US20030126079A1 publication Critical patent/US20030126079A1/en
Assigned to VERIZON BUSINESS GLOBAL LLC reassignment VERIZON BUSINESS GLOBAL LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI, LLC
Assigned to MCI, LLC reassignment MCI, LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: MCI, INC.
Assigned to MCI, INC. reassignment MCI, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: WORLDCOM, INC.
Assigned to MCI, LLC reassignment MCI, LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: MCI, INC.
Assigned to VERIZON BUSINESS GLOBAL LLC reassignment VERIZON BUSINESS GLOBAL LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI, LLC
Assigned to MCI, INC. reassignment MCI, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: WORLDCOM, INC.
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERIZON BUSINESS GLOBAL LLC
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: VERIZON BUSINESS GLOBAL LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment schemes or models characterised by micropayments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • these consumables come at a cost that must be paid to ensure their continued availability.
  • transaction costs on a per transaction event basis may be greatly reduced when customers and the providers agree in advance on an acceptable conduct.
  • risk and the uncertainty associated with risk are also reduced when parties engage in multiple transactions.
  • 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.
  • Subsidies 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.
  • content subsidies are in one of two types: advertisements; and third-party subscriptions which are described below in detail.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • micropayments 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.
  • a micropayment payment model 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.
  • 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.
  • pay-as-you-use services such as water, sewage, electricity, gas, long distance, cell minutes, etc.
  • prior art Internet micropayment models have been based on those well accepted concepts.
  • 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.
  • 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.
  • 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.
  • 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.
  • prior art micropayment systems 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the payment vouchers drawn on the user's account may be issued by the payment agent directly and passed to the provider for payment.
  • 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.
  • the user can invite a provider's application on to the user's device.
  • 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.
  • 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.
  • the payment agent 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • FIG. 6 is flowchart depicting a process for instantiating a policy based payment agent in accordance with an exemplary embodiment of the present invention
  • FIG. 7 depicts a flowchart of the payment process implemented by the payment agent in accordance with an exemplary embodiment of the present invention.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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 .
  • 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 .
  • 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.
  • 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 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.
  • 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.
  • Chappy invites ZebraSoftware application Z 310 to execute on Chappy's computer 300 .
  • 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 .
  • Protocol 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
  • 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.
  • micropayment systems 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • HTTP Hypertext Transfer Protocol
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • 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 .
  • 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.
  • voucher 404 may identify the supplier of application 410 as the recipient of the funds, such as vendor ZebraSoft.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • central banking service 460 accrues the service charge by virtue of holding less total obligations to the account holders.
  • 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.
  • 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.
  • the agent 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.
  • 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.
  • payment agent 506 is local on user machine 502 , as is payment policy 508 .
  • 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.
  • the payment agent and/or payment policy may be located anywhere in extended network 526 .
  • 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.
  • remote payment agent 516 connects to payment policy database 538 once the user's secret code is authenticated by remote payment agent 516 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payment agent can form a payment decision based on the payment policy specified by the consumer.
  • 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.
  • 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.
  • the tally of outstanding voucher obligations needs to be debited, as well as the funds account transfer occurring.
  • 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.)
  • 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.
  • 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.
  • 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.
  • the payment agent 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.
  • the consumer's device may have only one instance of a payment agent associated with it which is accessed.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payment request will be passed to the user for direct user interaction.
  • 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.
  • 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 ).
  • step 828 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 ).
  • 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.
  • 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.
  • step 832 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.
  • 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.
  • 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.

Abstract

The present invention is directed to a system, method and software program product for implementing a policy payment agent which, based on policy thresholds set by the consumer, determines whether or not to autonomously issue a payment. Initially, the consumer sets the payment policy through the selection of payment parameters such as the type of consumable or transaction, maximum one-time payment amount, and recent spending rate. If the payment request meets the payment policy criteria, then the payment agent autonomously issues a payment. Otherwise, the request is passed to the user for manual intervention.

Description

    CROSS REFERENCES TO RELATED APPLICATIONS
  • 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.[0001]
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0002]
  • 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. [0003]
  • 2. Description of Related Art [0004]
  • 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. [0005]
  • 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. [0006]
  • 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. [0007]
  • 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: [0008]
  • 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. [0009]
  • 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. [0010]
  • 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. [0011]
  • 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. [0012]
  • 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. [0013]
  • 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. [0014]
  • 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. [0015]
  • 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. [0016]
  • 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. [0017]
  • 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. [0018]
  • 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. [0019]
  • 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. [0020]
  • 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. [0021]
  • 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. [0022]
  • SUMMARY OF THE INVENTION
  • 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. [0023]
  • 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. [0024]
  • 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. [0025]
  • 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. [0026]
  • 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. [0027]
  • 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. [0028]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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: [0029]
  • 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; [0030]
  • 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; [0031]
  • 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; [0032]
  • 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; [0033]
  • 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; [0034]
  • FIG. 6 is flowchart depicting a process for instantiating a policy based payment agent in accordance with an exemplary embodiment of the present invention; [0035]
  • 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 [0036]
  • 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.[0037]
  • Other features of the present invention will be apparent from the accompanying drawings and from the following detailed description. [0038]
  • DETAILED DESCRIPTION OF THE INVENTION
  • 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. [0039]
  • 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' [0040] 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.
  • 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, [0041] 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.
  • 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 [0042] 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.
  • 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. [0043]
  • 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 [0044] 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.
  • In the discussion up to now, a service such as [0045] 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.
  • 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 [0046] Z application 310.
  • 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: [0047]
  • 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. [0048]
  • 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. [0049]
  • 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. [0050]
  • 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. [0051]
  • 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. [0052]
  • 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. [0053]
  • 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. [0054]
  • 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. [0055]
  • 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 [0056] 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.
  • As discussed above, each of these “dollar flows” depicted in the diagrams as [0057] 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.
  • With the above approach to consumer payment for online services, [0058] 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.
  • 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. [0059]
  • 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. [0060]
  • 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 [0061] 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.
  • 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. [0063]
  • 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 [0064] 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).
  • 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 [0065] 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.
  • 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, [0066] central banking service 460 accrues the service charge by virtue of holding less total obligations to the account holders.
  • 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. [0067]
  • Returning to FIG. 5, in accordance with one exemplary embodiment, [0068] 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.
  • 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 [0069] 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.
  • 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 [0070] 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.
  • 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 [0071] 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.
  • 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 [0072] 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.
  • 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. [0073]
  • 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.) [0074]
  • 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 [0075] 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.
  • After the policy parameters are entered, the parameters are checked for their legal implications (step [0076] 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.
  • 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 [0077] 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.
  • With the payment agent and the policy, the payment agent can invoke the payment policy for handling the payment request (step [0078] 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.
  • 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. [0079]
  • 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 [0080] 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.
  • 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 [0081] 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.
  • Returning to step [0082] 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.
  • Returning to step [0083] 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.
  • 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. [0084]
  • 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. [0085]
  • 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. [0086]

Claims (34)

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.
US10/292,118 2001-11-12 2002-11-12 System and method for implementing frictionless micropayments for consumable services Abandoned US20030126079A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/292,118 US20030126079A1 (en) 2001-11-12 2002-11-12 System and method for implementing frictionless micropayments for consumable services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US34495601P 2001-11-12 2001-11-12
US10/292,118 US20030126079A1 (en) 2001-11-12 2002-11-12 System and method for implementing frictionless micropayments for consumable services

Publications (1)

Publication Number Publication Date
US20030126079A1 true US20030126079A1 (en) 2003-07-03

Family

ID=23352823

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/292,118 Abandoned US20030126079A1 (en) 2001-11-12 2002-11-12 System and method for implementing frictionless micropayments for consumable services
US10/292,256 Expired - Fee Related US7194543B2 (en) 2001-11-12 2002-11-12 System and method for creating and managing survivable, service hosting networks

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/292,256 Expired - Fee Related US7194543B2 (en) 2001-11-12 2002-11-12 System and method for creating and managing survivable, service hosting networks

Country Status (4)

Country Link
US (2) US20030126079A1 (en)
EP (1) EP1461679A4 (en)
AU (1) AU2002365037A1 (en)
WO (1) WO2003050648A2 (en)

Cited By (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050051619A1 (en) * 1999-08-19 2005-03-10 Graves Phillip Craig System and method for securely authorizing and distributing stored-value card data
US20050216424A1 (en) * 2004-03-23 2005-09-29 Star Systems, Inc. Transaction system with special handling of micropayment transaction requests
US20070011104A1 (en) * 2003-03-21 2007-01-11 Ebay Inc. Payment transactions via substantially instant communication system
US20070078764A1 (en) * 2005-10-04 2007-04-05 International Business Machines Corporation Scalable lazy payment capture in online commerce systems
US20070108268A1 (en) * 2005-11-15 2007-05-17 Graves Phillip C Temporary value card method and system
US20070143177A1 (en) * 2005-12-16 2007-06-21 Graves Phillip C Rebate card system
US20070143180A1 (en) * 2005-12-16 2007-06-21 Graves Phillip C Multiple use rebate card
WO2007149785A2 (en) * 2006-06-19 2007-12-27 Visa U.S.A. Inc. Portable consumer device verification system
US20080003977A1 (en) * 2005-03-23 2008-01-03 Chakiris Phil M Delivery of Value Identifiers Using Short Message Service (SMS)
US20080033877A1 (en) * 2006-08-03 2008-02-07 First Data Corporation Money transfer transactions via pre-paid wireless communication devices
US20080172331A1 (en) * 2007-01-16 2008-07-17 Graves Phillip C Bill Payment Card Method and System
US7437328B2 (en) * 2003-11-14 2008-10-14 E2Interactive, Inc. Value insertion using bill pay card preassociated with biller
US20080307107A1 (en) * 2007-06-08 2008-12-11 At&T Knowledge Ventures, Lp Peer-to-peer distributed storage for internet protocol television
US20080319836A1 (en) * 2007-06-20 2008-12-25 Cvon Innovations Limited Method and system for delivering advertisements to mobile terminals
US20090076904A1 (en) * 2007-09-17 2009-03-19 Frank David Serena Embedding digital values for digital exchange
US20090171842A1 (en) * 2007-12-27 2009-07-02 Mastercard International, Inc. Techniques For Conducting Financial Transactions Using Mobile Communication Devices
US20100169216A1 (en) * 2006-07-06 2010-07-01 Moneygram International, Inc. Systems and methods for processing payments with payment review features
US20100319004A1 (en) * 2009-06-16 2010-12-16 Microsoft Corporation Policy Management for the Cloud
US20100332384A1 (en) * 2003-03-21 2010-12-30 Ebay Inc. Transaction aggregation engine
US20110066517A1 (en) * 2007-01-16 2011-03-17 Merrill Brooks Smith Systems and methods for the payment of customer bills utilizing payment platform of biller
US20110082789A1 (en) * 2009-10-06 2011-04-07 Apple Inc. Vendor payment consolidation system
US20110184868A1 (en) * 2008-01-31 2011-07-28 Bill.Com, Inc. Enhanced invitation process for electronic billing and payment system
US20110184843A1 (en) * 2008-01-31 2011-07-28 Bill.Com, Inc. Enhanced electronic anonymous payment system
US20110196786A1 (en) * 2008-01-31 2011-08-11 Rene Lacerte Determining trustworthiness and familiarity of users of an electronic billing and payment system
US20110213710A1 (en) * 2008-02-05 2011-09-01 Bank Of America Corporation Identification of customers and use of virtual accounts
CN102196035A (en) * 2010-03-18 2011-09-21 微软公司 Unified web service discovery
US20110270698A1 (en) * 2010-05-03 2011-11-03 Masher Media Inc. Providing a Conditional Allowance Within a Virtual Space
US20120054853A1 (en) * 2010-08-24 2012-03-01 International Business Machines Corporation Systems and methods to control device endpoint behavior using personae and policies
US20120130853A1 (en) * 2010-11-24 2012-05-24 Digital River, Inc. In-Application Commerce System and Method with Fraud Detection
US20120222094A1 (en) * 2010-12-29 2012-08-30 Uwe Huebler Method and arrangement for enabling the use of a consumable unit
US8406792B2 (en) 2006-11-27 2013-03-26 Apple Inc. Message modification system and method
US20130080327A1 (en) * 2011-09-23 2013-03-28 Mark Baldrick Automatic refresh authorization for expired payment transaction authorizations
US8510658B2 (en) 2010-08-11 2013-08-13 Apple Inc. Population segmentation
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US8819789B2 (en) 2012-03-07 2014-08-26 Bill.Com, Inc. Method and system for using social networks to verify entity affiliations and identities
US8935718B2 (en) 2007-05-22 2015-01-13 Apple Inc. Advertising management method and system
US8949342B2 (en) 2006-08-09 2015-02-03 Apple Inc. Messaging system
US9141991B2 (en) 2008-01-31 2015-09-22 Bill.Com, Inc. Enhanced electronic data and metadata interchange system and process for electronic billing and payment system
US9256867B2 (en) 2005-03-23 2016-02-09 E2Interactive, Inc. Delivery of value identifiers using short message service (SMS)
US9569769B2 (en) 2012-09-17 2017-02-14 E2Interactive, Inc. Composite activation indicia substrate
US9633347B2 (en) 2012-05-04 2017-04-25 e2interactive. Inc Systems and/or methods for selling non-inventory items at point-of-sale (POS) locations
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US9846871B2 (en) 2010-04-12 2017-12-19 E2Interactive, Inc. Systems and/or methods for determining item serial number structure and intelligence
US10063714B2 (en) 2001-09-24 2018-08-28 E2Interactive, Inc. Inserting value into customer account at point of sale using a customer account identifier
US10068287B2 (en) 2010-06-11 2018-09-04 David A. Nelsen Systems and methods to manage and control use of a virtual card
US10074113B2 (en) 2011-09-07 2018-09-11 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US10079811B2 (en) 2011-09-07 2018-09-18 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10115137B2 (en) 2013-03-14 2018-10-30 Bill.Com, Inc. System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US10152614B2 (en) 2003-11-14 2018-12-11 E2Interactive, Inc. Systems and methods for electronic device point-of-sale activation
US10163080B2 (en) 2015-08-13 2018-12-25 The Toronto-Dominion Bank Document tracking on a distributed ledger
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US10198729B2 (en) 2011-09-07 2019-02-05 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10263936B2 (en) 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner
US10296916B2 (en) 2009-09-11 2019-05-21 Maridee Joy Maraz System and/or method for handling recalled product purchases and/or return/warranty requests
US10410191B2 (en) 2013-03-14 2019-09-10 Bill.Com, Llc System and method for scanning and processing of payment documentation in an integrated partner platform
US10410192B2 (en) * 2015-09-29 2019-09-10 Ncr Corporation User interface for controlling multiple devices
US10417674B2 (en) 2013-03-14 2019-09-17 Bill.Com, Llc System and method for sharing transaction information by object tracking of inter-entity transactions and news streams
US10445743B2 (en) 2001-11-15 2019-10-15 E2Interactive, Inc. Non-serialized electronic product registration system and method of operating same
US10498827B2 (en) 2016-09-30 2019-12-03 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US10546306B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10572921B2 (en) 2013-07-03 2020-02-25 Bill.Com, Llc System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US10586219B2 (en) 2015-08-13 2020-03-10 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US10769686B2 (en) 2008-01-31 2020-09-08 Bill.Com Llc Enhanced invitation process for electronic billing and payment system
US10861012B2 (en) 2010-09-30 2020-12-08 The Western Union Company System and method for secure transactions at a mobile device
US10937076B2 (en) 2010-10-13 2021-03-02 E2Interactive, Inc. Online personalized gifting system
US10954049B2 (en) 2017-12-12 2021-03-23 E2Interactive, Inc. Viscous liquid vessel for gifting
CN112688998A (en) * 2020-12-17 2021-04-20 中国航空工业集团公司成都飞机设计研究所 Configurable main data subscription pushing method with permission
US11017443B2 (en) 2014-04-30 2021-05-25 E2Interactive, Inc. System and method for a merchant onsite personalization gifting platform
US11111065B2 (en) 2013-02-15 2021-09-07 E2Interactive, Inc. Gift card presentation devices
US11120428B2 (en) 2013-05-02 2021-09-14 E2Interactive, Inc. Stored value card kiosk system and method
US11144989B1 (en) * 2017-03-07 2021-10-12 Wells Fargo Bank, N.A. Customized graphical user interface for managing multiple user accounts
US20210326960A1 (en) * 2020-04-16 2021-10-21 Bank Of Montreal Artificial intelligence modeling to predict electronic account data
US11182836B2 (en) 2010-10-13 2021-11-23 E2Interactive, Inc. Gift card ordering system and method
US11219288B2 (en) 2013-02-15 2022-01-11 E2Interactive, Inc. Gift card box with slanted tray and slit
US11392905B2 (en) * 2009-12-23 2022-07-19 Aristocrat Technologies Australia Pty Limited System and method for cashless gaming
US11436651B2 (en) 2012-01-30 2022-09-06 E2Interactive, Inc. Group video generating system
US11900346B1 (en) * 2019-08-22 2024-02-13 Wells Fargo Bank, N.A. Apparatuses and methods for payment for consumable content
US11928696B2 (en) 2009-12-16 2024-03-12 E2Interactive, Inc. Systems and methods for generating a virtual value item for a promotional campaign

Families Citing this family (192)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1430758A (en) * 2000-05-22 2003-07-16 阿德特姆软件公司 Revenue forecasting and managing sellers using statistical analysis
US6922685B2 (en) * 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
US7130822B1 (en) 2000-07-31 2006-10-31 Cognos Incorporated Budget planning
US7249195B2 (en) 2001-03-30 2007-07-24 Minor Ventures, Llc Apparatus and methods for correlating messages sent between services
WO2003051014A2 (en) * 2001-12-11 2003-06-19 British Telecommunications Public Limited Company Event notification over a communications network
US20040019465A1 (en) * 2002-05-13 2004-01-29 Kerr James W. Event router and method for handling events in distributing computing applications
US7747730B1 (en) * 2002-06-28 2010-06-29 Netfuel, Inc. Managing computer network resources
JP4240930B2 (en) * 2002-07-15 2009-03-18 株式会社日立製作所 Method and apparatus for unifying temporary transmission of multiple network storages
US20040019640A1 (en) * 2002-07-25 2004-01-29 Bartram Linda Ruth System and method for distributing shared storage for collaboration across multiple devices
US7234137B2 (en) * 2002-07-25 2007-06-19 Sun Microsystems, Inc. Method, system, and program for processing objects in a distributed computing environment
US7146389B2 (en) * 2002-08-30 2006-12-05 Hitachi, Ltd. Method for rebalancing free disk space among network storages virtualized into a single file system view
EP1546965A4 (en) * 2002-09-30 2005-11-02 Adaytum Inc Node-level modification during execution of an enterprise planning model
US7072822B2 (en) * 2002-09-30 2006-07-04 Cognos Incorporated Deploying multiple enterprise planning models across clusters of application servers
US7257612B2 (en) * 2002-09-30 2007-08-14 Cognos Incorporated Inline compression of a network communication within an enterprise planning environment
US6768995B2 (en) * 2002-09-30 2004-07-27 Adaytum, Inc. Real-time aggregation of data within an enterprise planning environment
FR2846839B1 (en) * 2002-10-31 2005-01-21 Thales Sa METHOD FOR ALLOCATING ACCESS IN A PARTIALLY CONNECTED NETWORK
US7376733B2 (en) * 2003-02-03 2008-05-20 Hewlett-Packard Development Company, L.P. Method and apparatus and program for scheduling and executing events in real time over a network
US7155398B2 (en) * 2003-02-19 2006-12-26 Cognos Incorporated Cascaded planning of an enterprise planning model
US7756901B2 (en) 2003-02-19 2010-07-13 International Business Machines Corporation Horizontal enterprise planning in accordance with an enterprise planning model
US7284054B2 (en) * 2003-04-11 2007-10-16 Sun Microsystems, Inc. Systems, methods, and articles of manufacture for aligning service containers
US20050021836A1 (en) * 2003-05-01 2005-01-27 Reed Carl J. System and method for message processing and routing
US7363508B2 (en) * 2003-05-21 2008-04-22 Palo Alto Research Center Incorporated System and method for dynamically enabling components to implement data transfer security mechanisms
US7702668B2 (en) * 2003-06-16 2010-04-20 Microsoft Corporation Asset composition
US20040260946A1 (en) * 2003-06-20 2004-12-23 Cahill Conor P. User not present
JP4694482B2 (en) * 2003-07-24 2011-06-08 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Complex device and individual-based authorized domain architecture
US20050114469A1 (en) * 2003-09-16 2005-05-26 Manabu Nakamura Information processing apparatus with a network service function and method of providing network services
WO2005043262A2 (en) * 2003-10-20 2005-05-12 Sensorlogic, Inc. Behavior agent based system and process for machine to machine applications and services
US20050125487A1 (en) * 2003-11-26 2005-06-09 O'connor Neil Method and system for distributing contacts within a network
US7966294B1 (en) * 2004-01-08 2011-06-21 Netapp, Inc. User interface system for a clustered storage system
US7490183B2 (en) * 2004-02-12 2009-02-10 International Business Machines Corporation Information kit integration architecture for end-user systems
CN1668014A (en) 2004-03-12 2005-09-14 国际商业机器公司 Auto-restored composite network service method and device
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
US8533737B2 (en) * 2004-03-18 2013-09-10 Global Infotek, Inc. System and method for interfacing distributed systems with different frameworks
US7739351B2 (en) 2004-03-23 2010-06-15 Salesforce.Com, Inc. Synchronous interface to asynchronous processes
US8549541B2 (en) * 2004-03-26 2013-10-01 Intellectual Ventures Ii Llc Bridging local device communications across the wide area
US8200823B1 (en) * 2004-03-30 2012-06-12 Oracle America, Inc. Technique for deployment and management of network system management services
US7865617B1 (en) * 2004-06-10 2011-01-04 Infoblox Inc. Maintaining consistency in a database
US7802007B2 (en) 2004-05-19 2010-09-21 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US20050273668A1 (en) * 2004-05-20 2005-12-08 Richard Manning Dynamic and distributed managed edge computing (MEC) framework
US8943050B2 (en) * 2004-05-21 2015-01-27 Ca, Inc. Method and apparatus for optimizing directory performance
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US7426657B2 (en) * 2004-07-09 2008-09-16 International Business Machines Corporation System and method for predictive processor failure recovery
US7213199B2 (en) * 2004-07-16 2007-05-01 Cognos Incorporated Spreadsheet user-interface for an enterprise planning system having multi-dimensional data store
US20060031476A1 (en) * 2004-08-05 2006-02-09 Mathes Marvin L Apparatus and method for remotely monitoring a computer network
US7725605B2 (en) * 2004-08-06 2010-05-25 Salesforce.Com, Inc. Providing on-demand access to services in a wide area network
US7873832B2 (en) * 2004-08-19 2011-01-18 Microsoft Corporation Mechanism for secure participation in a transaction by a third party
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US8281002B1 (en) * 2004-09-21 2012-10-02 Qurio Holdings, Inc. Method and system for providing notification of the availability of a peer computer in a peer-to-peer network
US7415021B1 (en) * 2004-09-22 2008-08-19 Sun Microsystems, Inc. Method and apparatus for preserving null semantics during use of a forwarding method
US7584245B2 (en) * 2004-09-29 2009-09-01 Microsoft Corporation Web service generation
CA2827035A1 (en) 2004-11-08 2006-05-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
GB0501697D0 (en) * 2005-01-27 2005-03-02 Ibm Controlling service failover in clustered storage apparatus networks
KR100715846B1 (en) * 2005-02-14 2007-05-10 삼성전기주식회사 A method for application reconfiguration using subtyping-based flexible service adaptation in pervasive computing environment and system thereof
US7886295B2 (en) * 2005-02-17 2011-02-08 International Business Machines Corporation Connection manager, method, system and program product for centrally managing computer applications
US20060200705A1 (en) * 2005-03-07 2006-09-07 International Business Machines Corporation Method, system and program product for monitoring a heartbeat of a computer application
US9075657B2 (en) 2005-04-07 2015-07-07 Adaptive Computing Enterprises, Inc. On-demand access to compute resources
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
WO2008036058A2 (en) 2005-03-16 2008-03-27 Cluster Resources, Inc. On-demand computing environment
US20060230118A1 (en) * 2005-04-12 2006-10-12 Digi Chain Information Co., Ltd. Share memory service system and method of web service oriented applications
CA2600503C (en) * 2005-04-18 2012-10-09 Research In Motion Limited Method and system for executing a container-managed application on a processing device
US7506204B2 (en) * 2005-04-25 2009-03-17 Microsoft Corporation Dedicated connection to a database server for alternative failure recovery
US20070005725A1 (en) * 2005-06-30 2007-01-04 Morris Robert P Method and apparatus for browsing network resources using an asynchronous communications protocol
US9418040B2 (en) * 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
US20070043646A1 (en) * 2005-08-22 2007-02-22 Morris Robert P Methods, systems, and computer program products for conducting a business transaction using a pub/sub protocol
WO2007039337A1 (en) * 2005-09-29 2007-04-12 International Business Machines Corporation System and method for automatically managing it-resources in a heterogeneous environment
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7930363B2 (en) * 2005-10-12 2011-04-19 Powerreviews, Inc. Application service provider delivery system
WO2007123580A2 (en) * 2005-11-09 2007-11-01 Computer Associates Think, Inc. System and method for routing directory service operations in a directory service network
US8326899B2 (en) 2005-11-09 2012-12-04 Ca, Inc. Method and system for improving write performance in a supplemental directory
US8572201B2 (en) * 2005-11-09 2013-10-29 Ca, Inc. System and method for providing a directory service network
US8478898B2 (en) * 2005-11-09 2013-07-02 Ca, Inc. System and method for routing directory service operations in a directory service network
US20070112791A1 (en) * 2005-11-09 2007-05-17 Harvey Richard H Method and system for providing enhanced read performance for a supplemental directory
US8321486B2 (en) * 2005-11-09 2012-11-27 Ca, Inc. Method and system for configuring a supplemental directory
US8458176B2 (en) 2005-11-09 2013-06-04 Ca, Inc. Method and system for providing a directory overlay
US9922031B2 (en) * 2005-11-09 2018-03-20 Ca, Inc. System and method for efficient directory performance using non-persistent storage
US7945816B1 (en) 2005-11-30 2011-05-17 At&T Intellectual Property Ii, L.P. Comprehensive end-to-end storage area network (SAN) application transport service
US8010701B2 (en) 2005-12-19 2011-08-30 Vmware, Inc. Method and system for providing virtualized application workspaces
US8935429B2 (en) 2006-12-19 2015-01-13 Vmware, Inc. Automatically determining which remote applications a user or group is entitled to access based on entitlement specifications and providing remote application access to the remote applications
US20070150441A1 (en) * 2005-12-23 2007-06-28 Morris Robert P Methods, systems, and computer program products for associating policies with tuples using a pub/sub protocol
US7512880B2 (en) * 2005-12-23 2009-03-31 Swift Creek Systems, Llc Method and system for presenting published information in a browser
US8073929B2 (en) * 2005-12-29 2011-12-06 Panasonic Electric Works Co., Ltd. Systems and methods for managing a provider's online status in a distributed network
US7979733B2 (en) 2005-12-30 2011-07-12 Sap Ag Health check monitoring process
US7930681B2 (en) * 2005-12-30 2011-04-19 Sap Ag Service and application management in information technology systems
US20070174232A1 (en) * 2006-01-06 2007-07-26 Roland Barcia Dynamically discovering subscriptions for publications
US20070218446A1 (en) * 2006-03-03 2007-09-20 Burck Smith Student interaction management system
US8892509B2 (en) * 2006-03-28 2014-11-18 Oracle America, Inc. Systems and methods for a distributed in-memory database
US20070257354A1 (en) * 2006-03-31 2007-11-08 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Code installation decisions for improving aggregate functionality
ATE468556T1 (en) * 2006-04-13 2010-06-15 Microsoft Corp VIRTUAL EXECUTION SYSTEM FOR RESOURCE LIMITED DEVICES
US7747785B2 (en) * 2006-04-14 2010-06-29 Microsoft Corporation Instant messaging plug-ins
CN101094223B (en) * 2006-06-23 2010-12-08 国际商业机器公司 Metod and device for distributing policy in service model facing to service system structural system
US7979320B2 (en) * 2006-08-15 2011-07-12 Microsoft Corporation Automated acquisition and configuration of goods and services via a network
US8090766B2 (en) * 2006-08-15 2012-01-03 Microsoft Corporation System and method to identify, rank, and audit network provided configurables
US8055747B2 (en) * 2006-08-15 2011-11-08 Microsoft Corporation Message based network transmission for selection and auditing of internet services
US7861213B2 (en) * 2006-09-05 2010-12-28 Oracle International Corporation Mechanism for developing AJax applications using java swing framework and method for using the same
US20080066067A1 (en) * 2006-09-07 2008-03-13 Cognos Incorporated Enterprise performance management software system having action-based data capture
US8627402B2 (en) 2006-09-19 2014-01-07 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US8984579B2 (en) * 2006-09-19 2015-03-17 The Innovation Science Fund I, LLC Evaluation systems and methods for coordinating software agents
US8601530B2 (en) * 2006-09-19 2013-12-03 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US8607336B2 (en) * 2006-09-19 2013-12-10 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US8523069B2 (en) 2006-09-28 2013-09-03 Visa U.S.A. Inc. Mobile transit fare payment
US8118223B2 (en) 2006-09-28 2012-02-21 Visa U.S.A. Inc. Smart sign mobile transit fare payment
US8346639B2 (en) 2007-02-28 2013-01-01 Visa U.S.A. Inc. Authentication of a data card using a transit verification value
US8386349B2 (en) 2007-02-28 2013-02-26 Visa U.S.A. Inc. Verification of a portable consumer device in an offline environment
US20080203170A1 (en) * 2007-02-28 2008-08-28 Visa U.S.A. Inc. Fraud prevention for transit fare collection
US8738485B2 (en) * 2007-12-28 2014-05-27 Visa U.S.A. Inc. Contactless prepaid product for transit fare collection
US7527208B2 (en) * 2006-12-04 2009-05-05 Visa U.S.A. Inc. Bank issued contactless payment card used in transit fare collection
CN100536479C (en) * 2006-10-10 2009-09-02 华为技术有限公司 Service establishing, executing, mapping system and method
US9330190B2 (en) 2006-12-11 2016-05-03 Swift Creek Systems, Llc Method and system for providing data handling information for use by a publish/subscribe client
US9009187B2 (en) * 2006-12-19 2015-04-14 Ianywhere Solutions, Inc. Assigning tasks to threads requiring limited resources using programmable queues
US20080282262A1 (en) * 2007-05-10 2008-11-13 Microsoft Corporation Automatic and configurable loading of loosely coupled service oriented software components
US8898277B2 (en) * 2007-06-08 2014-11-25 Oracle International Corporation Performance monitoring infrastructure for distributed transaction service
US7689689B2 (en) * 2007-06-11 2010-03-30 Air Products And Chemicals, Inc. Protection of industrial equipment from network storms emanating from a network system
US20090077480A1 (en) * 2007-06-19 2009-03-19 Caunter Mark Leslie Apparatus and method of managing electronic communities of users
US20090063423A1 (en) * 2007-06-19 2009-03-05 Jackson Bruce Kelly User interfaces for service object located in a distributed system
US20090037588A1 (en) * 2007-07-31 2009-02-05 Morris Robert P Method And System For Providing Status Information Of At Least Two Related Principals
US8386630B1 (en) 2007-09-09 2013-02-26 Arris Solutions, Inc. Video-aware P2P streaming and download with support for real-time content alteration
US9262127B2 (en) * 2007-09-10 2016-02-16 Oracle International Corporation System and method for an infrastructure that enables provisioning of dynamic business applications
US8683033B2 (en) * 2007-09-17 2014-03-25 International Business Machines Corporation Apparatus, system, and method for server failover to standby server during broadcast storm or denial-of-service attack
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US7908363B2 (en) * 2007-10-23 2011-03-15 Yahoo! Inc. Call limiter for web services
US8577837B2 (en) * 2007-10-30 2013-11-05 Sap Ag Method and system for generic extraction of business object data
US9756004B2 (en) 2007-11-08 2017-09-05 Skype Message delivery system and method
US8769346B2 (en) * 2007-11-21 2014-07-01 Ca, Inc. Method and apparatus for adaptive declarative monitoring
US20090138620A1 (en) * 2007-11-27 2009-05-28 Boeing Company Apparatus and method facilitating web service communications between networks
NZ585054A (en) * 2007-11-30 2013-08-30 Ericsson Telefon Ab L M Key management for secure communication
US8244827B2 (en) * 2007-12-19 2012-08-14 International Business Machines Corporation Transferring a logical partition (‘LPAR’) between two server computing devices based on LPAR customer requirements
US8533453B2 (en) * 2008-03-12 2013-09-10 Go Daddy Operating Company, LLC Method and system for configuring a server and dynamically loading SSL information
US20090235353A1 (en) * 2008-03-15 2009-09-17 Microsoft Corporation Scalable Hosting of User Solutions
US8316101B2 (en) * 2008-03-15 2012-11-20 Microsoft Corporation Resource management system for hosting of user solutions
US8320878B2 (en) * 2008-05-20 2012-11-27 Motorola Mobility Llc Charging system for a communication system
US20090307374A1 (en) * 2008-06-05 2009-12-10 Morris Robert P Method And System For Providing A Subscription To A Tuple Based On A Schema Associated With The Tuple
US20090320097A1 (en) * 2008-06-18 2009-12-24 Jackson Bruce Kelly Method for carrying out a distributed search
US20090319385A1 (en) * 2008-06-18 2009-12-24 Jackson Bruce Kelly Monetizing and prioritizing results of a distributed search
US8060603B2 (en) * 2008-06-18 2011-11-15 Qualcomm Incorporated Persistent personal messaging in a distributed system
US7949894B2 (en) * 2008-08-11 2011-05-24 International Business Machines Corporation Self-healing capabilities in a directory server
US20100050179A1 (en) * 2008-08-22 2010-02-25 Ajay Mohindra Layered capacity driven provisioning in distributed environments
US9218218B2 (en) 2008-08-27 2015-12-22 International Business Machines Corporation Method and system for policy based lifecycle management of virtual software appliances
US10110631B2 (en) * 2009-02-12 2018-10-23 International Business Machines Corporation Introducing encryption, authentication, and authorization into a publication and subscription engine
US8868782B2 (en) * 2009-03-10 2014-10-21 Telefonaktiebolaget L M Ericsson (Publ) System and methods for a managed application server restart
US8369968B2 (en) * 2009-04-03 2013-02-05 Dell Products, Lp System and method for handling database failover
US8327351B2 (en) * 2009-04-30 2012-12-04 Sap Ag Application modification framework
US8359594B1 (en) * 2009-06-30 2013-01-22 Sychron Advanced Technologies, Inc. Automated rapid virtual machine provisioning system
GB0911981D0 (en) * 2009-07-09 2009-08-19 Movix Uk Ltd Data processing system using geographical locations
US7965630B1 (en) 2009-09-08 2011-06-21 Southern Company Services, Inc. Load balancing port proxy for dynamically controlling routing of query requests
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US8700752B2 (en) * 2009-11-03 2014-04-15 International Business Machines Corporation Optimized efficient LPAR capacity consolidation
US8352610B2 (en) * 2009-11-25 2013-01-08 International Business Machines Corporation Matching interest and availability of services in distributed federated service domains
US8234515B2 (en) * 2010-04-01 2012-07-31 Accenture Global Services Limited Repurposable recovery environment
US9367359B2 (en) 2010-06-30 2016-06-14 International Business Machines Corporation Optimized resource management for map/reduce computing
US20120016999A1 (en) * 2010-07-14 2012-01-19 Sap Ag Context for Sharing Data Objects
US9240965B2 (en) 2010-08-31 2016-01-19 Sap Se Methods and systems for business interaction monitoring for networked business process
JP5743469B2 (en) * 2010-09-22 2015-07-01 キヤノン株式会社 Information processing apparatus, control method thereof, and control program
US20120124193A1 (en) 2010-11-12 2012-05-17 International Business Machines Corporation Identification of Critical Web Services and their Dynamic Optimal Relocation
JP5845571B2 (en) * 2010-11-30 2016-01-20 富士通株式会社 Calculation system and calculation system management method
US20120158553A1 (en) * 2010-12-17 2012-06-21 Yodchai Sudhidhanakul Method and System for Inventory Management Over a Peer-To-Peer Network
US20120239561A1 (en) * 2011-03-14 2012-09-20 Ido Sharon Method and apparatus for unique identification of account and for billing an activity in an open network
US9998545B2 (en) * 2011-04-02 2018-06-12 Open Invention Network, Llc System and method for improved handshake protocol
US20120311016A1 (en) * 2011-06-02 2012-12-06 Recursion Software, Inc. System and method for providing self-healing capabilites in a distributed knowlegde network/intelligent sensor network
US8825748B2 (en) * 2011-07-06 2014-09-02 Sharp Laboratories Of America, Inc. Sandboxed daemon process invocation through HTTP
US8862928B2 (en) * 2011-09-20 2014-10-14 Cloudbyte, Inc. Techniques for achieving high availability with multi-tenant storage when a partial fault occurs or when more than two complete faults occur
US10579982B2 (en) 2012-01-03 2020-03-03 International Business Machines Corporation Identifying money laundering in micro-commerce
GB2507338A (en) * 2012-10-26 2014-04-30 Ibm Determining system topology graph changes in a distributed computing system
US20140365269A1 (en) * 2013-06-10 2014-12-11 Internationl Business Machines Corporation Failure prediction based preventative maintenance planning on asset network system
US10333789B1 (en) * 2013-12-18 2019-06-25 Amazon Technologies, Inc. Client-directed placement of remotely-configured service instances
US9582677B2 (en) * 2014-02-20 2017-02-28 International Business Machines Corporation Dynamic storlets in storage system data path
US9864861B2 (en) * 2014-03-27 2018-01-09 Intel Corporation Object oriented marshaling scheme for calls to a secure region
US9742692B2 (en) * 2014-06-23 2017-08-22 Microsoft Technology Licensing, Llc Acquiring resource lease using multiple lease servers
US10587698B2 (en) * 2015-02-25 2020-03-10 Futurewei Technologies, Inc. Service function registration mechanism and capability indexing
EP3366056B1 (en) * 2015-10-20 2019-06-05 Telefonaktiebolaget LM Ericsson (publ) User profiling prevention in personal area network communication
US11102103B2 (en) * 2015-11-23 2021-08-24 Bank Of America Corporation Network stabilizing tool
US10140066B2 (en) * 2016-02-01 2018-11-27 International Business Machines Corporation Smart partitioning of storage access paths in shared storage services
JP6717067B2 (en) * 2016-06-13 2020-07-01 富士通株式会社 Handling history analysis program, method, and device
US10713072B1 (en) 2016-06-27 2020-07-14 Amazon Technologies, Inc. Computing resource provisioning
US10701160B2 (en) * 2016-07-28 2020-06-30 Polybit Inc. System and method for a unified interface to networked webservices
US10237339B2 (en) 2016-08-19 2019-03-19 Microsoft Technology Licensing, Llc Statistical resource balancing of constrained microservices in cloud PAAS environments
US10013275B2 (en) 2016-11-17 2018-07-03 Red Hat, Inc. Executing code referenced from a microservice registry
US11138030B2 (en) 2016-11-17 2021-10-05 Red Hat, Inc. Executing code referenced from a microservice registry
US10616037B2 (en) * 2017-04-25 2020-04-07 International Business Machines Corporation Devices demise actions and notification
US11023885B2 (en) * 2017-06-30 2021-06-01 Marqeta, Inc. System, method, and computer program for securely transmitting and presenting payment card data in a web client
US11416616B2 (en) 2017-11-30 2022-08-16 Forcepoint Llc Secure boot chain for live boot systems
US11693832B2 (en) * 2018-03-15 2023-07-04 Vmware, Inc. Flattening of hierarchical data into a relational schema in a computing system
US10511520B1 (en) * 2018-05-29 2019-12-17 Ripple Labs Inc. Multi-hop path finding
US10757215B2 (en) 2018-09-13 2020-08-25 Pivotal Software, Inc. Allocation of computing resources for a computing system hosting multiple applications
GB2586913B (en) * 2020-06-05 2021-11-10 Iotech Systems Ltd Data processing
US11695774B2 (en) 2020-06-24 2023-07-04 Polybit Inc. System and method for federated identity functionality for API development
US20220122111A1 (en) * 2020-10-19 2022-04-21 Nurture Financial Services, Llc Computation server system and method for user-specific processing
US11777863B2 (en) * 2020-12-21 2023-10-03 Landis+ Gyr Innovations Optimized route for time-critical traffic in mesh network
US11343344B1 (en) * 2021-04-23 2022-05-24 Akamai Technologies, Inc. Proxy server entity transfer modes
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
US20230039426A1 (en) * 2021-08-04 2023-02-09 International Business Machines Corporation Intelligent request routing within service mesh

Citations (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5715314A (en) * 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US5848400A (en) * 1996-07-01 1998-12-08 Sun Microsystems, Inc. Electronic check exchange, clearing and settlement system
US5890138A (en) * 1996-08-26 1999-03-30 Bid.Com International Inc. Computer auction system
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US5905736A (en) * 1996-04-22 1999-05-18 At&T Corp Method for the billing of transactions over the internet
US5956700A (en) * 1994-06-03 1999-09-21 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US6018724A (en) * 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
US6029151A (en) * 1996-12-13 2000-02-22 Telefonaktiebolaget L M Ericsson Method and system for performing electronic money transactions
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US6105008A (en) * 1997-10-16 2000-08-15 Visa International Service Association Internet loading system using smart card
US6115690A (en) * 1997-12-22 2000-09-05 Wong; Charles Integrated business-to-business Web commerce and business automation system
US6173269B1 (en) * 1998-12-16 2001-01-09 Zowi.Com, Inc Method and apparatus for executing electronic commercial transactions with minors
US6223168B1 (en) * 1995-07-25 2001-04-24 Bottomline Technologies, Inc. Automatic remittance delivery system
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US20020055909A1 (en) * 2000-03-01 2002-05-09 Passgate Corporation Method, system and computer readable medium for Web site account and e-commerce management from a central location
US20020069162A1 (en) * 2000-11-15 2002-06-06 Cornelius Boylan Method for payment, user equipment, server, payment system and computer program product
US20020111916A1 (en) * 2001-02-12 2002-08-15 Coronna Mark S. Payment management
US20020111907A1 (en) * 2000-01-26 2002-08-15 Ling Marvin T. Systems and methods for conducting electronic commerce transactions requiring micropayment
US20020128917A1 (en) * 2001-03-06 2002-09-12 Electronic Data Systems Corporation Method and apparatus for processing financial transactions
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
US20020161724A1 (en) * 2001-04-05 2002-10-31 International Business Machines Corporation Enhanced protection for account-based transactions through the use of personal authorization criteria
US6532450B1 (en) * 1998-12-09 2003-03-11 American Management Systems, Inc. Financial management system including an offset payment process
US6598026B1 (en) * 1999-01-25 2003-07-22 Nextag.Com, Inc. Methods and apparatus for brokering transactions
US20030208440A1 (en) * 2000-05-01 2003-11-06 Robert Harada International payment system and method
US6882983B2 (en) * 2001-02-05 2005-04-19 Notiva Corporation Method and system for processing transactions
US20070299742A1 (en) * 2000-08-28 2007-12-27 Javien Digital Payment Solutions, Inc. Third-party billing system and method
US7340518B1 (en) * 2000-07-10 2008-03-04 Jenkins Gerald L Method and system to enable contact with unknown internet account holders
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6446070B1 (en) * 1998-02-26 2002-09-03 Sun Microsystems, Inc. Method and apparatus for dynamic distributed computing over a network
US5987140A (en) * 1996-04-26 1999-11-16 Verifone, Inc. System, method and article of manufacture for secure network electronic payment and credit collection
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
US6061665A (en) * 1997-06-06 2000-05-09 Verifone, Inc. System, method and article of manufacture for dynamic negotiation of a network payment framework
US6374295B2 (en) * 1998-10-29 2002-04-16 Nortel Networks Limited Active server management
US6718486B1 (en) * 2000-01-26 2004-04-06 David E. Lovejoy Fault monitor for restarting failed instances of the fault monitor
US20010032878A1 (en) * 2000-02-09 2001-10-25 Tsiounis Yiannis S. Method and system for making anonymous electronic payments on the world wide web
US6961937B2 (en) * 2001-07-11 2005-11-01 Sun Microsystems, Inc. Registry service for use in a distributed processing framework system and methods for implementing the same

Patent Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5465206A (en) * 1993-11-01 1995-11-07 Visa International Electronic bill pay system
US5956700A (en) * 1994-06-03 1999-09-21 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5715314A (en) * 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US6223168B1 (en) * 1995-07-25 2001-04-24 Bottomline Technologies, Inc. Automatic remittance delivery system
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US5905736A (en) * 1996-04-22 1999-05-18 At&T Corp Method for the billing of transactions over the internet
US5848400A (en) * 1996-07-01 1998-12-08 Sun Microsystems, Inc. Electronic check exchange, clearing and settlement system
US5890138A (en) * 1996-08-26 1999-03-30 Bid.Com International Inc. Computer auction system
US6029151A (en) * 1996-12-13 2000-02-22 Telefonaktiebolaget L M Ericsson Method and system for performing electronic money transactions
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US6018724A (en) * 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
US6105008A (en) * 1997-10-16 2000-08-15 Visa International Service Association Internet loading system using smart card
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US6115690A (en) * 1997-12-22 2000-09-05 Wong; Charles Integrated business-to-business Web commerce and business automation system
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
US6532450B1 (en) * 1998-12-09 2003-03-11 American Management Systems, Inc. Financial management system including an offset payment process
US6173269B1 (en) * 1998-12-16 2001-01-09 Zowi.Com, Inc Method and apparatus for executing electronic commercial transactions with minors
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6598026B1 (en) * 1999-01-25 2003-07-22 Nextag.Com, Inc. Methods and apparatus for brokering transactions
US20020111907A1 (en) * 2000-01-26 2002-08-15 Ling Marvin T. Systems and methods for conducting electronic commerce transactions requiring micropayment
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
US20020055909A1 (en) * 2000-03-01 2002-05-09 Passgate Corporation Method, system and computer readable medium for Web site account and e-commerce management from a central location
US20030208440A1 (en) * 2000-05-01 2003-11-06 Robert Harada International payment system and method
US7340518B1 (en) * 2000-07-10 2008-03-04 Jenkins Gerald L Method and system to enable contact with unknown internet account holders
US20070299742A1 (en) * 2000-08-28 2007-12-27 Javien Digital Payment Solutions, Inc. Third-party billing system and method
US20020069162A1 (en) * 2000-11-15 2002-06-06 Cornelius Boylan Method for payment, user equipment, server, payment system and computer program product
US6882983B2 (en) * 2001-02-05 2005-04-19 Notiva Corporation Method and system for processing transactions
US20020111916A1 (en) * 2001-02-12 2002-08-15 Coronna Mark S. Payment management
US20020128917A1 (en) * 2001-03-06 2002-09-12 Electronic Data Systems Corporation Method and apparatus for processing financial transactions
US20020161724A1 (en) * 2001-04-05 2002-10-31 International Business Machines Corporation Enhanced protection for account-based transactions through the use of personal authorization criteria

Cited By (131)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706630B2 (en) 1999-08-19 2014-04-22 E2Interactive, Inc. System and method for securely authorizing and distributing stored-value card data
US20050051619A1 (en) * 1999-08-19 2005-03-10 Graves Phillip Craig System and method for securely authorizing and distributing stored-value card data
US10063714B2 (en) 2001-09-24 2018-08-28 E2Interactive, Inc. Inserting value into customer account at point of sale using a customer account identifier
US10445743B2 (en) 2001-11-15 2019-10-15 E2Interactive, Inc. Non-serialized electronic product registration system and method of operating same
US20070011104A1 (en) * 2003-03-21 2007-01-11 Ebay Inc. Payment transactions via substantially instant communication system
US20100332384A1 (en) * 2003-03-21 2010-12-30 Ebay Inc. Transaction aggregation engine
US10535049B2 (en) 2003-03-21 2020-01-14 Paypal, Inc. Payment transactions via substantially instant communication system
US7437328B2 (en) * 2003-11-14 2008-10-14 E2Interactive, Inc. Value insertion using bill pay card preassociated with biller
US10152614B2 (en) 2003-11-14 2018-12-11 E2Interactive, Inc. Systems and methods for electronic device point-of-sale activation
WO2005094442A3 (en) * 2004-03-23 2007-01-18 First Data Corp Transaction system with special handling of micropayment transaction requests
US20050216424A1 (en) * 2004-03-23 2005-09-29 Star Systems, Inc. Transaction system with special handling of micropayment transaction requests
US20080003977A1 (en) * 2005-03-23 2008-01-03 Chakiris Phil M Delivery of Value Identifiers Using Short Message Service (SMS)
US7537152B2 (en) 2005-03-23 2009-05-26 E2Interative, Inc. Delivery of value identifiers using short message service (SMS)
US9256867B2 (en) 2005-03-23 2016-02-09 E2Interactive, Inc. Delivery of value identifiers using short message service (SMS)
US20070078764A1 (en) * 2005-10-04 2007-04-05 International Business Machines Corporation Scalable lazy payment capture in online commerce systems
US20070108268A1 (en) * 2005-11-15 2007-05-17 Graves Phillip C Temporary value card method and system
US7575152B2 (en) * 2005-11-15 2009-08-18 E2Interactive, Inc. Temporary value card method and system
US20070143180A1 (en) * 2005-12-16 2007-06-21 Graves Phillip C Multiple use rebate card
US8190471B2 (en) 2005-12-16 2012-05-29 E2Interactive, Inc. Rebate card system
US8190472B2 (en) 2005-12-16 2012-05-29 E2Interactive, Inc. Multiple use rebate card
US20070143177A1 (en) * 2005-12-16 2007-06-21 Graves Phillip C Rebate card system
US11783326B2 (en) 2006-06-19 2023-10-10 Visa U.S.A. Inc. Transaction authentication using network
WO2007149785A3 (en) * 2006-06-19 2008-07-24 Visa Int Service Ass Portable consumer device verification system
US8489506B2 (en) 2006-06-19 2013-07-16 Visa U.S.A. Inc. Portable consumer device verification system
US11107069B2 (en) 2006-06-19 2021-08-31 Visa U.S.A. Inc. Transaction authentication using network
WO2007149785A2 (en) * 2006-06-19 2007-12-27 Visa U.S.A. Inc. Portable consumer device verification system
US20100169216A1 (en) * 2006-07-06 2010-07-01 Moneygram International, Inc. Systems and methods for processing payments with payment review features
US8655778B2 (en) * 2006-07-06 2014-02-18 Moneygram International, Inc. Systems and methods for processing payments with payment review features
US8781966B2 (en) * 2006-08-03 2014-07-15 The Western Union Company Money transfer transactions via pre-paid wireless communication devices
US20130311376A1 (en) * 2006-08-03 2013-11-21 The Western Union Company Money transfer transactions via pre-paid wireless communication devices
US20080033877A1 (en) * 2006-08-03 2008-02-07 First Data Corporation Money transfer transactions via pre-paid wireless communication devices
US8510223B2 (en) * 2006-08-03 2013-08-13 The Western Union Company Money transfer transactions via pre-paid wireless communication devices
US8949342B2 (en) 2006-08-09 2015-02-03 Apple Inc. Messaging system
US8406792B2 (en) 2006-11-27 2013-03-26 Apple Inc. Message modification system and method
US20140058934A1 (en) * 2007-01-16 2014-02-27 Merrill Brooks Smith Systems and Methods for the Payment of Customer Bills Utilizing Payment Platform of Biller
US20100042540A1 (en) * 2007-01-16 2010-02-18 E2Interactive, Inc.D/B/A E2Interactive, Inc. Bill Payment Card Method and System
US8566240B2 (en) * 2007-01-16 2013-10-22 E2Interactive, Inc. Systems and methods for the payment of customer bills utilizing payment platform of biller
US20080172331A1 (en) * 2007-01-16 2008-07-17 Graves Phillip C Bill Payment Card Method and System
US20110066517A1 (en) * 2007-01-16 2011-03-17 Merrill Brooks Smith Systems and methods for the payment of customer bills utilizing payment platform of biller
US9076174B2 (en) 2007-02-26 2015-07-07 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US8935718B2 (en) 2007-05-22 2015-01-13 Apple Inc. Advertising management method and system
US20080307107A1 (en) * 2007-06-08 2008-12-11 At&T Knowledge Ventures, Lp Peer-to-peer distributed storage for internet protocol television
US9578288B2 (en) * 2007-06-08 2017-02-21 At&T Intellectual Property I, L.P. Peer-to-peer distributed storage for internet protocol television
US20080319836A1 (en) * 2007-06-20 2008-12-25 Cvon Innovations Limited Method and system for delivering advertisements to mobile terminals
US20090076904A1 (en) * 2007-09-17 2009-03-19 Frank David Serena Embedding digital values for digital exchange
US20090171842A1 (en) * 2007-12-27 2009-07-02 Mastercard International, Inc. Techniques For Conducting Financial Transactions Using Mobile Communication Devices
US8527415B2 (en) * 2007-12-27 2013-09-03 Mastercard International, Inc. Techniques for conducting financial transactions using mobile communication devices
US9141991B2 (en) 2008-01-31 2015-09-22 Bill.Com, Inc. Enhanced electronic data and metadata interchange system and process for electronic billing and payment system
US10043201B2 (en) 2008-01-31 2018-08-07 Bill.Com, Inc. Enhanced invitation process for electronic billing and payment system
US20110196786A1 (en) * 2008-01-31 2011-08-11 Rene Lacerte Determining trustworthiness and familiarity of users of an electronic billing and payment system
US20110196771A1 (en) * 2008-01-31 2011-08-11 Rene Lacerte Enhanced invitation process for electronic billing and payment system
US10769686B2 (en) 2008-01-31 2020-09-08 Bill.Com Llc Enhanced invitation process for electronic billing and payment system
US20110184868A1 (en) * 2008-01-31 2011-07-28 Bill.Com, Inc. Enhanced invitation process for electronic billing and payment system
US8738483B2 (en) 2008-01-31 2014-05-27 Bill.Com, Inc. Enhanced invitation process for electronic billing and payment system
US20110184843A1 (en) * 2008-01-31 2011-07-28 Bill.Com, Inc. Enhanced electronic anonymous payment system
US8693737B1 (en) 2008-02-05 2014-04-08 Bank Of America Corporation Authentication systems, operations, processing, and interactions
US20110213709A1 (en) * 2008-02-05 2011-09-01 Bank Of America Corporation Customer and purchase identification based upon a scanned biometric of a customer
US20110213710A1 (en) * 2008-02-05 2011-09-01 Bank Of America Corporation Identification of customers and use of virtual accounts
US20100319004A1 (en) * 2009-06-16 2010-12-16 Microsoft Corporation Policy Management for the Cloud
US10417641B2 (en) 2009-09-11 2019-09-17 E2Interactive, Inc. System and/or method for handling recalled product purchases and/or return/warranty requests
US10296916B2 (en) 2009-09-11 2019-05-21 Maridee Joy Maraz System and/or method for handling recalled product purchases and/or return/warranty requests
US20120030101A1 (en) * 2009-10-06 2012-02-02 Apple Inc. Vendor payment consolidation system
US20110082789A1 (en) * 2009-10-06 2011-04-07 Apple Inc. Vendor payment consolidation system
US11928696B2 (en) 2009-12-16 2024-03-12 E2Interactive, Inc. Systems and methods for generating a virtual value item for a promotional campaign
US20220351157A1 (en) * 2009-12-23 2022-11-03 Aristocrat Technologies Australia Pty Limited System and method for cashless gaming
US11392905B2 (en) * 2009-12-23 2022-07-19 Aristocrat Technologies Australia Pty Limited System and method for cashless gaming
CN102196035A (en) * 2010-03-18 2011-09-21 微软公司 Unified web service discovery
US9247008B2 (en) 2010-03-18 2016-01-26 Microsoft Corporation Unified web service discovery
US9846871B2 (en) 2010-04-12 2017-12-19 E2Interactive, Inc. Systems and/or methods for determining item serial number structure and intelligence
US20110270698A1 (en) * 2010-05-03 2011-11-03 Masher Media Inc. Providing a Conditional Allowance Within a Virtual Space
US10068287B2 (en) 2010-06-11 2018-09-04 David A. Nelsen Systems and methods to manage and control use of a virtual card
US8510658B2 (en) 2010-08-11 2013-08-13 Apple Inc. Population segmentation
US20120054853A1 (en) * 2010-08-24 2012-03-01 International Business Machines Corporation Systems and methods to control device endpoint behavior using personae and policies
US8539561B2 (en) * 2010-08-24 2013-09-17 International Business Machines Corporation Systems and methods to control device endpoint behavior using personae and policies
US11263691B2 (en) 2010-09-30 2022-03-01 The Western Union Company System and method for secure transactions at a mobile device
US10861012B2 (en) 2010-09-30 2020-12-08 The Western Union Company System and method for secure transactions at a mobile device
US11182836B2 (en) 2010-10-13 2021-11-23 E2Interactive, Inc. Gift card ordering system and method
US10937076B2 (en) 2010-10-13 2021-03-02 E2Interactive, Inc. Online personalized gifting system
US20120130853A1 (en) * 2010-11-24 2012-05-24 Digital River, Inc. In-Application Commerce System and Method with Fraud Detection
US9785988B2 (en) * 2010-11-24 2017-10-10 Digital River, Inc. In-application commerce system and method with fraud prevention, management and control
US20120222094A1 (en) * 2010-12-29 2012-08-30 Uwe Huebler Method and arrangement for enabling the use of a consumable unit
US8959590B2 (en) * 2010-12-29 2015-02-17 Francotyp-Postalia Gmbh Method and arrangement for enabling the use of a consumable unit
US10546295B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US10074113B2 (en) 2011-09-07 2018-09-11 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US10079811B2 (en) 2011-09-07 2018-09-18 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10606989B2 (en) 2011-09-07 2020-03-31 Elwha Llc Computational systems and methods for verifying personal information during transactions
US10546306B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10263936B2 (en) 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US10198729B2 (en) 2011-09-07 2019-02-05 Elwha Llc Computational systems and methods for regulating information flow during interactions
US10523618B2 (en) 2011-09-07 2019-12-31 Elwha Llc Computational systems and methods for identifying a communications partner
US10366390B2 (en) * 2011-09-23 2019-07-30 Visa International Service Association Automatic refresh authorization for expired payment transaction authorizations
US20130080327A1 (en) * 2011-09-23 2013-03-28 Mark Baldrick Automatic refresh authorization for expired payment transaction authorizations
US11436651B2 (en) 2012-01-30 2022-09-06 E2Interactive, Inc. Group video generating system
US9633353B2 (en) 2012-03-07 2017-04-25 Bill.Com, Inc. Method and system for using social networks to verify entity affiliations and identities
US9413737B2 (en) 2012-03-07 2016-08-09 Bill.Com, Inc. Method and system for using social networks to verify entity affiliations and identities
US8819789B2 (en) 2012-03-07 2014-08-26 Bill.Com, Inc. Method and system for using social networks to verify entity affiliations and identities
US9633347B2 (en) 2012-05-04 2017-04-25 e2interactive. Inc Systems and/or methods for selling non-inventory items at point-of-sale (POS) locations
US9569769B2 (en) 2012-09-17 2017-02-14 E2Interactive, Inc. Composite activation indicia substrate
US11219288B2 (en) 2013-02-15 2022-01-11 E2Interactive, Inc. Gift card box with slanted tray and slit
US11111065B2 (en) 2013-02-15 2021-09-07 E2Interactive, Inc. Gift card presentation devices
US10410191B2 (en) 2013-03-14 2019-09-10 Bill.Com, Llc System and method for scanning and processing of payment documentation in an integrated partner platform
US10115137B2 (en) 2013-03-14 2018-10-30 Bill.Com, Inc. System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US10417674B2 (en) 2013-03-14 2019-09-17 Bill.Com, Llc System and method for sharing transaction information by object tracking of inter-entity transactions and news streams
US11120428B2 (en) 2013-05-02 2021-09-14 E2Interactive, Inc. Stored value card kiosk system and method
US11176583B2 (en) 2013-07-03 2021-11-16 Bill.Com, Llc System and method for sharing transaction information by object
US11080668B2 (en) 2013-07-03 2021-08-03 Bill.Com, Llc System and method for scanning and processing of payment documentation in an integrated partner platform
US11803886B2 (en) 2013-07-03 2023-10-31 Bill.Com, Llc System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US10572921B2 (en) 2013-07-03 2020-02-25 Bill.Com, Llc System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US11367114B2 (en) 2013-07-03 2022-06-21 Bill.Com, Llc System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US11017443B2 (en) 2014-04-30 2021-05-25 E2Interactive, Inc. System and method for a merchant onsite personalization gifting platform
US10824999B2 (en) 2015-08-13 2020-11-03 The Toronto-Dominion Bank Systems and methods for implementing hybrid public-private block-chain ledgers
US10586219B2 (en) 2015-08-13 2020-03-10 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US11151526B2 (en) 2015-08-13 2021-10-19 The Toronto-Dominion Bank Systems and methods for establishing and enforcing transaction-based restrictions using hybrid public-private blockchain ledgers
US10402792B2 (en) 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
US10282711B2 (en) 2015-08-13 2019-05-07 The Toronto-Dominion Bank System and method for implementing hybrid public-private block-chain ledgers
US11126975B2 (en) 2015-08-13 2021-09-21 The Toronto-Dominion Bank Systems and method for tracking behavior of networked devices using hybrid public-private blockchain ledgers
US10692054B2 (en) 2015-08-13 2020-06-23 The Toronto-Dominion Bank Document tracking on distributed ledger
US11810080B2 (en) 2015-08-13 2023-11-07 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
US10163080B2 (en) 2015-08-13 2018-12-25 The Toronto-Dominion Bank Document tracking on a distributed ledger
US10410192B2 (en) * 2015-09-29 2019-09-10 Ncr Corporation User interface for controlling multiple devices
US10498827B2 (en) 2016-09-30 2019-12-03 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US11102303B2 (en) 2016-09-30 2021-08-24 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US11144989B1 (en) * 2017-03-07 2021-10-12 Wells Fargo Bank, N.A. Customized graphical user interface for managing multiple user accounts
US10954049B2 (en) 2017-12-12 2021-03-23 E2Interactive, Inc. Viscous liquid vessel for gifting
US11900346B1 (en) * 2019-08-22 2024-02-13 Wells Fargo Bank, N.A. Apparatuses and methods for payment for consumable content
US11798059B2 (en) * 2020-04-16 2023-10-24 Bank Of Montreal Artificial intelligence modeling to predict electronic account data
US20210326960A1 (en) * 2020-04-16 2021-10-21 Bank Of Montreal Artificial intelligence modeling to predict electronic account data
CN112688998A (en) * 2020-12-17 2021-04-20 中国航空工业集团公司成都飞机设计研究所 Configurable main data subscription pushing method with permission

Also Published As

Publication number Publication date
US20030144894A1 (en) 2003-07-31
EP1461679A2 (en) 2004-09-29
AU2002365037A1 (en) 2003-06-23
EP1461679A4 (en) 2006-01-18
US7194543B2 (en) 2007-03-20
WO2003050648A3 (en) 2004-07-08
AU2002365037A8 (en) 2003-06-23
WO2003050648A2 (en) 2003-06-19

Similar Documents

Publication Publication Date Title
US20030126079A1 (en) System and method for implementing frictionless micropayments for consumable services
US7328189B2 (en) Method and apparatus for conducting electronic commerce transactions using electronic tokens
US8589268B2 (en) Financial institution-based transaction processing system and approach
AU2005255453B2 (en) Financial institution-based transaction processing system and approach
US7175072B2 (en) Strategies for handling transactions based on policies
US8442894B2 (en) Guaranteed merchant payment in a card-not-present transaction
US8793160B2 (en) System and method for processing transactions
US10068265B2 (en) Creating revenue sources using allocation source
US20020032650A1 (en) Payment system and method
WO2004114069A2 (en) System and method for facilitating a subsidiary card account
US9251515B2 (en) System and method for preventing fraud in the secondary market for gift cards
US20050149437A1 (en) Method, system, and storage medium for managing electronic transactions
WO2004095228A2 (en) System and method for facilating a bubsidiary card account with controlled spending capability
WO2006034265A2 (en) Computer system for maintaining linked accounts
JP2007527064A (en) Financial transactions with sending and receiving charges
KR20070065192A (en) System and method for complex transaction card
US20050021458A1 (en) Account-enabled on-line devices
US20080103966A1 (en) System and/or method for dynamic determination of transaction processing fees
KR20230030981A (en) Business agency service system based on rental business
US20030120590A1 (en) Electronic settlement method and system
KR20010078918A (en) Method for management a credit card and system for the performing the same
KR20030057845A (en) Method of providing mileage point using information network
WO2001018724A1 (en) SYSTEM AND METHOD FOR SUBSIDIZING CONDITIONAL PURCHASE OFFERS (CPOs)

Legal Events

Date Code Title Description
AS Assignment

Owner name: WORLDCOM, INC., MISSISSIPPI

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GREENE, WILLIAM SPROTT;REEL/FRAME:013446/0668

Effective date: 20030219

AS Assignment

Owner name: WORLDCOM, INC., MISSISSIPPI

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROBERTSON, JAMES A.;REEL/FRAME:013453/0784

Effective date: 20030226

AS Assignment

Owner name: MCI, LLC, NEW JERSEY

Free format text: MERGER;ASSIGNOR:MCI, INC.;REEL/FRAME:020517/0311

Effective date: 20060109

Owner name: VERIZON BUSINESS GLOBAL LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:MCI, LLC;REEL/FRAME:020520/0075

Effective date: 20061120

Owner name: MCI, INC., VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:WORLDCOM, INC.;REEL/FRAME:020517/0226

Effective date: 20040419

AS Assignment

Owner name: VERIZON BUSINESS GLOBAL LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:MCI, LLC;REEL/FRAME:020671/0510

Effective date: 20061120

Owner name: MCI, LLC, NEW JERSEY

Free format text: MERGER;ASSIGNOR:MCI, INC.;REEL/FRAME:020671/0439

Effective date: 20060109

Owner name: MCI, INC., VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:WORLDCOM, INC.;REEL/FRAME:020671/0399

Effective date: 20040419

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:032734/0502

Effective date: 20140409

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:044626/0088

Effective date: 20140409