Methods and systems for implementing service level consolidated user information management

Embodiments of the invention provide methods and systems for implementing service level consolidated user information management. According to one embodiment, a method comprises intercepting, at a policy enforcer, a manipulation request of data. The method may further include analyzing the request to determine which data the manipulation request is associated with and, based on that analysis, selecting a policy from a plurality of policies. Furthermore, the method may execute the selected policy. The policy may be configured to direct the policy enforcer to allow the manipulation request to pass through to the associated destination data system to process the request, delegate processing of the manipulation request to at least one of a plurality of data systems, or process the manipulation request by the policy enforcer.

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate generally to methods and systems for implementing service level consolidated user information management and more particularly to providing a policy enforcing mechanism to manage routing of requests related to user information.

As an ever increasing number of services are being offered by various network providers, there is a corresponding increase in the number of systems, devices, applications, and components that utilize and store data for customers. Data typically is stored in databases as either structured or unstructured data. Directories (e.g., Lightweight Directory Access Protocol (LDAP) directories) can be used to store the data, as well as various schemas. XML data can be stored in XML-aware databases and repositories such as are found in XML Data Management (XDM) servers allow storage and exchange of XML data. Other examples include dynamic data such as network information (e.g., Home Subscriber Server (HSS) data, Home Location Register (HLR) data), presence information, location from network resources, etc. Data that may be considered for aggregation includes: Operations Support System (OSS) and Business Support System (BSS) data such as subscription data, account information, billing information, bills, inventory of assets, etc. (all of this information can be represented in TMF Shared Information/Data (SID) data model). All of these are particular examples of data repositories.

Existing systems used to capture, describe, present, etc. user profiles do not provide a view or aggregation of data from other domains, where data manipulation can be accomplished, accompanied by, or conditioned by execution of a policy (i.e., any combination of any condition and any action) that may call other systems to perform tasks that may update or result in updates of the data as needed, and that provide a view of the updated results or that may call other systems to perform tasks as a result of the update. Typically, these other systems are the “master controller” or “owner” of the data that is viewed. Data manipulation then is typically done as a request to change data in a system, a security check or identity authentication/validation, and a change of data by the database or repository. Such approaches can lead to problems in that changes made in one system might not align or be consistent with other systems using the same data, or consistent with related data in the same or other systems. As such, when a change takes place, the other data should be changed by other processes that result from the change or processes should be able to be initiated which result from the change to ensure that the other systems are properly updated.

Certain information thus overlaps or is related to other information stored for different services or in different repositories. Unfortunately, it is usually not practical for most entities to rewrite the schemas or redesign all the systems and services to use a common data model, single repository, single point of access, etc. As such, there typically is no way to easily treat the various repositories as a single data source that is readily available to applications, users, etc.

A significant problem thus exists in the fact that updating information in one data repository may require corresponding changes or updates in other repositories and/or running processes/workflows, with each repository storing information for multiple applications. In order to update data in a repository, the overall system assumes that several processes, workflows, applications, or at an initial or intermediate step, and that these applications have executed their own processes may have changed the context or data elsewhere. As such, these flows are not triggered and must separately manually (e.g., via a check list or the like) or consistency of the data must be periodically checked and updated as a result. So currently there are often many inconsistencies as a result, at least till reconciliation is performed. Or alternatively such approaches to integrate do not work and cannot be used to allow data updates via the profile. In other words, changes must be done on all systems when a change is to take place, as opposed to a request to a profile that carries the changes through to all systems effected.

For example, adding a subscription for a user in a BSS may also require updating support data and asset data (e.g. in an OSS, Network, or run time environment like service delivery platform (SDP)), as well as ensuring that some provisioning, activation, fulfillment, and/or billing takes place, as well as Enterprise Resource Planning Software (ERP) flows, (e.g., to supply equipment like delivering a phone, modem, or laying a cable, etc.) etc. If the data is allowed to be updated without following all such flows, data existing elsewhere (e.g. catalog or provisioning flows, new rates, inventories of assets associated to a principal (e.g. subscriber) or support details, etc.) may be dropped (i.e., not appropriately added/updated). Further, other data in the same repository that might need to be modified as a result of the change might not be modified appropriately. For example, an action such as creating a customer record in a customer database for a business such as a telecommunications service provider requires other updates or processes to be run for other systems, such as where a new customer must be added to the billing system in order to ensure that the customer will be billed for the service. The customer information must also be manually added to a support system so that the customer can receive necessary support, etc. It thus is not enough to simply update the information locally but all other necessary processes also must be executed in response to the update.

In the case of a service, when an update is to take place, it often is difficult to know where information is located, which information needed to be updated, as well as anything else that may need to be updated in order to maintain consistency of the entire system. This can significantly slow access, use, and changes to data such as subscription data. Many initiatives to offer such capabilities either fail or are extremely difficult to implement and/or integrate within a service provider's domain. Hence, there is value in offering a single API that allows the service to make queries without being made aware of specific details about the data, where the data is located, etc. In fact, many applications do not want to be made aware of the location of the data, how to keep the data consistent, what other OSS/BSS business flows to take into account, etc.

Hence, there is a need for improved methods and systems for implementing service level consolidated user information management.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention provide systems and methods for implementing service level consolidated user information management. According to one embodiment, a method of implementing service level consolidated user information management can comprise receiving and/or intercepting, at a policy enforcer, a manipulation request of data. The selection of a policy to process/execute is a function of the manipulation request (i.e., viewing/accessing rights, changing/modifying rights, deletion rights, etc.) and the target data (i.e., which system/repository owns the data, is the data owned by one repository or multiple repositories or directly controlled by the main system). Such a determination may be straightforward or may require careful analysis of the manipulation request. For example, the analysis may include a check of affected data and whether to let the data pass through or be intercepted; a check of the data manipulation type and make a decision as to how to treat the manipulation request based on the type. These can be viewed as a sequence of conditions and actions within an overall protocol where these checks can be, for example, conditions followed by actions and/or workflows. This is further detailed in U.S. application Ser. No. 11/024,160, filed on Dec. 27, 2004, entitled POLICIES AS WORKFLOWS, and U.S. application Ser. No. 11/565,578, filed on Nov. 30, 2006, entitled ADDING FACTORED OUT FLOWS IN DECLARATIVE POLICY RULE SETS, which are incorporated by reference for any and all purposes. The method may further include analyzing the request to determine a data type associated with the manipulation request and, based on the data type, selecting a policy from a plurality of policies.

Additionally, an alternative aspect of the invention includes the situation for which when data is requested, in general, the location of the requested data is not known at the time the request is made. The requester is simply instructed as to the schema that the requester is able to access. However, in some cases, the requester may have additional information and may actually know the location of the data. In such cases, it is possible for the requester to be able to make a request through a common interface but also to specify which data is to be mapped to what file (i.e., what is the schema the requester expects to use and how the requester desires to see the data mapped from the original data that are aggregated and/or federated data).

Furthermore, the method may process (i.e., evaluation and/or enforce) the selected policy. The policy may be configured to direct the policy enforcer to allow the manipulation request to pass through to the associated destination data system to process the request, delegate processing of the manipulation request to at least one of a plurality of data systems, or process the manipulation request by the policy enforcer. In addition, the policy may be used to delegate the manipulation request to the owner(s) of the data, and initiate other possible workflows which are associated as processes across multiple systems/application (i.e., OSS/BSS, etc.).

In an alternative embodiment, when the data is requested in general, the requesting system will not know where the data is located. The system is simply aware of the schema which the system is able to access. However, in some cases the system may actually be aware of the data and where the data is located. In such cases, it is possible that the system is able to make a request through, for example, a common interface and also specify which data is to be mapped to what file (i.e., what is the schema the system expects to use and does the system want to see the schema mapped from the original data that is aggregated.

According to a further embodiment, a system for implementing service level consolidated user information management is described. The system may include a plurality of data systems, an aggregator/federator that aggregates/federates (virtually or otherwise) the data sources and provides a) managed identities and b) aggregation/federation of the data schemas. As such, a) and b) include data mapping that may be completed by an administrator at installation, at run time, or that may be exposed and controlled programmatically via interfaces. The system may further include a policy enforcer coupled with the plurality of data systems. The policy enforcer may be configured to receive/intercept any data manipulation request. The manipulation request may include an associated destination data system from the plurality of data systems. In an alternative embodiment, the storage location of the data is unknown to the policy enforcer and only the type of data from an aggregated view which the policy enforcer will desire to see. The mapping of the aggregation/federation then allows for a determination of the source of the data repository (or repositories) which are involved. The policy enforcer may further analyze the request to determine the content of the data, the location of the data, the construction of the request, etc. associated with the manipulation. Based on this information, a policy is selected from a plurality of policies and the selected policy is executed. The policy may be configured to direct the policy enforcer to allow the manipulation request to pass through to the associated destination data system to process the request, delegate processing of the manipulation request to at least one of the plurality of data systems, or process the manipulation request by the policy enforcer.

Furthermore, when generating a request to the consolidated profile which aggregates data, the schema may have been previously set up (e.g., via administration or configuration) or for a particular request may pass a description of the expected schema, mapping rules, aggregation rules, etc. (e.g., retrieve certain data from one address and other data from another address, and perform certain actions on the data, etc.). This may also be modeled as mapping policies (i.e., any combination of any condition and any action) to be used for the aggregation so that at the time of the request the required mappings are determined by the details passed in the request.

DETAILED DESCRIPTION OF THE INVENTION

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks.

Embodiments of the invention provide systems and methods for implementing service level consolidated user information management. More specifically, embodiments of the present invention provide for manipulating user data and data dependencies using a consolidated management and/or data access system. Alternatively, a common interface and schema and/or aggregation/federation of data across multiple sources with identify management (and federation) may be implemented to map data based on aggregated schema and identity management. Further aspects of the present invention include an enabler which exposes through, for example, a northbound interface the schema/data independently from a database with or without aggregation. Particularly, in addition to providing aggregated/federated views and aggregated/federated identities and a common interface, a policy enforcer may be configured to receive/intercept data manipulation requests. The policy enforcer may then, based on the request and the content of the data, the location of the data, and the construction of the request, etc. associated with the request, select an appropriate policy to apply. Furthermore, based on the selected policy, the policy enforcer may either process the request itself, delegate the processing of the request to another data system (e.g., OSS/BSS, a billing system, a subscription system, etc.), or allow the request to pass through to the destination data system (which typically may then own the data or the database that is targeted/aggregated may also trigger processes when data is changed or requests are made). Hence, the policy enforcer may act as an “orchestrator” which manages data manipulation requests in order to ensure that a single entity is directing the management of the data. As such, the data is always correctly synchronized and data dependencies are properly maintained. Various additional details of embodiments of the present invention will be described below with reference to the figures.

FIG. 1is a block diagram illustrating components of an exemplary operating environment in which various embodiments of the present invention may be implemented. The system100can include one or more user computers105,110, which may be used to operate a client, whether a dedicated application, web browser, etc. The user computers105,110can be general purpose personal computers (including, merely by way of example, personal computers and/or laptop computers running various versions of Microsoft® Corp.'s Windows® and/or Apple Corp.'s Macintosh® operating systems) and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation, the variety of GNU/Linux operating systems). These user computers105,110may also have any of a variety of applications, including one or more development systems, database client and/or server applications, and web browser applications. Alternatively, the user computers105,110may be any other electronic device, such as a thin-client computer, Internet-enabled mobile telephone, and/or personal digital assistant, capable of communicating via a network (e.g., the network115described below) and/or displaying and navigating web pages or other types of electronic documents. Although the exemplary system100is shown with two user computers, any number of user computers may be supported.

The system100may also include one or more server computers120,125,130which can be general purpose computers and/or specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.), personal digital assistants (PDAs), and other such computing devices. One or more of the servers (e.g.,130) may be dedicated to running applications, such as a business application, a web server, application server, etc. Such servers may be used to process requests from user computers105,110. The applications can also include any number of applications for controlling access to resources of the servers120,125,130.

In some embodiments, an application server may create web pages dynamically for displaying on an end-user (client) system. The web pages created by the web application server may be forwarded to a user computer105via a web server. Similarly, the web server can receive web page requests and/or input data from a user computer105,110and can forward the web page requests and/or input data to an application and/or a database server. Those skilled in the art will recognize that the functions described with respect to various types of servers may be performed by a single server and/or a plurality of specialized servers, depending on implementation-specific needs and parameters.

The system100may also include one or more databases135. The database(s)135may reside in a variety of locations. By way of example, a database135may reside on a storage medium local to (and/or resident in) one or more of the computers105,110,120,125,130. Alternatively, it may be remote from any or all of the computers105,110,120,125,130, and/or in communication (e.g., via the network115) with one or more of these. In a particular set of embodiments, the database135may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers105,110,120,125,130may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database135may be a relational database, such as Oracle® 10g, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 2illustrates an exemplary computer system200, in which various embodiments of the present invention may be implemented. The system200may be used to implement any of the computer systems described above. The computer system200is shown comprising hardware elements that may be electrically coupled via a bus255. The hardware elements may include one or more central processing units (CPUs)205, one or more input devices210(e.g., a mouse, a keyboard, etc.), and one or more output devices215(e.g., a display device, a printer, etc.). The computer system200may also include one or more storage device220. By way of example, storage device(s)220may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like.

The computer system200may additionally include a computer-readable storage media reader225a, a communications system230(e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory240, which may include RAM and ROM devices as described above. In some embodiments, the computer system200may also include a processing acceleration unit235, which can include a DSP, a special-purpose processor and/or the like.

The computer-readable storage media reader225acan further be connected to a computer-readable storage medium225b, together (and, optionally, in combination with storage device(s)220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system230may permit data to be exchanged with the network115(FIG. 1) and/or any other computer described above with respect to the system200.

The computer system200may also comprise software elements, shown as being currently located within a working memory240, including an operating system245and/or other code250, such as an application program (which may be a client application, web browser, mid-tier application, RDBMS, etc.). It should be appreciated that alternate embodiments of a computer system200may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. Software of computer system200may include code250for implementing embodiments of the present invention as described herein.

The present invention relates to the systems and methods described in U.S. patent Ser. No. 12/019,299, filed on Jan. 24, 2008, entitled “SERVICE-ORIENTED ARCHITECTURE (SOA) MANAGEMENT OF DATA REPOSITORY,”, which is hereby incorporated herein by reference, which is summarized inFIGS. 3(a) and3(b).FIG. 3(a) describes an application302which can issue a command to create a new account in a unified user profile (UUP)304. Instead of updating the appropriate repository, however, the UUP component304causes a workflow to be launched (may be a single action such as a data manipulation action if needed) which may consist of one or more business processes which interact with the OSS/BSS306to initiate an update to the OSS/BSS-owned repository (or repositories). Once the OSS/BSS repository is updated, the UUP continues such that the resulting updates in the OSS/BSS repository are reflected in the data hub308and UUP304(or any other repository that may be visible/aggregated by the UUP). The UUP is a virtual view of other data repositories such that, when data is updated, the view by default is also updated, alternatively the data is synchronized/replicated from the repository. In such a situation, automation of the process between OSS/BSS repositories and the UUP occurs. However, if this is not well automated, then the workflows may be responsible for triggering the replications in order to make sure the changes are correctly reflected in the UUP. The end result seen by the application is the same, but any corresponding actions are taken care of by the workflow.FIG. 3(b) illustrates another exemplary flow350wherein the UUP304component updates the data in a database component with SOA data management capabilities352, wherein the database component itself is able to trigger (possibly before the update or as a result of an update) a workflow that creates a business process which interacts with the OSS/BSS306.

It is always possible that an update operation might fail. For example, a requester may wish to create an account for a user and, if the system simply used SQL to create the appropriate records, then the account would be created. When using a workflow, however, it is possible that the customer information first would be directed to a financial system wherein the customer might fail a credit check, for example, which would cause the customer to not qualify for the selected service. In such a case, the account will not be created in the database. In one embodiment, a failure is expected to result in the UUP304returning an error message to the requestor through the requestor's interface, just as a success answer can also be similarly returned if all requests are completed as expected. Accordingly, these actions could then result in a remedial flow or flows which revert the previous actions.

In one example, the creation of an account triggers updates in rating and billing information for the account, as well as a list of support data, etc. There can also be an updating of data not seen in the SDP and typically not known by the applications. There may be assets that are not aggregated in the UUP304, which can be a valid choice for a particular operator. The new service may result in the shipping of a new phone, modem, or set-top box, for example. The service can also be reflected in another repository, which would not have been updated if the change had been done straight to the repository without the flows. In another example, a user phone or modem must be delivered, provisioned and/or service activated when the subscriber adds a subscription, which is the result of a flow that would not have occurred if the data were simply updated directly.

The service level user profile can rely on the UUP304to provide an identity managed virtual view of all data about principals or customers encountered in a service provider (SP) domain and used in the service layer. A SDP is an example of a platform for the service layer (i.e., for development, deployment, execution, and management), thus the User profile is expected to be used to access all of the information needed in the service layer (but not all encountered in the service layer). Hence, because applications should not be restricted as to actions they can perform, all information that a SP has about users, subscribers, principals, etc. is made available. This information can include, for example, credentials, BSS/Subscriptions (including the data hub and subscription management), service/application specific data, security data, preferences and usage patterns, network information (e.g., HSS), dynamic information (e.g., presence and location information), OMA XDM profiles, and OMA GSSM information when available, for subscribers, users, customers, third parties, or any other appropriate parties. In other words, any appropriate principals.

In a further embodiment, UUP304may be used, for example, to abstract a database with an interface, to connect to the database via an adapter, to map a schema, to manage an identity, and to aggregate across a number of repositories. UUP304may further be used to expose profile/versions of profiles in a service layer and to use user profiles based on the service layer. The profiles may be optimized with various alternatives. Furthermore, policies may control data manipulation and affect workflow before, during, and after data change requests are received, passed to the repositories, etc.

The data management of the virtual directory or unified repository can be controlled (if necessary and depending on setup, policies, the data, and the request) so that an operation on some or all of the data is not performed as a simple data management operation. However, instead it converted into at least one request that is passed to another system(s) that will act on the request in ways that should ultimately similarly affect the data, but may affect other data or the context for the data.

The UUP304utilizes the managed/federated identity to provide an identity managed and federated virtual view of all data about principals or customers encountered in a service provider domain and used in the service layer. This information can include in association with the same identity aggregated data that were associated to different identities (possibly in different identity systems) from where the data is located, for example, credentials, BSS/Subscriptions (including a data hub and subscription management), service/application specific data, security data, preferences and usage patterns, network information (e.g., HSS), dynamic information (e.g., presence and location information), OMA XDM profiles, and OMA GSSM information (when available) for subscribers, users, customers, third parties, and/or any other appropriate parties.

The data management of a virtual directory (i.e., one way to implement the aggregated view aspect of the UUP304) can be controlled so that an operation on some or all of the data is not performed as a simple data management operation, but instead is converted into at least one request that is passed to another system(s) that will act on the request in ways that should ultimately similarly affect the data, but may affect other data or the context for the data. Information about principals or customers encountered in the SDP can include, for example, credentials, BSS/Subscriptions (including the data hub and subscription management), service specific data, network information (e.g., HSS), dynamic information (e.g., presence and location information), OMA XDM profiles, and OMA GSSM information when available, for subscribers, users, customers, third parties, or any other appropriate parties. Alternatively, this may not be accomplished by the UUP304but instead delegated to a target repository which can then be seen as a UUP304to some extent.

Additionally, UUP304may provide various applications in the SDP with concurrent network access to various directories and repositories/database management systems across the domain. Concurrent access can be provided via various methods, such as by using Identity Management (IdM), Lightweight Directory Access Protocol (LDAP v3), Directory Services Markup Language (DSML v2), and Diameter Sh and Cx. The UUP304can include a highly extensible user profile with support for application-specific dynamic user views and can provide support for Home Subscriber Server (HSS) and Subscription Location Function (SLF) functionality. The user profile data can be managed using any appropriate data management system, such as the Oracle® RDBMS server available from Oracle Corporation of Redwood Shores, Calif.

Turning now toFIG. 4which is a block diagram illustrating, at a high-level, functional components of a system for implementing service level consolidated user information management according to one embodiment of the present invention. In this example, the system400includes a policy enforcer405. In one embodiment, policy enforcer405may be configured to intercept manipulation requests (i.e., adding a new field, removing an entry, changing a value, etc.) of data from a subscription/profile management requester420or a policy management requester425via UUP304.

Alternatively, system400may include an additional policy enforcer located outside of UUP304. In one embodiment, the additional policy enforcer may be configured to apply for service provider policies on how capabilities are exposed to an application (e.g., security, changing values, logging, etc.).

Policy enforcer405may act as an orchestrator (or central processing hub) which routes all data manipulation requests received from requesting systems (i.e., subscription/profile management requester420, policy management requester425, etc.). In one embodiment, policy enforcer405is able to ensure that each manipulation request is handled by an appropriate data system (e.g., OSS, BSS, etc.), that proper data synchronization and data dependencies are maintained, and that data manipulation management is controlled in a consolidated manner by a single entity.

In one embodiment, policy enforcer405may be coupled with a policies database440. As used herein, the term policy may refer to a combination of one or more conditions and a set of one or more associated actions to be performed upon the condition(s) being satisfied. That is, the policies can define conditions to be met and corresponding actions to be taken when receiving a publication of a presence attribute, notifying subscribers/listeners, responding to queries, etc. For example, the policies can define which subscribers or listeners are authorized to receive a notification or access a profile or attribute. Additionally or alternatively, the policies can define conditions and actions for use by the service to determine what information is shown to whom, how is the information transformed, under what conditions, etc. Other possible policies, i.e., any combination of any condition and any action, are contemplated and considered to be within the scope of the present invention. According to one embodiment, application of policies and handling of events can be performed as described in U.S. patent application Ser. No. 11/424,451 filed Jun. 15, 2006 by Maes and entitled “PAST PRESENCE HINTS”, the entire disclosure of which is incorporated herein by reference for all purposes. That is, application of policies and handling of events can be based on current events and/or information as well as past events and/or information.

Upon receiving a manipulation request, policy enforcer405may analyze the request to determine the appropriate policy to apply to the request. As described above, the policy may provide policy enforcer405with instructions on how to manage the various requests. For example, some requests may deal with manipulating data with access which is restricted only to the owner of the data. As such, based on the appropriate policy instructions, policy enforcer405would need to instruct the data's owner to perform the data manipulation. Conversely, certain data may be able to be accessed by multiple data systems (which may or may not own the data).

In this situation, the policy may instruct policy enforcer405to delegate execution of the request or to execute the request itself. Hence, policy enforcer405, based on the selected policy, can effectively route requests to the appropriate data systems in order to effectively process the requests.

In one embodiment, the data systems in which the request may be routed are interfaces of the UUP304which expose subscriber manager410or profile manager415functions and/or capabilities. In an alternative embodiment, subscriber manager410and profile manager415are interfaces (or enablers) which are configured to provide dedicated functions. One difference between subscriber manager410and profile manager415and UUP304is that subscriber manager410allows access to subscription information with subscription management operations such as, for example, being able to subscribe to a service, is a user subscribed, what service is the user subscribed to, what are the conditions for using the subscription, what are the rates, etc. Similarly, profile manager415allows access to user profile information such as the profile type, information regarding the user's identity, the user preferences for a service, the user's history, etc. Hence, subscriber manager410and profile manager415are provided with higher level primitives than simply the basic “data access or manipulations” that are exposed more or less directly through the UUP304interfaces. Accordingly, subscriber manager410and profile manager415can be built on top of UUP304as a higher-level construct that consists of one or multiple manipulations of data through UUP304.

Subscriber manager410may “own” the data contained in subscription data database430, and profile manager415may “own” the data contained in profile data database435. In other words, any requests may pass directly to subscriber manager410and profile manager415; alternatively, UUP304may also “own” the data. Accordingly, merely by way of example, subscriber management requester420initiates a data manipulation request to change a customer's contact information. The contact information may be stored in subscription data database430and the contact information may be accessed by either policy enforcer405or subscriber manager410. In one embodiment, policy enforcer405may check a requester to determine if the requester is authorized to access the data within the request. Examples of policy enforcer405may be found in U.S. application Ser. No. 10/855,999, filed on May 28, 2004, entitled METHOD AND APPARATUS FOR SUPPORTING SERVICE ENABLERS VIA SERVICE REQUEST HANDHOLDING, U.S. application Ser. No. 10/856,588, filed on May 28, 2004, entitled METHOD AND APPARATUS FOR SUPPORTING SERVICE ENABLERS VIA SERVICE REQUEST COMPOSITION, and U.S. application Ser. No. 11/357,653, filed on Feb. 16, 2006, entitled FACTORIZATION OF CONCERNS TO BUILD A SDP (SERVICE DELIVERY PLATFORM), which are incorporated by reference in their entirety for any and all purposes. As such, based on the policy which policy enforcer405employs, policy enforcer405may allow the request to execute the subscription management or profile management, or policy enforcer405will allow the request to pass to the repository (i.e., UUP304). The policies are used by policy enforcer405to decide which requests policy enforcer405executes/allows to pass through after intercepting the request, as well as executing, enforcing, processing, etc. of the policies.

Alternatively, if, for example, the customer's contract information is restricted to only be accessed by the owner of the data (i.e., subscriber manager410), then policy enforcer405would instruct subscriber manager410to execute the request. Additionally, if the customer's contract information included a data dependency with data stored in, for example, profile data database435(e.g., the change to the customer's contact information caused a change to the customer's profile as well), then policy enforcer405would need to execute a subsequent data manipulation request to change the dependent customer profile. Similarly, based on the policy employed, policy enforcer405would either directly execute the change to the profile data or may instruct profile manager415to perform the change.

In a further embodiment, policy manager405may provide an interface for changing existing policies as well as adding new policies (i.e., to manage policies440). For example, the interface may access policy database440and present policy management requester425with details about the various policies. As such, policy management requester425may request changes to the policies or may provide information about a new policy. For example, a policy's conditions and/or associated actions may be changed or removed, as well as the data types and/or request types associated with each of the polices.

Furthermore, policy enforcer405may provide a unified interface for all data contained in, for example, databases430and435. In one embodiment, the unified interface may be a service level interface. In a further embodiment, the interface may include “Northbound” interfaces (e.g., Java™, SOAP/HTTP, LDAP, Diameter (Sh/Dh), Diameter (Cx/Dx), OMA GSSM, XCAP (OMA XDM profile enabler)) and “Southbound” protocols (e.g., LDAP, XCAP, JDBC, Diameter (Sh/Dh), Diameter (Cx/Dx), HSS, SLS, MAP (HLR) and FW to adapt to dynamic resources such as enablers, NW resources, and applications) as well as any customer repositories and applications that expose/control the interface. The source can include various IMS profiles (schemas (TS 23.008) and schema extensibility), TMF SID/customer data model support (for both northbound and southbound), subscriber management features (e.g. as applications) including integration with, for example, OSS/BSS306(FIGS. 3(a) and3(b)). These can then be mapped adequately using either information passed with the request (that indicates how to map, what identity management/federation to use, and how to map any attributes); in general, the information is pre-defined by, for example, a vendor at setup or configured by an administration task, interface, console, etc.

In an alternative embodiment, aspects of the present invention may be used to provide a common interface to any data repository. For example, in the case of data aggregation, the data is not actually aggregated, but instead each individual database is separately maintained and the common interface exposes the individual database in one common interface. Accordingly, the present invention is configured similar to an enabler which abstracts repository details with possible identity, management, federation, mappings, etc.

Referring now toFIG. 5which is a block diagram further illustrating, at a high-level, functional components of a system for implementing service level consolidated user information management according to another embodiment of the present invention. In this example, the system500includes the integration of OSS/BSS306(or generally the data owner) to system400. As can be seen in system500, policy enforcer405may interact directly with either subscriber manager410or profile manager415, or alternatively may indirectly interact with subscriber manager410or profile manager415through OSS/BSS306. Accordingly, the request goes to the one of the management interfaces and accesses the data that arrives for subscriber manager410, UUP304, or profile manager415, if policy enforcer405allowed the request to pass through. The request is sent (or the request triggers flows to data owners (e.g. OSS, BSS)). Both situations can coexist (i.e., some requests change the data and some requests allow the repositories themselves to behave the same and trigger flows). When the data owner determines some data changes should take place, the data owner may directly make the change to the repositories or the owners may also use UUP304or higher level APIs to execute the changes.

In one embodiment, policy enforcer405may delegate execution of the manipulation request to OSS/BSS306. Subsequently, OSS/BSS306may then instruct subscriber manager410or profile manager415to perform the changes associated with the manipulation request. In one embodiment, policy enforcer405may delegate to OSS/BSS306, because OSS/BSS306is the data owner which should perform the changes that results in policy enforcer405delegating to OSS/BSS306based on the policies indicating as such. Alternatively, OSS/BSS306may be aware of data dependencies and other data correlations of which UUP304is not aware. Furthermore, OSS/BSS306may also be better equipped to handle the particular data manipulation request. Nonetheless, whatever the reason for delegating execution of the request to OSS/BSS306, policy enforcer405is configured to manage all of the incoming requests and appropriately route the requests.

Turning now toFIG. 6which is a block diagram further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention. In this example, UUP304(FIGS. 3(a) and3(b)) is removed and aggregated into subscriber manager/UUP605and profile manager/UUP610. As such, subscriber manager/UUP605and profile manager/UUP610control data flow to subscription data430and profile data435, respectively. Policy enforcer405passes data to subscription data430and profile data435repositories, to the repositories' higher level abstractions, or to the data owner (e.g., OSS/BSS306).FIG. 6further includes other resources615which may be used for delegation and/or policy enforcement. In a further embodiment, subscription inquiry requester615is configured to process subscription inqueries.

Turning now toFIG. 7which is a block diagram further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention.FIG. 7removes subscriber manager/UUP605and profile manager/UUP610, as shown inFIG. 6, in order to provide OSS/BSS306with direct access to subscription data430and profile data345repositories.

Turning now toFIGS. 8 and 9which are block diagrams further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention.FIGS. 8 and 9remove subscription data430and profile data435, respectively. In one embodiment, profile data435and subscription data430may be the same or similar and, as such, removing one or the other does not affect the functionality of system500.

Turning now toFIGS. 10,11,12, and13which are block diagrams further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention.FIGS. 10,11,12, and13adds UUP304to abstract one or multiple repositories (i.e., subscription data430, profile data435, policies440, or other resources615). Such a configuration simplifies system500by factoring out of policies data aggravation/federation, mapping, and identity management/federation. Specifically, inFIG. 13, OSS/BSS306is added to provide data driven synchronization. OSS/BSS306may manage data and the data may update OSS/BSS306via SOA database management.

Turning now toFIGS. 14 and 15which are block diagrams further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention. Alternatively, instead of updating applications (i.e., OSS/BSS306), a network subscription management system (SUM)1405may be updated. Network SUM1405is then responsible for synchronizing the OSS/BSS306and, by implication, the data. Furthermore,FIG. 15may include a SOA1505as opposed to a policy enforcer405(FIG. 14).

Turning now toFIG. 16which is a block diagram further illustrating, at a high-level, functional components of a system500(FIG. 5) for implementing service level consolidated user information management according to another embodiment of the present invention. In one embodiment, Subscription/Profile Management Requester420is configured to read and/or write to profile1615in response to any complex request. Further, subscription details requester1605is configured to read from profile1615in response to a simple schema request. In addition, requester of subscription validation1610provides a “yes” or a “no” to profile1615for service and attribute requests.

FIG. 17is a flowchart illustrating a process for implementing service level consolidated user information management according to one embodiment of the present invention. In this example, processing begins with a policy enforcer (i.e., policy enforcer405(FIGS. 4 and 5)) intercepting a data manipulation request (process block1705). The request may be to make changes to, for example, a user profile, user information, user subscription information, user preferences, etc. Furthermore, the request may include a destination data system or associated data system which “owns” the data.

At process block1710, the request may be analyzed to determine the content of the data, the location of the data, the construction of the request, etc. associated with the request as well as the owner of the data. For example, the data may be customer profile information and the owner of the data may be a profile manager. Accordingly, based on the type and owner of the data, an appropriate policy may be selected to be used by the policy enforcer for the request (process block1715). In one embodiment, the policy may be selected from multiple policies stored in a policy database. The policies may also be updated and/or modified, or new policies may be added to the policy database.

As discussed above, policies include a number of conditions and commands which instruct the policy enforcer as to how to handle various data manipulation requests. Hence, at process block1720, the selected policy may be analyzed to determine how the policy enforcer is to handle the received request. In one embodiment, the policy may provide the policy enforcer with routing instructions. For example, the policy may instruct the policy enforcer to directly handle the request itself, to pass the request through the UUP304(FIGS. 3(a) and3(b)) or higher level APIs, or to delegate processing of the request to the owner of the data (e.g., to another data system, application, set of processes (e.g., OSS/BSS306(FIGS. 3(a) and3(b))), etc.). Thus, the policy enforcer405(FIGS. 4 and 5)orchestrates and manages the routing of all of the requests.

Accordingly, at decision block1725, it may be determined whether the policy enforcer is to allow the request to pass through to the owner of the data. If it is determined that the owner of the data is to process the request, then at process block1730, the request may be forwarded to the owner of the data by the policy enforcer. Subsequently, the manipulation request may then be processed and the data changed (process block1750).

Alternatively, if it is determined that the request is not to be allowed to pass through to the data owner, then it is determined whether the request is to be delegated to a data system (decision block1735). Hence, if it is determined that the manipulation request is to be delegated to a data system, then the request is forwarded to the selected data system to handle the request (process block1740). Then, the request is processed by the selected data system (process block1750).

However, if it is determined that the request is not to be delegated to a data system, then it is determined that the UUP304(FIGS. 3(a) and3(b)) (or other higher level entity) is to handle the request directly (process block1745). As such, the policy enforcer405(FIGS. 4 and 5)can proceed to access the data and make the requested change (process block1750). Accordingly, the policy enforcer is able to direct all requests to manipulate data, and data synchronization and consistency is able to be effectively maintained by a centralized entity.