U.S. patent application number 10/329302 was filed with the patent office on 2004-01-29 for system and method for debt presentment and resolution.
Invention is credited to Evans, Scott L., Kent, Eben L., Stuckey, Kent D..
Application Number | 20040019560 10/329302 |
Document ID | / |
Family ID | 46298914 |
Filed Date | 2004-01-29 |
United States Patent
Application |
20040019560 |
Kind Code |
A1 |
Evans, Scott L. ; et
al. |
January 29, 2004 |
System and method for debt presentment and resolution
Abstract
A system and method for debt presentment and resolution through
an Intranet or Internet content provider is disclosed. The system
and method include a plurality of "transaction communities" which
are electronic forums allowing interaction between a plurality of
transactors and a plurality of creditors through a variety of
channels. The system of the invention allows transactors to access
and input information related to a particular debt and select the
method in which to complete the transaction. For example,
transactors may be provided with a URL for a content provider along
with a unique identification code from the collection agency(s)
through mail correspondence or other communication. Upon the
transactor entering the URL and entering the identification code,
the transactor may then proceed to choose from a variety of
settlement options listed on the HTML page. A database system then
records the transaction(s) and synchronizes with the database of
the collection agency(s).
Inventors: |
Evans, Scott L.; (Columbus,
OH) ; Kent, Eben L.; (Columbus, OH) ; Stuckey,
Kent D.; (Columbus, OH) |
Correspondence
Address: |
WARD & OLIVO
708 Third Avenue
New York
NY
10017
US
|
Family ID: |
46298914 |
Appl. No.: |
10/329302 |
Filed: |
December 23, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10329302 |
Dec 23, 2002 |
|
|
|
09267840 |
Mar 12, 1999 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 20/14 20130101; G06Q 20/108 20130101; G06Q 40/02 20130101;
G06Q 20/102 20130101; G06Q 40/025 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A method for producing the payment of a bill, debt or other
transactions, said method comprising the steps of: providing a
transaction interface for a creditor or vendor and user to exchange
information such that said user may complete a payment transaction
with said creditor or vendor; providing at least one computer in
communication with a computer network; storing control information
in a database; informing said user of said control information,
wherein said control information includes access information unique
to said creditor or vendor, said access information allowing said
user to access said transaction interface without system
enrollment; inviting said user to access said transaction interface
using said access information to complete said payment transaction;
providing access for said user to a transaction community upon
connection to said transaction interface and following input of
said access information; and interactively promoting said
information exchange between said user and said creditor or vendor
for said user to complete said transaction.
2. A method according to claim 1, wherein said transaction
interface is a Web site, said site including said transaction
community accessible by said user following input of said access
information, said software application enabling said interactive
exchange of information between said user and said creditor or
vendor.
3. A method according to claim 1, wherein said transaction
interface is an interactive voice response (IVR) telephone
system
4. A method according to claim 3, wherein said IVR system is
capable of interacting with said transaction community software
application following input of said access information enabling
said interactive exchange of information between said user and said
creditor or vendor.
5. A method according to claim 1, wherein said transaction
comprises payment by said user.
6. A method according to claim 1, wherein said transaction
comprises accessing information related to said payment.
7. A method according to claim 1, wherein said transaction
comprises disputing a debt.
8. A method according to claim 1, wherein said informing comprises
said user receiving a letter via regular mail.
9. A method according to claim 1, wherein said informing comprises
said user receiving an electronic message.
10. A method according to claim 1, wherein said informing comprises
said user receiving a telephone message.
11. A method according to claim 1, wherein said transaction results
in said transaction information being stored in said database.
12. A method according to claim 11, wherein said transaction
information may be retrieved by said creditor or vendor.
13. A method according to claim 1, said method further comprising
the step of: allowing said user to access information unrelated to
said debt, including financial, employment or demographic
information.
14. A method according to claim 1, said method further comprising
the step of: allowing said user to complete said payment
transaction using their checking account.
15. A method according to claim 14, said method further comprising
the step of: reporting receipt of said payment to said
database.
16. A method according to claim 1, said method further comprising
the step of: allowing for said payment by credit card over the
Internet.
17. A method according to claim 1, said method further comprising
the step of: allowing for said payment by credit card through the
mail.
18. A method according to claim 17, said method further comprising
the step of: reporting receipt of said payment to said
database.
19. A method according to claim 1, said method further comprising
the step of: allowing said debtor to make a charitable
contribution.
20. A method according to claim 19, said method further comprising
the step of: providing said user with a receipt acknowledging said
contribution.
21. A method according to claim 20, wherein said receipt is in
printed format.
22. A method according to claim 20, wherein said receipt is in
electronic format.
23. A method according to claim 19, said method further comprising
the step of: gathering contribution information in compliance with
charitable organization reporting regulations and compiling said
contribution information for reporting.
24. A method according to claim 1, said method further comprising
the step of: allowing said user to make a campaign
contribution.
25. A method according to claim 24, said method further comprising
the step of: providing said user with a receipt acknowledging said
contribution.
26. A method according to claim 25, wherein said receipt is in
printed format.
27. A method according to claim 25, wherein said receipt is in
electronic format.
28. A method according to claim 24, said method further comprising
the step of: gathering contribution information in compliance with
campaign reporting regulations and compiling said contribution
information for reporting.
29. A method according to claim 1, said method further comprising
the step of: providing advertising materials appropriate for said
user.
30. A method according to claim 1, said method further comprising
the step of: providing at least one of a plurality of reports
accessible by said creditor, said reports providing transaction
information from all payment channels.
31. A method according to claim 30, wherein creditor information is
automatically updated.
32. A method according to claim 1, said method further comprising
the step of: automatically loading one or more user restrictions
files.
33. A method according to claim 32, wherein said restrictions files
are related to rules selected from the group consisting of
coordination of service termination status accounts, minimum
payment requirements, payment method limitations, and payment
method privilege suspension.
34. A method according to claim 1, said method further comprising
the steps of: allowing account number rules to be applied at user
entry; and scrubbing said database prior to reporting to reduce
invalid or unknown transactions.
35. A method according to claim 1, said method further comprising
the step of: providing real-time notification of payment.
36. A method according to claim 1, said method further comprising
the step of: providing reports over the Internet of attempted and
successful payment initiations for customer use with restricted
access based on the internet protocol address and/or password
access.
37. A method according to claim 1, said method further comprising
the step of: providing an account level edit interface over the
Internet for customer use with restricted access based on internet
protocol address and/or password access.
38. A method according to claim 1, said method further comprising
the step of: integrating reporting of all payment transactions and
subsequent changes in status with conventional formats for daily
reporting with reconciliation support.
39. A method according to claim 1, said method further comprising
the step of: sending payment remittance and reconciliation
information to a backend financial information system.
40. A method according to claim 1, said method further comprising
the step of: managing non-sufficient funds check returns.
41. A method according to claim 40, wherein said managing further
comprises representment of returned check/ACH transactions.
42. A method according to claim 41, wherein said check/ACH
presentments are timed to target said user's automatic payroll
deposit schedule.
43. A method according to claim 1, said method further comprising
the step of: recognizing duplicate transactions.
44. A method according to claim 1, said method further comprising
the step of: automatically apply service fees to said users where
said service fees are authorized.
45. A method according to claim 1, said method further comprising
the step of: verifying the availability of funds to cover payments
by checks and/or checking account debits.
46. A method according to claim 1, said method further comprising
the step of: providing an advanced analytics framework to provide
instantaneous data associations of multi-variate data structures
within said database.
47. A system for producing the payment of bills, debts or other
transactions, said system comprising: at least one server computer
having a transaction interface for computing over a network; means
for a creditor to interact with said server computer for providing
control information to establish a database, said information
including access information unique to said creditor; means for
informing said user of said control information, including said
access information; interface means for said user to interact with
said server computer without enrollment using said access
information, said interface means enabling said user to perform
transactions on said server associated with said control
information; and means for storing transaction information entered
by said user.
48. A system according to claim 47, wherein said transaction
interface is a Web site, said site including a transaction
community accessible by said user following input of said access
information, said transaction community enabling said interactive
exchange of information between said user and said creditor.
49. A system according to claim 47, wherein said transaction
interface is an interactive voice response (IVR) telephone
system
50. A system according to claim 49, wherein said IVR system is
capable of interacting with said transaction community following
input of said access information enabling said interactive exchange
of information between said user and said creditor.
51. A system according to claim 47, wherein said transaction
comprises payment by said user.
52. A system according to claim 47, wherein said transaction
comprises accessing information related to said payment.
53. A system according to claim 47, wherein said transaction
comprises disputing a debt.
54. A system according to claim 47, wherein said means for
informing comprises a letter sent from said creditor to said user
via regular mail.
55. A system according to claim 47, wherein said means for
informing comprises an electronic message.
56. A system according to claim 47, wherein said informing
comprises a telephone message.
57. A system according to claim 47, wherein said transaction
information is stored in said database.
58. A system according to claim 57, wherein said transaction
information may be retrieved by said creditor from said database
having any of a plurality of formats.
59. A system according to claim 47, said system further comprising
means for allowing said user to access information unrelated to
said debt.
60. A system according to claim 59, wherein said information
unrelated to said debt is selected from the group consisting of
financial information, employment information and demographic
information.
61. A system according to claim 47, wherein said system further
comprises means for allowing said user to complete said payment
transaction using said user's checking account.
62. A system according to claim 47, wherein said system further
comprises means for allowing for said payment by credit card over
the Internet.
63. A system according to claim 47, wherein said system further
comprises means for allowing for said payment by credit card
through the mail.
64. A system according to claim 47, wherein said information
relates to a charitable organization, said interface means allowing
said user to make a payment to said charitable organization.
65. A system according to claim 64, said system comprising means
for providing said user with a receipt acknowledging said payment
to said charitable organization.
66. A system according to claim 65, wherein said receipt is in
printed format.
67. A system according to claim 65, wherein said receipt is in
electronic format.
68. A system according to claim 64, said system comprising means
for gathering contribution information in compliance with said
charitable organization reporting regulations and compiling said
contribution information for reporting.
69. A system according to claim 47, wherein said information
relates to a campaign, said interface means allowing said user to
make a payment to said campaign.
70. A system according to claim 69, said system comprising means
for providing said user with a receipt acknowledging said payment
to said campaign.
71. A system according to claim 70, wherein said receipt is in
printed format.
72. A system according to claim 70, wherein said receipt is in
electronic format.
73. A system according to claim 69, said system comprising means
for gathering contribution information in compliance with said
campaign's reporting regulations and compiling said contribution
information for reporting.
74. A system according to claim 47, wherein said system further
comprises revenue sharing means properly allocating collected funds
between creditors and service providers.
75. A system according to claim 47, wherein said system further
comprises means for providing said debtor with advertising
materials appropriate for said user.
76. A system according to claim 47, said system comprising means
for providing at least one of a plurality of reports accessible by
said creditor, said reports providing transaction information from
all payment channels.
77. A system according to claim 76, wherein creditor information is
automatically updated.
78. A system according to claim 47, said system comprising means
for automatically loading one or more user restrictions files.
79. A system according to claim 78, wherein said restrictions files
are related to rules selected from the group consisting of
coordination of service termination status accounts, minimum
payment requirements, payment method limitations, and payment
method privilege suspension.
80. A system according to claim 47, said system comprising means
for allowing account number rules to be applied at user entry, and
means for scrubbing said database prior to reporting to reduce
invalid or unknown transactions.
81. A system according to claim 47, said system comprising means
for providing real-time notification of payment.
82. A system according to claim 47, said system comprising means
for providing reports over the Internet of attempted and successful
payment initiations for customer use with restricted access based
on the internet protocol address and/or password access.
83. A system according to claim 47, said system comprising means
for providing an account level edit interface over the Internet for
customer use with restricted access based on internet protocol
address and/or password access.
84. A system according to claim 47, said system comprising means
for integrating reporting of all payment transactions and
subsequent changes in status with conventional formats for daily
reporting with reconciliation support.
85. A system according to claim 47, said system comprising means
for sending payment remittance and reconciliation information to a
backend financial information system.
86. A system according to claim 47, said system comprising means
for managing non-sufficient funds check returns.
87. A system according to claim 86, wherein said managing further
comprises representment of returned check/ACH transactions.
88. A system according to claim 87, wherein said check/ACH
presentments are timed to target said user's automatic payroll
deposit schedule.
89. A system according to claim 47, said system comprising
recognizing duplicate transactions.
90. A system according to claim 47, said system comprising means
for automatically applying service fees to said users where said
service fees are authorized.
91. A system according to claim 47, said system comprising means
for verifying the availability of funds to cover payments by checks
and/or checking account debits.
92. A system according to claim 47, said system comprising means
for providing an advanced analytics framework to provide
instantaneous data associations of multi-variate data structures
within said database.
93. A system for producing the payment of bills, debts or other
transactions, said system comprising: a server computer having an
interface for computing over a network; a database associated with
said server computer for storing control information associated
with a debt; means for generating a notice based upon said control
information, said notice comprising access information unique to a
creditor; means for sending said notice to a user; a transaction
community established for said creditor and accessible by said user
following input of said access information; and means for allowing
said user to resolve said debt with said creditor; wherein said
transaction community enables interactive exchange of information
between said user and said creditor; and wherein said notice
includes an invitation for said user to resolve said debt by
accessing said transaction community.
94. A system according to claim 93, wherein said creditor inputs
said information.
95. A system according to claim 93, wherein said Web site includes
access to said transaction community such that said user is enabled
to perform an interactive exchange of information with said
creditor.
96. A system according to claim 93, wherein said user may access
said information on said system through an interactive voice
response (IVR) telephone system.
97. A system according to claim 96, wherein said IVR system is
capable of interacting with said transaction community following
input of said access information enabling said interactive exchange
of information between said user and said creditor.
98. A system according to claim 93, wherein said user accesses said
information.
99. A system according to claim 93, wherein said user disputes said
debt.
100. A system according to claim 93, wherein said notice is a
letter sent from said system to said user via regular mail.
101. A system according to claim 93, wherein said notice is in the
form of an electronic message.
102. A system according to claim 93, wherein said notice is in the
form of a telephone message.
103. A system according to claim 93, wherein resolution of said
debt results in transaction information being stored in said
database.
104. A system according to claim 103, wherein said transaction
information may be retrieved by said creditor from said database in
any of a plurality of formats.
105. A system according to claim 93, said system further comprising
means for allowing said user to access information unrelated to
said debt.
106. A system according to claim 105, wherein said information
unrelated to said debt is selected from the group consisting of
financial information, employment information and demographic
information.
107. A system according to claim 93, wherein said system further
comprises means for allowing said user to complete said transaction
using said user's checking account.
108. A system according to claim 93, wherein said system further
comprises means for allowing for payment of said debt by credit
card over the Internet.
109. A system according to claim 93, wherein said system further
comprises means for allowing for payment of said debt by credit
card through the mail.
110. A system according to claim 93, wherein said information
relates to a charitable organization, said interface means allowing
said user to make a payment to said charitable organization.
111. A system according to claim 110, said system comprising means
for providing said user with a receipt acknowledging said payment
to said charitable organization.
112. A system according to claim 111, wherein said receipt is in
printed format.
113. A system according to claim 111, wherein said receipt is in
electronic format.
114. A system according to claim 110, said system comprising means
for gathering contribution information in compliance with said
charitable organization reporting regulations and compiling said
contribution information for reporting.
116. A system according to claim 93, wherein said information
relates to a campaign, said interface means allowing said user to
make a payment to said campaign.
117. A system according to claim 116, said system comprising means
for providing said user with a receipt acknowledging said payment
to said campaign.
118. A system according to claim 117, wherein said receipt is in
printed format.
119. A system according to claim 117, wherein said receipt is in
electronic format.
120. A system according to claim 116, said system comprising means
for gathering contribution information in compliance with said
campaign's reporting regulations and compiling said contribution
information for reporting.
121. A system according to claim 93, wherein said system further
comprises revenue sharing means for properly allocating collected
funds between creditors and service providers.
122. A system according to claim 93, wherein said system further
comprises means for providing said debtor with advertising
materials appropriate for said debtor.
123. A system according to claim 93, said system comprising means
for providing at least one of a plurality of reports accessible by
said creditor, said reports providing transaction information from
all payment channels.
124. A system according to claim 30, wherein creditor information
is automatically updated.
125. A system according to claim 93, said system comprising means
for automatically loading one or more user restrictions files.
126. A system according to claim 32, wherein said restrictions
files are related to rules selected from the group consisting of
coordination of service termination status accounts, minimum
payment requirements, payment method limitations, and payment
method privilege suspension.
127. A system according to claim 93, said system comprising means
for allowing account number rules to be applied at user entry, and
means for scrubbing said database prior to reporting to reduce
invalid or unknown transactions.
128. A system according to claim 93, said system comprising means
for providing real-time notification of payment.
129. A system according to claim 93, said system comprising means
for providing reports over the Internet of attempted and successful
payment initiations for customer use with restricted access based
on the internet protocol address and/or password access.
130. A system according to claim 93, said system comprising means
for providing an account level edit interface over the Internet of
attempted and successful payment initiations for customer use with
restricted access based on internet protocol address and/or
password access.
131. A system according to claim 93, said system comprising means
for integrating said reporting with conventional formats for daily
reporting with reconciliation support.
132. A system according to claim 93, said system comprising means
for sending payment remittance and reconciliation information to a
backend financial information system.
133. A system according to claim 93, said system comprising means
for managing non-sufficient funds check returns.
134. A system according to claim 40, wherein said managing further
comprises representment of returned check/ACH transactions.
135. A system according to claim 41, wherein said check/ACH
presentments are timed to target said user's automatic payroll
deposit schedule.
136. A system according to claim 93, said system comprising
recognizing duplicate transactions.
137. A system according to claim 93, said system comprising means
for automatically apply service fees to said users where said
service fees are authorized.
138. A system according to claim 93, said system comprising means
for verifying the availability of funds to cover payments by checks
and/or checking account debits.
139. A system according to claim 93, said system comprising means
for providing an advanced analytics framework to provide
instantaneous data associations of multi-variate data structures
within said database.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part application of
published application Ser. No. 09/267,840 filed Mar. 12, 1999.
TECHNICAL FIELD OF THE INVENTION
[0002] The present invention relates broadly to a system and method
whereby a person owing a debt, bill, obligation or promise is
invited to resolve this indebtedness, bill, obligation, promise, or
other transaction via multiple payment channels without enrollment
or subscription. More specifically, the user is invited (by
traditional media such as phone or mail) to visit a "transaction
community" wherein the bill, debt, or contribution may be resolved
through an interactive exchange of information. The user is enabled
to simply log in to all available payment channels without the
impediment of enrollment or subscription (call center, automated
phone (IVR), PayMyBill.com (or other "Transaction Community"),
wireless, etc.) to complete transactions with organizations which
utilize the system and method. The system enables billers and other
transacting organizations to leverage their existing paper bills
and collection communications to include key system access
information. The system and method increases consumer utilization
by making payment remittance easier and more fulfilling while
providing billing organizations rich customized features without
the customized development effort currently necessary. The system
simplifies setup for billers and other transacting organizations to
utilize its robust capabilities and does not require enrollment by
either the billing organization's users wishing to conveniently
transact or the billing organization's bank or other financial
institution.
BACKGROUND OF THE INVENTION
[0003] The present invention relates to a multiple channel or
interface financial/transaction service that, unlike current
systems, may be accessed by anyone wishing to transact without the
impediment of enrollment or subscription. This disclosed system
exceeds current standards for online banking (Open Financial
Exchange) and is set to meet or exceed anticipated revisions. In a
typical bill payment or debt resolution or other transaction
application of the disclosed system, the billing organization can
simply participate in all transaction channels or interfaces
without previously establishing an online banking system or other
specific banking relationship. Initially, the billing organization
invites the debtor to utilize applicant's multitude of payment
channels or interfaces as an option to traditional payment methods
such as mail. For example, the mailed copy of a bill or "past due"
notice invites the debtor to visit the call center, automated
phone(IVR), PayMYBill.com (or other "Transaction Community"),
wireless, etc. to complete transactions. The WorldWide Web, or
Internet, is actually a complex "web" of smaller regional networks.
It is comparable in many ways to our roadways. A network of
interstate superhighways connect large cities. These highways flow
into smaller freeways and parkways linking smaller towns to the big
cities. The parkways ultimately connect to slower, narrower
residential streets. See EFF's Extended Guide to the Internet,
incorporated herein by reference.
[0004] In the world of computers, the "superhighway" is the
high-speed Internet. Connected to the Internet are computers that
use a particular system of transferring data at high speeds. In the
United States, the major Internet "backbone" theoretically can move
data at rates of 45 million bits per second. By way of comparison,
the average home modem has a top speed of roughly 14,400 to 56,000
bits per second. This inter-Internetworking "protocol" allows a
network user to connect and link up with computers around the
world.
[0005] Smaller networks serving particular geographic regions are
connected to the backbone computers, which generally move data at
speeds around 1.5 million bits per second. These networks are
hooked to even smaller networks and individual computers. Unlike
commercial networks, a central computer does not run the Internet.
This is both its greatest strength and its greatest weakness. This
approach means it is virtually impossible for the entire Internet
to crash at once--even if one computer shuts down, the rest of the
network stays up. This design also reduces the costs associated
with an individual or organization accessing the Internet through a
network. However, thousands of connected computers can also make it
difficult to navigate the Internet and find what you
want--especially as different computers may have different commands
for "plumbing" or accessing their resources. Only recently have
Internet users begun to develop the navigational tools and "maps"
that allow neophytes and relatively inexperienced users get around
and navigate the Internet without getting lost.
[0006] The number of users, computers, and networks making up this
Internet is not known with any degree of certainty. Some estimates
place as many as 5,000 networks, connecting nearly 2 million
computers and more than 15 million people around the world as the
Internet. Whatever the actual numbers, they are increasing
rapidly.
[0007] The Internet is more than just a technological marvel. It is
a revolutionary means of communication. The rate at which
information and documents are exchanged is obviously quite a bit
faster than mail, as messages race around the globe in seconds,
provided you have the right connection. Network providers are
therefore continually working on ways to facilitate communication
between users of one network with those of another. At present,
work is underway on a universal "white pages" in which you could
look up somebody's electronic-mail address. This "connectivity"
will become even more important in coming years as users begin to
demand "seamless" network access, much as a telephone user can dial
almost anywhere in the world without thinking about the number of
phone companies actually involved with the call. As it becomes
easier to use, more and more people will undoubtedly join this
worldwide community known as the Internet.
[0008] While the present invention will have broad application to
the full range of online financial transactions, particular
applicability is seen in the area of credit and collection
practices. The credit and collection arenas are segmented into
distinct market niches. The first niche comprises, for instance,
collection organizations. The collection industry is further
defined by type of debts collected (consumer vs. commercial) and
then by the placement of various debts by and within the various
industries.
[0009] Credit transactions (e.g., loans, credit cards, etc.)
provide an additional immediate niche for the invention as
disclosed. The "transaction community" of the present invention
allows for customization to address the various transaction niches
required within the various credit and collection communities. In
other words, the invention may be adapted to handle almost any
credit or collection transaction.
[0010] The debt collection industry is consolidating. The May 1996
issue of Collection & Credit Risk Magazines Annual Report notes
that: "[a]lready the number of collection agencies has fallen by
some 20% in the past two decades." Additionally,
mergers-and-acquisitions specialist M. Kaulkin and Associates, of
Bethesda, Md., reports that industry insiders expect another 15% to
20% decrease and further consolidation: "[t]he signs of an ongoing
consolidation in the collections industry are unmistakable. In
fact, as measured by placements, the 10 largest agencies in the
country have increased their market share from about 15% in 1992 to
42.1% last year."
[0011] Over the years, debt collection has evolved as a function of
available technology and its utilization. There was a time when a
collection agent would personally visit the debtor for debt
resolution. Mail allowed the creditor and debtor to communicate
through a series of "dunning" letters to prompt debt resolution.
With the advent of the telephone, the creditor and debtor were able
to facilitate debt resolution. Of course, while far less costly
than personal visits, mail and phone collections are expensive
operations, lowering the profitability of the debt collection
process.
[0012] Computers have long been used in billing and debt
collections, initially with respect to the maintenance of billing
and debtor records through database consolidation and utilization.
More recently, advances include computer telephony and predictive
dialers, which have increased efficiency and lowered time, energy,
and cost expended in debt collection via the telephone. The present
invention is a leap forward in the use of technology in the
functional or transactional billing, transaction, and debt
collection services industry. In applicant's system, the billing
organization or creditor invites and encourages the transactor or
debtor to communicate and resolve bills, obligations, promises or
debts through multiple channels/interfaces including the
instantaneous and robust user interface, communication, artificial
agent, and artificial intelligence capabilities now available to
consumers on the personal computer over the Internet. It should be
noted that all previous technological advances in this field have
been used to increase creditor yield while reducing expenses. Times
have changed. Increased competition for consumer dollars has
changed the creditor/debtor relationship into a customer service
relationship. Creditors now compete to retain and attract customers
by offering customer service. The present invention accelerates
this trend by allowing all billing organizations from highly
functioning billing service providers, billers, charitable
organizations, campaigns, and credit or collection organizations to
offer competitive customer service while also increasing yield and
decreasing expenses by providing a method that gives customers the
ability to resolve bills, obligations, contributions, and debt
through multiple channels/interfaces including web-based interfaces
such as the PayMYBill.com "transaction community". Where
instantaneous and robust user interface, communication, artificial
agent, and artificial intelligence capabilities are now possible
through the use of a personal computer or other computing deice and
the Internet.
[0013] Not surprisingly, there are a number of prior references
that teach various methods of bill payment and management.
[0014] For example, U.S. Pat. No. 5,220,501, issued to Lawlor, et
al., discloses a system and method for the remote distribution of
financial services (e.g., home banking and bill-paying) which
includes providing a portable computer terminal to a user. The
terminal may include a multi-line display, keys "pointer to" lines
on the display, and additional function keys. The terminal
establishes contact between a central computer that is operated by
a service provider, preferably over an analog telephone line, and a
packeted data network software bundle. Information is exchanged
between the central computer and a terminal that solicits
particular information from the user relating to requested
financial services. For example, to pay a bill the payee approves
the amount and provides his bank account PIN (personal
identification number). The central computer would then transmit a
response message over a conventional electronic Automatic Teller
Machine ("ATM") network for debiting the user's bank account in
real time, and then electronically remitting payment to the
specified payees in the specified amounts. Additionally, payment(s)
and/or transfer(s) may be further scheduled in advance or on a
periodic basis. Because the central or main computer interacts with
the user's bank as a standard point of sale ("POS") or ATM network
node, no significant software changes are required at the bank's
computers. The terminal interface tries to be user-friendly in
incorporating some of the features of standard ATMs.
[0015] U.S. Pat. No. 5,383,113, issued to Kight, et al., discloses
a computerized payment system by which a consumer may instruct a
service provider via telephone, computer, or other
telecommunications means to pay various bills without the consumer
having to write individual checks for each bill. The system
essentially operates without restriction as to where the consumer
banks and what bills are to be paid. Essentially, the service
provider collects consumer information, financial institution
information and merchant information and arranges payment according
to the consumer's instructions.
[0016] U.S. Pat. No. 5,465,206, issued to Hilt, et al., discloses a
bill pay system wherein participating consumers may pay bills to
participating creditors through a payment network. The
participating consumers receive bills from participating creditors
(paper bills, e-mail, implied bills from automatic debts) which
indicate an amount and biller identification number. To authorize a
remittance, a consumer transmits to a participating bank a payment
notice that indicates a payment date, an amount, the debtor's
account, the source from which the funds are to be remitted and the
biller's identification number. A bank then submits a payment
"message" to the subscribed payment network and forwards the
payment message to the biller's bank. For settlement, the debtor's
bank debits the consumer's account and likewise, the creditor's
bank receives a Internet position from the payment network and
credits the creditor's bank account. If the debtors's bank agrees
to send a non-reversible payment message, then the debtor's bank
does not submit the transaction until funds are good unless the
consumer's bank is willing to take the risk of loss as would be in
the case in a guaranteed payment network. In specific embodiments,
the consumer initiates the bill pay orders manually, via paper at
an ATM, via PC, or via telephone keypad.
[0017] U.S. Pat. No. 5,483,445, issued to Pickering, discloses an
automated system and method for consolidating a plurality of
individual company charges for a customer with different periodic
company billing and payment due dates. Under the system, companies
and businesses such as utility companies would report periodic
billing information to a central processing facility. This transfer
is completed by electronic or magnetic data transfer. The
processing office undergoes minimal processing and "holds" the
billing information data until all of the billing information is
received. Then, the central facility generates a single customer
statement which identifies individual company charges and the
statement due date. The statement is then sent to the customer with
payment for the charges by the due date. After receiving payment
from the customer, the system processes the payment and remits
payment to the companies.
[0018] U.S. Pat. No. 5,504,677, issued to Pollin, discloses a
system and method of collecting payments using an automated system
to generate a draft, payable to the creditor and drawn on the
payor's checking account, pursuant to payor's authorization. The
draft is executed by the debt collector as authorized signatory for
the payor, and deposited into the payee's account. The automated
system has a simple input screen that receives the necessary
information for generation of the draft, which may be read to the
system operator over the telephone by the authorizing payor. The
system verifies the account information, comparing the input
information to records in a database associated with the system.
Optionally, the system may also generate an "inquiry" to the bank
to determine the funds availability. When verification is complete,
the system generates a paper draft payable to the payor, which may
use an MICR ink so that the draft can be processed in the banking
system like an ordinary check. The signature block would then be
made for the collection agent "as authorized signatory for" the
payor.
[0019] U.S. Pat. No. 5,621,640, issued to Burke, discloses an
automatic donation system for a sales establishment including an
entry arrangement for entering the price of a product into a cash
register, the amount of cash being paid and a calculator for
determining excess cash payment(s). A card reader keypad receives a
card(s) number for accessing data and then prints out the amounts
entered.
[0020] U.S. Pat. No. 5,623,662, issued to McIntosh, discloses a
method and system for extracting revenue information from a
point-of-sale (POS) terminal for purposes of revenue sharing that
includes the steps of periodically selecting and extracting
predetermined portions of data from a proprietary database. This
system allows for extrapolation of select data relating to revenue
traffic in a rental system. Revenue stored in a proprietary
database by a proprietary POS operating program is periodically
selected, extracted and stored in a periodic database. The
proprietary POS operating program can be used to create a history
report database from the revenue transaction data and the portions
of the revenue transaction data can be selected and extracted from
the history report database.
[0021] U.S. Pat. No. 5,644,727, issued to Atkins, discloses a
communication and computer based system for effecting exchange,
investment and borrowing, involving the use of digital
communication and computation terminals distributed to users and
service providers. Through the system described and its combined
computer and communication terminals, client/customers may purchase
goods and services, save, invest, track bonuses and rebates and
effect enhanced personal financial analysis, planning, management
and record keeping with less effort and increased convenience.
Through a prioritization function, the client specifies her
financial objectives, her risk preference, and budgetary
constraints. The prioritization function automatically suggests to
the individual a portfolio of asset and liability accounts that may
be credited and/or debited to provide the required funds for
consumption and to form investments and borrowing to best realize
the financial objectives. If desired, the system automatically
manages a client's budgetary and financial affairs through a system
of expert sweeps based on a client's preferences. The client's
accounts are monitored via a borrowing power baseline, and
considered imbalanced if the client's borrowing power is less than
the minimum borrowing power. If the account is imbalanced, the
client may then reallocate the assets and liabilities within the
client account and/or modify a set of constraints on the client
account. If the client account is still not balanced after
modification of the account, the system will deny authorization for
certain requested transactions, and may initiate the liquidation of
certain asset accounts and reduce the balances of one or more
liability accounts.
[0022] U.S. Pat. No. 5,649,117, issued to Landry, discloses a
system and method for paying bills without requiring interaction
with the payors. The system includes a payor control interface, a
communications interface, a bill generator, and a TCF message
generator. The bill generator generates bill records from the payor
and payee information and from bill data messages received from
payees. The generated records are used by the TCF message generator
to generate the EFT messages for transferring funds electronically
between payors and payees. Payors may alter the payment amount and
date for a bill as well as reverse payment of a bill already paid.
Payees are also able to alter recurring bill records or may present
bill data so that bill records reflecting variable obligation
amounts may be generated.
[0023] U.S. Pat. No. 5,652,786, issued to Rogers, discloses a
method and apparatus for processing payment transactions using
debit card numbers without the requirement of a personal
identification number (PIN). A telepay system of the present
invention provides an interface between a standard touch-tone
telephone and at least one debit card network such that real-time
bill payment transactions may be effected using a keypad of the
telephone. The telepay system includes an interactive voice
response unit for prompting a payor to enter an access code,
account number, debit card number and payment amount and for
informing the user of the status of the transaction. Real-time
processing of transactions is provided through use of debit card
networks, rather than the Automated Clearing House. The telepay
system is also capable of performing settlement functions and
processing inquiries by payees of the system regarding previously
processed transactions.
[0024] U.S. Pat. No. 5,655,008, issued to Futch, et al., discloses
a system and method whereby a multiplicity of users may perform a
variety of transactions, such as a product/service request, a bill
payment request and long distance telephone service, through a
system operator. The system includes a plurality of telephone
instruments respectively having a telephone identifier and a wallet
card swipe reader or the like for inputting a user identifier. A
plurality of user actuators, such as individual buttons, are
located on the telephone instrument to initiate a request for a
particular transaction. A system processor in communication with
the telephone instrument determines which type of transaction is
being requested and determines whether the request is valid.
Preferably, the validity check is completely performed at a
computer having a validity table in its memory corresponding to the
particular telephone instrument. The computer stores all
transaction requests accrued over a period of time in its memory
and forwards them to a central computer at a predetermined regular
time. The central computer then correlates the transaction request
with complete information in its database to carry out the
transaction as requested.
[0025] U.S. Pat. No. 5,655,089, issued to Bucci, discloses that
analysis has revealed that there is an undue proliferation of
first-class mail being sent each month in the nature of bills,
statements and similar such documents. Analysis has also revealed
that this produces an unnecessary expense for postage and
processing, besides the costs involved in purchasing the paper and
envelopes to begin with. The method of the invention avoids this
through the single mailing of one or more two-sided documents on
which is presented all the bills, statements, etc., intended for a
given recipient during a specified period of time, for all
subscribers to the service. In accordance with the described
embodiment of the invention, the method forms a computer database
of addressee information; merges with that database all such record
information provided by subscribers; prints out one or more sheets,
preferably on both sides, of all information intended for
designated recipients during the time period in question; and
allows for a single mailing of such sheets in a single
envelope.
[0026] U.S. Pat. No. 5,684,965, issued to Pickering, discloses an
automated method and system for consolidating a plurality of
individual company charges for a customer with different periodic
company billing and payment due dates. Under the system, companies
and businesses such as utility companies report their periodic
billing information to a central processing office or facility. The
processing office holds the billing information data until all of
the billing information for the customer during a pre-selected time
period is received. Then, the central processing facility generates
a single customer statement which identifies all individual company
charges as well as a statement due date. The statement is sent to
the customer and payment for the charges due. After receiving
payment from the customer, the centralized billing center processes
the payment and then remits payment to all of the companies.
[0027] U.S. Pat. No. 5,696,906, issued to Peters, et al., discloses
an integrated computerized system and method of telecommunication
user account management. The invention creates, maintains,
processes and analyzes data regarding individual users for
telecommunication services. Billing for individual users is
generated. The user data is analyzed and reports for all or part of
the user data are prepared and generated. Ancillary functions are
enabled, including word processing, editing, e-mail, and other
functions. The invention is applicable to subscriber
telecommunication services, and pay-for-use services, and the user
may be a subscriber or a non-subscriber. The invention is
applicable to multi- or single-channel telecommunication services.
Such telecommunication services may include cable television,
telephone, video, audio, on-line databases, television, radio,
music video, video juke box, pay-for-view, video-on-demand,
interactive TV, home-shopping, video conferences, telephone
conferences, interfacing to imaging systems, and automatic
telephone call charge-backs ("900" numbers). The current preferred
embodiment of the invention is for cable television services
subscriber account management.
[0028] U.S. Pat. No. 5,699,528, issued to Hogan, discloses a bill
delivery payment system in which users are able to access a server
computer on a communications network to obtain bill information and
pay bills. For example, such a communications network may be the
Internet. Using a personal computer, a user can access a Web site
provided by the server computer to view the bill information and
instruct the server computer as to the details of the bill payment.
In a second embodiment, without visiting the web site, users are
provided with electronic bills containing bill information in the
form of electronic mail (e-mail) at their e-mail addresses. After
opening an electronic bill, a user can make the bill payment by
replying to the electronic bill.
[0029] U.S. Pat. No. 5,710,887, issued to Chelliah, et al.,
discloses a system for facilitating commercial transactions,
between a plurality of customers and at least one supplier of items
over a computer driven network capable of providing communications
between the supplier and at least one customer site associated with
each customer. Each site includes an associated display and an
input device through which the customer can input information into
the system. At least one supplier is presented on the display for
selection by the customer using the input device. Similarly items
from a supplier can be displayed for the customer to observe. In
addition, a customer information database stores information
relating to the customer. Associated with each customer is a
customer monitoring object for each customer. The customer
monitoring object is created by referencing information, relating
to that customer, which had been stored in the customer information
database and when the customer selects a supplier. The customer
monitoring object is configured to operate by responding to
customer inquiries regarding a presented item by retrieving
information relating to the item and presenting the information to
the customer; receiving a customer's selection of a presented item;
receiving customer communications, indicating a desire to receive
the item; and passing a communication to initiate the delivery of
the item to the customer.
[0030] U.S. Pat. No. 5,715,298, issued to Rogers, discloses
processing payment transactions using debit card numbers without
the requirement of a personal identification number (PIN). A
telepay system provides an interface between a standard touch-tone
telephone and at least one debit card network such that real-time
bill payment transactions may be effected using a keypad of the
telephone. The telepay system includes an interactive voice
response unit for prompting a payor to enter an access code,
account number, debit card number and payment amount and for
informing the user of the status of the transaction. Real-time
processing of transactions is provided through use of debit card
networks, rather than the Automated Clearing House. The telepay
system is also capable of performing settlement functions and
processing inquiries by payees of the system regarding previously
processed transactions.
[0031] U.S. Pat. No. 5,715,399, issued to Bezos, discloses a system
for securely indicating to a customer one or more credit card
numbers that a merchant has on file for the customer when
communicating with the customer over a non-secure network. The
merchant sends a message to the customer that contains only a
portion of each of the credit card numbers that are on file with
the merchant. Then a computer retrieves the credit card numbers by
reference on file for the customer in a database, constructs the
message, and transmits the message to a customer location (10) over
the Internet network (30) or other non-secure network. The customer
can then confirm in a return message that a specific one of the
credit card numbers on file with the merchant should be used in
charging a transaction. Since only a portion of the credit card
number(s) are included in any message transmitted, a third party
cannot discover the customer's complete credit card number(s).
[0032] U.S. Pat. No. 5,724,512, issued to Dedrick, discloses a
method for providing electronic advertisements to end users in a
consumer best-fit pricing manner including an index database, a
user profile database, and a consumer scale matching process. The
index database provides storage space for the titles of electronic
advertisements. The user profile database provides storage for a
set of characteristics that correspond to individual end users of
the apparatus. The consumer scale matching process is coupled to
the content database and the user profile database and compares the
characteristics of the individual end users with a consumer scale
associated with the electronic advertisement. The apparatus then
charges a fee to the advertiser, based on the comparison by the
matching process. In one embodiment, a consumer scale is generated
for each of multiple electronic advertisements. These
advertisements are then transferred to multiple yellow page
servers, and the titles associated with the advertisements are
subsequently transferred to multiple metering servers. At the
metering servers, a determination is made as to where the
characteristics of the end users served by each of the metering
servers fall on the consumer scale. The higher the characteristics
of the end users served by a particular metering server fall, the
higher the fee charged to the advertiser.
[0033] U.S. Pat. No. 5,724,584, issued to Peters, et al., discloses
a system for processing a batch which is distributed into a
plurality of independent segments. A preferred embodiment of this
invention calls for implementation on a symmetrical multiprocessing
platform, however, the invention is also applicable to massively
parallel architectures as well as uniprocessor environments. Each
segment comprises a plurality of discrete events, each discrete
event comprising a plurality of sub-events to be processed. The
system operates to process each discrete event within each segment
sequentially and each sub-event within each discrete event
sequentially. The plurality of segments may be processed on an
uniprocessor, an SMP system or an MPP system. By balancing the
number of discrete events in each segment using a "coarse grain"
approach, a flexible but efficient use of processor availability is
obtained.
[0034] U.S. Pat. No. 5,727,249, issued to Pollin, discloses a
system and method of collecting payments comprising an automated
system to generate a draft, payable to the creditor and drawn on
the payor's checking account, pursuant to the payor's
authorization. The draft is then executed by the debt collector as
authorized signatory for the payor, and deposited into the payee's
account to complete payment. The automated system has a simple
input screen that receives the necessary information for generation
of the draft, which may be read to the system operator over the
telephone by the authorizing payor. The system verifies the bank
and account information by comparing the input information to
records in a database associated with the system. Optionally, the
system may also generate an inquiry to the bank to determine the
availability of funds in the payor's account. When verification is
complete, the system generates a paper bank draft payable to the
payor, using MICR ink so that the draft can be processed in the
banking system like an ordinary check. The signature block of the
draft is made for the collection agent "as authorized signatory
for" the payor.
[0035] U.S. Pat. No. 5,729,594, issued to Klingman, discloses a
remote communication system for facilitating secure electronic
purchases of goods on-line, wherein a suitable local user input
device in association with a data transmission system couples the
user input into a packet network system for communication to a
remote receiver/decoder apparatus to try a potentially desired
product. Upon selection of the desired product by the user, a
telecom network link is used to communicate a telephone number
associated with the desired product from the user to the remote
receiver to allow the user to buy the desired product. The telecom
network used to link the user input device to the remote apparatus
may also include a 900 number billing system for assessing and
collecting fees for use of the system.
[0036] U.S. Pat. No. 5,734,828, issued to Pendse, et al., discloses
an on-line/information service system which is constituted with a
caller management server and a number of on-line/information
servers. The caller management server is equipped with multiple
ports and complementary hardware/software, including a call
management application, for managing multiple concurrent calls,
which includes optionally validating the calls depending on whether
services are provided on a callee or caller basis, assigning and
connecting the calls to corresponding on-line/information service
delivery environments on the on-line/information servers. The
on-line/information servers are equipped with adequate
hardware/software, including an on-line/information service manager
application and a number of on-line/information service
applications, to support multiple on-line/information service
delivery environments. Each on-line/information service delivery
environment is equipped with streamlined application sharing host
services, thereby allowing an end-user PC equipped with streamlined
application sharing client services to access on-line/information
services provided by the on-line/information service
applications.
[0037] U.S. Pat No.: 5,737,414, issued to Walker, et al., discloses
a billing and collection system for enabling payment for a service
provided over a data network by billing a customer for a telephone
connection to a shared revenue billing network where the telephone
connection to the billing network regulates access to the service
provided over the data network, comprising: a data network
including at least one user on-line service provider presenting at
least one service for on-line access by a user with a user computer
through the data network, a billing network and an access
management computer for controlling access to the on-line service
provider and billing the user for access to the on-line service
provider, the access management computer communicating with the
data network for enabling and terminating access to the on-line
service provider through the user computer whereby the billing
Network shares revenues for the telephone connection with the
on-line service provider.
[0038] U.S. Pat. No. 5,739,512, issued to Tognazinni, discloses
that digital delivery of receipts overcomes many of the problems
associated with paper receipts. Digital receipts can be delivered
over a proprietary or over an open Network such as the Internet.
They can be uploaded to a smart card. They can be standardized in
format to facilitate automated processing. An e-mail address can
also be incorporated into a bank card or other machine readable and
for automatic routing of the receipt to a payor's e-mailbox.
[0039] It is clear that these prior references do not teach or
suggest the present invention, which invites the consumer to visit
an interactive "transaction community" that provides the consumer
with an interesting, creative alternative to traditional methods of
debt presentment and resolution.
SUMMARY OF THE INVENTION
[0040] The present debt presentment and resolution sysytem utilizes
an Internet system featuring the distributed network of
administrative and consumer users on, for example, Microsoft
Windows 32-bit operating systems connecting legacy systems and
providing secure access to a robust SQL database structure
delivering innovative benefits and advantages in customer service
and payment options for consumers. Billing service companies whose
services extend via the mail and electronic bill presentment and
payment do not offer a connected system that integrates the paper
billing system with the online enhanced customer service and
payment options.
[0041] The disclosed system is an Internet Content Provider serving
a "transaction community" of creditors and debtors. Said invention
brings these two groups together to engage in alternative debt
resolution via enhanced, interactive communication. The principle
underlying the "transaction community" model is mutuality. A
community is created when it is mutually beneficial for individuals
to come together in a common understanding. The "transaction
community" has enormous potential for mutuality because it has
beneficial offerings for both the creditor and the debtor
communities. The creditor community benefits by providing enhanced
customer service and gaining increased profits. The debtor
community benefits by gaining enhanced customer service and access
to an array of services related to improving their financial
condition.
[0042] The "transaction community" model provides transaction focal
points or kiosks for credit and collection agencies to drive
customers to complete transactions. The base technology of a
"transaction community" is a sophisticated Internet/intranet based
software application that allows users to access and input
information related to a particular debt with any popular browser.
The user is invited to resolve debt through direct mail
correspondence from the collection agency. This letter includes the
"transaction community" Internet address (URL) as well as a unique
ID that allows users to view their debt and enter a valid
settlement. The credit or collection agency can consult with its
clients to decide which "transaction community" would be
appropriate to direct the client's customers toward. For example, a
collection agency's utility client would want to have their
customers directed to a "transaction community" for utility
payment.
[0043] Customers may select from a variety of settlement options
listed on the HTML (HyperText Markup Language) page. The database
records for the "transaction community" are synchronized with those
of the corresponding debt collection agency and exchanged at
regular intervals.
[0044] Initiation of debtor interaction with said "transaction
community" requires several steps. First, a creditor invites debtor
to "join" through mail and/or telephone to communicate using a new
customer service option, "transaction community". Next, the
customer enters the appropriate URL (Universal Resource Locator)
into their Internet browser and begins interfacing with the
"transaction community". The customer is welcomed and the purpose
or goal of the "transaction community" is explained. Clearly
explained to said customer is that: technology has improved and the
customer should benefit from advances in technology, the Internet
has improved the way a provider and a customer may communicate and
interact regarding transactions, the "transaction community" helps
customers solve their debts by opening the lines of communication
in an efficient, confidential, private, controlled, and comfortable
environment, and the "transaction community" is a customer friendly
service interface presented on a computer via the Internet designed
to mediate between creditor and debtor and collect delinquent
receivables and debts. The "transaction community" then asks the
debtor to provide a secure pass code (as provided by the creditor
in the invitation) to bring up account information. The
"transaction community" then states the current status of the
account and gives the customer or debtor options for further
negotiation. The first option could be an agreement to pay the
outstanding debt. At this point, options for payment may be
displayed. Payment options include secure credit card payment or
secure acceptance of checks through integration of an automated
customer check printing system into the Internet transaction system
as a few of the possible payment means. Other possible responses,
aside from agreeing to pay said debt could include, but are not
limited to, discernable choices for the debtor and/or a free form
slate for communication via forms or e-mail. Said customer may
choose a reason or type a reason why said debt is not paid and the
appropriate form is sent to the collection center. In addition, the
creditor can choose automated decision making via an artificial
intelligence means (debtor response is matched with creditor
tolerances) located within said "transaction community" server or
may choose human decision via an online e-mail collection
center.
[0045] In addition to the debt resolution or transaction
management, the "transaction community" could incorporate
interactive content that may be of interest to the demographics and
characteristics of the particular market segment. This content
could include information, links to other financial and employment
related sites, and other interactive services.
[0046] The system architecture is divided into two sides, client
side and server side. On the client side, said debtor will be able
to login to the "transaction community" web page by entering said
unique identification code, typically a password generated by the
system, and typically supplied to the debtor along with his/her
bill or "past due" notice. Debtors/users/customers will be able to
use leading web browser software to access the "transaction
community" web page.
[0047] The application essentially consists of several HTML forms,
containing a minimal set of ActiveX controls, to increase speed of
operation and eliminate the necessity of downloading appropriate
ActiveX controls from said web page.
[0048] The first screen may have two data entry fields, Customer
ID, i.e., said unique identification code, and said secondary key.
After proper authentication, which will take the user to another
HTML page, an account presentation form may appear. The data
displayed on this account form will be read from the remote
database residing on the "transaction community's" server. These
components should constitute the "back office" components.
[0049] The second form may contain, but is not limited to, the
following data about the account: debtor identification code,
secondary access key, debtor name, debtor address, debtor phone
number(s), debtor fax number(s), debtor's e-mail address(s), DUNS
number, initial creditor's name, amount of the loan, principal
amount of loan, interest to date, other costs accrued, debt status,
aging of the debt, and collection agent's name. If data for one of
the fields is not available, a "blank" field may be displayed.
Alternatively, an administrative or help page may also appear.
[0050] To further process the transaction, a button on said page,
possibly labeled "Settlement Options", will then take users to
another HTML page that may have five or more options; pay the debt
off now with a credit card, dispute the debt, make a payment via
phone, make a payment via check, or make a payment promise. The
first option will allow debtors to pay off the debt with a credit
card, in which case a standard credit card payment screen with data
fields will appear. The second option will load an HTML page that
will allow debtors to enter a dispute claim and e-mail it to the
creditor or collection agent. It will also provide an option to
request a verification of the debt. When a dispute message is
received, some auto-decision making tools may be used, or the
decision may be made manually and sent to the customer. The third
option will provide users with telephone access to an authorized
representative to arrange payment. With this option the customer
will need to provide a representative with information about
his/her checking account and/or bank requisites. The fourth option
will allow users to arrange payment via a check or via a debit
system on the account thereof. The fifth option will allow debtors
to make a promise to send a payment via check or money order by a
certain date, for a certain amount to an address that could be
verified on the HTML form. An account number verification will also
be requested from the customer. Additional HTML forms may be
created or provided to support additional desired options. The
disclosed system is payment processor neutral, i.e., as payment
systems evolve, they may be incorporated into the present
system.
[0051] On the server side, the system contains appropriate database
software and appropriate system support software. Authenticated
customers will be able to access the database records and
administer the accounts to various utilities such as an Internet
Transaction Control Center via either RAS (remote access service)
or HTTP through their web browsers.
[0052] Database records contain all the necessary fields to
describe each account contained in the database, such as the status
codes, description fields, history field, status types, action
codes, and transaction result codes.
[0053] It is anticipated that the present invention may be utilized
in a broad range of applications other than debt collection--in
short, as an Internet Transaction Control Center. It incorporates a
Web Debt Settlement System, providing a method for coordinating
with various types of collection systems. It is intended that the
invention also allows for payment by check via the Internet, as
well as a method for making philanthropic contributions. Such a
feature would be made available by the creditor or biller as a
promotion or at the consumer's choice, by which the consumer could
choose from a list of charitable organizations.
[0054] The system is also equipped with a fundraising system
providing direct mail to invite campaign contributions. The system
keeps accurate records of the donors and their contributions, and
it gives donors the option to pay immediately (via check, credit
card or smart card), or to pay in accordance with payment plans
approved by the organization. This fundraising attribute of the
system is designed to ensure privacy while also providing the
permanent contribution records required by campaign laws.
[0055] The system may also include a revenue sharing system. Upon
using a particular system feature, the system would distribute
revenue to the appropriate vendor of that feature. For example,
when the consumer logs on to a Website, the system would distribute
revenue to the direct mail provider/system provider. When a
consumer chooses to pay via credit card, revenue would be dispensed
to the credit card processor. If the Call Center Button is hit,
revenue would go to the call center button/center provider. Upon
consolidation, the system will allocate revenue to the appropriate
vendor. The system may also provide Help and Advertising for
Dynamic Debt Resolution, as well as a Collection/Customer Service
Call Center Button on the Web Page.
[0056] In preferred embodiments, the invention features a dynamic
changing of graphical user interface to adapt to international
language variances. The system utility will include interactive
digital agents to guide the bill payer or the debtor through
payment or customer service. The system will also incorporate
digital advertising based on what is already known about the
consumer.
[0057] Another component of the invention is an Education and
Entertaining Bill Payment experience for American consumers. This
will include educational information, debt counseling and debt
consolidation, as well as games and promotions.
[0058] Thus, it is the object of this invention to provide a system
and method for debt presentment and resolution through an Intranet
or Internet content provider.
[0059] Further, it is also the object of this invention to provide
a system and method comprising a plurality of "transaction
communities" which are electronic forums for interaction between a
plurality of parties through means of electronic mail (e-mail) or
other such electronic communication means.
[0060] Furthermore, it is also an object of this invention to have
an embodiment employing artificial intelligence means, whereby
verbose instantaneous communication is made possible by the
comparison of responses to tolerances.
[0061] In addition, it is also an object of this invention to
provide a system and method further comprising an Internet/Intranet
base software application that allows said debtors to access and
input information related to a particular debt with any leading
Internet browser software.
[0062] Further, it is an object of this invention to provide a
web-based financial service accessible to any person with a PC and
Internet connection.
[0063] Additionally, it is an object of this invention to provide a
web-based financial service whereby database records at said
"transaction community" are synchronized with those of the
corresponding debt collection agency and exchanged at regular
intervals.
[0064] Further, it is also an object of this invention to provide a
web-based financial service ready to adapt to the new standards for
online banking as they evolve.
[0065] Furthermore, it is an object of this invention to provide a
web-based financial service that utilizes modern technology to
facilitate debt collection.
[0066] Further, it is also an object of this invention to provide a
web-based financial service that allows creditors to provide
greater customer service to their customers.
[0067] Further, it is an object of this invention to provide a
web-based financial service that allows creditors to increase
profits.
[0068] In addition, it is also an object of this invention to
provide a web-based financial service that provides debtors with
information and access to an array of services geared towards
improving their financial condition.
[0069] Further, it is an additional object of this invention to
provide enhanced means in which a debtor and creditor may interact
regarding transactions and debts.
[0070] Furthermore, it is an object of this invention to provide
"transaction communities" which help debtors solve their debts by
opening the lines of communication in an efficient, confidential,
private, controlled, and comfortable environment.
[0071] Additionally, it is an object of this invention to provide a
web-based financial service whose payment options for resolving
debt include, but are not limited to, secure credit card payment or
secure acceptance of checks through the integration of an automated
customer check printing means into the Internet transaction
system.
[0072] Furthermore, it is an object of this invention to provide a
web-based financial service whose options aside from paying the
debt include, but are not limited to, disputing the debt or making
a payment promise, and means to accomplish same.
[0073] Further, it is an object of this invention to provide a
web-based financial service whose server has appropriate database
software and appropriate system support software.
[0074] Additionally, it is an object of this invention to provide a
web-base financial service whereby authenticated customers will be
able to access the server database records and administer the
accounts to various utilities such as an Internet Transaction
Control Center via either RAS or HTTP.
[0075] In addition, it is an object of this invention to provide a
web-based financial service which requires a system generated
unique identification code in order to gain access to account
information.
[0076] Furthermore, it is an object of this invention to provide a
service that enables a user to simply log in to all available
payment channels without the impediment of enrollment or
subscription to complete transactions with billing organizations
which utilize the system.
[0077] Further, it is an object of this invention to provide a
simple setup for billing organizations and other transacting
entities without requiring enrollment by either the billing
organization's users, banks or other institutions.
[0078] Other objects, features, and characteristics of the present
invention, as well as the methods of operation and functions of the
related elements of the structure, and the combination of parts and
economies of manufacture, will become more apparent upon
consideration of the following detailed description with reference
to the accompanying drawings, all of which form a part of this
specification.
BRIEF DESCRIPTION OF THE DRAWINGS
[0079] A further understanding of the present invention can be
obtained by reference to a preferred embodiment set forth in the
illustrations of the accompanying drawings. Although the
illustrated embodiment is merely exemplary of systems for carrying
out the present invention, both the organization and method of
operation of the invention, in general, together with further
objectives and advantages thereof, may be more easily understood by
reference to the drawings and the following description. The
drawings are not intended to limit the scope of this invention,
which is set forth with particularity in the claims as appended or
as subsequently amended, but merely to clarify and exemplify the
invention.
[0080] For a more complete understanding of the present invention,
reference is now made to the following drawings in which:
[0081] FIG. 1 is a block diagram illustrating conventional
"transaction community" process methodology.
[0082] FIGS. 2A-E are flow charts depicting an embodiment of the
debt presentment and resolution process according to the present
invention.
[0083] FIG. 3 depicts a logon instruction sheet used in accordance
with the present invention.
[0084] FIG. 4 depicts the Login Screen that a user may encounter
upon connection to the debt resolution website.
[0085] FIG. 5 depicts the Main Menu Screen that a user may
encounter upon successfully logging into the program.
[0086] FIG. 6 depicts the screen a user may encounter when
accessing account information.
[0087] FIG. 7 depicts the screen a user may encounter to create a
new account.
[0088] FIG. 8 depicts the View Debtors screen, which lists debtor
profiles.
[0089] FIG. 9 depicts the New Debtor Profile screen, which allows a
user to create a new debtor profile.
[0090] FIG. 10 depicts the View Creditors screen, which lists
information regarding creditors.
[0091] FIG. 11 depicts the New Creditor Profile screen, which
allows a user to create a new creditor profile.
[0092] FIG. 12 depicts the Collectors screen, which includes a
listing of collector profiles.
[0093] FIG. 13 depicts the New Collector Profile screen, which
allows a user create a profile for a new collector.
[0094] FIG. 14 depicts the Pending Transactions screen, which lists
any impending transactions.
[0095] FIG. 15 depicts a more detailed version of the Pending
Transactions screen shown in FIG. 14.
[0096] FIG. 16 depicts the Systems Settings screen, which
illustrates system default settings as input by a particular
collector.
[0097] FIG. 17 depicts the Upload Data screen, which permits a
collector to select a file and its format, as well as to process
such file.
[0098] FIG. 18 depicts the Download Results screen, which allows a
user to keep track of any information that is downloaded.
[0099] FIG. 19 depicts a Main Menu screen from an embodiment of the
present invention, which provides a user with access to general
information about the system, including, for example, descriptions
of the operator utilities.
[0100] FIG. 20 depicts the Administration Help screen, which gives
a user the opportunity to access the system's Help feature.
[0101] FIG. 21 depicts the Send Mail screen, which allows a user to
send Email.
[0102] FIG. 22 illustrates a typical notice received by a debtor
from a collection agency regarding an overdue payment.
[0103] FIG. 23 depicts the screen a consumer/debtor may first
encounter upon entering the system.
[0104] FIG. 24 provides information for a user regarding compliance
with the Fair Debt Collection Practice Act.
[0105] FIG. 25 depicts the "About SolveMyDebt.com" screen,
providing a user with basic information about the system, as well
as access to more detailed information about the system,
transaction communities, information regarding compliance with the
Fair Debt Collection Practice Act, security, a user's account,
help, send mail, job opportunities, etc.
[0106] FIG. 26 depicts the Security and Privacy screen, which
provides a user with detailed information regarding the system's
security features.
[0107] FIG. 27 depicts the Access Your Account screen, which
provides a user with the means to enter their accounts.
[0108] FIG. 28 depicts the Account Information screen, which
provides a user with general account information.
[0109] FIG. 29 depicts the Account Details screen, which provides
more detailed information regarding the user's account.
[0110] FIG. 30 illustrates the screen a user encounters when paying
a debt by credit card.
[0111] FIG. 31 illustrates the screen a user encounters when paying
a debt by check or money order.
[0112] FIG. 32 illustrates the screen a user encounters when
disputing a debt.
[0113] FIG. 33 illustrates the screen a user encounters when
selecting "Other 376" as a reason for disputing the debt (see FIG.
32), and affords a user the opportunity to communicate the reasons
a debt has not been paid.
[0114] FIG. 34 is a block diagram illustrating an overview of the
preferred embodiment of the debt presentment and resolution system
according to the invention.
[0115] FIGS. 35A-D are flow charts illustrating the preferred
embodiment of the debt presentment and resolution process according
to the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0116] As required, a detailed illustrative embodiment of the
present invention is disclosed herein. However, physical
communication systems, data formats and operating structures in
accordance with the present invention may be embodied in a wide
variety of forms and modes, some of which may be quite different
from those in the disclosed embodiments. Consequently, the specific
structural and functional details disclosed herein are merely
representative, yet in that regard, they are deemed to afford the
best embodiment for purposes of disclosure and to provide a basis
for the claims herein which define the scope of the present
invention. The following presents a detailed description of a
preferred embodiment (as well as some alternative embodiments) of
the present invention.
[0117] The "transaction community" system embodiment is implemented
as two Active Server applications. One of them is designed to
provide potential debtors access to their accounts, while another,
which allows maintenance of the data and settings, including system
policies, is designed to be used by collectors, system
administrators and operators, and probably third party users. Both
applications share a common database, for instance, Microsoft SQL
server 6.5. These systems also use client-side scripting (mostly
JavaScript), Java applets and ISAPI extensions in addition to
server-side (ASP) scripting. Usage of ActiveX components on client
side is reduced to minimum (there is only Microsoft Internet
Transfer control that is used on client side to facilitate file
uploads) due to potential compatibility problems. This further
exemplifies the reason why JavaScript was used instead of VBScript
(Visual Basic Script) on the client side. The vast majority of
Internet browsers support Java applets and JavaScript on all
platforms, while ActiveX and Visual Basic Script is supported
mainly by Microsoft Internet Explorer and primarily on Intel-based
environments.
[0118] The server side environment includes Microsoft NT 4.0,
Microsoft IIS 3.0 with ASP (as well as Front Page extensions for
development purposes), SQL 6.5 along with TSQL debugger extensions
for debugging purposes.
[0119] The client application can run on any Java-enabled browser
supporting JavaScript. Netscape Navigator 3.0 or higher or
Microsoft Internet Explorer 3.02 or higher is recommended.
Microsoft Internet Explorer should be enabled to open pages
containing ActiveX to upload files on server (from administrator's
application).
[0120] The database scheme is relatively simple: it uses a
"customer" table to represent debtors, a "creditor" table to store
creditor profiles, a "collector" table to keep collectors' data and
an "account" table to represent a debt instance. Another important
table is "operation", which keeps all the account transactions.
[0121] Referring first to FIG. 1, illustrated is the overall
networking scheme between the agency database 100, web server 103,
database sever 104, and user 107. Said web server 103 and database
server 104 are networked together via a secure local area Network
(LAN) 109, innaccessable by outside users. Said agency database
100, web server 103, and user 107 are Networked together through
the Internet 105, described above. Said agency database 100, web
server 103, and user 107 connect individually to the Internet via
appropriate bidirectional communication means (e.g., a modem) 101,
102, 106, respectively. Alternatively, said web server 103 and said
agency database 100 may also be directly connected 108 via either a
private LAN or wide area network (WAN) to effectuate faster
communication.
[0122] FIGS. 2A and 2B illustrates initial creditor interaction
with the debt presentment system. Prior to the use of the system,
said invention is marketed to collection agencies and credit
providers through known methods 200A or integrated into currently
available collection management systems. Said collection agency or
credit provider would then decide 200B whether to utilize 202 the
system or not 201. Should said collection agency or credit provider
decide to use the system, a special access code is given to log on
to the system 203 (see FIG. 3). After receiving said access code
203, said collection agency or credit provider may then log on to
the system 204 (see FIG. 4). This brings the user to the Main
System Administration Screen 205 (see FIG. 5). Here, the user is
given several options. User may access Accounts Screen 206 (see
FIG. 6), Create New Accounts Screen 207 (see FIG. 7), View Debtors
Screen 208 (see FIG. 8), Create New Debtor Screen 209 (see FIG. 9),
View Creditors Screen 210 (see FIG. 10), Create New Creditor Screen
211 (see FIG. 11), View Collectors Screen 212 (see FIG. 12), Create
New Collectors Screen 213 (see FIG. 13), Pending Transactions
Screen 214 (see FIG. 14), Pending Transactions Detail Screen 215
(see FIG. 15), System Settings Screen 216 (see FIG. 16), Upload
Data Screen 217 (see FIG. 17), Download Results Screen 218 (see
FIG. 19), About Screen 220 (see FIG. 20), Help Screen 221 (see FIG.
21), or Send Mail Screen 222 (see FIG. 22). After utilizing said
screens (206-218 and 220-222) appropriately, said user may then
send bills with an invitation 223 to use said system.
[0123] FIG. 2C illustrates the process wherein a debtor decides
whether or not to pay an outstanding debt. After a debtor receives
an invitation from said creditor indicating the availability of
said system, debtor then decides 224 whether to use 226 (see FIG.
24) said system or not 225. Said debtor must then log on to the
Internet and enter the appropriate URL (Universal Resource Locator)
into their browser to access said system. When said debtor arrives
at said system, said debtor is presented with several screens and
options. Said screens and options could include targeted
advertisements 227, options to view said system in another language
228, an information screen containing the Fair Debt Collection Act
229 (see FIG. 25), general information regarding said debt
presentment system 230 (see FIG. 26), general information regarding
transaction security and privacy information 231 (see FIG. 27), a
login screen for access to account information 232 (see FIG. 28), a
help screen 233, an option to send electronic mail to the
adminsitrator of said system 234, and general information regarding
job opportunities or other information pertinent to the
demographics of said debtors 235. After viewing said screens and
options (227-235), said debtor may then decide 236 whether to logon
into said system when presented with option 237. If debtor decides
not to login to said system, said debtor leaves 238 said system. If
said debtor decides to login, an appropriate login passcode must be
entered 239 to begin customer service. After login, said debtor is
presented with the account information screen 240 (see FIG. 29).
Upon reviewing the presented debt(s), said debtor decides 241
whether or not to pay said debt(s). User may decide not to pay said
debt(s) 242, or may decide to pay said debt 252 and work out an
appropriate payment schedule 253.
[0124] FIG. 2D illustrates the process for paying or disputing a
debt. With respect to the aforementioned step 242 (see FIG. 2C),
after deciding not to pay said debt, said debtor is given the
option to dispute the debt 243. If said debtor decides not to
dispute said debt, said debtor leaves said system 244. If said
debtor decides to dispute said debt 245, the Dispute the Debt
screen is displayed 246 (see FIG. 33). Here, said debtor may choose
how to dispute said debt 247. Said debtor may choose a discrete
debt dispute reason from a given list 248 (see FIG. 33), or said
debtor may choose an option to input their own reason for disputing
the debt 249. In either case, the creditor then processes the
debtor's dispute 250 and sends an appropriate response to said
debtor 251. With respect to aforementioned step 252 (see FIG. 2C),
if customer decides to pay said debt and creates a payment schedule
253 (see FIG. 2C), said payment schedule will be compared to
parameters preset by said creditor through artificial intelligence
254 or by using live collectors monitoring account status. If said
credit accepts said debtors payment schedule 255, said debtor will
then choose a payment type 262. If said creditor rejects said
payment plan 257, said debtor is instructed to make another offer
within said creditor's parameters 258. The artifical intelligence
process of comparing debtor's payment schedule to that required by
said creditor is illustrated in an additional iteration comprising
steps 259 through 260. It should be noted,however, that this is
merely illustrative. As many iterations as necessary for said
creditor to accept said debtor's payment schedule may occur. After
an acceptable payment schedule is found, said debtor then chooses a
payment type 262.
[0125] FIG. 2E illustrates the process of said debtor choosing a
payment method. Referring to aforementioned step 262 (see FIG. 2D),
when said debtor chooses a payment type, payment processing typs
are presented 263. Payment options may include: payment by check
via Internet 264, payment by credit card screen 265 (see FIG. 31),
payment by payment promise 266 (see FIG. 32), or other type of
payment processing 267. After choosing a payment processing option,
said debtor enters payment processing information 268. Said debtor
may then choose what type of receipt they would prefer 269. Receipt
options include: no additional receipt 270, receipt via regular
mail 271, receipt via electronic mail 272, or receipt via
electronic mail and regular mail 273. After submitting all relevant
payment processing information 274, payment processing occurs as
per the debtor's selected method 275. Said payment processing may
proceed in realtime whereby receipt processing is performed on-line
276, payment processing may occur at a later date 277, e.g., batch
processing, or the payment processing may be unsucessful 278. After
said payment processing, said debtor receives receipt in form
specified in aformentioned step 269 279.
[0126] FIG. 3 depicts a log-on instruction sheet for a debt
collection application utilizing the present invention.
[0127] FIG. 4 depicts the Login Screen that a user will encounter
upon connection to the debt resolution website. As is typical with
such applications, the user is presented with various options. For
example, by clicking on "About VRG 101," the user can find
information about the debt collection company. Other related
services may be accessed by clicking "Services 102." "Help 103"
provides instructions on using the program. In the event the user
would prefer information via standard mail, he or she may click
"Send Mail 104."
[0128] Access to the program is limited to users who have been
previously provided (by mail or otherwise) with a "User ID 105" and
"Password 106" and once these have been typed, the user will click
"Login 107" to enter the program. To stop transmitting the said
information or to re-enter different information, click "Reset
108."The "Restricted Access Warning 109" on the bottom of the
screen is to caution unauthorized users from entering and viewing
the program. Once the user's ID and password have been transmitted,
the user is logged in.
[0129] FIG. 5 depicts the Main Menu Screen that a user will
encounter upon successfully logging into the program. The Main Menu
Screen has the following hyperlinks to other areas of the database
and are self explanatory: "Access Accounts Data 111;" "Create New
Accounts 112;" "View Debtors 113;" "Create New Debtor 114;" "View
Creditors 115;" "Create New Creditor 116;" "View Collectors 117;"
"Create New Collector 118;" "Pending Transactions 119;" "System
Settings 120;" "Upload Data 121;" "Download Results 122;" "About
Solve My Debt 123;" "Help 124;" "Send Mail 125" and "Description of
Operator Utilities 126."
[0130] If the user chooses to access his or her account, then he or
she will be brought to FIG. 6, which depicts the screen the user
will encounter when accessing account information. The information
displayed consists of standard account information, including
"Account Number 128," the "Name of the Debtor 129," a "Description
of the Debt 130," an illustration of the "Total Due 131,"
"Identification of the Creditor 132," indication of the "Date the
Debt was Created 133," and a "Description of the Collector 134."
The "Branding 135" is illustrated as well. The remainder of FIG. 6
consists of methods for navigating the account information page,
allowing one to move "back one entire page 136," "back by a single
entry (137)," "forward by a single entry 138," "forward an entire
page 139," and to "Requery 140." The user can also "return to the
main menu 141," as well as link to the system's "Help Feature 142"
and "Send Mail 143."
[0131] Alternatively, a user may choose to develop a new account.
The screen illustrated in FIG. 7 permits a user to do so. To create
a new account, the user will input the "Customer Name 144," the
"Identity of the Creditor 145," as well as an "Illustration of the
Creditor 146." The screen also allows for the user to indicate a
"Description of the Debt 147," the "Type of Account Created 148"
and whether the account has been "modified 149," whether an
"invoice was sent 150," "when payment is received 151," the "Amount
of the Principal Debt 152," "Other Costs a Consumer Might Owe 153,"
an indication of the "Interest Accrued to Date 154," the "Amount of
the Last Payment 155," the "Status of the Debt 156" as well as any
"Comments 157." The screen also allows the user to put in the
"Monthly Payments 158," the "Maximum Number of Months in which to
pay 159," the "Interest Rate 160," the "User Login Identification
161," and the "Password 162." Finally, this screen will process the
aforementioned information upon clicking "Create 163." The user can
clear the information in the fields by clicking "Reset 164" or the
return to the previous "Main Menu 165."
[0132] A user who seeks a description of a debtor can obtain one.
FIG. 8 depicts the View Debtors screen, which lists debtor
profiles. This screen tabulates information in the system by "Name
166;" "Address 167;" "Phone 168;" "E-mail account 169;" "Date of
Birth 170;" and "Description 171." The user can page backward or
forward by clicking the "Back 172" and "Forward 175" buttons,
respectively. Likewise, the user can move backward or forward by a
single debtor in the listing by hitting buttons 173 and 174,
respectively. One can ask questions of a particular debtor by
clicking the "Requery button 176." The user can return to the main
menu "Return to Main Menu 177," ask for help "System Help 178," or
send mail "Send Mail 179."
[0133] Rather than viewing the profile of an already existing
debtor, a user may create a description of a new debtor. FIG. 9
depicts the New Debtor Profile Screen. This screen allows the user
to input the personal profile of each debtor. Such information
would include the "Name 180," "Address (181-185)," "Phone 186," and
"other personal data 187-194." The user can input additional
"Comments 195" and input the above information into the system
database for later retrieval and usage by clicking "Submit 196."
The user can also clear the information in the fields by clicking
"Reset 197" or return to the "Main Menu 198."
[0134] Similarly, a user may seek to review a description of an
already existing creditor or may desire to create a new one. This
is achievable via the screens depicted in FIG. 10 and FIG. 11. FIG.
10 depicts the Creditors Screen. This screen tabulates creditor
information in the system by "Creditor ID 199;" "Name 200;"
"Contact Name 201;" "Address 202;" "Phone 203;" "Fax 204;" and
"E-mail account 205." The user can page backwards or forwards by
clicking the "Back 206" and "Forward 209" buttons, respectively.
Likewise, the user can go backward or forward by a single debtor in
the list by hitting buttons 207 and 208, respectively. One can ask
questions of a particular debtor by clicking the "Requery button
210." The user can return to the main menu "Return to Main Menu
211," ask for help "System Help 212," or send mail "Send Mail
213."
[0135] FIG. 11 depicts the New Creditor Profile Screen. This screen
allows the user to input the personal profile of each creditor.
Such information would include the "Organization 214," the "Name
215," "Address (216-220)," "Phone 221," and other "data (222-224)."
The user can input additional "comments 225" and input the above
information into the system database by clicking "Submit 226." The
user can delete information by clicking "Reset 227" or the user can
return to the "Main Menu 228."
[0136] A user can obtain a list of collector profiles, as well.
FIG. 12 depicts the Collectors Screen. This screen allows the user
to list collectors, and it includes a hyperlink to detailed debtor
information. The screen lists the collectors by "Name 229,"
"Address 230," "Phone 231," "Fax Number 232," "Email 233," and
"Comments 234." The remainder of FIG. 12 consists of methods for
navigating the account information page, allowing one to move "back
one entire page 235," "back by a single entry 236," "forward by a
single entry 237," "forward an entire page 238," to "Requery 239,"
"return to the main menu 240," as well as link to the system's
"Help Feature 241" and "Send Mail 242."
[0137] It is also possible to create a new collector profile. FIG.
13 depicts the New Collector Profile screen, which allows the user
to input information about a collector such as "Name 243," "Address
244-248," "Phone 249," "Fax Number 250," "Email 251," and "Comments
252." The system can process the aforementioned information,
putting it into the system database for later retrieval and usage,
by clicking "Submit 253." The user can clear the information in the
fields by clicking "Reset 254" or the user can return to the "Main
Menu 255."
[0138] FIG. 14 depicts the Pending Transactions Screen. This screen
allows the user to ascertain the status of any pending transactions
through the "Account 256" feature. The user can gain access to
"Debtor/Card Member Name 257," "Date/Time Information 258," an
illustration of the "Code 259," which includes a hyperlink to
singular pending transaction information, the transaction "Amount
260" information, the chosen "Payment Method 261," the "Date
(Expected or Promised) 262," and the pending transaction "CC/Check
Number 263." The user can also obtain the name of the "Issuer 264,"
information regarding a "Send Verification 265," and "Reason 266"
information. The user can navigate around the page via the "Back by
Page 267" feature, as well as "Back by Single 268," "Forward by
Single 269," "Forward by Page 270," "Requery 271," and "Return to
Main Menu 272." The screen also features a hyperlink to information
about the "System Help 273," as well as a hyperlink to "Send Mail
274."
[0139] FIG. 15 depicts a more detailed version of the Pending
Transaction Screen. "Originated 275" allows a user to ascertain the
date on which the debt originated, and "Account ID 276" displays
the account identification number, with a hyperlink to the detailed
account information screen. "Debtor 277" provides the name of the
debtor, and includes a hyperlink to the detailed debtor information
screen. Additional information about the account is provided
through the "Original Status 278," the "Amount 279," "Payment
Method 280" information, "Date (Expected Or Promised) 281," and
"Collector Decision 282" including ability to change decision with
pull down menu. "Submit 283" allows the user to submit the
information into the system database, while "Reset 284" permits the
user toclear the fields. "Return to Main Menu 285" allows the user
to return to the system's main menu.
[0140] A user may also input default settings for the system. FIG.
16 depicts the Systems Settings Screen, which provides information
fields for the default settings. The user inputs minimum monthly
payment information in "Minimum Monthly Payment 286," the maximum
number of months permitted to repay the debt in "Maximum Months to
Pay the Debt 287," and the applicable interest rate in "Interest
Rate 288." "Submit 289" allows the user to submit the system
settings, while "Reset 290" permits the user to reset the system.
"Main Menu 291" allows the user to return to the system's main
menu.
[0141] FIG. 17 depicts the Upload Data screen, which permits the
creditor to prepare data offline, and then upload that data to the
system for the convenient customization of the debt presentment
system. The user can input a file name via "Import File 292,"
select the file format under "Format 293," process and import the
file with the "Process 294" feature, and reset the system using
"Reset 295." A file is uploaded using "Upload Button 296," and the
user can input the full path to the local file using ""Full Path to
Local File 296A."
[0142] To keep track of downloaded information, a user can access
FIG. 18, which depicts the Download Results screen. The download
results are illustrated using "Download Results 297." The date,
time, characteristics and file name of the downloaded results are
accessed using "Date 298," "Time 299," "Characteristics 300," and
"File Name 301," respectively.
[0143] A user can access general information about the system
through the "About SolveMyDebt.com" screen, as depicted in FIG. 19.
Using "SolveMyDebt.com 302," the user can access descriptions of
the operator utilities.
[0144] A user who seeks assistance with any of the system's
features can access the screen depicted in FIG. 20, the
Administration Help screen. With "Access to Help and Instructions
for System Administration 303," the user reaches an illustration of
the system's help screen for administration.
[0145] Should the user wish to send Email, he or she may do so
through the Send Mail screen, as depicted in FIG. 21.
"Pre-Addressed e-mail ready to fill in and send 304" illustrates
the send mail screen for administration support.
[0146] When a debtor receives a notice from a collection agency
regarding an overdue payment, it will typically resemble the one
shown in FIG. 22. The notice depicted in this Figure informs the
debtor of the SolveMyDebt.com service, and invites the payor to
access the cite.
[0147] The debtor who chooses to visit the website will encounter
FIG. 23, which depicts the screen a consumer first meets upon
entering the system. "Branding 305" portrays the visual/graphic and
audio content that differentiates one system deployment from
another, and it can be dynamic based on the demographic
characteristics of the consumer to maximize communication
effectiveness (including multilingual, multicultural, etc.).
"Advertising 306" illustrates the advertising (which can be
dynamic) in the generic debt collection embodiment. The user
encounters an illustration of system construction information and
information for compliance with the Fair Debt Collection Practice
Act with "Instructions and FDCPA if necessary 307" (the information
is based on the locality of the debtor to comply with fair debt
collection laws). The screen provides the user with hyperlinks to a
variety of system resources via "Hyperlink to FDCPA 308,"
"Hyperlink to About SolveMyDebt.com 309," "Hyperlink to Security
and Privacy Info. 310," "Hyperlink to Access Account 311,"
"Hyperlink to Help 312," "Hyperlink to Send Mail 313," and
"Hyperlink to job Opportunities 314."
[0148] A debtor who seeks detailed information regarding the FDCPA
will link to FIG. 24. "FDCPA Information 315" illustrates
information for compliance with the FDCPA. The information is
dynamic based on locality of debtor to comply with fair debt
collection laws. "Hyperlinks 316" represents hyperlinks to about
SolveMyDebt.com, security information, access to the user's
account, help, and send mail.
[0149] A consumer who seeks detailed information about the system
itself will link to FIG. 25, which represents the About
SolveMyDebt.com screen. "SolveMyDebt.com 317" is a hyperlink to
information about the SolveMyDebt.com transaction community and,
where necessary, information for compliance with the Fair Debt
Collection Practice Act. "Hyperlinks 318" provides access to about
SolveMyDebt.com, security information, a user's account, help, send
mail, and job opportunities.
[0150] FIG. 26 represents the Security and Privacy screen, to which
a consumer who requires more detailed material regarding the
privacy of his or her transactions can link. The user can access
information regarding security and privacy policies within the
SolveMyDebt.com transaction community using "Security and Privacy
Information 319." The screen also provides links to about
SolveMyDebt.com, security information, access your account, help,
send mail, and job opportunities through "Hyperlinks 320."
[0151] A consumer who wishes to utilize the system can link to FIG.
27, which delineates the Access Your Account screen. To gain entry
into an account, the user follows the directions provided by
"Instructions 321," then proceeds to input the user's account
number in "Enter Your Account Number 322," and passcode in "Enter
Your Passcode 323." To access the account, the user submits the
account number and passcode via "Submit 324." The user also has the
opportunity to clear the account number and passcode using "Clear
325." The screen also provides "Hyperlinks 326," which links a user
to information regarding about SolveMyDebt.com, security
information, accessing one's account, help, sending mail, and job
opportunities.
[0152] Once the proper name and password have been processed, the
user will reach FIG. 28, which illustrates the Account Information
screen. On this screen, the user will find information regarding:
"Name 327," "Address 328," "Creditor 329," "Debt Description 330,"
"Principal Amount 331," "Interest to Date 332," Other Costs 333,"
and "Total 334." The user can also determine when repayment was due
with "Due Since 335," the identity of the collection agent using
"Collection Agent 336." The user has the option of either settling
the debt under "Pay the Debt 337," or disputing the debt via
"Dispute the Debt 338." "Help 339" and "Home 340" provide the user
with hyperlinks to the help information screen and to the
SolveMyDebt.com homepage, respectively. The debt's status can be
ascertained using "Status 341." "Account Details 342" provides a
hyperlink to the account details information screen.
[0153] If the consumer seeks more detailed information regarding
the account, he or she can access FIG. 29, which depicts the
Account Details screen. Information on this screen provides the
user with the particulars of the debt, including: "Debtor/Card
Member Name 343," "Date/Time 344," "Code 345," "Amount 346,"
"Payment Method 347," "Date (Exp. Or Prom.) 348," "CC/Check Number
349," "Issuer 350," "Reason 351," and "Last Updated 352." The
screen also furnishes hyperlinks to the account information screen
with "Account 353," the SolveMyDebt.com homepage using "Home 354,"
the system's help feature with "Help 355," and the send mail
feature with "Send Mail 356."
[0154] Once the consumer decides to pay the debt, he or she can pay
by credit card, check or money order. FIG. 30 illustrates the
screen a user encounters when paying a debt by credit card. The
user selects this choice of payment method with "Payment Method
357." The amount owed is depicted within the "Amount 358" field.
Information regarding the user's credit card is input by the user
into the "Card Member Name 359," "Card Issuer 360," "Credit Card
Number 361," and "Expiration Date 362" fields. The user manifests
assent to the specified payment arrangement with "Agree 363." "Back
264" is a means for the user to go back on the payment arrangement
screen.
[0155] FIG. 31 illustrates the screen a user encounters when paying
a debt by check or money order. The user selects this choice of
payment with "Payment Method 365." An illustration of the amount
owed is found in "Amount 366." The payment type selected, the
sending date, and the address to which payment is being sent are
illustrated in the "I'll be paying by 367," "I'll be sending it on
368" and "the address I'm sending payment is" fields, respectively.
The user assents to the specified payment arrangement using "Agree
370," or may go back on the payment arrangement screen using "Back
371."
[0156] If the consumer feels that the overdue payment with which he
or she is charged is erroneous, then the consumer may choose to
dispute he debt. FIG. 32 depicts the screen which allows a user to
dispute a debt. The user chooses from a list of reasons for the
dispute, listed as: "Never Ordered 372," "Never Received 373,"
"Already Paid 374," "Returned Merchandise 375," and "Other 376."
The user may also request a verification of the debt, using "Please
send me verification of the debt 377." The user then submits the
reason for dispute using "Submit 378," or may choose to clear the
dispute screen with "Clear 379."
[0157] FIG. 33 depicts the screen encountered by a user who selects
"Other 376" (from FIG. 31) as the reason for disputing the debt.
This screen illustrates "Never Ordered 380," "Never Received 381,"
"Already Paid 382," and "Returned Merchandise 383," all as seen on
the debt dispute screen from FIG. 31. "Other 384" is an
illustration of the "other" reason selection on the debt dispute
screen, as well. "Input Area for Other Reason 385" depicts the
field available to input the other reason for disputing the debt.
The reason may be reviewed by live collectors or a collection
agency which utilizes artificial intelligence. "Please send me
verification of the debt 386" allows the user to request
documentation of the debt. The user then submits the reason for
dispute using "Submit 387," or may choose to clear the dispute
screen with "Clear 388."
[0158] The preferred embodiment of the debt presentment and
resolution system of the invention is implemented primarily as an
Active Server application (i.e., the web page type generated by the
Microsoft.RTM. computing platform Active Server Pages (ASP)
application (the current description of the Microsoft.RTM. platform
for providing information via the Internet is described as "Web
Services"))--with other additional server applications that serve
to interface with transactors and then update the primary server
application database with transaction information. The payment or
transaction channels or interfaces are server applications that are
designed to provide potential transactors with the ability to
simply login to any of the channels or interfaces using a billing
organization's system UserID, as provided or communicated to them
by the particular billing organization, and that billing
organization's account number (or passcode) (i.e., debtor number,
contributor number, taxpayer number, etc) to complete transactions
through interaction at all available payment channels (i.e., a call
center, an automated phone (IVR), a website (or some other
"Transaction Community"), a wireless network, etc.) without the
impediment of enrollment or subscription. Additional applications
such as Microsoft.RTM. Access.RTM. are used to gather and
manipulate data. Microsoft.RTM. Access.RTM., Microsoft.RTM. Excel,
and Microsoft.RTM. Outlook.RTM. (or Microsoft Exchange Server.RTM.)
may also be used to create highly customized reports for the
billing organizations and email and/or HTML/XML delivery of
transaction information to billing organizations such as in the
embodiment described below. Still other applications may be used
for maintenance of the data and settings of the Internet payment
channels, such as the "Transaction Community" websites, including
system policies, and may be designed for use by billing
organizations, collectors, system administrators, system operators,
and third party users. Importantly, both applications share a
common database, for instance, Microsoft.RTM. SQL Server 2000.
[0159] These systems also use client-side scripting (mostly
JavaScript.RTM.), Java applets and ISAPI extensions in addition to
server-side ASP scripting. Usage of ActiveX.RTM. components on the
client side is reduced to minimum (only Microsoft.RTM. Internet
Transfer control is used on the client side to facilitate file
uploads) due to potential compatibility problems. This further
exemplifies the reason why JavaScript.RTM. was used instead of
VBScript (Visual Basic.RTM. Script) on the client side. The vast
majority of Internet browsers support Java applets and
JavaScript.RTM. on all platforms, while ActiveX.RTM. and Visual
Basics Script is supported mainly by Microsoft.RTM. Internet
Explorer.RTM. and primarily on Intel.RTM.-based environments.
[0160] Referring now to FIG. 34, shown is a flow chart depicting an
overview of the preferred embodiment of the debt presentment and
collection system according to the invention. Initially, as shown,
an Administrator first sets up a billing organization in the system
450. In doing so, the billing organization receives control
information, including a user identification name and/or number and
business rules for the unified processing, funding and reporting of
transactions through any of the payment channels. The Unified
reporting may be accessed through various methods and/or
channels--see FIG. 35A, steps 516-519. The billing organization
then communicates the control information and a customer ID (i.e.,
for a debtor) in a secure manner, such as via a hard copy bill, to
a transactor 452. Subsequently, the transactor provides the control
information and customer ID through a chosen payment channel (e.g.,
by mail, by walk-in to a payment center, by phone, by computer,
etc.) to initiate a transaction 454. Next, the transactor selects
from the available payment methods and completes the transaction
456. Finally, the system uses the control information, customer ID,
and transaction information to report transactions to provide
unified funding, reporting and data entry to the billing
organization 458. This debt presentment and collection system will
now be described in greater detail.
[0161] Turning to FIG. 35A, shown is a flow diagram that
illustrates the initial interaction and setup of a billing
organization with the debt presentment system of the present
invention. Prior to the use of the system, billing organizations
are contacted 500 through known methods, (e.g., mail
advertisements, telemarketing direct marketing, etc.) or integrated
into currently available billing and bill collection management
systems. The billing organizations must then decide 502 whether or
not to utilize the debt presentment system. Should a billing
organization decide to use the system 504, they will communicate
this to a system administrator along with their preferences
regarding setup considerations and customizations. The system
adminstrator then sets up the billing organization within the
system 508. Setup considerations and customization may include a
UserID setup where each UserID is tied to a billing organizations
choices for, e.g., banking information, account number rules
validation, termination notification, allowable payment channels,
payment methods, payment rules, and other information used to
interface with the transactor at the multiple payment channels.
Each billing organization provides its banking and other relevant
transaction information for the system administrator to create a
trust code which is provided to the billing organization 510. The
trust code may designate which bank is designated for deposit of
funds collected, debit of fees, as well as the custom information
choices, which may be further protected by password, encryption, or
other security method depending on the sensitivity of the
information used to interface with the transactors. The billing
organization may designate any bank or financial institution for
funds collected and may optionally designate a different account
for the debiting of transaction fees. The trust code may
additionally be assigned payment rules, fee policy, data center
information and/or other possible custom information such as
billing, marketing, advertising, promotional, incentive, campaign,
and interactive agent information. Optionally, eXtensible Markup
Language (XML) formatting may be utilized to publish and interact
with the transactors on several interfaces, such as the Internet,
IVR Telephone, wireless etc.
[0162] Also during setup 508, the system administrator will give
its UserID numbers to the billing organization. The UserID for the
embodiment described is preferably a seven digit number comprised
of two groups of three numbers followed by a single character check
digit. Other arrangements of characters and numbers may be used.
This check digit number validates the other grouping of numbers,
and authenticates that the transactor knows and intends to
communicate its UserID to begin a transaction at one of the
multiple payment or interaction channels. The UserID may be longer
in length and complexity depending on the purpose and requirements
of the particular system embodiment. The system administrator then
enables the various payment interfaces to accept the created UserID
and utilize the information associated with the UserID to interact
with the transactor in order to complete a transaction and report
results of the transaction interaction with transactor dynamically
through multiple reporting interfaces.
[0163] Depending on the particular needs of the billing
organization as determined by the system administrator, the UserID
will be set up to enable the billing organization to utilize
unified reports 512 by sending information from the system
administrator 550 that makes the multiple report formats available
514 to the billing organization. Such reports may include real time
account level detail 516, notification of termination status
payment 517, customized Excel reports 518, and other transaction
data formatted for automatic import into a billing organization's
database. In other words, transaction information from all payment
channels or interfaces is gathered and presented to the billing
organization in real time 516 and/or in customized reports 518.
Transaction information may also be specifically formatted and
transmitted to a website or some other "Transaction Community" or
designated Internet address for interaction using HTML/XML through
a standard personal computer having access to the Internet to
complete payment transactions. The appropriate level of password
protection, IP restriction, encryption, etc., may then be applied
to the various reports. The reports will preferably vary depending
on the billing organization and needs of the billing organization's
system administrator, customer service representative, treasury,
etc. Finally, the administrator is ready to communicate to the
billing organization that the system is now ready to be used by the
billing organization and transactor(s) 510. Accordingly, the system
administrator communicates the UserID(s) to the billing
organization, identifying which group of transactors or other
differentiation each relates to. The billing organization may then
communicate with the transactors, for example, using the US postal
service (secured by Federal Laws), the telephone, or any other know
method, identifying the availability of multiple payment channels
and the appropriate UserID and password 520.
[0164] Referring next to FIG. 35B, upon receipt of the billing
organization's communication, the transactor decides whether to
transact with the billing organization utilizing one of the
multiple payment or interaction channels/interfaces without the
impediment and distraction of enrollment or subscription 522. In
the preferred embodiment, payment or interaction
channels/interfaces include mail-in service, payment center or
kiosk service, automated or live telephone service, or Internet
service. Accordingly, payment may be initiated at any of the
multiple payment or interaction channels/interfaces by an Automated
Clearing House (ACH) debit or credit card. Other embodiments could
include utilization of any combination of additional emerging
payment methods such as "smart card", stored value cards, consumer
initiated ACH credit, verified balance ACH (utilizing a multibank
switch/agreement to verify balance availability), guaranteed ACH,
points, reward and incentive programs, or other form of payment and
value transfer available.
[0165] The transactor then decides which payment channel he wishes
to use to transact with the billing organization 522. The multiple
payment or interaction channels/interfaces include but are not
limited to use of an inbound and outbound call center 558 (see FIG.
35C), an inbound and outbound automated interactive voice response
(IVR) telephone or wireless personal data assistant interface 526,
an Internet website, "Transaction Community" or other designated
Internet address (see FIG. 35C) for interaction using HTML/XML
utilizing a standard personal computer and connection to the
Internet via modem or high speed access 584, a walk-in payment
center or kiosk 528 (preferably, conveniently located), or simply
by mail to the billing organization or some other outsource mail
remittance provider 530.
[0166] If the transactor chooses to transact via mail service, the
billing organization or other outsource mail remittance provider,
upon receipt of the transaction information 532, will employ a
handler to open the mail and sort the transactor's checks 534. The
opener will scan the check 536 (e.g., to capture the MICR line
information) and the payment stub 538, if available, to gather and
store the appropriate payment or transaction information to
complete a transaction through the debt presentment system. The
transaction information is then posted to the transactor's account
540 and batched by the system administrator 552. After the
information is batched, it is sent from the system administrator
550 (FIG. 35A) to update the unified reports available to the
billing organization 514 (FIG. 35A) (e.g., real time account level
report 516, notification of termination status report 517,
customized spreadsheet report 518, formatted transaction date
report 519). Optionally, information expressing the transactor's
payment or transaction information may be contained in bar coding,
watermarking or other information storage medium or layout to
increase the information capture speed, accuracy and depth of
information.
[0167] Alternatively, transactors may choose to call the automated
IVR system to complete payment transactions 526. Upon dialing the
telephone number provided, the transactor's call is answered by the
automated IVR system which prompts the transactor to enter a system
UserID and passcode 542. Of course, the transactor may have the
option of exiting the system without entering a UserID or passcode
548. On the other hand, the transactor may enter the system by
entering a valid UserID and passcode 546, which the system
verifies. If either the UserID or password are invalid, the system
may prompt the transactor to re-enter the information. This may be
performed an infinte number of times until a valid UserID and
password are entered. Optionally, the system may limit the number
of attempts by a transactor to enter a valid UserID and passcode
before automatically forcing the transactor to exit the system.
Once the transactor's UserID and passcode have been confirmed, the
system then prompts the transactor to select whether he wishes to
make a payment, review payment options, or exit the IVR interface
610. Other options may be made available to the transactor at this
time. If the transactor chooses to exit the IVR phone interface
616, the caller exits the system and the call is terminated.
Alternatively, if the transactor chooses to review payment options
612, the transactor will be advised of all available payment
options (e.g., standard payment options include electronic check
(ACH debit), credit card/debit card or restricted payment options
which may include only verified funds, or based upon business rules
and other incentive payment options including charitable
contributions, discounts, payment plans, etc.) and then be prompted
again to select to make a payment, review payment options, or exit
the IVR interface 610. Once the transactor chooses to make a
payment 614, the transactor will be further prompted to select a
payment method 618. Preferably, the transactor may elect to pay by
credit card or by electronic deposit, both of which will now be
described in greater detail. Optionally, the billing organizations
may also have automated dialing systems that automatically call the
automated IVR system to complete payment transactions.
[0168] Turning now to FIG. 35D, shown is a flow diagram of the
process of making a payment by credit card or electronic deposit in
accordance with the system of the invention. As shown, the
transactor, after choosing to pay by credit card 620, is prompted
to choose from the available card types 622 (e.g., MaserCard.RTM.,
VISA.RTM., Discover Card.RTM., American Express.RTM., etc.). Next,
the transactor inputs the amounts he wants to pay 624, which the
system checks to determine whether the entered payment amount 624
meets the parameters pre-set by the billing organization 626. If
the desired payment amount 624 does not meet the pre-set parameters
625, the transactor is requested to make another payment offer 627.
For example, if the offered payment amount is less than the minimum
dollar amount required by the billing organization, then the
transactor will be instructed to enter a higher dollar amount.
Other requirements may be pre-set by the billing organization.
Optionally, the system may allow this to continue an unlimited
number of times until the pre-set parameters are met, or it may
place a limit (e.g., three attempts) on the number of offers a
transactor may make before being asked to exit the system and start
over.
[0169] Once the payment amount entered by the transactor meets the
pre-set parameters of the billing organization 628, the transactor
will be prompted to input the name as it appears on the credit card
631, the credit card number 632, the month of the expiration date
of the credit card 633, the year of the expiration date of the
credit card 634, and the zip code of the billing address of the
credit card 635. Of course, the system may prompt the transactor
for this information, or additional information, in any order.
Similarly, the system may permit the transactor to input such
information into the IVR system by either speaking the requested
information into the telephone or by using the telephone keypad to
enter the information. Also, the system may be configured to
continue to prompt the transactor for each bit of information until
it receives a recognizable response. The transactor is then
prompted to authorize the charge or payment 636. The system
contacts the credit card company to determine whether the charge is
accepted or declined 637. If declined 629, then the transactor is
advised that the payment has been declined 623, and is prompted
again to choose from available credit card types 622. On the other
hand, if the credit card company accepts payment 638, then the
payment is sent to the unified reporting 640 and all of the
transaction information is batched by the system administrator 552.
Optionally, the transactor may be provided with a confirmation
number and/or a receipt, e.g., via email, confirming completion of
the transaction. Once batched, all of the information regarding the
transaction is sent from the system administrator in the form of
unified reports 550, accessible by the billing organizations (See
FIG. 35A).
[0170] Alternatively, the transactor may select, still referring to
FIG. 35D, the electronic deposit (or ACH debit) option 642. Here,
the transactor is again prompted to input the payment amount
desired 644. The system then checks whether the entered desired
payment amount meets the pre-set parameters of the billing
organization 646. If the desired payment amount does not meet the
pre-set parameters 650, the transactor is requested to make another
payment offer 652. For example, if the offered payment amount is
less than the minimum dollar amount required by the billing
organization, then the transactor will be instructed to enter a
higher dollar amount. Other requirements may be pre-set by the
billing organization. Optionally, the system may allow this to
continue an unlimited number of times until the pre-set parameters
are met, or it may place a limit (e.g., three attempts) on the
number of offers a transactor may make before being asked to exit
the system and start over.
[0171] Once the payment amount entered by the transactor meets the
pre-set parameters of the billing organization 648, the transactor
will be prompted to input a check number 662, a bank routing number
660, and a checking account number 664. Of course, the system may
prompt the transactor for this information, or additional
information, in any order. Similarly, the system may permit the
transactor to input such information into the IVR system by either
speaking the requested information into the telephone or by using
the telephone keypad to enter the information. Also, the system may
be configured to continue to prompt the transactor for each bit of
information until it receives a recognizable response. The
transactor is then prompted to confirm or authorize the charge or
payment 666. Once confirmed, the system then contacts the
appropriate institution to verify the bank routing number 668.
Optionally, the system may also verify the transactor's account
number. If the bank routing number does not meet the bank routing
number verification criteria 672, the transactor is again prompted
to re-enter the check number 662, the bank routing number 660, and
the checking account number 664. On the other hand, if the bank
routing number meets bank routing number criteria 670, the
transactor will optionally be provided with a transaction
confirmation number and an opportunity to receive a receipt, e.g.,
via email. Whether or not the transactor chooses to receive a
receipt, e.g., via email, the transaction information is sent to
the unified reporting 640. If the transactor chooses to receive a
receipt via email, he is prompted to enter his email address. The
receipt is then sent to the transactor. Finally, all of the
transaction information is batched by the system administrator 552.
Once batched, all of the information regarding the transaction is
sent from the system administrator in the form of unified reports
550, accessible by the billing organizations (See FIG. 35A).
[0172] Referring back to FIG. 35B, the transactor may choose to
walk-in to a payment center or kiosk 528 and either be served by a
customer service representative or use an automated transaction
kiosk. Here, the transactor may choose not to pay 554 or he may
choose to make a payment 556. Both the customer service
representative and the automated transaction kiosk may then utilize
the Internet service, "Transaction Community" or other designated
Internet address for interaction using, for example, HTML/XML via a
standard personal computer with connection to the Internet via
modem or high speed access to complete the payment transaction(s)
557.
[0173] Referring now to FIG. 35C, shown is a flow diagram of the
call center and the Internet website payment channels according to
the invention. As depicted, transactors may call or be called by
the billing organization's call center or an outsource call center
provider to make payment 558. In one instance, the call center may
accept an inbound call from the transactor 560, the transactor must
decide whether or not to pay. If the transactor chooses not to pay
562, the call may be terminated. Optionally, the call center
representative may provide information to the transactor before
terminating the call. If, on the other hand, the transactor chooses
to pay 564, the live call center customer service representative
can either conference the transactor with the automated IVR system
568 or complete the transaction by keying in the information into
the Internet website interface 570 to complete the payment
transaction 566. If the IVR system is utilized, the customer
service representative will conference the transactor with the IVR
system 568 and the transactor will be prompted to enter the system
UserID and passcode 542 (see FIG. 35B). The call center
representative may then disconnect from the call while the
transactor completes the transaction through the IVR as described
herein above with respect to FIGS. 35B and 35D. Alternatively, the
call center representative may remain on the line to provide
assistance to the transactor throughout completion of the
transaction.
[0174] Alternatively, if the Internet site is utilized 570, the
customer service representative will complete the transaction by
keying in the information into the Internet website interface to
complete the payment transaction for the transactor. Completion of
a transaction via the Internet site is described in greater detail
below.
[0175] Similarly, still referring to FIG. 35C, the call center may
assign a representative to make an outbound call to a particular
transactor to complete a transaction for a billing organization
572. In this case the transactor must decide whether or not to pay.
If the transactor chooses not to pay 574, the call may be
terminated and the system may notify the billing organization, or
simply provide the non-payment information to the Unified Reports.
Optionally, the call center representative may provide additional
information to the transactor before terminating the call. If, on
the other hand, the transactor chooses to pay 576, the live call
center customer service representative has two options 578--either
conference the transactor with the automated IVR system 580 or
complete the transaction by keying in the information into the
Internet website interface 582, as discussed herein with respect to
the Internet site payment option. If the IVR system is utilized,
the customer service representative will conference the transactor
with the IVR system 580 and the transactor will be prompted to
enter the system UserID and passcode 542 (see FIG. 35B). The call
center representative may then disconnect from the call while the
transactor completes the transaction through the IVR as described
herein above with respect to FIGS. 35B and 35D. Alternatively, the
call center representative may remain on the line to provide
assistance to the transactor throughout completion of the
transaction. Alternatively, if the Internet site is utilized 582,
the customer service representative will complete the transaction
by keying in the information into the Internet website interface to
complete the payment transaction for the transactor. Completion of
a transaction via the Internet site is described in greater detail
below.
[0176] The final payment channel according to the preferred
embodiment of the invention allows transactors to access an
Internet site, "Transaction Community" or other designated Internet
address for completing a payment transaction 584. Access may be
directly through the transactor's standard personal computer and
connection to the Internet via modem or high speed access to
complete payment transactions or through a call center where a
representative accesses the Internet site on behalf of the
transactor while on the telephone. The billing organization may
also email the transactors to provide links to the Internet site or
other "Transaction Community" or other designated Internet
address.
[0177] Once at the Internet website, the transactor may be provided
with information regarding terms of use 586, privacy policy 588,
security 590, and Better Business Bureau (BBB) privacy verification
592. Also, the transactor will be prompted to login to the system
594. If the transactor chooses not to login to the system, the
transactor exits the Internet website 598. Conversely, if the
transactor chooses to login, then the transactor enters the UserID
and passcode 600 to gain access to the system's payment interface.
After a valid UserID and passcode are entered the transactor is
presented with the account information screen 240 (see FIG. 29)
602. Next, the transactor is prompted to key in the name of the
person or entity of the account being paid 604, and verify that the
account number is correct 606. Upon verification, the transactor
selects the payment method from the options available 608, which
preferably include payment by credit card 700 or by electronic
deposit (or ACH debit) 740 (see FIG. 35D).
[0178] Once again, turning back to FIG. 35D, as described
hereinabove, the transactor may complete a transaction via multiple
payment options. For example, if transactor chooses to pay by
credit card 620, he is prompted to choose from the available card
types 622 (e.g., MasterCard.RTM., VISA.RTM., Discover Card.RTM.,
American Express.RTM., etc.). Next, the transactor inputs the
amount to be paid 624, which the system checks to determine whether
the entered payment amount meets the parameters pre-set by the
billing organization 626. If it does not 625, the transactor is
requested to make another payment offer 627. For example, if the
offered payment amount is less than the minimum dollar amount
required by the billing organization, then the transactor will be
instructed to enter a higher dollar amount. Other requirements may
be pre-set by the billing organization. Optionally, the system may
allow this to continue an infinite number of times until the
pre-set parameters are met, or it may place a limit (e.g., three
attempts) on the number of offers a transactor may make before
being asked to exit the system and start over.
[0179] Once the payment amount entered by the transactor meets the
pre-set parameters of the billing organization 628, the transactor
will be prompted to input the name as it appears on the credit card
631, the credit card number 632, the month of the expiration date
of the credit card 633, the year of the expiration date of the
credit card 634, and the zip code of the billing address for the
credit card 635. Once this information is input, the transactor
submits the information to the system. The system may prompt the
transactor for this information, or additional information, in any
order. The transactor may also be prompted to enter this
information until a fully recognizable response is entered. Once
the information is submitted, the transactor is prompted by the
system to authorize the payment or charge 636. The system contacts
the credit card company to determine whether charge is accepted or
declined. If declined 629, the transactor is advised that the
payment has been declined 623, and is again prompted to choose from
the available credit card types 622. On the other hand, if the
credit card company accepts payment 638, then the payment is sent
to the unified reporting 640 and all transaction information is
batched by the system administrator 552. Optionally, the transactor
may be provided with a confirmation number and/or receipt, e.g.,
via email, confirming completion of the transaction. Once batched,
all of the information regarding the transaction is sent from the
system administrator in the form of unified reports 550, accessible
by the billing organizations (See FIG. 35A).
[0180] Alternatively, the transactor may select the electronic
deposit payment option 642. Here, the transactor is prompted to
input the payment amount desired 644. Then, the system checks
whether the input desired payment amount meets the pre-set
parameters of the billing organization 646. As discussed above, if
the desired payment amount does not meet the pre-set parameters
650, the transactor is requested to make another payment offer 652.
The system may allow this to continue an unlimited number of times
until the pre-set parameters are met, or it may place a limit
(e.g., three attempts) on the number of offers a transactor may
make before being asked to exit the system and start over.
[0181] Once the payment amount entered by the transactor meets the
pre-set parameters of the billing organization 648, the transactor
will be prompted to input, for example, the check number 662, the
bank routing number 660, and the checking account number 664. Once
this information is input, the transactor submits the information
to the system, and the transactor is prompted by the system to
authorize the payment or charge 666. The system then contacts the
appropriate institution to check the bank routing number 668. If
the bank routing number does not meet the bank routing number
criteria 672, the transactor is again prompted to enter the
electronic deposit information. Once the routing number meets bank
routing number criteria 670, the transactor will optionally be
given a transaction confirmation number and an opportunity to
receive a receipt, e.g., via email. Whether or not the transactor
chooses to receive a receipt, transaction information is sent to
the unified reporting 640. Finally, all of the transaction
information is batched by the system administrator 552. Once
batched, all of the information regarding the transaction is sent
from the system administrator in the form of unified reports 550,
accessible by the billing organizations (See FIG. 35A).
[0182] While the present invention has been described with
reference to one or more preferred embodiments, such embodiments
are merely exemplary and are not intended to be limiting or
represent an exhaustive enumeration of all aspects of the
invention. The scope of the invention, therefore, shall be defined
solely by the following claims. Further, it will be apparent to
those of skill in the art that numerous changes may be made in such
details without departing from the spirit and the principles of the
invention. It should be appreciated that the present invention is
capable of being embodied in other forms without departing from its
essential characteristics.
* * * * *