WO1997024687A1

WO1997024687A1 - Method and apparatus for hierarchical control of a distributed processing network

Info

Publication number: WO1997024687A1
Application number: PCT/US1996/020136
Authority: WO
Inventors: James R. Logan; Kurt Deshazer
Original assignee: Tele-Communications, Inc.
Priority date: 1995-12-29
Filing date: 1996-12-23
Publication date: 1997-07-10
Also published as: AU1294097A

Abstract

A system and method for providing a product to a plurality of customers. The system is accessed by a plurality of users each of which has an authority level, A, = 1 to n, with n being highest. A first device (12) receives n-level parameters from an n-level authority user which define a product, creates an n-level product record comprising the n-level parameters, and stores the n-level product record in a memory. A plurality of second devices (16) receive level 1 parameters from a level (1) authority user which redefine a product having an n-level product record to create a level 1 product record comprising the n-level and the level 1 parameters. A plurality of third devices (18) access the memory to receive one of the level 1 product records and provide a product to a plurality of customers (110) according to the parameters of that level 1 product record.

Description

METHOD AND APPARATUS FOR HIERARCHICAL CONTROL OF A DISTRIBUTED PROCESSING NETWORK

Field Of The Invention The present invention relates generally to the field of computer networks and more specifically, to computer networks for operating customer-oriented systems. More specifically, the present invention relates to a computer network for interconnecting a plurality of cable system providers and other cable system offices. Background Of The Invention

Cable television has become immensely popular over the last several decades. Due to the rapid growth and expansion of this industry, many different entities have participated in establishing local cable systems to meet the growing demand. As such, most local cable systems have different requirements, different equipment, different customer tastes, etc. Almost no two local cable systems are alike and the differences which have resulted from the rapid growth ofthe cable industry have made centralized control over the operations of the local operators a difficult and burdensome task. For example, if a multiple system operator (MSO) owning four local cable systems in four different regions of the country wishes to set pricing information for a particular product, it would have to contact each of the four local cable systems, establish the pricing information, and supervise the local cable systems to ensure that the pricing information for that particular product was properly applied to the customers. This is just one example of many in which monitoring and controlling operations of the MSO's perspective is burdensome under the present systems.

These problems are exacerbated in more complex MSO structures in which a main MSO office may oversee a plurality of regional offices which may oversee a plurality of divisions which may oversee a plurality of state offices which may oversee a plurality of cable providers and/or other MSO's. The iterations and complexities are almost endless in the present cable industry. SUMMARY OF THE INVENTION

Thus, a need has arisen for a system which allows centralized and hierarchical control over the operations of local cable systems. It is an object of the present invention to overcome these and other disadvantages of the present systems.

In explaining the objects and advantages of the present invention, a general understanding of terminology is provided below.

A cable provider is generally any entity which has a franchise or other legal right to allow that entity to provide cable television prograrmr ng.

A customer is generally the person or legal entity (an individual or a company) that is financially responsible for prograrnming and other services purchased from a cable provider. For example, the customer may be Joe Smith or ABC, Inc.

A service location is generally the physical site (a house, apartment, or business, e.g.) at which a cable provider provides, or could provide, programming and other services. For example, the service location may be 123 Walnut Street, Cooperstown, New York. An account is generally an informational link between a customer and a service location.

A product is generally a good or service provided by the cable provider to the customer. For example, the product may be anything from Home Box Office to installation. A product parameter is generally any parameter which defmes the product. Product parameters may include product name, product availability, or product pricing, to list just a few.

It is an object of the present invention to provide centralized product defmition such that entities at each level in the hierarchical chain may establish parameters about the product which must be followed by any entities lower on the hierarchical chain.

It is another object of the present invention to provide a system which enables any entity in the system access to information about any customer or account in the system.

It is still another object of the present invention to provide a system which allows customer service representatives from any entity of the system access to most ofthe information about customers and accounts with ease and speed. It is yet another object of the present invention to provide a system in which a customer may be associated with one or more service locations.

It is still another object ofthe present invention to provide a system in which an account may be associated with only one customer or may be associated with one or more service locations.

It is yet another object of the present invention to provide a system in which a service location may be associated with zero, one or many customers.

It is another object of the present invention to provide a system in which a service location may be associated with zero, one or many accounts.

Accordingly, the present invention comprises a system and method for providing a product to a plurality of customers. The system is accessed by a plurality of users each of which has an authority level, A, where A = 1 to n, with n being the highest authority level. A memory stores a plurality of records. A first device receives parameters from a highest level authority user which define a product. The first device then creates a product record at the highest authority level using the parameters received from the highest level authority user and stores the highest level authority record in a memory. A plurality of second devices receive lowest authority level parameters from a lowest authority level user which redefine a product having a highest level authority record. The lowest level authority parameters must be more specific than the highest level authority parameters. The second devices then creates a lowest level product record comprising the highest level authority parameters and the lowest level authority parameters and stores the lowest level product record in memory. A plurality of third devices access the memory to receive at least one of the lowest level product records and provide a product to a plurality of customers according to the parameters of that lowest level product record. The first, second and third devices, and the memory may be distributed over a wide area network.

According to another aspect of the present invention, a system for operating a cable television network, wherein the network comprises a plurality of customers each associated with one or more accounts and with one or more service locations, comprises an operational management system. The operational management system comprises a main processor and memory for storing customer records, account records, and service location records. The memory is arranged to associate each customer record with at least one account record and at least one service location record, to associate each account record with at least one customer record and at least one service location record and to associate each service location record with at least one customer record and at least one account record. The operational management system also comprises at least one main customer service processor which accesses the memory and retrieves information contained in any customer record, any service location record, and any account record stored in the memory. This data may then be presented to a user.

The system further comprises a plurality of node office systems which are connected to the operational management system over a wide area network, for example. Each node office system has a plurality of customers, service locations and accounts associated therewith. Each node office system comprises a cable television product delivery device which provides a cable television product to a service location associated with that node office system. Further, each node office system comprises at least one node customer service processor which accesses the memory and presents information contained in any customer record, any service location record, and any account record stored in the memory. The node customer service processor and the main customer service processor enable a user to request that a new customer record be created for customers of any of the plurality of node office systems, service location records for service locations connected to any of the plurality of node office systems, and account records for accounts associated with any ofthe plurality of node office systems.

According to another aspect of the present invention, a system for operating a cable television network wherein the network comprising a plurality of customers each associated with one or more accounts and with one or more service locations, comprises memory for storing customer records, account records, and service location records. The memory associates each customer record with at least one account record and at least one service location record, each account record with at least one customer record and at least one service location record, and each service location record with at least one customer record and at least one account record. The system also comprises at least one customer service processor which accesses the memory for information contained in any customer record, any service location record, and any account record stored in the memory means. The customer service processor comprises an input device which receives customer service requests, a memory access device which retrieves at least one customer record, at least one account record, and at least one service location record in response to the customer service request, and a display. The customer service processor controls the display to present a graphical user interface comprising a banner window, an account window, and a service location window. The banner window comprises fields for customer related information.

The account window comprises fields for account related information. The service location window comprises fields for service location related information. The novel graphical user interface allows a customer service representative to alter customer, service location and account records stored in the memory.

Other aspects, features, and advantages of the present invention will become apparent to one of ordinary skill in the art upon consideration of this specification and the accompanying figures. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 depicts an overall system architecture according to one embodiment ofthe present invention.

Fig. IB depicts a schematic of the hierarchical structure of Fig. 1 according to one embodiment of the present invention.

Fig. 2 depicts a divisional office system and a regional call center according to one embodiment ofthe present invention.

Fig. 3 depicts a node office system according to one embodiment of the present invention. Fig. 4 depicts an operational management system according to one embodiment of the present invention.

Fig. 5 depicts an operational management system according to one embodiment of the overall system architecture of Fig. 1.

Fig. 6 depicts a flow diagram of a user interface system according to one embodiment of the present invention.

Fig. 7 depicts a graphical user interface according to one embodiment of the present invention.

Fig. 8 depicts a customer window according to one embodiment of the present invention.

Fig. 9 depicts a customer window according to another embodiment of the present invention.

Fig. 10 depicts a service location window according to one embodiment of the present invention. Fig. 11 depicts a service location window according to another embodiment of the present invention.

Fig. 12 depicts a bill window according to one embodiment ofthe present invention.

Fig. 13 depicts a bill window according to another embodiment ofthe present invention.

Fig. 14 depicts an account window according to one embodiment ofthe present invention.

Fig. 15 depicts an account window according to another embodiment of the present invention. Fig. 16 depicts an account window according to yet another embodiment ofthe present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An overall system architecture according to one embodiment of the present invention is depicted in Fig. 1. System 10 in Fig. 1 comprises a operational management system 12, hierarchical systems 30, and support systems 32. Hierarchical systems 30 may comprise a plurality of divisional office systems 16, a plurality of state office systems 18, a plurality of franchise systems 20, and a plurality of node office systems 28, distributed over a wide area network (WAN) 100. Hierarchical systems 30 may also comprise one or more regional call centers 14 distributed on WAN 100.

In a preferred embodiment, each franchise system 20 may control the operations of a single cable provider or a plurality of cable providers. If a plurality of cable providers are controlled, then each franchise system 20, in this preferred embodiment may have one or more node office systems 28 associated therewith.

Support systems 32 may comprise a bill printing system 22, a bill payment system 24, and an accounting system 26 distributed on WAN 100. System 10 may also comprise additional systems distributed on WAN 100.

System 10 depicts an architecture in which five hierarchical levels exist. In this embodiment, for example, the hierarchical order may be operational management system 12, divisional office systems 16, state office systems 18, franchise systems 20, and node office systems 28. It is also possible for others numbers of hierarchical levels to exist.

In a preferred embodiment, operational management system

12 has hierarchical control over each system of hierarchical system 30, each system of support system 32, and any other system distributed on WAN 100. As such, centralized control of every system on the network may be achieved. Within hierarchical control system 30, control may be exercised according to hierarchy.

Fig. IB depicts a schematic of the hierarchical control provided according to one embodiment of the present invention. OMS 12 controls a plurality of divisional office systems 16. For example, m divisional office systems 16 may be provided, where m may equal from 1 to 100 or more. Each divisional office system 16 controls certain operations of a plurality of state office systems 18 to which it has been assigned. For example, divisional office system number 1 may control state office systems 1, 1 to l,p where p may equal an integer from 1 to 50 for example. Divisional office system number 2, on the other hand, may directly control one or more franchise systems 20.

Each state office system 18 may control certain operations of a plurality of franchise systems 20 or franchise/node systems 20/28 to which it has been assigned. A franchise/node system 20/28 may be a franchise having only one node and thus operating as a node system 28 as described herein. For example, state office system l,p controls franchise systems l,p, 1 to l,p,s where s may be an integer from 1 to 100 or more. Each franchise system 20 controls certain operations of at least one node office system 28 assigned to the franchise system. For example, franchise system m,l,x may control node systems m, l,x, l to m, l,x,c where c is an integer from 1 to 100 or more.

In a preferred embodiment, each node office system 28 is assigned to one and only one franchise system 20, each franchise system 20 is assigned to one and only one state office system 18 or one and only one divisional office system 16 or directly to OMS 12. Each state office system 18 is assigned to one and only one divisional office system 16 or directly to OMS 12. Each divisional office system 16 is under the direct control of operational management system 12.

Although divisional office systems 16, and state office systems 18 may have different functions as described below, their system architecture may be basically similar. Fig. 2 depicts a system architecture for a divisional office system 16 and a regional call center 14. Divisional office system 16 may comprise a main divisional processor 40 connected to WAN 100, a plurality of customer service processors 42 in communication with main divisional processor 40, and an automatic response unit (ARU) 39 connected to main divisional processor 40. Main divisional processor 40 comprises a product rating subprocessor 41. ARU 39 may be operatively connected to customer telephone equipment through a telephone line or two way cable, for example. ARU 39 then may operate to indicate to main divisional processor 40 certain information about a customer calling with a request. This information may then be passed through to one of the customer service processors 42 assigned to handle the customer's requests or may be handled automatically. The operations of ARU 39 will be described in greater detail below.

The architecture for a state office system 18 may be similar to divisional office system 16. In a preferred embodiment, state office system 18 may comprise a main state processor having a product rating subprocessor connected to WAN 100, an ARU connected to the main processor and to a phone line or two way cable which is connected to customer telephone equipment, and a plurality of customer service processors in communication therewith.

Regional call center 14 may comprise a regional call center processor 43, an automatic response unit 47 connected to the regional call center processor 43, and a plurality of customer service processors 45 connected to regional call center processor 43. Regional call center 14 may be associated with one or more node office systems 28 and/or one or more franchises 20. Preferably, regional call centers 14 operate to handle overflow requests at one or more node office system 28 or one or more franchise systems 20 with which they are associated. Regional call centers 14 may also directly service customer requests or inquiries. Fig. 3 depicts one embodiment of a node office system 28.

Node office system 28 comprises a node processor 50 connected to WAN 100. Node processor 50 may comprise one or more sub processors. For example, node processor 50 may comprise a technician control subprocessor 52, a product/rating subprocessor 53, and an administration subprocessor 54. Technician control subsystem 52 may be in communication with one or more technicians who may be called upon to act in response to service requests at one of the service locations assigned to node office system 28. Administration subsystem 54 may control internal operations of the node, for example. Product/rating subprocessor 53 establishes product information and pricing for products available at the node as described in detail below. Node processor 50 may also have connected thereto a plurality of customer service processors 56.

Node processor 50 may also be connected to a head end unit 58 and its associated head end controller 62. Head end controller 62 may also be connected directly to WAN 100. Head end 58 may also be connected to one or more satellite receivers 60 according to known techniques in the art. Head end 58 may further be connected via connection 66 to a converter box connected to a television 74 or directly to television 74 at one or more service locations 64. Connection 66 between head end 58 may be by coaxial cable, fiber optic cable, or telephone lines, for example. Other methods of connections including over-air signal transmission such as by microwave, for example, may also be used. Node processor 50 may also be connected to an automatic response unit (ARU) 70. ARU 70 is connected to incoming telephone lines 68 and operates to identify incoming callers to more quickly direct their calls. Telephones 72 at service locations 64 may be connected to telephone lines 68 and thus to ARU 70. Details of ARU operations are provided in greater specificity below.

Franchise system 20 may either resemble divisional office system 16 or node office system 28. Franchise system 20 may be associated with one or many nodes. If only one node is present, then franchise system 20 is a node system and thus may be similar to node office system 28 depicted in Fig. 3. If more than one node office system 28 is associated with a particular franchise system 20, then franchise system 20 may resemble divisional office system 16.

Fig. 4 illustrates an embodiment of the operational management system (OMS) 12 of the present invention. OMS 12 generally includes operational processing system (OPS) 80, database access systems (DAS) 104, and customer service processors 102. OPS 80 comprises multiple processing components 82-99 which are responsible for various functions of OMS 12. In a preferred embodiment, the processing components comprise a product/rating component 82, a dispatch component 84, an external interface component 86, a bill production component 88, an addressability component 90, a customer support component 92, an internal interface component 94, a reporting component 96, a global component 97, a telephone component 98, and a miscellaneous component 99. The above listed components are merely exemplary. For example, multiple DAS's 104 may be employed for redundancy as discussed in further detail below (for example, two are shown in Fig. 4). Additionally, OPS 80 may be distributed physically and /or logically so that each of the processing components 82-99 may reside on a separate OPS or various individual processing components may be grouped together on associated OPSs.

As discussed above, each of the processing components may perform a variety of functions. Product/rating component 82 may be responsible for defining new products, redefining existing products, pay- per-view management, packages, promotions, installations and repair service definition, merchandise, product restrictions/blackouts, and rating maintenance, for example. The functions of product/rating component 82 is described in detail below.

The dispatch component 84 may be responsible for work order scheduling, technician quota points, work order routing, dispatch- GIS, technician maintenance, technician user interfaces, technician devices, technician communication systems, equipment inventory, outage detection, global positioning systems, map images, digitized intelligent plants, and status monitoring. Other functions may also be performed by dispatch component 84. Generally, though, dispatch component 84 processes information and requests regarding dispatch of service technicians to a customer site for repair, installation or other services.

The extemal interface component 86 may be responsible for collections processes, subscriber payment maintenance such as credit card interfaces, lock box interfaces, electronic funds transfer, drop box, cashiers, check-in process, and collection agencies, bill rendering, refund check rendering, and product usage payments, for example. Extemal interface component 86 is the main component for interacting with support systems 32 and may function to communicate with other extemal processors as well.

The bill production component 88 is preferably the main component for interfacing with outsourcing of bill generation. Bill product component 88 may be responsible for billing cycle maintenance, bill production, reminder notices/bill messaging, refunds processing, account aging, intemal collections, write-off processing, subscriber notifications, marketing inserts, bill reprints, adjustments and credits, bill formatting, cash processing-payment, and bill archiving, for example. The functions of bill production component 88 are described in greater detail in related application, Attorney Docket No. 018972.0251 entitled "Method And Apparatus For Processing Billing Transactions" which is copending.

The addressability component 90 is the component generally responsible for addressing customer equipment such as converter boxes. Generally, each converter box has a specific address. The addressability component 90 is responsible for sending signals to the converter box at that specific address over the WAN 100. The addressability component 90 may be responsible for channel lineups, pay- per-view connections, TAC, DMX, controller addressing, two way converter communications, digital compression, netlink functionality, automatic box refreshing, bill transmission to a converter box, payment from a converter box and converter box assignments, for example. The addressability component 90 may also be responsible for other functions. The customer support component 92 may be responsible for various customer related functions. For example, customer support component 92 may be responsible for subscriber management, order processing, customer service, equipment inventory, customer follow-ups, on-line bulletin boards, library topics, phone directory, and tax calculations. The customer support component 92 generally comprises a plurality of OLTP applications. The operation of customer support component 92 is described in greater detail below.

The intemal interface component 94 is generally responsible for various functions within the corporate structure. For example, the intemal interface component 94 may comprise an accounting interface, equipment inventory, payroll/commissions, marketing interface, plant management, budget integration, and CIS functionality. Intemal interface component 94 may also be responsible for other functions as well. The reporting component 96 may be responsible for various reporting functions such as global reporting, government reporting, MSR functionality, tax returns, and ad-hoc capabilities, for example. The reporting component 96 generally functions to coordinate various data across DAS's 104. The telephone component 98 may be responsible for various telephone oriented functions. The telephone component 98 may be responsible for automatic response unit operations, automatic number indicating screen popping processes, DNIS handling processes, call center regionalization, and phone switch interfaces, for example. Other telephone, or non-telephone related functions may also be performed by telephone component 98.

The global component 97 may be responsible for various system-wide functions such as help facilities, security, parameter management, utility programs, corporate intemal information, computer- based training, audits and controls, and address maintenance. Global component 97 may also perform other functions.

A miscellaneous component 99 is preferably provided to perform other functions not performed by another components of OPS 80. For example, miscellaneous component 99 may be responsible for disaster recovery, facilities, implementation planning, architecture, GUI enor handling, GUI validation processing, client hardware specifications, ad-hoc reporting tools, reporting standards, technician device UI porting, dispatch to technician communication, customer tracking, user effectiveness, system performance, system enhancement requests, client to client communications and intemational support. Miscellaneous component 99 may also perform other functions. Also, additional miscellaneous components 99 may be provided, if desired.

As discussed above, a plurality of customer service processors 102 are preferably connected to OPS 80. Customer service processors 102 handle requests made at OMS 12. The operations of customer service processors 102 is described in greater detail below.

OMS 12 further comprises a plurality of database access systems 104. One of the features of the present invention is that all data is preferably maintained within OMS 12 in database access systems 104. As such, every component on the system may have access to information about any other component on system 10. For example, any node office system 28 may have access to information about any customer of any other node office system 28 in part because that information is resident on the database access system 104 which services both node office systems 28. Because data is stored globally within OMS 12, all data is accessed by global parameters also. The uniformity of data access also allows for any node office system 28 to access any other node office system 28^*s data because the parameters have been globally defmed. Data definition is described in greater detail below.

For purposes of ensuring identity of data on the various database access systems 104, replication servers 122 may be provided. Replication servers 122 ensure that every update of data on one of the database access systems 104 also occurs to the data on the other database access systems 104. Replication servers 122 replicate vertical data across servers for consistency. They also replicate all data across sites for redundancy and replicate data to offline reporting/data warehouse for back up purposes. Database Access System 104 Operations

Each database access system 104 comprises a plurality of data directory servers 106, a plurality of cross reference servers 108, and a plurality of data servers 107. For example, each database access system 104 may comprise a customer data server 1 10, a dispatch data server 112, an archive data server 114, a billing data server 116, a message/notice data server 118, and a miscellaneous data server 120. Database access system 104 may comprise more or fewer data servers as needed or desired.

Each processor, subprocessor, and component on WAN 100 acts as a transaction generator toward database access systems 104. These include support systems 32, bill printing system 22, bill payment system 24, accounting system 26, regional call center processors 43, customer service processors 45, main divisional processors 40, product/rating subprocessors 41, customer service processors 42, node processor 40, technician control subprocessor 52, adrninistration subprocessor 54, customer service processors 56, head end controller 62, OPS 80, product/rating component 82, dispatch component 84, extemal interface sub-processor 86, bill production co-extemal component 88, addressability component 90, customer support component 92, intemal interface component 94, reporting component 96, global component 97, telephone component 98, miscellaneous component 99, and customer service processors 102. Each of these elements may make a data request over WAN 100. All data requests in a prefened embodiment are handled by one of the DAS 's 104.

Each of these transaction generators is connected via WAN 100 which is a two-way communication link to the one (or more) DAS's 104. As described above, each DAS 104 may include any number of data directory servers 106, but includes at least one. Each data directory server 106 in turn is connected via a two-way communication link to multiple data servers 107, for example. Each data server 107 comprises one or more databases either as components of a single subsystem (processor and database) or through a two way communication link. Additionally, each DDS 106 is connected via a two-way communication link to one or more cross reference servers (X-ref, - X-ref,,, where n = any integer) 108.

In Fig. 4, DDSs 106 are represented as being connected over WAN 100. Likewise, DDSs 106 are represented as being connected to a plurality of data servers 107. In a preferred embodiment, these connections are individual connections rather than connections to a grouping of DDS 106. For example, OPS 80 is separately connected to each DDS 106. Further, each customer data server 110 is separately connected to each DDS 106. Alternatively, however, DDS functionally may be grouped with common connections to the transaction generators and/or data servers 107 as indicated in Fig. 4, so long as proper control between DDSs 106 is maintained.

The system ofthe present invention is designed to manage a very large number of OLTP transactions occurring within the system. The system of the present invention provides users with the ability to query across the entire database from any element in the system. Similarly, each of the users may update certain data located anywhere within the system.

DDSs 106 respond to transaction generators through procedure calls to the DDS. The transaction generators in the system of the present invention may be any devices capable of receiving input from a user and transmitting that input to the Data Directory Servers (DDSs) 106. In a preferred embodiment, each of the components ofthe hierarchical control systems 30 comprise transaction generators. At least one control application is resident on each transaction generator, wherever located, for communication between the DDS(s) 106 and a human operator and/or process. As will be discussed in more detail below, the control application, among other functionality, enables updating the intemal mles used by DDS(s) 106. As described in more detail below, when a transaction is generated by a transaction generator and sent to a data directory server 106, data directory server 106 determines the appropriate data server 107 for execution of the transaction. Preferably, this is accomplished by DDS 106 consulting the intemal rules and identifying the arguments associated with the transaction.

Each of the transaction generators are clients of the DDSs 106. These terms are used interchangeably herein. Transaction generators may be dumb terminals (i.e., incapable of performing local processing) or they may have various processing capabilities of their own. Examples of transaction generators include, without limitation, PC's, RISC-based workstations, supercomputers, and local area networks. In typical applications, there may be a large number of transaction generators. Thus, the system is designed as an open platform environment which is hardware independent. The transaction generators may be homogeneous in terms of interface and operation or they may be heterogeneous. In other words, all transaction generators may be of one type or there may be a variety of devices interacting with the DDSs 106. It is also possible to permit customer interaction with the system through ARU/ANI (Automated Interactive Voice Response Unit/ Automatic Number Indicator) units such as ARU 70, and telephone component 98. In this case, much ofthe processing may be driven by the telephone number retrieved by the ANI when the customer calls into the system. DDSs 106 of the present invention function as the middle tier of a three tier client server architecture. As depicted in Fig. 4, more than one DDS 106 may exist within the operational management system 12. In such case, each DDS 106 has commumcation access to all of other DDSs 106 as well as to each data servers 107. DDS 106 serve three primary functions. After receiving a client request, the selected DDS 106 first locates the appropriate data server 107 for execution of the request. It then submits the client request to the selected data server 107 and finally DDS 106 returns the result to the submitting client.

Transaction generators requesting information from the databases connect to a DDS 106 prior to accessing data. Through the use of intemal mles, DDS 106 determines where a remote procedure should be performed in order to complete processing of a transaction. Access to DDS 106 may be efficiently implemented through the use of remote procedure calls (RPCs) which are identified in tables intemal to DDS 106. Any of a large number of standards for such RPCs may be used with the current invention.

DDS(s) 106 are preferably open server applications that provides a mechanism to direct any data request associated with a generated transaction to a data server 107 that can service the transaction generators' requests. Specifically, DDSs 106 may be open servers comprising the same or similar hardware as data servers 107 of the present invention. Alternatively, DDS 106 may be configured differently from the data servers 107. DDS 106 function to analyze the client's data request transaction and, based upon the transaction type and a set of mles, directs the request to the appropriate data server 107. The types of transactions which are received at DDSs 106 are based upon a set of stored procedures recognizable to DDSs 106 and available to the transaction generators.

DDSs 106 communicate with a plurality of data servers 107 each accessing one or more storage devices. In a preferred embodiment of this invention the data servers 107 are Cebus SQL Servers which execute Cebus remote procedure calls. This invention is not, however, necessarily limited thereto and the servers may be of any type so long as the stored procedures are designed for processing by the particular server and the associated database which are selected. It is possible to employ any number of data servers 107, transaction generators, and DDSs 106 in the operational management system 12 of this invention so long as the proper number of communication channels is supplied and supported. As noted above, more than one DDS 106 may exist in the system to provide scalable execution of these functions, each such DDS 106 being in communication with all transaction generators/clients and all servers 107. In an embodiment with multiple DDSs 106, the clients are connected with one DDS 106 according to a pre-determined method. DDSs 106 preferably operate according to a limited number of event handlers responsible for processing the requests generated by the transaction generators 120 as well as intemal requests generated as a result of DDS processing itself. The event handlers are as follows:

1. Start Handler - The start handler provides a convenient and central location for installing any other event handler routines, building any tables necessary for processing client requests and for installing any other services that the DDS requires for its functionality.

2. Stop Handler - The stop handler is executed when a request to shut down the system has been received through a particular request or as a result of certain system conditions.

3. Connect Handler - The connect handler is executed whenever a client connects to the DDS.

4. Disconnect Handler - The disconnect handler is executed whenever a client terminates an active connection to the DDS. 5. Language Handler - The language handler is executed whenever a client application issues a language statement to the DDS. The language handler in the DDS does nothing since all client requests are required to be either registered procedure calls or remote procedure calls. 6. RPC Handler - The Remote Procedure Call handler carries the bulk of the load shouldered by the DDS and is the most important handler for purposes of this discussion. Any client request which is not registered in the DDS registered procedure table will generate an RPC handler event where the request is analyzed by the RPC event handler and acted upon accordingly.

7. Error Handlers - Several enor handlers are installed in the DDS application to provide information on any failure from the client, server and client/server components of the DDS. All error messages are logged in the DDS.

8. Attention Handlers - An attention handler is installed to handle disconnects from a client application. The DDS has been set up to cause all client disconnects to generate an attention event in order to determine if the client application has interrupted its connection to the DDS.

The functionality comprising the operation of the DDS can be categorized into three separate classes - the main function, the local DDS registered procedures and the utility functions. The main ( ) function provides the entry point for all executable C programs. Note that although the preferred embodiment is formulated using the C and C++ languages, the particular invention described herein is by no means limited to such a design. The error handlers and the start handler are installed in the main function body. These include a set of routines which serve to parse input parameters and configuration file attributes in order to set up any DDS properties. The network listening function is spawned in the main function body and sleeps until the DDS application is terminated either normally or abnormally.

The DDS application is dependent on several global data tables. These global tables are used to control the navigational decisions that the RPC Handler needs to direct the client's data requests to the appropriate data server in order to complete the data request.

Service requests originating at the client that are not identified as a registered procedure, are treated as remote procedure calls and are handled by the RPC Handler. All ofthe event handlers and supporting system functions provide a trace log of activities in a locally maintained log file. This file is preferably truncated every time the DDS application is started.

Data servers 107 maintain the various data necessary for meeting the functions described above and are accessible by each of the transaction generators through a DDS 106. In a typical implementation, data servers 107 are SQL devices which are capable of executing the RPCs transmitted by a DDS 106.

The databases available to data servers 107 may be either homogenous or heterogeneous. In a homogeneous environment, particular protocols for accessing each of the databases are consistent throughout the enterprise. Conversely, in a heterogeneous environment, the particulars of database access vary within the enterprise. In a heterogeneous environment, it is often desirable, however, to render any differences in requirements within the enterprise transparent to user working at the client site. That is, a user should not be aware of any database heterogeneity and a user request should be processed in a standard manner across all resources.

The databases which are accessed in a distributed system may all be located together or they may be physically apart. They may be at the client location or they may be at an alternate site. Databases may be relational databases such as CEBUS (a trademark of Cebus, Inc.) or they may be as simple as a series of flat files.

DDSs 106 interface with a control application which resides on each transaction generator. The control application functions to allow a system operator to store, update, and modify stored procedures available to the transaction generators. This is typically accomplished by downloading the update to the X-Ref Server 108 which loads the new mles base into the DDSs 106 at DDS startup. OPS 80 also includes one or more X-Ref Servers 108. X- Ref Servers 108 function as a resource available to DDSs 106 for determining where specific data resides in the system and for storing the mles base which is loaded into DDSs 106 at DDS start-up. X-Ref Servers 108 contain a variety of global tables which are continually updated as data is added, updated and deleted within the system.

In a preferred embodiment, DDSs 106 access XRef Server(s) 108 at startup to access database information necessary for the operation of DDSs 106. After the start-up tasks are complete, normal client requests may be processed by DDSs 106. Alternatively, DDSs 106 may access XRef Server(s) 108 (or any other device containing the required data) as requests are submitted to DDSs 106.

Client requests are initiated at the transaction generators and transmitted to a DDS 106. Once it has received the data request, the DDS application consults the DDS Server Table (a global table) which identifies all ofthe available and accessible data servers 107. There is also provided an XRef Server Table (global) which identifies all known and accessible XRef Servers 108. An additional global table is the Error Message Handler Table which maintains all enor handler messages. All of the global tables defined in DDS 106 provide feature functionality to support the access related to these tables.

The transaction generators make requests for reads, writes, and updates through DDS 106. As discussed above, once a request is received, DDS 106 determines the set of potential data servers which may execute the request and pseudo randomly selects one or more servers from that set for servicing. Alternatively, various, non-random and semi- random methods for selecting the subset of potential data servers may be used. Examples of such methods include those relating to current server loads (load balancing) and those relating to queuing theory in general. The subset of servers which are available to process the request may be determined in one of two ways as discussed above. In a first embodiment, global tables are loaded from XRef Server 108 into intemal DDS memory at DDS startup. In a second embodiment, no such loading occurs at startup - rather, upon receiving a client request, DDS 106 submits a request to XRef Server 108 in order to retrieve the necessary data. In either embodiment, DDS 106 has available to it the necessary mles base and other data which is required to determine the type of transaction (including the data required and the locations of that data) and to select the appropriate data server(s) 107 for processing the transaction. Next, the request is submitted to the selected data server(s) which process the request and returns a result set to DDS 106 which may then perform additional operation(s) on the data prior to passing the final result set back to the transaction generators. Alternatively, the result set may pass through DDS 106 to the transaction generators without any additional processing on the part of DDS 106. The latter situation is generally termed "pass-through mode".

After a request has been serviced and the result set has been returned to the transaction generators, DDS 106 may receive another request and process it in accordance with the above procedure. In such an embodiment, the DDS 106 does not begin processing a new request until it has completed processing ofthe prior request. In another and preferred embodiment, a single DDS 106 processes multiple client requests concurrently exploiting the availability of numerous resources for processing large numbers of transactions.

The operations of DASs 104 according to one embodiment of the present invention are described in greater detail in Application Number 08/405,766 entitled "Method And Apparatus For Transaction Processing In A Distributed Database System," which was filed on March 17, 1995, which is co-pending and which is hereby incorporated by reference.

Fig. 5 depicts another configuration depicting the connections of the various components of DAS 104. In this embodiment, two DAS's 104 are provided, one at Denver, for example, and one at Dallas, for example. The DAS's 104 are distributed over WAN 100. Customer service processors 102 are also indirectly connected to WAN 100 to enable access to DDS's 106, XRef servers 108 and the various data servers 107 which in this embodiment may comprise customer data server 110, dispatch data server 112, bill data server 116 and miscellaneous data server 120. Several ofthe extemal processors 32 may also be connected to WAN 100. For example, bill printing system 22 and accounting system 26 may be provided with access to DDSs 106.

In the embodiment of Fig. 5, there are eight DDSs 106 provided at each location and two XRef servers 108. These numbers may be varied such that more or fewer DDSs 106 may be provided or more or fewer XRef servers 108 may be provided.

Three types of connections may be provided:

1) a client to DDS connection; 2) a DDS to data server connection; and

3) a replication server to data server connection.

In Fig. 5, the various connections are depicted. As described above, in a preferred embodiment, each of the components are directly connected. For example, each customer service processor 102 is preferably directly connected to a DDS 106. Also, each data server 107 is preferably connected directly to a DDS. A replication server is a server that generates a duplicate copy of the information located on a primary server. In a preferred embodiment, when at least two DAS's 104 are provided, each DAS 104 has an associated replication server 107. For example, in Fig. 5, CUSTD 2 may have the same information as CUSTL 2. In this embodiment, if a customer service processor 102 requests information from DDSD l, for example, about a customer which is stored on CUSTD 2 and the DDSD l is unable to access that data server (for whatever reason, e.g., transmission problems), the DDSD l may access the required data from CUSTL 2 in Dallas. Therefore, the CUSTL 2 is a replication server for DDSD l and all other DDS's at the Denver location.

Many of the operations of this system are understood upon an explanation of the functions of the components. Product/rating component 82, product rating subprocessor 53, and product/rating subprocessor 41 interact over WAN 100 with OMS 12 in a manner which highlights various features of the present invention. Product/Rating Component

As described above, in general product/rating component 82 is responsible for product definition, pricing, packaging and the like. According to a preferred embodiment of the present invention, product/rating occurs strictly according to the hierarchical control established in system 10. OMS 12 has ultimate control over definition of any product provided by any node office system 28 on OMS 12. Operational Management System Product Defmition

According to a preferred embodiment of the present invention, a user having access to operational management system 12 defines a product and product parameters which become universal information for all cable systems, i.e., node systems 28 on OMS 12. In a preferred embodiment, products are defined at the highest level, for example at the corporate level, before the same product may be defined at any lower level. The information defined at the highest level is preferably input by a limited number of individuals having access to that level, for example, specified corporate personnel, and is designed to provide the highest level of priority and security. The product definitions and product parameters defined at the highest level, such as the corporate level, define the standards that are adhered to at all lower levels of product definition. Product Parameters

In a preferred embodiment, a product is defined by a product ID which may be a system generated number that relates to the defined product; a product name which must be unique from all other defined products; a product start date and stop date; product category and product type for example.

There may be any number of product categories including entertainment, pay-per-view, package, equipment rental, merchandise, work order, and special, for example. Within the entertainment product category, there may be several product types including basic, expanded basic, game, premium, and audio, for example. Within the pay-per-view product category, there may be several product types including PPV event, PPV movie, PPV adult, and PPV game, for example. Within the package product category, there may be several product types including recurring and one-time, for example. Within the equipment rental product category, there may be several product types including converter, remote control, DMX tuner, and DMX DJ remote, for example. Within the merchandise product category, there may be several product types including equipment, remote control, game, guide, DMX tuner, DMX DJ remote, coax cable, a/b switch, splitter, and accessory, for example. Within the work order product category, there may be several product types including installation, service change (upgrade, downgrade or sidegrade), hourly service charge, restart, trouble call, and transfer, for example. Within the special product category, there may be several product types including guide, club membership, home wiring maintenance, equipment maintenance, and credit card membership, for example. General Product Definition

In general, products are defined by the creation of a record by product/rating component 82 and stored in one or more of data servers 107. For example, product definition records may be stored in the customer data server 110 or may be distributed across several servers. Some fields ofthe product record may be required regardless of the product category. For example, product name, product long name, product category, product type, business unit, bill statement name, product start date, product stop date, revenue ID, account type, offer method, corporate suggested price, corporate rninimum price, and corporate maximum price may be mandatory product parameters.

Other fields may also be completed for the various types of product categories. For example, these fields may include channel position, range, franchise rate, channel number, price effective date, network, frequent buyer points, marketing description, intemal, commission, inclusions/exclusions, equipment dependencies, authorization codes, division suggested price, division minimum price, division maximum price, state suggested price, state minimum price, state maximum price, multi-outlet discount, business unit approval code, deferred rate, task code, force monthly bill, charge before, studio, distributor, rating subject, free view minutes, event ID, event start date/time, even stop date/time, event duration, ARU price, ANI price, impulse price, club price, CSSR price, event price effective, date/time, employee price, base event number, event authorization/controller, event number, cancel date/time offset, start order date/time offset, and stop order date/time offset. Other parameters may also be provided to define products.

Definition Of Product At Highest Level

Operational management system 12 in a preferred embodiment defines the highest level of priority in system 10. Access to OMS 12 is restricted according to predefined mles. For example, the corporate office may have direct access to OMS 12. Certain individuals having a password which is defined in product/rating component 82 have the authority to define a product which may then be made available to the various node systems 28 and intermediary systems distributed over system 10. These individuals may then be users on OMS 12 and may define a product.

Every user of system 10 has an associated authorization indicating the business level at which product definition may be made. For example, a small set of people may have corporate level authorization and may define products at the corporate level, or any lower level. Others, such as personnel at the various division offices, may have authorization at the division level and may define products at the division level, or any lower level. Others, for example, personnel at the various state offices, may have authorization at the state level and may define products at the state level, or any lower level. Others, for example, personnel at the various franchises, may have authorization at the franchise level and may define products at the franchise level, or any lower level. Others, for example, personnel at the various node offices, may have authorization at the node level and may define products at only that node level. Authorization is not limited to geographic location, however, and it is possible for a user at a node to have corporate, divisional, state, or franchise level authorization. It is also possible for a user at the corporate location to have only authorization for a particular node. Due to a possible wide geographic distribution of office systems, however, for the sake of explanation, it may be assumed that most users have authority at the level corresponding to the office system from which they access system 10. When a corporate authorization level user wishes to define a new product, first the user makes a request of product/rating component 82 to define the new product by a product name. To avoid potential duplication of names which could lead to confusion, product/rating component 82 initiates a search to determine if a product having the requested product name exists. Product/rating component 82 may send a request to database access system 104 which may supply the requested information. Because product names are preferably unique over the entire system, only one product may have the requested name. In a preferred embodiment, when a corporate user is redefining a predefined product, a screen enabling the user to select the product from a list of defined products may be provided.

If the product requested is not identified, the user may define the product. A new product may be defined when product/rating component 82 creates a new record with the necessary product parameters. This record then becomes available at all lower levels for product definition and revision, subject to the conditions and limitations placed on the product at the highest level. Lower Level Product Definition

As stated above, in a preferred embodiment, products may only be defined at lower levels if that product has been defined at the highest level. For example, a local cable operator cannot offer HBO as a product unless the corporate level has defined HBO as a product. Many parameters about a product may differ at the lower levels of the organization. For example, a node office in New York City may charge $8.00 for HBO whereas a node office in a much smaller community may charge only $5.00 for HBO. Nonetheless, any parameter of a product at the local level must fall within the parameters established at every higher level. Therefore, each actual provider of services must define the product also. Node office systems 28 and franchise systems 20 may offer services, for example. In order for these offices to provide the products defmed at the highest level, the products must also be defined at the level of their office. Product defimtion at the intermediate levels such as division and state offices may also be provided if the division and state offices wish to maintain greater control over product definition than that provided at the highest or corporate level.

To define a product at a lower level, the user requests a product defmition from the product/rating component at its level. For example, if a user at the division level wishes to define a product for the division level, then product rating component 41 may be used. If a user at the node level wishes to define a product for the node level, product/rating component 53 may be used. Other product/rating components may also be used, as long as the user only defines a product at the level for which the user has authorization.

The product/rating component servicing the user request then makes a database request to database access system 104 to determine if the product is defined at the highest level. If a product is not identified, the user is notified that the product does not exist or is no longer active. If the product is identified, then that product has been defined at the highest level and therefore, the user may proceed to define the product for a lower level. The user is then prompted to select the business unit at which the product definition or revision is requested. For example, the permissible business units may include corporate, division, state, franchise, or node. When the business unit is identified and validated to ensure that the user has the authority to make product definition/revisions at the requested business unit, the product/rating component initiates a search through database access system 104 to identify a record for the product at the desired business unit.

If a record for the product at the requested business unit level is identified, the product parameters from that record are presented and the user is provided with the opportunity to modify authorized parameters. Because certain parameters for the lower level record were defined at the highest level, those parameters may not be altered by the user at the lower level. Further, certain parameters for the lower level record may have been defined at a higher level (but not the highest level). Those parameters may not be altered by the user at the lower level either. For example, if a product has been defined at the corporate, division, state, and franchise level, a product record would have been created for the product at each of those levels. The product record for the division level would have the same completed parameters as the product record for the corporate level and would likely include several other completed parameters. The product record for the state level has the completed parameters from the corporate level and the division level and may include several other completed parameters. The product record for the franchise level has the completed parameters from the corporate level, the division level, and the state level and may include several other completed parameters. For a request to define a product at the node level the product/rating component generates a new record for the product at the node level having the completed parameters from the corporate, division, state and franchise level.

If a record does not exist at the desired business unit for the selected product, the user may define the product at the desired business unit. Product definition at a level lower than the highest level occurs when the product/rating component generates a new record for the product at the specified business level. This record is copied for the next highest level at which the product has been defined. Additional parameters to be completed are then provided to the use in a graphical interface for the user to complete.

If price information for the lower level is input which confines the limits imposed at a higher level of authorization, those price parameters must be modified in all records for all levels below the defining level. For example, if a product is defined at the division level with a minimum and maximum price which are higher and lower, respectively, of the minimum and maximum price of the corporate level record, then all product records at the state, franchise and node levels must be modified to include this information. Further, all pricing information at those levels must be verified to ensure that they are still in compliance with the hierarchical structure.

For example, if HBO has a minimum price of $5.00 and a maximum price of $15.00 at the corporate level and at a node level, the price may be set at $6.00. If a division record is modified such that the division nrinimum price is $8.00, then the price at the node level would not longer be valid and would have to be modified. Franchise Level Specifics

Because timing is different across the country based upon the time zone ofthe business unit, at the franchise level, when certain products such as pay-per-view events are defined, the product/rating component adjusts the times from the corporate, division, and state product definitions for the event Product Definition Example

Assume a system having a corporate office, five division offices, one hundred state offices, 250 franchises and 500 nodes. Each division covers ten states, each state covers five franchises and each franchise has two nodes. Suppose a user at the corporate level accessing OMS 12 defines a product called ABC 123 which is to be a new educational tutoring premium network. The user inputs a request through a customer service processor 102, for example. The user is then prompted to enter the required parameters to define a product. In one embodiment, those parameters may be product name = ABC 123 ; bill statement name = ABC 123; product long name = ABC 123 Educational Channel; product category = entertainment; product type = premium; product start date = 01/01/96; product stop date = 12/31/16; corp. min. price = $1.00; corp. max. price = $10.00; corp. sug. price = $3.00.

When the user has input into the customer service processor these parameters, product/rating component 82 generates a record to be stored by data access system 104. Data access system 104 and product/rating components 82 also generate a product ID which is a number which uniquely identifies the product. The corporate user may also enter other parameters which may be provided for the product.

Once ABC 123 is defined as a product at the corporate level, all lower levels may define this product at their respective level. All lower level definitions of a product must comply with the boundaries and conditions established at the corporate, or highest, level authorization. For example, suppose after a year, response to the ABC 123 channel is good for node systems 28 within a particular state, State A, but studies indicate that the pricing for that particular state is a little too high. Further, the state level determines that the ABC 123 product is a valuable premium channel and that the cost should be n inimized for the cable systems in its state. The state level determines that the maximum price for any system in its state should be set at $2.00 instead of $10.00 as defined at the corporate level as of 01/01/97. A user having authority at State A level may define the ABC 123 product for State A through a customer service processor 42 at state office system 18 located in State A, for example. A user having State A level authority may also use any other customer service processor including one at OMS 12.

Product/rating component 41 at state office system 18 may be used by the user to request the creation of the State A level ABC 123 product record. Product/rating component 41 then may access DDS 106 to retrieve a record for ABC 123 at the next highest level at which the product is defined and which is associated with the particulate state level at which the user has authority. A State A level ABC 123 product record may be generated by copying ABC 123 record from the next highest level product record which is retrieved from DDS 106. For example, if the product has only been defined at the corporate level, the corporate level product record for ABC 123 is copied to generate a State A level ABC 123 product record. In addition, additional state level parameters may be provided. Each state level may define these parameters differently such that 50 different state level product records may exist for a single product. Therefore, the State A level ABC 123 product record may include the following parameters: product name = ABC 123 ; bill statement name = ABC 123 channel; product long name = ABC 123 Educational Channel; product category = entertainment; product type = premium product start date = 01/01 /96 product stop date = 12/31/16 corp. min. price = $1.00; corp. max. price = $10.00; corp. sug. price = $3.00; state min. price = $1.00; state max. price = $2.00; state sug. price = $ 1.00; state prod, start date = 01/01/97; state prod, stop date = 12/31/16. Suppose that on February 1, 1996, a franchise, Franchise

Apple, in State A which did not previously provide ABC 123 decides to provide ABC 123. A user having authority for Franchise Apple may request a product definition for ABC 123 for Franchise Apple. For example, the user may use product/rating component 53 at Franchise Apple's franchise system 28 to create a Franchise Apple level product record for that franchise system 20. Product/rating component 53 first retrieves the State A level ABC 123 product record and generates a new record having the same parameters as the State A level ABC 123 product record. Then the user is prompted to complete additional information for that particular franchise. Other franchises in State A may define the product differently depending on the individual needs. A franchise level product record may be as follows: product name = ABC 123 ; bill statement name = ABC 123 channel; product long name - ABC 123 Educational Channel; product category = entertainment; product type = premium; product start date = 01/01/96; product stop date = 12/31/16; corp. min. price = $1.00; corp. max. price = $10.00; corp. sug. price = $3.00; state min. price = $1.00; state max. price = $2.00; state sug. price = $1.00; state prod, start date = 01/01/97; state prod, stop date = 12/31/16; franchise rate = $1.50; effective date = 02/01/97; fran. prod, start date = 02/01/97; fran. prod, start date = 12/31/97.

Suppose on July 1, 1996, the division office overseeing the state and franchise systems in this example determines that ABC 123 is not viable in its division unless the price is at least $2.50. The division office may define the product at the division level. The record for the division level product is copied from the corporate level which is the next highest level where the product is defined. A division office user may then complete division level specific parameters. The division level ABC 123 product record may be as follows: product name = ABC 123; bill statement name = ABC 123; product long name = ABC 123 Educational Channel; product category = entertainment; product type = premium; product start date = 01/01/96; product stop date = 12/31/16; corp. min. price = $1.00; corp. max. price = $10.00; corp. sug. price = $3.00; div. min. price = $2.50; div. max. price = $10.00; div. sug. price = $5.00.

Once the division level product has been defined, all lower levels must be updated, particularly because the new division minimum price has been set at a level higher than the state maximum price. Because the user at the division level may change records for all lower levels, the division level user may simply change the state level and franchise level product records such that the state maximum price is $2.50, for example. Product/rating component 42 may perform this automatically, for example, through data access system 104. Alternatively, authorization may be required from the division user to ensure that the division user wishes to override the state level product definition. Whenever a state level definition has been altered, state office system 18 for which the product was defined is notified of the change.

Package Definition

A package is one particular type of product for which additional information is entered to define the product. Essentially, a package is a collection of two or more individual products (preferably not other packages) that are discounted and offered to customers as a single product. The individual products to be included in a package must be defined before they can be included as a package. For example, in order to have a package including HBO, HBO must be defined as an individual product in the manner set forth above. The combination of individual products to create packages is specifically designed to provide a price differential and entice customers to buy products. Further, each package is preferably unique in that it contains a different combination of individual products.

Package Searching As with a product definition, the initial step of package definition is for product/rating component 82 to search for the package. Packages can be identified in two ways: 1) search for a package via the package name or package long name, and 2) provide a selectable list of all available packages. Package lists are presented in alphabetic order based on the long name. The ability to present the package list by package name or package long name/package type is also provided.

In addition, a user can search for packages containing any combination of individual products. This search requires the user to select one or more individual products. For example, a user may select HBO and Shovvtime. Upon such a request, all packages containing HBO and Showtime are found and displayed for the user to choose from. If a package is not found in the search, a new package may be defined. Example: Find and display all packages containing HBO, Showtime and Cinemax. 1 ) Enter "HBO", Showtime" and "Cinemax"

2) Search all packages that contain HBO, Showtime and Cinemax

3) Display all packages that contain HBO, Showtime and Cinemax End Result:

Package Name Package Components

HBO/SHO/MAX HBO, Showtime, Cinemax

The Movie Channel HBO, Showtime, Cinemax Encore, Starz

The Complete Package Basic, Expanded Basic, HBO,

HB02, Showtime, Showtime2, Cinemax, Encore, Starz

Package Components

The individual products that make up a package are preferably either recurring or one-time products. Recurring products are billed in regular intervals (e.g., monthly, quarterly, etc.) and contain individual subscription products, or products with recurring charges. When a package is defined as a recurring package, each and every package component is preferably a recurring charge. One-time charge products are applied once on a customer's account. A one-time package contains individual one-time products, or products with a one-time charge. When a package is defined as a one-time package, each and every package component is preferably a one-time charge. One-time charges include PPV events, work order (e.g., install, change of service, etc.) and merchandise.

Because packages are products, the procedures for defining products may also be followed to define packages. Therefore, packages are also defined with strict adherence to the business hierarchy. The highest level of control, for example, the corporate level, defines the accounting, billing and pricing standards for all packages. A package must exist at the highest level before it can be defined at any lower level in the business hierarchy. The lower levels may narrow the pricing standards and may identify the areas in which the package will be available. The franchise level establishes a specific package price, just as it establishes specific individual prices.

Packages may be defmed by a package name, package long name, package category (automatically set to "package"), package type (either recurring or one-time), corporate package minimum price, corporate package maximum price, account type, package components, package start date, package stop date, package price effective date and package allocation, all of which may be input by a user at the highest level as set forth above with respect to product definition. Product/rating component 82 then determines if the package is valid. First, it ensures that no other packages exist with the same products. Then, it ensures that the stop date of all of the products which form the package components is at least as late as the package stop date. Further, product/rating component 82 determines whether all ofthe products which form the package components have a product type which is the same as the package type, i.e., that all products are recurring for a recurring package and all products are one-time for a one-time package.

Revenue for individual products may need to be determined from the package. In other words, for accounting purposes, it may be necessary to know how much HBO is generating even if HBO is part of a package which generates a single price for all products included therein. For this purpose, package defmition also includes package allocation parameters. Package Allocation

The package allocation parameters contain the package component information and associated dollar amounts and percentages. The package allocation parameters may include package component, revenue split, revenue split percentage, and fixed revenue indicator. The package component parameter contains the individual product components that are part of the package (e.g., HBO, Showtime, Basic, Expanded Basic, Terminator 2, WWF Wrestlemania, etc.). Additionally, for each product component one of three revenue indicators (revenue split, revenue split percentage, or fixed revenue indicator) may be defined.

Revenue split indicates that the product has a specific dollar amount. For example, if a package containing two components is defined and priced at $12.00, then the revenue split for the first package component can be $7.00 and the revenue split for this second package component can be priced at $5.00.

Revenue split percentage parameter defines the percentage of a package price that should be attributed to the individual product. If a package containing two individual products is defined and each individual product should make up 50% of the total price, then each revenue split percentage would be set to 50%.

Fixed revenue indicator may be used to indicate that the revenue should be fixed. Some package components are defined as only having one selling price regardless of what franchise they are sold in or what package they are a part of. An example is Encore. When Encore is sold, a-la-carte or part of a package, it is sold for $1.00.

There are two methods of providing the revenue splitting information: the suggested retail price/revenue split percentage method and the revenue split method. Suggested Retail Price Revenue Split Percentage Method

In this method, for each component, a revenue split percentage is defined as a package parameter. Also, a corporate suggested retail price is defined as a package parameter. The individual revenue splits for the products are then determined based on the percentage parameter times the corporate suggested retail price. Example

1) Package components HBO, Showtime and Cinemax are collected into a package. 2) Suggested retail price is entered as $20.

3) HBO is given a revenue split percentage of 40%,

Showtime is given a revenue split percentage of 40% and Cinemax is given a revenue split percentage of

20%. 4) The revenue split percentages total 100% (40% plus

40% plus 20%). 5) The HBO revenue split is calculated to be $8 (40% multiplied by $20), the Showtime revenue split is calculated to be $8 (40% multiplied by $20) and the Cinemax revenue split is calculated to be $4 (20% multiplied by $20).

Revenue Split Method

In this method, revenue splits are directly defined. The suggested retail price is then totaled from the revenue split definitions. The revenue split percentages are then determined by simply dividing the suggested retail price with the revenue splits for the individual product components.

Example 1) Package components HBO, Showtime and Cinemax are collected into a package.

2) HBO is given a revenue split of $8, Showtime is given a revenue split of $8 and Cinemax is given a revenue split of $4. 3) The suggested retail price is calculated to be $20 ($8 plus $8 plus $4).

4) The HBO revenue split percentage is calculated to be 40% ($8 divided by $20), the Showtime revenue split percentage is calculated to be 40% ($8 divided by

$20) and the Cinemax revenue split percentage is calculated to be 20% ($4 divided by $20).

Effect Of Fixed Revenue Indicator When a fixed revenue indicator is associated with a package component, the revenue split is entered for the package component. When this occurs, the package component's revenue split percentage is set to 0% and cannot be changed as long as the fixed revenue indicator exists. In addition, the calculation of the revenue and revenue split percentages are impacted by this fixed revenue indicator as follows: If dollar amounts are entered for the other package components, the suggested retail price is determined by summing all package component revenue splits. The revenue split percentages are then calculated by first subtracting the revenue split of the package component with a fixed revenue split from the suggested retail price. Then, the other package components are divided by the previously calculated number to determine revenue split percentages

Example

1) Package components HBO, Showtime and Encore are collected into a package.

2) The fixed revenue indicator is associated with Encore and set at $1.00.

3) Encore is given a revenue split of $ 1.

4) Encore's revenue split percentage is automatically set to 0%.

5) HBO is given a revenue split of $5 and Showtime is given a revenue split of $4.

6) The suggested retail price is calculated to be $10 ($1 plus $5 plus $4).

7) The Encore revenue split of $1 is subtracted from the suggested retail price of $10. $9 is then used to determine the revenue split percentages for the remaining package components. 8) The HBO revenue split percentage is calculated to be 55.5%

($5 divided by $9) and the Showtime revenue split percentage is calculated to be 44.4% ($4 divided by $9).

If a suggested retail price is entered, the user is required to enter percentages for each package component (excluding the package component with a fixed revenue split). Once the entered percentages equal 100%, the revenue split amounts are then calculated. The first step is to subtract the revenue split of the package component with a fixed revenue split from the suggested retail price. The revenue split percentages are then multiplied by the previously calculated number to determine the revenue splits.

Example 1) Package components HBO, Showtime and Encore are collected into a package. 2) The fixed revenue indicator is associated with Encore.

3) Encore is given a revenue split of $ 1.

4) Encore's revenue split percentage is automatically set to 0%.

5) Suggested retail price is entered as $10. 6) HBO is given a revenue split percentage of 60% and Showtime is given a revenue split percentage of 40%

7) The Encore revenue split of $1 is subtracted from the suggested retail price of $10. $9 is then used to determine the revenue splits for the remaining package components.

8) The HBO revenue split is calculated to be $5.40 (60% multiplied by $9) and the Showtime revenue split is calculated to be $3.60 (40% multiplied by $9).

Changing Revenue Splits and Revenue Split Percentages

In a preferred embodiment, revenue splits and revenue split percentages may only be modified at the highest level of control, for example, the corporate level. When a lower level business unit, such as a division, changes the suggested retail price, the revenue splits at that level are automatically recalculated based on the new suggested retail price and the revenue split percentages. All calculated revenue splits are rounded to the nearest penny to ensure the total of the revenue splits total the suggested retail price.

Three methods of changing this information at lower levels exist once the package is initially defined. The three methods are:

1. A change to the suggested retail price at any level which causes the product rating to recalculate the revenue splits using the already defined revenue split percentages. 2. A change to the revenue split amounts at the highest level which causes product/rating component 82 to recalculate the suggested retail price and then recalculate the revenue split percentages. 3. A change to the revenue split percentages at the highest level which causes product/rating component 82 to recalculate the revenue splits using the already defined suggested retail price. The following provides an example of method number one. Example

1) A state business unit changes the suggested retail price from $20 to $24.

2) The HBO revenue split is recalculated to be $9.60 (40% multiplied by $24), the Showtime revenue split is recalculated to be $9.60 (40% multiplied by $24) and the Cinemax revenue split is recalculated to be $4.80 (20% multiplied by $24). Package Savings

In a preferred embodiment, product/rating component 82 determines package savings parameters for the defined package. The package savings parameters indicate the savings this package offers as compared to the individual product prices. These parameters may include individual product price, individual product price total, dollar savings and percentage savings. The individual product price is the price charged for the package component if it was sold a-la-carte. The individual product price total is the total dollar amount of all the package components if they were sold a-la-carte. The dollar savings is the savings, in dollar amount, of this package as compared to the total cost of all the package components if they were sold a-la-carte. The percentage savings is the savings, as a percentage, of this package as compared to the total cost of all the package components if they were sold a-la-carte. The package savings parameters are particularly useful for customer service representatives who are attempting to sell the packages. Multi-Outlet Pricing

Some packages may contain parameters for multi-outlet pricing. To determine if the package is eligible for multi-outlet pricing, the process evaluates the product category, offer method and a regulated flag for each package component. If any of the package components are categorized as entertainment or equipment and have an offer method of charge-by-outlet, multi-outlet pricing can be defined. Multi-outlet pricing is defined for a package by using the multi-outlet pricing defined for an individual product. The option then exists to change the multi-outlet pricing once it is populated with pricing data from the individual product level. The following describes the two possible scenarios regarding multi-outlet pricing.

Scenario 1 All of the package's components are unregulated and the offer method for one or more package components is charge-by-outlet (set during product definition). Multi-outlet pricing can be a flat dollar charge only. The multi-outlet price can be defmed as a dollar amount that is equal to or less than the package rate. Scenario 2

The package's components consist of regulated and unregulated products and the offer method for one or more package components is charge-by-outlet (set during product definition). Multi- outlet pricing can be a flat dollar charge only. Example

The following example shows how a package can have multi-outlet discounts with both regulated and unregulated products.

Outlet 1 Outlet 2-3 Outlet 4-5 Basic $10 $0 $0 HBO $6 $4 $2

Showtime $6 $4 $2

TOTAL $22 $8 $4

Multi-outlet pricing in the above example can be defined in two ways. The first is to use the package multi-outlet pricing information that was automatically populated with the individual product multi-outlet pricing information. The second way is to change the revenue split for each package component for additional outlet ranges (except for Basic since it is a regulated product). The individual dollar amounts are then summed to determine the total cost to the customer to have the package on additional outlets.

Package Termination Packages can be terminated in two ways. The first, and most common, is based on the entered stop date when a package is initially defined. Once the current date is greater than the package stop date, the package is no longer offerable to customers. The second way to terminate a package is to actually delete the package. This deletion may only occur if the package has never been associated with any customer's account. Once a package has been associated with at least one customer's account, the package cannot be deleted. It's stop date can be changed, based on the previously defined mles, to a date that no longer allows the package to be offered to customers. Package Redefinition Once Offered

In a preferred method, once a package is defined and customers begin receiving it, no package components can be added or deleted. If active or inactive customer accounts are currently associated with a package, then no package components can be deleted (i.e., removed). In addition, components cannot be added or deleted once a package has been defined at the corporate level and lower levels begin redefining the package. Hierarchical Control Generally

Product definition provides one example of how OMS 12 controls the operations of every other hierarchical system 30. Unless a product is defined by OMS 12, none ofthe hierarchical systems 30 may define that product. In such a manner, oversight of the operations of subsidiary components of system 10 is very efficient.

Hierarchical control by OMS 12 is preferably also provided for every other system of system 10. For example, dispatch component 84 preferably provides for hierarchical control of all dispatch operations on system 10. If the highest level of control determines that a certain repair unit in Denver should be sent to a certain customer, a user on OMS 12 having highest level access, such as a corporate user, may enter such an order. Lower levels of control, even the franchise or node level, may not override this order in a preferred embodiment.

Also, for example, if at the division level, for example, it is deteπnined that all calls from a specified customer or customers in that division should be handled at one of regional call centers 14, a division level user may enter such a command, and all telephone calls identified by telephone component 98 shall be transferred to a customer service processor at regional call center 14. Such a decision may be made, for example, if a particular customer only speaks Spanish and none of the operators at the franchise or node associated with the customer speak Spanish, but several regional call center operators speak Spanish. As can be seen, system 10 provides for top level, i.e., OMS

12, control over operations of system 10. Additionally, intermediate levels of control are provided by division office systems 16, state office systems 18, and franchise office systems 20. Lowest level control may be provided by franchise office systems 20 and/or node office systems 28. OMS 12 also controls the operations of various support systems 32 which may also be accessed by the various hierarchical control systems 30.

In addition to top-level down control, the present invention also provides a system for access by every node on the system to every other node's information. The ability to provide communications and links between customers, accounts, and service locations across system 10 is provided. This unique link between customers, accounts, and service locations allows for access to this information system wide. Customer-Account-Service Location Linking The present invention allows for a customer to have one or more accounts and one or more service locations. Also, an account preferably may only be associated with one customer. Also, an account may have one or more service locations. Further, a service location may be associated with zero, one or many customers and zero, one or many accounts.

This ability may be provided by establishing a record for each customer, account, and service location. In each record for a customer, links to a plurality of account records and service location records may be permitted. Additionally, for each account, a link to a single customer record and one or more service location records may be permitted. Further, for each service location, a link to one or more customers and one or more accounts may be permitted. The one to many relationships may be handled by migration of keys in a relational database. Keys are devices which enable components to locate information maintained on a database. By migrating a key, information may be related to other information according to standard techniques in relational database. The number of relationships may be limited to 9999 when using some interface systems.

In a preferred embodiment, a customer record may comprise the customer last name, customer first name, customer middle name, organization name, customer type, language, language type, customer ID (generated by customer support component 92), social security number (if the customer is an individual), telephone number, telephone extension, telephone type, address, drivers license number and state, customer PIN, comment information, preferences, account members name, account member relationship to customer, account member PIN, young children, old children, account number(s) (by links to account number records) and service locations (by links to service location records). An account record preferably comprises account number

(generated by customer support component 92), bill method, bill cycle, bill frequency, movie rating, altemative addresses, PIN, credit limit, account member privileges, credit card number, credit card expiration date, credit card type, bank identifier, bank account number, customer (by a link to a customer record), and service locations (by links to service location records).

A service location record preferably comprises a status, serviceability date, street number, street name, city, state, zip cope and zip extension, account type, franchise area, management area, schedule area, head end ID, amplifier ID, control number, complex number, fraction, definition, direction, unit number, building number, map coordinates, sales route, overhead/underground, legal lot, legal description, drop location, outlet number, outlet location, equipment ID, AB switch, comment information, credit card number, customers (by links to customer records), and accounts (by links to account records). Customer Service Interface

The present invention also comprises a interfacing component which has particular usefulness for customer service functions. At each terminal on the system, a copy of or access to a graphical user interface component is provided. The graphical user interface enables the user to input and receive information stored or to be stored on system 10. Typically, users access this at a customer service processor at one of the hierarchical systems 30 or at OMS 12, although any terminal on system 10 may be used, for simplicity of explanation, a customer service processor is described as the medium of access.

Flow of a portion of the graphical user interface is depicted in a flow diagram shown as Fig. 6. From any non-application space 200 at one ofthe customer service processors, the graphical user interface component may be activated. Non-application space 200 may comprise any operating system for a personal computer such as operating systems sold under the trademark DOS or Windows by Microsoft, Inc., under the trademark Macintosh by Apple, Ine, or under the trademark UNIX by Bell Laboratories, Inc. The initial operation of the graphical user interface component is to present a login window 202.

Preferably, every user has a password associated with their login name. Customer service processors accept as input a login name and password. Upon receipt of this information, an initial determination is made to ensure that the user has been defined on the system. The graphical user interface component receives the input and makes an inquiry of OMS 12 which can cross reference a user database maintained at one of the database access systems 104. If the user has been defined, information on the user's authority is passed back to the graphical user interface component. For example, the user's authority may be corporate, division, state, franchise, or node. User authority determines what actions may be taken, as described in detail above.

If the user authority is determined to be either corporate, division, or state, for example, then in one preferred embodiment, graphical user interface component transfers control to an administrative scenarios component 204. At the administrative scenarios component 204, a user may perform certain administrative functions such as adding service locations to the system, adding equipment, accepting payments, or searching for equipment, for example. At the administrative scenarios component 204, a user may either exit back to login window 202 or move to a taking calls window 206. Typically, a user with administrative authority will not receive customer service calls. However, if the user does decide to take incoming calls, then an option is presented by the administrative scenarios component 204 to move to the taking calls window 206.

A non administrative authority user is transferred by the graphical user interface component to taking calls window 206. If a user decides that he or she is not available for customer service calls, an option is presented in the taking calls window to block calls and control is transferred to a blocking calls window 208. From the blocking calls window, a user may exit back to login window 202 or he or she may move to the administrative scenarios component 204 or taking calls window 206.

Taking calls window 206 enables a user to receive incoming customer service telephone calls. Taking calls window 206 presents the user with an incoming icon or other selection device. By selecting the incoming icon, a customer service call is received. The initial function that is required to service a customer request is to identify either the customer, service location, or account about which the call is being placed. Therefore, upon selecting the incoming icon, control passes to a search window 210.

ARU units associated with the customer service processors on which the graphical user interface is operating may automatically identify the customer as is known in the art. As such, entry into search window 210 is not necessary. If an ARU unit is not operating, or is not providing calling number information, entry into search window 210 is mandatory to identify and gather information about the customer. From search window 210, a user may transfer to a commercial PPV window 214, if the caller is a commercial customer calling regarding PPV information. If the caller is non-commercial and requests other information, a search scenarios component 212 may be activated.

Search scenarios component 212 provides the ability to search for a customer, service location or account in the customer database maintained at one or more of the database access systems. A search for a customer, service location or account may be performed in a preferred embodiment, searches may be performed by one of the following methods: 1) customer name;

2) customer ID;

3) customer phone number (may be through an ARU, for example);

4) service location address; 5) service location equipment ID;

6) account number;

7) hotel and room; and

8) hotel and credit card number.

Upon a successful search, control then passes through taking calls window 206 to a selection window 216. Selection window 216 enables the user to determine which information should be presented. The user may select one or more ofthe following: an account window, a members window, a service locations window and a customer window. Each selection indicates to the graphical user interface what information to request from the customer database. In a preferred embodiment, this information is requested and transferred from the customer database to the customer service processor making the request.

From the selection window, then a user may cancel and return to taking calls window 206 or indicate approval of his or her selections and control passes to an overview window 218 (depicted as a box in Fig. 6) which contains five windows: a banner window 220, a service location window 222, a bill window 224, an account window 226 and a browser window 228. Overview window enables the user access to all or at least most of the information about a customer-service location- account link within one or two selections of buttons or icons on the overview window. Overview window thus enables a user such as a customer service representative to quickly and effectively answer or adjust most customer related information. An example of an overview window is depicted in Fig. 7 and is described in detail below.

If a customer, service location or account is not identified through search window 210, control passes through selection window 216 and banner window 220 to a customer window 230 and a check list window 232. Customer window 230 and check list window 232 may be presented simultaneously to a user and present the user with the ability to add a new customer to the customer database.

Banner window 220 contains summary information about the customer. As depicted in Fig. 7, banner window 220 may comprise a customer information portion 314 which may contain fields showing customer name, address, creation date, account type, personal identification number, and balance, for example. Banner window 220 also may contain several icons including a search icon 300 (for transferring control to search window 210), a take call icon 302 (to accept a customer service call), a block icon 304 (to transfer control to blocking calls window 208), a logs icon 306 (to move to a logs window 234), a warnings icon 308 (to move to a warnings window 236), a revert icon 310 (to restore the data to its original unedited state), and a save icon 312 (to activate any changes). Logs window 234 may provide the user with a listing of all logs compiled. For example, each customer service request may be logged. Warnings window 236 may provide the user with information about warnings

By selecting on customer information portion 314, the user may also move to a customer window. Figs. 8 and 9 depict examples of customer windows for both an individual customer (Fig. 8) and an organizational customer (Fig. 9). In customer windows, information about the customer may be altered.

Service location window 222, bill window 224, and account window 226 may comprise a plurality of panels which enable the window to provide larger amounts of information in a more readable fashion. Each panel may provide different information and may be selected by clicking on a tab represented at the top of the panel. For example, in Fig. 7, an address panel 238 of service location window 222 may be selected when a user, using an input device such as a mouse, for example, selects a tab 260 which is placed at the top of address panel 238. When a panel is selected, the contents of the panel are presented overlying the contents of other panels in the same window.

In a preferred embodiment, service location window 222 may comprise an address panel 238, a contents panel 240 and a legal panel 242. When a panel is selected, the graphical user interface system passes control to that panel. In a preferred embodiment, customer service representative users do not have authority to change the address of a service location without first going to a dispatch window 258 which operates with dispatch component 84 of OMS 12 to dispatch a service unit to dislocate at the current address and/or hook up service at a new service location.

Address panel 238 preferably comprises fields for creation date, street number, street fraction, street direction, street type, city, state, zip, country, county, franchise, and sales route, for example, as depicted in Fig. 7. Contents panel 240 preferably comprises fields for room number, room ID, room location, type, outlet number, cable ready, AB switch, splitter used, equipment function, equipment serial number, equipment model, and equipment brand, for example, as depicted in contents panel 240 of Fig. 10. Legal panel 242 may comprise fields for service date, subdivision name, geographical location/map, complex, building type, amp ID, catl ID, latitude, longitude, overhead, drop description, description, legal description, legal lot number, and right of entry, for example, as depicted in Fig. 11.

Bill window 224 may comprise two panels, a bill payment panel 244 and a bill ledger panel 246 as depicted in Fig. 7. Bill payment panel 244 may comprise fields for a bill to location, billing name, and billing address, for example. From this window, control may be passed to an address edit window 270 if the customer wishes to change the address for billing purposes. In a preferred embodiment bill payment panel 244 may further comprise three sub-panels which may be activated by selecting a node 275 on bill payment panel 244, for example. Bill ledger panel 246 may comprise fields to display payments, charges and other bill related data, for example. From either bill payment panel 244 or bill ledger panel 246, a user may view an image of bill through bill image window 276. Bill image window 276 provides an image which depicts exactly what the customer's bill will look like for a specified billing cycle. The subpanels for bill payment panel 244 may comprise a statement subpanel 262 (depicted in Fig. 7), account subpanel 264 (depicted in Fig. 12), and credit card subpanel 266 (depicted in Fig. 13), for example. Statement subpanel 262 may comprise fields for statement frequency, statement billing cycle, and statement due date, for example. Account subpanel 264 may comprise fields for a bank ID, bank account number, billing frequency, billing cycle and billing due date, for example. Credit card subpanel 266 may comprise fields for a credit card number, credit card expiration month, expiration year, billing frequency, billing cycle and billing due date, for example.

Account window 226 may comprise four panels: a products panel 248 (depicted in Fig. 14), a members panel 250 (depicted in Fig. 7), an outlets panel 252 (depicted in Fig. 15), and a details panel 254 (depicted in Fig. 16), for example. Products panel 248 may comprise fields for products, schedule date, price, and frequency of charge. Products panel 248 may also comprise several icons, for example, a disconnect icon 280, a pay-per-view icon 282 and a sell icon 284. By selecting disconnect icon 280 or sell icon 284, control passes to an order processing window 278 for adding or deleting products or services. By selecting pay-per-view icon 282, control passes to a pay-per-view window 286 for ordering pay-per-view events.

Members panel 250 may comprise fields for member names, member relations, member account privileges and pay-per-view privileges. Icons for adding and deleting members may also be provided. Outlets panel 252, an example of which is depicted in Fig. 15, may comprise fields for outlet names, outlet number, outlet products, outlet price range and outlet price, for example. If a user desires to change outlets, pricing, etc., control transfers to order processing window 278. Details panel 254, an example of which is depicted in Fig. 16, may comprise fields for last modification, creation date, account number, account type, account product type, credit line, personal identification number and mailing address, for example. Should the user request that the mailing address be changed, control passes to address edit window 270 for servicing that request.

Browser window 228 comprises a depiction of the arrangement of bill, account, and service location for a particular customer. A particular account or service location which may have been selected is indicated as selected, for example, as service location Logan in Fig. 7. An icon is presented in browser window 228 to enable the user to enlarge browser window 228 to be presented on the entire screen in place of the overview window.

Browser window 228 shows the context of overview window 218 and allows insertion, deletion, and display of various nodes associated with the customer. The nodes may comprise customer- >account->(member -> product-> service location -> room -> outlet -> equipment), where the members, products, and service locations can be presented in parallel. The arrows used in describing the nodes above represent columns in the browser, for example. By single clicking with a mouse, or other input device, for example, on a particular node and holding the mouse button down (alternatively, with a keyboard, the user may hold down the shift key while pressing the down arrow), a drop down menu appears showing the user the actions which may be taken for that particular node. To display a column to the right of the selected column, Expand may be chosen from the drop down menu for the node which is currently selected. When expand is chosen from an account node, an hierarchical menu appears giving the choice of expanding on members, service locations, or products. When service location is chosen, another hierarchical menu is presented to enable a user to expand either active or inactive service locations or both. A collapse command may also be presented in the drop down menu which provided the oppose of the expand. New and delete are also options provided in the drop down menu. As illustrated above, the present invention provides a graphical user interface which provides an overview window. This overview window allows a user such as a customer service representative located at any terminal on system 10 to access all or at least most of the information about any customer-account-service location relationship which is stored in the customer database within one click on a tab or node. This provides for global information, support, and changes because all requests for information and changes are funneled through OMS 12. Thus, a distributed network with information sharing is provided and a unique and easy manner of accessing provides for efficient operation. While this invention has been described with reference to specific embodiments, it is not intended that the invention been limited thereto. The invention is only limited by the claims which follow.

Claims

CLAIMSWe claim:

1. A system for providing a product to a plurality of customers, the system being accessed by a plurality of users, each user having an authority from authority level A = 1 to n, with n being the highest authority level, the system comprising: memory means for storing a plurality of product records; at least a first input means for inputting from an n-level authority user n-level parameters to define a product; at least a first processor means, operatively connected to the memory means and the first input means, for creating an n-level product record comprising the n-level parameters and storing the n-level product record in the memory means; a plurality of second input means for inputting from a level 1 authority user level 1 parameters to redefine a product having an n-level product record, wherein the level 1 parameters are more specific than the n-level parameters; a plurality of second processor means, operatively connected to the memory means and to one of the second input means, for creating a level 1 product record comprising the n-level parameters and the level 1 parameters and storing the level 1 product record in the memory means; and a plurality of third processor means, operatively connected to the memory means, for accessing the memory means to receive one of the level 1 product records and providing a product to a plurality of customers according to the parameters of that level 1 product record.

2. The system of claim 1 further comprising: a plurality of third input means for inputting from a level m authority user level m parameters, wherein m may be from 2 to n-l, to redefine a product having an n-level product record, wherein the level m parameters are more specific than the n-level parameters and any p-level parameters in any p-level records, wherein p may be from m+1 to n-l ; a plurality of fourth processor means, operatively connected to one of the third input means and the memory means, for creating a level m product record comprising the n-level parameters, any level p parameters and the level m parameters; and wherein each level m record has one or more level 1 product record which are derived therefrom and wherein each of those level 1 product records comprise all of the level m parameters for the level m record from which it derives and all of the level 1 parameters in those level 1 product records are more specific than the level m parameters.

3. The system of claim 1 wherein the n-level parameters comprise maximum price and minimum price and wherein the level 1 parameters comprise an offer price and wherein the offer price must be less than or equal to the maximum price and greater than or equal to the minimum price.

4. The system of claim 2 wherein the n-level parameters comprise an n-level maximum price and an n-level minimum price and wherein the m-level parameters comprise an m-level maximum price and an m-level niinimum price and wherein the m-level maximum price must be less than or equal to the n-level maximum price and the m- level minimum price must be greater than or equal to the n-level minimum price.

5. The system of claim 1 wherein the n-level parameters comprise an n-level product start date and wherein the level 1 parameters comprise a level 1 product start date which is later than or equal to the n-level product start date.

6. The system of claim 1 wherein the product comprises a package comprising two or more products.

7. The system of claim 1 wherein the first processor means and each of the second processor means are distributed on a wide area network.

8. The system of claim 7 wherein the memory means is distributed on the wide area network.

9. The system of claim 2 wherein the first processor means, the second processor means, and the fourth processor means is distributed on a wide area network.

10. The system of claim 1 wherein the product comprises a cable television channel, the system further comprising: a television located at a service location for a customer; channel providing means connected to the television; and wherein one ofthe third processor means controls the channel providing means to provide the cable television channel according to one ofthe level 1 product records.

11. The system of claim 1 wherein each level 1 authority user may define a level 1 product record provided by exactly one processor means.

12. The system of claim 2 wherein each level m authority user may define a level m product record provided by a subset of all ofthe third processor means.

13. A method of providing a product to a plurality of customers by a plurality of users, each user having an authority from authority level A = 1 to n, with n being the highest authority level, the method comprising: inputting from an n-level authority user n-level parameters to define a new product; creating an n-level product record comprising the n-level parameters input by the n-level authority user; storing the n-level product record in the memory means; inputting from at least one level 1 authority user level 1 parameters to redefine a product having an n-level product record, wherein the level 1 parameters are more specific than the n-level parameters; creating a level 1 product record comprising the n-level parameters and the level 1 parameters, wherein each level 1 authority user may create a separate level 1 product record; storing the level 1 product record in the memory means; and supplying a product to a plurality of customers according to the parameters of a level 1 product record which is assigned to the customer.

14. The method of claim 13 further comprising the steps of: inputting from a level m authority user level m parameters, wherein m may be from 2 to n-l, to redefine a product having an n-level product record, wherein the level m parameters are more specific than the n-level parameters and any p-level parameters in any p-level records, wherein p may be from m+1 to n-l ; creating a level m product record comprising the n-level parameters, any level p parameters and the level m parameters, wherein each level m authority user may create a separate level m product record; and wherein each level m record has one or more level 1 product records which are derived therefrom and wherein each of those level 1 product records comprise all of the level m parameters for the level m record from which it derives and wherein each ofthe level 1 parameters from those level 1 product records are more specific than the level m parameters.

15. The system of claim 13 wherein each level 1 authority user may define a level 1 product record which is provided by exactly one third processor means.

16. The system of claim 14 wherein each level m authority user may define a level m product record which is provided by only a subset of all of the third processor means.

17. A system for operating a cable television network, the network comprising a plurality of customers each associated with one or more accounts and with one or more service locations, comprising: an operational management system comprising: a main processor means; memory means for storing customer records, account records, and service location records, for associating each customer record with at least one account record and at least one service location record, for associating each account record with at least one customer record and at least one service location record, for associating each service location record with at least one customer record and at least one account record; and at least one main customer service processor means for accessing the memory means and providing a customer with information contained in any customer record, any service location record, and any account record stored in the memory means; a plurality of node office systems operatively connected to the operational management system, each node office system having a plurality of customers, service locations and accounts associated therewith, each node office system comprising: means for providing a cable television product to a service location associated with that node office system; and node customer service processor means for accessing the memory means and providing information contained in any customer record, any service location record, and any account record stored in the memory means and for requesting creation of new customer records for customers of any of the plurality of node office systems, service location records for service locations connected to any of the plurality of node office systems, and account records for accounts associated with any of the plurality of node office systems; and wherein the main customer service means further comprises means for requesting creation of new customer records for customers of any of the plurality of node office systems, service location records for service locations connected to any of the plurality of node office systems, and account records for accounts associated with any of the plurality of node office systems.

18. The system of claim 17 wherein the plurality of node office systems and the operational management system are distributed over a wide area network.

19. The system of claim 17 further comprising a plurality of intermediate office systems each comprising intermediate customer service processor means for accessing the memory means and providing infoπnation contained in any customer record, any service location record, and any account record stored in the memory means and for requesting creation of new customer records for customers of any ofthe plurality of node office systems, service location records for service locations connected to any ofthe plurality of node office systems, and account records for accounts associated with any of the plurality of node office systems

20. A system for operating a cable television network, the network comprising a plurality of customers each associated with one or more accounts and with one or more service locations, comprising: memory means for storing customer records, account records, and service location records, for associating each customer record with at least one account record and at least one service location record, for associating each account record with at least one customer record and at least one service location record, for associating each service location record with at least one customer record and at least one account record; and at least one customer service processor means, operatively connected to the memory means, for accessing the memory means for information contained in any customer record, any service location record, and any account record stored in the memory means, said customer service processor means comprising: input means for receiving a customer service request; access means for retrieving at least one customer record, at least one account record, and at least one service location record in response to the customer service request; and means for displaying a graphical user interface comprising a banner window, an account window, and a service location window; wherein the banner window comprises fields for customer related information; wherein the account window comprises fields for account related information; and wherein the service location window comprises fields for service location related infoπnation.

21. The system of claim 20, wherein the customer service requests comprise either a customer request, an account request, a service location request, or a bill request; wherein each customer record is associated with one or more account record and one or more service location records; wherein each account record is associated with one or more customer records and one or more service location records; and wherein each service location record is associated with one or more customer records and one or more account records.

22. The system of claim 21 wherein in response to a customer request, the access means retrieves a single customer record, every account record, and every service location record associated with the customer.

23. The system of claim 21 wherein in response to a service location request, the access means retrieves a single service location record, every account record, and every customer record associated with the service location.

24. The system of claim 21 wherein in response to an account request or a bill request, the access means retrieves a single account record, every customer record, and every service location record associated with the account.

25. The system of claim 21 wherein the graphical user interface further comprises a browser window, the browser window displaying a schematic diagram of the customer, service locations and accounts retrieved from the customer records, service location records and account records.

26. The system of claim 25 wherein the service location window displays information about a service location which is selected from the browser window.

27. The system of claim 25 wherein the account window displays information about an account which is selected from the browser window.

28. The system of claim 25 wherein the customer window displays information about a customer which is selected from the customer window.

29. An apparatus for providing customer service to customers of a cable television network, the network comprising a plurality of customers each associated with one or more accounts and with one or more service locations, comprising: computer means for storing customer related information, account information, and service location information; a display means, operatively connected to the computer means, for displaying a graphical user interface, the graphical user interface comprising a banner window, an account window, and a service location window; wherein the banner window comprises fields for displaying a first set of customer related fields and means for displaying a second set of customer related fields, the first and second set of customer related fields collectively comprising all of the customer information for a customer; wherein the account window comprises a first set of account related fields and means for displaying a second set of account related fields, the first and second set of account related fields collectively comprising the account related information for all accounts associated with the customer; and wherein the service location window comprises a first set of service location related fields and means for displaying a second set of service location related fields, the first and second set of service location related fields collectively comprising the service location information for all service locations associated with the customer.

30. The apparatus of claim 29 wherein the means for displaying comprise tabs.

31. The apparatus of claim 29 wherein the means for displaying comprise nodes.

32. The apparatus of claim 29 wherein the graphical user interface further comprises a browser window, the browser window displaying a schematic diagram ofthe customer, service locations and accounts retrieved from the customer records, service location records and account records.

33. The system of claim 32 wherein the service location window displays information about a service location which is selected from the browser window.

34. The system of claim 32 wherein the account window displays information about an account which is selected from the browser window.

35. The system of claim 32 wherein the customer window displays infoπnation about a customer which is selected from the customer window.