CA2302327A1 - A customer care and billing system separating identity and relationship characteristics - Google Patents

Abstract

A customer care and billing system that separates identity information from customer information. An customer entity object maintains relationships of the customer to system features, such as a customer account.
A separate identity entity object provides identity information, such as, name for the customer, and other person-type objects. The entity object can be linked to plural objects which represents persons or organizations allowing a single entity object to store the identity information for a number of objects.
The entity object and for example, a customer object are linked allowing the relationships of an individual with the system to be identified through the links. The entity object can also be linked to an entity role object that identifies the roles, such as, bill recipient, an individual or organization has in the system.

Description

~,; , ~x r - 1 - 1330.1048 A Customer Care And Billing System Separating Identity And Relationship Characteristics Reference To Appendix A microfiche appendix is included herewith having 2 fiche and having 141 frames.
BACKGROUND OF THiE INVENTION
Field of the Invention The present invention is directed to a system that separates information associated with individuals or organizations from the relationships those individuals or organizations have with a telecommunications system and, more particularly, to a system that provides an entity object, which identifies the personal characteristics of an individual or organization, that can be linked to any number of objects that identify the roles, i.e., customer or bill recipient, the individual or organization has within the system.

- 2 - 1330.1048 Description of the Related Art In a traditional telecommunications customer care and billing system, a customer represents a real individual or organization that has subscribed (or is considering subscribing) to services from the telecommunications provider. A customer is typically modeled as a single table or object that includes the customer's name and address(es), billing preferences, tax circumstances, etc. Similarly, if a traditional system is sophisticated enough to support actions such as sending a copy of an account's bill to someone other than the customer, billing an account to someone other than the customer, or designating an individual as a contact person for a specific account or subscription, these types of interactions are also modeled as a single table or object which includes the individual's name and address(es), etc. In other words, traditional systems do not separate information about individuals and organizations that a customer designates to act on the customer's behalf in certain capacities related to the customer's business relationship with the telecommunications provider from the representations of those designations themselves. In many cases, this straight-forward approach is acceptable, but as competition increases in the telecommunications industry, and telecommunications providers offer more varied and flexible customer service arrangements, the limitations of this model prove to be a disadvantage for the telecommunications provider.
What is needed is a system in which the identifying information for an individual or organization in a system is stored separate from the information that represents the interactions, i.e., roles the individual or organization has with the telecommunications provider.
SUMMARY OF THE INVENTION
It is an object of the present invention to store identifying information for an individual or organization in the system separate from the - 3 - 1330.1048 information that represents the interactions the individual or organization has with the telecommunications provider.
It is also an object of the present invention to store the identifying information for an individual or organization only once.
It is an additional object of the present invention to reuse the identifying information in the system.
It is a further object of the system to use the interaction information to easily and accurately identify all the ways in which an individual or organization interacts with the telecommunications provider.
It is another object of the system to utilize the architecture of separate interaction and identifying information to introduce advanced customer care and billing processes that encourage customer loyalty and mitigate risk.
The above obj ects can be attained by a system, such as a teleconununications customer care and billing system, that stores identifying information, such as name and tax ID, separate from information that represents the interactions, such as a customer or bill recipient, an individual or organization has with a telecommunications provider. The present invention utilizes an entity object to store the identifying information. An instance of the entity object represents a real world individual or organization to the system, and is used by the system, through relationships rather than duplication of data; to give an identity to the various ways that individual or organization interacts, e.g., as a customer or bill recipient, with the telecommunications provider.
These together with other objects and advantages, which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout.

- 4 - 1330.1048 BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is an example of a typical object model containing a set of objects and relationships according to the present invention.
Figure 2 illustrates the hardware and software configuration of relevant components of a current implementation of the invention.
Figure 3 is a process flow illustrating how an entity object is created and associated to typical telecommunications objects.
Figure 4 is a process flow illustrating how the invention is used to enhance the user interface by identifying all the ways in which a single individual or organization interacts with the system.
Figure 5 is a process flow illustrating how the invention is used to implement checks within the system to prevent undesired processing.
Figure 6 is a process flow illustrating how the system uses the invention to identify for the billing process a specific individual or organization name to place on a bill.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
As competition increases in the telecommunications industry and businesses steadily introduce complexity into their telecommunications arrangements, telecommunications providers are finding that it is not uncommon to have more than one type of interaction with an individual or organization. For example, an individual may interact with the telecommunications provider on behalf of his household, and he may also interact at some level with the telecommunications provider on behalf of his employer. The same individual may also receive a copy of a family member's bill because he has signed as a co-guarantor of the family member's telecommunications charges. In a traditional model, this individual's personal information must be re-entered for each role the individual has in the system (in this case a residential customer, contact person for his employer, and as a - 5 - 1330.1048 bill recipient and co-guarantor for the family member's telecommunications charges). By storing separately the identity information of a role (e.g., customer, contact person, bill recipient, co-guarantor, etc.) an individual or organization may have in the system, that identity information (e.g., name, addresses, phone numbers, etc.) need only to be entered once, and is simply re-used.
The present invention is an approach to modeling and organizing identity information in a customer care and billing system designed to support telecommunications providers, and the way a telecommunications provider views the ways it interacts with an individual or organization. The invention introduces a way of separating identity information (i.e., 18~ person characteristics) of an individual or organization from the arrangements (e.g:, services, billing preferences, etc.) the individual or organization has with the telecommunications provider.
~ An individual or organization in the context of the present invention is modeled as an entity, i.e., an entity is further qualified as an individual or organization. The present invention introduces a normalized representation of individuals and organizations, i.e., entities, and how they are represented in a customer care and billing system given the interactions they can have with a telecommunications provider. The result of this normalization is the introduction of the concept of a role that is modeled in the system as an entity role, which captures a single type of interaction (i.e., a customer or bill recipient) an entity may have with the telecommunications provider. And personal identity information of an entity role in the system is stored in an entity object, separate from the entity role object itself. For example, a customer is a type of role an entity can have in the system. A
customer object still maintains all of its business relationships to accounts, subscriptions, and the like, but the customer object now gets its identity, the - 6 - 1330.1048 information which identifies a single individual or organization, from a relationship to an entity object. The benefits of this design are:
creation and maintenance of identifying information is simplified because normalizing it into entity objects helps to minimize duplication of data in the system by storing all the identifying information for an individual or organization only once instead of with each role that the individual has in the system, entities can be re-used within the system when an individual or organization has more than one role within the system, such as a bill recipient or a co-guarantor of subscribed services, the invention continues to support, with little or no degradation of performance, all traditional customer care and billing activities such as billing a customer or identifying a contact person for a large business customer, and the invention readily allows for new and dynamic customer care and billing activities such as evaluating all the ways a given individual or organization interacts with the , telecommunications provider.
The invention isolates and stores the identifying information of an entity that interacts with a telecommunications provider. By isolating identifying information, re-use of that information is easily achieved for the potential roles that an entity in the system has such as a bill recipient, a co guarautor of an account, or a contact person for a single subscription or an entire company.
The invention is preferably implemented using object-oriented technology in a language such as C++. Figure 1 is an object model that illustrates logical objects and their relationships of the invention. One of skill in the art will readily recognize that each object can be implemented in the - 7 - 1330.1048 database as a table, as an object, or part of a de-normalized table or object.
Included in the object model for several objects are sample attributes that are intended to help clarify what each object represents. The lines between the objects represent relationships between the objects, including polarity (i.e., whether a relationship is required or optional, and how many relationships can be established between a given instance of one object and available instances of the related object). The text and arrows on the-relationship lines are included to offer additional insight into the relationship between two objects. Using the object names and relationship information (e.g., text, arrow direction, and polarity) simple sentences can be constcvcted to help understand the relationships. For example, the relationship between the Entity 12 object (identifying information) and Entity Role 24 object (interaction information) can be read as "any specific Entity 12 may take on zero-to-many Entity Roles 24," and "any specific Entity Role 24 must be related to exactly one Entity 12."
In Figure 1, the Customer 14 object (a form of interaction information) represents the business aspects of a customer of the telecommunications provider, i.e., telecommunications-specific attributes and relationships to objects such as Contract 32 and Account 36. For the present invention, the Customer 14 object is limited in the sense that the identity of the individual or organization who is the customer is not captured in the Customer 14 object. Rather, a relationship to the identity of the customer is captured in the abstract Entity 12 object, which is further identified as either an Individual 16 or Organization 18 specialization object.
The Entity 12 object is important to the invention, because this object enables the system to capture information, including multiple instances of Address 20 or Contact Information 22 for an Entity 12, i.e., for an Individual 16 or Organization 18 and store it independent of telecommunications-specific information such as Customer 14 or Bill - 8 - 1330.1048 Recipient 30. Once this has been established, the Entity 12 information is available for re-use by objects in the system that require identity information, such as name, address, or tax ID number, in order to be complete.
The abstract object Entity Role 24, which is a generic object designed to represent the different roles an Individual 16 or Organization 18 can have with the system, coordinates relationships with other objects for its specialization objects Co-guarantor 26, Contact Role 28, and Bill Recipient 30. A person of ordinary skill in the art of object oriented design will recognize that the polarity of the relationship between Entity 12 and Entity Role 24 illustrates how the system supports a single Individual 16 or Organization 18, which again are specializations of an Entity 12, having more than one Entity Role 24, and that any given instance of Entity Role 24 can be related to only one Entity 12. The objects Contract 32, Subscription 34, Account 36, and Provisioning Order 38 are included in Figure 1 to offer insight into a telecommunications customer care and billing system to help illustrate the meaningfulness of the abstract Entity Role 24 object and its specialization objects Co-guarantor 26, Contact Role 28, and Bill Recipient 30. For example, an Individual 16's role as the contact person for a specific Account 36 is established through relationships between the abstract objects Entity 12 and Entity Role 24, and between Contact Role ~28 and Account 36.
The object model in Figure 1 illustrates how other Entity Role 24 objects may be appropriate for applications other than telecommunications customer care and billing can be easily added.
Note that a Customer 14 object has some characteristics that are similar to the Entity Role 24 object, but that the Customer 14 object is not modeled as a specialization of the abstract Entity Role 24 object because of its unique relationships with other objects and its prominence in a telecommunications customer care and billing system. In other words, an - 9 - 1330.1048 Entity 12 can also have a role of a Customer 14, even though the Customer 14 is not a specialization of Entity Role 24.
The invention has been implemented on a three-tiered client server architecture. Figure 2 illustrates how the components, i.e., tiers, of the system are separated. The client tier 40 is where the user interface operates.
No significant application processes are performed on the client tier 40, but users are able to enter data, view data, and request the system to perform actions such as searching. The application server 42 is where the majority of application processes of the system are stored and executed, although these . processes can also be distributed if an implementation requires such. The application processes, such as a customer service process like an account balance check, are either invoked 52 by the system (not shown) or a user on the client tier 40 invokes them. The application server sends 54 data requests to the database server 44, receives 54 data back, and sends 52 display-ready 1 S information to the client. The database server 44 is where the data and relationships are stored. Figure 2 illustrates how the entity 48 information described in Figure 1 is stored in separate database tables from customer 46 and entity role SO information. The database 56 and database server 44 together maintain and enforce the relationships between the tables. The processes and data structure described herein can be stored in storage available within the components described above.
Figure 3 illustrates the process of creating or identifying an Entity for use or re-use, respectively, for associating with an Entity Role or a Customer. The state of the system prior to the start of the flow illustrated in Figure 3 is not included because it is not important to the description of the invention. What is important in Figure 3 is the illustration of how information that uniquely identifies an Entity is captured, referenced, and re-used.

- 10 - 1330.1048 The flow in Figure 3 illustrates the processes for Create Customer 62, Create Co-guarantor 64, Create Contact Role 66 and Create Bill Recipient 68. Because the objects Customer, Co-guarantor, Contact Role, and Bill Recipient require information that identifies the Individual or Organization the object is modeling, then an Entity must be created or re-used during these processes. The first operations of Figure 3 highlight the interaction between a user and the system in an effort to locate an existing Entity that can be correctly used as the identity of the objects being created.
In operation 70, information such as name, date of birth, tax ID number, etc., intended to identify a single Individual or Organization, or a subset of Individuals and Organizations, is entered by a user. The details entered could also include information~such as street address, a city, an email address, or a phone number, because Address Information and Contact Information can be useful in limiting search results. The exact information included must be decided for each implementation of the present invention.
Using this information, the system searches 72 through all existing Entities and retrieves those that match the identifying information entered by the user. The system then displays 74 a list of the Entities matching the search criteria.
At this point, the user determines 76 whether the desired Entity has been retrieved by the system or not. If the desired Entity has been retrieved by the system, then the user selects 78 the desired entity, and the system conventionally creates a relationship 84 between the selected Entity and the object being created, i.e., Customer, Co-guarantor, Contact Role, or Bill Recipient. If the desired Entity has not been retrieved by the system, the user decides 80 whether or not he/she wants to retry the search. If so, the user updates the search criteria 70 to expand or limit the number of Entities retrieved, and the search 72 and display 74 processes are performed again.
Otherwise the user creates a new Entity 82, which implies that the Individual - 11 - 1330.1048 or Organization currently does not exist in the system. To create a new Entity, the user only needs to enter information 82 for the Individual or Organization that was not entered for the search 70 because the system maintains that information throughout the process, i.e., the user is not S required to re-enter information that was used for the search 72. Once the new Entity is created, the system creates a relationship 84 between the new Entity and the object being created, i.e., Customer 62, Co-guarantor 64, Contact Role 66, or Bill Recipient 68. Not shown is a conventional process that verifies the information entered by the user for the new Entity is unique.
This verification ensures that Entity information for any given Individual or Organization is entered into the system only once.
Once action 84 is complete, and the object being created is related to a valid Entity, the user completes the creation process 86 by entering the remaining information for whichever object is being created, i.e., Customer 62, Co-guarantor 64, Contact Role 66, or Bill Recipient 68.
Referring again to Figure 1, the design of the invention is that every Customer 14 and Entity Role 24 is required to have a relationship with an Entity 12 (this is illustrated by a polarity of "1" on the Entity 12 side of the relationships~between Customer 14 and Entity 12, and Entity Role 24 and Entity 12). To guarantee this requirement, the process flow illustrated in Figure 3 ensures that an Entity is associated 84 with the Customer 62, Co-guarantor 64, Contact Role 66, or Bill Recipient 68 object being created, before the creating of the object is allowed to be completed.
Once the relationships that are established between Entities and Customers, and Entities and Entity Roles are stored in the system, it becomes a simple exercise to identify all the ways in which a given Entity interacts with the system. Figure 4 is an illustration of the process 90 to accomplish this. The process for identifying 92 all the ways in which a single Entity interacts with the system (similar to the process illustrated in Figure - 12 - 1330.1048 for creating an object that requires a relationship with an Entity) begins with a user entering information 94, such as name, date of birth, tax ID number, etc., intended to identify a single Individual or Organization, or a small set of Individuals and Organizations. The details entered could also include S information such as a street address, a city, an email address, or a phone number, because Address information and Contact Information can be useful in limiting search results. The exact information included must be decided for each implementation of the present invention.
Using this information, the system searches 96 through all existing Entities and retrieves those that match the identifying information entered by the user. The system then displays 98 a list of the Entities matching the search criteria At this point, the user determines 100 whether the desired Entity has been retrieved by the system or not. If the desired Entity has not been retrieved by the system, the user deoides 102 whether or not he/she wants to retry the search. If so, the user updates the search criteria 94 to expand or limit the number of Entities retrieved, and the search 96 and display 98 processes are performed again. Or, the user has the option of.
abandoning the search if the process has been attempted several times without success.
Once the desired Entity has been retrieved by the system, the user selects 104 the desired entity, and the system immediately retrieves 106 all related customer and entity role objects, by following the relationships of the selected entity to those objects, and then the system displays them 108 for the user. Not shown is the flexibility of the system at this point to allow the user to select any of the displayed customer or entity roles for editing or additional information.
If it were possible to achieve the same results from a traditional telecommunications customer care and billing system in which the ____ __ _T_-_ - 13 - 1330.1048 identifying information for each of the types of roles an individual or organization could have would require significantly more processing time, and in all likelihood could not be accomplished in the time it takes a customer service representative to handle a call from a customer. In other words, traditional telecommunications systems simply do not include the data structures, database tables, and data relationship representations that can be used for these purposes.
The invention can also be used to prevent undesired processes from occurring. For example, telecommunications systems have the ability to suspend the telecommunications services of a customer in the situation where the customer is delinquent in paying for those services. This process is usually triggered by an accounts receivable system. Traditionally, when the customer care and billing system receives the request from the accounts receivable system to suspend services, the customer care and billing system carries out the request at the earliest possible moment. Considering the case where a residential customer whose services the system is going to disconnect is also the contact person for a major business customer, then the telecommunications provider risks losing a major business customer as a result of suspending services for a residential customer. Figure 5 illustrates a process using the invention to prevent this situation from occurring.
Figure 5 only shows the relevant portion of a "suspend services" process. The suspend services for customer 110 process begins, and Figure 5 picks up the processing just before the invention is used. A process to calculate the average monthly revenue (call it X) for the~customer 112 is performed for the customer who is the object of the suspend process. This average will be used later to determine if there is a risk in suspending the customer. Once an average is calculated, the entity of the customer is retrieved 114 by following the mandatory relationship from the customer to its owning entity. Now the entity is used to retrieve all the entity roles 116, - 14 - 1330.1048 i.e., the co-guarantor, contact role, and bill recipient roles, of the entity.
Note that no more customers will be identified for the entity because an entity can only be related to one customer, which was known before the average revenue was calculated 112.
The number of entity roles retrieved is examined 118. If there is at least one entit,~role associated to the entity (other than the customer) then the system checks 120 to see if the entity role is related to a customer, and, if so, calculates 122 the average monthly revenue (call it ~ for that customer. The system is now able to compare 124 the average monthly revenue (X) of the customer in the suspense processing with the average monthly revenue (~ of the related customer. If the related customer generates more revenue than the customer in the suspense processing, then the system writes 126, a line out to a report for subsequent examination by an analyst to determine whether an action other than suspension of the customer is appropriate.
The process to check to see if any records for this entity were written to a report is performed 128 as a final step to determine whether or not the system will proceed with the suspension. If the entity had no report lines written for it, i.e., the entity had no entity roles (other than customer) or the entity did not have entity roles that constituted a risk for the telecommunications provider, then the suspend customer 130 process is performed. Otherwise, processing to suspend the customer is bypassed 132 to allow an analyst to evaluate the complex situation of the entity to determine what the appropriate course of action is for the telecommunications provider.
Finally, to demonstrate that the invention does not significantly, negatively impact critical telecommunications processes such as billing, refer to Figure 6, which shows the basic process flow utilizing the present invention to create a bill. The architecture of the billing process, i.e., - 1 S - 1330.1048 batch billing, continuous billing, or on-demand billing, is not relevant to the invention and is not included iri Figure 6 for simplicity.
The first action of the process is to identify all the accounts that are going to be billed 140, which could be zero or more accounts. ' The next action is to examine if there is at least one account to be billed 142.
If no accounts were identified for billing, then the process ends.
When there are accounts to be billed, they are processed one at a time. The customer who is financially responsible for paying for the charges for the current account is retrieved 144 simply by following the mandatory relationship from the account to its owning customer. Since the entity information is not stored as part of the customer information, an additional action to retrieve the entity and address information 146 is necessary, which is also accomplished by following the mandatory relationship from the customer to its owning entity.
At this point, the system is now ready to extract the unbilled events 148 for the current account, and format 150 the bill for printing using the unbilled events; customer, and entity information retrieved.
When the bill for the current account has been formatted, the process checks 142 to see if there are still more accounts to be billed, and repeats the activities, i.e., retrieve customer 144 through format bill 150, until all accounts to be billed have been processed.
The present invention provides for the isolation of person-identification in an Entity object, and for cooperation with an Entity Role object, which allows a single definition of an Entity (an Individual or Organization) to perform more than one role in a system. As a result, a system can now identify all the ways a single individual or organization interacts with the organization that maintains the system.
The present invention has been described with respect to an object-oriented system. The invention is not limited to object oriented - 16 - 1330.1048 implementations and the same concept can be implemented using different programming languages, traditional operating systems, or traditional database architectures. The invention is also not limited to systems that support the telecommunications.business. Any application that models real world people in any way such as, but not limited to, credit card billing applications, retail sales and shipping applications, health care coordination of benefits and billing applications, or any systems that model individuals or organizations, store information about them, and their interactions with a business could apply the invention. The number and types of roles an individual or organization can play is theoretically infinite; i.e., the list of possible entity roles for a telecommunications provider is not limited to Customer, Co-guarantor, Contact Role, or Bill Recipient.
The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention.to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be,resorted to, falling within the scope of the invention.

Claims (14)

What is claimed is:

1. An apparatus, comprising:

a system providing services for a customer; and a database storing information about the customer and comprising interaction information providing information about relationships of the customer to the system and identifying information, linked to the interaction information, and providing information about an identity of the customer.

2. An apparatus as recited in claim 1, wherein the interaction information is separate from the identifying information.

3. An apparatus, as recited in claim 1, wherein the identifying information comprises an entity object and the interaction information comprises an entity roles object.

4. An apparatus as recited in claim 3, wherein said interaction information comprises a customer object.

5. An apparatus as recited in claim 3, wherein the entity object has a link to one of an individual identifier and an organization identifier.

6. An apparatus as recited in claim 1, wherein said system determines whether identifying information for the customer exists in said database before new identifying information of the customer is stored.

7. An apparatus as recited in claim 1, wherein the system searches said database for the customer identifying information responsive to customer search information and, when the customer identifying information is not found in said database, uses the search information in creating new customer identifying information for the customer.

8. A telecommunications customer care and billing apparatus, comprising:

a system providing telecommunication services for a telecommunications system customer; and a database system storing information about the customer and comprising:

identifying information in an entity object providing information about an identity of the customer;

interaction information in a customer object, separate from and linked to said entity object, and providing customer information;
and interaction information in an entity roles object, separate from and linked to said entity object and said customer object, and providing information about relationships of the customer to the system.

9. A process, comprising:

providing service to a customer and including:

accessing interaction information providing information about relationships of the customer to the system; and accessing identifying information, stored separately from and linked to the interaction information, and providing information about an identity of the customer.

10. A process as recited in claim 9, wherein the interaction information is accessed through the identifying information.

11. A process as recited in claim 9, wherein the identifying information is accessed through the interaction information.

12. A process as recited in claim 9, further comprising determining whether similar identifying information for a customer exists in a database before identifying information of new customer is allowed to be stored.

13 A process as recited in claim 9, further comprising:
searching for the customer identifying information in a database responsive to user entered customer search information; and providing the user-entered customer search information to a create customer process when the customer identifying information is not found in the database.

14. A computer readable storage storing a data structure controlling access to data within said storage and comprising interaction information providing information about relationships of a customer system and identifying information, linked to and separate from the interaction information, and providing information about an identity of the customer.