HK1071453B - A method for user profile management - Google Patents

Description

Method for user profile management

RELATED APPLICATIONS

This application claims priority from U.S. application entitled "ACCESS CONTROL PROTOCOL for user Profile MANAGEMENT (Access CONTROL PROTOCOL) under serial number 09/808,919 filed on 14/3/2001, the same as the inventor of this application, the contents of which are incorporated herein by reference.

Technical Field

The present application relates generally to information processing, and more particularly, to an access control protocol for user profile (profile) management.

Background

Internet service providers and wireless service providers typically attempt to provide personalized services to users by maintaining information related to the user in a user profile. Each service provider stores data relating to each user separately, such as purchase history, personal preferences, billing information, and the like. The service provider is responsible for collecting data relating to the user and storing the data in a particular data format.

However, there are several disadvantages to this conventional approach to customizing services for a user. First, there is a great deal of repetitive labor. An independent service provider may maintain the same information for a user, such as name, address, and telephone number. This represents an inherent inefficiency and is also inconvenient for the user, as the user may be required to submit the same information to multiple service providers. Second, each service provider owns only a portion of the user's preferences (i.e., only the data collected by the service provider). Thus, each vendor can only partially personalize the services provided to the user. Third, the user typically has no control over the data stored by the service provider. In fact, most users cannot even access the collected data. Such data may be abused by unscrupulous service providers. Fourth, the data collected for a user may be incorrect or outdated because the information is not automatically propagated to all service providers; but typically only provides the correct information to a selected subset of service providers.

Disclosure of Invention

The present invention overcomes the limitations of conventional methods of acquiring and maintaining user-related data by providing an infrastructure of user profiles. According to this infrastructure, user profiles are stored and accessible through a central repository. The user profile may contain information accessible by a plurality of service providers. Because there is only one user profile per user, changes need only be made at one location to ensure that the user profile is up-to-date. The user profile may be modified by the user. The user may have full control of the user profile and may specify the information to be included in the user profile. The user may also control permissions (permissions) that specify which clients have permission to access information within the user profile. These permissions may specify the type of access provided to each client. Permission rights may be specified not only for the entire user profile, but also for various fields within the user profile.

The infrastructure includes a protocol that facilitates the creation, management and access of user profiles by customers. Customers may include service providers, system administrators, and users. Account information may be maintained for each customer.

According to a first aspect of the invention, the method is implemented in an electronic device. According to the method, a user profile is provided to store information associated with a user. A set of permissions is established for the user profile. The set of permissions specifies who may access the user profile and may also specify which type of access is authorized.

According to another aspect of the invention, a user profile is provided to maintain information related to the user. The user profile may be accessed over a network. A service provider's grouping may be defined. Each group containing a group of service providers. Access permissions are granted to a selected one of the plurality of groups to facilitate access to the information by service providers within the selected group.

According to another aspect of the invention, a user profile is provided in an electronic device that includes a plurality of fields, at least some of which have associated permissions. Permission is set for a given service provider to disable access to at least one selected field in the user profile and to authorize access to at least one selected field to support anonymous transactions (i.e., transactions that do not indicate the identity of the user) between the given service provider and the user.

The invention provides a method for user profile management, comprising the steps of:

providing a user profile that stores information related to the user;

establishing a first set of permissions for the user profile, wherein the first set of permissions specifies who may access the user profile;

establishing a second set of permissions for a selected field of the user profile, wherein the second set of permissions specifies who may access the field; and

wherein for a user to access the selected field, the user must be designated as having access to the user profile using a first set of permissions and must be designated as having access to the selected field using a second set of permissions.

The present invention also provides a method for user profile management, comprising the steps of:

providing a user profile that holds information related to a user and is accessible over a network;

defining groups of service providers for providing services to users, each group containing a group of service providers; and

access permissions to authorization information in a selected user profile are granted to a selected one of the groups so that service providers within the selected group can access the authorization information.

The present invention also provides a method for user profile management, comprising the steps of:

providing a user profile having fields, wherein at least one of said fields has associated permissions;

permission is set for a given service provider to prohibit access to at least one selected field in the user profile and to authorize access to at least one given field, thereby supporting anonymous transactions between the given service provider and the user by concealing the identity of the user.

Drawings

An exemplary embodiment of the present invention will be described below with reference to the accompanying drawings.

FIG. 1 illustrates a number of components used in an exemplary embodiment of the invention.

FIG. 2 illustrates one exemplary environment for implementing the illustrative embodiments.

Fig. 3 illustrates a number of different clients that may participate in the PMT protocol.

Fig. 4 illustrates an example of data stored in a user profile.

FIG. 5 illustrates different granularities (granularities) at which licensing rights may be added in this illustrative embodiment.

Figure 6 illustrates an example of a service provider hierarchy.

FIG. 7 is a flowchart illustrating the steps performed to generate a user profile.

FIG. 8 is a flowchart illustrating an example of steps performed in support of an anonymous exchange.

Detailed Description

An exemplary embodiment of the present invention provides a user profile access protocol with flexible access control capabilities. The protocol includes operations to obtain and set: user profile schema definitions, user profile fields, user profile access permissions (per field basis), groupings defining which user parties are granted permission, grouping access permissions, and permission access permissions (i.e., "sub-permission").

The user profile may be accessed by customers, such as administrators, users, and service providers. The user profile is specially modified for use by internet service providers and wireless service providers. The protocol provides a way to generate, modify, and access user preferences and other types of user information. The service provider may access this user profile information to customize the services provided to the customer.

The agreement specifies the interaction between a preference administrator and a single client. It is assumed that there is a communication mechanism for the request and response of the transport protocol. The client may communicate with the preference administrator over a network, such as a computer network (such as the internet) or a communication network (such as a wireless network). Typically, the protocol requires a communication path between the preference administrator and the client.

The PMT protocol controls access to each block of data within the user profile by checking the permissions associated with the data. The permissions may be associated with the entire user profile or with a field within the profile. Thus, the granularity of the license right may vary with the smallest granularity being a field. The licensing rights may be specified in groups. In practice, the licensing rights may be specified using one set algebra applied to each group. For example, a given user profile may be accessed by clients identified by the associations of both groups. A group may be defined as a list of customers (i.e., a list of account IDs, where each customer has an associated account ID) or may be defined in other groups. The use of such groups allows data sharing within groups of homogeneous service providers as well as other miscellaneous data sharing. Moreover, these groups readily accept dynamic modifications to clients that are allowed to access the user profile. For example, if a user authorizes a group of pizza sellers to access the user's phone number, the group of pizza sellers can be dynamically modified without requiring the user to update the user profile to include or exclude pizza sellers that have been added or deleted from the group. The description of the licensing rights automatically takes these changes into account.

The user profile may include service provider specific fields (i.e., customer specified patterns). For example, a pizza vendor may have a field that describes the user's favorite pizza. The user profile may also contain a number of general information such as the user's name, address and telephone number.

The protocol specifies the semantics of each communication. For example, to obtain information about a user, the emphasis of the response to the request is on the meaning of the licensing rights in this environment. The protocol describes the acquisition and retrieval of licensing rights and a description of which information is stored for each user. The protocol also describes the definition of groups and accounts. This protocol seeks to provide a powerful infrastructure while maintaining simplicity.

FIG. 1 illustrates components used in an exemplary embodiment of the invention. A PMT server 10 is provided to facilitate transactions associated with the user profiles stored within the database 14. It is assumed that the PMT server 10 is a server process running on a computer system or other intelligent electronic device. The PMT protocol 12 is supported by the PMT server 10 and transacts according to the PMT protocol. It is assumed that the clients also support PMT protocols (e.g., they can formulate the correct PMT requests). The PMT server 10 may execute an account manager 16 that maintains an account registration for customers seeking access to the data in the database 14. As described above, each account may represent a customer user, such as a service provider or system administrator. The PMT server 10 may also maintain a plurality of default licensing rights 18, with these licensing rights 18 being assigned if the user does not specify explicit licensing rights for the data within the user profile. The database 14 holds user profiles, information relating to customer (e.g., service provider) groups, and licensing rights information.

A Service Provider (SP)20 may access the data within the database 14 by communicating with the PMT server 10 using the PMT protocol 12. The data sharer device 22 facilitates the exchange of information between a repository and another system (e.g., a system maintained by a service provider) that stores certain types of personal data. An anonymous dialog enabler device 24 enables a communication dialog to be conducted anonymously using PMT protocols, as will be described in greater detail below. A secure transaction manager 26 is provided to ensure that communication between the service provider and the PMT protocol 10 is conducted in a secure manner.

User interface logic 28 may be provided to allow a user to communicate with the PMT server 10. It may be desirable for the user to be able to view the user profile and associated permissions and modify the user profile permissions. For example, the PMT server 10 may provide a web page to allow a verified and authenticated user to view and modify the user profile and associated permissions. The UI logic 28 facilitates such interaction between the user and the PMT server 10. As described above, the user may access and communicate with the PMT server 10 through a network device 32, the network device 32 communicating over the Internet or other computer network through a network user interface 34. Examples of network devices include, but are not limited to, personal computers, internet appliance devices, network computers, and other types of devices that rely on a web browser. The user may also communicate using a wireless device 30, such as a cellular telephone, Personal Digital Assistant (PDA), and smart pager, via a wireless UI 36. The wireless device 30 may be a Wireless Application Protocol (WAP) device 30 that communicates with the PMT server 10 using WAP.

FIG. 2 illustrates an example of one environment in which the illustrative embodiments may be implemented. The PMT server 10 is coupled to a network 50, such as the internet, a computer network, or a communications network. Each service provider 52 and 54 has resources coupled through network 50. A user 56 having a user profile stored in the database 14 may access the network 50. The manager 58 may have direct access to (i.e., may be directly cabled to) the server 10. The server 10 includes a preference manager 17 which is responsible for maintaining data within the user profile. The server 10 may also include an authentication mechanism for authenticating both the user and the client. In general, other support for the PMT protocol 28 may be stored and run on the server 10. The server may include a plurality of servlets (servlets) 15 that assist in execution. The database 14 includes a user profile, account information, and grouping related information.

Those skilled in the art will appreciate that there need not be only one database; conversely, multiple databases may be used, or copies of multiple databases may be provided. Also, multiple PMT servers may be provided to enhance availability, to provide load balancing and to reduce latency for transactions.

As mentioned above, the customer may take a variety of forms. Fig. 3 illustrates that a customer 16 may be a service provider 62. The service provider provides services over a network, such as a wireless network or computer network. The service provider may be an Internet Service Provider (ISP) to which users access via the internet. The client may be a user 64 or a system administrator 66.

The information within the user profile may be stored hierarchically. Those skilled in the art will appreciate that the data need not be stored in a record form, and other data types are acceptable. For example, in some instances all data is encapsulated within the target. These objects may be organized hierarchically. The data need not be hierarchical, but may be non-hierarchical.

Fig. 4 illustrates an example of a portion of the user profile table 68. The data stored within the user profile table 68 includes a user name 72, an address 74, and a telephone number 76. Information 84 for one store ("store x") may be stored in the user profile table 68. PIZZA preferences 85 for the user may also be stored within the user profile table 68. Similarly, preference 90 relating to CAFE LATTE and preference 88 relating to CAFE MOCHA (MOCHA) may be provided. Other data 91 may also be stored in the user profile table 68.

The granularity of the licensing rights that may be specified for a user is variable. The permissions may be associated with the entire user profile or with a field within the user profile. When different data structures are used, the granularity may vary to suit the particular data structure used. Fig. 5 illustrates an example of one such licensing rights. The user profile table 68 includes a name field 72, an address field 74, and a phone number field 76. Permission rights are stored for the user profile table 68 and for the telephone number field 76. The licensing rights 102 for the user profile 68 include a user i.d.104 that specifies a unique identifier for the user associated with the user profile 100. The permissions 102 also specify the account i.d. and access permissions 106 for each client or group of clients that may access the user profile. Finally, permission rights 122 are stored for telephone number field 76. One field i.d.124 uniquely identifies the phone number field 76. A list 126 of customers is provided with access to the telephone number field.

The permissions also specify the type of access granted to a client. These permissions include write access that enables the client to write and read data from the associated data unit and read access that allows the client to read data from the associated data unit but not write data. The permissions also include delete access. Delete access allows a client to delete data within the associated data unit. Availability access enables a customer to determine whether data is available. The permissions also include write access that enables the client to write the permission value.

The protocol facilitates the definition of client groups. These groups are specifically adapted for grouping service providers. These groups allow the service providers to share information and associate licensing rights with these groups rather than with individual customers.

These groups may be organized hierarchically, for example as shown in FIG. 6. Fig. 6 illustrates a hierarchy 150 of a plurality of service provider groups. The food group 152 comprises service providers within the food industry. The food industry 152 may include a pizza vendor's subgroup 154 and a fast food vendor's subgroup 156. The PIZZA vendor group 154 may include a PIZZA KING service provider 158 and a PIZZA SHACK service provider 160. Similarly, fast food group 156 may include a BURGE MEISTER service provider 162 and a JOHNNY's BURGERS service provider 164.

As described above, account information is maintained for each customer and each customer is identified by a unique account i.d. Other information, such as billing information and other related information, may be maintained for the account.

A group is either a collection of accounts or a collection algebraic (setalgebra) expression with respect to other groups. In particular, set algebra expressions use set algebra operators of union, intersection and difference sets. The groupings defined using a set algebraic expression are dynamically evaluated. If these groupings change, the values of the finally obtained expressions also change dynamically.

The protocol is a response/request protocol. In other words, a request is submitted and a response is returned. A number of different parameters are used in the request. These parameters include an account i.d. identifier that provides an alphanumeric string that identifies a customer. Another parameter is a group i.d. that uniquely identifies a group. Similarly, there is also a field i.d. identifying the field. The permission types include read, write, availability, and delete. Other licensing rights include licensing rights read and licensing rights write.

The protocol provides that a login may be required before the session starts. A client that is ready to initiate a session with the PMT server 10 may be required to provide an account i.d. and password.

The protocol specifies a number of operations that may be related to the data stored within the database 14. These operations include:

getNodeData (obtaining node data)

setNodeData (setting node data)

deletepprofileNode (delete profile node)

getTransmission (obtaining permission)

setTransmission (set permission)

query (Inquiry)

The getNodeData operation is a parameter that conveys information identifying the user profile sought. The information may include a user i.d. and a field i.d. Conversely, when looking for a field, it is necessary to specify both the user i.d. and the field i.d. If the requesting client possesses the appropriate licensing rights, the get request results in the return of the required data to the client. If not, the client receives an appropriate message indicating that the request was denied.

The SetNodeData operation causes the client to set a value in the user profile. The input parameters may include a user i.d., a field i.d., and a value to be set.

The DeleteProfileNode operation causes the client to delete a field or user profile. The input parameters specify fields or user profiles. The client must have the appropriate delete access permission rights.

The GetPermission operation enables the client to obtain permission associated with a field or user profile. This field and the user profile are specified using input parameters.

The SetPermission operation causes the client to set permissions for a field or user i.d. This command can be used to set SetPermission (set permission) for the entire group.

The query operation returns a list of user IDs that match the query criteria.

The protocol also specifies operations that may be submitted when a request to manage the various groups is made. These operations include:

getMembers (acquisition members)

newGroup (New group)

DefineGroup (definition group)

deleteGroup (delete group)

getGroupPermission (obtaining group permission)

setGroupPermission (set group permission)

The getMembers operator allows a client to obtain a list of members within a group identified by a group i.d. input parameter.

The NewGroup operator enables a customer to define a new group. The input parameters include a group name and a text description. An acknowledgement is returned to the client that a group i.d. and/or a new empty group has been defined.

The DefineGroup operator defines the members of a group that has been created using the newGroup operator. The input parameters include a group i.d. and any algebraic set operators required to properly define the group.

The DeleteGroup operator deletes a group from the database 14. The input parameters specify a group i.d. of the group.

The GetGroupPermission operator obtains permission for a particular group.

The SetGroupPermission operator allows permission to be set for a specified group.

The protocol also includes operators for database schema management within the user profile. As described above, service providers and other customers may define patterns for data stored within a user profile. These operations include:

addField (Add field)

deleteField (delete field)

setschema permission (setting mode permission)

The addField operator may add a new field to the schema. The input parameter identifies the new field to be added.

The DeleteField operator deletes a field identified by the field i.d.

An API may be defined to enable a client to invoke the various operations specified by the PMT protocol.

One of the advantages of the illustrative embodiment is that it allows the user to control the user profile. The user may access the PMT server 10 using the UI logic 28. FIG. 7 is a flowchart illustrating the steps performed to generate a user profile. Information relating to the user is obtained (see step 170 in fig. 7). The user may be prompted by UI logic 28 to enter information to be incorporated into the user profile. Alternatively, information may be obtained by the data sharer device 22 or from other sources to build a user profile. This information is then stored in the user profile along with the associated licensing rights (see step 132 in FIG. 7). The user can set the licensing rights explicitly or default licensing rights 18 can be applied as well.

The illustrative embodiment advantageously has the ability to perform anonymous transactions by appropriately setting licensing rights. FIG. 8 is a flow chart illustrating steps that may be performed to facilitate such anonymous transactions. Initially, the permission rights for at least one data unit are set to prohibit access (step 180 of FIG. 8). This data unit may be, for example, a field. Access to such units may be prohibited by denying selected clients access to a plurality of such units. At least one data element within the user profile is configured such that the licensing rights permit the at least one customer to access the field (step 182 of fig. 8). The transaction may then be executed. Transactions may be performed anonymously, such as to prohibit access to user names and other identifying information. For example, access to a user's credit card number, address, or telephone number may be prohibited. Similarly, in some cases, access may be strictly granted to a payment mechanism, such as a credit card or bank account number.

One potential application is in the field of medical records (medical records) where a patient can be identified by a patient i.d. by which the patient cannot be easily tracked, access to fields in a user profile that will reveal the identity of the patient is prohibited, and the medical record can then be securely sent over a network connection marked with the patient i.d..

While the present invention has been described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the scope of the present invention as defined by the following claims.

Claims (23)

1. A method for user profile management, comprising the steps of:

providing a user profile that stores information related to the user;

establishing a first set of permissions for the user profile, wherein the first set of permissions specifies who may access the user profile;

establishing a second set of permissions for a selected field of the user profile, wherein the second set of permissions specifies who may access the field; and

wherein for a user to access the selected field, the user must be designated as having access to the user profile using a first set of permissions and must be designated as having access to the selected field using a second set of permissions.

2. The method of claim 1, wherein the first set of permissions specifies what type of access to the user profile is granted to a user who may access the user profile.

3. The method of claim 2, wherein at least one user party is granted read access to the user profile indicating that the user party can read information in the user profile.

4. The method of claim 3, wherein at least one user party is granted write access to the user profile indicating that the user party may write information to the user profile.

5. The method of claim 3, wherein at least one user party is authorized availability access to the user profile indicating whether data in the user profile is available to the user party.

6. The method of claim 3, wherein at least one user party is authorized deletion access to the user profile indicating that the user may delete information in the user profile.

7. The method of claim 1, wherein the first set of permissions contains a list of clients accessing the user profile and the second set of permissions contains a list of clients accessing the field.

8. The method of claim 1, wherein defined groups of parties are provided, and wherein at least one of the first set of permissions and the second set of permissions specify that one of the groups has access rights.

9. The method of claim 1, wherein the user specifies at least one of a first set of permissions and a second set of permissions.

10. The method of claim 1, wherein at least one of the first set of permissions and the second set of permissions is established by default.

11. The method of claim 1, further comprising the steps of: a third set of permissions is established for an additional field in the user profile, wherein the third set of permissions specifies who may access the additional field.

12. The method of claim 10, wherein the fields of the user profile are organized hierarchically, and wherein the fields contain additional fields.

13. The method of claim 1, wherein defined groupings are provided, and wherein at least one of the first group permission and the second group permission designates a person having access to a set of accesses obtained by performing a set algebra operation on at least two of the groups.

14. A method for user profile management, comprising the steps of:

providing a user profile that holds information related to a user and is accessible over a network;

defining groups of service providers for providing services to users, each group containing a group of service providers; and

access permissions to authorization information in a selected user profile are granted to a selected one of the groups so that service providers within the selected group can access the authorization information.

15. The method of claim 14, wherein the service providers in the selected group all provide a common type of service.

16. The method of claim 14, wherein at least one of the packets comprises other packets that form a subset of the packet, and the packets comprise logically related service providers.

17. The method of claim 14, wherein the user profile is accessed through a central repository, and wherein authorization information within the user profile is accessible by service providers that do not directly request accessible information from the user.

18. A method for user profile management, comprising the steps of:

providing a user profile having fields, wherein at least one of said fields has associated permissions;

permission is set for a given service provider to prohibit access to at least one selected field in the user profile and to authorize access to at least one given field, thereby supporting anonymous transactions between the given service provider and the user by concealing the identity of the user.

19. The method of claim 18, wherein the user profile includes a name field holding a name of the user, and wherein the selected field is the name field.

20. The method of claim 18, wherein the user profile includes an address field holding the address of the user, and wherein said selected field is the address field.

21. The method of claim 18, wherein the permission rights are set to prohibit access to the plurality of fields by a given service provider.

22. The method of claim 18, wherein the user profile includes a payment field that holds information related to a payment mechanism, and wherein the given field is the payment field.

23. The method of claim 18, wherein the user profile includes a credit card field holding credit card numbers, and wherein the selected field is a credit card field.