shown in recent studies [32], provides good performance and security .... The structure of a content provider's site in the wireless environment is usually a.
mPERSONA: Personalized Portals for the Wireless User: An Agent Approach♦ Christoforos Panayiotou, George Samaras Department of Computer Science, University of Cyprus CY-1678 Nicosia, Cyprus {cs95gp1, cssamara}@ucy.ac.cy
ABSTRACT The needs of the wireless and mobile user regarding information access and services are quite different than those of the desktop user. This need is not about browsing the Web but about receiving personalized services that are highly sensitive to the immediate environment and requirements of the user. Personalization appears to be the most appropriate solution to this need. It comes into aid by creating personalized portals that are specific for the wireless user, which (a) are focus on the local content and (b) directly tones down factors that break up the functionally of the Internet/wireless services when viewed through wireless devices; factors like the “click count”, user response time (the “choice” factor) and the size of the wireless network traffic. In this paper we present a flexible personalization system for the wireless user that takes into consideration user mobility, the local environment and the user and device profile. The system utilizes the various characteristics of mobile agents to support flexibility, scalability, modularity and user mobility. We present metrics appropriate to the wireless environment, and an initial performance evaluation indicating improvement ranging from 33% up to, for certain metrics, 60%.
1. Introduction Wireless access is not about browsing the Web on your cell phone; it is about providing personalized services that are highly sensitive to the immediate environment and needs of the user. Thus, the main requirement that a mobile user presents as he moves around the globe, is the effective ability to access local information and services. If she needs to eat she needs a local restaurant that serves the food she likes, if he needs a lawyer he needs one with local contacts and knowledge of the local law system, and so on and so forth. It is evident that the
♦
This work is partially funded by the Information Society Technologies programme of the European Commission under the IST-2001-32645 DBGlobe project.
effectiveness and well being of the mobile user is effectively tightly coupled to the local environment and content. To alleviate this and similar problems, the solution of personalization and user profiling (representing in some form the user’s interests) is lately receiving attention. The purpose of such systems is to reduce the information volume produced by an Internet site as well as structuring it based on the needs of the individual user. The design, however, and implementation of such systems poses many challenges which become even bigger within the context of the wireless Internet [8,9]. Some of the added issues are low bandwidth, unreliable connectivity, lack of processing power, limited interface of wireless devices and user mobility. Adding to all these, is the huge variety of wireless devices with different capabilities and limitations. On the positive side, however, is the fact that while the Internet is governed by a tremendous quantity of unstructured information, the wireless internet is mostly characterized by a more structural content that makes it easier to more resourcefully and effectively exploit it to the benefit of the moving user. In a nutshell, the proposed personalization system provides innovative solutions to cellular network subscribers; it provides them with personalized content according the end-user preferences and local environment, taking into account not only his/her profile but the profile of his/her handset device as well. The innovation relies in the way that the end-user receives the information to his/her mobile handset, i.e. with minimized clicks, and exactly the information required, thus reducing access time, cost and browsing time (defined as the time needed to select and follow a given link in the current page, we refer to as the “choice” factor). In fact for each end-user the system builds a unique wireless (e.g. WAP) portal that is created according to the user profile. To this end, and in simple terms, the system devises a flexible middleware and protocols to handle the diversity of content structures and their semantics. Algorithms are designed and implemented so that (a) they match the user profile to the local content, (b) they dynamically materialize the user’s personalized portal and (c) they adapt the device characteristic to the various results. Performance is also measured, demonstrating the effectiveness and viability of the system. Our initial performance evaluation indicates improvement ranging from 33% up to as much as 60% for certain metrics. The implemented system utilizes multiple communication technologies such as Bluetooth [20] and cellular connectivity.
The system employs the technology of mobile agents [2,3,4] by taking advantage their various characteristics such as asynchronicity, autonomy, and mobility. Via mobile agents the system becomes modular, scalable, flexible but above all, truly mobile. Consider, for example, the obvious requirement of having the profiles able to move around following the clients; user profiles implemented as mobile agents can do the trick. A degree of security is also enforced via the controlled access that mobile agents provide to their data. The paper is organized as follows. Section 2 gives background information on mobile agent technologies. Section 3 presents the problem of personalization and section 4 presents the proposed architecture including all its components and the respective algorithms. Section 5 gives a short discussion on the extensibility of the architecture and section 6 discuses the advantages of utilizing mobile agents. Section 7 presents the implemented prototype, experiments and performance analysis. Finally, section 8 presents related work and section 9 concludes the paper.
2. Mobile-Agent Technologies Mobile agents are processes dispatched from a source computer to accomplish a specified task [21, 22]. Each mobile agent is a computation along with its own data and execution state. After its submission, the mobile agent proceeds autonomously and independently of the sending client. When the agent reaches a server, it is delivered to an agent execution environment. Then, if the agent possesses necessary authentication credentials, its executable parts are started. To accomplish its task, the mobile agent can transport itself to another server, spawn new agents, or interact with other agents. Upon completion, the mobile agent delivers the results to the sending client or to another server. By letting mobile hosts submit agents, the burden of computation is shifted from the resource-poor mobile hosts to the fixed network. Mobility is inherent in the model; mobile agents migrate not only to find the required resources but also to follow mobile clients. Finally, mobile agents provide the flexibility to adaptively shift load to and from a mobile host depending on bandwidth and other available resources. The driving force motivating mobile agent-based computation is twofold. First, mobile agents provide an efficient, asynchronous method for searching for information or services in rapidly evolving network; mobile agents may be launched
into the unstructured network and roam around to gather information. Second, mobile agents support intermittent connectivity, slow networks, and light-weight devices. Thus, mobile agents provide many benefits [2, 3, 22] in Internet system programming (otherwise networking programming), in which there is a need for different kinds of integrated information,
monitoring and notification, encapsulating
artificial
intelligence techniques, security and robustness [1, 3, 31, 32, 35, 36, 37]. Also the mobile agent paradigm has satisfactory performance when deployed for distributed access to Internet databases, distributed retrieving and filtering of information and minimizing network workload [1, 16, 30, 31, 34, 35, 37, 38]. Finally, mobile agents have proved very effective in supporting asynchronous execution of client requests, weak connectivity and disconnected operations and the dynamic adaptation to the various types of user connectivity [1, 31, 33, 34]. Mobile Agents Platforms: Several mobile agent platforms have been proposed. They can be broadly categorized as Java and non-Java based ones. There is an increasing interest in Java-based platforms due to the inherent advantages of Java, namely, platform independence support, highly secure program execution, and small size of compiled code. These features of Java combined with its simple database connectivity interface (JDBC) that facilitates application access to relational databases over the Web at different URLs, make the Java approaches very attractive to work with. The Java-based mobile agents platforms include IBM’Aglets Workbench [23], Recursion Software’s Voyager[24], Mitsubishi’s Concordia [25], IKV++ Grasshopper [26] and General Magic’s Odyssey [22]. The non-Java-based systems include, for example, TACOMA [27] and Agent Tcl [28].While all these systems provide the basic functionality expected from such mobile platforms, they differ significantly in their system architecture, the communication mechanism employed, the additional functionality they provide and their performance. For a comprehensive comparison and quantitative performance evaluation of the Java-based mobile agents platforms see [29, 30]. For our purposes, namely to demonstrate the abilities and potential of mobile agents, we have chosen to use Recursion Software’s Voyager. Voyager, as shown in recent studies [32], provides good performance and security features for the handling and transportation of the agents. In Voyager SSL technology can be utilized for the transfer of data. Additionally, Voyager can use different, application customized policies in combination with certificates (as in the public-private key scheme) in order to authenticate and authorize RMIs and objects/agents.
3. The Personalization Problem The problem of personalization is a complex one with many aspects and issues that need to be resolved [10,12,14]. Some of these issues become even more complicated once viewed from a wireless perspective. Such issues include, but are not limited to, the following: •
What content to present to the user. How to decide what to show, using user profiles, using the user history to predict future needs etc. When using user profiles we must address the need for (1) storing the interests of the user in a format that is easy to be used, be updated or moved, and (2) relating interests and items based on a semantics level (e.g., the theme interest of “flowers” is related to “florists” or even fertile producers.)
•
How to show the content to the user. Many users want to see the same things but the form they want the data presented might be different. In the wireless environment this also relates to the mobile device used and its specific characteristics.
•
How to ensure the user’s privacy. Every personalizing system needs (and records) information about the habits of each user. This leads to privacy concerns as well as legal issues [11]. It also leads to lack of user trust and could result in the failure of the system due to the avoidance of its use.
•
How to create a global personalization scheme. The user doesn’t care if a set of sites can be personalized but that at each one of them he has to repeat the personalization process. This is especially annoying and cumbersome for the user on the move carrying a resource poor mobile device.
These are the major issues of personalization. They could be summarized in the following phrase: “What, how and for everything.” There are many approaches to personalization [8,9,10,12,13,14,39,40,41,42,43,44,45,46,47,48] and each one of them usually focuses on a specific area, whether this is profile creation, machine learning and pattern matching, data and web mining or personalized navigation. So far, to our knowledge, there hasn’t been an approach towards a total solution or more importantly focusing specifically to the wireless/mobile user.
4. The mPERSONA Architecture One of the issues of the personalization problem is the lack of an architecture that combines the existing techniques in a component-based fashion. Our aim is to
propose such architecture, which in addition is flexible and scalable. Furthermore, we focus our efforts on the wireless Internet in general. We do that by avoiding tying up our proposal to specific wireless protocols (today that would be the WAP [5]) and taking into consideration mobility, device characteristics and other limitations imposed by mobility and the wireless medium. We achieve this by using, as much as possible, autonomous and independent, components. This allows us to replace any component as needed without making the whole system inoperable. To realize such a high degree of independence, autonomy and flexibility we based our approach on mobile
agents
and
mobile
E ntry Point
E ntry Point
computing models such as the
C ontent P rovider
”client intercept model” [1,4]. The aim is to build a distributed personalization
system
that
Intern et
supports user mobility, wireless content
and
allows
multiple
E ntry P oint
content providers to seamlessly
C ontent P rovider
join in. The architecture supports
Figure 4.1: Abstract View of the Architecture
C ontent P rovider
multiple “entry points” (Fig. 4.1) whose main purpose is to provide registration facilities to users and
content providers to initialize/materialize the various
agents/components (Fig. 4.2: 1, 2, 3, 4) of our architecture and maintain the user profile. The initial entry point is called the “home” of the user. The wireless user can connect directly to any content provider (Fig. 4.1) that participates to the system. The architecture’s components (i.e., mobile agents) accommodate this by relocating themselves to the chosen content provider dynamically (Fig. 4.2: 3,4); it doesn't matter where your profile is located because it can follow/find you. In summary, we have designed a
Content Provider
Content
(7)
multi-tier agent-based architec-
Request
Content reform component Agent B Agent A (4) (3)
Result
ture. The architectural components are distinguished based on
Entry Point
DB
(6)
Internet Entry point & User profile management component (5)
(2) Content description component
(8) Description tree
(9) Selection tree
Figure 4.2: Detailed View of the Architecture.
their location and functionality DB
(1) Content selection component
(Figure 4.2): Entry-Point Site, Content Site and Client Site Components.
Entry-Point Component: User Registration and Profile Management (Fig. 4.2: 5): register and manage user profiles. Content Side Components: (1) Content Description (Fig. 4.2: 1,6): create content’s provider metadata structure and (2) Content Selection (Fig. 4.2: 2,7): create and manage the user’s personalized portal metadata. Client Side Component: Content Reform (Fig. 4.2: 3,4): materialize the portal, reform and deliver the desired content. Agents may be mobile (move from one location to another, i.e., the Client Site Components) or stationary (migrate to a location and remain there, i.e., the Entry-Point and Content Side Components). Without loss of generality we present the component participation and interaction between only one pair of entry point and content provider (Fig 4.2). So, considering the single pair case, at the one end we have the entry point of the client into our architecture (Fig. 4.2:9) and on the other lies the servers that link the content providers with the client (Fig. 4.2:8). In between these ends is the heart of our approach (Fig. 4.2: 3,4), implemented by mobile agents. 4.1 User Registration and Profile Management Component By user needs we mean both, her thematic preferences (i.e., the traditional notion of profile) as well as the characteristics of her personal device on which any requested info will be displayed. By focusing on wireless Internet the capabilities of the user’s device become crucial as these wireless devices are quite restrictive on the form and length of the received content. Yet these two kinds of data are quite different indicating the need to split the user’s profile in two parts (Fig. 4.3). The first part holds the interests of the user, called the “theme profile”. The second part holds information about the user’s device and is called respectively “device profile”. The creation and management of these profiles is implementation specific. This is true especially in the case of the “theme profile” where a profile can be comprised of just a collection of keywords that represent theme interests (as in our implementation), or a complicated scheme that exploits the user’s history. Similarly, for the device profile we may opt to just have a simple collection of device characteristics (as in our implementation) or to use a standardized format such as CC/PP [7].
User Profile Theme Profile Sports, NBA, Football, Domestic news, …
Device Profile 120 chars. width, 200 chars. height, 1400 bytes max., …
Figure 4.3: The user’s profile
The “User Registration and Profile Management” component (fig. 4.2:5) serves as the registration and entry point of the client/user and content provider in our system. It host the user and content provider registration repositories, the user profile repository as well as all the necessary services for initializing the mobile agents (components) used by the client or content provider. During user registration the user provides the system with his profiles; his theme profile and his devices profiles (one per device). After a successful registration, agents A and B of the Reform Component are created (see section 4.4 below). Upon their creation they upload the device and theme profile associated with the current user respectively. Hence we are able to move around the user profile as needed. During content provider registration the content provider submits her characteristics and her URL to the system. After a successful registration the Content Description and Content Selection components wrapped as mobile agents are sent to the content provider where they finally park (see sections 4.2 and 4.3 respectively). These components are initiated asynchronously, before any client activity. The user and content provider can un-register from the system at will. This, of course, will signal the deletion of the profiles, user characteristics and parked components and in general the abolition of their existence from the system. The component is implemented as a static agent (one per server), which resides on a dedicated Internet server (one of many) that is part of our architecture. Note that the specific entry point (only one), that is used to store a user’s profile, is the “home” of that user. To be able to support user connection from any entry point (e.g., for profile manipulation or any other activity) we have implemented a mechanism to locate the home of the user and thus allowing her mobile agents to access any required information. The implemented mechanism consists of a distributed broker that is, in effect, a distributed registry of the users registered to the system. The above mentioned mechanisms utilize an in-house location management system for moving objects called Tracker [15]. 4.2 Content Description Component The structure of a content provider’s site in the wireless environment is usually a hierarchy of information types (see fig. 4.4). In fact, this type of structure is adopted by the vast majority (if not all) of the wireless content providers (e.g., WINMOB Technologies [17], YOURWAP.com [18], Yahoo Mobile [19] etc). This is quite logical if someone considers the informative nature of the majority of the wireless
services provided by such sites. They provide local content, which needs to be structured in a way that can tackle the limitations of the wireless devices and provide easy and structural navigation. Indeed a hierarchical structure can make the navigation through a site much easier by toning down the navigational confusion created by a limitless number of unstructured link choices. This hierarchy is easily represented by a tree structure. News Sports Basket
Football
Political National
International
Financial General
Taxes
Figure 4.4: An Information Hierarchy of a site
Knowledge, however, of the content structure alone is not enough; we also need the context description of each content node. The sole purpose of this component is to construct a tree where each node of the tree contains this metadata. Figure 4.5a shows one such tree (called Description or Metadata Tree). We are, thus, able to fully describe both the navigational structure as well as the context (or semantic) structure of the site of a content provider. In essence, this metadata associates each node with one or more keywords (i.e., “thematic interests”) that match the type of information under that node. For example, when a node contains information on flower shops we associate with it the thematic interests of “florist”, “flower” etc. In fact, what is needed is a full semantic description of each node. Once the Metadata Tree is produced, existing techniques (such as pattern matching) can be used to select the wanted content. Note that whatever selection technique is used is purely an implementation detail that has no impact on the design of the architecture. It is obvious, that for performance reasons, the Content Description component should be as close as possible to the real content. Metadata Tree Creation: To produce such a tree a specialized crawler is build that automates the process. This crawler makes it trivial to get the (semantic) structure of the provider. To get the context description of each content node, however, the provider is required to include at least one keyword in her pages, describing the content of each node. Nonetheless, this is not enough as different users describe the same concept using a variety of different keywords. To alleviate this problem the crawler utilizes a thesaurus of theme topics to fully enrich the description of each node (fig. 4.5:b). At the end of the crawling procedure each node is associated with
a large array of semantically similar keywords. We can still, however, face the case where the same topic is used to describe two completely different information pages. For example, the topic “Japanese” might refer to either restaurants or art. To differentiate between the two (or more similar concepts) we use the hierarchy of the content by allowing the inheritance of the context metadata from the upper nodes of the Metadata Tree. Thus, the full context metadata for each content page (tree node) are the “thematic topics” directly linked with it (such as “Japanese”), along with the topics of its parent nodes (“Arts”). The parent topics are used to narrow down the contextual domain of the node in question (e.g. Arts:Japanese, Food:Japanese, Playoffs:Basket, Playoffs:Football). (a)
(b)
Sports, Sportsmanship, Sport events, Games, Playoffs, Athletes, Athletics, Exercise,…
Figure 4.5: Enriching the Description Tree: Sports page example
Forest of Metadata trees: For each content provider participating in the system, we build the corresponding Metadata Tree – we do not build one Metadata Tree accommodating all the content providers. This allows the maintenance of the content’s hierarchical structure by avoiding merging different hierarchies into a complex graph of hierarchies that may contain cycles. In this way when a user decides to connect and retrieve content from a specific content provider, she utilizes the appropriate Metadata Tree. Furthermore, by separating the Metadata Trees per provider, we avoid the situation where we have contextual discrepancies between various parts of the Metadata Tree (e.g. use the same keyword somehow for two
completely different topics), as each content provider is not likely to change its contextual description style due to someone else’s decisions. Maintenance of Metadata Tree: There is also the issue of maintaining the Metadata Tree. Luckily the Metadata Tree is not sensitive to the actual content, but only to the contextual type and contextual the structure of the content. It is typical for these two factors to have a small rate of change, and most of the times the changes made are additions. This makes it easier to maintain the Metadata Tree with partial and/or incremental updates. 4.3 Content Selection Component This component uses the Metadata Tree and the user profile to produce a new trimmed tree (called the “Selection Tree”) (see fig. 4.7:A-E). This tree represents the user’s personalized portal. The used algorithm is split into three modules: 1. Find all the useful nodes from the Metadata Tree (fig. 4.7:B). Matching and comparing the theme interests taken from the user profile and the Metadata Tree achieves this. During the matching the inheritance of the contextual topics of the Metadata Tree is observed in order to make it more precise. 2. Discard the unneeded nodes (fig. 4.7:C). This step Cuisine Cuisine just removes the unwanted nodes/branches from Asian the Metadata Tree. Chinese Chinese 3. Restructure and further reduce the Metadata tree. Figure 4.6: Tree In this final step we further reduce the tree by restructuring. We are removing the inner unneeded nodes (fig. 4.7:D). interested only for Chinese
Please note the difference between steps 2 and 3: Step 2 drops all the nodes that aren’t part of any navigational path to the interesting nodes while step 3 shortens these paths by eliminating unneeded inner nodes. The final product is a reduced tree that contains only the desired nodes without the need to contain the context metadata (see fig. 4.7:E). In fact the product of this matching algorithm is a metadata hierarchy representing the personalized portal of the user. This component should also reside (or park) at the provider’s site and it is implemented as a static agent. 4.4 Content Reform Component This component is the truly mobile portion of our architecture and is split in two parts (fig. 4.8). Along with the flexibility provided by mobile agents, the mobility
required/desired by this component is the main reason for basing our approach to mobile agents.
User Profile Sports, NBA, Football, Domestic news
(A) The description tree at the beginning of the transformation.
(B) During the first step of the transformation we find all the interesting nodes.
(C) On the second step of the transformation we remove all the branches/nodes that are of no interest.
(D) The third step removes any unneeded inner nodes
(E) The final result: The selection tree
Figure 4.7: Transforming a Description Tree to a Selection Tree.
The first part of the component (i.e., Agent B) carries the user’s theme profile and resides at the server side. It arrives there either following the user or, as it is very often required and so instructed, ahead of the user. Its purpose is twofold: First, whenever the agent visits a new content provider, it delivers the profile to the Content Selection component. In return it receives the appropriate Selection Tree. Second, upon a user’s query, it takes as input the Selection Tree and delivers a modified version of the currently requested content node. The modification made to the content node is the removal or addition of links from the node according to the Selection Tree and the dynamic characteristics of the user’s profile (i.e., his location). Content nodes Selection tree
Reform component Agent B: Reforms the navigation between nodes
Requests / Results
Agent A: Reforms the result based on the client’s device
Result
Client
Request
Figure 4.8: Content Reform Component This restructuring has the effect of bringing “closer” the interesting content
nodes, as well as hiding the irrelevant ones effectively materializing, in a step wise fashion, the personalized portal. The example shown in part 3 of the figure 4.9 presents the personalized content of the provider’s original node (i.e., part 1). Note, that the user has the option to see the original, impersonalized content node and thusly has the opportunity to see the hidden nodes. Agent B then passes the modified node to the second part of the component (namely Agent A which caries the user’s device profile). This part reforms the received content node according to the user’s device profile and delivers it back to the client. For example, if the user’s device cannot support the full length of the served page then it splits the page in smaller parts and so serves them to the user’s device. Another such example is the elimination of any, unsupported by the specific user’s device, features of the page (e.g. the use of WTAI links - for the WAP protocol). It is worth noting that once agent B receives the Selection tree the content provider has no need of the user’s profile anymore. Also note that the user’s profile isn’t actually delivered to the content provider but to the Content Selection component.
(1)
(1) The original provider’s node (2) Removed the unwanted nodes (3) Replaced some links in order to shorten the navigation paths to the interesting nodes interesting nodes
(2)
(3)
Figure 4.9: 3.8: Navigational Navigational restructuring restructuring of of the the Content Content Provider’s Provider’s pages. pages Figure Migration and design Issues: Agent B migrates in the following two ways: (a)
following the user to a specific content provider site and (b) sent in advance (by the user) to a particular site, in which case, upon his arrival his personalized portal is ready waiting for him. This is done in order to optimize the data transfer (the link) between the content provider and the client. By locating agent B to the content source we minimize the amount of content transferred over the Internet, wireless or not. As the user may request content from different providers we need to relocate agent B. So it is essential that agent B is a mobile agent. Asynchronicity is another important feature of Agent B in that during disconnections agent B can continue processing the user’s request which upon reconnection are served to the user. Similar design issues apply for agent A for both the mobility requirement and the device profile insulation. In order to optimize the link on the client’s side we have agent A located as close as possible to the user’s device. If the device was powerful enough, agent A could be located on the device itself. However, this is not the case today where many of the vastly different devices (such as WAP enabled phones or PDAs) do not support this,
thus requiring keeping agent A on the fixed network. In order to minimize the (wireless) network latency between the user’s device and the agent we need to relocate it as close to the user as possible. Optimizing the Materialization of the Selection Tree: To, over time, optimize the materialization of the personalized portal, Agent B maintains a cache of the so far materialized portal. Agent A, on the other hand, maintains a small cache of the pages currently requested by the user in the transformed and “ready-to-deliver” form. The actual content page may be split into several “device” pages depended on the capabilities of the user’s device. The splitting, caching and delivery of the content to the user device is done in parallel. In our implementation, we observed that by the time the user reads the first part, the resulting pages have been all split and cached. The next intake by the user is already cached and sized according to the device profile. Agent B and Agent A can collaborate in further optimizing the caching process [16]. Summary: To summarize, this component is made up by two mobile parts (agents) and is based on the client/agent/agent/server (for short client/intercept) [1] mobile computing model (fig. 4.8). On the server side we have the agent (agent B) that reforms the navigation between the nodes, and on the client side the one (agent A) that reformats the final results. Agent B moves in order to follow the requests of the user while agent A moves to follow the user himself. The first part (agent B) materializes the personalized portal in a step wise fashion while the second part (agent A) transforms the content provider nodes in a form that can be processed by the user’s device. Both agent support caching so to optimize the materialization and delivery process. Agent B follows the user requests (i.e. visits the content providers), while agent A keeps close to the user thus minimizing network traffic and latency. Agent A and B can collaborate to further optimize their tasks [16]. It is worth noting that as in the case of the Description Component, the Content Reform component must be able to understand the syntax of the content node. To satisfy this it is advisable for the content provider to describe its content in a standardized language. The easiest (and probably the best) way to define such a language is through the use of XML [6]. With XML it comes easy to transcode between various dialects.
4.5 mPersona and the Personalization Problem. Section 3 presented the various issues of the personalization problem. Having already presented mPersona, in this section, we show how our proposal satisfies these issues. Before doing this, lets see a flow of the system so to better associate the various issues to mPresona’s components. Figure 4.10 presents a complete flow and interactions of the various components in serving a users request who is trying to access the particular content provider. Server Content provider
1,3.
Internet 7.
Content description & Selection components
8.
Agent B of the reform component
6.
9. Agent A of the reform component
5. *. *Initialization
Client
4.
2.
Entry point & User profile management component
Figure 4.10: Graphical representation of the architecture’s components in action. 1.
Registration of the content provider. The Content Description and Selection components wrapped as mobile agents are sent to the content provider where they park. These components are initiated asynchronously, before any client activity.
2.
Registration of the client. Agents A and B of the Reform Component are created. They contain the device and theme profile associated with the client respectively
3.
The Content Description component crawls the content’s provider data and creates the Metadata Tree.
4.
The client requests a node from agent A. If this is the first request, it can only be the homepage of a particular provider.
5.
The request is passed on to agent B.
6.
If not already done, agent B delivers the theme profile to the Content Selection component and receives the Selection Tree. This is done once, on the first request of the client.
7.
Agent B pulls the relevant content node and modifies it according to the Selection Tree. It transforms the node to contain only the interesting links discarding the rest, i.e., materializing part of the personalized portal.
8.
Agent B returns the navigationally modified node to agent A.
9.
Agent A reforms the received content node based on the device profile and returns it to the client.
•
What content to present to the user? The collaboration of the Agent B, which carries the users profile and the Selection Component, delivers an optimized personalized portal to the user totally based on its profile. The content is presented to the user in an optimized form (via the agent A), in an optimal manner (i.e., with
minimal clicks) and while taking into consideration the semantic relation between items of interest. To this end, we utilized a thesaurus of theme topics to fully enrich the description of each node of the contents providers tree and relate it to the user’s profile. •
How to show the content to the user? The collaboration of agent A and agent B allows agent A, which carries the current device’s profile, to format the results of a user’s request into an appropriate form. Agent A, being private to the user, can in addition, handle any other required transcoding.
•
How to ensure the user’s privacy? Agents A and B of the Reform Component carry the device and theme profile associated with the current user respectively. Hence we are able to move around the user profile without actually allowing access to it by the various content providers. Only system components have access to the two parts of the profile, thus, improving the user’s privacy. The content provider does not have access to any information related to the user. In fact, the content provider is the one that must allow access to its content so that the Content Description component could derive the Metadata Tree.
•
How to create a global personalization scheme? Within mPersona there is no need for the user to repeatedly define her profile while visiting various sites. Agent B carries the user profile, which is defined only once, and delivers it whenever the agent visits a new content provider. Agent B resides on the fixed network, representing the user, and is independent of the type of the mobile device the user uses at any particular moment. Agent A on the other hand senses the mobile device and smartly employees the appropriate device profile.
5. Extensibility of the Architecture The component-based structure of our architecture allows us to change or replace the various components without further propagating other changes. This level of “componization” is largely due to the fact that our basic building blocks are mobile agents. Indeed, the very nature of mobile agents and their object orientation offers a high degree of independence and flexibility. We can add new components in our architecture just as easily. An obvious extension would be the incorporation of a mobile agent (component) that utilizes the off-line time of the client; asynchronicity is one of the main virtues of mobile agents technology. Its functionality could include
(without been limited to) prefetching, caching or the controlled materialization of the users private wireless portal, in essence extending the capabilities of step 4 of figure 4.10. Figure 5.1 shows an updated design of our approach and the next step in our future work. Furthermore, we can add components that visit the participating content providers in order to gather and process user’s historical data to aid prediction on future demands. Yet another possibility is the incorporation of a communication standard to enable linking with other personalization systems. That would result in the building of a personalization meta-system that could benefit from the combination of their strong points. Internet Content provider
Description
DB tree
Selection tree
Content selection & description components
Content reform component Agent Β Agent Α
Prefetching & Precaching
Entry point & User profile management component
Result
Client
DB
Figure 5.1: Extensibility Example. The utilization of agents as independent building blocks has a significant effect regarding extensibility. We can update the implementation of any of the above components without effecting in any way the operations of the other components. We can even remove some of the components without operational changes. For example, if we removed the Content Selection component the system would still continue to function without any problem. Of course the functionality will not be quite the same. Similarly, we still get a functional system if we remove agent B from the system, it will still function utilizing the device profile only; no user profile is utilized.
6. Advantages of the Use of Mobile Agents Mobile agent technology has been proven quite suitable for wireless systems [1, 2, 4]. This is due to the fact that mobile agents are excellent for asynchronous communication and execution (e.g., the creation of the Metadata Tree, the creation of the personalized portal (or Metadata Tree)), for mobility (e.g., having agents A and B to follow the user and the user’s request respectively, in fact agent B can transfer the
user profile to the various destinations asynchronously as needed). The effects of intermittent connectivity, an ever present characteristic of the wireless environment, can be significantly minimized via the collaboration of agent B and agent A. Mobility can be used to dynamically set up and configure the various players of the system; the content selection, the content description and the content reform components can all be set up dynamically and asynchronously. A less obvious advantage is the increased protection of the user’s privacy. Keep in mind that the user-profile data remains within the mobile agents of the system, blocking the provider’s direct access to them. As mentioned in section 4.4 the profiles (theme and device) of the user are carried by agents A and B of the reform component and are accessible only through them. Even further, no parts of the user’s profile are delivered to the content provider. The content provider has no way of legally accessing the users’ profiles as, for example, in WINMOB Technologies [17] or YOURWAP.com [18].
7. Metrics, Prototype and Experiments Our prototype implementation is a personalization system for WAP [5] services. Our system is not tied to any particular protocol and can be used long after WAP is gone. In fact we used the system for HTML or XML based content hierarchies without the need for any changes to the prototype. The implemented system utilizes multiple communication technologies such as Bluetooth and cellular connectivity. In this experimentation we utilized the content of a real content provider1 with more than 30 services and with a service hierarchy that contains more than 5500 nodes. Metrics: Being a new environment is always prudent to defined appropriate performance metrics. The “click count”, the “cost” (namely the size of the network traffic), and the “choice factor” were selected as the most suitable ones. While the first two are sort of known, the third one brings in a new dimension, namely the time the user takes to decide for the next link/click. This is not directly measurable but indirectly affects the overall performance. One might relate it to the number of provider choices at each level. •
The “click count”. The number of links that the user must follow in order to reach the desired content.
1
WINMOB Technologies is a wireless service provider residing in Cyprus
•
The size of the network traffic. The size of the content delivered over the wireless link. This is especially important as the wireless link is very slow and often a bottleneck.
•
The “choice factor”. The time the user needs to navigate from one node to another. This depends on the number of options the user has as well as the confusion produced by these options. By eliminating undesired options we keep the confusion to a minimum and thus speeding the process of finding the desired link.
Configuration: For the Bluetooth implementation we utilized both the iPAQ 3970 and the siemens LOOX PDAs. For the cellular connectivity we utilized GSM and GPRS connectivity. The tests, however, were concluded
Service entry
using the Nokia Mobile Internet Toolkit, which accurately
Cuisine type
emulates a real WAP client. A content provider’s data was used for our measurements. Without any loss of generality and to contained the experimentation we tested a single service with a large hierarchy and a large amonut of data. The tested service was a restaurant information service with almost 2200 leaf nodes and a hierarchy of up to 5 levels
Restaurant location (provenance) Restaurant location (area) Restaurant information
Figure 7.1: Provider’s Content Hierarchy.
(Fig. 7.1 shows the hierarchy). Scenarios: For our experimentation we came up with two testing scenarios (effectively, two different user profiles), one that would produce a “wide” Selection Tree (many different branches - scenario A) and one that would produced a “deep” Selection Tree (few long branches - scenario B). These user profiles contained the following keywords, for scenario A {restaurants:vegetarian, cuisine:vegetarian, [current location]} and for scenario B {food:chilli, cuisine:mexican, [current location]}. These scenarios were tested both with and without our system. The performed test was very rigorous. We have evaluated both, the “click-count” and the “cost” metrics for EVERY possible selection produced from the user’s profile. In essence, we collected all the qualified restaurants from the profile and accessed each one of them with and without our system. Figure 7.2 presents screen shots of the user’s device using the personalization system for the restaurant service. Note that figure 7.2:B.2 shows the users selection tree, i.e. his personalized portal.
Part A
The user needs to navigate through five screens of information before reaching the requested info (i.e., La Scala vegetarian restaurant) without personalization (the above screenshots, part a), whereas with the use of our system it only takes two (the below screenshots, part b). The shaded menu entries show the flow.
Part B
Figure 7.2: A Flow of the Personalization System. The user request is “the Nearest Vegetarian Restaurant, the chosen restaurant is “la scala”. The screenshot b.2 shows the reduced selection tree.
Considering that the location of a user is part of his profile and that the wireless infrastructure (or the content provider) supports location management and service, we included in our testing the factor of “locality”. Thus, by knowing the location of the user beforehand, we can further trim the Selection Tree based on the locality of the content. Experiments:
We
performed
the
following
comparisons,
(1)
“without
personalization” versus “with personalization”, (2) “without personalization” versus “with personalization including the exploitation of the locality factor” and (3) “with
personalization” versus “with personalization including the exploitation of the locality factor”. As shown in the following graphs we present the best, the worst and the average case of the “personalization effect” on the service (min, max and avg. respectively). Graph 7.1 (i.e., scenario A) shows that with no personalization every selection requires 5 clicks while with personalization the average case is reduced to 3,75 clicks and further reduced to 3 clicks when we exploit the locality factor. Similarly, the graph of the network traffic metric shows significant reduction with personalization. A similar analysis applies for scenario B as well (Graph 7.2). Them e profile A Netw ork traffic metric
T heme profile A Click count m etric
8000
6 5
5
4
Size (in bytes)
5 Click count
7301
7000
4
3 2
2 5
1
3,75
2 3
6000 5000 4000
3757,4
3000
3494 2818 2923,05 2391,7 2101 1831
2651
2000 1000
0 No pers. Avg
W ith pers.
0
W ith pers. & locality
Min
No pers. W ith pers. W ith pers. & locality Min
Max
Avg
Max
Graph 7.1: Scenario A.
Theme profile B Netw ork traffic m etric
T hem e profile B Click count m etric 6
2500
5
4 3
3
2
2
1
5
2,92
2 2
Avg
W ith W ith pers. pers. & locality Min
2748 2701,46 2654
2000
2450 2194,77
1798
1500
1607 1605,5 1604
1000 500
0 No pers.
Size (in bytes)
Click count
5
3000
Max
0 No pers. Min
Graph 7.2: Scenario B
W ith pers. W ith pers. & locality Avg
Max
Our analysis clearly indicated a significant benefit from the use of our system. The improvement achieved ranges from 33% to, for certain metrics, 60%. We also see that the locality factor plays a crucial role on location-based services. One important observation is that the second scenario presents a much better performance improvement. This is attributed to the type of the Selection Tree: In the first scenario we have a “wide” Selection Tree with many different sub-branches and this, in general, reduces the number of unneeded inner nodes which in turn, hampers performance. In fact, it minimizes the effect of step 3 of the Selection Tree algorithm.
8. Related Work To our knowledge, personalization approaches that focus explicitly on the wireless Internet and its specificities are quite limited. The widely known work appears within the fixed network and is Internet based. In all approaches, none of them utilizes mobile agents. This is understandable since not much work has been concentrated on mobility and wireless connectivity. Trends, however, in the direction of the mobile user and the wireless internet are rabidly gaining attention. In the wireless internet we have a couple of interest approaches. PSE [46] in one such approach. PSE identifies the need to have various profiles that encapsulate data about the users, services, networks and devices. It discusses service adaptation based on the various profiles and identifies the service discovery as another interesting problem. PSE is serviced based, in that it mainly aims to find services based on user profiles and adapt them to the terminal device. A similar concept as mPersona but from a different point of view (services versus information data) and not focus on the wireless internet and wireless content provider per se. PSE is still under development and it is still unclear how all these issues will be handled. A clearer approach but with a much narrower scope is the one presented in [48]. Its aim is to find an efficient way to use Internet directories (e.g. Yahoo!) from mobile devices (PDAs to be more precise). The personalization is achieved through a subscription scheme which significantly reduces the data volume of the directory and so the data can be stored on the PDA itself. Issues as synchronization and user preference updates are also addressed. Within the Internet world we have a vast amount of approaches. These are mostly based on AI concepts with a number of them utilizing static agents. Approaches closer
to our system are ARCHIMIDES [47] and Proteus [8,9]. “ARCHIMIDES” is (static) agent based and aims to personalize a web server’s content by rearranging the navigation inside the web server’s content. It achieve this navigation rearrange in a similar fashion to our approach. The structure of the web server is represented by a tree where each node corresponds to a web page and is associated with a set of keywords in order to match it with the user’s preferences. The similarities to mPersona, however, end here as the “ARCHIMIDES” system focuses on Internet web servers and users without any personalized and device portals are created. Similarly, “Proteus” is a system that creates models for each user (using AI techniques) for the purpose of adjusting the nodes of an Internet site to the needs of that specific user. This adjustment is made by rearranging the order in which pieces of information are presented in the resulting page. Furthermore, it has the ability to reorder or remove links to other pages. This last point is very similar with our approach except that we don’t reorder the information within the page. We do, however, perform a multiple level tree restructuring. The support provided by
Proteus to mobile devices is
achieved only with the reduction of the content and not its adaptation to the device characteristics. Other approaches based on static agents are presented in WBI [10,12] and BASAR [13]. The difference with our approach, besides the flexibility provided by the use of mobile agents, is the operation mode. WBI works by using several plugins, which must be at the client’s machine in order to automate general browsing tasks that the user would perform on his own. BASAR is a similar system that manages and updates the “personal webspace” which is created by the user’s bookmarks collection. Siteseer [39] is another system that is based on the user’s bookmarks analysis in order to predict and suggest relevant, possibly interesting Internet sites. Another interesting approach is the use of “theme profiles”. A profile holds the theme interests of the user and the biggest problem here is the management of this profile. [43] is a subsystem of the SiteSeer services that uses profiling. In mPersona we utilized the idea of the “thematic profiles” leaving, however, the heavy specifics as implementation details. Another approach is the analysis and modeling of the user in order to predict his future moves. [42] and [44] describe two such systems that incorporated machine learning and artificial intelligence techniques respectively. The first describes a system that recognizes user behavioral patterns and predicts the user’s future moves.
The later focuses in harvesting and managing the knowledge that comprises the user profile. Modeling the user through rule discovery and validation is another approach. The 1:1Pro [40] system is a representative of this category, and uses data mining techniques to achieve its goal. Yet another approach, is the exploitation of histories in order to reduce the results of information retrieval. Haystack [41] is a system that gathers the transactional history of the user in order to discover knowledge that will be used to limit the results of information retrieval to only the most interesting information. While we do not include such methodologies in the prototype of mPersona, its component based architecture, can easily, accommodate such additions. Finally, another approach is the one followed by the eRACE [45] system. eRace is a prefetching and precaching system that further personalizes the user related results. It utilizes user profiles (written in XML) to search the Internet for possibly interesting nodes. Afterwards it downloads all the potentially interesting nodes presenting them in a uniform fashion. eRACE searches to HTTP, NTTP, SMTP and POP3 sources. The scopes of mPersona and eRace are quite different.
9. Conclusions In this paper we have presented a flexible personalization architecture for Wireless Internet based on Mobile Agents. The system utilizes mobile agents as the fundamental building block and in doing so capitalizes on a number of specific to mobile agent-technology advantages. Some of them being the following: (1) Flexibility and independence between the various components, (2) Asynchronous communication and execution (e.g., the creation of the Metadata Tree, the creation of the personalized portal), (3) Mobility (e.g., by moving the user profile asynchronously as needed), and (4) Increased protection of the user privacy. A unique approach is presented for the dynamic creation and utilization of the user’s personalized portal. We demonstrated the transformation of the content provider’s Metadata Tree into the user’s wireless personalized portal (i.e., the selection tree) based on a user profile in a step by step manner demonstrating the minimization of clicks and choices. One other important strength of our approach is flexibility. Being component based we can easily extent our architecture by adding new components as necessary. Furthermore, this flexibility allows us to split the user profile in two: the theme profile and the device profile. Wireless Internet makes the existence of a device profile a
necessity. The incorporation of the device profile in the design of our architecture relieves the content provider from the necessity to handle different devices as this is now done by the personalization system. Finally, the prototype shows proof of concept with its viability as well as its promising results during our tests. Our performance evaluation indicates significant improvement over the traditional with no personalization approach. Initial results show improvement that ranges from 30% to 60% dependent on the profile. We do expect these figures to fare even better once we incorporate better profile management algorithms in our architecture.
10. REFERENCES [1] Evaggelia Pittura and George Samaras. Data Management for Mobile Computing. Kluwer Academic Publishers, 1997. [2] C. Harrison, D. Chess and A. Kershenbaum, “Mobile Agents: Are they a good idea?”, IBM T.J. Watson Research Center, Yorktown Heights, New York, March 1995. [3] D. B. Lange and M. Oshima. Seven Good Reasons for Mobile Agents. Com. of the ACM, 42(3):88-91, March 1999. [4] G. Samaras, E. Pitoura and P. Evripidou, “Software Models for Wireless and Mobile Computing: Survey and Case Study”. TR-99-5, University of Cyprus, March 1999. [5] WAP Forum, Tech. specifications, http://www.wapforum.org [6] T.Bray, J. Paoli and C. M. Sperberg-McQueen. Extensible Markup Language (XML) 1.0 Specifications. World Wide Web Consortium, http://ww.w3.org/TR/Rec-xml [7] Composite
Capabilities/Preference
Profiles,
World
Wide
Web
Consortium,
http://www.w3c.org/Mobile/CCPP/ [8] Corin R. Anderson, Pedro Domingos, and Daniel S. Weld. “Adaptive Web Navigation for Wireless Devices.” In Proceedings of the 17th International Joint Conference on Artificial
Intelligence (IJCAI-01). 2001. [9] Corin R. Anderson, Pedro Domingos, Daniel S. Weld. “Personalizing Web Sites for Mobile Users.” In Proceedings of the 10th Conference on the World Wide Web, 2001.
[10] Paul Maglio and Rob Barrett, Intermediaries Personalize Information Streams, Communications of the ACM, Vol. 43(8), pages 96-101, August 2000. [11] Eugene Volokh, Personalization and Privacy, Com. of the ACM, Vol. 43(8), pp. 84-88, August 2000. [12] Rob Barrett, P. Maglio, and D. Kellem. How to Personalize the Web. Proc. CHI 97. [13] C. Thomas and G. Fischer. Using agents to personalize the web. In Proc. ACM IUI'97, pages 53--60, Orlando, Florida, USA, 1997. [14] Cingil, I., Dogac, A. and Azgin, A., A Broader Approach to Personalization. Communications of the ACM, Vol. 43(8), pages 136--141, August 2000.
[15] George Samaras, Constantinos Spyrou, Evaggelia Pitoura, Marios Dikaiakos, Tracker: A Universal Location Management System for Mobile Agents. Proc. The
European
Wireless 2002 Conference, Next Generation Wireless Networks: Technologies, Protocols, Services and Applications, pp. 572-580, Florence, Italy, February 25-28, 2002. [16] Barron C. Housel, George Samaras, David B. Lindquist, “WebExpress: A Client/Intercept Based System for Optimizing Web Browsing in a Wireless Environment”. Journal of ACM/Baltzer Mobile Networking and Applications (MONET),
special issue on "Mobile Networking on the Internet", 3(4): 419-431, December, 1998. [17] WINMOB Technologies, web site: www.winmob.com. [18] YOURWAP.com, web site: www.yourwap/wml/index.wml. [19] Yahoo Mobile, web site: mobile.yahoo.com/home. [20] Bluetooth official membership site, www.bluetooth.org [21] D. Chess and B. Grosof and C. Harrison and D. Levine and C. Parris and G. Tsudik, Itinerant Agents for Mobile Computing, Journal IEEE Personal Communications, Vol. 2, No. 5, October, 1995. [22] J. E. White, Mobile Agents, General Magic White Paper, www.genmagic.com/agents, 1996. [23] Aglets Workbench, by IBM Japan Research Group. Web site: . [24] Recursion Software Voyager, web site: www.recursionsw.com [25] D. Wong, N. Paciorek, T. Walsh, J. DiCelie, M. Young and B. Peet. Concordia: An Infrastructure for Collaborating Mobile Agents. Lecture Notes in Computer Science, 1219, 1997. . [26] M. Breugst, I. Busse, S. Covaci and T. Magedanz. Grasshopper A Mobile Agent Platform for IN Based Service Environments. IEEE IN Workshop, Bordeaux, France, May 10-13, 1998. [27] Dag Johansen, Fred B. Schneider, and Robbert van Renesse. What TACOMA Taught Us. Also in, "Mobility, Mobile Agents and Process Migration - An edited Collection", Dejan Milojicic, Frederick Douglis, and Richard Wheeler eds., Addison Wesley Publ. Company, 1998. . [28] Robert Gray and David Kotz and George Cybenko and Daniela Rus. Agent Tcl. In William Cockayne and Michael Zyda, editors, Mobile Agents: Explanations and Examples, Manning Publishing, 1997. Imprints by Manning Publishing and Prentice Hall. . [29] M. Dikaiakos, G. Samaras, "A Performance Analysis Framework for Mobile-Agent Systems, "First Annual Workshop on Infrastructure for Scalable Multi-Agent Systems, The Fourth International Conference on Autonomous Agents 2000, ACM, Barcelona, June 2000. To appear in Lecture Notes of Computer Science. [30] Samaras G., Dikaiakos M., Spyrou C., Liberdos A., “Mobile Agent Platforms for WebDatabases: A Qualitative and Quantitative Assessment”, The Joint Symposium ASA/MA'99. First International Symposium on Agent Systems and Applications (ASA'99). Third International Symposium on Mobile Agents (MA'99), pp. 50-64, USA, 1999. [31] D.B. Lange, M. Oshima, Programming and Deploying Java Mobile Agents with Aglets, Addison-Wesley, 1998. [32] G. Samaras and P. Evripidou, E. Pitoura, “Mobile-Agents based Infrastructure for eWork and eBussiness Applications”, The eBusiness and eWork Conference, 2000 [33] C. Spyrou, G. Samaras, E. Pitoura, P. Evripidou , “Mobile Agents for Wireless Computing: The Convergence of Wireless Computational Models with Mobile-Agent Technologies”, Journal of ACM/Baltzer Mobile Networking and Applications (MONET), special issue on “Mobility in Databases & Distributed Systems ", 2000. (to appear) [34] G. Samaras, A. Pitsillides, "Client/Intercept: a Computational Model for Wireless Environments", Proc. 4th International Conference on Telecommunications (ICT'97), Melbourne, Australia, April 1997.
[35] S. Papastavrou, G. Samaras, E. Pitoura, Mobile Agents for WWW Distributed Database Access, Proc. 15th International Data Engineering Conference, p228-237, Sydney, Australia, March 1999. [36] A. Pitsillides, G. Samaras, M. Dikaiakos, E. Christodoulou, DITIS: Collaborative Virtual Medical team for home healthcare of cancer patients, Conference on the Information Society and Telematics Applications, Catania, Italy, 16-18 April 1999. [37] M. Dikaiakos, D. Gunopoulos, FIGI: The Architecture of an Internet-based Financial Information Gathering Infrastructure. In Proceedings of the 1st International Workshop on Advanced Issues of E-Commerce and Web-based Information Systems. IEEE-Computer Society, pages 91-94, April 1999. [38] Y. Villate, A. Illarramendi, and E. Pitoura, “Data Lockers: Mobile-Agent Based Middleware for the Security and Availability of Roaming Users Data”, In CoopIS Israel, September 2000. [39] Rucker, J., Marcos, J.P., Siteseer: Personalized Navigation for the Web, Communications of the ACM, pp. 73-75, Vol. 40, no. 3, March 1997. [40] Adomavicius, G. and Tuzhilin, A. "User profiling in personalization applications through rule discovery and validation." KDD-99, 1999. [41] E. Adar, D. Karger, and L. Stein. Haystack: Per-user information environments. In Proceedings of the 1999 Conf. on Inf. and Knowledge Management, CIKM, 1999. [42] Haym Hirsh, Chumki Basu, and Brian D. Davison. Learning to personalize. Communications of the ACM, 43(8), Aug 2000. [43] Kurt Bollacker, Steve Lawrence, and C. Lee Giles. A system for automatic personalized tracking of scientific literature on the web. In Digital Libraries 99 - The Fourth ACM Conference on Digital Libraries, pages 105--113, New York, 1999. ACM Press. [44] Sung Myaeng and Robert Korfhage. Towards an intelligent and personalized information retrieval system. Technical Report 86--CSE--10, Dept. of Computer Science and Engineering, Southern Methodist University, Dallas, Texas, March 1986. [45] M. Dikaiakos, D. Zeinalipour-Yazti, "A Distributed Middleware Infrastructure for Personalized Services," Technical Report TR-2001-4, Department of Computer Science, University of Cyprus, December 2001. [46] M.M. Lankhorst, H. van Kranenburg, A. Salden, A.J.H. Peddemors, “Enabling technology for personalizing mobile services”. Proceedings of the 35th Annual Hawaii International Conference on System Sciences HICSS, p.1107 -1114, 7-10 January 2002 [47] N. Bogonikolos, D. Fragoudis, S. Likothanassis, “ARCHIMIDES”: an intelligent agent for adaptive-personalized navigation within a WEB server. Proceedings of the 32nd Annual Hawaii International Conference on System Sciences, HICSS-32. Volume: Track5 , 5-8 Jan. 1999. [48] Doron Cohen, Michael Herscovici, Yael Petruschka, Yoëlle S. Maarek, Aya Soffer, “Personalized pocket directories for mobile devices”. Proceedings of the eleventh international conference on World Wide Web, p. 627-638, isbn 1-58113-449-5, Honolulu, Hawaii, USA, 2002.
