US6334116B1 - Technique for centrally tracking transactions in an electronic billing system - Google Patents

Abstract

A method is provided for centrally tracking transactions in an electronic billing system. The system includes multiple different billing entities, multiple different financial institute entities and multiple different user entities. Each of the multiple different billing entities is associated with a respective portion of the multiple different user entities and each of the multiple different financial institute entities is associated with a respective portion of the multiple different user entities. A message is received from any of the multiple different financial institute entities indicating a request from any of the multiple different user entities associated with the applicable financial institute entity to view billing information. The receipt of the request to view the billing information is logged in a database as first event information. A message indicative of the billing information of at least one of the multiple different billing entities associated with the applicable user entity which is available for viewing is transmitted to the applicable user entity. A message indicating a request from the applicable user entity to view the available billing information of that billing entity is received from any of the at least one of the billing entities. The receipt of the message indicating the applicable user entity request to view the billing information of the applicable billing entity is logged in the database as a second event information.

Description

This application is a continuation of application Ser. No. 09/017,169, filed on Feb. 2, 1998, now U.S. Pat No. 6,055,567.

FIELD OF THE INVENTION

The present invention relates generally to distributed data networks and, more particularly, to a distributed data accessing technique.

BACKGROUND OF THE INVENTION

There are two prevalent models for electronic bill presentment that are currently used in industry. The first is anaggregation model10, which is shown in FIG.1. In its simplest form, theaggregation model10 includes acustomer12, anaggregator14, and a plurality ofbillers16. Thecustomer12 can be, for example, an individual person, a family, or a business. Theaggregator14 can be a financial institution (FI) such as, for example, a bank. Alternatively, theaggregator14 can be a separate entity which acts of behalf of asponsor18, which can also be an FI such as a bank. Eachbiller16 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.

Eachbiller16 provides customer-related invoice data to theaggregator14. Theaggregator14 serves as an intermediary between eachbiller16 and thecustomer12 by providing bill presentment directly to thecustomer12, potentially on behalf of thesponsor18.

There are two variants of theaggregation model10 resulting from the ownership, or “branding”, of the presentation experience and the communication channel between theaggregator14 and thecustomer12. In one variant, theaggregator14 may offer aggregator-branding, thus totally owning both the presentation experience and the communication channel between theaggregator14 and thecustomer12. In the other variant, theaggregator14 may offer sponsor-branding, thus staying “behind the scenes” in terms of the presentation experience and supporting the communication channel between theaggregator14 and thecustomer12 on behalf of thesponsor18.

The second prevalent model for electronic bill presentment is a billerdirect model20, which is shown in FIG.2. In its simplest form, the billerdirect model20 includes acustomer12 and at least onebiller16. In the billerdirect model20, eachbiller16 retains the customer-related invoice data and the full relationship with the customer12 (i.e., the presentation experience and the communication channel). Thecustomer12 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 theaggregator14 of theaggregation model10 described above.

The above-described models present a dichotomy between a sponsor-centric view and a biller-centric view of bill presentment. That is, theaggregation model10 allows theaggregator14 and/or thesponsor18 to use customer-related invoice data, bill presentment, and the communication channel between theaggregator14 and thecustomer12 for cross-selling or other peripheral services. The billerdirect model20, on the other hand, insures that control of customer-related invoice data, bill presentment, and the communication channel between thebiller16 and thecustomer12 remains with thebiller16.

Also, neither of the above-described models adopt a truly customer-centric view. That is, neither of the above-described models allow acustomer12 to interact directly withindividual billers16 while retaining the benefits of interacting with asingle aggregator14 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 acustomer12 to retain the benefits of interacting with asingle aggregator14 while allowing theaggregator14,billers16, andsponsor18 to retain certain preferences such as, for example, the ability to retain control of customer-related data and a communication channel with eachcustomer12. Accordingly, it would be desirable to provide a distributed data accessing technique which addresses the above-mentioned shortcomings of the above-described models.

OBJECTS OF THE INVENTION

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.

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.

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.

Another object of the present invention is to provide a distributed data accessing technique that supports an end-to-end audit trail from the initial stages of bill presentment to the final stages of bill payment, which can serve a variety of purposes, including improved customer care.

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.

SUMMARY OF THE INVENTION

According to the present invention, a distributed data accessing technique is provided. The technique can be realized by storing, at a first network station, information identifying data which is available at a second network station. The first network station can be, for example, an electronic payment and customer service entity. The second network station can be, for example, a billing entity such as a utility company. The information identifying the data that is available at the second network station can be, for example, information which indicates that a bill is available at the second network station.

A signal is generated at the first network station. The signal represents the information identifying the available data and linking information to the second network station. The linking information can be, for example, a web site address along with some additional parameters.

The signal is transmitted to a third network station. The third network station can be, for example, a user entity such as a personal computer. The transmitted linking information is operable at the third network station to establish a network link over which the identified available data is transmittable from the second network station to the third network station. That is, the third network station can invoke the linking information so as to create, for example, a link to the web site of a utility company.

The signal is typically generated in response to a request for data. Such a request can include an identification of a user so that the user can be authenticated. The signal is then generated after the user is authenticated. The request is typically received from the third network station. The request, as well as any other events that occur between the various network stations, can be logged at the first network station. The logged events can then be accessed by an entity located outside of the network such as, for example, a centralized customer service center.

The identified available data is typically stored at the second network station. However, the identified available data can be provided to the second network station by an entity located outside of the network. Such an outside entity could be, for example, a legacy billing system or an established billing aggregator.

The first network station can receive a notification that the identified available data was transmitted from the second network station to the third network station. The identified available data is preferably transmitted from the second network station directly to the third network station over the network link. The identified available data can be transmitted from the second network station to the third network station so as to be displayed in a presentation format. The presentation format can be, for example, an internet web page or a frame of an internet web page.

In accordance with a further aspect of the invention, the identified available data can be identified available first data, the linking information can be first linking information, the network link can be a first network link, and further information identifying second data which is available at a fourth network station can be stored at the first network station. Similar to the second network station, the fourth network station can be, for example, a billing entity such as a retailer. The information identifying the second data that is available at the fourth network station can be, for example, information which indicates that a bill is available at the fourth network station.

The signal that is generated at the first network station can further represent the further information identifying the available second data and second linking information to the fourth network station. As with the first linking information, the second linking information can also be, for example, a web site address.

The signal can again be transmitted to the third network station, and the transmitted second linking information is operable at the third network station to establish a second network link over which the identified available second data is transmittable from the fourth network station to the third network station. The third network station can therefore invoke the second linking information so as to create, for example, a link to the web site of the retailer.

The signal can again be generated in response to a request for data. The request can include an identification of a user so that the user can be authenticated for use with more than one network station. That is, only a single authentication procedure is required for use with both the second and the fourth network stations. As before, the request, as well as any other events that occur between the various network stations can be logged at the first network station. The logged events can then be accessed by an entity located outside of the network such as, for example, a centralized customer service center.

The identified available second data is typically stored at the fourth network station. However, as with the second network station, the identified available second data can be provided to the fourth network station by an entity located outside of the network. Again, such an outside entity could be, for example, a legacy billing system or an established billing aggregator.

The first network station can receive a first notification that the identified available first data was transmitted from the second network station to the third network station, and a second notification that the identified available second data was transmitted from the fourth network station to the third network station. The identified available first data is preferably transmitted from the second network station directly to the third network station, and the identified available second data is preferably transmitted from the fourth network station directly to the third network station. Both the identified available first data and the identified available second data can be transmitted to the third network station so as to be displayed in a presentation format. The presentation format can be, for example, an internet web page or a frame of an internet web page. It should be noted that the identified available first data and the identified available second data can be presented in separate frames of an internet web page at the same time.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to facilitate a fuller understanding of the present invention, reference is now made to the appended drawings. These drawings should not be construed as limiting the present invention, but are intended to be exemplary only.

FIG. 1 is an aggregation model for electronic bill presentment.

FIG. 2 is a biller direct model for electronic bill presentment.

FIG. 3 is an infrastructure diagram of a distributed database entity in accordance with the present invention.

FIG. 4 is a schematic diagram of an electronic bill presentment and payment system in accordance with the present invention.

FIG. 5 is a schematic diagram of an electronic payment and customer service (EPCS) entity in accordance with the present invention.

FIG. 6 is a schematic diagram of the electronic bill presentment and payment system shown in FIG. 4, extended to include certain associated directly related systems.

FIG. 7 is a schematic diagram of the electronic bill presentment and payment system shown in FIG. 4, extended to include certain associated indirectly related systems.

FIG. 8 is a schematic diagram of the electronic bill presentment and payment system shown in FIG. 4, extended to include certain associated customer care entities.

FIG. 9 is a schematic diagram of the electronic bill presentment and payment system shown in FIG. 4, extended to include a centralized customer care entity.

FIG. 10 is a flowchart diagram showing initial sign-on data and message flows between a user entity and a banking entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 11 is a flowchart diagram showing sign-on and authentication data and message flows between a user entity, a banking entity, and an EPCS entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 12 is a flowchart diagram showing bill availability data and message flows between a user entity, a banking entity, and an EPCS entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 13A is a flowchart diagram showing billing entity presentment data and message flows between a user entity, a billing entity, and an EPCS entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 13B is a flowchart diagram showing billing aggregator bill presentment data and message flows between a user entity, a billing entity, an EPCS entity, and an established billing aggregator in the electronic bill presentment and payment system shown in FIG.4.

FIG. 13C is a flowchart diagram showing alternative system bill presentment data and message flows between a user entity, an EPCS entity, and an alternative bill presentment and payment system in the electronic bill presentment and payment system shown in FIG.4.

FIG. 14 is a flowchart diagram showing bill payment data and message flows between a user entity, an EPCS entity, and a billing entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 15 is a flowchart diagram showing bill remittance and debiting data and message flows between an EPCS entity and a billing entity and a banking entity in the electronic bill presentment and payment system shown in FIG.4.

FIG. 16 shows an example of a branded interface having a sign-on request prompt that includes a username field and a password field.

FIG. 17 shows an example of a banking entity home page, including a “view bills” icon, a “view checking account” icon, and a “view savings account” icon.

FIG. 18 shows a first modified banking entity home page having a frame presenting new bill availability data.

FIG. 19 shows a second modified banking entity home page having a frame presenting detailed bill data.

FIG. 20 is a flowchart diagram showing customer service data and message flows between a centralized customer service center, and an EPCS entity, a billing entity, and a banking entity in the electronic bill presentment and payment system shown in FIG.4.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

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

The plurality of message interfaces34-40 includes aninternal message interface34, anexternal message interface36, apartner message interface38, and a customercare message interface40. Theinternal message interface34 defines messages that are used to communicate and query data between the given distributeddatabase entity30 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. Theexternal message interface36 defines messages that are used to communicate and query data between the given distributeddatabase entity30 and any existing system(s) that are directly related to the given distributeddatabase entity30. For example, an FI such as a bank can have an existing direct deposit account (DDA) system. Thepartner message interface38 defines messages that are used to communicate and query data between the given distributeddatabase entity30 and any existing system(s) that are indirectly related to the given distributeddatabase entity30. For example, in a bill presentment and payment system, communication with an established billing aggregator may be necessary to satisfy customer demands. The customercare message interface40 defines messages that are used to communicate and query data between the given distributeddatabase entity30 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.

Referring to FIG. 4, there is shown a schematic diagram of a versatile electronic bill presentment andpayment system50 in accordance with the present invention. Thesystem50 comprises auser entity52, abanking entity54, abilling entity56, and an electronic payment and customer service (EPCS)entity58. For purposes of this detailed description, theuser entity52, thebanking entity54, thebilling entity56, and theEPCS entity58 are each distributeddatabase entities30 as defined above. Thus, theuser entity52, thebanking entity54, thebilling entity56, and theEPCS entity58 each has adatabase component32, aninternal message interface34, anexternal message interface36, apartner message interface38, and a customercare message interface40. It should be noted, however, that theuser entity52, thebanking entity54, thebilling entity56, and theEPCS entity58 are not required to have adatabase component32, aninternal message interface34, anexternal message interface36, apartner message interface38, and a customercare message interface40. That is, theuser entity52, thebanking entity54, thebilling entity56, and theEPCS entity58 are only required to have aninternal message interface34 so that communications can take place between each entity.

At this point it should be noted that, although only asingle user entity52,banking entity54,billing entity56, andEPCS entity58 is shown in thesystem50, 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.

As previously described, aninternal message interface34 defines messages that are used to communicate and query data between distributed database entities. Thus, since theuser entity52, thebanking entity54, thebilling entity56, and theEPCS entity58 are all distributed database entities, they all communicate through internal message interfaces34. The communications are performed overinterconnections60, which can be electrical wire, optical fiber, or microwave-based interconnections.

At this point it should be noted that eachinternal message interface34, as well as eachexternal message interface36,partner message interface38, and customercare message interface40, 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 interfaces34, the external message interfaces36, the partner message interfaces38, and the customer care message interfaces40 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.

Theuser entity52 is typically a personal computer (PC) that is directly connected to thesystem50, or is connected to thesystem50 through a network server. Thus, thedatabase component32 associated with theuser entity52 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 thedatabase component32 associated with theuser entity52 can also be located in one of the other distributed database entities, which can download data to the user entity52 (e.g., a Java client). It should also be noted that thedatabase component32 associated with theuser entity52 can be distributed among all three of the above-listed locations, owing to the distributed nature of eachdatabase component32. Thus, eachdatabase component32 should not be thought of as a single, monolithic database. Rather, eachdatabase component32 is better described as a distributed repository of data categorized by the entity that “owns” the data.

Wherever it is located, thedatabase component32 associated with theuser entity52 stores data that is related to the type of user interface (UI) that is being presented to a subscriber of thesystem50. For example, thedatabase component32 associated with theuser entity52 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. Thedatabase component32 associated with theuser entity52 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. Thedatabase component32 associated with theuser entity52 can further store subscriber authentication data, which is described in detail below.

The main function of theuser entity52 is to build a UI using data obtained from the other distributed database entities, and then present the UI to a subscriber of thesystem50. 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.

Other functions of theuser entity52 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 theuser entity52 includes storing subscriber authentication data (e.g., a security ticket) that is used to gain access to other distributed database entities in thesystem50.

Thebanking entity54, which is typically an FI such as, for example, a bank, is generally viewed as a primary point of presence for a subscriber to thesystem50, 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, thebanking entity54 is assumed to be the aggregator of thesystem50. It should be noted, however, that any one of the other entities could also be the aggregator of thesystem50 in accordance with the present invention. There are several factors which can be used to determine aggregator status such as, for example, market clout.

Thebanking entity54 typically gains access to thesystem50 through a network server. Thus, thedatabase component32 associated with thebanking entity54 can be located in the network server. It should be noted that thedatabase component32 associated with thebanking entity54 can also be located in a system associated with thebanking entity54 such as, for example, a DDA system. Such a DDA system could be accessed through theexternal message interface36 of thebanking entity54, as described in detail below. It should further be noted that thedatabase component32 associated with thebanking entity54 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 eachdatabase component32.

Wherever it is located, thedatabase component32 associated with thebanking entity54 stores bank-specific subscriber profile data profile such as, for example, subscriber names and addresses and subscriber account numbers. Thedatabase component32 associated with thebanking entity54 can also store account information such as, for example, static account information (e.g., lease rate, principle), and dynamic account information (e.g., balance). Thedatabase component32 associated with thebanking entity54 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.

Since it is likely that thesystem50 will be used with existing banking systems such as, for example, an existing DDA system, one of the main functions of thebanking entity54 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, thebanking entity54 also provides data to theuser entity52 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 thebanking entity54 can also provide data to theuser entity52 to be used for the creation of a UI for traditional banking and bill payment.

Since thebanking entity54 is generally viewed as the primary point of presence for a subscriber to thesystem50, thebanking entity54 also functions as the likely, but not exclusive, entry point for subscriber sign-on. Thus, thebanking entity54 typically controls the sign-on and authentication procedures for subscribers through theuser entity52. It should be noted that thebanking entity54 typically works in conjunction with theEPCS entity58 in controlling the authentication procedure, as described in detail below.

Another function of thebanking entity54 includes tracking bank related events and storing them in an event tracking database, which is typically associated with theEPCS entity58, as also described in detail below.

Thebilling entity56 is typically a biller such as, for example, a utility company. Thebilling entity56 typically gains access to thesystem50 through a network server. Thus, thedatabase component32 associated with thebilling entity56 can be located in the network server. It should be noted that thedatabase component32 associated with thebilling entity56 can also be located in a system associated with thebilling entity56 such as, for example, a legacy billing system. Such a legacy billing system could be accessed through theexternal message interface36 of thebilling entity56, as described in detail below. It should further be noted that thedatabase component32 associated with thebilling entity56 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 eachdatabase component32.

Wherever it is located, thedatabase component32 associated with thebilling entity56 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). Thedatabase component32 associated with thebilling entity56 also stores billing data for use by theuser entity52 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.

Thedatabase component32 associated with thebilling entity56 can also store biller transaction history such as, for example, bill data manipulation (e.g., viewing, searching, sorting), and cross-sell events. Thedatabase component32 associated with thebilling entity56 can further store biller profile data such as, for example, graphics, business rules, and relationships with aggregators such as banks.

The main function of thebilling entity56 is to provide billing data to theuser entity52 for use in creating the UI for the subscriber. Thebilling entity56 also provides bill availability data to an aggregator database, whether it is located in thebanking entity54, theEPCS entity58, or another entity, to provide notice of bill availability to subscribers. Thebilling entity56 can also access legacy billing systems through theexternal message interface36 of thebilling entity56, as indicated above.

Another function of thebilling entity56 includes tracking biller-related events and storing them in an event tracking database, which is typically associated with theEPCS entity58, as described in detail below.

TheEPCS entity58 can generally be described in terms of adata processing system70, such as shown in FIG.5. Thedata processing system70 preferably comprises at least one processor (P)72, memory (M)74, and input/output (I/O)interface76, which are connected to each other by a bus78, for implementing the functions of theEPCS entity58, as described in detail below.

Referring again to FIG. 4, theEPCS entity58 typically gains access to thesystem50 through a network server. Thus, thedatabase component32 associated with theEPCS entity58 can be located in the network server. It should be noted that thedatabase component32 associated with theEPCS entity58 can also be located in a system associated with theEPCS entity58 such as, for example, a legacy aggregating system. Such a legacy aggregating system could be accessed through theexternal message interface36 of theEPCS entity58, as described in detail below. It should further be noted that thedatabase component32 associated with theEPCS entity58 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 eachdatabase component32.

Wherever it is located, thedatabase component32 associated with theEPCS entity58 stores bill payment-specific subscriber profile data such as, for example, subscriber names and addresses, subscriber DDA account numbers, and subscriber credit ratings. Thedatabase component32 associated with theEPCS entity58 also stores bill payment warehouse data such as, for example, user-specific payees, single occurrence payments, and recurring payments/models.

As previously described, both thebanking entity54 and thebilling entity56 track and store events in an event tracking database. This event tracking database is typically located in thedatabase component32 associated with theEPCS entity58. 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.

Thedatabase component32 associated with theEPCS entity58 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). Thedatabase component32 associated with theEPCS entity58 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 thebilling entity56. Thedatabase component32 associated with theEPCS entity58 still further stores security data such as, for example, required sign-on information and macro-level authorizations. Thedatabase component32 associated with theEPCS entity58 additionally stores customer service data such as, for example, FAQ's, FI and biller contact information, and problem resolution data.

TheEPCS entity58 is the glue that holds the distributed database entities together. TheEPCS entity58 accomplishes this by functioning as an integration agent by maintaining bill payment profiles and warehouse data, aggregating bill availability and status data (but 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, theEPCS entity58 functions as the authentication gate keeper. This doesn't mean to imply that theEPCS entity58 necessarily maintains user identification numbers and/or passwords. However, it does imply that theEPCS entity58 accepts sign-on requests and doles out authentication “tickets” in response, in conjunction with the banking entity as described above.

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

It should also be noted that theEPCS entity58 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.

As previously described, aninternal message interface34 defines messages that are used to communicate and query data between distributed database entities. As also previously described, eachinternal message interface34 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 aninternal message interface34 in accordance with the present invention.

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

Thebanking entity54 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. Thebanking entity54 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. Thebanking entity54 will further process an internal message to query/update bank subscriber profile data for purposes of customer care. Thebanking entity54 will still further process an internal message to query bank transaction history for customer care and for linking to the event tracking database. Thebanking entity54 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 theEPCS entity58 to tailor the list by FI sponsor. Thebanking entity54 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.

Thebilling entity56 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. Thebilling entity56 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. Thebilling entity56 will further process an internal message to query/update biller subscriber profile data for purposes of customer care. Thebilling entity56 will still further process an internal message to query biller transaction history for customer care and for linking to the event tracking database. Thebilling entity56 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.

TheEPCS entity58 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, e-mail created/read/deleted data.

TheEPCS entity58 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.).

TheEPCS entity58 will also process internal security messages. Such internal security messages may relate to authentication, which result in theEPCS entity58 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 thebanking entity54. It may be initiated if a subscriber tries to gain access to thebilling entity56, and thereby not even contacting thebanking entity54. The point being that with a security ticket a subscriber is generally allowed to freely traverse any database entity in thesystem50 without going through repeated sign-on procedures.

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.

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.

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, thebilling entity56 may, for whatever reason, require additional authentication information.

TheEPCS entity58 will further process internal messages relating to aggregation data. For example, anEPCS entity58 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 thebilling entity56.

TheEPCS entity58 will still further process an internal message to query/update bill payment transaction history for purposes of customer care.

TheEPCS entity58 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.

TheEPCS entity58 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).

As previously described, anexternal message interface36 defines messages that are used to communicate and query data between a given distributeddatabase entity30 and any existing system(s) that are directly related to the given distributeddatabase entity30. As also previously described, eachexternal message interface36 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.

Referring to FIG. 6, there is shown a schematic diagram of the versatile electronic bill presentment andpayment system50, along with some associated directly related systems. The associated directly related systems comprise adesktop database80, aDDA system82, alegacy billing system84, and alegacy remittance system86. The communications between the various database entities and their associated directly related systems are performed overinterconnections88, which can be electrical wire, optical fiber, or microwave-based interconnections.

Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), theuser entity52 may need to process an external message in order to communicate with an existing system such as, for example, thedesktop database80. To support such a legacy system, it may be necessary to implement theexternal message interface36 of theuser entity52 in the context of an existing, and possibly extended, protocol specification, such as Gold, NPC, or OFX.

Thebanking entity54 will process external messages to and from an existing system such as, for example, theDDA system82 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 thebanking entity54 would need to interface with other banking systems (e.g., stops). Thus, theexternal message interface36 of thebanking entity54 is a key feature of the versatile electronic bill presentment andpayment system50.

Thebilling entity56 will process external messages to and from an existing system such as, for example, thelegacy billing system84 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, theexternal message interface36 of thebilling entity56 is a key feature of the versatile electronic bill presentment andpayment system50.

TheEPCS entity58 will process external messages to and from an existing system such as, for example, thelegacy remittance system86. Thelegacy remittance system86 could be, for example, ACH, RPP, RPS, or Direct Send.

As previously described, apartner message interface38 defines messages that are used to communicate and query data between a given distributeddatabase entity30 and any existing system(s) that are indirectly related to the given distributeddatabase entity30. As also previously described, eachpartner message interface38 can be implemented using any number of existing message-based communication systems, or with proprietary messaging software on a private network or is intranet. Furthermore, the message specification or file format can be either standard (i.e., open) or proprietary.

Referring to FIG. 7, there is shown a schematic diagram of the versatile electronic bill presentment andpayment system50, along with some associated indirectly related systems. The associated indirectly related systems comprise apersonal finance system90, abanking system92, an establishedbilling aggregator94, and an alternative bill presentment andpayment system96. The communications between the various database entities and their associated indirectly related systems are performed overinterconnections98, which can be electrical wire, optical fiber, or microwave-based interconnections.

Depending upon the nature of the presentation technology being used (e.g., a “fat” client, an HTML browser client, or a Java client), theuser entity52 may need to process a partner message in order to communicate with a partner such as, for example, thepersonal finance system90. Thepersonal finance system90 could be, for example, a personal financial manager (PFM) software package such as, for example, Quicken or Money.

Thebanking entity54 will process partner messages to and from a partner such as, for example, thebanking system92.

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

To present a bill generated by the establishedbilling aggregator94, thepresent system50 would, for example, receive bill availability data and the URL of a web server of the establishedbilling aggregator94, and thebilling entity56 would then point to the web server of the establishedbilling aggregator94 to get an HTML presentation of detailed bill data. In this scenario, thepartner message interface38 would be essentially the same as aninternal message interface34, but possibly with added bulk transfer capability.

TheEPCS entity58 will process partner messages to and from a partner such as, for example, the alternative bill presentment andpayment system96. Such a partner relationship may be required if abilling entity56 has a subscriber base that is split between using thepresent system50 and the alternative bill presentment andpayment system96. In such a scenario, thepresent system50 could function as a billing aggregator for the alternative bill presentment andpayment system96, and vice-versa. However, the alternative bill presentment andpayment system96 and its subscribers would not receive any of the benefits of the messaging functionality provided by thepresent system50. Only the minimum amount of functionality would be provided. That is, thepartner message interface38 would only provide what is required to present bills through the alternative bill presentment andpayment system96, and not offer any of the advantages provided by thepresent system50. The goal being to have thebilling entity56 encourage all of its subscribers to access bills through thepresent system50.

It should be noted that theEPCS entity58 will typically require the capabilities of abilling entity56 in order to present bills to and from the alternative bill presentment andpayment system96.

As previously described, a customercare message interface40 defines messages that are used to communicate and query data between a given distributeddatabase entity30 and a customer care entity. As also previously described, each customercare message interface40 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.

Referring to FIG. 8, there is shown a schematic diagram of the versatile electronic bill presentment andpayment system50, along with some associated customer care entities. The associated customer care entities comprise a user entityself service center100, a banking entitycustomer service center102, a billing entitycustomer service center104, and an EPCScustomer service center106. The communications between the various database entities and their associated customer care entities are performed overinterconnections108, which can be electrical wire, optical fiber, or microwave-based interconnections.

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

Thebanking entity54 will process customer care messages from a customer care entity such as, for example, the banking entitycustomer service center102. A customer care message may be a request for data or a request to modify existing data. Thebanking entity54 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 entitycustomer service center102. The banking entitycustomer service center102 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.

Thebilling entity56 will process customer care messages from a customer care entity such as, for example, the billing entitycustomer service center104. A customer care message may be a request for data or a request to modify existing data. Thebilling entity56 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 entitycustomer service center104. The billing entitycustomer service center104 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.

TheEPCS entity58 will process customer care messages from a customer care entity such as, for example, the EPCS entitycustomer service center106. A customer care message may be a request for data or a request to modify existing data. TheEPCS entity58 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 entitycustomer service center106. The EPCS entitycustomer service center106 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.

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

Referring to FIGS. 10-15, there are shown flowchart diagrams of data and message flows between the various entities within thesystem50. These flowchart diagrams assume that theuser entity52 is an HTML browser client, thebanking entity54 is the primary point of presence for a subscriber to thesystem50, thebilling entity56 controls bill presentment, and theEPCS entity58 controls bill payment.

In FIG. 10, a subscriber at theuser entity52 accesses the web site of thebanking entity54 instep200. In return, thebanking entity54 presents a branded interface to theuser entity52, including a sign-on request prompt instep202. FIG. 16 shows an example of such a brandedinterface120, wherein the sign-on request prompt includes ausername field122 and apassword field124.

In FIG. 11, theuser entity52 submits a sign-on request with authentication credentials insteps204. Thebanking entity54 messages theEPCS entity58 with the authentication credentials of the subscriber and the event is logged instep206. TheEPCS entity58 provides a security ticket to thebanking entity54 instep208. Thebanking entity54 delivers the security ticket to theuser entity52 and presents its “home page” touser entity52 instep210. FIG. 17 shows an example of such ahome page130, which includes a “view bills”icon132, a “view checking account”icon134, and a “view savings account”icon136.

It should be noted that either theEPCS entity58 or thebanking entity54 could perform the authentication procedure, but in either case the event is still logged in the event tracking database.

In FIG. 12, the subscriber selects the “view bills”icon132 instep212. Thebanking entity54 messages theEPCS entity58 with an aggregation data request and the event is logged instep214. TheEPCS entity58 presents aggregation data of new bill availability touser entity52 instep216. FIG. 18 shows a first modifiedhome page140 having anEPCS entity frame142 presenting the new bill availability data, which includes an “electric bill”icon144, a “gas bill”icon146, a “phone bill”icon148, a “cable bill”icon150, a “credit card bill”icon152, and an “all bills”icon154 which allows all bills to be presented simultaneously, albeit in separate frames.

In FIG. 13A, the subscriber selects the “gas bill”icon146 and is linked to thebilling entity56 along with the security ticket instep218. Thebilling entity56 messages theEPCS entity58 to log the “view bill” request event instep220. Thebilling entity56 presents detailed bill data to theuser entity52 instep222. FIG. 19 shows a second modifiedhome page160 having abilling entity frame162 presenting the detailed bill data, which includes the subscriber name, subscriber address, account number, usage, and cost, and a “pay bill”icon164.

In FIG. 14, the subscriber selects the “pay bill”icon164 and messages theEPCS entity58 with a forward dated pay bill request so the event is logged instep224. TheEPCS entity58 messages thebilling entity56 with a pay bill request notification along with a bill identification number instep226.

In FIG. 15, the EPCS posts a debit with thebanking entity54 and the event is logged instep228. TheEPCS entity58 then remits a payment to thebilling entity56 and the event is logged instep230.

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 establishedbilling aggregator94 thru thepartner message interface38 of thebilling entity56. In FIG. 13B, the subscriber again selects the “gas bill”icon146 and is linked to thebilling entity56 along with the security ticket instep232. Thebilling entity56 again messages theEPCS entity58 to log the “view bill” request event instep234. However, in this case, detailed bill data is available only from the establishedbilling aggregator94. Thus, thebilling entity56 accesses the establishedbilling aggregator94 through itspartner message interface38 instep236. In response, the establishedbilling aggregator94 provides detailed bill data to thebilling entity56 instep238. Thebilling entity56 then presents the detailed bill data to theuser entity52 instep240.

It should be noted that, in an alternative embodiment, the establishedbilling aggregator94 could present the detailed bill data directly to theuser entity52.

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 andpayment system96 thru thepartner message interface38 of theEPCS entity58. In FIG. 13C, the subscriber selects the “gas bill”icon146 and is linked back to theEPCS entity58 along with the security ticket and the event is logged instep242. In this case, detailed bill data is available only from the alternative bill presentment andpayment system96. Thus, theEPCS entity58 accesses the alternative bill presentment andpayment system96 through itspartner message interface38 instep244. In response, the alternative bill presentment andpayment system96 provides detailed bill data to theEPCS entity58 instep246. TheEPCS entity58 then presents the detailed bill data to theuser entity52 instep248.

It should be noted that, as previously described, theEPCS entity58 will typically require the capabilities of abilling entity56 in order to present bills to and from the alternative bill presentment andpayment system96. Alternatively, it should be noted that detailed bill data can be provided by the alternative bill presentment andpayment system96 thru thepartner message interface38 of thebilling entity56 in a manner similar to that as described in FIG.13B.

Referring to FIG. 20, there is shown a flowchart diagram of data and message flows between the centralizedcustomer service center110 and the various entities within thesystem50. Asubscriber170 contacts the centralizedcustomer service center110 regarding a bill payment instep250. The centralizedcustomer service center110 accesses the event tracking database in theEPCS entity58 to see if a view bill, pay bill, remit payment, or debit posting event has been logged instep252. If more detailed information regarding, for example, the posting of a debit for a bill, the centralizedcustomer service center110 can access thedatabase component32 associated with thebanking entity54, as shown instep254. Similarly, if more detailed information regarding, for example, the remitting of a payment for a bill, the centralizedcustomer service center110 can access thedatabase component32 associated with thebilling entity56, as shown instep256. It should be noted that, although not shown, theEPCS entity58 can log all of the above-described accesses performed by centralizedcustomer service center110.

As is apparent from the foregoing description, thesystem50 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. Thesystem50 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.

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 distributeddatabase entities30 to facilitate distributed data accessing within a network in accordance with the present invention.

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.

Claims (27)

What is claimed is:

1. A method for centrally tracking transactions in an electronic billing system having multiple different billing entities, multiple different financial institute entities and multiple different user entities, each of the multiple different billing entities being associated with a respective portion of the multiple different user entities and each of the multiple different financial institute entities being associated with a respective portion of the multiple different user entities, comprising the steps of:

receiving, from any of the multiple different financial institute entities, a message indicative of a request from any of the multiple different user entities associated with the applicable financial institute entity to view billing information;

logging, in a database, the receipt of the request to view the billing information as a first event information;

transmitting, to the applicable user entity, a message indicative of the billing information of at least one of the multiple different billing entities associated with the applicable user entity which is available for viewing;

receiving, from any of the at least one of the billing entities, a message indicative of a request from the applicable user entity to view the available billing information of that billing entity; and

logging, in the database, the receipt of the message indicative of the applicable user entity request to view the billing information of the applicable billing entity as a second event information.

2. A method according to claim1, further comprising the steps of:

receiving a message indicative of a signing-on to the system of the applicable user entity; and

logging, in a database, the receipt of the message indicative of the applicable user entity signing-on to the system.

3. A method according to claim2, wherein the message indicative of the applicable user entity signing-on to the system is indicative of the applicable user entity having been authenticated.

4. A method according to claim2, wherein the message indicative of the applicable user entity signing-on to the system is received, from the applicable financial institute entity, and includes authentication credentials of the applicable user entity.

5. A method according to claim1, wherein the at least one of the billing entities is two or more billing entities, and further comprising the steps of:

receiving, from the applicable user entity, a request to view the available billing information of another of the two or more billing entities;

logging, in the database, the receipt of the applicable user request to view the available billing information of the other applicable billing entity; and

transmitting, to the applicable user entity, the requested billing information of the other applicable billing entity.

6. A method according to claim1, further comprising the steps of:

receiving, from the applicable user entity, a request to pay a billed amount represented by the billing information which the applicable user entity has requested to view; and

logging, in the database, the receipt of the applicable user request to pay the billed amount as a third event information.

7. A method according to claim6, further comprising the steps of:

transmitting, to the applicable financial institute entity, a request to debit the billed amount from an account maintained by the applicable financial institute entity on behalf of the applicable user entity;

logging, in the database, the request to debit funds associated with the account maintained by the applicable financial institute entity on behalf of the applicable user entity as a fourth event information;

transmitting, to applicable billing entity, a payment of the billed amount; and

logging, in the database, the payment of the billed amount as a fifth event information.

8. A method according to claim7, further comprising the steps of:

receiving, from a customer care representative of at least one of the applicable financial institute entity and the applicable billing entity, a request for one or more of the first, the second, the third, the fourth and the fifth event information;

retrieving the requested one or more of the first, the second, the third, the fourth and the fifth event information from the database; and

transmitting the retrieved information to the customer care representative.

9. A system for centrally tracking electronic billing transactions involving multiple different billing entities, multiple different financial institute entities and multiple different user entities, each of the multiple different billing entities being associated with a respective portion of the multiple different user entities and each of the multiple different financial institute entities being associated with a respective portion of the multiple different user entities, comprising:

a processor configured (i) to receive, from any of the multiple different financial institute entities, a message indicative of a request from any of the multiple different user entities associated with the applicable financial institute entity to view billing information, (ii) to transmit, to the applicable user entity, a message indicative of the billing information of at least one of the multiple different billing entities associated with the applicable user entity which is available for viewing, (iii) and to receive, from any of the at least one of the billing entities, a message indicative of a request from the applicable user entity to view the available billing information of that billing entity; and

a database configured to store a log of the receipt of the request to view the billing information as a first event information, and of the receipt of the message indicative of the applicable user entity request to view the billing information of the applicable billing entity as a second event information.

10. A system according to claim9, wherein:

the processor is further configured to receive a message indicative of a signing-on to the system of the applicable user entity; and

the database is further configured to store a log of the receipt of the message indicative of the applicable user entity signing-on to the system.

11. A system according to claim10, wherein the message indicative of the applicable user entity signing-on to the system is received from the applicable financial institute entity.

12. A system according to claim9, wherein:

the at least one of the billing entities is two or more billing entities;

the processor is further configured to receive, from the applicable user entity, a request to view the available billing information of another of the two or more billing entities and to transmit, to the applicable user entity, the requested billing information of the other applicable billing entity; and

the database is further configured to store a log of the receipt of the applicable user request to view the available billing information of the other applicable billing entity.

13. A system according to claim9, wherein:

the processor is further configured to receive, from the applicable user entity, a request to pay a billed amount represented by the billing information which the applicable user entity has requested to view; and

the database is further configured to store a log of the receipt of the applicable user request to pay the billed amount as a third event information.

14. A system according to claim13, wherein:

the processor is further configured to transmit, to the applicable financial institute entity, a request to debit the billed amount from an account maintained by the applicable financial institute entity on behalf of the applicable user entity, and to transmit, to applicable billing entity, a payment of the billed amount; and

the database is further configured to store a log of the request to debit funds associated with the account maintained by the applicable financial institute entity on behalf of the applicable user entity as a fourth event information, and of the payment of the billed amount as a fifth event information.

15. A system according to claim14, wherein:

the processor is further configured (i) to receive, from a customer care representative of at least one of the applicable financial institute entity and the applicable billing entity, a request for one or more of the first, the second, the third, the fourth and the fifth event information, (ii) to retrieve the requested one or more of the first, the second, the third, the fourth and the fifth event information from the database, and (iii) to transmit the retrieved information to the customer care representative.

16. A method for centrally tracking electronic billing transactions between multiple different billing entities and multiple different user entities, each of the multiple different billing entities being associated with a different portion of the multiple different user entities, comprising the steps of:

receiving requests at the multiple different billing entities from the multiple different user entities to view billing information; and

storing an indication of the receipt of the requests in a central database as first event information.

17. A method according to claim16, further comprising the steps of:

receiving requests from the multiple different user entities to pay billed amounts represented by the requested billing information;

storing an indication of receipt of the requests from the multiple different user entities to pay the billed amounts in the central database as second event information;

receiving requests to debit the billed amounts from accounts maintained on behalf of the multiple different user entities by multiple different financial institute entities, each being associated with a respective portion of the multiple different user entities;

storing an indication of receipt of the requests to debit the billed amounts from the accounts in the central database as third event information;

directing payments of the billed amounts; and

storing an indication of the payments in the central database as fourth event information.

18. A method according to claim17, further comprising the steps of:

receiving requests at the multiple different financial institute entities from the multiple different user entities to view billing information; and

storing an indication of the receipt of requests at the multiple different financial institute entities from the multiple different user entities to view billing information in the central database as fifth event information.

19. A method according to claim17, further comprising the steps of:

receiving, from a customer care representative of at least one of the multiple different financial institute entities and the multiple different billing entities, a request for one or more of the first, the second, the third, and the fourth event information;

retrieving the requested one or more of the first, the second, the third, and the fourth event information from the central database; and

transmitting the retrieved information to the customer care representative.

20. A method according to claim16, further comprising the steps of:

transmitting messages to the multiple different user entities, each respective message indicative of the billing information of the multiple different billing entities which is available to a particular one of the multiple different user entities for viewing.

21. A system for centrally tracking electronic billing transactions between multiple different billing entities and multiple different user entities, each of the multiple different billing entities being associated with a different portion of the multiple different user entities, comprising:

a central database configured to store transaction events; and

a central processor configured to log, in the database, requests received by the multiple different billing entities from the multiple different user entities to view billing information as first event information.

22. A system according to claim21, wherein:

the central processor is further configured to log, in the database, (i) requests from the multiple different user entities to pay billed amounts represented by the requested billing information as second event information, (ii) requests to debit the billed amounts from accounts maintained on behalf of the multiple different user entities by multiple different financial institute entities, each being associated with a respective portion of the multiple different user entities as third event information, and (iii) payments of the billed amounts as fourth event information.

23. system according to claim22, wherein:

the central processor is further configured to log, in the database, requests received by the multiple different financial institute entities from the multiple different user entities to view billing information.

24. A system according to claim22, wherein the central processor is further configured (i) to receive, from a customer care representative of at least one of the multiple different financial institute entities and the multiple different billing entities, a request for one or more of the first, the second, the third, and the fourth event information, (ii) to retrieve the requested one or more of the first, the second, the third, and the fourth event information from the database, and (iii) to transmit the retrieved information to the customer care representative.

25. A system according to claim21, wherein the central processor is further configured to transmit messages to the multiple different user entities, each respective message indicative of the billing information of the multiple different billing entities which is available to a particular one of the multiple different user entities for viewing.

26. A method for centrally tracking transactions in an electronic billing system having multiple different billing entities, multiple different financial institute entities and multiple different user entities, each of the multiple different billing entities being associated with a respective portion of the multiple different user entities and each of the multiple different financial institute entities being associated with a respective portion of the multiple different user entities, comprising the steps of:

receiving, from any of the multiple different financial institute entities, a message indicative of a request from any of the multiple different user entities associated with the applicable financial institute entity to view billing information;

logging, in a database, the receipt of the request to view the billing information as event information; and

transmitting, to the applicable user entity, a message indicative of the billing information of at least one of the multiple different billing entities associated with the applicable user entity which is available for viewing.

27. A system for centrally tracking electronic billing transactions involving multiple different billing entities, multiple different financial institute entities and multiple different user entities, each of the multiple different billing entities being associated with a respective portion of the multiple different user entities and each of the multiple different financial institute entities being associated with a respective portion of the multiple different user entities, comprising:

a processor configured (i) to receive, from any of the multiple different financial institute entities, a message indicative of a request from any of the multiple different user entities associated with the applicable financial institute entity to view billing information, and (ii) to transmit, to the applicable user entity, a message indicative of the billing information of at least one of the multiple different billing entities associated with the applicable user entity which is available for viewing; and

a database configured to store a log of the receipt of the request to view the billing information as event information.

Images