WO2001091020A1

WO2001091020A1 - Apparatus and method of optimizing the total monthly amount due on bills and satisfying customer's preferences

Info

Publication number: WO2001091020A1
Application number: PCT/US2001/017157
Authority: WO
Inventors: Scott Currie; Laks Srinivasan; Rudrapatnam Balasubramanyam; Srinivasan Renganathan; Philip Hatfield; Robert A. Riddle
Original assignee: Expenseadvisor, Inc.
Priority date: 2000-05-25
Filing date: 2001-05-25
Publication date: 2001-11-29
Also published as: AU2001274986A1

Abstract

An apparatus and method (see Fig.1) for minimizing the total customer cost for bills by gathering usage information derived from customer's bills, and receiving one or more customer preferences (9), wherein said preferences comprise one or more geographical limitations, service provider limitations, anticipated usage patters, compiling a database of one or more service plans offered by one or more providers, generating in response to said customer preferences, a list of one or more service bundles for said customer, wherein said bundle optimizes a total amount due for all bills, and communicating said list to the customer for evaluation. The invention also teaches the ability of the service providers matching or bettering the competition's plans in order to keep the customer's business.

Description

APPARATUS AND METHOD OF OPTIMIZING THE TOTAL MONTHLY AMOUNT DUE ON BILLS AND SATISFYING CUSTOMER'S

PREFERENCES

FIELD OF THE INVENTION The present invention relates to systems and methods for bill payment.

More particularly, the present invention related to automated methods and systems for evaluating service plans such as utility service plans and bundling service plans together in order to optimize payment terms.

BACKGROUND OF THE INVENTION Service providers of all types of services, including but not limited to heating, water, electricity, telephone, mobile phone, pagers, beepers, mortgages, loans, on-line trading, groceries, and credit cards offer one or more service plans to customers. Customers need to evaluate the plans and often do so by guessing what their usage of the service is. For instance, the average customer merely guesses how much peak and off-peak airtime, and local versus long distance minutes he actually uses on his mobile phone, before he chooses a service plan. The present invention eliminates the guess work, and analyzes the customer's usage of these services and generates a list of the lowest cost plans and the bundles of plans with the lowest overall total cost that satisfy the customer's preferences. Further, the present invention allows for recurring analysis to occur based upon changes in the plans offered, the customer's actual service usage, and/or the customer's preferences.

Customers in today's market are subjected to numerous monthly bills for everything from utilities to mortgages to car payments, and for every bill, the customer must decide what service plan best fits his needs. The invention described herein allows a customer to evaluate the cost for each service plan which would fit his needs, bundle service plans together in order to optimize payments which occur at regular time intervals, preferably monthly, and best match the customer's individual needs based upon the Customer's actual usage of the services. Further, it allows bundling of numerous customers' plans together in order to obtain discounts from the service provider. Additionally, the invention can analyze the Customer's usage and generate optimal plans on a recurring basis.

Currently in the industry there are service providers who gather information on their individual customer's usage from that specific service provider's bills. Some of these service providers gather this information on a recurring basis. Unlike these service providers' methods, the present invention is directed to optimization of plans for more than one service for each customer. The invention gathers information from bills from one or more providers other than the coordinator's bills; or from bills from the coordinator and one or more other providers. The coordinator may or may not be a service provider. Thus, this invention allows all of the bills from one or more service providers for a customer to be analyzed and optimized.

Other companies have tried to minimize a customer's utility costs but require the customer to answer lengthy questions about their usage of any service (which requires either time consuming, tedious work by the customer, or more likely, guesses by the customer). The present invention does not require the customer to guess or have any information other than copies of bills, and gathers the information required from these bills, rather than by questioning the customer.

SUMMARY OF THE INVENTION In today's market, customers, both individual and commercial, ("Customers") enter into service plans ("Plans") with service providers ("Providers") for all types of services, including but not limited to heating, water, electricity, telephone, mobile phone, pagers, beepers, mortgages, loans, on-line trading, groceries and credit cards (collectively "Services"). Each Provider offers one or more Plans from which the Customer must choose. The invention provides for the compilation of information based upon the Customer's actual usage of the Service, and an analysis of which Plans are best for the Customer. The Plans may be ranked according to total lowest cost or in any manner desired by the Customer. The Plans and Customers can then be automatically registered for Plans with the Providers. In addition, the invention allows for a reevaluation of the Plans at Customer's request or automatically in regular intervals to find the optimal Plans for the Customer for the most current usage information. Groups of more than one Customers' Plans may be bundled together under the invention to achieve group discounts from one or more Providers.

In the first embodiment ("First Embodiment"), the Customer desires to know his costs for any Plan that fits his needs, including usage patterns and Preferences, and/or desires that the overall total cost that he pays be optimized for all of the Services he uses each month or one or more particular bills each month. The Customer's services and costs are optimized by finding the lowest prices for the services that the Customer desires while accounting for the Customer's Preferences, if any. A coordinator ("Coordinator") gathers information from the Customer's bills, including but not limited to name, address, total costs, flat fees, usage-based fees (which are fees calculated from actual use of the Service), amount of usage for each Service, times of peak usage for each Service, and times of any usage of each Service (collectively "Information"). The Coordinator may or may not be a Provider. These bills provided by the Customer, Coordinator or Provider are bills from one or more of the following: the Coordinator and/or one or more Provider who is not the Coordinator (collectively "Bills"). The Customer supplies one or more customer's preferences, including but not limited to geographical limitations, acceptable

Providers, unacceptable Providers, a desire to earn airline mileage rewards, a desire to give to particular charitable causes, and anticipated usage patterns (collectively "Preferences"). The Data of one or more Plans from one or more Providers, including but not limited to flat fees, use-based fees, free Services, time limitations and rewards, are compiled into a database, which may be a real-time or stored database ("Database"). A database may be a commercial off-the-shelf or custom database and may be a relational, object-oriented or other database. The Customer Preferences and the information from the bills are analyzed, compared with the Database and a list of one or more service bundles ("Bundles") is generated ("List"). Each Bundle consists of one or more suggested Plans for different Services, which would optimize the total cost of all the Bills, or the specific bills that Customer wanted to minimize and satisfy the Customer Preferences. The List is communicated to the Customer via internet, intranet, electronic mail, regular mail, telephone, wireless devices, cellular technology and/or personal communication.

A separate preferred embodiment ("Second Embodiment") comprises the situation in which the Customer desires to optimize the overall total cost that he pays, including flat fees and use-based fees, for Services each month. A Coordinator automatically gathers Information from the Customer's Bills, including but not limited to total costs, flat fees, usage-based fees (which are fees calculated from actual use of the Service), amount of usage for each Service, times of peak usage for each Service, and times of any usage of each Service. The automatic gathering of Information may be accomplished by scanning Bills into a computer, converting the Bills into text format, preferably ASCII files, reading the text files of all the Bills, and having a computer automatically analyze the Bills for the information, or by electronically transmitting the Bills to a computer and have a computer automatically analyze the Bills for Information. The Customer supplies one or more customer's Preferences, preferably by internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. The Customer Preferences and the Information from the Bills are automatically analyzed and compared with the Database and a List of one or more Plan or Bundle is automatically generated. The List is automatically communicated to the Customer via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication.

Continuing in the same embodiment, the Customer may be dissatisfied with the List or desire to be informed of more or different Bundles. The Customer may optionally enter new Preferences ("New Preferences"), and have the Information and New Preferences analyzed and a different List generated. The steps in this paragraph may occur repeatedly.

A further embodiment ("Third Embodiment") encompasses the First or Second Embodiment with the following additions. After the completion of the First or Second Embodiment of the invention, the Coordinator automatically gathers Information from the Bills upon receipt of each Bill, at set time intervals or at the request of the Customer. The Bills are automatically evaluated to reveal any, if any, permanent changes in the Customer's usage patterns. If there are any permanent changes (that is, changes that are not just one month aberrations or are statistically insignificant), the changes become part of the Information, and the Information and Preferences (which may have been changed by the Customer) are compared to the Plans in the Database. The Database may or may not have had one or more new Plans added since the last evaluation for this Customer. A New List is automatically generated, and is automatically compared to the List which was generated in the last evaluation. The Bundles that are optimal due to the minimization of total costs and/or the ability to satisfy the Preferences ("Optimal Bundles") are designated, preferably automatically. If one or more Optimal Bundles are not on the List, these Optimal Bundles are communicated to the Customer. Optionally, the entire New List may be communicated to the Customer. Another embodiment ("Fourth Embodiment"), which comprises alternatively the First, Second or Third Embodiment with the following additions, is described herein. After communicating the List or the New List to the Customer, the Customer directs the Coordinator to register the Customer for one Bundle. The Coordinator may or may not ask the Customer for permission to contact the Providers, which the Customer currently uses ("Old Providers"). Optionally, the Coordinator contacts one or more of the Old Providers, preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication, and tells the Old Providers about the Plan or the Plans in the chosen Bundle for the Service they provide. Each of these Old Providers may or may not have the first right to retain ("Right to Retain") the Customer by matching or bettering the Plan ("Matched Plans") listed in the chosen Bundle. The Customer may or may not be able to decline the Matched Plans. Customer is enrolled, preferably automatically via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication or in one or more Plans from the chosen Bundle with one or more Providers or optionally, for one or more Matched Plans.

The invention is encompassed in a further embodiment. After the First, Second, Third or Fourth Embodiment, the Coordinator may coordinate payment for the Customer to each Provider to which the Customer owes money. This coordination may include one or more of the following: receiving the Bills, communicating the Bills to the Customer, paying the Bills and billing the Customer or receiving funds or access to bank accounts from the Customer to pay the Bills. Further, the Coordinator may optionally audit the Bills upon receipt for any errors. If there are any errors in the Bills, the Coordinator may optionally try to negotiate with the Provider to correct the error or communicate the error to the Customer.

A further embodiment of the invention comprises receiving the Information from the Bills transmitted to the Coordinator, by either the Provider or the Customer, in an on-going basis. Coordinator gathers Customer's Preferences, preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. The Information and the Preferences are automatically analyzed, preferably with parametric or nonparametric statistical estimation, and the results are stored in a database, which may be a real-time or stored database. One or more Plans may or may not be eliminated from the potential Plans which may be evaluated to determine whether they are optimal for the Customer, due to Information which will not be adequately covered by one or more particular Plans or due to the fact that in prior analyses for this Customer revealed that one or more particular Plan was unacceptable due to Information or Preferences. One or more Plans may or may not be added to the Plans considered in the evaluation, depending on whether the Plans could satisfy the Preferences and cover the Services required by the Information. A List is generated from the remaining Plans which optimize the total costs and satisfy the Preferences.

Another embodiment of the invention is similar to the embodiment in the previous paragraph, with the following changes. Upon receiving the Bills, the Coordinator automatically statistically analyzes the Information and the Preferences, preferably with parametric or nonparametric estimation, and the results are stored in a database, which may be a real-time or stored database.

An additional embodiment of the invention allows the Coordinator to satisfy the Customer's Preferences and generate the List without processing every possible Plan for every Customer. The Coordinator compiles all of the usage Information from one or more consumers, which may or may not be Customers (preferably a statistically significant number of consumers) for a particular Type of Service (this may be accomplished for each Type of Service individually) into a distribution of number of consumers that use a specific amount of the Service (for example, how many consumers use particular amounts of minutes on a cellular phone). Statistical analyses, preferably parametric or non-parametric, generate distributional models of usage Information ("Models"). This will allow the

Coordinator to predict that a significant number of consumers use a specified range of cellular phone minutes ("Specified Range"), for instance 80% of consumers use between 20 and 200 minutes on a cellular phone each month. The Models are employed in conjunction with Plan Data and further statistical analyses, preferably parametric or non-parametric, to identify Plans that are statistically unlikely to satisfy any given Customer (e.g. Plans which do not offer Service coverage in the Specified Range). The Plans that are unlikely to satisfy may or may not be eliminated as possible solutions for each Customer. If no Plans or Lists are generated that will satisfy any given Customer, any Plans that had been eliminated from consideration may or may not be considered in another optimization step.

In another embodiment, the optimization algorithms are linear in time with respect to the number of available Plans. In a real-time system, more than one ^• Customer may be able to request an optimization of Plans simultaneously, requiring a unique optimization on the entire list of available plans for each requesting Customer. This real-time model scales well as a consequence of highly efficient optimizer algorithms. However, if the Coordinator received a high number of requests from Customers and/or a high number of new Plans, a real-time system may not be able to process the requests simultaneously, depending on the hardware and /or software capacity. Another subsystem ("Comparer") may be used as a floodgate during the transitional phases when backend systems are inadequate for the real-time demands. The rationale behind the Comparer is that if some of the plans from the list of plans to consider could be eliminated, the optimization would take less time, preventing the system from crashing until either the volumes of Customer requests and/or Plans decrease, or a long term solution can be implemented.

In this same embodiment, there are two methods by which the Comparer is able to eliminate Plans from consideration in the optimization process. First, the Comparer may eliminate all those Plans which are absolutely inferior to some other Plan. Absolute inferiority denotes a state wherein no fiscally rational person would select a particular Plan because a second particular Plan would be less expensive for any Customer. This requires the existence of two plans with exactly the same characteristics so that any Customer, whatever his Preferences, would consider the two Plans equivalent on all bases other than price. (For instance, Company A offers 100 free cellular minutes at anytime for $40/month and $1 /extra minute and Company A offers another Plan for 100 free cellular minutes at anytime for $60/month and $1 /extra minute, then this analysis may eliminate the second Plan from any further analysis with regard to every Customer.) Somewhat surprisingly, this absolute inferiority of Plans occurs fairly frequently, usually when Providers are making an attempt to phase out an older Plan and introduce an identical, yet less expensive Plan.

A second way to reduce the number of Plans considered for each Customer's optimization, in the same embodiment, has also been invented. The rationale behind this method stems from the following question: "If one Customer was selected at random, how likely would a given Plan be to suit this Customer's needs?" To answer this question, preference and usage profiling are employed to create statistical models of the distributions of both. Preferences and usage have both been found to have roughly normal statistical distributions, thereby forming a bell curve when volume of usage or degree of preference is plotted on the horizontal axis and the number of customers with such usage or preference level is plotted vertically. If a Plan is to perform well for the average Customer it must have certain characteristics, depending on the particular distribution for a given Type of Service. For example, if the standard deviation is large for service usage (i.e. the normal curve has a wide base), a Plan must be fiscally attractive for most of those usage levels to be considered desirable for any randomly selected Customer. On the other hand, if the standard deviation is low (i.e. the normal curve has a narrow base) a Plan must be fiscally attractive for those usage levels centered around the peak of the curve if it is to be considered good for any randomly selected Customer. In trying to predict the usage of the next Customer, prediction intervals on the aggregate data are appropriate metrics for the uncertainty of this particular statistic. Usage, a random variable with a normal distribution, must be linearly transformed, resulting in another random variable with a normal distribution. The true value of the random variable is unknown, which requires the use of a point estimator for each Plan, employing data collected from the current Customers or other sources. The minimum variance unbiased estimator (MVUE) is constructed using standard methods and the prediction interval is calculated on that statistic. This point estimator gives a reasonable estimate of the true cost of a particular Plan to the next Customer, and the corresponding prediction interval captures the uncertainty of that estimate. A summary statistic that accounts for both usage breadth and total cost factors is then constructed and used as an index for sorting Plans. By considering only those plans within a particular number of places from the top of the sorted list, the Plans considered in each optimization may be arbitrarily limited ("Reduced List"). After considering all those Plans on the Reduced List, the remaining Plans may be considered, if desired.

Calculating the potential costs incurred by a Customer is addressed in another embodiment of the invention. A Database is generated which includes one or more variables of one or more Plans offered by one or more Providers, including but not limited to peak time fees, off-peak time fees, flat fees, free usage, rewards, and geographic limitations. The Customer's Information is compiled from the Bills, while one or more Plans are designated as a potential solution set ("Solution Set") for the Customer. The estimated costs for the Customer for each Plan in the Solution Set is determined based upon the Information.

A method of ranking the Plans is embodied in a further embodiment, which comprises the following additional steps in addition to any one of the other embodiments. The Customer lists his output requirements ("Requirements"), including but not limited to lowest monthly bill, airline reward programs, best Plan for each Service, no minimum time period for the Plan, no penalties to terminate the Plan and listing all Plans. These Requirements determine how the List is generated and presented to the Customer. For example, if the Customer lists airline reward programs in the Requirements, then the List communicated to the Customer would list the Bundles with airline reward programs first. The Coordinator would automatically have the Bundles analyzed and ranked to display what the Customer requested in the Requirements. BRIEF DESCRIPTION OF DRAWINGS

The invention will become more readily apparent from the following description of preferred embodiments thereof shown, by way of example only, in the accompanying drawings wherein:

Figure 1 is a flowchart of an embodiment of the invention, which displays the steps in the inventive process.

Figure 2 is a flowchart of another embodiment of the invention, again detailing the steps of the inventive process.

Figures 3A-3C represent a flowchart of yet another embodiment of the invention, which details the steps of the inventive process. Figures 4a-4b display another embodiment of the invention in flowchart form.

Figure 5 is a block diagram of an apparatus embodiment of the invention.

Figures 6a-6b represent a flowchart of another embodiment of the invention, again detailing the steps of the inventive process.

Figure 7 is a flowchart of another embodiment of the invention.

Figures 8a-8b depict a flowchart of another embodiment of the invention.

Figures 9a-9h display the files and fields of a database in an embodiment of the invention.

Figure 10 is a diagram of the structure of a database of an embodiment of the invention. Figures 11 a-l lb depict a table of tags used in one embodiment of the invention.

Figure 12 depicts an example of the Parser output. Figures 13 a- 13b depict sample information input into and sample results generated from the invention.

Figures 14a-14h is a copy of a sample Bill. Figures 15a-15r depict a sample descriptor file in the Parser of the invention, and a sample bill for wireless phone service.

DETAILED DESCRIPTION A preferred embodiment of this invention is shown in Figure 1. The

Customer, an individual or business, provides the Coordinator with copies of his bills for any services or the Bills are obtained directly from the Provider, in paper form (1), in image form (3), in text format (5), or electronic format (7). The paper bills (1) are scanned into a computer in step (2), and then both the scanned bills from step (2) and the bills in image format undergo optical character recognition processing ("OCR") in step (4). After step (4), the OCR's results and the bills in text format are parsed in step (6) for usage information, including but not limited to one or more of: peak time usage, off-peak time usage, flat fees, and penalties. The results of step (6) and the bills in electronic format are added to the Customer Usage Database, which may be real-time or stored, in step (8).

Further, in the same embodiment, the Customer communicates his Preferences to the Coordinator. In step (9), the Preferences are input into the Customer Preferences Database, which may or may not be the Customer Usage Database. In order to complete the input of information which is required for the invention, Providers communicate the data ("Data") of the Plans, preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. These Data may include but are not limited to one or more of: flat fees, peak times, peak time fees, off-peak time fees, rewards and penalties. Since these Data may be provided in hard copy form, via information posted on the internet or directly from the Provider electronically, in step (10) the hard copy Data are manually input, in step (11) the internet Data are retrieved via an automated program, preferably a bot (a program that performs a repetitive task on a network), and in step (12) the Providers directly provide the Data electronically to the Coordinator; and the Data are placed in the Provider Plan Database (13), which may or may not be the same as the Customer Usage Database.

The Customer Usage Database, the Customer Preferences Database, and the Provider Plan Database are all accessed for analysis in step (14). In an effort to satisfy the Preferences based upon the Data and the Information, optimal Bundles of Plans are generated and compiled in Step (15) in the Results Database, which may or may not be the same as the Customer Usage Database, the Customer Preferences Database and/or the Provider Plan Database.

Referring now to Figure 2, a separate embodiment of the invention is demonstrated. The Preferences input into the Customer Preferences Database is used to compile a rules engine ("Rules Engine" 19). Since Preferences can take a wide variety of forms and encapsulate an infinite set of gradations of intensity, a system of accounting for Preferences is necessarily complex. The most difficult task is determining how to fairly weigh competing and possibly conflicting Preferences against each other. Furthermore, there is the problem of how to weigh non-financial Preferences against cost considerations. To solve these problems and minimize the possibility of strong other Preferences completely dominating cost in the ranking process (as later discussed), all Preferences are combined into a single weight factor by which the total cost of the Plan is multiplied before ranking. Applying these Preferences to the cost is not a simple matter, because storage limitations prohibit the storing of separate, Preference- weighted plans for every customer. Consequently the Preferences and their weight must be applied real-time. Furthermore, Preferences are exceedingly difficult and awkward to store in a database, since multiple conditions combined with boolean operators and the corresponding actions would require many records in several linked tables for each Preference of each Customer. Consequently, database access and data transfer times would be excessively large. After the Customer inputs the preferences, the system encodes them. Individual Preferences are represented by individual Preference language statements, and the collection of statements for a single Customer is stored in a text file on the server. Running in parallel with the Optimizer is a real-time programming language interpreter that decodes Preferences and applies the Preferences to the data model in memory. After checking any desired Plan characteristic, the Preference statement may eliminate a Plan from the list of Plans to be considered, change its Preference weight factor (for instance, if Customer prefers Company A, then Company A's Plans may be weighted heavier than the same Plan offered by Company B) or even change any Plan characteristic for the current optimizer execution (allowing the creation of hybrid or altered Plans provided the Providers can provide such Plans). Consequently, as Plans are loaded and checked for optimization, the Rules Engine applies Preferences in parallel which allows the Ranker to make recommendation decisions based on the weighted Preferences. In addition to applying Customer Preferences, the Rules Engine may be used to dynamically change plan characteristics. For example, if a Provider allows rate schedules to change if a particular Plan is bundled with another, that change can be made using the Rules Engine in real-time.

Upon the compilation of the Rules Engine (19), the Rules Engine works in connection with a comparer ("Comparer") (21) which automatically performs non-statistical, or preferably statistical, analysis of the best Plans for the Customer's usage. Upon receipt of new Bills from the Customer or upon request by the Customer, preferably via the internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication, the Comparer will reanalyze the Preferences and Information. Over time, the Data regarding a particular Customer and his analyses accumulates, allowing the Comparer to eliminate certain Plans from the analysis due to their inability to satisfy the Preferences or the Customer's usage. Further, in this same embodiment, the Information in the Customer Usage Database (18) is aggregated and processed into a set of fields, which are comparable for all Plans from any Provider, by a processor ("Processor") (22), which is preferably a computer-based analysis.

Continuing with the same embodiment, the Rules Engine (19), the Comparer (21) and the Processor (22), all provide information for a cost calculating analysis ("Cost Calculator") (23). After the Rules Engine (19) and the Comparer (21) have narrowed the set of possible Plans, the Cost Calculator determines the total cost that the Customer would have incurred for his current usage patterns for every Plan in the set. Hundreds of variables (for example those listed in Figures 9a-9h and described below) in the Processor are matched with the Data of each Plan. For example, the Cost Calculator will determine costs for long distance telephone service by considering one or more of the following factors, including but not limited to intra-state, inter-state, peak, off-peak, and weekend costs, taxes, monthly fees, surcharges, and free minutes.

After the Cost Calculator is finished processing, in the same embodiment, the Bundles of Plans are ranked according to the Customer's Requirements, or total monthly cost by the process called the Ranker (24). In the next step, the results from the Ranker are input into the Results Database (25), which may or may not be different from the Customer Usage Database, the Customer Preferences Database, or Provider Plans Database. Once the Customer receives the Ranker's results, the Customer selects its Bundle. Information about the Customer is given to the Provider, preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication, so that the

Customer can be enrolled for the Plan with the Provider. This whole process is noted as the Coordinator Process (26). Data about the Plan are stored in the Customer Usage Database (18) for future comparisons. Figures 3A-3C depict another embodiment of the present invention. Customer Bills are provided to the Coordinator (27). Any Bills that are in paper form (28) are scanned into a computer (29) and converted to image files (30), which are then converted to text files by OCR (31). Other Bills may or may not be provided as image or text files. The text files (32) are processed by a parser ("Parser") (33) to aggregate and process the information into a set of fields of electronic data (34) that are comparable across all provider plans (some of these fields are further described in the description of Figures 9a-9h below).

Usage information of Customers may come from a variety of sources, both digital and hardcopy. The digital information may be processed in the Parser

(33). The Parser is capable of extracting all useful usage information from a standard electronic bill whether it is in ASCII plain text, HTML, XML or some other representation. The general problem, which is solved by the Parser, results from the fact that within a standard bill, there exists much useful information dispersed among relatively worthless garbage text, primarily used for advertisements, service notices, formatting and aesthetics. The task of the Parser is to sort the useful from the useless information and organize the useful information into a usable form. Parsing the entire bill, including large unnecessary text blocks would require natural language processing algorithms which are incredibly complex and notably slow. The Parser in the invention however, recognizes the Bills as nothing more complex than a context free grammar.

A Context Free Grammar is a linguistic construct that describes a language wherein every symbol in that grammar has the same meaning, regardless of its position in any given document. While this restriction may seem crippling, this construct may be used so that context dependent symbols may be disregarded in Bills. Formally defined, context free grammars are 4-tuples: (§, V, S, R) wherein • § is the alphabet, in this case the English alphabet including the arabic number set and standard punctuation.

• V is the set of all nonterminals. These non-terminals or variables describe grammatical structures that store information and encode context. They consist of symbols from the alphabet in possible combination with other nonterminals.

• S is the start variable or the first non-terminal that the Parser attempts to recognize.

• R is the set of rules that define the composition of each nonterminal. Each nonterminal may have multiple rules defined in R.

By flagging certain symbols as having possible contextual ambiguity, the problem of context dependency can be avoided. A special non-terminal ("Garbage Text") may be defined to handle miscellaneous data having little or no importance to the invention, for example, advertisements or notices of service modifications have no meaning to optimization, yet may complicate the process of the Parser significantly since Parsers may be written in natural language. Paragraphs of Garbage Text are the only sections of a Bill that might call into question the assumption of context independence. Fortunately, this Garbage Text may be ignored. If any flagged symbol appears in a position that makes its meaning uncertain and the Parser defines this flagged symbol as Garbage Text, that data may be ignored. Even if the Parser does make a mistake in designating or not designating Garbage Text, the worst case scenario is a Parser error, rather than lost or corrupted data. In this way, Bills may be treated as context free grammars and processed by the Parser accordingly.

All important keywords will only appear where they should. In any cases where keywords have multiple meanings depending on position, the situation can be resolved through brute force methods. Since bills are context free grammars, it is possible to parse them using standard programming language compiler techniques. Due to its speed and error robustness, an LALR (look ahead left recursive) algorithm may be used for the Parser. To implement this part of the invention, a parser generator developed by the Free Software Foundation (FSF) known as Bison and a lexical analyzer generator developed also by the FSF known as Flex may be used. One problem to be solved in the Parser is the entry of new Bill types. Entering grammar descriptions directly using the Bison grammar descriptor format would require significant technical knowledge and professional level expertise with the C programming language. In order to make Bill entry as easy as possible, an XML language may be defined that has several predefined tags (see Figures 11a- 11b) for denoting specific predefined grammatical constructs and a considerable amount of flexibility in defining new structures. This language is based around Bill structures, not data structures. Consequently, it is simple for the person who is administering the entry of new Bill types to understand and to use. The XML document (seen in Figures 15a- 15c) may be processed and used to generate the input files for Bison and Flex which then generate code for the Parser. Continuing in the description of the same embodiment of the Parser, after creating a Parser, which may or may not be the same as another Parser, for each bill type (e.g. a Bill for a Particular Plan or Provider), upon receipt of a Bill, each of the Parsers could simply be tried successively until one of the Parsers returned an output without an error. Since the LALR algorithm is able to exit at the soonest possible time after an error is found, this solution becomes extremely efficient since most incorrect Parsers will fail before the first 10 to 20 tokens have been parsed. In addition, using information passed along with the bill by partners, such as provider name and customer account number, the list of possible bill types to consider can be greatly reduced. A sample long distance phone Bill is depicted in Figures 14a-14h. An example of the Parser's output (from the Bill in Figures 14a-14h) is displayed in Figure 12. As in the previous embodiment, the electronic data is then compiled into the Customer Usage Database (35). In the Customer Usage Database (35) step, the output of the Parser may be processed to verify whether Customer is a new or existing customer of the Coordinator. Each new Customer may have a new subscription record created. Then the output of the Parser is identified by Type of Service and grouped into subsets of information (e.g. for a long distance phone Bill, in-state calls may be grouped separately from state-to-state calls). This information may be aggregated to record certain enumerated information in the Database (e.g. the top 20 phone numbers called, the tope 10 states called).

Continuing in Figure 3B of the same embodiment, the Data about the Provider Service Plans (36) are gathered from paper descriptions (37) or telephone discussions (38), which are both manually input (41) into the Provider Plan Database (44), or from Internet websites (39) owned by the Provider, which may be manually input (41) or retrieved via Bot (42) for the Provider Plan Database (44). Additionally, the Data may optionally be provided through electronic data (40), which may be automatically downloaded (43) to the Provider Plans Database (44).

As seen in Figure 3C of the same embodiment, the Customer inputs his Preferences preferably by the Internet. The Rules Engine (48) processes the Preferences and defines parameters which are required for any Plan to be considered. The Rules Engine processes the Plans in the Provider Plans Database (49), and eliminates any Plans which will not satisfy the Preferences. The Customer

Information is also processed by a processor ("Processor") which compiles the Information into fields which are common among the Plans for each Service (45). For example, long distance telephone service usage may be distributed into 15-minute groups or buckets over a month. Figure 13a depicts a snapshot of the sample Bill's information input into the Processor and the details captured in 672 15-minute buckets over one month. This Information is further processed by analysis, preferably statistical or non-statistical, either parametric or nonparametric, in order to determine what types of Plans would satisfy this Customer's usage (46). Both results from step (46) and step (49) are processed, preferably automatically in order to calculate the cost for the Customer's usage under each Plan which would satisfy the Preferences and Information (50). Figures 13a-13b detail a sample output from the cost calculator step (50). The output of step (50) may be further processed so that the Bundles will be ranked according to lowest total cost, preferably monthly cost (a sample of which is depicted as output of the Ranker in Figure 13b). The results of this ranking are stored in the Results Database, which may be real-time or stored (52). A sample of the overall output is depicted in Figure 13b. In this embodiment, the Coordinator optionally facilitates the Customer enrollment in the new Plans with one or more Provider (53), this facilitation may include one or more of: contacting the

Provider, gathering data about the Customer for the Provider and agreeing to have the Provider change the Service to the new Plan, on the Customer's behalf. Preferably, this facilitation may be accomplished via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication with the Provider.

Figures 4a-4b display another embodiment of the invention. In step 54, the Customer's Bills are gathered from the Customer or the Provider and the Information is culled from these Bills, as set forth in the other embodiments. The Customer gives his Preferences to the Coordinator preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication in step (55). The Provider's Plans and the associated Data are compiled into a Database in step (56). Using the Information, Data and Database, a List of Optimal Bundles is generated (step 57), and in step (58) is communicated to the Customer preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. The Customer reviews the List and chooses a Bundle in step (59). Then the Coordinator contacts each Old Provider for each Plan on which Customer is currently enrolled, to inform the Old Provider about the new Plan that Customer desires in step (60) ("New Plan"). The Old Provider may have the right of first retention, and will keep the Customer if the Old Provider matches or betters the New Plan (in step (61)). Optionally, the Customer may change Providers even if the Old Provider matches or betters the New Plan. Another, separate embodiment is represented in Figures 6a-6b. In step,

74, the Customer's Bills are gathered from the Customer or the Provider and the Information is culled from these Bills, as set forth in the other embodiments. The Customer gives his Preferences preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication in step (75). The Provider's Plans and the associated Data are compiled into a Database in step (76). Using the Information, Data and Database, a List of Optimal Bundles is generated (step 77), and in step (78) is communicated to the Customer preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. The Customer or Provider provides new Bills to the Coordinator, and the Coordinator gathers Information from the New Bills in step (79) (as in step (74)). The New Information, new Plans and new Preferences, if any were provided by the Customer, are evaluated in step (80), and a new List of Bundles which satisfy the new Preferences and New Information is generated in step (81). The New List and the List are compared (82) so that one or more Optimal Bundles may be designated (83). If any of the Optimal Bundles are not on the List, those

Optimal Bundles (optionally, along with all the Optimal Bundles) are communicated to the Customer in step (84).

The invention is manifested in another embodiment represented in Figure 7. The Bills are received and the Information is gathered from the Bills (85) as described in other embodiments. Similarly, the Preferences are received (86) as described in other embodiments. The Information and Preferences are statistically analyzed (87), as also described in previous embodiments, and one or more databases, which may or may not be the same as other databases used in this embodiment, of the results are generated (88). One or more Plans may be eliminated as a possible solution for the List if the Plan(s) do not satisfy the statistical or other requirements (89). From the Plans not eliminated, a List of Optimal Bundles is generated in step (90). Continuing in the description of the invention with another embodiment, Figures 8a-8b represent yet another embodiment. In step 91, the Customer's Bills are gathered from the Customer or the Provider and the Information is culled from these Bills, as set forth in the other embodiments. The Customer gives his Preferences preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication in step (92). The

Provider's Plans and the associated Data are compiled into a Database in step (93). Using the Information, Data and Database, a List of Optimal Bundles is generated (step 94), and in step (95) is communicated to the Customer preferably via internet, intranet, electronic mail, telephone, wireless devices, cellular technology and/or personal communication. The payments for the Plans are coordinated for the Customer in step (96), so that Customer may receive one or more bills from the Coordinator for one or more Plans, and the Customer may direct the Coordinator to pay the Provider Bills, while the Customer pays the Coordinator. The Bills may be audited for errors in step (97), and if one or more error is found, the Coordinator may contact the Provider about the error (98). The Coordinator may or may not obtain permission from the Customer to negotiate and then attempt to negotiate with the Provider on the Customer's behalf regarding the error in step (99).

Figure 5 represents another embodiment of the invention. The other embodiments of the invention are preferably computer software which is implemented on the apparatus represented in Figure 5. The Customer's

Communication Device (62) is preferably a computer, telephone, wireless device, cellular phone or other media employed to communicate Information, Preferences and any Customer input to (67) or receive Lists or inquiries from (68) a Network (63). The Network is a group of computers and associated devices that are connected together by permanent connections, such as cables, or temporary connections, such as telephone links. The Network is preferably internet including the Web, on-line services, such as America-On-Line, intranet, local area networks, wide area networks, telephone system, wireless or cellular network or any media network.

Further in this embodiment, the Provider's Communication Device (65) is preferably a computer, telephone, wireless device, cellular phone or other media employed to communicate the Plans to (74) or receive enrollment information or right of first retention information (73) from the Network. The Information, Preferences, Plans, Lists and other communications from the Customer or Provider are sent (70) to one or more Servers (64). The Servers are mainframe computers, minicomputers, microcomputers (including personal computers or workstations) or other computers serving as a repository for data gathered and are preferably owned and/or operated by or on behalf of the Coordinator. The Server then sends the Information, Preferences and Plans (71) to one or more Databases (66), and the Databases supply the same to the Servers when needed (72). Finally, the Servers communicate Bundles and Lists to the Network (69) for transmission to the Customer's Communication Devices (67); and Bundles, Lists, enrollment information, and first retention information to the Provider's Communication Device (73).

Figure 10 depicts the structure of the Database described in Figures 9a-9h. Figures 9a-9h depict the data which may be contained in the Customer Usage Database (8), the Customer Preferences Database (9), the Provider Plans Database (13) and the Results Database (15). One or more of the following files and one or more of the fields may be included in one or more databases in this invention. The file Address (100) may contain one or more of the fields (lOOa-lOOh) which comprise a Customer identification number, address type or format of the address, a designation of the Customer's state, and Customer address information. Further, the Customer file (105) and Customer_Phones (106) for each Customer includes the fields (105a-105n) for the Customer's identification number, name, social security number, email address(es), title, suffix, date of first using the Coordinator, driver's license number, state, birthdate, and password, and the fields (106a-106f) with type of phone (for example landline, cellular, wireless), area code, hours of availability, phone number and extension. Any preferences entered by the Customer may be stored in the Preferences file (120) with fields (120a-120e) of the Customer's identification number, Provider identification number, type of Service, whether the Customer prefers to save on a particular Service or on the overall package of Services. Agg_Usage (101) is a file that contains one or more of the fields (101a- lOlh) which includes the identification assigned each of the particular Service Plans in which the Customer is currently enrolled, the type of Service (for example electricity, gas, water, telephone), the date of the Bill provided, the country in which the Service is rendered, the amount of the Bill, the number of minutes a Service is used by Customer, the dollars billed to the Customer, the account number or phone number in the value field, the number of calls. The fields (102a- 102b) in the Area_Codes file (102) store data of the area code of the Customer and links to the jurisdiction identification file, which limits the location of the Customer to help eliminate any inappropriate plans and calculate the relevant costs of Plans. Each state is assigned a code and that is stored in the State file (128, fields 128a-128b). The zip codes are stored in the Zip_Codes file (140), and each zone's information is stored by type of record (for instance state), value of record (for instance Pennsylvania) and jurisdiction identification in the fields (141a-141c) of the Zones file (141). Data regarding Bundles are stored in the Bundles file (103), and include (in fields 103a- 103 f) an identification number assigned to a particular Bundle, the date on which the Bundle can first be offered to Customers, the name of the Bundle, the last date on which the Bundle can be offered, the flat fee if any associated with the Bundle, and a designation of commitment (e.g. what penalties are incurred if a Customer changes a Plan before a specified time).

Each Provider's information will be stored in the Provider file (122) with one or more of the fields (122a- 1221) including an identification number assigned to the particular Provider, a code of the state in which the Provider offers Plans, the Provider's name, address, the Parent Provider identification (this tracks the parent company, which offers each particular Plan), the website, phone number and a code to be used with any Plan from the Provider which is coordinated by Coordinator (so the Coordinator may be credited with bringing the Provider business). For each type of Service, there is a Types of Service file (134) which includes the type of Service and a description of that Service in fields (134a-134b). The Provider is linked to its Type of Service in the fields (135a-135b) of the Types OfjServiceJProvider file (135). Each type of rate scheme (for example, by the minute, flat fee, including certain peak and off-peak minutes) is stored in a Rates file (125) with the fields (125a-125e) with an identification number assigned to this rate scheme, with start and end dates of the scheme, the type of Service, and any fixed fee. The Rates_Schedules file (124) stores the variable rate information for a particular Plan, while the Rates_Repeating file (126) stores the constant rate information (126a- 126c) for a particular plan. The Sequence_gen file (127) generates sequences used to assign unique identifications for each identification field (127a- 127b). The Rates_Schedule_Aggregate file (123) stores the aggregate rate information of a particular Plan (e.g. number of free minutes) (123a-123c). When the Data of the Provider's Plans is provided, it is stored in the Plans file (118) with one or more of the fields (118a-l 18i, 1181-118q) including an identification number assigned to the Plan, an identification number assigned to the provider, the type of Plan, a description, whether the Plan must be offered with other Plans, the start and end date when the Plan is offered, Rate identification (which relates the file to other files with rate information for the Plan), timeschedule identification, the name of the Plan, type of Service, and whether the Customer has been enrolled. If a Plan has more than one sub-Plans offered, this information may be included in the Plans file. Each Plan may be limited in geographic scope, which would be stored in the Plans_Coverage File (119) which includes the fields (119a-l 19e) of an identification of the jurisdiction (or geographic scope), the start and end dates of the Plan, the identification of the

Provider, and the Plan identification number. On occasion, a Provider may offer a promotion associated with a Service, and that Data may be stored in the Promotion file (121) with the fields (121 a- 121 g) including an identification number assigned to that particular Promotion, an identification number for the Bundle in which the Promotion is included, the Promotion name, the monetary amount of the Promotions, the start and end date of the Promotion, and a description of the Promotion. Some of the Provider's Data is stored in the Feature_Master (108) file with the fields (108a- 108c) for the identification of the feature file, the type of Service and the name of the feature offered in the Plan by the Provider. The Features_Plan (110) file stores the date for each Plan, including the fields (1 lOa-1 lOg) of the start date for each feature (for example amount of peak minutes included in the flat rate for a particular telephone service Plan), the type of Service, the feature value, which is the dollar value of the particular feature in that Plan, the end date for each feature, the identification number, the Provider identification and the Plan identification number. The Jurisdiction File (111) also stores data in the fields (11 la-11 lb), as does the Levels File (112) with fields (112a-l 12e), which addresses any variations in rates above or below a specified level of usage. Any taxes associated with each particular jurisdiction is stored in the Taxes_Tariffs file (130) with the jurisdiction identification and identification assigned to the tax in the fields (130a- 130b). Once a Customer has made a choice of Plans, the Choice file (104) has a list of all the Plans and Bundles of Plans which can be offered to the Customer. The Orders file (115) may store the fields (115a- 115k) including the identification number assigned to this particular Customer's order, the Customer's and Provider's identification numbers, the date on which the Order was placed with the Provider, Customer's credit card type, number, and authorization, amount of the order, expiration date for the credit cards, status of the order and a reference number assigned to this Order. If the Customer has selected on or more features, the data is stored in the Features_Customer_Bundle file ( 109) with the fields ( 109a- 109f) for the Provider's identification number, the type of Service, the end date on which the Customer will cease receiving the Feature, the identification for the Customer's enrollment in the Plan, the identification number of the Plan, and the identification number associated with the FeatureJVIaster file. Once the Customer is enrolled in a Plan, the Subscriptions file (129) stores fields (129a-129i) which may include the start date, Plan identification number, end date, term of the enrollment, account number, an identification assigned to the Subscription, the Provider identification, Order and Customer identification.

As the Coordinator receives the Bills of the Customer, the information regarding the Customer's usage will be stored in Usage_Detail (136) in fields (136b- 136g), the year, number of week, number of units used, an identification number assigned to this Bill's usage, the identification of the Detail file, and the associated Subscription identification. The UsageJVIaster (137) captures a Customer's usage for a Type of Service. The Usage_Running_Avg (138) comprises the master table of 672 (15 minute groupings) identifications for the detail records of usage over an entire month, while User_Running_Avg_Detail (139) comprises the 672 detail records of usage.

The present invention may be embodied in other specific forms without departing from the spirit or essential attributes of the invention. Accordingly, reference should be made to the appended claims, rather than the foregoing specification, as indicating the scope of the invention.

Claims

What is claimed is:

1. A method for minimizing total customer cost for bills, comprising: gathering usage information derived from a customer's bills; receiving one or more customer preferences, wherein said preferences comprise one or more of the group consisting of geographical limitations, utility provider limitations, and anticipated usage patterns; compiling a database of one or more service plans offered by one or more providers; generating, in response to said customer preferences, a list of one or more service bundles for said customer, wherein said bundle optimizes a total amount due for all said bills; and communicating said list to said customer for evaluation.

2. The method of claim 1 further comprising: automatically gathering said usage information upon receipt of each bill; automatically evaluating said usage information, with new preferences resulting from one or more permanent changes in a usage pattern; automatically generating a new list of one or more service bundles, said bundles optimize a total amount due for all said bills and satisfy customer preferences; automatically comparing the list and the new list; designating one or more optimal service bundles; and communicating the optimal service bundles to customer, in the event one or more optimal service bundles are not in the list.

3. The method of claim 1 further comprising: receiving a direction from said customer to register said customer for one service bundle; and enrolling said customer with said providers for one or more plans in said service bundle.

4. The method of claim 1 further comprising: receiving a direction from said customer to register said customer for one service bundle; automatically contacting a old provider which the customer already uses with the information of a cost of the relevant plan in the bundle; and allowing the old provider to retain the customer by offering the identical relevant plan or a better relevant plan.

5. The method of claim 1 further comprising: coordinating payments for said customer to all said providers; and auditing said bills for one or more errors.

6. The method of claim 1 further comprising: generating distributional models of one or more customer's usage information for one or more types of service; and identifying one or more plans which are statistically unlikely to satisfy any customer.

7. The method of claim 6 further comprising: eliminating said unlikely plans from consideration for the list.

8. The method of claim 1 further comprising: eliminating from possible inclusion on a list one or more plans which have the same characteristics as another plan and is more expensive.

9. The method of claim 1 further comprising: assigning in real time a weight to each plan based upon said preferences.

10. A method of comparing customer usages to service bundles comprising: receiving a customer's usage information from one or more bills transmitted to the coordinator on an on-going basis upon receipt of said bills; gathering one or more customer's preferences; automatically statistically analyzing said usage information and said customer preferences for a list of one or more optimal service bundles, said statistical analyzing comprises one or more of the group consisting of parametric and nonparametric estimation; generating a database, said database comprising said usage information from said bills; eliminating one or more provider plans from a possible solution set based upon said usage information; eliminating one or more provider plans from a possible solution set base upon prior iterations of said analysis; and generating a list of one or more service bundles, said bundles optimize a total amount due for all said bills and satisfy customer preferences.

11. A method of calculating the potential costs incurred by a customer with a specified provider plan comprising: generating a database, said database comprising one or more variables for one or more service plans offered by one or more providers; compiling a customer's usage information from one or more bills transmitted to a coordinator; designating a set of said plans as a potential solution set for said customer; and determining a cost for each said plan in said set.

12. A method of ranking service plans comprising: ranking service plans for said customer according to said customer's output requirements comprising one or more of the group consisting of lowest bill, best plan for each service, and listing all service plans.

13. An apparatus for minimizing total customer cost for bills, comprising: a means for gathering usage information derived from a customer's bills; a means for receiving one or more customer preferences, wherein said preferences comprise one or more of the group consisting of geographical limitations, utility provider limitations, and anticipated usage patterns; a means for compiling a database of one or more service plans offered by one or more providers; a means for generating, in response to said customer preferences, a list of one or more service bundles for said customer, wherein said bundle optimizes a total amount due for all said bills; and a means for communicating said list to said customer for evaluation.

14. The apparatus of claim 13 further comprising: a means for automatically gathering said usage information upon receipt of each bill; a means for automatically evaluating said usage information with new preferences resulting from one or more permanent changes in a usage pattern; a means for automatically generating a new list of one or more service bundles, said bundles optimize a total amount due for all said bills and satisfy customer preferences; a means for automatically comparing the list and the new list; a means for designating one or more optimal service bundles; and a means for communicating the optimal service bundles to customer, in the event one or more optimal service bundles are not in the list.

15. The apparatus of claim 13 further comprising: a means for receiving a direction from said customer to register said customer for one service bundle; and a means for enrolling said customer with said providers for one or more plans in said service bundle.

16. The apparatus of claim 13 further comprising: a means for receiving a direction from said customer to register said customer for one service bundle; a means for automatically contacting a old provider which the customer already uses with the information of a cost of the relevant plan in the bundle; and a means for allowing the old provider to retain the customer by offering one of the group consisting of an identical relevant plan and a better relevant plan.

17. The apparatus of claim 13 further comprising: a means for coordinating payments for said customer to all said providers; and a means for auditing said bills for one or more errors.

18. An apparatus of comparing customer usages to service bundles comprising: a means for receiving a customer's usage information from one or more bills transmitted to the coordinator on an on-going basis upon receipt of said bills; a means for gathering one or more customer's preferences; a means for automatically statistically analyzing said usage information and said customer preferences for a list of one or more optimal service bundles, said statistical analyzing comprises one or more of the group consisting of parametric and nonparametric estimation; a means for generating a database, said database comprising said usage information from said bills; a means for eliminating one or more provider plans from a possible solution set based upon said usage information; a means for eliminating one or more provider plans from a possible solution set base upon prior iterations of said analysis; and a means for generating a list of one or more service bundles, said bundles optimize a total amount due for all said bills and satisfy customer preferences.

19. An apparatus of calculating the potential costs incurred by a customer with a specified provider plan comprising: a means for generating a database, said database comprising one or more variables for one or more service plans offered by one or more providers; a means for compiling a customer's usage information from one or more bills transmitted to a coordinator; a means for designating a set of said plans as a potential solution set for said customer; and a means for determining a cost for each said plan in said set.

20. An apparatus of ranking service plans comprising: a means for ranking service plans for said customer according to said customer's output requirements comprising one or more of the group consisting of lowest bill, best plan for each service, and listing all service plans.

21. A method of parsing information from one or more bills from one or more providers for one or more plans comprising: describing a bill's format with a graphical user interface, said description noting one or more of characteristics consisting of important information, position of the particular information, data types, and table details; transferring the description to one of the formats consisting of XML, HTML and self-defined tagged languages; automatically generating one or more functions in programming language from the modified description; using the function to process one or more bills from one or more providers as context free grammar, and extracting the information from said bills.