Patent Publication Number: US-2012036044-A1

Title: Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor

Description:
RELATED APPLICATIONS 
     The present application is a continuation of U.S. application Ser. No. 12/544,919, entitled “Method and System to Facilitate a Payment in Satisfaction of Accumulated Micropayment Commitments to a Vendor,” and filed Aug. 20, 2009, which is a continuation of U.S. application Ser. No. 10/741,091, entitled “Method and System to Facilitate a Payment in Satisfaction of Accumulated Micropayment Commitments to a Vendor,” and filed on Dec. 19, 2003, which claims the priority benefit of PCT Application No. PCT/US03/35950, entitled “Facilitating Micropayments between a Plurality of Parties,” and filed Nov. 10, 2003. Each of these applications is hereby incorporated herein by reference in its entirety. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates generally to the field of commerce automation and, more specifically, to a system to enable a payment in satisfaction of accumulated micropayment commitments to a vendor. 
     BACKGROUND OF THE INVENTION 
     Electronic payments between transacting parties have become increasingly prevalent, as the accessibility of technology to enable such payments has increased. For example, a majority of vendors are today equipped to handle credit card and/or debit card transactions. Network-based (or online) vendors are typically heavily dependent on electronic payment services, and may accept a number of electronic payment instruments (e.g., credit cards, debit cards, and other electronic payment services (e.g., the PayPal online payment service)). 
     A number of companies offer electronic payment (or funds transfer) services (e.g., Visa, Mastercard, American Express, PayPal, etc.). Such electronic payment services naturally charge for the provision of such services, typically on a per-transaction basis. These transaction charges are further typically levied against a vendor that is providing goods or services. While such transaction charges are unattractive to vendors, in many instances the transaction charges are small in comparison to the total transaction value. Further, vendors regard the convenience benefits to both the purchaser and the vendor as outweighing the relevant cost. 
     The transaction charges levied by the various electronic payment services are, as noted above, typically per-transaction charges, and further often include fixed transaction charges. As a total transaction value decreases, the per-transaction charge of course increases as a percentage of the total transaction value, and the attractiveness to the vendor of using such electronic payment services decreases. It is for this reason that vendors are often reluctant to accept electronic payment (e.g., via a credit card) where the total transaction value is small. The use of electronic payment services becomes particularly unattractive when the transaction costs begin to approach the profit margins associated with a transaction. Consider for example the situation where an online vendor is selling electronic content (e.g., MP3 files) for less than $1. Assuming, for example, a per transaction charge of $0.10, it will be appreciated that the vendor may be reluctant to receive payment via an electronic payment service because 10% of the total transaction value is consumed by electronic payment service charges. The problem becomes more acute as the per item value decreases. 
     With a view to addressing the problem of transaction charges associated with so-called “micropayments”, a number of solutions have been proposed. One such solution is proposed by Jan Chomicki et al, in “Decentralized Micropayment Consolidation”, Proceedings of the International Conference on Distributed Computing Systems (ICDS &#39;98), May 1998, Amsterdam, The Netherlands. Specifically, a protocol based on the concept of debt consolidation in a decentralized network environment is discussed in this document. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG. 1  is a diagrammatic representation of a networked transaction environment, according to an exemplary embodiment of the present invention, within which a client-server architecture is deployed. 
         FIG. 2  is a diagrammatic representation of a networked transaction environment, according to an alternative embodiment of the present invention, in which a micropayment system is shown to be deployed as a peer-to-peer system. 
         FIG. 3  is a block diagram illustrating further detail regarding micropayment applications, according to one exemplary embodiment of the present invention, which form part of the micropayment system. 
         FIG. 4  is a high-level entity-relationship diagram illustrating various tables, according to one exemplary embodiment of the present invention, which may reside within a micropayment database associated with the micropayment system. 
         FIG. 5  is a block diagram illustrating an exemplary commitments receivable table that is populated with values. 
         FIG. 6  is a flowchart of a method, according to an exemplary embodiment of the present invention, whereby micropayment applications may calculate a total commitment receivable value, owed to a payee user, and then allocate that total commitment receivable value to a funding queue. 
         FIG. 7  is flowchart illustrating a method, according to an exemplary embodiment of the present invention, to facilitate payments between parties for aggregated payment commitments. 
         FIG. 8  is a flowchart illustration of an exemplary method to calculate a risk-adjusted commitments receivable balance for a particular payee user. 
         FIG. 9  illustrates an exemplary payment commitment interface that may be generated and presented by the micropayment system. 
         FIG. 10  illustrates an exemplary payable interface that may be generated and presented by the micropayment system. 
         FIG. 11  illustrates an exemplary payment commitment receipt interface that may be presented to a user of the micropayment system via a respective web server. 
         FIG. 12  illustrates an exemplary payable interface, which may be presented to a payee user, advising the payee user that a commitments receivable balance exceeds a threshold that is eligible for a funding payment. 
         FIG. 13  shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. 
     
    
    
     DETAILED DESCRIPTION 
     A method and system to enable the transfer of micropayments to a vendor are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. 
     While the term “micropayments” is utilized throughout this specification, the present invention is not limited to the processing of payments below a specific value. The present invention may find application in the processing of payments of any value, and the processing of micropayments is described as one use scenario in which the invention would find application. 
     The below-described exemplary embodiment of the present invention proposes a payment system whereby a payor user is enabled to make payment commitments to a payee user, these payment commitments potentially being for small amounts (e.g., $0.05). The payment commitments made by the payor user are then registered against both the payor user and the payee user. Over time, it will be appreciated that the total value of a number of payment commitments made by the payor user, for example to a number of payee users, will grow. Similarly, the total of the payment commitments made to the payee user, potentially by a number of payor users, will also grow. In order to reduce the transaction costs associated with the processing of these various payment commitments, one exemplary embodiment of the present invention proposes a threshold value at which a payor user may be requested to fund (e.g., make a payment) in connection with a total value that comprises an accumulated total of payment commitments made by that payor user. Similarly, a payee user may, when the accumulated total value of payment commitments made to that payee user exceeds a threshold, become eligible to receive a payment in satisfaction of the accumulated payment commitments. One aspect of an exemplary embodiment of the present invention relates to the determination of which payor user should make a payment to which payee user, and a further aspect of the exemplary embodiment of the present invention relates to the determination of when such a payment should be made, and what the value of such a payment should be. It will be appreciated that, by accumulating payment commitments owed by a payor user, and owed to a payee user, and performing a single payment transaction (or a reduced number of payment transactions) in satisfaction of a number of accumulated payment commitments, the transaction costs associated with the satisfaction of multiple payment commitment may be reduced. 
     The exemplary embodiment of the present invention further draws a distinction between unfunded payment commitments (e.g., payment commitments for which the payor user has not made a payment in satisfaction thereof), and funded commitments (e.g., payment commitments in connection with which the payor user has made a payment). 
       FIG. 1  is a diagrammatic representation of a networked transaction environment  10 , according to an exemplary embodiment of the present invention, within which a client-server architecture is deployed. A number of client-side machines are shown to be coupled, via a network  20 , to a number of server-side machines and processes. For example, a client machine  12  is shown to host and execute a first client application, in the exemplary form of a web browser  14 , and a second client machine  16  is shown to execute a further client  18 , which may communicate via one or more server-side machines utilizing a published Application Program Interface (API). Each of the client machines  12  and  16  is shown to be coupled to the network  20  (e.g., the Internet, Local Area Network (LAN), a Wide Area Network (WAN)), which may include wired, wireless or some combination of wired and wireless technologies. The network  20  may furthermore facilitate communications between the client machines and the server-side utilizing any one of a number of well-known protocols (e.g., HTTP). 
     Returning now to the server-side, three systems are also coupled to the network  20 , namely a settlement system  22 , a micropayment system  24 , and a trading system  26 . While each of the systems  22 ,  24  and  26  is shown in  FIG. 1  to be a separate and distinct system, in alternative embodiments of the present invention, the components and functions of these systems may be integrated into one or more related systems. Each of the exemplary systems  22 ,  24  and  26  is shown to have a similar three-tier architecture, including a database server  28 , which facilitates access to an associated database, one or more application server machines  30 , which host and execute respective applications, one or more web servers  32  that generate and/or serve web pages (e.g., HTML pages) responsive to requests received from the client-side, and one or more Application Program Interface (API) servers  34  that provide programmatic access to an associated system. For example, an API server  34  may, responsive to a request received from the client-side, generate and serve eXtensible Markup Language (XML) files to a requesting machine. 
     Dealing now specifically with the settlement system  22 , the relevant application server machines  30  host one or more settlement applications  42  that enable the transfer of value (e.g., dollar or a proprietary currency) between transacting parties. The settlement applications  42  are further able to read data from and write data to a settlement database  40 , via a database server  28 . The settlement system  22  may support a payment service, such as the PayPal payment service operated by Inc., of Mountain View, Calif. 
     The micropayment system  24  similarly hosts one or more micropayment applications  38  on application server machines  30 , these micropayment applications  38  having read and write access to data stored on a micropayment database  36 , via a database server  28 . Further details regarding exemplary micropayment applications  38  are described in further detail below. 
     The trading system  26  hosts one or more trading applications  46  on appropriate application server machines  30 , the trading applications  46  having read and write access to data stored on a trade database  44 , via a database server  28 . The trading applications  46  may include one or more price-setting applications (e.g., an auction application, a fixed-price application, etc) whereby a value for an agreement between parties may be established. Other trading applications  46  may include, for example, reputation applications that track feedback and transactional history information pertaining to a user. Such reputation applications may also publish reputation information regarding a user, so as to allow users to establish credibility within the trading system  26 , and have this reputation information published to potential trading partners, or to other systems (e.g., the settlement system  22  or the micropayment system  24 ) for use by these systems in assessing the credibility, trustworthiness and the risk factors for a particular user. One example of the trading system  26  is the eBay on-line marketplace, operated by eBay Inc., of San Jose, Calif. 
       FIG. 2  is a diagrammatic representation of a networked transaction environment  50 , according to an alternative embodiment of the present invention, in which a micropayment system is shown to be deployed as a peer-to-peer system, as opposed to the server-based system described above with reference to  FIG. 1 . To this end,  FIG. 2  shows the networked transaction environment  50  as including user machines  52  and  58 , each of which hosts a respective peer-to-peer micropayment application  54  and  60 . Each of the user machines  52  and  58  is shown to be coupled to a network  64  (e.g., the Internet), and the micropayment applications  54  and  60  are accordingly able to communicate via the network  64 . Each of the micropayment applications  54  and  60  further has access to a local micropayment database  56  and  62 , respectively, and may be architectured and provide the various functions as described in further detail below. 
       FIG. 2  also illustrates the settlement system  22  and the trading system  26  as being server-based systems with which the relevant micropayment applications  54  and  60  can communicate via the network  64 . In a further embodiment of the present invention, the settlement system  22  and/or the trading system  26  may also be deployed utilizing a peer-to-peer architecture, as opposed to the server-based architecture illustrated in  FIG. 2 . Additionally, have various components of either the settlement system  22  or the trading system  26  may, in alternative embodiments, be deployed as peer-to-peer systems. For example, a peer-to-peer reputation system, or a peer-to-peer risk analysis system, could also be utilized in conjunction with a micropayment system that is server based or is itself a peer-to-peer system. 
       FIG. 3  is a block diagram providing further detail regarding the micropayment applications  38 , according to one exemplary embodiment of the present invention, that may be hosted on one or more application servers  30  of the micropayment system  24  illustrated in  FIG. 1 . It will of course be appreciated that the illustrated micropayment applications  38  could also form modules, or sub-applications, of a peer-to-peer, stand-atone micropayment application  54  that executes on a user machine  52 . 
     The exemplary micropayment applications  38  include a payable commitment register module  70 , which operates to register payment commitments that may be made by a payor user utilizing the micropayment system  24 . For example, the micropayment system  24  may provide one or more user interfaces whereby a payer user can identify a payee user to which the payer user wishes to make a payment commitment, and utilizing which the payor user may also specify a value e.g., a monetary value) for the relevant payment commitment. One embodiment of the present invention classifies payment commitments as either being unfunded (e.g., the relevant payer user has not made an actual payment to satisfy one or more payment commitments) and funded payment commitments (e.g., the payor user made a payment in satisfaction of one or more payment commitments). 
     The payment commitment register module  70  may communicate with the web server  32  and/or the API server  34  so as to send commitment information (e.g., to be included within a marked up language document), and to receive payment commitment information from a payer user. The payment commitment register module  70 , on receipt of the payment commitment information, further operates to record this information within appropriate tables within the micropayment database  36 . Such tables may include, for example, a commitments payable table  94  and a commitments receivable table  96 , which are discussed in further detail below with reference to  FIG. 4 . 
     Similarly, a receivable commitment register module  72  operates to receive commitment information pertaining to a payment commitment to a payee user, and to register this payment commitment information within an appropriate table, or tables, within the micropayment database  36 . For example, the receivable commitment register module  72  may record receivable commitment information. within a commitments receivable table  96 , which is described in further detail below with reference to  FIG. 4 . 
     Both the payable commitment register module  70  and the receivable commitment register module  72  communicate with a recurring commitment module  74 . The recurring commitment module  74  is responsible for generating recurring payments commitments as defined by a payor user (for generating or recurring commitment requests as may be defined by a payee user), and for communicating appropriate commitment information to the register modules  70  and  72 , responsive to which the register modules  70  and  72  will create and/or update records within the appropriate tables. Consider for example that a particular payor user may wish to make a monthly payment commitment to a specified payee user (e.g., for subscription to a particular service). The recurring commitment module  74  then handles such a recurring commitment. 
     A threshold adjustment module  76 , according to one exemplary embodiment of the present invention, facilitates the specification of, or specifies, thresholds that trigger a funding transaction (e.g., the initiation of a payment process) in satisfaction of payment commitments that have been registered within the micropayment system  24 . For example, a payable threshold may be specified in connection with payable commitments of a payor user, so that when the total value of payment commitments made by the payor user exceeds the payable threshold, a payment process is initiated whereby the payor user funds the relevant unfunded payment commitments. 
     Similarly, a receivable threshold may be specified by the threshold adjustment module  76 , the receivable threshold being a threshold total value that, when exceeded by the value of payment commitments made to a payee user, renders the payee user eligible to receive value in satisfaction of the payment commitments. 
     In one embodiment of the present invention, the threshold adjustment module  76  may simply operate to allow an administrator of the micropayment system  24  to specify one or more threshold values (e.g., $5.00) as either a payable threshold or a receivable threshold, for example. For example, an administrator of the micropayment system  24  may specify different thresholds that are applicable to individual payor users or payee users, or even various pairs of payor/payee combinations. 
     In another embodiment of the present invention, the threshold adjustment module  76  may allow individual users to specify payable and/or receivable thresholds, for example within the constraints of certain minimum and maximum values, which would be applicable to the relevant user. 
     In yet a further embodiment of the present invention, the threshold adjustment module  76  may automatically calculate payable and/or receivable thresholds, utilizing the various information sources. For example, where the micropayment system  24  is aware that a certain settlement system  22  will be utilized in connection with a particular funding event, the threshold adjustment module  76  may adjust thresholds dependent on transaction charges levied by the relevant settlement system  22 . Consider the specific example where a settlement system  22  increases transaction charges associated with funding events. In this case, the threshold adjustment module  76  may raise thresholds so as to maintain the transaction charges as a predetermined maximum percentage of a funding value. In another exemplary embodiment, the threshold adjustment module  76  may adjust thresholds dynamically based on whether a particular payee user has failed to achieve a predetermined rate of payment commitments. For example, the threshold adjustment module  76  may automatically lower a funding receivable threshold so as to prevent the relevant payee user from having to wait an unacceptable amount of time prior to having payment commitments funded. Also, where a payor user is not making payment commitments at a predetermined rate, the threshold adjustment module  76  may also lower the funding payable threshold associated with that user so as to extract funding within an acceptable time period. 
     The threshold adjustment module  76  may also take into account the characteristic or attribute information associated with a payor or payee user in assessing a threshold associated with that user. For example, where historical or reputation information associated with the user indicates an increased or decreased risk associated with obtaining funding from a payor user, the threshold adjustment module  76  may automatically adjust a funding payable threshold for that user. In yet another exemplary embodiment, the threshold adjustment module  76  may increased or decreased the threshold over time. For example, the threshold may start at a certain level (e.g., $5.00), and be reduced by a predetermined amount each month (e.g., $1.00 per month) to a minimum acceptable transaction value, to ensure that the payor user is eventually made liable to make a funding payment, even if the funding payment is very small. 
     The threshold adjustment module  76  may also specify thresholds with varying resolutions. For example, the threshold adjustment module  76  may specify thresholds to be applied on a system level across the micropayment system  24 . The threshold adjustment module  76  may also specify thresholds to be specified at a user-level, or even at a funding transaction level, depending on various circumstances. 
       FIG. 3  shows the threshold adjustment module  76  being coupled to a threshold assessment module  80 , the threshold assessment module  80  operating to assess whether a commitment payable total, for a commitment receivable total, exceeds a specified threshold. Operation of the threshold assessment module  80  is described in further detail below with reference to  FIG. 6 . 
     The micropayments applications  38  are, in one exemplary embodiment, also shown to include a receivable calculation module  78  that operates to calculate a total commitment receivable value for a payee user, utilizing a risk profile associated with a user (e.g., the payee user). In other embodiments of the present invention, the calculation of the total commitment receivable value may take other risk information into account. The invention is accordingly not limited to the utilization of a risk profile associated with a user, but may include the utilization of any information from which a risk determined or inferred. 
     The receivable calculation module  78  is shown to communicate with a risk assessment module  81 , which determines the risk profile associated with a user (e.g., the payee user). For example, the risk assessment module  81  may author a risk profile for a user (or otherwise calculate a risk value for utilization within the micropayments system  24 ) utilizing historical and reputation information. The historical and/or reputation information utilized by the risk assessment module  81  may be obtained locally from the micropayment system  24 , or may be obtained from other sources, such as for example reputation information obtained from the trading system  26 , and historical payment information obtained from the settlement system  22 . The risk assessment module  81  may also obtain information from third party information vendors, such as Equifax and credit score organizations. 
     A wide variety of other information sources may be utilized by the risk assessment module  81  in calculating risk values (e.g., a risk profile for a user) for utilization within the micropayment system  24 . For example, a type of merchandise or service offered by a particular user may be relevant. For example, gaming or pornography services are typically at a higher risk of default by payor users. A geographic location of a payor or a payee user may also be relevant. It should be noted any combination of information associated with any type of user, or any party to a particular transaction, may be utilized by the risk assessment module  81  in assessing risk. The assessment risk may furthermore be utilized beyond the calculation of the total commitment receivable value for a payee user, and may be utilized for risk-adjusting, other payment values and other purposes within the micropayment system  24 , for example as described below. 
     The risk assessment module  81  is also shown to provide input to the threshold adjustment module  76 , so as to enable the module  76  to utilize a risk profile in adjusting threshold values associated with the user, if warranted. 
     The micropayment applications  38  also include a communication module  82  to enable the communication of various types of information between the micropayment applications  38  and other applications (e.g., the settlement application  42  and the trading applications  46  illustrated in  FIG. 1 ), as well as the communication of messages (e.g., emails, SMS messages, Instant Messages (IMs), etc.) to users of the micropayment system  24 . For example, the communication module  82  may communicate instructions to settlement applications  42 , as part of a payment process, to initiate the transfer of funds from a payor user to a payee user. The communication of such instructions may be performed automatically on instruction from a payment allocation module  84 , or may be performed upon receiving instructions from a user for the relevant funds transfer. 
     The communication module  82  may also receive communications from other applications. For example, the settlement applications  42  may communicate back to the communication module  82  that funds have successfully been transferred from a payor user to a payee user, responsive to which the micropayment applications  38  may register certain commitments as being funded. To this end, the communication module  82  is shown to be in communication with the register module  70  and  72 , an as to enable these modules to register commitments as funded, when appropriate and as confirmed by a settlement application  42 . 
     The communication module  82  is also shown to be in communication with the threshold adjustment module  76  so as to enable the threshold adjustment module  76  and the risk assessment module  81  to send communications to, and receive communications from, external systems such as the settlement system  22  and the trading system  26 . 
     A payment allocation module  84  operates, in one exemplary embodiment of the present invention, to instruct the automatic transfer of funds from a payor user to a payee user. For example, a payor user may have defined preferences in terms of which payment commitments are automatically funded upon the total of such commitments exceeding a funding payable threshold. Further, the payor user may have specified preferences as to which payee user is to receive the relevant funds, or have specified criteria in terms of which the payment allocation module  84  may automatically identify a payee user to which the funds should be allocated. For example, a specific user may define preferences whereby, upon the total of payment commitments for the payor user exceeding a threshold, such commitments are funded by making a payment to a charity organization that qualifies to receive the funding. 
     As will be described in further detail below, in one exemplary embodiment, receivable commitments, when exceeding a funding receivable threshold, may be placed in a funding queue by the receivable calculation module  78  and by the threshold assessment module  80 . In this embodiment, the payment allocation module  84  may operate various algorithms to determine which of the eligible payees within the funding queue is to be funded next, or upon occurrence of a specific event. For example, the payment allocation module  84  may allocate funding to the funding queue based on a simple first in, first out principle. Alternatively, the payment allocation module  84  may apply more sophisticated criteria to the selection of payees from within the funding queue. 
       FIG. 4  is a high-level entity-relationship diagram illustrating various tables  90 , according to one exemplary embodiment of the present invention, which may reside within the micropayment database  36 . The tables  90  include a user table  92  in which is stored contact and other information specific to each user. A commitments payable table  94  maintains a record of each payment commitment made to a specific user, and includes identifiers identifying the payor user, the payee user, an amount of the commitment, the date on which the commitment was made, a description of the commitment, an indication of whether the commitment is funded or not, and an indication as to whether the commitment is recurring. 
     Similarly, a commitments receivable table  96  stores records for each payment commitment receivable by a particular user, and records the same information recorded within the commitments payable table  94 . 
     It will be appreciated that by maintaining separate commitments payable and commitments receivable tables  94  and  96 , these tables may be utilized to perform double-entry verification. In an alternative embodiment, the commitments payable table  94  and the commitments receivable table  96  may be combined into a single commitments table. 
     A settlements table  98  is populated with records for each funding transaction between a particular payor user and a particular payee user. The records within the settlement table  98  may be generated from information retrieved from the settlement system  22 , and may also be utilized by the register modules  70  and  72  to flag entries within the tables  94  and  96  as funded responsive to a particular funding transaction. 
     The tables  90  further includes a user thresholds table  100 , which stores a funding payable threshold and a funding receivable threshold for each user for which a record exists within the user table  92 . As described above, in one exemplary embodiment of the present invention, payable and receivable thresholds may be specified at a user-level. In an alternative embodiment of the present invention, a system thresholds table  102  may store funding payable and funding receivable thresholds that are applicable at a system level within the micropayment system  24 . Of course, both user thresholds and systems thresholds table  100  and  102  may exist, and the recorded thresholds may be selectively applied by the payment allocation module  84 , depending on predetermined criteria. 
     The tables  90  also include a reputation table  104  that is populated with records that include feedback and history information for a particular user. For example, the reputation table  104  may include transaction feedback information, payment feedback information, membership duration information, external credit or identification verification information, and affiliate information. As described above, information within the reputation table  104  may be internally generated within the micropayment system  24 , or may be received via the communication module  82  from external sources and systems (e.g., the settlement system  22  and the trading system  26 ). 
       FIG. 5  is a block diagram illustrating an exemplary commitments receivable table  96  that is populated with values. As shown, various commitments are flagged as either being funded or unfounded, depending on whether a relevant payor has performed a funding transaction that applies and covers the relevant payment commitment. 
     It should be noted that the user table  92  might, in one exemplary embodiment, reflect a commitment payable balance and a commitment receivable balance. The receivable calculation module  78 , based on information contained within the commitments payment table  94  and the commitments receivable table  96 , may periodically update these balances. 
       FIG. 6  is a flowchart of a method  110 , according to an exemplary embodiment of the present invention, whereby the micropayment applications  38  may calculate a total commitment receivable value, owed to a payee user, and then allocate that total commitment receivable value to a funding queue. Specifically, the commitments receivable table  96  provides input, in the form of raw commitments receivable information, to the receivable calculation module  78 . The receivable calculation module  78  deploys a risk model  112  to calculate a risk-adjusted commitments receivable value total. The risk model  112  utilizes information retrieved from the reputation table  104  to author a risk profile, associated with the relevant payee user, and calculates the risk-adjusted commitments receivable total as a function of the authored risk profile. In one embodiment, the risk profile is applied only to the unfunded portion of the raw commitments receivable total, in view of the uncertainty regarding the funding of this portion of the commitments receivable total. In other embodiments of the present invention, the risk profile that is applied to the unfunded portion of the raw commitments receivable total is not particularly associated with the payee user, but may be applicable across the micropayment system  24  as a whole, or may be calculated based on the payor users associated with the unfunded payment commitments. 
     The function of the risk profile that is applied by the receivable calculation module  78  may be a simple function (e.g., a simple percentage calculation), or may be a more complex function that takes a number of factors into consideration. For example, the risk profile (or other at risk value) may be calculated utilizing any of the information types specified above. Further, the function of the risk profile (or risk value) that is applied by the receivable calculation module  78  may be the subject of continuous improvement or adjustment, either by an administrator of the micropayment system  24  or by its own machine learning. 
     The risk-adjusted commitments receivable total is then communicated from the receivable calculation module  78  to the threshold assessment module  80 , which makes a determination as to whether the risk-adjusted commitments receivable total exceeds a threshold that qualified the receivable total for funding. In making this assessment, the threshold assessment module  80  may utilize information contained in the threshold tables  100  or  102 , described above with reference to  FIG. 4 . As noted, the thresholds may be applied on a system-level, a user-level or a transaction-level. 
     In the event that the threshold assessment module  80  determines that the risk-adjusted commitments receivable total is qualified to receive funding, the relevant receivable total is entered into a funding queue  114 . Each entry within the funding queue  114  records the risk-adjusted commitments receivable total, the payee user, the date on which the receivable total was entered into the funding queue, and a priority. In one embodiment, the payment allocation module  84  may determine the priority. Specifically, the payment allocation module  84  may prioritize each of the entries within the funding queue  114  based on a first in, first out priority scheme, or a more complex priority scheme. For example, entries for which the payee is a specific type of organization (e.g., a charity), or is identified as a priority payee, may be prioritized ahead of other entries. In other embodiments, the priority scheme may be utilized to prioritize entries within the funding queue to ensure that the payees do not wait an unacceptable period of time prior to receiving funding. 
       FIG. 7  is flowchart illustrating a method  120 , according to an exemplary embodiment of the present invention, to facilitate payments between parties for aggregated payments commitments. The method  120  commences at block  122 , with the presentation of the payment commitment interface to a payor user.  FIG. 9  illustrates an exemplary payment commitment interface  160 , which may be presented at block  122 . As will be noted from  FIG. 9 , the payment commitment interface  160  may include a payee identification field  162 , within which a payor user may identify a payee user, and an amount field  164 , into which a payor user can input a value associated for the relevant commitment. The payment commitment interface  160  also includes a recurrence section  168 , which allows the payor user to identify the commitment as being recurring (e.g., using yes/no radio buttons), and allows the payor user to specify a recurrence date within a recurrent date field  169 , and the recurrence period within a recurrence period field  170 . In other exemplary embodiments, the interface  160  may provide other mechanisms for indicating recurrence, such as number and frequency of payment, e.g, “make 25 commitments of $0.10 each, one commitment per day.” 
     Returning to  FIG. 7 , at block  124 , the communication module  82  receives payment commitment information from the payor user (e.g., via the web server  32  or the API server  34 ), the payment commitment information including an identifier for the payee user, an amount, a date and the above discussed recurrence information. 
     At block  162 , the payment commitment register module  70  registers a payment commitment, based on the payment commitment information, against the payor user within the commitments payable table  94 . Similarly, the receivable commitment register module  72  registers the payment commitment against the payee user in the commitments receivable table  96 . Further, the receivable calculation module  78  may calculate and update the commitments payable and commitments receivable balances for each of the payer and the payee users within the user table  92 , based on the received payment commitment information. 
     At decision block  128 , as are described above, the updated commitments receivable balance that is calculated at block  126  and reflected in the user table  92 , may be a risk-adjusted commitments receivable balance (or total) as calculated by the receivable calculation module  78 . 
     Moving on to decision block  128 , the threshold assessment module  80 , subsequent to the updating of the commitments payable balance, determines whether the commitments payable balance for the payor exceeds a pre-determined threshold funding payable threshold (e.g., specific at a user-level or a system-level threshold). In the event that the commitments payable balance for the payor user does not exceed a threshold, the method  120  then terminates at block  130 , 
     On the other hand, should the commitments payable balance for the payor user exceed the funding payable threshold, at decision block  132 , the payment allocation module  84  makes a determination whether a payee user (e.g., a vendor) exists with a commitments receivable balance that is equal to, or exceeds, the commitments payable balance of the payor user. As noted above, the commitments receivable balance is, in an exemplary embodiment, a risk-adjusted commitments receivable balance. The determination performed by the payment allocation module  84  at decision block  132  may include the payment allocation module  84  performing a search of the funding queue  114  to identify entries having a commitments receivable total that is satisfiable by the commitments payable balance of the payor user. In performing the search of the funding queue  114 , the payment allocation module  84  may also consider the priority data associated with each entry when attempting to identify an eligible payee user. 
     In the event that the payment allocation module  84  is successful in identifying a payee user at decision block  132 , the method  120  proceeds to block  134 , where a payment process is initiated to effect a funding payment from the payer user to the located payee user. 
     In various embodiments of the present invention, the initiation of the payment process at block  134  may take various forms. For example, the micropayment system  24 , may at block  134  present a payable interface  172 , an exemplary embodiment of which is illustrated in  FIG. 10 , to the payor user, the payable interface  172  communicating to the payor user that (1) his or her commitments payable balance exceeds the threshold, and that (2) the payor user is now required to make a funding payment to the located payee user. In one exemplary embodiment of the present invention, the payment allocation module  34  may, at decision block  132 , in fact identify a number of payee users that are eligible to receive the funding payment. In this exemplary embodiment, the payable interface  172  may present to the payor user a list  174  of eligible payee users, together with a mechanism (e.g., a radio box) to select at least one of the eligible payee users to receive the funding payment. 
     The payable interface  172  also shown in  FIG. 10  to include a “proceed to payment service” button  176 , which is user-selectable to divert the payor user to the settlement system  22 . The settlement system conveniently allows the payor user to make the funding payment to the selected payee user. Accordingly, selection of the button  176  may cause the micropayment system  24  utilizing the communication module  82 , to communicate payor user identification information, payee user identification information, amount information and funding amount information to the settlement system  22 . Where the settlement system  22  is web-services enabled, this information may be received via a relevant API server  34 . The settlement applications  42  of the settlement system  22  may then initiate a flow whereby the funding transaction payment may be completed. 
     In an alternative embodiment of the present invention, at block  134 , the payment allocation module  84  may automatically communicate instruction that cause the funding payment to be paid to the payee user, without manual intervention or approval by the payor user. For example, the payment allocation module  84 , utilizing the communication module  82 , may communicate instructions to the settlement system  22  to perform the funding payment into an account of the payee user. 
     Where the settlement system  22  is utilized to complete the payment at block  134 , the settlement system  22  may communicate confirmation information back to the micropayment system  24 , this information being received by the communication module  82 , and then provided to the register modules  70  and  72 . Responsive to receiving confirmation of the funding payment, the register modules  70  and  72  may then flag the payment commitments within the commitments tables  94  and  96  as being funded. 
     Moving on from block  134  of the method  120 , the method  120  en terminates at block  136 . 
     Returning to decision block  132 , in the event that the payment allocation module  84  is unable to locate a payee user within the funding queue  114  with a commitments receivable value that is greater than or equal to the commitments payable balance, the payment allocation module  84  proceeds to attempt to locate a payee user with a commitments receivable balance that is greater than or equal to a predetermined threshold. In the exemplary embodiment of the present invention that includes the funding queue  114 , the threshold assessment module  80  will have already identified, and placed within the funding queue  114 , all commitments receivable balances that exceed an appropriate funding payable threshold. In this case, the payment allocation module  84  selects a next commitments receivable balance, from the funding queue  114  and according to the employed priority scheme, to receive the funding payment. In an alternative embodiment to the present invention, the threshold assessment module  80 , at decision block  178 , performs an analysis on the commitments receivable balances (e.g., risk-adjusted or otherwise) with a view to identifying eligible payee users, where after the payment allocation module  84  may dynamically select from the eligible payee users. 
     In the event that the payment allocation module  84  is unable to locate an eligible payee user at block  138  (e.g., the funding queue  114  is empty), the method  120  proceeds to block  136  and ends. On the other hand, if at least one eligible payee user is identified, the method  120  progresses to block  140 , and a process whereby the payor user pays the payee user the funding payment is initiated. The method  120  then loops back from. block  140  to decision block  128 . 
       FIG. 8  is a flowchart illustration of an exemplary method  127 , which may be performed within the context of the block  126  of  FIG. 7 . The method  127  is to calculate a risk-adjusted commitments receivable balance for a particular payee user. The receivable calculation module  78  may perform the method  127 . 
     The method commences at block  142  with the identification of the funded commitments to the payee by performing a search of the commitments payable table  94 . 
     At block  144 , the module  78  sums identified funded commitments to the payee user, to thereby generate a funded commitments receivable total. 
     At block  146 , the module  78  identities unfunded payment commitments to the payee, again by performing a search of the commitments payable table  94 . 
     At block  148 , the module  78  sums the unfounded payment commitments to the relevant payee user to generate an unfunded commitments receivable total. 
     Moving on to block  150 , utilizing the risk model  112 , the receivable calculation module  78  applies a risk profile function to the unfunded commitments receivable total, thereby to generate a risk-adjusted unfunded commitments receivable total. 
     At block  152 , the receivable calculation module  78  then sums the funded commitments receivable total, and the risk-adjusted funded commitments receivable total, to generate the risk-adjusted commitments receivable value total, which may then be written into the user table  92 , or otherwise stored within the micropayment system  24 . The method  127  then ends at block  154 . 
     While the risk adjustment is described above as being performed with respect to unfunded commitments to a payee user, the present invention is not so limited. In alternative embodiments of the present invention, the risk adjustment may be performed with respect to an entire commitments receivable total, and need not be performed only on the unfunded component thereof. 
       FIG. 11  illustrates an exemplary payment commitment receipt interface  180  that may be presented to a user of the micropayment system  24  via a respective web server  32 . Specifically, the interface  180  may be presented to a payee user in order to advise the payee user of receipt of a payment commitment from a payor user. To this end, the interface  180  may identify the payor user to the payee user via a payor field  182 , and may also communicate the amount of the payment commitment within an amount field  184 . 
     The interface  180  is also shown to include a statement portion  188 , which communicates to the payee user a total of unfunded commitments receivable  190 , a total funded commitments receivable  192 , a total commitments receivable  194  and a risk-adjusted commitments receivable total  196 , calculated in the manner described above. 
     In one embodiment of the present invention, the micropayment system  24  my also allow a payee user to select from a list of eligible payor users from which the payee user would prefer to receive a funding payment. To this end,  FIG. 12  illustrates an exemplary payable interface  198 , which may be presented to a payee user, advising the payee user that a commitments receivable balance exceeds a threshold that is eligible for a funding payment, and also presenting a list  199  of eligible payers, together with amounts that the eligible payers are eligible to pay. The payable interface  198  also includes a “proceed to payment service” button  176  that, in the manner described above, may initiate an interaction between the micropayment system  24  and the settlement system  22 . 
       FIG. 13  shows a diagrammatic representation of machine in the exemplary form of a computer system  200  within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. in alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, white only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
     The exemplary computer system  200  includes a processor  202  (e.g., a central processing unit (CPU), a graphics processing unit (CPU) or both), a main memory  204  and a static memory  206 , which communicate with each other via a bus  208 . The computer system  200  may further include a video display unit  210  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  200  also includes an alphanumeric input device  212  (e.g., a keyboard), a user interface (UI) navigation device  214  (e.g., a mouse), a disk drive unit  216 , a signal generation device  218  (e.g., a speaker) and a network interface device  220 . 
     The disk drive unit  216  includes a machine-readable medium  222  on which is stored one or more sets of instructions and data structures (e.g., software  224 ) embodying or utilized by any one or more of the methodologies or functions described herein. The software  224  may also reside, completely or at least partially, within the main memory  204  and/or within the processor  202  during execution thereof by the computer system  200 , the main memory  204  and the processor  202  also constituting machine-readable media. 
     The software  224  may further be transmitted or received over a network  226  via the network interface device  220  utilizing any one of a number of well-known transfer protocols (e.g., HTTP). 
     While the machine-readable medium  292  is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. 
     Thus, a method and system to enable the transfer of micropayments to a vendor have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.