WO2003038562A2

WO2003038562A2 - System and method for provisioning network services

Info

Publication number: WO2003038562A2
Application number: PCT/US2002/034915
Authority: WO
Inventors: Steven J. Borelli; Sally Elizabeth Else; Patrick C. Davies; Ranbir Chawla; Randall W. Cardinal
Original assignee: Csg Systems, Inc.
Priority date: 2001-10-31
Filing date: 2002-10-31
Publication date: 2003-05-08
Also published as: AU2002336701A1; WO2003038562A3

Abstract

A system and method for provisioning services accessible via a broadband network. The system receives a user selection of one or more services/products that have been deemed to be available to the user via the network as well as user registration information. The user registration information may include billing information and a user identifier such as a login id or email address. The system then authenticates the identity of the user with an ISP and communicates the user identifier to each provider of each selected service/product. The registration information and information representative of any selected service/product or service is also communicated to a billing engine. In this manner, a user may access each product or service and be billed appropriately for its usage.

Description

SYSTEM AND METHOD FOR PROVISIONING NETWORK SERVICES

BACKGROUND OF THE INVENTION This invention relates generally to networks and, more particularly, relates to a system and method for provisioning network services.

A growing demand for high bandwidth access to the Internet has resulted in a number of potential access methods, the most popular being Digital Subscriber Line service offered by LECs and HFC networks offered by the major cable companies. With some exceptions, network providers do not offer the full suite of services users have come to expect from their dial-up Internet Service Providers ("ISPs"), such as email, web hosting and, most importantly, technical support to facilitate connectivity to the network. Consumers are therefore reluctant to leave their current ISPs and services, since changing email and web addresses can be quite difficult. Lastly, ISPs have also proven to be better at marketing to consumers. An ideal solution for DSL providers was to allow ISPs to market and sell bandwidth to customers with the ISP providing their current suite of services. Current implementations are both DSL provider and ISP provider specific. However, the operational costs of maintaining the geometric growth in interfaces threatens the long- term economic viability of these implementations. Meanwhile, the cable HFC network has remained somewhat more closed, due to lack of infrastructure in the case of smaller franchises, and a competitive offering in the case of AT&T and Time Warner (@Home and AOL respectively). As the operators of these HFC networks begin the process of opening their networks to multiple ISPs the same issues and problems will arise in this industry. An additional concern for ISPs is the negative profit margin they realize from some high-speed data offerings. The high operational costs combined with the high prices of network access charged by the network providers assure that simply offering access, email, and technical support will not suffice as a long term business model in a broadband environment. To survive, the ISPs must generate high margin, sustainable revenue in the form of additional services and products offered to high bandwidth customers. Examples of these types of additional services are music downloads, network disk storage, file backup services, etc. However, creating order entry, provisioning and rating capabilities across a large number of service providers adds another layer of operational complexity and increases the time to market for offering these types of new services. These costs can become so high as to prohibit ISPs from realizing this type of revenue. Small service providers will also have a much higher cost of entry into this market due to the number of disparate interfaces that need to be created to reach all their potential customers. In an attempt to solve some of these problems efforts are underway to develop standards for the creation of the necessary interfaces via the CableLabs' s B2B effort. Furthermore, various venders in the EAI and network spaces offer partial solutions using their software products to try and achieve a pseudo-standard interface to each provider/partner. These solutions, however, focus only on user qualification, order entry and basic provisioning. Complex product catalogs and usage rating are not being considered. Accordingly, presently contemplated solutions will not remove the operational complexity that results from a system having interconnects and monthly reconciliations with many partners.

Still further, as networks become more complex and grow in size, the issue of IP address space also becomes a critical concern. New IP address space is becoming more and more scarce and, therefore, more valuable. Current industry solutions vary, but most have dealt with this issue by creating a clear delineation of IP space between DSL/HFC networks and ISP assets. While this solution may suffice for the time being, as the Open Access model grows IP address space will become a scarce commodity. As network topologies become more sophisticated it may be possible to assign groups of users IP addresses based on economic factors vs. geographic or network configurations. Nevertheless, current product and pricing models do not accommodate this functionality.

SUMMARY OF THE INVENTION To address these and other deficiencies, a system and method for provisioning services accessible via a broadband network is described. Generally, the system receives a user selection of one or more services/products that have been deemed to be available to the user via the network as well as user registration information. The user registration information may include billing information and a user identifier such as a login id or email address. The system then authenticates the identity of the user with an ISP and communicates the user identifier to each provider of each selected service/product. The registration information and information representative of any selected service/product or service is also communicated to a billing engine. In this manner, a user may access each product or service and be billed appropriately for its usage.

As will become apparent, the subject invention has, among others, the advantage of offering one interface for all connectivity and data flows. ISPs, BSPs and network providers would operate one interface to the system, dramatically reducing their operational costs. ISPs would be able to qualify potential customers across all available network providers to find the best fit from a bandwidth, cost and install time perspective. BSPs would be able negotiate complex revenue share deals with Network providers and ISPs without having to invest in sophisticated in house systems. Still further advantages include:

• Allowing BSPs, NPs, and ISPs to manage one API connection yet conduct business with all members of the consortium.

• Tracking of user identity across systems. (Users have pre-existing ID's they are not willing to give up. Over time the notion of a universal ID that is owned by the customer vs. a Service Provider will become a widely accepted concept.)

• Extending serviceability across all 'users' of the broker, and including IP availability into the equation.

• Bringing in IP management and IP space allocation calculus into the provisioning process.

• Provisioning across multiple providers and services. (A customer purchasing plan A from an ISP would generate multiple provisioning events across a number of providers within the broker network.)

• Facilitating transactions and rating of these transactions simultaneously. (Simply passing transaction messages is a core function, but one that many technologies offer. The difference is the broker system will also apply rating rules to this transaction and generate the necessary events. Example: Purchase of 100^th MP3 may qualify a user for a discount, something that could be tracked with a billing system. But the downloading of this may automatically put the user over their bandwidth quota, potentially changing the cost of the transaction and triggering specific events.) • Ability to support e- Wallet technologies. (As standards emerge for wallet support the broker service will handle the tracking of user purchases and facilitate billing for those purchases.)

A better understanding of the objects, advantages, features, properties and relationships of the invention will be obtained from the following detailed description and accompanying drawings which set forth an illustrative embodiment and which are indicative of the various ways in which the principles of the invention may be employed.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, reference may be had to preferred embodiments shown in the attached figures.

DETAILED DESCRIPTION Turning now to the figures, wherein like reference numerals refer to like elements, there is illustrated a system and method of provisioning network services. While not intended to be limiting, Fig. 1 illustrates an exemplary network in which the principles of the subject invention may be utilized. In this regard, the network includes one or more Internet Service Providers ("ISPs"), Broadband Content/Service Providers ("BCPs/BSPs"), and an Open Access Broker. As will be described in greater detail below, the Open Access Broker performs various tasks including those tasks associated with qualifying customers, registering customers, provisioning services, allocating IP addresses, and rating usage.

The ISPs, BC/SPs, and the Open Access Broker generally reside on one or more general purpose computing devices which operate under the control of computer executable instructions. Those of skill in the art will appreciate that the general purpose computing device need not be limited to computers and servers but may include hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Furthermore, the computer executable instructions may include routines, programs, objects, components, and/or data structures that perform particular tasks. Within the network, the computer executable instructions may reside on a single general purpose computing device or the tasks performed by the computer executable instructions may be distributed among a plurality of the general purpose computing devices.

For performing the tasks in accordance with the computer executable instructions, the general purpose computing devices preferably include one or more of a video adapter, a processing unit, a system memory, and a system bus that couples the video adapter and the system memory to the processing unit. The video adapter allows the computing devices to support a display, such as a cathode ray tube ("CRT"), a liquid crystal display ("LCD"), a flat screen monitor, a touch screen monitor or similar means for displaying textual and graphical data to a user. The display allows a user to view, enter, and/or edit information that is relevant to the operation of the system.

The system memory in the general purpose computing devices may include read only memory ("ROM") and/or random access memory ("RAM"). The general purpose computing devices may also include a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from and writing to a magnetic disk, and/or an optical disk drive for reading from and writing to a removable optical disk. The hard disk drive, magnetic disk drive, and optical disk drive may be connected to the system bus by a hard disk drive interface, a magnetic disk drive interface, and an optical disk drive interface, respectively. The drives and their associated computer-readable media provide non- volatile storage of computer readable instructions, data structures, program modules and other data for the general purpose computing devices.

To connect the general purpose computing devices within the network, the general purpose computing devices may include a network interface or adapter. When used in a wide area network, such as the Internet, the general purpose computing devices typically include a modem or similar device which functions in the same manner as the network interface. The modem, which may be internal or external, may be connected to the system bus via an external port interface. It will be appreciated that the described network connections are exemplary and that other means of establishing a communications link between the general computing devices may be used. For example, a wireless access interface that receives and processes information from the general purpose computing devices via a wireless communications medium, such as, cellular communication technology, satellite communication technology, blue tooth technology, WAP technology, or similar means of wireless communication can be utilized.

To provide network security, the network may also utilize security techniques that have become customary when conducting electronic business. These security techniques include, but are not limited to, firewalls, encryption, authentication certificates, directory-based user registration and security management, etc. Because the capabilities and best practices of network communication security are constantly evolving and improving, this document does not espouse the use of any particular technique, technology or product. Rather, it simply specifies that the network architecture should support the use of security practices necessary to protect the business interests of the participants and to insure the overall integrity and confidentiality of information within the system.

For exchanging information between the partners within the network any networking protocol can be utilized. For example, it is contemplated that communications can be performed using TCP/IP. Generally, HTTP and HTTPS are utilized on top of TCP/IP as the message transport envelope. These two protocols are able to deal with firewall technology better than other message management techniques. However, partners may choose to use a message-queuing system instead of HTTP and HTTPS if greater communications reliability is needed. An example of a message queuing system is IBM's MQ-Series or the Microsoft message queue (MSMQ). The system described hereinafter is suited for both HTTP/HTTPS, message-queuing systems, and other communications transport protocol technologies. Furthermore, depending on the differing business and technical requirements of the various partners within the system, the physical network may embrace and utilize multiple communication protocol technologies. Exemplary System Methods

Turning to Fig. 2, an exemplary qualification process using an ISP's Web system is illustrated. The customer uses a web browser to access an ISP's website and uses information on that site to navigate to a page that allows them to determine if broadband access is available in their area (1). The ISP's order entry system utilizes the XML API to query the Qualification Module with information entered by the customer such as, by way of example one, name, physical address, current phone #, etc. (2). The Qualification Module then searches in its service database to determine if any services are available at that location. If there are no services available, this is relayed by to the ISP systems (7) to be forwarded to the customer.

If there are services available, a query is made to the Product Catalog Server (3) to retrieve a list of offerings available at this location for this class of customer (4). While the customer may qualify for access to a Network Provider's network, it is possible that the provider may not have the necessary capacity from a switch, router, or head end or IP address stand point to offer the service. Given scarcity of resources it is also possible that that a provider may prioritize access to the network, offering these resources to certain high end plans for large customers, businesses, etc. (5). If a determination is made that an offering is not available due to resource constraints, it will be flagged and an error message sent to the appropriate entity informing them of the problem. The plan may still be included in the list that is returned to the ISP, but flagged as unavailable due to resource constraints. Each ISP will process this information differently, depending on their own internal policies. For example, an ISP may maintain their own waiting list of customers interested in DSL service and periodically check that availability on behalf of customers. The ISP may also choose to simply not display this option to the user, only showing those plans that are immediately available. How these business rules are determined and implemented is outside the scope of this document. Once each plan has been checked against the IP Address/Network DB, the list is forwarded to the ISP's systems where the data is parsed and displayed on the ISP's Website for the customer (7).

Turning to Figure 3, an exemplary qualification process using client software of a Network provider or ISP is illustrated. Customers can install a newly received client software package or be prompted via an advertising/marketing message to upgrade to broadband access. The customer will, as part of this signup process or in response to an ad, bring up an initial qualification screen on their PC (1). The customer may then enter the necessary information into the client software package, and the software package may also scan the PC to determine the physical attributes of the machine for use during the qualification process. These attributes would include processor speed, availability of a wireline or wireless network interface and other relevant data.

The software package then makes a connection to the provider's OSS systems using the provider's protocol. The provider's order entry system utilizes the XML API to query the Qualification module with information entered by the customer (2). The qualification server then searches in its service database to determine if any services are available at that location. If there are no services available, this is relayed by to the ISP systems (7) to be forwarded to the customer. If there are services available a query is made to the product catalog server to retrieve a list of offerings available at this location for this class of customer (4). A check is then made to make certain that network facilities are available given each particular plan (5). The complete response is forwarded to the ISP's systems where the data is parsed and then passed via the provider's protocol to the client software on the PC (7). These latter steps are in keeping with the description set forth above with respect to Fig. 2. Turing to Figure 4, an exemplary method for qualifying a customer using a customer service representative ("CSR") of a Network provider or ISP is illustrated. A customer calls the provider call center and speaks to a CSR. The CSR then uses the providers CRM system to take basic information from the customer(l). The provider's CRM system utilizes the XML API to query the Qualification module with information entered by the customer (2). The qualification server then searches in its service database to determine if any services are available at that location. If there are no services available, this is relayed by to the ISP systems (7) to be forwarded to the customer. If there are services available a query is made to the product catalog server to retrieve a list of offerings available at this location for this class of customer (4). A check is then made to make certain that network facilities are available given each particular plan (5). The complete response is forwarded to the ISP's systems where the data is parsed and then passed via the provider's protocol to the client software on the PC (7). These latter steps are in keeping with the description set forth above with respect to Fig. 2. The CSR may then relay the information to the customer. Turning to Figure 5, an exemplary method for registering and provisioning via an ISP Web system is illustrated. Once the customer has determined that service is available and has reviewed their options (see Fig. 2), they navigate the ISP's website and select a product or service to purchase. The customer is then asked to enter the necessary billing and contact information. The billing and contact information is determined by the product catalog and the credit and business rules of the providers offering products within the chosen plan. Next the customer is offered the opportunity to chose a login id/email username. The order entry system will check this choice against the ISP's authentication/name database. The exact composition of the database is under the control of the ISP, but at a minimum it will contain a username/password pair for network login and any other services such as email offered by the ISP. Additions and changes to this data are made via the ISP's internal systems, with information flowing from the ISP's external systems as well as the OA Broker system. If the product or service choice made by the customer is available, the information collected will be forwarded to the Open Access broker using the standard XML API's (2). The Open Access Broker will directly enter the username choice in the Identity/Service DB since it is already checked against the ISP's master authentication database. This name will be unique if it is stored in the full form of username@domain. This username will become the unique identifier for the user across all vendors and services [see the detailed information on the Identity DB for more detail]. The identity may be registered with the other providers if possible. The Identity manager will refer to the product catalog to determine the vendors and specific services that need a user identifier. If a user identifier is not need, usage could tracked using MAC address<-> Unique ID relationships.

Using XML APIs or interfaces provided by the Network Provider, the Identiy manager communicates with the Network Provider's systems to create the necessary authentication entries. Using the XML API's, the identity information will also be forwarded to the service providers listed in the plan via the Provisioning manager. If the identity currently exists on the service providers system an error condition is not created, but the service provider will be notified that this user is now being rated as part of this overall Open Access plan. If the identity does not exist, it will be created.

The registration information is then forwarded to the Core Billing and Financial engine where the customer's record is created if there is not a current entry for this customer. If the customer currently has a service provided by the network provider, their record will be updated to reflect the new services purchased (5). The information provided will be an agreed upon set of data. The information will also be forwarded to the Network provider's billing system (5) and the Provisioning Manager (5). While it is noted that customer related information has already been forwarded to the provision manager (see Fig. 2) and that it is possible to package all the relevant data to the provisioning manager in this one step, breaking the transfer of information into two discrete operations has the advantage of making it possible to determine the users identity info before provisioning information is sent out. This simplifies the second step of actually provisioning those systems. The provisioning manager will use data from the product catalog and the IP Address rules server to determine the proper IP subnet(s) for the plan selected. If multiple subnets are returned then the network provider's allocation mechanism is responsible for handling the selection of the appropriate subnet during the DHCP lease request process (6). The Provisioning Manager will then refer to the product catalog for the list of discrete services that need to be configured to complete the customer's registration process. For each step in the process the provisioning system will further break down these steps into concrete provisioning actions at a provider/device level, and complete the necessary steps to provision the user within the ISP's and Network provider's networks (8). If providers require custom software installs, this is noted and returned to the ISP website as a complete list to be executed by the ISP's systems (9). The completed list of providers and all identity/download information is returned as an XML message to the ISP systems to be processed by the ISP. The ISP handles the presentation of this information. Turning to Figure 6, an exemplary method for registering and provisioning using client software supplied by an ISP is shown. Once the customer has determined that service is available and reviewed their options (see Fig. 3), the client software will display the options available and request that the user select a plan (1). After entering in the necessary billing and contact information they are offered the opportunity to chose a login id/email username. The client software will use the ISP's internal methodologies to check this choice against the ISP's authentication/name database. If this choice is available the information collected will be forwarded to the ISP's internal systems and then to OA broker using the standard XML API's (2)

The OA Broker will register the username choice in the Identity/Service DB. This name will be unique if it is stored in the full form of username(a).domain. This username will become the unique identifier for the user across all vendors and services. The Identity manager will refer to the product catalog to determine the vendors and specific services that need a user identifier. Using XML APIs or interfaces provided by the Network Provider, it communicates with the Network Provider's systems to create the necessary authentication entries. Using the XML

API's, the identity information will also be forwarded to the service providers listed in the plan via the Provisioning manager. If the identity currently exists on the service providers system an error condition is not created, but the service provider will be notified that this user is now being rated as part of this overall Open Access plan. If the identity does not exist, it will be created. Any .new identifiers created are noted so that they can be returned to the customer for later reconciliation (see the description with respect to Fig. 6).

The registration information is then forwarded to the Core Billing and Financial engine where the customer's record is created if there is not a current entry for this customer. If the customer currently has a service provided by the network provider their record will be updated to reflect the new services purchased (5). The information will also be forwarded to the Network provider's billing system (5) and the Provisioning Manager (5). The provisioning manager will use data from the product catalog and the IP Address rules server to determine the proper IP subnet(s) for the plan selected. If multiple subnets are returned then the network provider's allocation mechanism is responsible for handling the selection of the appropriate subnet during the DHCP lease request process (6). The Provisioning Manager will then refer to the product catalog for the list of provisioning steps to be taken for the plan selected by the customer. For each step in the process the provisioning system will further break down these steps into concrete provisioning events (7) and using a variety of technologies to communicate with network gear within the ISP's and Network provider's networks (8). Using information received during the user identity creation process the provisioning manager will register customers with all service providers listed in the plan. If providers require custom software installs, this is noted and returned to the ISP website as a complete list to be executed by the ISP's systems (9). The completed list of providers and all identity/download information is returned as an XML message to the ISP systems to be processed by the ISP. The ISP handles the presentation of this information. Turning now to Figure 1, an exemplary method for registering and provisioning via an ISP CSR is illustrated. Once the customer has determined that service is available and reviewed their options (see Fig. 4), they select the appropriate plan. After the CSR's gathers the necessary billing and contact information the customer is offered the opportunity to select a login id/email username. The order entry system will check this choice against the ISP's authentication/name database. If this choice is available all the information collected by the ISP's CRM system will be forwarded to the OA broker using the standard XML API's (2).

The OA Broker will register the username choice in the Identity/Service DB.

This name will be unique if it is stored in the full form of usernamefajdomain. This username will become the unique identifier for the user across all vendors and services. The Identity manager will refer to the product catalog to determine the vendors and specific services that need a user identifier. Using XML API's or interfaces provided by the Network Provider, it communicates with the Network Provider's systems to create the necessary authentication entries. Using the XML

API's, the identity information will also be forwarded to the service providers listed in the plan via the Provisioning manager. If the identity currently exists on the service providers system an error condition is not created, but the service provider will be notified that this user is now being rated as part of this overall Open Access plan. If the identity does not exist, it will be created. Any new identifiers created are noted so that they can be returned to the customer for later reconciliation as described above.

The registration information is then forwarded to the Core Billing and Financial engine where the customer's record is created if there is not a current entry for this customer. If the customer currently has a service provided by the network provider their record will be updated to reflect the new services purchased (5). The information will also be forwarded to the Network provider's billing system (5) and the Provisioning Manager (5). The provisioning manager will use data from the product catalog and the IP Address rules server to determine the proper IP subnet(s) for the plan selected. If multiple subnets are returned then the network provider's allocation mechanism is responsible for handling the selection of the appropriate subnet during the DHCP lease request process (6).

The Provisioning Manager will then refer to the product catalog for the list of provisioning steps to be taken for the plan selected by the customer. For each step in the process the provisioning system will further break down these steps into concrete provisioning events (7) and using a variety of technologies to communicate with network gear within the ISP's and Network provider's networks (8). Using information received during the user identity creation process, the provisioning manager will register customers with all service providers listed in the plan. If providers require custom software installs, this is noted and returned to the ISP website as a complete list to be executed by the ISP's systems (9). The completed list of providers and all identity/download information is returned as an XML message to the ISP systems to be processed by the ISP. The ISP handles the presentation of this information. Turning to Figure 8, an exemplary method for registering and provisioning via a network provider CSR is illustrated. Once the customer has determined that service is available and reviewed their options (see Fig. 4), they select the appropriate plan. After the CSR's gathers the necessary billing and contact information the customer is offered the opportunity to choose a login id/email username. The order entry system will forward the selection to the OA Broker User ID Server via the XML API's (2). The User Manager communicates with the ISP's authentication DB via standard XML API's to determine if the selection is available and unique. Optionally, the Network Provider can create and assign a unique id to the customer that is valid or required for their network systems. The customer will still chose an email username that will be used as the unique ID across the entire Open Access system (3)/(4).

If the email name selected is not available, the OA Broker communicates this to the Network provider systems and the process is repeated until the user chooses a name that is unique. The user may also determine that the lack of availability of a desired name makes their current ISP choice unacceptable. Given that, the CSR can then offer them the alternative plans that are available for their location and begin the process again.

Once a name has been selected, the complete packet of registration information is forwarded to the OA Broker system using the XML API's (3). The OA Broker will register the username choice in the Identity/Service DB. This name will be unique if it is stored in the full form of username®, domain. This username will become the unique identifier for the user across all vendors and services. The Identity manager will refer to the product catalog to determine the vendors and specific services that need a user identifier. Using XML APIs or interfaces provided by the ISP, it communicates with the ISP's systems to create the necessary authentication entries. The Network Providers system may have already created the necessary entries in their system before forwarding the registration to the OA Broker. If this is not the case, the ID will be created using the standard XML API's. Using the XML API's, the identity information will also be forwarded to the service providers listed in the plan via the Provisioning manager. If the identity currently exists on the service providers system an error condition is not created, but the service provider will be notified that this user is now being rated as part of this overall Open Access plan. If the identity does not exist, it will be created. Any new identifiers created are noted so that they can be returned to the customer for later reconciliation as described above. The registration information is then forwarded to the Core Billing and Financial engine where the customer's record is created if there is not a current entry for this customer. If the customer currently has a service provided by the network provider their record will be updated to reflect the new services purchased (5). The information will also be forwarded to the Network provider's billing system (5) and the Provisioning Manager (5). The provisioning manager will use data from the product catalog and the IP Address rules server to determine the proper IP subnet(s) for the plan selected. If multiple subnets are returned then the network provider's allocation mechanism is responsible for handling the selection of the appropriate subnet during the DHCP lease request process (6).

The Provisioning Manager will then refer to the product catalog for the list of provisioning steps to be taken for the plan selected by the customer. For each step in the process the provisioning system will further break down these steps into concrete provisioning events (7) and using a variety of technologies communicate with network gear within the ISP's and Network provider's networks (8). Using information received during the user identity creation process the provisioning manager will register customers with all service providers listed in the plan, including the ISP's systems. If required the Provisioning Manager will provision low level services at the ISP level such as Radius or Email, or the ISP's systems will receive a summary packet of provisioning information for further processing. This is determined by each ISP. If providers require custom software installs, this is noted and returned to the Network Provider CSR and to the ISP's systems. The completed list of providers and all identity/download information is returned as an XML message to the Network Provider. Turning to Figure 9, an exemplary method for rating purchases is illustrated.

Users purchasing a service or product from a BSP trigger a rating event that is sent by the BSP to the Open Access Broker (1). This event contains the user's identity, the amount purchase, and the product or service purchase by pre-determined category. Each event can be processed individually as follows: If an user identifier is included as part of the rating event, the rating engine will query to User ID to determine the master unique id that is associated with this user (2). The rating engine will then query the product catalog for rating guidelines that apply for the product or service purchased by the user (3). After rating the event, the information is passed to the OA Broker Core Financial/Billing Engine, the Network Provider and the ISP's billing system for the purposes of later reconciliation

(4).

Turning to Figure 10, there is illustrated an exemplary method for rating network usage. Users purchasing a service or product from a BSP trigger a rating event that is sent by the BSP to the OA Broker (1). This event contains the user's identity, the amount purchase, and the product or service purchase by pre-determined category. Each event can be processed individually as follows:

If an user identifier is included as part of the rating event, the rating engine will query the User ID to determine the master unique id that is associated with this user (3). The rating engine will then query the product catalog for rating guidelines that apply for the plan selected by the user (4). A query is made against the IP Address Rules Server to determine if there are any further guidelines that apply to the IP address passed as part of this event. After rating the event, the information is passed to the OA Broker Core Financial/Billing Engine, the Network Provider and the ISP's billing system for the purposes of later reconciliation. Exemplary System Components

The qualification module is used to determine if a physical location or address is capable of receiving broadband data services. The factors used to make this decision are different for each type of service, as is the dependability of the answer. Using a standard address rationalization or 'scrubbing' package, address data is formatted to a standard used by the USPS. This data is then processed according the type of service being queried.

For example, for data services over a Hybrid Fiber Cable Network (HFC Network) each location capable of connecting to this network is stored in a 'Homes Passed' database. This database is populated and maintained by the Network provider, and is considered to be very accurate. To determine if a location is servicable, the Homes Passed DB is queried. If the location is found, the service is available. Often the DB will also contain information relating the bandwidth available on the sub-network connected to the location. This information is passed with the answer to allow the Broker to query the Product Catalog for more details on each type of service offered.

In the case of Digital Subscriber Line services the location to be serviced must be within a fixed distance from the Central Office ("CO") where DSL and standard telephony switching equipment is located (the distance will vary by the type of DSL being offered and the technologies employed for delivery). The calculation of this distance is based on an algorithm supplied by the network provider. The first step is to determine the CO that services the location in question using a provider supplied database and query methodology (this could vary across providers). Once that is determined the distance is calculated using the provider supplied algorithm. If the location is within the maximum allowed distance the location is marked as serviceable.

Given that the exact distance can vary depending on network topology and quality of transmission lines and other gear, a positive qualification answer is not 100% dependable and must be confirmed with a physical visit to the site in some cases. The determination of the CO will also influence the types of DSL offered in terms of bandwidth and IP address availability. This data is passed along with the qualification response to the Product Catalog in the same manner as HFC qualifications.

Qualification for satellite or fixed wireless services can depend on distance from a central transmission node, intervening geography and orientation of the structure to be used to mount the antenna. For most satellite-based services an antenna must have a clear site line in a roughly southern direction that corresponds to the location of a satellite in geosynchronus orbit. If this exists, then the location would qualify for services in most cases. The qualification module may not even be used in this case, rather the user would be prompted to answer basic questions to determine if the factors listed above do actually exist.

Qualification for fixed wireless service requires the antenna to be within a certain distance from the transmission node without large intervening buildings or hills/mountains in the line of site. The fixed wireless network provider would supply the Qualification module data, either at the zipcode+4 level, or a larger 'Homes Passed' database, to be used to determine if the location meets the distance requirement. The final qualification normally made during the installation process. Given that transmission and network gear may vary by location, multiple products may be offered. The types of service available are passed with the response in the same manner as HFC qualifications.

If there are services available a query is made to the product catalog server (3) to retrieve a list of offerings available at this location for this class of customer (4) as illustrated in Figs 2-4. The Product Catalog is used to organize the products and services offered to customers. Providers will use the XML API's or a GUI based tool to access and configure their products and services within the catalog. By way of example, a Network provider offers HFC network coimectivity across their network. The customer can purchase this access with a variety of bandwidth and total usage constraints. The provider may organize these offerings as one product with attributes or as a selection of different products, each with a set of fixed attributes. The catalog can organize and store the product configuration using either methodology. The provider may also offer email or web hosting services. These products are listed as components in the product catalog that can be assembled into a larger offering, or Plan.

Plans can be constructed using the products and services of one provider, or across providers. For example, an ISP may offer the 'High Speed Cable Gold' Plan, which consists of cable HFC network access for up to 3 PC's with a 30 Gigabit bandwidth quota per month, 3 email addresses, 20 free music downloads per month, and 30 MB of online backup. The network access is provided by Network Provider A, the email by the ISP, the music downloads by BSP B, and the online backup by BSP D.

Plans also delineate rating guidelines as appropriate for each service offered within the plan. Using the example list above, the bandwidth quota is 30 GB's of network usage per month. Once this level is exceeded a variety of actions could be taken. The user could be charge for each MB or GB of usage, the network provider may bill another provider for this usage (the ISP in this example), or the user's access could be terminated. The guidelines used will vary by product type. A key component of each plan is the pricing model and the financial settlement rules for that plan. Each plan has a unit or recurring charge to the end customer. How the revenue from the customer's purchase is divided among the various providers and how usage is allocated across these providers is determined by settlement rules outlined in the Plan definition. For each given network access service that is physically available to the customer at their location, there may be many possible product offerings or plans listed in the product catalog. The final determination is based on a number of factors. These factors are listed as part of a product definition in the product catalog. For example, some products may only be available to customers who have entered in a promotional code during the qualification process. Other products may be segmented by geographic region, or by the number of computers a customer wishes to connect to the network. The owner of the product offering creates the final plan definition and business rules that surround it, as well as the settlement rules involved. It should be noted that multi- vendor product configurations would be based on previously negotiated contractual agreements between the providers. How these arrangements are determined is outside the scope of this document.

The Identity/Service database is used to store customer authentication information across all providers for the purposes of tracking usage events and rating these events. Since it is possible for a user to have a different username or login at each service provider, it is necessary to build a database to track these relationships so that usage of these services can be rated and the appropriate financial settlements calculated. One positive consequence of this structure is that customers who do not yet have an identity with a service provider, or are willing to change, can request that the system automatically provision the username across all the selected providers [see the registration process] giving them one username to use vs. many.

Two major types of data are stored for each customer. The first type of data is a collection of data elements that represent the user's login/username data for each provider and/or service purchased by the customer. This information is referenced by an integer key that is unique across the entire customer base. This key is not used by the customer, and remains constant during their entire existence within the database. The customer facing key is a unique username(5),domain combination that is also the primary email address for the customer [the key is unique due to the design of the original Internet domain and email naming standards]. By storing 2 unique keys for each customer it is possible for the system to reconcile changes in the customer's email address by simply changing this entry alone, leaving the integer ID and all other entries unchanged. Also, when customers authenticate against a providers self-care systems they are asked for authentication information in the form of a unique username@domain string. The providers systems can use this key when communicating with the OA Broker system.

The Identity/Service DB is not the master DB for identity data. Since each provider has other sources for this data, their systems will be have to determine the availability of usernames for their service. The Identity/Service DB must communicate with each providers authentication/identity systems to assure that all data is synchronized across providers.

The service component of the database tracks configuration data for each service purchases by the customer. This data will vary depending on the service type, but can include such things as IP subnet allocations, network connection points, and email servers for mail accounts.

One important data point is the MAC address of the customers network gear, whether that is a DSL modem, cable modem, or the wireless termination point. MAC addresses are unique Ethernet network addresses assigned to every node on a network, including routers, DSL/Cable modems and PCs. Since most networks assign IP addresses on a temporary basis it is not always possible to determine the identity of a customer by IP address. MAC addresses can be tracked by network monitoring software to track each packet of information sent by a customer for the purpose of calculating usage and tracking network abuse. The Provisioning Manager is responsible for the physical provisioning of products and services purchased via the Open Acees Broker as well as tracking the status of each of the steps within the provisioning process. For each type of service and system different steps must be taken, and different messaging interfaces used to add, change, and delete a customer within these system. In order to meet this diverse set of requirements the provisioning manager is designed with a central core module surrounded by any number of adapter modules coded to work with specific device interfaces. An exemplary architecture is illustrated in Fig. 11.

The core module consists of a workflow management engine, a business logic layer, and a provisioning rules DB. Workflow procedures are created by the providers using GUI tools and/or the XML API's with the result being the detailed steps and procedures needed to provision their specific services. Providers will specify interface technologies, data elements that must be gathered and passed on to their systems, and the exact order of steps to be taken to complete any single provisioning task. A typical provisioning workflow could function as follows:

The workflow manager receives a request to provision a product for a customer (1). Within that request will be a list of discrete providers and services associated with these providers that comprise the plan purchased by the user. Where appropriate, configuration parameters will be pasted for each service based on the plan definition, an email mailbox size quota, or a bandwidth rate for network access (2). Iterating over this list, the workflow engine will create a service order for each item that is being provisioned. During the creation of the service order the workflow engine will query the provisioning rules DB to retrieve a list of specific systems that must be configured, the appropriate adapters to call to accomplish this task, and the exact data needed by each adapter (3). A service order is created and forwarded to each adapter (4) which is then responsible for interfacing the specific device or system at the designated provider.

If specialized business logic is required that is not available via the core workflow manager, custom provisioning modules are created to handle the event. These modules reside in the business logic layer. When the procedure is being configured for the first time, calls to the custom module are inserted appropriately in the workflow process (5).

If the adapter receives an error message, the message is forwarded to the workflow manager for processing. The workflow engine, using procedures defined by the provider of the relevant service, handles error processing. If provisioning errors are fatal (causing the service to not be provisioned), this information is passed back through the broker to the entity requesting provisioning.

Change orders and cancellations are handled in the same fashion, with the workflow manager breaking down the steps according to predefined procedures and working with the appropriate adapters to facilitate the process. For example, in the case that a user wishes to change a username, either for email or for login, the workflow manager must interact with the Identity manager to track and verify the changes required across all systems. The IP Address Server is responsible for the assignment of a discrete IP

Address, or address range at a network access point level for each access device managed by the OA Broker provisioning system. Each customer system connects to the larger network through a network device, which could be, but is not limited to, a cable modem, DSL router, or a wireless router. These devices can be provisioned with a permanent static IP address or an IP address assigned for a temporary leased basis using DHCP or other IP address assignment technologies. The IP address may be assigned from a pool of addresses managed and owned by a network provider, or a pool managed and owned by an ISP depending on the legal agreements in place between providers and ISPs. As more and more devices are comiected to the world wide IP network, the finite address space will be consumed. Efforts are underway to expand the pool of available addresses using technologies such as 'Ipv6', but these are not fully developed and supported by mainstream network equipment vendors. Adding to the problem is the enormous capital expenditure that will be required to bring all the network equipment and consumer level equipment to this new standard. For that reason it is reasonable to assume that IP address space will continue to be a more scarce resource and, as such, will begin to be treated as an independent economic resource much the same way as bandwidth and access are now. Current methodologies for handling address allocation are based on a temporary leased address model where for each X number of available addresses in Pool Y there are m*X number of end consumer devices eligible to receive an address from the Pool Y. Over time network operators have developed their own algorithms for calculating the appropriate multiplier 'm' that results in each consumer being allocated an address while minimizing the number of pools that a provider must maintain. As a pool of addresses is over allocated a provider must then apply for additional pools of addresses from the appropriate Regional Internet Registries depending on their geographical location. In the United States, for example, the appropriate Registry is ARTN. The registries are non-profit organizations funded by industry participants tasked with maintaining a balanced usage of IP address space. In order to receive a new pool of addresses a provider must show a defined need for the pool and have shown proper diligence in terms of managing it's current resources. As the available pools become scarcer it will become more difficult to receive a new allocation, and as such it will become cost effective to buy under allocated pools from other providers.

As network providers begin to offer access to ISP's the problem becomes moderately more complex. Current arrangements have distinct delineations in place. In some systems the IP address pool used at the consumer end is allocated from the ISP's pool, other times it's allocated from the network provider pool depending on the contractual agreement. These rules apply across the entire network and all access points. This type of blanket arrangement will not work in the long mn as some network subnets become more crowded than others and some pools are exhausted before others. Therefore, the allocation of IP addresses to consumer network devices will become more complex from a business rules standpoint. Also, any system managing the allocation of addresses must now take into account the financial aspects of each allocation transaction, and begin to track the assignment and usage of addresses across providers from a financial reconciliation standpoint.

During the initial customer registration and provisioning process, the IP Address server is responsible for determining if current IP resources exist at a given physical location and network connection point. The IP Address database contains this detailed network topology and IP address subnet allocation data. The data is supplied by network providers during the initial configuration of the system and is modified as network topologies are changed and assets added to the system. This data entry is accomplished either via the published XML API or via the GUI tools provided as part of the Open Access Broker tool set.

What will be needed in the future is an allocation scheme that is flexible enough to lease under-utilized pools to other providers and ISP's for a short time frame [much the same way that energy is managed on the electric grid, or money is lent with Treasury Repo's] within the constraints of the network topology. As an example, Fig. 12 illustrates ISP A which is responsible for allocating the IP addresses for their customers who have purchases Product A. Network Provider X provides the network access component of Product A. Due to a major national news event a larger than normal number of users are attempting to access the network (1) and view online news reports. During this temporary spike in usage ISP A has run out of available IP addresses. Once the DHCP server that is responsible for allocating those addresses detects the condition, it uses an XML API to make a request to the OA Broker for more IP addresses blocks (2). The request block contains a parameter outlining the number of addresses needed, as well as a flag indicating whether the ISP will accept a 3^rd parties IP allocation, and the maximum it will pay for this allocation.

The IP Address Server takes this request and processes it against the business rules outlined previously by the network provider as well as the IP allocation DB (3). If the policy exists to lease addresses temporarily and there are available IP addresses to lease, a positive response is sent back to the ISP's DHCP system with a parameter outlining the subnet that has been allocated, and another parameter outlining the amount of time that these IP addresses can be leased for (4). At the same time the IP

Address Server sends an IP Over-Allocation Rating Event to the rating engine delineating the details of the transaction and the providers involved. This event is processed as any other rating event and the financial charges allocated appropriately during the billing cycle.

If there are not addresses available to allocate from the Network provider's systems, and the ISP has set the 3^rd party flag to 'Yes', the IP Address Server will then check against the IP Address DB (5) to determine if it is possible to allocate another subnet from a different Network Provider and what the cost of this allocation would be. An additional factor is involved in making this decision, as it may not be possible to route traffic from ISP A through network provider X using a different provider. However, if arrangements and routing policies have been put in place at a prior time, it may be possible. The IP Address Server will attempt to find a subnet to allocate given the network topology and financial constraints set by the ISP in the initial request. If it is possible, a response will be sent to the ISP's DHCP system (4). If the ISP has set the 3^rd party flag to 'NO', a message is sent from the IP Address Server to a predestinated email address or wireless paging service to alert the ISP's personnel to the pending problem and direct them to a manual system.

An API will also exist to allow ISP's and network providers to interface their systems directly to the IP Address system. Operators at each site may inquire into the current state of the system, identify potential problems, etc. using this interface and manually request additional addresses before resource constraints trigger automatic events. Using this interface it will be possible for participants to make bids for address allocation and to accept bids. This allows for overrides to the automatic policy limits set in advance to allow for ISP's and network providers to make appropriate business decisions given a larger set of parameters. The Financial/Billing engine is responsible for tracking the financial relationships between customers, their chosen products/services and between providers of these services. In a simple model with one provider and multiple end consumers the billing process is very straightforward. A customer purchases a product/service and incurs a monthly charge and potentially an initial setup charge for installation and equipment. Customers are assigned account numbers and are segregated by provider, and in some cases, by physical locations in order to calculate franchise fees and taxes. Once per month the rating information received for a customer is combined with a monthly rate and a detailed bill is generated. The customer is either sent a detailed statement or their credit card is billed directly depending on the plan and billing methodologies available for the service offered. The accounts receivables for the providers are therefore directly related to the customers.

The billing engine is also responsible for tracking collections and delinquencies. How this is handled is a business policy issue determined by the end user. Some of the actions that could be taken include multiple dunning notices, disconnections of service and accumulations of late charges.

In a new multi-provider environment the process is not as direct. The products offered create a need to track multiple accounts receivable across providers at a customer detail level, as well as at a provider-to-provider level. In a simple example, a customer purchases a basic Internet Access package from ISP A, at a monthly rate of $50 per month for the first 100 GB of total bandwidth used for the month, and a $1 per GB charge for additional traffic, 10 free content downloads per month, and $1.00 per download above that amount. The core access service is provided by Cable provider B, the downloads by Provider C, and the ISP services such as email and website hosting by ISP C. The contractual terms agreed upon by all three providers break down the receivables as follows:

In month one, the customer uses a total of 120 GB of bandwidth and downloads content 15 times. The total charge to the customer is $75.00, which is collected in this instance by Provider A. Provider A then has an account receivable with the customer for $75.00, but must also recognize the Account Payable they have with Providers B and C, in the amounts of $53.75 and $4.5 respectively.

The billing engine interfaces with the Product Catalog module determines the contractual rules and rates for each product/service. The bill for each customer is calculated as it was in the first example. The billing engine now goes an additional step forward to calculate the total amount owed to provider B and Provider C for each customer, and a grand total is then calculated and an invoice generated for provider B and C.

The billing engine can still be used to calculate the appropriate franchise fees and taxes for the totals apportioned to the network provider(s) or the network provider(s) can use their internal systems to complete this aspect of the billing cycle if they do not use the full Open Access Broker billing engine. In the example above the franchise fees and taxes would be calculated for the basic access portion of $37.50 and if applicable, against the $16.25 charged for bandwidth usage.

The billing engine also presents a standard XML API and GUI tools that enable integration of account management functionality with providers current systems. Using these tools a provider can change important customer level information such as credit card numbers, phone numbers, monitor collections and issues credits for service related problems. These same tools can be used by a provider to view a detailed invoice at the end consumer level in order to reconcile invoices for services issued by the billing engine.

While specific embodiments of the invention have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those details could be developed in light of the overall teachings of the disclosure. Accordingly, the particular arrangement disclosed is meant to be illustrative only and not limiting as to the scope of the invention which is to be given the full breadth of the appended claims and any equivalents thereof.

Claims

CLAIMS What is claimed is:

1. In a network, a method for provisioning services comprising: receiving a user selection of one or more products or services that have been deemed to be available to the user via the network; receiving registration information from the user including billing information and a user identifier; authenticating the user identifier with an ISP; communicating the user identifier to each provider of a selected product or service; and communicating the registration information and information representative of each selected product or service to a billing engine; whereafter a user may access each product or service and be billed appropriately for usage.

2. The method as recited in claim 1, further comprising the step of determining if a physical location or address is capable of receiving broadband service before allowing a user to select any products or services.

3. The method as recited in claim 1, further comprising the step of registering the user with a provisioning manager which is responsible for determining if any discrete services are needed by the user to permit access to any select product or service.

4. An Open Access broker system used to facilitate the purchases of services across multiple network and service vendors by end customers, comprising: a standardize interface and API to allow vendors/service providers to develop connections to the system one time and then transact with others using the system; a product catalog of product and service offerings available to end subscribers across multiple Network Providers, Internet Service Providers (ISP's) and Broadband Service Providers (BSP's) organized into an aggregated product offering for presentation to the subscriber, the product catalog tracking financial data, network access data (IP address) and rating guidelines, their point of contact with the system and physical systems qualifications categorizes subscribers, and financial reconciliation rules between vendors on a per plan basis to be used for rating and billing of products and services; a rating engine used to process usage events that flow into the system from network providers and service providers wherein rating data is then summarized across multiple vendors and reconciled between these vendors based on rule sets determined by plans created in the product catalog; an IP address rules server tracking the assignment of IP address subnets across plans and services; and provisioning subsystem responsible for provisioning and de-provisioning of services across networks devices and services in a multiple vendor environment, the provisioning subsystem using information in the product catalog to create a series of provisioning events that are then relayed to individual devices.

5. An Open Access broker system used to facilitate the settlement of accounts for purchases and rating of usage of services across multiple network and service vendors by end customers, comprising: a billing and financial tracking system capable of tracking millions of subscribers and providers wherein financial and usage information can be summarized at the individual subscriber level and the provider level across a collection of subscribers; a financial reconciliation engine to track individual transactions across the Open Access Broker system and handle reconciliation between vendors; a product catalog tracking financial relationships between products and services across multiple vendors; a product catalog tracking rating guidelines for products and services across multiple vendors; a product catalog and IP address rules server tracking the assignment of IP subnets between providers based on network and financial constraints; a modular rating engine capable of rating network usage events, individual purchases, and micro transactions across millions of subscribers, with multiple vendors; and a modular rating engine capable of rating IP address usage for financial reconciliation between multiple vendors.