Note: Descriptions are shown in the official language in which they were submitted.
CA 02441849 2003-09-19
INTERMEDIARY COMPUTING TO HANDLE DEBT MANAGEMENT PLAN
REQUESTS
A portion of the disclosure of this patent document contains material that is
subject to copyright protection. The copyright owner has no objection to a
statutory fair use
of this material, as it appears in the files of the files or records of the U.
S. Patent and
Trademark Office and the Canadian Patent Office, but otherwise reserves all
copyright rights
whatsoever.
II. TECHNICAL FIELD OF THE INVENTION
The present invention pertains to an electrical digital computer machine and a
data
processing system, methods of making and for using the machine, products
produced
thereby, as well as data structures and articles of manufacture pertaining
thereto, and all
necessary intermediates of that which is discussed herein, generally in the
field of
computerized aspects of debt management plan requests. More particularly, the
technical
field relates to intermediary computer processing and Internet-based
computing, along with
automated generation of related documentation, inter-computer communications,
and
networking.
III. BACKGROUND OF THE INVENTION
Consumers who are experiencing financial difficulties seek out the services of
Consumer Credit Counseling agencies or other Financial Assistance Centers for
help
restructuring their debt. These organizations interview the consumer, conduct
a budget
review/analysis, and enroll qualified consumers into Debt Management Plans.
The
2 0 enrollment process can involve a formal request/application submitted to
each creditor to
whom the consumer is requesting some measure of relief. The two traditional
methods for
submitting such requests is either by mail service or to use the services of
an electronic
payment processor such as MasterCard RPPSTM or Visa ePayTM.
When mail service is used to submit the applications the process can take in
excess
2 5 of one week (most cases longer) to complete versus submitting
electronically, which
shortens the cycle to usually 24 hours. The cost to use mail service is
substantially higher
then electronic submit because of ever-increasing postage costs, paper,
envelops, employee
costs to print out forms, stuff envelops, open envelops, sort, process, and
storage of the
applications. Additionally, the burden of manually tracking the activity and
producing activity
30 reports is substantial. The benefits of electronic submission of the same
applications are
numerous, lower cost of operations including postage, handling, personnel,
storage, and the
process time is significantly reduced.
The initial cost to use the services of an electronic payment processor is
high with the
CA 02441849 2003-09-19
additional requirement or burden of developing the intertace between the
processor and the
originator's software system. A high percentage of organizations use the
services of an
intermediary service provider (Concentrator or Bili Service Provider) as a
channel to one or a
multiple of electronic payment processors.
Creditors are also faced with the same interface requirements as the
originators, they
must make the same investment in terms of time, resources, and infrastructure
in order to
receive and process applications electronically.
In view of the foregoing, an object of the invention is to improve over some
or all of
the drawbacks indicated herein. This and other objects and advantages of this
invention will
become apparent from a consideration of the figures and ensuing description in
contrast to
the state of the art before the present invention.
IV. SUMMARY OF THE INVENTION
The present invention radically changes the dynamics of the above-described
process. Whereas the prior approach had originators and receivers supporting,
the present
invention allows an originator or a receiver to process these transactions
electronically using
a computer network, such as the Internet, in a secure manner. This approach
eliminates the
cost and burden of development, personnel, and infrastructure for both
originators and
receivers. The present invention also supports a multitude of data
communications packages
such as MasterCard RPPS~rM and Visa ePayrM.
The present invention encompasses interfacing, receiving, and processing
electronic
debt management request proposals (DMPs) and other related requests from an
originator,
concentrator, or Bill Service Provider of such requests. The present invention
also
encompasses presenting a Graphical User Interface (GUI), using a secure,
online computer
network such as the Internet or other similar direct access to an institution
or organization
2 5 that has a vested interest, extents credit, processes payments or performs
collection activity
on pass-due accounts.
Additionally, the present invention can allow multiple electronic payment
processors,
such as MasterCard RPPSTM and Visa ePayTM that use different communications
control
formats, protocols, and data file specification, to transmit electronically,
debt management
proposals or similar requests to a single source for presentment to a
multitude of credit
grantors, payment processors and collections companies. Again, this can
preferably be
carried out using a secure, online computer network such as the Internet or
similar direct
access method.
Further, the present invention can allow an originator of such
requests/applications to
submit the same using a GUI for presentation to a multitude of credit
grantors, payment
2
CA 02441849 2003-09-19
processors and collections companies, again by using a secure, online computer
network
such as the Internet or similar direct access method.
Also, the present invention provides a secure, online, and consistent method
for
originating, receiving and processing electronic requests while eliminating a
need to develop
custom interfaces, invest in expensive proprietary solutions, utilizing
suitable resources for
connection to a secure computer network such as the Internet or other similar
direct
connection.
Further detail is provided in the drawings and detailed discussion set out
below.
V. BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is an illustration of hardware in accordance with the present
invention.
Figure 2 is an illustration of method steps for making, in accordance with the
present
invention.
Figure 3 is an illustration of method steps for using, in accordance with the
present
invention.
Figure 4 is an illustration of a menu.
Figure 5 is an illustration of a flow chart for Review/Enter a new Proposal.
Figure 6 is an illustration of a flow chart for Request/Provide a Balance
Verification.
Figure 7 is an illustration of a flow chart for Drop a consumer from the
program.
Figure 8 is an illustration of a flow chart for Agency Administration.
2 0 Figure 9 is an illustration of a flow chart for Reports.
Figure 10 is an illustration of a flow chart for Proposal Management.
Figure 11 is an illustration of a Log in Screen.
Figure 12 is an illustration of a Logging in Screen.
Figure 13 is an illustration of a Transaction Screen.
2 5 Figure 14 is an illustration of a Processing Proposals Screen.
Figure 15 is an illustration of a second Processing Proposals Screen.
Figure 16 is an illustration of a third Proposal Processing Screen.
Figure 17 is an illustration of a fourth Proposal Processing Screen.
Figure 18 is an illustration of a fifth Proposal Processing Screen.
30 Figure 19 is an illustration of a sixth Proposal Processing Screen.
Figure 20 is an illustration of a Creditor Information Screen.
Figure 21 is an illustration of a Budget Information Screen.
Figure 22 is an illustration of a Main Proposal Screen.
Figure 23 is an illustration of a Approve a Proposal Screen.
35 Figure 24 is an illustration of a Decline a Proposal Screen.
3
CA 02441849 2003-09-19
Figure 25 is an illustration of a Defer a Proposal Screen.
Figure 26 is an illustration of a Retrieving Deferred Proposals Screen.
Figure 27 is an illustration of a Deferred Proposal Search Screen.
Figure 28 is an illustration of a Deferred Proposals Screen.
Figure 29 is an illustration of a second Deferred Proposals Screen.
Figure 30 is an illustration of a Message Function Screen.
Figure 31 is an illustration of a Creating a Message Screen.
Figure 32 is an illustration of a Creating a second Message Screen.
Figure 33 is an illustration of a Processing Options Screen.
Figure 34 is an illustration of a Message Responses Screen.
Figure 35 is an illustration of a Viewing Message Responses Screen.
Figure 36 is an illustration of a second Viewing Message Responses Screen.
Figure 37 is an illustration of a third Viewing Message Responses Screen
Figure 38 is an illustration of a Decisioning Screen.
Figure 39 is an illustration of a Agency Contact Information Screen.
Figure 40 is an illustration of a Agency Search Screen.
Figure 41 is an illustration of a second Agency Search Screen.
Figure 42 is an illustration of a Agency Database Screen.
Figure 43 is an illustration of a Drops Screen.
2 0 Figure 44 is an illustration of a Balance Verifications Screen.
Figure 45 is an illustration of a Reporting Screen.
Figure 46 is an illustration of a Standard Reporting Screen.
Figure 47 is an illustration of a second Standard Reporting Screen.
Figure 48 is an illustration of a third Standard Reporting Screen.
2 5 Figure 49 is an illustration of a fourth Standard Reporting Screen.
Figure 50 is an illustration of a fifth Standard Reporting Screen.
Figure 51 is an illustration of a Main Menu Screen.
Figure 52 is an illustration of a Consumer Information Screen.
Figure 53 is an illustration of a Add FBDs Screen.
30 Figure 54 is an illustration of a Biller Information Screen.
Figure 55 is an illustration of a Add FBCs Screen.
Figure 56 is an illustration of a Proposal Summary Screen.
Figure 57 is an illustration of a Proposal Sent Screen.
Figure 58 is an illustration of a Consumer Information Screen.
35 Figure 59 is an illustration of a Balance Verification Sent Screen.
4
CA 02441849 2003-09-19
Figure 60 is an illustration of a Consumer Information Screen.
Figure 61 is an illustration of a Consumer Drop Sent Screen.
Figure 62 is an illustration of a Review Pending Proposals Screen.
Figure 63 is an illustration of a Proposal Detail Screen.
Figure 64 is an illustration of a Review Returned Proposals Screen.
Figure 65 is an illustration of a Proposal Detail Screen.
Figure 66 is an illustration of a Database Entity Relationship Diagram
Figure 66A is a continuation of the illustration of a Database Entity
Relationship
Diagram.
Figure 66B is a continuation of the illustration of a Database Entity
Relationship
Diagram
Figure 66C is a continuation of the illustration of a Database Entity
Relationship
Diagram
Figure 67 is an illustration of a DTS Upload Diagram.
Figure 68 is an illustration of a DTS Download Diagram.
Figure 68A is a further detailed illustration of the DTS Download Diagram.
Figure 68B is a further detailed illustration of the DTS Download Diagram.
Figure 68C is a further detailed illustration of the DTS Download Diagram.
VI. DESCRIPTION OF A REPRESENTATIVE PREFERRED EMBODIMENT
2 0 Turning now to a detailed discussion of the invention, and preferred
embodiment,
please refer to the code in the CD Appendix hereto, which is incorporated
herein.
By way of an overview, the invention encompasses a method for Internet-based
intermediary computing to handle debt management plan requests. The method can
include
the steps of: receiving respective debt management plan requests at an
intermediary
computer, preferably by Internet communication, from each of a plurality of
request-
originating computers. The intermediary computer handles processing the
respective debt
management plan requests to produce respective, formatted and at least
partially validated
debt management plan requests. These are used in enabling a respective debt
management plan decision at one of the intermediary computer and I or a
creditor computer.
Electronically communicating a signal of said decision to the request-
originating computer
follows thereafter.
In one embodiment, the intermediary computer can be programmed to present an
electronic form at the request originating computers. The electronic form is
structured to
induce inputting of respective debt management plan request information.
Entering the
respective debt management plan request information, responsive to the
presented
5
CA 02441849 2003-09-19
electronic form, at input devices operably connected respectively to the
request-originating
computers. This approach can recognizably structure the respective debt
management plan
requests for the intermediary computer. There follows the step of
communicating the
respective debt management plan requests from the request-originating
computers to the
intermediary computer to carry out the above-mentioned receiving.
Alternatively, or preferably in addition, an embodiment can handle file
transfer. This
involves programming the intermediary computer to receive a batch file
communication of
the respective debt management plan requests and structuring the respective
debt
management plan requests at the request-originating computers to produce a
batch file
communication recognizably structured for the intermediary computer. Again,
there follows a
communicating the respective debt management plan requests, by said file
communication,
from the request-originating computers to the intermediary computer to carry
out the
receiving.
Another aspect of the invention can involve forming an on-line (preferably in
real
time) presentation of said debt management plan decision requests, and
conveying the on-
line presentation from the intermediary computer to one of the request-
originating computers
to induce the respective debt management plan decision.
Yet another aspect can involve applying at least one rule in automatically
producing
one of the respective debt management plan request decision at the
intermediary computer;
2 0 and signaling the creditor computer of automatically produced decision.
The rule can
automatically produce a rejection as the debt management plan request
decision, an
acceptance, or preferably both, as well as flag situations that require
further consideration.
The present invention can extend to the full consequences of intermediary
computing, including providing status reports (and other reports) at said
intermediary
computer. The status report can correspond to at least one of said debt
management
requests, an aggregate of said debt management requests in a period of time,
or preferably
both.
Still further, the present invention can comprehend authorizing creditor
computer
access to the intermediary computer; authorizing request-originator computer
access to the
3 0 intermediary computer; and testing for at least one (better two, better
three, etc. ) of the
following criteria of a known: request originating computer, user, creditor,
account number,
and/or mask or format (or any combination thereof).
More so, the present invention comprehends providing a web site to facilitate
at least
one of the steps.
Further, with general reference to Figure 1, the present invention can be
carried out
6
CA 02441849 2003-09-19
with components including at least one request originating computer 2 system,
an
intermediary computer 12 system, and at least one creditor computer 38 system.
Turning first to the intermediary computer 12 computing, for an overview of
its
operations, with a more detailed discussion to follow, the present invention
can be carried
out, for example, with four basic elements.
- Computer Network 17
- System control program 54
- Database 52
- GUI 61
Computer Network - For reasons of maximizing processing efficiency and
workload
balancing/sharing a Three-tier Architecture computer network 17 was
constructed. A one or
two-tier network will serve the same purpose but will experience diminished
performance.
The three-tier architecture separates the database services layer 26, the
application services
layer 30, and the presentation services layer 28. The three-tier application
uses the middle
layer to multiplex connections from the presentation services layer, which
reduces the
number of connections into the SQL Server. In addition, the middle layer will
host and
perform a great deaf of the system/program logic, which allows the database
services layer
to handle just the transfer of data. An external Storage Area Network (SAN) 24
was selected
to store data to minimize the growth of the database by moving old
data/records yet
2 0 remaining accessibility to those records.
1. Servers 4 - dual processors, 500 Mhz or higher, 1 gig of memory, Ethernet
cards.
a. GUI presentation services 28
b. Application services 30
c. Database services 26
2 5 d. Spare
2. Storage area network (150-gig) - external 24
3. Monitor - VGA - 16,000 colors 32
4. Monitor console selector A/B/C switch 31
5. Keyboard 34
30 6. Mouse or other appropriate pointing device 36
7. 10/100 8-port Ethernet Hub 22
8. Firewall - allow outbound TCP traffic 20
9, Router 18
10. Dedicated connection to computer network such as the Internet, Virtual
Private
3 5 Network (VPN), Point-to-Point, or other similar connection. 16
7
CA 02441849 2003-09-19
11. Read/write CD-Rom
12. Appropriate cabling and connectors
13. Microsoft Windows 2000
14. Microsoft SQL 2000
15. Cold Fusion 5.0
System control program 54 - (Application services)
1. Retrieves data files from download directory.
2. Parses new data files into correct databases) & database table(s), saves,
and
renames original file.
3. Performs error checking routine on received data files and prevents the
program from
posting the corrupted file/data and records the error.
4. Checks database (at pre-determined intervals) for processed files from
Users and
formats data for either Presentment or Upload to electronic payment processors
in
the proper format, protocol, and file specification.
5. Posts processed and formatted files into either database or Upload
directory as per
the type of transaction.
6. Records events in log event file.
7. Checks database for old processed files and achieve at pre-determined
intervals.
8. System operation and status are monitored locally.
2 0 9. Uses a local connection to review, display, and process individual or
records as
desired.
10. Has build-in query capability to separate or segment data record types as
desired.
11. Setup Download and Upload directories for data file exchange to and from
electronic
payment processors.
2 5 12. Install and setup communications control programs from various
electronics payment
processors.
Database - (Database services)
1. Develop database with multiple tables to receive and store data files that
meet,
exceed, or conforms to the physical file characteristics and specifications of
multiple
30 electronic payment processors such as MasterCard RPPSTM or Visa ePayTM file
specifications or others as may be desired.
2. Develop database 52 with multiple tables to receive and store data types
associated
with debt management proposals and other associated requests such as
verification
of account balances, consumer dropped from programs, consumer terminated from
3 5 program.
8
CA 02441849 2003-09-19
3. Incorporate database tables 52 for identifying and registering Originators,
Concentrators, Bill Service Providers, Receivers, and Users.
4. Incorporate database table 52 for recording unique User names and
Passwords.
5. Incorporate database tables 52 for segmenting:
a. Record types
i. Proposals
ii. Accepted
iii. Rejected - with rejection codes
iv. Balance Inquire
v. Drops
vi. Terminations
b. Record dates
c. Originators
d. Receivers
e. Users
f. Consumer information
i. Name
ii. Social Security Number
iii. Address
iv. Home Phone
v. Work Phone
g. Creditor information
i. Account number
ii. Account balance
2 5 h. Status of requests
6. Incorporate query-on-demand and reporting capabilities 74.
7. Another function of the database is to be an information repository
consisting of:
- Agencies
- Creditors
- Consumers enrolled in debt management plans
Agencies
Various states such as California, Oregon, Michigan, and Maryland have
licensing or
registration requirements that must be met in order for an Agency to transact
business within
that state. Agencies are known as Debt Adjusters in one state, Debt
Consolidators in another
state, Credit Counseling Agencies in others. Collectively these entities must
register or
9
CA 02441849 2003-09-19
become licensed to conduct business within the state and meet certain
requirements such as
having a physical presence within the state or posting a surety bond. By
compiling this
registration information on an agency by agency level and then comparing to
published lists
for each state of agencies authorized to conduct business a business rule can
be applied
that would verify that an agency is authorized to submit debt management
proposals for
consumers within that state. Adherence to local, state and federal
requirements is of
importance to creditors to ensure compliance with the Gramm-Leach-Bliley Act,
Public Law
106-102-Nov. 12, 1999. The state of origination is determined by comparing the
pre-fix of the
consumer home telephone number to the agency's physical address. If the agency
is not
authorized to conduct within that state of origination then a business rule
could be applied
that would reject the debt management proposal.
Agencies often have one legal name, transact business under another name and
market under yet another name. Agencies often originate business under one
name and
submit debt management proposals under a different name usually through a
servicing
company, which may or may not be a not-for-profit entity. The function of the
database is to
give the User the ability to associate any of the possible combinations to the
parent level.
The database is designed to track all agencies or originators at this detail
level.
Creditors
Creditors like agencies operate under many names and each has there own
2 0 requirements to meet for the submission of debt management proposals. Some
credits will
only accept debt management proposals when a Full Budget Creditor or Full
Budget
Disclosure accompanies the request. Other Creditors do not want the Full
Budget Creditor or
Full Budget Disclosure except in cases of hardship. All the Creditors have
different mailing
addresses, pay different rates of fairshare and have different interest rate
levels. The
2 5 database is designed to exchange this information with the agencies and
for agency
information to be shared with the Creditors. The invention provides a common
information
and communication bridge between the agency and the creditor.
Consumers
Once a consumer has been approved for a debt management plan the database acts
30 as a conduit between the enrolling agency and the participating creditor.
The agency has
informed the creditor when to except the first and subsequent payments from
the consumers.
Should a payment be missed the creditor can either individually or in a batch
send immediate
notification to the originating agency that a payment has been missed. The
agency after
investigating the incident can update the creditor, all by way of the build in
message service.
35 Consider now the GUI presentation services as follows.
CA 02441849 2003-09-19
GUI presentation services -
1. GUI that allows User to submit, receive, review, decision and store debt
management
proposals or other related documents utilizing a secure, online computer
network
such as the Internet.
2. GUI presents data by:
a. Organization
b. Portfolio
c. Number of new records for review
d. Number of deferred records for review
e. By record type (both new and deferred)
3. GUI presents additional provided information such as:
a. Full Budget Creditor (FBCs) -creditors listed on the proposed debt
management plan and proposed monthly payments
b. Full Budget Disclosure (FBDs) - consumer income, other expenses, and
reason for hardship.
c. Originating organization
4. GUI retrieves and presents either one record at a time or multiplelbatch
records as
determined by the User.
5. GUI utilizes Secure Socket Layering (SSL), and 128-bit encryption
technology.
6. GUI is hosted on a secure website behind a firewall.
7. GUI has unique User names and Passwords for Users.
8. GUI automatically disconnects after a pre-determined 'no activity period'.
9. GUI incorporates electronic mail (Email) as a means of enhancing
communications
between Originators and Receivers.
GUI provides a reporting module for User to obtain activity information.
With respect to request originating (e.g., agency) computer 2, from the
Request
Originating Computer 2 a User logs onto the System 1 by:
- Opens Internet Explorer from their computer.
- Types in the following URL: https//epdms.net
A logon screen Figure 11 will appear, the User enters their User ID and
Password as illustrated in Figure 12 and clicks the 'Login' button with the
mouse pointer 10.
An Authentication routine 63 will run and authenticate the User and user
permissions such
as access to reports.
If the User ID cannot be authenticated a message will appear "User ID or
Password
incorrect, please try again". If the User ID is authenticated, the Main Menu
Figure 51 will
11
CA 02441849 2003-09-19
appear.
From the Main Menu Figure 51 the User can perform the following actions:
- Enter a New Proposal
- Request a Balance Verification
- Drop a Consumer from a debt management program
- Proposal Management
o Review Returned proposals
o Review Pending proposals
- Add Full Budget Disclosure
- Clear Form
- Log out of the System 1
To enter a new proposal the User would click 'Enter a New Proposal' with the
mouse
pointer 10, the Consumer Information screen Figure 52 would appear. The User
would data
enter the following Consumer Information:
- Internal Identification Number
- Consumer Name
- Home Phone
- First Counsel Date
- Total Creditors
2 0 - Monthly Income
- Monthly Living Expenses
- Social Security Number
- Work Phone
- First Payment Date
2 5 - Total Debt
- Monthly Debt
If the User desires to submit a Full Budget Disclosure with the Debt
Management
Plan the User clicks 'Add Full Budget Disclosure' button with the mouse
pointer 10. The Add
FBDs screen will appear and the User can select the components/items that make
up the
30 consumer's budget. Items can be selected from the Item field drop-down box
such as:
- Rent
- Phone
- Utilities
- Food
3 5 - Entertainment
12
CA 02441849 2003-09-19
- Clothes
- Laundry
- Insurance
- Auto Payment
After selecting an item the User inserts the amount for that item in the
'Amount' field
and clicks the 'Add Item' to continue adding items. If an item is mistakenly
entered it can be
removed by clicking the 'Remove Item' button. After entering the desired
items, the User
clicks the 'Return and Commit' to attach the Full Budget Disclosure to the
Consumer's Debt
Management Proposal.
If the User did not want to submit a Full Budget Disclosure then that step
would be
by-passed by clicking the 'Continue' button with the mouse pointer 10 on the
Consumer
Information screen Figure 52.
After the User clicks the 'Return and Commit' button the next screen to appear
is the
Biller Information screen Figure 54. From this screen the User selects the
BiIIer/Creditors
that the Debt Management Proposal is being sent too. Depending on the number
of accounts
the Consumer has will determine the number of Debt Management Proposals that
will be
sent. If the consumer is putting just one account on a Debt Management Plan
then just one
will be sent. If the consumer has fifteen different accounts, then a total of
fifteen Debt
Management Plans will be sent. The System 1 will automatically append the
Consumer
Information Figure 52 and the Full Budget Disclosure Figure 53 information to
each
BiIIer/Creditor Debt Management Proposal being sent. On the Biller Information
screen
Figure 54 the User will data enter the following information:
- Account Number
- Biller Name
2 5 - Balance
- Proposal Amount
To ensure the accuracy of the account number the User can click the 'View
Mask'
button to view a list of qualifying account numbers. The BiIIer/Creditor
provides a listing of
Pre-fixes or Suffixes that account number adheres to. As each BiIIer/Creditor
is added they
will be added to a running list of the right-hand side of the screen until all
the Biller/Creditors
have been added.
The User can select to append a Full Budget Creditor to the Debt Management
Plan
by clicking the 'Add Full Budget Creditors' button with the mouse pointer 10.
The Full Budget
Creditor is a listing of BiIIer/Creditors that will receive a Debt Management
Proposal for this
particular consumer. If a Full Budget Creditor is not desired then just the
total number of
13
CA 02441849 2003-09-19
creditors and the total outstanding debt will be reflected on the Debt
Management Proposal
as illustrated in Figure 52 with no indication of who the additional creditors
are and what is
the amount owned to each. After clicking on the 'Add Full Budget Creditors'
button with the
mouse pointer 10 the Add FBCs screen Figure 55 will appear. The User data
enters the
following information and a running list of items will appear on the right-
hand side of the
screen:
- Creditor Name
- Account Balance
- Proposal Amount
As the User enters additional items the 'Add Item' button is clicked using the
mouse
pointer 10 to go to the next item. After items have been added the User clicks
the 'Return
and Commit' button. The information has now been data entered, and the next
screen to
appear is the Proposal Summary Screen Figure 56. This screens provides the
User with the
opportunity to review and edit the consumer information, BiIIerICreditors to
receive
proposals, Full Budget Disclosure and Full Budget Creditor if information. To
edit the
consumer information the User would click the 'Update Customer Info' button.
To edit the
Biller/Creditors to receive Proposals listing the User would click the 'Edit
Biller' button. To
send the Full Budget Creditor with the Debt Management Proposal the Yes/No
drop-down
box would be selected. To submit the Debt Management Proposal the User would
click the
2 0 'Send to Creditors' button.
After clicking the 'Send to Creditors' button the Proposals Sent Figure 57
screen
would appear. If desired the User can choose to enter a new proposal by
clicking on the
'Enter a New Proposal' button, the Consumer Information screen Figure 52 would
then
appear. By clicking the 'Main Menu' button the Main Menu screen Figure 51
would appear
2 5 and the User can select a different option such as 'Request a Balance
Verification'.
Alternatively, the User can select to logout of the system by clicking the
'Logout' button.
From the Main Menu Figure 51 the User clicks the 'Request a Balance
Verification'
button and the Consumer Information screen Figure 58 will appear. The User
data enters the
following information on the screen:
30 - Internal Identification Number
- Consumer Name
- Biller Name
- Balance
- Social Security Number
35 - Account Number
14
CA 02441849 2003-09-19
The User then clicks the 'Submit' button and the Balance Verification Sent
screen
Figure 59 will appear. The User has four options on this screen:
- Request additional Balance Verification for this consumer
- Enter a New Balance Verification for different consumer
- Main Menu
- Logout
If the User selects 'Request additional Balance Verification' then the
Consumer
Information screen Figure 60 will appear with the Biller Name field, Account
Number field,
and Balance field being blank. The new information is data entered by the User
and the
'Submit' button is clicked. The Balance Verification Sent Screen Figure 59
will appear and
the process can be repeated until the User has sent the desired Balance
Verifications for that
consumer. The User can select to enter a new balance verification for a
different consumer
by selecting the 'Enter a New Balance Verification' button and the Consumer
Information
screen Figure 58 will appear with blank fields.
The User may logout of the system by clicking the 'Logout' button or return to
the
Main Menu Figure 51 by clicking the 'Main Menu' button. From the Main Menu
Figure 51 the
User can submit a consumer Drop by selecting 'Drop a Consumer from the
program'. The
Consumer Information screen Figure 52 will appear and the User enters the
following
information into the fields provided:
- Internal Identification Number
- Consumer Name
- Biiler Name
- Social Security Number
- Account Number
2 5 The User clicks the 'Submit' button and the Consumer Drop Figure 61 screen
will
appear notifying the User that the Drop was sent to the Biller/Creditor.
Additional Consumer
Drops can be sent to different Biller/Creditors for the same consumer by
clicking the 'Enter
additional Drops for this consumer' button. If selected the Consumer
Information Figure 52
will appear with the Biller Name and Account Number fields blank, This process
can be
repeated until the User has sent out the Drop notifications to appropriate
BiIIer/Creditors.
From the Consumer Drop screen Figure 61 the User has the option of entering a
new
Consumer Drop on a different consumer, logging out of the system or returning
to the Main
Menu Figure 51.
To view 'Returned' or 'Pending' Debt Management Proposals or Balance
Verifications
the User would click the 'Returned' or 'Pending' buttons from the Menu Main
Figure 51. The
CA 02441849 2003-09-19
User can specify whether to view 'Returned' or 'Pending' by selecting the
appropriate button.
If the 'Pending' button is selected the Review Pending Proposals screen Figure
62 will
appear. Proposals and balance verifications that have not been processed by
the individual
Biller/Creditors will be shown. A 'View' button will appear on the right-hand
side of each item.
Selecting the 'View' button next to an item will open the Proposal Detail
screen Figure 63
showing high-level details about the proposal or balance verification, and the
date sent to the
Biller/Creditor for processing. A print version of the detail record is
available by clicking the
'Print' button. Pressing the 'Close' button will return the User to the Main
Menu Figure 51.
If the 'Returned' button is selected the Review Returned Proposals screen
Figure 64
will appear. Proposals and balance verifications that have been processed by
the individual
Biller/Creditors will be shown. A 'View' button next to an item will open the
Proposal Detail
screen Figure 65 showing high-level details about the proposal or balance
verification. The
Bilfer/Creditor decision (Approved/Rejected) is displayed in addition to the
date sent and date
processed. Items are removed from the list by the User clicking the 'Remove'
button next to
each item.
Turning now to the creditor computer 38, and its role in interfacing,
receiving, and
processing electronic debt management proposals (DMPs). Computer 38 also
handles other
related requests from an originator, concentrator, or Bill Service Provider of
such requests
and presenting with a Graphical User Interface (GUI) 61 using a secure, online
computer
network such as the Internet 14 or other similar direct access to an
institution or organization
that has a vested interest, extents credit, processes payments or performs
collection activity
on pass-due accounts.
From the Creditor Computer 38 processing commences as follows.
- Open Internet Explorer 48
2 5 - Type URL Address
- Press 'Enter'
Login Screen 62 Figure 11 will appear, the size will occupy 113 of the
available
monitor 42 space so that the creditor's internal application can be open
simultaneously, to
view and record information from one application to the other without
toggling. Enter User ID
and Password as illustrated in Figure 12 and press the 'Login' button. An
Authentication
routine 63 will run and authenticate the User and User Permissions such as
access to
reports and identify the User as a batch or individual processor.
If the User ID cannot be authenticated a message will appear "User ID or
Password
incorrect, please try again". After three-failed authentication attempts the
User ID will be
locked out of the system. If the User ID is authenticated, the Transactions
Screen (Main
16
CA 02441849 2003-09-19
Menu) 64 Figure 13 will next appear indicating the following:
- Number of new proposals to decision.
- Number of deferred proposals to decision.
- Number of new drops to process.
- Number of deferred drops to process.
- Number of new balance verifications to process.
- Number of deferred balance verifications to process.
Additionally, the User can access their mailbox 67, search for an agency
(originator)
75 or view reports 74. To process new proposals the User would merely press
the New
Proposals button as illustrated on Figure 14 using their mouse 46 and pertorm
a similar
action for the desired functions available.
Once the New Proposal button has been pushed a Processing Proposals screen
Figure 15 will appear indicating the number of proposals for each creditor
portfolio. Each
portfolio will have a radio button next to it and the cursor or focus will
default to the first
portfolio. If this is the desired portfolio to work then the User presses the
Select button or the
User can select any one of the portfolios shown.
After pressing the select button the Proposal Processing Screen Figure 16 and
Figure 17 will appear. The screens in Figure 16 and Figure 17 will indicate
that this is a New
Proposal and provide the following information:
- Card or account number and card name.
- Social Security Number of the consumer/customer.
- Consumer/customer name.
- Agency identification number.
- Consumer/customer home phone number.
- Consumer monthly living expenses.
- Consumer monthly unsecured debt payment.
- Spouse name.
- Spouse Social Security Number.
- Consumer/customer work phone number.
- Consumer/customer monthly income.
- Number of accounts on debt management plan.
- Current balance as reported by agency.
- Proposed monthly payment for this account
- Payment calculated as percentage % to current balance.
3 5 - Date of 1 S' expected payment
17
CA 02441849 2003-09-19
- Field to data enter the actual balance
- Field that automatically calculates payment
- The fairshare amount typically offered
- Agency address information.
- Agency phone number.
- Agency fax number.
- Agency contact person.
The method of transmission of the proposal and the number of new proposals
remaining in the portfolio queue is indicated in Figure 18, it would show
either:
- Intermediary computer 12 identity
- MasterCardO
- VisaO
If a printed copy of the proposal information is desired, then a print feature
71 is
available as illustrated in Figure 19.
If the Full Budget Creditor 69 (FBC) was submitted with the original proposal
it can be
viewed by pressing the 'Show FBC' button as illustrated in Figure 20. The FBC
displays a list
of Creditors on the cardholder's debt management plan, their balances, and
monthly
payments.
If the Full Budget Disclosure (FBD) 68 was submitted with the original
proposal it can
2 0 be viewed by pressing the 'Show FBD' button as illustrated in Figure 21.
The FBD displays a
listing of the client's monthly income and expenses.
The User would now data enter the actual account balance as illustrated in
Figure 22.
Based on the creditor payment guidelines the new payment field would
automatically reflect
the needed payment. If the payment amount proposed is still within the
creditor guidelines,
the 'New' payment will appear in green text as a visual indicator. If it is
not within the creditor
guidelines, the 'New' payment will appear in red also as a visual indicator.
If the 'New'
payment is acceptable, select 'Approve' from the Select Action drop down list
and click
'Respond' as illustrated in Figure 23.
To decline a proposal, select the appropriate decline reason and click
'Respond' as
illustrated in Figure 24. The reasons selected most frequently will appear at
the top of the list
and the decline reason selected will be communicated to the originating
agency.
If the User is unable to decision the proposal for any reason, it can be
deferred until a
later date by clicking the 'Defer' button as illustrated in Figure 25.
When it is desirable to retrieve a deferred proposal, click on Deferred
Proposals on
the Transactions Screen as illustrated in Figure 26. The Search for Deferred
Proposals
18
CA 02441849 2003-09-19
Screen Figure 27 will appear, search by Account Number, Social Security Number
or Name
and click the Display Matches. If no search criterion is entered, then all
unprocessed
deferred proposals will be returned. Choose the radio button for the proposal
to be viewed
and click 'Select' button to view the deferred proposal as illustrated in
Figure 28. The
deferred proposal is now available to be decisioned appropriately as
illustrated in Figure 29.
When the User needs additional information before making a decision on a
proposal,
the User can contact the originating agency by using the 'Message Function' by
clicking on
the 'pen' icon as illustrated in Figure 30. Moving the mouse 46 pointer over
the pen icon will
cause it to change to 'Write Msgs'. A text box will appear where the User
enters the message
and clicks the 'Send Mail' button to forward the message. The System 1
automatically inserts
the following information to assist the originating agency in identifying the
consumer as
illustrated in Figure 31:
- Client ID Number
- Proposal Trace Number
- Today's date
- Transaction Type
The User is then notified that the message was sent and can closeout that
window/screen as illustrated in Figure 32, which will take the User back to
the Proposal
Processing screen as illustrated in Figure 33.
2 0 The User can access itemized response by selecting 'Mailbox' on the
Transaction
Screen as illustrated in Figure 34. If messages are waiting in queue, select
'Go To' in order
to view the messages attached to a transaction as illustrated in Figure 35.
When an inbound
or outbound message is attached to a proposal, a mailbox icon will appear on
the Proposal
Processing screen as illustrated in Figure 36. Click on the mailbox icon to
review messages
2 5 associated with that proposal. The original message is displayed along
with the response.
The most recent correspondence will appear at the top as illustrated in Figure
37. The User
closes the window after reading the message. Additional messages can continue
to be sent
as needed as illustrated in Figure 38.
At times it may be appropriate for a creditor User to talk directly with an
originating
3 0 agency therefore the originating agency contact information is provided on
the Proposal
Processing screen as illustrated in Figure 39. Additionally, a User may lookup
an agency
within the database by clicking the 'Find Agencies' button from the
Transactions Screen
(Main Menu) 64 as illustrated in Figure 40. The Search for Agencies screen
will appear
where the User can search by Agency Name, Agency City, Agency State, or Agency
Phone
35 and then click the 'Display Matches' button as illustrated in Figure 41.
Clicking the 'Display
19
CA 02441849 2003-09-19
Matches button executes a SQL query command of the database and the results
appear on
the next screen as illustrated in Figure 42. Using the mouse pointer 46 a User
may select
agency results that were returned to view more detailed information about that
agency.
Sometimes it is appropriate to 'Drop' a consumer from a debt management plan
for
various reasons, 'Drops' are processed in a similar manner to proposals. The
Transaction
Screen (Main Menu) 64 Figure 13 will indicate if new drops are available for
the creditor.
After selecting the 'Drops' button the next window to appear will be the Drops
screen, the
screen is for informational purposes to the Creditor User. The Creditor User
will annotate the
consumer drop within their internal system and then click the 'Acknowledge'
button on the
screen as illustrated in Figure 43. No reply is sent back to the originating
agency unless the
Message Function is used.
Balance Verifications are also processed similar to a proposal. The
Transaction
Screen (Main Menu) 64 Figure 13 will indicate if new Balance Verifications are
available for
the creditor. After selecting the 'BaIVers' button the Balance Verifications
screen will appear
where the Creditor User will data enter the current account balance into the
'Act' (actually
account balance) field provided and then click the 'Submit' button as
illustrated in Figure 44.
This account balance information will be transmitted back to the requesting
originating
agency. The message function is also available for balance verifications.
A variety of reports are available to Users that can be accessed by the
Transaction
2 0 Screen (Main Menu) 64 Figure 13. This option is permission based and will
appear on the
screen if the User is assigned access by their Supervisor and authenticated in
the initial login
procedure. As illustrated in Figure 45 the User accesses the Reports Menu by
clicking the
'Reports Menu' button. The Reports Menu page will appear next Figure 46
fisting the reports
available by category:
2 5 - General Reports
- Consumer Reports
- Agency Measurements
- Referral Tracking
- Employee Measurements
3 0 Each report is supported by a unique SQL query with one supported variable
consisting of the time period. A User can define the following time periods as
illustrated in
Figure 47:
- Today
- Yesterday
3 5 - Week to date
CA 02441849 2003-09-19
- Past 7 days
- Month to date
- Past 30 days
- Year to date
- Past 365 days
- Custom time period
Each report is in a standard report format as illustrated in Figures 48-50.
Returning now to the Intermediary Computer 12 system, in this Client/Server
embodiment, the Request Originating Computer 2 and the Creditor Computer 38
are
considered the clients. Clients access the System 1 through the Applications
Server 28. The
Applications Server 28 makes connections to the Database Server 26 to access
data and
return the results to the clients. This allows the Application Server 28 to
organize all client
connections to the Database Server for optimum connection pooling.
The System 1 is designed to transfer or exchange information between the
Request
Originating Computer 2, and the Creditor Computer 38 with the System 1
directing the flow of
exchange and then warehousing the data in a SQL database on the Database
Server 26.
Clients use a web server application written in Cold Fusion for easy access to
the SQL
database using the Internet to establish communications to the Applications
Server 28. This
is illustrated in Figures 11-65. ODBC serves as the application programming
interface (API)
that transform SQL Server instructions and data into system calls that
communicate with the
underlying network protocol layer. TCP/IP is selected at the network protocol
layer. The
Local Area Network 17 is Ethernet.
The SQL database uses tables Figure 66 to organize and store data, system
stored
procedures to accept input parameters, use local variables, and return data.
System stored
procedures can return data by using output parameters, return codes, result
sets from
SELECT statements, or global cursors. Defaults are used where no value is
explicitly
entered; constraints are used for identifying valid values and for enforcing
data integrity
within the database tables and between related tables.
The SQL database is designed to accept data files/requests from multiple
sources,
MasterCard RPPS and Visa EPay are two such sources. These sources have
scheduled
times when data files are downloaded to The System 1. Sequel Server Scheduler
is set to
execute the Sequel Download Manager program once each hour. Upon execution the
Sequel Download Manager program queries the download directory for any new
files from
MasterCard RPPS or Visa EPay. If a new file is found the Sequel Download
Manager
3 5 program executes the Sequel Download program, which parses the new file
into the proper
21
CA 02441849 2003-09-19
database tables and sets system flags to indicate that new records are
available for
processing by either Request Originating Computer 2 or Creditor Computer 38.
Additionally,
a copy of file is created in the Processed directory. The Sequel Download
program parses
the file as follows:
- Transactions are separated correctly by type -
o Proposals
o Balance Verification
o Drops
- Transactions are separated by BiIIer/Creditors
- Transactions are separated by Portfolio
- Transactions are separated by Request Originating Computer (Agency) 2
Additionally, Sequel Server Scheduler is set to execute the Sequel Upload
program
at alternating times. The Sequel Upload program runs a system-stored procedure
that looks
for newly processed records. Upon finding newly processed records the program
determines
the input source (MasterCard RPPS or Visa EPay) and creates an upload file in
the
appropriate format and specifications for each source. Once assembled the
newly created
upload file is placed in the upload directory with appropriately assigned file
names relative to
the communications requirements of each source. The Sequel upload program
updates
each record of the newly created file with the date/time the record was
uploaded. A duplicate
2 0 copy of the file is stored in the Processed directory.
Additional input sources would be the Clients from either the Request
Originating
Computer 2 or the Creditor Computer 38 who can submit data at any time and
therefore the
Sequel Server Scheduler is not used with these sources. The Cold Fusion web
application is
used to pass variables to the database where system stored procedures executes
the steps
2 5 to create new records and queries are used to update existing records.
Depending upon the transaction type or function desired by the clients the
Cold
Fusion web application passes custom queries to the Sequel database to perform
the Sequel
database operation. Examples would be:
- Creditor Computer 38, after a successful logon by a User a query is run
automatically
30 to count available transactions in the creditor work queue. The
transactions are sorted by
transaction type.
- Request Originating Computer 2, when a User desires to check for 'Pending'
proposals the Cold Fusion web application submits a query to the SQL database
by clicking
the 'Pending' button and the results are returned and displayed in Cold
Fusion.
3 5 While the above description contains many specificity's, these should not
be
22
CA 02441849 2003-09-19
construed as limitations on the scope of the invention, but rather as an
exemplification of the
invention and one embodiment thereof. Many other variations are possible.
Thus, the
foregoing is illustrative of the broad scope of the invention, which more
particularly should be
determined by the patent claims and their equivalents, rather than by the
principal
embodiment and other examples described above.
23
