JP2003533781A - Plan prices based on usage - Google Patents

Abstract

Summary An apparatus and method (100, 200, 300) for use-based pricing are disclosed. A pricing plan (310) for the service is established (235) according to how the service is used. Fees are calculated according to a pricing plan (310) that applies to actual use (340). The devices (100, 200, 300) are used by network service providers (NSPs) (130, 230) and Internet service providers (ISPs) (130, 230) to allow customers (110, 210) (130, 230) or how to use the network connection provided by the ISP (130, 230), and to what extent.

Description

Detailed Description of the Invention

The present invention relates to networks and network usage, and more particularly to network pricing plans.

Background Service providers are constantly competing with each other to find new ways to attract customers. An increasing number of service providers have entered the ever-growing world of e-commerce, which demands high quality service and fast turnaround time (the time from investing to receiving a profit). e-commerce service
Providers are taking direct online services, such as network access from Internet Service Providers (ISPs) and Network Service Providers (NSPs), and traditional services, such as e-commerce auctions, to further services. Provide a wide range of services that involve doing.
For example, many online auction services use e-commerce, where sellers sell their products for auction, and large numbers of buyers join the bidding competition that leads to the final purchase between the highest bidder and the seller. Help things. All of these services found online involve some kind of usage, either the time spent online or the bandwidth used during online time. Specifically, ISPs and NSPs may be online 24 hours a day, 7 days a week, from a personal web surfer who may be online for several hours at a time, consuming a large amount of bandwidth. Provide network access to users up to the large enterprises they need.

Customers, whether individual surfers or large corporations, try to find the best possible deal in order to minimize the cost of being online. ISP
And NSPs typically provide customers with pricing plans that include a per-hour charge, whether for an hourly or unlimited monthly charge. Furthermore,
Many ISPs and NSPs have "acceptable use" for the use of their services.
Have conditions. For example, customers cannot send "spam" emails via links provided by ISPs or NSPs. Another condition is
The customer may not connect the server to the link, as the server may use an unacceptable amount of bandwidth. However, ISPs and NSPs usually do not have what is needed to monitor violations of these conditions. Furthermore, ISP
The escalation of competition will drive ISP's marketing departments to catch up with rapid changes in their ISP payment plans to meet market demand.

Overview In general, the invention features a method and apparatus for representing a pricing plan for online services, particularly Internet and network services.

In one aspect, the invention is a method of determining a billing cycle price for a network service, including the step of establishing a price plan for each of a plurality of clients, the price plan being a price per usage unit. And collecting usage data from multiple clients, sorting the usage data into a data group corresponding to each of the multiple clients, and a billing cycle for each of the multiple clients. Processing the data group to determine a price, the billing cycle price is calculated from the usage data and the price of the usage unit.

[0006] In one embodiment, the price per unit of use is such that the amount of time each client uses the network service, the network bandwidth used by each client, the network content used by each client, and each client E-mail generated on the network, electronic storage space used by each client, web space used by each client, multimedia use used by each client, or internet protocol used by each client -Determined by address.

In another embodiment, the method further enables each of the plurality of clients to select a price plan that includes a plurality of usage unit prices, and a billing cycle for each usage unit price. Calculate the price, present each billing cycle price to each of the clients, allow the client to choose the most cost effective billing cycle price, and send the billing template to each of the clients And a bill presentation template is sent to the client web browser connected to the network to display the charge presentation imposed during the billing cycle.

In another aspect, the invention is a method of developing a price plan for a service on a display, providing an interface on the display and an image adapted to receive a price plan criterion. Features a method that includes providing on an interface and receiving a price plan criterion in an image.

In one embodiment, the image on the interface is a graphical user interface (GUI) screen. In another embodiment, providing the image includes presenting a GUI screen to present the user with price plan based input options for generating the price plan.

In another embodiment, the method further provides the steps of generating a price plan into source code and compiling the computer code into computer readable code.

In another embodiment, a method provides the step of providing price plan data to at least one of a source code and a computer readable code to calculate a charge for a service.

In yet another embodiment, the image on the interface is a graphical element representing a component of a price plan and the step of presenting the image places the graphical element on a display that graphically represents the calculation of the price plan fee. And providing interconnections between the graphical elements to provide a price plan data flow path.

In another alternative embodiment, the method further comprises storing the placement of the graphical element as source code, compiling the source code into computer readable code, and calculating a fee for the service. To provide price plan data to at least one of the source code and the computer readable code.

In another aspect, the invention is a method of billing for a service, the method comprising determining a price plan for billing a client for the service based on the use, the method comprising: A method comprising retaining records, determining a fee for the service based on the price plan and a record of the use of the service by the client, and presenting a bill for the service.

In one embodiment, the step of determining a price plan comprises establishing a type of use for which a client wishes to be charged, establishing a unit of cost for the type of use, the type of use and Generating a customized price plan template reflecting the unit of cost and adapted to receive a record of data.

In another embodiment, a customized price plan template for the step of determining a fee for a service to calculate a service fee by processing a record of data based on a type of usage and a unit of cost. Generating an invoice presentation template adapted to present a record of data, a type of use, a unit of cost, and a service charge, the step of presenting an invoice for a service comprising: Presenting the bill presentation template to the client.

In yet another aspect, the invention features a price plan network system, wherein the price plan network system includes at least one data collector () adapted to collect client data from the network. Collecting means), a database coupled to the data collector, a price plan builder (construction means) coupled to the database, the price plan builder having a user interface, and for developing the price plan. A first software module having a price plan template adapted to direct a user via a series of steps; a second software module coupled to the first software module; and a second module Create plan source code A plurality of components adapted to be interconnected for the purpose of: an object builder adapted to compile the source code into computer readable code; and a billing presentation module coupled to a database. Including.

In one embodiment, the system is further coupled to a database, the client
It includes a rater adapted to be controlled by the computer readable code for processing the data into billing data.

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

In yet another aspect, the invention is a price plan development and presentation system comprising:
This system provides a means to create price plans based on client service usage, a means to collect raw usage-based client data, and a means to process usage-based client data using price plans. And means for presenting raw use-processed client data and processed use-based client data to the client.

In another aspect, the invention is a network service provider method for billing a client for connecting the client to a network, the method comprising:
The method includes the step of developing a price plan contract between a service provider and a client, which contract states that the service provider provides connectivity to the network at the expense of the client and in exchange. Yes, the price is calculated based on the client's network usage, and
Providing a connection to the network to the client, collecting usage-based data from the network, processing the usage-based data based on a price plan, and presenting a fee to the client. Is characterized by.

In another aspect, the invention is a method of creating a price plan in a graphical program on a computer having a memory, a display, user inputs, and a processor, the method comprising aspects of the price plan. Storing in memory a plurality of executable functions that represent, and assembling a data flow diagram on a display in response to user input specifying a price plan; It is characterized by including functional icons corresponding to the respective ones, and generating an executable program from the data flow diagram.

In one embodiment, the method further comprises receiving price plan data within the executable program, processing the price plan data to calculate charge output data, and billing on a web page. The method includes the steps of creating a book presentation template and providing fee 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.

[0025]   Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION FIG. 1 shows a network access system 100. Multiple 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, is a device 1 such as a telephone modem or cable modem.
Network access may be provided through a series of connections 150 linking 10 to a network 120. The device 110 may desire to search the network 120 for information or gain access to any of a variety of servers 140. The service provider 130 typically charges a fee for linking the device 110 to the network 120. Accordingly, the service provider 130 also collects data related to billing the device 110 for connection to the network 120.

FIG. 2 shows an embodiment of the billing system 200. A client 210 may want access to a network 220 such as the Internet. The client 210 can get this connection via the service provider 230. Virtual private network (virtual private network), if necessary
The (VPN) module 245 is used to provide a private connection between the client 210 and the network 230. Client 210 is typically
Sign up (register) with the service provider 230 via the registration / provisioning (prescription) engine 240. Services using the registration engine
The provider 230 can ask the client 210 for relevant information about the client, such as how to pay for the service and the price plan that the client 210 wants to use. The client 210 can have a predetermined price plan that determines how the client 210 is billed for connecting to the network 220. In a typical embodiment, the price plan is usage-based. Usage-based pricing plans are described in detail below. A collector 235 is used to collect usage-based data. The collector 235 collects usage-based data, such as time stamps for time-based usage, bandwidth used for bandwidth-based usage, number of emails for email-based usage, and size of emails. Adapted to collect either. Time stamps are typically collected for all types of data so that when charged for use, price per unit can be determined by time. For example, different price units can be applied to bandwidth usage depending on the time of day. In other embodiments, the collector is adapted to collect data according to the usage-based plan selected by the client 210. The collector 235 is also used to manage the addresses of multiple clients connected to the service provider 230, as well as to provide application switches to individual clients. In one embodiment, the collector manages real-time switching between clients using Radius software to ensure that the correct usage-based data is billed to the correct client. In another embodiment, RMON2 software is used. The primary function of the collector 235 is to collect usage data from various usage information sources such as RADIUS and RMON2 devices and turn it into accounts (bills).
The usage information source is not part of collector 235. Collector 235 typically has no other functionality, such as administrative client addresses, application switches or the like.

Still referring to FIG. 2, a biller (billing means) / rater (charging means) 25
0 is used to calculate the charge charged while the client 210 is connected to the network 220. The biller / lator 250 is also used to present the bill to the client 210 after the billing cycle. Biller / Later 2
The 50 billing and rating functions are described in detail below. The biller / lator 250 is used in close association with the collector 235. Once the data is collected, the management software is used to
Appropriate billing fee to biller / rater 2 to calculate the correct fee charged to
Instruct 50. The fee charged to a client 210 depends on the price plan the client has subscribed to. Account management module 255 is used to manage usage-based data collected from clients 210 via collectors 235. The lator 250 ensures that the client 210 is only charged for the network usage to which the client 210 is charged, not other clients. The account management module 255 works closely with the collector 235 and the billers / laters to store and manage the charges charged. A market intelligence module 260 monitors and processes usage of clients 210 and also monitors and processes client usage from other service providers on network 220 to determine price plans and new marketing strategies. To do. Payment / Finance module 265, Client 2
Used to track payments made by 10 and other related financial matters. The database 270 includes information on the clients 210 and services.
Used to store pricing plans offered by provider 230 and various other service provider related information.

The use of the client 210 can be based only on time, such as hourly or monthly fees, and can also be used for bandwidth, content, email,
Storage Web Space, Active Internet Protocol (IP)
It may be based on other usage-related bases such as addresses, downloaded movies, or downloaded music and the like. For example, the client can be a server that receives a lot of traffic on a daily work basis. The service provider 230, in this situation, may want to charge a server-client with a large amount of traffic by bandwidth. In another example, the client 210 may be billed based solely on the number of emails sent between the client 210 and the network 220. A client can have a predetermined plan outlining how the client is billed for network usage. Charges typically include time, bandwidth, content, email, electronic storage (storage), used web space, multimedia usage such as video and audio downloads, and IP address in use It is charged by use, but the use included is not limited to these. For example, the client may choose a plan that charges the client for the time spent on the network. Under a time-based plan, clients may be billed by either hours or minutes, or once per week or month with unlimited minutes or hours. If the client is running a server on the network, the client may choose a plan to bill the client for the bandwidth used, regardless of the time spent on the network. In another plan, clients can be billed by the number of emails generated, whether sent or received. An email-based plan may also include a clause that at most emails sent and received must be of a certain size, or else additional charges will be levied. For example, each email can be limited to 3 megabytes, and more than 3 megabytes 1
For each megabyte, an additional fee is charged to take into account the additional bandwidth used for email. In yet another plan, clients can download movie and sound files from a website at a specific price for each movie and sound file. In one embodiment, the client may select an all-inclusive plan that includes more than one of the above plans. One goal of all inclusive plans is to track the fees for each of the plans included in all inclusive plans. At the end of the billing cycle, the client may be presented with a template containing each fee for each plan. afterwards,
The client may choose to pay for the cheapest plan. In this way, the client can use multiple plans on a trial basis to determine which plan best suits the client. In an all-inclusive plan embodiment, clients are charged an additional cost each billing cycle for being able to make decisions in multiple plans. After multiple billing cycles, the client may decide to exit the all-inclusive plan and leave only one plan. For example, if the NSP offers multiple usage-based plans such as time, bandwidth, email, and web space, the client may track each plan's charges under the overall inclusion plan. Can be selected.
At the end of the billing cycle, the client is presented with an invoice showing charges for each of the time used, bandwidth, email, and web space. The client may, for example, determine that the time-based fee is the cheapest and may choose to pay only the time-based fee. Clients are also charged an additional cost to have the ability to choose from among those plans. afterwards,
Client 210 may choose to be billed only under a time-based plan.

The billing and rating functions described above are interrelated with each other and include both service provider 230 and client 210 interactions. Figure 3
7 is a processing flowchart showing an embodiment of the operation of the biller / later 250. The service provider 230 has the ability to graphically define price plans using a set of software "primitives" that are connected together in a graphical programming environment such as Visio (R). The primitives and their functionality are described in detail below. A graphical price plan 310 is created by the service provider 230. Client 210 is network 220
Client browser 330 is used to sign on (log on) to perform network functions such as web surfing through service provider 230. The client browser 330 is also used to initially select a price plan and to have the client 210 present a billing charge at the end of the billing cycle. At approximately the same time as the price plan is defined using the graphical price plan 310, a bill presentation (display) template 320 is also defined. The bill presentation template 320 is typically determined by the price plan selected by the client 210. However, the bill presentation template can be modified to meet the needs of the client 210 and the service provider 230. When a charge is incurred, the collector 235 collects and transfers the charge data to the data repository 360. Fee data is transferred to the rating engine 340 and web billing presentation. Rating engine 3
40 is coupled to a graphical price plan 310. The rating engine 340 processes price data using price plan primitives from a graphical display. Depending on the price plan selected by client 210, the data collected by the collector may differ from another client. For example, if the client 210 selects a time-based price plan, the rating engine typically obtains time stamp information from the collected charge data. If the client's price plan is based on bandwidth usage, the rating engine 340 may use the client 2 during the network session.
Get data indicating the number of bytes used by 10. If the client's price plan is based on the number and size of emails sent to and received from the network, the rating engine 340 will process email data only.

The data repository 360 is also coupled to the web bill presentation 350 so that the client can see the “raw use” before it is processed by the rating engine 340. The web bill presentation 350 is a web interface with the client browser 330 for viewing bills. The rating engine 340 stores processed usage data in the account database 370.
Also coupled to web bill presentation 350. The account database 370 stores billing related information for all clients, such as the selected price plan. Rating engine 340 is also coupled to bill detail database 380, which stores all of the processed data. Accordingly, the client 210 can display the raw usage data and compare it to the processed usage data. If the client 210 has selected multiple price plans or all price plans as described above, the client will see all raw data and all processed data in the web invoice presentation 350. You can The bill presentation 350 allows the client 210 to determine which pricing plan works best for the client's needs.

Billing and Rating Graphical price plan 310 is a collection of components that service provider 230 uses to create a price plan for client 210. FIG. 4 shows a processing flowchart of the embodiment of the graphical price plan. In this embodiment, the collection of components that make up the graphical price plan is rating plan database 410, rating primitive database 420, plan object builder 430, and plan object database 440. Rating primitive database 420 is a storage medium for primitives, which are software components used to create price plans. Primitives are programmed to provide specific functionality. Primitives can be programmed for virtually all of the functionality needed for a price plan. A description of the primitives and their functionality follows. The rating plan database 410 contains
A graphical program made up of a series of interconnected primitives from the rating primitive database 420 is included. Rating plans can be viewed as graphical source code. Plan Object Builder 430 is a graphical source code compiler. Graphical source code is compiled and object
It is stored as a file in the plan object database 440. The rating engine 340 may access the plan object corresponding to the plan selected by the client 210 from the plan object database 440. The rating engine 440 executes the plan object code and processes the raw data from the collector 235.

Although primitives are the basic building blocks of price plans, price plan construction has multiple levels of complexity. Non-technical people such as marketing managers and salesmen need high-level editors that allow them to quickly develop price plans without requiring a high level of technical knowledge. 5A-5C show screen shots of an embodiment of the price plan wizard. FIG. 5A is a screenshot 500 of an embodiment of a pricing plan wizard introductory screen. This screen shot displays a textual instruction 505 that guides the developer through the price plan construction process. FIG. 5B shows a screenshot 510 of an embodiment of a screen that allows a price plan developer to select which type of fee 515 to charge within the price plan. As you can see from the figure,
A simple fixed fee 515a, such as a monthly fee, can be implemented in the price plan. It is also possible to charge a recurring (recurring) fee 515b such as a fee for each minute. A usage-based fee 515c can also be charged. Usage-based charge 515c is a charge for usage such as bandwidth, email, and other uses described above. FIG. 5C shows a screenshot of an embodiment of the fixed charges screen 520. Using this screen, the price plan developer can charge a one-time fee to the client 210 for set-up fees or other types of one-time fees. The Price Plan Wizard allows developers to quickly customize their customers' price plans without cumbersome programming.

FIG. 5D shows a flowchart 530 of an exemplary embodiment of price plan development using the price plan wizard. When the Price Plan Wizard starts,
First, it is determined 535 whether there is a one-time fee. If so, the developer supplies 540 one-time fee details, ie, costs and terms. The next question is whether there are recurring 545 charges. If there are recurring charges, the developer provides 550 the amount and frequency of the recurring charges. Recurring charges are typically minute, hour, or monthly unit charges. The next question 555 is whether there are usage-based charges. But,
In one embodiment, there may be recurring monthly charges, as well as additional charges for bandwidth used, emails generated and received, or other usage-based charges mentioned above. . If there is a usage-based fee, the developer provides 560 a description and amount of the usage-based fee. A typical plan may have some free usage. Therefore, asking 565 if there is free usage. If there is a free usage, the developer will provide the free usage details 57
0. In one embodiment, the free usage may be a length of free connection time. In another embodiment, free usage may be usage-based (eg, bandwidth, email, etc.). Another typical question 575 is whether there is a fee associated with the peak. If there is a peak related fee, the developer provides 580 details of the peak related fee.

The Price Plan Wizard then finishes the question and the set of primitives are connected and compiled without any intervention from the developer. The price plan object code is then available in the price plan database 410 for execution. Price plan graphical source code is typically stored as XML code.

The High Level Price Plan Wizard is a very important tool for non-technical persons of the service provider 230, but directly connects the primitives that can provide further extensibility of price plan development. It lacks more flexibility.

As mentioned above, in one embodiment, a graphical interface such as Visio® is used.
A programming program is used to create a price plan by interconnecting a number of primitives as a flow. In such an embodiment, service provider personnel can use this price plan editor to create price plans quickly and efficiently. For example, the marketing manager of an ISP company opens a price plan wizard or lets one of the programmers use the price plan editor to connect a set of primitives that match the price plan offered by the competitor. This allows you to react quickly to changes made by your competitors in your price plans. As another example, if an ISP salesman is discussing a transaction with a large company, the salesman can use the price plan wizard to change price plans quickly and efficiently. If a large company doesn't like any of the price plans that a salesman can create using the Price Plan Wizard, the salesman can contact an engineer or programmer to use a primitive editor to get a better price. Can create a plan. The programmer may attempt to use an existing primitive from the rating primitive database 420, an existing primitive in the rating primitive database 420. If the existing primitives are insufficient, the salesman can communicate the company's wishes and needs, and the programmer can write new primitives that meet the company's needs. The flexibility and extensibility of primitive programming allows salesmen, marketing managers, and programmers to work independently or in association to meet their marketing and sales needs in a competitive environment. In one embodiment, the primitive programming language is
It can be an open platform language such as Java (R), C, C ++, and Visual Basic (R).

Much has been said about primitives. The primitives and their functionality will now be described. The table below provides a subset of categories of primitives that can be used in any of the embodiments and a short description of the function of each primitive.

[0039]

[Table 1]

Primitives can be programmed directly in the primitive programming environment, which typically involves the addition of primitives and the interconnection of primitives using typical data flow programming. If no primitive meets the needs of a particular price plan, the programmer may
New primitives can be created by conventional programming methods such as (R), C, C ++, and Visual Basic (R).

Primitives are also connected while using the Price Plan Wizard.
As mentioned above, using the Price Plan Wizard, the developer selects price plan options within the screen of the Price Plan Wizard. During this development, the Price Plan Generator, which is part of the Price Plan Wizard,
Connecting multiple primitives together according to the selections made in the wizard. In both forms, primitives are the building blocks that underlie price plans.

FIG. 6A shows a flowchart of an embodiment of graphical programming for developing a price plan using primitives. Similar to the price plan wizard described with respect to FIGS. 5A-5C, first determine 605 if there is a one-time charge. In some cases, add 610 the required primitives in the programming editor to reflect the one-time charge. Next, it is determined 615 whether there are recurring charges. If there are recurring charges, add 620 primitives to reflect these charges. next,
Determine 625 if there are usage-based charges (described above). Again, if there is a usage-based fee, add 630 the primitive. If there is free usage 635, add 640 the appropriate primitives. There may be a difference in charges between on-peak (peak time) use and off-peak (non-peak time) use 6
45, primitives are added appropriately to reflect these differences in fees 6
46. Simple add and account management primitives are also added 647.

FIG. 6B shows an embodiment of a price plan developed by interconnecting primitives using the price plan editor. As described above with respect to FIG. 4, the primitive programming environment is graphical source code used by a developer to ultimately create plan objects for execution by the rating engine 340. The example used in FIG. 6 is a simple pricing plan consisting of a one-time setup fee of $ 10 and a monthly fee of $ 20 with a monthly bill of $ 20 / month. The plan includes 100 hours of free connection time. After 100 hours of peak hours (7pm to midnight),
This plan charges $ 1 per hour. In addition, off-peak hours (midnight to 7 pm) are $ 0.50 / for the first 100 additional hours.
You will be billed for the hour and thereafter for $ 0.25 / hr.

Each primitive in the price plan is programmed with the required data, as described. The OneTimeCharge primitive 655 causes the corresponding plan object code to execute only the first time.
It includes software logic that is programmed to charge a $ 10 setup fee and prevents the one-time fee from being charged multiple times. After that, the OneTimeCharge primitive 655 is not executed. O
Running in parallel with the neTimeCharge primitive 655 is the Recurring Charge primitive 660, which charges a $ 20 fee each month. The RecurringCharge primitive 660 uses the data collected by the collector 235 to obtain the time stamp data 651 to determine when the one month period has elapsed. FreeStepRater 665 is a primitive programmed to "step up" the number of hours up to a specified number of hours. It is programmed with data 667 to cause the escalation to stop at 100 hours in this example. Two D
The ailyTimeFilter primitives 670 and 679 are used to allow program data to flow to one or the other. If the data is collected during peak hours from 19:00 to 24:00, the data is allowed to flow through the DailyTimeFilter 670. Data 671 is programmed into the DailyTimeFilter 670 to specify the time range in which the data can flow.
During these peak hours, no data flows through the DailyTimeFilter 675. The DailyTimeFilter 675 is programmed with data 676 which allows data flow only during the hours 00:00 to 18:59. The corresponding PeakStepRater 680 is programmed to determine the cost of use during peak hours. As mentioned above, this example price plan charges $ 1 per hour of peak hour use. Multiplier data 681 is PeakStepRatter
It is programmed into primitive 680. These charges are FreeStepR
Only applicable after the 100 hour free time set by ater665 has elapsed. Similarly, if the client 210 is accessing the network during off-peak hours, a charge of $ 0.50 / hour will be applied if the 100-hour off-peak hours have not yet been reached, and If the length of time exceeds 100 hours, a fee of $ 0.25 / hour will be applied. However, if FreeStepRater 665 determines that the number of hours does not exceed the first 100 hours (peak or off-peak), the usage data is Dai
The cost data will not flow directly to the adder 690 via these paths, as it will be blocked from the lyTimeFilters 670 and 675 and the StepRaters 680 and 685. Because FreeStepRater 665 is
This is because it has no output that triggers subsequent primitives. The adder 690 is
It is programmed to add all of the available tariff data. Ad
After the execution of der (adder) 690, the data is the AccountFinali.
flow to zer (account final approval means) primitive 695, and
The Finalizer primitive 695 transfers the data to the account management module 255 or the account database 370. The fee data at this time is $ 0 unless the client 210 first uses the account, and the one-time fee is charged from the OneTimeCharge primitive 655.

In the graphical programming embodiment described above, multiple primitives are used. Some primitives execute in parallel when data is available. However, in many programming sequences, primitives may need to be executed serially. The systems and techniques described herein are fault tolerant, so that one primitive is not executed until it gets the required data from either the collector or the output of another primitive. This fault tolerance prevents the occurrence of errors in the context of attempting execution before the primitive has the correct data. The systems and techniques described herein imply the correct execution sequence of primitives to ensure that the input data is available from the previous primitive before it is executed. This can be accomplished by performing a topological sort on the price plan graph that treats the primitives as nodes and the interconnections as directed edges. For example, in FIG. 6 above.
In the example price plan described for B, the Adder primitive 690 is O
neTimeCharge Primitive 655, RecurringCharg
It does not execute until it has all of the data from the ePrimitive 660, PeakStepRater primitive 680, and OffPeakStepRater primitive 685. For example, if the one-time fee no longer exists,
If no data is available from these primitives, an appropriate signal is sent from the primitive, such as "0" null data. In one embodiment, the primitives are graphical icons used for data flow programming. In this embodiment, creating the price plan creates the source code for a graphical programming environment such as Visio (R).

FIG. 6C is a screen shot of an embodiment of the Price Plan Builder using the Visio® environment. In this embodiment, the Visio® environment is used to develop the graphical programming required to create a price plan. A series of primitives 697 are placed in edit field 699 and connected by a series of data flow connectors 697a. Palette tools 696 are used to create the graphical program. Also shown in this screen shot is an information field 698 used to provide information about the highlighted primitive.

Primitives should be created for various purposes, such as to monitor data coming in from collector 235 to ensure that client 210 is not using network communication for unauthorized purposes. You can also For example, if the client 210 is paying only for time-based usage, connecting a server to use an unbalanced amount of bandwidth is inappropriate. The primitive embodiment allows the amount of bandwidth the client 210 is using to be examined and compared to a price plan.

To ensure the accuracy of the price plan and final billing, the price plan wizard or similar template can be used to test the price plan with known data. The price plan object code is then available in the price plan database 410 for execution. Once retrieved for execution, the developer can execute the code in a run-time diagnostic environment with known data and knowledge of the resulting fees. In this way, the developer can execute diagnostic data to check the correctness of the code before it is compiled into object code and used in the actual billing environment.

FIG. 7A shows a flowchart of an embodiment of the diagnostic data process. The code stored in the price plan database 410 is retrieved 705. The developer then determines 710 if there are any required changes in the code. The first time the code is retrieved, there are typically no changes required and the developer determines 715 that the test code has been tested. The developer can then use the test run-time environment to test the source code with known data by incrementally executing 720 the code. The developer then again determines 710 if changes are to be made. If there is a change, the developer
Make that change. Typical changes include adding a new process (or primitive) 730, modifying an existing process 735 (existing primitives can be modified, but this involves complex software programming), and processes (primitives). Connection changes 740 between), but is not limited to these. Typical changes may include, but are not limited to, adding a new process (or primitive) 730, changing properties (or data) 735 for an existing process, and changing connections 740 between primitives. .

Once the price plan is created and tested, the rating database 41
Stored at 0. In an exemplary embodiment, price plans are stored in Extensible Markup Language (XML). The price plan, when programmed and stored, is then retrieved and compiled into object code for execution by the rating engine 340. FIG. 7B shows a flowchart of an embodiment of the Price Plan Object Builder. In order to compile the graphical source code, the XML price plan code is stored in the price plan database 4
755 won from 10. Parse the XML code 760 to create an object representation of the code. At this time, determine 765 if there are other processes that must be included in the plan. If more processes are desired for the plan, the developer finds and loads the primitive from the primitive database 420.
70, it is possible to create 775 an object representation of these primitives. Establish the properties of the object primitive 780, such as by supplying specific data (ie, constants or multipliers shown in Table 1).
If there are no more rating processes to add to the plan, the compilation process establishes 790 the interconnections between the primitives. At this point, the fault tolerance described above is built into the code. The rating mentioned above
Determine the execution sequence of the primitive. Each primitive is programmed to "know" what data it must wait before executing. It then verifies 795 the semantics of the plan, such as specific clauses in the plan. The object code is then sent 796 to the rating engine 340 for execution.

FIG. 8 shows a flowchart of an embodiment of the rating engine 340 object code execution process. When the code is executed, the rating engine 340 is instructed 805 to retrieve the usage record. This record is the usage data collected 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 to determine the plan used. Rating engine 340 then retrieves 815 the plan ID for the record and date. Plan logistics may differ for different usage records and dates. The rating engine 340 determines 820 whether the object code identified by the plan ID is available in the code cache for execution.
. If the object code is not available, establish the proper primitive connection 850 (same as establish primitive interconnect 790 of Figure 7B). If the object code is not available, construct and send the object code (see FIG. 7).
B). Once the code is available, it is initialized 825 with the relevant variables (ie, rate, free use, etc.) from the account information. Next, the usage records are appropriately rated 830 based on the plan, and the account variables are updated 835. Thereafter, the bill data is output 840 to the bill detail database 380 840. This process is repeated for all the data records retrieved by collector 235.

Bill Display Referring again to FIG. 3, the bill presentation template 320 and the web bill presentation are each typically implemented within a web page that is sent to the browser 330 of the client. In one embodiment, the bill presentation web page (not shown) is typically created and modified using a Hypertext Markup Language (HTML) editor. The HTML editor allows the service provider 230 and / or the client 210 to create web pages that best meet the billing needs. Service provider 2
30 provides important elements to the bill display process, such as individual charges charged during the billing cycle. The client 210 can optionally add bill data and the order in which it is displayed. For example, the client
The charges to be levied and the raw usage data can be displayed side by side to check the accuracy of the charges. Clients can take notes as to how fees are charged,
You can also add billing plan conditions. If the client 210 has signed up to use multiple billing plans, the charges for all plans will be displayed side-by-side so that prices can be compared so that the client can choose the final price plan to finalize. You can choose to.

FIG. 9 is a flowchart of an embodiment of a bill display (presentation) process. When the client 210 makes a request to view billing information on the client browser 330, the service provider 230 sends an HTM to the client browser 330.
Send 905 the web page as an L file. The client may make changes 935 to the web page at any time during the process, for example to customize the page to meet the needs of the client 210.
The service provider 230 provides 910 the billing data from the bill details database 380. If there is a network connection, the service provider 230
May also provide 915 any of the real time data when the rating engine 340 generates the real time data. Next, the HTML file is formatted 920 and the data is displayed on the client 210. When the client 210 is viewing the web page, it determines 925 whether additional real time data is available. More real
If there is time data, it is provided 915 to the client browser 330. This process is repeated as needed. All information is output 930 as an HTML file for viewing by client 210.

FIG. 10A is a screen shot of an embodiment 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 shows that the template 1000 is displayed on a typical web page 1005. Template 10
00 includes the various fields described above. The field 1010 for the one-time installation cost is shown first. This field is typically only present when the template 1000 is first displayed on the client 210. In this particular pricing plan, the client 210 is using a pricing plan that includes charges for the web space used and email. Respective fields 1015 and 1020 are displayed on template 1000 to reflect these charges. Field 1025 and 103
5 is displayed for on-peak charges and off-peak charges. Respective fields 1030 and 1040 are displayed reflecting the number of hours connected to on-peak and off-peak. Additional charges present in this billing plan are FTP data transfer charges and Voice over IP (Voice over IP) data charges. Respective fields 1045 and 1055 reflect these charges and fields 1050 and 1060 reflect the amount of transferred data that is charged these charges.

FIG. 10B shows a bill presentation template 1000 after billing data has been written.
3 shows a screen shot of an embodiment of the. The template 1100 seen by the client 210 includes a billing period field 1110 as well as a field 1120 displaying the total cost. The actual billing data is written in the field 1130 described in connection with FIG. 10A. Add multiple additional fields,
Other fees charged by using other pricing plans can be reflected. 10A and 10B are used merely as examples of the types of templates that can be used for both bill presentation development and actual bill presentation.

The techniques and apparatus described above have multiple business applications. In a typical application, as mentioned above, a pricing plan is developed by the ISP or NSP to meet the needs of each type of client with their individual needs. Further, the ISP or NSP may charge the client a maximum fee commensurate with the client's use of the network. For example, if a client connects to a server that uses a large amount of bandwidth, the ISP or NSP can detect the bandwidth used and make the appropriate billing.

In another embodiment, customer accounts may be sorted according to account number. For example, when there are 1 million customer accounts, the first section is assigned to account numbers 1 to 100000, the second section is assigned to 100001 to 200,000, and so on, so that 10 sections are created. be able to. Then, a rating engine is assigned to each partition. The rating engine uses the assigned account number range to select the usage record and determine the price. Scalability is achieved by creating an appropriate number of partitions with corresponding rating engines and distributing the rating engines across multiple computers. By assigning an account number range to the rating engine, rather than letting the rating engine handle any account, it is possible to cache account information (since no other changes are made to the same account). ,by this,
Overall usage record processing speed is increased.

In another embodiment, multiple engines can be assigned to act on the same account partition. In that case, each engine operating on the same partition is assigned a unique priority. Rating with highest priority
The engine is actively processing usage records. The other engine is monitoring the status of the active engine. If the monitoring engine detects that the first engine is inactive, the next highest priority engine will take over processing the used records. The active engine updates the record in the database with the current time stamp. If the time stamp update fails, the active engine is suspected to be non-functional. The monitoring engine initiates the takeover procedure. When the failed engine recovers, it regains control from the lower priority engine and resumes processing usage records. The central controlling entity is not involved in failures other than the database. Each engine operates autonomously.

Various aspects of this technique and apparatus may be implemented in digital circuitry or in computer hardware, firmware, software, or in combinations of them. The apparatus of the present invention may be implemented as a computer product tangibly embodied in a machine-readable storage device for execution by a programmable processor. The techniques described above may be performed by a programmable processor executing a program of instructions to perform the functions of the present invention, for example, by processing input data and producing an output.
The method includes at least one programmable processor coupled to receive data and instructions from the data storage system and to send data and instructions to the data storage system, at least one input / output device, and at least one.
It may be conveniently implemented in one or more computer programs executable on a programmable system including one output device. Each computer program can be implemented in a high level procedural or object oriented programming language, or in assembly or machine language, if desired, in which case the language is compiled. Can be a language to be interpreted or interpreted. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and / or a random access memory. Storage devices suitable for tangibly implementing computer program instructions and data include all forms of non-volatile memory, including, by way of example, semiconductor devices, such as EPROM, EEPROM and flash memory devices, embedded hardware, Includes magnetic disks such as disks and removable disks, magneto-optical disks, and CD-ROM disks. Any of the above can be augmented by or incorporated into an application specific integrated circuit (ASIC).

A number of embodiments of the invention have been described. Nevertheless, it should be understood that various modifications can be made without departing from the spirit and scope of the invention. Therefore,
Other embodiments are within the scope of the claims.

[Brief description of drawings]

[Figure 1]   FIG. 1 shows a network access system.

[Fig. 2]   FIG. 2 illustrates an embodiment of the billing system.

[Figure 3]   FIG. 3 is a process flowchart of a biller / lator embodiment.

[Figure 4]   FIG. 4 is a process flowchart of an embodiment of a graphical price plan.

5A-C are screens of an embodiment of a price plan wizard. FIG. 5D shows
3 is a flow chart of an embodiment of price plan development using a price plan wizard.

FIG. 6A is a flow chart of an embodiment of price plan development. FIG. 6B is a processing flowchart of the primitives used in the price plan. FIG. 6C is a screen shot of an embodiment of the Price Plan Builder.

FIG. 7A is a flowchart of an embodiment of a diagnostic run-time process. Figure 7B
3 is a flowchart of an embodiment of a process for creating object code.

FIG. 8 is a flow chart of an embodiment of a rating engine process.

[Figure 9]   FIG. 9 is a flowchart of an embodiment of the bill presentation process.

FIG. 10A is a screen shot of an embodiment of a blank bill presentation template. Figure 10
B is a screen of an embodiment of a bill presentation template after being supplied with billing data.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CO, CR, CU, CZ, DE , DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, I S, JP, KE, KG, KP, KR, KZ, LC, LK , LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, P T, RO, RU, SD, SE, SG, SI, SK, SL , TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72) Inventor Snowdon, Arthur Reed             New Jersey, United States 07724,             Tinton Falls, Wickham             Road 39 (72) Inventor Jeffrey, Donald Charles             New Jersey, United States 07747,             Matawan, Kristen Court 9 (72) Inventor Reun, Yu Kau             New Jersey State 07751,             Morganville, Nob Hill Road 5

Claims (39)

[Claims] 1. A method of determining a price for a billing cycle of a network service, the method comprising: using a plurality of graphical elements on a display to establish a price plan for each of a plurality of clients, the price comprising: A plan sets a price per unit of use; a step of collecting usage data from the plurality of clients; sorting the usage data into a data group corresponding to each of the plurality of clients Using the graphical element to process the data group to determine a price for the billing cycle for each of the plurality of clients, wherein the price for the billing cycle is the usage data. And the price per unit used It is those et calculation method and a step. 2. The method of claim 1, wherein the price per unit of use is determined by the time each of the clients has used the network service. 3. The method of claim 1, wherein the price per unit of use is determined by the network bandwidth used by each of the clients. 4. The method of claim 1, wherein the price per unit of use is determined by the network content used by each of the clients. 5. The method of claim 1, wherein the price per unit of use is determined by an email generated by each of the clients on the network. 6. The method of claim 1, wherein the price per unit of use is determined by the electronic storage space used by each of the clients. 7. The method of claim 1, wherein the price per unit of use is determined by the web space used by each of the clients. 8. The method of claim 1, wherein the price per unit of use is determined by the multimedia use used by each of the clients. 9. The method of claim 1, wherein the price per unit of use is determined by an internet protocol address used by each of the clients. 10. Allowing each of the plurality of clients to select a price plan that includes a plurality of prices per unit of use, and calculating a billing cycle price for each price per unit of use. Providing a price for each billing cycle to each of the clients; and allowing the client to select the most cost-effective price for the billing cycle. the method of. 11. Comparing costs associated with the plan to prices in the billing cycle, determining profits for each of a plurality of price plans, and determining actions to increase the profits. The method of claim 1, further comprising: 12. The method of claim 11, wherein the action is to change one or more of the plurality of clients to a new price plan. 13. The method of claim 11, wherein the action is to remove one or more of the price plans. 14. The method of claim 1, further comprising: developing a new price plan; and using an old usage-based data set in the new price plan to determine an impact on profits. . 15. The method of claim 1, further comprising the step of sending a bill presentation template to each of the clients. 16. The method of claim 15, wherein the bill presentation template is sent to a client web browser connected to the network. 17. The method of claim 16, wherein the bill presentation template displays fees charged during the billing cycle. 18. A method of developing a price plan for a service on a display, the method comprising providing an interface on the display, and providing an image on the interface adapted to receive criteria for a price plan. And receiving a price plan criterion in the image. 19. The method of claim 18, wherein the image on the interface is a graphical user interface (GUI) screen. 20. The step of providing the image comprises the step of presenting the GUI screens in order to present to a user the option of entering price plan criteria to generate the price plan. The method according to 19. 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 the step of providing the price plan data to at least one of the source code and the machine readable code to calculate a charge for the service. 23. The method of claim 18, wherein the image on the interface is a graphical element representing an element of the price plan. 24. Providing said image providing step, arranging said graphical element on said display to graphically represent the calculation of said price plan's charges, and providing a price plan data flow path. Providing an interconnection between the graphical elements for the purpose of :. 25. The method of claim 24, further comprising storing the placement of the graphical element as source code, and compiling the source code into machine readable code. 26. The method of claim 25, further comprising the step of providing the price plan data to at least one of the source code and the machine readable code to calculate a charge for the service. 27. A method of billing a service, comprising graphically determining a price plan for billing a client for a service based on usage, and the use of the service by the client. Maintaining a record of data for the service, determining a fee for the service based on the price plan and the record of use by the client of the service, and presenting a bill for the service. How to prepare. 28. The step of determining the price plan comprises establishing a type of use for which the client wishes to be charged; establishing a unit of cost for the type of use; 28. Generating a customized price plan template that reflects the type and unit of the expense and is adapted to receive the record of the data. 29. The step of determining the fee for the service is the customization to calculate a fee for the service by processing the record of the data based on the type of use and the unit of cost. 29. The method of claim 28, comprising using the priced template that is customized. 30. A bill presentation template adapted to present a bill for the service, the bill presentation template adapted to present the record of the data, the type of use, the unit of cost, and a charge for the service. 29. The method of claim 28, comprising: generating a bill presentation template to the client. 31. A price plan network system, at least one data collector adapted to collect client data from the network; a database coupled to the data collector; and the database. A price plan builder coupled to a user interface and a first software module having a price plan template adapted to direct a user through a series of steps for developing a price plan. A second software module including a plurality of components coupled to the first software module and adapted to be interconnected to create a price plan source code; The source code Price Plan network system comprising an object builder adapted to compile into 械読 preparative code, a bill presentation module coupled to the database. 32. The system of claim 31, further comprising a lator coupled to the database and adapted to be controlled by the machine-readable code to process the client data into billing data. 33. At least one additional lator, further comprising: the lator and the at least one additional lator adapted to operate autonomously with each other, further monitoring each other for a failure; 33. The system of claim 32, adapted to operate when one of the at least one additional iterator is inoperable. 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 system for developing and presenting a price plan, means for creating a price plan based on client usage of services, means for collecting raw usage based client data, said price plan. And means for presenting the raw use-based client data and the processed use-based client data to the client. 36. A network service provider's method for billing a client's connection to a network for developing a price plan arrangement between the service provider and the client. Step, the arrangement states that the service provider provides a connection to the network in exchange for a compensation from the client, the compensation being based on use of the network by the client. Calculated, providing a connection to the network to the client, collecting usage-based data from the network, and processing the usage-based data based on the price plan. , To the client Method and a step of presenting the serial charge. 37. A method of creating a price plan in a graphical program on a computer having a memory, a display, user input, and a processor, the memory storing a plurality of executable functions representing the nature of the price plan. And assembling a data flow diagram on the display in response to user input specifying the price plan, the data flow diagram corresponding to each of the executable functions. A method comprising: including a functional icon; 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; and processing the price plan data to calculate rate output data. 39. The method of claim 38, further comprising: creating a bill presentation template on a web page; and providing the fee output data to the bill presentation template.