[go: up one dir, main page]

WO2003038562A2 - Systeme et procede de fourniture de services de reseau - Google Patents

Systeme et procede de fourniture de services de reseau Download PDF

Info

Publication number
WO2003038562A2
WO2003038562A2 PCT/US2002/034915 US0234915W WO03038562A2 WO 2003038562 A2 WO2003038562 A2 WO 2003038562A2 US 0234915 W US0234915 W US 0234915W WO 03038562 A2 WO03038562 A2 WO 03038562A2
Authority
WO
WIPO (PCT)
Prior art keywords
network
service
services
user
providers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2002/034915
Other languages
English (en)
Other versions
WO2003038562A3 (fr
Inventor
Steven J. Borelli
Sally Elizabeth Else
Patrick C. Davies
Ranbir Chawla
Randall W. Cardinal
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CSG Systems Inc
Original Assignee
CSG Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/992,379 external-priority patent/US7917394B2/en
Application filed by CSG Systems Inc filed Critical CSG Systems Inc
Priority to AU2002336701A priority Critical patent/AU2002336701A1/en
Publication of WO2003038562A2 publication Critical patent/WO2003038562A2/fr
Publication of WO2003038562A3 publication Critical patent/WO2003038562A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

  • This invention relates generally to networks and, more particularly, relates to a system and method for provisioning network services.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.)
  • FIG. 1 illustrates an exemplary network in which the principles of the subject invention may be utilized.
  • the network includes one or more Internet Service Providers ("ISPs"), Broadband Content/Service Providers ("BCPs/BSPs”), and an Open Access Broker.
  • ISPs Internet Service Providers
  • BCPs/BSPs Broadband Content/Service Providers
  • 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.
  • 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.
  • the computer executable instructions may include routines, programs, objects, components, and/or data structures that perform particular tasks.
  • 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.
  • 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.
  • the general purpose computing devices may include a network interface or adapter.
  • the general purpose computing devices 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.
  • 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.
  • 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.
  • 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).
  • MSMQ Microsoft message queue
  • the system described hereinafter is suited for both HTTP/HTTPS, message-queuing systems, and other communications transport protocol technologies.
  • the physical network may embrace and utilize multiple communication protocol technologies. Exemplary System Methods
  • 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 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.
  • 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).
  • FIG. 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 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).
  • FIG. 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 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.
  • 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.
  • 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.
  • 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.
  • the Identiy manager uses XML APIs or interfaces provided by the Network Provider to create the necessary authentication entries.
  • 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.
  • FIG 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
  • 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.
  • 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).
  • the provisioning manager 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.
  • the customer 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.
  • the Identity manager will refer to the product catalog to determine the vendors and specific services that need a user identifier.
  • XML API's or interfaces provided by the Network Provider, it communicates with the Network Provider's systems to create the necessary authentication entries.
  • 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).
  • the provisioning manager 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.
  • FIG 8 an exemplary method for registering and provisioning via a network provider CSR is illustrated.
  • the customer Once the customer has determined that service is available and reviewed their options (see Fig. 4), they select the appropriate plan.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 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:
  • 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.
  • 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.
  • address data is formatted to a standard used by the USPS. This data is then processed according the type of service being queried.
  • HFC Network Hybrid Fiber Cable Network
  • a 'Homes Passed' database This database is populated and maintained by the Network provider, and is considered to be very accurate.
  • 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.
  • 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).
  • CO Central Office
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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].
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the DHCP server 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
  • IP Over-Allocation Rating Event 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système et un procédé de fourniture de services accessibles via un réseau à large bande. Le système reçoit une sélection par un utilisateur d'un ou de plusieurs services/produits accessibles via le réseau, ainsi que les informations d'inscription de l'utilisateur. Les informations d'inscription de l'utilisateur peuvent comprendre des informations relatives à la facturation et un identifiant utilisateur, tel qu'un nom de connexion ou une adresse de courrier électronique. Ensuite, le système authentifie l'identité de l'utilisateur avec un fournisseur de services Internet, puis, il communique l'identifiant utilisateur à chaque prestataire de chaque service/produit sélectionné. Les informations d'inscription et les informations concernant n'importe quel service/produit sélectionné sont également communiquées à un moteur de facturation. Ainsi, un utilisateur peut accéder à chaque produit ou service, et recevoir une facture correspondante.
PCT/US2002/034915 2001-10-31 2002-10-31 Systeme et procede de fourniture de services de reseau Ceased WO2003038562A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002336701A AU2002336701A1 (en) 2001-10-31 2002-10-31 System and method for provisioning network services

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US33536401P 2001-10-31 2001-10-31
US60/335,364 2001-10-31
US09/992,379 US7917394B2 (en) 2001-11-19 2001-11-19 System and method for providing access to network services
US09/992,379 2001-11-19

Publications (2)

Publication Number Publication Date
WO2003038562A2 true WO2003038562A2 (fr) 2003-05-08
WO2003038562A3 WO2003038562A3 (fr) 2003-07-24

Family

ID=26989661

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/034915 Ceased WO2003038562A2 (fr) 2001-10-31 2002-10-31 Systeme et procede de fourniture de services de reseau

Country Status (2)

Country Link
AU (1) AU2002336701A1 (fr)
WO (1) WO2003038562A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011163038A3 (fr) * 2010-06-22 2012-02-23 Microsoft Corporation Contrôles d'accès aux services en ligne au moyen de fonctions de répertoire évolutives
US8782025B2 (en) 2009-03-10 2014-07-15 Ims Software Services Ltd. Systems and methods for address intelligence

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4872158A (en) * 1988-03-31 1989-10-03 American Telephone And Telegraph Company, At&T Bell Laboratories Distributed control rapid connection circuit switch
US6182054B1 (en) * 1998-09-04 2001-01-30 Daleen Technologies, Inc. Dynamically configurable and extensible rating engine

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782025B2 (en) 2009-03-10 2014-07-15 Ims Software Services Ltd. Systems and methods for address intelligence
WO2011163038A3 (fr) * 2010-06-22 2012-02-23 Microsoft Corporation Contrôles d'accès aux services en ligne au moyen de fonctions de répertoire évolutives
US8782748B2 (en) 2010-06-22 2014-07-15 Microsoft Corporation Online service access controls using scale out directory features
RU2598324C2 (ru) * 2010-06-22 2016-09-20 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Средства управления доступом к онлайновой службе с использованием внемасштабных признаков каталога

Also Published As

Publication number Publication date
AU2002336701A1 (en) 2003-05-12
WO2003038562A3 (fr) 2003-07-24

Similar Documents

Publication Publication Date Title
US7917394B2 (en) System and method for providing access to network services
US11947607B2 (en) Methods and computer-readable media for enabling secure online transactions with simplified user experience
US7792745B2 (en) Method and system to facilitate financial settlement of service access transactions between multiple parties
JP4386582B2 (ja) 通信ネットワーク
US6950407B1 (en) Method and system for providing settlement of interconnected packet-switched networks
US6343277B1 (en) Energy network commerce system
US20010034677A1 (en) Method and system to normalize transaction data pertaining to accesses to a service provided via a plurality of service providers
CN1757025B (zh) 利用显式服务授权为网络服务提供预付费计费的方法和装置
AU741703B2 (en) Implementation of access service
US7636324B2 (en) System and method for automated provisioning of inter-provider internet protocol telecommunication services
WO2008097549A1 (fr) Système et procédés pour que des abonnés itinérants réapprovisionnent des comptes de valeur stockée
US20010034693A1 (en) Method and system to broker a service access transaction
EP1573418A3 (fr) Transactions entre commer ants et clients utilisant une plateforme pousser-tirer
WO2007014255A2 (fr) Cadre de paiement reseau
US20050197867A1 (en) Method and system for managing transactions in a remote network access system
EP1738322A2 (fr) Systeme de passerelle pour contenu intermediaire et procede correspondant
WO2001037509A2 (fr) Parquet boursier virtuel et agents intelligents pour produits et services de telecommunications
WO2001017182A1 (fr) Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre
WO2003038562A2 (fr) Systeme et procede de fourniture de services de reseau
WO2001017183A1 (fr) Systeme, procede et article de fabrication destines a la negociation automatique d'un contrat lors d'une transaction impliquant une certaine largeur de bande
JP2004517415A (ja) カスタマに構成可能なサービスを提供するシステム及び方法
WO2001082021A2 (fr) Systeme et procede de simplification de la negociation de largeur de bande
Stiller et al. Pre-study on “Customer Care, Accounting, Charging, Billing, and Pricing”
Rajala Service provisioning in IP/ATM Network
CN101183441A (zh) 企业信息化管理系统中增值业务的管理方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP