US20050137978A1 - Presentation and payment of bills over a wide area communications network - Google Patents
Presentation and payment of bills over a wide area communications network Download PDFInfo
- Publication number
- US20050137978A1 US20050137978A1 US11/057,233 US5723305A US2005137978A1 US 20050137978 A1 US20050137978 A1 US 20050137978A1 US 5723305 A US5723305 A US 5723305A US 2005137978 A1 US2005137978 A1 US 2005137978A1
- Authority
- US
- United States
- Prior art keywords
- bill
- entity
- user
- signal
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Definitions
- the present invention relates generally to distributed data networks and, more particularly, to a distributed data accessing technique.
- 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.
- FI financial institution
- 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.
- 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 .
- 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 .
- 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 .
- the second prevalent model for electronic bill presentment is a biller direct model 20 , which is shown in FIG. 2 .
- the biller direct model 20 includes a customer 12 and at least one biller 16 .
- 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.
- 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 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 .
- 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.
- 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-toend 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.
- a distributed data accessing 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.
- 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.
- the identified available data can be provided to the second network station by an entity located outside of the network.
- 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.
- 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
- 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.
- 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.
- the is 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.
- the identified available second data can be provided to the fourth network station by an entity located outside of the network.
- 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
- 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.
- 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 .
- 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 .
- 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.
- FI financial institution
- the database component 32 can also contain data from other distributed database entities and system components, as will be described in detail below.
- 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 .
- an FI such as a bank can have an existing direct deposit account (DDA) system.
- DDA direct deposit account
- 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 .
- 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.
- 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.
- 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 , a banking entity 54 , a billing entity 56 , and an electronic payment and customer service (EPCS) entity 58 .
- 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.
- 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 .
- 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.
- an internal message interface 34 defines messages that are used to communicate and query data between distributed database entities.
- 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.
- each internal message interface 34 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.
- 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.
- 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.
- 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).
- 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).
- 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 .
- 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.
- 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 .
- UI user interface
- 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.
- 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.
- 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 .
- subscriber authentication data e.g., a security ticket
- 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.
- the banking entity 54 typically gains access to the system 50 through a network server.
- the database component 32 associated with the banking entity 54 can be located in the network server.
- 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.
- 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 .
- 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.
- the banking entity 54 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.
- the banking entity 54 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.
- 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.
- 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.
- the database component 32 associated with the billing entity 56 can be located in the network server.
- 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.
- 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 .
- 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.
- 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.
- 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.
- 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.
- 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.
- P processor
- M memory
- I/O input/output
- the EPCS entity 58 typically gains access to the system 50 through a network server.
- the database component 32 associated with the EPCS entity 58 can be located in the network server.
- 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.
- 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 .
- 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.
- 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.
- 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.
- 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 not bill content or presentation), and maintaining an event tracking database (or audit trail) that can be accessed by all of the database entities.
- the EPCS entity 58 functions as the authentication gate keeper. This doesn't 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 doles out authentication “tickets” in response, in conjunction with the banking entity as described above.
- EPCS entity 58 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.
- 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.
- an internal message interface 34 defines messages that are used to communicate and query data between distributed database entities.
- 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.
- the message specification or file format can be either standard (i.e., open) or proprietary.
- 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.
- 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.
- 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.
- 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.
- 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, e-mail created/read/deleted data.
- subscriber service activation data e.g., biller, bill payment, banking, etc.
- sign-on data e.g., bill availability data
- bill viewed data e.g., bill payment generated data (option
- 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.).
- the EPCS entity 58 will also process internal security messages. Such internal security messages may relate to authentication, which result in the EPCS entity 0 . 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.
- 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.
- a security ticket 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.
- a security ticket enables, but does not mandate, a single sign-on procedure.
- a database entity such as, for example, the billing entity 56 may, for whatever reason, require additional authentication information.
- 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 .
- the EPCS entity 58 will still further process an internal message to query/update bill payment transaction history for purposes of customer care.
- 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.
- 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).
- 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 .
- 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.
- the message specification or file format can be either standard (i.e., open) or proprietary.
- 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.
- 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 .
- an existing system such as, for example, the desktop database 80 .
- 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).
- the external message interface 36 of the banking entity 54 is a key feature of the versatile electronic bill presentment and payment system 50 .
- 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 .
- 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.
- 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 .
- 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.
- the message specification or file format can be either standard (i.e., open) or proprietary.
- 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.
- 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.
- PFM personal financial manager
- the banking entity 54 will process partner messages to and from a partner such as, for example, the banking system 92 .
- the billing entity 56 will process partner messages to and from a partner such as, for example, the established billing aggregator 94 .
- 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 .
- 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 .
- 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.
- the partner message interface 38 would be essentially the same as an internal message interface 34 , but possibly with added bulk transfer capability.
- 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 .
- 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 .
- the present system 50 could function as a billing aggregator for the alternative bill presentment and payment system 96 , and vice-versa.
- 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.
- 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 .
- 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 .
- 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.
- 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.
- the message specification or file format can be either standard (i.e., open) or proprietary.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- FIGS. 10-15 there are shown flowchart diagrams of data and message flows between the various entities within the system 50 .
- 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
- the EPCS entity 58 controls bill payment.
- a subscriber at the user entity 52 accesses the web site of the banking entity 54 in step 200 .
- 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 .
- 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 .
- 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.
- 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 .
- 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 .
- 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 .
- 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 thru the partner message interface 38 of the billing entity 56 .
- 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 .
- detailed bill data is available only from the established billing aggregator 94 .
- the billing entity 56 accesses the established billing aggregator 94 through its partner message interface 38 in step 236 .
- 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 .
- the established billing aggregator 94 could present the detailed bill data directly to the user entity 52 .
- 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 thru the partner message interface 38 of the EPCS entity 58 .
- 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 .
- detailed bill data is available only from the alternative bill presentment and payment system 96 .
- the EPCS entity 58 accesses the alternative bill presentment and payment system 96 through its partner message interface 38 in step 244 .
- the alternative bill presentment and payment system 96 provides detailed bill data to the EPCS entity 58 in step 246 .
- the EPCS entity 58 presents the detailed bill data to the user entity 52 in step 248 .
- 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 .
- detailed bill data can be provided by the alternative bill presentment and payment system 96 thru the partner message interface 38 of the billing entity 56 in a manner similar to that as described in FIG. 13B .
- 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 .
- 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 .
- 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.
Abstract
A bill is presented and payment of the presented bill is requested over a communications network having a first network site associated with a bill payment entity, a second network site, which is different than the first network site, associated with a user, and a third network site, which is different than the first and the second network sites, associated with a bill presentment entity, which is different than the bill payment entity. A first signal, representing a request of the user for billing information, is transmitted from the second network site to the first network site. Responsive to the transmitted first signal, a second signal representing a bill availability identifier for a bill of a biller for the user, is transmitted from the first network site to the second network site. The bill availability identifier represented by the transmitted second signal is displayed and a first user input representing a selection of the displayed bill availability identifier is received, at the second network site. A third signal, representing a request of the user for the identified bill, is transmitted from the second network site to a third network site responsive to the first user input. Responsive to the transmitted third signal, a fourth signal representing the requested bill and an associated pay bill indicator, is transmitted from the third network site to the second network site. The bill and associated pay bill indicator represented by the transmitted fourth signal are displayed and a second user input representing a selection of the displayed pay bill indicator is received at the second network site. Responsive to the second user input, a fifth signal representing a request of the user that the bill payment entity pay the displayed bill on behalf of the user, is transmitted from the second network site to the first network site.
Description
- This application is a continuation of pending U.S. application Ser. No. 09/301,068, filed Apr. 28, 1999, which is a continuation of U.S. application Ser. No. 09/017,169, filed Feb. 2, 1998 (now U.S. Pat. No. 6,055,567), which are incorporated herein by reference in their entirety. This application is also related to U.S. application Ser. No. 10/645,521, filed Aug. 22, 2003.
- The present invention relates generally to distributed data networks and, more particularly, to a distributed data accessing technique.
- 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 inFIG. 1 . In its simplest form, theaggregation model 10 includes acustomer 12, anaggregator 14, and a plurality ofbillers 16. Thecustomer 12 can be, for example, an individual person, a family, or a business. Theaggregator 14 can be a financial institution (FI) such as, for example, a bank. Alternatively, theaggregator 14 can be a separate entity which acts of behalf of asponsor 18, which can also be an FI such as a bank. Eachbiller 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. - Each
biller 16 provides customer-related invoice data to theaggregator 14. Theaggregator 14 serves: as an intermediary between eachbiller 16 and thecustomer 12 by providing bill presentment directly to thecustomer 12, potentially on behalf of thesponsor 18. - There are two variants of the
aggregation model 10 resulting from the ownership, or “branding”, of the presentation experience and the communication channel between theaggregator 14 and thecustomer 12. In one variant, theaggregator 14 may offer aggregator-branding, thus totally owning both the presentation experience and the communication channel between theaggregator 14 and thecustomer 12. In the other variant, theaggregator 14 may offer sponsor-branding, thus staying “behind the scenes” in terms of the presentation experience and supporting the communication channel between theaggregator 14 and thecustomer 12 on behalf of thesponsor 18. - The second prevalent model for electronic bill presentment is a biller
direct model 20, which is shown inFIG. 2 . In its simplest form, the billerdirect model 20 includes acustomer 12 and at least onebiller 16. In the billerdirect model 20, eachbiller 16 retains the customer-related invoice data and the full relationship with the customer 12 (i.e., the presentation experience and the communication channel). Thecustomer 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 theaggregator 14 of theaggregation model 10 described above. - 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 theaggregator 14 and/or thesponsor 18 to use customer-related invoice data, bill presentment, and the communication channel between theaggregator 14 and thecustomer 12 for cross-selling or other peripheral services. The billerdirect model 20, on the other hand, insures that control of customer-related invoice data, bill presentment, and the communication channel between thebiller 16 and thecustomer 12 remains with thebiller 16. - 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 withindividual billers 16 while retaining the benefits of interacting with asingle 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 acustomer 12 to retain the benefits of interacting with asingle aggregator 14 while allowing theaggregator 14,billers 16, andsponsor 18 to retain certain preferences such as, for example, the ability to retain control of customer-related data and a communication channel with eachcustomer 12. Accordingly, it would be desirable to provide a distributed data accessing technique which addresses the above-mentioned shortcomings of the above-described models. - 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-toend 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.
- 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 is 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.
- 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 inFIG. 4 , extended to include certain associated directly related systems. -
FIG. 7 is a schematic diagram of the electronic bill presentment and payment system shown inFIG. 4 , extended to include certain associated indirectly related systems. -
FIG. 8 is a schematic diagram of the electronic bill presentment and payment system shown inFIG. 4 , extended to include certain associated customer care entities. -
FIG. 9 is a schematic diagram of the electronic bill presentment and payment system shown inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 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 inFIG. 4 . - Referring to
FIG. 3 , there is shown an infrastructure diagram of a distributeddatabase entity 30 in accordance with the present invention. The distributeddatabase entity 30 comprises adatabase component 32 and a plurality of message interfaces 34-40 for facilitating communication between thedatabase component 32 and other distributed database entities and system components. Thedatabase component 32 typically contains data that is controlled or “owned” by the controller or “owner” of the distributeddatabase entity 30. For example, if the distributeddatabase entity 30 is owned by a financial institution (FI) such as a bank, then thedatabase component 32 could contain information such as checking and savings account balances. It should be noted, however, that thedatabase component 32 can also contain data from other distributed database entities and system components, as will be described in detail below. - The plurality of message interfaces 34-40 includes an
internal message interface 34, anexternal message interface 36, apartner message interface 38, and a customercare message interface 40. Theinternal message interface 34 defines messages that are used to communicate and query data between the given distributeddatabase 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. Theexternal message interface 36 defines messages that are used to communicate and query data between the given distributeddatabase entity 30 and any existing system(s) that are directly related to the given distributeddatabase entity 30. For example, an FI such as a bank can have an existing direct deposit account (DDA) system. Thepartner message interface 38 defines messages that are used to communicate and query data between the given distributeddatabase entity 30 and any existing system(s) that are indirectly related to the given distributeddatabase 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 customercare message interface 40 defines messages that are used to communicate and query data between the given distributeddatabase 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. - Referring to
FIG. 4 , there is shown a schematic diagram of a versatile electronic bill presentment andpayment system 50 in accordance with the present invention. Thesystem 50 comprises auser entity 52, abanking entity 54, abilling entity 56, and an electronic payment and customer service (EPCS)entity 58. For purposes of this detailed description, theuser entity 52, thebanking entity 54, thebilling entity 56, and theEPCS entity 58 are each distributeddatabase entities 30 as defined above. Thus, theuser entity 52, thebanking entity 54, thebilling entity 56, and theEPCS entity 58 each has adatabase component 32, aninternal message interface 34, anexternal message interface 36, apartner message interface 38, and a customercare message interface 40. It should be noted, however, that theuser entity 52, thebanking entity 54, thebilling entity 56, and theEPCS entity 58 are not required to have adatabase component 32, aninternal message interface 34, anexternal message interface 36, apartner message interface 38, and a customercare message interface 40. That is, theuser entity 52, thebanking entity 54, thebilling entity 56, and theEPCS entity 58 are only required to have aninternal message interface 34 so that communications can take place between each entity. - At this point it should be noted that, although only a
single user entity 52,banking entity 54,billing entity 56, andEPCS entity 58 is shown in thesystem 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. - As previously described, an
internal message interface 34 defines messages that are used to communicate and query data between distributed database entities. Thus, since theuser entity 52, thebanking entity 54, thebilling entity 56, and theEPCS entity 58 are all distributed database entities, they all communicate through internal message interfaces 34. The communications are performed overinterconnections 60, which can be electrical wire, optical fiber, or microwave-based interconnections. - At this point it should be noted that each
internal message interface 34, as well as eachexternal message interface 36,partner message interface 38, and customercare 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. - The
user entity 52 is typically a personal computer (PC) that is directly connected to thesystem 50, or is connected to thesystem 50 through a network server. Thus, thedatabase component 32 associated with theuser 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 thedatabase component 32 associated with theuser 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 thedatabase component 32 associated with theuser entity 52 can be distributed among all three of the above-listed locations, owing to the distributed nature of eachdatabase component 32. Thus, eachdatabase component 32 should not be thought of as a single, monolithic database. Rather, eachdatabase component 32 is better described as a distributed repository of data categorized by the entity that “owns” the data. - Wherever it is located, the
database component 32 associated with theuser entity 52 stores data that is related to the type of user interface (UI) that is being presented to a subscriber of thesystem 50. For example, thedatabase component 32 associated with theuser 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. Thedatabase component 32 associated with theuser 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. Thedatabase component 32 associated with theuser entity 52 can further store subscriber authentication data, which is described in detail below. - 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 thesystem 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. - 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 theuser entity 52 includes storing subscriber authentication data (e.g., a security ticket) that is used to gain access to other distributed database entities in thesystem 50. - 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 thesystem 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, thebanking entity 54 is assumed to be the aggregator of thesystem 50. It should be noted, however, that any one of the other entities could also be the aggregator of thesystem 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. - The
banking entity 54 typically gains access to thesystem 50 through a network server. Thus, thedatabase component 32 associated with thebanking entity 54 can be located in the network server. It should be noted that thedatabase component 32 associated with thebanking entity 54 can also be located in a system associated with thebanking entity 54 such as, for example, a DDA system. Such a DDA system could be accessed through theexternal message interface 36 of thebanking entity 54, as described in detail below. It should further be noted that thedatabase component 32 associated with thebanking 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 eachdatabase component 32. - Wherever it is located, the
database component 32 associated with thebanking entity 54 stores bank-specific subscriber profile data profile such as, for example, subscriber names and addresses and subscriber account numbers. Thedatabase component 32 associated with thebanking 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). Thedatabase component 32 associated with thebanking 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. - 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 thebanking 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, thebanking entity 54 also provides data to theuser 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 thebanking entity 54 can also provide data to theuser entity 52 to be used for the creation of a UI for traditional banking and bill payment. - Since the
banking entity 54 is generally viewed as the primary point of presence for a subscriber to thesystem 50, thebanking entity 54 also functions as the likely, but not exclusive, entry point for subscriber sign-on. Thus, thebanking entity 54 typically controls the sign-on and authentication procedures for subscribers through theuser entity 52. It should be noted that thebanking entity 54 typically works in conjunction with theEPCS entity 58 in controlling the authentication procedure, as described in detail below. - 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 theEPCS entity 58, as also described in detail below. - The
billing entity 56 is typically a biller such as, for example, a utility company. Thebilling entity 56 typically gains access to thesystem 50 through a network server. Thus, thedatabase component 32 associated with thebilling entity 56 can be located in the network server. It should be noted that thedatabase component 32 associated with thebilling entity 56 can also be located in a system associated with thebilling entity 56 such as, for example, a legacy billing system. Such a legacy billing system could be accessed through theexternal message interface 36 of thebilling entity 56, as described in detail below. It should further be noted that thedatabase component 32 associated with thebilling 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 eachdatabase component 32. - Wherever it is located, the
database component 32 associated with thebilling 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). Thedatabase component 32 associated with thebilling entity 56 also stores billing data for use by theuser 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. - The
database component 32 associated with thebilling entity 56 can also store biller transaction history such as, for example, bill data manipulation (e.g., viewing, searching, sorting), and cross-sell events. Thedatabase component 32 associated with thebilling entity 56 can further store biller profile data such as, for example, graphics, business rules, and relationships with aggregators such as banks. - The main function of the
billing entity 56 is to provide billing data to theuser entity 52 for use in creating the UI for the subscriber. Thebilling entity 56 also provides bill availability data to an aggregator database, whether it is located in thebanking entity 54, theEPCS entity 58, or another entity, to provide notice of bill availability to subscribers. Thebilling entity 56 can also access legacy billing systems through theexternal message interface 36 of thebilling entity 56, as indicated above. - 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 theEPCS entity 58, as described in detail below. - The
EPCS entity 58 can generally be described in terms of adata processing system 70, such as shown inFIG. 5 . Thedata 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 abus 78, for implementing the functions of theEPCS entity 58, as described in detail below. - Referring again to
FIG. 4 , theEPCS entity 58 typically gains access to thesystem 50 through a network server. Thus, thedatabase component 32 associated with theEPCS entity 58 can be located in the network server. It should be noted that thedatabase component 32 associated with theEPCS entity 58 can also be located in a system associated with theEPCS entity 58 such as, for example, a legacy aggregating system. Such a legacy aggregating system could be accessed through theexternal message interface 36 of theEPCS entity 58, as described in detail below. It should further be noted that thedatabase component 32 associated with theEPCS 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 eachdatabase component 32. - Wherever it is located, the
database component 32 associated with theEPCS 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. Thedatabase component 32 associated with theEPCS entity 58 also stores bill payment warehouse data such as, for example, user-specific payees, single occurrence payments, and recurring payments/models. - As previously described, both the
banking entity 54 and thebilling entity 56 track and store events in an event tracking database. This event tracking database is typically located in thedatabase component 32 associated with theEPCS 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. - The
database component 32 associated with theEPCS 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). Thedatabase component 32 associated with theEPCS 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 thebilling entity 56. Thedatabase component 32 associated with theEPCS entity 58 still further stores security data such as, for example, required sign-on information and macro-level authorizations. Thedatabase component 32 associated with theEPCS entity 58 additionally stores customer service data such as, for example, FAQ's, FI and biller contact information, and problem resolution data. - The
EPCS entity 58 is the glue that holds the distributed database entities together. TheEPCS 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 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 entity 58 functions as the authentication gate keeper. This doesn't mean to imply that theEPCS entity 58 necessarily maintains user identification numbers and/or passwords. However, it does imply that theEPCS entity 58 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 the
EPCS entity 58, but may still physically reside in a distributed manner across several of the database entities. - 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. - 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, eachinternal 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 aninternal message interface 34 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), 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 thesystem 50. Theuser entity 52 may also need to process an internal message to update any resident software. Theuser entity 52 may further need to process an internal message containing various types of information (assuming a push model). Theuser entity 52 may additionally need to process internal e-mail messages such as, for example, those for receiving data from other database entities. - 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. Thebanking 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. Thebanking entity 54 will further process an internal message to query/update bank subscriber profile data for purposes of customer care. Thebanking 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. Thebanking 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 theEPCS entity 58 to tailor the list by FI sponsor. Thebanking 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. - 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. Thebilling 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. Thebilling entity 56 will further process an internal message to query/update biller subscriber profile data for purposes of customer care. Thebilling 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. Thebilling 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. - 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, e-mail created/read/deleted data. - 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.). - The
EPCS entity 58 will also process internal security messages. Such internal security messages may relate to authentication, which result in the EPCS entity 0.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 thebanking entity 54. It may be initiated if a subscriber tries to gain access to thebilling entity 56, and thereby not even contacting thebanking entity 54. The point being that with a security ticket a subscriber is generally allowed to freely traverse any database entity in thesystem 50 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, the
billing entity 56 may, for whatever reason, require additional authentication information. - The
EPCS entity 58 will further process internal messages relating to aggregation data. For example, anEPCS 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 thebilling entity 56. - The
EPCS entity 58 will still further process an internal message to query/update bill payment transaction history for purposes of customer care. - 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. - 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). - As previously described, an
external message interface 36 defines messages that are used to communicate and query data between a given distributeddatabase entity 30 and any existing system(s) that are directly related to the given distributeddatabase entity 30. As also previously described, eachexternal 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. - Referring to
FIG. 6 , there is shown a schematic diagram of the versatile electronic bill presentment andpayment system 50, along with some associated directly related systems. The associated directly related systems comprise adesktop database 80, aDDA system 82, alegacy billing system 84, and alegacy remittance system 86. The communications between the various database entities and their associated directly related systems are performed overinterconnections 88, 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), the
user entity 52 may need to process an external message in order to communicate with an existing system such as, for example, thedesktop database 80. To support such a legacy system, it may be necessary to implement theexternal message interface 36 of theuser entity 52 in the context of an existing, and possibly extended, protocol specification, such as Gold, NPC, or OFX. - The
banking entity 54 will process external messages to and from an existing system such as, for example, theDDA 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 thebanking entity 54 would need to interface with other banking systems (e.g., stops). Thus, theexternal message interface 36 of thebanking entity 54 is a key feature of the versatile electronic bill presentment andpayment system 50. - The
billing entity 56 will process external messages to and from an existing system such as, for example, thelegacy 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, theexternal message interface 36 of thebilling entity 56 is a key feature of the versatile electronic bill presentment andpayment system 50. - The
EPCS entity 58 will process external messages to and from an existing system such as, for example, thelegacy remittance system 86. Thelegacy remittance system 86 could be, for example, ACH, RPP, RPS, or Direct Send. - As previously described, a
partner message interface 38 defines messages that are used to communicate and query data between a given distributeddatabase entity 30 and any existing system(s) that are indirectly related to the given distributeddatabase entity 30. As also previously described, eachpartner 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. - Referring to
FIG. 7 , there is shown a schematic diagram of the versatile electronic bill presentment andpayment system 50, along with some associated indirectly related systems. The associated indirectly related systems comprise apersonal finance system 90, abanking system 92, an establishedbilling aggregator 94, and an alternative bill presentment andpayment system 96. The communications between the various database entities and their associated indirectly related systems are performed overinterconnections 98, 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), the
user entity 52 may need to process a partner message in order to communicate with a partner such as, for example, thepersonal finance system 90. Thepersonal finance system 90 could be, for example, a personal financial manager (PFM) software package such as, for example, Quicken or Money. - The
banking entity 54 will process partner messages to and from a partner such as, for example, thebanking system 92. - The
billing entity 56 will process partner messages to and from a partner such as, for example, the establishedbilling aggregator 94. Such a partner relationship may be required if a large group of subscribers are using the establishedbilling aggregator 94, and thereby have the leverage to demand that all of their bills come through the establishedbilling aggregator 94. The establishedbilling aggregator 94 is essentially treated as a proxy for the billers that it represents. Thus, subscribers to the establishedbilling aggregator 94 will have equal footing as subscribers to thepresent system 50. This means that subscribers to the establishedbilling aggregator 94 will receive the same event tracking, customer service, and payment processing functionality as subscribers to presentsystem 50. Of course, to gain the additional functionality provided by thepresent system 50, the establishedbilling aggregator 94, or someone acting on their behalf, will need to provide the same programming support that is required of any biller participating in thepresent system 50. - To present a bill generated by the established
billing aggregator 94, thepresent system 50 would, for example, receive bill availability data and the URL of a web server of the establishedbilling aggregator 94, and thebilling entity 56 would then point to the web server of the establishedbilling aggregator 94 to get an HTML presentation of detailed bill data. In this scenario, thepartner message interface 38 would be essentially the same as aninternal message interface 34, but possibly with added bulk transfer capability. - The
EPCS entity 58 will process partner messages to and from a partner such as, for example, the alternative bill presentment andpayment system 96. Such a partner relationship may be required if abilling entity 56 has a subscriber base that is split between using thepresent system 50 and the alternative bill presentment andpayment system 96. In such a scenario, thepresent system 50 could function as a billing aggregator for the alternative bill presentment andpayment system 96, and vice-versa. However, the alternative bill presentment andpayment system 96 and its subscribers would not receive any of the benefits of the messaging functionality provided by thepresent system 50. Only the minimum amount of functionality would be provided. That is, thepartner message interface 38 would only provide what is required to present bills through the alternative bill presentment andpayment system 96, and not offer any of the advantages provided by thepresent system 50. The goal being to have thebilling entity 56 encourage all of its subscribers to access bills through thepresent system 50. - It should be noted that the
EPCS entity 58 will typically require the capabilities of abilling entity 56 in order to present bills to and from the alternative bill presentment andpayment system 96. - As previously described, a customer
care message interface 40 defines messages that are used to communicate and query data between a given distributeddatabase entity 30 and a customer care entity. As also previously described, each customercare 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. - Referring to
FIG. 8 , there is shown a schematic diagram of the versatile electronic bill presentment andpayment system 50, along with some associated customer care entities. The associated customer care entities comprise a user entityself service center 100, a banking entitycustomer service center 102, a billing entitycustomer service center 104, and an EPCScustomer service center 106. The communications between the various database entities and their associated customer care entities are performed overinterconnections 108, 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), 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 entityself service center 100. The user entityself service center 100 could be, for example, a self service diagnostic tool. - The
banking entity 54 will process customer care messages from a customer care entity such as, for example, the banking entitycustomer service center 102. A customer care message may be a request for data or a request to modify existing data. Thebanking 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 entitycustomer service center 102. The banking entitycustomer 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. - The
billing entity 56 will process customer care messages from a customer care entity such as, for example, the billing entitycustomer service center 104. A customer care message may be a request for data or a request to modify existing data. Thebilling 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 entitycustomer service center 104. The billing entitycustomer 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. - The
EPCS entity 58 will process customer care messages from a customer care entity such as, for example, the EPCS entitycustomer service center 106. A customer care message may be a request for data or a request to modify existing data. TheEPCS 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 entitycustomer service center 106. The EPCS entitycustomer 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. - 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 inFIG. 9 . In such an scenario, each of the database entities would process customer care messages to and from the centralizedcustomer service center 110 similar to as described above. The communications between the various database entities and the centralizedcustomer service center 110 would be performed overinterconnections 112, 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 thesystem 50. These flowchart diagrams assume that theuser entity 52 is an HTML browser client, thebanking entity 54 is the primary point of presence for a subscriber to thesystem 50, thebilling entity 56 controls bill presentment, and theEPCS entity 58 controls bill payment. - In
FIG. 10 , a subscriber at theuser entity 52 accesses the web site of thebanking entity 54 instep 200. In return, thebanking entity 54 presents a branded interface to theuser entity 52, including a sign-on request prompt instep 202.FIG. 16 shows an example of such a brandedinterface 120, wherein the sign-on request prompt includes ausername field 122 and apassword field 124. - In
FIG. 11 , theuser entity 52 submits a sign-on request with authentication credentials insteps 204. Thebanking entity 54 messages theEPCS entity 58 with the authentication credentials of the subscriber and the event is logged instep 206. TheEPCS entity 58 provides a security ticket to thebanking entity 54 instep 208. Thebanking entity 54 delivers the security ticket to theuser entity 52 and presents its “home page” touser entity 52 instep 210.FIG. 17 shows an example of such ahome page 130, which includes a “view bills”icon 132, a “view checking account”icon 134, and a “view savings account”icon 136. - It should be noted that either the
EPCS entity 58 or thebanking entity 54 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”icon 132 instep 212. Thebanking entity 54 messages theEPCS entity 58 with an aggregation data request and the event is logged instep 214. TheEPCS entity 58 presents aggregation data of new bill availability touser entity 52 in step 216.FIG. 18 shows a first modifiedhome page 140 having anEPCS 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. - In
FIG. 13A , the subscriber selects the “gas bill”icon 146 and is linked to thebilling entity 56 along with the security ticket instep 218. Thebilling entity 56 messages theEPCS entity 58 to log the “view bill” request event instep 220. Thebilling entity 56 presents detailed bill data to theuser entity 52 instep 222.FIG. 19 shows a second modifiedhome page 160 having abilling 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. - In
FIG. 14 , the subscriber selects the “pay bill”icon 164 and messages theEPCS entity 58 with a forward dated pay bill request so the event is logged instep 224. TheEPCS entity 58 messages thebilling entity 56 with a pay bill request notification along with a bill identification number instep 226. - In
FIG. 15 , the EPCS posts a debit with thebanking entity 54 and the event is logged instep 228. TheEPCS entity 58 then remits a payment to thebilling entity 56 and the event is logged instep 230. -
FIG. 13B can be substituted forFIG. 13A in the above-described sequence of flowchart diagrams to show how detailed bill data can be provided by the establishedbilling aggregator 94 thru thepartner message interface 38 of thebilling entity 56. InFIG. 13B , the subscriber again selects the “gas bill”icon 146 and is linked to thebilling entity 56 along with the security ticket instep 232. Thebilling entity 56 again messages theEPCS entity 58 to log the “view bill” request event instep 234. However, in this case, detailed bill data is available only from the establishedbilling aggregator 94. Thus, thebilling entity 56 accesses the establishedbilling aggregator 94 through itspartner message interface 38 instep 236. In response, the establishedbilling aggregator 94 provides detailed bill data to thebilling entity 56 instep 238. Thebilling entity 56 then presents the detailed bill data to theuser entity 52 instep 240. - It should be noted that, in an alternative embodiment, the established
billing aggregator 94 could present the detailed bill data directly to theuser entity 52. -
FIG. 13C can be substituted forFIG. 13A in the above-described sequence of flowchart diagrams to show how detailed bill data can be provided by the alternative bill presentment andpayment system 96 thru thepartner message interface 38 of theEPCS entity 58. InFIG. 13C , the subscriber selects the “gas bill”icon 146 and is linked back to theEPCS entity 58 along with the security ticket and the event is logged instep 242. In this case, detailed bill data is available only from the alternative bill presentment andpayment system 96. Thus, theEPCS entity 58 accesses the alternative bill presentment andpayment system 96 through itspartner message interface 38 instep 244. In response, the alternative bill presentment andpayment system 96 provides detailed bill data to theEPCS entity 58 instep 246. TheEPCS entity 58 then presents the detailed bill data to theuser entity 52 instep 248. - It should be noted that, as previously described, the
EPCS entity 58 will typically require the capabilities of abilling entity 56 in order to present bills to and from the alternative bill presentment andpayment system 96. Alternatively, it should be noted that detailed bill data can be provided by the alternative bill presentment andpayment system 96 thru thepartner message interface 38 of thebilling entity 56 in a manner similar to that as described inFIG. 13B . - Referring to
FIG. 20 , there is shown a flowchart diagram of data and message flows between the centralizedcustomer service center 110 and the various entities within thesystem 50. Asubscriber 170 contacts the centralizedcustomer service center 110 regarding a bill payment instep 250. The centralizedcustomer service center 110 accesses the event tracking database in theEPCS entity 58 to see if a view bill, pay bill, remit payment, or debit posting event has been logged instep 252. If more detailed information regarding, for example, the posting of a debit for a bill, the centralizedcustomer service center 110 can access thedatabase component 32 associated with thebanking entity 54, as shown instep 254. Similarly, if more detailed information regarding, for example, the remitting of a payment for a bill, the centralizedcustomer service center 110 can access thedatabase component 32 associated with thebilling entity 56, as shown instep 256. It should be noted that, although not shown, theEPCS entity 58 can log all of the above-described accesses performed by centralizedcustomer service center 110. - 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. Thesystem 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. - 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. - 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 (20)
1. A method for presenting and requesting payment of a bill over a communications network having a first network site associated with a bill payment entity, a second network site, which is different than the first network site, associated with a user, and a third network site, which is different than the first and the second network sites, associated with a bill presentment entity, which is different than the bill payment entity, comprising:
transmitting, from the second network site to the first network site, a first signal representing a request of the user for billing information;
transmitting, from the first network site to the second network site responsive to the transmitted first signal, a second signal representing a bill availability identifier for a bill of a biller for the user;
displaying the bill availability identifier represented by the transmitted second signal and receiving a first user input representing a selection of the displayed bill availability identifier, at the second network site;
transmitting, from the second network site to a third network site responsive to the received first user input, a third signal representing a request of the user for the identified bill;
transmitting, from the third network site to the second network site responsive to the transmitted third signal, a fourth signal representing the requested bill and an associated pay bill indicator;
displaying the bill and associated pay bill indicator represented by the transmitted fourth signal and receiving a second user input representing a selection of the displayed pay bill indicator, at the second network site; and
transmitting, from the second network site to the first network site responsive to the received second user input, a fifth signal representing a request of the user that the bill payment entity pay the displayed bill on behalf of the user.
2. The method of claim 1 , wherein:
the bill presentment entity is the biller.
3. The method of claim 1 , wherein:
the bill payment entity is a payment service provider capable of paying bills of multiple billers on behalf of multiple users.
4. The method of claim 1 , further comprising:
issuing, from the first network site responsive to the transmitted fifth signal, a sixth signal to initiate payment of the bill on behalf of the user by the bill payment entity.
5. The method of claim 4 , wherein:
the payment initiated by the issuing of the sixth signal is performed according to a payment process that includes the bill payment entity directing a debiting of funds in a demand deposit account of the user maintained by a financial institution.
6. The method of claim 5 , wherein:
the financial institution is a bank.
7. The method of claim 1 , further comprising:
transmitting, from the first network site to the third network site based on the transmitted fifth signal, a sixth signal representing a notification of receipt of the request to pay the bill of the biller on behalf of the user.
wherein the notification represented by the sixth signal includes an identification of the represented bill.
8. A networked system having multiple different network stations each associated with a different entity for presenting bills to user entities and requesting payment of presented bills on behalf of the user entities, comprising:
a wide area communications network;
a first network station associated with a user entity for transmitting, over the communications network, a first signal representing a request of the user entity for billing information;
a second network station associated with a bill payment entity for transmitting, over the communications network, a second signal representing a bill availability identifier for a bill of a biller for the user entity, responsive to the transmitted first signal, wherein the first network station (i) displays the bill availability identifier represented by the transmitted second signal, (ii) receives a first user entity input representing a selection of the displayed bill availability identifier and (iii) transmits, over the communications network, a third signal representing a request of the user entity for the bill of the biller responsive to the received first user entity input; and
a third network station associated with a bill presentment entity for transmitting, over the communications network, a fourth signal representing the bill of the biller for the user entity and an associated pay bill indicator, responsive to the transmitted third signal;
wherein the first network station (i) displays the bill and the associated pay bill indicator represented by the transmitted fourth signal, (ii) receives a second user entity input representing a selection of the displayed pay bill indicator and (iii) transmits, over the communications network, a fifth signal representing a request to pay the displayed bill of the biller on behalf of the user entity, responsive to the second user entity input;
wherein the second network station issues a sixth signal to initiate payment of the bill by the bill payment entity on behalf of the user entity responsive to the transmitted fifth signal.
9. The system of claim 8 , wherein:
the bill presentment entity is the biller.
10. The system of claim 8 , wherein:
the bill payment entity is a payment service provider capable of paying bills of multiple billers on behalf of multiple user entities.
11. The system of claim 8 , wherein:
the payment initiated by the issuing of the sixth signal is performed according to a payment process that includes the bill payment entity directing a debiting of funds in a demand deposit account of the user entity maintained by a financial institution.
12. The system of claim 8 , wherein:
the financial institution is a bank.
13. The system of claim 8 , wherein:
the second network station transmits, to the third network station over the communications network, a seventh signal representing a notification of receipt of the request to pay the bill of the biller on behalf of the user entity represented by the transmitted fifth signal.
14. The method of claim 13 , wherein:
the notification represented by the seventh signal includes an identification of the represented bill.
15. A method for presenting bills to users and requesting payment of presented bills on behalf of the users over a communications network, comprising:
transmitting a first message, representing a request of a user for billing information, over the communications network to a bill payment entity;
transmitting a second message, in reply to the first message and representing a bill availability identifier for a bill of a biller for the user, over the communications network to the user;
transmitting a third message, representing a request of the user for the bill of the biller identified by the bill availability identifier represented by the transmitted second message, over the communications network to a bill presentment entity different than the bill payment entity;
transmitting a fourth message, in reply to the third message and representing the bill of the biller for the user and an associated selectable pay bill request indicator, over the communications network to the user; and
transmitting, a fifth message, representing a selection of the pay bill request indicator represented by the transmitted fourth message, over the communications network to the bill payment entity.
16. The method of claim 15 , wherein:
the selection of the pay bill request indicator represented by the transmitted fourth message activates a hyperlink via which the fifth message is transmitted.
17. The method of claim 15 , wherein:
the selection of the pay bill request indicator is represented in the transmitted fifth message as a request to pay the bill of the biller represented by the transmitted fourth message on behalf of the user.
18. The method of claim 15 , further comprising:
debiting, by the bill payment entity, of funds in a demand deposit account of the user maintained by a financial institution, based on the selection of the pay bill request indicator represented by the transmitted fifth message.
19. The method of claim 15 , further comprising:
transmitting a sixth message representing a notification of receipt by the bill payment entity of the transmitted fifth message representing the selection of the pay bill request indicator, over the communications network to the bill presentment entity.
20. The method of claim 19 , wherein:
the notification represented by the sixth message includes an identification of the represented bill.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/057,233 US20050137978A1 (en) | 1998-02-02 | 2005-02-15 | Presentation and payment of bills over a wide area communications network |
US11/059,370 US7778901B2 (en) | 1998-02-02 | 2005-02-17 | Integrated electronic presentment and payment of bills by different entities |
US11/534,159 US20070121840A1 (en) | 1998-02-02 | 2006-09-21 | Storing notice of remittance received in a distributed data network |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/017,169 US6055567A (en) | 1998-02-02 | 1998-02-02 | Distributed data accessing technique |
US09/301,068 US6856974B1 (en) | 1998-02-02 | 1999-04-28 | Electronic bill presentment technique with enhanced biller control |
US11/057,233 US20050137978A1 (en) | 1998-02-02 | 2005-02-15 | Presentation and payment of bills over a wide area communications network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/301,068 Continuation US6856974B1 (en) | 1998-02-02 | 1999-04-28 | Electronic bill presentment technique with enhanced biller control |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/059,370 Continuation US7778901B2 (en) | 1998-02-02 | 2005-02-17 | Integrated electronic presentment and payment of bills by different entities |
US11/534,159 Continuation US20070121840A1 (en) | 1998-02-02 | 2006-09-21 | Storing notice of remittance received in a distributed data network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050137978A1 true US20050137978A1 (en) | 2005-06-23 |
Family
ID=34114822
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/301,068 Expired - Fee Related US6856974B1 (en) | 1998-02-02 | 1999-04-28 | Electronic bill presentment technique with enhanced biller control |
US10/645,521 Expired - Fee Related US7657484B2 (en) | 1998-02-02 | 2003-08-22 | Electronic bill presentment via a wide area communications network |
US11/057,233 Abandoned US20050137978A1 (en) | 1998-02-02 | 2005-02-15 | Presentation and payment of bills over a wide area communications network |
US11/059,370 Expired - Fee Related US7778901B2 (en) | 1998-02-02 | 2005-02-17 | Integrated electronic presentment and payment of bills by different entities |
US11/534,159 Abandoned US20070121840A1 (en) | 1998-02-02 | 2006-09-21 | Storing notice of remittance received in a distributed data network |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/301,068 Expired - Fee Related US6856974B1 (en) | 1998-02-02 | 1999-04-28 | Electronic bill presentment technique with enhanced biller control |
US10/645,521 Expired - Fee Related US7657484B2 (en) | 1998-02-02 | 2003-08-22 | Electronic bill presentment via a wide area communications network |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/059,370 Expired - Fee Related US7778901B2 (en) | 1998-02-02 | 2005-02-17 | Integrated electronic presentment and payment of bills by different entities |
US11/534,159 Abandoned US20070121840A1 (en) | 1998-02-02 | 2006-09-21 | Storing notice of remittance received in a distributed data network |
Country Status (1)
Country | Link |
---|---|
US (5) | US6856974B1 (en) |
Cited By (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080010204A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Making a Payment Via a Paper Check in a Mobile Environment |
US20080040265A1 (en) * | 2006-07-06 | 2008-02-14 | Firethorn Holdings, Llc | Methods and Systems For Making a Payment Via A Stored Value Card in a Mobile Environment |
US20080183621A1 (en) * | 2007-01-28 | 2008-07-31 | Evans Steven D | Payer direct hub |
WO2009042434A1 (en) * | 2007-09-28 | 2009-04-02 | The Western Union Company | Bill payment aggregation service |
US20090327111A1 (en) * | 2007-09-28 | 2009-12-31 | The Western Union Company | Bill payment in association with television service providers systems and methods |
US20100042547A1 (en) * | 2008-08-12 | 2010-02-18 | The Western Union Company | Methods and systems for money transfer with cable and/or satellite providers |
US7979348B2 (en) | 2002-04-23 | 2011-07-12 | Clearing House Payments Co Llc | Payment identification code and payment system using the same |
US20110196768A1 (en) * | 2007-04-10 | 2011-08-11 | Invoice Compliance Experts | Legal billing enhancement method and apparatus |
US8121945B2 (en) | 2006-07-06 | 2012-02-21 | Firethorn Mobile, Inc. | Methods and systems for payment method selection by a payee in a mobile environment |
US20120066120A1 (en) * | 2010-09-09 | 2012-03-15 | Boku, Inc. | Systems and methods to process payments via a communication system |
US8145568B2 (en) | 2006-07-06 | 2012-03-27 | Firethorn Mobile, Inc. | Methods and systems for indicating a payment in a mobile environment |
US8160959B2 (en) | 2006-07-06 | 2012-04-17 | Firethorn Mobile, Inc. | Methods and systems for payment transactions in a mobile environment |
US20120310833A1 (en) * | 2004-01-07 | 2012-12-06 | Precash, Inc. | System and method for facilitating large scale payment transactions |
US8467766B2 (en) | 2006-07-06 | 2013-06-18 | Qualcomm Incorporated | Methods and systems for managing payment sources in a mobile environment |
US8489067B2 (en) | 2006-07-06 | 2013-07-16 | Qualcomm Incorporated | Methods and systems for distribution of a mobile wallet for a mobile device |
US8510220B2 (en) | 2006-07-06 | 2013-08-13 | Qualcomm Incorporated | Methods and systems for viewing aggregated payment obligations in a mobile environment |
US8595134B2 (en) | 2010-02-12 | 2013-11-26 | Mastercard International Incorporated | Apparatus and method for bill presentment and payment |
US20130333006A1 (en) * | 2012-06-07 | 2013-12-12 | Authentify, Inc. | Enterprise triggered 2chk association |
US8676672B2 (en) | 2007-08-23 | 2014-03-18 | E2Interactive, Inc. | Systems and methods for electronic delivery of stored value |
US8725607B2 (en) | 2004-01-30 | 2014-05-13 | The Clearing House Payments Company LLC | Electronic payment clearing and check image exchange systems and methods |
US9443268B1 (en) | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US9749391B2 (en) | 2000-03-29 | 2017-08-29 | Mastercard International Incorporated | Method and system for processing messages in a bill payment and presentment system over a communications network |
US10068287B2 (en) | 2010-06-11 | 2018-09-04 | David A. Nelsen | Systems and methods to manage and control use of a virtual card |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US10671749B2 (en) | 2018-09-05 | 2020-06-02 | Consumerinfo.Com, Inc. | Authenticated access and aggregation database platform |
US10937076B2 (en) | 2010-10-13 | 2021-03-02 | E2Interactive, Inc. | Online personalized gifting system |
US10943438B2 (en) | 2012-09-04 | 2021-03-09 | E2Interactive, Inc. | Processing of a game-playing transaction based on location |
US10943432B2 (en) | 2012-09-04 | 2021-03-09 | E2Interactive, Inc. | Processing of a game-playing transaction based on location |
US10954049B2 (en) | 2017-12-12 | 2021-03-23 | E2Interactive, Inc. | Viscous liquid vessel for gifting |
US11017443B2 (en) | 2014-04-30 | 2021-05-25 | E2Interactive, Inc. | System and method for a merchant onsite personalization gifting platform |
US11037397B2 (en) | 2012-09-04 | 2021-06-15 | E2Interactive, Inc. | Processing of a user device game-playing transaction based on location |
US11042882B2 (en) | 2015-07-01 | 2021-06-22 | The Clearing House Payments Company, L.L.C. | Real-time payment system, method, apparatus, and computer program |
US11111065B2 (en) | 2013-02-15 | 2021-09-07 | E2Interactive, Inc. | Gift card presentation devices |
US11120428B2 (en) | 2013-05-02 | 2021-09-14 | E2Interactive, Inc. | Stored value card kiosk system and method |
US11182836B2 (en) | 2010-10-13 | 2021-11-23 | E2Interactive, Inc. | Gift card ordering system and method |
US11219288B2 (en) | 2013-02-15 | 2022-01-11 | E2Interactive, Inc. | Gift card box with slanted tray and slit |
US11250666B2 (en) | 2013-03-15 | 2022-02-15 | E2Interactive, Inc. | Systems and methods for location-based game play on computing devices |
US11295308B1 (en) | 2014-10-29 | 2022-04-05 | The Clearing House Payments Company, L.L.C. | Secure payment processing |
US11436651B2 (en) | 2012-01-30 | 2022-09-06 | E2Interactive, Inc. | Group video generating system |
US11436577B2 (en) | 2018-05-03 | 2022-09-06 | The Clearing House Payments Company L.L.C. | Bill pay service with federated directory model support |
US11694168B2 (en) | 2015-07-01 | 2023-07-04 | The Clearing House Payments Company L.L.C. | Real-time payment system, method, apparatus, and computer program |
US11928696B2 (en) | 2009-12-16 | 2024-03-12 | E2Interactive, Inc. | Systems and methods for generating a virtual value item for a promotional campaign |
Families Citing this family (92)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8271339B2 (en) * | 1995-11-13 | 2012-09-18 | Lakshmi Arunachalam | Method and apparatus for enabling real-time bi-directional transactions on a network |
US8037158B2 (en) * | 1995-11-13 | 2011-10-11 | Lakshmi Arunachalam | Multimedia transactional services |
US7930340B2 (en) * | 1995-11-13 | 2011-04-19 | Lakshmi Arunachalam | Network transaction portal to control multi-service provider transactions |
US6856974B1 (en) * | 1998-02-02 | 2005-02-15 | Checkfree Corporation | Electronic bill presentment technique with enhanced biller control |
GB9806843D0 (en) * | 1998-03-24 | 1998-05-27 | Kal | Software application development system |
US8095391B2 (en) * | 1998-08-05 | 2012-01-10 | Ccc Information Services, Inc. | System and method for performing reinspection in insurance claim processing |
EP1049056A3 (en) | 1999-04-26 | 2001-06-13 | CheckFree Corporation | Electronic bill presentment and/or payment clearinghouse |
US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
US20080215472A1 (en) * | 2000-06-27 | 2008-09-04 | Nicholas Ahthony Lindsay Brown | Variable use advanced messaging system and method |
KR100449786B1 (en) * | 2000-11-23 | 2004-09-22 | 인터내셔널 비지네스 머신즈 코포레이션 | System and method for performing personal finance management using the Internet |
US7912193B2 (en) | 2001-02-27 | 2011-03-22 | Verizon Data Services Llc | Methods and systems for call management with user intervention |
US8761363B2 (en) | 2001-02-27 | 2014-06-24 | Verizon Data Services Llc | Methods and systems for automatic forwarding of communications to a preferred device |
US8494135B2 (en) | 2001-02-27 | 2013-07-23 | Verizon Data Services Llc | Methods and systems for contact management |
US7903796B1 (en) | 2001-02-27 | 2011-03-08 | Verizon Data Services Llc | Method and apparatus for unified communication management via instant messaging |
US8472428B2 (en) | 2001-02-27 | 2013-06-25 | Verizon Data Services Llc | Methods and systems for line management |
US8751571B2 (en) | 2001-02-27 | 2014-06-10 | Verizon Data Services Llc | Methods and systems for CPN triggered collaboration |
US8774380B2 (en) | 2001-02-27 | 2014-07-08 | Verizon Patent And Licensing Inc. | Methods and systems for call management with user intervention |
US7912199B2 (en) * | 2002-11-25 | 2011-03-22 | Telesector Resources Group, Inc. | Methods and systems for remote cell establishment |
US8488761B2 (en) | 2001-02-27 | 2013-07-16 | Verizon Data Services Llc | Methods and systems for a call log |
US6976017B1 (en) | 2001-02-27 | 2005-12-13 | Verizon Data Services Inc. | Method and apparatus for context based querying |
US8750482B2 (en) | 2001-02-27 | 2014-06-10 | Verizon Data Services Llc | Methods and systems for preemptive rejection of calls |
US8503650B2 (en) | 2001-02-27 | 2013-08-06 | Verizon Data Services Llc | Methods and systems for configuring and providing conference calls |
US8503639B2 (en) | 2001-02-27 | 2013-08-06 | Verizon Data Services Llc | Method and apparatus for adaptive message and call notification |
US8798251B2 (en) | 2001-02-27 | 2014-08-05 | Verizon Data Services Llc | Methods and systems for computer enhanced conference calling |
US8467502B2 (en) | 2001-02-27 | 2013-06-18 | Verizon Data Services Llc | Interactive assistant for managing telephone communications |
US8488766B2 (en) | 2001-02-27 | 2013-07-16 | Verizon Data Services Llc | Methods and systems for multiuser selective notification |
US8873730B2 (en) * | 2001-02-27 | 2014-10-28 | Verizon Patent And Licensing Inc. | Method and apparatus for calendared communications flow control |
US8472606B2 (en) | 2001-02-27 | 2013-06-25 | Verizon Data Services Llc | Methods and systems for directory information lookup |
US20020194127A1 (en) * | 2001-04-30 | 2002-12-19 | Randell Wayne L. | Method and system for processing invoices |
US20020194126A1 (en) * | 2001-04-30 | 2002-12-19 | Randell Wayne L. | Method and system for handling invoices |
US20020198830A1 (en) * | 2001-05-01 | 2002-12-26 | Randell Wayne L. | Method and system for handling disputes in an electronic invoice management system |
US7120928B2 (en) | 2001-06-15 | 2006-10-10 | Dinesh Sheth | Secure selective sharing of account information on an internet information aggregation system |
US20020194226A1 (en) * | 2001-06-15 | 2002-12-19 | Dinesh Sheth | Internet information aggregation system using programmatic data extraction |
US7287005B1 (en) * | 2001-06-29 | 2007-10-23 | Aol Llc, A Delaware Limited Liability Company | Method for supplementing descriptors for online banking transaction statements |
US6750897B1 (en) | 2001-08-16 | 2004-06-15 | Verizon Data Services Inc. | Systems and methods for implementing internet video conferencing using standard phone calls |
US9392120B2 (en) | 2002-02-27 | 2016-07-12 | Verizon Patent And Licensing Inc. | Methods and systems for call management with user intervention |
CA2406105A1 (en) * | 2002-09-30 | 2004-03-30 | Canadian National Railway Company | Method and system for generating account reconciliation data |
US7729996B2 (en) * | 2002-11-01 | 2010-06-01 | Checkfree Corporation | Reuse of an EBP account through alternate authentication |
US7526448B2 (en) | 2002-11-01 | 2009-04-28 | Checkfree Corporation | Matching consumers with billers having bills available for electronic presentment |
US8073773B2 (en) | 2002-11-01 | 2011-12-06 | Checkfree Corporation | Technique for identifying probable billers of a consumer |
US20040139011A1 (en) * | 2002-11-01 | 2004-07-15 | Kozee Casey W. | Technique for identifying probable payees of a consumer |
US7340422B2 (en) | 2003-02-10 | 2008-03-04 | Asentinel Llc | Systems and method for managing and processing of telecommunications invoices |
US20060195396A1 (en) * | 2005-02-28 | 2006-08-31 | Checkfree Corporation | Centralized customer care for electronic payments and other transactions via a wide area communications network |
US20060195395A1 (en) * | 2005-02-28 | 2006-08-31 | Checkfree Corporation | Facilitating electronic payment on behalf of a customer of electronic presented bills |
US20100280946A1 (en) * | 2005-08-11 | 2010-11-04 | Mpay Pty Limited | Transaction authorisation system |
US7734045B2 (en) | 2006-05-05 | 2010-06-08 | Tricipher, Inc. | Multifactor split asymmetric crypto-key with persistent key security |
US7571471B2 (en) * | 2006-05-05 | 2009-08-04 | Tricipher, Inc. | Secure login using a multifactor split asymmetric crypto-key with persistent key security |
US20080010191A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Providing a Payment in a Mobile Environment |
US20080006685A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Real Time Account Balances in a Mobile Environment |
JP2010536110A (en) | 2007-08-12 | 2010-11-25 | エルビズリ,サメール | System and method for offsetting invoice debt |
US8166118B1 (en) | 2007-10-26 | 2012-04-24 | Sendside Networks Inc. | Secure communication architecture, protocols, and methods |
US7991768B2 (en) * | 2007-11-08 | 2011-08-02 | Oracle International Corporation | Global query normalization to improve XML index based rewrites for path subsetted index |
US20090192911A1 (en) * | 2008-01-29 | 2009-07-30 | Revolution Money Inc. | Payment redirection for online transactions |
US8239322B2 (en) | 2008-02-20 | 2012-08-07 | Pitney Bowes Inc. | Method of postal payment for set of customized postage |
US20110106677A1 (en) * | 2008-08-08 | 2011-05-05 | Elbizri Samer | System and method of offsetting invoice obligations |
EP2344992A4 (en) * | 2008-09-05 | 2012-08-01 | Giftango Corp | Systems and methods for authentication of a virtual stored value card |
US20100076833A1 (en) * | 2008-09-19 | 2010-03-25 | Giftango Corporation | Systems and methods for managing and using a virtual card |
WO2010036737A2 (en) * | 2008-09-26 | 2010-04-01 | Giftango Corporation | System and methods for managing a virtual card based on geographical information |
US20100125514A1 (en) * | 2008-11-14 | 2010-05-20 | Bank Of America Corporation | Least Cost Routing of Fund Transfer Transactions |
US20110238568A1 (en) * | 2008-11-14 | 2011-09-29 | Bank Of America Corporation | Enhanced Optimized Routing With Volume Controls |
US20100138321A1 (en) * | 2008-12-01 | 2010-06-03 | Pitney Bowes Inc. | Method of postal fraud detection for stamps activated at point of sale |
US9344416B2 (en) * | 2012-01-11 | 2016-05-17 | Intel Corporation | File vault and cloud based document notary service |
US10970688B2 (en) | 2012-03-07 | 2021-04-06 | Early Warning Services, Llc | System and method for transferring funds |
US10395247B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | Systems and methods for facilitating a secure transaction at a non-financial institution system |
US9691056B2 (en) | 2012-03-07 | 2017-06-27 | Clearxchange, Llc | System and method for transferring funds |
US10318936B2 (en) | 2012-03-07 | 2019-06-11 | Early Warning Services, Llc | System and method for transferring funds |
US10395223B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | System and method for transferring funds |
US11593800B2 (en) | 2012-03-07 | 2023-02-28 | Early Warning Services, Llc | System and method for transferring funds |
US10748127B2 (en) | 2015-03-23 | 2020-08-18 | Early Warning Services, Llc | Payment real-time funds availability |
US20190378182A1 (en) * | 2015-03-23 | 2019-12-12 | Early Warning Services, Llc | Secure electronic billing with real-time funds availability |
US10878387B2 (en) | 2015-03-23 | 2020-12-29 | Early Warning Services, Llc | Real-time determination of funds availability for checks and ACH items |
US10769606B2 (en) | 2015-03-23 | 2020-09-08 | Early Warning Services, Llc | Payment real-time funds availability |
US10832246B2 (en) | 2015-03-23 | 2020-11-10 | Early Warning Services, Llc | Payment real-time funds availability |
US10839359B2 (en) | 2015-03-23 | 2020-11-17 | Early Warning Services, Llc | Payment real-time funds availability |
US11157884B2 (en) | 2015-07-21 | 2021-10-26 | Early Warning Services, Llc | Secure transactions with offline device |
US10963856B2 (en) | 2015-07-21 | 2021-03-30 | Early Warning Services, Llc | Secure real-time transactions |
US10956888B2 (en) | 2015-07-21 | 2021-03-23 | Early Warning Services, Llc | Secure real-time transactions |
US11386410B2 (en) | 2015-07-21 | 2022-07-12 | Early Warning Services, Llc | Secure transactions with offline device |
US11062290B2 (en) | 2015-07-21 | 2021-07-13 | Early Warning Services, Llc | Secure real-time transactions |
US10970695B2 (en) | 2015-07-21 | 2021-04-06 | Early Warning Services, Llc | Secure real-time transactions |
US10438175B2 (en) | 2015-07-21 | 2019-10-08 | Early Warning Services, Llc | Secure real-time payment transactions |
US11037122B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
US11037121B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
US11151522B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
US11151523B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
US20170316392A1 (en) * | 2016-04-29 | 2017-11-02 | Intuit Inc. | Method and system for integrating business invoices into a personal financial management and bill payment system |
US11151566B2 (en) | 2016-09-19 | 2021-10-19 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
CN113112254A (en) * | 2016-11-11 | 2021-07-13 | 创新先进技术有限公司 | Regional message sharing method and device |
US11393046B1 (en) | 2017-01-17 | 2022-07-19 | Intuit Inc. | System and method for perpetual rekeying of various data columns with a frequency and encryption strength based on the sensitivity of the data columns |
US10303895B1 (en) | 2017-01-19 | 2019-05-28 | Intuit Inc. | System and method for perpetual rekeying of various data columns with respective encryption keys and on alternating bases |
US10825104B1 (en) | 2017-02-16 | 2020-11-03 | Intuit Inc. | Method and system for integrating invoice related financial transaction data into a personal financial management and bill payment system and using the payment source to more accurately identify and categorize tax related financial transactions using the payment method |
CN110766318A (en) * | 2019-10-22 | 2020-02-07 | 北京牛卡福网络科技有限公司 | Enterprise terminal, medium and computing device based on vehicle refueling management |
Citations (91)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US528829A (en) * | 1894-11-06 | Plane | ||
US3852571A (en) * | 1970-05-18 | 1974-12-03 | Hempstead Bank | System of transferral of funds |
US4277837A (en) * | 1977-12-30 | 1981-07-07 | International Business Machines Corporation | Personal portable terminal for financial transactions |
US4319336A (en) * | 1979-02-02 | 1982-03-09 | International Business Machines Corporation | Transaction execution system with improved key function versatility |
US4460960A (en) * | 1979-02-02 | 1984-07-17 | International Business Machines Corporation | Transaction execution system having keyboard and message customization, improved key function versatility and message segmentation |
US4701601A (en) * | 1985-04-26 | 1987-10-20 | Visa International Service Association | Transaction card with magnetic stripe emulator |
US4734564A (en) * | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
US4734858A (en) * | 1983-12-05 | 1988-03-29 | Portel Services Network, Inc. | Data terminal and system for placing orders |
US4747050A (en) * | 1983-09-17 | 1988-05-24 | International Business Machines Corporation | Transaction security system using time variant parameter |
US4775935A (en) * | 1986-09-22 | 1988-10-04 | Westinghouse Electric Corp. | Video merchandising system with variable and adoptive product sequence presentation order |
US4799156A (en) * | 1986-10-01 | 1989-01-17 | Strategic Processing Corporation | Interactive market management system |
US4812628A (en) * | 1985-05-02 | 1989-03-14 | Visa International Service Association | Transaction system with off-line risk assessment |
US4822985A (en) * | 1987-01-06 | 1989-04-18 | Visa International Service Association | Transaction approval system |
US4922940A (en) * | 1989-07-31 | 1990-05-08 | Lewy Michael M | Invalid walker |
US4947028A (en) * | 1988-07-19 | 1990-08-07 | Arbor International, Inc. | Automated order and payment system |
US4961142A (en) * | 1988-06-29 | 1990-10-02 | Mastercard International, Inc. | Multi-issuer transaction device with individual identification verification plug-in application modules for each issuer |
US5025373A (en) * | 1988-06-30 | 1991-06-18 | Jml Communications, Inc. | Portable personal-banking system |
US5206488A (en) * | 1989-06-07 | 1993-04-27 | Mordechai Teicher | Credit card system including a central unit and a plurality of local units for conducting low-cost transactions |
US5220501A (en) * | 1989-12-08 | 1993-06-15 | Online Resources, Ltd. | Method and system for remote delivery of retail banking services |
US5231571A (en) * | 1990-08-14 | 1993-07-27 | Personal Financial Assistant, Inc. | Personal financial assistant computer method |
US5255182A (en) * | 1992-01-31 | 1993-10-19 | Visa International Service Association | Payment card point-of-sale service quality monitoring system, apparatus, and method |
US5287270A (en) * | 1989-08-14 | 1994-02-15 | Compucom Communications Corp. | Billing system |
US5319542A (en) * | 1990-09-27 | 1994-06-07 | International Business Machines Corporation | System for ordering items using an electronic catalogue |
US5326959A (en) * | 1992-08-04 | 1994-07-05 | Perazza Justin J | Automated customer initiated entry remittance processing system |
US5329589A (en) * | 1991-02-27 | 1994-07-12 | At&T Bell Laboratories | Mediation of transactions by a communications system |
US5336870A (en) * | 1992-05-26 | 1994-08-09 | Hughes Thomas S | System for remote purchase payment transactions and remote bill payments |
US5341429A (en) * | 1992-12-04 | 1994-08-23 | Testdrive Corporation | Transformation of ephemeral material |
US5347632A (en) * | 1988-07-15 | 1994-09-13 | Prodigy Services Company | Reception system for an interactive computer network and method of operation |
US5383113A (en) * | 1991-07-25 | 1995-01-17 | Checkfree Corporation | System and method for electronically providing customer services including payment of bills, financial analysis and loans |
US5420405A (en) * | 1993-02-26 | 1995-05-30 | Chasek; Norman E. | Secure, automated transaction system that supports an electronic currency operating in mixed debit & credit modes |
US5420926A (en) * | 1994-01-05 | 1995-05-30 | At&T Corp. | Anonymous credit card transactions |
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5465206A (en) * | 1993-11-01 | 1995-11-07 | Visa International | Electronic bill pay system |
US5483445A (en) * | 1992-10-22 | 1996-01-09 | American Express Trs | Automated billing consolidation system and method |
US5500513A (en) * | 1994-05-11 | 1996-03-19 | Visa International | Automated purchasing control system |
US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5613012A (en) * | 1994-11-28 | 1997-03-18 | Smarttouch, Llc. | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
US5649117A (en) * | 1994-06-03 | 1997-07-15 | Midwest Payment Systems | System and method for paying bills and other obligations including selective payor and payee controls |
US5655089A (en) * | 1992-04-10 | 1997-08-05 | Bucci; Joseph J. | Method for the consolidation summarization and transmission of a plurality of mailable materials |
US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
US5692132A (en) * | 1995-06-07 | 1997-11-25 | Mastercard International, Inc. | System and method for conducting cashless transactions on a computer network |
US5710887A (en) * | 1995-08-29 | 1998-01-20 | Broadvision | Computer system and method for electronic commerce |
US5710889A (en) * | 1995-02-22 | 1998-01-20 | Citibank, N.A. | Interface device for electronically integrating global financial services |
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US5717989A (en) * | 1994-10-13 | 1998-02-10 | Full Service Trade System Ltd. | Full service trade system |
US5724424A (en) * | 1993-12-16 | 1998-03-03 | Open Market, Inc. | Digital active advertising |
US5723400A (en) * | 1995-02-21 | 1998-03-03 | Montell North America Inc. | Process for the preparation of a solid catalyst component suitable for the polymerization of olefins which includes at least two additions of an electron donor |
US5727249A (en) * | 1992-10-15 | 1998-03-10 | Pollin; Robert E. | Automated payment system and method |
US5727163A (en) * | 1995-03-30 | 1998-03-10 | Amazon.Com, Inc. | Secure method for communicating credit card data when placing an order on a non-secure network |
US5729594A (en) * | 1996-06-07 | 1998-03-17 | Klingman; Edwin E. | On-line secured financial transaction system through electronic media |
US5768521A (en) * | 1994-05-16 | 1998-06-16 | Intel Corporation | General purpose metering mechanism for distribution of electronic information |
US5768385A (en) * | 1995-08-29 | 1998-06-16 | Microsoft Corporation | Untraceable electronic cash |
US5794221A (en) * | 1995-07-07 | 1998-08-11 | Egendorf; Andrew | Internet billing method |
US5815665A (en) * | 1996-04-03 | 1998-09-29 | Microsoft Corporation | System and method for providing trusted brokering services over a distributed network |
US5826245A (en) * | 1995-03-20 | 1998-10-20 | Sandberg-Diment; Erik | Providing verification information for a transaction |
US5832089A (en) * | 1995-06-07 | 1998-11-03 | Sandia Corporation | Off-line compatible electronic cash method and system |
US5832460A (en) * | 1995-06-02 | 1998-11-03 | International Business Machines Corporation | Method and system for bill presentation and payment reconciliation |
US5842185A (en) * | 1993-02-18 | 1998-11-24 | Intuit Inc. | Method and system for electronically tracking financial transactions |
US5884288A (en) * | 1996-07-01 | 1999-03-16 | Sun Microsystems, Inc. | Method and system for electronic bill payment |
US5893080A (en) * | 1995-07-25 | 1999-04-06 | Bottomline Technologies, Inc. | Disbursement system and method |
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
US5903732A (en) * | 1996-07-03 | 1999-05-11 | Hewlett-Packard Company | Trusted gateway agent for web server programs |
US5920847A (en) * | 1993-11-01 | 1999-07-06 | Visa International Service Association | Electronic bill pay system |
US5931917A (en) * | 1996-09-26 | 1999-08-03 | Verifone, Inc. | System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser |
US5943656A (en) * | 1997-12-03 | 1999-08-24 | Avista Advantage, Inc. | Methods and systems for computerized bill consolidating, billing and payment authorization, computerized utility bill consolidating, utility billing access and payment and utility provider consolidated billing systems |
US5963925A (en) * | 1996-10-09 | 1999-10-05 | Visa International Service Association | Electronic statement presentment system |
US5974146A (en) * | 1997-07-30 | 1999-10-26 | Huntington Bancshares Incorporated | Real time bank-centric universal payment system |
US5978780A (en) * | 1997-11-21 | 1999-11-02 | Craig Michael Watson | Integrated bill consolidation, payment aggregation, and settlement system |
US5987430A (en) * | 1997-08-28 | 1999-11-16 | Atcom, Inc. | Communications network connection system and method |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US6029151A (en) * | 1996-12-13 | 2000-02-22 | Telefonaktiebolaget L M Ericsson | Method and system for performing electronic money transactions |
US6035285A (en) * | 1997-12-03 | 2000-03-07 | Avista Advantage, Inc. | Electronic bill presenting methods and bill consolidating methods |
US6044362A (en) * | 1997-09-08 | 2000-03-28 | Neely; R. Alan | Electronic invoicing and payment system |
US6047268A (en) * | 1997-11-04 | 2000-04-04 | A.T.&T. Corporation | Method and apparatus for billing for transactions conducted over the internet |
US6049687A (en) * | 1997-10-31 | 2000-04-11 | Canon Kabushiki Kaisha | Developing apparatus |
US6055567A (en) * | 1998-02-02 | 2000-04-25 | Checkfree Corporation | Distributed data accessing technique |
US6058381A (en) * | 1996-10-30 | 2000-05-02 | Nelson; Theodor Holm | Many-to-many payments system for network content materials |
US6070150A (en) * | 1996-10-18 | 2000-05-30 | Microsoft Corporation | Electronic bill presentment and payment system |
US6076075A (en) * | 1995-09-25 | 2000-06-13 | Cardis Enterprise International N.V. | Retail unit and a payment unit for serving a customer on a purchase and method for executing the same |
US6078907A (en) * | 1998-02-18 | 2000-06-20 | Lamm; David | Method and system for electronically presenting and paying bills |
US6098053A (en) * | 1998-01-28 | 2000-08-01 | Citibank, N.A. | System and method for performing an electronic financial transaction |
US6128603A (en) * | 1997-09-09 | 2000-10-03 | Dent; Warren T. | Consumer-based system and method for managing and paying electronic billing statements |
US6134326A (en) * | 1996-11-18 | 2000-10-17 | Bankers Trust Corporation | Simultaneous electronic transactions |
US6137884A (en) * | 1995-03-21 | 2000-10-24 | Bankers Trust Corporation | Simultaneous electronic transactions with visible trusted parties |
US6289322B1 (en) * | 1998-03-03 | 2001-09-11 | Checkfree Corporation | Electronic bill processing |
US6292789B1 (en) * | 1997-08-26 | 2001-09-18 | Citibank, N.A. | Method and system for bill presentment and payment |
US6304857B1 (en) * | 1998-06-08 | 2001-10-16 | Microsoft Corporation | Distributed electronic billing system with gateway interfacing biller and service center |
US20020016765A1 (en) * | 2000-07-11 | 2002-02-07 | David Sacks | System and method for third-party payment processing |
US6378075B1 (en) * | 1997-04-11 | 2002-04-23 | The Brodia Group | Trusted agent for electronic commerce |
US20020059139A1 (en) * | 1999-03-12 | 2002-05-16 | Scott Evans | System and method for debt presentment and resolution |
US20030023552A1 (en) * | 1991-07-25 | 2003-01-30 | Checkfree Services Corporation | Payment processing utilizing alternate account identifiers |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2102606B (en) | 1981-06-19 | 1985-01-30 | Nat Res Dev | Apparatus and methods for making payments electronically |
US4713837A (en) * | 1985-12-24 | 1987-12-15 | Alastair Gordon | Communication network |
US4977595A (en) | 1989-04-03 | 1990-12-11 | Nippon Telegraph And Telephone Corporation | Method and apparatus for implementing electronic cash |
US5283829A (en) | 1992-10-01 | 1994-02-01 | Bell Communications Research, Inc. | System and method for paying bills electronically |
US6460021B1 (en) | 1993-09-28 | 2002-10-01 | William E. Kirksey | Collaterally secured debt obligation and method of creating same |
US5477038A (en) | 1993-10-25 | 1995-12-19 | Visa International | Method and apparatus for distributing currency |
US5590197A (en) | 1995-04-04 | 1996-12-31 | V-One Corporation | Electronic payment system and method |
US5699528A (en) | 1995-10-31 | 1997-12-16 | Mastercard International, Inc. | System and method for bill delivery and payment over a communications network |
US5682678A (en) | 1995-11-13 | 1997-11-04 | The Nordam Group, Inc. | Mechanical repair for a honeycomb panel |
US5794210A (en) | 1995-12-11 | 1998-08-11 | Cybergold, Inc. | Attention brokerage |
JP3133243B2 (en) | 1995-12-15 | 2001-02-05 | 株式会社エヌケーインベストメント | Online shopping system |
US5812668A (en) | 1996-06-17 | 1998-09-22 | Verifone, Inc. | System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture |
AU729075B2 (en) | 1996-10-22 | 2001-01-25 | Coloplast A/S | A mouldable mass for use in connection with an ostomy appliance |
IT241407Y1 (en) | 1996-11-05 | 2001-05-09 | Giuseppe Conti | SOCK OR TIGHTS, WHICH SUPPORTS WITH A SUPPORT SYSTEM ON THE SIDES |
US5970480A (en) | 1997-04-14 | 1999-10-19 | Kalina; Dyan T. | Centralized credit interchange system of converting purchase credit awards through credit exchange system for purchase of investment vehicle |
US6049786A (en) * | 1997-07-22 | 2000-04-11 | Unisys Corporation | Electronic bill presentment and payment system which deters cheating by employing hashes and digital signatures |
US6026364A (en) | 1997-07-28 | 2000-02-15 | Whitworth; Brian L. | System and method for replacing a liability with insurance and for analyzing data and generating documents pertaining to a premium financing mechanism paying for such insurance |
US6009402A (en) | 1997-07-28 | 1999-12-28 | Whitworth; Brian L. | System and method for predicting, comparing and presenting the cost of self insurance versus insurance and for creating bond financing when advantageous |
US6052674A (en) | 1997-12-23 | 2000-04-18 | Information Retrieval Consultants (Europe, Middle East, Africa ) Limited | Electronic invoicing and collection system and method with charity donations |
US6249770B1 (en) | 1998-01-30 | 2001-06-19 | Citibank, N.A. | Method and system of financial spreading and forecasting |
US6856974B1 (en) | 1998-02-02 | 2005-02-15 | Checkfree Corporation | Electronic bill presentment technique with enhanced biller control |
US6334116B1 (en) | 1998-02-02 | 2001-12-25 | Checkfree Corporation | Technique for centrally tracking transactions in an electronic billing system |
US6006200A (en) | 1998-05-22 | 1999-12-21 | International Business Machines Corporation | Method of providing an identifier for transactions |
US7295987B2 (en) | 2003-11-21 | 2007-11-13 | Graff/Ross Holdings Llp | Non-debt funding system for home finance |
US6167384A (en) | 1998-09-01 | 2000-12-26 | Graff/Ross Holdings | Augmented system and methods for computing to support fractional contingent interests in property |
US6360210B1 (en) | 1999-02-12 | 2002-03-19 | Folio Trade Llc | Method and system for enabling smaller investors to manage risk in a self-managed portfolio of assets/liabilities |
US20010037295A1 (en) * | 2000-01-31 | 2001-11-01 | Olsen Karl R. | Push model internet bill presentment and payment system and method |
WO2001080102A1 (en) * | 2000-04-17 | 2001-10-25 | Billwhiz Inc. | Electronic bill presentment and payment system and method providing biller directories |
US20010056508A1 (en) * | 2000-05-12 | 2001-12-27 | Kenneth Arneson | Event notification system and method |
US7206768B1 (en) | 2000-08-14 | 2007-04-17 | Jpmorgan Chase Bank, N.A. | Electronic multiparty accounts receivable and accounts payable system |
US7177834B1 (en) | 2000-09-29 | 2007-02-13 | Maestle Wilfried A | Machine-implementable project finance analysis and negotiating tool software, method and system |
US7219079B2 (en) | 2001-08-10 | 2007-05-15 | Birle Jr James R | Convertible financial instruments with contingent payments |
US7289322B2 (en) | 2005-10-24 | 2007-10-30 | Fu Zhun Precision Industry (Shen Zhen) Co., Ltd. | Heat sink |
-
1999
- 1999-04-28 US US09/301,068 patent/US6856974B1/en not_active Expired - Fee Related
-
2003
- 2003-08-22 US US10/645,521 patent/US7657484B2/en not_active Expired - Fee Related
-
2005
- 2005-02-15 US US11/057,233 patent/US20050137978A1/en not_active Abandoned
- 2005-02-17 US US11/059,370 patent/US7778901B2/en not_active Expired - Fee Related
-
2006
- 2006-09-21 US US11/534,159 patent/US20070121840A1/en not_active Abandoned
Patent Citations (102)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US528829A (en) * | 1894-11-06 | Plane | ||
US3852571A (en) * | 1970-05-18 | 1974-12-03 | Hempstead Bank | System of transferral of funds |
US4277837A (en) * | 1977-12-30 | 1981-07-07 | International Business Machines Corporation | Personal portable terminal for financial transactions |
US4319336A (en) * | 1979-02-02 | 1982-03-09 | International Business Machines Corporation | Transaction execution system with improved key function versatility |
US4460960A (en) * | 1979-02-02 | 1984-07-17 | International Business Machines Corporation | Transaction execution system having keyboard and message customization, improved key function versatility and message segmentation |
US4747050A (en) * | 1983-09-17 | 1988-05-24 | International Business Machines Corporation | Transaction security system using time variant parameter |
US4734858A (en) * | 1983-12-05 | 1988-03-29 | Portel Services Network, Inc. | Data terminal and system for placing orders |
US4734858B1 (en) * | 1983-12-05 | 1997-02-11 | Portel Services Network Inc | Data terminal and system for placing orders |
US4701601A (en) * | 1985-04-26 | 1987-10-20 | Visa International Service Association | Transaction card with magnetic stripe emulator |
US4734564A (en) * | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
US4812628A (en) * | 1985-05-02 | 1989-03-14 | Visa International Service Association | Transaction system with off-line risk assessment |
US4775935A (en) * | 1986-09-22 | 1988-10-04 | Westinghouse Electric Corp. | Video merchandising system with variable and adoptive product sequence presentation order |
US4799156A (en) * | 1986-10-01 | 1989-01-17 | Strategic Processing Corporation | Interactive market management system |
US4822985A (en) * | 1987-01-06 | 1989-04-18 | Visa International Service Association | Transaction approval system |
US4961142A (en) * | 1988-06-29 | 1990-10-02 | Mastercard International, Inc. | Multi-issuer transaction device with individual identification verification plug-in application modules for each issuer |
US5025373A (en) * | 1988-06-30 | 1991-06-18 | Jml Communications, Inc. | Portable personal-banking system |
US5347632A (en) * | 1988-07-15 | 1994-09-13 | Prodigy Services Company | Reception system for an interactive computer network and method of operation |
US5594910A (en) * | 1988-07-15 | 1997-01-14 | Ibm Corp. | Interactive computer network and method of operation |
US4947028A (en) * | 1988-07-19 | 1990-08-07 | Arbor International, Inc. | Automated order and payment system |
US4947028B1 (en) * | 1988-07-19 | 1993-06-08 | U S Order Inc | |
US5206488A (en) * | 1989-06-07 | 1993-04-27 | Mordechai Teicher | Credit card system including a central unit and a plurality of local units for conducting low-cost transactions |
US4922940A (en) * | 1989-07-31 | 1990-05-08 | Lewy Michael M | Invalid walker |
US5287270A (en) * | 1989-08-14 | 1994-02-15 | Compucom Communications Corp. | Billing system |
US5325290A (en) * | 1989-08-14 | 1994-06-28 | Compucom Communications Corp. | Billing system with data indexing |
US5220501A (en) * | 1989-12-08 | 1993-06-15 | Online Resources, Ltd. | Method and system for remote delivery of retail banking services |
US5231571A (en) * | 1990-08-14 | 1993-07-27 | Personal Financial Assistant, Inc. | Personal financial assistant computer method |
US5319542A (en) * | 1990-09-27 | 1994-06-07 | International Business Machines Corporation | System for ordering items using an electronic catalogue |
US5329589A (en) * | 1991-02-27 | 1994-07-12 | At&T Bell Laboratories | Mediation of transactions by a communications system |
US5873072A (en) * | 1991-07-25 | 1999-02-16 | Checkfree Corporation | System and method for electronically providing customer services including payment of bills, financial analysis and loans |
US5383113A (en) * | 1991-07-25 | 1995-01-17 | Checkfree Corporation | System and method for electronically providing customer services including payment of bills, financial analysis and loans |
US20030023552A1 (en) * | 1991-07-25 | 2003-01-30 | Checkfree Services Corporation | Payment processing utilizing alternate account identifiers |
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5455407A (en) * | 1991-11-15 | 1995-10-03 | Citibank, N.A. | Electronic-monetary system |
US5255182A (en) * | 1992-01-31 | 1993-10-19 | Visa International Service Association | Payment card point-of-sale service quality monitoring system, apparatus, and method |
US5655089A (en) * | 1992-04-10 | 1997-08-05 | Bucci; Joseph J. | Method for the consolidation summarization and transmission of a plurality of mailable materials |
US5336870A (en) * | 1992-05-26 | 1994-08-09 | Hughes Thomas S | System for remote purchase payment transactions and remote bill payments |
US5326959A (en) * | 1992-08-04 | 1994-07-05 | Perazza Justin J | Automated customer initiated entry remittance processing system |
US5727249A (en) * | 1992-10-15 | 1998-03-10 | Pollin; Robert E. | Automated payment system and method |
US5483445A (en) * | 1992-10-22 | 1996-01-09 | American Express Trs | Automated billing consolidation system and method |
US5341429A (en) * | 1992-12-04 | 1994-08-23 | Testdrive Corporation | Transformation of ephemeral material |
US5842185A (en) * | 1993-02-18 | 1998-11-24 | Intuit Inc. | Method and system for electronically tracking financial transactions |
US5420405A (en) * | 1993-02-26 | 1995-05-30 | Chasek; Norman E. | Secure, automated transaction system that supports an electronic currency operating in mixed debit & credit modes |
US5465206B1 (en) * | 1993-11-01 | 1998-04-21 | Visa Int Service Ass | Electronic bill pay system |
US6032133A (en) * | 1993-11-01 | 2000-02-29 | Visainternational Service Association | Electronic bill pay system |
US5920847A (en) * | 1993-11-01 | 1999-07-06 | Visa International Service Association | Electronic bill pay system |
US5465206A (en) * | 1993-11-01 | 1995-11-07 | Visa International | Electronic bill pay system |
US5724424A (en) * | 1993-12-16 | 1998-03-03 | Open Market, Inc. | Digital active advertising |
US5420926A (en) * | 1994-01-05 | 1995-05-30 | At&T Corp. | Anonymous credit card transactions |
US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5500513A (en) * | 1994-05-11 | 1996-03-19 | Visa International | Automated purchasing control system |
US6016509A (en) * | 1994-05-16 | 2000-01-18 | Intel Corporation | General purpose metering mechanism for distribution of electronic information |
US5768521A (en) * | 1994-05-16 | 1998-06-16 | Intel Corporation | General purpose metering mechanism for distribution of electronic information |
US5649117A (en) * | 1994-06-03 | 1997-07-15 | Midwest Payment Systems | System and method for paying bills and other obligations including selective payor and payee controls |
US5956700A (en) * | 1994-06-03 | 1999-09-21 | Midwest Payment Systems | System and method for paying bills and other obligations including selective payor and payee controls |
US5717989A (en) * | 1994-10-13 | 1998-02-10 | Full Service Trade System Ltd. | Full service trade system |
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US5613012A (en) * | 1994-11-28 | 1997-03-18 | Smarttouch, Llc. | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
US5723400A (en) * | 1995-02-21 | 1998-03-03 | Montell North America Inc. | Process for the preparation of a solid catalyst component suitable for the polymerization of olefins which includes at least two additions of an electron donor |
US5710889A (en) * | 1995-02-22 | 1998-01-20 | Citibank, N.A. | Interface device for electronically integrating global financial services |
US5826245A (en) * | 1995-03-20 | 1998-10-20 | Sandberg-Diment; Erik | Providing verification information for a transaction |
US6137884A (en) * | 1995-03-21 | 2000-10-24 | Bankers Trust Corporation | Simultaneous electronic transactions with visible trusted parties |
US5727163A (en) * | 1995-03-30 | 1998-03-10 | Amazon.Com, Inc. | Secure method for communicating credit card data when placing an order on a non-secure network |
US5832460A (en) * | 1995-06-02 | 1998-11-03 | International Business Machines Corporation | Method and system for bill presentation and payment reconciliation |
US5832089A (en) * | 1995-06-07 | 1998-11-03 | Sandia Corporation | Off-line compatible electronic cash method and system |
US5692132A (en) * | 1995-06-07 | 1997-11-25 | Mastercard International, Inc. | System and method for conducting cashless transactions on a computer network |
US5794221A (en) * | 1995-07-07 | 1998-08-11 | Egendorf; Andrew | Internet billing method |
US5893080A (en) * | 1995-07-25 | 1999-04-06 | Bottomline Technologies, Inc. | Disbursement system and method |
US5768385A (en) * | 1995-08-29 | 1998-06-16 | Microsoft Corporation | Untraceable electronic cash |
US5710887A (en) * | 1995-08-29 | 1998-01-20 | Broadvision | Computer system and method for electronic commerce |
US6076075A (en) * | 1995-09-25 | 2000-06-13 | Cardis Enterprise International N.V. | Retail unit and a payment unit for serving a customer on a purchase and method for executing the same |
US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
US5815665A (en) * | 1996-04-03 | 1998-09-29 | Microsoft Corporation | System and method for providing trusted brokering services over a distributed network |
US5729594A (en) * | 1996-06-07 | 1998-03-17 | Klingman; Edwin E. | On-line secured financial transaction system through electronic media |
US5884288A (en) * | 1996-07-01 | 1999-03-16 | Sun Microsystems, Inc. | Method and system for electronic bill payment |
US5903732A (en) * | 1996-07-03 | 1999-05-11 | Hewlett-Packard Company | Trusted gateway agent for web server programs |
US5931917A (en) * | 1996-09-26 | 1999-08-03 | Verifone, Inc. | System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US5963925A (en) * | 1996-10-09 | 1999-10-05 | Visa International Service Association | Electronic statement presentment system |
US6070150A (en) * | 1996-10-18 | 2000-05-30 | Microsoft Corporation | Electronic bill presentment and payment system |
US6058381A (en) * | 1996-10-30 | 2000-05-02 | Nelson; Theodor Holm | Many-to-many payments system for network content materials |
US6134326A (en) * | 1996-11-18 | 2000-10-17 | Bankers Trust Corporation | Simultaneous electronic transactions |
US6029151A (en) * | 1996-12-13 | 2000-02-22 | Telefonaktiebolaget L M Ericsson | Method and system for performing electronic money transactions |
US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
US6378075B1 (en) * | 1997-04-11 | 2002-04-23 | The Brodia Group | Trusted agent for electronic commerce |
US5974146A (en) * | 1997-07-30 | 1999-10-26 | Huntington Bancshares Incorporated | Real time bank-centric universal payment system |
US6292789B1 (en) * | 1997-08-26 | 2001-09-18 | Citibank, N.A. | Method and system for bill presentment and payment |
US5987430A (en) * | 1997-08-28 | 1999-11-16 | Atcom, Inc. | Communications network connection system and method |
US6044362A (en) * | 1997-09-08 | 2000-03-28 | Neely; R. Alan | Electronic invoicing and payment system |
US6128603A (en) * | 1997-09-09 | 2000-10-03 | Dent; Warren T. | Consumer-based system and method for managing and paying electronic billing statements |
US6049687A (en) * | 1997-10-31 | 2000-04-11 | Canon Kabushiki Kaisha | Developing apparatus |
US6047268A (en) * | 1997-11-04 | 2000-04-04 | A.T.&T. Corporation | Method and apparatus for billing for transactions conducted over the internet |
US5978780A (en) * | 1997-11-21 | 1999-11-02 | Craig Michael Watson | Integrated bill consolidation, payment aggregation, and settlement system |
US6035285A (en) * | 1997-12-03 | 2000-03-07 | Avista Advantage, Inc. | Electronic bill presenting methods and bill consolidating methods |
US5943656A (en) * | 1997-12-03 | 1999-08-24 | Avista Advantage, Inc. | Methods and systems for computerized bill consolidating, billing and payment authorization, computerized utility bill consolidating, utility billing access and payment and utility provider consolidated billing systems |
US6088688A (en) * | 1997-12-17 | 2000-07-11 | Avista Advantage, Inc. | Computerized resource accounting methods and systems, computerized utility management methods and systems, multi-user utility management methods and systems, and energy-consumption-based tracking methods and systems |
US6098053A (en) * | 1998-01-28 | 2000-08-01 | Citibank, N.A. | System and method for performing an electronic financial transaction |
US6055567A (en) * | 1998-02-02 | 2000-04-25 | Checkfree Corporation | Distributed data accessing technique |
US6078907A (en) * | 1998-02-18 | 2000-06-20 | Lamm; David | Method and system for electronically presenting and paying bills |
US6289322B1 (en) * | 1998-03-03 | 2001-09-11 | Checkfree Corporation | Electronic bill processing |
US6304857B1 (en) * | 1998-06-08 | 2001-10-16 | Microsoft Corporation | Distributed electronic billing system with gateway interfacing biller and service center |
US20020059139A1 (en) * | 1999-03-12 | 2002-05-16 | Scott Evans | System and method for debt presentment and resolution |
US20020016765A1 (en) * | 2000-07-11 | 2002-02-07 | David Sacks | System and method for third-party payment processing |
Cited By (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9749391B2 (en) | 2000-03-29 | 2017-08-29 | Mastercard International Incorporated | Method and system for processing messages in a bill payment and presentment system over a communications network |
US10387879B2 (en) | 2002-04-23 | 2019-08-20 | The Clearing Housse Payments Company L.L.C. | Payment identification code and payment system using the same |
US7979348B2 (en) | 2002-04-23 | 2011-07-12 | Clearing House Payments Co Llc | Payment identification code and payment system using the same |
US20120310833A1 (en) * | 2004-01-07 | 2012-12-06 | Precash, Inc. | System and method for facilitating large scale payment transactions |
US8595135B2 (en) * | 2004-01-07 | 2013-11-26 | Randy J. Templeton | System and method for facilitating large scale payment transactions |
US8725607B2 (en) | 2004-01-30 | 2014-05-13 | The Clearing House Payments Company LLC | Electronic payment clearing and check image exchange systems and methods |
US10643190B2 (en) | 2004-01-30 | 2020-05-05 | The Clearing House Payments Company L.L.C. | Electronic payment clearing and check image exchange systems and methods |
US11301824B2 (en) | 2004-01-30 | 2022-04-12 | The Clearing House Payments Company LLC | Electronic payment clearing and check image exchange systems and methods |
US9799011B2 (en) | 2004-01-30 | 2017-10-24 | The Clearing House Payments Company L.L.C. | Electronic payment clearing and check image exchange systems and methods |
US10685337B2 (en) | 2004-01-30 | 2020-06-16 | The Clearing House Payments Company L.L.C. | Electronic payment clearing and check image exchange systems and methods |
US10636018B2 (en) | 2004-01-30 | 2020-04-28 | The Clearing House Payments Company L.L.C. | Electronic payment clearing and check image exchange systems and methods |
US8467766B2 (en) | 2006-07-06 | 2013-06-18 | Qualcomm Incorporated | Methods and systems for managing payment sources in a mobile environment |
US8145568B2 (en) | 2006-07-06 | 2012-03-27 | Firethorn Mobile, Inc. | Methods and systems for indicating a payment in a mobile environment |
US8160959B2 (en) | 2006-07-06 | 2012-04-17 | Firethorn Mobile, Inc. | Methods and systems for payment transactions in a mobile environment |
US9911114B2 (en) | 2006-07-06 | 2018-03-06 | Qualcomm Incorporated | Methods and systems for making a payment via a stored value card in a mobile environment |
US20080010204A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Making a Payment Via a Paper Check in a Mobile Environment |
US8121945B2 (en) | 2006-07-06 | 2012-02-21 | Firethorn Mobile, Inc. | Methods and systems for payment method selection by a payee in a mobile environment |
US8489067B2 (en) | 2006-07-06 | 2013-07-16 | Qualcomm Incorporated | Methods and systems for distribution of a mobile wallet for a mobile device |
US8510220B2 (en) | 2006-07-06 | 2013-08-13 | Qualcomm Incorporated | Methods and systems for viewing aggregated payment obligations in a mobile environment |
US20080040265A1 (en) * | 2006-07-06 | 2008-02-14 | Firethorn Holdings, Llc | Methods and Systems For Making a Payment Via A Stored Value Card in a Mobile Environment |
US20080183621A1 (en) * | 2007-01-28 | 2008-07-31 | Evans Steven D | Payer direct hub |
US7676434B2 (en) | 2007-01-28 | 2010-03-09 | Bora Payment Systems, Llc | Payer direct hub |
US20110196768A1 (en) * | 2007-04-10 | 2011-08-11 | Invoice Compliance Experts | Legal billing enhancement method and apparatus |
US8244610B2 (en) * | 2007-04-10 | 2012-08-14 | Invoice Compliance Experts | Legal billing enhancement method and apparatus |
US8676672B2 (en) | 2007-08-23 | 2014-03-18 | E2Interactive, Inc. | Systems and methods for electronic delivery of stored value |
US20090089193A1 (en) * | 2007-09-28 | 2009-04-02 | The Western Union Company | Bill payment aggregation service |
US10679196B2 (en) * | 2007-09-28 | 2020-06-09 | The Western Union Company | Bill payment aggregation service |
WO2009042434A1 (en) * | 2007-09-28 | 2009-04-02 | The Western Union Company | Bill payment aggregation service |
US20090327111A1 (en) * | 2007-09-28 | 2009-12-31 | The Western Union Company | Bill payment in association with television service providers systems and methods |
US20100042547A1 (en) * | 2008-08-12 | 2010-02-18 | The Western Union Company | Methods and systems for money transfer with cable and/or satellite providers |
US11928696B2 (en) | 2009-12-16 | 2024-03-12 | E2Interactive, Inc. | Systems and methods for generating a virtual value item for a promotional campaign |
US8595134B2 (en) | 2010-02-12 | 2013-11-26 | Mastercard International Incorporated | Apparatus and method for bill presentment and payment |
US9824342B2 (en) | 2010-02-12 | 2017-11-21 | Mastercard International Incorporated | Apparatus and method for bill presentment and payment |
US10068287B2 (en) | 2010-06-11 | 2018-09-04 | David A. Nelsen | Systems and methods to manage and control use of a virtual card |
US20120066120A1 (en) * | 2010-09-09 | 2012-03-15 | Boku, Inc. | Systems and methods to process payments via a communication system |
US11182836B2 (en) | 2010-10-13 | 2021-11-23 | E2Interactive, Inc. | Gift card ordering system and method |
US10937076B2 (en) | 2010-10-13 | 2021-03-02 | E2Interactive, Inc. | Online personalized gifting system |
US11436651B2 (en) | 2012-01-30 | 2022-09-06 | E2Interactive, Inc. | Group video generating system |
US10025920B2 (en) * | 2012-06-07 | 2018-07-17 | Early Warning Services, Llc | Enterprise triggered 2CHK association |
US20130333006A1 (en) * | 2012-06-07 | 2013-12-12 | Authentify, Inc. | Enterprise triggered 2chk association |
US10943438B2 (en) | 2012-09-04 | 2021-03-09 | E2Interactive, Inc. | Processing of a game-playing transaction based on location |
US10943432B2 (en) | 2012-09-04 | 2021-03-09 | E2Interactive, Inc. | Processing of a game-playing transaction based on location |
US11037397B2 (en) | 2012-09-04 | 2021-06-15 | E2Interactive, Inc. | Processing of a user device game-playing transaction based on location |
US11219288B2 (en) | 2013-02-15 | 2022-01-11 | E2Interactive, Inc. | Gift card box with slanted tray and slit |
US11111065B2 (en) | 2013-02-15 | 2021-09-07 | E2Interactive, Inc. | Gift card presentation devices |
US11250666B2 (en) | 2013-03-15 | 2022-02-15 | E2Interactive, Inc. | Systems and methods for location-based game play on computing devices |
US11120428B2 (en) | 2013-05-02 | 2021-09-14 | E2Interactive, Inc. | Stored value card kiosk system and method |
US9443268B1 (en) | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US10269065B1 (en) | 2013-11-15 | 2019-04-23 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US11017443B2 (en) | 2014-04-30 | 2021-05-25 | E2Interactive, Inc. | System and method for a merchant onsite personalization gifting platform |
US11295308B1 (en) | 2014-10-29 | 2022-04-05 | The Clearing House Payments Company, L.L.C. | Secure payment processing |
US11816666B2 (en) | 2014-10-29 | 2023-11-14 | The Clearing House Payments Company L.L.C. | Secure payment processing |
US11694168B2 (en) | 2015-07-01 | 2023-07-04 | The Clearing House Payments Company L.L.C. | Real-time payment system, method, apparatus, and computer program |
US11042882B2 (en) | 2015-07-01 | 2021-06-22 | The Clearing House Payments Company, L.L.C. | Real-time payment system, method, apparatus, and computer program |
US10954049B2 (en) | 2017-12-12 | 2021-03-23 | E2Interactive, Inc. | Viscous liquid vessel for gifting |
US11829967B2 (en) | 2018-05-03 | 2023-11-28 | The Clearing House Payments Company L.L.C. | Bill pay service with federated directory model support |
US11436577B2 (en) | 2018-05-03 | 2022-09-06 | The Clearing House Payments Company L.L.C. | Bill pay service with federated directory model support |
US11265324B2 (en) | 2018-09-05 | 2022-03-01 | Consumerinfo.Com, Inc. | User permissions for access to secure data at third-party |
US11399029B2 (en) | 2018-09-05 | 2022-07-26 | Consumerinfo.Com, Inc. | Database platform for realtime updating of user data from third party sources |
US10880313B2 (en) | 2018-09-05 | 2020-12-29 | Consumerinfo.Com, Inc. | Database platform for realtime updating of user data from third party sources |
US10671749B2 (en) | 2018-09-05 | 2020-06-02 | Consumerinfo.Com, Inc. | Authenticated access and aggregation database platform |
Also Published As
Publication number | Publication date |
---|---|
US7657484B2 (en) | 2010-02-02 |
US7778901B2 (en) | 2010-08-17 |
US20070121840A1 (en) | 2007-05-31 |
US20060184451A1 (en) | 2006-08-17 |
US20060064377A1 (en) | 2006-03-23 |
US6856974B1 (en) | 2005-02-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7778901B2 (en) | Integrated electronic presentment and payment of bills by different entities | |
US6334116B1 (en) | Technique for centrally tracking transactions in an electronic billing system | |
US6055567A (en) | Distributed data accessing technique | |
US7366696B1 (en) | Electronic billing with flexible biller controlled electronic bill presentment | |
US7392223B1 (en) | Electronic billing with updateable electronic bill summary | |
US20060195397A1 (en) | Centralized electronic bill presentment | |
US7324972B1 (en) | Managing transactions on a network: four or more parties | |
US9418381B2 (en) | Method and system for notifying customers of transaction opportunities | |
US20020133412A1 (en) | System for management of transactions on networks | |
US20070287413A1 (en) | Method and system for mobile billing and content delivery | |
US7308434B2 (en) | Account management tool for e-billing system | |
US20060195396A1 (en) | Centralized customer care for electronic payments and other transactions via a wide area communications network | |
US20010056401A1 (en) | Integrated system for providing financial services including internet TV capabilities | |
US20020069168A1 (en) | System and method for performing personal finance management using the internet | |
US20060195395A1 (en) | Facilitating electronic payment on behalf of a customer of electronic presented bills | |
EP1136922A1 (en) | An elctronic bill presentment technique with enhanced biller control | |
EP1136924A1 (en) | Distributed data accessing technique | |
EP1083532A2 (en) | Electronic billing with updateable electronic bill summary | |
CA2301386A1 (en) | Distributed data accessing technique | |
CA2301346A1 (en) | An electronic bill presentment technique with enhanced biller control | |
NZ503497A (en) | Accessing billing data via different stations in a network | |
AU2245300A (en) | Distribution data accessing technique | |
AU2245500A (en) | An electronic bill presentment technique with enhanced biller control | |
NZ503499A (en) | Electronic bill presentation and payment via network | |
WO2001059648A1 (en) | System for management of transactions on networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |