Systems and methods for interfacing with a billing and account management unit

A system updates a billing unit. The system receives at least one modification to an Internet Protocol (IP) communications network account from a user and modifies a first record in a database based on the received at least one modification. The system transmits the at least one modification from the database to the billing unit and updates a second record, corresponding to the first record, in the billing unit based on the at least one modification so as to make the updated second record available in substantially real time.

FIELD OF THE INVENTION

The present invention relates generally to communications systems and, more particularly, to an operational support system that allows for communication service attributes to be updated in an account management and billing unit in substantially real time.

BACKGROUND OF THE INVENTION

Telecommunications service providers continually increase the number of services and products they offer to customers. A recent trend, for example, is a desire to offer broadband, wireless, and Internet services. As competition increases, service providers must provide an increased level of support for these advanced data services while keeping costs down.

Service providers also desire the ability to allow users (e.g., system administrators, engineers, and customers) to modify attributes associated with these advanced data services and to implement these modifications in substantially real time. By way of example, an attribute may relate to how Voice over Internet Protocol (VoIP) calls are routed to and from a customer. Conventionally, changes to telecommunication services required human intervention and could take days or weeks before the changes took effect. It is important that when these changes are eventually implemented, the service providers' billing systems be updated to reflect the changes to ensure that customers are billed correctly.

Accordingly, there is a need in the art for a system and method that allow users to modify service attributes associated with an IP communications network such that the modifications are available in substantially real time and that billing systems reflect the current service attributes.

SUMMARY OF THE INVENTION

Systems consistent with the principles of this invention address this and other needs by providing systems and methods that allow users to make changes to telecommunication services in substantially real time.

In an implementation consistent with the present invention, a method for updating a billing unit is disclosed. The method includes receiving at least one modification to an IP communications network account from a user, modifying a first record in a database based on the received at least one modification, transmitting the at least one modification from the database to the billing unit, and updating a second record, corresponding to the first record, in the billing unit based on the at least one modification. The updated second record is available in substantially real time.

In another implementation consistent with the present invention, a method for performing account management and billing is disclosed. The method includes providing a web-based interface to a user, where the web-based interface allows the user to view and manage at least one account associated with the IP communications network; receiving a modification to the at least one account from the user; updating a first record associated with the account in an operational data store based on the received modification; transferring the modification from the operational data store to an account management and billing unit associated with the IP communications network; modifying a second record associated with the account at the account management and billing unit, such that the modification to the second record is implemented in substantially real time; and performing one of an account management function and a billing function using the modified second record.

DETAILED DESCRIPTION

Implementations consistent with the present invention provide an operational support system that allows users to modify services offered by the operational support system via a web-based interface. A billing and account management unit is updated based on the modifications made by the user in substantially real time.

Exemplary System

FIG. 1illustrates an exemplary system100in which systems and methods, consistent with the present invention, may be implemented. InFIG. 1, system100includes a network110that interconnects a group of user devices120and an operational support system (OSS)130. It will be appreciated that a typical system may include more or fewer devices than illustrated inFIG. 1. Moreover, system100may include additional devices (not shown) that aid in the transfer, processing, and/or reception of data.

The network110may include, for example, the Internet, an intranet, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a public switched telephone network (PSTN), and/or some other similar type of network. In fact, the network110may include any type of network or combination of networks that permits routing of information from a particular source to a particular destination.

The user devices120may include a type of computer system, such as a mainframe, minicomputer, or personal computer, a type of telephone system, such as a POTS telephone or a session initiation protocol (SIP) telephone, and/or some other similar type of device that is capable of transmitting and receiving information to/from the network110. The user device120may connect to the network via any conventional technique, such as a wired, wireless, or optical connection.

FIG. 2illustrates an exemplary configuration of a user device120ofFIG. 1in an implementation consistent with the present invention. InFIG. 2, the user device120includes a bus210, a processor220, a memory230, a read only memory (ROM)240, a storage device250, an input device260, an output device270, and a communication interface280. The bus210may include one or more conventional buses that permit communication among the components of the user device120.

The processor220may include any type of conventional processor or microprocessor that interprets and executes instructions. In one implementation consistent with the present invention, the processor220executes the instructions to cause a web browser to be displayed to an operator of the user device120. As will be described in more detail below, the operator may access and modify attributes associated with the services provided by the OSS130via this web browser.

The memory230may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by the processor220. The memory230may also be used to store temporary variables or other intermediate information during execution of instructions by processor220.

The ROM240may include a conventional ROM device and/or another type of static storage device that stores static information and instructions for the processor220. The storage device250may include a magnetic disk or optical disk and its corresponding drive and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.

The input device260may include any conventional mechanism or combination of mechanisms that permits an operator to input information to the user device120, such as a keyboard, a mouse, a microphone, a pen, a biometric input device, such as voice recognition device, etc. The output device270may include any conventional mechanism or combination of mechanisms that outputs information to the operator, including a display, a printer, a speaker, etc.

The communication interface280may include any transceiver-like mechanism that enables the user device120to communicate with other devices and/or systems, such as OSS130. For example, the communication interface280may include a modem or an Ethernet interface to a network.

Returning toFIG. 1, the OSS130provides the infrastructure for integrating data from traditional telephony services and applications with advanced data application platforms. Through OSS130, customers, using, for example, user device120, may manage, configure, and provision traditional telephony and advanced data services in real time, obtain real time billing information, and generate reports using a rules-centric middleware core. In one embodiment, a customer may perform these functions through a single point of entry using an Internet accessible web interface.

FIG. 3illustrates an exemplary configuration of the OSS130ofFIG. 1in an implementation consistent with the present invention. As illustrated, the OSS130includes a process management system310, a network interface320, a group of integrated applications330, a group of traditional telephony systems340, a voice portal unit350, a web center unit360, an IPCOM unit370, a very high performance backbone network service (vBNS+) unit380, and a group of non-integrated applications390. It will be appreciated that the OSS130may include other components (not shown) that aid in receiving, processing, and/or transmission of data.

The process management system310acts as the backbone to the OSS130by providing graphical process automation, data transformation, event management, and flexible connectors for interfacing with OSS components. In one implementation consistent with the present invention, the process management system310uses a Common Object Request Broker Architecture (CORBA) based publish-and-subscribe messaging middleware to integrate the different components of the OSS130. Other techniques for integrating the different components of the OSS130may alternatively be used, such as eXtensible Markup Language (XML) or Enterprise JavaBeans (EJB). The process management system310may, for example, be implemented using Vitria Technology Inc.'s BusinessWare software system.

The network interface320provides a graphical user interface that allows users (e.g., customers, engineers, account teams, and the like) to access the components of the OSS130. The network interface320may include commercial off the shelf (COTS) software or hardware packages, such as Siteminder® by Netegrity, Inc. and/or iPlanet™ by Sun Microsystems, Inc., custom software or hardware, or a combination of custom software/hardware and COTS software/hardware.

Via the network interface320, customers may, for example, request that service be connected or disconnected, monitor or change network or user settings, obtain reports, and perform e-billing, account management, and trouble reporting and tracking functions in a real time manner. The network interface320may, for example, allow engineers to submit transactions to control and configure network elements and services in a real time manner. The network interface320may, for example, allow account teams to manage account creations and cancellations, generate sub-accounts from master accounts, access current account data, and access historical account data. As will be described in additional detail below, the network interface320allows for account management and billing functions to be performed remotely, such as over the Internet, via a user device120.

The network interface320authenticates users and controls actions that authenticated users are allowed to execute in the OSS130. In one implementation consistent with the present invention, the network interface320allows users access to the components of the OSS130via a single sign-on technique. This single sign-on eliminates the need for users to sign in (or authenticate themselves) in order to access different components of the OSS130. Once authenticated, users may access those components of the OSS130to which they have been provided authorization.

The integrated applications330may include, for example, a database331, a fault management unit332, a data collection unit333, a billing and account management unit334, and a reporting unit335. The database331may include one or more separate databases for storing data. In one implementation, the database331includes a data warehouse, an operational data store, and a lightweight directory access protocol (LDAP) directory server. The data warehouse acts as a repository for service order, account, usage, and performance data. In one implementation, the data warehouse may be implemented as a relational database management system (RDBMS) based system.

The operational data store (ODS) acts as the repository of data that reflects the most recent version of service and engineering attributes/parameters that should be acted upon in the network itself. The operational data store also stores authentication and authorization data. This data defines user's roles and privileges. Like the data warehouse, the operational data store may be a RDBMS based system.

The LDAP directory server stores similar information to that described above with respect to the operational data store, however, the LDAP directory server stores entries in a hierarchical, tree-like structure. As a result, the LDAP directory server provides a quick response to high volume lookup and/or search operations. Additional information regarding LDAP can be found in W. Yeong et al., “Lightweight Directory Access Protocol,” RFC 1777, March 1995, which is incorporated by reference herein.

The fault management unit332monitors and manages the overall operation of the OSS130. The fault management unit332receives information from every device, computer and application in the OSS130via the process management system310and, in situations where a fault has been detected, may transmit trouble tickets identifying the fault to the appropriate system administrator.

The data collection unit333collects customer usage and performance data for the devices supported by the OSS130, transforms the data, if necessary, and passes the data on to the appropriate device, such as the billing and account management unit334, the database331, etc. In one implementation, the data collection unit333utilizes a hierarchical architecture, having a centralized manager that defines and manages collection and data transformation schemas. Individual, lower level gatherers interface with source targets.

The billing and account management unit334receives customer usage and performance data from the data collection unit333and generates bills in a well-known manner based thereon. The billing and account management unit334may be configured with a variety of rating rules and plans and may provide mechanisms to manage and create rating plans, as well as mechanisms for building revenue reports and generating billing reports. The rating rules may be customized based on a particular customer's requirements or generalized. The rating rules may include traditional telephony styled rating rules that include time-of-day, day-of-week, distance-based, flat rate, non-recurring, and recurring on a definably regular basis, such as weekly, bi-weekly, monthly, etc., ratings. In an exemplary implementation of the present invention, the billing and account management unit334may also provide bonus points, airline miles, and other incentive items as part of the rules-based rating and billing service.

Billing and account management unit334may provide revenue and billing reports to authorized parties. Billing and account management unit334may allow customers to access previous invoices and view current charges not yet billed. In an exemplary implementation consistent with the present invention, billing and account management unit334may transfer rated events and summary records into other billing and revenue systems. For example, billing and account management unit334may receive and transfer billing information or event information to a legacy billing system (i.e., an existing billing system) that generates the actual bill. In alternative implementations, billing and account management unit334may provide hard copy bills and/or provide electronic bills to a customer. In this implementation, billing and account management unit334may be configured to perform electronic payment handling.

The billing and account management unit334also stores customer account information and allows users to access this information via the network interface320. As customer orders and accounts are created or modified through normal business functions, the OSS130keeps the billing and account management unit334up to date in a real time manner via the process management system310. Authorized parties may also extract real time data from the billing and account management unit334. While the billing and account management unit334is illustrated as a single unit inFIG. 3, in other implementations consistent with the present invention, the OSS130may include separate billing and account management units.

The reporting unit335may interact with various components of the OSS130, such as the database331and billing and account management unit334, to provide users (i.e., customers, engineers, and accountants) with the ability to obtain reports based on real time data. The reports may include, for example, billing reports, reports regarding the usage and/or performance of the network, etc.

The traditional telephony systems340may include one or more components that are typically used in a telecommunications network. In one implementation, the traditional telephony systems340include one or more legacy systems, such as an order entry system, provisioning system, billing system, and the like.

The voice portal unit350provides a variety of information services to subscribers. These services may include, for example, banking, brokerage, and financial services, travel and entertainment services, distribution and shipping services, insurance services, health and pharmaceutical services, manufacturing services, and the like. The voice portal unit350may store subscriber profiles to determine a subscriber's device preference (e.g., a cellular telephone, a personal digital assistant, a paging device, and the like) and may also track a subscriber's access to the services for billing purposes.

The web center360acts as a virtual call center by queuing, routing, and distributing communications from any first location to an appropriate agent at any second location. The web center360allows agents to handle multiple mediums (e.g., inbound telephone calls, faxes, e-mails, voicemail, VoIP transactions, etc.) via a single browser-based interface.

The IPCOM unit370may include one or more devices that provide VoIP services to subscribers. The subscribers may make and receive calls via an IP communications network using, for example, session initiation protocol (SIP) telephones. It will be appreciated that the IP communications service is not restricted to using SIP phones, however. It may also include the capability to establish IP-based inter-machine trunks between PBXs, replacing legacy telephony trunk interfaces like T1's and the like. Call routing over these IP communication trunks may traverse the IP communications network, but be terminated on both sides to a PBX. Sophisticated subscribers services, such as call forwarding, may be implemented on top of the trunking scenario.

The IPCOM unit370may support the following exemplary services: follow me, call blocking, call forwarding, voice mail, conference calling, single line extension, call screening, quality of service, class of service, dial-plan restrictions, dynamic registration, secondary directory number, and call transfer. As described above, customers may set or change attributes associated with these features via the network interface320.

The vBNS+ unit380provides the IP infrastructure for the IP communications network. The vBNS+ unit380may include a group of routers that route packets in the network. The non-integrated applications390may include, for example, a security unit, a trouble ticketing unit, and a fault manager. The security unit may include one or more firewalls for securing the network interface320, telephone equipment (e.g., PBX, switch, and redirect server), and network operations. The trouble ticketing unit manages the issuance and resolution of trouble tickets. The fault manager monitors the hardware components of the OSS130.

FIG. 4illustrates an exemplary configuration of the process management system310ofFIG. 3in an implementation consistent with the present invention. As illustrated, the process management system310includes a bus410, a processor420, a memory430, an input device440, an output device450, and a communication interface460. The bus410permits communication among the components of the process management system310.

The processor420may include any type of conventional processor or microprocessor that interprets and executes instructions. The memory430may include a RAM or another type of dynamic storage device that stores information and instructions for execution by the processor420; a ROM or another type of static storage device that stores static information and instructions for use by the processor420; and/or some type of magnetic or optical recording medium and its corresponding drive.

The input device440may include any conventional mechanism or combination of mechanisms that permits an operator to input information to the process management system310, such as a keyboard, a mouse, a pen, a biometric mechanism, and the like. The output device450may include any conventional mechanism or combination of mechanisms that outputs information to the operator, including a display, a printer, a speaker, etc. The communication interface460may include any transceiver-like mechanism that enables the process management system310to communicate with other devices and/or systems, such as the network interface320, integrated applications330, traditional telephony systems340, etc. via a wired, wireless, or optical connection.

Execution of the sequences of instructions contained in a computer-readable medium, such as memory430, causes processor420to implement the functional operations described below. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.

FIG. 5illustrates an exemplary functional block diagram of the process management system310ofFIG. 3in an implementation consistent with the present invention. As illustrated, the process management system310includes a process automator510, an analyzer520, a group of connectors530, and a transformer540. It will be appreciated that the process management system310may include additional functional elements (not shown) that aid in the reception, processing, and/or transmission of data.

The processor automator510includes a modeling tool that allows event processing to be visually modeled by engineers and product development analysts. The process automator510can then execute these models to create an automated business process. The analyzer520provides on-going and real time monitoring of the components of the OSS130. The analyzer520delivers reports, history, and trending on events processed through the process management system310.

The connectors530include a group of customized rules that allows the components of the OSS130to interact and communicate with the process management system310. A unique connector530may be established for each component in the OSS130. As new components are added to the OSS130, new connectors530are established to allow the new components to communicate with the existing components of the OSS130. Once the connectors530have been established, the OSS components may communicate with the process management system310via standard messaging or through full publish/subscribe processing. The transformer540inspects data received by the connectors530. The transformer540may also transform the data received by the connectors530, if necessary, prior to the data being transferred on to its destination.

FIG. 6illustrates an exemplary configuration of the voice portal unit350ofFIG. 3in an implementation consistent with the present invention. As illustrated, the voice portal unit350includes an eXtensible Program Management (XPM) unit610, one or more voice portal application servers620, and a customer directory database630. The XPM unit610receives user profile information from the network interface320via the process management system310and stores this information for use by the voice portal application servers620. The XPM unit610may also receive other information, such as information identifying the device(s) (e.g., personal digital assistant, cellular telephone, pager, etc.) by which the customer wishes to receive the service(s) provided.

The voice portal application servers620may include one or more servers that interact with the XPM unit610to provide, for example, banking, brokerage, and financial services, travel and entertainment services, distribution and shipping services, insurance services, health and pharmaceutical services, manufacturing services, and the like. Voice portal application servers620may also provide data collection unit333with information regarding what services are accessed and by whom. The data collection unit333may then pass this information on to the billing and account management unit334for billing purposes. The voice portal application servers620may be located at the OSS130or distributed throughout the network110. The customer directories630may store information relating to the services provided by the voice portal application servers620. For example, the customer directories630may store stock quotes, current weather forecasts, real time sports scores, etc.

FIG. 7illustrates an exemplary configuration of the web center360ofFIG. 3in an implementation consistent with the present invention. As illustrated, the web center360includes a communications server710and an agent information database720. The communications server710queues, routes, and distributes communications from any first location to an appropriate agent at any second location. The communications server710may determine the appropriate agent based on data stored in the agent information database720. The agent information database720may store agent activity information, the particular skills of the agents, and the like. Once a customer has utilized the services of the web center360, the usage information may be transmitted to the data collection unit333and then to the billing and account management unit334for billing. Users may, via the network interface320, provision new services, such as order a toll free number, and/or create new accounts at the web center360.

FIG. 8illustrates an exemplary configuration of the IPCOM unit370ofFIG. 3in an implementation consistent with the present invention. As illustrated, the IPCOM unit370includes a network server/redirect server810, CPE enterprise gateways820, and network gateways830. The network server/redirect server810may include one or more servers that process calls made over the IP communications network based on data stored in an associated database815. The database815may store data relating to call processing (e.g., information identifying the device by which the subscriber wishes to receive the call, network configuration information, etc.), subscriber profiles (e.g., subscriber identifiers), and network-supported features. The network server/redirect server810may direct calls to the appropriate gateway820or830based on this data. The network-supported features may include, for example, follow me, call blocking, call forwarding, voice mail, conference calling, single line extension, call screening, quality of service, class of service, dial-plan restrictions, dynamic registration, secondary directory number, and call transfer. As will be described in detail below, a subscriber may change attributes of these network-supported features and other network-related attributes using the network interface320.

The CPE enterprise gateways820may include one or more gateways for linking customer systems to the IP communications network. The CPE enterprise gateways820may, for example, connect to a customer's PBX and convert time division multiplexed (TDM) voice data into VoIP packets and voice signaling into SIP messages. The network gateways830include one or more gateways for linking the IP communications network to the PSTN in a well-known manner. The CPE enterprise gateways820and network gateways830track customer access and transmit this customer access data to the data collection unit333for billing purposes.

FIG. 9illustrates an exemplary configuration of the vBNS+ unit380ofFIG. 3in an implementation consistent with the present invention. As illustrated, the vBNS+ unit380includes a group of edge routers910that route packets to/from the vBNS+ core network920. The edge routers910may connect to the network server/redirect server810, network gateways830, customer's CPE equipment, other routers in the IPCom network, directly to SIP telephones, etc. The edge routers910may be configured or updated via the network interface320. The vBNS+ core920may include one or more core routers for routing packets between edge routers910.

The foregoing description of the OSS130provides an overview of the configuration of the OSS130. A more detailed description of the present invention is provided below.

Exemplary Processing

Some of the products and services supported by the OSS130enable various users (e.g., customers, engineers, accounting personnel, etc.) to submit modifications to attributes associated with services provided by the OSS130. It is important that these changes be reflected in the billing and account management unit334to ensure that the customer is properly billed after any modifications have been made to the customer's account. The present invention is directed to systems and methods that ensure that modifications made to customer accounts are available in the billing and account management unit in substantially real time.

FIG. 10illustrates an exemplary process for updating billing and account management unit334in an implementation consistent with the present invention. Processing may begin with a user (e.g., a customer, an accounting person, etc.) establishing a connection with the network interface320[act1010]. The user may, for example, accomplish this via any conventional Internet connection by entering a link or address, such as a uniform resource locator (URL), associated with the network interface320. In alternative implementations, the user may establish a direct connection with the network interface320. In each of these scenarios, the network interface320may then transmit a login screen to the user in order to authenticate the user [act1020].

FIG. 11illustrates an exemplary login screen1100consistent with the present invention. As illustrated, the login screen1100prompts the user to enter an identifier (ID)1110and password1120. The identifier may be, for example, an e-mail address or some other unique identifier associated with the user.

The user may enter an ID and password in a well-known manner via the user device120. The user device120may then transmit the user ID and password to the network interface320. The network interface320may authenticate the user by, for example, comparing the user's ID and password to authorized identifiers and passwords [act1020].

Once authenticated, the network interface320may optionally determine the level of authorization with which the user is associated [act1030]. The OSS130may, for example, grant engineers a higher level of authorization (i.e., permit access to a greater number of components of the OSS130) than customers.

If authorized, the user may perform the following exemplary account management functions: create accounts, create sub-accounts for a master account (the billing and account management unit334allows an account to be structured in a hierarchical fashion so as to reflect a customer's organization), update account information, manage disconnects, manage cancellations, access account data, and access historical data (e.g., old invoices). The user may also perform the following billing functions: creating and/or modifying pricing plans for service installation, subscription-based features (e.g., follow me, call forwarding, call blocking, voice mail, conference calling, single line extension, call screening, quality of service, class of service, dial-plan restrictions, dynamic registration, secondary directory number, and call transfer), IP communication services (e.g., VoIP), etc.

Assume that the user wishes to perform some account management function, such as creating a new account, or some billing function, such as viewing a past invoice. The network interface320may transmit graphical user interface screen(s) to the user device120to allow the user to perform desired account management and/or billing functions [act1040].

FIG. 12illustrates an exemplary account management introductory screen1200that may be provided to the user by the network interface320in an implementation consistent with the present invention. As illustrated, the account management introductory screen1200allows the user to select from the following exemplary categories: Order Management1210, Service Management1220, and Billing Management1230. The user may also select a button to obtain reference information, to change his/her password, or to create a new master customer account or sub-account. Via the Order Management category1210, the user may create, modify, cancel, or view orders. Via the Service Management category1220, the user may manage services and provision IP communication services. Via the Billing Management category1230, the user may view current or past invoices.

Upon selecting one of the categories1210-1230or buttons, such as customer profile button1240, the network interface320provides the user with one or more screens for performing the desired function(s). Initially, it is assumed that the user desires to create a new master customer account. To do so, the user may select the customer profile button1240.FIGS. 13-15illustrate exemplary screens that may be provided to a user by the network interface320in response to the user selecting the customer profile button1240in the account management introductory screen1200.

FIG. 13illustrates an exemplary account creation screen1300that can be provided to the user by the network interface320in an implementation consistent with the present invention. As illustrated, the account creation screen1300allows the user to create a new master customer account1310or to create a new sub-account for an existing master account1320. To create a new master customer account, the user may enter the name of the new master account and then select the create new master account button1330. In response, the network interface320may provide the user with the screen1400illustrated inFIGS. 14A and 14B.

In the screen1400illustrated inFIGS. 14A and 14B, the user may enter the new customer account information (e.g., account name, contact name, title, address, e-mail address, telephone number(s), fax number, customer abbreviation, customer type, etc.), customer billing information (e.g., billing contact person, address, and credit limit amount), and account information (e.g., a sales representative identifier). The fields shown inFIGS. 14A and 14Bare provided by way of example only. A typical account creation screen1400may include other fields (not shown) that aid in identifying and/or billing customers. Once the information has been entered into the fields of screen1400, the user may accept the information by selecting the confirm button1410.

Assume now that the user wishes to create one or more sub-accounts for this new master account. The user may select the customer profile button1240in account management introductory screen1200ofFIG. 12. The user may be provided with the account creation screen1300as illustrated inFIG. 15. In this scenario, the user may select the desired customer master account1510and then select the account to which the new sub-account will be added1520. The user may then select the create button1530to create the new sub-account.

FIGS. 16A and 16Billustrate an exemplary sub-account creation screen1600that may be provided to the user in an implementation consistent with the present invention. As illustrated, the sub-account creation screen1600is similar to the account creation screen1400. The sub-account creation screen1600includes the added ability to allow the master account to be billed for charges incurred by the sub-account as indicated by input1610. Once the user has entered the appropriate information into the fields of the sub-account creation screen1600, the user may accept the information by selecting the confirm button1620.

Returning toFIG. 12, assume that the user wishes to create a new order (e.g., for an IP communications service) for a customer. The user may select the Order Management category1210.FIGS. 17-19illustrate exemplary screens that may be provided to the user in an implementation consistent with the present invention.

Upon selection of the Order Management category1210, the user may be provided with the screen1700illustrated inFIG. 17. Here, the user may select the customer1710and account1720relating to the particular customer for which the order is being created. As illustrated inFIG. 17, the user has selected the South East Region of the customer UNITEL.

Upon selection of the appropriate customer and account, the user may be requested to enter a new service to be ordered1810or to add features (e.g., call forwarding, call screening, call blocking, voice mail, etc.) to an existing service1820, as illustrated in the exemplary screen1800ofFIG. 18. Assume that the customer desires to add IP communication services. The user may select “IPCOM” from the pull-down menu1810.

FIG. 19illustrates an exemplary screen1900that may be provided to the user for creating an IPCOM order in an implementation consistent with the present invention. As illustrated, the user is requested to enter service information (e.g., a service location and a service name), contact information (e.g., contact name, address, e-mail address, and telephone number), account team information (e.g., account team name, telephone number, and e-mail address), and feature information (e.g., feature type and feature name). Once the user has entered the appropriate information, the user can complete the order by selecting the next button1910.

Returning toFIG. 12, assume that the user wishes to manage a particular service by, for example, deactivating a feature or disconnecting the service. The user may select the Manage Services link in the Service Management category1220.FIGS. 20 and 21illustrate exemplary screens that may be provided to the user in an implementation consistent with the present invention.

Upon selection of the Manage Services link in the account management introductory screen1200, the user may be provided with the exemplary screen2000illustrated inFIG. 20. As illustrated, the user may be requested to select the account for which service is to be managed. The user may select the desired customer via the pull-down menu2010, an account associated with that customer via the pull-down menu2020, and a service/location via pull-down menu2030. In the exemplary screen2000illustrated inFIG. 20, the user has selected the customer ABC, the East Coast account, and IP communications service at ABC's Fairfax location.

FIG. 21illustrates an exemplary screen2100for managing the IP communications service selected inFIG. 20. Via this screen2100, the user may deactivate an existing IP communications feature, such as private call routing, prefix plan processing, location processing, call blocking, feature blocking, gateway processing, and dial plan processing, or disconnect IP communications service all together. The screen2100provides an exemplary list of active features2110(i.e., DialPlan 2ndroom, DialPlan Kitchen, and DialPlan Waynes Room). To deactivate one of these features, the user may select the particular feature to be deactivated from the list2110, and select the deactivate button2120. The other features will remain active. If, on the other hand, the user wishes to disconnect service all together, the user may select the disconnect service button2130.

Returning toFIG. 12, assume that the user wishes to view current or past invoices relating to his/her telecommunication service. The user may select the Billing Management category1230.FIGS. 22-27illustrate exemplary screens that may be provided to the user in an implementation consistent with the present invention.

Upon selection of the Billing Management category1230in the account management introductory screen1200, the user may be provided with the exemplary screen2200illustrated inFIG. 22. As illustrated, the user may be requested to select the particular account for which an invoice is desired. The user may select the customer via the pull-down menu2210and an account associated with that customer via the pull-down menu2220. In the exemplary screen2200illustrated inFIG. 22, the user has selected the customer account Joe Smith.

The user may then be presented with the exemplary view current charges screen2300illustrated inFIG. 23. Via this screen2300, the user may select to view current charges2310or a past invoice2320. To view current charges, the user may select the long distance session charges link2330. The user may then be provided with the exemplary screen2400illustrated inFIG. 24. Via this screen2400, the user may view a list of current charges2410. In this example, the user is presented with a list of current long distance charges. The list2410may include the following exemplary information: date and time, to what number the call was placed, the duration of the call, the charge per minute rate, and the total charge for each call.

If, on the other hand, the user wishes to view a past invoice, the user may select the select past invoice link2320in the screen2300illustrated inFIG. 23. In response, the user may be presented with the exemplary screen2500illustrated inFIG. 25. Via this screen2500, the user may view a past invoice by entering an invoice date range2510. Once a date range has been entered, the user may be presented with an exemplary screen2600(FIG. 26) that provides a list of past invoices that fall within the entered date range. Only one invoice is provided for simplicity. By selecting the desired invoice, the user may be presented with the exemplary screen2700illustrated inFIG. 27. Via this screen2700, the user may view a summary2710of the desired past invoice.

The screens illustrated inFIGS. 12-27have been provided by way of example. It will be appreciated that the network interface320may provide the user with similar (or different) screens for performing account management and billing functions.

Returning toFIG. 10, the network interface320receives any modifications (e.g., additions, cancellations, and/or updates) made by the user [act1050] and transmits this data to the process management system310. The process management system310transmits the new data to the warehouse and the ODS of database331. The ODS may validate, process, and store the data [act1060] and forward a copy of the data to the billing and account management unit334, via the process management system310, for storage [act1070]. In this way, the billing and account management unit334contains the most recent customer data for performing billing and account management functions. Additional details regarding the transfer of data to the billing and account management unit334via process management system310can be found in copending, commonly assigned, U.S. patent application Ser. No. 10/097,866, filed Mar. 15, 2002, the entire contents of which are expressly incorporated by reference herein.

The billing and account management unit334may thereafter generate one or more bills for a customer or perform one or more account management services using this data. In this manner, changes made by a user to services provided by the OSS130are reflected in the billing and account management unit334in substantially real time.

CONCLUSION

Implementations consistent with the present invention provide an operational support system that allows users to add, cancel, and/or modify services offered by the operational support system, such as VoIP services, via a web-based interface. The operational support system updates the billing and account management unit in substantially real time based on changes made by the users to ensure accurate billing and that services performed by the operational support system reflect these updates.

The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, it will be appreciated that the present invention can be implemented in hardware, software, or a combination of hardware and software. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.

Moreover, while a series of acts has been described with respect toFIG. 10, the order of the acts may vary in other implementations consistent with the present invention. In addition, non-dependent acts may be performed in parallel.