IBM Almaden Research Center,
650 Harry Rd, NWED-B2, San Jose CA 95120, U.S.A.
gentry@almaden.ibm.com,
pmaglio@almaden.ibm.com and
barrett@almaden.ibm.com
The vast scale and scope of current online information sources — which include the World Wide Web, Usenet news, electronic mail, as well as personal data such as that contained on a user's hard drive or personal digital assistant — make it difficult to find and process relevant information. Finding information requires time-consuming searching, and is so tedious that useful or interesting bits are often not uncovered. Push technology is being touted as an ideal solution to this quantity of information problem (e.g., [3]; see also Wired). By automatically delivering timely and relevant information to users, push promises to relieve users from the drudgery of information searching.
Some current approaches to push, such as the Pointcast Network, rely upon simple, static user models derived from data entered directly by the user. Typically, the application includes a customization screen, which consists of tabs, checkboxes, and entry blanks that allow the user to select certain kinds of news, weather, financial, and sports information that are of interest. Using these general categories as a kind of user model, a central service gathers relevant information from online sources and delivers it to the user. Other approaches to push incorporate no user model, adopting instead a television metaphor. Recent versions of Microsoft's Internet Explorer and Netscape's Communicator come packaged with a push application fashioned as a television remote control: users switch between c nnels of preformatted content that is updated continually and delivered in a rich multimedia format. Neither of these approaches, however, can achieve delivery of relevant information without significant work on the part of the user. For the push application to obtain information pertinent to a user's short-term interest, the user must directly manipulate the application (updating the user model in the first approach, and searching through channels in the second). Furthermore, categories of available information are either limited to a few broadly conceived areas or dispersed among many smaller concentrations that cannot be efficiently browsed.
These current approaches to delivering relevant information to users assume that user interests are relatively stable or quasi-static. Once defined — whether by checkboxes denoting broad information categories or by channels of predetermined content — a user's interests remain fixed until actively changed. The push application delivers new information when new information related to user interests becomes available: When when the world changes, the user is informed. Thus, the world is considered dynamic and the user is considered quasi-static. Although it is obvious that the user should be updated when the relevant state of the world changes, we believe it is equally obvious that users' interests are not nearly as stable as current approaches to push assume. Because what computer users do changes from moment to moment, information that would be relevant changes from moment to moment too. We believe that by monitoring the changes in user activity from moment to moment, we can determine t user's interests, and use that knowledge to build a dynamic user model [5]. Information retrieved using such a dynamic user model can deliver more useful, timely, and interesting information than can standard push.
In what follows, we describe our approach, User-Centered Push (UCP), in some detail. We begin by illustrating UCP through user scenarios. We then outline our general architecture and discuss a sample implementation.
Computer applications today range from Web browsing, electronic mail, and news readers to word processors and spreadsheets. Given the possibilities and ever-increasing computational power, it is common for an average user to have many applications open simultaneously, and to open and close many more during the course of a day. Obviously, the applications running on a computer reflect the interests of its user, at least to some extent. Multitasking enables computer use to be dynamic, changing with a user's whim, and in ways that would be hard to predict in advance.
To automatically retrieve timely, relevant information, our User-Centered Push approach takes advantage of information resources available on a user's computer, such as Web browsing and history, application usage, electronic mail and Usenet news postings, and keyboard and mouse input to build a dynamic profile of user interests. Using this profile, information pertaining to a user's interest can be derived and delivered almost immediately. Consider just a few examples of the sorts of timely information that can be obtained based on a dynamic user model:
We believe the items on this list reflect a coherent set of functions. Although implementing just one of these examples in a specific context is not a difficult job, implementing a framework that cuts across all of them may very well be. In addition to basic issues concerning the constitution of a user model, two main difficulties arise. The first is in providing the ability for user actions in one application to have an effect on what the user sees in another. For instance, we might want the sorts of typos a user makes when typing into a word processor to influence the sorts of typing exercises the typing tutor program constructs.
The second difficulty is in providing a general architecture that supports the right combinations of functions. It would be straightforward to implement each of the items on the above list as a separate application. It is more difficult, however, to leverage the abilities of one function in constructing another. For instance, given a program that finds financial information for display by a news ticker, it would be silly to reimplement this program simply to display the same information on a personal digital assistant. What is an appropriate level of abstraction for composing these sorts of functions?
We refer to our general architecture as User-Centered Push. At one level, it is an approach for implementing specific push applications, such as those listed above. But more importantly, it provides a framework for (a) tracking user behavior, (b) constructing a dynamic user model, (c) gathering information from local and distal sources, and (d) reporting back to the user.
To make our User-Centered Push approach concrete, consider its impact on an ordinary user named Ted:
Standard approaches to push would be hard-pressed to keep up with Ted. Even if Ted customizes his push software to include the stocks he currently owns, the application can only bring him stock prices and news stories related to those holdings. No mechanism exists to automatically provide Ted with information on new business interests. Many things that he might find interesting along the way, such as information regarding his spreadsheet, word processor, browser, or the content of the letter to his friend, require Ted expend special effort to obtain.
With the User-Centered Push approach, however, Ted receives additional information precisely when it is most likely to be useful to him. Moreover, the kind of information he receives changes as his activities change. For instance, UCP notices Ted using his word processor and provides helpful tips on how to better use it. UCP also notices where Ted is browsing the Web and delivers him relevant news on the company he is currently viewing. By continually updating a model of its user's interests, as they are reflected in user activity, UCP can search for and deliver information that is likely to be timely and relevant. Of course, the utility of this approach depends on the specific methods used to track activity, find information, and deliver information. We now turn to details of our architecture and implementation.
Our User-Centered Push system incorporates a basic blackboard architecture (e.g., [2]), containing a wide variety of agents that collaborate by monitoring user activity, deriving user interests, searching for relevant information, and reporting to the user. In UCP, such agents are called sleuths because they investigate the state of the user or the state of the world. When a sleuth discovers some information, it posts a fact on the shared blackboard. When facts are posted, sleuths might be triggered that derive additional facts (about the user or about the world) either by computing them or by looking them up. Certain sorts of facts trigger reporter sleuths, which deliver information to the user. Thus, we have a forward-chaining system whereby facts about user behavior lead to facts about user interests, which in turn trigger the search for facts that might interest the user. Ultimately, these interesting facts are delivered to the user. Processing in UCP can be broken down into three steps: (a) observing the user to create a user model, (b) gathering in rmation relevant to user interests, and (c) reporting this gathered information to the user. Figure 1 illustrates this system.
Fig. 1. Overview of User-Centered Push architecture.
A computer user interacts with various streams of data. To build a user model, UCP monitors traffic on those data streams in real time. For instance, by monitoring the HTTP stream, UCP can determine what the user is accessing on the World Wide Web; by monitoring window system messages, UCP can determine what applications are open and have focus; and by monitoring keyboard input, UCP can determine what text is being typed. In addition to monitoring streams with which the user is actively engaged, UCP can also investigate static data such as the applications on a user's hard disk and the contents of specific files such as email or text documents. In UCP, the user is modeled as a set of facts about user activity and about user interests derived from those activities. The model is dynamic in that user activity causes changes in the posted facts about those activities, which in turn causes changes in the posted facts about user interests.
As facts are added to the user model, sleuths are triggered to gather or derive information relevant to user interests. For instance, if the user is interested in a certain company, sleuths can investigate that company on the World Wide Web to find (among other things) current news and stock prices. If the user is interested in a certain software application, sleuths can investigate that application to find updates from well-known download sites. If the user is interested in a certain topic, sleuths can investigate that topic to find additional information, such as what the user has said about it in the past. In any case, sleuths that gather such relevant information are triggered by the posting of facts about current user interests. In addition, relevant information might be gathered from local sources, such as the user's email to find information on some topic, or it might be gathered from distal sources, such as WWW sites to find company news and stock prices. Given UCP's continually updated user model, sleuths can investigate topics related to current user interests. When these investigations turn up potentially relevant information, the gathered facts are posted to the shared blackboard. Eventually, these gathered facts ar reported to the user. In particular, certain sorts of facts posted on the blackboard trigger reporter sleuths that are responsible for information delivery.
The User-Centered Push system itself commits to no single delivery method. Rather, separate client applications, such as news and stock tickers or special email services, can use reporter sleuths to trigger when certain types of information are found. For example, the user may choose to display a news ticker at the bottom of his or her screen to view headlines and stock prices. Alternatively, the user may prefer that news headlines be emailed or directly downloaded to his or her PDA. In any event, like sleuths that infer facts or gather facts, reporter sleuths are triggered when certain types of facts are posted on the blackboard. However, unlike sleuths that infer or gather, reporters do not post new facts: they merely provide an interface between the blackboard and separate information delivery applications.
In summary, our User-Centered Push architecture is built around a shared memory, the blackboard. Investigative agents or sleuths communicate with each other through the blackboard as they uncover facts about user activity, infer facts about user interests, gather facts relevant to user interests, and report these relevant facts to the user. We have implemented this general architecture in Java 1.1. Our example implementation, deFacto, provides a testbed for the UCP approach, allowing us to try out arbitrary sleuths. In what follows, we describe details of our implementation, as well as some of the sleuths and fact-types with which we have experimented.
Sleuths that monitor user activity post facts about that activity on the shared blackboard. Each fact instance deposited on the blackboard is of a specific type, and contains data relevant to that specific type. For example, activity on the HTTP stream might result in a CurrentWebPage fact which contains the page's URL, whereas a new application being opened might result in a CurrentApplication fact which contains the name of the executable being run. Given facts about the user's current state, sleuths can infer what sorts of information might interest the user. If the current Web page has just changed, an inference sleuth triggered by the posting of CurrentWebPage facts might unpack the URL to find the name of the server, then try to determine the company, school, or organization associated with that server, and eventually post an Interest fact indicating that the user is interested in a particular company, school, or organization. The key point is that some sleuths are trig red by the types of facts posted on the blackboard; in this case, the posting of a CurrentWebPage fact triggers a sleuth that posts an Interest fact.
Sleuths that gather information are triggered by user interests and post facts about the state of the world. In many cases, investigating the state of the world means querying some search engine or database on the World Wide Web for related information. For instance, a sleuth that responds to a CompanyInterest fact to find current stock prices might query the company's stock symbol on Yahoo!'s stock quote service. If this query is successful, the sleuth would post a StockPrice fact on the shared blackboard that contains the current price for the company named in the CompanyInterest fact. Another sleuth that responds to CompanyInterest facts might try to find company news by querying Yahoo!'s business headline service. If news is found, this sleuth would post Headline facts that contain information on the company.
In other cases, investigating the state of the world means discovering information buried on the user's local system. For instance, if the user is writing email about a certain topic, an observer sleuth might detect repeated phrases, such as "push technology", and post a TopicInterest fact that contains the repeated phrase as its data. A gatherer sleuth that triggers on TopicInterest facts might then search through user' s old email to find what the user has said about this topic in the past. If such related email is found, the sleuth would post a RelatedEmail fact containing some of the previously written text (e.g., [4]). In any event, facts about the state of world trigger reporter sleuths to deliver that information to the user. For instance, reporters associated with the news ticker application are triggered when Headline and StockPrice facts are posted to the blackboard. Rather than using these facts to derive new facts, the sleuths report the information to the news ticker, which in turn displays it to the user.
The sorts of sleuths and facts we have discussed so far are oriented toward a user who is generally interested business and stocks. As stated, deFacto makes no commitment to any specific set of sleuths. If the user were a programmer concerned more with programming languages and software than with stock prices, different sleuths would be appropriate and could be added easily to the system. In this case, an observer sleuth might monitor the code the user writes, posting, say a CodeSnippet fact every once in a while. CodeSnippets might trigger a sleuth that determines programming language, posting, for instance, a JavaCodeSnippet fact. Another sleuth might trigger on this fact and declare the user to be a JavaProgrammer, which in turn might trigger a gatherer sleuth to find Java programming resources on the Web, and eventually post a ReferenceInformation fact that can be reported back to the user. The possibilities are endless.
Consider again the scenario involving Ted and User-Centered Push. Recall that while Ted is writing a letter to his friend, he happens upon the Web page for the Widget company, and deFacto automatically displays news about Widget for him. In this case, an observer sleuth detects that Ted has gone to a new Web page and posts a CurrentWebPage fact, with the URL for Widget in its data field. Once this fact is posted, a sleuth that is waiting for a new CurrentWebPage fact is triggered. This sleuth in turn pulls the name of the company out of the URL, and posts a CompanyInterest fact that contains the company name, Widget, in its data field. In plain English, deFacto has inferred that Ted is interested in Widget because he visited Widget's home page with his Web browser.
The fact that Ted is interested in Widget in turn triggers a gatherer sleuth that uses the stock symbol of the CompanyInterest fact to query Yahoo! for related news stories. Yahoo! returns a Web page that contains a list of articles in order of relevance. The gatherer sleuth selects the most relevant one, and posts a Headline fact to the blackboard which contains the article's title and associated URL. One reporter sleuth triggers on the Headline and sends it to the news ticker for display. Another reporter transfers the content of the Headline to Ted's PDA.
In another instance, a change in the CurrentApplication fact triggers a sleuth that posts a SoftwareInterest fact, which indicates that Ted is interested in a specific word processor. This fact in turn triggers a gatherer that uses the name of the directory of the word processor executable to find files on Ted's hard disk that contain helpful usage tips for the word processor application. If such tips are found, the gatherer sleuth posts a UsageTip fact on the blackboard, which then triggers a reporter to send the tip to the news ticker.
In addition to details of user activity, user interests, and the state of the world, facts also contain information about the sleuth that posted it, the fact it was based on (i.e., fact that triggered the sleuth that posted it, if any), the time it was posted, and the period of time it is to be considered valid. Because the goal of User-Centered Push is to provide users with timely information, a fact's life-span is of critical importance, and so a fact may expire after a time. For instance, when a user clicks on a hyperlink and a new Web page is displayed in his or her Web browser, additional information related to that page might only be interesting as long as the page is displayed, or perhaps only for a minute or two if the page remains current for a long time. In deFacto, the blackboard itself runs a special thread to expire facts. When a fact expires, all facts that were derived from it are also expired. This means that if an Interest fact was derived by a sleuth that triggered on a < CurrentWebPage fact, the Interest expires when the current page changes or the CurrentWebPage fact expires, indicating that the user is no longer interested in the topic of that page.
In addition to simply reporting facts to the user, information delivery applications might also enable the user to provide feedback to deFacto. Such feedback could be used in a supervised learning process to tune the sleuths in the system. For instance, if the user clicks on a headline displayed by the ticker application to view the full article in a Web browser, it might be reasonable for deFacto to deliver more headlines like this one. That is, by clicking on the headline, the user has expressed positive interest in this particular fact, and is likely to want to see similar information. Though we have not yet implemented a feedback scheme, one approach would be to give more weight to facts produced by sleuths that have a history of producing facts that the user has expressed a positive interest in. Such an approach does not fundamentally change our UCP architecture at all. In this case, it could be left up to the specific reporting application to decide which of many possible facts to display (and in at order) based on weights of the sleuths that led to them.
Some of the sleuths we have implemented use WBI [1] to monitor and otherwise interact with the user's HTTP stream. WBI is an architecture for adding intermediary functions to the Web as computationally powerful proxies that can monitor the data stream, edit the data stream, or generate their own responses. For instance, the sleuth that detects the CurrentWebPage is implemented as monitor in WBI. In addition, some observer sleuths rely on WBI generators create and process forms with which the user can directly interact. Thus, deFacto can be administered via locally generated Web pages through whcih the user selects sleuths to run and information delivery mechanisms to use. Another set of seluths provides users with a general preferences checklist about the sorts of news to deliver, much as Pointcast and other standard push systems do. Note that the standard approach to push falls out as a special case of our UCP approach.
Though the deFacto architecture is written in pure Java, some observer sleuths rely on native C++ functions to determine keyboard and low-level process information, and so in our present implementation, these are Win32-specific.
We have also implemented several mechanisms for delivering information to the user. We have built a news and information ticker that can be used to display Headline, StockPrice, and other types of facts to the user (see Fig. 2). In addition, we have written reporters that interface with the PalmPilot to automatically download Headlines and their associated articles.
Fig. 2. Screen shot of the news ticker displaying information (in bold) relevant to the page visible in the Web browser.
User-Centered Push is a new approach to push technology that centers information retrieval around a constantly changing model of user interests. UCP provides an architecture for (a) tracking user behavior, (b) constructing a dynamic user model, (c) gathering information from local and distal sources, and (d) reporting back to the user. Unlike standard approaches to push, UCP tracks user activity to determine when the user's interest changes. Because UCP bases users' information needs on a dynamic model of user interests, it has a good chance of delivering information to the user that is both timely and relevant. Our example implementation, deFacto, demonstrates that it is possible to deliver pertinent information to a user whose interests are dynamic.
|
George Underwood George (Gentry) is an undergraduate at Stanford University studying human-computer interaction in the Symbolic Systems Program. His work includes projects in interactive learning, adaptive agents, and passive information delivery. |
|
Paul P. Maglio Paul holds an S.B.in Computer Science and Engineering from the Massachusetts Institute of Technology, and a Ph.D. in Cognitive Science from the University of California, San Diego. He joined IBM Research in 1995, where he studies how people use information spaces, such as the World Wide Web. |
|
Rob Barrett Rob holds B.S. degrees in Physics and Electrical Engineering from Washington University in St. Louis, and a Ph.D. in Applied Physics from Stanford University. He joined IBM Research in 1991, where he has worked on magnetic data storage, pointing devices, and human-computer interactions in large information systems. |