KR100847710B1 - Facilitating micropayments between a plurality of parties - Google Patents

Abstract

The present invention is directed to a method and system that facilitates micropayment between a plurality of parties (FIG. 3). A first plurality of micropayment commitments made by the first party are registered (70), and the first plurality of payment commitments contribute to the total commitment payable value for the first party. A second plurality of payment commitments made to the second party are registered (72), and the second plurality of payment commitments contribute to the total commitment receivable value for the second party. The total commitment receivable value for the second party is calculated using the hazard indication 81 (78). The total commitment receivable value for the second party is identified as reimbursable by the total commitment payable value for the first party. In response to this determination, a payment process is initiated for payment of the total commitment receivable value by the first party to the second party.

Micropayment, commitment payable value, commitment acceptable value

Description

FACILITATING MICROPAYMENTS BETWEEN A PLURALITY OF PARTIES}

FIELD OF THE INVENTION

FIELD OF THE INVENTION The present invention generally relates to the field of commercial automation, and more particularly, to a system that enables a vendor to make payments as reimbursement of accumulated micropayment commitments.

Background of the invention

Electronic payments between trading parties are made more and more common because of the increasing accessibility of the technology to make these payments. For example, today, most vendors can handle credit and debit card transactions. Typically, network-based (or online) vendors rely heavily on electronic payment services, and many electronic payment methods (e.g., credit cards, debit cards, and other electronic payment services (e.g., PayPal). Online payment service)).

Many companies provide electronic payment (or funds transfer) services (eg, Visa, MasterCard, American Express, PayPal, etc.). Originally, such electronic payment services typically charge a fee for the provision of such services, on a per-transaction basis. In addition, these transaction fees are normally charged to the vendor providing the goods or services. These transaction fees do not attract the attention of the vendor, but in many cases the transaction fees are small when compared to the total transaction value. Vendors also believe that exceeding the appropriate cost is a convenience benefit for buyer and vendor modes.

Transaction fees imposed by various electronic payment services, as described above, are typically a per transaction fee, and often also include a fixed transaction fee. As the total transaction value decreases, naturally, as a percentage of the total transaction value, the fee per transaction increases, and attractiveness decreases for a vendor using such an electronic payment service. Because of this, vendors often do not try to accept electronic payments (eg, via credit card) if the total transaction value is small. The use of electronic payment services is not particularly noticeable when transaction costs begin to approach the profit margin associated with the transaction. For example, consider the situation where an online vendor sells less than $ 1 of electronic content (eg, an MP3 file). For example, assuming a per-transaction fee of $ 0.10, it can be seen that the vendor may not want to receive payments through the electronic payment service since 10% of the total transaction value is consumed as an electronic payment service fee. The problem is aggravated as the value per item decreases.

In order to solve the problem of transaction fees associated with so-called "small payment", a number of solutions have been proposed. One such solution is described in Jan. 1998 at "Decentralized Micropayment Consolidation", a proceeding of the International Conference on Distributed Computing Systems (ICDS '98) held in Amsterdam, the Netherlands. Proposed by Chomicki et al. Specifically, protocols based on the concept of debt consolidation in a decentralized network environment are described in this document.

Summary of the invention

According to a first aspect of the present invention, a method is provided for facilitating micropayments between a plurality of parties. A first plurality of payment commitments made by the first party are registered, and the first plurality of payment commitments contribute to the total commitment payable value for the first party. A second plurality of payment commitments made to the second party are registered, the second plurality of payment commitments contributing to a total commitment receivable value for the second party. The total commitment receivable value for the second party is calculated using a risk indication. The total commitment receivable value for the second party is identified as reimbursable by the total commitment payable value for the first party. In response to this determination, a payment process is initiated for the payment of the total commitment receivable value by the first party to the second party.

Other features of the present invention will become apparent from the accompanying drawings and the description that follows.

Brief description of the drawings

The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements.

1 is a schematic diagram of a networked trading environment in accordance with one exemplary embodiment of the present invention in which a client-server architecture is deployed.

2 is a schematic diagram of a networked trading environment in accordance with another embodiment of the present invention in which the micropayment system is shown deployed as a peer-to-peer system.

3 is a block diagram illustrating in more detail a micropayment application in accordance with one exemplary embodiment of the present invention, which forms part of a micropayment system.

4 is a high-level entity-relationship diagram illustrating various tables in accordance with one exemplary embodiment of the present invention, which may reside within a micropayment database associated with a micropayment system.

5 is a block diagram illustrating an exemplary commitment receivable table with values.

6 is a flow diagram of a method according to an exemplary embodiment of the present invention, whereby after calculating the total commitment receivable value owed to the recipient user, the total commitment receivable value is assigned to the funding queue. You may

7 is a flow diagram illustrating a method in accordance with one exemplary embodiment of the present invention, to facilitate payment between parties for an aggregate payment commitment.

8 is a flowchart of an example method for calculating a risk-adjusted commitment receivable balance for a particular recipient user.

9 illustrates an example payment commitment interface that may be generated and provided by the micropayment system.

10 illustrates an example payable interface that may be generated and provided by the micropayment system.

FIG. 11 illustrates an example payment commitment receiving interface that may be provided to a user of a micropayment system via each web server.

12 is an illustration of an exemplary payable interface that may be provided to a recipient user to notify the recipient user that the commitment receivable balance exceeds a threshold suitable for funding payment.

FIG. 13 is a schematic diagram of a machine in an exemplary form of a computer system in which a set of instructions may be executed to cause a machine to perform any one or more methods described herein.

details

A method and system are described that enable a vendor to make a micropayment transfer. 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. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details.

Although the term "small payment" is used throughout this specification, it does not limit the invention to the processing of payments below a certain value. The present invention may find an application of the processing of payment of any value, and the processing of micropayments is described as using a scenario in which the present invention finds an application.

The exemplary embodiments described below of the present invention propose a payment system in which a payer user can make payment commitments to a recipient user, whereby these payment commitments exist for a small amount (eg, $ 0.05). do. Thereafter, payment commitments made by the payer user are registered for both the payer user and the recipient user. It can be seen that over time, for example, the total value of a number of payment commitments made by a payer user to a plurality of recipient users increases. Similarly, the total amount of payment commitments made to the recipient user also increases, possibly by multiple payer users. In order to reduce transaction costs associated with the processing of these various payment commitments, one exemplary embodiment of the present invention relates to a total value wherein a payer user includes an accumulated amount of payment commitments made by the payer user. Proposes a threshold that may be requested to fund (eg, make a payment). Similarly, the recipient user may be adapted to receive payments as reimbursement of the accumulated payment commitments when the accumulated total value of the payment commitments made to that recipient user exceeds a threshold. One aspect of one exemplary embodiment of the present invention relates to the determination of which payer user should make payment to which recipient user, and another aspect of the exemplary embodiment of the present invention is when such payment is made And how much this payment should be. Reimbursement of multiple payment commitments by accumulating payment commitments owed by the payer user, owed to the recipient user, and performing a single payment transaction (or a reduced number of payment transactions) as reimbursement of multiple accumulated payment commitments. It can be seen that the transaction costs associated with this may be reduced.

In addition, exemplary embodiments of the present invention include unfunded payment commitments (eg, payment commitments where the payer user has not made payments as compensation) and funded commitments (eg, paid by the payer user). The difference between the payment commitment associated with doing

1 is a schematic diagram of a networked trading environment 10 in accordance with one exemplary embodiment of the present invention with a client-server architecture deployed. A number of client-server machines are shown to be coupled via a network 20 to a number of server-side machines and processes. For example, client machine 12 is shown to host and run a first client application in an exemplary form of web browser 14, and second client machine 16 is a published application program interface (API). Is shown to execute an additional client 18 that may communicate via one or more server-side machines. Each client machine 12 and 16 is a network 20 that may include wired, wireless or some combination of wired and wireless technology (eg, the Internet, a local area network (LAN), a wide area network). Shown to be coupled to)). In addition, the network 20 may use any one of a number of well-known protocols (eg, HTTP) to facilitate communication between the server-side and the client machine.

Next, referring to the server-side, three systems, namely, a settlement system 22, a micropayment system 24, and a trading system 26 are coupled to the network 20. Although each system 22, 24, and 26 is shown in FIG. 1 as a separate and separate system, in another embodiment of the present invention, the components and functions of these systems may be integrated into one or more related systems. . Each example system 22, 24, and 26 is shown to have a similar three-tier structure, which includes a database server 28 that facilitates access to an associated database, each application. One or more application server machines 30 for hosting and executing, one or more web servers 32 for generating and / or serving web pages (eg, HTML pages) in response to requests received from the client-side, and One or more application program interface (API) servers 34 that provide access to programs in the associated system. For example, API server 34 may generate and serve an extensible markup language (XML) file to the requesting machine in response to a request received from the client-side.

Next, in detail with regard to the settling system 22, the appropriate application server machine 30 is one that enables the transfer of values (e.g., dollars or proprietary currency) between trading partners. The above settlement application 42 is hosted. In addition, the settlement application 42 can read data from the settlement database 40 and write the data to the settlement database 40 via the database server 28. Settlement system 22 may support a payment service, such as a PayPal payment service operated by PayPal, Inc., located in Mountain View, California.

Similarly, micropayment system 24 hosts one or more micropayment applications 38 on application server machine 30, which micropayment applications 38, via database server 28, perform micropayment database. Write and read access to data stored on 36. Additional details regarding the exemplary micropayment application 38 are described in more detail below.

Trading system 26 hosts one or more trading applications 46 on a suitable application server machine 30, which trading application 46, via database server 28, is stored on trade database 44. Write and read access to data. Trading application 46 may include one or more price-setting applications (eg, auction application, fixed-price application, etc.), whereby a value for agreement between the parties may be established. . Another trading application 46 may, for example, include a reputation application that tracks historical information and feedback of transactions regarding a user. In addition, such reputation applications may be used by these systems to disclose reputation information about a user so that the user establishes credibility within the trading system 26 and to evaluate the reliability, credit and risk for a particular user. Such reputation information may be made available to other systems (eg, Settlement System 22 or Micropayment System 24) or potential trading partners. One embodiment of trading system 26 is an eBay on-line market run by eBay Corporation, San Jose, California.

FIG. 2 is a networked trading environment in accordance with an embodiment of another method of the present invention, shown in contrast to the server-based system described above with reference to FIG. 1, wherein the micropayment system is deployed as a peer-to-peer system. Schematic diagram of 50. For this purpose, FIG. 2 shows a networked trading environment 50, including user machines 52 and 58, each of which has a respective peer-to-peer micropayment application 54 and 60. ). Each user machine 52 and 58 is shown to be coupled to a network 64 (eg, the Internet), such that the micropayment application 54 and 60 can communicate over the network 64. In addition, each micropayment application 54 and 60 may access and structure local micropayment databases 56 and 62, respectively, to provide various functions as described in more detail below.

2 also shows a settlement system 22 and a trading system 26, which are server-based systems in which appropriate micropayment applications 54 and 60 can communicate over the network 64. Further, in another embodiment of the present invention, in contrast to the server-based structure shown in FIG. 2, the settling system 22 and / or trading system 26 are deployed using a peer-to-peer structure. May be In addition, various components of either the system 22 or the trading system 26 may be arranged as a peer-to-peer system in another embodiment. For example, a peer-to-peer reputation system or a peer-to-peer risk analysis system may be used in connection with a micropayment system that is server-based or itself a peer-to-peer system.

3 is a more detailed description of the micropayment application 38, which may be hosted through one or more application servers 30 of the micropayment system 24 shown in FIG. 1, in accordance with an exemplary embodiment of the present invention. A block diagram is provided for explanation. Also, of course, the illustrated micropayment application 38 may form a sub-application or module of a peer-to-peer stand-alone micropayment application 54 that runs through the user machine 52. It can be seen that.

Exemplary micropayment application 38 includes a payable commitment registration module 70 that operates to register a payment commitment that may be made by a payer user using micropayment system 24. For example, the micropayment system 24 may identify the payee user that the payer user wants the payer user to make a payment commitment, and use the payer user to determine a value for the appropriate payment commitment (e.g., For example, it may provide one or more user interfaces that may also specify a currency value). One embodiment of the present invention relates to a payment commitment, either an unfunded payment commitment (e.g., an actual payer user does not make an actual payment to reimburse one or more payment commitments) or a funded payment commitment (e.g., A payer user classifies payment commitments as any one of which a payment is made in reimbursement of one or more payment commitments.

Payable commitment registration module 70 may transmit commitment information (eg, to be included in a markup language document) and receive payment commitment information from a payer user, such as web server 32 and / or API server. May be in communication with 34. Also, upon receipt of payment commitment information, payable commitment registration module 70 operates to record this information in an appropriate table in micropayment database 36. Such a table may include, for example, a commitment payable table 94 and a commitment receivable table 96 described in detail below with reference to FIG. 4.

Similarly, receivable commitment registration module 72 operates to receive commitment information regarding payment commitments to the recipient user and to register such payment commitment information in the appropriate table or tables in micropayment database 36. For example, the receivable commitment registration module 72 may record the receivable commitment information in the commitment receivable table 96 described in detail below with reference to FIG. 4.

Both payable commitment registration module 70 and receiveable commitment registration module 72 are in communication with a recurring commitment module 74. The recurring commitment module 74 is responsible for generating a recurring payment commitment (as may be defined by the paying user, as may be defined by the paying user) as defined by the paying user, and registering modules 70 and 72. In response to creating and / or updating records in this appropriate table, it is responsible for conveying appropriate commitment information to registration modules 70 and 72. For example, consider that a particular payer user may wish to make a monthly payment commitment to a particular recipient user (eg, for a subscription to a particular service). The cyclical commitment module 74 then processes this cyclical commitment.

Threshold adjustment module 76 in accordance with one exemplary embodiment of the present invention is a threshold that triggers a funding transaction (eg, initiation of a payment process) as reimbursement of payment commitments registered in micropayment system 24. Easily describe the value or specify a threshold value by itself. For example, the payable threshold may be specified in relation to the payable commitment of the payer user, so that if the total value of the payment commitment made by the payer user exceeds the payable threshold, the payment process may occur. Initiated, the payer user funds an appropriate unfunded payment commitment.

Similarly, the receivable threshold may be specified by the threshold adjustment module 76, which receivable threshold, as an indemnification of the payment commitment, when exceeded by the value of the payment commitment made to the recipient user. The total threshold value that renders to the recipient user suitable for receiving the value.

In one embodiment of the present invention, the threshold adjustment module 76 simply causes an administrator of the micropayment system 24 to provide one or more of, for example, one of the payable threshold or the receivable threshold. May operate to specify a threshold (eg, $ 5.00). For example, the administrator of micropayment system 24 may specify different thresholds that may apply to various pairs of individual payer or recipient users, or payer / recipient combinations.

In another embodiment of the present invention, the threshold adjustment module 76 allows an individual user to, for example, pay within a constraint of a certain minimum and maximum value applicable to the appropriate user and / or Alternatively, the receivable threshold may be specified.

In another embodiment of the present invention, threshold adjustment module 76 may automatically calculate the payable threshold and / or the receivable threshold using various information sources. For example, if the micropayment system 24 knows that a certain settling system 22 is used in connection with a particular funding event, the threshold adjustment module 76 may be replaced by an appropriate settling system 22. The threshold may be adjusted depending on the transaction fee charged. Consider a particular embodiment where the settling system 22 increases transaction fees associated with this funding event. In this case, threshold adjustment module 76 may increase the threshold to maintain the transaction fee at a predetermined maximum percentage of the funding value. In yet another example embodiment, threshold adjustment module 76 may dynamically adjust the threshold based on whether a particular recipient user has failed to achieve a predetermined rate of payment commitment. For example, the threshold adjustment module 76 may automatically reduce the funding receivable threshold to prevent the associated recipient user from waiting for an unacceptable amount of time before funding the payment commitment. have. In addition, if the payer user does not make payment commitments at a predetermined rate, threshold adjustment module 76 may also fund the payable threshold associated with the user to extract the funding within an acceptable time period. May be reduced.

In addition, threshold adjustment module 76 may consider attribute or attribute information associated with the payer user or the recipient user in evaluating a threshold associated with that user. For example, if historical information or reputation information associated with that user indicates an increased risk or a reduced risk associated with obtaining funding from the payer user, threshold adjustment module 76 may fund the user. The payable threshold may be adjusted automatically. In yet another exemplary embodiment, threshold adjustment module 76 may increase or decrease the threshold over time. For example, the threshold may start at a certain level (e.g. $ 5.00), and even if the funding payment is very small, in order to ultimately make the payer user responsible for making the funding payment, the minimum allowable transaction To reach the value, it may be reduced by a certain amount each month (eg, $ 1.00 per month).

In addition, threshold adjustment module 76 may specify a threshold with a change in resolution. For example, the threshold adjustment module 76 may specify a threshold to be applied on the system level across the micropayment system 24. In addition, threshold adjustment module 76 may specify a threshold to be specified at the funding transaction level, either at the user-level or in accordance with various circumstances.

FIG. 3 shows a threshold adjustment module 76 coupled to threshold evaluation module 80, wherein threshold evaluation module 80 specifies that the amount of commitment payable for the amount of commitment receivable is specified. Operate to evaluate whether a threshold is exceeded. The operation of threshold evaluation module 80 is described in greater detail below with reference to FIG.

Further, in one exemplary embodiment, micropayment application 38 is receivable operative to calculate a total commitment receivable value for the recipient user, using a risk profile associated with the user (eg, recipient user). It is shown to include a calculation module 78. In another embodiment of the present invention, the calculation of the total commitment receivable value may take into account other risk information. Thus, the present invention is not limited to the use of a risk profile associated with a user and may include the use of any information for which risk is determined or inferred.

Receivable calculation module 78 is shown to communicate with risk assessment module 81, which determines a risk profile associated with a user (eg, a recipient user). For example, risk assessment module 81 may use the historical information and reputation information to create a risk profile for the user (otherwise may calculate a risk value for use in micropayment system 24). ). Historical information and / or reputation information used by risk assessment module 81 may be obtained locally from micropayment system 24 or, for example, reputation information obtained from trading system 26 and It may be obtained from another source, such as payment information of the history obtained from the settlement system 22. In addition, risk assessment module 81 may obtain information from a third party information vendor, such as an equifax and a credit score organization.

Various other information sources may be used by risk assessment module 81 in calculating risk values (eg, risk profiles for users) for use in micropayment system 24. For example, the type of merchandise or service provided by a particular user may be involved. For example, gaming or pornography services are typically at a higher default risk by payer users. In addition, the geographic location of the payer user or recipient user may be related. It can be appreciated that any type of user, or any combination of information associated with any party in a particular transaction, may be used by risk assessment module 81 in evaluating risk. In addition, the assessment risk may be used beyond the calculation of the total commitment receivable value for the recipient user and, for example, risk-adjusting other payment values and other purposes of use in the micropayment system 24, as described below. It may also be used to.

In addition, risk assessment module 81 is shown to provide input to threshold adjustment module 76 such that, if allowed, causes module 76 to use the risk profile in adjusting the threshold associated with the user. It can be done.

The micropayment application 38 also includes a communication module 82, such as the micropayment application 38 and other applications (e.g., the settlement application 42 and the trading application 46 shown in FIG. 1). Various types of information in between, as well as delivery of messages (eg, e-mail, SMS messages, instant messages (IMs), etc.) to users of micropayment system 24. For example, communication module 82 may communicate an instruction to settlement application 42, which is part of the payment process, to initiate the transfer of funds from the payer user to the recipient user. The delivery of such instructions may be performed automatically in accordance with the instructions from the payment allocation module 84, or upon receipt of the instructions from the user for proper transfer of funds.

In addition, communication module 82 may receive a communication from another application. For example, the settling application 42 may communicate that the micropayment application 38 may register certain commitments as funded, indicating that funds are being successfully transferred from the payer user to the recipient user. It may also pass back to (82). For this purpose, communication module 82 is shown to communicate with registration modules 70 and 72 to cause these modules to register commitments as funded when appropriate and when confirmed by settlement application 42. Can be.

In addition, the communication module 82 is shown to be in communication with the threshold adjustment module 76, causing the threshold adjustment module 76 and the risk assessment module 81 to communicate with externals such as the settling system 22 and the trading system. Send communications to the system and receive communications from the external system.

Payment allocation module 84 operates in an exemplary embodiment of the present invention to instruct automatic transfer of funds from the payer user to the recipient user. For example, a payer user may define a preference in that payment commitments are automatically funded when the total amount of such commitments exceeds a funding payable threshold. The payer user may also specify a preference as to which recipient user will receive the appropriate funds, or set the criteria in that payment allocation module 84 may automatically identify the recipient user to whom the funds are to be allocated. It may be specified. For example, a particular user may define preferences and, accordingly, commit such payments by making a payment to a charity that is eligible to receive funding when the total amount of payment commitments for the payer user exceeds a threshold. Is funded.

As described in greater detail below, in one exemplary embodiment, when a funding receivable threshold is exceeded, the receivable commitment is received by the receivable calculation module 78, and the threshold evaluation module 80. May be placed in the funding queue. In such an embodiment, payment allocation module 84 may operate various algorithms to determine which of the appropriate recipients in the funding queue will be funded next or upon occurrence of a particular event. For example, payment allocation module 84 may assign funding to a funding queue based on simple first-in, first-out principles. Alternatively, payment allocation module 84 may apply more sophisticated criteria to the recipient's selection from within the funding queue.

4 is a high-level entity-relationship diagram illustrating various tables 90 in accordance with one exemplary embodiment of the present invention that may reside within the micropayment database 36. The table 90 includes a user table 92 in which contacts and other information specific to each user are stored. The commitment payable table 94 maintains a record of each payment commitment made to a particular user and includes the payer user, the recipient user, the total amount of the commitment, the date the commitment is made, the description of the commitment, and the amount of the commitment. And an identifier identifying an indication of whether or not the fund has been funded, and an indication of whether the commitment is in circulation.

Similarly, commitment receivable table 96 stores a record for each payment commitment that is receivable by a particular user, and records the same information recorded in commitment payable table 94.

By maintaining separate commitment payable table 94 and commitment receivable table 96, it can be seen that these tables may be used to perform double-entry verification. In yet another embodiment, the commitment payable table 94 and the commitment receivable table 96 may be combined into a single commitment table.

Settlement table 98 has a record for each funding transaction between a particular payer user and a particular recipient user. Records in the settling table 98 may be generated from information retrieved from the settling system 22 and also flag entries in the tables 94 and 96 as funded, in response to a particular funding transaction. May be used by the registration modules 70 and 72.

The table 90 further includes a user threshold table 100 that stores funding payable thresholds and funding receivable thresholds for each user whose record is in the user table 92. As mentioned above, in one exemplary embodiment of the present invention, the payable threshold and the receivable threshold may be specified at the user-level. In another embodiment of the present invention, the system threshold table 102 may store a funding payable threshold and a funding receivable threshold applicable to a system level within the micropayment system 24. Of course, both the user threshold table 100 and the system threshold table 102 may exist, and the recorded thresholds may be selectively applied by the payment allocation module 84, according to certain criteria.

Table 90 also includes a reputation table 104 having a record containing feedback information and history information for a particular user. For example, reputation table 104 may include transaction feedback information, payment feedback information, membership duration information, external credit or ID verification information, and subscriber information. As described above, the information in the flat table 104 may be generated internally within the micropayment system 24, or may be generated from external sources and systems (eg, the settlement system 22 and the trading system 26). ) May be received via the communication module 82).

5 is a block diagram illustrating an example commitment receivable table 96 having values. As shown, the various commitments are flagged as being funded or unfunded, depending on whether the appropriate payer has made a funding transaction that applies and covers the appropriate payment commitment.

In one exemplary embodiment, it can be seen that the user table 92 may reflect the commitment payable balance and the commitment receivable balance. Based on the information included in the commitment payable table 94 and the commitment receivable table 96, the receivable calculation module 78 may periodically update these balances.

6 is a flow diagram of a method 110 in accordance with one exemplary embodiment of the present invention, whereby the micropayment application 38 calculates the total commitment receivable value owed to the recipient user, and then receives the total commitment. You can also assign a value to the funding queue. Specifically, the commitment receivable table 96 provides input to the receivable calculation module 78 in the form of raw commitment receivable information. Receivable calculation module 78 deploys risk model 112 to calculate a risk-adjusted commitment receivable value sum. The risk model 112 uses the information retrieved from the reputation table 104 to create a risk profile associated with the appropriate recipient user, and calculates the risk-adjusted commitment receivable sum as a function of the created risk profile. In one embodiment, the risk profile is applied only to the unfunded portion of the original commitment receivable sum, taking into account the uncertainty regarding the funding of the unfunded portion of the commitment receivable sum. In another embodiment of the present invention, the risk profile applied to the unfunded portion of the original commitment receivable sum is not specifically related to the recipient user, but may be applied throughout the micropayment system 24, or It may be calculated based on the payer user associated with the funded payment commitment.

The function of the risk profile applied by the receivable calculation module 78 may be a simple function (eg, a simple percentage calculation), or may be a more complex function considering a number of factors. For example, the risk profile (or other risk value) may be calculated using any of the types of information described above. Also, the function of the risk profile (or risk value) applied by the receivable calculation module 78 is subject to continuous improvement or adjustment by the administrator of the micropayment system 24 or by his machine learning. It may be.

Thereafter, the risk-adjusted commitment receivable sum is passed from the receivable calculation module 78 to the threshold evaluation module 80, and the threshold evaluation module 80 receives the risk-adjusted commitment receivable sum. A determination is made as to whether or not a threshold value that is eligible for funding the total amount is exceeded. By performing this evaluation, the threshold evaluation module 80 may use the information included in the threshold table 100 or 102 described above with reference to FIG. 4. As can be seen, depending on the system-level, user-level, or transaction-level, a threshold may be applied.

When the threshold evaluation module 80 determines that the risk-adjusted commitment receivable total is eligible to receive funding, the appropriate receivable total is entered into the funding queue 114. Each entry in funding queue 114 records the risk-adjusted commitment receivable sum, the recipient user, the date the receivable sum was entered into the funding queue, and the priority. In one embodiment, payment allocation module 84 may determine the priority. In particular, payment allocation module 84 may prioritize each entry in funding queue 114 based on a first-in, first-out, or more complex priority scheme. For example, an entry in which the recipient is a certain type of agency (eg, charity) or identified as a priority recipient may be prioritized before other entries. In another embodiment, a priority scheme may be used to prioritize entries in the funding queue to ensure that the recipient does not wait for an unacceptable time period prior to receipt of the funding.

FIG. 7 is a flow diagram illustrating a method 120 in accordance with one exemplary embodiment of the present invention, to facilitate payment between parties for a total payment commitment. The method 120 begins at block 122 with the provision of a payment commitment interface to the payer user. 9 illustrates an example payment commitment interface 160 that may be provided at block 122. As can be seen from FIG. 9, payment commitment interface 160 may include a recipient identification field 162 where the payer user may identify the recipient user, and a value associated with the payer user for the appropriate commitment. It may also include an amount field 164. In addition, payment commitment interface 160 includes a circulation 168 to allow the payer user to identify (eg, use a yes / no radio button) that the commitment is in circulation, and to provide a circular data field ( Specify a recurrence period in recursion date and recursion period field 170 in 169. In another exemplary embodiment, the interface 160 performs the number and frequency of payments, for example, "25 commitments of $ 0.10 each, one commitment per day." Other mechanisms may be provided to indicate a cycle such as

Referring back to FIG. 7, at block 124, the communication module 82 receives payment commitment information from the payer user (eg, via the web server 32 or the API server 34), and the payment. The commitment information includes the identifier for the recipient user, the total amount, the date, and the above-described circulation information.

In block 126, the payable commitment registration module 70 registers a payment commitment, based on the payment commitment information, for the payer user in the commitment payable table 94. Similarly, the receivable commitment registration module 72 registers a payment commitment for the recipient user of the commitment receivable table 96. In addition, the receivable calculation module 78 may calculate and update the commitment payable balance and the commitment receivable balance for each of the payer user and the recipient user in the user table 92 based on the received payment commitment information. have.

In decision block 128, as described above, the updated commitment receivable balance calculated in block 126 and reflected in the user table 92 is determined by the risk-adjusted commitment receivable balance calculated by the receivable calculation module 78. Or total amount).

In decision block 128, after updating the commitment payable balance, the threshold evaluation module 80 determines that the commitment payable balance for the payer is (eg, specified as a user-level or system-level threshold). Determine if a predetermined threshold for funding the payable threshold is exceeded. If the commitment payable balance for the payer user does not exceed the threshold, the method 120 ends at block 130.

On the other hand, if the commitment payable balance for the payer user exceeds the funding payable threshold, then in decision block 132, the payment allocation module 84 determines that the payee user (eg, vendor) is the payer user's. A determination is made as to whether there is a commitment receivable balance that is greater than or equal to the commitment payable balance. As described above, the commitment receivable balance is, in one exemplary embodiment, a risk-adjusted commitment receivable balance. The determination made by the payment allocation module 84 in decision block 132 may include a payment allocation module 84 that performs a search of the funding queue 114, which may be reimbursable by the payable user's commitment payable balance. It may also identify an entry with a commitment receivable sum. In addition, in performing the search of the funding queue 114, the payment allocation module 84 may consider the priority data associated with each entry when attempting to identify a suitable recipient user.

At decision block 132, if the payment allocation module 84 is successful in identifying the recipient user, the method 120 begins in which the payment process begins to achieve a funding payment from the paying user to the designated recipient user. Proceed to

In various embodiments of the present invention, initiation of the payment process at block 134 may take various forms. For example, the micropayment system 24 may provide the payer user with a payable interface 172, which is an exemplary embodiment shown in FIG. 10, at block 134, the payable interface 172. And (2) convey to the payer user that their commitment payable balance exceeds a threshold, and (2) the payer user is required to make a funding payment to the intended recipient user. In one exemplary embodiment of the present invention, payment allocation module 34 may actually identify, in decision block 132, multiple recipient users suitable for receiving the funding payment. In this example embodiment, the payable interface 172 includes a list of suitable recipient users 174, along with a mechanism (eg, a radio box) to select at least one of the suitable recipient users to receive the funding payment. ) May be provided to the payer user.

In addition, the payable interface 172 shown in FIG. 10 includes a user-selectable “go to payment service” button 176 to direct the payer user to the settling system 22. Conveniently, the settling system allows the payer user to make a funding payment to the selected recipient user. Therefore, the selection of the button 176, using the communication module 82, causes the micropayment system 24 to display the payer user identification information, the recipient user identification information, the total amount information, and the funding total amount information. 22). If the settlement system 22 is an allowed web-service, this information may be received via the appropriate API server 34. Thereafter, the settling application 42 of the settling system 22 may initiate the flow, whereby the funding transaction payment may be completed.

In another embodiment of the present invention, payment allocation module 84 may automatically deliver, at block 134, an instruction to cause the funding payment to be paid to the recipient user, without manual approval or intervention by the payer user. For example, payment allocation module 84 using communication module 82 may send instructions to settlement system 22 to perform funding payments to the recipient user's account.

In block 134, if the settling system 22 is used to end the payment, the settling system 22 may pass the confirmation information back to the micropayment system, where the information is communicated to the communication module 82. After it is received by, it is provided to registration modules 70 and 72. Thereafter, in response to receiving confirmation of the funding payment, registration modules 70 and 72 may flag the payment commitment in commitment tables 94 and 96 as unfunded.

Thereafter, moving from block 134 of method 120, the method 120 ends at block 136.

Referring again to decision block 132, when payment allocation module 84 is unable to determine a recipient user in funding queue 114 having a commitment receivable value that is greater than or equal to a commitment payable balance, payment allocation module 84 determines whether the payment allocation module 84 Start determining the recipient user with a commitment receivable balance that is above a threshold. In an exemplary embodiment of the present invention that includes a funding queue 114, the threshold evaluation module 80 has already identified and balances all commitment receivable balances that exceed the appropriate funding payable thresholds. Place it inside. In this case, payment allocation module 84 selects the next commitment receivable balance, from funding queue 114 and in accordance with the priority scheme used, to receive the funding payment. In another embodiment of the present invention, in decision block 138, the threshold evaluation module 80, after the payment allocation module 84, for the purpose of identifying a suitable recipient user, which may be dynamically selected from a suitable recipient user. Perform analysis on commitment receivable balance (eg, risk-adjusted, etc.).

At block 138, if payment allocation module 84 is unable to determine a suitable recipient user (eg, when funding queue 114 is empty), method 120 proceeds to block 136 and ends. On the other hand, if at least one suitable recipient user is identified, the method 120 proceeds to block 140 where a process is initiated where the payer user pays a funding payment to the recipient user. The method 120 then loops back from block 140 to decision block 128.

8 is a flow diagram of an example method 127 that may be performed within the context of block 126 of FIG. 7. The method 127 is for calculating a risk-adjusted commitment receivable balance for a particular recipient user. Receivable calculation module 78 may perform the method 127.

At block 142, the method begins with the identification of a commitment funded to the recipient by performing a search of the commitment payable table 94.

In block 144, the module 78 sums the identified funding commitments for the recipient user to generate the funded commitment receivable sum.

In block 146, the module 78 again identifies the unfunded payment commitment to the recipient by performing a search of the commitment payable table 94.

In block 148, the module 78 sums the unfunded payment commitments for the appropriate recipient user to generate an unfunded commitment receivable sum.

Moving to block 150, using the risk model 112, the receivable calculation module 78 applies the risk profile function to the unfunded commitment receivable sum, thereby adjusting the risk-adjusted unfunded commitment receivable sum. Generates.

Then, at block 152, the receivable calculation module 78 sums the funded commitment receivable total amount and the risk-adjusted unfunded commitment receivable total amount, which is then recorded in the user table 92 or made a micropayment. Generates a risk-adjusted commitment receivable value sum that may be stored in system 24. The method 127 then ends at block 154.

Although risk adjustment has been described above as being performed with respect to unfunded commitments to recipient users, the present invention is not so limited. In another embodiment of the present invention, risk adjustment may be performed with respect to the total commitment receivable amount, and need not be performed only for the unfunded component.

FIG. 11 illustrates an example payment commitment receiving interface 180 that may be provided to a user of the micropayment system 24 via each web server 32. In particular, an interface 180 may be provided to the recipient user to inform the recipient user of receipt of a payment commitment from the payer user. For this purpose, the interface 180 may identify the payer user for the recipient user, via the payer field 182, and may also pass the total amount of payment commitments within the total amount field 184.

In addition, the interface 180 is capable of receiving total unfunded commitment 190, total receivable total commitment 192, total receivable commitment 194, and risk-adjusted commitments, calculated in the manner described above. It is shown to include a statement portion 188 that delivers the receivable sum 196 to the recipient user.

Further, in one embodiment of the present invention, the micropayment system 24 may allow the recipient user to select from a list of suitable payment users that the recipient user prefers to receive funding payments. For this purpose, FIG. 12 illustrates an exemplary payable interface 198 that may be provided to the recipient user, informing the recipient user that the commitment receivable balance exceeds a threshold suitable for funding payment. It also provides a list 199 of suitable payers, together with the total amount suitable for the appropriate payer to pay. The payable interface 198 also includes a “go to payment service” button 176 that may initiate the interaction between the micropayment system 24 and the settling system 22 in the manner described above. .

FIG. 13 shows a schematic diagram of a machine in an exemplary form of computer system 200 in which a set of instructions may be executed to cause a machine to perform any one or more of the methods described herein. In yet another embodiment, the machine may operate as a standalone device or may be connected (eg, networked) to another machine. In a networked deployment, the machine may operate at the capacity of a server or client machine in a server-client network environment, or may operate as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular telephone, web appliance, network router, switch or bridge Or any machine capable of executing a set of instructions (or otherwise sequential) that specify an action to be taken by that machine. Also, while only a single machine is shown, “machine” means any machine that individually or jointly executes a set of (or multiple sets of) instructions for carrying out any one or more methods described below. May contain a collection.

Exemplary computer system 200 includes a processor 202 (eg, a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 204, which communicates with each other via a bus 208. Static memory 206. Computer system 200 may further include a video display unit 210 (eg, a liquid crystal display (LCD) or 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 generator ( 218 (eg, a speaker), and a network interface device 220.

Disk drive unit 216 stores one or more sets of instructions and data structures (e.g., software 224) stored in or utilized by any one or more methods or functions described herein. Machine-readable medium 222. In addition, the software 224 may reside completely or at least partially within the main memory 204 and / or within the processor 202 during execution by the computer system 200, and may also reside therein. And the processor 202 constitute a machine-readable medium.

In addition, the software 224 may be transmitted or received over the network 226 via the network interface device 220 using any one of a number of well known transfer protocols (eg, HTTP).

Although machine-readable medium 292 is shown as being a single medium in one embodiment, “machine-readable medium” refers to a single medium or multiple media (eg, to store one or more sets of instructions). For example, a centralized or distributed database, and / or its caches and servers). A "machine-readable medium" can also store, encode, or convey a set of instructions for execution by a machine and cause the machine to perform any one or more methods of the invention, or It should be construed to include any medium capable of storing, encoding or carrying a data structure used by or associated with a set of instructions. Thus, "machine-readable medium" is intended to include, but not limited to, solid-state memories, optical and magnetic media, and carrier signals.

Thus, a method and system have been described that enable vendors to make small payment transfers. Although the present invention has been described with reference to specific exemplary embodiments, it will be appreciated that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. The description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (60)

A registration module for registering a first plurality of payment commitments made by a first party in a database and registering a second plurality of payment commitments made to a second party in the database; A calculation module for retrieving a risk indication from the database and using the risk indication to calculate a total commitment receivable value for the second party; And Identifying the total commitment receivable value for the second party is satisfactory by the total commitment payable value for the first party, and in response to the determination, to the second party, the first A system for facilitating micropayments between a plurality of parties, comprising a payment application module for initiating a payment process for payment of the total commitment receivable value by a party, comprising: The first plurality of payment commitments contributes to the total commitment payable value for the first party, is made by the first party to a plurality of recipient parties, The second plurality of payment commitments contributes to the total commitment receivable value for the second party, is made to the second party by a plurality of payer parties, The risk indication includes a risk profile associated with one or more of the first or second parties and facilitates micropayment, determined using one or more of transaction history, payment history, transaction feedback, and payment feedback. system. The method of claim 1, The calculating module is configured to identify the second set of payment commitments, funded by a payer user, and unfunded by the payer user, the second plurality of payments. To identify an unfunded set of commitments, The calculating module is further configured to apply the function using the risk indication to the unfunded set of payment commitments to calculate a total unfunded commitment value portion of the total commitment receivable value. A system for facilitating micropayments, which is calculated. delete delete delete Claim 6 was abandoned when the registration fee was paid. The method of claim 1, And the plurality of recipient parties comprises the second party. delete The method of claim 1, And wherein the plurality of payer parties comprises the first party. The method of claim 1, The first plurality of payment commitments made by the first party are to be made over a period of time, Wherein the total commitment payable value varies over the time period to reflect a respective payment commitment of the first plurality of payment commitments. The method of claim 1, The second plurality of payment commitments made to the second party are made over a period of time, And wherein the total commitment receivable value varies over the time period to reflect each payment commitment of the second plurality of payment commitments. The method of claim 1, The registration module resides in a server where the first party and the second party are operatively coupled via a network, And wherein the registration module registers each of the first plurality of payment commitments and the second plurality of payment commitments with the server. The method of claim 1, The registration module resides in at least one of a first machine and a second machine associated with the first party and the second party, respectively, And the registration module registers each of the first plurality of payment commitments and the second plurality of payment commitments to be made on at least one of the first machine and the second machine. The method of claim 1, The payment application module may be reimbursed by the total commitment payable value for the first party after the total commitment receivable value exceeds a predetermined threshold value, wherein the payment application module may be reimbursed for the second party. A system that facilitates micropayment, identifying a total commitment receivable value. The method of claim 1, The payment application module determines whether the total commitment receivable value for the second party exceeds a predetermined threshold, and if it exceeds the threshold, the total commitment receivable value for the second party. A system that facilitates micropayments, allocating to a funding queue. The method of claim 14, The payment application module, as assigned to the funding queue, may be reimbursed by the total commitment payable value for the first party by identifying the total commitment receivable value for the second party, A system for facilitating micropayment, identifying the total commitment receivable value for the second party. The method of claim 15, A plurality of receivable values for a plurality of respective third parties are assigned to the funding queue, The payment application module communicates the plurality of receivable values to the first party and causes a selection by the first party of at least one of the receivable values to cause the total commitment payable to the first party. A system that facilitates micropayment that can be reimbursed by value. Claim 17 was abandoned upon payment of a registration fee. The method of claim 16, The transfer of the plurality of receivable values to the first party includes identifying the respective third party to the first party. Claim 18 was abandoned upon payment of a set-up fee. The method of claim 13, And the predetermined threshold is determined by at least one of a second user and an administrator of the system. Claim 19 was abandoned upon payment of a registration fee. The method of claim 13, Wherein the predetermined threshold is determined by an attribute associated with a second user. The method of claim 1, The payment application module may be reimbursed by the total commitment payable value for the first party after the total commitment payable value exceeds a predetermined payment threshold, and for the second party. A system for facilitating micropayment, identifying the total commitment receivable value. Claim 21 was abandoned upon payment of a registration fee. The method of claim 20, And said predetermined threshold is determined by at least one of a first user and an administrator of the system. Claim 22 was abandoned upon payment of a registration fee. The method of claim 20, Wherein the predetermined threshold is determined by an attribute associated with a first user. The method of claim 1, The payment application module resides in a server coupled to the network, Wherein the identification of the total commitment receivable value for the second party is performed at the server as reimbursable by the total commitment payable value for the second party. The method of claim 1, The payment application module resides in at least one of a first client machine and a second client machine associated with the first party and the second party, respectively, The identification of the total commitment receivable value for the second party, as reparable by the total commitment payable value for the first party, is at least one of the first client machine and the second client machine. A system for facilitating micropayment, carried out in the. The method of claim 1, And the payment application module initiates the payment process by providing an instruction to the first party to make the payment of the total commitment receivable value to the second party. The method of claim 1, The payment application module facilitates the micropayment process by initiating the payment process by providing communication to the second party regarding receipt of a payment of the total commitment receivable value to be received from the first party. The method of claim 1, The payment application module enables the first party to make a payment of the total commitment receivable value to the second party to initiate a payment process by the first party for a payment service. , A system that facilitates micropayment. Claim 28 was abandoned upon payment of a registration fee. The method of claim 1, The payment application module facilitates micropayment, initiating the payment process by connecting the second party to a payment system utilizing the second party's ability to receive payment of the total commitment receivable value. System. Claim 29 was abandoned upon payment of a set-up fee. The method of claim 1, The payment application module facilitates micropayment by initiating the payment process by automatically transferring the total commitment receivable value from the account of the first user to the second user. Claim 30 was abandoned upon payment of a registration fee. The method of claim 1, The registration module facilitates micropayment, registering at least one of a plurality of third parties, registering a recurring payment commitment by the first party, and registering a payment commitment in accordance with the recurring payment commitment. system. Registering a first plurality of payment commitments made by the first party; Registering a second plurality of payment commitments made to the second party; Using the indication of risk, calculating the total commitment receivable value for the second party; Identifying whether the total commitment receivable value for the second party is satisfactory by the total commitment payable value for the first party; And In response to the determination, initiating a payment process for payment of the total commitment receivable value by the first party to the second party, thereby facilitating micropayments between a plurality of parties. As a method, The first plurality of payment commitments contributes to the total commitment payable value for the first party, is made by the first party to a plurality of recipient parties, The second plurality of payment commitments contributes to the total commitment receivable value for the second party, is made to the second party by a plurality of payer parties, The risk indication includes a risk profile associated with one or more of the first or second parties and facilitates micropayment, determined using one or more of transaction history, payment history, transaction feedback, and payment feedback. Way. The method of claim 31, wherein Identifying a funding set of the second plurality of payment commitments as funded by a payer user, and identifying an unfunding set of the second plurality of payment commitments as unfunded by a payer user. , The calculating of the total commitment receivable value includes applying a function using the risk indication to the unfunded set of payment commitments to calculate a portion of the total commitment receivable value of the total unfunded commitment value. , To facilitate micropayment. delete delete delete The method of claim 31, wherein And the plurality of recipient parties comprises the second party. delete The method of claim 31, wherein Wherein the plurality of payer parties comprises the first party. Claim 39 was abandoned upon payment of a registration fee. The method of claim 31, wherein The first plurality of payment commitments made by the first party are to be made over a period of time, Wherein the total commitment payable value is modified over the time period to reflect a respective payment commitment of the first plurality of payment commitments. Claim 40 was abandoned upon payment of a registration fee. The method of claim 31, wherein The second plurality of payment commitments made to the second party are made over a period of time, And the total commitment receivable value is modified over the time period to reflect each payment commitment of the second plurality of payment commitments. Claim 41 was abandoned upon payment of a set-up fee. The method of claim 31, wherein And registering each of the first plurality of payment commitments and the second plurality of payment commitments is performed at a server where the first and second parties are coupled via a network. Claim 42 was abandoned upon payment of a registration fee. The method of claim 31, wherein The registration step of each of the first plurality of payment commitments and the second plurality of payment commitments, respectively, is associated with each of the first and second parties, each of the first and second machines coupled via a network. A method for facilitating micropayment, which is done at. The method of claim 31, wherein Identification of the total commitment receivable value for the second party is performed after the total commitment receivable value exceeds a predetermined threshold. The method of claim 31, wherein Identifying if the total commitment receivable value exceeds a predetermined threshold, and if the threshold is exceeded, assigning the total commitment receivable value for the second party to a funding queue. How to let. The method of claim 44, The identification of the total commitment receivable value for the second party, as reparable by the total commitment payable value for the first party, is assigned to the funding queue, the second party Identifying the total commitment receivable value for the micropayment. The method of claim 45, A plurality of receivable values for a plurality of respective third parties are assigned to the funding queue, The method identifies the plurality of receivable values for the first party and causes the selection by the first party of at least one of the receivable values to cause the total commitment payable value for the first party. A method for facilitating micropayment, comprising the step of making it reimburseable by Claim 47 was abandoned upon payment of a registration fee. The method of claim 46, The identification of the plurality of receivable values includes identifying the respective third party with respect to the first party. Claim 48 was abandoned when the setup fee was paid. The method of claim 43, Wherein the predetermined threshold is determined by a second user. Claim 49 was abandoned upon payment of a registration fee. The method of claim 43, Wherein the predetermined threshold is determined by an attribute associated with a second user. The method of claim 31, wherein Wherein the determination is performed when the total commitment payable value exceeds a predetermined threshold. Claim 51 was abandoned upon payment of a registration fee. 51. The method of claim 50, And said predetermined threshold is determined by a first user. Claim 52 was abandoned upon payment of a registration fee. 51. The method of claim 50, Wherein the predetermined threshold is determined by an attribute associated with a first user. Claim 53 was abandoned upon payment of a set-up fee. The method of claim 31, wherein Wherein the determination is performed at the server. Claim 54 was abandoned upon payment of a setup registration fee. The method of claim 31, wherein Wherein the determination is performed at any one of a first machine and a second machine associated with the first party and the second party, respectively. The method of claim 31, wherein Initiating the payment process includes providing an instruction to the first party to make the payment of the total commitment receivable value to the second party. The method of claim 31, wherein Initiating the payment process includes providing communication to the second party regarding receipt of a payment of the total commitment receivable value to be received from the first party. The method of claim 31, wherein Initiating the payment process includes directing the first party to a payment service, using the first party to make the payment of the total commitment receivable value to the second party. How to facilitate. The method of claim 31, wherein Initiating the payment process includes directing the second party to a payment system using the second party's ability to receive payment of the total commitment receivable value. Way. The method of claim 31, wherein The initiation of the payment process includes automatically transferring the total commitment receivable value from a first user's account to a second user. The method of claim 31, wherein Registering a recurring payment commitment by the first party to at least one of the first plurality of third parties, and registering a payment commitment, in accordance with the recurring payment commitment, to facilitate micropayment. .

Images