WO1997024691A1 - Subscriber management system and method - Google Patents

Subscriber management system and method Download PDF

Info

Publication number
WO1997024691A1
WO1997024691A1 PCT/US1996/020125 US9620125W WO9724691A1 WO 1997024691 A1 WO1997024691 A1 WO 1997024691A1 US 9620125 W US9620125 W US 9620125W WO 9724691 A1 WO9724691 A1 WO 9724691A1
Authority
WO
WIPO (PCT)
Prior art keywords
product
customer
level
record
account
Prior art date
Application number
PCT/US1996/020125
Other languages
French (fr)
Inventor
William Rierden
David J. Gollob
James R. Logan
Kurt A. Deshazer
Scott Stodghill
Wesley E. Munsil
Mark Marusin
Original Assignee
Tele-Communications, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tele-Communications, Inc. filed Critical Tele-Communications, Inc.
Priority to AU13363/97A priority Critical patent/AU1336397A/en
Publication of WO1997024691A1 publication Critical patent/WO1997024691A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2543Billing, e.g. for subscription services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866Management of end-user data
    • H04N21/25891Management of end-user data being end-user preferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/162Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/165Centralised control of user terminal ; Registering at central

Definitions

  • the present invention relates generally to the field of computer networks and applications and more specifically, to computer networks for operating customer-oriented systems. More specifically, the present invention relates to a computer network and a series of applications ninning thereon for interconnecting and operating multiple cable business units.
  • BACKGROUND OF THE INVENTION Cable television has become enormous 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.
  • MSO multiple system operator
  • Bill production can be another difficult task when business hierarchies become large and complex. The reason for this is twofold. First, the sheer volume of data to be processed can be problematical. Secondly, the complexities ofthe interrelationships between customers, accounts and services can lead to confusion, increased processing time and the potential for errors. With each of the local systems and MSOs establishing individual pricing for products, services, and packages, the process for generating bills for each individual subscriber can become complex, time consuming and error prone. Often, the time required to process a billing cycle can be excessive. This can cause numerous negative effects on the operation ofthe business including delay in receiving revenue, confused or hostile customers and late bills. Moreover, since many architectures employ the same servers for database requests originating from both OLTP and batch processes, an extended billing batch can have a long term negative impact on system performance from an OLTP standpoint.
  • a third area in which current systems for handling the operation of large business entities are deficient involves the way in which data is accessed in performing the above and other tasks.
  • the telecommunications industry and particularly the cable television industry have a particularly great need for storage and manipulation of large amounts of data.
  • Cable system operators typically maintain large databases contaimng a variety of subscriber, product and billing information.
  • Typical classes of information managed by cable companies include subscriber accounts, available products and their pricing structure, physical assets and their functionality and marketing data. It is often desirable to distribute this information across a network of databases whether or not they are located at the same physical location.
  • the processing requirements for cable based systems can be staggering. For example, it may be necessary to provide 24 hour a day, 7 day a week service for a subscriber base of millions or tens of millions of subscribers. In addition, such a system may be called upon to execute hundreds or thousands of transactions per second (TPS). In addition, such systems may be required to support thousands of interactive users operating client terminals (e.g. Customer Service Representatives (CSRs)) many of which may be concurrent users. It is further anticipated that the average customer record may soon be on the order of 15 kilobytes requiring a total database capacity of about 225 Gigabytes (assuming 15 million subscribers).
  • CSRs Customer Service Representatives
  • a typical distributed database system that may be employed by a system operator includes a plurality of transaction generators or terminals which may be operated by CSRs to acquire access to data contained within the system.
  • Each of the transaction generators communicates either directly or through a communications controller with a particular associated server or servers.
  • Commumcation techniques and protocols which are known in the art are employed to allow the transaction generators to communicate with the servers. For example, EthernetTM may be used when both client and server are PC-based processors.
  • An example of such a system exhibiting the drawbacks described above may include four data processing centers to support a national cable system operator.
  • Each of four geographical regions in the United States e.g. Northeast, Southeast, Midwest and West
  • all records for customers of the system operator who reside in Pennsylvania would be stored at the Northeast data center in its associated database.
  • the subscriber may call in to a CSR operating a transaction generator connected with the Northeast database.
  • the CSR using the transaction processor, can simply generate a request for information regarding that subscriber.
  • the subscriber may call in to an Automatic Response Unit (ARU) having an Automatic Number Indicator (ANI) interface and a similar request for information would be generated automatically.
  • ARU Automatic Response Unit
  • ANI Automatic Number Indicator
  • the problem arises when the same Pennsylvania subscriber also maintains a business account across the border in Ohio. Even though both accounts are serviced by the same system operator, a single call by the Pennsylvania/Ohio subscriber will not permit him or her to receive information about both accounts. This is because the Ohio account information will be located at and serviced by the Midwest data center.
  • the subscriber Since the transaction processor at the Northeast data center has no connection to the Midwest data base and since the transaction processor at the Midwest data center has no connection to the Northeast data base, the subscriber is forced to first call the Northeast data center for information about the residential account and then the Midwest data center for information about the business account. In addition, this subscriber is likely to receive two separate billing statements, one from each data center.
  • each of the customer records is completely contained on one physical server while the whole of its associated database and the enterprise domain of all customers is spread across all servers.
  • a fourth area in which customer oriented data processing systems have been less than satisfactory is in the area of the interface which is used by Customer Service Representatives (CSRs) to interact with the system.
  • CSRs Customer Service Representatives
  • Interfaces to date have been cumbersome and often require a CSR to scroll and page through large amounts of information before arriving at the desired information or data entry field. As can be imagined, this can significantly increase the time period during which a customer must be on the phone with a CSR in order to complete a transaction or receive requested information.
  • customers can become frustrated with the delays they may encounter when calling CSRs. Further, longer call times translate into less throughput per available CSR. Thus, customers may wind up waiting in order to even begin talking to a CSR. Alternatively, it may become necessary to hire additional CSRs in order to alleviate delays which are unacceptable to customers.
  • the present invention comprises a system and method for allowing various users to coordinate, track and manage business tasks necessary for delivering cable television products and services.
  • the present invention is described in the context of a cable television business environment, its teachings may be applied on a broader scale to include any business operation which requires such coordination, tracking and managing of its business tasks.
  • the system of the present invention allows users to quickly access customer and field personnel information, market expanding and diversified services, make informed business decisions and quickly access a variety of corporate and lower level information.
  • the system further enables efficient access to data located in a centralized database including dispatching information, addressability information, billing mformation, lockbox information and credit card data.
  • the architecture ofthe system allows for communication and coherency between the corporate business unit, regional service centers, individual cable systems, and other business units. Remote locations may be added to provide expanded service such as for automated call routing in the case of overload at a particular site.
  • the system is defined by a plurality of node office systems which are connected to an 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.
  • 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 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.
  • the system operates so as to associate related data in a unique manner.
  • a plurality of customers are associated with one or more accounts and with one or more service locations, and memory is allocated 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 includes 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.
  • the system of the present invention further includes a unique subsystem and method for data access and storage.
  • At least one Data Directory Server (DDS) is included and is located between one or more transaction generators and one or more data servers.
  • the DDS efficiently routes transactions and provides data location functions.
  • the DDS provides high data availability, high on-line transaction rates, batch capabilities, scalability and maintainability.
  • the DDS routes transactions to the appropriate server(s).
  • Transactions are classified according to where they may be executed. Specifically, transactions may be classified as SPECIFIC, ANY or ALL.
  • a SPECIFIC transaction must be processed at one or more specific servers irrespective ofthe accompanying arguments.
  • An ANY transaction may be processed at any ofthe servers and selection is made psuedorandomly.
  • An ALL transaction requires processing by each ofthe data servers.
  • a cable provider is generally any entity which has a franchise or other legal right to allow that entity to provide cable television prograrnming.
  • a customer is generally the person or legal entity (an individual or a company) that is financially responsible for programming and other services purchased from a cable provider.
  • 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, prograrnming and other services.
  • 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.
  • the product may be anything from Home Box Office to installation.
  • a product parameter is generally any parameter which defines the product.
  • Product parameters may include product name, product availability, or product pricing, to list just a few.
  • BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 depicts an overall system architecture according to one embodiment of the present invention.
  • Fig. IB depicts a schematic of the hierarchical structure of 13
  • 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. 4A is a flowchart illustrating the bill production process according to one embodiment of the present invention.
  • Fig. 5 depicts an operational management system according to one embodiment ofthe 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 ofthe 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 ofthe 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 of the present invention.
  • Fig. 13 depicts a bill window according to another embodiment of the 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 ofthe present invention.
  • Fig. 16 depicts an account window according to yet another embodiment of the present invention.
  • 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.
  • 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 may comprise an architecture in which five hierarchical levels exist. This is illustrated in Figure IB.
  • 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.
  • operational management system 12 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.
  • operational management system 12 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.
  • operational management system 12 may comprise an architecture in which five hierarchical levels exist. This is illustrated in Figure IB.
  • 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.
  • operational management system 12 may be operational management system 12, divisional office systems 16, state
  • each system of hierarchical system 30 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 ofthe present invention.
  • OMS 12 controls a plurality of divisional office systems 16.
  • 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.
  • 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.
  • state office system l,p controls franchise systems l,p,l 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.
  • 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.
  • 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.
  • 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.
  • state office system 18 may be similar to divisional office system 16.
  • 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.
  • 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.
  • Node office system 28 comprises a node processor 50 connected to WAN 100.
  • Node processor 50 may comprise one or more sub processors.
  • 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 ofthe service locations assigned to node office system 28.
  • Administration subsystem 54 may control internal operations ofthe 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.
  • 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.
  • the processing components comprise a product/rating component 82, a dispatch component 84, an extemal 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.
  • OPS 80 may be distributed physically and /or logically so that each ofthe processing components 82-99 may reside on a separate OPS or various individual processing components may be grouped together on associated OPSs.
  • each of the processing components may perform a variety of functions.
  • Product/rating component 82 may be responsible for defming 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 are 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 external interface component 86 may be responsible for collections processes, subscriber payment maintenance such as credit card interfaces, lockbox interfaces, electronic funds transfer, drop box, cashiers, check-in process, and collection agencies, bill rendering, refund check rendering, and product usage payments, for example.
  • External interface component 86 is the main component for interacting with support systems 32 and may function to communicate with other external 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, internal collections, write-off processing, subscriber notifications, marketing inserts, bill reprints, adjustments and credits, bill formatting, cash processing-payment, and bill archiving, for example.
  • Bill production component 88 completes a bill batch according to three distinct subprocesses.
  • Figure 4 A is a flowchart generally describing the broad steps in bill production according to the present invention.
  • the first subprocess is termed Bill Production Initiator (BPI).
  • BPI serves the general function of waking up periodically and initiating a billing cycle.
  • the BPI selects the billing work within the OMS 12 that needs to be processed for the specified billing cycle.
  • the second subprocess in completing bill production is the Bill Production Manager (BPM). Multiple BPMs may be operable at any one time. Each BPM preferably corresponds to a particular billing run for a particular business unit.
  • a BPM may be created for a billing run on the 15th of the month (billing cycle) for one particular node office (cable operator).
  • Each BPM processes the billing work specified by the BPI in order to divide the work up into manageable units. Work is further divided by the BPM such that the most efficient overall processing takes place.
  • the last major process in bill production as performed by billing component 88 is the Bill Production Worker (BPW).
  • BPW Bill Production Worker
  • post production activities may occur. These activities may occur as part ofthe BPW process itself, requiring completion prior to BPW processing being considered completed. Alternatively, the post production activities may be separately processed following BPW processing but prior to actual bill rendering. In a preferred embodiment, the post production activities occur automatically as part ofthe bill production processing, however, post production activities may alternately be manually instituted upon certain events such as the completion of a BPW process.
  • Post production activities may include, for example, storing a copy of a bill image as generated by the BPW in the database for later access by a CSR on-screen in case a customer wishes to discuss an old or newly generated bill.
  • a CSR on-screen in case a customer wishes to discuss an old or newly generated bill.
  • Another post production activity may be further steps in preparing the bill run for transmission to a bill renderer.
  • a header file may be created indicating such things as the number of bills following the header for the particular run, special fonts that will need to be accessed during printing of the subsequent bills, inserts that need to be included during preparation of the subsequent bills or special images that will need to be accessed during the printing of the subsequent bills.
  • bill production component 88 must necessarily interface with other components of operational management system 12 in performing the bill generation process.
  • bill production component 88 must interface with addressability component 90, for example when bill production component 88 determines that an account is past due during the aging process.
  • bill production component 88 causes addressability component 90 to place, for example, a pay-per-view inhibit flag on the subscriber's account and converter box.
  • bill production component 88 interfaces with bill rendering system 290 such that bill production component 88 supplies all data necessary for bill rendering system 290 to print bills suitable for delivery to subscribers.
  • 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, netiink 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.
  • 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 internal interface component 94 is generally responsible for various functions within the corporate structure.
  • the internal interface component 94 may comprise an accounting interface, equipment inventory, payroll/commissions, marketing interface, plant management, budget integration, and CIS functionality.
  • Internal 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 internal information, computer- based training, audits and controls, and address maintenance. Global component 97 may also perform other functions.
  • miscellaneous component 99 is preferably provided to perform other functions not performed by another components of OPS 80.
  • miscellaneous component 99 may be responsible for disaster recovery, facilities, implementation planning, architecture, GUI error 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 international support.
  • Miscellaneous component 99 may also perform other functions.
  • additional miscellaneous components 99 may be provided, if desired.
  • OMS 12 further comprises a plurality of database access systems 104.
  • database access systems 104 One ofthe features ofthe present invention is that all global 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 defined. Data definition is described in greater detail below.
  • 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. 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.
  • each database access system 104 may comprise a customer data server 110, a dispatch data server 1 12, 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, administration 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 component 88, addressability component 90, customer support component 92, internal 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 preferred 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.
  • 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 commumcation link.
  • DDSs 106 are represented as being connected over WAN 100.
  • 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 DDSs 106.
  • OPS 80 is separately connected to each DDS 106.
  • each customer data server 110 is separately connected to each DDS 106.
  • 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 of the present invention is designed to manage a very large number of OLTP transactions occurring within the system.
  • the system ofthe present invention provides users with the ability to query across the entire database from any element in the system.
  • 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 fransmirting that input to the Data Directory Servers (DDSs) 106.
  • each of the components ofthe 28 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 internal rules used by DDS(s) 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 internal 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.
  • ARU/ANI Automatic Interactive Voice Response Unit/Automatic Number Indicator
  • DDSs 106 ofthe 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 communication 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.
  • 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 internal 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.
  • DDSs 106 may be open servers comprising the same or similar hardware as data servers 107 ofthe present invention.
  • 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 rules, 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.
  • the data servers 107 are Sybase SQL Servers which execute Sybase 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.
  • DDSs 106 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 internal requests generated as a result of DDS processing itself. The event handlers are as follows:
  • 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.
  • 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.
  • Connect Handler The connect handler is executed whenever a client connects to the DDS.
  • Disconnect Handler The disconnect handler is executed whenever a client terminates an active connection to the DDS.
  • 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.
  • RPC Handler The Remote Procedure Call handler carries the bulk ofthe 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.
  • Error Handlers Several error 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.
  • 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.
  • 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.
  • 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 ofthe 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 Sybase (a trademark of Sybase, 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 rules 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 dete ⁇ nining where specific data resides in the system and for storing the rules 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.
  • 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.
  • the DDS application consults the DDS Server Table (a global table) which identifies all of the available and accessible data servers 107.
  • DDS Server Table a global table
  • XRef Server Table global
  • An additional global table is the Error Message Handler Table which maintains all error 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.
  • 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.
  • 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 internal DDS memory at DDS startup.
  • DDS 106 submits a request to XRef Server 108 in order to retrieve the necessary data.
  • DDS 106 has available to it the necessary rules 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.
  • 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.
  • 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".
  • 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.
  • DASs 104 The operations of DASs 104 according to one embodiment ofthe 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 copending and which is hereby inco ⁇ orated by reference.
  • Fig. 5 depicts another configuration illustrating the connections of the various components of DAS 104.
  • 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 1 10, dispatch data server 112, bill data server 116 and miscellaneous data server 120.
  • Several of the extemal processors 32 may also be connected to WAN 100.
  • bill printing system 22 and accounting system 26 may be provided with access to DDSs 106.
  • 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.
  • each of the components are directly connected.
  • each customer service processor 102 is preferably directly connected to a DDS 106.
  • each data server 107 is preferably connected directly to a DDS.
  • a replication server is a server that generates a duplicate copy ofthe information located on a primary server. In a preferred embodiment, when at least two DAS's
  • each DAS 104 has an associated replication server 107.
  • CUSTD 2 may have the same information as CUSTL 2.
  • 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.
  • Product/rating component 82 is responsible for product definition, pricing, packaging and the like. According to a preferred embodiment ofthe 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 Definition
  • 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.
  • 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.
  • 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 defmed products; a product start date and stop date; product category and product type for example.
  • product categories including entertainment, pay-per-view, package, equipment rental, merchandise, work order, and special, for example.
  • entertainment product category there may be several product types including basic, expanded basic, game, premium, and audio, for example.
  • pay-per-view product category there may be several product types including PPV event, PPV movie, PPV adult, and PPV game, for example.
  • package product category there may be several product types including recurring and one-time, for example.
  • 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.
  • products are defined by the creation of a record by product/rating component 82 and stored in one or more of data servers 107.
  • 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 ofthe 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 niinimum price, and corporate maximum price may be mandatory product parameters.
  • fields may include channel position, range, franchise rate, channel number, price effective date, network, frequent buyer points, marketing description, internal, commission, inclusions/exclusions, equipment dependencies, authorization codes, division suggested price, division minimum price, division maximum price, state suggested price, state mimmum 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.
  • 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 rules. 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.
  • 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.
  • product/rating component 82 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.
  • 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.
  • products may only be defined at lower levels if that product has been defined at the highest level.
  • 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 ofthe 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.
  • Node office systems 28 and franchise systems 20 may offer services, for example. In order for these offices to provide the products defined at the highest level, the products must also be defined at the level of their office. Product definition 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.
  • the user requests a product definition 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.
  • the product/rating component initiates a search through database access system 104 to identify a record for the product at the desired business unit.
  • 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.
  • 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.
  • the product/rating component 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.
  • 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.
  • 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 niinimum and maximum price which are higher and lower, respectively, ofthe minimum and maximum price ofthe 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.
  • the price may be set at $6.00. If a division record is modified such that the division niinimum price is $8.00, then the price at the node level would not longer be valid and would have to be modified.
  • the product/rating component adjusts the times from the corporate, division, and state product definitions for the event.
  • 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.
  • product/rating component 82 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 may be a number which uniquely identifies the product. The corporate user may also enter other parameters which may be provided for the product.
  • 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 minimized 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.
  • the corporate level product record for ABC 123 is copied to generate a State A level ABC 123 product record.
  • 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.
  • 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.
  • 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.
  • a package is one particular type of product for which additional information is entered to define the product.
  • 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.
  • 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.
  • 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 Showtime. 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.
  • 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.
  • 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.
  • 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.
  • 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 defined by a package name, package long name, package category (automatically set to "package"), package type (either recurring or one-time), corporate package rninimum 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 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 ofthe products which form the package components is at least as late as the package stop date.
  • 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.
  • package definition also includes package allocation parameters.
  • 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.
  • a revenue split percentage is defined as a package parameter.
  • 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.
  • Showtime is given a revenue split percentage of 40% and Cinemax is given a revenue split percentage of 20%.
  • 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)
  • the Cinemax revenue split is calculated to be $4 (20% multiplied by $20).
  • 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.
  • 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
  • the revenue split is entered for the package component.
  • the package component's revenue split percentage is set to 0% and cannot be changed as long as the fixed revenue indicator exists.
  • the calculation ofthe 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.
  • 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).
  • 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 ofthe 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.
  • revenue splits and revenue split percentages may only be modified at the highest level of control, for example, the corporate level.
  • 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.
  • a state business unit changes the suggested retail price from $20 to $24.
  • 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.
  • 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.
  • Multi-outlet pricing can be a flat dollar charge only.
  • the multi-outlet price can be defined 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.
  • 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.
  • 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
  • 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 of the 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.
  • dispatch component 84 preferably provides for hierarchical control of all dispatch operations on system 10. If the highest level of control dete ⁇ nines 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.
  • 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.
  • 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 ofthe operators at the franchise or node associated with the customer speak Spanish, but several regional call center operators speak Spanish.
  • 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.
  • OMS 12 also controls the operations of various support systems 32 which may also be accessed by the various hierarchical control systems 30.
  • 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.
  • the present invention allows for a customer to have one or more accounts and one or more service locations.
  • an account preferably may only be associated with one customer.
  • an account may have one or more service locations.
  • 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.
  • links to a plurality of account records and service location records may be permitted.
  • a link to a single customer record and one or more service location records may be permitted.
  • a link to one or more customers and one or more accounts may be permitted.
  • 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, alternative 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).
  • the present invention also includes an interfacing component which has particular utility for customer service functions.
  • an interfacing component which has particular utility for customer service functions.
  • 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.
  • users access this at a customer service processor at one ofthe 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, Inc, or under the trademark UNIX by Bell Laboratories, Inc.
  • the initial operation of the graphical user interface component is to present a log in window 202.
  • Every user has a password associated with their log in name.
  • Customer service processors accept as input a log in 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.
  • the user's authority may be corporate, division, state, franchise, or node. User authority deteirnines what actions may be taken, as described in detail above.
  • graphical user interface component transfers control to an administrative scenarios component 204.
  • an administrative scenarios component 204 a user may perform certain administrative functions.
  • a user may either exit back to log in window 202 or move to a taking calls window 206.
  • a user with administrative authority will not receive customer service calls.
  • an option is presented by the adrninistrative 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 log in 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 mcoming 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:
  • customer ID may be through an ARU, for example
  • control 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 of the 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.
  • 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 ofthe 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.
  • 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, and a save icon 312 (to activate any changes).
  • 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
  • logs icon 306 to move to a logs window 234)
  • warnings icon 308 to move to a
  • 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
  • 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 ofthe 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 ofthe panel are presented overlying the contents of other panels in the same window.
  • service location window 222 may comprise an address panel 238, a contents panel 240 and a legal panel 242.
  • the graphical user interface system passes control to that panel.
  • 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.
  • 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
  • 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.
  • disconnect icon 280 or sell icon 284 control passes to an order processing window 278 for adding or deleting products or services.
  • pay-per-view icon 282 control passes to a pay-per-view window
  • 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 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.
  • Expand may be chosen from the drop down menu for the node which is currently selected.
  • an hierarchical menu appears giving the choice of expanding on members, service locations, or products.
  • 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.
  • 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 ofthe 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.
  • a distributed network with information sharing is provided and a unique and easy manner of accessing provides for efficient operation.

Abstract

A system and method for allowing users to coordinate, track and manage business tasks necessary for delivering products and services. The system comprises an operational management system (12), hierarchical systems (30), and support system (32) connected over a wide area network (100). Hierarchical systems (30) 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 the wide area network (100).

Description

SUBSCRIBER MANAGEMENT SYSTEM AND METHOD
FIELD OF THE INVENTION
The present invention relates generally to the field of computer networks and applications and more specifically, to computer networks for operating customer-oriented systems. More specifically, the present invention relates to a computer network and a series of applications ninning thereon for interconnecting and operating multiple cable business units. 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.
One particular problem involves the definition of products and services. 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.
Bill production can be another difficult task when business hierarchies become large and complex. The reason for this is twofold. First, the sheer volume of data to be processed can be problematical. Secondly, the complexities ofthe interrelationships between customers, accounts and services can lead to confusion, increased processing time and the potential for errors. With each of the local systems and MSOs establishing individual pricing for products, services, and packages, the process for generating bills for each individual subscriber can become complex, time consuming and error prone. Often, the time required to process a billing cycle can be excessive. This can cause numerous negative effects on the operation ofthe business including delay in receiving revenue, confused or hostile customers and late bills. Moreover, since many architectures employ the same servers for database requests originating from both OLTP and batch processes, an extended billing batch can have a long term negative impact on system performance from an OLTP standpoint.
Another drawback of currently existing systems with respect to the bills that they generate is the treatment of data in a discrete fashion. For example, account data, service location data and subscriber data are not cohesively related. Various pieces of information, although logically related, are treated as separate abstractions without any relationship between such data represented in the system. Thus, in the case of an individual (e.g. a landlord with multiple rental units) having multiple accounts in different physical locations, multiple bills -one for each rental unit -would generally have to be generated for that single individual. This has obvious drawbacks including increased overall bill processing time, increased postage costs, inconvenience to the subscriber and resource (e.g. paper) waste.
Yet another problem existing in current billing applications relates to error handling. Often, during batch processing of bills, the processing of a particular bill will result in an error. Typically, current systems will respond to this event by discarding the batch, manually processing the bill causing the error or even removing that bill from the batch and then restarting the batch from the beginning. This scenario will often take place even if the batch has been nearly completed at the time that the error occurs. As is apparent to one of skill in the art, such treatment is undesirable in that system resources will be strained to complete the same batch portions multiple times.
A third area in which current systems for handling the operation of large business entities are deficient involves the way in which data is accessed in performing the above and other tasks. The telecommunications industry and particularly the cable television industry have a particularly great need for storage and manipulation of large amounts of data. Cable system operators typically maintain large databases contaimng a variety of subscriber, product and billing information. Typical classes of information managed by cable companies include subscriber accounts, available products and their pricing structure, physical assets and their functionality and marketing data. It is often desirable to distribute this information across a network of databases whether or not they are located at the same physical location.
The processing requirements for cable based systems can be staggering. For example, it may be necessary to provide 24 hour a day, 7 day a week service for a subscriber base of millions or tens of millions of subscribers. In addition, such a system may be called upon to execute hundreds or thousands of transactions per second (TPS). In addition, such systems may be required to support thousands of interactive users operating client terminals (e.g. Customer Service Representatives (CSRs)) many of which may be concurrent users. It is further anticipated that the average customer record may soon be on the order of 15 kilobytes requiring a total database capacity of about 225 Gigabytes (assuming 15 million subscribers).
A typical distributed database system that may be employed by a system operator includes a plurality of transaction generators or terminals which may be operated by CSRs to acquire access to data contained within the system. Each of the transaction generators communicates either directly or through a communications controller with a particular associated server or servers. Commumcation techniques and protocols which are known in the art are employed to allow the transaction generators to communicate with the servers. For example, Ethernet™ may be used when both client and server are PC-based processors.
In current systems, difficulty arises when access to data residing at differing locations is required. This places a burden on the CSR (or a transaction generator in general) because it may impose additional processing requirements to keep track of what data is accessible to a particular CSR and which is not. Additionally, if certain data is needed, but not accessible to a particular CSR, it may be necessary to determine where the data is located and which CSR may have access to that data.
An example of such a system exhibiting the drawbacks described above may include four data processing centers to support a national cable system operator. Each of four geographical regions in the United States (e.g. Northeast, Southeast, Midwest and West) may be supported by one of the four data processing centers. In such a case, all records for customers of the system operator who reside in Pennsylvania would be stored at the Northeast data center in its associated database. In the event that a particular Pennsylvania subscriber is at home and desires to receive information about his or her account the process is relatively simple. The subscriber may call in to a CSR operating a transaction generator connected with the Northeast database. The CSR, using the transaction processor, can simply generate a request for information regarding that subscriber. Alternatively, the subscriber may call in to an Automatic Response Unit (ARU) having an Automatic Number Indicator (ANI) interface and a similar request for information would be generated automatically. The problem, however, arises when the same Pennsylvania subscriber also maintains a business account across the border in Ohio. Even though both accounts are serviced by the same system operator, a single call by the Pennsylvania/Ohio subscriber will not permit him or her to receive information about both accounts. This is because the Ohio account information will be located at and serviced by the Midwest data center. Since the transaction processor at the Northeast data center has no connection to the Midwest data base and since the transaction processor at the Midwest data center has no connection to the Northeast data base, the subscriber is forced to first call the Northeast data center for information about the residential account and then the Midwest data center for information about the business account. In addition, this subscriber is likely to receive two separate billing statements, one from each data center.
An additional drawback with this hypothetical system becomes evident when it is necessary to obtain system wide data. For example, a system operator may desire to retrieve data based upon subscriber demographics. Suppose, for example, the marketing department wishes to generate an alphabetical list ofthe names and addresses of all subscribers, system wide, who are over the age of 30 and subscribe to ESPN. It is necessary, using the above described system, to separately access data within each ofthe four regions. Once data from each of the regions is gathered, it is further necessary to merge the data originating from each of the regions to generate one comprehensive list. The problems which are illustrated in this example are exacerbated when more than four data processing centers are used.
The method of distribution of customer records in the above example is known in the art as horizontal data distribution. In the above case, each of the customer records is completely contained on one physical server while the whole of its associated database and the enterprise domain of all customers is spread across all servers.
A fourth area in which customer oriented data processing systems have been less than satisfactory is in the area of the interface which is used by Customer Service Representatives (CSRs) to interact with the system. Interfaces to date have been cumbersome and often require a CSR to scroll and page through large amounts of information before arriving at the desired information or data entry field. As can be imagined, this can significantly increase the time period during which a customer must be on the phone with a CSR in order to complete a transaction or receive requested information. As a result of these less than satisfactory user interfaces, customers can become frustrated with the delays they may encounter when calling CSRs. Further, longer call times translate into less throughput per available CSR. Thus, customers may wind up waiting in order to even begin talking to a CSR. Alternatively, it may become necessary to hire additional CSRs in order to alleviate delays which are unacceptable to customers. 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 ofthe present systems.
It is an object of the present invention to provide centralized product definition 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 ofthe 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 the information about customers and accounts located anywhere within the system. It is a further object ofthe present invention to provide a batch processing system having minimal impact on the performance of OLTP transactions.
It is a still further object of the present invention to provide a billing system which allows for centralized control over billing operations.
It is yet another object of the present invention to provide a billing system which logically reflects relationships among the data to be processed. It is a yet further object of the present invention to provide a system which can effectively and rapidly process large billing batches.
It is a still further object of the present invention to provide a system wherein a batch need not be restarted from the begirming in the event a single batch component fails. It is a further object of the current invention to provide a distributed database system capable of high speed transaction processing.
It is a yet further object of the invention to allow database access while eliminating the need for time consuming processes normally associated with such access. It is a still further object ofthe invention to provide server selection based upon a rules base allowing fast and efficient access to distributed information.
It is an even further object of the present invention to provide a distributed database system in which particular servers may be designated for the servicing of requests based upon the nature or type of request to be serviced.
It is a yet further object of the present invention to provide a system having an easy to use and logical interface so that customer service representatives may easily and rapidly interface with and use the system.
Accordingly, the present invention comprises a system and method for allowing various users to coordinate, track and manage business tasks necessary for delivering cable television products and services. Although the present invention is described in the context of a cable television business environment, its teachings may be applied on a broader scale to include any business operation which requires such coordination, tracking and managing of its business tasks.
The system of the present invention allows users to quickly access customer and field personnel information, market expanding and diversified services, make informed business decisions and quickly access a variety of corporate and lower level information. The system further enables efficient access to data located in a centralized database including dispatching information, addressability information, billing mformation, lockbox information and credit card data. The architecture ofthe system allows for communication and coherency between the corporate business unit, regional service centers, individual cable systems, and other business units. Remote locations may be added to provide expanded service such as for automated call routing in the case of overload at a particular site.
The system is defined by a plurality of node office systems which are connected to an 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 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.
According to another aspect ofthe present invention, the system operates so as to associate related data in a unique manner. Specifically, a plurality of customers are associated with one or more accounts and with one or more service locations, and memory is allocated 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 includes 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.
The system of the present invention further includes a unique subsystem and method for data access and storage. At least one Data Directory Server (DDS) is included and is located between one or more transaction generators and one or more data servers. The DDS efficiently routes transactions and provides data location functions. The DDS provides high data availability, high on-line transaction rates, batch capabilities, scalability and maintainability. In particular, based upon internal rules and the particular transaction type, the DDS routes transactions to the appropriate server(s). Transactions are classified according to where they may be executed. Specifically, transactions may be classified as SPECIFIC, ANY or ALL. A SPECIFIC transaction must be processed at one or more specific servers irrespective ofthe accompanying arguments. An ANY transaction may be processed at any ofthe servers and selection is made psuedorandomly. An ALL transaction requires processing by each ofthe data servers. 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. DEFINITIONS
In order to aid in the explanation of the objects and advantages of the present invention, the following definitions are provided. A cable provider is generally any entity which has a franchise or other legal right to allow that entity to provide cable television prograrnming.
A customer is generally the person or legal entity (an individual or a company) that is financially responsible for programming 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, prograrnming 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 defines the product. Product parameters may include product name, product availability, or product pricing, to list just a few. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 depicts an overall system architecture according to one embodiment of the present invention.
Fig. IB depicts a schematic of the hierarchical structure of 13
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. 4A is a flowchart illustrating the bill production process according to one embodiment of the present invention. Fig. 5 depicts an operational management system according to one embodiment ofthe 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 ofthe 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 ofthe 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 of the present invention.
Fig. 13 depicts a bill window according to another embodiment of the 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 ofthe present invention. Fig. 16 depicts an account window according to yet another embodiment of the 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 may comprise an architecture in which five hierarchical levels exist. This is illustrated in Figure IB. 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 ofthe 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,l 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 ofthe service locations assigned to node office system 28. Administration subsystem 54 may control internal operations ofthe 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 extemal 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 ofthe 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 defming 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 are 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 external interface component 86 may be responsible for collections processes, subscriber payment maintenance such as credit card interfaces, lockbox interfaces, electronic funds transfer, drop box, cashiers, check-in process, and collection agencies, bill rendering, refund check rendering, and product usage payments, for example. External interface component 86 is the main component for interacting with support systems 32 and may function to communicate with other external 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, internal collections, write-off processing, subscriber notifications, marketing inserts, bill reprints, adjustments and credits, bill formatting, cash processing-payment, and bill archiving, for example.
Bill production component 88 completes a bill batch according to three distinct subprocesses. Figure 4 A is a flowchart generally describing the broad steps in bill production according to the present invention. The first subprocess is termed Bill Production Initiator (BPI). The BPI serves the general function of waking up periodically and initiating a billing cycle. The BPI selects the billing work within the OMS 12 that needs to be processed for the specified billing cycle. The second subprocess in completing bill production is the Bill Production Manager (BPM). Multiple BPMs may be operable at any one time. Each BPM preferably corresponds to a particular billing run for a particular business unit. For example, a BPM may be created for a billing run on the 15th of the month (billing cycle) for one particular node office (cable operator). Each BPM processes the billing work specified by the BPI in order to divide the work up into manageable units. Work is further divided by the BPM such that the most efficient overall processing takes place. Finally, the last major process in bill production as performed by billing component 88 is the Bill Production Worker (BPW). There are preferably multiple BPW processes rurming at a single time such that each of the work groupings specified by the BPW may be processed by a BPW process. Further, multiple BPW processes allow for parallel processing of the bill production workload. The ultimate result ofthe BPWs (and the billing component 88 in general) is the generation of individual bills for customers.
Upon completion ofthe BPW processes, various post production activities may occur. These activities may occur as part ofthe BPW process itself, requiring completion prior to BPW processing being considered completed. Alternatively, the post production activities may be separately processed following BPW processing but prior to actual bill rendering. In a preferred embodiment, the post production activities occur automatically as part ofthe bill production processing, however, post production activities may alternately be manually instituted upon certain events such as the completion of a BPW process.
Post production activities may include, for example, storing a copy of a bill image as generated by the BPW in the database for later access by a CSR on-screen in case a customer wishes to discuss an old or newly generated bill. Thus an archive database of customer bills is maintained within the system for some period of time so that images may be called up wherein the images will match the hard copies generated and mailed by the bill renderer. Another post production activity may be further steps in preparing the bill run for transmission to a bill renderer. For example, a header file may be created indicating such things as the number of bills following the header for the particular run, special fonts that will need to be accessed during printing of the subsequent bills, inserts that need to be included during preparation of the subsequent bills or special images that will need to be accessed during the printing of the subsequent bills.
It is important to realize that bill production component 88 must necessarily interface with other components of operational management system 12 in performing the bill generation process. For example, bill production component 88 must interface with addressability component 90, for example when bill production component 88 determines that an account is past due during the aging process. In this case bill production component 88 causes addressability component 90 to place, for example, a pay-per-view inhibit flag on the subscriber's account and converter box. Similarly, and as is apparent to one of skill in the art, bill production component 88 interfaces with bill rendering system 290 such that bill production component 88 supplies all data necessary for bill rendering system 290 to print bills suitable for delivery to subscribers. 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, netiink 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 internal interface component 94 is generally responsible for various functions within the corporate structure. For example, the internal interface component 94 may comprise an accounting interface, equipment inventory, payroll/commissions, marketing interface, plant management, budget integration, and CIS functionality. Internal 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 internal 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 error 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 international 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 are described in greater detail below. OMS 12 further comprises a plurality of database access systems 104. One ofthe features ofthe present invention is that all global 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 defined. 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. 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 110, a dispatch data server 1 12, 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, administration 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 component 88, addressability component 90, customer support component 92, internal 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 preferred 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 commumcation link. Additionally, each DDS 106 is connected via a two-way communication link to one or more cross reference servers (X-ref, - X-re , 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 DDSs 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 of the present invention is designed to manage a very large number of OLTP transactions occurring within the system. The system ofthe 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 fransmirting that input to the Data Directory Servers (DDSs) 106. In a preferred embodiment, each of the components ofthe 28 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 internal rules 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 internal 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 ofthe 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 communication 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 internal rules, 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 internal 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 ofthe 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 rules, 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 Sybase SQL Servers which execute Sybase 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 internal 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 ofthe 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 error 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 of the 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 ofthe 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 Sybase (a trademark of Sybase, 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 rules 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 deteπnining where specific data resides in the system and for storing the rules 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 of the 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 error 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 internal 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 rules 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 ofthe 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 copending and which is hereby incoφorated by reference. Fig. 5 depicts another configuration illustrating 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 1 10, dispatch data server 112, bill data server 116 and miscellaneous data server 120. Several of the 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 ofthe 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 ofthe 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 ofthe 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 ofthe 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 Definition
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 defmed 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 ofthe 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 niinimum 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, internal, commission, inclusions/exclusions, equipment dependencies, authorization codes, division suggested price, division minimum price, division maximum price, state suggested price, state mimmum 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 rules. 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 ofthe 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 defined at the highest level, the products must also be defined at the level of their office. Product definition 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 definition 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 defmed 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 niinimum and maximum price which are higher and lower, respectively, ofthe minimum and maximum price ofthe 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 niinimum 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 of the 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 may be 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 minimized 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 nunimum 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 ofthe 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 Showtime. 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 defined by a package name, package long name, package category (automatically set to "package"), package type (either recurring or one-time), corporate package rninimum 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 ofthe 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 definition 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 ofthe 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 ofthe 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 defined 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 of the 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 deteπnines 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 determined 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 ofthe 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.
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, alternative 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 includes an interfacing component which has particular utility 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 ofthe 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, Inc, or under the trademark UNIX by Bell Laboratories, Inc. The initial operation of the graphical user interface component is to present a log in window 202.
Preferably, every user has a password associated with their log in name. Customer service processors accept as input a log in 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 deteirnines 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.
At the administrative scenarios component 204, a user may either exit back to log in 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 adrninistrative 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 log in 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 mcoming 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 of the 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 ofthe 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, 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 ofthe 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 ofthe 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 ofthe 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 ofthe 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

WE CLAIM:
1. A system for managing products, services and customers comprising: an operational management system comprising an operational processing system, a database access system and at least one customer service processor; at least one hierarchical system, said operational management system communicating with said at least one hierarchical system through a network.
2. The system of claim 1 wherein said network is a wide area network.
3. The system of claim 1 further comprising at least one support system.
4. The system of claim 1 wherein said at least one hierarchical system comprises at least one divisional office system and at least one node office system.
5. The system of claim 1 wherein said at least one state office system and at least one node office system.
6. The system of claim 1 wherein said at least one hierarchical system comprises at least one divisional office system, at least one state office system, at least one franchise system and at least one node office system.
7. The system of claim 1 wherein said operational processing system includes a billing production component.
8. The system of claim 1 wherein said operational processing system includes a product/rating component.
9. The system of claim 7 wherein said billing production component comprises: means for monitoring a current time and date; means for generating a file containing customer bill records to be processed; means for distributing the customer bill records into groups based upon the geographical location ofthe customer; means for dividing the groups into one or more subgroups, wherein each customer bill distributed into each subgroup shares at least one common property; means for dividing the subgroups into processing groups, wherein the number of customer bills records distributed into each processing group is predeteirnined and; processor means for processing the customer bill records from at least one of the processing group files.
10. The system of claim 8 wherein said product/rating component is operative to provide 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, said product/rating component 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 said memory means and said at least one input means, for creating an n-level product record comprising the n-level parameters and storing the n-level product record in said memory means; a plurality of second input means for mputting 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 said memory means and to one ofthe 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 ofthe level 1 product records and providing a product to a plurality of customers according to the parameters of that level 1 product record.
11. The system of claim 10 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 nunimum price.
12. The system of claim 1 wherein said database access system comprises: a plurality of data servers; and data directory server means in communication with said operational processing system and each of said data servers, said data directory server means receiving database transactions from said transaction generator means and selecting at least one data server for processing each said database transaction. 78
13. The system of claim 12 further comprising at least one cross-reference server, said cross-reference servers providing data location information to said data directory servers.
14. The system of claim 12 wherein said plurality of data servers operate in parallel to process a plurality of database transactions concurrently.
15. The system of claim 1 wherein said system supports a plurality of customers each associated with one or more accounts and with one or more service locations and wherein: said database access system stores 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, and for associating each service location record with at least one customer record and at least one account record; said at least one customer service processor accessing said database access system for information contained in any customer record, any service location record, and any account record stored in said database access system, said customer service processor further 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, the account window comprises fields for account related information and the service location window comprises fields for service location related information.
16. The system of claim 15 wherein the customer service requests comprise either a customer request, an account request, a service location request, or a bill request and wherein each customer record is associated with one or more account records and one or more service location records, each account record is associated with one or more customer records and one or more service location records and each service location record is associated with one or more customer records and one or more account records.
17. A subscriber management system comprising: an operational management system, said operational management system operative for controlling the delivery and billing of products and services; a plurality of node office systems, said node office systems communicating with said operational management system over a network, each of said node office systems being associated with a plurality of customers, service locations and accounts; a distributed database system including a plurality of data servers and at least one data directory server, said distributed database system being accessible for reading and writing data by said operational management system and by each of said node office systems.
18. The system of claim 17 wherein each of said node office systems comprises a cable television product delivery device, said product delivery device delivering a cable television product to a service location associated with said node office system.
19. The system of claim 17 wherein said node office system comprises at least one node customer service processor, said node customer service processor accessing customer, account and service location data associated with said node office system.
20. The system of claim 17 wherein said operational management system comprises a product/rating component, a bill production component and a customer service component.
PCT/US1996/020125 1995-12-29 1996-12-24 Subscriber management system and method WO1997024691A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU13363/97A AU1336397A (en) 1995-12-29 1996-12-24 Subscriber management system and method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US58173295A 1995-12-29 1995-12-29
US08/581,732 1995-12-29
US71437396A 1996-09-16 1996-09-16
US08/714,373 1996-09-16

Publications (1)

Publication Number Publication Date
WO1997024691A1 true WO1997024691A1 (en) 1997-07-10

Family

ID=27078404

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/020125 WO1997024691A1 (en) 1995-12-29 1996-12-24 Subscriber management system and method

Country Status (2)

Country Link
AU (1) AU1336397A (en)
WO (1) WO1997024691A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6351738B1 (en) * 1999-05-24 2002-02-26 Douglas W. Clark Collective business system
US7124101B1 (en) 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US7127415B1 (en) * 1999-11-16 2006-10-24 Regency Ventures Ltd. Method and system for acquiring branded promotional products
US7130807B1 (en) * 1999-11-22 2006-10-31 Accenture Llp Technology sharing during demand and supply planning in a network-based supply chain environment
US7216086B1 (en) * 2001-04-30 2007-05-08 Cisco Technology, Inc. Method and apparatus providing a supply chain management system useful in outsourced manufacturing
US8694391B2 (en) 1999-11-16 2014-04-08 David Verchere Method and system for configurating products
US9922345B2 (en) 1999-11-22 2018-03-20 Accenture Global Services Limited Increased visibility during order management in a network-based supply chain environment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247575A (en) * 1988-08-16 1993-09-21 Sprague Peter J Information distribution system
US5410598A (en) * 1986-10-14 1995-04-25 Electronic Publishing Resources, Inc. Database usage metering and protection system and method
US5600573A (en) * 1992-12-09 1997-02-04 Discovery Communications, Inc. Operations center with video storage for a television program packaging and delivery system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410598A (en) * 1986-10-14 1995-04-25 Electronic Publishing Resources, Inc. Database usage metering and protection system and method
US5247575A (en) * 1988-08-16 1993-09-21 Sprague Peter J Information distribution system
US5600573A (en) * 1992-12-09 1997-02-04 Discovery Communications, Inc. Operations center with video storage for a television program packaging and delivery system

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6351738B1 (en) * 1999-05-24 2002-02-26 Douglas W. Clark Collective business system
US7127415B1 (en) * 1999-11-16 2006-10-24 Regency Ventures Ltd. Method and system for acquiring branded promotional products
US8694391B2 (en) 1999-11-16 2014-04-08 David Verchere Method and system for configurating products
US7124101B1 (en) 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US7130807B1 (en) * 1999-11-22 2006-10-31 Accenture Llp Technology sharing during demand and supply planning in a network-based supply chain environment
US7957991B2 (en) 1999-11-22 2011-06-07 Accenture Global Services Limited Technology sharing during demand and supply planning in a network-based supply chain environment
US8560366B2 (en) 1999-11-22 2013-10-15 Accenture Global Services Limited Technology sharing during demand and supply planning in a network-based supply chain environment
US9922345B2 (en) 1999-11-22 2018-03-20 Accenture Global Services Limited Increased visibility during order management in a network-based supply chain environment
US10013705B2 (en) 1999-11-22 2018-07-03 Accenture Global Services Limited Increased visibility during order management in a network-based supply chain environment
US7216086B1 (en) * 2001-04-30 2007-05-08 Cisco Technology, Inc. Method and apparatus providing a supply chain management system useful in outsourced manufacturing
US7426478B2 (en) 2001-04-30 2008-09-16 Cisco Technology, Inc. Method and apparatus providing a supply chain management system useful in outsourced manufacturing

Also Published As

Publication number Publication date
AU1336397A (en) 1997-07-28

Similar Documents

Publication Publication Date Title
US5696906A (en) Telecommunicaion user account management system and method
US6493680B2 (en) Method and apparatus for processing billing transactions
AU680266B2 (en) Display based marketing message control system and method
US5873068A (en) Display based marketing message control system and method
US6601041B1 (en) Method of providing targeted advertisements to a computer mediated communications network
WO1997024688A9 (en) Method and aparatus for processing billing transactions
US5416833A (en) Method and apparatus for provisioning a public switched telephone network
US5826270A (en) Methods and systems for client or customer-site transaction processing in a distributed database system
JP4503948B2 (en) Service providing method and telecommunication platform
US5953406A (en) Generalized customer profile editor for call center services
US20020199182A1 (en) Method and apparatus providing convergent solution to end-to end, adaptive business application management
US6332124B1 (en) Method and system for managing magazine portfolios
US6421652B2 (en) Method and system for qualifying consumers for trade publication subscriptions
US20020194143A1 (en) Method and system for usage-based pricing of E-content
CN1199479A (en) Interactive marketing network and process using electronic certificates
US20050081188A1 (en) Method and apparatus for providing integrated customer care and work-flow management
US7620654B2 (en) System and method providing user definable on-line wage and salary reports
WO1997024691A1 (en) Subscriber management system and method
US20020181689A1 (en) System and method for modeling resources for calls centered in a public switch telelphone network
WO1997024687A1 (en) Method and apparatus for hierarchical control of a distributed processing network
Dykman et al. Lufkin-Conroe Telephone Exchange Meets the Challenge of the
JP2002175239A (en) Information display device, information distribution device, and display data distribution method in system that connects the devices
Boyd Architecture Patterns for Business Systems
CN102100027A (en) Revenue management system and method
Lin James Lin, Taiwan Fixed Network Company

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM

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

Ref country code: JP

Ref document number: 97524379

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase