U.S. patent application number 13/273792 was filed with the patent office on 2012-02-09 for method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor.
This patent application is currently assigned to eBay Inc.. Invention is credited to Pierre M. Omidyar.
Application Number | 20120036044 13/273792 |
Document ID | / |
Family ID | 34793572 |
Filed Date | 2012-02-09 |
United States Patent
Application |
20120036044 |
Kind Code |
A1 |
Omidyar; Pierre M. |
February 9, 2012 |
METHOD AND SYSTEM TO FACILITATE A PAYMENT IN SATISFACTION OF
ACCUMULATED MICROPAYMENT COMMITMENTS TO A VENDOR
Abstract
Methods and systems for facilitating payments between payors and
payees are presented. In an example, a plurality of payment
commitments made to a payee is accessed. The plurality of payment
commitments are made by a plurality of payors to the payee and
contribute to a total commitment receivable value of the payee. The
total commitment receivable value is calculated based on the
plurality of payment commitments made to the payee. A priority of
the total commitment receivable value of the payee relative to
other total commitment receivable values of other payees is
determined. A payment process is initiated based at least in part
on the priority of the total commitment receivable value of the
payee. The payment process includes a transfer of the total
commitment receivable value from one of the payors to the
payee.
Inventors: |
Omidyar; Pierre M.;
(Henderson, NV) |
Assignee: |
eBay Inc.
San Jose
CA
|
Family ID: |
34793572 |
Appl. No.: |
13/273792 |
Filed: |
October 14, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12544919 |
Aug 20, 2009 |
8051007 |
|
|
13273792 |
|
|
|
|
10741091 |
Dec 19, 2003 |
7702584 |
|
|
12544919 |
|
|
|
|
Current U.S.
Class: |
705/26.41 |
Current CPC
Class: |
G06Q 20/26 20130101;
G06Q 20/367 20130101; G06Q 40/12 20131203; G06Q 20/10 20130101;
G06Q 20/102 20130101; G06Q 20/02 20130101; G06Q 20/04 20130101;
G06Q 20/06 20130101; G06Q 30/0613 20130101; G06Q 30/04 20130101;
G06Q 20/4016 20130101; G06Q 20/29 20130101 |
Class at
Publication: |
705/26.41 |
International
Class: |
G06Q 30/06 20120101
G06Q030/06 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 10, 2003 |
US |
PCT/US03/35950 |
Claims
1. A method comprising: accessing a plurality of payment
commitments made to a payee by a plurality payors, the plurality of
payment commitments contributing to a total commitment receivable
value of the payee; calculating the total commitment receivable
value of the payee based on the plurality of payment commitments
made to the payee; determining a priority of the total commitment
receivable value of the payee relative to other total commitment
receivable values of other payees; and initiating a payment process
based at least in part on the priority of the total commitment
receivable value of the payee, the payment process comprising a
transfer of the total commitment receivable value from one of the
payors to the payee.
2. The method of claim 1, the determining of the priority of the
total commitment receivable value of the payee being based at least
in part on an identity of the payee.
3. The method of claim 1, further comprising placing into a funding
queue a queue entry representing the total commitment receivable
value of the payee, the funding queue comprising a plurality of
queue entries corresponding to the other total commitment
receivable values of the other payees.
4. The method of claim 3, the determining of the priority of the
total commitment receivable value of the payee being based on an
elapsed period of time since the queue entry was placed in the
funding queue.
5. The method of claim 3, the determining of the priority of the
total commitment receivable value of the payee being based on a
first in, first out priority scheme relating to the funding
queue.
6. The method of claim 1, further comprising determining whether
the total commitment receivable value of the payee triggers a
crossing of a threshold, the initiating of the payment process
being at least in part in response to the determining of whether
the total commitment receivable value of the payee triggers the
crossing of the threshold.
7. The method of claim 6, the threshold being applied on one of a
system level, a user level, and a funding transaction level.
8. The method of claim 1, the initiating of the payment process
being at least in part in response to a total commitments payable
value of one of the plurality of payors exceeding a threshold, the
total commitment payable value being based on a plurality of
payment commitments made by the one of the payors.
9. The method of claim 8, the initiating of the payment process
being at least in part in response to the total commitment
receivable value being satisfiable by the total commitment payable
value.
10. The method of claim 8, the initiating of the payment process
being at least in part in response to the total commitment
receivable value crossing a second threshold.
11. The method of claim 8, the initiating of the payment process
further comprising receiving from the one of the payors a selection
of the payee.
12. A system comprising: at least one processor; and modules
including instructions to be executed by the at least one
processor, the modules comprising: a micropayment database to store
a plurality of payment commitments made to a payee by a plurality
of payors, the plurality of payment commitments contributing to a
total commitment receivable value of the payee; a calculation
module to calculate the total commitment receivable value of the
payee based on the plurality of payment commitments made to the
payee; and a payment allocation module to determine a priority of
the total commitment receivable value of the payee relative to
other total commitment receivable values of other payees, and to
initiate a payment process based at least in part on the priority
of the total commitment receivable value of the payee, the payment
process comprising a transfer of the total commitment receivable
value from one of the payors to the payee.
13. The system of claim 1, the priority of the total commitment
receivable value of the payee being based on an attribute of the
payee.
14. The system of claim 1, further comprising: a funding queue to
store a plurality of queue entries corresponding to the other total
commitment receivable values of the other payees; the payment
allocation module to place into the funding queue a queue entry
representing the total commitment receivable value of the
payee.
15. The system of claim 14, the priority of the total commitment
receivable value of the payee being based on an elapsed period of
time since the queue entry was placed in the funding queue.
16. The system of claim 14, the priority of the total commitment
receivable value of the payee being based on a first in, first out
priority scheme relating to the funding queue.
17. The system of claim 12, further comprising: a threshold
assessment module to determine whether the total commitment
receivable value of the payee triggers a crossing of a threshold;
the payment allocation module to initiate the payment process in
response to the total commitment receivable value of the payee
triggering the crossing of the threshold.
18. The system of claim 17, the threshold assessment module to
apply the threshold on one of a system level, a user level, and a
funding transaction level.
19. The system of claim 12, the payment allocation module to
initiate the payment process at least in part in response to a
total commitments payable value by one of the plurality of payors
exceeding a threshold, the total commitment payable value of the
payor based on a plurality of payment commitments made by the
payor.
20. A non-transitory computer-readable medium comprising
instructions that, when executed by at least one processor of a
machine, cause the machine to perform operations comprising:
accessing a plurality of payment commitments made to a payee by a
plurality of payors, the plurality of payment commitments
contributing to a total commitment receivable value of the payee;
calculating the total commitment receivable value of the payee
based on the plurality of payment commitments made to the payee;
determining a priority of the total commitment receivable value of
the payee relative to other total commitment receivable values of
other payees; and initiating a payment process based at least in
part on the priority of the total commitment receivable value of
the payee, the payment process comprising a transfer of the total
commitment receivable value from one of the payors to the payee.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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)).
[0004] 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.
[0005] 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.
[0006] 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 '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
[0007] 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:
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] FIG. 5 is a block diagram illustrating an exemplary
commitments receivable table that is populated with values.
[0013] 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.
[0014] 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.
[0015] FIG. 8 is a flowchart illustration of an exemplary method to
calculate a risk-adjusted commitments receivable balance for a
particular payee user.
[0016] FIG. 9 illustrates an exemplary payment commitment interface
that may be generated and presented by the micropayment system.
[0017] FIG. 10 illustrates an exemplary payable interface that may
be generated and presented by the micropayment system.
[0018] 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.
[0019] 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.
[0020] 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
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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).
[0025] 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).
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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).
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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).
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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."
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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,
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] Moving on from block 134 of the method 120, the method 120
en terminates at block 136.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] At block 144, the module 78 sums identified funded
commitments to the payee user, to thereby generate a funded
commitments receivable total.
[0083] At block 146, the module 78 identities unfunded payment
commitments to the payee, again by performing a search of the
commitments payable table 94.
[0084] At block 148, the module 78 sums the unfounded payment
commitments to the relevant payee user to generate an unfunded
commitments receivable total.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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).
[0095] 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.
[0096] 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.
* * * * *