CA2518263A1 - Electronic bill presentation and payment system - Google Patents
Electronic bill presentation and payment system Download PDFInfo
- Publication number
- CA2518263A1 CA2518263A1 CA002518263A CA2518263A CA2518263A1 CA 2518263 A1 CA2518263 A1 CA 2518263A1 CA 002518263 A CA002518263 A CA 002518263A CA 2518263 A CA2518263 A CA 2518263A CA 2518263 A1 CA2518263 A1 CA 2518263A1
- Authority
- CA
- Canada
- Prior art keywords
- information
- billing
- user
- financial institution
- ebpp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
Abstract
An electronic bill presentation and payment (EBPP) system and a method to use the same with application both in the businesstoconsumer and businesstobusiness transactions. The system enables a user of the system to specify a preferred financial institution for paying the consumer bills, and particular biller with which the user consumer does business, allowing both to be accessible on a single Web site. The information regarding the consumer's finances and the consumer's purchases from particular billers need not be shared between the financial institution and the billing company, thus providing improved security and consumer privacy. The look and feel of a singular presentation of financial institution information, biller information, and presenter information on a single page is provided by an advantageous use of Flash X technology which permits the presentation of information from the processor's centralized data base of acquired data from the servers of both the financial institution and billing companies through extraction, transforming and loading (ETL) techniques.
Description
ELECTRONIC BILL PRESENTATION AND PAYMENT SYSTEM
FIELD OF INVENTION
[0001] The present invention is directed toward an electronic bill presentation and payment system and, more particularly, to an electronic bill presentation and payment system in which a payer has access to one or more financial institutions information and one or more billing companies information and billing data through a single Web site.
BACKGROUND OF INVENTION
FIELD OF INVENTION
[0001] The present invention is directed toward an electronic bill presentation and payment system and, more particularly, to an electronic bill presentation and payment system in which a payer has access to one or more financial institutions information and one or more billing companies information and billing data through a single Web site.
BACKGROUND OF INVENTION
[0002] Electronic bill presentation and payment ~~EBPP°7 has emerged as a strategic differentiator in highly competitive markets. Besides providing convenient access to billing information, electronic payment by customers saves them stationery and postage costs. The electronic environment also enables business partners to reduce the cost of processing paper bills and statements by making it easier t~ use electronic workflow processes. ~n addition, electronic billing impr~ves cash flow by increasing the speed and accuracy of payments for goods and services between organizations. Furthermore, electronic billing information and data through a single Web site allows billing companies and banks to improve and enhance their relationship to their customers.
[0003] There are presently four primary models for implementing EBPP:
the billing company direct model; desktop consolidator model; thick consolidator model, and thin consolidator model. The billing company direct model supports a single billing company's EBPP requirements. This approach increases the billing company's control of the entire process, enables the billing company to customize the Web experience for consumers, and provides complete control over marketing messages. A disadvantage of the direct model is it is not easy to navigate and it does not provide a convenient mechanism for consumers to view statements and pay bills for multiple billing companies.
Page 1 of 22 _~ CA 02518263 2005-09-06 [0004] The desktop consolidator model aims to combine the benefits of bill consolidation for customers and consumer interaction for billing companies. This model may be implemented through Web browsers, email, or proprietary PC
software. Consumer acceptance of this model, however, has been limited because of the need to install additional software on client computers.
the billing company direct model; desktop consolidator model; thick consolidator model, and thin consolidator model. The billing company direct model supports a single billing company's EBPP requirements. This approach increases the billing company's control of the entire process, enables the billing company to customize the Web experience for consumers, and provides complete control over marketing messages. A disadvantage of the direct model is it is not easy to navigate and it does not provide a convenient mechanism for consumers to view statements and pay bills for multiple billing companies.
Page 1 of 22 _~ CA 02518263 2005-09-06 [0004] The desktop consolidator model aims to combine the benefits of bill consolidation for customers and consumer interaction for billing companies. This model may be implemented through Web browsers, email, or proprietary PC
software. Consumer acceptance of this model, however, has been limited because of the need to install additional software on client computers.
[0005] Using the thick consolidator model a consumer receives all statement and billing details in both summaries and detailed formats. The presentation is integrated with a bill payment process and the consumer relationship is managed at the consolidator Web site. Using the thin consolidator model a consumer receives a summary statement and billing information for a number of different billing companies. This model can be integrated with a bill payment process to authorize payments. A disadvantage of both the current thick and thin consolidator models is that to view a statement or billing detail, consumers must click a link to the originating billing company's Web site and are either redirected to the originating billing company's Web site or the billing details is ~~screen scraped" back to the consolidator site or the originating billing company's information is scanned from its printed for republication on the consolidator site.
[~0~~] There is a need for an EBPP system that does not have the limitations of the prior art systems. That is, there is a need for an EBPP
system that supports a consolidator model that does not require payers to link with billing companies' Web sites for paying bills or screen scraping billing details back to a consolidator site, as disclosed below in the embodiments of the present invention.
SUMMAltlf ~F INVENTI~N
[0007] The present invention discloses a unique EBPP system which consolidates in a centralized data base, informational data acquired from the servers of financial institutions and billing companies through extraction, transforming and loading ('~ELT'7 techniques, and which, at the same time, allows the users of the system to communicate with their financial institutions and billing companies in a manner such that information regarding the users' finances and the users' purchases from particular billers need not be shared between the financial institutions and the billing companies. One aspect of an embodiment of the present invention provides Page 2 of 22 improved security for both the financial institutions and billing companies as well as the user consumer's data and improved consumerdesired privacy. Such segregation capability further provides financial institutions and billing companies the ability to increase their interaction with and access to their consumers while maintaining a more exacting control over their consumer relationships.
[0008] In another aspect of an embodiment, the EBPP of the present invention enables a consumer to specify a preferred financial institution for paying the consumer bills, and particular billers with which the consumer does business, allowing both to be accessible on single Web site. In another aspect, the EBPP
system of the present invention enables the financial institution and billing company to present targeted product and/or services promotional material outside of that necessary for consummating the desired bill payment transaction. The look and feel of a singular presentation of financial institution information, biller information, and presenter information on a single page is provided by an advantageous use of Flash X technology which permits the presentation of information from the processor's centralised data base of acquired data from the servers of both the financial institution and billing c~mpanies through extraction, transforming and loading (ETL) techniques.
[~~~~] f~lore specifically, an embodiment of the present invention involves a system for electronic bill presentation and payment ("EBPP'7. The system comprises a memory for storing Web pages for an EBPP Web site, and a processor in communication with the memory. The processor operates to receive an EBPP user interface ("UI'~ from an EBPP host. The UI is configured to display financial institution information in a first portion of the UI, billing party information in a second portion, and billing data information in a third portion of the UI. The processor receives the financial institution information for display in the first portion of the UI, and transmits a request for the billing party information and billing data.
The processor then receives the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI. The system transmits instructions to the EBPP host to pay one or more bills of the billing party, and subsequently, relays payment information to the billing company.
Page 3 of 22 [0010] Another embodiment of the present invention discloses a method for utilizing an electronic bill presentation and payment ("EBPP") system. The method involves receiving an EBPP user interface ~~UI'~ from an EBPP host. The UI is configured to display financial institution information in a first portion of the UI, billing party information in a second portion of the UI, and display billing data information in a third portion of the UI. The system receives the financial institution information for display in the first portion of the UI, and transmits a request for the billing party information and billing data information. The system receives the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI.
The system then transmits instructions to the EBPP host to pay one or more bills of the billing party. The method further involves relaying the payment information back to the billing company or bank.
BRIEF DESCRIPTION ~F DRAWINGS
[~~~,~.] ~4 more complete appreciation of the invention and the advantages thereof will be more readily apparent by reference to the detailed description ~f the preferred embodiments when considered in c~nnection with the accompanying figures, wherein:
[0012] Fig. 1 is an overview of an exemplary system for implementing the present invention;
[00~,~] Fig ~ is a general flow chart of an exemplary method of the present invention;
[0014] Fig. .3 is a detailed flow chart of an exemplary method of the present invention;
[OOiS] Fig, 4 is a detailed flow chart, extending from Fig, .3, of an exemplary method of the present invention;
[0016] Figs Sa-Sb are exemplary screen shots of screens viewed by a user prior to logging onto a system of the present invention;
[0017] Figs 6a-66 are exemplary screen shots of an opening screen viewed by a user after logging onto the system;
Page 4 of 22 ' CA 02518263 2005-09-06 [0018] Figs 7a-7d are exemplary screen shots of a "view statements"
screen;
[0019] Fig. 8 is an exemplary screen shot of a "move funds" screen;
[0020] Figs 9a-9c are exemplary screen shots of a "pay bills" screen, wherein a user may view all paid bills, bills to pay, and scheduled;
[0021] Figs. IOa-IOb are exemplary screen shots of a "pay bills" screen, wherein a user may transfer funds into an account determined to have deficient funds; and [0022] Fig. 11 is an exemplary screen shot of a "pay bills" screen, wherein a user accesses information and billing data from a particular billing company's Web site.
[0023] In the figures, offpage references are used to refer the reader to figures that continue on another drawing page. The references include two parts: an offpage reference letter and a figure number in which the figure continues or from which the figure is continued. An example of an offpage reference is "A/4", where ee~ee is the ofFpage reference letter and 9~ is the drawing page on which the figure c~"o'intinues or from which the figure is continued.
[0024] All product, service, or company trade names mentioned herein or shown in the Figures are used only to facilitate descriptions of preferred embodiments of the present invention and are the property of their respective owners. Use of the trade names is not intended to express any owner's endorsement of the present invention.
DET~4ILED DESCRIPTI~N
[0025] The inventors have developed a system that includes a consolidator interface technology that provides seamless, transparent, comprehensive, secure and easy to use solution for electronic bill presentation and payment ("EBPP'~. Payers that use the disclosed EBPP system will have a central location where they may receive and analyze all of their electronically presented bills, invoices, and statements, and have payments made to billing companies via the payers preferred financial institution.
Page 5 of 22 [0026] The system allows individual financial institutions the ability to private label their own consolidator application enabling them to maintain control over their consumer relationships without the consumer knowing they are utilizing the system. Furthermore, the system offers billing companies (described alternatively as "billers" herein) the same control over their bill and pay transactions as if the EBPP system was running on their own premises. With tight integration to both sides of the buy/sell transaction, the system allows billers and payers to control as much of the process as they desire.
[0027] The EBPP system includes business-to-business ("B2B'~
components and business-to-consumer ("B2C'~ components; however, general operation of the system is common to both businesses and consumers. As disclosed in more detail herein below, the system is automatically configured when the user (the term "payer" is used interchangeably with the term "user'7, be it a business or a consumer, logs into the system.
[0028] Referring to Fig. 1, there is shown an overview of an exemplary system 100 for implementing the present invention. The system ~1~~ may include a server ~.~5, which may be the server of an EBPP host that provides EBPP
services to business and consumer system users. The server x.05 includes a storage medium 1~.~ that may store financial institution data 112, biller data ig~., payer data g15, business rules 118, and EBPP Web pages 120. The server 105 may be in communication with other servers 1015~ (representing one ~r more servers) via a network z3~ such as an intranet or the Tnternet. Such servers ~.a.0~,50 may be those of financial institutions and billers. The computer system 100 further includes client computers 160170 (representing one or more client computers) in communication with the server 105 via the network 130. Those of ordinary skill in the art will appreciate the various types of computers and configurations that the computers and the system may employ to facilitate embodiments of the present the invention.
[0029] Referring to Fig, 2, there is shown a general flow chart 200 of an exemplary method of the present invention. At step 210 of the exemplary method a user accesses an EBPP Web site configured in accordance with the present invention as described in more detail herein below. Generally, a screen is displayed to the user Page 6 of 22 ' CA 02518263 2005-09-06 that includes identification information of a financial institution previously designated by the user, biller, and a central ledger area. At step 220, the user may select a biller by clicking the biller's link, at which time outstanding bills are presented to the user for payment. From the user's point of view it appears that he is accessing the billers Web site for paying bills. At step 230, the user conducts a transaction with the selected biller by, for example, selecting a bill to be paid and confirming the payment transaction. Various other functions and attributes may be provided by the present invention as described in more detail herein below.
[0030] It is notable that although the term °'financial institution"
account is used herein, any type account may be used by a payer to pay bills.
[0031] Referring to Fig. 3, there is shown a flow diagram 300 for describing the operation of the system of the present invention. Reference will be made to the screen shots shown in Figs 511 to facilitate in a better understanding of the invention.
[0032] At step 301, initially a user may gain access to the site by entering the uniform record locator (°°URL'7 of the E6PP systems Web site into their web browser. A screen such as welcome screen 5~~ shown in Fig S~ may be displayed inviting the user to sign up f~r the EEPP service. The welcome screen ~~~
may include a °'ready to sign up" button 502 and a login button 50~ for gaining access to the system. The user may also choose take a tour 506 to get a preview of the system offerings. The welcome screen 500 may also include a rewards °'thermometer~' S~~, which, once the user has logged onto the system and the user's account information has been retrieved, indicates the amount of rewards points the user has accumulated by carrying out various activities in the system (e.g., pay a bill). For the user's convenience, the rewards ''thermometer" may be included in every screen viewed by the user. ~nce the user clicks on the ''log in'°
button, the user is presented by a secure login box 510 shown in Fig. fib.
[0033] It is notable that the system may employ multiple security gates including, for example, a software password request (a middleware gate), a physical firewall, stored encryption at the database level, operating system gates (e.g., timeouts), dragons, and third party vendor review/testing (e.g., RipTech).
Page 7 of 22 [0034] If the user had not previously signed up then he would click on the "ready to sign up" button 502 and follow the instructions for obtaining a password. The user would provide the system such information as the user's frill name, email address, user name, and a bank account profile (e.g., bank account name, type, customer number). Thereafter, the user would receive an email identifying a password. Once the user receives a password then the user will click on the login button 504 and enter the user's user name and password. At step 302, the system authenticates the user's user name and password.
[0035] If the user signs on through his financial institution, such as a bank, the sign on information appears to be on the bank site. In actuality, the user clicks on the bank icon that brings up the EPBB system application, which in turn presents to the user a page fully branded as the lookalike bank site.
[0036] At step 304, a main screen such as the main screen 600 shown in Fig. 6a is displayed. It is notable that the main screen 600 and subsequent screens received by the user are tailored to the particular user logged onto the system. For example, the financial institution and billers that are displayed throughout any session are those previously identified by the particular user logged on. Furthermore, prod~act/service offerings by the financial institution may be tailored t~ the user based on the user's economic profile and produet/serviee offerings by billers may be tailored to the user based on the user's prior purchasing habits across all billing companies and bank transactions.
[~~3~] The upper portion 6~2 of the main screen 6~~ includes identification indicia (e.g., branding information, marketing promotions, links, messages) of the user's preferred financial institution, the lefthand portion includes scrollable biller icons, and central portion 606 of the main screen may include various user functions and information related thereto headed by tab buttons entitled °'accounts" 608, "pay bills°' 610, "view statements"
612, and "move funds"
614. The main screen 600 also indicates when the user had his last transaction (e.g., Friday, January 30th), identifies how many bills are scheduled for payment this week, and indicates the number of member points the user earned. The main screen 600 also includes a rewards "thermometer" 616, which shows the number of member points the user earned. An online help button 618 is always available.
Page 8 of 22 Each one of the tab buttons shown in Fig. 6a are expandable with a click of the button to provide more explanation for the corresponding button, as referenced in general with numeral 620 in Fig, 66.
[0038] Those of ordinary skill in the art will appreciate that the Web's request and response model is inherently illsuited for realtime data updating because hyper t ext markup language ('~HTML'~ pages have to reload in full every time a browser checks for new data on a server. To overcome this inherent disadvantage, the inventors make use of Flash MX, an Internet content and applications development tool by Macromedia, Inc. (San Francisco, CA). As a consequence, for example, with Flash MX, and other Macromedia platforms, the user interface shown in Fig. 11 may be configured to include a shell (e.g., the ClickandPay Central screen) into which is integrated in the upper portion of the screen 1102 (the branding skin area) Web data provided and controlled by a financial institution, and integrated into the lefthand and central portion of the screen 1104 Web data provided and controlled by a biller. The host provider information (e.g., ClickandPay Central information) is dimmed in order to accentuate the default financial institution (e.g., Prey Eank). All attributes (described herein below) regarding the sell sheet area are applicable to the skin area. The central portion, or ledger area, includes a hot zone in which all interactivity takes place. For example, if a user is to perform an action or task he may utilize buttons, fields, pulldown menus and other capabilities available in the hot zone.
[~~3~] That is, each portion of the screen is basically a snapshot of the financial institution and biller's screen portions. To the user, the lJI has the look and feel of a singular presentation of information and data entry points. However, Flash MX facilitates the presentation of information fr~m the processor's centralized data base of acquired data from the servers of both the financial institution and billing companies through extraction, transforming and loading (ETL) techniques. The acquisition of data in realtime or through transfer of files, from the two respective servers as needed, thereby significantly reduces acquisition interruptions as perceived by the user and eliminating timeout interruptions by the financial institution and biller's servers. An additional advantage is improved security o f the user's data and improved protection of the user's privacy. A significant strength of Page 9 of 22 Flash MX is its ability to interact with the greatest number of middleware solutions, data bases, and data pipelines of any middleware for Web solutions.
[0040] Print stream vendors may be utilized to facilitate creating data pipelines to make legacy data available to the system. Dreamweaver MX, also by Macromedia, Inc., may be used for management of the Web site.
[0041] It is notable that a user can go directly from the hot zone reviewing bills that are to be paid to an active pay bills screen, as described in more detail herein below. The lefthand portion of the screen, also referred to as the "sell sheet," allows a biller to, for example: take care of important customer business (e.g., announce service or fee changes); provide timely information about products/services (e.g., announce seasonal sales, enhancements to existing products/services; new services); provide interactivity (e.g., quiz, games, short videos) that is directed to a particular marketing strategy (and not just a static ad).
The above functionality is made possible utilizing Flash MX and cannot be accomplished using standard HTML. The sell sheets are expandable into what appears to the user consumer as the biller's "Direct" site. The system also enables the user to easily navigate back to paying bills from a financial institution, or from other services provided by this full "financial wallet°' that allows the consumer to receive and interact with all available financial information from one screen.
[0042] Further examples of "sell sheet" capabilities include: rotating ads;
push/pull ads (e.g., content can be stored on biller end if the biller is to push the ads, alternatively, content can be stored on the EEPP system provider end);
biller can set timers for ad delivery; can provide scrolling ads (e.g., text, video, artwork) including large amounts of information in a scrolling format.
[0043] At step 306, the user is prompted as to whether the he wants to view his one or more accounts. If the user desires to view his one or more accounts he may select the "accounts" button 608 and thereby proceed to step 308. At step 308 the user may view each account's profile. After the user is done reviewing his accounts at step 308, the user proceeds to step 310. If, at step 306 the user does not desire to view his accounts, then the user may proceed directly to step 310.
[0044] At step 310, the user is prompted as to whether he wants to view his one or more statements. If the user desires to view his one or more Page 10 of 22 ' CA 02518263 2005-09-06 statements he may select the "view statements" button 612 and thereby proceed to step 312. At step 312, a statement screen such as statement screen 700 and 750, shown in Figs 7a and 76, respectively, is displayed. Statement screen 700 may include the name and the user's account number with various providers. The providers may include banks, brokerage firms, travel companies (e.g., airlines, hotels, car rental companies), etc. Buttons may be provided to separately access the statements of "banks" 702, "brokerage" firms 704, "travel/rewards" 706, "credit cards" 708, or "bills" 710. In statement screen 700, the "travel/rewards"
button 706 was clicked so all such travel/rewards are shown. An example of "banks"
view statement 760 is shown Fig. 7c, while screen 770 shows "brokerage" statement in Fig, 7d.
[0045] ~y clicking on a provider's name or icon, the user can open the statement for that particular provider. ~nce a user has selected a provider, a screen (not shown) is displayed showing the user's statement from that provider and allowing the user to perform certain transactions. For example, in a display screen showing a user's bank statement the user may transfer funds; in a display screen showing a user°s airline travel rewards statement the user may apply travel rewards t~ an airline ticket; in a display screen showing a user's brokerage statement the user may transfer funds from a brokerage savings account to an investment in particular stock. After the user is done reviewing his statements at step 312, the user proceeds to step 314. It at step 310 the user does not desire to view his statements, then the user may proceed directly to step 3~.~.
[00~s~] At step 314, the user is prompted as to whether he desires to move funds from one account to another account. Tf the user desires to move funds he may select the "move funds" button f 14 and thereby proceed to step 31f .
At step 3lfa, a move funds screen such as move funds screen 800 shown in Fig, 8 is displayed. The move funds screen 800 may enable the user to check account balances of his various accounts and move funds between such accounts. After the user is done moving funds at step 316, the user proceeds to step 318. It at step 314 the user does not desire to move funds, then the user may proceed directly to step 318.
Page 11 of 22 [0047] At step 3i8, the user is prompted as to whether he desires to view and pay bills. If the user desires to view and pay bills he may select the "pay bills" button 610 and thereby proceed to step 402 of flow diagram 400 shown in Fig, 4. At step 402, a default screen such as the default screen 900 shown in Fig. 9 is displayed. There are generally three steps to take when paying a bill.
First, the user selects a biller that is to be paid. Second, the user selects a bill that is to be.
And third, the user pays the selected bill. The system enables the user to carry out the three general steps in a variety of ways, thereby providing maximum flexibility to the user.
[0048] More particularly, for example, a user may view bill statements and select one or more related bills for payment, a user may view the status of bills to be paid and select one or more bills for payment, a user may select a biller from the scrolling icons to pull up the sell sheet of the biller in the lefthand portion of the screen and select one or more bills thereafter from the center portion (ledger area) of the screen. Or, a user can select to open up the sell sheet to expose a full "Biller ~irect°' application and select one or more of the various biller products and services being offered the consumer from the one screen. It is notable that regardless of the method used to initiate the bill paying process, the sell sheet of the bill will pull up in the lefthand portion of the screen and will open up to a full screen application with one click by the user. Further details regarding the various bill payment initiation methods is described herein and/or shown in the accompanying figures. A
significant aspect of the invention is that a minimal number of screens are used for bill payment. That is, while prior art bill payment systems require users to use a minimum of five screens to pay a bill, the present invention basically requires only a single screen for bill payment. An exception to singlescreen payment with the present system is when the user's account has insufficient funds.
Consequently, this makes the EBPP system disclosed herein significantly more efficient and more user friendly than prior art systems.
[0049] The default screen 900 may immediately display "all new and unpaid bills", as shown in Fig. 9a, where "new bills" are bills that became available for viewing since the last time the user logged in, and "unpaid bills" are bills that the user has viewed already but are still unpaid. The default screen 900 may also display a "new bill" button 902, "schedules" button 904, "unpaid" bills button 906, Page 12 of 22 "history" button 908, and a "billers list" button 910, as shown in the same Figure.
Figure 9b shows all unpaid bills 912, if any. Under the "pay bills", status 914 of paid bills, bills to pay 916 and schedule 918 can also be shown, as seen in Fig. 9c.
By clicking on the "new bills" button 902 the central panel may display all new bills only. By clicking on the "schedules" button 904 the central panel may display all bills that are scheduled for payment. Fig. IOa shows an exemplary screen 1000 that may be displayed after a user clicks on "schedules" button 904. By clicking on the "unpaid" bills button 906 the central panel may display all unpaid bills only.
If there are insufficient funds in a particular account for paying an unpaid bill, then an error window 1010 appears as shown in Fig. IOb. Proper transfer 1020 may be made from one account to another, if available, to pay the bill. Otherwise, the transaction can be cancelled by clicking button 1030, as shown in the same Figure. By clicking on the "history" button 908 in Fig. 6a, the central panel may display all past bills that have been paid. Conveniently, past bills are retained in the system for a period of time (e.g., one year) to enable the user to compare bills over such time period. By clicking on the "billers list" button 910 the lower panel may display all billers and their data. Options may be provided for adding billers, deleting billers, and editing biller information. The default screen may alternatively be as shown in Fig:
[~0~~] There is a need for an EBPP system that does not have the limitations of the prior art systems. That is, there is a need for an EBPP
system that supports a consolidator model that does not require payers to link with billing companies' Web sites for paying bills or screen scraping billing details back to a consolidator site, as disclosed below in the embodiments of the present invention.
SUMMAltlf ~F INVENTI~N
[0007] The present invention discloses a unique EBPP system which consolidates in a centralized data base, informational data acquired from the servers of financial institutions and billing companies through extraction, transforming and loading ('~ELT'7 techniques, and which, at the same time, allows the users of the system to communicate with their financial institutions and billing companies in a manner such that information regarding the users' finances and the users' purchases from particular billers need not be shared between the financial institutions and the billing companies. One aspect of an embodiment of the present invention provides Page 2 of 22 improved security for both the financial institutions and billing companies as well as the user consumer's data and improved consumerdesired privacy. Such segregation capability further provides financial institutions and billing companies the ability to increase their interaction with and access to their consumers while maintaining a more exacting control over their consumer relationships.
[0008] In another aspect of an embodiment, the EBPP of the present invention enables a consumer to specify a preferred financial institution for paying the consumer bills, and particular billers with which the consumer does business, allowing both to be accessible on single Web site. In another aspect, the EBPP
system of the present invention enables the financial institution and billing company to present targeted product and/or services promotional material outside of that necessary for consummating the desired bill payment transaction. The look and feel of a singular presentation of financial institution information, biller information, and presenter information on a single page is provided by an advantageous use of Flash X technology which permits the presentation of information from the processor's centralised data base of acquired data from the servers of both the financial institution and billing c~mpanies through extraction, transforming and loading (ETL) techniques.
[~~~~] f~lore specifically, an embodiment of the present invention involves a system for electronic bill presentation and payment ("EBPP'7. The system comprises a memory for storing Web pages for an EBPP Web site, and a processor in communication with the memory. The processor operates to receive an EBPP user interface ("UI'~ from an EBPP host. The UI is configured to display financial institution information in a first portion of the UI, billing party information in a second portion, and billing data information in a third portion of the UI. The processor receives the financial institution information for display in the first portion of the UI, and transmits a request for the billing party information and billing data.
The processor then receives the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI. The system transmits instructions to the EBPP host to pay one or more bills of the billing party, and subsequently, relays payment information to the billing company.
Page 3 of 22 [0010] Another embodiment of the present invention discloses a method for utilizing an electronic bill presentation and payment ("EBPP") system. The method involves receiving an EBPP user interface ~~UI'~ from an EBPP host. The UI is configured to display financial institution information in a first portion of the UI, billing party information in a second portion of the UI, and display billing data information in a third portion of the UI. The system receives the financial institution information for display in the first portion of the UI, and transmits a request for the billing party information and billing data information. The system receives the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI.
The system then transmits instructions to the EBPP host to pay one or more bills of the billing party. The method further involves relaying the payment information back to the billing company or bank.
BRIEF DESCRIPTION ~F DRAWINGS
[~~~,~.] ~4 more complete appreciation of the invention and the advantages thereof will be more readily apparent by reference to the detailed description ~f the preferred embodiments when considered in c~nnection with the accompanying figures, wherein:
[0012] Fig. 1 is an overview of an exemplary system for implementing the present invention;
[00~,~] Fig ~ is a general flow chart of an exemplary method of the present invention;
[0014] Fig. .3 is a detailed flow chart of an exemplary method of the present invention;
[OOiS] Fig, 4 is a detailed flow chart, extending from Fig, .3, of an exemplary method of the present invention;
[0016] Figs Sa-Sb are exemplary screen shots of screens viewed by a user prior to logging onto a system of the present invention;
[0017] Figs 6a-66 are exemplary screen shots of an opening screen viewed by a user after logging onto the system;
Page 4 of 22 ' CA 02518263 2005-09-06 [0018] Figs 7a-7d are exemplary screen shots of a "view statements"
screen;
[0019] Fig. 8 is an exemplary screen shot of a "move funds" screen;
[0020] Figs 9a-9c are exemplary screen shots of a "pay bills" screen, wherein a user may view all paid bills, bills to pay, and scheduled;
[0021] Figs. IOa-IOb are exemplary screen shots of a "pay bills" screen, wherein a user may transfer funds into an account determined to have deficient funds; and [0022] Fig. 11 is an exemplary screen shot of a "pay bills" screen, wherein a user accesses information and billing data from a particular billing company's Web site.
[0023] In the figures, offpage references are used to refer the reader to figures that continue on another drawing page. The references include two parts: an offpage reference letter and a figure number in which the figure continues or from which the figure is continued. An example of an offpage reference is "A/4", where ee~ee is the ofFpage reference letter and 9~ is the drawing page on which the figure c~"o'intinues or from which the figure is continued.
[0024] All product, service, or company trade names mentioned herein or shown in the Figures are used only to facilitate descriptions of preferred embodiments of the present invention and are the property of their respective owners. Use of the trade names is not intended to express any owner's endorsement of the present invention.
DET~4ILED DESCRIPTI~N
[0025] The inventors have developed a system that includes a consolidator interface technology that provides seamless, transparent, comprehensive, secure and easy to use solution for electronic bill presentation and payment ("EBPP'~. Payers that use the disclosed EBPP system will have a central location where they may receive and analyze all of their electronically presented bills, invoices, and statements, and have payments made to billing companies via the payers preferred financial institution.
Page 5 of 22 [0026] The system allows individual financial institutions the ability to private label their own consolidator application enabling them to maintain control over their consumer relationships without the consumer knowing they are utilizing the system. Furthermore, the system offers billing companies (described alternatively as "billers" herein) the same control over their bill and pay transactions as if the EBPP system was running on their own premises. With tight integration to both sides of the buy/sell transaction, the system allows billers and payers to control as much of the process as they desire.
[0027] The EBPP system includes business-to-business ("B2B'~
components and business-to-consumer ("B2C'~ components; however, general operation of the system is common to both businesses and consumers. As disclosed in more detail herein below, the system is automatically configured when the user (the term "payer" is used interchangeably with the term "user'7, be it a business or a consumer, logs into the system.
[0028] Referring to Fig. 1, there is shown an overview of an exemplary system 100 for implementing the present invention. The system ~1~~ may include a server ~.~5, which may be the server of an EBPP host that provides EBPP
services to business and consumer system users. The server x.05 includes a storage medium 1~.~ that may store financial institution data 112, biller data ig~., payer data g15, business rules 118, and EBPP Web pages 120. The server 105 may be in communication with other servers 1015~ (representing one ~r more servers) via a network z3~ such as an intranet or the Tnternet. Such servers ~.a.0~,50 may be those of financial institutions and billers. The computer system 100 further includes client computers 160170 (representing one or more client computers) in communication with the server 105 via the network 130. Those of ordinary skill in the art will appreciate the various types of computers and configurations that the computers and the system may employ to facilitate embodiments of the present the invention.
[0029] Referring to Fig, 2, there is shown a general flow chart 200 of an exemplary method of the present invention. At step 210 of the exemplary method a user accesses an EBPP Web site configured in accordance with the present invention as described in more detail herein below. Generally, a screen is displayed to the user Page 6 of 22 ' CA 02518263 2005-09-06 that includes identification information of a financial institution previously designated by the user, biller, and a central ledger area. At step 220, the user may select a biller by clicking the biller's link, at which time outstanding bills are presented to the user for payment. From the user's point of view it appears that he is accessing the billers Web site for paying bills. At step 230, the user conducts a transaction with the selected biller by, for example, selecting a bill to be paid and confirming the payment transaction. Various other functions and attributes may be provided by the present invention as described in more detail herein below.
[0030] It is notable that although the term °'financial institution"
account is used herein, any type account may be used by a payer to pay bills.
[0031] Referring to Fig. 3, there is shown a flow diagram 300 for describing the operation of the system of the present invention. Reference will be made to the screen shots shown in Figs 511 to facilitate in a better understanding of the invention.
[0032] At step 301, initially a user may gain access to the site by entering the uniform record locator (°°URL'7 of the E6PP systems Web site into their web browser. A screen such as welcome screen 5~~ shown in Fig S~ may be displayed inviting the user to sign up f~r the EEPP service. The welcome screen ~~~
may include a °'ready to sign up" button 502 and a login button 50~ for gaining access to the system. The user may also choose take a tour 506 to get a preview of the system offerings. The welcome screen 500 may also include a rewards °'thermometer~' S~~, which, once the user has logged onto the system and the user's account information has been retrieved, indicates the amount of rewards points the user has accumulated by carrying out various activities in the system (e.g., pay a bill). For the user's convenience, the rewards ''thermometer" may be included in every screen viewed by the user. ~nce the user clicks on the ''log in'°
button, the user is presented by a secure login box 510 shown in Fig. fib.
[0033] It is notable that the system may employ multiple security gates including, for example, a software password request (a middleware gate), a physical firewall, stored encryption at the database level, operating system gates (e.g., timeouts), dragons, and third party vendor review/testing (e.g., RipTech).
Page 7 of 22 [0034] If the user had not previously signed up then he would click on the "ready to sign up" button 502 and follow the instructions for obtaining a password. The user would provide the system such information as the user's frill name, email address, user name, and a bank account profile (e.g., bank account name, type, customer number). Thereafter, the user would receive an email identifying a password. Once the user receives a password then the user will click on the login button 504 and enter the user's user name and password. At step 302, the system authenticates the user's user name and password.
[0035] If the user signs on through his financial institution, such as a bank, the sign on information appears to be on the bank site. In actuality, the user clicks on the bank icon that brings up the EPBB system application, which in turn presents to the user a page fully branded as the lookalike bank site.
[0036] At step 304, a main screen such as the main screen 600 shown in Fig. 6a is displayed. It is notable that the main screen 600 and subsequent screens received by the user are tailored to the particular user logged onto the system. For example, the financial institution and billers that are displayed throughout any session are those previously identified by the particular user logged on. Furthermore, prod~act/service offerings by the financial institution may be tailored t~ the user based on the user's economic profile and produet/serviee offerings by billers may be tailored to the user based on the user's prior purchasing habits across all billing companies and bank transactions.
[~~3~] The upper portion 6~2 of the main screen 6~~ includes identification indicia (e.g., branding information, marketing promotions, links, messages) of the user's preferred financial institution, the lefthand portion includes scrollable biller icons, and central portion 606 of the main screen may include various user functions and information related thereto headed by tab buttons entitled °'accounts" 608, "pay bills°' 610, "view statements"
612, and "move funds"
614. The main screen 600 also indicates when the user had his last transaction (e.g., Friday, January 30th), identifies how many bills are scheduled for payment this week, and indicates the number of member points the user earned. The main screen 600 also includes a rewards "thermometer" 616, which shows the number of member points the user earned. An online help button 618 is always available.
Page 8 of 22 Each one of the tab buttons shown in Fig. 6a are expandable with a click of the button to provide more explanation for the corresponding button, as referenced in general with numeral 620 in Fig, 66.
[0038] Those of ordinary skill in the art will appreciate that the Web's request and response model is inherently illsuited for realtime data updating because hyper t ext markup language ('~HTML'~ pages have to reload in full every time a browser checks for new data on a server. To overcome this inherent disadvantage, the inventors make use of Flash MX, an Internet content and applications development tool by Macromedia, Inc. (San Francisco, CA). As a consequence, for example, with Flash MX, and other Macromedia platforms, the user interface shown in Fig. 11 may be configured to include a shell (e.g., the ClickandPay Central screen) into which is integrated in the upper portion of the screen 1102 (the branding skin area) Web data provided and controlled by a financial institution, and integrated into the lefthand and central portion of the screen 1104 Web data provided and controlled by a biller. The host provider information (e.g., ClickandPay Central information) is dimmed in order to accentuate the default financial institution (e.g., Prey Eank). All attributes (described herein below) regarding the sell sheet area are applicable to the skin area. The central portion, or ledger area, includes a hot zone in which all interactivity takes place. For example, if a user is to perform an action or task he may utilize buttons, fields, pulldown menus and other capabilities available in the hot zone.
[~~3~] That is, each portion of the screen is basically a snapshot of the financial institution and biller's screen portions. To the user, the lJI has the look and feel of a singular presentation of information and data entry points. However, Flash MX facilitates the presentation of information fr~m the processor's centralized data base of acquired data from the servers of both the financial institution and billing companies through extraction, transforming and loading (ETL) techniques. The acquisition of data in realtime or through transfer of files, from the two respective servers as needed, thereby significantly reduces acquisition interruptions as perceived by the user and eliminating timeout interruptions by the financial institution and biller's servers. An additional advantage is improved security o f the user's data and improved protection of the user's privacy. A significant strength of Page 9 of 22 Flash MX is its ability to interact with the greatest number of middleware solutions, data bases, and data pipelines of any middleware for Web solutions.
[0040] Print stream vendors may be utilized to facilitate creating data pipelines to make legacy data available to the system. Dreamweaver MX, also by Macromedia, Inc., may be used for management of the Web site.
[0041] It is notable that a user can go directly from the hot zone reviewing bills that are to be paid to an active pay bills screen, as described in more detail herein below. The lefthand portion of the screen, also referred to as the "sell sheet," allows a biller to, for example: take care of important customer business (e.g., announce service or fee changes); provide timely information about products/services (e.g., announce seasonal sales, enhancements to existing products/services; new services); provide interactivity (e.g., quiz, games, short videos) that is directed to a particular marketing strategy (and not just a static ad).
The above functionality is made possible utilizing Flash MX and cannot be accomplished using standard HTML. The sell sheets are expandable into what appears to the user consumer as the biller's "Direct" site. The system also enables the user to easily navigate back to paying bills from a financial institution, or from other services provided by this full "financial wallet°' that allows the consumer to receive and interact with all available financial information from one screen.
[0042] Further examples of "sell sheet" capabilities include: rotating ads;
push/pull ads (e.g., content can be stored on biller end if the biller is to push the ads, alternatively, content can be stored on the EEPP system provider end);
biller can set timers for ad delivery; can provide scrolling ads (e.g., text, video, artwork) including large amounts of information in a scrolling format.
[0043] At step 306, the user is prompted as to whether the he wants to view his one or more accounts. If the user desires to view his one or more accounts he may select the "accounts" button 608 and thereby proceed to step 308. At step 308 the user may view each account's profile. After the user is done reviewing his accounts at step 308, the user proceeds to step 310. If, at step 306 the user does not desire to view his accounts, then the user may proceed directly to step 310.
[0044] At step 310, the user is prompted as to whether he wants to view his one or more statements. If the user desires to view his one or more Page 10 of 22 ' CA 02518263 2005-09-06 statements he may select the "view statements" button 612 and thereby proceed to step 312. At step 312, a statement screen such as statement screen 700 and 750, shown in Figs 7a and 76, respectively, is displayed. Statement screen 700 may include the name and the user's account number with various providers. The providers may include banks, brokerage firms, travel companies (e.g., airlines, hotels, car rental companies), etc. Buttons may be provided to separately access the statements of "banks" 702, "brokerage" firms 704, "travel/rewards" 706, "credit cards" 708, or "bills" 710. In statement screen 700, the "travel/rewards"
button 706 was clicked so all such travel/rewards are shown. An example of "banks"
view statement 760 is shown Fig. 7c, while screen 770 shows "brokerage" statement in Fig, 7d.
[0045] ~y clicking on a provider's name or icon, the user can open the statement for that particular provider. ~nce a user has selected a provider, a screen (not shown) is displayed showing the user's statement from that provider and allowing the user to perform certain transactions. For example, in a display screen showing a user's bank statement the user may transfer funds; in a display screen showing a user°s airline travel rewards statement the user may apply travel rewards t~ an airline ticket; in a display screen showing a user's brokerage statement the user may transfer funds from a brokerage savings account to an investment in particular stock. After the user is done reviewing his statements at step 312, the user proceeds to step 314. It at step 310 the user does not desire to view his statements, then the user may proceed directly to step 3~.~.
[00~s~] At step 314, the user is prompted as to whether he desires to move funds from one account to another account. Tf the user desires to move funds he may select the "move funds" button f 14 and thereby proceed to step 31f .
At step 3lfa, a move funds screen such as move funds screen 800 shown in Fig, 8 is displayed. The move funds screen 800 may enable the user to check account balances of his various accounts and move funds between such accounts. After the user is done moving funds at step 316, the user proceeds to step 318. It at step 314 the user does not desire to move funds, then the user may proceed directly to step 318.
Page 11 of 22 [0047] At step 3i8, the user is prompted as to whether he desires to view and pay bills. If the user desires to view and pay bills he may select the "pay bills" button 610 and thereby proceed to step 402 of flow diagram 400 shown in Fig, 4. At step 402, a default screen such as the default screen 900 shown in Fig. 9 is displayed. There are generally three steps to take when paying a bill.
First, the user selects a biller that is to be paid. Second, the user selects a bill that is to be.
And third, the user pays the selected bill. The system enables the user to carry out the three general steps in a variety of ways, thereby providing maximum flexibility to the user.
[0048] More particularly, for example, a user may view bill statements and select one or more related bills for payment, a user may view the status of bills to be paid and select one or more bills for payment, a user may select a biller from the scrolling icons to pull up the sell sheet of the biller in the lefthand portion of the screen and select one or more bills thereafter from the center portion (ledger area) of the screen. Or, a user can select to open up the sell sheet to expose a full "Biller ~irect°' application and select one or more of the various biller products and services being offered the consumer from the one screen. It is notable that regardless of the method used to initiate the bill paying process, the sell sheet of the bill will pull up in the lefthand portion of the screen and will open up to a full screen application with one click by the user. Further details regarding the various bill payment initiation methods is described herein and/or shown in the accompanying figures. A
significant aspect of the invention is that a minimal number of screens are used for bill payment. That is, while prior art bill payment systems require users to use a minimum of five screens to pay a bill, the present invention basically requires only a single screen for bill payment. An exception to singlescreen payment with the present system is when the user's account has insufficient funds.
Consequently, this makes the EBPP system disclosed herein significantly more efficient and more user friendly than prior art systems.
[0049] The default screen 900 may immediately display "all new and unpaid bills", as shown in Fig. 9a, where "new bills" are bills that became available for viewing since the last time the user logged in, and "unpaid bills" are bills that the user has viewed already but are still unpaid. The default screen 900 may also display a "new bill" button 902, "schedules" button 904, "unpaid" bills button 906, Page 12 of 22 "history" button 908, and a "billers list" button 910, as shown in the same Figure.
Figure 9b shows all unpaid bills 912, if any. Under the "pay bills", status 914 of paid bills, bills to pay 916 and schedule 918 can also be shown, as seen in Fig. 9c.
By clicking on the "new bills" button 902 the central panel may display all new bills only. By clicking on the "schedules" button 904 the central panel may display all bills that are scheduled for payment. Fig. IOa shows an exemplary screen 1000 that may be displayed after a user clicks on "schedules" button 904. By clicking on the "unpaid" bills button 906 the central panel may display all unpaid bills only.
If there are insufficient funds in a particular account for paying an unpaid bill, then an error window 1010 appears as shown in Fig. IOb. Proper transfer 1020 may be made from one account to another, if available, to pay the bill. Otherwise, the transaction can be cancelled by clicking button 1030, as shown in the same Figure. By clicking on the "history" button 908 in Fig. 6a, the central panel may display all past bills that have been paid. Conveniently, past bills are retained in the system for a period of time (e.g., one year) to enable the user to compare bills over such time period. By clicking on the "billers list" button 910 the lower panel may display all billers and their data. Options may be provided for adding billers, deleting billers, and editing biller information. The default screen may alternatively be as shown in Fig:
6'a, wherein the llot gone of the ledger is partitioned into three areas, 1.e., °°paid'° bills, "bills to pay,°' and "scheduled°' bills.
[0050] At step 404, the user selects a biller that is to be paid. As noted above, there are variety of ways a user may select a biller, and thereafter a bill to be paid. A user may click directly on the biller°s icon in the left hand panel. A scroll bar may be provided to access billers' icons that do not appear in the lefthand portion of the screen. If the user clicks on a biller's icon, the lefthand portion of the screen may display the selected biller's branding, marketing messages, links, messages, and a login message. Fig. 11 shows an exemplary screen 1100 that may be displayed after a user clicks on the AT&T icon in the lefthand panel of screen 900. It is notable that although the user perceives that he is directly linked to the AT&T server, the user actually continues to interface with the EBPP system and communicates with the AT&T server through the EBPP system.
[0051] The user may then display the exemplary screen 1100 shown in Fig. 11. Screen 1100 includes AT&T's branding and marketing messages in the Page 13 of 22 lefthand portion of the screen and only unpaid AT&T bills in the central portion of the screen. Advantageously, such branding and marketing messages (e.g., product/service promotional messages) can be updated by the billet. The billing data is a summary of the data provided on the actual bills, thereby significantly simplifying the billpaying process for the user as only the essential information for paying bills is shown. It is notable that the "new bills" button 1106, "schedules" button 1108, "unpaid bills" button 1110, and "history" button 1112 may now be used to show the new bills, schedules, unpaid bills (as shown), and history for AT&T
billing data only.
[0052] At step 408, the user selects a bill that is to be paid. As noted above, there are a number of ways in which a user can select a billet and the bill that is to be paid. Screen 1100 enables a user to directly select to pay one or more bills 1114. In the exemplary screen, the user selected to pay a X300 AT&T bill only.
Once one or more bills are selected, the user may have the bill paid from an account that was previously established as a default account or, by using pulldown screens 111, selecting a particular account from which funds are to be withdrawn to pay the selected bill(s). In the exemplary screen ~.~.~0 a "Key ~heclzlng" acc~unt is the default acc~unt that will be used to pay the selected bill. Once the user identifies the one or more bills that are to be paid, the system instructs the financial institution to pay the one or more bills. Thereafter, the financial institution carries out the one or more transactions. Advantageously, the disclosed EEPP system avoids the need to comply with various online banking regulations that competitive systems have t~
comply with.
[005] As noted above, bills that are to be paid may be selected for payment in alternative ways. For example, referring to screen J00, a user may directly click on a bill listed as a new or unpaid bill. As a further example, a user may directly click on a bill that is listed as a bill scheduled for payment. In both examples, the lefthand portion of the screen may display the selected billet's branding, marketing messages, links, and messages. At such point, the user would proceed as described above with respect to step 406 et seq. to pay the bill.
[0054] At step 412, once one or more bills have been selected for payment, the user may select the "pay bill" button 1118. The one or more bills will Page 14 of 22 be paid out of the default account unless another account was selected by the user.
At step 414, if there are insufficient funds in the account from which funds are to be withdrawn, then, at step 416, the user is prompted to provide an alternate account to transfer funds to the account having insufficient funds. The prompt may be as shown in Fig. 10b, indicating that there is an error (i.e., insufFcient funds) and prompting the user to complete the transfer of funds before proceeding. At step 418, the user follows the prompts by providing an alternate account or transfers finds to the account having insufficient funds. Thereafter the user proceeds to step 412 and proceeds as described above. If the user decides that he does not want to provide an alternate account or transfer funds, then the user may proceed to step 320 and log out. Of course, as at other points in the present system a user may take other actions such as return to the main menu and attempt to pay other bills.
That is, the steps depicted herein are just one embodiment of the invention and not meant to limit the flexibility of the system.
[0055] If at step 414 it is determined that there are sufficient funds in the user's account from which the funds are to be withdrawn, then the system would proceed to step ~~2~. At step ~2~, the user may review the change in the status of the bills that have been paid by, for example, returning to the main menu ~~~
and reviewing the °°Paid?" column to verify that it reads °°yes" in the line corresponding to the bill just paid. Alternative screen 600 allows a user to review the status of a payment by reviewing the "paid (last 30 days)" box.
[~~5~] As an approved entity, the EBPP provider is authorized to direct the financial institution to pay a bill. lJpon receiving instructions from a user to pay a bill, the provider posts the bill with the appropriate financial institution for payment.
The bank may pay bills in any number of standardized ways (e.g., via ACH, mutual partnership agreements between participating banks).
[0057] As noted above, the EBPP system automatically recognizes the a ser when that user logs on. Therefore, for example, if a user logs on for a business, then the system will be configured accordingly. Many of the functionalities provided to all user, regardless if the user is a business or a consumer. For example, the system may provide dispute resolution functions useful for rectifying billing disputes.
Page 15 of 22 Utilizing such a function, a user may be provided a form in which he could indicate the dispute and automatically transmit the form to a biller.
[0058] The system utilizes an automated dispute resolution methodology. Upon presentation of an electronic invoice to a user, the system can automatically compare specific biller invoice details to a user's receiving and purchase order documents. This allows the system to automatic ally determine any differences between what the biller billed and what the payer ordered and/or received and create a turnaround document informing the biller of the differences.
For example, assume a biller invoiced an item at $2.00 a unit for 10 units.
However, the payer's applicable receiving document and purchase order indicate the payer expected to pay $1.75 a unit and that only 9 units were received. The system will automatically determine both price and quantity differences, adjust the invoice line item amount due accordingly, and transmit to the biller the information required for the biller to change their records to bring them into agreement with the payer's. As a further example, if a user buys 100 items and he should have received a 10%
price break due to a purchasing agreement, the system will automatically evaluate the bill and flag the bill if the price break is inadvertently not included. The system will also build a history file of these transactions that can be analyzed to determine if the billing errors are random, or if the biller is deliberately billing in error.
[0059] The system may provide importing functions for importing billing/payment information directly from the E~PP system to a tax program such as TurboTax by intuit, Inc. (Mountain View, CA) or t~ a thirdparty to , advisor.
[0060] The system may provide fraud detection functions such as those provided by eFalcon of HNC Software, Inc. (San ~iego, CA), a leading realtime payment fraud detection service.
[0061] The user can look at the types of things purchased by a business to determine if the business is heading toward bankruptcy. For example, a cashstrapped company will tend to purchase more "quick turnover products" than "long turnover products."
[0062] The system may use an artificial intelligence based conversion software that is able to read biller or payer bill/statement/invoice/purchase order/receiving document preparation software and extract the business rules Page 16 of 22 developed by the biller or payer that determine the structure of the printed document. The biller or payer data is stored in a standardized database, independent of the extracted business rules. The business rules are stored in an adjunct database. This procedure allows the system to use the same database structure for all users. It also significantly reduces the time and cost required to convert a new user.
[0063] The system may duplicate biller/payer output for either printed or electronic presentation, as required. An advantage lies in the ability to easily change the business rules without affecting the data. It is also possible to determine the effect of a rule change by back testing it against previously stored data and comparing the different outputs to each other. Also using a uniform database allows the system to use advanced data mining techniques across its entire database (within and between all users).
[0064] The nature of the biller and payer data stored in the systems database, as a result of the system's bill and invoice presentment and settlement processing, allows a myriad of analytical services to both billers and payers.
It should be noted that depending upon the type of analyties required, billers or payers may request various analyses to be run in batch mode with the report delivered, sometime later, over the Internet or run interactively with the biller or payer entering certain required data, online, upon a system request and the report produced and available while the user is still online.
[~O~i~] The system can determine within a stated confidence level how much of the billers accounts receivable is unlikely to be collected over a specified time horizon. For example, after a valueatrisk c~VAR'7 analysis is completed a statement similar to the following would be made: We are 95 % confident that the accounts receivable portfolio collection percent, over the coming six months, will not be less than 82.78%. Based on the portfolio value of $25 million the VAR =
(100%
82.78%) x $25,000, 000 = $4,305,000.
[0066] The system may also perform a purchasing pattern analysis. If the biller provides certain inventory class information, the system can determine whether the payer (purchaser) has significantly changed their purchasing pattern. A
change that would be red flagged would be for the purchaser to discontinue buying Page 17 of 22 ' CA 02518263 2005-09-06 across a product line to only acquiring fastmoving items. A buying change of this nature, in an account, can signify that the payer is having cash flow problems, in particular if they are the only customer that has made such a purchasing pattern change. Additionally, purchase pattern analysis may provide a billet with a guide as to the order to present any online promotions or specials to the payer such that the probability of the payer accepting, i.e., clicking on the promotion, is maximized.
[0067] The system may also perform a customer payment tracking analysis. The system can provide a billet with a comparative analysis of their customer payments over time and, thereby, help the billet to determine whether their risk of doing business with any specific customer is changing at a rate that indicates a potential credit problem with that customer sometime in the future.
[0068] The system may also evaluate credit department operations. The database contains both billing and payment data. Therefore, the system can utilize a discounted cash flow ("DCF'7 analysis to determine the maximum DCF of a given invoice versus the realized DCF of the invoice. If information is provided as to the salesman on each account or the credit analyst responsible it is possible to rank each individual in either the credit department or the sales department as to their performance, using an unbiased measure, compared to DSO or total sales which don°t take into account the time value of money.
[0069] The system may perform cash flow forecasting. The database, for a given billet, will contain multiple months of billing and payment activity by customer. The system will analyze this data for its billets, and develop a cash flow forecast for a specified time horizon based upon a statistical analysis of past performance and the billet's estimated sales forecast over the specified time period.
[0070] The system may perform fraud detection. Another byproduct of analyzing the payer's purchasing pattern is fraud detection. If there is a significant variation from the payer's normal purchasing pattern with a specific billet, the system will alert the payer that there may be invoiced items that the payer did not order or receive. This would be for payers that have not contracted with the system to convert its vendors to use the business invoice electronic presentation system.
[0071] The system may perform a cash requirements analysis. The system can analyze the payers unpaid invoice file and its outstanding purchase order Page 18 of 22 file, and based upon an analysis of the payers past performance develop a monthly cash requirements analysis over a specified time horizon.
[0072] From the detailed description provided above it should be readily apparent to those of ordinary skill in the art that the present invention is a significant improvement over prior art EBPP systems. An EBPP system and method is disclosed that enables a user to specify preferred financial institutions and billers with which the user does business and makes them accessible on a single Web site. In addition, a system and method is disclosed that enables the financial institution to present identification and targeted product/services promotional material and billers to present identification and targeted production/services promotional materials and billing data on the Web site. Furthermore, the system and methods disclosed provide significantly enhanced security and privacy for users' information.
[0073] Although the present invention has been described in detail with respect to certain embodiments and examples, variations and modifications exist which are within the scope of the present invention.
a Page 19 of 22
[0050] At step 404, the user selects a biller that is to be paid. As noted above, there are variety of ways a user may select a biller, and thereafter a bill to be paid. A user may click directly on the biller°s icon in the left hand panel. A scroll bar may be provided to access billers' icons that do not appear in the lefthand portion of the screen. If the user clicks on a biller's icon, the lefthand portion of the screen may display the selected biller's branding, marketing messages, links, messages, and a login message. Fig. 11 shows an exemplary screen 1100 that may be displayed after a user clicks on the AT&T icon in the lefthand panel of screen 900. It is notable that although the user perceives that he is directly linked to the AT&T server, the user actually continues to interface with the EBPP system and communicates with the AT&T server through the EBPP system.
[0051] The user may then display the exemplary screen 1100 shown in Fig. 11. Screen 1100 includes AT&T's branding and marketing messages in the Page 13 of 22 lefthand portion of the screen and only unpaid AT&T bills in the central portion of the screen. Advantageously, such branding and marketing messages (e.g., product/service promotional messages) can be updated by the billet. The billing data is a summary of the data provided on the actual bills, thereby significantly simplifying the billpaying process for the user as only the essential information for paying bills is shown. It is notable that the "new bills" button 1106, "schedules" button 1108, "unpaid bills" button 1110, and "history" button 1112 may now be used to show the new bills, schedules, unpaid bills (as shown), and history for AT&T
billing data only.
[0052] At step 408, the user selects a bill that is to be paid. As noted above, there are a number of ways in which a user can select a billet and the bill that is to be paid. Screen 1100 enables a user to directly select to pay one or more bills 1114. In the exemplary screen, the user selected to pay a X300 AT&T bill only.
Once one or more bills are selected, the user may have the bill paid from an account that was previously established as a default account or, by using pulldown screens 111, selecting a particular account from which funds are to be withdrawn to pay the selected bill(s). In the exemplary screen ~.~.~0 a "Key ~heclzlng" acc~unt is the default acc~unt that will be used to pay the selected bill. Once the user identifies the one or more bills that are to be paid, the system instructs the financial institution to pay the one or more bills. Thereafter, the financial institution carries out the one or more transactions. Advantageously, the disclosed EEPP system avoids the need to comply with various online banking regulations that competitive systems have t~
comply with.
[005] As noted above, bills that are to be paid may be selected for payment in alternative ways. For example, referring to screen J00, a user may directly click on a bill listed as a new or unpaid bill. As a further example, a user may directly click on a bill that is listed as a bill scheduled for payment. In both examples, the lefthand portion of the screen may display the selected billet's branding, marketing messages, links, and messages. At such point, the user would proceed as described above with respect to step 406 et seq. to pay the bill.
[0054] At step 412, once one or more bills have been selected for payment, the user may select the "pay bill" button 1118. The one or more bills will Page 14 of 22 be paid out of the default account unless another account was selected by the user.
At step 414, if there are insufficient funds in the account from which funds are to be withdrawn, then, at step 416, the user is prompted to provide an alternate account to transfer funds to the account having insufficient funds. The prompt may be as shown in Fig. 10b, indicating that there is an error (i.e., insufFcient funds) and prompting the user to complete the transfer of funds before proceeding. At step 418, the user follows the prompts by providing an alternate account or transfers finds to the account having insufficient funds. Thereafter the user proceeds to step 412 and proceeds as described above. If the user decides that he does not want to provide an alternate account or transfer funds, then the user may proceed to step 320 and log out. Of course, as at other points in the present system a user may take other actions such as return to the main menu and attempt to pay other bills.
That is, the steps depicted herein are just one embodiment of the invention and not meant to limit the flexibility of the system.
[0055] If at step 414 it is determined that there are sufficient funds in the user's account from which the funds are to be withdrawn, then the system would proceed to step ~~2~. At step ~2~, the user may review the change in the status of the bills that have been paid by, for example, returning to the main menu ~~~
and reviewing the °°Paid?" column to verify that it reads °°yes" in the line corresponding to the bill just paid. Alternative screen 600 allows a user to review the status of a payment by reviewing the "paid (last 30 days)" box.
[~~5~] As an approved entity, the EBPP provider is authorized to direct the financial institution to pay a bill. lJpon receiving instructions from a user to pay a bill, the provider posts the bill with the appropriate financial institution for payment.
The bank may pay bills in any number of standardized ways (e.g., via ACH, mutual partnership agreements between participating banks).
[0057] As noted above, the EBPP system automatically recognizes the a ser when that user logs on. Therefore, for example, if a user logs on for a business, then the system will be configured accordingly. Many of the functionalities provided to all user, regardless if the user is a business or a consumer. For example, the system may provide dispute resolution functions useful for rectifying billing disputes.
Page 15 of 22 Utilizing such a function, a user may be provided a form in which he could indicate the dispute and automatically transmit the form to a biller.
[0058] The system utilizes an automated dispute resolution methodology. Upon presentation of an electronic invoice to a user, the system can automatically compare specific biller invoice details to a user's receiving and purchase order documents. This allows the system to automatic ally determine any differences between what the biller billed and what the payer ordered and/or received and create a turnaround document informing the biller of the differences.
For example, assume a biller invoiced an item at $2.00 a unit for 10 units.
However, the payer's applicable receiving document and purchase order indicate the payer expected to pay $1.75 a unit and that only 9 units were received. The system will automatically determine both price and quantity differences, adjust the invoice line item amount due accordingly, and transmit to the biller the information required for the biller to change their records to bring them into agreement with the payer's. As a further example, if a user buys 100 items and he should have received a 10%
price break due to a purchasing agreement, the system will automatically evaluate the bill and flag the bill if the price break is inadvertently not included. The system will also build a history file of these transactions that can be analyzed to determine if the billing errors are random, or if the biller is deliberately billing in error.
[0059] The system may provide importing functions for importing billing/payment information directly from the E~PP system to a tax program such as TurboTax by intuit, Inc. (Mountain View, CA) or t~ a thirdparty to , advisor.
[0060] The system may provide fraud detection functions such as those provided by eFalcon of HNC Software, Inc. (San ~iego, CA), a leading realtime payment fraud detection service.
[0061] The user can look at the types of things purchased by a business to determine if the business is heading toward bankruptcy. For example, a cashstrapped company will tend to purchase more "quick turnover products" than "long turnover products."
[0062] The system may use an artificial intelligence based conversion software that is able to read biller or payer bill/statement/invoice/purchase order/receiving document preparation software and extract the business rules Page 16 of 22 developed by the biller or payer that determine the structure of the printed document. The biller or payer data is stored in a standardized database, independent of the extracted business rules. The business rules are stored in an adjunct database. This procedure allows the system to use the same database structure for all users. It also significantly reduces the time and cost required to convert a new user.
[0063] The system may duplicate biller/payer output for either printed or electronic presentation, as required. An advantage lies in the ability to easily change the business rules without affecting the data. It is also possible to determine the effect of a rule change by back testing it against previously stored data and comparing the different outputs to each other. Also using a uniform database allows the system to use advanced data mining techniques across its entire database (within and between all users).
[0064] The nature of the biller and payer data stored in the systems database, as a result of the system's bill and invoice presentment and settlement processing, allows a myriad of analytical services to both billers and payers.
It should be noted that depending upon the type of analyties required, billers or payers may request various analyses to be run in batch mode with the report delivered, sometime later, over the Internet or run interactively with the biller or payer entering certain required data, online, upon a system request and the report produced and available while the user is still online.
[~O~i~] The system can determine within a stated confidence level how much of the billers accounts receivable is unlikely to be collected over a specified time horizon. For example, after a valueatrisk c~VAR'7 analysis is completed a statement similar to the following would be made: We are 95 % confident that the accounts receivable portfolio collection percent, over the coming six months, will not be less than 82.78%. Based on the portfolio value of $25 million the VAR =
(100%
82.78%) x $25,000, 000 = $4,305,000.
[0066] The system may also perform a purchasing pattern analysis. If the biller provides certain inventory class information, the system can determine whether the payer (purchaser) has significantly changed their purchasing pattern. A
change that would be red flagged would be for the purchaser to discontinue buying Page 17 of 22 ' CA 02518263 2005-09-06 across a product line to only acquiring fastmoving items. A buying change of this nature, in an account, can signify that the payer is having cash flow problems, in particular if they are the only customer that has made such a purchasing pattern change. Additionally, purchase pattern analysis may provide a billet with a guide as to the order to present any online promotions or specials to the payer such that the probability of the payer accepting, i.e., clicking on the promotion, is maximized.
[0067] The system may also perform a customer payment tracking analysis. The system can provide a billet with a comparative analysis of their customer payments over time and, thereby, help the billet to determine whether their risk of doing business with any specific customer is changing at a rate that indicates a potential credit problem with that customer sometime in the future.
[0068] The system may also evaluate credit department operations. The database contains both billing and payment data. Therefore, the system can utilize a discounted cash flow ("DCF'7 analysis to determine the maximum DCF of a given invoice versus the realized DCF of the invoice. If information is provided as to the salesman on each account or the credit analyst responsible it is possible to rank each individual in either the credit department or the sales department as to their performance, using an unbiased measure, compared to DSO or total sales which don°t take into account the time value of money.
[0069] The system may perform cash flow forecasting. The database, for a given billet, will contain multiple months of billing and payment activity by customer. The system will analyze this data for its billets, and develop a cash flow forecast for a specified time horizon based upon a statistical analysis of past performance and the billet's estimated sales forecast over the specified time period.
[0070] The system may perform fraud detection. Another byproduct of analyzing the payer's purchasing pattern is fraud detection. If there is a significant variation from the payer's normal purchasing pattern with a specific billet, the system will alert the payer that there may be invoiced items that the payer did not order or receive. This would be for payers that have not contracted with the system to convert its vendors to use the business invoice electronic presentation system.
[0071] The system may perform a cash requirements analysis. The system can analyze the payers unpaid invoice file and its outstanding purchase order Page 18 of 22 file, and based upon an analysis of the payers past performance develop a monthly cash requirements analysis over a specified time horizon.
[0072] From the detailed description provided above it should be readily apparent to those of ordinary skill in the art that the present invention is a significant improvement over prior art EBPP systems. An EBPP system and method is disclosed that enables a user to specify preferred financial institutions and billers with which the user does business and makes them accessible on a single Web site. In addition, a system and method is disclosed that enables the financial institution to present identification and targeted product/services promotional material and billers to present identification and targeted production/services promotional materials and billing data on the Web site. Furthermore, the system and methods disclosed provide significantly enhanced security and privacy for users' information.
[0073] Although the present invention has been described in detail with respect to certain embodiments and examples, variations and modifications exist which are within the scope of the present invention.
a Page 19 of 22
Claims (13)
1. A system for electronic bill presentation and payment ("EBPP"), comprising:
a memory for storing Web pages for an EBPP Web site; and a processor in communication with the memory, wherein the processor is operative to (i) receive an EBPP user interface ("UI") from an EBPP host, the UI configured to display financial institution information in a first portion of the UI, configured to display billing party information in a second portion of the UI, and configured to display billing data in a third portion of the UI, (ii) receive the financial institution information for display in the first portion of the UI, (iii) transmit a request for the billing party information and billing data, (iv) receive the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI, (v) transmit instructions to the EBPP host to have one or more bills of the billing party paid, and (vi) transmit payment information to the billing company.
a memory for storing Web pages for an EBPP Web site; and a processor in communication with the memory, wherein the processor is operative to (i) receive an EBPP user interface ("UI") from an EBPP host, the UI configured to display financial institution information in a first portion of the UI, configured to display billing party information in a second portion of the UI, and configured to display billing data in a third portion of the UI, (ii) receive the financial institution information for display in the first portion of the UI, (iii) transmit a request for the billing party information and billing data, (iv) receive the billing party information for display in the second portion of the UI and the billing data identifying one or more bills for display in the third portion of the UI, (v) transmit instructions to the EBPP host to have one or more bills of the billing party paid, and (vi) transmit payment information to the billing company.
2. The system of claim 1, wherein the financial institution information comprises product/service promotional information of the financial institution.
3. The system of claim 1, wherein the billing party information comprises product/service promotional information, messages, and links.
4. The system of claim 1, wherein the UI content resides on Macromedia Flash and other Macromedia product lines.
5. The system of claim 1, wherein the EBPP system includes businesstobusiness components and businesstoconsumer components.
6. The system of claim 1, wherein the processor serves both businesses and consumers.
7. The system of claim 1, wherein the processor retrieves from a centralized data base, data acquired from servers of both financial institutions and billing companies, to present financial institution information, biller information, and presenter information on a single Web page.
8. A method for utilizing an electronic bill presentation and payment ("EBPP") system, comprising:
receiving an EBPP user interface ("UI") from an EBPP host, the UI configured to display financial institution information in a first portion of the UI, configured to display billing party information in a second portion of the UI, and configured to display billing data in a third portion of the UI;
receiving the financial institution information for display in the first portion of the UI;
transmitting a request for the billing party information and billing data;
receiving the billing party information for display in the second portion of the UI
and the billing data identifying one or more bills for display in the third portion of the UI; and transmitting instructions to the EBPP host to have one or more bills of the billing party paid and transmitting payment information back to the billing company or bank.
receiving an EBPP user interface ("UI") from an EBPP host, the UI configured to display financial institution information in a first portion of the UI, configured to display billing party information in a second portion of the UI, and configured to display billing data in a third portion of the UI;
receiving the financial institution information for display in the first portion of the UI;
transmitting a request for the billing party information and billing data;
receiving the billing party information for display in the second portion of the UI
and the billing data identifying one or more bills for display in the third portion of the UI; and transmitting instructions to the EBPP host to have one or more bills of the billing party paid and transmitting payment information back to the billing company or bank.
9. The method of claim 8, wherein the financial institution information is identification and product/service promotional information of the financial institution.
10. The method of claim 8, wherein the billing party information is product/service promotional information, messages, and links.
11. The method of claim 8, wherein the UI content is developed using Macromedia Flash and other Macromedia product lines.
12. The method of claim 8, wherein the financial institution controls the content of the financial institution information and the billing party controls of the content of the billing party information.
13. The method of claim 8, wherein the financial institution and billing party are preselected by the user.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US45458503P | 2003-03-13 | 2003-03-13 | |
| US60/454,585 | 2003-03-13 | ||
| PCT/US2004/007490 WO2004082361A2 (en) | 2003-03-13 | 2004-03-12 | Electronic bill presentation and payment system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2518263A1 true CA2518263A1 (en) | 2004-09-30 |
Family
ID=33029899
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002518263A Abandoned CA2518263A1 (en) | 2003-03-13 | 2004-03-12 | Electronic bill presentation and payment system |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20040225609A1 (en) |
| EP (1) | EP1618541A4 (en) |
| JP (1) | JP2007524887A (en) |
| AU (1) | AU2004222389A1 (en) |
| CA (1) | CA2518263A1 (en) |
| WO (1) | WO2004082361A2 (en) |
Families Citing this family (97)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU4958801A (en) | 2000-03-29 | 2001-10-08 | Mastercard International Inc | Method and system for processing messages in a bill payment and presentment system over a communications network |
| WO2003091849A2 (en) | 2002-04-23 | 2003-11-06 | The Clearing House Service Company L.L.C. | Payment identification code system |
| US9710852B1 (en) | 2002-05-30 | 2017-07-18 | Consumerinfo.Com, Inc. | Credit report timeline user interface |
| US9400589B1 (en) | 2002-05-30 | 2016-07-26 | Consumerinfo.Com, Inc. | Circular rotational interface for display of consumer credit information |
| US8725607B2 (en) | 2004-01-30 | 2014-05-13 | The Clearing House Payments Company LLC | Electronic payment clearing and check image exchange systems and methods |
| US20070214078A1 (en) * | 2005-09-28 | 2007-09-13 | Transpayment, Inc. | Bill payment apparatus and method |
| US8583534B1 (en) * | 2005-09-30 | 2013-11-12 | Trading Technologies International Inc. | System and method for multi-market risk control in a distributed electronic trading environment |
| US8510220B2 (en) | 2006-07-06 | 2013-08-13 | Qualcomm Incorporated | Methods and systems for viewing aggregated payment obligations in a mobile environment |
| US8145568B2 (en) | 2006-07-06 | 2012-03-27 | Firethorn Mobile, Inc. | Methods and systems for indicating a payment in a mobile environment |
| EP1980986A3 (en) * | 2006-07-06 | 2011-03-02 | Firethorn Holdings, LLC | Method and systems for managing payment sources in a mobile environment |
| US8160959B2 (en) | 2006-07-06 | 2012-04-17 | Firethorn Mobile, Inc. | Methods and systems for payment transactions in a mobile environment |
| US8121945B2 (en) * | 2006-07-06 | 2012-02-21 | Firethorn Mobile, Inc. | Methods and systems for payment method selection by a payee in a mobile environment |
| US8489067B2 (en) | 2006-07-06 | 2013-07-16 | Qualcomm Incorporated | Methods and systems for distribution of a mobile wallet for a mobile device |
| US9911114B2 (en) | 2006-07-06 | 2018-03-06 | Qualcomm Incorporated | Methods and systems for making a payment via a stored value card in a mobile environment |
| US8467766B2 (en) | 2006-07-06 | 2013-06-18 | Qualcomm Incorporated | Methods and systems for managing payment sources in a mobile environment |
| BRPI0715289A2 (en) * | 2006-10-02 | 2013-06-11 | Segmint Inc | custom consumption for advertising |
| US8874465B2 (en) | 2006-10-02 | 2014-10-28 | Russel Robert Heiser, III | Method and system for targeted content placement |
| US8626661B2 (en) * | 2006-10-10 | 2014-01-07 | Global Standard Financial, Inc. | Electronic lockbox using digitally originated checks |
| US7676434B2 (en) * | 2007-01-28 | 2010-03-09 | Bora Payment Systems, Llc | Payer direct hub |
| US7558777B1 (en) * | 2007-01-31 | 2009-07-07 | Intuit Inc. | Technique for identifying and collecting record-keeping information |
| WO2009070727A2 (en) * | 2007-11-27 | 2009-06-04 | Regulus Group, Llc. | Billing and remittance payment system |
| US8127986B1 (en) | 2007-12-14 | 2012-03-06 | Consumerinfo.Com, Inc. | Card registry systems and methods |
| US9990674B1 (en) | 2007-12-14 | 2018-06-05 | Consumerinfo.Com, Inc. | Card registry systems and methods |
| US8359245B1 (en) | 2008-01-15 | 2013-01-22 | SciQuest Inc. | Taxonomy and data structure for an electronic procurement system |
| US8694429B1 (en) * | 2008-01-15 | 2014-04-08 | Sciquest, Inc. | Identifying and resolving discrepancies between purchase documents and invoices |
| US10043201B2 (en) | 2008-01-31 | 2018-08-07 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
| US9141991B2 (en) | 2008-01-31 | 2015-09-22 | Bill.Com, Inc. | Enhanced electronic data and metadata interchange system and process for electronic billing and payment system |
| US10769686B2 (en) | 2008-01-31 | 2020-09-08 | Bill.Com Llc | Enhanced invitation process for electronic billing and payment system |
| US11669866B2 (en) | 2008-03-17 | 2023-06-06 | Segmint Inc. | System and method for delivering a financial application to a prospective customer |
| US8234159B2 (en) | 2008-03-17 | 2012-07-31 | Segmint Inc. | Method and system for targeted content placement |
| US11138632B2 (en) | 2008-03-17 | 2021-10-05 | Segmint Inc. | System and method for authenticating a customer for a pre-approved offer of credit |
| US11663631B2 (en) | 2008-03-17 | 2023-05-30 | Segmint Inc. | System and method for pulling a credit offer on bank's pre-approved property |
| US10885552B2 (en) | 2008-03-17 | 2021-01-05 | Segmint, Inc. | Method and system for targeted content placement |
| US11120471B2 (en) | 2013-10-18 | 2021-09-14 | Segmint Inc. | Method and system for targeted content placement |
| US9245291B1 (en) | 2008-05-27 | 2016-01-26 | SciQuest Inc. | Method, medium, and system for purchase requisition importation |
| US8312033B1 (en) | 2008-06-26 | 2012-11-13 | Experian Marketing Solutions, Inc. | Systems and methods for providing an integrated identifier |
| US8060424B2 (en) | 2008-11-05 | 2011-11-15 | Consumerinfo.Com, Inc. | On-line method and system for monitoring and reporting unused available credit |
| US20100169234A1 (en) * | 2009-01-01 | 2010-07-01 | Wizbill Ltd | Method for Capturing the Essence of Product and Service Offers of Service Providers |
| US10594870B2 (en) | 2009-01-21 | 2020-03-17 | Truaxis, Llc | System and method for matching a savings opportunity using census data |
| US10504126B2 (en) | 2009-01-21 | 2019-12-10 | Truaxis, Llc | System and method of obtaining merchant sales information for marketing or sales teams |
| US20110258028A1 (en) * | 2009-01-21 | 2011-10-20 | Billshrink, Inc. | System and method for providing a geographic map of alternative savings opportunities in association with a financial transaction data |
| US8595134B2 (en) | 2010-02-12 | 2013-11-26 | Mastercard International Incorporated | Apparatus and method for bill presentment and payment |
| BR112012028896A2 (en) | 2010-05-10 | 2017-03-14 | Segmint Inc | "consumer-specific advertising presentation and offer library" |
| US20120053967A1 (en) * | 2010-09-01 | 2012-03-01 | American Express Travel Related Services Company, Inc. | System and Method for Account Reconciliation |
| US9665854B1 (en) | 2011-06-16 | 2017-05-30 | Consumerinfo.Com, Inc. | Authentication alerts |
| US9483606B1 (en) | 2011-07-08 | 2016-11-01 | Consumerinfo.Com, Inc. | Lifescore |
| US9106691B1 (en) | 2011-09-16 | 2015-08-11 | Consumerinfo.Com, Inc. | Systems and methods of identity protection and management |
| US8738516B1 (en) | 2011-10-13 | 2014-05-27 | Consumerinfo.Com, Inc. | Debt services candidate locator |
| CN103123732B (en) * | 2011-11-21 | 2016-08-10 | 鸿富锦精密工业（深圳）有限公司 | A kind of public charging management system and charging method |
| US10169812B1 (en) * | 2012-01-20 | 2019-01-01 | The Pnc Financial Services Group, Inc. | Providing financial account information to users |
| US20130226798A1 (en) * | 2012-02-27 | 2013-08-29 | Bill.Com, Inc. | Methods and systems for automating payments utilizing rules and constraints |
| US8819789B2 (en) | 2012-03-07 | 2014-08-26 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
| US9853959B1 (en) | 2012-05-07 | 2017-12-26 | Consumerinfo.Com, Inc. | Storage and maintenance of personal data |
| US9654541B1 (en) | 2012-11-12 | 2017-05-16 | Consumerinfo.Com, Inc. | Aggregating user web browsing data |
| US9916621B1 (en) | 2012-11-30 | 2018-03-13 | Consumerinfo.Com, Inc. | Presentation of credit score factors |
| US10255598B1 (en) | 2012-12-06 | 2019-04-09 | Consumerinfo.Com, Inc. | Credit card account data extraction |
| US20150012442A1 (en) | 2013-03-14 | 2015-01-08 | Bill.Com, Inc. | Enhanced system and method for scanning and processing of payment documentation |
| US9406085B1 (en) | 2013-03-14 | 2016-08-02 | Consumerinfo.Com, Inc. | System and methods for credit dispute processing, resolution, and reporting |
| US10102570B1 (en) | 2013-03-14 | 2018-10-16 | Consumerinfo.Com, Inc. | Account vulnerability alerts |
| US9870589B1 (en) | 2013-03-14 | 2018-01-16 | Consumerinfo.Com, Inc. | Credit utilization tracking and reporting |
| US10115137B2 (en) | 2013-03-14 | 2018-10-30 | Bill.Com, Inc. | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
| US10417674B2 (en) | 2013-03-14 | 2019-09-17 | Bill.Com, Llc | System and method for sharing transaction information by object tracking of inter-entity transactions and news streams |
| US9582787B2 (en) * | 2013-04-23 | 2017-02-28 | Paypal, Inc. | Recovery of declined transactions |
| US10685398B1 (en) | 2013-04-23 | 2020-06-16 | Consumerinfo.Com, Inc. | Presenting credit score information |
| US10572921B2 (en) | 2013-07-03 | 2020-02-25 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
| US9443268B1 (en) * | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
| US10325314B1 (en) * | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
| US9477737B1 (en) | 2013-11-20 | 2016-10-25 | Consumerinfo.Com, Inc. | Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules |
| USD760256S1 (en) | 2014-03-25 | 2016-06-28 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
| USD759689S1 (en) | 2014-03-25 | 2016-06-21 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
| USD759690S1 (en) | 2014-03-25 | 2016-06-21 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
| US9892457B1 (en) | 2014-04-16 | 2018-02-13 | Consumerinfo.Com, Inc. | Providing credit data in search results |
| US20160020914A1 (en) * | 2014-07-15 | 2016-01-21 | Verizon Patent And Licensing Inc. | Method, apparatus, and system for providing billing entity information for a web session |
| US11295308B1 (en) | 2014-10-29 | 2022-04-05 | The Clearing House Payments Company, L.L.C. | Secure payment processing |
| US11042882B2 (en) | 2015-07-01 | 2021-06-22 | The Clearing House Payments Company, L.L.C. | Real-time payment system, method, apparatus, and computer program |
| US11694168B2 (en) | 2015-07-01 | 2023-07-04 | The Clearing House Payments Company L.L.C. | Real-time payment system, method, apparatus, and computer program |
| WO2017009726A1 (en) * | 2015-07-10 | 2017-01-19 | Muthyalu Govindraj | A cash flow management system |
| US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
| US9842330B1 (en) | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
| KR102409769B1 (en) | 2017-05-16 | 2022-06-16 | 애플 인크. | User interfaces for peer-to-peer transfers |
| US11221744B2 (en) | 2017-05-16 | 2022-01-11 | Apple Inc. | User interfaces for peer-to-peer transfers |
| US20190066115A1 (en) * | 2017-08-22 | 2019-02-28 | Coupa Software Incorporated | Calculation of benchmark dispute overage and rejection data with redress options |
| US20200202353A9 (en) * | 2017-09-15 | 2020-06-25 | James Eugene Paullus, JR. | Electronic Wallet Enterprise System Comprising Guaranteed Electronic Payment Transactions |
| US11436577B2 (en) | 2018-05-03 | 2022-09-06 | The Clearing House Payments Company L.L.C. | Bill pay service with federated directory model support |
| KR20240024294A (en) | 2018-06-03 | 2024-02-23 | 애플 인크. | User interfaces for transfer accounts |
| US11100498B2 (en) | 2018-06-03 | 2021-08-24 | Apple Inc. | User interfaces for transfer accounts |
| US10880313B2 (en) | 2018-09-05 | 2020-12-29 | Consumerinfo.Com, Inc. | Database platform for realtime updating of user data from third party sources |
| US11315179B1 (en) | 2018-11-16 | 2022-04-26 | Consumerinfo.Com, Inc. | Methods and apparatuses for customized card recommendations |
| US11238656B1 (en) | 2019-02-22 | 2022-02-01 | Consumerinfo.Com, Inc. | System and method for an augmented reality experience via an artificial intelligence bot |
| US11328352B2 (en) | 2019-03-24 | 2022-05-10 | Apple Inc. | User interfaces for managing an account |
| US11797962B2 (en) * | 2019-06-10 | 2023-10-24 | The Toronto-Dominion Bank | Configuring data transfers based on electronic messages |
| US11941065B1 (en) | 2019-09-13 | 2024-03-26 | Experian Information Solutions, Inc. | Single identifier platform for storing entity data |
| US20210082040A1 (en) * | 2019-09-16 | 2021-03-18 | The Toronto-Dominion Bank | Systems and methods for configuring transfers |
| WO2022003977A1 (en) * | 2020-07-03 | 2022-01-06 | ファーストアカウンティング株式会社 | Data processing device, data processing method, and program |
| US11921992B2 (en) | 2021-05-14 | 2024-03-05 | Apple Inc. | User interfaces related to time |
| JP7041992B1 (en) * | 2021-07-30 | 2022-03-25 | ファーストアカウンティング株式会社 | Data processing equipment, data processing methods and programs |
| US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5283829A (en) * | 1992-10-01 | 1994-02-01 | Bell Communications Research, Inc. | System and method for paying bills electronically |
| US5794221A (en) * | 1995-07-07 | 1998-08-11 | Egendorf; Andrew | Internet billing method |
| US5884288A (en) * | 1996-07-01 | 1999-03-16 | Sun Microsystems, Inc. | Method and system for electronic bill payment |
| AU745141B2 (en) * | 1996-10-09 | 2002-03-14 | Visa International Service Association | Electronic statement presentment system |
| US6070150A (en) * | 1996-10-18 | 2000-05-30 | Microsoft Corporation | Electronic bill presentment and payment system |
| US6292789B1 (en) * | 1997-08-26 | 2001-09-18 | Citibank, N.A. | Method and system for bill presentment and payment |
| US6493685B1 (en) * | 1999-02-10 | 2002-12-10 | The Chase Manhattan Bank | Electronic account presentation and response system and method |
| US7945491B2 (en) * | 2000-01-12 | 2011-05-17 | Metavante Corporation | Integrated systems for electronic bill presentment and payment |
| US7881962B2 (en) * | 2000-03-14 | 2011-02-01 | Verizon Business Global Llc | Early-payment discount for E-billing system |
| JP2002056272A (en) * | 2000-08-07 | 2002-02-20 | Takashi Kaise | Advertisement transmitting method, advertisement receiving method and storage medium |
| CN1409848A (en) * | 2000-09-14 | 2003-04-09 | 株式会社东芝 | Transaction system |
| KR100449786B1 (en) * | 2000-11-23 | 2004-09-22 | 인터내셔널 비지네스 머신즈 코포레이션 | System and method for performing personal finance management using the Internet |
| JP2002366741A (en) * | 2001-06-11 | 2002-12-20 | Sumitomo Life Insurance Co | System, server device and method for supporting property management |
-
2004
- 2004-03-12 EP EP04720336A patent/EP1618541A4/en active Pending
- 2004-03-12 WO PCT/US2004/007490 patent/WO2004082361A2/en active Search and Examination
- 2004-03-12 US US10/799,390 patent/US20040225609A1/en not_active Abandoned
- 2004-03-12 CA CA002518263A patent/CA2518263A1/en not_active Abandoned
- 2004-03-12 AU AU2004222389A patent/AU2004222389A1/en not_active Abandoned
- 2004-03-12 JP JP2006507094A patent/JP2007524887A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2007524887A (en) | 2007-08-30 |
| EP1618541A4 (en) | 2008-04-02 |
| WO2004082361A8 (en) | 2007-02-08 |
| WO2004082361A3 (en) | 2006-08-17 |
| US20040225609A1 (en) | 2004-11-11 |
| AU2004222389A1 (en) | 2004-09-30 |
| EP1618541A2 (en) | 2006-01-25 |
| WO2004082361A2 (en) | 2004-09-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20040225609A1 (en) | Electronic bill presentation and payment system | |
| CA2396266C (en) | Integrated systems for electronic bill presentment and payment | |
| US7103570B1 (en) | Merchant account activation system | |
| US7885869B2 (en) | Method for managing buyer transactions and settlements using communication network between computers, and method for relaying information following buyer consumption trends to the buyer | |
| US20050251460A1 (en) | Methods for soliciting donations | |
| US20130179318A1 (en) | System and Method for Debt Presentment and Resolution | |
| US20100262523A1 (en) | Method and systems for soliciting donations | |
| US20060122899A1 (en) | Comprehensive online shopping management system | |
| US20020059139A1 (en) | System and method for debt presentment and resolution | |
| AU2889200A (en) | Electronic bill presentment and/or payment clearinghouse | |
| JP2011502318A (en) | Payment processing | |
| US20040006510A1 (en) | System and method for collaborative affinity marketing | |
| US20040167852A1 (en) | Payment system | |
| US20090106144A1 (en) | Method and system for providing sellers access to selected consumers | |
| WO2000046732A1 (en) | Method and system for providing a user with integrated interactive access to products and services | |
| US20080126225A1 (en) | Intermediary service for application intergration of E-commerce functionality | |
| US20080270297A1 (en) | Gathering Information from a Financial Website | |
| KR100760373B1 (en) | Recording Medium for Providing Internet-based Household Account Book | |
| KR20120014359A (en) | Method for automatically journalizing using an act | |
| JP6250384B2 (en) | Bank account balance management system and management method thereof | |
| Walker et al. | Planning a revenue stream system in an e‐business environment | |
| Fonseca et al. | Future of Wholesale Banking: The Portal | |
| KR100759247B1 (en) | Operating Server for Household Account Book | |
| JP2003157359A (en) | Income and expenditure management system, program realizing function of the system, and recording medium | |
| KR20070034560A (en) | Method for Providing Information of Settlement Breakdown in Shopping Mall |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |