AU2001251048A1 - Usage-based price planning - Google Patents

Description

USAGE-BASED PRICE PLANNING

This invention relates to networks and network usage, and more particularly to network pricing plans. BACKGROUND

Service providers are in constant competition with each other to find new ways of attracting customers. An increasing number of service providers have entered the ever-growing world of e-commerce that demands high quality of service and quick turn-around time. E-commerce service providers offer a wide range of services that involve direct on-line services such as network access from Internet Service Providers (ISP) and Network Service Providers (NSP) and more traditional services such as e-commerce auctioning to further their service. For example, many on-line auction services use e-commerce to help sellers put their products up for auction while a number of buyers enter a bidding war leading to an ultimate purchase between the high bidder and the seller. All of these services found on-line involve some sort of usage, whether that usage be time spent on-line or bandwidth used during the time on-line. In particular, ISPs and NSPs provide network access to users who range from an individual web surfer who may be on-line a few hours at a time to large corporations who may be on-line 24 hours a day, seven days a week and who require a large amount of bandwidth.

Whether an individual surfer or a large corporation, customers attempt to find the best possible deals to minimize the cost of being on-line. ISPs and NSPs typically offer pricing plans to their customers that involve a charge per unit time, whether that be an hourly charge or an unlimited monthly charge. In addition, many ISPs and NSPs have an "acceptable use" condition for using their service. For example, customers cannot send "spam" emails over the link provided by the ISP or NSP. Another condition is that a customer cannot hook up a server to the link because the server can use an unacceptable amount of bandwidth. However, ISPs and NSPs typically are not equipped to monitor violations of these conditions. Furthermore, increasing ISP competition drives the marketing departments of the ISPs to come up with quick changes in the ISP pay plans to meet the market demand.

SUMMARY In general the inventions features a method and apparatus for representing pricing plans for on-line services, in particular for Internet and network services.

In one aspect, the invention features a method of determining a billing-cycle price for network services, including establishing a price plan for each of a plurality of clients, wherein the price plan sets a price per use unit, collecting use data from the plurality of clients, sorting the use data into data groups corresponding to each of the plurality of clients; and processing the data groups to determine the billing-cycle price for each of the plurality of clients, wherein the billing-cycle price is calculated from use data and the price per use unit.

In an implementation, the price per use unit is determined by: time that each of the clients used the network services, network bandwidth that each of the clients used, network content that each of the clients used, email that each of the clients generated on the network, electronic storage space used by each of the clients, web space that each of the clients used, multimedia usage that each of the clients used, or Internet protocol addresses in use by each of the clients. In another implementation, the method further includes allowing each of the plurality of clients to choose a price plan that includes more than one price per use unit, calculating a billing-cycle price for each price per use unit, presenting each billing-cycle price to each of the clients, allowing the client to choose the billing-cycle price that is the most cost efficient, transmitting a bill presentation template to each of the clients, wherein the bill presentation template is transmitted to a client web browser connected to the network, and displays charges presentation incurred dming the billing cycle.

In another aspect, the invention features a method of developing a price plan for services on a display, including providing an interface on the display, providing on the interface images adapted to receive price plan criteria and receiving in the images price plan criteria.

In an implementation, the images on the interface are graphical user interface (GUI) screens. In another implementation, providing the images comprises presenting the

GUI screens in an order to present price plan criteria input options for generating the price plan to the user.

In another implementation, the method further provides generating the price plan into source code and compiling the computer code into machine-readable code. In another implementation, the method provides supplying the price plan data to at least one of the source code and the machine-readable code to calculate a charge for the services.

In still another implementation, the images on the interface are graphical elements representing components of the price plan and providing the images includes _, arranging the graphical elements on the display that graphically represents the calculations for the price plan charge and providing interconnections among the graphical elements to provide price plan data flow paths.

In yet another implementation, the method further includes storing the arrangement of graphical elements as source code, compiling the source code into machine-readable code and supplying the price plan data to at least one of the source code and the machine-readable code to calculate a charge for the services.

In another aspect, the invention features method of billing for services, including determining a price plan that charges a client for services based on use, keeping a record of data of the client's use of the services, determining a charge for the services based on the price plan and the record of the client's use of services and presenting a bill for the services.

In an implementation, determining the price plan includes establishing the type of use for which the client desires to be billed, establishing a unit of cost for the type of use and generating a customized price plan template that reflects the type of use and the unit of cost and is adapted to receive the record of data. In another implementation, determining the charge for the services, comprises using the customized price plan template to calculate the service charge by processing the record of data based on the type of use and the unit of cost and presenting the bill for services includes generating a bill presentment template adapted to present the record of data, the type of use, the unit of cost, and the service charge and presenting the bill presentment template to the client.

In still another aspect, the invention features a price plan network system, including at least one data collector adapted to collected client data from the network, a database coupled to the data collector, a price plan builder coupled to the database, the price plan builder having a user interface a first software module having a price plan template adapted to direct a user through a series of steps to develop a price plan, a second software module coupled to the first software module, the second module including a plurality of components adapted to be interconnected to build a price plan source code, an object builder adapted to compile the source code into machine readable code and a bill presentation module coupled to the database.

In an implementation, the system further includes a rater coupled to the database, adapted to be controlled by the machine-readable code to process the client data into billing data.

In another implementation, the bill presentation template includes a user interface adapted to display the client data and the billing data

In yet another aspect, the invention features a price plan development and presentation system including means for building a price plan based on a client's use of services, means for collecting raw use-based client data, means for processing the use-based client data using the price plan and means for presenting the raw and processed use-based client data to the client.

In another aspect, the invention features a network service provider method of charging a client for comiecting the client to the network including developing a price plan agreement between the service provider and client, the agreement stating that the service provider provides a connection to the network in exchange for compensation from the client, the compensation being calculated based on the client's use of the network, providing to the client a connection to the network, collecting use-based data from the network, processing the use-based data based on the price plan and presenting the charges to the client.

In another aspect, the invention features a method of creating a price plan in a graphical program on a computer having a memory, a display, a user input and a processor, including storing in memory a plurality of executable functions representing aspects of the price plan, assembling a data flow diagram on the display in response to user input to specify the price plan, the data flow diagram including function icons corresponding to the respective ones of the executable functions and generating an executable program from the data flow diagram. In an implementation, the method further includes receiving price plan data in the executable program, processing the price plan data to calculate charge output data, creating a bill presentation template on a web page and providing the charge output data to the bill presentation template.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS Fig. 1 illustrates a network access system

Fig. 2 illustrates an implementation of a billing system.

Fig. 3 illustrates a process flow chart of an implementation of a biller/raler.

Fig. 4 illustrates a process flow chart of an implementation of a graphical price plan. Figs 5 A-5C illustrate screenshots of an implementation of a price plan wizard.

Fig. 5D illustrates a flow chart of an implementation of price plan development using a price plan wizard.

Fig. 6 A illustrates a flow chart for an embodiment of price plan development.

Fig. 6B illustrates a process flow chart of primitives used in a price plan. Fig. 6C illustrates a screen shot of an embodiment of a price plan builder.

Fig. 7A illustrates a flow chart for an implementation of a diagnostic run time process.

Fig. 7B illustrates a flow chart for an implementation of a process to build object code.

Fig. 8 illustrates a flow chart for an implementation of a rating engine process.

Fig. 9 illustrates a flow chart for an implementation of a billing presentation process.

Fig. 10A illustrates a screen shot of an implementation of a blank bill presentation template .

Fig. 10B illustrates a screen shot of an implementation of a bill presentation template after it is provided with billing data.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Fig. 1 illustrates a network access system 100. Several devices 110, such as personal computer stations, may desire access to a network 120, such as the Internet. A service provider 130, such as an NSP or ISP can provide network access through a series of connections 150, such as telephone modems or cable modems, linking the devices 110 to the network 120. The devices 110 may desire to search the network 120 for information or gain access to any one of a variety of servers 140. The service provider 130 typically imposes a charge to link the devices 110 to the network 120. Therefore, the service provider 130 also collects data related to billing the devices 110 for connection to the network 120. Fig. 2 illustrates an implementation of a billing system 200. A client 210 may want to access a network 220 such as the Internet. The client 210 can obtain this connection through a service provider 230. If necessary, a virtual private network (VPN) module 245 is used to provide a private connection between the client 210 and the network 230. The client 210 typically signs up with the service provider 230 through a registration/provisioning engine 240. Using the registration engine, the service provider 230 can query the client 210 for pertinent information concerning the client such as method of payment for services as well as a price plan that the client 210 desires to use. The client 210 can have a predetermined price plan that determines how the client 210 is billed for the connection to the network 220. In a typical embodiment, the price plan is use-based. Use-based price plans are discussed in detail below. A collector 235 is used to collect the use-based data. The collector 235 is adapted to collect any of the use-based data, such as time-stamps for time based-usage, bandwidth used for bandwidth-based usage, and number of emails and size of the emails for email-based usage. Typically, time stamps are collected for all types of data so that price per unit can be determined by time when use is incurred. For example, different price units can be applied on bandwidth use depending on the time of day. In other embodiments, the collector is adapted to collect any data depending on the usage-based plan that the client 210 has chosen. Also, the collector 235 is used to manage the addresses of the numerous clients attached to the service provider 230, as well as providing application switches to the individual clients. In one embodiment, the collector utilizes Radius software to manage real time switching between clients to ensure that the proper use-based data is charged to the proper client. In another embodiment RMON2 software is utilized. The principal function of the collector 235 is to collect and resolve usage data into accounts from various usage information sources such as RADIUS and RMON2 devices. The usage information sources are not part of the collector 235. The collector 235 does not typically have other functions such as managing client addresses, application switches and the like. Referring still to Fig. 2, a biller/rater 250 is used to calculate the charges that the client 210 incurs while connected to the network 220. The biller/rater 250 is also used to present the bill to the client 210 after a billing cycle. Billing and rating functions of the biller/rater 250 are discussed in detail below. The biller/rater 250 is used in close conjunction with the collector 235. Once data is collected, the management software is used to direct the appropriate billing charges the biller/rater

250 in order to calculate the correct charges which are billed to the client 210. The charges billed to the client 210 are dependent on the price plan for which the client signed. An account management module 255 is used to manage use-based data collected from the client 210 through the collector 235. The rater 250 ensures that the client 210 is charged only for the network usage incurred by the client 210 and not a different client. The account management module 255 works in close conjunction with the collector 235 and the biller/rater to store and manage the incurred charges. A market intelligence module 260 monitors and processes client 210 usage as well as price plans and client usage from other service providers on the network 220 to determine new marketing strategies. A payment/financial module 265 is used to track payments made by the client 210 and any other related financial matters. A database 270 is used to store client 210 information as well as price plans that the service provider 230 offers and a variety of other service provider-related information.

The client's 210 usage may be based only on time such as an hourly or monthly charge or may be based on some other usage-related basis such as bandwidth, content, email, storage web space, active internet protocol (IP) addresses, downloaded movies, or downloaded music. For example, the client may be a server that receives a large volume of traffic on a daily business. A service provider 230 may want to charge a server-client with a large traffic volume by bandwidth in this situation. In another example, the client 210 may be billed only on the number of emails that are sent between the client 210 and the network 220. The client can have a predetermined plan that outlines a how the client is charged for the network usage. Typically, charges are incurred by uses including but not limited to time, bandwidth, content, email, electronic storage, web-space used, multimedia usage such as video and audio downloads, and IP addresses in use. For example, a client may choose a plan that bills the client for time spent on the network. Under a time-based plan, the client can be charged either by the hour or minute or can be charged once per week or month for unlimited minutes or hours. If the client is rimning a server on the network, the client may choose a plan that charges the client for the bandwidth used regardless of the time spent on the network. Under another plan, the client may be charged by the number of emails generated, whether sent or received. The email-based plan may also include a further stipulation that the emails sent and received have to be of, at most, a certain size, or a further charge is incurred. For example, each email may be limited to 3 Megabytes, and for every Megabyte above 3 Mbytes, a further charge is incurred to take into account additional bandwidth used for the email. Still another plan can allow a client to download movies or sound files from web sites at a certain price per movie or sound file. In one embodiment, the client can choose an omni- inclusive plan that encompasses several of the above-described plans. One goal of the omni-inclusive plan is to track charges for each of the plans included in the omni- inclusive plan. At the end of the billing cycle, the client can then be presented with a template including each charge of each plan. The client can then choose to pay for the plan that is the least expensive. In this way the client can use several plans on a trial basis and determine which plan suits the client the best. In an implementation of the omni-inclusive plan, the client is charged an additional cost each billing cycle for being able to decide among several plans. After several billing cycles, the client can opt out of the omni-inclusive plan and decide to remain with only one plan. For example, if an NSP offers several use-based plans such as time, bandwidth, email and web space, a client can choose to track charges for each of the plans under an omni- inclusive plan. At the end of a billing cycle, the client is presented with a bill that shows a charge for each of the time, bandwidth, email and web spaced used. The client can determine, for example, that the time-based charge was the least expensive and chooses to pay only the time-based charge. The client is also charged an additional cost to have the ability to choose among the plans. Thereafter, the client 210 can then choose to be charged only under the time-based plan.

The billing and rating functions mentioned above are interrelated with one another and encompass both service provider 230 and client 210 interaction. Fig. 3 is a process flow chart illustrating an implementation of the operation of the biller/rater 250. The service provider 230 has the ability to graphically define a price plan with a series of software "primitives" which are connected together in a graphical programming environment, such as Visio®. Primitives and their functionality are discussed in detail below. A graphical price plan 310 is created by the service provider 230. The client 210 uses a client browser 330 in order to sign on to the network 220 and perform network functions such as web surfing through the service provider 230. The client browser 330 also is used to initially choose a price plan and to have the billing charges presented to the client 210 at the end of a billing cycle.

Around the same time that the price plan is defined using the graphical price plan 310, a bill presentation template 320 is also defined. The bill presentation template 320 is typically determined by the price plan chosen by the client 210. However, the bill presentation template can be modified to meet the needs of the client 210 or the service provider 230. As charges accrue, the collector 235 gathers the charge data and transfers it to a data repository 360. The charge data is transferred to a rating engine 340 and to the web bill presentment. The rating engine 340 is coupled to the graphical price plan 310. The rating engine 340 uses the price plan primitives from the graphical representation to process the charge data. Depending on the price plan chosen by the client 210, the data gathered by the collector may be different for different clients. For example, if the client 210^' chose a time-based price plan, then the rating engine would typically acquire time stamp information from the gathered charge data. If the client's price plan were based on bandwidth used, then the rating engine 340 would acquire data indicating the number of bytes used by the client 210 during the network session. If the client's price plan were based on the number and size of the emails sent to and received from the network, the rating engine 340 processes only the email data.

The data repository 360 is also coupled to the web bill presentment 350 so that the client can also view the "raw usage" before they are processed by the rating engine 340. The web bill presentment 350 is the web interface with the client browser 330 for bill viewing. The rating engine 340 stores the processed use data in an account database 370, which is also coupled to the web bill presentment 350. The account database 370 stores all of the client's billing pertinent information such as a chosen price plan. The rating engine 340 is also coupled to a bill details database 380, which stores all of the processed data. Therefore, the client 210 can view and compare the raw use data with the processed use data. If the client 210 has chosen more than one price plan or all of the price plans as discussed above, the client is able to view all raw data and all processed data on the web bill presentment 350. The bill presentment 350 enables a client 210 to make a decision on which price plan works best for the client's needs. Billing and Rating

The graphical price plan 310 is an aggregate of several components that the service provider 230 uses to build a price plan for the client 210. Fig. 4 illustrates a process flow chart of an implementation of the graphical price plan. In this implementation, the aggregate of components that make up the graphical price plan are a rating plans database 410, a rating primitives database 420, and plan object builder 430 and a plan objects database 440. The rating primitives database 420 is a storage medium for the primitives that are the software components used to build a price plan. Primitives are programmed to serve a specific function. Primitives can be programmed for virtually any function that is needed for the price plan. A description of primitives and their function is discussed below. A rating plans database 410 contains graphical programs made from interconnecting a series of primitives from the rating primitives database 420. The rating plans can be viewed as graphical source code. A plan object builder 430 is the compiler for the graphical source code. The graphical source code is compiled and stored as an object file in a plan objects database 440. The rating engine 340 can access, from the plan objects database 440, a plan object that corresponds to a plan the client 210 has chosen. The rating engine 440 then executes the plan object code and processes the raw data from the collector 235. While primitives are the fundamental building blocks of a price plan, building a price plan has several levels of complexity. For a non-technical person such as a marketing manager and salesperson, a high level editor is needed that allows a price plan to be developed quickly without requiring a high level of technical savvy. Figs. 5A-5C illustrate screenshots of an implementation of a price plan wizard. Fig. 5 A is a screenshot 500 of an implementation of an introductory screen for a price plan wizard. The screenshot displays textual instructions 505 to guide the developer through the price plan building process. Fig. 5B illustrates a screenshot 510 of an implementation of a screen in which a price plan developer can choose what kind of charges 515 incur in the price plan. As seen in the figure, a simple fixed charge 515a, such as one monthly charge, can be implemented in the price plan. A recurring charge 515b such as a per minute charge can also be incurred. A use-based charge 515c can also be incurred. The use-based charge 515c is the charge for such usages as bandwidth, email, and other usages as described above. Fig. 5C illustrates a screenshot of an implementation of a fixed charge screen 520. Using this screen, the developer of a price plan can impose a one-time charge on a client 210 for a set up charge or other type of one-time charges. Using the price plan wizard, a developer can quickly customize a price plan for a customer without burdensome programming.

Fig. 5D illustrates a flow chart 530 for a typical embodiment of a price plan development using a price plan wizard. When the price plan wizard is initiated it is first determined 535 if there are any one-time charges. If there are, then the developer provides 540 the details, that is, the cost and conditions of the one time charge. The next query is whether there are any recurring 545 charges. If there are recurring charges, then the developer provides 550, the amount and frequency of those recurring charges. Typically, the recurring charges will be a unit charge per minute, hour or month. The next query 555 is whether or not there are any use-based charges. However, in one implementation, there can be a recurring monthly charge as well as an additional charge for bandwidth used, email generated and received or any other use-based charges as discussed above. If there are use-based charges, then the developer provides 560 the description and amount of the use-based charges. In a typical plan, there may be some free usage. Therefore it is queried 565 whether or not there is any free usage. If there is free usage, then the developer provides 570 the details of the free usage. In one embodiment, the free usage may be a certain number of free connection hours. In another embodiment, the free usage may be use-based (i.e., bandwidth, email etc.) Another typical query 575 is whether there are any peak- related charges. If there are peak-related charges then the developer provides 580 the details of the peak-related charges.

The price plan wizard then ceases the queries and a series of primitives are connected and compiled without interaction from the developer. Price plan object code is then available in the price plan database 410 for execution. The price plan graphical source code is typically stored as XML code. While the high level price plan wizard is a vital tool for non-technical agents of the service provider 230, it lacks further the flexibility of directly connecting primitives which can provide further extensibility for price plan development.

As mentioned above, in one embodiment, a graphical programming program such as Nisio® is used to build a price plan by interconnecting numerous primitives as a flow. In such an embodiment, a service provider agent can build a price plan quickly and efficiently using this price plan editor. For example, a marketing manager in an ISP company such as can quickly respond to changes that competitors have made in a price plan by opening the price plan wizard or having one of the programmers use a price plan editor to connect a series of primitives to match the price plan offered by a competitor. As another example, if a salesperson for an ISP is discussing a deal with a large corporation, the salesperson can quickly and efficiently make changes to a price plan using the price plan wizard. If the large corporation does not like any of the price plans that the salesperson can create using the price plan wizard, the salesperson can contact an engineer or programmer to use the primitive editor to create a more suitable price plan. The programmer can attempt to use the existing primitive in the rating primitives database 420 existing primitives from the rating primitive database 420. If the existing primitives are not sufficient, the salesperson can communicate the desires and needs of the corporation and the programmer can write a new primitive that meets the needs of the corporation. The flexibility and extensibility of primitive programming allows sales people, marketing managers and programmers to work independently or in conjunction to respond to marketing and sales needs in a competitive environment. In an embodiment, the primitive programming language can be any open platform language such as Java®, C, C++ and Visual Basic®.

Many references have been made to primitives. The discussion now addresses primitives and their functionality. The following table represents a subset of categories of a number of primitives and a short description of the function of each primitive as it can be used in any of several implementations:

Table 1. Primitives can be programmed directly in a primitive programming environment, which typically involves adding primitives and interconnecting primitives using typical data flow programming. If there are no primitives that meet the needs of a particular price plan, a programmer can create a new primitive by traditional programming methods such as Java®, C, C++ and Visual Basic®.

Primitives are also connected while using the price plan wizard. As discussed above, using the price plan wizard, the developer chooses the price plan options in the price plan wizard screens. During this development, a price plan generator, which is part of the price plan wizard, is connecting a number of primitives together according to the choices made in the price plan wizard. Either way, primitives are fundamental building blocks of the price plan.

Fig. 6A illustrates a flow chart of an implementation of graphical programming using primitives to develop a price plan. Similar to the price plan wizard described with respect to Figs. 5 A - 5C, it is first determined 605 whether there are any one time charges. If there are, the necessary primitives are added 610in the programming editor to reflect the one time charge. It is next determined 615 if there are any recurring charges. If there are recurring charges, primitives are added 620 to reflect these charges. It is next determined 625 if there are any use-based charges (as discussed above). Once again, if there are any use-based charges, primitives are added 630. If there is any free usage 635, the appropriate primitives are added 640. There may be a charge difference for on-peak and off-peak usage 645, and primitives are appropriately added 646 to reflect those differences in charges. Simple adding primitives and account management primitives are also added 647. Fig 6B illustrates air implementation of a price plan developed by interconnecting primitives using a price plan editor. As discussed above with respect to Fig. 4, the primitive programming environment is the graphical source code that the developer uses to ultimately create a plan object for execution by the rating engine 340. The example used in Fig. 6 is a simple price plan that consists of a $10 one-time set-up charge and a single monthly charge of $20 with monthly billing at $20/month. The plan includes 100 free connection hours. After 100 hours peak time (7PM- midnight), the plan bills at $l/hr. In addition, off-peak time (midnight - 7PM) is billed at $0.50/hr for the first additional 100 hours, then $0.25 thereafter.

Each primitive in the price plan is programmed with the necessary data as described. A OneTimeCharge primitive 655 is programmed to incur a set-up charge of $10 only the first time that the corresponding plan object code is executed, and includes software logic to prevent multiple recurrences of the one time charge. Thereafter, the OneTimeCharge primitive 655 does not execute. Running in parallel to the OneTimeCharge primitive 655 is a RecurringCharge primitive 660 that incurs the charge of $20 for every pass ig month. The RecurringCharge primitive 660 uses the data gathered by the collector 235 in order to obtain time stamp data 651 to determine when a time period of one month has occurred. A FreeStepRater 665 is a primitive programmed to "step up" the numbers of hours up to a specified number of hours. It is programmed with data 667 in order to cease stepping, in this example, at 100 hours. Two Daily TimeFilter primitives 670, 679 are used to allow the program data to flow one way or another. If the data is gathered during peak hours of 19 : 00 to 24:00, then the data is permitted to flow through the Daily TimeFilter 670. Data 671 is programmed into the Daily TimeFilter 670 to specify the time range that data is able to flow. During these peak hours data does not flow through the DailyTimeFilter 675 which is programmed with data 676 that only allows data flow during the hours of 00:00 and 18:59. A corresponding PeakStepRater primitive 680 is programmed to determine the cost of usage during the peak hours. As discussed above, the price plan in this example charges $1/ hr of peak time usage. Multiplier data 681 is programmed into the PeakStepRater primitive 680. These charges only apply after the 100 free hours have passed as set by FreeStepRater 665. Similarly, if the client 210 is accessing the network during off peak hours, a charge of $0.50/hr applies if 100 hours of off-peak time has not yet been attained, and a charge of $0.25/hr applies if the number of off-peak hours exceeding 100 has been attained. However, if at the FreeStepRater 665, it is determined that the number of hours has not exceed the initial 100 hours (whether peak or off peak), the usage data is caused to be blocked from the Daily TimeFilters 670, 675 and the StepRaters 680, 685 and no cost data flows directly to an adder 690 through these paths because the FreeStepRater 665 will have no output to trigger the succeeding primitives. The adder 690 is programmed to add all of the charge data that is available to-it. After the Adder 690 executes, the data flows to an Account Finalizer primitive 695 that transfers the data to the account management module 255 or the account database 370. The charge data at this time is $0 unless it is the first time the client 210 is using the account, and the one time charge is incurred from the OneTimeCharge primitive 655.

In the above-described graphical programming implementations, several primitives are used. Some primitives are executed in parallel when data is available to them. However, for many programming sequences, primitives can be required to run in series. The systems and techniques described are fault tolerant so that one primitive does not execute until it has the data it needs either from the collector or from the output of another primitive. This fault-tolerance prevents errors from occurring in a situation where a primitive tries to execute before it has its proper data. The systems and techniques described imply a proper execution sequence of the primitives to make sure that input data is available from the preceding primitive before the current primitive is executed. This can be accomplished by perfomiing a topological sort on the price plan graph treating the primitives as nodes and interconnections as directed edges. For example, in the price plan example described above with respect to Fig. 6B, the Adder primitive 690 will not execute until it has all of the data from the OneTimeCharge 655, RecurringCharge 660, PeakStepRater 680 and OffPeakStepRater 685 primitives. If there is no data available from those primitives, such as in the case where there is no longer a one time charge, an appropriate signal such as a "0" null data is sent from the primitive. In one embodiment, primitives are graphical icons used in data flow programming. In this embodiment, building a price plan creates source code for a graphical programming environment such as Visio®.

Fig. 6C is a screen shot of an implementation of a price plan builder using a Nisio® environment. In this implementation, the Nisio® environment is used to develop the graphical programming necessary to build the price plan. A series of primitives 697 are placed in an editing field 699 and connected with a series of data flow connectors 697a. Palette tools 696 are used to build the graphical program. Also shown in the screen shot is an informational field 698 that is used to provide information about a highlighted primitive.

Primitives can also be created for a variety of purposes such as monitoring the incoming data from the collector 235 to make sure that the client 210 is not using the network connection for any unauthorized purposes. For example, if the client 210 is paying only for time-based usage, then it is inappropriate to connect a server and use a disproportionate amount of bandwidth. An implementation of a primitive can check the amount of bandwidth a client 210 is using and compare it with the price plan.

In order to assure accuracy of the price plan and ultimate billing, the price plan wizard or a similar template can be used to test the price plan with known data. Price plan object code is then available in the price plan database 410 for execution. When retrieved for execution the developer can run the code in a run time diagnostic environment with known data with knowledge of charges the result. In this way, the developer can run diagnostic data to check the accuracy of the code before it is compiled to object code and used in an actual billing environment.

Fig. 7 A illustrates a flow chart of an implementation of diagnostic data process. The code stored in the price plan database 410 is retrieved 705. The developer then determines 710 if there are any modifications necessary in the code. In the first instance of retrieving the code, there are typically no modifications that are necessary and the developer has made the determination that the test code is to be tested 715. The developer can then use the testing run time environment to test the source code with known data by stepping 720 through the code. Thereafter, the developer can determine 710 once again if there are any modifications to be made. If there are modifications, then the developer makes those modifications. Typical modifications can be but are not limited to adding 730 a new processes (or primitives), modifying 735 existing processes (existing primitives can be modified but involve more complicated software programming) and modifying 740 the connections between processes (primitives). Typical modifications can be but are not limited to adding 730 a new process (or primitive), modifying 735 the property (or data) with existing processes and modifying 740 the connections between primitives. Once a price plan has been built and tested, it is stored in the rating database 410. In a typical embodiment, the price plan is stored as extensible markup language (XML). When a price plan is programmed and stored, it is subsequently retrieved and compiled into object code for execution by the rating engine 340. Fig. 7B illustrates a flow chart of an implementation of a price plan object builder. To compile the graphical source code, the XML price plan code is obtained 755 from the plan database 410. The XML code is parsed 760 to create an object representation of the code. At this time it is determined 765 if there are anymore processes that are to be in the plan. If more processes are desired in the plan, the developer can find and load 770 the primitives from the primitive database 420 and object representations of those primitives are created 775. Properties of the object primitives are established 780 such as by furnishing specific data (i.e., constants or multipliers are indicated in Table 1.) If there are no more rating processes to be added to the plan, then the compilation process establishes 790 the interconnections between the primitives. At this point, the fault tolerance discussed above is built into the code. He execution sequence of the rating primitives as discussed above is determined. Each primitive is programmed to "know" the data for which it has to wait before executing. The plan semantics are then validated 795, for example, any specific provisions in the plan. The object code is then delivered 796 to the rating engine 340 for execution. Fig. 8 illustrates a flow chart for an implementation of a rating engine 340 object code execution process. When the code is executed, the rating engine 340 is told to retrieve 805 a usage record. This record is the usage data gathered by the collector 235. The rating engine 340 then retrieves 810 usage record account information from the account management module 255 or the account database 370 in order to determine what plan is to be used. The rating engine 340 then retrieves 815 the plan ID for a record and date. The plan logistics may differ for different usage records and dates. The rating engine 340 determines 820 if the object code identified by the plan ID is available in a code cache for execution. If the object code is not available, then the proper primitive connections are established 850 (same as establishing 790 primitive interconnections in Fig. 7B). If the object code is not available, then the object code is constructed and delivered (Fig. 7B). Once the code is available, then the code is initialized 825 with the pertinent variables from the account information (i.e., rates, free-usage etc.) The usage record is then rated 830 appropriately based on the plan and the account variables are updated 835. The bill data is then output 840 to the bill details database 380. This process is repeated for all data records retrieved by the collector 235.

Bill Presentation

Referring again to Fig. 3, the bill presentation template 320 and the web bill presentment are typically embodied, respectively, in a web page delivered to the client's browser 330. In one embodiment, a bill presentation web page (not shown) is typically created and modified by using a HyperText Markup Language (HTML) editor. The HTML editor allows the service provider 230 and/or the client 210 to create a web page that best meets the needs in bill presentation. The service provider 230 provides elements that are important to the bill presentation process such as the separate charges incurred during the billing cycle. The client 210 can optionally add billing data and the order in which it is presented. For example, the client can present the incurred charges and the raw usage-data side by side to check on the accuracy of the charges. The client can also add the terms of the billing plan as a reminder of how charges are incurred. If the client 210 is signed up to use multiple billing plans, the charges for all the plans can be displayed side by side to provide a price comparison so that the client can ultimately choose the price plan of choice.

Fig. 9 is a flow chart of an implementation of a bill presentment process. When the client 210 makes a request to view billing information on the client browser 330, the service provider 230 sends 905 a web page, as an HTML file, to the client's browser 330. The client can, at anytime during the process, for example, make 935 modifications to the web page to customize the page to meet the client's 210 needs. The service provider 230 provides 910 the billing data from the billing details database 380. If there is a network connection, the service provider 230 can also provide 915 any real time data as the rating engine 340 produces it. The HTML file is then formatted 920 to display the data to the client 210. As the client 210 is viewing the web page, it is determined 925 whether or not there is more real data available. If there is more real time data, then it is provided 915 to the client's browser 330. The process is repeated as necessary. The information is all output 930 as an HTML file for viewing by the client 210.

Fig. 10 A is a screen shot of an implementation of a bill presentation template 1000. This template is used as a development tool for the actual bill presentation that the client 210 sees. The figure illustrates that the template 1000 is displayed on a typical web page 1005. The template 1000 contains various fields as described above. A field 1010 for a one time installation cost is first shown. This field will typically be present only the first time the template 1000 is displayed to the client 210. In this particular price plan, the client 210 is using a price plan that includes charges for web space used and email. Respective fields 1015, 1020 are displayed in the template 1000 to reflect these charges. Fields 1025, 1035 are displayed for on and off peak charges. Respective fields 1030, 1040 are displayed reflecting the number of hours connected for on and off peak. Further charges present in the billing plan are an FTP data transfer charge and a Voice over IP data charge. Respective fields 1045, 1055 reflect these charges, and fields 1050, 1060 reflect the amount of data transferred to incur those charges.

Fig. 10B illustrates a screen shot of an implementation of the bill presentation template 1000 after it has been filled with billing data. The template 1 100, as seen by the client 210, contains a field 1110 for the billing period, as well as a field 1120 displaying the total costs. The fields 1130 as discussed with respect to Fig. 10A are filled with the actual billing data. Several additional fields can be added to reflect other charges that are incurred using other price plans. Figs. 10A and 10B are used only as examples of the types of templates that can be used in both bill presentation development and an actual bill presentation. The techniques and apparatus discussed above have several business applications. In a typical application, as discussed above, price plans are developed by an ISP or NSP to meet the needs of different types of clients with different needs. In addition, the ISP or NSP will be able to achieve maximum charges from the clients commensurate with their use of the network. For example, if a client is attaching a server that uses a lot of bandwidth, the ISP or NSP is able to detect that used bandwidth and make an appropriate charge. In another embodiment, the customer accounts can be partitioned according to account numbers. For example, if there are one million customer accounts, 10 partitions can be created by assigning account numbers 1 to 100,000 to the first partition, 100,001 to 200,000 to the second partition and so forth. A rating engine is then assigned to each partition. The rating engine selects and rates usage records with the assigned account number range. Scalability is achieved by creating the proper number of partitions with corresponding rating engines and distributing the rating engines to multiple computers. By assigning account number ranges to rating engines instead of having rating engines to process arbitrary accounts, caching of account information is possible (since no other modifications are made to the same account) and thereby increase the overall usage record processing rate.

In another embodiment, more than one engine can be assigned to work on the same account partition. In such a case, each engine working on the same partition is assigned a unique priority. The rating engine with the highest priority is active processing usage records. Other engines are monitoring the status of the active engine. In the event that the monitoring engines detect inactivity of the primary engine, the next highest priority engines takes over processing the usage records. The active engine updates a record in the database with a current time stamp. IF the time stamp fails to be updates, the active engine is assumed to be non-functional. A monitoring engine initiates a take over procedure. When the failed engine recovers, it regains control from a lower priority engine and resumes processing of the usage records. No central controlling entity is involved in the fail other that the database. Each engine operates autonomously.

Various aspects of the techniques and apparatus may be implemented in digital circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus of the invention may be implemented in a computer products tangibly embodied in a machine-readable storage device for execution by a programmable processor. The foregoing techniques may be performed, for example, by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output. The methods may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one in/out device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from read-only memory and/or random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example, semiconductor devices, such as EPROM, EEPROM. and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by or incorporated in, specially designed application- specific integrated circuits (ASICS).

A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.

Claims (39)

What is claimed is:

1. A method of determining a billing-cycle price for network services, comprising: using a plurality of graphical elements on a display to establish a price plan for each of a plurality of clients, wherein the price plan sets a price per use unit; collecting use data from the plurality of clients; sorting the use data into data groups corresponding to each of the plurality of clients; and using the graphical elements to process the data groups to determine the billing-cycle price for each of the plurality of clients, wherein the billing-cycle price is calculated from use data and the price per use unit.

2. The method of claim 1 wherein the price per use unit is determined by time that each of the clients used the network services.

3. The method of claim 1 wherein the price per use unit is determined by network bandwidth that each of the clients used.

4. The method of claim 1 wherein the price per use unit is determined by network content that each of the clients used.

5. The method of claim 1 wherein the price per use unit is determined by email that each of the clients generated on the network.

6. The method of claim 1 wherein the price per use unit is determined by electronic storage space used by each of the clients.

7. The method of claim 1 wherein the price per use unit is determined by web space that each of the clients used.

8. The method of claim 1 wherein the price per use unit is determined by multimedia usage that each of the clients used.

9. The method of claim 1 wherein the price per use unit is determined by Internet protocol addresses in use by each of the clients.

10. The method of claim 1 further comprising: allowing each of the plurality of clients to choose a price plan that includes more than one price per use unit; calculating a billing-cycle price for each price per use unit; presenting each billing-cycle price to each of the clients; and allowing the client to choose the billing-cycle price that is the most cost efficient.

11. The method of claim 1 further comprising: comparing a cost associated with the plan to the billing cycle price; determining a profit of each of a plurality of price plans; and determining an action to increase the profit.

12. The method of claim 11 wherein the action is changing one or more of the plurality of clients to a new price plan.

13. The method of claim 11 wherein the action is eliminating one or more of the price plans.

14. The method of claim 1 further comprising: developing a new price plan; and using a set of old use-based data in the new price plan to determine an effect on profits.

15. The method of claim 1 further comprising: transmitting a bill presentation template to each of the clients.

16. The method of claim 15 wherein the bill presentation template is transmitted to a client web browser connected to the network.

17. The method of claim 16 wherein the bill presentation template displays charges incurred during the billing cycle.

18. A method of developing a price plan for services on a display, comprising: providing an interface on the display; providing on the interface images adapted to receive price plan criteria; and receiving in the images price plan criteria.

19. The method of claim 18 wherein images on the interface are graphical user interface (GUI) screens.

20. The method of claim 19 wherein providing the images comprises presenting the GUI screens in an order to present price plan criteria input options for generating the price plan to the user.

21. The method of claim 20 further comprising: generating the price plan into source code; compiling the computer code into machine-readable code.

22. The method of claim 21 further comprising: supplying the price plan data to at least one of the source code and the machine-readable code to calculate a charge for the services.

23. The method of claim 18 wherein the images on the interface are graphical elements representing components of the price plan.

24. The method of claim 23 wherein providing the images comprises: arranging the graphical elements on the display that graphically represents the calculations for the price plan charge; and providing interconnections among the graphical elements to provide price plan data flow paths .

25. The method of claim 24 further comprising: storing the arrangement of graphical elements as source code; and compiling the source code into machine-readable code.

26. The method of claim 25 further comprising: supplying the price plan data to at least one of the source code and the machine-readable code to calculate a charge for the services.

27. A method of billing for services, comprising: graphically determining a price plan that charges a client for services based on use; keeping a record of data of the client's use of the services; determining a charge for the services based on the price plan and the record of the client's use of services; and presenting a bill for the services.

28. The method of claim 27 wherein determining the price plan comprises: establishing the type of use for which the client desires to be billed; establishing a unit of cost for the type of use; and generating a customized price plan template that reflects the type of use and the unit of cost and is adapted to receive the record of data.

29. The method of claim 28 wherein determining the charge for the services, comprises using the customized price plan template to calculate the service charge by processing the record of data based on the type of use and the unit of cost.

30. The method of claim 28 wherein presenting the bill for services comprises: generating a bill presentment template adapted to present the record of data, the type of use, the unit of cost, and the service charge; and presenting the bill presentment template to the client.

31. A price plan network system, comprising: at least one data collector adapted to collected client data from the network; a database coupled to the data collector; a price plan builder coupled to the database, the price plan builder having: a user interface; a first software module having a price plan template adapted to direct a user through a series of steps to develop a price plan; a second software module coupled to the first software module, the second module including a plurality of components adapted to be interconnected to build a price plan source code; an object builder adapted to compile the source code into machine readable code; and a bill presentation module coupled to the database.

32. The system of claim 31 further comprising a rater coupled to the database, adapted to be controlled by the machine-readable code to process the client data into billing data.

33. The system of claim 32 further comprising at least one additional rater, wherein the rater and the at least one additional rater are adapted to operate autonomously of each other, and further adapted to monitor each other for failure, and to operate in the event that one of the rater and the at least one additional rater fail to operate.

34. The system of claim 32 wherein the bill presentation template comprises a user interface adapted to display the client data and the billing data.

35. A price plan development and presentation system comprising: means for building a price plan based on a client's use of services; means for collecting raw use-based client data; means for processing the use-based client data using the price plan; and means for presenting the raw and processed use-based client data to the client.

36. A network service provider method of charging a client for connecting the client to the network comprising: developing a price plan agreement between the service provider and client, the agreement stating that the service provider provides a connection to the network in exchange for compensation from the client, the compensation being calculated based on the client's use of the network; providing to the client a connection to the network; collecting use-based data from the network; processing the use-based data based on the price plan; and presenting the charges to the client.

37. A method of creating a price plan in a graphical program on a computer having a memory, a display, a user input and a processor, comprising: storing in memory a plurality of executable functions representing aspects of the price plan; assembling a data flow diagram on the display in response to user input to specify the price plan, the data flow diagram including function icons corresponding to the respective ones of the executable functions; and generating an executable program from the data flow diagram.

38. The method of claim 37, further comprising: receiving price plan data in the executable program; processing the price plan data to calculate charge output data.

39. The method of claim 38 further comprising: creating a bill presentation template on a web page; and providing the charge output data to the bill presentation template.