Patent Application
20150019547
Over the last decade or so, more and more people have become subscribers of various types of services that are provided over the communication network. Often, a single network subscriber would purchase and enroll in multiple network services. Typically, service providers store user information in various types of database systems. For example, a mobile subscriber may be subscribed to both voice and cellular services offered by different mobile operators, and user profile information related to the voice and cellular services are stored at the separate database servers of the respective mobile operators. To retrieve user profile information, it is often necessary to access multiple databases where the user profiles are stored.
The present disclosure is related in general to data management. Information for a single user that is stored by different entities is gathered and unified to create a unified user profile. The unified user profile is stored and can be search, displayed, and/or otherwise used. There are other embodiments as well.
As explained above, existing solutions for storing user profiles, where a single user may have multiple profiles, typically involve storing different profiles of that single user at different databases. Consequently, to access these user profiles, it becomes necessary to individually access each of the databases where the user profiles are stored. In addition, since different databases may have different interfaces (e.g., different API's) and different database models, accessing these databases can be difficult.
Therefore, it is to be appreciated that the present disclosure describes various methods and systems for providing unified user profiles. More specifically, a Virtual Identity and Profile Broker (VIPB) is provided to create virtual views of unified user profiles. The VIPB can provide different virtual views and their mappings to various target systems. A virtual view can be a hierarchical tree structure in XML format that represents the unified user profile. By providing unified views of user profiles in the XML format, searching user profiles becomes independent of specific or custom user data models or search term syntaxes that may be required by various databases. Based on the needs, the VIPB can provide different virtual views of user profiles.
As an example, the term “VIPB” refers to a type of content management solutions (CMS) that create views of subscriber data that are mapped from multiple underlying subscriber data sources. A VIPB system can be implemented using one or more network servers and/or other entities. A virtual view can be a single XML document representing all the data of a single subscriber in the different repositories. The VIPB can be configured to perform data federation or brokering it in real-time. It can also store the assembled data tree of information for a user in an in-memory data grid. An auto-refresh process can be used to periodically trigger the VIPB to construct unified user profiles for a list of user identifiers. As the unified user profiles are collected into a cache memory, a database, and/or other types of storage, they can be indexed based on the access points (e.g. XPATH) as key and/or various attribute values that are stored in the unified profiles. For example, the indices of unified user profiles allow structured searches (e.g., using XPATH) and unstructured searches (e.g., using text).
It is to be appreciated that the methods and systems described in the present disclosure provide and manage a single view of personal, contextual, and behavioral information about a subscriber to support, thereby enhancing subscriber experiences and behaviors and promoting service providers' business interests. As an example, a unified user profile (UUP) is based on a simple premise: management of the relationship to, the experience of, and the interactions with a subscriber can be better achieved if a unified view of the subscriber and his/her information (e.g., environment, interests, devices, activities, etc.) is available to the operator and/or developer in real time.
Depending on the application, the unified user profile system 100 may obtain user profiles from the profile sources in various ways. For example, the unified user profile system 100 may periodically collect user profiles from the profile sources and keeps the profiles updated. The unified user profile system 100 can also obtain user profiles from the profile sources in response to requests received from the client 107. As explained above, the unified user profile system 100 analyzes user profiles obtained from the profile sources, and multiple user profiles that are retrieved from different profile sources but related to the same user are unified into a unified user profiles. The unified user profile system 100 can generate unified user profiles in XML format, which allows for unstructured search and other ways to access. The unified user profile system 100 is connected to the network repository 105, which can be used to store unified user profiles. For example, the network repository 105 can be a webrepository, a database, an IT repository, a network repository, or others. The unified user profile system 100 as show is connected to an analytics system 106. The analytics system 106, which is described below, can performed various functions, which include consolidating user profiles, enriching user profiles with additional information, and linking user profiles to various database and services.
In addition, the memory 205 includes instructions for consolidating user profiles to provide unified user profiles. Once generated, unified user profiles can be stored at the memory 205 and/or external memory or database. The user interface 204 provides a way for users to access the unified user profile system 100. The user interface 204 may include a display and/or input devices such as a keyboard, mouse, touch screen, motion sensors, and/or others. For example, through the user interface 204, an operator can view the unified user profiles and/or make changes. In addition to providing unified user profiles, the unified user profile system 100 can also provide search results and/or other information. For example, the unified user profile system 100 receives a search request through the network communication interface 201, and in response the processor 203 processes the search request, accesses the unified user profiles, and generates search results.
The synchronization 210 function is performed for provisioning, distributing, and synchronizing user profile data. For example, these processes can be activated by service requests and/or predetermined schedules. The customization 211 function is for customizing and configuring various controls, such as profile sources to be accessed, interval between synchronization processes, information to be collected from user profiles, and/or control parameters. The caching 212 function provides storage and/or replication of user profiles and other types of data. For example, the caching 212 function is implemented using a memory. The security 213 function sets access and security policies. When a user or a network entity accesses the unified user profile system 100, the security functions determines what level of access that user or network entity would have. For example, a unified user profile may have information that belongs to different access levels, and based on security and access policies set by the security 213 function. In addition, the security 213 function may perform authentication. The access interface 214 function provides interface between the unified user profile system 100 and other entities, such as profile sources and/or entities that need to access unified user profiles. For example, the access interface 214 function is implemented with communication interfaces that communicate with various network entities. The abstraction and data modeling 215 function analyzes the user profiles obtained from various profile sources, and based on a predetermined data model, retrieves information contained in the user profiles and generates unified profiles. For example, the abstraction and data modeling can be based on various criteria, such as profile source, name, age, purchase history, and/or others. The persistent subscriber data storage 216 function provides storage fur user profile information, and the storage can be for both unified user profiles generated by the unified user profile system 100 and user profiles obtained from various profile sources. For example, the persistent subscriber data storage 216 function is implemented using one or more storage devices, such as hard disk, solid state memory, optical disc, and/or others.
In a use scenario, a subscriber has a mobile profile stored at a mobile subscriber database and a cable television profile stored at a cable subscriber database. The mobile subscriber database and the cable subscriber database can be separate entities, and even operated by different operators. The unified user profile system 100, through its communication interfaces and with the help of the access interfacing 214 function, accesses the mobile subscriber database and the cable subscriber database to obtain the cable television profile and mobile profile. Using the predetermined criteria implemented through the abstraction and data modeling 215 function, the unified user profile system 100 generates a unified user profile for the subscriber. Depending on the application, the unified user profile can be stored in various formats, such as the XML format, which allows for unstructured searches. The unified user profile contains different levels of information, and the access of which is determined by the security 213 function. For example, the security 213 function generates an access policy for the unified user profiles, where at different access levels, different types of information stored at the unified user profile may or may not be available for access. Through the access interfacing 214 function, a searching entity may send search request to the unified user profile system 100 for mobile subscribers with certain usage patterns. Upon determining that the searching entity has the access credentials and that the subscriber meets the search criteria, the unified user profile system 100 provides the unified user profile in a unified view to the searching entity. In addition, the unified user profile system 100 may also perform analytics to help the searching entity better understand information provided in the unified user profile.
To make unified user profile data usable and assessable, adaptive formats can be used. For example, adaptive formats such as XML and LDAP formats are supported in the federation layer. Data presented to applications are abstracted. Being dissociated from physical storage location, structure, access protocol, and identity, abstract data make it possible for applications to approach the UUP with a known identity via an XML or LDAP request, and that identity is translated to every other identity and protocol needed to get the data. For example, the UUP system is capable of communicating using many different types of communication protocols.
The unified user profile system also provides an identity aliasing feature that enables an application to use the identity it knows the subscriber as, even though multiple identities may be required to access data across different sources where subscriber profiles are stored.
The federation can be configured to support “virtual” data models, which is to overcome the issues that may be caused by trying to create a monolithic data model. This means that any set or subset of data can be presented to any application, or group of applications, independent of all other applications and groups. Since data models can be created and evolved independently, each application initiative could even have its own data model. This is useful in limiting the access of external developers to only those elements of the data model the operator wishes that application to see, which provides a security benefit.
Fine-grained Access Control Lists (ACL) system is used to provide release control down to the by-element, by-requestor, by target subscriber level, which is consistent with the emerging OMA Global Permissions Manager standard. In addition to this security, group-level controls can also be supported, both for user-defined groups (e.g., membership and privileges) and global operator groups.
The UUP can have a multi-level cache capability, with caches at the federation as well as the data repository levels. Caching at the federation layer enables repeatability and consistency with regard to high performance, and it provides sophisticated control mechanisms to enable search requestors to use data within, or beyond, its time to live, to force a cache refresh for given elements or sources, and the like.
The data management layer provides central provisioning, control, and management of persistent data, thereby enabling the creation of a master repository or a central cache. Data replication capabilities from the data management layer enable central provisioning and support master data management initiatives.
In addition, the UUP can provide data transformation between the virtual view and the physical layer, both outbound and inbound. Data transformation can be used for lowering the resolution of a location, depending on who made the request (outbound). Data transformation can also be sued for data encryption (both inbound and outbound).
Depending on the application, the virtual unified user profiles can be configured for different viewing options. Each unified user profile can be presented as a single subscriber view. To access any of the unified user profile, a single point of access is provided through the VIPB 603. The unified user profiles can be stored in a common data model, which allows for unified and convenient methods of access. The access policies provide privacy control that prevents unauthorized access to user profile information. Based on the viewing needs, virtual views for unified user profiles can be modified.
Once a logical XML view is available, the VIPB provides data federation and unification, which can be a part of a CMS system. It is to be appreciated the logical XML view allows reading of any part of the unified user profile, which can be a logical data view, with any of the user's known identifier (e.g., email, MSISDN, etc). The VIPB is internally configured to map the parts of the logical data model to the different data sources using XML and XQUERY based configuration. When a read request is triggered on any part of the logical data model, the VIPB access the data model and in parallel retrieves different data required to form a unified user profile using the corresponding transformations and identifiers necessary to retrieve data from different data source, thereby fulfilling the read request. For example, if Individual/Customer/Product/Broadband is read for a user with the identifier “MSISDN 1234567890”, three data sources (e.g., CRM, Device Management, and Vertica) are read. During the read process, different identifiers may be needed to access different data sources. There can be multiple identifiers of the same type. For example, the CRM data source may need a Customer ID that is not the same as MSISDN. Internally, the VIPB provides a linkage of the different identifiers of a single user from a given identifier,
One of the benefits from aggregating and organizing user profiles into a unified user profile, which can be stored in an XML format, is user data can be accessed and search using one of many identifiers of a single user.
When an external process (or application) that triggers the access of unified user profile, for every user based on a given list of identifiers is run periodically and the federated XML profiles are cached in a time-to-live in-memory cache grid which spans clusters of nodes. Once user profiles are obtained from various profile sources, they may be stored in a cache memory for easy access. For easy access, the UUP system may index various values of the user profiles against the XPATHs of the unified XML For example, the indices can be stored in cache memory, thereby making it accessible across the different nodes.
Now referring to
When a search request is issued by a client application, the indices are used to find the match. For example, a search request that includes “find all users whose Top10 interests have Discovery Channel and whose age falls between 35 and 45 and who are Male” and “return their Mobile phone numbers”, a search function uses the indices created against the XPATH to find the matching documents that met these search terms. The client application may further narrow down the search by issuing a command that is as part of the search request to return desired attributes. For example, the client application issues a “return” command to provide the MSISDN attribute, which causes the UUP system to return all the MSISDNs of the users who matched the search criteria based on index values of their ULT. In turn, a “read” command is issued on the desired XPATHs of the ‘identifiers’ of the matched documents. Depending on the application, each of the indices can also store one of the identifiers of a user so that the index can be further used to retrieve the other information and attributes.
Table 1 provides an example of various types of search terms that can be used to at an UUP system. This table merely provides an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives.
While the above is a full description of the specific embodiments, various modifications, alternative constructions and equivalents may be used. Therefore, the above description and illustrations should not be taken as limiting the scope of the present invention which is defined by the appended claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US12/34338 | 4/20/2012 | WO | 00 | 7/8/2014 |
