FIELD OF INVENTION

Embodiments of the present invention relate to electronic bill presentment and payment systems that retrieve billing data in the form of a secure legal document for a user from various web sources, aggregate the data, and present it to the user. The secured legal document that has been retrieved may replace the paper version of the document.

BACKGROUND Many organizations currently provide routine bills to customers by mailing out a monthly statement. The customer must open the statement, review the bill, and send payment by check using a return envelope that is generally provided. This system uses and wastes a great deal of paper, which is both expensive, and a waste of renewable resources.

In recent years, organizations have started making the billing information available to the customers via a biller website using secured digital documents. Secured digital documents may take the form of bills, payslips, credit card statements, retirement account statements, tax statements, etc. The documents are considered secured because they are not available to the general public, and are considered reasonably tamper proof. Various standards have been established concerning the storage and transmission of secured documents, in order to accommodate both privacy and security concerns of the consumer.

A consumer currently must individually login to each of these sites and manually download the bills to their local machine for archiving. As many consumers receive bills from many different billers, it can be both time consuming and frustrating attempting to separately login and download all of the bills individually. The individual biller sites also maintain a limited storage capacity for past bills. If consumers need to obtain copies of bills not on the system, additional time is required to request/receive these bills from the biller. This system makes it difficult for many consumers to adopt a paperless lifestyle. Such consumers continue to rely on regular mail delivery to receive their bills. Meanwhile, the biller would like the user to be able to access a secured digital replacement of the paper document, to allow them to save the costs associated with delivering the legally required paper copies.

There have been some attempts to overcome this problem. For example, US Patent No. 7,370,014 provides an electronic bill presentment and payment system that obtains user bill information from biller web sites. The '014 patent provides an electronic bill presentation and payment (EBPP) system that is able to obtain bills for its customers from scrape-enabled biller Web sites. The EBPP system has an interface which permits a customer to specify that the customer wishes the EBPP system to retrieve a customer's bills from a biller Web site at which the customer may access them. The customer provides his or her access information for the biller Web site to the EBPP system, which then uses a software agent to make scheduled scrapes of the biller Web site to obtain the customer's bill. The software agent scrapes not only bill summary information such as the account number, the statement date, the bill amount, the payment due date, the minimum amount and/or total amount due from the biller Web site, but also scrapes display information for the bill. The display information is the HTML that the biller Web site itself uses to display the bill. The agent cleans the HTML so that it can be displayed in the environment provided by the EBPP system. Both the bill summary information and the display information are incorporated into databases maintained by the EBPP system, which treats bills obtained from scrape-enabled Web sites in the same fashion as bills obtained from other sources.

Unfortunately, the '014 has several disadvantages. The system does not provide the customer with an actual copy of the secured digital document, i.e. the bill. It merely scrapes bill related information from the HTML code that is used to program the various biller websites. The user is therefore not provided with an actual copy of the bill, only summary information concerning the bill. The system only provides customer access to the various biller websites via the EBPP system residing on the service provider's website. If a customer cannot login to their account, they have no access to their bills.

It would therefore be a great improvement in the art if a system and method could be developed which overcomes one or more of the deficiencies cited above.

SUMMARY

One aspect of the present invention provides a method of aggregating secured electronic documents for a user from at least one biller website over the internet, and using the aggregated documents to assist the user in effecting bill payment, the method comprising the steps of: providing an interface allowing the user to provide login data for the biller website to a service provider; using the service provider to facilitate access to the at least one biller website using said login data; downloading at least one secure document from said biller website; scraping said at least one secure document for biller information; and providing an image of said secure document and said biller information to said user.

In an alternate embodiment of the method, all of said secure documents and biller information are stored in a database provided by said service provider and said user may only access the secure documents and biller information through a service provider website.

In a further embodiment, the step of providing an interface further comprises: downloading a thin client to a user computer system; wherein said service provider uses said thin client to provide copies of said secure documents and said biller information to said user, said copies and biller information being stored both on said user's computer and in a database maintained by said service provider, wherein the copies stored on said user's computer are available to the user when working offline. In additional embodiments, the step of providing an interface further comprises: downloading software to a user computer system; wherein said software allows said user to directly access the at least one biller website to obtain said secure documents and biller information; and copies of said secure documents and biller information are only stored in a database created by said software on said user's computer.

In some embodiments, the secure documents are maintained in the portable document format (PDF), said downloading step comprises downloading a copy of said PDF document and said image comprises an image of said PDF document.

In alternate embodiments, the step of using the service provider to facilitate access the at least one biller website using said login data further comprises: configuring a bot containing said user login data to access said biller website and download said at least one secure document. The method may further include a step for maintaining an archive of all of said secure documents and said biller information. The method may also include using said biller information to schedule future downloads of said secure documents.

An alternate aspect of the present invention provides a system for aggregating secured electronic documents for a user from at least one biller website over the internet, and using the aggregated documents to assist the user in effecting bill payment, the system comprising: a user interface that allows the user to provide login data for the biller website to a service provider; a service provider website that provides access to the at least one biller website using said login data; a bot provided by said service provider that downloads at least one secure document from said biller website; wherein said service provider scrapes said at least one secure document for biller information; and provides an image of said secure document and said biller information to said user.

In an alternate embodiment, the system may further include data storage means provided by said service provider, wherein all of said secure documents and biller information are stored on said data storage means and said user may only access the secure documents and bilier information through a service provider website that accesses said data storage means.

In other embodiments, the system may further include a thin client installed on a user computer system; wherein said service provider uses said thin client to provide copies of said secure documents and said bilier information to said user, said copies and bilier information being stored both on said user's computer and in a database maintained by said service provider.

In further embodiments, the system may further include: a software package installed on a user computer system; wherein said software package allows said user to directly access the at least one bilier website to obtain said secure documents and bilier information; and copies of said secure documents and bilier information are only stored in a database created by said software on said user's computer.

In alternate embodiments, the said secure documents may be maintained in the portable document format (PDF), said bot downloads a copy of said PDF document, and said image comprises said copy of said PDF document. The system may further include storage means for storing an archive of all of said secure documents and said bilier information. The system may also further include a scheduler that uses said bilier information to schedule future downloads of said secure documents from said bilier websites.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which: Figure 1 is a block diagram illustrating one embodiment of an aggregated secured electronic document push-based delivery, presentment and payment system according to the present invention:

Figure 2 is a block diagram illustrating one implementation of the embodiment of the system of Figure 1 ;

Figure 3 is a block diagram illustrating an alternate implementation of the embodiment of the system of Figure 1 ;

Figure 4 is a block diagram illustrating another alternate implementation of the embodiment of the system of Figure 1 ;

Figure 5 is a block diagram illustrating one embodiment of a download process flow that may be used with the system of Figure 1 ;

Figure 6 is a flow chart illustrating one exemplary scraping operation according to the embodiment of the system illustrated in Figure 1 ; and

Figure 7 is a flow chart illustrating one exemplary operational process flow for the system of Figure 1 ;

Figure 8 illustrates a Summary Page display of the system of Figures 1-4, as shown in the flow chart of Figure 7;

Figure 9 illustrates a My Bills page display of the system of Figures 1-3, as shown in the flow chart of Figure 7;

Figure 10 illustrates an actual bill being displayed according to the system of Figures 1-4;

Figure 11 illustrates a My Bills page display of the system of Figure 4, as shown in the flow chart of Figure 7; Figures 12A and 12B show example of alerts that may be displayed according to the system of Figures 1-4, as shown in the flow chart of Figure 7; and

Figure 13 illustrates one embodiment of a general computer system that may be used to implement the system of Figures 1-4.

DETAILED DESCRIPTION

Embodiments of the present invention provide a system and method to securely retrieve biller documents for a user over the internet from a plurality of biller sites, aggregate that information for the user, and provide the aggregated information to the user to assist in paying the bills. Figure 1 is a block diagram illustrating the overall concept for one embodiment of a system, designated generally with reference numeral 10, according to the present invention. The system 10 allows a service provider to securely retrieve biller documents for a user over the internet from a plurality of biller sites, aggregate that information for the user, and provide the aggregated information to the user to assist in paying the bills. In the embodiment shown in Figure 1 , the system 10 includes a web application server 20 connected and a Gateway server 30, each of which is connected to a database 40. It is understood that a greater or lesser number of servers may be used as desired. Similarly, it is understood that the database 40 may reside on one of the servers, or be a separate component of a network, either internal or external to the servers 20, 30. Each of the servers 20, 30 is connected to the World Wide Web or internet 50 via data path 52.

The system 10 further includes various components/applications that allow a user to connect to one or more biller websites 60 via the servers 20, 30 and/or the World Wide Web 50 via a data path 62. This embodiment of the system 10 shows Component A 100, Component B 200 and Component C 300, each of which connects to the internet 50 via data paths 54, 56, and 58 respectively. Each of these components 100, 200, and 300 will be discussed in more detail below. Figure 2 is a block diagram illustrating one implementation of the embodiment of Component A 100 the system 10 of Figure 1. Component A 100 provides users 110a, 110b, etc. with access to the internet 50 via data path 54 using, for example, the Hypertext Transfer Protocol (HTTP) or the secure Hypertext Transfer Protocol (HTTPS) to the application server 20 providing an interface to a plurality of biller websites 60a, 6Ob ₁ 60c, etc. The application server 20 may employ various software engines 140 to perform the tasks required by the embodiments of the present invention. In this embodiment, the software engine 140 is shown employing a plurality of bots 142a, 142b, 142c. The details concerning the use of the bots 142 will be discussed below.

In this embodiment, the application server 20 may also include a database storage area 150 and a document storage area 155. It is understood that the database storage 150 and document storage 155 may reside on a single storage device, including but not limited to a hard drive, and may be included entirely within database 40. Additionally, it is understood that the storage devices 150, 155 may reside separately from the application server 20.

Component A 100 allows users 110 to view their secured documents stored in the database 150 and/or document storage 155 located with the application server 20. In this embodiment, all of the documents that are retrieved from the biller websites 60 are accessed by the user 110 through the application server 20. No documents are downloaded onto the user system. Details concerning the operation of Component A 100 are provided below with reference to Figures 5-7.

Figure 3 is a block diagram illustrating one implementation of the embodiment of Component B 200 the system 10 of Figure 1. Component B 200 provides users 110 with access to the internet 50 via data path 56 using, for example, the Hypertext Transfer Protocol (HTTP) or the secure Hypertext Transfer Protocol (HTTPS), and to the application server 20 providing an interface to a plurality of biller websites 60a, 60b, etc. In this embodiment, thin client software is loaded onto a data/file storage device 220 of a local computer 210 of the user 110. The user 110 connects to the application server 20, which facilitates the document retrieval from the biller websites 60 using various bots 142.

Component B 200 not only allows users to view their secured documents stored in the database 150 and/or document storage 155 located with the application server 20, but also provides a local copy of the secured documents on the storage device 220. This allows users 110 to view their secured documents even if the computer 210 is not connected to the internet 50. Details concerning the operation of Component B 200 are provided below with reference to Figures 5-7.

Figure 4 is a block diagram illustrating one implementation of the embodiment of Component C 300 the system 10 of Figure 1. Component C 300 provides users 1 10 with access to the internet 50 via data path 58 (Figure 1) using, for example, the Hypertext Transfer Protocol (HTTP) or the secure Hypertext Transfer Protocol (HTTPS), and to the application server 20 providing an interface to a plurality of biller websites 60a, 60b, etc. When using Component C, software is loaded onto a data/file storage device 320 of a local computer 310 of the user 110. In this embodiment, the software loaded onto the user system 310 includes the bots 142, so thatno connection to the application server 20 is required.

When using Component C 300, all downloaded documents are kept on the storage device 320 of the local computer 310. This embodiment provides the user 1 10 with additional security as no copies of the secure documents are stored on the database 40 of the system 10. Details concerning the operation of Component B 200 are provided below with reference to Figures 5-7.

In operation, the system 10 may be implemented from the servers 20, 30 using a variety of software modules or engines that provide specific functionality. With respect to Component C 300, some of this functionality is duplicated on the user computer 310. As an overview, the system 10 takes information from the user 110 concerning the user's accounts at various billers 60, automatically schedules downloads of the user's bills, downloads the bills, parses the downloaded bills to extract relevant data, and provides this data to the user. The system 10 provides a bot 142 (software agent) that takes the user information, logs into the biller website, downloads a secured document, including, but not limited to the user's bill, and returns this image to the server document storage 155 of the system 10, or for Component C 300, to the storages device 320 on the local computer 310. A parsing engine extracts the desired information from the bill and stores this information in database storage 40, 150. The downloaded secured document may then be viewed by the user 110. Details of the functionality and processes will be discussed below.

Figure 5 is a block diagram, designated generally with reference numeral 400, illustrating one embodiment of a download process flow that may be used with the system 10 and Components A 100, B 200, and C 300 of Figures 1-4. When using Components A 100 or B 200, these tasks are performed by one or more of the servers 20, 30 of the system 10. When using Component C 300, these tasks are performed by the local computer 310.

A scheduler 410 executes a script 412 that is sent to a crawler 414. In some embodiments, the crawler 414 may be identical to the bots 142. In some embodiments, the script 412 may include biller credentials, the user ID and password, the identity of the. requester, and any other data required by the biller website to login. Secured documents, such as user bills, are downloaded, as shown with reference numeral 420, from the biller website 60. The downloading process is sometimes termed scraping, as the information is automatically "scraped" from the biller website. If the download is successful, the bill data is parsed from the bill, the bill is stored in the document storage database 155, and the captured bill data is stored in the database 150, as shown with reference numeral 430. When using Component C 300, the secured documents are stored on the storage device 320 on the local computer 310. If, for some reason, there is a capture failure, information is sent to the database 150 to provide alerts to either the user 110 or the service provider, as appropriate, as shown with reference numeral 440.

Figure 6 is a flow chart, designated generally with reference numeral 500, illustrating one exemplary scraping operation according to the embodiment of the system illustrated in Figure 1. It is understood in the discussion which follows that any secured document may be downloaded by the system 10. The use of the term "bills" is for illustrative purposes only.

The first step is to log in to the biller website, as shown with reference numeral 502. The next step is to determine whether or not the login was successful, as shown with reference numeral 504. If the login was not successful, the user is notified about any error that may exist in the login credentials, as shown with reference numeral 506. If the login was successful, the appropriate user accounts are identified, as shown with reference numeral 510. The bot will then scrape/navigate the biller website to determine if there are any new bills, as shown with reference numerals 512 and 514 respectively. If there are no new bills, a No New Bill Alert will be generated and sent to the user, as shown with reference numeral 520.

If new bills are available, they will be downloaded, as shown with reference numeral 522. The desired user billing information may then be parsed and stored, as well as the image of the bill, as shown with reference numeral 524. In a preferred embodiment, the bills are available from the biller website 60 in, for example,

Adobe® Portable Document Format (PDF) form. It is understood that relevant user bill information may also be scraped from the biller website Hypertext Markup Language (HTML) code using an appropriately configured bot.

In a preferred embodiment, the current amount due, total amount due, bill date, bill due date and number of pages is parsed from the downloaded bill and stored in the database. It is understood that some, all, or additional information may be parsed and stored, as desired. Once the bills are stored, the user will receive a New Bill Alert, as shown with reference numeral 528. The New Bill Alert may take the form of an email to the user, or it may be provided as part of the Alerts Engine, which will be discussed in more detail below.

As discussed above, various portions of the system 10 may be implemented as software modules or engines. By way of example and not limitation, the various engines may include a scheduling engine, a bill download engine, a parsing engine, an integration engine, and an alerts and notifications engine. Various software tools and/or programming languages may be used to implement the embodiments of the system 10. By way of example and not limitation, the software tools and programming languages may include the Java Language, Java Webservices, Java Servlet, Java Mail, PDF Box, Public License HTTP Client for Java, JDBC XML Parser, XML, MySqI Database, Microsoft C# Language, C# Mail API, Public License HTTP Client API for C#, and VistaDB. It is understood that other tools and/or programming languages may also be used.

It is understood that the functional descriptions which follow are provided by way of example only. The various functions of the system 10 may be implemented in various ways, as known to those of skill in the art. Example embodiments of the screen pages produced by the various engines discussed below are provided in Figures 8-12B.

The scheduling engine is configured to schedule and trigger the bill download engine for each of the users 110 and each of the respective billers 60. The bot for bill download will be triggered for each user 110 based on his/her billing cycle. In a preferred embodiment, the billing cycle date will be captured and updated from the parsed 'Bill Date' from each user's last bill for each of his subscribed billers 60a, 60b, etc. The next scheduling cycle may then be intelligently calculated based on past download patterns. In alternate embodiments, the scheduler may be configured by the user 110 to download bills on a particular day, as desired.

The bill download engine is configured to download bills from the various billers 60 for a particular user 110 based on the schedule provided by the scheduling engine. Dedicated bots for each biller 60 will be triggered by the scheduling engine for each user and for each biller website. The bills will be downloaded from the biller sites and stored in the document storage unit 155 of the file server 20, 30. In a preferred embodiment, the bills are downloaded as PDF documents, for later parsing by the parsing engine. Logs may be maintained in the database 150 for each download attempt. The logs may contain, by way of example and not limitation, information such as the User, Biller- Account, Timestamp, Success/Failure and Type of Failure. It is understood that other types of information may also be logged. These logs may be used by the service provider to provide online application reports. The reports may include information such as the type of failure, i.e. a connection error, login error, bill download error, etc. In case of any type of failure, the engine will retry the next day, at a time as determined by the service provider schedule, or as requested by the service provider or the user. On login failure, the bill download engine may notify the end user of the failure and the reasons therefore. If the number of bill download errors exceeds a certain threshold, as determined by the service provider, notification may be sent to the administrator of the service provider. This may happen, for example, when a biller website updates their HTML programming. In this case, the bot would need to be reconfigured to work with the new code.

As discussed above, once the download engine downloads the bills, the parsing engine parses the desired information from the captured bill. By way of example and not limitation, the information to be parsed may include: the bill date, the bill due date, the account number, the current charges due, the total outstanding balance, and the number of pages in the bill. It is understood that different or additional information could also be parsed by the parsing engine. As with the download engine, logs may be maintained in the database 150 for each parsing attempt, indicating the user, Biller-Account, Timestamp, Success/Failure, etc. These logs may be used by the service provider to provide online application reports.

For users who are using Component B 200 or Component C 300, the latest bills may also be automatically downloaded to the user specified path on their hard disk. The latest bills are defined as those bills which have not been previously downloaded for the user 110. A list of the bills downloaded to the user specified location will be displayed in the 'My Backup Bills' tab in the desktop application on the user's computer. Additionally, the biller logo, biller name, account number, downloaded date, and other information may also be displayed. The user will be able to open the file by clicking on the file name link located on the My Bills page.

An Alerts Engine may be configured as a separate component which may automatically start on system boot. An icon may be displayed in, for example, the system tray. When the user 110 double clicks the icon, the user 110 will be prompted to login into the application. In some embodiments, alerts may be displayed to users irrespective of whether the user has run the application or not. However, if the user exits the application from the system tray, the Alerts engine will be disabled. All data required for displaying alerts may be stored in the local database 220, 320. Connection to the online server 20 is not required. An alert log may be maintained in the application for users to see previous alerts.

The generated alerts may take various forms. By way of example and not limitation, the alerts may include: a new bill downloaded to the client by the service provider, an inactive biller alert that prompts a user if he has not subscribed to a particular service.

The user may deactivate the alert for each service by clicking 'I am not using this service' in the application in the Services Zone page. The alert may be displayed in the service provider online screen which is displayed in the Comp B application. Database syncing should be accomplished at least once per day to identify when to deactivate the alert. An alert may also be generated when a new biller 60 is added by the service provider. Other alerts may be generated when the due date to pay a bill approaches. In some embodiments, the time period prior to bill payment may be set by the user for alert generation. Other alerts may be generated, for example, when a user has installed the Component B 200 application to their desktop 210, but has not yet signed up with the service provider. It is understood that many other types of alerts may also be generated.

Figure 7 provides a flow chart illustrating one exemplary method, designated generally with reference numeral 600, of implementing the system 10 of Figure 1 , using Components A 100, B 200, and C 300 shown in Figures 2-4. The operation of the system 10 will now be discussed in detail with reference to Figures 1-6. In the discussion which follows, the term "service provider" will be used to refer to the administrator of the system 10.

The method 600 begins with the user 110 visiting the website of the service provider, as shown with reference numeral 602. The server 20 of the system 10 established by the service provider will prompt the user 110 to log on to an existing account. If the user 1 10 has previously registered with the service provider to access the system 10, the user 110 will be directed to a user logon page, as shown with reference numeral 640. If the user 110 has forgotten the password to the user account, the system 10 will implement a forgotten password protocol, as designated with reference numeral 604. By way of example and not limitation, the user 110 may be directed to a "forgot password page". The user 110 may be prompted to provide his email address and a code from a captured image page. The system 10 may then generate, for example, a 5 character length alpha numeric password and email the same to the user 110.

If the user 110 has not previously registered with the server 20 to use the system 10, the user 110 will be directed to a user registration page, as shown with reference numeral 606. The system 10 will prompt the user 110 to provide various information required to begin using the various services provided. By way of example, the user 110 may be prompted to provide a full name, address, user identification, valid email address, billing information, such as a credit card number, and other information that may be required to implement the various services provided. In some embodiments, the service provider provides the service to the user 110 for free, and may receive compensation from the billers 60. In these embodiments, the billers 60 may provide banner ads or other information that appears on the user's computer screen (see Figure 10).

Optionally, once an account has been set up for the user 110 according the criteria established by the service provider, an email may be sent to the user email inbox provided during the registration process for authentication purposes, as shown with reference numeral 610. The user 110 would then have to click the link provided in the email to complete the registration process, by activating the user ID and password previously provided, as shown with reference numeral 612. In some embodiments, the user 110 will be prompted to change the password provided to a user unique password at the first login.

The user 110 may then be directed to a download page, as shown with reference numeral 614. The user 110 may have access to the "How to Get started" page shown in the user guide 630. At this point, the user 110 has the option of downloading software to implement Components B 200 and C 300 of the system 10 illustrated in Figures 3-4.

For the purposes of the present discussion, it is sufficient that the user 110 choose either Component B 200 or Component C 300 for download, as shown with reference numeral 616. At this point, the system 10 will perform a verification of the operating system of the user 110, as shown with reference numeral 620. It is understood that embodiments of the present invention may be implemented using any operating system presently available. By way of example and not limitation, the operating system could be any one of the current versions of the Microsoft Windows® operating system, the MAC® operating system provided by Apple Macintosh®, the UNIX operating system, etc. Installation of the appropriate software is then commenced, as shown with reference numeral 622.

Once installed, the application software provided on the user's computer will activate, and prompt the user 110 to log on to the local account kept on the user's computer, as shown with reference numeral 624. Depending on whether Component B 200 or Component C 300 was installed on the user system, the user 110 will .then have access to various services provided, as shown with reference numeral 626. Once logged on, either at step 626 or at step 640, the user 110 also then has access to the complete User Guide, as shown with reference numeral 630.

The User Guide provides information about the program, various web pages that may appear as part of the program, and various user settable options. By way of example and not limitation, the user of Components A 100 and B 200 may have access to a Summary Page 642, a My Bills page 644, a My Green Credit page 646, a Payment History page 648, a Reports page 650, a Service Zone page 654, a Refer a Friend page 656, a Frequently Asked Questions page 660, a Forum page 662, a Feedback and Support page 664, and a user Backup Bills page 670. Similarly, the user of Component C 300 may have access to a My Bills page 680, a Service Zone page 682, and a Summary page 684. The various functions of these pages will be detailed below. It is understood that these pages are provided by way of example only. Many other types of pages, screens, etc. may also be provided without departing from the scope of the embodiments of the present invention.

One example of a Summary Page 642 is shown in Figure 8. The Summary Page 642 may include aggregated information for the user 110. By way of example and not limitation, this information may include biller account number(s), number of printed pages saved, current statement dates, bill due dates, etc.

One example of a My Bills page 644 that may be used with Components A 100 and B 200 is shown in Figure 9. One example of a My Bills Page 244 that may be used with Component C 300 is shown in Figure 10. The My Bills page 644 may include detailed information for all current bills. By way of example and not limitation, this information may include the Biller name, account number, download date, status, i.e paid or unpaid, etc. It is understood that other information may also be included.

The My Green Credit page 644 may provide the user 110 with a total of the number of printed pages that have been saved as a result of using the system 10. It may also include a calculation of the extra number of pages saved with respect to envelopes, etc.

The Payment History page 648 may include a complete list of all bills that have been downloaded for a biller. The Payment History page 648 may include the bill information for all bills in which the user 110 has made a payment, as well as payment information, including, but not limited to, the payment transaction status, payment date, etc. This information may be kept indefinitely, so that a user never need request back bills from a biller.

The Reports Page 650 may include various types of charts that present a graphical representation of the user's bills over a period of time. In some embodiments, this period may be 6 months, but other periods may also be used. The charts may present the information by biller, by month, etc. The reports may be presented in pie or bar charts, each showing the data for the last 6 months for each biller. Additionally, a link may also be provided on this page to view specific account reports. The user 1 10 may select a particular and account number, and view reports containing the specific information for the biller and account.

The Service Zone page 654 may include information on available billers not currently being used by the system 10. Additionally, this page 654 may include various preferences that may be set by the user 1 10. For example, a user 110 may choose to alter the due date alert frequency, by setting the number of days before the due date when the due date alert for each bill should be generated. The due date of each bill is captured for each bill during the parsing operation. The user 110 may also choose to have the service provider maintain a copy of the bills online, as well as on the user's local system. One example of a "New Bills" alert 692 that may be generated by the system 10 is shown in Figures 12A.

The user 110 may also change his password to the service provider via this page. If the user 110 changes his password, an HTTP request will be sent to the online database for updating. If the update request fails, the user 110 will be prompted with an error message, and the new password will not be made active. Users may also add/edit/delete accounts for each biller by providing login and other account credentials. Required login credentials will be based on the requirements as established by the billers. This information may then be stored both on the local computer and in the database 40 of the system 10. In some embodiments, the login details for each user 110 may be stored in an encrypted form using, by way of example and not limitation, a base64 encoding methodology.

The Service Zone page 654 may also allow a user to add/delete accounts, change an existing account, or set a biller 60 status to "Not Using". Setting a biller 60 status to "Not Using" will disable the alerts to the user 110. One example of such an alert 694 is shown in Figure 12B. It is understood that other user selectable options may also be included on this page.

The Refer a Friend page 656 allows a user 110 to provide information to the service provider with respect to potential additional users. The service provider may then contact the potential users based on the information provided. The FAQ page 660 provides answers to routine user questions. The forum page 662 provides user access to technical support personnel, or other users, to discuss various aspects of the system 10. Similarly, the Feedback/Support page 664 allows the user 110 to contact support personnel at the service provider should any type of problem arise with the system.

The My Backup Bills page 670 maintains copies of all downloaded secured documents on the user's local system. When using Components A 100 and B 200, these copies are provided automatically from the server 20 to the user's system 210, 310 when the user 110 logs on. The user 1 10 then has access to previously downloaded information without having to connect to the internet 50.

When using Component B 200, one or more of the pages 642, 644, 646, 648, 650, and 654 may be downloaded from the server 20 based, for example, on a HTTP request from the client software running on computer 210 to the server software running on the server 20.

When a user selects installation of Component C 300, as shown in Figure 4, a truncated version of the above information is maintained by the user system 310. The My Bills page 680, Service Zone page 682, and Summary page 684 will contain essentially the same information as described above. Additionally, banner pages may be provided on the various pages displayed to the user 110. Figure 11 illustrates one example of a banner 690 that may be displayed.

Some portions of the description of the system 10 provided above are explicitly or implicitly presented in terms of algorithms, flow charts, engines, and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as

"scanning", "inputting", "calculating", "determining", "replacing", "generating", "initializing",

"outputting", or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.

The present specification also discloses apparatus for performing the operations of the methods. Such apparatus may be specially constructed for the required purposes, or may comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. . Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate. The structure of a conventional general purpose computer will appear from the description below.

In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention. Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus that implements the steps of the preferred method.

The invention may also be implemented as hardware modules. More particularly, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). Numerous other possibilities exist. Those skilled in the art will appreciate that the system can also be implemented as a combination of hardware and software modules.

The method and system of the example embodiment can be implemented on a computer system 700, schematically shown in Figure 13. It may be implemented as software, such as a computer program being executed within the computer system 700, and instructing the computer system 700 to conduct the method of the example embodiment.

The computer system 700 can include a computer module 702, input modules such as a keyboard 704 and mouse 706 and a plurality of output devices such as a display 708, and printer 710.

The computer module 702 can be connected to a computer network 712 via a suitable transceiver device 714, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN). The computer module 702 in the example includes a processor 718, a Random Access Memory (RAM) 720 and a Read Only Memory (ROM) 722. The computer module 702 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 724 to the display 708, and I/O interface 726 to the keyboard 704. The components of the computer module 702 typically communicate via an interconnected bus 728 and in a manner known to the person skilled in the relevant art.

The application program can be supplied to the user of the computer system 700 encoded on a data storage medium such as a CD-ROM or flash memory carrier and read utilizing a corresponding data storage medium drive of a data storage device 730. The application program is read and controlled in its execution by the processor 718. Intermediate storage of program data maybe accomplished using RAM 720.

Embodiments of the present system and method provide several advantages over the prior art. The system and method provide the capability to securely retrieve biller documents for a user over the internet from a plurality of biller sites, aggregate that information for the user, and provide the aggregated information to the user to assist in paying the bills. Copies of the secure documents may be stored on the service provider system, on the user system, or both. The system provides the user with the flexibility to use either a web-based application, a thin client application, or an application residing entirely on the user's system.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.