US20020138427A1

US20020138427A1 - Systems and methods for communicating from an integration platform to a billing unit

Info

Publication number: US20020138427A1
Application number: US10/097,866
Authority: US
Inventors: Prakash Trivedi
Original assignee: Worldcom Inc
Current assignee: Verizon Patent and Licensing Inc
Priority date: 2001-03-20
Filing date: 2002-03-15
Publication date: 2002-09-26
Also published as: US7289522B2; US20050066053A1; US8700528B2; MXPA03008507A; EP1374509A1; US7197560B2; WO2002075339A1; EP1373912A1; US7599351B2; US9124722B2; BR0208232A; US20020138378A1; US20020136370A1; US8761745B2; JP2005518681A; BR0208168A; BR0208268A; EP1374508A1; EP1374509A4; CA2441281A1

Abstract

An operational support system includes an integration platform and a billing system. The integration platform receives user-entered information and generates an event based on the user-entered information. The integration platform publishes the event on a channel subscribed to by a connector associated with the billing system. The connector transforms the event information to a format compatible with the billing system and forwards the event to a channel that is associated with a data storage system. The connector establishes communication with the billing system and downloads the information to the billing system in response to a message indicating that the data storage system received the event information.

Description

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) based on the following U.S. Provisional Applications: Serial Nos. 60/276,923, 60/276,953, 60/276,955, and 60/276,954 all filed on Mar. 20, 2001, the disclosures of which are incorporated herein by reference.[0001]

FIELD OF THE INVENTION

The present invention relates generally to support systems for telecommunications service providers and, more particularly, to providing a connector from an integration platform to a billing unit.

BACKGROUND OF THE INVENTION

Telecommunications service providers continually increase the number of services and products they offer to customers. As competition increases, service providers must provide an increased level of support for these services while keeping costs down.

In conventional support systems, a service provider may use a system integrator to develop solutions that tie together multi-vendor hardware systems. The system integrator typically uses a commercial off the shelf (COTS) software package to integrate the various hardware systems.

One problem with using COTS software to integrate multi-vendor hardware systems is that the selected software is often incompatible with all of the existing hardware systems. In this case, the service provider is often forced to replace legacy systems (i.e., existing systems) in order to maintain full functionality.

Another problem with using COTS software to integrate multi-vendor hardware systems is that the selected software package often does not include pre-packaged modules that permit the software to communicate with various hardware platforms. This may cause the system integrator to exclude one or more hardware platforms from the support system.

SUMMARY OF THE INVENTION

There exists a need for systems and methods that improve problems associated with providing a system to support various services and products that a telecommunication service provider offers.

These and other needs are met by the present invention where an operational support system (OSS) integrates various hardware and software platforms. The OSS includes a middleware core that may be customized to integrate various applications/platforms and to ensure that data from one application can be routed to the appropriate destination(s).

According to one aspect of the invention, a method for communicating from a first system to a billing system is provided. The method includes receiving user-entered information at the first system and sending event information to a channel, where the event information is based on the user-entered information and the channel is subscribed to by a first connector associated with the billing system. The method also includes receiving, by the first connector, the event information, transforming the event information to a format compatible with the billing system and publishing the event information to a channel subscribed to by a second connector associated with a database system. The method further includes sending, by the database system, an indication that the database system received the event information and receiving the indication by the first connector. The method also includes establishing, by the first connector, communications with the billing system and downloading the transformed event information to the billing system.

Another aspect of the present invention provides a computer-readable medium having stored instructions which when executed by a processor, cause the processor to monitor an input channel for data associated with at least one of adding, deleting and modifying information stored in a billing system. The instructions also cause the processor to receive the data associated with at least one of adding, deleting and modifying information stored in the billing system, format the data based on a type associated with the received data and forward the data to an operational data storage system. The instructions further cause the processor to receive an indication that the operational data storage system received the data, establish communications with the billing system in response to receiving the indication and download the formatted data to the billing system.

A further aspect of the present invention provides a software-based connector for communicating between an integration platform and a billing system using remote invocation over Internet inter-ORB protocol. The connector includes a transformer module configured to receive input information associated with a request for information from the billing system, identify an opcode corresponding to the request and format the request to include the identified opcode. The connector also includes a client module configured to establish communications with the billing system, transmit the formatted request to the billing system and receive information from the billing system in response to the request.

Other features and advantages of the present invention will become readily apparent to those skilled in this art from the following detailed description. The embodiments shown and described provide illustration of the best mode contemplated for carrying out the invention. The invention is capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings are to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference is made to the attached drawings, wherein elements having the same reference number designation may represent like elements throughout. [0013]
FIG. 1 is a block diagram of an exemplary system in which methods and systems consistent with the present invention may be implemented. [0014]
FIG. 2 illustrates an exemplary configuration of a user device of FIG. 1 in an implementation consistent with the present invention. [0015]
FIG. 3 illustrates an exemplary configuration of the operational support system (OSS) of FIG. 1 in an implementation consistent with the present invention. [0016]
FIG. 4 illustrates an exemplary configuration of the process management system of FIG. 3 in an implementation consistent with the present invention. [0017]
FIG. 5 illustrates an exemplary functional block diagram of the process management system of FIG. 3 in an implementation consistent with the present invention. [0018]
FIG. 6 illustrates an exemplary configuration of the voice portal of FIG. 3 in an implementation consistent with the present invention. [0019]
FIG. 7 illustrates an exemplary configuration of the web center of FIG. 3 in an implementation consistent with the present invention. [0020]
FIG. 8 illustrates an exemplary configuration of the Internet Protocol communications (IPCOM) unit of FIG. 3 in an implementation consistent with the present invention. [0021]
FIG. 9 illustrates an exemplary configuration of the very high performance backbone network service (vBNS+) unit of FIG. 3 in an implementation consistent with the present invention. [0022]
FIG. 10 illustrates an exemplary functional block diagram associated with one of the connectors of FIG. 5 in an implementation consistent with the present invention. [0023]
FIGS. 11 and 12 are flow diagrams illustrating exemplary processing by the OSS in an implementation consistent with the present invention. [0024]

DETAILED DESCRIPTION

The following detailed description of implementations consistent with the present invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents. [0025]
Systems and methods consistent with the present invention provide a connection from a support system to a billing unit using a flexible software based connector. The connector may also ensure that data is properly routed to other portions of the support system before storing the data in the billing unit. [0026]

EXEMPLARY SYSTEM

FIG. 1 illustrates an [0027] exemplary system 100 in which methods and systems consistent with the present invention may be implemented. In FIG. 1, system 100 includes a network 110 that interconnects a group of user devices 120 and an operational support system (OSS) 130. It will be appreciated that a typical system may include more or fewer devices than illustrated in FIG. 1. Moreover, system 100 may include additional devices (not shown) that aid in the transfer, processing, and/or reception of data.
The [0028] network 110 may 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 network 110 may include any type of network or combination of networks that permits routing of information from a particular source to a particular destination.
The [0029] user devices 120 may 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 network 110. The user device 120 may connect to the network via any conventional technique, such as a wired, wireless, or optical connection.
FIG. 2 illustrates an exemplary configuration of a [0030] user device 120 of FIG. 1 in an implementation consistent with the present invention. In FIG. 2, the user device 120 includes a bus 210, a processor 220, a memory 230, a read only memory (ROM) 240, a storage device 250, an input device 260, an output device 270, and a communication interface 280. The bus 210 may include one or more conventional buses that permit communication among the components of the user device 120.
The [0031] processor 220 may include any type of conventional processor or microprocessor that interprets and executes instructions. The memory 230 may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by the processor 220. The memory 230 may also be used to store temporary variables or other intermediate information during execution of instructions by processor 220.
The [0032] ROM 240 may include a conventional ROM device and/or another type of static storage device that stores static information and instructions for the processor 220. The storage device 250 may 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 [0033] input device 260 may include any conventional mechanism that permits an operator to input information to the user device 120, such as a keyboard, a mouse, a microphone, a pen, a biometric input device, such as voice recognition device, etc. The output device 270 may include any conventional mechanism that outputs information to the operator, including a display, a printer, a speaker, etc.
The [0034] communication interface 280 may include any transceiver-like mechanism that enables the user device 120 to communicate with other devices and/or systems, such as OSS 130. For example, the communication interface 280 may include a modem or an Ethernet interface to a network. Alternatively, communication interface 280 may include other mechanisms for communicating via a data network.
Returning to FIG. 1, the [0035] OSS 130 provides the infrastructure for integrating applications supporting traditional telephony services and applications supporting non-traditional products/services. Through OSS 130, customers, using, for example, user device 120, may manage, configure, and provision 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. 3 illustrates an exemplary configuration of the [0036] OSS 130 of FIG. 1 in an implementation consistent with the present invention. As illustrated, the OSS 130 includes a process management system 310, a network interface 320, a group of integrated applications 330, a group of traditional telephony systems 340, a voice portal unit 350, a web center unit 360, an Internet Protocol communications (IPCOM) unit 370, a very high performance backbone network service (vBNS+) unit 380, and a group of non-integrated applications 390. It will be appreciated that the OSS 130 may include other components (not shown) that aid in receiving, processing, and/or transmitting data.
The [0037] process management system 310 acts as the backbone to the OSS 130 by providing graphical process automation, data transformation, event management, and flexible connectors for interfacing with OSS 130 components. In one implementation consistent with the present invention, the process management system 310 uses a Common Object Request Broker Architecture (CORBA) based publish-and-subscribe messaging middleware to integrate the different components of the OSS 130. Other techniques for integrating the different components of the OSS 130 may also be used, such as extensible markup language (XML) or Enterprise JavaBeans (EJB). The process management system 310 may, for example, be implemented using Vitria Technology Inc.'s BusinessWare software system.
The [0038] network interface 320, also referred to as the web front end, provides a graphical user interface that allows users (e.g., customers, engineers, account teams, and the like) to access the components of the OSS 130. The network interface 320 may 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.
The [0039] network interface 320 may, for example, allow customers to request a new service or terminate an existing service and monitor or change network or user settings/preferences. The network interface 320 may also allow customers to obtain reports and billing information, perform account management and perform trouble reporting and tracking, all in a real time manner. The network interface 320 may also allow engineers to submit transactions to control and configure network elements and services in a real time manner. The network interface 320 may also allow account teams to create and cancel accounts, generate sub-accounts from master accounts, access current account data, and access historical account data.
The [0040] network interface 320 authenticates users and controls actions that authenticated users are allowed to execute in the OSS 130. In one implementation consistent with the present invention, the network interface 320 allows users access to the components of the OSS 130 via 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 OSS 130.
The integrated [0041] applications 330 may include, for example, a data warehouse 331, an operational data store (ODS) 332, a lightweight directory access protocol (LDAP) based server 333, an LDAP database 334, a fault management unit 335, a data collection unit 336, a billing unit 337 and a reporting unit 338. The data warehouse 331 may include one or more separate databases for storing data. The data warehouse 331 acts as a repository for service order, account, usage and performance data. In one implementation, the data warehouse 331 may be implemented as a relational database management system (RDBMS) and may include a server (not shown) that controls access to the data warehouse 331.
The [0042] ODS 332 may also include one or more separate databases for storing data. The ODS 332 temporarily stores data that is used in the course of fulfilling, for example, account creation, service order management, and network provisioning operations. The ODS 332 also stores authentication and authorization data. This data defines user's roles and privileges. Like the data warehouse 331, the ODS 332 may be a RDBMS and may include a server (not shown) that controls access to the ODS 332.
The [0043] LDAP server 333 may be a general directory server that controls access to the LDAP database 334. The LDAP database 334 may be an LDAP-based repository that stores information associated with users in a hierarchical, tree-like structure. For example, the LDAP database 334 may store attributes for a user that may include preferences associated with the following exemplary services: call blocking, follow-me, 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. The LDAP database 334 may store this information as one or more directory entries for each user. Each directory entry may include an identifier associated with the user and a collection of attributes associated with the user. Each of the attributes may include a type and one or more values that identify the user's settings associated with that type. In this manner, the LDAP server 333 and LDAB database 334 provide a system that enables the user's preferences regarding various services to be stored, searched, updated and retrieved in an efficient manner. The LDAP server 333 and LDAP database 334 are shown as separate devices. It should be understood, however, that these two devices may both be part of the same directory server in implementations consistent with the present invention.
The [0044] fault management unit 335 monitors and manages the operation of the OSS 130. The fault management unit 335 may receive information from every device, computer and application in the OSS 130 via the process management system 310. In situations where a fault has been detected, the fault management unit 335 may transmit a trouble ticket identifying the fault to the appropriate system administrator.
The [0045] data collection unit 336 collects usage and performance data for the products supported by the OSS 130. In one implementation, the data collection unit 336 utilizes a hierarchical architecture, having a centralized manager that defines and manages collection and data transformation. Individual, lower level gatherers interface with source targets. The data collection unit 336 may aggregate the gathered data and provide the data to other end-user applications in a desired format. For example, data collection unit 336 may provide various records to billing unit 337.
The [0046] billing unit 337 receives customer usage and performance data from the data collection unit 336 and generates bills for the customer. The billing unit 337 may be configured with a variety of rating rules and plans and may provide mechanisms to manage and create rating plans. 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. The billing unit 337 may also provide bonus points, airline miles and other incentives as part of the rules-based rating and billing service.
The [0047] billing unit 337 may provide revenue and billing reports to authorized parties. The billing unit 337 may further allow customers to access previous invoices and view current charges not yet billed. In an exemplary implementation consistent with the present invention, the billing unit 337 may transfer rated events and summary records into other billing and revenue systems. For example, billing unit 337 may 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 unit 337 may provide hard copy bills and/or provide electronic bills to a customer. In this implementation, billing unit 337 may also be configured to perform electronic payment handling. In an exemplary implementation of the present invention, the billing unit 337 may be implemented using Infranet(I by Portal Software, Inc.
As customer orders and accounts are created or modified through normal business functions, the [0048] OSS 130 keeps the billing unit 337 up to date in a real-time manner. Authorized parties may also extract real-time data from the billing unit 337, make changes to various services and request new services, as described in more detail below.
The [0049] reporting unit 338 may interact with various components of the OSS 130, such as the data warehouse 331, the data collection unit 336 and the billing unit 337, to provide user (i.e., customers, engineers and account team members) 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 [0050] traditional telephony systems 340 may include one or more components that are typically used in a telecommunications network. In one implementation, the traditional telephony systems 340 include one or more legacy systems, such as an order entry system, provisioning system, billing system, and the like.
The [0051] voice portal unit 350 provides 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 unit 350 may store subscriber profiles to determine a subscriber's device preference (e.g., a cellular telephone, a personal digital assistant (PDA), a paging device, and the like) and may also track a subscriber's access to the services provided for billing purposes.
The [0052] web center 360 acts 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 center 360 allows agents to handle multiple mediums (e.g., inbound telephone calls, faxes, e-mails, voicemail, voice over Internet protocol (VoIP) transactions, etc.) via a single browser-based interface. In one implementation, the web center 360 may be implemented using CallCenter@nywhere from Telephony@Work, Inc.
The [0053] IPCOM unit 370 may 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. The IPCOM unit 370 may support the following 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. Customers may set or change attributes associated with these features via the network interface 320.
The vBNS+[0054] unit 380 provides the IP infrastructure for the IP communications network. The vBNS+unit 380 may include a group of edge routers for routing packets in the network. The non-integrated applications 390 may 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 interface 320, telephone equipment (e.g., PBX, switch, redirect server, etc.) and network equipment. The trouble ticketing unit manages the issuance and resolution of trouble tickets and the fault manager monitors the hardware components of the OSS 130.
FIG. 4 illustrates an exemplary configuration of the [0055] process management system 310 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the process management system 310 includes a bus 410, a processor 420, a memory 430, an input device 440, an output device 450, and a communication interface 460. The bus 410 permits communication among the components of the process management system 310.
The [0056] processor 420 may include any type of conventional processor or microprocessor that interprets and executes instructions. The memory 430 may include a RAM or another type of dynamic storage device that stores information and instructions for execution by the processor 420; a ROM or another type of static storage device that stores static information and instructions for use by the processor 420; and/or some type of magnetic or optical recording medium and its corresponding drive.
The [0057] input device 440 may include any conventional mechanism that permits an operator to input information to the process management system 310, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, and the like. The output device 450 may include any conventional mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. The communication interface 460 may include any transceiver-like mechanism that enables the process management system 310 to communicate with other devices and/or systems, such as the network interface 320, integrated applications 330, traditional telephony systems 340, etc. via a wired, wireless, or optical connection.
As discussed previously, [0058] process management system 310 may run a CORBA-based program to integrate various components of the OSS 130. As such, execution of the sequences of instructions associated with the program contained in a computer-readable medium, such as memory 430, causes processor 420 to 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. 5 illustrates an exemplary functional block diagram of the [0059] process management system 310 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the process management system 310 includes a process automator 510, an analyzer 520, a group of connectors 530, a communicator 540 and a central engine 550. In an exemplary implementation of the present invention, these elements are implemented as functional modules of a software program executed by processor 420 of the process management system 310. It will be appreciated that the process management system 310 may execute additional functional modules (not shown) that aid in the reception, processing, and/or transmission of data.
The [0060] processor automator 510 includes a modeling tool that allows event processing to be visually modeled by engineers and product development analysts. The process automator 510 can then execute these models to create an automated business process executed by the central engine 550. The analyzer 520 provides on-going and real-time monitoring of the components of the OSS 130. The analyzer 520 delivers reports, history, and trending on events processed through the central engine 550. The connectors 530 allow the components of the OSS 130 to interact and communicate with the process management system 310. The OSS components may communicate with the process management system 310 via standard messaging or through full publish/subscribe processing. The communicator 540 enables the process management system 310 to communicate with various components of the 05 S 130 using transmission control protocol/Internet protocol (TCP/IP). The central engine 550 is the core of the software program and executes customized rules to enable the process management system 310 to integrate the various systems of the OSS 130, as described in more detail below. It should be understood that the central engine 550 may be programmed to perform any rules-based processing based on the particular requirements associated with managing the OSS 130.
FIG. 6 illustrates an exemplary configuration of the [0061] voice portal unit 350 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the voice portal unit 350 includes an extensible Program Management (XPM) unit 610, one or more voice portal application servers 620, and a customer directory database 630. The XPM unit 610 receives user profile information from the network interface 320 via the process management system 310 and stores this information for use by the voice portal application servers 620. The XPM unit 610 may also receive other information, such as information identifying the device(s) (e.g., PDA, cellular telephone, pager, computer, etc.) by which a user wishes to receive the information associated with a particular service(s) to which the user has subscribed.
The voice [0062] portal application servers 620 may include one or more servers that interact with the XPM unit 610 to provide, for example, banking, brokerage, and financial services, travel, entertainment, sports and weather services, distribution and shipping services, insurance services, health and pharmaceutical services, manufacturing services, and the like. Voice portal application servers 620 may also provide data collection unit 336 with information regarding what services are accessed and by whom. The data collection unit 336 may then pass this information to billing unit 337 for billing purposes. The voice portal application servers 620 may be located at the OSS 130 or distributed throughout the network 110. The customer directories 630 may store information relating to the services provided by the voice portal application servers 620. For example, the customer directories 630 may store stock quotes, current weather forecasts, real-time sports scores, etc.
FIG. 7 illustrates an exemplary configuration of the [0063] web center 360 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the web center 360 includes a communications server 710 and an agent information database 720. The communication server 710 queues, routes, and distributes communications from any first location to an appropriate agent at any second location. The communications server 710 may determine the appropriate agent based on data stored in the agent information database 720. The agent information database 720 may store agent activity information, the particular skills of the agents, and the like. Once a customer has utilized the services of the web center 360, the usage information may be transmitted to the data collection unit 336 and then to the billing unit 337 for billing. Users may, via the network interface 320, provision new services, such as order a toll free number.
FIG. 8 illustrates an exemplary configuration of the [0064] IPCOM unit 370 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the IPCOM unit 370 includes a redirect server 810, a redirect server database 812, network server 820, customer provided equipment (CPE) enterprise gateways/routers 830 and network gateways 840. According to an exemplary implementation, the redirect server 810 executes an object request broker (ORB) that is CORBA compliant. The redirect server 810 stores data in database 812 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., a subscriber identifier) and network-supported features. The redirect server 810 may decide how to route calls based on information stored in redirect server database 812. The redirect server 810 and the redirect server database 812 are shown as separate devices. It should be understood that these devices may both be part of the same server in implementations consistent with the present invention.
The [0065] redirect server 810 forwards the routing information to the network server 820. The network server 820, also referred to as the proxy server or SIP server, processes the actual calls made over the IP communications network. The network server 820 directs the calls to CPE enterprise gateways/routers 830 or network gateways 840 based on the type of call and the network-supported features to which a customer subscribes. 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 described above, a subscriber may change attributes of these network-supported features using the network interface 320. The redirect server 810 may also communicate with the data collection unit 336.
The CPE enterprise gateways/[0066] routers 830 may include one or more gateways for linking POTS telephone systems to the IP communications network. The CPE enterprise gateways/routers 830 may, for example, connect to a customer's private branch exchange (PBX) and convert TDM voice data into VoIP packets and voice signaling into SIP messages. The CPE enterprise gateways/routers 830 may also include one or more routers that receive information from a SIP phone over a network, such as a LAN or WAN.
The [0067] network gateways 840 may include one or more gateways for linking the IP communications network to the PSTN in a well known manner. The CPE enterprise gateways/routers 830 and network gateways 840 track customer access and transmit this customer access data to the data collection unit 336 for billing purposes.
FIG. 9 illustrates an exemplary configuration of the vBNS+[0068] unit 380 of FIG. 3 in an implementation consistent with the present invention. As illustrated, the vBNS+unit 380 includes a group of edge routers 910 that route packets to/from the vBNS+core network 920. The edge routers 910 may connect to the network server 820, redirect server 810, network gateways 830, customer's CPE equipment, other routers in the IP communications network, directly to SIP telephones, etc. The vBNS+core 920 may include one or more core routers for routing packets between edge routers.
The foregoing description of the [0069] OSS 130 provides an overview of the components and operations of the OSS 130. A more detailed description of the present invention as embodied, for example, in the process management system 310, is provided below.

BILLING UNIT CONNECTOR

As described previously, the [0070] OSS 130 may provide a number of products and services to users, such as services associated with voice portal unit 350, web center 360, IPCOM unit 370 and vBNS+unit 380. Each of these products has unique billing requirements. The data collection unit 336, consistent with implementations of the present invention, retrieves data from network elements associated with these products, normalizes the data records into a format recognized by billing unit 337 and forwards the data records to billing unit 337.
The [0071] billing unit 337 may include a database that stores information associated with a customer's account (e.g., the customer's calling plan information, the services subscribed to by the customer, etc.). The billing unit 337 may also store rating information to rate the data records so that the customer is billed the appropriate amount for the services it receives. At various times, the customer, account personnel and engineering personnel may require access to the billing unit 337. The present invention is directed to systems and methods for enabling the process management system 310 to communicate with the billing unit 337 to support various parties requiring access to the billing unit 337.
FIG. 10 is an exemplary functional block diagram illustrating one of the connectors [0072] 530 (FIG. 5) of the process management system 310 that enables the process management system 310 to communicate with the billing unit 337. Referring to FIG. 10, connector 532 may be a software module (i.e., part of the software program) executed by process management system 310. The connector 532 may be a Java-based connector that enables the process management system 310 to communicate with the billing unit 337. The connector 532 may include a channel source 1010, a transformer 1020, a client 1030 and a channel target 1040. These elements may represent functional processes implemented in software.
The [0073] connector 532 acts as a conversion point to drive data to and from the billing unit 337, since the billing unit 337 is not capable of performing a publish/subscribe activity on its own without the connector 532. The connector 532 manages the semantics associated with managing event queues on a channel on behalf of the billing unit 337. According to an exemplary implementation of the invention, the connector 532 communicates with the billing unit 337 to enable a user to retrieve information stored in the billing unit 337, modify or delete information stored in the billing unit 337 and create new service identification information.
For example, a customer or a member of an account team may wish to retrieve current charges associated with the customer's account. In this case, the user may access the [0074] process management system 310 using network interface 320. The process management system 310 receives the request and invokes connector 532 to establish communications with the billing unit 337 and retrieve the desired information. In an exemplary implementation consistent with the present invention, the connector 532 uses customized opcodes to retrieve the desired information, as described in more detail below. Using custom opcodes provides for the retrieval of data from the billing unit 337 in an efficient manner.
The [0075] connector 532 may also include logic that allows “event” information to be written to the billing unit 337 using a 2-phase commit procedure. The event information may include the user-entered information received via the network interface 320. By using a 2-phase commit procedure, the process management system 310 ensures that data written to the billing unit 337 is consistent with data stored in other portions of the OSS 130, as described in more detail below.
Referring back to FIG. 10, the [0076] channel source 1010 represents input data associated with user-entered event information. For example, when a user in an accounting department accesses the OSS 130 to perform some transaction, e.g., retrieve master account information, retrieve services associated with a particular master account, retrieve current charges associated with the master account, retrieve detailed charge information associated with the master account, etc., the process management system 310 receives the request via the network interface 320 and processes the request. In an exemplary implementation consistent with the present invention, the central engine 550 (FIG. 5) publishes an event on a channel, such as the channel corresponding to the channel source 1010. The transformer 1020 subscribes to the channel associated with the channel source 1010 and receives the event information.
The [0077] transformer 1020 may then identify the particular type of event received from the channel source 1010. For example, transformer 1020 determines what service/product the event is associated with and whether the event is associated with a user requesting information or a user attempting to modify or store new information associated with a particular service/product. The transformer 1020 may then determine how to format the data associated with the received event. The transformer 1020 may also invoke client 1030 to establish communications with the billing unit 337. The client 1030 may be used to transmit the re-formatted event information to the billing unit 337.
In accordance with an exemplary implementation of the invention, the [0078] transformer 1020 may also publish the event to various channel targets 1040 subscribed to by other modules/external systems. For example, according to an exemplary implementation of the present invention, the transformer 1030 may publish event information to a channel subscribed to by a connector associated with the ODS 332, represented by channel target 1040. It should be understood that in other implementations of the invention, the connector 532 may publish event information to channels associated with other modules/externals systems, based on the particular system requirements.
As described previously, the [0079] billing unit 337 may include a database that stores information associated with customer's accounts and the services to which the customer subscribes. The billing unit 337 may execute a billing unit process 1050 to facilitate the actual execution of the received event information from the connector 532, as described in more detail below.
The [0080] billing unit 337 may also communicate with other systems via the process management system 310 before performing the desired operation associated with the received event. For example, the billing unit 337 may prepare a transaction for writing to its database. The billing unit 337, however, may wait for a “go ahead” indication from the connector 532 before actually writing the data to its database. In this manner, the connector 532 may essentially perform a 2-phase commit process associated with a received event to ensure that the actual data written to the billing unit 337 is consistent with information in other databases of the OSS 130.
FIG. 11 is a flow diagram, consistent with the present invention, illustrating exemplary processing associated with [0081] connector 532. Processing may begin when a user accesses the OSS 130 (act 1110). For example, the user may wish to change his/her particular plan associated with a particular service, such as select a plan with unlimited minutes for VoIP communications. In this case, the user may access the OSS 130 with a conventional user device 120 via network 110 (FIG. 1). The user may provide a user identification and/or password and network interface 320 may determine whether the user is authorized to access/modify various information stored in the OSS 130. Assuming that the user is authorized, the OSS 130 downloads a graphical user interface (GUI) to the user's particular user device 120 (act 1120). The GUI may include a number of options associated with the user's account. These options may include selections associated with modifying the user's plan, selections associated with receiving billing information, etc.
In an exemplary scenario, the user wishes to change his VoIP plan. In this case, the user selects “customer configuration” or a similar graphic/text input and transmits the selection to the OSS [0082] 130 (act 1130). The OSS 130 receives the selection and downloads a customer configuration interface GUI to the user device 120 (act 1130). The GUI may also include pre-stored information associated with that user. For example, the pre-stored information may indicate the user's plan information for making/receiving VoIP calls.
Assuming that the user wishes to change his VoIP plan, the user selects “modify VoIP plan” or a similarly labeled input on the GUI. The user may then input the desired modification and transmit the information to the OSS [0083] 130 (act 1140).
The [0084] process management system 310 receives the user-entered information, also referred to as an “event,” via the network interface 320 (act 1150). The central engine 550 may then publish the event on a channel (act 1150). In the example described above where the event is associated with updating the user's VoIP plan, the central engine 550 publishes the event to a channel subscribed to by connector 532, represented by channel source 1010 (FIG. 10).
The [0085] connector 532 receives the event information (act 1160). In an exemplary implementation consistent with the present invention, the transformer 1020 extracts the event contents, identifies the event type based on the received information and converts the event information into an appropriate format based on the event type (act 1160). For example, the transformer 1020 may format the event information for the billing unit 337. The transformer 1020 may also publish the event information to other systems/units, represented by channel target 1040 (act 1160).
In the exemplary scenario in which the event is associated with modifying the user's VoIP plan, the [0086] transformer 1020 may publish the event to a channel target associated with the ODS 332. The ODS 332 essentially acts as the database of record for the OSS 130. It should be understood that transformer 1020 may also publish the event information to other channels, represented by channel target 1040. These channel targets may be associated with other external systems/connectors that may be involved in storing or processing information associated with the user's profile, such as the user's VoIP plan.
After the transformer publishes the event information to [0087] channel target 1040, a connector associated with the ODS 332 receives the event information, extracts the event contents, converts the event information into an appropriate format for the ODS 332 and downloads the event information to the ODS (act 1170). For example, as described previously, ODS 332 may be an RDBMS. In this case, one of connectors 530 that is designed to communicate with an RDBMS may be utilized to establish communications with ODS 332.
The [0088] ODS 332 receives the event information and stores the event information. If the ODS 332 is unable to store the information or does not receive the information, the connector 532 may queue the event information. Assuming that the ODS 332 write operation is successful, the ODS 332 sends a signal back to the process management system 310 indicating that the event data has been stored (act 1170).
After the [0089] process management system 310 receives the acknowledgement from the ODS 332, the transformer 1020 invokes the client 1030 to establish communications with the billing unit 337 (act 1180). The client 1030 establishes the semantics associated with communicating with the billing unit 337. In an exemplary implementation consistent with the present invention, the client 1030 may communicate with the billing unit 337 via method calls using Java remote method invocation over Internet inter-ORB protocol (RMI over IIOP). In alternative implementations, the client 1030 may communicate with the billing unit 337 using other techniques. In the event that the client 1030 is unable to establish communications with the billing unit 337, the connector 532 may queue the event, as described in more detail below with respect to FIG. 12.
Assume that the [0090] client 1030 is able to establish communications with the billing unit 337. In this case, the billing unit 337 receives the event information from client 1030 and initiates a billing unit process 1050 to update the user's plan information (act 1180). The billing unit process 1050 then stores the user-entered event information in the billing unit's 337 database (act 1180).
This procedure enables the [0091] billing unit 337 to ensure that the event information will be implemented in all the proper systems/databases before the billing unit 337 commits the operation to its database, thereby maintaining consistency across the various systems in the OSS 130.
In some implementations of the present invention, after the [0092] billing unit 337 updates its database, the billing unit 337 may signal the ODS 332, via process management system 310, to write additional data to the ODS 332. For example, when the original event received at act 1150 is associated with order management, such as ordering a new service, the ODS 332 may store the order-related event information. The billing unit 337 may then store the information in its database. As part of the storing process, the billing unit 337 may create a new service identifier associated with the new service. In this case, the billing unit 337 passes the service identifier back to the ODS 332, via the process management system 310. The ODS 332 receives the service identifier and completes the order record by storing the service identifier assigned to the service by the billing unit 337.
The description above with respect to FIG. 11 illustrates a process in which the [0093] ODS 332 stores the event information followed by the billing unit 337 storing the event information. In alternative implementations, the central engine 550 may publish the event to the channel target associated with ODS 332 at the same time that the event is published to the channel subscribed to by the connector 532. In this case, connector 532 may write the data to the billing unit 337 at the same time the data is being written to the ODS 332. If the ODS 332 returns an error, i.e., the data was not successfully written to the ODS 332, the connector 532 may signal the billing unit 337 to “roll back” the transaction. For example, the error may be data related (e.g., the user entered information regarding a request to modify calling plan information that is outside an accepted range) or equipment related (e.g., the ODS 332 is offline). In either case, the connector 532 signals the billing unit process 1050 to return the billing unit's 337 database to the state it was in prior to receiving the event information. This ensures that the billing unit's 337 database and the ODS 332 remain consistent.
Implementations consistent with the present invention also provide a mechanism for establishing a connection between the [0094] connector 532 and the billing unit 337 after an initial attempt is unsuccessful. FIG. 12 is a flow diagram, consistent with the present invention, illustrating exemplary processing associated with establishing communications with billing unit 337. Assume that the client 1030 cannot establish a connection with the billing unit 337 at act 1180 (act 1210). For example, assume that the billing unit 337 is offline, busy with another event, or generally unavailable. In this case, client 1030 queues the event (act 1220).
The [0095] client 1030 may also start a thread to check when the connection to the billing unit 337 can be made, i.e., determine when the billing unit 337 is available (act 1230). For example, the client 1030 may open a new thread that periodically “pings” the billing unit 337 to determine whether the billing unit 337 is available (act 1240). If the billing unit 337 is not available, the client 1030 may re-check the billing unit 337 every predetermined period of time. The predetermined period may be configurable. In addition, the client 1030 may repeat this process until a positive response is received or may ping the billing unit 337 a configurable number of times.
When the [0096] billing unit 337 is available, the client 1030 establishes the communication link to the billing unit 337 and downloads the queued event information to the billing unit 337 (act 1250). The billing unit 337 may then store the event information in its database (act 1250).
If the [0097] billing unit 337 is still unavailable after a predetermined period of time or after a predetermined number of attempts, the client 1030 may provide an alarm message indicating that the billing unit 337 is unavailable (act 1260). This alarm may be sent to a device, such as fault management unit 335. In implementations consistent with the present invention, the connector 532 may also provide information as to why the connection with the billing unit 337 cannot be established. For example, the connector 532 may indicate that the billing unit 337 is offline. The connector 532 may then send an error message to the user.
The [0098] connector 532, in implementations consistent with the present invention, may also signal the ODS 332, via process management system 310 to roll back the previous write operation (act 1270). In this manner, data across the OSS 130 remains consistent.
As described previously, customers, account personnel and engineering personnel may wish to access the [0099] billing unit 337 to retrieve information. For example, a party may wish to retrieve master account information, retrieve all services performed for a particular master account, retrieve all current charges for a master account, retrieve detailed charges for a master account, or retrieve any other information associated with the customer's account. In these situations, the user may make the request for information via network interface 320 in a manner similar to that described with respect to acts 1110 to 1150. The connector 532, however, recognizes that the event is a request for information and does not publish the event to any other channel targets. The transformer 1020 (FIG. 10) opens client 1030, which establishes communications with billing unit 337. The billing unit process 1050 retrieves the desired information and the process management system 310 provides the requested information to the user.
In summary, an authorized user may request any type of information regarding a customer's account via [0100] network interface 320. The process management system 310 publishes these type of events to a channel subscribed to by connector 532. Connector 532 identifies the type of request, formats the request for billing unit 337 and retrieves the desired information. The process management system 310 then returns the requested data to the authorized user.
To facilitate retrieval of information from the [0101] billing unit 337, the process management system 310 may use custom opcodes, as described previously. The custom opcodes may be implemented in Java using RMI over IIOP. The particular custom opcodes may be designed based on the service provider's business requirements so that the same opcodes can be used for any of the products/services in the OSS 130. For example, the same opcode may be used to retrieve account information associated with services provided by voice portal unit 350, web center 360, IPCOM unit 370 and vBNS+unit 380. In this manner, the programming associated with the customized opcodes may be minimized to take advantage of commonality associated with the various products/services of the OSS 130. For example, when a particular request is made, the connector 532 uses the appropriate custom opcode identifying the request. The billing unit 337 recognizes the opcode and returns the requested information on the customer's account.
Systems and methods consistent with the present invention provide a flexible connection between a support system and a [0102] billing unit 337 to allow a user to modify information regarding the services subscribed to by the user, request new services and request information from the billing unit 337. An advantage of the invention is that the connector may be easily customized to support new products/services. Another advantage of the invention is that the connector is fault tolerant. For example, when the billing unit 337 is unavailable, the connector 532 includes provisions for retrying the connection. This results in a more flexible and reliable system.
A further advantage of the present invention is the system can be easily modified to support various vendors' equipment. For example, the [0103] connector 532 described above essentially uses a two-tiered approach to connect with the billing unit 337. The first tier deals with the semantics of the physical connection and protocol between the connector 532 and the target billing unit 337. The second tier described above in relation to the transformer process deals with transaction completion and fault tolerance. If the particular vendor associated with the billing unit 337 changes, only the first tier of the connector needs to be modified to support this vendor. Therefore, the connector 532 facilitates the integration of new systems, thereby reducing development time and costs.
In this disclosure, there is shown and described only the preferred embodiments of the invention, but, as aforementioned, it is to be understood that the invention is capable of use in various other combinations and environments and is capable of changes or modifications within the scope of the inventive concept as expressed herein. [0104]
For example, the present invention has been described with a few examples with respect to requesting changes in service, requesting new services and requesting information stored in the [0105] billing unit 337. It should be understood that the present invention may be used to support any number of requests associated with account management, order management, service management and bill presentation. In addition, aspects of the present invention have been described as series of acts in relation to FIGS. 11 and 12. It should be understood that the order of these acts may vary in other implementations of the present invention. Moreover, non-dependent acts may be performed in parallel.
No element, act or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. [0106]
The scope of the invention is defined by the claims and their equivalents. [0107]

Claims

What is claimed is:

1. A method for conununicating from a first system to a billing system, the method comprising:

receiving user-entered information at the first system;

sending, by the first system, event information to a channel, the event information being based on the user-entered information and the channel being subscribed to by a first connector associated with the billing system;

receiving, by the first connector, the event information;

transforming the event information to a format compatible with the billing system;

publishing the event information to a channel subscribed to by a second connector associated with a database system;

sending, by the database system, an indication that the database system received the event information;

receiving the indication by the first connector;

establishing, by the first connector, communications with the billing system; and

downloading the transformed event information to the billing system.

2. The method of claim 1, fuirther comprising:

writing the transformed event information to a database associated with the billing system.

3. The method of claim 2, further comprising:

sending order-related information, after writing the transformed event information, from the billing system to the first connector; and

forwarding the order-related information to the database system.

4. The method of claim 3, wherein the order-related information comprises a service identifier, the method further comprising:

storing the service identifier in the database system.

5. The method of claim 1, further comprising:

signaling the billing system to not download the transformed event information if the indication is not received by the first connector.

6. The method of claim 1, fturther comprising:

queuing the transformed event information if the first connector is unable to establish communications with the billing system; and

periodically attempting to establish communications with the billing system.

7. The method of claim 6, further comprising:

generating an alarm if communications with the billing system are not established after a predetermined period of time or after a predetermined number of attempts.

8. The method of claim 1, wherein the user-entered information comprises information associated with at least one of account management, order management, service management and bill presentation and the establishing communications with the billing system includes:

establishing communications using remote method invocation over Internet interORB protocol.

9. A computer-readable medium having stored thereon a plurality of sequences of instructions, said sequences of instructions including instructions which, when executed by a processor, cause the processor to:

monitor an input channel for data associated with at least one of adding, deleting and modifying information stored in a billing system;

receive the data associated with at least one of adding, deleting and modifying information stored in the billing system;

format the data based on a type associated with the received data;

forward the data to an operational data storage system;

receive an indication that the operational data storage system received the data;

establish, in response to receiving the indication, communications with the billing system; and

download the formatted data to the billing system.

10. The computer-readable medium of claim 9, including further instructions for causing the processor to:

receive order-related information from the billing system; and

forward the order-related information to the operational data storage system.

11. The computer-readable medium of claim 10, wherein the order-related information comprises a service identifier.

12. The computer-readable medium of claim 9, including further instructions for causing the processor to:

queue the formatted data if the indication is not received.

13. The computer-readable medium of claim 9, including fu~rther instructions for causing the processor to:

queue the formatted data if communications with the billing system are not established; and

periodically attempt to establish communications with the billing system.

14. The computer-readable medium of claim 13, including further instructions for causing the processor to:

generate an alarm if communications with the billing system are not established after a predetermined number of attempts or after a predetermined period of time.

15. The computer-readable medium of claim 9, wherein the data associated with at least one of adding, deleting and modifying information stored in the billing system comprises information associated with at least one of account management, order management, service management and bill presentation and when establishing communications with the billing system, the instructions cause the processor to:

establish communications using remote method invocation over Internet interORB protocol.

16. A support system, comprising:

a memory configured to store an application program to integrate a number of hardware platforms; and

a processor configured to execute the application program and:

receive input data,

output event information associated with the input data to a channel subscribed to by a first connector associated with a billing system,

transform the data into an appropriate format for the billing system based on a type associated with the input data,

forward the data to an operational data storage system,

receive an indication that the operational data storage system received the data,

establish communications with the billing system, in response to receiving the indication, and

download the transformed data to the billing system.

17. The support system of claim 16, wherein the processor is further configured to:

receive order-related information from the billing system, and

forward the order-related information to the operational data storage system.

18. The support system of claim 17, wherein the order-related information comprises a service identifier associated with a service to which a user wishes to subscribe.

19. The support system of claim 16, wherein the processor is further configured to:

queue the event if communications with the billing system cannot be established, and

periodically attempt to establish communications with the billing system.

20. The support system of claim 19, wherein the processor is further configured to:

generate an alarm if communications with the billing system are not established after a predetermined period of time or after a predetermined number of attempts.

21. The support system of claim 16, wherein the user-entered information comprises information associated with at least one of account management, order management, service management and bill presentation and when establishing communications with the billing system, the processor is configured to:

22. A software-based connector for communicating between an integration platform and a billing system using remote method invocation over Internet inter-ORB protocol (RMI over IIOP), the connector comprising:

a transformer module configured to:

receive input information associated with a request for information from the billing system,

identify an opcode corresponding to the request, and

format the request to include the identified opcode; and

a client module configured to:

establish communications with the billing system,

transmit the formatted request to the billing system, and

receive information from the billing system in response to the request.

23. The software-based connector of claim 22, wherein the transformer module is further configured to:

receive event information associated with at least one of a request to change a plan associated with a service or a request for a new service,

transform the event information into an appropriate format, and

output information associated with the received event information to a channel subscribed to by a connector associated with at least one other system.

24. The software-based connector of claim 23, wherein the at least one other system comprises an operational data storage system and the client module is further configured to:

receive a message from the operational data storage system when the operational data storage system has received the information,

establish communications with the billing system in response to receiving the message, and

download the transformed event information to the billing system.

25. The software-based connector of claim 24, wherein the client module is further configured to:

queue the transformed event information if communications with the billing system cannot be established, and

periodically attempt to establish communications with the billing system.

26. The software-based connector of claim 22, wherein the received input information comprises at least one of a request for account information associated with a customer, a request for charge information associated with a customer and a request for service information associated with a customer.

27. The software-based connector of claim 23, wherein the event information comprises information associated with at least one of account management, order management, service management and bill presentation.