Adaptivity for Multi-Platform Access to ... - Semantic Scholar

Information Valets: Adaptivity for Multi-Platform Access to Heterogeneous Information Sofus A. Macskassy, Aynur A. Dayanik, Haym Hirsh {sofmac,aynur,hirsh}@cs.rutgers.edu

Department of Computer Science Rutgers University 110 Frelinghuysen Rd Piscataway, NJ 08854-8019 Abstract This paper introduces the concept of an Information Valet (“iValet”), an approach for combining multi-platform access to heterogeneous information with adaption to user preferences. The goal of an iValet is to support access to a range of information sources from a range of wired and wireless client devices with some degree of uniformity. An iValet should be aware of its user and user devices, learning from a user’s past interactions where and how to send new incoming information. Our metaphor is that of a valet that sits between a user’s client devices and the information services that the user may want to access. This paper describes a prototype iValet that interacts with its user through both the Palm VII “Web-clippings” service and the RIM 950 two-way email-capable pager, providing access to email, Web pages, and personal files. We discuss general issues raised by our work concerning the more general design of an iValet, and present initial results concerning the ability of machine learning techniques to successfully inject adaptability into our iValet system.

Information Valets Imagine that while walking to lunch, your mobile phone rings and tells you to turn on your Palm VII and connect to the ABC news site because there is an important story regarding a stock in your portfolio. Or on your way to a meeting, you receive a message on your pager telling you the meeting has been moved to another location. Compare this with commuting home and receiving an email message on your pager from a coworker with a monthly reminder to use the recycle bins at work. Some messages would likely be more relevant to you at a particular point in time than others. It would be nice if we could automatically decide which information to send to a user. Furthermore, we would like these decisions to be transparent to the world and, to the extent possible, the user. For example, it would be desirable to have a single, centralized location where all information is sent and gathered. A software agent residing at that location could then forward each piece of information to where the user would like to read it. Ideally, this agent would work in a way much akin to a secretary, knowing where the user is and knowing which information to send to the user on a particular device. Finally, with the agent residing at and accessing all information from a fixed location, the agent can perform additional information services, such as to send files, memos, email, or faxes to a printer at work, or even directly to another user. We call such an agent an Information Valet, or iValet, in that it provides “valet”-like functionality to help users manage their information. The structure of an Information Valet has three main components: the Front End interacts with a user’s client devices,

knowing how to present information to each device; the Back End interacts with the various information resources that may be of interest to a user, knowing how to interact with and retrieve information from each information source; and the iValet Core, which provides the glue between the front end, back end, and, ultimately, the iValet user, maintaining information about the capabilities and characteristics of each client device, the nature of each information source, and, finally, relevant aspects of its user, which includes its current estimate of a user’s interest, based on past user interactions. In more detail: Front End The front end is the component of the iValet that is capable of presenting information to any of a user’s available client devices. Its duties arise when a particular piece of information must be delivered to a particular device in a particular fashion. Thus, for example, it may need to deliver an image-laden Web page to a bandwidthlimited or low-resolution client device by removing the Web-page images. The front end must potentially be able to transform or filter information to make it appear in a usable fashion for that device. Its execution may depend on device characteristics, such as screen size, whether the device can display graphics or play audio, or has limitations on the size of information it can receive. It is the conduit for information about time-dependent aspects the devices to the iValet core, such as, for a wireless palmtop device, battery life or whether it is currently turned on and in service. The front end can be thought of as a set of modules, each for a different device. If a user has multiple devices of a single type (say, multiple pagers), the code of the module may be the same for the two devices, but we conceptually view this as two separate modules, reflecting the two different devices. Finally, our model is of a front end that is extensible in a simple fashion — new devices should be able to be added as a new module in a “plug and play” mode of operation. One logical approach this suggests is for the front end modules to communicate with the core using a standard communication bridge in the form of a public API. Back End The back end knows how to obtain information from a particular information source in a particular format. We don’t a priori constrain the nature of an information source, which may include email, news stories, stock information, personal files, Web pages, etc. Furthermore, the back end will generally understand the format of each information source, so it can parse the information into its salient parts. For example, for the medium of email we

would anticipate the back end understanding that a message may have headers, a textual body, and attachments. Mirroring the conceptualization of the front end, we view the back end as a set of modules, each for a different information source. If there are multiple sources of the same general type — such as email via two different email accounts — even though the code may be identical, we view them as separate modules, reflecting the different sources. Once again, new information sources should be able to be added in an extensible, “plug and play” fashion, where the back end may be structured to interact with the core using a standard API. iValet Core The heart of an iValet lies in the iValet core. The core knows about the user’s devices, available information sources, as well as about various aspects of the user, potentially both in his or her current circumstances, as well as over a longer term. It does not worry about details of retrieval or display, but rather its main concern is all decision-making that occurs about whether to deliver an item of information to the user, and if so, where and how to deliver it. In making these decisions it may maintain knowledge about the user’s devices (such as both capabilities and local state), the information sources, and the user’s preferences through some form of user model. This user model may be either explicitly specified by a user, or implicitly inferred through the user’s past interactions, which can be categorized as either implicit user feedback (passive watching) and explicit user feedback (the user explicitly informs the iValet about good and/or bad decisions it has done). Ultimately, the iValet core takes available information items, and decides which to deliver, where to deliver them, and how to deliver them based on the information to which it has access. In the remainder of this paper we first describe the current status of an iValet being developed at Rutgers. Its back end is able to handle email, Web pages, personal files, as well as actions on these items, such as sending them to a printer or forwarding them to other users. Its front end can interact with two forms of wireless platforms, ones that provide email services to their users, and those that provide a form of Web browsing for its users. In either case, the iValet hides the fact of the use of these devices to the outside world, which sees only one point of entry for communicating with the user; namely through the iValet. We then discuss issues that arise in the creation of an iValet, in terms of being able to add new front-end and back-end modules in a seamless fashion, as well as for an iValet to be able to model its user. We ground this in terms of the Rutgers iValet, discussing our ongoing work on how to inject adaptability through standard machine learning techniques, extending the iValet to a greater range of information sources, client devices, and additional functionalities.

The Rutgers iValet Our development of a functional information valet has involved the creation of the Rutgers iValet system. This iValet resides on a Unix system. It has two front end modules, one to an email-capable wireless device, the second to a wireless device with Web-browser-like capabilities. Through its three back-end modules it provides its users with access to email, files, and Web pages. At present the iValet core is rather primitive, passing along explicit user requests for information, plus providing inter-operability across client de-

vices accessible via the iValet front end. The rest of this section describes each of the Rutgers iValet components in more detail.

RIM 950 Front End The email front end was designed for RIM 950 two-way pagers provided by BellSouth Wireless Data. The RIM device is a small pager with a ’qwerty’ keyboard and an 8 by 30 textual screen. The services available to users of this device include sending and receiving text messages both through BellSouth’s proprietary Inter@active Paging ServiceSM service, as well as to and from arbitrary internet email addresses. Messages may only be up to 16Kb in size, and each device has 1Mb of memory in which saved email resides. These devices have been in use by the three authors for a period of over 16 months. Although created specifically for this platform, the email front end is structured to handle any device that provides email capabilities to its users, thereby being usable by frontend modules for other user devices whose primarily functionality consists of email. As should become clear, it also assumes that the iValet software resides on the same machine that services the user’s primary email address. Since the BellSouth service provides the device with its own email address, our front end was designed so that email from the device is always addressed to the user’s own regular email account, where the Rutgers iValet resides, so that it can repackage the email for sending to the intended recipient so that it appears to come from the user’s main email account. In more detail, we exploit two lesser-known features of the email RFC. This first states that any email sent to an address huseri+string@hhosti should be delivered by hhosti to huseri for any alpha-numeric string, maintaining the To field as huseri+string@hhosti. The second feature is simply that the sender of a message can override the default behavior of the reply function of an email system by including a Reply-To field. Rather than sending a reply to the address in the From field of a message, replies will instead be sent to the address found in that message’s Reply-To field. There are two key ideas to the email front end. The first is to set the Reply-To field of every message to an address that sends the resulting message to back to the user’s own account, to be accessed by the iValet system. This has the effect of letting the user see the original message — including its From field — as it was received by the iValet back end, yet redirect any replies to that message back to the iValet, rather than side-stepping the iValet and delivering email directly from the client. The second key idea is to communicate information, such as state, by by adding an ID string to the user’s address within the Reply-To field using the “+” email feature. Each message forwarded to the user is given a unique ID that is postpended to user’s email address in the Reply-To, in the form of huseri+email-ID@hhosti. In this fashion, whenever the user replies to a message the iValet receives the reply, and furthermore can identify to which message it refers. Initially the iValet only sends the headers of each message to the user. If an empty reply is received for this message (i.e., a reply is sent back to the iValet through the Reply-To field including that message’s ID) the iValet delivers the full message to the user (or the initial part of it up to the device’s maximum email length of 16K). A nonempty reply to this message is received by the iValet and repackaged and sent out

Palm VII Front End Our second, Web-style front end was designed to operate with the “Web clipping” service provides with the Palm VII wireless PDA. These devices support a constrained form of the HTML language, with the addition of being able to support the device ID as an optional argument to any requested URL. This front end resides at a Web server, and as such is invoked only by an explicit user-initiated request (as with any Web browser). Users connect to the iValet URL via an HTML page that resides on the Palm VII device. Information is delivered to the Palm device by converting it into HTML that is suitably formatted for this form of device. Requests from the user are obtained by connecting to the iValet URL through the iValet front page on the Palm VII, where values specified in this form are provided as parameters to the iValet URL and processed by the Palm VII front end. For example, one such parameter is “medium”, which identifies the medium of the requested information, in the current version one of email, file, or URL. Other parameters identify the specific information item, as well as the action wanted, which may include browse, mail, forward, print and delete. The front end passes the resulting request to the iValet core, ultimately returning with the desired response that it given back to the front end for delivery in a suitably formatted HTML page. This includes, for example, how many items to list at one time when the list of items is too large to be displayed if sent to the device. Other commands that are supported by this front end include searching and retrieving files based both the file name and file content; and forwarding of email and files to any of the other devices available to the user, information that is obtained from the iValet core. A example of the resulting Palm VII interface is shown in Figure 1. Once again, this module must reside and run on the Web-server machine.

Back Ends Figure 1: Palm VII screen

as if it had originated directly from the account at which the iValet resides. The RIM 950 device also has an address book that we initialize with “user names” such as “Get File”. Each such name is give an address of the form huseri+command@hhosti. When the user chooses to make a request of the iValet the user can select the appropriate entry in the address book, and the iValet receives the email, taking the string following the + as the command to be executed. This can, for example, include requests for retrieving a file (huseri+file@hhosti) or Web page (huseri+url@hhosti), where the desired file name or URL may appear in either the Subject field or body of the message. In summary, the email front end communicates with the user purely through normal email messages. It can act on requests by the iValet core by sending email headers to the user, or the full body of a message. It also receives requests from the user, via email to the user’s account where the iValet resides, recognizing them as coming from the email address of the email-capable client device, passing requests on to the core for further processing.

The back-end side of the Rutgers iValet uses fairly traditional server-side means for the iValet to access information sources. We only discuss these briefly here. The Rutgers iValet can retrieve email in two different ways. In the same fashion as Netscape, Outlook or Eudora do, email can be retrieved from an email server through POP3 as a pop-client. Since our iValet resides in a Unix environment, we also invoke the back-end email software through the use of an appropriately specified .forward file, invoking a script every time new mail arrives. Either way these back ends store a local copy of the email for later requests that may be made by the user. File requests and accesses are assumed to be for files available locally, on the same machine as the iValet. URLs are accessed using a suitably tailored Perl-script in Perl5 using the LWP, HTML and WWW mods.1

iValet Core Finally, the Rutgers iValet core, in its current state, is fairly modest. It maintains a list of devices and desired names for the devices in the form of device name=device email, as obtained from 1 Note that this architecture actually allows a wider range of functionalities, ranging all the way to executing requested user commands on the machine where the iValet resides. For security reasons we do not permit these and other insecure operations, only supporting actions that are of a non-destructive nature, including, in addition to those listed here, printing.

the user — so that the core knows the device name and relevant email address for each email-capable device that the user possesses. Furthermore, it has hard-coded constraints for the both Palm VII front end — such as that email messages should be presented five at a time, without consulting a more general user model to determine the suitable count and the RIM 950 front end — such as that messages must be truncated at 16K. (Clearly both of these constraints are simple enough to remove, although our efforts thus far have been spent elsewhere in system development.) The iValet core also saves important contextual information about the user and each email going through the RIM 950 front end. For example, for each email interaction, information is stored about the user’s current online status (idle-time on the user’s workstation, and whether the user is logged in), as well information on when the user last received (sent) email from (to) the sender of a new message and information on when the user last received (sent) email from (to) the sender of a message on that same subject. Although this information is not used at present, we anticipate its use in future revisions to the iValet core, and they form an important part of the adaptivity experiments on which we report later in this paper.

Front End Issues An iValet can make use of multiple devices, each having different characteristics and capabilities. For example, the user could have a pager that can send and receive email, is always on, but has a small and limited screen; a palm device that has graphics and a bigger screen, but is only on when the antenna is raised; and a mobile phone that can receive short one- or two-line messages through SMS (short messaging service). Each device has certain capabilities, contexts, and constraints to which the iValet should be sensitive. Further, by watching how the user makes use of each device, we would like the iValet to learn when and where to send new information. In this section we discuss three main areas of information that are important to know about a device in the creation of iValet front ends.

Device Connectivity Characteristics The nature of when and how an iValet can interact with a client device determines the actions available to the iValet — through its front end — with that device. For example, if the device is always on, and is able to receive information without asking first (e.g., is it push-capable?), then the front end is able to push new information to the device without user interaction. The RIM 950 is an example of such a device, as is any sort of platform with a short messaging service. However, if the device is intermittently connected or not push-capable, then the front end has to wait for the user to take action before any information can be sent to the device. The Palm VII is an example of such a device. As a second example, independent of whether a device is sporadically or continuously connected, bandwidth is an important factor on which the iValet can base its decisions on what, or how much, to send to a user via a device. If the device has a slow connection, it might not be feasible (or economical!) to send a 1Mb information item. More generally, the connectivity characteristics of a client device impact the iValet’s decisions about what and how to present information. For a device that is push-capable and currently on, the question may be structured as a binary decision, namely whether to send each piece of information.

For a non push-capable device, the question may be structured as a prioritization decision, determining a suitable order for delivering pending information items when the iValet is contacted, under the assumption that they are delivered upon each request, say, 5 items at a time, in decreasing order of priority. Finally, if the iValet is to learn how to make these decisions based on the user’s past interactions, the underlying learner is also ultimately impacted by these design decisions.

Device Capabilities What are the capabilities of the device in terms of presentation and storage? If the information contains solely otherwise uninterpretable audio or images and the device can only display text, then there is no reason to send the information (unless it can somehow be transformed into some suitable textual form). If an information piece is larger than the max item size of a device, then the information must be delivered in pieces in some fashion, or not sent at all. If the device has audio but no text capabilities (e.g., it is a non SMS capable cellular phone), then the front end should be able to convert text into audio. If the device does allow text, then what is the screen size? If the device is capable of showing graphics, at what screen resolution and at what color depth? If the device has local storage, then information could potentially be stored at the device, and the front end should support this. Other capabilities might include a yet wider range of concerns, such as whether the device includes infrared ports, which would provide the device with indirect access to other nearby devices, using a PAN (Personal Area Network), and processor speed, where information delivery may also consider device computational capabilities.

Device State A client device have many characteristics that change over time. For example, if the battery power is almost at zero, then the front end might try and either extract the most important part of an email, or send only the headers, to preserve the battery life; or the iValet might decide that the information is not important enough to further drain the battery, and not send it at all. If the device is not currently connected, the front end could so inform the iValet, so that information can be delivered via other means, for example. If there is a request to store information on the device and the remaining storage is not big enough, then this action should not occur. What is the price per byte for sending information to the device given its current connectivity? This real cost may be too great to warrant sending the information in its complete form. Each aspect of the device state can impact the method by which a user receives information via the iValet’s front end.

Back End Issues The second part of the iValet equation is the information that it accesses for its user. One approach to handling a range of information types is to convert them all into a single form — for example, into text — thereby reducing the iValet’s task to one of managing a single information modality. Clearly, though, not all information sources are easily transformable into a single format for subsequent processing. In the iValet approach, each piece of information, regardless of domain, is transformed into a set of feature–value pairs, where certain preset features have global semantics across all domains. For example, “author”, “medium”, “recipients”, and “length”,

all have make sense across all domains. If any two domains share a feature, then that feature should have the same name in both transformations. Part of the task for a back end module is then to be able to go to an information source, extract information pieces and transform them into these featurevalue pairs, which it can then give to the iValet core for local storage. Assuming that the back end can get at information sources and retrieve single information pieces, the main issue remaining is, for each type of information source, what are the features? Some examples include: Email : The salient features of an email message are apparent in its header. These can include the sender, the receiver(s) (to and cc), the subject, date, length (potentially two numbers: the textual size and the overall size, if the email contains binary attachments), and body of the mail. Aside from the intrinsic content of a message, there may also be “extrinsic” features regarding the context and history of the user’s email. This can include the last time the user received (sent) an email from (to) the sender and the last time the user received (sent) an email from (to) the sender on the particular subject. News Stories : News stories have an author, a title, a body, a date, and overall size of the item. It may also include information about the service providing the story, and information about included images. Newsgroups Articles : Newsgroups articles also typically have an author, a body, a date, and overall size of the item. It may also include other newsgroups to which the article was posted, and the history of postings in the discussion of which the article may be a part. Stock Quotes : There are a range of information that can be obtained concerning a particular stock. This includes information on the current stock price, volume, and past history. Files : Features that this could include is the owner of the file, the name of the file, its size, and of course its contents. The format of the information — especially if non-text — can also be available. Web Pages : The final domain we list is the Web. Information on the Web is less structured than many other forms of information, with the unstructured format of most HTML pages making it hard for any program to try and derive any features from the page itself. Even so, pages often have at minimum a text title, text body, URL, and a length.

The iValet Core The iValet core resides in the middle ground between the iValet’s front end and the iValet back end. At its most basic, the iValet should make use of multiple information resources to gather information, and through multiple devices, allow a user access to this information. The current Rutgers iValet core embodies this minimal functionality. The core also maintains information about the devices available to the user, allowing the commands available to each device to refer to other devices, information obtained from the core. In the long run, however, we envision a far more sophisticated core, where decisions about what to present as well as where to present it, are based on models of the information, the devices, and, we argue, the user as well. Both the information model and device model has been discussed as necessary in the preceding sections, in light of what the iValet

could do with these models. For example, the device model is mainly used as a profile of a device both about its capabilities and current state, which the iValet uses to decide on how appropriate it is to send information to a device, as well as what and how much information to send. Similarly, the information model maintains the characteristics of the various information sources available to the back end, for potential use by the core in determining how to satisfy users’ commands. In addition, if the iValet is to appear to make decisions personalized to its user, it needs to know more about the user and the user’s interests. This user model is closely tied to the information model. For example, a profile of a user’s interest will likely depend on the medium of the information — if it is textual versus images, for example. It also will depend on the nature of the domain of the information — the content of a user’s email may differ greatly from the new stories that the user reads. At minimum, the information maintained about the user should include the user model, representing what is known about the user’s various interests; the user context, representing information about the user’s current circumstance: where the user currently is, what the user is doing, the user’s current tasks and action items, etc.; and the available forms of user feedback appropriate for a given device or information sources, since this has a significant impact how the iValet will learn from its user. The remainder of this paper focuses on the challenges that are faced in adding such learning to an iValet, so we focus and expand on these user-level information items in the remainder of this section.

User Context What is important prior to a business meeting might not be as important if you are on vacation; what is important on the way home (i.e., picking up groceries) is not important when already home in bed at night. User context is clearly a function of the device and information being manipulated by the iValet. The user location seems to be a good feature to have, if possible. However, without a GPS module or some comparable special-purpose location-determining resource at best surrogates for this information can be used. For example, the iValet can maintain information on whether a user is online on known workstations and whether the user is idle, trying to get some sense of whether the user is at least on an online device or at the location where the device resides.

User Model The user model represents what is known about the user’s interests and possibly further in-depth knowledge about the user. This model can be explicitly provided by a user or learned implicitly through user feedback. Users typically have at least two levels of interests: long–term and short– term (Pazzani & Billsus 1997; Billsus & Pazzani 1999). What information should the user model store, and how? Furthermore, even if a given information item is new, its content may duplicate other already seen information, and thus it can be useful to maintain a model of what the user has already seen (Billsus & Pazzani 1999). Another distinction is the nature of the information on which the model is based. Content-based models refer to the specific content of each information item (such as the author or words contained within it). Collaborative models are typically based on a comparison of similarities between

users and information items, representing a given user’s decisions by the decisions of others that are somehow similar (Lashkari, Metral, & Maes 1994; Shardanand & Maes 1995), while newer types of models look into hybrid features, using both types of information (Basu, Hirsh, & Cohen 1998). A final issue concerning user models is that they may be device-dependent. Since each device has different capabilities and constraints, what is important on one device is not so important on another device. The user model needs to take into account not only the user interest, but also how this interacts with each device. For example, one device might be very costly to send data to, but also have many capabilities (bandwidth, graphics, etc.), while another device is slow and cheap. Where should information be sent? In a world where information access can occur from multiple devices, even for a single user, user models must now be specified for each of the user’s client devices, to help an iValet decide where a given information instance will be preferred to be seen, as well as which part of the information to send. It could even lead to sending a short one-line message to a pager or mobile phone to tell the user to turn on a palmtop and read email there, if the email is too big to read on the mobile phone/pager, but important enough to spend time and money to read it on the palmtop rather than wait until later.

User Feedback How the user interacts with the system impacts what can be learned about the user’s interests. User feedback at minimum may be gathered implicitly, inferred from a user’s regular information-manipulation actions, or explicitly, by requiring the user to perform additional interactions to aid the iValet in its tasks. In general most systems minimize explicit feedback due to the risk of disrupting a user too frequently. One midpoint is represented by the NewsDude (Billsus & Pazzani 1999), which learns from a user’s news story reading actions, but also allows the user to react to its news story prioritizations. Given the wide range of possible client devices and information sources, a great many interactions and feedbacks are possible. Implicit feedback can come from a range of information-handling actions, include whether the user wanted to read an item, implicitly stating that the item is important, or delete an item, implicitly stating that the item is not of interest. One subtlety is whether the deletion is for a particular device, representing that it is inappropriate for that device, or global, which means it is inappropriate for all devices. Other types of implicit feedback includes moving item to device, letting the iValet know that the information was preferred on another device, or skipping an item, if there is a list of available items and the third is chosen, then that was obviously of higher interest than the first two item. Even better is when explicit feedback can be obtained without overly burdening the user. Simple forms of explicit feedback about a user’s interests when accessing specific information items include strengthening a decision, discounting a bad decision, remove a certain decision-rule alltogether, or adding user-specified rules to the model.

Towards an iValet that Learns The main focus of the remainder of this paper lies in how we can inject machine learning techniques into the iValet to automatically learn user profiles based on user interactions. To explore possible approaches to this problem we performed a range of “off-line” experiments on recorded histories of the

users of the iValet. In this section we discuss design decisions in adding learning to an iValet, and present results of a range of learning methods and information sources in learning users’ actions specifically through the RIM 950 front end. The first question one must face in adding learning to an iValet is what needs to be learned and what learners are available for the task. This decision is impacted by the nature of the data on which learning is based — for example, whether the user gives implicit, only gross-level feedback by, say, choosing to read one email message and not another — and what the target of learning should be — for example, to assign a binary of-interest/not-of-interest label to a single item, or to prioritize a set of items. More generally, both user information “ratings” and the final decisions made by the results of learning, can take one of three forms: learning methods: Scoring : Each piece of information is given a score that represents how important or interesting this piece of information is to the user. This is the most detailed information that can be obtained about information items from a user. As such, it is the most desirable to obtain, but may not be realistic to gather given the structure of the user’s interactions with the iValet. Similarly, this would be the most detailed information that the results of learning could provide about items of information, which may not be feasible if only more limited feedback is obtainable from the user. Ordering : Many times it is unreasonable to force exact values on items of information. Calibration of values over time and across the scale is difficult and imperfect. A more modest expression of relative relevance of items of information consist of placing an ordering over the items, without imputing any scores to the items. Thus a user may be able to say that one item is better than another, but be uncommitted about the relative importance of two other items. Similarly, the learning system may need only to return a list of items, where scores of the items are unnecessary. The ordering over items may be total or partial. Classification : Finally, the weakest statement of preferences is a simple binary label of whether or not the item is of interest. An action taken by a user may give some sense of the user’s assessment of that item alone, without relating it to other items. Similarly, such a result of learning can be use to at least filter out undesirable items, even if they cannot be further prioritized. The goal of our work is to inject learning into the iValet, but the nature of desirable learning method depends on the nature of the information and devices. For the Palm VII we envision giving a user access to information in small numbers at a time, as befits its small display and billing charges, with higher-priority items delivered earlier. For the RIM 950 we envision only delivering items that are sufficiently desirable to the user, as a sort of notification method of an important item arriving for the user. To be able to handle both types of information-item assessments we plan to use a learning method that assigns scores to each item. For the Palm VII this would enable prioritizing items; for the RIM 950 this would allow specifying a numerical threshold, forwarding only those items whose scores exceed the threshold. However, the only feedback we will assume is available from the user is binary — whether or not the user chose to read an item. To explore the ability of current techniques to perform this task we carried out experiments with nine months worth of data gathered from the authors use of the RIM 950 pagers.

Run on HH data, window size: infinite. 100

Table 1: Dataset properties Size 2298 11034 1675

% of messages forwarded 27.08% 26.86% 16.78%

80

60 Recall

User AD HH SM

base naive bayes

40

Evaluation Table 1 shows the amount of data obtained for each user, and the proportion of email that each user requested to read on his or her RIM 950 device. Due to the large of size of our dataset, for each data-set, 500 random email messages were chosen. We then used all preceding instances in the data-set as training to score the given testinstance. The result is a score for each message. To evaluate these scores we compare the decisions that would result if only those over a particular threshold are delivered to the user. As this threshold is varied, a set of possible results are obtained. More specifically, we use the message score to create precision/recall curves. The precision of a classification method is the proportion of data that is labeled positive that really is positive. The recall of a classification method is the proportion of all truly positive data that are labeled as positive. In our case, the precision corresponds to the proportion of messages that were labeled as forward that really should have been forwarded, and the recall corresponds to the proportion of messages that should have been forwarded that were labeled forward.

Results Figure 2 shows a sample precision/recall graph; it allows certain conclusions to be made about the use of Naive Bayes in this domain.4 First, a very simple baseline approach is to forward all email to a user. This method yields 100% recall, but a precision that equals the proportion of messages that should be forwarded in the data (see Table 1). This baseline is represented by the vertical line in the graph. For all three users 2 We used a publicly available version of this learner that is part of the Rainbow (McCallum 1996) package. 3 In our experiments we have compared a range of standard text categorization algorithms. However, since they all performed comparably we solely report on the results for Naive Bayes, the learning method that is particularly well-suited to the sort of incremental learning that would be necessary in an iValet being used over an extended period of time. 4 Due to space limitations we only include prototypical graphs of selected users in this section.

20

0 0

20

40

60

80

100

Precision

Figure 2: Recall vs. Precision for Naive Bayes on HH data. Run on sofus data on method naivebayes. Compare context performace 100 all no online context no email context 80

60 Recall

From the user logs, two sets of email messages were created for each user, one containing those messages that the user chose to see, and a second that the user did not choose to see. The goal of learning was to assign a score new messages based on earlier messages. To do this we use a simple probabilistic learning method known as the Naive Bayes classifier (Domingos & Pazzani 1996).2 It uses Bayes’ rule to estimate the probability that a message will be read based on the prior probability of a category occurring, and the conditional probabilities of particular words occuring in a document given that it belongs to a category. The key simplifying assumption that makes it “naive” is that it assesses these probabilities assuming conditional independence of the words. Our first results focus solely on the words that appear in each message; later results evaluate the importance of this information and other information that can be used in the learning process.3

40

20

0 0

20

40

60

80

100

Precision

Figure 3: Effects of contextual features on SM data this default figure is met or, most often, surpassed. Further, we see that we can get a range of behavior from this scoring approach to labeling, having the opportunity to only forward a subset of messages, albeit at the risk of neglecting to forward desired messages to the user. Our further studies concern the use of information beyond solely the message’s words in the learning process. We would ideally like the learning algorithm to know where a user is — at home, work, in a car, etc. Although current client-platform technology does not make that available to the iValet, we instead use date and time as a (hopefully) helpful surrogate for such information about the message’s context (in contrast to its content). For example, if a person is typically at work certain times of day and days of the week this can be a cue for whether a user is at work, and thus may help the iValet learning process. To explore this question we did a second set of experiments to find out the effect of a number of contextual features in learning. To represent a user’s online context we allow learning to consider for each message “time since last read mail online”, “time since last being logged in online”, and “idle time online”; to represent an email message’s context we allow learning to consider “time since last received mail from sender”, “time since last sent mail to sender”, “time since last received mail from sender on same subject” and “time since last sent mail to sender on same subject”. We performed three sets of runs: one with all these features, one where all online context features had been removed, and one where all email context features had been removed. We then compared the precision/recall curves on the three runs. Figure 3 shows a sample run of this experiment, demonstrating the email context generally helps, whereas the use of user context is less clearly of benefit. Finally, it is not clear that the learner should have infinite “memory”. For example, perhaps going too far back in time

Run on AD data with method Naive Bayes on various window sizes. 100 100 500 infinite 80

Recall

60

40

20

0 0

20

40

60

80

100

Precision

Figure 4: Window sizes for Naive Bayes on AD data would discover spurious correlations with the current message being considered for delivery. Our final set of experiments concerns the use of the entire history of email that preceded each test example. By constraining learning to a smaller window of preceding messages we can also get a sense for how quickly learning can “get up to speed”, when learning must rely on less data than later on in the iValet’s life. To explore this question we performed a second set of tests, using three different window sizes: 100, 500 and infinite. Figure 4 shows a prototypical example of these runs. We observe that in most cases as the window size increases, so does the overall performance. However, it is interesting to note that this is not always the case, in that each window size performs the best on at least one point. Another interesting observation we make is that even for a window size of 100, we still get credible results, demonstrating that learning does have the potential for learning user’s preferences even early in the iValet’s use.

Prospects for the Future In this paper we introduced a new framework, the Information Valet (iValet), to be able to intelligently access information using a range of different client devices. We described the current status of an instantiation of an iValet, the Rutgers iValet, which provides wireless access to email, files, and the Web through multiple wireless clients. We discuss the issues that must be considered in the design of the various components of an iValet, especially those concerning the injection of adaptability into the iValet. We concluded with experimental studies of the potential behavior of one possible way of injecting adaptability into the Rutgers iValet based on 9 months of data from its three users. In addition to adding learning, our current efforts area also addressing the means for providing cross-device functionalities in the iValet. Our current front end allows each device to learn of what other devices exist, so that the user can forward items from one device, whose capabilities may not suit a given item, to a second device that may be more appropriate for that information. However, achieving such functionality forces us to confront additional questions. For example, in the case of email, the question of synchronizing across multiple devices and multiple email accounts arises. If a message is downloaded onto a particular client device, how can one distinguish between deleting it from the device while still wanting to see it later versus other means, and deleting it from existence for any client? More immediately our plan is to focus on exploiting the connectivity of devices in delivering information. For example, having one low-power device always on, and one more powerful device only intermittently

connected, allows the iValet send a message or notification to the shallow device to let the user know to turn on the more capable device, because a piece of information has arrived that the user might find important, but which is not easily viewed on the shallow device. Our current work concerning learning continues to address the nature of the information and features can be used to improve performance of the iValet. Longer term, we would like to understand how best to couple learning with multiple-device information access and a wider range of interaction modalities that future technologies may make possible. For example, permitting a wider range of interaction between the user and the iValet, such as via natural-language dialog, could provide a valuable resource to an iValet, such as making it possible to ask the user questions about his or her decisions. These technologies would help convert iValets from simple information access systems to more fully realized software entities that more accurately reflect the human valets from which they were given their name.

Acknowledgments This work was supported in part by a Rutgers Information Sciences Council pilot project as part of the Rutgers University Strategic Opportunities and Analysis initiative. Equipment for this work was provided by BellSouth Wireless Data.

References Basu, C.; Hirsh, H.; and Cohen, W. W. 1998. Recommendation as classification: Using social and content-based information in recommendation. In Proceedings of the Fifteenth National Conference on Artificial Intelligence. Billsus, D., and Pazzani, M. 1999. A personal news agent that talks, learns and explains. In Proceedings of the Third International Conference on Autonomous Agents. Domingos, P., and Pazzani, M. 1996. Beyond independence: Conditions for the optimality of simple bayesian classifier. In Proceedings of the 13th International Conference on Machine Learning, 105–112. Foner, L., and Maes, P. 1994. Paying attention to what’s important: Using focus of attention to improve unsupervised learning. In Proceedings of the Third International Conference on Simulation of Adaptive Behavior. Brighton, UK: MIT Press. Lashkari, Y.; Metral, M.; and Maes, P. 1994. Collaborative interface agents. In Proceedings of the Twelfth National Conference on Artificial Intelligence. Menlo Park, CA: AAAI Press. Macskassy, S. A.; Dayanik, A. A.; and Hirsh, H. 1999. Emailvalet: Learning user preferences for wireless email. In Proceedings of Learning about Users Workshop, IJCAI’99. Maes, P., and Kozierok, R. 1993. Learning interface agents. In Proceedings of the Eleventh National Conference on Artificial Intelligence, 459–465. Menlo Park, CA: AAAI Press. McCallum, A. K. 1996. Bow: A toolkit for statistical language modeling, text retrieval, classification and clustering. http://www.cs.cmu.edu/∼mccallum/bow. Pazzani, M., and Billsus, D. 1997. Learning and revising user profiles: The identification of interesting web sites. Machine Learning 27:313–331. Shardanand, U., and Maes, P. 1995. Social information filtering: Algorithms for automating ”word of mouth”. In Proceedings of the CHI-95 Conference. Takkinen, J., and Shahmehri, N. 1998. Are you busy, cool, or just curious? – cafe: A model with three different states of mind for a user to manage information in electronic mail. In Lundgren, P. A., ed., Human IT, number 1 in 98. ISSN 1402-1501.