Electronic billing with flexible biller controlled electronic bill presentment

[0001] This application is related to pending application Ser. No. 09/017,169, entitled “Distributed Data Accessing Technique”, filed Feb. 2, 1998.

[0002] The present invention relates to electronic bill presentment and more particularly to electronic billing with flexible, biller controlled, electronic bill presentment.

[0003] There are two prevalent models for electronic bill presentment that are currently used in industry. The first is an aggregation model 10, which is shown in FIG. 1. In its simplest form, the aggregation model 10 includes a customer 12, an aggregator 14, and a plurality of billers 16. The customer 12 can be, for example, an individual person, a family, or a business. The aggregator 14 can be a financial institution (FI) such as, for example, a bank. Alternatively, the aggregator 14 can be a separate entity which acts of behalf of a sponsor 18, which can also be an FI such as a bank. Each biller 16 can be of any billing institution type such as, for example, a local telephone company, a local electric company, a retail outlet, or a national long distance telephone company.

[0004] Each biller 16 provides customer-related invoice data to the aggregator 14. The aggregator 14 serves as an intermediary between each biller 16 and the customer 12 by providing bill presentment directly to the customer 12, potentially on behalf of the sponsor 18.

[0005] There are two variants of the aggregation model 10 resulting from the ownership, or “branding”, of the presentation experience and the communication channel between the aggregator 14 and the customer 12. In one variant, the aggregator 14 may offer aggregator branding, thus totally owning both the presentation experience and the communication channel between the aggregator 14 and the customer 12. In the other variant, the aggregator 14 may offer sponsor-branding, thus staying “behind the scenes” in terms of the presentation experience and supporting the communication channel between the aggregator 14 and the customer 12 on behalf of the sponsor 18.

[0006] The second prevalent model for electronic bill presentment is a biller direct model 20, which is shown in FIG. 2. In its simplest form, the biller direct model 20 includes a customer 12 and at least one biller 16. In the biller direct model 20, each biller 16 retains the customer-related invoice data and the full relationship with the customer 12 (i.e., the presentation experience and the communication channel). The customer 12 may have software for providing a capability similar to Web browser bookmarking so as to allow easy navigation between billers, and thus some level of virtual aggregation. However, there is no actual aggregation such as with the aggregator 14 of the aggregation model 10 described above.

[0007] The above-described models present a dichotomy between a sponsor-centric view and a biller-centric view of bill presentment. That is, the aggregation model 10 allows the aggregator 14 and/or the sponsor 18 to use customer-related invoice data, bill presentment, and the communication channel between the aggregator 14 and the customer 12 for cross-selling or other peripheral services. The biller direct model 20, on the other hand, insures that control of customer-related invoice data, bill presentment, and the communication channel between the biller 16 and the customer 12 remains with the biller 16.

[0008] Also, neither of the above-described models adopt a truly customer-centric view. That is, neither of the above-described models allow a customer 12 to interact directly with individual billers 16 while retaining the benefits of interacting with a single aggregator 14 such as, for example, the ability to retain a single authentication and log-in procedure and a common bill presentation framework. Further, neither of the above-described models allow a customer 12 to retain the benefits of interacting with a single aggregator 14 while allowing the aggregator 14, billers 16, and sponsor 18 to retain certain preferences such as, for example, the ability to retain control of customer-related data and a communication channel with each customer 12. Accordingly, it would be desirable to provide a distributed data accessing technique which addresses the above-mentioned shortcomings of the above-described models.

[0009] One object of the present invention is to provide a distributed data accessing technique that allows a customer to interact directly with individual billers while retaining the benefits of interacting with a single aggregator.

[0010] Another object of the present invention is to provide a distributed data accessing technique that allows a customer to retain the benefits of interacting with a single aggregator while allowing the aggregator, billers, and sponsor to retain control of customer-related data and a communication channel with each customer.

[0011] Another object of the present invention is to provide a distributed data accessing technique that allows complete flexibility as to who is offering bill presentment: billers only, aggregator only (possibly on behalf of one or more sponsors), or some combination of the above.

[0012] Another object of the present invention is to provide a distributed data accessing technique that allows the biller greater flexibility in the presenting supplemental information, such as promotional materials, to customers as part of the electronic bill presentment and/or payment process.

[0013] The above-stated objects, as well as other objects, features, and advantages, of the present invention will become readily apparent from the following detailed description which is to be read in conjunction with the appended drawings.

[0014] In accordance with the invention, an electronic bill presentment network includes a central network station, preferably a network server, and multiple user stations, each associated with one of multiple different users. The user stations could be personal computers or other network devices. The stations may be interconnected by virtually any type of network, although preferably the stations are interconnected and communicate via the Internet.

[0015] The central network station is configured, e.g. programmed, to transmit bill availability information via the network, typically responsive to requests from the user stations. A database is beneficially provided to store the bill availability information which will be transmitted by the central network station. The database may be located on a network memory at the central station or elsewhere on the network. Preferably, the user stations transmit requests for the bill availability information and the central network station transmits the bill availability information responsive thereto. The transmitted bill availability information identifies available bills of different billers for the different users. The bill availability information may identify the available bills with or without providing bill summary information, such as the amount of each, or all, of the identified bills for a user.

[0016] Each available bill of a respective biller is available at one of multiple network addresses associated with the applicable biller. These addresses could be different network addresses at one or more network sites controlled by the biller, or different addresses at different network sites controlled by different entities other than the biller, or different addresses at a combination of biller controlled and other entity controlled network sites. The network addresses themselves and/or indicators of the applicable address are preferably also stored in the database.

[0017] The network will typically include multiple different biller stations. Each biller station is typically associated with a respective biller, although this is not mandatory and a single station could represent multiple billers. The biller station will generally be implemented as a network server. Hence, the first network address discussed above could be a network address of the biller station associated with the applicable biller, while the second network address could be a network address associated with the central processing station.

[0018] Each user station is configured, e.g. programmed, to transmit requests, which may take the form of requests for bill availability information, to receive the transmitted bill availability information for its associated user, and to select one or more of the identified available bills. Identified available bills may be selected in order to, for example, generate a request(s) to view or pay the selected bill(s). Advantageously, each user station displays the transmitted bill availability information, and selects identified bills on the basis of received input of its associated user. Because a biller's bills are stored at more than one network address, a user station associated with a first user can be linked to a first network address associated a biller based on the selection of a bill of that biller by that user station, while another user station associated with a second user can be linked to a second network address associated with the same biller based on selection of another bill of that biller by the second user station.

[0019] Preferably, the transmitted bill availability information identifying the bill of the biller for the first user includes a hyperlink to the first network address and the availability information identifying the bill of the same biller for the second user includes a hyperlink to the second network address. In such a case, by simply clicking on the applicable bill availability information to select a bill, each user station is hyperlinked to the appropriate network address. Whether or not hyperlinks are utilized, the first user station is advantageously automatically linked to the first network address responsive to selection of the first bill, for example for viewing or payment, and the second user station is automatically linked to the second network address responsive to selection of the second bill.

[0020] According to an aspect of the invention, the information associated with the identified bill of the biller for the first user at the first network address is promotional information. On the other hand, the information associated with the identified bill of that same biller for the second user at the second network address excludes the promotional information. The promotional information could, for example, be a special offering which the biller is targeting to only certain of its customers, a survey which the biller is limiting to certain customers, a software upgrade which is required by only certain customers, or any other type of information which the biller wishes to present to only a selected portion of its customers. However, the associated information could be the bill itself, which might be presented to the first biller in a manner which provides an enriched bill presentation experience as compared to the bill presentation experience provided to the second biller and hence the network address to which a user is sent could relate primarily or even exclusively to the look and feel of the presentation.

[0021] In accordance with another aspect of the invention, each of the user stations is capable of generating a directive to view or pay a selected available bill(s) based on the bill availability information. It will be recognized that, in the case of pay directives, this will normally require that bill summary information, particularly the bill amount, be presented as part of the bill availability information. The user station can beneficially be linked, e.g. hyperlinked, to the first network address based on selecting a bill of the biller. Hence, in such an implementation the user station is linked to the first network address whether the bill itself or payment of the bill is requested by the user station during presentation of the bill availability information. In the case where the user station is linked to the first network address after a user inputs a pay bill command and hence after the user has found the bill acceptable, preferably only the promotional information, and not the full bill detail, is made available to the user station at the first network address.

[0022] According to still another aspect of the invention, the database for storing bill availability information includes identifiers of the different users along with the availability information for the bills of the different billers for the different users. The availability information for each of the available bills is associated with the identifier of one of the different users. The database also includes network location indicators. Each location indicator is associated with one or more of the different users and indicates a network location, e.g. a network address such as a URL, at which the identified available bills of one biller for those associated users are available. The locator is preferably a flag or other type indicator which is indicative of a network location different than the network location(s) at which the identified available bills of the biller for other of the users are available. However, the indicator could, if desired, be the location address itself.

[0023] It will also be understood by those skilled in the art, that the invention is easily implemented using computer software. More particularly, software can be easily programmed, using routine programming skill, based upon the description of the invention set forth herein and stored on a storage medium which is readable by a computer processor of the applicable component, e.g. a user station, a biller station or the central network station, to cause the processor to operate such that the particular component performs in the manner described above.

[0060] Referring to FIG. 3, there is shown an infrastructure diagram of a distributed database entity 30 in accordance with the present invention. The distributed database entity 30 comprises a database component 32 and a plurality of message interfaces 34–40 for facilitating communication between the database component 32 and other distributed database entities and system components. The database component 32 typically contains data that is controlled or “owned” by the controller or “owner” of the distributed database entity 30. For example, if the distributed database entity 30 is owned by a financial institution (FI) such as a bank, then the database component 32 could contain information such as checking and savings account balances. It should be noted, however, that the database component 32 can also contain data from other distributed database entities and system components, as will be described in detail below.

[0061] The plurality of message interfaces 34–40 includes an internal message interface 34, an external message interface 36, a partner message interface 38, and a customer care message interface 40. The internal message interface 34 defines messages that are used to communicate and query data between the given distributed database entity 30 and other distributed database entities, or other system components having an internal message interface. For example, in a bill presentment and payment system, communication between a banking entity and a billing entity may be required. The external message interface 36 defines messages that are used to communicate and query data between the given distributed database entity 30 and any existing system(s) that are directly related to the given distributed database entity 30. For example, an FI such as a bank can have an existing direct deposit account (DDA) system. The partner message interface 38 defines messages that are used to communicate and query data between the given distributed database entity 30 and any existing system(s) that are indirectly related to the given distributed database entity 30. For example, in a bill presentment and payment system, communication with an established billing aggregator may be necessary to satisfy customer demands. The customer care message interface 40 defines messages that are used to communicate and query data between the given distributed database entity 30 and a customer care entity. For example, in a bill presentment and payment system, a billing entity may allow a third party to access bill data in order to provide feedback to bill customers. It should be noted that all of the above-described interfaces will be described in greater detail below.

[0062] Referring to FIG. 4, there is shown a schematic diagram of a versatile electronic bill presentment and payment system 50 in accordance with the present invention. The system 50 comprises a user entity 52, an aggregator entity represented as a banking entity 54, a billing entity 56, and an electronic payment and customer service (EPCS) entity 58. It should be understood that the aggregator entity could be a portal, stock broker or other type entity if desired. For purposes of this detailed description, the user entity 52, the banking entity 54, the billing entity 56, and the EPCS entity 58 are each distributed database entities 30 as defined above. Thus, the user entity 52, the banking entity 54, the billing entity 56, and the EPCS entity 58 each has a database component 32, an internal message interface 34, an external message interface 36, a partner message interface 38, and a customer care message interface 40. It should be noted, however, that the user entity 52, the banking entity 54, the billing entity 56, and the EPCS entity 58 are not required to have a database component 32, an internal message interface 34, an external message interface 36, a partner message interface 38, and a customer care message interface 40. That is, the user entity 52, the banking entity 54, the billing entity 56, and the EPCS entity 58 are only required to have an internal message interface 34 so that communications can take place between each entity.

[0063] At this point it should be noted that, although only a single user entity 52, banking entity 54, billing entity 56, and EPCS entity 58 is shown in the system 50, it is common to have a plurality of such entities in an actual versatile electronic bill presentment and payment system in accordance with the present invention.

[0064] As previously described, an internal message interface 34 defines messages that are used to communicate and query data between distributed database entities. Thus, since the user entity 52, the banking entity 54, the billing entity 56, and the EPCS entity 58 are all distributed database entities, they all communicate through internal message interfaces 34. The communications are performed over interconnections 60, which can be electrical wire, optical fiber, or microwave-based interconnections.

[0065] At this point it should be noted that each internal message interface 34, as well as each external message interface 36, partner message interface 38, and customer care message interface 40, can be implemented using any number of existing message-based communication systems such as, for example, a TCP/IP message-based communication system running on the infrastructure of the internet. Alternatively, the internal message interfaces 34, the external message interfaces 36, the partner message interfaces 38, and the customer care message interfaces 40 could be implemented with proprietary messaging software on a private network or intranet. It should also be noted that there are no requirements as to the nature of the messaging protocol, or any middleware used to support the messaging.

[0066] The user entity 52 is typically a personal computer (PC) that is directly connected to the system 50, or is connected to the system 50 through a network server. Thus, the database component 32 associated with the user entity 52 can be located on the PC (e.g., a traditional “fat” client), or on the network server (e.g., an HTML browser client). It should be noted that the database component 32 associated with the user entity 52 can also be located in one of the other distributed database entities, which can download data to the user entity 52 (e.g., a Java client). It should also be noted that the database component 32 associated with the user entity 52 can be distributed among all three of the above-listed locations, owing to the distributed nature of each database component 32. Thus, each database component 32 should not be thought of as a single, monolithic database. Rather, each database component 32 is better described as a distributed repository of data categorized by the entity that “owns” the data.

[0067] Wherever it is located, the database component 32 associated with the user entity 52 stores data that is related to the type of user interface (UI) that is being presented to a subscriber of the system 50. For example, the database component 32 associated with the user entity 52 can store data that is related to the particular type of presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), a specific application, or a particular version. The database component 32 associated with the user entity 52 can also store data that is related to a particular computing session such as, for example, the existence of a computing session and/or the duration of a computing session. The database component 32 associated with the user entity 52 can further store subscriber authentication data, which is described in detail below.

[0068] The main function of the user entity 52 is to build a UI using data obtained from the other distributed database entities, and then present the UI to a subscriber of the system 50. The presentation of the UI to a subscriber is dependent upon the particular type of presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client). For example, a UI for a Java client requires that presentation data be downloaded from one of the other distributed database entities.

[0069] Other functions of the user entity 52 include storing certain data locally so as to facilitate off-line editing and viewing, maintaining a state in a connectionless environment (e.g., an HTTP environment), and sensing the availability of software updates and managing their subsequent application. All of these functions depend on the nature of the client (e.g., a “fat” client, an HTML browser client, or a Java client). As previously indicated, another function of the user entity 52 includes storing subscriber authentication data (e.g., a security ticket) that is used to gain access to other distributed database entities in the system 50.

[0070] The banking entity 54, which is typically an FI such as, for example, a bank, is generally viewed as a primary point of presence for a subscriber to the system 50, typically providing an appearance of aggregation to the subscriber. This view is held primarily due to the trust that consumers typically place in a bank brand, and the fact that bank customers who already bank online are also likely to want to receive bills online. Thus, in the following discussion, the banking entity 54 is assumed to be the aggregator of the system 50. It should be noted, however, that any one of the other entities could also be the aggregator of the system 50 in accordance with the present invention. There are several factors which can be used to determine aggregator status such as, for example, market clout.

[0071] The banking entity 54 typically gains access to the system 50 through a network server. Thus, the database component 32 associated with the banking entity 54 can be located in the network server. It should be noted that the database component 32 associated with the banking entity 54 can also be located in a system associated with the banking entity 54 such as, for example, a DDA system. Such a DDA system could be accessed through the external message interface 36 of the banking entity 54, as described in detail below. It should further be noted that the database component 32 associated with the banking entity 54 can also be located in one of the other distributed database entities, or be distributed among many of the above-mentioned locations, owing to the distributed nature of each database component 32.

[0072] Wherever it is located, the database component 32 associated with the banking entity 54 stores bank-specific subscriber profile data profile such as, for example, subscriber names and addresses and subscriber account numbers. The database component 32 associated with the banking entity 54 can also store account information such as, for example, static account information (e.g., lease rate, principle), and dynamic account information (e.g., balance). The database component 32 associated with the banking entity 54 can further store profile data specifically associated with the FI such as, for example, graphics, business rules, banking-related transaction histories, and aggregation relationships such as those between the FI and billers.

[0073] Since it is likely that the system 50 will be used with existing banking systems such as, for example, an existing DDA system, one of the main functions of the banking entity 54 is the continuation of current banking and bill payment functionality including the maintaining of customer profiles and already existing interfaces. In its role as aggregator, the banking entity 54 also provides data to the user entity 52 to be used for the creation of a navigation portion of a UI. For an HTML browser client, this data would be used to create a navigation frame, but not a content specific frame. It should be noted that the banking entity 54 can also provide data to the user entity 52 to be used for the creation of a UI for traditional banking and bill payment.

[0074] Since the banking entity 54 is generally viewed as the primary point of presence for a subscriber to the system 50, the banking entity 54 also functions as the likely, but not exclusive, entry point for subscriber sign-on. Thus, the banking entity 54 typically controls the sign-on and authentication procedures for subscribers through the user entity 52. It should be noted that the banking entity 54 typically works in conjunction with the EPCS entity 58 in controlling the authentication procedure, as described in detail below.

[0075] Another function of the banking entity 54 includes tracking bank related events and storing them in an event tracking database, which is typically associated with the EPCS entity 58, as also described in detail below.

[0076] The billing entity 56 is typically a biller such as, for example, a utility company. The billing entity 56 typically gains access to the system 50 through a network server. Thus, the database component 32 associated with the billing entity 56 can be located in the network server. It should be noted that the database component 32 associated with the billing entity 56 can also be located in a system associated with the billing entity 56 such as, for example, a legacy billing system. Such a legacy billing system could be accessed through the external message interface 36 of the billing entity 56, as described in detail below. It should further be noted that the database component 32 associated with the billing entity 56 can also be located in one of the other distributed database entities, or be distributed among many of the above-mentioned locations, owing to the distributed nature of each database component 32.

[0077] Wherever it is located, the database component 32 associated with the billing entity 56 stores biller-specific subscriber profile data such as, for example, subscriber names and addresses and subscriber account numbers and types (e.g., business vs. residential phone line). The database component 32 associated with the billing entity 56 also stores billing data for use by the user entity 52 in building the UI for the subscriber. The billing data can include bill availability data, detailed billing data, ads and other cross-sale displays and links, and bill payment terms and conditions.

[0078] The database component 32 associated with the billing entity 56 can also store biller transaction history such as, for example, bill data manipulation (e.g., viewing, searching, sorting), and cross-sell events. The database component 32 associated with the billing entity 56 can further store biller profile data such as, for example, graphics, business rules, and relationships with aggregators such as banks.

[0079] The main function of the billing entity 56 is to provide billing data to the user entity 52 for use in creating the UI for the subscriber. The billing entity 56 also provides bill availability data to an aggregator database, whether it is located in the banking entity 54, the EPCS entity 58, or another entity, to provide notice of bill availability to subscribers. The billing entity 56 can also access legacy billing systems through the external message interface 36 of the billing entity 56, as indicated above.

[0080] Another function of the billing entity 56 includes tracking biller-related events and storing them in an event tracking database, which is typically associated with the EPCS entity 58, as described in detail below.

[0081] The EPCS entity 58 can generally be described in terms of a data processing system 70, such as shown in FIG. 5. The data processing system 70 preferably comprises at least one processor (P) 72, memory (M) 74, and input/output (I/O) interface 76, which are connected to each other by a bus 78, for implementing the functions of the EPCS entity 58, as described in detail below.

[0082] Referring again to FIG. 4, the EPCS entity 58 typically gains access to the system 50 through a network server. Thus, the database component 32 associated with the EPCS entity 58 can be located in the network server. It should be noted that the database component 32 associated with the EPCS entity 58 can also be located in a system associated with the EPCS entity 58 such as, for example, a legacy aggregating system. Such a legacy aggregating system could be accessed through the external message interface 36 of the EPCS entity 58, as described in detail below. It should further be noted that the database component 32 associated with the EPCS entity 58 can also be located in one of the other distributed database entities, or be distributed among many of the above-mentioned locations, owing to the distributed nature of each database component 32.

[0083] Wherever it is located, the database component 32 associated with the EPCS entity 58 stores bill payment-specific subscriber profile data such as, for example, subscriber names and addresses, subscriber DDA account numbers, and subscriber credit ratings. The database component 32 associated with the EPCS entity 58 also stores bill payment warehouse data such as, for example, user-specific payees, single occurrence payments, and recurring payments/models.

[0084] As previously described, both the banking entity 54 and the billing entity 56 track and store events in an event tracking database. This event tracking database is typically located in the database component 32 associated with the EPCS entity 58. The event tracking data that is stored typically comprises event summaries and links to other databases, perhaps residing at other entities, which provide event details and/or an audit trail.

[0085] The database component 32 associated with the EPCS entity 58 also stores bill payment transaction histories, and system subscriber profile data such as, for example, metadata about subscribers and metadata about subscribers' relationships to other entities (e.g., a list of billers that a subscriber has enabled). The database component 32 associated with the EPCS entity 58 further stores billing-related profile information on the system aggregator and billers such as, for example, metadata about billing arrangements (e.g., flat rate, per subscriber, event-driven, etc.), and aggregation data such as, for example, new bill availability and messages or special announcements available from the billing entity 56. The database component 32 associated with the EPCS entity 58 still further stores security data such as, for example, required sign-on information and macro-level authorizations. The database component 32 associated with the EPCS entity 58 additionally stores customer service data such as, for example, FAQ's, FI and biller contact information, and problem resolution data.

[0086] The EPCS entity 58 is the glue that holds the distributed database entities together. The EPCS entity 58 accomplishes this by functioning as an integration agent by maintaining bill payment profiles and warehouse data, aggregating bill availability and status data (but typically not bill content or presentation), and maintaining an event tracking database (or audit trail) that can be accessed by all of the database entities. Also, in order to facilitate a single point of sign-on, the EPCS entity 58 functions as the authentication gate keeper. This does not mean to imply that the EPCS entity 58 necessarily maintains user identification numbers and/or passwords. However, it does imply that the EPCS entity 58 accepts sign-on requests and may, if desired, dole out authentication “tickets” in response, in conjunction with the banking entity as described above. Note that the aggregator entity, e.g. the bank entity, may choose to take total responsibility for authentication of the user; in which case, the EPCS entity 58 trusts the aggregator entity to verify the user credentials.

[0087] It should be noted that, like user identification numbers and passwords, other data elements, like event details, may end up being virtually aggregated by the EPCS entity 58, but may still physically reside in a distributed manner across several of the database entities.

[0088] It should also be noted that the EPCS entity 58 may also route e-mail messages to and from the various database entities, as well as store e-mail messages sent to and from the various database entities.

[0089] As previously described, an internal message interface 34 defines messages that are used to communicate and query data between distributed database entities. As also previously described, each internal message interface 34 can be implemented using any number of existing message-based communication systems, or with proprietary messaging software on a private network or intranet. Furthermore, the message specification or file format can be either standard (i.e., open) or proprietary. With this mind, the following types of messages are examples of messages which may be employed to implement an internal message interface 34 in accordance with the present invention.

[0090] Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), the user entity 52 may need to process an internal message to store a security ticket for later use in gaining access to other distributed database entities in the system 50. The user entity 52 may also need to process an internal message to update any resident software. The user entity 52 may further need to process an internal message containing various types of information (assuming a push model). The user entity 52 may additionally need to process internal e-mail messages such as, for example, those for receiving data from other database entities.

[0091] The banking entity 54 will process an internal message to add/update/delete/retrieve FI branding information, as well as an internal message to add/update/delete an entry from a list of billers that have been aggregated. The banking entity 54 will also process an internal message to activate a subscriber for home banking via a messaging protocol, which can be an existing messaging protocol such as, for example, OFX or a batch process. The banking entity 54 will further process an internal message to query/update bank subscriber profile data for purposes of customer care. The banking entity 54 will still further process an internal message to query bank transaction history for customer care and for linking to the event tracking database. The banking entity 54 will still further process an internal message to retrieve a list of billers available under the FI sponsor umbrella. An alternative to this is to place the list of billers available under the FI sponsor umbrella in an aggregation database. However, placing the list of billers available under the FI sponsor umbrella allows the EPCS entity 58 to tailor the list by FI sponsor. The banking entity 54 will additionally process internal e-mail messages such as, for example, those for sending data to other database entities, receiving data from other database entities, and broadcasting data to other database entities.

[0092] The billing entity 56 will process an internal message to add/update/delete/retrieve biller branding information, as well as an internal message to activate a subscriber for electronic bill presentment via a messaging protocol, which can be an existing messaging protocol such as, for example, OFX or a batch process. The billing entity 56 will also process an internal message to retrieve bill availability data, retrieve bill detail data, and retrieve bill presentation specifications or content. For example, the retrieved data could be URL links to ads and notices, HTML data, or OFX data. The billing entity 56 will further process an internal message to query/update biller subscriber profile data for purposes of customer care. The billing entity 56 will still further process an internal message to query biller transaction history for customer care and for linking to the event tracking database. The billing entity 56 will additionally process internal e-mail messages such as, for example, those for sending data to other database entities, receiving data from other database entities, and broadcasting data to other database entities.

[0093] The EPCS entity 58 will process internal event tracking messages. Such event tracking messages are used to gain access to two types of information in the event tracking database: summary data and a link to another database entry that can provide more detail. Such detail includes subscriber enrollment data, subscriber service activation data (e.g., biller, bill payment, banking, etc.), sign-on data, bill availability data, bill viewed data, bill payment generated data (optionally associated with presented bill data), subsequent bill payment events data (e.g., submitted, processed, failed, cleared, remittance received by biller, etc.), cross-sell events data (e.g., ad/offer viewed, ad/offer clicked, product/service purchased), terms & conditions viewed data, email created/read/deleted data.

[0094] The EPCS entity 58 will also process an internal messages related to subscriber profile data such as, for example, to add/modify/delete/read subscriber profile data, often as a function of the events listed above (e.g., enrollment, activation, etc.).

[0095] The EPCS entity 58 will also process internal security messages. Such internal security messages may relate to authentication, which result in the EPCS entity 58 issuing a security ticket. It should be noted that an authentication request does not have to come as a result of a subscriber “surfing” to the network server of the banking entity 54. It may be initiated if a subscriber tries to gain access to the billing entity 56, and thereby not even contacting the banking entity 54. The point being that with a security ticket a subscriber is generally allowed to freely traverse any database entity in the system 50 without going through repeated sign-on procedures.

[0096] An internal security message may also relate to macro-level authorization, wherein a security ticket may contain the credentials to allow a subscriber access to a particular billing entity, but doesn't address micro-level authorization issues such as allowed operations.

[0097] An internal security message may also relate to getting a security ticket without authentication. Such a message will originate from a trusted party (e.g., an FI performing its own authentication). Therefore, a security ticket is provided without performing an authentication.

[0098] It should be noted that the use of a security ticket enables, but does not mandate, a single sign-on procedure. In other words, a database entity such as, for example, the billing entity 56 may, for whatever reason, require additional authentication information.

[0099] The EPCS entity 58 will further process internal messages relating to aggregation data. For example, an EPCS entity 58 will process an internal message to create a link to summary or detailed bill information, or to create a link to message, notice, ad, or some other kind of non-bill information that is available from the billing entity 56.

[0100] The EPCS entity 58 will still further process an internal message to query/update bill payment transaction history for purposes of customer care.

[0101] The EPCS entity 58 will additionally process internal e-mail messages such as, for example, those associated with routing e-mail, picking-up e-mail, and querying and e-mail mailbox.

[0102] The EPCS entity 58 may also process internal messages related to data mining. Such messages are handled very carefully with respect to privacy, perhaps even providing an ACL or other mechanisms to ensure privacy. The results of such messages may be delivered out of band (e.g., by batch).

[0103] As previously described, an external message interface 36 defines messages that are used to communicate and query data between a given distributed database entity 30 and any existing system(s) that are directly related to the given distributed database entity 30. As also previously described, each external message interface 36 can be implemented using any number of existing message-based communication systems, or with proprietary messaging software on a private network or intranet. Furthermore, the message specification or file format can be either standard (i.e., open) or proprietary.

[0104] Referring to FIG. 6, there is shown a schematic diagram of the versatile electronic bill presentment and payment system 50, along with some associated directly related systems. The associated directly related systems comprise a desktop database 80, a DDA system 82, a legacy billing system 84, and a legacy remittance system 86. The communications between the various database entities and their associated directly related systems are performed over interconnections 88, which can be electrical wire, optical fiber, or microwave-based interconnections.

[0105] Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), the user entity 52 may need to process an external message in order to communicate with an existing system such as, for example, the desktop database 80. To support such a legacy system, it may be necessary to implement the external message interface 36 of the user entity 52 in the context of an existing, and possibly extended, protocol specification, such as Gold, NPC, or OFX.

[0106] The banking entity 54 will process external messages to and from an existing system such as, for example, the DDA system 82 in order to query and update information such as, for example, subscriber profile data, subscriber account data, out-of-band (e.g., ATM) account activity, and statement history. It's also conceivable that the banking entity 54 would need to interface with other banking systems (e.g., stops). Thus, the external message interface 36 of the banking entity 54 is a key feature of the versatile electronic bill presentment and payment system 50.

[0107] The billing entity 56 will process external messages to and from an existing system such as, for example, the legacy billing system 84 in order to query and update information such as, for example, subscriber profile data, subscriber account data, account activity, and statement history. Most of this data is industry, if not biller, specific. Thus, the external message interface 36 of the billing entity 56 is a key feature of the versatile electronic bill presentment and payment system 50.

[0108] The EPCS entity 58 will process external messages to and from an existing system such as, for example, the legacy remittance system 86. The legacy remittance system 86 could be, for example, ACH, RPP, RPS, or Direct Send.

[0109] As previously described, a partner message interface 38 defines messages that are used to communicate and query data between a given distributed database entity 30 and any existing system(s) that are indirectly related to the given distributed database entity 30. As also previously described, each partner message interface 38 can be implemented using any number of existing message-based communication systems, or with proprietary messaging software on a private network or intranet. Furthermore, the message specification or file format can be either standard (i.e., open) or proprietary.

[0110] Referring to FIG. 7, there is shown a schematic diagram of the versatile electronic bill presentment and payment system 50, along with some associated indirectly related systems. The associated indirectly related systems comprise a personal finance system 90, a banking system 92, an established billing aggregator 94, and an alternative bill presentment and payment system 96. The communications between the various database entities and their associated indirectly related systems are performed over interconnections 98, which can be electrical wire, optical fiber, or microwave-based interconnections.

[0111] Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), the user entity 52 may need to process a partner message in order to communicate with a partner such as, for example, the personal finance system 90. The personal finance system 90 could be, for example, a personal financial manager (PFM) software package such as, for example, Quicken or Money.

[0112] The banking entity 54 will process partner messages to and from a partner such as, for example, the banking system 92.

[0113] The billing entity 56 will process partner messages to and from a partner such as, for example, the established billing aggregator 94. Such a partner relationship may be required if a large group of subscribers are using the established billing aggregator 94, and thereby have the leverage to demand that all of their bills come through the established billing aggregator 94. The established billing aggregator 94 is essentially treated as a proxy for the billers that it represents. Thus, subscribers to the established billing aggregator 94 will have equal footing as subscribers to the present system 50. This means that subscribers to the established billing aggregator 94 will receive the same event tracking, customer service, and payment processing functionality as subscribers to present system 50. Of course, to gain the additional functionality provided by the present system 50, the established billing aggregator 94, or someone acting on their behalf, will need to provide the same programming support that is required of any biller participating in the present system 50.

[0114] To present a bill generated by the established billing aggregator 94, the present system 50 would, for example, receive bill availability data and the URL of a web server of the established billing aggregator 94, and the billing entity 56 would then point to the web server of the established billing aggregator 94 to get an HTML presentation of detailed bill data. In this scenario, the partner message interface 38 would be essentially the same as an internal message interface 34, but possibly with added bulk transfer capability.

[0115] The EPCS entity 58 will process partner messages to and from a partner such as, for example, the alternative bill presentment and payment system 96. Such a partner relationship may be required if a billing entity 56 has a subscriber base that is split between using the present system 50 and the alternative bill presentment and payment system 96. In such a scenario, the present system 50 could function as a billing aggregator for the alternative bill presentment and payment system 96, and vice-versa. However, the alternative bill presentment and payment system 96 and its subscribers would not receive any of the benefits of the messaging functionality provided by the present system 50. Only the minimum amount of functionality would be provided. That is, the partner message interface 38 would only provide what is required to present bills through the alternative bill presentment and payment system 96, and not offer any of the advantages provided by the present system 50. The goal being to have the billing entity 56 encourage all of its subscribers to access bills through the present system 50.

[0116] It should be noted that the EPCS entity 58 will typically require the capabilities of a billing entity 56 in order to present bills to and from the alternative bill presentment and payment system 96.

[0117] As previously described, a customer care message interface 40 defines messages that are used to communicate and query data between a given distributed database entity 30 and a customer care entity. As also previously described, each customer care message interface 40 can be implemented using any number of existing message-based communication systems, or with proprietary messaging software on a private network or intranet. Furthermore, the message specification or file format can be either standard (i.e., open) or proprietary.

[0118] Referring to FIG. 8, there is shown a schematic diagram of the versatile electronic bill presentment and payment system 50, along with some associated customer care entities. The associated customer care entities comprise a user entity self service center 100, a banking entity customer service center 102, a billing entity customer service center 104, and an EPCS customer service center 106. The communications between the various database entities and their associated customer care entities are performed over interconnections 108, which can be electrical wire, optical fiber, or microwave-based interconnections.

[0119] Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), the user entity 52 may need to process a customer care message in order to communicate with a customer care entity such as, for example, the user entity self service center 100. The user entity self service center 100 could be, for example, a self service diagnostic tool.

[0120] The banking entity 54 will process customer care messages from a customer care entity such as, for example, the banking entity customer service center 102. A customer care message may be a request for data or a request to modify existing data. The banking entity 54 will process such customer care messages by providing the requested data or providing a confirmation that the existing data has been modified, respectively, to the banking entity customer service center 102. The banking entity customer service center 102 could be, for example, a third party telemarketing group that is allowed access to banking and overall system data in order to provide feedback to system subscribers.

[0121] The billing entity 56 will process customer care messages from a customer care entity such as, for example, the billing entity customer service center 104. A customer care message may be a request for data or a request to modify existing data. The billing entity 56 will process such customer care messages by providing the requested data or providing a confirmation that the existing data has been modified, respectively, to the billing entity customer service center 104. The billing entity customer service center 104 could be, for example, a third party telemarketing group that is allowed access to billing and overall system data in order to provide feedback to system subscribers.

[0122] The EPCS entity 58 will process customer care messages from a customer care entity such as, for example, the EPCS entity customer service center 106. A customer care message may be a request for data or a request to modify existing data. The EPCS entity 58 will process such customer care messages by providing the requested data or providing a confirmation that the existing data has been modified, respectively, to the EPCS entity customer service center 106. The EPCS entity customer service center 106 could be, for example, a third party telemarketing group that is allowed access to event and overall system data in order to provide feedback to system subscribers.

[0123] It should be noted that all of the customer care entities described above could be consolidated into a centralized customer service center 110, as shown in FIG. 9. In such a scenario, each of the database entities would process customer care messages to and from the centralized customer service center 110 similar to as described above. The communications between the various database entities and the centralized customer service center 110 would be performed over interconnections 112, which can be electrical wire, optical fiber, or microwave-based interconnections.

[0124] Referring to FIGS. 10–15, there are shown flowchart diagrams of data and message flows between the various entities within the system 50. These flowchart diagrams assume that the user entity 52 is an HTML browser client, the banking entity 54 is the primary point of presence for a subscriber to the system 50, the billing entity 56 controls bill presentment, and the EPCS entity 58 controls bill payment.

[0125] In FIG. 10, a subscriber at the user entity 52 accesses the web site of the banking entity 54 in step 200. In return, the banking entity 54 presents a branded interface to the user entity 52, including a sign-on request prompt in step 202. FIG. 16 shows an example of such a branded interface 120, wherein the sign-on request prompt includes a username field 122 and a password field 124.

[0126] In FIG. 11, the user entity 52 submits a sign-on request with authentication credentials in steps 204. The banking entity 54 messages the EPCS entity 58 with the authentication credentials of the subscriber and the event is logged in step 206. The EPCS entity 58 provides a security ticket to the banking entity 54 in step 208. The banking entity 54 delivers the security ticket to the user entity 52 and presents its “home page” to user entity 52 in step 210. FIG. 17 shows an example of such a home page 130, which includes a “view bills” icon 132, a “view checking account” icon 134, and a “view savings account” icon 136.

[0127] It should be noted that either the EPCS entity 58 or the banking entity 54 could perform the authentication procedure, but in either case the event is still logged in the event tracking database.

[0128] In FIG. 12, the subscriber selects the “view bills” icon 132 in step 212. The banking entity 54 messages the EPCS entity 58 with an aggregation data request and the event is logged in step 214. The EPCS entity 58 presents aggregation data of new bill availability to user entity 52 in step 216. FIG. 18 shows a first modified home page 140 having an EPCS entity frame 142 presenting the new bill availability data, which includes an “electric bill” icon 144, a “gas bill” icon 146, a “phone bill” icon 148, a “cable bill” icon 150, a “credit card bill” icon 152, and an “all bills” icon 154 which allows all bills to be presented simultaneously, albeit in separate frames.

[0129] In FIG. 13A, the subscriber selects the “gas bill” icon 146 and is linked to the billing entity 56 along with the security ticket in step 218. The billing entity 56 messages the EPCS entity 58 to log the “view bill” request event in step 220. The billing entity 56 presents detailed bill data to the user entity 52 in step 222. FIG. 19 shows a second modified home page 160 having a billing entity frame 162 presenting the detailed bill data, which includes the subscriber name, subscriber address, account number, usage, and cost, and a “pay bill” icon 164.

[0130] In FIG. 14, the subscriber selects the “pay bill” icon 164 and messages the EPCS entity 58 with a forward dated pay bill request so the event is logged in step 224. The EPCS entity 58 messages the billing entity 56 with a pay bill request notification along with a bill identification number in step 226.

[0131] In FIG. 15, the EPCS posts a debit with the banking entity 54 and the event is logged in step 228. The EPCS entity 58 then remits a payment to the billing entity 56 and the event is logged in step 230.

[0132] FIG. 13B can be substituted for FIG. 13A in the above-described sequence of flowchart diagrams to show how detailed bill data can be provided by the established billing aggregator 94 through the partner message interface 38 of the billing entity 56. In FIG. 13B, the subscriber again selects the “gas bill” icon 146 and is linked to the billing entity 56 along with the security ticket in step 232. The billing entity 56 again messages the EPCS entity 58 to log the “view bill” request event in step 234. However, in this case, detailed bill data is available only from the established billing aggregator 94. Thus, the billing entity 56 accesses the established billing aggregator 94 through its partner message interface 38 in step 236. In response, the established billing aggregator 94 provides detailed bill data to the billing entity 56 in step 238. The billing entity 56 then presents the detailed bill data to the user entity 52 in step 240.

[0133] It should be noted that, in an alternative embodiment, the established billing aggregator 94 could present the detailed bill data directly to the user entity 52.

[0134] FIG. 13C can be substituted for FIG. 13A in the above-described sequence of flowchart diagrams to show how detailed bill data can be provided by the alternative bill presentment and payment system 96 through the partner message interface 38 of the EPCS entity 58. In FIG. 13C, the subscriber selects the “gas bill” icon 146 and is linked back to the EPCS entity 58 along with the security ticket and the event is logged in step 242. In this case, detailed bill data is available only from the alternative bill presentment and payment system 96. Thus, the EPCS entity 58 accesses the alternative bill presentment and payment system 96 through its partner message interface 38 in step 244. In response, the alternative bill presentment and payment system 96 provides detailed bill data to the EPCS entity 58 in step 246. The EPCS entity 58 then presents the detailed bill data to the user entity 52 in step 248.

[0135] It should be noted that, as previously described, the EPCS entity 58 will typically require the capabilities of a billing entity 56 in order to present bills to and from the alternative bill presentment and payment system 96. Alternatively, it should be noted that detailed bill data can be provided by the alternative bill presentment and payment system 96 through the partner message interface 38 of the billing entity 56 in a manner similar to that as described in FIG. 13B.

[0136] Referring to FIG. 20, there is shown a flowchart diagram of data and message flows between the centralized customer service center 110 and the various entities within the system 50. A subscriber 170 contacts the centralized customer service center 110 regarding a bill payment in step 250. The centralized customer service center 110 accesses the event tracking database in the EPCS entity 58 to see if a view bill, pay bill, remit payment, or debit posting event has been logged in step 252. If more detailed information regarding, for example, the posting of a debit for a bill, the centralized customer service center 110 can access the database component 32 associated with the banking entity 54, as shown in step 254. Similarly, if more detailed information regarding, for example, the remitting of a payment for a bill, the centralized customer service center 110 can access the database component 32 associated with the billing entity 56, as shown in step 256. It should be noted that, although not shown, the EPCS entity 58 can log all of the above-described accesses performed by centralized customer service center 110.

[0137] As is apparent from the foregoing description, the system 50 allows a subscriber to interact directly with individual billers while retaining the benefits of interacting with a single aggregator such as, for example, the ability to retain a single authentication and log-in procedure and a common bill presentation framework. The system 50 also allows a subscriber to retain the benefits of interacting with a single aggregator while allowing the billers and banks to retain certain preferences such as, for example, the ability to retain control of subscriber-related data and a communication channel with each subscriber.

[0138] Billers often include promotional information, which could include any type of supplemental information with paper bills. Materials containing such information are sometimes referred to as “envelope stuffers”. In a paper world, it is very difficult to selectively provide such supplemental information with only the bills mailed to those customers who are most likely to take advantage of the supplemental information. It is also very difficult to selectively avoid mailing supplemental information with bills to individual customers, e.g. to avoid providing a particular envelop stuffer to some selected group of customers.

[0139] For example, a telephone or other company may have certain customers currently using a low level of services. The company's market research may show that these customers are likely to increase their usage based upon a certain type of offer, e.g. a discount plan. The company may also have other customers who are already at a high level of usage. The company's market research may also show that these latter customers are likely to remain at a high level of usage without the discount plan.

[0140] In such a case, the company wants to make the promotional offering to the low level users but not to the high level users. Since the market research shows that the high level users will remain high level users without the offer, little, if anything, is to be gained and much could be lost by providing the discount offer to the existing high level users. Accordingly, the present invention allows the high level users to be advantageously serviced through a third party, such as the EPCS, or at a biller network address which is different than a biller network address at which the low level users are serviced. If the servicing is in the nature of bill presentment services, only low level users receive a bill presentation enriched with the special promotional offering. Because only a portion of the customers are serviced from the site offering the enriched bill presentment, greater resources can be focussed on providing a more satisfying bill presentation experience to the lower level users, and hence to the users most likely to increase usage based on the promotion. The system therefore allows resources to be allocated so as to provide the greatest potential benefit to the company.

[0141] FIG. 21 depicts the message flow in an alternative electronic billing system implementation which provides greater flexible in the biller control of the servicing of its customers. More particularly, the system allows the biller to select those users who will be directed to a first network address which is preferably, although not necessarily, one controlled by the biller, and those users who will be directed to some other network address, e.g. a different network address controlled by the biller or some other entity, for servicing. For example, different users may be directed to different addresses and/or entities for the presentment of a detailed bill and/or supplemental information such as special offerings. Hence, this alternative system allows billers to choose which users will be directed, for example, to a biller's network address and provided with an enriched presentation experience, and which users will be serviced by the EPCS or some other entity, or at some other biller network address and provided a somewhat different presentment experience.

[0142] The database component 32 associated with the billing entity 56 stores a flag or other indicator, sometimes referred to as a “magnet”, in the biller-specific subscriber profile data which indicates those users which are to be directed to, for example, the biller for presentment of bills or promotional information that supplements the bill. Users which are not flagged might be presented bills and/or general promotional information by the EPCS, or some other entity, such as a separate bill aggregator or alternative bill presentment and payment system. Alternatively, these non-flagged users could be presented bills and/or general promotional information by the biller, but from a network address different than the address used to present bills and/or special promotional information to the flagged users. The database component 32 associated with the billing entity 56 generally continues to store the billing data for both the flagged and non-flagged users. However, the billing entity also provides the billing data for the non-flagged users to the database of another entity if this other entity will be presenting bills to non-flagged users.

[0143] For example, the billing data for non-flagged users could be located at the EPCS entity 58, as has been previously discussed, if the EPCS will be presenting bills to non-flagged users. In such a case, the billing data for the non-flagged users is stored in the database component 32 of the EPCS entity 58. Whether or not the EPCS 58 will be presenting bills to non-flagged users, the database component 32 of the EPCS 58 stores one or more flags or other indicators in the biller-specific subscriber profile data to indicate that certain users are to be presented bills and/or promotional information at other than a primary biller network address. Of course, if desired, the flags could be used to indicate those users which are to be presented bills and/or promotional information at the primary biller address. In either case, the flags or other indicators stored in the EPCS database component 32 are used to ensure that certain users are presented bills and/or promotional information by the EPCS or some other entity, or at an alternate biller address, and other users are presented bills and/or promotional information at the primary biller or other entity address.

[0144] Users which are not flagged for the applicable biller in the EPCS database 32 are, in the preferred implementation, directed to the applicable biller primary network address for presentment of bills and/or promotional information. However, as noted above, these users could, if desired, be directed to an address controlled by some other entity. Users which are flagged in the EPCS database 32 are directed to the EPCS 58 or some other entity, or perhaps a different biller network address than the address to which the non-flagged users are directed, for presentment of bills and/or promotional information. In the preferred implementation, users which are not flagged for any billers are always directed to the applicable billers for presentment of bills and/or promotional information. Users which are flagged for some billers and not flagged for other billers are presented bills and/or promotional information of the billers for which they are flagged by the EPCS or at an alternate biller address, and are presented bills and/or promotional information of the billers for which they are not flagged by the billers themselves.

[0145] FIG. 22A depicts a database 1170 which is stored in the database component 32 associated with the EPCS 58. The database 1170 includes a user list 1172, listing users A, B, C . . . n, and a biller list 1174, listing billers 1, 2, 3 . . . n. For each user, the database stores bill availability information 1176. The information 1176 may simply indicate that a bill is available or may include bill summary information, such as the total bill amount. For each available bill, a flag or other indicator 1178 is optionally provided. The flag 1178 identifies the bills of those customers which are to be directed to a secondary network address for presentation of requested bills and/or promotional information of a particular biller. The flag information may be provided to the EPCS database at the time the bill availability information is transmitted to the database by the biller. Such transmissions typically occur off-line, e.g. in a non-real-time batch transmission, but could, if desired, occur in an on-line session between the biller and the EPCS. Even in this latter case, however, the session between the biller and the EPCS would typically occur asynchronously, i.e. as a separate session, from the session between the consumer and the EPCS. If desired, the flag could be provided in a communication separate from that transmitting the bill availability information. This may be advantageous if the network address to which the customer will be sent for bill presentment and/or presentation of promotional informaion will not change from billing cycle to billing cycle.

[0146] As shown in FIG. 22A, user A has bills available from billers 1 and 2. The biller 1 bill availability information is associated with a flag. Hence, as will be discussed further below, should user A request detailed bill information relating to the biller 1 bill or request payment of the bill without first requesting to view the bill, user A will be directed to a network address other than a primary network address of biller 1 for presentment of the bill and/or promotional material. On the other hand, should user A request detailed bill information relating to the biller 2 bill or request payment of the bill without first requesting to view the bill, user A will be directed to the primary network address of the biller 2 for presentment of the bill and/or promotional information.

[0147] User B has bills available from billers 1 and 3. The bill availability information for these bills is not associated with a flag. Accordingly, should user B request detailed bill information relating to the bill of biller 1 or biller 3 or request payment of the bill without first requesting to view the bill, user B will be directed to the primary network address of the applicable biller for presentment of the bill.

[0148] User C has bills available from billers 2 and 3. The biller 2 bill availability information is associated with a flag. Hence, should user C request detailed bill information relating to the biller 2 bill or attempt to pay the bill without first viewing the bill detail, user C will be directed to a network address other than a primary network address of biller 2 for presentment of the bill and/or promotional information. On the other hand, should user C request detailed bill information relating to the biller 3 bill or attempt to pay the bill without first viewing the bill detail, user C will be directed to the primary network address of biller 3 for presentment of the bill and/or promotional information.

[0149] It should be noted that none of the bill availability information associated with bills of biller 3 are shown to be flagged. This reflects a desire by biller 3 to have all its customers sent to its primary bill presentation address to view detailed bill information and/or promotional information.

[0150] As shown in FIG. 22B, the EPCS database component 32 also stores a database 1180 of network addresses 1184 and 1186 in association with an identifier 1182 for each of the billers. As depicted, biller 1 has a primary network address at URL 1A. This address could, for example, be the address of a presentment server at the biller's network site. Biller 1 also has a secondary network address at URL 1B. This address could be a network address of a presentment server at a different entity site, e.g. at the EPCS 58, or a different presentment server at the biller's site or a different address to a single presentment server at the biller 1 site.

[0151] Biller 2 has a primary network address at URL 2A. This address could, for example, be the address of a presentment server at the biller 2 network site. Biller 2 also has a secondary network address at URL 2B. As with biller 1, this address could be a network address of a presentment server at a different entity site, or a different presentment server at the biller's site or a different address to a single presentment server at the biller 2 site.

[0152] Biller 3 has only a single network address at URL 3. This address could be the address of a presentment server at the biller's network site. Since biller 3 does not have a secondary network address, all customers of biller 3 are directed to a single presentment server for presentment of detailed bill information and/or promotional information.

[0153] It will be recognized that, if desired, the number of different secondary network addresses for a given biller identified in database 1182 could be increased to 3 or more. In such a case, different flags, each for example representing a different network address, are used in database 1170 to identify which of the multiple secondary addresses a specific customer is to be directed for electronic bill and/or promotional information presentation.

[0154] Turning back to FIG. 21, as shown the subscriber selects the “view bills” icon 1132 in step 1212. The banking, or other aggregator, entity 54 messages the EPCS entity 58 with an aggregation data request and the event is logged in step 1214. The EPCS entity 58 presents aggregation data of new bill availability to user entity 52 in step 1216.

[0155] As shown in FIG. 23A, the banking entity modified home page 1140A includes an EPCS entity frame 1142A presenting the new bill availability data for a first subscriber. FIG. 23A is similar to FIG. 18, except that the user will be hyperlinked to the biller's primary network address to obtain detailed bill data and/or promotional information from some of the billers, but will be hyperlinked to the biller's secondary network address to obtain detailed bill data and/or promotional information of other of the billers.

[0156] More particularly, the available bills shown on screen 1140A include an “electric bill” icon 1144A, a “gas bill” icon 1146A, a “phone bill” icon 1148A, a “cable bill” icon 1150A, a “credit card bill” icon 1152A, and an “all bills” icon 1154A which allows all bills to be presented simultaneously, albeit in separate frames. The electric and phone bills are shown with one or more asterisks to indicate that these bills or associated promotional material will be provided to the first subscriber by the EPCS 58 or biller 56 at a secondary biller network address, as will be described in detail below, rather than by the biller 56 at a primary biller address. The asterisk(s) would not actually appear on the screen displayed to the user but is shown here to indicate that the first subscriber has not been flagged by the billers associated with the electric and phone bills so as to aid in the understanding of the invention.

[0157] FIG. 23B is similar to FIG. 23A but is for a second subscriber. The banking entity modified home page 1140B includes an EPCS entity frame 1142B presenting the new bill availability data for the second subscriber. The available bills shown on screen 1140B include an “electric bill” icon 1144B, a “gas bill” icon 1146B, a “phone bill” icon 1148B, a “cable bill” icon 1150B, a “credit card bill” icon 1152B, and an “all bills” icon 1154B. In the case of FIG. 23B, the second subscriber will be hyperlinked to the biller to obtain his/her electric bill and/or promotional information. It should be noted that, although both the first and second subscribers are billed by the same phone company, the first subscriber is directed to the EPCS for presentation of its phone bill and/or promotional information, and the second subscriber is directed to the biller itself for presentment of its phone bill and/or promotional information. The second subscriber will also be hyperlinked to the biller to obtain the gas bill and/or associated promotional information. However, although both the first and second subscribers are billed by the same gas utility company, the biller network address to which the second subscriber will be linked is different than the biller address to which the first subscriber will be linked for presentation of their respective gas bills and/or associated promotional information. Finally, the second subscriber will also be hyperlinked to the EPCS 58 to obtain its electric bill and/or associated promotional information. Hence, in FIG. 23B, the gas and electric bills rather than the electric and phone bills, are shown with an asterisk(s) to indicate that the second subscriber has not been flagged by the electric and gas companies and that these bills and/or associated promotional information will be provided to this particular user at a secondary network address by the biller 56 or the EPCS 58, rather than by the biller 56 at a primary network address.

[0158] FIG. 23C is similar to FIG. 23A except that the banking entity modified home page 1140C includes an EPCS entity frame 1142C presenting the new bill availability data, including total bill amounts, for the first subscriber. The modified home page 1140C can be substituted for the modified home page 1140A. The available bills shown on screen 1140C include an “electric bill” icon 1144C, a “gas bill” icon 1146C, a “phone bill” icon 1148C, a “cable bill” icon 1150C, a “credit card bill” icon 1152C, and an “all bills” icon 1154C. A “pay bill” icon 1155 is also provided so that a user can request the payment of the bill amount based upon a review of only the information presented in EPCS frame 1142C. In the case of FIG. 23C, the electric and phone bills are shown with one or more asterisks, as in FIG. 23A, to indicate that the billers associated with these bills have not flagged the first subscriber. Hence, if the “view bill” icon is clicked-on the first subscriber will be hyperlinked as discussed above with reference to FIG. 23A to the appropriate entity and address to view the detailed bill information and/or associated promotional information.

[0159] As discussed above with reference to FIGS. 14 and 15, when, after reviewing billing information, detailed or otherwise, the user selects “pay bill”, the user is directed to the EPCS 58 which communicates with the applicable billing and banking entities to process the payment. To perform this function, the database component 32 associated with the EPCS 58 entity is made aware of the total amount of each available bill for a user 52. Accordingly, each billing entity 56 must provide bill summary information, including the total bill amount, for each available bill to the aggregator database, which is preferably but not necessarily located at the EPCS entity 58, as has been previously discussed. As shown, the database component 32 of the EPCS entity 58 stores bill summary information for each available bill for each user which is accessed and used by the EPCS to process payments responsive to the receipt of user initiated “pay bill” messages received directly from the user or from the user's sponsor.

[0160] In the case of FIG. 23C, the payment process can be initiated by the user directly from the bill availability information presented by the EPCS entity 58 in frame 1142C. However, as noted above, certain billers have flagged the first subscriber, thereby indicating a desire that the first subscriber be directed to those billers. Hence, as will be described further below, the system further provides the ability to direct the user to the biller or any other desired entity even in those cases where the user is offered the option of providing the pay bill instruction from the EPCS bill availability screen, such as in FIG. 23C.

[0161] In FIG. 24A, which is similar to FIG. 13A, the first subscriber selects the “gas bill” icon 1146A and is linked to a network address at the billing entity 56, with the security ticket in step 1218A. The billing entity 56 messages the EPCS entity 58 to log the “view bill” request event in step 1220A. The billing entity 56 presents detailed bill data to the user entity 52 in step 1222A.

[0162] In FIG. 24B, which is similar to FIG. 24A, the first subscriber selects the “phone bill” icon 1148B and messages the EPCS 58 for detailed billing data in step 1218B. The EPCS entity 58 messages the billing entity 56 to log the “view bill” request event in step 1220B. The EPCS entity 58 presents detailed bill data to the user entity 52 in step 1222B.

[0163] In FIG. 24C, which is similar to FIG. 24A, the second subscriber selects the “gas bill” icon 1146C and is linked to a secondary network address at the billing entity 56, with the security ticket in step 1218C. Although the billing entity 56 in FIGS. 24A and 24C represent the same gas company, the network address of the billing entity, i.e. the gas company, to which the second subscriber is linked in step 1218C is different than the network address to which the first subscriber is linked in step 1218A. Thus, in the case of the gas company, the biller retains control over all bill presentments and simply flags different users so that the EPCS will provide hyperlinks which direct different users to different biller network addresses as desired by the biller. Here again, the billing entity 56 messages the EPCS entity 58 to log the “view bill” request event in step 1220C. The billing entity 56 also presents detailed bill data to the user entity 52 in step 1222C, however, as will be described in greater detail below, the presentations made to the subscriber linked to the primary network address of the gas company and to the subscriber linked to the secondary network address of the gas company will be different.

[0164] In FIG. 24D, which is similar to FIG. 24A, the first subscriber selects, e.g. clicks-on, the “pay bill” icon 1155 after highlighting the “gas bill” in the bill summary information shown in FIG. 23C. Although, as discussed above, the payment instruction will be processed by the EPCS, the first subscriber is automatically linked to a network address at the billing entity 56, with the security ticket, in step 1218D. The billing entity 56 messages the EPCS entity 58 to log the “pay bill” request event in step 1220D. The EPCS 58 may initiate processing of the pay instruction based upon this message from the billing entity 56 or based upon some other message, as will be recognized by those skilled in the art. The billing entity 56 presents a special promotional offer to the user entity 52 in step 1222D. Hence, even though the user has not requested detailed bill information from the biller, the user is forced to the billing entity for presentation of promotional information, as may be desired by the biller, without presenting the detailed bill. It will of course be recognized that the first subscriber can be forced to any biller whose bill is shown to be available in FIG. 23C, as may be desirable under the circumstances, whenever the user clicks on the “pay bill” icon to direct payment of that biller's bill.

[0165] FIG. 25A shows a home page 1160A having a billing entity frame 1162A presenting the detailed gas bill data to the first subscriber, after a “view bill” request. The home page 1160A includes, within frame 1162A, the subscriber name, subscriber address, account number, usage, and cost, and a “pay bill” icon 1164A. As shown in FIG. 25A, billing entity frame 1162A also includes an icon 1166A which can be clicked on to present special targeted promotional information, e.g. a special discount offer, survey or software upgrade etc., to the first subscriber. The first subscriber may also be provided with other general promotional information, such offers as which are being generally made to all gas company customers. Hence, a rich presentation is provided to the first subscriber.

[0166] FIG. 25B shows a home page 1160B having an EPCS entity frame 1162B presenting the detailed phone bill data to the first subscriber, after a “view bill” request. The home page 1160B includes, within frame 1162B, the same information included in frame 1162A of FIG. 25A. However, the FIG. 25B home page 1160B does not include the special targeted information for presentation to the first subscriber. Rather, the EPCS entity frame 1162B only includes an icon 1166B which can be clicked on to present general, typically untargeted, promotional information, e.g. a general offer to install an additional phone line within a facility, to the first subscriber. Hence, a more basic presentation is provided to the first subscriber.

[0167] FIG. 25C shows a home page 1160C having a billing entity frame 1162C presenting a description of a special promotional offering by the gas company to the first subscriber, without the presentation of detailed billing information, after a “pay bill” request is entered during presentation of the bill availability information. It should be noted that the special offering could be presented with the bill even though the pay bill request has been entered, if so desired. The home page 1160C includes, within frame 1162C, a description of the special offering 1164C, a message indicating the payment is being processed, and an icon 1166C which can be clicked on to place an order for the offered product. As discussed above, a special targeted promotional offering might be described or other promotional information could, if desired, be presented to the first subscriber. The first subscriber may also be presented with a description of other offers which are being generally made to gas company customers. Hence, a rich presentation is provided to the first subscriber after a selecting “pay bill” from the EPCS presentation shown if FIG. 23C.

[0168] It will be understood that, in the case of the first subscriber, richer, targeted gas, cable and credit card bill presentations, and more basic, untargeted electric and phone bill presentations are provided by the respective billing entities 56. On the other hand, the second subscriber receives richer, targeted phone, cable and credit card bill presentations, and more basic, untargeted electric and gas bill presentations from the respective billing entities 56.

[0169] At this point it should be noted that while the foregoing detailed description was directed to an electronic bill presentment and payment technique, any number of system types can employ the distributed database entities 30 to facilitate distributed data accessing within a network in accordance with the present invention.

[0170] The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, various modifications of the present invention in addition to those described herein, will be apparent to those of skill in the art from the foregoing description and accompanying drawings. Thus, such modifications are intended to fall within the scope of the appended claims.