Abstract:
A subscriber profile access management system for a telecommunications service provider or telecommunications operator provides technical solutions to providing a single point of access to telecommunications subscriber profile information. As the products and services offered by the service provider grow, and given the many different access mechanisms through which a subscriber connects to services, the single point of access eliminates the inefficient proliferation of custom interfaces between the many support systems and applications which need access to subscriber profile information. The single point of access provides a universal and personalized access to telecommunications services. Access may be made to the subscriber profile regardless of the particular type of access mechanism (e.g., WiFi, or DSL access), while the personalized access allows services to be customized based upon static and dynamically maintained information in the subscriber profile.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Priority Claim  
         [0002]     This application claims the benefit of EPO Application No. ______, filed ______ assigned attorney docket number 10022-673 and Italian Application No. ______, filed ______ assigned attorney docket number 10022-727, both of which are incorporated herein by reference in their entirety.  
         [0003]     2. Technical Field  
         [0004]     This invention relates to telecommunications service provider and telecommunication operator system architectures. In particular, this invention relates to maintaining and providing efficient access to both static and dynamic telecommunication subscriber profile information.  
         [0005]     3. Related Art  
         [0006]     Rapid advances in computer system and telecommunications technology have lead to a vast array of telecommunication services available to the consumer. Such telecommunications services include traditional telephone service, Internet service, cable television service, cellular phone service, messaging service, paging service, combined voice and data delivery service, and many other services. Furthermore, many services may be either wireless or wireline based.  
         [0007]     Telecommunications subscribers access their services through a wide range of connections. The hardware underlying the connections implements circuit switched connections, packet switched connections, and other types of connections. In addition, a wide range of communication protocols and access technologies further govern the transfer of data on the connections. Asymmetric Digital Subscriber Line (ADSL), Multi-protocol Label Switching (MPLS), Virtual Private Networks (VPNs), and other technologies are several examples of a wide array of access technologies for telecommunications services.  
         [0008]     Growing support of new and existing telecommunications services and the wide range of access mechanisms for those services have led to an extensive dispersal of subscriber profile information between many different telecommunication support systems which support the services and access mechanisms. The dispersal leads to the inefficient proliferation of custom interfaces between systems and applications which need to obtain profile information to authorize or authenticate access, determine which services are subscribed, determine how the subscriber connects to the services, and for many other reasons. Thus, in the past there was no sufficiently secure, flexible, and efficient mechanism which provided a single point of access to telecommunication subscriber profile information and which maintained the subscriber profile information.  
         [0009]     A need has long existed for an enhanced system architecture for a telecommunications service provider or telecommunications operator which efficiently provides access to and maintains subscriber profile information.  
       SUMMARY  
       [0010]     Creating an enhanced telecommunications service provider or telecommunication operator system architecture which provides and maintains subscriber profile information poses significant technical challenges. As one example, there is a technical challenge in defining and implementing an architecture which provides a single point of access to the subscriber profile information, and which eliminates inefficient dispersal of subscriber information among many different systems. Another technical challenge lies in providing a database data model architecture which efficiently flexibly supports real time and static presence information not only for subscribers, but also for the network services which subscribers use to connect to network resources and for the applications which subscribers use to, for example, communicate with other subscribers. Yet another technical challenge lies in providing a high performance data access layer which stores and updates subscriber profile information, and which responds to queries for subscriber profile information in a carrier grade environment where hundreds of thousands or millions of subscribers may generate an immense number (e.g., hundreds or thousands) of subscriber profile updates or queries per second.  
         [0011]     One aspect of the invention is a subscriber profile access management system for a telecommunications service provider or telecommunication operator. Another aspect of the invention is a presence system for use in the subscriber profile access management system. Still another aspect of the invention is a unified directory system for use in the subscriber profile access management system. The presence system includes a network data gatherer which may establish a single point of access for authorizing client access to network resources, and which updates subscriber presence information in the unified directory.  
         [0012]     The presence system also includes a message publisher in communication with the network data gatherer. The message publisher generates a published connection message from the subscriber connection message which the network data gatherer receives. A message queue manager queues the published connection message for delivery to a rules manager which subscribes to such messages. Thus, the rules manager receives the published connection message from the message queue manager.  
         [0013]     The rules manager applies routing rules to the published connection message. The routing rules determine how to process the published connection message. In one implementation, the routing rules determine whether to forward the published connection message to a technical key management queue or to a presence management queue. The technical key management queue handles authentication of subscriber connection requests (e.g., RADIUS authentication or DHCP discover requests). The messages in the technical key management queue include technical key information which is matched against technical keys stored in the unified directory. When the subscriber is authenticated, the associated subscriber information is inserted into the unified directory system, and then updated with IP address information during subsequent connection phases (e.g., during RADIUS accounting or DHCP request/acknowledgement phases). The messages in the presence management queue may give rise to a subscriber presence update message, request, or submission sent to the unified directory system. For example, the presence management queue may handle DHCP request/acknowledgement messages from which the presence system updates the subscriber IP address information in the unified directory system. The unified directory system thereby maintains dynamic information about subscribers connected to the network.  
         [0014]     The unified directory system includes a data access layer which defines a subscriber profile data store. The data access layer may be implemented as a persistent subscriber profile data store in a first type of memory (e.g., on a hard disk drive) and a cached representation of the persistent subscriber profile data store in a second memory (e.g., in Random Access Memory (RAM)) which is faster than the first memory. The cached representation of the persistent subscriber profile data store provides an extremely fast response time for querying subscriber profile information.  
         [0015]     The unified directory system implements a communication interface to the presence system. The communication interface receives subscriber insertion messages and subscriber presence update messages from the presence system in response to the published connection messages received at the presence system. A second interface in the unified directory system (e.g., a hypertext transport protocol (HTTP) interface) receives subscriber profile queries from external systems.  
         [0016]     Service logic in the unified directory system processes the subscriber insertion messages, subscriber presence update messages, and the subscriber profile queries. For example, the service logic may insert a subscriber identifier into the data access layer (e.g., in a network service presence table) in response to a subscriber insertion message. As another example, the service logic may query the data access layer in response to the subscriber profile query to obtain a query result. The subscriber profile query may be, as examples, a user status query, a network service data query, or an application service data query. The service logic may then return the query result to the external system.  
         [0017]     The message publisher may generate the published connection message according to a common message format for such messages, regardless of the type of subscriber connection message received (e.g. a dynamic host configuration protocol (DHCP) message or a remote authentication dial-in user service (RADIUS) message). The published connection message may include a username and a technical key. The technical key provides subscriber connection identifying information, such as a virtual path identifier (VPI), virtual circuit identifier (VCI), interface identifier, and other identifying information.  
         [0018]     Another aspect of the invention is a unified directory system incorporating a data model which stores subscriber profile information. The unified directory system establishes the data model in a data access layer. The data access layer implements a reliable persistent subscriber profile data store in a first memory and a high speed cached representation of the persistent subscriber profile data store in a second memory. The data access layer may include multiple parallel persistent nodes, multiple parallel real-time nodes, and a load balancer which distributes subscriber insertion messages, subscriber presence update messages, and the subscriber profile queries to the nodes.  
         [0019]     The data model which stores the subscriber profile information distributes the subscriber data across several layers. In one implementation, the data model includes a customer profile layer defining a customer entity which subscribes to products, a user profile layer defining users belonging to the customer entity, and a product profile layer which defines available products and services. The data model also includes a service profile layer which defines subscribed network and application services, and a presence layer which defines network service presence and application service presence for the subscribed services and applications.  
         [0020]     The data model flexibly distinguishes between network services and application services, and allows the unified directory to establish and maintain presence for both the network services and the application services. To that end, the presence layer may include a network service presence table and an application service presence table. The network service presence table dynamically updates the presence status of network services (e.g., updating whether a subscriber is connected to the network), and may exist in a one to many relationship with a network service instance table. The network service instance table instantiates network services subscribed by the users. Similarly, the application service presence table dynamically updates the presence status of application services (e.g., updating whether a subscriber has logged in), and may exist in a one to many relationship with an application service instance table. The application service instance table instantiates application services subscribed by the users.  
         [0021]     Other systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0022]     The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts or elements throughout the different views.  
         [0023]      FIG. 1  shows a portion of a telecommunications service provider architecture which includes a subscriber profile access management system.  
         [0024]      FIG. 2  shows a subscriber profile access management system which processes subscriber connection messages and subscriber profile queries.  
         [0025]      FIG. 3  illustrates a presence system which may be part of a subscriber profile access management system in a telecommunications service provider architecture.  
         [0026]      FIG. 4  shows a dynamic host configuration protocol (DHCP) subscriber connection message which the presence system may receive.  
         [0027]      FIG. 5  shows a DHCP subscriber connection response message which the presence system may send.  
         [0028]      FIG. 6  shows a remote authentication dial-in user service (RADIUS) subscriber connection message which the presence system may receive.  
         [0029]      FIG. 7  shows a RADIUS response message which the presence system may send.  
         [0030]      FIG. 8  illustrates a published connection message which the message publisher in the presence system may generate from the subscriber connection messages.  
         [0031]      FIG. 9  depicts a message publisher output message which the message queue manager in the presence system may send to the message publisher.  
         [0032]      FIG. 10  shows a unified directory system which may be part of a subscriber profile access management system in a telecommunications service provider architecture.  
         [0033]      FIG. 11  shows a data model which may implement a subscriber profile data store which the unified directory system maintains.  
         [0034]      FIG. 12  shows acts which the presence system may take to process subscriber connection messages.  
         [0035]      FIG. 13  shows acts which the unified directory system may take to process subscriber insertion or subscriber update messages.  
         [0036]      FIG. 14  shows acts which the unified directory system may take to process subscribe profile queries from the presence system and from external systems. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0037]     The elements illustrated in the Figures interoperate as explained in more detail below. Before setting forth the detailed explanation, however, it is noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting. For example, although aspects, features, or components of the implementations may be stored in memories, all or part of systems and methods consistent with the subscriber profile access management system, presence system, and unified directory may be stored on, distributed across, or read from other machine-readable media, for example, secondary storage devices such as hard disks, floppy disks, and CD-ROMs; a signal received from a network; or other forms of ROM or RAM either currently known or later developed.  
         [0038]     Furthermore, although specific components of the subscriber profile access management system, presence system, and unified directory architectures are described, methods, systems, and articles of manufacture consistent with the subscriber profile access management system, presence system, and unified directory architectures may include additional or different components. For example, processing logic, messaging systems, communication interfaces, message adaptors, and other components may be implemented with microprocessors, microcontrollers, application specific integrated circuits (ASICs), discrete logic, or a combination of other type of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash, disk, or any other type of memory. Flags, data, databases, tables, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways. Programs executed by the components may be parts of a single program, separate programs, or distributed across several memories and processors. Furthermore, the systems may be implemented in hardware, software, or a combination of hardware and software in one processing system or distributed across multiple processing systems.  
         [0039]      FIG. 1  shows a portion of a telecommunications architecture  100  which interacts with third parties  102 . The third parties  102  may vary widely in form and in implementation. As examples, the third parties  102  may include: subscriber devices  104  such as cellular phones, personal data assistants, network (e.g., Internet) communication devices; applications  106  such as telecommunications service applications implemented by other service providers, such as Short Message Service (SMS) messaging applications, Session Initiation Protocol (SIP) systems, and billing applications which charge customers for products and services; and other devices, programs, or entities  108 .  
         [0040]     The telecommunications architecture  100  implements functionalities which support telecommunications products and services and exposes selected functionalities to the third parties  102 . In addition, the telecommunications architecture  100  includes a subscriber profile access management system  122 . As will be explained in more detail below, the access management system  122  establishes and maintains subscriber profile information and provides a single point of access to the subscriber profile information.  
         [0041]     The products and services, and their exposed underlying functionalities, may vary between implementations. As examples, the telecommunications architecture  100  may implement SMS messaging services (to deliver and charge for an SMS message), Multimedia Messaging System (MMS) messaging services (to deliver and charge for an MMS message), and SIP services (to setup a SIP call and charge for the call). As additional examples, the telecommunications architecture  100  may implement Charge services (to request to bill a charge against an account), Internet Protocol Television (IPTV) services (to request delivery of television programming), User Status services (to request a current user status, such as ‘online’, ‘offline’, ‘busy’, or ‘away’), and user authentication services (e.g., to request verification of whether a mobile user exists and whether the mobile user has the credentials to purchase a desired service, such as IPTV service). Other functionalities may be provided in addition or as alternatives. Furthermore, the telecommunications architecture  100  and may also provide access to communication network services (e.g., Internet browsing services) through the third party access gateway  110 .  
         [0042]     The telecommunications architecture  100  secures access to the exposed services. To that end, the architecture  100  provides a third party access gateway  110 . The third party access gateway  110  acts as a single point of contact for the third parties  102  to the exposed services.  
         [0043]     As shown in  FIG. 1 , the third party access gateway  110  receives service requests  112  from the third parties  102 . In response, the third party access gateway  110  verifies that the service request originates with an authenticated and authorized third party. In the case of network communication service requests (as one example), the third party access gateway  110  processes authorized service requests and relays the service requests to service providers  114 . In the case of exposed service requests, such as SMS, MMS, and SIP service requests, the third party access gateway  100  may process and relay the authorized service requests to the service broker  116 .  
         [0044]     The service broker  116  executes the service request. In doing so, the service broker  116  may communicate with Business Support Systems (BSS) and Operation Support Systems (OSS)  118  which the architecture  100  implements to create, deploy, manage, and maintain telecommunications products and services. In executing the service request, the service broker  116  may additionally or alternatively communicate with a network layer  120  which may deliver or return service related data to the service broker  116 . Responses from service providers  114  and the service broker  116  are returned to the third-party access gateway  110  for delivery to the originating third party requester.  
         [0045]     The subscriber profile access management system  122  receives subscriber profile queries from external systems and also processes subscriber connection messages. The subscriber connection messages may originate from subscribers which attempt to connect to the network (e.g., as an initial step in establishing a communication session between the subscribers).  FIG. 1  shows two such subscribers  124  and  126  which establish a SIP based communication session  136 . The subscribers  124  and  126  may be cellular phones, personal data assistants, network (e.g., Internet) communication devices; personal computers; programs such as video phone or internet protocol television programs; or other entities.  
         [0046]     Any of the subscribers may connect to the subscriber profile access management system  122  through network intermediaries. The network intermediaries may include one or more network access server (NAS) systems  128 , dynamic host protocol (DHCP) servers  130  or proxies, and/or remote authentication dial-in user service (RADIUS) servers  132  or proxies. One or more networks  134  may connect the subscribers and network intermediaries to the subscriber profile access management system  122 .  
         [0047]      FIG. 2  shows the subscriber profile access management system  122 . The subscriber profile access management system  122  includes a presence system  202  which provides a single point of access for subscriber authentication and subscriber network presence detection services. RADIUS or DHCP servers or proxies  206  may communicate subscriber connection messages to the presence system  202 . As will be explained in more detail below, in response, the presence system  202  may initiate subscriber authentication with the unified directory system  204 , update subscriber information in the unified directory system  204 , or take other actions.  
         [0048]     A unified directory system  204  in the access management system  122  provides a single point of access to subscriber profile information. The unified directory system  204  may respond to subscriber insertion or update messages from the presence system  202 , or to subscriber information queries from external systems  208 , such as the service broker  116 , third party gateway  110 , or other systems outside the unified directory system. The external system  208  may query the unified directory system  204  to obtain the requested information about subscriber availability, connection characteristics, device characteristics, or other subscriber profile information. The unified directory system  204  returns query results to the external systems  208 .  
         [0049]     The subscriber profile access management system  122  implements a communication interface (the “presence interface”  210 ) between the presence system  202  and the unified directory system  204 . In addition, the unified directory system  204  implements a communication interface (the “external interface”  212 ) between the unified directory system  204  and the external systems  208 . The presence interface  210  and/or the external interface  212  may be implemented as a hypertext transfer protocol (HTTP) interface, Java™ database connectivity (JDBC) interface, or other type of communication interface, including an interface for exchanging messages between the systems.  
         [0050]      FIG. 3  illustrates the presence system  202  in detail. The presence system  202  includes a network data gatherer  302 , message publisher  304 , and message queue manager  306 . The presence system  202  also includes a presence manager  308 .  
         [0051]     As shown in  FIG. 3 , the presence system  202  sends and receives messages to the external network. For example, the presence system  202  may receive subscriber connection messages such as RADIUS messages  312  and the DHCP messages  314 . The presence system  202  may respond to RADIUS or DHCP servers or proxies with the RADIUS output messages  316  and the DHCP output messages  318 .  
         [0052]     In some implementations, however, the presence system  202  may itself implement a RADIUS server or DHCP server. To that end, the presence system  202  may include a DHCP server  320 , a RADIUS server  322 , or both. Thus, the presence system  202  may receive messages directly from subscribers which are attempting to connect to network resources, instead of receiving DHCP or RADIUS messages  312  and  314  from external systems.  
         [0053]     The network data gatherer  302  may include a communication interface and packet listener which monitors network traffic for incoming RADIUS and/or DHCP messages  312  and  314 . A separate interface or multiple interfaces may be provided for RADIUS message and DHCP messages. The network data gatherer  302  may be assigned a specific network address, such as an internet protocol (IP) address and port number, or may be addressed in other ways. The RADIUS and DHCP messages  312  and  314  may relate to subscriber network access and may be sent when a subscriber needs to connect to network resources, for example. As another example, the messages may relate to subscriber service use accounting, including accounting start and stop messages.  
         [0054]     As one example, a Lucent Technologies™ NavisRadius™ server, available from Lucent Technologies of Murray Hill, N.J. may implement the network data gatherer  302 , including the RADIUS server  322 . Alternatively or additionally, a Cisco Systems™ DHCP server, available from Cisco Systems, Inc. of San Jose, Calif., may implement the network data gatherer  302 , including the DHCP server  320 .  
         [0055]     The network data gatherer  302  passes the received messages to the message publisher  304 . Multiple network data gathers  302  and/or message publishers  304  may be provided, and a load balancer may distribute the messages between the message publishers  304  using a round robin technique or any other load balancing technique. The message publisher  304  may translate RADIUS and DHCP messages to a common message format for published connection messages. The common format may be employed regardless of whether the received messages are of a first message type (e.g., a RADIUS message) or a second, different, message type (e.g., a DHCP message).  
         [0056]     Adapter logic in the message publisher  304  translates the received messages to the common message format. The adapter logic transforms the messages and/or message content from one format (e.g., a format to which RADIUS messages adhere) to another format (e.g., the common format to which the published connection messages adhere). In one implementation, the message publisher  304  parses each received message into an extensible Markup Language (XML) published connection message. Examples of the message formats are given below.  
         [0057]     The message queue manager  306  may establish and control one or more messages queues.  FIG. 3  shows two message queues  324  and  326 . Each message queue may store a particular type of published connection message  325  received from the message publisher  304 . For example, the message queue  324  may queue RADIUS messages, while the message queue  326  may queue DHCP messages. The messages may be inserted into the queues depending on subscriber identifiers, connection message request type, or according to any other criteria, however.  
         [0058]     The message publisher  304  and/or message queue manager  306  may implement a publish/subscribe messaging interface. For example, a Sonic MQ™ message system, available from Sonic Software of Bedford Mass., may implement the message queue manager  306 . Other messaging techniques may be employed, however, including point-to-point message transmission.  
         [0059]     The presence manager  308  may include a message publisher/subscriber  328  and a rules manger  330 . The rules manager  330  determines message destinations or other processing actions to take based on the routing rules  332 . The message destinations may include different message queues, such as the presence management queue  334  and the technical key management queue  336 . Processing logic may be provided to retrieve and process the queued messages.  FIG. 3  shows presence queue logic  338  which processes messages in the presence management queue  334 , and technical key queue logic  340  which processes messages in the technical key management queue  336 . Service logic  310 , which may be part of the queue logic  338  and  340 , provides an interface to the unified directory system  204 . Although shown separately in  FIG. 3 , the queue logic  338  and  340  and service logic  310  are not necessarily distinct programs or circuitry. For example, the queue logic  338  and  340  for processing both queues  334  and  336  and/or the service logic  310  for communicating with the unified directory system  204  may be implemented in a single program or set of circuitry.  
         [0060]     The message publisher/subscriber  328  receives published subscriber connection messages from the message queue manager  306 . The rules manager  330  processes the received messages and determines their destination according to the routing rules  332 . As will be explained in more detail below, the routing rules  332  may specify which of the queues  334  and  336  should queue the received published subscriber connection message. The presence queue logic  338  and technical key queue logic  340  may then retrieve the queued messages and interact with the unified directory system  204  through the service logic  310  as noted below. The presence manager  308  and/or service logic  310  may be implemented with a Sonic ESB™ service bus and message processing system. More generally, any of the elements shown in  FIG. 3  may be implemented in hardware, software, or a combination of hardware and software.  
         [0061]      FIG. 4  shows an example of a DHCP connection message  312 . The connection message  312  includes a code field  402 , a length field  404 , and a client hardware address field  406 . In addition, the connection message  312  includes a server ID field  408 , a yiaddr field  410 , an xid field  412 , and an option field  414 . A description for each field is given below in Table 1.  
                                 TABLE 1                           DHCP message                Size               Field   (Bytes)   Description   Values               Code   1   Command Code -   1: DHCPDISCOVER               DHCPACK and   2: DHCPACK               DHCKNAK messages   3: DHCPNAK               may be received as the               consequence of a DHCP               server receiving and               processing a               DHCPREQUEST               message from a subscriber.       Length   1   Data Length       Chaddr   6   Subscriber hardware               address       Server   4   DHCP server IP address       ID       yiaddr   4   IP address offered to               subscriber through the               DHCP process       xid   4   DHCP transaction ID       Option   Variable   Optional message data                    
         [0062]     The option field  414  may include additional subscriber connection information, such as a unique identifier. The unique identifier allows other systems, such as Internet service providers to take specific actions based on the identifier. As examples, the systems may use the identifier to identify a subscriber, to assign specific actions to that subscriber (for example, assignment of host IP address, subnet mask, and domain name server (DNS)), to trigger accounting, or take other actions. The option field  414  may adhere to the DHCP Option82 format.  
         [0063]      FIG. 4  shows that the option field  414  may include length fields  416 ,  420 , and  426  for the information portions of the option field  414 . The information portions may include a first sub-option field  418 , a first information field  422 , a second sub-option field  424 , and a second information field  428 . Table 2 below provides a description for each field.  
                         TABLE 2                           Option field            Field   Description               Length1   Data Length of the option field 414       Suboption1   Optional identifier of a first sub option provided in           the option field       Length2   Data length of the first sub option       Info1   Message data for the first sub option - e.g., a circuit           identifier       Suboption2   Optional identifier of a second sub option provided in           the option field       Length3   Data length of the second sub option       Info2   Message data for the second sub option - e.g., MAC           address for a cable interface, technical key, or other data                    
         [0064]     The second sub-option field  428  may provide further information about the subscriber connection. The second sub-option field  428  may include a port type  430 , a version identifier  432 , reserved bytes  434 , and a technical key  436 . The second sub-option field  428  may support service providers which use ATM routed bridged encapsulation (RBE) to configure digital subscriber line (DSL) access. The second sub-option field  428  may thereby allow service providers to use DHCP to assign IP addresses and implement security and IP assignment policies. Table 3 below provides a description for each field.  
                         TABLE 3                           Sub-option 2            Field   Description               Port type   An identifier of a port type (e.g., Routed Bridge           Encapsulation)       Version   Version identifier for the format of option field 414.       Reserved   Reserved bytes for future use       Technical   A collection of subscriber connection characteristics, such       Key   as a network authentication service IP           address and/or port.                  
 
         [0065]      FIG. 4  shows the technical key  436  in more detail. The technical key includes a port IP address  438 , a Digital Subscriber Line Access Multiplexer (DSLAM) Medium Access Control (MAC) address  440 , and a slot identifier  442 . The technical key may also include a port identifier  444 , a Virtual Path Identifier (VPI)  446 , and a Virtual Circuit Identifier (VCI)  448 . Table 4, below, provides a description for each field:  
                         TABLE 4                           Technical Key            Field   Description               Port IP address   IP address of an interface on a DHCP relay agent.       DSLAM MAC   The MAC address of the DSLAM through which       address   the subscriber connects.       Slot   Slot identifier of the virtual circuit on which the           DHCP request has arrived.       Port   Port identifier of the virtual circuit on which the           DHCP request has arrived.       VPI   Virtual Path Identifier of the virtual circuit on which the           DHCP request has arrived.       VCI   Virtual Circuit Identifier of the virtual circuit on which           the DHCP request has arrived.                    
         [0066]      FIG. 5  shows a DHCP subscriber connection output message  318  which the presence system  202  may send in response to receiving and processing a DHCP subscriber connection message. The output message  318  may include a code field  502 , a length field  504 , and a description field  506 . Table 5, below, provides a description of each field.  
                                 TABLE 5                           DHCP subscriber connection output message                Size               Field   (Bytes)   Description   Values               Code   1   Command Code   1: SUCCESS                   2: ERROR       Length   1   Data Length       Description   Variable   A text description of the result               condition                    
         [0067]      FIG. 6  shows a RADIUS subscriber connection message  312  which the presence system  202  may receive. The RADIUS subscriber connection message  312  may include a type field  602 , an identifier field  604 , and a length field  606 . The message  312  may further include an authenticator field  608 , a framed IP address field  610 , and a user name field  612 . Additional fields include the NAS IP address field  614 , NAS ID field  616 , account session ID field  618 , and account status type field  620 . Table 6, below, provides a description for each field.  
                                                   TABLE 6                           RADIUS subscriber connection message                Size               Field   (Bytes)   Description   Values                    Type   1   Command Code which indicates   1: Access-               the type of RADIUS message   Request       Ident   1   Request Identifier which matches   2: Accounting-               a request with a corresponding   Request               response       Length   1   Data Length of the RADIUS               message.       Auth   16   Authenticator Field which               contains information which the               RADIUS client and server use to               authenticate each other       Framed IP   4   IP address offered to the               subscriber       Username   &gt;=3   Subscriber username       NAS IP   4   NAS IP address       NAS ID   &gt;=3   NAS identifier (e.g., a domain               name for the NAS)       Account   &gt;=3   Node Line Card (Slot/Port) and       session       Circuit IDs (VPI/VCI)       Account   6   Accounting Request Type   Start, Stop,       status type           Interim-Update                    
         [0068]      FIG. 7  shows a RADIUS response message  316  which the presence system  202  may send. The RADIUS response message  316  may include a type field  702 , an identifier field  704 , and a length field  706 . The response message  316  may also include an authenticator field  708  and an attribute field  710 . Table 7, below, provides a description for each field.  
                                                   TABLE 7                           RADIUS response message                Size               Field   (Bytes)   Description   Values                    Type   1   Command Code   2: Access-Accept                   3: Access-Reject                   4: Accounting-                   Response       Identifier   1   Request Identifier       Length   1   Data Length       Authenticator   16   Authenticator Field       Attribute   &gt;=7   Accounting response   OK, NOK               result description.               May include multiple               sub-fields: a vendor               specific attribute identifier,               length, and data field.                    
         [0069]     An example of a RADIUS access-request message is given below in Table 8. The access-request message may be sent from a RADIUS server in response to a subscriber attempt to connect to the network.  
                                           TABLE 8                           RADIUS access-request message                Field   Value                            Type   1           Ident   11           Length   167           Auth           Framed IP           Username   “test123@123.testtest1.com”           NAS IP   99.222.66.111           NAS ID   “rm100.aaa.testtest1.com”           Account   “3/0/0/1.1_00000483”           session           Account           status type                      
 
         [0070]     An example of a RADIUS accounting-request message is given below in Table 9. the accounting-request message may be sent to start or stop accounting of subscriber usage of network resources.  
                                           TABLE 9                           RADIUS accounting-request message                Field   Value                            Type   4           Ident   12           Length   198           Auth           Framed IP           Username   “magictested@123.testtest1.com”           NAS IP   99.222.66.111           NAS ID   “rm100.aaa.testtest1.com”           Account   “3/0/0/1.1_00000483”           session           Account   Start           status type                      
 
         [0071]     Table 10 gives an example of a corresponding RADIUS access-accept output message.  
                                           TABLE 10                           RADIUS access-accept output message                Field   Value                            Type   2           Identifier   11           Length   3           Authenticator           Attribute   OK                      
 
         [0072]     Table 11 gives an example of a corresponding RADIUS accounting-response output message.  
                                           TABLE 11                           RADIUS accounting-response output message                Field   Value                            Type   5           Identifier   12           Length   198           Authenticator           Attribute   26 (attribute identifier), 2 (attribute length), OK               (attribute data)                      
 
         [0073]      FIG. 8  illustrates a published connection message  325  which the message publisher  304  in the presence system  202  may generate from the subscriber connection messages. The published connection messages  325  may be XML messages, or other types of messages. The published connection message  325  may adhere to a common message format which includes a message type field  802 , a username field  804 , and a server IP field  806 . The published connection message  325  also includes a client IP field  808 , an access server IP field  810 , and an access server identifier field  812 . The common message format also includes a slot field  814 , port field  816 , interface field  818 , VPI field  820 , and VCI field  822  are also present. Table 12 provides a description of each field.  
                                 TABLE 12                           Published connection message            Field   Type   Description   Values               msgType   Integer   Command Code   1: DHCPDISCOVER                   2: DHCPACK                   3: DHCPNAK                   4: ACCESSREQUEST                   5: ACCTSTART                   6: ACCTSTOP       Username   String   Username or client MAC               address       Server IP   String   RADIUS or DHCP               server IP address       Client IP   String   IP address offered to the               subscriber       Access   String   NAS or DSLAM IP       Server IP       address       Access   String   NAS identifier or       server ID       DSLAM MAC address       Slot   Integer   Slot identifier       Port   Integer   Port identifier       Interface   Integer   Interface identifier       VPI   Integer   VPI identifier       VCI   Integer   VCI identifier                    
         [0074]      FIG. 9  illustrates a message publisher output message  900  which the message publisher  304  in the presence system  202  may send in response to receipt of a published connection message  325 . The output message  900  may include a code field  902  and a description field  904 . Table 13 provides a description of each field.  
                                 TABLE 13                           Message publisher output message            Field   Type   Description   Values               Code   Integer   Command Code   1: SUCCESS                   2: ERROR       description   String   A text description of the result               condition                    
         [0075]     Table 14a provides an example of an XML published connection message. The example in Table 14a is consistent with the common format shown in Table 12 for an access request from a subscriber. The published connection message identifies the technical key using the &lt;tk&gt; tag.  
                         TABLE 14a                       XML published connection message                                    &lt;?xml version=”1.0” ?&gt;           &lt;msg&gt;           &lt;msgType&gt;4&lt;/msgType&gt;           &lt;username&gt;44-45-53-54-42-00&lt;/username&gt;           &lt;serverIP&gt;10.107.109.182&lt;/serverIP&gt;           &lt;clientIP&gt;121.56.134.45&lt;/clientIP&gt;           &lt;tk&gt;             &lt;accessServerIP&gt;10.107.108.204&lt;/accessServerIP&gt;             &lt;accessServerID&gt;92.168.132.8&lt;/accessServerID&gt;             &lt;slot&gt;3&lt;/slot&gt;             &lt;port&gt;0&lt;/port&gt;             &lt;interface&gt;1&lt;/interface&gt;             &lt;vpi&gt;245&lt;/vpi&gt;             &lt;vci&gt;34&lt;/vci&gt;           &lt;/tk&gt;           &lt;/msg&gt;                      
 
         [0076]     Table 14b provides an example of an XML message publisher output message  900  for the access request. In this example, the output message conveys an error in the attempt to authorize the subscriber for network access because the subscriber&#39;s username is not recognized.  
                         TABLE 14b                       XML message publisher output message                                    &lt;?xml version=”1.0” ?&gt;           &lt;msg&gt;             &lt;code&gt;2&lt;/code&gt;             &lt;description&gt;username not present&lt;/description&gt;           &lt;/msg&gt;                      
 
         [0077]     As an example of the processing performed by the presence system  202 , the presence system  202  may receive a RADIUS subscriber connection message  312  which specifies that a subscriber is requesting access to network services. The message type is type 1: Access-Request. The presence system  202  will authorize the subscriber, and may act as the single point of contact for RADIUS, DHCP, and other systems to provide subscriber authorization. To that end, the network data gatherer  302  first receives the access-request message and passes it to the message publisher  304 .  
         [0078]     The message publisher  304  translates the message to create a new message which adheres to a common format for published connection messages. The message publisher  304  generates an XML common format connection message with the field shown above in Tables 12 and 14. The data for the common format connection message may be extracted from or derived from the fields in the access-request subscriber connection message.  
         [0079]     Once the common format connection message is formed, the message publisher  304  publishes the message. As a result, the message queue manager  306  receives the published message and inserts the published message into the appropriate queue  324 ,  326 . For example, the message queue manager  306  may insert the published connection message into a queue assigned to handle access request messages.  
         [0080]     The message queue manager  306  retrieves the published connection message and sends it to a message subscriber, such as the presence manager  308 . The message publisher/subscriber  328  in the presence manager  308  receives the published connection message. The rules manager  330  applies the routing rules  332  to the data in the published connection message to determine a destination for the published connection message.  
         [0081]     As one example, the routing rules  332  may be implemented as shown in Table 15:  
                     TABLE 15                       Routing rules                                If msgType == 1 or msgType == 4)         then  insert  published  connection  message  into  the  technical  key       management queue;       else  /* msgType is 2, 3, 5, or 6 */          insert  published  connection  message  into  the  presence       management queue.       If an error occurs,          then send a NOK message to the rules manager.                  
 
         [0082]     Thus, the technical key management queue  336  handles messages for subscriber access requests and DHCPDISCOVER requests (i.e., requests which a subscriber sends to locate a DHCP server). In this instance, the technical key management queue  336  receives the published connection message. The technical key management queue  336  holds messages for which subscriber authentication is desired. The authentication may be based on the technical key in the published connection message, as will be explained in more detail below.  
         [0083]     The TK queue logic  340  periodically services the technical key management queue  336 . Thus, the TK queue logic  340  retrieves the queued message. The TK queue logic  340  processes the queued message according to a set of rules implemented in hardware or software in the TK queue logic  340 . Table 16 provides one example of the TK queue logic processing rules. In Table 16, ‘tk’ refers to the technical key fields provided in the published subscriber connection message between the &lt;tk&gt; and &lt;/tk&gt; tags.  
                     TABLE 16                       TK queue logic processing rules                                Select * from SDP_CUST_NET_SVC_T where CUSTID =       (select CUSTID from       SDP_USR_T where USRID=‘username’)       If TK Parameters retrieved from SDP_CUST_NET_SVC_T == tk then        If ‘username’ and CUSTNETSVCID not in SDP_NET_PRES_T then         insert ‘username’ and CUSTNETSVCID into SDP_NET_PRES_T;            send OK message to the rules manager;       else            Send NOK message to the rules manager;       If any error occurs, send NOK message to the rules manager.                  
 
         [0084]     In general, the TK queue logic processing rules match the technical key information against technical keys stored in the unified directory. When the subscriber is authenticated, the associated subscriber information (e.g., a username) is inserted into the unified directory system. Subsequently, additional subscriber information, such as IP address, may be updated in the unified directory system during subsequent connection phases (e.g., during RADIUS accounting or DHCP request/acknowledgement phases). Thus, the TK queue logic  340  may issue one or more queries to the unified directory system  204  in processing the rules shown in Table 16. A query may obtain each customer ID matching the username specified in the published connection message from the user table (Table 19). The same query or a second query to the unified directory system  204  selects all the fields from the network service instance table (Table 27) for the matching customer (including the ACCESSSERVERID, ACCESSSERVERIP, SLOT, PORT, INTERFACE, VCI, AND VPI fields which form the technical key). The network service instance table defines active network services for each customer. Thus, the subscriber/customer is an authenticated user of a network service if the subscriber has a matching record in the user table, the network service instance table establishes a network service for the user, and the technical key provided in the published connection message matches the technical connection information which the unified directory system  204  has recorded for the subscriber in the network service instance table.  
         [0085]     If the subscriber is authenticated, then the presence system  202  tracks the subscriber connection. To that end, the presence system  202  sends an insertion message to the unified directory system  204  to cause insertion of the ‘username’ into the USRID field into the network presence table (Table 31) and insertion of the CUSTNETSVCID retrieved from the network service instance table into the network presence table. The CUSTNETSVCID field provides a unique identifier of an association between a customer and a network service.  
         [0086]     Thus, the presence system  202  helps to maintain current presence information about subscriber access and presence with regard to network resources. In addition, when the subscriber is authenticated, the presence manger  308  returns a success or OK message back through the message queue manager  306 , the message publisher  304 , network data gatherer  302 , and to the RADIUS server from which the subscriber connection message originated. The RADIUS server may thereby confirm with the subscriber that access is granted.  
         [0087]     As another example of the processing performed by the presence system  202 , the presence system  202  may receive a RADIUS accounting-request start message  312  which specifies that accounting should start for the subscriber. The accounting-request message specifies a message type of ‘2’, and an account status type of ‘Start’. The network data gatherer  302  passes the RADIUS connection message  312  to the message publisher  304 .  
         [0088]     The message publisher  304  translates the message to create a new XML message which adheres to the common format for published connection messages. Once the message publisher  304  has generated and published the message, the message queue manager  306  receives the published connection message and inserts the message into the appropriate queue  324 ,  326 . For example, the message queue manager  306  may insert the published connection message into a queue assigned to handle presence updates, RADIUS messages, accounting start messages, or another queue.  
         [0089]     The message queue manager  306  retrieves the published connection message and sends it to the presence manager  308 . The message publisher/subscriber  328  in the presence manager  308  receives the published connection message. The rules manager  330  applies the routing rules  332  to the data in the published connection message to determine a destination for the published connection message. As shown in Table 15, the routing rules may result in the insertion of the published connection message (which has a msgType of 5) into the presence management queue  334 .  
         [0090]     The presence management queue  334  handles messages which indicate subscriber activity on the network, and based on which the presence system  202  may provide a presence update to the unified directory  204 . The presence update keeps the unified directory system  204  informed about ongoing subscriber connectivity to network resources, and provides real-time tracking of subscriber connection information.  
         [0091]     The presence queue logic  338  periodically services the presence management queue  334 . The presence queue logic  338  retrieves the queued message and processes the queued message according to a set of rules implemented in hardware or software in the presence queue logic  338 . Table 17 provides one example of the presence queue logic processing rules.  
                     TABLE 17                       Presence queue logic processing rules                                Select * from SDP_CUST_NET_SVC_T where       CUSTID = (select CUSTID from       SDP_USR_T where USRID=‘username’)       If ‘username’ and CUSTNETSVCID not in SDP_NET_PRES_T then        insert ‘username’, CUSTNETSVCID, and ‘clientIP’ into        SDP_NET_PRES_T;         send OK message to the rules manager;       else         update ‘clientIP’ in SDP_NET_PRES_T;         send OK message to the rules manager.       If any error occurs, send NOK message to the rules manager.                  
 
         [0092]     The rules shown in Table 17 may be implemented in or more queries to the unified directory system  204 . A first query obtains each customer ID matching the username specified in the published connection message from the user table (Table 19). The same query or a second query to the unified directory system  204  selects all the fields from the network service instance table (Table 27) for the matching customer. Thus, the presence system  202  will manage subscriber presence for those subscribers/customers who have a matching record in the user table and the network service instance table.  
         [0093]     Specifically, the rules shown in Table 17 check whether the ‘username’ and CUSTNETSVCID are not yet present in the network service presence table. If they are not present, then the presence system  202  may send a subscriber insertion message to the unified directory system  204 . The subscriber insertion message causes the unified directory system  204  to insert the ‘username’ into the CUSTID field, insert the CUSTNETSVCID, and insert the ‘clientIP’ into the IP field in the network service presence table. However, if the subscriber is already present in the network presence table, then the presence system  202  may send a subscriber update message to the unified directory system  204  to cause an update to the ‘clientIP’ field in the network service presence table. The presence system  202  thereby tracks current connection information for the subscriber.  
         [0094]      FIG. 10  shows a unified directory system  204  which may be part of the subscriber profile access management system  122 . The unified directory system  204  receives subscriber insertion messages  1002  and subscriber update message  1004  from the presence system  202 . The subscriber insertion messages  1002  may request the unified directory to insert subscriber profile information into the subscriber profile data store as noted above with regard to Tables 16 and 17. Similarly, the subscriber update messages  1004  may request the unified directory to update subscriber profile information (e.g., the client IP address) in the unified directory.  
         [0095]     The external interface  212  connects the unified directory system  204  with other data processing systems or applications  1006 . The external applications  1006  may send subscriber profile queries to the unified directory system  204 . The unified directory system  204  may provide a single point of access to the subscriber profile information for any number of external applications  1006 . The subscriber profile data may thereby be centralized in the unified directory system  204 , eliminating the dispersal of subscriber profile information among multiple product and service support systems.  
         [0096]     The unified directory system  204  includes a data access layer  1010 . In a high performance environment, the unified directory system  204  may also include a load balancer  1012  which distributes messages to the data access layer  1010 . The load balancer  1012  may distribute the messages in a round robin manner or in other ways.  
         [0097]     The data access layer  1010  includes one or more real time nodes ( FIG. 10  shows an example with three real time nodes labeled  1014 ,  1016 , and  1018 ) and one or more persistent nodes ( FIG. 10  shows an example with two real time nodes labeled  1020  and  1022 ). Each real time node may include real time database service logic  1024  and a high performance database  1026 . Each persistent node  1020  may include a persistent database  1030 . The database service logic  1024  may include a database management system which executes database queries on the high performance databases  1026 . The service logic  1024  may also implement a communication interface (e.g., a Sonic ESB™ HTTP interface) for sending and receiving messages to the presence system  202  and the external systems and applications  1006 . Thus, the service logic  1024  receives and processes the HTTP messages received through the load balancer. The HTTP messages are then processed in the individual real time nodes  1014 - 1018 , with each node  1014 - 1018  handling part of the message servicing load.  
         [0098]     Each persistent node  1020 - 1022  may include a database management system which executes database insertion and update operations. The persistent nodes  1020 - 1022  may receive database insertion and update messages from external systems, such as a Business Support System (BSS) or Operational Support System (OSS)  1032  in the telecommunications architecture. To that end, the unified directory system  204  may provide a BSS/OSS message interface  1034 , which implements an HTTP, Service Provisioning Markup Language (SPML), or other interface and which may support the exchange of user, resource and service provisioning information between cooperating systems, including the BSS/OSS systems  1032 .  
         [0099]     The databases  1026  and  1030  store copies of a subscriber profile data store. The persistent databases  1030  may be implemented on disk with a database management system such as the Oracle 9i™ system available from Oracle Corporation of Redwood Shores, Calif. The high performance databases  1026  may be implemented in a memory system which is faster than the memory system which supports the persistent databases  1030 . For example, the high performance databases  1026  may be implemented in Random Access Memory (RAM) as cached copies of the persistent subscriber profile data stores. A TimesTen™ database system, also available from Oracle Corporation, may implement the real time nodes  1014 - 1018 .  
         [0100]     In other implementations, the real time nodes  1014 - 1016  cache a portion of the subscriber profile data store. For example, the real time nodes  1014 - 1016  may cache only the network service presence table (Table 31) and/or the application service presence table (Table 32). These tables store volatile or relatively frequently changing data (e.g., the subscriber CPE IP address). There is a reduced need to keep the persistent nodes  1022 - 1024  consistent with such data. Furthermore, the high speed implementation of the real time nodes  1014 - 1018  allows the unified directory system  204  to response extremely quickly to queries for current subscriber profile information.  
         [0101]     The real time nodes  1014 - 1016  provide extremely fast response time to subscriber profile queries, while the persistent nodes  1022  and  1024  may handle subscriber profile insertion and update messages  1002  and  1004  (e.g., JDBC transactions). The load balancer  1012  distributes the incoming messages to the nodes  1014 - 1022 , each of which may handle a portion of the load, provide a fault tolerant architecture, and handle hundreds or thousands of incoming messages per second. As an example, each real time node may handle 500 queries or more per second, while the persistent nodes may handle 200 JDBC transactions per second. The nodes  1014 - 1022  may be implemented on a SUN480 available from Sun Microsystems of Santa Clara, Calif. or similar servers available from other vendors. The response capability of the data access layer  1010  may be expanded by both adding processors to the nodes  1014 - 1022  and by adding additional nodes  1014 - 1022 .  
         [0102]      FIG. 11  shows a data model  1100  which may implement the subscriber profile data store which the nodes  1014 - 1022  store and maintain. The data model  1100  is divided into a customer profile layer  1102 , a user profile layer  1104 , and a product profile layer  1106 . In addition, the data model  1100  also defines a service profile layer  1108  and a presence layer  1110 . The division of the data model  1100  into layers efficiently segments subscribe profile data into dynamically changing information in the presence layer  1110 , and more static information in the service profile layer  1108 . The table structure defined in the data model  1100  also provides a technical solution to separating network services from application services. Thus, presence information for each may be independently established and maintained for any subscriber.  
         [0103]     The customer profile layer  1102  defines a customer table  1112 . The customer table  1112  may establish the data fields which characterize a physical person or legal entity which subscribes to telecommunication service products. The user profile layer  1104  defines a user table  1114 . The user table  1114  may establish data fields which characterize a physical person who subscribes to one or more products and/or services (e.g., an instant messaging application) and the services available on the products (e.g., instant messaging service).  
         [0104]     The product profile layer  1106  defines a product instance table  1116  and product catalog tables  1118 . The product instance table  1116  establishes the data fields which instantiate telecommunication service provider offerings, such as a particular service or product. The product catalog tables  1118  establishes the data fields which instantiate a whole catalog of products and special offers available from the telecommunication service provider.  
         [0105]     The service profile layer  1108  defines a network service catalog table  1120 , a network service instance table  1122 , a network service parameters table  1124 , and a network service data table  1126 . The network service catalog table  1120  instantiates a catalog of network services offered by a telecommunications service provider. The network service instance table  1122  instantiates a particular network service offered on a product which a subscriber has access to. The network service parameters table  1124  instantiates parameters applicable to network services in the catalog of network services. The network service data table  1126  instantiates the data which characterizes a particular network service instance.  
         [0106]     The service profile layer  1108  also defines an application service catalog table  1128 , an application service instance table  1130 , an application service parameter table  1132 , and an application service data table  1134 . The application service catalog table  1128  instantiates a catalog of application services offered by a telecommunications service provider. The application service instance table  1130  represents a particular application service offered on a product which a subscriber has access to. The application service parameters table  1132  instantiates parameters applicable to application services in the catalog of network services. The application service data table  1134  instantiates the data which characterizes a particular application service instance.  
         [0107]     The presence layer  1110  defines a network service presence table  1136  and an application service presence table  1138 . The network service presence table  1136  establishes the data fields which characterize network resource access connectivity, keeping track of recent subscriber connection information with respect to the network services (e.g., an established connection to a DSL network service). The application service presence table  1138  establishes the data fields which characterize subscriber access to application services, including whether the subscriber is logged in to or out of any of the subscribed application services (e.g., whether the subscriber is logged into an instant messaging application service).  
         [0108]     Table 18 below provides an example implementation of the customer table  1112 .  
                                       TABLE 18                           Customer Table            SDP_CUST_T   CUSTOMER            FIELD   TYPE   DESCRIPTION               CUSTID   NUMBER(20)   Customer Identifier, may be a               primary key.       ENTNAME   VARCHAR2(50)   Name Of The Enterprise       FIRSTNAME   VARCHAR2(50)   First Name       MIDDLENAME   VARCHAR2(50)   Middle Name       SURNAME   VARCHAR2(50)   Second Name       ENTFISCALCODE   VARCHAR2(50)   Enterprise Fiscal Code       FISCALCODE   VARCHAR2(50)   Fiscal Code       LEGALSTATUS   VARCHAR2(50)   Legal Status       DATEOFBIRTH   DATE   Date Of Birth       PLACEOFBIRTH   VARCHAR2(50)   Place Of Birth       CIVILSTATUS   VARCHAR2(20)   Civil Status       GENDER   CHAR(1)   Gender, e.g., ‘M’ or ‘F’       TEL   VARCHAR2(50)   Telephone Contact       CONTACTTEL   VARCHAR2(50)   First Tel Contact       CONTACTEL2   VARCHAR2(50)   Second Tel Contact       CONTACTFAX   VARCHAR2(50)   Contact Fax       MOBILETEL   VARCHAR2(50)   Mobile Phone Number       FAX   VARCHAR2(50)   Fax Contact       CUSTTYPE   VARCHAR2(20)   Customer Type                  
 
         [0109]     Table 19 below provides an example implementation of the user table  1114 .  
                                       TABLE 19                           User Table            SDP_USR_T   USER            FIELD   TYPE   DESCRIPTION               USRID   VARCHAR2(20)   Username@Domain, may be a               primary key.       CUSTID   NUMBER(20)   Customer Identifier, may be a foreign               key from SDP_CUST_T       ISMASTER   CHAR(1)   Flag Indicating If User Is Master User       ISFIRSTCONNECT   CHAR(1)   Flag Indicating If User Is A Default               User For Subscription       DISPLAYNAME   VARCHAR2(100)   Full Name Of User       IDENTITY   VARCHAR2(50)   Provides an alias identity for the               subscriber, such as a nickname or               other alias which the subscriber uses               with instant messaging, chat, or other               telecommunication services.       PWD   VARCHAR2(50)   Password       USRSTATUS   VARCHAR2(20)   USER STATUS, e.g., Active, Blocked,               Pending, Configured. May Default To               ‘Active’       CREATEDATE   DATE   CREATION DATE, May Default To               The System Date       EXPDATE   DATE   Expiry Date       LASTMODIFYDATE   DATE   Last Modification Date       LASTMODIFYDESC   VARCHAR2(50)   Last Modification Description       LASTMODIFYWRITER   VARCHAR2(50)   Last Modification Writer       FIRSTCONNECTDATE   DATE   First Ever Connection Date       LASTCONNECTDATE   DATE   Last Ever Connection Date       AUTHTYPE   VARCHAR2(20)   Type Of Authentication                  
 
         [0110]     Tables 20, 21, and 22 below provide an example implementation of the product profile layer  1106 .  
                                       TABLE 20                           Product Instance Table            SDP_SUB_T   PRODUCT INSTANCE            FIELD   TYPE   DESCRIPTION               SUBID   NUMBER(20)   Subscription Identifier, may be a primary               key       CUSTID   NUMBER(20)   Customer Identifier, may be a foreign               key from SDP_CUST_T       PRODCODE   VARCHAR(20)   Product Code, may be a foreign key               from SDP_PROD_T       CUSTNETSVCID   NUMBER(20)   Customer Network Service Combination               Identifier, may be a foreign key from               SDP_CUST_NET_SVC_T       SUBSTATUS   VARCHAR2(20)   Subscription Status, may default to               Active       BILLINGCLI   VARCHAR2(24)   Billing Call Line Identifier       CREATEDATE   DATE   Creation Date, may default to the               System Date       EXPDATE   DATE   Expiry Date       SUBTYPE   VARCHAR2(20)   Subscription Type       BILLINGTYPE   VARCHAR2(20)   Type Of Billing       LASTMODIFYDATE   DATE   Last Modification Date       LASTMODIFYDESC   VARCHAR2(50)   Last Modification Description       LASTMODIFYWRITER   VARCHAR2(50)   Last Modification Writer                  
 
         [0111]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 21 
               
             
             
               
                   
               
               
                   
               
               
                 Product Catalog Table 
               
             
          
           
               
                 SDP_PROD_T 
                 PRODUCT CATALOGUE 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 PRODCODE 
                 VARCHAR2(20) 
                 Product Code, may be a primary 
               
               
                   
                   
                 key 
               
               
                 OFFERCODE 
                 VARCHAR2(20) 
                 Product Offering Identifier, may be 
               
               
                   
                   
                 a foreign key from 
               
               
                   
                   
                 SDP_OFFER_T 
               
               
                 PRODNAME 
                 VARCHAR2(50) 
                 Name Of The Product 
               
               
                 PRODTYPE 
                 VARCHAR2(20) 
                 Type Of The Product 
               
               
                 PRODCODE 
                 VARCHAR2(20) 
                 Code Of The Product 
               
               
                 PRODSTATUS 
                 VARCHAR2(20) 
                 Status Of The Product 
               
               
                   
               
             
          
         
       
     
         [0112]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 22 
               
             
             
               
                   
               
               
                   
               
               
                 Product Offer Table 
               
             
          
           
               
                 SDP_OFFER_T 
                 PRODUCT CATALOGUE 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 OFFERCODE 
                 VARCHAR2(20) 
                 Product Offering Identifier, 
               
               
                   
                   
                 may be a primary key 
               
               
                 OFFERNAME 
                 VARCHAR2(100) 
                 Product Offering Name 
               
               
                 OFFERSTATUS 
                 VARCHAR2(20) 
                 Product Offering Status 
               
               
                 COMOFFERTYPE 
                 VARCHAR2(50) 
                 Commercial Product 
               
               
                   
                   
                 Offering Name 
               
               
                   
               
             
          
         
       
     
         [0113]     Tables 23, 24, 25, 26, 27, 28, 29, and 30 below provide an example implementation of the service profile layer  1108 . The service profile layer allows the data model  1100  to distinguish between network services and application service. The network services may be services offered by telecommunication operators which permit subscribers to connect to the network (e.g., DSL service or dial-up service). The application services may represent the applications (e.g., programs) which the subscriber may use over the network (e.g., instant messaging, IPTV, and VoIP applications).  
                                       TABLE 23                           Application Service Instance Table            SDP_USR_SVC_T   APPLICATION SERVICE INSTANCE            FIELD   TYPE   DESCRIPTION               USRSVCID   NUMBER(20)   User - Service Combination               Identifier, may be a               primary key       SVCCODE   VARCHAR2(20)   Service Identifier, may be a               foreign key from               SDP_SVC_T       USRID   VARCHAR2(50)   Resource Identifier, may be a               foreign key from               SDP_USR_T       SUBID   NUMBER(20)   Subscription Identifier, may               be a foreign key from               SDP_SUB_T       STATUS   VARCHAR2(20)   Service Activation Status                  
 
         [0114]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 24 
               
             
             
               
                   
               
               
                   
               
               
                 Application Service Catalog Table 
               
             
          
           
               
                 SDP_SVC_T 
                 APPLICATION SERVICE CATALOG 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 SVCCODE 
                 VARCHAR2(20) 
                 Service Code, may be a primary key 
               
               
                 SVCNAME 
                 VARCHAR2(50) 
                 Service Name 
               
               
                 SVCTYPE 
                 VARCHAR2(20) 
                 Service Type 
               
               
                 SVCSTATUS 
                 VARCHAR2(20) 
                 Service Status 
               
               
                   
               
             
          
         
       
     
         [0115]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 25 
               
             
             
               
                   
               
               
                   
               
               
                 Application Service Parameter Table 
               
             
          
           
               
                 SDP_SVC_SPEC_T 
                 APPLICATION SERVICE PARAM 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 SVCCODE 
                 VARCHAR2(20) 
                 Service Code, may be a primary 
               
               
                   
                   
                 key and/or a foreign key from 
               
               
                   
                   
                 SDP_SVC_T 
               
               
                 APPSERVICEPARAMNAME 
                 VARCHAR2(50) 
                 Application Service Param Name, 
               
               
                   
                   
                 may be a primary key 
               
               
                 APPSERVICEPARAMTYPE 
                 VARCHAR2(50) 
                 Application Service Param Type 
               
               
                   
               
             
          
         
       
     
         [0116]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 26 
               
             
             
               
                   
               
               
                   
               
               
                 Application Service Data Table 
               
             
          
           
               
                 SDP_USR_SVC_PROP_T 
                 APPLICATION SERVICE DATA 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 USRSVCID 
                 NUMBER(20) 
                 User - Service Combination 
               
               
                   
                   
                 Identifier, may be a primary key 
               
               
                   
                   
                 and/or a foreign key from 
               
               
                   
                   
                 SDP_USR_SVC_T 
               
               
                 APPSERVICEPARAMNAME 
                 VARCHAR2(50) 
                 Application Service Parameter 
               
               
                   
                   
                 Name, may be a primary key 
               
               
                 APPSERVICEDATA 
                 VARCHAR2(50) 
                 Application Service Data 
               
               
                   
               
             
          
         
       
     
         [0117]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 27 
               
             
             
               
                   
               
               
                   
               
               
                 Network Service Instance Table 
               
             
          
           
               
                 SDP_CUST_NET_SVC_T 
                 NETWORK SERVICE INSTANCE 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 CUSTNETSVCID 
                 NUMBER(20) 
                 User Network Service Combination 
               
               
                   
                   
                 Identifier, may be a primary key. This 
               
               
                   
                   
                 field identifiers a unique association 
               
               
                   
                   
                 between a customer and a network 
               
               
                   
                   
                 service and may qualify the 
               
               
                   
                   
                 subscription (as a foreign key) to the 
               
               
                   
                   
                 service. 
               
               
                 CUSTID 
                 NUMBER(20) 
                 Customer Identifier, may be a foreign 
               
               
                   
                   
                 key from SDP_CUST_T 
               
               
                 NETSVCCODE 
                 VARCHAR2(20) 
                 Network Service Code, may be a 
               
               
                   
                   
                 foreign key from SDP_NET_SVC_T 
               
               
                 ACCESSSERVERID 
                 VARCHAR2(50) 
               
               
                 ACCESSSERVERIP 
                 VARCHAR2(15) 
               
               
                 SLOT 
                 NUMBER(3) 
               
               
                 PORT 
                 NUMBER(3) 
               
               
                 INTERFACE 
                 NUMBER(20) 
               
               
                 VCI 
                 NUMBER(5) 
               
               
                 VPI 
                 NUMBER(5) 
               
               
                 MAXAVAILBAND 
                 NUMBER(5) 
                 Provides an identifier of a maximum 
               
               
                   
                   
                 available bandwidth for the network 
               
               
                   
                   
                 service. 
               
               
                 GUARBAND 
                 NUMBER(5) 
                 Provides an identifier of the 
               
               
                   
                   
                 guaranteed bandwidth for the 
               
               
                   
                   
                 network service. 
               
               
                 COS 
                 NUMBER(5) 
                 Provides an identifier of a class of 
               
               
                   
                   
                 service, such as ‘Gold’ or ‘Silver’ 
               
               
                   
                   
                 indicators of bandwidth or other 
               
               
                   
                   
                 service characteristics. 
               
               
                   
               
             
          
         
       
     
         [0118]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 28 
               
             
             
               
                   
               
               
                   
               
               
                 Network Service Catalog Table 
               
             
          
           
               
                 SDP_NET_SVC_T 
                 NETWORK SERVICE CATALOGUE 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 NETSERVICECODE 
                 VARCHAR2(20) 
                 Network Service Code (i.e., 
               
               
                   
                   
                 NETSVCCODE), may be a 
               
               
                   
                   
                 primary key which provides 
               
               
                   
                   
                 a unique identifier of a 
               
               
                   
                   
                 network service in the 
               
               
                   
                   
                 catalogue. 
               
               
                 NETSERVICENAME 
                 VARCHAR2(50) 
                 Network Service Name 
               
               
                 NETSERVICETYPE 
                 VARCHAR2(20) 
                 Network Service Type 
               
               
                 NETSERVICESTATUS 
                 VARCHAR2(20) 
                 Network Service Status 
               
               
                   
               
             
          
         
       
     
         [0119]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 30 
               
             
             
               
                   
               
               
                   
               
               
                 Network Service Data Table 
               
             
          
           
               
                 SDP_NET_SVC_PROP_T 
                 NETWORK SERVICE DATA 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 CUSTNETSVCID 
                 NUMBER(20) 
                 Customer Network Service 
               
               
                   
                   
                 Combination Identifier, may be a 
               
               
                   
                   
                 primary key and/or a foreign key 
               
               
                   
                   
                 from SDP_CUST_NET_SVC_T 
               
               
                 NETSERVICEPARAMNAME 
                 VARCHAR2(50) 
                 Network Service Param Name, 
               
               
                   
                   
                 may be a primary key 
               
               
                 NETSERVICEDATA 
                 VARCHAR2(50) 
                 Network Service Data 
               
               
                   
               
             
          
         
       
     
         [0120]     Tables 31 and 32 below provide an example implementation of the presence layer  1110 .  
                                       TABLE 31                           Network Service Presence Table            SDP_NET_PRES_T   NETWORK SERVICE PRESENCE            FIELD   TYPE   DESCRIPTION               USRID   VARCHAR2(50)   Username@Domain, may be a primary               key       CUSTNETSVCID   NUMBER(20)   Customer Network Service Combination               Identifier, may be a foreign key from               SDP_CUST_NET_SVC_T. This field               provides a unique identifier of an               association between a customer and a               network service, and may qualify a               subscription to a service.       IDENTITY   VARCHAR2(50)   Alias Identity       IP   VARCHAR2(50)   IP Address       ACCESSSERVERIP   VARCHAR2(50)   Access Server IP       ACCESSSERVERID   VARCHAR2(15)   Access Server ID       MAXAVAILBAND   NUMBER(5)   Max Available Band       GUARBAND   NUMBER(5)   Guaranteed Band       NETSERVICECODE   VARCHAR2(20)   Network Service Code       TIMESTAMP   DATE   Timestamp                  
 
         [0121]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 29 
               
             
             
               
                   
               
               
                   
               
               
                 Network Service Parameter Table 
               
             
          
           
               
                 SDP_NET_SVC_SPEC_T 
                 NETWORK SERVICE PARAM 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 NETSERVICECODE 
                 VARCHAR2(20) 
                 Network Service Code, may be a 
               
               
                   
                   
                 primary key and/or a foreign key from 
               
               
                   
                   
                 SDP_NET_SVC_T 
               
               
                 NETSERVICEPARAMNAME 
                 VARCHAR2(50) 
                 Network Service Param Name, 
               
               
                   
                   
                 may be a primary key 
               
               
                 NETSERVICEPARAMTYPE 
                 VARCHAR2(50) 
                 Network Service Param Type 
               
               
                   
               
             
          
         
       
     
         [0122]    
       
         
               
             
               
               
             
               
               
               
             
           
               
                 TABLE 32 
               
             
             
               
                   
               
               
                   
               
               
                 Application Service Presence Table 
               
             
          
           
               
                 SDP_SVC_PRES_T 
                 APPLICATION SERVICE PRESENCE 
               
             
          
           
               
                 FIELD 
                 TYPE 
                 DESCRIPTION 
               
               
                   
               
               
                 USRSVCID 
                 NUMBER(20) 
                 User - Service Combination Identifier, 
               
               
                   
                   
                 may be a primary key and/or a foreign 
               
               
                   
                   
                 key from SDP_USR_SVC_T 
               
               
                 USRID 
                 VARCHAR2(50) 
                 Username@Domain, may be a primary 
               
               
                   
                   
                 key and/or a foreign key from 
               
               
                   
                   
                 SDP_USR_T 
               
               
                 IDENTITY 
                 VARCHAR2(50) 
                 Alias Identity 
               
               
                 PORT 
                 NUMBER(20) 
                 Port 
               
               
                 CONTACTIP 
                 VARCHAR2(50) 
                 IP Address 
               
               
                 EXPIRY 
                 NUMBER(20) 
                 Expiry Time 
               
               
                 DISPLAYNAME 
                 VARCHAR2(100) 
                 Display Name 
               
               
                 STATUS 
                 VARCHAR2(20) 
                 Status 
               
               
                 SVCCODE 
                 VARCHAR2(50) 
                 Service Code 
               
               
                 TIMESTAMP 
                 DATE 
                 Timestamp 
               
               
                   
               
             
          
         
       
     
         [0123]     The network service instance table  1122  instantiates network services subscribed by the users. There may exist a one to many relationship to the network service presence table  1136 . Thus, the data model  1100  provides tracking capability for multiple sets of presence information for the same network resource (e.g., multiple PPP sessions on the same DSL modem). Similarly, the application service instance table  1130  instantiates application services subscribed by the users. There may exist a one to many relationship to the application service presence table  1138 . Thus, the data model  1100  provides tracking capability for multiple sets of presence information for the same user and application resource.  
         [0124]      FIG. 12  shows acts  1200  which the presence system  202  may take to process subscriber connection messages. The presence system  202  receives, as examples, a RADIUS or DHCP message (Act  1202 ). A load balancer in the presence system  202  may distribute incoming messages between multiple message publishers  304  to balance the message processing load and increase performance (Act  1204 ).  
         [0125]     The message publishers  304  generate connection messages according to a common format and publish the messages (Act  1206 ). Thus, the message queue manager  306  receives and queues the published connection messages  325  (Act  1208 ). The message queue manager  306  delivers the published connection messages to message subscribers, such as the presence manager  308  (Act  1210 ).  
         [0126]     The message publisher/subscriber  328  in the presence manager  308  receives the published connection messages. The rules manager  330  may then apply the routing rules  332  to determine how to queue the received connection message for further processing (Act  1212 ). For example, the rules manager  330  may determine whether to queue the connection message in a technical key management queue  336  or a presence management queue  334 .  
         [0127]     The technical key management queue  336  and TK queue logic  340  authenticate subscriber connection requests. Such requests may arise from RADIUS authentication or DHCP discover messages, as examples. If the subscriber is authenticated, the TK queue logic  340  inserts the subscriber information into the unified directory system  204 . Subsequent messages processed through the presence management queue  334  may then give rise to subscriber information updates in the unified directory, such as IP address information updates.  
         [0128]     As described above, certain messages may be inserted into the technical key management queue  336  (Act  1214 ). The technical key queue logic  340  extracts messages from the queue  336  (Act  1216 ). The technical key queue logic  340  processes the messages according to the technical key queue logic processing rules, such as those shown in Table 16. For example, the technical key queue logic  340  queries the unified directory  204  for a subscriber matching the technical key provided in the published connection message (Act  1218 ). If a matching subscriber technical key is not found, then the presence system  202  sends a subscriber insertion message to the unified directory system  204 .  
         [0129]     The subscriber insertion message may request the unified directory system  204  to insert a subscriber identifier (e.g., a username or other subscriber identifier), a network service instance identifier (e.g., CUSTNETSVCID) which provides a unique identifier of an association between a customer and a network service, or other subscriber profile information into the subscriber profile data store which the unified directory system  204  maintains. The unified directory system  204  may insert the subscriber profile information into the network service presence table  1136 . As a result, the presence system  202  keeps the unified directory system  204  up to date with respect to subscriber connection activity. The unified directory system  204  may thereby response to subscriber profile queries with current information about the subscriber.  
         [0130]     As another example, certain messages may be inserted into the presence management queue  334  (Act  1222 ). The presence queue logic  338  extracts messages from the presence management queue  336  (Act  1224 ) for processing. The presence queue logic  338  may query the unified directory  204  to determine whether a matching USRID and network service instance identifier are already present in the network service presence table  1136  (Act  1226 ).  
         [0131]     If so, the presences system  202  sends a subscriber update message to the unified directory system  204 . The subscriber update message instructs the unified directory system  204  to update the network service presence table  1136  with the current subscriber IP address provided in the published subscriber connection message. If a matching USRID and network service instance identifier are not already present, then the presence system  202  sends a subscriber presence insertion message to the unified directory system  204 . The subscriber presence insertion message may instruct the unified directory system  204  to insert a subscriber identifier (e.g., a username or other subscriber identifier), a network service instance identifier, a current subscriber IP address (provided in the published connection message) or other subscriber profile information into the subscriber profile data store which the unified directory system  204  maintains. Thus, the presence system  202  updates changing or additional subscriber connection information in the unified directory system  204 , and also ensures that active subscribers are noted in the presence information maintained in the network service presence table.  
         [0132]      FIG. 13  shows acts  1300  which the unified directory system  204  may take to process subscriber insertion or subscriber update messages. The unified directory system  204  receives the subscriber insertion and update messages (Act  1302 ). A load balancer  1012  may distribute the subscriber insertion and update messages among the persistent nodes  1020 - 1022  to balance the load and improve performance (Act  1304 ).  
         [0133]     For subscriber insertion messages, the unified directory system  204  inserts the requested subscriber information into the network service presence table  1136 . The unified directory system  204  extracts the requested subscriber information from the insertion message (Act  1305 ). For example, the subscriber insertion message may instruct the unified directory system  204  to insert a subscriber identifier such as a username (Act  1306 ). As another example, the subscriber insertion message may instruct the unified directory system  204  to insert a network service instance identifier (Act  1308 ). As yet another example, the subscriber insertion message may instruct the unified directory system  204  to insert the subscriber IP address into the network service presence table  1136  (Act  1310 ).  
         [0134]     The unified directory system  204  may also process subscriber update messages. To that end, the unified directory system  204  may extract an updated subscriber IP address from the update message (Act  1312 ). The unified directory system  204  may then update the IP address in the network service presence table  1136  with the extracted IP address (Act  1314 ).  
         [0135]      FIG. 14  shows acts  1400  which the unified directory system  204  may take to process unified directory queries from the presence system  202  and from external systems  1006 , such as the service broker  116 , third party access gateway  110 , and other external systems. The unified directory system  204  receives the query message (Act  1402 ). The query message may take many different forms. As examples, the query message may be a network service instance query or a network service presence query from the presence system  202 . As additional examples, the query message may be a user status query, network service data query, or application service data query received from an external system.  
         [0136]     The presence manager  202  sends a query to the unified directory system  204  when attempting to find a matching customer ID (as noted above in Tables 16 and 17). The unified directory system  204  may respond by searching the data access layer  1010  for matching records from the network service instance table based on the CUSTID which matches the username provided in the published subscriber connection message (Act  1404 ) and which is established in the user table. A search query results.  
         [0137]     Additionally, the presence manager  202  may send a query of the network service presence table  1136  when attempting to determine if a matching subscriber has been established in the network service presence table  1136  (as noted above in Tables 16 and 17). The unified directory system  204  may respond by searching the data access layer  1010  for matching records from the network service presence bale  1136  based on a username and network service instance identifier. A search query results. For either type of query message from the presence system  202 , the unified directory system  204  returns the search query result to the presence manager  308  through the presence interface  210  (Act  1408 ).  
         [0138]     External systems may query the unified directory system  204  for subscriber profile information through the external interface  212 . For example, the external systems may send a user status query, a network service data query, an application service data query, or another type of query. The unified directory system  204  determines the type of query based on message content (Act  1410 ), such as a message label field (e.g., TSOLABEL in the messages shown below). The unified directory system  204  queries the data access layer  1010  for the requested information (Act  1412 ). A search query results and is returned to the external system (Act  1414 ).  
         [0139]     Table 33 provides an example of a user status query message. The unified directory system  204  may search for subscribers which match each of the attributes in the message, and return the subscriber profile information for each matching subscriber. The SVC_PROP_T tables establish application service parameter names and store associated parameter data values for subscribed network and application services. In the example in Table 33, user status is queried with respect to an application service (“bac0010001”) matching an application service parameter named “CATEGORYID” with a value of “C01”. The SERVICEID field may be matched against the service code (e.g., SVCCODE) in the SVC_T tables.  
         [0140]     The profile information may include presence information which indicates whether the subscriber is online or offline, for example. Table 34 provides an example of a user status query response which delivers the search query results to the external system.  
                                     TABLE 33                           User status query message                    Field   Description               TSOID   A unique identifier of the message       TSOLABEL   An identifier of the message type, e.g.,           GETUSERSTATUS       Attribute Name   An identifier of a subscriber attribute or service           parameter, e.g., a category of user (CATEGORYID)       Attribute Name   An identifier of a subscriber attribute, e.g., a user           ID (USERID)       Attribute Name   An identifier of a subscriber attribute, e.g., a service           identifier (SERVICEID)                    Example XML user status query message                    &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt;        &lt;TSO_DATA xmlns:xsi=“http://www.w3.org/2001/XMLSchema-        instance”       xsi:noNamespaceSchemaLocation=“F:\tmp \TSOSchema_3PGW.xsd”&gt;        &lt;TSOheader TSOID=“12345” TSOlabel=“GETUSERSSTATUS” /&gt;         &lt;TSOattributes&gt;          &lt;attribute name=“CATEGORYID” value=“C01” /&gt;          &lt;attribute name=“USERID” value=“ ” /&gt;          &lt;attribute name=“SERVICEID” value=“bac0010001” /&gt;         &lt;/TSOattributes&gt;        &lt;/TSO_DATA&gt;                  
 
         [0141]    
       
         
               
             
               
               
             
               
             
               
             
           
               
                 TABLE 34 
               
               
                   
               
               
                   
               
             
             
               
                 User status query response 
               
               
                   
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 TSOID 
                 A unique identifier of the message 
               
               
                 TSOLABEL 
                 An identifier of the message type, e.g., 
               
               
                   
                 GETUSERSTATUS 
               
               
                 User ID List 
                 A list of matching User IDs 
               
               
                 User Status List 
                 A list giving the user status for each matching User ID 
               
               
                 TSOResult 
                 A result status code, error code, and error description 
               
               
                   
               
             
          
           
               
                 Example XML user status query response message 
               
               
                   
               
             
          
           
               
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                  &lt;TSO_DATA xmlns:xsi=“http://www.w3.org/2001/XMLSchema- 
               
               
                  instance” 
               
               
                 xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt; 
               
               
                  &lt;TSOheader TSOID=“12345” TSOlabel=“GETUSERSSTATUS” /&gt; 
               
               
                   &lt;TSOattributes&gt; 
               
               
                   &lt;list name=“USERSID” value=“3”&gt; 
               
               
                     &lt;attribute name=“1” value=“grant@mail” /&gt; 
               
               
                     &lt;attribute name=“2” value=“bob@mail” /&gt; 
               
               
                     &lt;attribute name=“3” value=“deb@mail” /&gt; 
               
               
                   &lt;/list&gt; 
               
               
                   &lt;list name=“USERSSTATUS” value=“3”&gt; 
               
               
                     &lt;attribute name=“1” value=“ONLINE” /&gt; 
               
               
                     &lt;attribute name=“2” value=“OFFLINE” /&gt; 
               
               
                     &lt;attribute name=“3” value=“ONLINE” /&gt; 
               
               
                   &lt;/list&gt; 
               
               
                   &lt;/TSOattributes&gt; 
               
               
                   &lt;TSOresult&gt; 
               
               
                    &lt;statusCode&gt;0&lt;/statusCode&gt; 
               
               
                    &lt;errorCode&gt;&lt;/errorCode&gt; 
               
               
                    &lt;errorDescription&gt;&lt;/errorDescription&gt; 
               
               
                  &lt;/TSOresult&gt; 
               
               
                 &lt;/TSO_DATA&gt; 
               
               
                   
               
             
          
         
       
     
         [0142]     Table 35 provides an example of a network service data query message. The unified directory system  204  may search the network service profile tables  1120 - 1126 , and return network profile information for each matching network service. The network profile information may include the subscriber&#39;s account ID, network status, location, access type, or other profile information. Table 36 provides an example of a network service query response which delivers the search query results to the external system.  
                                     TABLE 35                           Network service data query message                    Field   Description               TSOID   A unique identifier of the message       TSOLABEL   An identifier of the message type, e.g.,           GETNETWORKSERVICEDATA       Attribute Name   An identifier of an attribute of a network service,           e.g., a Mobile Station Integrated Services Digital           Network (MSISDN) identifier for a mobile phone, or           an IP Address for a IPTV connection.                    Example XML network service data query message                    &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt;        &lt;TSO_DATA xmlns:xsi=“http://www.w3.org/2001/XMLSchema-        instance”       xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt;        &lt;TSOheader TSOID=“12345”        TSOlabel=“GETNETWORKSERVICEDATA” /&gt;          &lt;TSOattributes&gt;          &lt;attribute name=“IPADDRESS” value=“80.17.10.23” /&gt;         &lt;/TSOattributes&gt;        &lt;/TSO_DATA&gt;                  
 
         [0143]    
       
         
               
             
               
               
             
               
             
               
               
             
           
               
                 TABLE 36 
               
               
                   
               
               
                   
               
             
             
               
                 Network service data query response message 
               
               
                   
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 TSOID 
                 A unique identifier of the message 
               
               
                 TSOLABEL 
                 An identifier of the message type, e.g., 
               
               
                   
                 GETNETWORKSERVICEDATA 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., an account 
               
               
                 Name 
                 identifier (ACCOUNTID) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a network 
               
               
                 Name 
                 status identifier (NETSTATUS) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a location 
               
               
                 Name 
                 name (LOCATION) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a type or 
               
               
                 Name 
                 characteristic of access, such as speed (TYPEOFACCESS) 
               
               
                 TSOResult 
                 A result status code, error code, and error description 
               
               
                   
               
             
          
           
               
                 Example XML network service data query response message 
               
               
                   
               
             
          
           
               
                   
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                   
                  &lt;TSO_DATA xmlns:xsi=“http://www.w3.org/2001/XMLSchema- 
               
               
                   
                  instance” 
               
               
                   
                 xsi:noNamespaceSchemaLocation= 
               
               
                   
                 “F:\tmp\UK\TSOSchema_3PGW.xsd”&gt; 
               
               
                   
                  &lt;TSOheader TSOID=“12345” 
               
               
                   
                  TSOlabel=“GETNETWORKSERVICEDATA” /&gt; 
               
               
                   
                    &lt;TSOattributes&gt; 
               
               
                   
                    &lt;attribute name=“ACCOUNTID” value=“0687180081” /&gt; 
               
               
                   
                    &lt;attribute name=“NETSTATUS” value=“OK” /&gt; 
               
               
                   
                    &lt;attribute name=“LOCATION” value=“Rome” /&gt; 
               
               
                   
                    &lt;attribute name=“TYPEOFACCESS” value=“MEGA” /&gt; 
               
               
                   
                   &lt;/TSOattributes&gt; 
               
               
                   
                  &lt;/TSO_DATA&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0144]     Table 37 provides an example of an application service data query message. The unified directory system  204  may search the application tables  1128 - 1134  for applications which match each of the attributes in the message, and return application service profile information for each matching application. The application service profile information may include technical profile information for the service, such as account ID, subscriber first name and last name, billing city, billing address, plan ID, customer type, or other profile information. Table 38 provides an example of a network service query response which delivers the search query results to the external system.  
                                         TABLE 37                           Application service data query message            Field   Description               TSOID   A unique identifier of the message       TSOLABEL   An identifier of the message type, e.g.,           GETAPPLICATIONSERVICEDATA       Attribute   One or more identifiers of attributes of an application       Name   service, e.g., a Mobile Station Integrated Services           Digital Network (MSISDN) identifier for a mobile phone,           a service identifier, and/or an IP Address when the           subscriber interacts directly with an application such as           an IPTV application.                    Example XML application service data query message                        &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt;            &lt;TSO_DATA xmlns:xsi=“http://www.w3.org/2001/XMLSchema-            instance”           xsi:noNamespaceSchemaLocation=           “F:\tmp\TSOSchema_3PGW.xsd”&gt;            &lt;TSOheader TSOID=“12345”            TSOlabel=“GETAPPLICATIONSERVICEDATA” /&gt;              &lt;TSOattributes&gt;              &lt;attribute name=“IPADDRESS” value=“77.17.10.23” /&gt;             &lt;attribute name=“SERVICEID” value=“bac0014001” /&gt;             &lt;/TSOattributes&gt;            &lt;/TSO_DATA&gt;                      
 
         [0145]    
       
         
               
             
               
               
             
               
             
               
             
               
             
               
             
           
               
                 TABLE 38 
               
               
                   
               
               
                   
               
             
             
               
                 Application service data query response message 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 TSOID 
                 A unique identifier of the message 
               
               
                 TSOLABEL 
                 An identifier of the message type, e.g., 
               
               
                   
                 GETAPPLICATIONSERVICEDATA 
               
               
                 Attribute 
                 A flag which begins a list of technical application service 
               
               
                 Name 
                 information 
               
               
                 List Name 
                 A flag which begins a list of technical application service 
               
               
                   
                 information 
               
               
                 Attribute 
                 One or more identifiers of an application service 
               
               
                 Names 
                 attribute, e.g., an account identifier, subscriber first name, 
               
               
                   
                 last name, the street address where a bill is sent, the 
               
               
                   
                 region (e.g., province) where a bill is sent, a postal code for 
               
               
                   
                 the address where the bill is sent, and a county where 
               
               
                   
                 the bill is sent. 
               
               
                 TSOResult 
                 A result status code, error code, and error description 
               
               
                   
               
             
          
           
               
                 Example XML application service data query response message for 
               
               
                 IPTV application service 
               
               
                   
               
             
          
           
               
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                   &lt;TSO_DATA xmlns:xsi= 
               
               
                   “http://www.w3.org/2001/XMLSchema-instance” 
               
               
                 xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt; 
               
               
                   &lt;TSOheader TSOID=“12345” TSOlabel= 
               
               
                  “GETAPPLICATIONSERVICEDATA” /&gt; 
               
               
                   &lt;TSOattributes&gt; 
               
               
                   &lt;attribute name=“SERVICESTATUS” value=“OK” /&gt; 
               
               
                   &lt;list name=“SERVICETECHNICALPROFILE”&gt; 
               
               
                   &lt;attribute name=“ACCOUNTID” value=“0687180081” /&gt; 
               
               
                   &lt;attribute name=“ACCFIRSTNAME” value=“Gordon” /&gt; 
               
               
                   &lt;attribute name=“ACCLASTNAME value=“Freeman” /&gt; 
               
               
                   &lt;attribute name=“ACCBILLCITY” value=“City” /&gt; 
               
               
                   &lt;attribute name=“ACCBILLADDRESS1” value=“Lambda Street” /&gt; 
               
               
                   &lt;attribute name=“ACCBILLREGION” value=“Region1” /&gt; 
               
               
                   &lt;attribute name=“ACCBILLPOSTALCODE” value=“00100” /&gt; 
               
               
                   &lt;attribute name=“ACCBILLCOUNTRY” value=“Country1” /&gt; 
               
               
                 &lt;/list&gt; 
               
               
                   &lt;/TSOattributes&gt; 
               
               
                  &lt;/TSO_DATA&gt; 
               
               
                   
               
             
          
           
               
                 Example XML application service data query response message for 
               
               
                 mobile phone application service 
               
               
                   
               
             
          
           
               
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                   &lt;TSO_DATA xmlns:xsi= 
               
               
                   “http://www.w3.org/2001/XMLSchema-instance” 
               
               
                 xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt; 
               
               
                   &lt;TSOheader TSOID=“12345” TSOlabel= 
               
               
                   “GETAPPLICATIONSERVICEDATA” /&gt; 
               
               
                   &lt;TSOattributes&gt; 
               
               
                   &lt;attribute name=“SERVICESTATUS” value=“OK” /&gt; 
               
               
                 &lt;list name=“SERVICETECHNICALPROFILE”&gt; 
               
               
                   &lt;attribute name=“COUNTRYCODE” value=“0039” /&gt; 
               
               
                   &lt;attribute name=“ROAMINGSTATUS” value=“StatusA” /&gt; 
               
               
                   &lt;attribute name=“ACCESSCHANNEL” value=“Ch3” /&gt; 
               
               
                   &lt;attribute name=“ROAMINGPARTNER” value=“H3G” /&gt; 
               
               
                   &lt;attribute name=“CUSTOMERTYPE” value=“Business” /&gt; 
               
               
                   &lt;attribute name=“PLANID” value=“Plan005” /&gt; 
               
               
                   &lt;attribute name=“SIMTYPE” value=“PREPAID” /&gt; 
               
               
                   &lt;attribute name=“TERMINALMODE” value=“DUAL” /&gt; 
               
               
                   &lt;attribute name=“MMSSTATUS” value=“OK” /&gt; 
               
               
                   &lt;attribute name=“UMTSSTATUS” value=“OK” /&gt; 
               
               
                   &lt;attribute name=“GPRSSTATUS” value=“OK” /&gt; 
               
               
                 &lt;/list&gt; 
               
               
                   &lt;/TSOattributes&gt; 
               
               
                  &lt;/TSO_DATA&gt; 
               
               
                   
               
             
          
         
       
     
         [0146]     Table 39 provides an example of a user profile query message. The unified directory system  204  may search the subscriber profile data store for the matching user profile information, and return the profile information to the external system. Table 40 provides an example of a user profile query response which delivers the search query results to the external system.  
                                     TABLE 39                           User profile query message            Field   Description               TSOID   A unique identifier of the message       TSOLABEL   An identifier of the message type, e.g.,           GETUSERPROFILE       Attribute   An identifier of an attribute of a network service,       Name   e.g., a Mobile Station Integrated Services Digital Network           (MSISDN) identifier for a mobile phone, or an IP Address           for a IPTV connection.                    Example XML user profile query message                    &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt;        &lt;TSO_DATA xmlns:xsi=        “http://www.w3.org/2001/XMLSchema-instance”       xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt;        &lt;TSOheader TSOID=“12345” TSOlabel=“GETUSERPROFILE” /&gt;         &lt;TSOattributes&gt;         &lt;attribute name=“IPADDRESS” value=“80.17.10.23” /&gt;         &lt;/TSOattributes&gt;        &lt;/TSO_DATA&gt;                  
 
         [0147]    
       
         
               
             
               
               
             
               
             
               
             
           
               
                 TABLE 40 
               
               
                   
               
               
                   
               
             
             
               
                 User profile query response message 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 TSOID 
                 A unique identifier of the message 
               
               
                 TSOLABEL 
                 An identifier of the message type, e.g., 
               
               
                   
                 GETUSERPROFILE 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., an account 
               
               
                 Name 
                 identifier (ACCOUNTID) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a network 
               
               
                 Name 
                 status identifier (NETSTATUS) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a location 
               
               
                 Name 
                 name (LOCATION) 
               
               
                 Attribute 
                 An identifier of a network service attribute, e.g., a type or 
               
               
                 Name 
                 characteristic of access, such as speed (TYPEOFACCESS) 
               
               
                 TSOResult 
                 A result status code, error code, and error description 
               
               
                   
               
             
          
           
               
                 Example XML user profile query response message 
               
               
                   
               
             
          
           
               
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                   &lt;TSO_DATA xmlns:xsi= 
               
               
                   “http://www.w3.org/2001/XMLSchema-instance” 
               
               
                 xsi:noNamespaceSchemaLocation=“F:\tmp\UK\ 
               
               
                 TSOSchema_3PGW.xsd”&gt; 
               
               
                   &lt;TSOheader TSOID=“12345” TSOlabel=“GETUSERPROFILE” /&gt; 
               
               
                   &lt;TSOattributes&gt; 
               
               
                   &lt;attribute name=“ACCOUNTID” value=“testemail@test.com” /&gt; 
               
               
                   &lt;attribute name=“NETSTATUS” value=“OK” /&gt; 
               
               
                   &lt;attribute name=“LOCATION” value=“Rome” /&gt; 
               
               
                   &lt;attribute name=“TYPEOFACCESS” value=“MEGA” /&gt; 
               
               
                   &lt;/TSOattributes&gt; 
               
               
                  &lt;/TSO_DATA&gt; 
               
               
                   
               
             
          
         
       
     
         [0148]     Table 41 provides an example of a service profile query message, which returns information concerning the status of the service identified in the query message. Table 40 provides an example of a user profile query response which delivers the query results to the external system.  
                                     TABLE 41                           Service profile query message            Field   Description               TSOID   A unique identifier of the message       TSOLABEL   An identifier of the message type, e.g.,           GETSERVICEPROFILE       Attribute Name   An identifier of an attribute of a network service, e.g.,           an IP Address for a IPTV connection, and a Service ID.                    Example XML service profile query message                    &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt;         &lt;TSO_DATA xmlns:xsi=        “http://www.w3.org/2001/XMLSchema-instance”       xsi:noNamespaceSchemaLocation=“F:\tmp\TSOSchema_3PGW.xsd”&gt;         &lt;TSOheader TSOID=“12345” TSOlabel=         “GETSERVICEPROFILE” /&gt;         &lt;TSOattributes&gt;         &lt;attribute name=“IPADDRESS” value=“80.17.10.23” /&gt;         &lt;attribute name=“SERVICEID” value=“ar0203030202” /&gt;         &lt;/TSOattributes&gt;        &lt;/TSO_DATA&gt;                  
 
         [0149]    
       
         
               
             
               
               
             
               
             
               
             
           
               
                 TABLE 40 
               
               
                   
               
               
                   
               
             
             
               
                 Service profile query response message 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 TSOID 
                 A unique identifier of the message 
               
               
                 TSOLABEL 
                 An identifier of the message type, e.g., 
               
               
                   
                 GETSERVICEPROFILE 
               
               
                 Attribute Name 
                 An identifier of a status of the service 
               
               
                   
                 (SERVICESTATUS) 
               
               
                 Attribute Name 
                 An identifier of data associated with the service (e.g., 
               
               
                   
                 an email account address) 
               
               
                   
                 (SERVICEDATA) 
               
               
                 TSOResult 
                 A result status code, error code, and error description 
               
               
                   
               
             
          
           
               
                 Example XML service profile query response message 
               
               
                   
               
             
          
           
               
                 &lt;?xml version=“1.0” encoding=“ISO-8859-1” ?&gt; 
               
               
                   &lt;TSO_DATA xmlns:xsi= 
               
               
                   “http://www.w3.org/2001/XMLSchema-instance” 
               
               
                 xsi:noNamespaceSchemaLocation= 
               
               
                 “F:\tmp\UK\TSOSchema_3PGW.xsd”&gt; 
               
               
                   &lt;TSOheader 
               
               
                   TSOID=“12345” TSOlabel=“GETSERVICEPROFILE” /&gt; 
               
               
                   &lt;TSOattributes&gt; 
               
               
                   &lt;attribute name=“SERVICESTATUS” value=“ok” /&gt; 
               
               
                   &lt;attribute name=“SERVICEDATA” value=“e.jarvis@sb.com” /&gt; 
               
               
                   &lt;/TSOattributes&gt; 
               
               
                  &lt;/TSO_DATA&gt; 
               
               
                   
               
             
          
         
       
     
         [0150]     The subscriber profile access management system  122  provides technical solutions to the problems of extensive dispersal of subscriber profile information between many different telecommunication support systems. The interfaces to the subscriber profile access management system  122  allow the unified directory system  204  to act as the single access point to subscriber profile information. The presence system  202 , through the message publisher and presence manager, and the unified directory system  204 , through the high performance multi-node data access layer, provides a technical solution to handling the profile queries, insertions, and updates for a carrier grade environment which supports hundreds of thousands to millions of subscribers.  
         [0151]     Furthermore, the layered structure and table implementation of the data model  1100  provides a technical solution to independently tracking and managing presence information for both network services and application services. In addition, the layered structure of the data model  1100  provides a technical solution to establishing and monitoring presence information, independently, for both network services and application services. Accordingly, the subscriber profile access management system  122  effectively provides a single point of access to subscriber profile information for a carrier grade telecommunications service provider.  
         [0152]     This application incorporates by reference the entirety of each of the following U.S. patent applications:  
         [0153]     Unified Directory System Including a Data Model for Managing Access to Telecommunications Services, attorney docket number 10022-744, filed ______, and assigned Ser. No. ______.  
         [0154]     Message Sequencing and Data Translation Architecture for Telecommunication Services, attorney docket number 10022-746, filed ______, and assigned Ser. No. ______.  
         [0155]     Service Broker Integration Layer for Supporting Telecommunication Client Service Requests, attorney docket number 10022-730, filed ______, and assigned Ser. No. ______.  
         [0156]     Authentication and Authorization Architecture for an Access Gateway, attorney docket number 10022-742, filed ______, and assigned Ser. No. ______.  
         [0157]     Third Party Access Gateway for Telecommunications Services, attorney docket number 10022-726, filed ______, and assigned serial number ______.  
         [0158]     While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.