WO2003065154A2

WO2003065154A2 - Multi-stage billing

Info

Publication number: WO2003065154A2
Application number: PCT/US2003/002438
Authority: WO
Inventors: Mike K. Lee; Milton Hernandez
Original assignee: Apogee Networks
Priority date: 2002-01-28
Filing date: 2003-01-28
Publication date: 2003-08-07
Also published as: WO2003065154A3

Abstract

The invention includes a method and system for defining a transaction. In one embodiment, the inventive method includes capturing characteristics of the transaction on a data network, determining burdens and benefits of the transaction, and determining interdependencies among the characteristics. The inventive method then defines the cost of the network transaction as a function of the characteristics and interdependencies. The inventive method also may identify one or more entities who are burdened or benefited by the transaction, and bill the benefited entity as a function of the burdens, benefits, and characteristics. Also, the inventive method may compensate the burdened entity as a function of the burdens, benefits, and characteristics.

Description

MULTI-STAGE BILLING

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of Provisional Application No. 60/352,355, filed January 28, 2002, the entirety of which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The invention relates generally to the processing of data, and more particularly to generically billing for presence or the communication of data.

BACKGROUND OF THE INVENTION

[0003] Recently, the collection and processing of data transmitted over communication networks, like the Internet, has moved to the forefront of business objectives. In fact, with the advent of the Internet, new revenue generating business models have been created to account for the consumption of content received from a data network (i.e., content-based billing). For example, content distributors, application service providers (ASPs), Internet service providers

(ISPs), and wireless Internet providers have realized new opportunities based on the value of the content and services that they deliver. [0004] Capturing this value and thus capitalizing on these opportunities has been accomplished with a variety of different business processes. In particular, each technology and each market tends to create unique billing processes. In fact, unique billing procedures often vary with tl e type of service provided within these markets. Generically standardizing the billing processes, as discussed in United States Patent No. 6,208,977 entitled "Accounting and Billing Based on Network Use," and incorporated herein by reference, provides a solution for adapting the billing process to various business environments.

[0005] Often, as part of the billing process, the ability to assign cost ownership for network usage has been limited to billing the originating party and/or the receiving party. In other words, existing systems typically are limited to billing the source or the destination of the network data. This has proven inadequate for many billing scenarios. For example, some applications (e.g., multi-tiered applications) require a user to interact with an application server, which in turn interacts with a separate database server. Traditional billing systems often are incapable of correlating and billing to the user, or to another party that should bear the cost, the server-to-server communication that often includes a significant amount of the total data traffic. Traditional billing systems also are inadequate in properly allocating costs to multiple end-users that reside at related destinations. For example, universities often have many different and autonomous departments that consume network data at differing rates under the single umbrella of the particular university. In this case, it may be desirable for the university to allocate its network costs as a function of usage, instead of evenly dividing the costs among all of the departments.

[0006] Therefore, there exists a need to provide a billing technique that can capture and adequately allocate network data usage. SUMMARY OF THE INVENTION

[0007] The invention includes a method and system for defining a transaction. In one embodiment, the inventive method includes capturing characteristics of the transaction on a data network, determining burdens and benefits of the transaction, and determining interdependencies among the characteristics. The inventive method then defines the cost of the network transaction as a function of the characteristics and interdependencies. The inventive method also may identify one or more entities who are burdened or benefited by the transaction, and bill the benefited entity as a function of the burdens, benefits, and characteristics. Also, the inventive method may compensate the burdened entity as a function of the burdens, benefits, and characteristics. The transaction may comprise multi-tiered applications, including an application server tier, a database server tier, and/or a client tier. Also, the characteristics may comprise data stored, storage allocated, storage transport, technical support, hardware used, software used, data transmitted, bandwidth used, networks used, and/or firewall usage. The inventive method may link a burden to another burden or benefit and/or link a benefit to another benefit or burden.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Other features of the invention are further apparent from the following detailed description of the embodiments of the invention taken in conjunction with the accompanying drawings, of which:

[0009] Figure 1 is a block diagram of a system for analyzing content transmitted over a communication network, according to the invention; [0010] Figure 2 is a block diagram further describing the components of the system described in Figure 1 ;

[0011] Figures 3A and 3B provide a flow diagram further detailing the operation the system described in Figure 1;

[0012] Figure 4 is a block diagram of a system in which a multi-stage billing process may be implemented, according to the invention;

[0013] Figure 5 is a block diagram of a system in which a multi-stage billing process may be implemented, according to the invention; and

[0014] Figure 6 provides an example of a multi-stage billing process, according to the invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

System Overview

[0015] Figure 1 is a block diagram of a system 100 for analyzing content transmitted over a communication network. Although the following description will be discussed in the context of collecting, processing and billing for data transmitted over the Internet, it should be appreciated that the invention is no so limited. In fact, the invention may be applied to any type of network, including a private local area network, for example. Also, the invention may be used for purposes other than billing for the usage of content. For example, the invention may be used to analyze the type of data transmitted over a particular network, or to determine the routing patterns of data on a network. Furthermore, the invention may be used to facilitate the intelligent collection and aggregation of data relevant to a particular industry. In addition, the invention may be used to track specific Internet protocol (IP) network resources and to detect fraud, for example. It should also be appreciated that the invention may contemplate non-network and non-computer related business domains like commodity trading (e.g., grains, crude oil) where multiple parties are involved. Therefore, although the invention is often described in the context of the Internet, it should be appreciated that the invention may equally applied to traditional business environments.

[0016] In addition, it should be appreciated that the term "content" may be defined as data that is transmitted over the network. In the context of the Internet, content may include .mp3 files, hypertext markup language (html) pages, videoconferencing data, and streaming audio, for example. In the traditional business setting, content may include services and/or goods provided in a typical commerce stream. The terms "content provider" and "customer" also will be used throughout the description as well. Content provider may refer to the primary creator or provider of the content, while customer is the primary recipient of the content. Both the producer and customer may be a human or a computer-based system.

[0017] As shown in Figure 1, an instrumentation component 101 provides raw data to a content collection component 102. Instrumentation component 101 may consist of various data sources, for example, network routers. The network routers may provide information regarding the various types of routed data, including for example, data format, originating Internet protocol (IP) address, and destination IP address. One example of such information is Cisco System's NetFlow™.

[0018] Content collection component 102 collects information about the delivery of the content, as well as the substance of the content itself. Content collection component 102 also may sort, filter, aggregate, correlate, and store the content according to the particular needs of the end user. In effect, content collection component 102 is responsible for extracting meaningful information about IP traffic, and so it is provided with an understanding of the data sources in instrumentation component 101. Content collection component 102 also may transform the data from the plurality of sources in instrumentation component 101 into standard formats for use in a transaction component 103.

[0019] Content collection component 102 is in communication with transaction component 103. Generally, content collection component 102 reports to transaction component 103 that a relevant communication event has occurred and should be considered by the remainder of system 100. A communication event may be defined as any transfer of data between systems. Transaction component 103 captures the predetermined agreements among all of the parties involved in system 100 regarding the value of the transferred content, as well as the value added by each of the individual parties in transferring such content. Therefore, transaction component 103 is charged with understanding the nature of the parties, as well as the understanding the actions that one or more parties perform and the influence of such action on the respective parties.

[0020] Transaction component 103 is in .communication with a settlement component 104. Settlement component 104 captures the operations that are necessary to understand the significance of the transaction defined by transaction component 103. For example, settlement component 104 may rate a particular transaction by assigning a monetary value to the transaction. Settlement component 104 also may divide the burdens and benefits of the monetary value among the relevant parties. In this way, settlement component 104 ensures that certain parties receive a particular portion of the payment made by the other parties. Settlement component 104 also may be responsible for delivering this burden and benefit information to the appropriate parties with the appropriate identifiers (e.g., account numbers).

[0021] Figure 2 is a block diagram further describing the components of system 100.

As shown in Figure 2, instrumentation component 101 includes data sources 201-203 that each provide raw data 204-206, respectively, to collection component 102. As discussed, data sources

201-203 may include various internetworking devices like routers, bridges, and network switches. Data sources 201-203 provide raw data to an input data adapter 207. Accordingly, input data adapter 207 understands the operation of, and the data provided by, data sources 201-

203. Although one input data adapter is shown in Figure 2, it should be appreciated that more than one input data adapter may be used in system 100. For example, each data source may have a dedicated input data adapter. [0022] Input data adapter 207 understands the incoming data and extracts the data into the appropriate fields. This field-delimited data, called flow objects 208, are sets of attributes. The attributes may be any characteristics that are provided by, or can be derived from, raw data 204-206 provided by data sources 201-203, respectively. For example, flow objects 208 may include a set of attributes describing the source arid destination, including source IP address, destination IP address, source interface, and destination interface. Because input data adapter 207 is charged with understanding raw data 204-206 from data sources 201-203, as well as the required flow objects 208 of system 100, it is capable of transforming the raw data to the flow objects, where the flow objects may all be of a standard format.

[0023] Input data adapter 207 provides flow objects 208 to a content data language 209. Content data language 209 may transform the attributes in flow objects 208 into other attributes that are desired by a particular customer. For example, content data language 209 may derive a network identifier attribute that is not readily available from a data source, from a source address attribute and a destination address attribute that are provided by flow object 208 attributes from input data adapter 207. This derivation may be based on a customer's desire to determine which network conveyed the transaction between the source and the destination. Therefore, following this example, content data language 209 will know to extract the source address attribute and the destination address attribute from flow objects 208.

[0024] Content data language 209 may perform other functions as well. For example, content data language 209 may perform a generic .lookup function 219 that is built into content data language 209. Generally, generic lookup 219 describes a technique for mapping any number of attributes to any number of other derived attributes. For example, generic lookup 219 may be used to map a unique resource locator (URL) attribute to a particular content-type attribute.

[0025] Content data language 209 also is in communication with a correlator 211.

Generally, correlator 211 connects the many daily network content events from various network devices, like routers for example. Often, the connected data may come from distinctly different data sources at distinctly unrelated times. Correlator 211 allows this data to be intelligently connected to each other, regardless of how different the sources or of how disparate the time received. For example, a Netflow™ enabled router and a Radius™ enabled network access switch may each provide certain data that is relevant to one particular transaction. However, because portions of the data come from different devices, the data may arrive at system 100 at different times, and in different formats. Also, because each provides data that is necessary to complete one transaction, the data from each cannot be considered separately. Correlator 211 allows this data to be intelligently grouped regardless of the format of the data or of the time the data pieces are received.

[0026] Furthermore, correlator 209 may rearrange the order of the received flow objects 208 to suit the needs of the remainder of system 100. By performing such correlation without having to first store all of the data on a disk (e.g., a database), significantly faster processing is achieved. Correlator 209 may perform this correlation in real-time, for example.

[0027] Although system 100 has been described using content data language 209 and correlator 211, it should be appreciated that flow objects 208 may proceed directly to a filter 212, if no correlation is required and if no attribute derivation is required, for example. Filter 212 analyzes flow objects 208 to ensure that the provided attributes are desired by system 100. If flow objects 208 are not needed (i.e., a mismatch), filter 212 may prevent flow objects 208 from passing to an aggregator 213. Also, although filter 212 has been shown as a separate device in system 100, it should be appreciated that the functionality of filter 212 may be incorporated into aggregator 213.

[0028] Filter 212 passes the matching flow objects to aggregator 213. Aggregator 213 may provide additional filtering and classification of the multitude of daily network content transactions, based on user criteria. Aggregator 213 may perform such filtering and classification in real-time. Aggregator 213 provides the filtered and classified information to an output data adapter 214. Output data adapter 214 may convert the data from aggregator 213 into one or more content detail records for storage in CDR database 215. Therefore, CDR database 215 stores a complete description of a content event.

[0029] Transaction component 103 includes CDR database 215, an ownership resolution component 216, and a transaction resolution component 221. CDR database 215 passes the CDR onto ownership resolution component 216. A proper accounting of a communication event, for any purpose including billing, requires both identifying the participants and defining the relationships among those participants. These tasks are accomplished by ownership resolution component 216 and transaction resolution component 221.

[0030] Ownership resolution component 216 serves to define the direct and indirect participants of the communication event. In particular, because raw data 204-206 may not provide sufficient "ownership" data relating to the parties involved in the content transaction, such "ownership" data must be provided by system 100 to properly account for the entire transaction. Ownership resolution component 216 operates to provide such ownership-based data to system 100.

[0031] Ownership resolution component 216 is in communication with transaction resolution component 221. Transaction resolution component 221 serves to capture the predetermined relationships and/or agreements among the parties defined by ownership resolution component 216 regarding the value of the transferred content, as well as the value added by each of the individual parties in transferring such content. Such predetermined relationships may be previously agreed upon by the participants, or may be created and agreed upon with the implementation of system 100. Therefore, transaction component 103 understands the nature of the parties, the actions that one or more parties perform, and the influence of such action on the respective parties. [0032] Transaction component 216 provides the transaction information to a rating component 217. Rating component 217 provides a weight or significance (e.g., a price) to the transaction, so as to provide a tangible value to the transaction. Rating component 217 may make this determination based on various metrics including the type of the content, the quantity of content consumed, the place and time delivered, or the quality of the content, for example. Therefore, rating component 217 allows system 100 to provide some contextual value, indicting the significance or relevance that certain content or information has to the individual customer.

[0033] Rating component 217 provides the rated transaction to a presentment component 218. Presentment component 218 may provide the capability for a customer 220 to view their real-time billing information, for example, over the network. Presentment component 218 also may attach relevant identifiers to the bill (e.g., account numbers, etc.).

[0034] Figures 3 A and 3B provide a flow diagram further detailing the operation 300 of system 100. As shown in Figure 3 A, in step 301, raw data 204-206 is received from data sources 201-203. In step 302, input data adapter 207 converts raw data 204-206 to flow objects 208, where flow objects 208 are sets of attributes, determined from raw data 204-206. In step 303, it is determined whether there is a need to derive new attributes from the existing attributes found in flow objects 208. If there is such a need, in step 304, CDL 209 is used to derive new attributes from existing attributes.

[0035] CDL 209 may serve to provide configuration-driven transformations of the attributes provided by flow objects 208. Also, CDL 209 may serve to derive new attributes from the existing attributes provided by flow objects 208. The transformations performed by CDL

209 represent the need for certain attributes that may be desired by a particular customer. This is especially pertinent in the context of content-based billing on a diverse network, like the Internet.

Specifically, transformation of provided attributes to other derived attributes may be necessary to accommodate the attributes that are required by legacy billing systems. CDL 209 is able perform a number of functions, including function calls, mathematical operators, lookup invocations, conditional processing and assignment. It should be appreciated, however, that the operation of CDL 209 is not limited to the described functionality. Instead, the described functionality is meant to provide examples of the ability of CDL 209 to derive new attributes from given attributes. CDL 209 is further discussed in U.S. Patent Application Attorney Docket No. APOG- 0003, filed August 21, 2001, and entitled "Content Data Language," which is incorporated herein by reference. Also, as discussed above, correlator 211 may correlate the attributes.

[0036] In step 305, flow objects 208 are filtered by filter 212. In step 306, the matching flow objects (i.e., those passed by filter 212) are further filtered and classified by aggregator 213. Aggregation is the process of filtering, classifying, and applying logical or mathematical function to data, based on user criteria. The process is conducted generically (i.e., without data-specific instructions) based on predetermined criteria. The generic aggregation permits the data to be stored in an in-memory or non-permanent memory portion of the database that typically responds faster than permanent memory devices. ■

[0037] The aggregation process may be accomplished both as the data is received in real-time and offline. The aggregation process may create one or more records that provide information sufficient to adequately describe a transaction or event. Aggregation may apply to any of the "attributes" of the data.

[0038] Although aggregator 213 is shown as a component of system 100, it should be appreciated that the aggregator may be accomplished by a list of computer-readable instructions (e.g., an aggregation file) located on anywhere within the system. Aggregator 213 is located in the block of Figure 2 to facilitate the discussion of the operation of the system. The aggregation process is further discussed in U.S. Patent Application No. 60/298,622 filed June 15, 2001, and entitled "Generic Data Aggregation," which is incorporated herein by reference. In step 307, output data adapter 214 converts the data aggregated by aggregator 213 to a format compatible with transaction component 103. [0039] As shown in Figure 3B, in step 308, output adapter 214 may format the aggregated data into one or more content data records for storage in CDR database 215. In step 309, ownership resolution component 216 identifies the parties involved in the transaction. Ownership resolution component 216 reads a usage record, and applies rules to the usage record, so as to determine one or more "accountables." Accountables are labels that are used to facilitate identifying the parties or owners to a transaction. Accountables may be defined and/or modified by an external user (e.g., a customer) using a graphical user interface. Also, it should be appreciated that accountables may be defined for a new usage types for which no rules are provided. The ownership resolution process is further discussed in U.S. Patent Application Attorney Docket No. APOG-0005, filed August 21, 2001, and entitled "Content Ownership Resolution," which is incorporated herein by reference.

[0040] In step 310, transaction resolution component 221 captures the predetermined agreements among the parties, as well as the value added by each of the individual parties. Transaction resolution component 221 identifies "contracts" that define the relationships or agreements between one or more accountables. In the context of a billing system, a contract identifies which party pays (i.e., the billed party) and which party receives payment (i.e., the billing party). A particular contract may be identified and executed when one based on "conditions" are satisfied, however, such conditions may not be required. The transaction resolution process is further discussed in U.S. Patent Application Attorney Docket No. APOG- 0004, filed August 21, 2001, and entitled "Content Transaction Resolution," which is incorporated herein by reference.

[0041] In step 311, the CDR is rated based on predetermined metrics (e.g., time of transmission, quality of content). In step 312, a b^ll is presented to the customer. Multi-Stage Billing

[0042] Multi-stage billing provides a billing process that has the capacity to assign cost ownership for network usage beyond merely the originating party and/or the receiving party. The invention will be described in the context of a corporate entity with individual departments. Although the invention has general application to an organizational structure with individual and autonomous departments, it should be appreciated that the invention may apply to any billing environment that may be benefited by the multi-stage billing process. Accordingly, the invention is not limited by the following discussion, but is provided merely as one example context in which the multi-stage billing process may be implemented.

[0043] Figure 4 is a block diagram of a system 400 in which a multi-stage billing process may be implemented. Generally, Figure 4 illustrates a typical corporate data network environment accessible by various departments. The corporate data network may, for example, have certain multi-tiered applications that require a user or "client" to interact with an application server, which in turn interacts with a separate database server. In this case, the multi-stage billing process permits the organization to correlate and bill the particular user, the particular user's department, and/or another party for the server-to-server (e.g., application server to database server, etc.) communication that often includes a significant amount of the total network data traffic. For example, the organization may be a university that has many different and autonomous departments that consume network data at differing rates under the single umbrella of the particular university. In this case,, it may be desirable for the university to allocate its network costs as a function of usage, instead of evenly dividing the total costs among all of the departments. Figure 4 provides one example of a system capable of doing so.

[0044] As shown in Figure 4, the Internet 401 is in communication with a firewall 403.

A WAN probe 402 captures the flow of network data traffic between the Internet 401 and firewall 403. Firewall 403 is in communication with a Demilitarized Zone (DMZ) Webserver

409. DMZ Webserver 409 typically permits an organization to host its own email or Internet- type services, while protecting against unauthorized access to its private network (e.g., internal corporate network 405). For example, DMZ Webserver 409 may be an Information Technology (IT) department resource (i.e., "owned" or "operated" by the IT department) that hosts multiple departments within an organization (e.g., Training, Internet Business Development (IBD), Human Resources (HR), etc.), where each department has various applications and other content located on DMZ Webserver 409. DMZ Webserver 409 also is in communication with a storage server 410.

[0045] A LAN probe 404 is in communication with firewall 403 and with internal corporate network 405. LAN probe 404 captures the flow of network data traffic from internal corporate network 405 between both the Internet ,401 and DMZ Webserver 409. Internal corporate network 405 is in communication with computers 406-408. Computers 406-408 may be typical desktop computing devices, for example, that provide access to information within system 400. Also, computers 406-408 each may be operated by different departments within the corporate organization. A database server 412 may be located within internal corporate network 405. Database server 412 may operate to store data from different departments (e.g., HR data, accounting data, etc.) that may be used by a particular Webserver's application. For example an expense report Web application that may be stored on DMZ Webserver 409 may store all expense data on database server 412.

[0046] Certain IP addresses captured by WAN probe 402 may be in a Network Address

Translation (NAT) format. The NAT format is an Internet standard that allows a local-area network (LAN), like Internal corporate network 405, to use one set of IP addresses for traffic within the LAN environment and a second set of addresses for external traffic outside the LAN environment (e.g., on the WAN). Using NAT format provides a type of firewall by hiding internal IP addresses, while allowing a company to use more internal IP addresses without the risk of conflict with other external IP addresses. For the purpose of collecting network data traffic, WAN probe 402 may be programmed to ignore dynamic NAT addresses because such addresses represent network data traffic destined for internal corporate network 405, and thus already captured by LAN probe 404.

[0047] Various burdens and benefits associated with the operation of system 400 may be collected and billed to users of the system. For example, the cost of storing data on storage server 410 may be billed directly to the IT department. Alternatively, if certain portions of storage server 410 are partitioned and assigned to other departments, the other departments may be billed accordingly. In addition, any other costs associated with providing storage server 410 (e.g., support, hardware, software, etc.) similarly may be resolved, distributed and billed to the relevant departments or users. Also, billing rules located within rating component 217 may define how the costs will be distributed among the relevant entities. For example, a billing rule in rating component 217 may require that 30% be billed to a quota-based charge, and 70% to variable storage data. The amount of storage a user or organization can use is determined by its quota. The quota-based charge may be a "soft" quota, which may be temporarily exceed, or a "hard" quota, which may not be exceeded and will result in an "Out of Space" message should the user attempt to exceed the hard quota. Variable storage data refers to the actual amount of data stored.

[0048] Also, for example, the cost of transmitting the network data that may be associated with the data stored in storage server 410 may be billed based on information captured by WAN probe 402 and LAN probe 404. Such costs may include the cost of operating the

WAN, firewall 403, storage server 410, database server 412, and DMZ Webserver 409. Because

WAN probe 402 may not be able to distinguish among the individual departments using these services (e.g., Training, HR, and/or IBD, etc.) simply from the data traffic alone, the costs may be billed directly to the IT department or to the appropriate "owner" of DMZ Webserver 409, for example. The IT department may then redistribute the costs of operating the WAN costs and other costs to the appropriate departments. This redistribution may be accomplished automatically or manually from the Web usage logs maintained by DMZ Webserver 409. Also, a billing rule in rating component 217 may define how to distribute the WAN and other costs among the individual departments. For example, a certain department may be charged a higher rate than another department. It should also be appreciated that other billing rules may be defined within each department's billing procedures to identify and recover costs down to the individual user if so desired.

[0049] In addition, the cost of operating the LAN and the WAN may be recovered. For example, the cost of leasing the WAN link (e.g., a T3 link) may be billed to the end-users. Such costs may be variable, fixed, or tiered. Also, other costs of operating the WAN link, for example maintenance and hardware, similarly may be billed to the end-users.

[0050] Figure 5 is a block diagram of a system 500 in which a multi-stage billing process may be implemented. System 500 provides a more detailed view of a multi-stage billing scenario in a typical enterprise. As shown in Figure 5, internal corporate network 405 is in communication with Internet 401 via firewall 403 and a virtual private network (VPN) 514. Internal corporate network 405 may be in communication with networks other than Internet 401, for example external/private dedicated connection network 512.

[0051] As indicated parenthetically, both NPN 514 and firewall 403 are "owned" or "operated" by the IT department. Internal user X 508 and internal user Y 507 may be charged the costs of operating and accessing VPN 514 and firewall 403 based on the users' IP addresses. The users' IP addresses may be determined by a Dynamic Host Configuration Protocol (DHCP) server 513, located within internal corporate network 405, and owned by the IT department. DHCP server 513 is a server that uses a protocol for dynamically assigning IP addresses to devices (e.g., computers for internal user Y 507 and internal user X 508) on a network. DCHP server 513 permits the computers for internal user Y 507 and internal user X 508 (both of which are in communication with internal corporate network 405) to have a different IP address each time they connect to internal corporate network 405. DHCP server 513 also may use a mix of dynamic and static IP addressing. [0052] In addition to resolving IP addresses for more specific user-level billing, DHCP server 513 may be used to monitor the network data traffic. DHCP server 513 also may be used to monitor the amount of time that a particular user uses an IP address and/or the frequency with which a particular IP address is used by one or more users. In this way, by providing IP address usage information, DHCP server 513 permits individual users within a department to be charged based on content/usage of network data.

[0053] VPN 514 and firewall 403 may be in communication with DMZ Webserver 409, as discussed with reference to Figure 4. DMZ Webserver 409 may include various servers that differ by functionality and/or ownership. For example, Webserver 501 may be owned by the IT department and Webserver 502 may be owned by IBD. Webserver 501 and Webserver 502 may provide Web hosting services (e.g., applications and content) for their individual departments. Email server 503 may be owned by the IT department and permit the organization to host its own email-type services, while protecting against unauthorized access to its internal corporate network 405.

[0054] Internal corporate network 405 is in communication with a content switch 504. Content switch 504 also is in communication with Webserver 506 owned by IBD and with Webserver 505 owned by the IT department. Content switch 504 is a device, which may be owned by the IT department, and that permits the IBD to provide content to internal corporate network 405 via Webserver 505. Similarly, content switch 504 permits the IT department to provide content to internal corporate network 405 via Webserver 506. Therefore, content switch may monitor the bandwidth usage required by Webserver 505 and Webserver 506, and charge the particular department accordingly.

[0055] Internal corporate network 405 also is in communication with a firewall 511 and a VPN 510, both of which may be owned by the IT department. Firewall 511 and VPN 510 may be in communication with a Remote Authentication Dial-In User Service (RADIUS) server 509, also owned by the IT department. RADIUS server 509 is an authentication and accounting system typically used by content service providers, like the IT department for example. When a user dials into a service provider's computer, RADIUS server 509 may verify a username and password, for example, provided by the user and permit access to internal corporate network 405. RADIUS server 509 also may provide an accounting function by charging users based on the network data traffic, and perhaps the duration and/or frequency of using an IP address provided via RADIUS server 509, in a fashion that may be similar to DHCP server 503.

[0056] Defining the stages and the criteria to accomplish a multi-stage billing process may be based on the particular computing environment. For example, in a simple and typical three-tiered computing environment there may be a client tier, an application server tier, and a database server tier. The multi-stage billing process may be designed to accommodate such a tiered computing environment. For example, referring to systems 400 and 500 described with reference to Figures 4 and 5, database server 412 may be owned by the IT department. Webserver 502, owned by IBD, may house an application program, for example a training application. The training application on Webserver 502 may operate by accessing data stored on database server 412. Internal user X 508 may be a part of the HR department, and may access the training application housed on Webserver 502 via internal corporate network 405.

[0057] A multi-stage billing process may provide the ability to charge and/or compensate each of the participants that permit internal user X 508 to access and operate the training application on Webserver 502. It should be appreciated that the following is just one example of how such multi-stage billing may be performed. Internal user X 508 may be charged for bandwidth usage required to access the training application on Webserver 502. This bandwidth usage cost may be paid to the IT department, who may be responsible for the costs of operating the WAN or LAN connection. Furthermore, IBD may be charged a cost for accessing data on database server 412, as is required by their training application on Webserver 502. This storage cost may be provided to the IT department, who may be responsible for the costs of maintaining database server 412. [0058] The billing process that captures these transactions may be separated into different stages. For example, in a first stage, the bandwidth usage of internal user X 508 may be captured by LAN probe 404. Also, in a second stage, the costs associated with the bandwidth use of internal user X may be accounted for and provided to the IT department. In a third stage, the amount of data communicated by Webserver 502 in allowing internal user X 508 to operate the training application may be collected. In a fourth stage, the costs associated with the storage use of IBD for Webserver 502 may be accounted for and provided to the IT department. As noted, the above provides just one example of the multi-stage billing process. Accordingly, it should be appreciated that the invention is not limited to the above example, but may include any number of stages. Also, it should be appreciated that the processes within each stage may be as varied as the possible computing processes that may be captured.

[0059] The computing environment is defined in the multi-stage billing process via definitions of user-defined service types. Although there are many possible stages that are contemplated by the invention, Figure 6 provides another example of just one possible multistage billing process 600.

[0060] In the first stage of the multi-stage billing process 600, in step 601, network data charges (e.g., on the WAN and/or LAN) may be collected and calculated based on bandwidth usage, for example. As discussed, bandwidth usage rates may be based on variable, fixed, or tiered cost basis. In the second stage of process 600, in step 602, source and/or destination-type billing may be collected and calculated. For example, internal user Y 607 communicating with Webserver 605 will be charged with the costs going to IBD, because IBD is the owner of Webserver 605. In the third stage of the multi-stage billing process 600, in step 603, application and service-based billing may be collected and calculated. For example, IBD may charge internal user X 508 for using IBD's application resident on Webserver 505, and the IT department may charge the various departments for using IT's Webserver 601. [0061] It should be appreciated that multi-stage billing process 600 provides just one example, and is not meant to be exclusive. For example, the number of stages necessary to accomplish the level of billing detail will vary with a particular user or a particular business environment. Also, the data that is gathered or the billing instructions that are resolved within a particular stage of a multi-stage billing process also may vary with the desires of a particular user. Service types provide the mechanism by which the user may define the multi-stage billing process.

[0062] A user defines multi-stage billing by defining certain service types. The service type is defined to comprise the costs that need to be allocated to the third party. For example, there may be a service type that needs to be defined to allocate individual users storage costs for an application. The organization may have certain centralized servers (e.g., Webserver 501 and Email Server 503, etc.) that provide the ability to store, retrieve, and analyze data on internal corporate network 405. As discussed with reference to Figure 4 and Figure 5, tliese servers may provide such ability to various departments in the organization including, for example, IT, IBD, HR and Training.

[0063] In addition, the business organization may have storage resources (e.g., hard- disk drives, tape drives, etc.), like storage server 401. The business organization may desire to allocate the costs of the storage resources among the various departments that use the servers to store data on the storage resources. Also, the business organization may desire to allocate the amount of network data traffic (e.g., bandwidth) among the various departments that access the servers via internal corporate network 405. Therefore, there may be for example, at least two service types that could be defined: storage transport and storage allocation. Storage allocation may represent the specific volumes (i.e., fixed amounts of storage) used by the servers. Storage transport may represent bandwidth used in communicating with a particular storage resource (e.g., storage server 410). For example, if a user places 100 megabytes of data on storage server 401, the user not only may be charged for storing 100 megabytes, but also may incur the cost of transferring the 100 megabytes over the network.

[0064] In addition to representing the costs of the storage and bandwidth associated with the process, the user may desire to configure the service types to define one or more end- users that will be assigned the storage costs and/or bandwidth transport costs associated with a particular server. Such a service type (e.g., called "bandwidth") may define the end-users that have transactions with the servers. For example, the service type may be identified by the host/IP addresses assigned to the servers, and be defined by any communications who source or destination included the predefined server addresses.

[0065] In addition to defining the required service types, a user may define which, if any, of the service types may be linked to other service types. For example, the storage transport and storage allocation service types may be used as inputs to the bandwidth service type. Accordingly, the storage transport and storage allocation may have to be processed by rating component 217 prior to being provided to the bandwidth service type.

[0066] For example, where a Web-based training server is linked to a storage service, it may be desirable to allowing rating component 217 to process the storage costs prior to operating the Web-based training service. In this way, the Web-based training will be able to recover this known storage cost to the user of Web-based training. Once the storage allocation and storage transport service types are rated, the bandwidth service types also may be rated.

[0067] In the context of system 100, described with reference to Figure 1 and Figure 2, the service types may be a part of rating component 217. In particular, service types may be defined to determine which rate plans within rating component 217 are used for a group of content data records. Rate plans assign billing liability for the price of a data transmission to a user responsible for or involved in a communication. For example, the sender of electronic mail is responsible for sending the mail transmission and is billed the price for the mail. Similarly, the requestor of a download from a free network server is responsible for the download and is billed the price for transmitting the download from the database. As discussed in United States Patent No. 6,208,977 entitled "Accounting and Billing Based on Network Use," and incorporated herein by reference, rate plans or billing classes determine the apportionment of the total price for data transmission between pairs of source and destination node locations. A price responsibility level matrix, for example, may implement the apportionment for billing classes.

[0068] Also, the invention may contemplate a cost pool and a parent cost pool for a service. A cost pool for a service is a set of costs that a service is interested in recovering or may incur. Cost pools for a given service can be derived based on the cost pool defined for the parent service, a direct additional cost pool defined for a service, and/or on a user-defined tariff. For example, a cost pool for Web-based training service may contain costs for training material, personnel cost associated in producing the material, and technical support. A parent service cost pool may include storage costs, backup service costs, or any other user-defined costs.

[0069] The invention is directed to a system and method of providing a multi-stage billing process. The invention often was described in the context of a business organization with many individual departments or entities, but is not so limited, regardless of any specific description in the drawing or examples set forth herein. For example, the invention may be equally applied to single-tier business organizations of any size or complexity. Also, although the invention was described in the context of benefits and burdens relating to "costs," perhaps implying the exchange of money, it should be appreciated that such benefits and burdens may include any form of compensation, including for example the exchange of services. In addition, it should be appreciated that the invention may be applied to wireless networks, as well as non- traditional networks like Voice-over-IP -based networks, private networks, and/or traditional business environments like commodity trading. Furthermore, although the invention was described in the context of WAN and LAN environments, it should be appreciated that the invention may be applied to any communication of data from one point to another. For example, the invention applies equally to an internal purchasing or accounting process, for example, where transactions are made electronically.

[0070] It will be understood that the invention is not limited to the use of any of the particular components or devices herein. Indeed, this invention can be used in any application that requires the determining of relationships among parties to a transaction. Further, the system disclosed in the invention can be used with the method of the invention or a variety of other applications.

[0071] While the invention has been particularly shown and described with reference to the embodiments thereof, it will be understood by those skilled in the art that the invention is not limited to the embodiments specifically disclosed herein. Those skilled in the art will appreciate that various changes and adaptations of the invention may be made in the form and details of these embodiments without departing from the true spirit and scope of the invention as defined by the following claims.

Claims

What is Claimed:

1. A method of defining a transaction, comprising: capturing characteristics of the transaction on a data network; determining burdens and benefits of the transaction; determining interdependencies among the characteristics; and defining the cost of the network transaction as a function of the characteristics and interdependencies .

2. The method of claim 1, further comprising identifying one or more entities who are burdened or benefited by the transaction.

3. The method of claim 2, further comprising billing the benefited entity as a function of the burdens, benefits, and characteristics.

4. The method of claim 3, wherein the billing comprises at least one of the following: source type billing, destination type billing, application based billing, and service based billing.

5. The method of claim 1, further comprising compensating the burdened entity as a function of the burdens, benefits, and characteristics.

6. The method of claim 1, wherein the transaction comprises multi-tiered applications.

7. The method of claim 6, wherein the multi-tiered applications include at least one of the following: application server tier, a database server tier, and a client tier.

8. The method of claim 6, wherein the characteristics comprise at least one of the following: data stored, storage allocated, storage transport, technical support, hardware used, software used, data transmitted, bandwidth used, networks used, firewall usage.

9. The method of claim 1 , further comprising linking a burden to another burden or benefit.

10. The method of claim 1, further comprising linking a benefit to another benefit or burden.

11. The system of claim 1, further comprising identifying one or more entities as a function of Internet protocol (IP) addresses.

12. A system for defining a transaction on a data network, wherein the data network includes client devices and server devices, comprising: a Local Area Network (LAN) probe that captures characteristics of network traffic between the server device and the client device via an internal data network; and a Wide Area Network (WAN) probe that captures the characteristics of network traffic between the server device and the client device via an external data network; and a billing component that defines the cost of the network transaction as a function of the characteristics and of interdependencies among the characteristics.

13. The system of claim 12, wherein the LAN and WAN probes capture IP addresses.

14. The system of claim 12, wherein the WAN probe ignores predetermined IP addresses.

15. The system of claim 12, wherein the characteristics comprise at least one of the following: data stored, storage allocated, storage transport, technical support, hardware used, software used, data transmitted, bandwidth used, networks used, firewall usage.

16. The system of claim 15, wherein storage allocated represents specific volumes and fixed amounts of storage.

17. The system of claim 12, wherein storage transport represents bandwidth used in communicating with a particular storage resource.

18. The system of claim 12, wherein the cost of the network transaction is a quota-based charge.

19. The system of claim 12, wherein the cost of the network transaction is a variable charge.

20. The system of claim 12, further comprising capturing the characteristics of network traffic using Web usage logs.

21. The system of claim 12, further comprising capturing the characteristics of network traffic using Dynamic Host Configuration Protocol (DHCP) server.

22. The system of claim 21, wherein the DHCP identifies an amount of time that an entity uses an IP address.

23. The system of claim 21, wherein the DHCP identifies a frequency with which an IP address is used by an entity.

24. The system of claim 12, wherein a set of costs are defined as a cost pool.

25. The system of claim 24, wherein the cost pool is derived from another cost pool.

26. A method of providing a billing process to assign burdens and benefits relating to a data network transaction, comprising: capturing bandwidth usage of a user in accessing an application, using a network probe; accounting for the costs associated with the bandwidth usage; determining an amount of data communicated by a data server in allowing the user to access the application; accounting for the costs associated with the communication with the data server; and allocating costs to the appropriate entity.