Billing data interface for conferencing customers Number:7,151,824 from the United States Patent and Trademark Office (PTO) owispatent A billing data interface provides billing data to customers in an accurate and efficient manner. Billing data is processed to preserve client billing information and to meet a customer's individual data requirements. The billing data may be presented in such a way that the customer may input the billing data directly into its client billing system. The billing data may be processed according to client billing specifications corresponding to a client billing system used by the customer. The processed data may preserve leading zeros, separate client code and matter code into two fields, etc. The resulting data file may be delivered to the customer for entry into the customer's client billing system.<H conferencing, customers, Billing, data, in, 7151824.html, Patent, pto, 7151824

Title: Billing data interface for conferencing customers

Abstract: A billing data interface provides billing data to customers in an accurate and efficient manner. Billing data is processed to preserve client billing information and to meet a customer's individual data requirements. The billing data may be presented in such a way that the customer may input the billing data directly into its client billing system. The billing data may be processed according to client billing specifications corresponding to a client billing system used by the customer. The processed data may preserve leading zeros, separate client code and matter code into two fields, etc. The resulting data file may be delivered to the customer for entry into the customer's client billing system.

Patent Number: 7,151,824 Issued on 12/19/2006 to Bingaman, et al.

Inventors: Bingaman; Anne K. (Washington, DC), Evans; Dagny Boyd (Alexandria, VA), Mathew; Boban (Arlington, VA)
Assignee: Soundpath Conferencing Services (Washington, DC)

Appl. No.: 10/848,149

Filed: May 19, 2004

Current U.S. Class: 379/114.22 ; 379/114.01; 379/114.26; 379/121.03; 379/127.03; 379/127.05

Current International Class: H04M 15/00 (20060101)

Field of Search: 379/114.01,114.03,114.21,114.26,114.28,115.01,121.03,121.05,126,127.03,127.05 705/51,52

References Cited [Referenced By]

U.S. Patent Documents


4481383	November 1984	Madon
4796293	January 1989	Blinken et al.
5099510	March 1992	Blinken, Jr. et al.
5287270	February 1994	Hardy et al.
5483587	January 1996	Hogan et al.
5506893	April 1996	Buscher et al.
5631904	May 1997	Fitser et al.
5701340	December 1997	Zwick
5719928	February 1998	Pinnell et al.
5818836	October 1998	DuVal
5828743	October 1998	Pinnell et al.
5842174	November 1998	Yanor
5844973	December 1998	Venkatraman et al.
5867494	February 1999	Krishnaswamy et al.
5884284	March 1999	Peters et al.
5903629	May 1999	Campbell, IV et al.
5943406	August 1999	Leta et al.
5960069	September 1999	Felger
5960416	September 1999	Block
5987633	November 1999	Newman et al.
6023499	February 2000	Mansey et al.
6141404	October 2000	Westerlage et al.
6377939	April 2002	Young
6385644	May 2002	Devine et al.
6427008	July 2002	Balaz
6515968	February 2003	Combar et al.
6553108	April 2003	Felger
6556659	April 2003	Bowman-Amuah
6925160	August 2005	Stevens et al.
2001/0002927	June 2001	Detampel, Jr. et al.
2001/0012346	August 2001	Terry
2002/0025028	February 2002	Manto
2002/0138828	September 2002	Robohm et al.
2002/0161667	October 2002	Felkey et al.
2003/0023523	January 2003	McKibben et al.
2003/0072428	April 2003	Stern et al.
2004/0170260	September 2004	Baker

Foreign Patent Documents


WO 98/23075	May., 1998	WO

Other References

US. Appl. No. 10/848,181, filed May 19, 2004, Bingaman et al. cited by other .
U.S. Appl. No. 10/848,180, filed May 19, 2004, Bingaman et al. cited by other .
U.S. Appl. No. 10/848,054, filed May 19, 2004, Bingaman et al. cited by other .
A Professional Conference Call, http://aprocall.com/billing.aspx, printed May 21, 2003 (2 pages). cited by other .
CustomCall Data Systems, http://www.customcall.com/index.html, printed May 21, 2003 (1 page). cited by other.

Primary Examiner: Tran; Quoc
Attorney, Agent or Firm: Finnegan, Henderson, Farabow, Garrett & Dunner LLP

Parent Case Text

I. RELATED APPLICATIONS

This application claims the benefit of priority of the following U.S. Provisional Patent Applications, which are incorporated herein by reference:

U.S. Provisional Patent Application No. 60/471,356, entitled INTERFACE TO BILLING SYSTEMS FOR CLIENT-REIMBURSABLE OR PROJECT-ASSIGNABLE AUDIO-CONFERENCE CALL CHARGES, filed May 19, 2003;

U.S. Provisional Patent Application No. 60/546,979, entitled ONLINE REPORTING TOOL, filed Feb. 24, 2004; and

U.S. Provisional Patent Application No. 60/563,441, entitled BILLING SYSTEM AND METHOD FOR CONFERENCING SERVICES, filed Apr. 20, 2004.

Claims

We claim:

1. A method for processing billing data for customers using conferencing services, comprising: receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; processing the cost data to remove extraneous data; batching the processed data with the client billing information to create billable event data corresponding to the conference; separating data fields in the billable event data according to client billing specifications of the customer, wherein the separating further includes preserving leading zeros in data fields corresponding to the client billing information; sorting the billable event data according to the client billing specifications; converting the sorted billable event data into a data file according to the client billing specifications; and delivering the data file to the customer.

2. A method for providing billing data to customers using conferencing services, comprising: receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; processing the cost data and the client billing information according to client billing specifications to create a data file, wherein the processing includes: creating a first data field for a client code and a second data field for a matter code, and preserving leading zeros in the client code and the matter code; and delivering the data file to the customer such that the data file may be input directly into a client billing system used by the customer to allocate costs from the conference.

3. The method of claim 2, wherein the delivering further comprises: storing the data file in a secure location; and granting the customer access to the secure location to obtain the data file.

4. The method of claim 2, wherein the delivering further comprises: enabling the customer to download the data file via a network.

5. The method of claim 2, wherein the delivering further comprises: storing the data file to a memory medium; and sending the memory medium to the customer.

6. A system for processing billing data for customers using conferencing services, comprising: a receiving component configured to receive, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; a processing component configured to process the cost data to remove extraneous data; a batching component configured to batch the processed data with the client billing information to create billable event data corresponding to the conference; a separating component configured to separate data fields in the billable event data according to client billing specifications of the customer, wherein the separating component further includes a preserving component configured to preserve leading zeros in data fields corresponding to the client billing information; a sorting component configured to sort the billable event data according to the client billing specifications; a converting component configured to convert the sorted billable event data into a data file according to the client billing specifications; and a delivering component configured to deliver the data file to the customer.

7. A system for providing billing data to customers using conferencing services, comprising: a receiving component configured to receive, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; a processing component configured to process the cost data and the client billing information according to client billing specifications to create a data file, wherein the processing component includes: a creating component configured to create a first data field for a client code and a second data field for a matter code, and a preserving component configured to preserve leading zeros in the client code and the matter code; and a delivering component configured to deliver the data file to the customer such that the data file may be input directly into a client billing system used by the customer to allocate costs from the conference.

8. The system of claim 7, wherein the delivering component further comprises: a storing component configured to store the data file in a secure location; and a granting component configured to grant the customer access to the secure location to obtain the data file.

9. The system of claim 7, wherein the delivering component further comprises: an enabling component configured to enable the customer to download the data file via a network.

10. The system of claim 7, wherein the delivering component further comprises: a storing component configured to store the data file to a memory medium; and a sending component configured to send the memory medium to the customer.

11. A system for providing billing data to customers using conferencing services, comprising: means for receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; means for processing the cost data and the client billing information according to client billing specifications to create a data file, wherein the processing includes creating a first data field for a client code and a second data field for a matter code, and preserving leading zeros in the client code and the matter code; and means for delivering the data file to the customer such that the data file may be input directly into a client billing system used by the customer to allocate costs from the conference.

12. A computer-readable medium with code embodied therein for performing a method for providing billing data to customers using conferencing services, the method comprising: receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; processing the cost data and the client billing information according to client billing specifications to create a data file, wherein the processing includes creating a first data field for a client code and a second data field for a matter code, and preserving leading zeros in the client code and the matter code; and delivering the data file to the customer such that the data file may be input directly into a client billing system used by the customer to allocate costs from the conference.

Description

II. BACKGROUND

A. Technical Field

The present invention relates generally to billing systems for conferencing services and more particularly to billing systems for conferencing services that are chargeable to a client or project.

B. Introduction

Businesses today rely heavily on conferencing services to enable people to meet without having to be physically present in the same location. Audio conferencing, video conferencing, and Web conferencing are all well-known services available to businesses operating on a regional, national, or global scale. Typically, a business makes a reservation for a conference through a conferencing services provider (CSP). The CSP establishes a "virtual location," e.g., a dial-in phone number or a Website address, for the conference participants. After the conference is over, the CSP bills the business for the cost of the conference.

A traditional CSP utilizes one or more conference facilities that provide the hardware, e.g., telephone bridges or Web servers, to support conferences. The CSP may use standard scheduling software to process customer reservations and employ a customer help line to handle any problems. If the CSP uses commissioned salespeople to sell its services, it may also use a separate sales system to track its sales and commissions data. The CSP may use an off-the-shelf or internally-developed billing system to track customer accounts and produce bills for conferences.

Many conferencing customers bill conferencing charges to their own clients or divide conferencing charges over multiple projects. For example, a law firm or consulting firm may work for several different clients and wish to divide its conferencing charges among the appropriate clients and/or matters. Because a conventional CSP typically provides a customer with a paper bill or an electronic bill in a standard format for all of its customers, the customer must input or manipulate the billing data before using the customer's own client billing software. Thus, someone in the customer's financial services department must manually process each conference bill to enable the customer to pass conferencing charges on to its clients or divide a bill among several projects. For a customer with hundreds of clients or projects, this not only takes a great deal of time but can result in human mistakes billing one client or project for another's conferences, resulting in client-relation problems.

Furthermore, conventional CSPs rely on a patchwork of systems and software that must be modified to meet the specific demands of conferencing services. For example, conferences involve a number of different people, each requiring different levels of access and information. In addition to the participants in a conference, a company's secretarial staff may be involved in scheduling the conference. The company's financial staff may be involved in processing bills, and an administrator may be designated to oversee the company's contract with the CSP. Depending on individual needs and responsibilities, each person may need access to different information. This can be very difficult to manage for a conventional conferencing services provider that relies on several separate systems.

Another difficulty faced by conventional CSPs is the calculation of salesperson commissions. Traditional commission systems base a salesperson's commission on a single measure that is easily calculated. Examples of such measures include total amount of sales or number of items sold, over a time period. Such systems are generally not designed to calculate commissions based on more economically meaningful measures such as gross margin (i.e., revenues minus cost of services sold) because of the complexity of calculating such measures. Sources of complexity include: different rates charged to different customers; different costs of services in different periods of time; and different commission rates for different services. However, conferencing services cannot be measured in simple amounts. Instead, conferencing rates vary a great deal based on, e.g., number of minutes, number of participants, time of day, etc. Furthermore, in one time period, a single customer may use several different services, making it difficult to quantify exactly what a salesperson has sold.

Systems and methods consistent with embodiments of the present invention address these and other drawbacks of conventional conferencing services provider systems.

III. SUMMARY OF THE INVENTION

Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Systems consistent with the present invention include a billing data interface to provide billing data to customers in an accurate and efficient manner. Billing data may be processed to preserve client billing information and to meet a customer's individual data requirements. The billing data may be presented in such a way that the customer may input the billing data directly into its client billing system.

In one embodiment of the present invention, a method for providing billing data to customers using conferencing services comprises receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer. The cost data and the client billing information are processed according to client billing specifications to create a data file, and the data file is delivered to the customer such that the data file may be input into a client billing system used by the customer to allocate costs from the conference.

In another embodiment, a method for processing billing data for customers using conferencing services comprises receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer; processing the cost data to remove extraneous data; and batching the processed data with the client billing information to create billable event data corresponding to the conference. Data fields in the billable event data are separated according to client billing specifications of the customer and the billable event data is sorted according to the client billing specifications. The sorted billable event data is converted into a data file according to the client billing specifications, and the data file is delivered to the customer.

In yet another embodiment, a method for providing billing data to customers using conferencing services comprises receiving, from a conference facility, cost data and client billing information for a conference conducted by participants related to a customer, and processing the cost data and the client billing information according to client billing specifications to create a data file. The processing includes creating a first data field for a client code and a second data field for a matter code, and preserving leading zeros in the client code and the matter code. The data file is delivered to the customer such that the data file may be input directly into a client billing system used by the customer to allocate costs from the conference.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

IV. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and together with the description, serve to explain the principles of the invention.

In the drawings:

FIG. 1 is a block diagram of a system for providing conferencing services, consistent with an embodiment of the present invention;

FIG. 2 is a block diagram of a customer in greater detail, consistent with an embodiment of the present invention;

FIG. 3 is a block diagram of a conferencing services provider in greater detail, consistent with an embodiment of the present invention;

FIG. 4 is a block diagram of a conference facility in greater detail, consistent with an embodiment of the present invention;

FIG. 5 depicts a CSP billing system in greater detail, consistent with an embodiment of the present invention;

FIG. 6 is a block diagram of system administration in greater detail, consistent with an embodiment of the present invention;

FIG. 6A is a screen shot of a sample display for managing users, consistent with an embodiment of the present invention;

FIG. 7 is a block diagram of customer information in greater detail, consistent with an embodiment of the present invention;

FIG. 7A is a screen shot of a sample account information screen, consistent with an embodiment of the present invention;

FIG. 7B is a screen shot of a sample billing information screen, consistent with an embodiment of the present invention;

FIG. 7C is a screen shot of a sample service rates screen, consistent with an embodiment of the present invention;

FIG. 7D is a screen shot of a sample customer traits screen, consistent with an embodiment of the present invention;

FIG. 7E is a screen shot of a sample commission screen, consistent with an embodiment of the present invention;

FIG. 7F is a screen shot of a sample customer comments screen, consistent with an embodiment of the present invention;

FIG. 7G is a screen shot of a sample contract details screen, consistent with an embodiment of the present invention;

FIG. 7H is a screen shot of a sample credit memo screen, consistent with an embodiment of the present invention;

FIG. 8 is a block diagram of system billing utilities, consistent with an embodiment of the present invention;

FIG. 9 is a flow chart of a process generating customer billing data, consistent with an embodiment of the present invention;

FIG. 10 is a flow chart of a process for creating unbilled usage data, consistent with an embodiment of the present invention;

FIG. 11 is a block diagram of a process for creating invoice reports data, consistent with an embodiment of the present invention;

FIG. 12 is a block diagram of a process for creating an ad hoc invoice, consistent with an embodiment of the present invention;

FIG. 13 is a block diagram of data access in greater detail, consistent with an embodiment of the present invention;

FIG. 14 is a block diagram of customer transactions in greater detail, consistent with an embodiment of the present invention;

FIG. 15 is a block diagram of administrative reports in greater detail, consistent with an embodiment of the present invention;

FIG. 16A is a screen shot of a sample drop-down list of reports, consistent with an embodiment of the present invention;

FIG. 16B is a screen shot of a sample dialog box for entering report criteria, consistent with an embodiment of the present invention;

FIG. 17 is a block diagram of a billing data interface in greater detail, consistent with an embodiment of the present invention;

FIG. 18 is a flow chart of processing-performed by a conference detail processor, consistent with an embodiment of the present invention;

FIG. 19 is another flow chart of processing performed by a conference detail processor, consistent with an embodiment of the present invention;

FIG. 20 is a block diagram of a bill presenter in greater detail, consistent with an embodiment of the present invention;

FIG. 21 is a block diagram of an online reporting tool in greater detail, consistent with an embodiment of the present invention;

FIG. 22 is a flow chart of processing performed by invoice reports module, consistent with an embodiment of the present invention;

FIG. 23 is a flow chart of a process for a customer to create an ad hoc report, consistent with an embodiment of the present invention;

FIG. 24 is a flow chart of a process for providing unbilled usage charges to a customer, consistent with an embodiment of the present invention, and

FIG. 25 is a block diagram of an administrative utilities in greater detail, consistent with an embodiment of the present invention.

V. DETAILED DESCRIPTION

A. Environment

FIG. 1 is a block diagram of a system for providing conferencing services consistent with an embodiment of the present invention. The system of FIG. 1 includes a customer 100, a conference facility 102, and a conferencing services provider (CSP) 104. Systems consistent with the present invention may include any number of customers 100, conference facilities 102, and CSPs 104. To provide conferencing services to customer 100, CSP 104 may utilize one or more conference facilities 102 to facilitate conferences for participants associated with customer 100.

A conference may include any type of meeting in which the participants are not physically in the same place, such as an audio conference, video conference, Web conference, or other type of conference. In one embodiment, some of the participants may be gathered together in one physical location while others are geographically dispersed. In another embodiment, each participant may be separated from the others. One of the participants may be designated as the moderator and may, for example, schedule the conference and input client billing information at the beginning of the conference.

A single customer 100 may have many associated moderators. For example, in a customer company, many different employees may conduct conferences and each one may function as a moderator at some time. In one embodiment, when customer 100 establishes an account with CSP 104, it may specify moderators associated with its account. Alternatively, a customer 100 with an existing account may add moderators at any time. CSP 104 may train moderators in using its conferencing services and may track information about each moderator, such as whether a moderator has been trained or how many conferences a moderator has conducted. CSP 104 may offer incentives or rewards to moderators, such as prizes for the moderator with the most conferences or a special offer for a moderator that has not conducted a conference in a long time.

Conference facility 102 provides a virtual location for a conference and collects data about the conference. For example, if the conference is an audio conference, conference facility 102 may include an audio conference bridge and may generate call detail records (CDRs) containing details about the conference, such as the number of participants, location of participants, and the amount of time each participant was connected to the conference. Consistent with an embodiment of the present invention, conference facility 102 also collects client billing information for the conference, e.g., from a moderator.

Client billing information may be any information used by customer 100 to allocate conferencing charges. For example, client billing information may include a client code identifying the customer's client that will be charged for part or all of a conference. In another example, client billing information may include a project code identifying the project that should be charged for part or all of a conference. In still another example, client billing information may include a biller code (e.g., an employee number) identifying the moderator or other conference participants. Consistent with the present invention, the client billing information may be associated with third parties (e.g., law firm clients) or with customer 100 (e.g., different projects or departments within the customer).

FIG. 2 is a block diagram of customer 100 in greater detail, consistent with an embodiment of the present invention. As shown in FIG. 2, customer 100 includes client billing system 200 and client billing specifications 204. Client billing system 200 may be any system that enables customer 100 to pass charges on to its clients. Alternatively, client billing system 200 may enable customer 100 to divide charges over a plurality of projects, project codes, tasks, etc. Client billing system 200 may use, for example, client codes, matter codes, biller codes, and other data in dividing charges over clients and/or projects. For example, a law firm representing many clients may assign a unique client number to each of its clients and a unique matter number to each matter for each client. Law firm customers may use known law firm billing system such as Elite, CMS-Open, etc. Client billing system 200 may be part of customer 100 or may be provided by a third party, including CSP 104.

Client billing specifications 204 may be associated with customer 100 and may correspond to client billing system 200. For example, client billing specifications 204 may specify that data input to client billing system 200 contain certain data fields in a certain order and that the data be in a specific format. For example, client billing specifications 204 may dictate two separate fields containing a client code and a matter code. In one embodiment, client billing specifications 204 may be standardized based on the type of billing system used by customer 100 or a default billing system. Client billing system 200 and client billing specifications 204 are described in greater detail below with reference to FIGS. 17 19.

FIG. 3 is a block diagram of CSP 104 in greater detail, consistent with an embodiment of the present invention. CSP 104 may include a billing system 300 to generate and manage conferencing charges for customers using conferencing services, a billing data interface 302 to provide billing data to customers in an accurate and efficient manner, and an online reporting tool 304 to present conferencing data to customers in a useful and flexible manner. CSP 104 may also include a transaction database 306, a billing database 308, a customer interface 310, and a conference facility interface 312.

Data to support CSP 104 may be stored, for example, in transaction database 306 and/or billing database 308. Alternatively, fewer or more than two databases may be used by CSP 104. CSP 104 may communicate with customers 100 via customer interface 310. For example, customer interface 310 may include a graphical user interface presented via a web server to customers over a network such as the Internet. Conference facility interface 312 enables CSP 104 to interface with conference facilities 102. For example, CSP 104 may use conference facility interface 312 to download information from conference facility 102. One skilled in the art will appreciate that CSP 104 may include fewer or more components than those depicted in FIG. 3. Furthermore, the components of CSP 104 may be combined or separated differently from the configuration shown in FIG. 3, and the components may be implemented in software and/or hardware.

FIG. 4 is a block diagram of conference facility 102 in greater detail, consistent with an embodiment of the present invention. Conference facility 102 may be any provider of hardware and/or software for conferencing. Conference facility 102 may include, for example, conferencing hardware 400 and conferencing software 402. For example, for an audio conference system, conferencing hardware 400 may include an audio conference bridge, and conferencing software 402 may include software to collect and transmit call data records (CDRs). In another alternative, conference facility 102 may offer web conferencing using conferencing hardware 400 including a web server and conferencing software 402 to manage the web server and interact with CSPs and customers.

B. Billing System

Systems consistent with the present invention include a CSP billing system to generate and manage conferencing charges for customers using conferencing services. Such a billing system may integrate functions such as customer care, management reporting, billing, commission management, and payment processing to provide seamless service to conferencing customers.

FIG. 5 depicts CSP billing system 300 in greater detail, consistent with an embodiment of the present invention. Billing system 300 includes a plurality of components, such as system administration 500, customer information 502, system billing utilities 504, data access 506, customer transactions 508, and administrative reports 510, each described in greater detail below. CSP 104 may use the components of billing system 300 to provide conferencing services to customers 100. In one embodiment, each of the components of billing system 300 may be presented as a tab on a graphical user interface to users of billing system 300. One skilled in the art will appreciate that the components depicted as being part of billing system 300 may be accessed from other parts of CSP 104 (e.g., from billing data interface 302). Furthermore, billing system 300 may include fewer or more components than are depicted in FIG. 5, the components may be combined or separated in different ways, and the components may be implemented in hardware and/or software.

FIG. 6 is a block diagram of system administration 500 in greater detail, consistent with an embodiment of the present invention. System administration 500 includes tools that may be used by a user such as an administrator to manage billing system 300. In one embodiment, system administration 500 includes user management 600, database password management 602, data backup 604, and administrator password management 606. The components of system administration 500 may be presented to the administrator, for example, as entries in a drop-down list accessed via a system billing and payment tab on a graphical user interface. By selecting user management 600, the administrator may manage users of billing system 300.

FIG. 6A is a screen shot of a sample display for managing users, consistent with an embodiment of the present invention. Via user management 600, the administrator is presented with a dialog box. The administrator may select a user, e.g., from a drop-down list of users, to manage. The administrator may also choose to create a new user and be prompted to provide user information such as a user name, user type, and user password.

To manage a user, the administrator may specify a great deal of detail about the user's access rights. For example, the administrator may select each component of billing system 300 (e.g., customer information 502 or data access 506) that the user may access. The administrator may also grant the user access to individual parts of each component. For example, the administrator may only grant the user access to add or edit sales people but not to any other part of customer information 502. Alternatively, the administrator may grant different types of access to the user, such as the right to view some reports and the right to edit other reports. In one embodiment, the user may not even be aware of components to which the user does not have access. For example, if the user does not have access to anything in system administration 500, the system administration tab will not be visible to the user when the user logs on to billing system 300.

The administrator may use database password management 602 to edit a password used to access part of billing system 300. For example, transaction database 306 may be password-protected, and the administrator may edit the password via database password management. The administrator may use data back-up 604 to manage the backup of data for billing system 300. For example, the administrator may specify a database, e.g., transaction database 306, to be backed up and a location where the back-up will be stored. The administrator may also specify what data is to be backed up, such as certain fields, types of files, etc. Using administrator password management 606, the administrator may change the password for the administrator to access billing system 300.

One skilled in the art will appreciate that the components depicted as being part of system administration 500 may be accessed from other parts of billing system 300 (e.g., from administrative reports 510). Furthermore, system administration 500 may include fewer or more components than are depicted in FIG. 6, the components may be combined or separated in different ways, and the components may be implemented in software and/or hardware.

FIG. 7 is a block diagram of customer information 502 in greater detail, consistent with an embodiment of the present invention. Customer information 502 may include tools used by billing system 300 to manage information relating to customers 100 in order to provide conferencing services. Customer information 502 comprises components such as account information 700, billing information 702, service rates 704, customer traits 706, commissions 708, comments 710, contract details 712, and credit memo 714. The components of customer information 502 may be listed, for example, as entries in a drop-down list accessed via a system billing and payment tab on a graphical user interface, may be presented to a user or administrator as dialog boxes, and may be implemented in hardware and/or software.

FIG. 7A is a screen shot of a sample account information screen consistent with an embodiment of the present invention. Account information 700 maintained by billing system 300 may include information about customers 100 such as, for example, company name, company ID, account owner, industry, office code, CSP ID, CSP company, company address, and company contact information. A single company may have multiple office codes corresponding, for example, to different locations or departments. An authorized user may view, update, search, print, etc., account information 700. The user may also view the account history corresponding to account information 700.

FIG. 7B is a screen shot of a sample billing information screen, consistent with an embodiment of the present invention. Billing information 702 maintained by billing system 300 may include, for example, a billing ID, billing contact, billing interface data, billing preferences, and a billing address. The billing contact for a customer may be the same as or different from the company contacts. Billing interface data may include data about how the customer receives billing data, such as whether the client receives billing data online, a login, a password, a contact name, and contact information. The customer's billing preferences may include, for example, type of bill presentation, bill format, bill cycle, customer client billing system, sales channel, tax status, and whether the customer uses biller codes. Customer billing is described in greater detail below with reference to FIGS. 17 20.

FIG. 7C is a screen shot of a sample service rates screen, consistent with an embodiment of the present invention. Service rates 704 tracked by billing system 300 include the rates paid for conferencing services, which may vary from customer to customer. Furthermore, a single customer may pay many different rates. For example, a customer may pay a different rate for each type of service (e.g., reservationless conference or operator-assisted conference, toll free or toll, etc.). Each rate may be tracked using a service name, service code, service sub-code, and rate. The costs associated with each customer and/or service are also managed by billing system 300.

FIG. 7D is a screen shot of a sample customer traits screen, consistent with an embodiment of the present invention. Billing system 300 may manage customer traits 706 to provide additional detail about customers 100. For example, customer traits may include number of branches, number of moderators, number of employees, previous CSP, previous rates, etc.

FIG. 7E is a screen shot of a sample commission screen consistent with an embodiment of the present invention. Commissions 708 may be used by billing system 300 to manage commissions for salespeople. Consistent with the present invention, a salesperson may be compensated for selling conferencing services for CSP 104. The salesperson may be compensated based on a commission schedule created and managed using commissions 708. For example, each salesperson may have a unique commission schedule for each customer he sells to, or the salesperson may have a default commission schedule. Alternatively, all of the salespeople for a customer may have a standard commission schedule.

To manage commissions, a commission schedule may be used. For each salesperson, an administrator or user may enter schedule details, such as the schedule name, metric, rate, schedule start date, and schedule end date. The schedule name may refer to a default commission schedule, a schedule corresponding to a customer, a schedule corresponding to a salesperson, etc. The metric may specify that the commission rate is based on gross revenue, gross margin, highest revenue, revenue collected, etc.

A matrix may be used to represent the commission schedule, such as the matrix shown in FIG. 7E. Using the matrix, a salesperson's commission may be based on the number of minutes used by a customer, the rate paid by the customer, and the commission rate. In this way, commissions may be customized according to the unique aspects of selling conferencing services.

FIG. 7F is a screen shot of a sample customer comments screen consistent with an embodiment of the present invention. Customer comments 710 may include, for example, a comment date and a comment. The comment may include notes from an administrator or user regarding a customer 100, such as information about the customer's account or services.

FIG. 7G is a screen shot of a sample contract details screen, consistent with an embodiment of the present invention. Contract details 712 may include details about a contract between CSP 104 and a customer 100, such as contract start date, contract end date, discount type, term, volume, and status.

FIG. 7H is a screen shot of a sample credit memo screen, consistent with an embodiment of the present invention. Credit memo 714 may be used to log a credit for an account, including data such as credit amount, credit date, customer representative, and credit description. It may also be used to apply a customer credit that has been logged but not processed.

One skilled in the art will appreciate that the components depicted as being part of customer information 502 may be accessed from other parts of billing system 300 (e.g., from system administration 500). Furthermore, customer information 502 may include fewer or more components than are depicted in FIG. 7, the components may be combined or separated differently, and the components may be implemented in software and/or hardware.

FIG. 8 is a block diagram of system billing utilities 504, consistent with an embodiment of the present invention. An administrator of billing system 300 may use system billing utilities 504 to support moderators associated with customers 100, obtain conference details from conference facilities 102, and create data to support billing system 300. System billing utilities 504 includes components such as bill run utilities 800, active moderator management 802, moderator training management 804, ad hoc invoice utility 806, invoice reports data utility 810, unbilled usage data utility 812, and commission management 814. The components of system billing utilities 504 may be presented, for example, as entries in a drop-down list accessed via a system billing and payment tab on a graphical user interface, and may be implemented in hardware and/or software.

By selecting bill run utilities 800, an administrator or user may run utilities to generate customer bills. The administrator may upload active moderator data using active moderator management 802 or moderator training information using moderator training management 804. As discussed above, billing system 300 may track data regarding moderators such as conference usage and whether a moderator has been trained. Using ad hoc invoice utility 806, a user of billing system 300 may create an invoice for a customer outside the periodic bill run. Ad hoc invoice utility 1402 is described in greater detail below with reference to FIG. 12.

The administrator may also create invoice reports data using invoice reports data utility 810 or may create unbilled usage data using unbilled usage data utility 812. These processes are described in greater detail below with reference to FIGS. 10 and 11. Commission management 814 enables an administrator to calculate and apply commission payments for salespeople, e.g., using commission schedules created using commissions 708.

One skilled in the art will appreciate that the components depicted as being part of system billing utilities 504 may be accessed from other parts of billing system 300 (e.g., from system billing and payment 508). Furthermore, system billing utilities 504 may include fewer or more components than are depicted in FIG. 8, the components may be combined or separated differently, and the components may be implemented in software and/or hardware.

FIG. 9 is a flow chart of a process consistent with the present invention for generating customer billing data. For example, bill run utilities 800 may be used to perform the process shown in FIG. 9. As discussed above, in one embodiment, when a conference moderator accesses conference facility 102, he may provide client billing information and conduct a conference. Further, conference facility 102 may generate conference details for the conference. For an audio conference facility, the conference details may be, for example, CDRs. To begin creating customer billing data, utility 800 receives conference details including client billing information (step 902). Utility 800 may receive conference details and client billing information from, for example, conference facility 102, customer 100, or another CSP 104.

At the end of a bill cycle, conference details may be rated by system billing utilities 504 to determine charges for conferences (step 904). System billing utilities 504 may remove courtesy calls from the rated charges (step 906). For example, CSP 104 may remove any charges for conferences including only one participant as a courtesy to customers 100. Typically, such a conference occurs when a moderator is testing the system or is in training. Alternatively, no courtesy calls may be removed from the rated charges. After the rated charges are combined with customer information stored in transaction database 306 (step 908), system billing utilities 504 calculates the taxes due on the rated charges (step 910). The taxes may be, for example, federal, state, and/or local taxes. Alternatively, the customer may be tax-exempt, and no taxes are calculated. The charges for each item may be rolled up at the billing event level (step 912). For example, ancillary costs, such as transcription charges, are added to usage charges to arrive at a summarized total charge for a conference. The summarized charges, along with rated and taxed conference details, are wed to create a billing data file (step 914), and the billing data file may be uploaded to billing database 308 (step 916). In this way, bill run data has been created by system billing utilities 504 and the billing data is available via billing database 308 to billing system 300. Further, the billing data may be stored in transaction database 306 or elsewhere.

FIG. 10 is a flow chart of a process for creating unbilled usage data consistent with an embodiment of the present invention. For example, unbilled usage data utility 812 may perform the process described in FIG. 10. Conference details including the client billing information are received (step 1002), e.g., from conference facility 102, customer 100, or another CSP 104. In one embodiment, CSP 104 may receive conference details via conference facility interface 312 on a regular basis, such as once a week or once a month. In another embodiment, conference details may be received each time a conference is completed or upon request.

To create unbilled usage data, billing system 300 uses unbilled usage data utility 812 to rate the conference details received since the last invoice to determine unbilled charges (step 1004). For example, billing system 300 may determine, for a customer, when the customer's last invoice was generated by searching transaction database 306. Once the unbilled charges are determined, they are combined with customer information from transaction database 306 (step 1006). The customer information may include, for example, a rate charged to the customer (e.g., $0.05 per minute) or the tax status (e.g., taxable or tax-exempt) of the customer.

If the customer is taxable, billing system 300 estimates the taxes due on the unbilled charges (step 1008). The tax estimation may include, for example, federal taxes, state taxes, and/or local taxes. The taxed and rated charges are rolled up to the billing event level (step 1010), and may include costs for ancillary services related to the conference, such as transcription, translation, etc., and usage charges. Once the charges are summarized, a file, such as a text file, is created (step 1012) and uploaded (step 1014), for example, to billing database 308, transaction database 306, or an online reports database. Customer 100 or an administrator at CSP 104 may then access the data to determine unbilled usage charges.

FIG. 11 is a flow chart of a process for creating invoice reports data consistent with an embodiment of the present invention. Using bill run utility 800, a user of billing system 300 may initiate a bill run to generate invoices for customers. For example, a bill run may be executed after a predetermined invoice cycle, such as once per month. At the end of a bill run, invoice reports data is created (step 1100). The invoice reports data may be stored in billing database 308, transaction database 306, or an online reports database (step 1102).

FIG. 12 is a flow chart of a process for creating an ad hoc invoice consistent with an embodiment of the present invention. Using ad hoc invoice utility 806, a user of billing system 300 may generate an invoice for a customer outside the invoice cycle. Alternatively, the user may generate an ad hoc invoice for a customer as part of the invoice cycle, for example, when the customer's data has been edited and a new invoice is needed. The user may select a customer name for the ad hoc invoice (step 1600), for example, from a list of customers. For the selected customer, billing system 300 determines the last invoice date and invoice number (step 1602) and enables creation of an invoice for ad hoc charges since the last invoice date (step 1604). The data required for the creation of ad hoc invoices may be manually inputted by a user or obtained from a process similar to a bill run. An ad hoc invoice may then be generated using the invoice data (step 1608). In one embodiment, customer information, such as customer's name, billing address, etc., may be combined with the invoice data to create the ad hoc invoice. Once the ad hoc invoice has been created, ad hoc invoice records may be created including accounting data from the ad hoc invoice creation and stored, for example, in transaction database 306 (step 1610).

FIG. 13 is a block diagram of data access 506 consistent with an embodiment of the present invention. Data access 506 handles data that is available to billing system 300, using components such as combined conference details and transaction data 1300, pre-tax data 1302, taxed billing data 1304, taxed billing data with local taxes 1306, and customer client billing data 1308. As described above, CSP 104 may generate combined conference details and transaction data for component 1300 in the course of running bill run utility 800. This data may be stored, for example, in billing database 308 and may be used by billing system 300. For example, as described above with reference to FIG. 9, billing system 300 uses conference details and transaction data 1300 in creating billing data.

Similarly, components including pre-tax data 1302, taxed billing data 1304, taxed billing data with local taxes 1306, and customer client billing data 1308 may be used by billing system 300 to support, for example, invoice data creation. Via the components of data access 506, users of billing system 300 may access data at any stage in the billing process. In one embodiment, customers 100 may also access data using the components depicted in FIG. 13. For example, customer client billing data 1308 may be made available to generate a data file that a customer may automatically enter into the customer's own client billing system. This example is described in greater detail below with reference to FIGS. 17 20.

FIG. 14 is a block diagram of customer transactions 508 in greater detail, consistent with an embodiment of the present invention. Customer transactions 508 may include components providing tools for billing system 300 such as account history 1400 and edit transactions 1402. The components of customer transactions 508 may be presented, for example, as entries in a drop-down list accessed via a system billing and payment tab on a graphical user interface. A user of billing system 300 may use account history 1400 to find and view the account history of customer 100. For example, the user may enter a customer name or identifier, e.g., by selecting it from a drop-down list of customers. An account history screen may then display information about the customer, such as a balance due, a customer identifier, and a list of transactions created for the customer. The user may be able to select an invoice from the list to view details about the invoice, such as the invoice number, conferences b