EP1287448A1 - User profile management in a communications network - Google Patents
User profile management in a communications networkInfo
- Publication number
- EP1287448A1 EP1287448A1 EP01931762A EP01931762A EP1287448A1 EP 1287448 A1 EP1287448 A1 EP 1287448A1 EP 01931762 A EP01931762 A EP 01931762A EP 01931762 A EP01931762 A EP 01931762A EP 1287448 A1 EP1287448 A1 EP 1287448A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- user
- contract
- agent
- profile
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000004891 communication Methods 0.000 title claims abstract description 17
- 230000006854 communication Effects 0.000 title claims abstract description 17
- 238000000034 method Methods 0.000 claims abstract description 24
- 230000004044 response Effects 0.000 claims description 15
- 230000008569 process Effects 0.000 abstract description 8
- 230000009466 transformation Effects 0.000 description 15
- 238000013459 approach Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 8
- 238000000844 transformation Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 230000005012 migration Effects 0.000 description 3
- 238000013508 migration Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000007935 neutral effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 230000003334 potential effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/953—Querying, e.g. by the use of web search engines
- G06F16/9535—Search customisation based on user profiles and personalisation
Definitions
- the invention relates generally to provision of services in a communi- cations network. More specifically, the invention relates to a system for providing user-specific information in a network where personalized services are provided.
- Profiling has become an important issue in solving the above problems related to complex services and overwhelming information flow. This is because profiling enables personalization of the services, which in turn provides customized aids to help individual users to cope with the above problems. Personalization is the process of applying the knowledge in the user profile in order to provide results fitting the needs of a particular user. Today, many Web portals are moving in this direction by providing means for filtering the information content based on the interests of the user.
- a further problem related to having each service maintain its own profile on each user is that an individual service's view of the users is very limited. Therefore, the user cannot benefit from the service in the most efficient way.
- Another major problem relating to the present situation is the privacy of the users. It is clear that the storage of personal data, such as the user profiles, in an open and shared system like the Internet requires careful consideration of user privacy. Since the users are, in the current situation, unable to comprehensively control the contents and the use of their profiles, the privacy of the users can easily be invaded. For example, an individual user has no means to prevent a malicious party from accessing the profile data on a single server or from combining the data on different servers.
- U.S. Patent 5,913,030 describes a system for communications between a client system and a server communicatively coupled to the client system.
- Information about a user is stored in the client system (i.e. in the client terminal).
- the user information comprises a plurality of attributes, each attribute comprising information relating to the user and a willingness indicator indicating the level of willingness of the user to reveal information concerning that attribute.
- the terminal can also include several persona modules, each containing data defining a particular persona of the user. The privacy of the user can further be protected by sending user- specific data to a trusted third party which reveals only aggregate demographic information about all the users to the server providing the service.
- the persona module can also be provided with a disguising function which generates incorrect information about the user.
- the main drawback of the systems where the user profile resides in the user terminal is that the utilisation of the user model is restricted to that terminal, i.e. typically to a fixed place, and the dissemination of the items of the user model is restricted.
- ProxyMate former Lucent Personalized Web Assistant, at www.proxymate.com
- ProxyMate focuses on offering users the means to interact with multiple servers so that an individual server providing a specific service can not reverse-engineer the identity of the user, but at the same time the user can be recognized and authenticated on repeated visits. This is achieved via generation of secure, consistent and pseudonymous aliases for Web users, and by anonymizing traffic to the Web servers. ProxyMate also acts as a mediator for e-mail.
- ProxyMate An important design criterion behind ProxyMate has been stateless- ness. It does not keep any long-term states, i.e. mappings between users and their aliases. Instead, all the aliases are generated on demand via a one-way function.
- ProxyMate works as a proxy for Web traffic. Hence, it can be located and used from anywhere in the network. These server-based systems require trust from their users. Although their theoretical construction is such that they do not require any state to be maintained outside the session, the implementation might, for example, collect a log of the user's actions. A further drawback of these served-based systems is that the user's connection to the server providing the service always goes through these proxy servers. This restricts the ways the desired data can be accessed. Further, constant routing through certain proxies results in inefficient use of the transmission resources of the network, and these proxies may become bottlenecks having an adverse effect on the response times of the sen ices. It is an object of the invention to obtain a solution by means of which it is possible to alleviate or eliminate the drawbacks described above and to bring about a system which provides the users of the network with full and comprehensive control of their profiles.
- each user is provided with a profile agent by means of which he/she can control his/her digital identities, i.e. the identities that the service applications see as the user.
- a profile agent by means of which he/she can control his/her digital identities, i.e. the identities that the service applications see as the user.
- Each user-specific profile agent has a multi-layer structure so that the user profile data can be accessed only through the uppermost layer comprising contracts which form the interfaces between the user-specific data and the network.
- the user-specific profile agents are accommodated in special servers, which are in this context termed hostels, and the network further com- prises a lookup system from where the location of a certain contract can be queried.
- the service applications can access the user-specific data only through the contract after such a contract is made for this purpose.
- the con- tract determines the information items that the service application sees from the user-specific data and also how the service can process said items.
- Each contract forms an interface of the user-specific data for a service or group of services.
- the contracts thus associate certain views or profiles with certain services. However, one service can also use more than one contract to access the user-specific data. In this case the service cannot recognize that the two contracts relate to the same user.
- the user profile data are disseminated only via user-defined digital identities. These identities form a layer between the contracts, which form the outermost layer of a user profile agent, and the basic profile data, which form the innermost layer of a user profile agent.
- the basic data can not be accessed by any service.
- the identities which are also called personae in this context, represent consistent views on the basic profile data of the user. The services see these views only, and they are unable to distinguish whether two different views belong to the same user or not.
- the privacy of the users thus has a central position in the system, since the user profile is centralized with an agent which can be controlled by the user, or by a party authorized by the user. Further, it is difficult to determine that two contracts are related and to expose the agent behind the contracts.
- profile agents can be mobile, they are no longer bound to certain providers, and the lifetime of the profiles becomes unlimited.
- Figure 1 illustrates the architecture of the system according to the present invention
- Figure 2 illustrates the general structure of an individual user-specific profile agent
- Figure 3 illustrates the cooperation of a service application with the profile agent
- Figure 4a illustrates a typical structure and information content of the lowermost layer of the user profile agent
- Figure 4b illustrates a typical structure and content of an individual item inside the lowermost layer of the user profile agent
- Figure 5 illustrates an example of the contents of the lowermost layer of a user profile agent
- Figure 6 and 7 are examples of the contents of two different personae on the middle layer of a user profile agent
- Figures 8 and 9 are examples of the contents of two different contracts on the outermost layer of a user profile agent
- Figure 10 illustrates an example of message transfer between the elements of the system when the user creates a profile agent for herself/himself
- Figure 11 illustrates an example of message transfer between the elements of the system when a contract is created for a service application
- Figure 12 illustrates an example of message transfer between the elements of the system in conjunction with a general information request received by a user profile agent
- Figure 13 illustrates an example of message transfer between the elements of the system when the user profile agent moves in the network
- Figure 14 depicts the structure of the lookup system.
- FIG. 1 shows the architecture of the general system according to the present invention.
- the system includes several servers (S1 to S3) which offer a broad array of resources and services for the users of the network.
- all the servers are nodes of the Internet or an Intranet network (or an equivalent TCP/IP network).
- service refers to a service application residing in a server.
- User terminals have access to the service providing servers in a manner known as such.
- the user terminals can be fixed terminals, as shown in conjunction with terminal UT1 , or mobile terminals that have wireless access to the system or to the network, as shown in conjunction with terminal UT2.
- Wireless access can be implemented through various access points (AP1 ) or alternatively through gateways (GW1) that translate the requests from the protocol stack used between the terminal and the gateway, such as the WAP protocol stack, to the protocol stack used between the gateway and the server, i.e. to the WWW protocol stack (HTTP and TCP/IP).
- AP1 access points
- GW1 gateways
- the types of the user terminals and the connections between the user terminals and the service providing servers are not of significance.
- the terminals are provided with browsers or other known client software by means of which they can communicate with the servers providing services.
- This communication occurs preferably according to HTTP protocol, although there can be a translating gateway between a server and a client terminal, as men- tioned above.
- the system further comprises user-specific profile agents PA so that each user of the system preferably has one profile agent assigned to that user only.
- a profile agent here refers to a piece of software that can accomplish tasks on behalf of its user and which stores the profile data related to the user.
- an individual profile agent is an integral entity to which the user can delegate the task of coordinating his/her profile.
- the structure of an individual profile agent, consisting of code and data, is discussed below in connection with Figures 2 and 3.
- the agents are implemented using known agent technology.
- the profile agents are located in specific servers, called hostels in this context.
- a hostel is simply a platform (i.e. a piece of software) that offers an execution environment for the profile agents and a connection to the network.
- Figure 1 shows only one hostel HS, although there are typically many hostels in the network.
- the system further includes agent creation units AC, by means of which the users can create their profile agents.
- Agent creation units can reside in the user terminals or in conjunction with the hostels, for example.
- Each user-specific profile agent is controlled only by the user in question.
- the user profile is centralized with an agent controlled by the user.
- a user-specific profile agent can be in a fixed location or it can be a mobile agent, especially if the user is mobile.
- a mobile profile agent preferably moves so that it is always in the hostel nearest to the current location of the user.
- the system further includes a lookup system LS which stores the current location of each individual profile agent and from which the locations of the profile agents can be queried.
- the structure of the lookup system is discussed in more detail below, where it is depicted that the location of each profile agent is stored as a plurality of locations, each location indicating the current address of the individual contract which is part of the profile agent.
- Figure 2 depicts the structure of an individual profile agent from the point of view of its clients.
- the agent preferably has a three-layer structure with the user base profile forming the lowermost layer.
- the base profile typically includes all data about the user, said data being supplied by the user or the clients.
- the middle layer includes the different digital personae of the user.
- Each persona is formed from the data in the base profile and it is a certain view of the base profile, the view being defined by the user.
- An individual persona or view can be formed passively, i.e. it can consist of data units that form a subgroup of the data units in the core profile, or actively, i.e. the desired data units in the base profile can be processed to obtain the data units forming the persona.
- the topmost layer of the profile agent consists of interfaces which are here called contracts. Contracts are the interfaces through which the user and the services can access the profile agent. The user always accesses the profile agent through a special contract, called master contract, which is for the use of the user only.
- the service applications access the digital personae through service contracts, i.e. the services can only point to the contracts, not to the personae behind the contracts.
- each service must first make a contract with the profile agent. After a contract is made, the service can utilize the profile agent through the said contract (interface).
- Each agent typically includes one contract per service provider or service application, although one contract can be for a group of applications/providers and one service application/provider can also use several contracts.
- the identity of the user is controlled by the contracts. While from the standpoint of the architecture the contracts mainly represent pseudony- mous contact points to the profile data, to the users their most important function is to set the limits to the information that is available to the clients (i.e. to the services).
- the profile agent needs to allow transformation of the base profile items from views to a base profile, and vice versa. The transformations usually needed are quite simple, such as replacing a name with an alias and emphasizing different interest areas of the user.
- a transformation from the base profile is made for a certain context. Generally, transformation is made for all valuations of the dimensions - who, where, when and what. These dimensions could be modeled as independent, so that the transformation could be the sum of transformations for all dimensions. In effect, the user could be represented by a base profile, and sets of transformations for each dimension. By selecting a suitable set for each dimension, and layering these upon the base profile, strong expressiveness with respect to the context can be achieved.
- Figure 3 illustrates the cooperation of a profile agent with a service application.
- Each contract CT on the uppermost layer handles access rights controlling both the entities who can access the profile agent and what those entities are allowed to do if access is allowed.
- the personae of the user corresponds to the views of the user available to the service applications. The views are formed from the base profile of the user, either directly or through transformations.
- the user profile agent is preferably based on a compromise of these two, i.e. the user fixes the transformation to some context.
- the transformation defines a persona of the user - e.g. a home or business persona.
- the personae are separated into their own layer, so that they can be used in multiple contracts and so that one contract can allow the use of multiple personae.
- the base profile contains the user's whole profile organized in a hierarchical manner.
- Figure 4a illustrates an example of a base profile organized in different categories by the content of the profile.
- the first category includes the unique identifiers of the user, the second category biographic and demographic data about the user, the third category the addresses of the user, the fourth category data about the interests and attitudes of the user, etc., and the last category data about the current location and activity of the user.
- Each category in the base profile includes a plurality of items.
- FIG. 4b illustrates an example of the structure of an individual item.
- the content of an item is divided into data units describing the item.
- the first data unit represents the name of the item
- the second gives a description of the item
- the third indicates the type of the item
- the fourth de-scribes how the item is transformed for a persona of the user
- the last one includes the value of the item.
- Figure 5 illustrates an example of the contents of one base profile forming the lowermost layer of an agent.
- the categories or items at the same hierarchy level have been indicated with bullets that are white at every other level and black at every other level.
- the user is Joe Doe, whose nickname is "Foobar".
- the "transformation" field describes all the transformations that are possible for that item.
- M male
- F female
- N neutral
- different service providers can gather information about the user preferences.
- the said category includes relative values indicating how frequently the user uses the sports, business, and weather services provided by the service portal at www.companyl .com. If a certain agreed ontology is used for user preferences, all service providers can utilize this information for their purposes.
- the base profile normally includes much more information than in the example of Figure 5, which only illustrates what kind of data the base profile can include.
- Figures 6 and 7 show two examples of the personae of the user whose base profile is shown in Figure 5.
- Figure 6 illustrates a business persona which can be used during office hours, for example.
- the above-mentioned business channel at www.companyl .com gets more weight than the other services, i.e. this persona is more interested in the business channel than in the other services.
- the nickname of the user is masked from the services, i.e. the services do not see the nickname of the user.
- Figure 7 illustrates a second persona, here called an online persona, which can be used in sessions initiated from home, for example.
- the gender of the user is changed to neutral, the income value is rounded to the nearest 10000, all the items in the name category, except the nickname, and also all the items under the home address are hidden.
- Figures 8 and 9 illustrate the contents of the contracts on the outermost layer of the user profile agent.
- Figure 8 shows a master contract which is used by the user only. To enable secure communication with the user, the master contract stores the public key of the client (PKU01) and public and secret keys of its own (PKM01 and SKM01). The client of the master contract is always the user whose master contract is in question.
- the items in the model/preferences category can be read and written, whereas the items in the identifiers category and under properties/income can only be read.
- the contract can also define the items of the base profile that are not allowed to access through the contract.
- the contract can further determine the personae (views) that can be seen through this contract. In this example, only the online persona can be seen through the contract. Thus, even if the user is currently using the business persona, serviceOI would see the online persona.
- the contract can also determine different policies for different services.
- the contract of Figure 9 includes one policy: if the recipient, i.e. the service provider, is "companyOI", indicating that the items are for its use only, all the items can be accessed which are not masked or otherwise hidden. As discussed below, the user controls what items can be seen through the contract, and in which form the items can be seen.
- the standard format according to P3P the Platform for Privacy Preferences Projects
- P3P the Platform for Privacy Preferences Projects
- the agent can also include several middle layers, each manipu- lating the view on the preceding layer. Determination of the data available to a client is preferably done so that the definition of the set of data available to a client gets more accurate and detailed moving from the base profile towards the outermost layer of the agent.
- Each user profile agent is preferably created by the user in question.
- Figure 10 illustrates an example of message transfer between the elements of the system when the user creates a profile agent for himself/herself.
- the system according to the present invention includes the above-mentioned agent creation units.
- Each agent creation unit is a piece of software that allows the user to create a user profile agent.
- the agent creation units can reside in the user terminals, in conjunction with the hostels, or in separate Web sites offering this service for the users.
- the messages exchanged are preferably always encrypted when the public key of the opposite party is available.
- the user terminal sends the agent creation unit a message requesting the said unit to initiate the creation of a user profile agent (step 1001 ).
- This message includes the public key (P_KEY_U) of the user.
- the agent creation unit generates an empty profile agent for the user.
- the agent creation unit requests the profile agent to create a master contract to allow the user to manipulate the agent through the said contract (step 1003).
- This request also includes the public key of the user.
- the user profile agent then generates an identifier (CID) for the master contract (step 1004) and a key pair for the master contract.
- the master contract now has the keys shown in Figure 8 for encrypted communication with the user.
- the user profile agent then informs the agent creation unit about the new contract by sending the creation unit an export message including the identifier and the public key (P_KEY_MC) of the newly created contract (step 1006).
- the agent creation unit sends the lookup system a registration request (step 1007).
- This request includes the identifier and the public key of the master contract as well as routing information pointing to the location of the profile agent. However, the routing information in this example is null (empty), since the user profile agent has not yet been moved to its correct location in the network.
- the lookup system checks that the identifier is not being used by any existing contract.
- the lookup system registers the contract and sends an acknowledgment to the agent creation unit (step 1008). After this the user profile agent is moved to its correct location, i.e. to a hostel (step 1009). If the agent creation unit and the profile agent are already in a hostel, this step is naturally omitted.
- the migration of the agent typically includes several messages, although only one is shown in the figure.
- the identifier of the contract is re-exported to the lookup system with proper routing information pointing to the hostel (step 1010). This is performed so that the hostel first activates the agent. As a result of this, the agent asks the hostel to perform the re-export, and the hostel sends the message to the lookup system.
- the agent creation unit then acknowledges the creation of the master contract to the user at step 1011. This acknowledgment message includes the identifier and the public key of the master contract.
- the user profile agent is now fully usable, although it is still empty.
- the user then has to supply data to the user profile agent.
- the user terminal first requests the routing information of the profile agent from the lookup system by sending a request including the identifier of the master contract (step 1012). Having received the routing information pointing to the hostel in which the user profile agent resides, an update message is sent to the hostel at step 1014.
- This message includes the identifier of the master contract, the operations to be performed, and the data to be used by the operations.
- the hostel forwards the message to the profile agent.
- the message would contain the following write operations and data: update("ldentifiers/name/first”, “John") update("ldentifiers/name/middle", “Bar”) update("ldentifiers/name/last”, “Doe”) update("ldentifiers/name/nickname", “Foobar”), etc.
- the user sets the desired data in the profile agent through the master contract whose address is first retrieved from the lookup system. This may require that several update messages are sent to the hostel.
- the profile agent After the profile agent has performed the desired operations, it acknowledges the operations (step 1017) to the hostel, which forwards the acknowledgment to the user terminal (step 1018).
- the user profile agent is now ready for the service applications. If the user later wants to update his/her existing profile agent, the update occurs as in steps 1012 to 1018 in Figure 10, i.e. routing information pointing to the correct hostel is first requested from the lookup system, and then one or more update messages are sent to the hostel where the profile agent resides.
- FIG 11 illustrates an example of message transfer between the elements of the system when a new contract is created between the user profile agent and the client (i.e. the service pro- vider/application).
- the user sends a conventional sen/ice request to a Web site (step 1101 ) providing services.
- the user typically receives a registration page from the server (step 1102).
- the user has to access his/her profile agent.
- he/she then sends the lookup system an import message requesting the address of the master contract from the lookup system (step 1103).
- the lookup system returns routing information to the user, the routing information indicating the current location of the master contract.
- the user profile agent is currently in hostel A.
- the user then sends a message to hostel A (step 1105), requesting a generation of a contract for the service.
- This message includes at least the identifier of the master contract as well as the public key of the service
- the hostel finds the user profile agent corresponding to the master contract ID received and forwards the message to the said profile agent at step 1106.
- the user profile agent then generates a contract ID and a key pair for the service (step 1107), and the agent exports the generated contract ID (CID) and its public key (P_KEY_C) to the hostel (step 1108).
- the hostel knows what node of the lookup system is available and sends a request to this node at step 1109. This request asks the lookup system to register the new contract.
- the message includes the ID of the contract, the public key of the contract, and routing information pointing to hostel A.
- the routing information given in this message indicates a different route to hostel A as compared to the route given at step 1104, so that the master contract and the service contract cannot be linked together by means of their location.
- the lookup system acknowledges the operation to the hostel (step 1110), which further acknowledges it to the user profile agent (step 1111).
- the user profile agent first sends the ID and the public key of the contract to the hostel, which forwards the message to the user terminal (steps 1112 and 1113).
- the user terminal updates the contract according to his/her preferences at step 1114.
- the user determines the views that can be seen through this contract by defining at least the outermost layer of the profile agent. This step determines what items the service provider/application can see, and in which form, and what the service provider is allowed to do with the contract.
- This message at step 1115 can be a normal HTTP-POST message including the contract ID and the public key of the contract.
- the user initiates the relationship between the service and the user profile agent by sending the identifier of the new contract to the server providing the service.
- the server requests routing information to the hostel of the agent from the lookup system (step 1116).
- the server receives this information at step 1117, it knows that a contract exists, i.e. that the user is not trying to bluff.
- the server requests information from the user profile agent by sending an information request to the hostel, which forwards the request to the profile agent (steps 1118 and 1119).
- the request includes the ID of the contract, the operations, and the arguments relating to the operations. For example, if the server asks for the data that is under the sub-category "name" in the user profile, the operation is "read” and the arguments include "identifiers/name”.
- the user profile agent first authenticates the request and then processes it. In response, the required information is returned to the server (steps 1121 and 1122). If a contract according to Figure 9 was created earlier, the user profile agent notices at step 1120 that the online persona must be used. Since the online persona is such that under the sub-category "Identifiers/name" only the nickname can be shown, the user profile agent returns only the nickname (Foobar) at step 1121. When the server receives this message, it can continue its normal operation by welcoming the user to the Web site (step 1123). This HTTP response then includes the nickname of the user in the body of the message. After this, the user can use the service.
- FIG 12 illustrates an example of message transfer between the elements of the system in conjunction with such a general information request coming from the server providing the service.
- the server again first requests routing information to the hostel of the profile agent from the lookup system and upon receiving it sends the information request to the hostel (steps 1201 to 1203), which forwards the request to the user profile agent (step 1204).
- the hostel the hostel of the profile agent
- the user profile agent then asks for permission from the user terminal by sending a verification request to the user terminal via the hostel (step 1205).
- the user profile agent If the user allows the operation, it returns an acceptance (step 1206).
- the user profile agent receives this message, it starts to process the request and then sends the desired information to the service (steps 1207 and 1208). For example, if the requested operation was "write", the user profile agent returns the status of the request (i.e. request accomplished). Should the user terminal deny the opera- tion required by the service, the service is informed that the operation requested is non-allowable. On the other hand, if no verification of the operation is required, the user profile agent replies the service directly after the request. As mentioned above, the user profile agent can also move in the network.
- the user profile agent can notice that it is too far away from the current location of the user.
- the user profile agent then initiates a location update by sending the current hostel a migration request, see Figure 13, step 1301.
- This message can include the address of the new hostel located near the current location of the user terminal, or, if the user profile agent does not know the nearest hostel, the message includes the current location of the user together with a request to move the agent to the hostel nearest to said location.
- the new hostel (hostel B) is sent a request to accept the user profile agent (step 1302). If the new hostel accepts the profile agent, it sends an acknowledgment to the current hostel (step 1303).
- the current hostel Upon receiving this message, the current hostel asks the user profile agent to serialize itself (step 1304). In response to this, the agent is transferred in serialized format to the new hostel (steps 1305 and 1306). This new hostel then activates the user profile agent at step 1307. In response to the activation, the user profile agent sends the new hostel a location update request for each of the contracts, one contract at a time.
- Figure 13 illustrates the location update of two contracts (CID., and CID 2 , steps 1308 and 1312, respectively).
- the messages sent by the user profile agent include the identifier and the public key of the contract.
- the new hostel sends the lookup system an update request inserting routing information into the message (steps 1309 and 1313 for the first and second contract, respectively).
- the lookup system updates the location of the contract indicated in the request and sends an acknowledgment back the to the hostel (steps 1310 and 1314), which forwards the acknowledgment to the user profile agent (steps 1311 and 1315).
- the user profile agent has received an acknowledgment from each update process, it sends the new hostel an acknowledgment request (step 1316).
- the new hostel acknowledges the transfer of the agent to the original hostel (step 1317).
- the new hostel updates the location of the user profile agent contract by contract.
- the locations are updated one contract at a time in order to prevent the lookup system from detecting that the contracts belong to the same user profile agent.
- the lookup system operates like a black box in serving the rest of the system.
- the contact points i.e. the contracts
- the contact points are registered there, via a loca- tion update operation, and are requested from there, via a lookup operation.
- Additional requirements for the lookup system are that it should be efficient and scalable. Thus, the capabilities of the lookup system should not hinder the mobility of the user profile agents.
- the options for implementing the lookup system are discussed briefly in the following.
- the profile agent knows its clients, the simplest choice would be for the profile agent to keep the clients aware of its whereabouts. However, through collaboration the clients could observe when each pseudonym (persona) changes its location, and thus could correlate which pseudonyms are likely to be linked to the same person. In particular, this would prevent the users from having two contracts with a client.
- pseudonym persona
- Utilizing forwarding chains is another option for the implementation of the lookup system.
- the agent leaves a forwarding address at its previous hostel when it migrates to a new hostel.
- a client can then find the agent.
- the drawback of this approach is that it performs poorly in situations where the agents are highly mobile - the length of the chain grows, and the search path might bounce from one side of the globe to the other.
- the home-based approach eliminates the erratic search paths in the forwarding chain approach.
- each user profile agent would have a designated server - home - to keep track of its location.
- this approach limits mobility, binding the user to its home provider.
- the name server approach is a traditional way to link identifiers to their locations. It is employed, for example in the Internet's Domain Name System. Name server systems are highly scalable, as the parts of the identifier space are distributed hierarchically over different servers. Unfortunately, hierarchical addressing assumes that address binding is relatively stable.
- the lookup system according to the present invention is preferably according to the system described in this article.
- a central notion in this location sen/ice is the exploitation of locality, meaning that the cost of a lookup increases with the distance to that address - i.e. it is cheaper to find local objects.
- the structure of such a lookup system is illustrated in Figure 14.
- the basic architecture is hierarchical so that the nodes of the system divide the network into a hierarchy of geographical domains. At the bottom of the hierar- chy are the leaf nodes, each leaf node covering a leaf domain which may in practice cover an area of a few LANs. The next higher level domain may then represent the city where the LANs are, for example.
- a directory node which stores location information for the contracts within its domain (i.e. the domain covered by the nodes below it).
- the root node at the top of the hierarchy covers the whole network and contains pointers for each identifier to the node in the next level, and so on.
- the leaf nodes store the addresses of the contracts.
- the lookup operation is started from the leaf node corresponding to the domain where the client is. If the leaf node has the address, the client gets the address immediately. Otherwise the request is propagated upwards until it reaches a directory node containing a record of the searched identifier, from where it propagates downwards to the leaf node where the address is.
- stateless communication In the above-described stateless communication mode no long-term information about the location of the profile agent is kept outside the lookup system. This mode enables a simple request-response message exchange. Since the other modes pose security risks, stateless communication is the preferred way of communication for the majority of the clients. For each message exchange, the clients first lookup the location of the profile agent and then perform the message exchange, including the authentication.
- a session-based communication mode enables the clients to commence a long-term relation with the profile agent. Should the profile agent migrate during this period, the session is also migrated. Furthermore, authenti- cation and policy notification are performed only once. However, when the profile agent sends notification of the new address to the clients, they can engage in a correlation attack based on the arrival time of the updates. Thus, the use of session based communication should be limited to trusted clients only. Event-based communication can be used for distributing changes in the profile. In this mode the clients subscribe to receive notification of certain items. When the profile agent receives an update on an item, it sends notification to all subscribers of that item.
- poten- tial can be reduced by making their delivery more asynchronous, e.g. by inserting varying delays between each notification to be sent.
- the user profile agent can also be a distributed object comprising a mother agent and several child agents. Thus, different contracts can reside in different hostels. The benefit of this implementation would be that the user no longer has to trust a single hostel with all information, except for the hostel of the mother agent, which can still access all parts of the profile but no longer knows all the clients with whom the profile agent has a relationship.
- the profile agents can also be implemented without storing the views for subsequent information requests.
- a view is formed by the profile agent each time profile information is requested, using one or more functions determining the view.
- the said one or more functions form the middle layer of the agent, residing between the core and the contracts.
- a contract can thus include its identifier only.
- the service level can easily be improved.
- the system can utilize ready-made views which are taken into use according to the time of day or according to the location of the user. In order to constrain the maximum number of contracts, a contract can be deleted after it has not been used for a certain time period.
- Anonymous routing can also be utilized for preventing malicious parties from exposing the user agent by correlating the contracts.
- a different address is attached to each contract of a user agent through the anonymizing network to which the hostels are connected. Since anonymous routing is known as such, it is not discussed in more detail here.
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Development Economics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Economics (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FI20001074 | 2000-05-08 | ||
FI20001074A FI111879B (en) | 2000-05-08 | 2000-05-08 | Management of user profile information in a telecommunications network |
PCT/FI2001/000430 WO2001086494A1 (en) | 2000-05-08 | 2001-05-07 | User profile management in a communications network |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1287448A1 true EP1287448A1 (en) | 2003-03-05 |
Family
ID=8558348
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01931762A Withdrawn EP1287448A1 (en) | 2000-05-08 | 2001-05-07 | User profile management in a communications network |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1287448A1 (en) |
AU (1) | AU2001258465A1 (en) |
FI (1) | FI111879B (en) |
WO (1) | WO2001086494A1 (en) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1692837B1 (en) | 2003-12-12 | 2008-02-13 | Telecom Italia S.p.A. | Method and system for user modelling |
US8166114B2 (en) | 2006-02-21 | 2012-04-24 | Strangeloop Networks, Inc. | Asynchronous context data messaging |
US7937435B2 (en) | 2006-02-21 | 2011-05-03 | Strangeloop Networks, Inc. | Identifying, storing, and retrieving context data for a network message |
US8037127B2 (en) | 2006-02-21 | 2011-10-11 | Strangeloop Networks, Inc. | In-line network device for storing application-layer data, processing instructions, and/or rule sets |
US9906620B2 (en) | 2008-05-05 | 2018-02-27 | Radware, Ltd. | Extensible, asynchronous, centralized analysis and optimization of server responses to client requests |
US9549039B2 (en) | 2010-05-28 | 2017-01-17 | Radware Ltd. | Accelerating HTTP responses in a client/server environment |
US9401962B2 (en) * | 2010-10-28 | 2016-07-26 | Verizon Patent And Licensing Inc. | Traffic steering system |
US9542501B2 (en) | 2011-01-28 | 2017-01-10 | Radware Ltd. | System and method for presenting content in a client/server environment |
US10157236B2 (en) | 2011-05-23 | 2018-12-18 | Radware, Ltd. | Optimized rendering of dynamic content |
US9292467B2 (en) | 2011-09-16 | 2016-03-22 | Radware, Ltd. | Mobile resource accelerator |
WO2017101003A1 (en) * | 2015-12-15 | 2017-06-22 | 深圳市银信网银科技有限公司 | Method and device for data exchange processing |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999039281A2 (en) * | 1998-01-30 | 1999-08-05 | Easynet Access Inc. | Personalized internet interaction |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0807291B1 (en) * | 1995-01-23 | 2000-01-05 | BRITISH TELECOMMUNICATIONS public limited company | Methods and/or systems for accessing information |
GB2328110B (en) * | 1997-08-01 | 2001-12-12 | Mitel Corp | Dialable screening profile |
GB2335761B (en) * | 1998-03-25 | 2003-05-14 | Mitel Corp | Agent-based web search engine |
-
2000
- 2000-05-08 FI FI20001074A patent/FI111879B/en not_active IP Right Cessation
-
2001
- 2001-05-07 WO PCT/FI2001/000430 patent/WO2001086494A1/en not_active Application Discontinuation
- 2001-05-07 EP EP01931762A patent/EP1287448A1/en not_active Withdrawn
- 2001-05-07 AU AU2001258465A patent/AU2001258465A1/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999039281A2 (en) * | 1998-01-30 | 1999-08-05 | Easynet Access Inc. | Personalized internet interaction |
Also Published As
Publication number | Publication date |
---|---|
WO2001086494A1 (en) | 2001-11-15 |
FI111879B (en) | 2003-09-30 |
AU2001258465A1 (en) | 2001-11-20 |
FI20001074A (en) | 2001-11-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103503419B (en) | The system and method that the equipment of the network address with distribution is accessed using Web proxy | |
Hofmann et al. | Content networking: architecture, protocols, and practice | |
US7206788B2 (en) | Schema-based services for identity-based access to device data | |
EP1130869B1 (en) | Management of user profile data | |
US7568016B2 (en) | Cookie management systems and methods | |
US6694375B1 (en) | Communications network and method having accessible directory of user profile data | |
US20030055652A1 (en) | Private network exchange with multiple service providers, having a portal, collaborative applications, and a directory service | |
WO2002073332A2 (en) | Separation of instant messaging user and client identities | |
JP2003531427A (en) | Stateless mechanism for data retrieval | |
KR20080009225A (en) | Method and system for providing and managing public telephone directory service | |
US20040006590A1 (en) | Service for locating centralized schema-based services | |
EP1287448A1 (en) | User profile management in a communications network | |
US7246122B2 (en) | Schema-based services for identity-based data access to favorite website data | |
US20020194295A1 (en) | Scalable data-sharing architecture | |
EP2242212A2 (en) | Digital Content Distribution System and Method | |
Bolcer et al. | Peer-to-Peer Architectures and the Magi Open Source Infrastructure | |
WO2001058113A1 (en) | Location service for the internet | |
Synnes et al. | Location Privacy in the Alipes platform | |
Sheresh et al. | Understanding directory services | |
US20020069283A1 (en) | Apparatus and method for providing communication service based on personal identifier in internet network | |
JP2002041522A (en) | Personal information disclosure system and electronic mail distribution system | |
KR20030089363A (en) | System and method of session management for integrating wired internet and mobile internet service | |
Paul et al. | A survey of naming systems: classification and analysis of the current schemes using a new naming reference model | |
Shang | Evaluation of usage scenarios in Mobile People Architecture | |
Tamrakar | Impact of Social networking sites on Local DNS server |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20021111 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: MAEKELAE, TEEMU |
|
17Q | First examination report despatched |
Effective date: 20030304 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: TELIASONERA FINLAND OYJ |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20040612 |