USRE47704E1 - Method and apparatus for selectively sharing and passively tracking communication device experiences - Google Patents

Abstract

The present invention includes methods and devices for passively tracking and selectively sharing user experiences with communication devices, including computers, web-enabled telephones, and PDAs. User rating or comments on their experiences can be captured. Particular aspects of the present invention are described in the claims, specification and drawings.

Description

More than one reissue application has been filed for the reissue of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006. The reissue applications are application Ser. No. 14/577,746 (the present application), Ser. Nos. 14/550,100, 13/894,009, 13/893,992, 12/820,579, and 12/172,518, all of which are reissues of U.S. Pat. No. 7,080,139. The present application is a reissue application of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006, and a continuation of application Ser. No. 14/550,100, filed on Nov. 21, 2014, which is a reissue application of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006, and a continuation of application Ser. No. 13/893,992, filed on May 14, 2013, now U.S. Pat. No. RE45,351, which issued on Jan. 20, 2015, which is a reissue application of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006, and a continuation of application Ser. No. 12/820,579, filed on Jun. 22, 2010, now U.S. Pat. No. RE44,324, which issued on Jun. 25, 2013, which is reissue application of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006, and a continuation of application Ser. No. 12/172,518, filed on Jul. 14, 2008, now U.S. Pat. No. RE41,450, which issued on Jul. 20, 2010, which is a reissue application of U.S. Pat. No. 7,080,139, which issued on Jul. 18, 2006.

BACKGROUND OF THE INVENTION

The Internet has opened up new channels of communication and vectors of influence over decision-making. Web sites, peer-to-peer technologies, e-mail and instant messengers are new communication technologies, which have major impacts.

Advertisers and marketers have shown great interest in the influence of these new technologies. However, it is difficult to observe the channels of communication or vectors of influence using traditional market research methods.

Users of the new communication technologies have been particularly quick to embrace instant messengers. Users desire new ways of sharing with friends the experiences they have and discoveries they make using the new communication technologies.

Therefore, there is an opportunity to introduce a new technology, a method and device which provide a new way of sharing experiences, potentially allowing advertisers and marketers to study channels of communication and vectors of influence at the same time.

SUMMARY OF THE INVENTION

The present invention includes methods and devices for sharing communication device usage experiences, including computer usage experiences. Particular aspects of the present invention are described in the claims, specification and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of interrelated components of systems practicing aspects of the present invention.

FIG. 2 is a user interface for logging in or creating a new account.

FIG. 3 is a user interface for providing access to system features.

FIGS. 4 and 5 are user interfaces for inviting a “buddy” to join in practicing aspects of the present invention.

FIGS. 6 and 7 are user interfaces for sending a buddy an item.

FIGS. 8A-8D are aspects of a user interface for administration of a buddy list.

FIG. 9 is a user interface for viewing activity of buddies. The interface illustrated applies as well to viewing of other item or location related data.

FIG. 10 is a user interface for viewing a so-called hits list, combined with a user interface for viewing activity. The interface illustrated applies as well to viewing of other item or location related data.

FIG. 11 is a user interface for viewing details regarding particular items. This user interface is combined, likeFIG. 10, with a user interface for viewing activity.

FIGS.12-14 is 12A, 12B, 13, and 14 are flowcharts illustrating the capture of URL related data from a user. The actions illustrated by these flowcharts apply as well to capture of other item or location related data.

FIG. 15 is a flowchart of automated updating of a visited URL database (“VUD”), with exception processing. The actions illustrated by these flowcharts apply as well to updating of databases reflecting captures of other item or location related data.

FIG. 16 is FIGS. 16A and 16B present a flow chart flowchart of an activity viewer. The actions illustrated by these flowcharts apply as well to viewing of other item or location related data.

FIGS. 17-19 are flow charts of buddy list and access control list (“ACL”) administration.

FIGS. 20-21 is flow charts of access control list interface actions.

FIG. 22 is a flow chart of the batch and custom query processes.

FIG. 23 extends aspects of the present invention to wireless devices, such as cellular telephones and pagers.

FIG. 24 is a flow chart of populating the visited location database (“VLD”).

DETAILED DESCRIPTION

The following detailed description is made with reference to the figures. Preferred embodiments are described to illustrate the present invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows.

A common theme among aspects of the present invention is collecting data regarding a user's computer usage experience and sharing that data. So-called “buddies” identified on buddy lists of instant messaging products can share selected aspects of their computer usage experiences. Administrative tools and processes can be provided to set up selective collection and sharing of data. Collection tools and processes operate on a variety of computer usage activities and user responses to their computer usage experiences. Processing tools and methods filter, integrate and correlate the collected data. Display tools and processes make portions of the data accessible on a pre-defined basis, such as according to defined rights of buddies. Aggregation tools and processes assemble statistics about user experiences across different bases, such as buddy lists, categories of users, and all service participants.

DATA COMPILED

Aspects of the present invention include building and making accessible various databases and combinations of databases. The databases specifically described below are illustrated in one or another of the figures; reference numbers are provided for ease of reference. One database is a visited URL database (“VUD”)100A. A VUD stores URLs visited by users, or by participants. More generally, a user could visit a web site, listen to or watch content, rate a site or content, assign an emoticon or quick comment to a site or content, send or bookmark a site or content or download data; a VUD entry could result. A rating may be thumbs up or thumbs down or its equivalent, a scaled alpha or numeric rating or its equivalent. An emoticon is an icon conveying a reaction, such as: “:)”, “:(”, “:\”, “—)”, “—(”, etc. Quick comments may be user defined and later accessible through a menue, ush as a pull-down menu. In addition to URLs, the database stores additional information such as page title, address, description, categories applicable to the URL, metadata, names of users accessing the URL, timestamps of visits, ratings of the URL, emoticons evaluating the URL, comments on and bookmarks to the URL, or keywords for retrieval. The page title, address, description and metadata may be ascertained from visiting the URL itself. With assistance of the URL's author, metadata may include suggested categorization. Alternatively, categorization may be provided by an existing content analysis provider, such as Yahoo or the Open Source Directory Project at www.dmoz.org1506. A further alternative is that content could be categorized by a service provider or other sponsor, either for web content or for intranet, extranet or other network content.

Another database used to practice aspects of the present invention is the visited location database (“VLD”)100B. A VLD stores similar information for locations visited by users or participants carrying portable devices. For instance, a Bluetooth equipped cell phone or pager could interact with a location that a user entered. Walking in the door of a popular restaurant, nightclub or other location could trigger an interaction between a Bluetooth device and a Bluetooth access point sponsored at the location. The Bluetooth device could learn the location visited and report that location immediately or later when the device returned to the proximity of a home access point or the device docked with a home access point. Alternatively, the Bluetooth device could disclose its identity to a Bluetooth access point at a particular location and the access point could report the visit. The user of the Bluetooth device could have the same options for providing additional information regarding the location, as for URLs. The VLD also could store geographic information regarding the location, such as geo-coded data. Several equivalent methods of associating a portable device with a location are available. Sophisticated networks may fingerprint, triangulate or otherwise locale a wireless device based on radio signal characteristics. Sophisticated devices may include circuits that determine the device's location; these circuits may utilize GPS, DGPS, Loran or any other location fixing protocol. The physics of how the device and the location are associated are relatively unimportant; an independent service may be used to track locations visited by a user based on any of the protocols identified above or any other protocol.

The VUD and VLD databases are readily extended to a visiteditem database100, which could include items on a computer, intranet, extranet or any network. These items may be data such as multimedia files, XML documents, database searches or virtually any other material. One distinction between practicing aspects of the present invention and general database processing is storing user-based information, such as the user's pattern of visiting and the user's rating, emoticon or comments regarding an item and making stored, user-based information available to buddies. Collectively, VUDs, VLDs and visited item databases can be referred to as VXDs. Reference to one of the three VXDs is intended to refer to all three, unless the context makes it clear that only one of the three applies.

Access control lists (“ACLs”)102,103,104,1609 also can be maintained as databases. An ACL identifies buddies and controls their access to VUD, VLD, visited item and other activity-related data. A user could set up his or her own ACL via buddy list and access control list administration functions. An enterprise could set up ACLs for enterprise users. ACL-like data complied for instant messaging products could be accessed and utilized to compile ACLs for users or enterprises.

A URL logo database (“ULD”)101 can be useful for associating logos with web sites. The logos may be sponsors, advertisers or others who provide support for operation of a service practicing aspects of the present invention.

Item categorization for VUD, VLD or visited items can generate exception databases, such as an item match exceptions database (for instance, a URL match exceptions database (“UMED”)1505) or a topic match exceptions database (“TMED”)1507. These exception databases record data which require further attention after initial processing to update the VUD, VLD or a visited item database.

An activity viewer database (“AVD”)1610 can store information associating particular users with URLs, locations or items. Raw data regarding user activity is filtered and matched with entries from the VUD, VLD or visited item database to create the AVD. The AVD holds users' activity parsed into a format for display via the Activity Viewer. It includes the activity, internal flag settings, the URL, the page title, the logo, the username, the timestamp & category for an entry. If a user filters the display of data on the Activity Viewer, data is pulled from this database.

Batch query results can be stored in a database, a “BQD”2211. Pre-defined queries can be run against the VUD, VLD or visited item database. For instance, top 10 hits, top 50 hits or top 100 hits in a wide range of categories are most efficiently recalculated periodically on a batch basis, rather than in response to ad hoc inquiries.

Third party location detection data can be stored in adetection network directory2312. Third party data can be provided as received, on an interrupt-like basis, or in response to periodic requests, on a polling or batch basis. Location categorizations anddescriptions2413, e.g., Yellow Pages.Com, AutoDesk, etc. can be used to provide supplemental information about locations.

Location/topic entries which require further attention, after processing to update the VLD, can be stored in another match exceptions database, a “LTMED”2414.

One aspect of practicing the present invention can include tying into a user's instant messaging products or, more generally, into the user's messaging facilities. For instant messaging (“IM”), users or participants typically set up so-called buddy lists. Other users or participants agree to participate in instant messaging. One IM user can send an instant message to another IM user, if their IM products are compatible. The two can carry on a dialog or a so-called “chat”. More than two users may be included in a real-time chat, when the instant messaging product allows multiple participants. Examples of instant messaging products include AOL's Instant Messenger software, MSN Messenger software, Yahoo! Messenger software, America Online's ICQ software, Odigo's instant messenger software and Jabber's instant messenger software. Reciprocal inclusion on buddy lists typically involves a closer relationship between participants than inclusion on an e-mail mailing list or directory, but this is not necessarily the case. Buddy lists sometimes are shorter and more selective than general messaging lists or directories.

The present invention also may be applied to a user's messaging facilities by selectively enabling others listed on a general e-mail or messaging list or directory to participate. Selectively enabling others limits the intrusion on a user's privacy and limits various administrative (e.g., setup and administration) and responsive (e.g., junk mail) burdens. Alternatively, group functions used for other e-mail or messaging purposes can be a basis for defining rights to sharing of activity data.

OVERVIEW AND USER INTERFACES

FIG. 1 is a block diagram of interrelated components of systems practicing aspects of the present invention. Tracked activity may includeInternet activity120, wireless network location track and interaction activity121 andenterprise intranet activity122. Activities tracked in these domains may include view, listen, rate, comment, assign emoticon, send, watch, download, bookmark or visit. A user views a URL, watches a visual presentation and listens to an audio presentation. A user visits a restaurant or other location. A user who views, watches, listens or visits may respond to their experience. A user's response may be to rate, comment, assign an emoticon, send information to a buddy, download data or bookmark an item for later access.

Data stored regarding an experience may include VUD, VLD orVXD databases100, a logo database for URLs, locations oritems101 and a variety of ACL databases. The access control lists can be maintained at theservice provider level104, theenterprise level102 or theindividual user level103.

Data130 reflecting individual experiences and aggregated experiences can be accessed or reported in a variety of ways. An activity viewer running on a user'ssystem131, either fixed or portable, can appear in a window. Reports on locations, either the experiences of others visiting the location or the proximity of buddies or buddies of buddies can be reported automatically to Bluetooth enabledwireless devices132 when such devices reach a location or are in contact with a location-sponsored Bluetooth access point. Wireless devices can be synchronized133 when reasonable bandwidth is available to retain data that would be too voluminous to access via a low bandwidth connection. The interfaces ofinstant message tools134 can serve as an output channel, as licensing arrangements become available.Physical reports135 can be printed for analysis. These reports can cover analysis of interactions among participants and spreading of information from one user to others.

FIG. 2 is a user interface for logging in or creating a new account. In one embodiment, separate fields can be provided foruser name251 andpassword254. In other embodiments, these fields could be combined. After filling in identification data, a user may select a sign onlink253 or press the enter, return key or other key or may take another action such as speaking a command or winking an eye, which triggers processing of the completed fields. A link is provided for creating anew user252, which may be on demand or subject to an approval process. A new user can either be a new name for a registered user or a new registration. A user who forgot their password may use one of the commonly employed password recovery schemes, by selecting a forgottenpassword link255. An additional link for new user registration is provided256. In one embodiment, the system implements a strict, anonymous access privacy policy and does not collect any information about the user which could be used for identification of the user or compilation of a database of user-identified activities. In another embodiment, the user can chose the amount of information that the user provides and corresponding services that are enabled by providing information such as an e-mail address. In this second embodiment, the system can publish a range of privacy policies, including a default, and ask the user to opt-in to a specific privacy policy, which may include providing the user's name or e-mail address to a handful of select vendors that have products responsive or keyed to the user's shared activities.

FIG. 3 is a user interface for providing access to system features. The embodiment illustrated is a relatively low profile access window. A lower profile access window can be provided via an icon that is visually accessible, such as a floating menu bar having an always on top attribute or an icon in a system tray. Pressing a hot key is an alternative way to bring an access window into view. The access window illustrated inFIG. 3 has many features, which can be included in a wide variety of combinations. Theservice provider logo360 doubles as providing access to features not immediately visible. These features may include maximize, minimize, quit or selection of a particular display format. Acurrent selection361 identifies a current context, such as viewing an aggregated list of the best Hip Hop music of 2000.Rating choices362 such as thumbs up and thumbs down or emoticons allow a user to instantly express their view regarding the current context with a simple action, such as a single click of a mouse. A user who wants to say more about their experience can select acomments button363 to activate a window for entering comments. A scroll button364 also supports entry of free form comments, definition of user comments, selection from among user comments, or selection of emoticons, either system supplied or user defined emoticons. When the scroll button364 is used, the default item may change from “comments.”Other button choices363 can be provided to a user, in addition to comments, such as emoticons or sending the current context to one or more buddies. A send button365 is immediately accessible and activates a window for selecting recipients of information from the current context. The current context may be a list or a particular item, either from a hit list or the like or from the user's own activities.

The sharingstatus toggle366 allows a user to turn sharing on and off. When sharing is on, rights defined in the ACL provide access for buddies to the user's activity. When sharing is off, the user's activity will not be shared with buddies. However, the user's activity may still be recorded to a tracking server either for aggregation or to be associated with the user but not reported to buddies. The user's options or access to information may be limited when sharing is off, tending to encourage the user to leave sharing activated. The window maximizecontrol367 allows direct access to maximizing the window to a pre-selected format.

Other aspects of this interface include space for a banner368 (either static or moving), aninvite button369, ahot list access370, asearch entry window371 and asearch button372. The banner could be used to generate advertising revenue. Theinvite button369 provides access to an invite interface such asFIG. 4. Thehot list access370 provides access to one or more options and access formats for aggregate ratings of items. The ratings may reflect the frequency of access to an item or rating scores assigned by users. The rating scores may be thumbs up/down or any of the other scoring approaches mentioned above. Thesearch entry window371 accepts text and logical connectors. Thefind button372 can be implemented to search titles of items accessed by participants, content of such items, the Internet, an intranet or another domain of interest.

FIGS. 4-5 are aspects of an interface for inviting others to become buddies.FIG. 4 is one of many possible initial invitation interfaces. An instant messagingselect button473 allows a user to identify an instant messaging product which maintains a list of buddies who can be invited to join a group. In some implementations, such as an enterprise implementation, a network directory such as a Novell, NT orWindows 2000 server directory of users may be accessed instead of an instant messaging product. In other implementations, an e-mail system user directory may be accessed for users to invite. Group membership for enterprise implementations alternatively may be administered by a security department, instead of individual users. Ascroll button474 allows a user who has more than one source of lists, such as more than one instant messaging product, to select the user to be invited. Thescreen name window475 accepts a text string. It may provide assisted field completion, including a list of near matches. For some implementations, such as AIM or Yahoo IM, the screen name may be a name. For other implementations, such as Indigo and ICQ, the screen name may be a number which ties to a name, which may be locally unique or not unique at all. These alternatives are further presented in the discussion ofFIG. 17, below. Asend button476 triggers transmission of an invitation to the identified buddy or other potential participant. The transmission may include a text message delivered by the instant messaging tool with a hyperlink for the recipient to sign up. The donebutton477 signals that the user is done inviting buddies. Amore information button478 provides a help function.

FIG. 5 is an invitation follow-up interface. In some embodiments of the invitation process, there is no feedback from the instant messaging tool to an invitation process. The invitation process may query the user to determine whether an invitation was sent successfully. This interface provides a user with three alternative responses. If the instant message transmission was successful, the user indicates “yes”582. If the user attempted the instant messaging invitation, but the buddy was not available, the user may press thee-mail link581. Alternatively, the user may elect to invite the buddy again later583. Then, the buddy's name will appear on a buddy administration list (FIG. 8A) with a link such as “resend invitation.” The system may allow a user to clink on an entry in a list and resend the invitation, preferably when the invitee is on line. In other embodiments or using other instant messaging products, the IM product may assure delivery of the message when the recipient is not instantly available. Yet another approach is for the IM product to provide direct feedback to the activity sharing processes, so that an invitation or other follow-up interface appears only when needed and so that the user never needs to confirm that an invitation or item was successfully sent.

FIG. 6 depicts an interface for sending an item to a buddy. This interface may be invoked, for instance, by selecting the send button365. The item being sent is identified691. Theitem identification691 may be linked to the item, a pull-down menu of items recently viewed or recently sent, or to a dialogue for selecting an item to send. The user selects between sending the item, a link to the item or other item-related information to a buddy who has enrolled to share activity data or to a person listed as an instant messaging buddy. In an enterprise implementation, as described above, the user might select an addressee from a network registry of users or an e-mail list. Apersonal note695 may be sent along with an item. The system may be configured so that the personal note is not retained on the tracking server or so that it is retained. Thesend item button696 signals that the items should be sent. The cancelbutton697 indicates that the item is not to be sent. Either the send or cancel button can be accompanied by a confirmation screen.

FIG. 7 is a confirmation interface for items sent. The three choices are as inFIG. 5: to confirm that the message was sent799 “yes”; to resend the item bye-mail798; or to queue it to be resent later799 “later.”

FIGS. 8A-8D depict interfaces for administration of buddy lists. The embodiments depicted are adapted to integration with instant messaging products. Slightly different embodiments would be better adapted to e-mail or other types of messaging facilities, such as Lotus Notes.FIG. 8A depicts one embodiment of a buddy list. A link is provided851 for inviting a new buddy. An alternate link for adding a user may appear in the list ofbuddies856. The columns provided in this embodiment include atick box852, abuddy name853, and one or more instant messaging contact links854. Thetick box852 may be used to delete several selected buddies. Thebuddy name column853 includes both buddy names and options to resend an invitation or add a new user. The buddy names may be active links which lead to additional interfaces, such as those depicted inFIGS. 8B-8D. Thecontact column854 lists one or more instant messaging contact links. The extension following the link may identify a particular instant messaging tool. The link may be in the form of the user ID applicable to a particular instant messaging tool. This interface also includes a link for deleting selectedbuddies857 and for indicating completion ofbuddy list administration858.

FIG. 8B is another of the buddy list administration interfaces. The name of the buddy being profiled appears as aheader861. Optionally, a group of buddies may be administered. Related buddy administration screens include abuddy overview screen862,contact information863, topic sharing rights864 and file sharing rights865. The user may either view866 or edit867 information regarding a buddy or group of buddies. More information can be obtained by clicking alink868. For particular buddy, a particular instant messaging tool is selected869 and instant messaging ID is entered or selected870. When a buddy has more than one instant messaging tool or ID, a user may select a link for addingadditional links871. The interface adds more rows, including more options for instant messaging tools and instant messaging ID's872,873. More than one instant messaging ID may be assigned to a buddy for a particular instant messaging tool. When the contact information is complete, the user selects the save changes link.

FIG. 8C uses tick boxes to select files or folders to be shared by default. Both default and particular user or user group administration is supported.Tick boxes881 and directory or filenames882 can be used. Additional files or folders can be added to alist883. Alternatively, a Windows Explorer-style file directory tree can be used to select files and directories, as is done for backing up and restoring files or directories. Additional fields and links inFIG. 8C have the same placement and usage has inFIG. 8B.

FIG. 8D is a topic sharing interface. Both default and particular user or user group administration is supported.Tick boxes891 and topic orsub topic names892 can be used. Additional topics can be added to alist893. Alternatively, a browser-style bookmark tree can be used to select topics. Additional fields and links inFIG. 8B have the same placement and usage as in the previous figures.

FLOWCHARTS

FIG. 9 is a user interface for viewing activity of buddies. The interface illustrated applies as well to viewing of other item or location related data.Tab963 indicates that the activity-viewing mode of the interface is currently active. Other tabs may be provided forpeople962,files964,messages965 orsummaries966. Thepeople tab962 may invoke buddy list administration. Thefiles tab964 may invoke a hierarchical representation of the user's file system and selection boxes for designating directories and files, relative to particular buddies. The buddy may appear as columns adjacent to the file system representation or with a separate list, with selection boxes for users to be associated with particular rights. Themessage tab965 may provide access to a message repository.Button961 provides access to commands such as minimize, maximize, always on top, etc., which were previously discussed in the context of FIG.3. The sharing button andindicator967 behaves as previously described, also in the context ofFIG. 3. In this embodiment, additional controls are provided in a row below the tabs and sharing button. Threefilters971,972 and973 are provided. The who filter971 specifies whose activity is of interest: for instance, all buddies or a user-defined group of buddies. Thetopic filter972 selects one or more pre-defined topics. Theview filter973 allows viewing of all or selected portions of a participant's activity by topic. For instance, only items bookmarked or sent to others may be of interest, in a domain having substantial activity. A keyword search is in effect a fourth filter, including thesearch term window974, thefind button975 and theadvanced find button976.

Several rows of information responsive to the filters971-976 appear inFIG. 9. The columns of information displayed for each row include who981 did892 what984 where985 in whattopic area982 when988.Ratings986 andcomments987 also may be provided. This interface can convey a substantial amount of information compactly. The whocolumn981 may use short labels, especially when the buddy list is short or subgroups of buddies are created. The didcolumn982 is compactly represented by an icon, from a recognizably short list of activity types. The icons depicted in this figure may signify viewing, visiting and sending items. Each of the activities mentioned above may be assigned an icon. Thetopic column983 also is compactly represented by an icon. The variety of topics may be larger than the variety of activities. User defined subtopics may complicate the selection of icons. In some instances, a user may need to access more detailed information about an activity in order to understand the topic involved. This detailed information may be available through the topics filter972 or by selecting a particular line including the icon. The whatcolumn984 is an informative title for the item identified. For a URL, a page title may be more informative than the URL. Accordingly, page titles may be stored for URLs, to guard against loss of the page title when a content provider updates the page. Similarly useful shorthands for other types of items may be used. For instance, the name of a restaurant may be used instead of its Bluetooth access point address. The wherecolumn985 is an opportunity to display banners, which may generate user impressions and revenue. Display of banners may be limited to vendors who pay a fee for preferential banner display. Therating column986 may use a graphic, a color or a symbol to indicate a rating. In this embodiment, icons for thumbs up/down are depicted. Thethoughts column987 may support either free text comments or pick-list comments such as emoticons or user-defined quick comments. The whencolumn988 records a date and time of an activity. Asend button989 is included. In this embodiment, it appears as a large button on a bottom row, instead of as an icon near the sharing button. Row select commands, such as mouse-click, shift mouse-click and control mouse-click can be used to select one or more rows prior to selecting the send button.

FIG. 10 is a user interface for viewing a so-called hits list, combined with a user interface for viewing activity. The interface illustrated applies as well to viewing of other item or location related data. The bottom part of this interface combines features found inFIGS. 3 and 9. Much of the tworows1070 is taken fromFIG. 3. The who filter1081 is fromFIG. 9. Theitem rows1071 are generally as inFIG. 9, with an added column forsend buttons1082. Next andprevious buttons1084,1085 are provided for scrolling through activities.

The top part of theFIG. 10 interface is a hits list. Thetitle line1051 identifies the category of hits, in this instance aTop 10 list. Filter buttons are provided foractivity type1052, group of persons sampled1053 and location of persons sampled1054. When the desired filters are selected, the submitbutton1055 signals for the screen to be refreshed. Three columns of information about these 10 hits are provided in this embodiment:rank1061, what1062 and where1063. These columns have been explained above, except the ranking, which is ordinal. The coincidence in this example between data lines in the top 10 list and in the activities is unlikely ever to occur at random in actual use; the repeat of the same lines twice in a top 10 list also is unlikely to occur in actual use.

FIG. 11 is a user interface for viewing details regarding particular items. This user interface is combined, likeFIG. 10, with a user interface for viewing activity. The bottom part of this interface,1070,1071, is as inFIG. 10. The top part includes two windows:1151 through1154 and1155 through1167. The larger frame in the top part displays search results, annotated with buddy-related information. The search string appears at the top1155 along withsummary search statistics1158. Bothcategory results1156 and individual items have been returned in this example. Onecategory1156 has been returned. Three items responsive to the search have been returned, each beginning with a title1157. Information for an item may include abuddies rating1161. The number of buddies of the user who have commented on the site is indicated parenthetically. A summary “thumbs up” is indicated and a percentage of favorable ratings appear. (In actual use, 78% would not be reported from a sample of three ratings.) In addition to user-buddy ratings, other group ratings can be reported. In this instance, ratings aggregated against all registeredusers1162 are reported. The second group could be user selected. In an enterprise implementation, it could be a division, subsidiary, a whole enterprise or any other predefined group. Theratings1161,1162 need not be up-to-the-moment ratings, they may be compiled periodically in a batch mode. The information for an item may include a site furnished text1163, a review furnisheddescription1164, one or more categories applicable to theitem1165 and links for retrieving acached copy1166 orsimilar pages1167. The cachedcopy retrieval1166 may be an alternative to retrieving a live copy of the item1157, which is useful when an item is deleted or moved after it is indexed.

The inset toFIG. 11, 1151-54, is intended to provide detailed information related one or more of the items displayed. The columns of detailed information in this embodiment include who1151, when1152,rating1153, and comments oremoticons1154. If there are more users then can readily be displayed in a single inset, previous and next buttons can be used to scroll through a list. Alternatively, the list can be sized into a larger window. The list also could be filtered to select particular buddies or groups of buddies, date ranges, ratings or comments. The names of individual users and their comments can be linked to additional information or functions related to the individual and to the detailed free text continents.

FIGS. 12-14 are a flowchart illustrating the capture of URL related data from a user. The actions illustrated by this flowchart apply as well to capture of other item or location related data.FIGS. 12 and 13 are linked by the capture/track connector1233.FIGS. 13 and 14 are linked by the file &item connector1355. The flow inFIG. 12 begins withstart1201. The user may visit aURL1202 utilizing any browser, from a PC, telephone, PDA or other device. Others processes described in the context of visiting or viewing a URL, it may be applied to other item types as well. The URL visited is captured1203. This capture may be accomplished via a browser plug-in, an independently running process, or in a variety of other ways. A page title or other descriptive text may be captured in addition to the URL address. The page title or other text is stored in a temporary variable, along with a timestamp and a user ID. In this embodiment, the capture process next has to determine whether in the user's sharing status is on1204. If the sharing status is off1205, the system sets the status of the item to private. In other embodiments, the system might all processing of the item. If the sharing status is on1206, the system sets the status of the item to public. After the status is been sent, the process tests to determine whether metadata associated with the URL provides apage title1207. If not1208, the system stores a null indicator in a temporary variable.

If the metadata provides apage title1209, the system stores the page title in a temporary variable. The system next compares the URL to entries in theVUD1210. If the URL is found inVUD1211, the system has to determine whether a page title is stored on theVUD1221. If there is a page title on theVUD1222, the system action depends on whether the page title variable has been set to null. If not, the system over writes the value on the VUD with the value of the temporarypage title variable1224. If the temporary page title variable is null, the page title stored on the VUD is used1223. Next, the system determines whether the URL has been categorized on theVUD1225. If not, the system sets a temporary category variable touncategorized1227. This is the same action that the system takes in the URL is not on theVUD1211. If the URL has been categorized on the VUD, the system sets a temporary category variable based on the contents of theVUD1226. The system checks to determine if the URL or a portion of the URL is logged in alogo database1228. The logo orULD database101 holds vendor logo images that correspond to the vendor's URLs. If the vendor has not arranged for its logo to be stored on theVLD1229, the system sets the temporary local variable to null1231. If there is a corresponding logo, the temporary variable is set to the correspondinglogo image1230. The system sets a temporary activity variable to view1232, corresponding to viewing a URL. The flow continues inFIG. 13.

FIG. 13 depicts processing of URLs behind the interfaces presented above. The user has several options after viewing a URL. Viewing the URL triggers background activities depicted inFIG. 12. While the user is viewing the URL, system monitors foractivity1341. If no activity is detected1342, monitoring continues. When activity is detected, the system determines the type ofactivity1343,1345,1347,1349,1351,1353. When the user moves to anew URL1343, the values stored in temporary variables for the old URL are added to theVUD1344. The new URL is processed in accordance withFIG. 12. When the user selects anemoticon1345, the system processes the user'sselection1346. The system may associate either a predefined emoticon with the URL or it may associate a user-defined emoticon with the URL. These values may be stored in a temporary variable until the user moves to a new URL or another user activity triggers storing data to the VUD. When the user decides to enter afree text comment1347, the system processes thefree text1348. It associates a text string with the URL at a temporary location, which can later be transferred to the VUD. The system then resumes monitoring forURL activity1341. The user selection ofrating1349 is processed1350 in much the same way as an emoticon. In the embodiment described here, the rating is either thumbs up for thumbs down, a binary rating. Multi-value ratings can also be processed, such as a scale of 1 to 5, 1 to 7, or 1 to 9. The system then resumes monitoring forURL activity1341. Choosing thesend button1351 causes twoprocessing steps1352. One or more items in the current context are sent to a buddy and the activity of sending the items is reported to a tracking server to be recorded in the VUD. The system then resumes monitoring forURL activity1341. Processing that follows detection of abookmark activity1353 is similar to processing of a send activity. Either the instant messaging product or the system may process the actual creation of the bookmark. The activity of creating the bookmark is reported to a tracking server to be recorded in theVUD1354. Again, the system then resumes monitoring for I/O activity1341. Other activities, more often associated with an item other than a URL, are processed as depicted inFIG. 14.

A variety of activities may be associated with items other than URLs. Depending on the type of item involved, the user may listen to or watch theitem1461, download theitem1463, purchase theitem1465, put the item on awish list1467, transfer the item to a mobile device, such as a cell phone orPDA1469, or select someother process1471. In some circumstances, an unrecognized activity may occur1473, which the system may either ignore or treat is an error condition. A listen to or watchactivity1461 causes the system to invoke a player and to record the action and properties of the item listened to or watched1462. The recorded information is forwarded for addition to the VUD. A download activity invokes a process, which records the download action and properties of the item downloaded1464. The recorded information is forwarded for addition to the VUD. Apurchase activity1465 invokes aprocess1466, which records the purchase action and properties of the item purchased. The recorded information is forwarded for addition to the VUD. Awish list activity1467 invokes awish list process1468 to maintain and add to the user's wish list. The wish list can be maintained as part of the VUD or in a separate database. The information can be maintained redundantly as part of the VUD and as the result of a batch query. When the activity is to transfer the item to amobile device1469, the system invokes a process for sending the information to the mobile device, records the action and properties of the items sent to the mobile device, and forwards the recorded information for addition to theVUD1470. The processing of each of these activities inFIG. 14, with the possible exception oferror processing1473, leads back to monitoring foractivity1341.

FIG. 15 is a flowchart of automated updating of a visited URL database or VUD, with exception processing. The actions illustrated by these flowcharts apply as well to updating of databases reflecting captures of other item or location related data. An automated VUD updating routine1511 updates keywords andmetadata1512 andtopics1513. The input for updating is a set of VUD update records from processing of user activity. Updating1514 may take place and real-time or on a batch basis. The updating of keywords and metadata utilizes a URL spider and an external search engine index to gather URL indices, keywords and metadata for each VUD entry being updated from theInternet1522. Unmatched entries are stored in anexceptions database1505 and anexception report1521 is generated. Data in the exceptions database (“UMED”) may be manually added to the VUD. These exceptions also can be reprocessed for instance, if Internet access is restored or improved. Additional processing takes place to update topics associated withVUD entries1513. During processing1515, the system compares VUD entries against one or more external URL categorization databases, such as the database provided by the Open Source Directory Project (www.dmoz.org). Matches are processed for addition to the VUD. VUD entries that do not match are marked as on categorized and stored in anexceptions database1507. Data in this topic exceptions database (“TMED”) may be added manually to the VUD or reprocessed any time. Additional items to the exceptions database may cause anexceptions report1523 to be generated.

FIG. 16 is a flow chart of an activity viewer. The actions illustrated by this flowchart apply as well to viewing of URL, other item or location related data. The activitydisplay population routine1621 supports theinterface1629, which previously has been discussed in the context ofFIG. 9. Thesystem keys1622 on fields which provide access to the relevant database, such as the VUD,VLD100 or VXD. For VUD entries, user ID and topic may be used as a key. Alternatively, the key may be fields which match filters available to or selected by the user. For a visited location, user ID and location or action may be used as a key. Thesystem1622 matches data from therelevant database100 with theuser ACL database1609. This matching may run periodically on a schedule set by the system administrator or it may run on demand. Data “matches” when the ACL database authorizes the requester or a particular user to have access (e.g., by user ID and topic) to the VXD entry and the status flag is public (as opposed to private) for the VXD entry. Matched data items are buttered1623. For eachbuffered entry1624, the system checks for the existence of a logo on the location logo database (“LLD”)1608. Processing depends on whether or not a logo exists1625. If it exists, the system sets a temporary variable corresponding to the logo image retrieved from thedatabase1626. Otherwise, the logo space is left blank. Each matched entry is added1627 to the corresponding shared users file within the activity viewer database (“AVD”)1610. The system populates activity viewers of logged-in users by pulling entries from theAVD1628. User ID, action, item, location, category, rating, emoticon, comment, time, or other relevant field may filter the displayed data from the AVD. The activity viewer of the user refreshes the activity display automatically. The frequency for this refresh may be set by a system administrator and may be modified by the user.

FIGS. 17-19 are flow charts of buddy list and access control list (“ACL”) administration. The after the administration processes invoked1721, the process tests to determine whether the user of the system is anew user1722. A new user may either be invited or not1725. An invited user is prompted to a start their buddy list with the person who and issued theinvitation1731. If the new user adds the person who invited them1732, the new user optionally definesaccess rights1735. The system then sets flags for new and invited status to “no”1736. The system adds the buddy and associated information in the user's buddy list to theACL1734 and loops back to thestart1721 with the user flagged as not new. In the processing of the new user, if the new user is not invited1725 or declines to add the person who invited them to the new user'sbuddy list1732, an error message is displayed indicating that at least one buddy must appear on abuddy list1726. The user is routed to an addbuddy screen1733. This addbuddy screen1733 also may be reached by a non-new user who has anempty buddy list1723 through the invitebuddy error message1726 or after the non-new user is shown theircurrent buddy list1724 and elects1727 to add additional buddies. Processing of a non-new user who declines to add additional buddies proceeds to1728, inFIG. 18. After the add buddy screen, the system checks the user's IM tool flags to determine which instant messaging tools are available and to provide an adapted message to theuser1734. The user'soptions1738 may include asking for more information, canceling the addition of users or selecting an instant messaging tool such as AIM user, ICQ user, Odigo user or Yahoo IM user. The user may be required to confirm my pressing an OK button after selection of an instant messaging tool. If the user presses OK1741, instead of cancel, the system tests to determine whether the user requestsmore information1742 and provides aninformation screen1745 upon request. The system also tests to determine whether the user requests sharedtopics information1743 and provides aninformation screen1746 on request. After information has been provided the system tests determine whether the user has selected one of theinstant messaging options1744. If not, the system loops and waits1741. If an instant messaging tool has been selected, the system determines which class of instant messaging tool has been selected1752. For some instant messaging tools, the system displays aname field1754 and prompts the user to enter aname1756. For otherinstant messaging tools1751, the system displays a user number field and prompts the user to enter abuddy number1753. For both classes ofinstant messaging tools1755, the user optionally defines access rights. Processing then continues to test for inviting anew buddy1757, as described inFIG. 19.

FIG. 18 includes logic for editing entries in the buddy list, followingother processing1728. The system checks to determine whether one or more buddies have been selected1861. If not, processing1862 returns to a previous screen. If a buddy has been selected, processing depends on the number of buddies in thelist1863. If there are one or fewer buddies in the last1864, the system activates only the end button. If there is more than one buddy in thelist1866, the system activates edit and remove buttons. The remove button is not activated for one or fewer buddies, as the system requires at least one buddy in a buddy list. The system checks to determine whether edit has been selected1867. If not, it checks to determine whether remove has been selected1868. If not, processing returns to thestart1865. If remove has been selected1869, the system displays a confirmation screen and tests whether the remove command has been confirmed1872. If not, the system loops again to test whether remove has been selected1868. If confirmation is given1874, the system removes one or more buddies from the user's buddy list and returns to thestart1865. Remove will not have been selected if edit is selected1871. The system responds to selection of edit with anedit user screen1871. The user responds to the screen by editing any the fields of the selected buddy and clicking submit or cancel. The system tests to determine whether submit has been selected1875 and, if so, tests to determine whether mandatory fields have been completed1877. Mandatory fields may include the identity of the instant messaging tool and a user ID, either a name or user number, as appropriate. If some of the mandatory fields are incomplete, anerror screen1876 is displayed and the user is given a further opportunity to add any of thefields1873. If the mandatory fields are completed, the system updates the buddy and associated information in thebuddy list1878 and returns to thestart1865. If the user clicks cancel instead of submit or otherwise fails to submit1875, processing proceeds to test whether remove has been selected1868. The processing from this point proceeds as described above.

FIG. 19 depicts logic for sending invitations to new prospective buddies. This logic complementsother interface processing1757. The system determines whether the user has selected thesend invitation link1982. If not, processing returns to thestart1981. If so, the system checks to determine whether the user being invited is already registered forservices1984. The system uses the prospective buddy's IM tool ID as a key. If the prospective buddy has more than one IM tool, the system may either use only a primary IM tool ID or may use all listed IM tool ID's to check for current registration status. If the prospective buddy is not registered1985, the system invites the buddy by invoking the user's instant messaging tool and creating a message with standard text and a link to invoke aregistration process1983. The system queues the invited prospective buddy in a file of pendinginvitations1986. The invited buddy's ACL and instant messaging ID will be stored against a temporary registration ID. When the invited buddy responds to the invitation, the system will use the temporary ID to match the invitee against the queue. After an invitation has been made, the system marks the user's buddy list as not empty1989 and sets the user's new and invited flags to “no”. For a theprospective buddy1985 who is already registered, the system notifies the user of the prospective buddy'sstatus1987 and stores the buddy name with relevant information, such adds an identification of the instant messaging tool used by thebuddy1988. The system adds the buddy and associated information to the user'sbuddy list1990. The system allows the user to send messages to the buddy, including a message regarding theirACL status1991. Either the user's instant messaging tool with standard text and links or an e-mail message may be used for this purpose. The system sets the user's new and invited flags to “no”1992 and returns to start1981.

FIGS. 20-21 are a flowchart for access control list administration. InFIG. 20, ACL administration begins with astart screen2051. One sensible default organization is bytopic2052. In the “by topic” view, the system checks2053 to determine whether a “by buddy” view has been selected. If so, logic for displaying and processing the “by buddy” view is invoked2054. If not, the system checks to determine whether the administration session has been canceled2055. If “cancel” has been selected, the system determines whether the page has been marked as amended2056. If the page has not been amended, the system returns to aprevious screen2050. If it has been marked as amended, the system prompts the user to savechanges2057 and tests whether the user wants to save changes. If not, the system simply the reverts to aprevious screen2050. If so, the system updates various access flags andrelated data2066 before reverting to theprevious screen2050. When “cancel” has not been selected, the system checks whether a topic folder has been selected2059. If so, the system shows the corresponding buddy list access level in a pane of theview screen2060. The system then determines whether tick boxes adjacent to any buddy name have been checked2061. If so, the display format of the buddy name may be altered to reinforce the tick mark and the page is marked as amended2062. Processing continues to determine whether a buddy name has been de-selected2063. If so, the display format of the buddy name may be altered to reinforce to the de-selection and page is marked as amended2064. Processing continues to determine whether “submit” has been selected2065. If not, processing loops to before2053. If so, theupdate path2066 is followed.

InFIG. 21, ACL administration proceeds from selection of the “by buddy”view2054. This view is displayed2172. The system determines whether the user has selected a change of view to “by topic”, for instance. If so, the display is changed2171. If not, the system determines whether the user has selected “cancel”2175. If “cancel” has been selected, the system determines whether the page has been marked as amended2176. If the page has not been amended, the system returns to aprevious screen2174. If it has been marked as amended, the system prompts the user to savechanges2177 and tests whether the user wants to savechanges2178. If not, the system simply the reverts to aprevious screen2174. If so, the system updates various access flags andrelated data2186 before reverting to theprevious screen2174. When “cancel” has not been selected, the system checks whether a buddy folder has been selected2179. If so, the system shows the corresponding topic list access level in a pane of theview screen2180. The system then determines whether tick boxes adjacent to any topic name have been checked2181. If so, the display format of the topic name may be altered to reinforce the tick mark, and the page is marked as amended2182. Processing continues to determine whether a topic name has been de-selected2183. If so, the display format of the topic name may be altered to reinforce the de-selection and the page is marked as amended2184. Processing continues to determine whether “submit” has been selected2185. If not, processing loops to before2173. If so, theupdate path2186 is followed.

FIG. 22 is a flow chart of the batch and custom query processes. Batch processing ofrequests2251 may be useful to reduce response time for certain processing-intensive queries. For instance, scoring the top 10 or top 100 hits in a category may require a substantial amount of processing which the user would be unlikely to endure. The selection of a hit list may be from a menu, which means that the number of processing-intensive queries is limited and manageable. The system performspredefined queries2252 against theVUD100A and theVLD100B or any similar database on a batch basis. The results are sent to a database of batch query results (“BQD”)2211. These predefined queries are accessible immediately to both Internet and wireless network queries.FIG. 22 distinguishes betweenInternet queries2253 and wireless queries2255. Internet queries may include both predefined queries and custom-builtqueries2254. To the extent that wireless queries are hampered by limited bandwidth, wireless queries may be limited topredefined queries2256. The processing of both types of queries is essentially the same2257. The user submits a query to the system and the system either performs or real-time query2258 or retrieves a predefined query from thebatch query database2259. The system returns results of the query to theuser2260.

FIG. 23 extends aspects of the present invention to wireless devices, such as cellular telephones and pagers. Processing of wireless location and action data begins at2351. The user's wireless communication device and location detection service is first activated2352. It is necessary for the user to have awireless device2354, which supports a location detection service. This support may be by Bluetooth, GPS or any other location detection technology. Then, the link between location detection and activity sharing is activated2353. A login process may be automated to execute whenever thewireless device2354 is activated. Given the activation of a wireless device, the system periodically receives information regarding the location of thewireless device2356. As described above, this may be on an interrupt, polling or periodic batch transfer basis. Alocation network directory2312 is accessible, which reflects location ofwireless devices2354 and contains information such as the devices' location address, location description, a timestamp, anduser ID2358. With this information, the system sets the action or activity type to “visit” a location and logs an entry into a visitedlocation database2358. The system also monitors2355 for activity related to a location, such as bookmarking a location, rating a location, adding an emoticon or comments about the location.Activity monitoring2355 continues when no input/output activity is detected2357. When input/output activity is detected, the system determines the type of activity. Typical activities includebookmarking2359, rating, or adding anemoticon2363 or free text comment to a location reference. When a location is bookmarked2359, the system adds a bookmark flag, location address, location description, a timestamp and a user ID to the VLD or a buffer for later addition to the VLD. When a location is rated2361, the system adds the rating, location address, location description, a timestamp and the user ID to the VLD or a buffer for later addition to the VLD. When a location is flagged with anemoticon2363, the system adds the emoticon, location address, location description, a timestamp and the user ID to the VLD or to a buffer for later addition to the VLD. Similarly, when a user makes a comment on alocation2365, the system adds the comment, location address, location description, a timestamp and the user ID to the VLD or to a buffer for later addition to the VLD. For each of these activities, fewer or more fields may be utilized in various embodiments.

FIG. 24 is a flow chart of populating the visited location database (“VLD”). The process for updating topics and descriptions begins at2451. The system compares2452 all VLD entries or buffer entries for addition to the VLD against location category and locationdescription database entries2413. It updates the matching entries and records to categorization and descriptions to the VLD. Unmatched entries are recorded in anexceptions database2414. This location-topic and location-description match exceptions database (“LTMED”) may be used to generate anexceptions report2453. Matched entries are written to theVLD100B.

APPLICATION EXAMPLES

The interfaces and software described above support many methods and devices for sharing communication device and computer usage experiences. One type of sharing communication device user experiences is sharing computer usage experiences, including Internet browsing experiences. Whichever communication device is used, sharing may depend on registration by a user with a registration server. Registration may involve downloading client software to run on the user's system. For enterprise applications, registration may be handled by a system administrator and integrated or coordinated with registration for network login, e-mail or other messaging. In some embodiments, registration may include contractual terms which limit the use of information collected from the user. In other embodiments, registration may be designed to exclude collection of certain user information, such as the user's e-mail address, actual name or physical address. Some users may feel more comfortable registering with the system if registration excludes collection of any information that identifies the user in a manner adapted to direct marketing. Even if registration excludes initial collection of user identifying information, the user may be given the option of entering additional personal information for general use by the providers of the system or for restricted use, in accordance with contractual terms. The registration process may make the user aware that at least a portion of the user's experiences with a communication device, computer or Internet browser will be collected and shared. It also may make the user aware that information collected from the user will be aggregated with information collected from other users.

Sharing communication device experiences also may include accessing one or more messaging buddy lists associated with the user. Accessing pre-existing buddy lists provides a base for linking the user and buddies with whom tracking data may be shared. Buddy lists may be maintained by AOL's Instant Messenger software, MSN's Messenger software, Yahoo! Messenger software, America Online's ICQ software, Indigo's instant messenger software or Jabber's instant messenger software. More generally, message recipient lists maintained in e-mail systems, such as Microsoft's Outlook products or AOL's Netscape products may maintain the lists that are accessed. Messaging systems such as Lotus Notes also may maintain message recipient lists that the system can access to identify persons with whom tracking data may be shared.

Buddies or groups of buddies are given defined rights to access tracking data collected from the user. Defined rights of buddies to access tracking data may be based on content categories of material accessed. Examples of content categories or topics can be found inFIG. 8D. Defined rights of buddies also could be based on keywords. Definition of rights to access tracking data collected from the user may have multiple aspects. Access may be restricted by the type of activity involved, such as viewing, listening, rating, commenting, assigning an emoticon, sending, watching, downloading, bookmarking or visiting. Access may be further restricted by when the activity potentially accessed took place. It may be restricted based on a value assigned to a rating or emoticon. It can also be restricted based on its original source. Activities marked private, instead of public, may never be shared, based on a user's decision to turn sharing off. There are many useful combinations of these approaches to define the rights of buddies or groups of buddies to access tracking data.

At least a portion of the user's computer usage experiences are tracked and reported to a tracking server. This tracking may be carried out by a module resident on the user's computer or by a device placed between the user's computer and an access point to the Internet. In an enterprise implementation, tracking can be carried out by a server or proxy server. The tracking data can be filtered before it is reported to the tracking server. Data may be filtered based on a sharing on/off option exercised by the user. It also may be filtered based on content categories. In some implementations, only those activities that fit content categories which the user agreed to share would be reported to the tracking server. Alternatively, activity could be reported to the tracking server that was never intended to be posted for access by buddies. The tracking server or a posting server could filter the information before posting it for buddies to access. The computer user experiences tracked could include viewing URLs, downloading files, listening to songs, viewing videos, making purchases, sending items from a user to their buddies, or general messaging between the user and buddies.

In addition to computer user experiences, mobile communication device locations can be tracked, using any of the technologies described above. Activities related to location may include visiting the location, rating, commenting on it, assigning an emoticon, or connecting with another buddy or buddy of a buddy at the location. Proximity to a location may be variation on visiting the location.

It further may be useful to categorize at least a portion of the tracking data by content. The categorized tracking data would be subject to filtering and sorting. Categorized tracking data also could be searchable by content category and date range. For instance, a particular buddy's viewing of stock-related sites containing the name “Cisco” during a one or two-month period could be located.

Tracking data can be posted, after filtering, for buddies to access according to their defined access rights. The interface for viewing activity reflected by the tracking data may include a send button, which allows a user to forward an item to a buddy, either with or without comment. Interface also may include rating an emoticon buttons. It may facilitate free text comments on an item. These functions may apply to selected groups of items, in addition to applying to individual items. The buttons for free text comments and the feature for adding notes to items sent to buddies allow annotation of items.

The tracking process further may include generating a full text index of items viewed. This indexing may be performed in the context to viewing URLs or, in an enterprise implementation, in the context of the viewing internal work product or summaries of internal work product. Automated some regeneration may be combined with indexing, so that summaries are indexed.

Additional functionality of the system, which passively tracks activities of registered users may include tracing the flow of information or data among registered users. Information which is sent from a user to a buddy may be annotated with a history of users who forwarded the information. Alternatively, it may include a first user who forward the information and the immediately previous forwarding user. Or, it could identify a limited number of previous forwarding users. If less than a will history of users who forwarded the information is included with information sent from a user to a buddy, an analysis server may use a combination of timestamps and forwarding information to determine the dissemination or diffusion information and the velocity at which it is disseminated. Social network theory provides a number of metrics for evaluating the dissemination or diffusion of information. The tracking capabilities which are an aspect of the present invention can readily be adapted to quantifying the relative influence of one or another user on their buddies, including the strength, frequency, extent and relative value of their influence. Certain users may be selected for introduction to information or new product releases. Certain users may be selected and rewarded as a result of efficient dissemination of information through their social network.

A system practicing aspects of the present invention can readily collect, collate and present user generated lists of superlatives regarding activities, products and services. List may be generated by time period, utilizing date stamps and activities, number of top items (10 or 50 or 100 top items) or other filtering criteria.

The availability of location information for mobile communication devices allows the system practicing aspects of the present invention to present information regarding buddies and buddies of buddies who may be present at the user's physical location. Based on tracking visits to locations, information can be generated such as a particular user's list of favorite restaurants or favorite boutiques. Patterns of visits to physical locations can be reported. Information can be presented to users based on locations recently visited.

Information associated with particular locations can be offered up to users of mobile communication devices, in a context sensitive mode. Categories of information such as buddies' ratings of nearby restaurants can be provided, utilizing location information generated from the mobile communication device and established buddy lists.

While the preceding example applications are cast in terms of a method, devices and systems employing this method are easily understood. A magnetic memory containing a program capable of practicing the claimed method is one such device. A computer system having memory loaded with a program practicing the claimed method is another such device. A system including a registration server and a tracking server practicing the methods described above is another such device.

While the present invention is disclosed by reference to the embodiments and examples detailed above, it is understood that these examples are intended in an illustrative rather than in a limiting sense. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims.

Claims (48)

We claim:

1. A method of sharing computer user experiences, including:

communicating with a registration server to register a user, for automatic client-side collection of computer usage experiences for future sharing, wherein the computer usage experiences include one or more of browsing URLs or visiting a location with a location-aware device that records the visited location;

accessing one or more of the user's messaging buddy lists and selecting one or more buddies with whom to share the automatically collected computer usage experiences;

defining categories of computer usage experiences to be shared with particular selected buddies;

tracking automatically on the client-side at least a portion of the user's computer usage experiences and reporting the user's computer usage experiences to a tracking server to be published to the particular buddies in accordance with their defined categories of sharing.

2. The method ofclaim 1, wherein the registration server and the tracking server are a single server.

3. The method ofclaim 1, wherein the registration server and the tracking server are distinct servers.

4. The method ofclaim 1, wherein registering the user excludes collection of the user's e-mail address.

5. The method ofclaim 1, wherein registering the user excludes collection of the user's actual name.

6. The method ofclaim 1, wherein registering the user excludes collection of the user's physical address.

7. The method ofclaim 1, wherein registering the user excludes collection of any information that identities a user in a manner adapted to direct marketing.

8. The method ofclaim 1, wherein registering the user further includes establishing an anonymous unique identifier for the user.

9. The method ofclaim 8, wherein reporting the tracking data includes reporting the anonymous unique identifier.

10. The method ofclaim 1, wherein the messaging buddy list is maintained by AOL's Instant Messenger software.

11. The method ofclaim 1, wherein the messaging buddy list is maintained by MSN Messenger software.

12. The method ofclaim 1, wherein the messaging buddy list is maintained by Yahoo! Messenger software.

13. The method ofclaim 1, wherein the messaging buddy list is maintained by America Online's ICQ software.

14. The method ofclaim 1, wherein the messaging buddy list is maintained by Odigo's instant messenger software.

15. The method ofclaim 1, wherein the messaging buddy list is maintained by Jabber's instant messenger software.

16. The method ofclaim 1, wherein the rights of the buddies are defined by content category of the user's computer usage.

17. The method ofclaim 1, wherein the rights of the buddies are defined by appearance of one or more keywords on pages corresponding to URLs viewed.

18. The method ofclaim 1, wherein the rights of the buddies are defined by activity type of the user's computer usage.

19. The method ofclaim 1, wherein the user utilizes a computer and tracking is carried out by a module resident on the computer.

20. The method ofclaim 1, wherein the tracking is carried out by a device placed between a computer utilized by the user and an access point to the Internet.

21. The method ofclaim 1, wherein the computer usage experience tracked is filtered before it is reported to the tracking server.

22. The method ofclaim 1, wherein the computer usage reported is filtered after it is reported to the tracking server and before it is posted for the buddies to access.

23. The method ofclaim 1, wherein the messaging buddy list is maintained by an instant messenger software.

24. The method of claim I, further including sending tracking data regarding one of a user's computer usage experiences to one or more buddies.

25. The method ofclaim 1, further including categorizing at least a portion of the tracking data by content and sorting the tracking data by content category.

26. The method ofclaim 1, further including categorizing at least a portion of the tracking data by content and making the tracking data searchable by content category and date range.

27. The method ofclaim 1, wherein posting further includes providing annotation tools for associating notes with individual tracking data entries.

28. The method ofclaim 1, wherein posting further includes providing annotation tools for associating ratings with individual tracking data entries.

29. The method ofclaim 1, wherein posting further includes indexing text portions of at least a portion of pages reported from tracking the user's Internet usage.

30. The method ofclaim 29, wherein text indexing is limited to pages reported from tracking as having been annotated or forwarded by the user.

31. A method of sharing Internet browsing experiences, including:

tracking automatically with a client-side application at least a portion of a user's Internet usage and reporting the tracking data to a server;

categorizing at least a portion of the reported tracking data by content category;

presenting to the user a history of the reported tracking data, with tools for searching and forwarding the tracking data;

receiving from the user data identifying of one or more persons on the user's buddy lists and authorizing the persons to receive tracking data;

responsive to a user request, sending one or more entries from the history of the reported tracking data to the authorized persons.

32. A method of sharing computer user experiences, including:

registering a user with a registration server to collect and share visited location data using a client-side application collected while visiting a location with a location-aware device that records the visited location;

accessing one or more of the user's messaging buddy lists to identify one or more buddies with whom the tracking data may be shared;

defining rights of the buddies to access the visited location data;

posting at least a portion of the user's visited location data for the buddies to access according to their defined rights.

33. A method of operation of a location-aware cellular phone device comprising:

sending registration information to a registration server from the location-aware cellular phone device;

enabling access to one or more lists of other users to identify one or more other users with whom visited geographic location data is to be shared;

enabling definition of access rights for the one or more other users to access the visited geographic location data;

collecting the visited geographic location data for geographic locations visited by the location-aware cellular phone device using a client-side application, the visited geographic location data comprising a plurality of the geographic locations visited by the location-aware cellular phone device, each geographic location visited time-stamped with a time of visit, the geographic locations visited automatically and passively recorded by the location-aware cellular phone device using a satellite-based location-fixing protocol and a detection network directory; and

reporting information indicating the visited geographic location data collected by the location-aware cellular phone device.

34. The method of claim 33 wherein enabling the definition of the access rights for the one or more other users comprises receiving, via a user interface of the location aware cellular phone device, input that defines at least one user of the one or more other users from the one or more lists of other users that is to have access to the visited geographic location data.

35. The method of claim 33 wherein reporting the information indicating the visited geographic location data comprises automatically and passively reporting the information indicating the visited geographic location data.

36. The method of claim 33 wherein the definition of the access rights for the one or more other users to access the visited geographic location data comprises, for each other user of at least a subset of the one or more other users, receiving, via a user interface of the location-aware cellular phone device, input that defines one or more categories of the visited geographic location data to be shared with the other user.

37. The method of claim 33 wherein the definition of the access rights for the one or more other users to access the visited geographic location data comprises, for each category of at least a subset of a plurality of categories of the visited geographic location data, receiving, via a user interface of the location-aware cellular phone device, input that defines at least one other user of the one or more other users to have access to the category of the visited geographic location data.

38. The method of claim 33 wherein reporting the information indicating the visited geographic location data comprises reporting the information indicating the visited geographic location data to the registration server.

39. The method of claim 33 wherein the one or more lists of other users comprises an Instant Messaging buddy list of a user of the location-aware cellular phone device.

40. The method of claim 33 wherein the one or more lists of other users comprises a contact list maintained by the location-aware cellular phone device.

41. The method of claim 33 wherein the one or more lists of other users comprises an e-mail contact list of a user of the location-aware cellular phone device.

42. The method of claim 33 wherein the visited geographic location data further defines ratings assigned to one or more of the geographic locations visited by the location-aware cellular phone device.

43. The method of claim 33 wherein the visited geographic location data further defines comments on one or more of the geographic locations visited by the location-aware cellular phone device.

44. The method of claim 33 wherein the visited geographic location data further defines emoticons assigned to one or more of the geographic locations visited by the location-aware cellular phone device.

45. The method of claim 33, further comprising:

enabling receipt and display of advertising information.

46. A non-transitory computer-readable medium storing software for instructing a controller of a location-aware cellular phone device that is configured for being registered with a registration server to:

enable access to one or more lists of other users to identify one or more other users with whom visited geographic location data is to be shared;

enable definition of access rights for the one or more other users to enable access to the visited geographic location data;

collect the visited geographic location data for geographic locations visited by the location-aware cellular phone device using a client-side application, the visited geographic location data comprising a plurality of the geographic locations visited by the location-aware cellular phone device, each geographic location visited time-stamped with a time of visit, the geographic locations visited automatically and passively recorded by the location-aware cellular phone device using a satellite-based location-fixing protocol and a detection network directory; and

report information indicating the visited geographic location data to a tracking server.

47. The non-transitory computer-readable medium of claim 46 where in order to report the information indicating the visited geographic location data, the software further instructs the controller of the location-aware cellular phone device to automatically and passively report the information indicating the visited geographic location data.

48. A non-transitory computer-readable medium storing software for instructing a controller of a location-aware cellular phone device that has registered with a registration server to:

enable identification of one or more other users with whom visited geographic location data is to be shared from one or more lists of other users;

enable definition of access rights for the one or more other users to allow for access to the visited geographic location data;

collect the visited geographic location data for geographic locations visited by the location-aware cellular phone device using a client-side application, the visited geographic location data comprising a plurality of the geographic locations visited by the location-aware cellular phone device, each geographic location visited time-stamped with a time of visit, the geographic locations visited automatically and passively recorded by the location-aware cellular phone device using a satellite-based location-fixing protocol and a detection network directory; and

report information indicating the visited geographic location data.

Images