Patent Application
20070100749
The present invention relates to online tools for management of account balance and bill payment operations.
Personal online banking is well known. A description of such technology and functionality appears, for example in U.S. Pat. No. 5,903,881, issued May 11, 1999 to Schrader, et al. for “Personal online banking with integrated online statement and checkbook user interface.” Users of online banking sites often perform a number of tasks at such sites, including initiating and verifying bill payment activities. Some users also use such sites for checking bank balances, verifying that certain transactions have taken place, and transferring money from one account to another.
Banking websites are, in general, able to provide information as to account balance, including transactions that have been processed by the bank. These account balances do not, in general, take into account future bills and other transactions that have not yet been processed by the bank. In order to accurately project their balances and bill-paying ability into the future, users are required to maintain a separate transaction record, either manually or in a personal financial software application such as Intuit Quicken or Microsoft Money. This separate transaction record can be updated to include downloaded transactions as well as manually-entered transactions, and can take into account expected future bills (including recurring bills). Unlike the separate transaction record maintained locally by the user, in general, the transaction information at the banking website does not include information about future bills (including recurring bills) and other transactions that have not yet been processed by the bank. Accordingly, there is no single place where the user can see accurate balance projections that include both user-entered transactions and bank-processed transactions at banking website.
In various embodiments, the present invention provides methods and systems for including expected bills in projected balances at a website associated with a bank or other financial institution. The user can manually enter bills, including those that have not yet been processed by the financial institution and are therefore not yet available to the financial institution website. These bills can include, for example, recurring bills, whether such bills have fixed or variable amounts. For bills having variable amounts, an estimate can be provided. The user can also manually enter transactions (and recurring transactions), including those that have not yet been processed by the financial institution. According to the techniques described herein, the invention presents to the user projected balances that take into account such manually-entered information combined with information for transactions that have already been processed by the financial institution. The combination of user-entered and financial institution processed transaction data, including expected future bills that may or may not be known to the financial institution, provides the user with a more accurate assessment of his or her bill-paying capability and ongoing expected balance. Such information allows the user to manage bill payment more effectively, by for example setting up future transactions so that expected balances can cover expected bill payments. It also allows the user to 1) review the impact on his or her balance of paying bills on various days and with various dollar amounts, and 2) see where he or she will have excess cash or shortfalls so that he or she can more effectively manage excess cash by, for example, moving funds to or from other accounts.
The present invention thus provides a mechanism for accurately projecting cash flow within a banking website, by including user-entered transaction data and system-entered electronic data from financial institutions and other sources. In various aspects, therefore, the present invention facilitates cash and online bill paying management using any combination of user-entered pending transactions, pending balances, user-entered data appended to transactions, transactions categorization, and bill payment initiation, modification, and the like.
In one aspect, the present invention is able to extract information from electronically presented bills, and to automatically incorporate such information in future balance estimates. In one aspect, the present invention also provides an interface by which users can view such electronically presented bills via the financial institution website.
In one aspect, the present invention automatically reconciles user-entered or bill pay system generated transactions and bill payments with those received from the financial institution. Matching algorithms detect matches between user-entered transactions, including bills, and bank-processed transactions. Matches are tagged as such, and duplicates are avoided. In one aspect, if automatic reconciliation is not possible (for example, if amounts do not match because the user entered inaccurate estimate), the user is given an opportunity to manually indicate a match.
In one aspect, the present invention presents projected balances on a day-by-day basis within a calendar display that incorporates data obtained from a financial institution, as well as any combination of user-entered transaction data, user-entered bill data, and data extracted (scraped) from bills presented electronically.
In one aspect, the present invention is implemented in a web-based application. A web service is used to return HTML components and/or data as a means of achieving rapid integration into a website, so as to lower integration time and improve efficiency. In another aspect, the invention is implemented in the context of a software application running on a personal computer, handheld device, or other device.
One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
According to one embodiment, the present invention provides an online tool for assisting users in managing bill payments and determining projected bank account balances. The user is thus able to schedule bill payments and other transactions so as to insure that sufficient funds are available in the bank account to cover expenses. In one embodiment, the online tool uses data received from a financial institution (such as a bank or brokerage), combined with user-entered data and/or data from electronically presented bills. This combination of data provides more accurate projections of account balances, since it takes into account bills and transactions that may not yet be recorded or known to the bank.
By providing users with an accurate picture of their current and projected account balances, taking into account expected and future transactions and bills, the present invention allows users to better manage their funds and to ensure that sufficient funds are present for expected bill payments.
In the following description, the terms “bank”, “brokerage” and “financial institution” are used interchangeably and for illustrative purposes only; one skilled in the art will recognize that transaction data can be received from and/or sent to any entity, including credit card issuers, credit unions, third party processors, banks, and/or other entities. Furthermore, the following description sets forth the present invention in terms of a website containing functionality for entering transaction and bill data; initiating, scheduling, and managing bill payments; viewing reports; and the like. One skilled in the art will recognize, however, that the invention can be practiced in other contexts as well, including within a stand-alone or bundled software application such as a personal financial software application or accounting application. Such a software application can use locally stored data, or can communicate with a remotely located server or other resource associated with or obtaining data from a financial institution. Alternatively, such a software application can use a combination of locally stored data and data received from a remote resource. For example, the functionality described herein can be implemented as a feature of a software application such as Quicken, available from Intuit Inc., which is capable of communicating with financial institutions and bill paying institutions to send and receive transaction information to and from such resources.
Furthermore, the particular arrangements of elements in screen shots and reports shown here are illustrative of one embodiment and are not intended to limit the scope of the present invention.
Architecture
Referring now to
Online banking web server 101 includes functionality for permitting user 112 to securely access and manage his or her accounts at financial institution 103. Financial institution 103 can be a bank, brokerage, credit union, credit card issuer, or the like. In one embodiment, password protection and authentication, 128-bit encryption, SHTML, and other security features are used to ensure the security of the user's data. Once user 112 has been authenticated, online banking web server 101 obtains transaction data including posted transaction data 104a and/or pending transaction data 104b from financial institution 103, including dates, amounts, and the like, as well as account balance 115. Account balance 115 can be posted, available, pending, and/or projected balance. In one embodiment, only account balance 115 is needed, since account balance 115 incorporates all transactions already known to financial institution 103. In one embodiment, web server 101 comprises a financial institution interface 151 for communicating with financial institutions 103 and a client communication interface 152 for communicating with client machine 107.
As described in more detail below, online banking web server 101 sends HTML code or other presentation technologies to browser 110 causing browser 110 to present a user interface to user 112. The user interface allows the user to enter transactions and/or bills, as well as to review account balances and view transaction information. When user 112 enters transactions and/or bills, the user-entered data 111 is transmitted to online banking web server 101, which projects future balances accordingly. Based on user-entered data 111 along with transaction data 104a, b and/or account balance 115 received from financial institution 103, report generation module 106 presents report 102 including projected balances and other useful information either in the context of HTML web pages or in other formats such as PDF, Microsoft Excel, and the like. In one embodiment, report generation module 106 is replaced by or augmented by a module for generating a list of transactions, or register that may or may not be interactive. This register or other mechanism for presenting transactions and facilitating user 112 interaction with transactions can take the place of report 102 as shown in
As described in more detail below, in one embodiment report generation module 106 presents a report 102 including a series of projected balances for various dates in a calendar format. Reports 102 including projected balances are provided to browser 110 in HTML, PDF, Excel, or the like, and displayed to user 112. User 112 can also save and/or print such reports as desired.
Optionally, online banking web server 101 can also include scraper 108 which receives electronic bills 109 and/or other data 109A describing electronic transactions (such as electronic payment screen) addressed to user 112 and extracts amounts and dates from such electronic bills 109 and/or other data 109A. Report generation module 106 uses this extracted data in generating report 102 including projected balances for display to user 112. In one embodiment, scraped bill and deposit information is automatically added to a list of projected transactions, and if relevant, to a list of pending transactions for presentation to the user in accordance with the techniques described herein.
Online banking web server 101 also includes module 105 for reconciling and/or matching user-entered data (and optionally data from electronic bills 109 and/or other data 109A) with transaction data 104a, b received from financial institution 103.
In one embodiment, online banking web server 101 stores user-entered data 111 and/or data extracted by scraper 108 in data store 114 for future use. Upon future visits, data that was previously entered by user 112 or extracted from electronic bills 109 and/or other data 109A is retrieved from data store 114 so that it can be used by report generation module 106 for generating reports and by reconciliation/matching module 105 for reconciling with transaction data 104a, b from financial institution 103. Such data can also be used for transaction look-up, for example to present to the user a list of all transactions for a particular payee in the past year.
One skilled in the art will recognize that the system architecture illustrated in
Method
Referring now to
Optionally, scraper 108 receives and extracts 204 data from electronic bills 109 and/or other data 109A as well, so that such data can also be used in generating projected balances and/or displaying transactions and/or displaying presented bills.
Optionally, online banking web server 101 also retrieves 205 data from data store 114. Data from data store 114 may include, for example, user-entered data that was entered during previous visits to the website and/or data received electronically from the FI and/or data extracted from electronic bills during previous online sessions.
Reconciliation/matching module 105 detects 206 matches and duplicates between user-entered data 111 and transaction data 104a, b from financial institution 103; duplicates are deleted. In one embodiment, reconciliation/matching module 105 also detects matches between other types of pending transactions (whether or not they are user-entered) and transaction data 104a, b from financial institution 103. For example, reconciliation/matching module 105 can detect matches between transactions from a biller website, or transactions initiated as electronic bill pay transactions, and transaction data 104a, b. Transaction data can include both pending electronic transactions 104b that financial institution 103 is aware of and that is used for populating the pending transaction list, and posted transactions 104a that are used for reconciliation. In one embodiment, reconciliation/matching module 105 uses matching algorithms that detect inexact matches as well as exact matches. In one embodiment, reconciliation/matching module 105 is also able to perform one-to-many and/or many-to-many transaction reconciliation. In one embodiment, a user interface is provided which allows a user to indicate transaction matches, particularly in situations where reconciliation/matching module 105 is unable to find matches automatically. In one embodiment, the user can be prompted to indicate whether or not a proposed match is correct. Techniques for automated reconciliation are well known in the art.
Report generation module 106 generates and displays 207 report 102 including projected balances and/or transactions. By taking into account user-entered data 111 and data from electronic bills 109 and/or other data 109A, report generation module 106 is able to generate projected balances that take into account transactions and/or bills that are not yet known to financial institution 130; therefore, reports generated by report generation module 106 more accurately reflect user's 112 projected financial situation. Report 102 may be a static report, a dynamic report allowing user interaction, or an input/output screen that allows the user to update, view, modify, and otherwise interact with transaction data.
In one embodiment, user 112 runs a personal financial software application at client machine 107 and enters transactions and/or bills via the software application. In such an embodiment, user-entered data 111 can include data entered via the personal financial software application instead of or in addition to data entered directly at the website presented by online banking web server 101. Thus, user-entered data 111 includes any data entered by the user, whether entered while at the website or entered at some other time. This includes, for example, data entered by the user in a personal financial software application such as Quicken, temporarily stored at the user's computer, and uploaded to online banking web server 101 immediately or at some other point in time.
Report and User Interface
Referring now to
In one embodiment, report 300 includes calendar 301. Calendar 301 includes day-by-day projected account balances 302, which are determined by combining user-entered data 111 with transaction data 104a, b and/or account balance 115 received from financial institution 103, as well as, optionally, data extracted from electronic bills 109 and/or other data 109A. User 112 can navigate to other months by clicking on links 306. Calendar 301 is described in more detail below. Other formats for display of projected account balances may also be used.
In one embodiment, report 300 includes bar graph 303, which visually depicts projected account balances over some period of time using a series of bars 304. For example, bar graph 303 can include an account balance for the current date, plus account balances for 13 additional dates in the future. One skilled in the art will recognize that bar graph 303 can cover any desired period of time. In addition, in one embodiment user 112 can hover a cursor over (or click on) elements of bar graph 303 to see more detailed information.
The financial institution or user 112 can configure report 300 by specifying which elements are included or excluded, for example by clicking on checkbox 305 to hide or show bar graph 303. In one embodiment, the financial institution or user 112 can also specify various parameters and preferences for report 300, including for example which accounts to include, time periods for reports, visual characteristics of reports, and the like. In one embodiment, such parameters and preferences can be set via a preferences screen or page (not shown).
In one embodiment, report 300 includes monthly bills and deposits report 307. Monthly bills and deposits report 307 contains a projected list of anticipated bills and deposits for some period of time, such as for example the current month.
In one embodiment, items appear on this list if, for example, the user has set up a single or recurring payment in an online bill payment system with a processing date within the calendar month displayed. Thus, the present invention takes into account future bill payments in generating projected balances. In one embodiment, the list is populated with this payment information based on real time and/or batch interface with a bill pay system associated with financial institution 103. Single payments are displayed if their processing date falls within the time window being displayed. Recurring payments are displayed if any instance of the payment has a processing date that falls within the time window being displayed.
Some online banking websites allow a user to request repeating payment reminders that are generally not paid until the user requests that they be sent. In one embodiment, such reminders are displayed as transaction reminders rather than as transactions. In one embodiment, report generation module 106 takes such reminders into account when determining projected balances, although the transactions themselves are not processed until approved by user 112.
In one embodiment, items also appear in monthly bills and deposits report 307 if user 112 has set up a single or recurring reminder for a manual transaction (a transaction that is paid outside of the online bill payment system such as paper check or biller website), and that transaction has a processing date in the calendar month being displayed. In one embodiment, user 112 can add such transactions through an “Add Transactions” screen, described in more detail below. For such transactions, the transaction amount affects the “Projected Balance” displayed. In one embodiment, reminders for a single payment are displayed when the payment's processing date falls within the window displayed. Reminders for a repeating payment are displayed when any instance of the payment falls within the window displayed.
In one embodiment, items also appear in monthly bills and deposits report 307 if they represent electronically presented bills, such as those received by email or by other electronic means. Such items can automatically be added to monthly bills and deposits report 307. If a corresponding item already appears in monthly bills and deposits report 307, and if any details of the listed item differ from the information received electronically, in one embodiment the existing item is updated to reflect the information received electronically. Thus, if user 112 previously entered an estimated amount for a bill, the record is updated to reflect the actual amount when the bill is electronically received or otherwise input.
In one embodiment, Biller Direct transactions are automatically added to monthly bills and deposits report 307, or (if a corresponding item already appears in monthly bills and deposits report 307) will update the scheduled amount of the transaction. Biller Direct transactions are transactions that user 112 initiates by visiting a website associated with the biller.
Monthly bills and deposits report 307 includes several items of information for each listed item. Paid indicator 314 indicates whether the item has been paid. If paid, a checkmark is shown. If not yet paid, an unchecked box is shown. The user can check the checkbox, enter an amount in field 318 and a payment date in field 319, and then click on Make Payments button 315 to automatically initiate payments for the checked items. In the case of manually entered items, user 112 can check the checkbox when he or she makes payment via paper check or biller website, or alternative method. In one embodiment, such payments are processed using well known bill-paying systems and methods. In one embodiment, clicking on Make Payments button 315 causes confirmation screen 1400 (
In one embodiment, unpaid items are shown in boldface to further distinguish them from paid items. Save changes button 316 saves any entered changes and refreshes monthly bills and deposits report 307 to reflect the changes. Add a monthly bill or deposit button 317 navigates to an add transaction screen for user entry of transaction information.
Payee 308 for each transaction is shown. Method of payment 309 is also shown, and can include a check number (for manual checks), an icon indicating electronic payment, or other descriptor. Amount 310 is shown; for unpaid bills, a field 318 is provided so as to allow user 112 to enter or change the amount to be paid.
In one embodiment, date 311 is the anticipated or actual date that the transaction will clear at financial institution 103. If the current date is past the displayed date 311 and the item has not yet cleared, the transaction moves to be displayed on the current date, but the date 311 is maintained until the item clears. For unpaid items, field 319 is shown, to allow a user to enter a payment date. In one embodiment, button 320 provides access to graphical interface element for entering the payment date.
In one embodiment, for upcoming bills, user 112 can change the date via field 319 or the dollar amount via field 318 until the item is marked as in-process, paid, or posted. In response to user-entered changes to date and/or dollar amount, calendar 301 is updated. If applicable, projected balances 302 are also updated.
In one embodiment, status 312 indicates whether the item is posted, overdue, in process, scheduled, or the like. Unpaid items that are not yet due and have not yet been scheduled show a blank status 312. “Scheduled” means the item has been scheduled through online bill pay or manually, but it is not yet in process. “In-Process” means payment has been initiated by the bill payment engine. “Posted” means payment has cleared user's 112 account, and has been reconciled to the projected transaction.
In one embodiment, column 313 provides additional links, commands, and/or other information. For example, edit link 321 allows user 112 to edit the transaction by navigating to a transaction detail screen. Cancel payment link 322 allows user 112 to cancel a payment before it takes place, by navigating to a cancel transaction confirmation screen.
In one embodiment, account activity tab 323 provides access to account activity screen 1311, described below in connection with
In one embodiment, bills and deposits report 307 is presented as a scrolling list, so there is no limit to the number of items that can be included.
Report 300 may also optionally include a display (not shown) of any or all of posted balance (including transactions from financial institution 103), available balance (amount available for the user to withdraw as of today's date), and projected balance (taking into account user-entered data 111 and/or data extracted from electronic bills 109 and/or other data 109A).
Referring now to
Add transaction button 1324 navigates to add pending transactions screen 800A, 1500 or 1500B (
Monthly bills and deposits tab 1327 causes monthly bills and reports report 307 to be displayed, as described above in connection with
Various icons indicate status and other information for transactions. These include, for example, manually recorded transaction indicator 1328, electronic bill payment indicator 1329, written check indicator 1331, automatic payment indicator 1330, and reconciled transaction indicator 1334.
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Calendar Display
Calendar 301 includes projected account balances 302. In one embodiment, projected account balances 302 take into account posted transaction balance (account balance 115 from financial institution's 103 real-time or batch posting system, optionally including transaction data 104a, b) plus any outstanding items (including payments and/or deposits) that the end user has initiated or entered, were initiated on the end user's behalf, but have not yet posted at financial institution 103. Projected account balances 302 are calculated for each relevant date as the available balance+projected (unreconciled) transactions. In one embodiment, the projected account balance 302 is shown on the current calendar date and future dates displayed to show balance reflecting scheduled, in-process transactions, as well as any future dates where the user has initiated a transaction. In another embodiment, the projected account balance 302 is shown on all dates currently displayed.
In one embodiment, calendar 301 also includes posted and/or projected transactions. For example, as shown in
Projected transactions are displayed on calendar 301, in whatever format is appropriate. For example, payee name 905B can be shown on the projected date. Other information can also be shown instead of or in addition to payee name 905B, such as amount, status, or the like. Such information can be shown directly in calendar 301, or can be accessible by causing a cursor to hover over the date, or clicking on the displayed information, or by clicking on the calendar date or by some other means. In one embodiment, if the transaction is a manual payment, and user 112 has not indicated that he or she has made payment, and “overdue” indicator is shown within calendar 301, and the transaction is displayed as a projected transaction on the current date until it is cleared.
Posted transactions are displayed on calendar 301, for example as a payee name 905A shown on the projected date. There include transactions reported as posted from financial institution 103. Other information can also be shown instead of or in addition to payee name 905A, such as amount, status, or the like. Such information can be shown directly in calendar 301, or can be accessible by causing a cursor to hover over the date, or clicking on the displayed information, by clicking on the date in the cell, or by some other means. In one embodiment, color-coding or some other visual indicator is used to distinguish projected transactions from posted transactions.
In one embodiment, clicking on a displayed payee name 905A, B initiates a look-up of all payments made to the specified payee for an established historical window of time. The window of time can be user-configurable, or configurable by financial institution 103.
As described above,
Referring now to
In one embodiment, user 112 can obtain more detailed information regarding an account balance for a date, whether past, present, or future, by clicking on the displayed account balance or by causing an on-screen cursor to hover over the account balance. Referring now to
In one embodiment, if user 112 has more than one account, calendar 301 shows more than one balance 301A, 302B for a date, as shown in
In one embodiment, as shown in
In one embodiment, calendar 301 only shows a value for dates when the account balance has changed; in another embodiment, values are shown for each date whether or not there has been a change.
Calendar 301 can take any form, including a standard calendar-month view, a rolling calendar view (showing a number of weeks, such as 1 week in the past and 3 weeks in the future, in calendar format), a weekly view (showing a single week), or the like. In one embodiment, user 112 can specify the format of calendar 301; in another embodiment, the FI selects the form of the calendar; in another embodiment, the format is determined based on the number of transactions, available on-screen space within the display window, and/or other factors.
One skilled in the art will recognize that calendar 301 including account balances can be provided in other contexts as well. For example, a financial software application or accounting application or another device can display calendar 301 within its user interface, to show a series of account balances for various dates. Account balances can include past balances, present balance, and/or future balances, alone or in any combination. Account balance data can come from local sources, online sources, user-entered data, projections, estimates, or any combination thereof. One skilled in the art will recognize that the invention is not limited to the particular implementation of calendar 301 described herein, but includes any system, method, or computer program product or hand-held device where a calendar is displayed or printed that includes a series of account balances. Such implementations include, but are not limited to, personal computer software, websites, web applications, kiosk applications, PDA applications, cell phone applications, consumer devices, and the like.
Account Detail
Referring now to
Current balance detail section 419 shows posted balance (including transactions from financial institution 103), available balance (provided by the FI and indicating the amount the user can withdraw to for a given day), and projected balance (taking into account user-entered data 111 and/or data extracted from electronic bills 109 and/or other data 109A such as electronic bill payment, presented bills, and the like).
Transactions list 404 shows a number of pending (not yet posted) transactions 405. The user can edit a transaction by clicking on edit link 406 (which in one embodiment navigates to edit pending transaction screen 1800 as shown in
Posted transactions report 412 includes a list of posted transactions. Reconciled transactions are indicated by a symbol 413. For each posted transaction, there is shown a date 414, description 415. In one embodiment, description 415 includes one or both of a) a FI-provided description, and b) a user-entered description. In one embodiment, description 415 may also be a link to a more detailed description of the transaction, category 416, amount 417, and running balance 418.
Referring now to
Referring now to
Referring now to
The present invention has been described in particular detail with respect to one possible embodiment. Those of skill in the art will appreciate that the invention may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.
Some portions of above description present the features of the present invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or by functional names, without loss of generality.
Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.
The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the, along with equivalent variations. In addition, the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references to specific languages are provided for invention of enablement and best mode of the present invention.
The present invention is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks comprise storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet.
Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
The present invention is related to U.S. Utility patent application Ser. No. 10/769,277, for “Payables Manager,” filed Jan. 30, 2004, the disclosure of which is incorporated herein by reference. The present invention is related to U.S. Utility patent application Ser. No. ______, for “Calendar and Running Balance for Billpay Planning”, inventor Suzanne Y. Pellican, filed ——————, the disclosure of which is incorporated herein by reference. The present invention is related to U.S. Utility patent application Ser. No. 10/997,157, for “Monthly Transactions View”, filed Nov. 24, 2004, the disclosure of which is incorporated herein by reference.
